機械翻訳について

自動スケーリングの使用

Autonomous Databaseインスタンスを作成すると、デフォルトで「コンピュートの自動スケーリング」が有効になり、ストレージの自動スケーリングが無効になります。 Oracle Cloud Infrastructureコンソールから自動スケーリングを管理して、「コンピュートの自動スケーリング」またはストレージの自動スケーリングを有効または無効にできます。

自動スケーリングのコンピュート

「コンピュートの自動スケーリング」を有効にすると、Oracle Cloud Infrastructureコンソールの「ECPU数」または「OCPUカウント」フィールドに示すように、「ECPU (データベースがOCPUを使用している場合はOCPU)」の数で指定された数よりも最大3倍多くのCPUおよびIOリソースを使用できます。

自動スケールが有効化されていると、ワークロードに追加のCPUおよびIOリソースが必要な場合、データベースは手動操作を必要とせずに自動的にリソースを使用します。 たとえば:

  • ECPUコンピュート・モデルでは、「ECPU数」が512の場合、これにより、自動スケーリングが有効なときに、データベースは最大512 x 3 ECPU (1536 ECPU)を使用できます。

    1時間に使用されたECPUの平均数を確認するには、データベース・アクションの「データベース・ダッシュボード」カードの「概要」タブで「割り当てられたECPUの数」グラフを使用します。 詳細については、「データベース・ダッシュボードの概要」を参照してください。

  • OCPUコンピュート・モデルでは、「OCPUカウント」が128の場合、自動スケーリングが有効になっていると、データベースで最大128 x 3 OCPU (384 OCPU)を使用できます。

    1時間に使用されたOCPUの平均数を確認するには、データベース・アクションの「データベース・ダッシュボード」カードの「概要」タブで「割り当てられたOCPUの数」グラフを使用します。 詳細については、「データベース・ダッシュボードの概要」を参照してください。

「コンピュートの自動スケーリング」を有効にしても、事前定義済サービスの同時実行性および並列性の設定は変更されません。 詳細については、「Autonomous Databaseでの同時実行性と優先度の管理」を参照してください。

ノート:

ライセンス・タイプによって最大「ECPU数」が決まります。 たとえば、ライセンス・タイプがBring Your Own License (BYOL)でOracle Database Standard Edition (SE)の場合、「ECPU数」の最大値は32です。このライセンス・タイプの場合、「ECPU数」の最大許容値は32です。 コンピュートの自動スケーリングを有効にすると、最大「ECPU数」 x 3 ECPUを使用できます。 このライセンスは、コンピュート自動スケーリングが有効かどうかに関係なく、使用可能なECPUの数を最大32個のECPUに制限します。

「コンピュートの自動スケーリング」が有効な場合、データベースが使用される可能性があり、ワークロードで必要に応じて追加のCPU使用量に対して請求される場合があります(Oracle Cloud Infrastructureコンソールの「ECPU数」または「OCPUカウント」フィールドに示されているように)。 「コンピュートの自動スケーリング」請求の詳細は、「Oracle Autonomous Databaseサーバーレス機能の請求」を参照してください。

「コンピュートの自動スケーリング」を有効にするステップは、「CPUまたはストレージ・リソースの追加または自動スケーリングの有効化」を参照してください。

ストレージの自動スケーリング

Autonomous Databaseインスタンスを作成すると、デフォルトで「ストレージの自動スケーリング」が無効になります。 Oracle Cloud InfrastructureコンソールまたはAPIを使用して、スケーリングを管理し、ストレージの自動スケーリングを有効にできます。

「ストレージの自動スケーリング」を有効にすると、Autonomous Databaseは、Oracle Cloud Infrastructureコンソールの「ストレージ」フィールドに示されているストレージで指定されているように、予約済ベース・ストレージの3倍まで使用するように拡張できます。 追加のストレージが必要な場合は、手動で操作する必要なく、予約済ストレージが自動的に使用されます。

データベースをプロビジョニングまたはクローニングするときにベース・ストレージを指定します。または、「リソース割当の管理」をクリックしてストレージ・サイズを変更することで、いつでもストレージを変更できます。 ワークロード・タイプおよびコンピュート・モデルの選択に応じて、予約済ベース・ストレージ・ユニットを指定するための次のオプションがあります:

  • データ・ウェアハウス: ストレージをTB単位で指定します。

  • Transaction Processing: ストレージをギガバイト(GB)またはテラバイト(TB)で指定します。 GB単位は、ワークロード・タイプがトランザクション処理で、コンピュート・モデルがECPUの場合にのみ使用できます。

