Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1114586
  • 博文数量: 350
  • 博客积分: 10
  • 博客等级: 民兵
  • 技术积分: 5668
  • 用 户 组: 普通用户
  • 注册时间: 2011-03-23 17:53
文章分类

全部博文(350)

文章存档

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

概括起来主要通过二个方面:

1Alert Log

一句话:一定要养成有事没事定期不定期随时查看alert.log的好习惯同时特别注意alert中的提示通常不经意间会发现它的提示能够让你的思路豁然开朗。

2动态性能视图

先也是一句话:做为自己自觉主动维护的一批虚拟表它的作用非常明显通过它可以及时获得当前数据库状态及处理进度总之好处多多也需特别关注后面示例也会多处用到大家要擦亮双眼。

先来点与恢复进度相关的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';

字数受限,详细请查看:

一步一步学DataGuard(10)物理standby之高级管理3全文


阅读(574) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~