機械翻訳について

2 Oracle Exadata Database Service on Cloud@Customerの新機能

Oracleは、常に新しい機能をOracle Exadata Database Service on Cloud@Customerに追加しています。 この項では、リリース時の新機能の概要について説明します。

ノート:

Oracle Autonomous Database on Exadata Cloud@Customerの新機能の詳細は、「Oracle Exadata Cloud@CustomerでのADB-Dの新機能」を参照してください

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

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

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

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

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

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

ノート:

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

外部キーストアを使用したキー管理

この機能改善により、選択した外部キーストア・プロバイダにデータベース暗号化キーを格納および管理できるようになりました。 この機能により、キー・セキュリティおよび制御を強化するために、外部キーストア・プロバイダを柔軟に選択できます。

Exadata Database Service on Cloud@CustomerとExascale

Exascaleテクノロジは、Oracle Exadata Database Service on Cloud@Customerで利用できるようになりました。 次に示す最小要件を満たすすべてのOracle Exadata Database Service on Cloud@Customer ExadataインフラストラクチャにExascaleストレージを構成し、構成されたExascaleストレージを使用してVMクラスタをプロビジョニングできます。

Exadata Cloud@CustomerでExascaleを構成するための最小要件:

  • Oracle Exadata X8M-2システム・モデル以降
  • Exadata Infrastructureシステム・ソフトウェア・リリース24.1.x以降
  • Oracle Grid Infrastructure 23ai以降
  • Oracle Database 23ai以降

Oracle Databaseリリースおよびソフトウェアのサポート・タイムラインについては、My Oracle SupportポータルのRelease Schedule of Current Database Releases (Doc ID 742060.1)を参照してください。

Exascaleには、次の利点があります:

  • Exascaleは、優れたスケーラビリティとパフォーマンスのために最適化されたストレージ・アーキテクチャを導入しています。
  • デプロイメント・モデルは、以前と同様に専用のままです。 Exascaleは、同じインフラストラクチャ内の既存のデータベースおよびストレージ・サーバーの自動ストレージ管理(ASM)と共存できるようになりました。
  • Exascaleは、プラガブル・データベースの領域効率の高いスナップショットおよびクローンを提供し、スパース・クローニングに必要な複雑なテスト・マスター設定を排除します。
  • 今後のリリースでは、Exascaleストレージ上のVMイメージやVMバックアップなどのVMモビリティのユース・ケースもサポートされるため、Oracle Exadata Database Service on Cloud@Customer Exadata InfrastructuresにさらにVMクラスタを作成できます。

Oracle Exadata Exascaleの詳細は、「Oracle® Exadata Exascaleユーザーズ・ガイド」を参照してください。

Microsoft Entra ID (MS-EI)とOracle Exadata Database Service on Cloud@Customerの統合

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

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

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

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

この機能拡張により、コンテナ・データベース(CDB)およびプラガブル・データベース(PDB)に対して、Data Guardの関連付けおよびアクションとともに同時操作を実行できるようになりました。 この改善により、Oracleデータベースの管理の効率性と柔軟性が大幅に向上します。 サポートされている同時操作は次のとおりです:
  • Data Guard設定が同じOracleホーム内の別のデータベースで実行されている間(またはその逆)にCDBを作成または削除します。
  • Data Guard設定が同じOracleホーム内の別のデータベースで実行されている間にPDBを作成または削除します。その逆も同様です。
  • Data Guard設定が同じOracleホーム内の別のデータベースで実行されている間(またはその逆)に、Data Guardアクション(スイッチオーバー、フェイルオーバーおよび回復)を実行します。
  • 同じOracleホーム内でData Guardアクション(スイッチオーバー、フェイルオーバーおよび回復)を同時に実行しながら、CDBを作成または削除します。その逆も同様です。
  • 同じOracleホーム内でData Guardアクション(スイッチオーバー、フェイルオーバーおよび回復)を同時に実行しながら、PDBを作成または削除します。その逆も同様です。
  • 同じOracleホーム内でPDBを同時に作成または削除してCDBを作成または削除してします、その逆も同様です。
  • 同じOracleホーム内の異なるデータベースでCDBを同時に作成または削除します。
  • 同じOracleホーム内の異なるデータベースでPDBを同時に作成または削除します。
  • 同じOracleホーム内の異なるデータベースでData Guard設定を同時に実行します。
  • 同じOracleホーム内の異なるデータベースでData Guardアクション(スイッチオーバー、フェイルオーバーおよび回復)を同時に実行します。
  • CDB/PDBの作成または削除、Data Guard設定の実行、Data Guardアクションの実行(スイッチオーバー、フェイルオーバーおよび回復)と同時にVMクラスタ・タグを更新します。

