Oracle 12c Dataguard 单机版部署

欢迎关注公众号：一介IT
本站博文抢先发布在公众号。

摘自个人网站，文章原文地址 https://l080l.com/oracle/deploy/singledg12c.html

本文 4.8万 字。
本文有不同方式部署DG，如果是实验，每做完一个方式建议做好快照，请按照目录阅读。
相关推荐【Oracle 12c Dataguard RAC版部署】

1. Dataguard介绍

1.1 概念

Data Guard是保证企业数据的高可用性(high availability)、数据保护(data protection)以及灾难恢复(disaster recovery)的集成化灾难恢复解决方案。该技术可以维护生产数据库一个或多个同步备份，由一个生产数据库和若干个备用数据库组成，并形成一个独立的、易于管理的数据保护方案。Data Guard备用数据库可以与生产系统位于相同的数据中心，也可以是在地理位置上分布较远的的远程灾难备份中心。

1.2 原理

Data Guard的基本原理是：当某次事务处理对生产数据库中的数据作出更改时，Oracle将在联机重做日志文件中记录此次更改。在Data Guard中，除了把日志记录到本地的联机日志文件和归档日志文件中外，还通过网络，把日志信息发送到远程的备用数据库服务器上。这个备用日志文件写入过程可以是实时同步的，以实现零数据丢失(最大保护模式)；也可以是异步的，以减少对网络带宽的压力(最大可用性模式)；或者是通过归档日志文件的批量传输模式，以减少对生产系统的性能影响(最大性能模式)。当备份数据库接收到日志信息时，Data Guard可以自动利用日志信息实现数据的同步。当主数据库打开并处于活动状态时，备份数据库可以执行恢复操作；如果主数据出现了故障，备用数据库即可以被激活并接管生产数据库的工作。

1.3 特点

• 需要冗余的服务器设备，该模式需要有冗余的服务器硬件，硬件成本较高。
• 需要冗余的存储设备，主机和备机都需要同样的存储空间，成本较高。
• 安装配置比较复杂，该模式比单节点、单实例的模式配置复杂一些，需要更多的配置步骤。
• 管理维护成本高，该模式对维护人员的要求较高，维护成本高。
• 具备一定的容灾特性，当主机数据库不可用，可以把数据库系统切换到备机上，具备容灾的功能。
• 备机可以用作只读查询，备机可以切换到只读状态供报表之类的查询操作，减轻主机的压力。

1.4 搭建DG方式

Data Guard备库按照从生产数据库传输过来的日志处理方法的不同分为物理备库、逻辑备库和快照备库。

1.4.1 物理备库

(三种方法：1、RMAN的Duplicate; 2、RMAN的备份恢复; 3、DBCA )。

备份数据库处于mount状态下，直接利用数据恢复技术，把日志文件中记录的数据变更应用在备份数据库中，从而实现与生产数据库的数据同步，在进行数据同步的时候，物理备份数据库是不能打开的、也无法提供数据查询等服务；物理备用数据库也可以通过只读的方式打开，此时就只能接收日志文件，而无法进行数据的同步。

1.4.2 逻辑备库

数据库是处于正常打开状态，当它接收到新的日志信息后，利用日志挖掘器的功能，把日志中记录的变更信息转换成具体的SQL语句，并在逻辑备用数据库上执行这些SQL语句，从而实现与生产数据库的数据同步。逻辑备份数据支持在数据同步时，进行数据的查询、报表等操作。Oracle从9i R2开始支持逻辑备份数据库。

1.4.3 快照备库

可以暂时将物理备份数据库转换为可更新的数据库，快照备份数据不会立马应用接收到的日志文件，设一个时间点，一次性转换。

1.5 备库数据保护级别

Oracle Data Guard 支持多种级别的数据保护模式：最大性能模式，最大可用性模式，最大保护模式。分别对应于“重要信息系统灾难恢复指南”中的5级，5级6级自适应，6级的数据保护级别。其中对应6级的最大保护模式可以实现实时数据实时同步和0数据丢失。另外，Oracle Data Guard 可以设置延时应用时间窗口，从而防范错误操作、黑客攻击等人为错误导致的数据损坏。

1.5.1 保护模式和重做传输

要确定适当的保护模式，企业需要根据用户对系统响应时间的要求来估量它们对数据保护的业务要求。下表从数据丢失风险的角度概述了各种模式的适用性。

1.5.2 最大保护模式

最大保护模式为主数据库提供了最高水平的数据保护，从而确保一个全面的零数据丢失的灾难恢复解决方案。当在最大保护模式下运行时，重做记录由日志写入器 (LGWR) 进程从主数据库同步地传输到备用数据库，并且直到确认事务数据在至少一个备用服务器上的磁盘上可用时，才在主数据库上提交事务。建议这种模式应至少配置两个备用数据库。当最后参与的备用数据库不可用时，主数据库上的处理将停止。这就确保了当主数据库与其所有备用数据库失去联系时，不会丢失事务。由于重做传输的同步特性，这种最大保护模式可能潜在地影响主数据库响应时间。可以通过配置一个低延迟网络，并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。需要这种最大保护模式的企业有股票交易所、货币交易所、金融机构等。

1.5.3 最大可用性模式

最高可用性模式拥有仅次于最高水平的主数据库数据可用性。如同最大保护模式一样，重做数据由 LGWR 从主数据库同步地传输到备用数据库，直到确认事务数据在备用服务器的磁盘上可用时，事务才在主数据库上完成。不过，在这种模式下（与最大保护模式不同），如果最后参与的备用数据库变为不可用，例如由于网络连接问题，处理将在主数据库上继续进行。备用数据库与主数据库相比，可能暂时落在后面，但当它再次变为可用时，备用数据库将使用主数据库上累积的归档日志自动同步，而不会丢失数据。由于同步重做传输，这种保护模式可潜在地影响响应时间和吞吐量。可以通过配置一个低延迟网络，并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。最高可用性模式适用于想要确保获得零数据丢失保护，但不想让生产数据库受网络/备用服务器故障影响的企业。如果又一个故障随后影响了生产数据库，然后最初的网络/备用服务器故障得到解决，那么这些企业将接受数据丢失的可能性。

1.5.4 最高性能模式

最高性能模式是默认的保护模式。它与最高可用性模式相比，提供了稍微少一些的主数据库数据保护，但提供了更高的性能。在这种模式下，当主数据库处理事务时，重做数据由 LGWR 进程异步传输到备用数据库上。另外，也可以将主数据库上的归档器进程 (ARCH) 配置为在这种模式下传输重做数据。在任何情况下，均先完成主数据库上的写操作，主数据库的提交操作不等待备用数据库确认接收。如果任意备用目标数据库变为不可用，则处理将在主数据库上继续进行，这对性能只有很小的影响或没有影响。在主数据库出现故障的情况下，尚未被发送到备用数据库的重做数据会丢失。但是，如果网络有足够的吞吐量来跟上重做流量高峰，并且使用了 LGWR 进程来将重做流量传输到备用服务器，则丢失的事务将非常少或者为零。当主数据库上的可用性和性能比丢失少量数据的风险更重要时，应该使用最高性能模式。这种模式还适合于 WAN 上的 Data Guard 部署，网络的内在延迟可能限制同步重做传输的适用性。

2. 环境准备

2.1 环境规划

实验基于单机DB+单实例DG。

注：备库中的实例名SID是参数设置的，SID可以和主库相同。

2.2 数据库安装(略)

• 在主库上安装数据库软件，并建监听和实例。
• 在备库上安装数据库软件，并建监听，但不创建实例，安装时选择只安装软件即可。

3. 主库配置

3.1 CDB和Non CDB环境下

• 如果实例处于多租户架构中，设置操作和Non-CDB方法相同，都在CDB下完成；
• 实验中有两个PDB1和PDB2，在创建备库后，默认两个PDB都会同步到备库，也可以通过参数指定只同步某个PDB；
• 也可以设置完同步的备库后，主库中再添加的PDB3也会同步到备库中。

# CDB环境下的实验配置中的主库实例也是orcl,备库是orcldg，需要设置主备不同的 DB_UNIQUE_NAME
# 同样可以通过name参数查看
SQL> show parameter name
NAME                                 TYPE        VALUE
------------------------------------ ----------- --------
cdb_cluster_name                     string
cell_offloadgroup_name               string
db_file_name_convert                 string
db_name                              string      orcl
db_unique_name                       string      orcl
global_names                         boolean     FALSE
instance_name                        string      orcl
lock_name_space                      string
log_file_name_convert                string
pdb_file_name_convert                string
processor_group_name                 string
service_names                        string      orcl
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

