联系方式
IBSurgeon
此页面为机器翻译。请阅读英文原文。 English

IBSurgeon 文库

IBAnalyst：您在摘要视图中可以看到什么

Dmitry Kuzmenko，最后更新于2014年3月31日

摘要

本文档旨在解释IBAnalyst“摘要视图”页面上的信息，以及如何为您的数据库统计信息解读这些内容。此外，我们在安装包中添加了几个统计示例，以方便您研究InterBase统计的所有细节。它们位于IBAnalyst安装目录的Examples文件夹中。

如果您不了解什么是Oldest transaction（最旧事务）、Oldest snapshot（最旧快照）、active（活动）和Next（下一个），请先阅读Craig Stunz的文章《理解事务生命周期》：

http://blogs.teamb.com/craigstuntz/articles/UnderstandingTransactionLifetimes.aspx

事务编号

如果您已经阅读了《理解事务生命周期》一文，可能仍然对OIT/OST/OAT编号有疑问。以下是简要说明：
编号 保持，… 向前移动，…
最旧事务 当具有此编号的事务被回滚，且其中包含大量数据更改时，或客户端连接丢失时 当自动或手动清理成功时。
最旧快照 当快照（或IB 7.1之前的读提交）长时间处于活动状态时（它记住最旧的活动快照作为其本地OST） 当新事务启动时，如果持有OST的事务已结束
最旧活动 当具有此编号的事务长时间处于活动状态时 当新事务启动时，如果持有OAT的事务已结束
下一个 从不 当新事务启动时

注意：此处的最旧事务与许多其他文章中提到的Oldest Interesting Transaction（OIT）相同。

标准设置下的良好统计

让我们启动IBAnalyst并打开（通过Statistics/Load statistics from file菜单）文件!allok.txt。

IBAnalyst不仅报告数据库创建日期，如果统计信息是通过Services API获取的，它还会识别服务器上的当前日期时间；如果是加载的统计文件，则识别文件日期时间。

这就是为什么我们建议不要修改统计文件，因为在这种情况下，IBAnalyst将无法正确计算每天的平均事务数。这里的每天事务数行显示每天约12500个事务，并且该数据库自创建或恢复以来已运行8天。

这里的Oldest、Oldest snapshot、Oldest active和Next事务处于完美状态，希望您的统计信息始终看起来如此。

大量活动事务

接下来，打开文件!lotofactive.txt（您可以随时回看!allok图片以比较以下示例）。

这里的Active transactions行被标记为红色，因为Oldest active和Next事务之间存在较大差异。这意味着在获取统计信息时，某个事务仍然处于活动状态，并且在其启动后，已有55,000个事务启动（它们可能处于任何状态–活动、已提交、已回滚）。由于每天的平均事务数约为12,500，IBAnalyst会向您显示警告，提示某个事务已持续活动4.4天。这可能发生在以下情况：

  • 某个应用程序仍在运行，并且至少有一个事务处于打开状态–某些用户可能让应用程序长时间运行
  • 应用程序长时间运行并丢失事务句柄–即您的代码（或您使用的组件/库）动态启动事务，并在某些情况下“忘记”通过回滚或提交来结束它们。
  • 您的应用程序不使用显式事务（BDE），将事务处理留给所使用的组件。因此，事务生命周期不受应用程序控制，您可以确信大多数Next-OAT事务实际上是活动的。
  • 您的应用程序使用允许“默认事务”的驱动程序或组件。如果您的代码不控制此事务，它可能会运行很长时间。

遗憾的是，统计信息不显示当前活动事务的实际数量。这只能在InterBase 7.x中通过IBConsole、IB Performance Monitor或直接查询tmp$transactions临时系统表来查看。在Firebird 1.5中，您可以调用isc_database_info并传入isc_info_active_transactions参数。

清理（Sweep）

现在让我们打开!needsweep.txt。

清理是InterBase内部的一个维护过程。清理会遍历数据库中的所有记录，尝试清理所有垃圾版本，然后尝试向前移动最旧事务编号。在新创建的数据库中，默认清理间隔为20000。当事务之间的差异（见下表）大于清理间隔时，清理将自动运行。因此，您可能会看到数据库出现周期性的性能下降。例如，您的应用程序在周一和周二运行正常，但到了周三，用户会报告性能问题持续数小时，然后性能又恢复正常。

如果您看到类似行为–那就是自动清理在运行。
服务器版本 清理运行时机
InterBase 7.x (最旧活动 - 最旧) > 清理间隔
InterBase 4.x、5.x、6.x、Firebird 1.5.2之前版本、Yaffil (最旧快照 - 最旧) > 清理间隔

表1. 自动清理运行的条件

注意：IBAnalyst会自动为所有版本显示正确的清理间隔信息。IBAnalyst只能通过ODS ID来区分服务器实现，例如，InterBase 7.x具有ODS 11.x，其他现代服务器具有ODS 10.x。如果您只使用InterBase 7.x数据库（ODS 11），可以在Options对话框中切换相应选项。

当您的数据库清理间隔<> 0时，IBAnalyst基本上会将此行标记为黄色（警告您自动清理可能在任何不可预测的时刻启动）。一般来说，60%的应用程序都存在自动清理问题。避免此问题的最简单方法是将清理间隔设置为0，这将关闭自动清理。但是，如果某个应用程序进行了大量更改然后回滚，最旧事务将冻结，并且在运行清理之前不会向前移动。由于有效事务状态是从最旧到下一个事务计算的，这个距离会增长，性能会下降。为防止这种情况，您必须手动运行清理（gfix -sweep）。在此图片中，您可以看到清理间隔为0且存在大型事务回滚时的行为：

