機械翻訳について

2 Oracle Exadata Database Service on Dedicated Infrastructureの新機能

Oracleは、常に新しい機能をExadata Cloud Infrastructureに追加しています。

四半期ごとのExadata Infrastructureメンテナンス計画および実行の拡張

ノート:

この機能は、SCL, YUL, ZRH, AUH, DXB, YNY, HYD, BOG, MTY1, AGA1, BOG1, XSP1およびRUH1リージョンにロールアウトされます。 フェーズで他のリージョンにロールアウトされます。

リージョンおよび可用性ドメインの詳細は、「リージョンおよび可用性ドメインについて」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

ノート:

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

X11Mシステム・サポート

ノート:

この機能は、IADリージョンとPHXリージョンにのみロールアウトされます。 フェーズで他のリージョンにロールアウトされます。

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

Data Guard関連付け、スイッチオーバーおよびフェイルオーバー操作でのプライマリDBホームとスタンバイDBホームの異なるRU

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

Data Guard関連付けの作成:

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

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

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

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

Oracle Cloud Infrastructure Zero Trust Packet Routingによる機密データの保護

データ対応のクラウド・セキュリティ制御である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バックアップのサポート

リカバリ・サービスは、Oracle Database@Azureなどのマルチ・クラウドOracle Databasesをサポートし、ソース・データベースが存在する同じクラウドのロケーションにバックアップを格納する柔軟性を提供します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ノート:

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

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

要件: Exadataシステム・ソフトウェア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以降で使用できます。

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

ノート:

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

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

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

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

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

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

    ノート:

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

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

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

この機能拡張により、Exadata Cloud Infrastructureが同じOCIリージョン内の異なるVCNまたはコンパートメントにある場合に、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)にデータベースを作成できます。
  • スタンバイ・データベースのバックアップを使用して、スタンバイ・データベースをリストアおよびリカバリできます。
  • プライマリ・データベースのみ、スタンバイ・データベースのみ、またはその両方でバックアップを柔軟に取得できます。
  • スタンバイ・データベースの手動完全バックアップを作成できます。
  • プライマリ・データベースのバックアップの保存先がObject Storageの場合にのみ、スタンバイ・データベースのバックアップを有効または無効にできます。

ノート:

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

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

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

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

進行中のバックアップを取り消すことができ、システム・リソースを解放できます。 このバックアップ・ジョブを取り消すために、運用チームを呼び出す必要はありません。

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

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

次のこともできます。

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

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

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

デフォルトのバックアップ保存先としてのAutonomous Recovery Service

サービス: データベース

リリース日: 2023年8月17日

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

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

Exadataフリート更新

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

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

Exadataフリート更新は、Cloud@Customer (ExaDB-C@C)およびExadata Database Service on Dedicated Infrastructure (ExaDB-D)を含むOracleのExadata Database Serviceでは無償で使用できます。

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

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

サービス: データベース

リリース日: 2023年8月1日

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

バックアップを使用した同じリージョン内の複数のアベイラビリティ・ドメインにわたるデータベースの作成

サービス: データベース

リリース日: 2023年7月26日

この機能改善により、ADが稼働しているときに、次のことができます:

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

暫定ソフトウェア更新

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

ノート:

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

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

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

サービス: データベース

リリース日: 2023年5月17日

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

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

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

バックアップ保存先、Object Storage ServiceおよびAutonomous Recovery Serviceの現在のデフォルトは次のとおりです:

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

これらの拡張コントロールでは、次のことができます:

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

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

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

サービス: データベース

リリース日: 2023年4月12日

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

アプリケーションVIPサポート

サービス: データベース

リリース日: 2023年4月12日

VMクラスタでは、アプリケーション仮想IPアドレスのアタッチおよびデタッチがサポートされるようになりました。

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

サービス: データベース

リリース日: 2023年3月1日

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

ノート:

インフラストラクチャ・セキュリティ・メンテナンスの実装は、SCL, YUL, ZRH, AUH, DXB, YNY, HYD, ORD, MAD, MTZおよびARNリージョンにのみロールアウトされます。 他のリージョンには段階的にロールアウトされます。

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

サービス: データベース

リリース日: 2023年1月24日

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

このリリースの時点では、IAMの認証と認可:
  • 新しくプロビジョニングされ、19.17にパッチが適用された既存のデータベースで使用できます。 この機能は、Oracle Databaseリリース21cでは使用できません。
  • Data Guardで構成されたデータベースでは使用できません。

Exadataクラウド・インフラストラクチャ: プライベートDNS

  • サービス: データベース
  • リリース日: 2023年1月18日

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

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

拡張インフラストラクチャ・メンテナンス制御

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

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

サービス: データベース

リリース日: 2023年1月11日

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

Microsoft Azure Active DirectoryとOracle Cloud Infrastructure Databaseとの統合

