rman中三個不完全恢復場景(r6筆記第16天)
rman在資料的備份恢復中還是發揮了重大的作用，把冷備，熱備這種手工備份方式做了整合化的管理，可以基於這個工具集完成相對複雜額備份恢復工作。 當然了rman相對於傳統的手工備份，提供了更多的改進， 比如壓縮備份，我們手工測試的場景中，一個1.5G的小庫，如果資料檔案的使用率不到300M，那麼生成的dump就在近300M，如果開啟壓縮備份的方式，生成的備份集差不多會在80M左右，改進的幅度還是很大的。比如並行備份，開啟多個通道對於資料庫中的多個數據檔案備份進行分工，還可以在這個基礎 上進行備份切分，把一個很大的備份集切分成多個指定單位大小的備份分片。 比如備份的加密方式，從安全性上也可以保證。 比如增量備份，這種方式通過手工方式是完成不了的。增量備份把資料的備份工作可以當做一個很有規劃性的工作來做。 當然備份是基礎，資料的恢復在這個基礎上就更為重要了。如果資料恢復不了，備份的意義就會大打折扣。 自己做了下面三個簡單的測試，屬於三個不完全恢復額場景，我們來看看在手工備份恢復的繁瑣之外，rman下是怎麼做的，有哪些改進，有些時候還可能需要動用一些非常規手段。 第一個例子是一個刪除使用者的例子， 我們已經存在一個備份，歸檔都保留著，然後我們在制定的時間刪除了資料庫中某個使用者，然後嘗試基於時間點的不完全恢復 目前我們存在下面的資料庫使用者，我們就拿newtest這個使用者開刀。
SQL> select *from all_users; USERNAME USER_ID CREATED ------------------------------ ---------- --------- TEST_UPDATE 33 29-JUL-15 NEWTEST 32 19-JUL-15 MGMT_VIEW 30 05-JUL-15 DBSNMP 24 04-JUL-15 TSMSYS 21 04-JUL-15 SYSMAN 28 05-JUL-15 DIP 19 04-JUL-15 OUTLN 11 04-JUL-15 SYSTEM 5 04-JUL-15 SYS 0 04-JUL-15 10 rows selected.
為了進行回覆後的驗證，我們隨便拿出一個有資料的表來做一個基本的驗證。
SQL> conn newtest/newtest
Connected.
SQL> select count(*)from t;
COUNT(*)
----------
6338然後開始我們的不完全恢復。從下面可以看到目前的日誌已經做了resetlogs啟動，序列是從1開始，但是在10g之後，resetlogs 啟動資料庫，原來的備份依然可用。
SQL> select sequence#,status from v$log; SEQUENCE# STATUS ---------- ---------------- 1 CURRENT 0 UNUSED 0 UNUSED
我們標記一下時間戳，然後刪除這個使用者
SQL> select systimestamp from dual;
SYSTIMESTAMP
---------------------------------------------------------------------------
02-AUG-15 09.19.56.666830 PM +08:00
SQL> drop user newtest cascade;
User dropped.破壞之後，我們停庫啟動到mount階段，開始做不完全恢復
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.通過rman來恢復，步驟就相對簡單多了。
RMAN> startup mount
Oracle instance started
database mounted
Total System Global Area 314572800 bytes
Fixed Size 1261564 bytes
Variable Size 163577860 bytes
Database Buffers 142606336 bytes
Redo Buffers 7127040 bytes
RMAN> run
2> {
3> set until time "to_date('2015-08-02:21:19:56','YYYY-MM-DD HH24:MI:SS')";
4> restore database;
5> recover database;
6> }這樣後臺就會自動去完成還原和恢復的工作，恢復的部分日誌如下：
starting media recovery
archive log thread 1 sequence 9 is already on disk as file /u02/oracle/flash_recovery_area/TEST10G/archivelog/2015_08_02/o1_mf_1_9_bvw5nrd2_.arc
archive log thread 1 sequence 10 is already on disk as file /u02/oracle/flash_recovery_area/TEST10G/archivelog/2015_08_02/o1_mf_1_10_bvw60std_.arc
archive log filename=/u02/oracle/flash_recovery_area/TEST10G/archivelog/2015_08_02/o1_mf_1_9_bvw5nrd2_.arc thread=1 sequence=9
archive log filename=/u02/oracle/flash_recovery_area/TEST10G/archivelog/2015_08_02/o1_mf_1_10_bvw60std_.arc thread=1 sequence=10
media recovery complete, elapsed time: 00:00:09
Finished recover at 02-AUG-15就這樣就輕鬆完成了時間點的恢復，使用resetlogs的方式開啟資料庫。
RMAN> alter database open resetlogs;
database opened我們簡單驗證一下使用者是否已經恢復回來。可以看到一切都在預料之中。
SQL> conn newtest/newtest
Connected.
SQL> select count(*)from t;
COUNT(*)
----------
6338
:第二個例子是一個相對來說暴力的破壞，我們刪除了所有的資料檔案，日誌檔案，控制檔案。然後嘗試恢復。 先是破壞，我們到資料檔案的目錄下，刪除全部檔案
$ rm *
然後使用rman把資料庫啟動到nomount階段，開始嘗試恢復控制檔案。
[oracle@oel1 TEST10G]$ rman target /
Recovery Manager: Release 10.2.0.3.0 - Production on Sun Aug 2 21:33:24 2015
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database (not started)
RMAN> startup nomount
Oracle instance started
Total System Global Area 314572800 bytes
Fixed Size 1261564 bytes
Variable Size 163577860 bytes
Database Buffers 142606336 bytes
Redo Buffers 7127040 bytes
這個時候檢視rman的配置會發現，原有的配置都會丟失，因為我們刪除了所有的資料。
RMAN> show all;
這個時候如果還原控制檔案，指定autobackup就會報錯，因為配置丟失，壓根找不到備份的配置。
RMAN> restore controlfile from autobackup;
Starting restore at 02-AUG-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=34 devtype=DISK
recovery area destination: /u02/oracle/flash_recovery_area
database name (or database unique name) used for search: TEST10G
channel ORA_DISK_1: no autobackups found in the recovery area
autobackup search outside recovery area not attempted because DBID was not set
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/02/2015 21:33:49
RMAN-06172: no autobackup found or specified handle is not a valid copy or piece
這個時候，我們可以手工指定需要還原參照的控制檔案備份即可。 比如我們在備份目錄下看到最新的控制檔案備份，直接應用還原。
RMAN> restore controlfile from '/u02/oracle/flash_recovery_area/TEST10G/ctl_c-1135735312-20150802-0b';
Starting restore at 02-AUG-15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=38 devtype=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output filename=/u02/oracle/oradata/TEST10G/control01.ctl
output filename=/u02/oracle/oradata/TEST10G/control02.ctl
Finished restore at 02-AUG-15
然後資料庫啟動到Mount階段，開始還原和恢復資料庫，
RMAN> run{
2> restore database;
3> recover database;
4> }
還原還是很平滑的過程，關鍵就在於恢復的過程，最後肯定會丟擲一些問題來，類似下面的形式。
unable to find archive log
archive log thread=1 sequence=1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/02/2015 21:37:15
RMAN-06054: media recovery requesting unknown log: thread 1 seq 1 lowscn 1151365
這個時候我們就需要做不完全恢復，我們來採用基於sequence的恢復。
RMAN> run{
2> set until sequence 1;
3> recover database;
4> }
然後使用resetlogs的方式就可以開啟資料庫了。
RMAN> alter database open resetlogs;
database opened
這種方式也還是相對比較簡單的過程。 第三種場景略微複雜。 如果存在備份，但是備份集出現了一些問題，或者出現了一些歸檔檔案的缺失，restore可以順利完成，但是在recover的時候會報出下面的錯誤來。
RMAN> recover database;
Starting recover at 02-AUG-15
using channel ORA_DISK_1
using channel ORA_DISK_2
starting media recovery
unable to find archived log
archived log thread=1 sequence=1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/02/2015 12:26:43
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 1 and starting SCN of 1094536
這種情況下采用基於sequence的不完全恢復也沒有基礎。 如果這個時候我們無招可用，看看resetlogs的方式能不能啟動資料庫，會有下面的錯誤。
RMAN> alter database open resetlogs;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 08/02/2015 12:28:06
ORA-01152: file 3 was not restored from a sufficiently old backup
ORA-01110: data file 3: '/u02/ora11g/oradata/TEST/undotbs01.dbf'
可見還是備份集出現一些問題，主要原因還是控制檔案中記錄的scn號和備份集中的scn出現了gap,嘗試恢復的時候又沒有相應的歸檔。 我們可以採用隱含引數來做， 在pfile中加入下面的三個隱含引數
_allow_resetlogs_corruption=true
_corrupted_rollback_segments=true
_offline_rollback_segments=true然後，重新啟動資料庫到mount階段之後，使用resetlogs的方式即可強制開啟資料庫。 這種方式存在著一定的風險，但是也是無奈的場景下的一種方式。畢竟資料庫能夠open是一個很重要的檢查點，資料庫都啟動不了的話，整個恢復的意義就會大打折扣了。 所以通過上面的三個簡單的例子，可以看到在資料的不完全恢復中，還是有很多的選擇，不完全恢復相對於完全恢復來說，場景真是數不勝數，各種破壞各種坑。合理利用手中的備份是我們資料恢復的一個基礎。