记一次dg故障的处理总结(r6笔记第63天)

今天早上收到一条报警短信，提示是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 / <<EOF 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

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