Reading An Oracle AWR Report PDF
Reading An Oracle AWR Report PDF
Below is one person’s approach to reading an Oracle Automated Workload Repository (AWR) report. It is not intended to be a
complete explanation of all the information contained within the report, just a list of places to start.
(3) CTRL-Click
All of the links in the AWR report are active. You may have to hold down the CTRL key and then click the link
Enjoy,
Ken Gottry
Oct-2013
WORKLOAD REPOSITORY report for
DB Name DB Id Instance Inst num Release RAC Host Comment [K1]:
DSILAPRD 3478342303 DSILAPRD 1 10.2.0.4.0 NO lalvpdsidbla01
HOW BUSY IS YOUR DATABASE SERVER?
Snap Id Snap Time Sessions Cursors/Session
The Operating System Statistics section says
Begin Snap: 26729 19-Oct-12 14:00:08 163 43.8 there are 8 CPU’s.
End Snap: 26731 19-Oct-12 16:00:15 129 42.3
The ELAPSED time for this AWR is 120.11
Elapsed: 120.11 (mins) minutes. Therefore, the total number of available
DB Time: 347.74 (mins) CPU minutes is 960.88.
Block changes: 2,183.15 283.80 UNIT OF WORK (UOW) = Redo Per Trans
Physical reads: 35.54 4.62
How much work is your database doing between
Physical writes: 22.88 2.97 COMMIT calls? An OLTP app typically has a small
User calls: 93.82 12.20 UOW (i.e. issues a COMMIT very often), while a
data load program may have a UOW that is
Parses: 210.84 27.41 controlled by a properties file.
Hard parses: 6.55 0.85
A large UOW means large Redo writes.
Sorts: 351.77 45.73
Logons: 0.26 0.03
Executes: 3,417.24 444.23 Comment [K4]:
Transactions: 7.69
SIZE OF TRANS = Executes Per Trans
% Blocks changed per Read: 1.16 Recursive Call %: 99.07
The Executes Per Transaction tells how many SQL
Rollback per transaction %: 0.34 Rows per Sort: 32.44
calls your app is making inside a transaction. This
example is executing 444 SQL calls for each
transactions.
Instance Efficiency Percentages (Target 100%)
Some people only look at the Transactions Per
Second. But that can be misleading unless you know
Buffer Nowait %: 100.00 Redo NoWait %: 100.00 how many SQLs are executed per transaction.
Buffer Hit %: 99.98 In-memory Sort %: 100.00
Library Hit %: 99.52 Soft Parse %: 96.89
Execute to Parse %: 93.83 Latch Hit %: 99.99
Parse CPU to Parse Elapsd %: 81.80 % Non-Parse CPU: 99.14
Begin End
Comment [K5]:
Memory Usage %: 78.18 76.67
BREAKDOWN OF DB TIME
% SQL with executions>1: 95.12 99.89
% Memory for SQL w/exec>1: 93.43 99.11 At the top it said ELAPSED TIME =120.11 minutes.
During that elapsed time, Oracle was working on
SQL for 347.74 minutes.
Top 5 Timed Events
The 347.74 is DB TIME which is made up of CPU
TIME + I/O TIME + WAIT TIME.
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
This table should show CPU TIME = 70%, I/O
CPU time 14,195 68.0 TIME = 20% and WAIT TIME =10%. This one is
db file sequential read 248,708 4,363 18 20.9 User I/O pretty close.
RMAN backup & recovery I/O 379,510 1,967 5 9.4 System I/O However, whenever I see LOG FILE SYNC in the
log file parallel write 30,944 589 19 2.8 System I/O Top Five I investigate further since this is a stop-the-
world wait.
log file sync 9,854 349 35 1.7 Commit
The Time(s) shows that only 349 seconds were spent
waiting for Writes to the Redo Log . . . but the Avg
Wait was 35ms. That is *extremely* slow. Writes to
Redo should be 4-10ms max. Have your storage
folks look into it
Comment [K6]:
Main Report WHAT NEXT?
Back to Top
Wait Class
s - second
cs - centisecond - 100th of a second
ms - millisecond - 1000th of a second
us - microsecond - 1000000th of a second
ordered by wait time desc, waits desc
Wait Class Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
User I/O 250,820 0.00 4,398 18 4.52
System I/O 465,663 0.00 2,746 6 8.40
Commit 9,854 0.91 349 35 0.18
Other 668 9.13 72 107 0.01
Concurrency 89,198 0.01 62 1 1.61
Configuration 123 36.59 19 151 0.00
Application 1,341 0.22 17 13 0.02
Network 754,112 0.00 6 0 13.60
Administrative 6 0.00 3 482 0.00
Comment [K8]:
Wait Events
WAIT EVENTS
s - second
The list of wait events is sorted by the TOTAL
cs - centisecond - 100th of a second WAIT TIME. So the top wait event could have tons
ms - millisecond - 1000th of a second and tons of waits each one very short, or it could
us - microsecond - 1000000th of a second have a few waits each one very, very long.
ordered by wait time desc, waits desc (idle events last) Be sure to check the AVG WAIT. For I/O waits
(including LOG FILE waits), a reasonable avg wait
time is 4-10ms. This AWR shows very slow I/O.
Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
This could be caused by (a) slow disks; (b) over-
db file sequential read 248,708 0.00 4,363 18 4.49 subscribed disks on a shared storage device; or (c)
tons of SQL that are overwhelming the disks.
RMAN backup & recovery I/O 379,510 0.00 1,967 5 6.85 Remember that each disk has finite limits in terms of
log file parallel write 30,944 0.00 589 19 0.56 MB/sec transfer and I/O per second (IOPS)
log file sync 9,854 0.91 349 35 0.18
control file parallel write 3,902 0.00 107 27 0.07
buffer exterminate 60 95.00 56 939 0.00
Log archive I/O 2,087 0.00 42 20 0.04
latch: library cache 87,074 0.00 41 0 1.57
log file sequential read 2,171 0.00 37 17 0.04
db file scattered read 1,541 0.00 36 23 0.03
enq: UL - contention 35 8.57 17 479 0.00
latch: shared pool 1,751 0.00 17 9 0.03
log buffer space 35 0.00 11 327 0.00
enq: TC - contention 5 60.00 11 2205 0.00
log file switch completion 39 0.00 7 178 0.00
os thread startup 20 5.00 4 209 0.00
latch free 112 0.00 3 31 0.00
SQL*Net more data from client 32,258 0.00 3 0 0.58
switch logfile command 6 0.00 3 482 0.00
control file sequential read 46,914 0.00 3 0 0.85
SQL*Net message to client 690,380 0.00 1 0 12.45
log file single write 40 0.00 1 18 0.00
SQL*Net more data to client 31,433 0.00 1 0 0.57
recovery area: computing obsolete files 3 0.00 1 201 0.00
SQL*Net break/reset to client 1,306 0.00 1 0 0.02
TCP Socket (KGAS) 41 0.00 0 12 0.00
log file switch (private strand flush incomplete) 3 0.00 0 53 0.00
cursor: pin S wait on X 14 85.71 0 9 0.00
enq: CF - contention 4 0.00 0 28 0.00
control file single write 95 0.00 0 1 0.00
library cache load lock 1 0.00 0 85 0.00
db file single write 10 0.00 0 5 0.00
enq: AU - audit index file 3 0.00 0 13 0.00
latch: cache buffers chains 201 0.00 0 0 0.00
latch: session allocation 110 0.00 0 0 0.00
latch: cache buffer handles 59 0.00 0 0 0.00
rdbms ipc reply 33 0.00 0 0 0.00
LGWR wait for redo copy 180 0.00 0 0 0.00
latch: redo allocation 40 0.00 0 0 0.00
latch: cache buffers lru chain 17 0.00 0 0 0.00
latch: library cache pin 16 0.00 0 0 0.00
latch: library cache lock 22 0.00 0 0 0.00
buffer busy waits 66 0.00 0 0 0.00
latch: row cache objects 27 0.00 0 0 0.00
enq: JS - queue lock 1 0.00 0 2 0.00
recovery area: computing backed up files 3 0.00 0 0 0.00
recovery area: computing dropped files 3 0.00 0 0 0.00
direct path read 270 0.00 0 0 0.00
latch: In memory undo latch 6 0.00 0 0 0.00
latch: object queue header operation 13 0.00 0 0 0.00
direct path write 291 0.00 0 0 0.01
recovery area: computing applied logs 3 0.00 0 0 0.00
cursor: pin S 18 0.00 0 0 0.00
undo segment extension 46 97.83 0 0 0.00
buffer deadlock 1 100.00 0 0 0.00
SQL*Net message from client 690,413 0.00 643,405 932 12.45
pipe get 11,876 95.55 49,224 4145 0.21
PL/SQL lock timer 756 97.49 15,608 20645 0.01
jobq slave wait 2,814 93.78 8,087 2874 0.05
wait for unread message on broadcast channel 7,206 99.67 7,036 976 0.13
Streams AQ: waiting for messages in the queue 1,465 98.36 7,035 4802 0.03
Streams AQ: qmn slave idle wait 256 0.00 7,021 27427 0.00
Streams AQ: qmn coordinator idle wait 534 52.06 7,021 13148 0.01
virtual circuit status 240 100.00 7,020 29249 0.00
Streams AQ: waiting for time management or cleanup tasks 12 100.00 3,323 276910 0.00
SGA: MMAN sleep for component shrink 1,356 99.56 15 11 0.02
class slave wait 3 0.00 0 0 0.00
Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
log file parallel write 30,945 0.00 589 19 0.56
control file parallel write 2,561 0.00 93 36 0.05
Log archive I/O 1,920 0.00 42 22 0.03
log file sequential read 1,998 0.00 35 17 0.04
os thread startup 20 5.00 4 209 0.00
log file single write 40 0.00 1 18 0.00
control file sequential read 6,200 0.00 0 0 0.11
latch: shared pool 71 0.00 0 3 0.00
events in waitclass Other 213 0.00 0 0 0.00
direct path read 270 0.00 0 0 0.00
direct path write 269 0.00 0 0 0.00
latch: library cache 3 0.00 0 0 0.00
buffer busy waits 1 0.00 0 0 0.00
rdbms ipc message 48,462 47.11 75,223 1552 0.87
pmon timer 2,534 99.72 7,036 2777 0.05
smon timer 2,267 0.00 7,031 3102 0.04
Streams AQ: qmn slave idle wait 256 0.00 7,021 27427 0.00
Streams AQ: qmn coordinator idle wait 534 52.06 7,021 13148 0.01
Streams AQ: waiting for time management or cleanup tasks 12 100.00 3,323 276910 0.00
SGA: MMAN sleep for component shrink 1,356 99.56 15 11 0.02
Comment [K9]:
Operating System Statistics
Statistic Total Check to be sure the OS has enough CPU.
BUSY_TIME 1,349,404 BUSY TIME is roughly equal to USER_TIME +
IDLE_TIME 4,417,862 SYS_TIME.
IOWAIT_TIME 540,774 TOTAL TIME = BUSY_TIME + IDLE_TIME
NICE_TIME 17 TOTAL TIME = 1.349M + 4.417M
TOTAL TIME = 5.766M
SYS_TIME 72,620
USER_TIME 1,186,273 PCT_BUSY = 1.349M / 5.766M
PCT_BUSY = 23.4%
LOAD 1
RSRC_MGR_CPU_WAIT_TIME 0 No problem there
PHYSICAL_MEMORY_BYTES 84,434,931,712
NUM_CPUS 8
Back to Wait Events Statistics
Back to Top
Service Statistics
ordered by DB Time
Service Name DB Time (s) DB CPU (s) Physical Reads Logical Reads
SYS$USERS 20,544.70 14,094.20 250,969 1,344,457,307
DSILAPRD.latimes.com 319.90 100.40 4,313 6,196,945
DSICTPRDXDB 0.00 0.00 0 0
SYS$BACKGROUND 0.00 0.00 892 61,661
User I/O Total User I/O Wt Concurcy Total Concurcy Wt Admin Total Admin Wt Network Total Network Wt
Service Name
Wts Time Wts Time Wts Time Wts Time
SYS$USERS 245332 429175 86789 4672 6 289 712789 235
DSILAPRD.latimes.com 4321 9386 1793 798 0 0 34180 58
SYS$BACKGROUND 1175 1287 157 589 0 0 0 0
SQL Statistics
SQL ordered by Elapsed Time
SQL ordered by CPU Time
SQL ordered by Gets
SQL ordered by Reads
SQL ordered by Executions
SQL ordered by Parse Calls
SQL ordered by Sharable Memory
SQL ordered by Version Count
Complete List of SQL Text
Comment [K10]:
SQL ordered by Elapsed Time This section does not necessarily help you identify
SQL that needs to be tuned. This section lists SQL
that are consuming the most time. That could be a
Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code. SQL that is very, very fast, but executed many, many
% Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100 times.
CPU Time (s) Elapsed Time (s) Executions CPU per Exec (s) % Total DB Time SQL Id SQL Module SQL Text
2,553 2,561 24,608 0.10 12.27 05gwz57k7fwsj SELECT /*+ ORDERED use_nl(subs...
1,207 1,684 53 22.77 8.07 3p6uywr76z4k5 dsi.exe BEGIN :rc := SECURITY....
Comment [K13]:
1,046 1,222 1 1045.74 5.86 gw1v6y00jz3nr DECLARE job BINARY_INTEGER := ...
949 949 1 948.95 4.55 35andu44s5fa0 DECLARE job BINARY_INTEGER := ... TOTAL CPU vs. CPU PER EXEC
716 857 1 715.89 4.11 5t1ygvubzndkc dsi.exe BEGIN circ.addr_subacct.route_...
Just as with Elapsed time, this report shows SQL that
643 643 24,608 0.03 3.08 289s3yd6cpfnp SELECT /*+ ORDERED */ COUNT(DI... used the most total CPU. That could be a SQL that
was executed many, many times and used only a
542 742 1 542.30 3.56 45uuqtn59j3ud dsi.exe SELECT "CIRC"."SUBSCRIPTION"...
little CPU each time; or, it could be a SQL that was
532 533 1 532.02 2.56 ckr8g65hugaw6 DECLARE job BINARY_INTEGER := ... executed only a few times but used a ton of CPU
each time.
530 806 1 529.60 3.86 bxps4dnmcfjfg DECLARE job BINARY_INTEGER := ...
524 525 1 523.88 2.52 7cm2x28dxag54 DECLARE job BINARY_INTEGER := ... Be sure to check the EXECUTIONS column as well
as the CPU PER EXEC column
516 518 1 515.82 2.48 7n61jwpjr71y2 DECLARE job BINARY_INTEGER := ...
503 509 1 503.03 2.44 1cnp1zyhy47xz DECLARE job BINARY_INTEGER := ... Comment [K14]:
393 410 9,805 0.04 1.97 765aawdsphw03 SELECT P.PACKAGE_NUMBER, P.RE... FULL SQL TEXT
355 355 2,186 0.16 1.70 cq0x2jabc4381 SELECT /*+ ORDERED use_nl(subs...
Oracle assigns a unique SQL_ID to each SQL
308 435 2,292,706 0.00 2.08 2sswh0d43wuf1 dsi.exe SELECT 'Y' FROM DUAL WHERE EXI... executed. This section of the report shows the first
264 390 2 132.08 1.87 1nmk3m3sxw19z dsi.exe BEGIN circ.subs_import.p_subs_... few characters of the SQL. Click on the SQL_ID to
jump to the full SQL text.
240 240 0 1.15 cffrqk300fnyq DECLARE job BINARY_INTEGER := ...
151 562 1 151.38 2.69 bu96mupzvbwfr DECLARE job BINARY_INTEGER := ...
145 551 1 145.34 2.64 d7nvkq43z6hms SELECT SYMBOL SYMBOL, ACCOUNT ...
41 290 3,573 0.01 1.39 10mu2x59guzwv dsi.exe SELECT "CIRC"."VW_SUBS_TRANS...
37 441 1 37.31 2.11 8w4hmwfhwp424 dsi.exe BEGIN CIRC.VW_SUBS_REF...
35 428 1 34.78 2.05 bkuqb8h4q6dh6 dsi.exe SELECT SUB.ACCOUNT, TRANS_DAT...
23 730 1 22.58 3.50 6qq9dagrs5h0h DECLARE job BINARY_INTEGER := ...
23 730 1 22.55 3.50 7tz40fck7szkg SELECT ALIAS_ACCT_SET ALIAS_AC...
17 287 5 3.43 1.38 8m8dvp0k4vjah SELECT /*+ ORDERED USE_NL(TR)...
16 347 586 0.03 1.66 2g0jhucv8bu3g JDBC Thin Client SELECT PAPER_CODE, PROD_CODE,...
5 333 578 0.01 1.59 gpsgysttf8ccd JDBC Thin Client SELECT /*+ ordered use_nl(sb s...
Comment [K15]:
SQL ordered by Gets
TOTAL BUFFER GETS vs. GETS PER EXEC
Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code. Just as with Elapsed Time and CPU Time, this report
Total Buffer Gets: 1,350,535,281 shows SQL that has the most total buffer gets. That
Captured SQL account for 96.3% of Total could be a SQL executed many, many times doing
very few buffer gets each time; or, it could be a SQL
that is executed very few times doing many, many
Buffer Gets Executions Gets per Exec %Total CPU Time (s) Elapsed Time (s) SQL Id SQL Module SQL Text buffer gets each time.
388,210,841 24,608 15,775.80 28.74 2553.05 2560.52 05gwz57k7fwsj SELECT /*+ ORDERED use_nl(subs... Buffer Gets (also called Logical Reads) means the
291,205,396 24,608 11,833.77 21.56 643.17 643.30 289s3yd6cpfnp SELECT /*+ ORDERED */ COUNT(DI... data is already in the data buffer cache and Oracle is
trying to locate the rows that match the WHERE
283,950,995 9,805 28,959.82 21.03 393.06 410.23 765aawdsphw03 SELECT P.PACKAGE_NUMBER, P.RE... clause.
171,471,143 1 171,471,143.00 12.70 948.95 949.48 35andu44s5fa0 DECLARE job BINARY_INTEGER := ...
There is no absolute “bad” number of buffer gets per
105,857,445 1 105,857,445.00 7.84 529.60 806.36 bxps4dnmcfjfg DECLARE job BINARY_INTEGER := ... execution. You need to observe your database over
104,838,358 1 104,838,358.00 7.76 532.02 533.50 ckr8g65hugaw6 DECLARE job BINARY_INTEGER := ... time to understand what “normal” is.
104,178,684 1 104,178,684.00 7.71 523.88 524.80 7cm2x28dxag54 DECLARE job BINARY_INTEGER := ... Here you see many DECLARE jobs doing 100+M
103,463,651 1 103,463,651.00 7.66 515.82 517.63 7n61jwpjr71y2 DECLARE job BINARY_INTEGER := ... buffer gets each time they execute compared to some
SELECT statements that only do 15K.
103,182,036 1 103,182,036.00 7.64 503.03 508.59 1cnp1zyhy47xz DECLARE job BINARY_INTEGER := ...
86,872,917 1 86,872,917.00 6.43 1045.74 1222.23 gw1v6y00jz3nr DECLARE job BINARY_INTEGER := ... A high number of Buffer Gets means two things: (1)
Oracle is working very hard to locate the matching
84,093,045 53 1,586,661.23 6.23 1206.59 1684.48 3p6uywr76z4k5 dsi.exe BEGIN :rc := SECURITY....
rows because of an unrestrictive WHERE clause or
78,251,817 1 78,251,817.00 5.79 115.59 138.84 170543cbhcvym DECLARE job BINARY_INTEGER := ... bad/missing indexes; and (2) high CPU since Oracle
counts the time it’s doing Buffer Gets as CPU time.
69,061,779 1 69,061,779.00 5.11 101.21 104.17 36qb1g0hqc3fg DECLARE job BINARY_INTEGER := ...
69,054,279 1 69,054,279.00 5.11 104.72 107.25 fsk6ay4dx9s6h DECLARE job BINARY_INTEGER := ...
68,763,798 1 68,763,798.00 5.09 103.26 107.12 78kumj80fb9zb DECLARE job BINARY_INTEGER := ...
62,451,992 2,186 28,569.07 4.62 355.28 355.41 cq0x2jabc4381 SELECT /*+ ORDERED use_nl(subs...
50,793,616 0 3.76 239.68 239.92 cffrqk300fnyq DECLARE job BINARY_INTEGER := ...
48,769,911 1 48,769,911.00 3.61 715.89 856.86 5t1ygvubzndkc dsi.exe BEGIN circ.addr_subacct.route_...
28,593,817 1 28,593,817.00 2.12 148.60 149.60 6pb91u7mf42zn DECLARE job BINARY_INTEGER := ...
25,366,375 1 25,366,375.00 1.88 542.30 741.99 45uuqtn59j3ud dsi.exe SELECT "CIRC"."SUBSCRIPTION"...
25,237,492 2,292,706 11.01 1.87 307.93 434.82 2sswh0d43wuf1 dsi.exe SELECT 'Y' FROM DUAL WHERE EXI...
25,126,395 1 25,126,395.00 1.86 151.38 562.05 bu96mupzvbwfr DECLARE job BINARY_INTEGER := ...
25,125,985 1 25,125,985.00 1.86 145.34 550.95 d7nvkq43z6hms SELECT SYMBOL SYMBOL, ACCOUNT ...
22,441,652 2,320,607 9.67 1.66 156.57 164.46 2hxytnmbzauvn dsi.exe SELECT CANDIDATE.ROUTE, OFFIC...
22,017,442 1,196,040 18.41 1.63 109.37 109.39 gr2dmtaxwkdnw JDBC Thin Client SELECT /*+ ORDERED */ QUANTITY...
14,403,106 1 14,403,106.00 1.07 37.31 440.67 8w4hmwfhwp424 dsi.exe BEGIN CIRC.VW_SUBS_REF...
14,260,555 1 14,260,555.00 1.06 34.78 427.90 bkuqb8h4q6dh6 dsi.exe SELECT SUB.ACCOUNT, TRANS_DAT...
13,782,952 2 6,891,476.00 1.02 264.17 390.00 1nmk3m3sxw19z dsi.exe BEGIN circ.subs_import.p_subs_...
13,650,051 1,832 7,450.90 1.01 131.96 138.97 3h0x8xtj70fjc dsi.exe UPDATE CAR_ADJ_IMPORT SET ADJ_...
30,382 1 30,382.00 11.86 37.31 440.67 8w4hmwfhwp424 dsi.exe BEGIN CIRC.VW_SUBS_REF... Therefore, a SQL that has a high number of physical
29,629 1 29,629.00 11.57 34.78 427.90 bkuqb8h4q6dh6 dsi.exe SELECT SUB.ACCOUNT, reads may not be bad in itself; it may just be the
TRANS_DAT... victim of some other SQL continually flushing its
data from cache.
25,460 1 25,460.00 9.94 151.38 562.05 bu96mupzvbwfr DECLARE job BINARY_INTEGER := ...
25,455 1 25,455.00 9.94 145.34 550.95 d7nvkq43z6hms SELECT SYMBOL SYMBOL, ACCOUNT
...
19,757 1 19,757.00 7.71 529.60 806.36 bxps4dnmcfjfg DECLARE job BINARY_INTEGER := ...
19,063 5 3,812.60 7.44 17.15 287.33 8m8dvp0k4vjah SELECT /*+ ORDERED USE_NL(TR)...
13,122 1 13,122.00 5.12 12.92 155.17 atuyvvkdmac3r dsi.exe BEGIN circ.subs_update2.collec...
12,564 1 12,564.00 4.90 7.24 139.55 b51y11a59mnv4 dsi.exe SELECT /*+ ORDERED USE_NL(st s...
12,427 586 21.21 4.85 16.15 347.36 2g0jhucv8bu3g JDBC Thin Client SELECT PAPER_CODE,
PROD_CODE,...
12,401 1 12,401.00 4.84 542.30 741.99 45uuqtn59j3ud dsi.exe SELECT "CIRC"."SUBSCRIPTION"...
12,383 578 21.42 4.83 4.55 332.76 gpsgysttf8ccd JDBC Thin Client SELECT /*+ ordered use_nl(sb s...
11,385 1 11,385.00 4.44 715.89 856.86 5t1ygvubzndkc dsi.exe BEGIN circ.addr_subacct.route_...
10,859 2,292,706 0.00 4.24 307.93 434.82 2sswh0d43wuf1 dsi.exe SELECT 'Y' FROM DUAL WHERE EXI...
10,849 1 10,849.00 4.24 1045.74 1222.23 gw1v6y00jz3nr DECLARE job BINARY_INTEGER := ...
9,476 24,062 0.39 3.70 19.32 158.96 8797a0njtpq3a pmdtm@tco-chi-rpt02 (TNS SELECT SEARCH_ORDER , 1 PRIOR...
V1-V3)
8,406 3,573 2.35 3.28 40.89 289.58 10mu2x59guzwv dsi.exe SELECT "CIRC"."VW_SUBS_TRANS...
7,361 2 3,680.50 2.87 264.17 390.00 1nmk3m3sxw19z dsi.exe BEGIN circ.subs_import.p_subs_...
7,035 723,142 0.01 2.75 84.39 171.59 0gvx8axq0dzwn pmdtm@tco-chi-rpt02 (TNS SELECT * FROM ADDR.VW_ADDRESS
V1-V3) ...
6,590 11 599.09 2.57 23.57 95.72 ffj33x2dmzm9b dsi.exe BEGIN :rc := CIRC.CAR_...
5,973 1,826 3.27 2.33 18.15 71.57 8tuf99gkdch9w dsi.exe SELECT UNALLOCATED FROM
VW_CAR...
5,479 143,095 0.04 2.14 23.53 99.66 1dghy6xv4u06f JDBC Thin Client SELECT TRANS_TYPE FROM
CIRC.VW...
3,249 1 3,249.00 1.27 101.73 154.91 dbvnxxq1hhdks SELECT /*+ ORDERED use_nl(SUBS...
3,195 699,175 0.00 1.25 65.17 105.89 2xf37ww4bsn2g JDBC Thin Client SELECT :B2 , :B1 , ROUTE.ROU...
Parse Calls Executions % Total Parses SQL Id SQL Module SQL Text
32,406 37,601 2.13 b8w84823hu0wj JDBC Thin Client UPDATE CIRC.SUBS_TRANS SET PAY...
18,066 122,870 1.19 g7x5fztkgc17y w3wp.exe SELECT PUBLICATION FROM CIRC.S...
17,981 380,584 1.18 7dpyfc02bm1qv SELECT PREF_ID, ITEM_DEFAULT,...
17,535 31,539 1.15 cz5t28pns876y dsi.exe SELECT SUB_TYPE FROM SUBSCRIPT...
17,339 17,339 1.14 f2a45dk38dgsy dsi.exe select count ( *) from securit...
17,129 124,968 1.13 d8fjjcd2tffhq w3wp.exe SELECT AMOUNT, TRANS_NUM, TR...
16,870 160,689 1.11 4g1a88zy33xv4 w3wp.exe SELECT PREF_ID, NVL(ITEM_VALU...
16,757 41,171 1.10 bxq23315z6a83 w3wp.exe SELECT PUB_PRODUCT_PAPER FROM ...
16,590 37,999 1.09 1n19tc89cp9gr w3wp.exe SELECT RATE_TABLE FROM VW_SUBS...
16,490 154,422 1.09 7jm2qf63sv9an w3wp.exe SELECT LAST_ACTIVITY, STATUS_...
16,194 18,694 1.07 c77mttrapwf2u JDBC Thin Client SELECT PUBLICATION, BILL_THRU...
16,160 23,003 1.06 3xq1sdy4r74fk JDBC Thin Client SELECT TO_TYPE FROM CIRC.SUBS_...
16,157 19,924 1.06 94njvpfz1bf83 JDBC Thin Client SELECT * FROM CIRC.DRAW_DEADLI...
16,155 18,653 1.06 98cdstump8aj1 JDBC Thin Client SELECT TRANS_NUM FROM CIRC.SUB...
16,150 19,294 1.06 amm826hmmyn07 JDBC Thin Client SELECT ST.TRANS_NUM, TRANS_DA...
16,115 18,614 1.06 594580p45718x JDBC Thin Client SELECT BILL_THRU_DATE FROM CIR...
16,115 18,614 1.06 bsd05wzbuy311 JDBC Thin Client SELECT TRANS_NUM, TRANS_DATE ...
16,071 19,635 1.06 0zzjmxz77kmba w3wp.exe SELECT SEQ_SUBS_TRANS.NEXTVAL ...
16,052 143,095 1.06 1dghy6xv4u06f JDBC Thin Client SELECT TRANS_TYPE FROM CIRC.VW...
16,006 1,243,725 1.05 6jypkct4xhs5p w3wp.exe SELECT * FROM PRODUCT_CODE WHE...
15,973 16,376 1.05 b0qwwsy6sqj7p SELECT TRANS_NUM, TRANS_DATE,...
15,965 15,992 1.05 a92vk52x0dmh8 SELECT MAX(LAST_DATE) MAX_DATE...
15,945 1,182,881 1.05 96c4ubpu90b9h w3wp.exe SELECT PUB_PRODUCT_PAPER FROM ...
15,908 1,196,040 1.05 gr2dmtaxwkdnw JDBC Thin Client SELECT /*+ ORDERED */ QUANTITY...
Sharable Mem (b) Executions % Total SQL Id SQL Module SQL Text
10,655,648 0.04 ammbbygjc57du BEGIN circ_rpt.vw_new_...
4,751,544 0.02 cz792q0h80y79 BEGIN CIRC_RPT.VW_NEW_...
3,343,704 0.01 f3fymkzj5jf5k BEGIN CIRC.VW_SUBS_TRA...
2,399,166 1 0.01 7tz40fck7szkg SELECT ALIAS_ACCT_SET ALIAS_AC...
1,175,196 13 0.00 4xw8ur39h4z5v dsi.exe SELECT C_FUNCT."IDX", ...
1,118,290 8 0.00 21vy7rp5r5xzh dsi.exe BEGIN CIRC.VW_SUBS_TRA...
1,070,299 89 0.00 3x1uz4svp4yx0 dsi.exe BEGIN CIRC.VW_SUBS_TRA...
1,064,893 24 0.00 dtty0ch031ntx dsi.exe BEGIN CIRC.VW_SUBS_TRA...
Back to Top
Comment [K18]:
Instance Activity Stats
I usually use this section to investigate issues I’ve
Statistic Total per Second per Trans
uncovered in other sections.
CPU used by this session 863,108 119.77 15.57
I typically focus on PER TRANS, locate high values
CPU used when call started 304,338 42.23 5.49 I don’t understand, Google the name of the Statistic,
CR blocks created 63,746 8.85 1.15 then talk to the developer.
Cached Commit SCN referenced 3,442 0.48 0.06
Commit SCN cached 2 0.00 0.00
DB time 9,660,305 1,340.47 174.26
DBWR checkpoint buffers written 152,213 21.12 2.75
DBWR checkpoints 12 0.00 0.00
DBWR object drop buffers written 0 0.00 0.00
DBWR revisited being-written buffer 0 0.00 0.00
DBWR tablespace checkpoint buffers written 5,486 0.76 0.10
DBWR thread checkpoint buffers written 146,727 20.36 2.65
DBWR transaction table writes 46 0.01 0.00
DBWR undo block writes 88,623 12.30 1.60
IMU CR rollbacks 1,883 0.26 0.03
IMU Flushes 15,500 2.15 0.28
IMU Redo allocation size 125,623,828 17,431.69 2,266.06
IMU commits 37,803 5.25 0.68
IMU contention 96 0.01 0.00
IMU ktichg flush 1,049 0.15 0.02
IMU pool not allocated 4,375 0.61 0.08
IMU recursive-transaction flush 11 0.00 0.00
IMU undo allocation size 227,964,872 31,632.63 4,112.14
IMU- failed to get a private strand 4,375 0.61 0.08
Misses for writing mapping 0 0.00 0.00
SMON posted for undo segment recovery 0 0.00 0.00
SMON posted for undo segment shrink 4 0.00 0.00
SQL*Net roundtrips to/from client 684,208 94.94 12.34
active txn count during cleanout 78,002 10.82 1.41
application wait time 1,735 0.24 0.03
background checkpoints completed 10 0.00 0.00
background checkpoints started 10 0.00 0.00
background timeouts 23,044 3.20 0.42
branch node splits 2 0.00 0.00
buffer is not pinned count 719,966,750 99,903.29 12,987.12
buffer is pinned count 1,930,024,782 267,812.13 34,814.74
bytes received via SQL*Net from client 170,514,106 23,660.70 3,075.82
bytes sent via SQL*Net to client 339,840,403 47,156.59 6,130.21
calls to get snapshot scn: kcmgss 25,016,928 3,471.37 451.27
calls to kcmgas 317,037 43.99 5.72
calls to kcmgcs 28,913 4.01 0.52
change write time 4,788 0.66 0.09
cleanout - number of ktugct calls 70,373 9.77 1.27
cleanouts and rollbacks - consistent read gets 54,647 7.58 0.99
cleanouts only - consistent read gets 627 0.09 0.01
cluster key scan block gets 1,120,880 155.53 20.22
cluster key scans 682,859 94.75 12.32
commit batch performed 0 0.00 0.00
commit batch requested 0 0.00 0.00
commit batch/immediate performed 278 0.04 0.01
commit batch/immediate requested 278 0.04 0.01
commit cleanout failures: block lost 7,515 1.04 0.14
commit cleanout failures: buffer being written 1 0.00 0.00
commit cleanout failures: callback failure 142 0.02 0.00
commit cleanout failures: cannot pin 14 0.00 0.00
commit cleanouts 248,613 34.50 4.48
commit cleanouts successfully completed 240,941 33.43 4.35
commit immediate performed 278 0.04 0.01
commit immediate requested 278 0.04 0.01
commit txn count during cleanout 33,187 4.61 0.60
concurrency wait time 6,058 0.84 0.11
consistent changes 938,311 130.20 16.93
consistent gets 1,336,750,200 185,488.77 24,112.96 Comment [K19]:
consistent gets - examination 909,200,981 126,161.62 16,400.62
CONSISTENT GETS
consistent gets direct 0 0.00 0.00
consistent gets from cache 1,336,750,172 185,488.76 24,112.96 I won’t try to explain the concept here, but anyone
who uses Oracle should Google and fully understand
current blocks converted for CR 0 0.00 0.00 this term
cursor authentications 56,966 7.90 1.03
data blocks consistent reads - undo records applied 830,039 115.18 14.97
db block changes 15,733,174 2,183.15 283.80
db block gets 13,784,365 1,912.73 248.65
db block gets direct 132 0.02 0.00
db block gets from cache 13,784,233 1,912.71 248.65
deferred (CURRENT) block cleanout applications 108,202 15.01 1.95
dirty buffers inspected 5 0.00 0.00
enqueue conversions 4,373 0.61 0.08
enqueue deadlocks 0 0.00 0.00
enqueue releases 404,440 56.12 7.30
enqueue requests 404,556 56.14 7.30
enqueue timeouts 161 0.02 0.00
enqueue waits 42 0.01 0.00
exchange deadlocks 1 0.00 0.00
execute count 24,626,830 3,417.24 444.23 Comment [K20]:
failed probes on index block reclamation 19 0.00 0.00
EXECUTE COUNT
frame signature mismatch 0 0.00 0.00
free buffer inspected 167,154 23.19 3.02 This tells the number of SQL executed during one
transaction. Here, the application executes 444 SQL
free buffer requested 568,865 78.94 10.26 within a transaction. That sounds like a lot. I’d talk
heap block compress 627,052 87.01 11.31 to the developer to understand why.
hot buffers moved to head of LRU 288,712 40.06 5.21 One cause of a high number is when an application
immediate (CR) block cleanout applications 55,274 7.67 1.00 developed for a mom-n-pop shop is deployed in an
enterprise environment. The data model has
immediate (CURRENT) block cleanout applications 32,937 4.57 0.59 hundreds of tables with no relationship defined
index crx upgrade (found) 29 0.00 0.00 between the tables.
index crx upgrade (positioned) 4,232,989 587.37 76.36 If the app needs data from 3 different tables, it does a
index fast full scans (full) 5,587 0.78 0.10 SELECT against one table, then iterates across the
result set, using each value in a WHERE clause to
index fetch by key 415,282,885 57,625.06 7,491.08 find the rest of the data. In an enterprise data model
index scans kdiixs1 56,163,384 7,793.29 1,013.10 and well-written app, this is all done in the database
with a JOIN statement.
java call heap collected bytes 6,275,568 870.80 113.20
java call heap collected count 66,147 9.18 1.19 This app may have been an MS-ACCESS program
that someone tried to deploy to IIS and Oracle.
java call heap gc count 67 0.01 0.00
java call heap live object count 7,243 1.01 0.13
java call heap live object count max 7,475 1.04 0.13
java call heap live size 1,671,280 231.91 30.15
java call heap live size max 2,068,728 287.06 37.32
java call heap object count 12,885 1.79 0.23
java call heap object count max 15,711 2.18 0.28
java call heap total size 3,284,480 455.76 59.25
java call heap total size max 3,284,480 455.76 59.25
java call heap used size 2,235,616 310.22 40.33
java call heap used size max 2,741,488 380.41 49.45
leaf node 90-10 splits 498 0.07 0.01
leaf node splits 2,426 0.34 0.04
lob reads 66 0.01 0.00
lob writes 593 0.08 0.01
lob writes unaligned 593 0.08 0.01
logons cumulative 1,901 0.26 0.03
messages received 34,240 4.75 0.62
messages sent 34,240 4.75 0.62
no buffer to keep pinned count 0 0.00 0.00
no work - consistent read gets 422,313,987 58,600.70 7,617.91
opened cursors cumulative 1,382,258 191.80 24.93
parse count (failures) 47 0.01 0.00
parse count (hard) 47,206 6.55 0.85
parse count (total) 1,519,434 210.84 27.41
parse time cpu 12,276 1.70 0.22
parse time elapsed 15,008 2.08 0.27
physical read IO requests 249,047 34.56 4.49
physical read bytes 2,098,405,376 291,176.78 37,852.07
physical read total IO requests 617,225 85.65 11.13
physical read total bytes ############### 23,989,606.00 3,118,573.92
physical read total multi block requests 320,922 44.53 5.79
physical reads 256,153 35.54 4.62
physical reads cache 255,883 35.51 4.62
physical reads cache prefetch 7,106 0.99 0.13
physical reads direct 270 0.04 0.00
physical reads direct (lob) 0 0.00 0.00
physical reads direct temporary tablespace 0 0.00 0.00
physical reads prefetch warmup 0 0.00 0.00
physical write IO requests 115,721 16.06 2.09
physical write bytes 1,350,664,192 187,419.48 24,363.95
physical write total IO requests 218,186 30.28 3.94
physical write total bytes 74,101,667,840 10,282,419.92 1,336,682.50
physical write total multi block requests 139,655 19.38 2.52
physical writes 164,876 22.88 2.97
physical writes direct 402 0.06 0.01
physical writes direct (lob) 78 0.01 0.00
physical writes direct temporary tablespace 0 0.00 0.00
physical writes from cache 164,474 22.82 2.97
physical writes non checkpoint 123,947 17.20 2.24
pinned buffers inspected 2,374 0.33 0.04
prefetch warmup blocks aged out before use 0 0.00 0.00
prefetched blocks aged out before use 0 0.00 0.00
process last non-idle time 7,557 1.05 0.14
recovery blocks read 0 0.00 0.00
recursive aborts on index block reclamation 0 0.00 0.00
recursive calls 72,287,769 10,030.72 1,303.96
recursive cpu usage 804,185 111.59 14.51
redo blocks read for recovery 0 0.00 0.00
redo blocks written 4,034,910 559.89 72.78
redo buffer allocation retries 66 0.01 0.00
redo entries 7,672,118 1,064.59 138.39
redo log space requests 43 0.01 0.00
redo log space wait time 730 0.10 0.01
redo ordering marks 502 0.07 0.01
redo size 1,967,022,396 272,945.95 35,482.12
redo synch time 35,693 4.95 0.64
redo synch writes 9,756 1.35 0.18
redo wastage 8,349,664 1,158.61 150.62
redo write time 60,340 8.37 1.09
redo writer latching time 0 0.00 0.00
redo writes 30,944 4.29 0.56
rollback changes - undo records applied 666,950 92.55 12.03
rollbacks only - consistent read gets 9,117 1.27 0.16
rows fetched via callback 70,182,228 9,738.55 1,265.98
session connect time 0 0.00 0.00
session cursor cache hits 251,725 34.93 4.54
session logical reads 1,350,535,281 187,401.60 24,361.62
session pga memory 161,176,960 22,365.07 2,907.39
session pga memory max 34,707,559,168 4,816,054.86 626,072.10
session uga memory ############### 110,823,137.47 14,406,662.03
session uga memory max 5,009,905,608 695,179.40 90,371.15
shared hash latch upgrades - no wait 14,426,416 2,001.82 260.23
shared hash latch upgrades - wait 32 0.00 0.00
sorts (disk) 0 0.00 0.00
sorts (memory) 2,535,107 351.77 45.73
sorts (rows) 82,227,635 11,409.99 1,483.26
sql area evicted 90,408 12.55 1.63
sql area purged 58 0.01 0.00
summed dirty queue length 5 0.00 0.00
switch current to new buffer 171,277 23.77 3.09
table fetch by rowid 1,108,167,338 153,770.38 19,989.67
table fetch continued row 1,964,982 272.66 35.45
table scan blocks gotten 18,539,180 2,572.51 334.42
table scan rows gotten 2,460,052,446 341,359.28 44,375.64
table scans (cache partitions) 0 0.00 0.00
table scans (long tables) 1 0.00 0.00
table scans (short tables) 262,413 36.41 4.73
total number of times SMON posted 2,267 0.31 0.04
transaction rollbacks 278 0.04 0.01
transaction tables consistent read rollbacks 4 0.00 0.00
transaction tables consistent reads - undo records applied 2,700 0.37 0.05
undo change vector size 688,501,420 95,537.13 12,419.53
user I/O wait time 439,800 61.03 7.93
user calls 676,148 93.82 12.20
user commits 55,250 7.67 1.00
user rollbacks 187 0.03 0.00
workarea executions - onepass 0 0.00 0.00
workarea executions - optimal 1,732,719 240.43 31.26
write clones created in background 0 0.00 0.00
write clones created in foreground 83 0.01 0.00
IO Stats
Tablespace IO Stats
File IO Stats
Back to Top
Tablespace IO Stats
ordered by IOs (Reads + Writes) desc
Tablespace Reads Av Reads/s Av Rd(ms) Av Blks/Rd Writes Av Writes/s Buffer Waits Av Buf Wt(ms)
CIRC 208,322 29 20.95 1.03 59,038 8 28 0.36 Comment [K21]:
UNDOTBS1 18 0 8.89 1.00 51,679 7 33 0.00
DISK I/O TIME
ADDR 34,317 5 19.16 1.04 881 0 0 0.00
SECURITY 1,702 0 24.08 1.00 985 0 0 0.00 Av Rd (ms) tells how long a physical disk takes
while Av Buf Wt (ms) tells how long an average
CRONACLE_INDEX 856 0 24.38 1.00 1,268 0 0 0.00 physical disk write takes.
SYSTEM 1,964 0 8.27 1.01 138 0 4 0.00
3-4ms is very good, 4-10ms is OK, over 10 usually
SYSAUX 625 0 21.95 1.07 1,416 0 0 0.00 means you need to talk to your storage team to
USER_DATA 891 0 0.18 1.00 18 0 0 0.00 understand why it’s so slow.
CRONACLE 275 0 27.82 1.00 201 0 1 0.00 READ TIME is much more important than WRITE
TEMPORARY_DATA 20 0 34.00 1.00 23 0 0 0.00 TIME. Reads occur synchronously while Oracle is
processing your SQL. Writes occur asynchronously
DSI 16 0 23.13 1.00 10 0 0 0.00 in the background when Oracle decides it’s time to
PAPERTRAK 12 0 35.00 1.00 11 0 0 0.00 write the changed data to disk.
USER_INDEX01 10 0 115.00 1.00 11 0 0 0.00 When the number of READS or WRITES is very
ADV 10 0 68.00 1.00 10 0 0 0.00 low, I tend to see much higher read-time and write-
time. Not sure why.
CASH 10 0 2.00 1.00 10 0 0 0.00
CLIENT 10 0 1.00 1.00 10 0 0 0.00 CIRC is the busiest tablespace for reads and each
read takes 20.95ms. Talk to the storage team
RBBIG 10 0 59.00 1.00 10 0 0 0.00
Back to IO Stats
Back to Top
File IO Stats
ordered by Tablespace, File
Av Av Av Av Buffer Av Buf
Tablespace Filename Reads Writes
Reads/s Rd(ms) Blks/Rd Writes/s Waits Wt(ms)
ADDR /oracle/oradata/data1/DSILAPRD/addr_DSILAPRD.dbf 34,317 5 19.16 1.04 881 0 0 0.00
ADV /oracle/oradata/data1/DSILAPRD/adv_DSILAPRD.dbf 10 0 68.00 1.00 10 0 0 0.00
CASH /oracle/oradata/data1/DSILAPRD/cash_DSILAPRD.dbf 10 0 2.00 1.00 10 0 0 0.00
CIRC /oracle/oradata/data2/DSILAPRD/circ_DSILAPRD.dbf 52,848 7 17.07 1.01 16,610 2 4 2.50 Comment [K22]:
CIRC /oracle/oradata/data2/DSILAPRD/circ_DSILAPRD_02.dbf 24,951 3 22.99 1.02 5,404 1 6 0.00
FILE I/O vs. TABLESPACE I/O
CIRC /oracle/oradata/data2/DSILAPRD/circ_DSILAPRD_03.dbf 17,799 2 27.65 1.04 4,355 1 0 0.00
CIRC /oracle/oradata/data2/DSILAPRD/circ_DSILAPRD_04.dbf 20,712 3 21.05 1.03 6,620 1 0 0.00 The previous section showed that the CIRC
tablespace had the most I/O and it was slow read I/O.
CIRC /oracle/oradata/data2/DSILAPRD/circ_DSILAPRD_05.dbf 18,561 3 18.74 1.05 4,675 1 0 0.00 This section lists all of the files in the CIRC
CIRC /oracle/oradata/data2/DSILAPRD/circ_DSILAPRD_06.dbf 21,868 3 18.07 1.03 6,439 1 0 0.00 tablespace.
CIRC /oracle/oradata/data2/DSILAPRD/circ_DSILAPRD_07.dbf 18,311 3 24.67 1.03 6,613 1 17 0.00 The number of READS against each of the files is
CIRC /oracle/oradata/data2/DSILAPRD/circ_DSILAPRD_08.dbf 19,191 3 26.88 1.03 4,314 1 1 0.00 about equal and the slowness is about the same. 17-
27ms is well above the acceptable 3-10ms range.
CIRC /oracle/oradata/data2/DSILAPRD/circ_DSILAPRD_09.dbf 14,081 2 17.73 1.04 4,008 1 0 0.00
CLIENT /oracle/oradata/data1/DSILAPRD/client_DSILAPRD.dbf 10 0 1.00 1.00 10 0 0 0.00 The AV READS/S shows that not many I/O’s are
executed so the slowness is likely not caused by the
CRONACLE /oracle/oradata/data2/DSILAPRD/cronacle_01.dbf 275 0 27.82 1.00 201 0 1 0.00 disks being overwhelmed with work . . . unless all
CRONACLE_INDEX /oracle/oradata/data2/DSILAPRD/cronacle_index_01.dbf 856 0 24.38 1.00 1,268 0 0 0.00 the files are on the same physical disk.
DSI /oracle/oradata/data1/DSILAPRD/dsi_DSILAPRD.dbf 16 0 23.13 1.00 10 0 0 0.00
PAPERTRAK /oracle/oradata/data1/DSILAPRD/papertrak_DSILAPRD.db 12 0 35.00 1.00 11 0 0 0.00
RBBIG /oracle/oradata/data2/DSILAPRD/rbbig_DSILAPRD.dbf 10 0 59.00 1.00 10 0 0 0.00
SECURITY /oracle/oradata/data1/DSILAPRD/security_DSILAPRD.dbf 630 0 29.87 1.00 203 0 0 0.00
SECURITY /oracle/oradata/data1/DSILAPRD/security_DSILAPRD_02. 224 0 20.98 1.00 167 0 0 0.00
SECURITY /oracle/oradata/data1/DSILAPRD/security_DSILAPRD_03. 522 0 20.33 1.00 460 0 0 0.00
SECURITY /oracle/oradata/data1/DSILAPRD/security_DSILAPRD_04. 326 0 21.04 1.00 155 0 0 0.00
SYSAUX /oracle/oradata/data1/DSILAPRD/sysaux_DSILAPRD01.dbf 625 0 21.95 1.07 1,416 0 0 0.00
SYSTEM /oracle/oradata/data1/DSILAPRD/sys_DSILAPRD01.dbf 1,964 0 8.27 1.01 138 0 4 0.00
TEMPORARY_DATA /oracle/oradata/data3/DSILAPRD/tmp_DSILAPRD01.dbf 20 0 34.00 1.00 23 0 0
UNDOTBS1 /oracle/oradata/data1/DSILAPRD/undo_DSILAPRD01.dbf 18 0 8.89 1.00 51,679 7 33 0.00
USER_DATA /oracle/oradata/data1/DSILAPRD/usr_DSILAPRD01.dbf 891 0 0.18 1.00 18 0 0 0.00
USER_INDEX01 /oracle/oradata/data2/DSILAPRD/user_index01_01.dbf 10 0 115.00 1.00 11 0 0 0.00
Back to IO Stats
Back to Top
P Number of Buffers Pool Hit% Buffer Gets Physical Reads Physical Writes Free Buff Wait Writ Comp Wait Buffer Busy Waits
D 2,553,542 100 1,350,336,573 255,882 164,474 0 0 66
Back to Top
Advisory Statistics
Instance Recovery Stats
Buffer Pool Advisory
PGA Aggr Summary
PGA Aggr Target Stats
PGA Aggr Target Histogram
PGA Memory Advisory
Shared Pool Advisory
SGA Target Advisory
Streams Pool Advisory
Java Pool Advisory
Back to Top
Targt MTTR Estd MTTR Recovery Estd Actual Redo Target Redo Log File Size Redo Log Ckpt Timeout Redo Log Ckpt Interval Redo
(s) (s) IOs Blks Blks Blks Blks Blks
B 0 0 47182 612238 610879 3225600 610879
E 0 0 31034 572561 572558 3225600 572558
P Size for Est (M) Size Factor Buffers for Estimate Est Phys Read Factor Estimated Physical Reads
D 2,064 0.10 255,291 4.73 2,873,929,011
D 4,128 0.20 510,582 4.02 2,442,440,276
Comment [K23]:
D 6,192 0.30 765,873 3.40 2,064,113,432
D 8,256 0.40 1,021,164 2.86 1,738,914,254 BUFFER POOL ADVISORY
D 10,320 0.50 1,276,455 2.41 1,461,738,107 Learn to use this type of table. Oracle uses it quite
D 12,384 0.60 1,531,746 2.02 1,227,198,858 often to help you quickly do the math.
D 14,448 0.70 1,787,037 1.69 1,029,611,375 Start by looking for the row with SIZE
D 16,512 0.80 2,042,328 1.42 863,978,027 FACTOR=1.00. This is your current sizing. It shows
that you have 2,562,805 buffers. With this number of
D 18,576 0.90 2,297,619 1.19 725,904,025 buffers and with the SQL activity captured here,
D 20,640 1.00 2,552,910 1.01 611,221,139 Oracle estimates that you’ll do 607,478,644 physical
reads.
D 20,720 1.00 2,562,805 1.00 607,478,644
D 22,704 1.10 2,808,201 0.85 516,040,017 Now we can make the buffer size smaller (moving
up the table) or larger (moving down the table).
D 24,768 1.20 3,063,492 0.72 436,817,441
D 26,832 1.30 3,318,783 0.61 370,363,374
Comment [K24]:
D 28,896 1.39 3,574,074 0.52 313,811,181
INCREASING BUFFER POOL
D 30,960 1.49 3,829,365 0.44 264,577,469
D 33,024 1.59 4,084,656 0.36 220,350,494 Let’s say we want to increase the buffer pool to
reduce the number of physical reads. What would
D 35,088 1.69 4,339,947 0.29 179,171,670
happen if we increased the buffer pool by 20%?
D 37,152 1.79 4,595,238 0.23 139,546,813
That would move us from the SIZE FACTOR line of
D 39,216 1.89 4,850,529 0.17 100,515,813
1.00 to the SIZE FACTOR line of 1.20.
D 41,280 1.99 5,105,820 0.10 61,609,412
The table shows that Oracle estimates the number of
physical reads will now be 436,817,441.
Back to Advisory Statistics
Back to Top But Oracle also does the math for you in the EST
PHYS READ FACTOR column. The value 0.72
means the number of physical reads will be 72% of
PGA Aggr Summary what they were with the current settings.
PGA Aggr Target(M) Auto PGA Target(M) PGA Mem Alloc(M) W/A PGA Used(M) %PGA W/A Mem %Auto W/A Mem %Man W/A Mem Global Mem Bound(K)
B 5,120 3,900 1,104.26 77.13 6.99 100.00 0.00 524,280
E 5,120 4,098 756.06 0.19 0.02 100.00 0.00 524,280
Low Optimal High Optimal Total Execs Optimal Execs 1-Pass Execs M-Pass Execs
2K 4K 1,675,649 1,675,649 0 0
64K 128K 17,140 17,140 0 0
128K 256K 12,534 12,534 0 0
256K 512K 4,665 4,665 0 0
512K 1024K 19,238 19,238 0 0
1M 2M 3,381 3,381 0 0
2M 4M 72 72 0 0
4M 8M 8 8 0 0
8M 16M 23 23 0 0
16M 32M 16 16 0 0
32M 64M 2 2 0 0
64M 128M 4 4 0 0
256M 512M 1 1 0 0
PGA Target Est (MB) Size Factr W/A MB Processed Estd Extra W/A MB Read/ Written to Disk Estd PGA Cache Hit % Estd PGA Overalloc Count
640 0.13 16,762,274.40 8,002,042.91 68.00 40,955
1,280 0.25 16,762,274.40 6,354,079.82 73.00 29
2,560 0.50 16,762,274.40 5,109,432.73 77.00 0
3,840 0.75 16,762,274.40 2,127,493.01 89.00 0
5,120 1.00 16,762,274.40 864,664.35 95.00 0 Comment [K25]:
6,144 1.20 16,762,274.40 721,732.29 96.00 0
PGA MEMORY ADVISORY
7,168 1.40 16,762,274.40 690,906.90 96.00 0
8,192 1.60 16,762,274.40 690,329.70 96.00 0 This table is similar to the Buffer Pool Advisory
table above.
9,216 1.80 16,762,274.40 690,329.70 96.00 0
10,240 2.00 16,762,274.40 689,897.58 96.00 0 The SIZE FACTOR 1.00 row shows the current
setting. It shows you’re getting 95.00% cache hit. As
15,360 3.00 16,762,274.40 676,865.67 96.00 0 you move down the table (i.e. increasing PGA), the
20,480 4.00 16,762,274.40 599,733.23 97.00 0 cache hit ratio doesn’t go up much at all.
30,720 6.00 16,762,274.40 580,478.48 97.00 0 Oracle is telling you that with the current SQL
40,960 8.00 16,762,274.40 507,674.88 97.00 0 workload and the current SQL tuning, you will not
get any better cache hit ratio by adjusting PGA
memory.
Back to Advisory Statistics
Back to Top
Shared Pool SP Size Est LC Size Est LC Mem Est LC Time Saved Est LC Time Saved Est LC Load Time Est LC Load Time Est LC Mem Obj
Size(M) Factr (M) Obj (s) Factr (s) Factr Hits
13,760 0.60 2,385 531,003 1,146,254,045 0.53 1,026,284,484 763.57 2,854,750,650
16,064 0.70 4,707 725,851 2,732,344,865 1.26 3,735,160,960 2779.02 16,451,255
18,368 0.80 7,042 946,642 4,089,252,247 1.88 2,378,253,578 1769.46 1,845,982,775
20,672 0.90 9,377 1,166,992 4,014,106,615 1.85 2,453,399,210 1825.37 3,185,247
22,976 1.00 11,712 1,388,195 2,171,194,472 1.00 1,344,057 1.00 64,738,013
25,280 1.10 14,047 1,610,200 3,010,150,094 1.39 1 0.00 146,055,729
27,584 1.20 16,383 1,831,471 365,713,243 0.17 1 0.00 234,311,779
29,888 1.30 18,718 2,052,999 3,873,644,003 1.78 1 0.00 371,151,121
32,192 1.40 21,053 2,276,600 1,461,117,307 0.67 1 0.00 3,185,251
34,496 1.50 23,388 2,494,773 3,733,181,392 1.72 1 0.00 20,554,395
36,800 1.60 25,723 2,715,820 3,702,460,107 1.71 1 0.00 58,296,950
39,104 1.70 28,058 2,935,949 3,994,391,245 1.84 1 0.00 162,476,521
41,408 1.80 30,393 3,156,743 1,050,891,283 0.48 1 0.00 122,430,879
43,712 1.90 32,728 3,379,123 2,161,568,614 1.00 1 0.00 30,538,819
46,016 2.00 35,063 3,598,986 1,182,289,372 0.54 1 0.00 24,856,198
Wait Statistics
Buffer Wait Statistics
Enqueue Activity
Back to Top
Enqueue Activity
only enqueues with waits are shown
Enqueue stats gathered prior to 10g should not be compared with 10g data
ordered by Wait Time desc, Waits desc
Enqueue Type (Request Reason) Requests Succ Gets Failed Gets Waits Wt Time (s) Av Wt Time(ms) Comment [K26]:
UL-User-defined 1,526 1,506 20 32 17 536.88
ENQUEUE WAIT TIME
TC-Tablespace Checkpoint 6 6 0 2 11 5,645.00
CF-Controlfile Transaction 5,591 5,591 0 4 0 27.50 The list is ordered by TOTAL enqueue wait time
which could be many, many waits each very, very
AU-Audit index file (audit index file) 15 15 0 3 0 16.67 short or very, very few waits each very, very long.
JS-Job Scheduler (queue lock) 27,016 27,016 0 1 0 0.00
Look at the AV WT TIME column
Comment [K27]:
Back to Wait Statistics
Back to Top
ENQUEUES
Back to Top
Undo TS# Num Undo Blocks (K) Number of Transactions Max Qry Len (s) Max Tx Concurcy Min/Max TR (mins) STO/ OOS uS/uR/uU/ eS/eR/eU
1 90.22 78,408 2,476 6 0/180 0/0 0/0/0/0/0/0
End Time Num Undo Blocks Number of Transactions Max Qry Len (s) Max Tx Concy Tun Ret (mins) STO/ OOS uS/uR/uU/ eS/eR/eU Comment [K28]:
19-Oct 16:08 1,605 1,344 1,161 4 180 0/0 0/0/0/0/0/0
DISTRIBUTION OF WORKLOAD
19-Oct 15:58 5,602 1,558 560 4 180 0/0 0/0/0/0/0/0
19-Oct 15:48 1,696 12,323 2,108 4 180 0/0 0/0/0/0/0/0 This AWR aggregates work over the 2-hour snapshot
interval. That often masks some values.
19-Oct 15:38 6,309 5,596 1,509 5 180 0/0 0/0/0/0/0/0
19-Oct 15:28 2,939 1,593 1,594 4 180 0/0 0/0/0/0/0/0 This table shows the number of transactions
executed every 10 minutes. Based on this table,
19-Oct 15:18 2,065 1,507 1,691 4 180 0/0 0/0/0/0/0/0 consider running ASH reports for 15:38 for 10
19-Oct 15:08 8,792 9,588 1,091 6 180 0/0 0/0/0/0/0/0 minutes and 14:38 for 10 minutes to drill deeper into
the heavy periods.
19-Oct 14:58 4,667 1,966 1,771 6 180 0/0 0/0/0/0/0/0
19-Oct 14:48 8,857 22,813 1,168 5 180 0/0 0/0/0/0/0/0
19-Oct 14:38 2,859 1,526 2,476 4 180 0/0 0/0/0/0/0/0
19-Oct 14:28 2,711 8,964 1,631 6 180 0/0 0/0/0/0/0/0
19-Oct 14:18 39,337 7,275 2,311 4 180 0/0 0/0/0/0/0/0
19-Oct 14:08 2,780 2,355 1,710 4 180 0/0 0/0/0/0/0/0
22-Oct 14:20 0 0 0 0 0 0/0 0/0/0/0/0/0
Latch Statistics
Latch Activity
Latch Sleep Breakdown
Latch Miss Sources
Parent Latch Statistics
Child Latch Statistics
Back to Top
Comment [K29]:
Latch Activity
LATCHES
"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for willing-to-wait latch get requests I use this table to help investigate issues I may have
"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests found elsewhere in the report
"Pct Misses" for both should be very close to 0.0
Latch Name Get Requests Pct Get Miss Avg Slps /Miss Wait Time (s) NoWait Requests Pct NoWait Miss
ASM db client latch 4,790 0.00 0 0
AWR Alerted Metric Element list 55,573 0.00 0 0
Consistent RBA 30,966 0.03 0.00 0 0
FAL request queue 164 0.00 0 0
FAL subheap alocation 164 0.00 0 0
FIB s.o chain latch 2,064 0.00 0 0
FOB s.o list latch 18,925 0.01 0.00 0 0
In memory undo latch 502,185 0.00 0.75 0 60,659 0.00
JOX SGA heap latch 235 0.00 0 0
JS Sh mem access 38 2.63 1.00 0 0
JS mem alloc latch 67 0.00 0 0
JS queue access latch 67 0.00 0 0
JS queue state obj latch 54,032 0.00 0 0
JS slv state obj latch 190 0.00 0 0
KMG MMAN ready and startup request latch 3,751 0.00 0 0
KMG resize request state object freelist 36 0.00 0 0
KTF sga latch 24 0.00 0 2,033 0.00
KWQMN job cache list latch 12 0.00 0 0
MQL Tracking Latch 0 0 144 0.00
Memory Management Latch 1,722 0.00 0 3,751 0.00
OS process 5,367 0.00 0 0
OS process allocation 5,946 0.00 0 0
OS process: request allocation 3,468 0.00 0 0
PL/SQL warning settings 173,242 0.00 0 0
SGA IO buffer pool latch 2,986 0.00 0 4,944 0.00
SQL memory manager latch 2 0.00 0 2,371 0.00
SQL memory manager workarea list latch 592,400 0.00 0.00 0 0
Shared B-Tree 268 0.00 0 0
X$KSFQP 105 0.00 0 0
active checkpoint queue latch 4,175 0.00 0 0
active service list 24,183 0.01 0.50 0 2,534 0.00
archive control 1,085 0.00 0 0
archive process latch 2,721 0.00 0 0
begin backup scn array 92 0.00 0 0
buffer pool 465 0.00 0 0
cache buffer handles 28,322,589 0.01 0.03 0 0
cache buffers chains 1,826,155,838 0.00 0.01 0 968,875 0.01
cache buffers lru chain 846,144 0.05 0.04 0 791,831 0.04
cache table scan latch 0 0 1,541 0.00
channel handle pool latch 5,754 0.03 0.00 0 0
channel operations parent latch 65,584 0.04 0.00 0 0
checkpoint queue latch 531,257 0.00 0.00 0 274,224 0.00
client/application info 35,476 0.00 0 0
compile environment latch 1,901 0.00 0 0
dml lock allocation 330,739 0.00 0.00 0 0
dummy allocation 3,836 0.00 0 0
enqueue hash chains 813,590 0.00 0.00 0 804 0.00
enqueues 393,194 0.00 0.20 0 0
event group latch 1,717 0.00 0 0
file cache latch 963 0.00 0 0
global KZLD latch for mem in SGA 1,669 0.00 0 0
hash table column usage latch 1,056 0.00 0 1,201,515 0.00
hash table modification latch 235 0.00 0 0
job workq parent latch 0 0 372 0.00
job_queue_processes parameter latch 296 0.00 0 0
kks stats 274,924 0.02 0.02 0 0
kokc descriptor allocation latch 130 0.00 0 0
krbmrosl 1,181 0.00 0 0
ksuosstats global area 484 0.00 0 0
ktm global data 2,275 0.00 0 0
kwqbsn:qsga 268 0.00 0 0
lgwr LWN SCN 31,136 0.00 0 0
library cache 21,380,071 0.55 0.74 41 248,932 11.69
library cache load lock 1,640 0.00 0 0
library cache lock 7,811,237 0.00 0.06 0 0
library cache lock allocation 61,553 0.00 0 0
library cache pin 9,147,874 0.00 0.04 0 0
library cache pin allocation 126,450 0.00 0 0
list of block allocation 11,360 0.00 0 0
loader state object freelist 2,362 0.00 0 0
longop free list parent 5,198 0.00 0 34 0.00
message pool operations parent latch 4,530 0.07 0.00 0 0
messages 145,429 0.00 0.00 0 0
mostly latch-free SCN 31,209 0.02 0.00 0 0
multiblock read objects 6,548 0.00 0 0
ncodef allocation latch 127 0.00 0 0
object queue header heap 21,075 0.00 0 4,518 0.00
object queue header operation 1,570,891 0.00 0.19 0 127,472 0.00
object stats modification 4,446 0.00 0 0
parallel query alloc buffer 952 0.00 0 0
parameter list 3,733 0.00 0 0
parameter table allocation management 2,007 0.10 0.50 0 0
post/wait queue 16,250 0.00 0 9,938 0.00
process allocation 3,468 0.12 1.00 0 1,717 0.00
process group creation 3,468 0.00 0 0
qmn task queue latch 1,024 0.00 0 0
redo allocation 7,853,975 0.06 0.01 0 0
redo copy 0 0 7,672,177 0.00
redo writing 101,840 0.00 0.00 0 0
row cache objects 16,686,586 0.02 0.01 0 0
sequence cache 290,957 0.00 0 0
session allocation 9,652,191 0.17 0.01 0 0
session idle bit 1,435,812 0.00 0.00 0 0
session state list latch 7,606 0.00 0 0
session switching 127 0.00 0 0
session timer 2,533 0.00 0 0
shared pool 3,365,665 0.05 1.12 17 0
shared pool simulator 21,965,836 0.01 0.07 3 0
simulator hash latch 99,751,220 0.00 0.01 0 0
simulator lru latch 167,525 0.37 0.00 0 99,539,572 0.12
slave class 4 0.00 0 0
slave class create 16 0.00 0 0
sort extent pool 15,810 0.13 0.33 0 0
state object free list 4 0.00 0 0
statistics aggregation 1,120 0.00 0 0
temp lob duration state obj allocation 5 0.00 0 0
temporary table state object allocation 2,210 0.00 0 0
threshold alerts latch 1,005 0.00 0 0
transaction allocation 503,605 0.00 0 0
transaction branch allocation 2,533 0.00 0 0
undo global data 515,822 0.00 0 0
user lock 7,570 0.00 0 0
Back to Latch Statistics
Back to Top
Latch Name Get Requests Misses Sleeps Spin Gets Sleep1 Sleep2 Sleep3
library cache 21,380,071 117,929 87,074 35,827 0 0 0
session allocation 9,652,191 16,072 110 15,971 0 0 0
cache buffers chains 1,826,155,838 13,965 201 13,775 0 0 0
redo allocation 7,853,975 4,985 40 4,947 0 0 0
row cache objects 16,686,586 2,953 27 2,927 0 0 0
cache buffer handles 28,322,589 2,198 59 2,140 0 0 0
shared pool 3,365,665 1,570 1,751 1,001 0 0 0
shared pool simulator 21,965,836 1,241 82 1,162 0 0 0
simulator hash latch 99,751,220 860 12 849 0 0 0
simulator lru latch 167,525 622 1 621 0 0 0
cache buffers lru chain 846,144 451 17 435 0 0 0
library cache pin 9,147,874 387 16 372 0 0 0
library cache lock 7,811,237 348 22 326 0 0 0
object queue header operation 1,570,891 70 13 58 0 0 0
kks stats 274,924 58 1 57 0 0 0
sort extent pool 15,810 21 7 14 0 0 0
enqueues 393,194 10 2 8 0 0 0
In memory undo latch 502,185 8 6 2 0 0 0
process allocation 3,468 4 4 0 0 0 0
active service list 24,183 2 1 1 0 0 0
parameter table allocation management 2,007 2 1 1 0 0 0
JS Sh mem access 38 1 1 0 0 0 0
Segment Statistics
Segments by Logical Reads
Segments by Physical Reads
Segments by Row Lock Waits
Segments by ITL Waits
Segments by Buffer Busy Waits
Back to Top
Comment [K30]:
Segments by Logical Reads
WHAT ARE THE HOTTEST TABLES /
INDEXES?
Total Logical Reads: 1,350,535,281
Captured Segments account for 94.4% of Total Logical Reads means the data is in the buffer.
Physical Reads means the data has to be retrieved
from disk first.
Owner Tablespace Name Object Name Subobject Name Obj. Type Logical Reads %Total
There are no absolute right or wrong values. Learn
CIRC CIRC PK_ADDRESS_SUBACCT INDEX 282,630,576 20.93 your app and become alert when you see values that
CIRC CIRC PK_INS_PACKAGE_ROUTE INDEX 278,597,472 20.63 are different than normal.
CIRC CIRC ADDRESS_SUBACCT TABLE 147,463,152 10.92 If you see high Logical Reads is often means the
CIRC CIRC PK_SUBSCRIBTION_NEW INDEX 75,337,424 5.58 WHERE clause isn’t restrictive enough so Oracle
has to hunt for your matching data.
CIRC CIRC IDX_SUBS_TRANS_ACCT_TYPE_VALID INDEX 42,018,112 3.11
Typically you’ll see TABLE in these segment
statistics. If you see INDEX, check the
Back to Segment Statistics characteristics of the index
Back to Top (DBA_IND_STATISTICS) to see why Oracle is
working so hard to find the index records.
Segments by Physical Reads Remember, Oracle first finds the Index records and
then uses that information to find the data records. If
you’re doing a ton of read against an Index, that will
Total Physical Reads: 256,153 often translate into tons and tons of reads against
Captured Segments account for 62.3% of Total data tables.
Owner Tablespace Name Object Name Subobject Name Obj. Type Row Lock Waits % of Capture
SECURITY SECURITY PK_JOB_LOG INDEX 109 12.88
CIRC CIRC IDX_SUBS_TRANS_TYPE_ACCT_VALID INDEX 68 8.04
SECURITY SECURITY IDX_JOB_LOG_DTL_JOB_ID INDEX 64 7.57
CIRC CIRC IDX_TRUCK_MAN_DTYPE_SESS_RT INDEX 62 7.33
CIRC CIRC IDX_SUBS_TRANS_ENTRYDATE INDEX 60 7.09
Owner Tablespace Name Object Name Subobject Name Obj. Type ITL Waits % of Capture
CIRC CIRC PK_TRUCK_MANIFEST INDEX 9 28.13
CIRC CIRC IDX_TRUCK_MAN_DTYPE_SESS_RT INDEX 6 18.75
SECURITY SECURITY IDX_JOB_LOG_DTL_JOB_ID INDEX 5 15.63
CIRC CIRC IDX_SUBS_IMPORT2_SEARCH INDEX 4 12.50
CIRC CIRC IDX_TRUCK_MANIFEST_SESSRTEPKG INDEX 4 12.50
Owner Tablespace Name Object Name Subobject Name Obj. Type Buffer Busy Waits % of Capture
CIRC CIRC SUBS_TRANS TABLE 5 35.71
CIRC CIRC PK_SUBS_TRANS INDEX 4 28.57
CIRC CIRC IDX_SUBS_TRANS_ACCT_TYPE_VALID INDEX 2 14.29
CIRC CIRC PK_SUBSCRIBTION_NEW INDEX 1 7.14
SYSJCS CRONACLE RWS_JOB$ TABLE 1 7.14
Cache Get Requests Pct Miss Scan Reqs Pct Miss Mod Reqs Final Usage
dc_awr_control 130 0.00 0 4 1
dc_database_links 3,369 0.00 0 0 1
dc_files 5,292 0.00 0 0 27
dc_global_oids 10,839 0.00 0 0 213
dc_histogram_data 274,271 0.00 0 0 7,502
dc_histogram_defs 88,995 0.03 0 0 14,838
dc_object_grants 477,972 0.00 0 0 2,443
dc_object_ids 1,017,405 0.00 0 0 4,765
dc_objects 272,450 0.01 0 38 5,035
dc_profiles 3,734 0.00 0 0 6
dc_rollback_segments 18,472 0.00 0 0 258
dc_segments 111,660 0.00 0 5 4,372
dc_sequences 15,277 0.01 0 15,277 120
dc_tablespace_quotas 1 0.00 0 0 4
dc_tablespaces 974,265 0.00 0 0 19
dc_usernames 13,980 0.00 0 0 345
dc_users 2,931,028 0.00 0 0 809
outstanding_alerts 436 0.00 0 0 35
Back to Top
Namespace Get Requests Pct Miss Pin Requests Pct Miss Reloads Invali- dations
BODY 7,466 0.05 1,507,490 0.00 60 0
CLUSTER 47 0.00 69 0.00 0 0
INDEX 18 0.00 52 1.92 1 0
JAVA DATA 5 0.00 0 0 0
JAVA RESOURCE 5 0.00 80 0.00 0 0
PIPE 4,772 0.00 5,156 0.00 0 0
SQL AREA 158,789 1.29 25,262,177 0.57 46,106 23,006
TABLE/PROCEDURE 16,463 0.18 2,645,431 0.03 719 0
TRIGGER 4,368 0.14 609,510 0.00 24 0
Back to Top
Memory Statistics
Process Memory Summary
SGA Memory Summary
SGA breakdown difference
Back to Top
Category Alloc (MB) Used (MB) Avg Alloc (MB) Std Dev Alloc (MB) Max Alloc (MB) Hist Max Alloc (MB) Num Proc Num Alloc
B Other 851.60 5.16 4.17 28 79 165 165
Freeable 130.25 0.00 0.92 0.57 6 142 142
SQL 101.00 88.71 0.66 6.24 78 574 154 152
PL/SQL 12.82 5.54 0.08 0.04 0 1 163 163
JAVA 8.67 8.64 1.08 0.44 1 2 8 7
E Other 612.21 4.67 3.68 22 73 131 131
Freeable 109.06 0.00 0.98 1.06 11 111 111
SQL 18.52 9.18 0.15 0.08 0 490 120 118
PL/SQL 10.04 4.31 0.08 0.04 0 1 129 129
JAVA 6.29 6.26 1.05 0.52 1 2 6 5
Streams Statistics
Streams CPU/IO Usage
Streams Capture
Streams Apply
Buffered Queues
Buffered Subscribers
Rule Set
Back to Top
Streams Capture
No data exists for this section of the report.
Streams Apply
No data exists for this section of the report.
Buffered Queues
No data exists for this section of the report.
Buffered Subscribers
No data exists for this section of the report.
Back to Streams Statistics
Back to Top
Rule Set
No data exists for this section of the report.
Back to Top
init.ora Parameters
End value (if
Parameter Name Begin value
different)
O7_DICTIONARY_ACCESSIBILITY TRUE
audit_file_dest /oracle/admin/DSILAPRD/adump
audit_sys_operations TRUE
audit_trail XML
background_dump_dest /oracle/admin/DSILAPRD/bdump
compatible 10.2.0.3.0
control_files /oracle/oradata/data1/DSILAPRD/ctl_DSILAPRD01.ctl, /oracle/oradata/data2/DSILAPRD/ctl_DSILAPRD02.ctl,
/oracle/oradata/data3/DSILAPRD/ctl_DSILAPRD03.ctl, /oracle/oradata/data1/DSILAPRD/ctl_DSILAPRD04.ctl
core_dump_dest /oracle/admin/DSILAPRD/cdump
db_block_size 8192
db_cache_size 9663676416
db_domain latimes.com
db_file_multiblock_read_count 16
db_name DSILAPRD
db_recovery_file_dest /oracle/flash_recovery_area
db_recovery_file_dest_size 21474836480
dispatchers (PROTOCOL=TCP) (SERVICE=DSICTPRDXDB)
fast_start_mttr_target 0
instance_name DSILAPRD
java_pool_size 117440512
job_queue_processes 30
large_pool_size 218103808
log_archive_dest_1 LOCATION=/oracle/oradata/Archive/DSILAPRD
log_archive_dest_state_1 enable
log_archive_format %t_%s_%r.arc
max_dump_file_size 100M
open_cursors 800
pga_aggregate_target 5368709120
processes 800
query_rewrite_enabled FALSE
remote_login_passwordfile EXCLUSIVE
remote_os_authent TRUE
resource_limit TRUE
session_cached_cursors 40
sga_max_size 56908316672
sga_target 46170898432
shared_pool_size 3221225472
smtp_out_server lauzsmtp01.latimes.com
star_transformation_enabled FALSE
timed_statistics TRUE
undo_management AUTO
undo_retention 10800
undo_tablespace UNDOTBS1
user_dump_dest /oracle/admin/DSILAPRD/udump
utl_file_dir /oracle/oraexport/la, /oracle/oraimport/la, /oracle/home/dsiadmin/stg/r510/fil, /oracle/oraexport/la/Complaints,
/oracle/oraexport/la/Complaints/Processed