Oracle Data Guard

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

Data Guardは、Oracleデータベースが自然災害やデータ破損などのあらゆる種類の停止に耐えられるよう、1つ以上のスタンバイ・データベースの作成、メンテナンス、管理および監視を行うサービスの包括的なセットを提供します。Data Guardスタンバイ・データベースは本番データベースの正確なレプリカなので、従来のバックアップ、リストア、フラッシュバックおよびクラスタ技術と組み合せて透過的に利用し、可能なかぎり高いレベルのデータ保護、データ可用性および障害時リカバリを提供できます。Data GuardはOracle Enterprise Editionに含まれています。

Data Guard構成は、1つのプライマリ・データベースと1つ以上のスタンバイ・データベースからなります。プライマリ・データベースは、単一インスタンスOracleデータベースまたはOracle RACデータベースのいずれかになります。プライマリ・データベースと同様に、スタンバイ・データベースは、単一インスタンスOracleデータベースまたはOracle RACデータベースのいずれかになります。プライマリ・データベースのバックアップ・コピーを使用してプライマリ・データベースからREDOを直接受信するスタンバイ・データベースを最大で30作成できます。オプションで、カスケード・スタンバイを使用して、プライマリがREDOを単一のリモート宛先に転送し、その宛先がREDOを複数のスタンバイ・データベースに転送する、Data Guard構成を作成することができます。これにより、プライマリ・データベースは必要に応じて、30よりも多くのスタンバイ・データベースと効率的に同期することができます。

ノート:

Oracle Active Data Guardは基本Data Guardの拡張で、様々なタイプの処理を本番データベースからオフロードする高度な機能を提供し、データ損失ゼロの保護をどんな距離にでも拡張して、高可用性を強化します。Oracle Active Data GuardはOracle AI Database Enterprise Editionとは別のライセンスです。

スタンバイ・データベースにはいくつかのタイプがあります。Data Guardフィジカル・スタンバイ・データベースはデータ保護および障害時リカバリについてのMAAベスト・プラクティスで、最も一般的に使用されるスタンバイ・データベースのタイプです。フィジカル・スタンバイ・データベースはREDO適用(Oracleメディア・リカバリの拡張)を使用して、本番データベースの正確なフィジカル・レプリカを保持します。MAAベスト・プラクティスを使用して構成する場合、REDO適用は複数のOracle対応検証チェックを使用して、プライマリに影響を与える可能性のある破損がスタンバイに影響を与えることを防ぎます。その他のタイプのData Guardスタンバイ・データベースには、スナップショット・スタンバイ(テストまたはその他の目的で読取り/書込みでオープンするスタンバイ)、ロジカル・スタンバイ(計画停止時間の短縮のために使用)があります。

Data Guard使用の利点

