No wait events info in trace file?

A very good day to all experts,
I am tracing a session using the below procedure.
dbms_system.set_ev(12,13,EV=>10046,LE=>12,NM=>'');
I am just displaying the following information in trace file.Trace file is not displaying any wait events even when i am doing level 12 tracing.How i can see the wait event information in trace files?
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.01 0 0 0 0
Fetch 2 0.00 0.05 2 2 0 1
total 4 0.01 0.07 2 2 0 1
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 55
Rows Row Source Operation
1 TABLE ACCESS BY INDEX ROWID aaa_USERS (cr=2 pr=2 pw=0 time=58806 us)
1 INDEX UNIQUE SCAN SYS_C004271 (cr=1 pr=1 pw=0 time=42773 us)(object id 47506)
Thank you....

Your post is without version information up to 4 digits.
You post tkprof output.
Not all version of Oracle have tkprof post wait event info.
IIRC. this started in Oracle 9iR2.
You would need to look in the raw trace file to find out whether this information is actually available. You will find it is.
This could likely being caused by using 8i, which doesn't have this facility.
But as you don't post a version, your question can not be answered.
Sybrand Bakker
Senior Oracle DBA

Similar Messages

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.

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

Trace file analysis: High cpu timings for FETCH

Hi!
I am doing a 10046 trace file analysis for a performance problem we see on a customer site, but we can't reproduce the problem on our local reference test system.
Basically, the cpu timings for FETCH calls for a SELECT statement are ten times as high on the customer system. There are no WAIT events in the trace file (for this statement), only a high cpu timing for the FETCHES:
Customer instance:
FETCH #19:c=140625,e=140189,p=0,cr=3358,cu=0,mis=0,r=1,dep=1,og=1,tim=1500177409
Reference system;
FETCH #4:c=15625,e=7984,p=0,cr=2262,cu=0,mis=0,r=1,dep=1,og=1,tim=5624714062
I see that the number of consistant reads is 50% higher, but I don't see why this result in 10 times the CPU time and about 20 times the elapsed time. This is does not seem to be a general problem with all statements, so the general timings are comparable to our reference system. The problem seems to be this Select statement only which only joins two tables.
I had the idea that a long running transaction that didn't commit would lead to this problem, since Oracle would need to reconstruct blocks from undo, but there are no such transactions on the system.
With no WAIT events emitted, where does the time go?
Thanks for your help,
Marcus

