I'm using mysql client to execute script files like: mysql -u root --prompt="memsql>" < file.sql. How can I retrieve the processing time of the query?
In other systems I usually do smth like:
BEGIN
start = now();
select *, some_udf(X_ID) from X;
end = now();
select DATEDIFF(start, end);
END;
But this is somehow not possible in Memsql.
EDIT: It seems there is a workload profiling feature in 5.8 but this section is not there in version 6. Also the views mv_activities/mv_finished_tasks nor the system variable read_advanced_counters exist in my system.
You can do this in a stored procedure: http://docs.memsql.com/v6.0-beta/docs/create-procedure.
Related
I'm running a procedure in parallel by using oracle's dbms parallel execute utility which chunks the workload ; but I have few chunks failing and I can't see any error logs. Is there a way to find out ?
Check this. The last two columns.
SELECT *
FROM user_parallel_execute_chunks
WHERE task_name = '{task name}'
ORDER BY chunk_id
/
I'm not sure, but probably you can use job_name from previous table. And query for more information from scheduler's tables. user_scheduler_job_run_details, user_scheduler_job_log.
I've been looking for answer to this but I can't seem to find the right answer online and my problem goes like this.
I'm trying to query a set of records from another table which is in an another database installed in a different machine. To make it clearer:
My stored procedure is running on IP: 192.168.XX.X1. I get to retrieve all the information I need in this server but I have another set of information or records that can only be retrieved from IP: 192.168.XX.X2.
I was thinking to achieve something like:
DECLARE
-- given that both queries will only return 1 record
CURSOR IS curSample1
SELECT * FROM Database1.Table1;
colSample curSample1%ROWTYPE;
CURSOR IS curSample2
SELECT * FROM Database2.Table1;
colSample curSample2%ROWTYPE;
vText1 VARCHAR(20);
vText2 VARCHAR(20);
BEGIN
OPEN curSample1;
LOOP
FETCH curSample1 INTO colSample1;
EXIT WHEN curSample1%NOTFOUND;
vText1 := colSample1.Column1;
END LOOP;
CLOSE curSample1;
OPEN curSample2;
LOOP
FETCH curSample2 INTO colSample2;
EXIT WHEN curSample2%NOTFOUND;
vText2 := colSample2.Column2;
END LOOP;
CLOSE curSample2;
dbms_output.put_line(vText1 || ',' || vText2);
END;
Any help you could provide will be much appreciated. Thank you very much.
Note: I'm trying this approach as this is the only way we could possibly do it as of now. Thanks again.
You will have to create a db link between your database 1 and database 2. For creating a database link it is not required to have both databases on the same server. Since in your case the databases are on different server you can start with the following steps.
You need a tns entry (pointing to database 2) in the tnsnames.ora file on your database 1 server. You can check if you have this entry by connecting to SQLPLUS from your database 1 machine to database 2.
sqlplus <username>/<password>#<tnsnames of database2>
If you are able to connect from your database 1 server then you can proceed with the following steps for creating the db link.
CREATE DATABASE LINK <dblink_name> CONNECT TO <username> IDENTIFIED BY <password> USING <tnsnames of database2>
Post this you can test your database link by running the following SQL command.
select * from Table#<dblink_name>;
as i know you cannot query data cross database directly.
1,maybe you can use DBlink or DataSync to let the data which in other database can be query.
2,instead of pl/sql procedure, use other development language to do cross DB process is a good idea(ex independent java program).
3,instead of pl/sql procedure, use Oracle Java Procedure to do this.
I'm running a query across a database link to a Sybase server from Oracle.
In it's where clause is a restriction on date, and I want it tied to sysdate, so something like this:
select * from some_remote_view where some_numeric_key = 1 and
some_date > sysdate+2
The problem is, when I do explain plan, only the condition some_numeric_key = 1 shows up in the actual sql that is getting remoted to the sybase server. Oracle is expecting to perform the date filter on its side.
This is causing a performance nightmare - I need that date filter remoted across to have this query working quickly
Even if I try something like casting the sysdate to a charcater string like this:
to_char(sysdate-2,'YYYY-MM-DD')
It still does not remote it.
Is there anything I can do to get Oracle to remote this date filter across the db link to Sybase?
Doing integration between Oracle and other platforms I often run into this problem, not just with SYSDATE but with other non-standard functions as well.
There are two methods to work around the issue, the first being the most reliable in my experience.
First, you can create a view on the remote db with the filters you need, then on the Oracle side you just select from the new view without additional filters.
Second, if you are not allowed to create objects on the remote side, try using bind variables (of the correct data type!) in your Oracle SELECT statement, e.g.:
declare
v_some_date constant date := sysdate + 2;
begin
insert into oracle_table (...)
select ...
from remote_table#db_link t
where t.some_numeric_key = 1
and t.some_date > v_some_date;
commit;
end;
/
Can anybody let me know if there is any way to find out cost of a stored procedure in Oracle? If no direct way is there, I would like to know any substitutes.
The way I found the cost is doing an auto trace of all the queries used in the stored procedure and then estimate the proc cost according to the frequency of the queries execution.
In addition to that I would like suggestions to optimize my stored procedure especially the query given below.
Logic of the procedure:
Below is the dynamic sql query used as a cursor in my stored procedure. This cursor is opened and fetched inside a loop. I fetch the info and put them in a varray, count the data and then insert it to a table.
My objective is to find out the cost of the proc as well as optimize the sp.
SELECT DISTINCT acct_no
FROM raw
WHERE 1=1
AND code = ''' || code ||
''' AND qty < 0
AND acct_no
IN (SELECT acct_no FROM ' || table_name || ' WHERE counter =
(SELECT MAX(counter) FROM ' || table_name || '))
One of the best tool in analyzing SQL and PLSQL performance is the native SQL trace.
enable tracing in your session:
SQL> alter session set SQL_TRACE=TRUE;
Session altered
Run your procedure
Exit your session
Navigate to your server udump directory and find your trace file (usually the latest)
Run tkprof
This will produce a file containing a list of all statements with lots of information, including the number of times each was executed, its query plan and statistics. This is more detailed and precise than manually running the plan for each select.
If you want to optimize performance on a procedure, you would usually sort the trace file by the time taken to execute (with sort=EXEELA) or fetch SQL and try to optimize the queries that make the most work.
You can also make the trace file log wait events by using the following command at step 1:
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';
The way to find out the cost (in execution of time) for a stored procedure is to employ a profiler. 11g introduced the Hierarchical Profiler which is highly neat. Find out more.
Prior to 11g there was only the DBMS_PROFILER, which is good enough, especially if your stored procedure doesn't use objects in other schemas. Find out more.
Trace is good for identifying poorly performing SQL. Profilers are good for identifying the cost of the PL/SQL elements of a stored proc. If your proc has some expensive computation elements which don't read or write to tables then that won't show up in SQL trace.
Likewise if you have a well-tuned SQL statement but use it badly ia profiler run is likely to be more help than trace. An example of what I mean is repeatedly executing the same SELECT statement inside a Cursor loop: I know that's not quite what you're doing but it's close enough.
Apparently the hierarchical profiler DBMS_HPROF is installed by default in 11g but a DBA has to grant some privileges to developers who want to use it. Find out more.
To install the DBMS_PROFILER in 10g (or earlier) a DBA has to run this script:
$ORACLE_HOME/rdbms/admin/proftab.sql
Be sure to get the reporting infrastructure as well:
$ORACLE_HOME/plsql/demo/profsum.sql
(The name or location of this script may vary in earlier versions).
The easy way is to execute the procedure and then query v$sql.
if you want a little tip to make your life easier (not just for packages) add a blank comment to the query inside the procedure, something like
select /* BIG DADDY */ * from dual;
and then query v$sql as follows
select * from v$sql where sql_text like '%BIG DADDY%';
the best way is definitely the way #Vincent Malgrat suggested.
good luck.
I have been trying to address the issue of how Oracle processes ROWNUM and SELECT ... FOR UPDATE SKIP LOCKED while trying to return several rows that aren't locked. I have tried a number of the solutions from the following: Force Oracle to return TOP N rows with SKIP LOCKED, as well as several other examples that look very similar to the ones found on that question. I know Oracle AQ is probably the best solution to this, but we have very little control over the databases and I have met with considerable resistance to the idea.
The problem I am running into is trying to get the results back to Java using JDBC. I have tried setFetchSize(20), but I run into the issue where only the top 20 rows are distributed to the clients. I usually see one processing agent getting all 20 rows or a few processors getting some rows, all of them adding up to 20. This is very much like the behavior one would see with using ROWNUM in conjunction with SELECT ... FOR UPDATE SKIP LOCKED.
The most promising solution I have tried is the following function:
create type IND_ID as object
(
ID varchar2(200)
);
create type IND_ID_TABLE as table of IND_ID;
create or replace function SELECTIDS return IND_ID_TABLE
pipelined is
ST_CURSOR SYS_REFCURSOR;
ID_REC IND_ID := IND_ID(null);
begin
open ST_CURSOR for
select ID
from TABLE
/* where clause */
for update SKIP LOCKED;
loop
fetch ST_CURSOR
into ID_REC.ID;
exit when ST_CURSOR%rowcount > 20 or ST_CURSOR%notfound;
pipe row(ID_REC);
end loop;
close ST_CURSOR;
return;
end;
However, when I try invoking it like so:
select * from table(SELECTIDS)
I get an ORA-14551: cannot perform a DML operation inside a query error, which I now understand is an issue with transactions. Removing the locks causes the function to return rows.
How can I get multiple rows out of this function into JDBC while preserving the locks?
This not gonna work. You calling a pl/sql function as part of a select statement and try to start a transaction in that function. I think the error is pretty clear.