DataGuard引數配置詳解

DB_NAME 
只需注意DataGuard的主備各節點instance使用相同的db_name即可。推薦與service_name一致。

Primary Site	Standby Site
*.DB_NAME='DB'	*.DB_NAME='DB’

DB_UNIQUE_NAME 
Primary與Standby端資料庫的唯一名字，設定後不可再更改。
注意:
如果主備db_unique_name不一樣，需要與LOG_ARCHIVE_CONFIG配合使用
db_unique_name並未規定需要與資料庫service_name一致，可以自定義任意名稱。

Primary Site	Standby Site
*.db_unique_name='Primary’	*.db_unique_name='Standb

LOG_ARCHIVE_CONFIG 
列出主備庫上的DB_UNIQUE_NAME 引數。預設情況下，定義該引數能確保主備庫資料庫能夠互相識別對方
Primary與Standby端的db_unique_name不一致時

Primary Site	Standby Site
*.db_unique_name=Primary	*.db_unique_name=Standby
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(Primary,Standby)'	*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(Primary,Standby)'

如在主備庫db_unique_name不一致的情況下未配置 LOG_ARCHIVE_CONFIG則會出現如下報錯 
ORA-16057: DGID from server not in Data Guard configuration
原因:主庫沒有設定引數log_archive_config
解決方法*.log_archive_config='dg_config=( Primary , Standby )'

alter system set log_archive_config='dg_config=( Primary , Standby )' scope=both;
Primary與Standby端的db_unique_name一致時

Primary Site	Standby Site
*.db_unique_name=test	*.db_unique_name=test
*.LOG_ARCHIVE_CONFIG=''	*.LOG_ARCHIVE_CONFIG='

