ORA-19809: 超出了恢复文件数的限制

一、故障现象:

RMAN> backup database;

启动 backup 于 05-10月-14

使用目标数据库控制文件替代恢复目录

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: sid=158 devtype=DISK

通道 ORA_DISK_1: 启动全部数据文件备份集

通道 ORA_DISK_1: 正在指定备份集中的数据文件

输入数据文件 fno=00001 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF

输入数据文件 fno=00005 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\HW_WH01.DBF

输入数据文件 fno=00003 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF

输入数据文件 fno=00002 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF

输入数据文件 fno=00006 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\GZ_DATA01.DBF

输入数据文件 fno=00007 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SZ_DATA01.DBF

输入数据文件 fno=00004 name=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF

通道 ORA_DISK_1: 正在启动段 1 于 05-10月-14

MAN-03009: backup 命令 (ORA_DISK_1 通道上, 在 12/08/2014 16:38:37 上) 失败

ORA-19804: 无法回收 52428800 字节磁盘空间 (从 2147483648 限制中)

继续执行其它作业步骤, 将不重新运行失败的作业

通道 ORA_DISK_1: 启动全部数据文件备份集

通道 ORA_DISK_1: 正在指定备份集中的数据文件

备份集中包括当前控制文件

在备份集中包含当前的 SPFILE

通道 ORA_DISK_1: 正在启动段 1 于 05-10月-14

通道 ORA_DISK_1: 已完成段 1 于 05-10月-14

段句柄=D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2014_12_08\O1_MF_NCSNF_TAG20141208T163642_7G0XWHOH_.BKP 标记=TAG20141208T163642 注释=NONE

通道 ORA_DISK_1: 备份集已完成, 经过时间:00:00:02

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

二、故障分析

在使用rman进行数据库全备份时出现ORA-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-19809错误是伴随着ORA-19804出现,接着我们看下ORA-19804的出现原因及解决方案:

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_DEST_SIZE的设置

首先查看数据库的当前设置:

SYS @ ORCL(159)> archive log list

数据库日志模式            存档模式

自动存档             启用

存档终点            USE_DB_RECOVERY_FILE_DEST

最早的联机日志序列     163

下一个存档日志序列   165

当前日志序列           165

SYS @ ORCL(159)>

可以看到使用了数据库默认的闪回区用来存储归档,接下来我们看下闪回区的位置,大小及使用情况

SYS @ ORCL(159)> show parameter db_recovery_file_dest

NAME                                 TYPE        VALUE

------------------------------------ ----------- -----------------------------------------------

db_recovery_file_dest                string      D:\oracle\product\10.2.0/flash_recovery_area

db_recovery_file_dest_size           big integer 2G

SYS @ ORCL(159)> select NAME,SPACE_LIMIT/1024/1024 "total(MB)",SPACE_USED/1024/1024 "used(MB)"

from v$recovery_file_dest;

NAME                                              total(MB)   used(MB)

------------------------------------------------ ---------- ----------

D:\oracle\product\10.2.0/flash_recovery_area           3072 2078.77051

对于db_recovery_file_dest_size,系统默认设置为2G大小,当该空间不够容纳备份集则会导致上面见到的错误。

三、解决方案:

对于上面的错误我们扩大了db_recovery_file_dest_size仍出错(由2G扩大至3G),可以看出即使扩容也是不够做一次全备份的(后面能够看到这个备份集得实际大小为2.05G)

1、扩大db_recovery_file_dest_size参数设置

alter system set db_recovery_file_dest_size=5G;

2、查看当前设置情况

show parameter db_recovery_file_dest

3、重新执行rman备份

RMAN> backup database;

......

RMAN> list backupset;

BS 关键字  类型 LV 大小       设备类型 经过时间 完成时间

------- ---- -- ---------- ----------- ------------ ----------

14      Full    2.05G      DISK        00:02:19     09-12月-14

BP 关键字: 14   状态: AVAILABLE  已压缩: NO  标记: TAG20141209T141548

段名:D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2014_12_09\O1_MF_NNNDF_TAG20141209T141548_7G2ZC4L2_.BKP

备份集 14 中的数据文件列表

文件 LV 类型 Ckp SCN    Ckp 时间   名称

---- -- ---- ---------- ---------- ----

1       Full 5170484    09-12月-14 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF

2       Full 5170484    09-12月-14 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF

3       Full 5170484    09-12月-14 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF

4       Full 5170484    09-12月-14 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF

5       Full 5170484    09-12月-14 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\HW_WH01.DBF

6       Full 5170484    09-12月-14 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\GZ_DATA01.DBF

7       Full 5170484    09-12月-14 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SZ_DATA01.DBF

BS 关键字  类型 LV 大小       设备类型 经过时间 完成时间

------- ---- -- ---------- ----------- ------------ ----------

15      Full    6.83M      DISK        00:00:02     09-12月-14

