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 VALIDLOG_ARCHIVE_DEST_2 VALIDLOG_ARCHIVE_DEST_3 INACTIVELOG_ARCHIVE_DEST_4 INACTIVELOG_ARCHIVE_DEST_5 INACTIVELOG_ARCHIVE_DEST_6 INACTIVELOG_ARCHIVE_DEST_7 INACTIVELOG_ARCHIVE_DEST_8 INACTIVELOG_ARCHIVE_DEST_9 INACTIVELOG_ARCHIVE_DEST_10 INACTIVE10 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 CLOSINGARCH CLOSINGARCH CLOSINGARCH CLOSINGLNS WRITING
備庫:
SQL> select process,status from v$managed_standby;PROCESS STATUS--------- ------------ARCH CONNECTEDARCH CONNECTEDARCH CLOSINGARCH CONNECTEDRFS IDLERFS IDLEMRP0 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 gapsSQL>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 VALIDLOG_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 VALIDLOG_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 standbySQL> select dest_name,status,error from v$archive_dest;DEST_NAME STATUS ERROR------------------------------ -----------LOG_ARCHIVE_DEST_1 VALIDLOG_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 mrporacle 31896 1 0 14:37 ? 00:00:00 ora_mrp0_floworacle 32001 31820 0 15:17 pts/1 00:00:00 grep mrp看來有，接著查gap，發現備庫上有此進程，SQL> select * from v$archive_gap ;no rows selected查詢視圖沒有發現，在接著檢查V$MANAGED_STANDBYSQL> select process,status from v$managed_standby;PROCESS STATUS——— ————ARCH CONNECTEDARCH CONNECTEDMRP0 WAIT_FOR_GAPRFS IDLERFS 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 0ARCH CONNECTED N/A 0 0 0 0MRP0 WAIT_FOR_GAP N/A 1 928 0 0RFS IDLE N/A 0 0 0 0RFS 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 CONNECTEDARCH CONNECTEDMRP0 WAIT_FOR_LOGRFS IDLERFS 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_DESTV$ARCHIVE_DEST_STATUSV$ARCHIVE_GAPV$ARCHIVED_LOGV$DATABASEV$DATAFILEV$DATAGUARD_STATUSV$LOGV$LOGFILEV$LOG_HISTORYV$STANDBY_LOG