ExaDB-C@Cのアクセス制御の委任

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

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

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

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にパッチを適用できます。

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

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

VMクラスタ操作に特定の権限を割り当てることができるようになりました。たとえば、選択したユーザー・セットにメモリーまたはCPUのスケーリングのみを許可したり、ローカル/Exadataストレージをスケーリングしたり、VMクラスタにSSHキーを追加したりできます。

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

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

インフラストラクチャ・メンテナンスは、顧客のプリファレンスに基づいて単一のスケジュール済アクティビティとして実行され、すべてのインフラストラクチャ・コンポーネントが含まれます。 コンポーネント数によっては、インフラストラクチャ・メンテナンスの実行に12の間隔を設けることができます - 30時間(または弾力的な拡張を備えたインフラストラクチャの場合はそれ以上)。

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

  • DBサーバー
  • ストレージ・サーバー
  • ネットワーク・スイッチ

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

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

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

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

ノート:

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

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

オンプレミスのOracle Key Vault (OKV)をOracle Exadata Database Service on Cloud@Customerと統合し、Oracle Key Vaultに格納されている顧客管理キーを使用してクリティカル・データを保護します。

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

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

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

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

Oracle Exadata Database Service on Cloud@Customer上のOracle Database 23ai

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

ExaDB-C@Cインフラストラクチャのホーム・リージョンの変更

この機能拡張により、ExaDB-C@Cインフラストラクチャが接続するホームOCIリージョンを変更できます。 これはフィールド・エンジニアが支援する操作であり、ホーム・リージョン変更の進行中はサービスの停止時間はありません。

ノート:

ExaDB-C@Cインフラストラクチャのホーム・リージョンを変更しても、請求には影響しません。

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

これらの新機能は次のとおりです:
  • OCI Cloud Shellを介したシリアル・コンソール・アクセス
  • コンソール履歴

この新機能により、仮想マシンのシリアル・コンソールに簡単に接続して、修正アクションを実行したり、他のユーザーがシリアル・コンソールで実行した以前のアクティビティを確認および監査できるようになりました。

ノート:

  • クラウド・シェルを使用して複数のDBノードに同時に接続することはできません。 たとえば、DBnode1へのオープン接続があり、DBnode2に接続する場合は、まずアクティブなクラウド・シェルをDBnode1から終了してから、DBnode2への接続を確立する必要があります。
  • シリアル・コンソールへのクラウド・シェル・アクセスには、クラウド・シェルに対する適切なIAM権限が必要です。詳細は、OCI Cloud Shellのドキュメントを参照してください。 また、シリアル・コンソールにアクセスし、コンソール履歴を使用するには、コントロール・プレーン・サーバー(CPS)が必要なOCIエンドポイントにアクセスできるようにファイアウォール・ルールを構成する必要があります。 オブジェクト・ストレージおよびVMコンソールの接続要件については、「表3-2」の詳細を確認してください。

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

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

単一のVM上のVMクラスタ

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

関連トピック

プラガブル・データベース(PDB)管理の拡張

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

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

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

ノート:

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

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

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

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では無償で使用できます。

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

Oracle Key Vault (OKV)とExaDB-C@Cの統合によるTransparent Data Encryption (TDE)キーの管理

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

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

ExaDB-C@Cシステムへのシリアル・コンソール・アクセスの管理

ExaDB-C@Cシステムへのシリアル・コンソール接続を作成および削除して、VMへの標準SSHアクセスが不可能な場合にSSH接続を使用してVMゲスト・オペレーティング・システムの問題を診断および解決できます。