BP 关键字: 15   状态: AVAILABLE  已压缩: NO  标记: TAG20141209T141548

段名:D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2014_12_09\O1_MF_NCSNF_TAG20141209T141548_7G2ZHQFO_.BKP

包括的控制文件: Ckp SCN: 5170574      Ckp 时间: 09-12月-14

包含的 SPFILE: 修改时间: 09-12月-14

至此问题已成功解决。

ORA-19809: 超出了恢复文件数的限制,布布扣,bubuko.com

时间: 05-12

ORA-19809: 超出了恢复文件数的限制的相关文章

记录一次Linux操作系统最大文件数限制的解决过程

在前面的文章中之前遇到过There is insufficient memory for the Java Runtime Environment to continue问题,无法连接上服务器.(http://blog.csdn.net/xifeijian/article/details/38326281),当时的解决方案是通过加大linux最大文件句柄数,问题暂时得到了解决. 可是在后来的工作中仍然遇到服务器连接不上的情况,之前一直怀疑是该服务器上性能测试脚本导致占据大量句柄. 奇怪的问题是:

Linux 下最大文件数等限制

操作如下: ulimit -a      #查看现有各个限制值情况 ulimit -n      #查看现有打开文件打开数量最大值 cat /proc/sys/fs/file-max         #查看本Linux最大打开文件打开数限制 echo ' *               soft  nofile 409600 ' >> /etc/security/limits.conf        #修改 echo ' *               hard nofile 409600 '

备份

假设条件:数据库完整的备份:数据库处于归档状态并保留所有的归档日志,完成下面的任务,贴出完整的操作过程,并给出你的恢复思路 1.用Rman分别作数据库,表空间和数据文件的备份. 2.模拟数据库,表空间和数据文件损坏后的恢复操作. 3.用示例说明两种库增量备份的差别. 4.模拟控制文件丢失后的数据库恢复(完全恢复). 5.模拟状态为inactive的日志损坏的恢复实验(完全恢复). 6.模拟状态为active的日志损坏的数据恢复实验(不完全恢复). 7.假设在最有一次全库备份之后,你误删除了一张表

oracle 归档空间满的解决办法

问题现象: 通过命令提示符登陆数据库,一般提示"ora-03113:通信通道的文件结尾"错误,查看trace日志,可以看到详细信息.部分摘录如下(橙色部分给出了建议方案): Errors in file g:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_1368.trc: ORA-19815: 警告: db_recovery_file_dest_size 字节 (共 4102029312 字节) 已使用 100.00%,

跟我学SharePoint 2013视频培训课程——删除恢复、文档离线工作(11)

课程简介 第11天,怎样在SharePoint 2013中删除.恢复文档.文档离线工作. 视频 SharePoint 2013 交流群 41032413

Oracle RMAN备份恢复指导书

目 录 1 目的与范围... 1 2 术语和定义... 1 3 角色和职责... 2 4 使用RMAN备份数据库... 2 4.1.1 检查数据库模式... 2 4.1.2 连接到target数据库... 3 4.1.3 查看备份信息... 3 4.1.4 备份数据库... 5 4.1.5 备份数据文件... 6 4.1.6 备份表空间... 6 4.1.7 备份控制文件... 6 4.1.8 备份归档日志文件... 7 4.1.9 备份闪回区... 8 4.1.10 增量备份... 8 4.2

WebUploader API文档

Web Uploader内部类的详细说明,以下提及的功能类,都可以在WebUploader这个变量中访问到. As you know, Web Uploader的每个文件都是用过AMD规范中的define组织起来的, 每个Module都会有个module id. 默认module id为该文件的路径,而此路径将会转化成名字空间存放在WebUploader中.如: module base:WebUploader.Base module file: WebUploader.File module l

四种生成和解析XML文档的方法详解

众所周知,现在解析XML的方法越来越多,但主流的方法也就四种,即:DOM.SAX.JDOM和DOM4J 一.介绍及优缺点分析 1. DOM(Document Object Model) DOM是用与平台和语言无关的方式表示XML文档的官方W3C标准.DOM是以层次结构组织的节点或信息片断的集合.这个层次结构允许开发人员在树中寻找特定信息.分析该结构通常需要加载整个文档和构造层次结构,然后才能做任何工作.由于它是基于信息层次的,因而DOM被认为是基于树或基于对象的. [优点]      ①允许应用

Linux 打开文件数1024限制的原理以及解决办法

/proc/sys/fs/file-max  该文件指定了可以分配的文件句柄的最大数目. 查看最大值: [[email protected] home]# cat /proc/sys/fs/file-max  100977 [[email protected] home]# 这表明这台Linux系统最多允许同时打开(即包含所有用户打开文件数总和)100977个文件,是Linux系统级硬限制,所有用户级的打开文件数限制都不应超过这个数值.通常这个系统级硬限制是Linux系统在启动时根据系统硬件资源