Direct Path Write

Is there a way to get Toplink to use direct path write (use the 'append' hint)?
Thanks,
Mike

p.s. we are using the BPEL database adapter...

Similar Messages

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

Wait events 'direct path write' and 'direct path read'

Hi,
We have a query which is taking more that 2 min. It's a 9.2.0.7 database. We took the trace/tkprof of the query,and identified that there are so manay 'direct path write' and 'direct path read' wait events in the trace file.
WAIT #3: nam='direct path write' ela= 5 p1=201 p2=70710 p3=15
WAIT #3: nam='direct path read' ela= 170 p1=201 p2=71719 p3=15
In the above, "p1=201" is a file_id, but we could not find any data file, temp file, control file with that id# 201.
Can you please let us know what's "p1=201" here, how to identify the file which is causing the issue.
Thanks
Sravan

What does:
show parameter db_filesreturn? My guess, is that it returns 200.
The direct file read and direct file write events are reads and writes to TEMP tablespace. In those wait events, the file# is reported as db_files+temp file id. So, 201 means temp file #1.
Now, as to your actual performance problem.
Without seeing the SQL and the corresponding execution plan, it's impossible to be sure. However, the most common causes of temp writes are sort operations and group by operations.
If you decide to post your SQL and execution plan, please be sure to make it readable by formatting it. Information on how to do so can be found here.
Hope that helps,
-Mark
Edited by: mbobak on May 1, 2011 1:50 AM

Oracle 10g direct path write too slow

Hi All,
We have Oracle 10g on a Solaris virtual server, VMWare ESXi being the host. Data files are on RAID1, internal storage on a HP DL585 with VMFS partition at ESXi level. Problem is that DB writes for a CREATE TABLE as SELECT... statement is way too slow. To create a table which is 0.5 GB, DB takes 9 minutes which amounts to 1 MB/s. When we check for FTP or file copy at Solaris level with same size file (0.5 GB), it flies through in less than a minute. This is Oracle 10.2.0.4, 8K data block, 2 vCPU assigned to the Solaris VM. Have checked with VMWare support for any known issues and also have SR open with Oracle for any param changes that can help speed up things. Any clues or pointers from you all will be of great help.
Thanks,
Nikhil

Here's the output from tkprof for waits
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
single-task message 1 0.17 0.17
SQL*Net message to dblink 150 0.00 0.00
SQL*Net message from dblink 150 0.04 0.32
SQL*Net message to client 1 0.00 0.00
direct path write temp 4003 1.16 804.93
direct path read temp 2563 0.14 35.86
SQL*Net more data from dblink 126967 0.17 11.81
SQL*Net message from client 1 17.73 17.73
Direct Path write temp has total waits of 804.93. Also, I am NOT looking to tune a particular SQL. Database is overall slow on VMware and I am looking for any gotchas for running Oracle 10g within a Solaris VM.
Thanks,
Nikhil

Direct path write temp wait problrm

Hi there,
(DB= 11.2.0, OS= OL 5)
I have a query which it takes approximately 20 seconds if I run it manually against the server via a tool like PL/SQL Developer and takes about 7 minutes if it runs via a reporting tool like BI Publisher. I dont have this problem with other queries. the query is against a huge table containing 800 million records. through monitoring EM the problem seems to be the wait event "DIRECT PATH WRITE TEMP". But when I execute it manually that will not be an issue. I'm sure the queries are the same in both environments. Application Server (where the BIP runs on it) access to DB server is through a LAN and my access is through a VPN over the net. By the way, the query has no order by clause. The memory_target_parameter is 20g and sort_area_size is 65536.
Please help me to understand why two behaviors of DB against a same query and why the wait event "DIRECT PATH WRITE TEMP" occurs and how I can resolve it.
THANKS
SMSK