MMarcus wrote:
Here is the execution plan for the query. It is the same on both systems, with slightly different total costs (8 or 10).
| Id | Operation                      | Name                | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |                     |     1 |    35 |    10 (10)| 00:00:01 |
|   1 | SORT ORDER BY                 |                     |     1 |    35 |    10 (10)| 00:00:01 |
|* 2 |   FILTER                       |                     |       |       |            |          |
|* 3 |    TABLE ACCESS BY INDEX ROWID | PLANHIERARCHIE      |     1 |    35 |     5   (0)| 00:00:01 |
|* 4 |     INDEX RANGE SCAN           | PLANHIERARCHIEINDEX |    21 |       |     2   (0)| 00:00:01 |
|   5 |    NESTED LOOPS                |                     |     1 |    39 |     4   (0)| 00:00:01 |
|* 6 |     TABLE ACCESS BY INDEX ROWID| PLANSCHRITTFOLGE    |     1 |    21 |     3   (0)| 00:00:01 |
|* 7 |      INDEX RANGE SCAN          | PLANSCHRITTFOLGEPK |    11 |       |     2   (0)| 00:00:01 |
|* 8 |     TABLE ACCESS BY INDEX ROWID| PLANHIERARCHIE      |     1 |    18 |     1   (0)| 00:00:01 |
|* 9 |      INDEX UNIQUE SCAN         | PLANHIERARCHIEPK    |     1 |       |     0   (0)| 00:00:01 |
You have omitted the predicate section from the execution plan - and [+*there may be important clues*+|http://jonathanlewis.wordpress.com/2008/12/03/predicate-problems/] in the predicate section.
In your case the problem may +(*for example*+) simply be the way in which the predicates apply to the PLANSCHRITTFOLGEPK index range scan.
Imagine you have 250 index entries per leaf block, and the predicates that apply to the index identify an index range scan that spans 25 entries in one system but 25000 entries (100 leaf blocks) in the other. It is possible that filter predicates against the index eliminate most of the index entries before you go to the table. The CPU used to examine (filter) large numbers of index leaf entries can be significant - and since that index range scan is part of a filter subquery it could many several time - escalating the CPU usage. A check of the access and filter predicates may give you some clue about whether you are seeing that type of problem.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan

About Trace file

Hi
Can I create a trace file as my desire name in Udump folder? Because there are so many trc files in my udump folder. If I soft by date also, i can't recognize my trace file which is recently created.
Please advise...!!
Regards
Arpitha

Hi
How to see the following output of TKPROF for a query? and also how to see the Wait events info? Please help me?
My query
SELECT * FROM emp, dept
WHERE emp.deptno = dept.deptno;I would like to see the trace file output like this...
call   count      cpu    elapsed     disk    query current    rows
Parse     11     0.08      0.18        0       0       0         0
Execute   11     0.23      0.66        0       3       6         0
Fetch     35     6.70      6.83      100   12326       2       824
total     57     7.01      7.67      100   12329       8       826
Misses in library cache during parse: 0 Wait events info.
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                      8084        0.12          5.34
direct path write                             834        0.00          0.00
direct path write temp                        834        0.00          0.05
db file parallel read                           8        1.53          5.51
db file scattered read                       4180        0.07          1.45
direct path read                             7082        0.00          0.05
direct path read temp                        7082        0.00          0.44
rdbms ipc reply                                20        0.00          0.01
SQL*Net message to client                       1        0.00          0.00
SQL*Net message from client                     1        0.00          0.00please help me in this regard..!!

Wait Events "log file parallel write" / "log file sync" during CREATE INDEX

Hello guys,
at my current project i am performing some performance tests for oracle data guard. The question is "How does a LGWR SYNC transfer influences the system performance?"
To get some performance values, that i can compare i just built up a normal oracle database in the first step.
Now i am performing different tests like creating "large" indexes, massive parallel inserts/commits, etc. to get the bench mark.
My database is an oracle 10.2.0.4 with multiplexed redo log files on AIX.
I am creating an index on a "normal" table .. i execute "dbms_workload_repository.create_snapshot()" before and after the CREATE INDEX to get an equivalent timeframe for the AWR report.
After the index is built up (round about 9 GB) i perform an awrrpt.sql to get the AWR report.
And now take a look at these values from the AWR
                                                                   Avg
                                             %Time Total Wait    wait     Waits
Event                                 Waits -outs    Time (s)    (ms)      /txn
log file parallel write              10,019     .0         132      13      33.5
log file sync                           293     .7           4      15       1.0
......How can this be possible?
Regarding to the documentation
-> log file sync: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3120
Wait Time: The wait time includes the writing of the log buffer and the post.-> log file parallel write: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3104
Wait Time: Time it takes for the I/Os to complete. Even though redo records are written in parallel, the parallel write is not complete until the last I/O is on disk.This was also my understanding .. the "log file sync" wait time should be higher than the "log file parallel write" wait time, because of it includes the I/O and the response time to the user session.
I could accept it, if the values are close to each other (maybe round about 1 second in total) .. but the different between 132 seconds and 4 seconds is too noticeable.
Is the behavior of the log file sync/write different when performing a DDL like CREATE INDEX (maybe async .. like you can influence it with the initialization parameter COMMIT_WRITE??)?
Do you have any idea how these values come about?
Any thoughts/ideas are welcome.
Thanks and Regards

Surachart Opun (HunterX) wrote:
Thank you for Nice Idea.
In this case, How can we reduce "log file parallel write" and "log file sync" waited time?
CREATE INDEX with NOLOGGINGA NOLOGGING can help, can't it?Yes - if you create index nologging then you wouldn't be generating that 10GB of redo log, so the waits would disappear.
Two points on nologging, though:
<ul>
it's "only" an index, so you could always rebuild it in the event of media corruption, but if you had lots of indexes created nologging this might cause an unreasonable delay before the system was usable again - so you should decide on a fallback option, such as taking a new backup of the tablespace as soon as all the nologging operatons had completed.
If the database, or that tablespace, is in +"force logging"+ mode, the nologging will not work.
</ul>
Don't get too alarmed by the waits, though. My guess is that the +"log file sync"+ waits are mostly from other sessions, and since there aren't many of them the other sessions are probably not seeing a performance issue. The +"log file parallel write"+ waits are caused by your create index, but they are happeninng to lgwr in the background which is running concurrently with your session - so your session is not (directly) affected by them, so may not be seeing a performance issue.
The other sessions are seeing relatively high sync times because their log file syncs have to wait for one of the large writes that you have triggered to complete, and then the logwriter includes their (little) writes with your next (large) write.
There may be a performance impact, though, from the pure volume of I/O. Apart from the I/O to write the index you have LGWR writting (N copies) of the redo for the index and ARCH is reading and writing the completed log files caused by the index build. So the 9GB of index could easily be responsible for vastly more I/O than the initial 9GB.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan

Max wait from a trace file...what does it mean

Hi,
following is a part of an extended sql trace file :
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
library cache lock 5 0.00 0.00
row cache lock 7 0.00 0.00
library cache pin 3 0.00 0.00
rdbms ipc reply 2 0.00 0.00
SQL*Net message to client 8185 0.00 0.01
SQLNet message from client 8185 1671.98 1688.26*
here what does the column max.wait mean? this is a trace file when a proc was run remotely to a database - it has lots of dbms_output statements, it creates an output file (on the remote pc from which it runs) the proc calls several sql scrips, does lot of query and dml
Now when teh same script is run locally from the server those sql net waits are not there. and the interesting fact is: when run locally it takes 4 mins
and remotely it takes 1 hour. How can we interpret this? and what does teh max wait indiccate?
thanks,

Can you explain more on this? the same proc when run locally does not have this wait and when run from remote ip it has this wait - so does that mean that this is due to network issue?
should we for example - remove the dbms_output statements from this and try ? what should we do to be able to run the script from remote ip and run it in 6-7 minutes- when the scritp is run locally from the from server it takes 4 minutes and from a remote ip it takes one hour. the script also has a spool statement as it has to log its output. Is it that spoling that may be causing this?
Thanks again,
Edited by: orausern on Jan 18, 2010 7:09 AM

SQL*Net message from client - huge wait in trace file

Dear All,
I am facing a performance issue in a particular operation ( which was completed in 21 Minutes earlier). Now the same operation takes more than 35 Minutes. I took a trace for those session ( 10046 level 12 trace ) and found Lot of waits in SQL*Net message from client.
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQLNet message from client 611927 10.00 1121.35*
I copied only the highest wait in the tkprof output.
And I found from the tkprof and even in raw trace file this event waits more time after excuting
SELECT sysdate AS SERVERDATE from dual;
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 115 0.00 0.00
SQLNet message from client 115 10.00 724.52*
Please help me to find out why this wait taking long time, especially on the above query..
Regards,
Vinodh

Vinodh Kumar wrote:
Hi,
This is what available in the trace file
PARSING IN CURSOR #2 len=38 dep=0 uid=60 oct=3 lid=60 tim=7052598842 hv=3788189359 ad='7d844fa0'
*"SELECT sysdate AS SERVERDATE FROM dual"*
END OF STMT
PARSE #2:c=0,e=12,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=7052598839
BINDS #2:
EXEC #2:c=0,e=42,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=7052599002
WAIT #2: nam='SQL*Net message to client' ela= 1 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=7052599058
FETCH #2:c=0,e=15,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=7052599110
*** 2012-01-02 17:07:30.364
WAIT #2: nam='SQL*Net message from client' *" ela= 10007957"* driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=7062607120Please find the last line WAIT -- in the complete trace after executing this query
In awr report , this query taken less than a sec for more than 2000 executions.
Regards,
VinodhGood idea to check the raw trace file. It is important to notice that this particular wait event appears after the fetch of the result from the database. The client receives the SYSDATE from the database server, and then the client performs some sort of action for about 10 seconds before submitting its next request to the database. The SQL statement that immediately follows and immediately preceeds this section of the trace file might provide clues regarding what caused the delay, and where that delay resides in the client side code. Maybe a creative developer added a "sleep for 10 seconds" routine when intending to sleep for 10ms? Maybe the client CPU is close to 100% utilization?
Charles Hooper
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

SQL*NET waits in trace file

Hi All,
There is a long running query, i generated trace file for this request. In trace file i found that there are huge waits on SQL*Net message from client
The below is the trace file output:
Elapsed times include waiting on following events:
Event waited on Times Waited Max. Wait Total Waited
SQL*Net message to client 16 0.00 0.00
SQL*Net more data to client 17 0.00 0.00
db file sequential read 1450 0.02 4.26
SQL*Net message from client 16 1414.20 2702.84
How to resolve this waits from SQL*NET message from client? I checked the network connection, there is no delays in network.
Any inputs on this issue will be appreciated.

As Satish indicated, the "SQL*Net message from client" wait is an event which indicates that the database server was waiting for the next request from the client computer, and not an indication that the query needs to be tuned. Manually review the trace file. At one point in the trace file, you will see this wait event with an ela= value which begins with 14142 - please post to this thread that line from the trace file along with the 20 lines before that line and the 20 lines after that line. You may just have a long wait on this event at the beginning, and another long wait on this event at the end of the query.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Log file sync wait event advise?

Due to business needs, Apps has been designed to do every single transaction commit and coming to infrastructure, db Datafiles and redo logs are in faster disk (FC) and archive logs are placed in slower speed disk(SATA). We are seeing the log file sync wait event in the top events and symptoms for this waitevent is either disk speed is slow or doing frequent commit. In my scenario i guess 99% this wait event happening due to frequent commits. Can i assume archive log slower disk will not be root cause for this (my understanding this waitevent occurs on redo log writing area and not in archive log writing area) ? Please confirm.

user530956 wrote:
We are seeing the log file sync wait event in the top events and symptoms for this waitevent is either disk speed is slow or doing frequent commit.As Hemant has pointed out, this could also be due to CPU overload.
I note you say the event is IN the top events - this tells us virtually nothing; an event might be IN the top 5 while being responsible for less than 1% of the total recorded wait time; it could be IN the top 5 but explained as a side effect of something that appeared above it in the Top 5. Why not just show us a typical Top 5 (along with a typical Load Profile it you want to be really helpful).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files from text files, START and END the text with the tag {noformat}{noformat} (the word "code" in lowercase, curly brackets, no spaces) so that the text appears in fixed format. This won't be sufficient if you try to cut and paste from an HTML report, which will need further editing.

Wait events "db file scatter read"

I have a continuous wait event in my production database...*"db file scatter read"* can any one tell me the reason behind that..

i want perfect answer not google search..google produce lot of options ..i know that.Where is perfect answer? In documentation, books, expert's blog, forum right? And how to find them, i think from google and/or search in net. Simple to admit, but hard to follow....
I really appreciate that you are seeking "perfect answer", but i am sure for that you have to use "search tech" as well.
As Sidhu has already given you the perfect link, Aman has asked you statspack info, now i hope you are addressing your question in a well manner. Let us work on the issue with great experts.
Regards
Girish Sharma

Trace file doesn't show any info about error

Dear all,
DB : 10.2.0.4
Solaris 5.10
We have a background program to do some activities in the Database.
Today ,when running the program we got the below error :
1) 20221: errexit, ORA-00001: unique constraint (MEDS.MED_USER_EQUS_HIST_PK) violated.
I ran a trace of this session and the trace file doesnt have any info about the error..ran trace using the below command :
exec sys.DBMS_SUPPORT.START_TRACE_IN_SESSION(2166,30629, false,TRUE);
why is that the trace file doesn't have any info about the error.
2) I disable the constraint disable novalidate.
even then I got the same error .. why is the constraint getting validate even if I disable the constraint ?
Please guide
Kai

