转两个恢复redo log的例子

godymoon

1。
今天无廛之氓的数据库由于CURRENT的REDO LOG损坏而无法打开了。当时他先将所有的数据文件以及控制文件，REDO LOG文件等拷贝到了一台测试机，并准备在测试机上打开数据库，并导出数据。碰到这种情况首先备份数据是十分好的做法。以下是当时的聊天记录，希望大家碰到类似问题可以参考。


无廛之氓(8819616) 18:39:37
   日志文件坏了。
   但是我在alter database recover database until cancel，结果报错。
   ora-00279,00289,00280
   非归档模式。
   我把生产库拷贝出来了。在一个测试环境里。建了一个和生产库一模一样的生产环境。
白鳝-shenzhen(62565) 18:56:03
   设置_ALLOW_RESETLOGS_CORRUPTION = TRUE
   然后尝试打开数据库
无廛之氓(8819616) 18:57:27
   00283,01124
   报这个错，system01.dbf
   是8.17的版本。
   提示我正在恢复或正在使用中。
白鳝-shenzhen(62565) 19:01:05
   先recover database until cancel;
   然后随便输入一个文件名
   提示找不到后输入cancel
   然后alter database open resetlogs;
无廛之氓(8819616) 19:03:25
   recover database until cancel;告诉我介质恢复完。
   然后我alter database open resetlogs,告诉我ora-00603
白鳝-shenzhen(62565) 19:04:35
   那应该报ORA-600了吧
无廛之氓(8819616) 19:04:43
   没有。
白鳝-shenzhen(62565) 19:05:19
   看alert log
无廛之氓(8819616) 19:06:15
   错误提示是: oralce server session by fatal error
   有600
   alert文件里有报00600
   internal error code:argument ,后面一大堆数字要不要报出来？
   [2662]
白鳝-shenzhen(62565) 19:13:22
   2662,SCN不一致
无廛之氓(8819616) 19:13:33
   [2662],[0],[243126373
白鳝-shenzhen(62565) 19:14:02
   需要ADJUST_SCN
   http://www.oraclefans.cn/forum/s ... 088&rootid=2271
【
   ADJUST_SCN在数据库灾难恢复的时候十分有用，特别使对于ORA-600[2662]或在数据库启动的时候发生ORA-1555/ORA-604的时候
The ADJUST_SCN event is useful in some recovery situations where the
    current SCN needs to be incremented by a large value to ensure it
    is ahead of the highest SCN in the database. This is typically
    required if either:
      a. An ORA-600 [2662] error is signalled against database blocks
    or
      b. ORA-1555 errors keep occuring after forcing the database open
         or ORA-604 / ORA-1555 errors occur during database open.
         (Note: If startup reports ORA-704 & ORA-1555 errors together
                then the ADJUST_SCN event cannot be used to bump the
                SCN as the error is occuring during bootstrap.
                Repeated startup/shutdown attempts may help if the SCN
                mismatch is small)
    or
      c. If a database has been forced open used _ALLOW_RESETLOGS_CORRUPTION
         (See < Parameter:Allow_Resetlogs_Corruption> )


    The ADJUST_SCN event acts as described below.

  **NOTE: You can check that the ADJUST_SCN event has fired as it
    should write a message to the alert log in the form
  "Debugging event used to advance scn to %s".
  If this message is NOT present in the alert log the event
  has probably not fired.


  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  If the database will NOT open:
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Take a backup.
    You can use event 10015 to trigger an ADJUST_SCN on database open:

startup mount;

alter session set events '10015 trace name adjust_scn level 1';

        (NB: You can only use IMMEDIATE here on an OPEN database. If the
     database is only mounted use the 10015 trigger to adjust SCN,
     otherwise you get ORA 600 [2251], [65535], [4294967295] )

alter database open;

If you get an ORA 600:2256 shutdown, use a higher level and reopen.

    Do *NOT* set this event in init.ora or the instance will crash as soon
    as SMON or PMON try to do any clean up. Always use it with the
    "alter session" command.

  ~~~~~~~~~~~~~~~~~~~~~~~~~~
  If the database *IS* OPEN:
  ~~~~~~~~~~~~~~~~~~~~~~~~~~
    You can increase the SCN thus:

alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';

    LEVEL:  Level 1 is usually sufficient - it raises the SCN to 1 billion
            (1024*1024*1024)
    Level 2 raises it to 2 billion etc...

    If you try to raise the SCN to a level LESS THAN or EQUAL to its
    current setting you will get <OERI:2256>    - See below.
    Ie: The event steps the SCN to known levels. You cannot use
the same level twice.

  Calculating a Level from 600 errors:
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get a LEVEL for ADJUST_SCN:

a) Determine the TARGET scn:
    ora-600 [2662]    See <OERI:2662>  Use TARGET >= blocks SCN
    ora-600 [2256]    See <OERI:2256>  Use TARGET >= Current SCN

  b) Multiply the TARGET wrap number by 4. This will give you the level
   to use in the adjust_scn to get the correct wrap number.
