备案控制台
探索云世界
开发者社区 数据库 文章 正文

重建控制文件时resetlogs与noresetlogs的使用情况

2016-05-13 2370
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：
重建控制文件时resetlogs与noresetlogs的使用情况
控制文件中记录着数据库的数据文件,日志文件,备份数据等信息,更为重要的,控制文件中还记录了数据库的检查点
和scn信息,这些信息在数据恢复的过程中将起到关键性作用.

一个正常运行的数据库,通常控制文件都存在多份镜像,这些镜像的内容是完全相同的,oracle缺省就创建多份控制
文件更说明了控制文件的重要:
SQL> select name from v$controlfile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/product/11.2.0/oradata/jingyong/control01.ctl
/u01/app/oracle/product/11.2.0/oradata/jingyong/control02.ctl

可以通过如下一条命令将控制文件的创建语句备份到跟踪文件中:
SQL> alter database backup controlfile to trace;

Database altered.

SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_18818.trc

SQL> host sz /u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_18818.trc
rz
Starting zmodem transfer.  Press Ctrl+C to cancel.
  100%       8 KB    8 KB/s 00:00:01       0 Errors

此跟踪文件中会记录控制文件的创建脚本,脚本包含两个主要的段落,其中一段如下所示:
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "JINGYONG" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo02.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo03.log'  SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
  '/u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf',
  '/u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf',
  '/u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf',
  '/u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf',
  '/u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf',
  '/u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf'
CHARACTER SET ZHS16GBK
;

当数据库处于nomount状态下时,可以通过运行这段脚本创建控制文件,控制文件会自动创建到参数文件中
记录控制文件的位置(原来的控制文件在创建过程会被覆盖).这里需要理解的一个主要选项是:
noresetlogs/resetlogs.在跟踪文件中包含如下注释,详细解释了这两个选项的含义:
-- Below are two sets of SQL statements, each of which creates a new
-- control file and uses it to open the database. The first set opens
-- the database with the NORESETLOGS option and should be used only if
-- the current versions of all online logs are available. The second
-- set opens the database with the RESETLOGS option and should be used
-- if online logs are unavailable.
-- The appropriate set of statements can be copied from the trace into
-- a script. file, edited as necessary, and executed when there is a
-- need to re-create the control file.

当数据库当前的redo log都可用时,可以通过noresetlogs参数重建控制文件,此时oracle能够从日志文件中
读取redo信息,记录到控制文件中,由于redo中记录的信息足以重演所有提交成功的事务,所以最终能够实现
完全恢复,成功打开数据库,这时的数据库就如同进行了一次断电之后的实例恢复,数据没有损失,重做日志
可以继续向前写入:

下面测试来看一下以noresetlogs重建控制文件进行数据库恢复的过程
先在数据库正常运行状态下对控制文件执行一次转储:
SQL> alter session set events 'immediate trace name controlf level 12';

Session altered.

SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_19350.trc

这个转储文件中将包含数据库的检查点,redo thread信息,数据文件等信息,看一下
log file records内容:
***************************************************************************
LOG FILE RECORDS
***************************************************************************
 (size = 72, compat size = 72, section max = 16, section in-use = 3,
  last-recid= 3, old-recno = 0, last-recno = 0)
 (extent = 1, blkno = 10, numrecs = 16)
LOG FILE #1:
  name #3: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log
 Thread 1 redo log links: forward: 2 backward: 0
 siz: 0x19000 seq: 0x00000010 hws: 0x2 bsz: 512 nab: 0x1e flg: 0x1 dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.000ea466
 Low scn: 0x0000.000ea474 05/02/2013 11:40:58
 Next scn: 0x0000.000ea4db 05/02/2013 11:44:07
LOG FILE #2:
  name #2: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo02.log
 Thread 1 redo log links: forward: 3 backward: 1
 siz: 0x19000 seq: 0x00000011 hws: 0x1 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.000ea474
 Low scn: 0x0000.000ea4db 05/02/2013 11:44:07
 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