LOG_ARCHIVE_DEST_1 
本地歸檔路徑。Primary與Standby需要定義各自的online redo log的歸檔地址，以系統實際的存放路徑為準。格式如下：
Primary Site: 
*.LOG_ARCHIVE_DEST_1='LOCATION=/arch/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) '
Standby Site:
*.LOG_ARCHIVE_DEST_1='LOCATION=/stdby/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) '
注意：  
在LOG_ARCHIVE_DEST_n設定DB_UNIQUE_NAME表示該引數在 DB_UNIQUE_NAME指定的資料庫上生效 ，設定為本地的db_unique_name。以priamry端為例，格式如下：
*.LOG_ARCHIVE_DEST_1='LOCATION=/archivelog/ VALID_FOR=(ALL_LOGFILES,
ALL_ROLES) DB_UNIQUE_NAME=Primary' 
這樣配置的意義為： 在資料庫 Primary 上log_archive_dest_1對主備庫上的聯機日誌都有效，這裡的 db_unique_name可以省略　　　　　　　　　　　　　　　　　　 　
LOG_ARCHIVE_DEST_2 
該引數僅當資料庫角色為primary時生效，指定primary歸檔redo log到該引數定義的standby database上。
log_archive_dest_2可以說是dataguard上最重要的引數之一，它定義了redo log的傳輸方式(sync or async)以及傳輸目標(即standby apply node)，直接決定了dataguard的資料保護級別。
格式如下：
Primary Site: 
*.LOG_ARCHIVE_DEST_2='SERVICE=DR2 lgwr async  VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) '
Standby Site: (switch over後生效) 
*.LOG_ARCHIVE_DEST_2='SERVICE=DR1 lgwr async  VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) ' 
注意：  
LOG_ARCHIVE_DEST_2引數裡定義的service值，比如DR1，是tnsnames.ora檔案裡定義的Oracle Net名稱。
有時會在LOG_ARCHIVE_DEST_2定義DB_UNIQUE_NAME的值，當前節點設定的均為另一端資料庫的db_unique_name。以primary端為例，格式如下：
*.LOG_ARCHIVE_DEST_2='SERVICE=DR1 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=Standby' 　
這個引數的意義為： 在資料庫DR1上log_archive_dest_2對主庫上的聯機日誌都有效 　　　　　 　
關於valid_for引數，有如下解釋：
The redo_log_type keyword identifies the destination as valid for archiving to one of the following:
ONLINE_LOGFILE:This destination is valid only when archiving online redo log files.
STANDBY_LOGFILE:This destination is valid only when archiving standby redo log files.
ALL_LOGFILES:This destination is valid when archiving either online redo log files or standby redo log files.
The database_role keyword identifies the role in which this destination is valid for archiving:
PRIMARY_ROLE:This destination is valid only when the database is running in the primary role.
STANDBY_ROLE:This destination is valid only when the database is running in the standby role.
ALL_ROLES:This destination is valid when the database is running in either the primary or the standby role. 　　　　　　　　　　　　 　
LOG_ARCHIVE_DEST_3 
該引數僅當資料庫角色為standby時生效，定義primary database的日誌寫到standby database的standby redo log中。
Primary Site: 
*.LOG_ARCHIVE_DEST_3='LOCATION=/archivelog/standbylog/  VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) '
Standby Site: 
*.LOG_ARCHIVE_DEST_3='LOCATION=/arch/arch3/  VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE)'
注意：
LOCATION定義的路徑以本節點能讀寫的實際路徑為準。
LOG_ARCHIVE_DEST_STATE_n 
設定為ENABLE，啟用log_archive_dest_n定義的屬性。
FAL_SERVER and FAL_CLIENT 
當Primary Database的某些日誌沒有成功傳送到Standby Database， 這時候發生餓了歸檔裂縫（Archive Gap）。
FAL是Fetch Archive Log的簡寫，它是dataguard主備之間GAP的處理機制。 
當Primary Database的某些日誌沒有成功傳送到Standby Database， 這時候發生餓了歸檔裂縫（Archive Gap）。 
Primary上不會有GAP，所以fal_server和fal_client也是隻在standby上生效的引數，當然為了switch over的需要同樣會在primary端進行預設定。 
缺失的這些日誌就是裂縫（Gap）。 Data Guard能夠自動檢測，解決歸檔裂縫，不需要DBA的介入。這需要配置FAL_CLIENT， FAL_SERVER 這兩個引數（FAL: Fetch Archive Log）。
從FAL 這個名字可以看出，這個過程是Standby Database主動發起的“取”日誌的過程，Standby Database 就是FAL_CLIENT. 它是從FAL_SERVER中取這些Gap， 10g中，這個FAL_SERVER可以是Primary Database， 也可以是其他的Standby Database。
如：FAL_SERVER='PR1,ST1,ST2';
FAL_CLIENT和FAL_SERVER兩個引數都是Oracle Net Name。 FAL_CLIENT 透過網路向FAL_SERVER傳送請求，FAL_SERVER透過網路向FAL_CLIENT傳送缺失的日誌。 但是這兩個連線不一定是一個連線。 因此FAL_CLIENT向FAL_SERVER傳送請求時，會攜帶FAL_CLIENT引數值，用來告訴FAL_SERVER應該向哪裡傳送缺少的日誌。 這個引數值也是一個Oracle Net Name，這個Name是在FAL_SERVER上定義的，用來指向FAL_CLIENT. 
FAL引數定義的資料庫名同樣取自本地tnsnames.ora裡配置的Oracle Net Service Name.

Primary Site	Standby Site
*.fal_server='DR2’	*.fal_server=' DR1 ’
*.fal_client='DR1'	*.fal_client=' DR2'

其中DR1、DR2分別為主備庫的網路服務名 
DB_FILE_NAME_CONVERT 
primary與standby上diskgroup的名稱或是資料檔案的存放路徑不一致的時候，需要定義該引數進行轉換，否則standby apply後無法建立與primary一致的資料檔案並報錯。
db_file_name_convert 主資料庫和備用資料庫的資料檔案轉換目錄對映（如果兩資料庫的目錄結構不一樣），如果有多個對映，逐一指明對映關係。
格式：
*.db_file_name_convert=主資料庫資料檔案目錄，備用資料庫資料檔案目錄
例如：
Primary Site: 
*.db_file_name_convert='+DATAGRP/db/datafile/','+DG1/db/datafile/'
或者*.db_file_name_convert='/u01/app/oradata/standby','/u01/app/oradata/primary'
Standby Site: 
*.db_file_name_convert='+DG1/db/datafile/','+DATAGRP/db/datafile/' 

