Zen は使いやすく、また最小限の管理で利用できるようになっています。しかし、Zen 環境のさまざまな状況やリソースについて監視することもできます。たとえば、アプリケーションの一部を調整したり、データベースに関するさまざまなパフォーマンス面を監視したりする必要があるかもしれません。あるいは、ビジネス ニーズに応じて Zen の各種設定を調整しており、デフォルト設定からの変更を監視することもできます。

以下のトピックで監視について説明します。

Monitor ツールではデータベースの状態を監視することができます。次の項目について監視が可能です。

Monitor を初めて使用する場合、またはこのツールの概要を知りたい場合は、Monitor の概要を参照してください。

Monitor はデータベース エンジンの特定の動作と属性を体系的に監視することができるツールです。このツールでは、データベース管理およびアプリケーションのプログラムの診断に役立つ情報を提供します。これは MicroKernel エンジンおよびリレーショナル エンジンのどちらの状況も監視できます。

Monitor には次の 2 つのインターフェイスがあり、いずれも同じ機能を提供します。

ZenCC には、情報を一連のタブ形式で構成して表す Monior ツールが含まれています。タブの配置は必要に応じて変えることができます。タブ内のデータ列も配置を変えたり並べ替えたりすることができます。ある特定の時点のスナップショットを表示し、その情報は手動または自動でリフレッシュすることができます。

ZenCC 内で、Zen エクスプローラーから Minitor にアクセスできます。

Monitor ウィンドウを開くには、以下のオプションのうちの 1 つを使用します。同時に複数のエンジンの監視を行うこともできます。

Monitor の初期設定は、Monitor 自体または ZenCC のどちらからでも設定できます。Monitor では、［ウィンドウ］>［設定］の順に選択し、［設定］ダイアログ下で［Server Monitor］タブ ページを開きます。ZenCC では、［ウィンドウ］>［設定］>［Zen］>［Server Monitor］を選択します。

設定できる初期設定には 2 つのタイプがあります。1 つは、Monitor ユーザー インターフェイスのレイアウト設定です。Monitor を次回開くとき、今回のタブの配置を復元するよう設定できます。これはアクセスするサーバーごとに設定できます。もう 1 つは、特定のグリッドに対する機能の設定です。列幅、ソート順、列の順序などの機能について設定できます。別のサーバーでその特定のグリッドを開いた場合、そのグリッドにも同じ設定が適用されます。このため、異なるサーバーで同じグリッドを簡単に比較することができます。

Monitor の情報は、指定した間隔または必要に応じて随時リフレッシュすることができます。また、リフレッシュを行わないようにすることもできます。短い間隔で多くのウィンドウをリフレッシュすると、パフォーマンスが低下する可能性があるので注意してください。

タブは、必要に応じて配置を変更したり、分離させたり、また再び一体化したりすることができます。タブを移動させるには、そのタブ ラベル上にカーソルを置いてマウスの左ボタンを押したまま、目的の位置へ移動します。

タブによってデータの性質が異なるため、実行できる操作もタブごとに異なります。これらの操作は、タブ ラベル行の右端に表示されるアイコンによって実行されます。次の表ではこのアイコンについて説明しています。

［アクティブ ファイル］では、現在開いている MicroKernel ファイルについての情報を提供します。監視する列を選択する方法については、表示する列の選択を参照してください。

アクティブ ファイルのハンドル情報を見ることができます。ハンドルを表示/非表示を参照してください。アクティブ ファイルのハンドルには以下の情報が含まれます。

［MicroKernel セッション］タブでは、MicroKernel エンジンに対する現在の接続情報を提供します。監視する列を選択する方法については、表示する列の選択を参照してください。

MicroKernel セッションのハンドル情報を見ることができます。ハンドルを表示/非表示を参照してください。MicroKernel セッションのハンドルには以下の情報が含まれます。

［リソース使用状況］タブでは、エンジンが最後に起動してから現在まで MicroKernel によって使用されているリソースを表示します。監視する列を選択する方法については、表示する列の選択を参照してください。

データベース エンジンは、これらのリソースのうちいくつかの最大値を動的に制御します。ユーザー数、セッション数および使用中データの最大値は製品ライセンスによって決まります。『Zen User's Guide』のライセンス モデルを参照してください。

たとえば、ユーザー数は Cloud Server には適用されません。このため、Cloud Server が監視される場合は、［ユーザー数］の［現在値］、［ピーク値］および［最大値］には "n/a" が表示されます。同様に、Zen サーバーが監視される場合は、［セッション数］と［使用中データ MB］の［最大値］には "n/a" が表示されます。

Cloud Server の使用を検討されている場合、［使用中データ MB］の現在値やピーク値の予測が必要です。そのため、それらの統計情報はサーバーでも表示されますが、実施はされません。これらの統計情報については、その値に関わらず通知は送信されません。

