Oracle Exadata Database Service on Dedicated Infrastructureの新機能

Exadata Cloud Infrastructureには常に新しい機能が追加されています。

ExaDB-DとExaDB-XS間のクロスサービス相互運用性: Data Guard、バックアップおよびリストア

クロスサービスのOracle Data Guardデプロイメント・サポートをお知らせします。クロスサービス・デプロイメントでは、Exadata Database Service on Dedicated Infrastructure (ExaDB-D)とExadata Database Service on Exascale Infrastructure (ExaDB-XS)の2つのサービス間でプライマリ・データベースとセカンダリ・データベースを設定します。クロスサービスOracle Data Guardをデプロイする機能により、可用性が向上します。

詳細は、「ExaDB-DとExaDB-XS間のクロスサービス相互運用性: Data Guard、バックアップおよびリストア」を参照してください。

シリアル・コンソール機能の拡張

これらの新機能は次のとおりです。

  • OCI Cloud Shellを介したシリアル・コンソールへのアクセス
  • コンソールの履歴

この機能拡張により、OCI Cloud Shellを介して仮想マシンのシリアル・コンソールに簡単に接続して、修正アクションを実行できます。また、シリアル・コンソール履歴を表示して、すべてのユーザーがシリアル・コンソールで実行した以前のアクティビティを確認および監査できます。

ノート

  • クラウド・シェルを使用して複数のDBノードに同時に接続することはできません。たとえば、DBnode1へのオープン接続があり、DBnode2に接続する場合は、最初にアクティブなクラウド・シェルをDBnode1から終了してから、DBnode2への接続を確立する必要があります。
  • シリアル・コンソールへのクラウド・シェル・アクセスには、クラウド・シェルの適切なIAM権限が必要です。詳細は、OCI Cloud Shellのドキュメントを参照してください。

選択したOCIリージョンの新規テナンシのバックアップ保存先の変更(2025年8月6日有効)

2025年8月6日以降、Autonomous Recovery Serviceは、フランクフルト(FRA)、フェニックス(PHX)および東京(NRT)のOCIリージョンで新しく作成されたテナンシの自動バックアップ構成中に排他的なバックアップ保存先になりました。

詳細は、OCIコンソールを使用した自動バックアップおよびスタンドアロン・バックアップの有効化時のバックアップ先の動作を参照してください。

Exadataシステム・ソフトウェア25.1.0.0.0

Exadata System Softwareリリース25.1は、2024年12月から提供されています。新しいExadata X11Mインフラストラクチャ・デプロイメントには、Exadata System Software 25.1が含まれます。このリリースは、2025年5月から四半期メンテナンスの一部としてExadata Cloud Infrastructureに適用されます。これは、Exadata System Software 24ai以前のリリースで導入された機能に基づいています。このリリースでは、次のようないくつかの主要なイノベーションが導入されています。

ゲストOS用のExadata Software 25.1も利用でき、お客様がゲスト・仮想マシンに適用できます。

さらに学習するには、Exadataシステム・ソフトウェア・リリース25.1のドキュメントを参照してください。

更新手順については、My Oracle Support Note 3021895.1— Exadata System Software 25.1.0.0.0 Updateを参照してください。

ノート

Exadata Software 25.1の一部の機能は、クラウド・サービスで使用できない場合があります。

データベース・ワークフロー全体でのタグ付けサポートの拡張

以前にデータベースの作成時にサポートされていたタグ付けは、スタンバイ・データベースの作成やバックアップからのデータベースの作成など、追加のワークフローに拡張されました。

Amazon S3によるOracle Database@AWS上のExadata Database ServiceでのOracle管理バックアップのサポート

この機能では、Oracle Database@AWSのお客様に対するExadata Database Serviceの追加バックアップ先としてAmazon S3が導入され、OCI Exadata Database Serviceインタフェースから直接、Oracle管理データベース・バックアップをシームレスにスケジュールおよび管理できます。

詳細は、自動バックアップを参照してください。

Oracle Database@AzureでのExadata Database ServiceのAzure Key Vault統合

Oracle Database@Azure上のExadata Database Serviceでは、データベースの透過的データ暗号化(TDE)キー(マスター暗号化キー(MEK)とも呼ばれる)を、ファイルベースのOracleウォレットまたはOCI Vaultに格納できます。この機能により、Oracle Database@AzureユーザーのExadata Database Serviceで、TDE MEKの管理にAzure Key Vault (AKV)管理対象HSM、AKV PremiumおよびAKV Standardを使用できます。この統合により、アプリケーション、Azureサービスおよびデータベースは、一元化されたキー管理ソリューションを使用して、セキュリティを強化し、キー・ライフサイクル管理を簡素化できます。

事前チェック検証を使用したOracle Data Guard設定

Oracle Data Guardを設定する前に事前チェックを実行できるようになりました。

Data Guard (DG)構成の一部として、サービスは暗黙的な事前チェックを実行しました。この機能拡張により、Data Guard設定に進む前に、明示的な事前チェックを実行して潜在的な問題を識別して対処できるようになりました。

VM Cloud Automation更新のスケジュール

Exadata Database Service on Dedicated Infrastructure(ExaDB-D)でVMクラスタのVM Cloud Automation更新をスケジュールする一般提供(GA)を発表します。

以前は、Oracleはゲスト仮想マシンを中断することなく、これらの更新をバックグラウンドで自動的に適用していました。この新機能により、更新の適用時期を定義し、最初に受け取るクラスタに優先順位を付け、ビジネス・ポリシーに沿った凍結期間を設定して、重要な時間枠中に更新を一時停止できるようになりました。

最新のOracleクラウド機能にアクセスするためには、ゲスト・仮想マシン上のOracle管理エージェントおよびツールに対するクラウド自動化ソフトウェアの更新が不可欠ですが、多くのお客様は、現在のバージョンを中心にスクリプトとワークフローを構築しています。操作の継続性を維持するために、更新をクラスタに適用するタイミングを選択できるようになりました。また、このリリースでは、非本番クラスタの更新を最初にテストする柔軟性も備えており、すべての新しいOracleリリースでスムーズに展開できます。この機能改善により、お客様は次のことが可能になります。

  • 更新のスケジュール:新しい更新をチェックして適用するVMの特定の時間を定義します。
  • 凍結期間中の更新の回避:データベース・アクティビティが多い期間中の更新を防止します。
  • リスクの軽減:既存のスクリプトおよび自動化に対する更新の影響を最小限に抑えます。

重要なOCI REST APIへのアクセスの分類と制御

Oracle API Access Controlを使用すると、様々なデータベース・クラウド・サービスによって公開されるREST APIおよびクラウド・コンソール操作へのアクセスを管理および制限できます。特定のAPIを特権として指定することで、それらのAPIを呼び出す前に、テナンシ内の指定されたグループからの認可を必要とする承認ワークフローを強制できます。

Transparent Data Encryption (TDE)キーを管理するためのExaDB-DとのOracle Key Vault (OKV)統合

Oracle Key Vault (OKV)をOracle Exadata Database Service on Dedicated Infrastructureと統合し、Oracle Key Vaultに格納されている顧客管理キーを使用して、Oracle Transparent Data Encryption (TDE)マスター暗号化キー(MEK)を暗号化します。

OKVサーバーの場所を制御し、ExaDB-Dインスタンスへのネットワーク接続がある任意の場所にデプロイできます。

プロビジョニングされたストレージ・サーバーの削除

