WebIV:View NOTE:159900.1 |
![]() ![]() |
![]() |
![]() |
![]() |
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
Article-ID: <Note:159900.1>
Alias: VIEW:X$KCBLDRHIST
Circulation: PUBLISHED (INTERNAL) ***Oracle Confidential - Internal Use Only***
Folder: server.Internals.General
Topic: ** X$ Table Definitions
Title: VIEW: X$KCBLDRHIST - Direct Read HISTory - (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$KCBLDRHIST
[K]ernel [C]ache [B]uffer [L]oad management
[d]irect [r]ead [hist]ory 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
DRTHRUPT NUMBER throughput of direct reads
TOTLSLTS NUMBER Total number of slots as seen by CKPT INCREASE NUMBER Increase bit
KCBLHV_STAY 0 Do not increase number of slots
KCBLHV_INCR 1 Increase number of slots
KCBLHV_SYNC 2 Syncronize mode REALSLTS NUMBER Total number of slots as seen by the PQ slaves Notes from source: One copy of the history vector is allocated per instance.
Each entry corresponds to a different time snapshot.
Every 3 seconds, the next entry is updated.
Each entry contains the following information:
- Throughput of direct reads during the last 3 seconds expressed in
blocks per second.
- Total number of slots (1). The background process every 3 seconds adds
up the number of slots in all active sessions. This is possible
since every session maintains statistics about its number of slots.
- Total number of slots (2). Each slave running adaptive direct reads
adds regularly its number of slots to the history vector.
The reason for having two different variables representing the
same logical entity is because either of those two variables
alone is not accurate enough. For example, if just before the end
of the 3 second interval, a new slave started then (1) will not be
accurate. On the other hand, if a slave just missed the chance to
add its number of slots in the last entry, then (2) is wrong.
So before any decision is taken, we make sure that (1) is identical
to (2).
- Increase bit. This bit indicates the decision taken by the background
process for the next 3 seconds interval based on the previous history
entries. Check the note in kcblclc for more information about the
increase bit. KCBLHSZ 1000 Size of History Vector in number of rows KCBLHSLTRT 25 Minimum percentage increase in number of slots
Minimum percentage increase in throughput expressed in percentage
increase in the number of slots. For example, if we have a 40% increase
in the number of slots, then the minimum increase in
throughput needs to be 40% * 25% = 10%. So this number
correlates the increase in number of slots with the throughput.
The minimum increase in throughput is used by the background process
as will be seen later. The latter compares the current increase in
throughput with the minimum increase to determine whether to increase
the number of slots in the system or not. KCBLHTHPTRT 25
Maximum IO Wait to Cumulative time ratio where slave is CPU bound
expressed in percentage. If that IO wait to cumulative time ratio
is greater than this number, then the slave is considered IO bound
and would increase number of slots if background process indicates
to do so. Otherwise, the slave is considered CPU bound and
consequently ignores all decisions taken by the background process. KCBLHCPUBDRT 10
NOTE ON PERSISTENT AND NONPERSISTENT STATE FOR ADAPTIVE READS:
The state for adaptive direct reads is composed of a persistent and
nonpersistent state. Persistent state means that kcbl state is
maintained across uses of a load descriptor. In other words, the
state is maintained across kcbldrini calls. The reason for that is
that sometimes kcbldrini is called multiple times for the same table
or index... We don't want to restart the adaptation from scratch
everytime kcbldrini is called. Instead we would like to maintain some
state so that in case kcbldrini is called again on that same object,
no redundant adaptation is needed.