如何区分Informix不同种类的长事务Word格式.docx
《如何区分Informix不同种类的长事务Word格式.docx》由会员分享，可在线阅读，更多相关《如何区分Informix不同种类的长事务Word格式.docx（56页珍藏版）》请在冰豆网上搜索。
107”这种情况的长事务已经超过了长事务高水位值（LTXHWM）并且没有自动进入到“commit”或“rollback”阶段，此时数据库会开始主动回滚该长事务在这种情况下，客户需要监控事务的回滚状态，必要时需要采取一定的措施防止该长事务阻塞数据库，影响生产。
2常见导致InformixPD的原因及处理方式
[常见导致InformixChunkPD的原因及处理方式]
环境:
IDS11.5UIX
问题描述:
在实际生产环境中，当客户使用双机时，存在一个问题。
当数据库实例在主机运行过程中，用户在主机中增加了链接文件并使用这些文件向实例中添加了chunk。
而在备机里忘记增加对应的链接文件。
此后如果执行双机切换操作，数据库服务器在备机启动过程中，数据库服务器将这些新chunk标志为PD（PrimaryDown）。
即使将实例切换回备机运行，chunk仍然是PD.
解答:
这是由于这些链接文件在备机不存在，导致数据库启动时无法读取对应chunk的内容。
因此数据库服务器将他们标识为PD。
此后，切换回主机问题仍然存在的原因是Informixchunk的状态信息保存在rootchunk内的保留页中。
当在备机数据库实例启动时chunk的标志位已经被置为PD（PrimaryDown）,切换回主机后，数据库不会自动改写这些标志位。
处理方法是在添加好相应的链接文件后，使用onspaces-s-p-o-O命令将标志位修改为PD（PrimaryOnline）
-s要修改chunk所属dbspaces名字
-p要修改chunk的全路径
-o要修改chunk的偏移量
-O（无附加参数）
3通过onstat-k信息发现锁的级别
在IBMInformix数据库维护时，有时知道上了锁，但并不知道锁的级别即是锁了整个表？
还是锁了相关的页，还是某一行？
下面的例子将解答这个问题。
注释：
tblsnum0x100002是数据库databasetablespace，是informix数据库的内部结构，在
onstat-k输出中可以忽略相关内容
Locksaddresswtlistownerlklisttypetblsnumrowidkey#/bsiz
4409ad50044d5bac00S000023030
4409ada8044d5bac04409ad50HDR+IX1003ba00
4409ae00044d5bac04409afb8HDR+X1003bb101K-1
4409ae58044d5bac04409ae00HDR+X1003bb201K-1
4409aeb0044d5bac04409ae58HDR+X1003bc101K-1
4409af08044d5bac04409aeb0HDR+X1003bc201K-1
4409af60044d5bac04409ada8HDR+X1003ba1010
4409afb8044d5bac04409af60HDR+X1003ba2010
440b0510044d5a8780HDR+S1000023030
440b0568044d5a878440b0510HDR+IX1003b800
440b05c0044d5a878440b0568HDR+X1003b83000
440b0720044d5c0d80S1000023030
440b0778044d5c0d8440b0720HDR+X1003c200
1、绿色的字显示的是在表0x1003c2上的表级别锁
2、蓝色字显示的是在表0x1003b8第三个页（0x3）的页级锁
3、红色的字显示在表0x1003ba，第二页（0x2）第一个槽的行级锁
4、紫色的字显示的是在表0x1003bb，第一页第一个槽，第二页第一个槽索引（K-1）上的锁
如果想要知道是哪一个索引引起了锁，可以通过oncheck-pT<
0xtblsnum>
查找
$oncheck-pT0x1003bb|grep"
IndexUsageReport"
IndexUsageReportforindex101_3onstores_demo:
informix.orders
IndexUsageReportforindex101_70onstores_demo:
4如何通过逻辑日志监控Informix数据库操作？
如何通过逻辑日志监控Informix数据库操作？
有时在没有数据库审计的情况下，也需要对数据库的某些操作进行监控或审计，此时一般只能通过对逻辑日志的分析来实现，
下面我们将举一个通过逻辑日志监控altertable的例子
假设怀疑数据库“stores7”中的表“state”，在2003年9月29日16:
00到18:
00被恶意的修改了，我们需要查出谁在什么时间发起了这个alter操作。
1、在online.log中，通过CKPT完成的时间来确认相关的“logicallogs”
MonSep2917:
20:
062003
17:
38Checkpointloguniq287,logpos0xd2018
23:
34Checkpointloguniq287,logpos0xd5018
26:
22LogicalLog287Complete.
26Checkpointloguniq288,logpos0x18
47:
05Checkpointloguniq288,logpos0x1018
52:
06Checkpointloguniq288,logpos0x2018
通过上边的日志信息，我们可以猜测修改操作大概发生在逻辑日志287或288。
2、确认这些被选中的逻辑日志的状态和位置
（有没有被备份，在磁带中还是在磁盘上），通过onstat-l我们发现逻辑日志287和288还没有被备份，依然在磁盘上
flagsuniqid
U------287
U---C-L288
3、找到state表的partnum
$dbaccessstores7-
Databaseselected.
>
selecthex（partnum）fromsystableswheretabname='
state'
;
（expression）
0x001001FC
1row（s）retrieved.
4、查找相关操作记录
4.1、使用onlog命令找出关于表state在相应时间段的所有记录
$onlog-n287-l-t0x001001FC>
onlog-287.out
$onlog-n288-l-t0x001001FC>
onlog-288.out
4.2、在相应的记录输出中，查找相应的ALTER关键字
$grepALTonlog288.out
308c52PTALTER04030401001fc01130113111-20
4.3、分析整个记录确认所需事物信息
addrlentypexididlink
308c52PTALTER104030401001fc01130113111-20
3400000000005d0010000000680000004.....].....h...
40300000e385880000000000fc011000@0..............
01000100000000006a0400006b040000........j...k...
ecff0000....
Transactionid:
xid=104
5、使用onlog和BEGIN关键字得到关于事物104的详细信息
onlog-n288-l-x104>
onlog288-104.out
lognumber:
288.
301840BEGIN104288009/29/200317:
55:
2613Administrator
28000000200101000000000068000000（..........h...
00000000e1858800000000004eaa783f............N.x?
060000000d000000........
逻辑日志的记录我们可以看出"
Administrator"
用户，在09/29/200317:
26发起了相应的altertable操作
5如何监控、维护Informix数据库空间？
本文对如何监控、维护Informix数据库空间的方法及注意事项作了一个简单的小结，以方便广大InformixDBA在日常工作中处理Informix数据库空间的问题。
1、如何监控Informix数据库空间的异常离线?
1.1、在相关的chunk进行I/O操作时如果相应的Chunk有问题，数据库会报相应的I/O错误，并将CHUNK置为“PD”；
另外当数据库启动或是进行数据库备份时，Informix数据库会对所有空间进行例行的健康检查“sanitycheck”，如果相应的chunk有错误，Informix数据Informixonline.log中输出如下的错误信息：
08:
39:
58IBMInformixDynamicServerVersion9.40.FC4
58Who:
Session（1,informix@HBDB84_1,0,c000000000b63028）
Thread（15,main_loop（）,
升级会员 