更新がスタンバイ・データベースに適用される前に、Oracleデータ・ブロックおよびREDO内の構造の物理的および論理的整合性に対する複数のチェックを使用した、すべての変更のOracle対応の継続的な検証。これにより、スタンバイ・データベースが分離され、プライマリ・システムで発生する可能性のあるデータ破損による影響を受けることを防ぎます。
透過的な操作 - データ保護のためのData Guardフィジカル・スタンバイの使用には制約がありません。REDO適用はすべてのデータおよびストレージタイプ、すべてのDDL操作、およびすべてのアプリケーション(カスタムおよびパッケージ・アプリケーション)をサポートし、プライマリとスタンバイ・データベース間の整合性を保証します。
最高のパフォーマンス: 最高のリカバリ・ポイントの目標のための高速REDO転送、最高のリカバリ時間の目標のための高速適用パフォーマンス。マルチインスタンスREDO適用により、REDO適用にOracle RACのスケーラビリティが提供され、単一のデータベース・サーバーのボトルネックが排除されます。REDO適用は、基本的にOracle RACクラスタで使用可能なCPU、I/Oおよびネットワークまでスケールアップされます。8ノードRAC Exadataでは、3500 MB/秒(12 TB/時)のRedo適用レートが確認されています。
なんらかの理由でプライマリ・データベースに障害が発生した場合の、可用性を維持するためのスタンバイ・データベースへの高速フェイルオーバー。フェイルオーバーはData Guardの構成方法により、手動または自動の操作になります。
フェイルオーバーの発生後、アプリケーション・クライアントが新しいプライマリ・データベースに接続できるようにする、統合されたクライアント通知フレームワーク。
フェイルオーバーの発生後、障害の発生したプライマリ・データベースの自動または自動化された(構成による)再同期化、同期化されたスタンバイ・データベースへの迅速な変換。
すべてのネットワーク構成、可用性およびパフォーマンスSLA、ビジネス要件をサポートする、柔軟なデータ保護レベルの選択。
Data Guard Brokerコマンド・ライン・インタフェースまたはOracle Enterprise Manager Cloud Controlのいずれかを使用して、プライマリおよびそのスタンバイ・データベースのすべてを単一の構成として管理し、管理と監視を簡略化。
Data Guard Brokerは次の追加機能により大幅に管理容易性が向上しています。どの時点でも、構成によるリカバリ・ポイントの目標およびリカバリ時間の目標のSLAのサポートを自動的に監視するための、包括的な構成のヘルス・チェック、再開可能スイッチオーバー操作、合理化されたロール・トランジション、カスケード・スタンバイ構成のサポート、転送および適用ラグに対するユーザー構成可能なしきい値。
プライマリ本番データベースから送信されてカスケード・スタンバイ・データベースにより転送される単一のREDOストリームを使用した、複数のリモート宛先への効果的な転送。
スナップショット・スタンバイにより、フィジカル・スタンバイ・データベースをテストおよび本番データのレプリカの読取り/書込みが必要なアクティビティ用に読取り/書込みでオープン可能。スナップショット・スタンバイは受信は続行しますが、プライマリにより生成された更新の適用は行いません。テストが完了すると、読取り/書込みでオープンしている間の変更を最初に破棄し、次にプライマリ・データベースから受信したREDOを適用することで、スナップショット・スタンバイは同期されたフィジカル・スタンバイ・データベースへと変換されて戻されます。プライマリ・データは常に保護されます。スナップショット・スタンバイはOracle Real Application Testingと一緒に使用される場合特に有用です(スタンバイ・データベース(本番の正確なレプリカ)でのリプレイおよび後続のパフォーマンス分析のためにワークロードが本番データベースで取得されます)。
スタンバイ・データベースを使用してローリング方式でメンテナンスを実行することにより、計画停止時間を短縮。停止時間はData Guardスイッチオーバーの実行に必要な時間だけです。つまりアプリケーションはメンテナンスの実行中も使用可能なままです。
プライマリ・システムとスタンバイ・システムで異なるCPUアーキテクチャまたはオペレーティング・システムが使用されているData Guard構成の柔軟性の向上は、My Oracle Supportのノート413484.1に定義されている制限が前提です。
コンテナ・データベース(CDB)の効率的な障害時リカバリ。Data Guardフェイルオーバーおよびスイッチオーバーは、CDBに統合されたプラガブル・データベース(PDB)の数にかかわらず、CDBレベルで1つのコマンドを使用して実行されます。
特定の管理特権であるSYSDGで、Data Guardに対する標準の管理業務を処理できるようになります。この新しい権限は、特定の機能を実行するのに必要な権限のみユーザーに付与され、それ以上は付与されない、最低限の権限の原則に基づいています。SYSDBA権限は以前のリリースでも引き続き動作します。
Active Data Guard環境のスタンバイ・データベースで、Oracle AI Databaseインメモリー列ストアがサポートされます。
新しいRMANコマンドRECOVER DATABASE NOLOGGINGで修復できるようにNOLOGGING操作からの情報をトラッキングしてData Guard構成でのデータ・ウェアハウスのパフォーマンスと可用性をさらに改善します。
新しいパラメータDATA_GUARD_SYNC_LATENCYを使用して、複数のSYNCトランスポート宛先がプライマリ・データベースに与える影響を改善します。このパラメータは、少なくとも1つの同期スタンバイがREDOの受信を確認した後、後続の宛先を切断するまで、プライマリ・データベースが待機する最大時間(秒単位)を定義します。
Data Guard Brokerは、代替の宛先の管理を拡張するのみでなく、プライマリとは異なるエンディアンの宛先をサポートすることで管理性を改善します。
Data Guardは、次を含む複数の機能により、保護およびリカバリ時間目標(RTO)とリカバリ・ポイント目標(RPO)を改善します。
- マルチインスタンスREDO適用(MIRA)は、Oracle RACインスタンスでスケーラブルなREDO適用パフォーマンスを実現し、本番環境のOLTPやバッチ・ワークロードが高い場合でもRTOを削減します
- 新しいDBMS_DBCOMPパッケージを使用してプライマリ・データベースとスタンバイ・データベース・ブロックを比較し、書込み欠落を特定してそれらを効率よく解決できるようにできます。
- Fast Start Failover (FSFO)は、最大保護モードのサポートによる高可用ゼロ・データ損失構成の堅牢性を備えると同時に、構成の高可用性のために複数のオブザーバーと複数のフェイルオーバーの柔軟性を提供します。FSFOは、プライマリで書込み欠落を検出してスタンバイに自動的にフェイルオーバーするよう設定することもできます。
- 非同期構成での保管失敗後のデータ損失なしフェイルオーバーおよびアプリケーション・コンティニュイティに対するData Guard BrokerサポートによりRPOが改善されて、Data Guardロール・トランジション時のユーザー・エクスペリエンスが向上します。
Oracle Data Guard Brokerは、プライマリ宛先が使用できない場合の代替アーカイブ先管理の拡張に加えて、プライマリとは異なるendianessの宛先をサポートして管理性を改善します。
Oracle Data Guardデータベース比較ツールでは、Oracle Data Guardプライマリ・データベースとそのフィジカル・スタンバイ・データベースに格納されたデータ・ブロックを比較します。DBVERIFYユーティリティなどの他のツールでは検出できないディスク・エラー(書込み欠落など)を検出するには、このツールを使用します(Oracle Database 12cリリース2で導入済)。
Oracle Data Guard Brokerは、ファスト・スタート・フェイルオーバー構成で複数の自動フェイルオーバー・ターゲットをサポートします。複数のフェイルオーバー・ターゲットを指定すると、必要なときに自動フェイルオーバーに適したスタンバイが常に存在する可能性が大幅に向上します(Oracle Database 12cリリース2で導入済)
Oracle Data Guard Brokerのファスト・スタート・フェイルオーバーのターゲットを動的に変更します。ファスト・スタート・フェイルオーバーを無効化せずに、ファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースをターゲット・リスト内の別のスタンバイ・データベースに動的に変更できます(Oracle Database 19cで導入済)
プライマリからスタンバイ・サイトにリストア・ポイントを伝播します。プライマリ・データベースで作成されたリストア・ポイントは、フェイルオーバー操作後も使用できるようにスタンバイ・サイトに伝播されます(Oracle Database 19cで導入済)
Oracle Data Guardの自動停止解決は、特定のニーズにあわせてチューニングできます。Oracle Data Guardには、ハングしたプロセスを検出して停止するための内部メカニズムがあるため、通常の停止解決を実行できます(Oracle Database 19cで導入済)
Active Data GuardのDMLリダイレクションは、プライマリ・データベースとスタンバイ・データベース間のロード・バランシングに役立ちます。偶発的なデータ操作言語(DML)操作をActive Data Guardスタンバイ・データベースで実行できます。これにより、なんらかの書込みが必要なときにActive Data Guardスタンバイ・データベースの使用からメリットを得られるアプリケーションが多くなります。Active Data Guardのスタンバイ・データベースで偶発的なDMLが発行されると、更新は処理されるプライマリ・データベースに渡されます。トランザクションの結果のREDOによってスタンバイ・データベースが更新されてから、制御がアプリケーションに戻されます(Oracle Database 19cで導入済)

