お問い合わせ
IBSurgeon
このページは機械翻訳されています。英語の原文をお読みください。 English

IBSurgeon ライブラリ

IBAnalyst: サマリービューで確認できる内容

Dmitry Kuzmenko、最終更新日：2014年3月31日

概要

このドキュメントは、IBAnalystの「サマリービュー」ページの情報の説明と、その情報を独自のデータベース統計のために解釈する方法に焦点を当てています。また、InterBase統計の詳細を学習しやすくするために、インストールパッケージにいくつかの統計例を追加しました。これらはIBAnalystインストールのExamplesディレクトリにあります。

Oldest transaction、Oldest snapshot、active、Nextが何かわからない場合は、先にCraig Stunzの記事「Understanding Transactions Lifetime」をお読みください：

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

トランザクション番号

「Understanding Transaction Lifetimes」の記事を読んだ場合でも、OIT/OST/OAT番号について疑問が残るかもしれません。以下に簡単な説明を示します：
番号 保持される状況、… 前進する状況、…
Oldest transaction この番号のトランザクションがロールバックされ、その中で大量のデータ変更があった場合、またはクライアント接続が失われた場合 自動または手動のスイープが成功したとき
Oldest Snapshot スナップショット（またはIB 7.1より前のread committed write）が長時間アクティブな場合（最も古いアクティブなスナップショットをローカルOSTとして記憶） 新しいトランザクションが開始され、OSTを保持しているトランザクションが終了したとき
Oldest Active この番号のトランザクションが長時間アクティブな場合 新しいトランザクションが開始され、OATを保持しているトランザクションが終了したとき
Next 決して 新しいトランザクションが開始されたとき

注：ここでのOldest transactionは、他の多くの記事で言及されているOldest Interesting Transaction（OIT）と同じです。

標準設定での良好な統計

IBAnalystを起動し、（Statistics/Load statistics from fileメニューから）ファイル !allok.txt を開きましょう。

IBAnalystはデータベースの作成日付を報告するだけでなく、統計がServices APIを介して取得された場合はサーバーの現在の日時を、統計ファイルが読み込まれた場合はファイルの日時を認識します。

そのため、統計ファイルを変更しないことをお勧めします。この場合、IBAnalystは1日あたりの平均トランザクション数を誤って計算するためです。ここでの1日あたりのトランザクション行は、約12,500トランザクション/日を示し、そのデータベースは作成または復元から8日間「生存」しています。

Oldest、Oldest snapshot、Oldest active、Nextトランザクションはここでは完璧な状態にあり、常にこのような統計になることを願っています。

多数のアクティブなトランザクション

次に、ファイル !lotofactive.txt を開きます（いつでも !allok の画像を見返して、以下の例と比較できます）。

ここでは、Active transactions行が赤でマークされています。これは、Oldest activeとNextトランザクションの間に大きな差があるためです。これは、統計が取得された時点で一部のトランザクションがまだアクティブであり、その開始後に55,000のトランザクションがすでに開始されている（アクティブ、コミット済み、ロールバック済みのいずれの状態でもあり得る）ことを意味します。1日あたりの平均トランザクション数が約12,500であるため、IBAnalystは一部のトランザクションが4.4日間生存しているという警告を表示します。これは次の場合に発生する可能性があります：

  • 一部のアプリケーションがまだ実行中で、少なくとも1つのトランザクションが開いている - 一部のユーザーがアプリケーションを長時間実行し続けている可能性があります
  • アプリケーションが長時間実行され、トランザクションハンドルを失う - つまり、コード（または使用しているコンポーネント/ライブラリ）が動的にトランザクションを開始し、特定の状況下でロールバックやコミットで終了するのを「忘れる」
  • アプリケーションが明示的なトランザクション（BDE）を使用せず、トランザクション処理を使用中のコンポーネントに任せている。その結果、トランザクションの寿命はアプリケーションによって制御されず、Next-OATトランザクションのほとんどが実際にアクティブであると確信できます。
  • アプリケーションが「デフォルトトランザクション」を許可するドライバーまたはコンポーネントを使用している。コードがこのトランザクションを制御しない場合、非常に長い時間実行される可能性があります。

