Oracle wait event views

Hi,
I have to investigate a 10gr2 SE database. it is performing badly. As i understand oracle now we need to look at what the database is WAITING for.
as it is SE then I cannot use AWR. Now I have seen this document which talks about wait classes
http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents001.htm
can these be accessed with out AWR?
thanks

query V$SESSION_WAIT
SQL> desc v$session_wait
Name                            Null?    Type
SID                                  NUMBER
SEQ#                                  NUMBER
EVENT                                  VARCHAR2(64)
P1TEXT                              VARCHAR2(64)
P1                                  NUMBER
P1RAW                                  RAW(4)
P2TEXT                              VARCHAR2(64)
P2                                  NUMBER
P2RAW                                  RAW(4)
P3TEXT                              VARCHAR2(64)
P3                                  NUMBER
P3RAW                                  RAW(4)
WAIT_CLASS_ID                             NUMBER
WAIT_CLASS#                             NUMBER
WAIT_CLASS                             VARCHAR2(64)
WAIT_TIME                             NUMBER
SECONDS_IN_WAIT                        NUMBER
STATE                                  VARCHAR2(19)

Similar Messages

Oracle wait events

Hello colleagues,
Could you please let me know where can I find detailed information with regards to Oracle wait events?
I'm interested in methods that allow me to know how to identify performance issues on the system that are related to DB wait events.
Thanks and best regards
Rod

Hi there,
in addition to the already mentioned SAP notes, why don't you just check the Oracle documentation?
Most of the wait events are fully explained in there, along with the approach how to use the wait event data.
If you want to grasp a better understanding of the technique of wait time analysis, I highly recommend that you check the website of Cary Millsap and Method R. Cary provides great introductions into the theory behind the wait events and does a perfect job with explaining it.
regards,
Lars

Wait events tuning

Hello SAP Community,
I start by mentioning a few details about the system I'll be talking about in this subject:
- SAP NetWeaver 7.0
- Oracle Database 10.2g
I was reading the following Note: "Note 618868 - FAQ: Oracle performance", in order to try to understand what's causing the oracle database to have slow performance.
While reading section 3 "How can I determine whether the general database performance can be optimized?" I found out that the ratio of "Busy wait time to CPU time" is away above the recommended 60:40 value. I'm getting a 94:6 ratio. This value was calculated using the query:
SELECT
ROUND((STM1.VALUE - STM2.VALUE) / 1000000) "BUSY WAIT TIME (S)",
ROUND(STM2.VALUE / 1000000) "CPU TIME (S)",
ROUND((STM1.VALUE - STM2.VALUE) / STM1.VALUE * 100) || ' : ' ||
ROUND(STM2.VALUE / STM1.VALUE * 100) RATIO
FROM V$SYS_TIME_MODEL STM1, V$SYS_TIME_MODEL STM2
WHERE STM1.STAT_NAME = 'DB time' AND STM2.STAT_NAME = 'DB CPU';
With such high values, SAP recommends to improve system performance doing some "wait event tuning".
Can someone give me some directions about this subject? Some guides specific to this subject would be nice. Any further information about my system you may require, please ask me.
Thanks in advance.
Best regards,
Daniel Garrido

