如何理解primary數據庫standby

這期內容當中小編將會給大家帶來有關如何理解primary數據庫standby，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

一、Read only/write模式打開物理standby
以read only 或read write模式打開物理standby,可以轉移一些查詢，備份之類的操作到standby數據庫，以分擔一些primary的壓力。

1). standby數據庫處于shutdown狀態

　　直接startup即可

2). standby數據庫處于redo應用狀態

　　首先取消redo應用：

SQL> alter database recover managed standby database cancel; SQL> alter database open

3). 從open狀態再切換回redo應用，并不需要shutdown,只需啟用redo應用即可

SQL> alter database recover managed standby database disconnect from session;

由于只讀打開時就不能應用，雖然我們能夠查詢，但是查詢的結果確是與primary 不同步的，這點大大降低了物理standby 做報表服務分擔主庫壓力的可能性，對于這點呢，我們有兩個解決方案:

a.改用邏輯standby b. 使用oracle 11G

二、管理影響standby的primary數據庫事件

某些情況下，primary數據庫的某些改動會自動通過redo數據傳播到standby數據庫，因此不需要在standby數據庫做額外的操作，而某些情況，則需要手工調整。

下列事件會由redo傳輸服務及redo應用自動處理，不需要dba的干預：

• ALTER DATABASE ENABLE|DISABLE THREAD語句

• 修改表空間狀態(例如read-write到read-only, online到offline)

• 創建修改刪除表空間或數據文件（前提條件：參數STANDBY_FILE_MANAGEMENT設置為AUTO）

以下事情則需要dba手工干預：

1. 添加、修改、刪除數據文件或表空間

　　Standby_file_management設置為manual

　　不過需要注意一點，如果數據文件是從其它數據庫復制而來，則不管Standby_file_management參數值如何設置，都必須同時復制到standby數據庫，并注意要修改standby數據庫的控件文件。

2. 重命名數據文件

　　如果primary數據庫重命名了一個或多個數據文件，該項不修改并不會自動傳播到standby數據庫，不管standby_file_management它是auto還是manual。

 A. SQL> alter tablespace webtbs offline; -- primary數據庫操作

 B. 手工數據文件改名(操作系統) -- primary數據庫操作

 C. SQL> alter tablespace webtbs rename datafile

　　　　　　'webtbs01.dbf' to 'tbsweb01.dbf';

　　SQL> alter tablespace webtbs online;

 D. 暫停redo應用，并shutdown --standby數據庫操作

　　SQL> alter database recover managed standby database cancel;

　　SQL> shutdown immediate

 E. 手工將數據文件改名 -- standby數據庫操作

 F. 重啟standby,修改數據文件路徑(數據字典) --standby數據庫操作

　　SQL> startup mount

　　SQL> alter database rename file

　　　　　　'webtbs01.dbf' to 'tbsweb01.dbf';

 G. 重新啟動redo應用

　　SQL> alter database recover managed standby database disconnect from session;

 H. 切換日志 -- primary數據庫操作

　　SQL> alter system switch logfile;

3. 添加或刪除online redo logs

三、對open resetlogs的primary數據庫standby的恢復

四、 監控primary/standby數據庫

1. 與恢復進度相關的v$視圖應用

A). 查看進程的活動狀況 -- v$managed_standby

B). 確認redo應用進度 -- v$archive_dest_status

C). 檢查歸檔文件路徑及創建信息 -- v$archived_log

D). 查詢歸檔歷史 -- v$log_history
E). 查詢備庫上gap問題  --v$archived_gap，顯示有關備用數據庫上存檔空缺的信息。 這個視圖可以用來找出當前存檔的差距，阻礙目前恢復化身的恢復

1.1、查看進程的活動狀態

SQL> select process,status,thread#,sequence# from v$managed_standby order by 3,1;

