6 I/Oリソースの管理
I/Oリソース管理(IORM)は、複数のデータベースおよびデータベース内のワークロード間でOracle Exadata System SoftwareのI/Oリソースをどのように共有するかを管理するためのツールです。
データベース内のワークロードを管理するために、Oracle Database Resource ManagerがIORMと連動し、データベースのリソースを管理できます。
6.1 リソース管理の概要
多くの場合、ストレージは複数のタイプのワークロードおよびデータベース間で共有されます。共有ストレージには、専用のストレージを超える利点があります。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リクエストが発行されます。
6.2 I/Oリソース管理(IORM)の理解
IORMは、ストレージ・サーバーの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には、リソース割当てを管理するための多くの機能が用意されています。各機能は個別に使用できますが、他の機能と組み合せて使用することもできます。
データベース・リソース管理では、データベース内のワークロードを管理できます。データベース・リソース管理はデータベース・レベルで構成されます。この場合は、Oracle Database Resource Managerを使用してデータベース・リソース・プランを作成します。この機能は、1つのデータベース内に複数のタイプのワークロードがある場合や、これらのワークロード間でデータベースのリソース割当てをどのように共有するかを指定するためのポリシーを定義する必要がある場合に使用してください。1つのデータベースでのみOracle Exadata Storage Serverリソースを使用している場合、必要なIORM機能はこれのみです。
データベース間のリソース管理では、複数のデータベースのリソースを管理できます。データベース間のリソース管理を構成する場合は、CellCLIユーティリティを使用してデータベース間のプランを作成します。データベース間のプランでは、データベースごとにリソース割当てを指定します。この機能は、Oracle Exadata Storage Serverリソースを使用しているデータベースが複数ある場合に使用してください。
データベース間のプランが構成されている場合は、各データベースでデータベース・プランとリソース割当てを設定できます。データベース・リソース・プランでは、ワークロード(コンシューマ・グループ)間でデータベースのリソース割当てをどのように振り分けるかを指定します。データベースでデータベース・リソース・プランを有効にしていない場合は、データベースのリソース割当ては振り分けられず、データベースのすべてのI/Oリソースが単一のワークロードとして処理されます。同じDB_UNIQUE_NAME
を持っているが、異なるOracle ASMクラスタに関連付けられているデータベースがある場合、Oracle Exadata System Softwareリリース19.1.0以降では、asmcluster
属性を使用すると、データベース間プランの各データベースを一意に識別できます。
カテゴリ・リソース管理は拡張機能です。この機能は、Oracle Exadata Storage Serverが複数のデータベースをサポートしており、主に実行中の処理のカテゴリ別にリソースを割り当てる場合に有効です。たとえば、すべてのデータベースにOLTP、レポート、メンテナンスの3つのカテゴリのワークロードがあるとします。これらのワークロード・カテゴリに基づいてI/Oリソースを割り当てるには、カテゴリ・リソース管理を使用します。
最大使用率制限(limit
)の概要はIORMでサポートされています。リソース割当て値の指定に加えて、特定のデータベースの最大使用率制限も指定できます。このディレクティブにより、指定した制限を超えるI/Oリソースがデータベースで利用されないことが保証されます。たとえば、本番とテスト環境用のデータベースがOracle Exadata Storage Serverリソースを共有している場合、テスト用データベースの最大使用率制限を設定し、テスト用データベースのI/O使用率を制限できます。
最大使用率制限が指定されている場合、データベースが過剰な容量を使用することはありません。最大使用率制限を指定すると、ストレージ・デバイスをフル容量未満で実行できます。
ハード・ディスクに発行されたI/Oは最大使用率制限の対象ではありませんが、フラッシュ・デバイス上のI/Oは対象になります。これは、ほとんどすべてのI/OがExadataスマート・フラッシュ・キャッシュによって提供されるためです。フラッシュ・デバイスでのみ最大使用率制限を強制することで、キャッシュ・ミスや移入I/Oなど、フラッシュ・キャッシュを失わないI/Oの低使用率制限が原因で、長い待機時間と外れ値が回避されます。
IORMでは、フラッシュ・キャッシュおよびフラッシュ・ログの管理をサポートしています。ALTER IORMPLAN flashcache
属性をoff
に設定すると、データベースがフラッシュ・キャッシュを使用しないようにできます。同様に、ALTER IORMPLAN flashlog
属性をoff
に設定すると、データベースでフラッシュ・ログが使用されないようにできます。同じDB_UNIQUE_NAME
を持っているが、異なるOracle ASMクラスタに関連付けられているデータベースがある場合、Oracle Exadata System Softwareリリース19.1.0以降では、asmcluster
属性を使用すると、各データベースを一意に識別できます。これらの属性により、特に統合環境において、フラッシュ・キャッシュおよびフラッシュ・ログをミッション・クリティカルなデータベース用に確保できます。
IORMでは、特定のデータベースのフラッシュ・キャッシュを単純にオフにすることに加えて、フラッシュ・キャッシュ・グループごとに割当てを指定することがサポートされています。フラッシュ・キャッシュ・グループは、データベースでもプラガブル・データベース(PDB)でもかまいません。これらの割当て制限により、特定のクリティカル・グループに対するフラッシュ・キャッシュ内の領域の予約がサポートされるだけでなく、重要性の低い、または不正なデータベースやPDBがフラッシュ・キャッシュ全体を消費することも防止されます。データベース間プランまたはコンテナ・データベース(CDB)・リソース・プランを使用して最小と最大の割当て制限を指定できます。
フラッシュ・キャッシュがフルでない場合は、グループがその割当てを超えて増加できる、弱い最大値を指定できます。また、フラッシュ・キャッシュがフルでない場合でも、データベースやPDBがその割当てを超えることができない、Oracle Cloudやパフォーマンス・ベース課金デプロイメントのためのフラッシュ・キャッシュの分割オプションもあります。
IORMのデータベース間プランでは、数百ものデータベースのデータベース間プランの管理と構成を容易にするため、プロファイルがサポートされています。現在、ストレージ管理者がデータベース間プラン内のすべてのデータベースに対してリソースを指定する必要があります。また、この計画は新しいデータベースが作成されるたびに更新する必要があります。IORMプロファイルを使用すると、この問題を軽減できます。最初のステップでは、パフォーマンス要件に基づいて様々なプロファイル・タイプを定義できるプロファイル・ディレクティブを作成します。2番目のステップでは、データベース間プランに定義されているプロファイルの1つに新しいデータベースと既存のデータベースをマップします。これにより、データベースによってプロファイル・ディレクティブからすべての属性が自動的に継承されます。
6.2.1 データベース・リソース管理について
通常、データベースには多くのタイプのワークロードがあります。これらのワークロードは、パフォーマンス要件および発行されるI/Oの量が異なる場合があります。
Oracle Database Resource Managerでは、各データベースで次のタスクを実行できます。
-
リソース・コンシューマ・グループの作成
リソース・コンシューマ・グループを使用すると、特定のワークロードを構成するセッションをグループ化できます。たとえば、データベースで4つの異なるアプリケーションが実行されている場合、4つのコンシューマ・グループを作成して、各アプリケーションに1つずつ使用できます。データ・ウェアハウスにクリティカルな問合せ、通常の問合せおよびETL(抽出、変換およびロード)などの3つのタイプのワークロードがある場合、各タイプのワークロードにコンシューマ・グループを作成できます。
-
コンシューマ・グループへのユーザー・セッションのマップ
コンシューマ・グループを作成したら、コンシューマ・グループにセッションをどのようにマップするかを指定するルールを作成する必要があります。Oracle Database Resource Managerでは、Oracleユーザー名、データベースとの接続にセッションで使用されたサービス、クライアント・マシン、クライアントのプログラム名、クライアントのユーザー名など、セッションの属性に基づいてマッピング・ルールを作成できます。各アプリケーションにコンシューマ・グループを作成しており、各アプリケーションに専用のサービスがある場合は、サービス名に基づいてマッピング・ルールを作成してください。コンシューマ・グループを特定のユーザー・セットに指定する場合は、そのユーザー名に基づいてマッピング・ルールを作成してください。コンシューマ・グループに明示的に割り当てられていないセッションは、
OTHER_GROUPS
コンシューマ・グループに配置されます。 -
CDBリソース・プランの作成
コンテナ・データベース(CDB)・リソース・プランは、同一のコンテナを構成する様々なプラガブル・データベース(PDB)間でCPUおよびI/Oリソースを割り当てる方法を指定します。CDBプランはOracle Database Resource Managerを使用して作成されます。CDBプランには、各PDBのディレクティブが含まれています。ディレクティブは、そのPDBに割り当てられている共有数を定義します。共有は、プランの他のPDBと比較したときの、そのPDBの相対的な優先度を定義します。
PDBの最大使用率制限を指定できます。
CDBリソース・プランでは、各PDBに
memory_min
およびmemory_limit
も指定できます。これらのパラメータは、各PDB用のフラッシュ・キャッシュの最小および最大の割当て制限を指定します。 -
リソース・プランの作成
データベースのリソース・プランはデータベース内リソース・プランとも呼ばれ、データベースのコンシューマ・グループ間でCPUとI/Oリソースをどのように割り当てるかを指定します。リソース・プランはOracle Database Resource Managerを使用して作成されます。これには、各コンシューマ・グループに対するリソース割当てディレクティブが含まれており、割合とレベルで構成されています。最大8つのレベルまで指定できます。
- レベル2のコンシューマ・グループでは、レベル1で割り当てられなかったリソースや、レベル1のコンシューマ・グループによって使用されなかったリソースが取得されます。
- レベル3のコンシューマ・グループには、レベル1および2の割当てが一部残っている場合にのみリソースが割り当てられます。
- リソース・プランには、各コンシューマ・グループのリソース割当てのディレクティブが含まれ、割合およびレベルで構成されます。
複数のレベルで優先度付けできるだけでなく、プライマリおよび残りのすべてのリソースをどのように使用するかを明示的に指定することもできます。割合、優先度、または割合と優先度を組み合せてコンシューマ・グループ間でリソースを割り当てるリソース・プランを構成できます。
コンシューマ・グループの最大使用率制限を指定することもできます。これはデータベースの最大使用率制限と同じように動作し、コンシューマ・グループのI/O使用率を指定した値に制限します。
CDBプラン以外にも、PDBごとにリソース・プランを作成することにより、PDB内で実行されているワークロードを管理することもできます。PDBでサポートされるのは、最大8つのコンシューマ・グループが含まれる単一レベルのプランのみです。
-
リソース・プランの有効化
データベース・リソース・プランは、
RESOURCE_MANAGER_PLAN
初期化パラメータを使用して手動で有効にできます。また、ジョブ・スケジューラ・ウィンドウで自動的に有効にすることもできます。
データベースでデータベース・リソース・プランを設定すると、プランの説明が各セルに自動的に送信されます。Oracle Exadata Database Machineを実行するOracle Real Application Clusters (Oracle RAC)データベースの場合は、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
です。
関連項目:
PDB、CDBプラン、コンシューマ・グループ、コンシューマ・グループへのユーザー・セッションの割当ておよびリソース・プランの管理の詳細は、『Oracle Database管理者ガイド』のOracle Database Resource Managerを使用したリソースの管理に関する項を参照してください6.2.2 データベース間のリソース管理について
データベース間のリソース管理は、データベース間のプランを使用して管理されます。
データベース間のプランでは、複数のデータベース間でリソースを各セルにどのように割り当てるか(割合または共有別)を指定します。データベース間のプランのディレクティブでは、コンシューマ・グループではなくデータベースへの割当てを指定します。データベース間のプランは、各セルで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%を均等に割当てます。同じDB_UNIQUE_NAME
を持っているが、異なるOracle ASMクラスタに関連付けられているデータベースがある場合、Oracle Exadata System Softwareリリース19.1.0以降では、asmcluster
属性を使用すると、データベース間プランの各データベースを一意に識別できます。
ただし、別のアプリケーションの使用率がワークロードで突然上昇する場合は、各アプリケーションを分離できます。最大使用率制限を使用してアプリケーションを分離し、たとえば、各アプリケーションに40%の最大使用率制限を指定します。このようなシナリオの場合、各アプリケーションはI/Oリソースの最大40%を使用することができ、システムを完全に占有することはありません。最大使用率制限は、このような統合シナリオの場合に便利です。
特定のサービス・プロバイダには、パフォーマンス・ベースで課金されるモデルがあります。これらのプロバイダは、購入されたサービスのレベルに応じて顧客に対するパフォーマンスを保証することを求めています。ゴールド層のサービスを購入していない顧客は、ゴールド・レベルのパフォーマンスを享受できないようにする必要があります。これは、最大使用率制限が意味を持つもう1つの事例です。フラッシュ・キャッシュの最小および最大の割当て制限は、このモデルでも役に立ちます。
データベース間プランを使用して管理されるもう1つのリソースはフラッシュ・キャッシュ領域です。複数のデータベースが使用されており、プラガブル・データベース(PDB)によって記憶域が共有されている場合、フラッシュ・キャッシュは管理が必要なクリティカルなリソースになります。I/Oリソース管理では、フラッシュ・キャッシュ内の領域を保証することにより、予測可能なパフォーマンスを実現できます。また、1つのデータベースまたはPDBがフラッシュ・キャッシュ全体を占有しないようにすることもできます。これを行うには、flashcachemin
、flashcachelimit
およびflashcachesize
属性を使用します。
flashcachemin
— ブロックがコールド状態であってもデータベースに対して保証される、フラッシュ・キャッシュ内の最小サイズを指定しますflashcachelimit
— フラッシュ・キャッシュの弱い最大サイズを指定します。フラッシュ・キャッシュがフルでない場合、データベースはこのflashcachelimit
の値を超えることができます。flashcachesize
— フラッシュ・キャッシュの強い最大サイズを指定します。データベースは、常にflashcachelimit
値を超えることはできません。Oracle Exadata System Softwareリリース19.2以降では、すべてのディレクティブでflashcachesize
の合計がフラッシュ・キャッシュのサイズより大きい場合、flashcachesize
は保証された予約ではありません。それ以外の場合、フラッシュ・キャッシュはパーティション化されます。
flashcachesize
を指定されたフラッシュ・キャッシュ・グループは、フラッシュ・キャッシュがフルでない場合も、その割当て制限を超えることはできません。ただし、リソース・プランを設定する前にデータベース用のフラッシュ・キャッシュの使用量がすでにflashcachesize
の値を超えている場合、Oracle Exadata System Softwareはフラッシュ・キャッシュから事前にデータを削除しません。データは、フラッシュ・キャッシュ内の領域が不足しているときにレイジー方式で削除されます。
flashcachemin
は保証付き予約であるため、すべてのディレクティブのflashcachemin
の合計は、各グループがそれぞれの割当てを取得するように、フラッシュ・キャッシュのサイズより小さくする必要があります。
リソース・プランを管理する場合は、次の点に注意してください。
- 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では、データベースのデータベース・リソース・プランを使用して、データベースのコンシューマ・グループ間で割当てをどのように配分するかを決定します。
- 同じ
DB_UNIQUE_NAME
を持っているが、異なるOracle ASMクラスタに関連付けられているデータベースがある場合、Oracle Exadata System Softwareリリース19.1.0以降では、asmcluster
属性を使用すると、ディレクティブの指定時に各データベースを一意に識別できます。 - コンテナ・データベース(CDB)プランで
memory_min
またはmemory_limit
を指定しており、データベース間プランでflashcachesize
を指定している場合は、CDBプランのmemory_min
は無視されます。
6.2.3 I/Oリソース管理プロファイルについて
I/Oリソース管理(IORM)のデータベース間プランでは、数百ものデータベースのデータベース間プランの管理と構成を容易にするため、プロファイルがサポートされています。
プロファイルにより、データベースに対してI/Oリソースを割り当てる方法が導入されます。これは、データベースの初期化パラメータdb_performance_profile
を使用して実行されます。データベース管理者は、db_performance_profile
パラメータを設定することにより、様々なデータベースをGOLD
、SILVER
、BRONZE
として分類できます。Oracle Database Resource Managerプランと同様に、db_performance_profile
情報はすべてのストレージ・サーバー(セル)に自動的にプッシュされます。次の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
プロファイルを持つデータベースは5つの共有と60%の制限を取得し、BRONZE
プロファイルを持つデータベースは1つの共有と20%の制限を取得します。
新しいデータベースを追加する場合、db_performance_profile
パラメータを設定し、データベースを再起動します。データベース間プランを変更しなくても、データベースによってプロファイル属性が自動的に継承されます。また、プロファイル・ディレクティブとデータベース・ディレクティブが混在するデータベース間プランの作成もサポートされています。
データベース間プロファイル・プランを管理する場合、次の各事項に注意してください。
db_performance_profile
パラメータは動的パラメータでないため、データベースの再起動時にはプロファイルを更新する必要があります。type
属性を指定しない場合、ディレクティブはdatabase
ディレクティブにデフォルト設定されます。- データベース間プランで指定できるのは、8つのプロファイル・ディレクティブと1024のデータベース・ディレクティブのみです。
- プロファイル・ディレクティブでは、レベル、割当ておよびロールを指定することはできません。
OTHER
とDEFAULT
という単語は予約語です。プロファイル名をOTHER
またはDEFAULT
にすることはできません。type
属性は、カテゴリ・プランでは指定できません。- プロファイルは、カテゴリ・プランととともに指定することはできません。
- 複数のデータベースが
OTHER
ディレクティブにマップされる場合、Oracle Exadata Storage Serverでは、それらのデータベースにOracle Database Resource Managerを使用しません。この場合は、すべてのI/Oリクエストが同等に処理されます。
関連項目
6.2.4 カテゴリ・リソース管理について
データベース・リソース・マネージャでは、すべてのコンシューマ・グループでカテゴリを指定できます。コンシューマ・グループはデータベース内のユーザーの集合を表しますが、カテゴリはすべてのデータベースのコンシューマ・グループの集合を表します。カテゴリ・プランを作成すると、カテゴリに基づいて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のカテゴリにマップしてください。
関連項目
6.3 コンシューマ・グループおよびリソース・プランについて
Oracle Exadata Database Machineには、Oracle Exadata System Softwareを使用するデータ・ウェアハウス専用のデフォルトのコンシューマ・グループおよびリソース・プランが付属しています。
これらのリソース・プランは、現在の環境の要件にあわせて変更できます。
データ・ウェアハウス用のコンシューマ・グループは、次のとおりです。
-
ETL_GROUP: ETL(抽出、変換およびロード)ジョブ用のコンシューマ・グループ。
-
DSS_GROUP: クリティカルではない意思決定支援システム(DSS)の問合せ用のコンシューマ・グループ。
-
DSS_CRITICAL_GROUP: クリティカルなDSS問合せ用のコンシューマ・グループ。
データ・ウェアハウス用のリソース・プランは、次のとおりです。
6.3.1 DSS_PLANリソース・プラン
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グループに付与されます。
6.3.2 ETL_CRITCAL_PLANリソース・プラン
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 |
6.4 CDBプランおよびプラガブル・データベースについて
マルチテナント・コンテナ・データベースは、多数のユーザー定義のプラガブル・データベースをサポートしています。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 |
6.5 IORMの管理
この項では、I/Oリソース管理(IORM)のタスクについて説明します。このタスクを実行するには、DBMS_RESOURCE_MANAGER
パッケージを使用して、データベース・ホスト上にデータベース・リソース・プランを定義し、CellCLIユーティリティを使用して、各セルのIORMおよびカテゴリを指定します。
この項では、次の項目について説明します。
関連項目
6.5.1 レイテンシに優先順位を付けるための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
に変更することもできます。
6.5.2 データベース・リソース管理の管理
データベース・リソース管理を設定するには、Oracle Database Resource Managerを使用し、コンシューマ・グループを構成してセッションをコンシューマ・グループに割り当て、データベース・リソース・プランを作成してプランを有効にする必要があります。
6.5.2.1 コンシューマ・グループおよびカテゴリの設定
コンシューマ・グループおよびカテゴリは、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
6.5.2.2 コンシューマ・グループへのセッションの割当て
リソースのコンシューマ・グループにセッションを手動で割り当てるか、コンシューマ・グループのマッピング・ルールを使用して自動的に割り当てることができます。
どちらの方法でも、コンシューマ・グループを切り替えるための明示的な権限をユーザーに付与する必要があります。ユーザーが切替え可能なコンシューマ・グループを制御するには、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()
プロシージャを使用して、セッションを特定のコンシューマ・グループに手動で切り替えることもできます。
例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;
/
6.5.2.3 CDBプランの作成
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;
/
6.5.2.4 データベース・プランの作成
データベース・リソース・プランはデータベース内プランとも呼ばれ、PL/SQLのDBMS_RESOURCE_MANAGER.CREATE_PLAN()
プロシージャおよびCREATE_PLAN_DIRECTIVE()
プロシージャを使用して作成されます。
PL/SQLプロシージャのCREATE_PENDING_AREA()
を使用してリソース・プランの作成または更新を開始し、PL/SQLプロシージャのSUBMIT_PENDING_AREA()
を使用してそれらを完了する必要があります。また、OTHER_GROUPS
のディレクティブを含める必要もあります。OTHER_GROUPSには、コンシューマ・グループに明示的にマップされないすべてのセッションが保持されます。
DBMS_RESOURCE_MANAGER
PL/SQLパッケージのプロシージャを実行するには、システム権限のADMINISTER_RESOURCE_MANAGER
が必要です。このリソース・プランでは、データベース・インスタンスのCPUリソースおよびセルのI/Oリソースの両方を管理します。
例6-5 アプリケーション間でのリソースの共有
この例では、複数のアプリケーション間でデータベースを共有し、I/Oリソースを特定の比率で各アプリケーションに割り当てます。たとえば、SALES、FINANCE、MARKETINGという名前の3つのアプリケーションがあるとします。I/Oリソースを60%、25%、10%の割合でそれぞれ割り当て、これらのコンシューマ・グループにマップされないセッションに残りの5%を割り当てます。このシナリオでは、各アプリケーションにコンシューマ・グループを作成し、単一レベルのリソース・プランを作成して、各コンシューマ・グループに割り当てるI/Oリソースの割合を指定します。この割当ては、実際はコンシューマ・グループで使用可能な最小のI/Oリソースです。コンシューマ・グループで割当てが使用されなかった場合、その割当てはプランで指定した比率で他のコンシューマ・グループに再配分されます。MGMT_P1
パラメータを使用して、割当てを指定できます。
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 ワークロード間でのリソースの共有
この例では、あるワークロードを別のワークロードよりも優先する場合を想定します。たとえば、問合せの実行中にデータをデータ・ウェアハウスにロードする場合に、データ・ロードよりも問合せを常に優先するとします。このシナリオでは、問合せ用にコンシューマ・グループを2つ(レポートおよび非定型)作成し、データ・ロード用にコンシューマ・グループを1つ作成します。問合せ用の2つのコンシューマ・グループ間で、I/Oリソースを75:25の比率で共有するとします。また、問合せのコンシューマ・グループで割当てをすべて使用しない場合にのみ、データ・ロードのI/Oを発行するとします。リソース・プラン・レベルを使用して、割当て優先度を指定できます。
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;
/
6.5.2.5 データベース・リソース・プランの有効化
データベース・リソース・プランは、RESOURCE_MANAGER_PLAN
パラメータを設定することで手動で有効化できます。リソース・プランでOracle Schedulerウィンドウを定義すると、リソース・プランを自動的に有効化できます。
Oracle Schedulerウィンドウが開くと、リソース・プランが有効になります。Oracle Schedulerウィンドウが閉じると、リソース・プランが無効になります。
リソース・プランが有効になると、このイベントに関してデータベースからすべてのセルにアラートが通知され、リソース・プランが提供されます。リソース・プランが無効になる場合も、すべてのセルにアラートが通知されます。データベースではリソース・プランを1つしかアクティブにできないため、データベースのすべてのインスタンスで同じリソース・プランを有効にする必要があります。データベースでデータベース・リソース・プランが有効になっていない場合は、すべてのI/Oリクエストが同等に処理されます。
6.5.2.6 高速ファイル作成の管理
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;
/
6.5.2.7 データのインポート管理
データのインポート(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;
/
6.5.2.8 Oracle Recovery Managerのバックアップおよびコピーの管理
バックアップは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;
/
6.5.3 データベース間のリソース管理の管理
CellCLIのALTER IORMPLAN
コマンドを使用すると、Oracle Exadata Database Machineのデータベース間プランまたはカテゴリ・プランを構成できます。
CellCLIでALTER IORMPLAN
コマンドを実行できます。また、alter_iorm
という名前のテキスト・ファイルにALTER IORMPLAN
コマンドを配置し、CellCLIのSTART alter_iorm
コマンドでテキスト・ファイルを使用してコマンドを実行できます。プラン名は、cellname_IORMPLAN
に自動的に設定されます。
catPlan
パラメータでは、カテゴリ・プランを指定します。dbPlan
パラメータでは、データベース間のプランを指定します。カテゴリ・プラン、データベース間のプランまたはデータベース・リソース・プランを使用してI/Oリソースを管理するには、objectiveを設定します。
objective
オプションのデフォルトはbasic
で、I/Oリソース管理(IORM)は、構成済のリソース・プランに基づいてI/Oリソースを管理します。objective
オプションはauto
、auto
、low_latency
、balanced
またはhigh_throughput
に設定できます。
コンテナ・データベース(CDB)プランでプラガブル・データベース(PDB)に対してmemory_min
およびmemory_limit
属性が指定されている場合、これは、データベースまたはフラッシュ・キャッシュ・サイズ合計(何も指定されていない場合)に対するflashcachemin
、flashcachelimit
またはflashcachesize
値の割合として計算されます。
オプション設定:
-
データベース間のプランを構成する場合、
catPlan
およびdbPlan
はオプションのパラメータになります。catPlan
が指定されていない場合、カテゴリ間のIORMは有効になりません。同様に、dbPlan
が指定されていない場合、データベース間のIORMは有効になりません。 -
flashcachemin
およびflashcachelimit
属性を使用して、フラッシュ・キャッシュ・グループに対して保証される最小と最大の割当て制限を指定します。これらの属性を使用すると、データベース間でフラッシュ・キャッシュ領域を配分する方法を制御できます。これらの属性は、データベース間プランでのみ指定でき、CellCLIユーティリティを使用して構成されます。-
flashcachemin
属性は、データベースに対して保証されるフラッシュ・キャッシュ内の最小領域を指定します。 -
flashcachelimit
属性値は、データベースがフラッシュ・キャッシュ内で使用できる領域の最大値を指定します。flashcachelimit
は弱い最大値であり、それは、フラッシュ・キャッシュがフルでない場合にフラッシュ・キャッシュ・グループがその割当て制限を超過できることを意味します。このモデルは、Oracle Cloudおよびパフォーマンス・ベース課金の環境では機能しません。flashcachesize
と呼ばれる別の属性が、この制限の緩和に役立ちます。flashcachesize
は、グループのフラッシュ・キャッシュの使用量を制限する強い最大値です。この属性はOracle Cloud環境での使用を目的としているため、フラッシュ・キャッシュに空き領域がある場合でもflashcachesize
は超過しません。
-
-
role
属性はOracle Data Guardで使用されます。この属性では、データベースのロール(primary
またはstandby
)に基づいて異なる割当てを指定できます。デフォルトでは、データベースがいずれかのロールの場合に、データベース間プランのすべての割当てが適用されます。データベースがprimary
ロールの場合にのみ割当てを適用する場合は、role=primary
と設定します。同様に、データベースがstandby
ロールの場合にのみ割当てを適用する場合は、role=standby
と設定します。 -
同じ
DB_UNIQUE_NAME
を持っているが、異なるOracle ASMクラスタに関連付けられているデータベースがある場合、Oracle Exadata System Softwareリリース19.1.0以降では、asmcluster
属性を使用すると、各データベースを一意に識別できます。
必須設定:
-
データベース間のプランのディレクティブが有効であるためには、レベルおよび割当て、共有、最大使用率制限、またはフラッシュ・キャッシュ割当て制限ディレクティブを指定する必要があります。割当て、共有または最大使用率制限を指定していないディレクティブは無効です。割当てと共有の両方を指定するディレクティブも無効です。
-
catPlan
またはdbPlan
を指定する場合は、ディレクティブでname=other
を指定する必要があります。カテゴリ・プランの場合は、カテゴリがカテゴリ・プランで指定されていないアクティブなすべてのコンシューマ・グループの割当てがother
ディレクティブで指定されます。データベース間のプランでは、Oracle Exadata System Softwareを使用しているがデータベース間のプランで明示的に指定されていないすべてのデータベースの割当てがother
ディレクティブで指定されます。other
ディレクティブが指定されていない場合は、CellCLIユーティリティによってエラーが返されます。
例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 データベース間プランのデフォルト値へのリセット
データベース間のプランの属性をデフォルト値にリセットするには、属性を空の文字列に設定します。プラン全体をリセットしたり、catPlan
またはdbPlan
を個別にリセットしたりすることもできます。
CellCLI> ALTER IORMPLAN dbPlan="", catPlan=""
CellCLI> ALTER IORMPLAN dbPlan=""
CellCLI> ALTER IORMPLAN catPlan=""
例6-13 フラッシュ・キャッシュ・グループのデータベース間プランの構成
この例は、finance
データベースおよびdev
データベースのフラッシュ・キャッシュ・グループの最小および最大割当て制限を保証するプランを作成する方法を示しています。sales
データベースとtest
データベースは、フラッシュ・キャッシュ内の一定量の領域を保証しますが、フラッシュ・キャッシュに空き領域がある場合でも、それらのデータベースのフラッシュ・キャッシュで使用可能な領域は、指定したサイズを超えません。
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のデータベース間プランの構成
この例は、データベースがprimary
ロールかstandby
ロールかに基づいて、異なる割当てを指定したプランを作成する方法を示しています。
ALTER IORMPLAN -
dbPlan=((name=prod, share=8, role=primary), -
(name=prod, share=1, limit=25, role=standby) -
(name=default, share=2))
例6-15 同じDB_UNIQUE_NAMEを使用したデータベースのデータベース間プランの構成
この例は、同じDB_UNIQUE_NAME
を持つデータベースのプランを作成する方法を示しています。データベースは異なるOracle ASMクラスタのクライアントである必要があり、すでにASMを有効範囲にしたセキュリティを構成しておく必要があります。この機能は、Oracle Exadata System Softwareリリース19.1.0以降で使用できます。
ALTER IORMPLAN -
dbplan=((name=pdb1, share=4, flashcachemin=5G, asmcluster=asm1), -
(name=pdb1, share=2, limit=80, asmcluster=asm2), -
(name=pdb2, share=2, flashcachelimit=2G, asmcluster=asm1), -
name=default, share=1, flashcachelimit=1G))
6.5.4 I/Oリソース管理プランの表示
セルでCellCLIのLIST IORMPLAN
コマンド使用すると、セルの現在のデータベース間プランを表示できます。次の例は、データベース間プランの属性の詳細なリストを示しています。
例6-16 データベース間プランの詳細の表示
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
関連項目
6.5.5 I/Oリソース管理の構成の確認
次のチェックリストを使用して、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;
出力はデータベースからの大小のリクエストによって使用されるディスク・リソースのパーセントを示したものです。
関連項目
6.5.6 プランの使用例
同じストレージを共有する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データベースのパフォーマンスが影響を受ける可能性があります。
リソースは、次の例に示すとおり指定できます。
6.5.6.1 割当てを使用したリソースの指定
次のようにデータベース間のプランを指定することにより、これらの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-17に示すように、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-17 割当ての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))
6.5.6.2 共有を使用したリソースの指定
OLTPデータベースのPRODは最も重要であるため、PRODデータベースには16の共有を指定できます。DWデータベースでは4つの共有、PROD_TESTでは2つの共有、PROD_DEVでは1つの共有を取得します。このプランでは、PRODデータベースのI/O発行の可能性がDWデータベースの4倍になります。発行するI/OがPRODにない場合は、共有に基づいて他のデータベースが使用されます。
例6-18 共有のALTER IORMPLAN構文
CellCLI> ALTER IORMPLAN - dbPlan=( - (name=prod, share=16), - (name=dw, share=4), - (name=prod_test, share=2), - (name=prod_dev, share=1))
6.5.6.3 フラッシュ・キャッシュおよびフラッシュ・ログの管理
データベースのI/Oリソースではなく、フラッシュ・キャッシュおよびフラッシュ・ログの管理にIORMを使用する場合があります。この場合は、次の例に示すように、ALTER IORMPLANコマンドを使用してI/Oの優先順位付けを無効にし、PROD_TESTおよびPROD_DEVデータベースでフラッシュ・キャッシュおよびフラッシュ・ログを無効にします。
注意:
フラッシュ・キャッシュおよびフラッシュ・ログはデフォルトでオンになっているため、PRODおよびDWデータベースでフラッシュ・キャッシュおよびフラッシュ・ログを明示的に有効にする必要がありません。これらは、PROD_TESTおよびPROD_DEVデータベースでの設定と対比した例に示されています。
例6-19 フラッシュ・キャッシュおよびフラッシュ・ログを管理するための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))
6.5.6.4 データベースおよびPDBのためのフラッシュ・キャッシュ割当て制限の管理
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の割当て制限は、データベース間プランのディレクティブで指定されたデータベース用のmemory_min
とmemory_limit
値のパーセンテージとして計算されます。
前述の例で、データベース間プランを指定せず、フラッシュ・キャッシュのサイズが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
は強い制限であり、同じディレクティブ内にflashcachelimit
とともに指定できません。データベースtest
にはフラッシュ・キャッシュのディレクティブが指定されていません。したがって、そのデータベースおよびそのPDB(もしあれば)では、フラッシュ・キャッシュの割当て制限は管理されません。
CDBにflashcachesize
が指定されている場合は、CDBリソース・プランのmemory_min
の値は無視され、memory_limit
の値が正規化されて、それぞれのPDBのフラッシュ・キャッシュ・サイズの計算に使用されます。newcdb
CDBにはflashcachesize
が指定されているため、memory_min
の値は無視されます。flashcachesize
は、前述のように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
の値は絶対的な値として指定され、追加の正規化は必要ありません。flashcachemin
は保証付きの予約であるため、flashcachemin
の合計は、すべてのディレクティブ全体でフラッシュ・キャッシュの合計サイズより小さくする必要があります。