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

转载: http://blog.csdn.net/inthirties/archive/2009/09/05/4521793.aspx

 

接到客户的请求，他的数据库坏掉了，启动不了，

马上连到了远程的数据库，启动数据库

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 set db_recovery_file_dest_size=4G scope=both;

这个方法同样，治标不治本，好比，现在现在水库泄洪，你扩大水库的size是一种方法，但是单纯靠这个方法，总有一天，还是overflow了。我们需要的应该是定期的就放一放水，增加容量，同时最好放到无限制的水库里

所以还有一个方法不要忘记了，就是把这个archivelog_dest指定到没有限制的地方

SQL>alter system set log_archive_dest='F:oracleproduct10.2.0archivelog_area';

OK了

这次故障处理，没有惊心动魄，以前遇到没有整理，这次详细的整理了一下记了下来。

不过由于客户的故障不能宕机太久，所以在处理的时候，没有记录出错信息，现在的整理的过程中的错误信息和操作步骤中的一些信息，全是在自己机器中模拟出来的，如果和实例有差异，以你的机器的实际信息为主。

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

转载于:http://blog.itpub.net/22021749/viewspace-660844/