登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

飞哥的技术博客

世上无难事,只怕有心人!

 
 
 

日志

 
 
 
 

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

2009-10-07 14:28:25|  分类: Oracle |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
  一步一步学DataGuard(10)物理standby之高级管理3

我们都知道alter database open resetlogs之后,数据库的scn被重置,也就是此时其redo数据也会从头开始。当物理standby接收到新的redo数据时,redo应用会自动获取这部分redo数据。对于物理standby而言,只要数据库没有应用resetlogs之

假设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是你唯一的选择。

Ø  V$ARCHIVE_DEST_STATUS

Ø  V$ARCHIVE_DEST_STATUS

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

A) v$managed_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

SQL> select dest_name,archived_thread#,archived_seq#,applied_thread#,applied_seq#,db_unique_name

  2  from v$archive_dest_status where status='VALID';

DEST_NAME            ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# DB_UNIQUE_

-------------------- ---------------- ------------- --------------- ------------ ----------

LOG_ARCHIVE_DEST_1                  1           765               0            0 jsspdg

LOG_ARCHIVE_DEST_2                  0             0               0            0 jssweb

STANDBY_ARCHIVE_DEST                1           764               1          764 NONE

SQL> select name,creator,sequence#,applied,completion_time from v$archived_log;

NAME                                CREATOR  SEQUENCE# APP COMPLETION_TIM

-------------------------------------------------- ------- ---------- --- --------------

E:\ORA10G\ORADATA\JSSPDG\LOG1_750_641301252.ARC    ARCH      750 YES 18-1月 -08

E:\ORA10G\ORADATA\JSSPDG\LOG1_749_641301252.ARC    ARCH      749 YES 18-1月 -08

E:\ORA10G\ORADATA\JSSPDG\LOG1_751_641301252.ARC    ARCH      751 YES 18-1月 -08

E:\ORA10G\ORADATA\JSSPDG\LOG1_752_641301252.ARC    ARCH      752 YES 18-1月 -08

E:\ORA10G\ORADATA\JSSPDG\LOG1_753_641301252.ARC    ARCH      753 YES 18-1月 -08

E:\ORA10G\ORADATA\JSSPDG\LOG1_754_641301252.ARC    ARCH      754 YES 18-1月 -08

SQL> select first_time,first_change#,next_change#,sequence# from v$log_history;

FIRST_TIME          FIRST_CHANGE# NEXT_CHANGE#  SEQUENCE#

------------------- ------------- ------------ ----------

2008-01-03 12:00:51        499709       528572         18

2008-01-08 09:54:42        528572       539402         19

2008-01-08 22:00:06        539402       547161         20

2008-01-09 01:05:57        547161       560393         21

2008-01-09 10:13:53        560393       561070         22

SQL> select database_role,db_unique_name,open_mode,protection_mode,protection_level,switchover_status

DATABASE_ROLE    DB_UNIQUE_NAME                 OPEN_MODE  PROTECTION_MODE      PROTECTION_LEVEL     SWITCHOVER_STATUS

---------------- ------------------------------ ---------- -------------------- -------------------- --------------------

PHYSICAL STANDBY jsspdg                         MOUNTED    MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY SESSIONS ACTIVE

SQL> select fs_failover_status,fs_failover_current_target,fs_failover_threshold,

  2  fs_failover_observer_present from v$database;

FS_FAILOVER_STATUS    FS_FAILOVER_CURRENT_TARGET     FS_FAILOVER_THRESHOLD FS_FAIL

--------------------- ------------------------------ --------------------- -------

DISABLED                                                                 0

查询v$archive_dest_status视图,如果打开了实时应用,则recovery_mode会显示为:MANAGED REAL TIME APPLY,例如:

SQL> select recovery_mode from v$archive_dest_status where dest_id=2;

该视图显示那些被自动触发写入alert.log或服务器trace文件的事件。通常是在你不便访问到服务器查询alert.log时,可以临时访问本视图查看一些与dataguard相关的信息,例如:

SQL> select message from v$dataguard_status;

----------------------------------------------------------------------------

ARC0: Becoming the 'no FAL' ARCH

ARC0: Becoming the 'no SRL' ARCH

ARC1: Becoming the heartbeat ARCH

Attempt to start background Managed Standby Recovery process

MRP0: Background Managed Standby Recovery process started

Managed Standby Recovery not using Real Time Apply

Media Recovery Waiting for thread 1 sequence 761

在介质恢复或redo应用期间,都需要读取重做日志文件,默认都是串行恢复,我们可以在执行recover的时候加上parallel子句来指定并行度,提高读取和应用的性能,例如:

SQL> alter database recover managed standby database parallel 2 disconnect from session;

设置初始化参数DB_BLOCK_CHECKING=FALSE能够提高2倍左右的应用效率,该参数是验证数据块是否有效,对于standby禁止验证基本上还是可以接受的,另外还有一个关联初始化参数DB_BLOCK_CHECKSUM,建议该参数在primary和standby都设置为true。

4096

在恢复期间最大瓶颈就是I/O读写,要缓解这个瓶颈,使用本地异步I/O并设置初始化参数DISK_ASYNCH_IO=TRUE会有所帮助。DISK_ASYNCH_IO参数控制到数据文件的磁盘I/O是否异步。某些情况下异步I/O 能降低数据库文件并行读取,提高整个恢复时间。

 
引文来源  一步一步学DataGuard(10)物理standby之高级管理3 - 无名扫把 - CSDN博客
  评论这张
 
阅读(498)| 评论(0)

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018