Oracle RMAN Recover中使用BBED 跳过缺失的归档继续 Recover 的测试

时间 2019-11-09

标签 oracle rman recover 使用 bbed 跳过缺失归档继续测试栏目 Oracle 繁體版

原文原文链接

一.背景说明

Oracle RMAN 备份的恢复分2个步骤：RESTRE 和 RECOVER。数据库

在这个过程当中，Recover 是依赖与归档文件的。session

假设一种状况：周一对数据库作了全备，而后保留归档。周四发现数据库有异常，准备恢复，发现周二的时候少了一个归档。oracle

按照正常的状况，咱们只能将数据库恢复到周二缺失归档的以前的点。app

那么我这里就是一个研究，如何跳过这个缺失的归档，让数据库继续进行Recover。测试

根据测试结果，Recover 是能够继续，可是测试的结果意义不是很大，由于仍是有数据丢失。ui

因此这里更多的是对这种方法的抛砖引玉。 spa

二.测试案例

2.1 使用RMAN 全备数据库

此步骤直接备份便可。.net

2.2 建立测试表dave1并切换归档

SQL> select sequence# from v$log wherethread#=1;rest

SEQUENCE#code

----------

152

151

SQL> create table dave1 as select * fromdba_users;

Table created.

SQL> alter system switch logfile;

System altered.

SQL> select sequence# from v$log wherethread#=1;

SEQUENCE#

----------

152

153

2.3 建立测试表dave2并切换归档

SQL> create table dave2 as select * fromdba_users;

Table created.

SQL> alter system switch logfile;

System altered.

SQL> select sequence#,status from v$logwhere thread#=1;

SEQUENCE# STATUS

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

154 CURRENT

153 ACTIVE

SQL> select sequence# fromv$archived_log where thread#=1;

SEQUENCE#

----------

148

149

150

151

152

153

6 rows selected.

2.4 删除153的归档

[oracle@dave arch]$ ll

total 42200

-rw-r-----. 1 oracle oinstall 42715136Jul 5 22:56 1_125_816661296.dbf

-rw-r-----. 1 oracle oinstall 248320 Jul 6 23:14 1_152_816661296.dbf

-rw-r-----. 1 oracle oinstall 127488 Jul 6 23:15 1_153_816661296.dbf

-rw-r-----. 1 oracle oinstall 113664 Jul 6 23:19 1_154_816661296.dbf

[oracle@dave arch]$ rm-rf 1_153_816661296.dbf

[oracle@dave arch]$ ll

total 42072

-rw-r-----. 1 oracle oinstall 42715136Jul 5 22:56 1_125_816661296.dbf

-rw-r-----. 1 oracle oinstall 248320 Jul 6 23:14 1_152_816661296.dbf

-rw-r-----. 1 oracle oinstall 113664 Jul 6 23:19 1_154_816661296.dbf

[oracle@dave arch]$

2.5 而后进行restore 和recover

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL>

SQL> startup mount

RMAN> restore database;

Starting restore at 06-JUL-13

released channel: ORA_DISK_1

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=20 device type=DISK

channel ORA_DISK_1: starting datafilebackup set restore

channel ORA_DISK_1: specifying datafile(s)to restore from backup set

channel ORA_DISK_1: restoring datafile00001 to /u01/app/oracle/oradata/dave/system.256.816661027

channel ORA_DISK_1: restoring datafile00003 to /u01/app/oracle/oradata/dave/undotbs1.258.816661037

channel ORA_DISK_1: restoring datafile00005 to /u01/app/oracle/oradata/dave/undotbs2.265.816661787

channel ORA_DISK_1: reading from backuppiece /u01/backup/dave_lev0_06oe3kdv_1_1_20130706

channel ORA_DISK_1: piecehandle=/u01/backup/dave_lev0_06oe3kdv_1_1_20130706 tag=DAVE_LEV0

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete,elapsed time: 00:00:25

channel ORA_DISK_1: starting datafilebackup set restore

channel ORA_DISK_1: specifying datafile(s)to restore from backup set

channel ORA_DISK_1: restoring datafile00002 to /u01/app/oracle/oradata/dave/sysaux.257.816661033

channel ORA_DISK_1: restoring datafile00004 to /u01/app/oracle/oradata/dave/users.259.816661039

channel ORA_DISK_1: restoring datafile00006 to /u01/app/oracle/oradata/dave/dave01.dbf

channel ORA_DISK_1: restoring datafile00007 to /u01/app/oracle/oradata/dave/dave02.dbf