As usual this question has documented answers, and you are asking this question, because you consistently refuse to read any documentation. So in your case the answer could have been 'Yes, there is. See the docs'.
You could actually say you are in gross violation of the forums etiquette post, and are abusing this forum.
If you would have read the docs, you wouldn't have used dbms_support (which was never supported for end-users), but you would have looked at
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_monitor.htm#i1003679
and what do you see?
The life of a DBA can be so easy when he makes an attempt to find information himself!
He doesn't have to wait until some kind soul answers doc question 779!
Sybrand Bakker
Senior Oracle DBA

Performance Issue: Wait event "log file sync" and "Execute to Parse %"

In one of our test environments users are complaining about slow response.
In statspack report folowing are the top-5 wait events
Event Waits Time (cs) Wt Time
log file parallel write 1,046 988 37.71
log file sync 775 774 29.54
db file scattered read 4,946 248 9.47
db file parallel write 66 248 9.47
control file parallel write 188 152 5.80
And after runing the same application 4 times, we are geting Execute to Parse % = 0.10. Cursor sharing is forced and query rewrite is enabled
When I view v$sql, following command is parsed frequently
EXECUTIONS PARSE_CALLS
SQL_TEXT
93380 93380
select SEQ_ORDO_PRC.nextval from DUAL
Please suggest what should be the method to troubleshoot this and if I need to check some more information
Regards,
Sudhanshu Bhandari

