機械翻訳について

Autonomous Database on Exadata Cloud@Customerの新機能

次に、注目に値するAutonomous Database on Exadata Cloud@Customerの追加と拡張機能の概要を示します。

Autonomous Database on Dedicated Exadata Infrastructureでの23aiデータベース・サポート

Oracle Public CloudおよびExadata Cloud@Customerデプロイメントで23ai Autonomous Database on Dedicated Exadata Infrastructureをプロビジョニングできます。これにより、Oracle Database 23aiが提供するすべての新機能を利用できます。

23aiデータベースは現在、次の制限付きでサポートされています:

  • 23aiデータベースは、適切なタグを使用して、23aiサポートの起動後または起動後に作成されたAutonomous Exadata VMクラスタ(AVMC)にのみ作成できます。 詳細は「23aiデータベース・ソフトウェア・バージョンのタグの要件」を参照してください。
  • 23aiソフトウェア・バージョンのAutonomous Databasesは、19cバージョンおよびその逆のAutonomous Databaseにクローニングできません。

Autonomous Database on Dedicated Exadata Infrastructureから別のAutonomous Databaseへのデータベース・リンクのサポート

DBMS_CLOUD_ADMINパッケージのサブプログラムを使用して、Autonomous Database on Dedicated Exadata InfrastructureからターゲットAutonomous DatabaseへのTLSおよび非TLSデータベース・リンクを作成できます。

詳細は、次の記事を参照してください:

Autonomous Database on Dedicated Exadata InfrastructureからOracle Databaseへのデータベース・リンクのサポート

Autonomous Database on Dedicated Exadata Infrastructureから、DBMS_CLOUD_ADMINパッケージ・サブプログラムを使用して、パブリック・エンドポイントまたはプライベート・エンドポイントにあるターゲットOracleデータベースへのデータベース・リンクを作成できます。

詳細は、次の記事を参照してください:

ネットワーク・ファイル・システム(NFS)のNFSv4のサポート

DBMS_CLOUD_ADMINプロシージャを使用して、NFSv4サーバー上の顧客から提供された外部NFSデバイスをAutonomous Databaseにアタッチできます。 アクセスするネットワーク・ファイル・システムのバージョンに応じて、NFSv3とNFSv4の両方がサポートされます。

詳細は、次のドキュメントを参照してください。

Amazon S3の事前署名済URL

事前署名済URLは、資格証明を作成せずに、Amazon Simple Storage ServiceのファイルにアクセスするためのURLを取得するDBMS_CLOUDプロシージャで使用できます。

詳細については、「Amazon S3互換URI形式」を参照してください。

運用上の問題およびお知らせの顧客担当者の表示および管理

顧客コンタクトが設定されると、Oracleは、お知らせ、運用通知および計画外メンテナンス通知を指定されたEメール・アドレスに送信します。

Autonomous Databasesのプロビジョニング中に電子メール・コンタクトを追加できます。 Oracle Cloud Infrastructureコンソールを使用して、既存のAutonomous Databaseの顧客コンタクトを表示および変更することもできます。

詳細については、「Autonomous Databaseの顧客担当者の管理」を参照してください。

DBMS_CLOUD_PIPELINEを使用した、クラウド内のデータのロードおよびエクスポート用のデータ・パイプラインの作成

DBMS_CLOUD_PIPELINEを使用して、クラウド内のデータをロードおよびエクスポートするためのデータ・パイプラインを作成できます。 このパッケージは、データベースへのオブジェクト・ストア内のファイルの継続的な増分データ・ロード、およびタイムスタンプ列に基づくデータベースからオブジェクト・ストアへの表データまたは問合せ結果の継続的な増分エクスポートをサポートします。

詳細については、「DBMS_CLOUD_PIPELINEパッケージ」を参照してください。

Select AIを使用した自然言語プロンプトからのSQLの生成

Autonomous Databaseは、次のようなAIサービス・プロバイダと対話できます: OpenAIおよびCohereAIは、Large Language Models (LLM)を使用するOracle Databaseから生成AI機能へのアクセスを提供します。 LLMがOracle Databaseと連携する1つの方法は、データベースとの通信を可能にする自然言語プロンプトからSQLを生成することです。