或者*.db_file_name_convert='/u01/app/oradata/ primary ','/u01/app/oradata/ standby '        
其中+DG1/db/datafile/是primary dastabase上存放datafile的路徑，+DATAGRP/db/datafile/是standby上存放datafile的路徑
多對多對映設定 
*.db_file_name_convert='/opt/oracle/oraInventory/oradata/oracle',

'/opt/oracle/oraInventory/oradata/standby','/home/ldai/testdb',
'/home/ldai/testdb/standby' 
注意: primary上的該引數僅在主備switch over後生效,格式應保持一致，比如"*.db_file_name_convert='+DG1/db/datafile','+DATAGRP/db/datafile/' ”，路徑少了一個"/”，將導致standby apply失敗。這個引數僅對standby資料庫有效
primary上執行create tablespace等add datafile操作時，無須自定義datafile的全路徑名稱，由資料庫自動建立datafile即可。
LOG_FILE_NAME_CONVERT 
同DB_FILE_NAME_CONVERT類似，定義主備log檔案的存放路徑轉換。 
STANDBY_FILE_MANAGEMENT 
初始化引數STANDBY_FILE_MANAGEMENT作用於standby資料庫 ，用來控制是否自動將Primary資料庫增加表空間或資料檔案的改動，傳播到物理Standby資料庫。該引數有兩個值：
AUTO：如果該引數值設定為AUTO，則Primary資料庫執行的表空間建立操作也會被傳播到物理Standby資料庫上執行。
MANUAL：如果設定為MANUAL或未設定任何值（預設值是MANUAL），需要手工複製新建立的資料檔案到物理Standby伺服器。
注意：STANDBY_FILE_MANAGEMENT引數特指Primary資料庫端的表空間或資料檔案建立，如果資料檔案是從其他資料庫複製而來（比如透過TTS傳輸表空間），則不管STANDBY_FILE_MANAGEMENT引數值如何設定，都必須同時手工複製到Standby資料庫，並重建物理Standby資料庫的控制檔案。
在Primary資料庫端刪除表空間時，會影響到物理Standby端資料庫的資料檔案和表空間，初始化引數STANDBY_FILE_MANAGEMENT的屬性值設定決定了該事件是否需要DBA介入。
當STANDBY_FILE_MANAGEMENT設定為AUTO。
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;  
System altered. 
在Primary資料庫端執行刪除表空間的操作： 
SQL> DROP TABLESPACE TEST INCLUDING CONTENTS AND DATAFILES;  
Tablespace dropped. 
INCLUDING DATAFILES子句，在刪除表空間時Oracle也將自動刪除對應的物理檔案。
將初始化引數STANDBY_FILE_MANAGMENT設定為AUTO，對於表空間和資料檔案的操作無須DBA手工干預，物理Standby能很好地進行處理。
當STANDBY_FILE_MANAGEMENT引數設定為MANUAL時，即使DBA在Primary資料庫端執行刪除操作時加上了INCLUDING DATAFILES子句，Standby資料庫仍然只會將表空間和資料檔案從資料字典中刪除，表空間涉及的物理檔案仍需要手工刪除。
對於檔案系統，我們可以將初始化引數STANDBY_FILE_MANAGMENT設定為AUTO，但是對於裸裝置，只能將該引數設定為MANUAL。
在Primary資料庫端執行資料檔案重新命名操作： 
如果Primary資料庫重新命名了一個或多個資料檔案，該項修改並不會自動傳播到Standby資料庫。 就算設定了初始化引數STANDBY_FILE_MANAGEMENT等於AUTO也不行，要讓Standby的資料檔案與Primary保持一致，只能手工操作。
1、alter tablespace/datafile offline;
2、使用作業系統命令來複製
3、alter databaser rename datafile '....' to '...' 
4、alter tablespace/datafile online;
5、確認STANDBY DB中所有歸檔已經apply
6、alter database recover managed standby database cancel停止redo apply 
7、複製並重新命名資料檔案 
8、alter database rename file '...' to '....';
9、alter databas recover managed standby database disconnect from session. 
新增或刪除Redologs檔案 
資料庫調優時極有可能會涉及重置日誌檔案大小或增加刪除日誌組等操作，如果STANDBY_FILE_MANAGEMENT引數值設定為AUTO的話，這種操作也會被傳播到物理Standby資料庫。不過在一般情況下，你可以不管STANDBY_FILE_MANAGEMENT引數的設定，因為無論Primary端對日誌組或日誌檔案的操作是否傳播到物理Standby資料庫，也不會影響到物理Standby資料庫的執行，不過如果你不注意其中的關係，造成的影響可能會很深遠。
通常建議當你在Primary資料庫增加或刪除Online Redologs時，一定記得手工同步相關物理Standby資料庫中相關的設定，同時也要考慮好Standby Redologs與Online Redologs之間的關係，即保證Standby Redologs比Online Redologs要至少多一組。
注意的就是在Standby資料庫端操作前務必將STANDBY_FILE_MANAGEMENT設定為MANUAL，如果物理Standby資料庫的日誌檔案與Primary資料庫路徑不同的話，應該透過初始化引數LOG_FILE_NAME_CONVERT的設定，讓其自動進行轉換。
Standby redo log組數公式>=(每個instance日誌組個數+1)*instance個數，例如
rac 2臺機器 每臺3組 則 standy 需8組，並且建立時要為每個例項建4組。一般來說，邏輯備庫需要更多的redo組數，這是由於邏輯備庫有自身的redo日誌，而這些redo日誌優先歸檔，故同等條件下邏輯備庫的歸檔速度比物理備庫的慢。
跨OPEN RESETLOGS的應用 
在某些情況下，Primary資料庫以RESETLOGS方式開啟之後，也不會影響Data Guard的配置，Standby資料庫無須人工參與，自動應用OPEN RESETLOGS的操作，繼續接收並應用Primary資料庫OPEN RESETLOGS之後產生的日誌。
當然這是有條件的，並不是所有情況下都能這麼智慧。我們知道執行ALTER DATABASE OPEN RESETLOGS語句之後，資料庫的INCARNATION被重置，也就是此時其Standby資料庫的SEQUENCE序號也會從頭開始設定。當然物理Standby資料庫並不關注這一點，它只是忠實地緊跟Primary資料庫的腳步，一步一步地執行Primary資料庫曾經執行過的操作，因此當其接收到新的REDO資料時，就會自動應用這部分REDO資料。
圖中顯示了Primary資料庫RESETLOGS操作對Standby的影響

