1. ユーザーズ・ガイド
  2. I/Oリソースの管理

5 I/Oリソースの管理

Exadata I/Oリソース管理(IORM)は、複数のワークロードおよびデータベース間でOracle Exadata Database MachineのI/Oリソースをどのように共有するかを管理するためのツールです。

データベース内のワークロードを管理するために、Oracle Database Resource ManagerがExadata IORMと連動するように拡張されます。

  • I/Oリソース管理(IORM)の理解
    IORMでは、ストレージ・サーバーのI/Oリソースをセル単位で管理します。I/Oリクエストによりセルの容量が飽和状態になり始めると、構成済のリソース・プランに従って、受信するI/OリクエストがIORMによってスケジュール調整されます。
  • IORMの管理
    I/Oリソース管理(IORM)に関連する様々な管理タスクを実行できます。

関連項目

5.1 I/Oリソース管理(IORM)の理解

IORMは、ストレージ・サーバーのI/Oリソースをセルごとに管理します。I/Oリクエストによりセルの容量が飽和状態になり始めると、構成済のリソース・プランに従って、受信するI/OリクエストがIORMによってスケジュール調整されます。

親トピック: I/Oリソースの管理

5.1.1 Exadata Database MachineのI/Oリソース管理(IORM)について

IORMには、リソース割当てを管理するための多くの機能が用意されています。各機能は個別に使用できますが、他の機能と組み合せて使用することもできます。

多くの場合、ストレージは複数のタイプのワークロードおよびデータベース間で共有され、パフォーマンスの問題が発生することもあります。たとえば、本番環境のデータ・ウェアハウスの1つで多数のパラレル問合せを実行すると、他のデータベースにおいてクリティカルなOLTPのパフォーマンスに影響を与える場合があります。このような問題は、ストレージ・システムをオーバー・プロビジョニングすることにより軽減できますが、この方法では、共有ストレージのコスト削減の利点もなくなります。クリティカルでないタスクをピーク時以外に実行するようにスケジュール設定することもできますが、この手動処理には手間がかかります。

IORMを使用することにより、ユーザー定義のポリシーに従って、複数のワークロードおよびデータベース間でOracle Exadata Storage Serverを共有できます。データベース内のワークロードを管理する場合は、Oracle Exadata Storage ServerのI/Oリソースを管理できるように拡張されたOracle Database Resource Managerを使用して、データベース・リソース・プランを定義できます。含まれるプラガブル・データベース(PDB)を管理できるコンテナ・データベース(CDB)リソース・プランを定義することもできます。複数のデータベースを管理する場合は、データベース間のプランを定義できます。または、クラスタベースのリソース管理を実行するクラスタ・プランを定義できます。

I/Oリソースに競合がある場合、IORMでは、発行するI/Oリクエストとキューに入れるI/Oリクエストを迅速に振り分けることにより、I/Oをスケジュール設定します。I/Oリクエストは、リソース・プランに従ってリソース割当てを超えていないワークロードに対してすぐに処理されます。I/Oリクエストは、リソース割当てを超えるワークロードのキューに入れられます。キューに入れられたI/Oは、ワークロードがリソース割当てを超えなくなったときに、リソース・プランの優先順位に従って処理されます。セルが容量を下回って動作していて、I/Oリソースの競合がない場合、IORMはI/Oリクエストをキューに入れず、使用可能なI/Oリソースを消費するためにワークロードがリソース割当てを超えるようにします。

たとえば、本番環境のデータベースとテスト用のデータベースでOracle Exadata Storage Serverリソースを共有している場合は、本番環境のデータベースを優先するようにリソース・プランを構成できます。この場合、テスト用のデータベースの負荷が本番環境のデータベースのパフォーマンスに影響を与える場合は、本番環境のデータベースのI/Oパフォーマンスが影響を受けないように、IORMによってI/Oリクエストがスケジュール調整されます。つまり、テスト用のデータベースのI/Oリクエストは、本番環境のデータベースのI/Oリクエストのパフォーマンスに影響を与えずに発行可能になるまで、キューに入れられます。

フラッシュIORMにより、フラッシュ・キャッシュ内のクリティカルなOLTP I/Oリクエストのレイテンシを保護します。OLTP I/Oリクエストと同時にフラッシュで表スキャンが実行されている場合、OLTPのレイテンシに大きく影響します。フラッシュIORMでは、表スキャン、および他の優先度の低いI/Oリクエストがキューに入れられ、制限されます。クリティカルなOLTP I/Oリクエストはキューに入れられません。フラッシュ・ドライブがクリティカルなOLTP I/Oリクエストの処理のためにビジーでない場合、IORMプランでのリソース割当てに基づいて、キューに入れられたI/Oリクエストが発行されます。

  • IORMのobjectiveについて
    I/Oリソース管理(IORM)のobjectiveオプションは、IORMの最適化モードを指定します。
  • IORMプラン
    Exadata I/Oリソース管理(IORM)は、様々なIORMプランを使用してリソースを管理します。
  • リソース割当て方法
    shareまたはallocationを使用して、IORMプランにリソースを割り当てることができます。

親トピック: I/Oリソース管理(IORM)の理解

5.1.1.1 IORMのobjectiveについて

I/Oリソース管理(IORM)のobjectiveオプションは、IORMの最適化モードを指定します。

IORMのobjectiveは、CellCLI ALTER IORMPLANコマンドを使用して、すべてのストレージ・サーバーで個別に構成されます。システム全体のパフォーマンスを一貫したものにするには、ストレージ・クラスタ内のすべてのストレージ・サーバーが同じIORM構成設定を使用するようにします。

有効なobjective値は次のとおりです。

  • auto - IORMがアクティブなワークロードおよびリソース・プランに基づいて最適なモードを決定します。IORMは、監視対象のワークロードおよび有効なリソース・プランに基づいて、継続的かつ動的に最適化の目標を決定します。ほとんどのユースケースで、autoがお薦めの値です。

    Oracle Exadata System Softwareリリース21.2.0以降、autoが新規デプロイメントのデフォルト設定です。

  • high_throughput - 高いスループットが要求されるクリティカルなDSSのワークロードを最適化します。この設定により、ディスクのスループットが向上しますが、I/Oレイテンシが長くなります。

  • low_latency - 非常に適切なディスク・レイテンシが要求されるクリティカルなOLTPワークロードを最適化します。この設定により、ディスク使用率が制限され、レイテンシが可能なかぎり最短になりますが、スループットが低下します。

  • balanced - 低ディスク・レイテンシと高スループットのバランスを取ります。これは、クリティカルなOLTPおよびDSSワークロードが混在する場合に役立ちます。この設定により、大きいI/Oのディスク使用率がlow_latencyより小さい範囲に制限され、レイテンシとスループットがバランスします。

  • basic - この設定は、小さいI/Oの最大遅延を制限する場合に使用します。それ以外の場合は、I/Oの優先順位付けを無効にします。これは、Oracle Exadata System Softwareリリース20.1.0以前の新規デプロイメントのデフォルト設定です。具体的には、この設定を使用して、次のようにします。

    • IORMは、スマート・スキャンやその他のディスク集中型のI/O操作の前にログの書込み、バッファ・キャッシュの読取りおよびその他のクリティカルなI/Oを優先順位付けすることで、これらの処理において極端に長い待機時間が発生しないように監視します。
    • IORMでは、フラッシュ・キャッシュおよびフラッシュ・ログへのアクセスを管理します。
    • IORMは、異なるワークロード間でリソースが共有されるようにスキャンを管理します。
    • IORMでは、IORMプランの最大使用率制限は強制されません。プラン割当ては、極端に長い待機時間が発生しないように保護するためだけに使用され、プランへの適合は考慮されていません。プランに厳密に適合させるために、最大利用率を制限する場合は、objectiveオプションをbasic以外の値に設定する必要があります。

高容量(HC)ストレージ・サーバーでは、フラッシュIORMは、スマート・スキャンおよび優先度の低いI/Oより先にフラッシュ・デバイスへのクリティカルなI/Oの優先度を設定することでOLTPレイテンシを保護します。これは、objectiveオプションの設定に関係なく、デフォルトで発生します。

Extreme Flash (EF)ストレージ・サーバーでは、IORMのobjectiveによりフラッシュIORMをある程度制御できます。EFストレージ・サーバーでは、objectiveオプションがbasic、autoまたはbalancedに設定されている場合、フラッシュIORMはHCサーバーと同じように動作します。ただし、EFストレージ・サーバーでは、high_throughputはクリティカルなI/Oレイテンシを犠牲にしてスキャン・スループットを向上させ、low_latencyは両方のワークロードが同時に実行される場合に、スキャン・スループットが大幅に低下することを犠牲にして最大のレイテンシ保護を提供します。

5.1.1.2 IORMプラン

Exadata I/Oリソース管理(IORM)は、様々なIORMプランを使用してリソースを管理します。

Oracle Database Resource Managerを使用すると、データベース内のリソースを管理できます。これは、データベース内リソース管理とも呼ばれます。データベース・リソース・プランは、異なるワークロードまたはコンシューマ・グループ間でのリソースの割当て方法を指定します。データベースがOracle Exadata Storage Serverを使用する場合、データベース・リソース・プランはストレージ・サーバーに送信され、IORMによって使用されます。データベースでデータベース・リソース・プランを有効にしていない場合は、データベース内リソース管理が無効になり、データベースのすべてのI/Oリソースが単一のワークロードとして処理されます。

データベース間のリソース管理では、複数のデータベースのリソースを管理できます。データベース間リソース管理は、CellCLIのALTER IORMPLANコマンドを使用してデータベース間プラン(dbplan)を指定することで構成されます。dbplanには、特定のデータベースのリソース割当てを指定するディレクティブが含まれています。この機能は、Oracle Exadata Storage Serverリソースを共有しているデータベースが複数あり、特定のデータベースへのリソース割当てを制御する場合に使用できます。

クラスタ・リソース管理を使用すると、同じストレージ・サーバー・リソースを共有する複数のOracle Grid Infrastructureクラスタ間でリソースを管理できます。クラスタ・リソース管理は、CellCLIのALTER IORMPLANコマンドを使用してクラスタ・プラン(clusterplan)を指定することで構成されます。clusterplanには、特定のクラスタ内のすべてのデータベースに適用されるリソース割当てを指定するディレクティブが含まれます。

ノート:

クラスタ・プランは、Oracle Exadata System Softwareリリース21.2.0で初めて導入されました。
カテゴリ・リソース管理では、実行中の作業のカテゴリに従ってリソースが割り当てられます。たとえば、すべてのデータベースにOLTP、レポート、メンテナンスの3つのカテゴリのワークロードがあるとします。これらのワークロード・カテゴリに基づいてI/Oリソースを割り当てるには、カテゴリ・リソース管理を使用できます。カテゴリ・リソース管理では、Oracle Database Resource Managerを使用して、各データベースのワークロード・カテゴリと、各ストレージ・サーバーで定義されているカテゴリ・プラン(catplan)を定義します。

ノート:

Oracle Exadata System Softwareリリース21.2.0以降、カテゴリ・プランは非推奨となり、カテゴリ・プランが設定されると警告メッセージが発行されます。

各データベース内に構成されているデータベース・リソース・プラン定義とは別に、Exadata IORMプラン(dbplanやclusterplanなど)は、CellCLI ALTER IORMPLANコマンドを使用してすべてのストレージ・サーバーで個別に構成されます。システム全体のパフォーマンスを一貫したものにするには、ストレージ・クラスタ内のすべてのストレージ・サーバーが同じIORM構成設定を使用するようにします。

5.1.1.3 リソース割当て方法

shareまたはallocationを使用して、IORMプランにリソースを割り当てることができます。

share値は、各エンティティの相対的な重要度を表します。shareベースのリソース割当てでは、share値が高いほど、優先度が高くなり、I/Oリソースへのアクセスが強化されます。たとえば、share値が2のデータベースは、share値が1のデータベースのリソース割当ての2倍になります。

有効なshare値は1から32 (1は最下位のshare、32は最上位のshare)です。プランのすべてのshare値の合計は32768より大きくできません。

データベース間プラン(dbplan)には、shareベースのリソース割当てをお薦めします。クラスタ・プラン(clusterplan)では、shareベースのリソース割当てが唯一のオプションです。

