Ignore this record in the alter File

Ignore the record environment 11gR2 In the alter file. centOS64bit Problem description: [SQL] Tue May 07 18:40:01 2013 Thread 1 cannot allocate new log, sequence 78 Private strand flush not complete Current log #4 seq #77 mem #0: /u01/app/oracle/oradata/upload/redo04.log Thread 1 advanced to log sequence 78 (LGWR switch) Current log #5 seq #78 mem #0: /u01/app/oracle/oradata/upload/redo05.log Tue May 07 18:40:01 2013 Archived Log entry 36 added for thread 1 sequence 77 ID 0x30de06b8 dest 1: based on experience on the internet, the following operations are done to solve the problem in the View: 1: Add redo group 2: Set the db_writer_processes parameter from Google: odm finding: Alert Log Messages: Private Strand Flush Not Complete Applies: oracle Server-Enterprise Edition-Version: 10.2.0.1 to 11.2.0.3-Release: 10.2 to 11.2 Information in this document applies to any platform. private strand flush not completeSymptoms "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 completeCurrent log #7 seq #18357 mem #0: /u03/oradata/bitst/redo07.logThread 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" 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 unless there is a significant time gap between the "cannot allocate new log" message and the "advanced to log sequence" message. increasing the value for db_writer_processes can in some situations avoid the message from being generated. hdr: 7005709 10.2.0.3 RDBMS 10.2.0.3 txn mgmt local PRODID-5 PORTID-59Abstract: log file switch (private strand flush incomplete) WHEN _ IN_MEMORY_UNDO = true problem: -------- Oracle 10.2.0.3.0This is a large database for Oracle Applications plus a lot of custom code. last night a user noticed slowness between 9 and 10 pm. when we now run AWR and ADDM reports, we see high waits for "log file switch (private strand flush incomplete )". this looks similar to Bug 6806770 doesn't that we're re HPUX 11.11, non-Itanium. as per the bug, we currently have _ in_memory_undo = TRUE. we had this setting set to false for a while as a workaround for another bug (5028099), but re-enabled it after applying a patch (6733906 ). $> grep memory spfilecfap. ora *. _ in_memory_undo = true diagnostic analysis: ------------------ One night a user noticed slowness between 9 and 10 pm. when we now run AWR and ADDM reports, we see high waits for "log file switch (private strand flush incomplete )". we had _ in_memory_undo = FALSE from Jan 15 until March 16, when we applied patch 6733906. before Jan 15, we had numerous alert log messages like what's below. since Mar 16, we 've had approx. 25 more of these messages. in between Jan 15 and Mar 16 we had none of the messages. thread 1 cannot allocate new log, sequence 92288 Private strand flush not complete WORKAROUND: ----------- The only workaround is to set parameter _ in_memory_undo = FALSE to disable imu related bugs: ------------- 6806770-still at status 11 Slow Running User Process And Top Database Wait Event Is 'Log file switch (private strand flush incomplete) 'Applies to: Oracle Server-Enterprise Edition-Version: 10.2.0.1 to 10.2.0.3-Release: 10.2 to 10.2 Information in this document applies to any platform. symptomsChecked for relevance on 31---2011 A user process is running very slow and the top database wait event is always 'Log file switch (private strand flush incomplete )'. AWR Report shows the following Top 5 Timed Events. log file switch (private strand flush incomplete) buffer busy waits log file sync db file sequential read log file switch (checkpoint incomplete) causeUnpublished Bug 5605290 which causes deadlocks between the CKPT and LGWR or DBWR processes, and can manifest itself in gateways. solutionUnpublished Bug 5605290 is fixed in the 10.2.0.4 patchset, so applying it will resolve this issue. in addition there is a workaround available to prevent the problem until able to get the database patched up. sqlplus/as sysdbaalter system set "_ in_memory_undo" = FALSE scope = both;