Dataguard日常维护

主备库的起停和维护

Dataguard关闭（先关主库再关备库）

Dataguard开启（先开备库再开主库）

日常的监控视图

1.select dest_name,status,error from v$archive_dest;

在主库上执行主要是查看日志归档目的地是否可用，如果远程归档目录不可用则error会显示错误信息。

SQL> select dest_name,status,error from v$archive_dest;

DEST_NAME           STATUS              ERROR

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

LOG_ARCHIVE_DEST_1  VALID

LOG_ARCHIVE_DEST_2  VALID

LOG_ARCHIVE_DEST_3  INACTIVE

LOG_ARCHIVE_DEST_4  INACTIVE

LOG_ARCHIVE_DEST_5  INACTIVE

LOG_ARCHIVE_DEST_6  INACTIVE

LOG_ARCHIVE_DEST_7  INACTIVE

LOG_ARCHIVE_DEST_8  INACTIVE

LOG_ARCHIVE_DEST_9  INACTIVE

LOG_ARCHIVE_DEST_10 INACTIVE

10 rows selected.

如上记录则代表备库归档日志目录有效且正常。

 

2.select database_role,LOG_MODE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;主要查询数据库的主备角色，以及当前dataguard保护的模式，主备库上查询结果不同。

 

SQL>select database_role,LOG_MODE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;

 

DATABASE_ROLE   LOG_MODE    PROTECTION_MODE     PROTECTION_LEVEL

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

PRIMARY         ARCHIVELOG  MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE

 

3. select name,SEQUENCE#,APPLIED from v$archived_log order by sequence#;

主要查询归档日志的应用情况。主备库上查询结果不同，在主库上对于每个归档文件会有两条记录。下面是在备库上的查询结果，可以看见日志应用都YES。

SQL> select name,SEQUENCE#,APPLIED from v$archived_log order by sequence#;

NAME                           SEQUENCE# APP

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

/opt/arch/1_5_726573806.dbf            5 YES

/opt/arch/1_6_726573806.dbf            6 YES

/opt/arch/1_7_726573806.dbf            7 YES

/opt/arch/1_8_726573806.dbf            8 YES

/opt/arch/1_9_726573806.dbf            9 YES

/opt/arch/1_10_726573806.dbf          10 YES

/opt/arch/1_11_726573806.dbf          11 YES

/opt/arch/1_12_726573806.dbf          12 YES

/opt/arch/1_13_726573806.dbf          13 YES

如果有发现日志不连续，则需要对照主库的归档日志序列，判断是否有丢失的日志，如果有则需要手动注册日志并应用归档。（方法：从主库的归档目录拷贝相应的归档文件到备库上注册alter database register physical logfile '/opt/arch/归档文件名’;然后手动应用日志alter database recover automatic standby database;

在测试过程中发现oracle10G下把丢失的归档日志文件考入指定目录会自动注册，不需手动注册。）

 

4，select process,status from v$managed_standby;

--查询主备库上的进程信息。

5，select message_num,message from v$dataguard_status;

--查看dataguard的状态信息。

6,select * from v$archive_gap;

--在备库检查是否有日志缺失

 

常见故障

1备库重启后，在主库上归档出现ORA-03113错误

SQL> select dest_name,status,error from v$archive_dest;

DEST_NAME             STATUS    ERROR

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

LOG_ARCHIVE_DEST_1    VALID

LOG_ARCHIVE_DEST_2    ERROR    ORA-03113: end-of-file on   communication channel

解决办法：在主库执行

SQL> alter system set log_archive_dest_state_2= enable;

这个命令式手动触发主库区尝试连接备库。

其实这种情况下，只要保证主备库之间的网络和配置是正确的。dataguard会自动恢复这个错误。这个周期默认是300秒，也可以在log_archive_dest_2的参数中添加reopen参数指定这个主备库之间失败后继续尝试的周期。

2 ORA-01031: insufficient privileges错误

SQL> select dest_name,status,error from v$archive_dest;

DEST_NAME             STATUS             ERROR

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

LOG_ARCHIVE_DEST_1   VALID