LOG FILE #3:
  name #1: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo03.log
 Thread 1 redo log links: forward: 0 backward: 2
 siz: 0x19000 seq: 0x0000000f hws: 0x2 bsz: 512 nab: 0x2 flg: 0x1 dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.000e8ed8
 Low scn: 0x0000.000ea466 05/02/2013 11:40:52
 Next scn: 0x0000.000ea474 05/02/2013 11:40:58

从记录信息中我们可以看到redo02.log文件的next scn:0xffff.ffffffff,所以redo02.log文件是当前的
日志文件,我们可以从v$log视图中查看当前的重做日志组
SQL> select group#,status from v$log;

    GROUP# STATUS
---------- ----------------
         1 INACTIVE
         2 CURRENT
         3 INACTIVE

接下来通过shutdown abort模拟一次数据库故障:
SQL> shutdown abort;
ORACLE instance shut down.

启动数据库到nomount状态,再来使用noresetlogs参数来重建控制文件:
SQL> startup nomount;
ORACLE instance started.

Total System Global Area  238530560 bytes
Fixed Size                  1335724 bytes
Variable Size             150998612 bytes
Database Buffers           83886080 bytes
Redo Buffers                2310144 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "JINGYONG" NORESETLOGS  ARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 3
  4      MAXDATAFILES 100
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 292
  7  LOGFILE
  8    GROUP 1 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log'  SIZE 50M BLOCKSIZE 512,
  9    GROUP 2 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo02.log'  SIZE 50M BLOCKSIZE 512,
 10    GROUP 3 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo03.log'  SIZE 50M BLOCKSIZE 512
 11  -- STANDBY LOGFILE
 12  DATAFILE
 13    '/u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf',
 14    '/u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf',
 15    '/u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf',
 16    '/u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf',
 17    '/u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf',
 18    '/u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf'
 19  CHARACTER SET ZHS16GBK
 20  ;

Control file created.

此时再来对控制文件进行一次转储,检查log file records部分:
SQL> alter session set events 'immediate trace name controlf level 12';

Session altered.

SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_19438.trc

***************************************************************************
LOG FILE RECORDS
***************************************************************************
 (size = 72, compat size = 72, section max = 16, section in-use = 3,
  last-recid= 0, old-recno = 0, last-recno = 0)
 (extent = 1, blkno = 10, numrecs = 16)
LOG FILE #1:
  name #2: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log
 Thread 1 redo log links: forward: 2 backward: 0
 siz: 0x19000 seq: 0x00000010 hws: 0x2 bsz: 512 nab: 0x1e flg: 0x0 dup: 1
 Archive links: fwrd: 2 back: 3 Prev scn: 0x0000.000ea466
 Low scn: 0x0000.000ea474 05/02/2013 11:40:58
 Next scn: 0x0000.000ea4db 05/02/2013 11:44:07
LOG FILE #2:
  name #1: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo02.log
 Thread 1 redo log links: forward: 3 backward: 1
 siz: 0x19000 seq: 0x00000011 hws: 0x1 bsz: 512 nab: 0xffffffff flg: 0xa dup: 1
 Archive links: fwrd: 0 back: 1 Prev scn: 0x0000.000ea474
 Low scn: 0x0000.000ea4db 05/02/2013 11:44:07
 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
LOG FILE #3:
  name #3: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo03.log
 Thread 1 redo log links: forward: 0 backward: 2
 siz: 0x19000 seq: 0x0000000f hws: 0x2 bsz: 512 nab: 0x2 flg: 0x0 dup: 1
 Archive links: fwrd: 1 back: 0 Prev scn: 0x0000.00000000
 Low scn: 0x0000.000ea466 05/02/2013 11:40:52
 Next scn: 0x0000.000ea474 05/02/2013 11:40:58

从上面的记录我们可以看到重建的控文件能够从当前的日志文件获得正确的SCN及时间点等信息.同样地,控制
文件也能够从数据文件中获得详细的检查点信息:

