ORA-19809: 超出了恢复文件数的限制故障处理实例

ORA-19809: 超出了恢复文件数的限制故障处理实例 收藏
作者: 三十而立 http://blog.csdn.net/inthirties/archive/2009/09/05/4521793.aspx
时间：2009年9月05日 0:44:18
本文出自 “inthirties（三十而立）”博客，转载请务必注明作者和保留出处http://blog.csdn.net/inthirties/archive/2009/09/05/4521793.aspx
没有惊心动魄，但也记忆犹新。ORA-19809: 超出了恢复文件数的限制故障处理实例
接到客户的请求，他的数据库坏掉了，启动不了，
马上连到了远程的数据库，启动数据库
SQL>startup;
数据库提示已经启动了。
SQL>select status from v$instance;
mount状态
SQL>shutdown immediate;
SQL>startup
Total System Global Area 1.0435E+10 bytes
Fixed Size                  2021512 bytes
Variable Size            2466252664 bytes
Database Buffers         7952400384 bytes
Redo Buffers               14753792 bytes
数据库装载完毕。
ORA-16038: 日志 1 序列号 865 无法归档
ORA-19809: 超出了恢复文件数的限制
ORA-00312: 联机日志 1 线程 1:
'E:ORACLEPRODUCT10.2.0ORADATAORCLREDO01.LOG'
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-16014: 日志 1 的序列号 865 未归档, 没有可用的目的地
ORA-00312: 联机日志 1 线程 1:
'E:ORACLEPRODUCT10.2.0ORADATAORCLREDO01.LOG'
通过这里的错误信息，可以看到是归档归档不了了，马上查看归档的路径
SQL> archive log list;
数据库日志模式            存档模式
自动存档             启用
存档终点            USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列     23
下一个存档日志序列   25
当前日志序列           25
用的是DB_RECOVERY_FILE_DEST的路径了。
估计又是以前遇到过的错误的。
Oracle官方的有关19809的信息
ORA-19809: limit exceeded for recovery files
Cause: The limit for recovery files specified by the DB_RECOVERY_FILE_DEST_SIZE was exceeded.
Action: The error is accompanied by 19804. See message 19804 for further details.
ORA-19804: cannot reclaim string bytes disk space from string limit
Cause: Oracle cannot reclaim disk space of specified bytes from the DB_RECOVERY_FILE_DEST_SIZE limit.
Action: There are five possible solutions:
1) Take frequent backup of recovery area using RMAN.
2) Consider changing RMAN retention policy.
3) Consider changing RMAN archivelog deletion policy.
4) Add disk space and increase DB_RECOVERY_FILE_DEST_SIZE.
5) Delete files from recovery area using RMAN.
这里是官方提供的信息和解决方案了，以前遇过这个错误，还记得是怎么搞定的吗
当然记得，经历是最好的学习方式。这样的错误恢复当然是记得怎么搞的的哟。
基本上的原因是，db_recovery_file_desc有size限制，默认是2G，如果用户没有设置过的话，应该就是这里的归档的文件超过了这个大小，而导致归档失败了，
先查看一下情况吧
SQL> archive log list;
数据库日志模式            存档模式
自动存档             启用
存档终点            USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列     23
下一个存档日志序列   25
当前日志序列           25
SQL> select * from v$recovery_file_dest;
NAME
----------------------------------------------------------------
SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
----------- ---------- ----------------- ---------------
F:developeroracleproduct10.2.0 lash_recovery_area
2147483648 2547483848                 0               73
这里已经把所有的db_recovery_file_dest的容量都占完了。
解决方法，
删除多余的归档文件。
然后设置较大的db_recovery_file_dest_size
把log_archive_destx指定到别的地方，不要放到db_recovery_file_dest这里了
开始我们的恢复之旅吧，数据的恢复就像旅行一般，让我们在oracle的知识体系里旅游一样
删除多余的归档文件
打开RMAN
rman target /
RMAN>crosscheck archivelog all;
运行这个命令可以把无效的archivelog标准出来，这样，我们就知道哪些是expired的了
RMAN>delete expired archivelog all;
也可以直接用一个指定的日期来删除
RMAN>delete noprompt archivelog until time "sysdate -3";
我用的上面的方式 delete expired archivelog all; 低调低调
这样基本上就搞定了，数据库应该可以启动了，
试试看就知道
SQL>alter database open;
熟悉的启动的信息出来了。
不过这样完，就有点不是学习知识的态度了，因为你这个是一个治标不治本的方法，
随时客户还会因为这个问题，一个星期，一个月后找你，因为，这里的archivelog，可能又操过限制了
因为这里的archivelog还在不断的增长，既然是这样就还会出现这样的问题。
要解决他，
我们要针对着这个问题的本质动刀了。
action
指定retention的策略，使得archivelog不至于这样增加
RMAN>configure retention policy to recovery window of 7 days;
RMAN>configure retention policy to redundancy 3;
呵呵呵   客户没有使用RMAN来进行备份，下次有机会要介绍给客户，同时也多接这样一个业务，客户现在还没有因为数据崩溃而崩溃过，所以现在他还不知道这个价值，如果那天有这样一天，客户想起我给他介绍的RMAN，估计自己就会想起来找我的。 嘻嘻
指定大一些db_recovery_file_dest_size
SQL>alter system db_recovery_file_dest_size=4G scope=both;
这个方法同样，治标不治本，好比，现在现在水库泄洪，你扩大水库的size是一种方法，但是单纯靠这个方法，总有一天，还是overflow了。我们需要的应该是定期的就放一放水，增加容量，同时最好放到无限制的水库里
所以还有一个方法不要忘记了，就是把这个archivelog_dest指定到没有限制的地方
SQL>alter system log_archive_dest='F:oracleproduct10.2.0archivelog_area';
OK了