専用Exadataインフラストラクチャ上のAutonomous Databaseでのコンピュート管理

専用Exadataインフラストラクチャ上のAutonomous Databaseでは、Autonomous Databaseリソースの構成中に2つのコンピュート・モデルが提供されます。これは次のとおりです:

ECPU: ECPUは抽象化されたコンピュート・リソースの尺度です。ECPUは、コンピュートおよびストレージ・サーバーのプールから柔軟に割り当てられたコア数に基づいています。Autonomous Databaseをプロビジョニングするには、少なくとも2つのECPUが必要です。

新しいデータベースのプロビジョニング、既存のデータベースのクローニングおよび既存のデータベースのCPUリソースのスケール・アップまたはスケール・ダウを行う場合、CPU数はデフォルトで2 ECPU (1単位)になります。たとえば、2を超える次の使用可能なECPU数は3です。

ECPUベースのコンテナ・データベースにAutonomous Database for Developersインスタンスを作成できます。開発者が新しいアプリケーションを構築およびテストするために使用できる無料のAutonomous Databaseです。詳細は、開発者向けAutonomous Databaseを参照してください。
OCPU: OCPUは、コンピュート・リソースの物理的な尺度です。OCPUは、ハイパースレッドが有効なプロセッサの物理コアに基づきます。

ノート:
OCPUはレガシー請求メトリックであり、専用Exadataインフラストラクチャ上のAutonomous Databaseに対してリタイアされています。Oracleでは、新規および既存のすべてのAutonomous DatabaseデプロイメントにECPUを使用することをお薦めします。詳細は、Oracle Supportドキュメント2998755.1を参照してください。

新しいデータベースのプロビジョニング、既存のデータベースのクローニングおよび既存のデータベースのCPUリソースのスケール・アップまたはスケール・ダウンの場合:
- CPU数のデフォルトは1 OCPUで、単位は1です。たとえば、次に使用可能な1を超えるOCPUの数は2です。
- 全体OCPUを必要としないデータベースの場合、0.1から0.9までのOCPUを0.1 OCPU単位で割り当てることができます。これにより、CPUをオーバープロビジョニングし、各インフラストラクチャ・インスタンスでより多くのデータベースを実行できます。詳細は、CPUオーバープロビジョニングを参照してください。

Autonomous Exadata VMクラスタのコンピュート・タイプは、そのすべてのAutonomous Container DatabaseおよびAutonomous Databaseインスタンスに適用されます。

関連項目

専用ExadataインフラストラクチャでのAutonomous Databaseの請求

コンピュート管理

Autonomous Databaseインスタンスは、Autonomous Exadata VMクラスタ(AVMC)およびその子Autonomous Container Database (ACD)のいずれかにデプロイされます。Exadataインフラストラクチャでは、複数のAVMCを実行できます。AVMCリソースのプロビジョニング中に割り当てるCPUは、そのAutonomous Databaseで使用可能な合計CPUになります。複数のAVMCを作成する場合、各AVMCはCPU合計に独自の値を設定できます。

複数のVM Exadata VMクラスタは、複数のVM Autonomous Database機能の起動前に作成されたExadataインフラストラクチャ(EI)リソースのOracle Public Cloudデプロイメントでは使用できません。複数AVMC機能の起動後に作成されたX8M生成以上のExadataインフラストラクチャ・リソースの場合、各AVMCは、選択したExadataシステム・シェイプのサーバーごとに1つのクラスタ・ノードを使用して作成されます。異なるユーザー・グループ間でこれらの合計CPUを制約する方法の詳細は、コンパートメント割当てがCPU管理に与える影響を参照してください。

ノート:

特定のExadataインフラストラクチャで作成できるAVMCおよびACDリソースの最大数は、ハードウェアの生成によって異なります。各世代の制約の詳細は、リソース制限およびインフラストラクチャ・シェイプの特性を参照してください。

