**三节点DG环境主库单机转RAC（DG主备切换）
所有数据以脱敏**

---
**prod主库（15.91）有关DG环境的参数：**

```
*.db_unique_name='prod'
*.fal_client='prod'
*.fal_server='proddg'
*.log_archive_config='DG_CONFIG=(prod,proddg,proddg2)'
*.log_archive_dest_1='location=/data/zjcbss/arch'
*.log_archive_dest_2='service=proddg arch async VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=proddg'
*.log_archive_dest_3='SERVICE=proddg2 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=proddg2'
*.log_archive_dest_state_2='ENABLE'
*.standby_file_management='AUTO'
```

**proddg备库1（15.55）有关DG环境的参数：**

```
*.db_file_name_convert='/data/prod2/data','/oradata/rman'
*.log_file_name_convert='/data/prod2/data','/oradata/rman'
*.db_unique_name='proddg'
*.fal_client='proddg'
*.fal_server='prod'
*.log_archive_config='DG_CONFIG=(prod,proddg)'
*.log_archive_dest_1='location=/oradata/oracle/arch'
*.log_archive_dest_2='SERVICE=prod LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=prod'
*.log_archive_dest_state_2='ENABLE'
*.standby_file_management='AUTO'
```

**proddg2备库2（15.101）有关DG环境的参数：**

```
*.db_file_name_convert='/data/prod2/data','/oradata/zjcbss'
*.log_file_name_convert='/data/prod2/data','/oradata/zjcbss/prod2/data'
*.fal_client='proddg2'
*.fal_server='prod'
*.log_archive_config='DG_CONFIG=(prod,proddg,proddg2)'
*.log_archive_dest_1='location=/oradata/zjcbss/arch'
*.log_archive_dest_2='SERVICE=prod LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=prod'
*.log_archive_dest_state_2='ENABLE'
*.standby_file_management='AUTO'
```

**切换后的环境为：**

```
主库proddg2  192.168.15.101   
备库proddg   192.168.15.55
备库prod     192.168.15.91

//先切换，后修改参数
//切换成功后，proddg2为主库，prod为备库，proddg不属于该DG环境中，后续修改参数将proddg加入，将prod剔除
```

**一：切换前准备：**

```
1.本地杀会话
杀客户端进程：
ps -ef|grep "LOCAL=NO"|grep -v grep|awk '{print "kill -9 " $2}'| sh     --->直接删

查询连接会话数量：
ps -ef|grep "LOCAL=NO"| wc -l       --> 生产中是杀不干净的，几秒钟连接数又到了几十个

select count(*) from v$session where username is not null;

2.修改crontab删除归档脚本
三节点关闭归档日志删除计划任务//注释掉crontab
cronbab -l

3.在主库切换归档日志（多次切换，确保备库正常接收）
alter system switch logfile

4.standby redolog数据量配置正确：
standby redolog=redolog + 1
（经检查现环境符合要求，无需修改）
```

**二：开始进行switchover切换**

**1.主库prod切为备库：**

```
select name,database_role,switchover_status from v$database;

NAME	  DATABASE_ROLE    SWITCHOVER_STATUS
--------- ---------------- --------------------
prod	  PRIMARY	   SESSIONS ACTIVE

如果switchover_status状态是SESSIONS ACTIVE  --> 生产下百分百是session active

使用下面命令切换
alter database commit to switchover to physical standby with session shutdown; 
```

**2.切换完成后数据库会被关闭,重新启动查看切换完的状态：**

```
select name,database_role,switchover_status from v$database;

NAME	  DATABASE_ROLE    SWITCHOVER_STATUS
--------- ---------------- --------------------
prod	  PHYSICAL STANDBY  TO PRIMARY
//如果此时switchover_status显示为recovery needed，则启动日志应用服务alter database recover managed standby database disconnect from session后，再次查看

//在生产上我切换完，他的switchover_status依旧为session active，没有去过多在意

select database_role,protection_mode,protection_level from v$database;

DATABASE_ROLE	 PROTECTION_MODE      PROTECTION_LEVEL
---------------- -------------------- --------------------
PHYSICAL STANDBY MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE
```

**3.备库proddg2切为主库：**

