RAC下歸檔不放到共享盤的測試
RAC下歸檔不放到共享盤的測試。
11.2.0.3 測試，因為11.2.0.3加入了SCAN_IP我們使用VIP連線預設情況下是連線到特定的例項所以
設定
RAC1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.143)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = racdb)
)
)
RAC2 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.144)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
備份使用語句
run {
allocate channel c1 device type disk connect sys/gelc123@RAC1;
allocate channel c2 device type disk connect sys/gelc123@RAC2;
backup format='/home/oracle/bak_%t_%s_%p.bak' database plus archivelog delete all input format '/home/oracle/arch_%t_%s_%p.bak';
release channel c1;
release channel c2;
}
當然最後自己顯示備份一下控制檔案比較好
測試1 能否進行完全恢復
猜測:雖然在節點2透過設定通道完成了備份，但是當節點1如果進行了日誌切換也就是說生成了新的歸檔日誌，這部分日誌是不能進行恢復的，只能進行不完全恢復
1、在節點1進行幾次日誌切換，然後檢視日誌生成
QL> alter system switch logfile;
System altered.
SQL> r
1* alter system switch logfile
System altered.
[oracle@rac1 admin]$ cd /home/oracle/archive/
[oracle@rac1 archive]$ ls
1_49_811227726.dbf 1_50_811227726.dbf
2、關閉資料庫
srvctl stop database -d racdb
3、複製節點的備份到節點2，也包括控制檔案
[oracle@rac1 dbs]$ scp c-808844491-20130329-03 192.168.1.142:/oracle/app/oracle/product/11.2.0/dbs/
c-808844491-20130329-03 100% 18MB 17.7MB/s 00:00
[oracle@rac1 ~]$ scp *.bak 192.168.1.142:/home/oracle/
arch_814692392_20_1.bak 100% 397MB 36.1MB/s 00:11
arch_814692412_22_1.bak 100% 146KB 145.5KB/s 00:00
arch_814692413_24_1.bak 100% 6144 6.0KB/s 00:00
arch_814692413_26_1.bak 100% 3584 3.5KB/s 00:00
arch_814692414_28_1.bak 100% 1380KB 1.4MB/s 00:00
arch_814692446_31_1.bak 100% 7168 7.0KB/s 00:00
bak_814692419_29_1.bak 100% 538MB 38.4MB/s 00:14
注意如果是備份到磁帶這一步是不需要的。
4、啟動節點的例項到MOUNT節點進行恢復控制檔案，然後啟動MOUNT階段
RMAN> restore controlfile from '/oracle/app/oracle/product/11.2.0/dbs/c-808844491-20130329-03';
Starting restore at 06-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=139 instance=racdb2 device type=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:12
output file name=+DATA/racdb/controlfile/current.260.811227723
Finished restore at 06-MAY-13
RMAN> sql 'alter database mount';
5、進行完全恢復
RMAN> restore database;
Starting restore at 06-MAY-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=125 instance=racdb2 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 00002 to +DATA/racdb/datafile/sysaux.257.811227637
channel ORA_DISK_1: restoring datafile 00005 to +DATA/racdb/datafile/example.264.811227735
channel ORA_DISK_1: restoring datafile 00006 to +DATA/racdb/datafile/undotbs2.265.811227979
channel ORA_DISK_1: reading from backup piece /home/oracle/bak_814692419_29_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/bak_814692419_29_1.bak tag=TAG20130506T072658
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
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 00001 to +DATA/racdb/datafile/system.256.811227637
channel ORA_DISK_1: restoring datafile 00003 to +DATA/racdb/datafile/undotbs1.258.811227637
channel ORA_DISK_1: restoring datafile 00004 to +DATA/racdb/datafile/users.259.811227637
channel ORA_DISK_1: reading from backup piece /home/oracle/bak_814692419_30_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/bak_814692419_30_1.bak tag=TAG20130506T072658
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
Finished restore at 06-MAY-13
RMAN> recover database;
Starting recover at 06-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=125 instance=racdb2 device type=DISK
starting media recovery
archived log for thread 1 with sequence 50 is already on disk as file +DATA/racdb/onlinelog/group_2.262.811227727
archived log for thread 1 with sequence 51 is already on disk as file +DATA/racdb/onlinelog/group_1.261.811227727
archived log for thread 2 with sequence 65 is already on disk as file +DATA/racdb/onlinelog/group_3.266.811228159
archived log for thread 2 with sequence 66 is already on disk as file +DATA/racdb/onlinelog/group_4.267.811228161
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=48
channel ORA_DISK_1: reading from backup piece /home/oracle/arch_814692446_31_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/arch_814692446_31_1.bak tag=TAG20130506T072726
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/home/oracle/archive/1_48_811227726.dbf thread=1 sequence=48
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=64
channel ORA_DISK_1: reading from backup piece /home/oracle/arch_814692447_32_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/arch_814692447_32_1.bak tag=TAG20130506T072726
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/home/oracle/archive/2_64_811227726.dbf thread=2 sequence=64
archived log file name=+DATA/racdb/onlinelog/group_3.266.811228159 thread=2 sequence=65
unable to find archived log
archived log thread=1 sequence=49
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/06/2013 09:25:58
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 49 and starting SCN of 4095531
可以看到確實和我們猜測一樣的找不到1_49_811227726.dbf。
測試2 透過複製的方式把歸檔複製過來
猜測：這樣應該沒問題了
[oracle@rac1 archive]$ scp * 192.168.1.142:/home/oracle/archive
1_49_811227726.dbf 100% 1024 1.0KB/s 00:00
1_50_811227726.dbf 100% 1024 1.0KB/s 00:00
繼續恢復
RMAN> recover database;
Starting recover at 06-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=144 instance=racdb2 device type=DISK
starting media recovery
archived log for thread 1 with sequence 50 is already on disk as file +DATA/racdb/onlinelog/group_2.262.811227727
archived log for thread 1 with sequence 51 is already on disk as file +DATA/racdb/onlinelog/group_1.261.811227727
archived log for thread 2 with sequence 65 is already on disk as file +DATA/racdb/onlinelog/group_3.266.811228159
archived log for thread 2 with sequence 66 is already on disk as file +DATA/racdb/onlinelog/group_4.267.811228161
archived log file name=/home/oracle/archive/1_49_811227726.dbf thread=1 sequence=49
archived log file name=+DATA/racdb/onlinelog/group_3.266.811228159 thread=2 sequence=65
archived log file name=+DATA/racdb/onlinelog/group_2.262.811227727 thread=1 sequence=50
archived log file name=+DATA/racdb/onlinelog/group_1.261.811227727 thread=1 sequence=51
archived log file name=+DATA/racdb/onlinelog/group_4.267.811228161 thread=2 sequence=66
Finished recover at 06-MAY-13
RMAN> sql 'alter database open';
可以看到恢復已經完成並且資料庫已經已經開啟，並且是應用我們的當前日誌檔案的。所以是可以完全恢復的。
測試3 RAC中的不完全恢復應該以低SCN為準，比如例項1的NEXT SCN為222 例項2的NEXT SCN為221 ，那麼恢復的recover database until scn 221,很好理解雖然RAC中的LOGFILE的seq是不相同的但是SCN一定的一致的，同樣的1-221的記錄都分別在兩個例項的
歸檔日誌中，但是221-222的只有例項1有例項2根本沒有，當然就不能恢復。
如下：
SEQUENCE# TIME_D CHANGE#
---------------------------------------- --------------------------------------- -----------------
---- 2013-05-06 07:26:59 4095499
---- 2013-05-06 07:26:59 4095499
---- 2013-05-06 07:26:59 4095499
---- 2013-05-06 07:26:59 4095497
---- 2013-05-06 07:26:59 4095497
---- 2013-05-06 07:26:59 4095497
64 2013-05-06 07:26:11=2013-05-06 07:27:15 4095359=4095528
48 2013-05-06 07:26:10=2013-05-06 07:27:16 4095356=4095531
47 2013-05-06 07:08:29=2013-05-06 07:26:10 4091232=4095356
63 2013-05-06 07:08:28=2013-05-06 07:26:11 4091229=4095359
62 2013-05-06 07:06:16=2013-05-06 07:08:28 4091028=4091229
46 2013-05-06 07:06:15=2013-05-06 07:08:29 4091024=4091232
45 2013-05-06 07:06:14=2013-05-06 07:06:15 4091021=4091024
44 2013-05-06 07:06:13=2013-05-06 07:06:14 4091018=4091021
61 2013-05-06 07:06:11=2013-05-06 07:06:16 4091014=4091028
60 2013-05-06 07:06:07=2013-05-06 07:06:11 4091010=4091014
可以看到這個恢復如果在只有備份集的情況下只能恢復到4095528而非4095531，也能看到RAC中SEQ的不同。
如果恢復到4095531報錯
RMAN> recover database until scn 4095531;
Starting recover at 06-MAY-13
using channel ORA_DISK_1
starting media recovery
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=48
channel ORA_DISK_1: reading from backup piece /home/oracle/arch_814692446_31_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/arch_814692446_31_1.bak tag=TAG20130506T072726
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/home/oracle/archive/1_48_811227726.dbf thread=1 sequence=48
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=64
channel ORA_DISK_1: reading from backup piece /home/oracle/arch_814692447_32_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/arch_814692447_32_1.bak tag=TAG20130506T072726
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/home/oracle/archive/2_64_811227726.dbf thread=2 sequence=64
unable to find archived log
archived log thread=2 sequence=65
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/06/2013 10:01:25
RMAN-06054: media recovery requesting unknown archived log for thread 2 with sequence 65 and starting SCN of 4095528
但是我們再次RESTORE recover到4095528如下：
RMAN> recover database until scn 4095528;
Starting recover at 06-MAY-13
using channel ORA_DISK_1
starting media recovery
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=48
channel ORA_DISK_1: reading from backup piece /home/oracle/arch_814692446_31_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/arch_814692446_31_1.bak tag=TAG20130506T072726
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/home/oracle/archive/1_48_811227726.dbf thread=1 sequence=48
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=64
channel ORA_DISK_1: reading from backup piece /home/oracle/arch_814692447_32_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/arch_814692447_32_1.bak tag=TAG20130506T072726
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/home/oracle/archive/2_64_811227726.dbf thread=2 sequence=64
media recovery complete, elapsed time: 00:00:00
Finished recover at 06-MAY-13
可以看到恢復完成。接下來只有resetlogs丟資料時不能避免的。
所以雖然歸檔不共享的情況下備份沒有問題，但是恢復只能在一個例項完成。如果放到磁帶上也不需要複製備份集，但是如果是在各自的儲存中是需要複製備份集到恢復節點上，因為每個節點都只有備份的一部分而已。
不管是磁帶還是各自儲存，新生成的歸檔時需要複製的到恢復端的。所以還是比較麻煩，還不如使用共享NFS當然ASM是更好的。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7728585/viewspace-761206/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 使用NFS共享RAC節點的歸檔目錄NFS
- RAC歸檔配置方案：使用NFS共享儲存儲存歸檔檔案NFS
- QC、QTP等測試工具已經放到網站資源共享QT網站
- RAC 環境下修改歸檔模式模式
- ORACLE RAC模式下歸檔模式和非歸檔模式的切換方法Oracle模式
- 使用OpenFiler來模擬儲存配置RAC中ASM共享盤及多路徑（multipath）的測試ASM
- 閃迴歸檔的簡單測試
- 【RAC】RAC環境下歸檔日誌格式約定
- RAC下啟動日誌歸檔模式模式
- 物理DG刪除歸檔測試
- RMAN恢復歸檔但是歸檔放到ASM中，ASM已經掛掉的情況ASM
- 將RAC資料庫更改為不歸檔日誌的模式資料庫模式
- Oracle RAC 歸檔與非歸檔切換Oracle
- rac更改歸檔模式模式
- 關於歸檔日誌的切換測試
- Oracle10g RAC下啟用歸檔模式Oracle模式
- rac下啟動關閉與更改歸檔模式模式
- 【Docker】Windows將docker下載的映象存放到其他盤DockerWindows
- 歸檔模式下的 nologging和/*+ append */引數 效能測試模式APP
- RAC環境中非歸檔改為歸檔模式模式
- RAC（ASM）歸檔模式修改ASM模式
- ORACLE RAC 設定歸檔Oracle
- ORACLE RAC 啟用歸檔Oracle
- 測試在丟失歸檔日誌的情況下，跳過部分歸檔日誌進行資料恢復資料恢復
- rac下啟動關閉與更改歸檔模式(zt)模式
- oracle 8i的歸檔與不歸檔切換Oracle
- 【轉】雙節點RAC下將資料庫從非歸檔模式更改到歸檔模式資料庫模式
- win10怎麼把電腦桌面的東西放到別的盤_win10如何把桌面檔案放到其他盤Win10
- Windows下RAC歸檔滿和ORA-04031問題Windows
- oracle RAC開啟歸檔模式Oracle模式
- RAC 開啟歸檔日誌
- 安卓 unit 測試與 instrument 測試的程式碼共享安卓
- 11GR2新特性測試-閃迴歸檔
- RAC－－歸檔日誌的開啟方法
- RAC的VIP切換測試
- RAC開啟資料庫歸檔資料庫
- 10G RAC歸檔設定
- rac歸檔模式/非歸檔模式下檔案建至本地儲存修復方法-ORA-01157模式