涉及的CDB简单操作：

# 查看当前处于的那个容器
SQL> show con_name
CON_NAME
------------------
CDB$ROOT
# 如果处于CDB，可以查看所有PDB
SQL> show pdbs
CON_ID	CON_NAME                 OPEN MODE  RESTRICTED
------ 	------------------------ ---------- ----------
   2 	PDB$SEED                 READ ONLY  NO
   3 	PDB1                     READ WRITE NO
   4 	PDB2                     READ WRITE NO
# 切换到PDB1
SQL> alter session set container=PDB1;
Session altered.
# 再次查看处于PDB1
SQL> show pdbs
CON_ID	CON_NAME                 OPEN MODE  RESTRICTED
------ 	------------------------ ---------- ----------
   3 	PDB1                     READ WRITE NO
# 再次查看处于PDB1
SQL> show con_name
CON_NAME
----------
PDB1
# 切回CDB
SQL> alter session set container=CDB$ROOT;
Session altered.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

3.2 开启归档

# 如果是CDB环境，先检查处于CDB根容器中，PDB下是不允许的
SQL> show con_name
CON_NAME
------------------
CDB$ROOT
# 查看归档是否Enable
SQL> archive log list
Database log mode				Archive Mode
Automatic archival				Enabled
Archive destination				USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence		129
Next log sequence to archive	131
Current log sequence			131
# 这里的归档路径是默认的 USE_DB_RECOVERY_FILE_DEST
# 如果没有开启，开启的步骤
shutdown immediate
startup mount
alter database archivelog;
# alter system set log_archive_dest_1='LOCATION=xxx' ;
alter database open;
SQL> alter system switch logfile;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

3.3 开启闪回

闪回区的管理，及闪回日志管理，数据库能闪回到过去的多久时间点，这个由闪回区大小以db_flashback_retention_target 参数控制，在闪回区大小足够的情况下，默认能闪回1440秒也就是一天的数据。

SQL> show parameter flashback
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target        integer     1440
1
2
3
4

# 1、查看闪回未开启
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------
NO
# 2、查看 db_recovery_file_dest 为空
SQL> show parameter recovery
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string
db_recovery_file_dest_size           big integer 0
recovery_parallelism                 integer     0
remote_recovery_file_dest            string
# 3、指定闪回区大小，指定闪回目录路径(顺序必须先设置闪回区大小，才能指定闪回目录，否则报错)
SQL> alter system set db_recovery_file_dest_size=4560m scope=spfile;
System altered.
SQL> shutdown immediate
SQL> startup
# 需要重启数据库才能生效，再继续修改目录位置，修改完目录也需要重启实例
# 4、先创建目录，在指定该闪回区域目录
mkdir -p /u01/app/oracle/fast_recovery_area
SQL> alter system set db_recovery_file_dest='/u01/app/oracle/fast_recovery_area';
System altered.
SQL> shutdown immediate
SQL> startup
# 5 开启闪回
SQL> alter database flashback on;
Database altered.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

3.4 开启所有PDB

如果是CDB环境，开启所有PDB。

col name for a10
SQL> select name,open_mode from v$pdbs;
NAME                           OPEN_MODE
------------------------------ --------------
PDB$SEED                       READ ONLY
PDB1                           MOUNTED
PDB2                           MOUNTED
# 开启 PDB
SQL> alter pluggable database all open;
Pluggable database altered.
# 查看
SQL> select name,open_mode from v$pdbs;
NAME       OPEN_MODE
---------- ----------
PDB$SEED   READ ONLY
PDB1       READ WRITE
PDB2       READ WRITE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

3.5 设置数据库强制归档

有一些DDL语句可以通过指定NOLOGGING子句的方式避免写REDO(目的是提高速度，某些时候确实有效)。指定数据库为Force Logging模式后，数据库将会记录除临时表空间或临时回滚段外所有的操作，而忽略类似NOLOGGING之类的指定参数。如果在执行Force Logging时有NOLOGGING之类的语句在执行，那么Force Logging会等待，直到这类语句全部执行。Force Logging是作为固定参数保存在控制文件中，因此其不受重启之类操作的影响(只执行一次即可)，如果想取消，可以通过ALTER DATABASE NO FORCE LOGGING语句关闭强制记录。

# 如果是CDB环境，先检查处于CDB根容器中，PDB下是不允许的
# 查看
SQL> SELECT NAME, OPEN_MODE, FORCE_LOGGING FROM V$DATABASE;
NAME       OPEN_MODE            FORCE_LOGGING
---------- -------------------- -----------------
ORCL       READ WRITE           NO
# **开启强制归档**
SQL> alter database force logging;
1
2
3
4
5
6
7
8

3.6 添加Standby redo log

3.6.1 说明

为主库添加standby redo log后，备库自动同步，所以备库不用再创建standby redo log 。

Data Guard在最大保护和最高可用性模式下，Standby数据库必须配置standby redo log。

3.6.2 作用

实际上就是与主库接收到的重做日志相对应，也就是说备库调用RFS进程将主库接收到的重做日志按顺序导入到standby logfile ，在主库创建Standby logfile是便于发生角色转换后备用。

3.6.3 创建原则

• 确保Standby redo log的大小与主库online redo log的大小一致：
  • 如果主库为单实例数据库：Standby redo log组数=主库日志总数+1。
  • 如果主库是RAC数据库：Standby redo log组数=(每线程的日志数+1)*最大线程数。
  • 不建议复用Standby redo log，避免增加额外的I/O以及延缓重做传输。

