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>

Similar Messages

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

Wait Event Direct path read TEMP

HI,
I have two sessions waiting on wait event "DIECT PATH READ TEMP" (both the sessions with same SQL).Those sessions are almost in hung state.If i run that query from any other session,even that gets hanged.I have generated 10046 trace for these and found that all of them are waiting for a index object in TEMP datafile.
Has anyone of you had the same issue.
Please explain me what kind of action i have taken.
I have verified the stats..they are all up to date.
Thanks,
Pramod Garre

Hi ,
It is IMPOSSIBLE for two SELECT statements to obstruct each other.-
Its not impossible my dear.Do you know something called "Hot Block".Dont you know that in that case select queries obstruct each other??Dont suggest if you dont know.
If you don't post meaningful information, you'll be left with your own mystery-
I agree i have to provide more information.
Thanks
Pramod

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

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.

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

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

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

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

951241 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 temp

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

Hi,
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

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.

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

Invisible index getting accessed during query execution

Hello Guys,
There is a strange problem , I am encountering . I am working on tuning the performance of one of the concurrent request in our 11i ERP System having database 11.1.0.7
I had enabled oradebug trace for the request and generated tkprof out of it. For below query which is taking time , I found that , in the trace generated , wait event is "db file sequential read" on an PO_LINES_N10 index but in the generated tkprof , for the same below query , the full table scan for PO_LINES_ALL is happening , as that table is 600 MB in size.
Below is the query ,
===============
UPDATE PO_LINES_ALL A
SET A.VENDOR_PRODUCT_NUM = (SELECT SUPPLIER_ITEM FROM APPS.IRPO_IN_BPAUPDATE_TMP C WHERE BATCH_ID = :B1 AND PROCESSED_FLAG = 'P' AND ACTION = 'UPDATE' AND C.LINE_ID =A.PO_LINE_ID AND ROWNUM = 1 AND SUPPLIER_ITEM IS NOT NULL),
LAST_UPDATE_DATE = SYSDATE
===============
Index PO_LINES_N10 is on the column LAST_UPDATE_DATE , logically for such query , index should not have got used as that indexed column is not in select / where clause.
Also, why there is discrepancy between tkprof and trace generated for the same query .
So , I decided to INVISIBLE the index PO_LINES_N10 but still that index is getting accessed in the trace file .
I have also checked the below parameter , which is false so optimizer should not make use of invisible indexes during query execution.
SQL> show parameter invisible
NAME TYPE VALUE
optimizer_use_invisible_indexes boolean FALSE
Any clue regarding this .
Thanks and Regards,
Prasad
Edited by: Prasad on Jun 15, 2011 4:39 AM

Hi Dom,
Sorry for the late reply , but yes , an update statement is trying to update that index even if it's invisible.
Also, it seems performance issue started appearing when this index got created , so now I have dropped that index in test environment and ran the concurrent program again with oradebug level 12 trace enabled and found bit improvement in the results .
With index dropped -> 24 records/min got processed
With index -> 14 records/min got processed
so , I am looking forward without this index in the production too but before that, I have concerns regarding tkprof output. Can we further improve the performance of this query.
Please find the below tkprof with and without index .
====================
Sql statement
====================
UPDATE PO_LINES_ALL A SET A.VENDOR_PRODUCT_NUM = (SELECT SUPPLIER_ITEM FROM
APPS.IRPO_IN_BPAUPDATE_TMP C
WHERE
BATCH_ID = :B1 AND PROCESSED_FLAG = 'P' AND ACTION = 'UPDATE' AND C.LINE_ID =
A.PO_LINE_ID AND ROWNUM = 1 AND SUPPLIER_ITEM IS NOT NULL),
LAST_UPDATE_DATE = SYSDATE
=========================
TKPROF with Index for the above query ( processed 643 records )
=========================
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 2499.64 2511.99 98158 645561632 13105579 1812777
Fetch 0 0.00 0.00 0 0 0 0
total 2 2499.64 2511.99 98158 645561632 13105579 1812777
=============================
TKPROF without Index for the above query ( processed 4452 records )
=============================
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 10746.96 10544.13 84125 3079376156 1870058 1816289
Fetch 0 0.00 0.00 0 0 0 0
total 2 10746.96 10544.13 84125 3079376156 1870058 1816289
=============================
Explain plan which is same in both the cases
=============================
Rows Row Source Operation
0 UPDATE PO_LINES_ALL (cr=3079377095 pr=84127 pw=0 time=0 us)
1816289 TABLE ACCESS FULL PO_LINES_ALL (cr=83175 pr=83026 pw=0 time=117690 us cost=11151 size=29060624 card=1816289)
0 COUNT STOPKEY (cr=3079292918 pr=20 pw=0 time=0 us)
0 TABLE ACCESS BY INDEX ROWID IRPO_IN_BPAUPDATE_TMP (cr=3079292918 pr=20 pw=0 time=0 us cost=4 size=22 card=1)
180368800 INDEX RANGE SCAN IRPO_IN_BPAUPDATE_N1 (cr=51539155 pr=3 pw=0 time=16090005 us cost=3 size=0 card=1)(object id 372721)
There is a lot increase in the CPU ,so I would like to further tune this query. I have run SQL Tuning task but didn't get any recommendations for the same.
Since in the trace , I have got db scattered read wait event for the table "PO_LINES_ALL" but disk reads are not much , so am not sure the performance improvement even if I pin this table (620 MB in size and is it feasible to pin , SGA is 5GB with sga_target set ) in the shared pool .
I have already gathers stats for the concerned tables and rebuilt the indexes .
Is there any other thing that can be performed to tune this query further and bring down CPU, time taken to execute.
Thanks a lot for your reply.
Thanks and Regards,
Prasad
Edited by: Prasad on Jun 28, 2011 3:52 AM
Edited by: Prasad on Jun 28, 2011 3:54 AM
Edited by: Prasad on Jun 28, 2011 3:56 AM

