Oracle Active Data Guard リアルタイム・データ保護と可用性 · このホワイト・ペーパーでは、Active Data Guard（オプション・ライセンス）と

Oracle Active Data Guard リアルタイム・データ保護と可用性 Oracle ホワイト・ペーパー | 2018 年 5 月

Oracle Active Data Guardリアルタイム・データ保護と可用性

目次

はじめに ........................................................................................................................................................... 1

Oracle Active Data Guard – 概要 ................................................................................................................ 2

Oracle Data Guard によるスタンバイ・データベースの同期 ............................................................. 3

REDO 転送サービス .............................................................................................................................. 4

REDO Apply サービス........................................................................................................................... 6

Oracle データの継続的な検証 ............................................................................................................ 6

保護モード ....................................................................................................................................................... 7

Oracle Data Guard の構成の管理 ............................................................................................................... 8

ロール管理サービス - スイッチオーバーとフェイルオーバー ................................................... 8

ファスト・スタート・フェイルオーバー ........................................................................................ 9

クライアント・フェイルオーバーの自動化 .................................................................................... 9

Oracle Data Guard による計画停止時間の短縮 .................................................................................... 10

プラットフォーム/クラウドの移行、ハードウェアと OS のメンテナンス、

データセンターの移設 ....................................................................................................................... 10

Standby-First Patch によるパッチの保証 ..................................................................................... 11

Oracle Active Data Guard .......................................................................................................................... 11

リアルタイム問合せ – パフォーマンスと ROI .............................................................................. 11

自動ブロック修復機能 – 高可用性 .................................................................................................. 12

Far Sync - いかなる距離でもデータ損失ゼロの保護 ................................................................... 13

Active Data Guard を使用したデータベース・ローリング・アップグレード ..................... 14

アプリケーション・コンティニュイティ ...................................................................................... 15

Oracle Global Data Services ............................................................................................................. 15

関連テクノロジー ........................................................................................................................................ 16

ストレージのリモート・ミラー化 .................................................................................................. 16

Oracle GoldenGate ............................................................................................................................. 17

Zero Data Loss Recovery Appliance ............................................................................................... 19

Oracle Active Data Guardリアルタイム・データ保護と可用性

Oracle Real Application Clusters（Oracle RAC） ........................................................................ 19

Oracle Multitenant ............................................................................................................................. 19

Oracle Engineered Systems と Oracle Data Guard ..................................................................... 20

顧客事例 ................................................................................................................................................ 21

結論 ................................................................................................................................................................. 21

付録 A：Data Guard と Active Data Guard の機能の概要 ................................................................. 22

付録 B：一時ロジカル・データベース・ローリング・アップグレード ......................................... 26

1 | Oracle Active Data Guardリアルタイム・データ保護と可用性

はじめに

高可用性（HA）アーキテクチャを適切に導入すると、冗長システムとソフトウェアによってシ

ングル・ポイント障害が排除され、停止時間の発生とデータの損失を防ぐことができます。こ

の原理はミッション・クリティカルなデータベースにも当てはまります。管理者のミス、シス

テムやソフトウェアの障害によるデータの破損、またはサイト全体の障害によってデータベー

スの可用性が影響を受ける場合があります。複数のサーバー上で動作するクラスタ化された

データベースであっても、適切に保護されていなければ、シングル・ポイント障害が発生する

可能性があります。クラスタ化されたデータベースでは非常に優れたサーバーHA を実現できま

すが、それも結局のところは、共有ストレージ上で単一のデータベースを動作させる緊密に結

合されたシステムにすぎません。

シングル・ポイント障害による影響を防ぐ唯一の方法は、すでに別のシステム上で動作してい

る本番データベースの完全に独立した（理想的には別の場所にデプロイされた）コピーを持ち、

本番データベースが何らかの理由で使用できなくなった場合にすぐにアクセスできるようにし

ておくことです。

Oracle Active Data Guard は、ミッション・クリティカルな Oracle Database のシングル・ポイン

ト障害を排除できるもっとも包括的なソリューションです。このソリューションは、本番デー

タベースの同期された物理レプリカを遠隔地に保持することによって、もっとも単純かつ経済

的な方法でデータの損失と停止時間の発生を防ぎます。何らかの理由で本番データベースが使

用できなくなると、クライアント接続が、迅速に（また一部の構成では透過的に）、同期され

ているレプリカにフェイルオーバーされ、サービスがリストアされます。Oracle Active Data

Guard は、レポート作成アプリケーション、非定型の問合せ、およびデータ抽出の、本番データ

ベースの読取り専用のコピーへのオフロードを可能にすることにより、コストのかかる無駄な

冗長性を排除します。Active Data Guard は、Oracle Database と緊密に統合され、リアルタイ

ム・データ保護と可用性に焦点を合わせており、ストレージのリモート・ミラー化やその他の

ホストベース・レプリケーション・ソリューションに見られるような妥協がありません。

このホワイト・ペーパーでは、Active Data Guard（オプション・ライセンス）と Oracle Data

Guard（Oracle Database Enterprise Edition に組み込まれている）の両方について詳しく説明しま

す。対象読者は、データの損失や停止時間の発生を防ぐための各種の方法を評価する IT マネー

ジャーやデータベース管理者、および Active Data Guard の機能を深く理解しようと努めている

技術スタッフです。


Oracle Active Data Guard – 概要

Oracle Database 18c の Oracle Active Data Guard1が備える機能によって実現される、導入と管理が容易な高機能のアクティブ・ディザスタ・リカバリ・システムにより、データ損失の防止、高可用性の実装、リスクの排除、投資収益率の向上という戦略的な目標をさらに強化できます。

Active Data Guard（図 1）は、以下のような多数のメリットを提供します。

» 読取り専用レポート、非定型の問合せ、およびグローバル一時表への書込みを行う読取り中心のアプリケーションを、ディザスタ・リカバリにも使用されるスタンバイ・データベースにオフロードできます。これにより、使用可能な容量が増加します。また、競合するワークロードの分離により応答時間が改善されます。さらに、シンプルな物理レプリケーションを使用しながらスタンバイ・システムの投資収益率（ROI）を向上させることができます。

» プライマリ・データベースとスタンバイ・データベースのいずれの場合も、どこで物理的なブロックの破損が生じても自動的に修復されるため、ユーザーへのサービス提供が中断されず、管理者による手動操作も不要になります。

» データ損失ゼロの保護を、プライマリ・データベースとスタンバイ・データベースが数千マイル離れた構成に実装できます。これにより、プライマリ・データベースのパフォーマンスが低下したり、複雑さが増したり、コストのかかる独自規格のストレージやネットワーク・デバイスが必要になったりすることはありません。データ保護のためにパフォーマンス面で妥協する必要はなくなります。

» データベースのローリング・アップグレードをより簡単かつ確実に実行できる新しい自動化機能を使用することにより、計画停止時間は最小限に短縮され、本番データベース環境にさまざまな変更を加えるリスクも抑えられます。

図1：Oracle Active Data Guard

1 www.oracle.com/goto/dataguard

http://www.oracle.com/goto/dataguard


Active Data Guard は、Oracle Database Enterprise Edition に付属する Data Guard 機能のスーパーセットでもあります。このため、Active Data Guard は、シングル・ポイント障害を排除して、リアルタイム・データ保護と可用性を提供できます。これは、障害、データ破損、人為的エラー、災害から Oracle データを保護する 1 つ以上の同期スタンバイ・データベースを作成および保持する、管理、監視、自動化ソフトウェアによって実現されます。

Active Data Guard ではシンプルな物理レプリケーションが使用されますが、Oracle Database と緊密に統合されているため、プライマリ・データベースとスタンバイ・データベースの他に類を見ない分離により、データ損失に対する最高レベルの保護が実現されます。Active Data Guard は、同期保護（データ損失ゼロ）と非同期保護（データ損失がほぼゼロ）の両方をサポートします。ミッション・クリティカルなアプリケーションの高可用性を保持するために、データベース管理者（DBA）は、プライマリ・システムが何らかの理由で使用できなくなった場合のスタンバイ・データベースへの手動のフェイルオーバーまたは自動のフェイルオーバーを選択できます。

Active Data Guard は、Oracle Database Enterprise Edition のオプション・ライセンスです。以降の項で説明するどの機能も、‘Active Data Guard’を明示的に指している場合は、Active Data Guard のライセンスが必要です。また、どの機能も、Oracle Database Enterprise Edition に付属する‘Data Guard’を明示的に指している場合は、オプション・ライセンスは不要です。Active Data Guard は、Data Guard 機能のスーパーセットであり、その機能をすべて継承します。

「Active Data Guard は、高可用性とディザスタ・リカバリ（DR）の境界をなくします。VocaLink では、合計で約 8 分の停止時間という、以前に使用していたディザスタ・リカバリ・アーキテクチャよりもはるかに短い時間で完全なサイト・フェイルオーバーを実行できるようになりました。Data Guard の Standby-First Patch も、計画的なメンテナンスの停止時間を短縮する上で役立ちます。」

VocaLink、データベース・テクニカル・アーキテクト、Martin McGeough 氏 2

Oracle Data Guardによるスタンバイ・データベースの同期