プロビジョニングされたストレージ・サーバーは、クラウドExadataインフラストラクチャから削除できます。「プロビジョニングされた」ストレージサーバーは、ディスクグループが構成されたストレージサーバーを指します。ASMに必要な空きディスク・グループの容量を参照し、ストレージ・サーバーの削除後にASMリバランス操作を完了する必要があることに注意してください。

Data Guard、コンテナ・データベース(CDB)およびプラガブル・データベース(PDB)の同時操作をサポートする拡張機能

この機能拡張により、コンテナ・データベース(CDB)およびプラガブル・データベース(PDB)で、Data Guardのアソシエーションおよびアクションとともに同時操作を実行できるようになりました。この改善により、Oracleデータベースの管理の効率性と柔軟性が大幅に向上します。サポートされている同時操作は次のとおりです。

  • コンテナ・データベース(CDB)が更新状態の場合でも、最大10個のPDBを同時に作成または削除します。
  • Data Guard設定が同じOracleホーム内の別のデータベースで実行されている間(またはその逆)にCDBを作成または削除します。
  • Data Guard設定が同じOracleホーム内の別のデータベースで実行されている間(またはその逆)にPDBを作成または削除します。
  • Data Guard設定が同じOracleホーム内の別のデータベースで実行されている間に、Data Guardアクション(スイッチオーバー、フェイルオーバーおよび回復)を実行します。その逆も同様です。
  • 同じOracleホーム内の異なるデータベースでData Guardアクション(スイッチオーバー、フェイルオーバーおよび回復)を同時に実行しながら、CDBを作成または削除します(またはその逆)。
  • 同じOracleホーム内の異なるデータベースでData Guardアクション(スイッチオーバー、フェイルオーバーおよび回復)を同時に実行しながら、PDBを作成または削除します(またはその逆)。
  • 同じOracleホーム内で別のCDBのPDBを同時に作成または削除しながら、CDBを作成または削除します。その逆も同様です。
  • 同じOracleホーム内の異なるデータベースでCDBを同時に作成または削除します。
  • 同じOracleホーム内の異なるデータベースでPDBを同時に作成または削除します。
  • 同じOracleホーム内の異なるデータベースでData Guard設定を同時に実行します。
  • 同じOracleホーム内の異なるデータベースでData Guardアクション(スイッチオーバー、フェイルオーバーおよび回復)を同時に実行します。
  • VMクラスタ・タグを同時に更新しながら、CDB/PDBの作成または削除、Data Guard設定の実行、Data Guardアクション(スイッチオーバー、フェイルオーバーおよび回復)の実行を行います。

二重スタック(IPv4およびIPv6)ネットワーク・サポート

Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)で、IPv4/IPv6デュアルスタック・ネットワーキングを使用してVMクラスタをプロビジョニングできるようになりました。この機能により、組織はIPv4とIPv6の両方を同時に使用できるようになり、コスト効率の高いソリューションを提供して、IPv4アドレスの不足を管理し、規制要件へのコンプライアンスを確保し、将来のスケーラビリティと成長のためにIPv6へのスムーズな移行を促進できます。次のシナリオがサポートされます。

  • クライアントおよびバックアップ・サブネット上の新しいExadata VMクラスタに対するIPv4/IPv6デュアルスタック・サポート。
  • IPv4のみのExadata VMクラスタからデュアル・スタックExadata VMクラスタにデータを移行するようにData Guardを構成します。
  • IPv4アドレスとIPv6アドレスの両方を使用してアプリケーションVIPを構成します。
ノート

デュアル・スタック・ネットワークを構成するための最小要件:
  • Exadataシステム・ソフトウェア24.1.4
  • Oracle DatabaseおよびOracle Grid Infrastructure:
    • 19c -> 19.26
    • 23ai -> 23.7
ノート

Oracle Exadata Database Service on Dedicated Infrastructureでは、GUA、BYOIPおよびULAのIPv6接頭辞がサポートされています。VMクラスタのプロビジョニング中、サブネットにはIPv6接頭辞が1つのみ必要です。ExaDB-Dでは、複数のIPv6接頭辞を持つサブネットはサポートされていません。

詳細は、IPv6アドレスを参照してください。

詳細は、VCNsおよびサブネットの概要およびサブネットへのIPv6接頭辞の追加を参照してください。

長期保存バックアップ(LTR)

Long-Term Retention Backup(LTR)を使用すると、最大10年または短期間でフル・バックアップを格納できるため、コンプライアンス、規制、その他のビジネス要件を満たすためにアーカイブ・データを検索および取得できます。この保存期間中、LTRバックアップをリストアして、新しいデータベース(アウトオブプレース・リストアと呼ばれるプロセス)を作成できます。

四半期ごとのExadataインフラストラクチャ・メンテナンスの計画および実行の拡張

この機能改善により、小規模なメンテナンス期間にあわせて、四半期ごとのインフラストラクチャ更新を柔軟に計画および適用できます。1つのウィンドウですべてのインフラストラクチャ・コンポーネントでメンテナンスを実行するか、複数の小さいウィンドウに分割してビジネス・ニーズに合わせてメンテナンスを実行できます。Oracle Automationは、優先タイム・スロットに基づいて、これらのメンテナンス・ウィンドウ全体で特定のインフラストラクチャ・コンポーネントのメンテナンスを実行し、すべてのコンポーネントにセキュリティおよびコンプライアンスのガイドラインを満たすためにソフトウェア更新が適用されるようにします。

インフラストラクチャ・コンポーネントには次のものがあります。

  • DBサーバー
  • ストレージ・サーバー

VMクラスタ更新操作のきめ細かな権限

この機能拡張により、VMクラスタの更新操作をきめ細かく制御できます。

DBAグループがメモリーまたはCPUのみをスケーリングできるようにしたり、ストレージ管理者グループがローカル/Exadataストレージを管理できるようにしたり、セキュリティ管理者グループがVMクラスタにSSHキーを追加できるようにしたりするなど、VMクラスタ操作に対して詳細な権限を割り当てることができるようになりました。

詳細は、VMクラスタの権限およびAPI操作の詳細を参照してください。

複数のスタンバイ・データベース

この機能拡張により、プライマリ・データベースにリンクされた複数のローカル・スタンバイ・データベースおよびリモート・スタンバイ・データベースを作成および管理できるため、データ保護とディザスタ・リカバリの両方に柔軟に対応できます。ローカル・スタンバイ・データベースはデータ損失の最小化に役立ちますが、リモート・スタンバイ・データベースはリージョンの障害から保護します。この機能拡張により、プライマリ・データベースに対して最大6つのスタンバイ・データベースを作成できます。

一般的なData Guard構成では、2つのスタンバイ・データベースが一般的に使用されます。

  • ローカル・スタンバイ:本番データベースと同じリージョンのスタンバイ・データベースは、フェイルオーバー・シナリオに最適であり、ローカル障害(データベース、クラスタ、可用性ドメインの障害など)のデータ損失はゼロです。この場合、アプリケーションはリモート・リージョンとの通信によるパフォーマンス・オーバーヘッドなしで動作し続けるため、アプリケーションのフェイルオーバーの影響が軽減されます。
  • リモート(リージョン間)スタンバイ:通常、別のリージョンにあるリモート・スタンバイ・データベースは、ディザスタ・リカバリまたは読取り専用問合せ処理のオフロードに使用されます。リモート・スタンバイ・データベースの設定により、リージョンの障害に対するデータ保護が保証されます。

