WebSphere 反向投资者: 您是否确定要重组消息引擎数据库？

核心提示：在每篇专栏文章中，“WebSphere 反向投资者”将回答问题、提供指导和讨论与 WebSphere 产品相关的基础主题，WebSphere 反向投资者: 您是否确定要重组消息引擎数据库？，经常会给出与流行的看法相悖的经过实践验证的建议， 沼泽地怪物我最近回复了一个电子邮件询问，虽然我在本讨论中

在每篇专栏文章中，“WebSphere 反向投资者”将回答问题、提供指导和讨论与 WebSphere 产品相关的基础主题，经常会给出与流行的看法相悖的经过实践验证的建议。

沼泽地怪物

我最近回复了一个电子邮件询问，结果在几天的过程中导致了一系列更多的电子邮件，这提示我回想起了我以前的经理非常喜欢的一句谚语：

当您深陷入鳄鱼口中的时候，很容易忘记当初为什么想要排干沼泽地的水。

您会问，这会让人想起什么呢？言归正传，该询问是咨询“IBM 要向对消息引擎数据库运行 DB2 重组和 runstat 的客户提供的建议”，虽然我并不以为是在全权代表 IBM 发言，但我的建议是不要操心去那样做。由于不喜欢鳄鱼，我通常尽量避免排干沼泽地的水，虽然为什么沼泽地可能根本不需要排干的原因对我来说似乎很清楚—— 或者对此例来说，为什么不需要对消息引擎数据库运行数据库实用工具——但是此建议并不是很适合该客户。虽然我并不确定客户最终是否被说服了，但是我想我应该在这里与您分享我的基本原理和方法，以便您能够决定什么可能最适合于您的环境。

调查沼泽地

在排干沼泽地的水之前，始终最好对其进行调查。在消息引擎数据库的情况下，您可以在 WebSphere Application Server 信息中心开始您的调查，其中提供了有关数据库结构的信息：

表 1. 消息数据库表

表	用途
SIBOWNER	确保某个活动的消息引擎对数据存储进行独占访问。
SIBCLASSMAP	对数据存储中不同的对象类型编录。
SIBLISTING	对 SIBnnn 表编录。
SIBXACTS	维护活动的两阶段提交事务的状态。
SIBKEYS	为消息引擎中的对象分配唯一标识符。
SIBnnn，其中 nnn 为数字	包含持久化的对象，例如消息和订阅信息；这些表同时包含持久和非持久对象，并对不同类型的数据使用单独的表。

困扰客户的其中一个问题是包含独占锁的 SIBOWNER 表，WebSphere Application Server 信息中心对此进行了阐述，其中陈述到（节选）：

数据存储中的 SIBOWNER 表将锁作为一对唯一标识符包含在单个行中。消息引擎在启动时使用这两个标识符获取和维护其独占锁：

MEUUID

消息引擎的唯一标识符，每当消息引擎启动和停止，此标识符保持相同。

INCUUID

消息引擎的具体标识符，在消息引擎每次启动时更改。

这些标识符确定哪一个消息引擎在使用某个数据存储。这些标识符还确定消息引擎的运行实例是否在其运行期间的时段中维护其独占锁。

当消息引擎启动时，它获得 SIBOWNER 表上的一个独占表锁。

消息引擎持有独占锁的结果在于，数据库维护实用工具无法以首选的方式运行，该方式旨在对数据库中的所有表进行维护。

需要改造？

现在您知道了沼泽地——即数据库——的大致情况，您真的需要将其排干吗？您可以通过停止正在使用消息引擎数据库的消息引擎，从而查看下表的内容：

>db2　select　*　from　ibmme0.sibowner　
　
ME_UUID　　　　　INC_UUID　　　　　VERSION　　　MIGRATION_VERSION　
----------------　----------------　-----------　-----------------　
E4C0B7CC5E3B76D3　4C224C2252CE2BDD　　　　　　1　　　　　　　　　0　
　
1　record(s)　selected.　

基于此表的描述，这是我预期要看到的内容。此外，有关其余那些表的文档（以及我对消息引擎如何工作的了解）导致我预期消息引擎的其余所有表将由少量的行组成。我通过运行两个测试验证了这一点，一个是同步的，另一个是异步的，测试中持久化和处理了来自数据库中的 5,000,000 多个消息，然后运行 DB2® REORGHK 以确定是否需要数据库重组。下面是 REORGHK 产生的输出：

