Oracle報(bào)ora-00603錯(cuò)誤不能處理大數(shù)據(jù)并發(fā)的問(wèn)題解決方案
前天用戶突然反映一個(gè)軟件總是報(bào)ora-00603錯(cuò)誤。一開(kāi)始一位就是個(gè)普通的表空間不足之類的,可是一看日志卻發(fā)現(xiàn)不是那么簡(jiǎ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: 無(wú)法打開(kāi)文件
O/S-Error: (OS 32) 另一個(gè)程序正在使用此文件,進(jìn)程無(wú)法訪問(wèn)。
ORA-01114: IO error writing block to file 11 (block # 42773)
ORA-27041: unable to open file
OSD-04002: 無(wú)法打開(kāi)文件
O/S-Error: (OS 32) 另一個(gè)程序正在使用此文件,進(jìn)程無(wú)法訪問(wèn)。
ORA-01114: IO error writing block to file 11 (block # 42773)
ORA-27041: unable to open file
OSD-04002: 無(wú)法打開(kāi)文件
O/S-Error: (OS 32) 另一個(gè)程序正在使用此文件,進(jìn)程無(wú)法訪問(wèn)。
里面的File 11就是我的那個(gè)程序使用的表空間的一個(gè)數(shù)據(jù)文件。表空間總共有四個(gè)數(shù)據(jù)文件加起來(lái)8G左右,總體使用率在70%左右。數(shù)據(jù)文件號(hào)分別為9,11,13,14。出問(wèn)題的文件號(hào)不一定,時(shí)間也是隨機(jī)的,有可能一分鐘就會(huì)重復(fù)上面那段日志,有可能幾秒就重復(fù)一次。
下面是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: 將塊寫(xiě)入文件 11 時(shí)出現(xiàn) IO 錯(cuò)誤 (塊 # 42773)
ORA-27041: 無(wú)法打開(kāi)文件
OSD-04002: 無(wú)法打開(kāi)文件
O/S-Error: (OS 32) 另一個(gè)程序正在使用此文件,進(jìn)程無(wú)法訪問(wèn)。
ORA-01114: 將塊寫(xiě)入文件 11 時(shí)出現(xiàn) IO 錯(cuò)誤 (塊 # 42773)
ORA-27041: 無(wú)法打開(kāi)文件
OSD-04002: 無(wú)法打開(kāi)文件
O/S-Error: (OS 32) 另一個(gè)程序正在使用此文件,進(jìn)程無(wú)法訪問(wèn)。
ORA-01114: 將塊寫(xiě)入文件 11 時(shí)出現(xiàn) IO 錯(cuò)誤 (塊 # 42773)
ORA-27041: 無(wú)法打開(kāi)文件
OSD-04002: 無(wú)法打開(kāi)文件
O/S-Error: (OS 32) 另一個(gè)程序正在使用此文件,進(jìn)程無(wú)法訪問(wèn)。
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
從這個(gè)日志中看,“Current SQL statement for this session:
INSERT INTO "VIO_JDCZP" ("XH","HPHM","HPZL","PHOTO1") VALUES (:1,:2,:3,:4) RETURNING ROWID into :5”這句話說(shuō)明了是在執(zhí)行“INSERT INTO "VIO_JDCZP" ("XH","HPHM","HPZL","PHOTO1") VALUES (:1,:2,:3,:4) RETURNING ROWID into :5”這句話時(shí)出的問(wèn)題,而且說(shuō)有的錯(cuò)誤都是這樣。這句話是將一個(gè)圖片寫(xiě)入數(shù)據(jù)庫(kù)。
軟件是CS結(jié)構(gòu)的,總共有八個(gè)客戶端。八個(gè)客戶端每3秒錄入一條數(shù)據(jù),數(shù)據(jù)包括一些文本類的信息還有就是有一張圖片,圖片大小在80KB至200KB不等。圖片是直接存入數(shù)據(jù)庫(kù)中的。
現(xiàn)在是單個(gè)用戶錄入時(shí)不會(huì)出現(xiàn)問(wèn)題,八個(gè)用戶一起錄入時(shí)很快就會(huì)出現(xiàn)這個(gè)問(wèn)題。查了oracle的參數(shù),沒(méi)有用戶數(shù)方面的限制和Session的限制。
現(xiàn)在就是覺(jué)得奇怪了,ORACLE是大型數(shù)據(jù)庫(kù),不可能會(huì)出現(xiàn)這種類似于并發(fā)訪問(wèn)的問(wèn)題的。從日志簡(jiǎn)單的分析上來(lái)看是一個(gè)用戶數(shù)據(jù)寫(xiě)入未完成時(shí)另一個(gè)用戶寫(xiě)入數(shù)據(jù)造成數(shù)據(jù)文件被占用造成的。程序里試驗(yàn)過(guò),使用事務(wù)和不使用事務(wù)結(jié)果是一樣的,基本上可以排除事務(wù)將文件給鎖住的原因。
兩個(gè)解決方法:
1 將數(shù)據(jù)庫(kù)升級(jí)到9.2.0.1以上,不是一定得用10G之類的,升級(jí)成9.2.0.3或更高的,當(dāng)然越高越好。
2 圖片不寫(xiě)入數(shù)據(jù)庫(kù),存成文件之類的。
老外的解決問(wèn)題的方法:
The solution is (as proposed on this thread):
alter system set events '10046 trace name context off';
alter system set timed_statistics=false;
執(zhí)行完這兩條腳本,問(wèn)題果然解決。
注:
timed_staticstices 用于啟動(dòng)或禁止對(duì)定時(shí)統(tǒng)計(jì)信息(如CUP時(shí)間、占用時(shí)間),以及動(dòng)態(tài)性能表中多種統(tǒng)計(jì)信息的收集功能。
ORA-00603錯(cuò)誤解決過(guò)程
今天在查看job運(yùn)行情況時(shí),發(fā)現(xiàn)一同步數(shù)據(jù)的job執(zhí)行了很長(zhǎng)時(shí)間,但也沒(méi)有出現(xiàn)異常記錄。手動(dòng)執(zhí)行之后出現(xiàn)ORA-00603錯(cuò)誤,解決過(guò)程如下:
1.插入操作報(bào)ORA-00603錯(cuò)誤,上網(wǎng)搜索說(shuō)是temp空間不夠,但實(shí)際用戶所用的臨時(shí)表空間不是系統(tǒng)的temp空間,而自定
關(guān)鍵詞:Oracle
閱讀本文后您有什么感想? 已有 人給出評(píng)價(jià)!
- 0
- 0
- 0
- 0
- 0
- 0