channel ORA_DISK_1: reading from backuppiece /u01/backup/dave_lev0_05oe3kdv_1_1_20130706

channel ORA_DISK_1: piece handle=/u01/backup/dave_lev0_05oe3kdv_1_1_20130706tag=DAVE_LEV0

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete,elapsed time: 00:00:25

Finished restore at 06-JUL-13

RMAN>

RMAN> recoverdatabase;

Starting recover at 06-JUL-13

using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 152is already on disk as file /u01/arch/1_152_816661296.dbf

archived log for thread 1 with sequence 154is already on disk as file /u01/arch/1_154_816661296.dbf

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGESTACK FOLLOWS ===============

RMAN-00571:===========================================================

RMAN-03002: failure of recover command at07/06/2013 23:23:48

RMAN-06053: unable to perform mediarecovery because of missing log

RMAN-06025: no backup ofarchived log for thread 1 with sequence 153 and starting SCN of 3836001 foundto restore

RMAN>

这个153 是咱们刚才手工删掉的归档。若是这个不搞定，后面没办法恢复。

2.6 BBED 推荐SCN

2.6.1 修改原理说明

-- System Checkpoint SCN：

SQL> select checkpoint_change# fromv$database;

CHECKPOINT_CHANGE#

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

3836654

--- Datafile CheckpointSCN：

SQL> select name,checkpoint_change# fromv$datafile;

NAME CHECKPOINT_CHANGE#

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

/u01/app/oracle/oradata/dave/system.256.816661027 3836654

/u01/app/oracle/oradata/dave/sysaux.257.816661033 3836654

/u01/app/oracle/oradata/dave/undotbs1.258.816661037 3836654

/u01/app/oracle/oradata/dave/users.259.816661039 3836654

/u01/app/oracle/oradata/dave/undotbs2.265.816661787 3836654

/u01/app/oracle/oradata/dave/dave01.dbf 3836654

/u01/app/oracle/oradata/dave/dave02.dbf 3836654

7 rows selected.

---START SCN:

SQL> select name,checkpoint_change# fromv$datafile_header;

NAME CHECKPOINT_CHANGE#

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

/u01/app/oracle/oradata/dave/system.256.816661027 3835435

/u01/app/oracle/oradata/dave/sysaux.257.816661033 3835434

/u01/app/oracle/oradata/dave/undotbs1.258.816661037 3835435

/u01/app/oracle/oradata/dave/users.259.816661039 3835434

/u01/app/oracle/oradata/dave/undotbs2.265.816661787 3835435

/u01/app/oracle/oradata/dave/dave01.dbf 3835434

/u01/app/oracle/oradata/dave/dave02.dbf 3835434

7 rows selected.

+++++SCN号与数据库启动：

在数据库启动过程当中，当 SystemCheckpoint SCN、Datafile Checkpoint SCN和Start SCN号都相同时，数据库能够正常启动，不须要作mediarecovery.三者当中有一个不一样时，则须要作media recovery。

若是在启动的过程当中，EndSCN号为NULL，则须要作instance recovery。ORACLE在启动过程当中首先检查是否须要media recovery，而后再检查是否须要instance recovery。

在进行recovery的时候，咱们根据归档，推动START SCN，可是归档缺失，致使没法推荐，数据库也没法启动。

咱们这里缺失的是153的归档，咱们只须要手工的修改datafile header，让数据库认为这个归档已经恢复了，便可。这是一种欺骗行为，虽然能够继续，但仍是会出现问题。

能够使用以下方法肯定具体缺失的归档SCN,而后使用BBED 跳过这些SCN 便可。

SQL> selectsequence#,first_change#,next_change# from v$archived_log;

SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#

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

148 3834837 3835155

149 3835155 3835184

150 3835184 3835498

151 3835498 3835507

152 3835507 3836001

153 3836001 3836079

154 3836079 3836303

7 rows selected.

这个正好与咱们以前RMAN 错误一致：

RMAN-03002: failure of recover command at07/06/2013 23:23:48

RMAN-06053: unable to perform mediarecovery because of missing log

RMAN-06025: no backup ofarchived log for thread 1 with sequence 153 and starting SCN of 3836001 foundto restore

2.6.2 使用BBED 推动全部DATAFILE header SCN

这里，咱们只修改kscnbas的值：

kscnbas (at offset 484) - SCN of lastchange to the datafile.

BBED> info

File# Name Size(blks)

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

1 /u01/app/oracle/oradata/dave/system.256.816661027 129280

