ITPub博客

首页 > Linux操作系统 > Linux操作系统 > ORA-19809: 超出了恢复文件数的限制故障处理实例

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

原创 Linux操作系统 作者:it_wangych 时间:2010-04-27 11:03:21 0 删除 编辑
转载: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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-07-06

  • 博文量
    43
  • 访问量
    80545