Oracle Cloud InfrastructureコンソールまたはAPIを使用して、Autonomous Databaseインスタンスのストレージを最大384 TBまでプロビジョニングまたは自動スケーリングできます。 384 TBを超えるストレージ要件の場合、Oracleでは、「Oracle Cloudサポート」にサービス・リクエストを提出することをお薦めします。

たとえば、ストレージが100 TBで、ストレージの自動スケーリングが有効になっている場合、最大300 TBのストレージにアクセスでき、ストレージが200 TBであれば最大384 TBにアクセスできます(サービス・リクエストを送信してより大きな最大をリクエストした場合、最大サイズはカスタムの最大サイズになります)。

データ・フローとして、ワークロード・タイプに応じて、次のように請求されます:

  • 予約済ベース・ストレージ未満のストレージ使用量については、ベース・ストレージに基づいて請求されます。

  • 割り当てられたストレージが予約済ベース・ストレージを超えると、割り当てられたストレージに基づいて、ワークロード・タイプがData Warehouseの場合はTBに切り上げられ、ワークロード・タイプがTransaction Processing、APEXまたはJSONの場合はGBに切り上げられた所定の時間に、ストレージ使用量が請求されます。

たとえば、ワークロード・タイプがData Warehouseの場合、予約済ベース・ストレージが4TBであれば、割り当てられたストレージが4TBのストレージを超えると、ベース・ストレージ(4TB)に基づいて請求されます。 4 TBを超えると、ストレージは、TBに最も近い場所で1時間に切り上げられ、割り当てられたストレージに基づいて請求されます。 この例では、割り当てられたストレージが特定の時間に4 TB以上増加した場合(たとえば4.9 TBまで)、その時間以降の5 TBのストレージについて請求されます。

1 TBのデータを削除した場合、割り当てられたストレージは4.9 TBのままとなり、縮小操作を実行するまで5 TBの課金されます。 縮小操作を実行すると、Autonomous Databaseによって、割り当てられたストレージを3.9 TB (データおよびUNDO表領域の縮小)に戻すことができます。 縮小操作が完了し、割り当てられたストレージ(3.9 TB)が予約ベース・ストレージ(4 TB)を再度下回ったら、4 TBの予約ベース・ストレージに対して再度請求されます。 詳細については、「ストレージの縮小」を参照してください。

ノート:

一時表領域を減らすには、データベースを再起動する必要があります。

Oracle Cloud Infrastructureコンソールの「ストレージ」フィールドに示されているストレージで指定されているとおり、「ストレージの自動スケーリング」を無効にして、使用されているストレージが予約されているベース・ストレージより大きい場合、Autonomous Databaseは、ストレージの自動スケーリング確認の無効化ダイアログに警告を表示します。 この警告により、予約済ベース・ストレージの値が、データ・ウェアハウス・ワークロード・インスタンスでの実際のストレージ使用量よりも最も近いTBに増加するか、トランザクション処理ワークロード・インスタンスでの実際のストレージ使用量よりも最も近いGBに増加することがわかり、新しい予約済ベース・ストレージ値が表示されます。

Autonomous Databaseインスタンスのストレージ使用量を確認するには、「データベース・アクション」の「データベース・ダッシュボード」カードをクリックして、「概要」タブで「割り当てられたストレージ」および「使用されたストレージ」グラフを表示します。 詳細については、「データベース・ダッシュボードの概要」を参照してください。

ストレージの自動スケーリングを有効にするステップについては、「CPUまたはストレージ・リソースの追加または自動スケーリングの有効化」を参照してください。

ストレージの自動スケーリングを有効にする場合は、次の点に注意してください:

  • Autonomous Databaseは、Exadata Smart Flash Cacheを使用して、頻繁にアクセスされるデータを自動的にキャッシュし、フラッシュのI/O率と高速なレスポンス時間を提供します。 データベースのフラッシュ・キャッシュの量は、プロビジョニングするストレージの量、またはストレージの自動スケーリングを有効にした場合に割り当てられるストレージの量によって異なります。

    ストレージの自動スケーリングが無効になっている場合、保証される最小フラッシュ・キャッシュ・サイズは、データベースのプロビジョニングされたストレージ・サイズの10%です。

    ストレージの自動スケーリングを有効にすると、保証される最小フラッシュ・キャッシュ・サイズは、データベースのプロビジョニングされたベース・ストレージ・サイズまたは割り当てられたストレージ・サイズの10%(いずれか大きい方)になります。