次の表では、使用状況の監視の対象となるリソースの種類を示しています。

［MicroKernel 通信統計情報］タブでは、MicroKernel エンジンとの通信に関する情報を表示します。これは、通信統計情報セクションとリソース使用状況情報セクションに分かれています。通信統計情報は、データベース エンジンの起動時から現在までに処理された回数の合計が計算されています。

監視する列を選択する方法については、表示する列の選択を参照してください。

 

リソース使用状況情報では、リソース発生回数の現在値、ピーク値、および最大値を提供します。

［SQL アクティブ セッション］タブでは、リレーショナル エンジンに対する現在の接続情報を提供します。このタブでは、SQL セッションの削除も行えます。選択したセッションの削除を参照してください。監視する列を選択する方法については、表示する列の選択を参照してください。

以下のトピックでは、Monitor のコマンド ライン バージョン bmon について説明します。

bmon コマンド ライン ツールは、Zen でサポートされる Windows、Linux および Raspbian プラットフォームで実行します。この実行可能プログラムは、bmon.exe（Windows の場合）および bmon（Linux ベースのシステムの場合）です。Windows システムの場合、このツールは Zen インストール ロケーションの bin ディレクトリにあります。Linux システムの場合、このツールは /usr/local/actianzen/bin にあります。

bmon は構成ファイルに基づいてサーバー設定を管理します。Zen はデフォルトの設定ファイル monconfig.txt を Zen のインストール先の bin ディレクトリに用意しています。ファイル内の各設定の説明はコメントに記載されています。

bmon からの出力をコンソールおよびログ ファイルのいずれか、または両方にリダイレクトすることができます。設定ファイルで出力先を指定することができます。たとえば、アプリケーションは、コンソールやログ ファイルで特定の状態を調べてから適切な対応をとることができます。Zen v15 では、-runonce オプションで JSON 出力がサポートされるようになりました。

-runonce パラメーターは省略可能です。省略した場合、bmon は設定ファイルで指定された設定を使用します。サンプル ファイルの monconfig.txt では、リフレッシュ レート（refreshrate）の初期値は 5 秒に設定されています。bmon の実行中、いつでも手動で終了することができます。終了には Q（または q） + Enter キーを使用します。

リフレッシュ レートが 0（ゼロ）の場合、bmon はキーボードのキー応答があるまで停止します。設定ファイルのリフレッシュ レート設定（refreshrate）により、停止する時間を指定します。

データベースが頻繁に使用される状態が続くと、その間にレコードの作成、更新、または削除が繰り返し行われるので、データが断片化され、ファイルへのアクセスやトランザクションの応答に時間がかかるようになることがあります。この場合の断片化とはデータ ファイル内で起こるものであり、ハード ディスク上のファイル システムの断片化とは異なります。開発者またはデータベース管理者であれば、ファイルの集中使用から判断してファイルがいつ断片化されやすいかはご存知でしょうが、システムによってはその断片化のタイミングを推測している（断定できない）かもしれません。

Defragmenter は、データの断片化を検出し、それを修正することでこの問題を解決するツールです。最適化は、データ ファイル内でレコードの再配置やインデックスの再構築を行ったり、未使用領域を除去したりして、再びデータへ効率よくアクセスできるようにします。ファイルの最適化によってそのファイルのデータが変更されることはありません。また、ファイルの最適化中でもレコードの作成、読み取り、更新または削除が可能です。ほとんどの場合、Defragmenter の機能を使用するためにダウンタイムを設ける、または業務を停止する必要はなく、データベース エンジンの実行中にもこの機能を使用することができます。

Defragmenter は Zen Control Center から開くことができるグラフィカル ツールの 1 つです。このツールでは、使用中のデータ ファイルと、その読み取り/書き込み回数が表示されるので、頻繁に使用されるデータ ファイルをすばやく見つけることができます。ファイルまたはテーブルを［ウォッチ リスト］タブに追加するには、その追加対象を選択してドラッグ アンド ドロップ、ボタンをクリック、または右クリックしてコマンドを選択します。別の場所に Btrieve ファイルがある場合は、その場所を参照し、監視対象として追加することもできます。

Defragmenter は dbdefrag ツールとしても実行します。

以下のセクションでは、Defragmenter の使用方法について説明します。

Defragmenter を無人モードで使用する方法については、自動最適化を参照してください。

Defragmenter は、データ ファイルについて、パフォーマンス低下の原因を示す統計情報を分析するのに役立ちます。ファイルサイズ、断片化率、未使用率、および順序不同率の統計値が大きいと、データベースのパフォーマンス低下の原因になることがあります。ファイルまたはテーブルを最適化すれば、これら 4 つの数値をすべて下げることができます。詳しくは、ウォッチ リスト セクションで説明しています。一般に、コンパクト化され、インデックスを作成し直した新しいファイルは、効率性、容量およびパフォーマンスが復元し、トランザクションもより迅速に実行します。