一部のエンタープライズ顧客は、サイト切り替え後の対称性を目指しています。たとえば、リージョン1にはプライマリ・スタンバイとローカル・スタンバイの両方、リージョン2には独自のローカル・スタンバイを持つリモート・スタンバイの両方を使用することをお薦めします。この構成では、3つのスタンバイ・データベースがあります。サイトの切替え後も、新しいプライマリ・リージョンでプライマリ・データベースとローカル・スタンバイをすぐに利用できます。

さらに、お客様は、スナップショット(読取り/書込み)スタンバイ機能を活用して、テスト目的で別のスタンバイ・データベースを追加することで、構成を強化できます。

ノート

別のスタンバイ・データベース(カスケード・スタンバイ)に関連付けられたスタンバイ・データベースの作成はサポートされていません。

X11Mシステム・サポート

Note

This feature is rolled out only to the PHX, IAD, NRT, FRA, LHR, GRU, VCP, KIX, MAD, HYD, SIN, ORD, YYZ, CDG, JED, BOM, JNB, LIN, MXP, and TYO regions.他のリージョンにもフェーズでロールアウトされる予定です。

Oracle Exadata Database Service on Dedicated Infrastructureは、ExadataインフラストラクチャX11Mをサポートするように拡張されました。

Microsoft Entra ID (MS-EI)とOracle Exadata Database Service on Dedicated Infrastructureの統合

Oracle Exadata Database Service on Dedicated Infrastructureは、Microsoft Entra ID (MS-EI)トークンを受け入れてデータベースにアクセスできるようになりました。Azureのユーザーおよびアプリケーションは、MS-EIトークンを使用してデータベースにアクセスできます。

MS-EI統合は、19.17以上のパッチが適用されたデータベースで使用できます。この機能は、Oracle Databaseリリース21cでは使用できません。

MS-EIの構成、データベースの構成およびデータベース・クライアントの構成の詳細は、次を参照してください。

ExaDB-Dのアクセス制御の委任

Oracle Exadata Database Service Dedicatedのお客様は、アクセス制御サービスを委任することで、VMおよびデータベースのメンテナンスおよびサポート・サービスをサブスクライブし、サービス・プロバイダへのアクセスを委任し、サービス・プロバイダがVMおよびデータベース・リソースにアクセスできるタイミングを制御できます。これらのサービス・プロバイダには、Oracleグローバル・サポート、Oracleクラウド・サポートおよびOracleプロフェッショナル・サービスが含まれます。

Data Guardアソシエーション、スイッチオーバーおよびフェイルオーバー操作でのプライマリDBホームとスタンバイDBホームの異なるRU

Oracle Data Guard構成では、両方のデータベース・ホームに同じリリース更新(RU)が適用されるなど、プライマリ・データベースとスタンバイ・データベースを同期状態にすることが一般的です。ただし、特にパッチ適用サイクル中またはテスト目的で、プライマリ・データベース・ホームとスタンバイ・データベース・ホーム間で異なるRUを許可する必要がある場合があります。

Data Guardアソシエーションの作成:

  • プライマリおよびスタンバイのOracle Homesは、同じメジャー・データベース・バージョンである必要があります。
  • プライマリとスタンバイのOracle Homesで異なるRUが実行されている場合、スタンバイがプライマリ・データベースと同じまたはそれ以上のRU上にある場合にのみ、Data Guardアソシエーションを作成できます。
  • プライマリがカスタムDSIまたはOracleイメージで実行されているかどうかに関係なく、スタンバイのホームはカスタムDSIまたはOracleイメージにできます。

スイッチオーバーまたはフェイルオーバー・データベース:プライマリおよびスタンバイのOracle Homesは、任意のメジャー・データベース・バージョンまたは異なるRUの実行が可能です。

データベースのアップグレード:プライマリおよびスタンバイのOracle Homesでは、異なるメジャー・データベース・バージョンを使用できます。

パッチ・データベース:プライマリおよびスタンバイのOracle Homesで異なるRUが実行されている場合、スタンバイはプライマリ・データベースよりも上位のRUにパッチを適用できます。

Oracle Cloud Infrastructureゼロ・トラスト・パケット・ルーティングによる機密データの保護

データ対応のクラウド・セキュリティ制御であるOracle Cloud Infrastructure Zero Trust Packet Routing (ZPR)を使用すると、不正なアクセスや抽出からデータを保護できます。

KMSベースのコンテナ・データベース(CDB)およびプラガブル・データベース(PDB)への新しいキー・バージョンの割当て

BYOK (Bring-Your-Own-Key)を使用すると、ユーザーはボールト・サービスでキーを内部的に生成するのではなく、独自のキーまたはキー・バージョンをインポートできます。BYOKを使用すると、ユーザーはOCI Vaultサービスにキーをインポートし、インポートしたキーをデータベース暗号化に使用できます。現在、ExaDB-D顧客がBYOKを使用して新しいデータベース(CDB)を作成すると、顧客のキーはCDBにのみ使用され、システム生成のキー・バージョンはPDBに割り当てられます。ユーザーは特定のキー・バージョンをPDBに割り当てることはできません。

この機能改善:

  • CDBとPDBの両方にキー・バージョンを関連付けます。
  • CDBレベルおよびPDBレベルでキーを個別にローテーションします。
    ノート

    Data Guardアソシエーションでは、キー・ローテーションはプライマリ・データベースでのみ可能で、スタンバイ・データベースではできません。

Data Guard環境のスタンバイ・データベースからのバックアップおよびリストアの拡張

この機能拡張により、リカバリ・サービスまたはオブジェクト・ストレージを使用してスタンバイ・データベースをバックアップできます。

開始する前に、次の点に注意してください。

  • 自動バックアップをスケジュールし、スタンバイ・データベースで保存期間およびバックアップ・スケジュールを構成できます。
  • データベースは、同じリージョン内の別の可用性ドメイン(AD)に作成することも、スタンバイ・データベースのバックアップとは異なるリージョンに作成することもできます。
  • バックアップは、プライマリ・データベースまたはスタンバイ・データベース、あるいはその両方で構成できます。ただし、構成した場合、プライマリ・データベースとスタンバイ・データベースが同じバックアップ保存先を共有する必要があります。
  • リカバリ・サービスのバックアップの場合、プライマリ・データベースは、スタンバイ・データベースまたはプライマリ・データベースのバックアップからリストアまたはリカバリできます。同様に、スタンバイ・データベースは、プライマリ・データベースまたはスタンバイ・データベースのバックアップからリストアまたはリカバリできます。
  • オブジェクト・ストレージ内のバックアップの場合、プライマリ・データベースとスタンバイ・データベースは、それぞれのバックアップを使用してのみリストアまたはリカバリできます。
  • Data Guardアソシエーションのプライマリ・データベースとスタンバイ・データベースのバックアップ先は同じである必要があります。たとえば、プライマリ・データベースのバックアップ保存先がリカバリ・サービスである場合、スタンバイ・データベースのバックアップ保存先もリカバリ・サービスである必要があります。同様に、スタンバイ・データベースのバックアップ保存先がリカバリ・サービスである場合、プライマリ・データベースのバックアップ保存先もリカバリ・サービスである必要があります。
  • バックアップの保存先は、Data Guardアソシエーションのプライマリ・データベースまたはスタンバイ・データベースでバックアップを無効にした後にのみ変更できます。たとえば、プライマリ・データベースとスタンバイ・データベースの両方のバックアップ保存先がオブジェクト・ストレージで、プライマリ・データベースのバックアップ保存先をリカバリ・サービスに変更する場合は、最初にスタンバイ・データベースのバックアップを無効にする必要があります。
  • 自動バックアップがプライマリ・データベースで構成されている場合、スイッチオーバー時にバックアップは新しいスタンバイ・データベースで続行されます。
  • 自動バックアップがスタンバイ・データベースで構成されている場合、フェイルオーバー時に、バックアップは新しいプライマリ・データベースで続行されます。ただし、バックアップは新しいスタンバイ・データベースで無効になります。