allocationベースのリソース管理の場合、allocationではリソース割当てをパーセンテージ(0から100)で指定します。各割当てはlevelに関連付けられます。有効なlevel値は1から8で、allocation値の合計は、各levelで100を超えることはできません。最初にリソースがlevel1に割り当てられ、次に残りのリソースがlevel2に割り当てられます。

推奨されませんが、allocationベースのリソース管理はデータベース間プラン(dbplan)で使用できます。カテゴリ・プラン(catplan)では、allocationベースのリソース管理が唯一のオプションです。

5.1.2 データベース内のデータベース・リソース管理について

Oracle Database Resource Managerでは、データベース内のワークロードを管理できます。

通常、データベースには多くのタイプのワークロードがあります。これらのワークロードは、パフォーマンス要件および発行されるI/Oの量が異なる場合があります。データベース・リソース管理はデータベース・レベルで構成されます。この場合は、Oracle Database Resource Managerを使用してデータベース・リソース・プランを作成します。1つのデータベース内に複数のタイプのワークロードがある場合は、この機能を使用する必要があります。これらのワークロードでデータベース・リソースの割当てを共有する方法を指定するポリシーを定義できます。1つのデータベースでのみOracle Exadata Storage Serverリソースを使用している場合、必要なリソース管理機能はこれのみです。

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に割り当てられているshares数を定義します。sharesは、プランの他のPDBと比較したときの、そのPDBの相対的な優先度を定義します。

    PDBの最大使用率制限を指定できます。

    CDBリソース・プランでは、各PDBにmemory_minおよびmemory_limitも指定できます。これらのパラメータは、PDBごとに様々なキャッシュ割当て制限を定義し、データベース・インスタンスのメモリー・サイズ設定には影響しません。

  • リソース・プランの作成

    データベースのリソース・プランはデータベース内リソース・プランとも呼ばれ、データベースのコンシューマ・グループ間でCPUとI/Oリソースをどのように割り当てるかを指定します。リソース・プランはOracle Database Resource Managerを使用して作成されます。これには、各コンシューマ・グループに対するリソース割当てディレクティブが含まれており、allocation とlevelで構成されています。最大8つのlevelまで指定できます。

    • level2のコンシューマ・グループでは、level1で割り当てられなかったリソースや、level1のコンシューマ・グループによって使用されなかったリソースが取得されます。
    • level3のコンシューマ・グループには、level1および2の割当てが一部残っている場合にのみリソースが割り当てられます。
    • リソース・プランには、各コンシューマ・グループのリソース割当てのディレクティブが含まれ、allocationおよびlevelで構成されます。

    複数のlevelで優先度付けできるだけでなく、プライマリおよび残りのすべてのリソースをどのように使用するかを明示的に指定することもできます。allocation、優先度、またはallocationと優先度を組み合せてコンシューマ・グループ間でリソースを割り当てるリソース・プランを構成できます。

    コンシューマ・グループの最大使用率制限を指定することもできます。これはデータベースの最大使用率制限と同じように動作し、コンシューマ・グループのI/O使用率を指定した値に制限します。

    CDBプラン以外にも、PDBごとにリソース・プランを作成することにより、PDB内で実行されているワークロードを管理することもできます。PDBでサポートされるのは、最大8つのコンシューマ・グループが含まれる単一levelのプランのみです。

  • リソース・プランの有効化

    データベース・リソース・プランは、RESOURCE_MANAGER_PLAN初期化パラメータを使用して手動で有効にできます。また、ジョブ・スケジューラ・ウィンドウで自動的に有効にすることもできます。

データベースでデータベース・リソース・プランを設定すると、プランの説明が各セルに自動的に送信されます。Oracle Exadataを実行する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です。

関連項目

親トピック: I/Oリソース管理(IORM)の理解

5.1.3 データベース間のリソース管理について

データベース間のリソース管理では、同じ共有ストレージを使用して複数のデータベースのリソースを管理できます。

データベース間のプランでは、複数のデータベース間でリソースを各ストレージ・サーバーにどのように割り当てるか(allocationまたはshare別)を指定します。データベース間のプランのディレクティブでは、コンシューマ・グループではなくデータベースへの割当てを指定します。データベース間のプランは、各ストレージ・サーバーでCellCLIユーティリティを使用して構成および有効化されます。

関連項目

親トピック: I/Oリソース管理(IORM)の理解

5.1.3.1 データベース間のIORMプランのディレクティブについて

データベース間のプランのディレクティブは、データベースのDB_UNIQUE_NAMEを識別子として使用して指定されます。

allocationベースのリソース管理を使用する場合、各ディレクティブがallocation量とlevel(1から8)で構成される点でデータベース・リソース・プランと同じです。各プランでは、任意のlevelのallocationの合計を100%以下にする必要があります。データベース間のプランとデータベース・リソース・プランの異なる点は、データベース間のプランにはサブプランを含めることができず、I/Oリソースのディレクティブしか含めることができないことです。

shareベースのプランでは、allocationによる割当ておよびlevelではなく、相対的なshareを使用します。このようなプランは実装は簡単ですが、allocationによる割当てと同様の効果があります。各データベースには、1から32の整数のshare値が割り当てられます。shareの合計は32768まで可能です。shareベースのプランでは、データベース間プラン内で最大1024のディレクティブをサポートします。たとえば、クリティカルなデータベースのFINANCEに4つのshareがあり、優先度の低いデータベースのREPORTINGに1つのshareがある場合、リソース競合期間中のFINANCEデータベースのI/O発行の可能性はREPORTINGデータベースの4倍になります。

Oracle Exadata System Softwareでは、データベース間プランおよびデータベース・リソース・プランを併用してI/Oリソースを割り当てます。

  • 最初に、データベース間のプランによって各データベースにI/Oリソースが割り当てられます。
  • 次に、各データベースのデータベース・リソース・プランによってコンシューマ・グループにI/Oリソースが割り当てられます。データベースにアクティブなデータベース・リソース・プランがない場合は、すべてのユーザーI/Oが同じように処理されます。バックグラウンドのI/Oは、重要度に基づいてユーザーI/Oに対して優先度が付けられます。

ベスト・プラクティスとしては、ストレージを共有するデータベースごとにディレクティブを作成することをお薦めします。これは、shareベースのプランでは自動的に実行されますが、allocationベースのプランでは自動的に実行されません。明示的なディレクティブのないデータベースをallocationによる割当てプランで管理できるようにするには、OTHERという名前の割当てを作成します。明示的なディレクティブのないデータベースは、OTHERグループ・ディレクティブの割当てを使用して管理されます。

shareベースのプランで明示的にマッピングされない各データベースのデフォルトのshareは、それぞれ1です。ただし、shareベースのプランでは、DEFAULTディレクティブを使用して様々なIORM属性のデフォルト値を指定できます。

異なるOracle ASMクラスタにDB_UNIQUE_NAMEが同じデータベースがある場合、Oracle Exadata System Softwareリリース19.1.0以降では、asmcluster属性を使用すると、データベース間プランの各データベースを一意に識別できます。

5.1.3.2 統合と分離でのデータベース間のプランの使用

データベース間のリソース管理プランを使用すると、データベースを統合または分離する際のリソースの管理に役立ちます。

同じOracle Exadata Storage Serverを共有する4つの異なるデータベースを統合する場合を検討します。すべてのデータベースが同じ優先度の場合は、IORMを使用してI/Oリソースの25%を各データベースに均等に割り当てることができます。1つのデータベースが他のデータベースよりも重要な場合、IORMを使用して、より高いshareのI/Oリソースを与えることができます。

最大使用率制限の定義は、統合シナリオの場合にも便利です。制限を使用すると、ワークロードが突然上昇した場合に各データベースを分離できます。たとえば、データベースごとに40%の最大使用率制限を定義できます。これにより、システムを独占できるデータベースがないことが保証されます。ただし、データベースが割り当てられた制限に達すると、空き容量を利用できなくなります。したがって、制限を指定すると、ディスクをフル容量未満で実行できます。

また、制限を使用したリソース管理は、購入されたサービスのレベルに応じて顧客に対するパフォーマンスをサービス・プロバイダが保証する、パフォーマンス・ベース課金のユースケースにも理想的です。たとえば、より低いパフォーマンス階層を購入する顧客は、より高いパフォーマンスに対して購入する顧客よりも制限する必要があります。

5.1.3.3 IORMを使用したExadataキャッシュ・リソースへのデータベース・アクセスの制御

IORMを使用して、重要なOracle Exadata Storage Serverキャッシュ・リソースへのアクセスを管理できます。

データベース間のIORMプランでflashcacheおよびflashlog属性を使用して、Exadataスマート・フラッシュ・キャッシュおよびフラッシュ・ログへのアクセスを制御できます。flashcache=offを設定すると、指定したデータベースがフラッシュ・キャッシュを使用できないようにできます。同様に、flashlog=offを設定すると、指定したデータベースがフラッシュ・ログを使用できなくなります。デフォルトでは、すべてのデータベースでキャッシングおよびロギングにフラッシュ・メモリーを使用できます。

同様に、適切に構成されたサーバーでは、xrmemcacheおよびxrmemlog属性を使用してExadata RDMAメモリー(XRMEM)リソースへのアクセスを制御できます。

ノート:

Exadata X8MおよびX9Mストレージ・サーバー・モデルでのみ、pmemcacheおよびpmemlog属性をxrmemcacheおよびxrmemlogと同じ意味で使用できます。ただし、IORMプランにPMEM属性とXRMEM属性を混在させることはできません。

これらの属性により、特に統合環境において、重要なキャッシュ・リソースをミッション・クリティカル・データベース用に確保できます。

5.1.3.4 IORMプランでのフラッシュ・キャッシュ管理について

I/Oリソース管理では、Exadataスマート・フラッシュ・キャッシュ内の領域を保証することにより、予測可能なパフォーマンスを実現できます。

複数のデータベースが使用されており、プラガブル・データベース(PDB)によって記憶域が共有されている場合、フラッシュ・キャッシュ領域は、管理が必要なクリティカルなリソースになります。IORMにより、重要なデータベースまたはPDB用の領域を確保しながら、重要性の低いエンティティや不正なエンティティによってフラッシュ・キャッシュ全体が使用されないようにすることができます。

データベース間プランで次の属性を使用すると、フラッシュ・キャッシュ・リソースに制限を設定できます。強い制限は、キャッシュがフルでない場合でも、指定された制限を超過できないことを意味します。弱い制限は、使用可能なリソースがある場合に、指定された制限を超過できることを意味します。

  • flashCacheMin — ブロックがコールド状態であっても指定されたデータベースに対して保証される、フラッシュ・キャッシュ領域の最小容量を指定します。これは強い制限です。

    flashCacheMinは保証付き予約であるため、すべてのディレクティブのflashCacheMinの合計は、各データベースがそれぞれの割当てを取得するように、フラッシュ・キャッシュのサイズより小さくする必要があります。

  • flashCacheLimit — データベースで使用できるフラッシュ・キャッシュ領域の弱い最大容量を指定します。フラッシュ・キャッシュがフルでない場合、データベースはflashCacheLimit値を超過できます。

  • flashCacheSize — データベースで使用できるフラッシュ・キャッシュ領域の強い最大容量を指定します。flashCacheSize値を超えることはできません。

    ただし、flashCacheSizeを、データベースが使用している現在の領域よりも小さい値に設定した場合、Oracle Exadata System Softwareリリース20.1.0以降では、超過分のデータがキャッシュから事前に消去されます。以前は、別のデータによって上書きされた場合のみ、超過分のデータが削除されていました。

    Oracle Exadata System Softwareリリース19.2.0以降では、すべてのディレクティブでflashCacheSizeの合計がフラッシュ・キャッシュのサイズより大きい場合、flashCacheSizeは保証された予約ではありません。この場合、flashCacheMinを指定して、保証付きの最小割当て制限を定義することもできます。

各データベース内で、memory_minディレクティブおよびmemory_limitディレクティブを使用して、コンテナ・データベース(CDB)リソース・プランで、Oracle Database Resource ManagerによりPDBの最小割当て制限および最大割当て制限を管理できます。

データベース間IORMプラン・ディレクティブのキャッシュ制限は、対応するCDBプランの設定を制約します。したがって、データベース間IORMプラン・ディレクティブでデータベースのflashcacheminおよびflashcachesize設定が指定されている場合、CDBプランでPDB固有のmemory_min割当て制限はflashcachemin設定の一部になり、PDB固有のmemory_limit値はflashcachesizeの一部になります。

