点击上方“IT那活儿”,关注后了解更多精彩内容!!!
主库操作
SQL> col DEST_NAME for a20SQL> col DESTINATION for a25SQL> col ERROR for a15SQL> col ALTERNATE for a20SQL> set lines 1000SQL>select DEST_NAME,DESTINATION,ERROR,ALTERNATE,TYPE,status,VALID_TYPE,VALID_ROLE from V$ARCHIVE_DEST where STATUS <>'INACTIVE';在主库检查创建的最后一个归档日志:SQL> select thread#, max(sequence#) "Last Primary Seq Generated" from gv$archived_log val, gv$database vdb where val.resetlogs_change# = vdb.resetlogs_change# group by thread# order by 1;
备库操作
使用以下查询,检查从主数据库接收到的最后一个归档日志;
查看备库从主库收到的最后一个归档日志:
SQL> select thread#, max(sequence#) "Last Standby Seq Received" from gv$archived_log val, gv$database vdb where val.resetlogs_change# = vdb.resetlogs_change# group by thread# order by 1;
验证初始化参数
log_archive_configfal_serverdb_unique_namelog_archive_dest_n
确保先决条件得到完全验证,同时遵循以下指导以成功切换,这些步骤应在真正的计划中断开始之前执行,并确保没有问题。
验证重做/归档日志应用良好并且没有GAP。
在备数据库中运行以下查询以检查从所有线程接收和应用的最后一个归档日志序列,这将不包括当前序列,因为 SQL 正在从 v$archived_log 中提取详细信息。
SQL> select thread#, max(sequence#) "Last Standby Seq Applied"from gv$archived_log val, gv$database vdbwhere val.resetlogs_change# = vdb.resetlogs_change#and val.applied in ('YES','IN- MEMORY')group by thread# order by 1;
检查 MRP 进程状态(它应该开始运行并应用日志):
SQL> select * from gv$dataguard_process;
停止和启动托管恢复过程的命令:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
无论出于何种原因,如果备库恢复 (MRP) 延迟启动,或者如果备用数据库始终保持滞后,则切换将消耗时间来应用要同步的日志。
在切换之前,尽量保持最小的归档日志应用延迟,这将减少总切换时间窗口。
检查数据文件和临时文件状态。
预计所有数据文件在主备库中都应该在线,如果有文件离线(或)不在在线状态,则恢复文件并恢复以确保备库文件与主库文件相同。
如果有离线文件和切换后的文件,如果切换后需要在线,则将文件在线。
SQL> SELECT NAME FROM V$DATAFILE WHERE STATUS='OFFLINE';SQL> ALTER DATABASE DATAFILE 'datafile-name' ONLINE;
对于临时文件:
SQL> select tf.name filename, bytes, ts.name tablespace from v$tempfile tf, v$tablespace ts where tf.ts#=ts.ts#;
列出的临时文件对于应用程序来说已经足够好了,应该没问题。
联机和备用重做日志文件配置
set lines 150col member for a50select a.thread#,a.group#,a.bytes,a.blocksize,b.type,a.status,b.member from v$log a,v$logfile b where a.group#=b.group#;
从primary执行上述命令时,可能会得到:
a.status in (INACTIVE,ACTIVE,CURRENT)Expected a.status from Standby is UNUSED, CLEARING or CLEARING_CURRENT,
如果输出有不同的结果,则需要手动清除redo logfiles。
对于备库redo日志文件(SRL):
select s.thread#,s.group#,s.status,s.bytes,l.type,l.member from v$logfile l,v$standby_log s where s.group#=l.group#;
备用重做日志文件状态将处于UNASSIGNED 或ACTIVE状态。
清除 ORL 组的命令:
SQL> ALTER DATABASE CLEAR LOGFILE GROUP <ORL GROUP# >;
如果需要在备用数据库中清除 ORL 或 SRL,则必须停止恢复过程。
检查警报日志文件
* 检查是否有任何重做传输报告的问题?
* 没有密码文件的问题?
* 没有 TNS 或连接问题
b. 从备用数据库确保:
* 没有与托管恢复相关的错误
* 通过应用存档日志/重做日志向前恢复
* 没有 TNS 或连接问题
* 没有I/O 问题或损坏问题
select * from v$database_block_corruption; -- 它不返回任何行select * from v$nonlogged_block; -- 它不返回任何行
检查归档日志 GAP 和redo延迟应用
主库执行以下命令:
SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
GAP_STATUS 应该是 NO GAP。
如果报告了不同的结果,则不应尝试切换。
如果配置了延迟,则停止恢复进程并立即启动该过程。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
如果延迟没有消除,那么切换将需要更长的时间。
SQL> ALTER DATABASE SWITCHOVER TO <standby db_name> VERIFY;
如果出现错误,请修复问题,然后重新运行切换验证命令。
SQL> ALTER DATABASE SWITCHOVER TO <standby db_name>;
如果步骤1成功,则按照步骤2启动新的primay库到open模式
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT from SESSION;
在主库:
SQL> alter system archive log current;SQL>select dest_id,error,status from v$archive_dest where dest_id=<your remote log_archive_dest_<n>>;SQL>select max(sequence#),thread# from v$log_history group by thread#;
SQL>select max(sequence#) from v$archived_log where applied='YES' and dest_id=2;
在备库:
SQL>select max(sequence#),thread# from v$archived_log group by thread#;SQL> select name,role,instance,thread#,sequence#,action from gv$dataguard_process;


END
更多精彩干货分享
点击下方名片关注
IT那活儿