F1:　100　*　OVERFLOW　/　CARD　<　5　
F2:　100　*　(Effective　Space　Utilization　of　Data　Pages)　>　70　
F3:　100　*　(Required　Pages　/　Total　Pages)　>　80　
　
SCHEMA.NAME　　　　　　　　　CARD　　　OV　　　NP　　　FP　ACTBLK　　TSIZE　F1　F2　F3　REORG　
----------------------------------------------------------------------------------------　
Table:　IBMME0.SIB000　　　　　　48　　　0　　　3　　　3　　　-　　　9936　　0　100　100　---　
Table:　IBMME0.SIB001　　　　　　-　　　-　　　-　　　-　　　-　　　　-　　-　　-　　-　---　
Table:　IBMME0.SIB002　　　　　　-　　　-　　　-　　　-　　　-　　　　-　　-　　-　　-　---　
Table:　IBMME0.SIBCLASSMAP　　　12　　　0　　　1　　　1　　　-　　　984　　0　　-　100　---　
Table:　IBMME0.SIBKEYS　　　　　　3　　　0　　　1　　　1　　　-　　　111　　0　　-　100　---　
Table:　IBMME0.SIBLISTING　　　　3　　　0　　　1　　　1　　　-　　　　90　　0　　-　100　---　
Table:　IBMME0.SIBOWNER　　　　　1　　　0　　　1　　　1　　　-　　　　62　　0　　-　100　---　
Table:　IBMME0.SIBXACTS　　　　　-　　　-　　　-　　　-　　　-　　　　-　　-　　-　　-　---　

毫不奇怪，这里有趣的主要列的标题为 REORG，当执行了表的重组时，其中显示一个“*”。您将注意到此数据库中的表不需要任何维护，即使在处理 5,000,000 个消息以后也是如此。

如果您退一步对此考虑一分钟，应该会觉得这没有什么大惊小怪的。执行数据库重组的原因有两个：

将相关数据紧密组织在一起，以最小化磁盘访问时间。

均匀分布空闲磁盘空间，同样是为了最小化磁盘 I/O。

在 SIBOWNER 表的情况下，由于只有单个行，因此不存在需要试验和紧密放在一起的“相关数据”；不需要重组的原因应该是相对明显的。其他表中的每一个表也仅包含少量的行，同样否定了对维护的需要。甚至是在其中插入和删除消息的 SIB000 表也不需要维护。由于消息引擎在消息到达时（或紧随其后）处理消息，数据库不会增长得非常大，因此不需要维护。

在排水之前先浸湿您的脚趾

虽然说认为消息引擎数据库从不需要维护可能不够严谨，但是我认为您大可以放心地断定并非所有的表都需要进行检查。给定消息引擎数据库中的表的使用情况和特征，只有 SIBnnn 表有可能是要进行改造——对不起，应该是维护——的候选表。在某些情况下，也许是在消息大量涌入或消息引擎出故障期间（假设没有使用 WebSphere Application Server High Availability 实现故障转移），数据库中可能会放置足够多的记录，从而要求进行维护。数据存储中形成消息累积的另一个可能原因是“有害消息”，可以使用此修复程序包对这些消息进行管理。无论原因是什么，我都不能确定我始终会诉诸于排干沼泽地的水。也许我会定期监视水位，在此例中是每晚或每周，并使用以下命令检查 SIBnnn 表：

>DB2　REORGCHK　UPDATE　STATISTICS　ON　TABLE　SIB000　

然后在必要时才执行重组。您也可以选择同时检查除 SIBOWNER 表以外的其他表，而不用停止 WebSphere Application Server 消息引擎——不过，与大多数关系数据库相比较，其他这些表同样仅包含少量的行，因此在绝大多数时间都不需要重组。

虽然我在本讨论中重点将 UDB (DB2) 作为消息引擎数据存储，但是此建议和基本原理同样适用于其他数据库管理器，不过用于监视数据库的工具可能随供应商而异——当然，除非您非常喜欢排干沼泽地！