LOG_ARCHIVE_DEST_2   ERROR  ORA-01031: insufficient   Privileges

解决办法：统一主备库的数据库密码文件，或者重建密码文件，sys密码设置成一样。

然后在主库执行

SQL> alter system set log_archive_dest_state_2= enable;

3  ORA-16191: Primary log shipping client not logged on standby

SQL> select dest_name,status,error from v$archive_dest;

 

DEST_NAME     STATUS       ERROR

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

LOG_ARCHIVE_DEST_1   VALID

LOG_ARCHIVE_DEST_2  ERROR  ORA-16191: Primary log  shipping client not logged on standby

解决办法：统一主备库的数据库密码文件，或者重建密码文件，sys密码设置成一样。

然后在主库执行

SQL> alter system set log_archive_dest_state_2= enable;

4发现备库一直无法应用日志，MRP0进程显示WAIT_FOR_GAP的问题

发现从主库传来的日志无法应用

在备库检查,
SQL> select sequence#,applied from v$archived_log;

 SEQUENCE# APP
———- —
       930 NO
       931 NO
       932 NO
       933 NO

然后开始查看有没有mrp

[oracle@HJITBACKUP bdump]$ ps -ef | grep mrp
oracle   31896     1  0 14:37 ?     00:00:00 ora_mrp0_flow
oracle   32001 31820  0 15:17 pts/1    00:00:00 grep mrp

看来有，接着查gap，发现备库上有此进程，

SQL> select * from v$archive_gap;

no rows selected

查询视图没有发现，

在接着检查V$MANAGED_STANDBY

SQL> select process,status from v$managed_standby;

PROCESS   STATUS
——— ————
ARCH      CONNECTED
ARCH      CONNECTED
MRP0     WAIT_FOR_GAP
RFS       IDLE
RFS       IDLE

发现MRP0在等待GAP,进一步查看此视图

select process,status,group#,thread#,sequence#,block#,blocks from v$managed_standby;

PROCESS  STATUS   GROUP#   THREAD#  SEQUENCE#   BLOCK#    BLOCKS
——— ———— ———- ———- ———- ———- ———---——---——--------
ARCH  CONNECTED   N/A    0     0       0        0
ARCH  CONNECTED   N/A    0     0       0        0
MRP0  WAIT_FOR_GAP  N/A    1    928      0        0
RFS  IDLE      N/A    0    0       0        0
RFS  IDLE      N/A    0    0       0         0
发现日志928没有应用，

原来是由于主库删除了928，导致备库没法应用，所以只能从备份中恢复，restore archivelog
至此问题处理完毕。

查询备库状态
SQL> select process,status from v$managed_standby;

PROCESS   STATUS
——— ————
ARCH      CONNECTED
ARCH      CONNECTED
MRP0      WAIT_FOR_LOG
RFS       IDLE
RFS       IDLE
所以当standby装完后，在主库切换日志后，这里状态应该是
MRP0      WAIT_FOR_LOG才是正常的状态

注意事项

建议在主备库的涉及到名称地方都统一用小写字母，避免在配置过程出现莫名的错误。

如果在主库执行alter database clear unarchived logfile或alter database open resetlogs，则dataguard要重建。

在连续恢复模式下工作之前，需要保证之前所有的归档日志己经应用到备用库上。因为在连续恢复模式的情况下，oracle不会应用之前的归档日志，而只会应用后面陆续到来的归档日志。

新建表、表空间、datafile都能通过日志应用到备库，但新建一个临时表空间和rename datafile均不能应用到备库上。

出现归档日志gap时，需要找出相应的归档日志，然后将这些归档日志copy到备用节点的log_archive_dest目录下面。然后ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE;

应当实时察看standby库的alert文件，就能清晰明了地知道主备更新的情况。这也是排错的重要方法。

 

相关视图

V$ARCHIVE_DEST
V$ARCHIVE_DEST_STATUS
V$ARCHIVE_GAP
V$ARCHIVED_LOG
V$DATABASE
V$DATAFILE
V$DATAGUARD_STATUS
V$LOG
V$LOGFILE
V$LOG_HISTORY
V$STANDBY_LOG