サービス: データベース

リリース日: 2023年1月10日

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 Infrastructureの場合、MultiVMは、2022年12月20日のMultiVM移行後の次回のスケジュール済メンテナンス実行の一部として有効になります。 2022年11月15日のMVMリリース後に新しくプロビジョニングされたすべてのExadata Infrastructureでは、MultiVMが有効になります。

関連トピック

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

  • サービス: データベース
  • リリース日: 2022年10月7日

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

ノート:

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

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

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

「Exadataクラウド・インフラストラクチャ」リソースは、組織スキームに従ってOracle Standardタグを使用してタグ付けできるようになりました。 リソースにタグ付けすることで、リソースをグループ化し、コストを管理し、それらがどのように使用されているかを把握できます。

自動診断収集

この機能により、データベース・サービス・イベント機能の実装が拡張され、ゲストVM上のOracle Databasesまたはその他のコンポーネントのヘルスに関する問題を通知できます。 この機能改善により、次のことが可能になります:
  • 診断と問題解決のための詳細なヘルス・メトリックをプロアクティブに収集するOracle
  • Oracleは、インシデント・ログとトレース・ファイルをオンデマンドで反応して収集し、より深い診断と問題解決を実現

ゲストVMイベント、ヘルス・メトリック、インシデント・ログおよびトレース・ファイルを収集すると、Oracleはサービス操作の強化と、早期発見および相関によるプロアクティブなサポートの提供を支援します。

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

  • サービス: データベース
  • リリース日: 2022年8月8日

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

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

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

VMゲストExadata OSイメージのメジャー・バージョン更新

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

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

  • サービス: データベース
  • リリース日: 2022年7月8日

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

お客様には現在、バックアップの開始、バックアップ終了、パッチ適用の開始など、基本的なライフサイクル管理イベントがあります。オラクルでは、お客様の問題のトラブルシューティングに役立つ包括的なDatabase Serviceイベント・セットを含める機能を拡張しています。

Database Service Eventsは、既存のOCIイベント・サービスおよび通知メカニズムをテナンシで活用することで、ゲストVMの操作および条件を監視し、顧客の診断通知を生成します。 その後、顧客は電子メール、機能、ストリームなどを通じてトピックを作成し、これらのトピックをサブスクライブできます。イベント通知サービスの使用方法の詳細は、「通知の概要」を参照してください

お客様の主な利点

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

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

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

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

  • サービス: データベース
  • リリース日: 2022年6月29日

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

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

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

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

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 Oracle Cloud Databaseのオペレーション・インサイトのサポート

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

Data Guard関連付けのプライマリ・データベースとスタンバイ・データベースに同じSIDを指定

Data Guard関連付けの作成時に、プライマリ・データベースに使用されるものと同じSIDプレフィクスをスタンバイ・データベースにも使用できるようになりました。

Exadataクラウド・インフラストラクチャ: プラガブル・データベースのライフサイクル・サポート

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

Exadataクラウド・インフラストラクチャ: データベース作成時のDB_UNIQUE_NAMEおよびOracle SIDプレフィクスの設定

Exadata Cloud Infrastructureで新しいOracle Databaseを作成するときに、DB_UNIQUE_NAME値とOracle SIDプレフィクスを指定できるようになりました。 Oracle Data Guard関連付けでスタンバイ・データベースを作成するときに、これらの値を設定することもできます。 手順については、次の各トピックを参照してください。

既存のExadata Cloud Infrastructureインスタンスにデータベースを作成するには

コンソールを使用したExadata Cloud InfrastructureシステムでのData Guardの有効化

柔軟な拡張

サービス: データベース

リリース日: 2021年12月23日

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

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

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

  • 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 Databasesおよび仮想マシンDBシステムの作成の詳細は、ドキュメントの次のトピックを参照してください:

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

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

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

Exadataクラウド・インフラストラクチャ: VMクラスタのカスタムSCANリスナー・ポート

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

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

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

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

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

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

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

Exadataクラウド・インフラストラクチャ: 非ローリング・インフラストラクチャのパッチ適用オプションが使用可能になりました

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

Exadata Cloud InfrastructureのOracle Data Guard-enabledデータベースで使用可能な顧客管理暗号化キー

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

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

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

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

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

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

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

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

Oracle Cloud Infrastructure VaultとExadata Cloud Infrastructureの統合

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

Exadataクラウド・インフラストラクチャ: Oracle Database 19cのアップグレード機能が使用可能

  • サービス: データベース
  • リリース日: 2020年12月3日
  • 影響を受けるAPIバージョン: 20160918

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

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

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

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

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

Exadataクラウド・インフラストラクチャ: フレキシブルX8Mシェイプが使用可能になりました

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

Exadataクラウド・インフラストラクチャ: Data Guardスタンバイ・データベースの設定時に既存のデータベース・ホームを使用

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