Oracle難道不能處理大資料並發的問題

來源:互聯網
上載者:User

 

Oracle難道不能處理大資料並發的問題

 

前天使用者突然反映一個軟體總是報ora-00603錯誤。一開始一位就是個普通的資料表空間不足之類的,可是一看日誌卻發現不是那麼簡單。

 

截取部分日誌如下:

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就是我的那個程式使用的資料表空間的一個資料檔案。資料表空間總共有四個資料檔案加起來8G左右,總體使用率在70%左右。資料檔案號分別為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 時出現 IO 錯誤 (塊 # 42773)
ORA-27041: 無法開啟檔案
OSD-04002: 無法開啟檔案
O/S-Error: (OS 32) 另一個程式正在使用此檔案,進程無法訪問。
ORA-01114: 將塊寫入檔案 11 時出現 IO 錯誤 (塊 # 42773)
ORA-27041: 無法開啟檔案
OSD-04002: 無法開啟檔案
O/S-Error: (OS 32) 另一個程式正在使用此檔案,進程無法訪問。
ORA-01114: 將塊寫入檔案 11 時出現 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”這句話說明了是在執行“INSERT INTO "VIO_JDCZP" ("XH","HPHM","HPZL","PHOTO1") VALUES (:1,:2,:3,:4) RETURNING ROWID into :5”這句話時出的問題,而且說有的錯誤都是這樣。這句話是將一個圖片寫入資料庫。

 

軟體是CS結構的,總共有八個用戶端。八個用戶端每3秒錄入一條資料,資料包括一些文本類的資訊還有就是有一張圖片,圖片大小在80KB至200KB不等。圖片是直接存入資料庫中的。

 

現在是單個使用者錄入時不會出現問題,八個使用者一起錄入時很快就會出現這個問題。查了oracle的參數,沒有使用者數方面的限制和Session的限制。

 

現在就是覺得奇怪了,ORACLE是大型資料庫,不可能會出現這種類似於並發訪問的問題的。從日誌簡單的分析上來看是一個使用者資料寫入未完成時另一個使用者寫入資料造成資料檔案被佔用造成的。程式裡實驗過,使用事務和不使用事務結果是一樣的,基本上可以排除事務將檔案給鎖住的原因。

 

不知園子裡哪些仁兄能解釋一下這個問題,這個問題上網上查也出不出個所以然來,只能在這裡向各位求教了。

 

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.