Informix常见错误处理思路

Update Statistics的作用
为了提高数据库的效率，INFORMIX提供了一个基于成本的 查询优化器， 执行update statistics语句的作用就是将您创建的数据 库表的有关统计信息更新到系统sysmaster的相关表中，以便查询 优化器选择最佳的执行路径。当sysmaster库中没有相应的统计信 息，或者统计信息不十分准确时，优化器便无法制定一个行之有 效的查询策略，其结果必然是进行大量极其可怕的顺序扫描，产 生严重的性能问题。 因此，当您重新装载数据或者对数据库表进行了大量的更新 操作后，应该及时执行update statistics。也许您会发现，数据库一 些参数配置的不合理可能使数据库效率降低百分之几，但如果您 没有定期执行update statistics的话。数据库的性能则可能降低几到 十几倍。
Informix的应用案例
• 查询业务库中表大小（方式一）
Informix的应用案例
• 查询业务库中表大小（方式二）
Informix的应用案例
在公司OA系统提交主机操作记录，审核通过后即可操作
Informix的应用案例
Informix的应用案例
Informix的应用案例
有兴趣的同事可以浏览：
希望同事们给点儿掌声，激发自我学习的激情。
谢 谢!
数据库 chunk 出现异常，I/O 失败
• 故障现象： 数据库日志中出现 chunk IO 错误，使用 onstat –d 观察 chunk flag 的状态是 down 的状态，数据库操作中不能操作包含在这些 chunk 中的数据，如果使 用到这些数据可能会返回错误，严重情况下会导致数据库宕机。
频繁的锁冲突
使用onstat –g sql + sessid –r 跟踪查询锁状态
频繁的锁冲突
• 故障处理：
1. 调整数据库隔离级别，例如使用 dirty read，将数据库表的缺省页级锁 修改为行级锁； 设置锁等待时间； 调整应用 SQL，提高执行效率，尽量快的完成事务处理，释放资源； 如果需要快速处理锁冲突的情况，在确定锁的实际拥有者以后可以确 定是否应该终止其操作，执行 onmode –z <sid> Kill specified session id ，以达到释放锁资源的目的。
Informix的应用案例
接下来，我们以一个主机数据操作记录案例来了解 一下，刚刚所讲的两条命令在实际操作中的应用。
操作背景：DCOMS数据库空间已达91%，为满足业务系
统数据空间需要，对历史数据备份后进行清理。
操作计划：根据空间情况，需要对DCOMS业务库 中所有表进行分析以判断哪些表比较大，是否可做 数据备份清理。对于一些比较重要的表，尤其是财 务方面的表，需要提前与财务或业务部门沟通后再 做清理。当然，我们可根据经验制定相应的清理标 准。
Informix 常见错误处理思路及应用
深圳IT-叶万华
2019年1月10日
informix常见错误处理思路
逻辑日志满
频繁的锁冲突 长事务 I/O 失败
逻辑日志满
• 故障现象： 数据库不再进行任何操作，使用 onstat –l 命令观察逻辑日志状态，所有 的逻辑日志都处于已使用未备份状态，即 flags 为 U------ 标志。
• http://www.cniug.org/informix-dba/194-informix.html 中国Informix数据库用户协会
所有的管理都存在一定风险，所有的监控都是为了更好的管理。希望同事们不 断总结经验，共享经验，从各方面提升自我。我们可以抱着怀疑的态度去肯定 自己，证实自己。任何操作都是有风险的，请大家多留意细节！
长事务
• 故障处理： 根据数据库日志里面所提供的信息可以很方便的发现具体是哪一个事务造 成了长事务。系统在将某个事务判定为长事务以后就会自动对其进行回滚 操作。事后可以有针对性的调整应用将大的事务划分为小事务进行提交； 避免一个活动事务长时间没有后续的操作；提供充足的逻辑日志空间，这 里所指出的不仅是空间的总量需要增加，逻辑日志的个数也是应该增加的 ，因为判断的标准是以逻辑日志的使用个数所占比例来确定的。在 INFORMIX 9.3X 以后的版本中可以通过动态增加逻辑日志的手段避免由于 长事务带来的一些不良影响，在长事务回滚过程中如果逻辑日志空间被消 耗完毕，如果 DYNAMIC_LOGS 设置为 2，数据库服务器会自动在最后创 建的逻辑日志所存在的 dbspace 上查找空余空间，按照最后创建的逻辑日 志的大小自动在当前逻辑日志之后新增逻辑日志，如果不能满足需要则会 创建失败，需要管理员手工添加。
onspa01g2:/home/szit>onstat –l address 1228d4ed0 1228d4f38 1228d4fa0 1228bec50 1228becb8 1228bed20 1228bed88 1228bedf0 1228bee58 number 1 2 3 4 5 6 7 8 9 flags U-----U-----U---C-L U-B---U-B---U-B---U-----U-----U-----uniqid 10521 10522 10523 10504 10505 10506 10507 10508 10509 begin 3:53 3:12853 3:25653 3:38453 3:51253 3:64053 3:76853 3:89653 3:102453 size 12800 12800 12800 12800 12800 12800 12800 12800 12800 used 12800 12800 10828 12800 12800 12800 12800 12800 12800 %used 100.00 100.00 84.59 100.00 100.00 100.00 100.00 100.00 100.00
2. 3. 4.
长事务
• 故障现象： 在数据库日志里面出现发现长事务的提示，受影响的事务处于回滚状态， 个别情况下会导致整个数据库实例的其他数据库会话都停止执行。
• 故障分析： 当一个活动事务它所占用的逻辑日志个数的比例达到或超过 LTXHWM（ 长事务基准线） 所设定的值，数据库就会判定该事务为一个长事务，对该 事务进行回滚操作，如果这个时候逻辑日志的使用个数仍然持续上涨达到 或超过 LTXEHWM 所设定的值，则数据库会停止其他会话的正常运转， 全力保证该长事务的回滚操作。
类似的锁表现象中，我们在日常的监控过程中会经常观察得到。
频繁的锁冲突
• 故障分析：
数据库在进行修改操作的时候为了防止其他用户的同时修改，都会在修改所涉及的数据上设 置对应的锁，如果其他用户再访问到这些已经被放置上锁的数据，就会出现锁失败。例如如 果需要知道在指定的表上是有哪些用户具体占用了锁，可以通过以下的方式查看： 执行 onstat –u来获得实际的 session 信息，从中就可以找到锁的拥有者。
在确定所有硬件或设置都已经恢复正常以后，可以首先尝试使用 onspaces – s 进行恢复，如果还不能恢复成功，请联系 IBM 相关人员技术支持。
Informix的应用案例
dbschema 常用命令 Update Statistics的作用 应用案例
dbschema 常用命令
•
• • • • • •
•
1）导出数据库中所有的表结构到文件db.sql $dbschema -d your_database -t all db.sql 2) 导出数据库中所有的存储过程到文件db.sql $dbschema -d your_database -f all db.sql 3）导出数据库中的所有对象（包含表，存储过程，触发器。。。）到文件db.sql $dbschema -d your_database db.sql 4) 导出数据库中一个表的结构到文件db.sql $dbschema -d your_database_name -t your_table_name db.sql 5) 导出一个存储过程定义到文件db.sql $dbschema -d your_database_name -f your_procedure_name db.sql 6) 如果导出更多的表的信息(EXTENT...) $dbschema -d your_database_name -ss db.sql 7) 导出数据库中对用户或角色的授权信息 $dbschema -d your_database_name -p all $dbschema -d your_database_name -r all 8) 导出数据库中一个表的详细结构到文件db.sql $dbschema -d 【your_database_name】 -t 【your_table_name】 -ss 【db.sql】
频繁的锁冲突
• 故障现象： 在正常的数据库操作中会经常出现－243、－244 等一类的锁错误码出现 -243 Could not position within a table table-name. -244 Could not do a physical-order read to fetch next row.
(注：红色部分为异常状态，如绿色部分也被使用完，数据库将出现异常。版 面上只显示出该店出现异常时用onstat –l监控到的部分信息。)
逻辑日志满
• 故障分析： 由于数据库的大部分操作都需要记录逻辑日志，所以如果逻辑日志由 于各种各样的原因被充满都会导致数据库停止正常的操作，等待逻辑日 志空间的释放、重新再利用。原因可能为： 1. 数据库逻辑日志没有及时备份 2. 数据库逻辑日志空间分配过小 3. 逻辑日志里面包含活动事务、包含检查点信息
• 故障分析： 由于发生 IO 错误，数据库不能正常的操作包含在受影响 chunk 中的数据 ，所有的操作请求都将失败。这可能是由于磁盘设备出现问题、chunk 所 使用的设备不存在、使用的链接设备不存在、设备的权限错误等可能性。
数据库 chunk 出现异常，I/O 失败
• 故障处理： 根据前面所列出的可能性逐一进行检查。一个快速确定存储设备是否可用 的办法是：使用 dd 命令实际读取该设备，这里需要强调的是只能做读取操 作，不能写入，严禁在 of 设备项指定为 chunk 路径，因此我们也只能验证 其存储设备是否可读，例如： dd if=/home/informix/940/dsk/data_chk1 of=/dev/null bs=2048k
逻辑日Hale Waihona Puke Baidu满
• 故障处理： 检查是否是由于逻辑日志备份出现问题，如果是不能备份请查找不能 备份的原因，可能是由于磁带满或磁带机出现故障，或者是磁带设备繁 忙；个别情况下即使逻辑日志标志为已备份但是仍然是不可使用的，包 括： 1. 该逻辑日志包含活动的事务信息，由于数据库需要考虑其可能的回滚 操作，因此是不会让该逻辑日志的内容被覆盖的，可以通过 onstat –x 检查其 beginlg 来确定事务的逻辑日志起始位置； 2. 包含检查点信息，可以通过 onstat –l 观察 flags 的最后一位为 L 的逻辑 日志的位置，在它之后的逻辑日志即使已经备份也是不可使用的，因 为这些逻辑日志内容将会在快速恢复中使用到。 3. 在这些情况出现以后如果暂时不能快速的处理，可以使用逻辑日志联 机增加的功能，只要有空闲的 chunk 空间，即可在当前逻辑日志后增 加新的逻辑日志，并且不需要执行 0 级备份。