Standby 資料庫狀態	Standby 資料庫操作	解決方案
尚未應用RESETLOGS 之前的 REDO資料	自動應用REDO 資料	無須手工介入
應用了RESETLOGS 之後的 REDO 資料，不過 Standby 資料庫啟用了 FRA	可以回到應用RESETLOGS 之前的狀態，不過需要 DBA 手工介入	手工FLASHBACK DATABASE 到應用 RESETLOGS 日誌之前的狀態 重啟REDO 應用，以重新接收新的REDO 資料
應用了RESETLOGS 之後的 REDO 資料，而且沒有配置 FRA	無法進行應用處理	重建物理Standby 是唯一的選擇

 

正常情況下這個邏輯沒有問題，不過遇到Primary執行過OPEN RESETLOGS之後，又透過備份恢復到OPEN RESETLOGS之前的狀態，視物理Standby的具體配置（配置方式決定了物理Standby是否有可能回到OPEN RESETLOGS之前的狀態）的不同，情況可能會複雜很多。

參考至：http://java-beginner-liyun.iteye.com/blog/monthblog/2010-07?show_full=true
              
               http://www.cnblogs.com/sopost/archive/2010/01/30/2190114.html
               http://epub.itpub.net/6/5.htm

                

---------------------------------------------------------------------------------------------------&gt>

轉載於:http://czmmiao.iteye.com/blog/1311070