***************************************************************************
DATA FILE RECORDS
***************************************************************************
 (size = 520, compat size = 520, section max = 100, section in-use = 6,
  last-recid= 0, old-recno = 0, last-recno = 0)
 (extent = 1, blkno = 11, numrecs = 100)
DATA FILE #1:
  name #9: /u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf
creation size=0 block size=8192 status=0x12 head=9 tail=9 dup=1
 tablespace 0, index=1 krfil=1 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:119 scn: 0x0000.000ea4db 05/02/2013 11:44:07
 Stop scn: 0xffff.ffffffff 05/02/2013 12:44:28
 Creation Checkpointed at scn:  0x0000.00000007 08/13/2009 23:00:53
 thread:0 rba:(0x0.0.0)
 .....
 DATA FILE #2:
  name #8: /u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf
creation size=0 block size=8192 status=0x12 head=8 tail=8 dup=1
 tablespace 1, index=2 krfil=2 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:119 scn: 0x0000.000ea4db 05/02/2013 11:44:07
 Stop scn: 0xffff.ffffffff 05/02/2013 12:44:28
 Creation Checkpointed at scn:  0x0000.00000874 08/13/2009 23:00:57
 thread:0 rba:(0x0.0.0)
 .....
 DATA FILE #3:
  name #7: /u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf
creation size=0 block size=8192 status=0x12 head=7 tail=7 dup=1
 tablespace 2, index=3 krfil=3 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:47 scn: 0x0000.000ea4db 05/02/2013 11:44:07
 Stop scn: 0xffff.ffffffff 05/02/2013 12:44:28
 Creation Checkpointed at scn:  0x0000.000b7982 08/13/2009 23:56:54
 thread:0 rba:(0x0.0.0)
 .....
 DATA FILE #4:
  name #6: /u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf
creation size=0 block size=8192 status=0x12 head=6 tail=6 dup=1
 tablespace 4, index=4 krfil=4 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:118 scn: 0x0000.000ea4db 05/02/2013 11:44:07
 Stop scn: 0xffff.ffffffff 05/02/2013 12:44:28
 Creation Checkpointed at scn:  0x0000.00004743 08/13/2009 23:01:06
 thread:0 rba:(0x0.0.0)
 ....
 DATA FILE #5:
  name #5: /u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf
creation size=0 block size=8192 status=0x12 head=5 tail=5 dup=1
 tablespace 6, index=5 krfil=5 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:43 scn: 0x0000.000ea4db 05/02/2013 11:44:07
 Stop scn: 0xffff.ffffffff 05/02/2013 12:44:28
 Creation Checkpointed at scn:  0x0000.000bf3fe 04/25/2013 14:05:52
 thread:0 rba:(0x0.0.0)
 ....
 DATA FILE #6:
  name #4: /u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf
creation size=0 block size=8192 status=0x12 head=4 tail=4 dup=1
 tablespace 7, index=6 krfil=6 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:11 scn: 0x0000.000ea96d 05/02/2013 12:00:47
 Stop scn: 0xffff.ffffffff 05/02/2013 12:44:28
 Creation Checkpointed at scn:  0x0000.000e9b4f 05/02/2013 08:43:22
 thread:0 rba:(0x0.0.0)
 .....

从上面的信息可以知道由于数据库是异常关闭的,所以数据文件的Stop scn:为无穷大:
Stop scn: 0xffff.ffffffff,接下来对数据库执行恢复,当恢复完成后再对控制文件进行转储:
SQL> recover database;
Media recovery complete.

SQL> alter session set events 'immediate trace name controlf level 12';

Session altered.

SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_19450.trc

来观察此跟踪文件中的数据文件信息:
***************************************************************************
DATA FILE RECORDS
***************************************************************************
 (size = 520, compat size = 520, section max = 100, section in-use = 6,
  last-recid= 0, old-recno = 0, last-recno = 0)
 (extent = 1, blkno = 11, numrecs = 100)
DATA FILE #1:
  name #9: /u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf
