Informix BTSCANNER索引清理技术

B-Tree scanner是Informix数据库用来清理脏索引项以及压缩B-Tree叶子节点索引页的功能组件。现在随着业务量、数据量的增长，BTSCANNER带来的影响也逐渐浮出水面，BTSCANNER也成了我们需要加以关注的对象。...



你不一定要点蓝字关注我的

B-Tree scanner是Informix数据库用来清理脏索引项（标记为删除的索引项）以及压缩（合并）B-Tree叶子节点索引页的功能组件。在过去的使用过程中，我们往往会采用默认的数据库BTSCANNER配置，对BTSCANNER的运行机制和使用等均鲜有了解。现在随着业务量、数据量的增长，BTSCANNER带来的影响也逐渐浮出水面，BTSCANNER也成了我们需要加以关注的对象。通过这篇文章，针对BTSCANNER运行机制的解刨，希望能够让读者对BTSCANNER是如果工作的有更深入的理解，从而能够提升Informix数据库OLTP事务处理性能。B-Tree scanner从Informix数据库V7.31.UD8、V9.21.UC7、V9.30.UC6以及之后的版本开始推出，B-Tree scanner用来清理脏的索引项（标记为删除的索引项）以及压缩（合并）B-Tree叶子节点索引页。在新的版本中，新的btscanner线程替换了老的btcleaner线程（在这里会不会有很多老司机跟我一样傻傻分不清楚，O(∩_∩)O~）。新的btscanner机制能够比以前效率更高、更灵活以及管理更简单。

当一个索引项从索引中被删除后，这个删除操作并不会立即将这个索引项从索引页中移除，而是仅仅将这个索引项标记为删除。在事务中，在这个“未提交的删除的索引项（uncommitted deleted item）”会维护一个锁。当这个事务提交后，这个索引项上面的锁也随之释放，但是这个“已经提交的删除的索引项（committed deleted item）”占用的空间是没有释放的。随着未被清理的已经标记为删除的索引项越来越多，这对数据库的性能的负面冲击越来越大，因为数据库需要额外的工作去检查锁，而且，索引的大小也会不断增长，需要消耗更多的I/O资源。

对于数据库索引扫描操作，想要扫描扫描能够尽量执行的更快，“已经提交的标记为删除的”索引项比较及时从索引页中移除，并且索引需要能够及时压缩（合并不饱满的索引页）以及维护索引的平衡（索引采用B+树数据结构）。其中，将“已经提交的标记为删除的”索引项的处理过程叫做索引清理（index cleaning）。在Informix数据库采用一个特殊的叫做btscanner的线程负责异步地清理索引。相对比于老版本中的btcleanr索引清理机制，新版本中的btscanner索引清理机制有了非常大的改进和提升，下面我们列举出其中比较突出的特点：

◾btscanner线程能够动态地创建和配置。在数据库启动时通过BTSCANNER配置参数进行配置后，可以通过onmode -C命令进行动态调整；

◾已经提交的标记为删除的索引项，如果没有清理，会引起数据库服务器做额外的工作。btscanner能够根据这些索引的负载（影响情况）进行排序和清理；

◾ 对于每一个索引，每次遇到“已经提交的被标记为删除的索引项”（索引扫描、索引维护）时，就会通过hit-count计数器进行计数。如果hit-count的数值超过了指定的阈值，那么btscanner就会着手针对这个索引进行清理，将这个索引放置到hot-list上；

◾btscanner根据hot-list清单上列出的需要清理的索引，扫描一定范围的索引叶子节点页进行清理。一次性扫描多少个索引页进行清理依据配置的模式，btscanner支持多种索引扫描模式，总共有叶子扫描、范围扫描和Alice（自适应线性索引清理）扫描三种模式。btscanner根据扫描模式扫描一定范围的索引叶子节点，将其中已经提交的标记为扫描的索引项清理掉。同时，如果需要的话，会将不饱和的索引页进行合并。可以通过如下方式配置BTSCANNER：

