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;
posted @ 2012-08-06 14:39  南宫元耘  阅读(902)  评论(0编辑  收藏  举报