前天用戶突然反映一個軟件總是報ora-00603錯誤。一開始一位就是個普通的表空間不足之類的，可是一看日志卻發(fā)現(xiàn)不是那么簡單。

截取部分日志如下：

Thu Nov 05 15:28:53 2009
Errors in file d:\oracle\admin\orcl\udump\orcl_ora_4684.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-01114: IO error writing block to file 11 (block # 42773)
ORA-27041: unable to open file
OSD-04002: 無法打開文件
O/S-Error: (OS 32) 另一個程序正在使用此文件，進程無法訪問。
ORA-01114: IO error writing block to file 11 (block # 42773)
ORA-27041: unable to open file
OSD-04002: 無法打開文件
O/S-Error: (OS 32) 另一個程序正在使用此文件，進程無法訪問。
ORA-01114: IO error writing block to file 11 (block # 42773)
ORA-27041: unable to open file
OSD-04002: 無法打開文件
O/S-Error: (OS 32) 另一個程序正在使用此文件，進程無法訪問。

里面的File 11就是我的那個程序使用的表空間的一個數(shù)據文件。表空間總共有四個數(shù)據文件加起來8G左右，總體使用率在70%左右。數(shù)據文件號分別為9，11，13，14。出問題的文件號不一定，時間也是隨機的，有可能一分鐘就會重復上面那段日志，有可能幾秒就重復一次。

下面是orcl_ora_4684.trc文件的片段：

JServer Release 9.2.0.1.0 - Production
Windows 2000 Version 5.2 Service Pack 2, CPU type 586
Instance name: orcl

Redo thread mounted by this instance: 1

Oracle process number: 30

Windows thread id: 4684, image: ORACLE.EXE

*** SESSION ID:(39.280) 2009-11-05 15:28:52.000
*** 2009-11-05 15:28:52.000
ksedmp: internal or fatal error
ORA-01114: 將塊寫入文件 11 時出現(xiàn) IO 錯誤 (塊 # 42773)
ORA-27041: 無法打開文件
OSD-04002: 無法打開文件
O/S-Error: (OS 32) 另一個程序正在使用此文件，進程無法訪問。
ORA-01114: 將塊寫入文件 11 時出現(xiàn) IO 錯誤 (塊 # 42773)
ORA-27041: 無法打開文件
OSD-04002: 無法打開文件
O/S-Error: (OS 32) 另一個程序正在使用此文件，進程無法訪問。
ORA-01114: 將塊寫入文件 11 時出現(xiàn) IO 錯誤 (塊 # 42773)
ORA-27041: 無法打開文件
OSD-04002: 無法打開文件
O/S-Error: (OS 32) 另一個程序正在使用此文件，進程無法訪問。
Current SQL statement for this session:
INSERT INTO "VIO_JDCZP" ("XH","HPHM","HPZL","PHOTO1") VALUES (:1,:2,:3,:4) RETURNING ROWID into :5
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
_ksedmp+147          CALLrel  _ksedst+0            
..1.44_7.except.114  CALLrel  _ksedmp+0            3
+fc                                                
..1.1_3.except.34+a  CALLrel  _ksupop+0            2
f                                                  
_ttcpip+a86          CALLreg  00000000             5E 14 8ACE738 0
_opitsk+2f4          CALLrel  _ttcpip+0            
_opiino+5fc          CALLrel  _opitsk+0            0 0 A616320 6D1F564 C2 0
_opiodr+4cd          CALLreg  00000000             3C 4 8ACFBD8
_opidrv+233          CALLrel  _opiodr+0            3C 4 8ACFBD8 0
_sou2o+19            CALLrel  _opidrv+0            
_opimai+10a          CALLrel  _sou2o+0             
_OracleThreadStart@  CALLrel  _opimai+0            
4+35c                                              
7C824826             CALLreg  00000000             
 從這個日志中看，“Current SQL statement for this session:
INSERT INTO "VIO_JDCZP" ("XH","HPHM","HPZL","PHOTO1") VALUES (:1,:2,:3,:4) RETURNING ROWID into :5”這句話說明了是在執(zhí)行“INSERT INTO "VIO_JDCZP" ("XH","HPHM","HPZL","PHOTO1") VALUES (:1,:2,:3,:4) RETURNING ROWID into :5”這句話時出的問題，而且說有的錯誤都是這樣。這句話是將一個圖片寫入數(shù)據庫。

軟件是CS結構的，總共有八個客戶端。八個客戶端每3秒錄入一條數(shù)據，數(shù)據包括一些文本類的信息還有就是有一張圖片，圖片大小在80KB至200KB不等。圖片是直接存入數(shù)據庫中的。

現(xiàn)在是單個用戶錄入時不會出現(xiàn)問題，八個用戶一起錄入時很快就會出現(xiàn)這個問題。查了oracle的參數(shù)，沒有用戶數(shù)方面的限制和Session的限制。

現(xiàn)在就是覺得奇怪了，ORACLE是大型數(shù)據庫，不可能會出現(xiàn)這種類似于并發(fā)訪問的問題的。從日志簡單的分析上來看是一個用戶數(shù)據寫入未完成時另一個用戶寫入數(shù)據造成數(shù)據文件被占用造成的。程序里試驗過，使用事務和不使用事務結果是一樣的，基本上可以排除事務將文件給鎖住的原因。

兩個解決方法：
1 將數(shù)據庫升級到9.2.0.1以上，不是一定得用10G之類的，升級成9.2.0.3或更高的，當然越高越好。
2 圖片不寫入數(shù)據庫，存成文件之類的。

老外的解決問題的方法：

The solution is (as proposed on this thread):
alter system set events '10046 trace name context off';
alter system set timed_statistics=false;
執(zhí)行完這兩條腳本，問題果然解決。
注：
timed_staticstices 用于啟動或禁止對定時統(tǒng)計信息（如CUP時間、占用時間），以及動態(tài)性能表中多種統(tǒng)計信息的收集功能。

ORA-00603錯誤解決過程

今天在查看job運行情況時，發(fā)現(xiàn)一同步數(shù)據的job執(zhí)行了很長時間，但也沒有出現(xiàn)異常記錄。手動執(zhí)行之后出現(xiàn)ORA-00603錯誤，解決過程如下：

1.插入操作報ORA-00603錯誤，上網搜索說是temp空間不夠，但實際用戶所用的臨時表空間不是系統(tǒng)的temp空間，而自定