| Oracle® Data Guard概要および管理 12c リリース1 (12.1) B71304-07 |
|
 前 |
 次 |
スタンバイ・データベースは、Oracle本番データベースのトランザクション一貫性のあるコピーで、最初はプライマリ・データベースのバックアップ・コピーから作成されます。スタンバイ・データベースが作成および構成されると、Oracle Data Guardは、プライマリ・データベースのREDOデータをスタンバイ・システムに転送し、スタンバイ・データベースに適用することによって、スタンバイ・データベースを自動的にメンテナンスします。
スタンバイ・データベースのタイプには、フィジカル・スタンバイ・データベース、ロジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースがあります。フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースは、必要に応じてプライマリ・データベースのロールを担い、本番処理を引き継ぐことができます。Oracle Data Guard構成にはこのようなスタンバイ・データベースの種類の組合せ(フィジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースおよびロジカル・スタンバイ・データベース)を含めることができます。
フィジカル・スタンバイ・データベースはプライマリ・データベースを正確に、ブロックごとにコピーしたものです。フィジカル・スタンバイはREDO Applyと呼ばれるプロセスによって正確なコピーとして維持されます。このプロセスではデータベース・リカバリ・メカニズムを使用して、プライマリ・データベースから受信したREDOデータを継続的にフィジカル・スタンバイ・データベースに適用します。
フィジカル・スタンバイ・データベースは、読取り専用アクセス用にオープンし、問合せをプライマリ・データベースからオフロードするために使用できます。 Oracle Active Data Guardオプションのライセンスを購入している場合は、フィジカル・スタンバイ・データベースを開いている間はRedo Applyをアクティブにすることができます。それにより、問合せによって、プライマリ・データベースからのものと同じ結果が得られます。この機能は、リアルタイム問合せ機能と呼ばれます。
関連項目:
Oracle Active Data Guardの詳細は、『Oracle Databaseライセンス情報』を参照してください。
フィジカル・スタンバイ・データベースのメリット
フィジカル・スタンバイ・データベースには次のメリットがあります。
障害時リカバリと高可用性
フィジカル・スタンバイ・データベースは、堅牢で効率的な障害時リカバリおよび高可用性のソリューションです。管理が容易なスイッチオーバー機能とフェイルオーバー機能を使用すると、プライマリ・データベースとフィジカル・スタンバイ・データベース間でロールを可逆的に推移できるため、計画的および計画外の停止によるプライマリ・データベースの停止時間が最小限になります。
データ保護
フィジカル・スタンバイ・データベースは、予期しなかった障害時でもデータ損失を防止することができます。フィジカル・スタンバイ・データベースでは、すべてのデータ型、およびプライマリ・データベースがサポートしているすべてのDDLおよびDMLの操作がサポートされます。また、データの破損およびユーザー・エラーからも保護します。プライマリ・データベースに対するストレージ・レベルの物理的な破損は、スタンバイ・データベースに伝播しません。同様に、データ損失の原因となる論理的な破損ユーザー・エラーも簡単に解決できます。
プライマリ・データベースのワークロードの低減
Oracle Recovery Manager(RMAN)は、フィジカル・スタンバイ・データベースを使用してプライマリ・データベースからバックアップをオフロードし、貴重なCPUとI/Oのサイクルを節約できます。
フィジカル・スタンバイ・データベースは、REDO Applyがアクティブであれば問い合せることもできるため、プライマリ・データベースからフィジカル・スタンバイ・データベースに問合せをオフロードでき、プライマリ・データベースのワークロードはさらに低減します。
パフォーマンス
フィジカル・スタンバイ・データベースで使用されるREDO Applyテクノロジは、プライマリ・データベースで行われた変更でスタンバイ・データベースを常に更新することに関しては最も効率的なメカニズムです。これは、SQLレベルのコード・レイヤーをすべてバイパスする、低レベルのリカバリ・メカニズムを使用して変更を適用するためです。
ロジカル・スタンバイ・データベースは、最初はプライマリ・データベースと同じ内容のコピーで作成されますが、後で異なる構造に変更できます。ロジカル・スタンバイ・データベースは、SQL文を実行して更新されます。ロジカル・スタンバイ・データベースの柔軟性の高さにより、ローリング方式でほとんど停止時間なく、Oracle Databaseソフトウェア(パッチ・セットおよび新しいOracle Databaseリリース)をアップグレードし、その他のデータベースのメンテナンスを実行することができます。Oracle Database 11g以降から、一時ロジカル・データベースのローリング・アップグレード・プロセスを、既存のフィジカル・スタンバイ・データベースとともに使用することもできます。
Oracle Data Guardは、ログ・ファイルのデータをSQL文に変換し、ロジカル・スタンバイ・データベースでそのSQL文を実行することによって、アーカイブREDOログ・ファイルまたはスタンバイREDOログ・ファイルの情報をロジカル・スタンバイ・データベースに自動的に適用します。ロジカル・スタンバイ・データベースはSQL文を使用して更新されるため、オープン状態のままであることが必要です。ロジカル・スタンバイ・データベースは読取り/書込みモードでオープンされますが、再生成されたSQLに対するターゲット表は、読取り専用操作用にのみ使用可能です。更新中、これらの表は、レポート生成、要約、問合せなどの他のタスクで同時に使用できます。
ロジカル・スタンバイ・データベースには、データ型、表のタイプ、DDL操作およびDML操作のタイプに関していくつかの制限があります。ロジカル・スタンバイ・データベースのデータ型およびDDLのサポートの詳細は、「ロジカル・スタンバイ・データベースでサポートされるデータ型およびDDL」を参照してください。
ロジカル・スタンバイ・データベースの利点
ロジカル・スタンバイ・データベースは、データ・リカバリ(DR)のメリットとともに高可用性(HA)を提供するには理想的です。フィジカル・スタンバイ・データベースと比較して、ロジカル・スタンバイ・データベースは、さらに次の重要なHAのメリットを提供します。
ソフトウェア・アップグレード時の停止時間の最短化
ロジカル・スタンバイ・データベースはOracle Data Guard構成をローリング方式でアップグレードするのに最適です。ロジカル・スタンバイを使用すると、パッチ・セットやソフトウェアの新しいリリースの適用に関連する停止時間を大幅に短縮できます。ロジカル・スタンバイは、新しいリリースへのアップブレード後に切り替えて、アクティブなプライマリにすることができます。これにより、古いプライマリをロジカル・スタンバイに変換してパッチ・セットを適用する間、完全な可用性を可能にします。ロジカル・スタンバイはDBMS_ROLLING PL/SQLパッケージの基本となるプラットフォームを提供し、Oracle Database 12cリリース1 (12.1)で使用可能です。DBMS_ROLLINGパッケージは、ローリング・アップグレードやその他の記憶域の再編成の状況で、Oracle Data Guard構成の可用性を高めることのできる機能を提供します。
レポート生成要件および意思決定支援要件のためのサポート
ロジカル・スタンバイの主な利点は、レポート作成のワークロードを最適化する重要な補助構造(プライマリのトランザクション・レスポンス時間に対する抑制効果をもたらす構造)を作成できることです。ロジカル・スタンバイは、そのデータをパーティショニングの異なる各種ストレージに物理的に再構成し、多数の異なる索引を付けて、オンデマンド・リフレッシュ・マテリアライズド・ビューを作成および維持することができます。また、データ・キューブおよびその他のOLAPデータ・ビューの作成促進に使用することができます。しかし、ロジカル・スタンバイ・データベースではデータの変換はできません(列のサブセットのみのレプリケーション、ユーザー表の追加列の許可など)。これらのタイプのレポート・アクティビティには、Oracle GoldenGateが望ましいソリューションです。
スナップショット・スタンバイ・データベースは、プライマリ・データベースに完全なデータ保護を提供するタイプの更新可能なスタンバイ・データベースです。スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信およびアーカイブしますが、適用はしません。プライマリ・データベースから受信したREDOデータは、スナップショット・スタンバイ・データベースへのローカル更新がすべて破棄された後、スナップショット・スタンバイ・データベースが変換されてフィジカル・スタンバイ・データベースに戻ると適用されます。
プライマリ・データベースのREDOデータは受信と同時には適用されないので、スナップショット・スタンバイ・データベースは、時間の経過とともにプライマリ・データベースとの差異が生じます。スナップショット・スタンバイ・データベースのローカルな更新によって差異が増えます。ただし、スナップショット・スタンバイはいつでもフィジカル・スタンバイ・データベースに戻すことができ、その後プライマリから受信したREDOデータを適用できるため、プライマリ・データベース内のデータは完全に保護されています。
スナップショット・スタンバイ・データベースのメリット
スナップショット・スタンバイ・データベースは、全面的に更新可能なスタンバイ・データベースで、フィジカル・スタンバイ・データベースと同様の、障害時リカバリおよびデータ保護のメリットがあります。スナップショット・スタンバイ・データベースは、プライマリ・データベースの障害からリカバリする時間が増えても、プライマリ・データベースの一時的かつ更新可能なスナップショットを保持するメリットがある場合に最もよく使用されます。
スナップショット・スタンバイ・データベースの使用には、次のメリットがあります。
常にデータ保護を維持しながら、開発およびテスト用に本番データベースの正確なレプリカを提供します。Oracle Real Application Testingのオプションを使用してプライマリ・データベース・ワークロードを取得して、スナップショット・スタンバイでのテストの目的でそれに応答できます。
フィジカル・スタンバイに変換して再同期化することで、現行の本番データが格納されるように簡単にリフレッシュできます。
スナップショット・スタンバイの作成、テスト、本番環境との再同期化に続いて、再びスナップショット・スタンバイの作成およびテストを実行できることは、必要に応じて何度も繰り返すことができる1サイクルです。同じプロセスを使用して、データへの読取り/書込みアクセスが必要なレポート生成用にスナップショット・スタンバイを簡単に作成し、定期的に更新できます。
関連項目:
Oracle Real Application Testingおよびその使用に必要なライセンスの詳細は、Oracle Database Testingガイドを参照してください
Oracle Data Guard構成の構成、実装および管理には、次のインタフェースを使用できます。
Oracle Enterprise Manager Cloud Control
Oracle Enterprise Manager Cloud Controlでは、Oracle Data Guard環境の作成、構成および監視に関係するタスクの多くを自動化する、Oracle Data Guard BrokerのGUIインタフェースが用意されています。GUIとそのウィザードの詳細は、Oracle Enterprise Manager Cloud Controlのオンライン・ヘルプを参照してください。
SQL*Plusコマンドライン・インタフェース
いくつかのSQL*Plus文では、STANDBYキーワードを使用して、スタンバイ・データベースに対する操作を指定します。他のSQL文にはスタンバイ固有の構文はありませんが、スタンバイ・データベースで操作を実行するときに役立ちます。関連する文のリストについては、「Oracle Data Guardに関連するSQL文」を参照してください。
初期化パラメータ
Oracle Data Guard環境の定義には、いくつかの初期化パラメータが使用されます。関連する初期化パラメータのリストは、「初期化パラメータ」を参照してください。
Oracle Data Guardブローカ・コマンドライン・インタフェース(DGMGRL)
DGMGRLコマンドライン・インタフェースは、Oracle Enterprise Manager Cloud Controlの代替手段です。DGMGRLコマンドライン・インタフェースは、ブローカを使用してバッチ・プログラムまたはスクリプトからOracle Data Guard構成を管理する場合に役立ちます。完全な情報は、『Oracle Data Guard Broker』を参照してください。
Oracle Database 11g以降、Oracle Data GuardではData Guard構成の柔軟性が高まり、プライマリ・システムとスタンバイ・システムで、異なるCPUアーキテクチャ、オペレーティング・システム(たとえばWindowsとLinux)、オペレーティング・システムのバイナリ(32-bit/64-bit)、またはOracleデータベースのバイナリ(32-bit/64-bit)を使用できるようになりました。
プラットフォームの混在について向上した柔軟性は、http://support.oracle.comにあるMy Oracle SupportのNote 413484.1および1085687.1で記述されている現行の制限事項の対象となります。
Note 413484.1では、フィジカル・スタンバイに対するプラットフォーム混在のサポートおよび制限事項について説明しています。
Note 1085687.1では、ロジカル・スタンバイに対するプラットフォーム混在のサポートおよび制限事項について説明しています。
同じリリースのOracle Database Enterprise Editionをプライマリ・データベースおよびすべてのスタンバイ・データベースにインストールする必要があります。ただし、ロジカル・スタンバイ・データベースまたは一時ロジカル・スタンバイ・データベースを使用したローリング・データベース・アップグレード時を除きます。
関連項目:
ローリング・データベース・アップグレードの詳細は、「SQL Applyを使用したOracle Databaseのアップグレード」を参照してください。
次のリストに、Oracle Data Guard使用時のOracleソフトウェア要件を示します。
Oracle Data Guardは、Oracle Database Enterprise Editionの専用機能として提供されています。Oracle Database Standard Editionには提供されていません。
注意:
Oracle Database Standard Editionを実行しているデータベースでは、スタンバイ・データベース環境を再現することが可能です。これを行うには、オペレーティング・システムのコピー・ユーティリティ、または定期的にアーカイブREDOログ・ファイルをデータベースからデータベースに送信するカスタム・スクリプトを使用して、手動でアーカイブREDOログ・ファイルを転送し、それらを登録し、メディア・リカバリを使用して障害時リカバリ・サイトのデータベースのコピーをロール転送します。このような構成では、Oracle Data Guardによって提供される利便性、管理性、パフォーマンスおよび障害時リカバリ機能を得られません。
Oracle Data Guard SQL Applyを使用して、Oracle Databaseソフトウェアをパッチ・セット・リリースn(10.1.0.3以上)から上位バージョンのパッチ・セットまたはメジャー・バージョン・リリースにローリング・アップグレードできます。ローリング・アップグレード時には、プライマリ・データベースおよびロジカル・スタンバイ・データベースを1つずつアップグレードする間、異なるリリースのOracle Databaseを実行できます。詳細は、「SQL Applyを使用したOracle Databaseのアップグレード」および該当するOracle Database 10gパッチ・セット・リリースのREADMEファイルを参照してください。
Oracle Data Guard構成のすべてのデータベースで、COMPATIBLEデータベース初期化パラメータを同じ値に設定する必要がありますが、ロジカル・スタンバイ・データベースは例外で、プライマリ・データベースよりもCOMPATIBLEの設定値を大きくできます。
プライマリ・データベースはARCHIVELOGモードで実行する必要があります。詳細は、『Oracle Database管理者ガイド』を参照してください。
プライマリ・データベースは、単一インスタンス・データベースまたはOracle Real Application Clusters(Oracle RAC)データベースのいずれかです。スタンバイ・データベースは、単一インスタンス・データベースまたはOracle RACデータベースで、フィジカル・タイプ、ロジカル・タイプおよびスナップショット・タイプを組み合せることができます。
プライマリ・データベースとスタンバイ・データベースには、それぞれ独自の制御ファイルが必要です。
スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、スタンバイ・データベースのアーカイブ・ディレクトリは、プライマリ・データベースとは異なるディレクトリ構造を使用する必要があります。同じ構造を使用すると、スタンバイ・データベースがプライマリ・データベース・ファイルを上書きする可能性があります。
プライマリ・データベースに対して、ログに記録されず、スタンバイ・データベースに伝播できないダイレクト書込みが行われるのを防ぐには、プライマリ・データベースでFORCE LOGGINGをオンにした後で、スタンバイ作成用にデータファイルのバックアップを実行します。スタンバイ・データベースが必要な間は、データベースをFORCE LOGGINGモードに保持してください。
プライマリおよびスタンバイ・データベース・インスタンスを管理するために使用するユーザー・アカウントは、SYSDGまたはSYSDBA管理権限を持つ必要があります。
動作を簡略化するために、Oracle Automatic Storage Management(Oracle ASM)およびOracle Managed Files(OMF)をOracle Data Guard構成で設定する際は、プライマリおよびスタンバイ・データベースに対称的に設定することをお薦めします。移行やメンテナンス用に意図的に混合構成を実装する場合を除き、Oracle Data Guard構成のいずれかのデータベースでOracle ASM、OMF、またはその両方を使用する場合は、構成内のすべてのデータベースでもそれぞれOracle ASM、OMFまたはその両方を使用する必要があります。詳細は、「OMFまたはOracle ASMを使用するスタンバイ・データベースの作成」のシナリオを参照してください。
注意:
更新の際に時間ベースのデータが使用される一部のアプリケーションでは、複数のタイムゾーンで入力されたデータを処理できないため、ロールの推移後もレコードの時間的順序が維持されるよう、プライマリおよびリモート・スタンバイ・システムに同じタイムゾーンを設定することをお薦めします。
各種スタンバイ・データベースのディレクトリ構造によってスタンバイ・データファイル、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイルのパス名が決まるため、ディレクトリ構造は重要です。可能であれば、プライマリ・システムとスタンバイ・システムでデータファイル、ログ・ファイルおよび制御ファイルの名前およびパス名を同一にし、Optimal Flexible Architecture(OFA)のネーミング規則を使用する必要があります。スタンバイ・データベースのアーカイブ・ディレクトリも、サイズおよび構造を含めてサイト間で同一であることが必要です。この方法により、バックアップ、スイッチオーバーおよびフェイルオーバーなどの他の操作を同じ手順で実行できるようになり、メンテナンスの複雑さが軽減されます。
関連項目:
Optimal Flexible Architecture(OFA)の詳細は、オペレーティング・システム固有のOracleドキュメントを参照してください。
同一にしない場合は、ファイル名変換パラメータ(表2-1を参照)を設定するか、データファイルの名前を変更する必要があります。ディレクトリ構造が異なるシステムを使用する必要がある場合や、スタンバイ・データベースとプライマリ・データベースのシステムを同じにする必要がある場合は、管理作業を最小限に抑えるようにしてください。
図2-1に、3つの基本構成オプションを示します。構成オプションは、次のとおりです。
スタンバイ・データベースがプライマリ・データベースと同じシステムにあるが、プライマリ・システムとは異なるディレクトリ構造を使用する。これは、図2-1のStandby1です。
スタンバイ・データベースをプライマリ・データベースと同じシステムに配置する場合は、異なるディレクトリ構造を使用する必要があります。同じ構造を使用すると、スタンバイ・データベースがプライマリ・データベース・ファイルを上書きしようとします。
スタンバイ・データベースが別個のシステム上にあり、プライマリ・システムと同じディレクトリ構造を使用する。これは、図2-1のStandby2です。このオプションをお薦めします。
スタンバイ・データベース別個のシステム上にあり、プライマリ・システムと異なるディレクトリ構造を使用する。これは、図2-1のStandby3です。
注意:
動作を簡略化するために、Oracle Automatic Storage Management(Oracle ASM)およびOracle Managed Files(OMF)をOracle Data Guard構成で設定する際は、プライマリおよびスタンバイ・データベースに対称的に設定することをお薦めします。移行やメンテナンス用に意図的に混合構成を実装する場合を除き、Oracle Data Guard構成のいずれかのデータベースでOracle ASM、OMF、またはその両方を使用する場合は、構成内のすべてのデータベースでもそれぞれOracle ASM、OMFまたはその両方を使用する必要があります。詳細は、「OMFまたはOracle ASMを使用するスタンバイ・データベースの作成」のシナリオを参照してください。
図2-1では、プライマリ・データベースとスタンバイ・データベースの可能な構成およびそれぞれの結果的な注意事項について説明します。
表2-1 スタンバイ・データベースの位置とディレクトリ・オプション
| スタンバイ・システム | ディレクトリ構造 | 結果的な注意事項 |
|---|---|---|
プライマリ・システムと同じ |
プライマリ・システムと異なる(必須) |
|
離れたシステム |
プライマリ・システムと同じ |
|
離れたシステム |
プライマリ・システムと異なる |
|
データベースがアクティブにファイルにアクセスしている間に、オンライン・データ・ファイルをある物理ファイルから別の物理ファイルへと移行することができます。これを行うには、SQL文ALTER DATABASE MOVE DATAFILEを使用します。
ALTER DATABASE MOVE DATAFILE文を使用して実行する操作は、データベースの可用性を向上させます。オンライン・データファイルの場所を移行するのにデータベースを停止する必要がないからです。Oracle Database 12cリリース1 (12.1)以前のリリースでは、データベースが停止しているかオープンしていない場合、または最初にファイルをオフラインにすることにより、オンライン・データファイルの場所を移行できるだけでした。
データファイルのオンライン移動操作はプライマリおよびスタンバイ(フィジカルまたはロジカルのいずれも)で独立して実行できます。データファイルがプライマリで移行する場合もスタンバイは影響を受けず、逆も同様です。
フィジカル・スタンバイで、データベースをオープンするインスタンスが読取り専用モードの場合、スタンバイのリカバリの実行中に、データファイルのオンライン移行操作を実行できます。この機能には、Oracle Active Data Guardのライセンスが必要です。
スタンバイがマウントされていてオープンされていない場合、ファスト・スタート・フェイルオーバー・ターゲットであるフィジカル・スタンバイのオンライン・データファイルの改名または再配置を、SQL ALTER DATABASE MOVE DATAFILEコマンドを使用して行うことはできません。
マウントされているがオープンされていないインスタンスでのスタンバイのリカバリの実行中、フィジカル・スタンバイで、データファイルのオンライン移行操作は実行できません。
スタンバイ・リカバリ・プロセスがデータファイルをオフラインで取得、ファイルを縮小、または表領域を削除すると、データファイルのオンライン移行操作は中断されます。
プライマリ・データベースで、プライマリ・データベースのすべてのインスタンスでクローズ済のプラガブル・データベース(PDB)に属するファイルで、データファイルのオンライン移行操作は実行できません。
関連項目:
オンライン・データファイルの改名および再配置の詳細は、『Oracle Database管理者ガイド』を参照してください。
ALTER DATABASE MOVE DATAFILE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
