|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: How we can find %age completion of query when is in running status [message #553211 is a reply to message #553205] |
Wed, 02 May 2012 09:36   |
cookiemonster
Messages: 13965 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
msol25 wrote on Wed, 02 May 2012 15:28hi Cookie,
I want to know what is the logic implemented in dbms_pipe for moving data from source session to destination session.Same logic i want to implement for getting information from running session.
Session 1 puts data in pipe. Session 2 gets data out of pipe.
Your problem is that session 1 can't put data in the pipe if it's busy doing something else - like a delete.
You could change your process to delete a row at time in a for loop and send data to a pipe between deletes.
The problem with that is that it'll make your already slow delete massively slower.
So you can do what you want but it'll cripple performance.
|
|
|
|
|
|
|
|
|
|
Re: How we can find %age completion of query when is in running status [message #553368 is a reply to message #553169] |
Thu, 03 May 2012 22:05   |
 |
Kevin Meade
Messages: 2103 Registered: December 1999 Location: Connecticut USA
|
Senior Member |
|
|
The question is difficult to answer and at the same time easy.
1) it is correct, that given Oracle's default consistency model, it is not possible to see the results of an insert/update/delete before it is committed. Therefore you cannot create a process that can directly interrogate tables to see how far along things are.
2) of course, the internal processes of the Oracle database can see this kind of information; they have to. Oracle routinely reads dirty pages as it does work and communicates this type of information between its processes as necessary. No real news there. This means that it is possible for Oracle to provide an API through which you can interrogate the system to get this kind of info and you can be sure they have such an API and use it in their toolsets. But it is not generally available and I know of no third party tools that takes advantage of same. How this information would be turned into a "progress picture" for a query or update etc. is another matter. Maybe you can ask Oracle corp. for the API? Worst they can do is say no.
3) You have been told the two most common ways of "watching the progress" of dml:
a) using v$session_longops to check the progress of Oracle expected long operations. A good example of this is a simple table scan of a large (large being whatever oracle decides). With some basic math and v$session_longops message interrogation, you can see the number of blocks in total to be read, and the number of blocks alread read, and various time elements, from which you can compute a %complete and estimated runtime, and completion date etc. I in fact do this all the time. In Data Warehouses were table scans are common, and in tuning long running queries where table scans are common, this is very helpful. I also use it to compare the "usable data movement speed" of different databases. Here is my special script for doing same. Have fun. This is one of my big 10 tools that gives me an edge over my fellow DBA'ers, but I guess it is time to share it.
col time_remaining head 'Seconds|Remaining'
col scanned_blocks head 'Scanned Blocks'
col all_blocks head 'All Blocks'
col blocks_remaining head 'Blocks|Remaining'
col opname format a25
col target format a35
col username format a15
col MB_per_Second form 990.0 head 'MB/s'
col pct_scanned head '%Scanned' format 990.00
col predicted_runtime_seconds head 'Estmd.|Runtime|Seconds'
col total_blocks head 'Total|Blocks'
col sid format 99990
col block_size format 99990 head 'Block|Size'
col hash_passes_temp format a20
with
scan_data as (
select
to_number(
substr(a.message
,instr(a.message,': ',1,2)+2
,instr(a.message,' out of ',1,1)-instr(a.message,': ',1,2)-1
)
)
/ to_number(
substr(a.message
,instr(a.message,' out of ',1,1)+8
,instr(a.message,' Blocks done',1,1)-instr(a.message,' out of ',1,1)-7
)
) *100 pct_scanned
, to_number(
substr(a.message
,instr(a.message,' out of ',1,1)+8
,instr(a.message,' Blocks done',1,1)-instr(a.message,' out of ',1,1)-7
)
)
- to_number(
substr(a.message
,instr(a.message,': ',1,2)+2
,instr(a.message,' out of ',1,1)-instr(a.message,': ',1,2)-1
)
) blocks_remaining
, a.time_remaining
, a.opname
, to_number(b.value) block_size
, a.target
, a.sid
, a.username
from (
select
replace(v$session_longops.message,'RMAN:','RMAN') message
, v$session_longops.time_remaining
, v$session_longops.opname
, v$session_longops.target
, v$session_longops.sid
, v$session_longops.username
from v$session_longops
, v$session
where v$session_longops.sid = v$session.sid
) a
,v$parameter b
where a.time_remaining > 0
and b.name = 'db_block_size'
)
select
round(blocks_remaining*block_size/1024/1024/time_remaining,1) MB_per_Second
, scan_data.time_remaining
, round(time_remaining/(1-pct_scanned/100)) predicted_runtime_seconds
, scan_data.pct_scanned
, scan_data.blocks_remaining
, round(blocks_remaining/(1-pct_scanned/100)) total_blocks
, scan_data.opname
, scan_data.BLOCK_SIZE
, scan_data.target
, (
select
DECODE(MAX(NUMBER_PASSES),0,'OPTIMAL',1,'ONE-PASS',NULL,NULL,'MULTI-PASS')||DECODE(max(TEMPSEG_SIZE),NULL,NULL,','||max(TEMPSEG_SIZE))
from v$sql_workarea_active
where v$sql_workarea_active.sid = scan_data.sid
and scan_data.opname in ('Hash Join','Sort Output')
and OPERATION_TYPE in ('HASH-JOIN','SORT','WINDOW (SORT)')
) hash_passes_temp
, scan_data.sid
, scan_data.username
from scan_data
order by time_remaining
/
Unfortunately as you will soon see, there is still some guessing and fill in the blank you will have to do where for those queries that are not all FULL TABLE SCAN/HASH JOIN. INDEX LOOKUP and NESTED LOOP aren't shown along with lots of other stuff. Still, this is a very useful script for queries. It is of much less use to INSERT/UPDATE/DELETE.
b) watching "UNDO". This is way tougher and I almost never use it to watch a query. It normally requires that you know how much work is being done by the insert/update/delete and then you simply measure in your head the amount of undo done vs. what you have seen before. You can do similar things with almost any statistic or metric.
The most useful way I have found to watch UNDO is to see if the numbers are going up or down. Numbers going up means your transaction is doing work. Numbers going down means your transaction is rolling back. You can compute how long it will take to rollback by clocking some amount of undo number changes and then doing the math. Here is a simple showundo script. I have not run it in a while so like everything, no warranty express or implied...
select s.sid, s.username, rn.name, rs.curext
,rs.curblk, t.used_ublk, t.used_urec
from v$transaction t
,v$session s
,v$rollname rn
,v$rollstat rs
where t.addr = s.taddr
and t.xidusn = rn.usn
and rn.usn = rs.usn
order by s.sid
/
Good luck. Maybe Oracle will provide us an update to EM one of these days with an "active execution" page that shows some graph or chart or other visual to help us understand an executing query.
Kevin
|
|
|
|
|
Re: How we can find %age completion of query when is in running status [message #553496 is a reply to message #553169] |
Sat, 05 May 2012 06:38  |
martijn
Messages: 286 Registered: December 2006 Location: Netherlands
|
Senior Member |
|
|
well ... you posted that you are not interested in performance so....we can device a solution.
(however I would not ever use it in a serious setup)
1 - create a logging table
2 - create a procedure which logs to that table. This table uses the "pragma autonomous_transaction"
create or replace procedure message2log (message IN varchar2)
is
PRAGMA AUTONOMOUS_TRANSACTION;
begin
insert into log values (sysdate,message);
commit;
end;
3 - create a trigger on the table you are deleting from which uses the procedure from step 2
create or replace trigger log4table
before delete
on <table_name>
for each row
begin
message2log('deleting '||:old.num);
end;
4 - start the delete process on your table
5 - query your log-table to see how far you are
Again.....you can see how far the process is, but the process will be soooooo slow. Also it will take a lot of space. And...what happens when you do not commit the delete?.....your logging tells you the rows are deleted.
Have fun
|
|
|