RAC下歸檔不放到共享盤的測試

gaopengtttt發表於2013-05-15
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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章