# 如果是CDB环境，先检查处于CDB根容器中，PDB下是不允许的；
# 在Oracle 12c的架构里，online redo log 和控制文件是保存在CDB中的，PDB中只有运行需要的数据文件；  
# 所以如果是CDB下，就在CDB中加 Standby redo log。
# 1、查看组数=3
SQL> select count(group#),thread# from v$log group by thread#;
COUNT(GROUP#)	THREAD#
------------	--------
3				1
# 2、大小=50M
SQL> select group#,bytes/1024/1024 from v$log;
GROUP#	BYTES/1024/1024
------	---------------
1		50
2		50
3		50
# 3、创建standby logfile(3+1组、每组50M)
	#	注意路径大小写，本文部署CDB环境时，SID是大写的ORCL
SQL> select * from v$standby_log;
alter database add standby logfile group 4 ('/u01/app/oracle/oradata/orcl/stantby_redo04.log') size 50m;
alter database add standby logfile group 5 ('/u01/app/oracle/oradata/orcl/stantby_redo05.log') size 50m;
alter database add standby logfile group 6 ('/u01/app/oracle/oradata/orcl/stantby_redo06.log') size 50m;
alter database add standby logfile group 7 ('/u01/app/oracle/oradata/orcl/stantby_redo07.log') size 50m;
# 4、验证查看
SQL> select * from v$standby_log;
SQL> select group#,bytes/1024/1024 from v$standby_log;
GROUP#  BYTES/1024/1024
-----   ---------------
4       50
5       50
6       50
7       50
SQL> select group#,status,type,member from v$logfile;
GROUP#STATUS	TYPE	MEMBER
----- -------	------- ----------------------------------
3     ONLINE			/u01/app/oracle/oradata/orcl/redo03.log
2     ONLINE 			/u01/app/oracle/oradata/orcl/redo02.log
1     ONLINE 			/u01/app/oracle/oradata/orcl/redo01.log
4     STANDBY 			/u01/app/oracle/oradata/orcl/stantby_redo04.log
5     STANDBY 			/u01/app/oracle/oradata/orcl/stantby_redo05.log
6     STANDBY 			/u01/app/oracle/oradata/orcl/stantby_redo06.log
7     STANDBY 			/u01/app/oracle/oradata/orcl/stantby_redo07.log
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

3.7 修改参数文件

3.7.1 设置DB唯一名称

# 通常主库的DB名和唯一名相同,show参数查看
alter system set db_unique_name='orcl' scope=spfile;
# 其中dg_config填写的是主备库的db_unique_name
alter system set log_archive_config='DG_CONFIG=(orcl,orcldg)' scope=spfile;
1
2
3
4

3.7.2 设置归档日志的路径

# =前后不能有空格，本地的archive路径没有修改，使用默认
alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST valid_for=(all_logfiles,all_roles) db_unique_name=orcl' scope=spfile;
alter system set log_archive_dest_2='SERVICE=ORCLDG ASYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=orcldg' scope=spfile;
# 第一个ORCLDG是备库tnsname.ora的连接名(最开头名称)
# 第二个orcldg是DB_UNIQUE_NAME
1
2
3
4
5

3.7.3 启用设置的日志路径

alter system set log_archive_dest_state_1=enable scope=spfile;
alter system set log_archive_dest_state_2=enable scope=spfile;
1
2

3.7.4 设置归档日志进程的最大数量

#（视实际情况调整）
alter system set log_archive_max_processes=30 scope=both;
1
2

3.7.5 设置备库从哪个数据库获取归档日志

# 只对standby库有效，在主库上设置是为了在故障切换后，主库可以成为备库使用，值就是TNSNAME
# fal表示fetch archive log
# fal_client用于发送日志，fal_server用于接受日志。也即无论是主库或备库，fal_server=对方，fal_client=自己
alter system set fal_server=orcldg;
alter system set fal_client=orcl;
1
2
3
4
5

3.7.6 设置文件管理模式

# 表示如果Primary数据库数据文件发生修改（如新建、重命名等）则按照本参数的设置在Standby数据库中作相应修改。
# 设为AUTO表示自动管理。设为MANUAL表示需要手工管理
# 此项设置为自动，不然在主库创建数据文件后，备库不会自动创建
alter system set standby_file_management=auto scope=spfile;
1
2
3
4

3.7.7 主备文件路径

如果主备库文件的存放路径不同，还需要设置以下两个参数（需要重启数据库生效）。

alter system set db_file_name_convert='/u01/app/oracle/oradata/orcldg','/u01/app/oracle/oradata/orcl' scope=spfile;
alter system set log_file_name_convert='/u01/app/oracle/oradata/orcldg','/u01/app/oracle/oradata/orcl' scope=spfile;
1
2

3.7.8 设置数据库口令文件的使用模式

SQL> show parameter remote_login_passwordfile
NAME						TYPE		VALUE
-------------------------	------		---------
remote_login_passwordfile	string		EXCLUSIVE
# 默认也是EXCLUSIVE
alter system set remote_login_passwordfile=EXCLUSIVE scope=spfile;
1
2
3
4
5
6

3.7.9 设置默认监听

此处直接让监听为空即可，保持后面创建的默认静态监听，否则备库无法从参数文件启动，或者如果想要设置监听值，也可以如下设置：

# 设置监听
alter system set local_listener='(DESCRIPTION =(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.2.2)(PORT=1521)))';
SQL> show parameter local_listener;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
local_listener                       string      LISTENER_ORCL
# 设置空
alter system set local_listener='';
SQL> show parameter local_listener;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
local_listener                       string
1
2
3
4
5
6
7
8
9
10
11
12

4. 备库配置

4.1 变量环境

[oracle@l080ldg ~]$ cat .bash_profile 
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin
export PATH
export EDITOR=vi
export ORACLE_SID=orcldg
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/12.1.0/dbhome_1
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/usr/lib
export PATH=/u01/app/oracle/product/12.1.0/dbhome_1/bin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/X11R6/bin
export PATH=$ORACLE_HOME/bin:$PATH
# 使变量生效
source ~/.bash_profile
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

4.2 主备库密码文件

# Data Guard环境中，数据库的sys用户名密码要相同，可直接将主库复制密码文件复制到备库
# 拷贝后备库的密码文件格式：ora+sid，Windows下格式为：PWD[sid].ora
scp $ORACLE_HOME/dbs/orapworcl oracle@192.168.2.3:$ORACLE_HOME/dbs/orapworcldg
1
2
3

4.3 修改参数文件

4.3.1 复制主库参数文件

备库的参数文件根据主库参数进行修改 ，主库上创建pfile，然后拷贝给备库。

SQL> create pfile from spfile;
# 拷贝后的静态参数文件格式：init+sid.ora
$ scp $ORACLE_HOME/dbs/initorcl.ora oracle@192.168.2.3:$ORACLE_HOME/dbs/initorcldg.ora
1
2
3

4.3.2 修改initorcldg.ora内容

orcl.__data_transfer_cache_size=0
orcl.__db_cache_size=1761607680
orcl.__java_pool_size=16777216
orcl.__large_pool_size=33554432
orcl.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
orcl.__pga_aggregate_target=822083584
orcl.__sga_target=2466250752
orcl.__shared_io_pool_size=117440512
orcl.__shared_pool_size=520093696
orcl.__streams_pool_size=0
# 修改为备库的orcldg
*.audit_file_dest='/u01/app/oracle/admin/orcldg/adump'
*.audit_trail='db'
*.compatible='12.1.0.2.0'
*.control_file_record_keep_time=19
# 修改为备库的orcldg
*.control_files='/u01/app/oracle/oradata/orcldg/control01.ctl' #Restore Controlfile
*.db_block_size=8192
*.db_domain=''
# 修改顺序主备路径和主库的相反
*.db_file_name_convert='/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/orcldg'
# DB名相同
*.db_name='orcl'
# 修改实例唯一名
*.db_unique_name='orcldg'
*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=4560m
*.diagnostic_dest='/u01/app/oracle'
# 修改orcldgXDB
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orcldgXDB)'
# 和主库配置顺序相反
*.fal_client='ORCLDG'
*.fal_server='ORCL'
# 使用默认监听
*.local_listener=''
# 和主库配置相同
*.log_archive_config='DG_CONFIG=(orcl,orcldg)'
# 修改为本库(备库)的唯一名
*.log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST valid_for=(all_logfiles,all_roles) db_unique_name=ocrldg'
# 服务名修改为连接主库TNS的ORCL，DB唯一名修改为主库的orcl
*.log_archive_dest_2='SERVICE=ORCL LGWR ASYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=orcl'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_max_processes=30
# 和主库配置相反
*.log_file_name_convert='/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/orcldg'
*.nls_date_format='yyyy-mm-dd hh24:mi:ss'
*.open_cursors=300
*.pga_aggregate_target=780m
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=2341m
*.standby_file_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.utl_file_dir='/home/oracle/logmnr'
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

4.4 备库创建spfile

SQL> create spfile from pfile;
File created.
SQL> 
1
2
3

4.5 创建备库所需路径

Oracle建议一般控制文件至少三个，放在不同的地方，本文主库没有设置。如果主库修改相关文件目录，拷贝过来的参数文件修改后也需要在备库中创建相关目录。

# 每个人的环境不同，根据备库参数文件创建所需目录
mkdir -p /u01/app/oracle/admin/orcldg/adump
mkdir -p /u01/app/oracle/oradata/orcldg		#根据情况是否大写	mkdir -p /u01/app/oracle/oradata/ORCLDG
mkdir -p /u01/app/oracle/fast_recovery_area
1
2
3
4

5. 主备库监听

5.1 开机自启动监听

设置主备库自动开启监听。
不建议备库设置自动开启数据库，因为DG开关有先后顺序，要手动开启。

## 修改/etc/rc.d/rc.local文件
su - root
# vi /etc/rc.d/rc.local			# 增加一行(/etc/rc.local是/etc/rc.d/rc.local的软连接)
su - oracle -c 'lsnrctl start'
## 授权rc.local文件可执行权限
# chmod +x /etc/rc.d/rc.local
1
2
3
4
5
6

5.2 主库注册静态监听

# 静态注册的参数概念：
GLOBAL_DBNAME	:#数据库服务名，默认和SID_NAME保持一致。在本例中这里需要填写PDB的服务名。
ORACLE_HOME		:#实例运行的ORACLE_HOME目录，如果是集群环境这里也填写ORACLE的ORACLE_HOME目录。
SID_NAME		:#数据库实例名。和数据库参数INSTANCE_NAME一致。
1
2
3
4

使用Net Manager创建监听不容易出错，添加 Database Services，客户端如果没有添加hosts信息或DNS建议写IP。如果是CDB环境，监听也是相同静态配置即可，无需配置PDB监听或TNS。

[oracle@l080l admin]$ cat listener.ora 
# listener.ora Network Configuration File: /u01/app/oracle/product/12.1.0/dbhome_1/network/admin/listener.ora
# Generated by Oracle configuration tools.

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = orcl)
      (ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1)
      (SID_NAME = orcl)
    )
  )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.2.2)(PORT = 1521))
    )
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

ADR_BASE_LISTENER = /u01/app/oracle
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

5.3 备库注册静态监听