AVMCまたはACDレベルで、データベースの作成に使用できるCPUの合計数は、使用可能なCPUと呼ばれます。AVMCリソース・レベルでは、最初のACDを作成するまで、使用可能なCPUはCPU合計と等しくなります。ACDを作成すると、ノード当たり8 ECPUまたは2 OCPUがAVMCの使用可能なCPUから新しいACDに割り当てられます。したがって、AVMCリソース・レベルで使用可能なCPUは、それに応じて減少します。そのACDで最初のAutonomous Databaseを作成すると、新しいデータベースは、最初に割り当てられたCPU(ノード当たり8 ECPUまたは2 OCPU)を使用します。新しいデータベースに必要なECPUが8を超える場合、またはOCPUが2を超える場合は、親AVMCの使用可能なCPUから割り当てられるため、親AVMCレベルで使用可能なCPUは少なくなります。ACDをさらに作成し、各ACD内でAutonomous Databaseをプロビジョニングすると、それに応じて使用可能なCPU値が変更されます。

Autonomous Exadata VMクラスタ・レベルで使用可能なCPUは、そのすべてのAutonomous Container Databaseに適用されます。自動スケーリング時のCPU割当てで説明されているように、自動スケーリング機能を使用している場合、コンテナ・データベースで使用可能なこのCPU数は重要です。

同様に、Autonomous DatabaseのCPUを手動でスケール・アップすると、CPUは親のAVMCレベルで使用可能なCPUから消費され、それに応じて値が変化します。

Autonomous Databaseを作成すると、Oracleはデフォルトで追加のCPUを予約して、ノード障害が発生した場合でもデータベースが50%以上の容量で実行されるようにします。ACDのプロビジョニング中に、ノード間で予約されているCPUの割合を0%または25%に変更できます。手順については、Autonomous Container Databaseの作成のノード・フェイルオーバー予約を参照してください。これらの追加CPUは、請求に含まれません。

Autonomous Databaseが実行されている場合、初期作成時に指定されたか、手動スケーリング操作によって後で指定されたかに関係なく、データベースに現在割り当てられているCPUの数に対して請求されます。また、データベースの自動スケーリングが有効になっている場合は、自動的にスケール・アップした結果としてデータベースで使用されている追加CPUの秒ごとに請求されます。請求を測定および計算する方法の詳細は、CPU請求の詳細を参照してください。

Autonomous Database停止している場合、請求されません。ただし、割り当てられたCPUの数は、デプロイメント全体の親AVMCレベルの使用可能なCPUに戻されません。

Autonomous Databaseが終了またはスケール・ダウンされると、そのデータベースに割り当てられているCPUの数は、デプロイメント全体について、親AVMCレベルの使用可能なCPUにすぐに戻されるわけではありません。その親コンテナ・データベースが再起動されるまでは、引き続き親コンテナ・データベースで使用可能なCPUの数に含まれます。これらのCPUは、再利用可能CPUと呼ばれます。親AVMCレベルの再利用可能なCPUは、そのすべてのACDの再利用可能なCPUの合計です。ACDが再起動すると、すべての再利用可能なCPUが親AVMCレベルの使用可能なCPUに返されます。

Autonomous Container Database (ACD)の再起動は、クラスタ全体でローリング方式で実行されるオンライン操作であり、透過的アプリケーション・コンティニュイティを使用するためのベスト・プラクティスに従って構成されている場合、アプリケーションの停止時間は発生しません。

ヒント :

この記事で説明する様々なコンピュート(CPU)属性は、Autonomous Exadata VMクラスタ(AVMC)またはAutonomous Container Database (ACD)の「詳細」ページから追跡できます。ガイダンスは、リソース使用状況トラッキングを参照してください。

自動スケーリング時のCPU割当て

自動スケーリング機能により、Autonomous Databaseでは、割り当てられたCPU数の最大3倍のCPUおよびIOリソースを使用できます。CPUオーバープロビジョニングの場合、CPU数が3倍になると値が1未満になると、次の整数に丸められます。CPUオーバープロビジョニングは、OCPUでのみサポートされています。詳細は、CPUオーバープロビジョニングを参照してください。

単一のAutonomous Databaseを自動スケール・アップして、デプロイメント全体に対してプールで使用可能なすべてのCPUを消費できないようにするために、Oracle Autonomous Database on Dedicated Exadata Infrastructureでは、Autonomous Container Databaseを制限制御として使用します。