PROCESS   STATUS          THREAD#  SEQUENCE#
--------- ------------ ---------- ----------
RFS       IDLE                  0          0
RFS       IDLE                  0          0
RFS       IDLE                  0          0
RFS       IDLE                  0          0
ARCH      CLOSING               1      13411
ARCH      CLOSING               1      13412
RFS       IDLE                  1      13413
ARCH      CLOSING               2       8849
ARCH      CLOSING               2       4101
MRP0      APPLYING_LOG          2       8850
RFS       IDLE                  2       8850

這里，process就是進程名，包括ARCH, RFS, MRP0等，對應英文解釋如下：
Type of the process whose information is being reported:
    RFS - Remote file server----接收進程
    MRP0 - Detached recovery server process----恢復進程
    MR(fg) - Foreground recovery session
    ARCH - Archiver process
    FGRD
    LGWR
    RFS(FAL)
    RFS(NEXP)
    LNS - Network server process
    
CLIENT_PROCESS 對應 Primary 數據庫中的進程如 ARCH\LGWR等
SEQUENCE#：歸檔序號
STATUS 當前進程狀態

重要的是status字段，表示當前的進程狀態，中文解釋如下：
ALLOCATED: 正在準備但還未連接主庫
ATTACHED: 正在連接到主庫
CONNECTED:已經連接到主庫
IDLE:空閑
ERROR：失敗的進程，需要關注
RECEIVING:歸檔日志接收中
OPENING:歸檔日志處理中
CLOSING:歸檔日志處理完，正在收尾中
WRITING: 進程在將REDO數據寫向歸檔文件中
WAIT_FOR_LOG:等待新的REDO歸檔數據中
WAIT_FOR_GAP:歸檔有中斷，正在等待中斷的那部分REDO數據.
APPLYING_LOG:正在應用REDO歸檔數據到備庫

1.2 查看REDO應用進度
SELECT DEST_NAME,ARCHIVED_THREAD#,ARCHIVED_SEQ#,APPLIED_THREAD#,APPLIED_SEQ#,DB_UNIQUE_NAME,STATUS FROM V$ARCHIVE_DEST_STATUS
 --WHERE STATUS='VALID'

DEST_NAME                 ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# DB_UNIQUE_NAME                 STATUS
------------------------- ---------------- ------------- --------------- ------------ ------------------------------ ---------
LOG_ARCHIVE_DEST_1                       0             0               0            0 cuuo                           VALID
LOG_ARCHIVE_DEST_2                       0             0               0            0 cuug                           VALID
LOG_ARCHIVE_DEST_3                       0             0               0            0 NONE                           INACTIVE
LOG_ARCHIVE_DEST_4                       0             0               0            0 NONE                           INACTIVE
LOG_ARCHIVE_DEST_5                       0             0               0            0 NONE                           INACTIVE
LOG_ARCHIVE_DEST_6                       0             0               0            0 NONE                           INACTIVE
LOG_ARCHIVE_DEST_7                       0             0               0            0 NONE                           INACTIVE
LOG_ARCHIVE_DEST_8                       0             0               0            0 NONE                           INACTIVE
LOG_ARCHIVE_DEST_9                       0             0               0            0 NONE                           INACTIVE
LOG_ARCHIVE_DEST_10                      0             0               0            0 NONE                           INACTIVE
STANDBY_ARCHIVE_DEST                     0             0               0            0 NONE                           VALID

11 rows selected.

1.3 查看歸檔文件的路徑及創建信息
15:24:30 > SELECT NAME,CREATOR,THREAD#,SEQUENCE#,APPLIED,ARCHIVED,COMPLETION_TIME FROM V$ARCHIVED_LOG;

NAME                                                  CREATOR    THREAD#  SEQUENCE# APP ARC COMPLETIO
---------------------------------------------------- ------- ---------- ---------- --- --- ---------
/u01/app/oracle/oradata/cuuo/arch2_91_787689201.dbf   ARCH         1         91     YES YES 04-JUL-12                       
/u01/app/oracle/oradata/cuuo/arch2_92_787689201.dbf   LGWR         1         92     YES YES 04-JUL-12                    
/u01/app/oracle/oradata/cuuo/arch2_93_787689201.dbf   LGWR         1         93     YES YES 04-JUL-12      
                                   
