| From: | Steve Adams |
| Date: | 31-Aug-2000 16:03 |
| Subject: | Contention for the cache buffers chains latches |
No, your sleeps are not distributed evenly. It is not possible to attribute the
sleeps to individual blocks. You should run the second query repeatedly to find
out which of those blocks persist in the cache. Those are the most likely to be
the hot blocks causing the latch contention (but not necessarily so).
The block from file number 0 is from the SYSTEM tablespace. File numbers in the
X$ tables often fail to correspond directly to the file numbers shown in the
data dictionary. In general, these file numbers just need to be adjusted by 1
before joining to a data dictionary table. However, there is an exception in 8.1
which I'll treat in a separate mail to answers.
-----Original Message-----
Sent: Thursday, 31 August 2000 4:48
I ran your script the hot_hash_latches i got this output.
CHILD# SLEEPS CUR_BUFFERS CR_BUFFERS
--------- ---------- ----------- ----------
12721 7203 7 0
10052 6630 5 6
10254 4850 5 0
12840 4676 6 1
10248 2117 7 0
10170 1642 3 0
15594 1410 3 0
12722 1407 8 0
5981 1118 5 0
9154 799 3 0
9159 634 2 0
9153 557 3 0
9155 465 3 0
8343 239 8 0
Then i went down further and find out the the buffers mapping to the high sleeps
latches.
HLADDR CHILD# FILE# DBABLK SLEEPS
-------- ---------- ---------- ---------- ----------
02C19A38 12721 0 12720 7280
02C19A38 12721 6 159400 7280
02C19A38 12721 11 53436 7280
02C19A38 12721 5 17354 7280
02C19A38 12721 6 140193 7280
02C19A38 12721 7 17773 7280
02C19A38 12721 7 36980 7280
7 rows selected.
from the above output is sleeps are distributed evenly ? and also i see the
file# 0 i don't have any data file with file_id 0 ,can you please explain how
you interpret that.