単一VM上のVMクラスタ

この機能拡張により、RACライセンスを必要とせずに、単一のVMで実行されているVMクラスタに複数のデータベースをデプロイおよび実行できます。

詳細は、VMクラスタ・ノードのサブセット化の概要を参照してください。

マルチクラウドOracle Databaseバックアップのサポート

Recovery Serviceは、Oracle Database@AzureなどのマルチクラウドOracle Databasesをサポートし、ソース・データベースが存在するクラウドと同じ場所にバックアップを格納する柔軟性を提供します。

Recovery Serviceでは、デフォルトで保護されたデータベースおよび関連するバックアップがOracle Cloudに作成されます。オプションで、Oracle Database@AzureなどのマルチクラウドOracle Databasesのこのデフォルトの動作をオーバーライドできます。

保護ポリシーに対して「データベースと同じクラウド・プロバイダにバックアップを格納」オプションを有効にすると、ポリシー・リンク保護されたデータベースおよびバックアップは、Oracle Databaseがプロビジョニングされているのと同じクラウドの場所に格納されます。たとえば、Oracle Database@Azureの場合、保護ポリシーで「データベースと同じクラウド・プロバイダにバックアップを格納」オプションを選択した場合、Recovery Serviceは関連付けられた保護されたデータベース・バックアップをAzureに格納します。

保護ポリシーに対して「データベースと同じクラウド・プロバイダにバックアップを格納」を選択しない場合、Oracle Databaseが別のクラウドの場所にプロビジョニングされている場合でも、ポリシー・リンク保護されたデータベースおよびバックアップはOracle Cloudに格納されます。

バックアップのリストアによるリージョン間でのデータベースの作成

この拡張機能により、リージョンが稼働しているときに、次のことができます。

  • 既存のバックアップを使用してリストアし、同じ可用性ドメイン内またはリージョン間で異なる可用性ドメイン内にデータベース(アウトオブプレース・リストア)を作成します。バックアップの保存先Object StorageまたはAutonomous Recovery Serviceでバックアップが作成されたかどうかは関係ありません
  • ホストベースのウォレット(ローカル・ウォレット)またはOCI Vaultを使用して構成されたデータベースで作成されたバックアップをリストアします

プラガブル・データベース(PDB)のコストおよび使用状況属性

OCI Cost Management Serviceのコスト分析機能の拡張により、VMクラスタ内のすべてのPDBの帰属使用量およびコストを表示できます。このデータは、コスト分析ダッシュボードおよびレポートで使用できます。

OCIリージョン間で同じカスタム・ソフトウェア・イメージを使用

この機能改善により、別のリージョンの1つのリージョンで作成されたソフトウェア・イメージを使用できます。

  • データベース・ソフトウェアの更新
  • Grid Infrastructureソフトウェアの更新
  • 新規データベース・ホームのプロビジョニング
  • 新規データベースのプロビジョニング
  • Data Guardアソシエーションの有効化
  • バックアップからのデータベースの作成

ゲストVMローカル・ファイル・システムのサイズを増やす機能

現在、ゲストVMで/u02ファイル・システムのサイズを増減することしかできません。OCIコンソールまたはAPIを使用すると、//u01/tmp/var/var/log/var/log/audit/homeなど、追加のローカル・ファイル・システムのサイズを増やすことができます。

ノート

X8M以降では、ゲストVMファイル・システムのいずれかを拡張する際にローリング再起動は必要ありません。ただし、/u02のサイズを小さくする場合は、各VMのローリング再起動が必要です。

カスタム・ソフトウェア・イメージの作成および使用

カスタム・ソフトウェア・イメージ(データベースおよびGrid Infrastructure)を作成し、必要なすべてのパッチをバンドルして顧客環境で認定することで、開発者およびデータベース管理者は、承認され再利用可能なゴールド・イメージを構築できます。

Oracle Exadata Database Service on Dedicated Infrastructureシステムへのシリアル・コンソール・アクセスの管理

ノート

シリアルコンソール機能には(少なくとも) Exadata System Software 23.1.13が必要です。必要なソフトウェアが四半期メンテナンスでインストールされ、仮想マシンが再起動されると、新しいシリアル・コンソール機能を使用できるようになります。

Oracle Exadata Database Service on Dedicated Infrastructureシステムへのシリアル・コンソール接続を作成および削除して、仮想マシンへの標準SSHアクセスが不可能な場合に備えて、SSH接続を使用してVMゲスト・オペレーティング・システムの問題を診断および解決できます。

要件: Exadata System Software 23.1.13は、最低限必要なバージョンです。また、opcまたはrootユーザーのパスワードの設定など、次に示す前提条件をすべて確認してください。これらの要件を事前に満たすために必要な変更を行わないと、VMにアクセスできないときに必要なときにシリアルコンソールに緊急に接続できなくなります。

Exadata Database Service on Dedicated Infrastructure上のOracle Database 23ai

Oracle Database 23aiは、Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)で使用可能な通常の本番リリースです。このリリースでは、23aiデータベースですべてのライフサイクル操作を実行できます。

データベース・ホームの作成中の統合監査の有効化

この機能拡張により、データベース・ホーム(Oracle Databaseバージョン12.1以降で使用可能な機能)の作成時に統合監査を有効にできます。

  • 12.1より前のOracle Databaseバージョンの場合:統合監査フレームワークを使用できず、かわりに従来のOracle Database監査フレームワークである従来の監査を使用する必要があります。
  • Oracle Databaseバージョン12.1以上の場合: OCIコンソールから統合監査を有効にできます。Oracle Databaseバージョン12.1以上でバージョン23aiより低い場合、デフォルトでは「統合監査」チェック・ボックスは選択されていません。ただし、Oracle Databaseバージョン23aiではデフォルトで選択されています。
ノート

データベース・ホームのプロビジョニング後に統合監査を無効にすることはできません。

OL7またはOL8ベースのイメージのいずれかを使用したVMクラスタのプロビジョニング

この機能拡張により、VMクラスタにOL7ベースのイメージまたはOL8ベースのイメージ(インフラストラクチャがX9以前の場合)のいずれかをプロビジョニングできます。

データベースおよびストレージ・サーバーを削除するためのOCIコンソールの拡張

この拡張機能により、次のことができます。

  • サーバー数を現在の割当てより低い値に変更して、Exadataインフラストラクチャ・リソースをスケール・ダウンします。
  • DBサーバーとストレージ・サーバーの両方で、より少ない数までスケール・ダウンできます。
  • データベース・サーバーで実行中のVMがない場合、データベース・サーバーは削除されます。
    ノート

    削除するDBサーバーは選択できません。この機能により、仮想マシンがないデータベース・サーバーが自動的に削除されます。
  • サーバーがExadataインフラストラクチャ・ストレージの拡張に使用されていない場合、ストレージ・サーバーは削除されます。
  • マルチVM対応でないインフラストラクチャのプロビジョニングされたVMクラスタからVMを削除します。この手順は、マルチVM対応インフラストラクチャのVMクラスタからのVMの終了に似ています。

「容量の追加」ステップは、ストレージ・サーバーのスケールアップ・ワークフローの一部として実行され、ディスク・グループが作成され、すべてのストレージ・サーバー間でデータがリバランスされます。詳細については、Scale VM Resources in Multi VM Enabled Infrastructureを参照してください。

