Venzi's Tech-Blog

29 October 2008

Private strand flush not complete

Filed under: Oracle — Venzi @ 15:10

Today I got a message in the alert log which is new to me:

Thread 1 cannot allocate new log, sequence 607
Private strand flush not complete

Private strand flush not complete… sounds similar to checkpoint not complete. So the next step brought me to Metalink and there I found note 372557.1.

What you can read in there is that Oracle hasn’t completed writing all the redo information to the log at the logfile switch. It is also written that this is similar to a “checkpoint not complete” except that this only involves the redo being written to the log and that the log switch can not occur until all of the redo has been written.

The next thing: What’s a private strand?

Oracle says:

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.

When you switch logs all private strands have to be flushed to the current log before the switch is allowed to proceed.

So all in all this isn’t a bug or an error. As said above it’s similar to the “checkpoint not complete” message and can be also handled that way!

3 Comments »

  1. […] Private strand flush not complete October 2008 4 […]

    Pingback by 2010 in review « Venzi's Weblog — 2 January 2011 @ 18:56 | Reply

  2. Hello,
    When i backing up database with rman and my backup was hang. I saw in alertlog file and I got this error:
    Thread 1 cannot allocate new log, sequence 57656
    Private strand flush not complete
    Current log# 13 seq# 57655 mem# 0: /u01/app/oracle/oradata/vtadb/redo13.log
    Thread 1 advanced to log sequence 57656
    Current log# 9 seq# 57656 mem# 0: /u01/app/oracle/oradata/vtadb/redo9.log

    How can i fix this. Thank in advance

    —Huyen Nguyen——–

    Comment by Huyen — 9 October 2011 @ 22:25 | Reply

    • Hi Huygen,

      First of all: Are you sure that this is the actual issue and not only a red herring that you have here in the alert log? The reason why I ask: Private strand flush not complete should definitely not bring the database into a hanging state but just make rman going slower as it has to wait until the private strand completed it’s redo writing into the log section.
      However, private strand flush not complete as well as checkpoint not complete can be tuned in various reasons:
      * Increase the size of the log files – Therefore the redo logs do not have to switch so often and the private strands have more time to flush
      * Put redo logs on faster disks – Faster writing operations means the private strands completing faster
      If you see a lot of those or “checkpoint incomplete” I would definitely recommend to increase the size of the redo logs. They are most likely too small for the amount of redo being generated!
      But again, I would first check if that is actually your problem. If the database comes into a complete hanging state, I highly doubt it that this is your issue!

      Thx,

      Venzi

      Comment by Venzi — 11 October 2011 @ 22:06 | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: