ORACLE RAC資料庫的備份與恢復(2)

junsansi發表於2010-03-31

2、配置節點歸檔間歸檔檔案的自動傳送

  首先要明確一點,通過RMAN建立備份集時,必須保證連線到的例項能夠訪問所有節點所生成的歸檔日誌,否則會導致備份失敗(除非不備份歸檔檔案)。 對於單例項當然不存在這樣的問題,因為單例項資料庫的歸檔通常是放在本地,必然能夠訪問(廢話,不能訪問的話怎麼寫進去的),不過對於多例項的RAC資料庫這就可能會成為一個問題, 如何保證RMAN能夠訪問到所有節點生成的歸檔檔案呢 ?兩種方案:

  • 各節點生成的歸檔放到共享儲存上,這樣自然可以確保每個節點都能夠訪問到,比如將歸檔存放到ORACLE的ASM,或者是第三方提供的叢集檔案系統中;
  • 各節點除在本地生成歸檔檔案外,另外向其它節點或者說執行備份的節點傳送歸檔日誌,以確保執行備份的那臺節點能夠訪問到所有的歸檔檔案。

  從RMAN易用的角度來說,將歸檔放置於共享儲存上無疑是最方便的,不過第三方叢集件的配置又會帶來一些其它額外的管理成本;ASM倒是簡單,但是三思的個人看法是這樣,ASM確實好用效率也不錯,不過由於ASM對DBA來說就像個黑匣子(起碼10g版本是這樣,當然也有可能是俺研究的還不夠深入),使用上了之後就得求天保佑千萬不要出現問題,一旦出現問題很有可能都不知該從何處著手處理。因此,這裡三思決定採用另外的方案。

  ORACLE 的重做日誌傳送機制非常靈活,在10g版本中可以同時向10個目標地寫入歸檔(11g增加到了30個),這裡三思準備利用這種特性,將各節點生成的歸檔傳送到執行備份的節點中,來實現該節點能夠訪問所需的歸檔檔案。

  操作非常簡單,其實上就是給LOG_ARCHIVE_DEST_n初始化引數設定適當的值,例如當下的測試環境中,三思經過慎重考慮,決定將備份操作放在節點2端執行,因此,只需要在節點1中,設定傳送節點1生成的歸檔檔案到節點2即可,操作如下:

    JSSDBN1 > alter system set log_archive_dest_2=¨service=jssdbn2¨ sid=¨jssdbn1¨;

    System altered.

  命令中設定的jssdbn2是指tnsnames.ora檔案中配置的連線節點2的網路服務名(好繞口),除此之外呢,還有一個初始化引數LOG_ARCHIVE_LOCAL_FIRST,用來設定是否首先歸檔檔案到本地,預設為true,將其改為false,同樣只修改節點1的設定即可,操作如下:

    JSSDBN1> alter system set log_archive_local_first=false sid=¨jssdbn1¨;

    System altered.

  測試一下效果,嘗試手動觸發歸檔操作,然後檢視是否成功歸檔至各節點的適當位置:

    JSSDBN1> alter system switch logfile;

    System altered.

    JSSDBN1> select inst_id,recid,dest_id,name from gv$archived_log where sequence#=219;

       INST_ID RECID DEST_ID NAME

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

             1     8       2 /data/oradata/jssdbn2/archivelog/1_219_703671669.dbf

             1     9       1 /data/oradata/jssdbn1/archivelog/1_219_703671669.dbf

             2     8       2 /data/oradata/jssdbn2/archivelog/1_219_703671669.dbf

             2     9       1 /data/oradata/jssdbn1/archivelog/1_219_703671669.dbf

  歸檔檔案成功生成併傳送到節點2端!

    提示:

    RAC 資料庫各例項擁有各自的REDO執行緒,因此還需要考慮各節點生成的歸檔檔名稱規則的問題,不要因為檔名生成規則不合適造成檔名重複,導致歸檔失敗。歸檔檔名的生成規則由LOG_ARCHIVE_FORMAT初始化引數控制,還好預設情況下是 %t_%s_%r.dbf ( 具體%符所代表意義就不說了,可以參考之前三思筆記系列文章),不會導致重複的發生。

  下面我們來考慮一個問題~~~

  問:丟失了幾個歸檔怎麼辦?

  答:簡單,涼拌,噢對不起說錯了,是冷複製。

  比如說由於山崩地裂洪水海嘯等等這些最近幾年我們耳熟能詳的事件原因導致節點1的某幾個歸檔沒能成功傳送至節點2,結果節點2執行備份時報錯(一般是提示找不到歸檔檔案),那麼手工複製缺少的幾個歸檔到節點2的適當路徑下就好了,用什麼複製呢?方式很多,如果檔案數目不多的話,直接用scp命令吧,比如說這裡我們複製seq為218的歸檔檔案到節點2,操作如下。

  首先是找到要複製的檔案詳細路徑,最簡單的方式就是從v$archived_log檢視中查詢:

    JSSDBN1> select name from v$archived_ l og where sequence#=218;

    NAME

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

    /data/oradata/jssdbn1/archivelog/1_218_703671669.dbf

  接下來通過scp命令來複制檔案,scp可以在任意節點上操作,語法也比較簡單,就是指明源路徑和目標路徑就好,例如:

    [oracle@jssdbn1 ~]$ scp /data/oradata/jssdbn1/archivelog/1_218_703671669.dbf jssdbn2:/data/oradata/jssdbn2/archivelog/1_218_703671669.dbf

    1_218_703671669.dbf                                                                               100%   34MB  17.1MB/s   00:02

  然後在節點2註冊該歸檔檔案,操作如下:

    JSSDBN2> alter database register physical logfile ¨/data/oradata/jssdbn2/archivelog/1_218_703671669.dbf¨;

    Database altered.

  再次查詢gv$archived_log,確定歸檔檔案已被註冊:

    JSSDBN2> select inst_id,recid,dest_id,name from gv$archived_log where sequence#=218;

       INST_ID RECID DEST_ID NAME

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

             2     7       1 /data/oradata/jssdbn1/archivelog/1_218_703671669.dbf

             2    10       1 /data/oradata/jssdbn2/archivelog/1_218_703671669.dbf

             1     7       1 /data/oradata/jssdbn1/archivelog/1_218_703671669.dbf

             1    10       1 /data/oradata/jssdbn2/archivelog/1_218_703671669.dbf

  那麼再接下來呢...........................

 

 

 

 

 

 

 

  下面沒有了~~

  今天先到這兒,明天同一時間同一地點,請大家繼續關注!

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7607759/viewspace-630876/,如需轉載,請註明出處,否則將追究法律責任。

相關文章