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

6 I/Oリソースの管理

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

データベース内のワークロードを管理するために、Oracle Database Resource ManagerがIORMと連動し、データベースのリソースを管理できます。

  • I/Oリソース管理(IORM)の理解
    IORMでは、ストレージ・サーバーのI/Oリソースをセル単位で管理します。I/Oリクエストによりセルの容量が飽和状態になり始めると、構成済のリソース・プランに従って、受信するI/OリクエストがIORMによってスケジュール調整されます。
  • コンシューマ・グループおよびリソース・プランについて
    Oracle Exadata Database Machineには、Oracle Exadata System Softwareを使用するデータ・ウェアハウス専用のデフォルトのコンシューマ・グループおよびリソース・プランが付属しています。
  • CDBプランおよびプラガブル・データベースについて
    コンテナ・データベース(CDB)では、リソースについて競合する複数のPDB内に、複数のワークロードが存在する場合があります。
  • IORMの管理
    I/Oリソース管理(IORM)に関連する様々な管理タスクを実行できます。

関連項目

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

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

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

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

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

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

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

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

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

6.1.1.1 IORMプラン

IORMでは、カテゴリ・プラン(catPlan)またはデータベース間プラン(dbPlan)を作成できます。

カテゴリ・リソース管理は拡張機能です。この機能は、Oracle Exadata Storage Serverが複数のデータベースをサポートしており、主に実行中の処理のカテゴリ別にリソースを割り当てる場合に有効です。たとえば、すべてのデータベースにOLTP、レポート、メンテナンスの3つのカテゴリのワークロードがあるとします。これらのワークロード・カテゴリに基づいてI/Oリソースを割り当てるには、カテゴリ・リソース管理を使用します。

データベース間のリソース管理では、複数のデータベースのリソースを管理できます。データベース間のリソース管理を構成する場合は、CellCLIユーティリティを使用してデータベース間のプランを作成します。データベース間のプランでは、データベースごとにリソース割当てを指定します。この機能は、Oracle Exadata Storage Serverリソースを使用しているデータベースが複数ある場合に使用してください。

データベース間のプランが構成されている場合は、各データベースでデータベース・プランとリソース割当てを設定できます。データベース・リソース・プランでは、ワークロード(コンシューマ・グループ)間でデータベースのリソース割当てをどのように振り分けるかを指定します。データベースでデータベース・リソース・プランを有効にしていない場合は、データベースのリソース割当ては振り分けられず、データベースのすべてのI/Oリソースが単一のワークロードとして処理されます。

6.1.1.2 データベースへのリソースの割当て方法

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

catPlanで、allocationを使用すると、各データベースまたはカテゴリのI/O分散の割合を指定できます。allocationでは、IORMで最大32のカテゴリまたはデータベースを管理できます。8つの異なるlevelでリソースを割り当てることができます。たとえば、バッチ操作を営業活動とは異なるlevelに配置できます。

dbPlanでは、allocationを使用するか、shareまたはlimitを使用してリソースを管理することもできます。

  • shareメソッドを使用して、データベースの相対優先度を指定します。share値が高いほど、優先度が高くなり、I/Oリソースの保証が強化されます。dbPlanには、このメソッドをお薦めします。

  • limitメソッドを使用して、データベースのI/O使用率を指定した使用率制限に制限します。このディレクティブにより、指定した制限を超えるI/Oリソースがデータベースで利用されないことが保証されます。たとえば、本番とテスト環境用のデータベースがOracle Exadata Storage Serverリソースを共有している場合、テスト用データベースの最大使用率制限を設定し、テスト用データベースのI/O使用率を制限できます。

    最大使用率制限が指定されている場合、データベースが過剰な容量を使用することはありません。そのため、最大使用率制限を指定すると、ディスクをフル容量未満で実行できます。

    limitに1から100の値を使用して、データベースの最大ディスクI/O使用率制限を指定します。この構成は、パフォーマンス・ベース課金の使用ケースに理想的であり、公平性を実現するためには使用できません。

    ハード・ディスクに発行されたI/Oは最大使用率制限の対象ではありませんが、フラッシュ・デバイス上のI/Oは対象になります。これは、ほとんどすべてのI/OがExadataスマート・フラッシュ・キャッシュによって提供されるためです。フラッシュ・デバイスでのみ最大使用率制限を強制することで、キャッシュ・ミスや移入I/Oなど、フラッシュ・キャッシュを失わないI/Oの低使用率制限が原因で、長い待機時間と外れ値が回避されます。