詳細については、「Select AIを使用した自然言語プロンプトからのSQLの生成」を参照してください。

Autonomous Databaseまたはスキーマで作成されたAIプロファイルとその属性のリストを取得するには、DBMS_CLOUD_AIビューを使用します。

詳細については、「DBMS_CLOUD_AIビュー」を参照してください。

無料の開発者データベース・インスタンスのプロビジョニング

専用Exadata InfrastructureまたはExadata Cloud@CustomerのいずれかでOracle Exadataデータベース・サービスまたはAutonomous Databaseをサブスクライブしたお客様は、Oracle Autonomous Database for Developersインスタンスを作成して使用できます。

Autonomous Database for Developersインスタンスは、開発者が新しいアプリケーションのビルドおよびテストに使用できる無料のAutonomous Databasesです。

Autonomous Database for Developersインスタンスを使用すると、新しいAutonomous Database機能を無料で試して、進行中の開発プロジェクトまたは新しい開発プロジェクトに適用できます。 開発者データベースはリソースに制限されているため、大規模なテストおよび本番デプロイメントには適していません。 より多くのコンピュート・リソースまたはストレージ・リソースが必要な場合は、開発者データベースを通常のAutonomous Databaseにクローニングすることで、有料データベース・ライセンスに移行できます。

自動バックアップの無効化および有効化

デフォルトでは、自動バックアップはAutonomous Container Database (ACD)に対して有効です。 ただし、ACDのプロビジョニング中にこれらを無効にして、後でいつでも有効にできるようになりました。 自動バックアップを有効にした後は、ACDに対して無効にできません。 バックアップのバックアップ保存期間は、7日から95日の間に設定できます。

Autonomous Exadata VMクラスタをスケール・アップまたはスケール・ダウンする機能

リソースは、Autonomous Exadata VMクラスタ(AVMC)に追加または削除できます。 これは、Autonomous Exadata VMクラスタの垂直スケーリングと呼ばれます。

この機能を使用すると、次のリソースを変更して、AVMCをスケール・アップまたはスケール・ダウンできます:

  • VM当たりのCPU数
  • Autonomous Container Databasesの数
  • データベース・ストレージ

Autonomous Container Database (ACD)のDSTタイムゾーン・ファイルの更新

Autonomous Container Database (ACD)のプロビジョニング中または既存のACDに対して、タイムゾーン・ファイル更新を四半期ごとの自動メンテナンス・パッチとともに含めるか除外するかを選択できるようになりました。

タイムゾーン・ファイルを更新するには、ACDおよび関連するAutonomous Databasesの完全な停止時間が必要です。 ダウンタイムは、タイムゾーンに依存するデータの量に依存します。

また、オンデマンド・メンテナンスをスケジュールして、RU (リリース更新)をタイムゾーン・ファイルとともに更新したり、ACDのタイムゾーン・ファイルのみを更新することもできます。

Autonomous Container Databaseを更新するローリングおよび非ローリング・メンテナンス・メソッド

四半期ごとの自動メンテナンス・パッチを適用するために、ローリング・メンテナンス・メソッドまたは非ローリング・メンテナンス・メソッドを選択できるようになりました。 メンテナンス・メソッドは、Autonomous Container Database (ACD)のプロビジョニング中または既存のACDに対して構成できます。 非ローリング・メンテナンス・メソッドでは、完全なシステム・ダウンタイムが発生します。

リソース使用量データの対話型ビジュアライゼーション

Autonomous Exadata VMクラスタ(AVMC)およびAutonomous Container Databases (ACD)全体のExadataリソースの割当ておよび使用状況を、Oracle Cloud Infrastructure (OCI)コンソールの粒度および新しいビジュアルがリアルタイムで拡張されて監視および追跡できます。

このリリースでは、OCIコンソールの詳細ページから、AVMCおよびACDレベルでのコンピュートおよびストレージ・リソースの割当てと使用状況を包括的かつ明確に把握できます。 選択した内容に応じて、グラフィカル・ビューまたは表ビューでこの情報を表示できます。

これらの詳細を理解して知ることは、Autonomous Databasesへのリソース割当てを最適化し、容量ニーズを効率的に予測するのに役立ちます。

ECPU請求モデルおよびCPU割当て