ただし、データベース間IORMプラン・ディレクティブでflashcacheminを指定せずにflashcachesizeが指定されている場合、PDB固有のmemory_min設定は無視されますが、memory_limit設定は引き続きflashcachesizeの一部になります。

5.1.3.5 IORMプランでのXRMEMキャッシュ管理について

I/Oリソース管理(IORM)では、Exadata RDMAメモリー・キャッシュ(XRMEMキャッシュ)の領域を保証することで、予測可能なパフォーマンスを実現できます。

複数のデータベースが使用されており、プラガブル・データベース(PDB)によって記憶域が共有されている場合、XRMEMキャッシュ領域は、管理が必要なクリティカルなリソースになります。IORMにより、重要なデータベースまたはPDB用の領域を確保しながら、重要性の低いエンティティや不正なエンティティによってXRMEMキャッシュ全体が使用されないようにできます。

データベース間プランで次の属性を使用すると、XRMEMキャッシュ・リソースに制限を設定できます。強い制限は、キャッシュがフルでない場合でも、指定された制限を超過できないことを意味します。弱い制限は、使用可能なリソースがある場合に、指定された制限を超過できることを意味します。

  • xrmemCacheMin — ブロックがコールド状態であっても指定されたデータベースに対して保証される、XRMEMキャッシュ領域の最小容量を指定します。これは強い制限です。

    xrmemCacheMinは保証付き予約であるため、すべてのディレクティブのxrmemCacheMinの合計は、各データベースがそれぞれの割当てを取得するように、XRMEMキャッシュのサイズより小さくする必要があります。

  • xrmemCacheLimit — データベースで使用できるXRMEMキャッシュ領域の弱い最大容量を指定します。XRMEMキャッシュがフルでない場合、データベースはxrmemCacheLimit値を超過できます。

  • xrmemCacheSize — データベースで使用できるXRMEMキャッシュ領域の強い最大容量を指定します。xrmemCacheSize値を超えることはできません。

    ただし、xrmemCacheSizeを、データベースが使用している現在の領域よりも小さい値に設定した場合、超過分のデータがキャッシュから事前に消去されます。

    すべてのディレクティブでxrmemCacheSizeの合計がXRMEMキャッシュのサイズより大きい場合、xrmemCacheSizeは保証された予約ではありません。この場合、xrmemCacheMinを指定して、保証付きの最小割当て制限を定義することもできます。

    ノート:

    Exadata X8MおよびX9Mストレージ・サーバー・モデルでのみ、xrmemのかわりにpmemで始まる属性名を同じ意味で使用できます。たとえば、xrmemCacheMinのかわりにpmemCacheMinです。ただし、IORMプランにPMEM属性とXRMEM属性を混在させることはできません。

各データベース内で、memory_minディレクティブおよびmemory_limitディレクティブを使用して、コンテナ・データベース(CDB)リソース・プランで、Oracle Database Resource ManagerによりPDBの最小割当て制限および最大割当て制限を管理できます。

データベース間IORMプラン・ディレクティブのキャッシュ制限は、対応するCDBプランの設定を制約します。したがって、データベース間IORMプラン・ディレクティブでデータベースのxrmemCacheMinおよびxrmemCacheSize設定が指定されている場合、CDBプランでPDB固有のmemory_min割当て制限はxrmemCacheMin設定の一部になり、PDB固有のmemory_limit値はxrmemCacheSizeの一部になります。

ただし、データベース間IORMプラン・ディレクティブでxrmemCacheMinを指定せずにxrmemCacheSizeが指定されている場合、PDB固有のmemory_min設定は無視されますが、memory_limit設定は引き続きxrmemCacheSizeの一部になります。

5.1.3.6 IORMプランでのPMEMキャッシュ管理について

ノート:

このトピックは、23.1.0より前のOracle Exadata System Softwareリリースにのみ適用されます。それ以外の場合は、「IORMプランでのXRMEMキャッシュの管理について」を参照してください。

I/Oリソース管理(IORM)では、Oracle Exadata Storage Server X8MおよびX9Mで使用可能な永続メモリー(PMEM)キャッシュの領域を保証することで、予測可能なパフォーマンスを実現できます。

複数のデータベースが使用されており、プラガブル・データベース(PDB)によって記憶域が共有されている場合、PMEMキャッシュ領域は、管理が必要なクリティカルなリソースになります。IORMにより、重要なデータベースまたはPDB用の領域を確保しながら、重要性の低いエンティティや不正なエンティティによってPMEMキャッシュ全体が使用されないようにすることができます。

データベース間プランで次の属性を使用すると、PMEMキャッシュ・リソースに制限を設定できます。強い制限は、キャッシュがフルでない場合でも、指定された制限を超過できないことを意味します。弱い制限は、使用可能なリソースがある場合に、指定された制限を超過できることを意味します。

  • pmemCacheMin — ブロックがコールド状態であっても指定されたデータベースに対して保証される、PMEMキャッシュ領域の最小容量を指定します。これは強い制限です。

    pmemCacheMinは保証付き予約であるため、すべてのディレクティブのpmemCacheMinの合計は、各データベースがそれぞれの割当てを取得するように、PMEMキャッシュのサイズより小さくする必要があります。

  • pmemCacheLimit — データベースで使用できるPMEMキャッシュ領域の弱い最大容量を指定します。PMEMキャッシュがフルでない場合、データベースはpmemCacheLimit値を超過できます。

  • pmemCacheSize — データベースで使用できるPMEMキャッシュ領域の強い最大容量を指定します。pmemCacheSize値を超えることはできません。

    ただし、pmemCacheSizeを、データベースが使用している現在の領域よりも小さい値に設定した場合、Oracle Exadata System Softwareリリース20.1.0以降では、超過分のデータがキャッシュから事前に消去されます。以前は、別のデータによって上書きされた場合のみ、超過分のデータが削除されていました。

    すべてのディレクティブでpmemCacheSizeの合計がPMEMキャッシュのサイズより大きい場合、pmemCacheSizeは保証された予約ではありません。この場合、pmemCacheMinを指定して、保証付きの最小割当て制限を定義することもできます。

各データベース内で、memory_minディレクティブおよびmemory_limitディレクティブを使用して、コンテナ・データベース(CDB)リソース・プランで、Oracle Database Resource ManagerによりPDBの最小割当て制限および最大割当て制限を管理できます。

データベース間IORMプラン・ディレクティブのキャッシュ制限は、対応するCDBプランの設定を制約します。したがって、データベース間IORMプラン・ディレクティブでデータベースのpmemCacheMinおよびpmemCacheSize設定が指定されている場合、CDBプランでPDB固有のmemory_min割当て制限はpmemCacheMin設定の一部になり、PDB固有のmemory_limit値はpmemCacheSizeの一部になります。

ただし、データベース間IORMプラン・ディレクティブでpmemCacheMinを指定せずにpmemCacheSizeが指定されている場合、PDB固有のmemory_min設定は無視されますが、memory_limit設定は引き続きpmemCacheSizeの一部になります。

5.1.3.7 データベース間のリソース・プランの管理のヒント

データベース間のリソース・プランを作成および管理する場合は、次の情報に注意してください。

  • Oracle Exadataが1つのデータベースのみをホストする場合、データベース間プランは不要です。
  • データベース間のプランが指定されていない場合は、すべてのデータベースで割当てが同じになります。
  • OTHERディレクティブにマップされるデータベースが1つしかなく、他のすべてのデータベースに明示的なディレクティブがある場合、Oracle Exadata System Softwareでは、そのデータベースのデータベース・リソース・プランを使用して、そのデータベースのコンシューマ・グループ間でOTHERデータベースの割当てをどのように再配分するかを決定します。
  • 複数のデータベースがOTHERディレクティブにマップされる場合、Oracle Exadata System Softwareでは、それらのデータベースにOracle Database Resource Managerを使用しません。この場合は、すべてのI/Oリクエストが同等に処理されます。
  • shareベースのプランでは、プランで明示的に名前が指定されていない場合でも、各データベースで独自のディレクティブを取得します。Oracle Exadata System Softwareでは、データベースのデータベース・リソース・プランを使用して、データベースのコンシューマ・グループ間で割当てをどのように配分するかを決定します。

  • データベース間のプランのディレクティブは、データベースのDB_UNIQUE_NAMEを識別子として使用して指定されます。

    DB_UNIQUE_NAME値自体では、大文字と小文字は区別されません。ただし、同じOracle RACデータベースの複数のインスタンスでDB_UNIQUE_NAMEに使用される文字の大文字と小文字の区別が一貫していない場合(PRODやprodなど)、IORMが正しく動作しないことがあります。したがって、各Oracle RACデータベース間でDB_UNIQUE_NAMEに使用される文字の大文字と小文字の区別が一貫していることを確認してください。

    値が指定されていない場合、DB_UNIQUE_NAME値はDB_NAMEから導出されます。その場合は、Oracle RACデータベース全体でDB_NAME値に使用される文字の大文字と小文字の区別が一貫していることを確認してください。

  • 同じDB_UNIQUE_NAMEを持っているが、異なるOracle ASMクラスタに関連付けられているデータベースがある場合、Oracle Exadata System Softwareリリース19.1.0以降では、asmcluster属性を使用すると、ディレクティブの指定時に各データベースを一意に識別できます。

  • データベース間IORMプラン・ディレクティブのキャッシュ制限は、対応するコンテナ・データベース(CDB)プランの設定を制約します。

    したがって、データベース間IORMプラン・ディレクティブでデータベースのflashcacheminおよびflashcachesize設定が指定されている場合、CDBプランでPDB固有のmemory_min割当て制限はflashcachemin設定の一部になり、PDB固有のmemory_limit値はflashcachesizeの一部になります。

    ただし、データベース間IORMプラン・ディレクティブでflashcacheminを指定せずにflashcachesizeが指定されている場合、PDB固有のmemory_min設定は無視されますが、memory_limit設定は引き続きflashcachesizeの一部になります。

    CDBプラン内のPDB固有の割当て制限(memory_minおよびmemory_limit)とデータベース間IORMプラン内のキャッシュ固有の設定(xrmemcacheminおよびxrmemcachesize)の関係に関して、Exadata RDMAメモリー・キャッシュ(XRMEMキャッシュ)にも同じことが当てはまります。

5.1.4 クラスタのリソース管理について

クラスタのリソース管理では、同じ共有ストレージを使用して複数のクラスタのリソースを管理できます。

ノート:

クラスタ・プランは、Oracle Exadata System Softwareリリース21.2.0で初めて導入されました。

I/Oリソース管理(IORM)クラスタ・プランでは、複数のクラスタ間でストレージ・サーバー・リソースを割り当てる方法を指定します。クラスタ・プランの各ディレクティブは、個々のデータベースまたはコンシューマ・グループではなく、クラスタへの割当てを指定します。

たとえば、clusterAおよびclusterBという2つのクラスタをホストするシステムについて考えてみます。ここで、clusterAに3つのshareがあり、clusterBに1つのshareがあるshareベースのリソース割当てを持つクラスタ・プランを考えてみます。その場合、および他のIORMプランがない場合、clusterAで実行されているすべてのデータベースはI/Oリソースの75%をshareし、clusterBのデータベースは残りの25%をshareします。

クラスタ・プランは、データベース間リソース・プランと連携できますが、データベース間リソース・プランが(allocationおよびlevelディレクティブを使用して)allocationベースのリソース管理を使用していない場合のみ可能です。この場合、両方のプランのディレクティブが適用され、リソースのshareが決定されます。

したがって、前述の例から、clusterA内のデータベースがshareベースのリソース割当てを使用したデータベース間リソース・プランにあるとします。その場合、クラスタ・プランでclusterAに割り当てられたリソースは、データベース間リソース・プランのディレクティブを使用してデータベース間でさらに分割および共有されます。

クラスタ・プランは、カテゴリ・プランと連携して動作できません。つまり、カテゴリ・プラン・ディレクティブが存在する場合、IORMクラスタ・プラン・ディレクティブは設定できません。同様に、クラスタ・プラン・ディレクティブが存在する場合は、カテゴリ・プラン・ディレクティブを設定できません。