6.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を使用して作成されます。これには、各コンシューマ・グループに対するリソース割当てディレクティブが含まれており、割合とレベルで構成されています。最大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です。

関連項目

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

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

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

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

関連項目

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

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

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

たとえば、データベースSALESにI/Oリソースの70%、HRに30%が割り当てられるように指定し、未使用の割当てがTEST_SALESデータベースに再割当てされるように指定するとします。データベース間のプランは、各ディレクティブがallocationとlevel(1から8)で構成される点でデータベース・リソース・プランと同じです。各プランでは、任意のレベルの割当ての合計を100%以下にする必要があります。データベース間のプランとデータベース・リソース・プランの異なる点は、データベース間のプランにはサブプランを含めることができず、I/Oリソースのディレクティブしか含めることができないことです。所定の時間で1つのセルで有効にできるデータベース間プランの数は1つのみです。

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

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

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

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

shareベースのプランでは、DEFAULTディレクティブを使用して、プランで名前が明示的に指定されていないデータベース用の様々なIORM属性のデフォルト値を指定します。デフォルトのshareは1で、上限は100%に設定されます。Exadataスマート・フラッシュ・キャッシュおよびExadataスマート・フラッシュ・ログはデフォルトで有効になっており、フラッシュ・キャッシュの割当て制限の最小または最大のデフォルトの設定はありません。

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

ノート:

Oracle Data Guardデプロイメントの場合のみ、I/Oリソース管理(IORM)では、ディレクティブにrole属性も指定されている場合を除き、db_nameを使用したディレクティブの指定はサポートされません。
6.1.3.2 統合と分離でのデータベース間のプランの使用

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

同じOracle Exadata Storage Serverにある4つの異なるアプリケーションを統合する場合を検討します。すべてのアプリケーションが同じような優先度要件の場合は、IORMを使用してI/Oリソースの25%を均等に割り当てることができます。1つのアプリケーションが他のアプリケーションよりも重要な場合、IORMを使用して、より高い割合のI/Oリソースを与えることができます。

最大使用率制限は、このような統合シナリオの場合にも便利です。あるアプリケーションの使用率がワークロードで突然上昇する場合は、各アプリケーションを分離できます。最大使用率制限を使用してアプリケーションを分離し、たとえば、各アプリケーションに40%の最大使用率制限を指定します。このようなシナリオの場合、各アプリケーションはI/Oリソースの最大40%を使用することができ、システムを完全に占有することはありません。

最大使用率の制限が意味を持つ別の状況は、パフォーマンス・ベース課金モデルを保証する場合です。サービス・プロバイダは、購入されたサービスのレベルに応じて顧客に対するパフォーマンスを保証することを求めています。ゴールド層のサービスを購入していない顧客は、ゴールド・レベルのパフォーマンスを享受できないようにする必要があります。IORMリソース・プランを使用すると、パフォーマンス・モデルに基づいて顧客アプリケーション間でI/Oリソースを配分できます。フラッシュ・キャッシュの最小および最大の割当て制限は、このモデルでも役に立ちます。

6.1.3.3 データベース間のプランでのフラッシュ・キャッシュ管理について

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

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

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

  • 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の最小割当て制限および最大割当て制限を管理できます。

6.1.3.4 データベース間のプランでのPMEMキャッシュ管理について

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

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

dbPlanで属性を使用して、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の最小割当て制限および最大割当て制限を管理できます。

6.1.3.5 IORMを使用したフラッシュ・リソースおよびPMEMリソースへのデータベース・アクセスの制御

IORMを使用して、重要なフラッシュ・メモリー・リソースおよび永続メモリー(PMEM)リソースへのアクセスを管理できます。

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

同様に、データベース間のIORMプランでpmemcacheディレクティブおよびpmemlogディレクティブを使用して、PMEMキャッシュおよびPMEMログへのアクセスを制御できます。

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