この機能改善により、Autonomous Databaseリソースの構成中に、ECPUまたはOCPUのコンピュート・モデルのいずれかを選択できます。

AVMの作成時に、ECPUまたはOCPUを使用してAVMにCPUを割り当てるオプションがあります。 マルチVMがサポートされているADB-C@Cでは、サイズ設定ウィジェットでノード当たりのECPU数およびECPU当たりのメモリーを割り当てることで、AVMのサイズ設定もできます。 ACDおよびADBは、親AVMからCPUタイプを継承します。 たとえば、AVMがOCPUを使用して構成されている場合、そのAVMのACDおよびADBリソースの使用は、Total/Available/Reclaimable/Provisionable OCPUなどのOCPUを使用して追跡されます。 AVM内でADB CPUタイプが混在することはありません。

  • ECPU : ECPUは、コンピュート・リソースの抽象化されたメジャーです。 ECPUは、コンピュート・サーバーとストレージ・サーバーのプールから柔軟に割り当てられるコアの数に基づきます。

    新しいデータベースのプロビジョニング中、既存のデータベースのクローニング中、および既存のデータベースのCPUリソースのスケール・アップまたはスケール・ダウン中:

    • CPU数のデフォルトは2 ECPUです。
    • 2つ以上のECPUを必要とするデータベースの場合、割り当てられるECPUの数を1単位で指定する必要があります。
    • CPUのオーバー・プロビジョニングは、ECPUではサポートされていません。 これは、すべてのADB-C@Cワークロードに適用されます。
  • OCPU: OCPUは、コンピュート・リソースの物理メジャーです。 OCPUは、ハイパー・スレッドが有効なプロセッサの物理コアに基づきます。

    新しいデータベースのプロビジョニング中、既存のデータベースのクローニング中、および既存のデータベースのCPUリソースのスケール・アップまたはスケール・ダウン中:

    • CPU数のデフォルトは1 OCPUです。
    • OCPU全体が不要なデータベースの場合、0.1のOCPU数を0.9に、0.1のOCPU単位で割り当てることができます。 これにより、システム・レベルでCPUを過剰にプロビジョニングし、各インフラストラクチャ・インスタンスでさらに多くのデータベースを実行できます。
    • 2つ以上のOCPUを必要とするデータベースの場合、割り当てられたコアの数を整数として指定する必要があります。 たとえば、3.5 OCPUをデータベースに割り当てることはできません。 3を超えると、次に使用可能なOCPUの数は4です。

X10Mシステム・サポート

Exadata Cloud@Customer上のAutonomous Databaseは、X10Mシステムをサポートするように拡張されました。

インメモリー列ストアのサポート

インメモリー列ストア(IM列ストア)では、高速スキャン用に最適化された列形式を使用して、表およびパーティションがメモリーに格納されます。 Oracle Databaseでは、高機能なアーキテクチャを使用して、列形式と行形式で同時にデータを管理します。

IM列ストアを有効にすると、SGAはデータを別のロケーションで管理: InMemory領域およびデータベース・バッファ・キャッシュ。 詳細は、「インメモリー列ストアのアーキテクチャ」を参照してください。

この機能改善により、次のことが可能です:

  • 4つ以上のOCPUが割り当てられているかぎり、既存のADBでのIM列ストアの作成中または有効化/無効化中にIM列ストアを有効にするか、停止時間なしで再起動します。
  • 5%から70%のメモリー比率を選択し、停止時間なしで動的に調整します。
  • 新しいオブジェクトを変更または作成し、IM列ストアに格納するように指定します。
  • インメモリーを実行しているADBのOCPUを手動でスケール・アップまたはスケール・ダウンします。 インメモリー・サイズは指定されたパーセンテージに従って調整され、ADBの再起動は不要です

インメモリー初期化パラメータ

IM列ストアの動作を制御するいくつかの初期化パラメータを示します。

  • INMEMORY_QUERY: インメモリー問合せを許可するかどうかを指定します。

  • OPTIMIZER_INMEMORY_AWARE: データベース・インメモリーのオプティマイザ・コスト・モデルの拡張を制御します。
  • INMEMORY_OPTIMIZED_ARITHMETIC: NUMBER列がインメモリー最適化形式で格納されるかどうかを制御します。

