监控和估计Informix Dynamic Server 中逻辑日志的使用情况

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

onparams  -a -d  [-s ] [-i] | 
          -d -l  [-y]     |
          -p -s  [-d ] [-y] 
          -a  - Add a logical log file
          -i  - Insert after current log
          -d  - Drop a logical log file
          -p  - Change physical log size and location
          -y  - Automatically responds "yes" to all prompts

要使用 onparams 实用程序，有两个先决条件：
· 该实用程序专门限于用户 Informix。系统中其他用户，包括用户 root 或其他具有 DBA 权限的用户都不能使用此实用程序。
· Informix Dynamic Server 必须是静态或单用户模式。这意味着在使用该实用程序添加、删除或移动逻辑日志时，其他用户连接或活动都是不允许的。
请参考 Administrator's Guide以了解关于如何使用该实用程序的细节。
如何阅读和解释逻辑日志的内容，逻辑日志记录带有什么样的有用信息呢？通常的操作系统编辑器，例如 vi不能直接读逻辑日志；只能使用 onlog实用程序来读逻辑日志。该实用程序提供了以下功能：
·        显示关于每条日志记录的最大信息。
·        不显示程序头。
·        显示关于已记录的 BLOB 页（仅限 -d 选项）的信息。
·        从磁带设备读。
·        显示指定的日志。
·        显示指定的用户。
·        显示指定的 TBLspace。
·        显示指定的事务。
onlog显示逻辑日志记录时有两个选项，即 onlog -l和 onlog -n。例如，假设我们刚完成了一个数据库事务，该事务包含对一个表的一次更新。现在执行 onlog -l，看看逻辑日志如何记录这个事务：

addr     len  type     xid      id link    
18       48   BEGIN    20       155 0        07/01/2003 15:34:08 737      eric
         00000030 009b0001 00000000 00009af8 ...0.... ........ 
         00000014 00000000 0427bcdf 00000000 ........ .'...... 
         00000000 3f01f040 0000006e 000002e1 ....?..@ ...n.... 
48       60   HUPDAT   20       0  18       3000c1   1707     0        108 108 1  
         0000003c 00000049 00008010 00006d91 ...<...I ......m. 
         00000014 00000018 0427bcdf 00000000 ........ .'...... 
         003000c1 00001707 00000000 006c006c .0...... .....l.l 
         00010003 00020100 00000000          ........ ....
84       48   COMMIT   20       0  48       07/01/2003 15:34:08
         00000030 00000002 00000010 00006d91 ...0.... ......m. 
         00000014 00000048 0427bcdf 00000000 .......H .'...... 
         3f01f040 00001707 00000000 3f01f040 ?..@.... ....?..@ 

输出显示，该事务生成了三条逻辑日志记录，每条记录包含两部分：记录头和 ASII dump。ASII dump 是数据更改的 ASII 码，在这里更新语句是在数据库恢复中使用的。头部是最有趣的地方。它包含很多字段，将提供关于事务的一些有用信息。接下来的表解释了头部的每个字段：
头部字段        描述        格式
addr        日志位置        十六进制
len        以字节计的记录长度        十进制
type        记录类型名        ASII
xid        事务号        十进制
id        逻辑日志号        十进制
link        到事务中前一记录的链接        十进制
此外，该输出还记录了事务的时间：该事务始于 07/01/2003 15:34:08，在 07/01/2003 15:34:08 时完成。第一条记录标志事务的开始（开始工作），第三条记录标志事务的结束（提交工作）。第二条记录表明该事务只包含一个数据库操作，也就是更新。字段 len表明记录所占的逻辑日志空间。在这里，逻辑日志使用了 156 （所有三条记录的总和，48 + 60 + 48）字节来记录该事务。在估计逻辑日志的使用情况时，这个数字非常有用。在本文的后面还将有与此相关的更多讨论。
现在执行 onlog -n，看看输出有什么不同。既然这个选项是用于显示某特定逻辑日志中的逻辑日志记录的，因而就需要一个逻辑日志 id。知道了所有逻辑日志记录都在逻辑日志号 155 中，我们就可以执行 onlog -n 155，以下是输出：

