Oracle RMAN Recover中使用BBED 跳過缺失的歸檔 繼續 Recover 的測試

一.背景說明

 

Oracle RMAN 備份的恢復分2個步驟：RESTRE 和 RECOVER。

 

在這個過程當中，Recover 是依賴與歸檔文件的。

 

假設一種狀況：週一對數據庫作了全備，而後保留歸檔。週四發現數據庫有異常，準備恢復，發現週二的時候少了一個歸檔。

 

按照正常的狀況，咱們只能將數據庫恢復到週二缺失歸檔的以前的點。

 

那麼我這裏就是一個研究，如何跳過這個缺失的歸檔，讓數據庫繼續進行Recover。

 

根據測試結果，Recover 是能夠繼續，可是測試的結果意義不是很大，由於仍是有數據丟失。

 

因此這裏更多的是對這種方法的拋磚引玉。

 

二.測試案例

 

2.1 使用RMAN 全備數據庫

此步驟直接備份便可。

 

2.2 建立測試表dave1並切換歸檔

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

 

 SEQUENCE#

----------

      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