Oracle Active Data Guard

Oracle Active Data Guardはフィジカル・レプリケーション・プロセスを使用した、Oracleデータベースのリアルタイムのデータ保護および障害時リカバリに対するOracleの戦略的ソリューションです。

Oracle Active Data Guardはまた、プライマリ・データベースから受信した変更を適用する間もスタンバイ・システムを読取り専用でオープンできることにより、障害時リカバリ・システムで高い投資利益率を提供します。Oracle Active Data Guardは、Oracle Enterprise Editionに含まれるData Guard機能を大幅に拡張する高度な機能を提供する、別個のライセンス製品です。

図3-1 Oracle Active Data Guardアーキテクチャ

「図3-1 Oracle Active Data Guardアーキテクチャ」の説明

Oracle Active Data Guardにより、プライマリ・データベースから受信した変更を適用する間も読取り専用でオープンできるフィジカル・スタンバイ・システムに、プライマリ・データベースから処理をオフロードすることにより、管理者はパフォーマンスを向上できます。Oracle Active Data Guardのオフロード機能には、次のものが含まれています。読取り専用レポート作成およびグローバル一時表および一意のグローバルまたはセッション順序へのDMLを含む非定型問合せ、データの抽出、高速増分バックアップ、REDO転送圧縮、複数のリモート宛先の効果的な処理、およびプライマリ・データベースのパフォーマンスに影響を与えずにデータ損失ゼロの保護をリモート・スタンバイ・データベースへ拡張する機能。また、Oracle Active Data Guardは、自動ブロック修復を実行し、高可用性アップグレードの自動化を有効にすることによって、高可用性を向上させます。

