重建控制文件时resetlogs与noresetlogs的使用情况
2023-09-14 08:59:50 时间
重建控制文件时resetlogs与noresetlogs的使用情况
控制文件中记录着数据库的数据文件,日志文件,备份数据等信息,更为重要的,控制文件中还记录了数据库的检查点
和scn信息,这些信息在数据恢复的过程中将起到关键性作用.
一个正常运行的数据库,通常控制文件都存在多份镜像,这些镜像的内容是完全相同的,oracle缺省就创建多份控制
文件更说明了控制文件的重要:
SQL select name from v$controlfile;
--------------------------------------------------------------------------------
/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
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.
eric0435 系统架构师(高级工程师),ACOUG amp;CSOUG核心成员，Oracle Young Expert 。政府信息化技术顾问。湖南省政府采购评审专家，从2007年开始从事社会保险系统开发，应用架构设计，数据库管理工作。擅长Oracle数据库故障诊断，性能调优。
eric0435 系统架构师(高级工程师),ACOUG amp;CSOUG核心成员，Oracle Young Expert 。政府信息化技术顾问。湖南省政府采购评审专家，从2007年开始从事社会保险系统开发，应用架构设计，数据库管理工作。擅长Oracle数据库故障诊断，性能调优。
相关文章
- Matlab仿真PID控制（带M文件、simulink截图和参数分析）
- UI自动化控制微信发送文件【解决了一个无人回答的难题，Pywin32设置文件到剪切板】「建议收藏」
- 控制Tello无人机扫描条形码「建议收藏」
- 微信 自动回复 机器人_python控制微信
- Linux账号文件控制管理步骤详解
- Oracle 11g控制文件全部丢失从零开始重建控制文件
- Oracle控制文件重建:解决故障的利器（oracle控制文件重建）
- Oracle控制文件中的内容查看（oracle控制文件查看）
- 什么是进程控制块，进程控制块的作用
- 数据Linux下通过串口读取数据实现智能控制（linux串口读取）
- 权限Linux文件权限控制之执行用户权限（linux文件执行用户）
- Linux文件权限管理：扭转文件安全隐患（linux文件权限控制）
- 重建Oracle数据库: 恢复控制文件（重建oracle控制文件）
- 权限Linux用户文件读取授权的控制（linux用户文件读写）
- 如何有效控制Oracle控制文件大小（oracle控制文件大小）
- MySQL锁机制：如何实现高效的并发控制（mysql锁是如何实现的）
- MySQL通过参数化查询实现数据控制（mysql参数化查询）
- MySQL实现数据并发控制加行锁（mysql中加行锁）
- 控制Redis缓存长度以保证性能（控制redis长度）
- MySQL的文件上传限制 如何控制文件大小和类型（mysql 上传文件限制）
- 利用Redis实现队列设置间隔控制（redis队列设置间隔）