Thanks Dom,
After posting this thread I also doubted about different Plans, Too. I noticed that the application runs the query via a web service but there is no web service call when I run it on my PL/SQL Developer client. I dont know if this is informational or not.
Another thing that surprised me is DATABASE LINK. when I run a query containing a reference to a DB-LINK provided table, COMMIT and ROLLBACK buttons of the PL/SQL Developer client menu bar will be enabled. this is not natural. I just run a SELECT statement which doesnt require COMMIT nor ROLLBACK. So I try to temporarily bring those DB-LINK tables using CTAS. Surprisingly performance of the application server becomes good and prepares the report result in just 4 seconds!
Therefore, it seems that subject of the problem I'm looking for should be change to:
Why commit or rollback will be enabled after executing a select statement over a DB-LINK table?
IS this occurrence affects query performance?
Does this leads to wait event "direct path write temp"?
Any helpful comment or link about db-link performance.
SMSK.

DIRECT PATH WRITE TEMP during SQL

Hi all,
recently I have been experiencing a very interesting question. We have 2 equal system therefore 2 databases. They have same hardware, the same memory and init configuration. On one of the system an SQL statement runs in 1 second, on the other system the statement hangs with:DIRECT PATH WRITE TEMP wait event. I came to the conclusion in a way that I traced the session:
*** 2013-08-08 18:09:05.131
*** SESSION ID:(90.36255) 2013-08-08 18:09:05.131
*** CLIENT ID:() 2013-08-08 18:09:05.131
*** SERVICE NAME:(SYS$USERS) 2013-08-08 18:09:05.131
*** MODULE NAME:(sqlplus@i87345 (TNS V1-V3)) 2013-08-08 18:09:05.131
*** ACTION NAME:() 2013-08-08 18:09:05.131
WAIT #140650920871104: nam='direct path write temp' ela= 2254 file number=201 first dba=1800095 block cnt=31 obj#=71542 tim=1375978145131322
*** 2013-08-08 18:09:25.905
WAIT #140650920871104: nam='direct path write temp' ela= 18683 file number=201 first dba=1746847 block cnt=31 obj#=71542 tim=1375978165905262
WAIT #140650920871104: nam='direct path write temp' ela= 26832 file number=201 first dba=1740253 block cnt=31 obj#=71542 tim=1375978165988243
and so on
just waiting and waiting, and then
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
significantly there is no difference in the amount of data between the 2 systems. Statistics have beeen collecting and are actual. Earlier the statement run properly, also within one second. Something has changed, but not to system configuration. Temp tablespace could be extended, but probably this is not the way (I think).
Any tip how we can continue?
thanks
Attila

Run both queries again, and pull the execution plans from memory using dbms_xplan.display_cursor() and the format 'peeked_binds' option.
Bear in mind that even if the data is the same, and stats were collected at the same instant on the two systems, a sample (rather than a compute) could result in slightly different statistics that end up giving different execution plans. This is more likely to happen if there are histograms on the critical columns.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Now on Twitter: @jloracle

Getting wait event "direct path write temp" during query execution

Hi All,
While executing one query in database, it is taking longer time and failing with error "ORA-01652: unable to extend temp segment by 1280 in tablespace PSTEMP".
I have increaesd the Temp tablespace size also till 96GB, Database size is 120GB.
I have upgraded the database from 10.2.0.3 to 11.2.0.3 version last month.
same query is running fine in other databases on same version.
It is giving me "Direct write temp path" wait event.
server load is also normal.
I have increased pga_aggregate_target upto 512MB but it has not solved my problem
Can you please help me out to solve this issue.

