如何解决inix数据库锁表问题.doc

如何解决Informix数据库锁表问题Informix数据库在移动智能网占有重要地位，而从实际的运行情况来看，informix数据库出现的问题很多，大多数情况下informix出现问题体现为系统严重限呼（SCP20库）、SMAP/WEBSAMP/SMPMML操作超时（insms20库），有共同的特别oninit进程占用很高。这里主要讨论一下数据库表被锁的定位和处理，下面几个问题分析处理的过程希望能对日常定位问题有一定的帮助。我们经常说数据库表格被锁，那怎么判断那个表被锁？是那个用户、那个线程将表锁了？用informix用户onstat k系统输出如下：Locksaddress wtlist owner lklist type tblsnum rowid key#/bsizc1808c20 0 d656ced8 0 HDR+S 100002 205 0c1808e28 0 d656a28c 0 S 100002 205 0c1808f2c 0 d656a778 0 S 100002 205 0c1808f60 0 d656ac64 0 S 100002 205 0c1809064 0 d656c9ec 0 S 100002 205 0c18091d0 0 d656dd9c 0 S 100002 205 0c1809440 0 d656f14c 0 S 100002 205 0c18094dc 0 d65709e8 0 S 100002 205 0c1809510 0 d656e774 c181cb3c HDR+X 6002e1 2c602 0c1809a8c 0 d656e774 c180b764 HDR+X 6002e1 2cf01 0c1809af4 0 d656e774 c18186fc HDR+X 6002e1 2cf02 0c1809bc4 0 d656e774 c180bee8 HDR+X 6002e1 28b03 0c1809c60 0 d656e774 c1824960 HDR+X 6002e1 2c302 0c1809fa0 0 d656e774 c1826ff8 HDR+X 6002e1 28901 0c180a03c 0 d656e774 c1818ee8 HDR+X 6002e1 2b901 0c180a0d8 0 d656e774 c1825ad8 HDR+X 6002e1 2bb02 0需要关注lklist和type项，从上面来看tblsnum为6002e1（6292193）的表被锁了。可以重查询是那个表被锁：dbaccess ：select * from systables where partnum=6292193得到tabname basetab_mvpnowner smpmmlpartnum 6292193tabid 12813rowsize 464ncols 61nindexes 1nrows 2984created 12/10/2002version 839843846tabtype Tlocklevel Rnpused 746fextsize 16nextsize 16flags 0明显是basetab_mvpn表被锁。此时可以通过dbaccess确认：选择info选择表名后选择“status”系统会提示表被锁。知道那个表被锁就比较好办了，执行onstat u，将owner为d656e774的线程找出来，address flags sessid user tty wait tout locks nreads nwritesd656e774 Y-P- 4261 smp20 - d6ad2330 0 180 99620 16再用onstat g sql d656e774可以将这个线程执行过的sql语句打印出来。确定该线程已经没有用处后，解决问题只要用informix用户执行onmode-z 4261干掉线程就可以了。在处理这些问题时还会遇到表被锁是因为该线程还没有执行完毕，此时就不能简单的onmode z杀线程了。以下是几个最近遇到的解决数据库表被锁问题处理方法：例一：scp20的sms_union_smrecord表和monet_smrecord表索引失效，SCP限呼严重。在SCP上面查看：mscp1 tellin :/tellin/logonstat -uInformix Dynamic Server Version 7.31.UC5 - On-Line (Prim) - Up 136 days 14:21:06 - 348664 KbytesUserthreadsaddress flags sessid user tty wait tout locks nreads nwritesd51003c8 -P-B 10 informix - 0 0 0 109 4027d51008b4 -P-D 13 informix - 0 0 0 0 0d510128c Y-P-D 59781 informix - d51f4388 0 0 155 68d5101778 -BPR- 71328 tellin ta 0 0 3 76 275d5102150 -P-D 59782 informix - 0 0 0 0 0d5102b28 -P-D 59783 informix - 0 0 0 0 1d5103500 Y-P- 71335 tellin tg d89c3d38 0 1 0 0d51039ec -P-M 59795 informix - 0 0 0 0 0d51079e8 Y-P- 59796 tellin - d53c4428 0 1 47 0d51083c0 Y-P- 71204 tellin - d53c8888 0 1 230 96d5109284 Y-P- 59701 tellin ta d5358ba0 0 0 15958 14432d510a148 -PR- 71311 tellin ta 0 0 1 324 929d510e630 -PR- 71316 tellin - 0 0 1 256 770d510eb1c Y-P- 71086 tellin ti d54bbd58 0 1 2 0d510f008 L-PR- 71326 tellin ta c163b3f8 10 1 133 337我们在看这些结果的时候关注的是flags项目，Y、P是正常的，R、M、B就是一些异常的情况。需要进一步分析。mscp1 tellin :/tellin/logonstat -g sql 71328Last parsed SQL statement : update monet_MSReport set PushTotal=PushTotal-50,PushCount=PushCount-1 where Report_Month=? and MS=?mscp1 tellin :/tellin/logonstat -g sql 71326Current SQL statement : selectRecordFlag,Realfee,DestGWID,SourceGWID,PayMS,OtherNum,ServiceCode,MSPayKind ,MSMsgfee,Discount,SMCAddress,DealTime,SPID,CDrType,PriorityFlag,ServerCode from monet_smrecord where Msgid=?可以看出肯定跟梦网的表格有关，如果需要进一步确定是那个表有问题，可以使用研发提供的工具indexcheck.sh（请在无线智能网信息系统上面取得）。mscp1 tellin :/tellin/tempidxcheck.sh scp20 -r 100=idxcheck start at 2003-03-13 09:48:18=2003-03-13 09:48:50: 1 sequential scan found on table pps_attendant!Write message to OAM(1955) success!Write message to OAM(10982) success!Write message to OAM(10456) success!2003-03-13 09:48:53: 63 sequential scan found on table monet_smrecord!=check result: total 64 sequential scans found on 57 tablestable number of sequential scan foundmonet_smrecord 63pps_attendant 1Hint: you may check indexs on these tables检查该表发现索引已经建立，问题应该是索引失效了，解决问题需要对monet_smrecord表的索引字段进行优化：update statistaics low for table monet_smrecord;该SCP每天早上monet_smrecord的索引都会失效，最终定位为，dailymonet的配置存在问题，该SCP设置只保存了一个小时的梦网临时话单数据。因此该表每天都几乎被清空，在每次执行dailymonet后，大量删除数据情况下，导致索引失效。修改为默认配置，保留3天的记录，经过几天观察，问题解决。例二：某地SMP的basetab_pps表索引丢失，大量SMAP用户访问不成功，造成锁表。由于当时是白天，但onmode z杀掉一些进程后又有用户连进来，需要建索引没法建成功。解决的办法：rename table basetab_pps to basetab_ppst，然后建索引，建好后rename table basetab_ppst to basetab_pps。用户使用SMAP就正常了。例2：某地SCP的monet_monthfee表复合唯一索引丢失，由于SP该日发大量扣月租请求，SCP出现严重限呼。这是通过kill线程是解决不了问题的，因为这样的线程会不断的产生。唯一办法就是尽快建立索引。这时执行create unique index idx_monthfee on monet_monthfee (month,spid,servicecode,payms, destms)提示执行不成功，表中有重复记录。为了尽快解决限呼问题只能先建立非唯一索引create index idx_monthfee on monet_monthfee(month,spid, servicecode,payms,destms)。晚上需要重建表并建立唯一索引后，通过dbload将数据导入：-d表示数据库名；-c跟tgl文件名；-n表示多少行提交一个事务，-e表示允许unl文件中有多少行错误记录，错误记录将不导入数据库，记录在日志中；-l表示记录日志名。Dbload.sh文件：dbload