原文：https://www.ibm.com/developerworks/data/library/techarticle/dm-0311fan/index.html
逻辑日志是数据库管理的重要方面。 逻辑日志如果管理不当，将使数据库管理员感到头疼。 一些最常见的问题是：
多头交易。 如果一笔交易达到排他的多笔交易高水位标记（ELTM）时未提交或回滚，则该交易被称为多笔交易。 排他的长事务高水位标记是一个配置参数，规定单个事务可以跨越逻辑日志的百分比。 一旦事务达到Informix®Dynamic Server配置文件中的ELTM设置，服务器就会中止事务并开始回滚事务。 在回滚期间，服务器将暂停进一步的数据库操作，前端用户将遇到其应用程序的挂起。
灾难恢复。 如果丢失任何逻辑日志，则在发生灾难的情况下，我们选择的还原策略将受到限制； 我们只能执行冷恢复。 由于Informix Dynamic Sever需要检查所有逻辑日志以重新应用上次备份之后发生的数据库事务，因此不可能进行热还原。 结果就是数据丢失。
性能慢。 如果我们没有将逻辑日志放置在正确的位置，例如，如果将逻辑日志放置在根dbspace或磁盘上的其他热点中，则系统和服务器的整体性能将受到影响。
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输出可以告诉我们哪个逻辑日志包含最后一个检查点记录：如果flags字段在其输出中的最后位置是“ L”，则表明该逻辑日志包含最后一个检查点记录并且无法重用。
逻辑日志中不得包含未刷新到磁盘的任何事务。 这是为了确保所有交易都不会丢失。 事务完成后，它将保留在逻辑日志中，等待将检查点刷新到磁盘。 如果我们在检查点之前重用逻辑日志，我们将丢失所有这些事务。
在配置逻辑日志时，我们需要注意以下问题：
尺寸。 逻辑日志文件的正确大小在200 KB（最小）和2,097,152 KB（最大）之间。 这是一个广泛的领域，没有一个硬性规则可以遵循。 基本上，较小的逻辑日志文件具有较小的恢复粒度。 如果包含逻辑日志文件的磁盘出现故障，则可能会丢失最后一个未备份的逻辑日志文件。
数。 必须始终至少有三个逻辑日志文件。 最大数量为32,767。 这又是一个广泛的范围。 根据生产环境做出决定。 逻辑日志文件的数量不得超过配置文件中LOGMAX参数的值。 但是，在Informix Dynamic Server 9.40x中取消了此限制。
位置。 逻辑日志文件的位置很重要。 当Informix Dynamic Server首次初始化时，它会自动创建逻辑日志并将其与物理日志一起放置在根dbspace中。 逻辑日志文件将导致对所有重要系统统计信息存储在的根dbspace的大量磁盘写入，并且可能会引起磁盘I / O争用。 为了最大程度地减少对根dbspace的磁盘争用，从而提高整体系统性能，请将逻辑日志移出根dbspace，然后将其传播到其他磁盘设备中。
备份。 添加新的逻辑日志后，请进行真实（使用真实备份设备）或伪造（使用/ dev / null）备份。 否则，Informix Dynamic Server不能使用这些新添加的逻辑日志。 在Informix Dynamic Server 9.4x中取消了此限制，该限制将在将逻辑日志添加到系统后立即使用。
始终保持最少三个逻辑日志。 否则，Informix Dynamic Server将无法启动。
此外，还有一些性能注意事项：
逻辑日志备份。 逻辑日志填满后，必须对其进行备份。 备份逻辑日志将使用诸如CPU和内存之类的系统资源，并阻碍涉及与逻辑日志位于同一磁盘上的数据的数据库事务。
检查点。 检查点阻止用户或数据库事务处理。 如果经常备份和释放逻辑日志，则检查点将频繁发生，因此，数据库事务可能会不断被阻塞，并需要更长的时间才能完成。
数据库事务日志记录的类型。 使用无缓冲日志记录的数据库将比使用缓冲日志记录的数据库更快地填充逻辑日志。
有关如何有效配置逻辑日志的详细信息，请参阅《 IBM Informix Dynamic Server管理员指南，版本9.4》 （在本文中称为“管理员指南”）的第13章。
逻辑日志由onparams实用程序管理，该实用程序允许添加，删除和移动逻辑日志。 如上所述，在首次初始化期间，Informix Dynamic Server将自动创建一些逻辑日志。 它创建的逻辑日志的数量由配置文件中的LOGFILES参数规定。 之后，使用onparams实用程序添加，删除或移动逻辑日志。 Onparams具有以下选项：
onparams -a -d <DBspace> [-s <size>] [-i] | -d -l <log file number> [-y] | -p -s <size> [-d <DBspace>] [-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必须处于静态或单用户模式。 这意味着在使用该实用程序添加，删除或移动逻辑日志时，不允许其他用户连接或活动。
有关如何使用此实用程序的详细信息，请参阅《 管理员指南》 。
如何读取和解释逻辑日志的内容以及哪些有用的信息来自逻辑日志记录？ 常规的操作系统编辑器（例如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转储。 ASII转储是数据更改的ASII代码，在这种情况下，更新语句用于数据库还原。 标头部分是最有趣的。 它包含许多字段，并将提供一些有关事务的有用信息。 下表说明了标题部分中的每个字段：
| 标头字段 | 描述 | 格式 |
|---|---|---|
| 地址 | 日志位置 | 十六进制 |
| 伦 | 记录长度（以字节为单位） | 小数 |
| 类型 | 记录类型名称 | 信息产业协会 |
| 西德 | 交易号 | 小数 |
| ID | 逻辑日志号 | 小数 |
| 链接 | 链接到交易中的前一个记录 | 小数 |
此外，输出还记录了交易时间：交易从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转储部分。 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管理员参考》 。
监视逻辑日志使用情况
配置逻辑日志后，请不断监视逻辑日志的使用情况，以确保有足够的逻辑日志，以使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）。 标志字段指示逻辑日志状态； U代表已使用的逻辑日志，B代表已备份，C代表当前正在使用，L代表具有最多检查点记录的逻辑日志。 上面的输出显示使用了逻辑日志号5，但是当前仍在使用并且具有最多的检查点记录。 Uniqid字段是唯一的日志ID。 由于逻辑日志是循环的； 每当重新使用逻辑日志时，此数字都会更改。 大小字段指示页面中逻辑日志的大小（一页约为2 k字节）。 已用字段表示用于事务记录的空间，也以页为单位。 ％used字段以百分比表示逻辑日志使用情况。 有关输出中所有字段的详细说明，请参阅《 管理员参考》的第3章。
要监视当前事务的逻辑日志使用情况，这是一个小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)
}'该脚本在帮助确定当前事务消耗了多少逻辑日志空间方面非常有用。 但是，有没有办法变得更加主动？ 如果知道正在执行的事务，可以预先计算逻辑日志空间吗？ 交易的成功或失败可以预测吗？ 如果答案是肯定的，则应主动采取一些措施，例如增加逻辑日志空间或将事务分成较小的部分，以避免长时间的事务。
估计逻辑日志使用量：一个示例
估计逻辑日志的使用量并非易事，它涉及许多详细的分析，测试和计算。 这是一个真实的例子。
我们的客户在运行名为Move BSC的程序时遇到长时间交易的问题。 BSC是电信中的网络元素。 当BSC从一个位置移动到另一个位置时，该程序将执行许多存储过程，并且这些存储过程中的每一个又会执行许多数据库操作，例如对不同数据库表的插入，删除和更新。 由于我们的数据库使用事务日志记录，因此所有这些操作都记录在逻辑日志中。 在极少数情况下，我们的客户一次移动了太多的BSC，并且使用了系统上所有可用的逻辑日志，而Informix Dynamic Server却耗费了很长时间。 因此，整个交易最终被回滚。 由于回滚花费了很长时间，并且冻结了Informix Dynamic Server引擎，这使客户感到沮丧。 因此，我们的客户要求我们给他们一个数学公式，以估算逻辑日志的使用情况，然后再开始移动BSC和一次可以移动的最大BSC数量。
由于逻辑日志的使用与事务密切相关，因此我们必须首先确定Move BSC程序中涉及多少事务。 我们假定存储过程的每次执行都是一个事务，因为存储过程中的所有数据库操作都作为一个整体执行。 下表列出了Move BSC程序使用的或由其调用的所有存储过程及其执行次数：
| 存储过程名称 | 执行次数 |
|---|---|
| bsc_I | 2 |
| bsc_UA | 2 |
| 笼子 | 4 |
| cage_UA | 4 |
| slot_I | 64 |
| gp_func_I | 12 |
| bsc_xcdr_assoc_I | 1个 |
| te_I | 52 |
| te_timeslot_I | 637 |
| gp_func_xcdr_I | 6 |
| nail_I（xcdr） | 2 |
| bsc_D | 2 |
| 笼_D | 4 |
| slot_D | 64 |
| gp_func_D | 12 |
| bsc_xcdr_assoc_D | 1个 |
| te_D | 52 |
| te_timeslot_D | 637 |
| gp_func_xcdr_D | 6 |
| nail_D | 3 |
| 总 | 1567 |
现在，借助上表，我们能够进一步确定每个事务涉及什么以及涉及多少数据库操作。 经过仔细的研究和分析，我们制作了一个电子表格，列出了每个存储过程或事务中涉及的所有数据库操作。 该列表很长，下面仅是列表的一部分，其中显示了bsc_D存储过程中涉及的所有数据库表和相应的操作：
| 存储过程名称 | 表名 | 操作方式 | 操作次数 |
|---|---|---|---|
| BSC_D | 奈琳 | 更新资料 | 200 |
| 一个 | 聚氯乙烯 | 删除 | 600 |
| 一个 | Tdm | 删除 | 100 |
| 一个 | 平衡计分卡 | 删除 | 100 |
| 一个 | NE | 删除 | 100 |
| 一个 | 工作空间操作日志 | 插 | 400 |
| 一个 | Workspace_paramlog | 插 | 300 |
然后，我们必须估计每个存储过程的逻辑日志使用情况。 这涉及大量的测试和计算。 我们需要进行大量测试，以获取Move BSC中涉及的每个表上每个数据库操作的逻辑日志使用情况统计信息。 接下来，我们必须使用从测试中收集的统计信息来计算Move BSC程序中使用的每个存储过程的逻辑日志使用情况。 在所有数据库操作中，insert使用大多数逻辑日志。 因此，我们决定使用插入作为我们估算的基础。 首先，我们确定了存储过程中涉及的表的列表，然后将几行或记录插入到每个表中。 然后，我们使用onlog实用程序查看插入操作生成了多少逻辑日志记录，并汇总了每个逻辑日志记录的长度。 例如，为了估计NE表的逻辑日志使用率，我们在测试数据库中的NE表中插入了一行，然后使用onlog -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的记录长度之和。 事务开销是恒定的，需要为每个数据库事务添加。 在我们的情况下，对于存储过程的每次执行。 结果，我们提出了下表，该表列出了逻辑记录用法，该逻辑用法用于将记录插入到与移动BSC操作有关的每个表中：
| 表名 | 逻辑日志使用量（以字节为单位） |
|---|---|
| 平衡计分卡 | 448 |
| bscage | 300 |
| 卡 | 324 |
| 链接 | 378 |
| bscnail | 424 |
| ccb | 308 |
| cpxcdr | 304 |
| ds | 248 |
| gpfunc | 248 |
| 米斯潘 | 300 |
| NE | 652 |
| 奈琳 | 284 |
| 聚氯乙烯 | 248 |
| ib | 356 |
| 板条 | 300 |
| tdm | 276 |
| workspace_oplog | 392 |
| workspace_paramlog | 236 |
| xblconn | 290 |
使用上面的表，找出每个存储过程将使用多少逻辑日志空间会容易得多。 例如，计算存储过程BSC_D的逻辑日志使用率。 根据上面的表格，驱动以下公式进行计算：
Total logical log usage = 200 * 284 + 600 * 248 + 100 * 276 + 100 * 448 + 100 * 652 + 400 * 392 + 300 * 236 = 618000 (bytes)
此外，我们需要添加96字节的事务开销，需要36字节的检查点和最多300字节的DPT开销。 对于每个存储过程执行，所有这些开销都需要添加一次。 因此，此存储过程的实际总逻辑日志使用量为580500 + 96 +300 = 618396字节，约为620 KB（620 KB？）。 有关检查点和DPT的详细说明，请参阅《 管理员指南》的第4章。
下表总结了Move BSC中涉及的每个存储过程的逻辑日志用法：
移动BSC的逻辑日志用法
| 操作名称 | 操作次数 | 每次操作的日志使用率 | 总日志使用量（字节） |
|---|---|---|---|
| bsc_I | 2 | 415880 | 831760 |
| bsc_UA | 2 | 165960 | 331920 |
| 笼子 | 4 | 18720 | 74880 |
| cage_UA | 4 | 18720 | 74880 |
| slot_I | 64 | 29680 | 1899520 |
| gp_func_I | 12 | 15840 | 190080 |
| bsc_xcdr_assoc_I | 1个 | 3718340 | 3718340 |
| te_I | 52 | 41400 | 2152800 |
| te_timeslot_I | 637 | 30080 | 19160960 |
| gp_func_xcdr_I | 6 | 39500 | 237000 |
| nail_I（xcdr） | 2 | 22320 | 44640 |
| bsc_D | 2 | 618400 | 1236800 |
| 笼_D | 4 | 21720 | 86880 |
| slot_D | 64 | 27320 | 1748480 |
| gp_func_D | 12 | 15840 | 190080 |
| bsc_xcdr_assoc_D | 1个 | 3713620 | 3713620 |
| te_D | 52 | 41400 | 2152800 |
| te_timeslot_D | 637 | 24640 | 15695680 |
| gp_func_xcdr_D | 6 | 42200 | 253200 |
| nail_D | 3 | 22320 | 66960 |
| 总 | 1567 | 一个 | 53861280 |
因此，Move BSC的逻辑日志总使用量约为54 MB。 这是一个非常保守的估计。 由于Move BSC包含大量事务，因此在Move BSC期间，由于提交的事务，很有可能释放一些逻辑日志空间并准备重用。 我们配置了80个逻辑日志，每个逻辑日志大30 MB，长事务高水位标记设置为50。这意味着我们系统上的可用逻辑日志空间为：80 * 30/2 = 1200 MB。 最后，我们将所有这些计算放在一起，并为我们的客户提出以下公式：
Â1200 MB-移动的最大BSC * 54 MB => 30MB
30 MB是一个逻辑日志的大小。 根据Informix Dynamic Server文档，我们应该始终保留一个空的逻辑日志。 因此，如果剩余逻辑日志空间大于30 MB，那么我们可以安全地说，移动BSC将会成功，没有问题，因此一次移动的最大BSC数目为：
Â可移动的最大BSC = <（1200 MB-30 MB）/ 54
要移动的BSC的最大值为21，换句话说，如果客户一次尝试移动超过21个BSC，则Informix Dynamic Server可能会用尽逻辑日志并击中长事务，这反过来将中止Move BSC操作并冻结Informix Dynamic服务器引擎。
结论
我们的公式有多准确？我们对估计有多少信心？ 让我们对其进行测试。 在我们的实验室中，我们在不同的机器上进行了三个测试，以模拟客户使用Move BSC的情况。 在每次测试之前，我们使用onstat -l获取日志空间使用情况（输出的“ 日志空间已使用”字段）信息，然后在每次测试之后，我们再次进行此操作，然后计算两者之间的差异。 这两个数字之间的差异是所使用的实际逻辑日志空间。 下表显示了我们的测试结果，单位为千字节：
移动BSC测试结果
| 测试 | 描述 | 之前 | 后 | 实际 | 预料到的 | 准确性 | ||
|---|---|---|---|---|---|---|---|---|
| 1个 | 移动 | 10 | 平衡计分卡 | 336707980 | 851707980 | 515000000 | 540000000 | 95.37 |
| 2 | 移动 | 15 | 平衡计分卡 | 2198356812 | 2978356812 | 780000000 | 810000000 | 96.30 |
| 3 | 移动 | 20 | 平衡计分卡 | 7035159124 | 8105159124 | 1070000000 | 1080000000 | 99.07 |
上面的测试结果表明，平均而言，我们的估算值对现实的准确度超过95％，并且还注意到预测列中的数字始终大于实际列中的数字； 这意味着我们对逻辑日志使用情况的估计是充分而可靠的。