データベースはそれぞれ異なるので、すべての人に該当するような推奨事項はありません。最適化を行うかどうかは、使用しているデータベースとそのアプリケーションに対する知識や経験値によって異なってきます。ただし、以下の一般的な事項は検討する価値があります。

最適化を実施してもパフォーマンスの改善が見られない場合は、ほかの問題が原因である可能性があり、別の診断や解決策が必要です。

場合によっては、Defragmenter を使用できなかったり、優先順位の上位にランク付けされているデータベース活動によって操作をキャンセルされたりすることがあります。

Defragmenter は次の 3 つの方法で実行します。

Defragmenter では、データベース テーブル、ファイル、およびその他のオブジェクトをそれぞれのタブに表示します。

Defragmenter ウィンドウ内のタブの配置は変更することができます。タブの配置を参照してください。

［使用中のファイル］タブでは、Zen エンジンで現在開いている、または最近開いたファイルを一覧表示します。このタブに表示されるファイルは［ウォッチ リスト］タブに追加して、監視、分析、および最適化を行うことができます。パフォーマンスの低下の一因となる可能性が高いので、データベース作業のルーチン実行に関わるファイルのみを選択することをお勧めします。

［使用中のファイル］タブでは、［読み取り/書き込み］列の見出しをクリックすることで、リストを並べ替えることができます。リストを並べ替えることで、最も頻繁に使用されており、断片化されている可能性が高いファイルを特定することができます。

［テーブル］タブは、Zen エクスプローラーと似ており、Defragmenter が実行しているサーバーのノードを表示します。このタブに表示されるファイルは［ウォッチ リスト］タブに追加することができます。

［Btrieve ファイル］タブは、ファイル システム上のドライブやディレクトリのファイル エクスプローラーです。このタブでは、データ ファイルに加えルーチン オペレーションに含まれない項目（dbnames.cfg や .ddf ファイルなど）も一覧に表示されます。これらのファイルは［ウォッチ リスト］タブに追加して分析や最適化を行うことができますが、データ ファイルとは異なり、それらのファイルを変更しようとしたときにファイルが使用中であった場合はエラーが返ります。これらのメタデータ オブジェクトは断片化のリスクが低いです。これは一般に実稼働環境では変更しないからです。まれなケースとしてこれらの最適化が必要となった場合は、ダウンタイムのメンテナンス中に行うことができます。

［ウォッチ リスト］タブ内の項目は、分析または最適化が適用された後の統計情報を表しています。

［ウォッチ リスト］タブの下にある［詳細］ペインでは、［ウォッチ リスト］タブ内の列の統計情報をまとめたものですが、さらに次の情報が追加されています。

［ウォッチ リスト］タブで 1 つの項目を選択すると、その項目の詳細が表示されます。複数の項目を選択した場合は、強調表示（選択）されている項目のうち一番上にある項目の詳細が表示されます。

最適化の初期設定は、ツール内または Zen Control Center のどちらからでも設定できます。どちらの GUI でも、［ウィンドウ］>［設定］>［Zen］>［Defragmenter］の順に選択すれば、［設定］ダイアログ ボックスの［Defragmenter］ページが開きます。

次の表では、設定できる初期設定とその内容について示しています。

Defragmenter の情報は、指定した間隔で自動的にリフレッシュすることができます。デフォルトでは 5 秒間隔でリフレッシュされます。頻繁に多くのウィンドウをリフレッシュすると、パフォーマンスが低下する可能性があるので注意してください。

Defragmenter のタブは、必要に応じて配置を変更したり、分離させたりすることができます。タブを移動させるには、タブのラベル部分を希望の移動先までドラッグ アンド ドロップします。Defragmenter の初期設定で、［ウィンドウ レイアウトを保存］オプションを選択した場合は、変更したタブの配置が維持されます。

ここでは、Defragmenter GUI におけるざまなタスク向け機能を使用する手順を提供します。

自動リフレッシュ レートは［ウォッチ リスト］タブの統計情報に適用されます。それ以外のタブ一覧をリフレッシュするには、各タブで［更新］アイコンをクリックするか右クリックで［更新］を選択し、手動で行います。

［ウォッチ リスト］タブへのファイルやテーブルの追加は、次のようにさまざまな方法で行うことができます。

［ウォッチ リスト］タブへ追加される項目は、既に追加されている項目の一覧の最後部に表示されます。

分析では統計情報を報告します。これにより、最適化する必要がある項目を決定できます。

［ウォッチ リスト］タブでは、対象項目の各列を更新することで分析結果を報告します。最初に選択された項目の場合、［詳細］タブにはファイルを最適化するために必要な空きディスク容量など、その項目の詳細な状態が表示されます。

