标签：following   rtu   current   rdf   opera   fixed   lis   least   spfile   

oracle dataguard配置说明
系统环境

rh linux 6.3
oracle 11g
物理备库和逻辑备库

物理备库：physical standby, 备库与主数据库完全一样的备份（数据为物理块到块的复制），数据库的表和索引都相同，物理结构是相同的。基于RMAN实现，传输和直接应用redo log来实现。
逻辑备库：logical standby ，逻辑备库，standby侧的逻辑信息是一样的，物理信息和数据结构是不同的，其实现原理是将redo log中的信息提取出SQL，然后在standby执行相应的SQL语句。 (logical standy数据库是可以OPEN的，也可以用户数据库用户的查询和报表，但要求数据库表必须有primary key. —此项待查，实验进行相应的验证）

在正式环境做备库时，我们一般使用物理备库。
关于Oacrle ADG的授权说明

Oracle Active Data Guard requires a separate license and can only be used with Oracle Database Enterprise Edition. It can be purchased as the Active Data Guard Option for Oracle Database Enterprise Edition. It is also included with Oracle GoldenGate. Basic Data Guard functionality does not require a separate license, and it is included with Oracle Enterprise Edition.

ADG只能用于oracle企业版，但是需要购买额外的license 。 （OGG也是相同的，需要额外购买）
BASIC Data Guard ，也就是基本的DG，是不需要购买额外的license的。 这个是oracle企业版自带的。
Oracle Data Guard 和 Oracle Active Data Guard

DG:：oracle数据库备库，数据库状态为mount状态，数据库信息不可查看。
ADG ：oracle active data guard ，oracle备库处理Open Read-only状态，数据库表等信息可查。
DG的三种数据保护模式

最大保护模式： max protection, 数据零丢失，数据双至多重数据保障。
它要求所有的事务在提交前其redo不仅被写入到本地的online redo log，还要同时提交到standby数据库的standby redo log，并确认redo数据至少在一个standby数据库可用(如果有多个的话)，然后才会在primary数据库上提交。如果出现了什么故障导致standby数据库不可用的话，primary数据库会被shutdown。
LGWR SYNC将数据同步传输，如遇到网络故障，如网络中断，则主库会down机。
最大可用模式：max availability,数据零丢失，LGWR SYNC数据同步传输。 all redo data has been written to online redo log and at least one of the standy db’s online redo log , the transaction 才提交。
若redo stream不能同时写入到 synchronized standby db, 则 会按照maxinum performance操作，直到可以同步写入的时候。
最高性能模式： max performanc模式， 数据最少丢失，因为使用LGWR和ARCH来做数据库的异步传输的应用。 事务可以随时提交,当前primary库中的redo数据至少要保证写入到一个standby数据库中。
如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护而仅对primary数据库有轻微的性能影响

一般在应用环境中，用最大可以模式比较多。
配置传统的DG备库

主：192.168.5.1 DOG
备：192.168.5.2 DOGSBY

配置主机hosts文件
/etc/hosts
192.168.5.1 oracle01.mytest.com oracle01
192.168.5.2 oracle02.mytest.com oracle02

主备库配置listener并配置静态监听
listener监听两边的数据库连接，同时在主备切换时，可以顺利进行。
此步其实不是必须的，我们把监听修改为了静态监听了。
主：

备：

主备库配置tnsnames
主备：

主库配置DG所需要的参数信息
规划归档：
配置主库的归档日志路径：
/app/arch/dog

配置备库的归档日志路径：
/app/arch/dogsby

主库操作：
alter system set log_archive_config=‘DG_CONFIG=(DOG,DOGSBY)’ scope=both sid=’’;
alter system set log_archive_dest_1=‘LOCATION=/app/arch/dog/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DOG’ scope=both sid=’’; #这个配置的
alter system set log_archive_dest_2=‘SERVICE=DOGSBY LGWR ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DOGSBY’ scope=both sid=’’; #这里使用的tnsnanes.ora配置来串接两个数据库，主与备
alter system set log_archive_dest_state_1=enable;
alter system set log_archive_dest_state_2=enable
alter system set fal_client=‘DOG’ scope=both sid=’’;
alter system set fal_server=‘DOGSBY’ scope=both sid=’’;
alter system set db_file_name_convert=’/app/oracle/oradata/DOGSBY’,’/app/oracle/oradata/DOG’ scope=spfile sid=’’; # 用于主备切换，如果主库生效，则需要重启主库。 在线库可以不重启，在下次数据库重启时，自动优先加载spfile时，生效。
alter system set log_file_name_convert=’/app/oracle/oradata/DOGSBY’,’/app/oracle/oradata/DOG’ scope=spfile sid=’*’;
alter system set standby_file_management=auto;

主： 创建pfile
create pfile from spfile # 备库的启动参数，通过这个pfile来启动。

修改之后的参数文件 ：
主库：

备库：

创建standby redo log
主： 用于主备切换时，主切换到备之后的online redo log
ALTER DATABASE ADD STANDBY LOGFILE group 4 (’/app/oracle/oradata/DOG/slog4.log’) SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE group 5 (’/app/oracle/oradata/DOG/slog5.log’) SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE group 6 (’/app/oracle/oradata/DOG/slog3.log’) SIZE 50M;

备库：备升级为主，作用主的standby日志。
在数据库mount之后，在应用归档日志之前创建相应的standby redo log，用于接收主库传过来的online redo log
ALTER DATABASE ADD STANDBY LOGFILE group 4 (’/app/oracle/oradata/DOGSBY/slog4.log’) SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE group 5 (’/app/oracle/oradata/DOGSBY/slog5.log’) SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE group 6 (’/app/oracle/oradata/DOGSBY/slog6.log’) SIZE 50M;

备库建立相应的目录
mkdir -p /app/arch/dogsby
mkdir -p /app/oracle/oradata/DOGSBY
mkdir -p /app/oracle/fast_recovery_area/DOGSBY
mkdir -p /app/oracle/admin/DOGSBY/adump
用以存放数据库相应的目录

密码文件
主库的密码文件传输到备库
如无密码文件，则可使用orapwd命令生成 密码文件

数据库恢复
主库备份并将备份传输到备库机器上，使用RMAN进行数据库恢复。

主库创建standby controlfile，将此文件传输到备份库，然后进行相应的数据库恢复
alter database create standby controlfile as ‘/tmp/control01.ctl’

scp到备库的/tmp目录
备库：
将控制文件存放到相应的目录下：
cp /tmp/control01.ctl /app/oracle/oradata/DOGSBY/control01.ctl
cp /tmp/control01.ctl /app/oracle/fast_recovery_area/DOGSBY/control01.ctl

主：
备份数据库

RMAN> backup database plus archivelog;

Starting backup at 06-AUG-19
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=266 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=5 RECID=1 STAMP=1015604850
input archived log thread=1 sequence=6 RECID=2 STAMP=1015604853
input archived log thread=1 sequence=7 RECID=3 STAMP=1015605358
input archived log thread=1 sequence=8 RECID=4 STAMP=1015608784
channel ORA_DISK_1: starting piece 1 at 06-AUG-19
channel ORA_DISK_1: finished piece 1 at 06-AUG-19
piece handle=/app/oracle/fast_recovery_area/DOG/backupset/2019_08_06/o1_mf_annnn_TAG20190806T173304_gnllbjyo_.bkp tag=TAG20190806T173304 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 06-AUG-19

Starting backup at 06-AUG-19
using channel ORA_DISK_1
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=/app/oracle/oradata/DOG/system01.dbf
input datafile file number=00002 name=/app/oracle/oradata/DOG/sysaux01.dbf
input datafile file number=00003 name=/app/oracle/oradata/DOG/undotbs01.dbf
input datafile file number=00004 name=/app/oracle/oradata/DOG/users01.dbf
channel ORA_DISK_1: starting piece 1 at 06-AUG-19
channel ORA_DISK_1: finished piece 1 at 06-AUG-19
piece handle=/app/oracle/fast_recovery_area/DOG/backupset/2019_08_06/o1_mf_nnndf_TAG20190806T173306_gnllbl65_.bkp tag=TAG20190806T173306 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
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 06-AUG-19
channel ORA_DISK_1: finished piece 1 at 06-AUG-19
piece handle=/app/oracle/fast_recovery_area/DOG/backupset/2019_08_06/o1_mf_ncsnf_TAG20190806T173306_gnllbt8o_.bkp tag=TAG20190806T173306 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 06-AUG-19

Starting backup at 06-AUG-19
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=9 RECID=5 STAMP=1015608795
channel ORA_DISK_1: starting piece 1 at 06-AUG-19
channel ORA_DISK_1: finished piece 1 at 06-AUG-19
piece handle=/app/oracle/fast_recovery_area/DOG/backupset/2019_08_06/o1_mf_annnn_TAG20190806T173315_gnllbvdc_.bkp tag=TAG20190806T173315 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 06-AUG-19

将备份传输到备库，对应的目录下。 以便恢复的时候，不用指定备份片的目录了

备库：
mkdir -p /app/oracle/fast_recovery_area/DOG/backupset/2019_08_06/
sqlplus / as sysdba
startup nomount pfile=initDOG.ora
alter database mountstandby database;

restore备库：

[oracle@oracle02 trace]$ rman target /

Recovery Manager: Release 11.2.0.4.0 - Production on Tue Aug 6 18:00:42 2019

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

connected to target database: DOG (DBID=4198870852, not open)

RMAN> restore database;

Starting restore at 06-AUG-19
Starting implicit crosscheck backup at 06-AUG-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=393 device type=DISK
Crosschecked 4 objects
Finished implicit crosscheck backup at 06-AUG-19

Starting implicit crosscheck copy at 06-AUG-19
using channel ORA_DISK_1
Crosschecked 2 objects
Finished implicit crosscheck copy at 06-AUG-19

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 /app/oracle/oradata/DOGSBY/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /app/oracle/oradata/DOGSBY/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /app/oracle/oradata/DOGSBY/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /app/oracle/oradata/DOGSBY/users01.dbf
channel ORA_DISK_1: reading from backup piece /app/oracle/fast_recovery_area/DOG/backupset/2019_08_06/o1_mf_nnndf_TAG20190806T173306_gnllbl65_.bkp
channel ORA_DISK_1: piece handle=/app/oracle/fast_recovery_area/DOG/backupset/2019_08_06/o1_mf_nnndf_TAG20190806T173306_gnllbl65_.bkp tag=TAG20190806T173306
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
Finished restore at 06-AUG-19

在standy备库端启动应用归档日志：
alter database recover managed standby database disconnect from session;

备库端的应用日志：
Tue Aug 06 19:28:17 2019
ALTER DATABASE RECOVER managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (DOGSBY)
Tue Aug 06 19:28:17 2019 开始应用日志了
MRP0 started with pid=24, OS id=24846
MRP0: Background Managed Standby Recovery process started (DOGSBY)
started logmerger process
Tue Aug 06 19:28:22 2019
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 4 slaves 使用并行者进程
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /app/oracle/product/11.2.0/dbhome_1/dbs/arch1_9_1015599238.dbf
Media Recovery Waiting for thread 1 sequence 10
Completed: ALTER DATABASE RECOVER managed standby database disconnect from session
Tue Aug 06 19:32:59 2019
Using STANDBY_ARCHIVE_DEST parameter default value as /app/arch/dogsby/
Tue Aug 06 19:40:01 2019
db_recovery_file_dest_size of 41820 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Tue Aug 06 19:42:05 2019
RFS[1]: Assigned to RFS process 25175 RFS进程
RFS[1]: Opened log for thread 1 sequence 12 dbid -96096444 branch 1015599238
Tue Aug 06 19:42:05 2019
RFS[2]: Assigned to RFS process 25177
RFS[2]: Opened log for thread 1 sequence 11 dbid -96096444 branch 1015599238
Archived Log entry 2 added for thread 1 sequence 12 rlc 1015599238 ID 0xfa453f44 dest 2: 新来的日志
Archived Log entry 3 added for thread 1 sequence 11 rlc 1015599238 ID 0xfa453f44 dest 2:
Tue Aug 06 19:42:05 2019
RFS[3]: Assigned to RFS process 25179
RFS[3]: Opened log for thread 1 sequence 10 dbid -96096444 branch 1015599238
Archived Log entry 4 added for thread 1 sequence 10 rlc 1015599238 ID 0xfa453f44 dest 2:
RFS[2]: Selected log 4 for thread 1 sequence 13 dbid -96096444 branch 1015599238
Tue Aug 06 19:42:07 2019
Archived Log entry 5 added for thread 1 sequence 13 ID 0xfa453f44 dest 1:
Tue Aug 06 19:42:07 2019
Primary database is in MAXIMUM PERFORMANCE mode 使用最大性能模式
RFS[4]: Assigned to RFS process 25181
RFS[4]: Selected log 4 for thread 1 sequence 14 dbid -96096444 branch 1015599238
Tue Aug 06 19:42:13 2019
Media Recovery Log /app/arch/dogsby/1_10_1015599238.dbf
Media Recovery Log /app/arch/dogsby/1_11_1015599238.dbf
Media Recovery Log /app/arch/dogsby/1_12_1015599238.dbf
Media Recovery Log /app/arch/dogsby/1_13_1015599238.dbf
Media Recovery Waiting for thread 1 sequence 14 (in transit) 备库端应用的四个日志文件
Tue Aug 06 19:43:57 2019
RFS[4]: Selected log 5 for thread 1 sequence 15 dbid -96096444 branch 1015599238
Tue Aug 06 19:43:57 2019
Archived Log entry 6 added for thread 1 sequence 14 ID 0xfa453f44 dest 1:
Tue Aug 06 19:43:59 2019
Media Recovery Log /app/arch/dogsby/1_14_1015599238.dbf
Media Recovery Waiting for thread 1 sequence 15 (in transit)

Tue Aug 06 22:00:26 2019
RFS[4]: Selected log 4 for thread 1 sequence 16 dbid -96096444 branch 1015599238
Tue Aug 06 22:00:26 2019
Archived Log entry 7 added for thread 1 sequence 15 ID 0xfa453f44 dest 1:
Tue Aug 06 22:00:28 2019
Media Recovery Log /app/arch/dogsby/1_15_1015599238.dbf
Media Recovery Waiting for thread 1 sequence 16 (in transit)
Tue Aug 06 22:13:59 2019
Warning: VKTM detected a time drift.
Time drifts can result in an unexpected behavior such as time-outs. Please check trace file for more details.
Wed Aug 07 04:00:19 2019
RFS[4]: Selected log 5 for thread 1 sequence 17 dbid -96096444 branch 1015599238
Wed Aug 07 04:00:20 2019
Archived Log entry 8 added for thread 1 sequence 16 ID 0xfa453f44 dest 1:
Wed Aug 07 04:00:21 2019
Media Recovery Log /app/arch/dogsby/1_16_1015599238.dbf 主库端进行日志切换之后，自动应用新的日志
Media Recovery Waiting for thread 1 sequence 17 (in transit)

standby数据库查看日志应用情况 ：
select thread#,sequence#,archived,applied from v$archived_log order by first_time;

SQL> select thread#,sequence#,archived,applied,t.name,t.dest_id,t.creator,t.standby_dest from v$archived_log t order by first_time;

THREAD# SEQUENCE# ARC APPLIED NAME DEST_ID CREATOR STA

8 rows selected.

primary主库端查看日志应用情况 ：

SQL> select thread#,sequence#,archived,applied,t.name,t.dest_id,t.creator,t.standby_dest from v$archived_log t order by first_time;

THREAD# SEQUENCE# ARC APPLIED NAME DEST_ID CREATOR STA

可以看到name为DOGSBY的显示的为日志应用的情况，其中applied字段为YES，则已应用，这个和备库端的是对应起来的。
creater为LGWR，则是传输的redo日志到standby数据库端应用。

切换日志后，主备库日志分析
主：
alter system switch logfile

Wed Aug 07 09:20:45 2019
Thread 1 advanced to log sequence 18 (LGWR switch)
Current log# 3 seq# 18 mem# 0: /app/oracle/oradata/DOG/redo03.log
Wed Aug 07 09:20:45 2019
LNS: Standby redo logfile selected for thread 1 sequence 18 for destination LOG_ARCHIVE_DEST_2 LNS进程查看到 和 LOG_ARCHIVE_DEST_2
Wed Aug 07 09:20:45 2019
Archived Log entry 21 added for thread 1 sequence 17 ID 0xfa453f44 dest 1:

备库日志

Wed Aug 07 04:00:21 2019
Media Recovery Log /app/arch/dogsby/1_16_1015599238.dbf
Media Recovery Waiting for thread 1 sequence 17 (in transit)
Wed Aug 07 09:20:44 2019
RFS[4]: Selected log 4 for thread 1 sequence 18 dbid -96096444 branch 1015599238 ：RFS进程传输
Wed Aug 07 09:20:45 2019
Archived Log entry 9 added for thread 1 sequence 17 ID 0xfa453f44 dest 1:
Wed Aug 07 09:20:47 2019
Media Recovery Log /app/arch/dogsby/1_17_1015599238.dbf
Media Recovery Waiting for thread 1 sequence 18 (in transit) 应用日志

查看v$dataguard_status
此视图保留的dg运行过程状态

Log Transport Services Control 0 256 0 YES 2019-08-07 09:20:45
ARC1: Beginning to archive thread 1 sequence 17 (1026670-1048932)

Log Transport Services Control 0 257 0 YES 2019-08-07 09:20:45
LNS: Completed archiving log 2 thread 1 sequence 17

Log Transport Services Warning 1 258 0 NO 2019-08-07 09:20:45
LNS: Standby redo logfile selected for thread 1 sequence 18 for destination LOG_ARCHIVE_DEST_2

Log Transport Services Control 0 259 0 YES 2019-08-07 09:20:45
LNS: Beginning to archive log 3 thread 1 sequence 18

Log Transport Services Control 0 260 0 YES 2019-08-07 09:20:45
ARC1: Completed archiving thread 1 sequence 17 (1026670-1048932) 可以看到日志传输和归档状态等，及各进程在不同时间点的操作

创建测试数据表验证

在主库创建测试表，并在备库提升至read-only模式验证
主：

SQL> create table scott.test01 as select * from dba_objects;

Table created.

SQL> select count(*) from scott.test01;

SQL> alter system switch logfile;

System altered.

验证数据库已同步之后，再以read only standby方式打开standby数据库：
备：
alter database recover managed standby database cancel;
shutdown immediate;
startup mount;
alter database open read only;
select count(*） from scott.test01;

SQL> alter database recover managed standby database cancel;

Database altered.

SQL> shutdown immediate;
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.

Total System Global Area 1068937216 bytes
Fixed Size 2260088 bytes
Variable Size 444597128 bytes
Database Buffers 616562688 bytes
Redo Buffers 5517312 bytes
Database mounted.
SQL> alter database read only;
alter database read only
*
ERROR at line 1:
ORA-02231: missing or invalid option to ALTER DATABASE

SQL> alter database open read only;

Database altered.

SQL> select count(*) from scott.test01;

在这里可以查看到数据已同步。

再次关闭备库，并恢复DG的应用
shutdown immediate;
startup nomount ; # 此处已创建spfile
alter database mount standby database
alter database recover managed standby database disconnect from session; #启用归档日志的应用。

主库：

当启动归档应用的时候，则日志应用可再次使用

Wed Aug 07 09:42:57 2019
LNS: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)
LNS: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Error 3135 for archive log file 2 to ‘DOGSBY‘
Errors in file /app/oracle/diag/rdbms/dog/DOG/trace/DOG_nsa2_18225.trc:
ORA-03135: connection lost contact
LNS: Failed to archive log 2 thread 1 sequence 20 (3135)
Wed Aug 07 09:43:29 2019
ALTER SYSTEM SET log_archive_dest_state_2=‘ENABLE‘ SCOPE=MEMORY SID=‘*‘;
Wed Aug 07 09:43:29 2019
Thread 1 advanced to log sequence 21 (LGWR switch)
Current log# 3 seq# 21 mem# 0: /app/oracle/oradata/DOG/redo03.log
Wed Aug 07 09:43:29 2019
Archived Log entry 26 added for thread 1 sequence 20 ID 0xfa453f44 dest 1:
Wed Aug 07 09:43:29 2019

LGWR: Setting ‘active‘ archival for destination LOG_ARCHIVE_DEST_2

ARC3: Standby redo logfile selected for thread 1 sequence 20 for destination LOG_ARCHIVE_DEST_2
LNS: Standby redo logfile selected for thread 1 sequence 21 for destination LOG_ARCHIVE_DEST_2

主备切换
主：查看目录
select name,database_role,switchover_status from v$database;
当主库的switchover_status的值为to_standby时，则主备库才可以切换。

主备切换命令：
主库操作
alter database commit to switchover to phyical standby
备库操作：
alter database commit to switchowver to primary;

主库：

select name,database_role,switchover_status from v$database;

NAME DATABASE_ROLE SWITCHOVER_STATUS

DOG PRIMARY SESSIONS ACTIVE

备库：

SQL> select name,database_role,switchover_status from v$database;

NAME DATABASE_ROLE SWITCHOVER_STATUS

DOG PHYSICAL STANDBY NOT ALLOWED 不允许状态

当主库信息的状态为：SESSIONS ACTIVE状态时，则先将physical standby with session shutown，然后切换状态
alter database commit to switchover to physical standby ; #切换（TO STANDBY状态时切换）
主：
alter database commit to switchover to physical standby with session shutdown; # 断开session

执行上述操作后主库的日志：

Wed Aug 07 10:52:32 2019
alter database commit to switchover to physical standby with session shutdown
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 23988] (DOG)
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Waiting for all FAL entries to be archived...
All FAL entries have been archived.
Waiting for potential Physical Standby switchover target to become synchronized...
Active, synchronized Physical Standby switchover target has been identified
Switchover End-Of-Redo Log thread 1 sequence 21 has been fixed
Switchover: Primary highest seen SCN set to 0x0.0x1068b3
ARCH: Noswitch archival of thread 1, sequence 21
ARCH: End-Of-Redo Branch archival of thread 1 sequence 21
ARCH: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
ARCH: Standby redo logfile selected for thread 1 sequence 21 for destination LOG_ARCHIVE_DEST_2
Archived Log entry 28 added for thread 1 sequence 21 ID 0xfa453f44 dest 1:
Expanded controlfile section 11 from 28 to 255 records
Requested to grow by 227 records; added 9 blocks of records
ARCH: Archiving is disabled due to current logfile archival
Primary will check for some target standby to have received alls redo
Final check for a synchronized target standby. Check will be made once.
LOG_ARCHIVE_DEST_2 is a potential Physical Standby switchover target
Active, synchronized target has been identified
Target has also received all redo
Backup controlfile written to trace file /app/oracle/diag/rdbms/dog/DOG/trace/DOG_ora_23988.trc
Clearing standby activation ID 4198842180 (0xfa453f44)
The primary database controlfile was created using the
‘MAXLOGFILES 16‘ clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE ‘srl1.f‘ SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE ‘srl2.f‘ SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE ‘srl3.f‘ SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE ‘srl4.f‘ SIZE 52428800;
Archivelog for thread 1 sequence 21 required for standby recovery
Switchover: Primary controlfile converted to standby controlfile succesfully. #控制文件要的到standby数据库的控制文件了
Switchover: Complete - Database shutdown required
USER (ospid: 23988): terminating the instance
Instance terminated by USER, pid = 23988
Completed: alter database commit to switchover to physical standby with session shutdown #直接关闭数据库了
Shutting down instance (abort)
License high water mark = 6
Wed Aug 07 10:52:36 2019
Instance shutdown complete

