ORA-19809: limit exceeded for recovery files

最新推荐文章于 2019-07-08 13:39:40 发布
原创 最新推荐文章于 2019-07-08 13:39:40 发布 · 1.1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#file #disk #database #encryption #optimization #compression

Got an error when do the backup.

$ rman target /

Recovery Manager: Release 11.2.0.2.0 - Production on Wed Mar 2 02:12:32 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: LAB10G (DBID=1038266291)

RMAN> show all;

using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name LAB10G are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/orahome/oracle/product/11.2.0/dbhome_01/dbs/snapcf_LAB10G.f'; # default

RMAN> backup database;

Starting backup at 02-MAR-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=644 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00003 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/sysaux01.dbf
input datafile file number=00001 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/system01.dbf
input datafile file number=00010 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/transport01.dbf
input datafile file number=00021 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/migrate_data01.dbf
input datafile file number=00002 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/undotbs01.dbf
input datafile file number=00011 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/svc_mgmt01.dbf
input datafile file number=00004 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/users01.dbf
input datafile file number=00005 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/cmdb01.dbf
input datafile file number=00015 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/nsp01.dbf
input datafile file number=00006 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/mon_mgmt01.dbf
input datafile file number=00012 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/svc_mgmt_idx01.dbf
input datafile file number=00013 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/acct_mgmt01.dbf
input datafile file number=00019 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/knowledge_mgmt01.dbf
input datafile file number=00022 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/am_common_data01.dbf
input datafile file number=00024 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/am_itsp_data01.dbf
input datafile file number=00026 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/am_data01.dbf
input datafile file number=00028 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/attach_svc_data01.dbf
input datafile file number=00007 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/streams_tbs01.dbf
input datafile file number=00008 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/cmdb_idx01.dbf
input datafile file number=00009 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/mon_mgmt_idx01.dbf
input datafile file number=00014 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/acct_mgmt_idx01.dbf
input datafile file number=00016 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/nsp_idx01.dbf
input datafile file number=00020 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/knowledge_mgmt_idx01.dbf
input datafile file number=00023 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/am_common_idx01.dbf
input datafile file number=00025 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/am_itsp_idx01.dbf
input datafile file number=00027 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/am_idx01.dbf
input datafile file number=00029 name=/opt/app/oracle/oracle/product/10.2.0/db_1/oradata/LAB10G/attach_svc_idx01.dbf
channel ORA_DISK_1: starting piece 1 at 02-MAR-11
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 03/02/2011 02:15:04
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 52428800 bytes disk space from 2147483648 limit
continuing other job steps, job failed will not be re-run
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 02-MAR-11
channel ORA_DISK_1: finished piece 1 at 02-MAR-11
piece handle=/orahome/oracle/admin/LAB10G/flash_recovery_area/LAB10G/backupset/2011_03_02/o1_mf_ncsnf_TAG20110302T021317_6pw2ol1r_.bkp tag=TAG20110302T021317 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:04
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================

RMAN-03009: failure of backup command on ORA_DISK_1 channel at 03/02/2011 02:15:04
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 52428800 bytes disk space from 2147483648 limit
$ sqlplus /

SQL*Plus: Release 11.2.0.2.0 Production on Wed Mar 2 02:16:57 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning option

SQL> show parameter recovery

NAME                                 TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
db_recovery_file_dest                string
/orahome/oracle/admin/LAB10G/f
lash_recovery_area
db_recovery_file_dest_size           big integer
2G
recovery_parallelism                 integer
0
SQL> alter system set db_recovery_file_dest_size=30G
  2  ;

System altered.

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning option
$ rman target /

Recovery Manager: Release 11.2.0.2.0 - Production on Wed Mar 2 02:17:26 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: LAB10G (DBID=1038266291)

Do the backup again.

Just becasue backup files to fast recovery area.