要件: シリアル・コンソール機能を使用するには、22.Xユーザーの場合はExadata Infrastructureバージョン22.1.10以上、23.Xユーザーの場合はバージョン23.1.1以上が必要です。 シリアル・コンソール機能は、すぐに作成された新しいVMクラスタで使用できますが、次回の四半期メンテナンス・サイクル後に、以前の既存のVMクラスタでのみ使用できます。 また、opcまたはrootユーザーのパスワードの設定など、次に示すすべての前提条件を確認してください。 これらの要件を事前に満たすために必要な変更を行わないと、VMにアクセスできない場合、必要に応じてシリアル・コンソールに緊急に接続できなくなります。

ノート:

コントロール・プレーン・サーバー(CPS)に次の2つのエンドポイントが追加されました。 これらのURL形式を使用して、oci_regionをリージョンに置き換えます。

  • console1.exacc.oci_region.oci.oraclecloud.com
  • console2.exacc.oci_region.oci.oraclecloud.com

シリアル・コンソール接続を機能させるには、ファイアウォールでこれらを許可する必要があります。 詳細は、「Oracle Exadata Database Service on Cloud@Customerのネットワーク要件」表3-2 を参照してください。

暫定ソフトウェア更新

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

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

クライアントおよびバックアップNetworksのLink Aggregation Control Protocol (LACP)のサポート

Oracle Exadata Database Service on Cloud@Customer物理ネットワーク(クライアントおよびバックアップ)は、デフォルトでアクティブ・バックアップを使用するように構成されます。 このモードはほとんどのお客様にお勧めします。 ただし、LACPのサポート(802.3広告アクティブ/アクティブ・ボンディング・モード)も、必要な顧客に対して追加されました。

Exadata Infrastructureのプロビジョニング中に、LACPを使用してクライアント・ネットワークおよびバックアップ・ネットワークを構成できます。 ネットワーク・ボンディング・モードはインフラストラクチャ・レベルで設定され、将来または既存のすべてのVM Cluster Networksにグローバルに適用されます。 設定は各ネットワーク・インタフェースに個別に適用されるため、クライアント・インタフェースとバックアップ・ネットワーク・インタフェースを相互に独立して柔軟に構成できます。 たとえば、必要に応じて、バックアップ・ネットワークをLACPに、クライアント・ネットワークをアクティブ・バックアップに構成できます。

現在使用中の既存のExadata Infrastructureでは、ネットワーク・ボンディング・モードをアクティブ-バックアップからLACP(またはその逆)に変更できます。 ただし、これは非ローリング更新プロセスであり、ボンディング・モードはすべてのデータベース・サーバーで同時に変更されることに注意してください。 ネットワーク上の独自のスイッチ設定を適宜管理する必要があります。 ネットワークが停止する可能性があるため、スイッチ設定とExaDB-C@C設定が一致するまで、アプリケーションの停止時間を計画する必要があります。

LACPを使用するには、LACPが正しく動作できるように、サーバーとswitch(es)の両方に互換性のある設定が必要です。 ExaDB-C@CにLACPを使用するには、Linuxのifcfg-bondethx構成ファイルから次のパラメータと互換性があるようにネットワーク・スイッチを構成する必要があります:

BONDING_OPTS="mode=802.3ad miimon=100 downdelay=200 updelay=200 lacp_rate=1 xmit_hash_policy=layer3+4"

ホスト・オペレーティング・システムのBONDING_OPTS行は変更できないため、カスタマ・スイッチの設定は、変更せずに前述のパラメータと互換性がある必要があります。

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

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

ノート:

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

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

データベース・ソフトウェア・イメージを使用したData Guardの有効化(カスタム・イメージ)

データベース・ソフトウェア・イメージ(DSI)を使用してDBホームをプロビジョニングした場合、Data Guard操作の有効化は、プライマリDBホームと同じDSIにデフォルト設定されます。

この拡張機能を使用します。

  • 自動的に選択されたプライマリDSIをスタンバイ・データベースの別のDSIに変更できます。
  • プライマリ・データベースの作成に使用されたDSIが使用できない場合、Data Guardを有効にすると、最新のOracle公開イメージが使用されます。 オプションで、選択したDSIを持つようにスタンバイ・データベースを構成できます。

どちらの場合も、プライマリ・データベースとスタンバイ・データベースに異なるイメージが存在することに関する潜在的な問題が警告されます。

Oracle Exadata Database Service on Cloud@CustomerでのIdentity and Access Management (IAM)認証の使用