而此时查看备库的日志为：

Wed Aug 07 10:52:34 2019
RFS[3]: Assigned to RFS process 12302
RFS[3]: Selected log 5 for thread 1 sequence 21 dbid -96096444 branch 1015599238
Wed Aug 07 10:52:34 2019
Archived Log entry 13 added for thread 1 sequence 21 ID 0xfa453f44 dest 1:
Wed Aug 07 10:52:34 2019
RFS[4]: Assigned to RFS process 12300
RFS[4]: Possible network disconnect with primary database
Wed Aug 07 10:52:34 2019
RFS[1]: Possible network disconnect with primary database 断开与原主库的连接
Wed Aug 07 10:52:35 2019
Media Recovery Log /app/arch/dogsby/1_21_1015599238.dbf 应用了一个日志
Identified End-Of-Redo (switchover) for thread 1 sequence 21 at SCN 0x0.1068b3
Resetting standby activation ID 4198842180 (0xfa453f44) 重置了这个操作
Media Recovery End-Of-Redo indicator encountered
Media Recovery Continuing
Media Recovery Waiting for thread 1 sequence 22 应用了日志

此时再查看备库的状态：
而此时standby备库的状态由原来的NOT ALLOWED状态，已经到的TO_PRIMARY状态了

SQL> select name,database_role,switchover_status from v$database;

