11gリリース1（11.1）
E05755-03
 目次 |
 索引 |
| Oracle Data Guard 概要および管理 11gリリース1（11.1） E05755-03 |
|
Data Guard構成には、1つのプライマリ・データベースと、それに対応付けられた最大9個のスタンバイ・データベースが含まれます。この章では、Data Guardの使用を開始するための次の考慮事項について説明します。
スタンバイ・データベースは、Oracle本番データベースのトランザクション一貫性のあるコピーで、最初はプライマリ・データベースのバックアップ・コピーから作成されます。スタンバイ・データベースが作成および構成されると、Data Guardは、プライマリ・データベースのREDOデータをスタンバイ・システムに転送し、スタンバイ・データベースに適用することによって、スタンバイ・データベースを自動的にメンテナンスします。
スタンバイ・データベースのタイプには、フィジカル・スタンバイ・データベース、ロジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースがあります。フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースは、必要に応じてプライマリ・データベースのロールを担い、本番処理を引き継ぐことができます。Data Guard構成には、これらのタイプのスタンバイ・データベースを任意に組み合せて含めることができます。
フィジカル・スタンバイ・データベースは、プライマリ・データベースのブロック単位の完全コピーです。フィジカル・スタンバイ・データベースは、REDO Applyと呼ばれるプロセスにより完全コピーとしてメンテナンスされます。すなわち、データベース・リカバリ・メカニズムを使用して、プライマリ・データベースから受信されたREDOデータがフィジカル・スタンバイ・データベースに継続的に適用されます。
フィジカル・スタンバイ・データベースには次のメリットがあります。
フィジカル・スタンバイ・データベースは、堅牢で効率的な障害時リカバリおよび高可用性のソリューションです。管理が容易なスイッチオーバー機能とフェイルオーバー機能を使用すると、プライマリ・データベースとフィジカル・スタンバイ・データベース間でロールを可逆的に推移できるため、計画的および計画外の停止によるプライマリ・データベースの停止時間が最小限になります。
フィジカル・スタンバイ・データベースにより、予期しない障害が発生した場合でもデータ消失を防ぐことができます。フィジカル・スタンバイ・データベースでは、プライマリ・データベースでサポートされるすべてのデータ型、およびすべてのDDL操作とDML操作がサポートされます。また、データの破損やユーザーのミスに対する保護対策も用意されています。プライマリ・データベースの記憶域レベルの物理破損は、スタンバイ・データベースに伝播されません。同様に、データ消失の原因になりかねない論理的な破損やユーザー・エラーも簡単に解決できます。
Oracle Recovery Manager（RMAN）は、フィジカル・スタンバイ・データベースを使用してプライマリ・データベースからバックアップをオフロードし、貴重なCPUとI/Oのサイクルを節約できます。
フィジカル・スタンバイ・データベースは、REDO Applyがアクティブであれば問い合せることもできるため、プライマリ・データベースからフィジカル・スタンバイ・データベースに問合せをオフロードでき、プライマリ・データベースのワークロードはさらに低減します。
フィジカル・スタンバイ・データベースで使用されるREDO Applyテクノロジは、プライマリ・データベースで行われた変更でスタンバイ・データベースを常に更新することに関しては最も効率的なメカニズムです。これは、SQLレベルのコード・レイヤーをすべてバイパスする、低レベルのリカバリ・メカニズムを使用して変更を適用するためです。
ロジカル・スタンバイ・データベースは、最初はプライマリ・データベースと同じ内容のコピーで作成されますが、後で異なる構造に変更できます。ロジカル・スタンバイ・データベースは、SQL文を実行して更新されます。これにより、ユーザーは問合せとレポート生成の目的で、スタンバイ・データベースにいつでもアクセスできます。このように、ロジカル・スタンバイ・データベースは、データ保護操作とレポート生成操作に同時に使用できます。
Data Guardは、ログ・ファイルのデータをSQL文に変換し、ロジカル・スタンバイ・データベースでそのSQL文を実行することによって、アーカイブREDOログ・ファイルまたはスタンバイREDOログ・ファイルの情報をロジカル・スタンバイ・データベースに自動的に適用します。ロジカル・スタンバイ・データベースはSQL文を使用して更新されるため、オープン状態のままであることが必要です。ロジカル・スタンバイ・データベースは読取り/書込みモードでオープンされますが、再生成されたSQLに対するターゲット表は、読取り専用操作用にのみ使用可能です。更新中、これらの表は、レポート生成、要約、問合せなどの他のタスクで同時に使用できます。さらに、これらのタスクは、メンテナンスされている表に追加の索引やマテリアライズド・ビューを作成することによって最適化できます。
ロジカル・スタンバイ・データベースには、データ型、表のタイプ、DDL操作およびDML操作のタイプに関していくつかの制限があります。ロジカル・スタンバイ・データベースのデータ型およびDDLのサポートの詳細は、付録Cを参照してください。
ロジカル・スタンバイ・データベースは、データ・リカバリ（DR）のメリットとともに高可用性（HA）を提供するには理想的です。フィジカル・スタンバイ・データベースと比較して、ロジカル・スタンバイ・データベースは、さらに次の重要なHAのメリットを提供します。
ロジカル・スタンバイはREDOを分析してデータベースに対する論理的な変更を再構成するため、ブロック・レベルの変更を介してレプリケートされる可能性がある、プライマリでの特定の種類のハードウェア障害を検出し、それから保護することができます。Oracleでは、同じプライマリ・サーバーに対してフィジカル・スタンバイとロジカル・スタンバイの両方を保持できます。
ロジカル・スタンバイ・データベースは、プライマリでの変更をレプリケートする場合、読取り/書込み用にオープンされます。そのため、ロジカル・スタンバイ・データベースを同時に使用して、他の多くのビジネス要件を満たすことができます。たとえば、プライマリのスループットに対して問題のあるワークロードのレポート生成を実行できます。プライマリのデータの完全で正確なコピーに対して、ソフトウェアの新しいリリースやある種のアプリケーションをテストするのにも使用できます。また、ローカル変更に対してプライマリからレプリケートされたデータを保護しつつ、他のアプリケーションや追加スキーマをホスト管理できます。特定の種類の物理的な再構築（パーティショニング・スキームへの変更など）による影響を評価するのにも使用できます。ロジカル・スタンバイはユーザー・トランザクションを識別し、バックグラウンド・システムの変更を除外しながら対象の変更のみをレプリケートするため、目的のトランザクションのみを効率的にレプリケートできます。
ロジカル・スタンバイには、最新の一貫性のあるプライマリ・データベースのレプリカを作成するための、単純なターンキー・ソリューションがあります。このソリューションは、ワークロードの分散に使用できます。ワークロードの増加がレポートされた場合、プライマリ・サーバーのトランザクション・スループットに影響を与えずに透過的に負荷を分散して、ロジカル・スタンバイを追加作成できます。
ロジカル・スタンバイの主要なメリットは、重要な補助構造が作成してレポート生成のワークロードを最適化できることです。この構造は、プライマリのトランザクション・レスポンス時間にきわめて大きな影響を与えます。ロジカル・スタンバイは、異なるパーティショニングの様々な記憶域タイプにデータを物理的に再編成できます。また、多種多様な索引を保持し、オンデマンド・リフレッシュ・マテリアライズド・ビューを作成およびメンテナンスすることも可能です。さらに、データ・キューブおよび他のOLAPデータ・ビューを作成するのにも使用できます。
ロジカル・スタンバイを使用すると、パッチ・セットやソフトウェアの新しいリリースの適用に関連する停止時間を大幅に短縮できます。ロジカル・スタンバイは、新しいリリースへのアップブレード後に切り替えて、アクティブなプライマリにすることができます。これにより、古いプライマリをロジカル・スタンバイに変換してパッチ・セットを適用する間、完全な可用性を可能にします。
スナップショット・スタンバイ・データベースは、全面的に更新可能なスタンバイ・データベースで、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換して作成します。スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信およびアーカイブしますが、適用はしません。プライマリ・データベースから受信したREDOデータは、スナップショット・スタンバイ・データベースへのローカル更新がすべて破棄された後、スナップショット・スタンバイ・データベースが変換されてフィジカル・スタンバイ・データベースに戻ると適用されます。
スナップショット・スタンバイ・データベースは、通常、時間とともにプライマリ・データベースとは異なってきます。これは、プライマリ・データベースからのREDOデータが受信時に適用されないためです。スナップショット・スタンバイ・データベースに対するローカル更新が原因で、相違はさらに大きくなります。しかし、プライマリ・データベースのデータは完全に保護されます。これは、任意の時点でスナップショット・スタンバイを変換してフィジカル・スタンバイ・データベースに戻すことができ、その後にプライマリから受信したREDOデータが適用されるためです。
スナップショット・スタンバイ・データベースは、全面的に更新可能なスタンバイ・データベースで、フィジカル・スタンバイ・データベースと同様の、障害時リカバリおよびデータ保護のメリットがあります。スナップショット・スタンバイ・データベースは、プライマリ・データベースの一時的かつ更新可能なスナップショットを保持することにメリットがあれば、管理上の複雑さやプライマリ・データベースの障害からリカバリする時間が増えてもかまわない場合に最もよく使用されます。
スナップショット・スタンバイ・データベースの使用には、次のメリットがあります。
スナップショット・スタンバイの作成、テスト、本番環境との再同期化に続いて、再びスナップショット・スタンバイの作成およびテストを実行できることは、必要に応じて何度も繰り返すことができる1サイクルです。同じプロセスを使用して、データへの読取り/書込みアクセスが必要なレポート生成用にスナップショット・スタンバイを簡単に作成し、定期的に更新できます。
Data Guard構成の構成、実装および管理には、次のインタフェースを使用できます。
Enterprise Managerでは、Data Guard環境の作成、構成および監視に関係するタスクの多くを自動化する、Data Guard BrokerのGUIインタフェースが用意されています。GUIおよびウィザードの詳細は、『Oracle Data Guard Broker』およびOracle Enterprise Managerのオンライン・ヘルプを参照してください。
いくつかのSQL*Plus文では、STANDBYキーワードを使用して、スタンバイ・データベースに対する操作を指定します。他のSQL文にはスタンバイ固有の構文はありませんが、スタンバイ・データベースで操作を実行するときに役立ちます。関連する文のリストは、第16章を参照してください。
Data Guard環境の定義には、いくつかの初期化パラメータが使用されます。関連する初期化パラメータのリストは、第14章を参照してください。
DGMGRLコマンドライン・インタフェースは、Enterprise Managerの代替手段です。DGMGRLコマンドライン・インタフェースは、ブローカを使用してバッチ・プログラムまたはスクリプトからData Guard構成を管理する場合に役立ちます。詳細は、『Oracle Data Guard Broker』を参照してください。
次の各項で、Data Guard使用時の動作要件を説明します。
Oracle Database 11gでは、またMetaLink Note 4134841.1に記載されている現在の制限により、Data Guard構成に対するData Guardの柔軟性が増し、プライマリ・システムおよびスタンバイ・システムに、異なるCPUアーキテクチャ、オペレーティング・システム（WindowsやLinuxなど）、オペレーティング・システムのバイナリ（32ビット/64ビット）またはOracleデータベースのバイナリ（32ビット/64ビット）が存在してもかまいません。混在するプラットフォームのサポートの詳細は、https://metalink.oracle.comからOracle MetaLink Note 413484.1を参照してください。
同じリリースのOracle Database Enterprise Editionをプライマリ・データベースおよびすべてのスタンバイ・データベースにインストールする必要があります。ただし、ロジカル・スタンバイ・データベースを使用したローリング・データベース・アップグレード時を除きます。
次のリストに、Data Guard使用時のOracleソフトウェア要件を示します。
COMPATIBLE初期化パラメータを同じ値に設定する必要があります。
FORCE LOGGINGをオンにした後で、スタンバイ作成用にデータファイルのバックアップを実行します。スタンバイ・データベースが必要な間は、データベースをFORCE LOGGINGモードに保持してください。
SYSDBAシステム権限が必要です。
各種スタンバイ・データベースのディレクトリ構造によってスタンバイ・データファイル、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイルのパス名が決まるため、ディレクトリ構造は重要です。可能であれば、プライマリ・システムとスタンバイ・システムでデータファイル、ログ・ファイルおよび制御ファイルの名前およびパス名を同一にし、Optimal Flexible Architecture（OFA）のネーミング規則を使用する必要があります。スタンバイ・データベースのアーカイブ・ディレクトリも、サイズおよび構造を含めてサイト間で同一であることが必要です。この方法により、バックアップ、スイッチオーバーおよびフェイルオーバーなどの他の操作を同じ手順で実行できるようになり、メンテナンスの複雑さが軽減されます。
同一にしない場合は、ファイル名変換パラメータ（表2-1を参照）を設定するか、データファイルの名前を変更する必要があります。ディレクトリ構造が異なるシステムを使用する必要がある場合や、スタンバイ・データベースとプライマリ・データベースのシステムを同じにする必要がある場合は、管理作業を最小限に抑えるようにしてください。
図2-1に、3つの基本構成オプションを示します。構成オプションは、次のとおりです。
Standby1です。スタンバイ・データベースをプライマリ・データベースと同じシステムに配置する場合は、異なるディレクトリ構造を使用する必要があります。同じ構造を使用すると、スタンバイ・データベースがプライマリ・データベース・ファイルを上書きしようとします。
Standby2です。このオプションをお薦めします。
Standby3です。
Data Guard構成のいずれかのデータベースでASM、OMF、またはその両方を使用する場合、構成内のすべてのデータベースでもそれぞれASM、OMFまたはその両方を使用する必要があります。Data Guard構成でのOMFのセットアップ方法を説明する使用例は、第13章を参照してください。
注意
表2-1では、プライマリ・データベースとスタンバイ・データベースの可能な構成およびそれぞれの結果的な注意事項について説明します。Data Guard構成の複数のメンバーが同じシステムに存在する場合は、DB_UNIQUE_NAME初期化パラメータに一意の値を指定する必要があります。各データベースが異なるシステムに存在する場合も、DB_UNIQUE_NAME初期化パラメータには常に一意の値を指定することをお薦めします。
| スタンバイ・システム | ディレクトリ構造 | 結果的な注意事項 |
|---|---|---|
|
プライマリ・システムと同じ |
プライマリ・システムと異なる（必須） |
|
|
離れたシステム |
プライマリ・システムと同じ |
|
|
離れたシステム |
プライマリ・システムと異なる |
|
|
 Copyright © 1999, 2008 Oracle Corporation. All Rights Reserved. |
|