同じOCIリージョン内の異なるVCNまたはコンパートメント間でのData Guardの有効化

この機能拡張により、Exadata Cloud Infrastructureが同じOCIリージョン内の異なるSCNまたはコンパートメントにある場合、Data Guardを有効にできます。

管理者(SYSユーザー)およびTDE Walletパスワードの管理

この機能拡張により、管理者およびTDEウォレットのパスワードを管理できます。

ノート

Oracle Key Vault (OKV)またはOCI Vault Key管理対応データベースのTDEウォレット・パスワードの変更は現在サポートされていません。

Data Guard環境でのOCIオブジェクト・ストレージを使用したスタンバイ・データベースからのバックアップおよびリストア

この機能拡張は:

  • お客様は、Data Guard環境でOCI Object Storageを使用してスタンバイ・データベースにバックアップをオフロードできるため、本番データベース環境のリソースを解放できます。
  • お客様は、Data Guard環境のスタンバイ・データベースで自動バックアップをスケジュールし、保存期間およびバックアップ・スケジュールを構成できます。
  • お客様は、スタンバイ・データベースのバックアップから、同じリージョン内の別のアベイラビリティ・ドメイン(AD)にデータベースを作成できます。
  • 顧客は、スタンバイ・データベースのバックアップを使用してスタンバイ・データベースをリストアおよびリカバリできます。
  • プライマリ・データベースのみ、スタンバイ・データベースのみ、またはその両方でバックアップを作成できる柔軟性を提供します。
  • スタンバイ・データベースの手動完全バックアップを作成できます。
  • プライマリ・データベースのバックアップ保存先がオブジェクト・ストレージの場合のみ、スタンバイ・データベースのバックアップを有効または無効にできます。
ノート

  • プライマリおよびスタンバイ・データベースのバックアップ宛先がオブジェクト・ストレージの場合、プライマリ・データベースのバックアップ宛先をAutonomous Recovery Serviceに変更できません。

    プライマリ・データベースのバックアップ保存先をAutonomous Recovery Serviceに変更するには、まずスタンバイ・データベースのバックアップを無効にします。

  • スタンバイ側のバックアップを使用して、プライマリ・データベースでリストア/リカバリ操作を実行することはできません。
  • スイッチオーバー・シナリオ:
    • オブジェクト・ストレージのバックアップ保存先を使用してプライマリで自動バックアップが構成されている場合、スイッチオーバー時に、バックアップは新しいスタンバイ・データベースで続行されます
    • Autonomous Recovery Serviceのバックアップ保存先を使用してプライマリで自動バックアップが構成されている場合、スイッチオーバー時に、新しいスタンバイ・データベースでバックアップおよびリストアが無効になります
    • 自動バックアップがオブジェクト・ストレージのバックアップ保存先を使用してスタンバイで構成されている場合、スイッチオーバー時に、バックアップは新しいプライマリ・データベースで続行されます
  • フェイルオーバーのシナリオ:
    • オブジェクト・ストレージまたはAutonomous Recovery Serviceのバックアップ保存先を使用してプライマリで自動バックアップが構成されている場合、フェイルオーバー時に、新しい無効なスタンバイ・データベースでバックアップが無効化されます
    • オブジェクト・ストレージのバックアップ保存先を使用してスタンバイに自動バックアップが構成されている場合、フェイルオーバー時にバックアップは新しいプライマリ・データベースで続行されます

実行中の完全または増分バックアップの取消

進行中のバックアップを取り消して、システム・リソースを解放できるようになりました。このバックアップ・ジョブを取り消すためにオペレーション・チームに依頼する必要はもうありません。

データベースの作成ワークフローの一部として、また(データベースの作成後に)単独で、自動バックアップを有効にし、必要なバックアップの保存先を選択できます。選択したバックアップの保存先によっては、1つ以上の完全バックアップと複数の増分バックアップがある場合があります。これらのバックアップの開始後、途中でそのバックアップを取り消すオプションはありません。

この機能により、OCIコンソールまたはOCI APIを介して、実行中のバックアップ(自動またはスタンドアロン)を取り消すことができます。

また、次のこともできます:

  • 「バックアップの作成」ボタンをクリックするとトリガーされる手動バックアップを取り消します

    ノート:すべての手動バックアップは全体バックアップです。

  • 取り消された手動バックアップの削除

デフォルトのバックアップ先としての自律型リカバリ・サービス

このコンソールの拡張機能では、Autonomous Recovery Serviceがすべてのリージョンの自動バックアップのデフォルトのバックアップ先として設定され、リクエストすることなく自動的にデフォルトの制限が含まれます。

サービス制限、割当ておよび使用方法の詳細は、Autonomous Recovery Serviceの制限を参照してください。

Exadataフリート更新

Exadata Fleet Updateは、Oracle DatabaseおよびGrid Infrastructureのパッチ適用エクスペリエンスを簡素化、標準化および強化します。Exadata Fleet Updateでは、顧客のビジネス・ニーズに基づいてコンポーネントを、特定のメンテナンス・サイクル内で1つのエンティティとしてパッチを適用できるコレクションにグループ化することで、これを実現しています。

Exadataフリート・アップデートでは、このパッチ適用エンジンをOCIにネイティブ・クラウド・サービスとして提供し、OCIコンソール、OCI APIおよびOCI CLIからアクセスできます。

Exadata Fleet Updateは、Cloud@Customer (ExaDB-C@C)やExadata Database Service on Dedicated Infrastructure (ExaDB-D)などのOracle Exadata Database Serviceで無料でご利用いただけます。

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

ゲストVM(domU)オペレーティング・システムのOracle Linux 8の更新

コンソールまたはAPIを使用して、ゲストVMオペレーティング・システムをOracle Linus 8に更新します。この拡張機能は、Exadata X7、X8MおよびX9Mシステムに制限されています。

バックアップを使用した、同じリージョン内の可用性ドメインをまたがるデータベースの作成

この拡張機能により、ADが稼働しているときに、次のことができます。

  • 既存のバックアップを使用してリストアし、同じ可用性ドメイン内または同じリージョン内の別の可用性ドメイン内にデータベース(アウトオブプレース・リストア)を作成します。バックアップの保存先Object StorageまたはAutonomous Recovery Serviceでバックアップが作成されたかどうかは関係ありません
  • ホストベースのウォレット(ローカル・ウォレット)またはOCI Vaultを使用して構成されたデータベースで作成されたバックアップをリストアします

暫定ソフトウェア更新

この機能により、クラウドのみのお客様はOCIコンソールおよびAPIから個別パッチをダウンロードできます。コンソールおよびAPIを介してダウンロードしたパッチを適用するオプションはありません。これらのパッチを適用するには、お客様はVMにログインし、パッチ適用ユーティリティを実行する必要があります。

ノート

暫定的なソフトウェア更新をダウンロードするには、少なくともExaDB-Dインフラストラクチャがプロビジョニングされている必要があります。

個別パッチをダウンロードしても、データベース・ソフトウェア・イメージ(DSI)の作成は置換されません。お客様は、引き続きデータベース・ソフトウェア・イメージ(DSI)を使用して、カスタマイズされたイメージを構築およびデプロイする必要があります。

自動完全バックアップ(L0)および増分バックアップ(L1)を構成するための拡張制御

データベースの作成ワークフロー中または別のステップとして自動バックアップを有効にすると、最初の完全バックアップ(初期L0)がすぐに開始されます。