addr     len  type     xid      id link    
18       48   BEGIN    20       155 0        07/01/2003 15:34:08 737   eric
48       60   HUPDAT   20       0  18       3000c1   1707     0        108 108 1  
84       48   COMMIT   20       0  48       07/01/2003 15:34:08

这里的输出非常类似于 onlong -l的输出，惟一不同之处是这里省去了逻辑日志记录的 ASII dump 部分。 Onlog -n选项只报告逻辑日志记录的头部。
让我们看一个更复杂的例子。再次假设我们刚刚完成了一个事务，但是这次该事务比起前面的事务要复杂得多。这次该事务包括一组数据库操作。
它创建一个表，插入一些行，更新行号，删除一行，然后删除这个表。用于记录该事务的逻辑日志是 234。通过使用 onlog -n 234，我们得到以下输出：

addr     len  type     xid      id link    
2ea81fc  36   CKPOINT  1        0  2ea8018  0       
2ea9018  48   BEGIN    38       234 0        07/04/2003 11:28:11 1035     eric
2ea9048  40   UNIQID   38       0  2ea9018  20005c   129     
2ea9070  380  BLDCL    38       0  2ea9048  2000d0 8 8 4 0 fan
2ea91ec  44   CHALLOC  38       0  2ea9070  00002:0000032326 8       
2ea9218  48   PTEXTEND 38       0  2ea91ec  2000d0   7        00002:0000032326
2ea9248  140  HINSERT  38       0  2ea9218  20005c   a0e      90 
2ea92d4  88   ADDITEM  38       0  2ea9248  20005c   a0e      7     1     36   
2ea932c  56   ADDITEM  38       0  2ea92d4  20005c   a0e      2     2     4    
2ea9364  72   HINSERT  38       0  2ea932c  20005d   1328     24 
2ea93ac  60   ADDITEM  38       0  2ea9364  20005d   1328     16    1     6    
2ea93e8  56   ADDITEM  38       0  2ea93ac  20005d   1328     17    -32766 4    
2ea9420  128  HINSERT  38       0  2ea93e8  20005f   909      77 
2ea94a0  120  ADDITEM  38       0  2ea9420  20005f   909      10    1     68   
2ea9518  88   ADDITEM  38       0  2ea94a0  20005f   909      7     2     36   
2ea9570  52   HINSERT  38       0  2ea9518  2000d0   101      4  
2ea95a4  52   HINSERT  38       0  2ea9570  2000d0   102      4  
2ea95d8  56   HUPDAT   38       0  2ea95a4  2000d0   101      0        4   4   1  
2ea9610  52   HDELETE  38       0  2ea95d8  2000d0   102      4  
2ea9644  140  HDELETE  38       0  2ea9610  20005c   a0e      90 
2ea96d0  88   DELITEM  38       0  2ea9644  20005c   a0e      7     1     36   
2ea9728  56   DELITEM  38       0  2ea96d0  20005c   a0e      2     2     4    
2ea9760  72   HDELETE  38       0  2ea9728  20005d   1328     24 
2ea97a8  60   DELITEM  38       0  2ea9760  20005d   1328     16    1     6    
2ea97e4  56   DELITEM  38       0  2ea97a8  20005d   1328     17    2     4    
2eaa038  128  HDELETE  38       0  2ea97e4  20005f   909      77 
2eaa0b8  120  DELITEM  38       0  2eaa038  20005f   909      10    1     68   
2eaa130  88   DELITEM  38       0  2eaa0b8  20005f   909      7     2     36   
2eaa188  36   PERASE   38       0  2eaa130  2000d0  
2eaa1ac  48   BEGCOM   38       0  2eaa188 
2eaa1dc  44   CHFREE   38       0  2eaa1ac  00002:0000032326 8       
2eaa208  36   ERASE    38       0  2eaa1dc  2000d0  
2eaa22c  48   COMMIT   38       0  2eaa208  07/04/2003 11:28:11
2eab018  484  DPT      1        234 0        37      
2eab1fc  36   CKPOINT  1        0  2eab018  0 

这个事务比第一个事务大得多，它生成了更多的逻辑日志记录。换句话说，比起先前的那个事务，这里逻辑日志占用了更多的空间来记录该事务。这个事务所使用的总空间可以通过求输出中所有 len字段的和算出。