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

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

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

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スタンバイ・サービス・インスタンスでは発生しません。

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

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

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

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

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

• Autonomous Databaseを作成する場合、指定したCPU数がACDレベルで定義されたデータベース分割しきい値またはAVMCのノード当たりのCPU数(どちらか小さい方)より大きい場合、そのCPU割当ては複数のVMクラスタ・ノードに分割されます。

  たとえば、2つのノードと40 ECPUのノードを持つAVMCリソースを作成し、データベース分割しきい値を64に設定してこのAVMCにACDを作成したとします。40は64より小さいため、40を超えるCPU要件を持つAutonomous Databaseは、複数のノード間で分割およびオープンされ、それらのノード間でDMLリクエストが可能になります。ただし、AVMCが2つのノードおよびノード当たり80 ECPUで作成された場合、ECPU要件が64を超えるデータベースは分割され、複数のノードにまたがってオープンされます。

• Autonomous Databaseを手動でスケーリングすると、そのCPU割当ては、この同じ割当てモデルと一致するようにリバランスされます単一のVMクラスタ・ノードは、ACDレベルで設定されたデータベース分割しきい値以下のCPU数、またはAVMCリソースのノード当たりのCPU数(いずれか)に使用されますCPU数がACDレベルで設定されたデータベース分割しきい値またはAVMCリソースのノード当たりのCPU数のいずれか小さい方より大きい場合は、複数のVMクラスタ・ノードに分割されます。

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