Well, of course, you probably can't eliminate this sort of thing entirely: a setup such as yours is inevitably a compromise. What you can do is make sure your log buffer is a good size (say 10MB or so); that your redo logs are large (at least 100MB each, and preferably large enough to hold one hour or so of redo produced at the busiest time for your database without filling up); and finally set ARCHIVE_LAG_TARGET to something like 1800 seconds or more to ensure a regular, routine, predictable log switch.
It won't cure every ill, but that sort of setup often means the redo subsystem ceases to be a regular driver of foreground waits.

Trace file event set....need the file for the user...

hello all,
i had a question about the trace file, I was asked by one of ur manager to set events for trace file...he asked to do this...
ALTER SESSION SET EVENTS '10046 trace name context forever, level 12';
alter system set events '1483 trace name errorstack, level 12' ;
i understand they go to the udump, but my question how am i suppose to know which trace file to look as there are tons of them in udump??? We actually want this for a specific schema that we are lookin for. Could anyone explain what the above are doing and how to get the trace file for it. Thanks

If you are running this from your session and want to check the file that has been created for your session,from Effective Orcle by design,this may be helpful,
select rtrim(c.value,'/') || '/' ||d.instance_name ||
'_ora_' || ltrim(to_char(a.spid)) || '.trc'
from V$process a,v$session b,v$parameter c,v$instance d
where a.add=b.paddr
and b.audsid=sys_context('userenv','sessionid')
and c.name='user_dump_dest'This would tell you the exact file that would had been created for your session.
HTH
Aman....