同様に、後続の完全バックアップ(将来のL0)および日次増分バックアップ(L1)では、時間ウィンドウを指定できますが、これらのバックアップを開始する必要がある曜日は変更できません。

将来のL0およびL1バックアップは、自動バックアップ・プロセスの開始時にユーザーがデータベースに対して選択した2時間のスケジュール・ウィンドウ中に開始されます。12個のスケジューリング・ウィンドウから選択できます。各ウィンドウは偶数時間から始まります。たとえば、あるウィンドウは午前4:00から6:00まで実行され、次のウィンドウは午前6:00から8:00まで実行されます。バックアップ・ジョブは、必ずしもスケジュールされたウィンドウ内に完了するわけではありませんウィンドウを指定しない場合、デフォルトの6時間のバックアップ・ウィンドウ(00:00から6:00まで)が選択されます。この場合、タイム・ゾーンはExadata Cloudインフラストラクチャ・インスタンスのリージョンに対応します。

バックアップ保存先、オブジェクト・ストレージ・サービスおよびAutonomous Recovery Serviceの現在のデフォルトは次のとおりです:

  • 初期完全L0バックアップ:即時
  • 後続の完全L0バックアップ:毎週日曜日
  • 日次増分L1バックアップ:毎週月曜日から土曜日

これらの拡張制御では、次のことができます:

  1. 最初のL0バックアップをすぐに開始するように構成する以外に、最初のL0バックアップをすぐに開始するか、L0スケジュールに従って開始するかも指定できます。
  2. 将来の完全バックアップを開始する時間ウィンドウを選択します。
  3. 増分バックアップを開始する時間ウィンドウを選択します。これは、L0バックアップの時間ウィンドウとは異なる場合があります。

    時間ウィンドウは、2時間のスケジュール・ウィンドウとデフォルトの6時間のウィンドウのままになります。

バックアップの宛先としてのOracle Database Autonomous Recovery Serviceの構成

Oracle Database Autonomous Recovery Serviceは、Exadata Database on Dedicated Infrastructure向けの最適化されたポリシー主導の自動バックアップおよびリカバリ・システムを提供します。また、データベース障害が発生した場合に保護されたデータベースをデータ損失ゼロでリカバリできるリアルタイム・データ保護機能も提供します。リアルタイム・データ保護は追加料金のオプションであるため、有効にするか無効にするかを選択できます。

月次ExaDB-Dインフラストラクチャ・セキュリティ・メンテナンス

四半期メンテナンスと並行して実行されるセキュリティ・メンテナンスは、月に1回実行され、CVSSスコアが7以上の脆弱性の修正を含みます。

Identity and Access Management (IAM)とOracle Exadata Database Service on Dedicated Infrastructureの統合

最新のリリース更新では、Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM)認証および認可を使用するように仮想マシン・クラスタでデータベースを構成し、IAMユーザーがIAM資格証明を使用してデータベースにアクセスできるようになりました。

このリリースの時点では、次の条件でIAM認証および認可がサポートされています:

  • サポートされている環境:新しくプロビジョニングされたデータベースおよび19.17にパッチが適用された既存のデータベースで使用できます。この機能は、Oracle Database 21cではサポートされていません。
  • サポートされていない構成: IAM認証および認可は、Data Guardで構成されたデータベースでは使用できません。

Exadata Cloud Infrastructure: プライベートDNS

ユーザーは、ExaCSに新しいVMクラスタをプロビジョニングするときに、プライベート・ビューおよびプライベート・ゾーンを選択できます。VCNの基礎となるすべてのリソース(ExaDB-Dのリソースを含む)は、同じプライベート・ゾーンに作成される必要があります。プライベート・ゾーンは、VCN内のサブネットに関連付けることができます。この構成は後で変更できません。

プライベートDNSリゾルバは、顧客VCNの問合せとオンプレミス・ネットワークからの問合せを解決します。DNSアドレスを提供し、条件付き転送を使用してそれをDBリソースにシードする機能は、プライベートDNS機能によって提供されます。プライベート・リゾルバを使用すると、顧客は異なるVCN間でAレコードを解決できます(VCNピアリング-ローカル/リモートを使用)。

インフラストラクチャ・メンテナンス制御の機能強化

Exadata Cloud InfrastructureのOracle管理インフラストラクチャ・メンテナンスでは、次のように制御と可視性が向上しました:
  • ローリングおよび非ローリング・メンテナンス方法の選択。
  • メンテナンスが再開されるか、構成されたタイムアウトに達するまで、自動メンテナンスがVMを停止する前に待機することで、各データベース・サーバーでメンテナンス前にカスタム・アクションを実行する機能。
  • データベース・サーバーの更新順序の可視性。
  • コンポーネント・レベルでのメンテナンス進行状況の詳細なトラッキング。

Oracle Exadata Database Service on Dedicated Infrastructureでのプラガブル・データベースのデータベース管理サポート

Oracle Exadata Database Service on Dedicated Infrastructureでプラガブル・データベース(PDB)のデータベース管理を有効にし、モニタリング、パフォーマンス管理およびチューニングにデータベース管理機能を使用できるようになりました。

Microsoft Azure Active DirectoryとOracle Cloud Infrastructureデータベースの統合

Oracle Exadata Database on Dedicated Infrastructureは、Azure ADトークンを受け入れてデータベースにアクセスできるようになりました。Azure ADユーザーはAzure ADトークンを使用してデータベースに直接アクセスでき、アプリケーションはサービス・トークンを使用してデータベースにアクセスできます。

Azure AD統合は、19.17以上のパッチが適用されたデータベースで使用できます。この機能は、Oracle Databaseリリース21cでは使用できません。

Exadataシステムごとの複数の仮想マシン(MultiVM)の作成および管理とVMクラスタ・ノードのサブセット化

  • サービス: データベース
  • リリース日: 2022年11月9日以降(リリース日はリージョンごとに異なります)

Exadataリソースを複数の仮想マシンにスライスします。Oracle Exadata Database Service on Dedicated Infrastructureで最大8つの複数の仮想マシン(VM)クラスタを定義し、それらにシステム・リソース全体を割り当てる方法を指定します。

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

ノート

既存のExadataインフラストラクチャの場合、MultiVMは、2022年12月20日のMultiVM移行後の次回のスケジュール済メンテナンス実行の一部として有効になります。2022年11月15日のMVMリリース後に新しくプロビジョニングされたすべてのExadataインフラストラクチャでは、MultiVMが有効になります。

関連トピック

OCIコンソールでのVMクラスタおよびデータベースのヘルスおよびパフォーマンス・メトリック

このリリースでは、OracleはOracle Cloud Infrastructure (OCI)コンソールでデータベースおよびVMクラスタのヘルス・メトリックを提供します。

ノート

ネットワークの問題があり、Oracle Trace File Analyzer (TFA)がメトリックをポストできない場合、TFAは1時間待機してからメトリックのポストを再試行します。これは、TFAでメトリック処理のバックログを作成しないようにするために必要です。

ネットワークの復旧から最初のメトリックのポストまで、1時間分のメトリックが失われる可能性があります。

Oracle Exadata Database Service on Dedicated Infrastructure上のリソースに対するOracleの標準タグ付け

Exadata Cloud Infrastructureリソースは、組織スキームに従ってOracle標準タグを使用してタグ付けできるようになりました。リソースにタグ付けすることで、リソースをグループ化し、コストを管理して、リソースがどのように使用されているかについてインサイトを得ることができます。

自動診断収集