ストレージの縮小

データベースで使用されているストレージが割当て済ストレージよりも大幅に低い場合、縮小操作によって割当て済ストレージが削減されます。

ストレージの割り当てと縮小操作を理解するには、次の点に注意してください:

  • 予約ベース・ストレージ: データベースをプロビジョニングまたはスケーリングするときにデータベースに対して選択するストレージの基本量で、自動スケーリング値は除外されます。 予約ベース・ストレージは、Oracle Cloud Infrastructureコンソールの「ストレージ」フィールドに表示されます。

  • 割当て済ストレージ: すべてのデータベース表領域(サンプル・スキーマ表領域を除く)に物理的に予約されたストレージの量です。 この数には、これらの表領域の空き領域も含まれます。

  • 使用済ストレージ: すべての表領域で実際に使用されるストレージの量です(サンプル・スキーマ表領域を除く)。 使用されているストレージでは、これらの表領域の空き領域は除外されます。 使用済ストレージは、内部的に使用された一時領域を含む、データベース・オブジェクト、表、索引などによって実際に使用されるストレージです。

  • 最大ストレージ: 予約されている最大ストレージです。 ストレージの自動スケーリングが無効になっている場合、最大ストレージは予約ベース・ストレージと等しくなります。 ストレージの自動スケーリングが有効な場合、最大ストレージはベース・ストレージの3倍になります(最大=予約ベースx 3)。

ノート:

「縮小」操作は、Always Free Autonomous Databaseでは使用できません。

ストレージを縮小するには:

  1. 「詳細」ページで、「リソース割当の管理」をクリックします。
  2. 「リソース割当の管理」領域で、「縮小」を選択します。
  3. 「データベースの縮小」ダイアログで「確認」をクリックします。

ノート:

「縮小」操作は長時間実行操作です。

「縮小」操作では、次のすべてを適用する必要があります:

  • 「ストレージの自動スケーリング」を有効にする必要があります。

  • 割当て済ストレージは予約済ベース・ストレージより大きくする必要があります。

  • 1TBに切り上げられた割当て済ストレージは、1TB以上縮小できます。

  • 次の条件が満たされている必要があります:

    割当て済ストレージ - 使用済ストレージ> 100 GB

「縮小」をクリックすると、これらの条件が満たされない場合は、Autonomous Database「処理は使用できません」ダイアログが表示されます。

縮小操作については、次の点に注意してください:

  • 縮小操作は、データベースCPUを使用するalter table... move online操作を実行します。 縮小操作の実行が遅い、または非常に長い時間がかかっている場合、OracleではCPUの数をスケール・アップすることをお薦めします。 詳細については、「CPUまたはストレージ・リソースの追加または自動スケーリングの有効化」を参照してください。

  • Autonomous Databaseインスタンスに次のものが含まれている場合、縮小操作は許可されません:

    • ベクトル索引

    • 「アドバンスト・キューイング」表

    • MEMOPTIMIZE FOR WRITE

  • ROWIDデータ型の列がある場合、これらの列値が指すROWIDは縮小操作中に変更される可能性があります。

  • 次の表を含む表は、縮小操作中にオフラインで移動できます。 これらの表のDML操作は移動中にブロックされる可能性があり、これらの表の表索引は縮小操作が完了するまで使用できなくなります:

    • ビットマップ結合索引を持つ表

    • ネストした表

    • オブジェクト表

    • 不変表

    • ブロックチェーン表

    • ドメイン索引付きのパーティション表

  • データ削除操作の直後に「縮小」操作を実行すると、「縮小」操作が失敗する可能性があります。 これは、Autonomous Databaseがストレージ値を再計算するために必要な遅延が原因である可能性があります。 この場合、Oracleでは、「縮小」操作を再試行することをお薦めします(つまり、ストレージの削除および関連するストレージ使用状況の更新が完了するまで数分待ってから、「縮小」操作を再度実行することをお薦めします)。