Oracle ADG Snapshot Standby体验

本文参考了OBE文章Using Snapshot Standby

Snapshot Standby的概念

参见这里。

A snapshot standby database is a fully updatable standby database. It receives and archives redo data from a primary database, but does not apply it.

Redo data received from the primary database is applied when a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database.

A snapshot standby database typically diverges from its primary database over time because redo data from the primary database is not applied as it is received. Local updates to the snapshot standby database cause additional divergence. The data in the primary database is fully protected however, because a snapshot standby can be converted back into a physical standby database at any time, and the redo data received from the primary is then applied.

A snapshot standby database provides disaster recovery and data protection benefits that are similar to those of a physical standby database. Snapshot standby databases are best used in scenarios where the benefit of having a temporary, updatable snapshot of the primary database justifies increased time to recover from primary database failures.

准备工作，搭建ADG环境

搭建了一个标准的ADG配置，一个Primary，一个Physical Standby。

$ dgmgrl
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Mon Jul 31 03:18:49 2023
Version 19.19.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys
Password:
Connected to "DB0730_n5p_fra"
Connected as SYSDBA.
DGMGRL> show configuration

Configuration - DB0730_n5p_fra_DB0730_8th_fra

  Protection Mode: MaxPerformance
  Members:
  DB0730_n5p_fra - Primary database
    DB0730_8th_fra - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 15 seconds ago)

确认FlashBack Database特性已开启

Snapshot Standby 依赖于Flashback Database，详见这里。此时Flashback Database的作用为：

Flashback Database is used to convert a snapshot standby database back into a physical standby database.

确认主备数据库均已开启Flashback Database，并且默认的保留期为24小时：

SQL> select FLASHBACK_ON from v$database;

FLASHBACK_ON
------------------
YES

SQL> show parameter flashback

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target        integer     1440

将Physical Standby数据库转换为Snapshot Standby 数据库

在转换之前，确认此时并没有restore point：

SQL> select * from V$RESTORE_POINT;

no rows selected

将Physical Standby转换为Snapshot Standby：

DGMGRL> convert database DB0730_8th_fra to snapshot standby;
Converting database "db0730_8th_fra" to a Snapshot Standby database, please wait...
Database "db0730_8th_fra" converted successfully

-- 以下是另一种方法
-- SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

此时在备库上已自动创建了有保障的恢复点：

SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
        GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE
        FROM V$RESTORE_POINT;

NAME                                             SCN        TIME                               DATABASE_INCARNATION#    GUARANTEE_FLASHBACK_DATABASE    STORAGE_SIZE    
SNAPSHOT_STANDBY_REQUIRED_07/31/2023 03:22:47       1952214 31-JUL-23 03.22.47.000000000 AM                           2 YES                                  1073741824 

此时的配置如下，注意其中的Snapshot standby：

DGMGRL> show configuration

Configuration - DB0730_n5p_fra_DB0730_8th_fra

  Protection Mode: MaxPerformance
  Members:
  DB0730_n5p_fra - Primary database
    DB0730_8th_fra - Snapshot standby database
      Warning: ORA-16855: transport lag has exceeded specified threshold

Fast-Start Failover:  Disabled

Configuration Status:
WARNING   (status updated 29 seconds ago)

上面输出中ORA-16855的错误是正常的，可以看下要求的delay是多少：

SQL> show parameter log_archive_dest_n

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2                   string      service="DB0730_8th_fra", ASYN
                                                 C NOAFFIRM delay=0 optional co
                                                 mpression=disable max_failure=
                                                 0 reopen=300 db_unique_name="D
                                                 B0730_8th_fra" net_timeout=30,
                                                  valid_for=(online_logfile,all
                                                 _roles)

DGMGRL也可以看：

DGMGRL> show database verbose "DB0730_n5p_fra" DelayMins
  DelayMins = '0'

可以看到，要求的为0，而实际的滞后为36分钟：

SQL> SELECT * FROM v$dataguard_stats WHERE name LIKE '%lag%';

SOURCE_DBID SOURCE_DB_UNIQUE_NAME            NAME
----------- -------------------------------- --------------------------------
VALUE
----------------------------------------------------------------
UNIT                           TIME_COMPUTED
------------------------------ ------------------------------
DATUM_TIME                         CON_ID
------------------------------ ----------
 1907664404 DB0730_n5p_fra                   transport lag
+00 00:36:14
day(2) to second(0) interval   07/31/2023 03:59:02
07/31/2023 03:59:00                     0


SOURCE_DBID SOURCE_DB_UNIQUE_NAME            NAME
----------- -------------------------------- --------------------------------
VALUE
----------------------------------------------------------------
UNIT                           TIME_COMPUTED
------------------------------ ------------------------------
DATUM_TIME                         CON_ID
------------------------------ ----------
 1907664404 DB0730_n5p_fra                   apply lag