c) Next, add the following value to the level to get the desired base
   value as well :

        Add to Level         Base
        ~~~~~~~~~~~~ ~~~~~~~~~~~~
                   0            0
                   1   1073741824
                   2   2147483648
                   3   3221225472


  】
   参考一下这个文档吧
   现在数据库能打开的机会50%吧，如果BOOTSTRAP$对象有问题，那么就需要用bbed修改了，会相当的麻烦
   那样的话如果有备份就通过备份系统恢复吧
无廛之氓(8819616) 19:18:42
   没有备份。呵呵。
   我先试试。
   alter session set events '10015 trace name ADJUST_SCN level 1'
古董(29516760) 19:19:05
   "对于10个g，缺省情况_ALLOW_ERROR_SIMULATION是FALSE，这会阻止ADJUST_SCN，所以要做ADJUST_SCN必须设置这个隐含参数为TRUE "

    老白.你这个是要说10g大小,还是10g版本?
白鳝-shenzhen(62565) 19:19:33
    10G版本
白鳝-shenzhen(62565) 19:22:58
    817只能修改参数文件
    然后重启数据库
无廛之氓(8819616) 19:25:11
    alter session可以了．
    现在提示redo3出错．
白鳝-shenzhen(62565) 19:26:47
    startup mount;

    alter session set events '10015 trace name adjust_scn level 1';

        (NB: You can only use IMMEDIATE here on an OPEN database. If the
     database is only mounted use the 10015 trigger to adjust SCN,
     otherwise you get ORA 600 [2251], [65535], [4294967295] )

    alter database open;
    If you get an ORA 600:2256 shutdown, use a higher level and reopen.

无廛之氓(8819616) 19:26:58
    alter database open.
    报redo3出错．
白鳝-shenzhen(62565) 19:27:10
    ALTER DATABASE OPEN RESETLOGS
无廛之氓(8819616) 19:28:25
    内部错误，自变量，kcsgssn2
    我要不把ＯＲＡＣＬＥ进程结束了，重新来一下？
白鳝-shenzhen(62565) 19:29:31
    数据库关闭重启
无廛之氓(8819616) 19:29:36
    好的．
    现在可以exp了．
白鳝-shenzhen(62565) 19:39:16
    exp的时候可能会碰到某个表有坏块。所以你还是按照OWNER导吧。不要导全库
无廛之氓(8819616) 19:39:56
按照我的用户schema导的．



----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2.SQL>startup之后报错

ORA-00314：log 3ofthread 1,expectedsequence#doesn'tmatch
ORA-00312: onlinelog 3thread 1 :'/home/oracle/app/oracle/oradata/ora8/redo01.log'

联机日志分为当前联机日志(current)和非当前联机日志(inactive)，非当前联机日志(inactive)的损坏是比较简单的，一般通过clear命令就可以解决问题。


如何查询online redo log的 状态(是否current还是inactive) .

在数据库mount或open状态下查询v$log即可看到。

例如:

SQL> select group#,sequence#,archived,status from v$log;

GROUP#SEQUENCE# ARCHIV STATUS

---------- ---------- ------ --------------------------------