creation size=0 block size=8192 status=0x2 head=9 tail=9 dup=1
 tablespace 0, index=1 krfil=1 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:120 scn: 0x0000.000efd7d 05/02/2013 12:43:16
 Stop scn: 0x0000.000efd7d 05/02/2013 12:43:16
 Creation Checkpointed at scn:  0x0000.00000007 08/13/2009 23:00:53
 thread:0 rba:(0x0.0.0)
 ....
DATA FILE #2:
  name #8: /u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf
creation size=0 block size=8192 status=0x2 head=8 tail=8 dup=1
 tablespace 1, index=2 krfil=2 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:120 scn: 0x0000.000efd7d 05/02/2013 12:43:16
 Stop scn: 0x0000.000efd7d 05/02/2013 12:43:16
 Creation Checkpointed at scn:  0x0000.00000874 08/13/2009 23:00:57
 thread:0 rba:(0x0.0.0)
....
DATA FILE #3:
  name #7: /u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf
creation size=0 block size=8192 status=0x2 head=7 tail=7 dup=1
 tablespace 2, index=3 krfil=3 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:48 scn: 0x0000.000efd7d 05/02/2013 12:43:16
 Stop scn: 0x0000.000efd7d 05/02/2013 12:43:16
 Creation Checkpointed at scn:  0x0000.000b7982 08/13/2009 23:56:54
 thread:0 rba:(0x0.0.0)
 ....
DATA FILE #4:
  name #6: /u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf
creation size=0 block size=8192 status=0x2 head=6 tail=6 dup=1
 tablespace 4, index=4 krfil=4 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:119 scn: 0x0000.000efd7d 05/02/2013 12:43:16
 Stop scn: 0x0000.000efd7d 05/02/2013 12:43:16
 Creation Checkpointed at scn:  0x0000.00004743 08/13/2009 23:01:06
 thread:0 rba:(0x0.0.0)
 ....
DATA FILE #5:
  name #5: /u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf
creation size=0 block size=8192 status=0x2 head=5 tail=5 dup=1
 tablespace 6, index=5 krfil=5 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:44 scn: 0x0000.000efd7d 05/02/2013 12:43:16
 Stop scn: 0x0000.000efd7d 05/02/2013 12:43:16
 Creation Checkpointed at scn:  0x0000.000bf3fe 04/25/2013 14:05:52
 thread:0 rba:(0x0.0.0)
 ....
DATA FILE #6:
  name #4: /u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf
creation size=0 block size=8192 status=0x2 head=4 tail=4 dup=1
 tablespace 7, index=6 krfil=6 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:12 scn: 0x0000.000efd7d 05/02/2013 12:43:16
 Stop scn: 0x0000.000efd7d 05/02/2013 12:43:16
 Creation Checkpointed at scn:  0x0000.000e9b4f 05/02/2013 08:43:22
 thread:0 rba:(0x0.0.0)
 ....
经过恢复之后,数据文件达到了一致状态,checkpoint scn(0x0000.000efd7d)和Stop scn(0x0000.000efd7d)
达到了一致,此时数据库就完成了恢复,数据库可以顺利启动:

SQL> ALTER SYSTEM ARCHIVE LOG ALL;

System altered.

SQL> ALTER DATABASE OPEN;

Database altered.

SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/product/11.2.0/oradata/jingyong/temp01.dbf'
  2       SIZE 30M  REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 40M;

Tablespace altered.

现在我们来实验使用resetlogs方式来重建控制文件:
模拟数据库故障
SQL> shutdown abort;
ORACLE instance shut down.

以resetlogs来重建控制文件
SQL> startup nomount
ORACLE instance started.

