Private strand flush not complete

在一次巡检中，发现某数据库告警日志文件中有如下错误：

Tue Feb 11 12:47:55 2014
Thread 1 cannot allocate new log, sequence 5380
Private strand flush not complete
  Current log# 3 seq# 5379 mem# 0: /dev/rxREDOLOG03

首次发现这样的报错：Private strand flush not complete

一下资料来自：

http://blog.csdn.net/tianlesoftware/article/details/6015400

一个redo条目包含了相应操作导致的数据库变化的所有信息，所有redo条目最终都要被写入redo文件中去。 Redo log buffer是为了避免Redo文件IO导致性能瓶颈而在sga中分配出的一块内存。 一个redo条目首先在用户内存(PGA)中产生，然后由oracle服务进程拷贝到log buffer中，当满足一定条件时，再由LGWR进程写入redo文件。

 

    由于log buffer是一块“共享”内存，为了避免冲突，它是受到redo allocation latch保护的，每个服务进程需要先获取到该latch才能分配redo buffer。因此在高并发且数据修改频繁的oltp系统中，我们通常可以观察到redo allocation latch的等待。

 

       为了减少redo allocation latch等待，在oracle 9.2中，引入了log buffer的并行机制。其基本原理就是，将log buffer划分为多个小的buffer，这些小的buffer被成为Shared Strand。每一个strand受到一个单独redo allocation latch的保护。多个shared strand的出现，使原来序列化的redo buffer分配变成了并行的过程，从而减少了redo allocation latch等待。

 

       为了进一步降低redo buffer冲突，在10g中引入了新的strand机制——Private strand。Private strand不是从log buffer中划分的，而是在shared pool中分配的一块内存空间。

       Private strand的引入为Oracle的Redo/Undo机制带来很大的变化。每一个Private strand受到一个单独的redo allocation latch保护，每个Private strand作为“私有的”strand只会服务于一个活动事务。获取到了Private strand的用户事务不是在PGA中而是在Private strand生成Redo，当flush private strand或者commit时，Private strand被批量写入log文件中。如果新事务申请不到Private strand的redo allocation latch，则会继续遵循旧的redo buffer机制，申请写入shared strand中。事务是否使用Private strand，可以由x$ktcxb的字段ktcxbflg的新增的第13位鉴定：

 

       对于使用Private strand的事务，无需先申请Redo Copy Latch，也无需申请Shared Strand的redo allocation latch，而是flush或commit是批量写入磁盘，因此减少了Redo Copy Latch和redo allocation latch申请/释放次数、也减少了这些latch的等待，从而降低了CPU的负荷。

 

 

 

看了这些理论知识，我们在来看一下之前的错误：

       Private strand flush not complete

 

       当我们flush或者commit的时候，必须先将buffer中的内容写入到redo中，才能去接收新的记录。 这个错误就是发生在这个过程中。 Oracle 对这个问题提了2个方法：

 

       （1） 忽略，在使用之前，必须要等待buffer的信息flush完成。 这时候进程是会短暂的hang住。

       （2） 增加db_writer_process的数据。

还是没懂，不懂latch，加强学习啊……