| |
|
|
|---|
| The following informations are about the module RAC PERFORMANCE : GENERIC APPROCH |
|
|
|
| |
|
|
| RAC PERFORMANCE : GENERIC APPROCH | Most global cache wait events that show a high total time as reported in the AWR and Statspack reports or
in the dynamic performance views are normal and may present themselves
as the top database time consumers without actually indicating a
problem;
If user response times increase and a high proportion of time waited is for global cache, then you should determine the cause.
Most reports include a breakdown of events sorted by percentage of the total time.
It is useful to start with an ADDM report, which analyzes the routinely
collected performance statistics with respect to their impact,
and points to the objects and SQL contributing most to the time waited,
and then moves on to the more detailed reports produced by AWR and Statspack. |
|
|
|
|
|
| |
|
|
Most global cache wait events that show a high total time as reported in the AWR and Statspack reports or
in the dynamic performance views are normal and may present themselves
as the top database time consumers without actually indicating a
problem;
If user response times increase and a high proportion of time waited is for global cache, then you should determine the cause.
Most reports include a breakdown of events sorted by percentage of the total time.
It is useful to start with an ADDM report, which analyzes the routinely
collected performance statistics with respect to their impact,
and points to the objects and SQL contributing most to the time waited,
and then moves on to the more detailed reports produced by AWR and Statspack. |
|
|
|
|
|
| |
|
|
| Block-Related Wait Events | The main wait events for block-related waits are:
gc current block 2-way
gc current block 3-way
gc cr block 2-way
gc cr block 3-way
The block-related wait event statistics indicate that a block was received as either the result of a 2-way or a 3-way message,
2-way : the block was sent from the resource master requiring 1 message and 1 transfer.
3-way : the block was forwarded to a third node from which it was sent, requiring 2 messages and 1 block transfer.
|
| Contention-Related Wait Events | The main wait events for contention-related waits are:
gc current block busy
gc cr block busy
gc buffer busy acquire/release
The contention-related wait event statistics indicate that a block was received which was pinned by a session on another node,
was deferred because a change had not yet been flushed to disk or
because of high concurrency, and therefore could not be shipped
immediately
The gc current block busy and gc cr block busy wait events indicate that
the local instance that is making the request did not immediately
receive a current or consistent read block.
The term busy in these events' names indicates that the sending of the block was delayed on a remote instance.
For example, a block cannot be shipped immediately if Oracle Database
has not yet written the redo for the block's changes to a log file.
In comparison to block busy wait events, a gc buffer busy event
indicates that Oracle Database cannot immediately grant access to data
that is stored in the local buffer cache.
This is because a global operation on the buffer is pending and the operation has not yet completed.
In other words, the buffer is busy and all other processes that are attempting to access the local buffer must wait to complete
|
| Load-Related Wait Events |
The main wait events for load-related waits are:
gc current block congested
gc cr block congested
The load-related wait events indicate that a delay in processing has occurred in the GCS,
which is usually caused by high load, CPU saturation and would have to be solved by additional CPUs,
load-balancing, off loading processing to different times or a new cluster node.
For the events mentioned, the wait time encompasses the entire round
trip from the time a session starts to wait after initiating a block
request until the block arrives.
|
| Message-Related Wait Events | The main wait events for message-related waits are:
gc current grant 2-way
gc cr grant 2-way
The message-related wait event statistics indicate that no block was received because it was not cached in any instance.
Instead a global grant was given, enabling the requesting instance to
read the block from disk(cr grant) or modify it(current grant).
If the time consumed by these events is high, then it may be assumed
that the frequently used SQL causes a lot of disk I/O (in the event of
the cr grant) or
that the workload inserts a lot of data and needs to find and format new blocks frequently (in the event of the current grant).
|
|
|
|
|
|
| |
|
|
| 1 | SELECT
A.VALUE "GC BLOCKS LOST 1",
B.VALUE "GC BLOCKS CORRUPT 1",
C.VALUE "GC BLOCKS LOST 2",
D.VALUE "GC BLOCKS CORRUPT 2"
FROM GV$SYSSTAT A, GV$SYSSTAT B, GV$SYSSTAT C, GV$SYSSTAT D
WHERE A.INST_ID=1 AND A.NAME='gc blocks lost'
AND B.INST_ID=1 AND B.NAME='gc blocks corrupt'
AND C.INST_ID=2 AND C.NAME='gc blocks lost'
AND D.INST_ID=2 AND D.NAME='gc blocks corrupt'; | global cache blocks lost and global cache blocks corrupt should always be as near to zero as possible |
|
|
|
|
|
| |
|
|
| Measuring block transfer time | Contention in blocks can be measured by using the block transfer time.
To determine
block transfer time, examine the statistics global cache cr block receive time and global cache
cr blocks received. |
|
|
|
|
|
|
|
Aucun commentaire:
Enregistrer un commentaire