◾BTSCANNER配置参数（ONCONFIG文件中）；

◾onmode -C命令动态修改；

在数据库的ONCONFIG文件中，通过BTSCANNER配置参数来指定BTSCANNER索引清理的相关配置。其中由如下五个部分组成，如下表4-1所示：

当在数据库运行过程中，需要动态的修改BTSCANNER相关配置时，可以通过onmode -C命令命令来修改，如下表4-2所示：

叶子扫描

在叶子扫描模式中，btscanner线程从根节点开始，沿着B+树从索引的左节点开始查找，一直找到叶子节点，然后一直将所有的叶子节点找到并且扫描，判断这些叶子节点的索引页中是不是存在“已经提交的被标记为删除”的索引项。这种方式对于较小的索引以及attached的索引效率较高。

如果将大小较大的索引也采用叶子扫描这种方式，那么需要将每一个叶子节点的索引页读取到数据库的buffer pool中，这样会消耗非常多个I/O操作以及buffer pool中的buffer页。同时，如果这些叶子节点中仅仅有小部分的索引页含有“已经提交的被标记为删除”的索引项，也就是说这些I/O操作大部分都是无效的，命中率非常低，浪费了大量的I/O操作。范围扫描

相比于叶子扫描模式，范围扫描不需要读取所有的叶子节点索引页。btscanner会维护每一个索引中含有“已经提交的被标记为删除的”索引项的最小的逻辑页地址和最大的逻辑页地址。范围扫描只会读取这个范围内的索引页，这些索引页将会被读取到buffer pool中进行清理。

相比于叶子扫描，范围扫描能够大大提升btscanner的索引清理效率。范围扫描需要更少的I/O操作，因为它只读取索引的一部分，并且能够大大减少对buffer pool的消耗。然而，在某些极端的场景下，含有“已经提交的被标记为删除的”索引项的最小的逻辑页地址和最大的逻辑页地址形成的这个范围能够涵盖整个索引的大小。在这种场景下，范围扫描也会执行很多不必要的I/O操作。ALICE扫描

从V10.00.xC5版本起，Informix支持了一种新的索引清理和索引扫描模式，叫做ALICE（Autonomic Linear Index Cleaning，自适应线性索引清理）模式。该机制下，会将索引中的所有索引页分组形成一个一个大小相等的region。通过bitmap位图来标识哪一个region中含有“已经提交的被标记为删除”索引项的索引页，其中一个bit比特用来表示一个region，如果bit的值为1，则表示这个region代表的索引页中含有“已经提交的被标记为删除”的索引项，需要扫描并且清理这个region内的索引页。

Alice扫描含有12个级别，取值范围分别为0-12（0表示禁用ALICE扫描）。级别的不同仅仅在于一个region能够表示的索引页数量。比如ALICE模式的级别设置为N，那么表示需要2^(12-N)次I/O操作来表示索引范围。其中，一次I/O操作将读取256个索引页。

基于索引的清理效率，btscanner能够自动调整Alice扫描的级别。这里讲的索引的清理效率，是指读取的索引页中含有“已经提交的被标记为删除”的索引页的比例。btscanner默认在5次索引扫描后，如果效率依然低于30%，那么就把Alice扫描模式的级别往上升一个级别，这样也就是每一个bit比特代表更少的索引页（每个region含有更少的索引页），以此就可以提高索引的命中率和扫描效率。在btscanner机制之前，清理索引中含有“已经提交的被标记为删除”的索引项的效率是非常低的，而且也不易于管理。btscanner机制的产生，提供了一个更有效、更灵活的清理索引的方式，而且提供了方便的命令用于动态调整和监控btscanner。

相信经过了这篇文章的介绍，读者能够为数据库实例选择合适的索引清理方式，通过ONCONIFG文件配置BTSCANNER参数，通过onmode命令动态的修改BTSCANNER的配置，并且监控btscanner的运行状态，从而能够提升Informix数据库OLTP事务处理性能。公众号

ToprowDB

长按识别左侧二维码，关注我们

    关注 ToprowDB