infrmi逻辑日志监控与分析.doc

informix逻辑日志监控与分析 逻辑H志实际上是一?组文件，这些文件保存了自上次o级备份以来数据库事务和数据库服 务器变更的历史记泉。逻辑日志文件不是普通的操作系统文件。它们是由Informix Dynamic Server在第一次初始化期间自动创建的，由Informix Dynamic Server o叩arants实用程 序管理。逻辑日志文件是循环的。换句话说，在它们被填满之后，又可以一次接一次地重复 使用。但是，对于重用有一定的条件： 必须备份逻辑口志文件。默认情况下，当日志文件被填满时，Informix Dynamic Server 服务器将A动备份逻辑日志文件。这是巾配置文件中的ALARMPROGRAM参数规定的。应该总 是将该参数设置为一个名为log_full.sh的脚本，该脚本会进行逻辑日志文件的备份。 Log_full. sh是随Informix Dynamic Server软件包一起提供的一个服务器系统脚本。 逻辑U志中的所有记录都必须与关闭的事务相关联。这里提到的关闭的事务，是指要么 提交要么回滚了的事务。如果一个事务悬而未决，而在逻辑口志中又有与之关联的一条记录, 那么该逻辑日志就不能重用。 逻辑日志决不能包含最后检查点记录。Onstat -1输出可以告诉我们那个逻辑日志包 含了最后检查点记录：如果在输出屮标志字段的最后一位是“L”，那么表明逻辑日志包含了 最后检査点记录，因而不能重用。 逻辑口志决不能包含任何没有刷新到磁盘的事务。这是为了确保所有事务不会丢失。当 一个事务完成时，它呆在逻辑日志中，等待检查点的到來，以便刷新到磁盘。如果我们在检 查点之前重用逻辑日志，那么将丢失所有那些事务。 在配置逻辑H志时，我们需要注意以下问题： 大小。逻辑口志文件的适当大小介于200 KB （最小）和2,097, 152 KB （最大）之间。 这是一个很宽的范围，也没有什么难于遵循的规则。基本上，更小的逻辑日志文件有更小的 恢S粒度。如果包含逻辑日志文件的磁盘崩溃，那些上次没有备份的逻辑日志文件就有丢失 的风险。 数量。至少应该总是有三个逻辑日志文件，最多可有32,767个。这同样是个很宽的范 围。请根据生产环境来作出决定。逻辑日志文件的数量决不能超过配置文件中LOGMAX参数 的值。不过，在Informix Dynamic Server 9. 40x该限制己被撤销。 位賈。逻辑日志文件的位賈相当重要。当Informix Dynamic Server进行第一次初始 化时，它自动地创建逻辑日志文件，并将这些文件一起放在rootdbspace中。逻辑日志将 导致大量向root dbspace的磁盘写操作，而那里存储/所有重要的系统统计信息，这样就 可能导致磁盘I/O争用。为了最小化root dbspace的磁盘争用，以提高整个系统的性能, 应该将逻辑日志移出root dbspace,而将它们分布在其他磁盘设备屮。 备份。在添加新逻辑日志之后，要做一次备份，可以是实备份（使用实备份设备），也 可以是“假”备份（使用/dev/null ）0否则，Informix Dynamic Server就不能使用那些 新添加的逻辑日志。这一限制在Informix Dynamic Server 9. 4x屮己被撤销，在那里， Informix Dynamic Server可以在将遷辑日志添加到系统之后马上使用它们。 在任何时候都要维护最少情况下的三个逻輯日志。否则Informix Dynamic Server将 不能启动。 此外，下面有一些性能方面的考虑: 逻辑H志备份。当逻辑日志被填满时，必须备份它们。备份逻辑H志时将A用系统资源， 例如CPU和内存，并且妨碍那些涉及与逻辑日志存放在相同磁盘上的数据的事务。 检查点。检查点阻塞川户或数据库事务处理。如果频繁地备份和释放逻辑日志，那么检 查点将经常出现，结果就是数据库事务可能会经常被肌塞，从而占有更长的时间才得以完成。 数裾庳事务日志记录的类型。使用无缓冲日志记录的数椐库会比那些使用缓冲日志记录 的数据库更快地填充逻辑日志。 要丫解关于如何有效地配置逻辑口志的细节，请参考IBM Informix Dynamic Server Administrator’s Guide, Version 9. 4（在本文中引作 Administrator’s Guide）的第 13 章。 逻辑円志由onparams实用程序管理，该实用程序允许添加、删除（drop）和移动逻辑円志。 如前所述，在第一次初始化期间，Informix Dynamic Server将自动创逮一些逻辑日忠。它 所创建的逻辑日志的数量是由配置文件中的LOGFTLES参数规定的。此后，使用onparams 实用程序添加、删除或者移动逻