Oracle Data Guard 11g Oracle RACシステムでのインストールと構成

Transcription

1 Oracle Data Guard 11g Oracle RAC システムでのインストールと構成 Oracle ホワイト ペーパー 2008 年 4 月 Maximum Availability Architecture Oracle Best Practices For High Availability

2 目次 1 はじめに 目的 背景 対象範囲とアプリケーション 関連ドキュメント 前提条件 アーキテクチャと概念 用語 Oracle RAC アーキテクチャ Oracle Data Guard アーキテクチャ ネットワーク Oracle Data Guard アーキテクチャ ログ転送サービス ログ適用サービス Oracle Data Guard Broker 機能 アーカイブ ログの送信 スタンバイ REDO ログ 保護レベル 最大保護モード 最大可用性モード 最大パフォーマンス モード 長所と短所 前提条件 ハードウェア ネットワーク ソフトウェア Oracle Real Application Clusters Oracle ASM RAW デバイス Oracle Data Guard 環境の作成 前提条件 手順 - まとめ Oracle RAC スタンバイ データベースの作成 プライマリ サイトとスタンバイ サイトの構成 各サイトへの Oracle ソフトウェアのインストール サーバー名と VIP Oracle ネットワーキングの構成 各サイトでの Oracle ASM の構成... 16

