10gリリース3（10.1.3.1.0）
B31836-02
 目次 |
 索引 |
| Oracle Application Server パフォーマンス・ガイド 10gリリース3（10.1.3.1.0） B31836-02 |
|
Oracle Business Activity Monitoringのパフォーマンスを最大化するには、Oracle Business Activity Monitoringシステム専用のハードウェアを用意し、それにデータベースを配置します。また、この章で説明するデータベース管理を実践することで、Oracle Business Activity Monitoringの着信トランザクションのスループットを最大化できます。これらのデータベース管理は、Oracle Business Activity Monitoringシステムに特化された検証テストと監視情報に基づいています。Databaseパフォーマンス・チューニング・ガイドに説明されている一般的なデータベース管理方法も、Oracle Business Activity Monitoring専用のデータベースに適用されます。
この章には、次の項が含まれています。
Oracle Business Activity Monitoringによる入力データの受信率が高くなると、Oracle Business Activity Monitoring Active Data Cache（ADC）が受信したデータをデータベースに送信し、使用可能な入力帯域幅がほとんどあるいはまったくなくなる状態がADCサーバーで生じます。そのため、データベースがADCサーバーからの受信データをどれくらいの率で取得できるかが、入力データのスループットを制限する要因となります。データの取得率が高くなると、ログ・ファイル同期とも呼ばれる、データベースがREDOログ・レコードをディスクに書き込む機能によって、データベースのスループットが制限されます。アプリケーション、この場合はADCサーバーが、REDOログ・データがディスクに書き込まれる速度よりも速くデータをコミットすると、以降のトランザクション・コミット・リクエストまたはロールバック・リクエストは待機が必要になります。
REDOログ・ファイルのチューニングの最終的な目標は、挿入スループットの制限要因となる、ログ・ファイルの同期待ちを軽減または除去することです。Oracleデータベースでログ・ファイルの同期待ち数を減らすには、次の2つの戦略が有効です。
REDOログ同期用の帯域幅は、RAIDまたはオペレーティング・システム・ベースのストライプ化メカニズムを使用して、REDOログ・ファイルを複数のディスクにストライプ化する方法でも増やせます。ログ同期アクティビティでは順次書込みが実行されるため、32Kや64Kなどのようにストライプ・サイズを大きくすると最高のパフォーマンスを得られます。
Oracleデータベースには、少なくとも2つのREDOログ・ファイルが必要です。これによって、1つのファイルがフルになると別のファイルにスイッチし、そのファイルの領域を非同期式に解放できます。頻繁なログ・スイッチはデータベースのパフォーマンスを大きく低下させるため、スイッチの頻度が許容可能なレベルまで下がるように、REDOログ・ファイルのサイズを調整する必要があります。原則として、ログ・スイッチは20分に1回を超えないようにします。
ログ・スイッチの頻度を調べるには、データベースの初期化パラメータLOG_CHECKPOINTS_TO_ALERTをTRUEに設定します。これによって、ログ・スイッチ・イベントがデータベース・アラート・ログにタイムスタンプとともに書き込まれ、ログ・スイッチが過度に生じていないかどうかをアラート・ログで監視できます。
同様に、増分チェックポイントもパフォーマンス低下の要因になります。データベースのクラッシュ・リカバリ時に処理が必要となるREDOログの量を制限するために（つまり、システム障害後のデータベースの起動時間を短縮するために）、データベースは一定の間隔でREDOログにチェックポイントを設定します。LOG_CHECKPOINTS_TO_ALERTパラメータをTRUEに設定すると、これらのチェックポイント・イベントがアラート・ログに書き込まれます。
通常、増分チェックポイントの頻度は暗黙的に設定されます。FAST_START_MTTR_TARGET初期化パラメータを設定すると、ターゲット・インスタンスに対して、クラッシュ後のクラッシュ・リカバリ時の起動時間を指定できます。FAST_START_MTTR_TARGETを大きな値に設定すると、増分チェックポイントの頻度が減少し、ランタイム・パフォーマンスが向上します（その一方で、インスタンス起動時のクラッシュ・リカバリ時間が犠牲になる）。FAST_START_MTTR_TARGETを小さな値に設定すると、増分チェックポイントの頻度が増加し、インスタンス起動時に必要なクラッシュ・リカバリ時間が短縮されますが、ランタイム・パフォーマンスが犠牲となります。アプリケーションの要件に基づいて、このトレードオフを分析する必要があります。ランタイム・パフォーマンスが最重要要件の場合は、初期化パラメータFAST_START_MTTR_TARGETを十分大きな値に設定し、増分チェックポイントが発生しないようにします。この場合、チェックポイントはログ・スイッチ時に作成されます。
|
関連項目
|
Oracle Business Activity Monitoringデータベースのパフォーマンスは、データベースのシステム・グローバル領域（SGA）のdb_cacheおよびlog_bufferに対して指定されるサイズと、SGA全体のサイズ（このサイズは、SGA内で管理されるオブジェクトのサイズに基づいて指定される）に大きく影響されます。
Oracle Business Activity Monitoring専用データベースのSGAは、最小サイズの1024MBに構成します。SGAサイズは、SGA_MAX_SIZE初期化パラメータを使用して設定します。SGA内のメモリー・プールの値は、SGA自動チューニングを使用して設定するか、または固定サイズのプールを使用します。自動チューニングを指定するには、SGA_TARGET初期化パラメータをSGA_MAX_SIZEと同じ値に設定します。
SGA内部のメモリー・プールは手動設定したほうが、よいパフォーマンスが得られる可能性があります。SGAの自動チューニングを無効化するには、SGA_TARGET初期化パラメータを0に設定します。SGAの最大サイズが1024MBに設定されているインストールで自動チューニングを無効化したときは、初期設定として例8-1に示す設定をお薦めします。
db_cache_size = 820M java_pool_size = 16M large_pool_size = 16M streams_pool_size = 16M shared_pool_size = 144M log_buffer = 10485760
データベースのキャッシュまたはバッファ・プールには、データベース内の最近アクセスされたデータが保持され、これによって同じデータ・ページの再度の読取りが不要になります。Oracle Business Activity Monitoringデータベースの場合、データベースへの挿入パフォーマンスは、主キーの制約チェックの速度に依存しますが、これはデータベース・キャッシュに保持されている各主キーに作成されている索引を介して実行されます。バッファ・プールのヒット率は、データベース・キャッシュのサイズが小さすぎないかどうかを調べる際のよい指標になります。通常のデータベースでは、ヒット率は95%を超えるようにします。Oracle Business Activity Monitoringデータベースでは、ヒット率を99%以上に維持することをお薦めします。受信データのデータベースへの挿入がワークロードの大半となるデータベースでは、一般的に、これくらいの値が必要です。主要なワークロードがレポート問合せの場合は、バッファ・プールのヒット率は95%が有効な目安です。バッファ・プールのヒット率は、次の問合せを使用して取得できます。
SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS, 1 - (PHYSICAL_READS / (DB_BLOCK_GETS + CONSISTENT_GETS)) "Hit Ratio" FROM V$BUFFER_POOL_STATISTICS;
Oracle Business Activity Monitoringは、ログのバッファ・サイズにも大きく影響されます。データベースにログ・ファイルの同期待ちがあるときは、コミット処理を保留中のすべてのリクエストがログ・バッファに格納されます。ログ・ファイルの同期待ちが多数になると、ログ・バッファがフルになることがあります。これが原因でログ・バッファへのリクエストが実行不能になると、リクエスト元は、ログ・バッファの再試行と呼ばれる機能によって、しばらくしてから再度リクエストを実行します。
ログ・バッファの再試行は、パフォーマンスを大きく低下させる原因となります。データ入力のバッチ・サイズが大きいワークロードや、ログ・バッファの再試行数が多いワークロードがあるときは、ログ・バッファ・サイズの増加が必要となる場合があります。
データベースでバッファの再試行を監視するには、次の問合せを使用します。
SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME = 'redo buffer allocation retries';
通常、このメトリックは、ワークロードの開始時の値とワークロードの終了時の値を収集することで測定され、これらの2つの値の差異がワークロードの実行に必要なログ・バッファの再試行数を示します。テスト・ワークロードの開始時にデータベースを再起動した場合は、開始値が0となるため、終了値のみが必要です。10分程度の間隔では、ログ・バッファの再試行数が100未満である必要があります（理想的なケースでは、値は0になる）。この値が100から300の範囲であればパフォーマンスへの影響は許容範囲ですが、これよりも大きいと無視できなくなります。
ログ・バッファやデータベース・キャッシュなどのSGAコンポーネントのサイズを増やすことも重要ですが、SGAの全体サイズを同じだけ増やすことも重要です（コンポーネントのサイズを増加した分、全体サイズも増加する）。そうしないと、サイズを増加したコンポーネントによって、SGA内の他のオブジェクト用のメモリーが占有されます。
Oracle Business Activity Monitoringをインストールすると、Oracle Business Activity Monitoring表領域のORACLEBAMが作成され、データセットとメタデータが保持されます。Oracle Business Activity Monitoringユーザーがデータセットを作成すると、Oracle Database表が作成され、データセット内のオブジェクトが格納されます。この表には、SysIterIDという名前のシステム生成の主キーがあります。Oracle Business Activity MonitoringユーザーがOracle Business Activity Monitoringデータセット内の列にOracle Business Activity Monitoring索引を作成すると、データベース内の対応する表に、対応する索引が作成されます。
Oracle Business Activity Monitoring表領域は、自動セグメント領域管理機能が有効化されて作成されます。これによって、Oracle Business Activity Monitoring表にマップされているセグメント内の空き領域管理が支援され、さらにはデータベースの再編成時にシステムの停止が不要になります。ただし、データベースの手動再編成の必要性が完全になくなるわけではなく、特に、削除アクティビティが相当な回数実行された後などは注意が必要です。
削除アクティビティが相当量実行されると、Oracle Business Activity Monitoringデータセット表にマップされているセグメントのデータ密度が散在的になる場合があります。この状況は一般的に内部フラグメンテーションと呼ばれ、表操作の実行時に必要なI/O回数が急激に増加する原因となります。内部フラグメンテーションがあると、主キーに対する索引を含め、表に対して作成された索引の構造が、多数の削除操作の実行後に、最適なバランス構成でなくなります。そのため、多数の削除操作の実行後は、データベースの再編成を行い、索引の構造を改善して、より少ないデータ・ページに表の行が効率的に収まるようにする必要があります。または、不要になったOracle Business Activity Monitoringデータを削除するスクリプトを記述し、その削除ジョブの一部として再編成を行うこともできます。
Oracle Business Activity Monitoringデータセット表のセグメントを再編成するプロシージャは、表の主キーの削除、表の索引の削除、表の行移動の有効化、表領域の縮小、表内の未使用領域の割当て解除、表の主キーの再作成、表の索引の再作成、および表の行移動の無効化の各手順で構成されます。
例8-2に、データベース表の_Call_Detailおよび_Call_Aggに格納されている2つのOracle Business Activity MonitoringデータセットCall_DetailおよびCall_Aggのセグメントを再編成するサンプル・スクリプトを示します。
alter table "ORABAM"."_Call_Detail" drop primary key; alter table "ORABAM"."_Call_Agg" drop primary key; <drop indexes on "ORABAM"."_Call_Detail"> <drop indexes on "ORABAM"."_Call_Agg"> alter table "ORABAM"."_Call_Detail" enable row movement; alter table "ORABAM"."_Call_Agg" enable row movement; < Note: include deletion activity here, if it is added as part of the script> alter table "ORABAM"."_Call_Detail" shrink space; alter table "ORABAM"."_Call_Agg" shrink space; alter table "ORABAM"."_Call_Detail" deallocate unused; alter table "ORABAM"."_Call_Agg" deallocate unused; alter table "ORABAM"."_Call_Detail" disable row movement; alter table "ORABAM"."_Call_Agg" disable row movement; alter table "ORABAM"."_Call_Detail" add primary key ("SysIterID"); alter table "ORABAM"."_Call_Agg" add primary key ("SysIterID"); <rebuild indexes on "ORABAM"."_Call_Detail"> <rebuild indexes on "ORABAM"."_Call_Detail">
|
注意 行移動を有効化してOracle Business Activity Monitoring表を実行するよう構成する場合は、例8-2に示すスクリプトを変更し、行移動の無効化コマンドを削除する必要があります。 |
Oracle Business Activity Monitoringユーザーは、複数のプラン・モニター・サービスと複数のエンタープライズ・リンクを構成することで、パフォーマンスを改善できます。
|
 Copyright © 2001, 2008, Oracle. All Rights Reserved. |
|