Data Guard の構成には、プライマリ・データベースと呼ばれる本番データベースと、スタンバイ・データベースと呼ばれる最大 30 の直接接続レプリカが含まれます。プライマリ・データベースとスタンバイ・データベースは、Oracle Net Services を使用した TCP/IP を介して接続されます。データベース同士の通信が可能であれば、設置場所に関する制約はありません。スタンバイ・データベースは、本番アプリケーションまたはデータベースの停止時間を必要とすることなく、プライマリ・データベースのバックアップから作成されます。スタンバイ・データベースが作成および構成されると、Data Guard は、プライマリ・データベースで REDO（トランザクションを保護するためにすべての Oracle Database によって使用される変更ベクトル情報）が生成されるときにその REDO を送信し、スタンバイ・データベースに適用することにより、プライマリ・データベースとスタンバイ・データベースを自動的に同期します。

2 http://www.oracle.com/technetwork/database/availability/vocalink-exadata-1940109.pdf

http://www.oracle.com/technetwork/database/availability/vocalink-exadata-1940109.pdf


REDO転送サービス

Data Guard の REDO 転送サービスでは、プライマリ・データベースからスタンバイ・データベースへの REDO の送信に関するすべての側面を処理します。ユーザーがプライマリ・データベースでトランザクションをコミットすると、REDO レコードが生成され、ローカルのオンライン・ログ・ファイルに書き込まれます。Data Guard の転送サービスは、プライマリ・データベースのログ・バッファ（システム・グローバル領域内で割り当てられているメモリ）からスタンバイ・データベースへ同じ REDO を同時に直接送信し、スタンバイ・データベースはスタンバイ REDO ログ・ファイルにREDO を書き込みます。Data Guard の REDO 転送は、以下の理由により非常に効率的です。

» Data Guard によるメモリからの直接送信により、プライマリ・データベースでのディスク I/Oオーバーヘッドが回避されます。これは、他のホストベースのレプリケーション・ソリューションが、レプリケーション・プロセスで使用する専用ファイルによって、ディスクからデータを読み取り、取得したデータをディスクに書き込むことで、プライマリ・データベースでのI/O を向上させるのとは異なります。

» Data Guard は、データベース REDO だけを送信します。これは、リアルタイム同期を維持するためにすべてのファイルのすべての変更されたブロックを送信しなければならないストレージのリモート・ミラー化とはまったく対照的です。オラクルが実施したテストによると、ストレージのリモート・ミラー化では、Data Guard よりも、最大 7 倍のネットワーク・データが送信され、27 倍のネットワーク I/O 操作が必要であることが示されています。

» Data Guard のフィジカル・スタンバイでは、論理レプリケーション・ソリューションで必要になるプライマリ・データベースでのサプリメンタル・ロギングの I/O オーバーヘッドも回避されます。I/O への影響を最小限に抑える物理レプリケーションの利点は、スタンバイ・データベースにも及びます。論理レプリケーションとは異なり、Data Guard の適用プロセスでは、スタンバイ・データベースでディスクに書き込んでアーカイブする必要のあるローカル REDO が生成されません。

Data Guard では、同期と非同期の 2 つの転送サービスを選択できます。

同期 REDO 転送では、REDO が受信され、ディスク（スタンバイ REDO ログ・ファイル）に書き込まれたというスタンバイ・データベースからの確認を待ってから、プライマリ・データベースがコミットの成功を伝える信号をアプリケーションに送信します。同期転送と、Data Guard の適用サービスによるトランザクション・セマンティクスの高度な認識との結合により、プライマリ・データベースに突然障害が発生しても、データ損失ゼロが保証されます。

プライマリ・サイトとスタンバイ・サイトの距離には物理的な制限はありませんが、サポートできる距離には実際的な制限があります。距離が遠くなるほど、プライマリ・データベースがスタンバイ・データベースからの確認を待たなければならない時間も長くなり、アプリケーションの応答時間とスループットに直接影響します。このパフォーマンスに関する懸念に対処するように設計された Oracle Database 12c Release 1 には、次の 2 つの新しい同期転送オプションが実装されました。

» Fast Sync は、データ損失ゼロの同期構成でパフォーマンスを向上させるための簡単な方法を提供します。Fast Sync を使用すると、スタンバイはスタンバイ REDO ログ・ファイル（SYNC NOAFFIRM）へのディスク I/O を待たずに、REDO をメモリ内に受信したらすぐにプライマリ・データベースに確認応答します。これにより、プライマリとスタンバイの間の合計のラウンドトリップ時間が短縮されるため、同期転送によるプライマリ・データベースのパフォーマンスへの影響が軽減されます。Fast Sync では、スタンバイ・データベースの I/O が完了する前にプ


ライマリ・データベースとスタンバイ・データベースの両方で障害が同時発生するとデータが損失する危険性がごくわずかながら存在します。ただし、その危険性のある時間は非常に短く（両方の障害が数ミリ秒の間に発生する必要がある）、そのような状況は極めて特異なものであるため、発生する可能性はほとんどありません。Fast Sync は、Data Guard に付属しています。

» Far Sync により、リモート・スタンバイ・データベースが数千マイル離れていても、プライマリ・データベースのパフォーマンスに影響したり、コストや複雑さを実質的に増したりすることなく、データ損失ゼロのフェイルオーバーを実現できます。Far Sync は、Active Data Guardに付属しています（詳しくは、このホワイト・ペーパーの「Oracle Active Data Guard」の項を参照）。

非同期 REDO 転送では、ローカル・ログ・ファイルへの書込み完了の直後にアプリケーションにコミットの成功が伝えられるため、プライマリ・データベースのパフォーマンスは低下しません。プライマリ・データベースは、スタンバイ・データベースの受信確認を待ちません。任意の時点において、コミットされたトランザクションのすべての REDO がスタンバイ・データベースによって受信されるという保証があるわけではないため、このパフォーマンス上の利点には、潜在的に少量のデータ損失が伴う可能性があります。

Oracle Data Guard 転送と複数スタンバイ構成：複数のスタンバイ・データベースをサポートするData Guard の機能を使用する企業が増えています。たとえば、HA を高める場合にはローカルのスタンバイに同期送信し、ディザスタ・リカバリ（DR）の場合にはリモートのスタンバイに非同期送信するプライマリ・データベースがあります。あるいは、ローカルのスタンバイ・データベースで、リモートの場所に配置されている第 2 のスタンバイ・データベースに対して、REDO をカスケードで送信できます。リアルタイム・カスケード（Oracle Database 12c Release 1 現在で使用できるActive Data Guard の機能）を使用すると、ローカルのスタンバイ・データベースは非同期転送を使用して REDO をリモート・スタンバイ・データベースに転送して、スタンバイ・データベースとプライマリ・データベースの緊密な同期を維持します。

ローカルとリモートの両方のスタンバイ・データベースを持つ複数スタンバイ構成には、以下のメリットがあります。

» 最高レベルのデータ保護：ローカルの Data Guard スタンバイ・データベースは非常に近くにあるため、データベースのパフォーマンスにほとんど影響を与えずにデータ損失ゼロのフェイルオーバーを実現できます。Data Guard のファスト・スタート・フェイルオーバーでも、人が介入する必要のない自動フェイルオーバーを実行できます。

» 最高レベルの可用性：クライアントのデータベース接続は、透過的アプリケーション・フェイルオーバーと高速接続フェイルオーバーにより、迅速かつ透過的にフェイルオーバーできます。実行中のトランザクションも、アプリケーション・コンティニュイティ（Oracle Database 12c Release 1 の新機能、Active Data Guard または Oracle RAC に付属）を使用して透過的にフェイルオーバーされます。

» 継続的なデータ保護による容易な操作：ローカル・スタンバイ・データベースへのフェイルオーバーが実行されると、リモート・スタンバイ・データベースがフェイルオーバーの発生を自動的に検出し、新しいプライマリ・データベースから REDO を受信し始めるため、DR 保護機能が常に維持されます。


» 優れた費用対効果と柔軟性：スタンバイ・データベースは、障害発生時に本番データベースとして稼働する準備を常に整えていますが、Data Guard スナップショット・スタンバイを使用してテスト・システムとして機能する多目的のデータベースとして使用可能です。また、プライマリ・データベースからの読取り専用ワークロードのオフロード、高速増分バックアップのオフロード、または Active Data Guard を使用したデータベースのローリング・アップグレードを実行するために使用することもできます。

自動ギャップ解消：プライマリ・データベースとスタンバイ・データベースの接続が（ネットワーク障害やスタンバイ・サーバー障害のために）切断されると、そのスタンバイ・データベースへのREDO の送信が停止します。プライマリ・データベースはトランザクションの処理を続行し、スタンバイ・データベースへの新しい接続が確立されるまでの間、REDO のバックログを蓄積します。この切断期間はアーカイブ・ログ・ギャップとして報告され、転送ラグとして測定されます。この状態の間、Data Guard は、切断されたスタンバイ・データベースのステータスを監視し、接続の再確立を検出し、切断期間に生成されたアーカイブ・ログ・ファイルを送信することによってスタンバイ・データベースとプライマリ・データベースを自動的に再接続し、再同期させます。最大保護モードでは、切断されたスタンバイ・データベースが残された最後の同期 REDO の送信先となっている場合、プライマリ・データベース自体が中断してデータ損失ゼロを保証するため、REDOギャップが発生することはありません。詳しくは、このホワイト・ペーパーで後述する「保護モード」を参照してください。

