在11g中建立10。1或10。2基表的物化视图，就会引发这个错误：
SQL> CONN YANGTK/YANGTK@192。25。1。101/TEST101已连接。 SQL> CREATE TABLE T (ID NUMBER); 表已创建。 SQL> CREATE MATERIALIZED VIEW LOG ON T WITH ROWID; 实体化视图日志已创建。
SQL> CONN YANGTK/yangtk@192。25。1。103/ORA11G_P。YTK_THINKPAD已连接。 SQL> CREATE MATERIALIZED VIEW MV 2 REFRESH FAST 3 WITH ROWID 4 AS SELECT * FROM T@TEST101。
YTK; CREATE MATERIALIZED VIEW MV *第 1 行出现错误: ORA-04052: 在查找远程对象 SYS。DBMS_SNAPSHOT@TEST101。YTK 时出错 ORA-00604: 递归 SQL 级别 2 出现错误 ORA-06544: PL/SQL: 内部错误, 参数: [55916], [], [], [], [], [], [], [] ORA-06553: PLS-801: 内部错误 [55916] ORA-02063: 紧接着 2 lines (起自 TEST101。
YTK) 和其他内部错误有所区别的是，这个错误不会出现在后台告警日志中。 当前的数据库版本为11。1。0。6，而物化视图基表数据库的版本为10。1。0。2： SQL> SELECT * FROM V$VERSION; BANNER ------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11。
1。0。6。0 - Production PL/SQL Release 11。1。0。6。0 - Production CORE 11。1。0。6。0 Production TNS for Linux: Version 11。1。0。6。
0 - Production NLSRTL Version 11。1。0。6。0 - Production SQL> CONN YANGTK/YANGTK@192。25。1。101/TEST101已连接。 SQL> SELECT * FROM V$VERSION; BANNER ----------------------------------------------- Oracle Database 10g Enterprise Edition Release 10。
1。0。2。0 - Prod PL/SQL Release 10。1。0。2。0 - Production CORE 10。1。0。2。0 Production TNS for 32-bit Windows: Version 10。1。
0。2。0 - Production NLSRTL Version 10。1。0。2。0 - Production 通过检查metalink，在文档Doc ID: Note:4511371。8中详细描述了这个bug，只要在11g中调用10。
1版本(补丁小于10。1。0。5)或10。2版本(补丁小于10。2。0。2)数据库中的过程，就会引发这个错误。 除了打补丁升级之外，没有什么好的临时解决方法。将10g的数据库升级到10。1。0。5或10。2。0。2版本以上，可以避免问题的产生。
问题：在备份Oracle10g时出现下面的错误: ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 100。00% used, and has 0 remaining bytes available。
************************************************************* You have the following choices to free up space from flash recovery area: 1。
Consider changing your RMAN retention policy。 If you are using dataguard, then consider changing your RMAN archivelog deletion policy。
2。 Backup files to tertiary device such as tape using the RMAN command BACKUP RECOVERY AREA。 3。 Add disk space and increase the db_recovery_file_dest_size parameter to reflect the new space。
4。 Delete unncessary files using the RMAN DELETE command。 If an OS command was used to delete files, then use RMAN CROSSCHECK and DELETE EXPIRED commands。
************************************************************* 此时flash_recovery_area已经手工释放空间，甚至切换到一个全新的磁盘，但问题依然没有办法解决。 解决过程如下： 首先，连接数据库查询： $ sqlplus "/ as sysdba" SQL*Plus: Release 10。
1。0。2。0 - Production on Mon Mar 28 11:45:30 2005 Copyright (c) 1982, 2004, Oracle。 All rights reserved。 Connected to: Oracle Database 10g Enterprise Edition Release 10。
1。0。2。0 - 64bit Production With the Partitioning, OLAP and Data Mining options SYS AS SYSDBA on 28-MAR-05 >set liesize 120 SP2-0158: unknown SET option "liesize" SYS AS SYSDBA on 28-MAR-05 >set linesize 120 SYS AS SYSDBA on 28-MAR-05 >SELECT substr(name, 1, 30) name, space_limit AS quota, 2 space_used AS used, 3 space_reclaimable AS reclaimable, 4 number_of_files AS files 5 FROM v$recovery_file_dest ; NAME QUOTA USED RECLAIMABLE FILES ---------------------------------- ---------- ---------- ----------- ---------- /data5/flash_recovery_area 2147483648 2144863232 0 227 在此处发现仍然记录了227个文件，但USED空间并未释放。
然后用rman登录数据库进行crosscheck： $ rman target / Recovery Manager: Release 10。1。0。2。0 - 64bit Production Copyright (c) 1995, 2004, Oracle。
All rights reserved。 connected to target database: EYGLE (DBID=1337390772) RMAN> crosscheck archivelog all; using target database controlfile instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=144 devtype=DISK validation failed for archived log archive log filename=/opt/oracle/flash_recovery_area/EYGLE/ archivelog/2004_05_17/o1_mf_1_790_0bjq36ps_。
arc recid=1 stamp=526401126 validation failed for archived log archive log filename=/opt/oracle/flash_recovery_area/EYGLE/ archivelog/2004_05_17/o1_mf_1_791_0bkbcy7x_。
arc recid=2 stamp=526420862 validation failed for archived log archive log 。