クラスタ・プランは、CellCLIのALTER IORMPLANコマンドを使用して、各ストレージ・サーバーで構成および有効化されます。クラスタ・プランを操作するには、ASMを有効範囲にしたセキュリティも構成する必要があります。

関連項目

親トピック: I/Oリソース管理(IORM)の理解

5.1.5 カテゴリ・リソース管理について

カテゴリは、すべてのデータベースのコンシューマ・グループの集合を表します。

ノート:

Oracle Exadata System Softwareリリース21.2.0以降、カテゴリ・プランは非推奨となり、カテゴリ・プランが設定されると警告メッセージが発行されます。

Oracle Database Resource Managerでは、すべてのコンシューマ・グループでカテゴリを指定できます。カテゴリ・プランを作成すると、カテゴリに基づいてI/Oリソースを管理できます。たとえば、Oracle Exadata Storage Serverを共有するすべてのデータベースで、batchカテゴリのコンシューマ・グループよりもinteractiveカテゴリのコンシューマ・グループを優先するように優先順位を指定できます。

カテゴリの数の追加、または事前定義済のカテゴリの変更を行うことができます。同じセル・ストレージを使用するすべてのデータベースで、コンシューマ・グループを適切なカテゴリにマップしてください。明示的にカテゴリを指定されていないコンシューマ・グループは、デフォルトでOTHERカテゴリに設定されます。

カテゴリ・プランは、CellCLIユーティリティを使用してセルで構成および有効化されます。一度に有効にできるカテゴリ・プランは1つのみです。次の表は、Oracle Databaseに用意されている事前定義済のカテゴリとサンプルの割合を説明したものです。

表5-1 サンプルのカテゴリ・リソース管理プラン

カテゴリ名 カテゴリの説明 level1 (%) level2 (%) level3 (%)

ADMINISTRATIVE

緊急の管理タスクなど、優先度が非常に高い処理用。

このカテゴリは必須です。

80

未設定

未設定

INTERACTIVE

OLTPトランザクションなど、優先度が高くパフォーマンスに依存する処理用。

未設定

70

未設定

BATCH

クリティカルでないレポートやバックアップなど、優先度の低い処理用。

未設定

未設定

70

MAINTENANCE

自動化されたタスクなど、優先度が低い処理用。

未設定

未設定

10

OTHER

カテゴリ・ラベルがなく、現在のカテゴリ・プランにないカテゴリを参照するすべてのコンシューマ・グループ用。

このカテゴリは必須です。

未設定

未設定

20

前述の表に示すサンプル・プランでは、すべてのデータベースでadministrativeアクティビティが最も優先されます。interactiveアクティビティはbatch、maintenanceおよびその他のアクティビティよりも優先されます。このサンプル・プランのリソース割当ては次のとおりです。

  • level1には、I/Oリソースの80%が割り当てられます。ADMINISTRATIVEカテゴリはlevel1の唯一のカテゴリです。

  • level2には、level1で未割当てまたは未使用のすべてのリソースが割り当てられます。この例では、I/Oリソースの20%とADMINISTRATIVEカテゴリで使用されていないリソースがlevel2に割り当てられます。INTERACTIVEカテゴリでは、level2の量の70%が割り当てられます。

  • level3のカテゴリには、INTERACTIVEカテゴリで使用されていないリソースを含む、残りのリソースが割り当てられます。BATCHカテゴリには、残りのリソースの70%、OTHERカテゴリには20%、MAINTENANCEカテゴリには10%が割り当てられます。

すべてのデータベースのすべての管理コンシューマ・グループは、ADMINISTRATIVEカテゴリにマップしてください。重要なOLTPトランザクションやタイムクリティカルなレポートなど、優先度の高いすべてのユーザー・アクティビティは、INTERACTIVEカテゴリにマップしてください。レポートやメンテナンス、優先度の低いOLTPトランザクションなど、優先度の低いすべてのユーザー・アクティビティは、BATCH、MAINTENANCEおよびOTHERのカテゴリにマップしてください。

関連項目

親トピック: I/Oリソース管理(IORM)の理解

5.1.6 コンシューマ・グループおよびリソース・プランについて

Oracle Exadataには、Oracle Exadata System Softwareを使用するデータ・ウェアハウス専用のデフォルトのコンシューマ・グループおよびリソース・プランが付属しています。

これらのリソース・プランは、現在の環境の要件にあわせて変更できます。

データ・ウェアハウス用のコンシューマ・グループは、次のとおりです。

  • ETL_GROUP: ETL(抽出、変換およびロード)ジョブ用のコンシューマ・グループ。
  • DSS_GROUP: クリティカルではない意思決定支援システム(DSS)の問合せ用のコンシューマ・グループ。
  • DSS_CRITICAL_GROUP: クリティカルなDSS問合せ用のコンシューマ・グループ。

データ・ウェアハウス用のリソース・プランは、次のとおりです。

  • DSS_PLANリソース・プラン
    DSS_PLANリソース・プランは、クリティカルではないDSS問合せおよびETLジョブよりもクリティカルなDSS問合せを優先するデータ・ウェアハウス用に設計されています。
  • ETL_CRITCAL_PLANリソース・プラン
    ETL_CRITICAL_PLANでは、DSS問合せよりもETLが優先されます。

親トピック: I/Oリソース管理(IORM)の理解

5.1.6.1 DSS_PLANリソース・プラン

DSS_PLANリソース・プランは、クリティカルではないDSS問合せおよびETLジョブよりもクリティカルなDSS問合せを優先するデータ・ウェアハウス用に設計されています。

このプランでは、SYS_GROUPが最高の優先度を持ち、次にDSS_CRITICAL_GROUP、DSS_GROUPが続き、その次にETL_GROUPとBATCH_GROUPの組合せが続きます。帯域幅のすべてを使用できるコンシューマ・グループはありません。

表5-2 データ・ウェアハウス用のDSS_PLANリソース・プラン

コンシューマ・グループ level1 (%) level2 (%) level3 (%) level4 (%)

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グループには、level2で75%のみが割り当てられます。未使用の割当ては、同じlevelの他のコンシューマ・グループではなく、すべて次のlevelに付与されます。つまり、DSS_CRITICAL_GROUPグループで割当てが完全に使用されない場合、その割当ては同じlevelのORA$DIAGNOSTICSグループやORA$AUTOTASK_SUBPLANグループには付与されません。かわりに、割当てはlevel3のDSS_GROUPグループに付与されます。

5.1.6.2 ETL_CRITCAL_PLANリソース・プラン

ETL_CRITICAL_PLANでは、DSS問合せよりもETLが優先されます。

このプランでは、SYS_GROUPグループに帯域幅の75%が割り当てられます。残りの帯域幅は、level2の割当てで指定される割合に基づいて、他のコンシューマ・グループ間で分割されます。ETL_GROUPおよびDSS_CRITICAL_GROUPグループの割当て(35%)は、DSS_GROUPおよびBATCH_GROUPグループの割当て(10%)より多くなっています。

表5-3 データ・ウェアハウス用のETL_CRITICAL_PLANリソース・プラン

コンシューマ・グループ level1 (%) level2 (%) level3 (%) level4 (%)

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

未設定

未設定

5.1.7 CDBプランおよびプラガブル・データベースについて

コンテナ・データベース(CDB)では、リソースについて競合する複数のPDB内に、複数のワークロードを使用できます。

Oracle Multitenantコンテナ・データベース(CDB)は、多数のユーザー定義のプラガブル・データベース(PDB)をサポートしています。CDBでは、リソースは次のレベルで管理されます。

  • CDBレベル: Oracle Database Resource Managerを使用して、システム・リソースおよびCDBリソースを巡って競合関係にある複数のPDBのワークロードを管理します。管理者は、PDBへのリソースの割当て方法を指定し、特定のPDBのリソース使用率を制限できます。

  • PDBレベル: Oracle Database Resource Managerを使用して、各PDB内のワークロードを管理します。

次の例では、SALES、SERVICESおよびHRという3つのPDBのCDBプランの概要を示します。PDBは、そのCDBプラン内でそれぞれ異なるshares数および最大使用率制限が使用されます。

PDB名 共有のためのディレクティブ 使用率制限のためのディレクティブ Memory_min Memory_limit

SALES

3

無制限

20

未設定

SERVICES

3

無制限

20

未設定

HR

1

70

未設定

50

親トピック: I/Oリソース管理(IORM)の理解

5.2 IORMの管理

I/Oリソース管理(IORM)に関連する様々な管理タスクを実行できます。

このタスクを実行するには、DBMS_RESOURCE_MANAGERパッケージを使用して、データベース・サーバー上にデータベース・リソース・プランを定義し、CellCLIユーティリティを使用して、各セルのIORMプランを指定します。

関連項目

親トピック: I/Oリソースの管理

5.2.1 IORMのobjectiveの設定

IORMのobjectiveを設定するには、CellCLIのALTER IORMPLANコマンドを使用します。

たとえば:

CellCLI> ALTER IORMPLAN objective=auto

ノート:

IORMのobjectiveは、CellCLI ALTER IORMPLANコマンドを使用して、すべてのストレージ・サーバーで個別に構成されます。システム全体のパフォーマンスを一貫したものにするには、ストレージ・クラスタ内のすべてのストレージ・サーバーが同じIORM構成設定を使用するようにします。

関連項目

親トピック: IORMの管理

5.2.2 データベース・リソース管理の管理

データベース・リソース管理を設定するには、Oracle Database Resource Managerを使用し、コンシューマ・グループを構成してセッションをコンシューマ・グループに割り当て、データベース・リソース・プランを作成してプランを有効にする必要があります。

親トピック: IORMの管理

5.2.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ビューには、データベース内のカテゴリに関する情報が表示されます。

例5-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;
/

例5-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
5.2.2.2 コンシューマ・グループへのセッションの割当て

リソースのコンシューマ・グループにセッションを手動で割り当てるか、コンシューマ・グループのマッピング・ルールを使用して自動的に割り当てることができます。

どちらの方法でも、コンシューマ・グループを切り替えるための明示的な権限をユーザーに付与する必要があります。ユーザーが切替え可能なコンシューマ・グループを制御するには、PL/SQLプロシージャのDBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP()を使用します。

コンシューマ・グループのマッピング・ルールは、ユーザー名、データベースとの接続にセッションで使用されたサービス名、クライアント・プログラムの名前などのセッション属性に基づきます。コンシューマ・グループのマッピング・ルールを作成するには、例5-3に示すようにSET_CONSUMER_GROUP_MAPPINGプロシージャを使用します。SET_CONSUMER_GROUP_MAPPINGプロシージャを実行する前に、最初にペンディング・エリアを作成する必要があります。

PL/SQLのDBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER()プロシージャまたはSWITCH_CONSUMER_GROUP_FOR_SESS()プロシージャを使用して、セッションを特定のコンシューマ・グループに手動で切り替えることもできます。

例5-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;
/
5.2.2.3 CDBプランの作成

CDBプランでは、データベース・サーバーのCPUリソースおよびExadataストレージ・サーバーのフラッシュ・キャッシュ領域やI/O帯域幅を管理します。

CDBプランは、PL/SQLのDBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN()プロシージャおよびCREATE_CDB_PLAN_DIRECTIVE()プロシージャを使用して作成されます。CDBプランは、ルートPDB以外から構成することはできません。

例5-4 CDBプランを使用したPDB間でのリソースの配分

この例は、SALES、SERVICESおよびHRという3つのPDB間でのリソースの配分方法を示しています。SALESおよびSERVICESは優先度が高く、またHRのshares数が1つであるのに対し、SALESおよびSERVICESのshares数はそれぞれ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;
/
5.2.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リソースの両方を管理します。

例5-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;
/

例5-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;
/
5.2.2.5 データベース・リソース・プランの有効化

データベース・リソース・プランは、RESOURCE_MANAGER_PLANパラメータを設定することで手動で有効化できます。リソース・プランでOracle Schedulerウィンドウを定義すると、リソース・プランを自動的に有効化できます。

Oracle Schedulerウィンドウが開くと、リソース・プランが有効になります。Oracle Schedulerウィンドウが閉じると、リソース・プランが無効になります。

リソース・プランが有効になると、このイベントに関してデータベースからすべてのセルにアラートが通知され、リソース・プランが提供されます。リソース・プランが無効になる場合も、すべてのセルにアラートが通知されます。データベースではリソース・プランを1つしかアクティブにできないため、データベースのすべてのインスタンスで同じリソース・プランを有効にする必要があります。データベースでデータベース・リソース・プランが有効になっていない場合は、すべてのI/Oリクエストが同等に処理されます。

