[記錄]Standby相關引數及gap問題解決

什麼時候傳送

這小節包含兩個內容，傳送什麼，以及傳送給誰：

1、透過VALID_FOR屬性指定傳輸及接收物件

valid_for，字面理解就是基於xx有效，再配合其redo_log_type,database_role屬性，我們基本上可以將其理解為：為指定角色設定日誌檔案的歸檔

路徑，主要目的是為了輔助一旦發生角色切換操作後資料庫的正常運轉。

redo_log_type可設定為：ONLINE_LOGFILE，STANDBY_LOGFILE，ALL_LOGFILES

database_role可設定為：PRIMARY_ROLE，STANDBY_ROLE，ALL_ROLES

注意valid_for引數是有預設值的，如果不設定的話，其預設值等同於：

valid_for=(ALL_LOGFILES,ALL_ROLES)

推薦主動設定該引數而不要使用預設值，某些情況下預設的引數值不一定合適，比如邏輯standby就不像物理standby，邏輯standby處於open模式，

不僅有redo資料而且還包含多種日誌檔案(online redologs,archived redologs以及standby redologs)。多數情況下，邏輯standby生成的online

redologs與standby redologs生成在相同的目錄內。因此，推薦你對每個*dest設定合適的valid_for屬性。

2、透過DB_UNIQUE_NAME屬性指定資料庫

DB_UNIQUE_NAME屬性主要是為某個資料庫指定唯一的資料庫名稱，這就使得動態新增standby到包含RAC結構的primary資料庫的dg配置成為可能，並

且對於log_archive_dest_n中的service屬性，其屬性值對應的也必然是db_unique_name，也正因有了db_unique_name，redo資料在傳輸過程中才能

確認傳輸到你希望被傳輸到的資料庫上。當然要保障傳輸redo資料到指定伺服器，除了db_unique_name,log_archive_dest_n之外，還有一個初始化

引數：log_archive_config。

關於log_archive_config呢，我們前面有過一些接觸，在第二部分第1節中也有一些簡單的介紹，log_archive_config初始化引數還包括幾個屬性，

可以用過控制資料庫的傳輸和接收，SEND,NOSEND,RECEIVE,NORECEIVE：

l SEND允許資料庫傳送資料到遠端

l RECEIVE則允許standby接收來自其它資料庫的資料

l NOSEND,NORECEIVE自然就是禁止嘍。

例如，設定primary資料庫不接收任何歸檔資料，可以做如下的設定：

LOG_ARCHIVE_CONFIG='NORECEIVE,DG_CONFIG=(jssweb,jsspdg)'

當然，你同樣也需要注意，一旦做了如上的設定，那麼假設該伺服器發生了角色切換，那它仍然也沒有接收redo資料的能力喲。

 

出錯了咋整

對於歸檔失敗的處理，LOG_ARCHIVE_DEST_n引數有幾個屬性可以用來控制一旦向歸檔過程中出現故障時應該採取什麼措施，它們是：

1、REOPEN 指定時間後再次嘗試歸檔

使用REOPEN=seconds(預設=300)屬性，在指定時間重複嘗試向歸檔目的地進行歸檔操作，如果該引數值設定為0，則一旦失敗就不會再嘗試重新連線

併傳送，直到下次redo資料再被歸檔時會重新嘗試，不過並不會歸檔到已經失敗的歸檔目的地，而是向替補的歸檔目的地傳送。

2、ALTERNATE 指定替補的歸檔目的地

alternate屬性定義一個替補的歸檔目的地，所謂替補就是一旦主歸檔目的地因各種原因無法使用，則臨時向alternate屬性中指定的路徑寫。

需要注意一點，reopen的屬性會比alternate屬性優先順序要高，如果你指定reopen屬性的值>0，則lgwr/arch會首先嚐試向主歸檔目的地寫入，直到達

到最大重試次數，如果仍然寫入失敗，才會向alternate屬性指定的路徑寫。

3、MAX_FAILURE 控制失敗嘗試次數

max_failure屬性指定一個最大失敗嘗試次數，大家應該能夠聯想到reopen，沒錯兩者通常是應該配合使用，reopen指定失敗後重新嘗試的時間週期

，max_failure則控制失敗嘗試的次數，如例：

LOG_ARCHIVE_DEST_1='LOCATION=E:\ora10g\oradata\jsspdg\ REOPEN=60 MAX_FAILURE=3'

 

管理歸檔中斷

如果primary資料庫中的歸檔日誌沒能成功傳送至standby資料庫，就會出現歸檔中斷。當然通常情況下你不需要擔心這一點，因為dg會自動檢測並嘗

試複製丟失的歸檔以解決中斷問題，透過什麼解決呢？FAL(Fetch Archive Log)。

FAL分server和client，前面建立步驟中講初始化引數時想必大家也注意到了。FAL client自動主動要求傳輸歸檔檔案，FAL server則響應FAL

client傳送的請求。多好的兩口子啊。

FAL機制會自動處理下列類似的歸檔中斷問題：

l 當建立物理或邏輯的standby資料庫，FAL機制會自動獲取primary資料庫熱備時產生的歸檔檔案。

l 當接收的歸檔檔案出現下列的問題時，FAL機會會自動獲取歸檔檔案解決：

Ø 當接收到的歸檔在應用之後被刪除時；

Ø 當接收到的歸檔所在磁碟損壞時；

l 當存在多個物理standby時，FAL機制會自動嘗試從其它standby伺服器獲取丟失的歸檔檔案。

讓大家瞭解這個東西不是為了讓你做什麼，而是希望你放心，oracle會管理好這些，如果它沒有管理好，你明白這個原理，你也能分析一下它為什麼

沒能管理好，透過什麼方式能夠促使它恢復有效管理的能力，當然你一定要自己動手，也可以，下面透過示例來說明手工處理歸檔中斷（注意，俺只

描述步驟，演示俺就不做了。因為三思現在用地最大保護模式，不會丟失歸檔地說，哇哈哈哈:)）

1、首先你要確認一下standby是否存在歸檔中斷

可以透過查詢v$archive_gap檢視來確定，如果有記錄就表示有中斷。

SQL> select *from v$archive_gap;

這一步的目的是為了取出對應的LOW_SEQUENCE#和HIGH_SEQUENCE#，如果有RAC的話，還需要注意一下THREAD#。

2、查詢sequence對應的歸檔檔案

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN 7 AND 10;

3、複製對應的歸檔檔案到standby

注意，如果是RAC的話，要找對機器喲:)

然後透過alter database register logfile命令將這些檔案重新註冊一下，例如：

SQL> ALTER DATABASE REGISTER LOGFILE 'e:\ora10g\jsspdg\xxxx.arc';

然後重啟redo應用即可。

對於邏輯standby的丟失歸檔處理稍微複雜一點點，因為邏輯standby沒有提供型別v$archive_gap;之類的檢視，因此我們需要自己想辦法來識別是否

存在丟失的情況，具體可以透過下列的語句：

SQL> select thread#,sequence#,file_name from dba_logstdby_log l

  2  where next_change# not in (

  3  select first_change# from dba_logstdby_log where l.thread# = thread#)

  4  order by thread#,sequence#;

找出丟失的歸檔檔案後，接著的處理方式與物理standby相同。