2013年（350）
分类： Oracle
2013-04-24 16:39:38
对open resetlogs的primary数据库standby的恢复
当primary数据库被以resetlogs打开之后，dg提供了一些，能够让你快速的恢复物理standby，当然这是有条件的，不可能所有的情况都可以快速恢复。我们都知道alter database open resetlogs之后，的scn被重置，也就是此时其redo数据也会从头开始。当物理standby接收到新的redo数据时，redo应用会自动获取这部分redo数据。对于物理standby而言，只要数据库没有应用resetlogs之后的redo数据，那么这个过程是不需要dba手工参与的。
下表描述其它情况下如何同步standby与primary数据库。
|
Standby数据库状态 |
Standby服务器操作 |
解决方案 |
|
没有应用resetlog之前的redo数据 |
自动应用新的redo数据 |
无须手工介入 |
|
应用了resetlog之后的redo数据，不过standby打开了flashback。 |
可以应用，不过需要dba手工介入 |
1.手工flashback到应用之前 2.重启redo应用，以重新接收新的redo数据。 |
|
应用了resetlog之后的redo数据，而且没有flashback。 |
完全无法应用 |
重建物理standby是唯一的选择 |
很绕是吧，举个例子你就明白了：
假设primary数据库当前生成的archive sequence#如下：...26,27,28，然后在28的时候执行了resetlogs，又生成了新的1,2,3.....，那么standby能够正常接收并应用26,27,28及新产生的1,2,3....
如果primary数据库在28的时候发生数据出现故障，recover到27，然后resetlogs，又生成了新的1,2,3.....，这个时候(大家注意，招子放亮点)：如果standby还没有应用28，刚刚应用到27，则standby还可以继续接收新的redo数据1,2,3.....并应用。
如果此时不幸，standby由于是实时应用，已经应用了28的redo数据，那么如果standby打开了flashback，不幸中的万幸啊，这时候只需要dba手工介绍先flashback到27,然后再接收并应用新的1,2,3....
如果此时非常不幸，standby由于是实时应用，已经应用了28的redo数据，并且standby也没有打开flashback，那么，重建物理standby是你唯一的选择。
这下大家都明白了吧，赶紧起立鼓掌感谢yangtingkun大大的友情客串及形象示例，很通俗，很易懂:)。
监控primary/standby数据库
本节主要介绍一些监控dg配置的方式，先给大家提供一个表格(描述不同事件的不同信息监控途径)：
|
primary数据库事件 |
primary监控途径 |
standby监控途径 |
|
带有enable|disable thread子句的alter database命令 |
? Alert.log ? V$THREAD |
? Alert.log |
|
当前数据库角色，保护模式，保护级别，switchover状态，failover快速启动信息等 |
? V$DATABASE |
? V$DATABASE |
|
Redo log切换 |
? Alert.log ? V$LOG ? V$LOGFILE的status列 |
? Alert.log |
|
重建控制文件 |
? Alert log |
? Alert log |
|
手动执行恢复 |
? Alert log |
? Alert log |
|
表空间状态修改(read-write/read-only,online/offline) |
? DBA_TABLESPACES ? Alert log |
? V$RECOVER_FILE |
|
创建删除表空间或数据文件 |
? DBA_DATA_FILES ? Alert log |
? V$DATAFILE ? Alert log |
|
表空间或数据文件offline |
? V$RECOVER_FILE ? Alert log ? DBA_TABLESPACES |
? V$RECOVER_FILE ? DBA_TABLESPACES |
|
重命名数据文件 |
? V$DATAFILE ? Alert log |
? V$DATAFILE ? Alert log |
|
未被日志记录或不可恢复的操作 |
? V$DATAFILE view ? V$DATABASE view |
? Alert log |
|
恢复的进程 |
? V$ARCHIVE_DEST_STATUS ? Alert log |
? V$ARCHIVED_LOG ? V$LOG_HISTORY ? V$MANAGED_STANDBY ? Alert log |
|
Redo传输的状态和进度 |
? V$ARCHIVE_DEST_STATUS ? V$ARCHIVED_LOG ? V$ARCHIVE_DEST ? Alert log |
? V$ARCHIVED_LOG ? Alert log |
|
数据文件自动扩展 |
? Alert log |
? Alert log |
|
执行OPEN RESETLOGS或CLEAR UNARCHIVED LOGFILES |
? Alert log |
? Alert log |
|
修改初始化参数 |
? Alert log |
? Alert log |
概括起来主要通过二个方面：
1、Alert Log
一句话：一定要养成有事没事定期不定期随时查看alert.log的好习惯同时特别注意alert中的提示通常不经意间会发现它的提示能够让你的思路豁然开朗。
2、动态性能视图
先也是一句话：做为自己自觉主动维护的一批虚拟表它的作用非常明显通过它可以及时获得当前数据库状态及处理进度总之好处多多也需特别关注后面示例也会多处用到大家要擦亮双眼。
l 先来点与恢复进度相关的v$视图应用示例：
A).查看进程的活动状况---v$managed_standby
该视图就是专为显示standby数据库相关进程的当前状态信息，例如：
SQL> select process,client_process,sequence#,status from v$managed_standby;
PROCESS CLIENT_P SEQUENCE# STATUS
--------- -------- ---------- ------------
ARCH ARCH 763 CLOSING
ARCH ARCH 762 CLOSING
MRP0 N/A 764 WAIT_FOR_LOG
RFS LGWR 764 IDLE
RFS N/A 0 IDLE
PROCESS列显示进程信息
CLIENT_PROCESS列显示对应的主数据库中的进程
SEQUENCE#列显示归档redo的序列号
STATUS列显示的进程状态
通过上述查询可以得知primary开了两个归档进程，使用lgwr同步传输方式与standby通信，已经接收完763的日志，正等待764。
B).确认redo应用进度---v$archive_dest_status
该视图显示归档文件路径配置信息及redo的应用情况等，例如：
SQL> select dest_name,archived_thread#,archived_seq#,applied_thread#,applied_seq#,db_unique_name
2 from v$archive_dest_status where status='VALID';
字数受限，详细请查看：
