1.配置 dg_broker
| IP | hostname | db_unique_name | DG Broker role | switchover role | failover role |
|---|---|---|---|---|---|
| 172.52.169.62 | primary | primary | 主库 | 从库 | 从库 |
| 172.52.168.144 | standby | standby | 从库 | 主库 | 从库 |
使用以下方法可以添加多个备库，具体配置的差异由你来确定
2.安装oracle数据库软件
略…
3.主数据库配置
3.1.设置数据库归档
查看数据库是否运行在归档模式：
SQL> archive log list
数据库日志模式 存档模式
自动存档 未启用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 18
下一个存档日志序列 20
当前日志序列 20
SQL>
数据库已经开启归档，下面的操纵可以忽略。
如上所示未开启归档，可按下面方法开启数据库归档
SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 2432695144 bytes
Fixed Size 8899432 bytes
Variable Size 536870912 bytes
Database Buffers 1879048192 bytes
Redo Buffers 7876608 bytes
Database mounted.
SQL> alter database archivelog;
Database altered.
SQL> alter database open;
Database altered.
SQL>
设置归档路径
SQL> alter system set log_archive_dest_1='location=D:\app\Administrator\archivelog';
系统已更改。
SQL> archive log list
数据库日志模式 存档模式
自动存档 启用
存档终点 D:\app\Administrator\archivelog
最早的联机日志序列 18
下一个存档日志序列 20
当前日志序列 20
SQL>
3.2.设置数据库闪回
验证是否开启闪回
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------------------------
NO
SQL>
SQL> show parameter db_recovery_file_dest
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
db_recovery_file_dest string D:\app\Administrator\fast_reco
very_area
db_recovery_file_dest_size big integer 12732M
SQL>
数据库已经开启flashback，那么下面步骤可忽略。
如上显示，该数据库未开启flashback，可按下面方法开启。
a. 创建文件夹 D:\app\Administrator\fast_recovery_area
b. 配置 db_recovery_file_dest
SQL> alter system set db_recovery_file_dest='D:\app\Administrator\fast_recovery_area';
System altered.
SQL> show parameter db_recovery_file_dest
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
db_recovery_file_dest string D：\app\Administrator\fast_recovery_area
db_recovery_file_dest_size big integer 12732M
SQL>
c. 开启闪回
SQL> alter database flashback on;
数据库已更改。
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------------------------
YES
SQL>
3.3.设置数据库强制归档
验证是否开启focelogging
SQL> select force_logging from v$database;
FORCE_LOGGING
------------------------------------------------------------------------------
NO
SQL>
数据库已经开启force logging，那么下面步骤可忽略。
如上可以看出数据库未开启，则按下面步骤执行：
SQL> alter database force logging;
数据库已更改。
SQL>
SQL> select force_logging from v$database;
FORCE_LOGGING
------------------------------------------------------------------------------
YES
SQL>
3.4.添加 STANDBY 日志文件
通过下面语句可以查询主库在线日志的大小和组数：
SQL> select group#, bytes/1024/1024 from v$log;
GROUP# BYTES/1024/1024
---------- ---------------
1 200
2 200
3 200
SQL>
通过下面的语句可以查询备库Standby日志的大小和组数：
SQL> select group#,bytes/1024/1024 from v$standby_log;
no rows selected
SQL>
创建standby logfile
alter database add standby logfile group 4 'D:\app\Administrator\oradata\ORCL\STANDBY_REDO04.LOG' size 200M;
alter database add standby logfile group 5 'D:\app\Administrator\oradata\ORCL\STANDBY_REDO05.LOG' size 200M;
alter database add standby logfile group 6 'D:\app\Administrator\oradata\ORCL\STANDBY_REDO06.LOG' size 200M;
alter database add standby logfile group 7 'D:\app\Administrator\oradata\ORCL\STANDBY_REDO07.LOG' size 200M;
确认 standby redolog file
SQL> select group#, bytes/1024/1024 from v$standby_log;
GROUP# BYTES/1024/1024
---------- ---------------
4 200
5 200
6 200
7 200
SQL>
3.5.修改 db_unique_name
alter system set db_unique_name='primary' scope=spfile;
重新启动数据库，然后再重启动监听服务
lsnrctl reload
3.6.修改监听配置文件
# listener.ora Network Configuration File: D:\app\Administrator\oracle\product\19.3.0\db_home\NETWORK\ADMIN\listener.ora
# Generated by Oracle configuration tools.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby-database)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = primary)
(SID_NAME = orcl)
(ORACLE_HOME = D:\app\Administrator\oracle\product\19.3.0\db_home)
)
(SID_DESC =
(GLOBAL_DBNAME = primary_DGMGRL)
(ORACLE_HOME = D:\app\Administrator\oracle\product\19.3.0\db_home)
(SID_NAME = orcl)
(ENVS="TNS_ADMIN=D:\app\Administrator\oracle\product\19.3.0\db_home\NETWORK\ADMIN")
)
)
ADR_BASE_LISTENER = D:\app\Administrator\oracle
3.7.修改TNS配置文件
# tnsnames.ora Network Configuration File: D:\app\Administrator\oracle\product\19.3.0\db_home\NETWORK\ADMIN\tnsnames.ora
# Generated by Oracle configuration tools.
LISTENER_ORCL =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby-database)(PORT = 1521))
STANDBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby-database)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = standby)
(UR = A)
)
)
PRIMARY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = primary-database)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = primary)
(UR = A)
)
)
创建认证配置文件
D:\app\Administrator\oracle\product\19.3.0\db_home\NETWORK\ADMIN\sqlnet.ora
# This file is actually generated by netca. But if customers choose to
# install "Software Only", this file wont exist and without the native
# authentication, they will not be able to connect to the database on NT.
SQLNET.AUTHENTICATION_SERVICES = (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
ADR_BASE = D:\app\Administrator\oracle
4.备数据库配置
4.1.拷贝参数文件
4.2.拷贝密码文件
4.3.创建相应的文件目录
根据上面修改的参数文件，为备库创建相应的文件目录
D:\app\oracle\archivelog
D:\app\oracle\fast_recovery_area\orcl
D:\app\oracle\admin\orcl\adump
D:\app\oracle\oradata\orcl
4.4.修改监听配置文件
# listener.ora Network Configuration File: D:\app\Administrator\oracle\product\19.3.0\db_home\NETWORK\ADMIN\listener.ora
# Generated by Oracle configuration tools.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby-database)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = standby)
(SID_NAME = orcl)
(ORACLE_HOME = D:\app\Administrator\oracle\product\19.3.0\db_home)
)
(SID_DESC =
(GLOBAL_DBNAME = standby_DGMGRL)
(ORACLE_HOME = D:\app\Administrator\oracle\product\19.3.0\db_home)
(SID_NAME = orcl)
(ENVS="TNS_ADMIN=D:\app\Administrator\oracle\product\19.3.0\db_home\NETWORK\ADMIN")
)
)
ADR_BASE_LISTENER = D:\app\Administrator\oracle
4.5.修改TNS配置文件
# tnsnames.ora Network Configuration File: D:\app\Administrator\oracle\product\19.3.0\db_home\NETWORK\ADMIN\tnsnames.ora
# Generated by Oracle configuration tools.
LISTENER_ORCL =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby-database)(PORT = 1521))
STANDBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby-database)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = standby)
(UR = A)
)
)
PRIMARY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = primary-database)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = primary)
(UR = A)
)
)
创建认证配置文件
D:\app\Administrator\oracle\product\19.3.0\db_home\NETWORK\ADMIN\sqlnet.ora
# This file is actually generated by netca. But if customers choose to
# install "Software Only", this file wont exist and without the native
# authentication, they will not be able to connect to the database on NT.
SQLNET.AUTHENTICATION_SERVICES = (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
ADR_BASE = D:\app\Administrator\oracle
4.6.修改 db_unique_name
alter system set db_unique_name='standby' scope=spfile;
重新启动数据库到 nomount 状态，然后再启动监听服务
lsnrctl start
5.验证监听和TNS配置
主库:
sqlplus sys/admin123@primary as sysdba
sqlplus sys/admin123@standby as sysdba
备库:
sqlplus sys/admin123@primary as sysdba
sqlplus sys/admin123@standby02 as sysdba
注意：该步骤一定要在主备库上都能通过才能执行下面步骤
6.恢复数据库
# 连接数据库
rman target sys/admin123@primary auxiliary sys/admin123@standby nocatalog
# 备份数据
duplicate target database for standby from active database nofilenamecheck;
7.dg_broker 添加备库
dg_broker_config_file1 以及 dg_broker_config_file2 对应路径必须先存在(不存在需要先创建，否则启动dg_broker_start提示ORA-16604: Data Guard broker configuration file inaccessible 。)
step 1.查看 DG_BROKER_CONFIG_FILE文件
SQL> set linesize 1000
SQL> show parameter broker
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
connection_brokers string ((TYPE=DEDICATED)(BROKERS=1)),
((TYPE=EMON)(BROKERS=1))
dg_broker_config_file1 string D:\APP\ADMINISTRATOR\ORACLE\PR
ODUCT\19.3.0\DB_HOME\DATABASE\
DR1PRIMARY.DAT
dg_broker_config_file2 string D:\APP\ADMINISTRATOR\ORACLE\PR
ODUCT\19.3.0\DB_HOME\DATABASE\
DR2PRIMARY.DAT
dg_broker_start boolean FALSE
use_dedicated_broker boolean FALSE
SQL>
可以用默认的路径，也可以自己指定 。如果是RAC环境，把这个文件把到共享存储或者ASM中。
step 2.重置 LOG_ARCHIVE_DEST_n 信息
所有节点均需配置，这步开始，已有主从同步会中断。
ALTER SYSTEM set LOG_ARCHIVE_DEST_2='';
ALTER SYSTEM set LOG_ARCHIVE_DEST_3='';
使用 reset 需要重启 。
step 3.开启 dg_broker_start 为TRUE,默认是FALSE
SQL> alter system set dg_broker_start=true sid='*';
step 4.创建DGMGRL主库配置文件
使用 dgmgrl 远程登陆主库进行配置
C:\Users\Administrator> dgmgrl sysdg/Oracle12
DGMGRL for 64-bit Windows: Release 19.0.0.0.0 - Production on ??? 5? 28 23:05:49 2024
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
欢迎使用 DGMGRL, 要获取有关信息请键入 "help"。
已连接到 "primary"
以 SYSDG 身份连接。
DGMGRL> CREATE CONFIGURATION xiangxun AS PRIMARY DATABASE IS primary CONNECT IDENTIFIER IS primary;
已使用主数据库 "primary" 创建配置 "ditie"
DGMGRL>
查看配置
DGMGRL> show configuration;
配置 - xiangxun
保护模式: MaxPerformance
成员:
primary - 主数据库
快速启动故障转移: Disabled
配置状态:
DISABLED
DGMGRL>
启用主库配置
DGMGRL> ENABLE CONFIGURATION;
已启用。
DGMGRL> show configuration;
配置 - xiangxun
保护模式: MaxPerformance
成员:
primary - 主数据库
警告: ORA-16789: 备用重做日志未正确配置
快速启动故障转移: Disabled
配置状态:
WARNING (状态已在 1 秒前更新)
DGMGRL>
step 5.增加备库：
DGMGRL> add database 'standby' as connect identifier is standby;
已添加数据库 "standby"
DGMGRL>
查看配置：
DGMGRL> show configuration;
配置 - xiangxun
保护模式: MaxPerformance
成员:
primary - 主数据库
警告: ORA-16789: 备用重做日志未正确配置
standby - 物理备用数据库 (disabled)
ORA-16905: 尚未启用成员。
快速启动故障转移: Disabled
配置状态:
WARNING (状态已在 9 秒前更新)
DGMGRL>
启用当前配置:
DGMGRL> enable Database standby;
已启用。
DGMGRL>
step 6.查看配置详细信息:
DGMGRL> show configuration;
配置 - xiangxun
保护模式: MaxPerformance
成员:
primary - 主数据库
警告: ORA-16789: 备用重做日志未正确配置
standby - 物理备用数据库
警告: ORA-16809: 检测到成员的多个警告
快速启动故障转移: Disabled
配置状态:
WARNING (状态已在 28 秒前更新)
查看配置详细信息:
DGMGRL> show configuration verbose;
配置 - xiangxun
保护模式: MaxPerformance
成员:
primary - 主数据库
警告: ORA-16789: 备用重做日志未正确配置
standby - 物理备用数据库
警告: ORA-16809: 检测到成员的多个警告
属性:
FastStartFailoverThreshold = '30'
OperationTimeout = '30'
TraceLevel = 'USER'
FastStartFailoverLagLimit = '30'
CommunicationTimeout = '180'
ObserverReconnect = '0'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'
ObserverOverride = 'FALSE'
ExternalDestination1 = ''
ExternalDestination2 = ''
PrimaryLostWriteAction = 'CONTINUE'
ConfigurationWideServiceName = 'orcl_CFG'
快速启动故障转移: Disabled
配置状态:
WARNING
DGMGRL>
获取信息中包含任何告警都需要进行处理。
step 7.通过dgmgrl查看主备实例详细
前面使用单引号增加database,后面查询一律要使用。
主库信息：
DGMGRL> show database verbose primary;
数据库 - primary
角色: PRIMARY
预期状态: TRANSPORT-ON
实例:
orcl
数据库警告:
ORA-16789: 备用重做日志未正确配置
属性:
DGConnectIdentifier = 'primary'
ObserverConnectIdentifier = ''
FastStartFailoverTarget = ''
PreferredObserverHosts = ''
LogShipping = 'ON'
RedoRoutes = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyLagThreshold = '30'
TransportLagThreshold = '30'
TransportDisconnectedThreshold = '30'
ApplyParallel = 'AUTO'
ApplyInstances = '0'
StandbyFileManagement = ''
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '0'
LogArchiveMinSucceedDest = '0'
DataGuardSyncLatency = '0'
LogArchiveTrace = '0'
LogArchiveFormat = ''
DbFileNameConvert = ''
LogFileNameConvert = ''
ArchiveLocation = ''
AlternateLocation = ''
StandbyArchiveLocation = ''
StandbyAlternateLocation = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
LogXptStatus = '(monitor)'
SendQEntries = '(monitor)'
RecvQEntries = '(monitor)'
HostName = 'PRIMARY-DATABAS'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=WIN-93I9QSRLKN6)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=primary_DGMGRL)(INSTANCE_NAME=orcl)(SERVER=DEDICATED)))'
TopWaitEvents = '(monitor)'
SidName = '(monitor)'
日志文件位置:
预警日志 : D:\APP\ADMINISTRATOR\diag\rdbms\primary\orcl\trace\alert_orcl.log
Data Guard 中介日志 : D:\APP\ADMINISTRATOR\diag\rdbms\primary\orcl\trace\drcorcl.log
数据库状态:
WARNING
DGMGRL>
FQ 1:主库未添加 standby log file。
FQ 2:修改staticconnectidentifier参数或者静态参数文件
如果没有这个步骤在broker切换时会提示连接不到数据库，需要手动启动新备库。
因为staticconnectidentifier指向静态监听名 <db_unique_name>
该参数默认指向的service_name是<db_unique_name>_DGMGRL如果不修改该参数则需要修改监听文件。
DGMGRL> edit database primary set property StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=primary-database)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=primary_DGMGRL)(INSTANCE_NAME=orcl)(SERVER=DEDICATED)))';
已更新属性 "staticconnectidentifier"
DGMGRL>
备库信息：
DGMGRL> show database verbose standby;
数据库 - standby
角色: PHYSICAL STANDBY
预期状态: APPLY-ON
传输滞后: 7 分钟 1 秒 (已在 13 秒之前计算)
应用滞后: (未知)
平均应用速率: (未知)
活动应用速率: (未知)
最大应用速率: (未知)
实时查询: OFF
实例:
orcl
数据库警告:
ORA-16853: 应用滞后已超出指定阈值
ORA-16855: 传输滞后已超出指定阈值
ORA-16789: 备用重做日志未正确配置
属性:
DGConnectIdentifier = 'standby'
ObserverConnectIdentifier = ''
FastStartFailoverTarget = ''
PreferredObserverHosts = ''
LogShipping = 'ON'
RedoRoutes = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyLagThreshold = '30'
TransportLagThreshold = '30'
TransportDisconnectedThreshold = '30'
ApplyParallel = 'AUTO'
ApplyInstances = '0'
StandbyFileManagement = ''
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '0'
LogArchiveMinSucceedDest = '0'
DataGuardSyncLatency = '0'
LogArchiveTrace = '0'
LogArchiveFormat = ''
DbFileNameConvert = ''
LogFileNameConvert = ''
ArchiveLocation = ''
AlternateLocation = ''
StandbyArchiveLocation = ''
StandbyAlternateLocation = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
LogXptStatus = '(monitor)'
SendQEntries = '(monitor)'
RecvQEntries = '(monitor)'
HostName = 'STANDBY-DATABAS'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=standby-database)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=standby_DGMGRL)(INSTANCE_NAME=orcl)(SERVER=DEDICATED)))'
TopWaitEvents = '(monitor)'
SidName = '(monitor)'
日志文件位置:
预警日志 : D:\APP\ADMINISTRATOR\diag\rdbms\standby\orcl\trace\alert_orcl.log
Data Guard 中介日志 : D:\APP\ADMINISTRATOR\diag\rdbms\standby\orcl\trace\drcorcl.log
数据库状态:
WARNING
DGMGRL>
备库添加 Standby log file
a. 需要关闭mrp
alter database recover managed standby database cancel;
alter database recover managed standby database parallel 10 using current logfile disconnect from session;
b. 添加 standby log file
c. 开启实时同步
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
FQ 1：ORA-16853: 应用滞后已超出指定阈值
The Data Guard broker also has configurable database properties that can be used to generate warnings when a transport or apply lag exceed a user defined value:
Data Guard代理还具有可配置的数据库属性，当传输或应用滞后超过用户定义的值时，这些属性可用于生成警告：
- ApplyLagThreshold
The ApplyLagThreshold configurable database property generates a warning status for a logical or physical standby when the database’s apply lag exceeds the value specified by the property. The property value is expressed in seconds. A value of 0 seconds results in no warnings being generated when an apply lag exists. As a best practice, Oracle recommends setting ApplyLagThreshold to at least 15 minutes.
当数据库的应用滞后超过属性指定的值时，ApplyLagThreshold可配置数据库属性会为逻辑或物理备用生成警告状态。属性值以秒为单位表示。如果值为0秒，则在存在应用滞后时不会生成任何警告。作为最佳实践，Oracle建议将ApplyLagThreshold设置为至少15分钟。
- TransportLagThreshold
The TransportLagThreshold configurable database property can be used to generate a warning status for a logical, physical, or snapshot standby when the database’s transport lag exceeds the value specified by the property. The property value is expressed in seconds. A value of 0 seconds results in no warnings being generated when a transport lag exists. As a best practice, Oracle recommends setting TransportLagThreshold to at least 15 minutes.
当数据库的传输滞后超过属性指定的值时，TransportLagThreshold可配置数据库属性可用于为逻辑、物理或快照备用生成警告状态。属性值以秒为单位表示。如果值为0秒，则在存在传输滞后时不会生成任何警告。作为最佳做法，Oracle建议将TransportLagThreshold设置为至少15分钟。
DGMGRL> edit database standby set property ApplyLagThreshold=3600;
已更新属性 "applylagthreshold"
DGMGRL> edit database standby set property TransportLagThreshold=3600;
已更新属性 "transportlagthreshold"
DGMGRL>
FQ 2：ORA-16855的错误是正常的，可以看下要求的delay是多少：
SQL> show parameter log_archive_dest_2
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
log_archive_dest_2 string service="standby", ASYNC NOAFF
IRM delay=0 optional compressi
on=disable max_failure=0 reope
n=300 db_unique_name="standby"
net_timeout=30, valid_for=(on
line_logfile,all_roles)
log_archive_dest_20 string
log_archive_dest_21 string
log_archive_dest_22 string
log_archive_dest_23 string
log_archive_dest_24 string
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
log_archive_dest_25 string
log_archive_dest_26 string
log_archive_dest_27 string
log_archive_dest_28 string
log_archive_dest_29 string
SQL>
DGMGRL也可以看：
DGMGRL> show database verbose primary DelayMins;
DelayMins = '0'
DGMGRL>
可以看到，要求的为0，而实际的滞后为 15 分钟：
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
----------- ---------------------------------------------------------------- ---------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------ ------------------------------------------------------------ ------------------------------------------------------------ ----------
1696997271 transport lag +00 00:15:01
day(2) to second(0) interval 05/29/2024 00:15:27 05/29/2024 00:14:30 0
1696997271 apply lag +00 00:15:01
day(2) to second(0) interval 05/29/2024 00:15:27 05/29/2024 00:14:30 0
SQL>
更新数据库并确认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#
------------------------ ---------- ----------
IDLE 20 8503
SQL>
清空备库中某表，同时也可以证明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 18503
BLOCK#的定义为：Last processed archived redo log block number
FQ 3: ORA-16857: 成员与重做源断开连接的时间已超过指定的阈值
Solution 1:
The size of Online Redo logs (ORLs) and Standby Redo Logs(SRLs) are different on both primary and standby databases
On Standy:
SQL> select GROUP#,THREAD#,BYTES/1024/1024 from v$log;
GROUP# THREAD# BYTES/1024/1024
---------- ---------- ---------------
1 1 200
2 1 200
3 1 200
SQL> select GROUP#,THREAD# ,BYTES/1024/1024, status from v$standby_log;
GROUP# THREAD# BYTES/1024/1024 STATUS
---------- ---------- --------------- ----------
8 1 50 UNASSIGNED
9 1 50 UNASSIGNED
10 1 50 UNASSIGNED
11 1 50 UNASSIGNED
On Primary:
SQL> select GROUP#,THREAD#,BYTES/1024/1024 from v$log;
GROUP# THREAD# BYTES/1024/1024
---------- ---------- ---------------
1 1 200
3 1 200
2 1 200
SQL> select GROUP#,THREAD# ,BYTES/1024/1024, status from v$standby_log;
GROUP# THREAD# BYTES/1024/1024 STATUS
---------- ---------- --------------- ----------
8 1 50 UNASSIGNED
9 1 50 UNASSIGNED
10 1 50 UNASSIGNED
11 1 50 UNASSIGNED
Drop all standby redologs from both primary and standby and recreate with the same size.
On Primary:
--add the SRLs with the same size as ORLs
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 12 ('/u01/oradata/dev12c/std_redo12.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 13 ('/u01/oradata/dev12c/std_redo13.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 14 ('/u01/oradata/dev12c/std_redo14.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 15 ('/u01/oradata/dev12c/std_redo15.log') SIZE 200M;
--drop the old SRLs
SQL> alter database drop standby logfile group 8;
SQL> alter database drop standby logfile group 9;
SQL> alter database drop standby logfile group 10;
alter database drop standby logfile group 11;
On Standby:
--stop the managed recovery
alter database recover managed standby database cancel;
--add the SRLs with the same size as ORLs
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 12 ('/u01/oradata/dev12c/std_redo12.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 13 ('/u01/oradata/dev12c/std_redo13.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 14 ('/u01/oradata/dev12c/std_redo14.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 15 ('/u01/oradata/dev12c/std_redo15.log') SIZE 200M;
--drop the old SRLs
SQL> alter database drop standby logfile group 8;
SQL> alter database drop standby logfile group 9;
SQL> alter database drop standby logfile group 10;
alter database drop standby logfile group 11;
--Start the managed recovery
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE THROUGH ALL SWITCHOVER DISCONNECT USING CURRENT LOGFILE;
Solution 2:
Modify the value of TransportDisconnectedThreshold, if a delay in the redo transport is expected.
Default value is 30 Seconds
EDIT DATABASE standby SET PROPERTY TransportDisconnectedThreshold='150';
After making the changes check the dataguard status
DGMGRL> show database standby;
Database - dev12cdr
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 2 minutes 39 seconds (computed 16 seconds ago)
Apply Lag: 4 minutes 51 seconds (computed 16 seconds ago)
Average Apply Rate: 2.00 KByte/s
Real Time Query: OFF
Instance(s):
dev12c
Database Status:
SUCCESS
DGMGRL>
8.备库重新启用数据库闪回
验证是否开启闪回
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------------------------
NO
SQL> show parameter db_recovery_file_dest
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
db_recovery_file_dest string D:\app\Administrator\fast_reco
very_area
db_recovery_file_dest_size big integer 12732M
SQL>
数据库已经开启flashback，那么下面步骤可忽略。
如上显示，该数据库未开启flashback，可按下面方法开启。
a. 创建文件夹
D:\app\Administrator\fast_recovery_area
b. 配置 db_recovery_file_dest
SQL> alter system set db_recovery_file_dest_size='5G';
System altered.
SQL> alter system set db_recovery_file_dest='D:\app\Administrator\fast_recovery_area';
System altered.
SQL> show parameter db_recovery_file_dest
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
db_recovery_file_dest string /u01/app/oracle/fast_recovery_
area
db_recovery_file_dest_size big integer 5G
SYS@orcl>
c. 开启闪回
SQL> alter database flashback on;
Database altered.
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------------------------
YES
SYS@orcl>
FQ 1：未配置闪回目录
SQL> alter database flashback on;
alter database flashback on
*
ERROR at line 1:
ORA-38706: Cannot turn on FLASHBACK DATABASE logging.
ORA-38709: Recovery Area is not enabled.
SQL> show parameter db_
FQ 2：日志应用未停止
SQL> alter database flashback on;
alter database flashback on
*
ERROR at line 1:
ORA-01153: an incompatible media recovery is active
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
SQL>
9.Fast-Start Fail Over
配置完成后，FSFO将在以下情况下起作用：
- 主库与 Observer和目标备库 失联时间均超过FastStartFailoverThreshold属性配置阈值（单位为秒）
- 单实例数据库中主实例崩溃
- RAC中所有主实例崩溃
- shutdown abort主库
- 应用程序通过调用DBMS_DG.INITIATE_FS_FAILOVER函数启动FSFO
- Oracle 错误：可以指定启动 FSFO 故障切换的 ORA 错误列表（默认为空）
- Broker 可配置为遇到以下任一条件时启动FSFO：
| Health Condition | Description | 默认启用 |
|---|---|---|
| Datafile Offline | 数据文件由于写错误脱机 | Yes |
| Corrupted Dictionary | 关键数据库对象的字典损坏，该状态可在数据库open时被检测到 | Yes |
| Corrupted Controlfile | 控制文件由于写入错误永久损坏 | Yes |
| Inaccessible Logfile | 由于IO错误，LGWR无法写入日志组的任何成员 | No |
| Stuck Archiver | 由于设备已满或不可用，归档进程无法归档redo log | No |
Observer是一个OCI（Oracle Call Interface）客户端组件，通常运行在独立服务器并监视主库可用性。
Observer 应安装在独立的服务器上，与主、备服务器分开。DGMGRL包含Observer 软件，因此要在独立的服务器上安装DGMGRL。安装方法有以下两种：
- 通过选择Oracle Universal Installer中的Administrator选项来安装完整的Oracle Client Administrator。此安装包括DGMGRL，但不包括OEM代理。这种安装方式可以使用DGMGRL命令但无法使用OEM来管理Observer。
- 安装完整的Oracle数据库软件包，这种安装方式包括DGMGRL。
顾名思义，Observer可以观察主备库之间的活动，决定是否进行FSFO，因此我们需要在连接性最高的服务器上安装Observer。FSFO可能会导致错误的故障转移，即使主库正在运行并且可以在本地访问，也可能会发生FSFO；如果客户端无法访问主库，也可能不发生FSFO。
只有maximum availability mode or maximum performance mode才能启用fast-start failover模式。在maximum availability模式下面，在切换时可以保证无数据丢失，在maximum performance mode下面，会有数据丢失，丢失多少数据由FastStartFailoverLagLimit这个参数来配置。
FSFO过程：
- FSFO之前
DG稳定运行，主库将REDO数据传输到备库，Observer监视整体状态。 - FSFO期间
主库遇到灾难，并且它与Observer和目标备库均失联。在检测到通信中断后，Observer在FastStartFailoverThreshold指定时间内尝试重连主库，如果还是无法连接，且目标备库已准备好进行FSFO，则将发生FSFO。 - FSFO之后
FSFO已完成，并且目标备库以主库角色运行。在修复了原主库之后，Observer将重建与该数据库的连接，并将其恢复为新主库的备库。新主库开始将重做数据传输给它。
FSFO配置前提条件：
- 直到11g为止，数据库保护模式应为“最大可用性”或“最大性能”
- 已配置 Oracle DG Broker，配置方法参考 Oracle DG Broker 进行 SwitchOver & Failover及Failover后恢复主从同步
- LOGXPTMODE属性在最大可用性模式下应为SYNC，在最大性能模式下应为ASYNC，主备库LOGXPTMODE设置必须相同
- 主库和作为FSFO目标的备库必须都启用闪回数据库
- 在Observer上配置tnsnames.ora文件，使其能连接到主库和作为FSFO目标的备库
- 创建一个静态服务名称，以便Observer可以在恢复时自动重启数据库
step 1.查看配置属性
DGMGRL> SHOW CONFIGURATION VERBOSE;
配置 - xiangxun
保护模式: MaxPerformance
成员:
primary - 主数据库
standby - 物理备用数据库
警告: ORA-16809: 检测到成员的多个警告
属性:
FastStartFailoverThreshold = '30'
OperationTimeout = '30'
TraceLevel = 'USER'
FastStartFailoverLagLimit = '30'
CommunicationTimeout = '180'
ObserverReconnect = '0'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'
ObserverOverride = 'FALSE'
ExternalDestination1 = ''
ExternalDestination2 = ''
PrimaryLostWriteAction = 'CONTINUE'
ConfigurationWideServiceName = 'orcl_CFG'
快速启动故障转移: Disabled
配置状态:
WARNING
DGMGRL>
9.1.修改数据库状态
DGMGRL> show database primary;
数据库 - primary
角色: PRIMARY
预期状态: TRANSPORT-ON
实例:
orcl
数据库状态:
SUCCESS
DGMGRL>
DGMGRL> show database standby;
数据库 - standby
角色: PHYSICAL STANDBY
预期状态: APPLY-ON
传输滞后: 9 小时 13 分钟 23 秒 (已在 52 秒之前计算)
应用滞后: 9 小时 13 分钟 23 秒 (已在 52 秒之前计算)
平均应用速率: (未知)
实时查询: ON
实例:
orcl
数据库警告:
ORA-16853: 应用滞后已超出指定阈值
ORA-16855: 传输滞后已超出指定阈值
数据库状态:
WARNING
DGMGRL>
Intended State 有以下几种：
- TRANSPORT-ON
- TRANSPORT-OFF
- APPLY-ON
- APPLY-OFF
| 数据库角色 | 状态 | 描述 |
|---|---|---|
| Primary | TRANSPORT-ON | 设置重做传输服务，以便在打开主库以进行读/写访问时将重做数据传输到备库或远程同步实例。如果这是Oracle RAC数据库，则所有以读/写模式打开的实例都将运行重做传输服务。首次启用时，这是主库的默认状态。 |
| Primary | TRANSPORT-OFF | 重做传输服务在主库上停止。 如果这是Oracle RAC数据库，则重做传输服务不在任何实例上运行。 |
| Physical Standby | APPLY-ON | 备库启用Redo Apply。 如果备库是Oracle RAC数据库，则代理将仅在一个称为Apply实例的备库实例上启动Redo Apply。 如果此实例失败，则代理将自动选择另一个已安装或打开为只读的实例。 然后该新实例将成为Apply实例。 从Oracle Database 12c第2版（12.2.0.1）开始，可以将Redo Apply设置为在每个活动的运行中的物理备用实例上运行。 如果已经设置数据库在多个实例上运行重做应用，则可以使用DG Broker属性ApplyInstances来限制Oracle RAC物理备库上重做应用所涉及的实例数量。 |
| Physical Standby | APPLY-OFF | 备库停用Redo Apply 如果这是Oracle RAC数据库，则在将数据库状态更改为APPLY-ON之前，没有实例运行Apply Services。 |
| Logical Standby | APPLY-ON | 打开逻辑备库并打开逻辑备库保护后，将在逻辑备库上启动SQL Apply。 如果这是一个Oracle RAC数据库，则SQL Apply正在一个实例（apply实例）上运行。 如果此实例失败，则代理将自动选择另一个打开的实例。 这个新实例将成为apply实例。 首次启用时这是逻辑备库的默认状态。 |
| Logical Standby | APPLY-OFF | SQL Apply已停止。 逻辑备库保护功能已打开。 如果这是Oracle RAC数据库，则在将状态更改为APPLY-ON之前，不会运行SQL Apply的实例。 |
主库状态转换
当将主库转换为TRANSPORT-ON状态时，broker将使用配置成员的与重做传输相关的属性以及主库上的RedoRoutes属性来设置重做传输服务。
重做传输服务的设置是通过在主数据库上设置LOG_ARCHIVE_DEST_n和LOG_ARCHIVE_DEST_STATE_n初始化参数，以及在所有数据库（主库或备库）和远程同步实例上设置LOG_ARCHIVE_CONFIG初始化参数来完成的。
当将主库转换为TRANSPORT-OFF状态时，对应的log_archive_dest_state_n将置为RESET状态;
当将主库转换为TRANSPORT-ON状态时，对应的log_archive_dest_state_n将置为ENABLE状态;
# TRANSPORT-OFF
DGMGRL> edit database 'orcl' set state='TRANSPORT-OFF';
2021-03-01T17:42:39.159982+08:00
ALTER SYSTEM SET log_archive_dest_state_2='RESET' SCOPE=BOTH;
# TRANSPORT-ON
DGMGRL> edit database 'orcl' set state='TRANSPORT-ON';
2021-03-01T17:42:58.926310+08:00
ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH;
物理备库状态转换
在将物理备库转换为APPLY-ON状态时，broker将使用与Redo Apply相关的属性指定的选项启动Redo Apply。 如果备库是Oracle RAC数据库，则代理将在一个称为Apply实例的备用实例上启动Redo Apply。
从Oracle Database 12c第2版（12.2.0.1）开始，可以将Redo Apply设置为在多个活动运行的物理备用实例上运行。 （此功能要求备库具有Oracle Active Data Guard选项的许可证。）如果已经设置数据库在多个实例上运行Redo Apply，则可以使用Data Guard Broker属性ApplyInstances限制数量。
当物理备库转换为APPLY-OFF状态时，broker停止Redo Apply。
# APPLY-OFF
DGMGRL> edit database 'orcladg' set state='APPLY-OFF';
Succeeded.
2021-03-02T09:46:48.776536+08:00
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
2021-03-02T09:46:48.777132+08:00
MRP0: Background Media Recovery cancelled with status 16037
2021-03-02T09:46:48.889176+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcladg/orcladg/trace/orcladg_pr00_2632.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 7993612
2021-03-02T09:46:49.040882+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcladg/orcladg/trace/orcladg_pr00_2632.trc:
ORA-16037: user requested cancel of managed recovery operation
2021-03-02T09:46:49.142033+08:00
MRP0: Background Media Recovery process shutdown (orcladg)
2021-03-02T09:46:49.777718+08:00
Managed Standby Recovery Canceled (orcladg)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
# APPLY-ON
DGMGRL> edit database 'orcladg' set state='APPLY-ON';
Succeeded.
2021-03-02T09:47:46.674256+08:00
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT NODELAY
2021-03-02T09:47:46.674819+08:00
Attempt to start background Managed Standby Recovery process (orcladg)
Starting background process MRP0
2021-03-02T09:47:46.691256+08:00
MRP0 started with pid=56, OS id=2899
2021-03-02T09:47:46.692433+08:00
MRP0: Background Managed Standby Recovery process started (orcladg)
2021-03-02T09:47:51.718042+08:00
Started logmerger process
2021-03-02T09:47:51.737502+08:00
Managed Standby Recovery starting Real Time Apply
2021-03-02T09:47:51.788006+08:00
Parallel Media Recovery started with 2 slaves
2021-03-02T09:47:52.201813+08:00
Media Recovery Waiting for thread 1 sequence 235 (in transit)
2021-03-02T09:47:52.202522+08:00
Recovery of Online Redo Log: Thread 1 Group 5 Seq 235 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/orcladg/redo05.log
2021-03-02T09:47:52.699581+08:00
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT NODELAY
9.2.设置故障转移目标
step 1.只能为当前主库设置一个目标转移备库，若只有一个备库，此步骤可忽略。
DGMGRL> enable fast_start failover
在潜在数据丢失模式中启用.
DGMGRL>
启用 Fast-Start Fail Over ，默认第一个备库未优先切换为从库。
DGMGRL> SHOW CONFIGURATION;
配置 - xiangxun
保护模式: MaxPerformance
成员:
primary - 主数据库
警告: ORA-16824: 检测到数据库的多个警告, 包括与快速启动故障转移相关的警告
standby - (*) 物理备用数据库
警告: ORA-16824: 检测到数据库的多个警告, 包括与快速启动故障转移相关的警告
快速启动故障转移: 在潜在数据丢失模式中启用
配置状态:
WARNING (状态已在 22 秒前更新)
DGMGRL>
FQ 1：未开启闪回数据库功能
DGMGRL> enable fast_start failover; Warning: ORA-16827: Flashback Database is disabled Enabled in Potential Data Loss Mode.
FQ 2: ORA-16829: 快速启动故障转移配置滞后
ORA-16819: 未启动快速启动故障转移观察程序
a. 关闭fast_start failover (可选）
DGMGRL> disable fast_start failover
已禁用。
DGMGRL>
b. 重新开启fast_start failover (可选）
DGMGRL> enable fast_start failover
Enabled.
c. 备库执行取消同步语句，全部使用DGMGRL工具管理
SQL> alter database recover managed standby database cancel;
备库执行实施同步语句
SQL> alter database recover managed standby database using current logfile disconnect from session;
查看数据库的状态
DGMGRL> show database standby;
数据库 - standby
角色: PHYSICAL STANDBY
预期状态: APPLY-ON
传输滞后: 10 小时 23 分钟 26 秒 (已在 47 秒之前计算)
应用滞后: 10 小时 23 分钟 26 秒 (已在 47 秒之前计算)
平均应用速率: (未知)
实时查询: OFF
实例:
orcl
数据库错误:
ORA-16766: 重做应用已停止
数据库警告:
ORA-16853: 应用滞后已超出指定阈值
ORA-16855: 传输滞后已超出指定阈值
数据库状态:
ERROR
DGMGRL>
d. 对备库使用DGMGRL重启APLLY
DGMGRL> edit database standby set state="APPLY-OFF";
成功。
DGMGRL> edit database standby set state="APPLY-ON";
成功。
DGMGRL>
在使用了DGMGRL来管理Dataguard时，就千万不要再使用SQLPLUS命令行来管理了，所有的操作必须都要在DGMGRL下进行修改配置，否则会造成参数冲突，导致问题排查困难，造成不必要的劳动
step 2.修改目标转移备库，需要先禁用FSFO，改完后再启用
DGMGRL> DISABLE FAST_START FAILOVER
Disabled.
DGMGRL>
修改转移备库为Standby
DGMGRL> EDIT DATABASE primary SET PROPERTY FASTSTARTFAILOVERTARGET=standby;
Property "faststartfailovertarget" updated
DGMGRL> EDIT DATABASE standby SET PROPERTY FASTSTARTFAILOVERTARGET=primary;
Property "faststartfailovertarget" updated
DGMGRL>
step 3.设置保护模式与LogXptMode
DGMGRL> SHOW CONFIGURATION verbose
配置 - ditie
保护模式: MaxPerformance
成员:
primary - 主数据库
standby - 物理备用数据库
警告: ORA-16809: 检测到成员的多个警告
属性:
FastStartFailoverThreshold = '30'
OperationTimeout = '30'
TraceLevel = 'USER'
FastStartFailoverLagLimit = '30'
CommunicationTimeout = '180'
ObserverReconnect = '0'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'
ObserverOverride = 'FALSE'
ExternalDestination1 = ''
ExternalDestination2 = ''
PrimaryLostWriteAction = 'CONTINUE'
ConfigurationWideServiceName = 'orcl_CFG'
快速启动故障转移: Disabled
配置状态:
WARNING
LOGXPTMODE属性在最大可用性模式下应为SYNC，在最大性能模式下应为ASYNC，主备库LOGXPTMODE设置必须相同
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
错误: ORA-16627: 操作不允许, 因为所有成员都不再支持保护模式
失败。
DGMGRL>
最大保护和最高可以的前提条件是日志传输模式为SYNC，所以我们要先修改日志传输模式。
因为考虑到以后要进行故障转移，所以需要将所有的数据库的LogXptMode都设置为SYNC。
DGMGRL> EDIT DATABASE standby SET PROPERTY LogXptMode='SYNC';
已更新属性 "logxptmode"
DGMGRL> EDIT DATABASE primary SET PROPERTY LogXptMode='SYNC';
已更新属性 "logxptmode"
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
成功。
DGMGRL> SHOW CONFIGURATION verbose
配置 - ditie
保护模式: MaxAvailability
成员:
primary - 主数据库
警告: ORA-16629: 数据库报告的保护级别与保护模式的保护级别不同
standby - 物理备用数据库
属性:
FastStartFailoverThreshold = '30'
OperationTimeout = '30'
TraceLevel = 'USER'
FastStartFailoverLagLimit = '0'
CommunicationTimeout = '180'
ObserverReconnect = '0'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'
ObserverOverride = 'FALSE'
ExternalDestination1 = ''
ExternalDestination2 = ''
PrimaryLostWriteAction = 'CONTINUE'
ConfigurationWideServiceName = 'orcl_CFG'
快速启动故障转移: Disabled
配置状态:
WARNING
DGMGRL>
step 4. 设置FSFO阈值
如果主库与 Observer和目标备库失联时间均超过FastStartFailoverThreshold属性配置阈值（单位为秒），将启动FSFO。
FastStartFailoverThreshold表示，Observer和目标备库 在检测到主库不可用后、希望等多少秒才启动FSFO。再此期间，它们会尝试重连主库。
默认值为30秒，最小6秒。
DGMGRL> edit configuration set property faststartfailoverthreshold=300;
已更新属性 "faststartfailoverthreshold"
DGMGRL>
step 5. 设置最大可接受延迟时间
FastStartFailoverLagLimit表示，自动故障转移允许的最大数据丢失量（单位为秒），仅在最高性能保护模式时才可使用。
FastStartFailoverLagLimit作为DG可接受的最大延迟时间，备库的apply lag只有在此限制之内，才允许FSFO。
如果无法维持已配置的数据丢失保证，主库上的redo生成将停止。为了避免长时间停顿，Observer或者目标备库可能会在第一次记录到无法发生FSFO之后，允许主库继续生成redo。此时若主库故障，将无法发生FSFO。
默认值为30秒，最小值为10秒。
DGMGRL> edit configuration set property faststartfailoverlaglimit=50;
已更新属性 "faststartfailoverlaglimit"
DGMGRL>
step 6.设置FastStartFailoverPmyShutdown属性
默认为true，表示在FastStartFailoverThreshold属性指定的秒数过去之后，使用ABORT选项关闭主数据库。
如果不希望由于主库redo生成停止 或 主库与Observer和目标备库 失联时间超过FastStartFailoverThreshold指定时间而在触发FSFO后关闭主库，需要将其设置为假。
DGMGRL> edit configuration set property FastStartFailoverThreshold='false';
错误: ORA-16790: 可配置属性的值无效
失败。
DGMGRL>
step 7.设置自动恢复数据库属性
如果FastStartFailoverAutoReinstate属性设置为TRUE，在原主库故障修复后，会自动尝试将其恢复为新主库的备库。
DGMGRL> EDIT CONFIGURATION SET PROPERTY FASTSTARTFAILOVERAUTOREINSTATE=TRUE;
已更新属性 "faststartfailoverautoreinstate"
DGMGRL>
step 9.启用fast_start故障转移
DGMGRL> enable fast_start failover;
Enabled in Zero Data Loss Mode.
DGMGRL>
step 10.查看FSFO配置
DGMGRL> show fast_start failover
快速启动故障转移: 在潜在数据丢失模式中启用
保护模式: MaxAvailability
滞后限制: 50 秒
阈值: 300 秒
活动目标: standby
潜在目标: "standby"
standby 有效
观察程序: (无)
关闭主数据库: TRUE
自动恢复: TRUE
观察程序重新连接: (无)
观察程序覆盖: FALSE
可配置的故障转移条件
健康状况:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Write Errors YES
Oracle 错误条件:
(无)
DGMGRL>
10.配置Observer（可选）
同时ob机器需要安装好同版本的oracle软件
ObserverConnectIdentifier用于指定Observer应如何连接并监视主备库。如果希望Observer使用不同于发送重做数据连接串的连接标识符，请为主库和目标备库设置此属性（可选）。
DGMGRL> start observer
[W000 2024-05-08T09:25:45.030+08:00] FSFO target standby is standby01
Observer 'primary' started
[W000 2024-05-08T09:25:45.169+08:00] Observer trace level is set to USER
[W000 2024-05-08T09:25:45.169+08:00] Try to connect to the primary.
[W000 2024-05-08T09:25:45.169+08:00] Try to connect to the primary primary.
[W000 2024-05-08T09:25:45.238+08:00] The standby standby01 is ready to be a FSFO target
[W000 2024-05-08T09:25:45.238+08:00] Connection to the primary restored!
[W000 2024-05-08T09:25:47.238+08:00] Disconnecting from database primary.
通过登录到观察者计算机并运行DGMGRL，最多启动三个观察者。以具有SYSDG或SYSDBA权限的用户身份连接到配置，然后发出Start observer命令。请注意，在发出命令后将不会得到DGMGRL提示。
DGMGRL> show observer;
配置 - ditie
无观察程序。
DGMGRL>
启动OBSERVER后台进程
DGMGRL> CONNECT sysdg@primary;
Password:
已连接到 "primary"
以 SYSDG 身份连接。
DGMGRL>
DGMGRL> START OBSERVER observer1 IN BACKGROUND FILE IS D:\app\Administrator\broker\fsfo.dat LOGFILE IS D:\app\Administrator\broker\observer.log CONNECT IDENTIFIER IS primary
已连接到 "primary"
已使用连接标识符 "primary" 提交命令 "START OBSERVER"
DGMGRL> show observer
配置 - ditie
主: primary
活动目标: standby
观察程序 "observer1" - 主
主机名: primary-database
上次对主观察程序进行试通: 1 秒前
上次对目标进行试通: 1 秒前
DGMGRL>
出于安全考虑，Oracle建议使用此命令格式；没有可见的凭据。这种做法可防止系统上的其他用户使用实用程序（例如UNIX ps实用程序）来显示连接凭据。它还防止明文密码在用户的终端上可见。
从脚本启动观察程序时，Oracle建议您使用支持“connect/”的方法，这样数据库连接凭据就不必嵌入脚本中。如果您选择使用客户端Oracle钱包作为安全的外部密码存储，请确保添加主数据库和快速启动故障切换目标备用数据库的凭据。添加每个数据库的凭据时指定的数据库连接字符串必须与ObserverConnectIdentifer或DGConnectIdentifier数据库属性匹配。
当启动多个观察程序时，启用快速启动故障切换后，一个观察程序是主观察程序，其余观察程序是备份观察程序。只有主观察者才能与Data
Guard代理协调快速启动故障切换。如果主数据库和目标备用数据库保持连接，但与主观察器的连接丢失，则代理会尝试指定一个备份观察器作为新的主观察者。
停止observer
DGMGRL> stop observer observer1
观察程序已停止。
DGMGRL> show observer
配置 - ditie
无观察程序。
DGMGRL>
启动 observer
DGMGRL> start observer "observer1"
[W000 2024-05-29T11:00:50.990+08:00] FSFO target standby is standby
观察程序 'observer1' 已启动
[W000 2024-05-29T11:00:51.085+08:00] Observer trace level is set to USER
[W000 2024-05-29T11:00:51.085+08:00] Try to connect to the primary.
[W000 2024-05-29T11:00:51.085+08:00] Try to connect to the primary primary.
[W000 2024-05-29T11:00:51.105+08:00] The standby standby is ready to be a FSFO target
[W000 2024-05-29T11:00:52.125+08:00] Connection to the primary restored!
[W000 2024-05-29T11:00:54.141+08:00] Disconnecting from database primary.
^C
新会话查看 observer
DGMGRL> show observer
配置 - ditie
主: primary
活动目标: standby
观察程序 "observer1" - 主
主机名: primary-database
上次对主观察程序进行试通: 9 秒前
上次对目标进行试通: 9 秒前
DGMGRL>
11.测试
11.1.使用 DG Broker 进行 SwitchOver
step 1.连接到其中一个数据库
[oracle@dg admin]$ dgmgrl sys/oracle@tnsslnngk;
step 2.查看配置
DGMGRL> SHOW CONFIGURATION
配置 - ditie
保护模式: MaxAvailability
成员:
primary - 主数据库
错误: ORA-16820: 快速启动故障转移观察程序不再对此数据库进行观察
standby - (*) 物理备用数据库
错误: ORA-16820: 快速启动故障转移观察程序不再对此数据库进行观察
快速启动故障转移: 在潜在数据丢失模式中启用
配置状态:
ERROR (状态已在 48 秒前更新)
DGMGRL>
step 3.主库切换到Standby
DGMGRL> switchover to standby
立即执行切换, 请稍候...
操作要求连接数据库 "standby"
正在连接...
已连接到 "standby"
以 SYSDG 身份连接。
新的主数据库 "standby" 正在打开...
操作要求启动数据库 "primary" 上的实例 "orcl"
正在启动实例 "orcl"...
已连接到空闲例程。
ORACLE 例程已经启动。
已连接到 "primary"
数据库装载完毕。
数据库已经打开。
已连接到 "primary"
切换成功, 新的主数据库为 "standby"
DGMGRL>
从库会自动启动日志应用进程
SQL> select open_mode,protection_mode,database_role,switchover_status from v$database;
OPEN_MODE PROTECTION_MODE DATABASE_ROLE SWITCHOVER_STATUS
---------------------------------------- ---------------------------------------- -------------------------------- ----------------------------------------
READ WRITE MAXIMUM AVAILABILITY PRIMARY TO STANDBY
SQL> select process,status from v$managed_standby;
PROCESS STATUS
------------------ ------------------------
DGRD ALLOCATED
ARCH CLOSING
DGRD ALLOCATED
ARCH CLOSING
ARCH CLOSING
ARCH CLOSING
DGRD ALLOCATED
LGWR WRITING
已选择 8 行。
SQL>
完成主从切换
11.2.使用 DG Broker 进行 Failover
step 1.主库故障
shutdown abort
step 2.检查下目标库延迟
DGMGRL> show database primary
数据库 - primary
角色: PHYSICAL STANDBY
预期状态: APPLY-ON
传输滞后: 0 秒 (已在 0 秒之前计算)
应用滞后: 0 秒 (已在 0 秒之前计算)
平均应用速率: 1.00 KB/秒
实时查询: ON
实例:
orcl
数据库状态:
SUCCESS
DGMGRL>
step 3.DGMGRL 连接目标库，failover 切换
DGMGRL> failover to primary
立即执行故障转移, 请稍候...
故障转移成功, 新的主数据库为 "primary"
DGMGRL>
查看切换后配置信息
DGMGRL> show configuration
配置 - ditie
保护模式: MaxAvailability
成员:
primary - 主数据库
警告: ORA-16857: 成员与重做源断开连接的时间已超过指定的阈值
standby - (*) 物理备用数据库 (disabled)
ORA-16661: 需要恢复备用数据库
快速启动故障转移: 在潜在数据丢失模式中启用
配置状态:
WARNING (状态已在 122 秒前更新)
DGMGRL>
SQL> select open_mode,protection_mode,database_role,switchover_status from v$database;
OPEN_MODE PROTECTION_MODE DATABASE_ROLE SWITCHOVER_STATUS
---------------------------------------- ---------------------------------------- -------------------------------- ----------------------------------------
READ WRITE MAXIMUM AVAILABILITY PRIMARY NOT ALLOWED
SQL>
如手工切换时failover有两类，使用DG Broker也有两种failover方法
- Complete Failover（默认）：尝试先将所有重做日志应用到备库，最大程度地减少数据丢失。
- Immediate Failover ：不再对备库进行日志应用，立刻进行切换。
DGMGRL> FAILOVER TO database-name;
# 或者
DGMGRL> FAILOVER TO database-name IMMEDIATE;
step 4.Failover后恢复主从关系
为使REINSTATE命令成功执行，故障转移之前必须已在原主库（新备库）上启用闪回，并且必须有足够的闪回和归档日志。
a. 启动到mount状态
如果有开机自启动的，startup过程中会报错 “ORA-16649: possible failover to another database prevents this database from being opened”，会发现只能起到mount状态，没关系，继续后面的操作。
startup mount
b. 恢复主从关系
连接到代理配置中的任何数据库（要恢复的数据库除外）时，执行：
DGMGRL> reinstate database standby;
正在恢复数据库 "standby", 请稍候...
已成功恢复数据库 "standby"
DGMGRL>
如果能完成，它将变为新主库的备库。如果失败，其状态将更改为 “ORA-16795: the standby database needs to be re-created”, 这种情况下，只能重新同步备库。
step 5.查看切换后配置信息
DGMGRL> show configuration
配置 - ditie
保护模式: MaxAvailability
成员:
primary - 主数据库
standby - (*) 物理备用数据库
快速启动故障转移: 在潜在数据丢失模式中启用
配置状态:
SUCCESS (状态已在 37 秒前更新)
DGMGRL>
Fast-Start Fail Over 测试
step 1.从机上开启 Obserser
DGMGRL> start observer
[W000 2024-05-29T15:31:09.174+08:00] FSFO target standby is standby
观察程序 'primary-database' 已启动
[W000 2024-05-29T15:31:09.332+08:00] Observer trace level is set to USER
[W000 2024-05-29T15:31:09.332+08:00] Try to connect to the primary.
[W000 2024-05-29T15:31:09.332+08:00] Try to connect to the primary primary.
[W000 2024-05-29T15:31:09.332+08:00] The standby standby is ready to be a FSFO target
[W000 2024-05-29T15:31:10.355+08:00] Connection to the primary restored!
[W000 2024-05-29T15:31:12.379+08:00] Disconnecting from database primary.
step 2.查看配置信息
DGMGRL> show configuration
配置 - ditie
保护模式: MaxAvailability
成员:
primary - 主数据库
standby - (*) 物理备用数据库
快速启动故障转移: 在潜在数据丢失模式中启用
配置状态:
SUCCESS (状态已在 58 秒前更新)
DGMGRL> show observer
配置 - ditie
主: primary
活动目标: standby
观察程序 "primary-database" - 主
主机名: primary-database
上次对主观察程序进行试通: 0 秒前
上次对目标进行试通: 3 秒前
DGMGRL> show fast_start failover
快速启动故障转移: 在潜在数据丢失模式中启用
保护模式: MaxAvailability
滞后限制: 50 秒
阈值: 300 秒
活动目标: standby
潜在目标: "standby"
standby 有效
观察程序: primary-database
关闭主数据库: TRUE
自动恢复: TRUE
观察程序重新连接: (无)
观察程序覆盖: FALSE
可配置的故障转移条件
健康状况:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Write Errors YES
Oracle 错误条件:
(无)
DGMGRL>
step 3.将主库给shutdown abort
step 4.查看 OBServer 日志
[W000 2024-05-29T15:33:24.968+08:00] Primary database cannot be reached.
[W000 2024-05-29T15:34:07.698+08:00] Fast-Start Failover threshold has not exceeded. Retry for the next 300 seconds
[W000 2024-05-29T15:34:08.717+08:00] Try to connect to the primary.
[W000 2024-05-29T15:38:27.151+08:00] Primary database cannot be reached.
[W000 2024-05-29T15:38:27.151+08:00] Fast-Start Failover threshold has expired.
[W000 2024-05-29T15:38:27.151+08:00] Try to connect to the standby.
[W000 2024-05-29T15:38:27.151+08:00] Making a last connection attempt to primary database before proceeding with Fast-Start Failover.
[W000 2024-05-29T15:38:27.151+08:00] Check if the standby is ready for failover.
[S002 2024-05-29T15:38:27.168+08:00] Fast-Start Failover started...
2024-05-29T15:38:27.168+08:00
正在为数据库 "standby" 启动快速启动故障转移...
[S002 2024-05-29T15:38:27.168+08:00] Initiating Fast-start Failover.
立即执行故障转移, 请稍候...
故障转移成功, 新的主数据库为 "standby"
2024-05-29T15:44:59.655+08:00
[S002 2024-05-29T15:44:59.657+08:00] Fast-Start Failover finished...
[W000 2024-05-29T15:44:59.657+08:00] Failover succeeded. Restart pinging.
[W000 2024-05-29T15:44:59.671+08:00] Primary database has changed to standby.
[W000 2024-05-29T15:44:59.671+08:00] Try to connect to the primary.
[W000 2024-05-29T15:44:59.671+08:00] Try to connect to the primary standby.
[W000 2024-05-29T15:44:59.766+08:00] The standby primary needs to be reinstated
[W000 2024-05-29T15:44:59.766+08:00] Try to connect to the new standby primary.
[W000 2024-05-29T15:44:59.766+08:00] Connection to the primary restored!
[W000 2024-05-29T15:45:01.787+08:00] Disconnecting from database standby.
[W000 2024-05-29T15:45:26.036+08:00] Connection to the new standby restored!
step 5.查看当前配置
C:\Users\Administrator>dgmgrl sys/Oracle12@standby
DGMGRL for 64-bit Windows: Release 19.0.0.0.0 - Production on ??? 5? 29 15:42:54 2024
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
欢迎使用 DGMGRL, 要获取有关信息请键入 "help"。
已连接到 "STANDBY"
以 SYSDBA 身份连接。
DGMGRL> show configuration
配置 - ditie
保护模式: MaxAvailability
成员:
standby - 主数据库
错误: ORA-16825: 检测到数据库的多个错误或警告, 包括与快速启动故障转移相关的错误或警告
primary - (*) 物理备用数据库 (disabled)
ORA-16661: 需要恢复备用数据库
快速启动故障转移: 在潜在数据丢失模式中启用
配置状态:
ERROR (状态已在 8 秒前更新)
DGMGRL> show observer
配置 - ditie
主: standby
活动目标: primary
观察程序 "primary-database" - 主
主机名: primary-database
上次对主观察程序进行试通: (未知)
上次对目标进行试通: (未知)
DGMGRL> SHOW FAST_START FAILOVER;
快速启动故障转移: 在潜在数据丢失模式中启用
保护模式: MaxAvailability
滞后限制: 50 秒
阈值: 300 秒
活动目标: primary
潜在目标: "primary"
primary 无效 - 成员已禁用
观察程序: primary-database
关闭主数据库: TRUE
自动恢复: TRUE
观察程序重新连接: (无)
观察程序覆盖: FALSE
可配置的故障转移条件
健康状况:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Write Errors YES
Oracle 错误条件:
(无)
DGMGRL>
step 6.查看备库 standby 状态
SQL> select open_mode,protection_mode,database_role,switchover_status from v$database;
OPEN_MODE PROTECTION_MODE DATABASE_ROLE SWITCHOVER_STATUS
---------------------------------------- ---------------------------------------- -------------------------------- ----------------------------------------
READ WRITE MAXIMUM AVAILABILITY PRIMARY NOT ALLOWED
SQL>
step 7.恢复 primary 数据库，启动数据库到 mount 状态
step 8.查看 OBServer 日志
[W000 2024-05-29T15:50:54.986+08:00] New primary is now ready to reinstate.
[W000 2024-05-29T15:50:55.996+08:00] Issuing REINSTATE command.
2024-05-29T15:50:55.996+08:00
正在为数据库 "primary" 启动恢复过程...
正在恢复数据库 "primary", 请稍候...
[W000 2024-05-29T15:51:06.090+08:00] The standby primary is ready to be a FSFO target
已成功恢复数据库 "primary"
2024-05-29T15:51:35.731+08:00
[W000 2024-05-29T15:51:36.459+08:00] Successfully reinstated database primary.
step 9.查看 primary 状态
SQL> select open_mode,protection_mode,database_role,switchover_status from v$database;
OPEN_MODE PROTECTION_MODE DATABASE_ROLE SWITCHOVER_STATUS
---------------------------------------- ---------------------------------------- -------------------------------- ----------------------------------------
READ ONLY WITH APPLY MAXIMUM AVAILABILITY PHYSICAL STANDBY NOT ALLOWED
SQL>
当主库物理故障恢复后，从新进行切换回主库。
测试用例
| 测试环境描述： | ||||
|---|---|---|---|---|
| 1 | 操作系统： | WIndows Server 2022 | ||
| 2 | Oracle Cluster版本： | |||
| 3 | Oracle数据库版本： | 19.3.0 | ||
| 4 | 架构： | Data guard + DG_broker + FSFO | ||
| — | — | — | — | — |
| 编号 | 描述 | 测试动作 | 预期结果 | 实际结果/备注 |
| 1 | 计划外主库实例挂掉 | kill -9 pid_of_smon 或者 SQL > shutdown abort |
Primary instance crash，standby instance 进行切换。 切换后，原standby instance成primary instance. 在dgmgrl控制台可以看到ORA-16829: fast-start failover configuration is lagging，且原primary instance可以看到ORA-16661: the standby database needs to be reinstated |
2分钟左右完成切换 |
| 2 | 计划外备库实例挂掉 | kill -9 pid_of_smon 或者 SQL > shutdown abort |
dgmgrl控制台主库报错ORA-16810: multiple errors or warnings detected for the database，备库报错ORA-01034: ORACLE not available | 备库挂掉，应用不受影响 |
| 3 | 计划内关闭主库 | SQL > shutdown immediate | 主备库不切换，在dgmgrl控制台可以看到主库报错：Error: ORA-01034: ORACLE not available，备库提示信息：(*) Physical standby database | 计划内维护 |
| 4 | 计划内关闭备库 | SQL > shutdown immediate | 主备库不切换，在dgmgrl控制台可以看到主库报错：ORA-16829: fast-start failover configuration is lagging，备库提示信息：(*) Physical standby database (disabled) | 计划内维护 |
| 5 | 重新启动失败数据库实例 | SQL > startup | 启动原primary库之后，自动变成physical standby角色。在完成Clearing online log之后，进行mrp的介质恢复。 在dgmgrl控制台，看到原primary状态从ORA-16661: the standby database needs to be reinstated，变成ORA-16657: reinstatement of database in progress，继而变成ORA-16829: fast-start failover configuration is lagging，待lag补齐之后最终变成Physical standby database |
重启的原primary库恢复正常大约5~10分钟，重启期间应用完全不受影响。 |
| 6 | 主库监听挂掉 | kill -9 pid_of_listener | 应用无法连接。 主库和备库之间如果没有lag，处于standby redolog的recovery，则不受影响。主库和备库之间如果有lag，则当备库启动时，需要使用archivelog的recovery，就会报错 ORA-01196: file n is inconsistent due to a failed media recovery session。Dgmgrl控制台报错备库 ORA-16664: unable to receive the result from a database |
监听挂掉，应用无法连接数据库，需要手工启动监听。 注：已经添加自动重启监听脚本，发现监听宕掉，自动拉起监听。 |
| 7 | 备库监听挂掉 | kill -9 pid_of_listener | 应用正常连接。 主库和备库之间如果没有lag，处于standby redolog的recovery，则不受影响。 主库和备库之间如果有lag，dgmgrl控制台主库报错：ORA-16810: multiple errors or warnings detected for the database，备库报错：ORA-12541: TNS:no listener 备库启动时，需要使用archivelog的recovery，就会报错 ORA-01196: file n is inconsistent due to a failed media recovery session。Dgmgrl控制台报错备库 ORA-16664: unable to receive the result from a database |
应用连接正常，需要手工启动备库监听 注：已经添加自动重启监听脚本，发现监听宕掉，自动拉起监听。 |
| 8 | 计划内切换主备库 | DGMGRL> switchover to ‘fltrec_dg’; | 在切换期间，应用连接报错ORA-16456: switchover to standby in progress or completed。 切换后，应用恢复正常。 |
大 |
相关视图
SELECT fs_failover_status,
fs_failover_current_target,
fs_failover_threshold,
fs_failover_observer_present,
fs_failover_observer_host
FROM v$database;
最后修改时间：2024-06-04 10:57:03
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