2 /u01/app/oracle/oradata/dave/sysaux.257.816661033 97280

3 /u01/app/oracle/oradata/dave/undotbs1.258.816661037 9600

4 /u01/app/oracle/oradata/dave/users.259.816661039 640

5 /u01/app/oracle/oradata/dave/undotbs2.265.816661787 12800

6 /u01/app/oracle/oradata/dave/dave01.dbf 393216

7 /u01/app/oracle/oradata/dave/dave02.dbf 6400

+++咱们须要将全部datafile 的SCN从3836001 推到3836079：

SQL> selectto_char('3836079','xxxxxxxxx') from dual;

TO_CHAR('3

----------

3a88af

所以咱们的kscnbas 的新值是：0x003a88af。

可是注意，对于little-endian的format，他存储是先存储低位的，所以实际block 存储的是：af883a00.

咱们须要使用BBED 将全部datafileheader 的@484 的值修改为：af883a00。

BBED> d /v dba 1,1 offset 484

File:/u01/app/oracle/oradata/dave/system.256.816661027 (1)

Block: 1 Offsets: 484 to 499 Dba:0x00400001

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

2b863a00 00000000 bfd1e130 01000000 l+.:........0....

<16 bytes per line>

BBED> modify /x af88 dba 1,1 offset 484

File: /u01/app/oracle/oradata/dave/system.256.816661027(1)

Block: 1 Offsets: 484 to 499 Dba:0x00400001

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

af883a00 00000000 bfd1e130 01000000

<32 bytes per line>

BBED> sum dba 1,1 apply

Check value for File 1, Block 1:

current = 0xe9ba, required = 0xe9ba

+++按照一样的步骤，把剩下的6个datafile都修改。

--BBED 推荐成功：

SQL> selectfile#,checkpoint_change#,status from v$datafile_header;

FILE# CHECKPOINT_CHANGE# STATUS

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

1 3836079 ONLINE

2 3836079 ONLINE

3 3836079 ONLINE

4 3836079 ONLINE

5 3836079 ONLINE

6 3836079 ONLINE

7 3836079 ONLINE

7 rows selected.

这里的datafile 的SCN 都跳过了咱们缺失的归档，咱们能够继续进行recover了。

2.7 从新进行Recover

RMAN> recover database;

Starting recover at 07-JUL-13

using channel ORA_DISK_1

starting media recovery

media recovery failed

RMAN-00571:===========================================================

RMAN-00569: =============== ERROR MESSAGESTACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at07/07/2013 01:04:43

ORA-00283: recovery session canceled due toerrors

RMAN-11003: failure during parse/executionof SQL statement: alter database recover if needed

start

ORA-00283: recovery session canceled due toerrors

ORA-00600: internal errorcode, arguments: [3020], [3], [8077], [12590989], [], [], [], [], [], [], [],[]

ORA-10567:Redo is inconsistent with data block (file# 3, block# 8077, file offset is 66166784 bytes)

ORA-10564: tablespaceUNDOTBS1

ORA-01110: data file 3:'/u01/app/oracle/oradata/dave/undotbs1.258.816661037'

ORA-10560: block type 'KTU UNDO BLOCK'

根据官网的说明，咱们这是UNDO 表空间恢复没法继续了，详见：

Resolving ORA-600[3020] Raised During Recovery (文档 ID 361172.1)

尝试跳过坏块测试：

RMAN> recover database allow 50 corruption;

Starting recover at 07-JUL-13

using channel ORA_DISK_1

starting media recovery

media recovery complete, elapsed time:00:00:01

Finished recover at 07-JUL-13

RMAN>

恢复是没有问题，可是打开是有问题的：

SQL> alter database open;

alter database open

ERROR at line 1:

ORA-01092: ORACLE instance terminated.Disconnection forced

ORA-01578: ORACLE data block corrupted(file # 3, block # 128)

ORA-01110: data file 3:'/u01/app/oracle/oradata/dave/undotbs1.258.816661037'

Process ID: 32549

Session ID: 16 Serial number: 5

2.8 重建UNDO 表空间

这里里面的 3 就是咱们的undo 表空间，咱们把从新建立一个UNDO 在拉起数据库：

2.8.1 用spfile 建立pfile，而后修改参数

#*.undo_tablespace='UNDOTBS1'

*.undo_management='MANUAL'

*.rollback_segments='SYSTEM'

2.8.2 用修改以后的pfile，重启DB

SQL> startuppfile='/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initdave.ora'

ORACLE instance started.

Total System Global Area 718188544 bytes

Fixed Size 2231832 bytes

Variable Size 436208104 bytes

Database Buffers 276824064 bytes

Redo Buffers 2924544 bytes

Database mounted.

Database opened.

SQL>

2.8.3 删除原来的表空间，建立新的UNDO 表空间

SQL> select tablespace_name fromdba_tablespaces;

TABLESPACE_NAME

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

SYSTEM

SYSAUX

UNDOTBS1

TEMP

USERS

UNDOTBS2

DAVE

7 rows selected.

SQL> droptablespace undotbs1;

SQL> create undo tablespace undotbs1datafile '/u01/app/oracle/oradata/dave/undotbs1.dbf' size 50M;

Tablespace created.

2.8.4 关闭数据库，修改pfile参数，而后用新的pfile建立spfile，在正常启动数据库。

*.undo_tablespace='UNDOTBS1'

#*.undo_management='MANUAL'

#*.rollback_segments='SYSTEM'

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

Total System Global Area 718188544 bytes

Fixed Size 2231832 bytes

Variable Size 436208104 bytes

Database Buffers 276824064 bytes

Redo Buffers 2924544 bytes

Database mounted.

Database opened.

SQL>

库终于拉起来了。

2.9 验证

SQL> select name,checkpoint_change# fromv$datafile;

NAME CHECKPOINT_CHANGE#

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

/u01/app/oracle/oradata/dave/system.256.816661027 3857521

/u01/app/oracle/oradata/dave/sysaux.257.816661033 3857521

/u01/app/oracle/oradata/dave/undotbs1.dbf 3857521

/u01/app/oracle/oradata/dave/users.259.816661039 3857521

/u01/app/oracle/oradata/dave/undotbs2.265.816661787 3857521

/u01/app/oracle/oradata/dave/dave01.dbf 3857521

/u01/app/oracle/oradata/dave/dave02.dbf 3857521

7 rows selected.

SQL> select name,checkpoint_change# fromv$datafile_header;

NAME CHECKPOINT_CHANGE#

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

/u01/app/oracle/oradata/dave/system.256.816661027 3857521

/u01/app/oracle/oradata/dave/sysaux.257.816661033 3857521

/u01/app/oracle/oradata/dave/undotbs1.dbf 3857521

/u01/app/oracle/oradata/dave/users.259.816661039 3857521

/u01/app/oracle/oradata/dave/undotbs2.265.816661787 3857521

/u01/app/oracle/oradata/dave/dave01.dbf 3857521

/u01/app/oracle/oradata/dave/dave02.dbf 3857521

7 rows selected.

SQL> select checkpoint_change# fromv$database;

CHECKPOINT_CHANGE#

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

3857521

SQL> select count(1) from dave1;

select count(1) from dave1

ERROR at line 1:

ORA-00942: table or view does not exist

SQL> select count(1) from dave2;

select count(1) from dave2

ERROR at line 1:

ORA-00942: table or view does not exist

库是正常拉起来了，不过以前建立的表都没有成功恢复。

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

版权全部，文章容许转载，但必须以连接方式注明源地址，不然追究法律责任!

QQ: 251097186

Skype: tianlesoftware

Email: tianlesoftware@gmail.com

Blog: http://blog.csdn.net/tianlesoftware

Weibo: http://weibo.com/tianlesoftware

Twitter: http://twitter.com/tianlesoftware

Facebook: http://www.facebook.com/tianlesoftware

Linkedin: http://cn.linkedin.com/in/tianlesoftware

Oracle RMAN Recover中使用BBED 跳过缺失的归档 继续 Recover 的测试

一.背景说明

二.测试案例

2.1 使用RMAN 全备数据库

2.2 建立测试表dave1并切换归档

2.3 建立测试表dave2并切换归档

2.4 删除153的归档

2.5 而后进行restore 和recover

2.6 BBED 推荐SCN

2.6.1 修改原理说明

2.6.2 使用BBED 推动全部DATAFILE header SCN

2.7 从新进行Recover

2.8 重建UNDO 表空间

2.8.1 用spfile 建立pfile，而后修改参数

2.8.2 用修改以后的pfile，重启DB

2.8.3 删除原来的表空间，建立新的UNDO 表空间

2.8.4 关闭数据库，修改pfile参数，而后用新的pfile建立spfile，在正常启动数据库。

2.9 验证

Oracle RMAN Recover中使用BBED 跳过缺失的归档继续 Recover 的测试