这里的清理间隔值显示，某个大型（进行了大量更改）事务大约在4.5天前被回滚。我们建议您每天手动运行清理。

当然，对于上述提到的60%应用程序，也许将清理间隔设置为大于或小于20000更好，但这取决于许多因素（例如，每日事务量是其中一个因素），只能通过实验方式来确定。因此，如果您将清理间隔设置为0，可以确保清理不会在不可预测的时刻自动运行。

您可以在!rollback.txt文件中看到相同的图片。

注意：如果清理正在自动运行，对于大型数据库或包含大量垃圾记录版本的数据库，Snapshot、Active和Next事务可能会在清理工作时向前移动，并且清理可能会在最近的事务启动时再次开始。

清理无法完成工作的情况

有许多情况会导致清理无法将最旧事务向前移动。当然，清理首先会尝试完成其工作，即检查数据库中的所有记录并收集不需要的记录版本。但如果出现以下情况，它会一次又一次地运行而无法成功：

清理运行时出现了问题：服务器在清理期间被停止，或者在垃圾记录版本清理过程中出现错误。此外，您还可能在以下情况下看到此图片：

  • 统计信息是在清理工作时获取的

  • 清理正在运行，并试图为正在持续更新的表收集垃圾。这可能会持续到更新结束。

  • sweep 因页面锁而停滞，因为有大量用户正在处理数据。

通常，在数据库高负载期间，sweep 没有机会完成。通常当性能下降到无法继续正常工作时，DBA 会重启服务器，sweep 会在第一个用户连接时运行。由于其他用户连接还需要一些时间，sweep 将有时间完成其工作。

由于 InterBase 7.1/7.5 计算 Sweep gap 的方式与之前版本不同，另一种 sweep 无法完成工作的情况是某些应用程序有长时间运行的快照事务：

这里有两个警告–一个（黄色）关于长时间运行的快照，另一个（红色）关于 Sweep interval 和 Sweep gap。

长时间运行的快照

上图指示了 InterBase 7.1/7.5 中的长时间运行快照。如果 Sweep interval 设置为 0，则不会有红色警告，只有黄色警告。类似的图片将指示其他 InterBase、Firebird 和 Yaffil 版本中的长时间运行快照事务：

如您所见，Sweep gap 是根据 Oldest Snapshot 和 Oldest transaction 之间的差异计算的（对于 ODS 10，即 IB7.x 之前的版本）。因此没有 sweep 警告（除了默认的 sweep interval）。

但是，并非只有快照事务会以这种方式影响事务状态。除 InterBase 7.1/7.5 之外的所有 InterBase、Firebird 和 Yaffil 版本都有以下行为，我们称之为“read committed 伪影”。

再次讨论快照以及 ReadCommitted 冻结 Oldest Snapshot 的情况

打开 !snapshot2.txt。：

请注意，Oldest transaction 大于 Oldest snapshot。并且 Sweep gap 为负值。这可能在两种情况下发生。第一种情况是存在一些快照事务一个接一个地开始和提交。即，此图片可能与上一张图片一样发生在快照情况下。下一种情况仅发生在除 IB 7.1/7.5 之外的服务器上，涉及 ReadCommitted 事务（或 ReadCommitted 与 Snapshot 事务的组合）。它们可以像 Snapshot 事务一样锁定 Oldest Snapshot 编号。当前事务状态可以通过以下序列模拟：

  1. 启动事务 1，snapshot 或 read_committed

  2. 启动/提交一些 read_committed 事务

  3. 启动事务 2，snapshot 或 read_committed

  4. 启动/提交一些 read_committed 事务

  5. 提交事务 1

（当然，我们这里讨论的是 read_committed 写事务，而不是只读事务）。

此时，当前活动的事务 2（snapshot 或 read committed），在快照 1（标记 3）之后启动，将保持快照编号作为 Oldest Snapshot（如果您使用 IB 7.1/7.5，这只能发生在并发快照事务中。read_committed 或 read_committed+snapshot 不会产生此效果）。由于没有大的回滚，Oldest transaction 向前移动，并变得大于 Oldest Snapshot。

现在，如果您有长时间运行的 read committed 事务，您将看到这样的图片。遗憾的是，您在这里对应用程序无能为力（除了为只读事务添加“read”参数）。当然，在这种情况下，sweep 不会自动运行（如果设置为 <> 0）。

注意：此行为将在 Firebird 2.0 中修复

绝对视图和相对视图

默认情况下，IBAnalyst 根据事务绝对值的百分比填充事务行。即，100% 是从 0 到 Next transaction。有时，当数据库长时间运行时，您会看到事务信息如下：

虽然事务很多，但 snapshot、active 和 oldest 之间的差异看起来非常小（接近 98%）。为了使情况更清晰，请打开 Options 对话框，Transactions 选项卡，并勾选“Relative (from oldest) bars %”选项（如果您使用旧式视图（没有图形条），则无法设置此复选框）。按 OK 按钮后，事务视图将变为：

现在您可以在相对视图中看到事务差异（100% 是从 Oldest（或 snapshot）事务到 Next，而不是从 0）。更容易理解当前情况并查看警告（如果有）。

此视图将一直保持，直到您通过 Options 对话框取消勾选。您可以通过 Oldest Transaction 或 Oldest snapshot 行来了解您正在查看的视图–在相对视图中，这些行之一永远不会填充绿色。在绝对视图中，它总是被填充（当然，是部分填充）。

仍有疑问？请通过 [email protected] 联系我们