5.2.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を使用して優先度を変更することはできません。

例5-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;
/
5.2.2.7 データのインポート管理

I/Oリソース管理(IORM)を使用すると、ETLの優先度だけでなく、ETLで使用されるI/Oリソースの量も制御できます。

データのインポート、または抽出、変換およびロード(ETL)は、データ・ウェアハウスのメンテナンスの重要な部分です。レポートや問合せはデータがロードされるまで実行できないため、ETLがパフォーマンスにとって非常に重要になる場合があります。このような場合は、ETLが他のすべての問合せよりも優先するようにします。また、特定の時間で完了しない場合にしか優先する必要がない場合など、ETLが優先度の低いバックグラウンドのアクティビティになる場合もあります。

ETLを管理するには、次を実行します。

  • ETLセッションをETL_GROUPコンシューマ・グループにマップします。

    ETLのマッピング・ルールは、通常はユーザー名またはクライアント・プログラム名に基づきます。データ・ポンプは、DATALOAD関数で実行されます。DATALOAD関数は、デフォルトでETL_GROUPコンシューマ・グループにマップされます。

  • リソース・プランにETL_GROUPグループを含めます。

非圧縮データを圧縮データとしてインポートするには:

例5-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;
/

圧縮データとしての非圧縮データのインポート

デフォルトでExadataハイブリッド列圧縮表として新規表を作成するようにターゲット表領域が構成されている場合に、TRANSFORM:SEGMENT_ATTRIBUTES=nオプションを使用すると、非圧縮データを圧縮データとしてインポートできます。

5.2.2.8 Oracle Recovery Managerのバックアップおよびコピーの管理

I/Oリソース管理(IORM)を使用すると、RMAN I/Oのリソースの消費と優先順位を制御できます。

バックアップは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コンシューマ・グループにマップされます。これらの関数は、次の例に示すように他のコンシューマ・グループに再マップできます。

例5-9 コンシューマ・グループを使用したリソースの管理

この例は、BACKUP関数をBATCH_GROUPコンシューマ・グループにマップし、COPY関数をMAINTENANCE_GROUPコンシューマ・グループにマップする方法を示しています。 

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;
/

5.2.3 IORM計画の管理

IORMプランは、CellCLIのALTER IORMPLANコマンドを使用して管理できます。

親トピック: IORMの管理

5.2.3.1 IORM計画の設定

IORMプランを設定するには、CellCLIのALTER IORMPLANコマンドを使用します。

たとえば:

CellCLI> ALTER IORMPLAN                                                 -
         dbplan=((name=sales01, share=4),                               -
                 (name=sales02, share=3),                               -
                 (name=dev01, share=1),                                 -
                 (name=DEFAULT, share=2))

一般的なIORMプラン定義は長く複雑であるため、ALTER IORMPLANコマンドをスクリプト・ファイルに配置し、CellCLIのSTARTコマンドを使用して実行することを検討してください。

ノート:

Exadata I/Oリソース管理(IORM)は、CellCLIのALTER IORMPLANコマンドを使用して、すべてのストレージ・サーバーで個別に構成されます。システム全体のパフォーマンスを一貫したものにするには、ストレージ・クラスタ内のすべてのストレージ・サーバーが同じIORM構成設定を使用するようにします。

5.2.3.2 共有ベースのリソース管理の使用

share値は、各エンティティの相対的な重要度を表します。

shareベースのリソース割当てでは、share値が高いほど、優先度が高くなり、I/Oリソースへのアクセスが強化されます。たとえば、share値が2のデータベースは、share値が1のデータベースのリソース割当ての2倍になります。

有効なshare値は1から32 (1は最下位のshare、32は最上位のshare)です。プランのすべてのshare値の合計は32768より大きくできません。

データベース間プラン(dbplan)には、shareベースのリソース割当てをお薦めします。クラスタ・プラン(clusterplan)では、shareベースのリソース割当てが唯一のオプションです。

次の例は、データベース間プランでshareベースのリソース管理を使用する方法を示しています。同じOracle Exadata Storage Serverリソースを共有する4つのデータベースについて考えてみます。4つのデータベースは次のとおりです。

  • PRODという名前のクリティカルなOLTP本番環境用データベース
  • PROD_TESTという名前のテスト用データベース
  • PROD_DEVという名前の開発用データベース
  • DWという名前のデータ・ウェアハウス用データベース

OLTP本番環境用データベースでは、一般的に小さいI/Oリクエストが発行されます。これらのリクエストのレイテンシが短いことは重要な要件です。データ・ウェアハウスでは、多数の大きいI/Oリクエストが発行されるので、各I/OリクエストのレイテンシよりもI/Oスループットが重要になります。I/Oリソース管理を使用しないと、DWデータベースで発行されるI/Oリクエストの数がストレージ・サブシステムの容量を超えてしまい、PRODデータベースで発行されるI/Oリクエストのレイテンシが増加します。また、テスト用データベース(PROD_TEST)および開発用データベース(PROD_DEV)で発行されるI/Oリクエストにより、PRODデータベースおよびDWデータベースのパフォーマンスが影響を受ける可能性があります。

I/Oリソースの適切な分散を確保するために、次のように共有ベースのデータベース間プランを定義できます。

CellCLI> ALTER IORMPLAN                                    -
         dbplan=((name=prod, share=16),                    -
                 (name=dw, share=4),                       -
                 (name=prod_test, share=2),                -
                 (name=DEFAULT, share=1))

データベース間プランの例を使用すると、I/Oリソースの競合が発生した場合はクリティカルなOLTPデータベース(PROD)が優先されます。具体的には、PRODのI/O shareは、DWの4倍、PROD_TESTの8倍、およびPROD_DEVに割り当てられたデフォルトのshareの16倍です。

いつでもshare割当てを変更して、相対的な優先度を調整できます。

親トピック: IORMプランの管理

5.2.3.3 割当てベースのリソース管理の使用

IORMでは、allocation値でリソース割当てをパーセンテージ(0から100)で指定します。

allocationベースのリソース管理では、各allocationがlevelに関連付けられます。有効なlevel値は1から8で、allocation値の合計は、各levelで100を超えることはできません。最初にリソースがlevel1に割り当てられ、次に残りのリソースがlevel2に割り当てられます。

推奨されませんが、allocationベースのリソース管理はデータベース間プラン(dbplan)で使用できます。カテゴリ・プラン(catplan)では、allocationベースのリソース管理が唯一のオプションです。

次の例は、データベース間プランでallocationベースのリソース管理を使用する方法を示しています。同じOracle Exadata Storage Serverリソースを共有する4つのデータベースについて考えてみます。4つのデータベースは次のとおりです。

  • PRODという名前のクリティカルなOLTP本番環境用データベース
  • PROD_TESTという名前のテスト用データベース
  • PROD_DEVという名前の開発用データベース
  • DWという名前のデータ・ウェアハウス用データベース

OLTP本番環境用データベースでは、一般的に小さいI/Oリクエストが発行されます。これらのリクエストのレイテンシが短いことは重要な要件です。データ・ウェアハウスでは、多数の大きいI/Oリクエストが発行されるので、各I/OリクエストのレイテンシよりもI/Oスループットが重要になります。I/Oリソース管理を使用しないと、DWデータベースで発行されるI/Oリクエストの数がストレージ・サブシステムの容量を超えてしまい、PRODデータベースで発行されるI/Oリクエストのレイテンシが増加します。また、テスト用データベース(PROD_TEST)および開発用データベース(PROD_DEV)で発行されるI/Oリクエストにより、PRODデータベースおよびDWデータベースのパフォーマンスが影響を受ける可能性があります。

I/Oリソースの適切な分散を確保するために、次のようにallocationベースのデータベース間プランを定義できます。

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)では、I/Oリソースの競合期間中にI/Oリソースの80%が保証されます。
  • DWデータベースには、残りの未使用のI/Oの80%を割り当てます。
  • 最後に、PROD_TESTおよびPROD_DEVデータベースには、未使用のI/Oの50%および40%をそれぞれ割り当てます。また、この例では、10%のallocationが、プランに明示的にリストされていないOTHERデータベース用に予約されています。

いつでもallocationを変更して、リソース割当てを調整できます。

親トピック: IORMプランの管理

5.2.3.4 limit属性の使用

limit属性では、使用可能リソースの割合としてフラッシュI/O使用率の上限を指定します。

limit属性を使用すると、データベース間プランまたはクラスタ・プランでのエンティティのフラッシュI/O使用率を制限できます。この属性により、指定したエンティティで、指定した制限を超えてフラッシュI/Oリソースが使用されないようにします。この属性は、フラッシュ・デバイス上のI/Oにのみ適用されます。これにはフラッシュベースのグリッド・ディスクおよびExadataスマート・フラッシュ・キャッシュが含まれます。

たとえば、本番とテスト用のデータベースでOracle Exadata Storage Serverリソースが共有されている場合は、次のように、データベース間プランでテスト用データベースのフラッシュ使用率上限を設定できます。 

ALTER IORMPLAN dbplan=((name=prod),               -
                       (name=test, limit=20),     -
                       (name=DEFAULT, limit=10))

最大使用率制限が指定されている場合、超過容量は使用されない可能性があります。そのため、使用率の上限を指定すると、全容量が使用されることなくフラッシュ・デバイスを稼働させることができます。

ノート:

limit値を低く指定すると、パフォーマンスに深刻な影響を与える可能性があり、通常はお薦めしません。

制限を使用したリソース管理は、パフォーマンス・ベース課金のユースケースに理想的ですが、公平性を実現するためには使用できません。かわりに、share属性を使用してI/Oリソースが均等に配分されるようにします。

親トピック: IORMプランの管理

5.2.3.5 フラッシュ・キャッシュおよびフラッシュ・ログへのアクセスの制御

IORMを使用して、フラッシュ・キャッシュおよびフラッシュ・ログへのアクセスを管理できます。

データベース間プランでflashcache属性およびflashlog属性を使用して、フラッシュ・キャッシュおよびフラッシュ・ログへのアクセスを制御できます。データベース間プランで設定されている場合、これらの属性は特定のデータベースによるアクセスを制御します。

次の例は、prod_testデータベースおよびprod_devデータベースのフラッシュ・キャッシュとフラッシュ・ログを無効にする方法を示しています。この例では、dw_testデータベースのフラッシュ・ログも無効になります。 

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=dw_test, flashcache=on, flashlog=off))

これらの属性は、他の属性と組み合せて使用することもできます。たとえば:

CellCLI> ALTER IORMPLAN                                                   -
         dbplan=((name=prod, share=8, flashcache=on, flashlog=on),        -
                (name=dw, share=6, flashcache=on, flashlog=on),           -
                (name=prod_test, share=2, flashcache=off, flashlog=off),  -
                (name=prod_dev, share=1, flashcache=off, flashlog=off),   -
                (name=dw_test, share=2, flashcache=on, flashlog=off),     -
                (name=other, share=1))

flashcache=onまたはflashlog=onはデフォルト設定であるため、明示的に設定する必要はありません。

親トピック: IORMプランの管理

5.2.3.6 フラッシュ・キャッシュの属性の使用

IORMプランでフラッシュ・キャッシュ属性を使用して、Exadataスマート・フラッシュ・キャッシュの領域割当てを保証できます。

IORMでは、フラッシュ・キャッシュ属性を使用することで、重要なデータベース用の領域を確保しながら、重要性の低いエンティティや不正なエンティティによってフラッシュ・キャッシュ全体が使用されないようにすることができます。これらの属性は、データベース間プランでのみ指定でき、CellCLIユーティリティを使用して構成されます。