ノート:

Oracle Active Data GuardはOracle AI Database Enterprise Editionのデータベース・オプション・ライセンスとして、別個にライセンスされます。すべてのOracle Active Data Guard機能も、Oracle Enterprise EditionのOracle Golden Gateライセンスに含まれます。これにより顧客は、Oracle Active Data Guardのスタンドアロン・ライセンス、またはすべての高度なOracleレプリケーション機能へのアクセスを取得するためのOracle GoldenGateのライセンスを選択できるようになります。

Oracle Active Data Guardの利点

Oracle Active Data Guardは前述のData Guardの利点のすべてと、次の内容を継承します。

プライマリ・データベースのパフォーマンスの向上: 読取り専用アプリケーション、レポート作成および非定型問合せのOracle Active Data Guardスタンバイ・データベースへの本番オフロード。読取り専用データベースと互換性のあるアプリケーションはOracle Active Data Guardスタンバイで実行できます。Oracleは多くのOracle E-Business Suite Reports、PeopleToolsのレポート作成、Oracle Business Intelligence Enterprise Edition (OBIEE)およびOracle TopLinkアプリケーションのOracle Active Data Guardスタンバイ・データベースへのオフロードを可能にする統合も提供します。
DMLグローバル一時表およびスタンバイ・データベースでの順序の使用により、本番データベースからOracle Active Data Guardスタンバイ・データベースにオフロードできる読取り専用アプリケーションの数が大幅に増加します。
複数のOracle Active Data Guardスタンバイ・データベースを使用して、読取りパフォーマンスを容易に高めることのできるユニークな機能は、リーダー・ファームとも呼ばれます。
Oracle Data Pumpまたはその他のソース・データベースから直接読み取る手法を使用した、データの抽出の本番オフロード。
プライマリとスタンバイ・データベースが数百または数千マイルも離れている、同期したデータ損失ゼロの構成で、ネットワーク待機時間からのパフォーマンスの影響の本番オフロード。遠隔同期はプライマリ・データベースとは独立したシステムにデプロイされた軽量インスタンス(制御ファイルおよびアーカイブ・ログ・ファイルはあるが、リカバリ・ファイルおよびデータ・ファイルはない)を使用します。遠隔同期インスタンスは、アプリケーションが同期転送のパフォーマンスの影響に耐えて最適な保護を提供できる、プライマリ・システムから最も離れた場所に配置するのが理想的です。Data GuardはREDOを遠隔同期インスタンスに同期して転送し、遠隔同期はそのREDOを最終フェイルオーバー・ターゲットであるリモート・スタンバイ・データベースに非同期に転送します。プライマリ・データベースに障害が発生すると、Data Guard構成で使用される同じフェイルオーバー・コマンドまたはOracle Enterprise Manager Cloud Controlを使用したマウス・クリック、あるいはData Guardファスト・スタート・フェイルオーバーを使用した自動フェイルオーバーにより、リモート宛先へのゼロデータ損失フェイルオーバーが開始されます。この透過性は、同期構成でのWANネットワーク待機時間のプライマリ・データベースのパフォーマンスの影響を回避しながら、REDOをプライマリ・データベースから直接受け取っているかのように、データ損失ゼロの保護をリモート・スタンバイ・データベースに拡張します。
遠隔同期を使用した複数のリモート・スタンバイ宛先にサービスするオーバーヘッドの本番オフロード。遠隔同期構成では、プライマリ・データベースは同期または非同期転送を使用して、REDOの単一のストリームを遠隔同期インスタンスへ送信します。遠隔同期インスタンスは、ソース・データベースの増分オーバーヘッドなしで、REDOを29のリモート宛先に非同期で転送できます。
Data Guardの最大可用性では、次の使用がサポートされます
```
NOAFFIRM
```
REDO転送属性。REDOがメモリーで受信されるとすぐに、スタンバイ・データベースは受領通知をプライマリ・データベースに返します。スタンバイ・データベースでは、リモート・ファイル・サーバー(RFS)によるスタンバイREDOログ・ファイルへの書込みを待っていません。
この機能により、最大可用性とSYNCREDO転送を使用するData Guard構成でのプライマリ・データベースのパフォーマンスが向上します。高速同期により、最大可用性構成内のプライマリ・データベースが、スタンバイ・データベースでの遅いI/Oによるパフォーマンスの影響から隔離されます。この新しいFAST SYNC機能は、フィジカル・スタンバイ・ターゲットとともに使用することも、遠隔同期構成内で使用することも可能です。
REDO転送圧縮の実行に必要なCPUサイクルの本番オフロード。Data Guard構成がOracle Advanced Compression用にライセンスされている場合、REDO転送圧縮は遠隔同期インスタンスにより実行できます。これはプライマリ・データベースの増分オーバーヘッドなしでバンド幅を保存します。
RMANブロック変更のトラッキングのためにOracle Active Data Guardサポートを使用することで、高速増分バックアップをプライマリ・データベースからスタンバイ・データベースへ移動することによる、本番オフロードおよびバックアップ・パフォーマンスの向上。
プライマリまたはスタンバイのいずれかで検出された、ファイル・ヘッダー破損を含むブロック破損を、アプリケーションおよびユーザーに透過的に修復するための、Oracle Active Data Guard自動ブロック修復を使用した高可用性が向上。
高可用性アップグレードにより提供される追加の自動化を使用して、新しいOracle AI Databaseリリース更新およびデータベース・リリースへのアップグレードの計画停止時間を短縮することにより、高可用性が向上。
ロールの変更によりActive Data Guardスタンバイで接続を維持することで、レポート作成が容易になり、ユーザー・エクスペリエンスが向上。データベース・ロールがプライマリ・データベースに変更され、再開している間接続は一時接続するため、ユーザー・エクスペリエンスが向上します。
Oracle Enterprise Manager診断ツールをActive Data Guardとともに使用してパフォーマンス・データをキャプチャし、自動ワークロード・リポジトリに送信できると同時に、SQLチューニング・アドバイザを使用してプライマリ・データベースのSQL文のチューニングをスタンバイ・データベースにオフロード可能。
Oracle AI Database In-Memoryオプションに対するActive Data Guardのサポートにより、レポート作成をスタンバイ・データベースにオフロードできると同時に、スタンバイ・データベースのワークロード用に調整された列ストアなどのインメモリー・オプションを利用可能。