Hello again,
Before I did any changes to the Oracle's parameters I checked the Note 619188 - FAQ: Oracle wait events, to understand what could be causing such high event wait time.
With the query:
SELECT EVENT, TOTAL_WAITS, TIME_WAITED, AVG_MS,
ROUND(RATIO_TO_REPORT(TIME_WAITED) OVER () * 100) PERCENT
FROM (SELECT SUBSTR(EVENT, 1, 30) EVENT, TOTAL_WAITS, TIME_WAITED,
ROUND(TIME_WAITED_MICRO / TOTAL_WAITS / 1000, 2) AVG_MS
FROM V$SYSTEM_EVENT
WHERE WAIT_CLASS NOT IN ('Idle', 'System I/O')
UNION
SELECT 'CPU' EVENT, NULL, VALUE, NULL
FROM V$SYSSTAT
WHERE STATISTIC# = 12
ORDER BY 3 DESC)
WHERE ROWNUM <=10;
I got the non-idle events that took more time in my system and the result was:
Result of the SELECT statement
EVENT
TOTAL_WAITS
TIME_WAITED
AVG_MS
PERCENT
log file switch (archiving nee
578.686
57.850.863
999.69
80
buffer busy waits
712.163
6.420.932
90.16
9
CPU
0
2.791.238
4
db file sequential read
4.005.546
1.746.442
4.36
2
log file sync
10.176.490
1.577.177
1.55
2
enq: TX - row lock contention
854.451
642.955
7.52
1
db file scattered read
1.055.533
621.332
5.89
1
enq: CF - contention
210.085
246.910
11.75
0
read by other session
561.558
119.910
2.14
0
log file switch completion
10.777
85.843
79.65
0
So most of the TIME_WAITED for wait events was because of the "log file switch (archiving needed)", after reading what could cause such wait event, I understood this was related with a problem I previously had in the server, where the archiving folder was with no space left. (Meanwhile the backup of the archives is being done and so the folder is being cleaned on a daily basis).
Thank you all for your help!

Need help to analysis "foreground and background wait events" on statspack report for oracle database 11.2.0.4 on AIX

Hi: I'm analyzing this STATSPACK report: it is "volume test" on our UAT server, so most input is from 'bind variables'. Our shared pool is well utilized in oracle. Oracle redo logs is not appropriately configured on this server, as in 'Top 5 wait events' there are 2 for redos.
I need to know what else information can be dig-out from 'foreground wait events' & 'background wait events', and what can assist us to better understanding, in combination of 'Top 5 wait event's, that how the server/test went? it could be overwelming No. of wait events, so appreciate any helpful diagnostic or analysis. Database is oracle 11.2.0.4 upgraded from 11.2.0.3, on IBM AIX power system 64bit, level 6.x
STATSPACK report for
Database    DB Id    Instance     Inst Num Startup Time   Release     RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
700000XXX   XXX              1 22-Apr-15 12:12 11.2.0.4.0 NO
Host Name             Platform                CPUs Cores Sockets   Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
     dXXXX_XXX    AIX-Based Systems (64-     2     1       0         16.0
Snapshot       Snap Id     Snap Time      Sessions Curs/Sess Comment
~~~~~~~~    ---------- ------------------ -------- --------- ------------------
Begin Snap:       5635 22-Apr-15 13:00:02      114       4.6
End Snap:       5636 22-Apr-15 14:00:01      128       8.8
   Elapsed:      59.98 (mins) Av Act Sess:       0.6
   DB time:      35.98 (mins)      DB CPU:      19.43 (mins)
Cache Sizes            Begin        End
~~~~~~~~~~~       ---------- ----------
    Buffer Cache:     2,064M              Std Block Size:         8K
     Shared Pool:     3,072M                  Log Buffer:    13,632K
Load Profile              Per Second    Per Transaction    Per Exec    Per Call
~~~~~~~~~~~~      ------------------ ----------------- ----------- -----------
      DB time(s):                0.6                0.0        0.00        0.00
       DB CPU(s):                0.3                0.0        0.00        0.00
       Redo size:          458,720.6            8,755.7
   Logical reads:           12,874.2              245.7
   Block changes:            1,356.4               25.9
Physical reads:                6.6                0.1
Physical writes:               61.8                1.2
      User calls:            2,033.7               38.8
          Parses:              286.5                5.5
     Hard parses:                0.5                0.0
W/A MB processed:                1.7                0.0
          Logons:                1.2                0.0
        Executes:              801.1               15.3
       Rollbacks:                6.1                0.1
    Transactions:               52.4
Instance Efficiency Indicators
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %: 100.00       Redo NoWait %: 100.00
            Buffer Hit   %:   99.98 Optimal W/A Exec %: 100.00
            Library Hit   %:   99.77        Soft Parse %:   99.82
         Execute to Parse %:   64.24         Latch Hit %:   99.98
Parse CPU to Parse Elapsd %:   53.15     % Non-Parse CPU:   98.03
Shared Pool Statistics        Begin   End
             Memory Usage %:   10.50   12.79
    % SQL with executions>1:   69.98   78.37
% Memory for SQL w/exec>1:   70.22   81.96
Top 5 Timed Events                                                    Avg %Total
~~~~~~~~~~~~~~~~~~                                                   wait   Call
Event                                            Waits    Time (s)   (ms)   Time
CPU time                                                       847          50.2
enq: TX - row lock contention                    4,480         434     97   25.8
log file sync                                  284,169         185      1   11.0
log file parallel write                        299,537         164      1    9.7
log file sequential read                           698          16     24    1.0
Host CPU (CPUs: 2 Cores: 1 Sockets: 0)
~~~~~~~~              Load Average
                      Begin     End      User System    Idle     WIO     WCPU
                       1.16    1.84     19.28   14.51   66.21    1.20   82.01
Instance CPU
~~~~~~~~~~~~                                       % Time (seconds)
                     Host: Total time (s):                  7,193.8
                  Host: Busy CPU time (s):                  2,430.7
                   % of time Host is Busy:      33.8
             Instance: Total CPU time (s):                  1,203.1
          % of Busy CPU used for Instance:      49.5
        Instance: Total Database time (s):                  2,426.4
%DB time waiting for CPU (Resource Mgr):       0.0
Memory Statistics                       Begin          End
~~~~~~~~~~~~~~~~~                ------------ ------------
                  Host Mem (MB):     16,384.0     16,384.0
                   SGA use (MB):      7,136.0      7,136.0
                   PGA use (MB):        282.5        361.4
    % Host Mem used for SGA+PGA:         45.3         45.8
Foreground Wait Events DB/Inst: XXXXXs Snaps: 5635-5636
-> Only events with Total Wait Time (s) >= .001 are shown
-> ordered by Total Wait Time desc, Waits desc (idle events last)
                                                             Avg          %Total
                                          %Tim Total Wait   wait    Waits   Call
Event                               Waits out   Time (s)   (ms)     /txn   Time
enq: TX - row lock contentio        4,480    0        434     97      0.0   25.8
log file sync                     284,167    0        185      1      1.5   11.0
Disk file operations I/O            8,741    0          4      0      0.0     .2
direct path write                  13,247    0          3      0      0.1     .2
db file sequential read             6,058    0          1      0      0.0     .1
buffer busy waits                   1,800    0          1      1      0.0     .1
SQL*Net more data to client        29,161    0          1      0      0.2     .1
direct path read                    7,696    0          1      0      0.0     .0
db file scattered read                316    0          1      2      0.0     .0
latch: shared pool                    144    0          0      2      0.0     .0
CSS initialization                     30    0          0      3      0.0     .0
cursor: pin S                          10    0          0      9      0.0     .0
row cache lock                         41    0          0      2      0.0     .0
latch: row cache objects               19    0          0      3      0.0     .0
log file switch (private str            8    0          0      7      0.0     .0
library cache: mutex X                 28    0          0      2      0.0     .0
latch: cache buffers chains            54    0          0      1      0.0     .0
latch free                            290    0          0      0      0.0     .0
control file sequential read        1,568    0          0      0      0.0     .0
log file switch (checkpoint             4    0          0      6      0.0     .0
direct path sync                        8    0          0      3      0.0     .0
latch: redo allocation                 60    0          0      0      0.0     .0
SQL*Net break/reset to clien           34    0          0      1      0.0     .0
latch: enqueue hash chains             45    0          0      0      0.0     .0
latch: cache buffers lru cha            7    0          0      2      0.0     .0
latch: session allocation               5    0          0      1      0.0     .0
latch: object queue header o            6    0          0      1      0.0     .0
ASM file metadata operation            30    0          0      0      0.0     .0
latch: In memory undo latch            15    0          0      0      0.0     .0
latch: undo global data                 8    0          0      0      0.0     .0
SQL*Net message from client     6,362,536    0    278,225     44     33.7
jobq slave wait                     7,270 100      3,635    500      0.0
SQL*Net more data from clien        7,976    0         15      2      0.0
SQL*Net message to client       6,362,544    0          8      0     33.7
Background Wait Events DB/Inst: XXXXXs Snaps: 5635-5636
-> Only events with Total Wait Time (s) >= .001 are shown
-> ordered by Total Wait Time desc, Waits desc (idle events last)
                                                             Avg          %Total
                                          %Tim Total Wait   wait    Waits   Call
Event                               Waits out   Time (s)   (ms)     /txn   Time
log file parallel write           299,537    0        164      1      1.6    9.7
log file sequential read              698    0         16     24      0.0    1.0
db file parallel write              9,556    0         13      1      0.1     .8
os thread startup                     146    0         10     70      0.0     .6
control file parallel write         2,037    0          2      1      0.0     .1
Log archive I/O                        35    0          1     30      0.0     .1
LGWR wait for redo copy             2,447    0          0      0      0.0     .0
db file async I/O submit            9,556    0          0      0      0.1     .0
db file sequential read               145    0          0      2      0.0     .0
Disk file operations I/O              349    0          0      0      0.0     .0
db file scattered read                 30    0          0      4      0.0     .0
control file sequential read        5,837    0          0      0      0.0     .0
ADR block file read                    19    0          0      4      0.0     .0
ADR block file write                    5    0          0     15      0.0     .0
direct path write                      14    0          0      2      0.0     .0
direct path read                        3    0          0      7      0.0     .0
latch: shared pool                      3    0          0      6      0.0     .0
log file single write                  56    0          0      0      0.0     .0
latch: redo allocation                 53    0          0      0      0.0     .0
latch: active service list              1    0          0      3      0.0     .0
latch free                             11    0          0      0      0.0     .0
rdbms ipc message                 314,523    5     57,189    182      1.7
Space Manager: slave idle wa        4,086   88     18,996   4649      0.0
DIAG idle wait                      7,185 100      7,186   1000      0.0
Streams AQ: waiting for time            2   50      4,909 ######      0.0
Streams AQ: qmn slave idle w          129    0      3,612 28002      0.0
Streams AQ: qmn coordinator           258   50      3,612 14001      0.0
smon timer                             43    2      3,605 83839      0.0
pmon timer                          1,199   99      3,596   2999      0.0
SQL*Net message from client        17,019    0         31      2      0.1
SQL*Net message to client          12,762    0          0      0      0.1
class slave wait                       28    0          0      0      0.0
thank you very much!

Hi: just know it now: it is a large amount of 'concurrent transaction' designed in this "Volume Test" - to simulate large incoming transaction volme, so I guess wait in eq:TX - row is expected.
The fact: (1) redo logs at uat server is known to not well-tune for configurations (2) volume test slow 5%, however data amount in its test is kept the same by each time import production data, by the team. So why it slowed 5% this year?
The wait histogram is pasted below, any one interest to take a look? any ideas?
Wait Event Histogram DB/Inst: XXXX/XXXX Snaps: 5635-5636
-> Total Waits - units: K is 1000, M is 1000000, G is 1000000000
-> % of Waits - column heading: <=1s is truly <1024ms, >1s is truly >=1024ms
-> % of Waits - value: .0 indicates value was <.05%, null is truly 0
-> Ordered by Event (idle events last)
                           Total ----------------- % of Waits ------------------
Event                      Waits <1ms <2ms <4ms <8ms <16ms <32ms <=1s   >1s
ADR block file read          19   26.3   5.3 10.5 57.9
ADR block file write          5                     40.0        60.0
ADR file lock                 6 100.0
ARCH wait for archivelog l   14 100.0
ASM file metadata operatio   30 100.0
CSS initialization           30              100.0
Disk file operations I/O   9090   97.2   1.4    .6    .4    .2    .1    .1
LGWR wait for redo copy    2447   98.5    .5    .4    .2    .2    .2    .1
Log archive I/O              35   40.0         8.6 25.7   2.9        22.9
SQL*Net break/reset to cli   34   85.3   8.8         5.9
SQL*Net more data to clien   29K 99.9    .0    .0    .0          .0    .0
buffer busy waits          1800   96.8    .7    .7    .6    .3    .4    .5
control file parallel writ 2037   90.7   5.0   2.1    .8   1.0    .3    .1
control file sequential re 7405 100.0                      .0
cursor: pin S                10   10.0                    90.0
db file async I/O submit   9556   99.9    .0                .0          .0
db file parallel read         1 100.0
db file parallel write     9556   62.0 32.4   1.7    .8   1.5   1.3    .1
db file scattered read      345   72.8   3.8   2.3 11.6   9.0    .6
db file sequential read    6199   97.2    .2    .3   1.6    .7    .0    .0
direct path read           7699   99.1    .4    .2    .1    .1    .0
direct path sync              8   25.0 37.5 12.5 25.0
direct path write            13K 97.8    .9    .5    .4    .3    .1    .0
enq: TX - row lock content 4480     .4    .7   1.3   3.0   6.8 12.3 75.4    .1
latch free                  301   98.3    .3    .7    .7
latch: In memory undo latc   15   93.3   6.7
latch: active service list    1              100.0
latch: cache buffers chain   55   94.5                     3.6   1.8
latch: cache buffers lru c    9   88.9                    11.1
latch: call allocation        6 100.0
latch: checkpoint queue la    3 100.0
latch: enqueue hash chains   45   97.8                     2.2
latch: messages               4 100.0
latch: object queue header    7   85.7        14.3
latch: redo allocation      113   97.3               1.8    .9
latch: row cache objects     19   89.5                           5.3   5.3
latch: session allocation     5   80.0              20.0
latch: shared pool          147   90.5   1.4   2.7   1.4    .7   1.4   2.0
latch: undo global data       8 100.0
library cache: mutex X       28   89.3         3.6         3.6         3.6
log file parallel write     299K 95.6   2.6   1.0    .4    .3    .2    .0
log file sequential read    698   29.5    .1               4.6 46.8 18.9
log file single write        56 100.0
log file switch (checkpoin    4               25.0 50.0 25.0
log file switch (private s    8         12.5        37.5 50.0
log file sync               284K 93.3   3.7   1.4    .7    .5    .3    .1
os thread startup           146                                      100.0
row cache lock               41   85.4   9.8               2.4         2.4
DIAG idle wait             7184                                      100.0
SQL*Net message from clien 6379K 86.6   5.1   2.9   1.3    .7    .3   2.8    .3
SQL*Net message to client 6375K 100.0    .0    .0    .0    .0    .0    .0
Wait Event Histogram DB/Inst: XXXX/xxxx Snaps: 5635-5636
-> Total Waits - units: K is 1000, M is 1000000, G is 1000000000
-> % of Waits - column heading: <=1s is truly <1024ms, >1s is truly >=1024ms
-> % of Waits - value: .0 indicates value was <.05%, null is truly 0
-> Ordered by Event (idle events last)
                           Total ----------------- % of Waits ------------------
Event                      Waits <1ms <2ms <4ms <8ms <16ms <32ms <=1s   >1s
SQL*Net more data from cli 7976   99.7    .1    .1    .0                      .1
Space Manager: slave idle 4086     .1    .2    .0    .0    .3         3.2 96.1
Streams AQ: qmn coordinato 258   49.2                .8                    50.0
Streams AQ: qmn slave idle 129                                            100.0
Streams AQ: waiting for ti    2   50.0                                      50.0
class slave wait             28   92.9   3.6   3.6
jobq slave wait            7270     .0                               100.0
pmon timer                 1199                                            100.0
rdbms ipc message           314K 10.3   7.3 39.7 15.4 10.6   5.3   8.2   3.3
smon timer                   43                                            100.0

Current wait events in oracle database

Hi guys need your help
I got a dataabse ruuning very slow and I need to find out the current wait events in the oracle database and can I find out what reason each session is waiting for.

Use @wait.sql script to find out the wait events :
select sid, event, seconds_in_wait secs_wait, state,p1,p2,p3,wait_time,p1text,p2text,p3text
from v$session_wait
where sid in
+(select a.sid from v$session a, v$process b where a.paddr = b.addr+
and a.status = 'ACTIVE' and a.username is not null)
order by 1
+/+
Edited by: Girish on Jun 9, 2011 4:06 AM

Streams AQ wait event on Oracle 10g

Hello,
I have ECC 6.0 on W2k3 with Oracle. I have some wait event about Streams AQ :
Streams AQ: waiting for messages in the queue
Streams AQ: qmn slave idle wait
Streams AQ: qmn coordinator waiting for slave to start
What does it mean ? What can I do to fix that?
From what I read, it's seems to have something to do with parameter : aq_tm_processes
What this parameter whould be set to? It seems to be set to O now.
Thank you for any help,
Nicholas

Hi,
What is the Patch Level of Oracle 10g which is in use ?
Please refer Oracle Meta link 428441.1 to get more information. It will tell you the reason and the possible alternatives to deal with it. You can refer SAP Note 758563 to get Oracle Meta link access.
Unless you use Oracle Streams Advanced Queuing , there's no need to set this parameter.
If AQ_TM_PROCESSES is not specified or is set to 0, then the queue monitor is not created.
In 10gR2 parameter AQ_TM_PROCESSES shouldn't be set explicitly in pfile/spfile, because Oracle autotunes it.
Also refer the [this link|SRM Alert Management does not determine recipient runtime?; to get more info.
Regards,
Bhavik G. Shroff

Oracle RAC Wait events

Sun OS 10
Oracle 10.2.0.5
We we are running 2 node RAC and we frequently seeing the following waits in the top 5 wait event
cr request retry
gcs log flush sync
Couldn't locate these events in the database reference
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents.htm
Thanks
Saravanan

gcs log flush sync is similar to log file sync in standalone:
from - http://orainternals.files.wordpress.com/2010/02/riyaj_advanced_rac_troubleshooting_rmoug_2010_ppt.pdf (you might have more luck opening this one)
Gcs log flush sync
- But, if the instances crash right after the block is transferred to
other node, how does RAC maintain consistency?
-Actually, before sending a current mode block LMS process will
request LGWR for a log flush.
- Until LGWR sends a signal back to LMS process, LMS process
will wait on ‘gcs log flush’ event.
- CR block transfer might need log flush if the block was
considered “busy”.
- One of the busy condition is that if the block was constructed by
applying undo records.
cr request retry in some cases means that the message was lost and re-requested... this is tied to interconnect - either udp issues (like truncated udp packets or packets sent out of order), the session was lost on the other node, or the node restarted quickly... could also mean your nic might be flaky or something happening on the switch. If this is a big concern then you'll need to have someone look at the flow on in the interconnects as this is specific to cache fusion.

Oracle RAC 9i LMD library cache lock top wait event

We are experiencing the library cache lock as our top wait event. Even thought the box is currently idle, The Global Enqueue Service Daemon (LMD) is taking up CPU cycles. The background process is also logging to trace "skgxpdocon: warning outstanding accept handle count has reached new high water mark 245000".
Any help would be appreciated.
Thanks

There is a new patch for this - check out p4673610 on metalink. We have also experience the problem in 9.2.0.8.

Wait event PX Deq: reap credit in Oracle 9.2.0.8

Hi,
Can you please explain me what does mean by "PX Deq: reap credit" wait event. My session is waiting on this event. Can you please suggest how to reduce this wait.
Thanks

Hi
oratst@ebsdevdb on /ebdbh/11g/data/cfgtoollogs/dbua/ebstest/upgrade1 # more Upgrade_Directive.log
Connected.
ODMA_DIRECTIVE:VERSION:9.2.0.8
ODMA_DIRECTIVE:MIGRATE_SID:
ODMA_DIRECTIVE:ORA:IGNORE:06512:
ODMA_DIRECTIVE:ORA:FATAL:00600:
ODMA_DIRECTIVE:ORA:FATAL:01012:
ODMA_DIRECTIVE:ORA:FATAL:01031:
ODMA_DIRECTIVE:ORA:FATAL:01034:
ODMA_DIRECTIVE:ORA:FATAL:01078:
ODMA_DIRECTIVE:ORA:FATAL:01092:
ODMA_DIRECTIVE:ORA:FATAL:01109:
ODMA_DIRECTIVE:ORA:FATAL:01119:
ODMA_DIRECTIVE:ORA:FATAL:01507:
ODMA_DIRECTIVE:ORA:FATAL:01722:
ODMA_DIRECTIVE:ORA:FATAL:03113:
ODMA_DIRECTIVE:ORA:FATAL:03114:
ODMA_DIRECTIVE:ORA:FATAL:07445:
ODMA_DIRECTIVE:ORA:FATAL:12560:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01650:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01651:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01652:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01653:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01654:
ODMA_DIRECTIVE:ORA:RECOVER_TBS:01655:
ODMA_DIRECTIVE:ORA:RECOVER_ROLL:01562:
ODMA_DIRECTIVE:ORA:RECOVER_INIT:04031:
ODMA_DIRECTIVE:SCRIPT:UPGRADE:rdbms/admin/catupgrd.sql:
ODMA_DIRECTIVE:BOUNCE_DATABASE:UPGRADE:
ODMA_DIRECTIVE:SCRIPT:UPGRADE:rdbms/admin/catuppst.sql:
ODMA_DIRECTIVE:SCRIPT:UPGRADE:sqlplus/admin/help/hlpbld.sql helpus.sql:
Thanks
With Regards
A-Z

Library Cache Pin Wait Event (within the context of APEX)

Hello,
Firstly -
Oracle Version: 10.2.0.4.0
Apex Version: 3.0.1.00.08
Okay, my colleague (no really! This isn't one of those "Ahem ... A friend of mine has contracted something nasty +downstairs+..."-type questions) is having problems compiling a package (using TOAD incidentally, but it's the same in SQL Developer).
I've searched the forum and the web for a bit of help on what's maybe happening here and it appears to be related to a concurrency conflict with the package definition - from what I can understand it's a case of the package is in use by another session, therefore another session cannot alter it at the same time (which makes sense)
"What does this have to do with APEX?"... well, he is working on this package using the following methodology:
1. Compile the package body/spec (as necessary - body more often obviously)
2. run an apex page which uses the code in a process, which may or may not result in the error page being displayed
3. Making changes to the package body/spec
repeat steps 1-3 ad nauseum...
He is the only user directly accessing the schema (and the only user accessing the page via APEX too, although I appreciate this isn't quite the same thing).
I was wondering if, due to the architecture of APEX (the use of session pools etc), the state of a package might be being retained in some manner, thus resulting in this library cache pin wait event? If so, is there anything I can do to mitigate against this occurring?
p.s. the only difference I can see between this particular package and any other package in the schema is that this one interacts with blobs (including making references to the wwv_flow_files view) - with blobs being passed as parameters between procedures (thus potentially creating temporary blobs which may or may not being closed).
Any ideas?
p.p.s. there are also no DBMS_SCHEDULER jobs or anything that might potentially be running the code incidentally...
Edited by: Joel_C on 11-Nov-2011 11:58
We got our DBAs to run a bit of code to identify the blocking session:
select
         decode(lob.kglobtyp, 0, 'NEXT OBJECT', 1, 'INDEX', 2, 'TABLE', 3, 'CLUSTER',
                      4, 'VIEW', 5, 'SYNONYM', 6, 'SEQUENCE',
                      7, 'PROCEDURE', 8, 'FUNCTION', 9, 'PACKAGE',
                      11, 'PACKAGE BODY', 12, 'TRIGGER',
                      13, 'TYPE', 14, 'TYPE BODY',
                      19, 'TABLE PARTITION', 20, 'INDEX PARTITION', 21, 'LOB',
                      22, 'LIBRARY', 23, 'DIRECTORY', 24, 'QUEUE',
                      28, 'JAVA SOURCE', 29, 'JAVA CLASS', 30, 'JAVA RESOURCE',
                      32, 'INDEXTYPE', 33, 'OPERATOR',
                      34, 'TABLE SUBPARTITION', 35, 'INDEX SUBPARTITION',
                      40, 'LOB PARTITION', 41, 'LOB SUBPARTITION',
                      42, 'MATERIALIZED VIEW',
                      43, 'DIMENSION',
                      44, 'CONTEXT', 46, 'RULE SET', 47, 'RESOURCE PLAN',
                      48, 'CONSUMER GROUP',
                      51, 'SUBSCRIPTION', 52, 'LOCATION',
                      55, 'XML SCHEMA', 56, 'JAVA DATA',
                      57, 'SECURITY PROFILE', 59, 'RULE',
                      62, 'EVALUATION CONTEXT',
                     'UNDEFINED') object_type,
         lob.KGLNAOBJ object_name,
         pn.KGLPNMOD lock_mode_held,
         pn.KGLPNREQ lock_mode_requested,
         ses.sid,
         ses.serial#,
         ses.username
    FROM
       x$kglpn pn,
       v$session ses,
       x$kglob lob,
       v$session_wait vsw
WHERE
   pn.KGLPNUSE = ses.saddr and
   pn.KGLPNHDL = lob.KGLHDADR
   and lob.kglhdadr = vsw.p1raw
   and vsw.event = 'library cache pin'
order by lock_mode_held descresults as follows (I've changed some object names to protect the ignorant):
OBJECT_TYP OBJECT_NAME                   LOCK_MODE_HELD LOCK_MODE_REQUESTED        SID    SERIAL# USERNAME
PACKAGE    PKG_FOOBAR                             2                   0        356      21694 HTMLDB_PUBLIC_U
                                                                                                  SER
PACKAGE    PKG_FOOBAR                             0                   3        463      22309 FOOHTMLDB_PUBLIC_USER is the apex user incidentally. The session is marked in the v$session table as "inactive", the last statement being
Begin
   Dbms_session.reset_package;
End;Edited by: Joel_C on 11-Nov-2011 14:39

bump
No-one?
The problem seems to have 'resolved itself' over the weekend incidentally (although I don't believe anything truly resolves itself in this manner - something must have changed).

Problem identifying db object for "buffer busy waits" event.

10.2.0.3
AIX 64
SELECT username, a.p1text, a.p1, a.p2text, a.p2, a.p3text, a.p3, event FROM v$session a WHERE
a.status='ACTIVE'
AND a.event = 'buffer busy waits'
Query reports about 40 active sessions with this information:
file# 3746
block# 2
class# 13
select
owner,
segment_name,
segment_type
from
dba_extents
where
file_id = 3746
and
2 between block_id and block_id + blocks -1;
no rows returned
SELECT MAX(a.file#) FROM sys.file$ a
3535
This was only a temporary situation when after couple of minutes(7) wait event "buffer busy waits" dissapeared completely.
Any ideas?
Thank you,
Daniel.

http://perfvision.com/papers/06_buffer_cache.ppt
Slide 80-81 points at increasing the size of the initial and next extent for File Header Block buffer busy waits
Side 85 points at high extent allocation for File Header Block buffer busy waits
http://perfvision.com/ftp/hotsos/aas.ppt
Side 55 points at extent allocation too small/too many extents being allocated for File Header Block buffer busy waits
A couple hints from the documentation:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm
"To determine the possible causes [of buffer busy waits], first query V$SESSION to identify the value of ROW_WAIT_OBJ# when the session waits for buffer busy waits."
"To identify the object and object type contended for, query DBA_OBJECTS using the value for ROW_WAIT_OBJ# that is returned from V$SESSION."
"V$SEGMENT_STATISTICS - This is a user-friendly view of statistic values. In addition to all the columns of V$SEGSTAT, it has information about such things as the segment owner and table space name. It makes the statistics easy to understand, but it is more costly."
You may want to query DBA_TEMP_FILES for the specific FILE_ID identified by the V$SESSION. Taking a look at V$SEGMENT_STATISTICS might also be helpful.
Are you using dictionary managed tablespaces, locally managed tablespaces with manual extent size management, ASSM with manual extent size management, or ASSM with automatic extent size management?
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Hash join ending up in huge wait events

Hi,
We are experiencing huge wait events ( direct path read temp , direct path write temp) on our Materialized View refresh in 10.2.0.4 version of oracle 10g in linux rhel5 environment while monitoring the refresh session from db console. While checking the explain plan of the mv query there is a huge hash_join (due to self join nature of the query) is shown. As advised in some dba forums, i have increased my pga_aggregate_target to a value of 4 gb from 1800 mb. The PGA_HIT % is raised to 60% from 58% ( just 2% improvement). But still my direct path read temp and direct path write temp wait event have not reduced and a huge temp space is taken for hash join.
Since we have some usage limit set by some hidden parameters for a each session on pga_aggregate_target, increase the size did not helped me much. The mv refresh is taking more than 5 hours ( sometimes it exceeds 5 hrs) to completes it refresh where as the same query in window (production) is completed less than two hours. Before a month, the refresh time in both environment was nearly close. But now it has changed and not able to figure it out.
STATISTICS have been collected regularly using dbms_gather_stats in both environment. Both mv refresh are scheduled to run using dbms_scheduler (Manual refresh). SGA_TARGET and other memory parameters are almost same.
Environment : Dataware house
O/s : RHEL 5
Oracle version : 10.2.0.4
Work_policy=auto
Is there any possibility to reduce this wait event and there by reducing the elapsed time? I am also interested to know changing the plan to use other sort will help? I don't know whether the details are sufficient to analyze this issue. If you need more details on this just let me know.
I really appreciate your help and thanks in advance to all.

Thans for your comments. Here is the code, explan plan and autotrace trace stat output.
SELECT lasg.employee_number "EMPLOYEE_NUM",
lasg.full_name "FULL_NAME",
lasg.person_id "PERSON_ID",
SUBSTR (lasg.organization, 1, 4) "DEPT",
casg.assign_start_date "EFFECTIVE_START_DATE",
casg.assign_end_date "EFFECTIVE_END_DATE",
hasg.organization "PRIOR_ORG",
casg.organization organization,
hasg.supervisor "PRIOR_SUPERVISOR",
casg.supervisor "SUPERVISOR_NAME",
hasg.location "PRIOR_LOCATION",
casg.location location,
hasg.job_title "PRIOR_TITLE",
casg.job_title job_name,
CASE
WHEN hasg.organization = casg.organization THEN 'No Change'
ELSE 'Change'
END
org_change,
CASE
WHEN hasg.location = casg.location THEN 'No Change'
ELSE 'Change'
END
loc_change,
CASE
WHEN hasg.supervisor = casg.supervisor THEN 'No Change'
ELSE 'Change'
END
sup_change,
CASE
WHEN hasg.job_title = casg.job_title THEN 'No Change'
ELSE 'Change'
END
job_change
FROM panad.data_employ_details lasg,
panad.data_employ_details casg,
panad.data_employ_details hasg
WHERE lasg.person_id = casg.person_id(+)
AND lasg.assign_end_date = (SELECT MAX (lasg2.assign_end_date)
FROM panad.data_employ_details lasg2
WHERE lasg.person_id = lasg2.person_id)
AND casg.person_id = hasg.person_id(+)
AND hasg.assign_start_date =
(SELECT MAX (hasg2.assign_start_date)
FROM panad.data_employ_details hasg2
WHERE hasg2.person_id = lasg.person_id
AND hasg2.assign_end_date < casg.assign_start_date)
| Id | Operation                 | Name                       | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT          |                            |     1 |   303 |       | 10261 (91)| 00:02:04 |
|* 1 | FILTER                   |                            |       |       |       |            |          |
|* 2 |   HASH JOIN               |                            |     1 |   303 |       | 10179 (91)| 00:02:03 |
|* 3 |    HASH JOIN              |                            |     5 | 1060 |       | 10095 (92)| 00:02:02 |
|* 4 |     HASH JOIN             |                            | 6786 |   960K|       | 10011 (93)| 00:02:01 |
|   5 |      VIEW                 | VW_SQ_1                    | 6786 |   225K|       | 9927 (94)| 00:02:00 |
|   6 |       HASH GROUP BY       |                            | 6786 |   384K|       | 9927 (94)| 00:02:00 |
|   7 |        MERGE JOIN         |                            |    50M| 2820M|       | 1427 (53)| 00:00:18 |
|   8 |         SORT JOIN         |                            | 31937 |   998K| 2776K|   367   (2)| 00:00:05 |
|   9 |          TABLE ACCESS FULL| DATA_EMPLOY_DETAILS            | 31937 |   998K|       |    82   (2)| 00:00:01 |
|* 10 |         SORT JOIN         |                            | 31937 |   810K| 2520K|   324   (2)| 00:00:04 |
| 11 |          TABLE ACCESS FULL| DATA_EMPLOY_DETAILS        | 31937 |   810K|       |    82   (2)| 00:00:01 |
| 12 |      TABLE ACCESS FULL    | DATA_EMPLOY_DETAILS        | 31937 | 3461K|       |    83   (3)| 00:00:01 |
| 13 |     TABLE ACCESS FULL     | DATA_EMPLOY_DETAILS        | 31937 | 2089K|       |    83   (3)| 00:00:01 |
| 14 |    TABLE ACCESS FULL      | DATA_EMPLOY_DETAILS        | 31937 | 2838K|       |    83   (3)| 00:00:01 |
| 15 |   SORT AGGREGATE          |                            |     1 |    13 |       |            |          |
|* 16 |    TABLE ACCESS FULL      | DATA_EMPLOY_DETAILS        |     5 |    65 |       |    82   (2)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("LASG"."ASSIGN_END_DATE"= (SELECT MAX("LASG2"."ASSIGN_END_DATE") FROM
              "PANAD"."DATA_EMPLOY_DETAILS" "LASG2" WHERE "LASG2"."PERSON_ID"=:B1))
   2 - access("CASG"."PERSON_ID"="HASG"."PERSON_ID" AND "HASG"."ASSIGN_START_DATE"="VW_COL_1")
   3 - access("LASG"."PERSON_ID"="CASG"."PERSON_ID" AND "PERSON_ID"="LASG"."PERSON_ID")
   4 - access("ROWID"=ROWID)
10 - access(INTERNAL_FUNCTION("HASG2"."ASSIGN_END_DATE")<INTERNAL_FUNCTION("CASG"."ASSIGN_START_DATE")
       filter(INTERNAL_FUNCTION("HASG2"."ASSIGN_END_DATE")<INTERNAL_FUNCTION("CASG"."ASSIGN_START_DATE")
16 - filter("LASG2"."PERSON_ID"=:B1)
37 rows selected.
- autot trace stat output -
5070 rows selected.
Statistics
      35203 recursive calls
          0 db block gets
    3675913 consistent gets
    4269882 physical reads
          0 redo size
    1046781 bytes sent via SQL*Net to client
       4107 bytes received via SQL*Net from client
        339 SQL*Net roundtrips to/from client
         69 sorts (memory)
          0 sorts (disk)
       5070 rows processed   I have tried running this query with paralell but not helped.
I have read the links provided by both of you. Dictionary and fixed table stats are collected as a routine.
From the link given byTaral, Greg Rahn has suggested that it is a bug as below.
Its bug 9041800 and there is a 10.2.0.4 backport available as of 01/29/10.How can i get this bug fixed since there is no explanation of what need to be done? Do i need to contact oracle support for the 10.2.0.4 backport for RHEL5?
Thanks in advance
Edited by: Karthikambalav on Mar 9, 2010 2:43 AM

Can you please tell me how to find top 10 wait events

Hi
Can you please tell me how to find top 10 wait events and what actions need to be taken when there is a wait?
Thanks
Regards,
RJ.

hi,
suggest you to use statspack !!!!!!! for the all tuning..else use the views
* v$session_event
* v$session_wait
* v$system_event
go through this for tuning tips
http://www.dba-oracle.com/art_dbazine_waits.htm
Thanks
--Raman

Redo log wait event

Hi,
in my top evens i've:
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
CPU time 1,894 36.1
log file sync 36,862 1,008 27 19.2 Commit
db file scattered read 165,508 970 6 18.5 User I/O
db file sequential read 196,596 857 4 16.3 User I/O
log file parallel write 35,847 565 16 10.8 System I/O
Log file are on a separate disks, with no activity, only 1 redo per group, and 4 groups.
I think that 27ms for log file synch is high.
I raised commits in sqlloader putting rows=100000 instead 30000 but it's always high.
Which check i can perform?
I'm on AIX 5.3 and database in 10.2.0.4.4

Log File Sync
The “log file sync” wait event is triggered when a user session issues a commit (or a rollback). The user session will signal or post the LGWR to write the log buffer to the redo log file. When the LGWR has finished writing, it will post the user session. The wait is entirely dependent on LGWR to write out the necessary redo blocks and send confirmation of its completion back to the user session. The wait time includes the writing of the log buffer and the post, and is sometimes called “commit latency”.
The P1 parameter in <View:V$SESSION_WAIT> is defined as follows for this wait event:
P1 = buffer#
All changes up to this buffer number (in the log buffer) must be flushed to disk and the writes confirmed to ensure that the transaction is committed and will be kept on an instance crash. The wait is for LGWR to flush up to this buffer#.
Reducing Waits / Wait times:
If a SQL statement is encountering a significant amount of total time for this event, the average wait time should be examined. If the average wait time is low, but the number of waits is high, then the application might be committing after every row, rather than batching COMMITs. Applications can reduce this wait by committing after “n” rows so there are fewer distinct COMMIT operations. Each commit has to be confirmed to make sure the relevant REDO is on disk. Although commits can be "piggybacked" by Oracle, reducing the overall number of commits by batching transactions can be very beneficial.
If the SQL statement is a SELECT statement, review the Oracle Auditing settings. If Auditing is enabled for SELECT statements, Oracle could be spending time writing and commit data to the AUDIT$ table.
If the average time waited is high, then examine the other log related waits for the session, to see where the session is spending most of its time. If a session continues to wait on the same
If the average time waited is high, then examine the other log related waits for the session, to see where the session is spending most of its time. If a session continues to wait on the same buffer# then the SEQ# column of V$SESSION_WAIT should increment every second. If not then the local session has a problem with wait event timeouts. If the SEQ# column is incrementing then the blocking process is the LGWR process. Check to see what LGWR is waiting on as it may be stuck. If the waits are because of slow I/O, then try the following:
Reduce other I/O activity on the disks containing the redo logs, or use dedicated disks.
Try to reduce resource contention. Check the number of transactions (commits + rollbacks) each second, from V$SYSSTAT.
Alternate redo logs on different disks to minimize the effect of the archiver on the log writer.
Move the redo logs to faster disks or a faster I/O subsystem (for example, switch from RAID 5 to RAID 1).
Consider using raw devices (or simulated raw devices provided by disk vendors) to speed up the writes.
See if any activity can safely be done with NOLOGGING / UNRECOVERABLE options in order to reduce the amount of redo being written.
See if any of the processing can use the COMMIT NOWAIT option (be sure to understand the semantics of this before using it).
Check the size of the log buffer as it may be so large that LGWR is writing too many blocks at one time.

A clarification about block# wait event parameter ....

Hi ,
In Oracle Database Reference of 10g (Part Number B14237-02) about the block# wait event parameter is pointed out ... :
This is the block number of the block for which Oracle needs to wait. The block number is relative to the start of the file. To find the object to which this block belongs, enter the following SQL statements:
select name, kind
from ext_to_obj_view
where file# = file#
and lowb <= block#
and highb >= block#;Can you give me a simple example of using the above sql statement.... as ext_to_obj_view object does not exist.....
Many thanks ,
Simon

This view is created by $ORACLE_HOME/rdbms/admin/catclust.sql script (to be run by sys user).
http://download-uk.oracle.com/docs/cd/B19306_01/rac.102/b14197/monitor.htm#RACAD718
Nicolas.

Oracle wait event views

Similar Messages

Maybe you are looking for