詳細は、次を参照してください。

  • Oracle® Databaseインメモリー・ガイドインメモリー初期化パラメータ
  • Oracle® Databaseリファレンス初期化パラメータ
REST APIエンドポイント 説明
CreateAutonomousDatabase 新しいAutonomous Databaseを作成します。
UpdateAutonomousDatabase 指定されたAutonomous Databaseの1つ以上の属性を更新します。 更新可能な属性の完全なリストについては、UpdateAutonomousDatabaseDetailsリファレンスを参照してください。
GetAutonomousDatabase 指定されたAutonomous Databaseの詳細を取得します。
ListAutonomousDatabases 指定した問合せパラメータに基づいて、Autonomous Databasesのリストを取得します。

Autonomous Data Guard Associationsの作成およびコントロール・プレーン・リージョン間のAutonomous Databaseのクローニング

テナンシ内のリージョンにまたがるData Guard関連付けを作成します。 これは、自然災害からデータを保護するための効果的な障害リカバリ計画を実装するのに役立ちます。

この機能改善により、次のことが可能です:

  • 2つの異なるコントロール・プレーン・リージョンのAutonomous Container Databases間のAutonomous Data Guard関連付けの作成
  • リージョン全体にわたってAutonomous Databasesをクローニングします。たとえば、リージョンAのAutonomous Container DatabaseからリージョンBのAutonomous Container DatabaseにAutonomous Databaseをクローニング

ポリシー・ステートメントを使用したコンパートメント割当て制限の設定

この機能改善により、次のことが可能です:

  • Exadata Cloud@CustomerのOracle Autonomous DatabaseのOCIコンソールでテナンシの制限、割当ておよび使用状況を表示
  • ポリシー・ステートメントを使用したコンパートメント割当て制限の設定

Oracle Autonomous Database on Dedicated Exadata Infrastructureでのベース・シェイプのサポート

Oracle Autonomous Database on Dedicated Exadata Infrastructureには、様々なサイズのワークロードをサポートするために、様々なインフラストラクチャ・シェイプが用意されています。 このリリースでは、ベース・シェイプをサポートするようにAutonomous Database on Dedicated Exadata Infrastructureの機能が拡張されました。

Bring Your Own Certificates (BYOC)

この機能を使用すると、AVMCリソースのセキュリティ証明書をローテーションする際に、CA署名サーバー側のOracle REST Data Services (ORDS)またはSecure Socket Layer (SSL)証明書を使用できます。

次のシードおよびローテーション・オプションを使用して、データベース証明書とORDS SSL証明書の両方をシードおよびローテーションするメソッドを選択します。
  • サービス提供のデフォルトの自己署名証明書を選択します(デフォルト・オプション)。
  • OCI証明書サービスと統合して、CA、CAバンドルおよび証明書を取得します。

Kerberosを使用したAutonomous Databaseユーザーの認証

この機能拡張により、Kerberosを使用して、ユーザー管理用に選択したディレクトリ・サービスと一元的にデータベース・ユーザーを認証できます。

長期バックアップ

この機能改善により、定義されたACD保存期間外に存在するオンデマンド・バックアップを取得できます。 90日から10年の範囲では、任意の日数、月数または年数を指定できます。

  • Data Guard環境では、アクションが開始されたプライマリ・データベースまたはスタンバイ・データベースで長期的なバックアップが実行されます。 そのため、必要に応じて、プライマリ・データベースとスタンバイ・データベースをバックアップするために2つの個別のリクエストを行う必要があります。
  • 長期バックアップは、ADBが実行中または停止状態(終了していない状態)で使用可能であれば使用できます。
  • 長期バックアップのみを使用して新しいデータベースを作成できます。 インプレース/PITRリストアには使用できません。
  • 長期バックアップには、同じまたは異なるADB-Dインフラストラクチャでデータベースをリストアするために必要なすべてのデータファイル、アーカイブ・ログ、制御ファイルおよびサーバー・パラメータ・ファイル(SPFILE)が含まれます。
  • 必要に応じて、長期バックアップを削除できます。
  • 長期バックアップからADBを作成すると、常に現在サポートされているバージョン(ターゲットACDバージョン)にアップグレードされます。

    たとえば、5-year-oldバックアップに使用可能な19cがない場合、Oracleによってデータベースが23cにアップグレードされます。 ただし、このように作成されるADBは、データが使用可能であるためアプリケーションが動作することを保証しません。