従来のソリューションより優れているOracle Data Guardの利点

Oracle Data Guardには、従来のソリューションよりも優れた多くの利点があります。

データ破損、書込み欠落、データベースおよびサイト障害に対するデータベース・フェイルオーバーは、高速かつ自動で実行され、従来のソリューションを使用した場合は数時間かかるリカバリが、Data Guardでは数秒になります
Oracle Active Data Guard遠隔同期の使用時、ワイド・エリア・ネットワーク経由でデータ損失ゼロ
Active Data Guard遠隔同期を使用したREDO転送圧縮処理のオフロードおよび最大29のリモート宛先へのREDO送信
破損自動修復の機能により、プライマリ・データベースまたはフィジカル・スタンバイ・データベースの物理ブロックの破損を、フィジカル・スタンバイ・データベースまたはプライマリ・データベースの良好なブロックをコピーして自動的に置換
プライマリ・データベースでのデータ破損と書込み欠落に対する最も包括的な保護
ストレージ、Oracle ASM、Oracle RAC、システムの移行と一部のプラットフォームの移行、およびData Guardスイッチオーバーを使用した変更による停止時間の短縮
Data Guardのローリング・アップグレード機能による、データベースのアップグレードのための停止時間の短縮
Database In-Memory列のサポートを含め、リアルタイム問合せの適用ラグ機能を使用して、スタンバイ・データベースを読取り専用リソースとして使用するRTOおよびRPOの機能を犠牲にせずに、プライマリ・データベースのアクティビティ(バックアップ、問合せまたはレポート作成など)のオフロードが可能
サイト全体のフェイルオーバー操作の一部として、Oracle AI Database File System (DBFS)またはOracle Advanced Cluster File System (Oracle ACFS)を使用してデータベース以外のファイルを統合する機能
サイト障害の後で、インスタンスの再起動、ストレージの再マスタリングまたはアプリケーションの再接続が不要
アプリケーションに対する透過性
アプリケーション・フェイルオーバーに対する透過的な統合サポート(アプリケーション・コンティニュイティおよびトランザクション・ガード)
ネットワーク使用の効率化
Database In-Memoryのサポート
アプリケーション全体のRTOを短縮する統合されたサービスとクライアント・フェイルオーバー
Oracle RAC、RMAN、Oracle GoldenGate、Enterprise Manager、ヘルス・チェック(orachk)、DBCA、フリート・パッチ適用およびプロビジョニングなどの既存のOracleテクノロジで拡張および統合されるData Guard認識

