案例學習Oracle錯誤：ORA-00604

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-604錯誤的其它原因可能有:

- 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 參數值的設置太低了。這個參數的默認值是非常低的(50)。它應該設置為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錯誤

問題描述:當我使用網絡應用程序的時候，遇到了下面的這個錯誤。

ORA-00604: 遞歸SQL1級的時候出現錯誤。

ORA-04031: 無法分配4200字節的共享內存，"RBKS_BK_INFO", "sga_heap", "library cache"。

這些錯誤信息是什麼意思?我該如何解決它們?它們是在應用程序裡面還是數據庫裡面?

解決方案:您應該使用的是Oracle 8.1.7.4之前版本的Oracle。第一個錯誤信息告訴你Oracle針對你的行為執行的SQL 語句失敗了。ORA-4031告訴你為什麼它會失敗。ORA-4031錯誤信息的意思是你沒有獲得足夠的空閒空間。你可以增加你的SHARED_POOL_SIZE，重新啟動數據庫再拭一次。這個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

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

Create a synonym for SDO_GEOM_METADATA_TABLE under SYSTEM which points to 
MDSYS.SDO_GEOM_METADATA_TABLE.

Now the user can be dropped connected as SYSTEM.
Related Documents
ORA-604 and ORA-942 Reported During DROP USER CASCA

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

UPDATE emp SET sal = sal*1.05 WHERE empno=1001;

　　ALTER SESSION SET sql_trace=TRUE;

　　ALTER SESSION SET sql_trace=FALSE;

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

ALTER SESSION SET sql_trace=TRUE;