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をチューニングする場合は、ここに記載されているチューニングを完了していることを最初に確認してください。
MDSは、DMSセンサーを使用して、Enterprise Managerで参照可能なチューニングおよび診断の情報を提供しています。この情報は、MDSキャッシュのサイズが十分かどうかを確認する場合などに便利です。
DMSメトリックの情報は、Fusion Middleware Controlコンソールで確認できます。ページ上部の「ヘルプ」をクリックすると、詳しい情報が表示されます。ほとんどの場合、ヘルプ・ウィンドウには現在のページに関するヘルプ・トピックが表示されます。ヘルプ・ウィンドウの「目次」をクリックして、ヘルプ・トピックのリストを参照するか、「検索」をクリックして特定の語句を検索します。
チューニングは、パフォーマンスを向上させるためのパラメータの調整です。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パフォーマンス・チューニング・ガイド』の未使用領域の解放に関する項を参照してください。
MDSでは、キャッシュを使用してメタデータ・オブジェクトおよび関連オブジェクト(XMLコンテンツなど)をメモリーに格納しています。MDSキャッシュは、(同じJVM上の)アプリケーションのすべてのユーザーがアクセスできる共有キャッシュです。メタデータ・オブジェクトが同じカスタマイズ内容で繰り返し要求される場合、そのオブジェクトはキャッシュからすばやく取得されます(「ウォーム」読取り)。メタデータ・オブジェクトがキャッシュ内に見つからない場合(「コールド」読取り)、そのオブジェクトは、それ以降の読取り操作が容易になるように、キャッシュ構成、メタデータ・オブジェクトのタイプおよびアクセス頻度に応じてMDSによりキャッシュに入れられます。
キャッシュは、デプロイ後にMBeanを介して構成または変更できます。この要素は、MDSAppConfig
MBeanのMaximumCacheSize
属性にマップされます。詳細は、『Oracle Fusion Middlewareの管理』のデプロイしたアプリケーションのMDS構成属性の変更に関する項を参照してください。
注意:
Enterprise Managerで参照できるMDSメトリックは、MDSキャッシュをチューニングする際に便利です。特に、「MOコンテンツ取得当たりのIO」
または「メタデータ・オブジェクト取得当たりのIO」
に1より小さい値を指定する必要があります。指定しない場合は、MDSキャッシュのサイズを大きくすることを検討してください。DMSメトリックに関する情報の表示の詳細は、Oracle Metadata Serviceのパフォーマンスのモニタリングを参照してください。
正しいサイズのキャッシュがあれば、メタデータ・オブジェクトを繰り返し読み取る際のスループットを大幅に改善できます。最適なキャッシュ・サイズは、使用されるメタデータ・オブジェクトの数および個々のサイズによって異なります。Enterprise ARchive (EAR)ファイルをパッケージングする前に、adf-config.xmlのcache-configを手動で更新できます。そのためには、次のエントリを追加します。
<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構成属性の変更に関する項を参照してください。
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人のユーザーのみに適用されます。ユーザーによるカスタマイズは一般に、ユーザーがログアウトするまで、そのユーザーのセッション(Session)にキャッシュされます。
カスタマイズの概念とカスタマイズ・クラスの記述および構成の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のMDSによるアプリケーションのカスタマイズに関する項を参照してください。