Oracle Cloud Infrastructure Identity and Access Management (OCI IAM)認証および認可を使用するようにOracle Exadata Database Service on Cloud@CustomerシステムでOracle Databaseを構成し、IAMユーザーがIAM資格証明を使用してデータベースにアクセスできるようにします。

ノート:

OCI IAMとのOracle Exadata Database Service on Cloud@Customer統合は、アイデンティティ・ドメインとの商用テナンシと、アイデンティティ・ドメインを含まないレガシーOCI IAMでサポートされています。 アイデンティティ・ドメインを含むOCI IAMは、2021年11月8日より後に作成された新しいOCIテナンシで導入されました。 新しいアイデンティティ・ドメインでは、デフォルト・ドメインOCI IAMユーザーのみがサポートされます。

リージョン間のData Guard関連付けの作成

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

ノート:

Active Data GuardまたはData Guard関連付けは、Oracle Key Vault (OKV)対応データベースではなく、Transparent Data Encryption (TDE)対応データベースに対してのみ作成できます。

マルチ・ラックの柔軟なコンピュートおよびストレージの拡張

特定のデプロイメントでは、単一のExadata Infrastructureラック内でサポートされるコンピュート・サーバーおよびストレージ・サーバーの最大数を超えて拡張できます。 コンピュートおよびストレージ拡張に対するこの拡張により、VMクラスタで使用可能な複数のラックにわたる追加のコンピュートおよびストレージをExadata Infrastructureにプロビジョニングできるようになりました。

基本システムは、マルチ・ラック拡張の対象にはなりません。 マルチ・ラックは次のシェイプにのみ適用されます:

  • X8M-2標準シェイプ
  • X9M-2標準シェイプ

ノート: 8台以上のコンピュート・サーバーまたは12台のストレージ・サーバーを備えたExadata Infrastructureには、マルチ・ラック・デプロイメントが必要です。

「マルチ・ラック」を選択すると、サーバー構成で指定できるコンピュート・サーバーおよびストレージ・サーバーの最大数になります。

  • シングル・ラック:
    • すべてのシステム: 8コンピュートおよび12ストレージ
  • Mulit-rack:
    • X7、X8およびすべてのベース・システム: 適用なし
    • X8MおよびX9Mシステム: 32のコンピューティング・サーバーと64のストレージ・サーバー

事前デプロイメント・プロセス:

  • マルチ・ラックが必要または必要な場合、FEは顧客にJSON構成ファイルを提供します。
  • 顧客は、Exadata Infrastructureの作成時または拡張時に構成ファイルをアップロードします。

デプロイメント・プロセス:

  • 顧客がインフラストラクチャを作成し、マルチ・ラックを選択した場合、コントロール・プレーンがダウンロード用の構成バンドルを正しく生成できるように、JSONをアップロードする必要があります。 JSONファイルは、追加のコンポーネントを正しく構成するために使用されます。 JSONのアップロードは、マルチ・ラックとして識別されるデプロイメントに対してのみ必須です。
  • 顧客がインフラストラクチャをマルチ・ラックとして識別できず、その後マルチ・ラックであると判断した場合は、そのインフラストラクチャを削除して再作成する必要があります。
  • 顧客が既存のインフラストラクチャを拡張し、単一のラック内に留まる場合(サーバーの追加のみ)、現在のデプロイメント・プロセスに変更はありません。
  • 顧客が既存のインフラストラクチャを拡張して新しいラックを追加したり、既存の拡張ラックを使用してインフラストラクチャを拡張する場合、マルチ・ラック・デプロイメント・タイプを選択し、新しいマルチ・ラック構成ファイル(JSON)をアップロードする必要があります。

関連トピック

自動診断収集

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

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

柔軟なコンピュート拡張

Elastic Compute Expansionでは、任意の数のDBサーバーをExadata Cloud@Customerインフラストラクチャに追加できます。 以前にリリースされたエラスティック・ストレージ拡張機能とともに、個別の数のDBサーバーおよびストレージ・サーバーをプロビジョニングすることで、新しいインフラストラクチャ・インストールをカスタマイズできるようになりました。 また、既存のインフラストラクチャ・デプロイメントのコンピュート容量を拡張するには、エラスティック・ストレージ拡張に似た方法で個々のDBサーバーを追加します。

