6 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)に関連する様々な管理タスクを実行できます。
6.1 I/Oリソース管理(IORM)の理解
IORMは、ストレージ・サーバーのI/Oリソースをセルごとに管理します。I/Oリクエストによりセルの容量が飽和状態になり始めると、構成済のリソース・プランに従って、受信するI/OリクエストがIORMによってスケジュール調整されます。
- Exadata Database MachineのI/Oリソース管理(IORM)について
IORMには、リソース割当てを管理するための様々な機能が用意されています。各機能は個別に使用できますが、他の機能と組み合せて使用することもできます。 - データベース内のデータベース・リソース管理について
Oracle Database Resource Managerでは、データベース内のワークロードを管理できます。 - データベース間のリソース管理について
データベース間のリソース管理では、同じ共有ストレージを使用して複数のデータベースのリソースを管理できます。 - クラスタのリソース管理について
クラスタのリソース管理では、同じ共有ストレージを使用して複数のクラスタのリソースを管理できます。 - カテゴリ・リソース管理について
カテゴリは、すべてのデータベースのコンシューマ・グループの集合を表します。 - コンシューマ・グループおよびリソース・プランについて
Exadata Database Machineには、Oracle Exadata System Softwareを使用するデータ・ウェアハウス専用のデフォルトのコンシューマ・グループおよびリソース・プランが付属しています。 - CDBプランおよびプラガブル・データベースについて
コンテナ・データベース(CDB)では、リソースについて競合する複数のPDB内に、複数のワークロードが存在する場合があります。
親トピック: I/Oリソースの管理
6.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)の理解
6.1.1.1 IORMのobjectiveについて
I/Oリソース管理(IORM)のobjective
オプションは、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
は両方のワークロードが同時に実行される場合に、スキャン・スループットが大幅に低下することを犠牲にして最大のレイテンシ保護を提供します。
6.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リソースを共有しているデータベースが複数あり、特定のデータベースへのリソース割当てを制御する場合に使用できます。
ALTER IORMPLAN
コマンドを使用してクラスタ・プラン(clusterplan
)を指定することで構成されます。clusterplan
には、特定のクラスタ内のすべてのデータベースに適用されるリソース割当てを指定するディレクティブが含まれます。
ノート:
クラスタ・プランは、Oracle Exadata System Softwareリリース21.2.0で初めて導入されました。catplan
)を定義します。
ノート:
Oracle Exadata System Softwareリリース21.2.0以降、カテゴリ・プランは非推奨となり、カテゴリ・プランが設定されると警告メッセージが発行されます。6.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ベースのリソース管理が唯一のオプションです。
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のフラッシュ・キャッシュおよびPMEMキャッシュの割当て制限を定義し、データベース・インスタンスのメモリー・サイズ設定には影響しません。 -
リソース・プランの作成
データベースのリソース・プランはデータベース内リソース・プランとも呼ばれ、データベースのコンシューマ・グループ間で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
初期化パラメータを使用して手動で有効にできます。また、ジョブ・スケジューラ・ウィンドウで自動的に有効にすることもできます。
データベースでデータベース・リソース・プランを設定すると、プランの説明が各セルに自動的に送信されます。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
です。
6.1.3 データベース間のリソース管理について
データベース間のリソース管理では、同じ共有ストレージを使用して複数のデータベースのリソースを管理できます。
データベース間のプランでは、複数のデータベース間でリソースを各ストレージ・サーバーにどのように割り当てるか(allocationまたはshare別)を指定します。データベース間のプランのディレクティブでは、コンシューマ・グループではなくデータベースへの割当てを指定します。データベース間のプランは、各ストレージ・サーバーでCellCLIユーティリティを使用して構成および有効化されます。
- データベース間のIORMプランのディレクティブについて
データベース間のプランのディレクティブは、データベースのDB_UNIQUE_NAME
を識別子として使用して指定されます。 - 統合と分離でのデータベース間のプランの使用
データベース間のリソース管理プランを使用すると、データベースを統合または分離する際のリソースの管理に役立ちます。 - IORMプランでのフラッシュ・キャッシュ管理について
I/Oリソース管理では、Exadataスマート・フラッシュ・キャッシュ内の領域を保証することにより、予測可能なパフォーマンスを実現できます。 - IORMプランでのPMEMキャッシュ管理について
I/Oリソース管理では、Oracle Exadata Storage Server X8M以降で使用可能な永続メモリー(PMEM)キャッシュ内の領域を保証することにより、予測可能なパフォーマンスを実現できます。 - IORMを使用したフラッシュ・リソースおよびPMEMリソースへのデータベース・アクセスの制御
IORMを使用して、重要なフラッシュ・メモリー・リソースおよび永続メモリー(PMEM)リソースへのアクセスを管理できます。 - データベース間のリソース・プランの管理のヒント
データベース間のリソース・プランを作成および管理する場合は、次の情報に注意してください。
関連項目
親トピック: I/Oリソース管理(IORM)の理解
6.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
属性を使用すると、データベース間プランの各データベースを一意に識別できます。
親トピック: データベース間のリソース管理について
6.1.3.2 統合と分離でのデータベース間のプランの使用
データベース間のリソース管理プランを使用すると、データベースを統合または分離する際のリソースの管理に役立ちます。
同じOracle Exadata Storage Serverを共有する4つの異なるデータベースを統合する場合を検討します。すべてのデータベースが同じ優先度の場合は、IORMを使用してI/Oリソースの25%を各データベースに均等に割り当てることができます。1つのデータベースが他のデータベースよりも重要な場合、IORMを使用して、より高いshareのI/Oリソースを与えることができます。
最大使用率制限の定義は、統合シナリオの場合にも便利です。制限を使用すると、ワークロードが突然上昇した場合に各データベースを分離できます。たとえば、データベースごとに40%の最大使用率制限を定義できます。これにより、システムを独占できるデータベースがないことが保証されます。ただし、データベースが割り当てられた制限に達すると、空き容量を利用できなくなります。したがって、制限を指定すると、ディスクをフル容量未満で実行できます。
また、制限を使用したリソース管理は、購入されたサービスのレベルに応じて顧客に対するパフォーマンスをサービス・プロバイダが保証する、パフォーマンス・ベース課金のユースケースにも理想的です。たとえば、より低いパフォーマンス階層を購入する顧客は、より高いパフォーマンスに対して購入する顧客よりも制限する必要があります。
親トピック: データベース間のリソース管理について
6.1.3.3 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
の一部になります。
親トピック: データベース間のリソース管理について
6.1.3.4 IORMプランでのPMEMキャッシュ管理について
I/Oリソース管理では、Oracle Exadata Storage Server X8M以降で使用可能な永続メモリー(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
割当て制限はflashcachemin
設定の一部になり、PDB固有のmemory_limit
値はpmemCacheSize
の一部になります。
ただし、データベース間IORMプラン・ディレクティブでpmemCacheMin
を指定せずにpmemCacheSize
が指定されている場合、PDB固有のmemory_min
設定は無視されますが、memory_limit
設定は引き続きpmemCacheSize
の一部になります。
親トピック: データベース間のリソース管理について
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 データベース間のリソース・プランの管理のヒント
データベース間のリソース・プランを作成および管理する場合は、次の情報に注意してください。
- Exadata Database Machineが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プラン内のPMEMキャッシュ設定(pmemcachemin
およびpmemcachesize
)の関係に関して、永続メモリー(PMEM)キャッシュにも同じことが当てはまります。
親トピック: データベース間のリソース管理について
6.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を有効範囲にしたセキュリティも構成する必要があります。
6.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に用意されている事前定義済のカテゴリとサンプルの割合を説明したものです。
表6-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)の理解
6.1.6 コンシューマ・グループおよびリソース・プランについて
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リソース管理(IORM)の理解
6.1.6.1 DSS_PLANリソース・プラン
DSS_PLANリソース・プランは、クリティカルではないDSS問合せおよびETLジョブよりもクリティカルなDSS問合せを優先するデータ・ウェアハウス用に設計されています。
このプランでは、SYS_GROUPが最高の優先度を持ち、次にDSS_CRITICAL_GROUP、DSS_GROUPが続き、その次にETL_GROUPとBATCH_GROUPの組合せが続きます。帯域幅のすべてを使用できるコンシューマ・グループはありません。
表6-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グループに付与されます。
親トピック: コンシューマ・グループおよびリソース・プランについて
6.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%)より多くなっています。
表6-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 |
未設定 |
未設定 |
親トピック: コンシューマ・グループおよびリソース・プランについて
6.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)の理解
6.2 IORMの管理
I/Oリソース管理(IORM)に関連する様々な管理タスクを実行できます。
このタスクを実行するには、DBMS_RESOURCE_MANAGER
パッケージを使用して、データベース・サーバー上にデータベース・リソース・プランを定義し、CellCLIユーティリティを使用して、各セルのIORMプランを指定します。
- IORMのobjectiveの設定
IORMのobjectiveを設定するには、CellCLIのALTER IORMPLAN
コマンドを使用します。 - データベース・リソース管理の管理
データベース・リソース管理を設定するには、Oracle Database Resource Managerを使用し、コンシューマ・グループを構成してセッションをコンシューマ・グループに割り当て、データベース・リソース・プランを作成してプランを有効にする必要があります。 - IORMプランの管理
IORMプランは、CellCLIのALTER IORMPLAN
コマンドを使用して管理できます。 - I/Oリソース管理プランの表示
ストレージ・サーバー上のCellCLILIST IORMPLAN
コマンドを使用して、ストレージ・サーバーの現在のデータベース間プランを表示できます。 - データベースおよびPDBのためのフラッシュ・キャッシュ割当て制限の管理
IORMにより、異なるデータベースとプラガブル・データベース(PDB)の間でフラッシュ・キャッシュをどのように共有するかを制御できます。 - データベースおよびPDBのためのPMEMキャッシュ割当て制限の管理
I/Oリソース管理(IORM)により、異なるデータベースとプラガブル・データベース(PDB)の間でPMEMキャッシュをどのように共有するかを制御できます。 - IORM profileの使用
I/Oリソース管理(IORM)のデータベース間プランでは、数百ものデータベースのデータベース間プランの管理と構成を容易にするため、プロファイルがサポートされています。 - I/Oリソース管理の構成の確認
このチェックリストを使用して、I/Oリソース管理(IORM)が正しく構成されていることを確認します。
関連項目
親トピック: I/Oリソースの管理
6.2.1 IORMのobjectiveの設定
IORMのobjectiveを設定するには、CellCLIのALTER IORMPLAN
コマンドを使用します。
たとえば:
CellCLI> ALTER IORMPLAN objective=auto
親トピック: IORMの管理
6.2.2 データベース・リソース管理の管理
データベース・リソース管理を設定するには、Oracle Database Resource Managerを使用し、コンシューマ・グループを構成してセッションをコンシューマ・グループに割り当て、データベース・リソース・プランを作成してプランを有効にする必要があります。
- コンシューマ・グループおよびカテゴリの設定
コンシューマ・グループおよびカテゴリは、PL/SQLDBMS_RESOURCE_MANAGER
パッケージのプロシージャを使用して設定します。 - コンシューマ・グループへのセッションの割当て
リソースのコンシューマ・グループにセッションを手動で割り当てるか、コンシューマ・グループのマッピング・ルールを使用して自動的に割り当てることができます。 - CDBプランの作成
CDBプランでは、データベース・サーバーのCPUリソースおよびExadataストレージ・サーバーのフラッシュ・キャッシュ領域やI/O帯域幅を管理します。 - データベース・プランの作成
データベース・リソース・プランはデータベース内プランとも呼ばれ、PL/SQLのDBMS_RESOURCE_MANAGER.CREATE_PLAN()
プロシージャおよびCREATE_PLAN_DIRECTIVE()
プロシージャを使用して作成されます。 - データベース・リソース・プランの有効化
データベース・リソース・プランは、RESOURCE_MANAGER_PLAN
パラメータを設定することで手動で有効化できます。リソース・プランでOracle Schedulerウィンドウを定義すると、リソース・プランを自動的に有効化できます。 - 高速ファイル作成の管理
Oracle Exadata System Softwareの高速ファイル作成機能では、データ・ファイルの初期化を高速化できます。 - データのインポート管理
I/Oリソース管理(IORM)を使用すると、ETLの優先度だけでなく、ETLで使用されるI/Oリソースの量も制御できます。 - Oracle Recovery Managerのバックアップおよびコピーの管理
I/Oリソース管理(IORM)を使用すると、RMAN I/Oのリソースの消費と優先順位を制御できます。
親トピック: IORMの管理
6.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
ビューには、データベース内のカテゴリに関する情報が表示されます。
例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.2.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.2.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.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リソースの両方を管理します。
例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.2.2.5 データベース・リソース・プランの有効化
データベース・リソース・プランは、RESOURCE_MANAGER_PLAN
パラメータを設定することで手動で有効化できます。リソース・プランでOracle Schedulerウィンドウを定義すると、リソース・プランを自動的に有効化できます。
Oracle Schedulerウィンドウが開くと、リソース・プランが有効になります。Oracle Schedulerウィンドウが閉じると、リソース・プランが無効になります。
リソース・プランが有効になると、このイベントに関してデータベースからすべてのセルにアラートが通知され、リソース・プランが提供されます。リソース・プランが無効になる場合も、すべてのセルにアラートが通知されます。データベースではリソース・プランを1つしかアクティブにできないため、データベースのすべてのインスタンスで同じリソース・プランを有効にする必要があります。データベースでデータベース・リソース・プランが有効になっていない場合は、すべてのI/Oリクエストが同等に処理されます。
親トピック: データベース・リソース管理の管理
6.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を使用して優先度を変更することはできません。
例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.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
グループを含めます。
非圧縮データを圧縮データとしてインポートするには:
例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.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
コンシューマ・グループにマップされます。これらの関数は、次の例に示すように他のコンシューマ・グループに再マップできます。
例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.2.3 IORMプランの管理
IORMプランは、CellCLIのALTER IORMPLAN
コマンドを使用して管理できます。
- IORMプランの設定
IORMプランを設定するには、CellCLIのALTER IORMPLAN
コマンドを使用します。 - shareベースのリソース管理の使用
share値は、各エンティティの相対的な重要度を表します。 - allocationベースのリソース管理の使用
IORMで、allocation値ではリソース割当てをパーセンテージ(0から100)で指定します。 - limit属性の使用
limit
属性では、使用可能なリソースの割合として最大I/O使用率の制限を指定します。 - フラッシュ・キャッシュ属性の使用
IORMプランでフラッシュ・キャッシュ属性を使用して、Exadataスマート・フラッシュ・キャッシュの領域割当てを保証できます。 - PMEMキャッシュ属性の使用
IORMプランでPMEMキャッシュ属性を使用して、永続メモリー(PMEM)キャッシュの領域割当てを保証できます。 - フラッシュ・キャッシュおよびフラッシュ・ログへのアクセスの制御
IORMを使用して、フラッシュ・キャッシュおよびフラッシュ・ログへのアクセスを管理できます。 - PMEMキャッシュおよびPMEMログへのアクセスの制御
IORMを使用して、永続メモリー(PMEM)キャッシュおよびPMEMログへのアクセスを管理できます。 - role属性の使用
role
属性により、データベースにOracle Data Guardprimary
またはstandby
ロールがあるかどうかに基づいて、異なる割当てを指定できます。 - asmcluster属性の使用
asmcluster
属性を使用すると、同じDB_UNIQUE_NAME
を持つデータベースを一意に識別できます。 - IORMプランのデフォルト値のリセット
IORMプランをリセットするには、空の文字列を使用します。
親トピック: IORMの管理
6.2.3.1 IORMプランの設定
IORMプランを設定するには、CellCLIのALTER IORMPLAN
コマンドを使用します。
IORMプランは、有効なディレクティブがカテゴリ・プラン(catplan
)、データベース間プラン(dbplan
)またはクラスタ・プラン(clusterplan
)で有効になっている場合に設定されます。
たとえば:
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
コマンドを使用して実行することを検討してください。
親トピック: IORMプランの管理
6.2.3.2 shareベースのリソース管理の使用
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プランの管理
6.2.3.3 allocationベースのリソース管理の使用
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プランの管理
6.2.3.4 limit属性の使用
limit
属性では、使用可能なリソースの割合として最大I/O使用率の制限を指定します。
limit
属性を使用して、データベース間プランまたはクラスタ・プランのエンティティのI/O使用率を制限できます。この属性は、指定されたエンティティが指定された制限を超えてI/Oリソースを使用しないようにします。たとえば、本番とテスト用のデータベースがOracle Exadata Storage Serverリソースを共有している場合、データベース間プランでテスト用データベースの最大使用率制限を次のように設定できます。
ALTER IORMPLAN dbplan=((name=prod), -
(name=test, limit=20), -
(name=DEFAULT, limit=10))
最大使用率制限が指定されている場合、超過容量は使用されない可能性があります。そのため、最大使用率制限を指定すると、ディスクをフル容量未満で実行できます。
制限を使用したリソース管理は、パフォーマンス・ベース課金のユースケースに理想的ですが、公平性を実現するためには使用できません。
親トピック: IORMプランの管理
6.2.3.5 フラッシュ・キャッシュの属性の使用
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
を指定して、保証付きの最小割当て制限を定義することもできます。
例6-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))
例6-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プランの管理
6.2.3.6 PMEMキャッシュ属性の使用
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
を指定して、保証付きの最小割当て制限を定義することもできます。
例6-12 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.2.3.7 フラッシュ・キャッシュおよびフラッシュ・ログへのアクセスの制御
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.2.3.8 PMEMキャッシュおよびPMEMログへのアクセスの制御
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プランの管理
6.2.3.9 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))
6.2.3.10 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.2.3.11 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プランの管理
6.2.4 I/Oリソース管理プランの表示
ストレージ・サーバー上のCellCLI LIST IORMPLAN
コマンドを使用して、ストレージ・サーバーの現在のデータベース間プランを表示できます。
例6-13 データベース間プランの詳細の表示
この例は、データベース間プラン属性の詳細なリストを取得する方法を示しています。
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.2.5 データベースおよびPDBのためのフラッシュ・キャッシュ割当て制限の管理
IORMにより、異なるデータベースとプラガブル・データベース(PDB)の間でフラッシュ・キャッシュをどのように共有するかを制御できます。
これは、CDBリソース・プランのみ、またはI/Oリソース管理(IORM)データベース間プランと組み合せて使用できます。
プランに記載されている3つのPDB用にmemory_min
およびmemory_limit
を指定するCDBリソース・プランを考えてみてください。次の点に注意してください。
memory_min
およびmemory_limit
の値は、0から100の範囲のパーセンテージで指定されます。オーバー・プロビジョニングがサポートされているため、パーセンテージの合計は100%には制限されません。これらの値の合計が100%を超える場合、値はパーセンテージへと正規化されます。memory_min
が指定されていない場合は、デフォルトで0に設定されます。memory_limit
が指定されていない場合は、デフォルトで100に設定されます。CDB$ROOT
用には、5%のmemory_limit
値があります。
次の例では、3つのPDBのデータベース間プランを作成する方法を示します。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%を超えたために)制限を正規化した後の割当て制限の内訳を次の表に示します。正規化後、最小値が対応する制限より大きくなった場合は、最小値は制限と等しくなるように減らされます。
表6-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 |
該当なし |
次の例は、フラッシュ・キャッシュ割当て制限のあるデータベース間プランを示しています。この例では、基礎となるフラッシュ・キャッシュ・サイズの合計が50 GBで、PMEMキャッシュ・サイズが10 GBであると仮定しています。
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
属性を指定する場合のみです。データベース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プランの例とともに適用した場合に有効なフラッシュ・キャッシュ制限を示します。
表6-5 ケース2: データベース間プランがある場合のPDBフラッシュ・キャッシュの制限
PDB | フラッシュ・キャッシュの最小 | FCの強い制限 | 正規化済の強い制限 | FCの弱い制限 |
---|---|---|---|---|
SALESPDB |
0 |
100 (デフォルト) |
100 / 175 * 10 GB = 5.71 GB |
該当なし |
SERVICESPDB |
0 |
50 |
50 / 175 * 10 GB = 2.86 GB |
該当なし |
HRPDB |
0 |
25 |
25 / 175 * 10 GB = 1.43 GB |
該当なし |
非CDBデータベースでは、flashcachesize
、flashcachemin
およびflashcachelimit
の値は絶対的な値として指定され、追加の正規化は必要ありません。flashcachemin
は保証付きの予約であるため、flashcachemin
の合計は、すべてのディレクティブ全体でフラッシュ・キャッシュの合計サイズより小さくする必要があります。
親トピック: IORMの管理
6.2.6 データベースおよびPDBのためのPMEMキャッシュ割当て制限の管理
I/Oリソース管理(IORM)により、異なるデータベースとプラガブル・データベース(PDB)の間でPMEMキャッシュをどのように共有するかを制御できます。
これは、CDBリソース・プランのみ、またはI/Oリソース管理(IORM)データベース間プランと組み合せて使用できます。
プランに記載されている3つのPDB用にmemory_min
およびmemory_limit
を指定するCDBリソース・プランを考えてみてください。次の点に注意してください。
memory_min
およびmemory_limit
の値は、0から100の範囲のパーセンテージで指定されます。オーバー・プロビジョニングがサポートされているため、パーセンテージの合計は100%には制限されません。これらの値の合計が100%を超える場合、値はパーセンテージへと正規化されます。memory_min
が指定されていない場合は、デフォルトで0に設定されます。memory_limit
が指定されていない場合は、デフォルトで100に設定されます。CDB$ROOT
用には、5%のmemory_limit
値があります。
次の例では、3つのPDBのデータベース間プランを作成する方法を示します。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%を超えたために)制限を正規化した後の割当て制限の内訳を次の表に示します。正規化後、最小値が対応する制限より大きくなった場合は、最小値は制限と等しくなるように減らされます。
表6-6 ケース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 |
該当なし |
次の例は、PMEMキャッシュ割当て制限のあるデータベース間プランを示しています。この例では、基礎となるフラッシュ・キャッシュ・サイズの合計が50 GBで、PMEMキャッシュ・サイズが10 GBであると仮定しています。
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キャッシュの割当て制限が強制されるのは、ディレクティブで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キャッシュ制限を示します。
表6-7 ケース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の管理
6.2.7 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, limit=100, type=profile), -
(name=silver, share=5, limit=60, type=profile), (name=bronze, share=1, limit=20, -
type=profile))
前述の例には、profileの3つのディレクティブ(GOLD
、SILVER
およびBRONZE
)が含まれています。db_performance_profile
がGOLD
に設定されたすべてのデータベースは、セルに対して10のshare、および100%のlimitを取得します。同様に、前述の例では、SILVER
profileを持つデータベースは5つのshareと60%のlimitを取得し、BRONZE
profileを持つデータベースは1つのshareと20%のlimitを取得します。
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の管理