About Private strand flush not complete

The alarm logs sent by netizens are originally about a deadlock. Another problem is that the logs written from the redo log buffer to the redo log file cannot be allocated with new logs, private strand flush not complete wait event. This is a redo log-related topic. The following is a description from Meatlink.

 

Tue Sep 24 14:27:48 2013
Thread 1 cannot allocate new log, sequence 22120
Private strand flush not complete
Current log #4 seq #22119 mem #0:/u01/app/oracle/oradata/orcl/redo04.log

 

Information 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:

Mon Jan 23 16:09:36 2012
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.

-- Before switching the daily value, all private strands must be written to the current redo logfile.

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" Before t 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 mechanisms 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 mechanic for redo (and undo), which seem to be aimed at startup cing contention.

Instead of redo being recorded in real time, it can be recorded 'privateely 'and pumped into the redo log buffer on commit.

Similarly 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

Increasing the value for db_writer_processes can in some situations help to avoid the message from being generated. why, because one of the DBWR main function is to keep the buffer cache clean by writing out dirty buffer blocks. so having multiple db_writer_processes shocould be able to produce a higher throughput.

Finally,

 

In highly concurrent and multi-user database systems, all client processes ensure data integrity and consistency by writing redo log buffer to redo data. The management of redo log buffer is implemented through the latch mechanism. There are two latch related to redo, one is redo allocation latch and the other is redo copy latch. The former is responsible for allocating space for the new redo log buffer, and the latter is copying the redo in the pga to the redo log buffer. The following describes the redo generation process.

 

 

As described in Doc ID 372557.1 above, the log_parallelism mechanism is introduced after Oracle 9.2. When the value of this parameter is greater than 1, the database allocates multiple shared redo log buffers, that is to say, the redo log buffer is subdivided again, so that each shared buffer uses an independent redo allocation latch for protection to improve the redo concurrency. These shared redo log buffers are called shared strand. After 10gR2, another private strand exists, which is allocated from the shared pool instead of the previous log buffer. Private strand is a large number of small private memory, usually around 64kb-128kb, which is protected by independent redo allocation latch. Each specific small transaction is bound to an independent and idle private redolog strand, that is, bound to an active transaction. After the introduction of this new mechanism, once the user process applies to private strand, redo does not save the pga, so the redo copy latch process is no longer required. If the new transaction cannot apply for the redo allocation latch of private strand, the old redo buffer mechanism will be followed and the application will be written to shared strand. Due to the introduction of the new mechanism, the corresponding redo generation has changed as follows:

 

For this new mechanism, LGWR needs to write shared strand and private strand content when redo is written to logfile. When redo flush occurs, all publicredo allocation latch needs to be obtained, all public strands redo copy latch needs to be checked, and all private strands containing active transactions need to be held.

 

We can see that the appearance of the Private strand flush not complete event is avoided by adding the value of the DBWn parameter. Because DBWn will trigger LGWR to write redo to logfile.

 

Use crs_profile to manage RAC resource configuration files
RAC database startup and Shutdown
Oracle RAC services
Services in Oracle Database 10g
Migrate datbase from single instance to Oracle RAC
Connect Oracle RAC to a specified instance
Oracle RAC load balancing test (combined with server and client)
Oracle RAC server connection Load Balance)
Load Balance)
Non-Default port listening configuration in oracle rac (listener. ora tnsnames. ora)
Oracle rac listener Configuration (listener. ora tnsnames. ora)
Configure RAC load balancing and Failover
CRS-1006, CRS-0215 fault case
Installing Oracle 10g RAC Based on Linux (RHEL 5.5)
Use runcluvfy to verify the Oracle RAC installation environment

Configure dynamic service registration for non-default ports
Configure sqlnet. ora to restrict IP Access to Oracle
Configure and manage Oracle listener logs
Set the Oracle LISTENER password (LISTENER)
Configure the ORACLE client to connect to the database

Oracle cold backup
Oracle Hot Backup
Concept of Oracle backup recovery
Oracle instance recovery
Oracle recovery based on user management
SYSTEM tablespace management and Backup Recovery
SYSAUX tablespace management and recovery
Oracle backup control file recovery (unsing backup controlfile)

RMAN overview and architecture
RMAN configuration, Monitoring and Management
Detailed description of RMAN backup
RMAN restoration and recovery
Create and use RMAN catalog
Create RMAN storage script based on catalog
Catalog-based RMAN backup and recovery
RMAN backup path confusion
Use RMAN for recovery from different machine backups (WIN platform)
Use RMAN to migrate a file system database to ASM
Linux RMAN backup shell script
Use RMAN to migrate the database to a different machine

Oracle tablespace and data files
Oracle Password File
Oracle parameter file
Oracle ONLINE redo LOG FILE)
Oracle Control File)
Oracle archiving logs
Oracle ROLLBACK and UNDO)
Oracle database instance startup and Shutdown Process
Automated Management of Oracle 10g SGA
Oracle instances and Oracle databases (Oracle Architecture)