話外:在說這個問題前,我先說說昨天說的CSDN的部落格問題,
總之,不是很爽,昨天同樣寫了一篇文章,不過是直接在CSDN上面寫的在提交時
CSDN後臺出錯啦!!!暈.白寫半天..說起來自己也真夠笨的,
希望別的朋友不要和我一樣犯這樣的底級錯誤!

話裡:
    今天...不...應該是昨天.在公司遇到這樣一件事性.當有後臺開通程式向
    informix批量加入資料時.速度非常慢,整個表被鎖起.所以別的操作都沒辦法進
    行下去.最後用下面的命令跟蹤到加入資料的SQL,分析出原來是在建表時
    初始空間和擴充套件空間設定不合理,導致每幾次在加入資料時,informix
    都要自己在去擴充套件表空間,且擴充套件比較小,所以啦!就鎖住啦!!呵呵.問題就是這
    樣的.下面是跟蹤的過程,也是種精驗吧.看兄弟們你們用不用的上.
   
   
    oncheck -pt 資料庫名:表名       //查詢表的使用情況,和空間申請次數      number of extends 每次申請擴充套件數

  onstat -g act -r 2       //看當前執行緒 每2秒執行一次     查出tcb
  
  onstat -u|grep tcb       //檢視當前執行緒   執行的SQL ID號
  
  onstat -g sql id                  //檢視SQL
  
  onmode -z id                     //殺掉執行的SQL
  
  onstat -d                       //資料庫空間
  
  dbschema -d 資料庫名 -t 表名 -ss u.sql      //匯出建表SQL到u.sql檔案
  
  
  { TABLE "informix".o_message row size = 4248 number of columns = 10 index size =
              20 }
create table "informix".o_message
  (
    message_id char(15) not null ,
    staff_id integer not null ,
    primary key (message_id)  constraint "informix".pk_o_message
  )  extent size 16 next size 16 lock mode row;