パフォーマンス
以下のトピックでは、データベースのパフォーマンスについて説明します。
データベースのパフォーマンスの向上に関する詳細については、『SQL Engine Reference』のパフォーマンスの最適化リファレンスを参照してください。
SQL クエリ ログ
データベースのパフォーマンスは、SQL ステートメントの効率など、さまざまな要因によって異なります。SQL クエリをログに記録することで、パフォーマンスの低いクエリを特定して最適化できるようになります。クライアント アプリケーションやその他のクエリ ツールでも、不明なクエリが実行される可能性があり、それらはログで検出することができます。
Zen v16 では、クエリをログに記録するために、エンジンのプロパティに次の 2 つの設定が導入されました。
• クエリ ログ：SQL エンジンがクエリの実行をファイルに記録して確認できるようにします。
• クエリ ログのフェッチ：クエリ ログに FETCH オペレーションを含めるかどうかを指定します。フェッチ ログをオフにすると、ログの詳細度が低くなり、確認しやすくなります。
ZenCC でこれらの設定を表示するには、エンジン エントリを右クリックして［プロパティ］を選択し、プロパティのカテゴリ一覧から［デバッグ］を選択します。各設定を有効または無効にするには、チェックボックスを使用します。［クエリ ログのフェッチ］を有効にするには、［クエリ ログ］も有効にする必要があります。また、 bcfg で各設定の数値 ID（それぞれ 184 と 185）を使用して、［クエリ ログ］と［クエリ ログのフェッチ］の設定をオン/オフにすることもできます。
データベースのクエリ ログをオン（有効）にすると、新しいデータベース接続ごとにそのエントリが、C:\ProgramData\Actian\Zen\logs で新規作成されるテキスト ファイルに記録されます。ログ ファイルの名前は、<user name> - <database name> -yyyy-mm-dd_hh-mm-ss.mmm-query.log の形式です。接続セッションが終了すると、ログ ファイルは閉じられます。次の新しいデータベース接続により、新しいログ ファイルが作成されます。最新のリリースでは、ログ ファイルの保存場所は変更できません。
ログ エントリは ODBC 呼び出しを参照します。セキュリティ上の理由から、一部の SQL ステートメントはログに記録されません。次の表は、ログに記録されるステートメントとログに記録されないステートメントの両方を一覧表示します。
クエリ ログ | |||||
|---|---|---|---|---|---|
以下の SQL ステートメントはログに記録されます。 | |||||
CALL | COMMIT | DELETE | EXEC | EXECUTE | INSERT |
RELEASE | ROLLBACK | SAVEPOINT | SELECT | UPDATE | |
以下の SQL ステートメントはログに記録されません。 | |||||
ALTER | CREATE | DROP | GRANT | ALTER | CREATE |
INSERT | REVOKE | SET | USE | ||
注記
• クエリ ログは、WHERE 句を含む SELECT クエリとの組み合わせでのみ、INSERT または UPSERT ステートメントをキャプチャします。レコードの追加や更新自体では、最適化のためのクエリが生じません。SELECT オペレーションと WHERE 句を追加することで、実行を最適化する機会が得られます。
• クエリ ログでは、ストアド プロシージャ呼び出しによって実行されたクエリがキャプチャされます。
• パスワードはクエリ ログには表示されません。
例
次の例では、クエリ ログと Query Plan Viewer を使用して、SQL 実行のパフォーマンスの向上を検出および確認する方法を示しています。
Demodata データベースで次の SQL ステートメントを実行します。
SELECT Major, COUNT(*) AS NumMajors from Student GROUP BY Major;
このクエリ ログ エントリの結果：
====================================================================================================
2024-05-01T13:42:58.353: Start: SQLPrepare Handle: 0x29b7fa21410
SQL Query text: "select Major, count(*) as NumMajors from Student group by Major"
2024-05-01T13:42:58.384: End: SQLPrepare Retcode:0 Handle: 0x29b7fa21410
====================================================================================================
ログには実行時間が 31 ミリ秒であることが示されます。
SELECT ステートメントの前にインデックスを作成すると、実行時間が短縮されます。
CREATE INDEX Major_index ON Student (Major);
SELECT Major, COUNT(*) AS NumMajors FROM Student GROUP BY Major;
このクエリ ログ エントリの結果：
====================================================================================================
2024-05-01T13:42:58.634: Start: SQLPrepare Handle: 0x29b7f9a4200
SQL Query text: "select Major, count(*) as NumMajors from Student group by Major"
2024-05-01T13:42:58.634: End: SQLPrepare Retcode:0 Handle: 0x29b7f9a4200
====================================================================================================
これにより、実行時間が 1 ミリ秒未満に短縮されます。
Zen Query Plan Viewer は、改善を視覚化するのに役立ちます。次のスクリプトはクエリ プラン ファイルを作成します。
DROP INDEX IF EXISTS student.major_index;
SET qryplanoutput = 'C:\ProgramData\Actian\Zen\logs\Majors.qpf';
SELECT Major, COUNT(*) AS NumMajors from Student GROUP BY Major;
CREATE INDEX Major_index ON Student (Major);
SELECT Major, COUNT(*) AS NumMajors FROM Student GROUP BY Major;
SET qryplanoutput = NULL;
インデックスが追加される前のクエリ プランには、グループ化を行うためのテンポラリ ファイルが作成されることが示されます。インデックスが追加された後のクエリ プランでは、テンポラリ ファイルが不要になっていることが示され、パフォーマンスが向上します。詳細については、Query Plan Viewer を参照してください。
パフォーマンスの分析
Zen サーバーの Windows 版では、Windows パフォーマンス モニターで使用するパフォーマンス カウンターを提供します。パフォーマンス カウンターはデータベース エンジンの状態や動作を測定します。これによりアプリケーションのパフォーマンスを分析することができます。
この機能の詳しい説明については、他の多くの Zen データベース監視機能と一緒にパフォーマンス カウンターの監視トピックにまとめて記載しています。
パフォーマンス チューニング
このセクションでは、データベース初期接続および実行時オペレーションでパフォーマンスを最大にするための一般的なヒントをいくつか提供します。一般的なガイドラインをいくつか示しますが、特定のアプリケーションのパフォーマンスは、以下に挙げる要因だけに限らず、非常に多くの要因によって変わります。
• ネットワークの帯域幅および使用率
• アプリケーションでのコーディング技法
• 使用可能な物理記憶域
• 使用可能なメモリ
• プロセッサの速度
• アプリケーションでの使用パターン（大量の書き込み、大量の読み取り、トランザクションの使用/不使用、レコード サイズの大小、複雑または単純なクエリ、ODBC、Btrieve のみ、など）
• CPU サイクルで競合する無関係なアプリケーション
• データベース エンジン設定
ご覧のように、エンジンの設定は一定のアプリケーションの全体のパフォーマンスの中では比較的限定的な役割を果たします。さらに、データベース エンジンは使用パターンに基づいてさまざまなリソースを動的に管理します。データベース エンジン自体が、必要に応じ環境に合わせてチューニングします。以下のセクションで提供するのは、有用なガイドラインにすぎず、特定のレベルのパフォーマンスを保証するものではありません。
パフォーマンスのボトルネックを見極める
Monitor ツールを使用すると、特定のデータベース エンジンの設定オプションに関連するパフォーマンスのボトルネックを見つけることができます。オペレーティング システムの［スタート］メニューまたはアプリ画面から、あるいは Zen Control Center の［ツール］メニューから Monitor を起動します。
Monitor の表示と設定オプション
Monitor にある 2 つのタブには、設定オプションに関連するパフォーマンスの値が表示されます。
• リソース使用状況
• MicroKernel 通信統計情報
次の表に示すように、データベース エンジンは複数のサーバー設定オプションを動的に管理します。
動的に管理される設定 | リソース使用状況タブに表示される値 | 通信統計情報タブに表示される値 |
|---|---|---|
ファイル数 | X | |
ハンドル数 | X | |
クライアント数 | X | |
ワーカ スレッド数 | X | |
リモート セッション総数 | X |
表示および動作の解釈
Monitor に表示される情報を活用することができます。Monitor はリソースのタイプごとに 3 つの情報を表示します。たとえば、リモート セッション総数には次のように表示されます。
• 現在値。実際に動作しているリモート セッションの現在の数。
• ピーク値。エンジンが開始されてから実際に使用されたリモート セッションの最大数。
• 最大値。リモート セッションの使用可能な最大数。
リソースのピーク値と最大値が同じ場合には、そのリソースの最大値を増やすように設定プロパティを設定すれば、データベース エンジンは、必要な場合に特定のリソースの追加のインスタンスを割り当てることができます。
設定プロパティを変更する前に
以下のセクションでは、次のことを前提とします。
1. Zen Control Center（ZenCC）が既に開いていること。
このタスクについての説明が必要な場合は、『Zen User's Guide』の Windows での ZenCC の起動を参照してください。
2. 構成しようとするエンジンが既に登録済みであること（可能な場合）。
このタスクについての説明が必要な場合は、『Zen User's Guide』のリモート サーバー エンジンを登録するにはを参照してください。
3. 所定のエンジンを構成するには、オペレーティング システムの適切な権限が必要です。
このタスクについての説明が必要な場合は、『Zen User's Guide』のデータベース エンジンの管理者権限の許可を参照してください。
4. 一部のエンジン設定については、設定を変更した後にデータベース エンジンの再起動が必要になります。
初期接続時間を最小限にする
最短接続時間の基礎を成す理論は、3 つの必要条件を中心に展開します。これらの必要条件についての要約は次のようになり、詳細についてはその後で説明します。
• 既知の通信プロトコル。クライアントまたはサーバーが、その環境でサポートされていないプロトコルを介して接続を試行するために余計な時間を費やすことは望ましくありません。クライアント/サーバーが使用できないプロトコルを削除することにより、ネットワーク コンポーネントがそれらの使用を試行することを防げます。
• 既知のデータベース エンジンのロケーション。クライアントが存在しないエンジンへの接続を試行しない場合もあります。ワークグループのみのサポート、またはサーバーのみのサポートを適切に指定することにより、クライアントが存在しない接続でタイムアウトになることを防ぐことができます。非共有および共有データベースの両方がある環境では、ゲートウェイの一貫性保持を使用して、データベース エンジンがデータベース エンジンの実行されていないマシンを常に知ることができ、これにより、これらのマシン上のエンジンへの接続を試行せず、別の方法でデータにアクセスします。
• 実行準備の整ったデータベース エンジン。休止しているエンジンが新しい接続リクエストを受け取ると、リソースの再割り当ておよび実行時の状態に戻るのに時間がかかります。接続スピードがサーバー上のリソース使用量より重要な場合は、サーバー エンジンが使用されていないときにも休止しないようにすることができます。
クライアントとサーバーのプロパティを管理することで、次の要件を満たすことができます。
クライアントのプロパティ
クライアントのプロパティの変更は、そのクライアント マシンで行う必要があります。個々のクライアントでプロパティを変更する必要があります。
クライアント側の接続待ち時間を最小限にするには
1. Zen エクスプローラーで、ツリーのローカル クライアント ノードを展開します（ノードの左の展開アイコンをクリックします）。
2. ［MicroKernel ルーター］を右クリックします。
3. ［プロパティ］をクリックします。
4. プロパティ ツリーで［通信プロトコル］をクリックします。
5. ［サポート プロトコル］で、必要なプロトコルにはチェック マークが入って選択されており、使用されないプロトコルのチェック マークは外されているようにします。
6. ［適用］をクリックします。
これで、クライアントが、使用されていないプロトコルと通信しようとするのを妨ぐことができるようになりました。
7. プロパティ ツリーで［アクセス］をクリックします。
8. リモート サーバーまたはリモート ワークグループ エンジンのみを使用している場合は、［ローカル MicroKernel エンジンの使用］チェック ボックスの選択を解除し、オフに設定されるようにします。
ローカル ワークグループ エンジンのみを使用している場合は、［リモート MicroKernel エンジンの使用］チェック ボックスの選択を解除し、オフに設定されるようにします。
ワークグループ エンジンを使用することもあり、サーバー エンジンまたはリモート ワークグループ エンジンを使用することもある場合には、両方の設定を選択し、オンにしておく必要があります。
このような共有と非共有データの混合環境では、各クライアントで［ゲートウェイ一貫性保持］をオンに設定しておくことができます。この設定によって、データベース エンジンに接続することができないすべてのマシンの名前のリストを強制的にクライアント ソフトウェアに保持させます。クライアント ソフトウェアが、指定されたコンピューターにはエンジンが存在しないことを判定するには、すべてのネットワーク プロトコルのリクエストがタイムアウトになるまで待ちます。
Zen データベース エンジンを持たないサーバーにデータが格納されていて、［リモート MicroKernel エンジンの使用］の設定がオンの場合、クライアントはそのマシンにエンジンがないことを知るために少なくとも 1 度はタイムアウトを待たなければなりません。ゲートウェイ一貫性保持を使用すると、アプリケーションがそのデータに最初にアクセスしたときのみにこのタイムアウトが起きるようにできます。
メモ： ゲートウェイ一貫性保持を使用すると、ネットワーク トポロジを固定します。後に、リモート コンピューターに Zen サーバーまたはワークグループ エンジンをインストールする場合、各クライアントで［ゲートウェイ一貫性保持］をオフにして、データベース エンジンを持たないコンピューターのリストが削除されるようにする必要があります（これにより新しいデータベース エンジンに接続できるようになります）。［ゲートウェイ一貫性保持］に戻ると、リストは空になっています。
9. ［OK］をクリックします。
これで、クライアントが、使用されていないデータベース エンジンに接続しようとするのを防ぐことができます。
サーバーのプロパティ
サーバー側の接続待ち時間を最小限にするには
1. エクスプローラーで、ツリーのエンジン ノードを展開します（ノードの左の展開アイコンをクリックします）。
2. 設定を指定するデータベース エンジンを右クリックします。
3. ［プロパティ］をクリックします。
4. ［サポート プロトコル］で、必要なプロトコルにはチェック マークが入って選択されており、使用されないプロトコルのチェック マークは外されているようにします。
5. ［適用］をクリックします。
これで、サーバーが、使用されていないプロトコルと通信しようとするのを防ぐことができます。
メモ： サーバーの設定で選択したプロトコルの少なくとも 1 つが、クライアントの設定で選択されたものと同一であることを確認してください。サーバーとクライアントは同じプロトコルを使用しなければ通信できません。
6. プロパティ ツリーで［メモリの使用］をクリックします。
7. ［起動時のリソース割当］をクリックして、値をオン（チェック ボックスを選択）に設定します。
このオプションは、データベース エンジンが必要なすべてのメモリを割り当てるタイミングを、最初の接続要求が入ってきたときではなく、起動時とします。この値を選択すると、より多くのメモリが必要ですが、クライアントから見ると、エンジンの処理速度が速くなります。
8. ［非アクティブ時、最小の状態に戻す］をオフに設定します（チェック ボックスをクリア）。
このオプションは、データベース エンジンが非アクティブなときにも、リソースを解放してオペレーティング システムに戻さないことを指定します。すべてのリソースは割り当てられたままで、次のクライアント接続に備えられます。
9. ［OK］をクリックします。
10. これらの変更を有効にするために、［はい］をクリックしてエンジンを再起動します。
ランタイムのスループットを最大にする
最大スループットを得るための原理は、ここに挙げる非常に多くの要因に依存します。最も重要な要因をいくつかを挙げます。
• 十分な物理メモリ。ホスト システムの RAM が少なすぎる場合、異なるユーザーおよびプロセスが限られたリソースを競い合うと、システムはその時間と CPU サイクルのほとんどをメモリとディスクのスワップに費やすことになります。
• 十分な CPU 能力。CPU が、データ処理リクエストの流入量について行けなくなると、アプリケーションのパフォーマンスが悪影響を受けます。
• 十分なネットワーク帯域幅。ネットワークが遅かったり、高いコリジョン率によって悪影響を受けている場合、データベース エンジンはデータ アクセスのリクエスト間で休止状態になり、各クライアントでは低いパフォーマンスを示します。
• 最小限のディスク I/O。ディスク I/O は、メモリ I/O より著しく速度低下を招きます。十分なキャッシュを確保して、できる限りディスクにアクセスすることを避けます。
• 十分なリソース割り当て。大きな物理メモリが使用可能であっても、データベース エンジンの設定プロパティが人為的に低く設定されている場合には、データベースのパフォーマンスは悪くなります。
結局、最適化されたパフォーマンスは、ネットワークのボトルネック、ディスク I/O のボトルネック、メモリのボトルネック、および CPU のボトルネックの間を綱渡りすることで実現しています。以下のトピックでは、メモリおよびディスク I/O のボトルネックを減少させる方法のガイドラインをいくつか示します。
速いディスクと速い CPU
ハードウェアへの投入費用に対しパフォーマンス向上の効果を最大にしたければ、既存のパフォーマンスの制約を理解する必要があります。データベースが非常に大きくて、データベースの主要な部分をキャッシュに入れるための十分なメモリを購入してインストールするのが妥当でない場合、パフォーマンスはディスク I/O によって制約を受けがちです。これらの状況では、速い RAID ディスク配列に費用をかけてディスク I/O のパフォーマンスを最大にします。
さらに、アプリケーションがリレーショナル エンジンを使用していて一時ファイルを頻繁に作成する場合、これらのファイルが作成されるディレクトリが速いディスク ドライブであることを望むでしょう。このディレクトリの場所および一時ファイルを作成するクエリのタイプの詳細については、『SQL Engine Reference』のテンポラリ ファイルを参照してください。
データベースが小さくてメモリに全部またはほとんどがキャッシュできる場合、速いディスク配列の追加では著しいパフォーマンス向上を得る可能性はありません。このような状況下では、CPU をアップグレードするか CPU を追加することにより最高のパフォーマンス改善値が得られます。
十分な物理メモリとデータベース キャッシュを確保する
Pervasive.SQL バージョン 8 以降を使用する場合、データベース エンジンは設定プロパティで設定したキャッシュ割当サイズのレベル 1 キャッシュに加え、レベル 2 動的キャッシュを提供します。MicroKernel の最大メモリ使用量にゼロを設定してレベル 2 動的キャッシュを無効にしないとすれば、レベル 1 キャッシュ サイズを手動で調整するのは、以前のリリースよりずっと楽です。これを念頭において、このセクションでは、データベース エンジンの最適なパフォーマンスのための十分なメモリを確実に利用できるようにする方法を説明します。
理想的には、データベース エンジンが十分なメモリを割り当てることができ、管理する各データベースの完全なコピーをキャッシュできれば、ディスク I/O を最大限避けることができます。1 つまたは複数のデータベース全体をキャッシュするのは状況によって、特にデータベースサイズが非常に大きい場合には、明らかに実用的ではありません。さらに、既存のシステム リソースが通常の使用でも大きな負荷がかかっている場合、パフォーマンスを向上させる対策はマシンに RAM を追加することだけです。
データベース エンジンは最初に起動されたときに動的にレベル 1 キャッシュ値を選択します。ただし、この値は使用可能なメモリに基づいていて、その環境で理想的なキャッシュ量になるとは限りません。
データベースのメモリ キャッシュの理想的なサイズを計算するには
1. まず、データベース エンジンがサービスするすべてのデータベース ファイルのサイズを合計します。
メモ： エンジンがサービスするデータベースが 2 つ以上あっても、同時に使用されない場合は、大きい方のサイズだけを加算します。
たとえば、サーバーに 2 つのデータベースがあり、それぞれに含まれるファイル サイズは次のとおりで、ユーザーが同時に両方のデータベースにアクセスするとします。
データベース A | データベース B | ||
|---|---|---|---|
file1.mkd | 223 MB | Afile.mkd | 675 MB |
file2.mkd | 54 MB | Bfile.mkd | 54 MB |
file3.mkd | 92 MB | Cfile.mkd | 318 MB |
file4.mkd | 14 MB | ||
これらすべてのファイルの合計は 1,430 MB です。
今得た値は、データベース エンジンがホストするすべてのデータをキャッシュした場合に使用するメモリの最大量です。この数値を MaxCache と呼びます。
キャッシュ割当サイズに、これより大きい値を指定しようとは考えないでしょう。そうすることは、データベース エンジンにまったく使用しないと思われるメモリを割り当てることになるからです。実際の運用に妥当なのは、キャッシュ割当サイズに MaxCache の 20% から 70% を設定することです。この範囲中で低い値は読み取り処理の多いアプリケーションに最適で、高い値は書き込み処理の多いアプリケーションに最適です。それは、すべての書き込み/更新操作はレベル 1 キャッシュで行われるからです。
メモ： ファイル ページは、アクセスされたときにのみデータベース キャッシュに書き込まれます。したがって、データベース エンジンはデータベースのすべてのページがアクセスされるたびに MaxCache を必要とします。この評価方式により、長期間安定した状態でデータベース処理を行うことができます。データベース エンジンを毎晩または毎週停止する場合、一定の稼働時間内にデータベース エンジンが、データベースのすべてのページにアクセスすることはあまりありません。
このような状況の場合、一定の稼動期間にアプリケーションが別個のページに平均何回アクセスするかを見積もり、ページ サイズを掛けて、特定の稼動期間のより現実的な MaxCache の値を求めたいでしょう。
Zen MicroKernel Cache も参照してください。
このような状況の場合、一定の稼動期間にアプリケーションが別個のページに平均何回アクセスするかを見積もり、ページ サイズを掛けて、特定の稼動期間のより現実的な MaxCache の値を求めたいでしょう。
Zen MicroKernel Cache も参照してください。
Windows 32 ビット オペレーティング システムでは、すべてのユーザー プロセスのメモリは 2GB に制限されています。MaxCache の計算値が 2 GB より大きく、データベース エンジンが 32 ビット Windows オペレーティング システム上で実行される場合、選択する MaxCache 値によってエンジンが絶対に 2 GB の限界を超えないようにしていください。そうしないと、エンジンがメモリを割り当ることができず、その後、エラーになる可能性があります。
必要な物理メモリ総量を決定するには
次の方程式を使用して、データベース エンジンで必要とされる総物理メモリ量の近似値を割り出します。
データベースの最大メモリ使用量 = L1 キャッシュサイズ + 内部割り当て + L2 キャッシュサイズ
各項目の説明は次のとおりです。
L1 キャッシュ サイズ：キャッシュ割当サイズ
内部割り当て：L1 キャッシュの約 25% のサイズ
L2 キャッシュ サイズ：システムのメモリ ロードに基づいて拡大および縮小するメモリ容量
以下の点に注意してください。
• L1 キャッシュはキャッシュ割当サイズに基づく固定サイズです。このサイズはデータベース操作によって拡大したり縮小したりすることはありません。アプリケーションで多数の書き込み操作を行う場合は、この L1 キャッシュをできるだけ増やしてください。
• すべてのデータを L1 キャッシュに収容することができれば、最高のパフォーマンスが得られます。すべてのデータが L1 キャッシュに収容されない場合は、キャッシュ割当サイズおよび MicroKernel の最大メモリ使用量を調整して妥当なシステム メモリ量を使用します。
• L2 キャッシュは、システムのメモリ ロードに基づいて拡大および縮小します。たとえば、ほかのアプリケーションでより多くのメモリが必要となった場合、L2 キャッシュは縮小します。十分なメモリが使用可能であれば、L2 キャッシュは上記の方程式に基づいて最大量に達します。L2 キャッシュの拡大や縮小はパフォーマンスに影響します。縮小した場合は、データ ページが L2 キャッシュから除去されるなどの事象が起こります。ディスク ストレージからのデータ ページの読み取りは、キャッシュに保持されたデータ ページの読み取りと比べ、より時間がかかります。
• L2 キャッシュには圧縮データ ページが含まれます（少ないスペースにより多くのページが収まります）。L2 キャッシュからのページ アクセスは、L1 キャッシュからのページ アクセスよりも時間がかかりますが、ディスク ストレージからのページ アクセスに比べれば処理が速くなります。多数の読み取り操作を実行するアプリケーションで L2 キャッシュは役立ちますが、すべての読み取りデータ ページを L1 キャッシュに収容することはできません。
ディスク I/O を最小限にする
ディスクからの読み取りおよびディスクへの書き込みは、メモリに対するそれよりずっと時間がかかります。したがって、パフォーマンスを最適化する 1 つの方法はディスクの動作を最小限にすることです。
ディスク I/O を最小化する上での重要な考慮点はデータの回復の可能性です。ディスク I/O は、トランザクション一貫性および回復可能性に対する直接的な交換条件です。変更のログをディスクに書き込むための停止なしでデータをメモリに保持するほど、データベースのパフォーマンスは速くなります。一方、変更のログをディスクに書き込むための停止を行わずにデータをメモリに保持するほど、システムに異常をきたした場合に失うデータが増えます。
ディスク I/O を減少させるには
1. 前のサブセクション、十分な物理メモリとデータベース キャッシュを確保するで説明したように、最も重要な考慮点の 1 つは、ディスクおよびキャッシュ間のデータ ページの頻繁なスワップを避けるために十分なデータベース メモリ キャッシュを確保することです。詳細については、そのセクションを参照してください。
ディスク I/O を減らす最良の方法の 1 つは、動的なレベル 2 キャッシュを必ずオンにすることです。レベル 2 キャッシュはキャッシュ要求がレベル 1 固定キャッシュの容量を超えたとき、アプリケーションの使用量の変化によってサイズを動的に調整して可能な限り多くのデータをメモリに格納し、それによりディスク I/O を減らします。デフォルトで、レベル 2 キャッシュはオンになっています。データベース エンジンがレベル 2 キャッシュを使用していることを確認するには、設定プロパティの［MicroKernel の最大メモリ使用量］を調べます
2. 次に、システム異常の場合に、どれだけのロギングが必要で、どれだけのデータベース オペレーションを失ってもかまわないかを考慮します。失ってもかまわない変更が多いほど、パフォーマンスの向上を追求することができます。
アーカイブ ログの使用、 トランザクション一貫性保持、 およびトランザクション ログはすべてログ ファイルを必要とします。デフォルトで、アーカイブ ロギングはオフになっています。定期的なバックアップを実行し、システム異常の時点のデータに回復する能力を必要とする場合にのみこれをオンにします。ログの対象とするファイルを指定するときには、完全にログを必要とするファイルのみを指定するようにしてください。詳細については、第 章のログ、バックアップおよび復元を参照してください。
デフォルトで、トランザクション ログはオンになっています。トランザクション ログをオフにすると、パフォーマンスは若干向上しますが、複数ファイルの一貫性とトランザクション アトミシティは保証されません。トランザクション ログをオフにする前に、アプリケーションがこの機能を使用しないで実行できるかどうかをベンダーに確認してください。
注意！ トランザクション ログが無効な場合、複数ファイルのデータベースの整合性は保証されません。
デフォルトで、トランザクション一貫性保持はオフになっています。アプリケーションでシステム クラッシュが起きてもトランザクション処理が完了することを必要とする場合は、この機能を有効にします。トランザクション一貫性保持を使用すると、パフォーマンスに最も高いペナルティが課されますが、引き換えに完了したトランザクションの最高の安全性を引き出します。
3. いずれかのロギング機能をオンにしている場合、エンジンがディスクに書き込む前にどれだけのデータを保存するかを指定することができます。変更データは繰り返し作成されるので、この機能は重要です。メモリに構築するログ データの許容量が多いほど、ディスク書き込みの頻度は減ります。
［トランザクション ログ バッファー サイズ］設定は、エンジンがデータベース操作をログ ファイルに書き出す前に、メモリに格納しておくバイト数を指定します（サーバーのプロパティ ツリーで［パフォーマンス チューニング］をクリックします）。
システム異常の場合、ログ バッファー内のデータは失われます。
4. トランザクション一貫性保持をオンにしている場合、ディスク上のログセグメントの最大サイズを指定することができます。小さいログ セグメントは作成と閉じることを繰り返すので、大きなログ セグメント サイズを指定すると、若干パフォーマンスを向上させることができます。
［トランザクション ログ サイズ］設定は、ログ セグメントを閉じて新しいログ セグメントを開くまでにログ セグメントに格納できる最大バイト数を指定します（サーバーのプロパティ ツリーで［パフォーマンス チューニング］をクリックします）。
5. データベースの使用率が高い場合には、データ ファイルが存在するのとは物理的に異なるボリュームにログが保持されるようシステムを構成する必要があります。一般的に高負荷の下では、単一ドライブで I/O 帯域幅を競う代わりに、ログ ファイルへの書き込みとデータ ファイルへの書き込みを別々のドライブに分ける方がパフォーマンスがよくなります。全体的なディスク I/O は減少しませんが、ロードはディスク コントローラー間で効率よく分散されます。
6. アプリケーションの使用方法がデータベース読み取り処理に重点を置いている場合、［インデックス バランスの実行］を調整することにより、パフォーマンスを向上させることができます（サーバーのプロパティ ツリーで［パフォーマンス チューニング］をクリックします）。インデックス バランスは通常のインデックス ページのノード数を増やし、読み取り操作を速くします。ただし、Insert、Update、および Delete オペレーションでは、エンジンは隣接ページにまたがってインデックス ノードのバランスをとるため、ディスク I/O 時間が余計に必要になることがあります。
7. MicroKernel および ODBC レベルの両方でトレースを必ずオフにしてください。トレースは、多くのディスク I/O を引き起こすため、パフォーマンスを著しく低下させます。
ODBC のトレースがオフであることを確認するには、Zen Control Center から ODBC アドミニストレーターを起動します。ODBC アドミニストレーターで［トレース］タブをクリックします。トレースがオフの場合、［トレースの開始］と表示されたボタンがあるので、［キャンセル］をクリックします。トレースがオンの場合は、［トレースの停止］ボタンをクリックし、［OK］をクリックします。
MicroKernel のトレースがオフであることを確認するには、設定プロパティの［トレース オペレーションの実行］がオフに設定されている（チェックされていない）かを調べます（サーバーのプロパティ ツリーで［デバッグ］をクリックします）。
十分なリソース割り当てを確保する
データベース サーバー プラットフォームに十分なメモリおよび CPU パワーがある場合は、データベース エンジンが複数クライアントおよび複数データ ファイルを最も効果的にサービスできるよう、ハードウェア リソースを最大限利用できるようにしてください。
複数クライアントおよび複数ファイルを扱えるように設定するには
ガイドラインとして、この設定の値は、アプリケーションが平均的に開くファイル数のおよそ 1/8 にします。たとえば、アプリケーションがたいてい 40 ファイルを開く場合、 I/O スレッドを 5 に設定します。
Monitor を使用して、メニューから［MicroKernel］［リソースの使用状況］を選択します。ウィンドウが開き、［ファイル数］欄に、開いているファイル数の現在値とピーク値が表示されています。何度か現在値を記録して平均表示度数を出すことができます。その平均値に基づいて、I/O スレッド数に適切な設定をしてください。
大きいシステム キャッシュ
Windows オペレーティング システムによっては "大きいシステム キャッシュ" 設定を提供しています。これを使用すれば、システムが空きメモリを利用して最近アクセスしたデータをキャッシュすることができます。一部の Windows サーバーではデフォルトでこの設定がオンになっています。これは、単純なファイル共有には都合がよく、積極的にシステム キャッシュを増加させます。
ファイル キャッシュ用のメモリを積極的に使用すると、Zen をスワップ アウトすることがあります。これによってデータベースに伴う多くのパフォーマンス問題が発生する可能性があります。"大きなシステム キャッシュ" をオンにし、Zen の設定である［システム キャッシュ］の設定もオン（明示的、または［MicroKernel の最大メモリ使用量］をゼロに設定）にすると、パフォーマンスが低下する可能性があります。データベースのパフォーマンスを向上させるために考えられる解決策は、この "大きなシステム キャッシュ" をオフにすることです。
この設定をオフにするには、コントロール パネルまたはマイ コンピューターのプロパティからシステム プロパティにアクセスします。［詳細設定］タブをクリックし、［パフォーマンス］セクションの［設定］ボタンをクリックします。［パフォーマンス オプション］ダイアログで［詳細設定］タブをクリックします。
［メモリの使用量］セクションで、［システム キャッシュ］オプションが選択されている場合は、大きなシステム キャッシュがオンになっています。これをオフにするには、［メモリの使用量］のもう 1 つのオプションである "プログラム" を選択します。要求に応じて［OK］をクリックして開いているダイアログを閉じ、設定を反映させるためにオペレーティング システムを再起動します。
ハイパーバイザー製品でのパフォーマンス
Zen で最高のパフォーマンスを実現するには、以下の事項を順守してください。
• ハイパーバイザー ベンダーからのパフォーマンス最良実施例に従うこと。
• Zen をホストする仮想マシンに十分なメモリ（RAM）が確保されていること。
• ハイパーバイザー ホストには十分な数の仮想 CPU があり、同じマシン上の全仮想マシンの中で仮想 CPU の競合を最小化します。これにより、Zen を実行する仮想マシンとの競合が避けられます。共通（アフィニティ）規則を使用する場合は、必ずすべてのコアを同じソケットで実行するようにしてください。
• Zen データ ファイルは高速な物理ストレージに存在し、物理ストレージ デバイスに対するスピンドルの競合およびコントローラーの競合を最小化します。
最終更新日: 2024年07月09日