また、特定のDBサーバーにネットワーク・リソースのサブセットを容易にする目的で、VMクラスタ・ネットワーク・オブジェクトに対して大きな変更が行われました。

インフラストラクチャのプロビジョニングおよびアクティブ化の方法については、次のリンクに従ってください。 DBサーバーがアクティブ化されると、すぐに認識されて使用できますが、追加のリソースをVMクラスタに追加する必要があります。 これは自動的には行われません。 まず、VM Cluster Networkリソースを追加してから、次のリンクの手順に従って、VMクラスタにVMを追加できます。

関連トピック

Oracle Exadata Database Service on Cloud@Customerのリソースに対するOracle Standardタグ付け

組織スキームに従って、Oracle Standardタグを使用してExadata Database Service on Cloud@Customerリソースをタグ付けできるようになりました。 リソースにタグ付けすることで、リソースをグループ化し、コストを管理し、それらがどのように使用されているかを把握できます。

Exadata Infrastructureのメンテナンス履歴

「メンテナンス履歴」ページから、メンテナンスをクリックしてメンテナンス履歴の詳細を表示できるようになりました。これには、スケジュールされたメンテナンスまたは進行中のメンテナンスに使用可能なものと同じメンテナンス詳細情報が含まれます。 メンテナンス履歴は、メンテナンスの成功と失敗の両方に使用できます。

失敗したゲストVMオペレーティング・システムの更新をロールバックまたは再試行するための拡張制御

Guest VMオペレーティング・システムの更新の適用が失敗した場合、強制的にロールバックする必要はありません。 現在のロールバック・オプションに加えて、失敗した更新を再試行して適用するための新しいオプションが追加されました。 失敗時に別のオペレーティング・システム・イメージ更新を適用する場合は、まずロールバックしてから適用する必要があります。

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クラスタの他のデータベースは終了できます。

システム・タグとしてのラック・シリアル番号のサポート

この機能改善により、OCIコンソールの「一般情報」セクションの「インフラストラクチャの詳細」ページの下に、Exadataクラウド@Customerラックのシリアル番号が表示されます。 シリアル番号は、SR時またはサービス・コール時に必要になる場合があります。

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用です。

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

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

データベース・サービス・イベント

データベース・サービス・イベント機能の実装により、ゲストVMのOracle Databasesまたはその他のコンポーネントに関するヘルスの問題について通知されます。

コントロール・プレーン・サーバー(CPS)オフライン診断レポート

Control Plane Server (CPS)オフライン診断レポートは、CPSとOCIエンドポイント間の接続の問題のトラブルシューティングに役立ちます。

データ・センターのネットワーク・インフラストラクチャの保守およびトラブルシューティングは、お客様の責任で行います。 OCIリージョンに接続するために、Exadata Cloud@Customer Gen2はインフラストラクチャと信頼性によって異なります。 OCIリージョンからExadata Cloud@Customerコントロール・プレーン・サーバー(CPS)へのExadata Cloud@Customer接続は、インフラストラクチャに加えた変更によって影響を受ける可能性があります。 ただし、Oracleではファイアウォールやネットワーキングを制御できません。

CPSとOCI間の接続が切断された場合、コントロール・プレーン・サーバー(CPS)オフライン診断レポートには、ネットワーク・インフラストラクチャの問題の診断に役立つ情報が表示されます。

レポートを表示するには、次のようにします。
  1. CPS IPアドレスを検索します。

    詳細は、「コンソールを使用したExadata Infrastructureネットワーク構成の詳細の表示」を参照してください。

  2. ローカル・ネットワークから、HTTPを介してレポートにアクセスします。

    レポートをHTML形式で表示するには、http://<CPSPublicIP>:18080/reportを使用

    レポートをJSON形式で表示するには、http://<CPSPublicIP>:18080/report/jsonを使用

ノート:

  • Exadata InfrastructureがDISCONNECTEDモードの場合、Control Plane Server (CPS)オフライン診断レポートを有効または無効にすることはできません。
  • 1時間ごとに、CPSで問題が検出されない場合でも、診断レポートはHTML形式およびJSON形式で生成および保存されます。 CPSとOCIエンドポイント間で接続の問題が発生すると、レポートがすぐに生成されます。
  • 任意の時点で、レポートはプライマリ・コントロール・プレーン・サーバーでのみ使用できます。 レポートを生成するときに、コントロール・プレーン・サーバーに指定された最初のIPアドレスが機能しない場合は、2番目のIPを試すことができます。

