最近客戶在執行程式時,常常會出現could not do a physical order read to fetch next row

因此在網路上找到了一個解決方法,再試試看這樣可不可以解決..悶.gif 

 


使用Informix時出現的異常:"could not do a physical order read to fetch next row",具體表現在大數據量操作數據庫的時候,容易出現。在JavaYou找到解決問題所在:

一方面可以在隔離級別的選擇上進行改動(但並不徹底),另一方面則是因為Informix默認鎖等待時間為0,即在操作(update、delete等)數據庫的時候,如遇到其他操作也在使用同一張表的情況時,則不等待和返回異常。

最簡單的解決方法就是每次在獲取新的(注意是新的,原有的連接也無妨,但影響效率)數據庫連接時,首先執行設置連接的鎖等待時間的Sql:

SET LOCK MODE TO WAIT 10 (意思是設置鎖等待時間為10ms),這樣基本解決問題,不再出現異常情況。


頻繁的鎖衝突

故障現象:

在正常的數據庫操作中會經常出現-243、-244 等一類的鎖錯誤碼出現

-243 Could not position within a table table-name.
-244 Could not do a physical-order read to fetch next row.


故障分析:

數據庫在進行修改操作的時候為了防止其他用戶的同時修改,都會在修改所涉及的數據上設置對應的鎖,如果其他用戶再訪問到這些已經被放置上鎖的數據,就會出現鎖失敗。例如如果需要知道在指定的表上是有哪些用戶具體佔用了鎖,可以通過以下的步驟:

  1. 首先確定表的 partnum,可以通過查詢 systables 裡面的 partnum,也可以通過執行 oncheck –pt database:tabname 查看 Partition partnum 來獲得,該數據為十進制數,需要轉換為十六進制;
  2. 執行 onstat –k | grep partnum 來查找相應的信息,partnum 為上一個步驟獲得的結果,需要使用具體的十六進制值來替換,觀察其 owner 字段的地址信息;
  3. 執行 onstat –u | grep address 來獲得實際的 session 信息,address 為上一個步驟獲得的結果,這是就可以找到具體的鎖的擁有者。
oncheck -pt stores:customer

Partition partnum 2097201
2097201=0x200031

onstat -k| grep 200031
5409bed4 0 54d93878 5409be7c HDR+IX 200031 0 0
5409bf2c 0 54d93878 5409bed4 HDR+U 200031 100 0

onstat -u | grep 54d93878
54d93878 Y--P--- 6 informix 12 5558e720 0 3 113 0


故障處理:

調整數據庫隔離級別,例如使用 dirty read;將數據庫表的缺省頁級鎖修改為行級鎖;設置鎖等待時間;調整應用 SQL,提高執行效率,儘量快的完成事務處理,釋放資源;如果需要快速處理鎖衝突的情況,在確定鎖的實際擁有者以後可以確定是否應該終止其操作,執行 onmode –z <sid> Kill specified session id,以達到釋放鎖資源的目的。

 

arrow
arrow
    全站熱搜

    丫德 發表在 痞客邦 留言(0) 人氣()