Oracle 18c&19c physical dg切換總結

這篇文章總結Oracle 18c/19c Physical Standby DG的主備切換的操作流程,主要參考官方文件18c & 19c Physical Standby Switchover Best Practices using SQL*Plus (Doc ID 2485237.1)^[1]. 由於參考官方的最佳實踐，所以有些步驟/過程略顯繁瑣。其實正常情況下，這裡面的很多步驟都可以略過。但是不妨我們從更嚴謹的態度和細節方面瞭解更多的技術細節。

前提條件(Prerequisites)檢查

DG的設定/配置驗證

• Primary & Standby 應使用相同版本的RDBMS
• 檢查/驗證主備庫的告警日誌，並確保沒有錯誤或告警

$ grep "ORA-" alert_<ORACLE_SID>.log 
$ tail -600 alert_<ORACLE_SID>.log  | grep "ORA-"

• 在主庫和備用資料庫執行下面SQL檢查驗證沒有壞塊

select * from v$database_block_corruption; 
select * from v$nonlogged_block;

注意：沒有記錄表示正常，如果有相關記錄返回，則表示資料庫存在壞塊。

• 確保主庫和備庫的配置正常/正確，並且重做日誌傳輸(redo transport)和重做日誌應用(redo apply)中沒有錯誤
• 驗證物理備用資料庫是否正常執行,檢查DG的主備庫情況

獲取主備庫的資訊以及保護模式(主備庫執行)

set linesize 720
col name for a10
col open_mode for a20
col database_role for a16
col switchover_status for a12 heading "SWITCHOVER |STATUS"
col force_logging for a8
col dataguard_broker for a8 heading "DATAGUARD|BROKER"
col guard_status for a8
select name
      ,open_mode
      ,database_role
      ,protection_mode
      ,protection_level
      ,switchover_status 
      ,force_logging
      ,dataguard_broker
      ,guard_status
from v$database;

檢查主庫下SWITCHOVER_STATUS欄位，如果值為"SESSION ACTIVE"或者"TO STANDBY", 則主資料庫角色可以切換為備庫角色。關於SWITCHOVER_STATUS欄位的各個取值如下所示：