Hi Nicolay,
Please find below output from that query :
SQL>
SELECT DBMS_SQLTUNE.report_sql_monitor(
sql_id => '(*******',
type => 'TEXT',
report_level => 'ALL') AS report
FROM dual;SQL> 2 3 4 5
SQL Monitoring Report
SQL Text
SELECT ASGN.TRANSACTIONID ,ASGN.UPA_CLIENT_ID FROM PS_UPA_CM_PRE_ASGN ASGN ,PS_UPA_CLIENT_TBL CL ,PS_UPA_CM_ADMIN_WL WL ,PSXLATITEM XCT ,PSXLATITEM XCS ,PS_PWC_INDUSTR_TBL IND ,PS_PWC_SUBIND_TBL SCT ,PS_UPA_FIN_REG_TBL REG ,PS_UPA_CM_MKT_VW1 MKT WHERE ASGN.UPA_CLIENT_ID = CL.UPA_CLIENT_ID AND CL.UPA_CM_GRP_ID = ' ' AND ASGN.UPA_CM_ADMIN_ACT = 'RCD' AND ASGN.UPA_CM_CLT_ROLENBR = WL.UPA_CM_CLT_ROLENBR AND ASGN.UPA_CM_ROLENBR_SEQ = WL.UPA_CM_ROLENBR_SEQ AND WL.UPA_CM_WL_STATUS = 'A' AND
WL.UPA_CM_ADMIN_ACT = 'RCD' AND CL.EFFDT = ( SELECT MAX(CL1.EFFDT) FROM PS_UPA_CLIENT_TBL CL1 WHERE CL1.UPA_CLIENT_ID = CL.UPA_CLIENT_ID AND CL1.EFFDT <= SYSDATE) AND CL.EFF_STATUS = 'A' AND CL.UPA_MONTH_DAY <> ' ' AND CL.UPA_CLIENT_TYPE <> ' ' AND CL.UPA_CLIENT_SEGMENT <> ' ' AND CL.PWC_INDUSTRY <> ' ' AND CL.PWC_SUB_INDUSTRY <> ' ' AND CL.UPA_FIN_REGION <> ' ' AND CL.UPA_STRAT_MKT <> ' ' AND CL.UPA_CLT_PRIORITIZ <> ' ' /*Harieash - Aadded as part of PR support IR 43024 */ AND XCT.FIELDNAME =
'UPA_CLIENT_TYPE' AND XCT.FIELDVALUE = CL.UPA_CLIENT_TYPE AND XCT.EFFDT = ( SELECT MAX(XCT1.EFFDT) FROM PSXLATITEM XCT1 WHERE XCT1.FIELDNAME = XCT.FIELDNAME AND XCT1.FIELDVALUE = XCT.FIELDVALUE AND XCT1.EFFDT <= SYSDATE) AND XCT.EFF_STATUS = 'A' AND XCS.FIELDNAME = 'UPA_CLIENT_SEGMENT' AND XCS.FIELDVALUE = CL.UPA_CLIENT_SEGMENT AND XCS.EFFDT = ( SELECT MAX(XCS1.EFFDT) FROM PSXLATITEM XCS1 WHERE XCS1.FIELDNAME = XCS.FIELDNAME AND XCS1.FIELDVALUE = XCS.FIELDVALUE AND XCS1.EFFDT <= SYSDATE) AND
XCS.EFF_STATUS = 'A' AND IND.SETID = 'USA00' AND CL.PWC_INDUSTRY = IND.PWC_INDUSTRY AND IND.EFFDT = ( SELECT MAX(IND1.EFFDT) FROM PS_PWC_INDUSTR_TBL IND1 WHERE IND1.SETID = IND.SETID AND IND1.PWC_INDUSTRY = IND.PWC_INDUSTRY AND IND1.EFFDT <= SYSDATE) AND IND.EFF_STATUS = 'A' AND SCT.SETID = 'USA00' AND CL.PWC_SUB_INDUSTRY = SCT.PWC_SUB_INDUSTRY AND SCT.EFFDT = ( SELECT MAX(SCT1.EFFDT) FROM PS_PWC_SUBIND_TBL SCT1 WHERE SCT1.SETID = SCT.SETID AND SCT1.PWC_SUB_INDUSTRY = SCT.PWC_SUB_INDUSTRY AND
SCT1.EFFDT <= SYSDATE) AND SCT.EFF_STATUS = 'A' AND REG.SETID = 'USA00' AND CL.UPA_FIN_REGION = REG.UPA_FIN_REGION AND REG.EFFDT = ( SELECT MAX(REG1.EFFDT) FROM PS_UPA_FIN_REG_TBL REG1 WHERE REG1.SETID = 'USA00' AND REG1.UPA_FIN_REGION = REG.UPA_FIN_REGION AND REG1.EFFDT <= SYSDATE) AND REG.EFF_STATUS = 'A' AND CL.UPA_STRAT_MKT = MKT.UPA_STRAT_MKT
Global Information
Status : EXECUTING
Instance ID : 1
Session : *******
SQL ID : *******
SQL Execution ID : *********
Execution Started : 11/12/2012 04:31:25
First Refresh Time : 11/12/2012 04:31:33
Last Refresh Time : 11/12/2012 04:31:55
Duration : 31s
Module/Action : ***** (TNS V1-V3)/-
Service : SYS$USERS
Program : ******* (TNS V1-V3)
Global Stats
=========================================================
| Elapsed | Cpu | IO | Buffer | Write | Write |
| Time(s) | Time(s) | Waits(s) | Gets | Reqs | Bytes |
=========================================================
| 33 | 25 | 7.30 | 162 | 4755 | 557MB |
=========================================================
SQL Plan Monitoring Details (Plan Hash Value=2177602723)
========================================================================================================================================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Write | Write | Mem | Temp | Activity | Activity Detail |
| | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | | | (%) | (# samples) |
========================================================================================================================================================================================================
| 0 | SELECT STATEMENT | | | | | | 1 | | | | | | | |
| 1 | NESTED LOOPS | | | | | | 1 | | | | | | | |
| 2 | NESTED LOOPS | | 1 | 491 | | | 1 | | | | | | | |
| -> 3 | HASH JOIN | | 120 | 130 | 31 | +1 | 1 | 0 | 4011 | 470MB | 95M | 598M | 80.65 | Cpu (19) |
| | | | | | | | | | | | | | | direct path write temp (6) |
| -> 4 | MERGE JOIN CARTESIAN | | 120 | 61 | 23 | +8 | 1 | 13M | | | | | | |
| -> 5 | MERGE JOIN CARTESIAN | | 1 | 38 | 23 | +8 | 1 | 1870 | | | | | | |
| -> 6 | MERGE JOIN CARTESIAN | | 1 | 37 | 23 | +8 | 1 | 70 | | | | | | |
| -> 7 | MERGE JOIN CARTESIAN | | 1 | 35 | 23 | +8 | 1 | 12 | | | | | | |
| 8 | MERGE JOIN CARTESIAN | | 1 | 33 | 21 | +8 | 1 | 2 | | | | | | |
| 9 | MERGE JOIN CARTESIAN | | 1 | 31 | 1 | +8 | 1 | 1 | | | | | | |
| 10 | VIEW | PS_UPA_CM_MKT_VW1 | 1 | 29 | 1 | +8 | 1 | 1 | | | | | | |
| 11 | SORT UNIQUE | | 1 | 28 | 1 | +8 | 1 | 1 | | | | | | |
| 12 | TABLE ACCESS BY INDEX ROWID | PS_UPA_ST_MKT_TBL | 10 | 2 | 1 | +8 | 1 | 43 | | | | | | |
| 13 | INDEX SKIP SCAN | PS0UPA_ST_MKT_TBL | 10 | 1 | 1 | +8 | 1 | 43 | | | | | | |
| 14 | SORT AGGREGATE | | 1 | | 1 | +8 | 33 | 33 | | | | | | |
| 15 | INDEX SKIP SCAN | PS0UPA_ST_MKT_TBL | 2 | 1 | 1 | +8 | 33 | 50 | | | | | | |
| 16 | BUFFER SORT | | 1 | 31 | 1 | +8 | 1 | 1 | | | | | | |
| 17 | TABLE ACCESS BY INDEX ROWID | PSXLATITEM | 1 | 2 | 1 | +8 | 1 | 14 | | | | | | |
| 18 | INDEX RANGE SCAN | PS_PSXLATITEM | 1 | 1 | 1 | +8 | 1 | 14 | | | | | | |
| 19 | SORT AGGREGATE | | 1 | | 1 | +8 | 14 | 14 | | | | | | |
| 20 | INDEX RANGE SCAN | PS_PSXLATITEM | 1 | 1 | 1 | +8 | 14 | 14 | | | | | | |
| 21 | BUFFER SORT | | 1 | 31 | 21 | +8 | 1 | 2 | | | | | | |
| 22 | TABLE ACCESS BY INDEX ROWID | PSXLATITEM | 1 | 2 | 1 | +8 | 1 | 2 | | | | | | |
| 23 | INDEX RANGE SCAN | PS_PSXLATITEM | 1 | 1 | 1 | +8 | 1 | 2 | | | | | | |
| 24 | SORT AGGREGATE | | 1 | | 1 | +8 | 2 | 2 | | | | | | |
| 25 | INDEX RANGE SCAN | PS_PSXLATITEM | 1 | 1 | 1 | +8 | 2 | 2 | | | | | | |
| -> 26 | BUFFER SORT | | 3 | 33 | 23 | +8 | 2 | 12 | | | | | | |
| 27 | TABLE ACCESS BY INDEX ROWID | PS_PWC_INDUSTR_TBL | 3 | 2 | 1 | +8 | 1 | 10 | | | | | | |
| 28 | INDEX SKIP SCAN | PS0PWC_INDUSTR_TBL | 6 | 1 | 1 | +8 | 1 | 26 | | | | | | |
| 29 | SORT AGGREGATE | | 1 | | 1 | +8 | 26 | 26 | | | | | | |
| 30 | FIRST ROW | | 1 | 1 | 1 | +8 | 26 | 26 | | | | | | |
| -> 31 | INDEX RANGE SCAN (MIN/MAX) | PS_PWC_INDUSTR_TBL | 1 | 1 | 23 | +8 | 26 | 26 | | | | | | |
| -> 32 | BUFFER SORT | | 3 | 35 | 23 | +8 | 12 | 70 | | | | | | |
| 33 | TABLE ACCESS BY INDEX ROWID | PS_UPA_FIN_REG_TBL | 3 | 2 | 1 | +8 | 1 | 6 | | | | | | |
| 34 | INDEX SKIP SCAN | PS0UPA_FIN_REG_TBL | 6 | 1 | 1 | +8 | 1 | 12 | | | | | | |
| 35 | SORT AGGREGATE | | 1 | | 1 | +8 | 12 | 12 | | | | | | |
| 36 | FIRST ROW | | 1 | 1 | 1 | +8 | 12 | 12 | | | | | | |
| -> 37 | INDEX RANGE SCAN (MIN/MAX) | PS_UPA_FIN_REG_TBL | 1 | 1 | 23 | +8 | 12 | 12 | | | | | | |
| -> 38 | BUFFER SORT | | 14 | 36 | 23 | +8 | 70 | 1870 | | | | | | |
| 39 | INDEX RANGE SCAN | PSAPWC_SUBIND_TBL | 14 | 1 | 1 | +8 | 1 | 27 | | | | | | |
| 40 | SORT AGGREGATE | | 1 | | 1 | +8 | 184 | 184 | | | | | | |
| 41 | FIRST ROW | | 1 | 2 | 1 | +8 | 184 | 184 | | | | | | |
| -> 42 | INDEX RANGE SCAN (MIN/MAX) | PS_PWC_SUBIND_TBL | 1 | 2 | 23 | +8 | 184 | 184 | | | | | | |
| 43 | BUFFER SORT | | 794 | 60 | 29 | +2 | 1870 | 13M | | | 306K | | 19.35 | Cpu (6) |
| 44 | TABLE ACCESS FULL | PS_UPA_CM_ADMIN_WL | 794 | 23 | 1 | +8 | 1 | 7052 | | | | | | |
| 45 | TABLE ACCESS FULL | PS_UPA_CM_PRE_ASGN | 3536 | 69 | | | | | | | | | | |
| 46 | INDEX RANGE SCAN | PSDUPA_CLIENT_TBL | 1 | 2 | | | | | | | | | | |
| 47 | SORT AGGREGATE | | 1 | | | | | | | | | | | |
| 48 | FIRST ROW | | 1 | 3 | | | | | | | | | | |
| 49 | INDEX RANGE SCAN (MIN/MAX) | PS_UPA_CLIENT_TBL | 1 | 3 | | | | | | | | | | |
| 50 | TABLE ACCESS BY INDEX ROWID | PS_UPA_CLIENT_TBL | 1 | 3 | | | | | | | | | | |
========================================================================================================================================================================================================
SQL>
spool offSQL>

Query regarding direct path write

Hi All,
We have Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production running on Redhat 4.
We have performance issue with high disk utilization.
When seen statspack report, top event is always direct path write.
when checked about direct path write found that it is consequence of direct path inserts/high sort operations.
I checked v$sort_usage and identified query which is listed there most of time, but column segtype is HASH for that query.
So is there chance i can conclude that this is the query which is causing direct path writes as confusing thing is SEGTYPE is HASH.
Please let me know your comment about the same and also is there a way i can find sql statement which are writing to temp tablespace using direct path write.
Regards
Vinay

v$sql_workarea_active gives information about the active work areas in the system. It shows the operation type, sid, memory usage and temp tablespace usage. You can check this to see what session is using the temporary tablespace for work areas.

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.

Direct path temp write

Hi,
Oracle Version : 11.2.0.1(Standard Edition)
Operating System : RHEL-5
We are having one Procedure which is causing Direct Path Temp Write Even. How can we avoid that and it is taking lot of time for execution.
Please help me how solve my problem.
Thanks & Regards,
Poorna Prasad.S

SIDDABATHUNI wrote:
Hi,
Oracle Version : 11.2.0.1(Standard Edition)
Operating System : RHEL-5
We are having one Procedure which is causing Direct Path Temp Write Even. How can we avoid that and it is taking lot of time for execution.
Please help me how solve my problem.
Thanks & Regards,
Poorna Prasad.SRead Charles Hooper comments on this event from this post direct path write temp wait event on temp lob

Direct path read/write temp

Hi!
We are getting an high number of wait events:
- direct path read temp
- direct path write temp
What could be the problem and what actions to debug this situation?
Thanks a lot
A.

While i execute the above query, it shows the output like
OBJECT_NAME OBJECT_TYPE EVENT P1 P2 P3 TTL_WAIT_TIME
FIN2010 TABLE direct path read 35 549636 124 .2
FIN2010 TABLE direct path read 35 415236 124 .15
FIN2010 TABLE direct path read 35 703616 128 .08
FIN2010 TABLE direct path read 35 487569 111 .07
FIN2010 TABLE direct path read 35 472960 128 .07
FIN2010 TABLE direct path read 35 125696 128 .07
FIN2010 TABLE direct path read 35 303618 126 .06
FIN2010 TABLE direct path read 35 146560 128 .06
FIN2010 TABLE direct path read 35 373376 128 .06
FIN2010 TABLE direct path read 35 523776 128 .06
FIN2010 TABLE direct path read 35 467584 128 .06
FIN2010 TABLE direct path read 35 456068 124 .06
FIN2010 TABLE direct path read 35 434304 128 .05
FIN2010 TABLE direct path read 35 443648 128 .05
FIN2010 TABLE direct path read 35 467840 128 .04
FIN2010 TABLE direct path read 35 752640 128 .04
FIN2010 TABLE direct path read 35 266240 128 .04
FIN2010 TABLE direct path read 35 525696 128 .04
FIN2010 TABLE direct path read 35 499200 128 .04
FIN2010 TABLE direct path read 35 854656 128 .04
FIN2010 TABLE direct path read 35 439552 128 .04
FIN2010 TABLE direct path read 35 514048 128 .04
FIN2010 TABLE direct path read 35 750279 57 .04
FIN2010 TABLE direct path read 35 434816 128 .04
FIN2010 TABLE direct path read 35 418308 124 .04
FIN2010 TABLE direct path read 35 534912 128 .04
FIN2010 TABLE direct path read 35 401057 95 .03
FIN2010 TABLE direct path read 35 476800 128 .03
FIN2010 TABLE direct path read 35 188928 128 .03
FIN2010 TABLE direct path read 35 865920 128 .03
FIN2010 TABLE direct path read 35 103812 124 .03
FIN2010 TABLE direct path read 35 307586 126 .03
FIN2010 TABLE direct path read 35 539520 79 .03
FIN2010 TABLE direct path read 35 333696 128 .03
FIN_TEST TABLE direct path read 35 272944 8 .03
FIN2010 TABLE direct path read 35 644608 128 .03
FIN2010 TABLE direct path read 35 833152 128 .03
FIN2010 TABLE direct path read 35 709248 128 .03
FIN2010 TABLE direct path read 35 507904 128 .02
FIN2010 TABLE direct path read 35 540928 128 .02
FINTABLE TABLE direct path read 35 569216 128 .02
FIN2010 TABLE direct path read 35 311810 126 .02
FIN2010 TABLE direct path read 35 441600 110 .02
FIN2010 TABLE direct path read 35 555780 124 .02
FIN2010 TABLE direct path read 35 144384 128 .02
FIN2010 TABLE direct path read 35 384000 128 .02
FIN2010 TABLE direct path read 35 720000 128 .02
FIN2010 TABLE direct path read 35 133376 128 .02
FIN2010 TABLE direct path read 35 135680 128 .02
FIN2010 TABLE direct path read 35 553732 124 .02
FIN2010 TABLE direct path read 35 840960 128 .02
FIN2010 TABLE direct path read 35 547072 128 .02
FIN2010 TABLE direct path read 35 756864 128 .01
FIN2010 TABLE direct path read 35 165888 128 .01
FIN2010 TABLE direct path read 35 885120 128 .01
FIN2010 TABLE direct path read 35 538880 128 .01
FIN2010 TABLE direct path read 35 646656 128 .01
FIN2010 TABLE direct path read 35 377856 128 .01
FIN2010 TABLE direct path read 35 336384 128 .01
FIN2010 TABLE direct path read 35 380032 128 .01
FIN2010 TABLE direct path read 35 573440 128 .01
FIN2010 TABLE direct path read 35 660352 128 .01
FIN2010 TABLE direct path read 35 482688 128 .01
FIN2010 TABLE direct path read 35 553088 128 .01
FIN2010 TABLE direct path read 35 545408 128 .01
FIN2010 TABLE direct path read 35 145152 128 0
FIN2010 TABLE direct path read 35 886272 128 0
FIN2010 TABLE direct path read 35 695424 128 0
FIN2010 TABLE direct path read 35 671488 128 0
FIN2010 TABLE direct path read 35 393344 128 0
FIN2010 TABLE direct path read 35 756096 128 0
FIN2010 TABLE direct path read 35 681344 128 0
FIN2010 TABLE direct path read 35 657536 128 0
FIN2010 TABLE direct path read 35 151296 128 0
FIN2010 TABLE direct path read 35 112000 128 0
FIN2010 TABLE direct path read 35 637184 128 0
FIN2010 TABLE direct path read 35 146304 128 0
FIN2010 TABLE direct path read 35 105344 128 0
FIN2010 TABLE direct path read 35 358148 124 0
FIN2010 TABLE direct path read 35 137856 128 0
FIN2010 TABLE direct path read 35 713984 128 0
FIN2010 TABLE direct path read 35 704896 128 0
FIN2010 TABLE direct path read 35 687616 128 0
FIN2010 TABLE direct path read 35 702720 128 0
FIN2010 TABLE direct path read 35 673664 128 0
FIN2010 TABLE direct path read 35 142592 128 0
FIN2010 TABLE direct path read 35 394496 128 0
FIN2010 TABLE direct path read 35 403072 128 0
FIN2010 TABLE direct path read 35 639616 128 0
FIN2010 TABLE direct path read 35 710656 128 0
FIN2010 TABLE direct path read 35 131328 128 0
FIN2010 TABLE direct path read 35 161156 124 0
FIN2010 TABLE direct path read 35 107520 128 0
FIN2010 TABLE direct path read 35 157824 128 0
FIN2010 TABLE direct path read 35 98502 58 0
FIN2010 TABLE direct path read 35 695936 128 0
FIN2010 TABLE direct path read 35 709632 128 0
FIN2010 TABLE direct path read 35 689536 128 0
FIN2010 TABLE direct path read 35 126218 118 0
FIN2010 TABLE direct path read 35 647680 128 0
FIN2010 TABLE direct path read 35 842240 119 0
FIN2010 TABLE direct path read 35 497536 128 0
FIN2010 TABLE direct path read 35 264960 128 0
FIN2010 TABLE direct path read 35 704256 128 0
FIN2010 TABLE direct path read 35 714240 128 0
FIN2010 TABLE direct path read 35 641920 128 0
FIN2010 TABLE direct path read 35 837376 128 0
FIN2010 TABLE direct path read 35 646528 128 0
FIN2010 TABLE direct path read 35 700672 128 0
FIN2010 TABLE direct path read 35 642432 128 0
=======================================================================
While i check my awr report, it take large time for direct path write temp.
Anybody help me to find the root cause and how to tune the database.
Please help me..
While

Direct path read event

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 fetch

Thanks 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.

What is p1 for direct path read temp wait event in 11gr1

hi friends,
When i run this query in my database(11gr1) i get this
SELECT P1,P1TEXT FROM V$ACTIVE_SESSION_HISTORY WHERE event='direct path write temp' and sql_id='2sd3hryy2baav';
P1 P1TEXT
1260 file number
As per the documentation given on the link
http://docs.oracle.com/cd/B28359_01/server.111/b28320/waitevents002.htm#
when i run the query for file#
select *
from v$datafile
where file# = file#;
i get no rows returned.
Can someone please tell me what is this value 1266??

Hemant K Chitale wrote:
P1 as FILE_ID is actually the value of DB_FILES (an instance parameter) + the temp file id. Check if DB_FILES is set to 1250. In that case P1 of 1260 would mean the 10th TEMPFILE.
How did you came to know that P1.V$ACTIVE_SESSION_HISTORY = DB_FILES + the temp file id ?
Because when I checked in the docs it is saying :
P1 NUMBER First additional parameter
http://docs.oracle.com/cd/E11882_01/server.112/e25513/dynviews_1007.htm#REFRN30299
Kindly share with us the link, is possible please.
Regards
Girish Sharma

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=1363614992309273

Tkprof 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 sync

select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE 10.2.0.5.0 Production
TNS for Solaris: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
5 rows selected.I am analyzing a CREATE TABLE statement that is showing very high waits (i.e. 96%, over the course of 12 hours) on 'direct path sync'.
To my surprise, the 10.2 Reference does not describe this wait, but this is what the 11.2 Reference says:
===============================
direct path sync
During Direct Path write operations the data is asynchronously written to the database files. At some point the session needs to ensure that all outstanding asynchronous I/O have been completed to disk. On Unix the fsync command, which synchronizes data to disk, is issued to confirm that all the writes have completed and the data is all on disk.
Wait Time: The time taken for the fsync operation to complete, which normally is the time taken to complete the outstanding I/Os.
Parameters Description
file# See "file#"
flags Flags used for debugging purposes
===============================
On our waits, the file# corresponds to a tablespace datafile and the 'flags'=512.
Can anyone suggest further steps for analysis?
Thanks.
Edited by: mtefft on May 24, 2011 3:16 AM

A trace file for this process filled with messages such as these:
WARNING:Could not lower the asynch I/O limit to 896 for SQL direct I/O. It is set to -1
WARNING:Could not lower the asynch I/O limit to 960 for SQL direct I/O. It is set to -1
WARNING:Could not lower the asynch I/O limit to 896 for SQL direct I/O. It is set to -1
WARNING:Could not lower the asynch I/O limit to 864 for SQL direct I/O. It is set to -1
which seems be caused by oracle bug 9772888.

Direct Path Write

Similar Messages

Maybe you are looking for