Why parallel query use direct path read ??
I think because access buffer cache needs latch and buffer block lock,if parallel query don't use direct path read ,parallel query will be impacted by Serialization mechanism such as latch and lock .so oracle choose direct path read to avoid it .
anybody have a good idea ??
Edited by: jinyu on Dec 8, 2008 7:52 AM
jinyu wrote:
I think because access buffer cache needs latch and buffer block lock,if parallel query don't use direct path read ,parallel query will be impacted by Serialization mechanism such as latch and lock .so oracle choose direct path read to avoid it .Jinyu,
basically, yes I think that's it. The purpose of parallel query is to scan a very large segment, because the overhead of communication between the processes and maintaining/starting up the parallel slave renders the operation inefficient for small segments.
Therefore I guess the assumption is that the segment to scan is probably very large, the fraction of the blocks in the buffer cache would be only very small in comparison to the blocks to scan, and therefore the reduced overhead of directly reading the blocks bypassing all the serialization issues of the buffer cache should outweigh the "un-buffered" blocks issue and save the buffer cache for objects that benefit more from being cached.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/
Similar Messages
-
Serial table scan with direct path read compared to db file scattered read
Hi,
The environment
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit
8K block size
db_file_multiblock_read_count is 128
show sga
Total System Global Area 1.6702E+10 bytes
Fixed Size 2219952 bytes
Variable Size 7918846032 bytes
Database Buffers 8724152320 bytes
Redo Buffers 57090048 bytes
16GB of SGA with 8GB of db buffer cache.
-- database is built on Solid State Disks
-- SQL trace and wait events
DBMS_MONITOR.SESSION_TRACE_ENABLE ( waits=>true )
-- The underlying table is called tdash. It has 1.7 Million rows based on data in all_objects. NO index
TABLE_NAME Rows Table Size/MB Used/MB Free/MB
TDASH 1,729,204 15,242 15,186 56
TABLE_NAME Allocated blocks Empty blocks Average space/KB Free list blocks
TDASH 1,943,823 7,153 805 0
Objectives
To show that when serial scans are performed on database built on Solid State Disks (SSD) compared to Magnetic disks (HDD), the performance gain is far less compared to random reads with index scans on SSD compared to HDD
Approach
We want to read the first 100 rows of tdash table randomly into buffer, taking account of wait events and wait times generated. The idea is that on SSD the wait times will be better compared to HDD but not that much given the serial nature of table scans.
The code used
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'test_with_tdash_ssdtester_noindex';
DECLARE
type array is table of tdash%ROWTYPE index by binary_integer;
l_data array;
l_rec tdash%rowtype;
BEGIN
SELECT
a.*
,RPAD('*',4000,'*') AS PADDING1
,RPAD('*',4000,'*') AS PADDING2
BULK COLLECT INTO
l_data
FROM ALL_OBJECTS a;
DBMS_MONITOR.SESSION_TRACE_ENABLE ( waits=>true );
FOR rs IN 1 .. 100
LOOP
BEGIN
SELECT * INTO l_rec FROM tdash WHERE object_id = l_data(rs).object_id;
EXCEPTION
WHEN NO_DATA_FOUND THEN NULL;
END;
END LOOP;
END;
/Server is rebooted prior to any tests
Whern run as default, the optimizer (although some attribute this to the execution engine) chooses direct path read into PGA in preference to db file scattered read.
With this choice it takes 6,520 seconds to complete the query. The results are shown below
SQL ID: 78kxqdhk1ubvq
Plan Hash: 1148949653
SELECT *
FROM
TDASH WHERE OBJECT_ID = :B1
call count cpu elapsed disk query current rows
Parse 1 0.01 0.00 2 47 0 0
Execute 100 0.00 0.00 1 51 0 0
Fetch 100 10.88 6519.89 194142802 194831012 0 100
total 201 10.90 6519.90 194142805 194831110 0 100
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 96 (SSDTESTER) (recursive depth: 1)
Rows Row Source Operation
1 TABLE ACCESS FULL TDASH (cr=1948310 pr=1941430 pw=0 time=0 us cost=526908 size=8091 card=1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
1 TABLE ACCESS MODE: ANALYZED (FULL) OF 'TDASH' (TABLE)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
Disk file operations I/O 3 0.00 0.00
db file sequential read 2 0.00 0.00
direct path read 1517504 0.05 6199.93
asynch descriptor resize 196 0.00 0.00
DECLARE
type array is table of tdash%ROWTYPE index by binary_integer;
l_data array;
l_rec tdash%rowtype;
BEGIN
SELECT
a.*
,RPAD('*',4000,'*') AS PADDING1
,RPAD('*',4000,'*') AS PADDING2
BULK COLLECT INTO
l_data
FROM ALL_OBJECTS a;
DBMS_MONITOR.SESSION_TRACE_ENABLE ( waits=>true );
FOR rs IN 1 .. 100
LOOP
BEGIN
SELECT * INTO l_rec FROM tdash WHERE object_id = l_data(rs).object_id;
EXCEPTION
WHEN NO_DATA_FOUND THEN NULL;
END;
END LOOP;
END;
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 3.84 4.03 320 48666 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 1 3.84 4.03 320 48666 0 1
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 96 (SSDTESTER)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
SQL ID: 9babjv8yq8ru3
Plan Hash: 0
BEGIN DBMS_OUTPUT.GET_LINES(:LINES, :NUMLINES); END;
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 96 (SSDTESTER)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 2 3.84 4.03 320 48666 0 2
Fetch 0 0.00 0.00 0 0 0 0
total 3 3.84 4.03 320 48666 0 2
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.00 0.00
log file sync 1 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 9 0.01 0.00 2 47 0 0
Execute 129 0.01 0.00 1 52 2 1
Fetch 140 10.88 6519.89 194142805 194831110 0 130
total 278 10.91 6519.91 194142808 194831209 2 131
Misses in library cache during parse: 9
Misses in library cache during execute: 8
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 5 0.00 0.00
Disk file operations I/O 3 0.00 0.00
direct path read 1517504 0.05 6199.93
asynch descriptor resize 196 0.00 0.00
102 user SQL statements in session.
29 internal SQL statements in session.
131 SQL statements in session.
1 statement EXPLAINed in this session.
Trace file: mydb_ora_16394_test_with_tdash_ssdtester_noindex.trc
Trace file compatibility: 11.1.0.7
Sort options: default
1 session in tracefile.
102 user SQL statements in trace file.
29 internal SQL statements in trace file.
131 SQL statements in trace file.
11 unique SQL statements in trace file.
1 SQL statements EXPLAINed using schema:
ssdtester.plan_table
Schema was specified.
Table was created.
Table was dropped.
1531657 lines in trace file.
6520 elapsed seconds in trace file.I then force the query not to use direct path read by invoking
ALTER SESSION SET EVENTS '10949 trace name context forever, level 1' -- No Direct path read ;In this case the optimizer uses db file scattered read predominantly and the query takes 4,299 seconds to finish which is around 34% faster than using direct path read (default).
The report is shown below
SQL ID: 78kxqdhk1ubvq
Plan Hash: 1148949653
SELECT *
FROM
TDASH WHERE OBJECT_ID = :B1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 2 47 0 0
Execute 100 0.00 0.00 2 51 0 0
Fetch 100 143.44 4298.87 110348670 194490912 0 100
total 201 143.45 4298.88 110348674 194491010 0 100
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 96 (SSDTESTER) (recursive depth: 1)
Rows Row Source Operation
1 TABLE ACCESS FULL TDASH (cr=1944909 pr=1941430 pw=0 time=0 us cost=526908 size=8091 card=1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
1 TABLE ACCESS MODE: ANALYZED (FULL) OF 'TDASH' (TABLE)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
Disk file operations I/O 3 0.00 0.00
db file sequential read 129759 0.01 17.50
db file scattered read 1218651 0.05 3770.02
latch: object queue header operation 2 0.00 0.00
DECLARE
type array is table of tdash%ROWTYPE index by binary_integer;
l_data array;
l_rec tdash%rowtype;
BEGIN
SELECT
a.*
,RPAD('*',4000,'*') AS PADDING1
,RPAD('*',4000,'*') AS PADDING2
BULK COLLECT INTO
l_data
FROM ALL_OBJECTS a;
DBMS_MONITOR.SESSION_TRACE_ENABLE ( waits=>true );
FOR rs IN 1 .. 100
LOOP
BEGIN
SELECT * INTO l_rec FROM tdash WHERE object_id = l_data(rs).object_id;
EXCEPTION
WHEN NO_DATA_FOUND THEN NULL;
END;
END LOOP;
END;
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 3.92 4.07 319 48625 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 1 3.92 4.07 319 48625 0 1
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 96 (SSDTESTER)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
SQL ID: 9babjv8yq8ru3
Plan Hash: 0
BEGIN DBMS_OUTPUT.GET_LINES(:LINES, :NUMLINES); END;
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 96 (SSDTESTER)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 2 3.92 4.07 319 48625 0 2
Fetch 0 0.00 0.00 0 0 0 0
total 3 3.92 4.07 319 48625 0 2
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.00 0.00
log file sync 1 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 9 0.01 0.00 2 47 0 0
Execute 129 0.00 0.00 2 52 2 1
Fetch 140 143.44 4298.87 110348674 194491010 0 130
total 278 143.46 4298.88 110348678 194491109 2 131
Misses in library cache during parse: 9
Misses in library cache during execute: 8
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 129763 0.01 17.50
Disk file operations I/O 3 0.00 0.00
db file scattered read 1218651 0.05 3770.02
latch: object queue header operation 2 0.00 0.00
102 user SQL statements in session.
29 internal SQL statements in session.
131 SQL statements in session.
1 statement EXPLAINed in this session.
Trace file: mydb_ora_26796_test_with_tdash_ssdtester_noindex_NDPR.trc
Trace file compatibility: 11.1.0.7
Sort options: default
1 session in tracefile.
102 user SQL statements in trace file.
29 internal SQL statements in trace file.
131 SQL statements in trace file.
11 unique SQL statements in trace file.
1 SQL statements EXPLAINed using schema:
ssdtester.plan_table
Schema was specified.
Table was created.
Table was dropped.
1357958 lines in trace file.
4299 elapsed seconds in trace file.I note that there are 1,517,504 waits with direct path read with total time of nearly 6,200 seconds. In comparison with no direct path read, there are 1,218,651 db file scattered read waits with total wait time of 3,770 seconds. My understanding is that direct path read can use single or multi-block read into the PGA. However db file scattered reads do multi-block read into multiple discontinuous SGA buffers. So it is possible given the higher number of direct path waits that the optimizer cannot do multi-block reads (contigious buffers within PGA) and hence has to revert to single blocks reads which results in more calls and more waits?.
Appreciate any advise and apologies for being long winded.
Thanks,
MichHi Charles,
I am doing your tests for t1 table using my server.
Just to clarify my environment is:
I did the whole of this test on my server. My server has I7-980 HEX core processor with 24GB of RAM and 1 TB of HDD SATA II for test/scratch backup and archive. The operating system is RHES 5.2 64-bit installed on a 120GB OCZ Vertex 3 Series SATA III 2.5-inch Solid State Drive.
Oracle version installed was 11g Enterprise Edition Release 11.2.0.1.0 -64bit. The binaries were created on HDD. Oracle itself was configured with 16GB of SGA, of which 7.5GB was allocated to Variable Size and 8GB to Database Buffers.
For Oracle tablespaces including SYS, SYSTEM, SYSAUX, TEMPORARY, UNDO and redo logs, I used file systems on 240GB OCZ Vertex 3 Series SATA III 2.5-inch Solid State Drive. With 4K Random Read at 53,500 IOPS and 4K Random Write at 56,000 IOPS (manufacturer’s figures), this drive is probably one of the fastest commodity SSDs using NAND flash memory with Multi-Level Cell (MLC). Now my T1 table created as per your script and has the following rows and blocks (8k block size)
SELECT
NUM_ROWS,
BLOCKS
FROM
USER_TABLES
WHERE
TABLE_NAME='T1';
NUM_ROWS BLOCKS
12000000 178952which is pretty identical to yours.
Then I run the query as brelow
set timing on
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'test_bed_T1';
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8';
SELECT
COUNT(*)
FROM
T1
WHERE
RN=1;
which gives
COUNT(*)
60000
Elapsed: 00:00:05.29
tkprof output shows
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.02 5.28 178292 178299 0 1
total 4 0.02 5.28 178292 178299 0 1
Compared to yours:
Fetch 2 0.60 4.10 178493 178498 0 1
It appears to me that my CPU utilisation is by order of magnitude better but my elapsed time is worse!
Now the way I see it elapsed time = CPU time + wait time. Further down I have
Rows Row Source Operation
1 SORT AGGREGATE (cr=178299 pr=178292 pw=0 time=0 us)
60000 TABLE ACCESS FULL T1 (cr=178299 pr=178292 pw=0 time=42216 us cost=48697 size=240000 card=60000)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
1 SORT (AGGREGATE)
60000 TABLE ACCESS MODE: ANALYZED (FULL) OF 'T1' (TABLE)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 3 0.00 0.00
SQL*Net message from client 3 0.00 0.00
Disk file operations I/O 3 0.00 0.00
direct path read 1405 0.00 4.68
Your direct path reads are
direct path read 1404 0.01 3.40Which indicates to me you have faster disks compared to mine, whereas it sounds like my CPU is faster than yours.
With db file scattered read I get
Elapsed: 00:00:06.95
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 1.22 6.93 178293 178315 0 1
total 4 1.22 6.94 178293 178315 0 1
Rows Row Source Operation
1 SORT AGGREGATE (cr=178315 pr=178293 pw=0 time=0 us)
60000 TABLE ACCESS FULL T1 (cr=178315 pr=178293 pw=0 time=41832 us cost=48697 size=240000 card=60000)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
1 SORT (AGGREGATE)
60000 TABLE ACCESS MODE: ANALYZED (FULL) OF 'T1' (TABLE)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
Disk file operations I/O 3 0.00 0.00
db file sequential read 1 0.00 0.00
db file scattered read 1414 0.00 5.36
SQL*Net message from client 2 0.00 0.00
compared to your
db file scattered read 1415 0.00 4.16On the face of it with this test mine shows 21% improvement with direct path read compared to db scattered file read. So now I can go back to re-visit my original test results:
First default with direct path read
call count cpu elapsed disk query current rows
Parse 1 0.01 0.00 2 47 0 0
Execute 100 0.00 0.00 1 51 0 0
Fetch 100 10.88 6519.89 194142802 194831012 0 100
total 201 10.90 6519.90 194142805 194831110 0 100
CPU ~ 11 sec, elapsed ~ 6520 sec
wait stats
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
direct path read 1517504 0.05 6199.93
roughly 0.004 sec for each I/ONow with db scattered file read I get
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 2 47 0 0
Execute 100 0.00 0.00 2 51 0 0
Fetch 100 143.44 4298.87 110348670 194490912 0 100
total 201 143.45 4298.88 110348674 194491010 0 100
CPU ~ 143 sec, elapsed ~ 4299 sec
and waits:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 129759 0.01 17.50
db file scattered read 1218651 0.05 3770.02
roughly 17.5/129759 = .00013 sec for single block I/O and 3770.02/1218651 = .0030 for multi-block I/ONow my theory is that the improvements comes from the large buffer cache (8320MB) inducing it to do some read aheads (async pre-fetch). Read aheads are like quasi logical I/Os and they will be cheaper compared to physical I/O. When there is large buffer cache and read aheads can be done then using buffer cache is a better choice than PGA?
Regards,
Mich -
Does anyone know how to control/predict the use of Adaptive Direct path Reads in 11g ?? For the unitiated, this is a new behavior of 11g, where if Oracle perceives a large amount of data is going to be "scanned", it switches to reading directly into the PGA, bypassing the SGA.
PROS -
-- Direct Path reads are much faster than db scattered reads.
-- These large reads (usually FTS) do not flush useful blocks out of the SGA.
CONS --
-- The results are not cached for the next query accessing them.
-- Multiple large reads of the same data, do not share blocks, and can overwhelm a system.
This last CON is the reason for this question.. I have an application that did 33 concurrent FTS of the same table . Since it did direct path reads for every session, none of the blocks were shared, and each process read the same blocks from disk directly into the PGA. What was the result ??? The storage team reported that the FA's were totally saturated, something they had never seen in their careeer. One little blade with 33 processes overwhelmed our infrastructure with a FTS.
Also, this makes it difficult to utilize Dbreplay. I am trying to compare the performance of the 10g optimizer to the 11g optimizer by changing the Optimizer_features_enabled.. This does NOT stop direct path reads from happening.. The PHV is the same regardless of whether it uses direct path reads or not.. This behavior can affect my results (good or bad), and thus obfuscate the interpretations of the performance when upgrading.Bryan Grenn wrote:
1) NO one else is really seeing issues with it on 11g, and I'm the only one that has gotten bitten by it.
or
2) Not enough customer base has upgraded and seen this.
I've seen it twice and (given the comments in the link above) presumably Tanel has seen it too. SO I'd gp with (2).
There's a bit of a catch-22 with this. When the database starts up the object is not cached, so the code goes for a direct path read. Because it's doing direct path reads it doesn't get cached as quickly as it used to be - so Oracle carries on doing direct path reads.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan -
请教高手:parallel query时为何会有 direct path reads?
请教高手:parallel query时为何会有 direct path reads?以及这个过程中会有什么细节呢？
请教高手:parallel query时为何会有 direct path reads?以及这个过程中会有什么细节呢？
-
Query Tuning (sequential read + direct path read/write temp)
Following query takes nearly 10 minutes under 10.2.0.2 on WIN2K3 to execute but I am sure there would be an alternate to tune it further.
Major waits are 'db file sequential read' and 'direct path read temp' in addition to 'direct path write temp'
Increasing/tuning the work_area_policy/sort_area_size would help? moving the tables to faster disk would reduce PIO causing sequential read, query re-writing would prove to be helpful?.
Below is the tkprof:
SELECT
P.PER_ID
, CL.DESCR
, P.ENG_NAME
, P.ARA_NAME
, P.NATION
, P.ADDR
, ('Mob:' || NVL(P.MOB, '') || ', Home:' || NVL(P.HOME, '') || ', Bus.:' || NVL(P.BUS, '') || ', Fax:' || NVL(P.FAX, '')) PHONE
, SUM(CASE
WHEN FT.FT_TYPE_FLG IN ('BS','BX','AD','AX') THEN FT.CUR_AMT
ELSE 0
END) BILL
, SUM(CASE
WHEN FT.FT_TYPE_FLG IN ('PS','PX') THEN FT.CUR_AMT * -1
ELSE 0
END) PAY
, SUM(FT.CUR_AMT) DUE
, SUM(CASE
WHEN FT.FREEZE_DTTM > '03-JUN-08' THEN
CASE WHEN FT.FT_TYPE_FLG IN ('PS','PX') THEN FT.CUR_AMT * -1
ELSE 0
END
ELSE 0
END) PAY_02JUN
FROM
CI_FT FT
, CI_SA SA
, CI_ACCT_CHAR AC
, CI_CUST_CL_L CL
, CI_ACCT A
, CI_ACCT_PER AP
SELECT
P.PER_ID
, (P.CITY || ', ' || P.STATE || ',' || P.COUNTRY) ADDR
, MAX(DECODE(PP.PHONE_TYPE_CD, 'MOB ', PP.PHONE)) MOB
, MAX(DECODE(PP.PHONE_TYPE_CD, 'BUSN ', PP.PHONE)) BUS
, MAX(DECODE(PP.PHONE_TYPE_CD, 'HOME ', PP.PHONE)) HOME
, MAX(DECODE(PP.PHONE_TYPE_CD, 'FAX ', PP.PHONE)) FAX
, MAX(DECODE(PN.NAME_TYPE_FLG, 'PRIM', PN.ENTITY_NAME)) ENG_NAME
, MAX(DECODE(PN.NAME_TYPE_FLG, 'ALT ', PN.ENTITY_NAME)) ARA_NAME
, MAX(DECODE(PC.CHAR_TYPE_CD, 'NATION ', PC.CHAR_VAL)) NATION
FROM
CI_PER P
, CI_PER_PHONE PP
, CI_PER_NAME PN
, CI_PER_CHAR PC
WHERE
P.PER_ID = PP.PER_ID (+)
AND P.PER_ID = PN.PER_ID (+)
AND P.PER_ID = PC.PER_ID (+)
GROUP BY
P.PER_ID
, (P.CITY || ', ' || P.STATE || ',' || P.COUNTRY)
) P
WHERE
P.PER_ID = AP.PER_ID
AND AP.ACCT_ID = AC.ACCT_ID
AND AP.ACCT_ID = SA.ACCT_ID
AND AP.MAIN_CUST_SW = 'Y'
AND A.ACCT_ID = SA.ACCT_ID
AND A.ACCT_ID = AP.ACCT_ID
AND AC.CHAR_TYPE_CD = 'ACCTYPE'
AND AC.CHAR_VAL IN ('UOS', 'DEFAULT')
AND AC.ACCT_ID = SA.ACCT_ID
AND CL.LANGUAGE_CD = 'ENG'
AND A.ACCT_ID = AC.ACCT_ID
AND A.CUST_CL_CD = CL.CUST_CL_CD
AND SA.SA_ID = FT.SA_ID
AND FT.FREEZE_DTTM IS NOT NULL
GROUP BY
P.PER_ID
, CL.DESCR
, P.ENG_NAME
, P.ARA_NAME
, P.NATION
, P.ADDR
, ('Mob:' || NVL(P.MOB, '') || ', Home:' || NVL(P.HOME, '') || ', Bus.:' || NVL(P.BUS, '') || ', Fax:' || NVL(P.FAX, ''))
HAVING
SUM(FT.CUR_AMT) > 0
call count cpu elapsed disk query current rows
Parse 1 0.64 0.64 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 304 353.09 430.04 21720 52997832 0 4543
total 306 353.73 430.69 21720 52997832 0 4543
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 79 (CISADM)
Rows Row Source Operation
4543 FILTER (cr=52997832 pr=21720 pw=10311 time=430019418 us)
5412 HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=430015729 us)
199471 VIEW (cr=52997832 pr=21720 pw=10311 time=423392346 us)
199471 HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=423192867 us)
4013304 TABLE ACCESS BY INDEX ROWID CI_FT (cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785 NESTED LOOPS (cr=49295470 pr=8987 pw=0 time=407554071 us)
13704480 NESTED LOOPS (cr=21818135 pr=7655 pw=0 time=287797921 us)
2782119 NESTED LOOPS OUTER (cr=3915432 pr=2950 pw=0 time=38953485 us)
571492 NESTED LOOPS OUTER (cr=2545763 pr=2711 pw=0 time=7433194 us)
286061 NESTED LOOPS OUTER (cr=2253263 pr=2671 pw=0 time=26607373 us)
123411 NESTED LOOPS (cr=1989056 pr=2642 pw=0 time=22711194 us)
123411 NESTED LOOPS (cr=1864959 pr=2642 pw=0 time=20860026 us)
123411 NESTED LOOPS (cr=1494040 pr=1754 pw=0 time=15553373 us)
243088 NESTED LOOPS (cr=29540 pr=1754 pw=0 time=10213331 us)
13227 TABLE ACCESS FULL CI_PER (cr=251 pr=49 pw=0 time=43331 us)
243088 INDEX RANGE SCAN XM150S1 (cr=29289 pr=1705 pw=0 time=6178159 us)(object id 97173)
123411 INLIST ITERATOR (cr=1464500 pr=0 pw=0 time=7220251 us)
123411 INDEX RANGE SCAN CM064S0 (cr=1464500 pr=0 pw=0 time=5631936 us)(object id 108631)
123411 TABLE ACCESS BY INDEX ROWID CI_ACCT (cr=370919 pr=888 pw=0 time=7241286 us)
123411 INDEX UNIQUE SCAN XM148P0 (cr=247508 pr=0 pw=0 time=1198649 us)(object id 97147)
123411 TABLE ACCESS BY INDEX ROWID CI_CUST_CL_L (cr=124097 pr=0 pw=0 time=1391837 us)
123411 INDEX UNIQUE SCAN XC523P0 (cr=686 pr=0 pw=0 time=595005 us)(object id 97745)
283749 TABLE ACCESS BY INDEX ROWID CI_PER_PHONE (cr=264207 pr=29 pw=0 time=3549713 us)
283749 INDEX RANGE SCAN XM172P0 (cr=125886 pr=4 pw=0 time=1307395 us)(object id 98733)
571492 INDEX RANGE SCAN XM171S2 (cr=292500 pr=40 pw=0 time=2976807 us)(object id 98728)
2777066 TABLE ACCESS BY INDEX ROWID CI_PER_CHAR (cr=1369669 pr=239 pw=0 time=23084761 us)
2777066 INDEX RANGE SCAN XM168P0 (cr=596156 pr=53 pw=0 time=7394319 us)(object id 98719)
13704480 TABLE ACCESS BY INDEX ROWID CI_SA (cr=17902703 pr=4705 pw=0 time=163320548 us)
13704480 INDEX RANGE SCAN XM199S1 (cr=5688247 pr=104 pw=0 time=51063061 us)(object id 98973)
4013304 INDEX RANGE SCAN CM112S1 (cr=27477335 pr=1332 pw=0 time=124063022 us)(object id 116797)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 304 0.00 0.00
db file sequential read 11366 0.34 65.63
direct path write temp 1473 0.06 2.91
latch: cache buffers chains 17 0.00 0.00
db file scattered read 7 0.01 0.03
read by other session 2 0.00 0.00
direct path read temp 1473 0.03 6.85
SQL*Net message from client 304 0.02 2.74
SQL*Net more data to client 292 0.00 0.00
********************************************************************************Luckys
I've just realised that I mis-read part of your plan:
199471 HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=423192867 us)
4013304 TABLE ACCESS BY INDEX ROWID CI_FT (cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785 NESTED LOOPS (cr=49295470 pr=8987 pw=0 time=407554071 us)The time component for a line is the time it supplies, plus the sum of the time from its direct descendents.
In this case I looked at the HASH GROUP BY and TABLE ACCESS and got a difference of about 283 seconds. In fact I should have taken more notice of the other lines in the plan - comparing the HASH GROUP BY with the NESTED LOOP for a difference of about 16 seconds and assuming that the time in the TABLE ACCESS line was not to be trusted. (See http://jonathanlewis.wordpress.com/2007/04/26/heisenberg/ for a couple of comments on the timing issue).
So the grouping is responsible for relatively little of the excess time - most of the time goes into the nested loop.
I shall be using the Hints as advised, when we say we
have to "rewrite the query"
given the current context excluding the HINTS, what
exactly should I be
considering in terms of query rewrite, what
additional intelligence I can add to the
query in question so that CBO produces a different
plan.
The main consideration is what the query is supposed to report. Compare this with the way the optimizer is running the query and see if it makes sense.
When are talking about high intermediate rows
processing are we referring to this
section of the plan?;
4013304 TABLE ACCESS BY INDEX ROWID CI_FT
(cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785 NESTED LOOPS (cr=49295470 pr=8987
pw=0 time=407554071 us)
13704480 NESTED LOOPS (cr=21818135 pr=7655
pw=0 time=287797921 us)
2782119 NESTED LOOPS OUTER (cr=3915432
pr=2950 pw=0 time=38953485 us)
2777066 TABLE ACCESS BY INDEX ROWID
CI_PER_CHAR (cr=1369669 pr=239 pw=0 time=23084761
us)
2777066 INDEX RANGE SCAN XM168P0 (cr=596156
pr=53 pw=0 time=7394319 us)(object id 98719)
13704480 TABLE ACCESS BY INDEX ROWID CI_SA
(cr=17902703 pr=4705 pw=0 time=163320548 us)
13704480 INDEX RANGE SCAN XM199S1
(cr=5688247 pr=104 pw=0 time=51063061 us)(object id
98973)
4013304 INDEX RANGE SCAN CM112S1 (cr=27477335
pr=1332 pw=0 time=124063022 us)(object id 116797)
Correct - one of the nested loops returns 2.78M rows - but as you run the next join you end up collecting 13.7M entires from the next index and table. That step is responsible for quite a lot of your work and time (as is the following step where you USE the 13.7M rows to probe the next index/table combination). If the optimizer had not grown the data set by merging the P view earlier on, the data sizes would be significantly smaller at that point.
Your inline view looks as if it is trying to turn rows into columns (the max(decode()) trick) - which is why I think it might be a good idea to stop Oracle from merging the view. So, as I suggested, look at the query withouth that bit of complexity and work out a sensible way to walk through the tables - bearing in mind the statistics below and the available indexes, and the amount of data your predicates identify at each stage.
Moreover tables have been analyzed:
CI_ACCT 243068
CI_ACCT_CHAR 222320
CI_ACCT_PER 242971
CI_FT 794510
CI_PER 13227
CI_PER_CHAR 42555
CI_PER_PHONE 18488
CI_SA 1082301
Parameters:
optimizer_features_enable string 10.2.0.2
optimizer_index_caching integer 100
optimizer_index_cost_adj integer 1
Unless you've been given strict instructions by a 3rd-part supplier, those settings for the optimizer_index_caching and optimizer_index_cost_adj are particularly bad - especially in 10g. With those settings, the optimizer is quite likely to choose stupid plans with excessive use of indexes - and pick the wrong index while doing it.
It's not appropriate to fiddle with system parameters to address one query - but at some stage you need to rethink your entire set of parameter settings to do things the 10g way. See this note from the Optimizer Group: http://www.oracle.com/technology/products/bi/db/10g/pdf/twp_bidw_optimizer_10gr2_0208.pdf
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance,
it is the illusion of knowledge." Stephen Hawking. -
Oracle direct path read IO size
Hello!
I am confused a little with IO size. I am running 11.2.0.3 on Oracle Linux x64 6.2. Block_size=8K, MULTIBOCK_READ_COUNT=128
Database is Single Instance and is using ASM grid. ASM AU =1M
As a test I am running a simple query against large table with 1.5Bln rows.
select /*+ PARALLEL (STOCK_DAY 10) */ count(*) from stock_day where cstast='NA'
STAT #140582923121480 id=1 cnt=0 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=0 pr=0 pw=0 time=0 us)'
STAT #140582923121480 id=2 cnt=0 pid=1 pos=1 obj=0 op='PX COORDINATOR (cr=0 pr=0 pw=0 time=0 us)'
STAT #140582923121480 id=3 cnt=0 pid=2 pos=1 obj=0 op='PX SEND QC (RANDOM) :TQ10000 (cr=0 pr=0 pw=0 time=0 us)'
STAT #140582923121480 id=4 cnt=0 pid=3 pos=1 obj=0 op='SORT AGGREGATE (cr=0 pr=0 pw=0 time=27 us)'
STAT #140582923121480 id=5 cnt=2301843 pid=4 pos=1 obj=0 op='PX PARTITION LIST ALL PARTITION: 1 762 (cr=68020 pr=68393 pw=0 time=29346414 us cost=303766 size=669864369 card=223288123)'
STAT #140582923121480 id=6 cnt=2301843 pid=5 pos=1 obj=1464816 op='TABLE ACCESS FULL STOCK_DAY PARTITION: 1 762 (cr=68020 pr=68393 pw=0 time=24376609 us cost=303766 size=669864369 card=223288123)'
when I am trying to measure disk io statistics with iostat it shows that Oracle is issuing a 32K direct path read requests to ASM LUNs. Why? Why not 1M?
Thank you in advance!
Regards,
Kirill
Edited by: Kirill.Boyko on Jan 31, 2013 12:53 PMThis is a kind of histogram for one parallel session wait events
select session_state,event,p3,count(1) from V$active_session_history ash where ash.session_id=1904 and ash.session_serial#=24381
group by session_state,event,p3
order by session_state,event,p3
session
state event P3 COUNT
ON CPU 5 1
ON CPU 9 8
ON CPU 15 1
ON CPU 115 10
ON CPU 123 1
ON CPU 124 2
ON CPU 126 23
ON CPU 128 77
ON CPU 512 1
WAITING direct path read 5 2
WAITING direct path read 8 2
WAITING direct path read 9 7
WAITING direct path read 15 3
WAITING direct path read 67 1
WAITING direct path read 101 1
WAITING direct path read 115 18
WAITING direct path read 124 5
WAITING direct path read 126 35
WAITING direct path read 127 1
WAITING direct path read 128 97
in fact as you can see almost all direct path reads are done with io size > 900K. Total size of information read by process~160M
strace shows a lot of calls to read function. If we divide 160M/78000 reads we will get about 2K per request which is strange
% time seconds usecs/call calls errors syscall
98.61 0.212144 3 78356 read
0.93 0.002000 32 63 58 semtimedop
0.29 0.000624 208 3 munmap
0.12 0.000263 0 7407 gettimeofday
according to iostat we see that we are reading from each LUN with requests of 32K
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
xvda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdb 4.00 0.00 2946.00 1.00 92.01 0.00 63.94 90.60 30.93 0.33 96.00
xvde 1.00 0.00 2466.00 0.00 77.00 0.00 63.95 49.84 20.64 0.33 80.90
xvdf 5.00 0.00 2694.00 1.00 84.15 0.01 63.95 69.68 25.37 0.32 87.20
xvdg 2.00 0.00 2798.00 0.00 87.41 0.00 63.98 91.95 33.81 0.35 97.40
xvdj 3.00 0.00 2676.00 1.00 83.45 0.03 63.87 38.83 14.72 0.31 82.10
xvdk 4.00 0.00 2951.00 0.00 92.14 0.00 63.95 100.21 32.42 0.31 91.00
xvdl 3.00 0.00 2735.00 1.00 85.45 0.03 63.98 56.04 21.14 0.32 86.50
Why linux is splitting Oracle requests and how to avoid that?
Regards,
Kirill -
Huge long time direct path read temp, but pga size is enough, one block p3
Hi Gurus,
Can you please kindly provide some points on my below questions. thanks
my env
select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
OS: Linux 4 2.6.39-100.5.1.el5uek
session operation: update a partition which have 4 partitions and total 16G
session trace info:
the session keep at active status and waiting for below wait event for more than 70 hours, and os iostats and cpu are almost idle on most time.
WAIT #8: nam='direct path read temp' ela= 7615 file number=202 first dba=105072 block cnt=1 obj#=104719 tim=1344850223569499
WAIT #8: nam='direct path read temp' ela= 5989 file number=202 first dba=85264 block cnt=1 obj#=104719 tim=1344850392833257
WAIT #8: nam='direct path read temp' ela= 319 file number=202 first dba=85248 block cnt=1 obj#=104719 tim=1344850399563184
WAIT #8: nam='direct path read temp' ela= 358 file number=202 first dba=85232 block cnt=1 obj#=104719 tim=1344850406016899
WAIT #8: nam='direct path read temp' ela= 349 file number=202 first dba=85216 block cnt=1 obj#=104719 tim=1344850413023792
WAIT #8: nam='direct path read temp' ela= 7975 file number=202 first dba=85200 block cnt=1 obj#=104719 tim=1344850419495645
WAIT #8: nam='direct path read temp' ela= 331 file number=202 first dba=85184 block cnt=1 obj#=104719 tim=1344850426233450
WAIT #8: nam='direct path read temp' ela= 2641 file number=202 first dba=82880 block cnt=1 obj#=104719 tim=1344850432699800
pgastat:
NAME VALUE/1024/1024 UNIT
aggregate PGA target parameter 18432 bytes
aggregate PGA auto target 16523.1475 bytes
global memory bound 1024 bytes
total PGA inuse 75.7246094 bytes
total PGA allocated 162.411133 bytes
maximum PGA allocated 514.130859 bytes
total freeable PGA memory 64.625 bytes
PGA memory freed back to OS 40425.1875 bytes
total PGA used for auto workareas 2.75195313 bytes
maximum PGA used for auto workareas 270.407227 bytes
total PGA used for manual workareas 0 bytes
NAME VALUE/1024/1024 UNIT
maximum PGA used for manual workareas 24.5429688 bytes
bytes processed 110558.951 bytes
extra bytes read/written 15021.2559 bytes
Most operation in PGA via query on V$SQL_WORKAREA_ACTIVE
IDX maintainenance (sort)
My questions:
1. why 'direct path read temp' just read one block every time, my understanding is this event can read one block and multiple blocks at one read call, why it keep read one block in my session?
2. my pga size is big enough, why this operation can not be treated with in PGA memory, instead of read block from disk into temp tablespace?
Thanks for you inputs.
Roy951241 wrote:
since the session(which was from hard code application) is completed.First of all, you showed wait events from sql trace in the first post. Is the tracing was disabled in the latest execution?
>
I just generated the AWR for that period, as get long elapsed time SQL as following
Elapsed Time (s) Executions Elapsed Time per Exec (s) %Total %CPU %IO SQL Id
3,075.35 0 85.10 91.03 8.68 duhz2wtduz709
524.11 1 524.11 14.50 99.29 0.30 3cpa9fxny9j35
so I get execution plan as below for these two SQL,
select * from table(dbms_xplan.display_awr('&v_sql_id')); duhz2wtduz709
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | UPDATE STATEMENT | | | | 4 (100)| |
| 1 | UPDATE | WORK_PAY_LINE | | | | |
| 2 | INDEX RANGE SCAN| WORK_PAY_LINE | 1 | 37 | 3 (0)| 00:00:01 |
Note
- automatic DOP: Computed Degree of Parallelism is 1 because of parallel thresholdI am not sure the why elapsed time in AWR is different with time in execution plan. Column "Time" in an execution plan is estimated time. In this execution plan Oracle expects to get 1 row, estimated time is 1 sec.
So, you need to check why estimated cardinality is such low, check statistics on the table WORK_PAY_LINE.
You update 10Gb from 16Gb table via Index Range Scan, it looks inefficient here by two reasons:
1. when a table updated via Index Range Scan optimized index maintenance is used. As a result some amount (significant in your case) of workareas is required. Required size depends on size and number of updated indexes and "global memory bound", 1Gb in your case.
2. if required table buffers will not be found in the cache it will be read from disk by single block reads. If you would use Full Table Scan then buffers for update most likely will be found in the cache because before it read by multiblock reads during Full Table Scan.
Figures from your AWR indicate, that only ~ 9% the session waited for I/O and 91% it worked and used CPU
Elapsed Time (s) Executions Elapsed Time per Exec (s) %Total %CPU %IO SQL Id
3,075.35 0 85.10 91.03 8.68 duhz2wtduz709 This amount of CPU time partially required for UPDATE 10Gb of data, partially for sorting during optimized index maintenance.
I would propose to use Table Full Scan here.
Also you can play around and create fake trigger on update, it will make impossible to use optimized index maintenance, usual index maintenance will be used. As a result you can check the same update with the same execution plan (with Index Range Scan) but without optimized index maintenance and "direct path .. temp" wait events.
Alexander Anokhin
http://alexanderanokhin.wordpress.com/ -
Direct Path Read waits are not showing in Elapsed time
Hi,
I'm having a question regarding interpretation of a SQL trace file. I'm on Oracle 11.2.0.1 HP/UX 64 bit.
Following is only the overall result of the trace (it is quite big).
My question is about the Direct Path Read waits which are totallizing 268s of wait but are not showing in the fetch elapsed time (49.58s) and are not showing anywhere in the trace except in the overall result.
I do not understand why it is not part of the Elapsed time...
For info, the trace is for the specific session that was performing all the required queries to display an online report. The database is accessed by the Java application using Hybernate.
The trace was obtained by the following SQL:
exec sys.dbms_monitor.serv_mod_act_trace_enable(service_name=>'SYS$USERS',waits=>true,binds=>true);Then I query the sessions to find the one created by the application.
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 36 0.43 0.51 0 5 0 0
Execute 62 0.01 0.01 0 0 0 0
Fetch 579 4.01 49.06 3027 153553 0 5516
total 677 4.45 49.58 3027 153558 0 5516
Misses in library cache during parse: 29
Misses in library cache during execute: 2
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 32754 0.00 0.03
SQL*Net message from client 32753 2.33 232.01
Disk file operations I/O 179 0.00 0.02
db file sequential read 2979 0.54 45.72
SQL*Net more data to client 133563 0.04 5.30
direct path read 34840 0.94 268.21
SQL*Net more data from client 1075 0.00 0.02
db file scattered read 6 0.03 0.11
asynch descriptor resize 52 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 25 0.00 0.02 0 0 0 0
Execute 58 0.05 0.04 0 0 0 0
Fetch 126 0.00 0.04 4 161 0 123
total 209 0.05 0.11 4 161 0 123
Misses in library cache during parse: 3
Misses in library cache during execute: 3
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
Disk file operations I/O 1 0.00 0.00
db file sequential read 4 0.01 0.03
asynch descriptor resize 1 0.00 0.00
37 user SQL statements in session.
57 internal SQL statements in session.
94 SQL statements in session.
Trace file: oxd1ta00_ora_16542.trc
Trace file compatibility: 11.1.0.7
Sort options: default
1 session in tracefile.
37 user SQL statements in trace file.
57 internal SQL statements in trace file.
94 SQL statements in trace file.
57 unique SQL statements in trace file.
241517 lines in trace file.
568 elapsed seconds in trace file.Thanks
ChristopheChristophe Lize wrote:
Closing this thread even if it's not answered...Sorry, I don't have time to test this myself now, but you shouldn't mark this thread as answered if it is not, because other people might find it and think they find an answer if they have a similar question.
I suggest you try the following to narrow down things:
1. Open the RAW trace file and check the cursor numbers of the "direct path reads" - check if you can find any references for those cursor numbers manually. The cursor numbers are those numbers behind the WAIT #<xx>, and you can check if you find any other entry unequal to WAIT #<xx> with the same #<xx>, for example EXEC #<xx> or FETCH #<xx>
A short primer on how to interpret the raw trace file can also be found in MOS document 39817.1
2. Run the RAW trace file through alternative free trace file analyzers like SQLDeveloper (yes it can process raw trace files), OraSRP or Christian Antognini's TVD$XTAT. If you have My Oracle Support access you can also try Oracle's own extended Trace Analyzer (TRCA / TRCANLZR). See MOS Note 224270.1
Check if these tools tell you more about your specific wait event and oddities with the trace file in general.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
Co-author of the "OakTable Expert Oracle Practices" book:
http://www.apress.com/book/view/1430226684
http://www.amazon.com/Expert-Oracle-Practices-Database-Administration/dp/1430226684 -
A lot of messages "direct path write temp" and "direct path read temp"
Hello, all
Please, understand me, what is going on in my system (DB: Oracle database 11.2.0.3, OS: Windows 2008 R2).
In AWR report (1 hour) I see next:
Foreground Wait Events
Avg
%Time Total Wait wait Waits % DB
Event Waits -outs Time (s) (ms) /txn time
direct path write temp 132,627 0 1,056 8 0.8 21.7
direct path read temp 308,969 0 565 2 2.0 11.6
log file sync 19,228 0 241 13 0.1 5.0
direct path write 17,698 0 135 8 0.1 2.8
db file sequential read 21,149 0 94 4 0.1 1.9
SQL*Net message from dblin 59 0 5 86 0.0 .1
Segments by Direct Physical Reads DB/Inst: SGRE/sgre Snaps: 1039-1040
-> Total Direct Physical Reads: 392,273
-> Captured Segments account for 94.7% of Total
Tablespace Subobject Obj. Direct
Owner Name Object Name Name Type Reads %Total
** MISSING TEMP ** TRANSIENT: 437734 MISSING ** UNDEF 38,290 9.76
DBSNMP TEMP MGMT_TEMPT_SQL TABLE 38,242 9.75
** MISSING TEMP ** TRANSIENT: 438784 MISSING ** UNDEF 37,790 9.63
** MISSING TEMP ** TRANSIENT: 437312 MISSING ** UNDEF 37,661 9.60
** MISSING TEMP ** TRANSIENT: 439257 MISSING ** UNDEF 37,477 9.55Some selects:
SELECT S.sid,
T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace, T.SEGTYPE
FROM v$sort_usage T, v$session S, v$sqlarea Q, dba_tablespaces TBS
WHERE T.session_addr = S.saddr
AND T.sqladdr = Q.address (+)
AND T.tablespace = TBS.tablespace_name
AND S.sid = 732
ORDER BY S.username, S.sid;
SID MB_USED TABLESPACE SEGTYPE
732 2 TEMP LOB_DATA
732 1 TEMP INDEX
732 1 TEMP DATA
732 1 TEMP INDEX
732 1 TEMP DATA
732 1 TEMP INDEX
732 1 TEMP DATA
732 1 TEMP INDEX
732 1 TEMP INDEX
732 1 TEMP DATA
732 1 TEMP INDEX
732 1 TEMP INDEX
732 1 TEMP DATA
732 1 TEMP INDEX
732 1 TEMP INDEX
732 1 TEMP DATA
732 1 TEMP INDEX
732 1 TEMP INDEX
732 1 TEMP DATA
732 1 TEMP INDEX
732 1 TEMP INDEX
732 1 TEMP DATA
732 1 TEMP INDEX
732 1 TEMP INDEX
732 1 TEMP DATA
732 1 TEMP INDEX
732 1 TEMP INDEX
732 1 TEMP DATA
732 1 TEMP INDEX
732 1 TEMP LOB_INDEX
select st.sid, sn.name, st.VALUE
from V$statname sn, v$sesstat st
where st.STATISTIC# = sn.STATISTIC#
and (sn.name like 'sorts%')
and st.sid in (select sid from v$session_wait where event like '%direct path write temp%')
order by st.sid
SID NAME VALUE
732 sorts (memory) 591408
732 sorts (rows) 102126
732 sorts (disk) 0Why I do not see any disk sorts? If TEMP is used for no sort operations, then for which operations?
How I can see that? How can I decrease direct path write temp without tuning SQL?
Additional information:
PGA_AGGREGATE_TARGET is set to big value - 6GB (3GB enough due to advisory recommendation)
Please, help.
Regards, user12103911.user12103911 wrote:
SELECT optimal_count, round(optimal_count*100/total, 2) optimal_perc,
onepass_count, round(onepass_count*100/total, 2) onepass_perc,
multipass_count, round(multipass_count*100/total, 2) multipass_perc
FROM
(SELECT decode(sum(total_executions), 0, 1, sum(total_executions)) total,
sum(OPTIMAL_EXECUTIONS) optimal_count,
sum(ONEPASS_EXECUTIONS) onepass_count,
sum(MULTIPASSES_EXECUTIONS) multipass_count
FROM v$sql_workarea_histogram);
OPTIMAL_COUNT OPTIMAL_PERC ONEPASS_COUNT ONEPASS_PERC MULTIPASS_COUNT MULTIPASS_PERC
13150685 100 0 0 0 0No n-pass executions.That's a pretty convincing display - given that your AWR manages to NAME an object that is in the TEMP tablespace, an obvious point to follow up is global temporary tables. If you have any declared as "on commit preserve" (duration = 'SYS$SESSION') then you could have code which does "insert /*+ append */ into gtt", and if you then query this in parallel (or - since you're on 11.2.0.3 - the data volume is large enough) Oracle could choose to do direct path writes to load the GTT and direct path reads to read it back.
Regards
Jonathan Lewis -
Hi All,
We are using 10.2.0.3 on sparc solaris 10 64bit OS.
I was wondering about two events in my environment which is taking some long time. Yes, we are doing huge amount of grouping, sorting and hash joins which spill data to temp.
Mostly, all time goes to "direct path read temp". I took trace and saw that it's just reading 1 block every time(p3) vs other reads like scattered or direct path write it read/write 32 blocks.
direct path read temp 241389 4.19 2511.08
direct path write 2 0.00 0.00So, is there any reason why direct path read temp would read only one block at time ? Can we set something that can make it read more blocks in one fetchThanks Greg for update i had done some testing and here are the results. Yes read are happening in multiblock. I think it has improved performance for sorting and other temp related things. But why timing are still same ?
1. Without setting any parameter. also MBRC set to 64 also partition table are on 32k blocksize tablespace.
call count cpu elapsed disk query current rows
Parse 1 0.03 0.03 1 1 0 0
Execute 2 2201.03 3684.17 2448608 81948 105405 10634379
Fetch 0 0.00 0.00 0 0 0 0
total 3 2201.06 3684.20 2448609 81949 105405 10634379
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Rows Row Source Operation
1 LOAD AS SELECT (cr=81948 pr=2448608 pw=2469926 time=1214528089 us)
10634379 FILTER (cr=77235 pr=2448586 pw=2371451 time=1182691751 us)
10651336 HASH JOIN OUTER (cr=77235 pr=2448586 pw=2371451 time=1183339026 us)
10651336 VIEW (cr=71659 pr=2340225 pw=2268656 time=1080320372 us)
10651336 FILTER (cr=71659 pr=2340225 pw=2268656 time=1069669023 us)
52582514 SORT GROUP BY (cr=71659 pr=2340225 pw=2268656 time=983648878 us)
58422208 HASH JOIN (cr=71659 pr=71569 pw=0 time=819068238 us)
10372 TABLE ACCESS FULL M_XXXXX (cr=105 pr=102 pw=0 time=889462 us)
5260925 PARTITION HASH ALL PARTITION: 1 16 (cr=71554 pr=71467 pw=0 time=184358781 us)
5260925 TABLE ACCESS FULL P_XXXXX PARTITION: 1 16 (cr=71554 pr=71467 pw=0 time=184537694 us)
3000000 TABLE ACCESS FULL Q_XXXXX (cr=5576 pr=5566 pw=0 time=6018262 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 38 0.04 0.38
control file sequential read 5 0.00 0.00
db file scattered read 2363 0.67 182.76
direct path write temp 91545 1.68 429.68
direct path read temp 158597 0.75 1397.00
direct path write 2 0.00 0.002.
alter session set "_smm_auto_max_io_size" = 248;
alter session set "_smm_auto_min_io_size" = 248;
call count cpu elapsed disk query current rows
Parse 1 0.03 0.02 1 1 0 0
Execute 2 2244.76 3611.03 2448548 81947 105368 10634379
Fetch 0 0.00 0.00 0 0 0 0
total 3 2244.79 3611.06 2448549 81948 105368 10634379
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Rows Row Source Operation
1 LOAD AS SELECT (cr=81947 pr=2448548 pw=2469866 time=1730139608 us)
10634379 FILTER (cr=77235 pr=2448527 pw=2371392 time=1695299871 us)
10651336 HASH JOIN OUTER (cr=77235 pr=2448527 pw=2371392 time=1695539943 us)
10651336 VIEW (cr=71659 pr=2340180 pw=2268611 time=1569342149 us)
10651336 FILTER (cr=71659 pr=2340180 pw=2268611 time=1558690801 us)
52582514 SORT GROUP BY (cr=71659 pr=2340180 pw=2268611 time=1494647490 us)
58422208 HASH JOIN (cr=71659 pr=71569 pw=0 time=818890193 us)
10372 TABLE ACCESS FULL M_XXXXX (cr=105 pr=102 pw=0 time=696215 us)
5260925 PARTITION HASH ALL PARTITION: 1 16 (cr=71554 pr=71467 pw=0 time=189631575 us)
5260925 TABLE ACCESS FULL P_XXXXX PARTITION: 1 16 (cr=71554 pr=71467 pw=0 time=184538085 us)
3000000 TABLE ACCESS FULL Q_XXXXX (cr=5576 pr=5566 pw=0 time=6022439 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 37 0.04 0.29
control file sequential read 5 0.00 0.00
db file scattered read 2363 0.68 185.38
direct path write temp 97827 1.65 414.77
direct path read temp 209832 0.73 1315.50
direct path write 2 0.00 0.00Is this may be I/O issue. -
Select count(*) from table in oracle 11g with direct path read takes time
select count(*) from table takes long time, even more than couple of hours..
direct path read is the wait event which is almost is at 99%..
can u someone provide some info on this.. on solution.. thankxknowledgespring wrote:
table has millions of records... 130 millions..
select count(*) from BIG_SIZE_TABLE; --- executed in sql plus command prompt.
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 SORT (AGGREGATE)
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'BIG_SIZE_TABLE' (TABLE)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
enq: KO - fast object checkpoint 1 0.01 0.01
Disk file operations I/O 18 0.00 0.00
direct path read 58921 0.34 418.54direct path read time waited is : 58921 total time waited: 418.54
That 418 seconds - not the hours you reported earlier. Is it possible that your connection to the database broke ?
On a typical system, by the way, you can usually turn one direct read for tablescan into 1MB, so your scan seems to have covered about 59 GB, which seems to be in the right sort of ballpark for 130M rows.
we have another query and when we test the query execution using v$sql, is_bind_sensitive =N, how to make is_bind_sensitive=Y all the time.. There is a hint /*+ bind_aware */ - I'd have to check whether or not it's documented at present. It might help.
I would be interested in hearing why you think the hint should be bind sensitive when the optimizer doesn't.
Regards
Jonathan Lewis -
WAIT = 'direct path read temp' in session
Hi;
select * from v$version
Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
In our development system, a query "insert into X" using a couple of session global temporary tables, was running under 5 minuts, is now taking 40 minuts!
Sql Developer Sessions shows a wait: "direct path read temp"
Any hints on that might cause this, and possible solutions?
Trace file of the session looks like this:
*** 2013-03-18 15:56:22.871
WAIT #20: nam='direct path read temp' ela= 106 file number=201 first dba=46685 block cnt=31 obj#=61321 tim=1363614982871399
*** 2013-03-18 15:56:25.354
WAIT #20: nam='direct path read temp' ela= 90 file number=201 first dba=46336 block cnt=31 obj#=61321 tim=1363614985354148
*** 2013-03-18 15:56:28.098
WAIT #20: nam='direct path read temp' ela= 86 file number=201 first dba=46367 block cnt=31 obj#=61321 tim=1363614988098575
*** 2013-03-18 15:56:32.302
WAIT #20: nam='direct path read temp' ela= 112 file number=201 first dba=69438 block cnt=31 obj#=61321 tim=1363614992302296
WAIT #20: nam='direct path read temp' ela= 93 file number=201 first dba=69469 block cnt=31 obj#=61321 tim=1363614992302484
WAIT #20: nam='direct path read temp' ela= 95 file number=201 first dba=68030 block cnt=31 obj#=61321 tim=1363614992302888
WAIT #20: nam='direct path read temp' ela= 93 file number=201 first dba=66719 block cnt=31 obj#=61321 tim=1363614992303265
WAIT #20: nam='direct path read temp' ela= 107 file number=201 first dba=65726 block cnt=31 obj#=61321 tim=1363614992303657
WAIT #20: nam='direct path read temp' ela= 94 file number=201 first dba=64702 block cnt=31 obj#=61321 tim=1363614992304037
WAIT #20: nam='direct path read temp' ela= 97 file number=201 first dba=63709 block cnt=31 obj#=61321 tim=1363614992304421
WAIT #20: nam='direct path read temp' ela= 94 file number=201 first dba=62623 block cnt=31 obj#=61321 tim=1363614992304820
WAIT #20: nam='direct path read temp' ela= 111 file number=201 first dba=61471 block cnt=31 obj#=61321 tim=1363614992305227
WAIT #20: nam='direct path read temp' ela= 121 file number=201 first dba=60606 block cnt=31 obj#=61321 tim=1363614992305764
WAIT #20: nam='direct path read temp' ela= 100 file number=201 first dba=59392 block cnt=31 obj#=61321 tim=1363614992306175
WAIT #20: nam='direct path read temp' ela= 101 file number=201 first dba=58589 block cnt=31 obj#=61321 tim=1363614992306579
WAIT #20: nam='direct path read temp' ela= 98 file number=201 first dba=57503 block cnt=31 obj#=61321 tim=1363614992306965
WAIT #20: nam='direct path read temp' ela= 93 file number=201 first dba=56510 block cnt=31 obj#=61321 tim=1363614992307342
WAIT #20: nam='direct path read temp' ela= 94 file number=201 first dba=55296 block cnt=31 obj#=61321 tim=1363614992307742
WAIT #20: nam='direct path read temp' ela= 96 file number=201 first dba=54272 block cnt=31 obj#=61321 tim=1363614992308149
WAIT #20: nam='direct path read temp' ela= 131 file number=201 first dba=53407 block cnt=31 obj#=61321 tim=1363614992308651
WAIT #20: nam='direct path read temp' ela= 108 file number=201 first dba=52480 block cnt=31 obj#=61321 tim=1363614992309129
WAIT #20: nam='direct path read temp' ela= 99 file number=201 first dba=52511 block cnt=31 obj#=61321 tim=1363614992309273Tkprof output... notice the big values for direct path write temp and direct path read temp values!
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
callcount cpu elapsed disk query current rows
Parse 2 0.17 0.18 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 4 206.24 207.66 18960 755 21 8
total 8 206.42 207.84 18960 755 21 8
Misses in library cache during parse: 2
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
SQL*Net message to client 5 0.00 0.00
SQL*Net message from client 5 11.01 19.27
db file sequential read 6 0.00 0.00
Disk file operations I/O 15 0.00 0.00
asynch descriptor resize 84 0.00 0.00
direct path write temp 1264 0.19 1.25
direct path read temp 1264 0.00 0.04
control file sequential read 42 0.00 0.00
db file single write 3 0.00 0.00
control file parallel write 9 0.00 0.00
rdbms ipc reply 2 0.00 0.00
local write wait 12 0.00 0.00
log file sync 2 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 85 0.04 0.04 0 0 0 0
Execute 899 0.18 0.24 22 47 7 4
Fetch 1393 0.04 0.69 204 3200 0 7002
total 2377 0.28 0.98 226 3247 7 7006
Misses in library cache during parse: 55
Misses in library cache during execute: 51
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
db file sequential read 206 0.03 0.65
latch: shared pool 4 0.00 0.00
Disk file operations I/O 2 0.00 0.00
db file scattered read 3 0.03 0.04
5 user SQL statements in session.
896 internal SQL statements in session.
901 SQL statements in session.
Trace file: SXDB_ora_25080.trc
Trace file compatibility: 11.1.0.7
Sort options: default
1 session in tracefile.
5 user SQL statements in trace file.
896 internal SQL statements in trace file.
901 SQL statements in trace file.
41 unique SQL statements in trace file.
21517 lines in trace file.
217 elapsed seconds in trace file.
Edited by: PauloSMO on 19/Mar/2013 11:36 -
Direct Path Reads instead of Sequential Reads for index range scan
Database is 11.2. I have two development schemas, with the same table loaded in each schema - a 5 million row table. The execution path for the sql statement is the same against both tables; it's doing an index range scan.
But it would appear Oracle performs a direct path read against one schema, and performs sequential reads against the other schema. I don't understand why I'm seeing different behavior when the execution plan is the same. Any ideas? These are two different schemas in the same database.There is not enough information.So you even these tables located same database and you gathered statistics it is not mean both run time wait event statistics must be same.Really they are different tables.If both query use INDEX RANGE SCAN the it is not mean these plans are same.What about table and their index statistics? are they same? for example num_row or num_blocks of both tables are same? also about indexes.In additionally if you want to get exact reason you can enable sql trace(using dbms_monitor or setting sql_trace parameter to true according session) and need analyze result trace file using tkprof utility.In additionally in 11g here when query execution time oracle automatically choose direct read path(serial) based on size of tables and size of buffer cache(also here is available some hidden parameter to controlling this behavior).
-
Hi everyone,
I am experiencing High Direct path reads and every time i run the query I see there is no decrease in physical reads.
I have come across in the docs that this could be if the blocks are directly read into PGA instead of SGA, what will be the cases for this to be true and how can i overcome the disk reads.
Please advice.
Thanks in advance for your help.user8710159 wrote:
Hi everyone,
I am experiencing High Direct path reads and every time i run the query I see there is no decrease in physical reads.
I have come across in the docs that this could be if the blocks are directly read into PGA instead of SGA, what will be the cases for this to be true and how can i overcome the disk reads.
Please advice.
Thanks in advance for your help.I would ask why do you want to overcome the disk reads.
And you may want to share your query as well as details which told you it is doing direct path reads every time. -
Hi All,
DB version is 10.2.0.4
An insert statement is running for almost 14 hours now. The wait event shows direct path read temp
SID EVENT WAIT_TIME SECONDS_IN_WAIT P1 P2
1264 direct path read temp -1 0 524 64626Read about this event, which says it might happen due to Parallel full table scan not using the index. But that is not happening here..
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | INSERT STATEMENT | | 1 | 512 | 941 (1)| 00:00:12 |
| 1 | COUNT | | | | | |
|* 2 | FILTER | | | | | |
| 3 | NESTED LOOPS | | 1 | 512 | 941 (1)| 00:00:12 |
| 4 | NESTED LOOPS | | 1 | 506 | 940 (1)| 00:00:12 |
| 5 | NESTED LOOPS | | 1 | 493 | 938 (1)| 00:00:12 |
| 6 | NESTED LOOPS | | 1 | 478 | 937 (1)| 00:00:12 |
| 7 | NESTED LOOPS | | 1 | 439 | 936 (1)| 00:00:12 |
| 8 | NESTED LOOPS | | 1 | 420 | 934 (1)| 00:00:12 |
| 9 | NESTED LOOPS | | 1 | 382 | 932 (1)| 00:00:12 |
| 10 | NESTED LOOPS | | 1 | 377 | 931 (1)| 00:00:12 |
| 11 | NESTED LOOPS | | 1 | 295 | 929 (1)| 00:00:12 |
| 12 | NESTED LOOPS | | 1 | 280 | 927 (1)| 00:00:12 |
| 13 | NESTED LOOPS | | 1 | 273 | 927 (1)| 00:00:12 |
| 14 | NESTED LOOPS | | 1 | 247 | 925 (1)| 00:00:12 |
| 15 | NESTED LOOPS | | 1 | 239 | 924 (1)| 00:00:12 |
| 16 | NESTED LOOPS | | 1 | 212 | 922 (1)| 00:00:12 |
| 17 | NESTED LOOPS | | 1 | 205 | 921 (1)| 00:00:12 |
| 18 | NESTED LOOPS | | 1 | 184 | 156 (1)| 00:00:02 |
| 19 | NESTED LOOPS | | 1 | 109 | 154 (1)| 00:00:02 |
| 20 | NESTED LOOPS | | 1 | 93 | 153 (1)| 00:00:02 |
|* 21 | HASH JOIN | | 4 | 284 | 145 (1)| 00:00:02 |
|* 22 | TABLE ACCESS BY INDEX ROWID | GL_JE_LINES | 65 | 2730 | 130 (0)| 00:00:02 |
| 23 | NESTED LOOPS | | 75 | 4500 | 140 (0)| 00:00:02 |
| 24 | MERGE JOIN CARTESIAN | | 1 | 18 | 10 (0)| 00:00:01 |
| 25 | TABLE ACCESS FULL | FND_PRODUCT_GROUPS | 1 | 2 | 2 (0)| 00:00:01 |
| 26 | BUFFER SORT | | 1 | 16 | 8 (0)| 00:00:01 |
|* 27 | TABLE ACCESS BY INDEX ROWID| GL_CODE_COMBINATIONS | 1 | 16 | 8 (0)| 00:00:01 |
|* 28 | INDEX RANGE SCAN | JSW_GL_CODE_COMB_SEG_IDX | 10 | | 2 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN | GL_JE_LINES_N1 | 933 | | 6 (0)| 00:00:01 |
|* 30 | TABLE ACCESS FULL | GL_PERIODS | 5 | 55 | 4 (0)| 00:00:01 |
|* 31 | TABLE ACCESS BY INDEX ROWID | GL_JE_HEADERS | 1 | 22 | 2 (0)| 00:00:01 |
|* 32 | INDEX UNIQUE SCAN | GL_JE_HEADERS_U1 | 1 | | 1 (0)| 00:00:01 |
| 33 | TABLE ACCESS BY INDEX ROWID | GL_CODE_COMBINATIONS | 1 | 16 | 1 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | GL_CODE_COMBINATIONS_U1 | 1 | | 0 (0)| 00:00:01 |
|* 35 | TABLE ACCESS BY INDEX ROWID | GL_JE_BATCHES | 1 | 75 | 2 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | GL_JE_BATCHES_U1 | 1 | | 1 (0)| 00:00:01 |
|* 37 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_ACCOUNTS | 1 | 21 | 765 (0)| 00:00:10 |
|* 38 | INDEX RANGE SCAN | MTL_TRANSACTION_ACCOUNTS_N3 | 4021 | | 28 (0)| 00:00:01 |
|* 39 | TABLE ACCESS BY INDEX ROWID | HR_ALL_ORGANIZATION_UNITS | 1 | 7 | 1 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | HR_ORGANIZATION_UNITS_PK | 1 | | 0 (0)| 00:00:01 |
|* 41 | TABLE ACCESS BY INDEX ROWID | HR_ORGANIZATION_INFORMATION | 1 | 27 | 2 (0)| 00:00:01 |
|* 42 | INDEX RANGE SCAN | HR_ORGANIZATION_INFORMATIO_FK2 | 1 | | 1 (0)| 00:00:01 |
| 43 | TABLE ACCESS BY INDEX ROWID | MTL_PARAMETERS | 1 | 8 | 1 (0)| 00:00:01 |
|* 44 | INDEX UNIQUE SCAN | MTL_PARAMETERS_U1 | 1 | | 0 (0)| 00:00:01 |
|* 45 | TABLE ACCESS BY INDEX ROWID | HR_ORGANIZATION_INFORMATION | 1 | 26 | 2 (0)| 00:00:01 |
|* 46 | INDEX RANGE SCAN | HR_ORGANIZATION_INFORMATIO_FK2 | 1 | | 1 (0)| 00:00:01 |
|* 47 | INDEX UNIQUE SCAN | HR_ALL_ORGANIZATION_UNTS_TL_PK | 1 | 7 | 0 (0)| 00:00:01 |
|* 48 | TABLE ACCESS BY INDEX ROWID | MTL_MATERIAL_TRANSACTIONS | 1 | 15 | 2 (0)| 00:00:01 |
|* 49 | INDEX UNIQUE SCAN | MTL_MATERIAL_TRANSACTIONS_U1 | 1 | | 1 (0)| 00:00:01 |
| 50 | TABLE ACCESS BY INDEX ROWID | MTL_SYSTEM_ITEMS_B | 1 | 82 | 2 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | MTL_SYSTEM_ITEMS_B_U1 | 1 | | 1 (0)| 00:00:01 |
|* 52 | INDEX FULL SCAN | GL_SETS_OF_BOOKS_U2 | 1 | 5 | 1 (0)| 00:00:01 |
|* 53 | TABLE ACCESS BY INDEX ROWID | RCV_TRANSACTIONS | 1 | 38 | 2 (0)| 00:00:01 |
|* 54 | INDEX UNIQUE SCAN | RCV_TRANSACTIONS_U1 | 1 | | 1 (0)| 00:00:01 |
|* 55 | TABLE ACCESS BY INDEX ROWID | PO_HEADERS_ALL | 1 | 19 | 2 (0)| 00:00:01 |
|* 56 | INDEX UNIQUE SCAN | PO_HEADERS_U1 | 1 | | 1 (0)| 00:00:01 |
| 57 | TABLE ACCESS BY INDEX ROWID | PO_VENDORS | 1 | 39 | 1 (0)| 00:00:01 |
|* 58 | INDEX UNIQUE SCAN | PO_VENDORS_U1 | 1 | | 0 (0)| 00:00:01 |
| 59 | TABLE ACCESS BY INDEX ROWID | PO_VENDOR_SITES_ALL | 1 | 15 | 1 (0)| 00:00:01 |
|* 60 | INDEX UNIQUE SCAN | PO_VENDOR_SITES_U1 | 1 | | 0 (0)| 00:00:01 |
| 61 | TABLE ACCESS BY INDEX ROWID | RCV_SHIPMENT_HEADERS | 1 | 13 | 2 (0)| 00:00:01 |
|* 62 | INDEX UNIQUE SCAN | RCV_SHIPMENT_HEADERS_U1 | 1 | | 1 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | RCV_SHIPMENT_LINES_U1 | 1 | 6 | 1 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------------------------------The PGA size is 5gb. What is the cause of this wait event?
baskar.lHi,
How do i resolve this..?
Read from the document Optimizer Selects the Merge Join Cartesian Despite the Hints (Doc ID 457058.1)
| 24 | MERGE JOIN CARTESIAN | | 1 | 18 | 10 (0)| 00:00:01 |
| 25 | TABLE ACCESS FULL | FND_PRODUCT_GROUPS | 1 | 2 | 2 (0)| 00:00:01 |
| 26 | BUFFER SORT | | 1 | 16 | 8 (0)| 00:00:01 |
|* 27 | TABLE ACCESS BY INDEX ROWID| GL_CODE_COMBINATIONS | 1 | 16 | 8 (0)| 00:00:01 |
|* 28 | INDEX RANGE SCAN | JSW_GL_CODE_COMB_SEG_IDX | 10 | | 2 (0)| 00:00:01 |Have set
SQL> alter session set "_optimizer_mjc_enabled"=false ;
|* 21 | HASH JOIN | | 4 | 284 | 139 (1)| 00:00:02 |
|* 22 | TABLE ACCESS BY INDEX ROWID | GL_JE_LINES | 65 | 2730 | 124 (0)| 00:00:02 |
| 23 | NESTED LOOPS | | 75 | 4500 | 134 (0)| 00:00:02 |
| 24 | NESTED LOOPS | | 1 | 18 | 10 (0)| 00:00:01 |
| 25 | TABLE ACCESS FULL | FND_PRODUCT_GROUPS | 1 | 2 | 2 (0)| 00:00:01 |
|* 26 | TABLE ACCESS BY INDEX ROWID| GL_CODE_COMBINATIONS | 1 | 16 | 8 (0)| 00:00:01 |
|* 27 | INDEX RANGE SCAN | JSW_GL_CODE_COMB_SEG_IDX | 10 | | 2 (0)| 00:00:01 |thanks,
baskar.l
Maybe you are looking for
-
Having a hard time with Spry Image & CS5 on GoDaddy
Please excuse the newbie here. I hope I can give you all the info up front. I downloaded and installed the Spry Image Slideshow with Filmstrip widget just fine into DreamWeaver CS5. I then changed Donald Booth's page to show images from my hobby of 1
-
Extract image in PDF file - vba code in Excel
Hi All, I am applying a solution for my company. We have some Front offices which receive customers' requests in paper form. We have one Back Office which is receiving the customers' original paper requests from Front Office via courier mail. To impr
-
Disabling Acrobat as default PDF viewer.
I used Customizer to genrate MST but it does not works in qb mode. It works in UI mode . Please help as I want to deploy in my organization in qb mode. Thanks.
-
Wireless Router asking for different password when trying to change settings
I have an "old" wireless router Linksys BEFW11S4 V2. I am trying to change settings using the web interface. I can get in using the "admin" password but as soon as I try to change anything (such as SSID, security, etc) and click "Apply", it asks me f
-
Time Machine says backup disk is full
My Time Machine backup disk (FreeAgent GoFlex Drive: 1TB) says it's full. I thought Time Machine was supposed to delete old backups to make room for new backups on an on-going basis. I don't see a setting for it. I'm fairly new to Mac, so forgive