A-A+
BBED跳过归档日志恢复数据
操作系统信息
[oracle@rhl6 lib]$ uname -a Linux rhl6.0x64 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
数据库版本
SQL> set line 400 SQL> select * from gv$version; INST_ID BANNER ---------- -------------------------------------------------------------------------------- 1 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production 1 PL/SQL Release 11.2.0.3.0 - Production 1 CORE 11.2.0.3.0 Production 1 TNS for Linux: Version 11.2.0.3.0 - Production 1 NLSRTL Version 11.2.0.3.0 - Production
测试数据
SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 66 Next log sequence to archive 68 Current log sequence 68 SQL> show parameter DB_RECOVERY_FILE_DEST NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string /u01/app/oracle/fast_recovery_ area db_recovery_file_dest_size big integer 4977M SQL> conn yallonking/yallonking Connected. SQL> alter session set nls_date_format='yyyy/mm/dd hh24:mi:ss'; Session altered. SQL> select rowid,t.* from yallonking t; ROWID ID NAME MY_DATE ------------------ ---------- -------------------- ------------------- AAARciAAFAAAACHAAA 1 yallonking 2013/07/22 09:44:53 AAARciAAFAAAACHAAB 2 oraking 2013/07/22 09:45:07 AAARciAAFAAAACHAAC 3 xiaolong 2013/07/22 09:50:09
备份数据库
RMAN> backup database; Starting backup at 24-JUL-13 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=30 device type=DISK channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00001 name=/u01/app/oracle/oradata/ora11gr2/system01.dbf input datafile file number=00002 name=/u01/app/oracle/oradata/ora11gr2/sysaux01.dbf input datafile file number=00003 name=/u01/app/oracle/oradata/ora11gr2/undotbs01.dbf input datafile file number=00004 name=/u01/app/oracle/oradata/ora11gr2/users01.dbf input datafile file number=00005 name=/u01/app/oracle/oradata/ora11gr2/yallonking01.dbf channel ORA_DISK_1: starting piece 1 at 24-JUL-13 channel ORA_DISK_1: finished piece 1 at 24-JUL-13 piece handle=/u01/app/oracle/fast_recovery_area/ORA11GR2/backupset/2013_07_24/o1_mf_nnndf_TAG20130724T112657_8yyld1x7_.bkp tag=TAG20130724T112657 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:03:56 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 24-JUL-13 channel ORA_DISK_1: finished piece 1 at 24-JUL-13 piece handle=/u01/app/oracle/fast_recovery_area/ORA11GR2/backupset/2013_07_24/o1_mf_ncsnf_TAG20130724T112657_8yylmk9m_.bkp tag=TAG20130724T112657 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 24-JUL-13 RMAN> exit Recovery Manager complete.
下边插入3条新记录并让其置于3个不同的归档日志中
SQL> insert into yallonking values(4,'archive_test1',sysdate); 1 row created. SQL> commit; Commit complete. SQL> alter system archive log current; System altered. SQL> insert into yallonking values(5,'archive_test2',sysdate); 1 row created. SQL> commit; Commit complete. SQL> alter system archive log current; System altered. SQL> insert into yallonking values(6,'archive_test3',sysdate); 1 row created. SQL> commit; Commit complete. SQL> alter system archive log current; System altered. SQL> select rowid,t.* from yallonking t; ROWID ID NAME MY_DATE ------------------ ---------- -------------------- ------------------- AAARciAAFAAAACHAAA 1 yallonking 2013/07/22 09:44:53 AAARciAAFAAAACHAAB 2 oraking 2013/07/22 09:45:07 AAARciAAFAAAACHAAC 3 xiaolong 2013/07/22 09:50:09 AAARciAAFAAAACHAAD 4 archive_test1 2013/07/24 11:31:48 AAARciAAFAAAACHAAE 5 archive_test2 2013/07/24 11:32:36 AAARciAAFAAAACHAAF 6 archive_test3 2013/07/24 11:32:51 6 rows selected.
清空redo记录,避免记录在redo中的存在影响测试
SQL> select a.GROUP#,MEMBER,a.STATUS from v$log a,v$logfile b where a.GROUP#=b.GROUP#; GROUP# MEMBER STATUS ---------- --------------------------------------------- ---------------- 1 /u01/app/oracle/oradata/ora11gr2/redo01.log ACTIVE 2 /u01/app/oracle/oradata/ora11gr2/redo02.log CURRENT 3 /u01/app/oracle/oradata/ora11gr2/redo03.log ACTIVE SQL> alter database clear unarchived logfile '/u01/app/oracle/oradata/ora11gr2/redo01.log'; Database altered. SQL> alter database clear unarchived logfile '/u01/app/oracle/oradata/ora11gr2/redo02.log'; alter database clear unarchived logfile '/u01/app/oracle/oradata/ora11gr2/redo02.log' * ERROR at line 1: ORA-01624: log 2 needed for crash recovery of instance ora11gr2 (thread 1) ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/ora11gr2/redo02.log' SQL> alter database clear unarchived logfile '/u01/app/oracle/oradata/ora11gr2/redo03.log'; Database altered. SQL> alter system switch logfile; System altered. SQL> alter database clear unarchived logfile '/u01/app/oracle/oradata/ora11gr2/redo02.log'; Database altered.
下边确认,每个记录都只在对应的归档日志中存在
[root@rhl6 ~]# cd /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_07_24 [root@rhl6 2013_07_24]# ls -ltr total 15528 -rw-r-----. 1 oracle oinstall 13705216 Jul 24 11:31 o1_mf_1_68_8yyloh5b_.arc -rw-r-----. 1 oracle oinstall 3072 Jul 24 11:32 o1_mf_1_69_8yylps9r_.arc -rw-r-----. 1 oracle oinstall 3584 Jul 24 11:32 o1_mf_1_70_8yylq9on_.arc -rw-r-----. 1 oracle oinstall 2186240 Jul 24 11:41 o1_mf_1_71_8yym6j68_.arc [root@rhl6 2013_07_24]# string * | grep 'archive_test1' -bash: string: command not found [root@rhl6 2013_07_24]# [root@rhl6 2013_07_24]# [root@rhl6 2013_07_24]# strings * | grep 'archive_test1' archive_test1 [root@rhl6 2013_07_24]# strings * | grep 'archive_test2' archive_test2 [root@rhl6 2013_07_24]# strings * | grep 'archive_test3' archive_test3 [root@rhl6 2013_07_24]# strings o1_mf_1_68_8yyloh5b_.arc | grep 'archive_test1' archive_test1 [root@rhl6 2013_07_24]# strings o1_mf_1_69_8yylps9r_.arc | grep 'archive_test2' archive_test2 [root@rhl6 2013_07_24]# strings o1_mf_1_70_8yylq9on_.arc | grep 'archive_test3' archive_test3 [root@rhl6 2013_07_24]# strings o1_mf_1_71_8yym6j68_.arc | grep 'archive_tes' [root@rhl6 ora11gr2]# cd /u01/app/oracle/oradata/ora11gr2/ [root@rhl6 ora11gr2]# strings *.log | grep 'archive_tes'
人为删除数据库数据文件和部分中间的归档日志,并进行从备份恢复数据库
[root@rhl6 2013_07_24]# rm -rf o1_mf_1_69_8yylps9r_.arc SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- /u01/app/oracle/oradata/ora11gr2/system01.dbf /u01/app/oracle/oradata/ora11gr2/sysaux01.dbf /u01/app/oracle/oradata/ora11gr2/undotbs01.dbf /u01/app/oracle/oradata/ora11gr2/users01.dbf /u01/app/oracle/oradata/ora11gr2/yallonking01.dbf SQL> !mv /u01/app/oracle/oradata/ora11gr2/yallonking01.dbf /tmp/yallonking01.dbf_bak SQL> shutdown immediate; ORA-01116: error in opening database file 5 ORA-01110: data file 5: '/u01/app/oracle/oradata/ora11gr2/yallonking01.dbf' ORA-27041: unable to open file Linux-x86_64 Error: 2: No such file or directory Additional information: 3 SQL> shutdown abort ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 939495424 bytes Fixed Size 2233960 bytes Variable Size 545261976 bytes Database Buffers 385875968 bytes Redo Buffers 6123520 bytes Database mounted. ORA-01157: cannot identify/lock data file 5 - see DBWR trace file ORA-01110: data file 5: '/u01/app/oracle/oradata/ora11gr2/yallonking01.dbf' RMAN> restore datafile 5; Starting restore at 24-JUL-13 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=21 device type=DISK channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00005 to /u01/app/oracle/oradata/ora11gr2/yallonking01.dbf channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/ORA11GR2/backupset/2013_07_24/o1_mf_nnndf_TAG20130724T112657_8yyld1x7_.bkp channel ORA_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/ORA11GR2/backupset/2013_07_24/o1_mf_nnndf_TAG20130724T112657_8yyld1x7_.bkp tag=TAG20130724T112657 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:01 Finished restore at 24-JUL-13 SQL> recover datafile 5; ORA-00279: change 761058 generated at 07/24/2013 11:26:57 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_07_24/o1_mf_1_68_8yy loh5b_.arc ORA-00280: change 761058 for thread 1 is in sequence #68 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} ORA-00279: change 761181 generated at 07/24/2013 11:31:59 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_07_24/o1_mf_1_69_8yy lps9r_.arc ORA-00280: change 761181 for thread 1 is in sequence #69 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} ORA-00308: cannot open archived log '/u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_07_24/o1_mf_1_69_8y ylps9r_.arc' ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such file or directory Additional information: 3
注:此处发现缺失的正是我们之前删除的那个中间归档日志69
查看数据库一致性
SQL> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# ------------------ 761498 SQL> select file#,checkpoint_change#,status from v$datafile; FILE# CHECKPOINT_CHANGE# STATUS ---------- ------------------ ------- 1 761498 SYSTEM 2 761498 ONLINE 3 761498 ONLINE 4 761498 ONLINE 5 761498 ONLINE SQL> select file#,change# from v$recover_file; FILE# CHANGE# ---------- ---------- 5 761181
下边使用BBED进行处理
BBED> d /v dba 1,1 offset 484 count 4 File: /u01/app/oracle/oradata/ora11gr2/system01.dbf (1) Block: 1 Offsets: 484 to 487 Dba:0x00400001 ------------------------------------------------------- 9a9e0b00 l .... <16 bytes per line> BBED> d /v dba 5,1 offset 484 count 4 File: /u01/app/oracle/oradata/ora11gr2/yallonking01.dbf (5) Block: 1 Offsets: 484 to 487 Dba:0x01400001 ------------------------------------------------------- 5d9d0b00 l ]... <16 bytes per line>
注:此处明显因为5号文件从备份恢复而来,故其scn滞后于文件1
凡是修改文件5的scn和1号文件一致,那么将会失去丢失归档之后的所有归档数据
下边我们只修改 kcrbaseq 为下一个日志序列,跳过缺失的日志
BBED> d /v dba 1,1 offset 484 count 4 File: /u01/app/oracle/oradata/ora11gr2/system01.dbf (1) Block: 1 Offsets: 484 to 487 Dba:0x00400001 ------------------------------------------------------- 9a9e0b00 l .... <16 bytes per line> BBED> d /v dba 5,1 offset 484 count 4 File: /u01/app/oracle/oradata/ora11gr2/yallonking01.dbf (5) Block: 1 Offsets: 484 to 487 Dba:0x01400001 ------------------------------------------------------- 5d9d0b00 l ]... <16 bytes per line> BBED> d /v dba 5,1 offset 500 count 4 File: /u01/app/oracle/oradata/ora11gr2/yallonking01.dbf (5) Block: 1 Offsets: 500 to 503 Dba:0x01400001 ------------------------------------------------------- 45000000 l E... <16 bytes per line>
查看发现当前的日志序列是 0x45也就是69号,我们将其改成0x46也就是70号日志文件
BBED> m /x 46 dba 5,1 offset 500 File: /u01/app/oracle/oradata/ora11gr2/yallonking01.dbf (5) Block: 1 Offsets: 500 to 503 Dba:0x01400001 ------------------------------------------------------------------------ 46000000 <32 bytes per line> BBED> sum apply; Check value for File 5, Block 1: current = 0xcd85, required = 0xcd85
再次恢复
SQL> recover datafile 5; ORA-00279: change 761181 generated at 07/24/2013 11:31:59 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_07_24/o1_mf_1_70_8yy lq9on_.arc ORA-00280: change 761181 for thread 1 is in sequence #70 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} ORA-00326: log begins at change 761200, need earlier change 761181 <<也就是当前的scn 000b9d5d ORA-00334: archived log: '/u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_07_24/o1_mf_1_70_8y ylq9on_.arc'
注:此处发现该文件的scn太久
我们继续修改5号文件的scn为 761200 也就是十六进制的 000b9d70,如下计算
SQL> select to_char('761200','xxxxxxxx') from dual; TO_CHAR(' --------- b9d70 SQL> select to_number('000b9d70','xxxxxxxx') from dual; TO_NUMBER('00B9D70','XXXXXXXX') ------------------------------- 761200 BBED> d /v dba 1,1 offset 484 count 4 File: /u01/app/oracle/oradata/ora11gr2/system01.dbf (1) Block: 1 Offsets: 484 to 487 Dba:0x00400001 ------------------------------------------------------- 9a9e0b00 l .... <16 bytes per line> BBED> d /v dba 5,1 offset 484 count 4 File: /u01/app/oracle/oradata/ora11gr2/yallonking01.dbf (5) Block: 1 Offsets: 484 to 487 Dba:0x01400001 ------------------------------------------------------- 5d9d0b00 l ]... <16 bytes per line> BBED> m /x 709d0b00 dba 5,1 offset 484 <<注意字节序的反转 File: /u01/app/oracle/oradata/ora11gr2/yallonking01.dbf (5) Block: 1 Offsets: 484 to 487 Dba:0x01400001 ------------------------------------------------------------------------ 709d0b00 <32 bytes per line> BBED> sum apply; Check value for File 5, Block 1: current = 0xd326, required = 0xd326
下边继续尝试恢复数据文件
SQL> recover datafile 5; ORA-00279: change 761200 generated at 07/24/2013 11:31:59 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_07_24/o1_mf_1_70_8yy lq9on_.arc ORA-00280: change 761200 for thread 1 is in sequence #70 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} ORA-00279: change 761212 generated at 07/24/2013 11:32:57 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/ORA11GR2/archivelog/2013_07_24/o1_mf_1_71_8yy m6j68_.arc ORA-00280: change 761212 for thread 1 is in sequence #71 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} Log applied. Media recovery complete.
注:此处已经跳过缺失的归档日志,并成功的应用了之后的归档进行了数据文件的恢复
检查测试数据
SQL> alter database open; Database altered. SQL> alter session set nls_date_format='yyyy/mm/dd hh24:mi:ss'; Session altered. SQL> select * from yallonking.yallonking; ID NAME MY_DATE ---------- -------------------- ------------------- 1 yallonking 2013/07/22 09:44:53 2 oraking 2013/07/22 09:45:07 3 xiaolong 2013/07/22 09:50:09 4 archive_test1 2013/07/24 11:31:48 6 archive_test3 2013/07/24 11:32:51
注:此处果真丢失了5号记录。
小结:
只要文件的scn和控制文件中的scn一致,则库便可以完成一致性检查打开,如果文件的scn滞后,那么就需要从该scn应用之后的日志(归档日志)追平scn。
在此例中,我们要跳过缺失的归档日志,我们需要设置该文件的scn为接下来归档开始的scn,以及设置日志序列号为接下来的归档日志序列号,这样才可跳过确实的归档日志进行恢复。