スタックとして保存

スタックは、特定のTerraform構成に対応するOracle Cloud Infrastructureリソースのコレクションです。 各スタックは、指定したコンパートメント内の単一のリージョンに存在しますが、特定のスタック上のリソースを複数のリージョンにデプロイできます。 詳細は、stackを参照してください。

この機能拡張により、Exadata Infrastructure、VMクラスタ、Autonomous VMクラスタ、Autonomous Container DatabaseおよびAutonomous Databaseのプロビジョニング中に、リソース構成をスタックとして保存できます。 スタックを使用して、リソース・マネージャ・サービスを介してリソースをインストール、構成および管理します。 リソース・マネージャで使用されるTerraform構成の要件および推奨事項については、「Terraformリソース・マネージャの構成」を参照してください。 スタックで定義されたリソースをプロビジョニングするには、「適用ジョブの作成」で説明されているステップに従います。

Autonomous Exadata VMクラスタ・ノードのサブセット化

Autonomous Exadata VM Clusterノードのサブセット化を使用すると、データベース・サーバーのサブセットを新しいAutonomous Exadata VMクラスタに割り当てて、コンピュート(CPU、メモリー、ローカル・ストレージ)リソースの割当ての柔軟性を最大限に高めることができます。

Autonomous Exadata VM Clusterノードのサブセット化を使用すると、次のことができます:
  • より小さいAutonomous Exadata VM Clusterを作成して、リソースとスケーラビリティの要件が低いデータベースをホストしたり、残りのワークロードから分離する必要がある少数のデータベースをホストします。

Autonomous Exadata VM Clusterノードのサブセット化に役立つ次のポイントを確認してください。

  • Autonomous Exadata VM Clusterノードのサブセット化機能は、Gen2 Exadata Cloud@Customerサービスの新しいAutonomous Exadata VMクラスタで使用できます。
  • Autonomous Exadata VMクラスタ全体のすべてのVMは、クラスタのプロビジョニング中にVMが作成されたか、既存のAutonomous Exadata VMクラスタを拡張して後で追加されたかに関係なく、VMごとに同じリソース割当てになります。
  • Autonomous Exadata VMクラスタには、ノードのサブセット化機能がある場合でも、少なくとも2つのVMが必要です。 現在、単一のVMによるクラスタはサポートされていません。
  • 各Autonomous Exadata VM Clusterネットワークには、インフラストラクチャ内のすべてのDB ServerのIPアドレスが事前にプロビジョニングされています。 1つのクラスタ・ネットワークは単一のAutonomous Exadata VMクラスタでのみ使用でき、IPアドレスが他のクラスタ・ネットワークと重複しないように検証されます。

インフラストラクチャ全体の最大クラスタ数は、DBサーバーごとに使用可能なリソースによって異なり、DBサーバーごとの最大VM制限の対象となります。

Autonomous Container Databases (ACD)のプロビジョニング中に特定のOracle Databaseバージョンを選択

Autonomous Container Database (ACD)には最新のOracle Databaseバージョンがプロビジョニングされており、四半期ごとに本番修正および最新のリリース更新(RU)で常にパッチが適用されます。 ACDをプロビジョニングすると、本番環境にプッシュされる新しいバージョン更新がデフォルトになります。 ACDのプロビジョニング中は、データベース・バージョンを選択できません。

この機能改善により、ACDのプロビジョニング中に、選択したデータベース・バージョンを選択できます。

また、以前のOracle Databaseバージョンを使用してACDを作成できます。 ACDの作成でサポートされている最新のデータベース・バージョンが19.15の場合は、Oracle Databaseバージョン19.14を選択できます。

この機能拡張では、データベース・デプロイメント用のOracleアプリケーション名タグも実装されます。 OracleアプリケーションのOracle Databaseデプロイメントには、特定のデータベース・バージョンが必要な場合があります。 Autonomous Databaseのデプロイ中にOracle-ApplicationNameタグ・ネームスペースに適切なアプリケーション・タグ・キーを設定すると、その特定のアプリケーションに対して動作保証されたデータベース・バージョンがデプロイされます。