NAME DATABASE_ROLE SWITCHOVER_STATUS

DOG PHYSICAL STANDBY NOT ALLOWED

SQL>
SQL>
SQL> select name,database_role,switchover_status from v$database;

NAME DATABASE_ROLE SWITCHOVER_STATUS

DOG PHYSICAL STANDBY TO PRIMARY 主库执行切换后，备库收到信息后，则此状态变了。

那么将备库提升为主库：

SQL> select name,database_role,switchover_status from v$database;

NAME DATABASE_ROLE SWITCHOVER_STATUS

DOG PHYSICAL STANDBY TO PRIMARY

SQL> alter database commit to switchover to primary;

Database altered.

SQL> select name,open_mode from v$database;

NAME OPEN_MODE

DOG MOUNTED

SQL> alter database open;

Database altered.
SQL>
SQL>
SQL> select name,database_role,switchover_status from v$database;

NAME DATABASE_ROLE SWITCHOVER_STATUS

DOG PRIMARY FAILED DESTINATION # 因为原为切换之后，并没有启动

备库提升为主库后，备库的alter日志：

Identified End-Of-Redo (switchover) for thread 1 sequence 21 at SCN 0x0.1068b3
Resetting standby activation ID 4198842180 (0xfa453f44)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Continuing
Media Recovery Waiting for thread 1 sequence 22
Wed Aug 07 11:01:15 2019
alter database commit to switchover to primary
ALTER DATABASE SWITCHOVER TO PRIMARY (DOGSBY) 提升为主库
Maximum wait for role transition is 15 minutes.
Switchover: Media recovery is still active
Role Change: Canceling MRP - no more redo to apply
Wed Aug 07 11:01:16 2019
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /app/oracle/diag/rdbms/dogsby/DOGSBY/trace/DOGSBY_pr00_10873.trc:
ORA-16037: user requested cancel of managed recovery operation
Recovery interrupted!
Wed Aug 07 11:01:17 2019
MRP0: Background Media Recovery process shutdown (DOGSBY)
Role Change: Canceled MRP
Backup controlfile written to trace file /app/oracle/diag/rdbms/dogsby/DOGSBY/trace/DOGSBY_ora_10834.trc
SwitchOver after complete recovery through change 1075379
Online log /app/oracle/oradata/DOGSBY/redo01.log: Thread 1 Group 1 was previously cleared 当前redo log使用情况
Online log /app/oracle/oradata/DOGSBY/redo02.log: Thread 1 Group 2 was previously cleared
Online log /app/oracle/oradata/DOGSBY/redo03.log: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 1075377
Switchover: Complete - Database mounted as primary
Completed: alter database commit to switchover to primary
Wed Aug 07 11:01:28 2019
ARC1: Becoming the ‘no SRL‘ ARCH
Wed Aug 07 11:01:52 2019
alter database open 打开数据库操作
Wed Aug 07 11:01:52 2019
Assigning activation ID 4198914298 (0xfa4658fa)
Thread 1 advanced to log sequence 23 (thread open)
Thread 1 opened at log sequence 23
Current log# 2 seq# 23 mem# 0: /app/oracle/oradata/DOGSBY/redo02.log 当前current log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Aug 07 11:01:52 2019
SMON: enabling cache recovery
Wed Aug 07 11:01:52 2019
Archived Log entry 14 added for thread 1 sequence 22 ID 0xfa4658fa dest 1:
Wed Aug 07 11:01:52 2019
NSA2 started with pid=24, OS id=12523
Wed Aug 07 11:01:52 2019
Error 1034 received logging on to the standby
PING[ARC2]: Heartbeat failed to connect to standby ‘DOG‘. Error is 1034. 因为原来的主库切换后shutdown abort了，所以现在还连接不上
[10834] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:2397233832 end:2397233892 diff:60 (0 seconds)
Dictionary check beginning
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Wed Aug 07 11:01:53 2019
QMNC started with pid=25, OS id=12525
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Completed: alter database open
Wed Aug 07 11:01:53 2019
Starting background process CJQ0
Wed Aug 07 11:01:53 2019
CJQ0 started with pid=28, OS id=12541
Error 1034 received logging on to the standby
FAL[server, ARC2]: Error 1034 creating remote archivelog file ‘DOG‘
FAL[server, ARC2]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance DOGSBY - Archival Error. Archiver continuing.
Thread 1 advanced to log sequence 24 (LGWR switch)
Current log# 3 seq# 24 mem# 0: /app/oracle/oradata/DOGSBY/redo03.log
Wed Aug 07 11:01:55 2019
ARC3: STARTING ARCH PROCESSES
Wed Aug 07 11:01:55 2019
ARC4 started with pid=26, OS id=12544
ARC4: Archival started
ARC3: STARTING ARCH PROCESSES COMPLETE
Archived Log entry 15 added for thread 1 sequence 23 ID 0xfa4658fa dest 1:
Shutting down archive processes
ARCH shutting down
ARC4: Archival stopped

