发现一台服务器的备份目录总是趋于增长的趋势。
由于备份文件占用的空间不断的增长，使得存放备份的目录已经没有什么空闲空间了：
-bash-3.00$ df -k /data1
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c2t1d0s7 141179002 119536270 20230942 86% /data1
由于备份策略设置保留了14天：
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
且备份脚本中包含了DELETE OBSOLETE命令：
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK;
CROSSCHECK BACKUPSET;
DELETE NOPROMPT OBSOLETE;
DELETE NOPROMPT EXPIRED BACKUP;
因此总体来说，备份集的大小应该保持比较稳定才对。如果说是数据库的不断增加导致了备份集大小的不断增长，那么增长速度不应该如此之快，而数据库中数据的增长比较缓慢，不会是备份集空间不断增加的主要原因。
检查备份集信息，发现系统中甚至还保存着今年1月份的备份集，这些备份集应该被DELETE OBSOLETE命令清除掉才对。
-bash-3.00$ ls -l grep -c Jan
86
-bash-3.00$ ls -l grep -c Feb
76
-bash-3.00$ ls -l grep -c Mar
85
-bash-3.00$ ls -l grep -c Apr
81
-bash-3.00$ ls -l grep -c May
79
-bash-3.00$ ls -l grep -c Jun
78
-bash-3.00$ ls -l grep -c Jul
110
-bash-3.00$ ls -l grep -c Aug
30
通过RMAN检查现存的备份集，发现时间最早的是7月3日，到现在不过1个月左右，难道RMAN在删除备份集的时候只清除了控制文件中的信息，而没有删除磁盘上的文件。
RMAN> list backup;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
3599 292.00K DISK 00:00:01 03-JUL-09
BP Key: 3599 Status: AVAILABLE Compressed: NO Tag: TAG20090703T002631
Piece Name: /data1/backup/jiangsu/20090703_kbkj5pho_1_1
List of Archived Logs in backup set 3599
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 2063 1112304070500 03-JUL-09 1112304071252 03-JUL-09
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
3601 2.00K DISK 00:00:01 04-JUL-09
BP Key: 3601 Status: AVAILABLE Compressed: NO Tag: TAG20090704T000108
Piece Name: /data1/backup/jiangsu/20090704_kekj8ce5_1_1
List of Archived Logs in backup set 3601
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 2064 1112304071252 03-JUL-09 1112304071265 03-JUL-09
.
.
.
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
3797 Full 7.27M DISK 00:00:01 06-AUG-09
BP Key: 3797 Status: AVAILABLE Compressed: NO Tag: TAG20090806T002649
Piece Name: /data1/backup/jiangsu/20090806_c-499478642-20090806-00
Control File Included: Ckp SCN: 1112472897718 Ckp time: 06-AUG-09
SPFILE Included: Modification time: 05-AUG-09
检查以往的RMAN脚本日志，没有发现CROSSCHECK和DELETE命令的错误信息，那么除非是碰到bug，否则按道理来说应该不说RMAN的问题。
不过如果是bug的话，没有道理只删除了部分备份集，而遗漏了其他的部分，检查磁盘上遗漏的备份集，并没有发现什么规律之处。
看来问题似乎和RMAN的设置没有什么关系。如果不是RMAN的问题，还有什么可以控制备份集的保留时间呢，看来只可能是数据库的初始化参数control_file_record_keep_time了。
SQL> show parameter control_file_record
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_file_record_keep_time integer 7
显然这个初始化参数设置太小了，在设置备份保留策略的时候，没有响应的调整这个初始化参数的值。虽然RMAN的设置是可以恢复14天之内的数据：
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
但是对于控制文件而言，归档日志和备份集信息只确保7天内不被重用，当控制文件的空间用完，就会重用超过7天的归档和备份记录，对于nocatalog模式来说，这就意味着这些记录从控制文件中被删除了，而这些文件仍然留在操作系统中。当RMAN根据过期策略，需要清除过期文件时，因为控制文件中的信息已经被覆盖，RMAN根本就不知道这些备份和归档信息的存在，也就无法删除记录。这就是造成这个问题的原因。
根据0级备份或全备的间隔，已经备份策略的保留时间，去调整控制文件中记录的保留时间。
在这个例子中，由于备份每天执行，而RMAN策略是保留14天，因此至少应该将初始化参数control_file_record_keep_time调整到16天以上。
SQL> alter system set control_file_record_keep_time = 16;
System altered.
时隔不久，又碰到了一个RECOVERY WINDOW内的备份集被清除的问题，由于备份是存储到带库中，因此很难查询磁带上的文件是否被删除，应该一系列检查发现，问题也是由于这个初始化参数太小造成的。虽然带库上的文件没有被删除，但是控制文件中的备份集信息被重用，因此在RMAN中看到的结果，就是备份集已经不存在了。
当前位置：
论坛首页 »
自由讨论区 »
MySQL, Oracle及数据库讨论区
»
发起投票
技术讨论
加好友
发消息
2011-8-25 18:41:35 |
赞(
操作