この機能は、ゲストVM上のOracle Databaseまたはその他のコンポーネントのヘルスに関する問題について通知を受けることができるデータベース・サービス・イベント機能の実装を拡張するものです。この拡張機能により、次のことが可能になります:
  • Oracleが診断と問題解決のために詳細なヘルス・メトリックを積極的に収集
  • Oracleが、より詳細な診断と問題解決のために、インシデント・ログとトレース・ファイルを事後対応的にオンデマンドで収集

ゲストVMイベント、ヘルス・メトリック、インシデント・ログおよびトレース・ファイルを収集すると、Oracleによるサービス運用の強化と、早期の検出および相関によるプロアクティブなサポートの提供に役立ちます。

Exadata Database on Dedicated Infrastructure: クロスリージョンData Guardのキー管理サービス

プライマリ・データベースとスタンバイ・データベースの暗号化キーをそれぞれプライマリ・リージョンとスタンバイ・リージョンで使用できるようになり、OCI Vaultキーの単一障害点に対する保護が提供されます。これは、キーがOCI Virtual Private Vaultにある場合に可能です。つまり、キーが仮想プライベート・ボールト(VPV)に存在し、OCI Vaultサービスによって管理されている場合、2つのデータベース間でクロスリージョンData Guardを設定できます。

VMクラスタでのOracle Databaseの同時作成または終了

この機能拡張により、VMクラスタが「更新中」状態であっても、Oracleデータベースを同時に作成または終了できるようになりました。
  • クラスタに作成できるデータベースの数は、VMで使用可能なメモリーによって異なります。VMに60GBを超えるメモリーがある場合は、データベースごとにデフォルトで12.6GB (SGAに7.6GB、PGAに5GB)が割り当てられます。VMが60GB以下の場合は、6.3GB (SGAに3.8GB、PGAに2.5GB)が割り当てられます。また、Grid InfrastructureおよびASMは、約2GBから4GBのメモリーを消費します。
  • 作成中のデータベースは終了できません。ただし、VMクラスタ内の他のデータベースは終了できます。

VM Guest Exadata OSイメージのメジャー・バージョン更新

現在インストールされているバージョンが19.2以上である場合、Exadata VMクラスタ・イメージに対してマイナー・バージョン更新を実行する以外に、新しいメジャー・バージョンに更新できます。たとえば、VMクラスタがバージョン20の場合は、バージョン21に更新できます。

Exadata Databaseのデータベース・サービス・イベント機能

この機能により、顧客はOCIコンソールまたはAPI/CLI/SDK/Terraformを使用して、ゲストVM上のOracle Databaseまたはその他のコンポーネントのヘルスに関するイベント通知を受信できます。

現在は、バックアップ開始、バックアップ終了、パッチ適用開始などの基本的なライフサイクル管理イベントがあります。データベース・サービス・イベントの包括的なセットを含めて顧客が問題をトラブルシューティングできるように機能が拡張されているところです。

データベース・サービス・イベントは、テナンシの既存のOCIイベント・サービスおよび通知メカニズムを活用して、ゲストVMの操作および状態をモニターし、顧客の診断通知を生成します。顧客は、トピックを作成し、電子メール、関数、ストリームなどを使用してこれらのトピックをサブスクライブできます。イベント通知サービスの使用の詳細は、通知の概要を参照してください

顧客の主な利点

  • オプトイン・メカニズムを介してゲストVM操作の通知を受信できます。
  • 問題が深刻になる前に顧客が事前に対処できます。

OCIコンソール・エクスペリエンス

顧客は、OCIコンソール・メニューから「Oracle Database」→「Oracle Exadata Database Service on Dedicated Infrastructure」→特定のVMクラスタを選択してVMクラスタの詳細ページに移動し、VMクラスタの診断通知を有効にできます。

Exadata Database on Dedicated Infrastructure: 顧客管理の暗号化を使用するデータベースで「バックアップからデータベースを作成」を使用できるようになりました

Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D): バックアップが顧客管理の暗号化を使用するデータベースのものである場合、バックアップからデータベースを作成できるようになりました。これは、バックアップがOracle管理の暗号化を使用するデータベースのバックアップである場合に、バックアップからデータベースを作成する既存の機能に加えて提供されます。

DBホーム・マイナー・バージョン選択(N-3)のサポート

選択したメジャー・バージョンおよびRUバージョンを使用してDBホームをプロビジョニングします。

プロビジョニング時に、イメージ・タイプとして「Oracle提供のデータベース・ソフトウェア・イメージ」を使用する場合は、「使用可能なすべてのバージョンの表示」スイッチを使用して、使用可能なすべてのPSUおよびRUから選択できます。各メジャー・バージョンの最新リリースは、「最新」ラベルで示されます。

Oracle Cloud Infrastructureで使用可能なOracle Databaseのメジャー・バージョン・リリースについては、現在のバージョンに加え、直近の3つの旧バージョン(NからN - 3まで)のイメージが提供されます。たとえば、インスタンスでOracle Database 19cを使用しており、提供される19cの最新バージョンが19.8.0.0.0である場合、プロビジョニングに使用できるイメージは、バージョン19.8.0.0.0、19.7.0.0、19.6.0.0および19.5.0.0が対象になります。

Oracle Cloud Infrastructure Operations InsightsによるOracle Cloudデータベースのサポート

オペレーション・インサイトで、Capacity PlanningおよびSQL Warehouseの機能を使用して、Oracle Cloud(ベア・メタル、仮想マシンVMおよびExadata Cloud Infrastructure)にデプロイされたOracle Databaseに関するインサイトを得られるようになりました。

Data Guardアソシエーションでプライマリ・データベースとスタンバイ・データベースに同じSIDを指定

Data Guardアソシエーションの作成時に、プライマリ・データベースに使用されるものと同じSID接頭辞をスタンバイ・データベースにも使用できるようになりました。

Exadata Cloud Infrastructure: プラガブル・データベースのライフサイクルをサポート

OCIコンソールおよびAPIを使用して、Exadata Cloud Infrastructureでプラガブル・データベース(PDB)を作成および管理できるようになりました。詳細は、Exadataプラガブル・データベースの作成および管理を参照してください。

Exadata Cloud Infrastructure: データベースの作成中に、DB_UNIQUE_NAMEおよびOracle SID接頭辞を設定

Exadata Cloud Infrastructureで新しいOracle Databaseを作成するときに、DB_UNIQUE_NAME値およびOracle SID接頭辞を指定できるようになりました。Oracle Data Guardアソシエーションでスタンバイ・データベースを作成する際にも、これらの値を設定できます。手順については、次のトピックを参照してください:

既存のVMクラスタにデータベースを作成するには

Exadata Cloud InfrastructureシステムでData Guardを有効にするには

エラスティックな拡張

エラスティックなプロビジョニングと拡張により、増大するワークロード要件を満たすようにCPUとストレージ容量を動的に増やすことができます。

サポートされる標準シェイプによる制約を受けずに、データベースまたはストレージ・サーバーを追加してインフラストラクチャをスケール・アップすることで、オンデマンドでインフラストラクチャの容量を拡張します。インフラストラクチャに新しいVMクラスタをプロビジョニングする際、またはすでにデプロイされているVMクラスタに(現在実行中のワークロードを中断することなく)、X8MおよびX9Mサーバーで使用可能なCPUおよびストレージ容量をシステム制限まで割り当てることができます。

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

  • Exadata Cloud InfrastructureクラウドVMクラスタまたはDBシステムでCPUコアをスケールするには
  • コンピュートおよびストレージ・リソースをフレキシブル・クラウドExadataインフラストラクチャ・リソースに追加するには
  • APIを使用したExadata Cloud Infrastructureインスタンスの管理
  • cloud-exadata-infrastructures
  • ストレージ拡張イベント・タイプ

