DG 逻辑standby角色转换

逻辑standby之switchover

要在primary和逻辑standby之间切换角色，一般是从操作primary开始。

提示：如果primary或逻辑standby是rac结构，切记只保留一个实例启动，其它实例全部shutdown.等角色转换操作完成之后再启动其它实例，角色转换的操作会自动传播到这些实例上，并不需要你再对这些实例单独做处理。

一、准备工作

1. 检查primary和逻辑standby的初始化参数设置，常规的检查包括：

- 确保fal_server, fal_client值设置正确

- 确保log_archive_dest_n参数设置正确

PRIMARY> show parameter fal

PRIMARY> show parameter name_convert

PRIMARY> show parameter log_archive_dest

如果需要修改其中的参数，可通过以下方式：

PRIMARY> alter system set log_archive_dest_2='...\std\ valid_for=(standby_logfiles, standby_role) db_unique_name=orcl';

注意：xx_file_name_convert这两个参数无法动态修改，因此我们首先修改spfile,然后再重启一下数据库

然后再以同样的方式查看逻辑standby数据库

2. 检查primary数据库是否配置了standby redologs

PRIMARY> select * from v$standby_log;

如果没有则创建：

PRIMARY> alter database add standby logfile group 4 ('c:\oradata\orcl\standbyrd01.log') size 20m;

二、检查primary数据库状态

PRIMARY> select switchover_status from v$database;

三、准备转换primary为逻辑standby

执行下列语句，将primary置为准备转换的状态：

PRIMARY> alter database prepare to switchover to logical standby;

PRIMARY> select switchover_status from v$database;

四、准备转换逻辑standby为primary

STANDBY> alter database prepare to switchover to primary;

STANDBY> select switchover_status from v$database;

五、再次检查primary数据库状态

PRIMARY> select switchover_status from v$database;

逻辑standby执行完prepare命令之后，就会发生相应的LogMiner字典数据，只有它正常生成并发送至当前的primary,转换操作才能够继续下去。不然当前的primary数据库在转换完之后，可能就失去了从新的primary接收redo数据的能力了。

如果上述查询的返回结果不是：To logical standby就需要取消此次转换，检查原因，然后重新操作。

分别在primary和逻辑standby执行：

ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;

六、转换primary为逻辑standby

PRIMARY> alter database commit to switchover to logical standby;

七、再次检查逻辑standby状态

STANDBY> select switchover_status from v$database;

八、转换逻辑standby为primary

最后的工作总会在逻辑standby上操作：

STANDBY> alter database commit to switchover to primary;

九、启动新逻辑standby的sql应用

alter database start logical standby apply;

逻辑standby之failover

一、准备工作

1. 检查及处理丢失的归档

standby> select max(sequence#) from v$archived_log;

primary> select sequence#, applied from dba_logstdby_log;

提示，如果primary数据库已经无法打开，只好直接到磁盘上查看归档目录中的序号来与standby端做比较了。如果不同序号，则将primary尚未发送至standby的归档文件手工复制到待转换的逻辑standby服务器，然后在standby端通过ALTER DATABASE REGISTER LOGICAL LOGFILE;命令将文件手工注册。

2. 检查待转换逻辑standby的日志应用情况

STANDBY> select applied_scn, latest_scn from v$logstdby_progress;

如果两值一至，表示所有接收到的归档都已经应用了。

3. 检查及修正待转换逻辑standby的初始化参数配置

standby> show parameter log_archive_dest
....

二、激活新的primary数据库

首先查看当前操作的角色

sql> select database_role, force_logging from v$database;

如果当前force_logging为no,务必执行：alter database force logging;

转换standby角色为primary

sql> alter database activate logical standby database finish apply;

该语句主要是停止待转换的逻辑standby中RFS进程，并应用完当前所有已接收但并未应用的redo数据，然后停止sql应用，将数据库转换成primary角色。

三、修复其它standby

1. 在各个原逻辑standby中创建数据库链，连接到新的primary

　　连接新primary的用户必须拥有SELECT_CATALOG_ROLE角色。

jssldg> alter session disable guard;

jssldg> create database link getjssweb connect to jss identified by jss using 'orcl';

jssldg> alter session enable guard;

2. 重新启动sql应用

在各个逻辑standby执行下列语句启动sql应用(注意更新dblinkName):

jssldg> alter database start logical standby apply new primary getjssweb;

如果出现ORA-16109错误，那么必须重建逻辑standby.

PRIMARY> select max(sequence#) from v$archived_log;

standby> select sequence#, applied from dba_logstdby_log;

如果日志已经传输过去，但是逻辑standby并没有开始应用(Applied=No),是怎么回事？

a). 确认standby的各进程状态：

standby> select process, status, group#, thread#, sequence#, block#, blocks from v$managed_standby;

b). 手工查询新primary生成的归档日志情况：

primary> select sequence#,name,completion_time from v$archived_log where sequence#>855;

c). 验证传输过来的scn与最后应用的scn:

standby> select applied_scn, latest_scn from v$logstdby_progress;

d). 如果应用的scn与最后的scn确实不匹配，就把所有可疑的传输到standby的归档文件手工复制到standby,然后通过alter命令注册一下：

standby> alter database register logical logfile 'c:\oradata\jssldg\std\xxxx.arc';

e). 再次查看应用状态：

standby> select sequence#, applied from dba_logstdby_log;