In this Document
Symptoms
Changes
Cause
Solution
References
Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.1.0.7 - Release: 10.2 to 11.1Information in this document applies to any platform.
Private strand flush not complete
Symptoms
"Private strand flush not complete" messages are being populated to the alert log, example:...
Fri May 19 12:47:29 2006
Thread 1 cannot allocate new log, sequence 18358
Private strand flush not complete
Current log# 7 seq# 18357 mem# 0: /u03/oradata/bitst/redo07.log
Thread 1 advanced to log sequence 18358
Current log# 8 seq# 18358 mem# 0: /u03/oradata/bitst/redo08.log
...
> />
Changes
When you switch logs all private strands have to be flushed to the current log before the switch is allowed to proceed.
Cause
The message means that we haven't completed writing all the redo
information to the log when we are trying to switch. It is similar in
nature to a "checkpoint not complete" except that is only involves the
redo being written to the log. The log switch can not occur until all of
the redo has been written.
A "strand" is new terminology for 10g and it deals with latches for redo .
Strands
are a mechanism to allow multiple allocation latches for processes to
write redo more efficiently in the redo buffer and is related to the
log_parallelism parameter present in 9i.
The concept of a strand
is to ensure that the redo generation rate for an instance is optimal
and that when there is some kind of redo contention then the number of
strands is dynamically adjusted to compensate.
The initial
allocation for the number of strands depends on the number of CPU's and
is started with 2 strands with one strand for active redo generation.
For
large scale enterprise systems the amount of redo generation is large
and hence these strands are *made active* as and when the foregrounds
encounter this redo contention (allocated latch related contention) when
this concept of dynamic strands comes into play.
There is always shared strands and a number of private strands .
Oracle 10g has some major changes in the mechanisms for redo (and undo), which seem to be aimed at reducing contention.
Instead of redo being recorded in real time, it can be recorded 'privately' and pumped into the redo log buffer on commit.
Similary
the undo can be generated as 'in memory undo' and applied in bulk. This
affect the memory used for redo management and the possibility to flush
it in pieces. The message you get is related to internal Cache Redo
File management.
...You can disregard these messages as normal messages.
Solution
These messages are not a cause for concern unless there is a
significant time gap between the "cannot allocate new log" message and
the "advanced to log sequence" message.
Changing the db_writer_process value, can in some situations avoid the message from being generated
References
|
产品
|
相关内容
返回页首