6.1.3.6 リソース・プランの管理のヒント

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

  • Oracle Exadata Database Machineが1つのデータベースのみをホストする場合、データベース間プランは不要です。
  • データベース間のプランが指定されていない場合は、すべてのデータベースで割当てが同じになります。
  • OTHERディレクティブにマップされるデータベースが1つしかなく、他のすべてのデータベースに明示的なディレクティブがある場合、Oracle Exadata System Softwareでは、そのデータベースのデータベース・リソース・プランを使用して、そのデータベースのコンシューマ・グループ間でOTHERデータベースのallocationをどのように再配分するかを決定します。
  • 複数のデータベースがOTHERディレクティブにマップされる場合、Oracle Exadata System Softwareでは、それらのデータベースにOracle Database Resource Managerを使用しません。この場合は、すべてのI/Oリクエストが同等に処理されます。
  • shareベースのプランでは、プランで明示的に名前が指定されていない場合でも、各データベースがで独自のディレクティブを取得します。Oracle Exadata System Softwareでは、データベースのデータベース・リソース・プランを使用して、データベースのコンシューマ・グループ間で割当てをどのように配分するかを決定します。
  • 同じDB_UNIQUE_NAMEを持っているが、異なるOracle ASMクラスタに関連付けられているデータベースがある場合、Oracle Exadata System Softwareリリース19.1.0以降では、asmcluster属性を使用すると、ディレクティブの指定時に各データベースを一意に識別できます。
  • コンテナ・データベース(CDB)プランでmemory_minまたはmemory_limitが指定され、データベース間プランでflashcachesizeのみが指定されている場合、CDBプランのmemory_minは無視されます。
  • コンテナ・データベース(CDB)プランでmemory_minまたはmemory_limitが指定され、データベース間プランでpmemcachesizeのみが指定されている場合、CDBプランのmemory_minは無視されます。

6.1.4 I/Oリソース管理プロファイルについて

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

プロファイルにより、データベース・グループに対してI/Oリソースを割り当てる方法が導入されます。プロファイルは、データベース間プランのディレクティブとして指定され、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のshare、および100%のlimitを取得します。同様に、前述の例では、SILVERプロファイルを持つデータベースは5つのshareと60%のlimitを取得し、BRONZEプロファイルを持つデータベースは1つのshareと20%のlimitを取得します。

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

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

SQL> SHUTDOWN IMMEDIATE

SQL> STARTUP

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

既存のプロファイルを表示するには、LIST IORMPROFILEコマンドを使用します。

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

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

関連項目

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

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

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

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

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

カテゴリ・プランを有効にすると、カテゴリ・プランが最初に使用され、カテゴリ間でリソースが割り当てられます。選択したカテゴリごとにデータベース間のプランが使用され、選択したカテゴリのコンシューマ・グループを持つデータベースが選択されます。最後に、選択したデータベース・リソース・プランが使用され、コンシューマ・グループの1つが選択されます。

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

表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のカテゴリにマップしてください。

関連項目

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

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

Oracle Exadata Database Machineには、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リソースの管理

6.2.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.2.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.3 CDBプランおよびプラガブル・データベースについて

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

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

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

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

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

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

SALES

3

無制限

20

未設定

SERVICES

3

無制限

20

未設定

HR

1

70

未設定

50

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

6.4 IORMの管理

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

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

関連項目

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

6.4.1 レイテンシに優先順位を付けるためのIORMの有効化

