ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Thread 1 cannot allocate new log, sequence 586 Private strand flush not complete

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

原创 Linux操作系统 作者:alsrt 时间:2011-08-13 17:23:42 0 删除 编辑

查看alert日志:Private strand flush not complete

The following message may be seen in the Oracle alert log on the primary server:
Thread 1 cannot allocate new log, sequence 586 Private strand flush not complete
Current log# 2 seq# 585 mem# 0: /u02/oradata/ebizsaas/redo02.log Thread 1 advanced to log sequence 586
Current log# 3 seq# 586 mem# 0: /u02/oradata/ebizsaas/redo03.log Mon Nov 10 20:00:03 2008 Thread 1 cannot allocate new log, sequence 587 Private strand flush not complete
Current log# 3 seq# 586 mem# 0: /u02/oradata/ebizsaas/redo03.log Thread 1 advanced to log sequence 587
Current log# 1 seq# 587 mem# 0: /u02/oradata/ebizsaas/redo01.log


This is normal behaviour according to Oracle. They say:

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.

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

Solution:
These messages are not a cause for concern unless there is a significant gap in seq# between the "cannot allocate new log" message and the "advanced to log sequence" message.
This issue is infact not a bug and is expected behavior.

For more information please see metalink NOTE:372557.1
采取的解决方法如下:
 

1.增加三个重做日志组

alter database add logfile group 4 '/opt/oracle/oradata/orcl/redo04a.log', size 200m;

alter database add logfile group 5 ' /opt/oracle/oradata/orcl/redo05.log' size 200m;

alter database add logfile group 6 ' /opt/oracle/oradata/orcl/redo06.log' size 200m;

2.切换日志组

alter system switch logfile;

alter system switch logfile;

alter system switch logfile;

3.删除3个日志组

alter database drop logfile group1;

alter database drop logfile group2;

alter database drop logfile group3;

4:切换日志组

alter system switch logfile;

alter system switch logfile;

alter system switch logfile;

 
 


 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8410760/viewspace-732483/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-05-02

  • 博文量
    34
  • 访问量
    33667