逻辑备库的Switchover
检查Primary数据库状态
查看当前Primary数据库状态：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
TO STANDBY
如果该查询返回TO STANDBY 或SESSIONS ACTIVE则表示状态正常，可以执行转换操作，如果是其他值，你就需要重新检查一下Data Guard配置，如看看LOG_ARCHIVE_DEST_n之类的参数值是否正确、有效等。
3．准备转换Primary为逻辑Standby
执行下列语句，将Primary置为准备转换的状态：
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;
Database altered.
执行完上述操作后，Primary数据库就开始为角色的转换打好基础，时刻准备着接收来自逻辑Standby数据库，也就是未来的新Primary数据库发来的REDO数据。
查看一下SWITCHOVER_STATUS的状态：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
PREPARING SWITCHOVER
4．准备转换逻辑Standby为Primary
逻辑Standby数据库准备转换为Primary角色，执行下列语句：
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
Database altered.
语句执行时响应可能会有点慢。
执行完后查看当前逻辑Standby数据库的转换状态：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
PREPARING SWITCHOVER
5．再次检查Primary数据库状态
执行下列语句：
SQL> 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的话，DBA就需要考虑是否取消此次转换，检查原因，然后再重新操作了。
取消转换可以通过下列语句进行：
ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;
需要分别在Primary端和逻辑Standby端执行。由此可见准备工作的好处显现出来了嘛，一旦异常，随时可以选择取消
6．转换Primary为逻辑Standby
如果前面的操作都没有问题，就可以正式开始角色转换的操作，首先是将原Primary数据库转换成新的Standby，操作如下：
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
Database altered.
该语句需要等待当前Primary数据库所有事务全部结束才开始执行。该语句执行过程中会自动拒绝用户提交新事务或修改需求。为了确保该操作尽可能快的执行，最好自开始切换操作起就禁止所有用户的操作。
该命令执行完之后，这个Primary数据库就已经成为新的逻辑Standby了。不过在新Primary执行完转换之前，不要关闭当前这个数据库。
7．再次检查逻辑Standby状态
逻辑Standby在接收到前Primary的转换消息，并应用完相关的REDO数据之后，会自动暂停SQL应用，然后查询SWITCHOVER_STATUS的状态，应该为TO PRIMARY：
SQL>SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
TO PRIMARY
或者
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
NOT ALLOWED
8．转换逻辑Standby为新的Primary数据库
最后的工作总会在逻辑Standby端操作，通过下列语句，将该逻辑Standby转换为新的Primary数据库：
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Database altered.
转换操作至此完成。
最后启动新逻辑Standby，即前Primary数据库端的SQL应用即可：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.
注意：每一个逻辑Standby都相当于是一个不同于（前）Primary的数据库（DBID都不同），因此当逻辑Standby完成了转换之后，相当于原Primary数据库已经消失，依照原Primary数据库配置的物理Standby自然也就失去了主从参照，物理Standby也就不再是当前Data Guard配置中的成员了。
这也正是前面修改Primary初始化参数时，取消发送REDO数据到物理Standby数据库的原因。不过还好，对于switchover，Data Guard配置中的其他逻辑Standby数据库不会有影响。
9．环境测试
最后来测试一下当前的Data Guard配置，首先在新Primary数据库操作一条记录：
SQL> insert into scott.dept values(2,'bl','bl');
1 row created.
SQL> commit;
Commit complete.
转到逻辑Standby端查看：
DEPTNO DNAME LOC
---------- -------------- -------------
1 dave dmm
2 bl bl
同步成功，也基本代表转换成功。
逻辑备库的Failover
failover有可能会丢失数据（视当前的数据库保护模式而定），而且所有的操作都是在Standby数据库端执行，这几点对于逻辑Standby也同样适用，甚至对于明确提及需要在前Primary数据库执行的，不执行也没关系，毕竟对于failover，我们假设的就是Primary数据库已经over。
1．检查及处理丢失的归档
虽然本步不是必需的，但如果希望尽可能少的丢失数据，除了数据保护模式之外，本步操作也非常重要。如果此时Primary数据库仍可被访问，首先应当检查当前的归档日志序号与逻辑Standby是否相同：
在主库查询：
SQL> SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG;
MAX(SEQUENCE#)
--------------
113
在备库查询：
SQL> SELECT SEQUENCE#,APPLIED FROM DBA_LOGSTDBY_LOG;
SEQUENCE# APPLIED
---------- --------
110 CURRENT
111 NO
如果上述查询的结果不同，说明Primary存在尚未发送至逻辑Standby数据库的归档文件，手工复制这些文件到待转换角色的逻辑Standby端，然后在该逻辑Standby数据库的SQL*Plus命令窗口，
通过执行 ALTER DATABASE REGISTER LOGICAL LOGFILE 'filepath'; 命令，将复制过来的归档文件手工注册。
如果逻辑Standby与Primary的归档序号相同，但某些序号的APPLIED状态为NO，建议DBA检查一下当前逻辑Standby数据库是否启动了SQL应用。
如果Primary数据库已经无法打开，DBA就只好直接到磁盘上查看归档目录中的序号，来与逻辑Standby数据库做比较。如果Primary数据库已经完全无法访问，那请直接跳过本步。
2．检查待转换逻辑Standby的日志应用情况
查询重做日志的应用情况，可以通过V$LOGSTDBY_PROGRESS视图进行，例如：
SQL> SELECT APPLIED_SCN,LATEST_SCN FROM V$LOGSTDBY_PROGRESS;
APPLIED_SCN LATEST_SCN
----------- ----------
598967 598967
如果返回的结果中显示，两列的列值一致，则表示所有接收到的重做日志都已经应用。如果不一致的话，启动逻辑Standby端的SQL应用。
3．检查及修正待转换逻辑Standby的初始化参数配置
确认待转换的逻辑Standby配置了正确的归档路径，不仅是写本地的归档配置，还要有写远端服务器的归档配置，不然转换完之后，这台新的Primary数据库就成了光杆司令了。
一般来说，我们都是推荐在创建Standby数据库的同时将一些用于角色切换的初始化参数也配置好（Primary和Standby端都应如此），以减少切换时操作的时间，提高切换效率。执行如下命令：
SQL> SHOW PARAMETER LOG_ARCHIVE_DEST
4．激活新的Primary数据库
首先查看当前操作的角色：
SQL> SELECT DATABASE_ROLE,FORCE_LOGGING FROM V$DATABASE;
DATABASE_ROLE FOR
---------------- ---
LOGICAL STANDBY YES
注 意
如果当前FORCE_LOGGING为NO，务必执行ALTER DATABASE FORCE LOGGING;命令。
执行下列语句，转换Standby数据库角色为Primary：
SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY;
数据库已更改。
该语句主要是停止待转换的逻辑Standby中RFS进程，并应用完当前所有已接收但并未应用的REDO数据，然后停止SQL应用，将数据库转换成Primary角色。
语句执行完成后，再次查看当前数据库的角色：
SQL> SELECT DATABASE_ROLE,FORCE_LOGGING FROM V$DATABASE;
DATABASE_ROLE FOR
---------------- ---
PRIMARY YES
基本上到这一步，我们可以说角色转换的工作已经完成了. 此处与逻辑Standby的switchover同理，切换完之后，原Data Guard配置就失效了，彻底的失效了，不仅物理Standby没了，逻辑Standby也失去了参照，逻辑Standby的failover威力确实大呀，怪不得逻辑Standby用的人这么少呢，环境脆弱肯定是原因之一，因此我们需要做些设置，重新将原来的逻辑Standby再加入到新的Data Guard配置环境中。
5．修复其他Standby数据库
物理Standby数据库的修复只有重建一种方式，至于如何创建物理Standby，前面说的已经足够多了，下面重点描述一下原Data Guard环境中的逻辑Standby。
注意的是，逻辑Standby的修复可不像物理Standby那样简单，相比较来说，重建其实是个简单的工作，因为初始化参数文件、密钥文件、存放目录等都是现成的，几乎不需要改动，DBA所需要做的，基本上就是重新复制一份新Primary数据库的相关文件，每个逻辑Standby都相当于是独立的数据库，如果你不希望重建逻辑Standby的话呢，Oracle倒是也提供了其他的解决方案。
假定原Data Guard环境中有逻辑Standby数据库LGDG，执行failover后，LGDG不再是新Data Guard环境中的成员，这里演示如何恢复该数据库到当前的Data Guard配置，操作步骤如下：
（1）在原逻辑Standby中创建数据库链，连接到新的Primary数据库。
这里所谓的原Standby数据库，自然是指JSSLDG2喽，注意，数据库链中用于连接新Primary数据库的用户必须拥有SELECT_CATALOG_ROLE角色。执行以下语句：
SQL> ALTER SESSION DISABLE GUARD;
Session altered.
SQL> CREATE DATABASE LINK BL CONNECT TO SYSTEM IDENTIFIED BY admin USING 'orcl_pd';
Database link created.
SQL> ALTER SESSION ENABLE GUARD;
会话已更改。
验证一下数据链是否能够正常访问：
SQL> SELECT SYSDATE FROM DUAL@BL;
SYSDATE
---------
06-MAY-10
提 示： ALTER SESSION ENABLE|DISABLE GUARD语句作用？
该语句用于允许或禁止用户修改逻辑Standby中的结构。
（2）重新启动SQL应用。
在各个逻辑Standby端执行下列语句启动SQL应用（注意更新dblinkName）：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY BL;
Database altered.
如果你运气好，等语句执行完之后，恢复过程就完成了。如果你非常不幸地碰到了ORA-16109错误，那么我不得不告诉你，恐怕你得重建逻辑Standby了。
参考至:http://blog.csdn.net/tianlesoftware/article/details/5564179
如有错误，欢迎指正
邮箱:czmcj@163.com