［ウォッチ リスト］タブでは、対象項目の各列を更新することで最適化の結果を報告します。1 つの項目を選択していた場合は、下にある［詳細］タブにその項目の詳細な状態が表示されます。複数の項目を選択していた場合は、最初に選択した項目についての状態が表示されます。

分析または最適化の実行中に、［ウォッチ リスト］内のファイルを選択し、右側にある［最適化の取り消し］アイコン をクリックします。表示される確認のダイアログで、［はい］をクリックします。Defragmenter は［はい］がクリックされるまで操作を続けます。

もう 1 つの方法として、左側にある［すべての最適化の取り消し］アイコン をクリックすることもできます。このアイコンでは、すべての分析および最適化の活動を停止でき、右側のアイコンでは、ウォッチ リストにある、分析または最適化が行われている個々のファイルについて活動を停止できます。

最適化の取り消し後、［ウォッチ リスト］タブ内の項目のうち、状態が "分析：完了" または "最適化：完了" で新しい統計情報が表示されるものもあれば、"分析：キャンセル" または "最適化：キャンセル" で空の統計情報が表示されるものもあるかもしれません。最適化を取り消した項目の場合、［詳細］タブでは取り消されるまでの所要時間が表示されます。

取り消しが成功したということは、分析が停止したか、ファイルまたはテーブルの断片化が変わっていないことを意味します。

［ウォッチ リスト］タブの各列の表示/非表示を設定することができます。

［クリックして詳細を非表示にする］アイコン をクリックすると、［詳細］タブの表示/非表示を切り替えることができます。

CLI ツールの dbdefrag では、ウォッチ リストがないことを除き、GUI バージョンと同じ機能を提供します。どちらのインターフェイスからでも最適化の開始、状況の確認、または取り消しが可能です。

次の表では、コマンド ライン オプションについて説明します。

次の例では、サイズが大きい .mkd ファイルで dbdefrag を使用する場合の一連の手順を示します。

C:\ProgramData\Actian\Zen\Examples>dbdefrag -analyze mybtrievefile.mkd
     断片化: 9%
     未使用: 4%
   順序不同: 100%
ファイル サイズ: 713 MB

C:\ProgramData\Actian\Zen\Examples>dbdefrag mybtrievefile.mkd
1125 / 1195242 個のレコードを処理しました (0%)
87021 / 1195242 個のレコードを処理しました (7%)
170910 / 1195242 個のレコードを処理しました (14%)
255393 / 1195242 個のレコードを処理しました (21%)
339805 / 1195242 個のレコードを処理しました (28%)
404202 / 1195242 個のレコードを処理しました (33%)
487928 / 1195242 個のレコードを処理しました (40%)
572585 / 1195242 個のレコードを処理しました (47%)
655802 / 1195242 個のレコードを処理しました (54%)
716472 / 1195242 個のレコードを処理しました (59%)
800406 / 1195242 個のレコードを処理しました (66%)
883729 / 1195242 個のレコードを処理しました (73%)
947475 / 1195242 個のレコードを処理しました (79%)
1032061 / 1195242 個のレコードを処理しました (86%)
1116015 / 1195242 個のレコードを処理しました (93%)
1185831 / 1195242 個のレコードを処理しました (99%)
1195242 / 1195242 個のレコードを処理しました (100%)
1 / 2 個のキーを処理しました (50%)
2 / 2 個のキーを処理しました (100)
最適化は完了しました。
所要時間: 0h:24m:57s

C:\ProgramData\Actian\Zen\Examples>dbdefrag -status mybtrievefile.mkd
最適化の状態: 進行中
1053373 / 1195242 個のレコードを処理しました (88%)
0 / 2 個のキーを処理しました (0%)

C:\ProgramData\Actian\Zen\Examples>dbdefrag -status mybtrievefile.mkd
     状態: 完了
     開始: 2014-08-08 11:08:28
     終了: 2014-08-08 11:33:25
所要時間: 0h:24m:57s

C:\ProgramData\Actian\Zen\Examples>dbdefrag -analyze mybtrievefile.mkd
     断片化: 0%
     未使用: 0%
   順序不同: 27%
ファイル サイズ: 682 MB

Zen サーバーの Windows 版では、Windows パフォーマンス モニターで使用するパフォーマンス カウンターを提供します。（Zen のパフォーマンス カウンターがサポートされるのは、Windows Vista 以降のオペレーティング システムのみです。）パフォーマンス カウンターはデータベース エンジンの状態や動作を測定します。これによりアプリケーションのパフォーマンスを分析することができます。Windows パフォーマンス モニターは、指定の時間間隔でパフォーマンス カウンターの現在の値を要求します。

Zen は、パフォーマンス モニターで表示するためだけにデータを提供しており、カウンターのプロパティは変更できません。パフォーマンス モニターは以下のアイテムを制御します。

