| Firebird Documentation Index → Firebird 2.5 リリースノート → 管理機能 → トレースと監査サービス |
|
|
|
バージョン2.5での新しいトレースと監査の機能は、当初、Nickolay Samofatov氏によってコントリビュートされたTraceAPIから開発されました。これはFirebirdコードをベースとする商業製品Red Soft Database用に彼が開発したものです。
新しいトレースと監査の機能は、SQL文の実行、接続、切断など、エンジン内で実行されるさまざまなイベントのログを取り、照合して、対応するパフォーマンス特性のリアルタイムな分析に使うことができます。
トレースは、トレース・セッションの文脈で起こります。それぞれのトレース・セッションが固有の設定、ステート、出力を持ちます。
Firebirdエンジンはトレース可能なイベントの固定リストを持ちます。システム監査トレースとユーザートレースという、二つの異なる種類のトレースを実行できます。エンジンがどのようにセッション用のイベントのリストを作成するかは、どのトレースが要求されているかによります。
全てのトレースセッションに一意なセッションIDが割り当てられます。任意のトレースセッションが始まると、サービスマネージャはこのIDをメッセージとして出力します。
Trace session ID nnnn started
もちろん、ここでの nnnn はIDです。
システム監査のセッションはエンジン自ら開始します。セッションがどのイベントに“関心を持っている”か決定するため、エンジンはセッションを作成しに行く際にトレース設定ファイルの内容を読みます。
firebird.confの新しいパラメータAuditTraceConfigFileは、ファイルの名前と配置を指示します。進行中のシステム監査トレースは最大で一つとなります。デフォルトでは、このパラメータの値は空で、どのシステム監査トレースも設定されていないことを示しています。
設定ファイルにはトレースされるイベントのリストが含まれ、各イベント用のトレースログの配置を指示しています。異なるイベントのセットがそれぞれ異なるデータベースのログを取り、ログファイルを切り離すことができるというような柔軟さは十分にあります。Firebirdのルートディレクトリ内にあるテンプレートファイルfbtrace.confには、監査トレース設定ファイルを記述するためのフォーマット、ルール、構文とともに、利用可能なイベントの完全なリストが含まれています。
このファイルには各エントリの目的と構文を説明する大量のコメント付きテキストが含まれます。サブリリースを重ねるごとに、トレース性能の改善のため時々新たなイベントと機能が加えられますので、注意して下さい。
例えば、最近のプレリリースでの拡張では、サービスイベントを、名前を使ってトレースしたり、include、excludeフィルタをを使ってターゲットを絞ることができるようになっています。
他の例として、パス名マッチングアルゴリズムの改善により、設定ファイル内の文字列をプラットフォームのキャラクタ・セットに従って翻訳したり、UTF-8の文字列に基づいて、Windowsでは大文字小文字を区別しない、POSIXでは大文字小文字を区別する、というようなファイル名の取り扱い等に関するプラットフォーム固有のルールが適用できるようなっています。（トラッカー・リファレンス CORE-2404、A. dos Santos Fernandes）。
バージョン2.5.2で施された改善では、トレースセッションの設定により、手動・自動スイープ両方の詳細情報についてログを取ることができるようになりました。テンプレートファイルから“SWEEP_”オプションを見つけて下さい。
ユーザートレース・セッションはサービスAPIに対する新しい呼び出しを使ってユーザーが管理します。このための新しいサービス関数は五つあります：
開始：isc_action_svc_trace_start
停止：isc_action_svc_trace_stop
中断：isc_action_svc_trace_suspend
再開：isc_action_svc_trace_resume
既知の全トレースセッションの一覧: isc_action_svc_trace_list
サービスAPI呼び出しの構文については、Firebird APIとODSの変更の章のアプリケーション用の新トレース機能の項で議論されています。
ユーザーアプリケーションがトレースセッションを開始すると、セッション名（オプション）とセッション設定（必須）が付けられます。セッション設定は、出力の配置に関する行は別として、fbtrace.confをテンプレートとするルールと構文に準拠したテキストファイルです。このファイルはFirebirdのルートディレクトリにあります。
これらのファイルはサーバーには残りません。ユーザートレースの要求に応えるためテキストの格納と取得にふさわしい仕組みを設計するのは、アプリケーション開発者の仕事になります。
例えば、コマンドラインユーティリティfbsvcmgrは、セーブファイル・パラメータtrc_cfgをサポートします。
ユーザーセッションの出力は、それぞれ1MBのテンポラリ・ファイルの一群に格納されます。アプリケーションによって一度完全に読み込まれたファイルは、自動的に削除されます。デフォルトでは、ファイルサイズの総計は最大で10MBに制限されています。この値はfirebird.conf内のMaxUserTraceLogSizeを使って小さくも大きくもできます。
アプリケーションによって一度ユーザートレース・セッションのサービスが開始されると、アプリケーションは、isc_service_query()への呼び出しを使ってその出力を読み込む必要があります。このサービスは、アプリケーションが読み込めるより速く出力を生成することがあります。出力のサイズの総計がMaxUserTraceLogSizeの上限に達すると、エンジンは自動的にトレースセッションを中断します。アプリケーションがファイル（出力の1MB分）を読み込み終えるとそのファイルは削除され、容量に余裕が生まれてエンジンはトレースセッションを自動的に再開します。
アプリケーションは、そのトレースセッションの停止を決めると、単にサービスからのデタッチをリクエストします。別の方法として、isc_action_svc_trace_*関数を使うことで、アプリケーションが自由にトレースセッションを中断、再開、停止することもできます。
アタッチメントのキャラクタ・セット名は対応するいずれのトレースログのレコードにも含まれ、user:roleとprotocol:portの間に置かれています。例えば、
A.FDB (ATT_36, SYSDBA:NONE, WIN1251, TCPv4:127.0.0.1)
DPBにキャラクタ・セットが指定されていない場合、アタッチメントのキャラクタ・セットのスロットでトレースログのレコードにNONEが書き込まれます。
どのユーザーでもトレースセッションを始動し、管理することができます。通常のユーザーは、自身の接続についてのトレースだけをリクエストすることができ、他のユーザーが開始したトレースセッションを管理することはできません。管理者はどのトレースセッションでも管理できます。
全てのFirebirdプロセスが停止されると、どのユーザートレース・セッションも保存されません。つまり、スーパーサーバーまたはスパークラシックサーバーのプロセスがシャットダウンされると、resumeを待機していたものを含め、進行中だったユーザートレース・セッションは完全に停止され、resumeもそれらを再開することができません。
もちろん、クラシックサーバーでは、それぞれの接続がそれぞれ専用のサーバー・インスタンスを含むことから、この状況は当てはまりません。そもそも、クラシックサーバー・インスタンスを“シャットダウン”するという事態はありません。どのサービス・インスタンスもそれを引き起こした接続より長生きすることはできません。
以下のサンプルは、ユーザートレース・セッションの設定テキストを記述するための基準を提供します。
接続12345に含まれる全てのSQL文のプリペア、解放、実行をトレースします。
<database mydatabase.fdb>
enabled true
connection_id 12345
log_statement_prepare true
log_statement_free true
log_statement_start true
log_statement_finish true
time_threshold 0
</database>
実行されたINSERT、UPDATE、DELETE文と、プロシージャとトリガへのネストされた呼び出しのログを取りつつ、データベースmydatabase.fdbへの所定のユーザーの全ての接続をトレースし、対応するPLANとパフォーマンスの統計を示します。
<database mydatabase.fdb>
enabled true
include_filter %(INSERT|UPDATE|DELETE)%
log_statement_finish true
log_procedure_finish true
log_trigger_finish true
print_plan true
print_perf true
time_threshold 0
</database>
トレースサービスと対話的に動作する新しいコマンドラインユーティリティfbtracemgrが追加されました。これはスイッチとパラメータに独自の構文を持ちます。実例も含めた詳細はユーティリティの章で議論されています。
さらに、サービスユーティリティfbsvcmgrは、コマンドラインからのサービスリクエストの送信に使うことができます。以下に例を示します。
fbtrace.confという名の設定ファイルを使って“My trace”と名づけたユーザートレースを開始し、画面上でその出力を読む。
fbsvcmgr service_mgr action_trace_start trc_name "My trace" trc_cfg fbtrace.conf
このトレースセッションを停止するには、fbsvcmgrコンソールプロンプトでCtrl+Cを押します。（下記(e)も参照）。
トレースセッションを一覧する：
fbsvcmgr service_mgr action_trace_list
ID 1のトレースセッションを中断する
fbsvcmgr service_mgr action_trace_suspend trc_id 1
ID 1のトレースセッションを再開する
fbsvcmgr service_mgr action_trace_resume trc_id 1
ID 1のトレースセッションを停止する
fbsvcmgr service_mgr action_trace_stop trc_id 1
他のコンソールでセッションの一覧を得て（b参照）、関心あるセッションのIDを探し、現在のコンソールでそれを使ってそのセッションを停止します。
トラッカー・リファレンス CORE-2588
Windowsでは、異なるWindowsセッションの複数のエンジン・インスタンスがグローバル名前空間でのtraceの起動を許可してしまうと、トレースツールは共有メモリの競合を引き起こします。そのため、トレーススコープは、現在のWindowsセッションからアクセス可能なプロセスだけに限定されています。
一般に三つの場合が考えられます：
エンジン活動の常時監査
システム監査トレースを使います。管理者はトレース設定ファイルを作成・編集し、firebird.conf内にあるAuditTraceConfigFileの設定を介してその名前を決め、Firebirdを再起動します。その後、管理者がこのセッションを中断、再開、停止するのにFirebirdを再起動する必要はありません。
監査設定の変更をエンジンに通知するには、Firebirdを再起動する必要があります。
一部（または全部）のデータベースの一部（または全部）の活動に対するオンデマンドな対話的インタラクティブ・トレース
アプリケーション（fbtracemgrユーティリティでも可）がユーザートレース・セッションを開始し、その出力を読み込み、トレースしたイベントをリアルタイムで画面に表示します。ユーザーはそのトレースを中断・再開することができ、最終的にそれを停止することもできます。
重要な期間（数時間または終日ということも）のエンジン活動を収集し後で分析する
アプリケーションがユーザートレース・セッションを開始し、トレースの出力を定期的に読み込み、一つまたは複数のファイルに保存します。そのセッションの停止はその同じアプリケーションか別のアプリケーションによって手動で行う必要があります。複数のトレースセッションが起動している場合、関心あるセッションを特定するため一覧の取得が求められることがあります。
新しいトレースAPIは外部プラグインモジュールとして実装可能なフックのセットを提供します。これらは、トレースされる任意のイベントの発生時にエンジンから呼び出されます。こうしたイベントで適宜ログを取る役割はプラグインが担うことになります。
このトレースAPIはFirebird 2.5に含まれおり、使用することもできますが、今後のサブリリースでの変更が予定されておりますので、正式なものではなく、unstableと見て下さい。
実装された“標準の”トレースプラグインfbtrace.dll (.so)は、Firebird 2.5がインストールされたディレクトリ内の\pluginsフォルダの中にあります。
|
| Firebird Documentation Index → Firebird 2.5 リリースノート → 管理機能 → トレースと監査サービス |