Oracle Metadata Serviceのチューニング

7 Oracle Metadata Serviceのチューニング

Oracle Metadata Services (MDS)をチューニングし、アプリケーション・サーバーおよびOracleリレーショナル・データベースとして、そのパフォーマンスを最適化できます。

Oracle Metadata Services (MDS)について
Oracle Metadata Services (MDS)はアプリケーション・サーバーであるとともに、ClassPath、ServletContext、データベース・リポジトリおよび場合によってはファイル・システムなどの領域にメタデータが保存されているOracleリレーショナル・データベースでもあります。
Oracle Metadata Serviceのパフォーマンスのモニタリング
MDSは、DMSセンサーを使用して、Enterprise Managerで参照可能なチューニングおよび診断の情報を提供しています。この情報は、MDSキャッシュのサイズが十分かどうかを確認する場合などに便利です。
チューニングに関する基本的な考慮事項
MDS構成のチューニングは、パフォーマンス向上に不可欠です。
チューニングに関する高度な考慮事項
推奨されている変更を行った後、デプロイメントに固有の変更をさらに追加できます。高度なチューニングの推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。

Oracle Metadata Services (MDS)について

Oracle Metadata Services (MDS)はアプリケーション・サーバーであるとともに、ClassPath、ServletContext、データベース・リポジトリおよび場合によってはファイル・システムなどの領域にメタデータが保存されているOracleリレーショナル・データベースでもあります。

MDSの主な用途の1つは、Oracleアプリケーションのカスタマイズおよび永続的なパーソナライズを格納することです。MDSは、Oracle Application Development Framework (ADF)などのコンポーネントによって、メタデータの管理に使用されます。MDSが管理するメタデータ・オブジェクトには、JSPページおよびページ・フラグメント、ADFページ定義およびタスク・フロー、これらのオブジェクトのカスタマイズ版などがあります。

ノート:

Oracle Metadata Services構成パラメータのほとんどは固定であり、特に指定のないかぎり実行時には変更できません。

Oracle B2Bおよびその他のOracle製品をチューニングする前にMDS表領域およびキャッシュ・サイズをチューニングすることは重要です。Oracle B2Bのユーザーズ・ガイドを使用してB2Bをチューニングする場合は、ここに記載されているチューニングを完了していることを最初に確認してください。

親トピック: Oracle Metadata Serviceのチューニング

Oracle Metadata Serviceのパフォーマンスのモニタリング

MDSは、DMSセンサーを使用して、Enterprise Managerで参照可能なチューニングおよび診断の情報を提供しています。この情報は、MDSキャッシュのサイズが十分かどうかを確認する場合などに便利です。

DMSメトリックの情報は、Fusion Middleware Controlコンソールで確認できます。ページ上部の「ヘルプ」をクリックすると、詳しい情報が表示されます。ほとんどの場合、ヘルプ・ウィンドウには現在のページに関するヘルプ・トピックが表示されます。ヘルプ・ウィンドウの「目次」をクリックして、ヘルプ・トピックのリストを参照するか、「検索」をクリックして特定の語句を検索します。

親トピック: Oracle Metadata Serviceのチューニング

チューニングに関する基本的な考慮事項

MDS構成のチューニングは、パフォーマンス向上に不可欠です。

MDSのデフォルト構成は、ほとんどすべてのデプロイメントでチューニングを必要とします。要件と推奨事項を十分に確認することが重要です。

親トピック: Oracle Metadata Serviceのチューニング

データベース・リポジトリのチューニング

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ログのサイズによって変わるためです。一般に、REDOログ・ファイルが大きければ、パフォーマンスは向上します。ログ・ファイルのサイズが小さいと、チェックポイント・アクティビティが増加し、パフォーマンスが低下する可能性があります。

詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のREDOログ・ファイルのサイズ指定に関する項を参照してください。

親トピック: データベース・リポジトリのチューニング

ディスク領域の解放

手動および自動のパージ操作を行うとメタデータの内容がリポジトリから削除されますが、表や索引が保持している領域をデータベースがただちに解放しない場合があります。その結果、MDSスキーマが消費するディスク領域は増大していきます。データベース管理者は、手動で索引を再作成して表を小さくすることで、パフォーマンスを改善するとともにディスク領域を解放できます。

詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』の未使用領域の解放に関する項を参照してください。

親トピック: データベース・リポジトリのチューニング

データベース・パフォーマンスのモニタリング

データベース管理者は、(Oracleデータベースの自動ワークロード・リポジトリ(AWR)・レポートを生成するなどの方法で)データベースをモニターしてロックの競合やI/O使用率を観察し、問題解決のための適切な措置を取る必要があります。

参照:

『Oracle Databaseパフォーマンス・チューニング・ガイド』の自動ワークロード・リポジトリ・レポートの生成に関する項
『Oracle Databaseパフォーマンス・チューニング・ガイド』のパフォーマンスのモニタリングに関する項。

親トピック: データベース・リポジトリのチューニング

キャッシュ構成のチューニング

MDSでは、キャッシュを使用してメタデータ・オブジェクトおよび関連オブジェクト(XMLコンテンツなど)をメモリーに格納しています。MDSキャッシュは、(同じJVM上の)アプリケーションのすべてのユーザーがアクセスできる共有キャッシュです。メタデータ・オブジェクトが同じカスタマイズ内容で繰り返し要求される場合、そのオブジェクトはキャッシュからすばやく取得されます(ウォーム読取り)。メタデータ・オブジェクトがキャッシュ内に見つからない場合(コールド読取り)、そのオブジェクトは、それ以降の読取り操作が容易になるように、キャッシュ構成、メタデータ・オブジェクトのタイプおよびアクセス頻度に応じてMDSによりキャッシュに入れられます。