Oracle Database: ベア・メタル、仮想マシンおよびExadata Cloud Infrastructureデータベースの暗号化キー・オプションを更新

新しいOracle Database、新しい仮想マシンまたはベア・メタルDBシステムをプロビジョニングする場合、TDEウォレット・パスワード・パラメータはオプションになりました。顧客管理キーとOCI Vaultサービスを使用するようにExadata Cloud Infrastructureデータベースを構成する場合は、使用されなくなりました。Oracle Databaseおよび仮想マシンDBシステムの作成の詳細は、ドキュメントの次のトピックを参照してください:

Vaultサービスを使用して、OCIリソースで使用される暗号化キーおよびその他のシークレットを格納および管理する方法の詳細は、Vaultサービスのドキュメントを参照してください。

パフォーマンス・ハブの「Exadata」タブ

「Exadata」タブには、Oracle Exadataハード・ディスクおよびフラッシュのパフォーマンス統計の統合ビューが表示され、Oracleデータベース、Oracle Exadataストレージ・セル、自動ストレージ管理(ASM)などのすべてのコンポーネントのヘルスとパフォーマンスについて深い洞察が得られます。Exadata CloudデプロイメントおよびExadataインフラストラクチャを使用する外部データベースで使用できます。詳細は、パフォーマンス・ハブを使用したデータベースのパフォーマンスの分析を参照してください。

Exadata Cloud Infrastructure: VMクラスタ用のカスタムSCANリスナー・ポート

ExadataクラウドVMクラスタにカスタムSCANリスナー・ポートを指定できるようになりました。詳細は、SCANリスナー・ポートの設定を参照してください。

Exadata Cloud Infrastructure、ベア・メタルDBシステムおよび仮想マシンDBシステムで実行されているデータベースに使用できるパフォーマンス・ハブおよびメトリック

パフォーマンス・ハブ・ツールを使用し、Exadata Cloud Infrastructureインスタンス、ベア・メタルDBシステムおよび仮想マシンDBシステムで実行されているクラウド・データベースのメトリックを表示できるようになりました。この機能により、これらのデータベースに対して追加のモニターおよび管理機能が提供されます。詳細は、Exadata Cloud Serviceデータベース・パフォーマンスの分析および仮想マシン/ベア・メタル・データベースのパフォーマンスの分析を参照してください。

Exadataインフラストラクチャのメンテナンス・アドバイザリの連絡先

Exadataインフラストラクチャに対して更新が行われた場合に、Oracleがメンテナンス通知を送信する有効な電子メール・アドレスを最大10個まで指定できます。指定する電子メール・アドレスは、サービスに関連する操作上の問題にのみ使用されます。詳細は、Oracle管理のインフラストラクチャ・メンテナンス更新を参照してください。

Exadata、ベア・メタルおよび仮想マシンのデータベース・クラウド・サービスのData Guard保護モードの機能拡張

Exadata Cloud Infrastructureインスタンスおよびベア・メタルおよび仮想マシンDBシステムにData Guard保護モードを指定できるようになりました。詳細は次のトピックを参照してください:

Exadata Cloud Infrastructure: インフラストラクチャの非ローリング・パッチ適用オプションが使用可能に

データベース・ノード間で非ローリング方式でExadataインフラストラクチャのパッチ適用が実行されるように構成できるようになりました。このオプションを使用すると、システムの四半期ごとのメンテナンスにかかる合計時間を短縮できますが、システム・ダウンタイムが伴います。詳細は、Oracle管理のインフラストラクチャ・メンテナンス更新を参照してください。

Exadata Cloud InfrastructureのOracle Data Guard対応データベースで、顧客管理の暗号化キーが使用可能に

Exadata Cloud Infrastructureの顧客管理キーは、顧客が管理する暗号化キーを使用してデータを暗号化できる暗号化キー管理サービスです。Oracle Data Guardが有効なExadata Cloud Infrastructureでプロビジョニングするデータベースで、顧客管理キーを使用できます。

ExaDB-D OS/DomUパッチ適用プロジェクト

DomU OSパッチ適用は、ExaDB-Dの顧客がOCIコンソールおよびAPIから、domUノード上のExadata OSイメージを自動でアップグレードできるようにする機能です。次の情報は、リリース時にドキュメントに追加できなかった機能の最近の変更について説明したものですが、間もなく追加される予定です。

パッチが失敗した場合、ロールバックが必要です。

マルチノード・システムでは、いずれかのノードがパッチに失敗した場合、すべてのノードをロールバックして、すべてのノードを同じバージョンにする必要があります。次に、事前チェックを実行し、問題を修正して、パッチを再度実行します。

例: 月曜日に事前チェックを実行し、すべてのノードが成功したが、水曜日までパッチを適用しない場合、ノードの変更またはメンテナンスの競合のために、1つ以上のノードがパッチに失敗する可能性があります。

これが発生しないように、パッチを適用する直前に事前チェックを実行することをお薦めします。

詳細は、Exadata Cloud Service VMクラスタ・オペレーティング・システムの更新を参照してください。

Oracle Cloud Infrastructure VaultサービスとExadata Cloud Infrastructureとの統合

Oracle Cloud Infrastructure VaultサービスとExadata Cloud Infrastructureとの統合により、顧客管理キーによるデータベース暗号化が可能になります。詳細は、Exadata Cloud Serviceの顧客管理キーを参照してください。

Exadata Cloud Infrastructure: Oracle Database 19cのアップグレード機能が使用可能に

Oracle Cloud InfrastructureコンソールまたはAPIを使用して、Exadata Cloud InfrastructureデータベースをOracle Databaseバージョン19cにアップグレードできるようになりました。詳細および手順は、Exadata Databaseのアップグレードを参照してください。

Exadata Cloud Infrastructureインスタンス用のカスタム・データベース・ソフトウェア・イメージの作成

Exadata Cloud Infrastructureインスタンスでデータベース・ホームのプロビジョニングおよびデータベースのパッチ適用に使用するカスタムOracle Databaseソフトウェア・イメージを作成できるようになりました。詳細は、Oracle Databaseソフトウェア・イメージを参照してください。

Exadata Cloud Infrastructure: クラウドVMクラスタのグリッド・インフラストラクチャのアップグレード

コンソールを使用して、Exadata Cloud Infrastructure VMクラスタのグリッド・インフラストラクチャ(GI)をアップグレードできるようになりました。詳細は、Exadata Grid Infrastructureのアップグレードを参照してください。

Exadata Cloud Infrastructure: フレキシブルX8Mシェイプが使用可能に

フレキシブルX8Mシェイプを使用して、Exadata Cloud Infrastructureインスタンスをプロビジョニングできるようになりました。このシェイプでは、プロビジョニング後にデータベースの拡大に伴ってより多くのストレージ・サーバーまたはコンピュート・サーバー(あるいはその両方)が必要になると、システムを拡張できます。詳細は、X8MスケーラブルExadataインフラストラクチャの概要を参照してください。

Exadata Cloud Infrastructure: Data Guardスタンバイ・データベースの設定時に既存のデータベース・ホームを使用

Exadata Cloud InfrastructureインスタンスでData Guardスタンバイ・データベースを設定するときに、既存のデータベース・ホームを使用することを選択できるようになりました。Exadataデータベースに対するData Guardの設定の詳細は、Exadata Cloud ServiceインスタンスでのOracle Data Guardの使用を参照してください。