Oracle 11G R2 DataGuard日常维护及故障处理

1.关于Forced Logging模式
有一些DDL语句可以通过指定NOLOGGING子句的方式避免写redo log(目的是提高速度，某些时候确实有效)，指定数据库为FORCE LOGGING模式后，数据库将会记录除临时表空间或临时回滚段外所有的操作而忽略类似NOLOGGING之类的指定参数。如果在执行force logging时有nologging之类的语句在执行，则force logging会等待直到这类语句全部执行。FORCE LOGGING是做为固定参数保存在控制文件中，因此其不受重启之类操作的影响(只执行一次即可)

打开force logging

SQL > alter database force logging;

关闭force logging

SQL > alter database no force logging;

查看force logging的状态：

SQL > select FORCE_LOGGING from v$database;

2.关于主备库的密码

密码文件位置$Oracle_HOME/dbs/orapwSID，主备库的密码必须要一致，否则可能出现日志无法传输故障，最好是使用scp传过去较为方便

3.关于listener.ora和tnsnames.ora

listener.ora为数据库的监听配置文件，tnsnames.ora为网络服务名配置文件

修改listener.ora是需要重启监听程序，而tnsnames.ora是不需要重启的，我们可以使用默认的listener.ora

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
    )
  )
ADR_BASE_LISTENER = /opt/oracle

以上是动态注册，如果是静态注册的话，则是

SID_LIST_LISTENER =
 (SID_LIST =
  (SID_DESC =
    (SID_NAME = PLSExtProc)
    (ORACLE_HOME = /opt/oracle/product/11.2.0/db_1)
    (PROGRAM = extproc)
  )

  (SID_DESC =
    (GLOBAL_DBNAME = db1)
    (ORACLE_HOME = /opt/oracle/product/11.2.0/db_1)
    (SID_NAME = db1)
  )
  )

tnsnames.ora则只需要添加服务名

db1 =
  (DEST_NAME
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = db1)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = db1)
    )
  )

db2 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = db2)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = db2)
    )
  )

以上按照自己的实际情况进行修改
以上配置好了，就可以相互的tnsping  db1或tnsping db2进行测试

4.参数文件说明

参数文件说明：
增加以下参数，如果在初始化参数已经有配置，则看需要做相应的修改。

1、与主库角色相关的初始化参数说明：

DB_NAME
注意保持同一个Data Guard环境中所有数据库DB_NAME相同

DB_UNIQUE_NAME
为每一个数据库指定一个唯一的名称,以标示同一个dataguard环境中不同的数据库。

LOG_ARCHIVE_CONFIG
该参数通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME(含主库db及备库db)，以逗号分隔。

例如：LOG_ARCHIVE_CONFIG='DB_CONFIG=(db1,db22)'

LOG_ARCHIVE_DEST_n
归档文件的生成路径。该参数非常重要,dataguard就是通过这里的设置传输日志的。

LOG_ARCHIVE_DEST_STATE_n
指定参数值为ENABLE，标示对应的LOG_ARCHIVE_DEST_n参数是否有效。

REMOTE_LOGIN_PASSWORDFILE
推荐设置参数值为EXCLUSIVE或者SHARED，注意保证相同Data Guard配置中所有db服务器sys密码相同。如果不同日志传输会失败。数据库默认是EXCLUSIVE,一般不用修改。

LOG_ARCHIVE_FORMAT
指定归档文件格式。一般也不用修改，保持默认即可

2、以下参数为备库角色相关的参数，建议在主库的初始化参数中也进行设置，这样在主备库角色相互转换后不需要做修改dataguard也能正常运行。

FAL_SERVER
指定备库到主数据库的连接服务名，FAL_SERVER = orcl2日志所在服务器。

FAL_CLIENT
指定主库到备库的连接服务名，FAL_CLIENT = orcl日志接收客户端。

STANDBY_FILE_MANAGEMENT

