盛哥学习 Data Guard 第三篇《物理standby之switchover 无损切换》
第三篇 物理standby之switchover 无损切换
一、switchover和failover
所谓switchover是针对failover而言的，它是一种无损切换，切换的过程中不会丢失数据。可以平滑的使主备互换并且2个库都可以正常使用。
切换过程：主库->切换->备库->检查状态->原备库->切换->主库->再检查状态
应用场合：主库需要调整升级，主库性能不佳，这时可以切换后用新主库对外提供服务
是否丢失数据：不会丢失数据
所谓failover，它是一种丢弃切换，直接把备库切换成主库，原主库自动丢弃，也就是不在属于DG架构的一部分了。
切换过程：备库->切换->主库->检查状态，原主库脱离DG架构
应用场合：当主库发生严重故障不可逆转的时候可以使用failover，例如 我们熟悉纽约双子塔911事件，如果你的主库在那里，呵呵那么你就不要在犹豫了，failover是你最佳之选择 come on
是否丢失数据：极有可能丢失数据，我们的目标就是损失降到最低
如果在failure之前是maximum protection or maximum availability模式，会丢失数据
挽救措施：重建主库 使用原来备份恢复主库
Switchover Role Transition 之前准备工作（标准流程，一般自己建的库最了解就可以skip）
1.检查主备库参数文件
2.主备库必须为归档模式
3.RAC模式下备库只能有一个实例为open，其他实例全部为shutdown，经过角色转换后，重新启动这些实例open
V$DATAGUARD_STATS可以评估备库角色切换后redo日志应用时间，只有备库有内容，主库没有
SYS@OEL> set lines 110
SYS@OEL> column name format a22
SYS@OEL> column value format a16
SYS@OEL> column unit format a28
SYS@OEL> column time_computed format a25
SYS@OEL> select * from v$dataguard_stats;
NAME VALUE UNIT TIME_COMPUTED
---------------------- -------------------- ---------------------------- ----------------------------------- -------------------------
apply finish time +00 00:18:35.5 day(2) to second(1) interval 04-JUN-2012 17:59:03
apply lag +06 21:28:29 day(2) to second(0) interval 04-JUN-2012 17:59:03
estimated startup time 27 second 04-JUN-2012 17:59:03
standby has been open N 04-JUN-2012 17:59:03
transport lag +00 00:00:00 day(2) to second(0) interval 04-JUN-2012 17:59:03
字段解释：
（1）apply lag：该值表示在通过在备库上应用主库传递过来的重做日志与出库同步所延迟的时间。APPLY LAG: Amount of time that the application of redo data on the standby database lags behind the primary database。
（2）transport lag：该值表示在单位时间内主库上产生的重做日志还没有传输到备库上，或者主库上产生的重做日志还没有被备库所应用
（3）apply finish time：该值表示在备库上完成应用重做日志所需要的时间
（4）estimated startup time：该值表示启动和打开物理备库所需要的时间，该字段不是适用于逻辑备库。 An estimate of the time needed to start and open the database
（5）VALUE：给出各个参数的值。如第1个查询中的，apply finish time值为+00 00:00:00.1，说明该物理备库需要0.1秒的时间来完成应用剩余的重做日志数据。
（6）UNIT：各个参数的时间单元。
（7）TIME_COMPUTED：物理备库上估算各个参数的本地时间。
（8）DATUM_TIME：在物理备库上获取元数据来估算 APPLY LAG 和 TRANSPORT LAG 这两个参数值的本地时间。如果从多次查询中看到该时间值对应的APPLY LAG 和 TRANSPORT LAG 这两个参数值保持不变的话，那么就说明该物理备库已经停止从主库接收到重做数据！该字段是11g中新出现的
官方文档上，关于V$DATAGUARD_STATS是这样描述的：该动态性能视图显示出在主库上产生了多少重做日志数据，但是还没有被备库所应用。所以，通过查询该视图可以基本确定如果万一主库出现崩溃的话，备库上将丢失多少重做日志数据。我们可以在一套Dataguard环境下的任一备库的实例上从该视图里获取相关信息，然而，在主库的实例上查询该视图返回的信息都将是空。也就是说，只可以从备库的实例上查询V$DATAGUARD_STATS，从主库实例上是看不到任何有用信息的。
二、实操switchover无损切换
1.我们在主库创建一个表空间test1，看看是否在备库应用了
SYS@LEO> create tablespace test1 datafile '/u01/app/oracle/oradata/LEO/file1/test01.dbf' size 20m;
Tablespace created.
SYS@LEO> select * from v$tablespace; 已经创建好了
TS# NAME INC BIG FLA ENC
---------- ------------------------------ --- --- --- ---
0 SYSTEM YES NO YES
1 UNDOTBS YES NO YES
2 SYSAUX YES NO YES
3 TEMPTS1 NO NO YES
4 USERS YES NO YES
6 TEMP1 NO NO YES
7 TEMP2 NO NO YES
8 EXAMPLE YES YES YES
9 TEST1 YES NO YES
2.我们看看备库有没有生成test1表空间
SYS@OEL> select * from v$tablespace; 我们在OEL库上没有看见test1表空间
TS# NAME INC BIG FLA ENC
---------- ---------------------- --- --- --- ---
0 SYSTEM YES NO YES
1 UNDOTBS YES NO YES
2 SYSAUX YES NO YES
3 TEMPTS1 NO NO YES
4 USERS YES NO YES
6 TEMP1 NO NO YES
7 TEMP2 NO NO YES
8 EXAMPLE YES YES YES
8 rows selected.
3.我们进行一次日志切换（LEO库）
SYS@LEO> alter system switch logfile; 日志切换后才把redo数据传到OEL库
System altered.
我们查看一下OEL的alert_OEL.log
RFS[1]: Archived Log: '/home/oracle/arch/OEL/log1_12_784052660.arc'
RFS进程已经获取到了12号归档日志
Mon Jun 4 19:46:42 2012
Media Recovery Log /home/oracle/arch/OEL/log1_12_784052660.arc
我们说过，如果不是实时应用，备库是从归档日志中获取恢复日志的（如果是实时应用我们是从standby logfile中获取恢复日志的）
Mon Jun 4 19:47:16 2012
Recovery created file /u01/app/oracle/oradata/OEL/file1/test01.dbf
Successfully added datafile 6 to media recovery
恢复表空间test1成功
Datafile #6: '/u01/app/oracle/oradata/OEL/file1/test01.dbf'
Mon Jun 4 19:47:27 2012
Media Recovery Waiting for thread 1 sequence 13 (in transit)
介质恢复等待13号归档日志
SYS@OEL> select * from v$tablespace; 此时test1表空间创建完毕
TS# NAME INC BIG FLA ENC
---------- ---------------------- --- --- --- ------------------- --- --- --- ---
0 SYSTEM YES NO YES
1 UNDOTBS YES NO YES
2 SYSAUX YES NO YES
3 TEMPTS1 NO NO YES
4 USERS YES NO YES
6 TEMP1 NO NO YES
7 TEMP2 NO NO YES
8 EXAMPLE YES YES YES
9 TEST1 YES NO YES
上面我们做了一个同步数据的小实验为了让我们感性认识DG的强大
下面进行switchover切换
（1）主库状态
作用：检查主库切换的可能性，如果“TO STANDBY”值表示主库可以顺利切换到备库
如果SWITCHOVER_STATUS=sessions active 表示当前仍然活动会话在进行，这是你可以添加“WITH SESSION SHUTDOWN”关键字在ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY语句之后进行强制关闭会话
SYS@LEO> select database_role,switchover_status,open_mode from v$database;
DATABASE_ROLE SWITCHOVER_STATUS OPEN_MODE
---------------- -------------------- -------------------------- -----------------
PRIMARY TO STANDBY READ WRIT
（2）LEO主库->OEL备库 注意看alert_LEO.log 是否有报错信息以便定位问题
SYS@LEO> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
Database altered.
这是alert_LEO.log日志显示的信息
Resetting standby activation ID 1558334580 (0x5ce24c74)
Mon Jun 4 20:16:30 2012
MRP0: Background Media Recovery process shutdown (LEO) MRP进程关闭
Mon Jun 4 20:16:30 2012
Switchover: Complete - Database shutdown required (LEO) 现在数据库（数据文件）为shutdown状态
Mon Jun 4 20:16:30 2012
Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN
SYS@LEO> select status from v$instance; 当前虽显示实例为开启状，但此时数据库为一个未知状态
STATUS
------------
STARTED
注：在switchover之前有一个自动备库控制文件的动作，以便以后重建之用
（3）重启LEO库
SYS@LEO> shutdown immediate
ORACLE instance shut down.
SYS@LEO> startup mount
ORACLE instance started.
Database mounted.
（4）检查OEL库状态
SYS@OEL> select database_role,switchover_status,open_mode from v$database;
DATABASE_ROLE SWITCHOVER_STATUS OPEN_MODE
---------------- -------------------- ------------------ -------------------- -----
PHYSICAL STANDBY TO PRIMARY MOUNTED
如果SWITCHOVER_STATUS= TO PRIMARY备库可以顺利切换到主库
如果SWITCHOVER_STATUS=sessions active 表示当前仍然活动会话在进行，这是你可以添加“WITH SESSION SHUTDOWN”关键字在ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY语句之后进行强制关闭会话，如果不加alert_LEO.log里有If media recovery active, switchover will wait 900 seconds
你需要等待900秒的时间，这只是一个估计值，实际上时间会更长
（5）OEL备库->LEO主库 注意看alert_OEL.log 是否有报错信息以便定位问题
SYS@OEL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
SwitchOver after complete recovery through change 169677
Online log /u01/app/oracle/oradata/OEL/file1/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/oracle/oradata/OEL/file2/redo1_2.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/oracle/oradata/OEL/file1/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/oracle/oradata/OEL/file2/redo2_2.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/oracle/oradata/OEL/file1/redo03.log: Thread 1 Group 3 was previously cleared
Online log /u01/app/oracle/oradata/OEL/file2/redo3_2.log: Thread 1 Group 3 was previously cleared
切换成主库之后要使用redo logfile
Standby became primary SCN: 169675
备库生成主库
Converting standby mount to primary mount.
转换备库mount状态->主库mount状态
Mon Jun 4 20:49:35 2012
Switchover: Complete - Database mounted as primary (OEL)
Mon Jun 4 20:49:35 2012
ARC0: STARTING ARCH PROCESSES
启动归档进程
Mon Jun 4 20:49:35 2012
Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
Mon Jun 4 20:49:35 2012
（6）OEL完成无损切换并打开
SYS@OEL> alter database open; 如果当初是mount状态，我们可以直接打开
Database altered.
SYS@OEL> SHUTDOWN IMMEDIATE; 如果当初是open状态，你就必须shutdown之后在startup
SYS@OEL> STARTUP;
注：如果你有多个备库，没有必要关闭->重启其他备库，这些备库在switchover之后会继续正常运行
（7）检查新主备库日志是否同步
SYS@OEL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# APP
---------- -----------
16 NO
16 NO
SYS@LEO> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# APP
---------- -------- ---
16 NO
已经同步，但LEO还没有应用日志，现在设置LEO库开始应用日志
（8）设置LEO库开始应用日志
SYS@LEO> alter database recover managed standby database disconnect from session parallel 2;
Database altered.
我们使用2个MRP进程恢复日志，查看alert_LEO.log日志
alter database recover managed standby database disconnect from session parallel 2
Mon Jun 4 21:24:14 2012
Attempt to start background Managed Standby Recovery process (LEO)
尝试启动介质恢复进程MRP
MRP0 started with pid=18, OS id=4046
Mon Jun 4 21:24:14 2012
MRP0: Background Managed Standby Recovery process started (LEO)
介质恢复进程MRP已经启动
Managed Standby Recovery not using Real Time Apply
没有使用实时应用，我们从归档日志中获取恢复日志
parallel recovery started with 2 processes
启动2个MRP进程
Mon Jun 4 21:24:21 2012
Completed: alter database recover managed standby database disconnect from session parallel 2
Mon Jun 4 21:24:22 2012
Clearing online redo logfile 1 /u01/app/oracle/oradata/LEO/file1/redo01.log
Clearing online log 1 of thread 1 sequence number 17 这是redo日志对应归档日志序号
开始清空所有redo日志，腾出空间便于重新使用，
小结：到此我们进行了一次完美的Switchover无损切换，大家都应该能看的明白吧，我把前后台所有内部变化都一一详细解析出来，再次强调一下所谓的无损就是要保持2边的日志必须有效同步，这样才能not data loss。下集请看 -> 第四篇 物理standby之failover 丢失切换
PS:ITPUB2012年的第二季度“技术新星”提名为候选人11http://www.itpub.net/thread-1615587-1-1.html
希望大家多多支持
候选人参选感言：
这是我职业生涯中第一个论坛荣誉，在这里得到了大家的支持与鼓励，不管结果如何，能够得到大家的认可是我最大的动力，我会继续努力，不辜负大家的期望！我会继续不断学习，不断的分享！
寄语：理论与实践需要交互进行，每一点汗水都是成功的阶梯，心有多大舞台就有多大，与大家共勉！
座右铭：分享技术 收获快乐
Leonarding
2012.6.04
于天津&summer
Blog：http://space.itpub.net/26686207
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/26686207/viewspace-731889/ ，如需转载，请注明出处，否则将追究法律责任。