Autonomous Data Guardの拡張機能

これらの拡張機能を使用すると、次のことができます:

  • ACDで保護モードを「最大パフォーマンス」から「最大可用性」に、またはその逆に変更します。
  • ファスト・スタート・フェイルオーバー(FSFO)のラグ制限を1ずつ変更します。 最小: 5および最大: 3600秒。 デフォルト: 30秒
  • フィジカル・スタンバイからスナップショット・スタンバイへの変換(またはその逆)

デフォルト以外のSCANリスナー・ポートの構成

この機能では、次のことが可能です:
  • 使用可能なポートの範囲から、Transport Layer Security (TLS)およびTLS以外用の単一クライアント・アクセス名(SCAN)リスナー・ポートを選択します。 TLSの場合、デフォルトは2484で、TLS以外の場合は1521です。
  • データベース・クライアント接続のための一方向TLSと相互TLS (mTLS)のいずれかを選択します。 ORDSは常に一方向TLSです。

同じリージョン内のExadata Infrastructure間でのAutonomous Databaseのクローニング

この機能改善により、あるExadata InfrastructureのACDから同じリージョン内の別のExadata InfrastructureのACDにADBをクローニングできます。

文字セット選択

この機能拡張により、ADBの作成時にデータベースの文字セットと各国語文字セットを指定できます。

  • ADBの作成時に、サポートされている文字セットのみを選択できます。 サポートされているキャラクタ・セットの完全なリストを取得するには、ListAutonomousDatabaseCharacterSets APIを使用します。
  • ADBの作成後に文字セットを変更することはできません。
  • ADBの作成時にのみ文字セットを設定できます。 キャラクタ・セットの選択は、クローニング(メタまたはフル)またはバックアップからの作成ではサポートされていません。
  • CDBでは、データベース文字セットにAL32UTF8、各国語文字セットにAL16UTF16が引き続き使用されます。
  • ACD内の各ADBは、異なる組合せのデータベース/各国語文字セットを持つことができます。

Autonomous Databaseの拡張リソース・トラッキング

再利用可能なOCPUの場所を特定して、新しいデータベース・リソースを作成したり、特定のしきい値に達したときにスケーリングを自動化するために再利用します。

Exadata Infrastructureリソースに複数のAVMCを作成できます。 AVMCリソースのプロビジョニング中に割り当てるOCPUは、そのAutonomous Databasesで使用可能な「総OCPU」になります。 複数のAVMCを作成すると、各AVMCはOCPUの合計に対して独自の値を持つことができます。

AVMCまたはACDレベルで、データベースの作成に使用できるOCPUの合計数を「使用可能なOCPU」と呼びます。

この機能拡張により、リソース使用のトラッキングが向上します:
  • 再利用可能OCPU:

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

  • プロビジョニング可能なOCPUによる障害なしADBプロビジョニング:

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

    コンソールで、Autonomous Databaseをプロビジョニングまたはスケーリングしようとしたときに、OCPU数がプロビジョニング可能なOCPUのリストに対して検証され、値がプロビジョニング可能でない場合は、直近のプロビジョニング可能なOCPUの値が2つ提供されます。 または、Autonomous Exadata VMクラスタのプロビジョニング可能なOCPU値の完全なリストを表示する場合は、次のAPIを使用できます:

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

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

自律型VMクラスタ

フリート管理者として、次のことを識別できます:

  • 総OCPU: VMクラスタに割り当てられたCPUコアの数。
  • Exadata Storage (TB): VMクラスタに割り当てられたストレージ(TB単位)。
  • 合計Autonomous Databaseストレージ(TB): Autonomous VMクラスタに割り当てられた合計Autonomous Databaseストレージ・ストレージ。
  • 使用可能なAutonomous Databaseストレージ(TB): Autonomous VMクラスタでAutonomous Databasesを作成するために使用できるストレージ
  • 合計メモリー: VMクラスタに割り当てられたメモリー(GB)。
  • 合計ローカル・ストレージ(GB): Exadata Infrastructureの合計ローカル・ストレージ。
  • 使用可能なOCPU: ADBへの割当てに使用できるCPUコア。
  • 再利用可能なOCPU: Autonomous VMクラスタ内のすべてのACD内のすべての再利用可能なOCPUの合計。
  • 使用可能なACD: 使用可能なリソースを使用してAVMで作成できるACDの数。
  • ACD合計: AVMで顧客が作成するACDの数。
  • 再利用可能なOCPUが大量に存在し、必要に応じて再起動するACD。

