Oracle 11G R2 DataGuard日常維護及故障處理

Oracle 11G R2 DataGuard日常維護及故障處理

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

Oracle 11gR2 在VMWare虛擬機器中安裝步驟

Debian 下 安裝 Oracle 11g XE R2

Oracle Data Guard 重要配置參數

基於同一主機配置 Oracle 11g Data Guard

探索Oracle之11g DataGuard

Oracle Data Guard （RAC+DG) 歸檔刪除策略及指令碼

Oracle Data Guard 的角色轉換

Oracle Data Guard的日誌FAL gap問題

Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 處理方法