如果主库的数据文件发生修改（如新建，重命名等）则按照本参数的设置在备库中做相应修改。设为AUTO表示自动管理。设为MANUAL表示需要手工管理。

例如：STANDBY_FILE_MANAGEMENT=AUTO

下面开始修改主库的初始化参数。

db_name参数已经设置，不用修改

SQL> alter system set db_unique_name =’db1’ scope=spfile;
SQL> alter system set log_archive_config='dg_config=(db1,db2)' scope=spfile;
---这里的db1和db2为db_unique_name

SQL> alter system set log_archive_dest_1='location=/opt/oracle/flash_recovery_area' scope=spfile;
--/opt/oracle/flash_recovery_area为本地的归档目录，需要手动创建该目录，当然也可以指定别的路径。

注意oracle账号对该目录又可读写的权限。
SQL> alter system set log_archive_dest_state_1=enable scope=spfile;
--这个通常不用修改，系统默认的就是enable。

SQL>alter system set log_archive_dest_2='service=db2 valid_for=(online_logfiles,primary_role) arch async NOAFFIRM db_unique_name=db2' scope=spfile;
-----这里的service为主库连接到备库的服务名，后面会在tnsnames.ora文件中配置

valid_for参数说明这个归档日志目的地在本数据库为主库的角色下才需要把online_logfile传输到备库去。arch async NOAFFIRM说明的是同步的方式，同步的方式有三种:最大保护，最大性能，最大可用。

SQL> alter system set log_archive_dest_state_2=enable scope=spfile;
以上修改的是作为主库角色需要的参数，为了方便以后主备库切换，建议在主库中也配置作为备库角色的相关参数。
SQL> alter system set fal_server=db2 scope=spfile;
SQL> alter system set fal_client=db scope=spfile;
SQL> alter system set standby_file_management=auto scope=spfile;
生成静态参数文件，以备后面给备库使用。

SQL> create pfile from spfile;
重新启动主库，使参数生效。

6.DataGuard启动停止及维护：

DataGuard停止：先主后备

DataGuard启动：先备后主

7.DataGuard日常监控视图

a.主库查看日志归档路径是否可用，如果远程归档目录不可用则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.
如上记录则代表备库归档日志目录有效且正常

b.查询数据库的主备角色，以及当前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

备库：

SQL> select database_role,LOG_MODE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;
DATABASE_ROLE    LOG_MODE    PROTECTION_MODE      PROTECTION_LEVEL
---------------- ------------ -------------------- --------------------
PHYSICAL STANDBY ARCHIVELOG  MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE

c.获取归档日志的应用情况，主备库结果不同。在主库上对于每个归档文件会有2条记录

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

备库:

/opt/oracle/flash_recovery_area/1_11_904130046.dbf   11   YES
/opt/oracle/flash_recovery_area/1_12_904130046.dbf   12   YES
/opt/oracle/flash_recovery_area/1_13_904130046.dbf   13   YES
/opt/oracle/flash_recovery_area/1_14_904130046.dbf   14   YES
/opt/oracle/flash_recovery_area/1_15_904130046.dbf   15   YES
/opt/oracle/flash_recovery_area/1_16_904130046.dbf   16   YES
/opt/oracle/flash_recovery_area/1_17_904130046.dbf   17   YES
/opt/oracle/flash_recovery_area/1_18_904130046.dbf   18   YES
/opt/oracle/flash_recovery_area/1_19_904130046.dbf   19   YES
/opt/oracle/flash_recovery_area/1_20_904130046.dbf   20   YES
/opt/oracle/flash_recovery_area/1_21_904130046.dbf   21   YES
/opt/oracle/flash_recovery_area/1_22_904130046.dbf   22   YES
/opt/oracle/flash_recovery_area/1_23_904130046.dbf   23   YES
/opt/oracle/flash_recovery_area/1_24_904130046.dbf   24   IN-MEMORY