```
//查看切换状态
select database_role,switchover_status from v$database;

DATABASE_ROLE	 SWITCHOVER_STATUS
---------------- --------------------
PHYSICAL STANDBY TO PRIMARY
（如果此时switchover_status为not allowed，可以尝试进行切换，按错误提示进行处理，一般为ORA-16139: media recovery required
尝试进行recover：SQL>recover managed standby database using current logfile disconnect from session;)

//生产上，备库竟然也是session active，并且该库也不是被用于查询使用。

//备库切换为主库
alter database commit to switchover to primary **with session shutdown;** 
```

**4.查看切换后的状态：**

```
SQL> select name,database_role,protection_mode,protection_level from v$database;

NAME	  DATABASE_ROLE    PROTECTION_MODE	PROTECTION_LEVEL
--------- ---------------- -------------------- --------------------
proddg2	  PRIMARY	   MAXIMUM PERFORMANCE	UNPROTECTED

SQL> alter database open;
```

**三：切换后的参数修改**

```
proddg2：
alter system set log_archive_config='DG_CONFIG=(proddg2,proddg)' scope=both;
alter system set log_archive_dest_2='SERVICE=proddg LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=proddg' scope=both;
alter system set log_archive_dest_state_2='ENABLE' scope=both;
alter system set fal_server='proddg' scope=both;
alter system set fal_client='proddg2' scope=both;
alter system set db_file_name_convert='/oradata/rman','/oradata/zjcbss' scope=spfile;
alter system set log_file_name_convert='/oradata/rman','/oradata/zjcbss/prod2/data' scope=spfile;
```

proddg：

```
alter system set log_archive_config='DG_CONFIG=(proddg2,proddg)' scope=both;
alter system set log_archive_dest_2='SERVICE=proddg2 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=proddg2' scope=both;
alter system set log_archive_dest_state_2='ENABLE' scope=both;
alter system set fal_server='proddg2' scope=both;
alter system set fal_client='proddg' scope=both;
alter system set db_file_name_convert='/oradata/zjcbss','/oradata/rman' scope=spfile;
alter system set log_file_name_convert='/oradata/zjcbss/prod2/data','/oradata/rman' scope=spfile;
```

prod无需修改参数，该节点已从DG环境中剔除

**四：切换后测试**

```
1.启动proddg的日志应用服务：
SQL> alter database recover managed standby database disconnect from session;

2.在新主库proddg2进行几次日志切换，查看alert日志，判断日志是否正常传输
SQL> alter system switch logfile;

//如果日志没有正常传输，则

alter system set log_archive_dest_state_2='defer' scope=both;

alter system set log_archive_dest_state_2='enable' scope=both;

重新开启一下service传输，再次查看alert日志，判断日志是否正常传输
```

3.检查日志应用情况：

```
SQL> select max(sequence#) from v$archived_log where applied='YES';  //备库查询
SQL> select max(sequence#) from v$archived_log;                      //主库查询
```

**五:其他配置**

```
1.在新的DG环境下重新布置归档日志删除脚本
将prod的归档日志删除脚本拷贝到proddg2相同目录下,并配置crontab计划任务
0,10,20,30,40,50 * * * * /home/oracle/delArch/delArchivelog.sh >> /home/oracle/delArch/delArchivelog.log

//注意修改脚本中的SID

2.将proddg的归档日志删除脚本注释打开

3.为了业务不修改service_name即可连接
在proddg库中再添加一个service_name=prod
alter system set service_names=proddg2,prod scope=both;

4.系统业务进行测试是否正常
```

**六：遇到的问题汇总：**

1.//主库切换为备库切换完后，他的switchover_status依旧为session active，正常情况应该为to primary
  个人理解：切换为备库后，数据库会被关闭，再次启动后，会启动到read only状态，启动后，还是有新会话进行连接查询，所以该状态为session active

2.当DG切换完成后，日志正常传输以及日志正常应用，由于db_file_name_convert与log_file_name_convert参数被修改 ，并且该参数无法动态修改，只能使用scope=spfile，所以需要重新启动数据库，当重新启动到mount状态时，启动MRP进行日志应用，前台提示启动MRP成功，后台警告日志滚动将MRP强制关闭，并且后台日志中还出现许多许多找不到数据文件的错误（mount阶段会检测控制文件中记录的数据文件，如果数据文件不存在会在后台日志中报错，当open时，才会在前台报错，无法锁定数据文件。）
  排查后最终发现，控制文件中记录的数据文件路径不正确，将228个数据文件进行重命名后，错误消失，日志传输正常，MRP进程启动正常。

ITPub博客

Oracle 三节点DG环境主库单机转RAC（DG主备切换）

最新文章