167 YESINACTIVE

268 YESINACTIVE

369 NOCURRENT

下面分;兩種情況分析:

1.如果查询v$log發現損壞的online redo log是inactive,說明該組日志是非當前日志,而且已經歸檔完成( STATUS是INACTIVE , ARCHIVE是YES ) .

處理方法(適用於歸檔及非歸檔數據庫) :

使用clear命令清理這個文件所在的redo log group .

SQL> alter database clear logfile group 3 ;

如果該日志組還沒有歸檔(STATUS是INACTIVE , ARCHIVE是NO )

那麼需要使用如下命令

SQL> alter database clear unarchived logfile group 3 ;

然後打開數據庫,備份.

2.如果查询v$log發現損壞的online redo log是current ,說明該組日志是當前日志.( STATUS是current , ARCHIVE是NO ) .

当前日志损坏分为两种情况：

第一种是日志中没有未决的事务 需要实例恢复(所有事务都已经提交或回滚完成)，那么当前日志组的损坏可以直接用alter database clear unarchivedlogfile group n ;来重新建立。

第二种是日志组中出现问题的时 候有活动(Active)的事务.数据库需要媒体恢复(Media Recovery),日志组需要应用来同步数据，有 两种补救方法：

A.最好的方法是不完全恢复，可以 保证数据的一致性，但是这种办法要求在归档方式下，并且有可用的备份。

B.通过强制性恢复，不过这种方法可能导致数据不一致。

方法A:通过可用备份实行不完全恢复。

可能看到的问题点是，打开数据库 的时候

ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:ORACLEORADATATESTREDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2)系统找不到指定的文件

查看v$log发现是当前日志。

GROUP#THREAD#SEQUENCE#BYTESMEMBERS ARC STATUS

11311048576001NOCURRENT

21291048576001YESINACTIVE

31301048576001YESINACTIVE

试图clear,但是不成功
SQL>; alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'D:ORACLEORADATATESTREDO01.LOG'

拷贝有效的数据库的全备份，并不完全恢复数据库可以采用获取最近的SCN的办法用until scn恢复或用until cnacel恢复
recover database until cancel先选择auto，尽量恢复可以利用的归档日志，然后重新
recover database until cancel这次输入cancel，完成不完全恢复，也就是说恢复两次。如：
SQL>; recoverdatabaseuntilcancel;
Auto
……
SQL>; recoverdatabaseuntilcancel;
Cancel;
5、利用alterdatabaseopenresetlogs；打开数据库说明：
1、这种办法恢复的数据库是一致的不完全恢复，会丢失当前联 机日志中的事务数据
2、这种方法适合于归档数据库并且有可用的数据库全备份。3、恢复成功之后，记得再做一次数 据库的全备份。
4、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不 容许的。

方法B:通过强制恢复，可能导致数据不 一致。

可能看到的问题点是，打开数据库的时候

ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:ORACLEORADATATESTREDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2)系统找不到指定的文件

查看v$log发现是当前日志。

GROUP#THREAD#SEQUENCE#BYTESMEMBERS ARC STATUS

11311048576001NOCURRENT

21291048576001YESINACTIVE

31301048576001YESINACTIVE

试图clear,但是不成功
SQL>; alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'D:ORACLEORADATATESTREDO01.LOG'

把数据库down掉
SQL>;shutdown immediate在init<sid>;.ora中加入如下参数_allow_resetlogs_corruption=TRUE重新启动数据库,利用until cancel恢复
SQL>;recover database until cancel;
Cancel如果出错，不再理会，发出
SQL>;alter database open resetlogs;数据库被 打开后，马上执行一个full export
shutdown数据库,去掉_all_resetlogs_corrupt参数重建库
import并完成恢复建议执行一下ANALYZE TABLE ...VALIDATE STRUCTURE CASCADE;

说明：
1、该恢复方法是没有办法之后的恢复方法，一般情况下建议不 要采用，因为该方法可能导致数据库的不一致
2、该方法也丢失数据，但是丢失的数据没有上一种方法的数据多，主要是未写入数据文件的已提交或未提交数据。3、建议成功后严格执行以上的7到11步，完成数据库的检查与分析
4、全部完成后做一次数据库的全 备份
5、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不 容许的。




