Oracle的ORA-00604错误案例学习
2008-05-12 16:07:29 来源:WEB开发网案例六:连接数据库用户的时候遇到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 来予以纠正。
- ››oracle 中 UPDATE nowait 的使用方法
- ››Oracle ORA-12560解决方法
- ››Oracle 10g RAC 常用维护命令
- ››Oracle如何在ASM中定位文件的分布
- ››Oracle的DBMS_RANDOM.STRING 的用法
- ››oracle 外部表导入时间日期类型数据,多字段导入
- ››Oracle中查找重复记录
- ››oracle修改用户登录密码
- ››Oracle创建删除用户、角色、表空间、导入导出等命...
- ››Oracle中登陆时报ORA-28000: the account is lock...
- ››Oracle数据库在配置文件中更改最大连接数
- ››Oracle中在pl/sql developer修改表的两种方式
更多精彩
赞助商链接