Total System Global Area  238530560 bytes
Fixed Size                  1335724 bytes
Variable Size             150998612 bytes
Database Buffers           83886080 bytes
Redo Buffers                2310144 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "JINGYONG" RESETLOGS  ARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 3
  4      MAXDATAFILES 100
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 292
  7  LOGFILE
  8    GROUP 1 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log'  SIZE 50M BLOCKSIZE 512,
  9    GROUP 2 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo02.log'  SIZE 50M BLOCKSIZE 512,
 10    GROUP 3 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo03.log'  SIZE 50M BLOCKSIZE 512
 11  -- STANDBY LOGFILE
 12  DATAFILE
 13    '/u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf',
 14    '/u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf',
 15    '/u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf',
 16    '/u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf',
 17    '/u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf',
 18    '/u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf'
 19  CHARACTER SET ZHS16GBK
 20  ;

Control file created.

此时对控制文件进行一次转储
SQL> alter session set events 'immediate trace name controlf level 12';

Session altered.

SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_19598.trc

观察转储的跟踪文件中的log file record的信息:
***************************************************************************
LOG FILE RECORDS
***************************************************************************
 (size = 72, compat size = 72, section max = 16, section in-use = 3,
  last-recid= 0, old-recno = 0, last-recno = 0)
 (extent = 1, blkno = 10, numrecs = 16)
LOG FILE #1:
  name #3: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log
 Thread 1 redo log links: forward: 2 backward: 0
 siz: 0x19000 seq: 0x00000000 hws: 0x0 bsz: 512 nab: 0x0 flg: 0x1 dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00000000
 Low scn: 0x0000.00000000 01/01/1988 00:00:00
 Next scn: 0x0000.00000000 01/01/1988 00:00:00
LOG FILE #2:
  name #2: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo02.log
 Thread 1 redo log links: forward: 3 backward: 1
 siz: 0x19000 seq: 0x00000000 hws: 0x0 bsz: 512 nab: 0x0 flg: 0x1 dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00000000
 Low scn: 0x0000.00000000 01/01/1988 00:00:00
 Next scn: 0x0000.00000000 01/01/1988 00:00:00
LOG FILE #3:
  name #1: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo03.log
 Thread 1 redo log links: forward: 0 backward: 2
 siz: 0x19000 seq: 0x00000000 hws: 0x0 bsz: 512 nab: 0x2 flg: 0xb dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00000000
 Low scn: 0x0000.00000000 01/01/1988 00:00:00
 Next scn: 0x0000.00000000 01/01/1988 00:00:00

从上面的信息可以看到此时控制文件中的日志信息都是空的,oracle认为resetlogs方式下,当前的日志文件
已经损坏,那么就意味着oracle可能会丢失提交成功的数据,恢复将是一次不完全的介质恢复.

此时的数据文件信息如下:
***************************************************************************
DATA FILE RECORDS
***************************************************************************
 (size = 520, compat size = 520, section max = 100, section in-use = 6,
  last-recid= 0, old-recno = 0, last-recno = 0)
 (extent = 1, blkno = 11, numrecs = 100)
DATA FILE #1:
  name #9: /u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf
creation size=0 block size=8192 status=0x12 head=9 tail=9 dup=1
 tablespace 0, index=1 krfil=1 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:123 scn: 0x0000.000efd80 05/02/2013 12:53:11
 Stop scn: 0xffff.ffffffff 05/02/2013 13:01:12
 Creation Checkpointed at scn:  0x0000.00000007 08/13/2009 23:00:53
 thread:0 rba:(0x0.0.0)
 ....
DATA FILE #2:
  name #8: /u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf
creation size=0 block size=8192 status=0x12 head=8 tail=8 dup=1
 tablespace 1, index=2 krfil=2 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:123 scn: 0x0000.000efd80 05/02/2013 12:53:11
 Stop scn: 0xffff.ffffffff 05/02/2013 13:01:12
 Creation Checkpointed at scn:  0x0000.00000874 08/13/2009 23:00:57
 thread:0 rba:(0x0.0.0)
 ....
DATA FILE #3:
  name #7: /u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf
creation size=0 block size=8192 status=0x12 head=7 tail=7 dup=1
 tablespace 2, index=3 krfil=3 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:51 scn: 0x0000.000efd80 05/02/2013 12:53:11
 Stop scn: 0xffff.ffffffff 05/02/2013 13:01:12
 Creation Checkpointed at scn:  0x0000.000b7982 08/13/2009 23:56:54
 thread:0 rba:(0x0.0.0)
 ....