How do I the interpret "Disk file operations I/O" wait event?

I have a large and very busy batch database. All of a sudden the "Disk file operations I/O" wait event is in the top 5 in AWR.
The manual page isn't very helpful:
http://download.oracle.com/docs/cd/E11882_01/server.112/e17110/waitevents003.htm#insertedID40
Disk file operations I/O
This event is used to wait for disk file operations (for example, open, close, seek, and resize). It is also used for miscellaneous I/O operations such as block dumps and password file accesses.
So here is my question: What exactly is going on when I see this wait event? Why doesn't it show up as one of the other I/O events? Can I make it go away? Should I make it go away?
DR

sb92075 wrote:
All of a sudden the "Disk file operations I/O" wait event is in the top 5 in AWR.Top wait event
In EVERY Top Wait Event list, one wait event will ALWAYS be on top as #1; by definition of the list.
Simply because any item, even #1, appears on this list does not mean this is a problem & needs to be fixed.
If the Top Wait Event accounts for only 5 seconds out of a 1 hour sample,
then reducing it to ZERO won't measurably improve overall application performance.
The actual Time Waited is required to determine if it is a problem or not.It's taking 20% of time in a 15 minute sample. Anything that takes 20% of deserves to be understood....So: What actually causes it?
DR

No wait events info in trace file?

Similar Messages

Maybe you are looking for