ACDでの自動スケーリングが有効なAutonomous Databaseのプロビジョニング中に、そのACD内の使用可能なCPUが新しいデータベースの3X CPU値より小さい場合、そのACDで追加のCPUが予約されます。これらのCPUは、予約済CPUと呼ばれます。予約済CPUは、ACDレベルで使用可能なCPUが、そのACDで最大の自動スケーリング対応データベースの3x CPU値以上であることを常に保証します。これらの予約済CPUは、引き続きこのACDでAutonomous Databaseを作成または手動でスケーリングするために使用できます。

Autonomous Databaseを自動的にスケール・アップする場合、Oracle Autonomous Database on Dedicated Exadata Infrastructureでは、親コンテナ・データベース内のアイドルCPUが検索されます。アイドルCPUが使用可能な場合、Autonomous Databaseはスケール・アップされます。それ以外の場合、スケール・アップされません。データベースには本質的にアイドル時間が多いため、自動スケーリングは、コストを制御しながらリソース使用率を最大化し、他のAutonomous Container Database内のデータベースから適切な分離を維持する方法です。

Autonomous Databaseの自動スケーリングに使用されるCPUが、軽量でロードされ、割り当てられたすべてのCPUを使用していない別の実行中のAutonomous Databaseからのものである場合、Oracle Autonomous Database on Dedicated Exadata Infrastructureは、他のデータベースで負荷が増加し、割り当てられたCPUを戻す必要がある場合に、自動スケーリングされたデータベースを自動的にスケール・ダウンします。

自動スケーリングが有効になっている4 CPUのAutonomous Databasesを実行している4つのAutonomous Container DatabaseをホストするAutonomous Container Databaseの例について考えてみます。このコンテナ・データベースで自動スケーリング目的に使用できるCPUの数は12です。負荷の増加により、これらのデータベースの1つを4 CPUを超えて自動スケーリングする必要がある場合、Oracle Autonomous Database on Dedicated Exadata Infrastructureは、他の1つ以上のデータベースの負荷が軽く、割り当てられているすべてのCPUを使用していない場合にのみ、自動スケーリング操作を実行します。4つの4 CPUデータベースが常に実行されているため、この例の請求コストは少なくとも16 CPUです。

対照的に、2 CPU Autonomous Databasesを実行している4つをホストするAutonomous Container Databaseの例を考えてみましょう。すべて自動スケーリングが有効になっており、1つは8 CPU Autonomous Databaseを停止しています。また、このコンテナ・データベースで自動スケーリング目的に使用できるCPUの数は16です。負荷の増加により、実行中のデータベースの1つを2 CPUを超えて自動スケーリングする必要がある場合、Oracle Autonomous Database on Dedicated Exadata Infrastructureは、停止した8 CPUデータベースに割り当てられているCPUを使用して操作を実行できます。この例では、4つの実行中データベースは、相互に割り当てられたCPUを消費することなく、同時に合計8つの追加CPUを消費できます。4つの2 CPUデータベースのみが常に実行されているため、この例の請求コストは少なくとも8つのCPUです。

Autonomous Data Guardサービス・インスタンス(ローカルまたはクロスリージョン)の場合、追加価格は、自動スケーリングが有効かどうかに関係なく、プライマリ・サービス・インスタンスを作成または明示的にスケーリングしたときに予約したECPUまたはOCPUの数になります。プライマリ・サービス・インスタンスでの自動スケーリング関連のECPUまたはOCPU消費は、Autonomous Data Guardスタンバイ・サービス・インスタンスでは発生しません。

CPU管理へのコンパートメント割当て制限の影響

通常、Autonomous Databaseを作成またはスケール・アップする場合、リクエストを満たすOracle Autonomous Database on Dedicated Exadata Infrastructureの機能は、デプロイメント全体にわたるCPUの単一プール内の未割当てCPUの可用性にのみ依存します。

ただし、Oracle Cloud Infrastructureのコンパートメント割当て機能を使用して、コンパートメントごとに、各ワークロード・タイプ(データ・ウェアハウスまたはトランザクション処理)の自律型データベースの作成、手動スケーリングおよび自動スケーリングに使用できるCPUの数をさらに制限できます。

簡単に言うと、コンパートメントの割当て制限の機能を使用するには、set、unsetおよびzeroポリシー・ステートメントを作成して、特定のコンパートメント内の特定のリソースの可用性を制限します。詳細および手順は、コンパートメントの割当て制限を参照してください。

