IBAnalyst: InterBase/Firebirdデータベースから統計情報を正しく取得する方法

Dmitry Kuzmenko、最終更新日 2014-03-31

概要

このドキュメントは、IBAnalyst を使用する場合と使用しない場合の両方で、InterBase/Firebird データベースから統計情報を収集および分析するためのヒントとコツについて説明します。

適切なタイミング、適切な場所

奇妙に聞こえるかもしれませんが、gstat や Services API を使用して統計情報を取得するだけでは十分ではありません。統計情報は、アプリケーションがデータベース内のデータとトランザクションにどのように影響するかを示すために、適切なタイミングで取得する必要があります。統計情報を取得するのに最悪なタイミングは次のとおりです。

リストア直後
-g スイッチなしでバックアップ（gbak -b db.gdb）を行った後
手動スイープ（gfix -sweep）後

また、作業中にデータベースが正常な状態になる瞬間があることも事実です。たとえば、アプリケーションのデータベース負荷が通常より低い場合（ユーザーの起動時、昼食時、または特定のビジネスプロセスの時間帯）などです。

データベースに何か問題があることをどのように検出するのでしょうか？

はい、アプリケーションが完璧に設計されていて、トランザクションとデータを常に正しく処理し、スイープギャップ、多数のアクティブトランザクション、長時間実行されるスナップショットなどを発生させない場合もあります。しかし、通常はそうはいきません。少なくとも、一部の開発者はアプリケーションを同時に2〜3人のユーザーでしかテストしないためです。そのため、作成したアプリケーションを15人以上の同時ユーザーで運用すると、データベースが予期しない動作をする可能性があります。もちろん、マルチユーザーモードは正常に動作する場合もあります。なぜなら、ほとんどのマルチユーザー競合は、2〜3つのアプリケーションを同時に実行してテストできるからです。しかし、さらに多くの同時アプリケーションが実行されると、少なくともガベージコレクションの問題が発生する可能性があります。そして、これは適切なタイミングで統計情報を取得すれば検出できます。

定期的なパフォーマンス問題が発生しない場合

これは、アプリケーションが正しく設計されているか、データベース負荷が低いか、ハードウェアが最新かつ非常に強力（現在のユーザー数とデータを十分に処理できる）である場合に発生します。

最も価値のある情報は、トランザクション負荷とバージョン蓄積です。これは、定期的な統計情報の保存を設定した場合にのみ確認できます。

InterBase には内部タスクスケジューラがないため、標準のタスクスケジューラ（Windows）や cron（Unix）などの外部スケジューラを自由に使用できます。

最適な設定は、1時間ごとにトランザクション統計を取得することです。これは次のコマンドで実行できます。

gstat -h db.gdb >db_stat_.txt

ここで

db.gdb はデータベース名、

db_stat_.txt は統計情報が保存されるテキストファイル、

は統計情報が取得された現在の日時です。

定期的なパフォーマンス問題が発生する場合

これらの問題は通常、自動スイープの実行によって引き起こされます。まず、このようなパフォーマンス低下の間隔を特定する必要があります。次に、この間隔を最小で4（8、16など）に分割します。現在の情報システムには多くの同時ユーザーがおり、サーバーとデータベースが設定されていない場合のパフォーマンス問題のほとんどは、1日に2〜3回発生します。たとえば、パフォーマンス低下が3時間ごとに発生する場合は、次のコマンドで統計情報を取得する必要があります。

gstat -h db.gdb

統計情報は30〜45分ごとに、そして

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

は1〜1.5時間ごとに取得します。

最適なのは、予想されるパフォーマンス低下の直前に gstat -a -r 統計情報を取得することです。これにより、実際のガベージがどこにあるか、および蓄積された古いレコードバージョンの数がわかります。

この統計情報をどうするか

アプリケーションがトランザクションを明示的に使用し、それらを適切に使用している場合、つまり read_committed とは何か、いつ使用するかを理解し、スナップショットトランザクションが必要以上に長く続かず、トランザクションが最小限の時間だけアクティブである場合、スイープ間隔を調整するかオフに設定し、その後はアプリケーションが行う更新の数と、どのテーブルの更新を減らすか、または更新に注意する必要があるかのみを考慮できます。

これはどういう意味か、と尋ねるかもしれません。毎朝20〜30分間パフォーマンス問題が発生したシステムの例を示します。これは「朝の」アプリケーションにとっては非常に十分な時間であり、それ以上続くことはありませんでした。

データベース管理者に適切な質問をしたところ、次のような状況が明らかになりました。

1日の作業はセクションに分かれていました。朝はアナリストが作業し、その後、通常のオペレーターがデータを挿入および編集し、1日の終わりには、翌日（少なくとも）アナリストが使用するデータを収集する特別なプロシージャが開始されました。

1日の終わりのデータベースへの最後の作業は、大量の更新であり、朝にアナリストが使用したテーブルの更新でもありました。そのため、多くのガベージバージョンが蓄積され、朝に実行されるアプリケーションによって収集され始めました。

そして、その問題の解決策は簡単に見つかりました。1日の終わりに gfix -sweep を実行することです。

スイープはデータベース内のすべてのテーブルを読み取り、コミット済みおよびロールバック済みトランザクションのすべてのガベージバージョンを収集しようとします。スイープ後、データベースはリストア直後とほぼ同じようにクリーンになりました。

そして、「朝の問題」は解消されました。

したがって、統計情報を他の多くの要因とともに考慮する必要があります。

日中に作業する同時ユーザー数（平均）
勤務時間の長さ（8、12、16、24時間）
異なる時間帯に実行されるアプリケーションの種類、およびそれらが同じ時間または次に実行される他のアプリケーションによって使用されるデータにどのように影響するか。つまり、1日全体と1週間全体で発生するビジネスプロセスを理解する必要があります。

DBA が何もできない場合

残念ながら、このような状況は発生します。また、例を示します。

約15人のユーザー向けにインストールされたシステムがあります。定期的にパフォーマンスが非常に悪くなり、DBA がサーバーを再起動する必要があります。サーバー再起動後、しばらくはすべて正常に動作しますが、その後再びパフォーマンスが悪化します。統計情報によると、1日の平均トランザクション数は約75,000で、1日の開始からパフォーマンスが低下する瞬間までアクティブなトランザクションが存在していました。

残念ながら、アプリケーションは BDE で記述されており、トランザクションをまったく使用していませんでした。つまり、すべてのトランザクション処理は自動であり、BDE 自体によって使用されていました。これにより、一部のトランザクションが長時間アクティブなままになり、DBA がサーバーを再起動するまでガベージ（レコードバージョン）が蓄積されました。再起動後、自動スイープが実行され、ガベージが収集（削除）されました。

これらはすべてアプリケーションが原因でした。なぜなら、アプリケーションは2〜3人の同時ユーザーでのみテストされており、約15人になると、アプリケーションは非常に高い負荷を発生させ始めたからです。

この構成では、ユーザーの70%がデータを読み取るだけで、残りの30%が一部の（！）データを挿入および更新していたことに注意する必要があります。

この状況でパフォーマンスを改善できる唯一の方法は、アプリケーションを完全に再設計することです。

まだ質問がありますか？ [email protected] までお問い合わせください。