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
IXDBA.NET社区论坛
ORA-00604: error occurred at recursive SQL level 1