The buffer state indicates the status of a
buffer in the local cache of an instance.
Information about the buffer state can be seen
in the dynamic performance view
v$bh.
The buffer state of a block relates to the
access mode of the block. For example, if a
buffer state is in exclusive current (XCUR)
state, it indicates that the instance owns the
resource in exclusive mode.
To see a buffer’s state, query the STATUS column
of the
v$bh
dynamic performance view. The
v$bh view provides information
about the block access mode and their buffer
state names as follows:
-
Buffer state ‘CR’
- indicates that the block access
mode is
N (null). It means the owning instance can
perform a consistent read
of the block, if the instance holds an older
version of the data.
-
Buffer state ‘SCUR’
- indicates that the block access mode is S
(shared). It means the instance has shared
access
to the block and can only perform reads.
-
Buffer state ‘XCUR’
- indicates that access mode is X
(exclusive). It means the instance has
exclusive access to the block and can modify
it.
-
Buffer state ‘PI’
- indicates that block access mode is
N (null). It
means that the instance has made changes to
the block but retains copies of past images.
BLOCK ACCESS MODE
|
BUFFER STATE NAME
|
DESCRIPTION
|
X
|
XCUR
|
Instance has exclusive access to the
block and therefore can modify the block
|
S
|
SCUR
|
Instance has shared access to the block
and can only perform reads
|
NULL
|
CR
|
Contains an older version of the data.
Can perform consistent read
|
--
|
PI
|
Past Image Exist
(useful for recovery)
|
Table 2.3:
Buffer States Shown in v$bh View
Only the SCUR and PI buffer states are real
application cluster-specific. There can be only
one copy of any block buffered in the XCUR state
at any time. To perform modifications on a
block, a process must assign an XCUR buffer
state to the buffer containing the data block.
For example, if another instance requests a read
access to the most current version of the same
block, then Oracle changes the access mode from
exclusive to shared, sends the current read
version of the block to the requesting instance,
and keeps a PI buffer if the buffer contained a
dirty block.
At this point, the first instance has the
current block
and the requesting instance also has the current
block in shared mode. Therefore, the role of the
resource becomes global. There can be multiple
shared current (SCUR) versions of this block
cached throughout the cluster database at any
given point of time.