カウンターの値は、呼び出し元を問わず、データベース エンジンへのすべての呼び出しを反映します。つまり、MicroKernel エンジン、リレーショナル エンジン、ネイティブな Btrieve アプリケーション、ユーティリティなど、すべてがカウンターの値の一因となります。カウンターの値はすべてのファイルを対象に収集されます。ファイルごとのカウンターは現在サポートされていません。

パフォーマンス カウンターの使用は、主にアプリケーション開発者およびその他の技術スタッフ向けの高度な機能です。Windows パフォーマンス モニターおよび一般的なカウンターの使用の詳細については、Microsoft の関連ドキュメントを参照してください。

デフォルトで、Zen のインストールでは Zen パフォーマンス カウンターをパフォーマンス モニターに登録します。このカウンターはインストール完了後に使用できるようになります。

お客様のニーズへの対応のため、本章で説明されていない Zen コレクター セットまたはカウンターを追加インストールすることになる可能性もあります。そのような場合は、Windows パフォーマンス モニターで提供されるコレクター セットまたはカウンターの説明を参照してください。カウンター セットまたは個別のカウンターをモニターへ追加するを参照してください。

データ コレクター セットは、複数のカウンターを 1 つのコンポーネントにまとめています。このコンポーネントを使用してパフォーマンスを再確認したり記録したりすることができます。Zen では以下のデータ コレクター セットを提供します。

これらのカウンターは、Btrieve API に関するクライアント アプリケーションの動作の特徴を示すために役立ちます。カウンターは、指定した時点にデータベース エンジンで処理されたオペレーションの種類を報告します。

『Btrieve API Guide』の Btrieve API オペレーションも参照してください。

データベース エンジンは 2 つのレベルのメモリ キャッシュ システムを使用してデータ操作のパフォーマンスを向上させます。2 つのキャッシュは「L1（レベル 1）キャッシュ」と「L2（レベル 2）キャッシュ」と呼ばれます。

ユーザーの要求に応じエンジンがディスクからページを読み取る頻度が高くなるほど、パフォーマンスは低下します。これらのカウンターを使用すると、データベース エンジンによるディスク読み取りの回避状況をまとめて表示し、キャッシュ サイズの設定に対してなんらかの変更が必要かどうかを判断することができます。

すべてのデータが L1 キャッシュに格納された場合は最高のパフォーマンスが得られます。ただし、データ ファイルのサイズによっては、L1 キャッシュにすべてのデータ ページを保持できないこともあります。このため、データベース エンジンは第 2 レベルのキャッシュ（L2 キャッシュ）も使用します。L2 キャッシュのページは圧縮形式で格納されるため、より多くのページをメモリに入れることができます。そのため、L1 キャッシュよりもパフォーマンスは低下しますが、データベース エンジンがディスクからページを読み取る状況と比べればパフォーマンスは高くなります。

データベースのメモリ キャッシュの理想的なサイズを計算するにはも参照してください。

このセットのカウンターは、データベース エンジンによる、物理記憶域へのデータの読み取りおよび書き込み状況を把握するのに役立ちます。カウンターによって報告されるページとはデータ ファイル ページです。これらのカウンターでは、アーカイブ ログまたはトランザクション ログ向けに使用されるファイルのページ用のデータは報告しません。

『Zen Programmer's Guide』のページも参照してください。

クライアントの要求は、リソースが使用可能になるのを待つため遅延することがあります。これらのカウンターを使用すれば、リソースが使用可能になるまでクライアント要求を待つ必要があるデータベース リソースのタイプを特定することができます。同様に、これらのカウンターでは複数のクライアントがリソースへアクセスしたときのデータベース エンジンの動作を観察することができます。値がクライアント数に近いまたは等しい場合は、同じリソースに対して競合している可能性があることを示しています。これらの競合を低減するための是正措置を行えば、反応性を改善することができます。

Waits on Page Buffers および Waits on Page Reads カウンターはグローバル リソースを待機します。その他のカウンターはすべて複数のクライアントに適用しますが、各クライアントはそれぞれ異なるリソースを待機している場合があります。

『Zen Programmer's Guide』のデータ整合性および複数のクライアントのサポートを参照してください。

これらのカウンターは、トランザクションに関するクライアント アプリケーションの動作を理解するために役立ちます。たとえば、変更が多く処理に長時間かかる少数のトランザクションと、短時間で処理が完了する多くのトランザクションとでは動作が異なります。

『Btrieve API Guide』の Begin Transaction（19 または 1019）、End Transaction（20）、および Abort Transaction（21）、また『Zen Programmer's Guide』の MicroKernel エンジンの基礎も参照してください。

このセットのカウンターは、ページ サーバーに関する統計情報を提供します。

このセットのカウンターは、Zen キャッシュ エンジンに関する統計情報を提供します。