Oracle Databaseに常駐するデータの場合、データ損失ゼロ機能が組み込まれているData Guardは、データ保護および障害時リカバリに関して従来のリモート・ミラー化ソリューションよりも効率的かつ安価でより最適化されています。Data Guardには、障害時リカバリとデータ保護のテクノロジを選択する際に、従来のリモート・ミラー化ソリューションよりもData Guardを採用する方が正しいとする、技術上およびビジネス上の理由があります。

Data Guardおよび計画メンテナンス

Data Guardスタンバイ・データベースを使用してローリング方式でメンテナンスを実行することにより、計画停止時間を短縮できます。スタンバイ・データベースで変更が最初に実装されます。新しいバージョンが本番用に確実に準備できるまで、古いバージョンでプライマリを実行し、新しいバージョンでスタンバイを実行する構成が可能です。Data Guardスイッチオーバーを実行して、本番を新しいバージョンに移行させたり、同じ変更をローリング方式で本番に適用することができます。可能性のあるデータベースの停止時間は、スイッチオーバーを実行するのに必要な時間のみです。

Data Guardスタンバイを使用してローリング方式でメンテナンスを実行するには、いくつかの方法があります。顧客の要件および好みにより、どの方法を使用するかが決まります。

Data Guard REDO適用およびStandby-First Patchの適用