3 4.3.6 プライマリ データベースの複製準備 プライマリ データベースの複製 スタンバイ データベースの spfile 作成 第 2 制御ファイルの作成 スタンバイ データベースのクラスタ対応 一時ファイル スタンバイ REDO ログの作成 SQL Plus を使用した Oracle Data Guard の構成 はじめに スタンバイ データベースの構成 プライマリ データベースの構成 保護モードの設定 REDO 転送と REDO Apply の有効化 Oracle Data Guard Broker を使用した Oracle Data Guard の構成 はじめに Oracle Data Guard Broker 構成ファイル Oracle Data Guard Broker の有効化 Oracle Data Guard Broker 構成の作成 Oracle Data Guard Broker 構成の有効化 Oracle Data Guard Broker のカスタマイズ 監視 はじめに ログ ファイル 固定ビュー 管理 スイッチオーバー SQL Plus を使用したスイッチオーバー Oracle Data Guard Broker を使用したスイッチオーバー フェイルオーバー SQL Plus を使用したフェイルオーバー Oracle Data Guard Broker を使用したフェイルオーバー 強制フェイルオーバー Oracle Data Guard Broker を使用した強制フェイルオーバー スタンバイ データベースの読取り専用オープン リアルタイム適用 / リアルタイム問合せ 付録 A - Oracle RMAN を使用したスタンバイ データベースの作成 ( 従来の方法 前提条件 Oracle RMAN のバックアップ 新規バックアップ 既存バックアップ スタンバイ データベースの作成 前提条件 手順 付録 B - 参考資料 Oracle マニュアル Metalink... 35

4 1 はじめに 1.1 目的 このドキュメントでは Oracle Real Application Clusters(Oracle RAC11g と Oracle Data Guard 11g を使用した高可用性環境を作成するためのエンドツーエンド プロセスについて説明します このホワイト ペーパーは標準ドキュメントを補完するものであり 環境全体を構築するすべてのプロセスについて説明します また この環境は プライマリ システムとフィジカル スタンバイ システムの両方が Oracle RAC に基づいています ここで説明するプロセスは ワークショップやコンサルティング契約でオラクルや顧客により繰り返しテストおよび適用されているものであり 実際の経験を反映したものです 1.2 背景 Oracle データベースは ミッション クリティカルな情報を保存するために使用されています この情報は たとえ大災害が発生しても安全に維持されている必要があります この安全性を得るために使用されてきた従来の手法は Oracle RAC やリモート ディスクのミラー化などのハードウェア指向ソリューションを中心としていました Oracle RAC は高水準の可用性を提供しますが RAC ノードは一般に同じコンピュータ室に設置されています ( 拡張クラスタをのぞく Oracle RAC クラスタにより ハードウェア層に高度な冗長性をもたらすことでシングル ポイント障害の発生を回避します しかし データベース単体 ( 現在もシングル やコンピュータ室自体など アーキテクチャ内には依然としてシングル ポイント障害が存在します コンピュータ室が破壊されるか孤立した場合 クラスタへのアクセスも不可能となります データベース自体が使用できなくなった場合 ( 部分的または全体的な障害 も サーバー レベルの冗長性はあまり役に立ちません このような事態に適用されるのが障害時リカバリ計画です この計画には 別のマシンへのデータベースのリストアが含まれる場合があります しかし このプロセスには完了までに何時間もかかる可能性が高いため 別のマシンにリストア済みのデータベースを用意しておき 継続的に最新の状態を維持しておくことがより優れた解決策といえます その場合 障害が発生しても このデータベースは非常に迅速に回復できます オラクルが提供するこのテクノロジーは Oracle Data Guard と呼ばれ データベース自体はスタンバイ データベースといいます 実際 Oracle Data Guard は 2 種類のスタンバイ データベース ( フィジカルおよびロジカル に関する概念フレームワークですが このドキュメントではフィジカル スタンバイ データベースのみに焦点を当てて説明します 1.3 対象範囲とアプリケーション このドキュメントでは Oracle Data Guard をインストールする際の一般的なステップについて とくに Oracle RAC に関するステップについて確認していきます また スタンバイ データベースが配置されているサイトにプライマリ サイトからスイッチオーバーやフェイルオーバーを実行する際に必要な手続きも含まれます

5 1.4 関連ドキュメント Oracle Data Guard 概要および管理 11g リリース 1 (2007 年 9 月 Oracle Data Guard Broker 11g リリース 1 (2007 年 9 月 1.5 前提条件 このドキュメントは以下の事項を前提としています 本番システムとスタンバイ システム間のネットワーク接続が 求められる保護レベル要件とデータベース REDO 情報の本番データ量の転送要件を満たしていること 読者が Oracle Net の構成に精通していること 読者が Oracle Recovery Manager(Oracle RMAN に精通していること 読者が Oracle RAC のインストールとその構成に精通していること

6 2 アーキテクチャと概念 2.1 用語 プライマリ サイト スタンバイ サイト 障害 本番データベースへアクセスするために接続するサイト スタンバイ データベースが維持されているサイト 障害時リカバリ (DR サイトとも呼ばれる フェイルオーバーまたはスイッチオーバーの適用時のみ このサイトに接続する プライマリ サイトが使用できないこと 2.2 Oracle RAC アーキテクチャ Oracle Real Application Clusters(Oracle RAC は高速インターコネクトで結合された多数の独立コンピュータ システムで構成されており そのすべてから同じディスク セットにアクセスできます Oracle RAC は ORACLE ASM RAW パーティション またはクラスタリングされたファイル システムを使用した共有ディスク上にデータベースを作成します Oracle 11g でもっとも一般的な実装方法は Oracle ASM を使用したものです それぞれのクラスタ ノードでは データベースとの対話に使用される Oracle インスタンスが実行されます ユーザーは 任意の Oracle インスタンスに接続してアプリケーションを実行できます 2.3 Oracle Data Guard アーキテクチャ スタンバイ サイトに配置されたノードのアーキテクチャがプライマリ サイトのアーキテクチャと一致することが理想的ですが これは必須ではありません スタンバイ システムのアーキテクチャを計画する場合 以下の事項を考慮する必要があります ( とくにプライマリ システムと同じアーキテクチャでない場合

7 フェイルオーバーが必要な場合 ( プライマリ サイトの計画外停止 スタンバイ サイトは期待されるワークロードを処理できるか プライマリ サイトでメンテナンスが実行されている間にスタンバイ サイトが使用される場合 ( 計画停止 スタンバイ サイトは期待されるワークロードを処理できるか 処理能力が十分である場合 次が当てはまります 以下はかならずしも必要ではありません スタンバイ サイトのクラスタリング スタンバイ サイトでの RAW デバイスの使用 ( スタンバイ サイト自体がクラスタである場合をのぞく 注 : 両方のサイト ( プライマリおよびスタンバイ で 完全に同じソフトウェア バージョンとオペレーティング システムを使用しなければならないという要件は緩和されました 現在は 柔軟な構成が選択できます 許容事項の状況は次のドキュメントに反映されています Metalink Note : Data Guard Support for Heterogeneous Primary and Standby Systems in Same Data Guard Configuration このドキュメントには 常に最新のサポート情報が記載されています 注 : スタンバイ システムがクラスタである場合 そのクラスタのうちの 1 つのノードのみがスタンバイ データベースと同期可能になります 残りのノードは スタンバイ システム上のデータベースが通常 ( 本番 運用としてオープンされるまでアイドル状態のままになります なんらかの理由でもとの適用ノードに障害が発生した場合 Oracle Data Guard Broker により " 適用ノード " がスタンバイ クラスタの使用可能なノードへ自動的にフェイルオーバーされます これについて詳しくは後述します 2.4 ネットワーク プライマリ サイトおよびスタンバイ サイトは ネットワーク リンクを介して接続されます このネットワーク リンクは信頼性が高く 適切な帯域幅と待機時間を維持している必要があります Oracle Data Guard には次の 3 種類のモードがあります 最大保護モード 最大可用性モード 最大パフォーマンス モード 詳しくは後述しますが 初めの 2 つのモードではスタンバイ サイトへの同期書込みが必要になります 同期書込みを使用すると 多くの場合 パフォーマンスのトレードオフが発生することに注意してください これらのモードはデータ損失ゼロの保護を実現しますが 帯域幅が限定されている場合や プライマリ データベースとスタンバイ データベース間のラウンドトリップ ネットワーク待機時間 (RTT が長い場合は プライマリ データベースのパフォーマンスに影響を及ぼす可能性があります 1 MetaLink Note の参照には MetaLink アカウントが必要です (

8 2.5 Oracle Data Guard アーキテクチャ 次の図に Oracle Data Guard のアーキテクチャ コンポーネントを示します 詳しくは後述します ログ転送サービス ログ転送サービス ( 別名 REDO 転送サービス は プライマリ データベースからスタンバイ データベースに対して 2 つの方法で変更を伝播するよう設計されています 1 つはアーカイブ ログを転送する方法 (ARCH であり もう 1 つはログ ライター プロセスに処理された REDO データを継続的に転送する方法 (LNS です ログ適用サービス ログ適用サービス ( フィジカル スタンバイ データベースでは 'REDO Apply' ロジカル スタンバイ データベースでは 'SQL Apply' は アーカイブ済みまたはスタンバイの REDO ログ ファイルからスタンバイ データベースに REDO 情報を適用する役割を果たします

9 2.5.3 Oracle Data Guard Broker Oracle Data Guard Broker は管理および監視コンポーネントであり 1 つ以上のフィジカル スタンバイ データベースによって保護されるプライマリ データベースの作成 制御 および監視に使用されます Oracle Data Guard Broker の使用は Oracle RAC 環境でサポートされています 2.6 機能 プライマリ データベースに情報が書き込まれると 同じ情報がスタンバイ データベースにも送信され 適用されます 基本的に これらは 2 つの段階として処理され直接相互連動するものではありません アーカイブ ログの送信 このシナリオでは プライマリ データベース インスタンスによってアーカイブ ログが生成されます アーカイブ ログは作成されるとすぐにスタンバイ サイトに送信され (ARCH プロセスによる そこでデータベースに適用されます この処理はただちに実行することも 設定した待ち時間のあとで実行することもできます スタンバイ REDO ログ REDO 情報の転送方法として望ましいのは LNS プロセスを利用する方法です LNS プロセスは Logwriter バックグラウンド プロセスが REDO バッファを消去してオンライン REDO ログ ファイルに書き込むと同時に REDO データを転送します これにより ネットワーク全体で REDO データが連続して流れます ( ピークなし ベスト プラクティスでは データを受信するスタンバイ サイトにスタンバイ REDO ログ (SRL を構成する必要があります この場合 受信 REDO は SRL に直接書き込まれます SRL の数は プライマリ データベース上のすべてのオンライン REDO ログの合計に 1 を加えたものと等しくする必要があります たとえば 4 つの RAC インスタンスにそれぞれ 4 つの REDO ログが含まれる場合 SRL の数は 17 になります プライマリ インスタンス上のオンライン REDO ログにデータが書き込まれるたびに そのデータがいずれかのスタンバイ REDO ログに同時に書き込まれます プライマリのオンライン REDO ログでログ スイッチ処理が実行されると スタンバイ データベース上でもログ スイッチ処理がおこなわれます つまり 最新の SRL がスタンバイ システム上のローカル ディレクトリにアーカイブされます Oracle 10g から ' リアルタイム適用 ' 機能が導入されました リアルタイム適用を使用すると REDO がスタンバイ REDO ログに書き込まれると同時に ログ スイッチ処理を待たずにスタンバイ データベースに適用されます

10 2.7 保護レベル Oracle Data Guard では 異なる保護レベルの設定がおこなえます それぞれの保護モードについて 以下にまとめます 最大保護モード このソリューションは 複数の障害が発生したシナリオ ( ネットワーク障害とプライマリ サイト障害 において プライマリ サイトとスタンバイ サイト間でのデータ損失ゼロを保証します なんらかの理由で最後のスタンバイ サイトが使用不能になると プライマリ データベースは停止されます 最大可用性モード このソリューションは 単一障害シナリオにおいてデータ損失ゼロを実現します なんらかの理由でスタンバイ サイトが使用不能になった場合 ( 単一障害 も この保護モードは " 可用性 " に重点を置いているため プライマリ データベース上での作業を継続できます プライマリ データベースの消失など 2 番目の障害がこの期間中に発生した場合 プライマリ データベース上の保護されていないトランザクションが消失します スタンバイ データベースが再び使用可能になると 自動的にプライマリ データベースのアーカイブ ログから未転送のデータをすべて取得し 手動介入なしで再同期します 最大パフォーマンス モード このソリューションでは LNS プロセスを介して非同期に REDO を送信するか または生成されたアーカイブ REDO ログを ARCH プロセス経由でプライマリ データベースからスタンバイ データベースに送信します この場合 プライマリ データベースとスタンバイ データベースが同期化されているという保証はないため 障害時には一定のデータ損失が発生する可能性があります 長所と短所 最大保護モードと最大可用性モードでは プライマリ サイトとスタンバイ サイトの間に高水準のネットワーク リンクが必要になります これは プライマリ データベースにデータが書き込まれると 同じ情報が同時にスタンバイ サイト上で書き込まれるためです つまり ネットワークの帯域幅が十分でない場合や WAN 環境でよく見られるように RTT 待機時間が長い場合 データ損失ゼロの保護による付加利益とプライマリ データベースのパフォーマンスへの潜在的影響を比較検討する必要があります 最大パフォーマンス モードはプライマリ データベースのパフォーマンスに影響を与えませんが REDO 転送の非同期性により フェイルオーバー時のデータ損失の可能性が残ります

11 3 前提条件 3.1 ハードウェア スタンバイ サイトは プライマリ サイトのワークロードに対応できるハードウェア上に配置することが理想的です これは必須条件ではありませんが スタンバイ サイトへのフェイルオーバーが必要な場合に同様のサービス レベルが達成されます 3.2 ネットワーク スタンバイ サイトでの最大保護モードまたは最大可用性モードの実現を円滑にするため プライマリ データベースは REDO ログ情報をプライマリ サイトとスタンバイ サイトの両方に同時に書き込みます したがって これらのサイト間のネットワーク リンクには以下が不可欠になります 高い信頼性 ( シングル ポイント障害がないこと 適切な帯域幅 ( 期待される REDO 量による 非常に短い待機時間 3.3 ソフトウェア 以前の Oracle リリースでは プライマリ サイトとスタンバイ サイトの両方で同じバージョンのデータベース ソフトウェアを実行する必要がありましたが この要件は実質的に緩和されました 混在環境に対する現行サポートについて 詳しくは Metalink Note を参照してください 3.4 Oracle Real Application Clusters Oracle ASM プライマリ データベースでディスク ストレージに Oracle ASM を使用している場合 スタンバイ サイトでも Oracle ASM を構成することを強く推奨します 注 :Oracle ASM は Oracle RAC データベースに望ましいストレージ管理機能であり Oracle RAC 以外のデータベースで使用されるケースも増加しています RAW デバイス プライマリ データベースが Oracle RAC データベースで RAW デバイスを利用しており かつスタンバイ データベースもクラスタ データベースである場合 スタンバイ サイトにも RAW デバイスを構成する必要があります 1 MetaLink Note の参照には MetaLink アカウントが必要です (

12 ただし スタンバイ サイトがクラスタでない場合はスタンバイ データベースで RAW デバイスを使用する必要はありません この場合は 次の手順にしたがうことによって管理が容易になります 非 RAW デバイス 1. スタンバイ サイトに データ ファイルを格納するディレクトリを作成します 2. それぞれのプライマリ RAC ノードに 同じディレクトリを作成します 3. プライマリ RAC ノードに このディレクトリから RAW デバイスへのシンボリック リンクを作成します 4. Oracle RAC データベースを作成する際 RAW デバイス名ではなくこれらのシンボリック リンクを使用します 長所 Oracle Data Guard によるデータベース ファイルの自動管理が可能になります つまり プライマリ データベースに追加されたファイルは 自動的にスタンバイ データベースにも追加されます 両方のサイトでディレクトリ構造が正確に一致しない場合 init.ora パラメータである db_file_name_convert と log_file_name_convert を使用してファイル名変換を設定する必要があります 例 :/u01/oradata/dbname/system.dbf は両方のサイトで同じ これは Oracle Managed Files を使用している場合にも当てはまります

13 4 Oracle Data Guard 環境の作成 4.1 前提条件 後述の手順では 以下を前提条件としています プライマリ ホスト名は europa および callistos スタンバイ ホスト名は dione および hyperion プライマリ データベースの参照名は MOON 仮想名は europa-vip callisto-vip dione-vip および hyperion-vip プライマリ データベースとスタンバイ データベースの両方でストレージに Oracle ASM を使用 使用する ASM ディスク グループは +DATA( データ用 と +FRA( リカバリ / フラッシュバック用 スタンバイ データベースの参照名は SUN Oracle Managed Files を使用 ORACLE_BASE は /u01/app/oracle に設定 後述の手順において これらの名前は上述のようにハイライト表示されます 4.2 手順 - まとめ Oracle Data Guard 環境を作成する手順を以下にまとめます 各タスクの実行方法について 詳しくは後述の項で説明します 1. プライマリ サイトとスタンバイ サイトの構成 2. 各サイトへの Oracle ソフトウェアのインストール 3. 各サイトでの Oracle ネットワーキング構成 4. 各サイトでの Oracle ASM 構成 5. 各サイトでのリスナー構成 6. 各サイトでの Oracle ネットワーキング構成 7. 初期化ファイルの作成 ( プライマリおよびスタンバイ 8. スタンバイ サイトへのプライマリ データベースの複製 9. スタンバイ サイトのサーバー パラメータ ファイルの作成 10. スタンバイ制御ファイルの追加作成 11. スタンバイ REDO ログ ファイルの作成 12. クラスタへのスタンバイ データベース登録 13. Oracle Data Guard Broker の構成 14. スタンバイ データベースの保護モードの設定 15. 監視

14 4.3 Oracle RAC スタンバイ データベースの作成 プライマリ サイトとスタンバイ サイトの構成 環境の管理 ( と Oracle Data Guard の構成 を容易にするため プライマリ マシンとスタンバイ マシンの構造を正確に一致させることを推奨します 具体的には 以下のように設定します 両サイトの ORACLE_HOME が同じマウント ポイントを指すようにする 両サイトの ORACLE_BASE/admin が同じマウント ポイントを指すようにする 両サイトの ASM ディスク グループを一致させる 各サイトへの Oracle ソフトウェアのインストール Oracle ソフトウェアは 両方のサイトで Oracle メディアからインストールします 一般的には以下のソフトウェアが含まれます Oracle Clusterware Oracle ASM により使用される Oracle データベース実行ファイル Oracle RDBMS により使用される Oracle データベース実行ファイル サーバー名と VIP Oracle Real Application Clusters 11g では 仮想サーバー名と IP アドレスは Oracle Cluster Ready Services(Oracle CRS によって使用および維持されます 次に クラスタのネーミング例を示します 注 : 略称と完全修飾名の両方が存在します サーバー名 / 別名 / ホスト エントリ 目的 europa.local パブリック ホスト名 ( プライマリ ノード 1 callisto.local パブリック ホスト名 ( プライマリ ノード 2 dione.local パブリック ホスト名 ( スタンバイ ノード 1 hyperion.local パブリック ホスト名 ( スタンバイ ノード 2 europa-vip.local パブリック仮想名 ( プライマリ ノード 1 callisto-vip.local パブリック仮想名 ( プライマリ ノード 2

15 dione-vip.local パブリック仮想名 ( スタンバイ ノード 1 hyperion-vip.local パブリック仮想名 ( スタンバイ ノード Oracle ネットワーキングの構成 各サイトでのリスナー構成 各サイトにリスナーを定義し ASM Oracle Home から実行します この構成例では以下のリスナーを定義しています プライマリ ロール Listener_europa Listener_callisto Listener_dione Listener_hyperion 静的登録 Oracle は インスタンスがオープン マウント クローズのどの状態にあっても 両方のデータベースのすべてのインスタンスにアクセスできなければなりません つまり すべてのインスタンスをリスナーに静的登録する必要があります Oracle Data Guard Broker を使用しやすくするため これらのエントリには特別な名前が付与されます 詳しくは後述します Listener.ora 例 LISTENER_dione = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP(HOST = dione-vip(port = 1521 (IP = FIRST (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP(HOST = dione(port = 1521 (IP = FIRST (ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC(KEY = EXTPROC SID_LIST_LISTENER_dione = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME=SUN_dgmgrl.local (SID_NAME = SUN1 (ORACLE_HOME = $ORACLE_HOME

16 各サイトでの TNS エントリ構成 作業を実行しやすくするため 両方のサイトで同じネットワーク サービス名が生成されます 次に これらのサービス名を示します 別名 MOON1_DGMGRL.local MOON1.local MOON2.local MOON.local SUN1_DGMGRL.local SUN1.local SUN2.local SUN.local listener_db_unique_name.local コメントサービス名 MOON_DGMGRL.local を使用して europa 上の MOON インスタンスを指す スタンバイ データベースの作成に使用できる サービス名 MOON.local を使用して europa 上の MOON インスタンスを指す サービス名 MOON.local を使用して callisto 上の MOON インスタンスを指す MOON データベースを指す つまり すべてのデータベース インスタンスを含む サービス名 SUN1_DGMGRL を使用して dione 上の SUN インスタンスを指す ** データベースの複製に使用する サービス名 SUN.local を使用して dione 上の SUN インスタンスを指す サービス名 SUN.local を使用して hyperion 上の SUN インスタンスを指す SUN データベースを指す つまり すべてのデータベース インスタンスを含む 2 つのアドレス行で構成される TNS 別名エントリ 最初のアドレス行はノード 1 上のリスナーのアドレスであり 2 番目はノード 2 上のリスナーのアドレス 上記リスナーの両方をアドレス リストに含むことで データベースは自動的に両ノードに登録される 2 セットのエントリを含む必要がある スタンバイ ノード用の listener_sun およびプライマリ ノード用の listener_moon tnsnames.ora の例 (europa MOON1_DGMGRL.local = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP(HOST = europa-vip(port = 1521 (CONNECT_DATA = (SERVER = DEDICATED (SERVICE_NAME = MOON_DGMGRL.local MOON1.local = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP(HOST = europa-vip(port = 1521 (CONNECT_DATA = (SERVER = DEDICATED (SERVICE_NAME = MOON.local (INSTANCE_NAME = MOON1 MOON2.local = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP(HOST = callisto-vip(port = 1521 (CONNECT_DATA = (SERVER = DEDICATED

17 (SERVICE_NAME = MOON.local (INSTANCE_NAME = MOON2 MOON.local = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP(HOST = europa-vip(port = 1521 (ADDRESS = (PROTOCOL = TCP(HOST = callisto-vip(port = 1521 (LOAD_BALANCE = yes (CONNECT_DATA = (SERVER = DEDICATED (SERVICE_NAME = MOON.local SUN1_DGMGRL.local = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP(HOST = dione-vip(port = 1521 (CONNECT_DATA = (SERVER = DEDICATED (SERVICE_NAME = SUN_DGMGRL.local SUN2.local= (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP(HOST = hyperion-vip(port = 1521 (CONNECT_DATA = (SERVER = DEDICATED (SERVICE_NAME = SUN.local (INSTANCE_NAME=SUN2 SUN1.local= (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP(HOST = dione-vip(port = 1521 (CONNECT_DATA = (SERVER = DEDICATED (SERVICE_NAME = SUN.local (INSTANCE_NAME=SUN1 SUN.local= (DESCRIPTION = (ADDRESS_LIST= (ADDRESS = (PROTOCOL = TCP(HOST = dione-vip(port = 1521 (ADDRESS = (PROTOCOL = TCP(HOST = hyperion-vip(port = 1521 (CONNECT_DATA = (SERVER = DEDICATED (SERVICE_NAME = SUN.local LISTENERS_MOON.local= (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP(HOST = europa-vip(port = 1521 (ADDRESS = (PROTOCOL = TCP(HOST = callisto-vip(port = 各サイトでの Oracle ASM の構成 ここで使用する Oracle RAC データベースは Oracle ASM を利用しているため 次へ進む前にスタンバイ サイトにも Oracle ASM を構成することを強く推奨します 説明を容易にするために スタンバイ サイトのディスク グループ名はプライマリ サイトのディスク グループ名と同じであるとします

18 4.3.6 プライマリ データベースの複製準備 初期化パラメータの中には データベースがスタンバイ データベース ロールまたはプライマリ データベース ロールのいずれかで実行している場合にのみ適用されるものがあります 両方のサイトにすべてのパラメータを定義しておくと ロールが切り替わる ( プライマリがスタンバイになり スタンバイが新しいプライマリになる 際も追加の設定をおこなう必要がありません ただし いくつかのパラメータはノード固有であるため プライマリ サイト ノード用のパラメータ セットとスタンバイ サイト ノード用のパラメータ セットを作成します プライマリ サイトの準備 複製をおこなう前に 次の初期化パラメータをプライマリ サイト上に設定します これらはプライマリ サイトでのみ適用されますが スタンバイ サイトでも同様に設定できます Dg_broker_config_file1 Dg_broker_config_file2 ASM ディスク グループ内のファイルを指す ファイルが存在する必要はない ASM ディスク グループ内のファイルを指す ファイルが存在する必要はない db_block_checksum データ ブロックの整合性チェックを有効にする ( オプション db_block_checking データ ブロックの一貫性チェックを有効にする ( オプション パフォーマンスが許す限り また既存の SLA に違反しない限り db_block_checksum および db_block_checking を設定する必要があります さらに 以下を設定する必要があります アーカイブ ログ モード プライマリ データベースをアーカイブ ログ モードに設定します 強制ロギング スタンバイ データベースを最新に保つためにスタンバイ サイトで適用されるトランザクションは オンライン REDO ログに記録されたものです 以前に Oracle Data Guard を利用していなかった環境では データベースのパフォーマンス向上のために NOLOGGING オプションが選択されている場合があります Oracle Data Guard で保護された環境でこの機能を使用することは きわめて不適切です Oracle Database のバージョン 9.2 以降では NOLOGGING トランザクションの発生を防ぐ方法が導入されています これは データベースの強制ロギング モードとして知られています 強制ロギングを有効にするには プライマリ データベースで次のコマンドを発行します alter database force logging; パスワード ファイル プライマリ データベースは 外部パスワード ファイルを使用するように設定する必要があります 通常 これはインストール時に実行されます インストール時に実行していない場合 次のコマンドを使用することでパスワード ファイルが作成できます

19 orapwd file=$oracle_home/dbs/orapwmoon1 password=mypasswd コマンドを発行する前に ORACLE_SID に適切なインスタンスが設定されていることを確認してください ここでは MOON1 です これをクラスタ内の各ノードで繰り返します また 初期化パラメータ remote_login_passwordfile に 'exclusive' が設定されていることを確認します Oracle Database 11g Release 1 (11.1 の場合 もう 1 つの方法として REDO 転送用の Oracle Net セッションを SSL 経由で認証できます (Oracle Data Guard 概要のマニュアルの 項を参照 スタンバイ サイトの準備 初期化ファイル 複製プロセスの一部で 一時的な初期化ファイルが使用されます このドキュメントの目的上 /tmp/initmoon.ora という名前のこのファイルには次の 1 行が含まれます db_name=moon パスワード ファイル スタンバイ データベースは パスワード ファイルを使用するように設定する必要があります このファイルを作成するには プライマリ サイトからスタンバイ サイトにパスワード ファイルをコピーし スタンバイ インスタンスを反映するように名前を変更します これをクラスタ内の各ノードで繰り返します また 初期化パラメータ remote_login_passwordfile に 'exclusive' が設定されていることを確認します 監査ファイルの保存先の作成 スタンバイ システムの各ノード上に監査ファイルを格納するディレクトリを作成します mkdir /u01/app/oracle/admin/sun/adump スタンバイ インスタンスの開始 ここまでで準備はすべて整ったので 複製を始めるためにスタンバイ インスタンスを開始します export ORACLE_SID=SUN1 sqlplus / as sysdba startup nomount pfile= /tmp/initmoon.ora 接続のテスト 次のコマンドを使用して プライマリ データベースからスタンバイ データベースへの接続をテストします sqlplus sys/mypasswd@sun_dgmgrl as sysdba 正しく接続したことを確認します

20 4.3.7 プライマリ データベースの複製 スタンバイ データベースはプライマリ データベースから作成します Oracle 10g 以前でこれを実行するには プライマリ データベースのバックアップを作成し スタンバイに転送してリストアする必要がありました このプロセスは Oracle RMAN 11g で提供された新しい方法により簡素化されました この方法では ' オンザフライ ' 複製が実行できます このドキュメントでは この方法を使用します (11g 以前の方法に関する説明は付録に記載 プライマリ データベースから 次のコマンドを使用して Oracle RMAN を起動します export ORACLE_SID=MOON1 rman target / auxiliary sys/mypasswd@sun1_dgmgrl 注 :Oracle RMAN からエラー "rman: can't open target" が返される場合 PATH の最初に ORACLE_ HOME/bin が表示されるようにしてください Linux ユーティリティにも RMAN という名前のものがあるためです 次に 以下の複製コマンドを実行します duplicate target database for standby from active database spfile set db_unique_name= SUN set control_files= +DATA/SUN/controlfile/control01.dbf set instance_number= 1 set audit_file_dest= /u01/app/oracle/admin/sun/adump set remote_listener= LISTENERS_SUN nofilenamecheck; スタンバイ データベースの spfile 作成 Oracle RMAN 複製コマンドは デフォルトで $ORACLE_HOME/dbs にあるインスタンスの spfile を作成します このファイルに含まれるエントリは プライマリ データベース上のインスタンス名を参照します 作成プロセスの一部でデータベース名はスタンバイ データベースの DB_UNIQUE_ NAME を反映するように変更されるため 作成される spfile は実質的に意味のないものになります ここでは プライマリ データベースの spfile の内容を使用して新しい spfile を作成します 制御ファイルの場所の取得 このプロセスを開始する前に 現在実行中のスタンバイ データベースから control_files パラメータの値を書きとめておきます テキスト形式初期化ファイルの作成 はじめに プライマリ データベースの初期化パラメータをテキスト ファイルにダンプします set ORACLE_SID=MOON1

21 sqlplus / as sysdba create pfile= /tmp/initsun.ora from spfile; 作成されたファイル /tmp/initsun.ora をスタンバイ サーバーへコピーします init.ora の編集 スタンバイ サーバー上で /tmp/initsun.ora ファイルを編集します 注 : すべての MOON を SUN に変更します ただし DB_NAME パラメータは変更しないでください control_files パラメータを設定して 上述の で得られた値を反映させます 通常 次のようになります +DATA/SUN/controlfile/control01.dbf 変更を保存します spfile の作成 テキスト形式の初期化ファイルはすでに作成してあるため 次のコマンドを使用してこれを spfile に変換してから Oracle ASM 内に保存します export ORACLE_SID=SUN1 sqlplus / as sysdba create spfile= +DATA/SUN/spfileSUN.ora from pfile= /tmp/initsun.ora ポインタ ファイルの作成 spfile が Oracle ASM 内に保存されたため RDBMS インスタンスにこの場所を知らせます スタンバイ ノード 1(dione の $ORACLE_HOME/dbs ディレクトリに initsun1.ora というファイルを作成します このファイルに次の 1 行を含めます spfile= +DATA/SUN/spfileSUN.ora スタンバイ ノード 2(hyperion の $ORACLE_HOME/dbs ディレクトリに initsun2.ora というファイルを作成します このファイルにも次の 1 行を含めます spfile= +DATA/SUN/spfileSUN.ora また Oracle RMAN が作成した spfile をスタンバイ ノード 1(dione の $ORACLE_HOME/dbs から削除します 第 2 制御ファイルの作成 Oracle RMAN 複製が完了した時点では スタンバイ データベースに作成された制御ファイルは 1 つだけです これはあまり適切ではないため 次のステップで追加の制御ファイルを作成します このプロセスには 2 段階の作業が含まれます 1. nomount を使用して データベースの停止と開始を実行します shutdown immediate;

22 startup nomount; 2. control_files パラメータの値を '+DATA', ' +FRA' に変更します alter system set control_files= +DATA, +FRA scope=spfile; 3. 再度 データベースの停止と開始を実行します shutdown immediate; startup nomount; 4. Oracle RMAN を使用して既存の制御ファイルを複製します export ORACLE_SID=SUN1 rman target / restore controlfile from +DATA/SUN/controlfile/control01.dbf これにより +DATA と +FRA の両方の ASM ディスク グループで制御ファイルが作成されます また spfile 内の制御ファイル パラメータも更新されます 制御ファイルを 3 つ用意したい場合には もとの制御ファイルと作成した制御ファイルを含めて制御ファイル パラメータを変更します スタンバイ データベースのクラスタ対応 次に スタンバイ データベースをクラスタウェアの管理下に置く つまり Oracle Cluster Ready Services に登録する必要があります 実行する前に 2 番目のスタンバイ ノード (hyperion 上のインスタンスが開始可能であることを確認します export ORACLE_SID=SUN2 sqlplus / as sysdba startup mount; 注 : 問題が発生している場合は解決してから次のステップへ進んでください サーバー側ロード バランシングの構成の確認 スタンバイ インスタンスで init.ora のパラメータ remote_listener が定義されていることを確認します パラメータが存在しない場合 ( すべてのスタンバイ ノード上の tnsnames.ora ファイルに次の形式のエントリを作成します LISTENERS_SUN.local = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP(HOST = dione-vip.local(port = 1521 (ADDRESS = (PROTOCOL = TCP(HOST = hyperion-vip.local(port = 1521

23 次に パラメータ remote_listener の値に LISTENERS_ SUN.local を設定します Oracle CRS へのデータベース登録 以下のコマンドを発行して Oracle Cluster Ready Services にデータベースを登録します srvctl add database -d SUN -o $ORACLE_HOME -m local -p +DATA/SUN/spfileSUN.ora -n MOON -r physical_standby -s mount srvctl add instance -d SUN -i SUN1 -n dione srvctl add instance -d SUN -i SUN2 -n hyperion テスト 実行中のスタンバイ インスタンスを停止してから 次のコマンドを使用してデータベース ( すべてのインスタンス を開始し 上記が正しく動作していることをテストします srvctl start database -d SUN データベースが開始されたら 次のコマンドを使用して関連インスタンスが実行中であることを確認します srvctl status database -d SUN 一時ファイル 一時表領域に関連付けられた一時ファイルは 自動的にスタンバイ データベースに作成されます スタンバイ REDO ログの作成 Logwriter(LGWR を使用した転送が設定されている場合 ( デフォルト プライマリ データベースからの REDO データを保存するためにスタンバイ REDO ログ (SRL が使用されます それぞれのスタンバイ REDO ログ ファイルのサイズは 少なくとも プライマリ データベースで最大の REDO ログ ファイルと同じサイズである必要があります プライマリ データベースのすべての REDO ログ ファイルと それぞれのスタンバイ データベースにおけるスタンバイ REDO ログを同じサイズにすることを推奨します 推奨される SRL 数は次のとおりです ( プライマリ インスタンスあたりのオンライン REDO ログ数 +1 インスタンス数 スタンバイ REDO ログが使用されるのはスタンバイ サイトでのみですが スタンバイ サイトと同様にプライマリ サイトでもこれらを定義することを推奨します こうすることで 2 つのデータベースのロールが切り替わった場合 ( プライマリ スタンバイ およびスタンバイ プライマリ にも追加の設定が不要になります かならずスタンバイ データベースをマウントしてから ( デフォルトで ' スタンバイ ' としてマウント SRL を作成してください 次のとおり SRL を作成します ( 以下に示したサイズは一例にすぎないため 環境に合わせて変更する必要があります 1. sqlplus / a sysdba 2. startup mount

24 3. alter database add standby logfile SIZE 100M; 注 : スタンバイ REDO ログは ログ ファイル グループにも作成されます ただし この場合グループ数をプライマリ データベースの ORL に関連付けられたグループ数よりも大きくする必要があることに注意してください Oracle は ORL と SRL 間でグループ数に違いを設けていません 注 : スタンバイ REDO ログは 両方のデータベース上で作成する必要があります ここまでで スタンバイ データベースが作成されました 次に トランザクションの同期化を有効にします 実行するには 2 つの方法があります 1. SQL Plus の使用 2. Oracle Data Guard Broker の使用 4.4 SQL Plus を使用した Oracle Data Guard の構成 はじめに ここでは SQL Plus を使用してフィジカル スタンバイ データベース環境を設定し データベースの初期化パラメータを手動で設定する手順について説明します スタンバイ データベースの構成 次に スタンバイ データベースに設定する初期化パラメータを示します パラメータ値 (dione 値 (hyperion db_unique_name SUN db_block_checking TRUE( オプション db_block_checksum TRUE( オプション log_archive_config dg_config=(moon, SUN log_archive_max_processes 5 fal_client SUN1.local SUN2.local fal_server Standby_file_management log_archive_dest_2 log_archive_dest_2 ( 最大パフォーマンス モード 'MOON1.local', 'MOON2.local' Auto service=moon LGWR SYNC AFFIRM db_unique_name=primary_moon VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE service=moon ARCH db_unique_name=primary_moon VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE

25 4.4.3 プライマリ データベースの構成 次に プライマリ データベースに設定する初期化パラメータを示します パラメータ値 (europa 値 (callisto db_unique_name MOON db_block_checking TRUE( オプション db_block_checksum TRUE( オプション log_archive_config dg_config=(moon, SUN log_archive_max_processes 5 fal_client MOON1.local MOON2.local fal_server standby_file_management Log_archive_dest_2 Log_archive_dest_2 ( 最大パフォーマンス モード 'SUN1.local', 'SUN2.local' Auto service=sun LGWR SYNC AFFIRM db_unique_name=sun VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE service=sun ARCH db_unique_name=sun VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE 保護モードの設定 保護モードを指定するには プライマリ データベースをマウント状態にする必要があります ただし オープン状態にはしません 注 : データベースは排他モードでマウントします これには 1 つをのぞいたすべての RAC インスタンスを停止し 残りのインスタンスに cluster_database=false というパラメータを設定して開始する必要があります 完了したら プライマリ サイトで次の文を実行します 最大保護モードを使用している場合 次のコマンドを使用します Alter database set standby database to maximize protection; 最大可用性モードを使用している場合 次のコマンドを使用します Alter database set standby database to maximize availability;

26 最大パフォーマンス モードを使用している場合 次のコマンドを使用します Alter database set standby database to maximize performance; REDO 転送と REDO Apply の有効化 REDO の転送および適用をスタンバイ データベースで有効にするには 以下にしたがいます スタンバイ サイト スタンバイ データベースを管理リカバリ モードに設定します 実行するには 次の文を発行します Alter database recover managed standby database disconnect; Oracle 10g Release 2 では リアルタイム REDO Apply が導入されました (SRL が必要 リアルタイム適用を有効にするには 次の文を発行します alter database recover managed standby database using current logfile disconnect; プライマリ サイト init.ora ファイルに次のパラメータを設定します log_archive_dest_state_2=enable または SQL Plus から次のコマンドを発行します alter system set log_archive_dest_state_2=enable 4.5 Oracle Data Guard Broker を使用した Oracle Data Guard の構成 はじめに Oracle Data Guard Broker が提供するコマンドライン インタフェースを利用すると Oracle Data Guard 環境全体の管理が容易になります Oracle Data Guard Broker を使用する場合 構成情報は Oracle Data Guard Broker 自体の内部に保管されます Oracle Data Guard Broker は開始されると ( データベース初期化パラメータにより有効化 一連の ALTER SYSTEM 文を使用してプライマリ サイトとスタンバイ サイト間のトランザクション同期化を設定します ここで設定されるパラメータは SQL Plus を使用した上述の例と同じです したがって データベース構成を変更するには 初期化パラメータを直接編集するのではなく Oracle Data Guard Broker を使用することが絶対に必要です このルールにしたがわない場合 Oracle Data Guard Broker によりパラメータ値が上書きされる結果となります 注 :Grid Control を使用して Oracle Data Guard 環境を管理するには Oracle Data Guard Broker を構成する必要があります

27 4.5.2 Oracle Data Guard Broker 構成ファイル Oracle Data Guard Broker は その構成情報を格納するために 2 つのファイルを使用します デフォルトでは これらのファイルは $ORACLE_HOME/dbs ディレクトリにあります Oracle RAC 環境では すべてのデータベース インスタンスが同じ構成情報にアクセスする必要があるため これは適切ではありません Oracle Data Guard Broker の構成を続ける前に Oracle Data Guard Broker ファイルが共有ストレージを指していることを確認してください ( この場合は Oracle ASM 確認するには 次のパラメータ値を参照します dg_broker_config_file1 および dg_broker_config_file2 これらのパラメータに適切な値を確認するには 上述の項 ( を参照してください Oracle Data Guard Broker の有効化 Oracle Data Guard Broker を開始する前に まず有効化する必要があります 実行するには データベース初期化パラメータ dg_broker_start の値を true に変更します alter system set dg_broker_start=true; 注 : この処理は プライマリ データベースとスタンバイ データベースの両方でおこなう必要があります Oracle Data Guard Broker 構成の作成 Oracle Data Guard Broker 構成を作成するには Grid Control を使用する方法と DGMGRL コマンドライン インタフェースを使用する方法があります ここでは 後者を使用します 次のコマンドを使用して dgmgrl を開始します dgmgrl sys/mypasswd ** 注 :"/" を単体で使用しないでください あとで問題が発生する可能性があります 次のコマンドを入力して Oracle Data Guard 構成を作成します create configuration MOON_SUN as primary database is MOON connect identifier is MOON.local; add database SUN as connect identifier is SUN.local maintained as physical; Oracle Data Guard Broker 構成の有効化 Oracle Data Guard Broker 構成を作成したら これを使用する前に有効化する必要があります 実行するには 次のコマンドを使用します enable configuration;

28 このコマンドは 完了するまでにいくらか時間がかかります 完了したら 次のコマンドを発行します show configuration; 正しく実行されている場合 メッセージ SUCCESS が表示されます そうでない場合 次のログ ファイルを確認し 問題が発生している場合は解決する必要があります $ORACLE_BASE/diag/rdbms/<db_name>/<instance_name>/trace/ drcinstance_name.log また 次のコマンドも役立ちます show database verbose DB_NAME 注 : このファイルはすべてのノードに存在します 注 :<db_name> を DB_UNIQUE_NAME の値で置換してください 注 :<instance_name> を ORACLE_SID の値で置換してください 注 : 構成が有効化されるまで セカンダリ インスタンスは表示されません Oracle Data Guard Broker のカスタマイズ ここまでで 基本的な構成は終了しました スタンバイ データベースが開始されたら 上述のとおり Oracle Data Guard Broker によりスタンバイ データベースは自動的に管理リカバリ モードに設定されます しかし この基本的な構成は環境全体を維持するには十分ではありません これには追加のカスタマイズが必要であり 実行するには Oracle Data Guard プロパティを設定します 次に 定義する必要のあるプロパティを示します dgmgrl sys/mypasswd edit database MOON set property LogArchiveMaxProcesses=5; edit database SUN set property LogArchiveMaxProcesses=5; edit database MOON set property StandbyFileManagement=auto; edit database SUN set property StandbyFileManagement=auto; 最大可用性 / 保護モード 最大可用性モードまたは最大保護モードを使用している場合 さらに次の値を設定する必要があります edit database MOON set property LogXptMode= SYNC ; edit database SUN set property LogXptMode= SYNC ; edit configuration set protection mode as maxavailability maxprotection;

29 5 監視 はじめに 構成を作成したら すべてが順調に実行されていることを確認することが重要です 次の項では 環境を監視するさまざまな方法について説明します ログ ファイル アーカイブ処理が発生すると アラート ログにこの情報が記入されます プライマリでログが切り替わるたびに これがアラート ログに登録されます スタンバイ データベースでアーカイブ ログ適用が実行されると スタンバイ インスタンスのアラート ログに登録されます 固定ビュー 次に Oracle Data Guard Broker を監視するために使用できる固定ビューを示します プライマリ サイト V$ARCHIVE_DEST V$ARCHIVE_DEST_STATUS V$ARCHIVED_LOG V$DATABASE V$LOG 現在のインスタンスの全アーカイブ REDO ログ出力先 現在の値 モード ステータスを表示する アーカイブ REDO ログ出力先の実行時情報と構成情報を表示する 制御ファイルからのアーカイブ REDO ログ情報を表示する アーカイブ ログ名を含む 制御ファイルからのデータベース情報を提供する データベースのステータスを含む オンライン REDO ログからのログ ファイル情報を含む スタンバイ サイト V$ARCHIVED_LOG V$DATABASE V$LOGFILE V$MANAGED_DATAGUARD V$DATAGUARD_LOG 制御ファイルからのアーカイブ REDO ログ情報を表示する アーカイブ ログ名を含む 制御ファイルからのデータベース情報を提供する データベース ステータスを含む オンライン / スタンバイ REDO ログに関する情報を含む Oracle Data Guard に関連する Oracle データベース サーバー プロセスの最新情報とステータス情報を表示する オンライン / スタンバイ REDO ログに関する情報を表示する

30 6 管理 6.1 スイッチオーバー プライマリ サーバーのメンテナンスなどの計画停止により プライマリ サイトが使用不能になる場合があります このような場合 スタンバイ サイトへ一時的にスイッチオーバーすることが得策です この手順は非破壊的であるため プライマリ サイトが使用可能になると どちらのデータベースも再構築することなく もとに戻すことができます SQL Plus を使用したスイッチオーバー データベースが引き受けるロールに対してそれぞれ正しく構成されており スタンバイ データベースがマウント状態にあることを確認します RAC プライマリからのスイッチオーバーを実行する前に 1 つをのぞいたすべてのプライマリ インスタンスを停止します ( スイッチオーバーが完了したら再開可能 RAC スタンバイへのスイッチオーバーまたはフェイルオーバーを実行する前に 1 つをのぞいたすべてのスタンバイ インスタンスを停止します ( ロール移行が完了したら再開可能 次の SQL 文を発行すると スタンバイへのスイッチオーバーが実行されます ( 注 : リカバリが必要な場合 項 7.1 にある REDO ログ変更の適用手順にしたがってください プライマリ データベースで スイッチオーバーを開始します alter database commit to switchover to physical standby [with session shutdown]; 注 : プライマリへの接続が存在する場合 'with sessin shutdown' 句を使用してください 新しいスタンバイ データベースを再起動してマウントします ( 古い スタンバイ データベースで 新しいプライマリ ロールへの切替えをおこないます alter database commit to switchover to primary; 新しいプライマリ データベースを再起動してオープンします 新しいスタンバイ データベースで REDO Apply を開始します alter database recover managed standby database [using current logfile] disconnect; 注 : 一般的に 長期間にわたってプライマリ サイトが使用不能になる場合は log_archive_dest_state_2 を 'defer' に設定することを推奨します Oracle Data Guard Broker を使用したスイッチオーバー ここでは Oracle Data Guard Broker のコマンドライン インタフェースに次のコマンドを入力することで スタンバイ データベースへのスイッチオーバーを実行します (Grid Control を使用することもできます

31 dgmgrl sys/mypasswd switchover to SUN; **<SUN> をスイッチオーバー先のデータベース名で置き換えます 注 : 長期間にわたってプライマリ サイトが使用不能になる場合は データベースを無効化してください disable database MOON; 6.2 フェイルオーバー SQL Plus を使用したフェイルオーバー 障害によりプライマリ データベースが使用不能になった場合 スタンバイ サイトへのフェイルオーバーが必要になります スタンバイ データベースを通常処理用にオープンする前に 完了していないすべての変更をデータベースに適用する必要があります 実行するには 次の手順にしたがいます 次のコマンドを実行して 管理リカバリ モードを終了します alter database recover managed standby database finish; スタンバイ データベースをプライマリ ロールに切り替え 通常モードでオープンします alter database commit to switchover to primary; alter database open; Oracle Data Guard Broker を使用したフェイルオーバー同じ処理を Oracle Data Guard Broker から実行できます 次のコマンドを使用します dgmgrl sys/mypasswd failover to SUN; 6.3 強制フェイルオーバー 場合によって 標準フェイルオーバーを実行できないことがあります このような場合 強制フェイルオーバーを実行できます 強制フェイルオーバーは破壊的であるため 一度起動すると 残っているスタンバイ データベースがあってもこれを再構築する必要があります SRL を使用する場合 次のコマンドを実行します alter database recover managed standby database finish force; 次に 以下のコマンドを実行します alter database activate standby database [skip standby logfile];

32 shutdown immediate; startup mount; alter database open resetlogs; Oracle Data Guard Broker を使用した強制フェイルオーバー同じ処理を Oracle Data Guard Broker からも実行できます dgmgrl sys/mypasswd failover to SUN immediate; 6.4 スタンバイ データベースの読取り専用オープン レポートやデータ チェックを実行するために スタンバイ データベースを読取り専用モードでオープンできます 実行するには 以下の手順にしたがいます 1. 管理リカバリを停止します alter database recover managed standby database cancel; 2. データベースをオープンします alter database open read only; または スタンバイ データベースで ' 通常 ' 起動を実行するとデータベースが読取り専用モードでオープンされます 注 : 読取り専用モードでオープンしている間 変更は受信されますがスタンバイ データベースへ適用されません 6.5 リアルタイム適用 / リアルタイム問合せ Oracle 11g では Oracle Data Guard を読取り専用でオープンしながら REDO 変更を適用する機能が導入されました この機能は リアルタイム適用 / リアルタイム問合せと呼ばれています 有効化するには SQL Plus を使用して次の手順にしたがいます 1. スタンバイ データベースに接続します sqlplus / as sysdba 2. 管理リカバリを取り消します alter database recover managed standby database cancel; 3. データベースをオープンします alter database open; 4. 管理リカバリを再開します alter database recover managed standby database disconnect;

33 7 付録 A - Oracle RMAN を使用したスタンバイ データベースの作成 ( 従来の方法 Oracle Database 11g 以前では スタンバイ データベースの " オンザフライ " 作成を実行できませんでした 以下の方法は広く使用されてきたものであり 必要に応じて 11g で使用することもできます 7.1 前提条件 このプロセスをより複雑で柔軟なものにすることもできますが ここでは以下の条件を前提としています スタンバイ データベースとプライマリ データベースの構造が一致する リカバリ カタログが存在する 注 : ここで説明するスタンバイ データベースの設定方法では リカバリ カタログを使用しません 注 : 通常 実行中の Oracle Data Guard 環境で Oracle RMAN を使用するにはリカバリ カタログが必要です 7.2 Oracle RMAN のバックアップ スタンバイ データベースの作成に適した Oracle RMAN のバックアップを作成する方法には 次の 2 種類があります 新規バックアップ Oracle RMAN を使用する前に一度もバックアップを取得していないデータベースの場合 バックアップを作成する必要があります プライマリ サイトから 次を実行します rman target / Run { allocate channel d1 device type disk format /backup/%u ; allocate channel d2 device type disk format /backup/%u ; sql alter system switch logfile backup database include current controlfile for standby plus archivelog; } Oracle RAC を実装している場合 次を実行します Run { allocate channel d1 device type disk format /backup/%u ; allocate channel d2 device type disk format /backup/%u ; sql alter system archive log current backup database include current controlfile for standby; sql alter system archive log current ; backup archivelog all; }

34 7.2.2 既存バックアップ データベースのバックアップを以前に作成済みである場合 以下を実行して スタンバイ制御ファイルを作成する必要があります rman target / run { allocate channel d1 device type disk format /backup/%u ; allocate channel d2 device type disk format /backup/%u ; backup current controlfile for standby; sql alter system archive log current; backup archive log all not backed up 1 times; } 7.3 スタンバイ データベースの作成 前提条件スタンバイ データベースを構築する前に 以下について確認します Oracle 実行ファイルがスタンバイ マシンにインストールされている データベースのディレクトリ構造がスタンバイ マシン上に存在する スタンバイ マシンでリスナーが開始されている スタンバイ データベースがリスナーに静的登録されている プライマリ上に スタンバイ データベースを指す tnsnames.ora エントリが存在する プライマリの初期化パラメータ ファイルがスタンバイ ホストから使用可能である remote_password_file が none に設定されている スタンバイ インスタンスに外部パスワード ファイルが作成されている RMAN バックアップ セットがスタンバイ ホストで使用可能である 手順 1. スタンバイ データベース インスタンスを開始します startup nomount pfile=init.ora 2. Oracle RMAN へ接続します ( プライマリ サイト上 rman target / auxiliary sys/syspwd@<standby_alias> 3. スタンバイ データベースを作成します duplicate target database for standby dorecover [nofilenamecheck];

35 ここまでで スタンバイ データベースが作成されました 注 : スタンバイ データベースの運用を開始する前にリカバリを実行する必要はありません REDO ログのギャップ解消機能により 管理リカバリの開始時に同期化されるためです このため dorecover オプションを使用することはあまりありません

36 8 付録 B - 参考資料 8.1 Oracle マニュアル Oracle Clusterwareインストール ガイド 11g リリース 1 for Linux 2007 年 10 月 Oracle Real Application Clustersインストール ガイド 11g リリース 1 for Linux 2007 年 9 月 Oracle Data Guard 概要および管理 11g リリース 年 9 月 Oracle Data Guard Broker 11g リリース 年 9 月 Oracle Databaseバックアップおよびリカバリ ユーザー ガイド 11g リリース 年 9 月 Oracle Databaseバックアップおよびリカバリ リファレンス 11g リリース 年 9 月 8.2 Metalink Note Data Guard Support for Heterogeneous Primary and Standby Systems in Same Data Guard Configuration 1 MetaLink Note の参照には MetaLink アカウントが必要です (

37 Oracle Data Guard 11g Oracle RAC システムでのインストールと構成 2008 年 6 月著者 :Michael Rhys オラクル共著者 :Holger Kalinowski オラクル Oracle USA, Inc. World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問い合わせ窓口 : 電話 : ファクシミリ : Copyright 2008, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は一切間違いがないことを保証するものではなく さらに 口述による明示または法律による黙示を問わず 特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み いかなる他の保証や条件も提供するものではありません オラクル社は本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクル社の書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracle JD Edwards PeopleSoft および Siebel は 米国 Oracle Corporation およびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です