+00 00:36:16
day(2) to second(0) interval   07/31/2023 03:59:02
07/31/2023 03:59:00                     0

更新数据库并确认Redo仍在复制

登录备库，查询表v$managed_standby，记录其BLOCK#的值：

SELECT
    v$managed_standby.status,
    v$managed_standby.sequence#,
    v$managed_standby.block#
FROM
    v$managed_standby
WHERE
    v$managed_standby.client_process = 'LGWR'

STATUS       SEQUENCE#    BLOCK#    
RECEIVING              36      1135

清空备库中某表，同时也可以证明Snapshot Standby是可写的：

SQL> select count(*) from date_dim;

  COUNT(*)
----------
      2556

SQL> truncate table date_dim;

Table truncated.

SQL> select count(*) from date_dim;

  COUNT(*)
----------
         0

在主库中将此表数据翻倍：

SQL> select count(*) from date_dim;

  COUNT(*)
----------
      2556

SQL> insert into date_dim select * from date_dim;

2556 rows created.

SQL> commit;

Commit complete.

SQL> select count(*) from date_dim;

  COUNT(*)
----------
      5112

再次查询表v$managed_standby，记录其BLOCK#的值，此时由1135变为了2836：

SELECT
    v$managed_standby.status,
    v$managed_standby.sequence#,
    v$managed_standby.block#
FROM
    v$managed_standby
WHERE
    v$managed_standby.client_process = 'LGWR'
    
STATUS       SEQUENCE#    BLOCK#    
RECEIVING              36      2836 

BLOCK#的定义为：

Last processed archived redo log block number

将Snapshot Standby 还原为Physical Standby

关于这一步，以下文档非常有用：

• Data Guard Physical Standby - Converting a Snapshot Standby back to a Physical Standby using Data Guard Broker (Doc ID 1546657.1)

注意要用口令而非以下方式登录dgmgrl，否则在后续操作过程中会报错：

$ dgmgrl / as sysdba
...
DGMGRL> convert database DB0730_8th_fra to physical standby;
Converting database "db0730_8th_fra" to a Physical Standby database, please wait...
Oracle Clusterware is restarting database "DB0730_8th_fra" ...
ORA-01017: invalid username/password; logon denied


Please complete the following steps and reissue the CONVERT command:
        shut down instance "DB0730" of database "DB0730_8th_fra"
        start up instance "DB0730" of database "DB0730_8th_fra"

应该用connect sys命令登录：

$ dgmgrl
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Mon Jul 31 04:29:42 2023
Version 19.19.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys
Password:
Connected to "DB0730_n5p_fra"
Connected as SYSDBA.
DGMGRL> show configuration

Configuration - DB0730_n5p_fra_DB0730_8th_fra

  Protection Mode: MaxPerformance
  Members:
  DB0730_n5p_fra - Primary database
    DB0730_8th_fra - Snapshot standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 31 seconds ago)

DGMGRL> convert database DB0730_8th_fra to physical standby;
Converting database "db0730_8th_fra" to a Physical Standby database, please wait...
Oracle Clusterware is restarting database "DB0730_8th_fra" ...
Connected to "DB0730_8th_fra"
Continuing to convert database "db0730_8th_fra" ...
Database "db0730_8th_fra" converted successfully
DGMGRL> show configuration

Configuration - DB0730_n5p_fra_DB0730_8th_fra

  Protection Mode: MaxPerformance
  Members:
  DB0730_n5p_fra - Primary database
    DB0730_8th_fra - Physical standby database
      Warning: ORA-16809: multiple warnings detected for the member

Fast-Start Failover:  Disabled

Configuration Status:
WARNING   (status updated 11 seconds ago)

以上输出中的警告是临时的，过一会就正常了：

DGMGRL> show configuration

Configuration - DB0730_n5p_fra_DB0730_8th_fra

  Protection Mode: MaxPerformance
  Members:
  DB0730_n5p_fra - Primary database
    DB0730_8th_fra - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 15 seconds ago)

在备库中确认数据已复制，并且只读

SQL> show con_name

CON_NAME
------------------------------
ORCLPDB1
SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         3 ORCLPDB1                       MOUNTED

SQL> alter pluggable database orclpdb1 open;

Pluggable database altered.

SQL> alter session set container=orclpdb1;

Session altered.

SQL> select count(*) from ssb.date_dim;

  COUNT(*)
----------
      5112

SQL> truncate table ssb.date_dim;
truncate table ssb.date_dim
                   *
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-16000: database or pluggable database open for read-only access

参考

• Flashback Database Best Practices & Performance (Doc ID 565535.1)
• Data Guard Physical Standby - Converting a Snapshot Standby back to a Physical Standby using Data Guard Broker (Doc ID 1546657.1)
• Managing Physical and Snapshot Standby Databases
• Using Snapshot Standby Database. (Doc ID 443720.1)