REDO Applyサービス REDO Apply サービスは、フィジカル・スタンバイ・データベース上で動作します。REDO Apply は、スタンバイ REDO ログ・ファイルから REDO レコードを読み取り、Oracle 検証機能を実行して REDOが破損していないことを確認してから、スタンバイ・データベースにそれらの REDO の変更を適用します。REDO Apply は、REDO 転送とは無関係に機能するため、プライマリ・データベースのパフォーマンスとデータ保護（リカバリ・ポイント目標（RPO））はスタンバイ・データベースでのREDO Apply のパフォーマンスの影響を受けません。REDO Apply サービスが停止するような極端な場合でも、Data Guard の転送は、REDO をスタンバイ・データベースに送信することによってプライマリ・データベースのデータを引き続き保護し、スタンバイ・データベースでは、REDO Applyプロセスが再開されたときに後で使用できるように REDO がアーカイブされます。REDO Apply プロセスは、スタンバイ・クラスタに複数のノードが存在する場合でも、フィジカル・スタンバイ・システムの 1 つのノード上で実行されます。Oracle Database 12c Release 2 以降、REDO Apply サービスは複数のノードに分散可能（「マルチインスタンス REDO Apply」と呼ばれます）になっており、適用速度がほとんど直線的に高まっています。

Oracleデータの継続的な検証 Data Guard は、スタンバイ・データベースに REDO が適用される前に、Oracle Database のプロセスを使用して常に REDO を検証します。REDO は、プライマリ・データベースのログ・バッファから直接送信されるため（ネットワーク経由のメモリ・コピー（memcpy）ファンクションに相当）、プライマリ・データベースの I/O の破損から完全に切り離されています。Oracle Database は、Oracle ブロック形式に関する情報を使用して、多数の主要インタフェースで、REDO の転送や REDO Apply の間に破損検出チェックを可能にすることで、物理と論理の両方のブロック内整合性を確保


します。また、スタンバイ・データベースで実行されるソフトウェア・コードパスは、プライマリ・データベースとは基本的に異なります。このため、プライマリ・データベースに影響する可能性があるファームウェア・エラーおよびソフトウェア・エラーからスタンバイ・データベースが事実上切り離されます。

Data Guard は、書込み損失によって発生する発見されにくい破損も検出します。書込み損失は、永続ストレージで実際に発生しなかった書込みの完了を I/O サブシステムが確認すると発生します。この I/O サブシステムは、後続ブロックの読取りで古いバージョンのデータ・ブロックを返します。次に、このブロックがデータベースの他のブロックの更新に使用されることで破損が広がります。Data Guard は、スタンバイ・データベースで書込み損失検証を実行してこれを防ぎます（プライマリ・データベースからこのオーバーヘッドをオフロード）。Data Guard は、書込み損失がプライマリ・データベースで発生した場合でもスタンバイ・データベースで発生した場合でも、書込み損失による破損を検出します。Oracle Database 18c のリリース時点で、書込み損失検出（シャドウ書込み損失保護と呼ばれます）を本番データベースに実装することにより、スタンバイが構成されていなかったり、その時点で REDO が適用されていなかったりする場合でも、書込み損失を検出可能になりました。シャドウ書込み損失保護機能では、大きなデータ破損が発生する前に書込み損失を検出します。シャドウ書込み損失保護は、Oracle Data Guard スタンバイ・データベースなしで、データベース、表領域、またはデータファイルに対して有効にすることができます。シャドウ書込み損失保護により、書込み損失を迅速に検出して直ちに対処することができるため、データ破損のためにデータベース内で発生する可能性があるデータ損失が最小限に抑えられます。

保護モード

表 1 に示すように、Data Guard には、コスト、可用性、パフォーマンス、データ保護のバランスを取るためのモードが 3 種類用意されています。各モードは、特定の REDO 転送メソッドを使用し、プライマリ・データベースとそのスタンバイ・データベースとの接続が失われた場合の Data Guardの構成の動作を定義します。

表1：Oracle Data Guardの保護モード

モードデータ損失のリスク転送スタンバイ・データベースからの確認応答がない場合の処理：

最大保護データ損失ゼロ二重障害保護 SYNC

トランザクションのREDOがスタンバイREDOログに書き込まれ

ているスタンバイ・データベースから確認応答を受信してからの

み、コミットの成功をアプリケーションに通知します。

最大可用性データ損失ゼロ単一障害保護

SYNC FAST SYNC FAR SYNC

スタンバイ・データベースからの応答を受信するか、または

NET_TIMEOUTしきい値に指定された時間が過ぎたら、いずれの

場合もコミットの成功をアプリケーションに通知します。

最大パフォー

マンス最小限のデータ損失

の可能性あり ASYNC プライマリはスタンバイからの応答を待つことなく、コミットの

成功をアプリケーションに通知します。


Oracle Data Guardの構成の管理

SQL*Plus を使用して、プライマリおよびスタンバイ・データベースとそれらのさまざまな相互作用を管理できます。また、Data Guard には、Data Guard 構成の作成、メンテナンス、監視を自動化および一元化するための、Oracle Data Guard Broker と呼ばれる分散型管理フレームワークも実装されています。スタンバイ・データベースの実際の作成は、規定された方法（Oracle Enterprise Manager Cloud Control、Oracle RMAN の duplicate コマンド、または 18c の新機能 Database Creation Assistant（DBCA））のいずれかを使用して Data Guard Broker の外部で実行されます。

データベース管理者（DBA）は、Data Guard Broker のコマンドライン・インタフェースまたはOracle Enterprise Manager Cloud Control を使用して、Data Guard Broker を対話操作できます。Enterprise Manager には、Data Guard 構成とそのスタンバイ・データベースの作成をさらに簡単に行うためのウィザードがあります。Data Guard の主要なメトリック（REDO Apply ラグ、REDO 転送ラグ、REDO 速度、構成ステータスなど）は、Data Guard 管理ページ（図 2 を参照）と統合された HA コンソールの両方に表示されます。Enterprise Manager では、いずれかのメトリックが事前に設定されたしきい値を超えた場合には、自動通報も有効にします。

ロール管理サービス - スイッチオーバーとフェイルオーバー Data Guard のロール管理サービスを使用すると、指定したスタンバイ・データベースをプライマリ・ロールに迅速に移行できます。スイッチオーバーは、オペレーティング・システムやハードウェアのアップグレード、Oracle Database のローリング・アップグレード、およびその他のデータベースのメンテナンスなどの計画メンテナンス時の停止時間を短縮するために使用される計画的なイベントです。メンテナンスは最初にスタンバイ・データベースで実行され、スイッチオーバーによって、プライマリ・データベースから新バージョンで動作するスタンバイ・データベースへと本番環境が移行されます。スイッチオーバーは、使用される転送方法や保護モードにかかわらず、常にデータ損失ゼロの操作です。

フェイルオーバーを行うと、元のプライマリ・データベースが計画外停止している間、スタンバイ・データベースが新しいプライマリ・データベースとしてオンラインになります。フェイルオーバーでは、プライマリ・ロールを引き継ぐためにスタンバイ・データベースを再起動する必要はありません。また、元のプライマリ・データベースがマウント可能であり、そのファイルが損傷していないかぎり、フラッシュバック・データベースを使用して、元のプライマリ・データベースを迅速に回復させてスタンバイ・データベースとして再同期できます。バックアップからリストアする必要はありません。

手動フェイルオーバーは、Oracle Enterprise Manager の GUI インタフェース、Data Guard Broker のコマンドライン・インタフェース、または SQL*Plus を使用して、DBA が開始します。オプションで、Data Guard では、Data Guard Broker のファスト・スタート・フェイルオーバー（FSFO）を使用して自動フェイルオーバーを実行できます。


図2：Oracle Enterprise Manager Cloud ControlでのOracle Data Guardの管理

ファスト・スタート・フェイルオーバー

Data Guard Broker のファスト・スタート・フェイルオーバーにより、Data Guard では、フェイルオーバーを起動するために人の介入を必要とせずに、事前に選択したスタンバイ・データベースに自動的にフェイルオーバーできます。Data Guard は、構成のステータスを継続的に監視し、必要に応じてフェイルオーバーを開始します。ファスト・スタート・フェイルオーバーには、スプリット・ブレイン（複数のデータベースが同時にそのデータベースをプライマリと認識する状態）を回避する制御機能が組み込まれています。このシンプルでありながら厳密に制御されたアーキテクチャにより、ファスト・スタート・フェイルオーバーは、HA と DR の両方が必要な場合に最適です。

クライアント・フェイルオーバーの自動化

データベース・フェイルオーバーを迅速に実行する能力は、HA のための最初の要件にすぎません。アプリケーションは、障害が発生したプライマリ・データベースへの接続をすみやかに解除し、新しいプライマリ・データベースに迅速に再接続できる必要もあります。

Data Guard のコンテキストにおける効率的なクライアント・フェイルオーバーには、次の 3 つの要素があります。