VMクラスタ・ノードのCPU管理への影響

前述のCPU管理および割当て状態の説明では、AVMCリソースのプロビジョニング中にノード当たりのCPU数を選択することで、複数のAutonomous Exadata VMクラスタ(AVMC)リソースを作成できます。

この項では、Oracle Cloud InfrastructureがVMクラスタ・ノードにAutonomous Databaseを配置する方法、および自動スケーリングおよびパラレル処理におけるこのような配置の結果について詳細に説明します。

次の属性は、Autonomous Databaseが複数のノードにまたがるタイミングと方法を決定します:

分割しきい値: Oracle Cloud Infrastructureが複数のノードにまたがってAutonomous Databaseを開くCPU値。デフォルトの分割しきい値は、ECPUの場合は64、OCPUの場合は16ですが、CPUノード数がデフォルト値未満でVMクラスタが作成された場合、デフォルトはVMクラスタ・ノード数サイズに上書きされます。Autonomous Container Database (ACD)のプロビジョニング中に、「しきい値の分割」属性を使用して分割値を明示的に設定することもできます。

分割値より小さいCPU値で作成されたAutonomous Databaseは、クラスタ内の1つのノードでオープンし、分割しきい値を超えるCPU値で作成されたものは、複数のノードでオープンします。
- AVMCにデフォルトの分割しきい値(64 ECPU)を持つACDを作成し、2つのノードと40 ECPUをノード当たりにするとします。40は64未満であるため、CPU要件が40より大きいAutonomous Databaseは複数のノードで分割およびオープンされ、それらのノード間でDMLリクエストが可能になります。ただし、AVMCが2つのノードおよびノード当たり80 ECPUで作成された場合、ECPU要件が64を超えるデータベースは分割され、複数のノードにまたがってオープンされます。
- 2つのノードと40 ECPUのノードを持つVMクラスタにACDを作成し、分割しきい値をはるかに小さい値(20 ECPUなど)に明示的に設定するとします。CPU要件が20より大きいAutonomous Databaseは、複数のノード間で分割およびオープンされ、CPU要件が20未満のデータベースは単一ノードでオープンされます。
  
  分割しきい値をデフォルト値よりもはるかに小さい値に設定すると、複数のノードでCPU数が小さいデータベースが開いている可能性が高くなります(CPU数が設定された分割値より大きい場合)。データベースが作成されるか、この分割値より大きいサイズにスケーリングされるたびに、複数のノードでオープンされます。これは、複数のノードでデータベースをオープンして、ノード障害または計画メンテナンスの場合のパフォーマンス低下を制御する場合に便利です。大きいRACクラスタ内の複数のノードにデータベースを分割すると、1つのノードに障害が発生した場合や、スケジュールされたメンテナンスが発生した場合でも、パフォーマンス・プロファイルを50%に低下させるのではなく、パフォーマンスを引き続き向上させることができます。
- 2つのノードと40 ECPUを持つAVMCで、デフォルト(80 ECPUなど)よりも分割しきい値をはるかに高い値に明示的に設定するとします。CPU要件が40より大きいAutonomous Databaseは、複数のノード間で分割およびオープンされ、CPU要件が40未満のデータベースは単一ノードでオープンされます。
  
  分割しきい値をデフォルトよりはるかに高い値に設定すると、データベースDMLは単一のRACノードにとどまり、クラスタ待機競合が発生する可能性がなくなります。