SWITCHOVER_STATUS取值	意義
NOT ALLOWED	在主資料庫上，此狀態表示沒有有效且已啟用的備用資料庫。如果配有DG關係，則表示當前資料庫不允許進行Switchover操作。這可能是因為多種原因，如資料庫狀態不正確、主備庫之間存在延遲或不一致、存在活躍的會話等。具體原因需要結合資料庫狀態和日誌資訊等來判斷。在備用資料庫上，此狀態表示尚未從主資料庫收到切換請求
SESSIONS ACTIVE	表示當前資料庫有活躍的會話或事務，這些會話或事務需要被斷開或提交後，才能進行Switchover操作。 資料庫具有活動會話。在物理備用資料庫上，必須指定 WITH SESSION SHUTDOWN 這樣的SQL子句才能在此狀態下執行角色轉換。在邏輯備用資料庫上，可以在此狀態下執行角色轉換，但在提交所有當前事務之前，角色轉換不會完成。
SWITCHOVER PENDING	在物理備用資料庫上，此狀態表示已從主資料庫收到切換請求並正在處理。在此瞬態狀態下，物理備用資料庫無法切換到主要角色。
SWITCHOVER LATENT	在物理備用資料庫上，此狀態表示切換請求處於掛起狀態，但原始主資料庫已切換回主要角色。
TO PRIMARY	表示當前資料庫可以切換為主資料庫（Primary Database）。這通常是在執行Switchover操作後，原備用資料庫（Standby Database）切換為主資料庫（Primary Database）時顯示的狀態。
TO STANDBY	表示當前資料庫可以切換為備用資料庫（Standby Database）。這通常意味著資料庫處於可以安全地進行Switchover操作的狀態，且沒有活躍的會話或事務阻止切換。
TO LOGICAL STANDBY	資料庫已從邏輯備用資料庫接收到資料字典，並準備切換到邏輯備用角色。
RECOVERY NEEDED	在物理備用資料庫上，此狀態指示必須先應用額外的重做，然後資料庫才能切換到主要角色
PREPARING SWITCHOVER	在主資料庫上，此狀態表示正在從邏輯備用資料庫接收資料字典，以準備切換到邏輯備用角色。在邏輯備用資料庫上，此狀態表示資料字典已傳送到主資料庫和其他備用資料庫。
PREPARING DICTIONARY	在邏輯備用資料庫上，此狀態表示正在將資料字典傳送到主資料庫和其他備用資料庫，以準備切換到主要角色。
FAILED DESTINATION	在主資料庫上，此狀態表示一個或多個備用目標處於錯誤狀態。這個值可能不是SWITCHOVER_STATUS的直接狀態值，但在執行Switchover過程中，如果遇到配置錯誤或網路問題導致目標資料庫無法接收歸檔日誌，可能會間接導致Switchover失敗，並顯示為類似“Failed Destination”的錯誤資訊。這種情況需要DBA檢查相關配置和網路連線。
RESOLVABLE GAP	在主資料庫上，此狀態表示一個或多個備用資料庫具有redo gap，可以透過從主資料庫或另一個備用資料庫獲取丟失的重做來自動解決該差距。 在某些情況下，如歸檔日誌傳輸過程中出現短暫的中斷導致日誌間隙（Gap），但這些間隙可以透過後續操作解決時，可能會顯示為“Resolvable Gap”狀態。這通常不是SWITCHOVER_STATUS的直接輸出，而是描述問題性質的一種方式。
UNRESOLVABLE GAP	在主資料庫上，此狀態表示一個或多個備用資料庫具有redo缺失(redo gap)，無法透過從主資料庫或另一個備用資料庫獲取丟失的redo日誌來自動解決該缺口
LOG SWITCH GAP	在主資料庫上，此狀態表示由於最近的日誌切換，一個或多個備用資料庫缺失了redo log。

檢查主庫重做日誌傳輸和應用狀態

主庫(Primary)

COL DEST_NAME FOR A20
COL DESTINATION FOR A25
COL ERROR FOR A15
COL ALTERNATE FOR A20
SET LINES 1000
SELECT DEST_NAME,DESTINATION,ERROR
      ,ALTERNATE,TYPE,STATUS
      ,VALID_TYPE,VALID_ROLE 
FROM V$ARCHIVE_DEST 
WHERE STATUS <>'INACTIVE';

重點關注ERROR欄位的輸出資訊，如果重做日誌傳輸和應用有問題，就會有相關錯誤資訊提示。

檢查主庫最後生成的歸檔日誌檔案

主庫(Primary)

SELECT   THREAD#, MAX(SEQUENCE#) "Last Primary Seq Generated"  
FROM     GV$ARCHIVED_LOG VAL, GV$DATABASE VDB
WHERE    VAL.RESETLOGS_CHANGE# = VDB.RESETLOGS_CHANGE#
GROUP BY THREAD# ORDER BY 1;

備庫(Standby)檢查驗證最後收到主庫的歸檔日誌

--Using the below query, check the last received archivelog from primary database 
--(RAC database result will be displayed for each thread).
SELECT   THREAD#, MAX(SEQUENCE#) "Last Standby Seq Received"  
FROM     GV$ARCHIVED_LOG VAL, GV$DATABASE VDB
WHERE    VAL.RESETLOGS_CHANGE# = VDB.RESETLOGS_CHANGE#
GROUP BY THREAD# ORDER BY 1;

備庫(standby)檢查最後應用的歸檔日誌序列

--Check last archive log sequence applied at standby.
SELECT    THREAD#, MAX(SEQUENCE#) "Last Standby Seq Applied"
FROM     GV$ARCHIVED_LOG VAL, GV$DATABASE VDB
WHERE    VAL.RESETLOGS_CHANGE# = VDB.RESETLOGS_CHANGE#
AND      VAL.APPLIED IN ('YES','IN-MEMORY')
GROUP BY THREAD# ORDER BY 1; 

