生活生产服务其它Informix
监控和估计Informix Dynamic Server 中逻辑日志的使用情况
简介逻辑日志（logical log）是数据库管理的一个重要方面。如果没有得到适当的管理，逻辑日志将给数据库管理员带来许多头痛的事。最常见的一些问题是：长事务（long transaction）。如果一个事务达到独占长事务高水准线（exclusive long transaction high water mark，ELTM）时还没有提交...显示全部
查看其它 4 个回答zhixian的回答
估计逻辑日志的使用：一个示例
估计逻辑日志的使用情况并非易事，这牵涉到大量的详细分析、测试和计算。下面是一个很好的实际生活中的例子。
我们的客户在运行名为 Move BSC 的程序时，会碰到有关长事务的问题。BSC 是无线电通讯（telecommunication）中的一个网络元素。当 BSC 从一个地方移动到另一个地方时，程序就会执行大量的存储过程，每个存储过程又会执行大量的数据库操作，例如对不同的数据库表进行插入、删除和更新。由于数据库使用了事务日志记录，所有这些操作都被记录在逻辑日志中。用户一次移动过多的 BSC，使用了系统上所有可用的逻辑日志，Informix Dynamic Server 达到了长事务，这些情况都很少发生。因而，整个事务最终会回滚。这导致客户受阻，因为回滚会占用很长的时间，而且会冻结 Informix Dynamic Server 引擎。因此客户请求我们为他们提供一个数学公式，以便估计在开始移动 BSC 之前逻辑日志的使用情况以及一次可以移动的 BSC 的最大数量。
由于逻辑日志的使用与事务紧密相关，我们首先必须识别在 Move BSC 程序中涉及到多少事务。假设一个存储过程的每次执行就是一个事务，因为存储过程中的所有数据库操作都是一起执行的。下面的表列出了 Move BSC 程序中使用或者调用的所有存储过程，以及存储过程的执行次数：
现在有了以上表的帮助，我们就可以进一步识别出每个事务中涉及到什么样的数据库操作，以及有多少这样的操作。经过仔细研究和分析之后，我们产生了一个表格，这个表格列出了在每个存储过程或者事务中涉及到的所有数据库操作。这份列表相当长，下面只是对该列表的一个摘要，它列出了所有数据库表和在 bsc_D 存储过程中涉及到的相应的操作：
然后我们必须为每个存储过程估计逻辑日志的使用情况。这牵涉到大量的测试和计算。我们需要进行大量的测试，以便获得针对在 Move BSC 中涉及到的每个表的每个数据库操作的逻辑日志使用情况的统计数字。接下来，我们要使用通过测试收集到的统计数字，为 Move BSC 程序中的每个存储过程计算逻辑日志的使用情况。在所有数据库操作当中，插入操作要使用大部分的逻辑日志。因此我们决定使用插入作为我们进行估计的基准。首先，识别在存储过程中涉及到的一系列的表，然后将一些行或记录插入到每个表中。接着我们使用 onlog 实用程序来查看由于插入操作而生成的逻辑日志记录有多少，并求每条逻辑日志记录长度的总和。例如，为了为 NE 表估计逻辑日志的使用，在测试数据库时我们插入一行到 NE 表中，然后使用 -n 155，其中 155 是日志 id，这样我们得到以下输出：
有了上面的表，要计算出每个存储过程将使用多少逻辑日志空间就容易多了。例如，计算存储过程 BSC_D 的逻辑日志使用情况：
下面的表总结了 Move BSC 中涉及的每个存储过程的逻辑日志使用情况：
Move BSC 的逻辑日志使用情况
所以 Move BSC 总共使用的逻辑日志大约是 54 MB。这是一个非常保守的估计。既然 Move BSC 包含了许多的事务，那么很可能在 Move BSC 的运行期间，有些逻辑日志空间会随着某些事务的提交而得到释放，并准备重用。我们配置了 80 个逻辑日志，每个 30 MB 大，长事务高水准线设为 50。这意味着系统上可用的逻辑日志空间是： 80 * 30 / 2 = 1200 MB。最后，我们将所有这些计算综合起来，从而为客户提出了以下公式：
1200 MB - maximum BSC to move * 54 MB => 30MB
其中 30 MB 是一个逻辑日志的大小。根据 Informix Dynamic Server 文档，我们应该总是预留一个空的逻辑日志。因此，如果剩下的逻辑日志记录空间大于 30 MB，那么还是安全的，我们可以自信地说 Move BSC 将会成功，而不会有任何问题，因而每次移动 BSC 的最大数量是：
Maximum BSC to move =< (1200 MB - 30 MB) / 54
移动 BSC 的最大数量是 21，也就是说，如果客户试图一次移动超过 21 个 BSC，那么 Informix Dynamic Server 就会耗尽逻辑日志，而成为长事务，这样反过来就会中止 Move BSC 操作，并冻结 Informix Dynamic Server 引擎。
估计逻辑日志的使用情况并非易事，这牵涉到大量的详细分析、测试和计算。下面是一个很好的实际生活中的例子。
我们的客户在运行名为 Move BSC 的程序时，会碰到有关长事务的问题。BSC 是无线电通讯（telecommunication）中的一个网络元素。当 BSC 从一个地方移动到另一个地方时，程序就会执行大量的存储过程，每个存储过程又会执行大量的数据库操作，例如对不同的数据库表进行插入、删除和更新。由于数据库使用了事务日志记录，所有这些操作都被记录在逻辑日志中。用户一次移动过多的 BSC，使用了系统上所有可用的逻辑日志，Informix Dynamic Server 达到了长事务，这些情况都很少发生。因而，整个事务最终会回滚。这导致客户受阻，因为回滚会占用很长的时间，而且会冻结 Informix Dynamic Server 引擎。因此客户请求我们为他们提供一个数学公式，以便估计在开始移动 BSC 之前逻辑日志的使用情况以及一次可以移动的 BSC 的最大数量。
由于逻辑日志的使用与事务紧密相关，我们首先必须识别在 Move BSC 程序中涉及到多少事务。假设一个存储过程的每次执行就是一个事务，因为存储过程中的所有数据库操作都是一起执行的。下面的表列出了 Move BSC 程序中使用或者调用的所有存储过程，以及存储过程的执行次数：
现在有了以上表的帮助，我们就可以进一步识别出每个事务中涉及到什么样的数据库操作，以及有多少这样的操作。经过仔细研究和分析之后，我们产生了一个表格，这个表格列出了在每个存储过程或者事务中涉及到的所有数据库操作。这份列表相当长，下面只是对该列表的一个摘要，它列出了所有数据库表和在 bsc_D 存储过程中涉及到的相应的操作：
然后我们必须为每个存储过程估计逻辑日志的使用情况。这牵涉到大量的测试和计算。我们需要进行大量的测试，以便获得针对在 Move BSC 中涉及到的每个表的每个数据库操作的逻辑日志使用情况的统计数字。接下来，我们要使用通过测试收集到的统计数字，为 Move BSC 程序中的每个存储过程计算逻辑日志的使用情况。在所有数据库操作当中，插入操作要使用大部分的逻辑日志。因此我们决定使用插入作为我们进行估计的基准。首先，识别在存储过程中涉及到的一系列的表，然后将一些行或记录插入到每个表中。接着我们使用 onlog 实用程序来查看由于插入操作而生成的逻辑日志记录有多少，并求每条逻辑日志记录长度的总和。例如，为了为 NE 表估计逻辑日志的使用，在测试数据库时我们插入一行到 NE 表中，然后使用 -n 155，其中 155 是日志 id，这样我们得到以下输出：
addr len type xid id link 18 48 BEGIN 20 155 0 07/01/2003 15:34:08 737 omcadmin 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 84 48 COMMIT 20 0 48 07/01/2003 15:34:08上面的输出表明，将一条记录插入到 NE 表中将生成三条逻辑日志记录，该数据库操作所使用的总逻辑日志空间是 284 字节，这也是三条记录长度的总和（140 + 88 + 56）。此外，还有 96 字节的事务开销，也就是 BEGIN 和 COMMIT 记录的总和。事务开销是恒定的，每个数据库事务都要加上这一项。在这里，也就是对于存储过程的每次执行都要考虑这一项。结果，我们得出下面的表，这个表列出了将一条记录插入到 Move BSC 程序中涉及的每个表中的逻辑日志的使用：
有了上面的表，要计算出每个存储过程将使用多少逻辑日志空间就容易多了。例如，计算存储过程 BSC_D 的逻辑日志使用情况：
Total logical log usage = 200 * 284 + 600 * 248 + 100 * 276 + 100 * 448 + 100 * 652 + 400 * 392 + 300 * 236 = 618000 (bytes)此外，我们还需要加上事务开销（96 字节），检查点（36 字节）和 DPT 开销（取最大值 300 字节）。每当为每次存储过程的执行计算逻辑日志开销时，所有这些开销都要加进来。因此该存储过程的全部逻辑日志开销就是 580500 + 96 +300 = 618396 字节，大约 620 KB （620 KB?）。要获得关于检查点和 DPT 的详细描述，请参考 Administrator's Guide的第 4 章。
下面的表总结了 Move BSC 中涉及的每个存储过程的逻辑日志使用情况：
Move BSC 的逻辑日志使用情况
所以 Move BSC 总共使用的逻辑日志大约是 54 MB。这是一个非常保守的估计。既然 Move BSC 包含了许多的事务，那么很可能在 Move BSC 的运行期间，有些逻辑日志空间会随着某些事务的提交而得到释放，并准备重用。我们配置了 80 个逻辑日志，每个 30 MB 大，长事务高水准线设为 50。这意味着系统上可用的逻辑日志空间是： 80 * 30 / 2 = 1200 MB。最后，我们将所有这些计算综合起来，从而为客户提出了以下公式：
1200 MB - maximum BSC to move * 54 MB => 30MB
其中 30 MB 是一个逻辑日志的大小。根据 Informix Dynamic Server 文档，我们应该总是预留一个空的逻辑日志。因此，如果剩下的逻辑日志记录空间大于 30 MB，那么还是安全的，我们可以自信地说 Move BSC 将会成功，而不会有任何问题，因而每次移动 BSC 的最大数量是：
Maximum BSC to move =< (1200 MB - 30 MB) / 54
移动 BSC 的最大数量是 21，也就是说，如果客户试图一次移动超过 21 个 BSC，那么 Informix Dynamic Server 就会耗尽逻辑日志，而成为长事务，这样反过来就会中止 Move BSC 操作，并冻结 Informix Dynamic Server 引擎。
浏览760