- Autonomous Databaseを手動でスケーリングすると、新しいCPU値が既存の分割モデルに適用されます。つまり、新しい値が分割しきい値より小さい場合、1つのノードでオープンし、その値が分割しきい値を超える場合は、複数のノードでオープンします。
分散アフィニティ: Autonomous Databaseが分割しきい値を超えるとオープンされるノードの数を決定します。
たとえば、ノードが4つ、ノード当たりECPUが80のAVMCリソースを作成し、データベースの「分割しきい値」が64に設定されたACDをこのAVMCに作成したとします。ECPU要件が120のAutonomous Databaseを作成すると、データベースが複数のノードに分割され、64を超える120 (分割しきい値)としてオープンされます。
- ディストリビューション・アフィニティが「最小ノード」に設定されている場合、Oracle Cloud Infrastructureは、各ノードに60 ECPUの2つのノードでデータベースを作成しようとします。これが不可能な場合は、それぞれ40 ECPUの3つのノードに分割されます。これも不可能な場合、Oracle Cloud Infrastructureは、それぞれ30 ECPUの4つのノードでデータベースをオープンしようとします。
- 最大ノードへの分散アフィニティを指定すると、Oracle Cloud Infrastructureは、それぞれ30 ECPUの4つのノードすべてに分割されたデータベースを作成しようとします。これが不可能な場合は、それぞれ40 ECPUの3つのノードに分割されます。これも不可能な場合、Oracle Cloud Infrastructureは、それぞれ60 ECPUの2つのノードでデータベースをオープンしようとします。
ノード・フェイルオーバー予約(%): ローカライズされた障害およびメンテナンス・イベントのために、AVMC内の隣接するノード(データベース・ソフトウェアが存在するがオープンしていないノード)に確保されるCPUの数。ノード・フェイルオーバーの予約は、分割されていないデータベース・デプロイメントに適用されます。デフォルトでは、50%の予約があります。つまり、障害イベントまたはメンテナンス中は引き続き実行されますが、割り当てられたCPUの50%で実行されます。
- 非常に使用率が低いクリティカルでないデータベースまたはデータベースの場合、ノード・フェイルオーバー予約を小さい値に設定して、最終的に専用Exadataインフラストラクチャ上に多数のデータベースを作成して統合できます。
- メンテナンス中の停止時間が許容される開発環境およびデータベースでは、この値をゼロに設定できます。
- ノード・フェイルオーバー予約は、分割しきい値および分散アフィニティを使用して、データベースが2つ以上のノードに分割されるようにすることによっても制御できます。Autonomous Databaseが4つのノードに分割されるシナリオを考えてみます。メンテナンス・アクティビティの進行中にローリング方式で一度に1つのノードを削除すると、常に3つのノードが稼働し、トラフィックが発生するため、パフォーマンス予約は通常の50%ではなく75%効果的に維持されます。より大きなクラスタでは、8ノード・クラスタでの87.5%の予約など、この予約をさらに推進できます。

Autonomous DatabaseのCPU割当てがVMクラスタ・ノード全体に分散される方法は、次の操作に影響します:

自動スケーリング:
- 自動スケーリングは、パラレル化不可能なDMLの場合は単一のVMクラスタ・ノード内で、DMLがパラレル化可能な場合はVMクラスタ・ノード間で発生する可能性があります。
- パラレル化不可能な問合せを含む複数の同時セッションをクラスタ内のすべてのノードにルーティングできるため、マルチノード・データベースのすべてのノードを効率的に自動スケーリングできます。
パラレル処理:
- SQL文のパラレル処理は、オープンされているAutonomous Exadata VMクラスタ・ノード内で、最初に単一ノード内で、次に隣接するオープン・ノードで発生します。前述のように、Autonomous Exadata VMクラスタのサイズによって異なります。

各ノードのリソース使用率に基づいて、使用可能なCPUのすべての値を使用してAutonomous Databaseをプロビジョニングまたはスケールできるわけではありません。たとえば、AVMCレベルで使用可能なCPUが20の場合、ノード・レベルのリソースの可用性に応じてAutonomous Databaseをプロビジョニングまたはスケールするために1から20のすべての値を使用できるわけではありません。Autonomous Databaseのプロビジョニングまたはスケーリングに使用できるCPU値のリストは、プロビジョニング可能なCPUと呼ばれます。

OCIコンソールからAutonomous Databaseをプロビジョニングまたはスケーリングしようとすると、「CPU」フィールドに、プロビジョニング可能なCPUのリストがドロップダウンに表示されます。または、次のAPIを使用して、暫定的なCPU値のリストを取得できます:

GetAutonomousContainerDatabaseは、指定されたAutonomous Container Databaseで新しいAutonomous Databaseの作成に使用できるプロビジョニング可能なCPU値のリストを返します。詳細については、GetAutonomousContainerDatabaseを参照してください。
GetAutonomousDatabaseは、指定されたAutonomous Databaseのスケーリングに使用できるプロビジョニング可能なCPU値のリストを返します。詳細については、GetAutonomousDatabaseを参照してください。

タイトルおよび著作権情報

Oracle and/or its affiliates.