一、switchover和failover
所谓switchover是针对failover而言的，它是一种无损切换，切换的过程中不会丢失数据。可以平滑的使主备互换并且2个库都可以正常使用。
切换过程：主库->切换->备库->检查状态->原备库->切换->主库->再检查状态
应用场合：主库需要调整升级，主库性能不佳，这时可以切换后用新主库对外提供服务
是否丢失数据：不会丢失数据
所谓failover，它是一种丢弃切换，直接把备库切换成主库，原主库自动丢弃，也就是不在属于DG架构的一部分了。
切换过程：备库->切换->主库->检查状态，原主库脱离DG架构
应用场合：当主库发生严重故障不可逆转的时候可以使用failover，例如 我们熟悉纽约双子塔911事件，如果你的主库在那里，呵呵那么你就不要在犹豫了，failover是你最佳之选择 come on
是否丢失数据：极有可能丢失数据，我们的目标就是损失降到最低
如果在failure之前是maximum protection or maximum availability模式，会丢失数据
挽救措施：重建主库 使用原来备份恢复主库
Failover Role Transition 之前准备工作（标准流程，一般自己建的库最了解就可以skip）
1. 如果备库是maximum protection 必须先修改成maximum performance之后才能切换
修改语句： Alter database set standby database to maximize performance；
注：切换之后你可以在改回maximum protection mode
2. 如果主库与备库之间有日志传输的话，如上语句修改备库从maximum protection->maximum performance不会成功的。因为failover操作会删除原主库的DG配置，这也是为了保护主库操作
二、实操failover丢弃切换
需要知道的事情
1.failover操作之后，会自动丢弃原主库不在是DG一部分
2.如果你有多个备库，其他备库也会自动脱离DG，也不需要做shutdown 和 restart 动作。当有了新主库之后可以根据需要重新创建所有备库
3.我们推荐使用命令行的方式进行failover操作
4.不能在备库接收日志情况下进行failover操作
6.在进行切换之前检查归档日志号不能有缺口gap
5.如果你的备库是在maximum protection mode or maximum availability mode并且使用LGWR方式传送日志，那么归档日志号是不会有缺口的必须是连续的，这时可以直接停止接收日志，马上进行failover切换
进入操作环节
（1）检查备库归档日志号是否都是连续的，不能有缺口，否则需要补救
SYS@OEL> select database_role,switchover_status,open_mode from v$database;
DATABASE_ROLE SWITCHOVER_STATUS OPEN_MODE
---------------- -------------------- ---------- -------------------- ----------- --
PHYSICAL STANDBY NOT ALLOWED READ ONLY
备库现在是read only状态，我们调整到mounted
SYS@OEL> alter database recover managed standby database disconnect from session parallel 2;
SYS@OEL> select database_role,switchover_status,open_mode from v$database;
DATABASE_ROLE SWITCHOVER_STATUS OPEN_MODE
---------------- -------------------- -------------------------- ------------------
PHYSICAL STANDBY SESSIONS ACTIVE MOUNTED
我们在read only状态可以直接应用日志，OEL数据库自动调整到mounted状态
可以检查V$ARCHIVE_GAP查看归档日志号有没有缺口
SYS@OEL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
no rows selected
备库归档日志号是连续的。不用在拷贝归档日志了
Example：
如果得到这个结果，说明缺少90、91、92号归档日志，可以从主库->copy->备库，必须保证归档日志齐全，否则会在failover时导致数据丢失
加载copy归档日志信息至控制文件
ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
对比主备库归档日志列表的完整性
SYS@LEO> select sequence#,ARCHIVED,APPLIED from v$archived_log; 主库归档日志列表
SEQUENCE# ARC APP
---------- --- ---
10 YES YES
11 YES NO
11 YES YES
12 YES NO
12 YES YES
SYS@OEL> select sequence#,ARCHIVED,APPLIED from v$archived_log; 备库归档日志列表
10 YES YES
11 YES YES
12 YES YES
（2）终止了RFS进程，以便停止接收redo日志，终止日志应用
OEL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;
Database altered.
我们来看看后台是怎么做的
SKIP STANDBY LOGFILE option no longer needed for RECOVERFINISH. Option ignored
跳过备库redo日志，不在需要恢复
Thu Jun 7 20:09:43 2012
Terminal Incomplete Recovery: request posted (OEL)
Thu Jun 7 20:09:46 2012
Terminal Recovery timestamp is '06/07/2012 20:09:46' 终止恢复时间
Terminal Recovery: applying standby redo logs. 终止redo日志应用
Terminal Recovery: thread 1 seq# 13 redo required 在13号归档日志终止
Terminal Recovery: End-Of-Redo log allocation
MRP: Validating standby redo logfile 4
Thu Jun 7 20:09:46 2012
Media Recovery Log /u01/app/oracle/oradata/OEL/file1/redo4_1.rdo
Terminal Recovery: log 4 reserved for thread 1 sequence 13 redo4_1 对应的是13号归档日志
Identified End-Of-Redo for thread 1 sequence 13
Force关键字：终止了RFS进程，以便停止接收日志
Finish关键字：后面还可以跟随 FORCE WAIT NOWAIT
（3）备库执行failover丢弃切换
SYS@OEL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Database altered.
查看alert_OEL.log日志
ALTER DATABASE SWITCHOVER TO PRIMARY (OEL)
Thu Jun 7 20:37:39 2012
If media recovery active, switchover will wait 900 seconds
如果存在日志应用会等待900秒，实际上可能更长
Standby terminal recovery start SCN: 166513
SwitchOver after complete recovery through change 166514 启动所有在线日志组
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
Standby became primary SCN: 166512
备库变成了主库
Switchover: Complete - Database shutdown required (OEL)
此时数据库是一个不确定的状态，需要重启来恢复
SYS@OEL> select status from v$instance;
STATUS
------------
STARTED
注意：a.此时OEL数据库已经不能在接收原主库日志了
b.如果你有其他备用数据库，failover过程中，standby logfile内容会自动归档并应用到其他备用数据库
c.没有必要关闭并重启任何其他备库，因为已经不属于DG的一部分了
SYS@LEO> select database_role,switchover_status,open_mode from v$database;
DATABASE_ROLE SWITCHOVER_STATUS OPEN_MODE
---------------- -------------------- --------------- -------------------- ---------
PRIMARY NOT ALLOWED READ WRITE 我们看到切换状态已经变成：不允许了
（4）重新启动新主库
在failover之后OEL是read only 的话，必须shutdown immediate –> startup 重启数据库
在failover之后OEL是mounted 的话，可以直接open打开
SYS@OEL> shutdown immediate
SYS@OEL> startup
（5）检查数据库状态
SYS@OEL> select log_mode from v$database; 并且还是归档模式
LOG_MODE
------------
ARCHIVELOG
SYS@OEL> select database_role,switchover_status,open_mode from v$database;
DATABASE_ROLE SWITCHOVER_STATUS OPEN_MODE
---------------- -------------------- ---------------- -------------------- -------
PRIMARY NOT ALLOWED READ WRITE
此时OEL库已经切换成主库了，并且不属于DG一部分了，还是read write状态可以正常对外服务
（6）backup 新主库
为什么要备份新主库，这是一个安全措施，现在没有完整数据库备份，发生故障时也就没有了恢复源了，DBA 第一黄金定律：有备无患
（7）恢复原主库
惯例往往都是发生严重事故后进行failover切换，绝大多数主库已经不能在使用了，那么我们用什么方法可以恢复主库呢？
第一，flashback database to restore the failed primary database
第二，利用现有OEL库重新创建LEO库为备库
第三，使用RMAN恢复原主库
小结：failover时一定要想好了主库能否再恢复，数据能否再找回来。
一定要检查日志号的连接性，否则切换不能成功。
必须停掉日志接收和应用后在切换
深刻理解failover和switchover含义与区别
Leonarding
2012.6.7
于天津&summer
Blog：http://space.itpub.net/26686207
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26686207/viewspace-732195/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/26686207/viewspace-732195/
800
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