» 高速データベース・フェイルオーバー

» 新しいプライマリ・データベースでのデータベース・サービスの高速起動

» クライアントへのすみやかな通知と新しいプライマリ・データベースへの再接続


Data Guard Broker によって管理されるロール移行により、人が介入することなく、スタンバイ・データベースのプライマリ・ロールへの自動移行、プライマリ・ロールに適したデータベース・サービスの開始、障害が発生したプライマリ・データベースとの接続の解除（TCP タイムアウトからの切り離し）のクライアントへの通知、および新しいプライマリ・データベースへのクライアントの接続を実行できます。また、グローバル・ロードバランサと DNS フェイルオーバーを使用してユーザー接続を新しい中間層にリダイレクトする場合は、Data Guard のロール変更イベントを使用することによって、それを自動化できます。

アプリケーション・コンティニュイティは、Oracle Database 12c Release 1 以降の新機能の 1 つで、この機能により、データベースのフェイルオーバーが発生したときに実行中だったトランザクションをロールバックして新しいプライマリ・データベースで再送信しなくても、そのトランザクションを完了することができます。アプリケーション・コンティニュイティは、Active Data Guard に付属しています。

Oracle Global Data Services（Oracle GDS）は、Oracle Database 12c Release 1 以降の新機能の 1 つで、この機能により、インテリジェントなロードバランシングとクライアント・フェイルオーバーの概念が、可用性を維持するために使用可能なフェイルオーバー・ターゲットが複数存在するグローバルな分散環境に拡張されます。前述の Data Guard の複数スタンバイ構成は、そのような環境の一例です。Oracle GDS は、Active Data Guard に付属しています。

Oracle Data Guardによる計画停止時間の短縮

Data Guard を使用して、さまざまな種類の計画メンテナンスにおける停止時間とリスクを軽減できます。一般的なアプローチでは、最初にスタンバイ・データベースに変更内容を実装し、テストしてからスイッチオーバーを行います。スタンバイ・データベースでメンテナンスが行われている間、本番アプリケーションは影響を受けることなくプライマリ・データベースで実行されます。停止時間は、本番データベースの処理をアップグレードされたスタンバイ・データベースに切り替えるために必要な時間までに制限されます。使用されるプロセスの具体的な詳細は、行われているメンテナンスの種類によって異なります。

プラットフォーム/クラウドの移行、ハードウェアとOSのメンテナンス、データセンターの移設

Data Guard の REDO Apply によって実現される柔軟性により、プライマリ・データベースとスタンバイ・データベースは、オペレーティング・システムまたはハードウェア・アーキテクチャが異なるシステム上で動作できるようになります。Data Guard 構成でサポートされている混合プラットフォームの組合せについて、詳しくは My Oracle Support Note 413484.1 を参照してください 3。REDO Apply を使用して、Oracle のクラウドへのオンプレミス本番データベースの移行を促進し、テクノロジー更新や一部のプラットフォーム移行を最小限の停止時間で実行可能です。REDO Applyは、自動ストレージ管理への移行、単一インスタンスの Oracle Database から Oracle Real Application Clusters（Oracle RAC）への移行、データセンターの移設にも使用できます。

3 https://support.oracle.com/rs?type=doc&id=413484.1

https://support.oracle.com/rs?type=doc&id=413484.1


Standby-First Patchによるパッチの保証

Standby-First Patch Apply（Oracle Database 11.2.0.1 以降）により、フィジカル・スタンバイ・データベースで REDO Apply を使用することで、プライマリ・データベースとスタンバイ・データベースの間で異なるソフトウェア・パッチ・レベルをサポートできます。これは、ローリング方式でOracle パッチを適用し、検証できるようにするための機能です。適合するパッチは、以下のとおりです。

» Patch Set Update、Critical Patch Update、Patch Set Exception、 Oracle Database のバンドル・パッチ

» Oracle Exadata Database Machine バンドル・パッチ、 Oracle Exadata Storage Server ソフトウェア・パッチ

詳しくは、My Oracle Support Note 1265700.1 を参照してください 4。

Oracle Active Data Guard

Active Data Guard は、Oracle Database Enterprise Edition のオプションです。これまで説明したData Guard のすべての機能と、以降の項で説明する機能が組み込まれています。

リアルタイム問合せ – パフォーマンスとROI Active Data Guard は、読取り専用のレポート作成アプリケーション、非定型の問合せ、データ抽出などを最新のフィジカル・スタンバイ・データベースにオフロードするとともに、障害に対する保護も提供します。Active Data Guard は、最高レベルのパフォーマンスを実現する高度にパラレル化された適用プロセスを持つと同時に、プライマリ・データベースで使用される読取り一貫性モデルがスタンバイ・データベースでも使用される点で、他に類を見ません。これを実行する物理または論理レプリケーション・ソリューションは他にありません。

グローバル一時表に書き込んだり、一意のシーケンスにアクセスしたりするという要件を除けば、読取り専用データベースを使用するレポート作成アプリケーションも存在します。Active Data Guard により、Oracle Database 12c Release 1 に新機能が追加され、グローバル一時表（GTT）に書き込んだり、アクティブなスタンバイで一意のシーケンスにアクセスしたりできるようになり、Oracle Database 18c ではこの機能が拡張され、Active Data Guard スタンバイ・データベースで GTTを動的に作成できるようになりました。これらの強化機能により、本番データベースからオフロード可能なレポート作成アプリケーションの数が増加しました。

4 https://support.oracle.com/rs?type=doc&id=1265700.1

https://support.oracle.com/rs?type=doc&id=1265700.1


Active Data Guard スタンバイ・データベースに作業をオフロードすることには、次の 2 つの重要な利点があります。

» 障害が発生するまで高価な資産が使用されない状態に終止符を打ち、スタンバイ・システムを生産的に使用することによって、それらの ROI が向上します。

» アクティブ・スタンバイで必要な場合にフェイルオーバーする準備ができていることを継続的にユーザー検証することにより、不明状態になるリスクが解消されます。アクティブ・スタンバイは、すでにいつでも動作しています。

自動ブロック修復機能 – 高可用性ブロックレベルのデータ損失は、通常、断続的なランダム I/O エラーや、ディスクへの書込みによるメモリの破損によって生じます。Oracle Database はブロックを読み取って破損を検出すると、そのブロックを破損としてマークし、アプリケーションにエラーを報告します。そのブロックに対する後続の読取りは、Active Data Guard を使用していないかぎり、そのブロックを手動でリカバリするまで成功しません。

Active Data Guard は、アプリケーションに透過的なブロック・メディア・リカバリを自動実行します。Active Data Guard は、プライマリ・データベース上の物理的破損を、スタンバイから取得された正常なバージョンのブロックを使用して修復します。逆に、スタンバイ・データベース上で検出された破損ブロックは、プライマリ・データベースの正常なバージョンを使用して自動的に修復されます。

また、アクティブ・スタンバイ・データベース上の物理的な破損は、プライマリ・データベースでブロックが変更されていない場合やスタンバイ・データベースで動作するアプリケーションによってブロックが読み取られた場合でも、検出され、自動的に修復されます。これは、プライマリ・データベースとスタンバイ・データベースの両方で Data Guard の書込み損失保護を有効にすることによって実行されます。この方法は、トランザクションが古いデータを使用することによって発生する発見されにくい破損を検出するための標準のベスト・プラクティスです。書込み損失保護には、スタンバイ・データベースで実行される物理的な破損の検証の全体的なレベルを劇的に向上させるという副次的なメリットもあります。データが変更されても変更されなくても、プライマリ・データベースで読み取られたブロックごとに、スタンバイ・データベースで書込み損失検証が実行されます。この方法でスタンバイ・データベースのブロックが読み取られると、物理的なブロック破損に関する追加のチェックが実行され、スタンバイ・データベースでのみ発生し、プライマリ・データベースでは発生しない障害が検出されます。


Far Sync - いかなる距離でもデータ損失ゼロの保護

データ損失ゼロの同期保護がデータベースのパフォーマンスに与える影響により、望ましくない妥協に結びつく場合があります。サイト間が遠く離れている場合は、保護について妥協し、非同期転送を使用して、許容可能なパフォーマンスの代わりにデータの損失を受け入れる必要があります。どうしてもデータ損失をゼロにする必要がある場合は、遠隔サイトによる保護について妥協し、同じ都市圏内にすべてのサイトを配置する必要があります。Oracle Database 12c がリリースされるまでは、長距離間でデータ損失ゼロを実現できる実行可能なオプションは、独自仕様の高価なストレージ・アレイ、専用のネットワーク・デバイス、複数の Data Guard スタンバイ・データベース（ローカルとリモート）、および複雑な管理手順のうち 1 つ以上を特徴とする 3 サイト・アーキテクチャだけでした。

Oracle Database 12c Release 1 の新機能である Active Data Guard Far Sync では、最小限のコストで、複雑さを増大させることなく、プライマリ・データベースから任意の距離にあるスタンバイ・データベースまでデータ損失ゼロの保護の範囲を拡大することにより、妥協をなくしています。