キャッシュは、デプロイ後にMBeanを介して構成または変更できます。この要素は、MDSAppConfig MBeanのMaximumCacheSize属性にマップされます。詳細は、『Oracle Fusion Middlewareの管理』のデプロイしたアプリケーションのMDS構成属性の変更に関する項を参照してください。

ノート:

Enterprise Managerで参照できるMDSメトリックは、MDSキャッシュをチューニングする際に便利です。特に、「MOコンテンツ取得当たりのIO」または「メタデータ・オブジェクト取得当たりのIO」に1より小さい値を指定する必要があります。指定しない場合は、MDSキャッシュのサイズを大きくすることを検討してください。DMSメトリック情報の表示の詳細は、を参照してください。

正しいサイズのキャッシュがあれば、メタデータ・オブジェクトを繰り返し読み取る際のスループットを大幅に改善できます。最適なキャッシュ・サイズは、使用されるメタデータ・オブジェクトの数および個々のサイズによって異なります。Enterprise ARchive (EAR)ファイルをパッケージングする前に、次のエントリを追加して、adf-config.xmlファイルを手動で更新します。

<mds-config>
  <cache-config>
    <max-size-kb>200000</max-size-kb>
  </cache-config>
</mds-config>

ノート:

MDSキャッシュのサイズは、メタデータ・オブジェクトがアクセスされるにつれて、max-size-kbに達するまで増大していきます。その後、必要に応じてオブジェクトがキャッシュから削除されます。この処理は、新しいオブジェクトを格納できるだけの余裕を持たせるために、最低使用頻度(LRU)に基づいて行われます。

ドキュメント・キャッシュの有効化

親トピック: チューニングに関する基本的な考慮事項

ドキュメント・キャッシュの有効化

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値を超えるとクリアされます。パフォーマンスの問題を回避するため、次のような通知を受信した場合はドキュメント・キャッシュ・サイズを大きくすることを検討してください。

通知: ドキュメント・キャッシュDBMetadataStore : MDS Repository connection = <>で最大エントリ数<NNNN>を超えたため、キャッシュがクリアされます。

DMSメトリック「ドキュメント取得当たりのIO」(Enterprise Managerで参照可能。「Oracle Metadata Serviceのパフォーマンスのモニタリング」を参照)に1より小さい値を指定する必要があります。指定しない場合は、ドキュメント・キャッシュ・サイズを大きくすることを検討してください。

親トピック: キャッシュ構成のチューニング

ドキュメント・バージョン履歴のパージ

MDSは、データベースのメタデータ・ストアにドキュメント・バージョン履歴を保持しています。バージョン履歴が蓄積するにつれて、必要なディスク領域が増え、読取り/書込みのパフォーマンスが低下します。ドキュメント・バージョンがアクティブ・ラベルの一部でない場合は、自動または手動でバージョン履歴をパージできます。

ノート:

バージョン履歴を手動でパージする場合、最後のパージ以降に行われたメタデータ更新の回数によっては、パフォーマンスに影響が出ることがあります。

親トピック: チューニングに関する基本的な考慮事項

自動パージの使用

自動パージ間隔は、デプロイ後に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構成属性の変更に関する項を参照してください。

親トピック: ドキュメント・バージョン履歴のパージ

手動パージ

データベース領域の不足やパフォーマンスの低下が疑われるときは、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構成属性の変更に関する項を参照してください。

ノート:

ポーリング間隔を設定する際には、次の点を考慮してください。ポーリングの頻度が高すぎると、データベースに問い合せたときに古いバージョンが取得されてしまいます。頻度が低すぎると、古いバージョンがたまっていき、ポーリングの処理に長時間かかることがあります。

親トピック: チューニングに関する基本的な考慮事項

チューニングに関する高度な考慮事項

推奨されている変更を行った後、デプロイメントに固有の変更をさらに追加できます。高度なチューニングの推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。

カスタマイズがパフォーマンスに与える影響の分析

親トピック: Oracle Metadata Serviceのチューニング

カスタマイズがパフォーマンスに与える影響の分析

MDSをカスタマイズすると、実行時のパフォーマンスに影響が出ることがあります。カスタマイズの影響は、次のような多くの要因によって変わります。

作成したカスタマイズのタイプ(共有か、ユーザー・レベルか)
システム内でメタデータ・オブジェクトがカスタマイズされている割合。この割合が低ければ、カスタマイズの影響は小さくなります。
構成されているカスタマイズ・レイヤーの数とカスタマイズの効率。

カスタマイズは主に2つのタイプに分けられます。

共有のカスタマイズ: getCacheHintメソッドがALL_USERSまたはMULTI_USERを返すカスタマイズ・クラスに対応するカスタマイズ・レイヤーです。このレイヤーは、すべてまたは複数のユーザーに適用されます。共有のカスタマイズは、(共有の)MDSキャッシュにキャッシュされます。
ユーザー・レベルのカスタマイズ(パーソナライズとも呼びます): getCacheHintメソッドがSINGLE_USERを返すカスタマイズ・クラスに対応するカスタマイズ・レイヤーです。このレイヤーは、1人のユーザーに適用されます。ユーザーによるカスタマイズは、ユーザーがログアウトするまで、そのユーザーのセッション(Session)にキャッシュされます。

カスタマイズの概念とカスタマイズ・クラスの記述および構成の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「MDSによるアプリケーションのカスタマイズ」を参照してください。

親トピック: チューニングに関する高度な考慮事項