信德隨想

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

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

使用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，以達到釋放鎖資源的目的。