残念ながら、統計は現在アクティブなトランザクションの実際の数を示しません。これはInterBase 7.xではIBConsole、IB Performance Monitor、またはtmp$transactions一時システムテーブルへの直接クエリでのみ表示できます。Firebird 1.5では、isc_info_active_transactionsパラメータを指定してisc_database_infoを呼び出すことができます。

スイープ

次に !needsweep.txt を開きましょう。

スイープはInterBase内部のハウスキーピングプロセスです。スイープはデータベース内のすべてのレコードを走査し、すべてのガベージバージョンをクリーンアップしようとし、次にOldest transaction番号を引き上げようとします。新しく作成されたデータベースでは、スイープ間隔はデフォルトで20000です。トランザクション間の差（以下の表を参照）がスイープ間隔より大きくなると、スイープが自動的に実行されます。これにより、データベースで定期的なパフォーマンス低下が見られることがあります。たとえば、アプリケーションが月曜日と火曜日は正常に動作しますが、水曜日にユーザーが数時間のパフォーマンス問題を報告し、その後パフォーマンスが再び正常になります。

同様の動作が見られる場合、それは自動スイープです。
サーバーバージョン スイープが実行される条件
InterBase 7.x (Oldest Active - Oldest) > スイープ間隔
InterBase 4.x、5.x、6.x、Firebird 1.5.2より前、Yaffil (Oldest Snapshot - Oldest) > スイープ間隔

表1. 自動スイープが実行される条件

注：IBAnalystはすべてのバージョンで正しいスイープギャップ情報を自動的に表示します。IBAnalystはODS IDによってのみサーバー実装の違いを検出できます。たとえば、InterBase 7.xはODS 11.x、他の最新サーバーはODS 10.xです。Interbase 7.xデータベース（ODS 11）のみを扱う場合は、Optionsダイアログで適切なオプションを切り替えることができます。

データベースのスイープ間隔が<> 0の場合、IBAnalystは基本的にこの行を黄色でマークします（自動スイープが予期しない瞬間に開始される可能性があることを警告します）。一般的に、全アプリケーションの60%が自動スイープに問題を抱えています。この問題を回避する最も簡単な方法は、スイープ間隔を0に設定することです。これにより自動スイープがオフになります。ただし、一部のアプリケーションが大量の変更を行ってからロールバックすると、Oldest transactionは凍結され、スイープが実行されるまで前進しません。有効なトランザクション状態はOldestからNextトランザクションまでで計算されるため、この距離は大きくなり、パフォーマンスが低下します。これを防ぐには、スイープを手動で実行する必要があります（gfix -sweep）。この画像では、スイープ間隔が0で大きなトランザクションがロールバックされた場合の動作が見られます：

ここでスイープギャップ値は、大きな（多くの変更を行った）トランザクションが約4.5日前にロールバックされたことを示しています。毎日手動でスイープを実行することをお勧めします。

もちろん、前述の60%のアプリケーションでは、スイープ間隔を20000より大きくまたは小さく設定する方が良い場合もありますが、これは多くの要因（たとえば1日のトランザクション数もその1つ）に依存し、実験的な方法でのみ理解できます。したがって、スイープ間隔を0に設定すれば、予期しない瞬間に自動スイープが実行されないことを確信できます。

同じ画像は !rollback.txt ファイルでも確認できます。

注：自動スイープが実行されている場合、大きなデータベースや多くのガベージレコードバージョンがあるデータベースでは、スイープの動作中にSnapshot、Active、Nextトランザクションが前進し、スイープが次のトランザクション開始時に再び開始される可能性があります。

スイープが機能しない場合

スイープがOldest transactionを引き上げられないケースは多数あります。もちろん、スイープはまずその作業を実行しようとします。つまり、データベース内のすべてのレコードをチェックし、不要なレコードバージョンを収集します。しかし、次の場合には成功せずに何度も実行されます：

スイープ実行中に問題が発生した場合：スイープ中にサーバーが停止した、またはガベージレコードバージョンのクリーンアップ中にエラーが発生した。さらに、次の場合にもこの画像が見られます：

  • スイープが動作中に統計が取得された

  • スイープが実行され、継続的に更新されているテーブルのガベージを収集しようとしている。これは更新が終了するまで続く可能性があります。

  • 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] 联系我们