(ZT)在归档模式下设定_disable_logging=true导致redo corrupt的解决办法

http://space.itpub.net/15415488/viewspace-616115

 

_disable_logging=true可以帮助非归档模式的Oracle在benchmark测试期间提高效率。

但是如果不小心在归档模式下把他设为true，会导致redo log corrupt的问题：

即使将这个参数重新设为false，但如果继续switch logfile到current log，那么switch log会hung住。

并且alert.log会报：

Thu Oct  8 03:42:09 2009ITPUB个人空间7B-BN#}5@'e
ARC1: Log corruption near block 2 change 215140805 time ?
6R)wC p D0Thu Oct  8 03:42:09 2009ITPUB个人空间k9W`I`-rp
Errors in file /oracle/xxx/data01/haozhu/bdump/haozhu_arc1_9082.trc:
F*u S L:D(_|0ORA-00354: corrupt redo log block headerITPUB个人空间0^!Ygn c OJT9q&A-{
ORA-00353: log corruption near block 2 change 215140805 time 10/08/2009 03:28:49ITPUB个人空间+K/~GiAk
ORA-00312: online log 2 thread 1: '/oracle/xxx/data01/haozhu/redo/haozhu_redo2.log'
5gXd}X0ARC1: All Archive destinations made inactive due to error 354
GDx$]O#t3w5{z j0Thu Oct  8 03:42:09 2009ITPUB个人空间 ^$L;cmoPD-Q'd
ARC1: Closing local archive destination LOG_ARCHIVE_DEST_1: '/oracle/xxx/data01/haozhu/archive/haozhu_42.1_698645072_arc' (error 354)

 

这时候解决的办法也非常简单，

对于非current的log file：

SQL>  select group#,status from v$Log;

    GROUP# STATUS
/r*HGZRS3vj-^1E0---------- ------------------------------------------------ITPUB个人空间 a0~2zwKS ]z0k
         2 CURRENTITPUB个人空间8U-WCft!f m
         1 ACTIVE

KtL.s,i zPj#}0SQL> alter database clear unarchived logfile '/oracle/xxx/data01/haozhu/redo/haozhu_redo1.log';

Database altered.

但是对于current logfile,必须设定unrecoverable datafile选项。

SQL> alter database clear unarchived logfile '/oracle/xxx/data01/haozhu/redo/haozhu_redo2.log';
3G1{r~.k u4@.biq0alter database clear unarchived logfile '/oracle/xxx/data01/haozhu/redo/haozhu_redo2.log'ITPUB个人空间T6A pP7S-@3a9e
*ITPUB个人空间(g9Y0m `/E1A'sR9i)m
ERROR at line 1:ITPUB个人空间t3L:e4YZ5e4s
ORA-01624: log 2 needed for crash recovery of instance haozhu (thread 1)
h)u[;Ge~D0ORA-00312: online log 2 thread 1: '/oracle/xxx/data01/haozhu/redo/haozhu_redo2.log'

SQL> alter database clear unarchived logfile group 2unrecoverable datafile;

Database altered.

经过对所有redo log进行clear后，一切恢复正常。

但是，在这期间生成的archive log，却是corrupt的。

dbv file=haozhu_41.1_698645072_arc blocksize=512

Total Pages Examined         : 308
8H}jHSaK g0B0Total Pages Processed (Data) : 0ITPUB个人空间p zW,w a2Hv;x&g
Total Pages Failing   (Data) : 0ITPUB个人空间Gh } OD%F#kY;_ {
Total Pages Processed (Index): 0ITPUB个人空间 e(E5aVs8Jx
Total Pages Failing   (Index): 0ITPUB个人空间i0w2nIyUz
Total Pages Processed (Other): 0
&o{-g-W;v0Total Pages Processed (Seg)  : 0ITPUB个人空间!|_q[~ }H XK
Total Pages Failing   (Seg)  : 0
R!vPH\+^0Total Pages Empty            : 0
$~0q3[\3V0Total Pages Marked Corrupt   : 308
"D`vC,H0Total Pages Influx           : 0
fZ9K0GEl-U5d[0Highest block SCN            : 0 (0.0)

相信这些corrupt的archive log，能够作为曾经在archivedlog模式下设立过_disable_logging=true的一点证据。

（因为alert log很有可能没有保存那么久远。）

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

转载于:http://blog.itpub.net/386081/viewspace-616217/