IBAnalyst：如何以正确方式获取InterBase/Firebird数据库的统计信息

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

摘要

本文档致力于介绍从InterBase/Firebird数据库中收集和分析统计信息的技巧与诀窍，无论是否使用IBAnalyst。

正确的时间，正确的地点

听起来可能有些奇怪，但仅仅通过gstat或Services API获取统计信息是不够的。统计信息必须在正确的时刻获取，才能显示应用程序如何影响数据库中的数据和事务。获取统计信息最糟糕的时机是：

恢复之后立即获取
备份（gbak -b db.gdb）未使用-g开关之后获取
手动清理（gfix -sweep）之后获取

同样正确的是，在工作过程中可能存在数据库处于正确状态的时刻，例如，当应用程序对数据库的负载低于平时（用户启动时、午餐时间或特定业务流程时间）。

如何捕捉数据库中何时出现问题？

是的，您的应用程序可能设计得非常完美，以至于它们始终能正确处理事务和数据，不会产生清理间隙、大量活动事务、长时间运行的快照等问题。但通常情况并非如此。至少因为一些开发人员只测试了2-3个同时运行的用户，而不是更多。因此，当他们为15个或更多同时运行的用户部署编写的应用程序时，数据库可能会表现出不可预测的行为。当然，多用户模式可以正常工作，因为大多数多用户冲突可以通过2-3个并发运行的应用程序进行测试。但是，接下来，当更多并发应用程序运行时，垃圾回收问题可能会出现（至少如此）。如果您在正确的时刻获取统计信息，就可以捕捉到这一点。

如果您没有遇到周期性的性能问题

这种情况可能发生在您的应用程序设计正确、数据库负载较低，或者您的硬件现代且非常强大（足以很好地处理当前用户数量和数据）时。

最有价值的信息是事务负载和版本累积。只有设置定期保存统计信息，才能看到这些。

InterBase没有内部任务调度器，因此您可以自由使用任何外部调度器，如标准任务计划程序（Windows）或cron（Unix）。

最佳设置是每小时获取一次事务统计信息。可以通过运行以下命令实现：

gstat -h db.gdb >db_stat_.txt

其中：

db.gdb 是您的数据库名称，

db_stat_.txt 是保存统计信息的文本文件，

- 是获取统计信息时的当前日期和时间。

如果您遇到周期性的性能问题

这些问题通常由自动清理运行引起。首先，您需要确定此类性能问题之间的时间间隔。接下来，将此间隔至少分成4份（8、16等）。现在信息系统有很多并发用户，大多数未配置服务器和数据库的性能问题每天发生2或3次。例如，如果性能问题每3小时发生一次，您需要每30-45分钟获取一次

gstat -h db.gdb

统计信息，并每1-1.5小时获取一次

gstat -a -r db.gdb -user SYSDBA -pass masterkey

最佳做法是在即将发生的性能问题之前获取gstat -a -r统计信息。它将显示真正的垃圾在哪里以及累积了多少过期的记录版本。

如何处理这些统计信息

如果您的应用程序明确使用事务并且使用得当，即您知道什么是read_committed以及何时使用它，您的快照事务持续时间不超过必要时间，事务活动时间最短，那么您可以调整清理间隔或将其关闭，然后只需关注应用程序进行了多少更新以及哪些表需要减少更新或关注更新。

您可能会问，这意味着什么？我们举一个系统的例子，该系统每天早上都会出现20-30分钟的性能问题。这对“早晨”应用程序来说非常明显，且不会持续更长时间。

数据库管理员被问了正确的问题，情况如下：

日常工作按部门划分–分析师在早上工作，然后数据由普通操作员插入和编辑，在一天结束时，特殊程序开始收集数据，这些数据将在第二天（至少）用于分析。

一天结束时对数据库的最后操作是大量更新，并且更新的是分析师早上使用的那些表。因此，存在大量垃圾版本，这些版本开始由早上运行的应用程序收集。

而这个问题的答案很简单–在一天结束时运行gfix -sweep。

清理会读取数据库中的所有表，并尝试收集已提交和回滚事务的所有垃圾版本。清理后，数据库几乎恢复到恢复后的状态。

于是，“早晨问题”消失了。

因此，您需要考虑统计信息以及许多其他因素：

白天平均有多少并发用户（平均）在工作
工作日有多长（8、12、16、24小时）
不同时间段运行什么类型的应用程序，以及它们如何影响其他应用程序（同时或随后运行）使用的数据。即，您必须了解整个白天和整个星期发生的业务流程。

当DBA无能为力时

遗憾的是，这种情况确实会发生。再次举例：

某个系统为约15个用户安装。性能周期性地变得非常糟糕，以至于DBA需要重启服务器。服务器重启后一切正常一段时间，然后性能再次变差。统计信息显示，平均每日事务数约为75,000，并且从一天开始到性能下降时，一直有活动事务在运行。

不幸的是，应用程序是用BDE编写的，完全没有使用事务；即所有事务处理都是自动的，由BDE本身使用。这导致一些事务长时间保持活动状态，垃圾（记录版本）不断累积，直到DBA重启服务器。重启后自动清理运行，垃圾被收集（消除）。

所有这些问题都是由应用程序引起的，因为它们只测试了2-3个并发用户，当用户数达到约15时，应用程序开始产生非常高的负载。

需要说明的是，在该配置中，70%的用户只读取数据，另外30%的用户插入和更新一些（！）数据。

在这种情况下，唯一能改善性能的方法是彻底重新设计应用程序。

还有问题吗？请通过 [email protected] 联系我们。