| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11g リリース1 (11.1.1) B61006-10 |
|
 前 |
 次 |
この章では、Oracle Metadata Services (MDS)のチューニングのヒントを示します。
Oracle Metadata Services (MDS)はアプリケーション・サーバーであるとともに、ClassPath、ServletContext、データベース・リポジトリおよび場合によってはファイル・システムなどの領域にメタデータが保存されているOracleリレーショナル・データベースでもあります。MDSの主な用途の1つは、Oracleアプリケーションのカスタマイズおよび永続的なパーソナライズの内容を格納することです。MDSは、Oracle WebCenter PortalやOracle Application Development Framework (ADF)などのコンポーネントによって、メタデータの管理に使用されます。MDSが管理するメタデータ・オブジェクトには、JSPページおよびページ・フラグメント、ADFページ定義およびタスク・フロー、これらのオブジェクトのカスタマイズ版などがあります。
|
注意: Oracle Metadata Services構成パラメータのほとんどは固定であり、特に指定のないかぎり実行時には変更できません。 |
MDSは、DMSセンサーを使用して、Enterprise Managerで参照可能なチューニングおよび診断の情報を提供しています。この情報は、MDSキャッシュのサイズが十分かどうかを確認する場合などに便利です。
DMSメトリックの情報は、Fusion Middleware Control Consoleコンソールで確認できます。ページ上部の「ヘルプ」をクリックすると、詳しい情報が表示されます。ほとんどの場合、ヘルプ・ウィンドウには現在のページに関するヘルプ・トピックが表示されます。ヘルプ・ウィンドウの「目次」をクリックして、ヘルプ・トピックのリストを参照するか、「検索」をクリックして特定の語句を検索します。
チューニングは、パフォーマンスを向上させるためのパラメータの調整です。MDSのデフォルト構成は、ほとんどすべてのデプロイメントでチューニングを必要とします。この項に記載されている要件および推奨事項を十分に確認してください。
MDS APIのパフォーマンスを最適化するために、MDSリポジトリのデータベース・スキーマはデータベース管理者が監視およびチューニングを行う必要があります。この項では、データベース・リポジトリをチューニングする際の推奨措置を示します。
データベース・チューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のインスタンスのパフォーマンスの最適化に関する項を参照してください。
MDSはデータベース索引を提供しますが、スキーマ統計が不足しているために、データベース索引が予想どおり使用されないことがあります。データベース・リポジトリのメタデータに対するアクセスや更新などのMDS操作でパフォーマンスが問題になっている場合、データベース管理者は、統計が利用でき、かつ最新であることを確認する必要があります。
次の例は、Oracleデータベースのスキーマ統計の収集方法を示しています。
execute dbms_stats.gather_schema_stats(ownname => '<username>' estimate_percent => dbms_stats.auto_sample_size, method_opt=> 'for all columns size auto', cascade=>true);
統計の収集後にパフォーマンスが向上しない場合は、次のコマンドを使用してデータベース共有プールをフラッシュし、既存のSQL計画を消去してください。
alter system flush shared_pool;
一般に、データベースは自動統計再収集を指定して構成します。統計収集の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』の自動パフォーマンス統計に関する項を参照してください。
REDOログ・ファイルのサイズはパフォーマンスに影響を与えます。これは、データベースのライター・プロセスおよびアーカイバ・プロセスの動作がREDOログのサイズによって変わるためです。一般に、REDOログ・ファイルが大きければ、パフォーマンスは向上します。ログ・ファイルのサイズが小さいと、チェックポイント・アクティビティが増加し、パフォーマンスが低下する可能性があります。
詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のREDOログ・ファイルのサイズ指定に関する項を参照してください。
手動および自動のパージ操作を行うとメタデータの内容がリポジトリから削除されますが、表や索引が保持している領域をデータベースがただちに解放しない場合があります。その結果、MDSスキーマが消費するディスク領域は増大していきます。データベース管理者は、手動で索引を再作成して表を小さくすることで、パフォーマンスを改善するとともにディスク領域を解放できます。
詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』の未使用領域の解放に関する項を参照してください。
データベース管理者は、(Oracleデータベースの自動ワークロード・リポジトリ(AWR)・レポートを生成するなどの方法で)データベースを監視してロックの競合やI/O使用率を観察し、問題解決のための適切な措置を取る必要があります。
詳細は、次のドキュメントを参照してください。
『Oracle Databaseパフォーマンス・チューニング・ガイド』の自動ワークロード・リポジトリ・レポートの生成に関する項
『Oracle Database管理者ガイド』のパフォーマンスの監視に関する項
MDSでは、キャッシュを使用してメタデータ・オブジェクトおよび関連オブジェクト(XMLコンテンツなど)をメモリーに格納しています。MDSキャッシュは、(同じJVM上の)アプリケーションのすべてのユーザーがアクセスできる共有キャッシュです。メタデータ・オブジェクトが同じカスタマイズ内容で繰り返し要求される場合、そのオブジェクトはキャッシュからすばやく取得されます(ウォーム読取り)。メタデータ・オブジェクトがキャッシュ内に見つからない場合(コールド読取り)、そのオブジェクトは、それ以降の読取り操作が容易になるように、キャッシュ構成、メタデータ・オブジェクトのタイプおよびアクセス頻度に応じてキャッシュに入れられます。
キャッシュは、デプロイ後にMBeanを介して構成または変更できます。この要素は、MDSAppConfig MBeanのMaximumCacheSize属性にマップされます。詳細は、『Oracle Fusion Middleware管理者ガイド』のデプロイ済アプリケーションのMDS構成属性の変更に関する項を参照してください。
|
注意: Enterprise Managerで参照できるMDSメトリックは、MDSキャッシュをチューニングする際に便利です。特に、 |
正しいサイズのキャッシュがあれば、メタデータ・オブジェクトを繰り返し読み取る際のスループットを大幅に改善できます。最適なキャッシュ・サイズは、使用されるメタデータ・オブジェクトの数および個々のサイズによって異なります。Enterprise ARchive (EAR)ファイルをパッケージングする前に、adf-config.xmlのcache-configを手動で更新できます。そのためには、次のエントリを追加します。
<mds-config>
<cache-config>
<max-size-kb>200000</max-size-kb>
</cache-config>
</mds-config>
|
注意: MDSキャッシュのサイズは、メタデータ・オブジェクトがアクセスされるにつれて、 |
MDSでは、メインのMDSキャッシュに加え、ドキュメント・キャッシュを各メタデータ・ストアとともに使用して、メタデータ・ドキュメント(基本ドキュメントおよびカスタマイズ・ドキュメント)のサムネイル情報をメモリーに格納します。各ドキュメントのエントリは小さく(100バイト未満)、ドキュメント・エントリ数によるキャッシュ・サイズ制限が指定されています。MDSでは、ドキュメント・キャッシュの適切なデフォルト・サイズ制限を、構成済のMDSキャッシュの最大サイズに基づいて次のように計算します。
MDSキャッシュが無効になっている場合、デフォルトではドキュメント・キャッシュを使用しません。
MDSキャッシュが有効になっている場合、デフォルトのドキュメント・キャッシュ・サイズは、構成済のドキュメント・キャッシュ1KB当たり1ドキュメント・エントリです。
cache-configが指定されていない場合、デフォルトは10000ドキュメント・エントリです。
MDSキャッシュが非常に小さい値に設定されている場合、ドキュメント・キャッシュの最小サイズとして500が使用されます。
一般に、ほとんどの場合はデフォルトで十分です。ただし、ドキュメント・キャッシュ・サイズが不足していると、パフォーマンスに影響が出ることがあります。Enterprise ARchive (EAR)ファイルをパッケージングする前に、次のエントリをadf-config.xmlに追加することで、ドキュメント・キャッシュ・サイズを明示的に設定できます。
<metadata-store-usage id="db1">
<metadata-store …>
<property name = …/>
</metadata-store>
<document-cache max-entries="10000"/>
</metadata-store-usage>
|
注意: ドキュメント・キャッシュは、document-cache max-entries値を超えるとクリアされます。パフォーマンスの問題を回避するため、次のような通知を受信した場合はドキュメント・キャッシュ・サイズを大きくすることを検討してください。
|
DMSメトリック「ドキュメント取得当たりのIO」(Enterprise Managerで参照可能。第7.2項を参照)に1より小さい値を指定する必要があります。指定しない場合は、ドキュメント・キャッシュ・サイズを大きくすることを検討してください。
MDSは、データベースのメタデータ・ストアにドキュメント・バージョン履歴を保持しています。バージョン履歴が蓄積するにつれて、必要なディスク領域が増え、読取り/書込みのパフォーマンスが低下します。ドキュメント・バージョンがアクティブ・ラベルの一部でない場合は、次の2つの方法でバージョン履歴をパージできます。
|
注意: バージョン履歴を手動でパージする場合、最後のパージ以降に行われたメタデータ更新の回数によっては、パフォーマンスに影響が出ることがあります。 |
自動パージ間隔は、デプロイ後にMBeanを介して構成または変更できます。この要素は、MDSAppConfig MBeanのAutoPurgeTimeToLive属性にマップされます。アプリケーションでMDSのデータベース・ストアが使用されている場合は、EARをパッケージングする前に、次のエントリをadf-config.xmlに追加することで、自動パージを設定できます。
<persistence-config> <auto-purge seconds-to-live="T"/> </persistence-config>
上の例では、自動パージはT秒ごとに実行され、指定した時間T(秒)より古いバージョンが削除されます。詳細は、『Oracle Fusion Middleware管理者ガイド』のデプロイ済アプリケーションのMDS構成属性の変更に関する項を参照してください。
|
ヒント: 自動パージ間隔は、アプリケーションで作成されたドキュメント・バージョンに基づいて調整します。作成されたバージョンの数によっては、パージに長時間かかることがあります。詳細は、第28.3.6項「MDSキャッシュ・サイズおよびパージ頻度の設定」を参照してください。 |
データベース領域の不足やパフォーマンスの低下が疑われるときは、WLSTコマンドまたはOracle Enterprise Managerを使用して、既存のバージョン履歴を手動でパージできます。手動でのパージはパフォーマンスに影響を与えることがあるため、メンテナンス期間内やシステムの利用率が低いときにパージを行う計画を立ててください。
バージョン履歴の手動パージの詳細は、『Oracle Fusion Middleware管理者ガイド』のメタデータ・バージョン履歴のパージに関する項を参照してください。
MDSでは、データベースに対して問合せを行い、MDSメモリー内キャッシュのデータとデータベースのデータの同期が外れているかどうかを判断する、ポーリング・スレッドを採用しています。この処理は、他のJVMでメタデータが更新されたときに発生します。同期が外れている場合、MDSは、その後の操作で最新バージョンのメタデータが参照されるように、古いキャッシュ・データをクリアします。また、MDSキャッシュだけでなくドキュメント・キャッシュも無効にするため、その後の操作では最新バージョンのメタデータが使用されます。
ポーリング間隔は、デプロイ後にMBeanを介して構成または変更できます。この要素は、MDSAppConfig MBeanのExternalChangeDetection属性およびExternalChangeDetectionInterval属性にマップされます。Enterprise ARchive (EAR)ファイルをパッケージングする前に、次のエントリをadf-config.xmlに追加することで、ポーリング間隔を構成できます。
<mds-config>
<persistence-config>
<external-change-detection enabled="true" polling-interval-secs="T"/>
</persistence-config>
</mds-config>
上の例では、Tは秒単位のポーリング間隔を示しています。最小値は1です。小さい値を指定すると、他のJVMで行われたメタデータの更新がすぐに参照されます。ただし、小さい値を指定した場合は問合せが頻繁に実行されるため、中間層およびデータベースのCPU消費量が増加することに注意してください。デフォルトでは、ポーリングは有効(true)になっており、デフォルト値の30秒で大半の目的に対応できます。詳細は、『Oracle Fusion Middleware管理者ガイド』のデプロイ済アプリケーションのMDS構成属性の変更に関する項を参照してください。
|
注意: ポーリング間隔を設定する際には、次の点を考慮してください。ポーリングの頻度が高すぎると、データベースに問い合せたときに古いバージョンが取得されてしまいます。頻度が低すぎると、古いバージョンがたまっていき、ポーリングの処理に長時間かかることがあります。 |
前の項で推奨されている変更を行った後、デプロイメントに固有の変更をさらに行うことができます。この項の推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。
MDSをカスタマイズすると、実行時のパフォーマンスに影響が出ることがあります。カスタマイズの影響は、次のような多くの要因によって変わります。
作成したカスタマイズのタイプ(共有か、ユーザー・レベルか)
システム内でメタデータ・オブジェクトがカスタマイズされている割合。この割合が低ければ、カスタマイズの影響は小さくなります。
構成されているカスタマイズ・レイヤーの数とカスタマイズの効率。
カスタマイズは主に2つのタイプに分けられます。
共有のカスタマイズ: getCacheHintメソッドがALL_USERSまたはMULTI_USERを返すカスタマイズ・クラスに対応するカスタマイズ・レイヤーです。このレイヤーは、すべてまたは複数のユーザーに適用されます。共有のカスタマイズは、(共有の)MDSキャッシュにキャッシュされます。
ユーザー・レベルのカスタマイズ(パーソナライズとも呼びます): getCacheHintメソッドがSINGLE_USERを返すカスタマイズ・クラスに対応するカスタマイズ・レイヤーです。このレイヤーは、1人のユーザーのみに適用されます。ユーザーによるカスタマイズは一般に、ユーザーがログアウトするまで、そのユーザーのセッション(HttpSession)にキャッシュされます。
カスタマイズの概念とカスタマイズ・クラスの記述および構成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のMDSによるアプリケーションのカスタマイズに関する項を参照してください。
