Oracle Exadata Database Service on Exascale Infrastructureの新機能

Oracleは、Exascaleインフラストラクチャ上のOracle Exadata Database Serviceの新しいリージョン(ExaDB-XS)を引き続き追加します。

使用量の増加に応じてExascaleストレージ・ボールトを自動的にスケーリングできるようになり、ストレージはユーザー定義の制限まで増分的に拡張されます。

リリース日: 2025年9月

以前は、Exascale Storage Vaultの手動スケール・アップまたは手動スケール・ダウンのみが使用できました。この新機能であるExascale Storage Vaultの自動スケーリングにより、Exascaleインフラストラクチャ環境上のExadata Database Serviceの俊敏性が向上します。これにより、手動による介入なしで、使用量の増加に応じてストレージを自動的に拡張できます。

自動スケーリングが有効な場合、Vaultの空き領域が割り当てられたストレージ容量の5%以下であることがシステムによって検出されると、Vaultの容量が自動的に拡張されます。Vaultの容量は、ユーザー定義の自動スケール制限に達するまで、割り当てられたストレージ容量の10%ずつ増加します。

これにより、Vaultの使用量が制限に近づいたときに、手動で容量を増やす必要がなくなります。ストレージは動的にスケーリングされるため、ミッションクリティカルなワークロードがスムーズかつ中断なく実行され続けます。

Oracleは、Exadata Database Service on Exascaleインフラストラクチャ(ExaDB-XS)がOracle Database 19cおよびOracle Grid Infrastructure 19cをサポートするようになったことをお知らせします。

リリース日: 2025年8月

Oracleは昨年、Oracle AI Database 26aiでExaDB-XSを開始し、業界で唯一のクラウド向けインテリジェント・データ・アーキテクチャを導入しました。これは、Exadataの長所とクラウドの長所を組み合わせた革新的な飛躍です。ExaDB-XSは、Exadataの利点をより低いエントリー・コストできめ細かいスケーラビリティで提供するため、幅広いミッションクリティカルなデータベースにとって理想的なプラットフォームとなっています。オンプレミス・データベースをクラウド内の共有Exascaleインフラストラクチャに簡単に移行できます。これまで、これらのメリットは、Oracle AI Database 26aiを導入する準備ができているお客様のみが利用できました。Oracle Database 19cでミッションクリティカルなワークロードを持つ多くの組織は、まだOracle AI Database 26aiにアップグレードする準備ができていません。これらの組織は、Oracle AI Database 26aiに独自のペースでアップグレードするオプションにより、Oracle Database 19cのExascaleインフラストラクチャのメリットをすぐに実現できるようになりました。

この機能拡張により、プラガブル・データベース(PDB)をリストア、リフレッシュおよび再配置できます。

リリース日付 2025年8月

OCIコンソールおよびAPIのPDBレベルのスナップショット機能を使用すると、PDBレベルのスナップショットを作成および管理したり、クローン(シン・クローンを含む)を作成できます。スペース効率の高いExascaleリダイレクト・オンライト・テクノロジを活用します。

クロスサービスのプライマリ・データベースとセカンダリ・データベースを使用して、Oracle Data Guard環境をデプロイできるようになりました。

リリース日: 2025年8月

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

• ExaDB-XSまたはExaDB-Dに1つ以上のスタンバイ・データベースがあるExaDB-D上のプライマリ・データベース。ExaDB-DまたはExaDB-XSに1つ以上のスタンバイ・データベースがあるExaDB-XS上のプライマリ・データベース。
• ExaDB-DまたはExaDB-XSに1つ以上のスタンバイ・データベースがあるExaDB-XS上のプライマリ・データベース。

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

リリース日付 2025年8月

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

バックアップ操作およびリカバリ操作を実行するためのOracle推奨オプション

2025年8月6日、OCIコンソールで自動バックアップを有効にすると、次の条件下で使用可能なバックアップ保存先はAutonomous Recovery Serviceのみになります。

• テナンシは、2025年8月6日以降に作成されました。
• データベースは、OCIリージョンのフランクフルト(FRA)、フェニックス(PHX)および東京(NRT)にデプロイされます。

Oracle Databaseのバージョンが19.18または23.4より後です。

これらの条件を満たさない場合、OCIオブジェクト・ストレージはバックアップの保存先として表示されます。

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

リリース日: 2025年7月

Oracle Data Guardを設定する前に事前チェックを実行し、Data Guardを設定する前に潜在的な問題に対処できるようになりました。

リリース日: 2025年6月

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

Oracle Exadata Database Service on Exascale InfrastructureでのVMクラスタのデプロイメント中に、VNクラスタの作成時にデフォルト・ネットワークをデプロイすることを選択できます。

リリース日: 2025年5月

VMクラスタの作成時にデフォルト・ネットワークをデプロイする一般可用性(GA)を発表します。デフォルトVCNを作成するオプションを選択すると、テナンシのネットワーク構成を自動移入するデフォルト設定を使用して、新しいVCNが作成されます。以前は、新しいVMクラスタを作成する際に、様々な特定の要件を満たすVCNを事前に作成する必要がありました。これで、クラウド自動化でデフォルトの新しいVCN設定を作成するオプションを選択できるようになりました。これは、ネットワークを事前に計画することなく、新しいVMクラスタをすばやく設定する便利な方法です。これは、単純なテストのユースケースに特に役立ちます。

リリース日: 2025年5月

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

パフォーマンス・ハブ・ツールを使用して、Exascaleインフラストラクチャ(ExaDB-XS)上のOracle Exadata Database Serviceで実行されているクラウド・データベースのメトリックを表示できるようになりました。

リリース日: 2025年4月

この機能は、ExaDB-XS上のデータベースに対して追加のモニターおよび管理機能を提供します。詳細は、Exadata Cloud Serviceデータベース・パフォーマンスの分析および仮想マシン/ベア・メタル・データベースのパフォーマンスの分析を参照してください。

プライマリ・データベースにリンクされた複数のローカルおよびリモートのOracle Data Guardスタンバイ・データベースを作成および管理できるようになりました。

リリース日2025年4月

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

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

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

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

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

Oracle Real Application Clusters (Oracle RAC)ライセンスを必要とせずに、単一ノード・クラスタでデータベースをデプロイおよび実行できます。

ExaDB-XSで、VMごとに有効になるECPUをゼロにスケーリングできるようになりました。