詳細は、「ExaCC gen2: 顧客側からのVPN/WSS接続のトラブルシューティング(ドキュメントID 2745571.1)」を参照してください。

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

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

Exadata Cloud@Customerでのプラガブル・データベースの管理

コンソールおよびAPIを使用して、Oracle Exadata Cloud@Customerシステムでプラガブル・データベース(PDB)を作成および管理します。

顧客がData Guardタイプの選択を許可

デプロイしたOracle Databaseソフトウェア・ライセンス・タイプに基づいて、Data GuardタイプActive Data GuardまたはData Guardを選択します。

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

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

Data Guard関連付けのプライマリ・データベースおよびスタンバイ・データベースのdb_unique_nameおよびSIDの指定

Oracleデータベースは3つの重要な名前で識別されます: db_namedb_unique_nameおよびinstance_name (SID)。 この新機能では、プライマリ・データベースとスタンバイ・データベース間で一貫したデータベース・ネーミング・コントロールが提供され、プライマリ・データベースとスタンバイ・データベースの両方でdb_unique_nameおよびSIDプレフィクスを入力できます。 これは、Oracle Databaseフリートを管理するための様々な命名規則をサポートするのに役立ちます。

VMクラスタ・ノードのサブ設定

ノート:

VMクラスタ・ノード・サブ設定機能は、すべてのOCI商用リージョンで使用できるようになりました。

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

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

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

詳細は、次を参照してください。
  • Oracle Exadata Cloud@Customerのシステム構成オプション
  • Oracle Exadata X9M-2システム・モデル仕様
  • VMにプロビジョニングできるローカル・ストレージの容量の見積り
  • Elastic Storage拡張の概要

SCANリスナー・ポートのカスタマイズ

VMクラスタ・ネットワーク・リソースの作成時に、許可される範囲内にSCANリスナー・ポート(TCP/IP)を指定できるようになりました。 詳細は、次を参照してください。
  • コンソールを使用したVMクラスタ・ネットワークの作成
  • コンソールを使用した構成済SCANリスナー・ポートの表示

既存のデータベース・ホームを使用したDG関連付け/スタンバイ・データベースの作成

Data Guard関連付けの有効化中に、既存のデータベース・ホームを選択するか、スタンバイ用に新しいデータベース・ホームを作成します。 詳細は、「コンソールを使用したExadata Cloud@CustomerシステムでのData Guardの有効化」を参照してください。

Exadata Cloud@Customer VMクラスタでのOracle Grid Infrastructureのアップグレード

Oracle Cloud InfrastructureコンソールまたはAPIを使用して、Exadata Cloud@Customer VMクラスタでOracle Grid Infrastructure (GI)をアップグレードします。 詳細は、「Exadata Cloud@Customer VMクラスタでのOracle Grid Infrastructureのアップグレード」を参照してください。

ゲストVMオペレーティング・システムの更新

OCIコンソールおよびAPIから自動化された方法で、Exadata Cloud@Customer VMクラスタ・ノードのオペレーティング・システム・イメージを更新します。 詳細は、「ゲストVMオペレーティング・システムの更新」を参照してください。

Oracleデータベースのアップグレード

コンソールおよびAPIを使用して、Oracle Database 19c (長期リリース)をアップグレードします。 詳細は、「Oracle Databasesのアップグレード」を参照してください。

ネットワーク検証レポートのダウンロード

ネットワーク構成の問題のトラブルシューティングで、Oracle Cloud Opsからのアクティブな関与なしでネットワーク検証失敗レポートを検証および検査します。 詳細は、「コンソールを使用したネットワーク検証レポートのダウンロード」を参照してください。

Elastic Storage拡張

Exadata Cloud@Customerインフラストラクチャに関連付けられたストレージを展開し、インフラストラクチャのプロビジョニング中および事後の両方でVMクラスタ割当てに使用できるようにします。 詳細は、次を参照してください。
  • Elastic Storage拡張の概要
  • コンソールを使用したインフラストラクチャ・ストレージの拡張
  • コンソールを使用したインフラストラクチャ・ストレージ構成ファイルのスケールのダウンロード
  • コンソールを使用した新しいストレージ・サーバーのアクティブ化
  • コンソールを使用したVMクラスタ消費で新規サーバーからのストレージ容量を使用可能化
  • コンソールを使用したスケーリング済ストレージ容量のExadata Cloud@Customerインフラストラクチャの詳細の表示
  • API操作ごとに必要な権限
  • exadata-infrastructures
  • ストレージ拡張イベント・タイプ

