ORA-00604 error occurred at recursive SQL level string
Cause：An error occurred while processing a recursive SQL statement （a statement applying to internal dictionary tables）。
Action：If the situation described in the next error on the stack can be corrected， do so； otherwise contact Oracle Customer Support.
ORA-00604： 递归某个SQL 层时出现错误
原因：在运行一条递归SQL语句（该语句将应用于对内部表或数据字典的操作）时，发生错误。
方案：如果上述描述的错误所在栈可以被修复，则修复并继续运行；否则，请联系Oracle客服。当然，那是Oracle官方的解决办法。
我曾经记得有个高手总结了关于ORA-00604/ORA-04031问题的解决：
修改INIT.ora
添加_db_handles_cached = 0并重新启动数据库。
分析：ORA-00604这个信息表明，在数据库执行内部SQL语句时，发生了错误。比如，要往表中插入一行数据，但没有可扩展的空间。ORACLE于是去查寻，哪儿可以建立下一个扩展空间，它有多大小，但没有成功。一般在发生ORA-00604错误时，还伴随着其它的错误，例如：ORA-1547等。
首先，应当检查警告文件alertSID.log，查找有关ORA-600类的信息。
该错误最常见的原因是数据库文件initSID.ora中的参数OPEN_CURSORS值太小。可以修改initSID.ora文件，OPEN_CURSORS的值一般为255.修改完后，宕下ORACLE，再重新启动。
还可以设置并启动数据库的事件跟踪功能。在initSID.ora中加上一行：
event = "00604 trace name errorstack"
宕下并重新启动ORACLE，使这个事件跟踪参数起作用。这样，当再发生ORA-604错误时，有关信息就保存在TRACE文件中。
造成ORA-00604错误的其它原因可能有：
- initSID.ora中，参数DC_FREE_EXTENTS或ROW_CACHE_ENQUEUES太低。可以根据操作系统和数据库的情况，适当增加这两个参数的值，宕下并重新启动ORACLE.
- 运行超出空间（伴随ORA-1547错误）。这时，要对表空间添加新文件，即增加表空间的大小。
- 达到了MAX_EXTENTS（伴随ORA-1556错误）。如果这样，就要修改表，允许更多的扩展。请从技术手册中查找MAX_EXTENTS的最大值。如果已经达到了最大值，必须用compress extents选项，把表卸出（export），再导入（import）数据库中。
案例一：Oracle执行递归查询的时候出错
问题描述：我经常遇到ORA-00604 和ORA-01000（开启游标数量达到最大值）错误。然而，当我检查代码的时候，所有的结果集和语句对象都在最后的块中关闭了（我使用的是JDBC）。我执行的查询是一个Oracle递归查询（以这个开始并通过这个连接）。您能告诉我是哪里出现了问题，以及在什么样的情况下会出现上述的错误吗？
解决方案：可能是init.ora 文件中的open_cursors 参数值的设置太低了。它应该设置为200或者更高。即使是你关闭了结果集，但是你并没有在JAVA代码中关闭SQL语句，就会导致这个问题。
如果设置为yes的话，那么确保你的活动连接池启用了（为了性能的原因），否则设置为no.
请你的数据库管理员监视数据库，并看看使用V$OPEN_CURSORS 和 V$SYSSTAT数据字典视图的条目。
案例二：Exp出错的一个案例
问题描述：客户用的Linux系统，Redhat 企业版（RHEL 3.0）。数据库，安装的9iR2， 前一段时间升级过。现在的版本是9204.
客户准备要做Exp导出，以前一直系统没有空间。先给给系统扩了一些空间。Linux下的LVM还算比较好用。虽然文件系统用的是ext3 ，要暂时停机。
进行导出操作，不成功，发现系统报告错误：
EXP-00056: ORACLE error 942 encountered
ORA-00942: table or view does not exist
EXP-00000: Export terminated unsuccessfully
很多朋友可能对这个错误都很熟悉。
哦，对了，客户说是升级过数据库，首先猜测是不是升级有问题？毕竟在论坛上类似升级不成功的问题看过很多了。
执行$ORACLE_HOME/rdbms/admin/catpatch.sql 脚本。
同时要注意调大java_pool_size 和shared_pool_size这两个参数的大小，要不重新来就耽误时间了，不要犯低级错误
SQL>shutdown immediate;
SQL>startup migrate;
SQL>@?/rdbms/admin/catpatch.sql
之后查看Spool 出来的日志。 发现有编译错误，重新执行了第二次。 等待……之有这个时候我才想起才抱怨CPU不够快，内存不够大 ；）
这次Log没错误。不料想……用户连接报告错误：
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-04045: errors during recompilation/revalidation of LBACSYS.LBAC_EVENTS
ORA-06508: PL/SQL: could not find program unit being called
ORA-06512: at line 2
ORA-06508: PL/SQL: could not find program unit being called
ORA-06512: at line 2
发现connect / as sysdba 还是可以登陆进去的。
看来是 LBACSYS.LBAC_EVENTS的状态有点问题。联接进去，编译一下如何？ 我的如意算盘是@？/rdbms/admin/utlrp.sql执行一下就没有问题了，不料根本没有用，错误依然。当时有些头晕，这系统还没有备份呢，看来有些麻烦了（心里暗地埋怨客户，一直不让备份，总说"等等再说"，作为一个DBA说话总不被重视也挺悲哀的不是？ ，虽然我自己偷着有个备份，不过还是上次升级时候的呢），赶紧上网Metalink查查，这里网络速度还不错 LBACSYS.LBAC_EVENTS 作为关键词，找到如下的信息：
The reason for this problem seems to be an Upgrade for Label-Security
even if it's not installed. //Label security 没有安装，居然补丁去默认给升级?
解决方案：
shutdown immediate;
startup migrate;
alter view lbacsys.lbac$all_table_policies compile;
alter package lbacsys.lbac_events compile body;
shutdown immediate;
startup;
支持人员说这是个Bug.但是普通用户不可见。 不太放心，再找找，在Suse.com站点的Maillist也发现了一则类似的案例，看来还可以，心里有底了。
按照上面的执行，重新检查，OK.
总结一下
其实是一个很没有技术含量的Case.首先以前升级的时候至少要测试一下Export是否可以（Export已经成为升级成功的一个标志了！） 其次，准备不够充分，造成了手忙脚乱。所幸不是关键系统，用户还可以容忍。Oracle 总说微软是个烂公司，其实他们才真的够栏。Bug多的不可胜数。
案例三：Sql_trace进行Oracle诊断案例
问题说明：很多时候，在我们进行数据库操作时，比如drop user，drop table等，经常会遇到这样的错误
ORA-00604： error occurred at recursive SQL level 1 .
这样的提示，很多时候是没有丝毫用处的。本案例就这一类问题提供一个思路及方法供大家参考。
1. drop user出现问题
报出以下错误后退出
ORA-00604： error occurred at recursive SQL level 1
ORA-00942： table or view does not exist .
关于 recursive SQL 错误我们有必要做个简单说明。
我们知道，当我们发出一条简单的命令以后
Oracle数据库要在后台解析这条命令，并转换为Oracle数据库的一系列后台操作。
这些后台操作统称为递归sql.
比如create table这样一条简单的DDL命令，Oracle数据库在后台，实际上要把这个命令转换为对于obj$，tab$，col$等底层表的插入操作。Oracle所作的工作可能比我们有时候想的要复杂的多。
2.跟踪问题
我们知道Oracle提供sql_trace的功能
可以用于跟踪Oracle数据库的后台递归操作。
通过跟踪文件，我们可以找到问题的所在
以下是格式化（tkprof）后的输出：
The following statement encountered a error during parse:
DELETE FROM SDO_GEOM_METADATA_TABLE WHERE SDO_OWNER = 'WAPCOMM'
Error encountered: ORA-00942
Oracle把错误信息首先呈现出来，我们看到ORA-00942错误是由于
SDO_GEOM_METADATA_TABLE表/视图不存在所致，问题由此可以定位。
对于这一类的错误，定位问题以后解决的方法就要依据具体问题原因而定了。
3.问题定位
对于本案例，通过Metalink获得以下解释：
Problem Description
The Oracle Spatial Option has been installed and you are encountering
the following errors while trying to drop a user, who has no spatial tables,
connected as SYSTEM:
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00942: table or view does not exist
ORA-06512: at line 7
A 942 error trace shows the failing SQL statement as:
DELETE FROM SDO_GEOM_METADATA_TABLE WHERE SDO_OWNER = ''
Solution Description
(1)
Create a synonym for SDO_GEOM_METADATA_TABLE under SYSTEM which points to
MDSYS.SDO_GEOM_METADATA_TABLE.
对于本例，为MDSYS.SDO_GEOM_METADATA_TABLE创建一个同义词即可解决，是相对简单的情况。
(2)
Now the user can be dropped connected as SYSTEM.
Related Documents
ORA-604 and ORA-942 Reported During DROP USER CASCA
4.实际处理
MDSYS.SDO_GEOM_METADATA_TABLE为Spatial对象，如果未使用Spatial选项，可以删除
SQL> connect / as sysdbaConnected.
SQL> select * from dba_sdo_geom_metadata order by owner;
select * from dba_sdo_geom_metadata order by owner
*
ERROR at line 1:
ORA-00942: table or view does not exist
ORA-04063: view "MDSYS.DBA_SDO_GEOM_METADATA" has errors
SQL> select object_name from dba_objects where object_name like '%SDO%';
OBJECT_NAME
ALL_SDO_GEOM_METADATA
ALL_SDO_INDEX_INFO
ALL_SDO_INDEX_METADATA
DBA_SDO_GEOM_METADATA
DBA_SDO_INDEX_INFO
DBA_SDO_INDEX_METADATA
....
DBA_SDO_GEOM_METADATA
DBA_SDO_INDEX_INFO
...
SDO_WITHIN_DISTANCE
USER_SDO_GEOM_METADATA
USER_SDO_INDEX_INFO
USER_SDO_INDEX_METADATA
88 rows selected.
SQL> drop user MDSYS cascade;
User dropped.
SQL> select owner,type_name from dba_types where type_name like 'SDO%';
no rows selected
SQL>
SQL> alter session set sql_trace=true;
Session altered.
SQL> drop user wapcomm;
User dropped.
SQL> alter session set sql_trace=false;
Session altered.
SQL> exit
Disconnected from Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production
With the Partitioning option
JServer Release 8.1.7.4.0 - 64bit Production
这时用户得以顺利drop
5.一点总结
使用sql_trace可以跟踪数据库的很多后台操作有利于我们发现问题的所在，很多时候，我们想要研究Oracle的内部活动或后台操作，也可以通过sql_trace跟踪，sql_trace/10046 是Oracle提供的最为有效的诊断工具之一。
案例四：表更新时发生递归SQL2级失败错误
问题描述：表更新的时候失败了，并且生成了一条ORA-00604 错误信息。这个错误发生在递归SQL 2级。
解决方案：不幸的是，这个错误并不能告诉你Oracle数据库在错误发生的时候正要做什么。当你执行一条SQL语句的时候，Oracle数据库会为你在幕后做很多事情。例如，考虑下面的SQL语句：
UPDATE emp SET sal = sal*1.05 WHERE empno=1001;
这条SQL语句给号码为1001的雇员涨5%的工资。当你执行这条语句的时候，Oracle查询数据目录来确定是否有这个表或者你是否使用了同义字。一旦它找到了数据库对象，Oracle查询数据字典来判断你是否拥有访问这个对象的权限。那么，Oracle到底是如何与数据字典进行交互的呢？它执行一条自己的SQL 语句。这些Oracle为你执行的SQL语句被称为“递归”SQL语句。你最初的SQL 语句是0级。Oracle为你执行的递归SQL语句是1级。有时候，一条递归SQL语句又会引起自己的递归SQL语句，就是2级。
在你的案例中，有一个2级的递归SQL语句正在执行，并且产生了问题。为了解决问题，你需要找出执行的是什么递归SQL语句引起的错误。要做到这一点，你必须启动会话中的追踪。
首先，执行下面的SQL 语句：
ALTER SESSION SET sql_trace=TRUE;
然后，执行你的更新语句。你会看到ORA-604 错误。接下来，执行下面的语句：
ALTER SESSION SET sql_trace=FALSE;
现在到你为数据库定义的USER_DUMP_DEST 起始参数上的路径去。那里应该有一个时间戳为当前时间的文件。那个就是你生成的追踪文件。你可以打开文件并检查递归SQL语句，其中包括引起错误的一条。
案例五：连接数据库用户的时候遇到ORA-00604错误
问题描述：当我试图连接到数据库用户的时候，得到了如下的错误信息：ORA-00604：递归SQL 1级的时候出现错误。但是如果我使用数据库管理员的角色的时候，用户就能够连接。系统用户可以连接，但是scott 就不能连接。
解决方案：Oracle为你在幕后做了很多的工作。它在自己的SQL 语句的全过程中进行这项工作。Oracle发布给你的任何的SQL 语句都是“递归的SQL”语句。应该有很多的SQL 语句会引起你遇到的问题。我建议你所做的就是在INIT.ORA文件中设置SQL_TRACE=TRUE，然后重新启动数据库。然后复制ORA-604错误。这会在你的USER_DUMP_DEST目录中生成所有用户进程的大量追踪文件。在错误发生之后，立即关闭数据库，并设置SQL_TRACE=FALSE.然后再一次启动数据库。现在通过追踪文件，你就可以USER_DUMP_DEST目录中生成的追踪文件中查找ORA-604错误那一条信息。就在那里，你就发现ORA-604错误是哪一个递归SQL语句产生的，以及实际发生的错误情况。你的解决方案依赖于语句和实际的错误。
案例六：有人Move了系统表Dependencie$表， Crash了
今天有人问我这样之后能不能恢复， 我想基本上已经不能了。 在open时报ORA-01092号错误， 我查了一下event也没有这方面的合适的event啊， 我推荐用不完全恢复， 不过好象是没有备份， 运行在noarchivelog模式。
从trc文件中得到的内容：
KCRA: buffers claimed = 0/0, eliminated = 0
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01502: index 'SYS.I_DEPENDENCY1' or partition of such index is in unusable state
oerr ora 704
00704, 00000, "bootstrap process failure"
// *Cause: Failure in processing bootstrap data - see accompanying error.
// *Action: Contact your customer support representative.
SQL_TRACE打开的情况下生成的Trace:
PARSING IN CURSOR #9 len=84 dep=2 uid=0 oct=3 lid=0 tim=18446744073254091198
hv=2287793623 ad='66f6c06c'
select o.name, u.name from obj$ o, user$ u where o.obj# = :1 and o.owner# = u.user#
END OF STMT
PARSE #9:c=0,e=343,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=0,tim=18446744073254091193
EXEC #9:c=0,e=186,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=18446744073254091456
FETCH #9:c=0,e=28019,p=2,cr=5,cu=0,mis=0,r=1,dep=2,og=4,tim=18446744073254119501
STAT #9 id=1 cnt=1 pid=0 pos=1 obj=0 op='NESTED LOOPS '
STAT #9 id=2 cnt=1 pid=1 pos=1 obj=18 op='TABLE ACCESS BY INDEX ROWID OBJ#(18) '
STAT #9 id=3 cnt=1 pid=2 pos=1 obj=36 op='INDEX UNIQUE SCAN OBJ#(36) '
STAT #9 id=4 cnt=1 pid=1 pos=2 obj=22 op='TABLE ACCESS CLUSTER OBJ#(22) '
STAT #9 id=5 cnt=1 pid=4 pos=1 obj=11 op='INDEX UNIQUE SCAN OBJ#(11) '
ORA-00704: 引导程序进程失败
ORA-00604: 递归 SQL 层 1 出现错误
ORA-01502: 索引'SYS.I_DEPENDENCY1'或这类索引的分区处于不可用状态
EXEC #1:c=109375,e=5578667,p=44,cr=616,cu=1,mis=0,r=0,dep=0,og=4,
tim=18446744073255895570
ERROR #1:err=1092 tim=23012387
DBA做事一定要细心， 在运行批处理时一定要审了再审。
补充：
后来我用AnySQL UnLoader去恢复数据了， 和客户一起花了24小时， 最后他们说OK了。
Eygle和Chensq对这个问题也有研究， 他们想出了更好的办法解决此事， 不过最后原来的库肯定是不能再用了， 必须要exp/imp到别的库了， 我是用AUL帮客户恢复数据的， 数据量在30G以上。
案例七：ORA-00604：递归SQL产生的错误
问题描述：我有一个Pro*c 的程序，有时候会给出下列的错误信息：
ORA-00604：递归SQL 1级上产生错误
你能告诉为什么会出现这个错误，它什么时候出现，以及可能的解决方案是什么吗？
解决方案：无论你什么时候执行查询，系统都会在后台执行一些查询来判断许多事情，例如“你是否有权限来执行这个查询？”，“你要访问的这个对象是否存在？”。这些系统执行的查询被称为“递归SQL”。有时候，一个递归SQL语句需要调用自身的递归SQL.那么这些执行的递归SQL语句就是另一个级别的，2级。
你不会在SQL*Plus 中看到递归SQL语句。要查看它们的最好的方式就是开启会话中的追踪。启动SQL*Plus ，执行下列命令：
ALTER SESSION SET sql_trace=TRUE;
然后运行你的进程，直到崩溃。继续，并关闭SQL*Plus .现在到USER_DUMP_DEST 目录中。那里会生成一个追踪文件给你。查看追踪文件中的有关ORA错误的信息。这就是问题产生的根源。纠正ORA错误就会防止ORA-600错误再次出现。
大多数的ORA-600错误都可以通过以SYS登录，并从ORACLE_HOME/rdbms/admin 运行CATALOG 和 CATPROC 来予以纠正
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/tianlesoftw ... /11/09/4787074.aspx
Cause：An error occurred while processing a recursive SQL statement （a statement applying to internal dictionary tables）。
Action：If the situation described in the next error on the stack can be corrected， do so； otherwise contact Oracle Customer Support.
ORA-00604： 递归某个SQL 层时出现错误
原因：在运行一条递归SQL语句（该语句将应用于对内部表或数据字典的操作）时，发生错误。
方案：如果上述描述的错误所在栈可以被修复，则修复并继续运行；否则，请联系Oracle客服。当然，那是Oracle官方的解决办法。
我曾经记得有个高手总结了关于ORA-00604/ORA-04031问题的解决：
修改INIT.ora
添加_db_handles_cached = 0并重新启动数据库。
分析：ORA-00604这个信息表明，在数据库执行内部SQL语句时，发生了错误。比如，要往表中插入一行数据，但没有可扩展的空间。ORACLE于是去查寻，哪儿可以建立下一个扩展空间，它有多大小，但没有成功。一般在发生ORA-00604错误时，还伴随着其它的错误，例如：ORA-1547等。
首先，应当检查警告文件alertSID.log，查找有关ORA-600类的信息。
该错误最常见的原因是数据库文件initSID.ora中的参数OPEN_CURSORS值太小。可以修改initSID.ora文件，OPEN_CURSORS的值一般为255.修改完后，宕下ORACLE，再重新启动。
还可以设置并启动数据库的事件跟踪功能。在initSID.ora中加上一行：
event = "00604 trace name errorstack"
宕下并重新启动ORACLE，使这个事件跟踪参数起作用。这样，当再发生ORA-604错误时，有关信息就保存在TRACE文件中。
造成ORA-00604错误的其它原因可能有：
- initSID.ora中，参数DC_FREE_EXTENTS或ROW_CACHE_ENQUEUES太低。可以根据操作系统和数据库的情况，适当增加这两个参数的值，宕下并重新启动ORACLE.
- 运行超出空间（伴随ORA-1547错误）。这时，要对表空间添加新文件，即增加表空间的大小。
- 达到了MAX_EXTENTS（伴随ORA-1556错误）。如果这样，就要修改表，允许更多的扩展。请从技术手册中查找MAX_EXTENTS的最大值。如果已经达到了最大值，必须用compress extents选项，把表卸出（export），再导入（import）数据库中。
案例一：Oracle执行递归查询的时候出错
问题描述：我经常遇到ORA-00604 和ORA-01000（开启游标数量达到最大值）错误。然而，当我检查代码的时候，所有的结果集和语句对象都在最后的块中关闭了（我使用的是JDBC）。我执行的查询是一个Oracle递归查询（以这个开始并通过这个连接）。您能告诉我是哪里出现了问题，以及在什么样的情况下会出现上述的错误吗？
解决方案：可能是init.ora 文件中的open_cursors 参数值的设置太低了。它应该设置为200或者更高。即使是你关闭了结果集，但是你并没有在JAVA代码中关闭SQL语句，就会导致这个问题。
如果设置为yes的话，那么确保你的活动连接池启用了（为了性能的原因），否则设置为no.
请你的数据库管理员监视数据库，并看看使用V$OPEN_CURSORS 和 V$SYSSTAT数据字典视图的条目。
案例二：Exp出错的一个案例
问题描述：客户用的Linux系统，Redhat 企业版（RHEL 3.0）。数据库，安装的9iR2， 前一段时间升级过。现在的版本是9204.
客户准备要做Exp导出，以前一直系统没有空间。先给给系统扩了一些空间。Linux下的LVM还算比较好用。虽然文件系统用的是ext3 ，要暂时停机。
进行导出操作，不成功，发现系统报告错误：
EXP-00056: ORACLE error 942 encountered
ORA-00942: table or view does not exist
EXP-00000: Export terminated unsuccessfully
很多朋友可能对这个错误都很熟悉。
哦，对了，客户说是升级过数据库，首先猜测是不是升级有问题？毕竟在论坛上类似升级不成功的问题看过很多了。
执行$ORACLE_HOME/rdbms/admin/catpatch.sql 脚本。
同时要注意调大java_pool_size 和shared_pool_size这两个参数的大小，要不重新来就耽误时间了，不要犯低级错误
SQL>shutdown immediate;
SQL>startup migrate;
SQL>@?/rdbms/admin/catpatch.sql
之后查看Spool 出来的日志。 发现有编译错误，重新执行了第二次。 等待……之有这个时候我才想起才抱怨CPU不够快，内存不够大 ；）
这次Log没错误。不料想……用户连接报告错误：
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-04045: errors during recompilation/revalidation of LBACSYS.LBAC_EVENTS
ORA-06508: PL/SQL: could not find program unit being called
ORA-06512: at line 2
ORA-06508: PL/SQL: could not find program unit being called
ORA-06512: at line 2
发现connect / as sysdba 还是可以登陆进去的。
看来是 LBACSYS.LBAC_EVENTS的状态有点问题。联接进去，编译一下如何？ 我的如意算盘是@？/rdbms/admin/utlrp.sql执行一下就没有问题了，不料根本没有用，错误依然。当时有些头晕，这系统还没有备份呢，看来有些麻烦了（心里暗地埋怨客户，一直不让备份，总说"等等再说"，作为一个DBA说话总不被重视也挺悲哀的不是？ ，虽然我自己偷着有个备份，不过还是上次升级时候的呢），赶紧上网Metalink查查，这里网络速度还不错 LBACSYS.LBAC_EVENTS 作为关键词，找到如下的信息：
The reason for this problem seems to be an Upgrade for Label-Security
even if it's not installed. //Label security 没有安装，居然补丁去默认给升级?
解决方案：
shutdown immediate;
startup migrate;
alter view lbacsys.lbac$all_table_policies compile;
alter package lbacsys.lbac_events compile body;
shutdown immediate;
startup;
支持人员说这是个Bug.但是普通用户不可见。 不太放心，再找找，在Suse.com站点的Maillist也发现了一则类似的案例，看来还可以，心里有底了。
按照上面的执行，重新检查，OK.
总结一下
其实是一个很没有技术含量的Case.首先以前升级的时候至少要测试一下Export是否可以（Export已经成为升级成功的一个标志了！） 其次，准备不够充分，造成了手忙脚乱。所幸不是关键系统，用户还可以容忍。Oracle 总说微软是个烂公司，其实他们才真的够栏。Bug多的不可胜数。
案例三：Sql_trace进行Oracle诊断案例
问题说明：很多时候，在我们进行数据库操作时，比如drop user，drop table等，经常会遇到这样的错误
ORA-00604： error occurred at recursive SQL level 1 .
这样的提示，很多时候是没有丝毫用处的。本案例就这一类问题提供一个思路及方法供大家参考。
1. drop user出现问题
报出以下错误后退出
ORA-00604： error occurred at recursive SQL level 1
ORA-00942： table or view does not exist .
关于 recursive SQL 错误我们有必要做个简单说明。
我们知道，当我们发出一条简单的命令以后
Oracle数据库要在后台解析这条命令，并转换为Oracle数据库的一系列后台操作。
这些后台操作统称为递归sql.
比如create table这样一条简单的DDL命令，Oracle数据库在后台，实际上要把这个命令转换为对于obj$，tab$，col$等底层表的插入操作。Oracle所作的工作可能比我们有时候想的要复杂的多。
2.跟踪问题
我们知道Oracle提供sql_trace的功能
可以用于跟踪Oracle数据库的后台递归操作。
通过跟踪文件，我们可以找到问题的所在
以下是格式化（tkprof）后的输出：
The following statement encountered a error during parse:
DELETE FROM SDO_GEOM_METADATA_TABLE WHERE SDO_OWNER = 'WAPCOMM'
Error encountered: ORA-00942
Oracle把错误信息首先呈现出来，我们看到ORA-00942错误是由于
SDO_GEOM_METADATA_TABLE表/视图不存在所致，问题由此可以定位。
对于这一类的错误，定位问题以后解决的方法就要依据具体问题原因而定了。
3.问题定位
对于本案例，通过Metalink获得以下解释：
Problem Description
The Oracle Spatial Option has been installed and you are encountering
the following errors while trying to drop a user, who has no spatial tables,
connected as SYSTEM:
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00942: table or view does not exist
ORA-06512: at line 7
A 942 error trace shows the failing SQL statement as:
DELETE FROM SDO_GEOM_METADATA_TABLE WHERE SDO_OWNER = ''
Solution Description
(1)
Create a synonym for SDO_GEOM_METADATA_TABLE under SYSTEM which points to
MDSYS.SDO_GEOM_METADATA_TABLE.
对于本例，为MDSYS.SDO_GEOM_METADATA_TABLE创建一个同义词即可解决，是相对简单的情况。
(2)
Now the user can be dropped connected as SYSTEM.
Related Documents
ORA-604 and ORA-942 Reported During DROP USER CASCA
4.实际处理
MDSYS.SDO_GEOM_METADATA_TABLE为Spatial对象，如果未使用Spatial选项，可以删除
SQL> connect / as sysdbaConnected.
SQL> select * from dba_sdo_geom_metadata order by owner;
select * from dba_sdo_geom_metadata order by owner
*
ERROR at line 1:
ORA-00942: table or view does not exist
ORA-04063: view "MDSYS.DBA_SDO_GEOM_METADATA" has errors
SQL> select object_name from dba_objects where object_name like '%SDO%';
OBJECT_NAME
ALL_SDO_GEOM_METADATA
ALL_SDO_INDEX_INFO
ALL_SDO_INDEX_METADATA
DBA_SDO_GEOM_METADATA
DBA_SDO_INDEX_INFO
DBA_SDO_INDEX_METADATA
....
DBA_SDO_GEOM_METADATA
DBA_SDO_INDEX_INFO
...
SDO_WITHIN_DISTANCE
USER_SDO_GEOM_METADATA
USER_SDO_INDEX_INFO
USER_SDO_INDEX_METADATA
88 rows selected.
SQL> drop user MDSYS cascade;
User dropped.
SQL> select owner,type_name from dba_types where type_name like 'SDO%';
no rows selected
SQL>
SQL> alter session set sql_trace=true;
Session altered.
SQL> drop user wapcomm;
User dropped.
SQL> alter session set sql_trace=false;
Session altered.
SQL> exit
Disconnected from Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production
With the Partitioning option
JServer Release 8.1.7.4.0 - 64bit Production
这时用户得以顺利drop
5.一点总结
使用sql_trace可以跟踪数据库的很多后台操作有利于我们发现问题的所在，很多时候，我们想要研究Oracle的内部活动或后台操作，也可以通过sql_trace跟踪，sql_trace/10046 是Oracle提供的最为有效的诊断工具之一。
案例四：表更新时发生递归SQL2级失败错误
问题描述：表更新的时候失败了，并且生成了一条ORA-00604 错误信息。这个错误发生在递归SQL 2级。
解决方案：不幸的是，这个错误并不能告诉你Oracle数据库在错误发生的时候正要做什么。当你执行一条SQL语句的时候，Oracle数据库会为你在幕后做很多事情。例如，考虑下面的SQL语句：
UPDATE emp SET sal = sal*1.05 WHERE empno=1001;
这条SQL语句给号码为1001的雇员涨5%的工资。当你执行这条语句的时候，Oracle查询数据目录来确定是否有这个表或者你是否使用了同义字。一旦它找到了数据库对象，Oracle查询数据字典来判断你是否拥有访问这个对象的权限。那么，Oracle到底是如何与数据字典进行交互的呢？它执行一条自己的SQL 语句。这些Oracle为你执行的SQL语句被称为“递归”SQL语句。你最初的SQL 语句是0级。Oracle为你执行的递归SQL语句是1级。有时候，一条递归SQL语句又会引起自己的递归SQL语句，就是2级。
在你的案例中，有一个2级的递归SQL语句正在执行，并且产生了问题。为了解决问题，你需要找出执行的是什么递归SQL语句引起的错误。要做到这一点，你必须启动会话中的追踪。
首先，执行下面的SQL 语句：
ALTER SESSION SET sql_trace=TRUE;
然后，执行你的更新语句。你会看到ORA-604 错误。接下来，执行下面的语句：
ALTER SESSION SET sql_trace=FALSE;
现在到你为数据库定义的USER_DUMP_DEST 起始参数上的路径去。那里应该有一个时间戳为当前时间的文件。那个就是你生成的追踪文件。你可以打开文件并检查递归SQL语句，其中包括引起错误的一条。
案例五：连接数据库用户的时候遇到ORA-00604错误
问题描述：当我试图连接到数据库用户的时候，得到了如下的错误信息：ORA-00604：递归SQL 1级的时候出现错误。但是如果我使用数据库管理员的角色的时候，用户就能够连接。系统用户可以连接，但是scott 就不能连接。
解决方案：Oracle为你在幕后做了很多的工作。它在自己的SQL 语句的全过程中进行这项工作。Oracle发布给你的任何的SQL 语句都是“递归的SQL”语句。应该有很多的SQL 语句会引起你遇到的问题。我建议你所做的就是在INIT.ORA文件中设置SQL_TRACE=TRUE，然后重新启动数据库。然后复制ORA-604错误。这会在你的USER_DUMP_DEST目录中生成所有用户进程的大量追踪文件。在错误发生之后，立即关闭数据库，并设置SQL_TRACE=FALSE.然后再一次启动数据库。现在通过追踪文件，你就可以USER_DUMP_DEST目录中生成的追踪文件中查找ORA-604错误那一条信息。就在那里，你就发现ORA-604错误是哪一个递归SQL语句产生的，以及实际发生的错误情况。你的解决方案依赖于语句和实际的错误。
案例六：有人Move了系统表Dependencie$表， Crash了
今天有人问我这样之后能不能恢复， 我想基本上已经不能了。 在open时报ORA-01092号错误， 我查了一下event也没有这方面的合适的event啊， 我推荐用不完全恢复， 不过好象是没有备份， 运行在noarchivelog模式。
从trc文件中得到的内容：
KCRA: buffers claimed = 0/0, eliminated = 0
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01502: index 'SYS.I_DEPENDENCY1' or partition of such index is in unusable state
oerr ora 704
00704, 00000, "bootstrap process failure"
// *Cause: Failure in processing bootstrap data - see accompanying error.
// *Action: Contact your customer support representative.
SQL_TRACE打开的情况下生成的Trace:
PARSING IN CURSOR #9 len=84 dep=2 uid=0 oct=3 lid=0 tim=18446744073254091198
hv=2287793623 ad='66f6c06c'
select o.name, u.name from obj$ o, user$ u where o.obj# = :1 and o.owner# = u.user#
END OF STMT
PARSE #9:c=0,e=343,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=0,tim=18446744073254091193
EXEC #9:c=0,e=186,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=18446744073254091456
FETCH #9:c=0,e=28019,p=2,cr=5,cu=0,mis=0,r=1,dep=2,og=4,tim=18446744073254119501
STAT #9 id=1 cnt=1 pid=0 pos=1 obj=0 op='NESTED LOOPS '
STAT #9 id=2 cnt=1 pid=1 pos=1 obj=18 op='TABLE ACCESS BY INDEX ROWID OBJ#(18) '
STAT #9 id=3 cnt=1 pid=2 pos=1 obj=36 op='INDEX UNIQUE SCAN OBJ#(36) '
STAT #9 id=4 cnt=1 pid=1 pos=2 obj=22 op='TABLE ACCESS CLUSTER OBJ#(22) '
STAT #9 id=5 cnt=1 pid=4 pos=1 obj=11 op='INDEX UNIQUE SCAN OBJ#(11) '
ORA-00704: 引导程序进程失败
ORA-00604: 递归 SQL 层 1 出现错误
ORA-01502: 索引'SYS.I_DEPENDENCY1'或这类索引的分区处于不可用状态
EXEC #1:c=109375,e=5578667,p=44,cr=616,cu=1,mis=0,r=0,dep=0,og=4,
tim=18446744073255895570
ERROR #1:err=1092 tim=23012387
DBA做事一定要细心， 在运行批处理时一定要审了再审。
补充：
后来我用AnySQL UnLoader去恢复数据了， 和客户一起花了24小时， 最后他们说OK了。
Eygle和Chensq对这个问题也有研究， 他们想出了更好的办法解决此事， 不过最后原来的库肯定是不能再用了， 必须要exp/imp到别的库了， 我是用AUL帮客户恢复数据的， 数据量在30G以上。
案例七：ORA-00604：递归SQL产生的错误
问题描述：我有一个Pro*c 的程序，有时候会给出下列的错误信息：
ORA-00604：递归SQL 1级上产生错误
你能告诉为什么会出现这个错误，它什么时候出现，以及可能的解决方案是什么吗？
解决方案：无论你什么时候执行查询，系统都会在后台执行一些查询来判断许多事情，例如“你是否有权限来执行这个查询？”，“你要访问的这个对象是否存在？”。这些系统执行的查询被称为“递归SQL”。有时候，一个递归SQL语句需要调用自身的递归SQL.那么这些执行的递归SQL语句就是另一个级别的，2级。
你不会在SQL*Plus 中看到递归SQL语句。要查看它们的最好的方式就是开启会话中的追踪。启动SQL*Plus ，执行下列命令：
ALTER SESSION SET sql_trace=TRUE;
然后运行你的进程，直到崩溃。继续，并关闭SQL*Plus .现在到USER_DUMP_DEST 目录中。那里会生成一个追踪文件给你。查看追踪文件中的有关ORA错误的信息。这就是问题产生的根源。纠正ORA错误就会防止ORA-600错误再次出现。
大多数的ORA-600错误都可以通过以SYS登录，并从ORACLE_HOME/rdbms/admin 运行CATALOG 和 CATPROC 来予以纠正
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/tianlesoftw ... /11/09/4787074.aspx
编辑回复