DEBUG: Replaying xcb
DEBUG: Restoring block headers for xcb
DEBUG: Finished replay for xcb
=====================================
Today, The following messages appear in the alert.log (oRACLE DATABASE 10.2.0.4 ):
Sun Apr 24 09:35:27 2011
DEBUG: Replaying xcb 0x903a9df68
Reconstructing Uhdr 0x34017f9 for xcb 0x903a9df68
Doing block recovery for file 13 block 6137
Block recovery from logseq 84873
Sun Apr 24 09:35:44 2011
DEBUG: Replaying xcb 0xd036ba400
Sun Apr 24 09:35:58 2011
Reconstructing Uhdr 0x2401929 for xcb 0xd036ba400
Doing block recovery for file 9 block 6441
Block recovery from logseq 84873
Sun Apr 24 09:35:59 2011
Recovery of Online Redo Log: Thread 1 Group 2 Seq 84873 Reading mem 0
Mem# 0: /d01/oracle/oradata/stlbas/redo02.log
Sun Apr 24 09:35:59 2011
Recovery of Online Redo Log: Thread 1 Group 2 Seq 84873 Reading mem 0
Mem# 0: /d01/oracle/oradata/stlbas/redo02.log
Block recovery completed at rba 84873.228401.16
DEBUG: Restoring block headers for xcb 0xd036ba400
DEBUG: Finished replay for xcb 0xd036ba400
Sun Apr 24 09:35:59 2011
Block recovery completed at rba 84873.227428.16
DEBUG: Restoring block headers for xcb 0x903a9df68
DEBUG: Finished replay for xcb 0x903a9df68
Sun Apr 24 09:39:43 2011
Timed out trying to start process P636.
Sun Apr 24 09:48:24 2011
---------------*****------------------------------
After Diagnosis the message, I found that,
If you see messages like "DEBUG: ..." without having activated Event 30047, then you have possibly encountered this bug.
This is a oracle bug, Bug no 7433585 .
The messages can be ignored. They are written unconditionally during restore and recover of a block online when replaying a transaction.
Or, you can use the following workaround:
set _in_memory_undo=false in the init.ora
Be advised this parameter may have a performance impact so test before implementing.
There are currently no patches available for this problem. It will be fixed in 11.2
WWSS
2 days ago
1 comment:
Very Nice write about this oracle problem
Post a Comment