このトピックでは、Windows パフォーマンス モニターの基本的な使用手順について説明し、Zen パフォーマンス カウンターを使用できるようにします。Windows パフォーマンス モニターの使用に関する詳細については、Microsoft のドキュメントを参照してください。

以下に示す手順は、Zen のインストールによって Zen パフォーマンス カウンターが Windows パフォーマンス モニターに登録されていることを前提としています。

Zen 製品では、エディションに応じて異なるライセンス モデルを使用します。Zen Enterprise Server および Workgroup は同時ユーザー カウント ライセンスに基づいてライセンスされます。Cloud Server は容量ベース ライセンスに基づいてライセンスされます。

ライセンスの使用状況に関する監視の大部分が、ユーザー数、セッション数、または使用中データを対象とします。たとえば、これらの現在の値を調べる、現在の値を増やす、または必要な容量をさらに調べることができます。

ライセンスの使用状況の監視に使用する 4 つの主要なユーティリティは、Monitor（リソース使用状況の監視を参照）、Capacity Usage ビューアー、License Administrator、および Notification Viewer です。

ZenCC では、すべてのデータベース エンジンの同時セッション数とデータ使用量を監視する Capacity Usage ビューアーを提供します。このビューアーは特に、Zen Enterprise Server から Zen Cloud Server への移行を検討する際に役立ちます。なぜなら、これらのライセンスは異なるからです。

Capacity Usage ビューアーには 2 つのグラフが含まれています。1 つは同時セッション数を表し、もう 1 つはデータの使用量を表します。各グラフには使用量のレベル バーというグラフを横断する横線を表示させることができます。これは業務上の正常とする使用量と異常とする使用量を判断するのに役立ちます。Capacity Usage ビューアーは使用量のピークに関する統計情報も表示します。

このグラフは毎日記録されるピーク値を使用します。エンジンが使用されない日については、ゼロの値が使用されます。グラフの生成には最低 2 日間のデータが必要です。そのデータがなければ、Capacity Usage ビューアーはエラー メッセージを表示します。

ここでは、以下の項目について説明します。

ZenCC で、検査対象のエンジンを右クリックし、［Capacity Usage ビューアー］を選択します。

次の図は Capacity Usage ビューアーを表しています。図の下の表は各機能の説明です。画像上のそれぞれの領域をクリックするとその詳細が表示されます。

［期間］プルダウン メニューで提供されている期間の選択肢以外の期間について確認する必要がある場合は、グラフのセグメントを選択して拡大することができます。2 つのグラフの一方を拡大すると、もう一方のグラフも同時に拡大されます。2 つのグラフは常に同じ期間が設定されます。

License Administrator はライセンスのキーの管理に使用するツールです。これについては、『Zen User's Guide』のライセンス管理で詳しく説明しています。次の表では、このツールで実施できる一般的な監視作業について簡単に説明し、関連情報の参照先として『Zen User's Guide』へのリンクも提供しています。

Actian Corporation では、Audit for Zen という、Zen に付属するデータベース レベルでのアクセスを監視するための製品を提供しています。Audit for Zen を使用すると、次のような監査目的のために、データへの変更を監視することができます。

Audit for Zen は詳細な監査証跡を提供するほか、クエリおよび警告機能を提供します。

製品の詳細については、Audit for Zen のドキュメントを参照してください。

Zen ではメッセージ用のさまざまなログ リポジトリを提供して、トラブルシューティングを支援します。ログは大きく分けて 2 つのカテゴリに分類されます。

次の表にログ リポジトリの概要を示します。

ログ リポジトリのいくつかはライセンス メッセージに重点を置いています。キーが無効と判断された場合、そのキーの状態は「アクティブ」から「検証失敗」に変わります。この状態でも一定の期間内はデータベース エンジンが正常に機能するので、検証失敗を修正するための時間は十分にあります。

その修正猶予期間が終わるまでにエラーが修正されないと、キーの状態は再び無効になります。キーが無効になると、データベース エンジンはデータ ファイルにアクセスできなくなります。

検証失敗への対応を適時に行う必要があるため、キーの状態の変更はできるだけ早く通知されるようになっています。たとえば、1 つのメッセージがすべてのメッセージ リポジトリに記録されます。リポジトリの中で最もわかりやすいのは Zen Notification Viewer です。License Administrator でもキーの状態が表示されます。このため、いつでも検証動作を実行して状態を確認することができます。『Zen User's Guide』のライセンス管理を参照してください。

次の表では、キーの状態の変更に応じて返されるメッセージのタイプについて説明します。

期限切れ状態（一時キーの場合のみ適用）、または非アクティブ状態（前バージョンの Zen で登録されたままのキーに適用）となっているキーに関するメッセージは記録されないので注意してください。

次の表は、ライセンス メッセージが記録される頻度を特定の動作別に示しています。