原主库操作：
因为原主库切换为当前备库了。
所以启动新备库：

SQL> startup nomount
ORACLE instance started.

Total System Global Area 1068937216 bytes
Fixed Size 2260088 bytes
Variable Size 444597128 bytes
Database Buffers 616562688 bytes
Redo Buffers 5517312 bytes
SQL> alter database mount standby database;

Database altered.

SQL> select name,database_role,switchover_status from v$database; 查看状态，新备库需要应用日志

NAME DATABASE_ROLE SWITCHOVER_STATUS

DOG PHYSICAL STANDBY RECOVERY NEEDED

SQL> alter database recover managed standby database disconnect from session; 启动应用日志

Database altered.

SQL> select name,database_role,switchover_status from v$database; 状态正常

NAME DATABASE_ROLE SWITCHOVER_STATUS

DOG PHYSICAL STANDBY NOT ALLOWED
SQL> select thread#,sequence#,archived,applied,t.name,t.dest_id,t.creator,t.standby_dest from v$archived_log t order by first_time;

查看日志的应用状态，当同步应用时，则此就是一次完整的数据主备切换。

常用管理命令
standby查看备库管理进程

SQL> select process,client_process,sequence#,status from v$managed_standby;

PROCESS CLIENT_P SEQUENCE# STATUS

