| Oracle® Exadata System Softwareユーザーズ・ガイド 18.1.0 E84909-07 |
|
 前 |
 次 |
I/Oリソース管理(IORM)は、複数のデータベースおよびデータベース内のワークロード間でOracle Exadata System SoftwareのI/Oリソースをどのように共有するかを管理するためのツールです。
データベース内のワークロードを管理するために、Oracle Database Resource ManagerがIORMと連動し、データベースのリソースを管理できます。
多くの場合、ストレージは複数のタイプのワークロードおよびデータベース間で共有されます。共有ストレージには、専用のストレージを超える利点があります。1つ目の利点は、メンテナンスが必要なストレージ・システムの数を減らすことができるため、管理コストが削減されることです。もう1つの利点は、領域および帯域幅の両方の観点からストレージの使用効率が大幅に向上することです。ストレージ・システムが単一のデータベース専用の場合、管理者は予想されるデータベースの最大負荷とサイズに基づいて、ストレージ・システムのサイズを設定する必要があります。この方法では、一部のデータベースで未使用のI/O帯域幅と領域が発生することになり、見積りが十分でない場合、他のデータベース用の帯域幅と領域が不十分になります。実際の環境ではワークロードが常に変化するため、複数のデータベース間でストレージ・リソースの適切なバランスを達成することはまれです。
一方、共有ストレージで複数のタイプのワークロードとデータベースを実行すると、多くの場合パフォーマンスの問題が発生します。たとえば、本番環境のデータ・ウェアハウスの1つで多数のパラレル問合せを実行すると、他の本番環境のデータ・ウェアハウスにおいてクリティカルな問合せのパフォーマンスに影響を与える場合があります。また、データ・ウェアハウスにデータ負荷が発生すると、そのデータ・ウェアハウスで実行中のクリティカルな問合せのパフォーマンスに影響を与える場合もあります。このような問題は、ストレージ・システムをオーバー・プロビジョニングすることにより軽減できますが、この方法では、共有ストレージのコスト削減の利点もなくなります。クリティカルでないタスクをピーク時以外に実行するようにスケジュール設定することもできますが、この手動処理には手間がかかります。この方法は、データベースに複数の管理者がおり、各管理者の作業の調整が行われない場合は不可能になります。
I/Oリソース管理を使用することにより、ユーザー定義のポリシーに従って、複数のワークロードおよびデータベース間でOracle Exadata Storage Serverを共有できます。データベース内のワークロードを管理する場合は、Oracle Exadata Storage ServerのI/Oリソースを管理できるように拡張されたデータベース・リソース・マネージャを使用して、データベース・リソースのプランを定義できます。コンテナ・データベース(CDB)のワークロードを管理するには、様々なプラガブル・データベースを管理できるCDBリソース・プランを定義します。複数のデータベースを管理する場合は、データベース間のプランを定義できます。
フラッシュI/Oリソース管理により、フラッシュ・キャッシュ内のクリティカルなOLTP I/Oリクエストのレイテンシを保護します。OLTP I/Oリクエストと同時にフラッシュで表スキャンが実行されている場合、OLTPのレイテンシに大きく影響します。フラッシュIORMでは、表スキャン、および他の優先度の低いI/Oリクエストがキューに入れられ、制限されます。クリティカルなOLTP I/Oリクエストはキューに入れられません。フラッシュ・ドライブがクリティカルなOLTP I/Oリクエストの処理のためにビジーでない場合、データベース間プランでのリソース割当てに基づいて、キューに入れられたI/Oリクエストが発行されます。
I/Oリソース管理(IORM)では、Oracle Exadata Storage ServerのI/Oリソースをセル単位で管理します。I/Oリクエストによりセルの容量が飽和状態になり始めると、構成済のリソース・プランに従って、受信するI/OリクエストがIORMによってスケジュール調整されます。IORMでは、発行するI/Oリクエストとキューに入れるI/Oリクエストを迅速に振り分けることにより、I/Oをスケジュール調整します。すぐに発行されるI/Oリクエストは、リソース・プランに従ってワークロードがリソース割当てを超えていないリクエストです。キューに入れられるI/Oリクエストは、ワークロードがリソース割当てを超えているリクエストです。キューに入れられたI/Oリクエストは、そのワークロードがリソース割当て以下になった時点、またはセルが容量内で動作している時点で発行されます。セルが許容量を下回る状態で動作している場合、IORMはI/Oリクエストをキューに入れられません。また、システムの能力が最大限に達していないため、ワークロードがリソース割当てを超えることが許可されます。
たとえば、本番環境のデータベースとテスト用のデータベースでOracle Exadata Storage Serverを共有している場合は、本番環境のデータベースを優先するようにリソース・プランを構成できます。この場合、テスト用のデータベースの負荷が本番環境のデータベースのパフォーマンスに影響を与える場合は、本番環境のデータベースのI/Oパフォーマンスが影響を受けないように、IORMによってI/Oリクエストがスケジュール調整されます。つまり、テスト用のデータベースのI/Oリクエストは、本番環境のデータベースのI/Oリクエストのパフォーマンスに影響を与えずに発行可能になるまで、キューに入れられます。
IORMには、リソース割当てを管理するための多くの機能が用意されています。各機能は個別に使用できますが、他の機能と組み合せて使用することもできます。
データベース・リソース管理では、データベース内のワークロードを管理できます。データベース・リソース管理はデータベース・レベルで構成されます。この場合は、データベース・リソース・マネージャを使用してデータベース・リソース・プランを作成します。この機能は、1つのデータベース内に複数のタイプのワークロードがある場合や、これらのワークロード間でデータベースのリソース割当てをどのように共有するかを指定するためのポリシーを定義する必要がある場合に使用してください。1つのデータベースでのみOracle Exadata Storage Serverを使用している場合、必要なIORM機能はこれのみです。
データベース間のリソース管理では、複数のデータベースを管理できます。データベース間のリソース管理を構成する場合は、CellCLIユーティリティを使用してデータベース間のプランを作成します。データベース間のプランでは、データベースごとにリソース割当てを指定します。この機能は、Oracle Exadata Storage Serverを使用しているデータベースが複数ある場合に使用してください。
データベース間のプランが構成されている場合は、各データベースでデータベース・プランとリソース割当てを設定できます。データベース・リソース・プランでは、ワークロード(コンシューマ・グループ)間でデータベースのリソース割当てをどのように振り分けるかを指定します。データベースでデータベース・リソース・プランを有効にしていない場合は、データベースのリソース割当ては振り分けられず、データベースのすべてのI/Oリソースが単一のワークロードとして処理されます。
カテゴリ・リソース管理は拡張機能です。この機能は、Oracle Exadata Storage Serverが複数のデータベースをホストしており、主に実行中の処理のカテゴリ別にリソースを割り当てる場合に有効です。たとえば、すべてのデータベースにOLTP、レポート、メンテナンスの3つのカテゴリのワークロードがあるとします。これらのワークロード・カテゴリに基づいてI/Oリソースを割り当てるには、カテゴリ・リソース管理を使用します。
最大使用率制限の概要 (limit) はI/Oリソース管理でサポートされています。リソースの割当て値の指定のほかに、指定したデータベースの最大使用率を指定することもできます。このディレクティブにより、データベースが指定された制限を超えてI/Oリソースを使用できないようにすることができます。たとえば、本番とテスト環境用のデータベースがExtradaセルを共有している場合、テスト用データベースの最大使用率制限を設定し、テスト用データベースのI/O使用率を制限することができます。
最大使用率制限が指定されている場合、データベースが過剰な容量を使用することはありません。最大使用率制限を指定すると、ディスクをフル容量未満で実行できます。
IORMでは、フラッシュ・キャッシュおよびフラッシュ・ログの管理をサポートしています。ALTER IORMPLAN flashcache属性をoffに設定すると、データベースがフラッシュ・キャッシュを使用しないようにできます。同様に、ALTER IORMPLAN flashlog属性をoffに設定すると、データベースでフラッシュ・ログが使用されないようにできます。これらの属性により、特に統合環境において、フラッシュ・キャッシュおよびフラッシュ・ログをミッション・クリティカルなデータベース用に確保できます。
IORMでは、特定のデータベースのフラッシュ・キャッシュを単純にオフにすることに加えて、フラッシュ・キャッシュ・グループごとに割当てを指定することがサポートされています。フラッシュ・キャッシュ・グループは、データベースでもプラガブル・データベースでもかまいません。これらの割当て制限により、特定のクリティカル・グループに対するフラッシュ・キャッシュ内の領域の予約がサポートされるだけでなく、重要性の低い、または不正なデータベースやプラガブル・データベースがフラッシュ・キャッシュ全体をすべて使用することも防止されます。データベース間プランまたはCDBリソース・プランを使用して最小と最大の割当て制限を指定できます。
フラッシュ・キャッシュがフルでない場合は、グループがその割当てを超えて増加できる、弱い最大値を指定できます。また、フラッシュ・キャッシュがフルでない場合でも、データベースやPDBがその割当てを超えることができない、クラウドや「パフォーマンス・ベース課金」デプロイメントのためのフラッシュ・キャッシュの分割オプションもあります。
I/Oリソース管理(IORM)のデータベース間プランでは、数百ものデータベースのデータベース間プランの管理と構成を容易にするため、プロファイルがサポートされています。現在、ストレージ管理者がデータベース間プラン内のすべてのデータベースに対してリソースを指定する必要があります。また、この計画は新しいデータベースが作成されるたびに更新する必要があります。IORMプロファイルを使用すると、この問題を軽減できます。最初のステップでは、パフォーマンス要件に基づいて様々なプロファイル・タイプを定義できるプロファイル・ディレクティブを作成します。2番目のステップでは、データベース間プランに定義されているプロファイルの1つに新しいデータベースと既存のデータベースをマップします。これにより、データベースによってプロファイル・ディレクティブからすべての属性が自動的に継承されます。
データベース・リソース・マネージャでは、各データベースで次のタスクを実行できます。
通常、データベースには多くのタイプのワークロードがあります。これらのワークロードは、パフォーマンス要件および発行されるI/Oの量が異なる場合があります。リソース・コンシューマ・グループを使用すると、特定のワークロードを構成するセッションをグループ化できます。たとえば、データベースで4つの異なるアプリケーションが実行されている場合、4つのコンシューマ・グループを作成して、各アプリケーションに1つずつ使用できます。データ・ウェアハウスにクリティカルな問合せ、通常の問合せおよびETL(抽出、変換およびロード)などの3つのタイプのワークロードがある場合、各タイプのワークロードにコンシューマ・グループを作成できます。
コンシューマ・グループを作成したら、コンシューマ・グループにセッションをどのようにマップするかを指定するルールを作成する必要があります。データベース・リソース・マネージャでは、Oracleユーザー名、データベースとの接続にセッションで使用されたサービス、クライアント・マシン、クライアントのプログラム名、クライアントのユーザー名など、セッションの属性に基づいてマッピング・ルールを作成できます。各アプリケーションにコンシューマ・グループを作成しており、各アプリケーションに専用のサービスがある場合は、サービス名に基づいてマッピング・ルールを作成してください。コンシューマ・グループを特定のユーザー・セットに指定する場合は、そのユーザー名に基づいてマッピング・ルールを作成してください。コンシューマ・グループに明示的に割り当てられていないセッションは、OTHER_GROUPSコンシューマ・グループに配置されます。
コンテナ・データベース・リソース・プラン(CDBプラン)は、同一のコンテナを構成する様々なプラガブル・データベース間でCPUおよびI/Oリソースを割り当てる方法を指定します。CDBプランはデータベース・リソース・マネージャを使用して作成されます。CDBプランには、各プラガブル・データベースのディレクティブが含まれています。ディレクティブは、そのプラガブル・データベースに割り当てられている共有数を定義します。共有は、プランの他のプラガブル・データベースと比較したときの、そのプラガブル・データベースの相対的な優先度を定義します。
プラガブル・データベースの最大使用率制限を指定できます。
CDBリソース・プランでは、各PDBにmemory_minおよびmemory_limitも指定できます。これらのパラメータは、各PDB用のフラッシュ・キャッシュの最小および最大の割当て制限を指定します。
データベースのリソース・プランはデータベース内リソース・プランとも呼ばれ、データベースのコンシューマ・グループ間でCPUとI/Oリソースをどのように割り当てるかを指定します。リソース・プランはデータベース・リソース・マネージャを使用して作成されます。これには、各コンシューマ・グループに対するリソース割当てディレクティブが含まれており、割合とレベルで構成されています。最大8つのレベルまで指定できます。レベル2のコンシューマ・グループでは、レベル1で割り当てられなかったリソースや、レベル1のコンシューマ・グループによって使用されなかったリソースが取得されます。同様に、レベル3のコンシューマ・グループには、レベル1および2の割当てが一部残っている場合にのみリソースが割り当てられます。リソース・プランには、各コンシューマ・グループのリソース割当てのディレクティブが含まれ、割合およびレベルで構成されます。複数のレベルで優先度付けできるだけでなく、プライマリおよび残りのすべてのリソースをどのように使用するかを明示的に指定することもできます。割合、優先度、または割合と優先度を組み合せてコンシューマ・グループ間でリソースを割り当てるリソース・プランを構成できます。
コンシューマ・グループの最大使用率制限を指定することもできます。これはデータベースの最大使用率制限と同じように動作し、コンシューマ・グループのI/O使用率を指定した値に制限します。
CDB計画以外にも、プラガブル・データベースごとにリソース計画を作成することにより、プラガブル・データベース内で実行されているワークロードを管理することもできます。プラガブル・データベースでサポートされるのは、最大8つのコンシューマ・グループが含まれる単一レベルの計画のみです。
データベース・リソース・プランは、RESOURCE_MANAGER_PLAN初期化パラメータを使用して手動で有効にできます。また、ジョブ・スケジューラ・ウィンドウで自動的に有効にすることもできます。
データベースでデータベース・リソース・プランを設定すると、プランの説明が各セルに自動的に送信されます。Oracle Real Applications Clusters (Oracle RAC)データベースでOracle Exadata Storage Serverを使用する場合は、Oracle RACクラスタのすべてのインスタンスを同じリソース・プランに設定する必要があります。新規セルの追加または既存のセルの再起動を行うと、データベースの現在のプランがセルに自動的に送信されます。リソース・プランは、データベース・サーバーおよびセルの両方のリソース管理に使用されます。
バックグラウンドのI/Oは、ユーザーI/Oに対する優先度に基づいてスケジュール設定されます。たとえば、REDO書込みおよび制御ファイルの読取りおよび書込みはパフォーマンスにとって重要なため、すべてのユーザーI/Oよりも常に優先されます。データベース・ライター・プロセス(DBWR)の書込みは、ユーザーI/Oと同じ優先度レベルでスケジュール設定されます。データベースでリソース・プランが有効になっていない場合、すべてのユーザーI/Oは同等に処理され、この段落の説明に従ってバックグラウンドのI/Oが処理されます。
Oracleでは、事前定義された複数のプランを用意しています。最も一般的に使用されるプランは、mixed_workload_plan、dss_planおよびdefault_maintenance_planです。
関連項目:
プラガブル・データベース、CDBプラン、コンシューマ・グループ、コンシューマ・グループへのユーザー・セッションの割当て、およびリソース・プランの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。
データベース間のリソース管理は、データベース間のプランを使用して管理されます。
データベース間のプランでは、複数のデータベース間でリソースを各セルにどのように割り当てるか(割合または共有別)を指定します。データベース間のプランのディレクティブでは、コンシューマ・グループではなくデータベースへの割当てを指定します。データベース間のプランは、各セルでCellCLIユーティリティを使用して構成および有効化されます。
データベース間のプランのディレクティブは、データベースのdb_unique_nameを識別子として使用して指定されます。IORMでは、ディレクティブでロール属性も指定される場合を除き、db_nameを使用したディレクティブの指定はサポートされません。これは、Oracle Data Guardデプロイメントにのみ適用されます。
たとえば、データベースSALESにI/Oリソースの70%、HRに30%が割り当てられるように指定し、未使用の割当てがTEST_SALESデータベースに再割当てされるように指定するとします。データベース間のプランは、各ディレクティブが割当て量とレベル(1から8)で構成される点でデータベース・リソース・プランと同じです。各プランでは、任意のレベルの割当ての合計を100%以下にする必要があります。データベース間のプランとデータベース・リソース・プランの異なる点は、データベース間のプランにはサブプランを含めることができず、I/Oリソースのディレクティブしか含めることができないことです。所定の時間で1つのセルで有効にできるデータベース間プランの数は1つのみです。
共有ベースのプランでは、割合による割当ておよびレベルではなく、相対的な共有を使用します。このようなプランは実装は簡単ですが、割合による割当てと同様の効果があります。各データベースには、1から32の整数の共有値が割り当てられます。共有の合計が100を超える場合もあります。共有ベースのプランでは、データベース間プラン内で最大1024のディレクティブをサポートします。たとえば、クリティカルなデータベースのFINANCEに4つの共有があり、優先度の低いデータベースのREPORTINGに1つの共有がある場合、FINANCEデータベースのI/O発行の可能性はREPORTINGデータベースの4倍になります。
Oracle Exadata System Softwareでは、IORMおよびデータベース・リソース・プランを併用してI/Oリソースを割り当てます。
最初に、データベース間のプランによって各データベースにI/Oリソースが割り当てられます。未使用のリソースは、プランに従って他のデータベースに再割当てされます。このプロセスはデータベース・リソース・プランと同様です。
次に、各データベースのデータベース・リソース・プランによってコンシューマ・グループにI/Oリソースが割り当てられます。データベースにアクティブなデータベース・リソース・プランがない場合は、すべてのユーザーI/Oが同じように処理されます。バックグラウンドのI/Oは、重要度に基づいてユーザーI/Oに対して優先度が付けられます。
ベスト・プラクティスとしては、同じセル・ストレージを使用しているデータベースごとにディレクティブを作成することをお薦めします。これは、共有ベースのプランでは自動的に実行されますが、割合による割当てプランでは自動的に実行されません。共有ベースのプランで明示的にマッピングされない各データベースのデフォルトの共有は、それぞれ1です。明示的なディレクティブのないデータベースを割合による割当てプランで管理できるようにするには、OTHERという名前の割当てを作成します。明示的なディレクティブのないデータベースは、OTHERグループ・ディレクティブの割当てを使用して管理されます。
共有ベースのプランでは、DEFAULTディレクティブを使用して、プランで名前が明示的に指定されていないデータベース用の様々なIORM属性のデフォルト値を指定します。デフォルトの共有は1で、上限は100%に設定されます。Exadataスマート・フラッシュ・キャッシュおよびExadataスマート・フラッシュ・ログはデフォルトで有効になっており、フラッシュ・キャッシュの割当て制限の最小または最大のデフォルトの設定はありません。
もう1つのデータベース間リソース管理の使用ケースは統合用です。たとえば、同じOracle Exadata Storage Serverにある4つの異なるアプリケーションを統合する場合です。すべてのアプリケーションが同じような優先度要件の場合は、I/Oリソースの25%を均等に割当てます。
ただし、別のアプリケーションの使用率がワークロードで突然上昇する場合は、各アプリケーションを分離できます。最大使用率制限を使用してアプリケーションを分離し、たとえば、各アプリケーションに40%の最大使用率制限を指定します。このようなシナリオの場合、各アプリケーションはI/Oリソースの最大40%を使用することができ、システムを完全に占有することはありません。最大使用率制限は、このような統合シナリオの場合に便利です。
特定のサービス・プロバイダには、パフォーマンス・ベースで課金されるモデルがあります。これらのプロバイダは、購入されたサービスのレベルに応じて顧客に対するパフォーマンスを保証することを求めています。ゴールド層のサービスを購入していない顧客は、ゴールド・レベルのパフォーマンスを享受できないようにする必要があります。これは、最大使用率制限が意味を持つもう1つの事例です。フラッシュ・キャッシュの最小および最大の割当て制限は、このモデルでも役に立ちます。
データベース間プランを使用して管理されるもう1つのリソースはフラッシュ・キャッシュ領域です。複数のデータベースが使用されており、プラガブル・データベースによって記憶域が共有されている場合、フラッシュ・キャッシュは管理が必要なクリティカルなリソースになります。I/Oリソース管理では、フラッシュ・キャッシュ内の領域を保証することにより、予測可能なパフォーマンスを実現できます。また、1つのデータベースまたはプラガブル・データベース(PDB)がフラッシュ・キャッシュ全体を占有しないようにすることもできます。これを行うには、flashcacheminおよびflashcachelimit属性を使用します。
flashcachemin — ブロックがコールド状態であってもデータベースに対して保証される、フラッシュ・キャッシュ内の最小サイズを指定します
flashcachelimit — フラッシュ・キャッシュの「弱い」最大サイズを指定します。フラッシュ・キャッシュがフルでない場合、データベースはこのflashcachelimitの値を超えることができます。
flashcachesize属性は、データベース用の領域を予約するためにフラッシュ・キャッシュを分割します。flashcachesizeを指定されたフラッシュ・キャッシュ・グループは、フラッシュ・キャッシュがフルでない場合も、その割当て制限を超えることはできません。ただし、リソース・プランを設定する前にデータベース用のフラッシュ・キャッシュの使用量がすでにflashcachesizeの値を超えている場合、Oracle Exadata System Softwareはフラッシュ・キャッシュから事前にデータを削除しません。データは、フラッシュ・キャッシュ内の領域が不足しているときにレイジー方式で削除されます。
flashcacheminおよびflashcachesizeは保証付きの予約であるため、flashcacheminとflashcachesizeの合計は、各グループがそれぞれの割当てを取得できるように、すべてのディレクティブ全体でフラッシュ・キャッシュのサイズより小さくする必要があります。
リソース・プランを管理する場合は、次の点に注意してください。
Oracle Exadata Storage Serverが1つのデータベースのみをホストする場合、データベース間プランは不要です。
データベース間のプランが指定されていない場合は、すべてのデータベースで割当てが同じになります。
OTHERディレクティブにマップされるデータベースが1つしかなく、その他のデータベースに明示的なディレクティブがある場合、Oracle Exadata Storage Serverでは、そのデータベースのデータベース・リソース・プランを使用して、そのデータベースのコンシューマ・グループ間でOTHERデータベースの割当てをどのように再配分するかを決定します。
複数のデータベースがOTHERディレクティブにマップされる場合、Oracle Exadata Storage Serverでは、それらのデータベースにOracle Database Resource Managerを使用しません。この場合は、すべてのI/Oリクエストが同等に処理されます。
共有ベースのプランでは、プランで明示的に名前が指定されていない場合でも、各データベースがで独自のディレクティブを取得します。Oracle Exadata Storage Serverでは、データベースのデータベース・リソース・プランを使用して、データベースのコンシューマ・グループ間で割当てをどのように配分するかを決定します。
コンテナ・データベース(CDB)プランでmemory_minまたはmemory_limitを指定しており、データベース間プランでflashCacheSizeを指定している場合は、CDBプランのmemory_minは無視されます。
関連項目
I/Oリソース管理のデータベース間プランでは、数百ものデータベースのデータベース間プランの管理と構成を容易にするため、プロファイルがサポートされています。プロファイルにより、データベースに対してI/Oリソースを割り当てる方法が導入されます。これは、データベースのinit.oraパラメータdb_performance_profileを使用して実行されます。データベース管理者は、db_performance_profileパラメータを設定することにより、様々なデータベースをGOLD、SILVER、BRONZEとして分類できます。DBRM計画の場合のように、db_performance_profile情報はOracle Exadataストレージ・グリッド内のすべてのストレージ・セルに対して自動的にプッシュされます。次のSQLは、データベースにプロファイル・パラメータを設定する方法を示しています。
SQL> alter system set db_performance_profile=gold scope=spfile;
プロファイルは、データベース間プランのディレクティブとして指定され、CellCLIユーティリティを使用して構成されます。プロファイル・ディレクティブは、識別子(名前)と一連の属性で構成されています。データベース・ディレクティブとプロファイル・ディレクティブを区別するために、typeと呼ばれる修飾子属性が使用されます。type属性は、databaseまたはprofileに設定できます。次は、type属性の構文の例です。
CellCLI> ALTER IORMPLAN DBPLAN=((name=gold, share=10, limit=100, type=profile), \ (name=silver, share=5, limit=60, type=profile), (name=bronze, share=1, limit=20, \ type=profile))
前述の例には、プロファイルの3つのディレクティブ(GOLD、SILVERおよびBRONZE)が含まれています。db_performance_profileがGOLDに設定されたすべてのデータベースは、セルに対して10の共有、および100%の制限を取得します。このことは、SILVERおよびBRONZEプロファイルにマップされているデータベースについても当てはまります。新しいデータベースを追加する場合、db_performance_profileを設定し、データベースを再起動します。データベース間プランを変更しなくても、データベースによってOracle Exadata Storage Server上のプロファイル属性が自動的に継承されます。また、プロファイル・ディレクティブとデータベース・ディレクティブが混在するデータベース間プランの作成もサポートされています。
データベース間プロファイル・プランを管理する場合、次の各事項に注意してください。
db_performance_profileパラメータは動的パラメータでないため、データベースの再起動時にはプロファイルを更新する必要があります。
type属性を指定しない場合、ディレクティブはdatabaseディレクティブにデフォルト設定されます。
データベース間プランで指定できるのは、8つのプロファイル・ディレクティブと1024のデータベース・ディレクティブのみです。
プロファイル・ディレクティブでは、レベル、割当ておよびロールを指定することはできません。
OTHERとDEFAULTという単語は予約語です。プロファイル名をOTHERまたはDEFAULTにすることはできません。
type属性は、カテゴリ・プランでは指定できません。
プロファイルは、カテゴリ・プランととともに指定することはできません。
データベース・リソース・マネージャでは、すべてのコンシューマ・グループでカテゴリを指定できます。コンシューマ・グループはデータベース内のユーザーの集合を表しますが、カテゴリはすべてのデータベースのコンシューマ・グループの集合を表します。カテゴリ・プランを作成すると、カテゴリに基づいてI/Oリソースを管理できます。たとえば、Oracle Exadata Storage Serverを共有するすべてのデータベースで、batchカテゴリのコンシューマ・グループよりもinteractiveカテゴリのコンシューマ・グループを優先するように優先順位を指定できます。次の表は、Oracle Databaseに用意されている事前定義済のカテゴリとサンプルの割合を説明したものです。
カテゴリの数の追加、または事前定義済のカテゴリの変更を行うことができます。同じセル・ストレージを使用するすべてのデータベースで、コンシューマ・グループを適切なカテゴリにマップしてください。明示的にカテゴリを指定されていないコンシューマ・グループは、デフォルトでOTHERカテゴリに設定されます。
カテゴリ・プランを有効にすると、カテゴリ・プランが最初に使用され、カテゴリ間でリソースが割り当てられます。選択したカテゴリごとにデータベース間のプランが使用され、選択したカテゴリのコンシューマ・グループを持つデータベースが選択されます。最後に、選択したデータベース・リソース・プランが使用され、コンシューマ・グループの1つが選択されます。
カテゴリ・プランは、CellCLIユーティリティを使用してセルで構成および有効化されます。一度に有効にできるカテゴリ・プランは1つのみです。サンプルのカテゴリ・プランを次の表に示します。
表6-1 サンプルのカテゴリ・プラン
| カテゴリ名 | カテゴリの説明 | レベル1 (%) | レベル2 (%) | レベル3 (%) |
|---|---|---|---|---|
ADMINISTRATIVE |
緊急の管理タスクなど、優先度が非常に高い処理用。 このカテゴリは必須です。 |
80 |
||
INTERACTIVE |
OLTPトランザクションなど、優先度が高くパフォーマンスに依存する処理用。 |
70 |
||
BATCH |
クリティカルでないレポートやバックアップなど、優先度の低い処理用。 |
70 |
||
MAINTENANCE |
自動化されたタスクなど、優先度が低い処理用。 |
10 |
||
OTHER |
カテゴリ・ラベルがなく、現在のカテゴリ・プランにないカテゴリを参照するすべてのコンシューマ・グループ用。 このカテゴリは必須です。 |
20 |
前述の表に示すサンプル・プランでは、すべてのデータベースでadministrativeアクティビティが最も優先されます。interactiveアクティビティはbatch、maintenanceおよびその他のアクティビティよりも優先されます。このサンプル・プランのリソース割当ては次のとおりです。
レベル1には、I/Oリソースの80%が割り当てられます。ADMINISTRATIVEカテゴリはレベル1の唯一のカテゴリです。
レベル2には、レベル1で未割当てまたは未使用のすべてのリソースが割り当てられます。この例では、I/Oリソースの20%とADMINISTRATIVEカテゴリで使用されていないリソースがレベル2に割り当てられます。INTERACTIVEカテゴリでは、レベル2の量の70%が割り当てられます。
レベル3のカテゴリには、INTERACTIVEカテゴリで使用されていないリソースを含む、残りのリソースが割り当てられます。BATCHカテゴリには、残りのリソースの70%、OTHERカテゴリには20%、MAINTENANCEカテゴリには10%が割り当てられます。
すべてのデータベースのすべての管理コンシューマ・グループは、ADMINISTRATIVEカテゴリにマップしてください。重要なOLTPトランザクションやタイムクリティカルなレポートなど、優先度の高いすべてのユーザー・アクティビティは、INTERACTIVEカテゴリにマップしてください。レポートやメンテナンス、優先度の低いOLTPトランザクションなど、優先度の低いすべてのユーザー・アクティビティは、BATCH、MAINTENANCEおよびOTHERのカテゴリにマップしてください。
関連項目
Oracle Exadata Database Machineには、Oracle Exadata System Softwareを使用するデータ・ウェアハウス専用のデフォルトのコンシューマ・グループおよびリソース・プランが付属しています。
これらのリソース・プランは、現在の環境の要件にあわせて変更できます。
データ・ウェアハウス用のコンシューマ・グループは、次のとおりです。
ETL_GROUP: ETL(抽出、変換およびロード)ジョブ用のコンシューマ・グループ。
DSS_GROUP: クリティカルではない意思決定支援システム(DSS)の問合せ用のコンシューマ・グループ。
DSS_CRITICAL_GROUP: クリティカルなDSS問合せ用のコンシューマ・グループ。
データ・ウェアハウス用のリソース・プランは、次のとおりです。
DSS_PLANリソース・プランは、クリティカルではないDSS問合せおよびETLジョブよりもクリティカルなDSS問合せを優先するデータ・ウェアハウス用に設計されています。このプランでは、SYS_GROUPが最高の優先度を持ち、次にDSS_CRITICAL_GROUP、DSS_GROUPが続き、その次にETL_GROUPとBATCH_GROUPの組合せが続きます。帯域幅のすべてを使用できるコンシューマ・グループはありません。
表6-2 データ・ウェアハウス用のDSS_PLANリソース・プラン
| コンシューマ・グループ | レベル1 (%) | レベル2 (%) | レベル3 (%) | レベル4 (%) |
|---|---|---|---|---|
SYS_GROUP |
75 |
|||
DSS_CRITICAL_GROUP |
75 |
|||
DSS_GROUP |
75 |
|||
ETL_GROUP |
45 |
|||
BATCH_GROUP |
45 |
|||
ORA$DIAGNOSTICS |
5 |
|||
ORA$AUTOTASK_SUB_PLAN |
5 |
|||
OTHER_GROUPS |
10 |
前述の表に示したように、DSS_CRITICAL_GROUPグループには、レベル2で75%のみが割り当てられます。未使用の割当ては、同じレベルの他のコンシューマ・グループではなく、すべて次のレベルに付与されます。つまり、DSS_CRITICAL_GROUPグループで割当てが完全に使用されない場合、その割当ては同じレベルのORA$DIAGNOSTICSグループやORA$AUTOTASK_SUBPLANグループには付与されません。プラン定義に従って、割当てはレベル3のDSS_GROUPグループに付与されます。
ETL_CRITICAL_PLANでは、DSS問合せよりもETLが優先されます。このプランでは、SYS_GROUPグループに帯域幅の75%が割り当てられます。残りの帯域幅は、レベル2の割当てで指定される割合に基づいて、他のコンシューマ・グループ間で分割されます。ETL_GROUPおよびDSS_CRITICAL_GROUPグループの割当て(35%)は、DSS_GROUPおよびBATCH_GROUPグループの割当て(10%)より多くなっています。
表6-3 データ・ウェアハウス用のETL_CRITICAL_PLANリソース・プラン
| コンシューマ・グループ | レベル1 (%) | レベル2 (%) | レベル3 (%) | レベル4 (%) |
|---|---|---|---|---|
SYS_GROUP |
75 |
|||
DSS_CRITICAL_GROUP |
35 |
|||
DSS_GROUP |
10 |
|||
ETL_GROUP |
35 |
|||
BATCH_GROUP |
10 |
|||
ORA$DIAGNOSTICS |
3 |
|||
ORA$AUTOTASK_SUB_PLAN |
3 |
|||
OTHER_GROUPS |
3 |
マルチテナント・コンテナ・データベースは、多数のユーザー定義のプラガブル・データベースをサポートしています。CDBでは、リソースについて競合する複数のPDB内に、複数のワークロードを使用することができます。CDBでは、リソースは次のレベルで管理されます。
CDBレベル: リソース・マネージャを使用して、システム・リソースおよびCDBリソースについて競合する複数のプラガブル・データベース(PDB)のワークロードを管理します。管理者は、PDBへのリソースの割当て方法を指定し、特定のPDBのリソース使用率を制限できます。
PDBレベル: リソース・マネージャを使用して、各PDB内のワークロードを管理します。
次のCDBプランには、SALES、SERVICESおよびHRという3つのPDBが含まれています。PDBは、そのCDBプラン内でそれぞれ異なる共有数および最大使用率制限が使用されます。
| PDB名 | 共有のためのディレクティブ | 使用率制限のためのディレクティブ | Memory_min | Memory_limit |
|---|---|---|---|---|
SALES |
3 |
無制限 |
20 |
|
SERVICES |
3 |
無制限 |
20 |
|
HR |
1 |
70 |
50 |
この項では、I/Oリソース管理(IORM)のタスクについて説明します。このタスクを実行するには、DBMS_RESOURCE_MANAGERパッケージを使用して、データベース・ホスト上にデータベース・リソース・プランを定義し、CellCLIユーティリティを使用して、各セルのIORMおよびカテゴリを指定します。
この項では、次の項目について説明します。
関連項目
IORMはデフォルトで有効です。デフォルトの状態において、IORMはフラッシュ・キャッシュとフラッシュ・ログを管理します。また、ログの書込み、バッファ・キャッシュの読取りおよびその他影響のあるI/Oにおいて、極端に長い待機時間が発生しないように監視します。ハード・ディスク上で非常に負荷の高いI/Oを実行すると、ディスクI/Oの待機時間が長くなります。IORMを使用せずに、ディスクI/Oのレイテンシを短くする唯一の方法は、スマート・スキャンやその他のディスクI/O集中型の操作を減らして、I/O全体のスループットを低くすることです。これらのI/O集中型操作を管理するには、IORMで最適化モードを指定するようにobjectiveオプションを設定します。デフォルトのobjectiveオプションはbasicです。
objectiveオプションをbasicに設定すると、データベース・リソース・プランの最大利用率が制限されません。データベース・リソース・プラン割当ては、極端に長い待機時間が発生しないように監視するためだけに使用され、プランへの適合は考慮されていません。
このモードでは、IORMはフラッシュ・デバイスに対するスマート・スキャンおよび優先度の低いI/Oをキューに入れられます。通常、クリティカルなI/Oによってディスクが常時ビジー状態になることはありません。これらのアイドル時間中、IORMはデータベース間プランの割当てを使用して、キューに入れられたスマート・スキャンおよび優先度の低いI/Oをフラッシュ・デバイスに対して発行します。これは、ハード・ディスクに対するI/Oの処理方法とは関係なく実行されます。
クリティカルなOLTP I/Oが発行されていないときも、IORMは異なるスキャンのワークロードの中で優先順位を付けます。フラッシュIORMは、フラッシュ・キャッシュとExadata Extreme Flashのハイブリッド・システムで有効になっています。フラッシュIORMのデバイス・キューの深さは、ハードウェアおよびフラッシュ・デバイスの種類によって異なります。
プランに厳密に適合させるために、最大利用率を制限する場合は、objectiveオプションをbasic以外の値に設定する必要があります。サポートされているIORMのobjective値は、auto、low_latency、balancedおよびhigh_throughputです。推奨されるobjectiveオプションはautoで、これを指定すると、IORMはワークロードを継続して監視し、現在セルでアクティブなワークロードに基づいて最適なモードを選択します。objectiveオプションがbasic以外の値に設定されている場合、IORMは次のいずれかの方法でI/Oリソースに優先順位を付けます。
データベースでデータベース・リソース・プランが設定されている場合に、IORMがディスクI/Oを管理します。
データベース間のプランまたはカテゴリ・プランが構成されている場合に、IORMがディスクI/Oを管理します。
I/Oの優先順位付けおよびスロットルを非アクティブ化するには、IORMのobjectiveの設定をbasicに戻します。
フラッシュIORMの動作は、Exadata Extreme Flashストレージを除き、IORMの目標の変更では制御できません。フラッシュIORMは、OLTPの待機時間を保護するように設計されており、クリティカルなI/Oを保護する際に目標を考慮に入れることはありません。
Exadata Extreme Flashストレージでは、IORMの目標によりフラッシュIORMの挙動をある程度制御できます。デフォルトの目標はbasicです。目標の値のautoとbalancedは、同じ動作になります。スキャンのスループットの低下度合いがあまりに高いと考えられる場合は、目標を、クリティカルなI/O待機時間を犠牲にしてスキャンのスループットを向上させるhigh_throughputに変更できます。クリティカルI/Oの待機時間は非常に良好だが、両方のワークロードを同時に実行するときにスキャンのスループットが大幅に劣化する、という場合には、目標をlow_latencyに変更することもできます。
データベース・リソース管理を設定するには、データベース・リソース・マネージャを使用し、コンシューマ・グループを構成してセッションを割り当て、データベース・リソース・プランを作成して有効にする必要があります。
この項では、次の項目について説明します。
コンシューマ・グループおよびカテゴリは、PL/SQL DBMS_RESOURCE_MANAGERパッケージのプロシージャを使用して設定します。
新規のコンシューマ・グループおよびカテゴリを作成するか、事前定義済のコンシューマ・グループまたはカテゴリのいずれかを使用することができます。カテゴリ・プランを使用する予定がない場合は、カテゴリを設定する必要はありません。
注意:
コンシューマ・グループおよびカテゴリはデータベースに作成されますが、セルに明示的に作成することはできません。
コンシューマ・グループおよびカテゴリを管理するためのDBMS_RESOURCE_MANAGERプロシージャを実行する前に、最初にペンディング・エリアを作成する必要があります。DBMS_RESOURCE_MANAGER PL/SQLパッケージのプロシージャを実行するには、システム権限のADMINISTER_RESOURCE_MANAGERが必要です。
次のPL/SQLコマンドは、コンシューマ・グループおよびカテゴリで使用されます。
カテゴリを管理する場合: CREATE_CATEGORY()、DELETE_CATEGORY()およびUPDATE_CATEGORY()
コンシューマ・グループを管理する場合: CREATE_CONSUMER_GROUP()およびUPDATE_CONSUMER_GROUP()
カテゴリにコンシューマ・グループを割り当てる場合: CREATE_CONSUMER_GROUP()またはUPDATE_CONSUMER_GROUP()
データベースには、各自で設定したコンシューマ・グループの他に、事前定義済のコンシューマ・グループも含まれています。DBA_RSRC_CONSUMER_GROUPSビューには、コンシューマ・グループに関する情報が表示され、DBA_RSRC_CATEGORIESビューには、データベース内のカテゴリに関する情報が表示されます。
例6-1 データベースのPL/SQLを使用したコンシューマ・グループおよびカテゴリの設定
この例は、データベースにコンシューマ・グループおよびカテゴリを設定する方法を示しています。MAINTENANCEカテゴリが事前定義されますが、この例では作成されません。
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_CATEGORY(
CATEGORY => 'dss',
COMMENT => 'DSS consumer groups');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
CONSUMER_GROUP => 'critical_dss',
CATEGORY => 'dss',
COMMENT => 'performance-critical DSS queries');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
CONSUMER_GROUP => 'normal_dss',
CATEGORY => 'dss',
COMMENT => 'non performance-critical DSS queries');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
CONSUMER_GROUP => 'etl',
CATEGORY => 'maintenance',
COMMENT => 'data import operations');
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/
例6-2 Oracle Databaseのコンシューマ・グループおよびカテゴリ
この例は、DBA_RSRC_CONSUMER_GROUPSビューに対する問合せを示しています。
SQL> SELECT consumer_group, category FROM DBA_RSRC_CONSUMER_GROUPS where
consumer_group not like 'ORA%' ORDER BY category;
CONSUMER_GROUP CATEGORY
------------------------------ ------------------------------
SYS_GROUP ADMINISTRATIVE
ETL_GROUP BATCH
BATCH_GROUP BATCH
DSS_GROUP BATCH
CRITICAL_DSS DSS
NORMAL_DSS DSS
DSS_CRITICAL_GROUP INTERACTIVE
INTERACTIVE_GROUP INTERACTIVE
ETL MAINTENANCE
LOW_GROUP OTHER
OTHER_GROUPS OTHER
AUTO_TASK_CONSUMER_GROUP OTHER
DEFAULT_CONSUMER_GROUP OTHER
13 rows selected
関連項目
リソースのコンシューマ・グループにセッションを手動で割り当てるか、コンシューマ・グループのマッピング・ルールを使用して自動的に割り当てることができます。どちらの方法でも、コンシューマ・グループを切り替えるための明示的な権限をユーザーに付与する必要があります。ユーザーが切替え可能なコンシューマ・グループを制御するには、PL/SQLプロシージャのDBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP()を使用します。
コンシューマ・グループのマッピング・ルールは、ユーザー名、データベースとの接続にセッションで使用されたサービス名、クライアント・プログラムの名前などのセッション属性に基づきます。コンシューマ・グループのマッピング・ルールを作成するには、例6-3に示すようにSET_CONSUMER_GROUP_MAPPINGプロシージャを使用します。SET_CONSUMER_GROUP_MAPPINGプロシージャを実行する前に、最初にペンディング・エリアを作成する必要があります。
PL/SQLのDBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER()プロシージャまたはSWITCH_CONSUMER_GROUP_FOR_SESS()プロシージャを使用して、セッションを特定のコンシューマ・グループに手動で切り替えることもできます。
関連項目:
次の詳細は、『Oracle Database管理者ガイド』を参照してください。
コンシューマ・グループへのセッションの割当て
セッション属性の完全なリスト
例6-3 サービスおよびユーザー名に基づいたコンシューマ・グループのマッピング・ルールの作成
BEGIN
DBMS_SERVICE.CREATE_SERVICE('SALES', 'SALES');
DBMS_SERVICE.CREATE_SERVICE('AD_HOC', 'AD_HOC');
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
(DBMS_RESOURCE_MANAGER.ORACLE_USER, 'SYS', 'CRITICAL_DSS');
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
(DBMS_RESOURCE_MANAGER.SERVICE_NAME, 'SALES', 'CRITICAL_DSS');
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
(DBMS_RESOURCE_MANAGER.SERVICE_NAME, 'AD_HOC', 'NORMAL_DSS');
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP (
GRANTEE_NAME => 'PUBLIC',
CONSUMER_GROUP => 'CRITICAL_DSS',
GRANT_OPTION => FALSE);
DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP (
GRANTEE_NAME => 'PUBLIC',
CONSUMER_GROUP => 'NORMAL_DSS',
GRANT_OPTION => FALSE);
END;
/
CDBプランは、PL/SQLのDBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN()プロシージャおよびCREATE_CDB_PLAN_DIRECTIVE()プロシージャを使用して作成されます。CDBプランは、ルートPDB以外から構成することはできません。CDBプランでは、データベース・インスタンスのCPUリソースおよびExadataセルのフラッシュ・キャッシュ領域やI/O帯域幅を管理します。
例6-4 CDBプランを使用したPDB間でのリソースの配分
この例は、SALES、SERVICESおよびHRという3つのPDB間でのリソースの配分方法を示しています。SALESおよびSERVICESは優先度が高く、またHRの共有数が1つであるのに対し、SALESおよびSERVICESの共有数はそれぞれ3つあります。HR PDBでは、最大使用率制限が70%に設定されています。
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN(
plan => ''NEWCDB_PLAN ',
comment => 'CDB resource plan for newcdb');
DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
plan => 'NEWCDB_PLAN',
pluggable_database => 'SALESPDB',
shares => 3,
memory_min => 20,
utilization_limit => 100);
DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
plan => ' NEWCDB_PLAN ',
pluggable_database => 'SERVICESPDB',
shares => 3,
memory_min => 20,
memory_limit => 75);
DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
plan => ' NEWCDB_PLAN ',
pluggable_database => 'HRPDB',
shares => 1,
memory_limit => 50,
utilization_limit => 70);
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/
データベース・リソース・プランはデータベース内プランとも呼ばれ、PL/SQLのDBMS_RESOURCE_MANAGER.CREATE_PLAN()プロシージャおよびCREATE_PLAN_DIRECTIVE()プロシージャを使用して作成されます。DBMS_RESOURCE_MANAGER PL/SQLパッケージのプロシージャを実行するには、システム権限のADMINISTER_RESOURCE_MANAGERが必要です。このリソース・プランでは、データベース・インスタンスのCPUリソースおよびセルのI/Oリソースの両方を管理します。
1つ目のシナリオでは、複数のアプリケーション間でデータベースを共有し、I/Oリソースを特定の比率で各アプリケーションに割り当てます。たとえば、SALES、FINANCE、MARKETINGという名前の3つのアプリケーションがあるとします。I/Oリソースを60%、25%、10%の割合でそれぞれ割り当て、これらのコンシューマ・グループにマップされないセッションに残りの5%を割り当てます。このシナリオでは、各アプリケーションにコンシューマ・グループを作成し、単一レベルのリソース・プランを作成して、各コンシューマ・グループに割り当てるI/Oリソースの割合を指定します。この割当ては、実際はコンシューマ・グループで使用可能な最小のI/Oリソースです。コンシューマ・グループで割当てが使用されなかった場合、その割当てはプランで指定した比率で他のコンシューマ・グループに再配分されます。MGMT_P1パラメータを使用すると、例6-5に示すように割当てを指定できます。
2つ目のシナリオでは、ワークロードに優先順位を付けます。たとえば、問合せの実行中にデータをデータ・ウェアハウスにロードする場合に、データ・ロードよりも問合せを常に優先するとします。このシナリオでは、問合せ用にコンシューマ・グループを2つ作成し、データ・ロード用にコンシューマ・グループを1つ作成します。問合せ用の2つのコンシューマ・グループ間で、I/Oリソースを75:25の比率で共有するとします。また、これらのコンシューマ・グループで割当てをすべて使用しない場合にのみ、データ・ロードのI/Oを発行するとします。この場合は、例6-6に示すように、リソース・プランのレベルを使用して割当ての優先度を指定できます。
この例では、PL/SQLプロシージャのCREATE_PENDING_AREA()を使用してリソース・プランの作成または更新を開始し、PL/SQLプロシージャのSUBMIT_PENDING_AREA()を使用してそれらを完了する必要があります。また、OTHER_GROUPSのディレクティブを含める必要もあります。OTHER_GROUPSには、コンシューマ・グループに明示的にマップされないすべてのセッションが保持されます。
例6-5 アプリケーション間でのリソースの共有
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PLAN('DAYTIME_PLAN', 'Resource plan for managing all
applications between 9 am and 5 pm');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('SALES', 'Sales App');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('FINANCE', 'Finance App');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('MARKETING', 'Marketing App');
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'SALES', 'Allocation
for SALES', MGMT_P1 => 60);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'FINANCE', 'Allocation
for FINANCE', MGMT_P1 => 25);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'MARKETING',
'Allocation for MARKETING', MGMT_P1 => 10);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'OTHER_GROUPS',
'Allocation for default group', MGMT_P1 => 5);
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/
例6-6 ワークロード間でのリソースの共有
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PLAN('DAYTIME_PLAN', 'Resource plan for prioritizing
queries between 9 am and 5 pm');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('REPORT_QUERIES', 'Report Queries');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('AD-HOC_QUERIES', 'Ad-Hoc Queries');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('DATA_LOAD', 'Data Load');
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'REPORT_QUERIES',
'Allocation for REPORT_QUERIES', MGMT_P1 => 75);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'AD-HOC_QUERIES',
'Allocation for AD-HOC_QUERIES', MGMT_P1 => 25);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'DATA_LOAD',
'Allocation for DATA_LOAD', MGMT_P2 => 100);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'OTHER_GROUPS',
'Allocation for default group', MGMT_P3 => 100);
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/
関連項目
データベース・リソース・プランは、RESOURCE_MANAGER_PLANパラメータを設定することで手動で有効化できます。リソース・プランでスケジューラ・ウィンドウを定義すると、リソース・プランを自動的に有効化できます。スケジューラ・ウィンドウが開くと、リソース・プランが有効になります。スケジューラ・ウィンドウが閉じると、リソース・プランが無効になります。
リソース・プランが有効になると、このイベントに関してデータベースからすべてのセルにアラートが通知され、リソース・プランが提供されます。リソース・プランが無効になる場合も、すべてのセルにアラートが通知されます。データベースではリソース・プランを1つしかアクティブにできないため、データベースのすべてのインスタンスで同じリソース・プランを有効にする必要があります。データベースでデータベース・リソース・プランが有効になっていない場合は、すべてのI/Oリクエストが同等に処理されます。
関連項目
Oracle Exadata System Softwareの高速ファイル作成機能では、データ・ファイルの初期化を高速化できます。
この機能は、表領域を新規作成、既存の表領域にデータ・ファイルを追加、または既存の表領域を自動拡張すると自動的に実行されます。Oracle Exadata System Softwareでは、多数のI/Oリクエストを同時に発行するため、ファイルの初期化を非常に高速化できます。ただし、このような同時I/Oリクエストは高い負荷がかかり、パフォーマンスが重要となる問合せに影響を及ぼす可能性があります。
I/Oリソース管理(IORM)を使用すると、新規の表領域を作成する場合や、既存の表領域にデータ・ファイルを追加する場合に高速ファイル作成の優先度を制御できます。これらの操作は、FASTFILECRE関数で実行されます。デフォルトでは、FASTFILECRE関数は、すべてのコンシューマ・グループおよびバックグラウンドI/Oより優先度の低い非表示のコンシューマ・グループにマップされます。ファイル作成の優先度を高くしてパフォーマンスを向上する場合、マッピング属性DBMS_RESOUCRE_MANAGER.ORACLE_FUNCTIONおよびマッピング値FASTFILECREに基づくマッピング・ルールを追加します。
既存の表領域の自動拡張は簡単ですが、多くの場合はタイムクリティカルな操作のため、IORMを使用して優先度を変更することはできません。
例6-7 高速ファイル作成の管理
この例は、MAINTENANCE_GROUPコンシューマ・グループで高速ファイル作成を実行する方法を示しています。BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('MAINTENANCE_GROUP', 'Maintenance
activity');
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(DBMS_RESOURCE_MANAGER.ORACLE_
FUNCTION, 'FASTFILECRE', 'MAINTENANCE_GROUP');
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/
データのインポート(ETL)は、データ・ウェアハウスのメンテナンスの重要な部分です。レポートや問合せはデータがロードされるまで実行できないため、ETLがパフォーマンスにとって非常に重要になる場合があります。このような場合は、ETLが他のすべての問合せよりも優先するようにします。また、特定の時間で完了しない場合にしか優先する必要がない場合など、ETLが優先度の低いバックグラウンドのアクティビティになる場合もあります。IORMを使用すると、ETLの優先度だけでなく、ETLで使用されるI/Oリソースの量も制御できます。
ETLを管理するには、ETL_GROUPコンシューマ・グループにETLセッションをマップして、リソース・プランにETL_GROUPグループを含める必要があります。ETLのマッピング・ルールは、通常はユーザー名またはクライアント・プログラム名に基づきます。データ・ポンプは、DATALOAD関数で実行されます。DATALOAD関数は、デフォルトでETL_GROUPコンシューマ・グループにマップされます。
例6-8 ETL_GROUPコンシューマ・グループへのプログラムのマップ
この例は、ETL_GROUPコンシューマ・グループにプログラムをマップする方法を示しています。
BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (DBMS_RESOURCE_MANAGER.CLIENT_PROGRAM, 'SQLLDR', 'ETL_GROUP'); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; /
バックアップはI/O集中型の操作です。Oracle Recovery Manager(RMAN)のI/Oの比率は、チャネル数を設定して制御できます。IORMを使用すると、RMANのI/Oのリソース使用量と優先度を大幅に抑えることもできます。たとえば、RMANを優先度の低いコンシューマ・グループにマップできます。これにより、Oracle Exadata Storage Serverがビジーになっても、RMAN操作の実行速度が大幅に低下するため、他のデータベース操作に影響を及ぼすことがなくなります。ただし、Oracle Exadata Storage Serverが十分に使用されていない場合は、未使用の帯域幅をRMANのI/Oが使用できるようにIORMによってスケジュール調整されます。
RMANのバックアップはBACKUP関数で実行されます。RMANのコピーはCOPY関数で実行されます。デフォルトでは、BACKUP関数およびCOPY関数の両方ともBATCH_GROUPコンシューマ・グループにマップされます。これらの関数は、次の例に示すように他のコンシューマ・グループに再マップできます。
例6-9 コンシューマ・グループを使用したリソースの管理
BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(DBMS_RESOURCE_MANAGER.ORACLE_ FUNCTION, 'BACKUP', 'BATCH_GROUP'); DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(DBMS_RESOURCE_MANAGER.ORACLE_ FUNCTION, 'COPY', 'MAINTENANCE_GROUP'); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; /
CellCLIのALTER IORMPLANコマンドを使用すると、Oracle Exadata System Softwareのデータベース間プランまたはカテゴリ・プランを構成できます。
catPlanパラメータでは、カテゴリ・プランを指定します。dbPlanパラメータでは、データベース間のプランを指定します。カテゴリ・プラン、データベース間のプランまたはデータベース・リソース・プランを使用してI/Oリソースを管理するには、objectiveを設定します。
objectiveオプションのデフォルトはbasicで、I/Oリソース管理(IORM)は、構成済のリソース・プランに基づいてI/Oリソースを管理します。objectiveオプションはauto、auto、low_latency、balancedまたはhigh_throughputに設定できます。
例6-10は、割当てを使用してセルのデータベース間プランを構成する方法を示しています。
プラン名は、cellname_IORMPLANに自動的に設定されます。
データベース間のプランのディレクティブが有効であるためには、レベルおよび割当て、共有、最大使用率制限、またはフラッシュ・キャッシュ割当て制限ディレクティブを指定する必要があります。
割当て、共有または最大使用率制限を指定していないディレクティブは無効です。割当てと共有の両方を指定するディレクティブも無効です。
データベース間のプランを構成する場合、catPlanおよびdbPlanはオプションのパラメータになります。catPlanが指定されていない場合、カテゴリ間のIORMは有効になりません。同様に、dbPlanが指定されていない場合、データベース間のIORMは有効になりません。catPlanまたはdbPlanを指定する場合は、ディレクティブでname=otherを指定する必要があります。カテゴリ・プランの場合は、カテゴリがカテゴリ・プランで指定されていないアクティブなすべてのコンシューマ・グループの割当てがotherディレクティブで指定されます。データベース間のプランでは、Oracle Exadata System Softwareを使用しているがデータベース間のプランで明示的に指定されていないすべてのデータベースの割当てがotherディレクティブで指定されます。otherディレクティブが指定されていない場合は、CellCLIユーティリティによってエラーが返されます。
例6-11は、共有を使用してセルのデータベース間プランを構成する方法を示しています。
データベース間プランの属性をデフォルト値にリセットするには、例6-12に示すように属性を空の文字列に設定します。プラン全体をリセットしたり、catPlanまたはdbPlanを個別にリセットしたりすることもできます。
alter_iormという名前のテキスト・ファイルに複数のALTER IORMPLANコマンドを入力し、START alter_iormコマンドとともにこのテキスト・ファイルを使用することで各コマンドを実行できます。
flashcacheminおよびflashcachelimit属性を使用して、フラッシュ・キャッシュ・グループに対して保証される最小と最大の割当て制限を指定します。これらの属性を使用すると、データベース間でフラッシュ・キャッシュ領域を配分する方法を制御できます。これらの属性は、データベース間プランでのみ指定でき、CellCLIユーティリティを使用して構成されます。
flashcachemin属性は、データベースに対して保証されるフラッシュ・キャッシュ内の最小領域を指定します。
flashcachelimit属性値は、データベースがフラッシュ・キャッシュ内で使用できる領域の最大値を指定します。flashcachelimitは「弱い」最大値であり、それは、フラッシュ・キャッシュがフルでない場合にフラッシュ・キャッシュ・グループがその割当て制限を超過できることを意味します。このモデルは、Oracle Cloudおよびパフォーマンス・ベース課金の環境では機能しません。flashcachesizeと呼ばれる別の属性が、この制限の緩和に役立ちます。flashcachesizeは、フラッシュ・キャッシュ内にグループのための領域を保証するために、フラッシュ・キャッシュを分割します。これは、Oracle Cloud環境向けに提供されているため、フラッシュ・キャッシュに空き領域がある場合でもflashcachesizeは超過されません。
コンテナ・データベース(CDB)プランでプラガブル・データベース(PDB)に対してmemory_minおよびmemory_limit属性が指定されている場合、これは、データベースまたはフラッシュ・キャッシュ・サイズ合計(何も指定されていない場合)に対するflashcachemin、flashcachelimitまたはflashcachesize値の割合として計算されます。
role属性はOracle Data Guardで使用されます。この属性では、データベースのロール(primaryまたはstandby)に基づいて異なる割当てを指定できます。デフォルトでは、データベースがいずれかのロールの場合に、データベース間プランのすべての割当てが適用されます。データベースがprimaryロールの場合にのみ割当てを適用する場合は、role=primaryと設定します。同様に、データベースがstandbyロールの場合にのみ割当てを適用する場合は、role=standbyと設定します。
例6-10 割当てを使用したデータベース間プランの構成
CellCLI> ALTER IORMPLAN -
catPlan=((name=administrative, level=1, allocation=80), -
(name=interactive, level=2, allocation=90), -
(name=batch, level=3, allocation=80), -
(name=maintenance, level=4, allocation=50), -
(name=other, level=4, allocation=50) -
), -
dbplan=((name=sales_prod, share=8, role=primary), -
(name=sales_prod, share=1, limit=50, role=standby), -
(name=sales_test, share=1, limit=25), -
(name=default, share=2))
例6-11 共有を使用したデータベース間プランの構成
ALTER IORMPLAN -
(name=dev01, share=1, limit=50, flashLog=off), -
(name=dev02, share=1, limit=25, flashCache=off) -
(name=default, share=4))
例6-12 データベース間プランのデフォルト値へのリセット
CellCLI> ALTER IORMPLAN dbPlan="", catPlan="" CellCLI> ALTER IORMPLAN dbPlan="" CellCLI> ALTER IORMPLAN catPlan=""
例6-13 フラッシュ・キャッシュ・グループのデータベース間プランの構成
ALTER IORMPLAN - dbplan=((name=sales, share=8, flashCacheSize=10G), - (name=finance, share=8, flashCacheLimit=10G, flashCacheMin=2G), - (name=dev, share=2, flashCacheLimit=4G, flashCacheMin=1G), - (name=test, share=1, limit=10, flashCacheSize=1G))
例6-14 Oracle Data Guardのデータベース間プランの構成
ALTER IORMPLAN -
dbPlan=((name=prod, share=8, role=primary), -
(name=prod, share=1, limit=25, role=standby) -
(name=default, share=2))
セルでCellCLIのLIST IORMPLANコマンド使用すると、セルの現在のデータベース間プランを表示できます。次の例は、データベース間プランの属性の詳細なリストを示しています。
例6-15 データベース間プランの詳細の表示
CellCLI> LIST IORMPLAN DETAIL
name: cell01_IORMPLAN
status: active
catPlan: name=administrative,level=1,allocation=80
name=interactive,level=2,allocation=90
name=batch,level=3,allocation=80
name=maintenance,level=4,allocation=50
name=other,level=4,allocation=50
dbplan: name=sales_prod, share=8, role=primary
name=sales_prod, share=1, limit=50, role=standby
name=sales_test, share=1, limit=25
name=default, share=2
objective: balanced
関連項目
次のチェックリストを使用して、IORMが適切に構成されているかどうかを確認できます。
IORMを使用してデータベース内のI/Oリソースを管理する場合、次の基準が満たされている必要があります。
リソース・プランが有効化されていること。
すべてのデータベース・インスタンスで同じリソース・プランが有効化されていること。
注意:
スケジューラ・ウィンドウを使用してデータベース・リソース・マネージャを有効化すると、すべてのデータベース・インスタンスで常に同じプランが有効化されます。
RESOURCE_MANAGER_PLANパラメータを使用してデータベース・リソース・マネージャを有効化する場合、sid='*'を使用してすべてのデータベース・インスタンスにパラメータを設定します。
リソース・プランのコンシューマ・グループごとに、リソース・プランにMGMT_P[1-8]ディレクティブが含まれていること。
次の問合せを使用して、前述の基準が満たされているかどうかを確認できます。
SELECT DECODE(count(*), 0, 'Intra-Instance IORM Plan Enabled', 'No Intra-Instance IORM Plan Enabled') status FROM gv$instance WHERE inst_id not in (SELECT inst_id FROM gv$rsrc_plan WHERE cpu_managed = 'ON');
IORMを使用して複数のデータベースのI/Oリソースを管理する場合、次のコマンドを使用してデータベース間プランが適切に構成されているかどうかを確認します。
CellCLI> LIST IORMPLAN DETAIL
データベース間プランが構成されていない場合、CellCLIのALTER IORMPLANコマンドを使用してプランを構成します。各アクティブ・データベースは、dbPlanパラメータに独自のディレクティブを保持している必要があります。
次の問合せを使用して、セッションが正しいコンシューマ・グループにマップされているかどうかを確認します。このコマンドは、ワークロードの処理中に実行する必要があります。
SELECT r.sid,
c.consumer_group current_consumer_group
FROM v$rsrc_session_info r, dba_rsrc_consumer_groups c
WHERE r.current_consumer_group_id = c.consumer_group_id
union
SELECT sid, 'OTHER_GROUPS' from v$rsrc_session_info
WHERE current_consumer_group_id = 0;
次の構成エラーが原因で、セッションが適切なコンシューマ・グループに存在していないことがあります。
権限の不足: セッションをいずれかのコンシューマ・グループに切り替えるには、そのコンシューマ・グループに切り替える権限がユーザーまたはロールに付与されている必要があります。次の問合せにより、すべてのコンシューマ・グループの権限が表示されます。
SELECT grantee, granted_group FROM DBA_RSRC_CONSUMER_GROUP_PRIVS ORDER BY granted_group;
次のコマンドは、任意のセッションをいずれかのコンシューマ・グループに切り替える権限を付与するSQLコマンドの例です。
EXEC dbms_resource_manager_privs.grant_switch_consumer_group -
('public', 'BATCH_GROUP', FALSE);
このコマンドで、コンシューマ・グループはBATCH_GROUPです。
アクティブではないコンシューマ・グループ: 現在のリソース・プランに含まれていないコンシューマ・グループにセッションがマップされるか、手動で切り替えられると、そのセッションはデフォルトのコンシューマ・グループであるOTHER_GROUPSに切り替えられます。
セッションがマッピング・ルールを使用してコンシューマ・グループに割り当てられている場合、次の問合せを使用して、マッピング・ルールにより選択されたコンシューマ・グループ、使用されたマッピング属性、およびセッション開始時の本来のコンシューマ・グループを確認できます。
SELECT r.sid,
r.mapped_consumer_group,
r.mapping_attribute,
c.consumer_group original_consumer_group
FROM v$rsrc_session_info r, dba_rsrc_consumer_groups c
WHERE r.orig_consumer_group_id = c.consumer_group_id;
マップ済のコンシューマ・グループが元のコンシューマ・グループと異なる場合、マップ済のコンシューマ・グループはリソース・プランに含まれていなかったことになります。
ワークロードの実行中に、I/O負荷が正しいコンシューマ・グループで管理されているかどうかを確認します。次のCellCLIコマンドでは、すべてのデータベースの各コンシューマ・グループで発行された大小のI/Oリクエストの数が表示されます。
CellCLI> LIST METRICCURRENT CG_IO_RQ_LG, CG_IO_RQ_SM ATTRIBUTES name, -
metricObjectName, metricValue, collectionTime;
アクティブなI/Oワークロードを保持する各コンシューマ・グループは、これらのメトリックのとおりに大小のI/Oリクエストを生成しています。
ワークロードを実行中は、各カテゴリ、データベース、およびコンシューマ・グループの実際のI/O使用率を問合せます。次のCellCLIコマンドは、Oracle Exadata Storage Serverで実行中の各データベースの大小I/O使用率のリストです。
CellCLI> LIST METRICCURRENT DB_IO_UTIL_LG, DB_IO_UTIL_SM ATTRIBUTES name, -
metricObjectName, metricValue, collectionTime;
出力はデータベースからの大小のリクエストによって使用されるディスク・リソースのパーセントを示したものです。
関連項目
同じストレージを共有する4つのデータベースの例を検討します。4つのデータベースは次のとおりです。
PRODという名前のOLTP本番環境用データベース
PROD_TESTという名前のテスト用データベース
PROD_DEVという名前の開発用データベース
DWという名前のデータ・ウェアハウス用データベース
OLTP本番環境用データベースでは、一般的に小さいI/Oリクエストが発行されます。これらのリクエストのレイテンシが短いことは重要な要件です。データ・ウェアハウスでは、多数の大きいI/Oリクエストが発行されるので、各I/OリクエストのレイテンシよりもI/Oスループットが重要になります。I/Oリソース管理を使用しないと、DWデータベースで発行されるI/Oリクエストの数がストレージ・サブシステムの容量を超えてしまい、OLTPデータベースで発行されるI/Oリクエストのレイテンシが増加します。また、テスト用データベース(PROD_TEST)および開発用データベース(PROD_DEV)で発行されるI/Oリクエストにより、OLTPデータベースおよびDWデータベースのパフォーマンスが影響を受ける可能性があります。
リソースは、次の例に示すとおり指定できます。
次のようにデータベース間のプランを指定することにより、これらの4つのデータベースのI/Oリクエストに優先度を設定できます。
OLTPデータベースのPRODには、高い優先度レベルでI/Oリソースの80%を割り当てます。
DWデータベースには、残りのI/Oリソースの20%とPRODデータベースの未使用の割当ての80%を割り当てます。
PROD_TESTデータベース、PROD_DEVデータベースおよびOTHERデータベースには、未使用のI/Oの50%、40%、10%をそれぞれ割り当てます。
例6-16に示すように、CellCLIユーティリティを使用してセルでデータベース間のプランを指定できます。
データベース間のプランの例を次の表に示します。
表6-4 割当てを使用したデータベース間プラン
| データベース名 | レベル1 (%) | レベル2 (%) | レベル3 (%) |
|---|---|---|---|
PROD |
80 |
||
DW |
80 |
||
PROD_TEST |
50 |
||
PROD_DEV |
40 |
||
OTHER |
10 |
PROD_TESTデータベースおよびPROD_DEVデータベースで非常に高いI/O負荷が発生しても、PRODデータベースおよびDWデータベースのパフォーマンスは影響を受けません。また、DWデータベースで大量のI/Oが発行されても、PRODデータベースのパフォーマンスが影響を受けることはありません。
例6-16 割当てのALTER IORMPLAN構文
CellCLI> ALTER IORMPLAN -
dbPlan=( -
(name=prod, level=1,allocation=80), -
(name=dw, level=2, allocation=80), -
(name=prod_test, level=3, allocation=50), -
(name=prod_dev, level=3, allocation=40), -
(name=other, level=3, allocation=10))
OLTPデータベースのPRODは最も重要であるため、PRODデータベースには16の共有を指定できます。DWデータベースでは4つの共有、PROD_TESTでは2つの共有、PROD_DEVでは1つの共有を取得します。このプランでは、PRODデータベースのI/O発行の可能性がDWデータベースの4倍になります。発行するI/OがPRODにない場合は、共有に基づいて他のデータベースが使用されます。
例6-17 共有のALTER IORMPLAN構文
CellCLI> ALTER IORMPLAN -
dbPlan=( -
(name=prod, share=16), -
(name=dw, share=4), -
(name=prod_test, share=2), -
(name=prod_dev, share=1))
データベースのI/Oリソースではなく、フラッシュ・キャッシュおよびフラッシュ・ログの管理にIORMを使用する場合があります。この場合は、次の例に示すように、ALTER IORMPLANコマンドを使用してI/Oの優先順位付けを無効にし、PROD_TESTおよびPROD_DEVデータベースでフラッシュ・キャッシュおよびフラッシュ・ログを無効にします。
注意:
フラッシュ・キャッシュおよびフラッシュ・ログはデフォルトでオンになっているため、PRODおよびDWデータベースでフラッシュ・キャッシュおよびフラッシュ・ログを明示的に有効にする必要がありません。これらは、PROD_TESTおよびPROD_DEVデータベースでの設定と対比した例に示されています。
例6-18 フラッシュ・キャッシュおよびフラッシュ・ログを管理するためのALTER IORMPLAN構文
CellCLI> ALTER IORMPLAN objective='basic';
CellCLI> ALTER IORMPLAN -
dbPlan=( -
(name=prod, flashcache=on, flashLog=on), -
(name=dw, flashcache=on, flashLog=on), -
(name=prod_test, flashcache=off, flashLog=off), -
(name=prod_dev, flashcache=off, flashLog=off) -
(name=other, flashcache=on, flashLog=on))
IORMにより、異なるデータベースとPDBの間でフラッシュ・キャッシュをどのように共有するかを制御できます。これは、CDBリソース・プランのみ、またはCDBプランとIORMデータベース間プランの両方を使用して行うことができます。
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN(
plan => ''NEWCDB_PLAN ',
comment => 'CDB resource plan for newcdb');
DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
plan => 'NEWCDB_PLAN',
pluggable_database => 'SALESPDB',
memory_min => 20);
DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
plan => ' NEWCDB_PLAN ',
pluggable_database => 'SERVICESPDB',
memory_min => 20,
memory_limit => 50);
DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
plan => ' NEWCDB_PLAN ',
pluggable_database => 'HRPDB',
memory_limit => 25);
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/
プランに記載されている3つのPDB用にmemory_minおよびmemory_limitを指定するCDBリソース・プランを考えてみましょう。これらの値は、0から100の範囲のパーセンテージで指定されます。オーバー・プロビジョニングがサポートされているため、パーセンテージの合計は100%には制限されません。合計が100%を超える場合、値は100%まで正規化されます。memory_minが指定されていない場合は、デフォルトで0に設定されます。memory_limitが指定されていない場合は、デフォルトで100に設定されます。CDB$ROOT用には、5%のmemory_limit値があります。この例では、memory_min値の合計は40%で、memory_limit値の合計は正規化する必要のある175%です。データベース間プランが指定されていない場合、これらのパーセンテージがフラッシュ・キャッシュのサイズ全体に適用されます。データベース間プランが指定されている場合、PDBの割当て制限は、データベース間プランのディレクティブで指定されたデータベース用の最小値と制限値のパーセンテージとして計算されます。
前述の例で、データベース間プランを指定せず、フラッシュ・キャッシュのサイズが10GBの場合の、memory_limitの値の合計が100%を超えた制限を正規化した後の割当て制限の内訳を次の表に示します。最小値がこの制限よりも大きくなった場合は、最小値を減らしてこの制限と等しくします。
表6-5 ケース1: データベース間プランがない場合のPDBの制限
| PDB | フラッシュ・キャッシュの最小 | FCの弱い制限 | 正規化済の弱い制限 | FCの強い制限 |
|---|---|---|---|---|
SALESPDB |
20% = 2 GB |
100 (デフォルト) |
100 / 175 = 5.7 GB |
該当なし |
SERVICESPDB |
20% = 2 GB |
50 |
50 / 175 = 2.85 GB |
該当なし |
HRPDB |
0 |
25 |
25 / 175 = 1.4 GB |
該当なし |
フラッシュ・キャッシュ・サイズが50GBのシステムでは、次のようなデータベース間プランを検討してください。
ALTER IORMPLAN dbplan= - ((name=newcdb, share=8, flashCacheSize=10G), - (name=finance, share=8, flashCacheLimit=10G, flashCacheMin=2G), - (name=dev, share=2, flashCacheLimit=4G, flashCacheMin=1G), - (name=test, share=1, limit=10))
「newcdb」CDBに加え、その他の3つのデータベース(finance、devおよびtest)で同じストレージ・セルを共有します。フラッシュ・キャッシュの割当て制限は、ディレクティブにflashcachesize、flashcachelimitまたはflashcachemin属性が指定されている場合にのみ強制されます。flashcachesizeは、保証付きの強い制限であり、分離して指定する必要があります。つまり、同じディレクティブ内にflashcacheminまたはflashcachelimitとともに指定できません。データベース「test」にはフラッシュ・キャッシュのディレクティブが指定されていません。それ、およびそのPDB(もしあれば)では、フラッシュ・キャッシュの割当て制限は管理されません。
CDBにflashcachesizeが指定されている場合は、CDBリソース・プランのmemory_minの値は無視され、memory_limitの値が正規化されて、それぞれのPDBのフラッシュ・キャッシュ・サイズの計算に使用されます。「newcdb」CDBにはflashcachesizeが指定されているため、memory_minの値は無視されます。flachcachesizeは、前に見たように、memory_limitの値を正規化した後に計算されます。唯一の違いは、CDBにはflashcachesizeディレクティブが指定されているため、これが保証された強い制限になることです。
表6-6 ケース2: データベース間プランがある場合のPDBの制限
| PDB | フラッシュ・キャッシュの最小 | FCの強い制限 | 正規化済の強い制限 | FCの弱い制限 |
|---|---|---|---|---|
SALESPDB |
0 |
100 (デフォルト) |
100 / 175 = 5.71 GB |
該当なし |
SERVICESPDB |
0 |
50 |
50 / 175 = 2.86 GB |
該当なし |
HRPDB |
0 |
25 |
25 / 175 = 1.43 GB |
該当なし |
非CDBデータベースでは、flashcachesize、flashcacheminおよびflashcachelimitの値は絶対的な値として指定され、追加の正規化は必要ありません。flashcachesizeおよびflashcacheminは保証付きの予約であるため、flashcachesizeとflashcacheminの合計は、すべてのディレクティブ全体でフラッシュ・キャッシュの合計サイズより小さくする必要があります。