Far Sync は、Active Data Guard の新しいタイプの転送先です。これは、Far Sync インスタンスと呼ばれ、プライマリ・データベースから REDO を同期受信し、その REDO を最大 29 のリモート送信先に非同期転送します。Far Sync インスタンスは、制御ファイルとログ・ファイルのみを管理する軽量のエンティティです。スタンバイ・データベースのわずかな CPU、メモリ、I/O を必要とします。ユーザーのデータファイルを保持することはなく、REDO Apply を実行することもありません。唯一の目的は、リモート送信先に REDO を送信するプライマリ・データベースのオーバーヘッドを透過的にオフロードすることです。Far Sync では、Oracle Advanced Compression を使用する場合に発生する REDO 転送圧縮に関するプライマリ・データベースのオーバーヘッドをオフロードすることにより、ネットワーク帯域幅も節約されます。

例として、ニューヨークにあるプライマリ・データベースとロンドンにあるスタンバイ・データベースの間で非同期転送を実行する既存の Data Guard 構成について考えます。Active Data Guardにアップグレードし、単にニューヨークの同期レプリケーション距離（推定 48～240 km）内にある第 3 の場所に Far Sync インスタンスをデプロイするのみで、データ損失ゼロを実装します（図 3を参照）。プライマリ・データベースと互換性があれば、どのようなサーバーでも使用できます。独自規格のストレージ、専用のネットワーク・デバイス、追加のライセンス、および複雑な管理は不要です。プライマリ・データベースに障害が発生すると、すべての Data Guard 構成で使用されるものと同じフェイルオーバー・コマンドやファスト・スタート・フェイルオーバーによる自動フェイルオーバーによって、ロンドンのデータベースがプライマリ・ロールに迅速に移行し、データ損失は発生しません。


図3：Active Data Guard Far Sync：任意の距離でデータ損失ゼロのフェイルオーバー

Active Data Guardを使用したデータベース・ローリング・アップグレード企業では、ミッション・クリティカルな本番環境に変更を加える際の計画停止時間の短縮とリスクの軽減に対する優先度が高まっています。データベース・ローリング・アップグレードには、次の2 つの利点があります。

» 最小限の停止時間：データベースのアップグレードや、データベースの物理構造を変更する（ユーザー表の実際の構造体の変更を除く）その他のさまざまな計画的メンテナンスは、本番環境をプライマリ・データベースで動作させたまま、スタンバイ・データベースで実施できます。すべての変更が検証されると、スイッチオーバーにより本番アプリケーションがスタンバイ・データベースに移行され、ユーザーが新しいバージョンで操作している間に元のプライマリ・データベースをアップグレードできます。計画停止時間は、全体で、本番データベースをスタンバイ・データベースに切り替えるために必要なわずかな時間に限定されます。

» 最小限のリスク：すべての変更がスタンバイ・データベースで実装され、完全にテストされるため、本番バージョンで操作するユーザーにはリスクがありません。Oracle Real Application Testing を使用して、実際のアプリケーション・ワークロードを本番システムで取得し、スタンバイ・データベースで再生することにより、本番サービス・レベルに影響を与える可能性のない厳密に制御された環境において実際の本番ワークロードが本番データベースの完全なコピー上で実行されるため、最大限に正確なテスト結果を得ることができます。これとは異なり、本番データベースにおいてメンテナンスをオンラインで行う場合でさえ、本番環境から完全に分離された個別のコピー上でメンテナンスを行いたいときは、データベース・ローリング・アップグレードを使用できます。

Oracle Database 12c Release 1 の新機能である Active Data Guard によるデータベース・ローリング・アップグレードは、一時ロジカル・ローリング・アップグレード（付録 B を参照）を実行するために必要な 40 以上の手動の手順を、ほとんどのプロセスを自動化する 3 つの PL/SQL パッケージに置き換えることにより、複雑さに関する懸念を解消します。


Active Data Guard によるデータベース・ローリング・アップグレードは、Oracle Database 12c Release 1 の最初のパッチ・セット以降のバージョン・アップグレードに使用できます。これは、Oracle Database 11g から Oracle Database 12c へのローリング・アップグレードまたは Oracle Database 12c の最初のリリースから Oracle Database 12c Release 1 以降の最初のパッチ・セットへのアップグレードでは依然として、このホワイト・ペーパーの付録 B で説明されている Data Guardによる手動の手順を使用する必要があることを意味します。

この新しい Active Data Guard のローリング・アップグレード機能は、データベース構造を変える他のメンテナンス作業で使用可能です。そのような作業には、以下が含まれます。

» パーティション化されていない表へのパーティションの追加

» BasicFile LOB の SecureFile LOB への変更

» CLOB として格納される XMLType のバイナリ XML として格納される XMLType への変更

» 表の圧縮

アプリケーション・コンティニュイティ高速アプリケーション通知（FAN）は例外条件をアプリケーションに迅速に配信する Oracle Database の機能ですが、アプリケーションの観点からは、最後のトランザクションの結果が報告されず、進行中のリクエストがリカバリされることもありません。その結果、動作の停止が表面化し、ユーザーの不便や収益の減少につながる場合があります。また、ユーザーが誤って二重に購入したり、同じ請求に対して複数回の支払いを行ったりする可能性もあります。これらの欠点、複雑なサポート、および継続的な開発に対処するために、開発者は、カスタム・アプリケーション・コードを作成して保持する以外に選択肢がありませんでした。

アプリケーション・コンティニュイティは、Oracle Database 12c におけるアプリケーションに依存しない新機能で、アプリケーションの観点から完了していないリクエストをリカバリし、システム、通信、ハードウェアの多くの障害およびストレージの停止をエンドユーザーから隠します。また、エンドユーザーのトランザクションが確実に一度だけ実行されるようにします。アプリケーション・コンティニュイティは、Active Data Guard に付属しています。

Oracle Global Data Services

Oracle Global Data Services（Oracle GDS）は Oracle Database 12c の新機能で、よく知られた Oracle RAC スタイルの接続時および実行時ロードバランシング機能、サービス・フェイルオーバー機能、ワークロード管理機能（単一のデータセンター内または複数のデータセンター間）をレプリケート・データベースのセットに拡張します。Oracle GDS は、Active Data Guard に付属しています。


関連テクノロジー

Data Guard と Active Data Guard は、高可用性とデータ保護の数々のテクノロジーで緊密に結ばれた関係にあります。

ストレージのリモート・ミラー化ストレージのリモート・ミラー化（EMC SRDF、Hitachi TrueCopy など）は、ディスク上のデータのコピーのリモート同期コピーの保持に関する一般的なアプローチです。ストレージのリモート・ミラー化は、Oracle Database 外部にあるファイル・システム・データのレプリケーションを実行する際に、Active Data Guard を補完する役割を果たします。ストレージのリモート・ミラー化は Oracle Database のレプリケーションのベスト・プラクティスにはなりません。Active Data Guard スタンバイ・データベースと同じ高いレベルの保護、可用性、機能性、ROI を実現する上で必要なデータベース・ブロックと REDO 構造体の情報がないためです。

ストレージのリモート・ミラー化と Active Data Guard 間のアーキテクチャの違いをざっと見てみれば、その理由が分かります。Oracle Database で I/O（たとえば、データファイル、制御ファイル、フラッシュバック・ログ・ファイル、オンライン・ログ・ファイル、アーカイブ・ログ・ファイルへの書込み）を発生させるデータベース・プロセスは多数あります。各プロセスは本番データベースに関して最大限のパフォーマンスとリカバリ能力を実現するように設計されていますが、I/O の総量によっては、リモート・レプリカのリアルタイム同期を維持するためにすべてのファイルへのすべての書込みをミラー化する必要のあるストレージのリモート・ミラー化ソリューションにとって問題となる場合があります（図 4 を参照）。テストの結果によると、ストレージのリモート・ミラー化では、リアルタイム・データ保護を維持するために Data Guard よりも最大 7 倍のボリュームのデータが送信され、27 倍以上のネットワーク I/O 操作が行われる可能性のあることが示されています。

図4：ストレージのリモート・ミラー化 – リアルタイム保護のため、全ファイルへの全書込みをミラー化

対照的に、Data Guard は、Oracle が認識する軽量のレプリケーション・プロセスを使用して、帯域幅の消費をプライマリ・データベースによって生成される REDO ボリューム（図 4 に示されるリカバリ・ファイルに書き込まれる 1 本の赤色のデータ・ストリームに相当するボリューム）に限定します。他には何も送信されません。Data Guard は、この REDO をメモリから直接送信することで、プライマリ・データベースでのディスク I/O への影響を排除するとともに、ストレージ層で発生する破損からの完全な分離を実現します（図 5 を参照）。


図5：Data Guard – ネットワークの消費が削減されるとともに、破損からの強力な分離が実現される

帯域幅消費の削減は、Active Data Guard の使用による一つのメリットに過ぎません。その他の重要なメリットは、以下のとおりです。

» プライマリ・データベースとスタンバイ・データベースの強力な物理的分離により、管理者のエラー（ストレージ管理作業による重要なデータベースやその他のファイルの誤った削除など）による影響が広がりません。