ARCH ARCH 15 CLOSING
ARCH ARCH 0 CONNECTED
ARCH ARCH 16 CLOSING
ARCH ARCH 14 CLOSING 四个归档
MRP0 N/A 17 WAIT_FOR_LOG
RFS ARCH 0 IDLE
RFS UNKNOWN 0 IDLE
RFS UNKNOWN 0 IDLE
RFS LGWR 17 IDLE 四个RFS进程，这个和alert日志中的信息对应

查看主库的管理进程
select pid,process,status,sequence# from v$managed_standby;

SQL> select pid,process,status,sequence# from v$managed_standby;

主备状态检查 ：
select DATABASE_ROLE from vdatabase;selectOPENMODE,PROTECTIONMODE,PROTECTIONLEVEL,SWITCHOVERSTATUSfromv

database;selectOPENM?ODE,PROTECTIONM?ODE,PROTECTIONL?EVEL,SWITCHOVERS?TATUSfromvdatabase;
SELECT COUNT(*) FROM V$SESSION WHERE USERNAME IS NOT NULL;

备库状态检查：
select DATABASE_ROLE from vdatabase;selectOPENMODE,PROTECTIONMODE,PROTECTIONLEVEL,SWITCHOVERSTATUSfromv

database;selectOPENM?ODE,PROTECTIONM?ODE,PROTECTIONL?EVEL,SWITCHOVERS?TATUSfromvdatabase;
select open_mode, protection_mode, protection_level, switchover_status from v$database;