如果有发现日志不连续，则需要对照主库的归档日志序列，判断是否有丢失的日志，如果有则需要手动注册日志并应用归档。

（方法：从主库的归档目录拷贝相应的归档
文件到备库上注册alter database register physical logfile '/opt/oracle/flash_recovery_area/归档文件名’;

然后手动应用日志alter database recover automatic standby database;
在测试过程中发现oracle10G下把丢失的归档日志文件考入指定目录会自动注册，不需手动注册。）

d.查询主备库的进程信息

SQL> select process,status from v$managed_standby;
--查询主备库上的进程信息

主库：

SQL>select process,status from v$managed_standby;
PROCESS  STATUS
--------- ------------
ARCH      CLOSING
ARCH      CLOSING
ARCH      CLOSING
ARCH      CLOSING
LNS      WRITING

备库:

SQL> select process,status from v$managed_standby;
PROCESS  STATUS
--------- ------------
ARCH      CONNECTED
ARCH      CONNECTED
ARCH      CLOSING
ARCH      CONNECTED
RFS      IDLE
RFS      IDLE
MRP0      APPLYING_LOG

注意以上2个红色部分

f.查看dataguard的状态信息

SQL > select message_num,message from v$dataguard_status;

g.检查备库是否有日志缺失

SQL > select * from v$archive_gap;

6.主备库的切换

switchover  （计划中的切换，不会丢失数据）

failover  （当主库出现故障的时候需要主备库切换角色）

a.switchover的切换

主库端：
select switchover_status from v$database;
如果是to standby表可以正常切换.
直接执行alter database commit to switchover to physical standby;
否则执行:alter database commit to switchover to physical standby with session shutdown;
shutdown immediate;
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;

备库端：
select switchover_status from v$database;
如果是to_primary表可以正常切换.
执行: alter database commit to switchover to primary;
否则执行: alter database commit to switchover to primary with session shutdown;
shutdown immediate;
startup;

b.failover的切换

(1)判断主数据库确实出现严重的硬件故障或其他原因导致主数据库无法启动。

(2)在物理备用数据库上检查是否有archive redo log gaps
SQL>SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

(3)消除archive redo log gaps
从主数据库上或其他备份的地方把没有传到物理备用数据库的archive redo log传到物理备用数据库上，并注册到物理备用数据库的controlfile中。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'archive redo log文件名称';
重复2,3步骤直到V$ARCHIVE_GAP视图无记录存在。

(4）在物理备用数据库上发起failover操作
SQL > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;

(5)把物理备用数据库转化成主用角色
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

(6)把新的主用数据库重新启动
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;

(7)对新的主用数据库做全备份.

7.归档日志的处理
a.物理备库中已经应用的归档日志需定期删除.
rman> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';
删除7天前的归档日志文件。删除之后最好做一个全备份。

b. 先手动删除归档日志文件，然后再RMAN里执行下面2条命令以更新控制文件
crosscheck archivelog all;
delete expired archivelog all;

c. 取消对备库传送日志
ALTER SYSTEM SET log_archive_dest_state_2=’DEFER’ ;

8.常见故障：

a.备库重启后，在主库上归档出现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参数指定这个主备库之间失败后继续尝试的周期。

b.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;

c.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;

d.发现备库一直无法应用日志，MRP0进程显示WAIT_FOR_GAP的问题
发现从主库传来的日志无法应用
在备库检查,
SQL> select sequence#,applied from v$archived_log;
 SEQUENCE# APP
———- —
      930 NO
      931 NO
      932 NO
      933 NO
      934 NO
      935 NO
      936 NO
      937 NO
      938 NO
      939 NO
      940 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,进一步查看此视图

SQL> 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, THREAD#, SEQUENCE#, BLOCK#, BLOCKS  FROM V$MANAGED_STANDBY;

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

9.注意事项
建议在主备库的涉及到名称地方都统一用小写字母，避免在配置过程出现莫名的错误。
如果在主库执行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