次の属性を使用すると、フラッシュ・キャッシュ・リソースの制限を設定できます。強い制限は、メモリー・キャッシュがフルでない場合でも、指定された制限を超過できないことを意味します。弱い制限は、使用可能なリソースがある場合に、指定された制限を超過できることを意味します。

  • flashCacheMin — ブロックがコールド状態であっても指定されたデータベースに対して保証される、フラッシュ・キャッシュ領域の最小容量を指定します。これは強い制限です。

    flashCacheMinは保証付き予約であるため、すべてのディレクティブのflashCacheMinの合計は、各データベースがそれぞれの割当てを取得するように、フラッシュ・キャッシュのサイズより小さくする必要があります。

  • flashCacheLimit — データベースで使用できるフラッシュ・キャッシュ領域の弱い最大容量を指定します。フラッシュ・キャッシュがフルでない場合、データベースはflashCacheLimit値を超過できます。

  • flashCacheSize — データベースで使用できるフラッシュ・キャッシュ領域の強い最大容量を指定します。flashCacheSize値を超えることはできません。

    ただし、flashCacheSizeを、データベースが使用している現在の領域よりも小さい値に設定した場合、Oracle Exadata System Softwareリリース20.1.0以降では、超過分のデータがキャッシュから事前に消去されます。以前は、別のデータによって上書きされた場合のみ、超過分のデータが削除されていました。

    Oracle Exadata System Softwareリリース19.2.0以降では、すべてのディレクティブでflashCacheSizeの合計がフラッシュ・キャッシュのサイズより大きい場合、flashCacheSizeは保証された予約ではありません。この場合、flashCacheMinを指定して、保証付きの最小割当て制限を定義することもできます。

例5-10 フラッシュ・キャッシュ属性を使用したデータベース間プランの構成

この例は、フラッシュ・キャッシュ属性を使用してデータベース間プランを作成する方法を示しています。

この例では、salesデータベースとtestデータベースでflashCacheSizeパラメータを使用することにより、フラッシュ・キャッシュの領域容量が割り当てられます。ただし、フラッシュ・キャッシュに空き領域がある場合でも、データベースは指定した割当てを超過できません。

financeデータベースおよびdevデータベースは、flashCacheMinを使用することにより最小割当て制限が保証されます。また、これらのデータベースは、フラッシュ・キャッシュに空き領域がある場合は、指定したflashCacheLimitサイズを超過することもできます。 

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))

例5-11 フラッシュ・キャッシュ属性を使用したデータベース間プランの構成

Oracle Exadata System Softwareリリース19.3.0以降は、同じターゲットに対してflashCacheMinとflashCacheSizeの両方を指定できます。 

ALTER IORMPLAN                                                  -
 dbplan=((name=sales, share=8, flashCacheMin=3G, 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))

親トピック: IORMプランの管理

5.2.3.7 XRMEMリソースへのアクセスの制御

IORMを使用して、Exadata RDMAメモリー(XRMEM)リソースへのアクセスを管理できます。

データベース間プランでxrmemcacheおよびxrmemlog属性を使用して、XRMEMキャッシュおよびXRMEMログへのアクセスを制御できます。データベース間プランで設定されている場合、これらの属性は特定のデータベースによるアクセスを制御します。

ノート:

Exadata X8MおよびX9Mストレージ・サーバー・モデルでのみ、pmemcacheおよびpmemlog属性をxrmemcacheおよびxrmemlogと同じ意味で使用できます。ただし、IORMプランにPMEM属性とXRMEM属性を混在させることはできません。

次の例は、prod_testデータベースおよびprod_devデータベースのXRMEMキャッシュとXRMEMログを無効にする方法を示しています。この例では、dw_testデータベースのXRMEMログも無効になります。 

CellCLI> ALTER IORMPLAN                                        -
         dbplan=((name=prod, xrmemcache=on, xrmemlog=on),        -
                (name=dw, xrmemcache=on, xrmemlog=on),           -
                (name=prod_test, xrmemcache=off, xrmemlog=off),  -
                (name=prod_dev, xrmemcache=off, xrmemlog=off),   -
                (name=dw_test, xrmemcache=on, xrmemlog=off))

これらの属性は、他の属性と組み合せて使用することもできます。たとえば:

CellCLI> ALTER IORMPLAN                                                 -
         dbplan=((name=prod, share=8, xrmemcache=on, xrmemlog=on),        -
                (name=dw, share=6, xrmemcache=on, xrmemlog=on),           -
                (name=prod_test, share=2, xrmemcache=off, xrmemlog=off),  -
                (name=prod_dev, share=1, xrmemcache=off, xrmemlog=off),   -
                (name=dw_test, share=2, xrmemcache=on, xrmemlog=off),     -
                (name=other, share=1))

xrmemcache=onまたはxrmemlog=onはデフォルト設定であるため、明示的に設定する必要はありません。

親トピック: IORMプランの管理

5.2.3.8 XRMEMキャッシュ属性の使用

IORMプランでXRMEMキャッシュ属性を使用して、Exadata RDMAメモリー・キャッシュ(XRMEMキャッシュ)での領域割当てを保証できます。

IORMでは、XRMEMキャッシュ属性を使用することで、重要なデータベース用の領域を確保しながら、重要性の低いエンティティや不正なエンティティによってXRMEMキャッシュ全体が使用されないようにできます。これらの属性は、データベース間プランでのみ指定でき、CellCLIユーティリティを使用して構成されます。

次の属性を使用して、XRMEMキャッシュ・リソースの制限を設定できます。強い制限は、メモリー・キャッシュがフルでない場合でも、データベースがその割当て制限を超過できないことを意味します。弱い制限は、使用可能なリソースがある場合に、指定された制限を超過できることを意味します。

  • xrmemCacheMin — ブロックがコールド状態であっても指定されたデータベースに対して保証される、XRMEMキャッシュ領域の最小容量を指定します。これは強い制限です。

    xrmemCacheMinは保証付き予約であるため、すべてのディレクティブのxrmemCacheMinの合計は、各データベースがそれぞれの割当てを取得するように、XRMEMキャッシュのサイズより小さくする必要があります。

  • xrmemCacheLimit — データベースで使用できるXRMEMキャッシュ領域の弱い最大容量を指定します。XRMEMキャッシュがフルでない場合、データベースはxrmemCacheLimit値を超過できます。

  • xrmemCacheSize — データベースで使用できるXRMEMキャッシュ領域の強い最大容量を指定します。xrmemCacheSize値を超えることはできません。

    ただし、xrmemCacheSizeを、データベースが使用している現在の領域よりも小さい値に設定した場合、超過分のデータがキャッシュから事前に消去されます。

    すべてのディレクティブでxrmemCacheSizeの合計がXRMEMキャッシュのサイズより大きい場合、xrmemCacheSizeは保証された予約ではありません。この場合、xrmemCacheMinを指定して、保証付きの最小割当て制限を定義することもできます。

    ノート:

    Exadata X8MおよびX9Mストレージ・サーバー・モデルでのみ、xrmemのかわりにpmemで始まる属性名を同じ意味で使用できます。たとえば、xrmemCacheMinのかわりにpmemCacheMinです。ただし、IORMプランにPMEM属性とXRMEM属性を混在させることはできません。

例5-12 XRMEMキャッシュ属性を使用したデータベース間プランの構成

この例は、XRMEMキャッシュ属性を使用してデータベース間プランを作成する方法を示しています。

この例では、salesデータベースとtestデータベースでxrmemCacheSizeパラメータを使用することにより、XRMEMキャッシュの領域容量が割り当てられます。ただし、XRMEMキャッシュに空き領域がある場合でも、データベースは指定した割当てを超過できません。

fincデータベースおよびdevデータベースは、xrmemCacheMinを使用することにより最小割当て制限が保証されます。また、これらのデータベースは、XRMEMキャッシュに空き領域がある場合は、指定したxrmemCacheLimitサイズを超過することもできます。

このプランの例には、様々なフラッシュ・キャッシュ属性も含まれています。

ALTER IORMPLAN dbplan=                                                                             -
((name=sales, share=8, xrmemCacheSize=2G, flashCacheSize=10G),                                     -
(name=finc, share=8, xrmemCacheMin=1G, xrmemCacheLimit=2G, flashCacheLimit=10G, flashCacheMin=2G), -
(name=dev, share=2, xrmemCacheMin=500M, xrmemCacheLimit=1G, flashCacheLimit=4G, flashCacheMin=1G), -
(name=test, share=1, limit=10, xrmemCacheSize=200M))

親トピック: IORMプランの管理

5.2.3.9 PMEMキャッシュおよびPMEMログへのアクセスの制御

ノート:

このトピックは、23.1.0より前のOracle Exadata System Softwareリリースにのみ適用されます。それ以外の場合は、「XRMEMリソースへのアクセスの制御」を参照してください。

IORMを使用して、永続メモリー(PMEM)キャッシュおよびPMEMログへのアクセスを管理できます。

データベース間プランでpmemcache属性およびpmemlog属性を使用して、PMEMキャッシュおよびPMEMログへのアクセスを制御できます。データベース間プランで設定されている場合、これらの属性は特定のデータベースによるアクセスを制御します。

次の例は、prod_testデータベースおよびprod_devデータベースのPMEMキャッシュとPMEMログを無効にする方法を示しています。この例では、dw_testデータベースのPMEMログも無効になります。 

CellCLI> ALTER IORMPLAN                                        -
         dbplan=((name=prod, pmemcache=on, pmemlog=on),        -
                (name=dw, pmemcache=on, pmemlog=on),           -
                (name=prod_test, pmemcache=off, pmemlog=off),  -
                (name=prod_dev, pmemcache=off, pmemlog=off),   -
                (name=dw_test, pmemcache=on, pmemlog=off))

これらの属性は、他の属性と組み合せて使用することもできます。たとえば:

CellCLI> ALTER IORMPLAN                                                 -
         dbplan=((name=prod, share=8, pmemcache=on, pmemlog=on),        -
                (name=dw, share=6, pmemcache=on, pmemlog=on),           -
                (name=prod_test, share=2, pmemcache=off, pmemlog=off),  -
                (name=prod_dev, share=1, pmemcache=off, pmemlog=off),   -
                (name=dw_test, share=2, pmemcache=on, pmemlog=off),     -
                (name=other, share=1))

pmemcache=onまたはpmemlog=onはデフォルト設定であるため、明示的に設定する必要はありません。

親トピック: IORMプランの管理

5.2.3.10 PMEMキャッシュ属性の使用

ノート:

このトピックは、23.1.0より前のOracle Exadata System Softwareリリースにのみ適用されます。それ以外の場合は、「XRMEMキャッシュ属性の使用」を参照してください。

IORMプランでPMEMキャッシュ属性を使用して、永続メモリー(PMEM)キャッシュの領域割当てを保証できます。

IORMでは、PMEMキャッシュ属性を使用することで、重要なデータベース用の領域を確保しながら、重要性の低いエンティティや不正なエンティティによってPMEMキャッシュ全体が使用されないようにすることができます。これらの属性は、データベース間プランでのみ指定でき、CellCLIユーティリティを使用して構成されます。

次の属性を使用して、PMEMキャッシュ・リソースの制限を設定できます。強い制限は、メモリー・キャッシュがフルでない場合でも、データベースがその割当て制限を超過できないことを意味します。弱い制限は、使用可能なリソースがある場合に、指定された制限を超過できることを意味します。

  • pmemCacheMin — ブロックがコールド状態であっても指定されたデータベースに対して保証される、PMEMキャッシュ領域の最小容量を指定します。これは強い制限です。

    pmemCacheMinは保証付き予約であるため、すべてのディレクティブのpmemCacheMinの合計は、各データベースがそれぞれの割当てを取得するように、PMEMキャッシュのサイズより小さくする必要があります。

  • pmemCacheLimit — データベースで使用できるPMEMキャッシュ領域の弱い最大容量を指定します。PMEMキャッシュがフルでない場合、データベースはpmemCacheLimit値を超過できます。

  • pmemCacheSize — データベースで使用できるPMEMキャッシュ領域の強い最大容量を指定します。pmemCacheSize値を超えることはできません。

    ただし、pmemCacheSizeを、データベースが使用している現在の領域よりも小さい値に設定した場合、Oracle Exadata System Softwareリリース20.1.0以降では、超過分のデータがキャッシュから事前に消去されます。以前は、別のデータによって上書きされた場合のみ、超過分のデータが削除されていました。

    すべてのディレクティブでpmemCacheSizeの合計がPMEMキャッシュのサイズより大きい場合、pmemCacheSizeは保証された予約ではありません。この場合、pmemCacheMinを指定して、保証付きの最小割当て制限を定義することもできます。

例5-13 PMEMキャッシュ属性を使用したデータベース間プランの構成