在备库端启用和停用数据日志应用
管理日志应用服务
在standby端将数据库启动到read open状态
alter database open read only;
在standby端启动Standby redo日志
alter database recover managed standby database disconnect from session;
停止Standby redo日志应用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
再次启动Standby redo日志
alter database recover managed standby database disconnect from session;

主备切换：
主至备：
alter database commit to switchover to physical standby ; (TO STANDBY状态时）
alter database commit to switchover to physical standby disconnect from shutdown; (v$database swithover_status为SESSION ACTIVE状态时,切换后数据库为shudown abort）
startup nomout; (新备库启动步骤）
alter database mount standby database ;
alter database recover managed standby database disconnect from session;
alter database reover managed standby database cancel;

备至主：
alter database commit to switchover to primary; （TO PRIMARY状态时）
alter database commit to switchover to primary disconnect from shutdown ; (v$database swithover_status为SESSION ACTIVE状态时）
alter database open; 新主库启动至open

查看数据库状态
select name,open_mode,database_role,switchover_status from v$database;

修改保护模式：（默认为MAXIMUM PERFORMANCE模式）
alter database set standby database to maximize availability;

查看日志：

select group#, bytes/1024/1024 from v$log;--查看原有日志
select group#, bytes/1024/1024 from v$standby_log;--查看standby日志

引申思考
上述步骤便是传统的DG搭建模式，standby端为mount的状态，如果需要临时查看standby数据库中的数据，则需要将standby数据库提升至read only模式。应用完毕之后，再次到mount状态应用。

搭建过程中遇到的问题：
在初始化参数的设定时，设置归档路径时应用的是ENABLE大写的，而oracle在这个过程中不认大写，这是个错误操作，需要使用小写的enable参数设定。修改如下：
在初始化参数中指定 initTSTSBY.ora中
alter system set log_archive_dest_state_1=enable
alter system set log_archive_dest_state_2=enable
ADG的搭建过程：

基本配置步骤是相同的，区别在于ADG备库是直接read-only的状态
当上述DG的过程，直接提升为ADG
备库端操作：
alter database recover managed standby database cancel; 停止日志应用
alter database open read only;
alter database recover managed standby database disconnect from session;
主：
alter system switch logfile ；后续观察可以看日志的应用

在使用RMAN配置备库的时候，可以使用duplicate命令来直接实现ADG的搭建

rman target sys/oracle@DOG auxiliary sys/oracle@DOGSBY
run {
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate auxiliary channel stby1 type disk;
allocate auxiliary channel stby2 type disk;
duplicate target database for standby from active database nofilenamecheck;
release channel c1;
release channel c2;
release channel stby1;
release channel stby2;
}

执行过程中的日志信息。有兴趣的话，可以分析具体的步骤：

oracle@oracle01 ~]$ rman target sys/oracle@DOG auxiliary sys/oracle@DOGSBY

Recovery Manager: Release 11.2.0.4.0 - Production on Tue Apr 7 14:31:59 2015

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

connected to target database: DOG (DBID=4059664894)
connected to auxiliary database: DOG (not mounted)

RMAN>

RMAN>

RMAN>

RMAN> run {
2> allocate channel c1 type disk;
allocate channel c2 type disk;
3> 4> allocate auxiliary channel stby1 type disk;
5> allocate auxiliary channel stby2 type disk;
6> duplicate target database for standby from active database nofilenamecheck;
7> release channel c1;
8> release channel c2;
9> release channel stby1;
10> release channel stby2;
11> }

using target database control file instead of recovery catalog
allocated channel: c1
channel c1: SID=45 device type=DISK

allocated channel: c2
channel c2: SID=1 device type=DISK

allocated channel: stby1
channel stby1: SID=20 device type=DISK

allocated channel: stby2
channel stby2: SID=21 device type=DISK

Starting Duplicate Db at 2015-04-07 14:35:17

contents of Memory Script:
{
backup as copy reuse
targetfile ‘/app/oracle/product/11.2.0/dbhome_1/dbs/orapwDOG‘ auxiliary format
‘/app/oracle/product/11.2.0/dbhome_1/dbs/orapwDOGSBY‘ ;
}
executing Memory Script

Starting backup at 2015-04-07 14:35:17
Finished backup at 2015-04-07 14:35:19

contents of Memory Script:
{
backup as copy current controlfile for standby auxiliary format ‘/app/oracle/oradata/DOGSBY/control01.ctl‘;
restore clone controlfile to ‘/app/oracle/oradata/DOGSBY/control02.ctl‘ from
‘/app/oracle/oradata/DOGSBY/control01.ctl‘;
}
executing Memory Script

Starting backup at 2015-04-07 14:35:19
channel c1: starting datafile copy
copying standby control file
output file name=/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_DOG.f tag=TAG20150407T143519 RECID=1 STAMP=876407719
channel c1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 2015-04-07 14:35:20

Starting restore at 2015-04-07 14:35:20

channel stby2: skipped, AUTOBACKUP already found
channel stby1: copied control file copy
Finished restore at 2015-04-07 14:35:28

contents of Memory Script:
{
sql clone ‘alter database mount standby database‘;
}
executing Memory Script

sql statement: alter database mount standby database

contents of Memory Script:
{
set newname for tempfile 1 to
"/app/oracle/oradata/DOGSBY/temp01.dbf";
switch clone tempfile all;
set newname for datafile 1 to
"/app/oracle/oradata/DOGSBY/system01.dbf";
set newname for datafile 2 to
"/app/oracle/oradata/DOGSBY/sysaux01.dbf";
set newname for datafile 3 to
"/app/oracle/oradata/DOGSBY/undotbs01.dbf";
set newname for datafile 4 to
"/app/oracle/oradata/DOGSBY/users01.dbf";
backup as copy reuse
datafile 1 auxiliary format
"/app/oracle/oradata/DOGSBY/system01.dbf" datafile
2 auxiliary format
"/app/oracle/oradata/DOGSBY/sysaux01.dbf" datafile
3 auxiliary format
"/app/oracle/oradata/DOGSBY/undotbs01.dbf" datafile
4 auxiliary format
"/app/oracle/oradata/DOGSBY/users01.dbf" ;
sql ‘alter system archive log current‘;
}
executing Memory Script

executing command: SET NEWNAME

renamed tempfile 1 to /app/oracle/oradata/DOGSBY/temp01.dbf in control file

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

Starting backup at 2015-04-07 14:35:33
channel c1: starting datafile copy
input datafile file number=00001 name=/app/oracle/oradata/DOG/system01.dbf
channel c2: starting datafile copy
input datafile file number=00002 name=/app/oracle/oradata/DOG/sysaux01.dbf
output file name=/app/oracle/oradata/DOGSBY/system01.dbf tag=TAG20150407T143533
channel c1: datafile copy complete, elapsed time: 00:00:15
channel c1: starting datafile copy
input datafile file number=00003 name=/app/oracle/oradata/DOG/undotbs01.dbf
output file name=/app/oracle/oradata/DOGSBY/sysaux01.dbf tag=TAG20150407T143533
channel c2: datafile copy complete, elapsed time: 00:00:15
channel c2: starting datafile copy
input datafile file number=00004 name=/app/oracle/oradata/DOG/users01.dbf
output file name=/app/oracle/oradata/DOGSBY/undotbs01.dbf tag=TAG20150407T143533
channel c1: datafile copy complete, elapsed time: 00:00:01
output file name=/app/oracle/oradata/DOGSBY/users01.dbf tag=TAG20150407T143533
channel c2: datafile copy complete, elapsed time: 00:00:01
Finished backup at 2015-04-07 14:35:50

sql statement: alter system archive log current

contents of Memory Script:
{
switch clone datafile all;
}
executing Memory Script

datafile 1 switched to datafile copy
input datafile copy RECID=1 STAMP=876407868 file name=/app/oracle/oradata/DOGSBY/system01.dbf
datafile 2 switched to datafile copy
input datafile copy RECID=2 STAMP=876407868 file name=/app/oracle/oradata/DOGSBY/sysaux01.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=3 STAMP=876407868 file name=/app/oracle/oradata/DOGSBY/undotbs01.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=4 STAMP=876407868 file name=/app/oracle/oradata/DOGSBY/users01.dbf
Finished Duplicate Db at 2015-04-07 14:35:52

released channel: c1

released channel: c2

released channel: stby1

released channel: stby2

Oracle RAC到单机的备库搭建

基本步骤是相同的，不同点在于oracle rac有两至多个实例，所以在设置归档日志转换路径时需要增加sid=““选项
Oracle RAC 环境使用ASM管理时，可以有类似的配置
alter system set log_archive_dest_2=‘service=DOG2 db_unique_name=DOG’ sid=’’;
alter system set standby_archive_dest=’ +RECVG/DOG/arch_dog’ sid=’’; # 如果不指定,则需要单独指定

DOG2.__db_cache_size=45365592064
DOG1.__db_cache_size=44962938880
DOG1.__java_pool_size=939524096
DOG2.__java_pool_size=939524096
DOG1.__large_pool_size=805306368
DOG2.__large_pool_size=805306368
DOG2.__oracle_base=‘/app/oracle‘#ORACLE_BASE set from environment
DOG1.__oracle_base=‘/app/oracle‘#ORACLE_BASE set from environment
DOG1.__pga_aggregate_target=20669530112
DOG2.__pga_aggregate_target=20669530112
DOG1.__sga_target=61874372608
DOG2.__sga_target=61874372608
DOG1.__shared_io_pool_size=536870912
DOG2.__shared_io_pool_size=0
DOG2.__shared_pool_size=14361296896
DOG1.__shared_pool_size=13958643712
DOG1.__streams_pool_size=268435456
DOG2.streams_pool_size=0
*.audit_file_dest=‘/app/oracle/admin/DOG/adump‘
*.audit_trail=‘db‘
*.cluster_database=true
*.compatible=‘11.2.0.4.0‘
*.control_files=‘+DATAVG/dog/controlfile/current.315.898601063‘,‘+DATAVG/dog/controlfile/current.316.898601063‘
*.db_block_size=8192
*.db_create_file_dest=‘+DATAVG‘
*.db_domain=‘‘
*.db_name=‘DOG‘
*.db_recovery_file_dest=‘+DATAVG‘
*.db_recovery_file_dest_size=42949672960
*.diagnostic_dest=‘/app/oracle‘
*.dispatchers=‘(PROTOCOL=TCP) (SERVICE=DOGXDB)‘
DOG2.instance_number=2
DOG1.instance_number=1
*.log_archive_dest_1=‘location=+RECVG‘
*.log_archive_format=‘%t%s%r.dbf‘
*.open_cursors=300
*.pga_aggregate_target=20615004160
*.processes=1500
*.remote_listener=‘rg77003-cluster-scan:1521‘
*.remote_login_passwordfile=‘exclusive‘
*.sessions=1655
*.sga_target=61847109632
DOG2.thread=2
DOG1.thread=1
*.undo_retention=86400
DOG2.undo_tablespace=‘UNDOTBS2‘
DOG1.undo_tablespace=‘UNDOTBS1‘

alter system set log_archive_dest_2=‘service=DOG2 db_unique_name=DOG‘ sid=‘DOG1‘;
alter system set log_archive_dest_2=‘service=DOG1 db_unique_name=DOG‘ sid=‘DOG2‘;
alter system set standby_archive_dest=‘ +RECVG/DOG/arch_dog‘ sid=‘DOG1‘;
alter system set standby_archive_dest=‘ +RECVG/DOG/arch_dog‘ sid=‘DOG2‘;
alter system set log_archive_config=‘dg_config=(DOG,DOGSBY)‘;
alter system set log_archive_dest_3=‘service=DOGSBY lgwr async VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=DOGSBY‘ sid=‘DOG1‘;
alter system set log_archive_dest_3=‘service=DOGSBY lgwr async VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=DOGSBY‘ sid=‘DOG2‘;
alter system set standby_file_management=auto;
alter system set fal_server=‘DOGSBY‘;
alter system set fal_client=‘DOG1‘ sid=‘DOG1‘;
alter system set fal_client=‘YZBL2‘ sid=‘DOG2‘;

————————————————
版权声明：本文为CSDN博主「Martin201609」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Martin201609/java/article/details/98618240

oracle dataguard详解和环境搭建

标签：following   rtu   current   rdf   opera   fixed   lis   least   spfile   

原文地址：https://www.cnblogs.com/hftian/p/12717448.html