henrybai
关注
ORA-19809: 超出了恢复文件数的限制
liu3348的专栏
05-13 4207
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
rman备份报ORA-19809 ORA-19804
cqszpx的博客
06-27 231
rman备份时报错信息：ORA-19809: limit exceeded for recovery filesORA-19804: cannot reclaim 52428800 bytes disk space from 2147483648 limitRMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS
ORA-19809: limit exceeded for recovery files问题
kt431128的专栏
04-03 204
ORA-16038: log 3 sequence# 472 cannot be archivedORA-19809: limit exceeded for recovery filesORA-00312: online log 3 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\CHEP\REDO03.LOG' 查了一下错误信息ORA-19809: ...
ORA-19809/ORA-19809: limit exceeded for recovery files 问题处理
caobihole
09-12 250
今天又遇到了这个问题，alert 日志中的报错信息如下： 其实问题的原因很简单，放归档的 fra 空间满了，导致无法归档，进而oracle挂起，注意这里db_recovery_file_dest 只是一个逻辑上的限制 ，可能放fra的目录还有空间剩余，但是oracle不会去用。平时还是要多多关注fra的使用情况。可以使用v$flash_recovery_area_usage 来查看fra的使用...
ORA-19809: limit exceeded for recovery files（超出了恢复文件数的限制）
syf8377的专栏
09-10 2325
客户数据库宕掉了，连接过去一看 可以正常到mount状态，然后alter database open，观察日志里面提示： ORA-19809: limit exceeded for recovery files Cause: The limit for recovery files specified by the DB_RECOVERY_FILE_DEST_SIZE was exceeded. ...
ORA-19809: 超出了恢复文件数的限制 ORA-19804: 无法回收 42991616 字节磁盘空间 (从 314572800 限制中)
不再疯要傻
02-14 5652
Rac环境下，启动数据库时候提示以下错误： [grid@RAC1 ~]$ srvctl  start database -d racdb PRCR-1079 : 无法启动资源 ora.racdb.db ORA-01034: ORACLE not available ORA-27101: shared memory realm does notexist Linux-x86_64 Erro
oracle数据库startup报ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
huangbaokang的博客
12-14 2906
oracle数据库startup的时候报了如下错： SQL> startup ORACLE instance started. Total System Global Area 6597406720 bytes Fixed Size 2240784 bytes Variable Size 4932505328 bytes Datab...
备份遇到RMAN-03009,ORA-19809,ORA-19804
不再疯要傻
07-09 1711
今天做实验想备份全库，随手输入backup database发现RMAN居然报错 RMAN> backup database; Starting backup at 09-JUL-15 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 cha
ORA-19809 limit exceeded for recovery files
cikunju7188的博客
04-17 195
使用RMAN备份的过程中，系统提示 ORA-19809 limit exceeded for recovery files 查询官方文档 ORA-19809: limit exceeded for recovery f...
ora-19809: limit exceeded for recovery files
有梦就别怕痛
01-10 436
错误代码： ora-19809: limit exceeded for recovery files 错误原因： 闪回恢复区flash_recovery_area目录容量已满 解决方法： 1. 设置归档到其他目录，修改alter system set log_archive_dest = 其他目录  2. 转移或删除闪回恢复区里的归档日志  3. 缩短备份保留时间，改为较
ORA-19815，ORA-19809 ：limit exceeded for recovery files
乐沙弥的世界
09-13 5047
数据库重新启动的时候，收到了ORA-19815的错误。从错误的提示来看，是由于闪回区的空间被填满导致无法成功启动。这种情形我们通常考虑的是清 除归档日志，那就直接在OS层面rm了，真的是这样吗？客官，如果你有相同的情形，接下往下看......
DBCA出错：ORA-19809: limit exceeded for recovery files处理过程
热门推荐
csdn's blog
07-08 1万+
1，dbca建库后台报错问题描述 [root@companydb1 rpms]# find / -name *alert*log /mnt/resource/app/oracle/diag/rdbms/strora/strora/trace/alert_strora.log /mnt/resource/app/oracle/product/11.2.0/dbhome_1/log/diag/rdbm...
ORA-01031:权限不足ORA-06512:在"SYS.DBMS SNAPSHOT KKXRCA", line 3020ORA-06512:在"SYS.DBMS ISNAPSHOT", line 216ORA-01403: 未找到任何数据ORA-06512:在"SYS.DBMS ISNAPSHOT", line 196ORA-06512:在"SYS.DBMS SNAPSHOT KKXRCA", line 2852ORA-06512:在"SYS.DBMS SNAPSHOT KKXRCA", line 326:ORA-06512:在"SYS.DBMS SNAPSHOT KKXRCA", ine 329!ORA-06512:在"SYS.DBMS SNAPSHOT", line 16ORA-06512:在line2 View program sources of error stack?
最新发布
03-14
<think>嗯，用户遇到了Oracle数据库的权限问题，具体是ORA-01031权限不足，还有涉及DBMS_SNAPSHOT和SYS包的调用错误。首先，我需要回想一下ORA-01031错误的常见原因。这个错误通常是因为用户没有执行特定操作所需的权限。比如，如果用户尝试访问某个表或执行某个存储过程，但没有相应的权限，就会报这个错误。所以，解决这个问题的第一步应该是检查用户的权限是否足够。 接下来，用户提到DBMS_SNAPSHOT_UTL包的问题，可能是在创建或管理物化视图日志时遇到的。这个包属于SYS用户，普通用户可能需要显式授权才能使用。我记得SYS的包默认只有DBA权限的用户才能访问，所以需要确认用户是否有EXECUTE权限。另外，引用1和2中提到的问题可能与Oracle版本有关，特别是11g的bug可能导致某些存储过程出错。这时候可能需要应用补丁或者升级数据库。 然后，用户还提到ORA-01555和ORA-12034错误。ORA-01555通常与UNDO表空间不足或查询时间过长有关，需要调整UNDO表空间的大小或优化查询。ORA-12034则涉及物化视图日志的问题，可能需要重新创建日志或调整刷新策略。 接下来，我需要考虑如何逐步指导用户解决这些问题。首先检查权限，授予必要的系统权限和对象权限。比如，如果用户需要创建物化视图，可能需要GRANT CREATE MATERIALIZED VIEW。然后检查SYS包的权限，比如DBMS_SNAPSHOT_UTL，可能需要用SYSDBA用户授予EXECUTE权限。 如果权限没有问题，可能需要考虑数据库版本的问题。引用2提到Oracle 11g的bug，如果在10g上没问题，可能需要查看是否触发了已知的bug，并检查是否有可用的补丁。此外，ORA-01555的问题需要调整UNDO表空间，增加大小或保留时间，避免长事务导致的错误。 最后，关于物化视图日志的问题，如ORA-12034，可能需要检查日志是否损坏，必要时重建，并确保刷新操作在合理的时间窗口内完成，避免数据不一致。 用户可能需要具体的步骤示例，比如如何授予权限，如何检查UNDO配置，如何重建物化视图日志等。同时，需要提醒用户谨慎操作SYS对象，最好在测试环境验证后再应用到生产环境。如果有必要，联系Oracle支持处理潜在的bug。</think>### 分步解决方案 #### **1. 解决 ORA-01031 权限不足问题** **步骤 1：确认操作所需的权限** - 若涉及创建/修改对象（如表、物化视图），需检查用户是否具备以下权限： ```sql GRANT CREATE TABLE, CREATE MATERIALIZED VIEW, CREATE ANY SNAPSHOT TO [用户名]; ``` - 若涉及系统包（如`DBMS_SNAPSHOT_UTL`），需授予`EXECUTE`权限： ```sql GRANT EXECUTE ON SYS.DBMS_SNAPSHOT_UTL TO [用户名]; ``` **步骤 2：检查角色继承** - 确保用户未被限制通过角色继承权限。Oracle 中某些权限需直接授予用户而非角色： ```sql SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE = '[用户名]'; ``` **步骤 3：验证 SYS 对象权限** - 若报错涉及`SYS.DBMS_SNAPSHOT_UTL`，需以`SYSDBA`身份检查包状态和权限： ```sql SELECT OBJECT_NAME, STATUS FROM DBA_OBJECTS WHERE OWNER = 'SYS' AND OBJECT_NAME = 'DBMS_SNAPSHOT_UTL'; GRANT EXECUTE ON SYS.DBMS_SNAPSHOT_UTL TO [用户名]; ``` **示例场景** 若用户执行物化视图刷新时出现权限不足： ```sql -- 直接授予物化视图相关权限 GRANT CREATE MATERIALIZED VIEW TO scott; GRANT EXECUTE ON DBMS_SNAPSHOT TO scott; ``` --- #### **2. 处理 DBMS_SNAPSHOT 和 SYS 包调用问题** **步骤 1：验证包状态** - 检查`DBMS_SNAPSHOT_UTL`是否有效： ```sql SELECT OBJECT_NAME, STATUS FROM DBA_OBJECTS WHERE OBJECT_NAME IN ('DBMS_SNAPSHOT_UTL', 'DBMS_SNAPSHOT'); ``` 若状态为`INVALID`，需重新编译： ```sql ALTER PACKAGE SYS.DBMS_SNAPSHOT_UTL COMPILE; ``` **步骤 2：处理 Oracle 版本兼容性问题** - 若问题在 Oracle 11g 中出现（如引用[^2]所述），检查是否触发已知 Bug： - 查询 Oracle 支持文档（如 MOS），确认 Bug 编号（如 Bug 12345678）。 - 应用官方补丁或升级到修复版本。 **步骤 3：重建物化视图日志（ORA-12034）** 若报错`ORA-12034: 实体化视图日志比上次刷新后的内容新`[^5]： ```sql -- 删除原有日志 DROP MATERIALIZED VIEW LOG ON scott.user_table; -- 重新创建日志 CREATE MATERIALIZED VIEW LOG ON scott.user_table WITH PRIMARY KEY, ROWID; ``` --- #### **3. 相关错误 ORA-01555 的预防** - **调整 UNDO 表空间**： ```sql ALTER DATABASE DATAFILE '/path/undo.dbf' RESIZE 10G; ALTER SYSTEM SET UNDO_RETENTION = 3600; -- 单位：秒 ``` - **避免长事务**：优化查询逻辑，减少全表扫描和锁竞争[^4]。 --- ### 总结操作顺序 1. 授予显式权限（对象权限 + SYS 包权限）。 2. 检查并修复无效的 SYS 包。 3. 处理版本兼容性问题（补丁/升级）。 4. 重建物化视图日志（针对 ORA-12034）。 5. 调整 UNDO 配置（针对 ORA-01555）。 ### 注意事项 - **谨慎操作 SYS 对象**：直接修改 SYS 拥有的包可能导致系统不稳定，建议先在测试环境验证。 - **监控 UNDO 使用**：通过`V$UNDOSTAT`视图分析 UNDO 空间使用趋势[^4]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值