Oracle Databaseソフトウェア・イメージ

データベースおよびOracle Databaseホームを作成し、データベースにパッチを適用するには、データベース・ソフトウェア・イメージ・リソース・タイプを使用します。 詳細は、次を参照してください。
  • Oracle Databaseソフトウェア・イメージ
  • コンソールを使用したExadata Cloud@CustomerでのOracle Databaseホームの作成
  • コンソールを使用したデータベース・ホームでのパッチ操作の実行

Exadata Cloud@Customer インフラストラクチャのパッチ適用の自動化

Oracle管理のExadata Cloud@Customerインフラストラクチャへのパッチ適用のメンテナンス・ウィンドウをスケジュールできるようになりました。 詳細は、「コンソールを使用したOracle管理インフラストラクチャの更新の構成」を参照してください。

顧客メンテナンス連絡先

メンテナンス連絡先は、ハードウェア交換およびその他のメンテナンス・イベントのサービス・リクエストベースの通信に必要です。

プライマリ・メンテナンス連絡先を追加し、オプションで最大9つのセカンダリ連絡先を追加します。 プライマリ連絡先とセカンダリ連絡先の両方が、ハードウェアの交換、ネットワークの問題およびソフトウェア・メンテナンスの実行に関するすべての通知を受け取ります。

任意のセカンダリ連絡先をプライマリとしていつでも昇格させることができます。 セカンダリ連絡先をプライマリに昇格すると、現在のプライマリ連絡先は自動的にセカンダリに降格されます。

詳細は、次を参照してください。
  • コンソールを使用したインフラストラクチャの作成
  • インフラストラクチャ・メンテナンス連絡先の管理

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

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

詳細は、次を参照してください。
  • Oracle Exadata Cloud@Customerのシステム構成オプション
  • Oracle Exadata Cloud@Customer X8M-2システムの仕様
  • Oracle Exadata Cloud@Customerのネットワーク要件

Data Guard関連付けの有効化および管理

Oracle Data Guardは、企業データの高可用性、データ保護および障害時リカバリを保証します。

データベース間のData Guard関連付けの有効化、スイッチオーバーまたはフェイルオーバー操作を使用したData Guard関連付けでのデータベースのロールの変更、および障害が発生したデータベースの回復。

詳細は、次を参照してください。
  • Exadata Cloud@CustomerでのOracle Data Guardの使用
  • APIを使用したExadata Cloud@CustomerシステムでのData Guard関連付けの管理
  • API操作ごとに必要な権限
  • Data Guardイベント・タイプ

Oracle Exadata Cloud@Customerデプロイメント・アシスタント

Oracle Exadata Cloud@Customerデプロイメント・アシスタントは、Oracle Exadata Cloud@Customerマシンを設定し、最小限の労力でOracle Databaseインスタンスを作成できる自動化されたインストールおよび構成ツールです。

詳細は、「Oracle Exadata Database Service on Cloud@Customerデプロイメント・アシスタント」を参照してください

Oracle Grid InfrastructureおよびOracle Databaseのパッチ適用

Oracle Cloud Infrastructureコンソール、APIまたはCLIを使用して、Oracle Grid InfrastructureおよびOracle Databaseパッチを表示、事前チェックおよび適用できます。 この機能には、データベースを別のデータベース・ホームに移動してデータベースに簡単にパッチを適用する機能が含まれています。 同様に、データベースを元のデータベース・ホームに戻すことで、データベースのバージョンを簡単にロールバックできます。

詳細および手順については、次を参照してください:
  • Exadata Cloud@Customerシステムのパッチ適用と更新
  • Exadata Cloud@Customerシステムのトラブルシューティング
  • データベースおよびGrid Infrastructureパッチ適用イベント・タイプ

OCPU使用量の秒単位の請求

Oracle Exadata Database Service on Cloud@Customer Gen2は、OCPUに秒単位の請求を使用します。 つまり、OCPU使用率は1分以上の使用率で秒単位で請求されます。