come from：http://tolywang.itpub.net/post/48/405841

godymoon

http://space.itpub.net/160455/viewspace-623353

昨天，一台oracle 数据库由于磁盘问题，造成current redo log 损坏，down 机后无法启动数据库。  

       环境： windows2003 + oracle 9i

      操作如下：

     startup mount;

      create pfile from spfile;

     shudown immediate;

     关闭当前数据库后，将所有oracle 下\ora92\ ,\oradata\ yw \ 目录拷贝到出来，将密码文件和pfile 备份。

     在另一台计算机上安装了一个新的oracle，并且重建库，实例名和数据库名与前相同-----yw。

    用备份的\oradata\yw\覆盖新库的\ora\data\yw\.

    覆盖原来的密码文件和 pfile.

    在pfile 中增加：

     __ALLOW_RESETLOGS_CORRUPTION=TRUE

SQL> startup mount pfile=c:\oracle\ora92\database\INITyw.ora;

ORACLE instance started.

Total System Global Area 2483027968 bytes
Fixed Size 2074760 bytes
Variable Size 1090520952 bytes
Database Buffers 1375731712 bytes
Redo Buffers 14700544 bytes
Database mounted.


SQL> recover database until cancel;

输入cancel

SQL> alter database open resetlogs;
alter database open
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
SQL> alter database open;


查看alert_yw.log 文件：

RESETLOGS after incomplete recovery UNTIL CHANGE 9431879262014
Resetting resetlogs activation ID 3761166285 (0xe02ed7cd)
Online log 2 of thread 1 was previously cleared
Online log 3 of thread 1 was previously cleared
Mon Dec 21 14:43:32 2009
Assigning activation ID 3761145403 (0xe02e863b)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: D:\ORACLE\ORADATA\NMYW\REDO01.LOG
Successful open of redo thread 1.
Mon Dec 21 14:43:32 2009
SMON: enabling cache recovery
Mon Dec 21 14:43:32 2009
Errors in file d:\oracle\admin\nmyw\udump\nmyw_ora_265156.trc:
ORA-00600: 内部错误代码，参数: [2662], [2196], [131080003], [2196], [131139845], [8388617], [], []
Mon Dec 21 14:43:32 2009
Errors in file d:\oracle\admin\nmyw\udump\nmyw_ora_265156.trc:
ORA-00600: 内部错误代码，参数: [2662], [2196], [131080003], [2196], [131139845], [8388617], [], []

Mon Dec 21 14:43:32 2009
Error 600 happened during db open, shutting down database
USER: terminating instance due to error 600
Instance terminated by USER, pid = 265156
ORA-1092 signalled during: alter database open resetlogs...
Mon Dec 21 14:48:33 2009
USER: terminating instance due to error 1092
Instance terminated by USER, pid = 265156

SQL> connect / as sysdba;

SQL>startup mount pfile=c:\oracle\ora92\database\INITyw.ora;

SQL> select file#,checkpoint_change# from v$datafile;

   发现所有的datafile 的checkpoint_scn 都是大得出奇：

利用10015事件进行adjust_scn

level 1 = 1billion (12位整数)

SQL> alter session set events '10015 trace name adjust_scn level 1';

SQL> alter database open ;

alter database open
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
SQL> alter database open;

查看alert_yw.log 文件：

Errors in file d:\oracle\admin\nmyw\udump\nmyw_ora_269012.trc:
ORA-00600: 内部错误代码，参数: [2256], [0], [1073741824],[2196],[131100005], [], [], []

Mon Dec 21 15:18:11 2009
Errors in file d:\oracle\admin\nmyw\udump\nmyw_ora_269012.trc:
ORA-00600: 内部错误代码，参数: [2256], [0], [1073741824], [2196], [131100005], [], [], []


level = (2196+1) *4=8788

SQL>alter session set events '10015 trace name adjust_scn level 8788';

SQL> alter database open;

报错：

查看alert_yw.log 文件：