Notification Viewer は、ライセンス コンポーネントによって記録されるメッセージを表示するツールです。このツールは、注目すべきライセンス メッセージ（ログ記録の頻度 を参照）をわかりやすく通知することを目的としています。

Notification Viewer は、デフォルトで Enterprise Server および Cloud Server（Windows および Linux の 32 ビットおよび 64 ビット版）および Zen Workgroup（Windows 版）のインストール時に一緒にインストールされます。また、Windows プラットフォームではデフォルトで、Windows を再起動すると Notification Viewer も再起動します。

Windows プラットフォームの場合、この実行可能ファイルの名前は notifyviewer.exe です。これはユーザーに対し、単独で実行するインスタンスを提供します。Notification Viewer が既に実行されている状態で新たに Notification Viewer を起動しようとすると、実行済みの GUI が画面の最前面に表示されます。

Linux および Raspbian の場合、このツールは notifyviewer という名前のシェル スクリプトです。このシェル スクリプトは実行するたびに、新たな Notification Viewer インストタンスを起動します。オペレーティング システムを再起動した場合は、Notification Viewer を手動で再起動する必要があります。再起動時、このシェル スクリプトは自動的には実行されません。

次のコマンド ライン オプションを使用すると、このツールの実行方法を指定できます。

Notification Viewer では、システム トレイ アイコンとグラフィカル ユーザー インターフェイスの 2 つのインターフェイスを提供します。

Windows のデフォルトでは、Notification Viewer は GUI を表示しないで起動し、システム トレイ アイコンを表示します。Linux の場合、Notification Viewer は GUI として起動し、そのディストリビューションがシステム トレイをサポートしている場合は、システム トレイ アイコンを表示します。ツールが実行されると、ライセンス メッセージの監視を開始します。

Notification Viewer が未読のメッセージを検出すると、トレイ アイコンは未読メッセージを示す表示に変わります。トレイ アイコンを参照してください。

Notification Viewer は 2 種類のツールヒントも表示します。ツールヒントをマウスでポイントすると、重要な未読メッセージがある場合はそのメッセージ数、未読メッセージの総数が表示されます。メッセージがすべて既読の場合はツールの名前が表示されます。通知する必要があるメッセージを Notification Viewer が検出した場合は、バルーン形式のツールヒントが表示されます。Windows の場合、このツールヒントは直接閉じるか、キーボードまたはマウス操作を行わない限り表示され続けます。Linux の場合、このツール ヒント上をクリックして閉じる必要があります。

トレイ アイコンのポップアップ メニューには、［Zen Notification Viewer を開く］（GUI を開く）および［終了］（ツールを終了する）という 2 つの項目があります。このメニューはトレイ アイコンを右クリックすると表示されます。

次の表ではトレイ アイコンの意味を説明します。

トレイ アイコンをダブルクリックするか、トレイ アイコンを右クリックして［Zen Notification Viewer を開く］をクリックすると、Notification Viewer GUI を開くことができます。Linux の場合は、Notification Viewe はデフォルトで GUI として起動し、そのシステム トレイ アイコンが表示されます起動動作を変更する場合は、notifyviewer シェル スクリプトに -tray オプションを渡します。Linux ディストリビューションがシステム トレイをサポートしていない場合、Notification Viewer は GUI を表示し、システム トレイ アイコンは表示しません。その場合は、シェル スクリプトを実行して Notification Viewer を起動してください。

この GUI が表示されると、未読メッセージが直ちに GUI へ追加されます。さらに、トレイ アイコンにツールヒントが表示され、アイコンは未読メッセージを示す表示に変わります。

Zen は、通知ファイルにある記録の既読または未読状態をユーザーごとに監視します。つまり、GUI を表示している各ユーザーからはすべてのメッセージが見えますが、メッセージの既読または未読状態はユーザーごと異なるということです。

オペレーティング システムでシステム トレイがサポートされない場合は、Notification Viewer に対して Close コマンドを実行することでこのツールは終了します。システム トレイがサポートされる場合は、画面を閉じることで GUI が非表示になり、ツールが実行中であることを示すトレイ アイコンが表示されます。

Zen は、オペレーティング システムのイベント ログに以下のエントリを書き込みます。

詳細については、以下のトピックを参照してください。

Windows オペレーティング システムでは、「アプリケーション」、「セキュリティ」、または「システム」として分類されるイベントの記録方法を提供しています。Zen では、一般的なエラー メッセージと選択したライセンス メッセージが zen.log に書き込まれると、Windows のアプリケーション イベント ログにもこれらのメッセージを記録します。

ライセンス メッセージの場合、「エラー」または「警告」として分類されるイベントが記録されます。これには、キーの状態の変更に起因するメッセージのほか、警告、エラー メッセージが含まれます（ログ記録の頻度を参照）。さらに、キーの状態の変更で挙げているような特定の情報メッセージも記録されます。