» 動作中の Oracle Database インスタンスによって変更がスタンバイ・データベースに適用される前に、Oracle が認識する物理および論理ブロックのチェックによる継続的な検証が実行されます。この検証により、破損がプライマリ・データベースからスタンバイ・データベースに広がることが防止され、Active Data Guard を使用するプライマリ・データベースまたはスタンバイ・データベースのいずれのディスクでも独立して発生する物理的なブロックの破損が検出され、自動的に修復されます。

» 読取り専用レポート、非定型の問合せ、Data Pump の本番オフロードが Active Data Guard スタンバイ・データベースにエクスポートされ、最大限の ROI が実現されます。

» リスクが軽減されるとともに高可用性が実現されます。Active Data Guard は、ミラー化されたボリュームによるデータベースのコールド起動が成功するかどうかに関する不確実性を排除します。また、ボリュームがマウントされる間の遅延も排除します。Active Data Guard スタンバイ・データベースは、常に稼働状態で、本番環境として使用する準備が完了しています。このスタンバイ・データベースは、読取り専用のワークロードを使用して、継続的な Oracle Database 検証とエンドユーザー検証を実行します。

» ローリング方式でデータベースのメンテナンスを実行できるため、計画停止時間が短縮されます。

Oracle GoldenGate Active Data Guard と GoldenGate はどちらも、オラクルのソフトウェア・ポートフォリオに含まれる戦略的製品です。これらの製品はどちらもおおまかにはレプリケーション・テクノロジーとして分類されますが、それぞれの重点領域は大きく異なります。

Active Data Guard を使用するケース：Active Data Guard は、レプリケーションをアクティブにしたまま読取り専用でオープンされる本番データベースの正確な物理レプリカを遠隔地に維持することにより、もっとも単純かつもっとも経済的な方法によって Oracle Database の最高レベルのデータ


保護と可用性を実現します。単純さ、最高レベルのデータ保護、データ可用性、最高レベルのパフォーマンスを重視する場合は、Active Data Guard を使用してください。

GoldenGate を使用するケース：GoldenGate は、高度な論理レプリケーション製品であり、双方向のマルチマスター・レプリケーション、ハブ・アンド・スポーク展開、データ変換をサポートすることで、あらゆる種類のレプリケーション要件に対応した非常に柔軟なオプションを提供しています。また、さまざまな異種プラットフォームおよびデータベース管理システム間のレプリケーションをサポートしています。

Active Data Guard とは異なり、GoldenGate はディスクから REDO レコードを読み取り、これらのレコードをプラットフォームに依存しない証跡ファイルの形式に変換してターゲット・データベースに送信することで、プライマリ・データベースの変更を取得します。また、証跡ファイルを SQLに変換し、この SQL をターゲット・データベースに適用することで、論理レプリカを維持します。ターゲット・データベースは、同期化中も読取り/書込みモードでオープンされます。

レプリカ・データベースを、レプリケーションをアクティブにしたまま読取り/書込みモードでオープンにする必要がある場合、または、Active Data Guard では対処できない高度なレプリケーション要件がある場合は、GoldenGate を使用してください。

Active Data Guard と GoldenGate を一緒に使用するケース：Active Data Guard と GoldenGate の両方のテクノロジーを使用する次の高可用性アーキテクチャの例でも明らかなように、これらのテクノロジーが相互に排他的ではないことを強調することは重要です。

» Active Data Guard スタンバイ・データベースは、ミッション・クリティカルな OLTP データベースの障害に対する保護とローリング・アップグレードのために使用されます。GoldenGate は、エンタープライズ・データウェアハウスの ETL 更新のために Data Guard プライマリ・データベースから（または GoldenGate ALO モードを使用するスタンバイ・データベースから）データを抽出するために使用されます。

» Active Data Guard がディザスタ・リカバリに使用されますが、Data Guard が直接支援できない計画的メンテナンスのアクティビティ（クロスエンディアン・プラットフォーム移行、バックエンド・データベース・オブジェクトを変更するアプリケーション・アップグレードなど）に対処するために GoldenGate の柔軟性が使用されます。GoldenGate は移行やアップグレードを実行するために使用され、それが完了すると、新しい本番環境の障害に対する保護を実現するために新しい Data Guard スタンバイ・データベースがデプロイされます。

これらのテクノロジーのいずれかまたは両方の使用が最適な要件について詳しくは、『Oracle Active Data Guard and Oracle GoldenGate』を参照してください 5。

5 http://www.oracle.com/technetwork/database/features/availability/dataguardgoldengate-096557.html

http://www.oracle.com/technetwork/database/features/availability/dataguardgoldengate-096557.html


Zero Data Loss Recovery Appliance

Zero Data Loss Recovery Appliance は、Oracle RMAN および Oracle Database と完全に統合された革新的なデータ保護ソリューションです。社内にある複数の Oracle データベースのバックアップとリカバリ・プロセスを刷新し、標準化も行う大きな技術革新を備えた統合ハードウェアおよびソフトウェア・アプライアンスです。このリカバリ・アプライアンスにより、永続的な増分バックアップ戦略とあらゆる時点のポイント・イン・タイム・リカバリが実現します。複数のレベルのバックアップ検証を実行することで、リカバリを正常に完了させます。その際、ソース・データベースにオーバーヘッドは生じません。Enterprise Manager を使ってエンド・ツー・エンドの管理コントロールを実行することで、管理者が目的のリカバリ時間を確実に達成できるようにします。

このリカバリ・アプライアンスは、REDO が生成されると、Data Guard 転送サービスを利用してすぐに転送することでデータ損失を排除し、本番データベースでアーカイブ・ログのバックアップを取得する必要性をなくします。Data Guard 転送のリアルタイムの性質により、リカバリ・アプライアンスは最新のトランザクションでもデータベース・バックアップからリストアできます。これは、スタンバイ・データベースなしで、Data Guard リカバリ・ポイント目標を達成することに相当します。

リカバリ・アプライアンスは、データベースのバックアップのリストアにより、可用性をリストアします。それとは対照に、Data Guard と Active Data Guard は、すでに実行中の同期されたスタンバイ・データベースへの高速フェイルオーバーを実現し、追加のリアルタイムの検証、本番オフロード、このペーパーで説明されているその他の高度な機能を提供します。

Oracle Real Application Clusters（Oracle RAC） Active Data Guard と Oracle RAC または Oracle RAC One Node は補完的なテクノロジーです。Oracle RAC は、サーバー障害からの保護に最適な HA ソリューションを提供するとともに、クラスタ環境でのワークロード管理とスケーラビリティのために独自の機能も提供します。Data Guard スタンバイを使用して、強力な分離とエンド・ツー・エンドの冗長性を実現することによって、Oracle RACプライマリ・データベースを保護します。これにより、クラスタ全体が使用できなくなる問題（データベース障害やサイト障害を引き起こすデータの破損、オペレーターのミス、複数の相関障害など）が発生した場合でも、データが保護され、高度な HA が実現されます。Data Guard により、オンラインで行うことができない、または複数の Oracle RAC にわたるローリング方式の計画的メンテナンスでの停止時間が短縮されます。

Oracle Multitenant

Oracle Multitenant は、データベース統合のためのまったく新しいアーキテクチャを提供する、Oracle Database 12c Release 1 の新しいオプションです。マルチテナント・アーキテクチャにより、複数の Oracle Database が統合された（それぞれプラガブル・データベース（PDB）と呼ばれる）、単一の Oracle Database ソフトウェア群（マルチテナントのコンテナ・データベース（CDB））の下で動作します。アーキテクチャ上の区別は、各 PDB（ユーザー・データおよびメタデータ）とその CDB（Oracle メタデータ）の間で行われます。PDB は、CDB に含まれない従来の Oracle Databaseと互換性を持ちます。

Data Guard と Active Data Guard は、コンテナ・レベルで保護を提供することにより、マルチテナント・アーキテクチャにおいて透過的に機能します。たとえば、50 の PDB を含む CDB は、単一の


Data Guard スタンバイ・データベースを持ち、単一の Data Guard 構成として管理されます。Enterprise Manager Cloud Control での 1 つのコマンドの実行またはマウスの 1 回のクリックにより、すべての PDB がディザスタ・リカバリ・サイトに一度にフェイルオーバーまたはスイッチオーバーされます。

CDB は、ストレージ・コンシステンシ・グループに似たポイント・イン・タイム機能も提供します。上記の例において、50 の PDB はすべて、Data Guard フェイルオーバーの実行後に、自動的に、全体的に一貫した時点を持ちます。これは、複数のデータベースにまたがる時点依存関係がある場合には重要な特性です。そのようなデータベースは、ストレージのリモート・ミラー化を使用する場合は事前に同じコンシステンシ・グループに入れることができ、Data Guard を使用する場合は一貫性のあるポイント・イン・タイム・リカバリのために複数回のフラッシュバック操作が必要になります。

Oracle Engineered SystemsとOracle Data Guard Data Guard は、Oracle Engineered Systems で動作する Oracle Database に使用できるディザスタ・リカバリ・ソリューションです。Data Guard フィジカル・スタンバイ・データベースは、Oracle Exadata Database Machine によって動作する非常に大きな容量のデータをサポートできる唯一のレプリケーション・テクノロジーです 6。Data Guard REDO Apply は、Exadata 上のすべてのワークロード（大規模データウェアハウス、Web スケール OLTP アプリケーション、データベース統合など）をサポートする実際の環境で、その能力を証明しています。Exadata 上で Active Data Guard を使用する各種のワークロードの注目すべき例には、以下のものがあります。