DATA FILE #4:
  name #6: /u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf
creation size=0 block size=8192 status=0x12 head=6 tail=6 dup=1
 tablespace 4, index=4 krfil=4 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:122 scn: 0x0000.000efd80 05/02/2013 12:53:11
 Stop scn: 0xffff.ffffffff 05/02/2013 13:01:12
 Creation Checkpointed at scn:  0x0000.00004743 08/13/2009 23:01:06
 thread:0 rba:(0x0.0.0)
 ....
DATA FILE #5:
  name #5: /u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf
creation size=0 block size=8192 status=0x12 head=5 tail=5 dup=1
 tablespace 6, index=5 krfil=5 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:47 scn: 0x0000.000efd80 05/02/2013 12:53:11
 Stop scn: 0xffff.ffffffff 05/02/2013 13:01:12
 Creation Checkpointed at scn:  0x0000.000bf3fe 04/25/2013 14:05:52
 thread:0 rba:(0x0.0.0)
 ....
DATA FILE #6:
  name #4: /u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf
creation size=0 block size=8192 status=0x12 head=4 tail=4 dup=1
 tablespace 7, index=6 krfil=6 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:15 scn: 0x0000.000efd80 05/02/2013 12:53:11
 Stop scn: 0xffff.ffffffff 05/02/2013 13:01:12
 Creation Checkpointed at scn:  0x0000.000e9b4f 05/02/2013 08:43:22
 thread:0 rba:(0x0.0.0)
 ....
 从上面的信息可以知道由于数据库是异常关闭的,所以数据文件的Stop scn:为无穷大:
Stop scn: 0xffff.ffffffff

不完全恢复最终要求数据库通过resetlogs方式打开,resetlogs将会强制清空或重建联机重做日志文件.
此时执行恢复必须使用backup controlfile选项,否则将会报错:
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

SQL> recover database using backup controlfile;
ORA-00279: change 982400 generated at 05/02/2013 12:53:11 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/product/11.2.0/flash_recovery_area/JINGYONG/archivelog/2013_05_0
2/o1_mf_1_18_%u_.arc
ORA-00280: change 982400 for thread 1 is in sequence #18


Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.

如果在线日志操坏,那么恢复到最后,oracle提示的最后一个归档日志将是不存在的(如果在线日志没有
损坏,则可以指定在线日志文件执行恢复),此时可以输入cancel取消恢复,然后可以强制打开数据库:
alter database open resetlogs;


SQL> recover database using backup controlfile;
ORA-00279: change 1003572 generated at 05/02/2013 13:20:06 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/product/11.2.0/flash_recovery_area/JINGYONG/archivelog/2013_05_0
2/o1_mf_1_19_%u_.arc
ORA-00280: change 1003572 for thread 1 is in sequence #19


Specify log: {=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;

Database altered.

SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/product/11.2.0/oradata/jingyong/temp01.dbf'
  2       SIZE 30M  REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 40M;

Tablespace altered.
文章标签：
日志服务
关系型数据库
Oracle
数据库
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
eric0435
目录
相关文章
姚远OracleACE
|
11月前
修复DataGuard备库中的datafile坏块一例
模拟备库块损坏 使用swingbench给主库施加一定的压力
姚远OracleACE
84 0
余二五
|
SQL 存储 Oracle
RMAN基于表空间的不完全恢复（TSPITR)
余二五
1351 0
郭一军_guoyJoe
|
Oracle 关系型数据库 数据库管理
基于rman的坏块恢复
rman备份恢复
郭一军_guoyJoe
1732 0
snowofsummer
|
监控
rman 恢复部分归档日志
rac 数据库在恢复部分归档日志的时候，需要指定数据库的线程编号。
snowofsummer
1861 0
acdante
|
SQL Oracle 关系型数据库
RMAN基于SCN或特定时间点的不完全恢复
acdante
2221 0
余二五
|
SQL Oracle 关系型数据库
重建控制文件--Rebuild controlfile
余二五
1188 0
技术小甜
|
Oracle 关系型数据库
控制文件丢失，重建控制文件
技术小甜
842 0
技术小美
|
Oracle 关系型数据库 数据库
oracle之 利用 controlfile trace文件重建控制文件
技术小美
1455 0
技术小美
|
SQL Oracle 关系型数据库
用备份控制文件做不完全恢复下的完全恢复（全备<老>--备份控制文件<次新>--删除表空间andy--日志文件<新>）
技术小美
945 0
技术小胖子
|
SQL Oracle 关系型数据库
RMAN 不完全恢复
技术小胖子
796 0