How to see the wait events info. after excute a select query

Hi
How to see the wait events info. after execute a select query. Are there any parameter to set for this option?
And also wanna see the follwing info. in trace file. For this what are the parameters I have to set right?
SELECT * FROM emp, dept
WHERE emp.deptno = dept.deptno;
call   count      cpu    elapsed     disk    query current    rows
Parse      1     0.16      0.29         3       13       0       0
Execute    1     0.00      0.00         0        0       0       0
Fetch      1     0.03      0.26         2        2       4      14
Misses in library cache during parse: 1
Parsing user id: (8) SCOTT Regards
Arpitha

$ sqlplus scott/tiger
SQL*Plus: Release 10.2.0.2.0 - Production on Wed Apr 20 15:29:33 2011
Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> SHOW PARAMETER dump
NAME                                 TYPE        VALUE
background_core_dump                 string      partial
background_dump_dest                 string      /user/oracle/app/oracle/admin/
                                                 orclsb/bdump
core_dump_dest                       string      /user/oracle/app/oracle/admin/
                                                 orclsb/cdump
max_dump_file_size                   string      UNLIMITED
shadow_core_dump                     string      partial
user_dump_dest                       string      /user/oracle/app/oracle/admin/
                                                 orclsb/udump
SQL> ALTER SESSION SET EVENTS='10046 trace name context forever, level 12';
Session altered.
SQL> SELECT * FROM emp WHERE deptno=20;
     EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM
    DEPTNO
      7369 SMITH      CLERK           7902 17-DEC-80        800
        20
      7566 JONES      MANAGER         7839 02-APR-81       2975
        20
      7788 SCOTT      ANALYST         7566 19-APR-87       3000
        20
     EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM
    DEPTNO
      7876 ADAMS      CLERK           7788 23-MAY-87       1100
        20
      7902 FORD       ANALYST         7566 03-DEC-81       3000
        20Now
$ pwd
/user/oracle/app/oracle/admin/orclsb/udump
$ ls -ltr|tail -5
-rw-r-----   1 oracle   oinstall     622 Apr 20 11:35 orclsb_ora_949.trc
-rw-r-----   1 oracle   oinstall     651 Apr 20 11:35 orclsb_ora_976.trc
-rw-r-----   1 oracle   oinstall    1982 Apr 20 11:35 orclsb_ora_977.trc
-rw-r-----   1 oracle   oinstall    1443 Apr 20 15:29 orclsb_ora_1251.trc
-rw-r-----   1 oracle   oinstall 279719 Apr 20 15:30 orclsb_ora_1255.trc
$ tkprof orclsb_ora_1255.trc orclsb_ora_1255.txt
TKPROF: Release 10.2.0.2.0 - Production on Wed Apr 20 15:32:17 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
$ ls -ltr|tail -5
-rw-r-----   1 oracle   oinstall     651 Apr 20 11:35 orclsb_ora_976.trc
-rw-r-----   1 oracle   oinstall    1982 Apr 20 11:35 orclsb_ora_977.trc
-rw-r-----   1 oracle   oinstall    1443 Apr 20 15:29 orclsb_ora_1251.trc
-rw-r-----   1 oracle   oinstall 279719 Apr 20 15:30 orclsb_ora_1255.trc
-rw-r--r--   1 oracle   oinstall   26872 Apr 20 15:32 orclsb_ora_1255.txtThis orclsb_ora_1255.txt contains the required information.

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

Similar Messages

Maybe you are looking for