管理Dataguard之--- 监控primary/standby数据库-阿里云开发者社区

开发者社区> 数据库> 正文

管理Dataguard之--- 监控primary/standby数据库

简介:

管理Dataguard之--- 监控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 、 动态性能视图

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

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

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

C) . 检查归档文件路径及创建信息---v$archived_log

  该视图查询standby数据库归档文件的一些附加信息,比如文件创建时间啦,创建进程啦,归档序号啦,是否被应用啦之类,例如:

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

D) . 查询归档历史---v$log_history

  该视图查询standby库中所有已被应用的归档文件信息(不论该归档文件是否还存在),例如:

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
  • 再来点与log应用相关的v$视图应用示例:

A) . 查询当前数据的基本信息---v$database信息。

  例如,查询数据库角色,保护模式,保护级别等:

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

  2  from v$database;

DATABASE_ROLE    DB_UNIQUE_NAME                 OPEN_MODE  PROTECTION_MODE      PROTECTION_LEVEL     SWITCHOVER_STATUS

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

PHYSICAL STANDBY jsspdg                         MOUNTED    MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY SESSIONS ACTIVE

  再比如,查询failover后快速启动的信息

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

B) . 检查应用模式(是否启用了实时应用)---v$archive_dest_status

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

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

RECOVERY_MODE

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

MANAGED REAL TIME APPLY

C) .Data guard 事件---v$dataguard_status

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

SQL> select message from v$dataguard_status;

MESSAGE

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

ARC0: Archival started

ARC1: Archival started

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

五、 调整物理standby log应用频率

调整应用频率说白了就是调整io读取能力,所以通常我们可以从以下几个方面 着 手:

1、 设置recover并行度

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

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

  推荐parallel的值是#CPUs*2;

2、 加快redo应用频繁

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

3、 设置PARALLEL_EXECUTION_MESSAGE_SIZE

  如果打开了并行恢复,适当提高初始化参数:PARALLEL_EXECUTION_MESSAGE_SIZE 的参数值,比如 4096 也 能提高大概20%左右的性能,不过需要注意增大这个参数的参数值可能会占用更多内存。

4、 优化磁盘I/O

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










本文转自 hsbxxl 51CTO博客,原文链接:http://blog.51cto.com/hsbxxl/747506,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章