Autonomous Container Database

データベース管理者として、次のことを識別できます:

  • 総OCPU: VMクラスタに割り当てられたCPUコアの数。
  • 使用可能なOCPU: Autonomous VMクラスタで使用可能なOCPUの合計+同じACD内の再生可能OCPU。
  • 再利用可能なOCPU: Autonomous Databaseが終了またはスケール・ダウンした場合、割り当てられたOCPUの数は、デプロイメント全体の親AVMCレベルで使用可能なOCPUにすぐに戻されません。 親コンテナ・データベースが再起動されるまで、親コンテナ・データベースで使用可能なOCPUの数に含まれ続けます。 これらのOCPUは、再生可能なOCPUと呼ばれます。 親AVMCレベルでの再生可能OCPUは、すべてのACDの再利用可能なOCPUの合計です。 ACDが再起動すると、すべての再利用可能なOCPUが親AVMCレベルの使用可能なOCPUに戻されます。

ノート:

2 OCPUがVMクラスタまたはExadata Infrastructureで使用できない場合は、ACDを作成できません。

Autonomous Database

データベース管理者として、ADBのプロビジョニングまたはスケーリングに使用できるOCPU数を識別できます。

  • OCPU: データベースで使用可能にするOCPUコアの数。
  • ストレージ: データベースにデータを格納するために使用可能なストレージの数量(テラバイト)。
  • ADBのプロビジョニング中に、サービスが既存のACDでプロビジョニングできないOCPU数を指定した場合、サービスによってエラー・メッセージが表示され、指定した値に近い距離で2つの値が提示されます。

    たとえば、使用可能なOCPUが20個あるクォータ・ラックExadata Infrastructureに15 OCPUのADBを作成するとします。 ただし、各ノードで使用できるOCPUは10個のみです。 この場合、15 OCPUが16 OCPUの分割しきい値未満であるため、サービスはADBをプロビジョニングできません。 したがって、最も近い値は17と18です。

  • ADBのスケーリング中に、サービスがADBのスケーリングに使用できないOCPU数を指定すると、サービスによってエラー・メッセージが表示され、指定した値に近い値に2つの値が提示されます。

表6-1 リソース使用状況を追跡および管理するためのREST APIエンドポイント

REST APIエンドポイント 説明

GetAutonomousVmCluster

使用可能なOCPU、再利用可能なOCPU、使用可能なAutonomous Databaseストレージおよび使用可能なACDのリストを表示します。

GetAutonomousContainerDatabase

  • 使用可能なOCPU、OCPU合計および再利用可能なOCPUのリストを表示します。
  • プロビジョニング可能なOCPUの配列を表示します。

GetAutonomousDatabase

スケーラブルなOCPUの配列を表示します。

長いデータベース名

データベース名の長さが14文字から30文字に拡張されました。 データベースの識別に使用できるわかりやすい名前を指定します。 データベース名に使用できるのは、許可された文字のみです。

データベース名を選択する場合は、次のガイドラインを確認してください:

  • 最大30文字
  • 英数字のみを含む
  • 英字で始める
  • スペースは使用できません

バックアップからの新しいAutonomous Databaseインスタンスの作成

Autonomous Database (ADB)バックアップを、既存または異なるAutonomous Exadata Cloud@Customerシステムで実行されている同じまたは別のAutonomous Virtual Machine (AVM)上のAutonomous Container Database (ACD)にリストアします。

前提条件および制限事項

  • 顧客管理キーを使用している場合、ターゲットAVM/ACDでは、キーのソースOracle Key Vault (OKV)へのアクセスが必要になります。
  • リストアを有効にするには、ターゲットAVMがソースのバックアップ保存先にアクセスできる必要があります。
  • データベース・クローンの作成には、「フル・クローン」オプションのみを使用できます。
  • ディスク・ベースのバックアップを使用してバックアップからADBインスタンスを作成することはできません。
  • ターゲットACDはソースと同じかそれ以上のバージョンである必要があります。
  • AVMごとに1つのADBリストア。 制限はターゲットAVMにのみ適用されます。