この例は、pmemキャッシュ属性を使用してデータベース間プランを作成する方法を示しています。この例では、salesデータベースとtestデータベースでpmemCacheSizeパラメータを使用することにより、PMEMキャッシュの領域容量が保証されます。ただし、PMEMキャッシュに空き領域がある場合でも、データベースは指定した割当てを超過できません。

fincデータベースおよびdevデータベースは、pmemCacheMinを使用することにより最小割当て制限が保証されます。また、これらのデータベースは、PMEMキャッシュに空き領域がある場合は、指定したpmemCacheLimitサイズを超過することもできます。

このプランの例には、様々なフラッシュ・キャッシュ属性も含まれています。

ALTER IORMPLAN dbplan=                                            -
((name=sales, share=8, pmemCacheSize= 2G, flashCacheSize=10G), -
(name=finc, share=8, pmemCacheMin= 1G, pmemCacheLimit= 2G, flashCacheLimit=10G, flashCacheMin=2G), -
(name=dev, share=2, pmemCacheMin= 500M, pmemCacheLimit= 1G, flashCacheLimit=4G, flashCacheMin=1G), -
(name=test, share=1, limit=10, pmemCacheSize= 200M))

親トピック: IORMプランの管理

5.2.3.11 role属性の使用

role属性により、データベースにOracle Data Guard primaryまたはstandbyロールがあるかどうかに基づいて、異なる割当てを指定できます。

デフォルトでは、データベースがいずれかのroleの場合に、データベース間プランのディレクティブが適用されます。データベースがprimaryロールの場合にのみディレクティブを適用する場合は、role=primaryを含めます。同様に、データベースがstandbyロールの場合にのみディレクティブを適用する場合は、role=standbyを含めます。

たとえば:

ALTER IORMPLAN                                          -
dbPlan=((name=prod, share=8, role=primary),             -
        (name=prod, share=1, limit=25, role=standby)    -
        (name=default, share=2))
5.2.3.12 asmcluster属性の使用

asmcluster属性を使用すると、同じDB_UNIQUE_NAMEを持つデータベースを一意に識別できます。

同じDB_UNIQUE_NAMEを持っているが、異なるOracle ASMクラスタに関連付けられているデータベースがある場合、Oracle Exadata System Softwareリリース19.1.0以降では、asmcluster属性を使用すると、データベースを一意に識別できます。

データベースは異なるOracle ASMクラスタのクライアントである必要があり、クラスタの識別を容易にするためにASMを有効範囲にしたセキュリティを構成する必要があります。

たとえば:

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))
5.2.3.13 IORMプランのデフォルト値へのリセット

IORMプランをリセットするには、空の文字列を使用します。

IORMプラン全体をリセットしたり、catplan、dbplanまたはclusterplanを個別にリセットしたりすることもできます。たとえば: 

CellCLI> ALTER IORMPLAN catplan="", dbplan="", clusterplan=""
CellCLI> ALTER IORMPLAN catplan=""
CellCLI> ALTER IORMPLAN dbplan=""
CellCLI> ALTER IORMPLAN clusterplan=""

親トピック: IORMプランの管理

5.2.4 I/Oリソース管理プランの表示

ストレージ・サーバー上のCellCLI LIST IORMPLANコマンドを使用して、ストレージ・サーバーの現在のデータベース間プランを表示できます。

例5-14 データベース間プランの詳細の表示

この例は、データベース間プラン属性の詳細なリストを取得する方法を示しています。

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の管理

5.2.5 データベースおよびPDBのためのフラッシュ・キャッシュ割当て制限の管理

IORMにより、異なるデータベースとプラガブル・データベース(PDB)の間でフラッシュ・キャッシュをどのように共有するかを制御できます。

これは、CDBリソース・プランのみ、またはI/Oリソース管理(IORM)データベース間プランと組み合せて使用できます。

NEWCDB CDBのデータベース内リソース・プランの例を考えてみます。プランでは、プランに記載されている3つのPDB用にmemory_minおよびmemory_limitを指定します。

次の点に注意してください。

  • memory_minおよびmemory_limitの値は、0から100の範囲のパーセンテージで指定されます。オーバー・プロビジョニングがサポートされているため、パーセンテージの合計は100%には制限されません。これらの値の合計が100%を超える場合、値はパーセンテージへと正規化されます。
  • memory_minが指定されていない場合は、デフォルトで0に設定されます。
  • memory_limitが指定されていない場合は、デフォルトで100に設定されます。
  • CDB$ROOT用には、5%のmemory_limit値があります。

次のコードは、データベース内プランの例を作成する方法を示しています。memory_min値の合計は40%で、memory_limit値の合計は正規化する必要のある175%です。データベース間プランが指定されていない場合、これらのパーセンテージがフラッシュ・キャッシュのサイズ全体に適用されます。データベース間プランが指定されている場合、PDBの割当て制限は、データベース間プランのディレクティブで指定されたデータベース用のflashcacheminとflashcachesize値のパーセンテージとして計算されます。 

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;
/

前述の例で、データベース間プランを指定せず、フラッシュ・キャッシュのサイズが50GBの場合の、(memory_limitの値の合計が100%を超えたために)制限を正規化した後の割当て制限の内訳を次の表に示します。正規化後、最小値が対応する制限より大きくなった場合は、最小値は制限と等しくなるように減らされます。

表5-4 ケース1: データベース間プランがない場合のPDBのフラッシュ・キャッシュの制限

PDB フラッシュ・キャッシュの最小 FCの弱い制限 正規化済の弱い制限 FCの強い制限

SALESPDB

20% = 10 GB

100 (デフォルト)

100 / 175 * 50 GB = 28.57 GB

該当なし

SERVICESPDB

20% = 10 GB

50

50 / 175 * 50 GB = 14.28 GB

該当なし

HRPDB

0

25

25 / 175 * 50 GB = 7.14 GB

該当なし

次の例に、NEWCDB CDBを含むフラッシュ・キャッシュ割当て制限のあるデータベース間プランを示します。 

ALTER IORMPLAN dbplan=                                                                                       -
      ((name=newcdb, share=8, flashCacheSize=20G),                                        -
       (name=finance, share=8, flashCacheLimit=10G, flashCacheMin=2G), -
       (name=dev, share=2, flashCacheLimit=4G, flashCacheMin=1G),    -
       (name=test, share=1))

newcdb CDBに加え、その他の3つのデータベース(finance、devおよびtest)で同じストレージ・サーバーを共有します。フラッシュ・キャッシュの割当て制限が強制されるのは、ディレクティブでflashcachesize、flashcachelimitまたはflashcachemin属性を指定する場合のみです。データベースtestにはフラッシュ・キャッシュのディレクティブが指定されていません。したがって、そのデータベースおよびそのPDB (もしあれば)では、フラッシュ・キャッシュの割当て制限は管理されません。

データベース間IORMプラン・ディレクティブのキャッシュ制限は、対応するCDBプランの設定を制約します。したがって、データベース間IORMプラン・ディレクティブでデータベースのflashcacheminおよびflashcachesize設定が指定されている場合、CDBプランでPDB固有のmemory_min割当て制限はflashcachemin設定の一部になり、PDB固有のmemory_limit値はflashcachesizeの一部になります。

ただし、データベース間IORMプラン・ディレクティブでflashcacheminを指定せずにflashcachesizeが指定されている場合、PDB固有のmemory_min設定は無視されますが、memory_limit設定は引き続きflashcachesizeの一部になります。

したがって、newcdbのデータベース間IORMプラン・ディレクティブの例では、flashcacheminなしでflashcachesizeが指定されているため、CDBプランでPDB固有のmemory_min割当て制限が無視されます。次の表に、CDBプランの例をデータベース間IORMプランの例とともに適用した場合に有効なフラッシュ・キャッシュ制限を示します。

表5-5 ケース2: データベース間プランがある場合のPDBのフラッシュ・キャッシュの制限

PDB フラッシュ・キャッシュの最小 FCの強い制限 正規化済の強い制限 FCの弱い制限

SALESPDB

0

100 (デフォルト)

100 / 175 * 20 GB = 11.43 GB

該当なし

SERVICESPDB

0

50

50 / 175 * 20 GB = 5.71 GB

該当なし

HRPDB

0

25

25 / 175 * 20 GB = 2.86 GB

該当なし

非CDBデータベースでは、flashcachesize、flashcacheminおよびflashcachelimitの値は絶対的な値として指定され、追加の正規化は必要ありません。flashcacheminは保証付きの予約であるため、flashcacheminの合計は、すべてのディレクティブ全体でフラッシュ・キャッシュの合計サイズより小さくする必要があります。

親トピック: IORMの管理

5.2.6 データベースおよびPDBのためのXRMEMキャッシュ割当て制限の管理

I/Oリソース管理(IORM)により、異なるデータベースとプラガブル・データベース(PDB)の間でExadata RDMAメモリー・キャッシュ(XRMEMキャッシュ)をどのように共有するかを制御できます。

これは、CDBリソース・プランのみ、またはI/Oリソース管理(IORM)データベース間プランと組み合せて使用できます。

NEWCDB CDBのデータベース内リソース・プランの例を考えてみます。プランでは、プランに記載されている3つのPDB用にmemory_minおよびmemory_limitを指定します。

次の点に注意してください。

  • memory_minおよびmemory_limitの値は、0から100の範囲のパーセンテージで指定されます。オーバー・プロビジョニングがサポートされているため、パーセンテージの合計は100%には制限されません。これらの値の合計が100%を超える場合、値はパーセンテージへと正規化されます。
  • memory_minが指定されていない場合は、デフォルトで0に設定されます。
  • memory_limitが指定されていない場合は、デフォルトで100に設定されます。
  • CDB$ROOT用には、5%のmemory_limit値があります。

次のコードは、データベース内プランの例を作成する方法を示しています。memory_min値の合計は40%で、memory_limit値の合計は正規化する必要のある175%です。データベース間プランが指定されていない場合、これらのパーセンテージがXRMEMキャッシュのサイズ全体に適用されます。データベース間プランが指定されている場合、PDBの割当て制限は、データベース間プランのディレクティブで指定されたデータベース用のxrmemcacheminとxrmemcachesize値のパーセンテージとして計算されます。 

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;
/

前述の例で、データベース間プランを指定せず、XRMEMキャッシュのサイズが1.25 TBの場合の、(memory_limitの値の合計が100%を超えたために)制限を正規化した後の割当て制限の内訳を次の表に示します。正規化後、最小値が対応する制限より大きくなった場合は、最小値は制限と等しくなるように減らされます。

表5-6 ケース1: データベース間プランがない場合のPDBのXRMEMキャッシュの制限

PDB XRMEMキャッシュの最小 XRMEMの弱い制限 正規化済の弱い制限 XRMEMの強い制限

SALESPDB

20% = 256 GB

100 (デフォルト)

100 / 175 * 1.25 TB = 731 GB

該当なし

SERVICESPDB

20% = 256 GB

50

50 / 175 * 1.25 TB = 366 GB

該当なし

HRPDB

0

25

25 / 175 * 1.25 TB = 183 GB

該当なし

次の例に、NEWCDB CDBを含むXRMEMキャッシュ割当て制限のあるデータベース間プランを示します。 

ALTER IORMPLAN dbplan=                                                                                       -
      ((name=newcdb, share=8, xrmemCacheSize= 200G, flashCacheSize=10G),                                        -
       (name=finance, share=8, xrmemCacheMin= 100G, xrmemCacheLimit= 200G, flashCacheLimit=10G, flashCacheMin=2G), -
       (name=dev, share=2, xrmemCacheMin= 1G, xrmemCacheLimit= 10G, flashCacheLimit=4G, flashCacheMin=1G),    -
       (name=test, share=1))

newcdb CDBに加え、その他の3つのデータベース(finance、devおよびtest)で同じストレージ・サーバーを共有します。XRMEMキャッシュ割当て制限は、ディレクティブでxrmemcachesize、xrmemcachelimitまたはxrmemcachemin属性が指定されている場合にのみ適用されます。データベースtestにはXRMEMキャッシュのディレクティブが指定されていません。したがって、そのデータベースおよびそのPDB (ある場合)では、XRMEMキャッシュの割当て制限は管理されません。

データベース間IORMプラン・ディレクティブのキャッシュ制限は、対応するCDBプランの設定を制約します。したがって、データベース間IORMプラン・ディレクティブでデータベースのxrmemcacheminおよびxrmemcachesize設定が指定されている場合、CDBプランでPDB固有のmemory_min割当て制限はxrmemcachemin設定の一部になり、PDB固有のmemory_limit値はxrmemcachesizeの一部になります。