驗證初始化引數

--主庫(primary)&備庫(standby)檢查

--檢查驗證引數

show parameter log_archive_config;
show parameter fal_server;
show parameter fal_client;
show parameter db_unique_name;
show parameter log_archive_dest_;
show parameter compatible;
show parameter db_file_name_convert;
show parameter log_file_name_convert;
show parameter pdb_file_name_convert;

或

set linesize 720 pagesize 60
col name for a30
col value for a120
SELECT 
    NAME,
    VALUE 
FROM 
    V$PARAMETER 
WHERE 
    NAME IN (
        'db_unique_name',
        'log_archive_config',
        'log_archive_dest_1',
        'log_archive_dest_2',
        'log_archive_dest_state_1',
        'log_archive_dest_state_2',
        'remote_login_passwordfile',
        'log_archive_format',
        'standby_file_management',
        'compatible',
        'fal_server',
        'db_file_name_convert',
        'log_file_name_convert'
        )
order by name;       

注意事項：要確保相容引數compatible和noncdb_compatible在主備上一致。

切換前工作(Pre-Switchover)

Ensure Prerequisites are completely verified. Along with Prerequisites, Follow the below guidance to have successful switchover. These steps should be executed before real planned outage starts and ensure no issues.

檢查MRP程序狀態

備庫(standby)

select * from gv$dataguard_process;

停止/啟動MRP程序，特殊情況下執行，此處不用執行。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  DISCONNECT;

檢查資料檔案和Tempfiles

這個步驟不是必須的，如果你確認DG最近沒有相關資料檔案和臨時表空間的相關檔案調整，可以直接跳過這一步。

--Check the datafiles & Tempfiles status

SELECT NAME FROM V$DATAFILE WHERE STATUS='OFFLINE';
--ALTER DATABASE DATAFILE 'datafile-name' ONLINE;

檢查temp表空間的檔案

set linesize 680
set pagesize 40
col filename for a80
col tablespace for a16
select tf.name filename
      , bytes
      , ts.name tablespace    
from v$tempfile tf, v$tablespace ts where tf.ts#=ts.ts#;

檢查redo log和standby redo log的資訊

執行下面SQL檢查redo log和standby redo log的資訊(主庫和備庫)

set lines 680
col member for a50
select a.thread#,a.group#,a.bytes,a.blocksize,b.type,a.status,b.member 
from v$log a,v$logfile b 
where a.group#=b.group#
order by a.group#;

set lines 680
col member for a50
select s.thread#,s.group#,s.status,s.bytes,l.type,l.member 
from v$logfile l,v$standby_log s where s.group#=l.group#
order by s.thread#,s.group#;

--檢查REDO LOG或歸檔日誌應用延遲。(主庫執行)

SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;

DEST_ID的值可以根據實際情況調整。STATUS欄位應該為VALID，GAP_STATUS欄位應該為"NO GAP"

檢查監控告警日誌

主庫(Primary)和備庫(Standby)

$ tail -600 alert_<ORACLE_SID>.ora | grep ORA 
$ tail -60f alert_<ORACLE_SID>.ora

關於檢查的具體內容，官方文件描述為

1) From primary database alert logfile:
    * Check for issue reported for redo transport
    * Ensure there is no password file issue
    * Ensure there are no TNS or connection issue

2) From Standby database alert logfile:
    * There are no error related to Managed recovery
    * Recovery is moving forward by applying the archive log / redo log
    * There are no TNS or connection issue
    * There are no I/O issue or corruption issue
    select * from v$database_block_corruption;  -- it should return no rows
    select * from v$nonlogged_block; -- it should return no rows

DG切換(Switchover)

驗證切換(Verify the switchover)

ADG切換驗證：(主庫執行):

ALTER DATABASE SWITCHOVER TO gspro VERIFY;

上面命令成功執行的話，則會返回"Database altered.",才可以執行下面命令，否則需要檢查分析原因。