热门文章

最新文章

  • 1
    随机生成UserAgent的python库（fake-useragent库）
  • 2
    使用zxing识别一幅包含多个二维码的图片
  • 3
    阿里云的SLB，植入cookie和重写cookie有什么区别？
  • 4
    基于Flink的实时日志分析系统实践
  • 5
    如何在服务器上跑python程序
  • 6
    电池技术多年没有较大发展，成为移动设备最大制约
  • 7
    Spread for WinRT 7新功能使用指南
  • 8
    codeforces Soldier and Number Game（dp+素数筛选）
  • 9
    九度oj-1001-Java
  • 10
    Android:随笔——对页面的View进行截图
  • 1
    分解商业周期时间序列：线性滤波器、HP滤波器、Baxter滤波器、Beveridge Nelson分解等去趋势2
    9
  • 2
    分解商业周期时间序列：线性滤波器、HP滤波器、Baxter滤波器、Beveridge Nelson分解等去趋势法1
    9
  • 3
    灰色关联分析(Grey Relation Analysis,GRA)中国经济社会发展指标
    9
  • 4
    极值分析：分块极大值BLOCK-MAXIMA、阈值超额法、广义帕累托分布GPD拟合降雨数据时间序列
    9
  • 5
    GARCH-DCC模型和DCC（MVT）建模估计
    8
  • 6
    ARIMA、ARIMAX、 动态回归和OLS 回归预测多元时间序列
    10
  • 7
    R语言预测期货波动率的实现：ARCH与HAR-RV与GARCH，ARFIMA模型比较
    10
  • 8
    spss modeler用决策树神经网络预测ST的股票
    9
  • 9
    K-means和层次聚类分析癌细胞系微阵列数据和树状图可视化比较
    8
  • 10
    matlab中使用VMD(变分模态分解)对信号去噪
    8

    • 相关电子书

    更多
  • 低代码开发师（初级）实战教程
  • 冬季实战营第三期：MySQL数据库进阶实战
  • 阿里巴巴DevOps 最佳实践手册
    • 下一篇
    阿里云oss简介和使用流程
    为什么选择阿里云什么是云计算全球基础设施技术领先稳定可靠安全合规分析师报告
    产品和定价全部产品免费试用产品动态产品定价价格计算器云上成本管理
    解决方案技术解决方案
    文档与社区文档开发者社区天池大赛培训与认证
    权益中心免费试用高校计划企业扶持计划推荐返现计划
    支持与服务基础服务企业增值服务迁云服务官网公告健康看板信任中心
    关注阿里云
    关注阿里云公众号或下载阿里云APP，关注云资讯，随时随地运维管控云服务
    阿里云APP阿里云微信
    联系我们：4008013260
    法律声明Cookies政策廉正举报安全举报联系我们加入我们
    阿里巴巴集团淘宝网天猫全球速卖通阿里巴巴国际交易市场1688阿里妈妈飞猪阿里云计算AliOS万网高德UC友盟优酷钉钉支付宝达摩院淘宝海外阿里云盘饿了么
    © 2009-2024 Aliyun.com 版权所有 增值电信业务经营许可证： 浙B2-20080101 域名注册服务机构许可： 浙D3-20210002 京D3-20220015
    浙公网安备 33010602009975号浙B2-20080101-4