Windows オペレーティング システムでは、イベント ログを表示および操作するための「イベント ビューアー」という GUI を提供しています。この GUI には、Windows の PC 設定またはコントロール パネルから、あるいはコマンド インターフェイスで eventvwr.msc コマンドを実行してアクセスすることができます。

Zen は 1 つのイベントに対し以下の内容を表示します。

さらに、［キーワード］列に "クラシック"、［ログ］列に "アプリケーション" を表示します。イベント ビューアーではさらに列が表示できるようになっていますが、Zen はそれらに対するデータを提供しません。

Linux および Raspbian ディストリビューションの場合は、Zen の全コンポーネントが標準ログ システムの syslog にメッセージを書き込みます。syslog はデフォルトで、Linux と Raspbian では /var/log/messages に書き込みます。SQL 接続マネージャーに限り、任意でメッセージを event.log ファイルに記録することもできます。

bti.ini は、Lnux および Raspbian ディストリビューションで使用される Zen 設定ファイルです。デフォルトでは、このファイルは /usr/local/actianzen/etc にあります。

このファイルを使用すると、SQL 接続マネージャー用の構成を行うことができます（INI ファイルの［SQLManager］セクション）。設定の 1 つである LogEvent は、イベント ログ ファイル（event.log）に記録するイベント メッセージのタイプを決定します。デフォルトでは、event.log は /usr/local/actianzen/bin にあります。

Windows プラットフォームの場合、Zen の全コンポーネントが Zen のイベント ログへステータス、エラー、警告、および情報メッセージを書き込みます。Linux および Raspbian ディストリビューションの場合、Zen は専用のイベント ログを使用しません。その代り、Zen の全コンポーネントが標準ログ システムの syslog にメッセージを書き込みます。Linux および Raspbian ディストリビューションのイベント ログを参照してください。

Zen のイベント ログは、デフォルトで ＜アプリケーション データ ディレクトリ＞\actianzen\logs ディレクトリにあります。Windows プラットフォームでは Zen の全コンポーネントがこのログ ファイルに書き込みます。Zen データベース エンジンを使用した複数のアプリケーションが同じマシン上で動作している場合、これらのアプリケーションは zen.log を共有します。

zen.log の内容は、次の表で説明されている形式のテキスト メッセージで構成されます。

エントリの後に、標準の 16 進形式のバイナリ データが続くことがあります。バイナリ データの長さには、制限がありません。

以下は、zen.log に含まれるデータの種類の例です。

Zen にはイベント メッセージの電子メール通知が含まれていません。そのような機能を提供するベンダーの製品が簡単に入手できるからです。このトピックでは、それらの製品のいくつかを挙げるとともに、Zen ライセンスおよび製品キーに関する操作を監視するためのイベント ログの使用についても説明します。

次の表は、オペレーティング システムのイベント ログに含まれるイベントの電子メール通知を提供できる製品の一部を挙げています。製品はアルファベット順に並んでいます。弊社では、特定の製品について推奨することはしません。一覧に記載されている製品は、ほかのベンダーから提供されるものであるため、製品とそれに関する解説がここで述べたものと異なることがあります。

通常、そのような製品は、エージェントをインストールする、WMI（Windows Management Instrumentation）のようなリモート アクセス メカニズム、あるいはセキュア シェル（SSH）を有効にする必要があります。

監視されるイベントの電子メール通知を提供する製品で挙げた項目はすべて、オペレーティング システムのイベント ログの内容を識別することができます。識別方法は、Windows プラットフォームと、Linux および Raspbian ディストリビューションで異なります。ここでは、各製品の具体的な監視方法について説明しません。詳細については、ベンダーのドキュメントを参照してください。

次に表では、オペレーティング システムのイベント ログで、Zen ライセンスのプロパティを示しています。監視する製品の設定で、それらのプロパティの値に基づいて電子メール通知が送信されるようにします。

Zen ライセンスに関するイベント メッセージのうち、警告またはエラーのメッセージについて電子メール通知を受け取りたいとします。製品を次のような条件で監視するよう設定します。

Linux および Raspbian の syslog には、Windows オペレーティング システムのイベント ログと同じプロパティは含まれていません。syslog 内のイベントと文字列を特定するよう通知製品を設定する必要があります。イベントと文字列の比較に基づいて、製品は電子メール通知など、希望の動作を開始することができます。

Zen データベース エンジンによって syslog に書き込まれるすべてのメッセージ（ライセンス関連かどうかに関わらずすべてのメッセージ）には mkded という文字列が含まれています。次の一覧には、syslog で Zen ライセンスのみに該当する文字列をいくつか示しています。syslog を監視する方法の 1 つは、mkded と以下の文字列の 1 つを含む内容に基づいて文字列比較を設定することです。