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

本文将详细讨论如何配置和管理逻辑日志。本文还将通过一个实际生活中的例子演示如何估计和预测逻辑日志的使用情况。

逻辑日志（logical log）是数据库管理的一个重要方面。如果没有得到适当的管理，逻辑日志将给数据库管理员带来许多头痛的事。最常见的一些问题是：

• 长事务（long transaction）。如果一个事务达到独占长事务高水准线（exclusive long transaction high water mark，ELTM）时还没有提交或回滚，我们就说该事务是长的。独占长事务高水准线是一个配置参数，该参数规定单个事务能横跨逻辑日志多大的百分比。只要一个事务达到了在一个 Informix Dynamic Server 配置文件中设置的 ELTM，服务器将中止该事务，并开始回滚该事务。在回滚期间，服务器将挂起进一步的数据库操作，前端用户将在他们的应用程序中遭遇中止。
• 灾难恢复（disaster recovery）。如果我们丢失了任何逻辑日志，那么在遇到灾难时，我们能选择的恢复策略就要受到限制。我们只能执行代码恢复（cold restore）。热恢复（warm restore）是不可能的，因为 Informix Dynamic Sever 需要检查所有逻辑日志来重新应用自上一次备份之后的数据库事务。结果就是数据丢失。
• 慢性能（slow performance）。如果没有将逻辑日志放在适当的位置，例如，如果我们将逻辑日志放在 root dbspace 中，或者磁盘上其他的热点（hot spot）中，那么系统和服务器的整体性能就会遭殃。
• Informix Dynamic Server 中止。如果没有正规地备份逻辑日志，并且在系统中使用了所有的逻辑日志，那么 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字段的和算出。在这个例子中，逻辑日志使用了 3556字节的空间来记录这个事务！要获得对以上输出的每个记录类型的详细解释，请参考 Informix Dynamic Server Administrator's Reference。

配置了逻辑日志之后，应不断监控逻辑日志的使用情况，以确保有足够的逻辑日志，这样 Informix Dynamic Server 就可以避免前面讨论过的长事务的情况。要监控逻辑日志的使用，需使用 onstat 实用程序。命令 onstat -l 将显示当前逻辑日志的使用情况。以下是 onstat -l 的示例输出：

Informix Dynamic Server Version 9.40.FC1      -- On-Line -- Up 1 days 19:37:46 -- 1818624 Kbytes Physical Logging Buffer bufused   bufsize   numpages numwrits pages/io    P-2   0         16        178155    11983     14.87        phybegin          physize     phypos      phyused     %used           1:263             8750        6413        0           0.00     Logical Logging Buffer bufused   bufsize   numrecs   numpages numwrits recs/pages pages/io    L-2   0         16        1695756   319940    227242    5.3         1.4      Subsystem     numrecs   Log Space used OLDRSAM       1695756   241316428      address           number    flags     uniqid    begin                 size      used     %used 16f4a7e90         4         U-B----   244       7:53                 15000     15000    100.00 16f4a7ee8         5         U---C-L   245       7:15053              15000      7558     50.39 16f4a7f40         6         U-B----   166       7:30053              15000     15000    100.00 16f4a7f98         7         U-B----   167       7:45053              15000     15000    100.00 16f181218         8         U-B----   168       7:60053              15000     15000    100.00 16f181270         9         U-B----   169       7:75053              15000     15000    100.00 16f1812c8         10        U-B----   170       7:90053              15000     15000    100.00 7 active, 7 total

看看该输出的底端部分。 Number字段表明逻辑日志号。该号码可能不是连续的，因为 DBA 可能要根据系统需要插入和删除逻辑日志。例如，上面的输出表明，由于某种原因，前三个逻辑日志（号码 1 到 3）已经被删除。 Flags字段表明逻辑日志的状态。U 代表使用过的逻辑日志，B 代表备份过，C 代表当前正在使用，L 代表有最后检查点记录的逻辑日志。上面的输出表明，逻辑日志 5 被使用过，但当前仍在使用，而且它有最后检查点记录。 Uniqid字段是惟一的日志 id。由于逻辑日志是循环的，当逻辑日志被重用时，该号码就会改变。Size 字段表明按页计算逻辑日志有多大（一页大约 2 k 字节）。Used 字段表明事务记录所使用的空间，这也是按页计算的。 %used字段表明逻辑日志的使用百分率。要获得该输出中所有字段的详细描述，请参考 Administrator's Reference的第 13 章。

为了监控当前事务的逻辑日志使用情况，下面有一个小小的 shell 脚本。它基本上是使用 onstat -l命令，但是它还计算通过该命令收集到的统计数字，然后输出该事务所使用的逻辑日志空间，这里是以百分比表示的。

#!/bin/sh $INFORMIXDIR/bin/onstat -l | awk -F" " ' BEGIN { t_flag=0 } { if ($1 == "address")     { t_flag=1 } if ( t_flag == 1 )     {     if ( $1 == "address")        { t_logsize=0          t_logused=0        }     else        {          if ( substr($3,3,1) != "B" )             { t_logused=t_logused+$7 }          t_logsize=t_logsize+$6        }     } } END { t_logperct=t_logused/t_logsize*100 printf("Logical log space used %-d%\\n",t_logperct) }'

该脚本在帮助识别当前事务消耗了多少逻辑日志空间时很有帮助。但是有没有更具前瞻性的方法呢？如果将要执行的事务是已知的，那么可不可以预先计算出逻辑日志空间呢？可不可以预测事务能否成功？如果答案是肯定的，那么就可以前瞻性地采取某些行动，例如增加逻辑日志空间或者将事务劈成更小的块以避免长事务。