/u01/app/oracle/oradata/cuuo/arch2_94_787689201.dbf   LGWR         1         94     YES YES 04-JUL-12

1.4 查看歸檔歷史
SELECT FIRST_TIME,FIRST_CHANGE#,NEXT_CHANGE#,SEQUENCE# FROM V$LOG_HISTORY;

1.5 查看物理STANDBY數據庫未接收的日志文件
--從primary 數據庫獲取

select local.thread#,local.sequence# from
   (select thread#,sequence# from v$archived_log where dest_id=1) local
    where local.sequence# not in
 (select sequence# from v$archived_log where dest_id=2 and thread# = local.thread#);


2 監控日志應用服務
2.1 查詢當前數據的基本信息（V$DATABASE) 數據庫角色、保護模式、保護級別
SELECT DATABASE_ROLE,DB_UNIQUE_NAME,OPEN_MODE,PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUS FROM V$DATABASE;

查詢failover后快速啟動的信息：
SELECT FS_FAILOVER_STATUS,FS_FAILOVER_CURRENT_TARGET,FS_FAILOVER_THRESHOLD,FS_FAILOVER_OBSERVER_PRESENT FROM V$DATABASE;

2.2 查詢REDO應用和REDO傳輸服務的活動狀態
SELECT PROCESS,STATUS,THREAD#,SEQUENCE#,BLOCK#,BLOCKS FROM V$MANAGED_STANDBY;

2.3 查看REDO應用模式（物理STANDBY數據庫）
SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;
RECOVERY_MODE
-----------------------
MANAGED

--如果開啟了實時應用，此處顯示的狀態應該為 MANAGED REAL TIME APPLY

2.4 DATAGUARD 事件監控
2.4.1 ALERT LOG
2.4.2 查詢 V$DATAGUARD_STATUS 視圖
16:03:17 > SELECT SEVERITY,DEST_ID,MESSAGE_NUM,ERROR_CODE,CALLOUT,MESSAGE FROM V$DATAGUARD_STATUS;

SEVERITY         DEST_ID MESSAGE_NUM ERROR_CODE CAL MESSAGE
------------- ---------- ----------- ---------- --- ----------------------------------------
Informational          0           1          0 NO  ARC0: Archival started
Informational          0           2          0 NO  ARC1: Archival started
Informational          0           3          0 NO  ARC0: Becoming the 'no FAL' ARCH
Informational          0           4          0 NO  ARC0: Becoming the 'no SRL' ARCH
Informational          0           5          0 NO  ARC1: Becoming the heartbeat ARCH
Control                0           6          0 YES Media Recovery Start: Managed Standby Recovery
Informational          0           7          0 NO  Managed Standby Recovery not using Real Time Apply

3. 與log應用相關的v$視圖應用

A). 查詢當前數據的基本信息 -- v$database

B). 檢查應用模式 --v$archive_dest_status

C). Data guard事件 -- v$dataguard_status

五、調整物理standby log應用頻率

調整應用頻率說白了就是調整IO讀取能力

5.1設置RECOVER并行度
在介質恢復或REDO應用期間都需要讀取redo log ，默認都是串行恢復，
可以在RECOVER的時候加上PARALLEL子句來指定并行度。
RECOVER STANDBY DATABASE PARALLEL 2;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 2 DISCONNECT FROM SESSION;

5.2 加快REDO 應用頻率
修改 DB_BLOCK_CHECKING=FALSE 能夠提高2倍的應用效率，設置為FALSE只適合物理STANDBY數據庫，不適合primary數據庫。

5.5 設置 parallel_execution_message_size
如果打開了并行恢復，適當加大parallel_execution_message_size大小也可以提升性能，不過需要注意的事
增加該參數會占用更多的內存。

5.5 優化磁盤I/O
恢復期間最大的性能瓶頸是I/O讀寫，某些情況下將 DISK_ASYNCH_IO設置為TRUE 即使用本地異步I/O能夠降低并行讀取的次數，加快整個恢復時間。

上述就是小編為大家分享的如何理解primary數據庫standby了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。