第三部分逻辑standby(3)角色转换 2008.02.22
关于角色转换的一些概念在物理standby 章节的时候已经讲了很多，在概念和操作方式上二者基本一致，不过如果你真正深刻理解了物理standby 和逻辑standby，你会意识到，对于逻辑standby 而言，不管是switchover还是failover，怎么操作起来，都这么怪怪的呢~~~
逻辑standby之switchover
要在primary 和逻辑standby 之间切换角色，一般是从操作primary 开始。
提示：
如果primary 或逻辑standby 是rac 结构，切记只保留一个实例启动，其它实例全部shutdown。等角色转换操作完成之后再启动其它实例，角色转换的操作会自动传播到这些实例上，并不需要你再对这些实例单独做处理。
一、准备工作
1、检查primary 和逻辑standby 的初始化参数设置，常规的检查包括：
●确保fal_server,fal_client 值设置正确
●确保log_archive_dest_n 参数设置正确
更多可能涉及的初始化参数可以参考2.1 中的第4 小章
首先来看当前的primary数据库：
JSSWEB> show parameter fal
NAME TYPE VALUE
-------------------------- ----------- -------------------------------
fal_client string jssweb
fal_server string jsspdg
JSSWEB> show parameter name_convert
NAME TYPE VALUE
-------------------------- ----------- -------------------------------
db_file_name_convert string oradata\jsspdg, oradata\jssweb
log_file_name_convert string oradata\jsspdg, oradata\jssweb
JSSWEB> show parameter log_archive_dest
NAME TYPE VALUE
-------------------------- ----------- -------------------------------
log_archive_dest string
log_archive_dest_1 string LOCATION=E:\ora10g\oradata\jssweb\arc
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=jssweb
log_archive_dest_2 string service=jsspdg OPTIONAL LGWR SYNC AFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=jsspdg
................
................
................
log_archive_dest_state_1 string ENABLE
log_archive_dest_state_2 string defer
由于此处primary 的初始化参数并不合适，为了避免其转换之后发生错误，我们需要提前做些修改：
JSSWEB> alter system set log_archive_dest_2='location=e:\ora10g\oradata\jssweb\std\valid_for=(standby_logfiles,standby_role) db_unique_name=jssweb';
系统已更改。
JSSWEB> alter system set log_archive_dest_1='location=e:\ora10g\oradata\jssweb\arc\valid_for=(online_logfiles,all_roles) db_unique_name=jssweb';
系统已更改。
JSSWEB> alter system set log_archive_dest_state_2='enable';
系统已更改。
JSSWEB> alter system set fal_server='jssldg';
系统已更改。
--xx_file_name_convert
这两个参数无法动态修改，因此我们首先修改
spfile
，然后再重启一下数据库
JSSWEB> alter system set db_file_name_convert='oradata\jssldg','oradata\jssweb' scope=spfile;
系统已更改。
JSSWEB> alter system set log_file_name_convert='oradata\jssldg','oradata\jssweb' scope=spfile;
系统已更改。
JSSWEB> startup force
然后再看看待转换的逻辑standbstandby
JSSLDG> show parameter fal
NAME TYPE VALUE
---------------------- ----------- --------------------
fal_client string
fal_server string
JSSLDG> show parameter file_name
NAME TYPE VALUE
---------------------- ----------- --------------------
db_file_name_convert string oradata\jssweb, oradata\jssldg
log_file_name_convert string oradata\jssweb, oradata\jssldg
JSSLDG> show parameter log_archive
NAME TYPE VALUE
---------------------- ----------- --------------------
log_archive_config string DG_CONFIG=(jssweb,jsspdg,jssldg)
log_archive_dest string
log_archive_dest_1 string location=E:\ora10g\oradata\jssldg\arc\
valid_for=(online_logfiles,all_roles)
db_unique_name=jssldg
log_archive_dest_10 string
log_archive_dest_2 string location=E:\ora10g\oradata\JSSLDG\std\
valid_for=(standby_logfiles,standby_role)
db_unique_name=JSSLDG
.......................
.......................
对于待转换的逻辑standby 中，某些初始化参数也可以不设置，不过走到这一步了，顺手全设置一遍。
JSSLDG> alter system set fal_server='jssweb';
系统已更改。
JSSLDG> alter system set fal_client='jssldg';
系统已更改。
JSSLDG> alter system set log_archive_dest_3='service=jssweb lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=jssweb';
系统已更改。
2、检查primary 数据库是否配置了standby redologs
JSSWEB> select * from v$standby_log;
未选定行
对于逻辑standby 数据库，standby redologs 是必须的，因此我们需要为当前的primary 创建几个standbyredologs。
JSSWEB> alter database add standby logfile group 4 ('e:\ora10g\oradata\jssweb\standbyrd01.log') size 20m;
数据库已更改。
.....................
.......................
.........................
JSSWEB> alter database add standby logfile group 8 ('e:\ora10g\oradata\jssweb\standbyrd05.log') size 20m;
数据库已更改。
二、检查primary数据库状态
在当前的primary 数据库查询v$database 视图中的switchover_status 列，查看当前primary 数据库状态。
JSSWEB> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO STANDBY
如果该查询返回TO STANDBY 或SESSIONS ACTIVE 则表示状态正常，可以执行转换操作，如果否的话，就需要你先检查一下当前的dataguard 配置，看看是否
三、准备转换primary为逻辑standby
执行下列语句，将primary 置为准备转换的状态：
JSSWEB> alterdatabasepreparetoswitchovertologicalstandby;
数据库已更改。
查看一下switchover_status 的状态，哟，果然变成准备ing 啦~~
JSSWEB> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
PREPARING SWITCHOVER
四、准备转换逻辑standby为primary
我们一定要学习oracle 这种逻辑，甭管想做什么，都得先有个准备的过程~
JSSLDG> alterdatabasepreparetoswitchovertoprimary;
数据库已更改。
JSSLDG> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
PREPARING SWITCHOVER
五、再次检查primary数据库状态
JSSWEB> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO LOGICAL STANDBY
注意：这步虽然不做什么操作，但检查结果却非常重要，它直接关系到switchover 转换是否能够成功。逻辑standby 执行完prepare 命令之后，就会生成相应的LogMiner 字典数据(就像我们前面创建逻辑standby 时，primary 会生成LogMiner 字典数据一样)，只有它正常生成并发送至当前的primary，转换操作才能够继续下去。不然当前的primary 数据库在转换完之后，可能就失去了从新的primary 接收redo 数据的能力了。
因此，如果上述查询的返回结果不是：TO LOGICAL STANDBY 的话，你可能就需要取消此次转换，检查原因，然后再重新操作了。
提示：
取消转换可以通过下列语句：
ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;
需要分别在primary 和逻辑standby 执行。
六、转换primary为逻辑standby
执行下列语句：
JSSWEB> alterdatabasecommittoswitchovertologicalstandby;
数据库已更改。
该语句需要等待当前primary 所有事务全部结束。同时该语句也会自动拒绝用户发布的新事务或修改需求。为确保该操作尽可能快的执行，最好自开始切换操作起就禁止所有用户的操作。
该命令执行完之后，这个primary 就已经成为新的逻辑standby 了。不过在新primary 执行完转换之前，不要关闭当前这个数据库。
七、再次检查逻辑standby状态
逻辑standby 在接收到前primary 的转换消息，并应用完相关的redo 数据之后，会自动暂停sql 应用，然后查询switchover_status 的状态，应该为：TO PRIMARY
JSSLDG> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO PRIMARY
八、转换逻辑standby为primary
最后的工作总会在逻辑standby 上操作，通过上列语句，将该逻辑standby 转换为新的primary。
JSSLDG> alterdatabasecommittoswitchovertoprimary;
数据库已更改。
转换完成
九、启动新逻辑standby的sql应用
最后启动新逻辑standby 的sql 应用。
JSSWEB> alter database start logical standby apply;
数据库已更改。
提示：还记的我们的jsspdg 吗，虽然它也是standby(物理)，不过它现在也并非这个dataguard 配置中的一员了，这也是由于逻辑standby 自身特性决定的，每一个逻辑standby 都相当于是一个不同于primary 的数据库(DBID都不同)，因此在逻辑standby 完成了转换之后，相当于原primary 已经消失，因此原primary 配置的物理standby也失去了主从参照，不过原primary 配置的逻辑standby 不会有影响。
逻辑standby之failover
前面学习物理standby 的failover 时我们提到过，failover 有可能会丢失数据(视当前的数据库保护模式而定)，对于逻辑standby 也一样；物理standby 在做failover 演示时还提到过，所有的操作都会在standby 端执行，对于逻辑standby 这也一样，甚至对于明确提及在前primary 执行的，你不执行，也没关系，毕竟对于failover，我们假设的就是，primary 已经over 了:)
一、准备工作要充分
准备工作可以从以下几个方面着手：
1、检查及处理丢失的归档
虽然本步不是必须的，但如果希望尽可能少丢失数据，除了数据保护模式之外，本步操作也非常重要。如果此时primary 仍可被访问，首先检查当前的归档日志序号与逻辑standby 是否相同：
JSSLDG> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
24
JSSWEB> select sequence#,applied from dba_logstdby_log;
SEQUENCE# APPLIED
---------- --------
23 YES
24 YES
已选择2 行。
提示：如果primary 的数据库已经无法打开，您就只好直接到磁盘上查看归档目录中的序号来与standby端做比较了。
如果不同序号，则将primary 尚未发送至standby 的归档文件手工复制到待转换的逻辑standby 服务器，然后在standby 端通过ALTER DATABASE REGISTER LOGICAL LOGFILE ''; 命令将文件手工注册
如果standby 与primary 的归档序号相同，但某些序号的applied 状态为no，建议你检查一下当前standby是否启动了SQL 应用：）。
2、检查待转换逻辑standby 的日志应用情况
可以通过查询v$logstdby_progress 视图：
JSSWEB> select applied_scn,latest_scn from v$logstdby_progress;
APPLIED_SCN LATEST_SCN
----------- ----------
1259449 1259453
如果两值一致，表示所有接收到的归档都已经应用了。
3、检查及修正待转换逻辑standby 的初始化参数配置
确认待转换的逻辑standby 配置了正确的归档路径，不仅是写本地的归档，还要有写远程的归档，不然转换完之后，这台新的primary 就成了光杆司令了。
JSSWEB> show parameter log_archive_dest
.......................
当然一般来说，我们都是推荐在创建standby 的同时将一些用于角色切换的初始化参数也配置好(primary 和standby 端都应如此)，以减小切换时操作的时间，提高切换效率。
二、激活新的primary数据库
首先查看当前操作的角色
JSSWEB> select database_role,force_logging from v$database;
DATABASE_ROLE FOR
---------------- ---
LOGICAL STANDBY YES
注意，如果当前force_logging 为no，务必执行：Alter database force logging;
转换standby 角色为primary
JSSWEB> altealterdatabaseactivatelogicalstandbydatabasefinishapply;
数据库已更改。
该语句主要是停止待转换的逻辑standby 中RFS 进程，并应用完当前所有已接收但并未应用的redo 数据，然后停止sql 应用，将数据库转换成primary 角色。
JSSWEB> select database_role,force_logging from v$database;
DATABASE_ROLE FOR
---------------- ---
PRIMARY YES
基本上到这一步，我们可以说角色转换的工作已经完成了，但是注意，活还没有干完！
此处与逻辑standby 的switchover 同理，切换完之后，原dg 配置就失效了(不仅原物理standby 没了，原逻辑standby 也失去了参照，看看，逻辑standby 的failover 确实威力巨大呀，怪不得逻辑standby 用的人这么人呢，环境脆弱肯定是原因之一啊)，因此我们需要做些设置，重新将原来的standby 再加入到新的dg 配置环境中。
三、修复其它standby
注意哟，逻辑standby 的修复可并不像物理standby 那样简单，每个逻辑standby 都相当于是独立的数据库，如果你不希望重建逻辑standby 的话呢，oracle 倒是也提供了其它解决方案(虽然不一定好使)：
1、在各个原逻辑standby 中创建数据库链，连接到新的primary
注意，数据库链中用于连接新primary 的用户必须拥有SELECT_CATALOG_ROLE 角色。
JSSLDG2> alter session disable guard;
会话已更改。
JSSLDG2> create database link getjssweb connect to jss identified by jss using 'jssweb';
数据库链接已创建。
JSSLDG2> alter session enable guard;
会话已更改。
验证一下数据链是否能够正常访问：
JSSLDG2> select sysdate from dual@getjssweb;
SYSDATE
--------------
23-2 月-08
提示：关于alter session enable|disable guard 语句，用于允许或禁止用户修改逻辑standby 中的结构。例如：
JSSLDG2> conn jss/jss
已连接。
JSSLDG2> select * from b;
ID
----------
1
2
3
4
5
6
7
8
已选择8 行。
JSSLDG2> alter table b rename to a;
alter table b rename to a
*
第1 行出现错误:
ORA-16224: Database Guard 已启用
JSSLDG2> alter session disable guard;
会话已更改。
JSSLDG2> alter table b rename to a;
表已更改。
2、重新启动SQL 应用
在各个逻辑standby 执行下列语句启动sql 应用(注意更新dblinkName)：
JSSLDG2> alter database start logical standby apply new primary getjssweb;
数据库已更改。
如果你运气好，等语句执行完之后，恢复过程就完成了。如果你非常不幸的碰到了ORA-16109 错误，那么我不得不告诉你，恐怕你得重建逻辑standby 了。所以，祝你好运吧:)
语句顺利执行完之后，我们来验证一下：
JSSWEB> alter system switch logfile;
系统已更改。
JSSWEB> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
862
JSSLDG2> select sequence#,applied from dba_logstdby_log;
SEQUENCE# APPLIED
---------- --------
862 NO
注意：出现问题了！！
日志是传输过去了，但是逻辑standby 并没有开始应用，怎么回事？
我们先来确认一下standby 的各进程状态：
JSSLDG2> select process,status,group#,thread#,sequence#,block#,blocks from v$managed_standby;
PROCESS STATUS GROUP# THREAD# SEQUENCE# BLOCK# BLOCKS
--------- ------------ --------- ---------- ---------- ---------- ----------
ARCH CLOSING 2 1 4 16385 1836
ARCH CLOSING 6 1 862 1 18
RFS IDLE N/A 0 0 0 0
RFS IDLE 3 1 863 2 1
看起来也是正常的，接收完了862,正在等待863，但是，为什么不应用呢。
手工查询一下新primary 生成的归档日志情况：
JSSWEB> select sequence#,name,COMPLETION_TIME from v$archived_log where sequence#>855;
SEQUENCE# NAME COMPLETION_TIME
---------- -------------------------------------------------------- -------------------
856 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_856_641301252.ARC 2008-02-21 10:15:42
857 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_857_641301252.ARC 2008-02-21 10:16:46
858 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_858_641301252.ARC 2008-02-23 14:15:18
859 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_859_641301252.ARC 2008-02-23 14:56:55
860 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_860_641301252.ARC 2008-02-23 14:57:03
861 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_861_641301252.ARC 2008-02-23 16:58:14
861 jssldg2 2008-02-23 16:58:16
862 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_862_641301252.ARC 2008-02-23 17:08:57
862 jssldg2 2008-02-23 17:08:57
863 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_863_641301252.ARC 2008-02-23 17:19:48
863 jssldg2 2008-02-23 17:20:59
864 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_864_641301252.ARC 2008-02-23 17:21:11
864 jssldg2 2008-02-23 17:21:13
已选择13 行。
发现了一点点痕迹，我们的切换操作是下午3 点左右进行的，期间还产生了序列号为860,861 之类的归档文件，但并未传输至standby，是不是因为这些文件中包含了一部分应被应用的数据，因此造成standby
接收到的新primary 传输过来的归档scn 与最后应用的scn 不连续，所以无法应用？再来验证一下：
JSSLDG2> select applied_scn,latest_scn from v$logstdby_progress;
APPLIED_SCN LATEST_SCN
----------- ----------
1259449 1284126
果然如此，应用的scn 与最后的scn 确实不匹配，剩下的就好解决了，把所有可疑的应传输到standby的归档文件手工复制到standby，然后通过alter 命令注册一下：
JSSLDG2> alter database register logical logfile 'E:\ora10g\oradata\jssldg2\std\LOG1_859_641301252.ARC';
数据库已更改。
JSSLDG2> alter database register logical logfile 'E:\ora10g\oradata\jssldg2\std\LOG1_860_641301252.ARC';
数据库已更改。
JSSLDG2> alter database register logical logfile 'E:\ora10g\oradata\jssldg2\std\LOG1_861_641301252.ARC';
数据库已更改。
提示：复制文件的时候尽可能把相近时间段的归档文件都拷过来，不用担心无用归档会不会影响到应用，oracle 会自动判断归档中的scn，对于已经应用过的正常情况下是不会重复应用的，因此我们把
859,860,861 全部复制过来。
再查看一下应用状态：
JSSLDG2> select sequence#,applied from dba_logstdby_log;
SEQUENCE# APPLIED
---------- --------
862 CURRENT
863 CURRENT
哈哈，已经开始应用了。逻辑standby 恢复成功！想起官方文档中有一句提示，说的是在打开新的primary数据库，生成数据字典之前，不要执行任何DDL，不然就只能重建逻辑standby 了，估计就是担心执行ddl后不幸触发日志切换，造成逻辑standby 接收新primary 传来的归档文件不连续，无法顺利应用。
切换完成之后，在修复逻辑standby 的同时，顺手打扫一下战场，比如设置新primary 数据库的备份策略，以及考虑如何修复前故障的primary 等等，dba 这份工作，人前看起来光鲜，如果你已经下定决心要从事这行，那对于人后的辛苦一定要有深刻心理准备哟，你看看像上面这种情况，primary 只要随随便便宕个机，引之而来的工作量就够我们忙活的。
也许这个时候dba 需要的不仅是保持清晰的大脑，还要能打开思路，此时我们更不妨考虑在做角色切换和修复损坏的primary 之间做个选择，究竟哪个更快，哪个更简便一些呢，你看，干dba 这行，不仅压力大，不仅要本领过硬，不仅要耐心细致，关键时刻还要保持清醒的头脑，额地神耶，太刺激啦，太有挑战啦~~~~~~