» 大きな負荷の ETL 処理の実行中でも 800 MB/秒以上の速度を維持して Data Guard が Exadata スタンバイ・データベース（11.2.0.3）に変更を適用した本番データウェアハウス。

» Oracle Open World で行われたプレゼンテーションにおいて PayPal によって紹介された、Webスケールでデプロイされ、Active Data Guard によって保護された、世界でももっとも要求の厳しい OLTP アプリケーションの 1 つ 7。

» コストを削減するとともにサービス・レベルを向上させる Active Data Guard を使用して、Garmin International によって Exadata 上にデプロイされた統合データベース環境 8。

6 http://www.oracle.com/technetwork/jp/database/features/availability/maa-wp-dr-dbm-130065-ja.pdf 7 http://www.oracle.com/technetwork/database/availability/11256-exadata-oltp-paypal-1864630.pdf 8 http://www.oracle.com/technetwork/database/availability/garmin-1667151.pdf

http://www.oracle.com/technetwork/jp/database/features/availability/maa-wp-dr-dbm-130065-ja.pdf

http://www.oracle.com/technetwork/database/availability/11256-exadata-oltp-paypal-1864630.pdf

http://www.oracle.com/technetwork/database/availability/garmin-1667151.pdf


顧客事例

Data Guard の機能は、Oracle Version 7 で始めて利用可能になり、後続の Oracle リリースで継続して拡張され、さらに充実したものになっています。このことから、Data Guard および Active Data Guard は、世界中の顧客のミッション・クリティカルなアプリケーションに使用されています。多くの詳細な実装の事例は、Oracle Technology Network で入手できます 9。

結論

Active Data Guard は、本番データベースの正確な物理レプリカを遠隔地に維持することにより、もっとも単純でもっとも経済的な方法によって Oracle データの最高レベルのデータ保護と可用性を実現します。他のテクノロジー（ストレージのリモート・ミラー化、論理レプリケーションなど）でも本番データベースの同期コピーを保持できますが、Oracle データを保護するために使用する場合はどれも、コスト、複雑さ、破損の検出、自動修復、可用性、投資収益率といった領域のいずれか、または複数の領域において大きな妥協が必要になります。Active Data Guard は、Oracle Database との緊密な統合と、Oracle データに関するリアルタイム・データ保護および可用性の実現への十分な特化により、妥協を排除します。

9 http://www.oracle.com/technetwork/database/features/availability/ha-casestudies-098033.html

http://www.oracle.com/technetwork/database/features/availability/ha-casestudies-098033.html


付録A：Data GuardとActive Data Guardの機能の概要

領域 Oracle Database 12c Release 1で利用可能な新機能

Active Data Guard Active Data Guardスタンバイ・データベースでは、グローバル一時表に関するDML操作がサポートさ

れます。プライマリ・データベースで作成される一意のグローバルまたはセッション・シーケンスに

も、Active Data Guardスタンバイ・データベース上で動作するレポーティング・アプリケーションか

らアクセスできます。

リアルタイム・カスケードにより、REDOを受信するスタンバイ・データベースは、REDOがスタンバ

イREDOログ・ファイルにアーカイブされるのを待たずに、受信直後にREDOを別のスタンバイ・デー

タベース（カスケード接続された送信先）に非同期転送できます。

Active Data Guard Far Syncは、制御ファイルとログ・ファイルだけを持つ軽量のインスタンスで構成

される新しいタイプのリモート転送先です。プライマリ・データベースからREDOを同期受信し、その

REDOを最大29の他のリモート送信先に非同期転送します。すべてのData Guard構成で使用されるも

のと同じフェイルオーバー・コマンドにより、Far Syncによって提供される任意のスタンバイ・データ

ベースへのデータ損失ゼロのフェイルオーバーが透過的に実行されます。 Active Data Guardによるデータベース・ローリング・アップグレードでは、40以上の手動の手順が3つのPL/SQLパッケージに置き換えられ、一時ロジカル・データベース・ローリング・アップグレード・

プロセスが大幅に簡素化されます（フィジカル・スタンバイ・データベースでSQL Applyを一時的に使

用することにより、ローリング・アップグレード時に複数のデータベース・バージョンにわたる同期が

実行されます）。アプリケーション・コンティニュイティは、アプリケーションの観点から完了していないリクエストの

リカバリを試みて、多数のシステム、通信、およびハードウェアの障害やストレージの停止が表面化し

てエンドユーザーに影響を与えることを防ぐ、アプリケーションに依存しない機能です。これにより、

エンドユーザーのトランザクションが複数回実行されることもなくなります。Active Data Guardには、アプリケーション・コンティニュイティのライセンスが含まれています。

Global Data Servicesは、よく知られたOracle RACスタイルの接続時および実行時ロードバランシング

機能、サービス・フェイルオーバー機能、ワークロード管理機能（データセンター内または複数のデー

タセンター間）をレプリケート・データベースのセットに拡張します。

Data Guard Zero Data Loss Recovery Appliance（ZDLRA）を非同期Data Guard REDO転送先として構成すること

で、最新のトランザクションでもバックアップからリストアできます。

Fast Syncでは、最大可用性保護モードを、同期転送およびNOAFFIRM属性とともに使用できます。こ

れにより、ラウンドトリップの合計時間からスタンバイREDOログのI/Oの時間が除外され、データ損

失ゼロの同期構成に関してプライマリ・データベースのパフォーマンスが改善されます。

Oracle RACプライマリ・データベースからフィジカル・スタンバイ・データベースへのスイッチオー

バーで、管理者は、1つのプライマリ・データベース・インスタンス以外はシャットダウンする必要が

なくなります。データベースがアクティブにファイルにアクセスしているときに、オンライン・データファイルの位置

を物理ファイル間で移動できます。プライマリ・データベース上での移動はスタンバイ・データベース

に影響を与えません（その逆も同様）。リカバリをアクティブにしたままスタンバイ・データベース上

でオンライン・データファイルを移動するには、Active Data Guardが必要です。 Data GuardとActive Data Guardは、Oracle Multitenantをサポートします。Data Guardは、マルチテナ

ントのコンテナ・データベース・レベルで動作し、統合環境における効率的なディザスタ・リカバリを

実現します。 SQL Applyは、追加のデータ型をサポートします。これらのデータ型は、すべてのストレージ・モデル

のXMLTypeデータ（互換性要件が満たされる場合）、Oracle Spatial、Oracle Multimedia、Oracle Text、オブジェクトとコレクション（VARRAY、ネストされたコレクションを含む）、Database File System（DBFS）、XDB、Oracle SecureFiles（重複排除）です。また、以前にデータベース・ローリ

ング・アップグレードにData Guardを使用する場合に存在した障害を排除するために、ユーザー定義

のデータ型が追加されました。SQL Applyは、データベース・ローリング・アップグレードのコンテキ

ストに固有の制御された方法において、データベース・ロール固有のジョブや、スケジューラ・ジョブ

のレプリケーションでDBMS_SCHEDULERをサポートします。拡張データ型サポート（EDS）によ

り、ネイティブのREDOベースのサポートをもたない特定のデータ型をSQL Applyがサポートするため

のメカニズムも提供されます。たとえば、トップレベルのVARRAY列を持つ表を、EDSを使用してレ

プリケートできます。

Data Guardに、特権を基本管理タスクに制限する固有の管理権限であるSYSDGが追加されました。



Data Guard Broker Data Guard Brokerは、比較的単純な構成や、データベース・ロールに応じて異なる転送方法（SYNCまたはASYNC）が使用される、より複雑な複数のスタンバイData Guard構成の管理のための新しい

Data Guard BrokerパラメータであるRedoRoutesをサポートしました。

新しいData Guard Brokerのデータベース検証コマンドにより、ロールの変更の前に、一連の包括的な

データベース・チェックが実行されます。このチェックでは、Data Guardのさまざまなビューと自動

診断リポジトリで提供される情報が使用されます。

Data Guard Brokerは、REDO ApplyのラグおよびREDO転送のラグに関するユーザーが構成可能なし

きい値を有効にします。これにより、データ損失が、設定したリカバリ・ポイント目標を超えると、

自動的に信号が送信されます。

再開可能なスイッチオーバーにより、管理者は、コマンドを最初に実行したときに完了を妨げる問題

が発生したスイッチオーバー操作を完了できます。管理者は、問題を解決してスイッチオーバーを再

開するか、プライマリ・データベース/スタンバイ・データベースを元の状態に戻すことができます。

Data Guard Broker構成を終了したり、再作成したりする必要はありません。

Data Guard BrokerがサポートするData Guard構成は、Oracle Multitenant、カスケードされたスタンバ

イ・データベース、Active Data Guard Far Sync、Active Data Guardによるデータベース・ローリン

グ・アップグレード、およびGlobal Data Servicesです。

Oracle Recovery Manager（Oracle RMAN）

スタンバイ・データベースまたはネットワークの停止後のアーカイブ・ログ・ファイルによるプライ