I/Oリソース管理(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リソースに優先順位を付けます。

  1. データベースでデータベース・リソース・プランが設定されている場合に、IORMがディスクI/Oを管理します。

  2. データベース間のプランまたはカテゴリ・プランが構成されている場合に、IORMがディスクI/Oを管理します。

I/Oの優先順位付けおよびスロットルを非アクティブ化するには、IORMのobjectiveの設定をbasicに戻します。

フラッシュIORMの動作は、Exadata Extreme Flashストレージ・サーバーを除き、IORMのobjectiveの変更では制御できません。フラッシュIORMは、OLTPの待機時間を保護するように設計されており、クリティカルなI/Oを保護する際にobjectiveを考慮に入れることはありません。

Exadata Extreme Flashストレージでは、IORMのobjectiveによりフラッシュIORMの挙動をある程度制御できます。デフォルトのobjectiveはbasicです。objectiveの値のautoとbalancedは、同じ動作になります。スキャンのスループットの低下度合いがあまりに高いと考えられる場合は、objectiveを、クリティカルなI/O待機時間を犠牲にしてスキャンのスループットを向上させるhigh_throughputに変更できます。クリティカルI/Oの待機時間は非常に良好だが、両方のワークロードを同時に実行するときにスキャンのスループットが大幅に劣化する、という場合には、objectiveをlow_latencyに変更することもできます。

親トピック: IORMの管理

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

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

親トピック: IORMの管理

6.4.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.4.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.4.2.3 CDBプランの作成

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

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

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

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

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

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

6.4.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.4.2.7 データのインポート管理

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

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

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

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

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

  • リソース・プランに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;
/

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

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

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

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

6.4.3 データベース間のリソース管理の管理

CellCLIのALTER IORMPLANコマンドを使用すると、Oracle Exadata Database Machineのデータベース間プランまたはカテゴリ・プランを構成できます。

親トピック: IORMの管理

6.4.3.1 データベース間プランまたはカテゴリ・プランの作成方法

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値の割合として計算されます。memory_minおよびmemory_limitもPMEMキャッシュに適用され、データベースのpmemcacheminおよびpmemcachelimitまたはpmemcachesizeの値の割合として、あるいは何も指定されていない場合はPMEMキャッシュ・サイズの合計として計算されます。

6.4.3.2データベース間プランまたはカテゴリ・プランに必要な設定

各カテゴリまたはデータベース間プランには、必要な設定が含まれています。

データベース間のプランのディレクティブが有効であるためには、levelおよびallocation、share、最大使用率制限、またはフラッシュ・キャッシュ割当て制限ディレクティブを指定する必要があります。allocation、shareまたは最大使用率制限を指定していないディレクティブは無効です。allocationとshareの両方を指定するディレクティブも無効です。

catPlanまたはdbPlanを指定する場合は、ディレクティブでname=otherを指定する必要があります。カテゴリ・プランの場合は、カテゴリがカテゴリ・プランで指定されていないアクティブなすべてのコンシューマ・グループの割当てがotherディレクティブで指定されます。データベース間のプランでは、Oracle Exadata System Softwareを使用しているがデータベース間のプランで明示的に指定されていないすべてのデータベースの割当てがotherディレクティブで指定されます。otherディレクティブが指定されていない場合は、CellCLIユーティリティによってエラーが返されます。

  • allocationを使用したリソースの指定
    データベース間プランを指定することにより、4つの例のデータベースのI/Oリクエストに優先度を設定できます。
  • shareを使用したリソースの指定
    データベース間プランで各データベースに共有を割り当てることにより、4つの例のデータベースのI/Oリクエストに優先順位を付けることができます。

親トピック: データベース間のリソース管理の管理

6.4.3.2.1 allocationを使用したリソースの指定

データベース間プランを指定することにより、4つの例のデータベースのI/Oリクエストに優先度を設定できます。

同じストレージを共有する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データベースのパフォーマンスが影響を受ける可能性があります。

データベース間プランには次の特性があります。

  • OLTPデータベースのPRODには、高い優先度レベルでI/Oリソースの80%をallocationします。
  • DWデータベースには、残りのI/Oリソースの20%とPRODデータベースの未使用の割当ての80%をallocationします。

  • PROD_TESTおよびPROD_DEVデータベースとOTHERコンシューマ・グループには、未使用のI/Oの50%、40%、10%をそれぞれallocationします。

このデータベース間のプランの例を次の表に示します。

表6-4 allocationを使用したデータベース間プラン

データベース名 level1 (%) level2 (%) level3 (%)

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-10 allocationの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-11 allocationを使用したデータベース間プランの構成

この例は、allocationの割合を使用してセルのデータベース間プランを構成する方法を示しています。

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.4.3.2.2 shareを使用したリソースの指定

データベース間プランで各データベースにshareを割り当てることにより、4つの例のデータベースのI/Oリクエストに優先順位を付けることができます。

同じストレージを共有する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データベースのパフォーマンスが影響を受ける可能性があります。

OLTPデータベースのPRODは最も重要であるため、PRODデータベースには16のshareを指定できます。DWデータベースでは4つのshare、PROD_TESTでは2つのshare、PROD_DEVでは1つのshareを取得します。このプランでは、PRODデータベースのI/O発行の可能性がDWデータベースの4倍になります。

発行するI/OがPRODにない場合は、shareに基づいて他のデータベースが使用されます。

例6-12 shareのALTER IORMPLAN構文

この例は、各データベースにshareを割り当ててデータベース間プランを作成するコマンドを示しています。

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

例6-13 shareを使用したデータベース間プランの構成

この例は、shareを使用してセルのデータベース間プランを構成する方法を示しています。

ALTER IORMPLAN                                                 -
     dbPlan=(                                                  -
        (name=dev01, share=1, limit=50, flashLog=off),         -
        (name=dev02, share=1, limit=25, flashCache=off)        -
        (name=other, share=4))
6.4.3.3データベース間プランまたはカテゴリ・プランのオプション設定

必要なディレクティブを指定した後、プランをカスタマイズするための追加ディレクティブを含めることができます。

データベース間のプランを構成する場合、catPlanおよびdbPlanはオプションです。catPlanが指定されていない場合、カテゴリ間のIORMは有効になりません。同様に、dbPlanが指定されていない場合、データベース間のIORMは有効になりません。

次のオプションのディレクティブがあります。

  • IORMプランのrole属性
    role属性により、データベースにOracle Data Guard primaryまたはstandbyロールがあるかどうかに基づいて、異なる割当てを指定できます。
  • IORMプランのasmcluster属性
    asmcluster属性を使用すると、同じDB_UNIQUE_NAMEを持つデータベースを一意に識別できます。

親トピック: データベース間のリソース管理の管理

6.4.3.3.1 IORMプランのrole属性

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

デフォルトでは、データベースがいずれかのロールの場合に、データベース間プランのすべての割当てが適用されます。データベースが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))
6.4.3.3.2 IORMプランの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))