共有データベース・ホームのリソース・タグ

共有データベース・ホーム・リソースに適用されるタグを追加、更新および削除します。

詳細および手順については、次を参照してください:
  • コンソールを使用したExadata Cloud@CustomerでのOracle Databaseホームの作成
  • コンソールを使用したデータベースの作成

Exadataシステムごとに複数の仮想マシンを作成および管理(MultiVM)

Exadataリソースを複数の仮想マシンにスライスします。 Oracle Exadata Database Service on Cloud@Customerで最大8つの仮想マシン(VM)クラスタを定義し、システム・リソース全体がどのように割り当てられるかを指定します。

詳細および手順については、次を参照してください:
  • コンソールを使用したVMクラスタの作成
  • コンソールを使用したVMクラスタのリソースのスケーリング
  • VMクラスタ・イベント・タイプ

クラウド接続なしでOCPUをスケーリング

Oracle Cloud Infrastructureで実行されているDatabaseサービス・コントロール・プレーンとの接続が失われた場合、Oracle Exadata Database Service on Cloud@Customerは切断モードであるとみなされます。 VMクラスタ内の仮想マシンのCPUコア数を切断モードでスケール・アップまたはスケール・ダウンします。

詳細および手順については、次を参照してください:
  • Exadata Cloud@Customerでのdbaascliユーティリティの使用について
  • dbaascli cpuscale get_status
  • dbaascli cpuscale update
  • Exadataインフラストラクチャ・イベント・タイプ

Oracle Database文字セットおよび各国語文字セットの構成

データベースを作成する前に、使用する文字セットを決定します。

データベースを作成した後で文字セットを変更すると、一般的に、時間およびリソースの面で大きなコストがかかります。 このような処理を行うには、データベース全体をエクスポートした後で再びインポートすることにより、すべての文字データの変換が必要な場合もあります。 そのため、データベース文字セットは、インストールの時点で慎重に選択することが重要です。

詳細および手順については、「コンソールを使用したデータベースの作成」を参照してください。

Oracle Exadata Database Service on Cloud@Customerインフラストラクチャのプロビジョニング中のタイムゾーンの指定

Oracle Exadata Database Service on Cloud@Customerインフラストラクチャのデフォルトのタイム・ゾーンはUTCです。 時間は、オペレーティング・システムとデータベース・レベルでUTC形式で表示されます。 Oracle Exadata Database Service on Cloud@Customerインフラストラクチャのプロビジョニング中に別のタイム・ゾーンを選択できます。 ただし、タイムゾーンの変換が不要になるため、OracleではデータベースのタイムゾーンをUTC (0:00)に設定することをお薦めします。

詳細および手順については、「コンソールを使用したインフラストラクチャの作成」を参照してください。

Oracle Exadata Database Service on Cloud@Customerの共有データベース・ホーム

複数のデータベースには単一のOracle Homeを使用します。 領域節約に加え、Oracle Databaseホームを複数のデータベースと共有すると、次の利点があります:
  • 複数のデータベースに必要な個別パッチは、より少ないOracle Homesにのみ適用する必要があり、パッチ適用のオーバーヘッドと管理が削減されます。
  • スペースの節約。たとえば、Oracleソフトウェア・バージョンごとに1つのOracle Homeのみを使用(複数も可能です)。
  • Oracle Databaseは、DBホームにパッチを適用するのではなく、ホーム間でデータベースを移動することでパッチ適用します。
  • パッチをロールバックせずにデータベースを下位のDBホーム・バージョンに移動する場合のフォールバック。
  • 新しいホームおよび新しいバージョンのソフトウェア・インストールでは、データベースの操作が中断されません。
  • Oracleバイナリをさらにレイアウトする必要がないため、データベースのパッチ適用時間が短縮されます。

Oracle Cloud Infrastructureコンソール、APIまたはCLIを使用して、Oracle Exadata Database Service on Cloud@Customerでデータベースの共有Oracle Databaseホームを作成および管理します。

詳細および手順については、「Exadata Cloud@CustomerシステムでのOracle Databaseホームの作成」を参照してください。

X7-2システムのサポート

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

詳細は、「Oracle Exadata X7-2システム・モデル仕様」を参照してください。