如何理解primary數據庫standby

163次閱讀

共計 6528 個字符，預計需要花費 17 分鐘才能閱讀完成。

這期內容當中丸趣 TV 小編將會給大家帶來有關如何理解 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 能夠降低并行讀取的次數，加快整個恢復時間。

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

正文完