複数のAutonomous VMクラスタのサポート

マルチVMクラスタは、Autonomous VMクラスタと非Autonomous VMクラスタがExadata Infrastructureに共存できる異機種コンピューティング環境をサポートしています。

複数のVMクラスタをサポートすることで、次のことができます:
  • Exadata Infrastructureでの複数のAutonomous VMクラスタの作成
  • Autonomous VMクラスタごとに個別のメンテナンス実行をスケジュール
  • Autonomous Databaseごとに異なるライセンス・モデルを使用

スタンバイとの自動フェイルオーバーAutonomous Container Database

ファスト・スタート・フェイルオーバー(FSFO)では、プライマリAutonomous Container Databaseの障害が自動的に検出され、指定されたスタンバイAutonomous Container Databaseにフェイルオーバーされます。

Autonomous Data Guardの構成時は、自動フェイルオーバーはオプションです。 Autonomous Data Guardを構成した後、自動フェイルオーバーを有効または無効にできます。

X9M-2システム・サポート

Oracle Exadata Cloud@Customerには、様々なサイズのワークロードをサポートするために、様々なインフラストラクチャ・シェイプが用意されています。 このリリースでは、Oracle Exadata Cloud@Customerの機能がX9M-2システムをサポートするように拡張されています。

詳細は、「使用可能なExadata Infrastructureハードウェア・シェイプ」を参照してください。

小数OCPUおよびGBストレージ

0.1から0.9 OCPUまでの分数の単位を使用してAutonomous Databasesを作成し、32 GBからExadataシェイプで使用可能な最大ストレージまでのサイズを指定します。

Autonomous Data GuardでAutonomous DatabaseとOracle Key Vault (OKV)の統合を実現

オンプレミスのOracle Key Vault (OKV)をAutonomous Data Guardと統合することで、Exadata Cloud@Customer上のAutonomous Databasesが可能となり、Oracle Key Vaultに格納されている顧客管理キーを使用して重要なデータを保護します。

インフラストラクチャのパッチ適用

ADB専用メンテナンスでは、Exadata Infrastructure(EI) Autonomous VM ClusterおよびAutonomous Container Database (ACD)にパッチを適用する必要があります。

Autonomous Data Guard対応Autonomous Databasesへのアクセスを制限するアクセス制御リスト(ACL)

アクセス制御リスト(ACL)は、特定のIPアドレスを持つクライアントのみがデータベースに接続できるようにすることで、データベースに追加の保護を提供します。 IPアドレスは個別に追加することも、CIDRブロックに追加することもできます。

ADB-D on Exadata Cloud@Customer: Autonomous Databaseのメトリックを使用してパフォーマンスをモニター

メトリック、アラームおよび通知を使用して、Autonomous Databasesのヘルス、容量およびパフォーマンスを監視できます。 Oracle Cloud InfrastructureコンソールまたはモニタリングAPIを使用して、メトリックを表示できます。

Exadata Cloud@Customer上のADB-D: Autonomous Data Guard

専用Exadataインフラストラクチャ上のAutonomous Container DatabaseでAutonomous Data Guardを有効にすると、データ保護、高可用性およびプライマリ・データベースの障害リカバリを容易にするスタンバイ(ピア) Autonomous Container Databaseが作成されます。

Autonomous Databasesへのアクセスを制限するアクセス制御リスト(ACL)

アクセス制御リスト(ACL)は、特定のIPアドレスを持つクライアントのみがデータベースに接続できるようにすることで、データベースに追加の保護を提供します。 IPアドレスは個別に追加することも、CIDRブロックに追加することもできます。

Oracle Key Vault (OKV)統合

オンプレミスのOracle Key Vault (OKV)をExadata Cloud@Customer上のAutonomous Databaseと統合して、クリティカル・データをオンプレミスで保護します。

Oracle Key Vaultの統合により、暗号化キーを完全に制御し、外部の一元化されたキー管理デバイスに安全に格納できます。

X8M-2システム・サポート

Autonomous Database OCPU使用率の秒単位の請求

Oracle Exadata Database Service on Cloud@Customer上のOracle Autonomous Database