Oracle Data Guard 主备库切换
Switchover
一般SWITCHOVER切换都是计划中的切换，特点是在切换后，不会丢失任何的数据，而且这个过程是可逆的，整个DATA GUARD环境不会被破坏，原来DATA GUARD环境中的所有物理和逻辑STANDBY都可以继续工作。
在进行DATA GUARD的物理STANDBY切换前需要注意：
1）确认主库和从库间网络连接通畅；
2）确认没有活动的会话连接在数据库中；
3）PRIMARY数据库处于打开的状态，STANDBY数据库处于MOUNT状态；
4）确保STANDBY数据库处于ARCHIVELOG模式；
5）如果设置了REDO应用的延迟，那么将这个设置去掉；
6）确保配置了主库和从库的初始化参数，使得切换完成后，DATA GUARD机制可以顺利的运行。
主库：
1. 查看switchover 状态
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
TO STANDBY
附: A:switchover_status出现session active/not allowed
当出现session active的时候表示还有活动的session,则运行
Alter database commit to switchover to physical standby with session shutdown;
当出现not allowed时，在官方文档说转换会不成功，但是我测试的时候成功了。
B.ora- 01153: an incompatible media recovery is active
运行下面代码
Alter database recover managed standby database finish;
或者Alter database recover managed standby database finish force;
Alter database recover managed standby database disconnect from session;
2 切换成备库
SQL>Alter database commit to switchover to physical standby with session shutdown;
或者
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
Database altered.
3 启动到mount和应用日志状态
SQL> SHUTDOWN IMMEDIATE
SQL> startup nomount;
SQL> alter database mount standby database;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
4. 查看数据库模式
SQL>select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_status;
SQL>select status,database_mode from v$archive_dest_status;
备库：
1.查看switchover状态
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
TO PRIMARY
附：若不是用此语句切换：ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY with session shutdown
补充：若出现：ORA-16139: media recovery required
是因为没有执行：alter database recover managed standby database disconnect from session;
2. 切换成主库
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Database altered.
SQL> shutdown immediate;
SQL> startup;
SQL> alter system switch logfile;
3. 查看数据库模式
SQL>select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_status;
SQL>select status,database_mode from v$archive_dest_status;
验证同步：
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
13
Failovers：
FAILOVER切换一般是PRIMARY数据库发生故障后的切换，这种情况是STANDBY数据库发挥其作用的情况。这种切换发生后，可能会造成数据的丢失。而且这个过程不是可逆的，DATA GUARD环境会被破坏。
由于PRIMARY数据库已经无法启动，所以FAILOVER切换所需的条件并不多，只要检查STANDBY是否运行在最大保护模式下，如果是的话，需要将其置为最大性能模式，否则切换到PRIMARY角色也无法启动。
1. 查看是否有日志GAP,没有应用的日志：
SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG;
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
如果有，则拷贝过来并且注册
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '路径';
重复查看直到没有应用的日志：
2. 然后停止应用归档：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
3. 下面将STANDBY数据库切换为PRIMARY数据库： -
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
或
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;
Database altered.
SQL> SELECT DATABASE_ROLE FROM V$DATABASE;
DATABASE_ROLE
----------------
PHYSICAL STANDBY
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Database altered.
SQL> ALTER DATABASE OPEN; 或者 shutdown immediate+startup
Database altered.
检查数据库是否已经切换成功：
SQL> SELECT DATABASE_ROLE FROM V$DATABASE;
DATABASE_ROLE
----------------
PRIMARY
至此，FAILOVER切换完成。这个时候应该马上对新的PRIMARY数据库进行备份。
List
监控日志应用服务 v$database
查看进程的活动状态 v$managed_standby
查看redo应用进度 v$archhive_dest
检查应用模式（是否启用了实时应用） v$archive_dest_status
检查归档文件路径和创建信息 v$archive_log
查询归档历史 v$log_histroy
修改语句查找最后应用的归档 v$log_history
Data Guard 事件 v$dataguard_status
调整物理Standby端REDO数据应用频率
监控日志应用服务
SQL>select database_role,db_unique_name,open_mode,protection_mode,protection_level,switchover_status from v$database;
查看进程的活动状态
V$managed_standby
SQL> SELECT PROCESS,CLIENT_PROCESS,SEQUENCE#, STATUS FROM
V$MANAGED_STANDBY;
PROCESS CLIENT_P SEQUENCE# STATUS
--------- -------- ---------- ------------
ARCH ARCH 0 CONNECTED
ARCH ARCH 0 CONNECTED
MRP0 N/A 9 WAIT_FOR_LOG
RFS UNKNOWN 0 IDLE相关说明：
PROCESS：进程名称，如ARCH、RFS、MRP0等。
CLIENT_P：对应的Primary数据库中的进程，如ARCH、LGWR等。
SEQUENCE#：归档序号。
STATUS：进程的当前状态，值较多，常见的有：
1）ALLOCATED：正准备连接Primary数据库。
2）ATTACHED：正在连接Primary数据库。
3）CONNECTED：已连接至Primary数据库。
4）IDLE：空闲中。
5）RECEIVING：归档文件接收中。
6）OPENING：归档文件处理中。
7）CLOSING：归档文件处理完，收尾中。
8）WRITING：REDO数据库写向归档文件中。
9）WAIT_FOR_LOG：等待新的REDO数据中。
10）WAIT_FOR_GAP：归档有中断，正等待中断的那部分REDO数据。
11）APPLYING_LOG：应用REDO数据中。
查看redo应用进度
V$archive_dest_status
SQL>
SELECT DEST_NAME,ARCHIVED_THREAD#,ARCHIVED_SEQ#,APPLIED_THREAD#,APPLIED_SEQ#,DB_UNIQUE_NAME FROM V$ARCHIVE_DEST_STATUS WHERE
STATUS='VALID';
DEST_NAME ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# DB_UNIQUE_NAME
-------------------- ---------------- - -- ------------ ------------------------------
LOG_ARCHIVE_DEST_1 1 8 0 0 dg_pd
LOG_ARCHIVE_DEST_2 1 8 1 7 dg_st
检查应用模式（是否启用了实时应用）
SQL>SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;
检查归档文件路径和创建信息
V$archived_log
SQL>SELECT NAME,CREATOR,SEQUENCE#,APPLIED,COMPLETION_TIME FROM
V$ARCHIVED_LOG
NAME CREATOR SEQUENCE# APP COMPLETIO
------------------------------ ------- ---------- --- ---------
/u01/archive/1_3_743828540.dbf ARCH 3 YES 23-FEB-11
/u01/archive/1_4_743828540.dbf ARCH 4 YES 23-FEB-11
/u01/archive/1_5_743828540.dbf ARCH 5 YES 23-FEB-11
/u01/archive/1_6_743828540.dbf ARCH 6 YES 23-FEB-11
/u01/archive/1_7_743828540.dbf ARCH 7 YES 23-FEB-11
查询归档历史
V$log_history
SQL> SELECT FIRST_TIME,FIRST_CHANGE#,NEXT_CHANGE#, SEQUENCE# FROM V$LOG_HISTORY;
FIRST_TIM FIRST_CHANGE# NEXT_CHANGE# SEQUENCE#
--------- ------------- ------------ ----------
23-FEB-11 446075 475647 1
23-FEB-11 475647 499245 2
23-FEB-11 499245 502860 3
23-FEB-11 502860 502901 4
23-FEB-11 502901 509381 5
23-FEB-11 509381 510608 6
23-FEB-11 510608 510610 7
7 rows selected.
修改语句查找最后应用的归档
SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG" FROM V$LOG_HISTORY GROUP BY THREAD#;
THREAD# LAST_APPLIED_LOG
---------- ----------------
1 8
Data Guard 事件
V$dataguard_status
调整物理Standby端的redo数据应用频率
1>设置recover并行度
Redo apply|sql apply 都需要读取重做日志，默认串行。
Parallel子句指定并行度
SQL>recover standby database parallel 2
建议#CPUs*2
2>加快应用频繁
Db_block_checking=false
3>设置PARALLEL_EXECUTION_MESSAGE_SIZE参数值
如果打开了并行恢复，适当提高初始化参数PARALLEL_EXECUTION_MESSAGE_ SIZE的参数值，比如4096也能提高大概20%左右的性能，不过需要注意，增大这个参数的参数值可能会占用更多内存。
4>优化磁盘I/0
恢复期间最大的瓶颈就是I/O读写，要缓解这个瓶颈，使用本地异步I/O并设置初始化参数DISK_ASYNCH_IO=TRUE会有所帮助。DISK_ASYNCH_IO参数控制到数据文件的磁盘I/O是否异步。某些情况下异步I/O 能降低数据库文件并行读取，提高整个恢复时间。
整理来自网络
491
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