[oracle@l080ldg admin]$ cat listener.ora
# listener.ora Network Configuration File: /u01/app/oracle/product/12.1.0/dbhome_1/network/admin/listener.ora
# Generated by Oracle configuration tools.

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = orcldg)
      (ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1)
      (SID_NAME = orcldg)
    )
  )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.2.3)(PORT = 1521))
    )
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

ADR_BASE_LISTENER = /u01/app/oracle
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

5.4 主备库TNS监听相同

[oracle@l080ldg admin]$ cat tnsnames.ora
# tnsnames.ora Network Configuration File: /u01/app/oracle/product/12.1.0/dbhome_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.

ORCLDG =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.2.3)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcldg)
    )
  )

ORCL =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.2.2)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

5.5 主备连接测试

# 主备库监听重启
lsnrctl stop
lsnrctl start
# 主备测试
tnsping orcl
tnsping orcldg
# 测试登录 #
# 主库登陆 在密码文件拷贝后才可以登陆
[oracle@l080l ~]$ sqlplus sys/Oracle#2020@orcl as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Mon Aug 16 01:45:02 2021
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL>
[oracle@l080l ~]$ sqlplus sys/Oracle#2020@orcldg as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Mon Aug 16 01:45:56 2021
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to an idle instance.
SQL>
# 备库登录
[oracle@l080ldg ~]$ sqlplus sys/Oracle#2020@orcl as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Mon Aug 16 01:47:24 2021
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL>
[oracle@l080ldg ~]$ sqlplus sys/Oracle#2020@orcldg as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Mon Aug 16 01:47:58 2021
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to an idle instance.
SQL>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

6. 方式一：物理备库之RMAN Duplicate

Duplicate 方式创建物理备库；通过这种方式直接在线从主库搭建物理备库。
本次实验：Non-CDB环境

6.1 备库启动到nomount状态

# 使用pfile启动到nomount
[oracle@l080ldg ~]$ sqlplus /  as sysdba
SQL> startup nomount pfile='/u01/app/oracle/product/12.1.0/dbhome_1/dbs/initorcldg.ora';
ORACLE instance started.
Total System Global Area 2466250752 bytes
Fixed Size                  2927384 bytes
Variable Size             671089896 bytes
Database Buffers         1778384896 bytes
Redo Buffers               13848576 bytes
# 创建Spfile
SQL> create spfile from pfile;
SQL> shutdown immediate;
# 启动到nomount
SQL> startup nomount
1
2
3
4
5
6
7
8
9
10
11
12
13
14

6.2 登陆RMAN连接主备库

# 主库target/orcl 备库auxiliary/orcldg
# 主备库DB_NAME必须一致，主库是open状态，备库是nomount状态
[oracle@l080ldg ~]$ rman target sys/Oracle#2020@orcl auxiliary sys/Oracle#2020@orcldg
Recovery Manager: Release 12.1.0.2.0 - Production on Mon Aug 16 16:54:46 2021
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
connected to target database: ORCL (DBID=1576583420)
connected to auxiliary database: ORCL (not mounted)
RMAN>
1
2
3
4
5
6
7
8

6.3 开始 Duplicate

RMAN> duplicate target database for standby from active database dorecover nofilenamecheck;
# 执行过程（略）
Starting Duplicate Db at 16-AUG-21
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=243 device type=DISK
current log archived
...
....
.....
media recovery complete, elapsed time: 00:00:01
Finished recover at 16-AUG-21
Finished Duplicate Db at 16-AUG-21
1
2
3
4
5
6
7
8
9
10
11
12
13

7. 方式二：物理备库之RMAN备份还原

使用 RMAN 备份恢复方法，将备份的文件和控制文件传到备库恢复。本次实验：Non-CDB环境。

7.1 主库RMAN全备

# 创建RMAN备份路径
mkdir -p /u01/rmanbackup
# RMAN备份
$ rman target /
RMAN> backup database format='/u01/rmanbackup/FULL_%d_%T_%s.dbf';
Starting backup at 18-AUG-21
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/orcl/system01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/orcl/sysaux01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/orcl/undotbs01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/orcl/test.dbf
input datafile file number=00006 name=/u01/app/oracle/oradata/orcl/users01.dbf
channel ORA_DISK_1: starting piece 1 at 18-AUG-21
channel ORA_DISK_1: finished piece 1 at 18-AUG-21
piece handle=/u01/rmanbackup/FULL_ORCL_20210818_1.dbf tag=TAG20210818T220447 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:25
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 18-AUG-21
channel ORA_DISK_1: finished piece 1 at 18-AUG-21
piece handle=/u01/rmanbackup/FULL_ORCL_20210818_2.dbf tag=TAG20210818T220447 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 18-AUG-21
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

7.2 主库备份控制文件

RMAN> backup current controlfile for standby format '/u01/rmanbackup/control.bak';
1

7.3 拷贝备份文件到备库

