oracle internal: VIEW: X$KCBKPFS - PreFetch Statistics - (9.0)

时间:2024-01-01 10:33:39
WebIV:View NOTE:159898.1   oracle internal: VIEW: X$KCBKPFS - PreFetch Statistics - (9.0) oracle internal: VIEW: X$KCBKPFS - PreFetch Statistics - (9.0) oracle internal: VIEW: X$KCBKPFS - PreFetch Statistics - (9.0) oracle internal: VIEW: X$KCBKPFS - PreFetch Statistics - (9.0) oracle internal: VIEW: X$KCBKPFS - PreFetch Statistics - (9.0)

Note (Sure)
- Note    Mods
- Note Refs
Error
ORA 600
TAR
TAR-Info
Bug
Bug Matrix
RFI
Diary
Events
Parameters
Locks
Latches
Views
Pkg/Proc
Statistics
Wait Events
Function
BugDB User
Port Names
Prod/Comp
Doc Part
        
Get
Explode
Mail
Fax
Mark
Tag
Tag-References
Check-References
Show Remarks
Edit
Edit (Full Header)
Copy (Full Header)
Attachments
Show Doc Stats
Show ML  Copy

oracle internal: VIEW: X$KCBKPFS - PreFetch Statistics - (9.0)


Article-ID: <Note:159898.1>
Alias: VIEW:X$KCBKPFS
Circulation: PUBLISHED (INTERNAL) ***Oracle Confidential - Internal Use Only***
Folder: server.Internals.General
Topic: ** X$ Table Definitions
Title: VIEW: X$KCBKPFS - PreFetch Statistics - (9.0)
Document-Type: REFERENCE
Impact: LOW
Skill-Level: NOVICE
Server-Version: 09.00
Updated-Date: 05-OCT-2001 05:27:02
References:
Shared-Refs:
Authors: MEPRESTO.US
Attachments: NONE
Content-Type: TEXT/PLAIN
Products: 5/RDBMS (9.0);

View: X$KCBKPFS
[K]ernal [C]ache [B]uffer chec[K]point management
[P]re[F]etch [S]tats Column Type Description
-------- ---- --------
ADDR RAW(4|8) address of this row/entry in the array or SGA
INDX NUMBER index number of this row in the fixed table array
INST_ID NUMBER oracle instance number
BUFFER_POOL_ID NUMBER Buffer Pool
TIMESTAMP NUMBER Timestamp
PREFETCH_OPS NUMBER number of prefetch operations
PREFETCH_BLOCKS NUMBER number of blocks prefetched
WASTED_BLOCKS NUMBER number of prefetched blocks wasted
CLIENTS_PREFETCH NUMBER number of clients actually prefetching buffers
PREFETCH_LIMIT NUMBER Limit to be used by for each prefetch operation Notes: This is maintained by the CKPT process which fills in an entry for each timeout period. Size of prefech history is limited to 50 per buffer pool. This section deals with controlling prefetching through the cache. This
is used to determine whether prefetch is wasteful i.e are prefetched blocks
being aged out of the cache before they can be used? This can happen,
for example, if there is a lot of recycling activity in the cache and
each client of the cache prefetched a large number of blocks into the cache. To prevent this the following algorithm is used to limit the amount
of prefetching done in each buffer pool: A history buffer is maintained per buffer pool. This buffer maintains
a history of prefetching performance. This is populated through a
timeout action. The history buffer contains the following information
in each entry (struct kcbkpfs):
- Timestamp at which entry was created.
- Number of prefetch operations since the last timeout action.
- Number of blocks prefetched in this period.
- Number of prefetched blocks that were wasted - this refers to
blocks that were prefetched but had to be aged out before
they could be pinned.
- Prefetch limit (this is the value computed by this function)
- Number of prefetching clients (as a snapshot at the time this
function is executed)
- Number of buffers being read at this time. The algorithm uses the history to determine the prefetch limit. It
the last few history entries (defined by KCBK_HIST_WINDOW) and then
computes the cumulative number of prefetch operations, prefetched
blocks and wasted prefetch blocks over this window. It then applies
the following rules to adjust the limit: - If there are no prefetched blocks, then set the limit to
Q/C where Q is the prefetch quota (in number of buffers) and
C is the number of clients performing prefetching - If there are prefetched blocks and some of them were wasted.
In this case, the limit is reduced by the fraction (P - W)/P
where P is the number of blocks prefetched over the history
window and W is the number of prefetched blocks that were wasted.
If W happens to be greater than P, this implies that the buffers
that were prefetched before the history window were wasted in
this time interval. In this case, we reduce the limit to half
its value. - If there are no wasted prefetch blocks, then there are 3 cases: (a) The number of clients has gone down - in this case we
double the prefetch limit. If this causes any wasted prefetches
it will be reduced by that fraction in the next timeout. Note
that the increase is limited by the ratio (Q/C') where Q is
the prefetch quota and C' is the new number of clients. (b) The number of clients has increased - retain the limit as long
as the it is less than (Q/C') (same ratio as above). If not,
set it to Q/C' (c) The number of clients remains the same - The limit is doubled
if the number of prefetched buffers has decreased by atleast
25% (again subject to the Q/C limit), otherwise the limit is
retained. The rationale is that if the number of prefetched
buffers has gone down, the clients have reduced their
prefetching, so increasing the limit may not lead to wasted
prefetches. Note that if the increase in the limit leads to wasted prefetching,
then at the next timeout, the limit will be reduced by the fraction
of the prefetched blocks that were wasted. oracle internal: VIEW: X$KCBKPFS - PreFetch Statistics - (9.0)