oracle dg异常处理,记一次dg故障的处理总结

今天早上收到一条报警短信，提示是dg的接收出了问题，从v$dataguard_status得到的最新记录如下：

2015-09-18 07:13:36.0 Fetch Archive LogErrorFAL[server, ARC1]: Error

270 creating remote archivelog file 'stest'

2015-09-18 07:13:36.0 Fetch Archive

LogErrorFAL[server, ARC3]: Error 270 creating remote archivelog file

'stest'

2015-09-18 07:13:36.0 Fetch Archive LogErrorFAL[server, ARC0]: Error 270

creating remote archivelog file 'stest'

使用dg broker来检查，发现已经提示error了。

初步猜想是备库的文件系统满了，结果连接到备库发现文件系统没有问题。

[root@stest~]# df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/sda6       6.0G  733M  4.9G  13% /

tmpfs            32G     0   32G   0% /dev/shm

/dev/sda1       124M   57M   62M  48% /boot

/dev/sda2       6.0G  1.7G  4.0G  31% /usr

/dev/sda3       4.0G  318M  3.5G   9% /var

/dev/sda7       5.4T  2.2T  3.0T  42% /U01

这个时候排除了文件系统的问题，那可能就是归档所在的闪回区的大小溢出了。这是一个11g的库，对于闪回区的空间利用率应该还是能够做一些管控的。

带着疑问查看了闪回区的设置，发现闪回区的空间设置还是比较大的，应该没有什么问题。

SQL> show parameter recover

NAME                                 TYPE          VALUE

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

db_recovery_file_dest                string        /U01/app/oracle/oradata/bidb/archive

db_recovery_file_dest_size           big integer   400G

db_unrecoverable_scn_tracking        boolean       TRUE

查看了归档路径，

SQL>show parameter archive_log

log_archive_dest_1                   string        location=USE_DB_RECOVERY_FILE_DEST, valid_for=(ALL_LOGFILES,ALL_ROLES)

这个时候数据库日志就是一个很好的工具，可以好好利用。

发现日志中已经有了下面的提示。

************************************************************************

Creating archive destination file : /U01/app/oracle/oradata/test/archive/STEST/archivelog/2015_09_18/o1_mf_1_81698_%u_.arc (544928 blocks)

Fri Sep 18 07:19:36 2015

Errors in file /U01/app/oracle/diag/rdbms/sbidb/test/trace/test_rfs_16263.trc:

ORA-19815: WARNING: db_recovery_file_dest_size of 429496729600 bytes is 100.00% used, and has 0 remaining bytes available.

************************************************************************

You have following choices to free up space from recovery area:

1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,

then consider changing RMAN ARCHIVELOG DELETION POLICY.

2. Back up files to tertiary device such as tape using RMAN

BACKUP RECOVERY AREA command.

3. Add disk space and increase db_recovery_file_dest_size parameter to

reflect the new space.

4. Delete unnecessary files using RMAN DELETE command. If an operating

system command was used to delete files, then use RMAN CROSSCHECK and

DELETE EXPIRED commands.

....

************************************************************************

Creating archive destination file : /U01/app/oracle/oradata/test/archive/STEST/archivelog/2015_09_18/o1_mf_1_81699_%u_.arc (546048 blocks)

Fri Sep 18 07:13:36 2015

Errors in file /U01/app/oracle/diag/rdbms/stest/bidb/trace/test_rfs_15685.trc:

ORA-19815: WARNING: db_recovery_file_dest_size of 429496729600 bytes is 100.00% used, and has 0 remaining bytes available.

好了问题，看起来已经很明显了。

归档的空间占用导致闪回区溢出，但是我们确实有归档的删除策略，而且脚本在其它环境中都在普遍使用，也没有碰到问题。

$ crontab -l

40 * * * * (. $HOME/.bash_profile;$HOME/xxxx/scripts/rman_trun_arch.sh)

脚本的主要内容就是定期检查删除一天前的归档。

rman target / <

crosscheck archivelog all;

delete noprompt expired archivelog all;

delete noprompt archivelog until time "sysdate-1";

exit

EOF

exec 3>&1 4>&2 1>>${LOGFILE} 2>&1

从这个脚本来看，也没有什么异常之处，为什么归档删除策略有，但是还是没有删除归档。

带着疑问排查了一圈，才发现是有下面的原因导致的。

$ ps -ef|grep smon

oracle    2019     1  0 Jul28 ?        00:01:14 ora_smon_test

oracle   29478     1  0 Jul24 ?        00:01:20 ora_smon_mtest

oracle   30508 27347  0 22:50 pts/0    00:00:00 grep smon

这台服务器上运行着两个备库，而默认的ORACLE_SID是mtest，是另外一个备库，相当于test这个备库还没有配置归档删除策略,所以闪回区的利用率就一直没有释放。

查看归档的情况，已经有快半个月没有清理过归档了。所以这个问题也是一点一点累计起来的，最终在特定的时间爆发出来。

所以为了尽快释放闪回空间，就直接先运行脚本，然后在crontab脚本中指定ORACLE_SID来进行处理,这个问题的处理就告一段落。

再次查看dg broker，配置已经显示成功了。

DGMGRL> show configuration;

Configuration - dg_mbionline

Protection Mode: MaxPerformance

Databases:

test  - Primary database

stest- Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

闪回区的使用率一下子释放出来了。

FILE_TYPE            PER_USED PER_RECLAIMABLE FILES

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

CONTROL FILE               0              0     0

REDO LOG                 2.1              0     7

ARCHIVED LOG             1.6              0     7

BACKUP PIECE               0              0     0

IMAGE COPY                 0              0     0

FLASHBACK LOG              0              0     0

FOREIGN ARCHIVED LOG       0              0     0

通过这个例子，可以看到一些通用的脚本在特定的场景下，可能会有一些潜在的问题，需要我们明辨。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1803499/，如需转载，请注明出处，否则将追究法律责任。