マリ・データベースとスタンバイ・データベースの自動再同期化は、Data Guard転送によって常に支

援してきました。必要なアーカイブ・ログ・ファイルがディスク上になくなるような長時間の停止の

場合は、Oracle RMAN高速増分バックアップを使用して手動で再同期化できます。Oracle Database 12cでは、新しい単一のOracle RMANコマンド（RECOVER DATABASE .. FROM SERVICE）の使用

により、手動の再同期化プロセスがさらに簡単になっています。



Active Data Guard フィジカル・スタンバイ・データベースでのマルチインスタンスREDO Apply。スタンバイがReal Application Clusterである場合は、スタンバイ・データベースが高負荷の本番データベースに追随可能

な速度を上げるため、クラスタ内のすべてのノードがREDOを適用するために使用されます。

Oracle Database In-Memoryの機能は、Active Data Guardスタンバイ・データベースがOracle Engineered Systems上に存在するか、Oracleのクラウドで実行されている場合には、それらのスタン

バイ・データベースで使用可能です。

問合せおよびREDO Applyパフォーマンスのチューニングは、オラクルの自動ワークロード・リポジト

リ（AWR）とSQLチューニング・アドバイザを使用して、完全にスタンバイ・データベースで実行で

きるようになりました。

ユーザーは、ドレイン・サービス機能を使用してData Guardのロール移行中に移動することができ、

読取りモードでスタンバイに接続しているユーザーは、切断されることがなくなり、ロール変更操作の

全体でその状態を保持することができます。

自動ブロック修復機能により、プライマリまたはスタンバイのデータベースで、ほとんどすべての潜在

的なブロック破損を検出して修復できるようになりました。

DBMS_ROLLINGアップグレードでのData Guard Brokerによる全体的なサポート。

Oracle RMANとEnterprise Managerを使用して、Far Syncインスタンスを作成できます。

Data Guard Oracle Database Creation Assistant（Oracle DBCA）とOracle Enterprise Manager Command Line Interface（Oracle EMCLI）を使用して、スタンバイ・データベースを作成できるようになりました。

Oracle MultitenantデータベースでData Guard BrokerのMIGRATEコマンドを使用した、スタンバイ・

コンテナ・データベースから別のプライマリ・コンテナへの個々のPDBのフェイルオーバー

プライマリ・データベースで完了したパスワード・ファイルの変更内容は、スタンバイ・データベース

に自動的に伝播されるようになりました。この場合の唯一の例外は、Far Syncインスタンスです。Far SyncインスタンスではREDOを受信しても適用しないため、更新したパスワード・ファイルは、引き

続き手動でFar Syncインスタンスにコピーする必要があります。

プライマリで実行される非ロギング操作は、RMAN RECOVER NONLOGGGED BLOCKコマンドを使

用してスタンバイで容易に修復できます。

本番データベースのストレージで障害が発生した場合には、最大パフォーマンス・スタンバイ・データ

ベースへのデータ損失ゼロ・フェイルオーバーを実行できるようになりました。

複数の同期スタンバイ送信先は、最速のスタンバイ・データベース接続から確認応答を受信するために

必要とされる時間中は本番データベースのパフォーマンスにのみ影響するように設定できます。

Multitenantスタンバイ・データベースは、PDBレベルの本番データベースのサブセットにすることがで

きます。最初にスタンバイ・データベースを暗号化し、スイッチオーバーを使用してユーザーを暗号化された

データベースに移動することにより、本番データベースでほとんど停止時間が発生しないようにして、

プライマリとスタンバイのデータベースをTDEに変換します。


Data Guard Broker Data Guard Brokerには、ユーザーが本番データベースと一部またはすべてのスタンバイ・データベー

スの間でブロックを比較できるようにするブロック比較ツールが組み込まれました。

Fast_Start Failoverでは、複数のフェイルオーバー・ターゲットと最大3つのオブザーバーをサポートで

きるようになりました。Fast_Start Failoverでは、最大保護モードもサポートされます。

Data Guard Brokerは、REDO ApplyのラグおよびREDO転送のラグに関するユーザーが構成可能なしき

い値を有効にします。これにより、データ損失が、設定したリカバリ・ポイント目標を超えると、自動

的に信号が送信されます。新しいData Guard Brokerプロパティ、RedoRoutesではより複雑なREDO転送構成が許容され、Data Guardの改善された代替送信先機能を使用してFar Syncインスタンスとリアルタイム・カスケードがサ

ポートされます。

Data Guard BrokerのDGMGRLコマンドライン・インタフェースによるスクリプト作成


領域 Oracle Database 18cで利用可能な新機能

Active Data Guard スタンバイ側のユーザーは、ロール変更（フェイルオーバーのスイッチオーバー）の後に離れた正確な

場所から、ロール変更操作においてバッファ・キャッシュで現在保持されているのと同じパフォーマン

スで続行できるようになります。グローバル一時表とシーケンスは、使用できるようにするにはプライマリ・データベースであらかじめ

作成されていなければならないという要件を排除することにより、スタンバイに接続されている間に動

的に作成可能です。

ログイン・セキュリティが強化され、ログイン失敗回数を超過したユーザー・アカウントは、Data Guard環境全体でロックされるようにすることができます。

ユーザーは、ドレイン・サービス機能を使用してData Guardのロール移行中に移動することができ、

読取りモードでスタンバイに接続しているユーザーは、切断されることがなくなり、ロール変更操作の

全体でその状態を保持することができます。

Data Guard スタンバイの準備ができていない場合でも、シャドウ表領域を使用して、プライマリ・データベースで

書込み損失を検出できるようになりました。


付録B：一時ロジカル・データベース・ローリング・アップグレード

データベース・ローリング・アップグレードでは、Data Guard SQL Apply を使用する必要があります。Oracle Database 11g では、物理スタンバイ・ユーザーがデータベース・ローリング・アップグレードを行うことを可能にする Data Guard 一時ロジカル・ローリング・アップグレード・プロセス（一連の複雑な手動の手順によって実行される）が導入されました。複雑さは常にリスクを増大させるため、当然のことながら、多くのフィジカル・スタンバイ・ユーザーが、比較的単純な従来のアップグレードを使用しました。しかし、従来のアップグレードは、長い停止時間と前述のような別のリスク要素という企業にとって望ましくない 2 つの事柄を生み出します。詳しくは、付録 B を参照してください。

12.1.0.2 より前の Oracle Database Release からアップグレードする場合は、Data Guard のフィジカル・スタンバイ・データベースで一時ロジカル・データベース・ローリング・アップグレード・プロセスを使用して、完全な Oracle Database パッチ・セットのインストール（たとえば、Oracle 11.2.0.1 から 11.2.0.3 へ）、または主要リリースのインストール（たとえば、Oracle 11.2 から 12.1へ）やデータベースのアップグレードを最小限の停止時間で実行できます。同じプロセスは、本番データベースのオフライン・コピーを使用して、データベースの論理構造を変更し、検証して、本番環境を変更されたバージョンに切り替える、さまざまな種類の計画的メンテナンスを実行する場合にも役立ちます。

一時ロジカル・プロセスは、プライマリ・データベースとフィジカル・スタンバイ・データベースによって開始されます。Standby-First Patch を使用するときと同様に最初にスタンバイ・データベースがアップグレードされますが、この場合、Data Guard の論理レプリケーション（SQL Apply）は、古いバージョンで動作するプライマリ・データベースから新しいバージョンで動作するスタンバイ・データベースへのレプリケートのために一時的に使用されます。REDO Apply とは異なり、論理レプリケーションは、バージョン間の同期のために SQL を使用し、異なる Oracle リリース間に存在する可能性のある物理 REDO 構造の違いの影響を受けません。

アップグレードの完了後、スイッチオーバー（唯一の停止時間）により、本番データベースが、スタンバイ・データベースで動作する新しいバージョンに移行されます。その後、元のプライマリ・データベースは、アップグレード・プロセスが開始されたときの状態にフラッシュバックされ、新しいプライマリ・データベースのフィジカル・スタンバイ・データベースに変換されます。フィジカル・スタンバイ・データベースは、新しい Oracle ホームにマウントされて、アップグレードされ、新しいプライマリ・データベースから受信した REDO を使用して再同期されます（2 回目のカタログ・アップグレードは不要）。

Oracle Corporation, World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065, USA

海外からのお問い合わせ窓口

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

C O N N E C T W I T H U S

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

Copyright © 2018, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく

変更されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による明示的保証や法律による黙示的保証

を含め、商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません。オラクルは本

文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル

の書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信する

ことはできません。

Oracle および Java は Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

Intel および Intel Xeon は Intel Corporation の商標または登録商標です。すべての SPARC 商標はライセンスに基づいて使用される SPARC International,

Inc.の商標または登録商標です。AMD、Opteron、AMD ロゴおよび AMD Opteron ロゴは、Advanced Micro Devices の商標または登録商標です。UNIX

は、The Open Group の登録商標です。1217

Oracle Active Data Guard

リアルタイム・データ保護と可用性 2018 年 5 月

Documents

Oracle Active Data Guard リアルタイム・データ保護と可用性 · このホワイト・ペーパーでは、Active Data Guard（オプション・ライセンス）と