上面命令執行成功，主庫告警日誌中會出現下面資訊：

2024-07-10T09:11:45.281610+08:00
ALTER DATABASE SWITCHOVER TO gspro VERIFY
2024-07-10T09:11:45.530174+08:00
SWITCHOVER VERIFY: Send VERIFY request to switchover target GSPRO
SWITCHOVER VERIFY COMPLETE: READY FOR SWITCHOVER
Completed: ALTER DATABASE SWITCHOVER TO gspro VERIFY

備庫的告警日誌中也會出現下面日誌

2024-07-10T09:11:45.598106+08:00
SWITCHOVER VERIFY BEGIN
SWITCHOVER VERIFY COMPLETE

如果執行報錯，也會在告警日誌中看到詳細的錯誤資訊。

切換(Switchover)步驟

--Step 1: (主庫執行)

ALTER DATABASE SWITCHOVER TO gspro;

--Step 2: 舊備庫上/新的主庫(new primary)執行

ALTER DATABASE OPEN;

--Step 3: 新的備庫/舊主庫上執行(current/new standby )

--If standby is Oracle Active data guard physical standby:
STARTUP;
--If standby is NOT Oracle Active data guard physical standby:
STARTUP MOUNT;

--注意：退出之前的sqlplus命令視窗，重新登陸執行命令，否則可能會遇到一些錯誤。如下例子所示：

SQL> STARTUP;
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORA-49100: Failed to process event statement [10235 trace name context forever,level 2: 7445 trace name heapdump level 2: 10027 trace name context forever,level 1: 10949 trace name context forever,level 1] 
ORA-00972: identifier is too long

將PDB啟動到OPEN狀態

SHOW PDBS;
ALTER PLUGGABLE DATABASE ALL OPEN;

--Step 4:新的備庫開始redo apply

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

--Step 5: 檢查確認Switchover是否正常

--主庫

alter system archive log current;
set linesize 720;
select dest_id,error,status from v$archive_dest where dest_id=<your remote log_archive_dest_<n>>;  --一般為2
select max(sequence#),thread# from v$log_history group by thread#;
select max(sequence#)  from v$archived_log where applied='YES' and dest_id=2;

--備庫(standby)

select max(sequence#),thread# from v$archived_log group by thread#;
select name,role,instance,thread#,sequence#,action from gv$dataguard_process;

--備庫執行SQL,檢查同步狀態

set linesize 720;
col name for a24;
col source_db_unique_name for a16;
col value for a16;
col unit for a20;
col time_computed for a19;
col datum_time for a19;
select source_db_unique_name
     , name
     , value
     , unit
     , time_computed 
     , datum_time
from v$dataguard_stats;

SQL> set linesize 720;
SQL> col name for a24;
SQL> col source_db_unique_name for a16;
SQL> col value for a16;
SQL> col unit for a20;
SQL> col time_computed for a19;
SQL> col datum_time for a19;
SQL> select source_db_unique_name
  2       , name
  3       , value
  4       , unit
  5       , time_computed 
  6       , datum_time
  7  from v$dataguard_stats;

SOURCE_DB_UNIQUE NAME                     VALUE            UNIT                 TIME_COMPUTED       DATUM_TIME
---------------- ------------------------ ---------------- -------------------- ------------------- -------------------
gspro            transport lag            +00 00:00:00     day(2) to second(0)  07/10/2024 09:44:36 07/10/2024 09:44:35
                                                           interval

gspro            apply lag                +00 00:00:00     day(2) to second(0)  07/10/2024 09:44:36 07/10/2024 09:44:35
                                                           interval

gspro            apply finish time        +00 00:00:00.000 day(2) to second(3)  07/10/2024 09:44:36
                                                           interval

                 estimated startup time   16               second               07/10/2024 09:44:36

SQL>

參考資料

[1]

1: https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=246469404737555&id=2485237.1&_afrWindowMode=0&_adf.ctrl-state=18aegmiut3_4