Академический Документы
Профессиональный Документы
Культура Документы
Todays Session
Twelve wait event interface enhancements in Oracle 10g that we really like.
Documentation gaps in some areas make this information harder to come by.
We will assume everyone is familiar with wait event concepts and the wait event interface in Oracle 9i or earlier. To learn more about wait events, read: www.dbspecialists.com/presentations.html #wait_events
2
White Paper
Contains additional detail we wont have time to cover today. Includes a handy reference list of all Oracle 10g wait events, wait classes, and wait event parameters. Download: www.dbspecialists.com/presentations
For these waits you had to look at parameter values to learn the wait condition. Oracle 10g gives the most common of these types of waits more descriptive names.
5
latch free
Prior to Oracle 10g: Could indicate a wait on any of dozens of different latches. Oracle 10g: The 26 most common latches have their own wait event.
The rest continue to use the generic latch free wait event.
SQL> SELECT * FROM v$event_name WHERE name = 'latch free'; EVENT# NAME PARAMETER1 PARAMETER2 PARAMETER3 ------ ---------- --------------- --------------- --------------3 latch free address number tries SQL> SELECT name FROM v$latch WHERE latch# = 97; NAME -------------------cache buffers chains
The more descriptive wait event name saves us the effort of decoding wait event parameters.
enqueue
Prior to Oracle 10g: Could indicate a wait on any of a few dozen different types of enqueues. Oracle 10g: 184 distinct wait events replace the one generic enqueue wait event:
Event names differentiate the enqueue type and sometimes even the contention type. Parameter names are more descriptive than generic id1 and id2.
10
12
13
14
15
v$event_name
Three new columns show which wait class a wait event belongs to:
SQL> DESCRIBE v$event_name Name Null? ----------------------------------------- -------EVENT# EVENT_ID NAME PARAMETER1 PARAMETER2 PARAMETER3 WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS Type ------------------NUMBER NUMBER VARCHAR2(64) VARCHAR2(64) VARCHAR2(64) VARCHAR2(64) NUMBER NUMBER VARCHAR2(64)
16
v$sqlarea Example
In session #1:
SQL> UPDATE testtab SET numcol = numcol + 1 WHERE ROWNUM < 1000;
In session #2:
SQL> UPDATE testtab SET numcol = numcol + 1 WHERE ROWNUM < 1000;
In session #1:
SQL> ROLLBACK;
In session #2:
SQL> ROLLBACK;
In session #3:
SQL> UPDATE testtab SET numcol = numcol + 1; 18
v$sqlarea Example
SQL> SELECT sql_id, application_wait_time appl, 2 concurrency_wait_time concurr, user_io_wait_time user_io 3 FROM v$sqlarea 4 WHERE sql_text LIKE 'UPDATE testtab SET numcol%'; SQL_ID APPL CONCURR USER_IO ------------- --------- --------- ----------038m56cp4am0c 178500000 0 20000 fd5mxhdbf09ny 0 10000 105040000 SQL> SELECT sql_id, sql_text 2 FROM v$sqlarea 3 WHERE sql_id IN ('fd5mxhdbf09ny','038m56cp4am0c'); SQL_ID ------------038m56cp4am0c fd5mxhdbf09ny SQL_TEXT ----------------------------------------------------------UPDATE testtab SET numcol = numcol + 1 WHERE ROWNUM < 1000 UPDATE testtab SET numcol = numcol + 1
19
v$session_wait_history
New view in Oracle 10g. Similar to v$session_wait, but shows the last ten wait events for each session. The seq# column is supposed to show the order in which the waits occurred, with 1 being the most recent wait:
Different from seq# in v$session. Does not appear to work as documented (on our 10.1.0.3 system on Solaris).
20
v$session_wait_history
SQL> DESCRIBE v$session_wait_history Name Null? ----------------------------------------- -------SID SEQ# EVENT# EVENT P1TEXT P1 P2TEXT P2 P3TEXT P3 WAIT_TIME WAIT_COUNT Type -------------------------NUMBER NUMBER NUMBER VARCHAR2(64) VARCHAR2(64) NUMBER VARCHAR2(64) NUMBER VARCHAR2(64) NUMBER NUMBER NUMBER
21
v$session_wait_history Example
SQL> 2 3 4 SELECT FROM WHERE ORDER BY sid, seq#, event, wait_time, p1, p2, p3 v$session_wait_history sid = 154 seq#;
SID SEQ# EVENT WAIT_TIME P1 P2 P3 --- ---- ------------------------ ---------- ------ ------ -----154 1 db file sequential read 28 4 3547 1 154 2 log buffer space 18 0 0 0 154 3 log buffer space 36 0 0 0 154 4 db file sequential read 0 4 3559 1 154 5 db file sequential read 0 4 1272 1 154 6 db file sequential read 0 4 3555 1 154 7 log buffer space 9 0 0 0 154 8 db file sequential read 0 4 3551 1 154 9 db file sequential read 6 4 1268 1 154 10 log buffer space 8 0 0 0
22
v$session
All columns from v$session_wait have been added to v$session:
Saves us the effort of joining the two views..
23
v$session Example
Prior to Oracle 10g:
SQL> 2 3 4 5 SELECT s.sid, w.state, w.event, w.seconds_in_wait siw, s.sql_address, s.sql_hash_value hash_value, w.p1, w.p2, w.p3 FROM v$session s, v$session_wait w WHERE s.sid = w.sid AND s.sid = 154;
Oracle 10g:
SQL> SELECT sid, state, event, seconds_in_wait siw, 2 sql_address, sql_hash_value hash_value, p1, p2, p3 3 FROM v$session 4 WHERE sid = 154;
24
Another Example
Why is session 154 waiting? And who is blocking session 154?
SQL> SELECT sid, blocking_session, blocking_session_status block_status, 2 username, event, seconds_in_wait siw 3 FROM v$session 4 WHERE sid = 154; BLOCKING SID _SESSION BLOCK_STATUS USERNAME EVENT SIW --- -------- ------------ -------- ------------------------------ --154 157 VALID TSUTTON enq: TX - row lock contention 318
25
v$event_histogram
New view in Oracle 10g. Shows instance-wide summary wait event statistics like v$system_event, but provides a wait time histogram for each. Buckets:
Less than 1 mS. 1 mS to 2 mS. 2 mS to 4 mS. 4 mS to 8 mS. ... and so on
26
v$event_histogram
SQL> DESCRIBE v$event_histogram Name Null? ----------------------------------------- -------EVENT# EVENT WAIT_TIME_MILLI WAIT_COUNT Type --------------------------NUMBER VARCHAR2(64) NUMBER NUMBER
27
v$event_histogram Example
How significant is the row lock contention on our system?
SQL> SELECT event, total_waits, time_waited, average_wait 2 FROM v$system_event 3 WHERE event = 'enq: TX - row lock contention'; EVENT TOTAL_WAITS TIME_WAITED AVERAGE_WAIT ----------------------------- ----------- ----------- -----------enq: TX - row lock contention 17218 2101966 122
Does the average wait of 1.22 seconds indicated by v$system_event paint an accurate picture?
28
v$event_histogram Example
SQL> SELECT event, wait_time_milli, wait_count 2 FROM v$event_histogram 3 WHERE event = 'enq: TX - row lock contention'; EVENT WAIT_TIME_MILLI WAIT_COUNT ----------------------------- --------------- ---------enq: TX - row lock contention 1 833 enq: TX - row lock contention 2 635 enq: TX - row lock contention 4 372 enq: TX - row lock contention 8 395 enq: TX - row lock contention 16 781 enq: TX - row lock contention 32 3729 enq: TX - row lock contention 64 3050 enq: TX - row lock contention 128 410 enq: TX - row lock contention 256 47 enq: TX - row lock contention 512 46 enq: TX - row lock contention 1024 37 enq: TX - row lock contention 2048 3 enq: TX - row lock contention 4096 6880 29
30
v$system_wait_class Example
SQL> SELECT wait_class, time_waited 2 FROM v$system_wait_class 3 ORDER BY time_waited DESC; WAIT_CLASS TIME_WAITED ------------- ----------Idle 777450022 System I/O 1261584 User I/O 116667 Configuration 116481 Application 72301 Other 12432 Commit 3496 Concurrency 319 Network 1
32
33
34
35
ASH is Always On
You may not have to turn on tracing or begin monitoring v$ views when users report a problem, because ASH is already sampling data. In some cases you may be able to diagnose and resolve a problem on first detection, even if you learn of the problem after the fact.
You may not need to get users to reproduce the problem.
36
Use ASH to view aggregate data on many sessions over a period of time. Dont use ASH to count waits, get maximum wait times, or look at a short time period.
37
ASH Example
SQL> 2 3 4 5 6 7 SELECT DECODE (session_state, 'WAITING', event, NULL) event, session_state, COUNT(*), SUM (time_waited) time_waited FROM v$active_session_history WHERE module = 'ARXENV' AND sample_time > SYSDATE - (2/24) GROUP BY DECODE (session_state, 'WAITING', event, NULL), session_state;
EVENT SESSION_STATE COUNT(*) TIME_WAITED ------------------------------ ------------- -------- ----------ON CPU 124 0 log file sync WAITING 2 52686 db file scattered read WAITING 2 28254 db file sequential read WAITING 1 6059 control file sequential read WAITING 1 9206 SQL*Net break/reset to client WAITING 1 9140 enq: TX - row lock contention WAITING 922 930864016
38
39
AWR Management
Snapshot data is stored in SYS-owned tables in the SYSAUX tablespace. Use dbms_workload_repository to:
Collect a snapshot on demand. Purge snapshots. Adjust snapshot interval. Adjust snapshot retention period. Disable AWR snapshot collection.
40
41
42
43
44
Tracing Improvements
Enabling extended SQL trace in another session is now more convenient. Tracing sessions in a connection pooling or shared server environment is no longer impractical. New dbms_monitor package offers these two benefits and more.
46
47
Tracing sessions in Oracle 10g is easier because dbms_monitor is provided and installed in every Oracle 10g database by default.
48
49
Tracing can be enabled for sessions with specific service / module / action combination:
EXECUTE dbms_application_info.set_module ('module name', 'action name'); EXECUTE dbms_application_info.set_action ('action name');
Trace data split over multiple trace files can be merged into one trace file for TKPROF processing:
$ trcsess output= [clientid=] [service=] [module=] [action=] [session=] 50
Trace the end-user session assigned session_id 12345 in the applications sessions table:
SQL> EXECUTE dbms_monitor.client_id_trace_enable > (client_id=>'12345', waits=>TRUE, binds=>TRUE);
Consolidate trace data into one trace file suitable for use by TKPROF:
$ cd $ORACLE_BASE/admin/$ORACLE_SID/udump $ trcsess output=mytracefile.trc clientid=12345 51
Wrapping Up
Oracle 10g includes many enhancements to the wait event interface that should make performance management using wait event methodologies easier than ever. Some are just conveniences:
More descriptive event names, wait event classes, dbms_monitor.session_trace_enable...
White Paper
Contains additional detail we didnt have time to cover today. Includes a handy reference list of all Oracle 10g wait events, wait classes, and wait event parameters. Download: www.dbspecialists.com/presentations
54
Contact Information
Terry Sutton and Roger Schrag
Database Specialists, Inc. 388 Market Street, Suite 400 San Francisco, CA 94111 Tel: 415/344-0500 Toll-free: 888/648-0500 www.dbspecialists.com tsutton@dbspecialists.com rschrag@dbspecialists.com
55