# 创建和主库相同的路径
mkdir -p /u01/rmanbackup
[oracle@l080l ~]$ cd /u01/rmanbackup/
[oracle@l080l rmanbackup]$ ls
control.bak  FULL_ORCL_20210818_1  FULL_ORCL_20210818_2
# 传输文件到备库改路径下
[oracle@l080l rmanbackup]$ scp /u01/rmanbackup/* oracle@192.168.2.3:/u01/rmanbackup
oracle@192.168.2.3's password: 
control.bak					100% 9888KB  36.6MB/s   00:00    
FULL_ORCL_20210818_1.dbf	100% 1299MB  51.9MB/s   00:25    
FULL_ORCL_20210818_2.dbf	100% 9920KB  18.0MB/s   00:00  
1
2
3
4
5
6
7
8
9
10
11

7.4 备库启动到nomount状态

# 使用pfile启动到nomount
# 如果已经创建spfile可以直接启动到 nomount状态
[oracle@l080ldg ~]$ echo $ORACLE_SID
orcldg
[oracle@l080ldg ~]$ sqlplus / as sysdba
# 启动
SQL> startup nomount pfile='/u01/app/oracle/product/12.1.0/dbhome_1/dbs/initorcldg.ora';
ORACLE instance started.
Total System Global Area 2466250752 bytes
Fixed Size                  2927384 bytes
Variable Size             671089896 bytes
Database Buffers         1778384896 bytes
Redo Buffers               13848576 bytes
# 创建Spfile
SQL> create spfile from pfile;
SQL> shutdown immediate;
# 启动到nomount
SQL> startup nomount
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

7.4 备库恢复控制文件

[oracle@l080ldg ~]$ rman target /
RMAN> restore standby controlfile from '/u01/rmanbackup/control.bak';
..
...
Finished restore at 18-AUG-21
1
2
3
4
5

7.6 备库mount

SQL> alter database mount;
Database altered.
1
2

7.7 还原数据库

RMAN> restore database;
Starting restore at 19-AUG-21
released channel: ORA_DISK_1
Starting implicit crosscheck backup at 19-AUG-21
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=355 device type=DISK
Crosschecked 2 objects
Finished implicit crosscheck backup at 19-AUG-21
Starting implicit crosscheck copy at 19-AUG-21
using channel ORA_DISK_1
Crosschecked 2 objects
Finished implicit crosscheck copy at 19-AUG-21
searching for all files in the recovery area
cataloging files...
no files cataloged
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/orcldg/system01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/orcldg/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/orcldg/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /u01/app/oracle/oradata/orcldg/test.dbf
channel ORA_DISK_1: restoring datafile 00006 to /u01/app/oracle/oradata/orcldg/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/rmanbackup/FULL_ORCL_20210818_1.dbf
channel ORA_DISK_1: piece handle=/u01/rmanbackup/FULL_ORCL_20210818_1.dbf tag=TAG20210818T235901
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
Finished restore at 19-AUG-21

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

8. 方式三：物理备库之CDB下的DBCA

8.1 DBCA备库说明

前两个物理备库方式都是基于Non-CDB创建DG的，也可以在CDB下通过Duplicate或RMAN备份还原的方法创建DG，配置主备库的条件相同，处于CDB状态下设置主库的配置即可；
到 12cR2 (12.2.0.1)后，新增 DBCA 方式直接建立物理备库的方法。但是对版本和实例环境有一定限制条件：
12cR2中:

# 1、12cR2 主库必须是单机环境，非 RAC 数据库；
# 若主库是 RAC 数据库，错误如下：
[FATAL] [DBT-16056] Specified primary database is not a Single Instance (SI) database.
CAUSE: Duplicate database operation is supported only for SI databases.
1
2
3
4

# 2、12cR2 主库必须是非 CDB 环境；
# 若主库是 CDB 环境，错误如下：
[FATAL] [DBT-16057] Specified primary database is a container database (CDB).
CAUSE: Duplicate database operation is supported only for non container databases.
1
2
3
4

18c 及以后:
18c(12.2.0.2)开始，这些限制条件已经取消，即主库是 CDB 或 RAC环境都可以通过 dbca 来创建物理备库。
本节DBCA备库环境： 19c的CDB环境，主/备库的环境和前面的配置方法相同。

8.2 配置Hosts

在没有DNS的配置下，需要配置Hosts，否则DBCA过程通讯报错：

ORA-17627：TNS：could not resolve connect identifier specified   
1

# cat /etc/hosts  
192.168.2.2	l080l  
192.168.2.3	l080ldg
1
2
3

8.3 DBCA过程

8.3.1 主库开启

# 如果是CDB环境，先开启数据库也要开启PDB
SQL> startup
SQL> alter pluggable database all open;
Pluggable database altered.
1
2
3
4

8.3.2 DBCA命令

不需要备库数据库处于nomount状态，监听开启后备库上直接DBCA即可。
如果是CDB环境，完成后CDB会直接开启，再开启PDB即可。

# 19c 官网展示的模板
dbca -createDuplicateDB 
    -gdbName global_database_name 
    -primaryDBConnectionString easy_connect_string_to_primary
    -sid database_system_identifier
    [-createAsStandby 
        [-dbUniqueName db_unique_name_for_standby]]
    [-customScripts scripts_list]
# 19c 官网DBCA案例    
	#	Database 			DB_UNIQUE_NAME 		Oracle Net Service Name
	#	Primary				chicago				chicago
	#	Physical standby	boston				boston
# dbca –silent -createDuplicateDB -primaryDBConnectionString  myprimary.domain:1523/chicago.domain -gdbName chicago.domain -sid boston -initParams instance_name=boston –createAsStandby

# 本实验如下设置
dbca -silent -createDuplicateDB \
-gdbName orcl \
-sid orcldg \
-sysPassword Oracle#2020 \
-primaryDBConnectionString 192.168.2.2:1521/ORCL \
-l080llist l080ldg \
-databaseConfigType SINGLE \
-createAsStandby -dbUniqueName orcldg
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 执行过程
[oracle@l080ldg ~]$ dbca -silent -createDuplicateDB \
> -gdbName orcl \
> -sid orcldg \
> -sysPassword Oracle#2020 \
> -primaryDBConnectionString 192.168.2.2:1521/ORCL \
> -l080llist l080ldg \
> -databaseConfigType SINGLE \
> -createAsStandby -dbUniqueName orcldg
Prepare for db operation
22% complete
Listener config step
44% complete
Auxiliary instance creation
67% complete
RMAN duplicate
89% complete
Post duplicate database operations
100% complete
Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/orcldg/orcldg.log" for further details.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

9. 开启并验证DG同步

9.1 开启实时同步

alter database open;
# 如果是CDB环境，需要开启pdb
SQL> alter pluggable database all open;
alter database recover managed standby database using current logfile disconnect from session;
# 从12C开始，RECOVER语句，不需要再指定using current logfile，Oracle会自动判断日志应用是否是实时的。
1
2
3
4
5

9.2 备库开启闪回

# 查看闪回
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------
NO
# 取消实时同步
SQL> alter database recover managed standby database cancel;
# 关闭数据库
SQL> shutdown immediate
SQL> startup mount
SQL> alter database flashback on;
# 开启数据库
SQL> alter database open;
# 再次开启同步
SQL> alter database recover managed standby database using current logfile disconnect from session;
# 查看
SQL> select open_mode from v$database;
OPEN_MODE 
--------------------
READ ONLY WITH APPLY
# 查看主库 PRIMARY
SQL> select log_mode,open_mode ,database_role from v$database;
LOG_MODE     OPEN_MODE            DATABASE_ROLE
------------ -------------------- ----------------
ARCHIVELOG   READ WRITE           PRIMARY
# 查看备库 PHYSICAL STANDBY
SQL> select log_mode,open_mode ,database_role from v$database;
LOG_MODE     OPEN_MODE            DATABASE_ROLE
------------ -------------------- ----------------
ARCHIVELOG   READ ONLY            PHYSICAL STANDBY
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

9.3 归档同步验证

# 主库切换归档, 查询主库备库最大归档序号，一致即归档同步成功
SQL> alter system archive log current;
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
            72
# 查看主备归档日志是否能正常传输（APPLIED=yes）
SQL> select SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED, ARCHIVED from V$ARCHIVED_LOG;
1
2
3
4
5
6
7
8

9.4 查看主备库状态

# 主库
SQL> select switchover_status,database_role from v$database;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
TO STANDBY           PRIMARY
# 备库
SQL> select switchover_status,database_role from v$database;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
NOT ALLOWED          PHYSICAL STANDBY
1
2
3
4
5
6
7
8
9
10

9.5 主库查看备库归档路径报错

# 主库 查看archive_log_dest_2列是否有error
SQL> select status,error from v$archive_dest where dest_id=2;
STATUS    ERROR
--------- --------------------
VALID
1
2
3
4
5

9.6 主库Dataguard的状态信息

# 查看Dataguard的状态信息
col message format a150
select message_num,message from v$dataguard_status;
# 查看GAP信息
SELECT STATUS,GAP_STATUS FROM v$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;
1
2
3
4
5

9.7 建表测试

# 主库
create table test(id number);
insert into test values(1);
commit;
select * from test;
# 备库
select * from test;
1
2
3
4
5
6
7

10. DG切换和恢复

配置DG的目的就是为了在主库出现故障时，备库能够提供服务，保证业务的正常运行。
DG的故障切换分为switchover和failover两种。

10.1 Switchover

10.1.1 主库上操作

# 1、主库查询状态
# 注意：下面查询结果为TO STANDBY 或 SESSIONS ACTIVE表明可以进行切换
SQL> select switchover_status,database_role from v$database;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
TO STANDBY           PRIMARY
# 2、主库开始切换
SQL> alter database commit to switchover to physical standby;
Database altered.
# 主库有会话连接的时候使用如下命令
# alter database commit to switchover to physical standby with session shutdown;
# 3、主库变备库，开启到mount状态
SQL> startup mount
ORACLE instance started.
Total System Global Area 2466250752 bytes
Fixed Size                  2927384 bytes
Variable Size             671089896 bytes
Database Buffers         1778384896 bytes
Redo Buffers               13848576 bytes
Database mounted.
SQL> select database_role from v$database;
DATABASE_ROLE
----------------
PHYSICAL STANDBY
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

10.1.2 备库上操作

# 1、备库查询状态
# 注意：下面查询结果为TO PRIMARY 或 SESSIONS ACTIVE表明可以进行切换
SQL> select switchover_status,database_role from v$database;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
TO PRIMARY           PHYSICAL STANDBY
# 2、备库开始切换
SQL> alter database commit to switchover to primary with session shutdown;
Database altered.
# 3、开启数据库
SQL>  alter database open;
Database altered.
# 4、查询状态，已经变成主库
SQL> select switchover_status,database_role,open_mode from v$database;
SWITCHOVER_STATUS    DATABASE_ROLE    OPEN_MODE
-------------------- ---------------- --------------------
TO STANDBY           PRIMARY          READ WRITE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

10.1.3 新备库(原主库)上的操作

# 1、开机数据库open
SQL> alter database open;
Database altered.
# 2、开启同步
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
# 3、主备检查切换状态
SQL> select open_mode,database_role,db_unique_name from v$database;
1
2
3
4
5
6
7
8

10.1.4 验证

# 新主库切换归档，主备查询
alter system archive log current;
SQL> select max(sequence#) from v$archived_log;
# 新主库表插入数据测试
insert into test values(2); 
commit;
select * from test;
1
2
3
4
5
6
7

10.2 Failover

10.2.1 故障转移操作流程图

Failover是当主库真正出现严重系统故障，如数据库宕机，软硬件故障导致主库不能支持服务，从而进行的切换动作。

为了能够在failover后能够恢复DG,需要在主库上开启flashback，否则DG就可能需要重新搭建。

先把主库关机，模拟Failover 。

Step1.刷新所有未发送的日志到备库

如果主库还可以启动到mount状态，则刷新所有未发送的归档日志和在线redo日志到备库。如果这一步成功了，则可以保证数据零丢失。
如果主库不能mount，则执行第2步。

# 主库
SQL> ALTER SYSTEM FLUSH REDO TO 'target_db_name';
# target_db_name为备库的db_unique_name。
# 如果上面的语句执行成功，则直接跳到步骤5；如果执行报错，则执行步骤2。
1
2
3
4

Step2.确认备库接收到最新归档日志文件

在备库上使用V\$ARCHIVED_LOG视图，查询每个实例的最大日志序列号的日志，通过查询出的日志序列号与主库的最大日志序列号比较（主库的直接到服务器上去查看归档日志文件），可以直到缺失了哪些归档日志文件。

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
1

如果可能，对于还未传输到备库的日志文件，直接从主数据库上拷贝过去，然后注册日志，注册日志放入如下：

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
1

Step3.确认和解决日志GAP

在备库上查询V$ARCHIVE_GAP视图，确认是否存在日志GAP，如：

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
THREAD#    LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1            90             92
1
2
3
4

在这个例子中，GAP存在于线程1的90，91，92号归档日志上，如果可能，拷贝这些日志到备库服务器上，然后注册日志。

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
1

Step4.重复步骤3直到把所有GAP解决

继续在备库上查询V$ARCHIVE_GAP视图，直到没有数据返回，说明没有GAP。
如果在执行了步骤2到步骤4后，依然无法解决日志GAP（例如，主服务器宕机，我们无法访问主数据库，导致日志无法同步到备库），则执行failover切换后会存在数据丢失。

Step5.备库停止日志应用

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
1

Step6.完成所有已经接收日志的应用

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
# SQL> alter database recover managed standby database finish force;
1
2

如果这个操作未报错，则执行步骤7。
如果发生报错，尝试解决错误，再次执行以上SQL语句，如果报错无法解决，可以在目标备库执行以下语句来进行故障转移（会丢失数据）

# 会丢失数据
# SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
1
2

这个语句完成后跳到第9步执行。

Step7.确认目标备库准备切换为主库

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO PRIMARY
1
2
3
4

如果SWITCHOVER_STATUS的值为“TO PRIMARY”或者“SESSIONS ACTIVE”，则说明备库已经准备切换为主库。如果不是这2个值，确认Redo日志应用是否还是活跃的，继续查询，直到变为这2个值中的一个为止。

Step8.切换物理备库为主库

使用下面的SQL语句进行切换：

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
1

STEP9.打开新的主库

SQL> ALTER DATABASE OPEN;
Database altered.
# 查看状态
SQL> select switchover_status,database_role,open_mode from v$database;
SWITCHOVER_STATUS    DATABASE_ROLE    OPEN_MODE
-------------------- ---------------- --------------------
FAILED DESTINATION   PRIMARY          READ WRITE
# 当新主库的SWITCHOVER_STATUS状态为FAILED DESTINATION时，是因为备库不在mount状态下,这里已经没有备库
1
2
3
4
5
6
7
8

10.2.11 简易操作

当备库和主库(主库无法打开)最终同步的情况下，以下简易步骤直接操作：

#1、停止日志应用
SQL> alter database recover managed standby database cancel;
Database altered.
#2、完成所有已经接收日志的应用
SQL> alter database recover managed standby database finish force;
Database altered.
#3、切换物理备库为主库
SQL> select database_role from v$database;
DATABASE_ROLE
----------------
PHYSICAL STANDBY
SQL> alter database commit to switchover to primary;
#SQL> alter database commit to switchover to primary with session shutdown;
Database altered.
SQL> select database_role from v$database;
DATABASE_ROLE
----------------
PRIMARY
#4、开启数据库open
SQL> alter database open;
Database altered.
#5、查看状态
SQL> select switchover_status,database_role,open_mode from v$database;
SWITCHOVER_STATUS    DATABASE_ROLE    OPEN_MODE
-------------------- ---------------- --------------------
FAILED DESTINATION   PRIMARY          READ WRITE
# 当主库的SWITCHOVER_STATUS状态为FAILED DESTINATION时，是因为备库不在mount状态下,这里已经没有备库
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

10.3 Failover恢复

上面提到了failover，这种情形是当主库真正出现异常之后，才会执行的操作，那么执行过failover 之后，如何在重新构建DG，这里利用flashback database来重构，具体方法如下：

10.3.1 在新主库上执行

# 查询变成新主库的scn
SQL> select to_char(standby_became_primary_scn) from v$database;
TO_CHAR(STANDBY_BECAME_PRIMARY_SCN)
----------------------------------------
12514234
1
2
3
4
5

10.3.2 在老主库上执行

# 要将之前出问题的老主库变成备库
# 1、启动 mount 状态下
SQL> startup mount
ORACLE instance started.
Total System Global Area 2466250752 bytes
Fixed Size                  2927384 bytes
Variable Size             671089896 bytes
Database Buffers         1778384896 bytes
Redo Buffers               13848576 bytes
Database mounted.
# 2、闪回到新的主库查询的scn
SQL> flashback database to scn 12514234;
Flashback complete.
# 3、转为备库
SQL> alter database convert to physical standby;
Database altered.
# 4、关闭
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
# 5、开启
SQL> startup
ORACLE instance started.
Total System Global Area 2466250752 bytes
Fixed Size                  2927384 bytes
Variable Size             671089896 bytes
Database Buffers         1778384896 bytes
Redo Buffers               13848576 bytes
Database mounted.
Database opened.
# 6、开启同步
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
# 7、同步验证(略)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

11. 方式四：逻辑备库Logical Standby

11.1 说明

• Oracle Data Guard逻辑备库是利用主库的一个备份首先建立一个物理备库，然后再将其转换为逻辑备库。
• 这之后主库将日志传递到备库，备库利用logminer从主库的日志中解析出主库所执行过的SQL，在备库上重新执行一遍，从而保证与主库的数据在逻辑上保持一致。
• 与物理备库相对应的是，物理备库使用的是redo apply，逻辑备库使用的是sql apply。
• 因此逻辑备库仅仅保证数据与主库是在逻辑上是一致的，从而逻辑备库可以处于open状态下并进行相应的DML操作。

11.2 备库停止MGR(Redo apply应用)

# 对于将物理备库切换到逻辑备库，需要在主库构建LogMiner字典及启用补充日志
# 因此应先停用备库的MRP进程，避免产生额外的Redo Apply
SQL> alter database recover managed standby database cancel;
1
2
3

11.3 主库构建LogMiner字典

# 1、创建字典表空间
SQL> create tablespace logmnrtbs datafile '/u01/app/oracle/oradata/orcl/logmnrtbs.dbf' size 100m autoextend on next 5m maxsize 2000m;
# 2、关联字典表空间
SQL> execute dbms_logmnr_d.set_tablespace('logmnrtbs');
PL/SQL procedure successfully completed.
# 3、构建LogMiner字典
SQL> exec dbms_logstdby.build;
PL/SQL procedure successfully completed.
1
2
3
4
5
6
7
8

11.4 物理备库恢复为逻辑备库

SQL> select name,open_mode,database_role,protection_mode from v$database; 
NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE
--------- -------------------- ---------------- --------------------
ORCL      MOUNTED              PHYSICAL STANDBY MAXIMUM PERFORMANCE
========================================================================
# 1、关闭,必须一致性性关闭数据库
SQL> shutdown immediate
# 2、以exclusive方式启动到mount
SQL> startup mount exclusive
# 3、转换为逻辑备库并设置新的db_name
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY ORCLLG; 
# 4、关闭,必须一致性性关闭数据库
SQL> shutdown immediate
# 5、正常启动到mount
SQL> startup mount
========================================================================
##	可以看到name自动改变，为读写模式，日志序列也从1开始
SQL> select name,open_mode,database_role,protection_mode from v$database; 
NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE
--------- -------------------- ---------------- --------------------
ORCLLG    MOUNTED              LOGICAL STANDBY  MAXIMUM PERFORMANCE
SQL> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     1
Next log sequence to archive   1
Current log sequence           1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

11.5 开启逻辑备库并同步

# 由于逻辑Standby与Primary数据库事务并不一致，因此第一次打开时必须指定RESETLOGS子句
SQL> ALTER DATABASE OPEN RESETLOGS;
# 执行启动REDO应用的命令，附加APPLY IMMEDIATE子句，以打开实时应用
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 
1
2
3
4

11.6 测试

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# 测试逻辑DG部分
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# 在测试数据是否正常同步时，不要使用数据库的内部账号，逻辑dg在默认情况下不传输系统用户下，用户自行创建的数据
# 比如在sys用户下创建一个test表，这个表不会同步到逻辑备库
# 可以使用下列语句查看哪些用户作为内部用户
SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# 以下在方式四的逻辑DG环境中，主库解锁scott，备库已也会同步经解锁该用户，并创建表等操作
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SQL> alter user scott account unlock;
User altered.
SQL> conn scott/tiger
ERROR:
ORA-28002: the password will expire within 7 days
create table test(id number);
insert into test values(1);
commit;
# 主备查询一致，至此逻辑Standby创建完成.
select * from test;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

11.7 Swichover

11.7.1 状态检查

# 1、查看当前Primary数据库状态：
#如果该查询返回TO STANDBY 或SESSIONS ACTIVE则表示状态正常，可以执行转换操作
# 主库
SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
TO STANDBY           PRIMARY
# 备库
SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
NOT ALLOWED          LOGICAL STANDBY
1
2
3
4
5
6
7
8
9
10
11
12

11.7.2 [准备]转换Primary为逻辑Standby

# 2、执行下列语句，将Primary置为准备转换的状态：
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;
Database altered.
# 执行完上述操作后，Primary数据库就开始为角色的转换打好基础，时刻准备着接收来自逻辑Standby数据库，也就是未来的新Primary数据库发来的REDO数据。
# 查看一下SWITCHOVER_STATUS的状态：
SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
PREPARING SWITCHOVER PRIMARY
1
2
3
4
5
6
7
8
9

11.7.3 [准备]转换逻辑Standby为Primary

# 转换为Primary的PREPARE状态
# 语句执行时响应会稍微有点慢
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
Database altered.
# 执行完后查看当前逻辑Standby数据库的转换状态：
SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
PREPARING SWITCHOVER LOGICAL STANDBY 
1
2
3
4
5
6
7
8
9

11.7.4 再次检查Primary状态

SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
TO LOGICAL STANDBY   PRIMARY
# 检查结果却非常重要，它直接关系到switchover转换是否能够成功。
# 逻辑Standby执行完PREPARE命令之后，就会生成相应的LogMiner字典数据（就像我们前面创建逻辑Standby时，Primary数据库会生成LogMiner字典数据一样）。
# 只有它正常生成并发送至当前的Primary数据库，转换操作才能够继续下去。
# 不然当前的Primary数据库在转换完之后，可能就失去了从新的Primary数据库接收REDO数据的能力了。
# 因此，如果上述查询的返回结果不是TO LOGICAL STANDBY的话，DBA就需要考虑是否取消此次转换，检查原因，然后再重新操作了

# ++取消转换可以通过下列语句进行++++++++++++++++++++++++++++++++++++++++++++++++
ALTER DATABASE PREPARE TO SWITCHOVER CANCEL; 
# ++需要分别在Primary端和逻辑Standby端执行+++++++++++++++++++++++++++++++++++++
1
2
3
4
5
6
7
8
9
10
11
12
13

11.7.5 正式转换Primary为逻辑Standby

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
Database altered.
# 该语句需要等待当前Primary数据库所有事务全部结束才开始执行
# 该语句执行过程中会自动拒绝用户提交新事务或修改需求，为了确保该操作尽可能快的执行，最好自开始切换操作起就禁止所有用户的操作
# 该命令执行完之后，这个Primary数据库就已经成为新的逻辑Standby了。不过在新Primary执行完转换之前，不要关闭当前这个数据库
1
2
3
4
5

11.7.6 再次检查逻辑Standby状态

# SWITCHOVER_STATUS的状态，应该为TO PRIMARY：
SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
TO PRIMARY           LOGICAL STANDBY
# 或者
SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
NOT ALLOWED          LOGICAL STANDBY
1
2
3
4
5
6
7
8
9
10

11.7.7 正式转换逻辑Standby为新Primary

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Database altered.
1
2

11.7.8 开始新的主备同步

# 新逻辑备库（即原主库上）
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.
1
2
3

11.7.9 测试

# 主库添加数据
insert into scott.test values(10);
commit;
# 主备查询
select * from scott.test;
# ==发现并没有同步=============================
# 查看新主库状态,存在GAP
SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
LOG SWITCH GAP       PRIMARY
# ==解决=====================================
# 新主库关闭启动到mount
shutdown immediate
startup mount
# 把新主库REDO FLUSH到新备库，
# 此处是orcldg是新主库，在新主库上将日志flush到新备库上
# ALTER SYSTEM FLUSH REDO TO target_db_name;其中target_db_name使用DB_UNIQUE_NAME
ALTER SYSTEM FLUSH REDO TO orcl;
# 再次查看新主库状态，再测试数据已经同步
SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
NOT ALLOWED          PRIMARY
# 开启数据库
alter database open;
# 测试查询结果
SQL> select * from scott.test;
        ID
----------
         2
        10
         1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

11.8 Failover

11.8.1 检查丢失的归档

# 如果此时Primary数据库仍可被访问，首先应当检查当前的归档日志序号与逻辑Standby是否相同
# 主库
SQL> SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG;
MAX(SEQUENCE#)
--------------
            11
# 备库
SQL> SELECT SEQUENCE#,APPLIED FROM DBA_LOGSTDBY_LOG;
 SEQUENCE# APPLIED
---------- --------
         8 YES
         9 YES
        10 YES
        11 CURRENT
1
2
3
4
5
6
7
8
9
10
11
12
13
14

11.8.2 模拟Failover

将Primary关机或关闭数据库，模拟Failover。

Failover三种情况：(上面查询的是正常运行的还没有Failover的情况)

• 第一种：如果逻辑Standby与Primary的归档序号相同，但某些序号的APPLIED状态为NO，建议检查当前逻辑Standby数据库是否启动了SQL应用。
• 第二种：如果逻辑Standby归档序号小于Primary的归档序号，说明Primary存在尚未发送至逻辑Standby数据库的归档文件，手工复制这些文件到待转换角色的逻辑Standby端，然后在该逻辑Standby数据库的SQL*Plus命令窗口，通过执行ALTER DATABASE REGISTER LOGICAL LOGFILE 'filepath'; 命令，将复制过来的归档文件手工注册。
• 第三种：如果Primary数据库已经无法打开，就只好直接到磁盘上查看归档目录中的序号，来与逻辑Standby数据库做比较。如果Primary数据库已经完全无法访问，那直接按照后面步骤进行操作。

11.8.3 检查Standby日志情况

# 通过V$LOGSTDBY_PROGRESS视图，查询重做日志的应用情况
SQL> SELECT APPLIED_SCN,LATEST_SCN FROM V$LOGSTDBY_PROGRESS;
APPLIED_SCN LATEST_SCN
----------- ----------
   12778829   12778829
# 如果返回的结果中显示，两列的列值一致，则表示所有接收到的重做日志都已经应用。如果不一致的话，启动逻辑Standby端的SQL应用。
1
2
3
4
5
6

11.8.4 激活前检查

# 确认待转换的逻辑Standby配置了正确的归档路径和远端服务器的归档配置(前面设置部分都配置过)
SQL> SHOW PARAMETER LOG_ARCHIVE_DEST
# 查看当前操作的角色：
SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE,FORCE_LOGGING FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE    FORCE_LOGGING
-------------------- ---------------- ---------------------------------------
NOT ALLOWED          LOGICAL STANDBY  YES
# 如果当前FORCE_LOGGING为NO，务必执行ALTER DATABASE FORCE LOGGING;命令。
1
2
3
4
5
6
7
8

11.8.5 激活新的Primary数据库

# 转换Standby数据库角色为Primary
SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY; 
Database altered.
# 该语句主要是停止待转换的逻辑Standby中RFS进程，并应用完当前所有已接收但并未应用的REDO数据，然后停止SQL应用，将数据库转换成Primary角色
# 再次查看当前数据库的角色
SQL> SELECT DATABASE_ROLE,FORCE_LOGGING FROM V$DATABASE; 
DATABASE_ROLE    FORCE_LOGGING
---------------- ---------------------------------------
PRIMARY          YES
# 至此完成Failover后角色的转换了
1
2
3
4
5
6
7
8
9
10

11.9 Failover恢复

上面这种情形是当主库真正出现异常之后，才会执行的Failover操作；执行过failover之后，如何在重新构建之前老的逻辑主库DG。

11.9.1 DB_LINK连接主备

# 在需要重构的库中执行
# ALTER SESSION ENABLE|DISABLE GUARD的作用
# 该语句用于允许或禁止用户修改逻辑Standby中的结构
# 直接修改会报错：
SQL> ALTER SESSION DISABLE GUARD;
# 创建DB_LINK
SQL> CREATE DATABASE LINK link_orcllg CONNECT TO system IDENTIFIED BY Oracle#2020 USING '192.168.2.2:1521/orcl'; 
SQL> ALTER SESSION ENABLE GUARD;
1
2
3
4
5
6
7
8

11.9.2 启动同步

# 使用link同步新主库
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY link_orcllg;
Database altered.
# 后面开关机可以正常使用下面SQL应用redo
# SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
1
2
3
4
5

11.9.3 查看状态并验证

# 主库
# 主库存在GAP
SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
RESOLVABLE GAP       PRIMARY
# 备库
SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
NOT ALLOWED          LOGICAL STANDBY
# ==解决=====================================
# 新主库关闭启动到mount
shutdown immediate
startup mount
# 把新主库REDO FLUSH到新备库
# 此处是orcl是新主库，在新主库上将日志flush到新备库orcldg上
# ALTER SYSTEM FLUSH REDO TO target_db_name;其中target_db_name使用DB_UNIQUE_NAME
ALTER SYSTEM FLUSH REDO TO orcldg;
# 再次查看新主库状态，再测试数据已经同步
SQL> SELECT SWITCHOVER_STATUS,DATABASE_ROLE FROM V$DATABASE;
SWITCHOVER_STATUS    DATABASE_ROLE
-------------------- ----------------
NOT ALLOWED          PRIMARY
# 开启数据库
alter database open;
# 数据验证
insert into scott.test values(900);
commit;
select * from scott.test;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

12. 方式五：快照备库Snapshot

继 方式一：物理备库之RMAN Duplicate 后的操作，快照备库是11g开始有的特性。

在Dataguard中，可以将standby备库切换为snapshot快照数据库，在切换为snapshot数据库后，备库将置于可读写的模式。
运用的场景：可用于模拟业务功能测试，备库处于快照备库模式后，可将备库置于可读写的状态，用于不方便在生产环境主库的测试内容,比如模拟线上测试等内容。快照模式的备库可以反复测试，在使用完成之后，可以将快照数据库切换为物理备库，则之前所有在快照备库上的操作都丢失，一般快照备库操作的数据越大，恢复回物理备库时间越长。
在快照备库期间，备库可以接受主库传输过来的日志，但是不能应用日志，需要处于物理备库的时候才可以应用。
当快照备库转回为物理备库时，所有在快照备库的操作被丢弃后，物理快照才会应用主库的redo数据。

12.1 备库停止Redo apply应用

# 确保备库指定闪回区域
SQL> show parameter db_recov
NAME                                 TYPE        VALUE
------------------------------------ ----------- ----------------------------------
db_recovery_file_dest                string      /u01/app/oracle/fast_recovery_area
db_recovery_file_dest_size           big integer 4560M
# 停止Redo应用
SQL> alter database recover managed standby database cancel;
Database altered.
1
2
3
4
5
6
7
8
9

12.2 备库到mount状态

# 确保数据库是否处于mount状态
SQL> select open_mode,database_role,protection_mode,protection_level from v$database;
OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE      PROTECTION_LEVEL
-------------------- ---------------- -------------------- --------------------
MOUNTED              PHYSICAL STANDBY MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE
1
2
3
4
5

12.3 转换为快照备库

SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
Database altered.
# 查看
SQL> select open_mode,database_role,protection_mode,protection_level from v$database;
OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE      PROTECTION_LEVEL
-------------------- ---------------- -------------------- --------------------
MOUNTED              SNAPSHOT STANDBY MAXIMUM PERFORMANCE  UNPROTECTED
1
2
3
4
5
6
7

12.4 快照备库到open状态

# 备库到open可读可写状态
SQL> alter database open;
# 查看 OPEN_MODE
SQL> select open_mode,database_role,protection_mode,protection_level from v$database;
OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE      PROTECTION_LEVEL
-------------------- ---------------- -------------------- --------------------
READ WRITE           SNAPSHOT STANDBY MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE
1
2
3
4
5
6
7

12.5 快照备库对主库的日志接收

当主库切换日志时，备库依然可以接受日志，只是不应用。

# 主库切换日志
SQL> alter system archive log current;
# 主备都是相同的序号
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
            88
1
2
3
4
5
6
7

# 查看日志alert日志位置
SQL> select name,value from V$diag_info where name in('Diag Trace','Diag Alert'); 
# 主库alert信息
[oracle@l080l trace]$ cat /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log 
Wed Aug 25 21:52:16 2021
ALTER SYSTEM ARCHIVE LOG
Wed Aug 25 21:52:16 2021
Thread 1 advanced to log sequence 89 (LGWR switch)
  Current log# 2 seq# 89 mem# 0: /u01/app/oracle/oradata/orcl/redo02.log
Wed Aug 25 21:52:16 2021
Archived Log entry 67 added for thread 1 sequence 88 ID 0x5df896fc dest 1:
Wed Aug 25 21:52:16 2021
TT00: Standby redo logfile selected for thread 1 sequence 89 for destination LOG_ARCHIVE_DEST_2
# 备库alert信息
RFS[3]: Selected log 5 for thread 1 sequence 89 dbid 1576583420 branch 1048802686
Wed Aug 25 21:52:15 2021
Archived Log entry 16 added for thread 1 sequence 88 ID 0x5df896fc dest 1:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

12.6 快照备库可读写

此时快照备库是可读写的 READ WRITE 状态

SQL> select open_mode,database_role,protection_mode,protection_level from v$database;
OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE      PROTECTION_LEVEL
-------------------- ---------------- -------------------- --------------------
READ WRITE           SNAPSHOT STANDBY MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE
1
2
3
4

12.7 恢复为物理备库

# 备库到mount状态
shutdown immediate
startup mount
# 恢复到物理备库
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
Database altered.
# 重新开启数据库
shutdown immediate
startup
# 开启同步
SQL> alter database recover managed standby database using current logfile disconnect from session;

# 验证
SQL> select open_mode,database_role,protection_mode,protection_level from v$database;
OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE      PROTECTION_LEVEL
-------------------- ---------------- -------------------- --------------------
READ ONLY WITH APPLY PHYSICAL STANDBY MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE
# 切换日志
SQL> alter system archive log current;
SQL> select max(sequence#) from v$archived_log;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

13. DG维护相关

13.1 开关机

---------------------------------------------------------------------------------
# 启动顺序：先启动备库，后启动主库
# 关闭顺序：先关闭主库，后关闭备库
---------------------------------------------------------------------------------
# 1、正确开启顺序
# 备库:
SQL> STARTUP MOUNT
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  DISCONNECT FROM SESSION;
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
		# 逻辑备库:
			SQL> STARTUP
			SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# 主库:
SQL> STARTUP
---------------------------------------------------------------------------------
# 2、正确关闭顺序
# 主库:
SQL> SHUTDOWN IMMEDIATE
# 备库:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
		# 逻辑备库:
		SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SQL> SHUTDOWN IMMEDIATE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

13.2 重建DG案例ORA-19573\ORA-19573

Standby DG重建时遇到的小问题。

# restore database报错
ORA-19573 : cannot obtain exclusive enqueue for datafile 4
# 数据文件离线
SQL> alter database datafile 4 offline drop;
# 确保处于mount状态再执行restore database
RMAN> startup mount
# restore database报新的错误
ORA-01156: recovery or flashback in progress may need access to files
# 解决方法：
# 关闭备库日志应用进程
SQL> alter database recover managed standby database cancel;
RMAN> restore database
1
2
3
4
5
6
7
8
9
10
11
12

13.3 ORA-10456

ORA-10456:cannot open standby database; media recovery session may be in progress

SQL> select * from test;
select * from test;
                 *
ERROR at line 1:
ORA-01219: database not open: queries allowed on fixed tables/views only

SQL> select name,open_mode from v$database;
NAME           OPEN_MODE
---------      --------------------
NOIDA          MOUNTED
-- 报错
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-10456: cannot open standby database; media recovery session may be in progress
-- solution
SQL> alter database recover managed standby database cancel;
Database altered.

SQL> alter database open;
Database altered.

SQL> alter database recover managed standby database using current logfile disconnect ; 
Database altered.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

欢迎关注公众号：一介IT
本站博文抢先发布在公众号。