ただし、データベース間IORMプラン・ディレクティブでxrmemcacheminを指定せずにxrmemcachesizeが指定されている場合、PDB固有のmemory_min設定は無視されますが、memory_limit設定は引き続きxrmemcachesizeの一部になります。

したがって、newcdbのデータベース間IORMプラン・ディレクティブの例では、xrmemcacheminなしでxrmemcachesizeが指定されているため、CDBプランでPDB固有のmemory_min割当て制限が無視されます。次の表に、CDBプランの例をデータベース間IORMプランの例とともに適用した場合の有効なXRMEMキャッシュ制限を示します。

表5-7 ケース2: データベース間プランがある場合のPDBのXRMEMキャッシュの制限

PDB XRMEMキャッシュの最小 XRMEMの強い制限 正規化済の強い制限 XRMEMの弱い制限

SALESPDB

0

100 (デフォルト)

100 / 175 * 200 GB = 114.29 GB

該当なし

SERVICESPDB

0

50

50 / 175 * 200 GB = 57.14 GB

該当なし

HRPDB

0

25

25 / 175 * 200 GB = 28.57 GB

該当なし

非CDBデータベースでは、xrmemcachesize、xrmemcacheminおよびxrmemcachelimitの値は絶対値として指定され、追加の正規化は必要ありません。xrmemcacheminは保証付きの予約であるため、xrmemcacheminの合計は、すべてのディレクティブ全体でXRMEMキャッシュの合計サイズより小さくする必要があります。

親トピック: IORMの管理

5.2.7 データベースおよびPDBのためのPMEMキャッシュ割当て制限の管理

ノート:

このトピックは、23.1.0より前のOracle Exadata System Softwareリリースにのみ適用されます。それ以外の場合は、「データベースおよびPDBのXRMEMキャッシュ割当ての管理」を参照してください。

I/Oリソース管理(IORM)により、異なるデータベースとプラガブル・データベース(PDB)の間でPMEMキャッシュをどのように共有するかを制御できます。

これは、CDBリソース・プランのみ、またはI/Oリソース管理(IORM)データベース間プランと組み合せて使用できます。

NEWCDB CDBのデータベース内リソース・プランの例を考えてみます。プランでは、プランに記載されている3つのPDB用にmemory_minおよびmemory_limitを指定します。

次の点に注意してください。

  • memory_minおよびmemory_limitの値は、0から100の範囲のパーセンテージで指定されます。オーバー・プロビジョニングがサポートされているため、パーセンテージの合計は100%には制限されません。これらの値の合計が100%を超える場合、値はパーセンテージへと正規化されます。
  • memory_minが指定されていない場合は、デフォルトで0に設定されます。
  • memory_limitが指定されていない場合は、デフォルトで100に設定されます。
  • CDB$ROOT用には、5%のmemory_limit値があります。

次のコードは、データベース内プランの例を作成する方法を示しています。memory_min値の合計は40%で、memory_limit値の合計は正規化する必要のある175%です。データベース間プランが指定されていない場合、これらのパーセンテージがPMEMキャッシュのサイズ全体に適用されます。データベース間プランが指定されている場合、PDBの割当て制限は、データベース間プランのディレクティブで指定されたデータベース用のpmemcacheminとpmemcachesize値のパーセンテージとして計算されます。 

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;
/

前述の例で、データベース間プランを指定せず、PMEMキャッシュのサイズが10 GBの場合の、(memory_limitの値の合計が100%を超えたために)制限を正規化した後の割当て制限の内訳を次の表に示します。正規化後、最小値が対応する制限より大きくなった場合は、最小値は制限と等しくなるように減らされます。

表5-8 ケース1: データベース間プランがない場合のPDBのPMEMキャッシュの制限

PDB PMEMキャッシュの最小 PMEMの弱い制限 正規化済の弱い制限 PMEMの強い制限

SALESPDB

20% = 2 GB

100 (デフォルト)

100 / 175 * 10 GB = 5.71 GB

該当なし

SERVICESPDB

20% = 2 GB

50

50 / 175 * 10 GB = 2.85 GB

該当なし

HRPDB

0

25

25 / 175 * 10 GB = 1.42 GB

該当なし

次の例に、NEWCDB CDBを含むPMEMキャッシュ割当て制限のあるデータベース間プランを示します。 

ALTER IORMPLAN dbplan=                                                                                       -
      ((name=newcdb, share=8, pmemCacheSize= 2G, flashCacheSize=10G),                                        -
       (name=finance, share=8, pmemCacheMin= 1G, pmemCacheLimit= 2G, flashCacheLimit=10G, flashCacheMin=2G), -
       (name=dev, share=2, pmemCacheMin= 100M, pmemCacheLimit= 1G, flashCacheLimit=4G, flashCacheMin=1G),    -
       (name=test, share=1))

newcdb CDBに加え、その他の3つのデータベース(finance、devおよびtest)で同じストレージ・サーバーを共有します。PMEMキャッシュの割当て制限が強制されるのは、ディレクティブでpmemcachesize、pmemcachelimitまたはpmemcachemin属性を指定した場合のみです。データベースtestにはPMEMキャッシュのディレクティブが指定されていません。したがって、そのデータベースおよびそのPDB (もしあれば)では、PMEMキャッシュの割当て制限は管理されません。

データベース間IORMプラン・ディレクティブのキャッシュ制限は、対応するCDBプランの設定を制約します。したがって、データベース間IORMプラン・ディレクティブでデータベースのpmemcacheminおよびpmemcachesize設定が指定されている場合、CDBプランでPDB固有のmemory_min割当て制限はpmemcachemin設定の一部になり、PDB固有のmemory_limit値はpmemcachesizeの一部になります。

ただし、データベース間IORMプラン・ディレクティブでpmemcacheminを指定せずにpmemcachesizeが指定されている場合、PDB固有のmemory_min設定は無視されますが、memory_limit設定は引き続きpmemcachesizeの一部になります。

したがって、newcdbのデータベース間IORMプラン・ディレクティブの例では、pmemcacheminなしでpmemcachesizeが指定されているため、CDBプランでPDB固有のmemory_min割当て制限が無視されます。次の表に、CDBプランの例をデータベース間IORMプランの例とともに適用した場合の有効なPMEMキャッシュ制限を示します。

表5-9 ケース2: データベース間プランがある場合のPDBのPMEMキャッシュの制限

PDB PMEMキャッシュの最小 PMEMの強い制限 正規化済の強い制限 PMEMの弱い制限

SALESPDB

0

100 (デフォルト)

100 / 175 * 2 GB = 1.14 GB

該当なし

SERVICESPDB

0

50

50 / 175 * 2 GB = 0.57 GB

該当なし

HRPDB

0

25

25 / 175 * 2 GB = 0.28 GB

該当なし

非CDBデータベースの場合、pmemcachesize、pmemcacheminおよびpmemcachelimitの値は絶対的な値として指定するため、追加の正規化は必要ありません。pmemcacheminは保証付きの予約であるため、pmemcacheminの合計は、すべてのディレクティブ全体でPMEMキャッシュの合計サイズより小さくする必要があります。

親トピック: IORMの管理

5.2.8 IORM profileの使用

I/Oリソース管理(IORM)のデータベース間プランでは、数百ものデータベースのデータベース間プランの管理と構成を容易にするため、profileがサポートされています。

profileにより、データベース・グループに対してI/Oリソースを割り当てる方法が導入されます。profileは、データベース間プランのディレクティブとして指定され、CellCLIユーティリティを使用して構成されます。profileディレクティブは、識別子(名前)と一連の属性で構成されています。データベース・ディレクティブとprofileディレクティブを区別するために、typeと呼ばれる修飾子属性が使用されます。type属性は、databaseまたはprofileに設定できます。次は、type属性の構文の例です。 

CellCLI> ALTER IORMPLAN DBPLAN=((name=gold, share=10, type=profile),  -
                                (name=silver, share=5, type=profile), -
                                (name=bronze, share=1, type=profile))

前述の例には、プロファイルの3つのディレクティブ(GOLD、SILVERおよびBRONZE)が含まれています。db_performance_profileがGOLDに設定されているデータベースはすべて、自動的にセルI/Oリソースの共有が10個になります。同様に、前述の例では、プロファイルがSILVERのデータベースは共有5つ、プロファイルがBRONZEのデータベースは共有1つになります。

profileを作成した後に、新規および既存のデータベースを、データベース間プランに定義されたprofileのいずれかにマップします。これを行うには、各データベースのdb_performance_profile初期化パラメータを必要なprofileの名前に設定します。その後、データベースを再起動する必要があります。Oracle Database Resource Managerプランと同様に、IORM profile情報はすべてのストレージ・サーバー(セル)に自動的にプッシュされます。次のSQLコマンドは、データベースに初期化パラメータを設定する方法を示しています。 

SQL> ALTER SYSTEM SET db_performance_profile=gold SCOPE=spfile;

SQL> SHUTDOWN IMMEDIATE

SQL> STARTUP

新しいデータベースを追加する場合、db_performance_profileパラメータを設定し、データベースを再起動します。データベース間プランを変更しなくても、データベースによってprofile属性が自動的に継承されます。また、profileディレクティブとデータベース・ディレクティブが混在するデータベース間プランを作成することもできます。

既存のprofileを表示するには、LIST IORMPROFILEコマンドを使用します。

データベース間profileプランを管理する場合、次の各事項に注意してください。

  • db_performance_profileパラメータは動的パラメータでないため、データベースの再起動時にはprofileを更新する必要があります。
  • type属性を指定しない場合、ディレクティブはdatabaseディレクティブにデフォルト設定されます。
  • データベース間プランで指定できるのは、8つのprofileディレクティブと1024のデータベース・ディレクティブのみです。
  • profileディレクティブでは、level、allocationおよびroleを指定することはできません。
  • OTHERとDEFAULTという単語は予約語です。profile名をOTHERまたはDEFAULTにすることはできません。
  • type属性は、カテゴリ・プランでは指定できません。
  • profileは、カテゴリ・プランととともに指定することはできません。
  • 複数のデータベースがOTHERディレクティブにマップされる場合、Oracle Exadata Storage Serverでは、それらのデータベースにOracle Database Resource Managerを使用しません。この場合は、すべてのI/Oリクエストが同等に処理されます。

関連項目

親トピック: IORMの管理

5.2.9 I/Oリソース管理の構成の確認

このチェックリストを使用して、I/Oリソース管理(IORM)が正しく構成されていることを確認します。

  • IORMを使用してデータベース内のI/Oリソースを管理する場合、次の基準が満たされていることを確認します。
    • リソース・プランが有効化されていること。
    • すべてのデータベース・インスタンスで同じリソース・プランが有効化されていること。
      • スケジューラ・ウィンドウを使用してOracle Database Resource Managerを有効化すると、すべてのデータベース・インスタンスで常に同じプランが有効化されます。
      • RESOURCE_MANAGER_PLANパラメータを使用してOracle Database Resource Managerを有効化する場合、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;

      次のコマンドを使用して、任意のセッションをコンシューマ・グループに切り替える権限を付与します。この例は、BATCH_GROUPに権限を付与する方法を示しています。 

      EXEC dbms_resource_manager_privs.grant_switch_consumer_group -
  ('public', 'BATCH_GROUP', FALSE);

    • アクティブではないコンシューマ・グループ: 現在のリソース・プランに含まれていないコンシューマ・グループにセッションがマップされるか、手動で切り替えられると、そのセッションはデフォルトのコンシューマ・グループである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;

      マップ済のコンシューマ・グループが元のコンシューマ・グループと異なる場合、マップ済のコンシューマ・グループはリソース・プランに含まれていなかったことになります。

  • 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コマンドでは、すべてのデータベースの各コンシューマ・グループで発行された大小のI/Oリクエストの数が表示されます。

    CellCLI> LIST METRICCURRENT CG_IO_RQ_LG, CG_IO_RQ_SM   ATTRIBUTES name, -
         metricObjectName, metricValue, collectionTime;
  • ワークロードを実行中は、各カテゴリ、データベース、およびコンシューマ・グループの実際の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;

    出力はデータベースからの大小のリクエストによって使用されるディスク・リソースのパーセントを示したものです。

関連項目

親トピック: IORMの管理