1.關於Forced Logging模式
有一些DDL語句可以通過指定NOLOGGING子句的方式避免寫redo log(目的是提高速度，某些時候確實有效)，指定數據庫爲FORCE LOGGING模式後，數據庫將會記錄除臨時表空間或臨時回滾段外所有的操作而忽略類似NOLOGGING之類的指定參數。如果在執行force logging時有nologging之類的語句在執行，則force logging會等待直到這類語句全部執行。FORCE LOGGING是做爲固定參數保存在控制文件中，因此其不受重啓之類操作的影響(只執行一次即可)
打開force logging
SQL > alter database force logging;
關閉force logging
SQL > alter database no force logging;
查看force logging的狀態：
SQL > select FORCE_LOGGING from v$database;
2.關於主備庫的密碼
密碼文件位置$ORACLE_HOME/dbs/orapwSID，主備庫的密碼必須要一致，否則可能出現日誌無法傳輸故障，最好是使用scp傳過去較爲方便
3.關於listener.ora和tnsnames.ora
listener.ora爲數據庫的監聽配置文件，tnsnames.ora爲網絡服務名配置文件
修改listener.ora是需要重啓監聽程序，而tnsnames.ora是不需要重啓的，我們可以使用默認的listener.ora
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
)
)
ADR_BASE_LISTENER = /opt/oracle
以上是動態註冊，如果是靜態註冊的話，則是
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /opt/oracle/product/11.2.0/db_1)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = db1)
(ORACLE_HOME = /opt/oracle/product/11.2.0/db_1)
(SID_NAME = db1)
)
)
tnsnames.ora則只需要添加服務名
db1 =
(DEST_NAME
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = db1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = db1)
)
)
db2 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = db2)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = db2)
)
)
以上按照自己的實際情況進行修改
以上配置好了，就可以相互的tnsping db1或tnsping db2進行測試
4.參數文件說明
參數文件說明：
增加以下參數，如果在初始化參數已經有配置，則看需要做相應的修改。
1、與主庫角色相關的初始化參數說明：
DB_NAME
注意保持同一個Data Guard環境中所有數據庫DB_NAME相同
DB_UNIQUE_NAME
爲每一個數據庫指定一個唯一的名稱,以標示同一個dataguard環境中不同的數據庫。
LOG_ARCHIVE_CONFIG
該參數通過DG_CONFIG屬性羅列同一個Data Guard中所有DB_UNIQUE_NAME(含主庫db及備庫db)，以逗號分隔。
例如：LOG_ARCHIVE_CONFIG='DB_CONFIG=(db1,db22)'
LOG_ARCHIVE_DEST_n
歸檔文件的生成路徑。該參數非常重要,dataguard就是通過這裏的設置傳輸日誌的。
LOG_ARCHIVE_DEST_STATE_n
指定參數值爲ENABLE，標示對應的LOG_ARCHIVE_DEST_n參數是否有效。
REMOTE_LOGIN_PASSWORDFILE
推薦設置參數值爲EXCLUSIVE或者SHARED，注意保證相同Data Guard配置中所有db服務器sys密碼相同。如果不同日誌傳輸會失敗。數據庫默認是EXCLUSIVE,一般不用修改
。
LOG_ARCHIVE_FORMAT
指定歸檔文件格式。一般也不用修改，保持默認即可
2、以下參數爲備庫角色相關的參數，建議在主庫的初始化參數中也進行設置，這樣在主備庫角色相互轉換後不需要做修改dataguard也能正常運行。
FAL_SERVER
指定備庫到主數據庫的連接服務名，FAL_SERVER = orcl2日誌所在服務器。
FAL_CLIENT
指定主庫到備庫的連接服務名，FAL_CLIENT = orcl日誌接收客戶端。
STANDBY_FILE_MANAGEMENT
如果主庫的數據文件發生修改（如新建，重命名等）則按照本參數的設置在備庫中做相應修改。設爲AUTO表示自動管理。設爲MANUAL表示需要手工管理。
例如：STANDBY_FILE_MANAGEMENT=AUTO
下面開始修改主庫的初始化參數。
db_name參數已經設置，不用修改
SQL> alter system set db_unique_name =’db1’ scope=spfile;
SQL> alter system set log_archive_config='dg_config=(db1,db2)' scope=spfile;
---這裏的db1和db2爲db_unique_name
SQL> alter system set log_archive_dest_1='location=/opt/oracle/flash_recovery_area' scope=spfile;
--/opt/oracle/flash_recovery_area爲本地的歸檔目錄，需要手動創建該目錄，當然也可以指定別的路徑。
注意oracle賬號對該目錄又可讀寫的權限。
SQL> alter system set log_archive_dest_state_1=enable scope=spfile;
--這個通常不用修改，系統默認的就是enable。
SQL>alter system set log_archive_dest_2='service=db2 valid_for=(online_logfiles,primary_role) arch async NOAFFIRM db_unique_name=db2' scope=spfile;
-----這裏的service爲主庫連接到備庫的服務名，後面會在tnsnames.ora文件中配置
valid_for參數說明這個歸檔日誌目的地在本數據庫爲主庫的角色下才需要把online_logfile傳輸到備庫去。arch async NOAFFIRM說明的是同步的方式，同步的方式有三種:最大保護，最大性能，最大可用。
SQL> alter system set log_archive_dest_state_2=enable scope=spfile;
以上修改的是作爲主庫角色需要的參數，爲了方便以後主備庫切換，建議在主庫中也配置作爲備庫角色的相關參數。
SQL> alter system set fal_server=db2 scope=spfile;
SQL> alter system set fal_client=db scope=spfile;
SQL> alter system set standby_file_management=auto scope=spfile;
生成靜態參數文件，以備後面給備庫使用。
SQL> create pfile from spfile;
重新啓動主庫，使參數生效。
6.DataGuard啓動停止及維護：
DataGuard停止：先主後備
DataGuard啓動：先備後主
7.DataGuard日常監控視圖
a.主庫查看日誌歸檔路徑是否可用，如果遠程歸檔目錄不可用則error會顯示錯誤信息
SQL> select dest_name,status,error from v$archive_dest;
DEST_NAME STATUS ERROR
-------------------- -------------------- --------------------
LOG_ARCHIVE_DEST_1 VALID
LOG_ARCHIVE_DEST_2 VALID
LOG_ARCHIVE_DEST_3 INACTIVE
LOG_ARCHIVE_DEST_4 INACTIVE
LOG_ARCHIVE_DEST_5 INACTIVE
LOG_ARCHIVE_DEST_6 INACTIVE
LOG_ARCHIVE_DEST_7 INACTIVE
LOG_ARCHIVE_DEST_8 INACTIVE
LOG_ARCHIVE_DEST_9 INACTIVE
LOG_ARCHIVE_DEST_10 INACTIVE
10 rows selected.
如上記錄則代表備庫歸檔日誌目錄有效且正常
b.查詢數據庫的主備角色，以及當前DataGuard的運行模式，在主備查詢結果不同
主庫：
SQL> select database_role,LOG_MODE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;
DATABASE_ROLE LOG_MODE PROTECTION_MODE PROTECTION_LEVEL
---------------- ------------ -------------------- --------------------
PRIMARY ARCHIVELOG MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
備庫：
SQL> select database_role,LOG_MODE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;
DATABASE_ROLE LOG_MODE PROTECTION_MODE PROTECTION_LEVEL
---------------- ------------ -------------------- --------------------
PHYSICAL STANDBY ARCHIVELOG MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
c.獲取歸檔日誌的應用情況，主備庫結果不同。在主庫上對於每個歸檔文件會有2條記錄
SQL > select name,SEQUENCE#,APPLIED from v$archived_log order by sequence#;
備庫:
/opt/oracle/flash_recovery_area/1_11_904130046.dbf 11 YES
/opt/oracle/flash_recovery_area/1_12_904130046.dbf 12 YES
/opt/oracle/flash_recovery_area/1_13_904130046.dbf 13 YES
/opt/oracle/flash_recovery_area/1_14_904130046.dbf 14 YES
/opt/oracle/flash_recovery_area/1_15_904130046.dbf 15 YES
/opt/oracle/flash_recovery_area/1_16_904130046.dbf 16 YES
/opt/oracle/flash_recovery_area/1_17_904130046.dbf 17 YES
/opt/oracle/flash_recovery_area/1_18_904130046.dbf 18 YES
/opt/oracle/flash_recovery_area/1_19_904130046.dbf 19 YES
/opt/oracle/flash_recovery_area/1_20_904130046.dbf 20 YES
/opt/oracle/flash_recovery_area/1_21_904130046.dbf 21 YES
/opt/oracle/flash_recovery_area/1_22_904130046.dbf 22 YES
/opt/oracle/flash_recovery_area/1_23_904130046.dbf 23 YES
/opt/oracle/flash_recovery_area/1_24_904130046.dbf 24 IN-MEMORY
如果有發現日誌不連續，則需要對照主庫的歸檔日誌序列，判斷是否有丟失的日誌，如果有則需要手動註冊日誌並應用歸檔。
（方法：從主庫的歸檔目錄拷貝相應的歸檔
文件到備庫上註冊alter database register physical logfile '/opt/oracle/flash_recovery_area/歸檔文件名’;
然後手動應用日誌alter database recover automatic standby database;
在測試過程中發現oracle10G下把丟失的歸檔日誌文件考入指定目錄會自動註冊，不需手動註冊。）
d.查詢主備庫的進程信息
SQL> select process,status from v$managed_standby;
--查詢主備庫上的進程信息
主庫：
SQL>select process,status from v$managed_standby;
PROCESS STATUS
--------- ------------
ARCH CLOSING
ARCH CLOSING
ARCH CLOSING
ARCH CLOSING
LNS WRITING
備庫:
SQL> select process,status from v$managed_standby;
PROCESS STATUS
--------- ------------
ARCH CONNECTED
ARCH CONNECTED
ARCH CLOSING
ARCH CONNECTED
RFS IDLE
RFS IDLE
MRP0 APPLYING_LOG
注意以上2個紅色部分
f.查看dataguard的狀態信息
SQL > select message_num,message from v$dataguard_status;
g.檢查備庫是否有日誌缺失
SQL > select * from v$archive_gap;
6.主備庫的切換
switchover （計劃中的切換，不會丟失數據）
failover （當主庫出現故障的時候需要主備庫切換角色）
a.switchover的切換
主庫端：
select switchover_status from v$database;
如果是to standby表可以正常切換.
直接執行alter database commit to switchover to physical standby;
否則執行:alter database commit to switchover to physical standby with session shutdown;
shutdown immediate;
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;
備庫端：
select switchover_status from v$database;
如果是to_primary表可以正常切換.
執行: alter database commit to switchover to primary;
否則執行: alter database commit to switchover to primary with session shutdown;
shutdown immediate;
startup;
b.failover的切換
(1)判斷主數據庫確實出現嚴重的硬件故障或其他原因導致主數據庫無法啓動。
(2)在物理備用數據庫上檢查是否有archive redo log gaps
SQL>SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
(3)消除archive redo log gaps
從主數據庫上或其他備份的地方把沒有傳到物理備用數據庫的archive redo log傳到物理備用數據庫上，並註冊到物理備用數據庫的controlfile中。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'archive redo log文件名稱';
重複2,3步驟直到V$ARCHIVE_GAP視圖無記錄存在。
(4）在物理備用數據庫上發起failover操作
SQL > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;
(5)把物理備用數據庫轉化成主用角色
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
(6)把新的主用數據庫重新啓動
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
(7)對新的主用數據庫做全備份.
7.歸檔日誌的處理
a.物理備庫中已經應用的歸檔日誌需定期刪除.
rman> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';
刪除7天前的歸檔日誌文件。刪除之後最好做一個全備份。
b. 先手動刪除歸檔日誌文件，然後再RMAN裏執行下面2條命令以更新控制文件
crosscheck archivelog all;
delete expired archivelog all;
c. 取消對備庫傳送日誌
ALTER SYSTEM SET log_archive_dest_state_2=’DEFER’ ;
8.常見故障：
a.備庫重啓後，在主庫上歸檔出現ORA-03113錯誤
SQL> select dest_name,status,error from v$archive_dest;
DEST_NAME STATUS ERROR
------------------------------ --------
LOG_ARCHIVE_DEST_1 VALID
LOG_ARCHIVE_DEST_2 ERROR ORA-03113: end-of-file on communication channel
解決辦法：在主庫執行
SQL> alter system set log_archive_dest_state_2= enable;
這個命令式手動觸發主庫區嘗試連接備庫。
其實這種情況下，只要保證主備庫之間的網絡和配置是正確的。dataguard會自動恢復這個錯誤。這個週期默認是300秒，也可以在log_archive_dest_2的參數中添加reopen參數指定這個主備庫之間失敗後繼續嘗試的週期。
b.ORA-01031: insufficient privileges錯誤
SQL> select dest_name,status,error from v$archive_dest;
DEST_NAME STATUS ERROR
---------------------- -----------------------------------------------
LOG_ARCHIVE_DEST_1 VALID
LOG_ARCHIVE_DEST_2 ERROR ORA-01031: insufficient Privileges
解決辦法：統一主備庫的數據庫密碼文件，或者重建密碼文件，sys密碼設置成一樣。
然後在主庫執行
SQL> alter system set log_archive_dest_state_2= enable;
c.ORA-16191: Primary log shipping client not logged on standby
SQL> select dest_name,status,error from v$archive_dest;
DEST_NAME STATUS ERROR
------------------------------ -----------
LOG_ARCHIVE_DEST_1 VALID
LOG_ARCHIVE_DEST_2 ERROR ORA-16191: Primary log shipping client not logged on standby
解決辦法：統一主備庫的數據庫密碼文件，或者重建密碼文件，sys密碼設置成一樣。
然後在主庫執行
SQL> alter system set log_archive_dest_state_2= enable;
d.發現備庫一直無法應用日誌，MRP0進程顯示WAIT_FOR_GAP的問題
發現從主庫傳來的日誌無法應用
在備庫檢查,
SQL> select sequence#,applied from v$archived_log;
SEQUENCE# APP
———- —
930 NO
931 NO
932 NO
933 NO
934 NO
935 NO
936 NO
937 NO
938 NO
939 NO
940 NO
然後開始查看有沒有mrp
[oracle@HJITBACKUP bdump]$ ps -ef | grep mrp
oracle 31896 1 0 14:37 ? 00:00:00 ora_mrp0_flow
oracle 32001 31820 0 15:17 pts/1 00:00:00 grep mrp
看來有，接着查gap，發現備庫上有此進程，
SQL> select * from v$archive_gap ;
no rows selected
查詢視圖沒有發現，
在接着檢查V$MANAGED_STANDBY
SQL> select process,status from v$managed_standby;
PROCESS STATUS
——— ————
ARCH CONNECTED
ARCH CONNECTED
MRP0 WAIT_FOR_GAP
RFS IDLE
RFS IDLE
發現MRP0在等待GAP,進一步查看此視圖
SQL> select process,status,group#,thread#,sequence#,block#,blocks from v$managed_standby;
PROCESS STATUS GROUP# THREAD# SEQUENCE# BLOCK# BLOCKS
——— ———— ———- ———- ———- ———- ———-
ARCH CONNECTED N/A 0 0 0 0
ARCH CONNECTED N/A 0 0 0 0
MRP0 WAIT_FOR_GAP N/A 1 928 0 0
RFS IDLE N/A 0 0 0 0
RFS IDLE N/A 0 0 0 0
發現日誌928沒有應用，
原來是由於主庫刪除了928，導致備庫沒法應用，所以只能從備份中恢復，restore archivelog
至此問題處理完畢。
查詢備庫狀態
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
PROCESS STATUS
——— ————
ARCH CONNECTED
ARCH CONNECTED
MRP0 WAIT_FOR_LOG
RFS IDLE
RFS IDLE
所以當standby裝完後，在主庫切換日誌後，這裏狀態應該是
MRP0 WAIT_FOR_LOG纔是正常的狀態
9.注意事項
建議在主備庫的涉及到名稱地方都統一用小寫字母，避免在配置過程出現莫名的錯誤。
如果在主庫執行alter database clear unarchived logfile或alter database open resetlogs，則dataguard要重建。
在連續恢復模式下工作之前，需要保證之前所有的歸檔日誌己經應用到備用庫上。因爲在連續恢復模式的情況下，oracle不會應用之前的歸檔日誌，而只會應用後面陸續到來的歸檔日誌。
新建表、表空間、datafile都能通過日誌應用到備庫，但新建一個臨時表空間和rename datafile均不能應用到備庫上。
出現歸檔日誌gap時，需要找出相應的歸檔日誌，然後將這些歸檔日誌copy到備用節點的log_archive_dest目錄下面。然後ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE;
應當實時查看standby庫的alert文件，就能清晰明瞭地知道主備更新的情況。這也是排錯的重要方法。
相關視圖
V$ARCHIVE_DEST
V$ARCHIVE_DEST_STATUS
V$ARCHIVE_GAP
V$ARCHIVED_LOG
V$DATABASE
V$DATAFILE
V$DATAGUARD_STATUS
V$LOG
V$LOGFILE
V$LOG_HISTORY
V$STANDBY_LOG
文章大部分內容參考:http://blog.163.com/scott_guo/blog/static/18102608320121111113518691/