Oracle Database 10gから、Data Guard REDO適用を使用してクロス・プラットフォームのサポートの柔軟性が向上しました。

特定のData Guard構成で、プライマリおよびスタンバイ・データベースは、異なるオペレーティング・システム(WindowsとLinuxなど)、ワード・サイズ(32ビット/64ビット)、異なるストレージ、異なるExadataハードウェアとソフトウェア・バージョンまたは異なるハードウェア・アーキテクチャのシステムで実行できます。REDO適用を使用して、Oracle Automatic Storage Management (ASM)への移行、単一インスタンスOracle DatabasesからOracle RACへの移行、テクノロジ・リフレッシュの実行、またはあるデータ・センターから次のデータ・センターへの移動を実行することもできます。

Oracle Database 11gリリース2 (11.2)から、Standby-First Patchの適用(REDO適用を使用したフィジカル・スタンバイ)は、ローリング方式でOracleパッチを適用および検証する目的で、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で異なるデータベース・ソフトウェア・パッチ・レベルをサポートします。Standby-First Patchの適用が可能なパッチには次のものがあります。

データベースのリリース更新(RU)またはリリース更新のリビジョン(RUR)
データベースのパッチ・セット更新(PSU)
データベースのクリティカル・パッチ・アップデート(CPU)
データベースのバンドル・パッチ

Standby-First Patchの適用は、Oracle Database Enterprise Edition 11gリリース2 (11.2)以降の認定データベース・ソフトウェア・パッチでサポートされます。

前述の計画メンテナンスの各タイプで、構成はプライマリおよびフィジカル・スタンバイ・データベースから始まります(新しいプラットフォームまたはASM、Oracle RACへの移行の場合、スタンバイは新しいプラットフォームに作成されます)。すべての変更がフィジカル・スタンバイ・データベースで実装されると、REDO適用(フィジカル・レプリケーション)が使用されてスタンバイとプライマリが同期します。Data Guardスイッチオーバーが使用され、本番がスタンバイ(新しい環境)に転送されます。

Data Guard一時ロジカル・ローリング・アップグレード

データベースの元のバージョンと変更後またはアップグレードされたバージョンを同期するのに、REDO適用(フィジカル・レプリケーション)を使用できない、多くのタイプのメンテナンス・タスクがあります。これらのタスクには、次のものが含まれます:

Standby-First Patchの適用に適格ではないデータベース・パッチまたはアップグレード。これにはデータベース・パッチ・セット(11.2.0.2から11.2.0.4)および新しいOracle Databaseのリリース(18cから19c)へのアップグレードが含まれます。
停止時間を必要とするデータベースの物理構造を変更するメンテナンスが実行される必要があります(パーティション化されていない表へのパーティションの追加、Basicfile LOBからSecurefile LOBへの変更、XML-CLOBからBinary XMLへの変更、表のOLTP圧縮への変更など)。

