High cache buffers chains
After a data load the data increased by around 30%. After the load, one statement now takes 5h compared to 40min before the load. The statement runs during the nighty batch so there are no other connections. Statistics for tables and indexes are gathered and current.
I have compared the AWRs before the data load and the current AWR:
- latch: cache buffers increased from 12Mio waits to 95Mio waits. As a consequence CPU usage is very high during the load period.
- consistent gets increased 3 times
- select count(distinct(hladdr)) from x$bh; result is 8192
- I checked for hot blocks - there are none as there is no other process during that time
The slow statement is an CTAS like (The same statement runs in an environment with much more data in less time.)
CREATE TABLE XXX NOLOGGING PARALLEL TABLESPACE YYY COMPRESS PARTITION BY RANGE(...) select with some outer joins.
What else should I examine/consider?
The object statistics including indexes are current & complete. I have rerun the whole queries on both environments - the plans are different.
Difference between the databases:
- the slow one uses AL32UTF8 as DB character set, the fast one WE8ISO8859P1.
- the fast DB has temporary tablespace on raw devices
SELECT
count(*)
FROM
SELECT
mand,
c2v_thk1, c2v_thk1origin,
c2v_thk1 AS thk1,
sustainid,
_from, _to,
FROM
SELECT
mand,
CASE WHEN c2v_thk1skr IS NOT NULL THEN c2v_thk1skr ELSE thk1 END AS c2v_thk1,
CASE WHEN c2v_thk1skr IS NOT NULL THEN thk1 ELSE NULL END AS c2v_thk1origin,
sustainid,
_from, _to,
FROM chem.exper LEFT OUTER JOIN
SELECT
olr.mand,
olr.sustainid,
o.handoverdate
FROM
chem.order olr, chem.ch_order o
WHERE
(olr.mand = o.mand AND olr.sustainorderno = o.sustainorderno) AND
olr.finishDate IS NULL AND
o.finishDate IS NULL
) v2o USING (mand, sustainid) LEFT OUTER JOIN
SELECT
mand, thk1, sustainid,
selling_retuid,
CASE WHEN liqudateStep = 0 THEN liqu_retuid ELSE NULL END AS liqu_retuid,
CASE WHEN liqudateStep = 0 THEN trj55_lastliqudate ELSE NULL END AS trj55_lastliqudate
FROM
SELECT
mand,
thk1,
sustainid,
DECODE(roleselling, 0, retuid, NULL) AS selling_retuid, DECODE(roleliqu, 1, retuid, NULL) AS liqu_retuid,
DECODE(roleliqu, 2, lastliqudate, NULL) AS trj55_lastliqudate,
ROW_NUMBER () OVER (PARTITION BY mand, thk1, sustainid ORDER BY roleliqu DESC NULLS LAST, lastliqudate DESC NULLS LAST,retuid) AS liqudateStep
FROM chem.sat_trj55etu trj55
WHERE finishDate IS NULL
WHERE
(liqudateStep = 1 OR liqu_retuid IS NULL OR selling_retuid IS NOT NULL)
) trj55 USING (mand, thk1, sustainid) LEFT OUTER JOIN
SELECT
mand,
thk1origin AS thk1,
thk1skr AS c2v_thk1skr
FROM chem.x_ref
WHERE finishDate IS NULL
) USING (mand, thk1) )
) bs LEFT OUTER JOIN (
SELECT
tk_pla.mand,
tk_pla.thk1company AS thk1,
CASE WHEN ss.thk1skr IS NOT NULL THEN ss.thk1skr ELSE tk_pla.thk1individual END AS tk_pla_thk1individual,
CASE WHEN ss.thk1skr IS NOT NULL THEN tk_pla.thk1individual ELSE NULL END AS tk_pla_thk1individualorigin,
FROM chem.sat_indy tk_pla, (SELECT * FROM chem.x_ref WHERE finishDate IS NULL) ss
WHERE tk_pla.finishDate IS NULL
AND (tk_pla.mand = ss.mand(+) AND tk_pla.thk1individual = ss.thk1origin(+))
AND tk_pla._to IS NULL
) tk_pla USING (mand, thk1);Slow environment with much less data (execution time much more since last data load; object statistics are current)
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1 | 62 | | 116 (6)| 00:00:02 | | | | |
| 1 | SORT AGGREGATE | | 1 | 62 | | | | | | | |
| 2 | NESTED LOOPS OUTER | | 90571 | 5483K| | 116 (6)| 00:00:02 | | | | |
| 3 | VIEW | | 73410 | 2437K| | 116 (6)| 00:00:02 | | | | |
| 4 | PX COORDINATOR | | | | | | | | | | |
| 5 | PX SEND QC (RANDOM) | :TQ10003 | 73410 | 10M| | 116 (6)| 00:00:02 | | | Q1,03 | P->S | QC (RAND)
| 6 | NESTED LOOPS OUTER | | 73410 | 10M| | 116 (6)| 00:00:02 | | | Q1,03 | PCWP |
| 7 | NESTED LOOPS OUTER | | 73410 | 8674K| | 115 (5)| 00:00:02 | | | Q1,03 | PCWP |
|* 8 | HASH JOIN RIGHT OUTER | | 73410 | 4588K| | 115 (5)| 00:00:02 | | | Q1,03 | PCWP |
| 9 | PX RECEIVE | | 49290 | 1540K| | 9 (12)| 00:00:01 | | | Q1,03 | PCWP |
| 10 | PX SEND HASH | :TQ10002 | 49290 | 1540K| | 9 (12)| 00:00:01 | | | Q1,02 | P->P | HASH
| 11 | VIEW | | 49290 | 1540K| | 9 (12)| 00:00:01 | | | Q1,02 | PCWP |
|* 12 | VIEW | | 49290 | 6979K| | 9 (12)| 00:00:01 | | | Q1,02 | PCWP |
| 13 | WINDOW SORT | | 49290 | 2406K| 7000K| 9 (12)| 00:00:01 | | | Q1,02 | PCWP |
| 14 | PX RECEIVE | | 49290 | 2406K| | 8 (0)| 00:00:01 | | | Q1,02 | PCWP |
| 15 | PX SEND HASH | :TQ10001 | 49290 | 2406K| | 8 (0)| 00:00:01 | | | Q1,01 | P->P | HASH
| 16 | PX BLOCK ITERATOR | | 49290 | 2406K| | 8 (0)| 00:00:01 | 1 | 6 | Q1,01 | PCWC |
|* 17 | TABLE ACCESS FULL | SAT_trj55etu | 49290 | 2406K| | 8 (0)| 00:00:01 | 1 | 6 | Q1,01 | PCWP |
| 18 | BUFFER SORT | | | | | | | | | Q1,03 | PCWC |
| 19 | PX RECEIVE | | 73410 | 2294K| | 106 (4)| 00:00:02 | | | Q1,03 | PCWP |
| 20 | PX SEND HASH | :TQ10000 | 73410 | 2294K| | 106 (4)| 00:00:02 | | | | S->P | HASH
| 21 | PARTITION RANGE ALL | | 73410 | 2294K| | 106 (4)| 00:00:02 | 1 | 6 | | |
| 22 | TABLE ACCESS FULL | exper | 73410 | 2294K| | 106 (4)| 00:00:02 | 1 | 6 | | |
| 23 | PARTITION RANGE ITERATOR | | 1 | 57 | | 0 (0)| 00:00:01 | KEY | KEY | Q1,03 | PCWP |
|* 24 | INDEX FAST FULL SCAN | X_x_ref | 1 | 57 | | 0 (0)| 00:00:01 | KEY | KEY | Q1,03 | PCWP |
|* 25 | VIEW PUSHED PREDICATE | | 1 | 35 | | 0 (0)| 00:00:01 | | | Q1,03 | PCWP |
|* 26 | TABLE ACCESS BY LOCAL INDEX ROWID| order | 1 | 106 | | 0 (0)| 00:00:01 | 1 | 1 | Q1,03 | PCWP |
| 27 | NESTED LOOPS | | 1 | 199 | | 0 (0)| 00:00:01 | | | Q1,03 | PCWP |
| 28 | PARTITION RANGE ALL | | 1 | 93 | | 0 (0)| 00:00:01 | 1 | 6 | Q1,03 | PCWP |
|* 29 | INDEX SKIP SCAN | X_ch_order | 1 | 93 | | 0 (0)| 00:00:01 | 1 | 6 | Q1,03 | PCWP |
| 30 | PARTITION RANGE SINGLE | | 1 | | | 0 (0)| 00:00:01 | KEY | KEY | Q1,03 | PCWP |
|* 31 | INDEX RANGE SCAN | XPKorder | 1 | | | 0 (0)| 00:00:01 | KEY | KEY | Q1,03 | PCWP |
| 32 | PX COORDINATOR | | | | | | | | | | |
| 33 | PX SEND QC (RANDOM) | :TQ20000 | 1 | 28 | | 0 (0)| 00:00:01 | | | Q2,00 | P->S | QC (RAND)
|* 34 | VIEW PUSHED PREDICATE | | 1 | 28 | | 0 (0)| 00:00:01 | | | Q2,00 | PCWP |
| 35 | NESTED LOOPS OUTER | | 40517 | 3204K| | 2 (0)| 00:00:01 | | | Q2,00 | PCWP |
| 36 | PX BLOCK ITERATOR | | 40517 | 1463K| | 2 (0)| 00:00:01 | KEY | KEY | Q2,00 | PCWC |
|* 37 | TABLE ACCESS FULL | SAT_INDI | 40517 | 1463K| | 2 (0)| 00:00:01 | KEY | KEY | Q2,00 | PCWP |
| 38 | PARTITION RANGE ITERATOR | | 1 | 44 | | 0 (0)| 00:00:01 | KEY | KEY | Q2,00 | PCWP |
|* 39 | INDEX FAST FULL SCAN | X_x_ref | 1 | 44 | | 0 (0)| 00:00:01 | KEY | KEY | Q2,00 | PCWP |
Predicate Information (identified by operation id):
8 - access("exper"."mand"="trj55"."mand"(+) AND "exper"."thk1"="trj55"."thk1"(+) AND
"exper"."sustainID"="trj55"."sustainID"(+))
12 - filter("liqudateStep"=1 OR "liqu_retuID" IS NULL OR "SELLIN
17 - filter("finishDate" IS NULL)
24 - filter("finishDate"(+) IS NULL AND "exper"."mand"="mand"(+) AND "exper"."thk1"="thk1ORIGIN"(+))
25 - filter("exper"."sustainID"="V2O"."sustainID"(+))
26 - filter("olr"."finishDate" IS NULL)
29 - access("O"."finishDate" IS NULL)
filter("O"."finishDate" IS NULL)
31 - access("olr"."mand"="O"."mand" AND "olr"."sustainORDERNO"="O"."sustainORDERNO")
filter("olr"."mand"="exper"."mand")
34 - filter("BS"."thk1"="tk_pla"."thk1"(+))
37 - filter("tk_pla"."finishDate" IS NULL AND "tk_pla"."_to" IS NULL AND "tk_pla"."mand"="BS"."mand")
39 - filter("finishDate"(+) IS NULL AND "tk_pla"."mand"="x_ref"."mand"(+) AND "tk_pla"."thk1INDIVIDUAL"="x_ref"."thk1ORIGIN"(+))
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.3
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
db_file_multiblock_read_count integer 32
db_block_size integer 8192
parallel_max_servers integer 17
parallel_min_percent integer 0
parallel_min_servers integer 0
parallel_server boolean FALSE
parallel_server_instances integer 1
parallel_threads_per_cpu integer 2
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1653.70019
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM 3.684
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED 1471
{code}
Fast environment with more data
{code}
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1 | 33 | | 52357 (6)| 00:04:29 | | | | | |
| 1 | SORT AGGREGATE | | 1 | 33 | | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10010 | 1 | 33 | | | | | | Q1,10 | P->S | QC (RAND) |
| 4 | SORT AGGREGATE | | 1 | 33 | | | | | | Q1,10 | PCWP | |
|* 5 | HASH JOIN RIGHT OUTER | | 22M| 698M| | 52357 (6)| 00:04:29 | | | Q1,10 | PCWP | |
| 6 | PX RECEIVE | | 294K| 4020K| | 86 (3)| 00:00:01 | | | Q1,10 | PCWP | |
| 7 | PX SEND BROADCAST | :TQ10007 | 294K| 4020K| | 86 (3)| 00:00:01 | | | Q1,07 | P->P | BROADCAST |
| 8 | VIEW | | 294K| 4020K| | 86 (3)| 00:00:01 | | | Q1,07 | PCWP | |
|* 9 | HASH JOIN OUTER BUFFERED | | 294K| 10M| | 86 (3)| 00:00:01 | | | Q1,07 | PCWP | |
| 10 | PX RECEIVE | | 294K| 6892K| | 77 (2)| 00:00:01 | | | Q1,07 | PCWP | |
| 11 | PX SEND HASH | :TQ10002 | 294K| 6892K| | 77 (2)| 00:00:01 | | | Q1,02 | P->P | HASH |
| 12 | PX BLOCK ITERATOR | | 294K| 6892K| | 77 (2)| 00:00:01 | 1 | 6 | Q1,02 | PCWC | |
|* 13 | TABLE ACCESS FULL | SAT_INDI | 294K| 6892K| | 77 (2)| 00:00:01 | 1 | 6 | Q1,02 | PCWP | |
| 14 | PX RECEIVE | | 71698 | 980K| | 8 (0)| 00:00:01 | | | Q1,07 | PCWP | |
| 15 | PX SEND HASH | :TQ10003 | 71698 | 980K| | 8 (0)| 00:00:01 | | | Q1,03 | P->P | HASH |
| 16 | PX BLOCK ITERATOR | | 71698 | 980K| | 8 (0)| 00:00:01 | 1 | 6 | Q1,03 | PCWC | |
|* 17 | INDEX FAST FULL SCAN | X_x_ref | 71698 | 980K| | 8 (0)| 00:00:01 | 1 | 6 | Q1,03 | PCWP | |
| 18 | VIEW | | 22M| 402M| | 52253 (6)| 00:04:28 | | | Q1,10 | PCWP | |
|* 19 | HASH JOIN RIGHT OUTER | | 22M| 1524M| | 52253 (6)| 00:04:28 | | | Q1,10 | PCWP | |
| 20 | PX RECEIVE | | 1673K| 28M| | 706 (3)| 00:00:04 | | | Q1,10 | PCWP | |
| 21 | PX SEND HASH | :TQ10008 | 1673K| 28M| | 706 (3)| 00:00:04 | | | Q1,08 | P->P | HASH |
| 22 | VIEW | | 1673K| 28M| | 706 (3)| 00:00:04 | | | Q1,08 | PCWP | |
|* 23 | VIEW | | 1673K| 111M| | 706 (3)| 00:00:04 | | | Q1,08 | PCWP | |
| 24 | WINDOW SORT | | 1673K| 63M| 192M| 706 (3)| 00:00:04 | | | Q1,08 | PCWP | |
| 25 | PX RECEIVE | | 1673K| 63M| | 695 (2)| 00:00:04 | | | Q1,08 | PCWP | |
| 26 | PX SEND HASH | :TQ10004 | 1673K| 63M| | 695 (2)| 00:00:04 | | | Q1,04 | P->P | HASH
| 27 | PX BLOCK ITERATOR | | 1673K| 63M| | 695 (2)| 00:00:04 | 1 | 6 | Q1,04 | PCWC |
|* 28 | TABLE ACCESS FULL | SAT_trj55etu | 1673K| 63M| | 695 (2)| 00:00:04 | 1 | 6 | Q1,04 | PCWP |
| 29 | PX RECEIVE | | 22M| 1143M| | 51528 (6)| 00:04:25 | | | Q1,10 | PCWP |
| 30 | PX SEND HASH | :TQ10009 | 22M| 1143M| | 51528 (6)| 00:04:25 | | | Q1,09 | P->P | HASH
|* 31 | HASH JOIN RIGHT OUTER | | 22M| 1143M| | 51528 (6)| 00:04:25 | | | Q1,09 | PCWP |
| 32 | PX RECEIVE | | 504K| 6893K| | 167 (3)| 00:00:01 | | | Q1,09 | PCWP |
| 33 | PX SEND BROADCAST | :TQ10005 | 504K| 6893K| | 167 (3)| 00:00:01 | | | Q1,05 | P->P | BROADCAST
| 34 | VIEW | | 504K| 6893K| | 167 (3)| 00:00:01 | | | Q1,05 | PCWP |
|* 35 | HASH JOIN | | 504K| 21M| | 167 (3)| 00:00:01 | | | Q1,05 | PCWP |
| 36 | PX BLOCK ITERATOR | | 692K| 16M| | 67 (2)| 00:00:01 | 1 | 6 | Q1,05 | PCWC |
|* 37 | INDEX FAST FULL SCAN | X_order | 692K| 16M| | 67 (2)| 00:00:01 | 1 | 6 | Q1,05 | PCWP |
| 38 | BUFFER SORT | | | | | | | | | Q1,05 | PCWC |
| 39 | PX RECEIVE | | 698K| 12M| | 98 (3)| 00:00:01 | | | Q1,05 | PCWP |
| 40 | PX SEND BROADCAST LOCAL| :TQ10001 | 698K| 12M| | 98 (3)| 00:00:01 | | | Q1,01 | P->P | BCSTLOCAL
| 41 | PX BLOCK ITERATOR | | 698K| 12M| | 98 (3)| 00:00:01 | 1 | 6 | Q1,01 | PCWC |
|* 42 | INDEX FAST FULL SCAN | X_ch_order | 698K| 12M| | 98 (3)| 00:00:01 | 1 | 6 | Q1,01 | PCWP |
|* 43 | HASH JOIN RIGHT OUTER | | 22M| 846M| | 51344 (6)| 00:04:24 | | | Q1,09 | PCWP |
| 44 | PX RECEIVE | | 71698 | 1400K| | 8 (0)| 00:00:01 | | | Q1,09 | PCWP |
| 45 | PX SEND HASH | :TQ10006 | 71698 | 1400K| | 8 (0)| 00:00:01 | | | Q1,06 | P->P | HASH
| 46 | PX BLOCK ITERATOR | | 71698 | 1400K| | 8 (0)| 00:00:01 | 1 | 6 | Q1,06 | PCWC |
|* 47 | INDEX FAST FULL SCAN | X_x_ref | 71698 | 1400K| | 8 (0)| 00:00:01 | 1 | 6 | Q1,06 | PCWP |
| 48 | BUFFER SORT | | | | | | | | | Q1,09 | PCWC |
| 49 | PX RECEIVE | | 22M| 423M| | 51319 (6)| 00:04:24 | | | Q1,09 | PCWP |
| 50 | PX SEND HASH | :TQ10000 | 22M| 423M| | 51319 (6)| 00:04:24 | | | | S->P | HASH
| 51 | PARTITION RANGE ALL | | 22M| 423M| | 51319 (6)| 00:04:24 | 1 | 6 | | |
| 52 | TABLE ACCESS FULL | exper | 22M| 423M| | 51319 (6)| 00:04:24 | 1 | 6 | | |
Predicate Information (identified by operation id):
5 - access("BS"."mand"="tk_pla"."mand"(+) AND "BS"."thk1"="tk_pla"."thk1"(+))
9 - access("tk_pla"."mand"="x_ref"."mand"(+) AND "tk_pla"."thk1INDIVIDUAL"="x_ref"."thk1ORIGIN"(+))
13 - filter("tk_pla"."finishDate" IS NULL AND "tk_pla"."_to" IS NULL)
17 - filter("finishDate"(+) IS NULL)
19 - access("exper"."mand"="trj55"."mand"(+) AND "exper"."thk1"="trj55"."thk1"(+) AND
"exper"."sustainID"="trj55"."sustainID"(+))
23 - filter("liqudateStep"=1 OR "liqu_retuID" IS NULL OR "SELLING_retuID" IS NOT NULL)
28 - filter("finishDate" IS NULL)
31 - access("exper"."mand"="V2O"."mand"(+) AND "exper"."sustainID"="V2O"."sustainID"(+))
35 - access("olr"."mand"="O"."mand" AND "olr"."sustainORDERNO"="O"."sustainORDERNO")
37 - filter("olr"."finishDate" IS NULL)
42 - filter("O"."finishDate" IS NULL)
43 - access("exper"."mand"="mand"(+) AND "exper"."thk1"="thk1ORIGIN"(+))
47 - filter("finishDate"(+) IS NULL)
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.3
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
db_file_multiblock_read_count integer 32
db_block_size integer 8192
parallel_max_servers integer 17
parallel_min_percent integer 0
parallel_min_servers integer 0
parallel_server boolean FALSE
parallel_server_instances integer 1
parallel_threads_per_cpu integer 2
(actually workload stats are missing)
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1644.207
SYSSTATS_MAIN IOSEEKTIM 3.775
SYSSTATS_MAIN IOTFRSPEED 6059.372
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED 1663
{code}
Edited by: TanteKaethe on May 26, 2009 1:38 PM
Similar Messages
-
AWR showing high latch: cache buffers chains
OS:Solaris 5.8
DB:10.2.0.2
AWR report show high latch: cache buffers chains . Please suggestuser8850066 wrote:
OS:Solaris 5.8
DB:10.2.0.2
AWR report show high latch: cache buffers chains . Please suggestYour question is not sensible - so the first answer you got may be a complete waste of your time, or it may be a lucky shot in the dark that helps.
How did you decide that your "latch: cache buffers chains" was high ?
The evidence that led you to this conclusion may help us understand what your problem is and how to help you.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
+"I believe in evidence. I believe in observation, measurement, and reasoning, confirmed by independent observers. I'll believe anything, no matter how wild and ridiculous, if there is evidence for it. The wilder and more ridiculous something is, however, the firmer and more solid the evidence will have to be."+
Isaac Asimov -
100 %CPU utilizationis , cache buffers chains and cursor: pin S
Hi every one ,
we have incident causing system response very slow with very bad response time, below top 5 wait events from AWR (RAC database)
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
latch: cache buffers chains 122,492 198,139 1,618 16.8 Concurrency
gc buffer busy 119,903 83,248 694 7.1 Cluster
cursor: pin S 18,674,280 72,651 4 6.2 Other
log file sync 639,867 66,673 104 5.7
Commit latch free 143,519 54,239 378 4.6 Other
Oracle support clearly identified the issue with latch cache buffer chains as SQL statement executed around 35000 times which is too high based on execution plan . and they suggest to tune SQL statements .
my question is cursor: pin S wait on X and library cache lock related ot it is just a symptoms , and is document 742599.1 applicable to us or not as we have 10.2.0.5 (suggest disable automatic memory management)
As I know high CPU utilization as result of latch: cache buffers chains , the cursor Pin S Wait should not .
Thank you in advanceHi,
All these 4 top events (excluding log file sync) are quite unusual and in your case, if all these are comming atop, these quite well be related. So, you can't say that cursor pin s wait on x should not be dealt saperatly, but, still you can try out suggestion in the note. First find out from v$sgasta about current allocation of shared pool, then after disabling automatic memory management, increase shared_pool significantly as compared to current value, and then monito the system
Definitely you should tune your SQL also, as suggested by support.
Salman -
Hi,
I am facing the following in my DB.Oracle version is 11.1.0.7.0
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
latch: cache buffers chains 37,910,465 17,344 0 42.64 Concurrency
I checked the SQL causing the wait using following query.
select count(*), SQL_ID from gv$active_session_history where event like '%cache buffers%' group by SQL_ID;
COUNT(*) SQL_ID
1
3 3wunvbmu64d8j
2 9q2ux8f92za7m
36000 47g8dw48ghk5s
2 5arqxftxr7tjr
Also i tried the following.
select count(*) child_count, sum(gets) sum_gets, sum(misses) sum_misses, sum(sleeps) sum_sleeps from v$latch_children where name = 'cache buffers chains';
CHILD_COUNT SUM_GETS SUM_MISSES SUM_SLEEPS
65536 1.5723E+10 3163139088 56744600
SQL> select P1 from v$session_wait where event = 'cache buffer chains';
no rows selected
How do i proceed with this?
SQL ID - 47g8dw48ghk5s is an update query.Can increasing freelists of this table help ??Kindly assist me.
Thanks.user10698496 wrote:
Elapsed Time (s) CPU Time (s) Executions Elap per Exec (s) % Total DB Time SQL Id SQL Module SQL Text
29,725 6,747 82,289 0.36 73.08 47g8dw48ghk5s app2 (TNS V1-V3) UPDATE ZH_TBL SE
CPU Time (s) Elapsed Time (s) Executions CPU per Exec (s) % Total % Total DB Time SQL Id SQL Module SQL Text
6,747 29,725 82,289 0.08 62.52 73.08 47g8dw48ghk5s app2 (TNS V1-V3) UPDATE ZH_TBL SE...
Assuming that this is the standard one-hour snapshot that seems to be a rather small number of executions to waste so much latch time.
Moreover, since it's an update by rowid it's surprising that it should take so much CPU per executions unless you have a very large number of indexes on the table which have to be maintained.
Can you show us the "Load profile" and "Top 5 timed events" from the same period, plus the system summary bit (memory, cache size, CPU count) that's near the top of the report.
In your position I'd run up a little query to look at the stats in v$sql for that sql_id, and watch the executions, buffer_gets, cpu_time etc. changing over a few minutes in case there's something funny with the snapshot and youre losing large numbers in the execution counts. (I'd be particularly interested in the number of CPUs you have, and the CPU load on the system - sometimes you can get really wierd latching issue which are basically caused by CPU loading, especially on NUMA systems).
Since you've got the ASH data, there's also more information you can get from there - is it
a) the same latch all the time
b) a small number of different latches
c) a small number of different latches, but the same latch for any specific sid/serial
d) does the latch seem to change over time
If it's a small number of fixed latches you may be able to query the buffer cache with the latch address to see if there are any "obvious" blocks with a high touch count covered by those latches - they may be things like the root blocks of indexes used for referential integrity.
If the latch seems to keep moving it could be an indication that the update is slowly travelling along a table and every block is subject to competition from a number of concurrent processes.
Kyle Hailey has some sample queries against ASH that may point you in the right direction: http://sites.google.com/site/embtdbo/wait-event-documentation/oracle-latch-cache-buffers-chains
If you can spot a session hitting the problem you could also start tracing it to see if that level of detail gives you more clues, and I'd also start thinking about read up Tanel's notes.
Regards
Jonathan Lewis
To post code, statspack/AWR report, execution plans or trace files, START and END the text with the tag {noformat}{noformat} (the word "code" in lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.) -
question from oracler:
由于没有代码，所以sql语句没法改。
1、4_28_awr.html是最初的状态cache buffers chains 征用严重，后来我把热点的2个索引INFO_KEYWORD、PKKEY_ARTICLE单独挪到了16k和4k的非标准表空间，这样多增加了几个池子希望可以降低征用。
2、4_28_2awr.html虽然cache buffers chains 还是比较多，但是waitstime比较低，没有影响前台使用。
3、428_3_awr.html 是刚才cpu的使用率又上去了，做的awr报告，发现cache buffers chains仍然较多，waitstime明显上去了。
请教：因为没办法修改sql语句的程序代码，只能从数据库层面入手。尽量降低热点块。是不是可以尝试将2个索引表空间的pctfree再增加到30%或者更高。或者2个索引采用4k的非标准块，这样分布在每个块中的行会比较少一点。我觉得我设置的16k块大小可能有点问题，盼赐教。
http://t.askmaclean.com/viewthread.php?tid=866&extra=page%3D1%26amp%3Bfilter%3Ddigest就症结来看 是SQL语句存在优化空间，大多都Buffer Gets过高 这意味着大量的逻辑读
Logical reads: 952,053.46 511,723.68
在其中一个AWR中 每秒逻辑读 达到 7G
buffer gets 较高 存在优化的SQL包括：
SQL ordered by Gets
Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
Total Buffer Gets: 1,733,719,818
Captured SQL account for 42.9% of Total
Buffer Gets Executions Gets per Exec %Total CPU Time (s) Elapsed Time (s) SQL Id SQL Module SQL Text
150,857,840 6 25,142,973.33 8.70 1296.33 1769.90 gmm6ktqrft6n1 select rowid, title, filep...
57,452,737 234 245,524.52 3.31 676.45 678.49 06r32459s5kzc select rowid, ArticleID, S...
50,264,264 2 25,132,132.00 2.90 311.70 329.90 731rq4a5rd9by select rowid, title, filep...
28,441,522 2 14,220,761.00 1.64 310.11 570.12 bxa7c0y5p6smg select rowid, title, filep...
28,440,949 2 14,220,474.50 1.64 279.11 464.68 68pwkvkgs7taj select rowid, title, filep...
28,433,242 2 14,216,621.00 1.64 234.45 391.91 f442cdh9hp6sk select rowid, title, filep...
粗略看 可能是因为 希望执行计划准确 而没有去绑定变量
这里考虑到 无法修改SQL 语句， 但是 有没有想过 通过其他手段(不修改语句 添加hint)而 改善其执行计划？
Segments by Logical Reads
Total Logical Reads: 1,733,719,818
Captured Segments account for 98.8% of Total
Owner Tablespace Name Object Name Subobject Name Obj. Type Logical Reads %Total
JSCMS JSCMS INFO_KEYWORD INDEX 1,159,873,824 66.90
JSCMS JSCMS PKKEY_ARTICLE INDEX 215,263,104 12.42
JSCMS JSCMS ARTICLE SYS_P76 TABLE PARTITION 198,657,088 11.46
逻辑较高的 segment 包括 INFO_KEYWORD 和 PKKEY_ARTICLE 把他们 移动到 block size的 非标准表空间上确实可以一定程度缓解 对这个segment 上buffer的交叉访问争用 ， 但是 使用 16KB的block size意味着 数据行的分布更为集中 ， 这可能导致段内buffer的争用加剧 。
建议：
1. 考虑在 不修改SQL文本 的情况下 调优SQL ，包括使用SQL Profile等技术
2. 考试使用 global hash index ，当然hash index不是一定能缓解cbc
3. 内存允许的话 可以吧 一个索引 keep到 db cache keep pool中(而非16k pool)，另一个使用 4k pool
一些Cache buffer chains相关的master Notes:
ODM FINDING:
Cache Buffers Chains Latch waits are caused by contention where multiple sessions waiting to read the same block.
Typical solutions are:-
o Look for SQL that accesses the blocks in question and determine if the repeated reads are necessary.
o Check for suboptimal SQL (this is the most common cause of the events) - look at the execution plan for the
SQL being run and try to reduce the gets per executions which will minimise the number of blocks being accessed
and therefore reduce the chances of multiple sessions contending for the same block
Note 34405.1 WAITEVENT: "buffer busy waits" Reference Note
@Note 42152.1 LATCH: CACHE BUFFERS CHAINS
Note 155971.1 Ext/Pub Resolving Intense and "Random" Buffer Busy Wait Performance Problems:
Note 163424.1 Ext/Pub How To Identify a Hot Block Within The Database Buffer Cache.:
These queries would benefit from tuning. They either do too much buffer gets (logical reads) per execution or just do a lot of buffer gets. Tuning these queries would lower the load on the CPU and reduce the CPU wait time. Check if all objects in these queries have representative and up to date stats present. Also check if all the indexes are present.
If a query does not do an excessive amount of gets for 1 run but when the query runs often, then lowering the amount of buffer gets per run with for example 10% will have a big impact overall.
To see the full SQL open the html AWR report and select SQL Statistics in the Main Report section, then select SQL ordered by Gets clicking on the SQL id then gives the complete statement.
"Cache Buffers Chains Latch waits are caused by contention where multiple sessions waiting to read the same block.
那么与
read by others session 这个等待事件有什么区别？"
通俗的说 (不深究技术细节)
CBC latch 是 大家都要逻辑读取同一个块，对于Consistent Read会使用kcbgtcr函数， kcbgtcr 函数可能使用2中模式去get cache buffer chains， 分别是 kcbgtcr: kslbegin excl 和 kcbgtcr: kslbegin shared， 在上述AWR中 主要是 kslbegin excl
“我们一般认为Latch结构是Mostly exclusive access的，也就是极少会有共享访问闩的机会。但Oracle一般对外宣称读取数据时服务进程是以共享模式使用cache buffers chains闩，这就造成了许多人误以为读读是不会出现latch: cache buffers chains争用的。
但是实际上查询语句大部分情况下仍需要以exclusive模式持有该类子闩(有时会以SHARED模式持有，这取决于读取时是使用kcbgtcr: kslbegin shared还是kcbgtcr: kslbegin excl；kcbgtcr是Oracle rdbms中重要的获取一致性读的函数，其含义为Kernal Cache Buffer GeT Cosistents Read，显然该函数存在两种获取cache buffers chains的方式即kslbegin shared和excl。与之相对应的是kcbgcur: kslbegin，kcbgcur的含义为Kernel Cache Buffer Get Current，该函数用以获取当前块以便修改，也就是”写”；很显然kcbgcur: kslbegin函数只有以excl排他方式持有child cache buffers chains latch的必要)，原因在于虽然是查询语句但同样需要修改buffer header结构，譬如修改tch抢手度、holder list的hash变量us_nxt、us_prv以及waiter list的hash变量wa_prv、wa_nxt等。换而言之读读是会引起Latch free:cache buffers chains等待的，而非许多人认为的仅有读写、写写会导致缓存链闩争用。”
FROM http://www.oracledatabase12g.com/archives/oracle%E9%97%A9latch-cache-buffers-chains.html
cache buffers chains kcbgtcr: kslbegin excl 0 28,633,140 27,628,172
cache buffers chains kcbrls: kslbegin 0 27,162,431 28,455,820
cache buffers chains kcbgtcr: fast path 0 1,969 2,664
read by others session 是这个block不在缓存(buffer cache)中，大家都想要访问这个block，但是只需要一个人去做物理读取到Buffer cache， 其他人在 有一个人去做physical read 的情况下非空闲(non-idle wait)等待即可。 -
Why the event latch: cache buffers chains wait event arises and resolution
Can any one please give full information about:
latch: cache buffers chains wait event
Why this event arises and resolution?Google gave me
http://www.pythian.com/news/1135/tuning-latch-contention-cache-buffers-chain-latches/ -
Slow/choppy playback - cache buffering issue
On playback, PP6 randomly slows down and plays back choppy on visually complex shots. It takes repeated stops and starts to clear it out. I have troubleshot the life out of this, read every relevant thread, and tried everything imaginable to fix it. Windows 7 pro is fully optimized. There are no software conflicts (installed a drive with only windows and CS6) I’ve got plenty of horsepower - 3930K in an asusp9x79pro, gtx 670 w/4mb, 32mb ram, OC to 4.5. Eric Bowen at ADK has personally tuned the system and done a manual overclock. Memtest confirms the ram is fine. There are no hardware issues. Dropped frame indicator stays green, no dropped frames. Switching from hardware to software mercury playback does nothing. Rendering has no effect, nor do any playback settings. It happens with AVCHD and h.264 mp4’s as well, on short clips, not just long ones. It does not happen outside of ppro. Since I have eliminated hardware and software issues, all this leaves is Premiere.
As Eric explains it, it is a cache buffering issue, related to how the nvidia card and ppro interact, and he sees it frequently enough. I can't do his explanation justice, but he has offered to jump in and provide more detail if need be.
Whatever it is, it’s ridiculous. It is totally unacceptable to play down a sequence and have it intermittently slow down on a system with this much power that has been properly set up by a pro. It’s a shame, because it’s the only thing from keeping ppro/cs6 from being the best platform I’ve edited on in my 12 years as an editor.
I’ve filed a bug report, but gotten no response. If others are seeing it, and can file a bug report, maybe it will be publicly acknowledged and resolved.
https://www.adobe.com/cfusion/mmform/index.cfm?name=wishformHi,
I think I have similair problem. First of all my current specs is:
Asus Sabertooth z77 mainboard with intel i7 2700K processor
32 gb (8*4) ram
120 gb ssd sata3 drive for OS and CS6
500 gb sata3 7200rpm hd for cache files
1 tb sata3 7200rpm hd for source video and audio
and finally Nvidia GeForce GTX 660 Ti with 2gb of memory
Blackmagic shuttle io card etc
This system were combined specially for my endless highend compositing needs and it works like a charm with all applications other than Premiere Pro.
Yesterday I barley finished editing a short (approx 2 minutes) 1080p project that shot with Canon 5D MKII. Without using mercury playback engine application
works fine but once I activate it all playback became really slow and laggy and sometime it freeze if I move playhead quickly.
I only use one video and one audio track in timeline so we can say this editing scenario is a fundamental for production grade NLE application.
My graphic processor has a lot of cuda power but Adobe doesn't support it natively so I have to edit the famous text file.
On CS5 and CS5.5 I done lots of 1080p project with my old gtx 480 card and I never encountered any similair problem.
I hope my favorite and trusted software company Adobe will find the problem and will fix it soon...
Thanks
M.Maya -
High cache usage of free memory
I dont know if this is normal but my fresh archlinux x86_64 install with Xfce uses round 300Mb of 4Gb ram space after boot but then after i start and close some programs i get to 3 Gb used of 3.87 Gb free memory when all applycation are closed. Now i understand that kernel caches some data in memory but i cant clear it all with commands:
sync
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches
After i do that system reports 540 Mb used compared to 300Mb from boot. Is there a way to limit the ammount of cache usage so i dont end up having all free memory used by cache?
Last edited by Anril (2009-12-29 13:19:52)Ram that is unused is wasted ram, the linux kernel manages it very well so no worries there.
If you have swap usage it's because most probably you have things stored in the ram that are not being used often but cannot be discarded too so things being used more often take precedence.
If you think you have enough ram for all your needs then why not disable swap? I've read that there might be a speed penalty for running without swap but I've been running my system without swap (arch64 4G ram) and I've never had any bad surprises.
There are a few things that might prompt swap usage (don't quote me on that though, it just seems to me to be the case), if you copy many files from one place to the other the kernel will use all the ram available to try to cache them, if you copy many GB then all the ram will get filled (and maybe other things will get evicted to swap).
It's not a bug, free ram is there to be used, things that have been used/needed recently get to stay in the ram, other things can go to the swap, if you can cache a file that has been recently used and need to use it again shortly after then it's much faster if it is in the ram instead of having to read it again from the hard disk. The logic behind it is good, it's just that some corner cases may make behave badly. -
Performance Degradation - High fetches and Prses
Hello,
My analysis on a particular job trace file drew my attention towards:
1) High rate of Parses instead of Bind variables usage.
2) High fetches and poor number/ low number of rows being processed
Please let me kno as to how the performance degradation can be minimised, Perhaps the high number of SQL* Net Client wait events may be due to multiple fetches and transactions with the client.
EXPLAIN PLAN FOR SELECT /*+ FIRST_ROWS (1) */ * FROM SAPNXP.INOB
WHERE MANDT = :A0
AND KLART = :A1
AND OBTAB = :A2
AND OBJEK LIKE :A3 AND ROWNUM <= :A4;
call count cpu elapsed disk query current rows
Parse 119 0.00 0.00 0 0 0 0
Execute 239 0.16 0.13 0 0 0 0
Fetch 239 2069.31 2127.88 0 13738804 0 0
total 597 2069.47 2128.01 0 13738804 0 0
PLAN_TABLE_OUTPUT
Plan hash value: 1235313998
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 268 | 1 (0)| 00:00:01 |
|* 1 | COUNT STOPKEY | | | | | |
|* 2 | TABLE ACCESS BY INDEX ROWID| INOB | 2 | 268 | 1 (0)| 00:00:01 |
|* 3 | INDEX SKIP SCAN | INOB~2 | 7514 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter(ROWNUM<=TO_NUMBER(:A4))
2 - filter("OBJEK" LIKE :A3 AND "KLART"=:A1)
3 - access("MANDT"=:A0 AND "OBTAB"=:A2)
filter("OBTAB"=:A2)
18 rows selected.
SQL> SELECT INDEX_NAME,TABLE_NAME,COLUMN_NAME FROM DBA_IND_COLUMNS WHERE INDEX_OWNER='SAPNXP' AND INDEX_NAME='INOB~2';
INDEX_NAME TABLE_NAME COLUMN_NAME
INOB~2 INOB MANDT
INOB~2 INOB CLINT
INOB~2 INOB OBTAB
Is it possible to Maximise the rows/fetch
call count cpu elapsed disk query current rows
Parse 163 0.03 0.00 0 0 0 0
Execute 163 0.01 0.03 0 0 0 0
Fetch 174899 55.26 59.14 0 1387649 0 4718932
total 175225 55.30 59.19 0 1387649 0 4718932
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 27
Rows Row Source Operation
28952 TABLE ACCESS BY INDEX ROWID EDIDC (cr=8505 pr=0 pw=0 time=202797 us)
28952 INDEX RANGE SCAN EDIDC~1 (cr=1457 pr=0 pw=0 time=29112 us)(object id 202995)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 174899 0.00 0.16
SQL*Net more data to client 155767 0.01 5.69
SQL*Net message from client 174899 0.11 208.21
latch: cache buffers chains 2 0.00 0.00
latch free 4 0.00 0.00
********************************************************************************user4566776 wrote:
My analysis on a particular job trace file drew my attention towards:
1) High rate of Parses instead of Bind variables usage.
But if you look at the text you are using bind variables.
The first query is executed 239 times - which matches the 239 fetches. You cut off some of the useful information from the tkprof output, but the figures show that you're executing more than once per parse call. The time is CPU time spent using a bad execution plan to find no data -- this looks like a bad choice of index, possibly a side effect of the first_rows(1) hint.
2) High fetches and poor number/ low number of rows being processedThe second query is doing a lot of fetches because in 163 executions it is fetching 4.7 million rows at roughly 25 rows per fetch. You might improve performance a little by increasing the array fetch size - but probably not by more than a factor of 2.
You'll notice that even though you record 163 parse calls for the second statement the number of " Misses in library cache during parse" is zero - so the parse calls are pretty irrelevant, the cursor is being re-used.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan -
High Buffer Busy Wait due to Concurrent INSERTS
Hi All,
One of my OLTP database is running on 11.1.0.7 (11.1.0.7.0 - 64bit Production) with RHEL 5.4.
On frequent basis, i am observing 'BUFFER BUSY WAITS' and last time i tried to capture some dictionary information to dig the waits.
1. Session Watis :
Oracle Sec Hash
Sid,Serial User OS User Svr-Pgm Wait Event State-Seq Wt Module Cmnd Value P1 P2 P3
633,40830 OLTP_USE fateadm 21646-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863905 1
647, 1761 OLTP_USE fateadm 22715-orac buffer busy wai Wtng-3837 0 ORDERS ISRT 3932487748 384 1863905 1
872, 5001 OLTP_USE fateadm 21836-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863905 1
702, 1353 OLTP_USE fateadm 21984-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863905 1
337,10307 OLTP_USE fateadm 21173-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863905 1
751,43016 OLTP_USE fateadm 21619-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863905 1
820,17959 OLTP_USE fateadm 21648-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863905 1
287,63359 OLTP_USE fateadm 27053-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863905 1
629, 1653 OLTP_USE fateadm 22468-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863905 1
788,14160 OLTP_USE fateadm 22421-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863905 1
615, 4580 OLTP_USE fateadm 21185-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863905 1
525,46068 OLTP_USE fateadm 27043-orac buffer busy wai Wtng-9034 1 ORDERS ISRT 3932487748 384 1863905 1
919,23243 OLTP_USE fateadm 21428-orac buffer busy wai Wtng-6340 1 ORDERS ISRT 3932487748 384 1863906 1
610,34557 OLTP_USE fateadm 21679-orac buffer busy wai Wtng-6422 1 ORDERS ISRT 3932487748 384 1863906 1
803, 1583 OLTP_USE fateadm 21580-orac buffer busy wai Wtng-6656 1 ORDERS ISRT 3932487748 384 1863906 1
781, 1523 OLTP_USE fateadm 21781-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863906 1
369,11005 OLTP_USE fateadm 21718-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863906 1
823,35800 OLTP_USE fateadm 21148-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863906 1
817, 1537 OLTP_USE fateadm 22505-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863906 1
579,54959 OLTP_USE fateadm 22517-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863906 1
591,33597 OLTP_USE fateadm 27027-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863906 1
481, 3031 OLTP_USE fateadm 21191-orac buffer busy wai Wtng-3502 1 ORDERS ISRT 3932487748 384 1863906 1
473,24985 OLTP_USE fateadm 22629-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863906 1
868, 3984 OLTP_USE fateadm 27191-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863906 1
select owner,segment_name,segment_type from dba_extents where file_id = 384 and 1863905 between block_id and block_id + blocks -1;
OWNER SEGMENT_NAME SEGMENT_TYPE
ORDER ORDER_DETAILS TABLE
select TABLE_NAME,PARTITIONED,ini_trans ,degree,compression,FREELISTS from dba_TABLES WHERE TABLE_NAME='ORDER_DETAILS';
TABLE_NAME PAR INI_TRANS DEGREE COMPRESS FREELISTS
ORDER_DETAILS NO 1 1 ENABLED 1
Tablespace is not ASSM managed !
select
object_name,
statistic_name,
value
from
V$SEGMENT_STATISTICS
where
object_name = 'ORDER_DETAILS';
OBJECT_NAME STATISTIC_NAME VALUE
ORDER_DETAILS logical reads 487741104
ORDER_DETAILS buffer busy waits 4715174
ORDER_DETAILS db block changes 200858896
ORDER_DETAILS physical reads 143642724
ORDER_DETAILS physical writes 20581330
ORDER_DETAILS physical reads direct 55239903
ORDER_DETAILS physical writes direct 19500551
ORDER_DETAILS space allocated 1.6603E+11
ORDER_DETAILS segment scans 9727
ORDER_DETAILS table is ~ 153 GB non-partitioned table.
It seems its not a READ BY OTHER SESSIONS wait but BUFFER BUSY due to write-wirte contention inside same block. I have never observed Cache Buffer Chain/ ITL-Wait/ High wait time on dbfile sequential/scattered reads.Table contains one PK (composite index on 3 columns) which seems to be highly fragmented.This non partitioned global Index has 3182037735 rows and blevel is 4.
BHAVIK_DBA.FATE1NA>select index_name,status,num_rows,blevel,pct_free,ini_trans,clustering_factor from dba_indexes where index_name='IDX_ORDERS';
INDEX_NAME STATUS NUM_ROWS BLEVEL PCT_FREE INI_TRANS CLUSTERING_FACTOR
IDX_ORDERS VALID 3182037735 4 2 2 2529462377
1 row selected.
One of the index column value is being populated by sequence. (Monotonically increasing value)
SEGMENT_NAME MB
IDX_ORDERS 170590.438
Index size is greater than table size !Tuning goal here is to reduce buffer busy waits and thus commit latencies.
I think, i need to increase FREELISTS and PCT_FREE to address this issue, but not much confident whether it is going to solve the issue or not?
Can i ask for any help here ?Hi Johnathan;
Many thanks for your detailed write-up. I was expecting you !
Your post here gave lot of information and wisdom that made me think last couple of hrs that is the reason for the delay in reply.
I did visited your index explosion posts couple of times and that scenario only gave me insight that concurrent DML (INSERT) is cause of index fragmentation in my case.
Let me also pick the opportunity to ask you to shed more light on some of the information you have highlighted.
if you can work out the number of concurrent inserts that are really likely to happen at any one instant then a value of freelists that in the range of
concurrency/4 to concurrency/2 is probably appropriate.May i ask you how did you derive this formula ? I dont want to miss learning opportunity here !
Note - with multiple freelists, you may find that you now get buffer busy waits on the segment header block.I did not quite get this point ? Can you shed more light please? What piece in segment header block is going to result contention(BBW on SEGMENT HEADER) on all concurrent inserts ?
The solution to this is to increase the number of freelist groups (making sure that
freelists and freelist groups have no common factors).My prod db NON-RAC environment. Can i use FREELIST GROUPS here ? My little knowledge did not get, What "common factors" you are referring here ?
The reads could be related to leaf block splits, but there are several possible scenarios that could lead to that pattern of activity - so the next step is to find out which blocks are being
read. Capture a sample of the waits, then query dba_extents for the extent_id, file_id, and block_id (don't run that awful query with the "block_id + blocks" predicate) and cross-check the
list of blocks to see if they are typically the first couple of blocks of an extent or randomly scattered throughout extents. If the former the problem is probably related to ASSM, if the
latter it may be related to failed probes on index leaf block reuse (i.e. after large scale deletes).I have 10046 trace file with me (giving you some sample below) that can give some information. However, since the issue was critical, i killed the insert process and rebuilt both the indexes. Since, index is rebuilt, i am not able to find any information in dba_extents.
select SEGMENT_NAME,SEGMENT_TYPE,EXTENT_ID from dba_extents where file_id=42 and block_id=1109331;
no rows selected
select SEGMENT_NAME,SEGMENT_TYPE,EXTENT_ID from dba_extents where file_id=42 and block_id=1109395 ;
no rows selected
select SEGMENT_NAME,SEGMENT_TYPE,EXTENT_ID from dba_extents where file_id=42 and block_id=1109459;
no rows selected
select SEGMENT_NAME,SEGMENT_TYPE,EXTENT_ID from dba_extents where file_id=10 and block_id=1107475;
no rows selected
select SEGMENT_NAME,SEGMENT_TYPE,EXTENT_ID from dba_extents where file_id=10 and block_id=1107539;
no rows selected
select object_name,object_Type from dba_objects where object_id=17599;
no rows selected
WAIT #4: nam='db file sequential read' ela= 49 file#=42 block#=1109331 blocks=1 obj#=17599 tim=1245687162307379
WAIT #4: nam='db file sequential read' ela= 59 file#=42 block#=1109395 blocks=1 obj#=17599 tim=1245687162307462
WAIT #4: nam='db file sequential read' ela= 51 file#=42 block#=1109459 blocks=1 obj#=17599 tim=1245687162307538
WAIT #4: nam='db file sequential read' ela= 49 file#=10 block#=1107475 blocks=1 obj#=17599 tim=1245687162307612
WAIT #4: nam='db file sequential read' ela= 49 file#=10 block#=1107539 blocks=1 obj#=17599 tim=1245687162307684
WAIT #4: nam='db file sequential read' ela= 198 file#=10 block#=1107603 blocks=1 obj#=17599 tim=1245687162307905
WAIT #4: nam='db file sequential read' ela= 88 file#=10 block#=1107667 blocks=1 obj#=17599 tim=1245687162308016
WAIT #4: nam='db file sequential read' ela= 51 file#=10 block#=1107731 blocks=1 obj#=17599 tim=1245687162308092
WAIT #4: nam='db file sequential read' ela= 49 file#=10 block#=1107795 blocks=1 obj#=17599 tim=1245687162308166
WAIT #4: nam='db file sequential read' ela= 49 file#=10 block#=1107859 blocks=1 obj#=17599 tim=1245687162308240
WAIT #4: nam='db file sequential read' ela= 52 file#=10 block#=1107923 blocks=1 obj#=17599 tim=1245687162308314
WAIT #4: nam='db file sequential read' ela= 57 file#=42 block#=1109012 blocks=1 obj#=17599 tim=1245687162308395
WAIT #4: nam='db file sequential read' ela= 52 file#=42 block#=1109076 blocks=1 obj#=17599 tim=1245687162308470
WAIT #4: nam='db file sequential read' ela= 98 file#=42 block#=1109140 blocks=1 obj#=17599 tim=1245687162308594
WAIT #4: nam='db file sequential read' ela= 67 file#=42 block#=1109204 blocks=1 obj#=17599 tim=1245687162308686
WAIT #4: nam='db file sequential read' ela= 53 file#=42 block#=1109268 blocks=1 obj#=17599 tim=1245687162308762
WAIT #4: nam='db file sequential read' ela= 54 file#=42 block#=1109332 blocks=1 obj#=17599 tim=1245687162308841
WAIT #4: nam='db file sequential read' ela= 55 file#=42 block#=1109396 blocks=1 obj#=17599 tim=1245687162308920
WAIT #4: nam='db file sequential read' ela= 54 file#=42 block#=1109460 blocks=1 obj#=17599 tim=1245687162308999
WAIT #4: nam='db file sequential read' ela= 52 file#=10 block#=1107476 blocks=1 obj#=17599 tim=1245687162309074
WAIT #4: nam='db file sequential read' ela= 89 file#=10 block#=1107540 blocks=1 obj#=17599 tim=1245687162309187
WAIT #4: nam='db file sequential read' ela= 407 file#=10 block#=1107604 blocks=1 obj#=17599 tim=1245687162309618TKPROF for above trace
INSERT into
order_rev
(aggregated_revenue_id,
legal_entity_id,
gl_product_group,
revenue_category,
warehouse_id,
tax_region,
gl_product_subgroup,
total_shipments,
total_units_shipped,
aggregated_revenue_amount,
aggregated_tax_amount,
base_currency_code,
exchange_rate,
accounting_date,
inventory_owner_type_id,
fin_commission_structure_id,
seller_of_record_vendor_id,
organizational_unit_id,
merchant_id,
last_updated_date,
revenue_owner_type_id,
sales_channel,
location)
VALUES
(order_rev.nextval,:p1,:p2,:p3,:p4,:p5,:p6,:p7,:p8,:p9,:p10,:p11,:p12,to_date(:p13, 'dd-MON-yyyy'),:p14,:p15,:p16,:p17,:p18,sysdate,:p19,:p20,:p21)
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 613 5.50 40.32 96672 247585 306916 613
Fetch 0 0.00 0.00 0 0 0 0
total 613 5.50 40.32 96672 247585 306916 613
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 446
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 164224 0.04 62.33
SQL*Net message to client 613 0.00 0.00
SQL*Net message from client 613 0.03 0.90
latch: cache buffers chains 8 0.00 0.00
latch: object queue header operation 2 0.00 0.00Is there any other way to find out culprit amongst the two you have listed (ASSM / failed probes on index leaf block reuse ) ? -
Hello,
The system we use is a kind of OLTP thing.
platform - linux
version - 10.2
here, in the statspack everything seems okay to me except the logical reads.(if not tell)
the problems is, the cpu grows gradually and reaches 100.
i need the cpu to be steady.
can somebody tell what is happening here?
STATSPACK report for
Database DB Id Instance Inst Num Startup Time Release RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
2386172435 apple22a 1 11-Aug-09 23:14 10.2.0.1.0 NO
Host Name: xxxxxxxxx Num CPUs: 4 Phys Memory (MB): 2
~~~~
Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
~~~~~~~~ ---------- ------------------ -------- --------- -------------------
Begin Snap: 1747 11-Aug-09 23:23:46 96 7.6
End Snap: 1752 11-Aug-09 23:34:00 218 12.5
Elapsed: 10.23 (mins)
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 2,864M Std Block Size: 8K
Shared Pool Size: 656M Log Buffer: 29,855K
Load Profile Per Second Per Transaction
~~~~~~~~~~~~ --------------- ---------------
Redo size: 8,051,891.15 5,042.02
Logical reads: 289,821.64 181.48
Block changes: 49,889.55 31.24
Physical reads: 197.76 0.12
Physical writes: 717.84 0.45
User calls: 1,908.82 1.20
Parses: 962.84 0.60
Hard parses: 0.25 0.00
Sorts: 591.85 0.37
Logons: 0.35 0.00
Executes: 25,757.48 16.13
Transactions: 1,596.96
% Blocks changed per Read: 17.21 Recursive Call %: 94.11
Rollback per transaction %: 26.58 Rows per Sort: 628.58
Instance Efficiency Percentages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.97 Redo NoWait %: 100.00
Buffer Hit %: 99.93 In-memory Sort %: 100.00
Library Hit %: 100.01 Soft Parse %: 99.97
Execute to Parse %: 96.26 Latch Hit %: 99.78
Parse CPU to Parse Elapsd %: 91.30 % Non-Parse CPU: 99.31
Shared Pool Statistics Begin End
Memory Usage %: 47.56 49.99
% SQL with executions>1: 60.62 73.55
% Memory for SQL w/exec>1: 77.58 84.79
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time
CPU time 1,362 31.6
log file sync 16,960 1,264 75 29.4
PL/SQL lock timer 10 586 58606 13.6
buffer busy waits 57,444 388 7 9.0
enq: TX - row lock contention 12,036 298 25 6.9
Host CPU (CPUs: 4)
~~~~~~~~ Load Average
Begin End User System Idle WIO WCPU
0.20 10.74 53.82 9.51 36.67
Note: There is a 8% discrepancy between the OS Stat total CPU time and
the total CPU time estimated by Statspack
OS Stat CPU time: 2261(s) (BUSY_TIME + IDLE_TIME)
Statspack CPU time: 2456(s) (Elapsed time * num CPUs in end snap)
Instance CPU
~~~~~~~~~~~~
% of total CPU for Instance: 63.51
% of busy CPU for Instance: 100.30
%DB time waiting for CPU - Resource Mgr:
Memory Statistics Begin End
~~~~~~~~~~~~~~~~~ ------------ ------------
Host Mem (MB): 1.9 .0
SGA use (MB): 3,584.0 3,584.0
PGA use (MB): 164.2 258.5
% Host Mem used for SGA+PGA: 194875.2 8987233.1
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
log file sync 16,960 4 1,264 75 0.0
PL/SQL lock timer 10 100 586 58606 0.0
buffer busy waits 57,444 0 388 7 0.1
enq: TX - row lock contention 12,036 0 298 25 0.0
log file parallel write 11,870 0 163 14 0.0
db file sequential read 21,324 0 95 4 0.0
log file sequential read 3,963 0 47 12 0.0
db file scattered read 22,614 0 29 1 0.0
log file switch completion 102 17 28 272 0.0
latch: cache buffers chains 5,829 0 11 2 0.0
Log archive I/O 4,346 0 9 2 0.0
enq: TX - index contention 1,153 0 7 6 0.0
latch free 1,483 0 4 3 0.0
control file parallel write 328 0 4 11 0.0
control file sequential read 1,593 0 2 1 0.0
latch: enqueue hash chains 337 0 2 6 0.0
buffer deadlock 1,091 99 2 2 0.0
Segments by Logical Reads DB/Inst: apple22A/apple22a Snaps: 1747-1752
-> End Segment Logical Reads Threshold: 10000
-> Pct Total shows % of logical reads for each top segment compared with total
logical reads for all segments captured by the Snapshot
Subobject Obj. Logical Pct
Owner Tablespace Object Name Name Type Reads Total
TPCCDB TPCCDB NEW_ORDER TABLE 89,638,240 51.4
TPCCDB TPCCDB PK_STOCK INDEX 22,913,776 13.1
TPCCDB TPCCDB PK_ORDER_LINE INDEX 14,941,264 8.6
TPCCDB TPCCDB PK_O_ORDER INDEX 10,503,040 6.0
TPCCDB TPCCDB ORDER_LINE TABLE 6,368,896 3.7
Segments by Physical Reads DB/Inst: apple22A/apple22a Snaps: 1747-1752
-> End Segment Physical Reads Threshold: 1000
Subobject Obj. Physical Pct
Owner Tablespace Object Name Name Type Reads Total
TPCCDB TPCCDB NEW_ORDER TABLE 49 12.2
TPCCDB TPCCDB WAREHOUSE TABLE 49 12.2
TPCCDB TPCCDB DISTRICT TABLE 49 12.2
TPCCDB TPCCDB INDEX_NO_D_ID INDEX 49 12.2
TPCCDB TPCCDB PK_NEW_ORDER INDEX 49 12.2
SQL Memory Statistics DB/Inst: apple22A/apple22a Snaps: 1747-1752
Begin End % Diff
Avg Cursor Size (KB): 65.12 67.79 3.95
Cursor to Parent ratio: 1.03 1.02 -.08
Total Cursors: 560 620 9.68
Total Parents: 546 605 9.75
init.ora Parameters DB/Inst: apple22A/apple22a Snaps: 1747-1752
End value
Parameter Name Begin value (if different)
aq_tm_processes 1
audit_file_dest /rdbms/oracle/apple22i/64/admin/o
background_dump_dest /rdbms/oracle/apple22i/64/admin/o
commit_write BATCH,NOWAIT
compatible 10.2.0.1.0
control_files /rdbms/oracle/apple22i/64/oradata
core_dump_dest /rdbms/oracle/apple22i/64/admin/o
cursor_sharing EXACT
db_block_size 8192
db_domain yyyyyyy
db_file_multiblock_read_count 16
db_name apple22a
db_recovery_file_dest /rdbms/oracle/apple22i/64/flash_r
db_recovery_file_dest_size 2147483648
dispatchers (PROTOCOL=TCP) (SERVICE=apple22aX
dml_locks 30028
global_names TRUE
job_queue_processes 10
log_archive_dest_1 LOCATION=/perf0/Archivelog_10g_ch
log_archive_format arch_%t_%s_%r.dbf
log_buffer 30571520
open_cursors 300
pga_aggregate_target 524288000
processes 2000
remote_login_passwordfile EXCLUSIVE
sessions 2205
sga_max_size 3758096384
sga_target 3758096384
transactions 7507
undo_management AUTO
undo_tablespace UNDOTBS1
user_dump_dest /rdbms/oracle/apple22i/64/admin/o
-------------------------------------------------------------Process Memory Summary Stats DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> B: Begin snap E: End snap
-> All rows below contain absolute values (i.e. not diffed over the interval)
-> Max Alloc is Maximum PGA Allocation size at snapshot time
Hist Max Alloc is the Historical Max Allocation for still-connected processes
-> Num Procs or Allocs: For Begin/End snapshot lines, it is the number of
processes. For Category lines, it is the number of allocations
-> ordered by Begin/End snapshot, Alloc (MB) desc
Hist Num
Avg Std Dev Max Max Procs
Alloc Used Freeabl Alloc Alloc Alloc Alloc or
Category (MB) (MB) (MB) (MB) (MB) (MB) (MB) Allocs
B -------- 192.0 95.1 8.8 2.0 6.4 51 55 97
Other 179.0 1.8 6.3 50 54 97
Freeable 8.8 .0 .8 .6 2 11
PL/SQL 2.7 1.4 .0 .0 0 0 95
SQL 2.0 1.0 .0 .0 0 2 58
E -------- 311.2 166.7 11.3 1.4 4.3 52 55 220
Other 284.0 1.3 4.1 49 52 220
Freeable 11.4 .0 1.0 1.0 3 11
PL/SQL 10.0 5.4 .0 .0 0 0 218
SQL 5.8 2.8 .0 .0 0 2 208
Top Process Memory (by component) DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> ordered by Begin/End snapshot, Alloc (MB) desc
Alloc Used Freeabl Max Hist Max
PId Category (MB) (MB) (MB) Alloc (MB) Alloc (MB)
B 5 DBW0 -------- 51.3 22.5 1.0 51.3 54.8
Other 50.3 50.3 53.8
Freeable 1.0 .0 1.0
PL/SQL .0 .0 .0 .0
6 LGWR -------- 24.7 11.7 .1 24.7 25.5
Other 24.5 24.5 25.4
Freeable .1 .0 .1
PL/SQL .0 .0 .0 .0
16 ARC0 -------- 21.9 10.3 .0 21.9 21.9
Other 21.9 21.9 21.9
PL/SQL .0 .0 .0 .0
17 ARC1 -------- 21.9 10.3 .0 21.9 21.9
Other 21.9 21.9 21.9
PL/SQL .0 .0 .0 .0
54 TNS V1-V3 --- 4.4 1.3 1.7 4.4 4.4
Other 2.6 2.6 2.6
Freeable 1.7 .0 1.7
SQL .2 .1 .2 2.3
PL/SQL .0 .0 .0 .0
11 MMON -------- 3.5 1.6 1.3 3.5 3.6
Other 2.1 2.1 2.1
Freeable 1.3 .0 1.3
SQL .1 .0 .1 1.1
PL/SQL .0 .0 .0 .1
8 SMON -------- 2.8 .7 1.9 2.8 2.8
Freeable 1.9 .0 1.9
Other .8 .8 .8
SQL .1 .0 .1 .6
PL/SQL .0 .0 .0 .0
10 CJQ0 -------- 1.6 .6 .8 1.6 1.7
Freeable .8 .0 .8
Other .7 .7 .7
SQL .1 .0 .1 .6
PL/SQL .0 .0 .0 .0
20 q000 -------- 1.6 .7 .2 1.6 1.6
Other 1.3 1.3 1.3
Freeable .2 .0 .2
SQL .1 .1 .1 .5
PL/SQL .0 .0 .0 .0
24 ------------ 1.6 .6 .3 1.6 1.6
Other 1.2 1.2 1.2
Freeable .3 .0 .3
SQL .1 .0 .1 .6
PL/SQL .1 .0 .1 .1
7 CKPT -------- 1.4 .4 .8 1.4 2.3
Freeable .8 .0 .8
Other .6 .6 1.4
SQL .0 .0 .0 .1
PL/SQL .0 .0 .0 .0
9 RECO -------- 1.2 .5 .6 1.2 1.2
Freeable .6 .0 .6
Other .5 .5 .5
SQL .1 .1 .1 .5
Top Process Memory (by component) DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> ordered by Begin/End snapshot, Alloc (MB) desc
Alloc Used Freeabl Max Hist Max
PId Category (MB) (MB) (MB) Alloc (MB) Alloc (MB)
B 9 PL/SQL .0 .0 .0 .0
21 ------------ 1.1 .5 .0 1.1 1.1
Other 1.0 1.0 1.0
PL/SQL .0 .0 .0 .0
SQL .0 .0 .0 .2
31 ------------ 1.1 .6 .1 1.1 1.1
Other .9 .9 .9
SQL .1 .0 .1 .2
Freeable .1 .0 .1
PL/SQL .1 .0 .1 .1
E 5 DBW0 -------- 52.4 23.4 3.3 52.4 54.8
Other 49.2 49.2 51.5
Freeable 3.3 .0 3.3
PL/SQL .0 .0 .0 .0
6 LGWR -------- 24.7 11.7 .1 24.7 25.5
Other 24.5 24.5 25.4
Freeable .1 .0 .1
PL/SQL .0 .0 .0 .0
16 ARC0 -------- 21.9 10.3 .0 21.9 21.9
Other 21.9 21.9 21.9
PL/SQL .0 .0 .0 .0
17 ARC1 -------- 21.9 10.3 .0 21.9 21.9
Other 21.9 21.9 21.9
PL/SQL .0 .0 .0 .0
54 TNS V1-V3 --- 4.6 1.3 1.9 4.6 4.6
Other 2.4 2.4 2.4
Freeable 2.1 .0 2.1
SQL .1 .1 .1 2.5
PL/SQL .0 .0 .0 .0
11 MMON -------- 3.5 1.6 1.3 3.5 3.6
Other 2.1 2.1 2.1
Freeable 1.3 .0 1.3
SQL .1 .0 .1 1.1
PL/SQL .0 .0 .0 .1
8 SMON -------- 2.8 .7 1.8 2.8 2.8
Freeable 1.8 .0 1.8
Other 1.0 1.0 1.0
SQL .1 .0 .1 .6
PL/SQL .0 .0 .0 .0
10 CJQ0 -------- 1.6 .6 .8 1.6 1.7
Freeable .8 .0 .8
Other .7 .7 .7
SQL .1 .0 .1 .6
PL/SQL .0 .0 .0 .0
20 q000 -------- 1.6 .7 .2 1.6 1.6
Other 1.3 1.3 1.3
Freeable .2 .0 .2
SQL .1 .1 .1 .5
PL/SQL .0 .0 .0 .0
24 ------------ 1.6 .6 .6 1.6 1.6
Other .9 .9 .9
Freeable .6 .0 .6
SQL .1 .0 .1 .6
Top Process Memory (by component) DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> ordered by Begin/End snapshot, Alloc (MB) desc
Alloc Used Freeabl Max Hist Max
PId Category (MB) (MB) (MB) Alloc (MB) Alloc (MB)
E 24 PL/SQL .1 .0 .1 .1
7 CKPT -------- 1.5 .4 .7 1.5 2.3
Other .8 .8 1.5
Freeable .7 .0 .7
SQL .0 .0 .0 .1
PL/SQL .0 .0 .0 .0
9 RECO -------- 1.2 .5 .6 1.2 1.2
Freeable .6 .0 .6
Other .5 .5 .5
SQL .1 .1 .1 .5
PL/SQL .0 .0 .0 .0
219 ------------ 1.2 .5 .0 1.2 1.2
Other 1.1 1.1 1.1
PL/SQL .0 .0 .0 .0
SQL .0 .0 .0 .2
21 ------------ 1.1 .5 .0 1.1 1.1
Other 1.0 1.0 1.0
PL/SQL .0 .0 .0 .0
SQL .0 .0 .0 .2
31 ------------ 1.1 .6 .1 1.1 1.1
Other .9 .9 .9
SQL .1 .0 .1 .2
Freeable .1 .0 .1
PL/SQL .1 .0 .1 .1
205 ------------ 1.1 .5 .0 1.1 1.1
Other 1.0 1.0 1.0
PL/SQL .1 .0 .1 .1
SQL .0 .0 .0 .1
27 ------------ 1.1 .5 .0 1.1 1.1
Other 1.0 1.0 1.0
PL/SQL .1 .0 .1 .1
SQL .0 .0 .0 .1
158 ------------ 1.1 .5 .0 1.1 1.1
Other 1.0 1.0 1.0
PL/SQL .1 .0 .1 .1
SQL .0 .0 .0 .1
172 ------------ 1.1 .5 .0 1.1 1.1
Other 1.0 1.0 1.0
PL/SQL .1 .0 .1 .1
SQL .0 .0 .0 .1
Enqueue activity DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> 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)
TX-Transaction (row lock contention)
106,475 106,474 0 106,341 20,273 190.64
TX-Transaction (index contention)
44,355 44,355 0 44,319 2,784 62.81
TX-Transaction (allocate ITL entry)
184 184 0 182 9 46.81
HW-Segment High Water Mark
1,975 1,975 0 70 5 66.29
FB-Format Block
2,164 2,164 0 50 3 54.60
TX-Transaction
394,649 394,668 0 30 0 4.33
Undo Segment Summary DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> Min/Max TR (mins) - Min and Max Tuned Retention (minutes)
-> STO - Snapshot Too Old count, OOS - Out Of Space count
-> Undo segment block stats:
uS - unexpired Stolen, uR - unexpired Released, uU - unexpired reUsed
eS - expired Stolen, eR - expired Released, eU - expired reUsed
Undo Num Undo Number of Max Qry Max Tx Min/Max STO/ uS/uR/uU/
TS# Blocks (K) Transactions Len (s) Concy TR (mins) OOS eS/eR/eU
1 117.7 322,423 49 73 15/15 0/0 0/0/0/0/0/0
Undo Segment Stats DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> Most recent 35 Undostat rows, ordered by End Time desc
Num Undo Number of Max Qry Max Tx Tun Ret STO/ uS/uR/uU/
End Time Blocks Transactions Len (s) Concy (mins) OOS eS/eR/eU
17-Aug 03:40 117,733 322,423 49 73 15 0/0 0/0/0/0/0/0
Latch Activity DB/Inst: apple22A/apple22a Snaps: 2147-2151
->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
willing-to-wait latch get requests
->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
->"Pct Misses" for both should be very close to 0.0
Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Requests Miss /Miss (s) Requests Miss
Consistent RBA 3,517 0.0 0 0
FAL request queue 11 0.0 0 0
FAL subheap alocation 11 0.0 0 0
FIB s.o chain latch 20 0.0 0 0
FOB s.o list latch 361 0.0 0 0
JS mem alloc latch 2 0.0 0 0
JS queue access latch 2 0.0 0 0
JS queue state obj latch 3,706 0.0 0 0
JS slv state obj latch 16 0.0 0 0
KGX 0 0 353,668 6.5
KMG MMAN ready and start 636 0.0 0 0
KMG resize request state 27 33.3 1.0 0 0
KTF sga latch 2 0.0 0 165 0.0
KWQP Prop Status 4 0.0 0 0
MQL Tracking Latch 0 0 11 0.0
Memory Management Latch 660 0.2 0.0 0 624 0.0
OS process 294 0.0 0 0
OS process allocation 507 0.0 0 0
OS process: request allo 333 0.0 0 0
PL/SQL warning settings 270,940 0.3 0.0 0 0
SGA IO buffer pool latch 2,654 0.0 0 5,801 0.0
SQL memory manager latch 4 0.0 0 158 0.0
SQL memory manager worka 11,158 0.0 0 0
Shared B-Tree 29 0.0 0 0
active checkpoint queue 8,205 0.0 0 0
active service list 2,335 0.0 0.0 0 174 0.0
archive control 13 0.0 0 0
archive process latch 171 0.0 0 0
buffer pool 139 0.0 0 0
cache buffer handles 46,062 0.1 0.0 0 0
cache buffers chains 457,192,374 0.2 0.0 1082 3,785,637 0.6
cache buffers lru chain 447,547 0.5 0.3 8 90,454,746 2.6
cache table scan latch 0 0 11,447 0.0
cas latch 100 0.0 0 0
channel handle pool latc 333 0.0 0 0
channel operations paren 8,286 0.0 0 0
checkpoint queue latch 199,380 0.0 0.0 0 386,367 0.0
client/application info 1,208 0.0 0 0
compile environment latc 791,470 0.0 0.1 1 0
dml lock allocation 3,552,580 0.5 0.1 117 0
dummy allocation 336 0.3 0.0 0 0
enqueue hash chains 5,288,101 0.3 0.1 45 23,479 0.4
enqueues 1,120,394 0.1 0.1 2 0
event group latch 239 0.0 0 0
file cache latch 2,388 0.0 0 0
global KZLD latch for me 236 0.0 0 0
hash table column usage 0 0 4,564 0.0
hash table modification 30 0.0 0 0
job workq parent latch 0 0 4 0.0
job_queue_processes para 11 0.0 0 0
Latch Activity DB/Inst: apple22A/apple22a Snaps: 2147-2151
->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
willing-to-wait latch get requests
->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
->"Pct Misses" for both should be very close to 0.0
Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Requests Miss /Miss (s) Requests Miss
kks stats 302 0.0 0 0
ksuosstats global area 58 0.0 0 0
ktm global data 270 0.0 0 0
kwqbsn:qsga 29 0.0 0 0
lgwr LWN SCN 3,520 0.0 0 0
library cache 19,899,407 0.4 0.0 199 16,683 ######
library cache load lock 1,030 0.0 0 63 0.0
library cache lock 17,688 0.2 0.0 0 0
library cache lock alloc 990 0.0 0 0
library cache pin 19,007,237 0.2 0.0 35 1,074 0.0
library cache pin alloca 681 0.0 0 0
list of block allocation 1,042 0.1 1.0 0 0
longop free list parent 8 0.0 0 16 12.5
messages 38,525 0.0 0.0 0 0
mostly latch-free SCN 2,543,316 0.1 0.0 0 0
multiblock read objects 30,207 0.0 1.0 0 0
ncodef allocation latch 8 0.0 0 0
object queue header heap 10 0.0 0 1,365 0.0
object queue header oper 1,198,162 0.1 0.1 0 0
object stats modificatio 832 0.0 0 0
parallel query alloc buf 64 0.0 0 0
parameter table allocati 116 1.7 0.5 0 0
post/wait queue 28,580 0.4 0.0 0 8,842 0.0
process allocation 333 0.0 0 239 0.0
process group creation 333 0.0 0 0
qmn state object latch 1 0.0 0 0
qmn task queue latch 124 0.0 0 0
redo allocation 22,668 2.0 0.2 1 9,366,319 0.5
redo copy 13 76.9 1.3 0 9,367,099 0.4
redo on-disk SCN 11,212 0.0 0 0
redo writing 23,270 0.0 0.0 0 0
resmgr group change latc 244 0.0 0 0
resmgr:actses active lis 347 0.0 0 0
resmgr:actses change gro 238 0.0 0 0
resmgr:free threads list 335 0.3 0.0 0 0
resmgr:schema config 12 0.0 0 0
rm cas latch 1,038 0.0 0 0
row cache objects 464,390 0.0 0.0 0 0
rules engine rule set st 400 0.0 0 0
sequence cache 752 0.0 0 0
session allocation 1,627,067 0.2 0.0 1 0
session idle bit 1,875,662 0.0 0.0 0 0
session state list latch 486 0.0 0 0
session switching 8 0.0 0 0
session timer 174 0.0 0 0
shared pool 58,091 0.3 0.3 1 0
simulator hash latch 32,009,012 0.0 0.0 0 0
simulator lru latch 20,996,297 4.9 0.0 1243 15,131 0.2
slave class 1 0.0 0 0
slave class create 3 0.0 0 0
Latch Activity DB/Inst: apple22A/apple22a Snaps: 2147-2151
->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
willing-to-wait latch get requests
->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
->"Pct Misses" for both should be very close to 0.0
Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Requests Miss /Miss (s) Requests Miss
sort extent pool 100 0.0 0 0
threshold alerts latch 29 0.0 0 0
transaction allocation 965 0.0 0 0
transaction branch alloc 8 0.0 0 0
undo global data 24,845,984 0.2 0.0 20 0
user lock 658 4.4 0.9 1 0
Latch Sleep breakdown DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> ordered by misses desc
Get Spin
Latch Name Requests Misses Sleeps Gets
simulator lru latch 20,996,297 1,020,829 20,140 1,003,339
cache buffers chains 457,192,374 1,016,828 24,247 994,418
library cache 19,899,407 86,387 3,201 83,529
undo global data 24,845,984 42,072 497 41,638
library cache pin 19,007,237 36,024 619 35,469
dml lock allocation 3,552,580 17,725 1,223 16,696
enqueue hash chains 5,288,101 14,754 1,086 13,773
simulator hash latch 32,009,012 7,219 54 7,171
session allocation 1,627,067 2,489 117 2,385
cache buffers lru chain 447,547 2,278 583 1,792
mostly latch-free SCN 2,543,316 1,814 14 1,802
enqueues 1,120,394 1,253 89 1,172
object queue header operat 1,198,162 1,010 52 965
PL/SQL warning settings 270,940 682 5 677
redo allocation 22,668 448 71 389
session idle bit 1,875,662 387 8 380
compile environment latch 791,470 176 12 165
shared pool 58,091 171 48 127
checkpoint queue latch 199,380 33 1 32
user lock 658 29 25 5
redo copy 13 10 13 0
KMG resize request state o 27 9 9 0
parameter table allocation 116 2 1 1
multiblock read objects 30,207 1 1 0
list of block allocation 1,042 1 1 0
-------------------------------------------------------------Edited by: praveenkumaar on Aug 18, 2009 4:07 AM -
Sqlquery to find out high CPU usage
Hi,
I want to find out the queries which using high CPU in a RAC database. What is the best way to find it out.
Regards,
KoushikI have executed the following query block enabling set event level 12.
begin
for i_rec in 1..4000
loop
TRD_TABLE_POPULATION;
end loop;
end;
The procedure contains deque and merge statement. Please find the output below of the trace output.
TKPROF: Release 10.1.0.2.0 - Production on Thu Oct 11 18:09:02 2007
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Trace file: orbit02_ora_5933.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
The following statement encountered a error during parse:
SELECT 1 FROM DUAL WHERE ORD.ORDL = TRD.ORDER_LINE_I
Error encountered: ORA-00904
ALTER SESSION SET EVENTS '10046 trace name context forever, level 12'
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: 280
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 74.65 74.65
begin
for i_rec in 1..4000
loop
TRD_TABLE_POPULATION;
end loop;
end;
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 1.13 1.22 11 2257403 970 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 1.13 1.23 11 2257403 970 0
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 280
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#,
sample_size, minimum, maximum, distcnt, lowval, hival, density, col#,
spare1, spare2, avgcln
from
hist_head$ where obj#=:1 and intcol#=:2
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 26 0.00 0.00 0 0 0 0
Fetch 26 0.00 0.00 0 103 0 25
total 53 0.00 0.00 0 103 0 25
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: RULE
Parsing user id: SYS (recursive depth: 3)
select metadata
from
kopm$ where name='DB_FDO'
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 2 0 1
total 3 0.00 0.00 0 2 0 1
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 1)
Rows Row Source Operation
1 TABLE ACCESS BY INDEX ROWID KOPM$ (cr=2 pr=0 pw=0 time=19 us)
1 INDEX UNIQUE SCAN I_KOPM1 (cr=1 pr=0 pw=0 time=11 us)(object id 350)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
row cache lock 3 0.00 0.00
select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,o.subname,
o.dataobj#,o.flags
from
obj$ o where o.obj#=:1
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 0 8 0 2
total 6 0.00 0.00 0 8 0 2
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Rows Row Source Operation
1 TABLE ACCESS BY INDEX ROWID OBJ#(18) (cr=4 pr=0 pw=0 time=34 us)
1 INDEX UNIQUE SCAN OBJ#(36) (cr=3 pr=0 pw=0 time=21 us)(object id 36)
select /*+ INDEX(TAB) */ tab.rowid, tab.msgid, tab.corrid, tab.priority,
tab.delay, tab.expiration, tab.retry_count, tab.exception_qschema,
tab.exception_queue, tab.chain_no, tab.local_order_no, tab.enq_time,
tab.time_manager_info, tab.state, tab.enq_tid, tab.step_no,
tab.sender_name, tab.sender_address, tab.sender_protocol,
tab.dequeue_msgid, tab.user_prop, tab.cscn, tab.dscn, tab.user_data
from
"GENESYS_POC_AQ"."FM_ORDERLINE_QUEUE_TBL" tab where q_name = :1 and state =
:2 order by q_name, state, enq_time, step_no, chain_no, local_order_no
for update skip locked
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 968 0.36 0.34 0 165 0 0
Fetch 968 0.10 0.05 0 4840 0 0
total 1937 0.46 0.39 0 5005 0 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 1)
MERGE INTO FM_ORDERLINES_TRD TRD USING (SELECT :B41 ORDL, :B40 SYSINS, :B39
CUST_ORD_ID, :B38 SERV_ID, :B37 INS_TEL, :B36 CUST_REQ_DATE, :B35
CUST_AGG_DATE, :B34 RCV_DATE, :B33 APP_DATE, :B32 APP_TIME, :B31 COMM_DATE,
:B30 EU_POST_CODE, :B29 PROD, :B28 SER_PRV, :B27 EXCH_ID, :B26 SRV_CARE_LVL,
:B25 ORD_TYPE, :B24 CAN_RES, :B23 AU_DELAY_RES, :B22 BILL_ACC_NO, :B21
CUST_ID, :B20 ACC_LINE_ID, :B19 COMP_DATE, :B18 COOR_ID, :B17 LOP_ID, :B16
EXCH_NAME, :B15 MDF_SITE, :B14 DES_DP, :B13 MPF_TIE_CABLE, :B12
MPF_TIE_PAIR, :B11 MPF_TIE_PAIR_ST, :B10 PSTN_ORD_NUM, :B9
PSTN_TIE_CABLE_ID, :B8 PSTN_TIE_PAIR_ST, :B7 CP_CONTACT_NUM, :B6
LINK_ORD_REF, :B5 BT_POST, :B4 CSS_SMPF_ORD, :B3 MNG_BES_ID, :B2 CSS_PROD,
:B1 CSS_DRV FROM DUAL) ORD ON(ORD.ORDL = TRD.ORDER_LINE_ID) WHEN MATCHED
THEN UPDATE SET TRD.SYSTEM_INSTANCE = ORD.SYSINS , TRD.CUST_ORDER_ID =
ORD.CUST_ORD_ID, TRD.SERVICE_ID =ORD.SERV_ID, TRD.INSTALLATION_TELEPHONE =
ORD.INS_TEL, TRD.CUSTOMER_REQ_DATE =ORD.CUST_REQ_DATE,
TRD.CUSTOMER_AGREED_DATE =ORD.CUST_AGG_DATE, TRD.RECEIVED_DATE =
ORD.RCV_DATE, TRD.APPOINTMENT_DATE =ORD.APP_DATE, TRD.APPOINTMENT_TIME =
ORD.APP_TIME, TRD.COMMIT_DATE =ORD.COMM_DATE, TRD.EU_POSTCODE =
ORD.EU_POST_CODE, TRD.PRODUCT =ORD.PROD, TRD.SERVICE_PROVIDER =ORD.SER_PRV,
TRD.EXCHANGE_ID =ORD.EXCH_ID, TRD.SERVICE_CARE_LEVEL =ORD.SRV_CARE_LVL,
TRD.ORDER_TYPE =ORD.ORD_TYPE, TRD.CANCELLED_REASON =ORD.CAN_RES,
TRD.AUTO_DELAY_REASON =ORD.AU_DELAY_RES, TRD.BILLING_ACCOUNT_NO =
ORD.BILL_ACC_NO, TRD.CUSTOMER_ID =ORD.CUST_ID, TRD.ACCESS_LINE_ID =
ORD.ACC_LINE_ID, TRD.COMPLETION_DATE =ORD.COMP_DATE, TRD.COORDINATOR_ID =
ORD.COOR_ID, TRD.LOP_ID =ORD.LOP_ID, TRD.EXCHANGE_NAME =ORD.EXCH_NAME,
TRD.MDF_SITE_ID =ORD.MDF_SITE, TRD.DESIGN_DP =ORD.DES_DP,
TRD.MPF_TIE_CABLE_ID =ORD.MPF_TIE_CABLE, TRD.MPF_TIE_PAIR_ID =
ORD.MPF_TIE_PAIR, TRD.MPF_TIE_PAIR_STATUS =ORD.MPF_TIE_PAIR_ST,
TRD.PSTN_ORDER_NO =ORD.PSTN_ORD_NUM, TRD.PSTN_TIE_CABLE_ID =
ORD.PSTN_TIE_CABLE_ID, TRD.PSTN_TIE_PAIR_STATUS =ORD.PSTN_TIE_PAIR_ST,
TRD.CP_CONTACT_NUMBER =ORD.CP_CONTACT_NUM, TRD.LINKED_ORDER_REF =
ORD.LINK_ORD_REF, TRD.BT_POSTCODE =ORD.BT_POST, TRD.CSS_SMPF_ORDER =
ORD.CSS_SMPF_ORD, TRD.MANAGE_BES_ID =ORD.MNG_BES_ID, TRD.CSS_PRODUCT_CODE =
ORD.CSS_PROD, TRD.CSS_DRIVER_CODE =ORD.CSS_DRV WHEN NOT MATCHED THEN
INSERT(TRD.ORDER_LINE_ID, TRD.SYSTEM_INSTANCE, TRD.CUST_ORDER_ID,
TRD.SERVICE_ID, TRD.INSTALLATION_TELEPHONE, TRD.CUSTOMER_REQ_DATE,
TRD.CUSTOMER_AGREED_DATE, TRD.RECEIVED_DATE, TRD.APPOINTMENT_DATE,
TRD.APPOINTMENT_TIME, TRD.COMMIT_DATE, TRD.EU_POSTCODE, TRD.PRODUCT,
TRD.SERVICE_PROVIDER, TRD.EXCHANGE_ID, TRD.SERVICE_CARE_LEVEL,
TRD.ORDER_TYPE, TRD.CANCELLED_REASON, TRD.AUTO_DELAY_REASON,
TRD.BILLING_ACCOUNT_NO, TRD.CUSTOMER_ID, TRD.ACCESS_LINE_ID,
TRD.COMPLETION_DATE, TRD.COORDINATOR_ID, TRD.LOP_ID, TRD.EXCHANGE_NAME,
TRD.MDF_SITE_ID, TRD.DESIGN_DP, TRD.MPF_TIE_CABLE_ID, TRD.MPF_TIE_PAIR_ID,
TRD.MPF_TIE_PAIR_STATUS, TRD.CP_CONTACT_NUMBER, TRD.LINKED_ORDER_REF,
TRD.BT_POSTCODE, TRD.CSS_SMPF_ORDER, TRD.MANAGE_BES_ID,
TRD.CSS_PRODUCT_CODE, TRD.CSS_DRIVER_CODE ) VALUES(ORD.ORDL, ORD.SYSINS,
ORD.CUST_ORD_ID, ORD.SERV_ID, ORD.INS_TEL, ORD.CUST_REQ_DATE,
ORD.CUST_AGG_DATE, ORD.RCV_DATE, ORD.APP_DATE, ORD.APP_TIME, ORD.COMM_DATE,
ORD.EU_POST_CODE, ORD.PROD, ORD.SER_PRV, ORD.EXCH_ID, ORD.SRV_CARE_LVL,
ORD.ORD_TYPE, ORD.CAN_RES, ORD.AU_DELAY_RES, ORD.BILL_ACC_NO, ORD.CUST_ID,
ORD.ACC_LINE_ID, ORD.COMP_DATE, ORD.COOR_ID, ORD.LOP_ID, ORD.EXCH_NAME,
ORD.MDF_SITE, ORD.DES_DP, ORD.MPF_TIE_CABLE, ORD.MPF_TIE_PAIR,
ORD.MPF_TIE_PAIR_ST, ORD.CP_CONTACT_NUM, ORD.LINK_ORD_REF, ORD.BT_POST,
ORD.CSS_SMPF_ORD, ORD.MNG_BES_ID, ORD.CSS_PROD, ORD.CSS_DRV )
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 968 1743.31 1791.19 0 2252195 1970 966
Fetch 0 0.00 0.00 0 0 0 0
total 969 1743.31 1791.19 0 2252195 1970 966
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: 280 (recursive depth: 1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
gc current grant 2-way 2 0.00 0.00
latch: cache buffers chains 10 0.02 0.16
INSERT INTO FM_ORDERLINES_EXP (ORDER_LINE_ID , SYSTEM_INSTANCE ,
CUST_ORDER_ID, SERVICE_ID , INSTALLATION_TELEPHONE , CUSTOMER_REQ_DATE ,
CUSTOMER_AGREED_DATE , RECEIVED_DATE , APPOINTMENT_DATE , APPOINTMENT_TIME ,
COMMIT_DATE , EU_POSTCODE , PRODUCT , SERVICE_PROVIDER , EXCHANGE_ID ,
SERVICE_CARE_LEVEL , ORDER_TYPE , CANCELLED_REASON , AUTO_DELAY_REASON ,
BILLING_ACCOUNT_NO, CUSTOMER_ID , ACCESS_LINE_ID , COMPLETION_DATE ,
COORDINATOR_ID , LOP_ID , EXCHANGE_NAME , MDF_SITE_ID , DESIGN_DP ,
MPF_TIE_CABLE_ID, MPF_TIE_PAIR_ID , MPF_TIE_PAIR_STATUS , PSTN_ORDER_NO ,
PSTN_TIE_CABLE_ID , PSTN_TIE_PAIR_STATUS , CP_CONTACT_NUMBER,
LINKED_ORDER_REF, BT_POSTCODE , CSS_SMPF_ORDER , MANAGE_BES_ID ,
CSS_PRODUCT_CODE , CSS_DRIVER_CODE)
VALUES
(:B41 , :B40 , :B39 , :B38 , :B37 , :B36 , :B35 , :B34 , :B33 , :B32 , :B31 ,
:B30 , :B29 , :B28 , :B27 , :B26 , :B25 , :B24 , :B23 , :B22 , :B21 , :B20
, :B19 , :B18 , :B17 , :B16 , :B15 , :B14 , :B13 , :B12 , :B11 , :B10 , :B9
, :B8 , :B7 , :B6 , :B5 , :B4 , :B3 , :B2 , :B1 )
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.05 0.17 11 177 6 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.05 0.17 11 177 6 1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: 280 (recursive depth: 1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
library cache lock 2 0.00 0.00
library cache pin 1 0.00 0.00
row cache lock 3 0.00 0.00
rdbms ipc reply 1 0.00 0.00
enq: TM - contention 2 0.00 0.00
db file sequential read 4 0.01 0.03
gc cr grant 2-way 1 0.00 0.00
gc current grant 2-way 2 0.00 0.00
select obj#,type#,ctime,mtime,stime,status,dataobj#,flags,oid$, spare1,
spare2
from
obj$ where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null
and linkname is null and subname is null
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 5 0 1
total 3 0.00 0.00 0 5 0 1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Rows Row Source Operation
1 TABLE ACCESS BY INDEX ROWID OBJ#(18) (cr=5 pr=0 pw=0 time=149 us)
1 INDEX RANGE SCAN OBJ#(37) (cr=4 pr=0 pw=0 time=135 us)(object id 37)
select t.ts#,t.file#,t.block#,nvl(t.bobj#,0),nvl(t.tab#,0),t.intcols,
nvl(t.clucols,0),t.audit$,t.flags,t.pctfree$,t.pctused$,t.initrans,
t.maxtrans,t.rowcnt,t.blkcnt,t.empcnt,t.avgspc,t.chncnt,t.avgrln,
t.analyzetime,t.samplesize,t.cols,t.property,nvl(t.degree,1),
nvl(t.instances,1),t.avgspc_flb,t.flbcnt,t.kernelcols,nvl(t.trigflag, 0),
nvl(t.spare1,0),nvl(t.spare2,0),t.spare4,t.spare6,ts.cachedblk,ts.cachehit,
ts.logicalread
from
tab$ t, tab_stats$ ts where t.obj#= :1 and t.obj# = ts.obj# (+)
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 5 0 1
total 3 0.01 0.00 0 5 0 1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
row cache lock 9 0.00 0.00
select i.obj#,i.ts#,i.file#,i.block#,i.intcols,i.type#,i.flags,i.property,
i.pctfree$,i.initrans,i.maxtrans,i.blevel,i.leafcnt,i.distkey,i.lblkkey,
i.dblkkey,i.clufac,i.cols,i.analyzetime,i.samplesize,i.dataobj#,
nvl(i.degree,1),nvl(i.instances,1),i.rowcnt,mod(i.pctthres$,256),
i.indmethod#,i.trunccnt,nvl(c.unicols,0),nvl(c.deferrable#+c.valid#,0),
nvl(i.spare1,i.intcols),i.spare4,i.spare2,i.spare6,decode(i.pctthres$,null,
null,mod(trunc(i.pctthres$/256),256)),ist.cachedblk,ist.cachehit,
ist.logicalread
from
ind$ i, ind_stats$ ist, (select enabled, min(cols) unicols,
min(to_number(bitand(defer,1))) deferrable#,min(to_number(bitand(defer,4)))
valid# from cdef$ where obj#=:1 and enabled > 1 group by enabled) c where
i.obj#=c.enabled(+) and i.obj# = ist.obj#(+) and i.bo#=:1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 4 0 0
total 3 0.01 0.00 0 4 0 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
row cache lock 6 0.00 0.00
select /*+ rule */ bucket, endpoint, col#, epvalue
from
histgrm$ where obj#=:1 and intcol#=:2 and row#=:3 order by bucket
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 14 0.00 0.00 0 0 0 0
Fetch 14 0.01 0.04 5 42 0 245
total 29 0.01 0.04 5 42 0 245
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: RULE
Parsing user id: SYS (recursive depth: 3)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
gc cr grant 2-way 3 0.00 0.00
db file sequential read 5 0.01 0.03
select name,intcol#,segcol#,type#,length,nvl(precision#,0),decode(type#,2,
nvl(scale,-127/*MAXSB1MINAL*/),178,scale,179,scale,180,scale,181,scale,182,
scale,183,scale,231,scale,0),null$,fixedstorage,nvl(deflength,0),default$,
rowid,col#,property, nvl(charsetid,0),nvl(charsetform,0),spare1,spare2,
nvl(spare3,0)
from
col$ where obj#=:1 order by intcol#
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 42 0.00 0.00 0 4 0 41
total 44 0.00 0.00 0 4 0 41
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
row cache lock 3 0.00 0.00
select con#,obj#,rcon#,enabled,nvl(defer,0)
from
cdef$ where robj#=:1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 2 0 0
total 3 0.01 0.00 0 2 0 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
select con#,type#,condlength,intcols,robj#,rcon#,match#,refact,nvl(enabled,0),
rowid,cols,nvl(defer,0),mtime,nvl(spare1,0)
from
cdef$ where obj#=:1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.03 2 2 0 0
total 3 0.00 0.03 2 2 0 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
row cache lock 6 0.00 0.00
db file sequential read 2 0.01 0.03
gc cr grant 2-way 1 0.00 0.00
select type#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,
NVL(lists,65535),NVL(groups,65535),cachehint,hwmincr, NVL(spare1,0),
NVL(scanhint,0)
from
seg$ where ts#=:1 and file#=:2 and block#=:3
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 4 0 1
total 3 0.00 0.00 0 4 0 1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Rows Row Source Operation
0 TABLE ACCESS CLUSTER SEG$ (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (cr=0 pr=0 pw=0 time=0 us)(object id 9)
select col#, grantee#, privilege#,max(mod(nvl(option$,0),2))
from
objauth$ where obj#=:1 and col# is not null group by privilege#, col#,
grantee# order by col#, grantee#
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 2 0 0
total 3 0.01 0.00 0 2 0 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
select grantee#,privilege#,nvl(col#,0),max(mod(nvl(option$,0),2))
from
objauth$ where obj#=:1 group by grantee#,privilege#,nvl(col#,0) order by
grantee#
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 2 0 0
total 3 0.00 0.00 0 2 0 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
select u.name,o.name, t.update$, t.insert$, t.delete$, t.enabled
from
obj$ o,user$ u,trigger$ t where t.baseobject=:1 and t.obj#=o.obj# and
o.owner#=u.user# and bitand(property,16)=0 and bitand(property,8)=0 order
by o.obj#
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 1 0 0
total 3 0.00 0.00 0 1 0 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Rows Row Source Operation
0 SORT ORDER BY (cr=1 pr=0 pw=0 time=55 us)
0 NESTED LOOPS (cr=1 pr=0 pw=0 time=36 us)
0 NESTED LOOPS (cr=1 pr=0 pw=0 time=34 us)
0 TABLE ACCESS BY INDEX ROWID TRIGGER$ (cr=1 pr=0 pw=0 time=33 us)
0 INDEX RANGE SCAN I_TRIGGER1 (cr=1 pr=0 pw=0 time=23 us)(object id 123)
0 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us)(object id 36)
0 TABLE ACCESS CLUSTER USER$ (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN I_USER# (cr=0 pr=0 pw=0 time=0 us)(object id 11)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 2 1.13 1.22 11 2257403 970 0
Fetch 0 0.00 0.00 0 0 0 0
total 3 1.13 1.23 11 2257403 970 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 74.65 74.65
row cache lock 2 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 18 0.00 0.01 0 0 0 0
Execute 1990 1743.76 1791.75 11 2252537 1976 967
Fetch 1062 0.11 0.12 7 5026 0 317
total 3070 1743.87 1791.89 18 2257563 1976 1284
Misses in library cache during parse: 17
Misses in library cache during execute: 16
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
row cache lock 28 0.00 0.00
gc current grant 2-way 4 0.00 0.00
latch: cache buffers chains 10 0.02 0.16
library cache lock 2 0.00 0.00
library cache pin 1 0.00 0.00
rdbms ipc reply 1 0.00 0.00
gc cr grant 2-way 5 0.00 0.00
db file sequential read 11 0.01 0.10
enq: TM - contention 2 0.00 0.00
4 user SQL statements in session.
16 internal SQL statements in session.
20 SQL statements in session.
Trace file: orbit02_ora_5933.trc
Trace file compatibility: 10.01.00
Sort options: default
1 session in tracefile.
4 user SQL statements in trace file.
16 internal SQL statements in trace file.
20 SQL statements in trace file.
19 unique SQL statements in trace file.
91823 lines in trace file.
1867 elapsed seconds in trace file.
Can you please tell me why a simple merge statement using that much of CPU.
And how do I restrict the usage.
Regards,
Koushik -
Hi,
in my 9.2.0.8 database i've found high latch: session allocation.
In addition to this my tnslnr process consume high cpu e paging space:
Name PID CPU% PgSp Owner
tnslsnr 3256468 6.1 780.6 ora9R2
oracle 5017828 2.9 4.6 ora9R2
oracle 1953934 2.7 4.3 ora9R2due to problem descripted in ml 557397.1.
Can these two problem related? Or how can i find the cause of this latch?
Thanks to all.Hi,
i've reduced the package compiled in debug mode.
Before
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
latch free 400,134 12,316 33.21
CPU time 10,641 28.69
db file sequential read 902,778 5,363 14.46
buffer busy waits 211,727 3,456 9.32
db file scattered read 322,748 2,011 5.42
Get Spin &
Latch Name Requests Misses Sleeps Sleeps 1->4
session allocation 201,688,557 6,075,154 96,070 5981249/91772/2101/32/0
library cache 244,452,480 1,392,840 161,791 1234527/154974/3220/119/0
cache buffers chains 4,075,484,598 1,060,603 79,117 998924/53273/4232/4177/0
redo allocation 60,138,195 519,535 19,525 500326/18895/312/2/0After
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
CPU time 10,684 49.91
db file sequential read 775,861 2,898 13.54
latch free 230,618 2,531 11.82
db file scattered read 294,938 1,318 6.16
db file parallel write 643,377 1,115 5.21
Get Spin &
Latch Name Requests Misses Sleeps Sleeps 1->4
session allocation 205,203,998 5,141,166 60,448 5081610/58670/880/6/0
library cache 250,958,548 1,390,770 102,917 1289488/99715/1521/46/0
cache buffers chains 4,023,791,844 1,305,675 34,095 1274720/29256/967/732/0
library cache pin 225,720,010 407,695 9,712 398039/9600/56/0/0There is an improvement but session allocation latch is still high.
Edited by: 842366 on 27-dic-2011 5.53 -
Oracle 10.2.0.4 library cache contention,every event wait 64s! strange
my database suddently very slow in a few seconds.After a while, all become normal.
In awr report,I find no special sql.
I paste two trouble time awr report here.
If you have any more information for troubleshooting ,I will paste if you require.
Thanks.
AWR report1:
WORKLOAD REPOSITORY report for
DB Name DB Id Instance Inst Num Release RAC Host
DB 3594421410 db2 2 10.2.0.4.0 YES db2
Snap Id Snap Time Sessions Curs/Sess
Begin Snap: 2342 17-Mar-09 21:30:23 521 1.1
End Snap: 2344 17-Mar-09 22:30:25 498 1.0
Elapsed: 60.03 (mins)
DB Time: 750.95 (mins)
Cache Sizes
~~~~~~~~~~~ Begin End
Buffer Cache: 3,504M 3,504M Std Block Size: 8K
Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 18,182.64 2,754.51
Logical reads: 326.19 49.41
Block changes: 123.54 18.72
Physical reads: 21.33 3.23
Physical writes: 7.29 1.10
User calls: 178.46 27.03
Parses: 62.04 9.40
Hard parses: 0.09 0.01
Sorts: 2.00 0.30
Logons: 0.20 0.03
Executes: 63.12 9.56
Transactions: 6.60
% Blocks changed per Read: 37.87 Recursive Call %: 17.93
Rollback per transaction %: 14.26 Rows per Sort: 44.63
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.99 Redo NoWait %: 99.95
Buffer Hit %: 93.46 In-memory Sort %: 100.00
Library Hit %: 99.52 Soft Parse %: 99.86
Execute to Parse %: 1.70 Latch Hit %: 99.97
Parse CPU to Parse Elapsd %: 0.82 % Non-Parse CPU: 98.60
Shared Pool Statistics Begin End
Memory Usage %: 78.60 78.77
% SQL with executions>1: 99.38 99.27
% Memory for SQL w/exec>1: 99.00 98.78
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
latch: library cache 736 47,078 63965 104.5 Concurrenc
CPU time 236 0.5
rdbms ipc reply 360 219 608 0.5 Other
log file sync 20,469 137 7 0.3 Commit
gc cr block 2-way 35,641 102 3 0.2 Cluster
AWR report 2:
DB Name DB Id Instance Inst Num Release RAC Host
db 3594421410 db2 2 10.2.0.4.0 YES yt-db2
Snap Id Snap Time Sessions Curs/Sess
Begin Snap: 2364 18-Mar-09 08:30:29 497 1.1
End Snap: 2365 18-Mar-09 08:42:28 511 1.0
Elapsed: 11.99 (mins)
DB Time: 277.14 (mins)
Cache Sizes
~~~~~~~~~~~ Begin End
Buffer Cache: 3,504M 3,504M Std Block Size: 8K
Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 23,306.73 2,556.74
Logical reads: 337.31 37.00
Block changes: 159.74 17.52
Physical reads: 0.72 0.08
Physical writes: 9.74 1.07
User calls: 274.07 30.06
Parses: 95.29 10.45
Hard parses: 0.04 0.00
Sorts: 2.52 0.28
Logons: 0.19 0.02
Executes: 95.71 10.50
Transactions: 9.12
% Blocks changed per Read: 47.36 Recursive Call %: 9.14
Rollback per transaction %: 11.13 Rows per Sort: 32.48
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 98.81 Redo NoWait %: 100.00
Buffer Hit %: 99.79 In-memory Sort %: 100.00
Library Hit %: 99.86 Soft Parse %: 99.95
Execute to Parse %: 0.44 Latch Hit %: 99.94
Parse CPU to Parse Elapsd %: 40.91 % Non-Parse CPU: 81.90
Shared Pool Statistics Begin End
Memory Usage %: 79.91 80.01
% SQL with executions>1: 99.52 99.52
% Memory for SQL w/exec>1: 98.83 98.77
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
latch free 176 4,391 24950 26.4 Other
gc buffer busy 3,726 3,335 895 20.1 Cluster
gc cr multi block request 4,165 2,204 529 13.3 Cluster
gc current grant busy 3,938 1,798 457 10.8 Cluster
latch: cache buffers chains 124 1,548 12487 9.3 Concurrenc
^LRAC Statistics DB/Inst: db/db2 Snaps: 2364-2365
Begin End
Number of Instances: 2 2
Global Cache Load Profile
~~~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
Global Cache blocks received: 19.36 2.12
Global Cache blocks served: 19.39 2.13
GCS/GES messages received: 63.76 6.99
GCS/GES messages sent: 63.64 6.98
DBWR Fusion writes: 2.58 0.28
Estd Interconnect traffic (KB) 334.84
Edited by: gaoyafang on 2009-3-18 上午12:46my database suddently very slow in a few seconds.After a while, all become normal.
In awr report,I find no special sql.
I paste two trouble time awr report here.
If you have any more information for troubleshooting ,I will paste if you require.
Thanks.
AWR report1:
WORKLOAD REPOSITORY report for
DB Name DB Id Instance Inst Num Release RAC Host
DB 3594421410 db2 2 10.2.0.4.0 YES db2
Snap Id Snap Time Sessions Curs/Sess
Begin Snap: 2342 17-Mar-09 21:30:23 521 1.1
End Snap: 2344 17-Mar-09 22:30:25 498 1.0
Elapsed: 60.03 (mins)
DB Time: 750.95 (mins)
Cache Sizes
~~~~~~~~~~~ Begin End
Buffer Cache: 3,504M 3,504M Std Block Size: 8K
Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 18,182.64 2,754.51
Logical reads: 326.19 49.41
Block changes: 123.54 18.72
Physical reads: 21.33 3.23
Physical writes: 7.29 1.10
User calls: 178.46 27.03
Parses: 62.04 9.40
Hard parses: 0.09 0.01
Sorts: 2.00 0.30
Logons: 0.20 0.03
Executes: 63.12 9.56
Transactions: 6.60
% Blocks changed per Read: 37.87 Recursive Call %: 17.93
Rollback per transaction %: 14.26 Rows per Sort: 44.63
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.99 Redo NoWait %: 99.95
Buffer Hit %: 93.46 In-memory Sort %: 100.00
Library Hit %: 99.52 Soft Parse %: 99.86
Execute to Parse %: 1.70 Latch Hit %: 99.97
Parse CPU to Parse Elapsd %: 0.82 % Non-Parse CPU: 98.60
Shared Pool Statistics Begin End
Memory Usage %: 78.60 78.77
% SQL with executions>1: 99.38 99.27
% Memory for SQL w/exec>1: 99.00 98.78
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
latch: library cache 736 47,078 63965 104.5 Concurrenc
CPU time 236 0.5
rdbms ipc reply 360 219 608 0.5 Other
log file sync 20,469 137 7 0.3 Commit
gc cr block 2-way 35,641 102 3 0.2 Cluster
AWR report 2:
DB Name DB Id Instance Inst Num Release RAC Host
db 3594421410 db2 2 10.2.0.4.0 YES yt-db2
Snap Id Snap Time Sessions Curs/Sess
Begin Snap: 2364 18-Mar-09 08:30:29 497 1.1
End Snap: 2365 18-Mar-09 08:42:28 511 1.0
Elapsed: 11.99 (mins)
DB Time: 277.14 (mins)
Cache Sizes
~~~~~~~~~~~ Begin End
Buffer Cache: 3,504M 3,504M Std Block Size: 8K
Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 23,306.73 2,556.74
Logical reads: 337.31 37.00
Block changes: 159.74 17.52
Physical reads: 0.72 0.08
Physical writes: 9.74 1.07
User calls: 274.07 30.06
Parses: 95.29 10.45
Hard parses: 0.04 0.00
Sorts: 2.52 0.28
Logons: 0.19 0.02
Executes: 95.71 10.50
Transactions: 9.12
% Blocks changed per Read: 47.36 Recursive Call %: 9.14
Rollback per transaction %: 11.13 Rows per Sort: 32.48
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 98.81 Redo NoWait %: 100.00
Buffer Hit %: 99.79 In-memory Sort %: 100.00
Library Hit %: 99.86 Soft Parse %: 99.95
Execute to Parse %: 0.44 Latch Hit %: 99.94
Parse CPU to Parse Elapsd %: 40.91 % Non-Parse CPU: 81.90
Shared Pool Statistics Begin End
Memory Usage %: 79.91 80.01
% SQL with executions>1: 99.52 99.52
% Memory for SQL w/exec>1: 98.83 98.77
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
latch free 176 4,391 24950 26.4 Other
gc buffer busy 3,726 3,335 895 20.1 Cluster
gc cr multi block request 4,165 2,204 529 13.3 Cluster
gc current grant busy 3,938 1,798 457 10.8 Cluster
latch: cache buffers chains 124 1,548 12487 9.3 Concurrenc
^LRAC Statistics DB/Inst: db/db2 Snaps: 2364-2365
Begin End
Number of Instances: 2 2
Global Cache Load Profile
~~~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
Global Cache blocks received: 19.36 2.12
Global Cache blocks served: 19.39 2.13
GCS/GES messages received: 63.76 6.99
GCS/GES messages sent: 63.64 6.98
DBWR Fusion writes: 2.58 0.28
Estd Interconnect traffic (KB) 334.84
Edited by: gaoyafang on 2009-3-18 上午12:46 -
Will Oracle look into the database buffer cache in this scenario?
hi guys,
say I have a table with a million rows, there are no indexes on it, and I did a
select * from t where t.id=522,000.
About 5 minutes later (while that particular (call it blockA) block is still in the database buffer cache) I do a
select * from t where t.id >400,000 and t.id < 600,000
Would Oracle still pick blockA up from the database buffer cache? if so, how? How would it know that that block is part of our query?
thanksWithout an Index, Oracle would have done a FullTableScan on the first query. The blocks would be very quickly aged out of the buffer cache as they have been retrieved for an FTS on a large table. It is unlikely that block 'A' would be in the buffer_cache after 5minutes.
However, assuming that block 'A' is still in the buffer_cache, how does Oracle know that records for the second query are in block 'A' ? It doesn't. Oracle will attempt another FullTableScan for the second query -- even if, as in the first query -- the resultset returned is only 1 row.
Now, if the table were indexed and rows were being retrieved via the Index, Oracle would use the ROWID to get the "DBA" (DataBlockAddress) and get the hash value of that DBA to identify the 'cache buffers chain' where the block is likely to be found. Oracle will make a read request if the block is not present in the expected location.
Hemant K Chitale
http://hemantoracledba.blogspot.com
Maybe you are looking for
-
HT1937 how to get a backup password which i have never made
i tried all my password but non of them worked how do i get a password for the back up on itunes
-
How to get 8MM movies onto Imac?
I have a new Imac and an old Sony Digital 8 Handycam. Model TRV530. I have connected via firewire to the Thunderbolt Port on the Imac. The Imac is not seeing the camera at all? Any suggestions?
-
MODIFY SCREEN inactive WITH LDB OF PNP
hi i want to set a screen field no input. and this report use PNP of LDB. AT SELECTION-SCREEN OUTPUT. LOOP AT SCREEN. IF SCREEN-NAME = 'PNPMASSN'. SCREEN-INPUT = 0. MODIFY SCREEN. ENDIF. ENDLOOP. but this can't active. how Mod
-
Is there an equalizer on iTunes 12 and how to access it?
Good morning to all, I cannot find the equalizer on iTunes 12 for windows 7 whereas in v. 11 it was easily accessible. Does anyone have a hint? Thanks
-
EVERY time I close firefox it takes DOZENS if not HUNDREDS of tries to get it to come up. HELP
''dupe of https://support.mozilla.org/en-US/questions/915561'' I cant confirm the email because firefox WILL NOT OPEN......THIS IS MY PROBLEM