6.4.4 IORMプランでのフラッシュ・キャッシュ属性の使用

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

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

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

  • 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を指定して、保証付きの最小割当て制限を定義することもできます。

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

この例は、フラッシュ・キャッシュ属性を使用してデータベース間プランを作成する方法を示しています。この例では、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))

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

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

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

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

これは、CDBリソース・プランのみ、またはCDBプランとI/Oリソース管理(IORM)データベース間プランの両方を使用して行うことができます。

プランに記載されている3つのPDB用にmemory_minおよびmemory_limitを指定するCDBリソース・プランを考えてみてください。次の点に注意してください。

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

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

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

前述の例で、データベース間プランを指定せず、フラッシュ・キャッシュのサイズが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で、PMEMキャッシュ・サイズが10GBのシステムで実行されているデータベース間プランを示しています。

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,  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の合計は、すべてのディレクティブ全体でフラッシュ・キャッシュの合計サイズより小さくする必要があります。

親トピック: IORMの管理

6.4.6 IORMプランでのPMEMキャッシュ属性の使用

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

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

dbPlanで次の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を指定して、保証付きの最小割当て制限を定義することもできます。

例6-16 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の管理

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

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

プランに記載されている3つのPDB用にmemory_minおよびmemory_limitを指定するCDBリソース・プランを考えてみてください。次の点に注意してください。

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

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

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キャッシュのサイズが10GBの場合の、memory_limitの値の合計が100%を超えた制限を正規化した後の割当て制限の内訳を次の表に示します。最小値がこの制限よりも大きくなった場合は、最小値を減らしてこの制限と等しくします。

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

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

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およびPMEMキャッシュ・サイズが10GBのシステムでは、次のようなデータベース間プランを検討してください。

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,  limit=10))

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

CDBにpmemcachesizeが指定されている場合は、CDBリソース・プランのmemory_minの値は無視され、memory_limitの値が正規化されて、それぞれのPDBのPMEMキャッシュ・サイズの計算に使用されます。newcdb CDBにはpmemcachesizeが指定されているため、memory_minの値は無視されます。pmemcachesizeは、前述のようにmemory_limit値を正規化した後に計算されます。唯一の違いは、CDBにはpmemcachesizeディレクティブが指定されているため、これが強い制限になることです。

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

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

SALESPDB

0

100 (デフォルト)

100 / 175 = 1.14 GB

該当なし

SERVICESPDB

0

50

50 / 175 = 0.57 GB

該当なし

HRPDB

0

25

25 / 175 = 0.28 GB

該当なし

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

親トピック: IORMの管理

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

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

データベース間の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の管理

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

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

データベース間のIORMプランで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の管理

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

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

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

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

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

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

6.4.12 データベース間プランのデフォルト値へのリセット

データベース間のプランの属性をデフォルト値にリセットするには、属性を空の文字列に設定します。

プラン全体をリセットしたり、catPlanまたはdbPlanを個別にリセットしたりすることもできます。 

CellCLI> ALTER IORMPLAN dbPlan="", catPlan=""
CellCLI> ALTER IORMPLAN dbPlan=""
CellCLI> ALTER IORMPLAN catPlan=""

親トピック: IORMの管理