Data Guard SQL Apply (ロジカル・レプリケーション)を使用して、以前のタイプのすべてのメンテナンスを、Data Guardスタンバイ・データベースを使用したローリング方式で実行し、古いバージョンのデータベースと新しいバージョンのデータベースを同期できます。Oracle Database 11g以前、これにはロジカル・スタンバイ・データベースの作成、ロジカル・スタンバイでのメンテナンスの実行、スタンバイとプライマリの再同期、およびスイッチオーバーが必要でした。さらに、フィジカル・スタンバイが障害時リカバリに使用された場合、新しいフィジカル・スタンバイ・データベースは新しいバージョンで本番データベースのバックアップから作成される必要があります。これは複数のTBデータベースのアップグレード時の、多くのロジスティックおよびコスト上の課題を表しています。

Oracle Database 11g以降、データベースのローリング・アップグレードでは、一時ロジカルと呼ばれる、フィジカル・スタンバイ・データベースで始まりフィジカル・スタンバイ・データベースで終わる、新しいプロシージャを使用できます。SQL Applyは、Data Guardが古いバージョンと新しいバージョンで同期している場合のフェーズ中でのみ使用されます。フィジカル・スタンバイがすでに所定の場所にある場合、新しいロジカル・スタンバイ・データベースを作成する必要はありません。メンテナンスが完了した後に、新しいフィジカル・スタンバイ・データベースを、新しいバージョンで本番データベースのバックアップから作成する必要はありません。インプレース・フィジカル・スタンバイを持つData Guard構成のアップグレードの従来のプロセスと同様に、元のプライマリは新しいプライマリ・データベースからのREDOおよびREDO適用を使用してアップグレードまたは変更されます(単一カタログのアップグレードではプライマリおよびスタンバイ・データベースの両方を新しいOracleリリースに移行します)。

一時ロジカル・アップグレードでは、プライマリ・データベースがOracle Database 11g リリース1 (11.1)以降で、データベースがSQL Applyの前提条件を満たしていることが必要です。

一時ロジカル・ローリング・アップグレード・プロセスに必要ないくつかの手動のステップを自動化するBourneシェル・スクリプトが用意されています。

Oracle AI Database Vaultを使用するデータベースは、Oracle Data Guardデータベース・ローリング・アップグレードを使用して新しいOracle AI Databaseリリースおよびパッチ・セットにアップグレードできます(一時ロジカル・スタンバイのみ)。

Oracle Active Data Guardを使用したローリング・アップグレード

Oracle Active Data Guardを使用したデータベースのローリング・アップグレードでは、手動の一時ロジカル・ローリング・アップグレードで表される方法よりも、より簡単で、自動化された、容易に繰返し可能な、計画停止時間を短縮するための方法が提供されます。

Oracle Active Data Guardを使用したローリング・アップグレードでは、手動プロシージャで必要な42以上のステップが、いくつかの使いやすいDBMS_ROLLING PL/SQLパッケージに変換されます。DBMS_ROLLING PL/SQLパッケージを使用して実行するローリング・アップグレードが、マルチテナント・コンテナ・データベース(CDB)でサポートされます。

Oracle Active Data Guardを使用したローリング・アップグレードでは、次の操作が行われます。

アップグレード・プロセスをガイドするための、構成に固有の指示セットを含むアップグレード・プランを生成
ローリング・アップグレードのパラメータを変更
アップグレードに関連するプライマリおよびスタンバイ・データベースを構成
本番データベースから新しいバージョンへのスイッチオーバーの実行。スイッチオーバーは必要な停止時間のみ
Data Guard構成で古いプライマリと追加のスタンバイ・データベースのアップグレードを完了し、新しいプライマリと同期

Oracle Active Data Guardを使用したローリング・アップグレードには、次の利点もあります。

簡単な指定-コンパイル-実行プロトコルを提供
- コンパイル・ステップで構成エラーを検出
- ランタイム・エラーを処理中に検出
状態をデータベースに保持
- 信頼できる、繰返し可能なプロセスが可能
含まれるデータベースの数に関係なく、実行時のステップは一定
元のプライマリ・データベースでエラーを処理
アップグレードされたプライマリに対するデータ保護がいつでも可能