Debugging event used to advance scn to 9436043149312
Undo Segment 1 Onlined
Undo Segment 2 Onlined
Undo Segment 3 Onlined
Undo Segment 4 Onlined
Undo Segment 5 Onlined
Undo Segment 6 Onlined
Undo Segment 7 Onlined
Undo Segment 8 Onlined
Undo Segment 9 Onlined
Undo Segment 10 Onlined
Successfully onlined Undo Tablespace 1.
Dictionary check beginning
Dictionary check complete
Mon Dec 21 15:50:52 2009
SMON: enabling tx recovery
Mon Dec 21 15:50:52 2009
Database Characterset is ZHS16GBK
Mon Dec 21 15:50:54 2009
Errors in file d:\oracle\admin\nmyw\udump\nmyw_ora_273712.trc:
ORA-00600: 内部错误代码，参数: [4193], [38371], [38432], [], [], [], [], []

Mon Dec 21 15:50:54 2009
Errors in file d:\oracle\admin\nmyw\udump\nmyw_p000_272924.trc:
ORA-00600: internal error code, arguments: [ktbsdp1], [], [], [], [], [], [], []

Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0 errs 0: D:\ORACLE\ORADATA\NMYW\REDO02.LOG
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0 errs 0: D:\ORACLE\ORADATA\NMYW\REDO02.LOG
Mon Dec 21 15:50:56 2009
Errors in file d:\oracle\admin\nmyw\udump\nmyw_p000_272924.trc:
ORA-00339: archived log does not contain any redo
ORA-00334: archived log: 'D:\ORACLE\ORADATA\NMYW\REDO03.LOG'
ORA-00600: internal error code, arguments: [ktbsdp1], [], [], [], [], [], [], []

Mon Dec 21 15:50:56 2009
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0 errs 0: D:\ORACLE\ORADATA\NMYW\REDO02.LOG
Mon Dec 21 15:50:56 2009
Errors in file d:\oracle\admin\nmyw\udump\nmyw_ora_273712.trc:
ORA-00607: 当更改数据块时出现内部错误
ORA-00600: 内部错误代码，参数: [4193], [38371], [38432], [], [], [], [], []



报ora-00600 [4193]错误，说明是undo 信息出错，将undo datafile offline 掉即可：

SQL> alter database datafile 'c:\oracle\oradata\yw\undotbs01.ora'  offline drop ;

SQL> alter database open ;

Database opened.

利用exp 将数据导出。 重新建库导入，一切ok.

在最后一步如果出现ora-600 [4193] [4194] 错误，如下解决：

ORA-600的4194和4193错误，根据错误信息的看来是Oracle进行恢复的过程中出现了问题。查询METALINK，发现是REDO中的回滚记录和UNDO中的不一致造成的。尝试使用隐含参数_CORRUPTED_ROLLBACK_SEGMENTS来打开数据库。在刚才的建立的inittest08.ora初始化文件中添加下面的信息：

undo_management='MANUAL'
_corrupted_rollback_segments=(_SYSSMU1&,_SYSSMU2&,_SYSSMU3&,_SYSSMU4&,_SYSSMU5&,_SYSSMU6&,_SYSSMU7&,_SYSSMU8&,_SYSSMU9&,_SYSSMU10&,_SYSSMU11&,_SYSSMU12&,_SYSSMU13&,_SYSSMU14&,_SYSSMU15&,_SYSSMU16&,_SYSSMU17&,_SYSSMU18&,_SYSSMU19&,_SYSSMU20&,_SYSSMU21&,_SYSSMU22&,_SYSSMU23&,_SYSSMU24&,_SYSSMU25&,_SYSSMU26&,_SYSSMU27&,_SYSSMU28&,_SYSSMU29&,_SYSSMU30&,_SYSSMU31&,_SYSSMU32&,_SYSSMU33&,_SYSSMU34&,_SYSSMU35&,_SYSSMU36&,_SYSSMU37&,_SYSSMU38&,_SYSSMU39&,_SYSSMU40&,_SYSSMU41&)

clzzf

高深+经验
LZ是学习的榜样