Oracle Data Guard 概要および管理, 10gリリース2（10.2）

Transcription

1 Oracle Data Guard 概要および管理 10g リリース 2(10.2) 部品番号 : B 年 10 月

2 Oracle Data Guard 概要および管理, 10g リリース 2(10.2) 部品番号 : B Oracle Data Guard Concepts and Administration, 10g Release 2 (10.2) 原本部品番号 : B 原本著者 : Vivian Schupmann 原本協力者 : Andy Adams, Beldalker Anand, Rick Anderson, Andrew Babb, Pam Bantis, Tammy Bednar, Barbara Benton, Chipper Brown, Larry Carpenter, George Claborn, Laurence Clarke, Jay Davison, Jeff Detjen, Ray Dutcher, B.G. Garin, Mahesh Girkar, Yosuke Goto, Ray Guzman, Susan Hillson, Mark Johnson, Rajeev Jain, Joydip Kundu, J. William Lee, Steve Lee, Steve Lim, Nitin Karkhanis, Steve McGee, Bob McGuirk, Joe Meeks, Steve Moriarty, Muthu Olagappan, Deborah Owens, Ashish Ray, Antonio Romero, Mike Schloss, Mike Smith, Vinay Srihali, Morris Tao, Lawrence To, Doug Utzig, Ric Van Dyke, Doug Voss, Ron Weiss, Jingming Zhang Copyright 1999, 2008, Oracle. All rights reserved. 制限付権利の説明 このプログラム ( ソフトウェアおよびドキュメントを含む ) には オラクル社およびその関連会社に所有権のある情報が含まれています このプログラムの使用または開示は オラクル社およびその関連会社との契約に記された制約条件に従うものとします 著作権 特許権およびその他の知的財産権と工業所有権に関する法律により保護されています 独立して作成された他のソフトウェアとの互換性を得るために必要な場合 もしくは法律によって規定される場合を除き このプログラムのリバース エンジニアリング 逆アセンブル 逆コンパイル等は禁止されています このドキュメントの情報は 予告なしに変更される場合があります オラクル社およびその関連会社は このドキュメントに誤りが無いことの保証は致し兼ねます これらのプログラムのライセンス契約で許諾されている場合を除き プログラムを形式 手段 ( 電子的または機械的 ) 目的に関係なく 複製または転用することはできません このプログラムが米国政府機関 もしくは米国政府機関に代わってこのプログラムをライセンスまたは使用する者に提供される場合は 次の注意が適用されます U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR , Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA このプログラムは 核 航空 大量輸送 医療あるいはその他の本質的に危険を伴うアプリケーションで使用されることを意図しておりません このプログラムをかかる目的で使用する際 上述のアプリケーションを安全に使用するために 適切な安全装置 バックアップ 冗長性 (redundancy) その他の対策を講じることは使用者の責任となります 万一かかるプログラムの使用に起因して損害が発生いたしましても オラクル社およびその関連会社は一切責任を負いかねます Oracle JD Edwards PeopleSoft Siebel は米国 Oracle Corporation およびその子会社 関連会社の登録商標です その他の名称は 他社の商標の可能性があります このプログラムは 第三者の Web サイトへリンクし 第三者のコンテンツ 製品 サービスへアクセスすることがあります オラクル社およびその関連会社は第三者の Web サイトで提供されるコンテンツについては 一切の責任を負いかねます 当該コンテンツの利用は お客様の責任になります 第三者の製品またはサービスを購入する場合は 第三者と直接の取引となります オラクル社およびその関連会社は 第三者の製品およびサービスの品質 契約の履行 ( 製品またはサービスの提供 保証義務を含む ) に関しては責任を負いかねます また 第三者との取引により損失や損害が発生いたしましても オラクル社およびその関連会社は一切の責任を負いかねます

3 目次 はじめに はじめに... xix 対象読者... ドキュメントのアクセシビリティについて... 関連ドキュメント... 表記規則... サポートおよびサービス... xx xx xx xxi xxi Oracle Data Guard の新機能 の新機能... xxiii 第 I 部 概要および管理 1 Oracle Data Guard の概要 1.1 Data Guard 構成 プライマリ データベース スタンバイ データベース 構成例 Data Guard サービス REDO 転送サービス ログ適用サービス ロールの推移 Data Guard Broker Oracle Enterprise Manager の使用 Data Guard コマンドライン インタフェースの使用 Data Guard 保護モード Data Guard と補完テクノロジ Data Guard のメリットの要約 Data Guard スタート ガイド 2.1 スタンバイ データベースのタイプ フィジカル スタンバイ データベース ロジカル スタンバイ データベース Data Guard 構成の管理のためのユーザー インタフェース i

4 2.3 Data Guard の動作要件 ハードウェアおよびオペレーティング システムの要件 Oracle ソフトウェア要件 スタンバイ データベースのディレクトリ構造に関する考慮事項 オンライン REDO ログ アーカイブ REDO ログおよびスタンバイ REDO ログ オンライン REDO ログおよびアーカイブ REDO ログ スタンバイ REDO ログ フィジカル スタンバイ データベースの作成 3.1 スタンバイ データベースを作成するためのプライマリ データベースの準備 強制ロギングの有効化 パスワード ファイルの作成 スタンバイ REDO ログの構成 プライマリ データベースの初期化パラメータの設定 アーカイブの有効化 フィジカル スタンバイ データベースの作成手順 プライマリ データベース データファイルのバックアップ コピーの作成 スタンバイ データベース用の制御ファイルの作成 スタンバイ データベース用の初期化パラメータ ファイルの準備 プライマリ システムからスタンバイ システムへのファイルのコピー スタンバイ データベースをサポートする環境の設定 フィジカル スタンバイ データベースの起動 フィジカル スタンバイ データベースが正しく実行されているかどうかの確認 作成後の手順 ロジカル スタンバイ データベースの作成 4.1 ロジカル スタンバイ データベースの作成要件 表のデータ型および記憶域属性のサポートの判別 プライマリ データベース内の表の行が一意に識別できることの確認 ロジカル スタンバイ データベースの作成手順 フィジカル スタンバイ データベースの作成 フィジカル スタンバイ データベースでの REDO Apply の停止 ロジカル スタンバイ データベースをサポートするためのプライマリ データベースの 準備 ロールの推移のためのプライマリ データベースの準備 REDO データでのディクショナリの構築 ロジカル スタンバイ データベースへの推移 ロジカル スタンバイ データベースへの変換 新規パスワード ファイルの作成 ロジカル スタンバイ データベース用の初期化パラメータの調整 ロジカル スタンバイ データベースのオープン ロジカル スタンバイ データベースが正しく実行されているかどうかの確認 作成後の手順 ii

5 5 REDO 転送サービス 5.1 REDO 転送サービスの概要 REDO データの送信先 宛先タイプ LOG_ARCHIVE_DEST_n パラメータを使用した宛先の構成 宛先属性の変更 V$ARCHIVE_DEST ビューを使用した属性の表示 フラッシュ リカバリ領域の設定 LOG_ARCHIVE_DEST_10 の宛先の使用 他の LOG_ARCHIVE_DEST_n の宛先の使用 STANDBY_ARCHIVE_DEST の宛先の使用 プライマリ データベースとスタンバイ データベースでフラッシュ リカバリ領域 を共有する REDO データの送信方法 アーカイバ プロセス (ARCn) を使用した REDO データのアーカイブ ARCn のアーカイブ動作を制御する初期化パラメータ ARCn のアーカイブ処理 ログ ライター プロセス (LGWR) を使用した REDO データのアーカイブ LGWR アーカイブ プロセスに関する LOG_ARCHIVE_DEST_n 属性 LGWR SYNC アーカイブ プロセス LGWR ASYNC アーカイブ プロセス セキュアな REDO データの転送の提供 REDO データの送信時間 VALID_FOR 属性を使用したロール ベースの宛先の指定 一意のプライマリ データベース名とスタンバイ データベース名の指定 エラーが発生した場合の対処方法 アーカイブ操作の再試行 代替アーカイブ先の使用 再試行回数の制御 データ保護モードの設定 データ保護モードの選択 最大保護モード 最大可用性モード 最大パフォーマンス モード Data Guard 構成のデータ保護モードの設定 ログ ファイルの管理 アーカイブ REDO ログ ファイルの代替ディレクトリ位置の指定 オンライン REDO ログ ファイルの再利用 スタンバイ REDO ログ ファイルの管理 スタンバイ REDO ログ ファイル グループの構成が適切であるかの判断 スタンバイ REDO ログ メンバーを既存のグループに追加 制御ファイルのサイズ拡大と再利用の計画 制御ファイルを含むディスク ボリュームのサイズ設定 制御ファイル内のレコードの再利用の指定 複数のスタンバイ データベース間でのログ ファイル宛先の共有 iii

6 5.8 アーカイブ ギャップの管理 アーカイブ ギャップの検出時期 ギャップの解決方法 フェッチ アーカイブ ログ (FAL) を使用したアーカイブ ギャップの解決 手動によるアーカイブ ギャップの判断および解決 確認 ログ ファイル アーカイブ情報の監視 REDO 転送サービスのパフォーマンスの監視 ARCn プロセスの待機イベント LGWR SYNC 待機イベント LGWR ASYNC 待機イベント ログ適用サービス 6.1 ログ適用サービスの概要 ログ適用サービスの構成オプション リアルタイム適用による REDO データの即時適用 アーカイブ REDO ログ ファイルの適用に対するタイム ディレイの指定 タイム ディレイ設定の代替策としてのフラッシュバック データベースの使用 REDO データのフィジカル スタンバイ データベースへの適用 REDO Apply の開始 リアルタイム適用の開始 ログ適用サービスの停止 フィジカル スタンバイ データベースでのログ適用サービスの監視 REDO データのロジカル スタンバイ データベースへの適用 SQL Apply の開始 リアルタイム適用の開始 ロジカル スタンバイ データベースでのログ適用サービスの停止 ロジカル スタンバイ データベースでのログ適用サービスの監視 ロールの推移 7.1 ロールの推移の概要 ロールの推移 ( フェイルオーバーまたはスイッチオーバー ) の準備 ロールの推移のターゲット スタンバイ データベースの選択 スイッチオーバー フェイルオーバー フィジカル スタンバイ データベースが関与するロールの推移 フィジカル スタンバイ データベースが関与するスイッチオーバー フィジカル スタンバイ データベースが関与するフェイルオーバー ロジカル スタンバイ データベースが関与するロールの推移 ロジカル スタンバイ データベースが関与するスイッチオーバー ロジカル スタンバイ データベースが関与するフェイルオーバー ロールの推移後のフラッシュバック データベースの使用 スイッチオーバー後のフラッシュバック データベースの使用 フェイルオーバー後のフラッシュバック データベースの使用 iv

7 8 フィジカル スタンバイ データベースの管理 8.1 フィジカル スタンバイ データベースの起動と停止 フィジカル スタンバイ データベースの起動 フィジカル スタンバイ データベースの停止 スタンバイ データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法 スタンバイ データベースをオープンするかどうかの評価 読取り専用アクセス用にフィジカル スタンバイ データベースをオープン スタンバイ データベースに影響を与えるプライマリ データベース イベントの管理 データファイルの追加または表領域の作成 STANDBY_FILE_MANAGEMENT が AUTO に設定されている場合 STANDBY_FILE_MANAGEMENT が MANUAL に設定されている場合 表領域の削除とデータファイルの削除 STANDBY_FILE_MANAGEMENT が AUTO または MANUAL に設定されている 場合 DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES の使用 フィジカル スタンバイ データベースでのトランスポータブル表領域の使用 プライマリ データベースのデータファイルの改名 オンライン REDO ログ ファイルの追加または削除 ログに記録されていないまたはリカバリ不能な操作 OPEN RESETLOGS 文を使用したリカバリ プライマリおよびスタンバイ データベースの監視 アラート ログ 動的パフォーマンス ビュー ( 固定ビュー ) リカバリの進捗の監視 プロセス アクティビティの監視 REDO Apply の進捗の確認 アーカイブ REDO ログ ファイルの位置および作成者の確認 OPEN RESETLOGS の前後のデータベース インカネーションの表示 アーカイブ REDO ログ履歴の表示 スタンバイ データベースに適用されたログ ファイルの確認 スタンバイ サイトが受信しなかったログ ファイルの確認 フィジカル スタンバイ データベースでのログ適用サービスの監視 V$DATABASE ビューへのアクセス V$MANAGED_STANDBY 固定ビューへのアクセス V$ARCHIVE_DEST_STATUS 固定ビューへのアクセス V$ARCHIVED_LOG 固定ビューへのアクセス V$LOG_HISTORY 固定ビューへのアクセス V$DATAGUARD_STATUS 固定ビューへのアクセス フィジカル スタンバイ データベースに関するログ適用レートのチューニング ロジカル スタンバイ データベースの管理 9.1 SQL Apply アーキテクチャの概要 SQL Apply に関する各種の考慮事項 トランザクション サイズの考慮事項 ページアウトの考慮事項 再開の考慮事項 DML 適用の考慮事項 DDL 適用の考慮事項 v

8 9.2 ロジカル スタンバイ データベースの管理および監視関連のビュー DBA_LOGSTDBY_EVENTS ビュー DBA_LOGSTDBY_LOG ビュー V$LOGSTDBY_STATS ビュー V$LOGSTDBY_PROCESS ビュー V$LOGSTDBY_PROGRESS ビュー V$LOGSTDBY_STATE ビュー V$LOGSTDBY_STATS ビュー ロジカル スタンバイ データベースの監視 SQL Apply の進捗の監視 ログ ファイルの自動削除 ロジカル スタンバイ データベースのカスタマイズ ロジカル スタンバイ データベースでのリアルタイム適用の使用 DBA_LOGSTDBY_EVENTS ビューでのイベントのロギングのカスタマイズ DBMS_LOGSTDBY.SKIP による特定のスキーマ オブジェクトに対する変更の防止 DDL 文のスキップ ハンドラの設定 ロジカル スタンバイ データベースの変更 ロジカル スタンバイ データベースでの DDL の実行 SQL Apply でメンテナンスされていない表の変更 ロジカル スタンバイ データベースでの表の追加または再作成 ロジカル スタンバイ データベースのコンテキストにおける特定のワークロードの管理 プライマリ データベースへのトランスポータブル表領域のインポート マテリアライズド ビューの使用 ロジカル スタンバイ データベースでのトリガーと制約の処理方法 OPEN RESETLOGS 文を使用したリカバリ ロジカル スタンバイ データベースのチューニング 主キー RELY 制約の作成 コストベース オプティマイザの統計の収集 プロセス数の調整 APPLIER プロセス数の調整 PREPARER プロセス数の調整 LCR キャッシュ用メモリーの調整 ロジカル スタンバイ データベースにおけるトランザクションの適用方法の調整 Recovery Manager を使用したファイルのバックアップおよびリストア 10.1 バックアップ処理 テープ バックアップ用キャッシュとしてのディスクの使用 テープへの直接バックアップの実行 スイッチオーバー フェイルオーバーおよび制御ファイル作成がバックアップに与える影響 プライマリ データベースのデータファイル消失からのリカバリ スタンバイ データベースのデータファイル消失からのリカバリ スタンバイ制御ファイルの消失からのリカバリ プライマリ制御ファイルの消失からのリカバリ オンライン REDO ログ ファイルの消失からのリカバリ データベースの不完全リカバリ vi

9 10.3 その他のバックアップ状況 スタンバイ データベースが地理的に離れすぎているためにバックアップを共有できない 場合 FAL サーバーとして使用されるスタンバイ データベースにデータファイルが含まれて いない場合 スタンバイ データベースのファイル名がプライマリ データベースとは異なる場合 フラッシュ リカバリ領域のアーカイブ REDO ログ ファイルに関する削除ポリシー ロールが推移した後の削除ポリシーの再構成 現行の削除ポリシーの表示 SQL Apply を使用した Oracle Database のアップグレード 11.1 SQL Apply を使用するローリング アップグレードのメリット SQL Apply を使用してローリング アップグレードを実行するための要件 アップグレード手順に使用する図と表記規則 アップグレードの準備 データベースのアップグレード Data Guard の使用例 12.1 アーカイブ先の設定および確認 プライマリ データベースおよびフィジカル スタンバイ データベースの構成 プライマリ データベースおよびロジカル スタンバイ データベースの構成 フィジカルおよびロジカル スタンバイ データベースの構成 各宛先について現行の VALID_FOR 属性設定の確認 ロールの推移に最適なスタンバイ データベースの選択 例 : フェイルオーバーに最適なフィジカル スタンバイ データベース 例 : フェイルオーバーに最適なロジカル スタンバイ データベース 新規プライマリ データベースをサポートするロジカル スタンバイ データベースの構成 新規プライマリ データベースがフィジカル スタンバイ データベースだった場合 新規プライマリ データベースがロジカル スタンバイ データベースだった場合 フェイルオーバー後のフラッシュバック データベースの使用 障害が発生したプライマリ データベースのフィジカル スタンバイ データベースへの フラッシュバック 障害が発生したプライマリ データベースのロジカル スタンバイ データベースへの フラッシュバック 特定の適用済 SCN へのロジカル スタンバイ データベースのフラッシュバック Open Resetlogs 文の発行後のフラッシュバック データベースの使用 特定時点へのフィジカル スタンバイ データベースのフラッシュバック プライマリのフラッシュバック後のロジカル スタンバイ データベースの フラッシュバック フィジカル スタンバイ データベースを使用した読取り / 書込みテストとレポート生成 Recovery Manager の増分バックアップによるフィジカル スタンバイ データベースの ロールフォワード フィジカル スタンバイ データベースがプライマリ データベースから大幅に遅れて いる場合 フィジカル スタンバイ データベースのデータファイルのサブセットにロギングなしの 変更がある場合 フィジカル スタンバイ データベースの広範囲にロギングなしの変更がある場合 vii

10 12.8 タイム ラグのあるフィジカル スタンバイ データベースの使用 フィジカル スタンバイ データベースでのタイム ラグの設定 タイム ラグのあるフィジカル スタンバイ データベースへのフェイルオーバー タイム ラグのあるフィジカル スタンバイ データベースへのスイッチオーバー ネットワーク障害のリカバリ NOLOGGING 句を指定した後のリカバリ ロジカル スタンバイ データベースのリカバリ手順 フィジカル スタンバイ データベースのリカバリ手順 リカバリ不能処理後にバックアップが必要かどうかの判断 手動によるアーカイブ ギャップの解決 アーカイブ ギャップの発生原因 スタンバイ データベースの作成 プライマリ データベースがオープンしている間のスタンバイ データベースの 停止 REDO の転送を妨げるネットワーク障害 アーカイブ ギャップが存在するかどうかの判断 スタンバイ サイトへのアーカイブ ギャップ ログ ファイルの手動による転送 スタンバイ データベースへのアーカイブ ギャップ ログ ファイルの手動による 適用 OMF または ASM を使用するスタンバイ データベースの作成 第 II 部 参照先 13 初期化パラメータ 14 LOG_ARCHIVE_DEST_n パラメータの属性 AFFIRM および NOAFFIRM ALTERNATE ARCH および LGWR DB_UNIQUE_NAME DELAY DEPENDENCY LOCATION および SERVICE MANDATORY および OPTIONAL MAX_CONNECTIONS MAX_FAILURE NET_TIMEOUT NOREGISTER REOPEN SYNC および ASYNC TEMPLATE VALID_FOR VERIFY viii

11 15 Data Guard に関連する SQL 文 15.1 ALTER DATABASE 文 ALTER SESSION 文 Oracle Data Guard に関連するビュー 第 III 部 付録 A Data Guard のトラブルシューティング A.1 一般的な問題... A-2 A.1.1 スタンバイ アーカイブ宛先が適切に定義されていない... A-2 A.1.2 ALTER DATABASE 文によるデータファイル名の変更... A-2 A.1.3 スタンバイ データベースがプライマリ データベースから REDO データを受信しない... A-3 A.1.4 フィジカル スタンバイ データベースをマウントできない... A-3 A.2 ログ ファイル宛先の障害... A-4 A.3 ロジカル スタンバイ データベース障害の処理... A-4 A.4 スタンバイ データベースへのスイッチオーバーの問題... A-5 A.4.1 REDO データが転送されていないためスイッチオーバーできない... A-5 A.4.2 SQL セッションがアクティブなためスイッチオーバーできない... A-5 A.4.3 ユーザー セッションがアクティブなためスイッチオーバーできない... A-7 A.4.4 ORA エラーによりスイッチオーバーできない... A-7 A.4.5 スイッチオーバー後に REDO データが適用されない... A-8 A.4.6 失敗したスイッチオーバーをロールバックして最初からやり直す... A-8 A.5 SQL Apply が停止した場合の処置... A-9 A.6 REDO データ転送のネットワーク調整... A-10 A.7 スタンバイ データベースのディスクのパフォーマンスが遅い... A-10 A.8 プライマリ データベースの停止を回避するにはログ ファイルを一致させる必要がある... A-10 A.9 ロジカル スタンバイ データベースのトラブルシューティング... A-11 A.9.1 エラーのリカバリ... A-11 A ファイル仕様が含まれている DDL トランザクション... A-11 A DML 障害のリカバリ... A-12 A.9.2 SQL*Loader セッションのトラブルシューティング... A-13 A.9.3 長時間実行トランザクションのトラブルシューティング... A-14 A.9.4 フラッシュバック トランザクションでの ORA-1403 エラーのトラブルシューティング... A-17 B Data Guard 構成におけるデータベースのアップグレード B.1 Oracle Database ソフトウェアをアップグレードする前の注意事項... B-2 B.2 フィジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード... B-2 B.3 ロジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード... B-5 ix

12 C ロジカル スタンバイ データベースでサポートされるデータ型および DDL C.1 データ型に関する考慮事項... C-2 C.1.1 ロジカル スタンバイ データベースでサポートされるデータ型... C-2 C.1.2 ロジカル スタンバイ データベースでサポートされないデータ型... C-2 C.2 記憶域型に関する考慮事項... C-3 C.2.1 サポートされる記憶域型... C-3 C.2.2 サポートされない記憶域型... C-3 C.3 PL/SQL パッケージに関する考慮事項... C-3 C.3.1 サポートされる PL/SQL パッケージ... C-3 C.3.2 サポートされない PL/SQL パッケージ... C-3 C.4 サポートされない表 順序およびビュー... C-4 C.5 ロジカル スタンバイ データベースでスキップされる SQL 文... C-5 C.6 ロジカル スタンバイ データベースでサポートされる DDL 文... C-5 D Data Guard および Real Application Clusters D.1 Real Application Clusters 環境でのスタンバイ データベースの構成... D-2 D.1.1 複数インスタンス プライマリ データベースと単一インスタンス スタンバイ データベースの設定... D-2 D.1.2 複数インスタンス プライマリ データベースと複数インスタンス スタンバイ データベースの設定... D-3 D.2 Real Application Clusters 環境での構成に関する考慮事項... D-5 D.2.1 アーカイブ REDO ログ ファイル名の形式... D-5 D.2.2 アーカイブ先の割当て制限... D-5 D.2.3 データ保護モード... D-6 D.2.4 ロールの推移... D-6 D スイッチオーバー... D-6 D フェイルオーバー... D-6 D.3 トラブルシューティング... D-7 D.3.1 Real Application Clusters 構成でスイッチオーバーできない... D-7 D.3.2 ネットワーク停止時に Real Application Clusters の停止時間を回避する... D-7 E カスケードされた宛先 E.1 カスケードされた宛先の構成... E-3 E.1.1 フィジカル スタンバイ データベースに対するカスケードされた宛先の構成... E-3 E.1.2 ロジカル スタンバイ データベースに対するカスケードされた宛先の構成... E-4 E.2 カスケードされた宛先を使用したロールの推移... E-5 E.2.1 フィジカル スタンバイ データベースから REDO データを受信するスタンバイ データベース... E-5 E.2.2 ロジカル スタンバイ データベースから REDO データを受信するスタンバイ データベース... E-5 E.3 カスケードされた宛先の例... E-5 E.3.1 ローカル フィジカル スタンバイとカスケードされたリモート フィジカル スタンバイ... E-5 E.3.2 ローカル フィジカル スタンバイとカスケードされたリモート ロジカル スタンバイ... E-6 E.3.3 ローカルおよびリモート フィジカル スタンバイとカスケードされたローカル ロジカル スタンバイ... E-6 E.3.4 カスケードされたロジカル スタンバイ宛先の統合レポート生成... E-7 E.3.5 ネットワーク アップグレード時のカスケードされた宛先の一時使用... E-7 x

13 F Recovery Manager を使用したスタンバイ データベースの作成 F.1 スタンバイ データベースを作成するための Recovery Manager の準備... F-2 F.1.1 Recovery Manager を使用したスタンバイ データベースの準備について... F-2 F.1.2 Recovery Manager を使用したスタンバイ制御ファイルの作成... F-3 F.1.3 Recovery Manager を使用した場合のスタンバイ データベース データファイルのネーミング... F-4 F.1.4 Recovery Manager を使用した場合のスタンバイ データベース ログ ファイルの ネーミング... F-5 F.2 Recovery Manager を使用したスタンバイ データベースの作成 : 概要... F-6 F.2.1 リカバリを実行しない Recovery Manager によるスタンバイの作成... F-6 F.2.2 リカバリを実行する Recovery Manager によるスタンバイの作成... F-7 F.3 スタンバイ データベースの設定... F-8 F.3.1 ファイルが Oracle Managed Files ではない場合のスタンバイ データベースの セットアップ... F-8 F.3.2 すべてのファイルが Oracle Managed Files の場合のスタンバイ データベースのセットアップ... F-9 F.3.3 ファイルのサブセットが Oracle Managed Files の場合のスタンバイ データベースの セットアップ... F-10 F.4 同一のディレクトリ構造のスタンバイ データベースの作成... F-10 F.4.1 リカバリを実行しないスタンバイ データベースの作成... F-10 F.4.2 スタンバイ データベースの作成およびリカバリの実行... F-11 F.5 異なるディレクトリ構造のスタンバイ データベースの作成... F-12 F.5.1 DB_FILE_NAME_CONVERT を使用したスタンバイ データベース ファイルの ネーミング... F-12 F リカバリを実行しないスタンバイ データベースの作成... F-12 F スタンバイ データベースの作成およびリカバリの実行... F-12 F.5.2 SET NEWNAME を使用したスタンバイ データベース ファイルのネーミング... F-13 F リカバリを実行しないスタンバイ データベースの作成... F-13 F スタンバイ データベースの作成およびリカバリの実行... F-13 F.5.3 CONFIGURE AUXNAME を使用したスタンバイ データベース ファイルのネーミング... F-14 F リカバリを実行しないスタンバイ データベースの作成... F-14 F スタンバイ データベースの作成およびリカバリの実行... F-15 F.6 ローカル ホスト上へのスタンバイ データベースの作成... F-16 F.7 イメージ コピーを使用したスタンバイ データベースの作成... F-17 F.7.1 概要... F-17 F.7.2 コピーおよびデータファイルで同一の名前を使用する場合... F-18 F.7.3 コピーおよびデータファイルで異なる名前を使用する場合... F-19 F リカバリを実行しないスタンバイ データベースの作成... F-19 F スタンバイ データベースの作成およびリカバリの実行... F-20 F.8 使用例... F-21 G アーカイブ トレースの設定 索引 G.1 LOG_ARCHIVE_TRACE 初期化パラメータ... G-2 G.2 トレース ファイルの位置の判別... G-2 G.2.1 LOG_ARCHIVE_TRACE 初期化パラメータの設定... G-2 G.2.2 整数値の選択... G-3 xi

14 xii

15 例 3-1 特定のスレッドへのスタンバイ REDO ログ ファイル グループの追加 特定のグループ番号へのスタンバイ REDO ログ ファイル グループの追加 プライマリ データベース : プライマリ ロールの初期化パラメータ プライマリ データベース : スタンバイ ロールの初期化パラメータ フィジカル スタンバイ データベース用の初期化パラメータを変更する プライマリ データベース : ロジカル スタンバイ ロールの初期化パラメータ ロジカル スタンバイ データベース用の初期化パラメータの変更 ローカルのアーカイブ先の指定 リモートのアーカイブ先の指定 共有リカバリ領域に関するプライマリ データベースの初期化パラメータ 共有リカバリ領域に関するスタンバイ データベースの初期化パラメータ LGWR 同期アーカイブのための初期化パラメータ LGWR 非同期アーカイブのための初期化パラメータ 再試行時間の設定と制限 必須のアーカイブ先の設定 DBA_LOGSTDBY_EVENTS を使用したイベントの監視 V$ARCHIVE_DEST ビューでの VALID_FOR 情報の検索 代替アーカイブ先への自動フェイルオーバー スタンバイ データベースに対する代替の Oracle Net サービス名の定義 A-1 再試行時間の設定と制限... A-4 A-2 代替宛先の指定... A-4 A-3 ITL が不十分な状態に関してレポートされる警告メッセージ... A-15 xiii

16 xiv

17 図 1-1 一般的な Data Guard 構成 フィジカル スタンバイ データベースの自動更新 ロジカル スタンバイ データベースの自動更新 Oracle Enterprise Manager の Data Guard 概要ページ 可能なスタンバイ構成 REDO データの転送 スタンバイ データベースがない場合のプライマリ データベースのアーカイブ処理 リモートの宛先にアーカイブする前にローカルの宛先にアーカイブする スタンバイ REDO ログ ファイルを使用したリモートの宛先への LGWR SYNC アーカイブ ネットワーク サーバー (LNSn) プロセスを使用した LGWR ASYNC アーカイブ 代替アーカイブ先のデバイスへのアーカイブ操作 依存する宛先を含む Data Guard 構成 リアルタイム適用を使用したスタンバイ宛先への REDO データの適用 スイッチオーバー前の Data Guard 構成 新しいプライマリ データベースへのスイッチオーバー前のスタンバイ データベース スイッチオーバー後の Data Guard 環境 スタンバイ データベースへのフェイルオーバー 読取り専用アクセス用にオープンしたスタンバイ データベース SQL Apply の処理 SQL Apply 処理中の進捗状態 アップグレード前の Data Guard 構成 ロジカル スタンバイ データベースのリリースのアップグレード 混合リリースの実行 スイッチオーバー後 両方のデータベースがアップグレードされた後 ロールの推移前のプライマリおよびフィジカル スタンバイ データベース ロールの推移後のプライマリおよびフィジカル スタンバイ データベース プライマリ データベースおよびロジカル スタンバイ データベースの宛先の構成 ロールの推移後のプライマリおよびロジカル スタンバイ データベース フィジカルおよびロジカル スタンバイ データベースを備えたプライマリ データベースの 構成 ロールの推移後のプライマリ フィジカルおよびロジカル スタンバイ データベース テストおよびレポート生成用データベースとしてのフィジカル スタンバイ データベースの 使用 アーカイブ ギャップ内にあるアーカイブ REDO ログ ファイルの手動リカバリ D-1 複数インスタンス プライマリ データベースからの REDO データの転送... D-2 D-2 Real Application Clusters のスタンバイ データベース... D-3 E-1 カスケードされた宛先の構成例... E-1 xv

18 xvi

19 表 2-1 スタンバイ データベースの位置とディレクトリ オプション フィジカル スタンバイ データベースを作成するためのプライマリ データベースの準備 フィジカル スタンバイ データベースの作成 ロジカル スタンバイ データベースを作成するためのプライマリ データベースの準備 ロジカル スタンバイ データベースの作成 LOG_ARCHIVE_DEST_STATE_n 初期化パラメータの属性 データ保護モードの最低要件 ARCH 属性で構成される宛先の待機イベント LGWR SYNC 属性で構成される宛先の待機イベント LGWR ASYNC 属性で構成される宛先の待機イベント プライマリ データベースでの変更後にスタンバイ データベースで必要なアクション プライマリ データベースの共通アクションを監視できる場所 Oracle Database ソフトウェアをアップグレードする手順 Data Guard の使用例 プライマリ データベースとフィジカル スタンバイ データベースの初期化パラメータの 設定 プライマリ データベースとロジカル スタンバイ データベースの初期化パラメータの 設定 プライマリ データベース フィジカル スタンバイ データベースおよび ロジカル スタンバイ データベースの初期化パラメータ フィジカル スタンバイ データベースの例で使用される識別子 ロジカル スタンバイ データベースの例で使用される識別子 Data Guard 構成内のインスタンスの初期化パラメータ TEMPLATE 属性のディレクティブ VALID_FOR 属性の値 Data Guard 環境で使用される ALTER DATABASE 文 Data Guard 環境で使用される ALTER SESSION 文 Data Guard 構成に関連のあるビュー A-1 スイッチオーバーを妨げる共通のプロセス... A-6 A-2 一般的な SQL Apply エラーの解決方法... A-9 C-1 DBMS_LOGSTDBY.SKIP プロシージャの stmt パラメータの値... C-5 C-2 SQL DDL 文スキップ用の文のオプション... C-7 D-1 LOG_ARCHIVE_FORMAT 初期化パラメータのディレクティブ... D-5 E-1 プライマリ データベース フィジカル スタンバイ データベースおよび ロジカル スタンバイ データベースの初期化パラメータ... E-3 F-1 Recovery Manager を使用したスタンバイ データベースの準備... F-2 F-2 スタンバイ データベース内のデータファイルのネーミング優先順位... F-5 F-3 イメージ コピーを使用したスタンバイ データベースの作成 : 使用例... F-17 xvii

20 xviii

21 はじめに Oracle Data Guard は 現在使用できる最も効率的なソリューションで 企業の中核となる資産 つまりデータを保護し 障害やその他の災害が発生しても 24 時間 365 日そのデータを使用できるようにします このマニュアルでは Oracle Data Guard テクノロジとその概要 スタンバイ データベースの構成および実装方法について説明します xix

22 対象読者 Oracle Data Guard 概要および管理 は Oracle データベース システムのバックアップ リストアおよびリカバリ操作を管理するデータベース管理者を対象としています このマニュアルは 読者がリレーショナル データベースの概念と 基本的なバックアップおよびリカバリ管理に精通していることを前提としています また Oracle ソフトウェアを実行するオペレーティング システム環境をよく理解している必要があります ドキュメントのアクセシビリティについて オラクル社は 障害のあるお客様にもオラクル社の製品 サービスおよびサポート ドキュメントを簡単にご利用いただけることを目標としています オラクル社のドキュメントには ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています HTML 形式のドキュメントで用意されており 障害のあるお客様が簡単にアクセスできるようにマークアップされています 標準規格は改善されつつあります オラクル社はドキュメントをすべてのお客様がご利用できるように 市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています オラクル社のアクセシビリティについての詳細情報は Oracle Accessibility Program の Web サイト を参照してください ドキュメント内のサンプル コードのアクセシビリティについて一部スクリーン リーダーは ドキュメント内のサンプル コードを正確に読めない場合があります コード表記規則では閉じ括弧だけを行に記述する必要があります しかし JAWS は括弧だけの行を読まない場合があります 外部 Web サイトのドキュメントのアクセシビリティについてこのドキュメントにはオラクル社およびその関連会社が所有または管理しない Web サイトへのリンクが含まれている場合があります オラクル社およびその関連会社は それらの Web サイトのアクセシビリティに関しての評価や言及は行っておりません 関連ドキュメント Oracle Data Guard 概要および管理 の読者は 次のマニュアルをすでに読んでいることが前提となります Oracle Database 概要 の冒頭部分 Oracle データベースに関連する概念と用語の概要が説明されており このマニュアルに記載されている詳細情報の基礎となっています Oracle Database 管理者ガイド の中で 制御ファイル オンライン REDO ログ ファイルおよびアーカイブ REDO ログ ファイルの管理について説明している章 Oracle Database ユーティリティ の中で LogMiner テクノロジについて説明している章 Oracle Data Guard Broker Data Guard 構成の作成 メンテナンス 監視を自動化および集中化するグラフィカル ユーザー インタフェースとコマンドライン インタフェースについて説明しています Oracle Enterprise Manager のオンライン ヘルプ システム このマニュアルの説明では 次の各マニュアルも取り上げています Oracle Database SQL リファレンス Oracle Database リファレンス Oracle Database バックアップおよびリカバリ基礎 Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド Oracle Database Net Services 管理者ガイド xx

23 SQL*Plus ユーザーズ ガイドおよびリファレンス Oracle Database 高可用性概要 Oracle Streams および Streams のダウンストリーム取得データベースの詳細は Oracle Streams 概要および管理 も参照してください Streams のダウンストリーム取得プロセスは Oracle Data Guard の REDO 転送サービスを使用して REDO データをリモート データベース上のログ ファイルに転送します リモート データベースでは Streams の取得プロセスにより リモート宛先でのアーカイブ REDO ログ ファイルの変更点が取得されます 表記規則 このマニュアルの本文では 次の表記規則が使用されています 規則太字イタリック体固定幅フォント 意味 太字は 操作に関連する Graphical User Interface 要素 または本文中で定義されている用語および用語集に記載されている用語を示します イタリックは ユーザーが特定の値を指定するプレースホルダ変数を示します 固定幅フォントは 段落内のコマンド URL サンプル内のコード 画面に表示されるテキスト または入力するテキストを示します サポートおよびサービス 次の各項に 各サービスに接続するための URL を記載します Oracle サポート サービスオラクル製品サポートの購入方法 および Oracle サポート サービスへの連絡方法の詳細は 次の URL を参照してください 製品マニュアル製品のマニュアルは 次の URL にあります 研修およびトレーニング研修に関する情報とスケジュールは 次の URL で入手できます その他の情報オラクル製品やサービスに関するその他の情報については 次の URL から参照してください 注意 : ドキュメント内に記載されている URL や参照ドキュメントには Oracle Corporation が提供する英語の情報も含まれています 日本語版の情報については 前述の URL を参照してください xxi

24 xxii

25 Oracle Data Guard の新機能 この項では Oracle Data Guard リリース 10.2 に追加された新機能について説明し 詳細情報へのリンクを提供します 10g リリース 2(10.2) の Oracle Data Guard には この項で説明する新機能と拡張機能が追加されました 新機能を 次の主な内容にわけて説明します REDO Apply と SQL Apply に共通する新機能 REDO Apply およびフィジカル スタンバイ データベース固有の新機能 SQL Apply およびロジカル スタンバイ データベース固有の新機能 xxiii

26 REDO Apply と SQL Apply に共通する新機能 10g リリース 2(10.2) の Oracle Data Guard に対する次の拡張機能により 利便性 管理性およびパフォーマンスが向上し 障害時リカバリ機能を改善する新機能が追加されています ファスト スタート フェイルオーバーファスト スタート フェイルオーバーは プライマリ データベースが消失した場合に 指定した同期スタンバイ データベースに自動的に 迅速かつ確実にフェイルオーバーする機能を提供します フェイルオーバーを起動するために複雑な手動ステップを実行する必要はありません また ファスト スタート フェイルオーバーの発生後は 構成に再接続すると自動的に古いプライマリ データベースが新しいスタンバイ データベースとして再構成されます これにより Data Guard は複雑な手動ステップなしで容易に構成に障害時保護をリストアできるため Data Guard の障害時リカバリ機能の堅牢性が向上するのみでなく Data Guard の管理性も向上します これらの新機能により 稼働時間を維持して可用性を高め 障害時リカバリの堅牢性も改善できます さらに 手動による介入の必要性が減少することで 管理コストが削減されます 関連項目 : Oracle Data Guard Broker Data Guard のスイッチオーバー間のフラッシュバック データベースプライマリ データベースとスタンバイ データベースを スイッチオーバー操作前の時点または SCN までフラッシュバックできるようになりました このフラッシュバック データベースの機能をフィジカル スタンバイ データベースで使用すると スタンバイ ロールが保持されます ロジカル スタンバイ データベースでは スタンバイ データベースのロールがターゲット SCN またはターゲット時点でのロールに変更されます この機能によりフラッシュバック ウィンドウが拡張され より柔軟に人為的エラーを検出して修正できます 関連項目 : 使用 7.4 項 ロールの推移後のフラッシュバック データベースの 非同期 REDO 転送ログ ライター プロセス (LGWR ASYNC) を使用する非同期 REDO 転送は プライマリ データベースのパフォーマンス低下を軽減するように改善されました 非同期 REDO 転送中は ネットワーク サーバー (LNSn) プロセスがプライマリ データベースのオンライン REDO ログ ファイルから REDO データを転送します ログ ライター プロセスと直接相互作用することはなくなりました この動作変更により ログ ライター プロセスは現行のオンライン REDO ログ ファイルに REDO データを書き込み プロセス間通信やネットワーク I/O の完了を待機せずに次の要求の処理を続行できます 関連項目 : 項 LGWR ASYNC アーカイブ プロセス および第 14 章の SYNC および ASYNC 属性の説明を参照してください LOG_ARCHIVE_DEST_n パラメータの新しい MAX_CONNECTIONS 属性この属性は プライマリ データベースのアーカイバ (ARCn) プロセスで REDO データをスタンバイ データベースに送信するタイミングを調整する方法を指定します MAX_ CONNECTIONS 属性を 0( ゼロ ) 以外の値に設定すると REDO 転送サービスでは複数のネットワーク接続とアーカイバ プロセスを使用して REDO データが転送されます 関連項目 : ページの MAX_CONNECTIONS 属性 xxiv

27 Oracle Enterprise Manager の Data Guard 拡張機能 Data Guard 構成の管理に Data Guard Broker を使用する場合は Oracle Enterprise Manager で次の拡張機能を使用できます フェイルオーバー推定時間 ( 秒 ) このスタンバイ データベースへのフェイルオーバーに必要な概算秒数 これは 起動時間 ( 必要な場合 ) と スタンバイ データベースで使用可能な REDO データをすべて適用するために必要な残り時間を考慮した推定時間です データベースを起動する必要がない場合は 残りの適用時間のみが表示されます 適用ラグ ( 秒 ) スタンバイ データベースが REDO データの適用に関してプライマリ データベースから遅れている秒数 REDO 生成率 (KB/ 秒 ) プライマリ データベースでの REDO 生成率が KB/ 秒単位で表示されます 時刻 ( 最後の REDO 生成時刻 最後の REDO 適用時刻 ) は表示されません REDO 適用率 (KB/ 秒 ) このスタンバイ データベースでの REDO 適用率が KB/ 秒単位で表示されます 転送ラグ ( 秒 ) このスタンバイ データベースで使用可能になっていない REDO データの概算秒数 これは REDO の未送信またはギャップの存在が原因で発生することがあります Data Guard ステータス Data Guard ステータス メトリックを使用すると Data Guard 構成に含まれる各データベースのステータスをチェックできます デフォルトで このメトリック列にはクリティカルしきい値と警告しきい値が設定されていました しきい値に達するとアラートが生成されます 必要に応じてしきい値を編集できます ファスト スタート フェイルオーバーの発生 ファスト スタート フェイルオーバーが使用可能な場合にファスト スタート フェイルオーバーが発生すると このメトリックにより新しいプライマリ データベース ( 古いスタンバイ データベース ) でクリティカル アラートが生成されます ファスト スタート フェイルオーバーの SCN は メトリックによりアラートが生成される前の値に初期化する必要があります 通常 これは 1 収集間隔です ファスト スタート フェイルオーバーが発生した場合に新しいプライマリ データベースの準備が完了していると ファスト スタート フェイルオーバー アラートが生成されます このアラートは 1 収集間隔後に消去されます デフォルトではクリティカル アラートが構成されます * アクセスを監視する SYSDBA でプライマリ データベースとスタンバイ データベースの両方を構成する必要があります * ファスト スタート フェイルオーバーの発生回数が表示されます 値は ファスト スタート フェイルオーバーが発生しなかった場合は 0( ゼロ ) 発生した場合は 1 です xxv

28 ファスト スタート フェイルオーバー SCN ファスト スタート フェイルオーバーが使用可能な場合にファスト スタート フェイルオーバーが発生すると このメトリックにより新しいプライマリ データベース ( 古いスタンバイ データベース ) でクリティカル アラートが生成されます ファスト スタート フェイルオーバーの SCN は メトリックによりアラートが生成される前の値に初期化する必要があります 通常 これは 1 収集間隔です ファスト スタート フェイルオーバーが発生した場合に新しいプライマリ データベースの準備が完了していると ファスト スタート フェイルオーバー アラートが生成されます このアラートは 1 収集間隔後に消去されます デフォルトではクリティカル アラートが構成されます * アクセスを監視する SYSDBA でプライマリ データベースとスタンバイ データベースの両方を構成する必要があります * 値は メトリックのトリガー準備が完了していることを示します ファスト スタート フェイルオーバーの時間 ファスト スタート フェイルオーバーが使用可能な場合にファスト スタート フェイルオーバーが発生すると このメトリックにより新しいプライマリ データベース ( 古いスタンバイ データベース ) でクリティカル アラートが生成されます ファスト スタート フェイルオーバーの SCN は メトリックによりアラートが作成される前の値に初期化する必要があります 通常 これは 1 収集間隔です ファスト スタート フェイルオーバーが発生した場合に新しいプライマリ データベースの準備が完了していると ファスト スタート フェイルオーバー アラートが実行されます その後 1 収集間隔後に消去されます デフォルトではクリティカル アラートが構成されます * アクセスを監視する SYSDBA でプライマリ データベースとスタンバイ データベースの両方を構成する必要があります * ファスト スタート フェイルオーバーが発生した場合は タイムスタンプが表示されます 関連項目 : Oracle Enterprise Manager のオンライン ヘルプ システム Change Data Capture および Streams の新規サポート Distributed( 異機種間 )Asynchronous Change Data Capture Downstream Capture Hot Mining 関連項目 : Oracle Streams 概要および管理 および Oracle Database データ ウェアハウス ガイド (Change Data Capture 情報 ) REDO Apply およびフィジカル スタンバイ データベース固有の新機能次のリストに Oracle Database 10g リリース 2(10.2) の REDO Apply およびフィジカル スタンバイ データベース固有の新機能を示します 高速化された REDO Apply フェイルオーバースタンバイ データベースが前回の起動時以後に読取り専用モードでオープンされていなければ データベースを再起動せずに フィジカル スタンバイ データベースをプライマリ データベース ロールに推移させることができます これにより 障害や停止からのリカバリが高速化され システムの可用性が向上します 関連項目 : 項 フィジカル スタンバイ データベースが関与するフェイルオーバー xxvi

29 フィジカル スタンバイ データベースからレポート用データベースへの容易な変換フィジカル スタンバイ データベースをプライマリ データベースとしてアクティブ化してレポート生成のために読取り / 書込み用にオープンし 元のフィジカル スタンバイ データベースに容易に変換できるように過去の時点へフラッシュバックできます この時点で Data Guard により自動的にスタンバイ データベースがプライマリ データベースと同期化されます これにより フィジカル スタンバイ データベースをレポート アクティビティや読取り / 書込みクローニング アクティビティに使用できます 関連項目 : 12.6 項 フィジカル スタンバイ データベースを使用した読取り / 書込みテストとレポート生成 RECOVER MANAGED STANDBY DATABASE FINISH の新しい FORCE キーワード ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH 文の新しい FORCE オプションを使用すると ターゲット スタンバイ データベースでアクティブな RFS プロセスを停止できます これにより ログが適用された直後にフェイルオーバーが進行します 関連項目 : 項 フィジカル スタンバイ データベースが関与するフェイルオーバー および Oracle Database SQL リファレンス の ALTER DATABASE 構文に関する項 Recovery Manager によるリカバリ後の一時ファイルの自動再作成 Recovery Manager によるリカバリ操作中に ローカルで管理される一時表領域に属する一時データファイルが自動的に作成されるため 一時ファイルを作成してフィジカル スタンバイ データベースの一時表領域に関連付ける必要がなくなりました 使用性と管理性を向上させるその他の変更点不要な初期化パラメータおよび特定の SQL 文の句とキーワードを廃止することで フィジカル スタンバイ データベースの使用性と管理性が改善されました 関連項目 : Oracle Database SQL リファレンス の Data Guard 関連の SQL 文に関する項および Oracle Database リファレンス の LOG_ARCHIVE_ DEST_n 初期化パラメータに関する項 SQL Apply およびロジカル スタンバイ データベース固有の新機能次のリストに Oracle Database 10g リリース 2(10.2) の SQL Apply およびロジカル スタンバイ データベースの新機能を示します 高速化された SQL Apply フェイルオーバーフェイルオーバー操作の一部として SQL Apply を再起動する必要がなくなったため ロジカル スタンバイ データベースへのフェイルオーバー完了までの所要時間が大幅に短縮されました これにより 障害や停止からの Data Guard 構成のリカバリが高速化され システムの可用性が向上します 関連項目 : 項 ロジカル スタンバイ データベースが関与するフェイルオーバー 索引編成表のデータ型サポートの追加 SQL Apply では LOB 列およびオーバーフロー セグメントを含む索引編成表により生成された REDO レコードのマイニングがサポートされるようになりました 関連項目 : 項 表のデータ型および記憶域属性のサポートの判別 xxvii

30 適用済アーカイブ REDO ログ ファイルの自動削除アーカイブ ログ ファイルは ロジカル スタンバイ データベースでの適用後に SQL Apply により自動的に削除されます これにより ロジカル スタンバイ データベースの記憶域使用量が減少し Data Guard の管理性が向上します 関連項目 : 項 ログ ファイルの自動削除 最適化されたロジカル スタンバイ データベース作成 Recovery Manager では使用できない特化されたロジカル スタンバイ制御ファイルを作成せずに ロジカル スタンバイ データベースを作成できるようになりました フィジカル スタンバイ データベースから容易にロジカル スタンバイ データベースを作成できます これにより ロジカル スタンバイ データベースを作成するための特別な手動操作が減少し Data Guard の管理性が向上します 関連項目 : 4.2 項 ロジカル スタンバイ データベースの作成手順 ロジカル スタンバイ データベース管理のために追加された複数の拡張機能 新規のビュー * V$LOGSTDBY_PROCESS( 廃止になった V$LOGSTDBY ビューの代替 ) * V$LOGSTDBY_STATE * V$LOGSTDBY_PROGRESS * V$LOGSTDBY_TRANSACTION * V$DATAGUARD_STATS DBMS_LOGSTDBY PL/SQL パッケージの新規の DBMS_LOGSTDBY.REBUILD() サブプログラム トレース 関連項目 : 第 9 章 ロジカル スタンバイ データベースの管理 xxviii

31 第 I 部 概要および管理 この部は 次の章で構成されています 第 1 章 Oracle Data Guard の概要 第 2 章 Data Guard スタート ガイド 第 3 章 フィジカル スタンバイ データベースの作成 第 4 章 ロジカル スタンバイ データベースの作成 第 5 章 REDO 転送サービス 第 6 章 ログ適用サービス 第 7 章 ロールの推移 第 8 章 フィジカル スタンバイ データベースの管理 第 9 章 ロジカル スタンバイ データベースの管理 第 10 章 Recovery Manager を使用したファイルのバックアップおよびリストア 第 11 章 SQL Apply を使用した Oracle Database のアップグレード 第 12 章 Data Guard の使用例

32

33 1 Oracle Data Guard の概要 Oracle Data Guard では 企業データの高可用性 データ保護および障害時リカバリを保証します Data Guard は 1 つ以上のスタンバイ データベースの作成 メンテナンス 管理および監視など 一連の包括的なサービスを提供し 本番の Oracle データベースを障害およびデータ破損から保護します Data Guard では スタンバイ データベースを本番データベースのトランザクション一貫性のあるコピーとしてメンテナンスします したがって 本番データベースが計画的または計画外の停止によって使用不可能になった場合は スタンバイ データベースを本番ロールに切り替えて 停止時間を最小限にできます Data Guard を従来のバックアップ リストアおよびクラスタ化の技法と連携して使用すると 高いレベルのデータ保護とデータ可用性を実現できます Data Guard を使用すると リソース集中型のバックアップおよびレポート生成操作をスタンバイ システムにオフロードすることで 管理者は本番データベースのパフォーマンスをオプションで改善できます この章では Oracle Data Guard の概要を説明します 次の項目で構成されています Data Guard 構成 Data Guard サービス Data Guard Broker Data Guard 保護モード Data Guard と補完テクノロジ Data Guard のメリットの要約 Oracle Data Guard の概要 1-1

34 Data Guard 構成 1.1 Data Guard 構成 Data Guard 構成には 1 つの本番データベースと 1 つ以上のスタンバイ データベースが含まれます Data Guard 構成のデータベースは Oracle Net で接続され 地理的に分散している場合があります データベースの配置場所に制限はありませんが 相互に通信できる必要があります たとえば 1 個のスタンバイ データベースを本番データベースと同じシステム上に配置し 2 個のスタンバイ データベースをリモート位置の別のシステム上に配置できます プライマリ データベースとスタンバイ データベースは SQL コマンドライン インタフェースまたは Data Guard Broker インタフェースを使用して管理できます Data Guard Broker インタフェースには コマンドライン インタフェース (DGMGRL) や Oracle Enterprise Manager に統合されたグラフィカル ユーザー インタフェースなどがあります プライマリ データベース Data Guard 構成には 1 個の本番データベースが含まれています これはプライマリ データベースとも呼ばれ プライマリ ロールで機能します アプリケーションは主としてこのデータベースにアクセスします プライマリ データベースは シングル インスタンスの Oracle データベースまたは Oracle Real Application Clusters データベースのいずれかです スタンバイ データベース スタンバイ データベースは プライマリ データベースのトランザクション一貫性のあるコピーです プライマリ データベースのバックアップ コピーを使用すると 最大 9 個のスタンバイ データベースを作成して Data Guard 構成に組み込むことができます スタンバイ データベースが作成されると Data Guard では プライマリ データベースからスタンバイ データベースに REDO データを転送し スタンバイ データベースに REDO を適用することによって 各スタンバイ データベースを自動的にメンテナンスします プライマリ データベースと同様 スタンバイ データベースは シングル インスタンスの Oracle データベースまたは Oracle Real Application Clusters データベースのいずれかです スタンバイ データベースは 次のフィジカル スタンバイ データベースまたはロジカル スタンバイ データベースのいずれかです フィジカル スタンバイ データベースプライマリ データベースと物理的に同一になるようコピーしたものです ディスク上のデータベース構造は ブロック単位でプライマリ データベースと同一です 索引などのデータベース スキーマも同一です フィジカル スタンバイ データベースでは プライマリ データベースから受信した REDO データをリカバリし REDO をフィジカル スタンバイ データベースに適用する Redo Apply によって プライマリ データベースとの同期を維持します フィジカル スタンバイ データベースは 限られた基準で障害時リカバリ以外のビジネス用途にも使用できます ロジカル スタンバイ データベース本番データベースと同じ論理情報が格納されますが データの物理的な構成と構造は異なる場合があります ロジカル スタンバイ データベースでは プライマリ データベースから受信した REDO データを SQL 文に変換し スタンバイ データベースでその SQL 文を実行する SQL Apply によって プライマリ データベースとの同期を維持します ロジカル スタンバイ データベースは 障害時リカバリ要件に加えて その他のビジネス用途にも使用できます このため ロジカル スタンバイ データベースには 問合せやレポート生成の目的でいつでもアクセスできます また ロジカル スタンバイ データベースを使用すると ほとんどの場合 データベースを停止することなく Oracle Database ソフトウェアやパッチ セットをアップグレードできます つまり ロジカル スタンバイ データベースは データ保護 レポート生成およびデータベースのアップグレードに同時に使用できます 1-2 Oracle Data Guard 概要および管理

35 Data Guard サービス 構成例 図 1-1 は REDO データをスタンバイ データベースに転送するプライマリ データベースが含まれている一般的な Data Guard 構成を示しています スタンバイ データベースは 障害時リカバリ操作とバックアップ操作に備えて プライマリ データベースから離れた位置に配置されます スタンバイ データベースはプライマリ データベースと同じ位置にも構成できます ただし 障害時リカバリに使用する場合は スタンバイ データベースを離れた位置に構成することをお薦めします 図 1-1 に 一般的な Data Guard 構成例を示します この構成では REDO はスタンバイ REDO ログ ファイルからスタンバイ データベースに適用されます 図 1-1 一般的な Data Guard 構成 1.2 Data Guard サービス 次の各項では Data Guard による REDO データの転送 REDO データの適用およびデータベース ロールの変更の管理方法について説明します REDO 転送サービス 本番データベースから 1 つ以上のアーカイブ先に対する REDO データの自動転送を制御します ログ適用サービス REDO データをスタンバイ データベースに適用し プライマリ データベースとのトランザクションの同期を維持します REDO データは アーカイブ REDO ログ ファイルから適用できます また リアルタイム適用が可能な場合は スタンバイ データベースで最初に REDO データをアーカイブしなくても いっぱいになったときにスタンバイ REDO ログ ファイルから直接適用することもできます ロールの推移 データベースのロールを スイッチオーバー操作またはフェイルオーバー操作を使用して スタンバイ データベースからプライマリ データベースに またはプライマリ データベースからスタンバイ データベースに変更します Oracle Data Guard の概要 1-3

36 Data Guard サービス REDO 転送サービス ログ適用サービス REDO 転送サービスは 本番データベースから 1 つ以上のアーカイブ先に対する REDO データの自動転送を制御します REDO 転送サービスでは 次のタスクを実行します REDO データを構成内のプライマリ システムからスタンバイ システムに転送します ネットワーク障害により発生したアーカイブ REDO ログ ファイル内のギャップを解決するプロセスを管理します データベース保護モード (1.4 項を参照 ) を施行します スタンバイ システム上の欠落または破損しているアーカイブ REDO ログ ファイルを自動的に検出し プライマリ データベースまたは別のスタンバイ データベースからかわりのアーカイブ REDO ログ ファイルを自動的に取得します プライマリ データベースから転送された REDO データは スタンバイ システム上でスタンバイ REDO ログ ファイルに書き込まれ ( そのように構成されている場合 ) アーカイブ REDO ログ ファイルにアーカイブされます ログ適用サービスログ適用サービスは REDO データをスタンバイ データベースに自動的に適用し プライマリ データベースとの一貫性を維持します データを読取り専用にすることも可能です フィジカル スタンバイ データベースとロジカル スタンバイ データベースの主な相違点は ログ適用サービスによるアーカイブ REDO データの適用方法にあります フィジカル スタンバイ データベースの場合 Data Guard では REDO Apply テクノロジを使用します このテクノロジでは 図 1-2 に示すように Oracle データベースの標準リカバリ技法を使用して REDO データがスタンバイ データベースに適用されます 図 1-2 フィジカル スタンバイ データベースの自動更新 1-4 Oracle Data Guard 概要および管理

37 Data Guard サービス ロジカル スタンバイ データベースの場合 Data Guard では SQL Apply テクノロジを使用します このテクノロジでは 図 1-3 に示すように まず 受信した REDO データが SQL 文に変換されてから 生成された SQL 文がロジカル スタンバイ データベース上で実行されます 図 1-3 ロジカル スタンバイ データベースの自動更新 ロールの推移 Oracle データベースは プライマリ ロールまたはスタンバイ ロールのいずれかで実行されます Data Guard では スイッチオーバー操作またはフェイルオーバー操作のいずれかを使用してデータベースのロールを変更できます スイッチオーバーとは プライマリ データベースとそのスタンバイ データベースの 1 つとの間でロールを可逆的に推移させる操作です スイッチオーバーにより データ消失のない状態が保証されます この操作は通常 プライマリ システムの計画的なメンテナンスに対して実行します スイッチオーバー時には プライマリ データベースがスタンバイ ロールに あるいはスタンバイ データベースがプライマリ ロールに推移します 推移は いずれのデータベースも再作成せずに実行されます フェイルオーバーは プライマリ データベースが使用不可能な場合に発生します フェイルオーバーは プライマリ データベースで災害などの障害が起きたときのみに実行され スタンバイ データベースをプライマリ ロールに推移させます データベース管理者は データが消失しないように Data Guard を構成できます このマニュアルで説明しているロールの推移は SQL 文を使用して手動で行います また 1.3 項で説明しているように Oracle Data Guard Broker を使用してロールの推移を単純化させ Oracle Enterprise Manager または DGMGRL コマンドライン インタフェースを使用してフェイルオーバーを自動化することもできます Oracle Data Guard の概要 1-5

38 Data Guard Broker 1.3 Data Guard Broker Data Guard Broker は分散管理フレームワークで Data Guard 構成の作成 メンテナンスおよび監視を自動化します Oracle Enterprise Manager のグラフィカル ユーザー インタフェース (GUI) または Data Guard コマンドライン インタフェース (DGMGRL) を使用すると 次の操作が自動化および単純化されます REDO 転送サービスやログ適用サービスの設定など Data Guard 構成の作成と有効化 構成内の任意のシステムによる Data Guard 構成全体の管理 Real Application Clusters のプライマリ データベースまたはスタンバイ データベースが含まれる Data Guard 構成の管理と監視 Oracle Enterprise Manager での単一キー クリックまたは DGMGRL コマンドライン インタフェースでの単一コマンドを使用した起動によるスイッチオーバーまたはフェイルオーバーの単純化 プライマリ データベースが使用不可能になった場合に 自動的にフェイルオーバーを起動するための ファスト スタート フェイルオーバーの有効化 ファスト スタート フェイルオーバーが有効になると Data Guard Broker によりフェイルオーバーが必要かどうかが決定され 指定のターゲット スタンバイ データベースに対して自動的にフェイルオーバーが開始されます DBA による操作の必要はなく データの消失もありません さらに Oracle Enterprise Manager を使用すると 次の操作が自動化および単純化されます プライマリ データベースのバックアップ コピーからのフィジカル スタンバイ データベースまたはロジカル スタンバイ データベースの作成 Data Guard 構成への新規または既存のスタンバイ データベースの追加 ログ適用レートの監視 診断情報の獲得 および集中化した監視ツール テスト ツール パフォーマンス ツールなどを使用した問題の早期検出 関連項目 : 詳細は Oracle Data Guard Broker を参照してください Oracle Enterprise Manager の使用 Oracle Enterprise Manager( 以下 Enterprise Manager と呼びます ) は Data Guard 構成内のプライマリ データベースおよびスタンバイ データベースを表示 監視および管理するための Web ベースのインタフェースを提供します Enterprise Manager の使いやすいインタフェースと Broker による Data Guard 構成の集中化された管理および監視を組み合せることで 企業内の高可用性 サイト保護およびデータ保護を実現するための Data Guard ソリューションが強化されます Enterprise Manager セントラル コンソールから すべての管理操作をローカルまたはリモートで実行できます プライマリ データベースとスタンバイ データベース およびプライマリ インスタンスとスタンバイ インスタンスを含む Oracle データベースのホーム ページの表示 既存のスタンバイ データベースの作成または追加 インスタンスの開始および停止 インスタンスのパフォーマンスの監視 イベントの表示 ジョブのスケジュール バックアップ操作およびリカバリ操作の実行が可能です Oracle Data Guard Broker および Oracle Enterprise Manager のオンライン ヘルプを参照してください 1-6 Oracle Data Guard 概要および管理

39 Data Guard Broker 図 1-4 は Enterprise Manager の Data Guard 管理概要ページを示しています 図 1-4 Oracle Enterprise Manager の Data Guard 概要ページ Data Guard コマンドライン インタフェースの使用 Data Guard のコマンドライン インタフェース (DGMGRL) を使用すると DGMGRL プロンプトまたはスクリプト内から Data Guard 構成を制御および監視できます DGMGRL を使用すると 構成でデータベースを管理および監視するために必要なアクティビティのほとんどを実行できます DGMGRL のリファレンスの詳細と例は Oracle Data Guard Broker を参照してください Oracle Data Guard の概要 1-7

40 Data Guard 保護モード 1.4 Data Guard 保護モード 場合によっては データの消失が許されないビジネスがあります また データの消失よりデータベースの可用性のほうが重要な企業もあります アプリケーションの中には データベース パフォーマンスを最大化することが必要で 少量のデータの消失なら許容できるものがあります データ保護には 次の 3 つの異なるモードが用意されています 最大保護この保護モードは プライマリ データベースに障害が発生した場合でも データ消失がないことを保証します このレベルの保護を提供するには トランザクションがコミットされる前に 各トランザクションをリカバリするために必要な REDO データを 少なくとも 1 つのスタンバイ データベースにあるローカルのオンライン REDO ログおよびスタンバイ REDO ログに書き込む必要があります 障害によって 少なくとも 1 つのトランザクション一貫性のあるスタンバイ データベースのスタンバイ REDO ログに REDO ストリームを書込みできない場合は データ消失が発生しないようにプライマリ データベースが停止します 最大可用性この保護モードは プライマリ データベースの可用性を低下させない範囲で可能な最高レベルのデータ保護を提供します 最大保護モードと同様に トランザクションは そのトランザクションのリカバリに必要な REDO が ローカル オンライン REDO ログおよび少なくとも 1 つのトランザクション一貫性のあるスタンバイ データベースのスタンバイ REDO ログに書き込まれるまでコミットされません 障害によってリモート スタンバイ REDO ログに REDO ストリームを書込みできない場合 最大保護モードとは異なり プライマリ データベースは停止しません かわりに 障害が解決され REDO ログ ファイルのすべてのギャップが解決されるまで プライマリ データベースは最大パフォーマンス モードで動作します すべてのギャップが解決されると プライマリ データベースは 最大可用性モードでの動作を自動的に再開します このモードでは プライマリ データベースに障害が発生した場合 ただし 2 回目の障害でプライマリ データベースから少なくとも 1 つのスタンバイ データベースに REDO データの完全なセットが送信される場合にのみ データが消失しないことを保証します 最大パフォーマンスこの保護モード ( デフォルト ) は プライマリ データベースのパフォーマンスに影響しない範囲で可能な最高レベルのデータ保護を提供します これは トランザクションのリカバリに必要な REDO データがローカルのオンライン REDO ログに書き込まれた直後に そのトランザクションのコミットを許可することで実行されます プライマリ データベースの REDO データ ストリームは 少なくとも 1 つのスタンバイ データベースにも書き込まれますが その REDO ストリームは REDO データを作成するトランザクションについて非同期で書き込まれます 十分な帯域幅を持つネットワーク リンクが使用される場合 このモードは プライマリ データベースのパフォーマンスに対する影響を最小限にして 最大可用性モードのレベルに近いデータ保護レベルを提供します 最大保護モードおよび最大可用性モードでは 構成内の少なくとも 1 つのスタンバイ データベースに スタンバイ REDO ログ ファイルを構成する必要があります 3 つの保護モードはいずれも REDO データが少なくとも 1 つのスタンバイ データベースに送信されるよう LOG_ARCHIVE_DEST_n 初期化パラメータで特定のログ転送属性を指定する必要があります データ保護モードの詳細は 5.6 項を参照してください 1-8 Oracle Data Guard 概要および管理

41 Data Guard と補完テクノロジ 1.5 Data Guard と補完テクノロジ Oracle Database では Data Guard を補完する複数の固有のテクノロジを提供して ビジネスに不可欠なシステムが 1 つのソリューションのみを利用する場合に比べ はるかに高い可用性とデータ保護を実現しながら稼働できるようにします Oracle の高可用性テクノロジには 次のものがあります Oracle Real Application Clusters(RAC) RAC を使用すると インターコネクトによってリンクされた複数の独立型サーバーで Oracle データベースへのアクセスを共有し 障害の発生時に 高可用性 スケーラビリティおよび冗長性を実現できます RAC と Data Guard を一緒に使用すると システムレベル サイトレベルおよびデータレベルのそれぞれの保護にメリットがあるため データを消失することなく 高い可用性と障害時リカバリが実現します RAC は ノード障害やインスタンスのクラッシュなどの障害から迅速かつ自動的にリカバリすることで システムの障害に対処します また アプリケーションのスケーラビリティも改善されます Data Guard では トランザクション的に一貫性のある ディスクを共有しないプライマリ データベースとスタンバイ データベースを介して サイト内の問題やデータ保護に対処し サイトの障害やデータ破損からリカバリできるようにします ローカル サイトとリモート サイトの使用 ロジカル スタンバイ データベースとフィジカル スタンバイ データベースの組合せとノードの使用によって RAC および Data Guard を使用した様々なアーキテクチャを実現できます RAC および Data Guard の統合の詳細は 付録 D Data Guard および Real Application Clusters および Oracle Database 高可用性概要 を参照してください フラッシュバック データベース フラッシュバック データベース機能により 論理データの破損やユーザー エラーから迅速にリカバリできます 適切なときにフラッシュバックを許可することで 誤って変更または削除された可能性のある以前のバージョンのビジネス情報に再度アクセスできるようになります この機能により 次のことが実現します バックアップをリストアして エラーや破損が発生した時点までロールフォワード変更を行う必要がなくなります かわりに フラッシュバック データベースでは データファイルをリストアせずに 以前の時点まで Oracle データベースをロールバックできます REDO の適用を遅延してユーザー エラーや論理的な破損から保護するための 代替手段を提供します したがって スタンバイ データベースは プライマリ データベースとより密接に同期できるため フェイルオーバーおよびスイッチオーバーの回数が少なくなります フェイルオーバー後に 元のプライマリ データベースを完全に作成しなおす必要がなくなります 障害が発生したプライマリ データベースを フェイルオーバー前の時点にフラッシュ バックして 新しいプライマリ データベースのスタンバイ データベースになるように変換できます フラッシュバック データベースの詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を REDO データの適用を遅延させる方法は 項を参照してください Oracle Data Guard の概要 1-9

42 Data Guard のメリットの要約 Recovery Manager(RMAN) Recovery Manager は データベース ファイルのバックアップ リストアおよびリカバリを単純化する Oracle ユーティリティです Data Guard と同様に Recovery Manager は Oracle データベースの機能の 1 つであるため 個別にインストールする必要はありません Data Guard と Recovery Manager は密接に統合されているため 次のことが実現されます Recovery Manager の DUPLICATE コマンドを使用して プライマリ データベースのバックアップからスタンバイ データベースを作成できます 本番データベースではなくフィジカル スタンバイ データベースからバックアップを取得して 本番データベースの負荷を軽減し スタンバイ サイトのシステム リソースを効率的に使用できます また フィジカル スタンバイ データベースが REDO を適用しているときに バックアップを取得することもできます バックアップの実行後 入力に使用されたアーカイブ REDO ログ ファイルを自動的に削除することで アーカイブ REDO ログ ファイルの管理を容易にします 付録 F Recovery Manager を使用したスタンバイ データベースの作成 および Oracle Database バックアップおよびリカバリ基礎 を参照してください 1.6 Data Guard のメリットの要約 Data Guard には次のようなメリットがあります 障害時リカバリ データ保護および高可用性 Data Guard は 効率のよい包括的な障害時リカバリおよび高可用性ソリューションを提供します 管理が容易なスイッチオーバー機能とフェイルオーバー機能を使用すると プライマリ データベースとスタンバイ データベース間でロールを可逆的に推移できるため 計画的および計画外の停止によるプライマリ データベースの停止時間が最小限になります 完全なデータ保護 Data Guard では 予期しない障害が発生した場合でもデータが消失しないことが保証されます スタンバイ データベースには データの破損やユーザーのミスに対する保護対策が用意されています プライマリ データベースの記憶域レベルの物理破損は スタンバイ データベースに伝播されません 同様に プライマリ データベースの完全な破損の原因となった論理的な破損やユーザーのミスも解決できます 最後に REDO データが スタンバイ データベースへの適用時に検証されます システム リソースの効率的な使用 プライマリ データベースから受信した REDO データで更新されたスタンバイ データベース表は バックアップ レポート生成 要約および問合せなどの他のタスクにも使用できます したがって これらのタスクの実行に必要なプライマリ データベースのワークロードを低減し 貴重な CPU と I/O のサイクルを節約できます ロジカル スタンバイ データベースを使用すると プライマリ データベースに基づいて更新されていないスキーマ内の各表で通常のデータ操作を実行できます ロジカル スタンバイ データベースは 表をプライマリ データベースから更新する間 オープン状態のままにしておくことができるため 表は読取り専用アクセスに同時に使用できます 最後に メンテナンスされている表に追加の索引やマテリアライズド ビューを作成することによって 問合せパフォーマンスを改善し 特定のビジネス要件を満たすことができます 可用性とパフォーマンス要件とのバランスを保つことができるデータ保護の柔軟性 Oracle Data Guard には 各企業がデータ可用性とシステム パフォーマンス要件とのバランスを保つことができるように 最大保護 最大可用性および最大パフォーマンスの 3 つのモードが用意されています 1-10 Oracle Data Guard 概要および管理

43 Data Guard のメリットの要約 ギャップの自動検出と自動解消 ネットワークの問題などで プライマリ データベースと 1 つ以上のスタンバイ データベースとの間の接続が失われた場合 プライマリ データベース上に生成される REDO データは 宛先のスタンバイ データベースに送信されません 接続が再度確立された時点で Data Guard によって 欠落しているアーカイブ REDO ログ ファイル ( ギャップと呼ばれます ) が自動的に検出され それらのファイルがスタンバイ データベースに自動的に転送されます スタンバイ データベースはプライマリ データベースと同期化されるため DBA による手動操作は不要です 集中化された単純な管理 Data Guard Broker は グラフィカル ユーザー インタフェースとコマンドライン インタフェースを提供し Data Guard 構成の複数のデータベース全体の管理タスクと操作タスクを自動化します また ブローカは 単一の Data Guard 構成内のすべてのシステムを監視します Oracle Database との統合 Data Guard では Oracle Database Enterprise Edition の機能の 1 つであるため 個別にインストールする必要はありません 自動ロールの推移 ファスト スタート フェイルオーバーが有効になると プライマリ サイトで障害が発生した場合 Data Guard Broker により DBA による操作の必要なしに同期化されたスタンバイ サイトにフェイルオーバーされます また アプリケーションにロールの推移が自動的に通知されます Oracle Data Guard の概要 1-11

44 Data Guard のメリットの要約 1-12 Oracle Data Guard 概要および管理

45 2 Data Guard スタート ガイド Data Guard 構成には 1 つのプライマリ データベースと それに対応付けられた最大 9 個のスタンバイ データベースが含まれます この章では Data Guard の使用を開始するための次の考慮事項について説明します スタンバイ データベースのタイプ Data Guard 構成の管理のためのユーザー インタフェース Data Guard の動作要件 スタンバイ データベースのディレクトリ構造に関する考慮事項 オンライン REDO ログ アーカイブ REDO ログおよびスタンバイ REDO ログ Data Guard スタート ガイド 2-1

46 スタンバイ データベースのタイプ 2.1 スタンバイ データベースのタイプ スタンバイ データベースは Oracle 本番データベースのトランザクション一貫性のあるコピーで 最初はプライマリ データベースのバックアップ コピーから作成されます スタンバイ データベースが作成および構成されると Data Guard は プライマリ データベースの REDO データをスタンバイ システムに転送し スタンバイ データベースに適用することによって スタンバイ データベースを自動的にメンテナンスします スタンバイ データベースには フィジカル スタンバイ データベースとロジカル スタンバイ データベースの 2 つのタイプがあります いずれのタイプのスタンバイ データベースも 必要に応じてプライマリ データベースのロールを引き継ぎ 本番処理を継続できます Data Guard 構成には フィジカル スタンバイ データベース ロジカル スタンバイ データベース または両方のタイプの組合せを含めることができます フィジカル スタンバイ データベース フィジカル スタンバイ データベースは プライマリ データベースと物理的に同一で ディスク上のデータベース構造は ブロック単位でプライマリ データベースと同一です 索引などのデータベース スキーマも同一です Data Guard では REDO Apply を実行することによって フィジカル スタンバイ データベースのメンテナンスが行われます リカバリが実行されていないときは フィジカル スタンバイ データベースを読取り専用モードでオープンでき フラッシュバック データベースが使用可能になっている場合は 一時的に読取り / 書込みモードでオープンできます REDO Apply フィジカル スタンバイ データベースは Oracle リカバリ メカニズムを使用して スタンバイ システムでアーカイブ REDO ログ ファイルの REDO データを適用するか またはスタンバイ REDO ログ ファイルを直接適用することによってメンテナンスされます リカバリ操作では データ ブロック アドレスを使用して REDO ブロック内の変更がデータ ブロックに適用されます REDO の適用中 データベースはオープンできません 読取り専用オープンフィジカル スタンバイ データベースは読取り専用モードでオープンできるため データベース上で問合せを実行できます 読取り専用モードでオープンしている間 スタンバイ データベースは REDO データの受信を継続できますが ログ ファイルからの REDO データの適用は データベースで REDO Apply が再開されるまで遅延されます フィジカル スタンバイ データベースでは REDO Apply と読取り専用モードのオープンを同時に実行することはできませんが これらの操作を切り替えることはできます たとえば REDO Apply を実行し 次にアプリケーションでレポートが実行できるようにデータベースを読取り専用モードでオープンした後 データベースを元に戻して REDO Apply を実行し 未処理のアーカイブ REDO ログ ファイルを適用できます このサイクルを繰り返し REDO Apply と読取り専用操作を適宜実行できます フィジカル スタンバイ データベースをバックアップの実行に使用できます さらに フィジカル スタンバイ データベースは アーカイブ REDO ログ ファイルまたはスタンバイ REDO ログ ファイルがその時点で適用されない場合でも REDO データの受信を継続します 読取り / 書込み用オープン フィジカル スタンバイ データベースは クローン データベースの作成やレポートの読取り / 書込みなどの目的で読取り / 書込みアクセス用にオープンすることもできます 読取り / 書込みモードでオープンされている間は スタンバイ データベースはプライマリ データベースから REDO データを受信せず 障害時保護を提供できません 2-2 Oracle Data Guard 概要および管理

47 スタンバイ データベースのタイプ フィジカル スタンバイ データベースを開発 レポートまたはテストのために読取り / 書込みモードで一時的にオープンしてから 過去の特定時点までフラッシュバックして元に戻すことができます データベースがフラッシュバックされると Data Guard では自動的にスタンバイ データベースをプライマリ データベースと同期化します プライマリ データベースのバックアップ コピーからフィジカル スタンバイ データベースを再作成する必要はありません 関連項目 : 使用例は 12.6 項を参照してください フィジカル スタンバイ データベースのメリットフィジカル スタンバイ データベースには次のメリットがあります 障害時リカバリと高可用性 フィジカル スタンバイ データベースによって 堅牢で効率的な障害時リカバリと可用性の高いソリューションを実現できます 管理が容易なスイッチオーバー機能とフェイルオーバー機能を使用すると プライマリ データベースとフィジカル スタンバイ データベース間でロールを可逆的に推移できるため 計画的および計画外の停止によるプライマリ データベースの停止時間が最小限になります データ保護 フィジカル スタンバイ データベースを使用することで 予期しない障害が発生した場合でもデータが消失しないことが保証されます フィジカル スタンバイ データベースでは プライマリ データベースでサポートされるすべてのデータ型 およびすべての DDL 操作と DML 操作がサポートされます また データの破損やユーザーのミスに対する保護対策も用意されています プライマリ データベースの記憶域レベルの物理破損は スタンバイ データベースに伝播されません 同様に プライマリ データベースの完全な破損の原因となった論理的な破損やユーザーのミスも解決できます 最後に REDO データが スタンバイ データベースへの適用時に検証されます プライマリ データベースのワークロードの低減 Oracle Recovery Manager は フィジカル スタンバイ データベースを使用してプライマリ データベースからバックアップをオフロードし 貴重な CPU と I/O のサイクルを節約できます フィジカル スタンバイ データベースを読取り専用モードでオープンすると レポート生成および問合せを実行することもできます パフォーマンス フィジカル スタンバイ データベースで使用される REDO Apply テクノロジは 低レベルのリカバリ メカニズムを使用して変更を適用します このメカニズムは SQL レベルのコード レイヤーをすべてバイパスするため 大量の REDO データの適用に関しては最も効率的です Data Guard スタート ガイド 2-3

48 スタンバイ データベースのタイプ ロジカル スタンバイ データベース ロジカル スタンバイ データベースは 最初はプライマリ データベースと同じ内容のコピーで作成されますが 後で異なる構造に変更できます ロジカル スタンバイ データベースは SQL 文を実行して更新されます これにより ユーザーは問合せとレポート生成の目的で スタンバイ データベースにいつでもアクセスできます このように ロジカル スタンバイ データベースは データ保護操作とレポート生成操作に同時に使用できます Data Guard は ログ ファイルのデータを SQL 文に変換し ロジカル スタンバイ データベースでその SQL 文を実行することによって アーカイブ REDO ログ ファイルまたはスタンバイ REDO ログ ファイルの情報をロジカル スタンバイ データベースに自動的に適用します ロジカル スタンバイ データベースは SQL 文を使用して更新されるため オープン状態のままであることが必要です ロジカル スタンバイ データベースは読取り / 書込みモードでオープンされますが 再生成された SQL に対するターゲット表は 読取り専用操作用にのみ使用可能です 更新中 これらの表は レポート生成 要約 問合せなどの他のタスクで同時に使用できます さらに これらのタスクは メンテナンスされている表に追加の索引やマテリアライズド ビューを作成することによって最適化できます ロジカル スタンバイ データベースには データ型 表のタイプおよび DDL 操作や DML 操作のタイプに関していくつかの制限があります サポートされないデータ型および表の記憶域属性は 項で説明しています ロジカル スタンバイ データベースのメリットロジカル スタンバイ データベースには フィジカル スタンバイ データベースと同様の障害時リカバリ 高可用性およびデータ保護のメリットがあります その他に 次のメリットもあります スタンバイ ハードウェア資源の効率的な使用 ロジカル スタンバイ データベースは 障害時リカバリ要件に加えて その他のビジネス用途にも使用できます Data Guard 構成内で保護されているデータベース スキーマ以外に別のデータベース スキーマをホスティングできるため ユーザーは これらのスキーマ上で通常の DDL 操作または DML 操作をいつでも実行できます Data Guard で保護されているロジカル スタンバイ表は プライマリ データベースとは異なる物理的なレイアウトで格納できるため 追加の索引やマテリアライズド ビューを作成して 問合せのパフォーマンスを改善したり 特定のビジネス要件にあわせることができます プライマリ データベースのワークロードの低減 ロジカル スタンバイ データベースは その表をプライマリ データベースから更新するとき オープン状態のままにしておくことができるため これらの表は読取りアクセスに同時に使用できます このことによって ロジカル スタンバイ データベースは 問合せ 要約およびレポート生成の各アクティビティを実行する際の優れたデータベースとなり これらのタスクからプライマリ データベースがオフロードされ 貴重な CPU と I/O のサイクルが節約されます 2-4 Oracle Data Guard 概要および管理

49 Data Guard の動作要件 2.2 Data Guard 構成の管理のためのユーザー インタフェース Data Guard 構成の構成 実装および管理には 次のインタフェースを使用できます Oracle Enterprise Manager Enterprise Manager では Data Guard 環境の作成 構成および監視に関係するタスクの多くを自動化する Data Guard Broker の GUI インタフェースが用意されています GUI およびウィザードについては Oracle Data Guard Broker および Oracle Enterprise Manager のオンライン ヘルプを参照してください SQL*Plus コマンドライン インタフェース いくつかの SQL*Plus 文では STANDBY キーワードを使用して スタンバイ データベースに対する操作を指定します 他の SQL 文にはスタンバイ固有の構文はありませんが スタンバイ データベースで操作を実行するときに役立ちます 関連する文のリストは 第 15 章を参照してください 初期化パラメータ Data Guard 環境の定義には いくつかの初期化パラメータが使用されます 関連する初期化パラメータのリストは 第 13 章を参照してください Data Guard Broker コマンドライン インタフェース (DGMGRL) DGMGRL コマンドライン インタフェースは Enterprise Manager の代替手段です DGMGRL コマンドライン インタフェースは ブローカを使用してバッチ プログラムまたはスクリプトから Data Guard 構成を管理する場合に役立ちます 詳細は Oracle Data Guard Broker を参照してください 2.3 Data Guard の動作要件 次の各項で Data Guard 使用時の動作要件を説明します ハードウェアおよびオペレーティング システムの要件 Oracle ソフトウェア要件 ハードウェアおよびオペレーティング システムの要件 次のリストに Data Guard 使用時のハードウェアおよびオペレーティング システムの要件を示します Data Guard 構成のすべてのメンバーで 同じプラットフォーム用に作成された Oracle イメージを実行する必要があります たとえば 32 ビットの Intel システムの Linux 上にプライマリ データベースが存在している Data Guard 構成の場合 そのスタンバイ データベースは 32 ビットの Intel システムの Linux 上に構成されている必要があります ただし 両方のサーバーが 32 ビット イメージを実行している場合は 64 ビットの HP-UX システムに存在するプライマリ データベースを 32 ビットの HP-UX システム上のスタンバイ データベースとともに構成することもできます ハードウェア (CPU の数 メモリー サイズ 記憶域構成など ) は プライマリ システムとスタンバイ システムで異なっていても構いません スタンバイ システムがプライマリ システムより小規模な場合は スイッチオーバーまたはフェイルオーバー後にスタンバイ システムで実行可能な作業を制限する必要があります スタンバイ システムには プライマリ データベースからすべての REDO データを受信して適用するための十分なリソースが必要です ロジカル スタンバイ データベースには REDO データを SQL 文に変換し その SQL をロジカル スタンバイ データベースで実行するための追加のリソースが必要です プライマリ ロケーションとスタンバイ ロケーションのオペレーティング システムは同じであることが必要ですが 同じリリースである必要はありません また スタンバイ データベースではプライマリ データベースと異なるディレクトリ構造を使用できます Data Guard スタート ガイド 2-5

50 Data Guard の動作要件 Oracle ソフトウェア要件 次のリストに Data Guard 使用時の Oracle ソフトウェア要件を示します Oracle Data Guard は Oracle Database Enterprise Edition の機能としてのみ提供されています Oracle Database Standard Edition には付属していません したがって Data Guard 構成のプライマリ データベースおよびすべてのスタンバイ データベースに 同じリリースの Oracle Database Enterprise Edition がインストールされている必要があります 注意 : Oracle Database Standard Edition を実行しているデータベースでスタンバイ データベース環境を再現することが可能です これを行うには オペレーティング システムのコピー ユーティリティ または定期的にアーカイブ REDO ログ ファイルをデータベースからデータベースに送信するカスタム スクリプトを使用して 手動でアーカイブ REDO ログ ファイルを転送します したがって この構成では Data Guard によって提供される利便性 管理性 パフォーマンスおよび障害時リカバリ機能を得られません Data Guard SQL Apply を使用して Oracle Database ソフトウェアをパッチ セット リリース n( 以上 ) から次のデータベース (n+1) パッチ セット リリースにローリング アップグレードできます ローリング アップグレード時には プライマリ データベースおよびロジカル スタンバイ データベースを 1 つずつアップグレードする間 異なるリリースの Oracle Database を実行できます 詳細は 第 11 章 SQL Apply を使用した Oracle Database のアップグレード および該当する Oracle Database 10g パッチ セット リリースの README ファイルを参照してください Data Guard 構成のすべてのデータベースで COMPATIBLE 初期化パラメータを同じ値に設定する必要があります 現在 Oracle8i データベース ソフトウェア上で Oracle Data Guard を実行している場合 Oracle Data Guard をアップグレードする際の詳細は Oracle Database アップグレード ガイド を参照してください プライマリ データベースは ARCHIVELOG モードで実行する必要があります 詳細は Oracle Database 管理者ガイド を参照してください プライマリ データベースは シングル インスタンス データベースまたは複数インスタンスの Real Application Clusters データベースです スタンバイ データベースは シングル インスタンス データベースまたは複数インスタンスの Real Application Clusters (RAC) データベースで フィジカル タイプとロジカル タイプを組み合せることができます Oracle Data Guard を RAC とともに構成および使用する方法については Oracle Database 高可用性概要 を参照してください プライマリ データベースとスタンバイ データベースには それぞれ独自の制御ファイルが必要です スタンバイ データベースがプライマリ データベースと同じシステムにある場合 スタンバイ データベースのアーカイブ ディレクトリは プライマリ データベースとは異なるディレクトリ構造を使用する必要があります 同じ構造を使用すると スタンバイ データベースがプライマリ データベース ファイルを上書きする可能性があります プライマリ データベースに対して ログに記録されず スタンバイ データベースに伝播できないダイレクト書込みが行われるのを防ぐには プライマリ データベースで FORCE LOGGING をオンにした後で スタンバイ作成用にデータファイルのバックアップを実行します スタンバイ データベースが必要な間は データベースを FORCE LOGGING モードに保持してください プライマリ データベースとスタンバイ データベースのインスタンスの管理に使用するユーザー アカウントには SYSDBA システム権限が必要です Oracle Automatic Storage Management(ASM) および Oracle Managed Files(OMF) を Data Guard 構成でセットアップする際 プライマリおよびスタンバイ データベースに対称的にセットアップすることをお薦めします つまり Data Guard 構成のいずれかのデータベースで ASM OMF またはその両方を使用する場合 構成内のすべてのデータベー 2-6 Oracle Data Guard 概要および管理

51 スタンバイ データベースのディレクトリ構造に関する考慮事項 スでもそれぞれ ASM OMF またはその両方を使用する必要があります 詳細は 項の使用例を参照してください 注意 : 更新の際に時間ベースのデータが使用される一部のアプリケーションでは 複数のタイムゾーンで入力されたデータを処理できないため ロールの推移後もレコードの時間的順序が維持されるよう プライマリおよびリモート スタンバイ システムに同じタイムゾーンを設定することをお薦めします 2.4 スタンバイ データベースのディレクトリ構造に関する考慮事項 各種スタンバイ データベースのディレクトリ構造によってスタンバイ データファイル アーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイルのパス名が決まるため ディレクトリ構造は重要です 可能であれば プライマリ システムとスタンバイ システムでデータファイル ログ ファイルおよび制御ファイルの名前およびパス名を同一にし Optimal Flexible Architecture(OFA) のネーミング規則を使用する必要があります スタンバイ データベースのアーカイブ ディレクトリも サイズおよび構造を含めてサイト間で同一であることが必要です この方法により バックアップ スイッチオーバーおよびフェイルオーバーなどの他の操作を同じ手順で実行できるようになり メンテナンスの複雑さが軽減されます 同一にしない場合は ファイル名変換パラメータ ( 表 2-1 を参照 ) を設定するか データファイルの名前を変更する必要があります ディレクトリ構造が異なるシステムを使用する必要がある場合や スタンバイ データベースとプライマリ データベースのシステムを同じにする必要がある場合は 管理作業を最小限に抑えるようにしてください 図 2-1 に 3 つの基本構成オプションを示します 構成オプションは 次のとおりです スタンバイ データベースがプライマリ データベースと同じシステムにあるが プライマリ システムとは異なるディレクトリ構造を使用する これは 図 2-1 の Standby1 です スタンバイ データベースをプライマリ データベースと同じシステムに配置する場合は 異なるディレクトリ構造を使用する必要があります 同じ構造を使用すると スタンバイ データベースがプライマリ データベース ファイルを上書きしようとします スタンバイ データベースが別個のシステム上にあり プライマリ システムと同じディレクトリ構造を使用する これは 図 2-1 の Standby2 です このオプションをお薦めします スタンバイ データベース別個のシステム上にあり プライマリ システムと異なるディレクトリ構造を使用する これは 図 2-1 の Standby3 です 注意 : Data Guard 構成のいずれかのデータベースで ASM OMF またはその両方を使用する場合 構成内のすべてのデータベースでもそれぞれ ASM OMF またはその両方を使用する必要があります Data Guard 構成での OMF のセットアップ方法を説明する使用例は 第 12 章を参照してください Data Guard スタート ガイド 2-7

52 スタンバイ データベースのディレクトリ構造に関する考慮事項 図 2-1 可能なスタンバイ構成 表 2-1 で プライマリ データベースとスタンバイ データベースの可能な構成 およびそれぞれの結果的な注意事項について説明します この表では デフォルトのサービス名が DB_ UNIQUE_NAME および DB_DOMAIN 初期化パラメータの値を連結したものであることに注意してください Data Guard 構成の複数のメンバーが同じシステムに常駐する場合は DB_UNIQUE_NAME 初期化パラメータに一意の値を指定する必要があります 各データベースが異なるシステムに存在する場合も DB_UNIQUE_NAME 初期化パラメータには常に一意の値を指定することをお薦めします 表 2-1 スタンバイ データベースの位置とディレクトリ オプション スタンバイ システム プライマリ システムと同じ ディレクトリ構造 プライマリ システムと異なる ( 必須 ) 結果的な注意事項 DB_UNIQUE_NAME 初期化パラメータを設定する必要があります スタンバイ データベース制御ファイル内のプライマリ データベースのデータファイル アーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイルのパス名を自動的に更新するには ファイル名を手動で変更するか スタンバイ データベースで DB_FILE_NAME_ CONVERT 初期化パラメータと LOG_FILE_NAME_ CONVERT 初期化パラメータを設定します (3.1.4 項を参照 ) スタンバイ データベースは プライマリ データベースとスタンバイ データベースが存在しているシステムを破壊するような障害に対する保護には役立ちませんが 計画的なメンテナンスに対するスイッチオーバー機能は提供します 2-8 Oracle Data Guard 概要および管理

53 オンライン REDO ログ アーカイブ REDO ログおよびスタンバイ REDO ログ 表 2-1 スタンバイ データベースの位置とディレクトリ オプション ( 続き ) スタンバイ システム 離れたシステム 離れたシステム ディレクトリ構造 プライマリ システムと同じ プライマリ システムと異なる 結果的な注意事項 スタンバイ データベース制御ファイル内のプライマリ データベースのファイル名 アーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイル名を変更する必要はありません ただし 新しいネーミング計画が必要な場合 ( 複数のディスクにファイルを分散する場合など ) は 変更しても構いません スタンバイ データベースを別の物理メディアに置くことにより プライマリ システムを破壊するような障害からプライマリ データベースのデータを保護できます ファイル名を手動で変更するか またはスタンバイ データベースで DB_FILE_NAME_CONVERT 初期化パラメータおよび LOG_FILE_NAME_CONVERT 初期化パラメータを設定し データファイル名を自動的に変更できます (3.1.4 項を参照 ) スタンバイ データベースを別の物理メディアに置くことにより プライマリ システムを破壊するような障害からプライマリ データベースのデータを保護できます 2.5 オンライン REDO ログ アーカイブ REDO ログおよびスタンバイ REDO ログ Data Guard リカバリ操作の最も重要な構造は オンライン REDO ログ アーカイブ REDO ログおよびスタンバイ REDO ログです プライマリ データベースから転送された REDO データは スタンバイ システムのリモート ファイル サーバー (RFS) プロセスによって受信されます RFS プロセスは この REDO データをアーカイブ ログ ファイルまたはスタンバイ REDO ログ ファイルのいずれかに書き込みます REDO データは REDO がアーカイブ REDO ログ ファイルまたはスタンバイ REDO ログ ファイルに書き込まれた後 もしくはリアルタイム適用が使用可能になっている場合は いっぱいになったスタンバイ REDO ログ ファイルから直接 適用できます このマニュアルでは オンライン REDO ログおよびアーカイブ REDO ログの概要を理解していることを前提としています 項では Data Guard 構成固有の情報を説明することにより 基本概念を強化しています 項では スタンバイ REDO ログ ファイルの使用方法の詳細を説明しています REDO ログおよびアーカイブ ログの詳細は Oracle Database 管理者ガイド を参照してください リアルタイム適用の詳細は 項を参照してください オンライン REDO ログおよびアーカイブ REDO ログ プライマリ データベースとスタンバイ データベースのトランザクション一貫性を維持するには REDO の転送が不可欠です Data Guard 環境では オンライン REDO ログおよびアーカイブ REDO ログの両方が必要です オンライン REDO ログ インスタンス障害の際にデータベースを保護するために Oracle プライマリ データベースおよびロジカル スタンバイ データベースのすべてのインスタンスには オンライン REDO ログが存在します フィジカル スタンバイ データベースは読取り / 書込み I/O のためにオープンされないため オンライン REDO ログは使用されません フィジカル スタンバイ データベースが変更されることはなく 新規 REDO データは生成されません Data Guard スタート ガイド 2-9

54 オンライン REDO ログ アーカイブ REDO ログおよびスタンバイ REDO ログ アーカイブ REDO ログ スタンバイ データベースとプライマリ データベースのトランザクション一貫性を維持するためにアーカイブが使用されるため アーカイブ REDO ログは必須です プライマリ データベース フィジカル スタンバイ データベースおよびロジカル スタンバイ データベースでは いずれもアーカイブ REDO ログが使用されます Oracle データベースは デフォルトで ARCHIVELOG モードで稼働するよう設定されています これにより いっぱいになった各オンライン REDO ログ ファイルが アーカイバ (ARCn) プロセスによって自動的に 1 つ以上のアーカイブ REDO ログ ファイルにコピーされます フィジカル スタンバイ データベースと異なり ロジカル スタンバイ データベースは REDO データを生成し 複数のログ ファイルを持つオープン状態のデータベースです ログ ファイルは オンライン REDO ログ ファイル アーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイル ( 構成されている場合 ) などです プライマリ サイトでのアーカイブ REDO ログ ファイルの生成には オンライン REDO ログ ファイルのサイズとログ スイッチの発生頻度の両方が影響します Oracle Database 高可用性概要 では ログ グループのサイズ決定の際の推奨事項を説明しています Oracle データベースは各ログ スイッチでチェックポイントを試行します したがって オンライン REDO ログ ファイルのサイズが小さすぎる場合は ログ スイッチの発生頻度が高いために チェックポイントの発生頻度も高くなり スタンバイ データベースのシステム パフォーマンスに悪影響を及ぼします スタンバイ REDO ログ 関連項目 : REDO ログ アーカイブ ログおよびログ グループの構成方法の詳細は Oracle Database 管理者ガイド を参照してください スタンバイ REDO ログはオンライン REDO ログと類似していますが スタンバイ REDO ログは他のデータベースから受信した REDO データの格納に使用されます 次のものを実装する場合は スタンバイ REDO ログが必要です データ保護の最大保護および最大可用性レベル (1.4 項 さらに詳細を 5.6 項で説明 ) リアルタイム適用 (6.2 項で説明 ) カスケードされた宛先 ( 付録 E で説明 ) スタンバイ REDO ログには 次のように多数のメリットがあります スタンバイ REDO ログ ファイルは RAW デバイスに常駐可能です プライマリおよびスタンバイ データベースの一方または両方が Real Application Clusters 環境に常駐する場合 この点が重要になります スタンバイ REDO ログ ファイルは 複数のメンバーを使用して多重化可能で これによってアーカイブ ログ ファイルの信頼性が向上します フェイルオーバー時には Data Guard はアーカイブ ログ ファイルのみに比べ スタンバイ REDO ログ ファイルからより多くの REDO データをリカバリおよび適用できます プライマリ データベース上のアーカイバ (ARCn) プロセスまたはログ ライター (LGWR) プロセスは リモート スタンバイ REDO ログ ファイルに直接 REDO データを転送でき これによって部分的にアーカイブ ログ ファイルを登録する必要がなくなります ( たとえば スタンバイ データベースのクラッシュ後のリカバリ時 ) 詳細は 第 5 章を参照してください 項では スタンバイ REDO ログ ファイルの構成手順を説明します 2-10 Oracle Data Guard 概要および管理

55 3 フィジカル スタンバイ データベースの作成 この章では フィジカル スタンバイ データベースを作成する手順について説明します この章は 次の主な項目で構成されています スタンバイ データベースを作成するためのプライマリ データベースの準備 フィジカル スタンバイ データベースの作成手順 作成後の手順 この章で説明する手順では スタンバイ データベースが最大パフォーマンス モードで構成されます このモードは デフォルトのデータ保護モードです 別のデータ保護モードの構成については 第 5 章を参照してください この章の説明は テキストの初期化パラメータ ファイル (PFILE) ではなく サーバー パラメータ ファイル (SPFILE) に初期化パラメータを指定することを前提としています 関連項目 サーバー パラメータ ファイルの作成方法および使用方法は Oracle Database 管理者ガイド を参照してください グラフィカル ユーザー インタフェースを使用してフィジカル スタンバイ データベースを自動的に作成する方法は Oracle Data Guard Broker および Enterprise Manager のオンライン ヘルプを参照してください フィジカル スタンバイ データベースの作成 3-1

56 スタンバイ データベースを作成するためのプライマリ データベースの準備 3.1 スタンバイ データベースを作成するためのプライマリ データベースの準備 スタンバイ データベースを作成する前に プライマリ データベースが正しく構成されていることを確認する必要があります 表 3-1 は フィジカル スタンバイ データベースを作成するための準備としてプライマリ データベースで実行するタスクのチェックリストです 各タスクを詳細に説明している参照先の項も記載されています 表 3-1 フィジカル スタンバイ データベースを作成するためのプライマリ データベースの準備 参照先 タスク 項強制ロギングの有効化 項パスワード ファイルの作成 項スタンバイ REDO ログの構成 項プライマリ データベースの初期化パラメータの設定 項アーカイブの有効化 注意 : これらの準備のためのタスクは 1 回のみ実行してください これらの手順を完了すると データベースは 1 つ以上のスタンバイ データベースに対するプライマリ データベースとして機能する準備が整います 強制ロギングの有効化 データベースの作成後 次の SQL 文を使用して プライマリ データベースを FORCE LOGGING モードにします SQL> ALTER DATABASE FORCE LOGGING; この文は 完了までに非常に時間がかかる場合があります これは ログに記録されないダイレクト書込み I/O がすべて完了するまで待機するためです パスワード ファイルの作成 パスワード ファイルが存在しない場合は 作成します Data Guard 構成内のすべてのデータベースにパスワード ファイルが必要です また SYS ユーザーのパスワードは REDO データを正常に転送するために すべてのシステムで同じである必要があります Oracle Database 管理者ガイド を参照してください 3-2 Oracle Data Guard 概要および管理

57 スタンバイ データベースを作成するためのプライマリ データベースの準備 スタンバイ REDO ログの構成 スタンバイ REDO ログ ファイルは 最大保護モードと最大可用性モードに必須であり LGWR ASYNC 転送モードをすべてのデータベースに使用することをお薦めします Data Guard はアーカイブ ログ ファイルのみに比べ スタンバイ REDO ログ ファイルからより多くの REDO データをリカバリおよび適用できます スタンバイ データベースを作成すると スタンバイ REDO ログ構成を計画して 必要なすべてのログ グループとグループのメンバーを作成する必要があります 可用性を向上するには オンライン REDO ログ ファイルの多重化と同様に スタンバイ REDO ログ ファイルを多重化することを検討してください 次の手順を実行して スタンバイ REDO ログを構成します 手順 1 プライマリ データベースおよびスタンバイ データベースのログ ファイルのサイズが同一であることを確認します 現行のスタンバイ REDO ログ ファイルのサイズは 現行のプライマリ データベースのオンライン REDO ログ ファイルのサイズと正確に一致している必要があります たとえば プライマリ データベースが ログ サイズが 200K の 2 つのオンライン REDO ログ グループを使用する場合 スタンバイ REDO ログ グループのログ ファイルのサイズも 200K である必要があります 手順 2 スタンバイ REDO ログ ファイル グループの適切な数を決定します 最小の構成では プライマリ データベースのオンライン REDO ログ ファイル グループの数より 1 つ以上多いスタンバイ REDO ログ ファイル グループが必要です ただし スタンバイ REDO ログ ファイル グループの推奨数は プライマリ データベース上のスレッド数によって異なります 次の数式を使用して スタンバイ REDO ログ ファイル グループの適切な数を決定します ( スレッド当たりのログ ファイルの最大数 + 1) スレッドの最大数 この数式を使用することにより スタンバイ REDO ログ ファイルがスタンバイ データベースに割り当てられないためにプライマリ インスタンスのログ ライター (LGWR) プロセスがブロックされる可能性が減少します たとえば プライマリ データベースにスレッド当たり 2 つのログ ファイルと 2 つのスレッドが存在する場合 スタンバイ データベースに 6 つのスタンバイ REDO ログ ファイル グループが必要になります 注意 : ロジカル スタンバイ データベースでは ワークロードにより これ以上のスタンバイ REDO ログ ファイル ( または追加の ARCn プロセス ) が必要になる可能性があります ロジカル スタンバイ データベースはオンライン REDO ログ ファイルにも書込みを行い これはスタンバイ REDO ログ ファイルより優先されるためです このため スタンバイ REDO ログ ファイルはオンライン REDO ログ ファイルほどすばやくアーカイブされない可能性があります 項も参照してください 手順 3 関連するデータベース パラメータおよび設定を確認します SQL CREATE DATABASE 文の MAXLOGFILES および MAXLOGMEMBERS 句に使用されている値により 追加できるスタンバイ REDO ログ ファイル グループ数とメンバー数が制限されないことを確認します MAXLOGFILES および MAXLOGMEMBERS 句で指定されている制限を無視するには プライマリ データベースまたは制御ファイルを再作成する必要があります MAXLOGFILES および MAXLOGMEMBERS 句のデフォルト値および有効な値の詳細は Oracle Database SQL リファレンス およびオペレーティング システム固有の Oracle ドキュメントを参照してください フィジカル スタンバイ データベースの作成 3-3

58 スタンバイ データベースを作成するためのプライマリ データベースの準備 手順 4 スタンバイ REDO ログ ファイル グループを作成します 新しいスタンバイ REDO ログ ファイル グループとメンバーの作成には ALTER DATABASE システム権限が必要です スタンバイ データベースは プライマリ データベースで次回ログ スイッチが発生するときに 新しく作成されたスタンバイ REDO ログ ファイルの使用を開始します 例 3-1 および例 3-2 では ADD STANDBY LOGFILE GROUP 句を変化させた ALTER DATABASE 文を使用して 新しいスタンバイ REDO ログ ファイル グループを作成する方法を示します 例 3-1 特定のスレッドへのスタンバイ REDO ログ ファイル グループの追加 次の文は 新しいスタンバイ REDO ログ ファイル グループをスタンバイ データベースに追加し それを THREAD 5 に割り当てます SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 5 2> ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500M; THREAD 句は 1 つ以上のスタンバイ REDO ログ ファイル グループを特定のプライマリ データベース スレッドに追加する場合にのみ必要です THREAD 句を含めず 構成で Real Application Clusters(RAC) を使用している場合 様々な RAC インスタンスからの必要性に応じ Data Guard により 実行時にスタンバイ REDO ログ ファイル グループがスレッドに自動的に割り当てられます 例 3-2 特定のグループ番号へのスタンバイ REDO ログ ファイル グループの追加 GROUP 句を使用して グループを識別する番号を指定することもできます SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10 2> ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500M; グループ番号を使用すると スタンバイ REDO ログ ファイル グループの管理が容易になります ただし グループ番号は 1 と MAXLOGFILES 句の値の間であることが必要です ログ ファイル グループ番号はスキップしないでください ( つまり グループに などの番号を付けないでください ) スキップすると スタンバイ データベースの制御ファイルの領域が余分に使用されます 注意 : スタンバイ REDO ログが使用されるのは データベースがスタンバイ ロールで実行されているときのみですが プライマリ データベースにスタンバイ REDO ログ ファイルを作成して プライマリ データベースが DBA による介入なしにスタンバイ ロールに迅速に切り替えられるようにすることをお薦めします プライマリ データベースおよびスタンバイ データベースの両方で自動的にスタンバイ REDO ログを構成するために Oracle Enterprise Manager を使用することを考慮してください 手順 5 スタンバイ REDO ログ ファイル グループが作成されたことを確認します スタンバイ REDO ログ ファイル グループが作成されて正しく実行していることを確認するには 作成後 プライマリ データベースでログ スイッチを起動してから スタンバイ データベースで V$STANDBY_LOG ビューまたは V$LOGFILE ビューを問い合せます 次に例を示します SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG; GROUP# THREAD# SEQUENCE# ARC STATUS NO ACTIVE YES UNASSIGNED YES UNASSIGNED 3-4 Oracle Data Guard 概要および管理

59 スタンバイ データベースを作成するためのプライマリ データベースの準備 プライマリ データベースの初期化パラメータの設定 プライマリ データベースでは データベースがプライマリ ロールで動作している間の REDO 転送サービスを制御する初期化パラメータを定義します また プライマリ データベースがスタンバイ ロールに推移したときに REDO データの受信とログ適用サービスを制御するパラメータを追加する必要があります 例 3-3 に プライマリ データベースでメンテナンスする プライマリ ロールの初期化パラメータを示します この例は シカゴにプライマリ データベースがあり ボストンにフィジカル スタンバイ データベースが 1 つある Data Guard 構成を示しています 例 3-3 に示すパラメータは シカゴのデータベースがプライマリ データベース ロールまたはスタンバイ データベース ロールで実行されている場合に有効です この構成例では 次の表に示す名前を使用しています データベース DB_UNIQUE_NAME Oracle Net サービス名 プライマリ chicago chicago フィジカル スタンバイ boston boston 例 3-3 プライマリ データベース : プライマリ ロールの初期化パラメータ DB_NAME=chicago DB_UNIQUE_NAME=chicago LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)' CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_2= 'SERVICE=boston LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE LOG_ARCHIVE_FORMAT=%t_%s_%r.arc LOG_ARCHIVE_MAX_PROCESSES=30 これらのパラメータは REDO 転送サービスが REDO データをスタンバイ システムに転送する方法と ローカル ファイル システムでの REDO データのアーカイブ処理を制御します 例では LGWR プロセスと LOG_ARCHIVE_DEST_2 初期化パラメータ上で REDO データを転送する非同期 (ASYNC) ネットワーク転送を指定します これらは推奨設定であり スタンバイ REDO ログ ファイルが必要です (3-3 ページの 項 スタンバイ REDO ログの構成 を参照 ) 例 3-4 に プライマリ データベースで定義するスタンバイ ロールの追加の初期化パラメータを示します これらのパラメータは プライマリ データベースがスタンバイ ロールに推移すると有効になります 例 3-4 プライマリ データベース : スタンバイ ロールの初期化パラメータ FAL_SERVER=boston FAL_CLIENT=chicago DB_FILE_NAME_CONVERT='boston','chicago' LOG_FILE_NAME_CONVERT= '/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/' STANDBY_FILE_MANAGEMENT=AUTO 例 3-4 に示す初期化パラメータを指定すると プライマリ データベースはギャップを解決して新しいプライマリ データベースからの新規データファイルとログ ファイルのパス名を変換するように設定され このデータベースがスタンバイ ロールで動作している間は着信 フィジカル スタンバイ データベースの作成 3-5

60 スタンバイ データベースを作成するためのプライマリ データベースの準備 REDO データがアーカイブされます 説明に従ってプライマリおよびスタンバイ ロールについて初期化パラメータを設定した場合 ロールの推移後に変更が必要なパラメータはありません 次の表に 例 3-3 および例 3-4 に示した各パラメータ設定に関する簡単な説明を示します パラメータ DB_NAME DB_UNIQUE_NAME LOG_ARCHIVE_CONFIG CONTROL_FILES LOG_ARCHIVE_DEST_n LOG_ARCHIVE_DEST_STATE_n REMOTE_LOGIN_PASSWORDFILE LOG_ARCHIVE_FORMAT LOG_ARCHIVE_MAX_PROCESSES =integer FAL_SERVER 推奨する設定 8 文字の名前を指定します すべてのスタンバイ データベースに同じ名前を使用してください 各データベースの一意の名前を指定します この名前はデータベースと固定され プライマリ データベースとスタンバイ データベースのロールが逆になっても変更されません このパラメータの DG_CONFIG 属性を指定して Data Guard 構成のプライマリ データベースとスタンバイ データベースの DB_UNIQUE_NAME をリストすると Real Application Clusters プライマリ データベースが最大保護モードまたは最大可用性モードで稼働している Data Guard 構成に スタンバイ データベースを動的に追加できます デフォルトでは LOG_ARCHIVE_CONFIG パラメータを指定すると データベースは REDO を送受信できます ロールの推移後は SEND NOSEND RECEIVE または NORECEIVE キーワードを使用して これらの設定を再指定する操作が必要になることがあります プライマリ データベースの制御ファイルのパス名を指定します 例 3-3 は 2 つの制御ファイルのパス名を指定する方法を示しています 不良制御ファイルの位置に正常な制御ファイルをコピーした後でインスタンスを簡単に再起動できるように 制御ファイルの第 2 コピーを使用可能にしておくことをお薦めします REDO データがアーカイブされるプライマリ システムおよびスタンバイ システムの位置を指定します 例 3-3 では 次のようになっています LOG_ARCHIVE_DEST_1 と指定すると プライマリ データベースにより生成された REDO データは ローカルのオンライン REDO ログ ファイルから /arch1/chicago/ にあるローカルのアーカイブ REDO ログ ファイルにアーカイブされます LOG_ARCHIVE_DEST_2 は プライマリ ロールにのみ有効です この宛先を指定すると REDO データはリモート フィジカル スタンバイ宛先 boston に転送されます 注意 : フラッシュ リカバリ領域を (DB_RECOVERY_FILE_DEST 初期化パラメータを使用して ) 構成しており LOCATION 属性でローカル アーカイブ先を明示的に構成していない場合は デフォルトのローカル アーカイブ先として LOG_ ARCHIVE_DEST_10 初期化パラメータが自動的に使用されます 詳細は 項を参照してください また LOG_ARCHIVE_DEST_n の詳細は 第 14 章を参照してください REDO 転送サービスが REDO データを指定した宛先に転送するのを許可するには ENABLE を指定します プライマリ データベースとスタンバイ データベースの両方で SYS に同じパスワードを設定します 推奨する設定は EXCLUSIVE または SHARED です スレッド (%t) 順序番号 (%s) およびリセットログ ID(%r) を使用して アーカイブ REDO ログ ファイルのフォーマットを指定します もう 1 つの例については 項を参照してください Oracle ソフトウェアが最初に起動するアーカイバ (ARCn) プロセスの最大数 (1 ~ 30) を指定します デフォルト値は 4 です ARCn 処理の詳細は 項を参照してください FAL サーバー ( 通常はプライマリ ロールで実行中のデータベース ) の Oracle Net サービス名を指定します シカゴのデータベースがスタンバイ ロールで実行されている場合 ボストンのデータベースが欠落しているログ ファイルを自動的に送信できなければ ボストンのデータベースが FAL サーバーとして使用され そこから欠落しているアーカイブ REDO ログ ファイルがフェッチ ( 要求 ) されます 5.8 項を参照してください 3-6 Oracle Data Guard 概要および管理

61 スタンバイ データベースを作成するためのプライマリ データベースの準備 パラメータ FAL_CLIENT DB_FILE_NAME_CONVERT LOG_FILE_NAME_CONVERT STANDBY_FILE_MANAGEMENT 推奨する設定 シカゴのデータベースの Oracle Net サービス名を指定します FAL サーバー ( ボストン ) は 欠落しているアーカイブ REDO ログ ファイルをシカゴのスタンバイ データベースにコピーします 5.8 項を参照してください プライマリ データベースのデータファイルのパス名とファイル名の位置を指定し その後にスタンバイの位置を指定します このパラメータにより プライマリ データベースのデータファイルのパス名がスタンバイ データファイルのパス名に変換されます スタンバイ データベースがプライマリ データベースと同じシステムにある場合 またはデータファイルが格納されているスタンバイ サイトのディレクトリ構造がプライマリ サイトと異なる場合は このパラメータが必要です このパラメータは フィジカル スタンバイ データベースのパス名の変換にのみ使用されることに注意してください このパラメータにより 複数のペアのパスを指定できます プライマリ データベースのオンライン REDO ログ ファイルの位置を指定し その後にスタンバイの位置を指定します このパラメータにより プライマリ データベースのログ ファイルのパス名がスタンバイ データベースのパス名に変換されます スタンバイ データベースがプライマリ データベースと同じシステムにある場合 またはログ ファイルが格納されているスタンバイ システムのディレクトリ構造がプライマリ システムと異なる場合は このパラメータが必要です このパラメータにより 複数のペアのパスを指定できます データファイルがプライマリ データベースに追加または削除された場合に それに対応してスタンバイ データベースも自動的に変更されるように AUTO に設定します 注意 : 変更の必要性がある他のパラメータについては 初期化パラメータ ファイルを調べてください たとえば ダンプ出力先パラメータ (BACKGROUND_DUMP_DEST CORE_DUMP_DEST USER_DUMP_DEST) の変更が必要な場合があります これは スタンバイ データベースのディレクトリ位置がプライマリ データベースで指定したディレクトリ位置と異なる場合に必要です さらに スタンバイ システムにまだ存在していないディレクトリがある場合は そのディレクトリを作成する必要があります アーカイブの有効化 アーカイブが有効になっていない場合は 次の文を発行して プライマリ データベースを ARCHIVELOG モードにし 自動アーカイブを有効にします SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE ARCHIVELOG; SQL> ALTER DATABASE OPEN; アーカイブについては Oracle Database 管理者ガイド を参照してください フィジカル スタンバイ データベースの作成 3-7

62 フィジカル スタンバイ データベースの作成手順 3.2 フィジカル スタンバイ データベースの作成手順 この項では フィジカル スタンバイ データベースの作成で実行するタスクについて説明します 表 3-2 は フィジカル スタンバイ データベースの作成で実行するタスク および各タスクを実行するデータベースのチェックリストです 各タスクを詳細に説明している参照先の項も記載されています 表 3-2 フィジカル スタンバイ データベースの作成 参照先 タスク データベース 項プライマリ データベース データファイルのバックアップ コピーの作成プライマリ 項スタンバイ データベース用の制御ファイルの作成プライマリ 項スタンバイ データベース用の初期化パラメータ ファイルの準備プライマリ 項プライマリ システムからスタンバイ システムへのファイルのコピープライマリ 項スタンバイ データベースをサポートする環境の設定スタンバイ 項フィジカル スタンバイ データベースの起動スタンバイ 項フィジカル スタンバイ データベースが正しく実行されているかどうかの確認スタンバイ プライマリ データベース データファイルのバックアップ コピーの作成 データベースを完全にリカバリするのに必要なアーカイブ REDO ログ ファイルがあるかぎり プライマリ データベースのバックアップ コピーを使用して フィジカル スタンバイ データベースを作成できます Recovery Manager(RMAN) ユーティリティを使用することをお薦めします バックアップの推奨事項は Oracle 高可用性アーキテクチャおよびベスト プラクティス を RMAN バックアップ操作の実行方法については Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください スタンバイ データベース用の制御ファイルの作成 バックアップ処理のために プライマリ データベースを停止する必要がある場合は 次の SQL*Plus 文を発行して プライマリ データベースを起動します SQL> STARTUP MOUNT; スタンバイ データベース用の制御ファイルを作成してから ユーザー アクセス用にプライマリ データベースをオープンします 次に例を示します SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/boston.ctl'; SQL> ALTER DATABASE OPEN; 注意 : プライマリ データベースとスタンバイ データベースの両方に単一の制御ファイルを使用することはできません 3-8 Oracle Data Guard 概要および管理

63 フィジカル スタンバイ データベースの作成手順 スタンバイ データベース用の初期化パラメータ ファイルの準備 次の手順を実行して スタンバイの初期化パラメータ ファイルを作成します 手順 1 スタンバイ データベースにプライマリ データベース パラメータ ファイルをコピーするプライマリ データベースで使用されているサーバー パラメータ ファイル (SPFILE) から テキストの初期化パラメータ ファイル (PFILE) を作成します テキストの初期化パラメータ ファイルは スタンバイの位置にコピーして変更できます 次に例を示します SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE; このファイルを変更して フィジカル スタンバイ データベースでの使用に適したパラメータ値を含めます このファイルは 後述の 項で サーバー パラメータ ファイルに変換し直します 手順 2 フィジカル スタンバイ データベースで初期化パラメータを設定するプライマリ システムからコピーしたテキストの初期化パラメータ ファイルの初期化パラメータ設定の多くは フィジカル スタンバイ データベースにも適していますが 一部を変更する必要があります 例 3-5 は スタンバイの初期化パラメータ ファイルの一部です この中の値は フィジカル スタンバイ データベース用に変更されています 例 3-3 および例 3-4 と異なるパラメータ値は 太字で示されています 例 3-5 に示すパラメータは ボストンのデータベースがプライマリ データベース ロールまたはスタンバイ データベース ロールで実行されている場合に有効です 例 3-5 フィジカル スタンバイ データベース用の初期化パラメータを変更する... DB_NAME=chicago DB_UNIQUE_NAME=boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)' CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl' DB_FILE_NAME_CONVERT='chicago','boston' LOG_FILE_NAME_CONVERT= '/arch1/chicago/','/arch1/boston/','/arch2/chicago/','/arch2/boston/' LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=chicago LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE STANDBY_FILE_MANAGEMENT=AUTO FAL_SERVER=chicago FAL_CLIENT=boston... 例では LOG_ARCHIVE_DEST_2 初期化パラメータのローカルおよびリモート両方の宛先に REDO データを転送するのに LGWR プロセスを使用することを前提としています フィジカル スタンバイ データベースの作成 3-9

64 フィジカル スタンバイ データベースの作成手順 また プライマリ データベースとスタンバイ データベースでは COMPATIBLE 初期化パラメータを同じ値に設定する必要があります 値が異なる場合は REDO 転送サービスが REDO データをプライマリ データベースからスタンバイ データベースに転送できないことがあります Data Guard 構成では COMPATIBLE を少なくとも に設定する必要があります ただし Oracle Database 10g の新機能を利用する場合は COMPATIBLE パラメータを 以上に設定します SHOW PARAMETERS コマンドを使用して 他に変更を必要とするパラメータがないかどうかを確認することをお薦めします 次の表に 例 3-5 のうち プライマリ データベースの設定と異なるパラメータ設定に関する簡単な説明を示します パラメータ DB_UNIQUE_NAME CONTROL_FILES DB_FILE_NAME_CONVERT LOG_FILE_NAME_CONVERT LOG_ARCHIVE_DEST_n FAL_SERVER FAL_CLIENT 推奨する設定 このデータベースの一意の名前を指定します この名前はデータベースと固定され プライマリ データベースとスタンバイ データベースのロールが逆になっても変更されません スタンバイ データベースの制御ファイルのパス名を指定します 例 3-5 は 2 つの制御ファイルのパス名を指定する方法を示しています 不良制御ファイルの位置に正常な制御ファイルをコピーした後でインスタンスを簡単に再起動できるように 制御ファイルの第 2 コピーを使用可能にしておくことをお薦めします プライマリ データベースのデータファイルのパス名とファイル名の位置を指定し その後にスタンバイの位置を指定します このパラメータにより プライマリ データベースのデータファイルのパス名がスタンバイ データファイルのパス名に変換されます スタンバイ データベースがプライマリ データベースと同じシステムにある場合 またはデータファイルが格納されているスタンバイ サイトのディレクトリ構造がプライマリ サイトと異なる場合は このパラメータが必要です プライマリ データベースのオンライン REDO ログ ファイルの位置を指定し その後にスタンバイの位置を指定します このパラメータにより プライマリ データベースのログ ファイルのパス名がスタンバイ データベースのパス名に変換されます スタンバイ データベースがプライマリ データベースと同じシステムにある場合 またはログ ファイルが格納されているスタンバイ システムのディレクトリ構造がプライマリ システムと異なる場合は このパラメータが必要です REDO データのアーカイブ先を指定します 例 3-5 では 次のようになっています LOG_ARCHIVE_DEST_1 を指定すると プライマリ データから受信した REDO データは /arch1/boston/ のアーカイブ REDO ログ ファイルにアーカイブされます LOG_ARCHIVE_DEST_2 はプライマリ ロールのみに有効であるため この宛先は現在は無視されます スイッチオーバーが発生して このインスタンスがプライマリ データベースになる場合は REDO データがリモートのシカゴの宛先に転送されます 注意 : フラッシュ リカバリ領域を (DB_RECOVERY_FILE_DEST 初期化パラメータを使用して ) 構成しており LOCATION 属性でローカル アーカイブ先を明示的に構成していない場合は デフォルトのローカル アーカイブ先として LOG_ ARCHIVE_DEST_10 初期化パラメータが自動的に使用されます 詳細は 項を参照してください また LOG_ARCHIVE_DEST_n の詳細は 第 14 章を参照してください FAL サーバー ( 通常はプライマリ ロールで実行中のデータベース ) の Oracle Net サービス名を指定します ボストンのデータベースがスタンバイ ロールで実行されている場合 シカゴのデータベースが欠落しているログ ファイルを自動的に送信できなければ シカゴのデータベースが FAL サーバーとして使用され そこから欠落しているアーカイブ REDO ログ ファイルがフェッチ ( 要求 ) されます 5.8 項を参照してください ボストンのデータベースの Oracle Net サービス名を指定します FAL サーバー ( シカゴ ) は 欠落しているアーカイブ REDO ログ ファイルをボストンのスタンバイ データベースにコピーします 5.8 項を参照してください 3-10 Oracle Data Guard 概要および管理

65 フィジカル スタンバイ データベースの作成手順 注意 : 変更の必要性がある他のパラメータについては 初期化パラメータ ファイルを調べてください たとえば ダンプ出力先パラメータ (BACKGROUND_DUMP_DEST CORE_DUMP_DEST USER_DUMP_DEST) の変更が必要な場合があります これは スタンバイ データベースのディレクトリ位置がプライマリ データベースで指定したディレクトリ位置と異なる場合に必要です さらに スタンバイ システムにまだ存在していないディレクトリがある場合は そのディレクトリを作成する必要があります プライマリ システムからスタンバイ システムへのファイルのコピー オペレーティング システムのコピー ユーティリティを使用して 次のバイナリ ファイルをプライマリ システムからスタンバイ システムにコピーします 項で作成したバックアップ データファイル 項で作成したスタンバイ制御ファイル 項で作成した初期化パラメータ ファイル スタンバイ データベースをサポートする環境の設定 次の手順を実行して Windows ベース サービスの作成 パスワード ファイルの作成 Oracle Net 環境の設定および SPFILE の作成を行います 手順 1 Windows ベース サービスを作成するスタンバイ システムが Windows ベース システムで実行されている場合は ORADIM ユーティリティを使用して Windows サービスとパスワード ファイルを作成します 次に例を示します WINNT> oradim -NEW -SID boston -INTPWD password -STARTMODE manual ORADIM ユーティリティの使用方法の詳細は Oracle Database プラットフォーム ガイド を参照してください 手順 2 パスワード ファイルを作成する Windows 以外のプラットフォーム上では パスワード ファイルを作成して SYS ユーザーのパスワードを プライマリ データベースの SYS ユーザーが使用するのと同じパスワードに設定します Data Guard 構成内のすべてのデータベースで SYS ユーザーのパスワードは REDO データを正常に転送するために同じにする必要があります Oracle Database 管理者ガイド を参照してください 手順 3 プライマリ データベースとスタンバイ データベースに対するリスナーを構成するプライマリ サイトとスタンバイ サイトの両方で Oracle Net Manager を使用して 各データベースに対するリスナーを構成します リスナーを再起動して新しい定義を読み込むには プライマリ システムとスタンバイ システムの両方で次の LSNRCTL ユーティリティ コマンドを入力します % lsnrctl stop % lsnrctl start Oracle Database Net Services 管理者ガイド を参照してください フィジカル スタンバイ データベースの作成 3-11

66 フィジカル スタンバイ データベースの作成手順 手順 4 Oracle Net サービス名を作成するプライマリ システムとスタンバイ システムの両方で Oracle Net Manager を使用して プライマリ データベースとスタンバイ データベースのネットワーク サービス名を作成します ネットワーク サービス名は REDO 転送サービスで使用されます Oracle Net ネット サービス名は プライマリ データベースとスタンバイ データベースに対するリスナーの構成時に指定したものと同じプロトコル ホスト アドレス ポートおよびサービスを使用する接続記述子に解析される必要があります この接続記述子は 専用サーバーが使用されるように指定する必要もあります Oracle Database Net Services 管理者ガイド および Oracle Database 管理者ガイド を参照してください 手順 5 スタンバイ データベース用のサーバー パラメータ ファイルを作成するフィジカル スタンバイ データベースからロジカル スタンバイ データベースに即時に推移する場合は ( 第 4 章 ロジカル スタンバイ データベースの作成 を参照 ) この手順をスキップして 項の指示に進みます アイドル状態のスタンバイ データベースで SQL の CREATE 文を使用して 3-9 ページの手順 2 で編集したテキストの初期化パラメータ ファイルから スタンバイ データベース用のサーバー パラメータ ファイルを作成します 次に例を示します SQL> CREATE SPFILE FROM PFILE='initboston.ora'; フィジカル スタンバイ データベースの起動 フィジカル スタンバイ データベースおよび REDO Apply を起動するには 次の手順を実行します 手順 1 フィジカル スタンバイ データベースを起動するスタンバイ データベースで 次の SQL 文を発行してデータベースを起動およびマウントします SQL> STARTUP MOUNT; 手順 2 REDO Apply を開始するスタンバイ データベースで 次のコマンドを発行して REDO Apply を開始します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; この文には DISCONNECT FROM SESSION オプションが指定されているため REDO Apply はバックグラウンド セッションで実行されます 詳細は 6.3 項 REDO データのフィジカル スタンバイ データベースへの適用 を参照してください 手順 3 フィジカル スタンバイ データベースへのアーカイブ操作をテストするこの例では リモート スタンバイ ロケーションへの REDO データの転送は ログ スイッチ後まで行われません デフォルトでは ログ スイッチはオンライン REDO ログ ファイルがいっぱいになったときに発生します REDO データを即時に転送するためにログ スイッチを強制実行するには プライマリ データベースで次の ALTER SYSTEM 文を使用します 次に例を示します SQL> ALTER SYSTEM SWITCH LOGFILE; 3-12 Oracle Data Guard 概要および管理

67 フィジカル スタンバイ データベースの作成手順 フィジカル スタンバイ データベースが正しく実行されているかどうかの確認 フィジカル スタンバイ データベースを作成して REDO 転送サービスを設定した後 データベースの変更がプライマリ データベースからスタンバイ データベースに正常に転送されているかどうかの確認が必要な場合があります スタンバイ データベースで REDO データが受信されていることを確認するには 最初に スタンバイ データベースの既存のアーカイブ REDO ログ ファイルを識別し ログ スイッチを強制実行して プライマリ データベースのオンライン REDO ログ ファイルをいくつかアーカイブし スタンバイ データベースを再度チェックする必要があります このタスクの実行手順を次に示します 手順 1 既存のアーカイブ REDO ログ ファイルを識別するスタンバイ データベースで V$ARCHIVED_LOG ビューを問い合せて アーカイブ REDO ログの既存のファイルを識別します 次に例を示します SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME 2 FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#; SEQUENCE# FIRST_TIME NEXT_TIME JUL-02 17:50:45 11-JUL-02 17:50: JUL-02 17:50:53 11-JUL-02 17:50: JUL-02 17:50:58 11-JUL-02 17:51:03 3 rows selected. 手順 2 ログ スイッチを強制実行してカレント オンライン REDO ログ ファイルをアーカイブするプライマリ データベースで ALTER SYSTEM SWITCH LOGFILE 文を発行して ログ スイッチを強制実行し カレント オンライン REDO ログ ファイル グループをアーカイブします SQL> ALTER SYSTEM SWITCH LOGFILE; 手順 3 新しい REDO データがスタンバイ データベースでアーカイブされたことを確認するスタンバイ データベースで V$ARCHIVED_LOG ビューを問い合せて スタンバイ データベースで REDO データが受信およびアーカイブされたことを確認します SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME 2> FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#; SEQUENCE# FIRST_TIME NEXT_TIME JUL-02 17:50:45 11-JUL-02 17:50: JUL-02 17:50:53 11-JUL-02 17:50: JUL-02 17:50:58 11-JUL-02 17:51: JUL-02 17:51:03 11-JUL-02 18:34:11 4 rows selected. アーカイブ REDO ログ ファイルは フィジカル スタンバイ データベースに適用できます フィジカル スタンバイ データベースの作成 3-13

68 作成後の手順 手順 4 新規アーカイブ REDO ログ ファイルの適用を確認するスタンバイ データベースで V$ARCHIVED_LOG ビューを問い合せて アーカイブ REDO ログ ファイルが適用されたことを確認します SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG 2 ORDER BY SEQUENCE#; SEQUENCE# APP YES 9 YES 10 YES 11 YES 4 rows selected. ログ転送サービスとログ適用サービスが正常に動作しているかどうかの確認方法は 項 ログ ファイル アーカイブ情報の監視 および 項 フィジカル スタンバイ データベースでのログ適用サービスの監視 を参照してください 3.3 作成後の手順 この時点で フィジカル スタンバイ データベースが実行中であり 最大パフォーマンス レベルのデータ保護を提供できます 次のリストに フィジカル スタンバイ データベースに対して実行できるその他の準備について説明します データ保護モードのアップグレード Data Guard 構成は 最初は最大パフォーマンス モード ( デフォルト ) で設定されます データ保護モードの詳細と現行の保護モードをアップグレードまたはダウングレードする方法は 5.6 項を参照してください フラッシュバック データベースの有効化 フラッシュバック データベースにより フェイルオーバー後のプライマリ データベースの再作成の必要がなくなります フラッシュバック データベースは従来の Point-in-Time リカバリと同様の機能で データベースを過去の最新時点の状態に戻すことができます フラッシュバック データベースでは データファイルをバックアップからリストアしたり REDO データを広範囲に適用する必要がないため Point-in-Time リカバリよりも高速です フラッシュバック データベースは プライマリ データベースまたはスタンバイ データベース あるいはその両方で有効化できます Data Guard 環境でのフラッシュバック データベースの使用例は 12.4 項および 12.5 項を参照してください フラッシュバック データベースの詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください 3-14 Oracle Data Guard 概要および管理

69 4 ロジカル スタンバイ データベースの作成 この章では ロジカル スタンバイ データベースを作成する手順について説明します この章は 次の主な項目で構成されています ロジカル スタンバイ データベースの作成要件 ロジカル スタンバイ データベースの作成手順 作成後の手順 関連項目 : サーバー パラメータ ファイルの作成方法と使用方法は Oracle Database 管理者ガイド を参照してください グラフィカル ユーザー インタフェースを使用してロジカル スタンバイ データベースを自動的に作成する方法は Oracle Data Guard Broker および Oracle Enterprise Manager のオンライン ヘルプを参照してください ロジカル スタンバイ データベースの作成 4-1

70 ロジカル スタンバイ データベースの作成要件 4.1 ロジカル スタンバイ データベースの作成要件 ロジカル スタンバイ データベースを作成する前に プライマリ データベースが正しく構成されていることを最初に確認する必要があります 表 4-1 は ロジカル スタンバイ データベースを作成するための準備としてプライマリ データベースで実行するタスクのチェックリストです 各タスクを詳細に説明している参照先の項も記載されています 表 4-1 ロジカル スタンバイ データベースを作成するためのプライマリ データベースの準備 参照先 タスク 項表のデータ型および記憶域属性のサポートの判別 項プライマリ データベース内の表の行が一意に識別できることの確認 表のデータ型および記憶域属性のサポートの判別 ロジカル スタンバイ データベースを設定する前に ロジカル スタンバイ データベースが プライマリ データベースのデータ型と表をメンテナンスできることを確認する必要があります データ型および記憶域型に関する考慮事項の詳細リストは 付録 C を参照してください プライマリ データベース内の表の行が一意に識別できることの確認 ロジカル スタンバイ データベースがプライマリ データベースのバックアップ コピーから作成されていても ロジカル スタンバイ データベースの物理的な構成は プライマリ データベースの構成とは異なります そのため プライマリ データベースによって生成された REDO レコードに含まれている ROWID は ロジカル スタンバイ データベース内の対応する行を識別するためには使用できません Oracle では ロジカル スタンバイ データベース内の変更された行をロジカルに識別するために 主キーまたは一意索引サプリメンタル ロギングを使用します また データベース全体の主キーおよび一意索引サプリメンタル ロギングが使用可能になると 各 UPDATE 文により ロジカル スタンバイ データベース内の変更された行を一意に識別するために REDO ログに必要な列の値が書き込まれます 表に主キーが定義されている場合 主キーは変更された行を識別するために UPDATE 文の一部としてログに記録されます 主キーがない場合 一番短く NULL 値が許容されていない一意キーが 変更された行を識別するために UPDATE 文の一部としてログに記録されます 主キーも NULL 値が許容されていない一意キーもない場合 バインドされているサイズのすべての列が 変更された行を識別するために UPDATE 文の一部としてログに記録されます つまり LONG LOB LONG ROW オブジェクト型およびコレクション以外のすべての列が ログに記録されます SQL Apply で REDO データの更新をロジカル スタンバイ データベースに効率的に適用できるように 適切で可能な場合には 必ずプライマリ データベースの表に主キーまたは NULL 値が許容されていない一意索引を追加することをお薦めします 4-2 Oracle Data Guard 概要および管理

71 ロジカル スタンバイ データベースの作成要件 ロジカル スタンバイ データベース内のレプリケートされている各表の行を SQL Apply によって一意に識別できるかどうかを確認するには 次の手順を実行します 手順 1 プライマリ データベース内の一意ロジカル識別子のない表を検索する SQL Apply で一意に識別できない可能性がある表のリストを表示するには DBA_LOGSTDBY_ NOT_UNIQUE ビューを問い合せます 次に例を示します SQL> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE 2> WHERE (OWNER, TABLE_NAME) NOT IN 3> (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED) 4> AND BAD_COLLUMN = 'Y' 手順 2 無効化された RELY 主キー制約を追加するアプリケーションで 表内の行が一意であることが保証される場合は 表に無効化された RELY 主キー制約を作成できます これによって プライマリ データベースでの主キーのメンテナンスに関するオーバーヘッドを回避できます 無効化された RELY 制約をプライマリ データベース表に作成するには RELY DISABLE 句を指定して ALTER TABLE 文を使用します 次の例では 無効化された RELY 制約が mytab という表に作成されます 各行は id 列と name 列を使用して一意に識別されます SQL> ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE; RELY 制約を指定すると システムでは行が一意であると仮定されます システムには情報に依存するように指示を出しますが 表が変更されるたびに検証は行わないため 表内の各行を一意に識別する RELY 制約が無効化されている場合は 十分に注意して列を選択する必要があります このような一意性が存在しない場合 SQL Apply による表のメンテナンスが正しく行われません SQL Apply のパフォーマンスを改善するには ロジカル スタンバイ データベースで行を一意に識別する列に索引を追加します 追加できない場合は SQL Apply によって表上で UPDATE または DELETE 文を実行中に 全表スキャンが実行されます 関連項目 : DBA_LOGSTDBY_NOT_UNIQUE ビューの詳細は Oracle Database リファレンス を参照してください ALTER TABLE 文の構文および RELY 制約の作成の詳細は Oracle Database SQL リファレンス を参照してください RELY 制約およびロジカル スタンバイ データベース上でパフォーマンスを向上させるために行うことができる処理の詳細は 9-23 ページの 項 主キー RELY 制約の作成 を参照してください ロジカル スタンバイ データベースの作成 4-3

72 ロジカル スタンバイ データベースの作成手順 4.2 ロジカル スタンバイ データベースの作成手順 この項では ロジカル スタンバイ データベースの作成で実行するタスクについて説明します 表 4-2 は ロジカル スタンバイ データベースの作成で実行するタスクのチェックリストで 各タスクを実行するデータベースを指定します 各タスクを詳細に説明している参照先の項も記載されています 表 4-2 ロジカル スタンバイ データベースの作成 参照先 タスク データベース 項フィジカル スタンバイ データベースの作成プライマリ 項フィジカル スタンバイ データベースでの REDO Apply の停止スタンバイ 項ロジカル スタンバイ データベースをサポートするためのプライマリ データベースの準備 プライマリ 項ロジカル スタンバイ データベースへの推移スタンバイ 項ロジカル スタンバイ データベースのオープンスタンバイ 項ロジカル スタンバイ データベースが正しく実行されているかどうかの確認スタンバイ フィジカル スタンバイ データベースの作成 ロジカル スタンバイ データベースを作成するには 次のように最初にフィジカル スタンバイ データベースを作成してから ロジカル スタンバイ データベースへと推移させます 第 3 章 フィジカル スタンバイ データベースの作成 の指示に従ってフィジカル スタンバイ データベースを作成します フィジカル スタンバイ データベースでの REDO Apply の停止 ロジカル スタンバイ データベースに変換する前に 実行時間に関係なく 新規フィジカル スタンバイ データベースで REDO Apply を実行できます ただし ロジカル スタンバイ データベースに変換する前に フィジカル スタンバイ データベースで REDO Apply を停止する必要があります REDO Apply の停止は LogMiner ディクショナリを含む REDO の後に変更が適用されることを避けるために必要です (4-6 ページの 項 REDO データでのディクショナリの構築 で説明 ) REDO Apply を停止するには フィジカル スタンバイ データベースで次の文を発行します データベースが複数のインスタンスから構成される RAC データベースの場合 この文を発行する前に 最初にインスタンスの数を 1 に削減する必要があります SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 4-4 Oracle Data Guard 概要および管理

73 ロジカル スタンバイ データベースの作成手順 この項は 次の項目で構成されています ロールの推移のためのプライマリ データベースの準備 REDO データでのディクショナリの構築 ロールの推移のためのプライマリ データベースの準備 3-5 ページの 項 プライマリ データベースの初期化パラメータの設定 では プライマリ データベースがフィジカル スタンバイ ロールに推移する場合に有効になるように 複数のスタンバイ ロールの初期化パラメータを設定しました プライマリ データベースをロジカル スタンバイ ロールに推移させる場合は ロールの推移後にパラメータを変更せずにすむように プライマリ データベースに例 4-1 に示す LOG_ARCHIVE_DEST_3 宛先を含める必要があります このパラメータは プライマリ データベースがスタンバイ ロールに推移したときにのみ有効になります 例 4-1 プライマリ データベース : ロジカル スタンバイ ロールの初期化パラメータ LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/chicago/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_STATE_3=ENABLE LOG_ARCHIVE_DEST_3 パラメータを動的に設定するには SQL ALTER SYSTEM SET 文を使用し 変更が即時に有効になってデータベースを停止して再起動した後も存続するように SCOPE=BOTH 句を指定します 次の表に 例 4-1 に示した初期化パラメータで定義されるアーカイブ プロセスを示します LOG_ARCHIVE_DEST_3 無視 LOG_ARCHIVE_DEST_3 は chicago がスタンバイ ロールで稼働している場合にのみ有効 ロジカル スタンバイ データベースをサポートするためのプライマリ データベースの準備 シカゴのデータベースがプライマリ ロールで稼働している場合 シカゴのデータベースがロジカル スタンバイ ロールで稼働している場合 /arch2/chicago/ 内のローカル アーカイブ REDO ログ ファイルにプライマリ データベースから受信した REDO データをアーカイブ ロジカル スタンバイ データベースの作成 4-5

74 ロジカル スタンバイ データベースの作成手順 REDO データでのディクショナリの構築 LogMiner ディクショナリは SQL Apply の LogMiner コンポーネントによって REDO での変更が適切に解釈できるように REDO データに構築される必要があります また サプリメンタル ロギングを設定して 主キーおよび一意索引の列がログに記録されるようにします サプリメンタル ロギング情報により 各更新に 文によって変更された各行をロジカルに識別するための十分な情報が含まれていることが保証されます LogMiner ディクショナリを構築するには 次の文を発行します SQL> EXECUTE DBMS_LOGSTDBY.BUILD; DBMS_LOGSTDBY.BUILD プロシージャでは 既存のトランザクションがすべて完了するのを待機します プライマリ データベースで長時間実行されているトランザクションは このコマンドの適時性に影響を与えます DBMS_LOGSTDBY.BUILD プロシージャでは フラッシュバック問合せを使用して REDO ストリームにログが記録されるデータ ディクショナリの一貫性のあるスナップショットを取得します プライマリ データベースおよびロジカル スタンバイ データベースの両方で UNDO_RETENTION 初期化パラメータを 3600 に設定することをお薦めします 関連項目 : Oracle Database PL/SQL パッケージ プロシージャおよびタイプ リファレンス の DBMS_LOGSTDBY.BUILD PL/SQL パッケージおよび Oracle Database リファレンス の UNDO_RETENTION 初期化パラメータ ロジカル スタンバイ データベースへの推移 この項では ロジカル スタンバイ データベースに推移するために フィジカル スタンバイ データベースを準備する方法について説明します この章は 次の項目で構成されています ロジカル スタンバイ データベースへの変換 新規パスワード ファイルの作成 ロジカル スタンバイ データベース用の初期化パラメータの調整 ロジカル スタンバイ データベースへの変換 REDO ログには フィジカル スタンバイ データベースをロジカル スタンバイ データベースに変換するために必要な情報が含まれています ロジカル スタンバイ データベースへの変換準備が完了するまで REDO データをフィジカル スタンバイ データベースに適用し続けるには 次の SQL 文を発行します SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY new-db_name; この文では ログ ファイル内に LogMiner ディクショナリが見つかるまで REDO データを適用しながら待機します 項 REDO データでのディクショナリの構築 に生成された REDO がスタンバイ データベースに推移されるのにかかる時間と 適用する必要のある REDO データの量にもよりますが この作業には数分かかります プライマリ データベースでディクショナリ構築が正常に実行されるまで このコマンドは完了しません SQL 文を取り消すには 別の SQL セッションから ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL 文を発行します 新規パスワード ファイルの作成 変換プロセスにより ロジカル スタンバイ データベース用のデータベース名 (DB_NAME 初期化パラメータを使用して最初に設定したデータベース名 ) が変更されるため パスワード ファイルを再作成する必要があります 詳細は Oracle Database 管理者ガイド を参照してください 4-6 Oracle Data Guard 概要および管理

75 ロジカル スタンバイ データベースの作成手順 ロジカル スタンバイ データベース用の初期化パラメータの調整 ロジカル スタンバイ データベースで STARTUP MOUNT 文を発行してデータベースを起動およびマウントします データベースをオープンしないでください 後続の作成プロセスまで データベースはユーザー アクセスに対してクローズの状態のままにしておく必要があります 次に例を示します SQL> STARTUP MOUNT; LOG_ARCHIVE_DEST_n パラメータを変更する必要があります これは フィジカル スタンバイ データベースとは異なり ロジカル スタンバイ データベースは REDO データを生成するオープン データベースであり 複数のログ ファイル ( オンライン REDO ログ ファイル アーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイル ) があるためです 次のものに対し 別々のローカル宛先を指定することをお薦めします ロジカル スタンバイ データベースで生成された REDO データを格納するアーカイブ REDO ログ ファイル 例 4-2 では LOG_ARCHIVE_DEST_1=LOCATION=/arch1/ boston 宛先として構成されています プライマリ データベースから受信した REDO データを格納するアーカイブ REDO ログ ファイル 例 4-2 では LOG_ARCHIVE_DEST_3=LOCATION=/arch2/boston 宛先として構成されています 例 4-2 に ロジカル スタンバイ データベース用に変更された初期化パラメータを示します 各パラメータは ボストンのロジカル スタンバイ データベースがプライマリ データベース ロールまたはスタンバイ データベース ロールで実行されている場合に有効です 例 4-2 ロジカル スタンバイ データベース用の初期化パラメータの変更 LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=chicago LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/boston/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE 次の表に 例 4-2 に示した初期化パラメータで定義されるアーカイブ プロセスを示します LOG_ARCHIVE_DEST_1 /arch1/boston/ 内のローカル アーカイブ REDO ログ ファイルにローカル オンライン REDO ログ ファイルからプライマリ データベースによって生成された REDO データをアーカイブするよう指示 LOG_ARCHIVE_DEST_2 リモート ロジカル スタンバイ データベース chicago に REDO データを転送するよう指示 LOG_ARCHIVE_DEST_3 無視 LOG_ARCHIVE_DEST_3 は boston がスタンバイ ロールで稼働している場合にのみ有効 ボストンのデータベースがプライマリ ロールで稼働している場合 ボストンのデータベースがロジカル スタンバイ ロールで稼働している場合 /arch1/boston/ 内のローカル アーカイブ REDO ログ ファイルにローカル オンライン REDO ログ ファイルからロジカル スタンバイ データベースによって生成された REDO データをアーカイブするよう指示 無視 LOG_ARCHIVE_DEST_2 は boston がプライマリ ロールで稼働している場合にのみ有効 /arch2/boston/ 内のローカル アーカイブ REDO ログ ファイルにプライマリ データベースから受信した REDO データをアーカイブするよう指示 ロジカル スタンバイ データベースの作成 4-7

76 作成後の手順 ロジカル スタンバイ データベースのオープン 新規データベースはプライマリ データベースと論理的には同じですが プライマリ データベースとのトランザクション一貫性に欠けるため リカバリ操作が異なります 新規ロジカル スタンバイ データベースをオープンするには 次の文を発行し RESETLOGS オプションを使用してオープンする必要があります SQL> ALTER DATABASE OPEN RESETLOGS; データベースがオープンされるのはこれが初めてなため データベースのグローバル名は 新しい DB_NAME 初期化パラメータと一致するように自動的に調整されます 次の文を発行して ロジカル スタンバイ データベースに対する REDO データの適用を開始します 次に例を示します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; ロジカル スタンバイ データベースが正しく実行されているかどうかの確認 ロジカル スタンバイ データベースが適切に実行されていることを検証するには 次の項を参照してください 項 ログ ファイル アーカイブ情報の監視 5-32 ページ 項 ロジカル スタンバイ データベースでのログ適用サービスの監視 6-7 ページ 第 9 章 ロジカル スタンバイ データベースの管理 9-1 ページ 4.3 作成後の手順 この時点で ロジカル スタンバイ データベースが実行中であり 最大パフォーマンス レベルのデータ保護を提供できます 次のリストに ロジカル スタンバイ データベースに対して実行できるその他の準備について説明します データ保護モードのアップグレード Data Guard 構成は 最初は最大パフォーマンス モード ( デフォルト ) で設定されます データ保護モードの詳細と現行の保護モードをアップグレードまたはダウングレードする方法は 5-20 ページの 5.6 項 データ保護モードの設定 を参照してください フラッシュバック データベースの有効化 フラッシュバック データベースにより フェイルオーバー後のプライマリ データベースの再作成の必要がなくなります フラッシュバック データベースは従来の Point-in-Time リカバリと同様の機能で データベースを過去の最新時点の状態に戻すことができます フラッシュバック データベースでは データファイルをバックアップからリストアしたり REDO データを広範囲に適用する必要がないため Point-in-Time リカバリよりも高速です フラッシュバック データベースは プライマリ データベースまたはスタンバイ データベース あるいはその両方で有効化できます Data Guard 環境でのフラッシュバック データベースの使用例は ページの 12.4 項 フェイルオーバー後のフラッシュバック データベースの使用 および ページの 12.5 項 Open Resetlogs 文の発行後のフラッシュバック データベースの使用 を参照してください フラッシュバック データベースの詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください 4-8 Oracle Data Guard 概要および管理

77 5 REDO 転送サービス この章では 本番データベースから 1 つ以上の宛先に REDO を転送するように REDO 転送サービスを構成する方法について説明します この章は 次の項目で構成されています REDO 転送サービスの概要 REDO データの送信先 REDO データの送信方法 REDO データの送信時間 エラーが発生した場合の対処方法 データ保護モードの設定 ログ ファイルの管理 アーカイブ ギャップの管理 確認 REDO 転送サービス 5-1

78 REDO 転送サービスの概要 5.1 REDO 転送サービスの概要 REDO 転送サービスは データベース宛先から 1 つ以上の宛先に対する REDO データの自動転送を制御します また ネットワーク障害によるアーカイブ REDO ログ ファイルのギャップを解決するプロセスも管理します REDO 転送サービスは ローカルとリモートの宛先に REDO データを転送できます リモートの宛先には 複数のタイプがあります フィジカルおよびロジカル スタンバイ データベース アーカイブ REDO ログ リポジトリ Oracle Change Data Capture ステージング データベース Oracle Streams ダウンストリーム取得データベースなどです 図 5-1 に REDO 転送サービスを使用して REDO データをプライマリ データベース上のローカルの宛先にアーカイブし 同時にリモート スタンバイ データベースの宛先にアーカイブ REDO ログ ファイルまたはスタンバイ REDO ログ ファイルを転送する単純な Data Guard 構成を示します 図 5-1 REDO データの転送 5-2 Oracle Data Guard 概要および管理

79 REDO データの送信先 5.2 REDO データの送信先 この項は 次の項目で構成されています 宛先タイプ REDO データの送信方法 フラッシュ リカバリ領域の設定 宛先タイプ REDO 転送サービスは 次のように複数タイプの宛先をサポートしています Oracle Data Guard スタンバイ データベース スタンバイ データベースの宛先には フィジカル スタンバイ データベースまたはロジカル スタンバイ データベースを使用できます スタンバイ データベースについては 項を参照してください アーカイブ REDO ログ リポジトリ このタイプのアーカイブ先では REDO データのアーカイブがオフサイトで可能です アーカイブ ログ リポジトリは フィジカル スタンバイ制御ファイルを使用し インスタンスを起動して データベースをマウントすることによって作成されます このデータベースにデータファイルは含まれず スイッチオーバーまたはフェイルオーバーには使用できません 短期間 ( たとえば 1 日 ) アーカイブ REDO ログ ファイルを保持し その後ログ ファイルを削除する方法として便利です これによって 他の完全に構成されたスタンバイ データベースの格納と処理の手間をほとんど省くことができます アーカイブ REDO ログ ファイルの一時記憶域には アーカイブ REDO ログ リポジトリを使用することをお薦めします そのためには 最大パフォーマンス モードで実行中の Data Guard 構成で アーカイバベースの転送に使用するリポジトリ宛先を (LOG_ ARCHIVE_DEST_n パラメータの ARCH 属性を使用して ) 構成します 非データ消失環境の場合は Data Guard 構成で LGWR SYNC および AFFIRM 転送設定を使用して完全に構成され 最大保護モードまたは最大可用性モードで稼働しているスタンバイ データベースを使用する必要があります Oracle Streams リアルタイム ダウンストリーム取得データベース この宛先タイプを使用すると Oracle Streams によって取得プロセスをリモートのダウンストリーム データベースで構成できます Streams ダウンストリーム取得プロセスは REDO 転送サービスを使用して REDO データをダウンストリーム データベースに転送し ここで Streams の取得プロセスが リモート宛先でのアーカイブ REDO ログ ファイルの変更点を取得します 詳細は Oracle Streams 概要および管理 を参照してください Oracle Change Data Capture ステージング データベース この宛先タイプは ステージング データベースでチェンジ データ キャプチャの Asynchronous AutoLog 構成をリモートにサポートしています REDO データは REDO 転送サービスを使用してソース データベースからステージング データベースにコピーされます チェンジ データ キャプチャ構成では 変更データが REDO データから取得されます 詳細は Oracle Database データ ウェアハウス ガイド を参照してください このマニュアルの説明では 本番データベースをプライマリ データベース アーカイブ先をスタンバイ データベースと呼びます ( 定義については 1.1 項を参照してください ) Oracle Change Data Capture を使用している場合は プライマリ データベースおよびスタンバイ データベースという用語をそれぞれソースおよびステージング データベースに置き換えてください Oracle Streams を使用している場合は プライマリ データベースおよびスタンバイ データベースという用語をそれぞれソースおよびダウンストリーム取得データベースに置き換えてください REDO 転送サービス 5-3

80 REDO データの送信先 LOG_ARCHIVE_DEST_n パラメータを使用した宛先の構成 LOG_ARCHIVE_DEST_n 初期化パラメータでは 最大 10(n = 1, 2, 3,... 10) の宛先を定義します いずれも LOCATION または SERVICE 属性を使用して REDO データのアーカイブ先を指定する必要があります LOCATION および SERVICE 属性では ローカル ディスクの場所 または REDO 転送サービスが REDO データを転送するスタンバイ宛先を示す Oracle Net サービス名を記述します SERVICE 属性でリモートの宛先を指定することにより 障害時リカバリに備え Data Guard がトランザクション一貫性のあるプライマリ データベースのリモート コピーを維持できます 定義する各 LOG_ARCHIVE_DEST_n 初期化パラメータに対し それぞれ対応する LOG_ ARCHIVE_DEST_STATE_n パラメータを指定します LOG_ARCHIVE_DEST_STATE_n(n は 1 から 10 の整数 ) 初期化パラメータは 対応する宛先が現在オン ( 有効 ) とオフ ( 無効 ) のどちらになっているかを指定します 表 5-1 に LOG_ARCHIVE_DEST_STATE_n パラメータの属性を示します 表 5-1 LOG_ARCHIVE_DEST_STATE_n 初期化パラメータの属性 属性 ENABLE DEFER ALTERNATE RESET 説明 REDO ログ転送サービスはこの宛先に REDO データを転送できる これはデフォルトです REDO 転送サービスはこの宛先に REDO データを転送しない これは有効ですが 使用されない宛先です この宛先は使用可能ではないが 関連付けられている宛先への通信に障害が起きると使用可能になる 機能は DEFER と同じだが 前に失敗している場合は宛先に関するエラー メッセージを消去する 例 5-1 に LOCATION 属性を持つ単一の宛先の例を示します 例 5-1 ローカルのアーカイブ先の指定 LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/' LOG_ARCHIVE_DEST_STATE_1=ENABLE 図 5-2 に 単一のローカル宛先で構成される この単純な構成を示します ログ ライター プロセスは REDO データをオンライン REDO ログ ファイルに書き込みます 各オンライン REDO ログ ファイルがいっぱいになると ログ スイッチが発生し ARCn プロセスは いっぱいになったオンライン REDO ログ ファイルをアーカイブ REDO ログ ファイルにアーカイブします これによって いっぱいになったオンライン REDO ログ ファイルが再利用できます 5-4 Oracle Data Guard 概要および管理

81 REDO データの送信先 図 5-2 スタンバイ データベースがない場合のプライマリ データベースのアーカイブ処理 図 5-2 で示されている構成にはスタンバイ データベースが含まれておらず 障害リカバリに対して保護しない点に注意してください この単純な構成を 障害時リカバリを提供する Data Guard 構成にするには SERVICE 属性を指定してリモートの宛先にスタンバイ データベースをします 例 5-2 に REDO 転送サービスによってオンライン REDO ログをローカルの宛先 chicago にアーカイブし REDO データを Oracle Net サービス名が boston のリモート スタンバイ データベースに転送することを可能にする初期化パラメータを示します この例では 他のすべての LOG_ARCHIVE_DEST_n 属性にデフォルト値を使用しています 例 5-2 リモートのアーカイブ先の指定 LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='SERVICE=boston' LOG_ARCHIVE_DEST_STATE_2=ENABLE これらの初期化パラメータは アーカイバ (ARCn) プロセスを使用してローカルとリモートの宛先にアーカイブする Data Guard 構成を設定します この構成は 最大パフォーマンス レベルのデータ保護を提供します LOG_ARCHIVE_DEST_n パラメータの LOCATION または SERVICE 属性のみを指定して Data Guard 構成を作成できますが オプションで他の属性を指定することにより 各宛先の動作をより詳細に指定できます LOG_ARCHIVE_DEST_n パラメータの全属性のリファレンス情報は 第 14 章を参照してください REDO 転送サービス 5-5

82 REDO データの送信先 宛先属性の変更 LOG_ARCHIVE_DEST_n および LOG_ARCHIVE_DEST_STATE_n パラメータのほとんどの属性値は ALTER SYSTEM SET 文を使用して動的に更新できます 変更は 次にプライマリ データベースでログ スイッチを行った後 有効になります たとえば REDO 転送サービスが boston という名前のリモート スタンバイ データベースに REDO データを転送するのを遅延させるには プライマリ データベースで次の文を発行します SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=boston 2> VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'; SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER; V$ARCHIVE_DEST ビューを使用した属性の表示 LOG_ARCHIVE_DEST_n 初期化パラメータの現行の設定を表示するには V$ARCHIVE_DEST ビューを問合せます フラッシュ リカバリ領域の設定 Oracle データベースでは フラッシュ リカバリ領域と呼ばれるディスク領域を構成できます これは ディレクトリまたは Oracle Storage Manager ディスク グループで リカバリに関連のあるファイルのデフォルトの格納場所として機能します フラッシュ リカバリ領域を構成するには DB_RECOVERY_FILE_DEST 初期化パラメータを使用します リカバリ領域を作成し 他のローカルのアーカイブ先を設定しない場合 LOG_ ARCHIVE_DEST_10 は暗黙的に USE_DB_RECOVERY_FILE_DEST に設定されます ( アーカイブ REDO ログ ファイルがフラッシュ リカバリ領域に送信されることを意味します ) ( フラッシュ リカバリ領域の構成方法は Oracle Database バックアップおよびリカバリ基礎 を Oracle Storage Manager と Oracle Managed Files の詳細は Oracle Database 管理者ガイド を参照してください ) 注意 : フラッシュ リカバリ領域に格納されたアーカイブ REDO ログ ファイルのファイル名は Oracle Managed Files(OMF) によって自動的に生成されます LOG_ARCHIVE_FORMAT 初期化パラメータによって指定された形式には基づいていません この項は 次の項目で構成されています LOG_ARCHIVE_DEST_10 の宛先の使用 他の LOG_ARCHIVE_DEST_n の宛先の使用 STANDBY_ARCHIVE_DEST の宛先の使用 プライマリ データベースとスタンバイ データベースでフラッシュ リカバリ領域を共有する 注意 : プライマリ データベースからロジカル スタンバイ データベースのフラッシュ リカバリ領域には REDO データを書き込めません フラッシュ リカバリ領域の構成方法については Oracle Database バックアップおよびリカバリ基礎 を フラッシュ リカバリ領域内のアーカイブ REDO ログ ファイルに対する削除ポリシーの設定方法については 項を参照してください 5-6 Oracle Data Guard 概要および管理

83 REDO データの送信先 LOG_ARCHIVE_DEST_10 の宛先の使用 フラッシュ リカバリ領域が構成されていて ローカルの宛先が定義されていない場合 Data Guard により暗黙的に LOG_ARCHIVE_DEST_10 の宛先がフラッシュ リカバリ領域として使用されます LOG_ARCHIVE_DEST_10 の宛先が使用される場合 Data Guard は 自動的にすべての LOG_ ARCHIVE_DEST_10 パラメータ属性のデフォルト値を使用します デフォルトを無視するには LOG_ARCHIVE_DEST_10 パラメータを明示的に指定し ほとんどの属性の値を動的に設定します たとえば 次の ALTER SYSTEM SET 文により LOG_ARCHIVE_DEST_10 初期化パラメータのいくつかの属性が指定されます SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_10='LOCATION=USE_DB_RECOVERY_FILE_DEST LGWR MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)' LOG_ARCHIVE_DEST_n の属性を設定すると LOG_ARCHIVE_DEST_n パラメータの TEMPLATE 属性は フラッシュ リカバリ領域のその他すべての指定に優先されます リモートの宛先について TEMPLATE 属性が指定され その宛先では REDO データがフラッシュ リカバリ領域にアーカイブされる場合 アーカイブ REDO ログ ファイルには TEMPLATE 属性で指定されたディレクトリおよびファイル名が使用されます 他の LOG_ARCHIVE_DEST_n の宛先の使用 他の 1 つ以上の LOG_ARCHIVE_DEST_n の宛先を フラッシュ リカバリ領域を指すように明示的に設定できます たとえば オプションで次のように構成できます LOG_ARCHIVE_DEST_10 以外の宛先を構成します たとえば 既存の Data Guard 構成では すでに LOG_ARCHIVE_DEST_10 の宛先が他の目的に使用されていたり LOG_ARCHIVE_DEST_10 の宛先を他の用途のために解放することが必要になる場合があります フラッシュ リカバリ領域を指すように他のアーカイブ先を構成するには LOCATION=USE_DB_RECOVERY_FILE_DEST 属性を指定して新規のアーカイブ先を定義する必要があります 次に例を示します SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)' 暗黙的な ( フラッシュ リカバリ領域を使用するための LOG_ARCHIVE_DEST_10 の ) 設定は消去されます ロールの推移後に使用するために LOG_ARCHIVE_DEST_10 の宛先に加えて宛先を構成します たとえば データベースがスタンバイ ロールで動作するときのスタンバイ REDO ログに有効なアーカイブ先と データベースがプライマリ ロールで動作するときのオンライン REDO ログに有効なアーカイブ先を構成できます LOG_ARCHIVE_DEST_10 に加えて LOG_ARCHIVE_DEST_n の宛先を構成するには 両方の宛先を明示的に指定する必要があります LOG_ARCHIVE_DEST_9='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)' LOG_ARCHIVE_DEST_10='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)' REDO 転送サービス 5-7

84 REDO データの送信先 STANDBY_ARCHIVE_DEST の宛先の使用 フィジカル スタンバイ データベースの場合は フラッシュ リカバリ領域を指すように STANDBY_ARCHIVE_DEST パラメータを定義できます 次に例を示します STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST' 注意 : ロジカル スタンバイ データベース (SQL Apply) で STANDBY_ARCHIVE_DEST パラメータを使用して指定したフラッシュ リカバリ領域の宛先は無視されます プライマリ データベースとスタンバイ データベースでフラッシュ リカバリ領域を共有する フラッシュ リカバリ領域を共有する各データベースに DB_UNIQUE_NAME 初期化パラメータで一意のデータベース名が指定されている場合は データベース間でフラッシュ リカバリ領域を共有できます 次の例に /arch/oradata ディレクトリにあるフラッシュ リカバリ領域を共有するプライマリおよびスタンバイ データベースで 初期化パラメータを指定する方法を示します 例 5-3 では DB_UNIQUE_NAME パラメータが指定されていませんが デフォルトで DB_NAME 初期化パラメータに指定されている名前 PAYROLL に設定されます 例 5-3 共有リカバリ領域に関するプライマリ データベースの初期化パラメータ DB_NAME=PAYROLL LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST' DB_RECOVERY_FILE_DEST='/arch/oradata' DB_RECOVERY_FILE_DEST_SIZE=20G 例 5-4 共有リカバリ領域に関するスタンバイ データベースの初期化パラメータ DB_NAME=PAYROLL DB_UNIQUE_NAME=boston LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST' STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST' DB_RECOVERY_FILE_DEST='/arch/oradata' DB_RECOVERY_FILE_DEST_SIZE=5G 複数のデータベース間でフラッシュ リカバリ領域を共有する方法の詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください 5-8 Oracle Data Guard 概要および管理

85 REDO データの送信方法 5.3 REDO データの送信方法 プライマリ データベースでは Oracle Data Guard はアーカイバ プロセス (ARCn) またはログ ライター プロセス (LGWR) を使用し トランザクション REDO データを収集してスタンバイ宛先に転送します 同じ宛先への REDO データ送信にアーカイバ プロセスとログ ライター プロセスの両方を使用することはできませんが ある宛先にはログ ライター プロセスを使用し 他の宛先にはアーカイバ プロセスを使用して REDO データを送信するように選択することはできます この項は 次の項目で構成されています アーカイバ プロセス (ARCn) を使用した REDO データのアーカイブ ログ ライター プロセス (LGWR) を使用した REDO データのアーカイブ セキュアな REDO データの転送の提供 また Data Guard では ギャップの自動解消および再同期化のために フェッチ アーカイブ ログ (FAL) クライアントおよびサーバーを使用して ネットワーク停止後にアーカイブ REDO ログ ファイルがスタンバイ宛先に送信されます FAL プロセスとギャップの解消については 5.8 項を参照してください アーカイバ プロセス (ARCn) を使用した REDO データのアーカイブ デフォルトで REDO 転送サービスは ARCn プロセスを使用して オンライン REDO ログ ファイルをプライマリ データベースにアーカイブします ARCn アーカイブ プロセスは Data Guard 構成で最大パフォーマンス レベルのデータ保護のみをサポートします 他のデータ保護モードで動作するスタンバイの場所に REDO データを転送するには LGWR プロセスを使用する必要があります (Data Guard のデータ保護モードの詳細は 5.6 項を参照してください ) この項は 次の項目で構成されています ARCn のアーカイブ動作を制御する初期化パラメータ ARCn のアーカイブ処理 ARCn のアーカイブ動作を制御する初期化パラメータ この項では LOG_ARCHIVE_DEST_n および LOG_ARCHIVE_MAX_PROCESSES 初期化パラメータの使用方法について説明します ARCn プロセスの有効化によるローカル宛先またはリモート宛先へのアーカイブ LOG_ARCHIVE_DEST_n 初期化パラメータの属性を指定して プライマリ データベースから他の宛先への REDO データの自動転送を制御します ARCn アーカイバ プロセスはデフォルトのアーカイブ動作であるため LOG_ARCHIVE_DEST_n パラメータの ARCH 属性の指定はオプションです ただし ローカル宛先にアーカイブするには LOCATION 属性を リモート アーカイブの場合は SERVICE 属性を指定する必要があります (5.2.2 項を参照 ) ARCn プロセスの起動数の指定 LOG_ARCHIVE_MAX_PROCESSES 初期化パラメータで ARCn プロセスの最大数を指定します デフォルトでは プライマリ データベース インスタンスの起動時に 4 つのアーカイバ プロセスが起動され アーカイバのワークロードのバランスを調整するために Oracle Database によりプロセス数が動的に調整されます そのため 実際のアーカイバ プロセス数は随時変動する場合があります アーカイブのワークロードが大きいと思われる場合は LOG_ARCHIVE_MAX_PROCESSES 初期化パラメータを設定してアーカイバ プロセスの最大数を 30 まで増やすことができます この初期化パラメータは動的であり ALTER SYSTEM コマンドを使用して変更し アーカイバ プロセスの最大数を増減させることができます 次に例を示します ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES = 20; REDO 転送サービス 5-9

86 REDO データの送信方法 ARCn のアーカイブ処理 図 5-3 は プライマリ データベースがシカゴにあり 1 つのフィジカル スタンバイ データベースがボストンにある場合の Data Guard 構成におけるアーカイブ処理の例を示しています ( これは 第 3 章で作成した構成です ) プライマリ データベースでログ スイッチが発生すると アーカイブが実行されます プライマリ データベースでは ARC0 プロセスが正常にローカル オンライン REDO ログをローカルの宛先 (LOG_ARCHIVE_DEST_1) にアーカイブした後 ARC1 プロセスがローカル アーカイブ REDO ログ ファイル ( オンライン REDO ログ ファイルではありません ) からリモート スタンバイ宛先 (LOG_ARCHIVE_DEST_2) に REDO を転送します リモートの宛先では リモート ファイル サーバー プロセス (RFS) が REDO データをスタンバイ REDO ログ ファイルからアーカイブ REDO ログ ファイルに書き込みます ログ適用サービスは REDO Apply(MRP プロセス 1 ) または SQL Apply(LSP プロセス 2 ) を使用して REDO をスタンバイ データベースに適用します オンライン REDO ログ ファイルはまずローカルにアーカイブされるため ローカルの宛先と同時に ARCn プロセスをスタンバイ データベースにアーカイブする場合に比べ LGWR プロセスによるオンライン REDO ログ ファイルの再利用が非常に早くなります 図 5-3 に示すように ローカル アーカイブをリモート アーカイブから分離するには 2 つ以上の ARCn プロセスが必要です このように分離するには LOG_ARCHIVE_MAX_PROCESSES 初期化パラメータを設定します ( デフォルト設定は 4 ですが 最大値は 30 です ) 図 5-3 リモートの宛先にアーカイブする前にローカルの宛先にアーカイブする 1 管理リカバリ プロセス (MRP) では アーカイブ REDO ログ ファイルがフィジカル スタンバイ データベースに適用され 開始時に最適なパラレル リカバリ プロセス数が自動的に判別されます 起動されるパラレル リカバリ スレーブの数は スタンバイ サーバー上で使用可能な CPU の数に基づきます 2 ロジカル スタンバイ プロセス (LSP) は パラレル実行 (Pnnn) プロセスと SQL インタフェースを使用して アーカイブ REDO ログ ファイルをロジカル スタンバイ データベースに適用します 5-10 Oracle Data Guard 概要および管理

87 REDO データの送信方法 デフォルトの ARCn アーカイブ プロセスでは ローカルのアーカイブとリモートのアーカイブの関連付けが解除されるため バックアップ直後にプライマリ データベース上のアーカイブ REDO ログ ファイルを削除するためのポリシーを持つサイトでは プライマリ データベースのアーカイブ REDO ログ ファイルを削除する前に スタンバイの宛先が対応する REDO データを受信することを確認する必要があります V$ARCHIVED_LOG ビューを問い合せると スタンバイの宛先で REDO データが受信されたことを確認できます ログ ライター プロセス (LGWR) を使用した REDO データのアーカイブ オプションで REDO 転送サービスを使用可能にし LGWR プロセスを使用して REDO データをリモートの宛先に転送できます LGWR プロセスの使用方法は ARCn プロセス (5.3.1 項を参照 ) とは異なります これは LGWR プロセスでは プライマリ データベースでオンライン REDO ログが切り替わるまで待機してからリモートの宛先でアーカイブ REDO ログ全体を一度に書き込むかわりに プライマリ データベースのカレント オンライン REDO ログ ファイルのログ順序番号 ( およびサイズ ) を反映するスタンバイ REDO ログ ファイルをスタンバイ サイトで選択するためです その後 プライマリ データベースで REDO が生成されると それがリモートの宛先にも転送されます リモートの宛先への転送は LOG_ARCHIVE_DEST_n パラメータに設定されている属性 (SYNC または ASYNC) に基づいて同期または非同期で実行されます Data Guard 構成では データ保護の最大保護および最大可用性モードには 同期 LGWR 処理が必須です (Data Guard のデータ保護モードの詳細は 5.6 項を参照してください ) この項は 次の項目で構成されています LGWR アーカイブ プロセスに関する LOG_ARCHIVE_DEST_n 属性 LGWR SYNC アーカイブ プロセス LGWR ASYNC アーカイブ プロセス LGWR アーカイブ プロセスに関する LOG_ARCHIVE_DEST_n 属性 次の各項では LGWR SYNC および ASYNC 属性について説明します REDO 転送サービスでの LGWR プロセスの使用可能化 REDO 転送サービスで LGWR プロセスを使用して REDO データをリモートのアーカイブ先に転送できるようにするには LOG_ARCHIVE_DEST_n パラメータの LGWR および SERVICE 属性を指定する必要があります 同期または非同期ネットワーク転送の指定 LGWR プロセスはリモートの宛先に REDO データを転送すると同時に 同期させてローカルのオンライン REDO ログ ファイルに書き込みます SYNC 属性を指定すると すべてのネットワーク I/O がオンライン REDO ログ ファイルへの各書込み操作と同期して実行され ネットワーク I/O の完了を待機します Data Guard 構成における同期的なネットワーク転送の例については 項を参照してください これは デフォルトのネットワーク転送設定です ASYNC 属性を指定すると すべてのネットワーク I/O は非同期的に実行され ネットワーク I/O の完了を待たずに 実行中のアプリケーションまたはユーザーへ制御が即時に戻されます Data Guard 構成における非同期ネットワーク転送の例については 項を参照してください 注意 : LGWR プロセスを使用するように宛先を構成しても なんらかの原因で LGWR プロセスが宛先にアーカイブできなくなると REDO 転送は ARCn プロセスの使用に戻ってアーカイブ操作を完了します REDO 転送サービス 5-11

88 REDO データの送信方法 LGWR SYNC アーカイブ プロセス 例 5-5 に 同期ネットワーク転送用に LGWR プロセスを構成するプライマリ ロールの LOG_ARCHIVE_DEST_n パラメータを示します 例 5-5 LGWR 同期アーカイブのための初期化パラメータ LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago' LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR SYNC NET_TIMEOUT=30' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE これは LGWR アーカイブ プロセスのデフォルトであるため LOG_ARCHIVE_DEST_n パラメータの SYNC 属性の指定はオプションです NET_TIMEOUT 属性は LGWR プロセスがネットワーク接続を終了する前にネットワーク サーバー プロセスからのステータスを待機する時間を制御するため この属性を指定することをお薦めします NET_TIMEOUT に指定した秒数以内にリプライがないと LGWR プロセスはエラー メッセージを戻します 図 5-4 に LGWR プロセスを使用して REDO データをプライマリ データベースのオンライン REDO ログ ファイルに書き込むと同時に同期させてスタンバイ システムに転送する Data Guard 構成を示します プライマリ データベースでは LGWR プロセスが REDO データを 1 つ以上のネットワーク サーバー (LNSn) プロセスに発行し そこで複数のリモート宛先に対するネットワーク I/O がパラレルに開始されます トランザクションのリカバリに必要な REDO データがすべての LGWR SYNC 宛先で受信されるまで プライマリ データベースではトランザクションがコミットされません スタンバイ システムでは リモート ファイル サーバー (RFS) がネットワークを介して LGWR プロセスから REDO データを受信し スタンバイ REDO ログ ファイルに書き込みます プライマリ データベースのログ スイッチによって スタンバイ データベースのログ スイッチがトリガーされると スタンバイ データベースの ARCn プロセスは スタンバイ REDO ログ ファイルをスタンバイ データベースのアーカイブ REDO ログ ファイルにアーカイブします REDO Apply(MRP プロセス ) または SQL Apply(LSP プロセス ) は REDO データをスタンバイ データベースに適用します リアルタイム適用が使用可能な場合 Data Guard では 現行のスタンバイ REDO ログ ファイルが RFS プロセスによっていっぱいになったときに そのファイルから REDO データを直接リカバリします 5-12 Oracle Data Guard 概要および管理

89 REDO データの送信方法 図 5-4 スタンバイ REDO ログ ファイルを使用したリモートの宛先への LGWR SYNC アーカイブ LGWR ASYNC アーカイブ プロセス 例 5-6 に 非同期ネットワーク転送用に LGWR プロセスを構成するプライマリ ロールの LOG_ARCHIVE_DEST_n パラメータを示します 例 5-6 LGWR 非同期アーカイブのための初期化パラメータ LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago' LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE 図 5-5 に LNSn プロセスを使用して オンライン REDO データをオンライン REDO ログ ファイルから収集し Oracle Net を介してスタンバイ データベース上の RFS プロセスに転送する様子を示します LGWR および ASYNC 属性を指定すると ログ ライター プロセスがローカルのオンライン REDO ログ ファイルに書き込む間に ネットワーク サーバー (LNSn) プロセス ( 宛先ごとに 1 つずつ ) が REDO をリモートの宛先に非同期的に転送します LGWR プロセスは LNS ネットワーク I/O の完了を待たずに次の要求の処理を続行します REDO 転送サービスが REDO データを複数のリモートの宛先に転送する場合 LNSn プロセス ( 宛先ごとに 1 つずつ ) は すべての宛先に対するネットワーク I/O をパラレルに開始します オンライン REDO ログ ファイルがいっぱいになると ログ スイッチが発生し アーカイバ プロセスはログ ファイルを通常どおりローカルにアーカイブします REDO 転送サービス 5-13

90 REDO データの送信方法 注意 : Oracle Database 10g リリース 10.2 からは LGWR 属性と ASYNC 属性の両方で構成されている LOG_ARCHIVE_DEST_n の宛先には NET_ TIMEOUT 属性を指定する必要はありません これは リリース 10.2 では どのような理由であれログ ライター プロセスが LNSn を待機することはないためです そのため NET_TIMEOUT 属性を指定する必要はありません 図 5-5 ネットワーク サーバー (LNSn) ( プロセスを使用した LGWR ASYNC アーカイブ 注意 : フラッシュ リカバリ領域の宛先指定には LOG_ARCHIVE_DEST または LOG_ARCHIVE_DUPLEX_DEST 初期化パラメータを使用しないでください 5-14 Oracle Data Guard 概要および管理

91 REDO データの送信方法 セキュアな REDO データの転送の提供 Data Guard は セキュアな環境を提供し REDO データがスタンバイ データベースに転送される際に改ざんされる可能性を防止します REDO 転送サービスは REDO データの送信に認証ネットワーク セッションを使用します これらのセッションは パスワード ファイル内の SYS ユーザー パスワードを使用して認証されます Data Guard 構成内の全データベースでパスワード ファイルを使用する必要があり このパスワード ファイル内の SYS パスワードは 全システムで同一である必要があります Oracle Advanced Security がインストールされていない場合もこの認証は実行可能で REDO の転送の際にある程度のセキュリティを提供します 注意 : REDO をさらに強力に保護するには ( たとえば REDO を暗号化したり ネットワーク上の REDO 通信の整合性チェックサム値を計算し ネットワーク上での REDO の改ざんを防止する ) Oracle Advanced Security をインストールし 使用することをお薦めします Oracle Database Advanced Security 管理者ガイド を参照してください プライマリ データベースと各スタンバイ データベースで 次の手順を実行します 1. プライマリ データベースおよびすべてのスタンバイ データベースで パスワード ファイルを作成します (orapwd ユーティリティを使用します ) 次に例を示します ORAPWD FILE=orapw PASSWORD=mypassword ENTRIES=10 この例では 10 のエントリを持つパスワード ファイルを作成し SYS のパスワードは mypassword です REDO データの転送を正しく実行するには すべてのプライマリおよびスタンバイ データベースで SYS ユーザー アカウントに同一のパスワードを設定する必要があります 2. REMOTE_LOGIN_PASSWORDFILE 初期化パラメータを EXCLUSIVE または SHARED に設定し Oracle によってパスワード ファイルを確認し パスワード ファイルを使用できるデータベース数を指定できるようにします 次に例を示します REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE このパラメータの詳細は Oracle Database リファレンス を参照してください REDO 転送サービス 5-15

92 REDO データの送信時間 5.4 REDO データの送信時間 この項は 次の項目で構成されています VALID_FOR 属性を使用したロール ベースの宛先の指定 一意のプライマリ データベース名とスタンバイ データベース名の指定 VALID_FOR 属性を使用したロール ベースの宛先の指定 VALID_FOR 属性を使用すると プライマリおよびスタンバイ データベース ロールの両方の宛先属性を 1 つのサーバー パラメータ ファイル (SPFILE) で構成でき Data Guard 構成はロールの推移後も正しく動作します ロールの推移後にロール固有のパラメータ ファイルを使用可能または使用不可能にする必要がないため スイッチオーバーおよびフェイルオーバーが単純化されます LOG_ARCHIVE_DEST_n パラメータの VALID_FOR 属性を指定する場合は 次の要因に基づき REDO 転送サービスが REDO データを宛先にいつ転送できるかを識別します データベースがプライマリ ロールとスタンバイ ロールのどちらで現在実行されているか データベースの現行のロールに応じて オンライン REDO ログ ファイル スタンバイ REDO ログ ファイルまたは両方のアーカイブが必要であるか LOG_ARCHIVE_DEST_n 宛先ごとにこれらの要因を構成するには キーワードのペア (VALID_FOR=(redo_log_type,database_role) を使用してこの属性を指定します redo_log_type キーワードは ONLINE_LOGFILE STANDBY_LOGFILE または ALL_LOGFILES のいずれかをアーカイブするのに 宛先が妥当であると指定します database_role キーワードは 宛先が妥当であるために カレント データベースが実行しているロールを PRIMARY_ ROLE STANDBY_ROLE または ALL_ROLES のいずれかに指定します 宛先の VALID_FOR 属性を指定していない場合 データベースのロールにかかわらず デフォルトで オンライン REDO ログおよびスタンバイ REDO ログのアーカイブは宛先で使用可能になります このデフォルトの動作は VALID_FOR 属性で (ALL_LOGFILES,ALL_ROLES) キーワード ペアを設定した場合と同様です 次に例を示します LOG_ARCHIVE_DEST_1='LOCATION=/ARCH1/CHICAGO/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES)' (ALL_LOGFILES,ALL_ROLES) キーワード ペアはデフォルトですが すべての宛先について推奨されるわけではありません たとえば フィジカル スタンバイ データベースとは異なり ロジカル スタンバイ データベースは REDO データを生成するオープン データベースであり 複数のログ ファイル ( オンライン REDO ログ ファイル アーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイル ) があります ほとんどの場合 ロジカル スタンバイ データベースによって生成されるオンライン REDO ログ ファイルは プライマリ データベースから REDO を受信するスタンバイ REDO ログ ファイルと同じディレクトリにあります そのため 各宛先に対してそれぞれ VALID_FOR 属性を定義し ロールの推移後を含め 常に Data Guard 構成が正しく動作するようにすることをお薦めします 各種 Data Guard 構成用の VALID_FOR 属性の設定例については 12.1 項の使用例を参照してください 宛先の構成に VALID_FOR 属性を使用しない場合 データベースがプライマリ ロールで動作している場合とスタンバイ ロールで動作している場合のためにそれぞれ 1 つずつ 合計 2 つのデータベース サーバー パラメータ ファイル (SPFILE) を維持する必要があります 構成例については 第 12 章を参照してください 5-16 Oracle Data Guard 概要および管理

93 REDO データの送信時間 一意のプライマリ データベース名とスタンバイ データベース名の指定 DB_UNIQUE_NAME 属性を使用すると 宛先の構成時に一意のデータベース名を指定できます これにより Real Application Clusters のプライマリ データベースが最大保護レベルまたは最大可用性保護レベルで実行されている場合 そのプライマリ データベースが含まれている Data Guard 構成にスタンバイ データベースを動的に追加できるようになります LOG_ ARCHIVE_CONFIG パラメータが定義されている場合 DB_UNIQUE_NAME 初期化パラメータは必須です 注意 : リモートの宛先のスタンバイ データベースが DB_UNIQUE_NAME 初期化パラメータで識別されていない場合は プライマリ インスタンスを起動する前にスタンバイ データベースにアクセスできる必要があります また LOG_ARCHIVE_DEST_n パラメータの DB_UNIQUE_NAME 属性と LOG_ARCHIVE_ CONFIG パラメータの DG_CONFIG 属性では Data Guard 構成の各データベースの一意の名前を指定します DB_UNIQUE_NAME 初期化パラメータで各データベースに対して定義した名前を指定してください たとえば 次の初期化パラメータは 第 3 章で説明した Data Guard 構成内のプライマリ データベース (chicago) の DB_UNIQUE_NAME および LOG_ARCHIVE_CONFIG 定義を示しています DB_NAME=chicago DB_UNIQUE_NAME=chicago LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago, boston)' LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) LOG_ARCHIVE_DEST_2= 'SERVICE=boston LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston' SERVICE 属性で指定されているリモートの宛先には DB_UNIQUE_NAME 属性が必須です この例の LOG_ARCHIVE_DEST_2 パラメータでは リモートの宛先に DB_UNIQUE_ NAME=boston が指定されています REDO 転送サービスは この情報をリモートの宛先で検証します 名前が一致しなければ その宛先への接続が拒否されます LOG_ARCHIVE_CONFIG パラメータには SEND NOSEND RECEIVE および NORECEIVE 属性もあります SEND は データベースによる REDO データのリモートの宛先への送信を可能にします RECEIVE は スタンバイ データベースによる別のデータベースからの REDO の受信を可能にします これらの設定を使用不可能にするには NOSEND および NORECEIVE キーワードを使用します たとえば プライマリ データベースがアーカイブ REDO データを意図せずに受信しないようにするには 次のようにプライマリ データベースで LOG_ARCHIVE_CONFIG 初期化パラメータを NORECEIVE に設定します LOG_ARCHIVE_CONFIG='NORECEIVE,DG_CONFIG=(chicago,boston)' ただし NOSEND または NORECEIVE 属性を指定すると ロールの推移後にデータベース インスタンスの機能が制限される場合があることに注意してください たとえば NOSEND 属性が設定されているスタンバイ データベースがプライマリ ロールに推移すると パラメータ値を SEND に再設定するまでは REDO データを他のスタンバイ データベースに転送できなくなります 同様に NORECEIVE 属性が指定されているデータベースは プライマリ データベースから REDO を受信できません REDO 転送サービス 5-17

94 エラーが発生した場合の対処方法 デフォルトで LOG_ARCHIVE_CONFIG パラメータは プライマリ データベースからスタンバイ データベースへの REDO データの送信を許可し また スタンバイ データベースによるプライマリ データベースからのアーカイブ用の REDO の受信を許可します これは LOG_ARCHIVE_CONFIG パラメータの SEND および RECEIVE 属性を設定した場合と同じです 注意 : LOG_ARCHIVE_CONFIG 初期化パラメータは 廃止になった REMOTE_ARCHIVE_ENABLE 初期化パラメータを置き換えます これら両方のパラメータを同じ SPFILE またはテキスト初期化パラメータ ファイルで指定しないでください 5.5 エラーが発生した場合の対処方法 アーカイブ障害を処理するために LOG_ARCHIVE_DEST_n パラメータの REOPEN MAX_ FAILURES および ALTERNATE 属性を使用して 宛先へのアーカイブ プロセスが失敗した場合に実行する処置を指定できます これには次の処置が含まれます 指定した期間が経過した後 失敗した宛先へのアーカイブ操作を上限回数まで再試行する 代替宛先を使用する 接続を再確立して失敗した宛先への REDO データ送信を再開する試行回数を制御する アーカイブ操作の再試行 REOPEN 属性を使用して ARCn プロセスまたは LGWR プロセスがエラー発生後に失敗した宛先への REDO データ再送信を試行するかどうかと その時期を指定します REOPEN=seconds 属性を使用して エラー発生後にアーカイブ プロセスが失敗した宛先へのアクセスを再試行するまでの最小経過秒数を指定します デフォルト値は 300 秒です REOPEN 属性に設定した値は 接続障害のみでなくすべてのエラーに適用されます REOPEN=0 を指定すると このオプションをオフにすることができます これにより 障害発生後は宛先へのアクセスが再試行されなくなります 代替アーカイブ先への転送に失敗した場合に REOPEN 属性が 0( ゼロ ) に設定されていると REDO 転送サービスは次回の REDO データのアーカイブ時に データを代替アーカイブ先に送信しようとします 代替アーカイブ先の使用 ALTERNATE 属性では 元のアーカイブ先で障害が発生したときに使用できる代替アーカイブ先を定義します 代替アーカイブ先が指定されていない場合は 障害発生時に宛先が自動的に他の宛先に変更されることはありません 図 5-6 では REDO データがローカルのディスク デバイスにアーカイブされています 当初のアーカイブ先のデバイスがいっぱいであったり 利用できない場合 アーカイブ操作は自動的に代替アーカイブ先のデバイスにリダイレクトされます 5-18 Oracle Data Guard 概要および管理

95 エラーが発生した場合の対処方法 図 5-6 代替アーカイブ先のデバイスへのアーカイブ操作 再試行回数の制御 REOPEN 属性は ALTERNATE 属性よりも優先されます 代替アーカイブ先は 次のいずれかの条件が満たされている場合にのみ使用されます REOPEN 属性に 値 0( ゼロ ) が指定されている 0( ゼロ ) ではない REOPEN 属性で 0( ゼロ ) ではない MAX_FAILURE の件数を超過している ALTERNATE 属性は MANDATORY 属性よりも優先されます これは 現在の宛先が必須であっても 有効な代替アーカイブ先に宛先をフェイルオーバーすることを意味します 関連項目 : 14-4 ページ ALTERNATE MAX_FAILURE 属性を使用して REDO 転送サービスが失敗した宛先への REDO データの転送を継続的に試行する最大回数を指定します MAX_FAILURE 属性とともに REOPEN 属性を使用すると 失敗した宛先との接続を再確立するための継続的な試行回数を制限できます 指定した試行回数を超過すると その宛先は REOPEN 属性が 0( ゼロ ) に設定されていたものとして処理されます MAX_FAILURE 属性を使用する場合は REOPEN 属性は必須です 例 5-7 に 再試行時間を 60 秒に設定し 再試行回数を 3 回に制限する方法を示します 例 5-7 再試行時間の設定と制限 LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=60 MAX_FAILURE=3' REDO 転送サービス 5-19

96 データ保護モードの設定 5.6 データ保護モードの設定 Data Guard には 最大保護 最大可用性および最大パフォーマンスという 3 つのデータ保護モードが用意されています 選択したデータ保護レベルにより プライマリ データベースからスタンバイ データベースへの接続が失われた場合の動作が制御されます この項は 次の項目で構成されています データ保護モードの選択 Data Guard 構成のデータ保護モードの設定 データ保護モードの選択 適切なデータ保護モードを判断するには 次のデータ保護モードの説明を参考にして データ可用性に対するビジネス要件を応答時間とパフォーマンスに対するユーザーのニーズに基づいて査定します また データ保護モードの設定方法については 項を参照してください 最大保護モード この保護モードは プライマリ データベースに障害が発生した場合にも データ消失がないことを保証します このレベルの保護を提供するには トランザクションがコミットされる前に 各トランザクションをリカバリするために必要な REDO データを 少なくとも 1 つのスタンバイ データベース上のローカル オンライン REDO ログおよびスタンバイ REDO ログに書き込む必要があります 障害によって少なくとも 1 つのリモート スタンバイ REDO ログに REDO ストリームを書込みできない場合 データ消失が発生しないようにプライマリ データベースが停止します 複数インスタンス RAC データベースでは Data Guard は正しく構成された少なくとも 1 つのデータベース インスタンスに REDO レコードを書き込めない場合に プライマリ データベースを停止します 最大保護モードでは 少なくとも 1 つのスタンバイ インスタンスにスタンバイ REDO ログがあり この宛先について LOG_ARCHIVE_DEST_n パラメータに LGWR SYNC および AFFIRM 属性が使用されている必要があります 最大可用性モード この保護モードは プライマリ データベースの可用性を低下させない範囲で可能な最高レベルのデータ保護を提供します 最大保護モードと同様に トランザクションは そのトランザクションのリカバリに必要な REDO が ローカルのオンライン REDO ログおよび少なくとも 1 つのリモート スタンバイ REDO ログに書き込まれるまでコミットされません 障害によってリモート スタンバイ REDO ログに REDO ストリームを書込みできない場合 最大保護モードとは異なり プライマリ データベースは停止しません かわりに 障害が解決され REDO ログ ファイルのすべてのギャップが解決されるまで プライマリ データベースは最大パフォーマンス モードで動作します すべてのギャップが解決されると プライマリ データベースは 最大可用性モードでの動作を自動的に再開します このモードでは プライマリ データベースに障害が発生した場合 ただし 2 回目の障害でプライマリ データベースから少なくとも 1 つのスタンバイ データベースに REDO データの完全なセットが送信される場合にのみ データが消失しないことを保証します 最大保護モードと同様に 最大可用性モードには次の要件があります 1 つ以上のスタンバイ データベースでスタンバイ REDO ログ ファイルを構成します 1 つ以上のスタンバイ データベースについて LOG_ARCHIVE_DEST_n パラメータの SYNC LGWR および AFFIRM 属性を設定します 最大パフォーマンス モード この保護モード ( デフォルト ) は プライマリ データベースのパフォーマンスに影響しない範囲で可能な最高レベルのデータ保護を提供します これは トランザクションのリカバリに必要な REDO データがローカルのオンライン REDO ログに書き込まれた直後に そのトランザクションのコミットを許可することで実行されます プライマリ データベースの REDO データ ストリームは 少なくとも 1 つのスタンバイ データベースにも書き込まれますが その REDO ストリームは REDO データを作成するトランザクションのコミットメントについて非同期で書き込まれます 5-20 Oracle Data Guard 概要および管理

97 データ保護モードの設定 十分な帯域幅を持つネットワーク リンクが使用される場合 このモードは プライマリ データベースのパフォーマンスに対する影響を最小限にして 最大可用性モードのレベルに近いデータ保護レベルを提供します 最大パフォーマンス モードでは スタンバイ データベースの宛先について LOG_ ARCHIVE_DEST_n パラメータの LGWR および ASYNC 属性を設定するか または ARCH 属性を設定できます LGWR および ASYNC 属性を設定すると プライマリ データベースに障害が発生した場合に スタンバイ宛先で受信されないデータの量を減少させることができます Data Guard 構成のデータ保護モードの設定 表 5-2 データ保護モードの最低要件 REDO 転送サービスを設定して Data Guard 構成のデータ保護レベルを指定する手順は 次のとおりです 手順 1 プライマリ データベースで LOG_ARCHIVE_DEST_n パラメータを構成するプライマリ データベースで LOG_ARCHIVE_DEST_n パラメータの属性を適切に構成します Data Guard の各データ保護モードでは 構成内の少なくとも 1 つのスタンバイ データベースが表 5-2 に記載された一連の最低要件を満たしている必要があります 最大保護 最大可用性 最大パフォーマンス REDO アーカイブ プロセス LGWR LGWR LGWR または ARCH ネットワーク転送モード SYNC SYNC LGWR プロセスを使用する場合は SYNC または ASYNC ARCH プロセスを使用する場合は SYNC ディスク書込みオプション AFFIRM AFFIRM AFFIRM または NOAFFIRM スタンバイ REDO ログの必要性可可不要 ただし推奨 注意 : 最大保護モードで実行する Data Guard 構成には 表 5-2 に記載された要件を満たす少なくとも 2 つのスタンバイ データベースを含めることをお薦めします これによって 1 つのスタンバイ データベースがプライマリ データベースから REDO データを受信できない場合でも プライマリ データベースは処理を継続できます 次の例に 最大可用性モードの構成方法を示します SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=chicago 2> OPTIONAL LGWR SYNC AFFIRM 3> VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 4> DB_UNIQUE_NAME=chicago'; まだ SPFILE で指定されていない場合は DB_UNIQUE_NAME 初期化パラメータを使用して一意の名前も指定し LOG_ARCHIVE_CONFIG パラメータの DG_CONFIG 属性ですべてのデータベースをリストする必要があります 次に例を示します SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)' これにより Data Guard 構成内で Real Application Clusters プライマリ データベースが最大保護モードまたは最大可用性モードで稼働している場合 この Data Guard 構成にスタンバイ データベースを動的に追加できます REDO 転送サービス 5-21

98 データ保護モードの設定 手順 1 保護モードをアップグレードする場合は次の手順を実行するこの手順を実行するのは 保護モードを ( たとえば 最大パフォーマンス モードから最大可用性モードなどのように ) アップグレードする場合のみです それ以外の場合は 手順 3 に進みます この例では Data Guard 構成を最大パフォーマンス モードから最大可用性モードにアップグレードすると仮定します プライマリ データベースを停止し マウント済モードで再起動します SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; Real Application Clusters データベースの場合は すべてのプライマリ インスタンスを停止し その中の 1 つのみを起動してマウントします 手順 2 データ保護モードを設定するデータ保護モードを指定するには プライマリ データベースで SQL ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION AVAILABILITY PERFORMANCE} 文を発行します たとえば 次の文は最大可用性モードを指定します SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY; 手順 3 プライマリ データベースをオープンする手順 1 で保護モードをアップグレードした場合は データベースをオープンします SQL> ALTER DATABASE OPEN; 保護モードをダウングレードしている場合 データベースはすでにオープンしています 手順 4 スタンバイ データベースで LOG_ARCHIVE_DEST_n パラメータを構成するスタンバイ データベースで スイッチオーバー後も構成が新しい保護モードで操作を継続できるように LOG_ARCHIVE_DEST_n パラメータ属性を構成します 次に例を示します SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=boston 2> OPTIONAL LGWR SYNC AFFIRM 3> VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 4> DB_UNIQUE_NAME=boston'; 手順 5 構成が新しい保護モードで動作していることを確認する V$DATABASE ビューを問い合せ Data Guard 構成が新しい保護モードで動作していることを確認します 次に例を示します SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE; PROTECTION_MODE PROTECTION_LEVEL MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY SQL 文については 第 15 章および Oracle Database SQL リファレンス を参照してください 5-22 Oracle Data Guard 概要および管理

99 ログ ファイルの管理 5.7 ログ ファイルの管理 この項は 次の項目で構成されています アーカイブ REDO ログ ファイルの代替ディレクトリ位置の指定 オンライン REDO ログ ファイルの再利用 スタンバイ REDO ログ ファイルの管理 制御ファイルのサイズ拡大と再利用の計画 複数のスタンバイ データベース間でのログ ファイル宛先の共有 アーカイブ REDO ログ ファイルの代替ディレクトリ位置の指定 通常 プライマリ データベースから受信された REDO データは LOG_ARCHIVE_DEST_n パラメータの LOCATION 属性で指定したディレクトリに格納されているアーカイブ REDO ログ ファイルに書き込まれます かわりに スタンバイ データベースの STANDBY_ARCHIVE_ DEST 初期化パラメータで アーカイブ REDO ログ ファイルがプライマリ データベースから受信された際の代替格納先ディレクトリを指定することも可能です 両方のパラメータを指定すると STANDBY_ARCHIVE_DEST 初期化パラメータは LOG_ ARCHIVE_DEST_n パラメータで指定したディレクトリ位置より優先されます スタンバイ データベースでのアーカイブ REDO ログ ファイルの格納場所は 次に示す一連の規則に従って決定されます データベース インスタンスの起動時には アーカイブ REDO ログ ファイルが次の順序で評価されます 1. スタンバイ データベースで STANDBY_ARCHIVE_DEST 初期化パラメータが指定されている場合は その位置が使用されます 2. LOG_ARCHIVE_DEST_n パラメータに VALID_FOR=(STANDBY_LOGFILE,*) 属性が含まれている場合は この宛先に指定されている位置が使用されます 3. COMPATIBLE パラメータが 10.0 以上に設定され どの LOG_ARCHIVE_DEST_n パラメータにも VALID_FOR=(STANDBY_LOGFILE,*) 属性が含まれていない場合は 宛先に有効な任意の LOG_ARCHIVE_DEST_n パラメータが使用されます 4. どの初期化パラメータも指定されていない場合 アーカイブ REDO ログ ファイルは STANDBY_ARCHIVE_DEST 初期化パラメータのデフォルト位置に格納されます STANDBY_ARCHIVE_DEST 初期化パラメータの暗黙的なデフォルト値を表示するには V$ARCHIVE_DEST ビューを問い合せます SQL> SELECT DEST_NAME, DESTINATION FROM V$ARCHIVE_DEST 2> WHERE DEST_NAME='STANDBY_ARCHIVE_DEST'; DEST_NAME DESTINATION STANDBY_ARCHIVE_DEST /oracle/dbs/arch REDO 転送サービスでは STANDBY_ARCHIVE_DEST 初期化パラメータで指定された値とともに LOG_ARCHIVE_FORMAT パラメータを使用して スタンバイ サイトでアーカイブ REDO ログ ファイルのファイル名を生成します 次に例を示します STANDBY_ARCHIVE_DEST='/arc_dest/arls' LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc この例で %s は順序番号 %r はリセットログ ID です これらによってデータベースの複数のインカネーションにわたり 一意の名前がアーカイブ ログ ファイルに対して確実に構成されます Real Application Clusters の構成に必要な %t は スレッド番号に対応しています REDO 転送サービス 5-23

100 ログ ファイルの管理 フィジカル スタンバイ データベースの場合 REDO 転送サービスはスタンバイ データベースの制御ファイルに完全修飾名を格納し REDO Apply はこの情報を使用してスタンバイ データベースでリカバリを実行します 注意 : LOG_ARCHIVE_DEST_n パラメータの TEMPLATE 属性を指定すると STANDBY_ARCHIVE_DEST および LOG_ARCHIVE_FORMAT パラメータで生成されるファイル名は無視されます TEMPLATE 属性の詳細は 第 14 章を参照してください スタンバイ システム上のアーカイブ REDO ログ ファイルのリストを表示するには スタンバイ データベースで V$ARCHIVED_LOG ビューを問い合せます SQL> SELECT NAME FROM V$ARCHIVED_LOG; NAME /arc_dest/log_1_771.arc /arc_dest/log_1_772.arc /arc_dest/log_1_773.arc /arc_dest/log_1_774.arc /arc_dest/log_1_775.arc オンライン REDO ログ ファイルの再利用 LOG_ARCHIVE_DEST_n パラメータの OPTIONAL または MANDATORY 属性を設定して オンライン REDO ログ ファイルを再利用するためのポリシーを指定できます デフォルトで リモートの宛先は OPTIONAL に設定されます OPTIONAL の宛先のアーカイブ操作に障害が発生した場合 REDO データの転送とログの内容の書込みが失敗した場合にも オンライン REDO ログ ファイルを再利用できます MANDATORY の宛先へのアーカイブ操作に障害が発生した場合は その宛先への失敗したアーカイブが完了するまで オンライン REDO ログ ファイルは上書きできません デフォルトでは すべてのローカル宛先を OPTIONAL に指定しても 1 つの宛先は MANDATORY になります 例 5-8 に 必須のローカル アーカイブ先を設定してその宛先を使用可能にする方法を示します MANDATORY 属性を指定する場合は 障害条件を処理するために 5.5 項の説明に従って REOPEN および MAX_FAILURE 属性を指定することも考慮してください 例 5-8 必須のアーカイブ先の設定 LOG_ARCHIVE_DEST_3 = 'LOCATION=/arc_dest MANDATORY' 5-24 Oracle Data Guard 概要および管理

101 ログ ファイルの管理 スタンバイ REDO ログ ファイルの管理 この項は 次の項目で構成されています スタンバイ REDO ログ ファイル グループの構成が適切であるかの判断 スタンバイ REDO ログ メンバーを既存のグループに追加 スタンバイ REDO ログ ファイル グループの構成が適切であるかの判断 スタンバイ REDO ログのログ ファイル グループ数が適切かどうかを確認する最も容易な方法は RFS プロセスのトレース ファイルとデータベースのアラート ログを検討することです アーカイブが完了しないために RFS プロセスが頻繁にグループを待つ必要があることを示すメッセージがいずれかのログに含まれている場合は スタンバイ REDO ログにログ ファイル グループを追加します スタンバイ REDO ログ ファイル グループを追加することにより スタンバイ REDO ログ ファイルが RFS プロセスで再利用される前に アーカイブ操作を完了する時間が確保されます 注意 : オンライン REDO ログ ファイル グループをプライマリ データベースに追加した場合は 対応するスタンバイ REDO ログ ファイル グループをスタンバイ データベースに追加する必要があります スタンバイ REDO ログ ファイル グループの数が不十分な場合 プライマリ データベースが最大保護モードで作動しているときは停止し 最大可用性モードで作動しているときは最大パフォーマンス モードに切り替わります スタンバイ REDO ログ メンバーを既存のグループに追加 スタンバイ REDO ログ ファイルの完全なグループを作成する必要がない場合もあります グループがすでに存在するものの 1 つ以上のメンバーが削除されているため完全ではないことがあります ( たとえば ディスク障害のために ) この場合には 新しいメンバーを既存のグループに追加できます スタンバイ REDO ログ ファイル グループに新しいメンバーを追加するには ALTER DATABASE 文と ADD STANDBY LOGFILE MEMBER 句を使用します 次の文は 新しいメンバーをスタンバイ REDO ログ ファイル グループの番号 2 に追加します SQL> ALTER DATABASE ADD STANDBY LOGFILE MEMBER '/disk1/oracle/dbs/log2b.rdo' 2> TO GROUP 2; ファイルの作成場所を示すために新しいメンバーの完全修飾されたファイル名を使用します 完全修飾されたファイル名を使用しないと データベースのデフォルト ディレクトリまたはカレント ディレクトリのいずれかにファイルが作成されます REDO 転送サービス 5-25

102 ログ ファイルの管理 制御ファイルのサイズ拡大と再利用の計画 この項は 次の項目で構成されています 制御ファイルを含むディスク ボリュームのサイズ設定 制御ファイル内のレコードの再利用の指定 制御ファイルを含むディスク ボリュームのサイズ設定 アーカイブ REDO ログ ファイルが生成され Recovery Manager のバックアップが作成されると 制御ファイルの再利用可能セクションに新規レコードが追加されます 再利用可能なレコードがない場合 ( すべてのレコードが CONTROL_FILE_RECORD_KEEP_TIME で指定された日数の範囲内にあるためなど ) 制御ファイルが拡張され 新規レコードが追加されます 制御ファイルの最大サイズは データベース ブロックです DB_BLOCK_SIZE が 8192 の場合 制御ファイルの最大サイズは 156 MB です 制御ファイルが事前作成済ボリュームに格納される場合は プライマリおよびスタンバイ制御ファイルを含むボリュームのサイズを最大サイズの制御ファイルが収まるように設定する必要があります 制御ファイルのボリュームが小さすぎ 拡張できない場合は 意図した再利用の前に制御ファイル内の既存のレコードが上書きされます この動作は アラート ログの次のメッセージで示されます krcpwnc: following controlfile record written over: 制御ファイル内のレコードの再利用の指定 CONTROL_FILE_RECORD_KEEP_TIME 初期化パラメータは 制御ファイル内の再使用可能レコードが再使用可能になるまでの最小日数を指定します このパラメータを適切に設定すると REDO 転送サービスでは制御ファイル内の再利用可能なレコードが上書きされなくなり REDO 情報はスタンバイ データベースで常に使用可能になります CONTROL_FILE_RECORD_KEEP_TIME を ディスク上のすべてのバックアップ情報を制御ファイルに保持できる値に設定します CONTROL_FILE_RECORD_KEEP_TIME では レコードが再利用候補となるまでに制御ファイルに保持されている日数を指定します CONTROL_FILE_RECORD_KEEP_TIME を バックアップ領域のサイズに基づいて最も古いバックアップ ファイルをディスク上に保存する期間として判断したよりも少し長い値に設定します たとえば 7 日ごとに作成される 2 つの完全バックアップと毎日の増分バックアップおよびアーカイブ REDO ログ ファイルを維持するようにバックアップ領域がサイズ設定されている場合は CONTROL_FILE_RECORD_KEEP_TIME を値 21 または 30 に設定します この期間よりも古いレコードが再利用されます ただし バックアップ メタデータは RMAN Recovery Catalog で引き続き使用可能です スタンバイ データベースについて適用遅延も設定されている場合は (6.2.2 項を参照 ) 十分に大きい値を指定してください このパラメータの値の範囲は 0 ~ 365 日です デフォルト値は 7 日です CONTROL_FILE_RECORD_KEEP_TIME 初期化パラメータの詳細は Oracle Database リファレンス を参照してください また Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド も参照してください 5-26 Oracle Data Guard 概要および管理

103 ログ ファイルの管理 複数のスタンバイ データベース間でのログ ファイル宛先の共有 LOG_ARCHIVE_DEST_n 初期化パラメータの DEPENDENCY 属性を使用して 各宛先に REDO データを個別に転送するのではなく 複数の宛先のかわりに REDO データを受信するアーカイブ先を 1 つ定義します 図 5-7 に Data Guard 構成例を示します この構成では プライマリ データベースは 1 つのアーカイブ先に REDO データを転送し そのアーカイブ REDO ログ ファイルはロジカル スタンバイ データベースおよびフィジカル スタンバイ データベースの両方で共有されます これらの宛先は 親の宛先へのアーカイブ操作が正常に完了することに依存します 図 5-7 依存する宛先を含む Data Guard 構成 宛先依存性を指定すると 次に示すような場合に便利です フィジカル スタンバイ データベースとロジカル スタンバイ データベースを同じシステム上で構成する場合 スタンバイ データベースとプライマリ データベースを同じシステム上で構成する場合 このため アーカイブ REDO ログ ファイルが暗黙的にスタンバイ データベースの影響を受けやすい状態にあります クラスタ化されたファイル システムが リモートのスタンバイ データベースにプライマリ データベースのアーカイブ REDO ログ ファイルへのアクセスを提供するために使用される場合 オペレーティング システム固有のネットワーク ファイル システムが使用され リモートのスタンバイ データベースに プライマリ データベースのアーカイブ REDO ログ ファイルへのアクセスを提供する場合 たとえば 2 つのスタンバイ データベース stdby1 および stdby2 がハードウェアの同一部分に存在するとします この場合 ネットワーク帯域幅とディスク容量を使用しなくても 同じ REDO データを両方の宛先に送信できます DEPENDENCY 属性を使用して宛先の一方を依存する宛先として指定すると 両方のデータベースで同じアーカイブ REDO ログ ファイルを共有できます つまり プライマリ データベースが REDO を送信すると 依存する宛先として定義されていない方の宛先にアーカイブされます その宛先に REDO データが正常に送信されると プライマリ データベースは両方の宛先にアーカイブされたものとみなします 次に例を示します LOG_ARCHIVE_DEST_1='LOCATION=DISK1 MANDATORY' LOG_ARCHIVE_DEST_2='SERVICE=stdby1 OPTIONAL' LOG_ARCHIVE_DEST_3='SERVICE=stdby2 OPTIONAL DEPENDENCY=LOG_ARCHIVE_DEST_2' REDO 転送サービス 5-27

104 アーカイブ ギャップの管理 これらのパラメータを定義すると プライマリ データベースは REDO データを stdby2 ではなく stdby1 に転送します かわりに stdby2 データベースは stdby1 に送信されたアーカイブ REDO ログ ファイルから REDO をリカバリします 5.8 アーカイブ ギャップの管理 アーカイブ ギャップは スタンバイ システムがプライマリ データベースによって生成された 1 つ以上のアーカイブ REDO ログ ファイルを受信していないときに スタンバイ システムで発生する可能性があります 欠落しているアーカイブ REDO ログ ファイルがギャップです ギャップがある場合 そのギャップは Data Guard によって自動的に検出され 欠落しているログ ファイルの順序番号をスタンバイ宛先にコピーすることで解決されます たとえば アーカイブ ギャップは ネットワークが使用不可能になり プライマリ データベースからスタンバイ データベースへの自動アーカイブが一時的に停止すると発生する可能性があります ネットワークが再度使用可能になると プライマリ データベースからスタンバイ データベースへの REDO データの自動転送が再開します Data Guard の場合 このようなギャップの検出と解決に DBA による手動操作は必要ありません 次の各項では ギャップの検出と解決について説明します アーカイブ ギャップの検出時期 アーカイブ ギャップは プライマリ データベースがローカルにアーカイブしたログが スタンバイ サイトでは受信されなかった場合に発生する可能性があります プライマリ データベースは 1 分ごとにスタンバイ データベースをポーリングして アーカイブ REDO ログ ファイルの順序番号にギャップがあるかどうかを確認します ギャップの解決方法 関連項目 : ページ DEPENDENCY ギャップ リカバリは ポーリング メカニズムを使用して処理されます フィジカルおよびロジカル スタンバイ データベース Oracle Change Data Capture および Oracle Streams の場合 Data Guard はギャップ検出を実行し 欠落しているアーカイブ REDO ログ ファイルをプライマリ データベースから自動的に取得することで解決します スタンバイ データベースのポーリング ギャップの検出または解決のために 余分な構成設定を行う必要はありません ここで重要なことは 自動ギャップ リカバリの実行には プライマリ データベースの可用性が不可欠であることです プライマリ データベースが使用不可能な場合 構成に複数のフィジカル スタンバイ データベースが含まれていれば REDO Apply によって別のスタンバイ データベースからアーカイブ ギャップを解決できるように初期化パラメータを追加設定できます 詳細は 項を参照してください ギャップを手動で解決する方法を示す使用例については 項を参照してください 注意 : Oracle Database 10g リリース 1(10.1) までは プライマリ データベースからのギャップを解決するために FAL クライアントおよびサーバーが使用されていました 5-28 Oracle Data Guard 概要および管理

105 アーカイブ ギャップの管理 フェッチ アーカイブ ログ (FAL) を使用したアーカイブ ギャップの解決 フェッチ アーカイブ ログ (FAL) クライアントおよびサーバーは プライマリ データベースで生成されてフィジカル スタンバイ データベースで受信されたアーカイブ REDO ログ ファイルの範囲内で 検出されたギャップを解決します FAL クライアントは アーカイブ REDO ログ ファイルの転送を自動的に要求します FAL サーバーは FAL クライアントからの FAL 要求を処理します FAL メカニズムでは 次のタイプのアーカイブ ギャップと問題が処理されます フィジカルまたはロジカル スタンバイ データベースの作成時に FAL メカニズムでは プライマリ データベースのホット バックアップ中に生成されたアーカイブ REDO ログ ファイルを自動的に取得できます すでにスタンバイ データベースで受信されているアーカイブ REDO ログ ファイルに問題があると FAL メカニズムはアーカイブ REDO ログ ファイルを自動的に取得して 次の状況を解決できます アーカイブ REDO ログ ファイルが スタンバイ データベースに適用される前にディスクから削除された場合 ディスク破損のためにアーカイブ REDO ログ ファイルを適用できない場合 REDO データがスタンバイ データベースに適用される前に アーカイブ REDO ログ ファイルがそれ以外のファイル ( テキスト ファイルなど ) によって意図せずに置換された場合 複数のフィジカル スタンバイ データベースがある場合 FAL メカニズムは欠落しているアーカイブ REDO ログ ファイルを別のフィジカル スタンバイ データベースから自動的に取得できます FAL クライアントおよびサーバーは スタンバイ データベースで設定される FAL_CLIENT および FAL_SERVER 初期化パラメータを使用して構成されます 初期化パラメータ ファイルの FAL_CLIENT および FAL_SERVER 初期化パラメータを フィジカル スタンバイ データベースに対してのみ次の表に従って定義してください パラメータ FAL_SERVER FAL_CLIENT 機能 スタンバイ データベースが FAL サーバーへの接続に使用するネットワーク サービス名を指定します リストには複数の値を指定できます FAL サーバーがスタンバイ データベースへの接続に使用するネットワーク サービス名を指定します 構文構文 FAL_SERVER=net_service_name 例 FAL_SERVER=standby2_db,standby3_db 構文 FAL_CLIENT=net_service_name 例 FAL_CLIENT=standby1_db REDO 転送サービス 5-29

106 アーカイブ ギャップの管理 手動によるアーカイブ ギャップの判断および解決 自動ギャップ リカバリを実行できず ギャップ リカバリを手動で実行する必要がある場合があります たとえば ロジカル スタンバイ データベースの使用中にプライマリ データベースが使用不可能になった場合は ギャップ リカバリを手動で実行する必要があります 次の各項では 適切なビューを問い合せて欠落しているログ ファイルを判断し 手動によるリカバリを実行する方法を説明します フィジカル スタンバイ データベースの場合フィジカル スタンバイ データベースにアーカイブ ギャップが存在するかどうかを判断するには 次の例に示すように V$ARCHIVE_GAP ビューを問い合せます SQL> SELECT * FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# この出力例は 現在フィジカル スタンバイ データベースでスレッド 1 の順序番号 7 ~ 10 のログ ファイルが欠落していることを示しています ギャップを識別した後 プライマリ データベースで次の SQL 文を発行し プライマリ データベースのアーカイブ REDO ログ ファイルの位置を特定します ( プライマリ データベースのローカル アーカイブ先は LOG_ ARCHIVE_DEST_1 とします ) SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND 2> SEQUENCE# BETWEEN 7 AND 10; NAME /primary/thread1_dest/arcr_1_7.arc /primary/thread1_dest/arcr_1_8.arc /primary/thread1_dest/arcr_1_9.arc これらのログ ファイルをフィジカル スタンバイ データベースにコピーし コピーしたログを ALTER DATABASE REGISTER LOGFILE 文を使用してフィジカル スタンバイ データベースに登録します 次に例を示します SQL> ALTER DATABASE REGISTER LOGFILE '/physical_standby1/thread1_dest/arcr_1_7.arc'; SQL> ALTER DATABASE REGISTER LOGFILE '/physical_standby1/thread1_dest/arcr_1_8.arc'; ログ ファイルをフィジカル スタンバイ データベースに登録した後は REDO Apply を再開できます 注意 : フィジカル スタンバイ データベースの V$ARCHIVE_GAP 固定ビューが戻すのは REDO Apply の続行をブロックしている次のギャップのみです そのギャップを解決して REDO Apply を開始した後 V$ARCHIVE_GAP 固定ビューをフィジカル スタンバイ データベースで再度問い合せて 次のギャップ シーケンス ( 存在する場合 ) を判断します この処理をギャップがなくなるまで繰り返します 5-30 Oracle Data Guard 概要および管理

107 アーカイブ ギャップの管理 ロジカル スタンバイ データベースの場合アーカイブ ギャップが存在するかどうかを判断するには ロジカル スタンバイ データベースで DBA_LOGSTDBY_LOG ビューを問い合せます たとえば 次の問合せでは ロジカル スタンバイ データベースの THREAD 1 に 2 つのファイルが表示されているため アーカイブ REDO ログ ファイルの順序番号にギャップがあることを示しています ( ギャップがない場合 問合せで表示されるのは スレッドごとに 1 つのファイルのみです ) この出力は 登録されたファイルの最大の順序番号は 10 ですが 順序番号 6 で示されるファイルにギャップがあることを示しています SQL> COLUMN FILE_NAME FORMAT a55 SQL> SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L 2> WHERE NEXT_CHANGE# NOT IN 3> (SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#) 4> ORDER BY THREAD#,SEQUENCE#; THREAD# SEQUENCE# FILE_NAME /disk1/oracle/dbs/log _6.arc 1 10 /disk1/oracle/dbs/log _10.arc 順序番号 7 8 および 9 の欠落しているログ ファイルをロジカル スタンバイ システムにコピーし コピーしたログを ALTER DATABASE REGISTER LOGICAL LOGFILE 文を使用してロジカル スタンバイ データベースに登録します 次に例を示します SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/disk1/oracle/dbs/log _10.arc'; ログ ファイルをロジカル スタンバイ データベースに登録した後は SQL Apply を再開できます 注意 : ロジカル スタンバイ データベースの DBA_LOGSTDBY_LOG ビューが戻すのは SQL Apply の続行をブロックしている次のギャップのみです 識別したギャップを解決して SQL Apply を開始した後 DBA_ LOGSTDBY_LOG ビューをロジカル スタンバイ データベースで再度問い合せて 次のギャップ シーケンス ( 存在する場合 ) を判断します この処理をギャップがなくなるまで繰り返します REDO 転送サービス 5-31

108 確認 5.9 確認 この項は 次の項目で構成されています ログ ファイル アーカイブ情報の監視 REDO 転送サービスのパフォーマンスの監視 ログ ファイル アーカイブ情報の監視 この項では ビューを使用してプライマリ データベースの REDO ログ アーカイブ アクティビティを監視する方法を説明します Data Guard 環境の監視に関係する多数のタスクを自動化するグラフィカル ユーザー インタフェースの詳細は Oracle Data Guard Broker および Oracle Enterprise Manager のオンライン ヘルプを参照してください 手順 1 REDO ログ ファイルのステータスを判定するプライマリ データベースで次の問合せを入力して すべてのオンライン REDO ログ ファイルのステータスを判定します SQL> SELECT THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$LOG; 手順 2 最新のアーカイブ REDO ログ ファイルを判定するプライマリ データベースで次の問合せを入力して 最後にアーカイブされたスレッドおよび順序番号を判定します SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#; 手順 3 各アーカイブ先で最新のアーカイブ REDO ログ ファイルを判定するプライマリ データベースで次の問合せを入力して アーカイブ先ごとに 最後に転送されたアーカイブ REDO ログ ファイルを判定します SQL> SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ# 2> FROM V$ARCHIVE_DEST_STATUS 3> WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE'; DESTINATION STATUS ARCHIVED_THREAD# ARCHIVED_SEQ# /private1/prmy/lad VALID standby1 VALID 最後に書き込まれたアーカイブ REDO ログ ファイルは リストされた各アーカイブ先で同じである必要があります 同じでない場合は その宛先へのアーカイブ操作の間に検出されたエラーは VALID 以外のステータスで表示されます 手順 4 アーカイブ REDO ログ ファイルが受信されたかどうかを確認するアーカイブ REDO ログ ファイルが特定のサイトで受信されなかったかどうかは プライマリ データベースで問合せを発行して確認できます 各宛先には対応付けられた ID 番号があります プライマリ データベースの V$ARCHIVE_DEST 固定ビューの DEST_ID 列に問合せを発行して 各宛先の ID 番号を特定できます カレント ローカル宛先が 1 で リモート スタンバイ宛先の ID の 1 つが 2 とします この場合 どのログ ファイルがこのスタンバイ宛先で欠落しているかを特定するために 次の問合せを発行します SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM 2> (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) 3> LOCAL WHERE 4> LOCAL.SEQUENCE# NOT IN 5> (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND 6> THREAD# = LOCAL.THREAD#); 5-32 Oracle Data Guard 概要および管理

109 確認 THREAD# SEQUENCE# プライマリ データベースのアーカイブ ステータス監視の詳細は 付録 A を参照してください 手順 5 スタンバイ サイトで転送された REDO の進行状況をトレースするスタンバイ宛先への REDO データの転送の進行状況を確認するには プライマリおよびスタンバイ初期化パラメータ ファイルに LOG_ARCHIVE_TRACE パラメータを設定します 詳細と例は 付録 G を参照してください REDO 転送サービスのパフォーマンスの監視 この項では REDO 転送サービスのパフォーマンスを監視する待機イベントについて説明します これらのログ転送サービスは プライマリ データベースで LOG_ARCHIVE_DEST_n 初期化パラメータの ARCH LGWR SYNC および ASYNC 属性を使用して指定されます 次の各項では V$SYSTEM_EVENT ビューで表示される待機イベントおよび関連する時間情報について説明します ARCn プロセスの待機イベント LGWR SYNC 待機イベント LGWR ASYNC 待機イベント ARCn プロセスの待機イベント 表 5-3 に ARCn アーカイブ プロセスについて 転送モードで ARCH を使用している場合の複数の待機イベントを示しています 各待機イベントは RFS 接続の起動または削除の所要時間 およびスタンバイ データベースに対する REDO データの送信所要時間を監視します ARCn アーカイブ プロセスについては 項を参照してください 表 5-3 ARCH 属性で構成される宛先の待機イベント 待機イベント ARCH wait on ATTACH ARCH wait on SENDREQ ARCH wait on DETACH 待機時間の監視対象 すべての ARCn プロセスによる RFS 接続の生成 すべての ARCn プロセスによる 受信した REDO データのディスクへの書込み およびリモートのアーカイブ REDO ログ ファイルのオープンおよびクローズ すべての ARCn プロセスによる RFS 接続の削除 REDO 転送サービス 5-33

110 確認 LGWR SYNC 待機イベント 表 5-4 に LGWR SYNC アーカイブ プロセスについて プライマリ データベースの LGWR プロセスによる次の操作の実行所要時間を監視する複数の待機イベントを示します プライマリ データベースのオンライン REDO ログ ファイルへの書込み完了 リモート スタンバイ宛先への REDO データの転送 スタンバイ REDO ログ ファイルへの REDO データ書込みの待機 リモート スタンバイ宛先からの応答の受信 LGWR SYNC アーカイブ プロセスについては 項を参照してください 表 5-4 LGWR SYNC 属性で構成される宛先の待機イベント 待機イベント LGWR wait on LNS LNS wait on ATTACH LNS wait on SENDREQ LNS wait on DETACH 待機時間の監視対象 LNSn プロセスからメッセージを受信するまでの LGWR プロセスの待機 すべてのネットワーク サーバーによる RFS 接続の生成 すべてのネットワーク サーバーによる 受信した REDO データのディスクへの書込み およびリモートのアーカイブ REDO ログ ファイルのオープンおよびクローズ すべてのネットワーク サーバーによる RFS 接続の削除 LGWR ASYNC 待機イベント 表 5-5 に LGWR ASYNC アーカイブ プロセスについて プライマリ データベースのオンライン REDO ログ ファイルに REDO データを書き込む所要時間を監視する複数の待機イベントを示します LGWR ASYNC アーカイブ プロセスについては 項を参照してください 表 5-5 LGWR ASYNC 属性で構成される宛先の待機イベント 待機イベント LNS wait on DETACH LNS wait on ATTACH LNS wait on SENDREQ True ASYNC Control FileTXN Wait 待機時間の監視対象 すべてのネットワーク サーバーによる RFS 接続の削除 すべてのネットワーク サーバーによる RFS 接続の生成 すべてのネットワーク サーバーによる 受信した REDO データのディスクへの書込み およびリモートのアーカイブ REDO ログ ファイルのオープンおよびクローズ LNSn プロセスによるライフタイム中の制御ファイル トランザクションの保留 True ASYNC Wait for ARCH log アーカイブ REDO ログを参照するまでの LNSn プロセスの待機 (LNSn プロセスが現行のログ ファイルをアーカイブ中でログ スイッチが発生する場合 ) Waiting for ASYNC dest activation True ASYNC log-end-of-file wait アクティブでない宛先がアクティブになるまでの LNSn プロセスの待機 論理的なファイルの終わりに達した後で次の REDO ビットに達するまでの LNSn プロセスの待機 5-34 Oracle Data Guard 概要および管理

111 6 ログ適用サービス この章では REDO データをスタンバイ データベースに適用する方法について説明します この章は 次の項目で構成されています ログ適用サービスの概要 ログ適用サービスの構成オプション REDO データのフィジカル スタンバイ データベースへの適用 REDO データのロジカル スタンバイ データベースへの適用 ログ適用サービス 6-1

112 ログ適用サービスの概要 6.1 ログ適用サービスの概要 デフォルトでは ログ適用サービスは いっぱいになったアーカイブ REDO ログ ファイルがスタンバイ データベースで受信されるのを待機してから スタンバイ データベースに適用します 項および 項では プライマリ データベースから転送された REDO データが スタンバイ システムのリモート ファイル サーバー プロセス (RFS) でどのように受信されるかについて説明しました スタンバイ システムでは RFS プロセスにより アーカイブ REDO ログ ファイルまたはスタンバイ REDO ログ ファイル ( オプション ) に REDO データが書き込まれます ただし スタンバイ REDO ログ ファイルを使用している場合は オプションでリアルタイム適用リアルタイム適用を使用可能にできます リアルタイム適用により Data Guard では 現在のスタンバイ REDO ログ ファイルが RFS プロセスによっていっぱいになったときに 現在のスタンバイ REDO ログ ファイルから REDO データをリカバリできます リアルタイム適用については 項を参照してください ログ適用サービスは 次の方法でフィジカル スタンバイ データベースとロジカル スタンバイ データベースをメンテナンスします REDO Apply( フィジカル スタンバイ データベースのみ ) ログ適用サービスは スタンバイ データベースに REDO を自動的に適用して プライマリ データベースとの同期を維持します また データに対するトランザクションの一貫性のあるアクセスを可能にします メディア リカバリを使用して プライマリ データベースとフィジカル スタンバイ データベースの同期を維持します 注意 : ユーザーがレポート生成のためにスタンバイ データベースを問合せできるように フィジカル スタンバイ データベースを読取り専用モードでオープンすることもできます オープン中も REDO データは受信されます ただし REDO Apply は停止し フィジカル スタンバイ データベースでは プライマリ データベースとのトランザクションの同期が維持されません このときに障害が発生すると フェイルオーバー操作が完了するまでに時間がかかる場合があります 詳細は 8.2 項 スタンバイ データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法 を参照してください SQL Apply( ロジカル スタンバイ データベースのみ ) プライマリ データベースから受信した REDO に基づいて SQL 文を再構成し その SQL 文をロジカル スタンバイ データベースに対して実行します ロジカル スタンバイ データベースは読取り / 書込みモードでオープンできますが レポート生成のためにロジカル スタンバイ データベースでメンテナンスされているターゲット表は読取り専用モードでオープンします ( データベース ガードが適切に設定されている場合 ) SQL Apply を使用すると SQL 文が適用されている間でも ロジカル スタンバイ データベースをレポート アクティビティで使用できます この章の各項では REDO Apply SQL Apply リアルタイム適用および適用の遅延について詳細に説明します 6-2 Oracle Data Guard 概要および管理

113 ログ適用サービスの構成オプション 6.2 ログ適用サービスの構成オプション この項は 次の項目で構成されています リアルタイム適用による REDO データの即時適用 アーカイブ REDO ログ ファイルの適用に対するタイム ディレイの指定 リアルタイム適用による REDO データの即時適用 リアルタイム適用機能が使用可能になっている場合 ログ適用サービスでは 現在のスタンバイ REDO ログ ファイルがアーカイブされるのを待機せずに REDO データを受信したときに REDO データを適用できます これにより スイッチオーバーおよびフェイルオーバーが高速化されます これは フェイルオーバーまたはスイッチオーバーが開始されるまでに スタンバイ REDO ログ ファイルがスタンバイ データベースにすでに適用されているためです 次のように ALTER DATABASE 文を使用して リアルタイム適用機能を使用可能にします フィジカル スタンバイ データベースの場合は ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE 文を発行します ロジカル スタンバイ データベースの場合は ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE 文を発行します リアルタイム適用を使用するには スタンバイ REDO ログ ファイルが必要です 図 6-1 に ローカル宛先とスタンバイ宛先がある Data Guard 構成を示します リモート ファイル サーバー (RFS) プロセスは スタンバイ データベース上のスタンバイ REDO ログ ファイルに REDO データを書き込むため ログ適用サービスでは いっぱいになったときにスタンバイ REDO ログ ファイルから REDO をリカバリできます 図 6-1 リアルタイム適用を使用したスタンバイ宛先への REDO データの適用 ログ適用サービス 6-3

114 ログ適用サービスの構成オプション アーカイブ REDO ログ ファイルの適用に対するタイム ディレイの指定 プライマリ サイトから REDO データを受信した後 その REDO データをスタンバイ データベースに適用するまでの間にタイム ラグを作成することが必要な場合があります 時間間隔 ( 分単位 ) を指定すると 破損したデータや誤ったデータがスタンバイ サイトに適用されるのを防止できます DELAY 間隔を設定すると スタンバイ データベースへの REDO データの転送が遅延することはありません かわりに 指定したタイム ラグは REDO データがスタンバイ宛先で完全にアーカイブされたときに開始します 注意 : リアルタイム適用が使用可能になっている宛先に遅延を定義すると その遅延は無視されます タイム ディレイの指定次のように プライマリ データベースとスタンバイ データベースでタイム ディレイを設定できます フィジカル スタンバイ データベースで LOG_ARCHIVE_DEST_n 初期化パラメータの DELAY=minutes 属性を使用して スタンバイ データベースへのアーカイブ REDO ログ ファイルの適用を遅延します この属性のデフォルト設定は NODELAY です 値を指定せずに DELAY 属性を指定すると デフォルトの遅延間隔は 30 分になります ロジカル スタンバイ データベースで DBMS_LOGSTDBY.APPLY_SET プロシージャを使用します 複数のスタンバイ データベースがある構成では 1 つ以上のスタンバイ データベースにタイム ラグを設定すると非常に便利な場合があります たとえば プライマリ データベースと様々なレベルで同期させる各スタンバイ データベースを維持する構成を設定できます タイム ディレイの取消し次のように 指定した遅延間隔を取り消すことができます フィジカル スタンバイ データベースで RECOVER MANAGED STANDBY DATABASE 句の NODELAY キーワードを使用します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY; ロジカル スタンバイ データベースで 次の SQL コマンドを指定します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY; これらのコマンドにより 時間間隔が経過する前に ログ適用サービスで スタンバイ データベースへのアーカイブ REDO ログ ファイルの適用が即時に開始されます 次の項およびマニュアルも参照してください 12.8 項 タイム ラグのあるフィジカル スタンバイ データベースの使用 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 文の DELAY 属性については Oracle Database SQL リファレンス を参照してください DBMS_LOGSTDBY.APPLY_SET プロシージャを使用したロジカル スタンバイ データベースについては Oracle Database PL/SQL パッケージ プロシージャおよびタイプ リファレンス を参照してください タイム ディレイ設定の代替策としてのフラッシュバック データベースの使用 適用遅延を設定するかわりにフラッシュバック データベースを使用して スタンバイ データベースへの破損データやエラー データの適用からリカバリできます フラッシュバック データベースを使用すると スタンバイ データベースを任意の時点まで すばやく容易にフラッシュ バックできます Data Guard とフラッシュバック データベースの併用方法の使用例は第 12 章を フラッシュバック データベースを有効にして使用する方法の詳細は Oracle Database バックアップおよびリカバリ基礎 を参照してください 6-4 Oracle Data Guard 概要および管理

115 REDO データのフィジカル スタンバイ データベースへの適用 6.3 REDO データのフィジカル スタンバイ データベースへの適用 デフォルトでは アーカイブ REDO ログ ファイルからの REDO データが適用されます REDO Apply を実行している場合 フィジカル スタンバイ データベースはリアルタイム機能を使用して スタンバイ REDO ログ ファイルが RFS プロセスによって書き込まれているときに スタンバイ REDO ログ ファイルから直接 REDO を適用できます ログ適用サービスは フィジカル スタンバイ データベースが読取り専用でオープンしているときは REDO データをデータベースに適用できないことに注意してください この項は 次の項目で構成されています REDO Apply の開始 リアルタイム適用の開始 ログ適用サービスの停止 フィジカル スタンバイ データベースでのログ適用サービスの監視 REDO Apply の開始 フィジカル スタンバイ データベースでログ適用サービスを開始するには フィジカル スタンバイ データベースが起動されマウントされていることを確認してから SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 文を使用して REDO Apply を開始します REDO Apply をフォアグラウンド セッションとして実行するか バックグラウンド プロセスとして実行するかを指定できます REDO Apply をフォアグラウンドで開始するには 次の SQL 文を発行します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE; フォアグラウンド セッションを開始すると 別のセッションでリカバリが取り消されるまで 制御がコマンド プロンプトに戻りません REDO Apply をバックグラウンドで開始するには この SQL 文に DISCONNECT キーワードを挿入します 次に例を示します リアルタイム適用の開始 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; この文によって 分離されたサーバー プロセスが起動し 即時に制御がユーザーに戻されます 管理リカバリ プロセスがバックグラウンドでリカバリを実行している間 RECOVER 文を発行したフォアグラウンド プロセスは 他のタスクの実行を継続できます これによって カレント SQL セッションが切断されることはありません リアルタイム適用を開始するには SQL 文に USING CURRENT LOGFILE 句を含めます 次に例を示します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE; ログ適用サービス 6-5

116 REDO データのロジカル スタンバイ データベースへの適用 ログ適用サービスの停止 REDO Apply またはリアルタイム適用を停止するには 別のウィンドウで次の SQL 文を発行します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; フィジカル スタンバイ データベースでのログ適用サービスの監視 フィジカル スタンバイ データベースでのログ適用サービスのステータスを監視するには 項を参照してください スタンバイ データベースは Oracle Enterprise Manager を使用して監視することもできます また ビューの詳細は Oracle Database リファレンス を参照してください 6.4 REDO データのロジカル スタンバイ データベースへの適用 ログ適用サービスは アーカイブ REDO ログまたはスタンバイ REDO ログのデータを SQL 文に変換してから その SQL 文をロジカル スタンバイ データベースで実行します ロジカル スタンバイ データベースはオープン状態のままであるため メンテナンスされる表は レポート生成 要約 問合せなどの他のタスクで同時に使用できます この項は 次の項目で構成されています SQL Apply の開始 リアルタイム適用の開始 ロジカル スタンバイ データベースでのログ適用サービスの停止 ロジカル スタンバイ データベースでのログ適用サービスの監視 SQL Apply の開始 SQL Apply を開始するには ロジカル スタンバイ データベースを起動し 次の文を発行して ロジカル スタンバイ データベースのアーカイブ REDO ログ ファイルから REDO データをリカバリします SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; リアルタイム適用の開始 ロジカル スタンバイ データベースでリアルタイム適用を開始して ロジカル スタンバイ データベースのスタンバイ REDO ログ ファイルから REDO データを即時にリカバリするには 次の文に示すように IMMEDIATE キーワードを含めます SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; ロジカル スタンバイ データベースでのログ適用サービスの停止 SQL Apply を停止するには ロジカル スタンバイ データベースで次の文を発行します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; この文を発行すると SQL Apply は適用対象プロセス内の完了トランザクションがすべてコミットされるまで待機します つまり このコマンドを実行しても SQL Apply プロセスが即時に停止しない場合があります SQL Apply を即時に停止する場合は 次の文を発行します SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY; 6-6 Oracle Data Guard 概要および管理

117 REDO データのロジカル スタンバイ データベースへの適用 ロジカル スタンバイ データベースでのログ適用サービスの監視 SQL Apply を監視するには 9.2 項を参照してください スタンバイ データベースは Oracle Enterprise Manager を使用して監視することもできます 付録 A Data Guard のトラブルシューティング および Oracle Data Guard Broker を参照してください また ビューの詳細は 項の V$ARCHIVE_DEST_STATUS 固定ビューの説明 および Oracle Database リファレンス を参照してください ログ適用サービス 6-7

118 REDO データのロジカル スタンバイ データベースへの適用 6-8 Oracle Data Guard 概要および管理

119 7 ロールの推移 Data Guard 構成は プライマリ ロールで機能する 1 つのデータベース およびスタンバイ ロールで機能する 1 つ以上のデータベースで構成されています 通常 各データベースのロールは変更されません ただし プライマリ データベースが停止したときに Data Guard を使用してサービスを維持する場合は 構成内の現行のプライマリ データベースと 1 つのスタンバイ データベース間でロールの推移を開始する必要があります データベースの現行のロールを表示するには V$DATABASE ビューの DATABASE_ROLE 列を問い合せます Data Guard 構成内のスタンバイ データベースの数 位置 タイプ ( フィジカルまたはロジカル ) およびプライマリ データベースからの REDO データを各スタンバイ データベースに伝播する方法に応じて プライマリ データベースの停止に対して設定できるロール管理オプションが決定します この章では Data Guard 構成でロールの水位を管理する方法について説明します この章は 次の項目で構成されています ロールの推移の概要 フィジカル スタンバイ データベースが関与するロールの推移 ロジカル スタンバイ データベースが関与するロールの推移 ロールの推移後のフラッシュバック データベースの使用 この章で説明するロールの推移は SQL 文を使用して手動で起動します Oracle Data Guard Broker を使用し ロールの推移を単純化してフェイルオーバーを自動化することもできます 関連項目 : Oracle Data Guard Broker を次の目的で使用する方法については Oracle Data Guard Broker を参照してください Oracle Enterprise Manager で単一キー クリックを使用するか DGMGRL コマンドライン インタフェースで単一コマンドを使用して起動できるように スイッチオーバーとフェイルオーバーを単純化します プライマリ データベースが使用不可能になった場合に ファスト スタート フェイルオーバーによる自動的なフェイルオーバーを可能にします ファスト スタート フェイルオーバーが有効化されている場合 Data Guard Broker はフェイルオーバーが必要かどうかを判断し 指定されたターゲット スタンバイ データベースへのフェイルオーバーを自動的に開始します データベース管理者が介入する必要はなく データが消失することはありません ロールの推移 7-1

120 ロールの推移の概要 7.1 ロールの推移の概要 データベースは 相互に排他的な次の 2 つのロールのいずれかで実行されます 2 つのロールとは プライマリプライマリとスタンバイスタンバイです Data Guard では この章で説明する SQL 文を発行するか Data Guard Broker の GUI またはコマンドライン インタフェースを使用して これらのロールを動的に変更できます Oracle Data Guard は 次のロールの推移をサポートしています スイッチオーバープライマリ データベースが スタンバイ データベースの 1 つを使用してロールを切り替えられるようにします スイッチオーバー時には データは消失しません スイッチオーバーの完了後 各データベースは 新しいロールとともに Data Guard 構成に継続して含まれます フェイルオーバープライマリ データベースの障害時に スタンバイ データベースをプライマリ ロールに変更します 障害の前にプライマリ データベースが最大保護モードまたは最大可用性モードで動作していなかった場合 データ消失が発生することがあります フラッシュバック データベースが使用可能になっている場合は 障害の原因が修正された後 障害が発生したデータベースを元どおり新規プライマリ データベースのスタンバイに戻すことができます 7-2 ページ 項 ロールの推移 ( フェイルオーバーまたはスイッチオーバー ) の準備 では 停止時間およびデータ消失のリスクを最小限にするために どのロールの推移を選択するかについて説明します 7-4 ページ 項 スイッチオーバー および 7-6 ページ 項 フェイルオーバー では それぞれスイッチオーバーとフェイルオーバーの詳細を説明します ロールの推移 ( フェイルオーバーまたはスイッチオーバー ) の準備 ロールの推移を開始する前に 次の準備を実行します 各データベースの初期化パラメータが正しく構成されていることを確認してください ロールの推移後に Data Guard 構成が正しく動作するように プライマリおよびスタンバイ データベースで初期化パラメータを構成する方法については 第 3 章 フィジカル スタンバイ データベースの作成 および第 4 章 ロジカル スタンバイ データベースの作成 を参照してください フィジカル スタンバイ データベースを作成するときに手動で REDO ログ ファイルを追加する方法については 3-3 ページの 項 スタンバイ REDO ログの構成 を参照してください 注意 : スイッチオーバーまたはフェイルオーバーの発生時に すべてのスタンバイ サイトが新規プライマリ データベースから引き続き REDO データを受信するように 各スタンバイ データベース上で LOG_ARCHIVE_DEST_ n および LOG_ARCHIVE_DEST_STATE_n パラメータを定義する必要があります LOG_ARCHIVE_DEST_n VALID_FOR 属性を使用して 将来のロールの推移に備えてロールベースの宛先を定義する方法については 5-16 ページ 項 VALID_FOR 属性を使用したロール ベースの宛先の指定 および第 14 章 LOG_ARCHIVE_DEST_n パラメータの属性 を参照してください 新たにプライマリ データベースになるスタンバイ データベースが ARCHIVELOG モードで動作していることを確認します スタンバイ データベースに存在する一時ファイルが プライマリ データベースの一時ファイルと一致することを確認します 新たにプライマリ データベースになるスタンバイ データベースで現在有効になっている REDO の適用遅延を解除します Real Application Clusters 構成で 1 つのスタンバイ インスタンスを除いて 構成内のすべてのインスタンスが停止していることを確認します 7-2 Oracle Data Guard 概要および管理

121 ロールの推移の概要 Real Application Clusters データベースの場合 ロールの推移中は 1 つのスタンバイ インスタンスのみをオンラインにできます ロールの推移を開始する前に 他のすべてのインスタンスを停止しておいてください ロールの推移の完了後 これらのインスタンスをオンラインに戻します 注意 : スイッチオーバー中にオープン状態のスタンバイ インスタンスが 1 つしかない場合も 他のすべてのスタンバイ データベース インスタンスはオープン時に自動的に新しいロールに正しく推移します ロールの推移のターゲット スタンバイ データベースの選択 ロールの推移のターゲット スタンバイ データベースを選択する際には 多数の要因を考慮する必要があります 次のような要因があります スタンバイ データベースのローカリティ スタンバイ データベースの機能 (CPU 数 使用可能な I/O 帯域幅などのハードウェア仕様 ) ロールの推移の実行所要時間 これは スタンバイ データベースが REDO データの適用に関してどの程度遅れているか およびアプリケーションの可用性とデータ消失をどの程度柔軟にトレードオフできるかに影響を受けます Data Guard には V$DATAGUARD_STATS ビューが用意されています このビューを使用して データの最新性に関する各スタンバイ データベースの実行可能性と 使用可能な REDO データがすべてスタンバイ データベースに適用された場合の ロールの推移の実行所要時間を見積もることができます 次に例を示します SQL> COLUMN NAME FORMAT A18 SQL> COLUMN VALUE FORMAT A16 SQL> COLUMN UNIT FORMAT A10 SQL> COLUMN TIME_COMPUTED FORMAT A24 SQL> SELECT * FROM V$DATAGUARD_STATS; NAME VALUE UNIT TIME_COMPUTED apply finish time :00:02.4 day(2) to 15-MAY :32:49 second(1) interval apply lag +00 0:00:04 day(2) to 15-MAY :32:49 second(0) interval transport lag :00:00 day(2) to 15-MAY :32:49 second(0) interval この例は トランスポート ラグがないこと ログ適用サービスでは過去 4 秒間に生成された REDO が適用されていないこと (apply lag) およびログ適用サービスで未適用の REDO の適用が完了するまでに 2.4 秒かかること (apply finish time) を示しています それぞれの統計の計算時刻は TIME_COMPUTED 列に示されています 構成にフィジカル スタンバイ データベースとロジカル スタンバイ データベースの両方が含まれている場合は フィジカル スタンバイ データベースをターゲット スタンバイ データベースとして選択することを考慮してください ロールの推移が完了すると 構成内のすべてのデータベースが新規プライマリ データベースのスタンバイ データベースとして実行可能になるため フィジカル スタンバイ データベースにスイッチオーバーまたはフェイルオーバーする方が適切です これに対して ロジカル スタンバイ データベースにスイッチオーバーまたはフェイルオーバーすると 他方のフィジカル スタンバイ データベースは元のプライマリ データベースに対して無効化されます その場合は 新規プライマリ データベースのバックアップからフィジカル スタンバイ データベースを再作成した後に 再び有効化する必要があります ロールの推移 7-3

122 ロールの推移の概要 スイッチオーバー スイッチオーバーは 通常 オペレーティング システムやハードウェアのアップグレード または Oracle データベース ソフトウェアとパッチ セットのローリング アップグレードなど 計画的な停止によるプライマリ データベースの停止時間を短縮するために使用します ( 第 11 章 SQL Apply を使用した Oracle Database のアップグレード を参照 ) スイッチオーバーは 2 つのフェーズで実行されます 最初のフェーズで 既存のプライマリ データベースがスタンバイ ロールに推移します 2 番目のフェーズで スタンバイ データベースがプライマリ ロールに推移します 図 7-1 は データベースのロールを切り替える前の 2 つのサイトにある Data Guard 構成を示します この構成では プライマリ データベースはサンフランシスコにあり スタンバイ データベースはボストンにあります 図 7-1 スイッチオーバー前の Data Guard 構成 図 7-2 に 元のプライマリ データベースがスタンバイ データベースにスイッチオーバーされた後 元のスタンバイ データベースがまだ新しいプライマリ データベースになっていない Data Guard 環境を示します このとき Data Guard 構成には一時的に 2 つのスタンバイ データベースが存在することになります 図 7-2 新しいプライマリ データベースへのスイッチオーバー前のスタンバイ データベース 7-4 Oracle Data Guard 概要および管理

123 ロールの推移の概要 図 7-3 は スイッチオーバー実行後の Data Guard 環境を示します 元のスタンバイ データベースは新しいプライマリ データベースになります 現在 プライマリ データベースはボストンにあり スタンバイ データベースはサンフランシスコにあります データベースがスイッチオーバー後に初めてオープンされると DB_ROLE_CHANGE システム イベントが実行されます このシステム イベントに関連付けるトリガーを記述して スイッチオーバーの発生後にタスクを管理できます V$DATABASE ビューの DATABASE_ROLE 列を問い合せると 現行のロールを判断できます 詳細は Oracle Database アプリケーション開発者ガイド - 基礎編 のシステム マネージャ イベントの表を参照してください 図 7-3 スイッチオーバー後の Data Guard 環境 スイッチオーバーの準備 項に示した前提条件が満たされていることを確認します また スイッチオーバーの場合は 次の前提条件が満たされている必要があります フィジカル スタンバイ データベースが関与するスイッチオーバーの場合は プライマリ データベース インスタンスがオープンし スタンバイ データベース インスタンスがマウントされていることを確認します スイッチオーバーの開始前に プライマリ ロールに変更するスタンバイ データベースをマウントする必要があります また データベースのロールが切り替えられたとき フィジカル スタンバイ データベースが REDO を適用することが理想的です フィジカル スタンバイ データベースが読取り専用アクセスのためにオープンされている場合 スイッチオーバーは実行されますが時間がかかります REDO Apply の詳細は 6-5 ページの 6.3 項 REDO データのフィジカル スタンバイ データベースへの適用 を参照してください ロジカル スタンバイ データベースが関与するスイッチオーバーの場合は プライマリおよびスタンバイ データベース インスタンスの両方がオープンし SQL Apply がアクティブであることを確認します SQL Apply の詳細は 6-6 ページの 6.4 項 REDO データのロジカル スタンバイ データベースへの適用 を参照してください Real Application Clusters でプライマリ データベースが関与するスイッチオーバーの場合は 1 つを除くすべてのインスタンスを停止する必要があります スイッチオーバーが正常に実行された後 他のすべてのインスタンスをオンラインに戻すことができます スイッチオーバーに成功すると DB_ROLE_CHANGE システム イベントが実行されます ( フィジカル スタンバイ データベースへのフェイルオーバーの場合は フェイルオーバー後に初めてデータベースがオープンされた時点でシステム イベントが実行されます ) このシステム イベントに関連付けるトリガーを記述して フェイルオーバーの発生後にタスクを管理できます 詳細は Oracle Database アプリケーション開発者ガイド - 基礎編 のシステム マネージャ イベントの表を参照してください ロールの推移 7-5

124 ロールの推移の概要 フェイルオーバー 通常 フェイルオーバーは プライマリ データベースが使用不可能になり 適正な時間内にプライマリ データベースをリストアしてサービスを再開できない場合にのみ使用します フェイルオーバー時に実行するアクションは フェイルオーバーに関与するスタンバイ データベースがロジカルかフィジカルか フェイルオーバー時の Data Guard 構成の状態 およびフェイルオーバーを開始するために使用する特定の SQL 文によって異なります 図 7-4 に サンフランシスコにあるプライマリ データベースからボストンにあるフィジカル スタンバイ データベースへのフェイルオーバーの結果を示します 図 7-4 スタンバイ データベースへのフェイルオーバー フェイルオーバーの準備可能な場合は フェイルオーバーを実行する前に 使用可能な未適用のプライマリ データベース REDO データを可能なかぎりスタンバイ データベースに転送する必要があります 7-2 ページの 項 ロールの推移 ( フェイルオーバーまたはスイッチオーバー ) の準備 に示した前提条件が満たされていることを確認します また フェイルオーバーの場合は 次の前提条件が満たされている必要があります 最大保護モードで実行中のスタンバイ データベースがフェイルオーバーに関与する場合は スタンバイ データベースで次の文を発行して データベースを最大パフォーマンス モードにします SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE; 適切なスタンバイ データベースが使用できる場合は フェイルオーバーが完了した後に 新しいプライマリ データベースで希望の保護モードをリセットできます 最大保護モードに設定されているスタンバイ データベースはフェイルオーバーできないため この作業が必要になります さらに 最大保護モードのプライマリ データベースがスタンバイ データベースと通信中の場合は スタンバイ データベースを最大保護モードから最大パフォーマンス モードに変更するために ALTER DATABASE 文を発行しても失敗します フェイルオーバーを実行すると元のプライマリ データベースは Data Guard 構成から削除されるため この機能によって 最大保護モードで実行されているプライマリ データベースを計画外のフェイルオーバーの影響から保護します 7-6 Oracle Data Guard 概要および管理

125 フィジカル スタンバイ データベースが関与するロールの推移 注意 : スタンバイ データベースが正しく更新されているかどうかをテストするために スタンバイ データベースにフェイルオーバーしないでください かわりに 次のようにします 項 フィジカル スタンバイ データベースが正しく実行されているかどうかの確認 を参照してください 項 ロジカル スタンバイ データベースが正しく実行されているかどうかの確認 を参照してください フェイルオーバーに成功すると DB_ROLE_CHANGE システム イベントが実行されます ( フィジカル スタンバイ データベースへのフェイルオーバーの場合は フェイルオーバー操作後に初めてデータベースがオープンされた時点でシステム イベントが実行されます ) V$DATABASE ビューの DATABASE_ROLE 列を問い合せると 現行のロールを判断できます このシステム イベントに関連付けるトリガーを記述して フェイルオーバーの発生後にタスクを管理できます 詳細は Oracle Database アプリケーション開発者ガイド - 基礎編 のシステム マネージャ イベントの表を参照してください フィジカル スタンバイ データベースが関与するフェイルオーバーを実行するには 7-10 ページの 項 フィジカル スタンバイ データベースが関与するフェイルオーバー を参照してください ロジカル スタンバイ データベースが関与するフェイルオーバーを実行するには 7-17 ページの 項 ロジカル スタンバイ データベースが関与するフェイルオーバー を参照してください 7.2 フィジカル スタンバイ データベースが関与するロールの推移 この項では フィジカル スタンバイ データベースが関与するスイッチオーバーおよびフェイルオーバーの実行方法を説明します フィジカル スタンバイ データベースが関与するスイッチオーバー この項では スイッチオーバーの実行方法について説明します スイッチオーバーは 現行のプライマリ データベースで開始し ターゲット スタンバイ データベースで完了する必要があります 次に スイッチオーバーを実行する手順を説明します 手順 1 スイッチオーバーを実行できるかどうかを確認するスイッチオーバーを実行できるかどうかを確認するには 現行のプライマリ データベースで V$DATABASE 固定ビューの SWITCHOVER_STATUS 列を問い合せます 次に例を示します SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS TO STANDBY 1 row selected SWITCHOVER_STATUS 列の値 TO STANDBY は プライマリ データベースのスタンバイ ロールへの切替えが可能であることを示します 値 TO STANDBY が表示されない場合は Data Guard 構成が正常に機能していることを確認してください ( たとえば LOG_ARCHIVE_DEST_ n パラメータのすべての値が正しく指定されていることを確認します ) SWITCHOVER_STATUS 列の値が SESSIONS ACTIVE の場合は A-5 ページの A.4 項 スタンバイ データベースへのスイッチオーバーの問題 で説明する手順を実行して スイッチオーバーの処理を妨げている可能性のあるアクティブなユーザーまたは SQL セッションを識別して終了します これらの手順を実行した後も SWITCHOVER_STATUS 列に SESSIONS ACTIVE と表示される場合は 手順 2 で説明した ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY 文に WITH SESSION SHUTDOWN 句を追加することでスイッチオーバーを正常に実行できます ロールの推移 7-7

126 フィジカル スタンバイ データベースが関与するロールの推移 V$DATABASE ビューの SWITCHOVER_STATUS 列に対するその他の有効な値については Oracle Database リファレンス を参照してください 手順 2 プライマリ データベースでスイッチオーバーを開始する現行のプライマリ データベースをフィジカル スタンバイ データベース ロールに変更するには プライマリ データベースで次の SQL 文を使用します SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY; この文が完了すると プライマリ データベース ロールはスタンバイ データベースに変換されます 現行の制御ファイルは スイッチオーバーの前にカレント SQL セッション トレース ファイルにバックアップされます これによって 必要に応じて現行の制御ファイルを再作成できるようになります 手順 3 元のプライマリ インスタンスを停止して再起動する元のプライマリ インスタンスを停止し データベースを再起動およびマウントします SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; スイッチオーバー プロセスのこの時点では 両方のデータベースがスタンバイ データベースとして構成されています ( 図 7-2 を参照 ) 手順 4 スイッチオーバーの状態を V$DATABASE ビューで確認するプライマリ データベースをフィジカル スタンバイ ロールに変更し 構成内のスタンバイ データベースがスイッチオーバー通知を受け取った後 ターゲット スタンバイ データベースで V$DATABASE 固定ビューの SWITCHOVER_STATUS 列を問い合せ ターゲット スタンバイ データベースがスイッチオーバー通知を処理したかどうかを確認する必要があります 次に例を示します SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS TO_PRIMARY 1 row selected SWITCHOVER_STATUS 列の値が SESSIONS ACTIVE の場合は A-5 ページの A.4 項 スタンバイ データベースへのスイッチオーバーの問題 で説明する手順を実行して スイッチオーバーの処理を妨げている可能性のあるアクティブなユーザーまたは SQL セッションを識別して終了します これらの手順を実行した後も SWITCHOVER_STATUS 列に SESSIONS ACTIVE と表示される場合は 手順 5 に進んでスイッチオーバー文に WITH SESSION SHUTDOWN 句を追加できます V$DATABASE ビューの SWITCHOVER_STATUS 列に対するその他の有効な値については Oracle Database リファレンス を参照してください 手順 5 ターゲット フィジカル スタンバイ データベース ロールからプライマリ ロールに切り替えるフィジカル スタンバイ データベースをスタンバイ ロールからプライマリ ロールに切り替えることができるのは そのスタンバイ データベースのインスタンスが REDO Apply モードでマウントされているか あるいは読取り専用アクセスのためにオープンされているときです フィジカル スタンバイ データベースは いずれかのモードでマウントする必要があります これによって プライマリ データベースのスイッチオーバー要求を調整できます 適切なモードでスタンバイ データベースをマウントした後 プライマリ ロールに変更するフィジカル スタンバイ データベースで次の SQL 文を発行します SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 7-8 Oracle Data Guard 概要および管理

127 フィジカル スタンバイ データベースが関与するロールの推移 手順 6 スタンバイ データベースからプライマリ ロールへの推移を終了する実行するタスクは フィジカル スタンバイ データベースが読取り専用モードでオープンされたことがあるかどうかに応じて異なります フィジカル スタンバイ データベースが前回の起動後に読取り専用モードでオープンされていない場合は SQL ALTER DATABASE OPEN 文を発行して新規プライマリ データベースをオープンします SQL> ALTER DATABASE OPEN; その後 7-9 ページの手順 7 に進みます フィジカル スタンバイ データベースが前回の起動後に読取り専用モードでオープンされている場合は ターゲット スタンバイ データベースを停止して再起動する必要があります SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP; ターゲット フィジカル スタンバイ データベースがプライマリ データベース ロールに推移します LOG_ARCHIVE_DEST_n の VALID_FOR 属性を使用して Data Guard 構成をロールの推移後も確実に正常に動作させる方法については 項 VALID_FOR 属性を使用したロール ベースの宛先の指定 および第 14 章 LOG_ARCHIVE_DEST_n パラメータの属性 を参照してください 注意 : スイッチオーバー時にオンラインでもスイッチオーバーに関与しない他のスタンバイ データベースは 停止して再起動する必要はありません これらのスタンバイ データベースは スイッチオーバーの完了後も正常に機能し続けます 手順 7 必要に応じてスタンバイ データベースでログ適用サービスを再開する新しいフィジカル スタンバイ データベース および Data Guard 構成内の他のフィジカルまたはロジカル スタンバイ データベースの場合 スイッチオーバー後も動作を継続するようにログ適用サービスが構成されていないときは 適切なコマンドを使用して ログ適用サービスを再開します ログ適用サービスを構成および開始する方法については 第 6 章 ログ適用サービス を参照してください 手順 8 スタンバイ データベースへの REDO データの送信を開始する新しいプライマリ データベースで次の文を発行します SQL> ALTER SYSTEM SWITCH LOGFILE; ロールの推移 7-9

128 フィジカル スタンバイ データベースが関与するロールの推移 フィジカル スタンバイ データベースが関与するフェイルオーバー この項では フィジカル スタンバイ データベースが関与するフェイルオーバーの実行方法を説明します フィジカル スタンバイ データベースが関与するフェイルオーバー時に 次の処理が実行されます すべての場合 フェイルオーバーの完了後 元のプライマリ データベースは Data Guard 構成に含まれなくなります ほとんどの場合 フェイルオーバーに直接関与しない他のロジカルまたはフィジカル スタンバイ データベースは構成内に残り 停止して再起動する必要はありません 新しいプライマリ データベースを構成した後 すべてのスタンバイ データベースの再作成が必要な場合があります フェイルオーバーを開始する前に 項 フェイルオーバー で説明した手順を可能なかぎり実行し 選択したスタンバイ データベースのフェイルオーバーの準備をしてから 項 フィジカル スタンバイ データベースが関与するフェイルオーバー に進んでください 注意 : フェイルオーバーを実行するには 次の項で説明するフェイルオーバーの手順およびコマンドのみを使用することをお薦めします ALTER DATABASE ACTIVATE STANDBY DATABASE 文によりデータ消失が発生する場合があるため フェイルオーバーの実行にはこの文を使用しないでください フェイルオーバーの手順この項では 選択したフィジカル スタンバイ データベースをプライマリ ロールに推移するために必要な手順について説明します 構成の一部でもある他のフィジカルまたはロジカル スタンバイ データベースは構成内に残り 停止して再起動する必要はありません ターゲット スタンバイ データベースがログ ライター プロセス (LGWR) を使用して最大保護モードまたは最大可用性モードで動作していた場合 アーカイブ REDO ログ ファイル内にギャップが存在しないため 手順 4 に直接進むことができます それ以外の場合は ギャップ解決の手順を手動で実行する必要があるかどうかを判断するために 手順 1 から始めます 手順 1 アーカイブ REDO ログ ファイルのギャップを識別して解決するターゲット スタンバイ データベースでアーカイブ REDO ログ ファイルにギャップが存在するかどうかを判断するには V$ARCHIVE_GAP ビューを問い合せます V$ARCHIVE_GAP ビューには 各スレッドで欠落しているアーカイブ REDO ログ ファイルの順序番号が表示されます 戻されるデータは 順序番号が最も大きいギャップのみです 次に例を示します SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# この例では スレッド 1 の順序 および 92 のアーカイブ REDO ログ ファイルがギャップです 可能であれば 欠落が識別されたすべてのアーカイブ REDO ログ ファイルを プライマリ データベースからターゲット スタンバイ データベースにコピーして登録します スレッドごとに実行する必要があります 次に例を示します SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1'; 7-10 Oracle Data Guard 概要および管理

129 フィジカル スタンバイ データベースが関与するロールの推移 手順 2 すべてのギャップが解決されるまで手順 1 を繰り返す手順 1 で実行する問合せでは 順序番号が最も大きいギャップに関する情報のみが表示されます そのギャップを解決した後 問合せで行が戻されなくなるまで 手順 1 を繰り返します 手順 3 欠落した他のアーカイブ REDO ログ ファイルをコピーする欠落したアーカイブ REDO ログ ファイルが他に存在するかどうかを判断するには ターゲット スタンバイ データベースで V$ARCHIVED_LOG ビューを問い合せて スレッドごとに最も大きい順序番号を取得します 次に例を示します SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) 2> OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG; THREAD LAST ターゲット スタンバイ データベースで最も大きい順序番号より大きい順序番号を含むプライマリ データベースから 使用可能なアーカイブ REDO ログ ファイルをターゲット スタンバイ データベースにコピーして登録します スレッドごとに実行する必要があります 次に例を示します SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1'; 使用可能なアーカイブ REDO ログ ファイルをすべて登録した後に 手順 1 で説明したように V$ARCHIVE_GAP ビューを問い合せて 手順 3 に他のギャップが追加されていないことを確認します 注意 : 手順 1 から 3 を実行しているときに アーカイブ REDO ログ ファイル内のギャップを解決できない場合 ( 障害の発生したプライマリ データベースが置かれているシステムへのアクセス権がない場合など ) フェイルオーバー時にデータが消失する可能性があります 手順 4 ターゲット フィジカル スタンバイ データベースでフェイルオーバーを開始する次の文を発行してフェイルオーバーを開始します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE; FORCE キーワードは ターゲット フィジカル スタンバイ データベース上のアクティブな RFS プロセスを終了します これにより フェイルオーバーはネットワーク接続のタイムアウトを待たずに即時に進行できます 注意 : フェイルオーバーにより アーカイブされる最後のログ ファイルのヘッダーに end-of-redo マーカーが追加され この REDO はプライマリ ロール (VALID_FOR=(PRIMARY_ROLE, *_LOGFILES) または VALID_FOR=(ALL_ROLES, *_LOGFILES) 属性で指定 ) として妥当なすべての使用可能な宛先に送信されます 注意 : FINISH キーワードは SQL 文で FORCE WAIT または NOWAIT を除く他のすべてのキーワードの後に置く必要があります ロールの推移 7-11

130 フィジカル スタンバイ データベースが関与するロールの推移 手順 5 フィジカル スタンバイ データベース ロールからプライマリ ロールに変換する SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE...FINISH FORCE 文が正常に完了した後 次の SQL 文を発行して フィジカル スタンバイ データベースをプライマリ データベース ロールに変更します SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; この SQL 文を発行した後 ターゲット スタンバイ データベースがプライマリ ロールに推移します その結果 このデータベースはスタンバイ データベースとして使用できなくなり 元のプライマリ データベースから受信した後続の REDO は適用できません フェイルオーバー プロセスでは スタンバイ REDO ログ ファイルが自動的にアーカイブされ 元のプライマリ データベースから作成した他のすべてのスタンバイ データベースでリカバリされます この処理は 新しいプライマリ データベースでスタンバイ宛先を適切に定義した場合のみ実行されます フェイルオーバーに関与しない構成内の他のスタンバイ データベースは 停止して再起動する必要はありません 手順 6 スタンバイ データベースからプライマリ データベース ロールへの推移を終了するこの手順で実行するタスクは フィジカル スタンバイ データベースが読取り専用モードでオープンされたことがあるかどうかに応じて異なります フィジカル スタンバイ データベースが前回の起動後に読取り専用モードでオープンされていない場合は SQL ALTER DATABASE OPEN 文を発行して新規プライマリ データベースをオープンします SQL> ALTER DATABASE OPEN; その後 手順 7 に進みます フィジカル スタンバイ データベースが前回の起動後に読取り専用モードでオープンされている場合は ターゲット スタンバイ データベースを停止して再起動する必要があります SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP; ターゲット フィジカル スタンバイ データベースがプライマリ データベース ロールに推移します LOG_ARCHIVE_DEST_n の VALID_FOR 属性を使用して Data Guard 構成をロールの推移後も正常に動作させる方法については 項 VALID_FOR 属性を使用したロール ベースの宛先の指定 および第 14 章 LOG_ARCHIVE_DEST_n パラメータの属性 を参照してください 手順 7 新しいプライマリ データベースをバックアップする STARTUP 文を発行する前に 新しいプライマリ データベースのバックアップを作成します バックアップを即時に実行することは 必要な安全策です これは データベースの完全なバックアップ コピーを作成せずにフェイルオーバーを行うと 変更をリカバリできないためです フェイルオーバーの結果 元のプライマリ データベースは Data Guard 構成に含まれなくなり 他のすべてのスタンバイ データベースは新しいプライマリ データベースから REDO データを受信して適用します 7-12 Oracle Data Guard 概要および管理

131 フィジカル スタンバイ データベースが関与するロールの推移 手順 8 障害の発生したプライマリ データベースをリストアする ( オプション ) フェイルオーバーの完了後 元のプライマリ データベースは構成に含まれなくなります フェイルオーバーの実行後 次のどちらかの方法を使用して 障害の発生したプライマリ データベースを新規スタンバイ データベースとしてリストアすることもできます フラッシュバック データベースを使用して 障害の発生したプライマリ データベースをフェイルオーバー発生前の時点までリストアしてから ページの 12.4 項 フェイルオーバー後のフラッシュバック データベースの使用 の手順に従ってスタンバイ データベースに変換します 注意 : フェイルオーバーの前に 旧プライマリ データベースでフラッシュバック データベースを使用可能にしておく必要があります 詳細は Oracle Database バックアップおよびリカバリ基礎 を参照してください 障害の発生したデータベースを再作成し 新規スタンバイ データベースとして構成に追加します 古いプライマリ データベースを新しい構成内で再利用するには 新しいプライマリ データベースのバックアップ コピーを使用し スタンバイ データベースとして再作成する必要があります この手順については 3.2 項 フィジカル スタンバイ データベースの作成手順 または 4.2 項 ロジカル スタンバイ データベースの作成手順 を参照してください 接続が再確立された時点で Oracle Data Guard Broker の REINSTATE コマンド (Oracle Enterprise Manager または DGMGRL の REINSTATE DATABASE コマンド ) を使用して 障害が発生したプライマリ データベースを新規構成のスタンバイ データベースとして再作成します 元に戻すための手順については Oracle Data Guard Broker を参照してください このオプションでは フェイルオーバー前にフラッシュバック データベースが有効化されている必要があります 障害が発生したプライマリ データベースがリストアされてスタンバイ ロールで稼働し始めた後 オプションでスイッチオーバーを実行し 元の ( 障害発生前の ) ロールへのそれぞれのデータベースの推移を実行できます 詳細は 項 フィジカル スタンバイ データベースが関与するスイッチオーバー を参照してください ロールの推移 7-13

132 ロジカル スタンバイ データベースが関与するロールの推移 7.3 ロジカル スタンバイ データベースが関与するロールの推移 この項では ロジカル スタンバイ データベースが関与するスイッチオーバーおよびフェイルオーバーの実行方法を説明します ロジカル スタンバイ データベースが関与するスイッチオーバー プライマリ データベースとロジカル スタンバイ データベースとの間でスイッチオーバーを実行する場合 スイッチオーバーは 常にプライマリ データベースで開始し ロジカル スタンバイ データベースで完了してください 次の手順を記載されているとおりの順序で実行しなかった場合 スイッチオーバーは成功しません 注意 : プライマリ データベースが RAC データベースの場合は スイッチオーバーを開始する前に 1 つを除くすべてのインスタンスが停止していることと 対応するスレッドが無効化されていることを確認してください 同様に ロジカル スタンバイ データベースが RAC データベースの場合は スイッチオーバーを開始する前に SQL Apply を実行中の 1 つを除くすべてのインスタンスが停止していることと 対応するスレッドが無効化されていることを確認してください スイッチオーバー操作が正常に完了した後 スレッドを再び有効化してインスタンスを起動できます インスタンスが停止されていても ロールの変更は再起動時にこれらのインスタンスへ自動的に伝播します 手順 1 プライマリ データベースでスイッチオーバーを実行できるかどうかを確認するスイッチオーバーを実行できるかどうかを確認するには 現行のプライマリ データベースで V$DATABASE 固定ビューの SWITCHOVER_STATUS 列を問い合せます 次に例を示します SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS TO STANDBY 1 row selected SWITCHOVER_STATUS 列の値 TO STANDBY または SESSIONS ACTIVE は プライマリ データベースをロジカル スタンバイ ロールに切替え可能であることを示します これらの値のいずれかが表示されない場合は Data Guard 構成が正常に機能していることを確認してください ( たとえば LOG_ARCHIVE_DEST_n パラメータのすべての値が正しく指定されていることを確認します ) V$DATABASE ビューの SWITCHOVER_STATUS 列に対するその他の有効な値については Oracle Database リファレンス を参照してください 手順 2 現行のプライマリ データベースのスイッチオーバーを準備するロジカル スタンバイ データベース ロール用に現行のプライマリ データベースを準備するには プライマリ データベースで次の SQL 文を発行します SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY; この文は 現行のプライマリ データベースがロジカル スタンバイ ロールに切り替わり 新しいプライマリ データベースから REDO データの受信を開始することを 現行のプライマリ データベースに通知します この手順は 現行のロジカル スタンバイ データベースの REDO ストリームで記録される LogMiner マルチバージョン データ ディクショナリを受信するための準備中に プライマリ データベースで実行します 手順 3 を参照してください この操作に成功すると V$DATABASE.SWITCHOVER_STATUS 列に値 PREPARING SWITCHOVER が表示されます 7-14 Oracle Data Guard 概要および管理

133 ロジカル スタンバイ データベースが関与するロールの推移 手順 3 ターゲット ロジカル スタンバイ データベースのスイッチオーバーを準備するスイッチオーバーのターゲットであるロジカル スタンバイ データベースで LogMiner マルチバージョン データ ディクショナリを作成するには 次の文を使用します SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY; また この文は 現行のプライマリ データベース および Data Guard 構成内の他のスタンバイ データベースに REDO データの転送を開始するロジカル スタンバイ データベースで REDO 転送サービスを開始します このロジカル スタンバイ データベースから REDO データを受信するサイトは REDO データを受け入れますが 適用はしません このスイッチオーバーは 処理量とデータベースのサイズによって完了までに時間がかかる場合があります ロジカル スタンバイ データベースの V$DATABASE.SWITCHOVER_STATUS には LogMiner マルチバージョン データ ディクショナリが REDO ストリームに記録されている間 最初は PREPARING DICTIONARY が表示されます 正常に完了すると SWITCHOVER_ STATUS 列に PREPARING SWITCHOVER が表示されます 手順 4 現行のプライマリ データベースで将来のプライマリ データベースの REDO ストリームに対する準備が完了していることを確認するプライマリ データベースからロジカル スタンバイ ロールへのロールの推移を完了する前に プライマリ データベースで V$DATABASE 固定ビューの SWITCHOVER_STATUS 列を問い合せ プライマリ データベースで LogMiner マルチバージョン データ ディクショナリが受信されていることを確認します LogMiner マルチバージョン データ ディクショナリが受信されていない場合 スイッチオーバーは進行できません これは 現行のプライマリ データベースでは 将来のプライマリ データベースから送信される REDO レコードを解析できないためです SWITCHOVER_STATUS 列は スイッチオーバーの進捗を示します 問合せが TO LOGICAL STANDBY 値を戻した場合は 手順 5 に進むことができます 次に例を示します SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS TO LOGICAL STANDBY 1 row selected 注意 : 次の文を順番に発行すると スイッチオーバー操作を取り消すことができます 1. プライマリ データベースでスイッチオーバーを取り消します SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY CANCEL; 2. ロジカル スタンバイ データベースでスイッチオーバーを取り消します SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL PRIMARY CANCEL; ロールの推移 7-15

134 ロジカル スタンバイ データベースが関与するロールの推移 手順 5 プライマリ データベースをロジカル スタンバイ データベース ロールに切り替えるプライマリ データベースからロジカル スタンバイ データベース ロールへのロールの推移を完了するには 次の SQL 文を発行します SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY; この文は プライマリ データベースで現在のトランザクションがすべて終了するまで待機し 新規ユーザーによる新規トランザクションの開始を防止して スイッチオーバーがコミットされる時点を設定します この文を実行すると ユーザーはロジカル スタンバイ データベースでメンテナンスされているデータの変更もできなくなります スイッチオーバーを迅速に実行するには スイッチオーバー文を発行する前に プライマリ データベースが静止状態で更新アクティビティが実行されていないことを確認してください ( たとえば すべてのユーザーをプライマリ データベースから一時的にログオフします ) V$TRANSACTIONS ビューを問い合せると この文の実行を遅延させる可能性のある現在進行中のトランザクションのステータス情報を取得できます この時点でプライマリ データベースのロールが推移して スタンバイ データベース ロールで実行されます プライマリ データベースをロジカル スタンバイ データベース ロールに推移した場合は データベースを停止して再起動する必要はありません 手順 6 使用可能なすべての REDO が 新規プライマリ データベースになるターゲット ロジカル スタンバイ データベースに適用されたことを確認するプライマリ データベースからロジカル スタンバイ ロールへのロールの推移を完了し 構成内のスタンバイ データベースがスイッチオーバー通知を受け取った後 ターゲット スタンバイ データベースで V$DATABASE 固定ビューの SWITCHOVER_STATUS 列を問い合せ ターゲット スタンバイ データベースがスイッチオーバー通知を処理したかどうかを確認する必要があります 使用可能なすべての REDO レコードがロジカル スタンバイ データベースに適用されると SQL Apply は予想されるロールの推移の準備を自動的に停止します スイッチオーバー中に SWITCHOVER_STATUS 値が更新され 進捗を示します TO PRIMARY 状態の場合は 手順 7 に進むことができます 次に例を示します SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS TO PRIMARY 1 row selected V$DATABASE ビューの SWITCHOVER_STATUS 列に対するその他の有効な値については Oracle Database リファレンス を参照してください 手順 7 ターゲット ロジカル スタンバイ データベースをプライマリ データベース ロールに切り替えるプライマリ ロールに切り替えるロジカル スタンバイ データベースで 次の SQL 文を使用し ロジカル スタンバイ データベースをプライマリ ロールに切り替えます SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; Data Guard 構成内のロジカル スタンバイ データベースは 停止して再起動する必要はありません 他の既存のロジカル スタンバイ データベースは スイッチオーバーの完了後も正常に機能し続けます ただし 既存のすべてのフィジカル スタンバイ データベースは スイッチオーバー後は Data Guard 構成に含まれなくなります 手順 8 新規のロジカル スタンバイ データベースで SQL Apply を開始する新しいロジカル スタンバイ データベースで SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; 7-16 Oracle Data Guard 概要および管理

135 ロジカル スタンバイ データベースが関与するロールの推移 ロジカル スタンバイ データベースが関与するフェイルオーバー この項では ロジカル スタンバイ データベースが関与するフェイルオーバーの実行方法を説明します ロジカル スタンバイ データベースが関与するフェイルオーバーによるロールの推移では 障害の発生したプライマリ データベースとすべてのロジカル スタンバイ データベースで対処措置を実行する必要があります 障害の発生したプライマリ データベースでフラッシュバック データベースが有効化されていない場合は 現行のプライマリ データベースから作成したバックアップを使用してデータベースを再作成する必要があります それ以外の場合は 12.4 項で説明する手順に従って 障害の発生したプライマリ データベースを新規プライマリ データベースのロジカル スタンバイ データベースに変換できます 構成に対する保護モードおよび REDO 転送サービスに対して選択した属性に従って プライマリ データベースの修正の一部またはすべてを自動的にリカバリすることも可能です ターゲット スタンバイ データベースが非データ消失モードで動作していた場合 アーカイブ REDO ログ ファイル内にギャップが存在しないため 手順 1 に直接進むことができます それ以外の場合は ギャップ解決の手順を手動で実行する必要があるかどうかを判断するために 手順 1 から始めます 手順 1 欠落したアーカイブ REDO ログ ファイルを 新規プライマリ データベースの候補となるターゲット ロジカル スタンバイ データベースにコピーし 登録する構成に含まれるコンポーネントの状態によっては プライマリ データベースのアーカイブ REDO ログ ファイルにアクセスできる場合があります アクセスする場合の手順は 次のとおりです 1. ロジカル スタンバイ データベースでアーカイブ REDO ログ ファイルが欠落しているかどうかを判断します 2. 欠落しているログ ファイルを プライマリ データベースからロジカル スタンバイ データベースにコピーします 3. コピーしたログ ファイルを登録します 次の文を発行して アーカイブ REDO ログ ファイルをロジカル スタンバイ データベースに登録できます 次に例を示します SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE 2> '/disk1/oracle/dbs/log-%r_%s_%t.arc'; Database altered. 手順 2 使用可能なすべてのアーカイブ REDO ログ ファイルが適用されたことを確認するプライマリ ロールに推移させるロジカル スタンバイ データベースで V$LOGSTDBY_ PROGRESS ビューを問い合せ 使用可能なすべてのアーカイブ REDO ログ ファイルが適用されたことを確認します 次に例を示します SQL> SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN LATEST_SCN APPLIED_SCN と LATEST_SCN の値が等しい場合は 取得可能なすべてのデータが適用され ロジカル スタンバイ データベースにはプライマリ データベースからのデータが可能なかぎり含まれています 注意 : ターゲット ロジカル スタンバイ データベースで SQL Apply がアクティブになっていない場合は ターゲット スタンバイ データベースで次の文を発行して SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY FINISH; Database altered. V$LOGSTDBY_PROGRESS ビューについては 第 9 章 ロジカル スタンバイ データベースの管理 および第 12 章 Data Guard の使用例 を参照してください ロールの推移 7-17

136 ロジカル スタンバイ データベースが関与するロールの推移 手順 3 リモート宛先を使用可能にする 5-16 ページの 項 VALID_FOR 属性を使用したロール ベースの宛先の指定 で説明したように ロールベースの宛先を以前に構成していない場合は 新しいプライマリ データベースのリモート ロジカル スタンバイ宛先に対応する初期化パラメータを識別して これらの宛先ごとに REDO データのアーカイブを手動で使用可能にします たとえば LOG_ARCHIVE_DEST_2 パラメータで定義したリモート宛先のアーカイブを可能にするには 次の文を発行します SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH; 後で新しいプライマリ データベースを再起動した場合にもこの変更を保持するには 適切なテキスト初期化パラメータ ファイルまたはサーバー パラメータ ファイルを更新します 通常 データベースがプライマリ ロールで動作する場合はリモート宛先へのアーカイブを可能にし データベースがスタンバイ ロールで動作する場合はリモート宛先へのアーカイブを不可能にする必要があります LOG_ARCHIVE_DEST_n VALID_FOR 属性を使用して 将来のロールの推移に備えてロールベースの宛先を定義する方法については 5-16 ページの 項 VALID_FOR 属性を使用したロール ベースの宛先の指定 および第 14 章 LOG_ARCHIVE_DEST_n パラメータの属性 を参照してください 手順 4 新しいプライマリ データベースをアクティブにするターゲット ロジカル スタンバイ データベース ( 新規プライマリ ロールに推移させるデータベース ) で 次の文を発行します SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY; この文は RFS プロセスを停止し ロジカル スタンバイ データベースがプライマリ データベースになる前にスタンバイ REDO ログ ファイルに残っている REDO データを適用し SQL Apply を停止して データベースをプライマリ データベース ロールでアクティブ化します FINISH APPLY 句が指定されていない場合 現行のスタンバイ REDO ログ ファイルの未適用の REDO は スタンバイ データベースがプライマリ データベースになるまで適用されません 手順 5 他のスタンバイ データベースのリカバリを準備する新しいプライマリ データベースに適用された REDO データの量に従って 既存の他のロジカル スタンバイ データベースを Data Guard 構成に再度追加して新しいプライマリ データベースのスタンバイ データベースとして使用できる場合があります ロジカル スタンバイ データベースを Data Guard 構成に再度追加するには 各ロジカル スタンバイ データベースで次の手順を実行します 1. 各ロジカル スタンバイ データベースでデータベース リンクを作成します ALTER SESSION DISABLE GUARD 文を使用してデータベース ガードをバイパスし ロジカル スタンバイ データベース内の表に対する変更を可能にします たとえば 次の文はプライマリ データベース chicago へのデータベース リンクを作成します SQL> ALTER SESSION DISABLE GUARD; SQL> CREATE DATABASE LINK chicago 2> CONNECT TO username IDENTIFIED BY password USING 'chicago'; SQL> ALTER SESSION ENABLE GUARD; CREATE DATABASE LINK 文で指定したデータベース ユーザー アカウントには プライマリ データベースに対する SELECT_CATALOG_ROLE ロールが付与されている必要があります 7-18 Oracle Data Guard 概要および管理

137 ロジカル スタンバイ データベースが関与するロールの推移 注意 : プライマリ データベースがオープンされた後 DDL 文が実行される前に ディクショナリ作成操作を実行する必要があります ディクショナリ作成操作を実行する前に DDL 文が実行されると バックアップがロジカル スタンバイ データベースの作成ソースとして無効になります データベース リンクを作成する方法については Oracle Database 管理者ガイド を参照してください 2. データベース リンクを確認します ロジカル スタンバイ データベースで データベース リンクを使用して次の問合せを実行し データベース リンクが正しく構成されていることを確認します SQL> SELECT * FROM DBA_LOGSTDBY_PARAMETERS@chicago; 問合せが成功した場合は 手順 1 で作成したデータベース リンクをロールの推移時に使用できることを示します 手順 6 SQL Apply を開始する各ロジカル スタンバイ データベースで SQL Apply を開始します たとえば 次の文では chicago データベースで SQL Apply が開始されます SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY chicago; この文が完了すると 残りのすべてのアーカイブ REDO ログ ファイルが適用されます この操作は 処理量によって完了までに時間がかかる場合があります ORA エラーが表示された場合は 新しいプライマリ データベースのバックアップ コピーからロジカル スタンバイ データベースを再作成して Data Guard 構成に追加する必要があります 次に 新しい構成内のロジカル スタンバイ データベースで SQL Apply の開始に失敗した例を示します ここで chicago は新しいプライマリ データベースを指すサービス名です SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY chicago; ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY chicago * ERROR at line 1: ORA-16109: 以前のプライマリからのログ データの適用に失敗しました 手順 7 新しいプライマリ データベースをバックアップする Data Guard のデータベース フェイルオーバー直後に 新しいプライマリ データベースのバックアップを作成します バックアップを即時に実行することは 必要な安全策です これは データベースの完全なバックアップ コピーを作成せずにフェイルオーバーを行うと 変更をリカバリできないためです ロールの推移 7-19

138 ロジカル スタンバイ データベースが関与するロールの推移 手順 8 障害の発生したプライマリ データベースをリストアするフェイルオーバーの実行後 必要に応じて次のいずれかの方法を使用して 障害の発生したプライマリ データベースを新規スタンバイ データベースとしてリストアすることもできます フラッシュバック データベースを使用して 障害の発生したプライマリ データベースをフェイルオーバー発生前の時点に変換してから ページの 12.4 項 フェイルオーバー後のフラッシュバック データベースの使用 の手順に従ってスタンバイ データベースに変換します 注意 : フェイルオーバーの前に 旧プライマリ データベースでフラッシュバック データベースを使用可能にしておく必要があります 詳細は Oracle Database バックアップおよびリカバリ基礎 を参照してください PL/SQL プロシージャ DBMS_LOGSTDBY.REBUILD を使用し プライマリ データベースを新しいスタンバイ データベースとして再作成します このプロシージャを実行する前に 次のことを確認する必要があります V$STANDBY_LOG または V$LOGFILE ビューを問い合せ スタンバイ REDO ログ ファイルがアーカイブ済であることを確認します DBA_LOGSTDBY_EVENTS ビューを問い合せ LogMiner ディクショナリの作成が正常に完了していることを確認します 接続が再確立された時点で Oracle Data Guard Broker の REINSTATE コマンド (Oracle Enterprise Manager または DGMGRL の REINSTATE DATABASE コマンド ) を使用して 障害が発生したプライマリ データベースを新規構成のスタンバイ データベースとして再作成します 元に戻すための手順については Oracle Data Guard Broker を参照してください 3-8 ページの 3.2 項 フィジカル スタンバイ データベースの作成手順 または 4-4 ページの 4.2 項 ロジカル スタンバイ データベースの作成手順 の手順に従って 障害の発生したデータベースを再作成し 新規スタンバイ データベースとして構成に追加します 障害が発生したプライマリ データベースがリストアされてスタンバイ ロールで稼働し始めた後 オプションでスイッチオーバーを実行し それぞれのデータベースを元の ( 障害発生前の ) ロールに推移できます 詳細は 7-14 ページの 項 ロジカル スタンバイ データベースが関与するスイッチオーバー を参照してください 7-20 Oracle Data Guard 概要および管理

139 ロールの推移後のフラッシュバック データベースの使用 7.4 ロールの推移後のフラッシュバック データベースの使用 ロールの推移後に 必要に応じて FLASHBACK DATABASE コマンドを使用して データベースをロールの推移が発生する前の時点またはシステム変更番号 (SCN) まで戻すことができます フィジカル スタンバイ データベース環境では Data Guard 構成を維持するためにプライマリ データベースとすべてのスタンバイ データベースのフラッシュバックが必要になる場合があります プライマリ データベースを特定の SCN または時点までフラッシュバックする場合は すべてのスタンバイ データベースを同じ ( またはそれ以前の )SCN または時点までフラッシュバックする必要があります これにより REDO Apply の開始後に フィジカル スタンバイ データベースではプライマリ データベースから受信した REDO データの適用が自動的に開始されます この方法でプライマリ データベースまたはスタンバイ データベースをフラッシュバックすると 過去のスイッチオーバーを認識する必要がありません Oracle では SCN または時点が過去のスイッチオーバーより前であれば 過去のスイッチオーバーにまたがって自動的にフラッシュバックできます 注意 : ロールの推移が発生する前に データベースでフラッシュバック データベースを有効化しておく必要があります 詳細は Oracle Database バックアップおよびリカバリ基礎 を参照してください スイッチオーバー後のフラッシュバック データベースの使用 スイッチオーバー後に FLASHBACK DATABASE コマンドを使用して データベースをスイッチオーバー発生前の時点またはシステム変更番号 (SCN) に戻すことができます スイッチオーバーにフィジカル スタンバイ データベースが関与していた場合 フラッシュバック操作中はプライマリおよびスタンバイ データベース ロールが保持されます つまり データベースが実行中のロールは フラッシュバックした時点またはターゲット SCN までデータベースがフラッシュバックされても変化しません スイッチオーバー後からフラッシュバックの前までフィジカル スタンバイ ロールで実行されていたデータベースは フラッシュバック データベース操作後もフィジカル スタンバイ データベースで実行されます スイッチオーバーにロジカル スタンバイ データベースが関与していた場合 フラッシュバックするとスタンバイ データベースのロールはフラッシュバックした時点またはターゲット SCN でのロールに変更されます フェイルオーバー後のフラッシュバック データベースの使用 フラッシュバック データベースを使用して 障害の発生したプライマリ データベースをフェイルオーバー発生前の時点に変換してから スタンバイ データベースに変換できます 手順の詳細は 12.4 項 フェイルオーバー後のフラッシュバック データベースの使用 を参照してください ロールの推移 7-21

140 ロールの推移後のフラッシュバック データベースの使用 7-22 Oracle Data Guard 概要および管理

141 8 フィジカル スタンバイ データベースの管理 この章では フィジカル スタンバイ データベースの管理方法について説明します この章は 次の項目で構成されています フィジカル スタンバイ データベースの起動と停止 スタンバイ データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法 スタンバイ データベースに影響を与えるプライマリ データベース イベントの管理 OPEN RESETLOGS 文を使用したリカバリ プライマリおよびスタンバイ データベースの監視 フィジカル スタンバイ データベースに関するログ適用レートのチューニング この章の各項では フィジカル スタンバイ データベースを管理するための SQL 文 初期化パラメータおよびビューの使用方法について それぞれ説明します この章で説明する管理タスクを自動化するために Data Guard Broker を使用する場合は Oracle Data Guard Broker を参照してください フィジカル スタンバイ データベースの管理 8-1

142 フィジカル スタンバイ データベースの起動と停止 8.1 フィジカル スタンバイ データベースの起動と停止 この項では フィジカル スタンバイ データベースの起動および停止に使用する SQL*Plus 文について説明します フィジカル スタンバイ データベースの起動 フィジカル スタンバイ データベースを起動するには 管理者権限で SQL*Plus を使用してデータベースに接続し SQL*Plus STARTUP または STARTUP MOUNT 文を使用します これらをフィジカル スタンバイ データベースで使用すると 次のことが実行されます STARTUP 文は データベースを起動し フィジカル スタンバイ データベースとしてマウントして 読取り専用アクセス用にデータベースをオープンします STARTUP MOUNT 文は データベースを起動し フィジカル スタンバイ データベースとしてマウントしますが データベースをオープンしません マウントされたデータベースは プライマリ データベースからアーカイブ REDO データを受信できます 次に REDO Apply またはリアルタイム適用を開始するか あるいはデータベースを読取り専用アクセス用にオープンします 次に例を示します 1. フィジカル スタンバイ データベースを起動し マウントします SQL> STARTUP MOUNT; 2. REDO Apply またはリアルタイム適用を開始します REDO Apply を開始するには 次の文を発行します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> DISCONNECT FROM SESSION; リアルタイム適用を開始するには 次の文を発行します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE; プライマリ データベースで V$ARCHIVE_DEST_STATUS ビューの RECOVERY_MODE 列を問い合せ スタンバイ データベースの操作を REDO Apply の場合は MANAGED_RECOVERY リアルタイム適用の場合は MANAGED REAL TIME APPLY として表示します REDO Apply については 6.3 項 リアルタイム適用については 項 フィジカル スタンバイ データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法については 8.2 項を参照してください 注意 : 新しく作成した プライマリ データベースからの REDO データをまだ受信していないフィジカル スタンバイ データベース上では 初めて REDO Apply を開始すると ORA メッセージが戻されることがあります このメッセージは REDO Apply がメディア リカバリ用の開始順序番号を判別できないことを示します このエラーが発生した場合は スタンバイ データベースでアーカイブ REDO ログ ファイルを手動で検索して登録するか または自動アーカイブが発生するまで待機したあと REDO Apply を再開する必要があります 8-2 Oracle Data Guard 概要および管理

143 スタンバイ データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法 フィジカル スタンバイ データベースの停止 フィジカル スタンバイ データベースを停止し REDO Apply を停止するには SQL*Plus の SHUTDOWN 文を使用します 停止処理が完了するまで データベース停止を開始したセッションに制御が戻されません プライマリ データベースが起動して実行中の場合は スタンバイ データベースを停止する前に プライマリ データベースで宛先を遅延し ログ スイッチ操作を実行します REDO Apply を停止してからデータベースを停止する手順は 次のとおりです 1. 次の問合せを発行し スタンバイ データベースが REDO Apply またはリアルタイム適用を実行しているかどうかを識別します MRP0 または MRP プロセスが存在する場合は スタンバイ データベースが REDO Apply を実行しています SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY; 2. REDO Apply が実行中の場合は 次の例に示すように取り消します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 3. スタンバイ データベースを停止します SQL> SHUTDOWN IMMEDIATE; 8.2 スタンバイ データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法 スタンバイ データベースが読取り専用アクセス用にオープンしている場合 ユーザーはスタンバイ データベースを問い合せることができますが 更新はできません したがって レポートを生成するためにスタンバイ データベースを使用すると プライマリ データベース負荷を低減できます スタンバイ データベースを定期的に読取り専用アクセス用としてオープンし REDO Apply がスタンバイ データベースを適切に更新していることを確認するために 非定型問合せを実行できます ( 分散問合せの場合 読取り専用データベースに対して問合せを発行する前に まず ALTER DATABASE SET TRANSACTION READ ONLY 文を発行する必要があります ) 図 8-1 に 読取り専用アクセス用にオープンしたスタンバイ データベースを示します フィジカル スタンバイ データベースの管理 8-3

144 スタンバイ データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法 図 8-1 読取り専用アクセス用にオープンしたスタンバイ データベース 関連項目 : スタンバイ データベースをオープンするかどうかの評価 読取り専用アクセス用にフィジカル スタンバイ データベースをオープン フィジカル スタンバイ データベースを開発 レポートまたはテストのために読取り / 書込みモードで一時的にオープンしてから 過去の特定時点までフラッシュバックして元に戻すことができます データベースがフラッシュバックされると Data Guard では自動的にスタンバイ データベースをプライマリ データベースと同期化します プライマリ データベースのバックアップ コピーからフィジカル スタンバイ データベースを再作成する必要はありません 関連項目 : フィジカル スタンバイ データベースを読取り / 書込みレポート用データベースとしてアクティブにした後 プライマリ データベースと再同期化する方法を示す使用例は 12.6 項を参照してください 8-4 Oracle Data Guard 概要および管理

145 スタンバイ データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法 スタンバイ データベースをオープンするかどうかの評価 フィジカル スタンバイ データベースを読取り専用または読取り / 書込みアクセス用にオープンするかどうかを判断する場合は 次のことを考慮してください フィジカル スタンバイ データベースを読取り専用でオープンすると フェイルオーバー後は再起動する必要があるため 障害や停止からのリカバリ所要時間が長くなることがあります フィジカル スタンバイ データベースが前回の起動後に読取り専用でオープンされていなければ フェイルオーバー後に再起動する必要はないため システムの可用性が向上します スタンバイ データベースが読取り専用または読取り / 書込みアクセス用にオープンされている間は プライマリ データベースから受信した REDO データが適用されないため プライマリ データベースとのトランザクション一貫性が維持されません フィジカル スタンバイ データベースがオープンされている場合 プライマリ データベースからの REDO データはスタンバイ データベースによって受信されますが ログ ファイルは適用されません スタンバイ データベースで REDO Apply を再開し アーカイブ REDO ログ ファイルを適用して スタンバイ データベースをプライマリ データベースと再同期化させることが必要となる場合があります 蓄積されたアーカイブ REDO ログ ファイルの適用には余分に時間がかかるため スタンバイ データベースを読取り専用アクセス用にオープンしておくと フェイルオーバーまたはスイッチオーバーに時間がかかる場合があります スタンバイ システムに複数のスタンバイ データベースを構成すると フィジカル スタンバイ データベースをレポート生成用またはクローン データベースとして使用すると同時に すばやくフェイルオーバーまたはスイッチオーバーを実行することが可能です たとえば ビジネス要件に基づき 次の構成が可能です 1 つのスタンバイ データベースに 2 つのフィジカル スタンバイ データベースを構成します 常に REDO Apply を実行することにより プライマリ データベースと可能なかぎり同期を取り もう一方のスタンバイ データベースは 営業時間中はレポート生成のために読取り専用モードでオープンにします 1 つのフィジカル スタンバイ データベースを構成し 障害時リカバリに備えてプライマリ データベースのコピーを維持します また ロジカル スタンバイ データベースを構成し プライマリ データベースの最新データへのアクセスが必要なレポート生成タスクをオフロードします 同じシステム上で複数のスタンバイ データベースを構成する場合は REDO データを各アーカイブ先に個別に転送するのではなく LOG_ARCHIVE_DEST_n 初期化パラメータの DEPENDENCY 属性を使用して 1 つのアーカイブ先がすべてのアーカイブ先のかわりに REDO データを受信するように定義することを考慮してください 詳細は 項を参照してください フィジカル スタンバイ データベースの管理 8-5

146 スタンバイ データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法 読取り専用アクセス用にフィジカル スタンバイ データベースをオープン フィジカル スタンバイ データベースは 次の手順に従って 読取り専用アクセス用オープンから REDO Apply の実行に ( またはその逆に ) 変更できます スタンバイ データベースが停止しているときに読取り専用アクセス用にオープンする方法次の文を使用して データベースを起動し マウントし 読取り専用アクセス用にオープンします SQL> STARTUP; REDO Apply の実行中にスタンバイ データベースを読取り専用アクセス用にオープンする方法 1. REDO Apply を取り消します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 2. 次のように入力してデータベースを読取り専用アクセス用にオープンします SQL> ALTER DATABASE OPEN; 読取り専用アクセス用にオープンするために インスタンスを停止する必要はありません 注意 : デフォルトで ALTER DATABASE OPEN 文は読取り専用モードでフィジカル スタンバイ データベースをオープンします Oracle データベースは 制御ファイルの情報に基づいて このデータベースがフィジカル スタンバイ データベースであるかどうかを判断します スタンバイ データベースを読取り専用アクセス用オープンから REDO Apply 実行に変更する方法 1. スタンバイ データベースのすべてのアクティブ ユーザー セッションを終了します 2. REDO Apply を再開します REDO Apply を開始するには 次の文を発行します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> DISCONNECT FROM SESSION; リアルタイム適用を有効にするには USING CURRENT LOGFILE 句を使用します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE; これらの適用モードを開始するために インスタンスを停止する必要はありません 8-6 Oracle Data Guard 概要および管理

147 スタンバイ データベースに影響を与えるプライマリ データベース イベントの管理 8.3 スタンバイ データベースに影響を与えるプライマリ データベース イベントの管理 問題が起きないようにするには スタンバイ データベースに影響するプライマリ データベースのイベントを認識し それらに応答する方法を見極める必要があります この項では それらのイベントについて説明し イベントに対して推奨される応答についても説明します プライマリ データベースで発生するイベントまたは変更の一部は REDO データを介してスタンバイ データベースに自動的に伝播されるため スタンバイ データベースでそれ以上のアクションは不要です それ以外の場合は スタンバイ データベースでメンテナンス タスクを実行する必要があります プライマリ データベースで行われた変更をスタンバイ データベースへ伝播するためには データベース管理者 (DBA) の介入が必要かどうかを表 8-1 に示します また これらのイベントに応答する方法についても簡単に説明します 応答の詳細は 表に示されている参照先の項で説明します 次のイベントは REDO 転送サービスおよび REDO Apply によって自動的に管理されるため データベース管理者の介入は不要です ENABLE THREAD または DISABLE THREAD 句を使用した SQL ALTER DATABASE 文の発行 表領域の状態の変更 ( 読取り / 書込みまたは読取り専用に変更され オンラインまたはオフラインにされる ) STANDBY_FILE_MANAGEMENT 初期化パラメータが AUTO に設定されている場合のデータファイルの追加または表領域の作成 表 8-1 プライマリ データベースでの変更後にスタンバイ データベースで必要なアクション 参照先 プライマリ データベースで行われた変更 スタンバイ データベースで必要なアクション 項 データファイルの追加または表領域の作成 STANDBY_FILE_MANAGEMENT 初期化パラメータを AUTO に設定 していない場合は 新しいデータファイルをスタンバイ データ ベースにコピーする必要がある 項 表領域またはデータファイルの削除 DROP または DELETE コマンドが含まれているアーカイブ REDO ログ ファイルの適用後に プライマリ データベースとスタン バイ データベースからデータファイルを削除する 項 トランスポータブル表領域の使用 プライマリ データベースとスタンバイ データベースの間で表 領域を移動する 項データファイル名の変更スタンバイ データベースでデータファイルを改名する 項 REDO ログ ファイルの追加または削除変更をスタンバイ データベースで同期化する 項 NOLOGGING または UNRECOVERABLE 句を使用した DML または DDL 操作の実行 ログに記録されていない変更を含むデータファイルをスタンバイ データベースに送信する 第 13 章 初期化パラメータの変更 スタンバイ パラメータを動的に変更するか またはスタンバ イ データベースを停止し 初期化パラメータ ファイルを更新 する フィジカル スタンバイ データベースの管理 8-7

148 スタンバイ データベースに影響を与えるプライマリ データベース イベントの管理 データファイルの追加または表領域の作成 STANDBY_FILE_MANAGEMENT 初期化パラメータを使用して 次のように プライマリ データベースへのデータファイルの追加がスタンバイ データベースに自動的に伝播されるかどうかを制御できます スタンバイ データベースのサーバー パラメータ ファイル (SPFILE) で STANDBY_ FILE_MANAGEMENT 初期化パラメータを AUTO に設定した場合は プライマリ データベースで作成された新しいデータファイルがスタンバイ データベースでも自動的に作成されます STANDBY_FILE_MANAGEMENT 初期化パラメータを指定していない場合 またはこのパラメータを MANUAL に設定した場合は 新しいデータファイルをプライマリ データベースに追加するときに そのデータファイルをスタンバイ データベースに手動でコピーする必要があります 既存のデータファイルを別のデータベースからプライマリ データベースへコピーする場合は STANDBY_FILE_MANAGEMENT 初期化パラメータの設定に関係なく 新しいデータファイルをスタンバイ データベースにコピーし スタンバイ制御ファイルを再作成する必要があります 次の各項では STANDBY_FILE_MANAGEMENT 初期化パラメータが AUTO または MANUAL に設定されている場合に データファイルをプライマリおよびスタンバイ データベースに追加する例を示します STANDBY_FILE_MANAGEMENT が AUTO に設定されている場合 次の例は STANDBY_FILE_MANAGEMENT 初期化パラメータが AUTO に設定されている場合に 新しいデータファイルをプライマリおよびスタンバイ データベースに追加する手順を示しています 1. プライマリ データベースに新しい表領域を追加します SQL> CREATE TABLESPACE new_ts DATAFILE '/disk1/oracle/oradata/payroll/t_db2.dbf' 2> SIZE 1m AUTOEXTEND ON MAXSIZE UNLIMITED; 2. REDO データがスタンバイ データベースに転送され そこで適用されるように カレントのオンライン REDO ログ ファイルをアーカイブします SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 3. 新しいデータファイルがプライマリ データベースに追加されたかどうかを確認します SQL> SELECT NAME FROM V$DATAFILE; NAME /disk1/oracle/oradata/payroll/t_db1.dbf /disk1/oracle/oradata/payroll/t_db2.dbf 4. 新しいデータファイルがスタンバイ データベースに追加されたかどうかを確認します SQL> SELECT NAME FROM V$DATAFILE; NAME /disk1/oracle/oradata/payroll/s2t_db1.dbf /disk1/oracle/oradata/payroll/s2t_db2.dbf 8-8 Oracle Data Guard 概要および管理

149 スタンバイ データベースに影響を与えるプライマリ データベース イベントの管理 STANDBY_FILE_MANAGEMENT が MANUAL に設定されている場合 この項では STANDBY_FILE_MANAGEMENT 初期化パラメータが MANUAL に設定されている場合に 新しいデータファイルをプライマリおよびスタンバイ データベースに追加する方法について説明します スタンバイ データファイルが RAW デバイスに存在する場合は STANDBY_FILE_MANAGEMENT 初期化パラメータを MANUAL に設定する必要があります また この項では 発生したエラーからのリカバリ方法についても説明します 注意 : 次の手順は Oracle Managed Files を使用するデータベースには使用しないでください また RAW デバイスのパス名がプライマリ サーバー上とスタンバイ サーバー上で異なる場合は DB_FILE_NAME_CONVERT 初期化パラメータを使用してパス名を変換してください RAW デバイスでの STANDBY_FILE_MANAGEMENT パラメータの使用 STANDBY_FILE_MANAGEMENT パラメータを AUTO に設定すると 新規データファイルがプライマリ データベースに追加または削除された場合に 手動で変更しなくてもスタンバイ データベースに対応する変更が加えられます これは スタンバイ データベースでファイル システムが使用されている場合です スタンバイ データベースでデータファイルに RAW デバイスが使用されている場合も STANDBY_FILE_MANAGEMENT 初期化パラメータは機能しますが 手動による介入が必要です この手動による介入では スタンバイ データベース上のログ適用サービスにより新規データファイルを作成する REDO データがリカバリされる前に RAW デバイスの存在を確認します プライマリ データベースで データファイルが RAW デバイスに常駐する新規表領域を作成します それと同時に スタンバイ データベースでも同じ RAW デバイスを作成します 次に例を示します SQL> CREATE TABLESPACE MTS2 DATAFILE '/dev/raw/raw100' size 1m; Tablespace created. SQL> ALTER SYSTEM SWITCH LOGFILE; System altered. スタンバイ データベースでは RAW デバイスが存在するため自動的にデータファイルが追加されます スタンバイ アラート ログには次のように示されます Fri Apr 8 09:49: Media Recovery Log /u01/miller/flash_recovery_area/mts_stby/archivelog/2005_04_08/o1_ mf_1_7_15ffgt0z_.arc Recovery created file /dev/raw/raw100 Successfully added datafile 6 to media recovery Datafile #6: '/dev/raw/raw100' Media Recovery Waiting for thread 1 sequence 8 (in transit) ただし プライマリ システム上で RAW デバイスが作成されてもスタンバイ上で作成されなければ MRP プロセスはファイル作成エラーにより停止します たとえば プライマリ データベースで次の文を発行します SQL> CREATE TABLESPACE MTS3 DATAFILE '/dev/raw/raw101' size 1m; Tablespace created. SQL> ALTER SYSTEM SWITCH LOGFILE; System altered. フィジカル スタンバイ データベースの管理 8-9

150 スタンバイ データベースに影響を与えるプライマリ データベース イベントの管理 スタンバイ システムには RAW デバイス /Dave/raw/raw101 が作成されていません アーカイブをリカバリすると スタンバイ アラート ログに次のメッセージが示されます Fri Apr 8 10:00: Media Recovery Log /u01/miller/flash_recovery_area/mts_stby/archivelog/2005_04_08/o1_ mf_1_8_15ffjrov_.arc File #7 added to control file as 'UNNAMED00007'. Originally created as: '/dev/raw/raw101' Recovery was unable to create the file as: '/dev/raw/raw101' MRP0: Background Media Recovery terminated with error 1274 Fri Apr 8 10:00: Errors in file /u01/miller/mts/dump/mts_mrp0_21851.trc: ORA-01274: データファイル '/dev/raw/raw101' を追加できません - ファイルを作成できませんでした ORA-01119: データベース ファイル '/dev/raw/raw101' の作成中にエラーが発生しました ORA-27041: ファイルをオープンできません Linux Error: 13: Permission denied Additional information: 1 Some recovered datafiles maybe left media fuzzy Media recovery may continue but open resetlogs may fail Fri Apr 8 10:00: Errors in file /u01/miller/mts/dump/mts_mrp0_21851.trc: ORA-01274: データファイル '/dev/raw/raw101' を追加できません - ファイルを作成できませんでした ORA-01119: データベース ファイル '/dev/raw/raw101' の作成中にエラーが発生しました ORA-27041: ファイルをオープンできません Linux Error: 13: Permission denied Additional information: 1 Fri Apr 8 10:00: MTS; MRP0: Background Media Recovery process shutdown ARCH: Connecting to console port エラーのリカバリ 項で説明した問題を修正する手順は 次のとおりです 1. スタンバイ データベースに RAW スライスを作成し Oracle ユーザーに権限を割り当てます 2. V$DATAFILE ビューを問い合せます 次に例を示します SQL> SELECT NAME FROM V$DATAFILE; NAME /u01/miller/mts/system01.dbf /u01/miller/mts/undotbs01.dbf /u01/miller/mts/sysaux01.dbf /u01/miller/mts/users01.dbf /u01/miller/mts/mts.dbf /dev/raw/raw100 /u01/app/oracle/product/10.1.0/dbs/unnamed00007 SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL; SQL> ALTER DATABASE CREATE DATAFILE 2 '/u01/app/oracle/product/10.1.0/dbs/unnamed00007' 3 AS 4 '/dev/raw/raw101'; 8-10 Oracle Data Guard 概要および管理

151 スタンバイ データベースに影響を与えるプライマリ データベース イベントの管理 3. スタンバイ アラート ログに 次のような情報が表示されます Fri Apr 8 10:09: alter database create datafile '/dev/raw/raw101' as '/dev/raw/raw101' Fri Apr 8 10:09: Completed: alter database create datafile '/dev/raw/raw101' a 4. スタンバイ データベースで STANDBY_FILE_MANAGEMENT を AUTO に設定して REDO Apply を再開します SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO; SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT; この時点で REDO Apply は新規の RAW デバイスのデータファイルを使用し リカバリが続行されます 表領域の削除とデータファイルの削除 プライマリ データベースで 1 つ以上のデータファイルまたは表領域を削除した場合は 次の手順に従って スタンバイ データベースでも対応するデータファイルを削除する必要があります 次の各項では STANDBY_FILE_MANAGEMENT 初期化パラメータが AUTO または MANUAL に設定されている場合に 表領域およびデータファイル削除する例を示します STANDBY_FILE_MANAGEMENT が AUTO または MANUAL に設定されている場合 次の手順は STANDBY_FILE_MANAGEMENT 初期化パラメータが MANUAL または AUTO に設定されている場合に有効です 1. プライマリ データベースから表領域を削除します SQL> DROP TABLESPACE tbs_4; SQL> ALTER SYSTEM SWITCH LOGFILE; 2. REDO Apply が実行中であることを確認します ( 実行中の場合は 変更がスタンバイ データベースに適用されます ) 次の問合せが MRP または MRP0 プロセスを戻した場合 REDO Apply は実行中です SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY; 削除されたデータファイルがデータベースに属していないことを確認するには V$DATAFILE ビューを問い合せます 3. アーカイブ REDO ログ ファイルがスタンバイ データベースに適用された後 スタンバイ システムで対応するデータファイルを削除します 次に例を示します % rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf 4. 削除した表領域の REDO 情報がスタンバイ データベースで適用されたことを確認した後 プライマリ データベースで表領域のデータファイルを削除できます 次に例を示します % rm /disk1/oracle/oradata/payroll/tbs_4.dbf DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES の使用 プライマリ データベースで SQL DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES 文を発行すると プライマリ データベースとスタンバイ データベースの両方からデータファイルを削除できます この文を使用するには STANDBY_FILE_MANAGEMENT 初期化パラメータを AUTO に設定する必要があります たとえば プライマリ サイトで表領域を削除するには 次のように入力します SQL> DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES tbs_4; SQL> ALTER SYSTEM SWITCH LOGFILE; フィジカル スタンバイ データベースの管理 8-11

152 スタンバイ データベースに影響を与えるプライマリ データベース イベントの管理 フィジカル スタンバイ データベースでのトランスポータブル表領域の使用 Oracle トランスポータブル表領域機能を使用すると Oracle データベースのサブセットを移動して 別の Oracle データベースにプラグインできます これにより 実際には表領域がデータベース間で移動します フィジカル スタンバイの使用中に表領域セットをプライマリ データベースに移動またはコピーする手順は 次のとおりです 1. トランスポートする表領域セットのデータファイルとその表領域セットの構造情報を含むエクスポート ファイルで構成される トランスポータブル表領域セットを生成します 2. 次の手順で表領域セットをトランスポートします a. データファイルとエクスポート ファイルをプライマリ データベースにコピーします b. データファイルをスタンバイ データベースにコピーします データファイルは DB_FILE_NAME_CONVERT 初期化パラメータで定義したディレクトリにコピーする必要があります DB_FILE_NAME_CONVERT が定義されていない場合は トランスポータブル表領域を含む REDO データが適用されて失敗した後に ALTER DATABASE RENAME FILE 文を発行してスタンバイの制御ファイルを変更します STANDBY_FILE_MANAGEMENT 初期化パラメータは AUTO に設定する必要があります 3. 表領域をプラグインします Data Pump ユーティリティを起動して 表領域セットをプライマリ データベースにプラグインします スタンバイ サイトで REDO データが生成されて適用され 表領域がスタンバイ データベースにプラグインされます トランスポータブル表領域の詳細は Oracle Database 管理者ガイド を参照してください プライマリ データベースのデータファイルの改名 プライマリ データベースで 1 つ以上のデータファイルを改名した場合 その変更はスタンバイ データベースに伝播されません STANDBY_FILE_MANAGEMENT 初期化パラメータを AUTO に設定しても変更処理は自動的に実行されないため スタンバイ データベースにある同じデータファイルを改名する場合は スタンバイ データベースで同じ変更を手動で行う必要があります 次の手順では プライマリ データベースでデータファイルを改名し その変更をスタンバイ データベースに手動で伝播する方法について説明します 1. プライマリ データベースでデータファイルを改名するには 表領域をオフラインにします SQL> ALTER TABLESPACE tbs_4 OFFLINE; 2. SQL プロンプトを終了し UNIX の mv コマンドなどのオペレーティング システム コマンドを発行して プライマリ システム上のデータファイルを改名します % mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf 3. プライマリ データベース内のデータファイルを改名し 表領域をオンラインに戻します SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE 2> '/disk1/oracle/oradata/payroll/tbs_4.dbf' 3> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf'; SQL> ALTER TABLESPACE tbs_4 ONLINE; 8-12 Oracle Data Guard 概要および管理

153 スタンバイ データベースに影響を与えるプライマリ データベース イベントの管理 4. スタンバイ データベースに接続し V$ARCHIVED_LOG ビューを問い合せてすべてのアーカイブ REDO ログ ファイルが適用されたことを確認した後 REDO Apply を停止します SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#; SEQUENCE# APP YES 9 YES 10 YES 11 YES 4 rows selected. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 5. スタンバイ データベースを停止します SQL> SHUTDOWN; 6. UNIX の mv コマンドなどのオペレーティング システム コマンドを使用して スタンバイ サイトでデータファイルを改名します % mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_ x.dbf 7. スタンバイ データベースを起動し マウントします SQL> STARTUP MOUNT; 8. スタンバイ制御ファイルのデータファイルを改名します STANDBY_FILE_MANAGEMENT 初期化パラメータは MANUAL に設定する必要があります SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf' 2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf'; 9. スタンバイ データベースで REDO Apply を再開します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> DISCONNECT FROM SESSION; スタンバイ システムで対応するデータファイルを改名しないでスタンバイ データベース制御ファイルをリフレッシュしようとすると スタンバイ データベースは改名されたデータファイルの使用を試みますが 改名されたデータファイルは見つかりません したがって アラート ログに次のようなエラー メッセージが表示されます ORA-00283: エラーによってリカバリ セッションは取り消されました ORA-01157: データファイル 4 を識別 / ロックできません - DBWR トレース ファイルを参照してください ORA-01110: データファイル 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf' フィジカル スタンバイ データベースの管理 8-13

154 スタンバイ データベースに影響を与えるプライマリ データベース イベントの管理 オンライン REDO ログ ファイルの追加または削除 データベースをチューニングするために オンライン REDO ログ ファイルのサイズと数を変更する場合があります スタンバイ データベースへの影響なしに プライマリ データベースへオンライン REDO ログ ファイル グループまたはメンバーを追加または削除できます 同様に スタンバイ データベースへの影響なしに プライマリ データベースからログ ファイル グループまたはメンバーを削除できます ただし これらの変更は スイッチオーバー後にスタンバイ データベースのパフォーマンスに影響します 注意 : オンライン REDO ログ ファイルをプライマリ データベースに追加した場合は 対応するオンライン REDO ログ ファイルおよびスタンバイ REDO ログ ファイルをスタンバイ データベースに追加する必要があります たとえば オンライン REDO ログ ファイルがプライマリ データベースに 10 個 スタンバイ データベースに 2 個ある場合 新しいプライマリ データベースとして機能するようにスタンバイ データベースにスイッチオーバーすると 新しいプライマリ データベースは元のプライマリ データベースより頻繁にアーカイブするように強制されます したがって プライマリ サイトでオンライン REDO ログ ファイルを追加または削除した場合は 次の手順に従って スタンバイ データベースで変更を同期化することが重要です 1. REDO Apply が実行中の場合は ログ ファイルを変更する前に REDO Apply を取り消す必要があります 2. STANDBY_FILE_MANAGEMENT 初期化パラメータを AUTO に設定している場合は 値を MANUAL に変更します 3. オンライン REDO ログ ファイルを追加または削除します オンライン REDO ログ ファイルを追加するには 次のような SQL 文を使用します SQL> ALTER DATABASE ADD LOGFILE '/disk1/oracle/oradata/payroll/prmy3.log' SIZE 100M; オンライン REDO ログ ファイルを削除するには 次のような SQL 文を使用します SQL> ALTER DATABASE DROP LOGFILE '/disk1/oracle/oradata/payroll/prmy3.log'; 4. 手順 3 で使用した文を各スタンバイ データベースで繰り返します 5. STANDBY_FILE_MANAGEMENT 初期化パラメータおよび REDO Apply オプションを元の状態にリストアします ログに記録されていないまたはリカバリ不能な操作 NOLOGGING または UNRECOVERABLE 句を使用して DML または DDL 操作を実行するとスタンバイ データベースは無効になるため 修正のために多大な DBA 管理アクティビティが必要になる場合があります SQL ALTER DATABASE または SQL ALTER TABLESPACE 文で FORCELOGGING 句を指定すると NOLOGGING 設定を上書きできます ただし この文はすでに無効になっているデータベースを修正しません NOLOGGING 句を使用した後のリカバリについては 項を参照してください 8-14 Oracle Data Guard 概要および管理

155 OPEN RESETLOGS 文を使用したリカバリ 8.4 OPEN RESETLOGS 文を使用したリカバリ Data Guard では RESETLOGS オプションを使用してプライマリ データベースがオープンされた後も フィジカル スタンバイ データベースでリカバリを続行できます プライマリ データベースで ALTER DATABASE OPEN RESETLOGS 文を発行すると データベースのインカネーションが変更され REDO データの新規ブランチが作成されます フィジカル スタンバイ データベースが REDO データの新規ブランチを受信すると REDO Apply ではそれが自動的に使用されます フィジカル スタンバイ データベースの場合 スタンバイ データベースにより新規リセットログの SCN より後 (REDO データの新規ブランチの開始より後 ) の REDO データが適用されていなければ 手動による介入は必要ありません 次の表に スタンバイ データベースとプライマリ データベースのブランチを再同期化する方法を示します スタンバイ データベースの状態 操作 実行する手順 新規リセットログの SCN の後 (REDO データの新規ブランチの開始より後 ) の REDO データが適用されていない場合 REDO Apply は自動的に REDO の新規ブランチを使用します 手動による介入は必要ありません MRP は 自動的にスタンバイ データベースを REDO データの新規ブランチと再同期化します 新規リセットログの SCN の後 (REDO データの新規ブランチの開始より後 ) の REDO データが適用され スタンバイ データベースでフラッシュバック データベースが使用可能になっている場合 新規リセットログの SCN の後 (REDO データの新規ブランチの開始より後 ) の REDO データが適用され スタンバイ データベースでフラッシュバック データベースが使用可能になっていない場合 スタンバイ データベースは REDO データの将来の新規ブランチでリカバリされます 指定のプライマリ データベース ブランチで プライマリ データベースとスタンバイの内容にずれが生じます 項の手順に従ってフィジカル スタンバイ データベースをフラッシュ バックします 2. REDO Apply を再開し 新規リセットログ ブランチへの REDO データの適用を続行します MRP は 自動的にスタンバイ データベースを新規ブランチと再同期化します 第 3 章の手順に従ってフィジカル スタンバイ データベースを再作成します REDO データの新規ブランチから介入するアーカイブ REDO ログ ファイルが欠落している場合 REDO データの前のブランチの終わりからアーカイブ REDO ログ ファイルが欠落している場合 MRP は欠落しているログ ファイルが取得されるまで続行できません MRP は欠落しているログ ファイルが取得されるまで続行できません 各ブランチから欠落しているアーカイブ REDO ログ ファイルを検索して登録します 前のブランチから欠落しているアーカイブ REDO ログ ファイルを検索して登録します データベース インカネーション OPEN RESETLOGS 操作を介したリカバリおよびフラッシュバック データベースの詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください フィジカル スタンバイ データベースの管理 8-15

156 プライマリおよびスタンバイ データベースの監視 8.5 プライマリおよびスタンバイ データベースの監視 この項では Data Guard 環境のプライマリおよびスタンバイ データベースを監視するための情報の検索方法について概要を説明します この項は 次の項目で構成されています アラート ログ 動的パフォーマンス ビュー ( 固定ビュー ) リカバリの進捗の監視 フィジカル スタンバイ データベースでのログ適用サービスの監視 表 8-2 に プライマリ データベースで発生する共通イベント およびプライマリ サイトとスタンバイ サイトでこれらのイベントを監視できるファイルとビューに関する情報をまとめます 表 8-2 プライマリ データベースの共通アクションを監視できる場所プライマリ データベース イベントプライマリ サイト情報 スタンバイ サイト情報 ENABLE THREAD または DISABLE THREAD 句を指定した SQL ALTER DATABASE 文の発行 現行のデータベース ロール 保護モードと保護レベル スイッチオーバー ステータスおよびファスト スタート フェイルオーバー情報 アラート ログ V$THREAD ビュー V$DATABASE アラート ログ V$DATABASE REDO ログの変更 アラート ログ V$LOG ビュー アラート ログ V$LOGFILE ビューの STATUS 列 CREATE CONTROLFILE 文の発行アラート ログアラート ログ 管理リカバリの実行アラート ログアラート ログ 表領域の状態の変更 ( 読取り / 書込みまたは読取り専用にされ オンラインまたはオフラインにされる ) データファイルの追加または表領域の作成 DBA_TABLESPACES ビュー アラート ログ DBA_DATA_FILES ビュー アラート ログ V$RECOVER_FILE ビュー V$DATAFILE ビューアラート ログ 表領域の削除 DBA_DATA_FILES ビュー アラート ログ V$DATAFILE ビューアラート ログ 表領域またはデータファイルをオフラインにする またはデータファイルをオフラインで削除する V$RECOVER_FILE ビュー アラート ログ DBA_TABLESPACES V$RECOVER_FILE ビュー DBA_TABLESPACES データファイル名の変更 V$DATAFILE アラート ログ V$DATAFILE ビューアラート ログ ログに記録されていないまたはリカバリ不能な操作 V$DATAFILE ビュー V$DATABASE ビュー アラート ログ リカバリの進捗 V$ARCHIVE_DEST_STATUS ビュー アラート ログ V$ARCHIVED_LOG ビュー V$LOG_HISTORY ビュー V$MANAGED_STANDBY ビューアラート ログ 8-16 Oracle Data Guard 概要および管理

157 プライマリおよびスタンバイ データベースの監視 表 8-2 プライマリ データベースの共通アクションを監視できる場所 ( 続き ) プライマリ データベース イベント プライマリ サイト情報 REDO 転送のステータスと進捗 V$ARCHIVE_DEST_STATUS ビュー V$ARCHIVED_LOG ビュー V$ARCHIVE_DEST ビュー アラート ログ スタンバイ サイト情報 V$ARCHIVED_LOG ビューアラート ログ データファイルの自動拡張アラート ログアラート ログ OPEN RESETLOGS または CLEAR UNARCHIVED LOGFILES 文の発行 アラート ログ アラート ログ 初期化パラメータの変更アラート ログアラート ログ アラート ログ データベースのアラート ログは メッセージとエラーに関する時系列のレコードです アラート ログには Oracle データベースに関する情報に加えて 次のような Data Guard 固有の操作に関する情報も含まれています SQL 文の ALTER DATABASE RECOVER MANAGED STANDBY STARTUP SHUTDOWN ARCHIVE LOG RECOVER などの管理操作に関連するメッセージ ARC0 MRP0 RFS LGWR などのバックグラウンド プロセスでレポートされる管理操作に関連するエラー 管理操作の完了タイムスタンプ アラート ログは 特定のプロセスで生成されたトレース ファイルまたはダンプ ファイルに関する情報も提供します 動的パフォーマンス ビュー ( 固定ビュー ) Oracle データベースには 基礎となるビューのセットがあります これらのビューは データベースがオープン状態および使用中の場合に連続的に更新されるため 動的パフォーマンス ビューと呼ばれることがあります その内容は主にパフォーマンスに関連しています また これらのビューは データベース管理者が変更または削除できないので 固定ビュー固定ビューと呼ばれることもあります これらのビューの名前には V$ または GV$ という接頭辞が付き たとえば V$ARCHIVE_DEST や GV$ARCHIVE_DEST のようになります 標準の動的パフォーマンス ビュー (V$ 固定ビュー ) には ローカル インスタンスの情報が格納されます それに対して グローバル動的パフォーマンス ビュー (GV$ 固定ビュー ) には Real Application Clusters(RAC) のすべてのオープン インスタンスの情報が格納されます 各 V$ 固定ビューには対応する GV$ 固定ビューがあります GV$ 固定ビューを選択すると 全インスタンスの情報を取得するために パラレル問合せのスレーブが使用されます 追加情報は 第 16 章 Oracle Data Guard に関連するビュー および Oracle Database リファレンス を参照してください フィジカル スタンバイ データベースの管理 8-17

158 プライマリおよびスタンバイ データベースの監視 リカバリの進捗の監視 この項では 項で説明した Data Guard 環境でリカバリの進捗を監視するビューの例をいくつか示します この項は 次の例で構成されています プロセス アクティビティの監視 REDO Apply の進捗の確認 アーカイブ REDO ログ ファイルの位置および作成者の確認 OPEN RESETLOGS の前後のデータベース インカネーションの表示 アーカイブ REDO ログ履歴の表示 スタンバイ データベースに適用されたログ ファイルの確認 スタンバイ サイトが受信しなかったログ ファイルの確認 プロセス アクティビティの監視 次のプロセスを実行してアクティビティを監視することにより スタンバイ データベースでの REDO Apply に関する情報を取得できます 参照名 ARCH MRP RFS システム プロセス名 ARC0,ARC1,ARC2, MRP MRP0 ORACLE{SID} スタンバイ データベース サイトの V$MANAGED_STANDBY ビューには Data Guard 環境内で REDO 転送プロセスおよび REDO Apply プロセスの両方で実行されたアクティビティが表示されます 次の問合せ出力の CLIENT_P 列で 対応するプライマリ データベース プロセスを識別します SQL> SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY; PROCESS CLIENT_P SEQUENCE# STATUS ARCH ARCH 0 CONNECTED ARCH ARCH 0 CONNECTED MRP0 N/A 204 WAIT_FOR_LOG RFS LGWR 204 WRITING RFS N/A 0 RECEIVING REDO Apply の進捗の確認 プライマリまたはスタンバイ データベース サイトのいずれかの V$ARCHIVE_DEST_ STATUS ビューには アーカイブされたオンライン REDO ログ ファイル 適用されるアーカイブ REDO ログ ファイル それぞれのログ順序番号などの情報が表示されます 次の問合せ出力は スタンバイ データべースでは プライマリ データベースから受信した REDO データの適用がアーカイブ REDO ログ ファイル 2 つ分プライマリ データベースから遅れていることを示しています SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# 2> FROM V$ARCHIVE_DEST_STATUS; ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# Oracle Data Guard 概要および管理

159 プライマリおよびスタンバイ データベースの監視 アーカイブ REDO ログ ファイルの位置および作成者の確認 スタンバイ データベースで V$ARCHIVED_LOG ビューを問い合せて アーカイブ REDO ログに関する追加情報を検索できます このビューから アーカイブ REDO ログの位置 アーカイブ REDO ログを作成したプロセス 各アーカイブ REDO ログ ファイルの REDO ログ順序番号 各ログ ファイルがアーカイブされた時期 アーカイブ REDO ログ ファイルが適用されたかどうかなどの情報を取得できます 次に例を示します SQL> SELECT NAME, CREATOR, SEQUENCE#, APPLIED, COMPLETION_TIME 2> FROM V$ARCHIVED_LOG; NAME CREATOR SEQUENCE# APP COMPLETIO H: ORACLE ORADATA PAYROLL STANDBY ARC ARCH 198 YES 30-MAY-02 H: ORACLE ORADATA PAYROLL STANDBY ARC ARCH 199 YES 30-MAY-02 H: ORACLE ORADATA PAYROLL STANDBY ARC ARCH 200 YES 30-MAY-02 H: ORACLE ORADATA PAYROLL STANDBY ARC LGWR 201 YES 30-MAY-02 H: ORACLE ORADATA PAYROLL STANDBY ARC ARCH 202 YES 30-MAY-02 H: ORACLE ORADATA PAYROLL STANDBY ARC LGWR 203 YES 30-MAY-02 6 rows selected OPEN RESETLOGS の前後のデータベース インカネーションの表示 スタンバイ データベースで V$DATABASE_INCARNATION ビューを問い合せ データベース インカネーションと RESETLOGS_ID 列を監視します プライマリ データベースで OPEN RESETLOGS 文が発行される前に スタンバイ データベースで次の問合せが発行されたとします SQL> SELECT INCARNATION#, RESETLOGS_ID, STATUS FROM V$DATABASE_INCARNATION ; INCARNATION# RESETLOGS_ID STATUS PARENT CURRENT SQL> SELECT RESETLOGS_ID,THREAD#,SEQUENCE#,STATUS,ARCHIVED FROM V$ARCHIVED_LOG 2 ORDER BY RESETLOGS_ID,SEQUENCE# ; RESETLOGS_ID THREAD# SEQUENCE# S ARC A YES A YES A YES A YES A YES 5 rows selected. フィジカル スタンバイ データベースの管理 8-19

160 プライマリおよびスタンバイ データベースの監視 プライマリ データベースで OPEN RESETLOGS 文が発行され スタンバイ データベースが起動されて新規の REDO ブランチで REDO データを受信する前に スタンバイ データベースで次の問合せが発行されたとします SQL> SELECT INCARNATION#, RESETLOGS_ID, STATUS FROM V$DATABASE_INCARNATION ; INCARNATION# RESETLOGS_ID STATUS PARENT PARENT CURRENT SQL> SELECT RESETLOGS_ID,THREAD#,SEQUENCE#,STATUS,ARCHIVED FROM V$ARCHIVED_LOG 2 ORDER BY RESETLOGS_ID,SEQUENCE# ; RESETLOGS_ID THREAD# SEQUENCE# S ARC A YES A YES A YES A YES A YES A YES A YES A YES 8 rows selected アーカイブ REDO ログ履歴の表示 スタンバイ サイトの V$LOG_HISTORY ビューには 最初のエントリの時間 ログ内の最小の SCN ログ内の最大の SCN アーカイブ REDO ログ ファイルの順序番号など アーカイブ REDO ログの完全な履歴が表示されます SQL> SELECT FIRST_TIME, FIRST_CHANGE#, NEXT_CHANGE#, SEQUENCE# FROM V$LOG_HISTORY; FIRST_TIM FIRST_CHANGE# NEXT_CHANGE# SEQUENCE# MAY MAY MAY MAY MAY MAY rows selected スタンバイ データベースに適用されたログ ファイルの確認 スタンバイ データベースで V$LOG_HISTORY ビューを問い合せてください このビューには 適用された最新のログ順序番号が記録されています たとえば 次のような問合せを発行します SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG" 2> FROM V$LOG_HISTORY 3> GROUP BY THREAD#; THREAD# LAST_APPLIED_LOG この例では ログ順序番号 967 のアーカイブ REDO ログ ファイルが最新の適用済ログ ファイルです 8-20 Oracle Data Guard 概要および管理

161 プライマリおよびスタンバイ データベースの監視 また スタンバイ データベースで V$ARCHIVED_LOG 固定ビューの APPLIED 列を使用すると スタンバイ データベースに適用されたログ ファイルを識別できます 次に例を示します SQL> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG; THREAD# SEQUENCE# APP YES 1 3 YES 1 4 YES 1 5 YES 1 6 YES 1 7 YES 1 8 YES 1 9 YES 1 10 YES 1 11 NO 10 rows selected スタンバイ サイトが受信しなかったログ ファイルの確認 各アーカイブ先には 割り当てられた宛先 ID があります V$ARCHIVE_DEST 固定ビューの DEST_ID 列を問い合せると 宛先 ID を識別できます 次に プライマリ データベースでの問合せにこの宛先 ID を使用すると 特定のスタンバイ サイトに送信されなかったログ ファイルを識別できます たとえば プライマリ データベースのカレント ローカル アーカイブ先 ID が 1 で リモート スタンバイ データベースの 1 つの宛先 ID が 2 であるとします このスタンバイ宛先が受信しなかったログ ファイルを識別するには プライマリ データベースで次の問合せを発行します SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM 2> (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) LOCAL 3> WHERE LOCAL.SEQUENCE# NOT IN 5> (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND 6> THREAD# = LOCAL.THREAD#); THREAD# SEQUENCE# この例には スタンバイ宛先 2 が受信しなかったログ ファイルが示されています フィジカル スタンバイ データベースの管理 8-21

162 プライマリおよびスタンバイ データベースの監視 フィジカル スタンバイ データベースでのログ適用サービスの監視 フィジカル スタンバイ データベースのログ適用サービスの状況を監視するには この項で説明する固定ビューを問い合せます スタンバイ データベースは Oracle Enterprise Manager GUI を使用して監視することもできます この項は 次の項目で構成されています V$DATABASE ビューへのアクセス V$MANAGED_STANDBY 固定ビューへのアクセス V$ARCHIVE_DEST_STATUS 固定ビューへのアクセス V$ARCHIVED_LOG 固定ビューへのアクセス V$LOG_HISTORY 固定ビューへのアクセス V$DATAGUARD_STATUS 固定ビューへのアクセス また ビューの詳細は Oracle Database リファレンス を参照してください V$DATABASE ビューへのアクセス 次の問合せを発行すると 保護モード 保護レベル データベース ロールおよびスイッチオーバー ステータスに関する情報が表示されます SQL> SELECT DATABASE_ROLE, DB_UNIQUE_NAME INSTANCE, OPEN_MODE, - PROTECTION_MODE, PROTECTION_LEVEL, SWITCHOVER_STATUS - FROM V$DATABASE; 次の問合せを発行すると ファスト スタート フェイルオーバーに関する情報が表示されます SQL> SELECT FS_FAILOVER_STATUS FSFO_STATUS, FS_FAILOVER_CURRENT_TARGET - TARGET_STANDBY, FS_FAILOVER_THRESHOLD THRESHOLD, - FS_FAILOVER_OBSERVER_PRESENT OBS_PRES - FROM V$DATABASE; V$MANAGED_STANDBY 固定ビューへのアクセス スタンバイ サイトで REDO Apply および REDO 転送サービスのアクティビティを監視するには フィジカル スタンバイ データベースを問い合せます SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS 2> FROM V$MANAGED_STANDBY; PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS RFS ATTACHED MRP0 APPLYING_LOG この問合せ出力は RFS プロセスが REDO ログ ファイル順序番号 947 のアーカイブを完了したことを示しています また この出力は REDO Apply がアーカイブ REDO ログ ファイル順序番号 946 を適用していることも示しています このリカバリ操作では現在 72 ブロックのアーカイブ REDO ログ ファイルのブロック番号 10 をリカバリしている最中です 8-22 Oracle Data Guard 概要および管理

163 プライマリおよびスタンバイ データベースの監視 V$ARCHIVE_DEST_STATUS 固定ビューへのアクセス スタンバイ データベースの同期のレベルを迅速に判断するには フィジカル スタンバイ データベースで次の問合せを発行します SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# 2> FROM V$ARCHIVE_DEST_STATUS; ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# この問合せ出力は スタンバイ データベースが プライマリ データベースからアーカイブ REDO ログ ファイル 2 つ分遅れていることを示しています リアルタイム適用が使用可能になっているかどうかを判断するには V$ARCHIVE_DEST_ STATUS ビューの RECOVERY_MODE 列を問い合せます リアルタイム適用が使用可能になっている場合は 次の例に示すように 値 MANAGED REAL TIME APPLY が含まれます SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2 ; RECOVERY_MODE MANAGED REAL TIME APPLY V$ARCHIVED_LOG 固定ビューへのアクセス フィジカル スタンバイ データベース上の V$ARCHIVED_LOG 固定ビューには プライマリ データベースから受信したすべてのアーカイブ REDO ログ ファイルが表示されます このビューが役に立つのは スタンバイ サイトが REDO データの受信を開始した後のみです それ以前のビューは プライマリ制御ファイルから生成された旧アーカイブ REDO ログ レコードによって移入されたものです たとえば 次の SQL*Plus 文を実行できます SQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#, FIRST_CHANGE#, 2> NEXT_CHANGE# FROM V$ARCHIVED_LOG; REGISTRAR CREATOR THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# RFS ARCH RFS ARCH RFS ARCH この問合せ出力は プライマリ データベースから受信した 3 つのアーカイブ REDO ログ ファイルを示しています V$LOG_HISTORY 固定ビューへのアクセス フィジカル スタンバイ データベースで V$LOG_HISTORY 固定ビューを問い合せると 適用されたすべてのアーカイブ REDO ログ ファイルが表示されます SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# 2> FROM V$LOG_HISTORY; THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# この問合せ出力は 最も最近適用されたアーカイブ REDO ログ ファイルが順序番号 945 であったことを示しています フィジカル スタンバイ データベースの管理 8-23

164 プライマリおよびスタンバイ データベースの監視 V$DATAGUARD_STATUS 固定ビューへのアクセス V$DATAGUARD_STATUS 固定ビューには 通常はアラート ログまたはサーバー プロセスのトレース ファイルへのメッセージによってトリガーされるイベントが表示されます 次の例は プライマリ データベースでの V$DATAGUARD_STATUS ビューの出力を示します SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS; MESSAGE ARC0: Archival started ARC1: Archival started Archivelog destination LOG_ARCHIVE_DEST_2 validated for no-data-loss recovery Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2' ARCH: Transmitting activation ID 0 LGWR: Completed archiving log 3 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2' LGWR: Transmitting activation ID 6877c1fe LGWR: Beginning to archive log 4 thread 1 sequence 12 ARC0: Evaluating archive log 3 thread 1 sequence 11 ARC0: Archive destination LOG_ARCHIVE_DEST_2: Previously completed ARC0: Beginning to archive log 3 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/arch/arch_1_11.arc' ARC0: Completed archiving log 3 thread 1 sequence 11 ARC1: Transmitting activation ID 6877c1fe 15 rows selected. 次の例は フィジカル スタンバイ データベースでの V$DATAGUARD_STATUS ビューの内容を示します SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS; MESSAGE ARC0: Archival started ARC1: Archival started RFS: Successfully opened standby logfile 6: '/oracle/dbs/sorl2.log' ARC1: Evaluating archive log 6 thread 1 sequence 11 ARC1: Beginning to archive log 6 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/arch/arch_1_11.arc' ARC1: Completed archiving log 6 thread 1 sequence 11 RFS: Successfully opened standby logfile 5: '/oracle/dbs/sorl1.log' Attempt to start background Managed Standby Recovery process Media Recovery Log /oracle/arch/arch_1_9.arc 10 rows selected Oracle Data Guard 概要および管理

165 フィジカル スタンバイ データベースに関するログ適用レートのチューニング 8.6 フィジカル スタンバイ データベースに関するログ適用レートのチューニング 次の方法を使用して フィジカル スタンバイ データベースに対する REDO 適用の所要時間を最適化することを考慮してください 詳細は URL availability/htdocs/maa.htm にアクセスし Oracle Media Recovery Best Practices ホワイト ペーパーを参照してください 1 つのスタンバイ ホスト上でパラレル リカバリを CPU 数の 2 倍に設定メディア リカバリまたは REDO Apply の実行中に REDO ログ ファイルが読み取られ REDO の適用を必要とするデータ ブロックが解析されます パラレル メディア リカバリでは これらのデータ ブロックはバッファ キャッシュに読み取られるリカバリ プロセスすべてに均等に分散されます デフォルトはシリアル リカバリまたは並列度ゼロ (0) で これは同じリカバリ プロセスが REDO を読み取り ディスクからデータ ブロックを読み取って REDO 変更を適用することを意味します パラレル メディア リカバリまたは REDO Apply を実装するには リカバリ コマンドにオプションの PARALLEL 句を追加します さらに データベース パラメータ PARALLEL_MAX_ SERVERS を並列度以上の値に設定します 次の例に リカバリの並列度の設定方法を示します RECOVER STANDBY DATABASE PARALLEL #CPUs * 2; 複数のシリアル リカバリ処理とパラレル リカバリ処理を比較して 最適のリカバリ パフォーマンスを判断する必要があります REDO Apply レート向上のための DB_BLOCK_CHECKING=FALSE の設定スタンバイまたはメディア リカバリ中に DB_BLOCK_CHECKING=FALSE パラメータを設定すると 適用レートを 2 倍にすることができます リカバリ中にはブロックがチェックされませんが これはリスクとして受け入れる必要があります ブロック チェックはプライマリ データベースで有効にしてください DB_BLOCK_CHECKSUM=TRUE( デフォルト ) は 本番データベースとスタンバイ データベースの両方について有効にしてください DB_BLOCK_ CHECKING パラメータは動的であるため スタンバイ データベースを停止せずにトグルできます PARALLEL_EXECUTION_MESSAGE_SIZE = 4096 の設定パラレル メディア リカバリまたはパラレル スタンバイ リカバリを使用する場合は PARALLEL_EXECUTION_MESSAGE_SIZE データベース パラメータを 4K(4096) に増やすと パラレル リカバリを 20 パーセント改善できます このパラメータは スイッチオーバー操作の準備中にプライマリ データベースとスタンバイ データベースの両方で設定します このパラメータの設定値を大きくすると 各パラレル実行スレーブ プロセスに必要な共有プールからのメモリーが増えます PARALLEL_EXECUTION_MESSAGE_SIZE パラメータは パラレル問合せ操作でも使用されます いずれかのパラレル問合せ操作でテストして システムに十分なメモリーがあることを確認する必要があります 32 ビット インストールでは 多数のパラレル問合せのスレーブがメモリー制限に達し PARALLEL_EXECUTION_MESSAGE_SIZE をデフォルトの 2K(2048) から 4K に増やせない場合があります ディスク I/O のチューニングリカバリ中に発生する最大のボトルネックは 読取りおよび書込みの I/O です このボトルネックを軽減するには システム固有の非同期 I/O を使用し DISK_ASYNCH_IO データベース パラメータを TRUE( デフォルト ) に設定します DISK_ASYNCH_IO パラメータは データファイルへのディスク I/O が非同期かどうかを制御します 非同期 I/O を使用すると データベース ファイルのパラレル読取りが大幅に減少し リカバリ時間全体が短縮されます フィジカル スタンバイ データベースの管理 8-25

166 フィジカル スタンバイ データベースに関するログ適用レートのチューニング 8-26 Oracle Data Guard 概要および管理

167 9 ロジカル スタンバイ データベースの管理 この章は 次の項目で構成されています SQL Apply アーキテクチャの概要 ロジカル スタンバイ データベースの管理および監視関連のビュー ロジカル スタンバイ データベースの監視 ロジカル スタンバイ データベースのカスタマイズ ロジカル スタンバイ データベースのコンテキストにおける特定のワークロードの管理 ロジカル スタンバイ データベースのチューニング ロジカル スタンバイ データベースの管理 9-1

168 SQL Apply アーキテクチャの概要 9.1 SQL Apply アーキテクチャの概要 SQL Apply では パラレル実行サーバーとバックグラウンド プロセスの集合を使用して プライマリ データベースの変更がロジカル スタンバイ データベースに適用されます 図 9-1 に 情報の流れと各プロセスで実行されるロールを示します 図 9-1 SQL Apply の処理 ログのマイニングおよび適用処理中は 次のように 様々なプロセスとその機能が関係します ログのマイニング中には 次のプロセスが実行されます READER プロセスでは REDO レコードがアーカイブ REDO ログ ファイルから読み込まれます PREPARER プロセスでは REDO レコードに含まれるブロックの変更が論理変更レコード (LCR) に変換されます 特定のアーカイブ REDO ログ ファイルに対して複数の PREPARER プロセスをアクティブにすることができます LCR は LCR キャッシュと呼ばれるシステム グローバル領域 (SGA) の共有プール内でステージングされます BUILDER プロセスでは LCR がトランザクション単位にグループ化されて LCR キャッシュ内のメモリー管理 SQL Apply の再起動に関連するチェックポイント処理および重要でない変更のフィルタリングなど その他のタスクが実行されます 適用処理中には 次のプロセスが実行されます ANALYZER プロセスでは LCR グループを含むトランザクション チャンクが検査され 重要でないトランザクションがフィルタリングされ 様々なトランザクション間の依存性が識別されます COORDINATOR プロセス (LSP) では 次の操作が実行されます トランザクションの割当て トランザクション間の依存性の監視と スケジュールの調整 ロジカル スタンバイ データベースに対する変更のコミットの認可 9-2 Oracle Data Guard 概要および管理

169 SQL Apply アーキテクチャの概要 APPLIER プロセスでは 次の操作が実行されます データベースに対する LCR の適用 COORDINATOR プロセスに対する 依存性が解決されていないトランザクションの承認の要求 トランザクションのコミット V$LOGSTDBY_PROCESS ビューを問い合せると SQL Apply プロセスのアクティビティを検査できます 現行のアクティビティに関する情報は V$LOGSTDBY_STATS ビューでも提供されます このビューには SQL Apply アクティビティ中のロジカル スタンバイ データベースに関する統計 現在の状態およびステータス情報が表示されます この 2 つのビューと他の関連ビューの詳細は 9.2 項 ロジカル スタンバイ データベースの管理および監視関連のビュー を参照してください SQL Apply に関する各種の考慮事項 この項は 次の項目で構成されています トランザクション サイズの考慮事項 ページアウトの考慮事項 再開の考慮事項 DML 適用の考慮事項 DDL 適用の考慮事項 トランザクション サイズの考慮事項 SQL Apply では トランザクションが大小 2 つのクラスに分類されます 小さいトランザクション : SQL Apply は REDO ログ ファイル内で小さいトランザクションのコミット レコードを検出すると そのトランザクションに属する LCR の適用を開始します 大きいトランザクション : SQL Apply は 大きいトランザクションをトランザクション チャンクと呼ばれる小さい単位に分割し そのトランザクションのコミット レコードを REDO ログ ファイル内で検出する前に チャンクの適用を開始します この処理が実行されるのは LCR キャッシュのメモリー使用量を削減し フェイルオーバー時間全体を短縮するためです たとえば 小さく分割しない場合 SQL*Loader のロードが 1000 万行で サイズがそれぞれ 100 バイトであれば LCR キャッシュでは 1GB を超えるメモリーが使用されます LCR キャッシュに割り当てられているメモリーが 1GB 未満の場合は LCR キャッシュからのページアウトが発生します メモリーの考慮事項とは別に SQL Apply がトランザクションの COMMIT レコードを検出するまでに 1000 万行の SQL*Loader ロードに関連する変更の適用を開始しない場合 フェイルオーバーが停止します SQL Apply がロジカル スタンバイ データベース上でトランザクションを適用し終わるまで そのトランザクションのコミット後に開始されたフェイルオーバーは終了できません すべてのトランザクションは 最初は小さいトランザクションとして分類されます SQL Apply では トランザクションが大きいトランザクションとして再分類されるタイミングは LCR キャッシュに使用可能なメモリー量と トランザクションに属する LCR のメモリー使用量に応じて決定します ロジカル スタンバイ データベースの管理 9-3

170 SQL Apply アーキテクチャの概要 ページアウトの考慮事項 LCR キャッシュのメモリーがすべて使用され SQL Apply を進捗させるために領域の解放が必要になると SQL Apply のコンテキスト内でページアウトが発生します たとえば LCR キャッシュに 100MB のメモリーが割り当てられている場合に SQL Apply でサイズが 300MB の LONG 列を含む表に対する INSERT トランザクションが検出されるとします この場合 ログ マイニング コンポーネントは LONG データの最初の部分をページアウトして列変更の後半部分を読み取ります 適切にチューニングされているロジカル スタンバイ データベースの場合 ページアウト アクティビティはほとんど発生せず システム全体のスループットには影響しません 関連項目 : 問題のあるページアウトを識別して対処措置を実行する方法の詳細は 9.4 項 ロジカル スタンバイ データベースのカスタマイズ を参照してください 再開の考慮事項 トランザクションのコミット レコードが REDO ログ ファイルからマイニングされてロジカル スタンバイ データベースに適用されるまで ロジカル スタンバイ データベースに対する変更は永続的な変更になりません つまり ユーザー指示の結果であるかシステム障害の結果であるかに関係なく SQL Apply は停止されるたびに コミットされていない最も古いトランザクションまで遡って再びマイニングする必要があります トランザクションの処理量が小さくても長時間オープン状態になっている場合は SQL Apply を再開すると非常に高コストになります これは SQL Apply ではコミットされていない少数のトランザクションの REDO データを読み取るのみでなく 多数のアーカイブ REDO ログ ファイルを再びマイニングする操作が必要になる場合があるためです これを軽減するために SQL Apply はコミットされていない古いデータのチェックポイントを定期的に実行します チェックポイントが実行される SCN は V$LOGSTDBY_PROGRESS ビューの RESTART_SCN 列に反映されます 再開時には SQL Apply は RESTART_SCN 列に表示される値より大きい SCN で生成される REDO レコードのマイニングを開始します 再開に不要なアーカイブ REDO ログ ファイルは SQL Apply により自動的に削除されます 多数の DDL トランザクション パラレル DML 文 (PDML) およびダイレクト パス ロードなど ある種のワークロードがあると RESTART_SCN はワークロードの存続期間中は進行しなくなります DML 適用の考慮事項 SQL Apply がロジカル スタンバイ データベースのスループットと待機時間に影響する DML トランザクションを適用する場合 次の特性があります 1 つの文で複数の行が変更されるバッチ更新または削除をプライマリ データベースで実行した場合 ロジカル スタンバイ データベースでは行の個別変更として適用されます そのため 保守されている各表に一意キーまたは主キーが必要になります 詳細は 項 プライマリ データベース内の表の行が一意に識別できることの確認 を参照してください プライマリ データベースで実行されたダイレクト パス インサートは ロジカル スタンバイ データベースで従来型の INSERT 文を使用して適用されます パラレル DML(PDML) トランザクションは ロジカル スタンバイ データベースではパラレルに実行されません 9-4 Oracle Data Guard 概要および管理

171 ロジカル スタンバイ データベースの管理および監視関連のビュー DDL 適用の考慮事項 SQL Apply がロジカル スタンバイ データベースのスループットと待機時間に影響する DDL トランザクションを適用する場合 次の特性があります パラレル DDL(PDDL) トランザクションは ロジカル スタンバイ データベースではパラレルに実行されません DDL トランザクションは ロジカル スタンバイ データベースではシリアルに適用されます そのため プライマリ データベースで同時に適用された DDL トランザクションは ロジカル スタンバイ データベースでは 1 度に 1 つずつ適用されます ロジカル スタンバイ データベース上で DML アクティビティ (CREATE TABLE AS SELECT(CTAS) 文の一部 ) が抑制されるように CTAS 文が実行されます CTAS 文の一部として新規作成された表に挿入された行は REDO ログ ファイルからマイニングされ 別の INSERT 文を使用してロジカル スタンバイ データベースに適用されます 9.2 ロジカル スタンバイ データベースの管理および監視関連のビュー 次のパフォーマンス ビューでは ロジカル スタンバイ データベースを保守する SQL Apply の動作が監視されます 次の各項では ロジカル スタンバイ データベースの監視に使用できる主なビューについて説明します DBA_LOGSTDBY_EVENTS ビュー DBA_LOGSTDBY_LOG ビュー V$LOGSTDBY_STATS ビュー V$LOGSTDBY_PROCESS ビュー V$LOGSTDBY_PROGRESS ビュー V$LOGSTDBY_STATE ビュー V$LOGSTDBY_STATS ビュー DBA_LOGSTDBY_EVENTS ビュー DBA_LOGSTDBY_EVENTS ビューには SQL Apply 操作中に発生した重要なイベントが記録されます デフォルトでは 最新の 100 のイベントが記録されます ただし 記録されるイベントの数は PL/SQL プロシージャ DBMS_LOGSTDBY.APPLY_SET() をコールして変更できます SQL Apply が突然停止した場合は このビューにその原因も記録されます 注意 : SQL Apply を停止させるエラーは イベント表に記録されます この種のイベントは ALERT.LOG ファイルにも記録され テキストに LOGSTDBY キーワードが挿入されます このビューを問い合せたときは EVENT_TIME_STAMP COMMIT_SCN CURRENT_SCN の順で列を選択してください この順序によって 停止障害がビューの最後に表示されます ロジカル スタンバイ データベースの管理 9-5

172 ロジカル スタンバイ データベースの管理および監視関連のビュー このビューには 適用された DDL 文やスキップされた DDL トランザクションなどの他の情報も表示されます 次に例を示します SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS'; Session altered. SQL> COLUMN STATUS FORMAT A60 SQL> SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS 2 ORDER BY EVENT_TIMESTAMP, COMMIT_SCN; EVENT_TIME STATUS EVENT JUL-02 18:20:12 ORA-16111: ログのマイニングと設定の適用 23-JUL-02 18:25:12 ORA-16128: ユーザーが開始した停止は 正常に完了しました 23-JUL-02 18:27:12 ORA-16112: ログのマイニングと停止の適用 23-JUL-02 18:55:12 ORA-16128: ユーザーが開始した停止は 正常に完了しました 23-JUL-02 18:57:09 ORA-16111: ログのマイニングと設定の適用 23-JUL-02 20:21:47 ORA-16204: DDL は正常に適用されました create table hr.test_emp (empno number, ename varchar2(64)) 23-JUL-02 20:22:55 ORA-16205: DDL はスキップ設定のためスキップされました create database link link_to_boston connect to system identified by change_on_inst 7 rows selected. この問合せは SQL Apply の開始と停止が数回繰り返されたことを示しています 適用された DDL とスキップされた DDL も示しています SQL Apply が停止した場合は 問合せの最後のレコードに問題の原因が表示されます DBA_LOGSTDBY_LOG ビュー DBA_LOGSTDBY_LOG ビューには SQL Apply で処理中のアーカイブ ログに関する動的な情報が表示されます 次に例を示します SQL> COLUMN DICT_BEGIN FORMAT A10; SQL> SET NUMF SQL> SELECT FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS FCHANGE#, - NEXT_CHANGE# AS NCHANGE#, TIMESTAMP, - DICT_BEGIN AS BEG, DICT_END AS END, - THREAD# AS THR# FROM DBA_LOGSTDBY_LOG - ORDER BY SEQUENCE#; FILE_NAME SEQ# F_SCN N_SCN TIMESTAM BEG END THR# APPLIED /oracle/dbs/hq_nyc_2.log :02:58 NO NO 1 YES /oracle/dbs/hq_nyc_3.log :02:02 NO NO 1 YES /oracle/dbs/hq_nyc_4.log :02:10 NO NO 1 YES /oracle/dbs/hq_nyc_5.log :02:48 YES YES 1 YES /oracle/dbs/hq_nyc_6.log :02:10 NO NO 1 YES /oracle/dbs/hq_nyc_7.log :02:11 NO NO 1 YES /oracle/dbs/hq_nyc_8.log :02:01 NO NO 1 YES /oracle/dbs/hq_nyc_9.log :02:16 NO NO 1 YES /oracle/dbs/hq_nyc_10.log :02:21 NO NO 1 YES /oracle/dbs/hq_nyc_11.log :02:26 NO NO 1 CURRENT /oracle/dbs/hq_nyc_12.log :02:30 NO NO 1 CURRENT /oracle/dbs/hq_nyc_13.log :02:41 NO NO 1 NO この問合せ出力は LogMiner ディクショナリの作成がログ ファイルの順序番号 5 で開始したことを示しています 最新のアーカイブ REDO ログ ファイルは順序番号 13 で ロジカル スタンバイ データベースでは 1 時 2 分 41 秒に受信されています APPLIED 列は SQL Apply により SCN までの REDO がすべて適用されたことを示しています トランザクションでは複数のアーカイブ ログ ファイルを使用している場合があるため 複数のアーカイブ ログ ファイルの APPLIED 列に値 CURRENT が表示されることがあります 9-6 Oracle Data Guard 概要および管理

173 ロジカル スタンバイ データベースの管理および監視関連のビュー V$LOGSTDBY_STATS ビュー このビューには ロジカル スタンバイ データベースのフェイルオーバー特性に関連する次のような情報が表示されます フェイルオーバー時間 (apply finish time) ロジカル スタンバイ データベース内のコミット済データの最新性 (lag time) 障害時の潜在的なデータ消失 (potential data loss) 次に例を示します SQL> SELECT NAME, VALUE, TIME_COMPUTED FROM V$LOGSTDBY_STATS; NAME VALUE TIME_COMPUTED apply finish time :00: APR :29:23 lag time :00: APR :29:23 potential data loss :00:00 07-APR :29:23 表示される各列の単位 ( メトリック ) は 日 (2) から秒 (1) までの間隔です この出力は ロジカル スタンバイ データベースがプライマリ データベースと 0.1 秒以内に一致することと プライマリ データベースに障害が発生した場合もデータ消失が発生しないことを示しています V$LOGSTDBY_PROCESS ビュー 関連項目 : Oracle Database リファレンス の V$LOGSTDBY_STATS ビューに関する項 このビューには 次のように SQL Apply 関連の各種プロセスの現在の状態に関する情報が表示されます 識別情報 (sid serial# spid) SQL Apply プロセス : COORDINATOR READER BUILDER PREPARER ANALYZER または APPLIER(type) プロセスの現行のアクティビティのステータス (status_code status) このプロセスで処理された最上位の REDO レコード (high_scn) 次に例を示します SQL> COLUMN LID FORMAT 9999 SQL> COLUMN SERIAL# FORMAT 9999 SQL> COLUMN SID FORMAT 9999 SQL> SELECT SID, SERIAL#, LOGSTDBY_ID AS LID, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_ PROCESS; SID SERIAL# LID SPID TYPE HIGH_SCN COORDINATOR READER BUILDER PREPARER ANALYZER APPLIER APPLIER APPLIER APPLIER rows selected. HIGH_SCN 列は READER プロセスが他のすべてのプロセスに先行することと PREPARER および BUILDER プロセスが残りのプロセスに先行することを示しています ロジカル スタンバイ データベースの管理 9-7

174 ロジカル スタンバイ データベースの管理および監視関連のビュー SQL> COLUMN STATUS FORMAT A40 SQL> SELECT TYPE, STATUS_CODE, STATUS FROM V$LOGSTDBY_PROCESS; TYPE STATUS_CODE STATUS COORDINATOR ORA-16117: 処理中です READER ORA-16127: 追加のトランザクションが適用されるまで 待機して停止しました BUILDER ORA-16116: 使用できる作業はありません PREPARER ORA-16117: 処理中です ANALYZER ORA-16120: SCN 0x0001.abdb440a での トランザクションに対する依存性を計算中です APPLIER ORA-16124: トランザクション は待機中です APPLIER ORA-16121: コミット SCN 0x0001.abdb4390 に トランザクションを適用しています APPLIER ORA-16123: トランザクション は コミットの認証を待機中です APPLIER ORA-16116: 使用できる作業はありません 出力は 実行中の SQL Apply のスナップショットを示しています マイニング側では READER プロセスはさらに読み取れるように追加のメモリーが使用可能になるまで待機中で PREPARER プロセスは REDO レコードの処理中 BUILDER プロセスに使用可能な処理はありません 適用側では COORDINATOR は APPLIER プロセスにさらにトランザクションを割当中で ANALYZER は SCN で依存性を計算中 APPLIER の 1 つは使用可能な処理がなく 2 つにはまだ満たされていない未処理の依存性があります 関連項目 : リファレンス情報については Oracle Database リファレンス の V$LOGSTDBY_PROCESS ビューに関する項 出力例については 項 SQL Apply の進捗の監視 を参照してください V$LOGSTDBY_PROGRESS ビュー このビューには 次のように SQL Apply の進捗に関する詳細情報が表示されます プライマリ データベース上でコミットされた全トランザクションがロジカル スタンバイ データベースに適用された SCN または時刻 (applied_scn applied_time) 再開時に SQL Apply による REDO レコードの読取りが開始される SCN または時刻 (restart_scn restart_time) ロジカル スタンバイ データベースで受信された最新 REDO レコードの SCN または時刻 (latest_scn latest_time) BUILDER プロセスにより処理された最新レコードの SCN または時刻 (mining_scn mining_time) 次に例を示します SQL> SELECT APPLIED_SCN, LATEST_SCN, MINING_SCN, RESTART_SCN FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN LATEST_SCN MINING_SCN RESTART_SCN この出力は次のことを示しています SQL Apply により SCN 以前にコミットされた全トランザクションが適用されました ロジカル スタンバイ データベースで受信された最新 REDO レコードは SCN で生成されました マイニング コンポーネントにより SCN 以前に生成された全 REDO レコードが処理されました 9-8 Oracle Data Guard 概要および管理

175 ロジカル スタンバイ データベースの管理および監視関連のビュー SQL Apply がなんらかの理由で停止されて再開されると SCN 以降に生成された REDO レコードのマイニングが開始されます SQL> ALTER SESSION SET NLS_DATE_FORMAT='yy-mm-dd hh24:mi:ss'; Session altered SQL> SELECT APPLIED_TIME, LATEST_TIME, MINING_TIME, RESTART_TIME FROM V$LOGSTDBY_ PROGRESS; APPLIED_TIME LATEST_TIME MINING_TIME RESTART_TIME :38: :41: :41: :09:30 この出力は次のことを示しています SQL Apply により 時刻 :38:21 以前にコミットされた全トランザクションが適用されました (APPLIED_TIME) 最後の REDO は プライマリ データベースで時刻 :41:53 に生成されました (LATEST_TIME) マイニング エンジンにより :41:21 以前に生成された全 REDO レコードが処理されました (MINING_TIME) SQL Apply の再開時には :09:30 以後に生成された REDO レコードのマイニングが開始されます V$LOGSTDBY_STATE ビュー 関連項目 : リファレンス情報については Oracle Database リファレンス の V$DATAGUARD_PROGRESS ビューに関する項 出力例については 項 SQL Apply の進捗の監視 を参照してください このビューには 次のように SQL Apply の現在の状態の概要が表示されます プライマリ データベースの DBID(primary_dbid) SQL Apply に割り当てられている LogMiner セッション ID(session_id) SQL Apply がリアルタイムで適用中かどうか (realtime_apply) SQL Apply が LogMiner マルチバージョン データ ディクショナリのロード プライマリ データベースからの REDO の受信および REDO データの適用のうち どの状態にあるか (state) 次に例を示します SQL> COLUMN REALTIME_APPLY FORMAT a15 SQL> COLUMN STATE FORMAT a16 SQL> SELECT * FROM V$LOGSTDBY_STATE; PRIMARY_DBID SESSION_ID REALTIME_APPLY STATE Y APPLYING この出力は SQL Apply がリアルタイム適用モードで実行中で 現在はプライマリ データベースから受信した REDO データを適用中であり プライマリ データベースの DBID が で SQL Apply セッションに関連付けられている LogMiner セッション ID が 1 であることを示しています 関連項目 : リファレンス情報については Oracle Database リファレンス の V$LOGSTDBY_STATE ビューに関する項 出力例については 項 SQL Apply の進捗の監視 を参照してください ロジカル スタンバイ データベースの管理 9-9

176 ロジカル スタンバイ データベースの管理および監視関連のビュー V$LOGSTDBY_STATS ビュー このビューには SQL Apply 統計が表示されます 次に例を示します SQL> COLUMN NAME FORMAT a32 SQL> COLUMN VALUE FORMAT a32 SQL> SELECT * FROM V$LOGSTDBY_STATS; NAME VALUE number of preparers 1 number of appliers 4 maximum SGA for LCR cache 30 parallel servers in use 8 maximum events recorded 1000 preserve commit order TRUE record skip errors Y record skip DDL Y record applied DDL N record unsupported operations N coordinator state APPLYING transactions ready transactions applied coordinator uptime realtime logmining Y apply delay 0 Log Miner session ID 1 bytes of redo processed txns delivered to client DML txns delivered 128 DDL txns delivered 23 CTAS txns delivered 0 Recursive txns delivered 874 Rolled back txns seen 40 LCRs delivered to client bytes paged out 0 secs spent in pageout 0 bytes checkpointed 0 secs spent in checkpoint 0 bytes rolled back 0 secs spent in rollback 0 secs system is idle rows selected. 関連項目 : Oracle Database リファレンス の V$LOGSTDBY_STATS ビューに関する項 9-10 Oracle Data Guard 概要および管理

177 ロジカル スタンバイ データベースの監視 9.3 ロジカル スタンバイ データベースの監視 この項は 次の項目で構成されています SQL Apply の進捗の監視 ログ ファイルの自動削除 SQL Apply の進捗の監視 SQL Apply には 5 つの進捗状況があります SQL Apply の初期化 LogMiner マルチバージョン データ ディクショナリのロード 適用 (REDO データ ) アーカイブ ギャップの解決の待機およびアイドルの 5 つです 図 9-2 に これらの状態の流れを示します 図 9-2 SQL Apply 処理中の進捗状態 次の各項では それぞれの状態を詳細に説明します 初期化中状態 ALTER DATABASE START LOGICAL STANDBY APPLY 文を発行して SQL Apply を開始すると 初期化中状態になります SQL Apply の現在の状態を判断するには V$LOGSTDBY_STATE ビューを問い合せます 次に例を示します SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE; SESSION_ID STATE INITIALIZING SESSION_ID 列は SQL Apply により作成された永続 LogMiner セッションを示します このセッションで プライマリ データベースで生成されたアーカイブ REDO ログ ファイルがマイニングされます ディクショナリ ログ待機中 SQL Apply は 初回の開始時に REDO ログ ファイルで取得された LogMiner マルチバージョン データ ディクショナリをロードする必要があります SQL Apply は LogMiner マルチバージョン データ ディクショナリのロードに必要な REDO データをすべて受信するまで WAITING FOR DICTIONARY LOGS 状態にとどまります ロジカル スタンバイ データベースの管理 9-11

178 ロジカル スタンバイ データベースの監視 ディクショナリ ロード中状態ディクショナリ ロード中状態は しばらく継続する場合があります 大型データベースで LogMiner マルチバージョン データ ディクショナリをロードするには 長時間かかることがあります V$LOGSTDBY_STATE ビューを問い合せると ディクショナリのロード中は次の出力が戻されます SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE; SESSION_ID STATE LOADING DICTIONARY LogMiner ディクショナリが完全にロードされるまでに起動されるのは COORDINATOR プロセスとマイニング プロセスのみです したがって この時点で V$LOGSTDBY_PROCESS を問い合せると APPLIER プロセスは表示されません 次に例を示します SQL> SELECT SID, SERIAL#, SPID, TYPE FROM V$LOGSTDBY_PROCESS; SID SERIAL# SPID TYPE COORDINATOR READER BUILDER PREPARER PREPARER V$LOGMNR_DICTIONARY_LOAD ビューを問い合せると ディクショナリ ロードの進捗に関する詳細情報を取得できます ディクショナリ ロードは 次の 3 つのフェーズで発生します 1. LogMiner マルチバージョン データ ディクショナリのロードに関連する REDO 変更を収集するために 関連アーカイブ REDO ログ ファイルがマイニングされます 2. 変更が処理され データベース内のステージング表にロードされます 3. 一連の DDL 文が発行されて LogMiner マルチバージョン データ ディクショナリ表がロードされます 次に例を示します SQL> SELECT PERCENT_DONE, COMMAND FROM V$LOGMNR_DICTIONARY_LOAD WHERE SESSION_ID = (SELECT SESSION_ID FROM V$LOGSTDBY_STATE); PERCENT_DONE COMMAND alter table SYSTEM.LOGMNR_CCOL$ exchange partition P101 with table SYS.LOGMNRLT_101_CCOL$ excluding indexes without validation PERCENT_DONE または COMMAND 列が長時間変化しない場合は V$SESSION_LONGOPS ビューを問い合せ 問題の DDL トランザクションの進捗を監視してください 9-12 Oracle Data Guard 概要および管理

179 ロジカル スタンバイ データベースの監視 適用中状態この状態では SQL Apply は LogMiner マルチバージョン データ ディクショナリの初期スナップショットを正常にロードしており 現在はロジカル スタンバイ データベースに REDO データを適用中です SQL Apply の進捗の詳細情報を確認するには 次のように V$LOGSTDBY_PROGRESS ビューを問い合せます SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS'; SQL> SELECT APPLIED_TIME, APPLIED_SCN, MINING_TIME, MINING_SCN, FROM V$LOGSTDBY_PROGRESS; APPLIED_TIME APPLIED_SCN MINING_TIME MINING_SCN JAN :00: JAN :10: プライマリ データベース上で APPLIED_SCN( または APPLIED_TIME) 以前に表示されるコミット済トランザクションは すべてロジカル スタンバイ データベースに適用されています マイニング エンジンは プライマリ データベースで MINING_SCN( および MINING_ TIME) 以前に生成された REDO レコードの処理をすべて完了しています 安定状態では MINING_SCN( および MINING_TIME) は常に APPLIED_SCN( および APPLIED_TIME) よりも前の値を示します ギャップ待機中状態この状態が発生するのは SQL Apply が使用可能な全 REDO レコードのマイニングと適用を完了し RFS プロセスによる新規ログ ファイル ( または欠落しているログ ファイル ) のアーカイブを待機している場合です SQL> SELECT STATUS FROM V$LOGSTBDY_PROCESS WHERE TYPE = 'READER'; STATUS ORA:01291 ログ ファイルを待機しています ( スレッド # %s 順序番号 # %s) アイドル状態 SQL Apply は プライマリ データベースで生成された REDO をすべて適用し終わると この状態になります ロジカル スタンバイ データベースの管理 9-13

180 ロジカル スタンバイ データベースの監視 ログ ファイルの自動削除 SQL Apply では 不要になったアーカイブ REDO ログ ファイルが自動的に削除されます 次の PL/SQL プロシージャを実行すると この動作をオーバーライドできます SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', FALSE); 注意 : デフォルトでは 不要になったアーカイブ REDO ログ ファイルは SQL Apply により削除されます ロジカル スタンバイ データベースをフラッシュバックすると アーカイブ REDO ログ ファイルが SQL Apply メタデータには存在しますが (DBA_LOGSTDBY_LOGS ビューに反映 ) ファイル システムには存在しない状態になる場合があります フラッシュバック データベース操作後に SQL Apply を再開すると 失敗してアラート ログに次のエラーが記録される場合があります Errors in file /home/oracle/dgr2/logical/stdl/bdump/stdl_lsp0_ trc: ORA-00308: アーカイブ ログ '/home/oracle/dgr2/logical/stdl/stlog/1_15_ dbf' をオープンできません ORA-27037: ファイル ステータスを取得できません 自動削除ポリシーにより削除されたアーカイブ REDO ログ ファイルを適切なディレクトリにコピーし SQL Apply を再開する必要があります ロジカル スタンバイ データベースでアーカイブ REDO ログ ファイルが不要になると SQL Apply により自動的に削除されますが SQL Apply で不要になったアーカイブ REDO ログ ファイルの削除が ( ディスク領域の解放などのために ) 必要になる場合があります デフォルトの自動ログ削除機能をオーバーライドする場合は 次の手順に従って SQL Apply で不要になったアーカイブ REDO ログ ファイルを識別し 削除します 1. 不要になったメタデータのロジカル スタンバイ セッションを消去するには 次の PL/SQL 文を入力します SQL> EXECUTE DBMS_LOGSTDBY.PURGE_SESSION; この文では 不要になったアーカイブ REDO ログ ファイルを表示する DBA_LOGMNR_ PURGED_LOG ビューも更新されます 2. DBA_LOGMNR_PURGED_LOG ビューを問い合せて 削除できるアーカイブ REDO ログ ファイルのリストを表示します SQL> SELECT * FROM DBA_LOGMNR_PURGED_LOG; FILE_NAME /boston/arc_dest/arc_1_40_ log /boston/arc_dest/arc_1_41_ log /boston/arc_dest/arc_1_42_ log /boston/arc_dest/arc_1_43_ log /boston/arc_dest/arc_1_44_ log /boston/arc_dest/arc_1_45_ log /boston/arc_dest/arc_1_46_ log /boston/arc_dest/arc_1_47_ log 3. オペレーティング システム固有のコマンドを使用して 問合せにより表示されたアーカイブ REDO ログ ファイルを削除します 9-14 Oracle Data Guard 概要および管理

181 ロジカル スタンバイ データベースのカスタマイズ 9.4 ロジカル スタンバイ データベースのカスタマイズ この項は 次の項目で構成されています ロジカル スタンバイ データベースでのリアルタイム適用の使用 DBA_LOGSTDBY_EVENTS ビューでのイベントのロギングのカスタマイズ DBMS_LOGSTDBY.SKIP による特定のスキーマ オブジェクトに対する変更の防止 DDL 文のスキップ ハンドラの設定 ロジカル スタンバイ データベースの変更 ロジカル スタンバイ データベースでの表の追加または再作成 関連項目 : Oracle Database PL/SQL パッケージ プロシージャおよびタイプ リファレンス の DBMS_LOGSTDBY パッケージに関する項 ロジカル スタンバイ データベースでのリアルタイム適用の使用 デフォルトでは Data Guard はいっぱいになったアーカイブ REDO ログ ファイルがスタンバイ データベースで受信されるのを待機してから スタンバイ データベースに適用します ただし スタンバイ REDO ログをスタンバイ データベースで構成している場合 オプションでリアルタイム適用を使用可能にできます リアルタイム適用を使用可能にすると SQL Apply では ログ ファイルが書き込まれるのと同時にスタンバイ REDO ログ ファイルから REDO データが適用されます これは ログ スイッチが発生する場合とは逆になります このような方法でスタンバイ REDO ログ ファイルを即時に適用することにより スタンバイ REDO ログ ファイルをスタンバイ サイトでアーカイブする必要なしに ロジカル スタンバイ データベースの内容をプライマリ データベースの内容とかぎりなく一致させることができます この結果 スイッチオーバーとフェイルオーバーをより迅速に実行できます ロジカル スタンバイ データベースでリアルタイム適用を開始するには 次の文を発行します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; SQL Apply をリアルタイム適用モードで実行することをお薦めします スタンバイ REDO ログの構成の詳細は 項 スタンバイ REDO ログの構成 も参照してください DBA_LOGSTDBY_EVENTS ビューでのイベントのロギングのカスタマイズ DBA_LOGSTDBY_EVENTS ビューは SQL Apply のコンテキストで発生する重要な最新イベントを含む循環型ログとみなすことができます デフォルトでは 最新の 100 のイベントがイベント ビューに記録されます ログに記録されるイベント数は DBMS_LOGSTDBY.APPLY_SET プロシージャを起動して変更できます たとえば 最新の 10,000 のイベントを確実に記録するには 次の文を発行できます SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('MAX_EVENTS_RECORDED', '10000'); また ビューに記録されるイベントのタイプを指定できます たとえば 適用済 DDL トランザクションを DBA_LOGSTDBY_EVENTS ビューに記録するには 次の文を発行します SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('RECORD_APPLIED_DDL', 'TRUE'); SQL Apply の停止原因となったエラーは システム表領域に十分な領域があるかぎり 必ずイベント ビューに記録されます これらのイベントは常に ALERT.LOG ファイルにも格納され テキストには LOGSTDBY というキーワードが含まれます このビューを問い合せたときは EVENT_TIME COMMIT_SCN CURRENT_SCN の順で列を選択してください この順序によって 停止障害がビューの最後に表示されます ロジカル スタンバイ データベースの管理 9-15

182 ロジカル スタンバイ データベースのカスタマイズ DBMS_LOGSTDBY.SKIP による特定のスキーマ オブジェクトに対する変更の防止 デフォルトでは プライマリ データベース内でサポートされる表は すべてロジカル スタンバイ データベースで複製されます このデフォルト動作は 特定の表に対する変更の適用をスキップするルールを指定することで変更できます たとえば HR.EMPLOYEES 表に対する変更を省略するには 特定の表に対する DML 変更と DDL 変更の適用を防止するルールを指定できます 次に例を示します 1. SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 2. SKIP ルールを登録します SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'DML', schema_name => 'HR', - object_name => 'EMPLOYEES', proc_name => null); SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'SCHEMA_DDL', schema_name => 'HR', - object_name => 'EMPLOYEES', proc_name => null); 3. SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; DDL 文のスキップ ハンドラの設定 特定の DDL 文をインターセプトして元の DDL 文を別の DDL 文で置き換えるプロシージャを作成できます たとえば ロジカル スタンバイ データベース内のファイル システムの編成がプライマリ データベースとは異なる場合 DBMS_LOGSTDBY.SKIP プロシージャを作成し ファイルを指定して DDL トランザクションを透過的に処理できます 次のプロシージャでは ファイル指定文字列に特定のネーミング規則を使用するかぎり プライマリ データベースとスタンバイ データベース間で異なるファイル システム編成を処理できます 1. 次のように 表領域の DDL トランザクションを処理するスキップ プロシージャを作成します CREATE OR REPLACE PROCEDURE SYS.HANDLE_TBS_DDL ( OLD_STMT IN VARCHAR2, STMT_TYP IN VARCHAR2, SCHEMA IN VARCHAR2, NAME IN VARCHAR2, XIDUSN IN NUMBER, XIDSLT IN NUMBER, XIDSQN IN NUMBER, ACTION OUT NUMBER, NEW_STMT OUT VARCHAR2 ) AS BEGIN -- All primary file specification that contains a directory -- /usr/orcl/primary/dbs -- should go to /usr/orcl/stdby directory specification NEW_STMT = REPLACE(OLD_STMT, '/usr/orcl/primary/dbs', '/usr/orcl/stdby'); ACTION := DBMS_LOGSTDBY.SKIP_ACTION_REPLACE; 9-16 Oracle Data Guard 概要および管理

183 ロジカル スタンバイ データベースのカスタマイズ EXCEPTION WHEN OTHERS THEN ACTION := DBMS_LOGSTDBY.SKIP_ACTION_ERROR; NEW_STMT := NULL; END HANDLE_TBS_DDL; 2. SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 3. スキップ プロシージャを SQL Apply に登録します SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'TABLESPACE', - proc_name => 'sys.handle_tbs_ddl'); 4. SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; ロジカル スタンバイ データベースの変更 デフォルトでは ロジカル スタンバイ データベースはデータベース ガードが ALL( 最も限定的な設定 ) に設定されている状態で作動し ユーザーはデータベースに対して変更を実行できません データベース ガードを無視して ロジカル スタンバイ データベースを変更可能にするには ALTER SESSION DISABLE GUARD 文を実行します 権限を付与されているユーザーは この文を発行して 現行のセッションでデータベース ガードをオフにできます 次の各項で 例を示します これらの例では データベース ガードが ALL または STANDBY に設定されていると仮定しています ロジカル スタンバイ データベースでの DDL の実行 この項では SQL Apply を介してメンテナンスされている表に制約を追加する方法を説明します デフォルトでは SYS 権限を持つアカウントのみがデータベースを変更でき データベース ガードは ALL または STANDBY に設定されています SYSTEM または権限を付与されている別のアカウントでログインした場合 最初はセッションに対するデータベース ガードをバイパスしていないので ロジカル スタンバイ データベースでは DDL 文を発行できません 次の例は SQL Apply を停止し データベース ガードをバイパスしてロジカル スタンバイ データベースで SQL 文を実行した後 データベース ガードを再び使用可能にする方法を示しています SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered. SQL> ALTER SESSION DISABLE GUARD; PL/SQL procedure successfully completed. SQL> ALTER TABLE SCOTT.EMP ADD CONSTRAINT EMPID UNIQUE (EMPNO); Table altered. SQL> ALTER SESSION ENABLE GUARD; PL/SQL procedure successfully completed. SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; Database altered. オラクル社では データベース ガードのバイパスが使用可能になっている間は SQL Apply により保守される表に対して DML 操作を実行しないことをお薦めします DML 操作を実行すると プライマリ データベースとスタンバイ データベース間で違いが生じ ロジカル スタンバイ データベースをメンテナンスできないようになります ロジカル スタンバイ データベースの管理 9-17

184 ロジカル スタンバイ データベースのカスタマイズ SQL Apply でメンテナンスされていない表の変更 場合によっては レポート生成アプリケーションが 要約した結果を収集してその結果を一時的に格納したり レポートが実行された回数を追跡する必要があります アプリケーションの主な目的はレポート アクティビティを実行することですが ロジカル スタンバイ データベースに対して DML( 挿入 更新および削除 ) 操作の発行が必要な場合があります さらに アプリケーションで表の作成や削除が必要になることもあります データが SQL Apply を介してメンテナンスされていない場合は レポート生成操作でデータを変更できるように データベース ガードを設定できます 次の設定を行う必要があります DBMS_LOGSTDBY.SKIP プロシージャを実行して アプリケーションによるデータの書込みを可能にする ロジカル スタンバイ データベース上の表のセットを指定します スキップされた表は SQL Apply でメンテナンスされません スタンバイ表のみを保護するようにデータベース ガードを設定します 次の例では レポートによって書込みが行われる表がプライマリ データベース上にあると仮定しています この例では 変更をロジカル スタンバイ データベースに適用できるように SQL Apply を停止し 表をスキップした後 SQL Apply を再開しています この操作によって レポート生成アプリケーションは MYSCHEMA の MYTABLES% に書込みができるようになります スキップされた表は SQL Apply でメンテナンスされません SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered. SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL',- schema_name => 'HR', - object_name => 'TESTEMP%'); PL/SQL procedure successfully completed. SQL> EXECUTE DBMS_LOGSTDBY.SKIP('DML','HR','TESTEMP%'); PL/SQL procedure successfully completed. SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered. SQL Apply では 開始後に 新しく指定されてスキップ ルールに追加された表について スタンバイ データベースのメタデータを更新する必要があります SQL Apply によりメタデータが更新される前に 新しくスキップされる表を変更しようとすると失敗します 追加したばかりの SKIP ルールが SQL Apply で正常に考慮されたかどうかは 次の問合せを発行すると確認できます SQL> SELECT VALUE FROM DBA_LOGSDTBY_PARAMETERS WHERE NAME = 'GUARD_STANDBY'; VALUE Ready VALUE 列に Ready と表示される場合 SQL Apply ではスキップされる表の関連メタデータがすべて正常に更新されており その表を変更しても安全です 関連項目 : C.6 項 ロジカル スタンバイ データベースでサポートされる DDL 文 および Oracle Database PL/SQL パッケージ プロシージャおよびタイプ リファレンス の DBMS_LOGSTDBY パッケージに関する項 9-18 Oracle Data Guard 概要および管理

185 ロジカル スタンバイ データベースのカスタマイズ ロジカル スタンバイ データベースでの表の追加または再作成 通常 リカバリ不能な操作の後に表を再作成するには 表のインスタンス化を使用します また プロシージャを使用して 以前はスキップしていた表に対する SQL Apply を使用可能にすることもできます 表を作成する前に 項 プライマリ データベース内の表の行が一意に識別できることの確認 に記載されている要件を満たす必要があります その後 次の手順に従って表 HR.EMPLOYEES を再作成し SQL Apply を再開できます この手順は プライマリ データベースにアクセスするデータベース リンク BOSTON が定義済であることを前提としています 次のリストは 表を再作成し その表に対して SQL Apply を再開する方法を示しています 1. SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 2. DBA_LOGSTDBY_SKIP ビューを問い合せ 問題の表で操作がスキップされていないことを確認します SQL> SELECT * FROM DBA_LOGSTDBY_SKIP; ERROR STATEMENT_OPT OWNER NAME PROC N SCHEMA_DDL HR EMPLOYEES N DML HR EMPLOYEES N SCHEMA_DDL OE TEST_ORDER N DML OE TEST_ORDER ロジカル スタンバイ データベース上で再作成する表には すでにスキップ ルールが関連付けられているため 最初にそのルールを削除する必要があります そのためには DBMS_LOGSTDBY.UNSKIP プロシージャをコールします 次に例を示します SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'DML', - schema_name => 'HR', - object_name => 'EMPLOYEES'); SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'SCHEMA_DDL', - schema_name => 'HR', - object_name => 'EMPLOYEES'); 3. DBMS_LOGSTDBY.INSTANTIATE_TABLE プロシージャを使用し ロジカル スタンバイ データベース内で全データを使用して表 HR.EMPLOYEES を再作成します 次に例を示します SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE(shema_name => 'HR', - object-+_name => 'EMPLOYEES', - dblink => 'BOSTON'); 4. SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 関連項目 : DBMS_LOGSTDBY.UNSKIP および DBMS_ LOGSTDBY.INSTANTIATE_TABLE プロシージャについては Oracle Database PL/SQL パッケージ プロシージャおよびタイプ リファレンス を参照してください ロジカル スタンバイ データベースの管理 9-19

186 ロジカル スタンバイ データベースのコンテキストにおける特定のワークロードの管理 新規にインスタンス化された表とデータベースの残りの部分にまたがってビューの一貫性が得られるように SQL Apply がプライマリ データベースと一致するまで待機してから この表を問い合せます 手順は次のとおりです 1. プライマリ データベースで V$DATABASE ビューを問い合せて現在の SCN を判別します SQL> SELECT CURRENT_SCN FROM CURRENT_SCN 前の問合せで戻された CURRENT_SCN より前のコミット済のトランザクションがすべて SQL Apply により適用されていることを確認します SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN この問合せで戻された APPLIED_SCN が最初の問合せで戻された CURRENT_SCN よりも大きい場合は 新規に再作成された表を問い合せても安全です 9.5 ロジカル スタンバイ データベースのコンテキストにおける特定のワークロードの管理 この項は 次の項目で構成されています プライマリ データベースへのトランスポータブル表領域のインポート マテリアライズド ビューの使用 ロジカル スタンバイ データベースでのトリガーと制約の処理方法 OPEN RESETLOGS 文を使用したリカバリ プライマリ データベースへのトランスポータブル表領域のインポート 表領域をプライマリ データベースにインポートする手順は 次のとおりです 1. ロジカル スタンバイ データベースを変更できるように ガード設定を無効にします SQL> ALTER SESSION DISABLE GUARD; 2. ロジカル スタンバイ データベースで表領域をインポートします 3. データベース ガード設定を有効にします ( または セッションから切断します ) SQL> ALTER SESSION ENABLE GUARD; 4. プライマリ データベースで表領域をインポートします 9-20 Oracle Data Guard 概要および管理

187 ロジカル スタンバイ データベースのコンテキストにおける特定のワークロードの管理 マテリアライズド ビューの使用 SQL Apply では 次の DDL 文はサポートされません CREATE ALTER または DROP MATERIALIZED VIEW CREATE ALTER または DROP MATERIALIZED VIEW LOG そのため ロジカル スタンバイ データベースの作成後にプライマリ データベースで作成 変更または削除された新規マテリアライズド ビューは ロジカル スタンバイ データベースには反映されません ただし ロジカル スタンバイ データベースの作成前にプライマリ データベースで作成されたマテリアライズド ビューは ロジカル スタンバイ データベースにも存在します プライマリ データベースとロジカル スタンバイ データベースの両方に存在するマテリアライズド ビューの場合 トランザクションのコミットが発生すると ロジカル スタンバイ データベースの ON-COMMIT マテリアライズド ビューがリフレッシュされます ON-DEMAND マテリアライズド ビューが SQL Apply により自動的にリフレッシュされることはありません リフレッシュするには DBMS_MVIEW.REFRESH プロシージャを実行する必要があります たとえば 高速リフレッシュ方法を使用して ロジカル スタンバイ データベースにある HR.DEPARTMENTS_MV という ON-DEMAND マテリアライズド ビューをリフレッシュするには 次のコマンドを発行します SQL> EXECUTE DBMS_MVIEW.REFRESH (- LIST => 'HR.DEPARTMENTS_MV', - METHOD => 'F'); ロジカル スタンバイ データベースに追加作成された ON-COMMIT マテリアライズド ビューは 自動的にメンテナンスされます ロジカル スタンバイ データベースに追加作成された ON-DEMAND マテリアライズド ビューは SQL Apply でメンテナンスされません これらは DBMS_MVIEW.REFRESH プロシージャを使用してリフレッシュする必要があります ロジカル スタンバイ データベースでのトリガーと制約の処理方法 デフォルトでは トリガーと制約はロジカル スタンバイ データベースで自動的に使用可能になり 処理されます スタンバイ データベースの場合 トリガーと制約は使用可能ですが 次に示すように実行はされません SQL Apply でメンテナンスされる表にトリガーおよび制約がある場合 : 制約 : CHECK 制約はプライマリ データベースで評価されます ロジカル スタンバイ データベースでの再評価は不要です トリガー : プライマリ データベースで実行されたトリガーの影響は スタンバイ データベースでログに記録され 適用されます SQL Apply でメンテナンスされない表にトリガーおよび制約がある場合 : 制約は評価されます トリガーは発行されます ロジカル スタンバイ データベースの管理 9-21

188 ロジカル スタンバイ データベースのコンテキストにおける特定のワークロードの管理 OPEN RESETLOGS 文を使用したリカバリ ロジカル スタンバイ データベースが REDO データの新規ブランチを受信すると SQL Apply ではそれが自動的に使用されます ロジカル スタンバイ データベースの場合 スタンバイ データベースにより新規リセットログの SCN より後 (REDO データの新規ブランチの開始より後 ) の REDO データが適用されていなければ 手動による介入は必要ありません 次の表に スタンバイ データベースとプライマリ データベースのブランチを再同期化する方法を示します スタンバイ データベースの状態 新規リセットログの SCN の後 (REDO データの新規ブランチの開始より後 ) の REDO データが適用されていない場合 操作 SQL Apply は 自動的に REDO データの新規ブランチを使用します 実行する手順 手動による介入は必要ありません ロジカル スタンバイ プロセス (LSP) は 自動的にスタンバイ データベースを REDO データの新規ブランチと再同期化します 新規リセットログの SCN の後 (REDO データの新規ブランチの開始より後 ) の REDO データが適用され スタンバイ データベースでフラッシュバック データベースが使用可能になっている場合 新規リセットログの SCN の後 (REDO データの新規ブランチの開始より後 ) の REDO データが適用され スタンバイ データベースでフラッシュバック データベースが使用可能になっていない場合 スタンバイ データベースは REDO データの将来の新規ブランチでリカバリされます 指定のプライマリ データベース ブランチで プライマリ データベースとスタンバイの内容にずれが生じます 項 プライマリのフラッシュバック後のロジカル スタンバイ データベースのフラッシュバック の手順に従ってロジカル スタンバイ データベースをフラッシュ バックします 2. SQL Apply を再開し 新規リセットログ ブランチへの REDO の適用を続行します LSP は 自動的にスタンバイ データベースを新規ブランチと再同期化します 第 4 章 ロジカル スタンバイ データベースの作成 の手順に従ってロジカル スタンバイ データベースを再作成します REDO データの新規ブランチから介入するアーカイブ REDO ログ ファイルが欠落している場合 REDO データの前のブランチの終わりからアーカイブ REDO ログ ファイルが欠落している場合 LSP は欠落しているログ ファイルが取得されるまで続行できません LSP は欠落しているログ ファイルが取得されるまで続行できません 各ブランチから欠落しているアーカイブ REDO ログ ファイルを検索して登録します 前のブランチから欠落しているアーカイブ REDO ログ ファイルを検索して登録します データベース インカネーション OPEN RESETLOGS 操作を介したリカバリおよびフラッシュバック データベースの詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください 9-22 Oracle Data Guard 概要および管理

189 ロジカル スタンバイ データベースのチューニング 9.6 ロジカル スタンバイ データベースのチューニング この項は 次の項目で構成されています 主キー RELY 制約の作成 コストベース オプティマイザの統計の収集 プロセス数の調整 LCR キャッシュ用メモリーの調整 ロジカル スタンバイ データベースにおけるトランザクションの適用方法の調整 主キー RELY 制約の作成 プライマリ データベースで 表に主キーまたは一意索引がなく 実際には一意である行がわかっている場合は 主キーの RELY 制約を作成します ロジカル スタンバイ データベースでは 主キーを構成する列に索引を作成します 次の問合せは ロジカル スタンバイ データベースで行を一意に識別するために適用できる索引情報がない表のリストを生成します 次の表に索引を作成することによって パフォーマンスが大幅に向上する可能性があります SQL> SELECT OWNER, TABLE_NAME FROM DBA_TABLES 2> WHERE OWNER NOT IN('SYS','SYSTEM','OUTLN','DBSNMP') 3> MINUS 3> SELECT DISTINCT TABLE_OWNER, TABLE_NAME FROM DBA_INDEXES 4> WHERE INDEX_TYPE NOT LIKE ('FUNCTION-BASED%') 5> MINUS 6> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED; プライマリ データベースの表に主キーの RELY 制約を追加する手順は 次のとおりです 1. プライマリ データベースで主キーの RELY 制約を追加します SQL> ALTER TABLE HR.TEST_EMPLOYEES ADD PRIMARY KEY (EMPNO) RELY DISABLE; SQL> ALTER SESSION DISABLE GUARD; これにより HR.TEST_EMPLOYEES 表の各行を一意に識別するために使用可能な EMPNO 列が その表に対して実行される更新の一部としてサプリメンタル ロギングで確実に記録されるようになります HR.TEST_EMPLOYEES 表には ロジカル スタンバイ データベースで指定された一意索引がまだないことに注意してください このため UPDATE 文ではロジカル スタンバイ データベースに対して全表スキャンが実行される場合があります これを避けるには ロジカル スタンバイ データベースで EMPNO 列に一意索引を追加します RELY 制約の詳細は 項 プライマリ データベース内の表の行が一意に識別できることの確認 および Oracle Database SQL リファレンス を参照してください 2. SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 3. ロジカル スタンバイ データベースでメンテナンスされる表を変更できるように ガードを無効にします SQL> ALTER SESSION DISABLE GUARD; 4. EMPNO 列に一意索引を追加します SQL> CREATE UNIQUE INDEX UI_TEST_EMP ON HR.TEST_EMPLOYEES (EMPNO); 5. ガードを有効にします SQL> ALTER SESSION ENABLE GUARD; 6. SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; ロジカル スタンバイ データベースの管理 9-23

190 ロジカル スタンバイ データベースのチューニング コストベース オプティマイザの統計の収集 プロセス数の調整 コストベース オプティマイザ (CBO) で最適の問合せ実行パスを判別するために使用されるため スタンバイ データベースで統計を収集する必要があります 以前の統計情報が正確でなくなるような変更をスキーマ オブジェクトのデータまたは構造に対して実行した場合は その後に新しい統計を収集してください たとえば 多数の行を表に挿入または削除した後は 行数に関する新しい統計を収集します プライマリ データベースでの DML および DDL 操作はワークロードの機能として実行されるため 統計はスタンバイ データベースで収集してください スタンバイ データベースがプライマリ データベースと論理的に等しい場合 SQL Apply ではワークロードを異なる方法で実行する場合があります そのため ロジカル スタンバイ データベースで STATS パッケージおよび V$SYSSTAT ビューを使用すると リソースおよび表スキャンを最も多く使用している表を判断する際に役立ちます 関連項目 : RELY 制約の詳細は 項 プライマリ データベース内の表の行が一意に識別できることの確認 および Oracle Database SQL リファレンス を参照してください 次の各項で 次の内容を説明します APPLIER プロセス数の調整 PREPARER プロセス数の調整 APPLIER プロセス数の調整 APPLIER プロセスの数を調整することでスループットを改善できるかどうかを判断する手順は 次のとおりです 1. 次の問合せを発行して APPLIER プロセスがビジーかどうかを判断します SQL> SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER' and status_code = 16166; IDLE_APPLIER アイドル状態の APPLIER プロセスがないことを確認した後 次の問合せを発行し APPLIER の数を調整した場合に追加分の APPLIER プロセスに十分な処理が使用可能かどうかを確認します SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE 'TRANSACTIONS%'; NAME VALUE transactions ready transactions applied この 2 つの統計では APPLIER プロセスによる適用準備が完了しているトランザクション数とすでに適用済のトランザクション数の累計が維持されます この数値 (transactions ready - transactions applied) が使用可能な APPLIER プロセス数の 2 倍を超えている場合は APPLIER プロセス数を増やすことでスループットを改善できます 9-24 Oracle Data Guard 概要および管理

191 ロジカル スタンバイ データベースのチューニング 注意 : この数値は準備作業の概算です ワークロードによっては 準備が完了したトランザクション間の依存性が 使用可能な追加の APPLIER プロセスによる適用の妨げになる場合があります たとえば 適用準備の完了しているトランザクションの大多数が DDL トランザクションの場合は さらに APPLIER プロセスを追加してもスループットは改善されません APPLIER プロセスの数を調整してデフォルト値の 5 から 20 にする手順は 次のとおりです a. SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered b. APPLY_SERVERS の数を 20 に設定します SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS', 20); PL/SQL procedure successfully completed c. SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered PREPARER プロセス数の調整 PREPARER プロセスの数の調整が必要になることは ほとんどありません PREPARER プロセスの数を増やす前に 次の条件に該当しているかどうかを確認してください すべての PREPARER プロセスがビジーである 適用準備が完了しているトランザクションの数が 使用可能な APPLIER プロセスの数よりも少ない アイドル状態の APPLIER プロセスがある 前述の条件に該当しているかどうかを判断する手順は 次のとおりです 1. すべての PREPARER プロセスがビジーであることを確認します SQL> SELECT COUNT(*) AS IDLE_PREPARER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'PREPARER' and status_code = 16166; IDLE_PREPARER 適用準備が完了しているトランザクションの数が APPLIER プロセスの数よりも少ないことを確認します SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE 'transactions%'; NAME VALUE transactions ready transactions applied SQL> SELECT COUNT(*) AS APPLIER_COUNT FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER'; APPLIER_COUNT 注意 : これが一時イベントでないことを確認するために この問合せは数回発行してください ロジカル スタンバイ データベースの管理 9-25

192 ロジカル スタンバイ データベースのチューニング 3. アイドル状態の APPLIER プロセスがあることを確認します SQL> SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER' and status_code = 16166; IDLE_APPLIER この例では すべての条件に該当しています したがって 次の手順を実行して PREPARER プロセスの数を 4 に ( デフォルト値の 1 から ) 増やすことができます 1. SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered 2. PREPARE_SERVERS の数を 4 に設定します SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS', 4); PL/SQL procedure successfully completed 3. SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered LCR キャッシュ用メモリーの調整 ある程度のワークロードの場合 SQL Apply は多数のページアウト操作を使用することがあるため システム全体のスループットが低下します LCR キャッシュに割当済のメモリーを増やした場合にスループットを改善できるかどうかを判断する手順は 次のとおりです 1. 次の問合せを発行して ページアウト アクティビティのスナップショットを取得します SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE '%PAGE%' OR NAME LIKE '%UPTIME%' OR NAME LIKE '%idle%'; NAME VALUE coordinator uptime in secs bytes paged out microsecs spent in pageout 2 system idle time in secs この問合せを 5 分以内に再発行します SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE '%PAGE%' OR NAME LIKE '%UPTIME%' OR NAME LIKE '%idle%'; NAME VALUE coordinator uptime in secs bytes paged out secs spent in pageout 100 system idle time in secs 正規化されたページアウト アクティビティを計算します 次に例を示します Change in coordinator uptime (C)= ( ) = 300 secs Amount of additional idle time (I)= ( ) = 0 Change in time spent in pageout (P) = (100 2) = 98 secs Pageout time in comparison to uptime = P/(C-I) = 98/300 ~ 32.67% 9-26 Oracle Data Guard 概要および管理

193 ロジカル スタンバイ データベースのチューニング ページアウト アクティビティによる消費量が稼働時間全体の 5% 以下であれば理想的です 間隔を長くして引き続きスナップショットを取得し ページアウト アクティビティが引き続き適用時間の大部分を占めていることがわかった場合は メモリー サイズを大きくするとスループットが改善される可能性があります SQL Apply に割当済のメモリーを増やす手順は 次のとおりです 1. SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered 2. LCR キャッシュに割当済のメモリーを設定します ( この例では SGA は 1GB に設定されています ) SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 1024); PL/SQL procedure successfully completed MAX_SGA は MB 単位で指定されているため この例ではメモリーを 1GB に増やすために 1024(MB) と指定しています 3. SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered ロジカル スタンバイ データベースにおけるトランザクションの適用方法の調整 デフォルトでは トランザクションは プライマリ データベースでコミットされた順序に正確に従って ロジカル スタンバイ データベースに適用されます トランザクションのデフォルトのコミット順序では レポート アプリケーションをロジカル スタンバイ データベースで透過的に実行できます ただし ロジカル スタンバイ データベースをプライマリ データベースと一致させる必要があり しばらくはレポート アプリケーションを実行しなくてもよい場合があります ( ハードウェア障害やアップグレードが原因でロジカル スタンバイ データベースの停止が長引いた後など ) この場合は 次の手順でデフォルトの適用モードを変更できます 1. SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered 2. PRESERVE_COMMIT_ORDER を FALSE に設定します SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER', 'FALSE'); PL/SQL procedure successfully completed 3. SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered プライマリ データベースと一致し (V$LOGSTDBY_STATS ビューを問い合せて確認し ) ロジカル スタンバイ データベースをレポート アプリケーションに対してオープンする準備が完了した時点で 次のように適用モードを変更できます 1. SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered 2. PRESERVE_COMMIT_ORDER パラメータのデフォルト値をリストアします SQL> EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER'); PL/SQL procedure successfully completed ロジカル スタンバイ データベースの管理 9-27

194 ロジカル スタンバイ データベースのチューニング 3. SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered 一般的なオンライン トランザクション処理 (OLTP) のワークロードでは デフォルト以外のモードにすると デフォルトの適用モードに比べてスループットを 50% 以上改善できます 9-28 Oracle Data Guard 概要および管理

195 10 Recovery Manager を使用したファイルのバックアップおよびリストア この章では Data Guard およびスタンバイ データベースとともに Oracle Recovery Manager ユーティリティ (RMAN) を使用するバックアップ対策について説明します Recovery Manager を使用すると 最小限の労力でプライマリ データベースのバックアップを実行し 個々のデータファイルの消失から またはデータベース全体をすばやくリカバリできます Recovery Manager と Data Guard を併用すると Data Guard 構成の管理作業を簡素化できます この章は 次の項目で構成されています バックアップ処理 スイッチオーバー フェイルオーバーおよび制御ファイル作成がバックアップに与える影響 その他のバックアップ状況 注意 : ロジカル スタンバイ データベースはプライマリ データベースのブロック単位のコピーではないため ロジカル スタンバイ データベースを使用してプライマリ データベースをバックアップすることはできません Recovery Manager を使用したファイルのバックアップおよびリストア 10-1

196 バックアップ処理 10.1 バックアップ処理 スタンバイ環境では プライマリまたはスタンバイ システム上のデータファイルとアーカイブ REDO ログ ファイルのバックアップを作成すると 両方のシステムでリカバリに使用できます 制御ファイルや SPFILE など 一部のファイルのバックアップはプライマリ データベースで作成する必要がありますが データファイルとアーカイブ REDO ログ ファイルのバックアップ処理をスタンバイ システムにオフロードして バックアップが本番システムに与える影響を最小限に抑えることができます スタンバイ サイトで作成できるのは スタンバイ インスタンスによって作成されたアーカイブ REDO ログ ファイルのバックアップのみです スタンバイ データベースの起動前に生成されたアーカイブ REDO ログ ファイルが存在する場合は そのバックアップをプライマリ データベースで作成する必要があります たとえば プライマリ データベースからスタンバイに送信された最初のログがログ順序番号 100 スレッド 1 の場合は プライマリ データベースで 99 以下のログ順序番号を持つアーカイブ REDO ログ ファイルのバックアップを実行する必要があります フラッシュ リカバリ領域が構成されている場合 Oracle ソフトウェアでは必要に応じてフラッシュ リカバリ領域からファイルが削除されます フラッシュ リカバリ領域は テープ バックアップ用のディスク キャッシュとして機能します テープ バックアップ用キャッシュとしてのディスクの使用 次の手順では フラッシュ リカバリ領域が構成されており (5.2.3 項を参照 ) 他の Recovery Manager の永続構成が設定されていると仮定します 次の手順に従ってください 1. プライマリ データベースで 次の Recovery Manager コマンドを発行して制御ファイルと SPFILE の最新バックアップを作成し プライマリ インスタンスによって作成されたフラッシュ リカバリ領域内のファイルをテープにバックアップします BACKUP DEVICE TYPE DISK CURRENT CONTROLFILE; BACKUP RECOVERY AREA; これらのコマンドは 現行の制御ファイルがすべて消失した場合に許容できる REDO データの適用量に応じて ( 項を参照 ) 毎日または 1 週間に 1 回発行 ( またはスクリプトで使用 ) します 2. スタンバイ データベースで 次の Recovery Manager コマンドを毎日発行し データベースのレベル 0 のコピーをロールフォーワードします RECOVER COPY OF DATABASE WITH TAG 'OSS'; BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE; BACKUP DEVICE TYPE DISK ARCHIVELOG ALL NOT BACKED UP 2 TIMES; BACKUP RECOVERY AREA; これらのコマンドは 前日に実行されたレベル 1 の増分バックアップを適用して 新しいレベル 1 の増分バックアップを作成し アーカイブ REDO ログ ファイルをフラッシュ リカバリ領域にバックアップして スタンバイ インスタンスによって作成されたファイルをフラッシュ リカバリ領域からテープにバックアップします 10-2 Oracle Data Guard 概要および管理

197 スイッチオーバー フェイルオーバーおよび制御ファイル作成がバックアップに与える影響 テープへの直接バックアップの実行 すべてのバックアップがテープに直接書き込まれる場合は Recovery Manager の CONFIGURE DEFAULT DEVICE TYPE TO SBT コマンドを使用してデフォルトのデバイス タイプを SBT に構成します プライマリ データベースで 次の Recovery Manager コマンドを使用して 現行の制御ファイルのバックアップを作成し プライマリ インスタンスによって作成された自動バックアップをテープにコピーします BACKUP AS BACKUPSET CURRENT CONTROLFILE; BACKUP RECOVERY AREA; これらのコマンドは 現行の制御ファイルがすべて消失した場合に許容できる REDO データの適用量に応じて ( 項を参照 ) 毎日または 1 週間に 1 回発行します 完全データベース バックアップが毎週日曜に実行される場合は スタンバイ データベースで次のコマンドを発行してレベル 0 のデータベース バックアップを作成できます BACKUP AS BACKUPSET INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG NOT BACKED UP 2 TIMES; バックアップ サイクルの別の曜日に 次のコマンドを実行して データベースとまだ 2 回バックアップされていないすべてのアーカイブ REDO ログ ファイルのレベル 1 増分バックアップを作成します BACKUP AS BACKUPSET INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG NOT BACKED UP 2 TIMES; 10.2 スイッチオーバー フェイルオーバーおよび制御ファイル作成がバックアップに与える影響 次のいずれかのイベントが発生した場合は Recovery Manager の CATALOG ARCHIVELOG 'archivelog_name_complete_path' コマンドを使用して バックアップが実行されたシステム上で最後のバックアップ以後に生成されたアーカイブ REDO ログ ファイルをすべて手動でカタログ化する必要があります プライマリまたはスタンバイ制御ファイルが再作成された場合 プライマリ データベース ロールが スイッチオーバー後にスタンバイに変更された場合 スタンバイ データベース ロールが スイッチオーバーまたはフェイルオーバー後にプライマリに変更された場合 新規アーカイブ REDO ログ ファイルがカタログ化されていない場合 Recovery Manager ではバックアップを作成できません 次の各項の例では バックアップを作成したのと同じシステムにテープからファイルをリストアすると仮定しています ファイルを異なるシステムにリストアする場合は メディア構成を変更するか リストア中に Recovery Manager チャネルで異なるパラメータを指定するか あるいはその両方の操作が必要になることがあります 異なるシステムから Recovery Manager バックアップにアクセスする方法の詳細は メディア管理のドキュメントを参照してください Recovery Manager を使用したファイルのバックアップおよびリストア 10-3

198 スイッチオーバー フェイルオーバーおよび制御ファイル作成がバックアップに与える影響 プライマリ データベースのデータファイル消失からのリカバリ 次の Recovery Manager コマンドを発行し データファイルをリストアおよびリカバリします プライマリ データベースとリカバリ カタログ データベースの両方に接続する必要があります RESTORE DATAFILE n,m...; RECOVER DATAFILE n,m...; 次の Recovery Manager コマンドを発行して 表領域をリストアおよびリカバリします プライマリ データベースとリカバリ カタログ データベースの両方に接続する必要があります RESTORE TABLESPACE tbs_name1, tbs_name2,... RECOVER TABLESPACE tbs_name1, tbs_name2, スタンバイ データベースのデータファイル消失からのリカバリ 1 つ以上のデータファイルが消失した後にスタンバイ データベースをリカバリするには Recovery Manager の RESTORE DATAFILE コマンドを使用して 消失したファイルをバックアップからスタンバイ データベースにリストアする必要があります 破損ファイルのリカバリに必要なアーカイブ REDO ログ ファイルすべてにスタンバイ データベースがディスク上でアクセス可能な場合は REDO Apply を再開します リカバリに必要なアーカイブ REDO ログ ファイルにディスク上でアクセスできない場合は 次の手順に従って Recovery Manager を使用し リストアしたデータファイルをスタンバイ データベースに最後に適用されたログよりも大きい SCN/ ログ順序番号までリカバリし REDO Apply を再開して REDO データの適用を続行します 1. REDO Apply を停止します 2. 次の問合せを発行して UNTIL_SCN 列の値を判別します SQL> SELECT MAX(NEXT_CHANGE#)+1 UNTIL_SCN FROM V$LOG_HISTORY LH, V$DATABASE DB WHERE LH.RESETLOGS_CHANGE#=DB.RESETLOGS_CHANGE# AND LH.RESETLOGS_TIME = DB.RESETLOGS_TIME; UNTIL_SCN 次の Recovery Manager コマンドを発行して スタンバイ データベースでデータファイルをリストアおよびリカバリします スタンバイ データベースとリカバリ カタログ データベースの両方に接続する必要があります ( スタンバイ インスタンスへの接続には TARGET キーワードを使用します ) RESTORE DATAFILE <n,m,...>; RECOVER DATABASE UNTIL SCN ; 表領域をリストアするには Recovery Manager の 'RESTORE TABLESPACE tbs_name1, tbs_name2,...' コマンドを使用します 4. REDO Apply を再開します 10-4 Oracle Data Guard 概要および管理

199 スイッチオーバー フェイルオーバーおよび制御ファイル作成がバックアップに与える影響 スタンバイ制御ファイルの消失からのリカバリ Oracle ソフトウェアでは スタンバイ制御ファイルを多重化できます スタンバイ制御ファイルが多重化されているかどうかを確認するには 次のように CONTROL_FILES 初期化パラメータを調べます SQL> SHOW PARAMETER CONTROL_FILES NAME TYPE VALUE control_files string <cfilepath1>,<cfilepath2> 多重スタンバイ制御ファイルの 1 つが消失しているかアクセスできないと Oracle ソフトウェアはインスタンスを停止し アラート ログに次のメッセージを書き込みます ORA-00210: 指定された制御ファイルをオープンできません ORA-00202: 制御ファイル : '/ade/banand_hosted6/oracle/dbs/scf3_2.f' ORA-27041: ファイルをオープンできません 制御ファイルの元のコピーを消失したコピーに上書きコピーし 次の SQL 文を使用してスタンバイ インスタンスを再起動できます SQL> STARTUP MOUNT; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; スタンバイ制御ファイルがすべて消失した場合は プライマリ データベースから新規制御ファイルを作成し それをスタンバイ データベースのすべての多重化位置にコピーして スタンバイ インスタンスを再起動し REDO Apply を再開する必要があります 作成された制御ファイルからは 作成前に生成されていたアーカイブ REDO ログ ファイルに関する情報がすべて失われています Recovery Manager はバックアップ対象となるアーカイブ REDO ログ ファイルのリストを制御ファイル内で検索するため 前回のバックアップ以後に生成されたアーカイブ REDO ログ ファイルをすべて手動でカタログ化する必要があります プライマリ制御ファイルの消失からのリカバリ Oracle ソフトウェアでは プライマリ データベースの制御ファイルを多重化できます プライマリ データベースで制御ファイルの 1 つを更新できない場合は プライマリ データベース インスタンスが自動的に停止します 項で説明したように リストアまたはリカバリ操作を実行しなくても 制御ファイルの元のコピーをコピーしてインスタンスを再起動できます 制御ファイルがすべて消失した場合は 許容できるダウンタイムに応じて次の手順から選択できます 新規制御ファイルの作成制御ファイルのコピーがすべて消失した場合は メディア リカバリの実行後に NORESETLOGS オプションを使用して新規制御ファイルを作成し データベースをオープンできます 既存のスタンバイ データベース インスタンスでは 次の文を使用して新規制御ファイルを作成するためのスクリプトを生成できます SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS; プライマリ データベースとスタンバイ データベースでデータベース ファイル名が異なる場合は 生成されたスクリプトを編集してファイル名を訂正する必要があります この文を定期的に使用して制御ファイル作成スクリプトを生成できます リカバリ計画の一部として制御ファイル作成スクリプトを使用する場合は データファイル 表領域または REDO ログ メンバーの追加や削除など 物理構造の変更後にこの文を使用する必要があります 作成された制御ファイルからは 作成前に生成されていたアーカイブ REDO ログ ファイルに関する情報がすべて失われています プライマリ データベースでアーカイブ REDO ログ ファイルのバックアップを実行する場合は 前回のバックアップ以後に生成されたアーカイブ REDO ログ ファイルをすべて手動でカタログ化しておく必要があります Recovery Manager を使用したファイルのバックアップおよびリストア 10-5

200 スイッチオーバー フェイルオーバーおよび制御ファイル作成がバックアップに与える影響 バックアップ制御ファイルを使用したリカバリ前述の手順で制御ファイルを作成できない場合は バックアップ制御ファイルを使用し 完全リカバリを実行して RESETLOGS オプションを指定してデータベースをオープンできます 制御ファイルをリストアしてデータベースをリカバリするには プライマリ インスタンス (NOMOUNT 状態 ) とカタログ データベースに接続した後に 次の Recovery Manager コマンドを発行します RESTORE CONTROLFILE; ALTER DATABASE MOUNT; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; Oracle リリース からは RESETLOGS 操作の前に作成したバックアップすべてをリカバリに使用できます そのため 本番に使用可能にする前にデータベースのバックアップを作成する必要はありません オンライン REDO ログ ファイルの消失からのリカバリ オンライン REDO ログ ファイルは多重化することをお薦めします オンライン REDO ログ グループのメンバーがすべて消失すると Oracle ソフトウェアはインスタンスを終了します 書込みできないのがログ ファイル グループの一部のメンバーのみの場合 そのメンバーはアクセス可能になるまで使用されません V$LOGFILE および V$LOG ビューには プライマリ データベース インスタンスのログ ファイル メンバーの現在のステータスに関する詳細情報が含まれます Oracle ソフトウェアがオンライン REDO ログ ファイルのメンバーの 1 つに書込みできない場合は 次のアラート メッセージが戻されます ORA-00313: ログ グループ 1( スレッド 1) のメンバーをオープンできません ORA-00312: オンライン ログ 1 スレッド 1: '/ade/banand_hosted6/oracle/dbs/t1_log1.f' ORA-27037: ファイル ステータスを取得できません SVR4 Error: 2: No such file or directory Additional information: 3 アクセスの問題がハードウェア エラーによる一時的なものの場合は 問題を解決すると処理が自動的に続行されます 消失が永続的な場合は 新規メンバーを追加して古いメンバーをグループから削除できます REDO ログ グループに新規メンバーを追加するには 次の文を発行します SQL> ALTER DATABASE ADD LOGFILE MEMBER 'log_file_name' REUSE TO GROUP n この文は データベースがオープン状態の場合にも データベースの可用性に影響を与えずに発行できます アーカイブ済の非アクティブ グループのメンバーがすべて消失した場合は そのグループを削除して再作成できます 他のすべての場合 ( 現行の ACTIVE グループまたはアーカイブされていない非アクティブ グループのオンライン ログ メンバーすべてが消失した場合 ) は スタンバイ データベースにフェイルオーバーする必要があります フェイルオーバー手順については第 7 章を参照してください 10-6 Oracle Data Guard 概要および管理

201 スイッチオーバー フェイルオーバーおよび制御ファイル作成がバックアップに与える影響 データベースの不完全リカバリ プライマリ データベースの不完全リカバリを実行するのは 通常 データベースが論理的に ( ユーザーまたはアプリケーションが原因で ) 破損した場合や 表領域またはデータファイルがデータベースから意図せずに削除された場合などです スタンバイ データベース インスタンス上の現在のデータベース チェックポイント SCN に応じて 次のいずれかの手順でデータベースの不完全リカバリを実行できます すべての手順は 最も所要時間が短いものから優先順位順になっています フラッシュバック データベースの使用フラッシュバック データベースの使用は プライマリ データベースでフラッシュバック データベース機能が使用可能で データベース ファイルが 1 つも消失しておらず Point-in-Time リカバリが最も古いフラッシュバック SCN より大きいか 最も早いフラッシュバック時間よりも後の場合の推奨手順です フラッシュバック データベースを使用して Point-in-Time リカバリを実行する手順については 12.5 項を参照してください スタンバイ データベース インスタンスの使用これは スタンバイ データベースが必要な不完全リカバリ時間より後のもので プライマリまたはスタンバイ データベースでフラッシュバック データベースが使用可能でない場合の推奨手順です 1. スタンバイ データベースを必要な時点までリカバリします RECOVER DATABASE UNTIL TIME 'time'; あるいは SCN またはログ順序番号を使用して不完全リカバリ時間を指定できます RECOVER DATABASE UNTIL SCN incomplete recovery SCN' RECOVER DATABASE UNTIL LOGSEQ incomplete recovery log sequence number THREAD thread number 2. スタンバイ データベースを読取り専用モードでオープンし データベースの状態を確認します 必要な状態になっていない場合は LogMiner ユーティリティを使用してアーカイブ REDO ログ ファイルを調べ 不完全リカバリに適切なターゲット時刻または SCN を確認します または ターゲット時刻より前の判明している時点までスタンバイ データベースをリカバリしてから データベースを読取り専用モードでオープンし データの状態を検査することもできます データベースの状態が正常であると確認されるまで このプロセスを繰り返します データベースのリカバリ終了時点が遅すぎると ( つまり エラーが発生した SCN より後までリカバリすると ) それより前の SCN に戻せないことに注意してください 3. SQL ALTER DATABASE ACTIVATE STANDBY DATABASE 文を使用してスタンバイ データベースをアクティブ化します これにより スタンバイ データベースがプライマリ データベースに変換されて 新しいリセットログ ブランチが作成され データベースがオープンします 新規リセットログ ブランチへのスタンバイ データベースの対応については 8.4 項を参照してください プライマリ データベース インスタンスの使用すべてのスタンバイ データベース インスタンスがすでに必要な時点より後までリカバリされており プライマリまたはスタンバイ データベースでフラッシュバック データベースが使用可能な場合は この方法で操作する必要があります 次の手順に従ってプライマリ データベースで不完全リカバリを実行します 1. LogMiner または他の手段を使用して データベースのすべてのデータが正常と判明している時点または SCN を識別します Recovery Manager を使用したファイルのバックアップおよびリストア 10-7

202 その他のバックアップ状況 2. その時点または SCN を使用して次の Recovery Manager コマンドを発行し 不完全データベース リカバリを実行し RESETLOGS オプションを使用して ( カタログ データベースと MOUNT 状態のプライマリ インスタンスに接続した後で ) データベースをオープンします RUN { SET UNTIL TIME 'time'; RESTORE DATABASE; RECOVER DATABASE; } ALTER DATABASE OPEN RESETLOGS; この処理の後に Data Guard 構成内ですべてのスタンバイ データベース インスタンスを再確立する必要があります 10.3 その他のバックアップ状況 次の各項では スタンバイ データベースとプライマリ データベースでバックアップ ファイルを共有できない場合 REDO ログ ファイルのリモート アーカイブにスタンバイ インスタンスのみが使用される場合 またはスタンバイ データベースのファイル名がプライマリ データベースとは異なる場合など その他の構成にあわせてバックアップ処理を変更する方法について説明します スタンバイ データベースが地理的に離れすぎているためにバックアップを共有できない場合 この場合 プライマリ システムや他のスタンバイ システムからは スタンバイ システム上で作成されたバックアップに簡単にアクセスできません すべてのシステム上でデータベースの完全バックアップを実行して リカバリ操作を実行します フラッシュ リカバリ領域は プライマリおよびスタンバイ システム上にローカルに置くことができます ( プライマリ データベースとスタンバイ データベースでフラッシュ リカバリ領域が異なる場合など ) この使用例でも 10.2 項で説明した一般的な対策を使用できますが 次の例外があります Recovery Manager で作成されるバックアップ ファイルには タグとしてローカル システム名を指定し そのタグを RESTORE 操作で使用して Recovery Manager による同じホスト上で作成されたバックアップの選択を制限する必要があります つまり バックアップの作成時には BACKUP コマンドで TAG node name オプションを使用します また RESTORE コマンドでは FROM TAG node name オプションを使用し RECOVER コマンドでは FROM TAG node name ARCHIVELOG TAG node name オプションを使用する必要があります スタンバイ サイトの障害時リカバリを実行する手順は 次のとおりです 1. スタンバイの操作に使用されていたのと同じパラメータ ファイルを使用して スタンバイ インスタンスを NOMOUNT 状態で起動します 2. プライマリ インスタンスで SQL ALTER DATABASE CREATE STANDBY CONTROLFILE AS filename 文を使用してスタンバイ制御ファイルを作成し 作成された制御ファイルを使用してスタンバイ インスタンスをマウントします 3. 次の Recovery Manager コマンドを発行し データベース ファイルをリストアおよびリカバリします RESTORE DATABASE FROM TAG 'node name' RECOVER DATABASE FROM TAG 'node name' ARCHIVELOG TAG 'node name' 4. REDO Apply を再開します 5.8 項で説明したように スタンバイ インスタンスにより残りのアーカイブ REDO ログ ファイルがフェッチされます 10-8 Oracle Data Guard 概要および管理

203 その他のバックアップ状況 FAL サーバーとして使用されるスタンバイ データベースにデータファイルが含まれていない場合 10.1 項で説明した手順を使用しますが データベース ファイルをバックアップする Recovery Manager コマンドは FAL サーバーに対して実行できません FAL サーバーは すべてのアーカイブ REDO ログ ファイルのバックアップ ソースとして使用できるため アーカイブ REDO ログ ファイルのバックアップを FAL サーバーにオフロードします スタンバイ データベースのファイル名がプライマリ データベースとは異なる場合 プライマリ データベースとスタンバイ データベースでデータベース ファイル名が異なる場合は 少し異なる RESTORE および RECOVER コマンドを使用します スタンバイ データベースで実際のデータファイル名を取得するには V$DATAFILE ビューを問い合せ データベースのすべてのデータファイルに対して SET NEWNAME オプションを指定します RUN { SET NEWNAME FOR DATAFILE 1 TO 'existing file location for file#1 from V$DATAFILE'; SET NEWNAME FOR DATAFILE 2 TO 'existing file location for file#2 from V$DATAFILE'; SET NEWNAME FOR DATAFILE n TO 'existing file location for file#n from V$DATAFILE'; RESTORE {DATAFILE <n,m, > TABLESPACE tbs_name_1, 2, DATABASE; SWITCH DATAFILE ALL; RECOVER DATABASE {NOREDO}; } 同様に Recovery Manager の DUPLICATE コマンドでも SET NEWNAME オプションを使用し スタンバイ データベースの作成中に新規ファイル名を指定する必要があります フラッシュ リカバリ領域のアーカイブ REDO ログ ファイルに関する削除ポリシー デフォルトでは 3 次記憶装置にバックアップ済であるか廃止 (Recovery Manager の保存ポリシーで定義 ) になったフラッシュ リカバリ領域内のアーカイブ REDO ログ ファイルは 削除対象となります バックアップ済または廃止になったアーカイブ REDO ログ ファイルは 最終的には自動的に削除し フラッシュ リカバリ領域のディスク領域がいっぱいになった場合に領域を解放できます ただし このデフォルトの削除ポリシーは 次の Recovery Manager コマンドを使用して変更できます CONFIGURE ARCHIVELOG DELETION POLICY TO [CLEAR NONE APPLIED ON STANDBY]; この項では コマンド修飾子について説明し 削除ポリシーの設定例を示します Oracle ソフトウェアによるフラッシュ リカバリ領域のディスク領域の管理方法の詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください Recovery Manager を使用したファイルのバックアップおよびリストア 10-9

204 その他のバックアップ状況 APPLIED ON STANDBY 句の使用すべての必須スタンバイ宛先に適用済のアーカイブ REDO ログ ファイルが削除されるように APPLIED ON STANDBY 句を使用します 次の表に この句を指定した場合に実行されるアクションを示します APPLIED ON STANDBY 句の構成場所プライマリ データベース 削除対象となるファイル すべての必須スタンバイ データベースに適用済の フラッシュ リカバリ領域内のアーカイブ REDO ログ ファイル 1 つ以上の必須のカスケード スタンバイ データベースを持つスタンバイ データベース すべての必須カスケード スタンバイ データベースに適用済の フラッシュ リカバリ領域内のアーカイブ REDO ログ ファイル カスケード スタンバイ データベースを持たないスタンバイ データベース スタンバイ データベースに適用済の フラッシュ リカバリ領域内のアーカイブ REDO ログ ファイル カスケードされた宛先の詳細は 付録 E を参照してください CLEAR 句の使用 CLEAR 句を使用して Recovery Manager の CONFIGURE ARCHIVELOG DELETION POLICY コマンドで前に設定した削除ポリシーを使用不可能にします Oracle データベースは デフォルトの削除ポリシー動作を再開します つまり フラッシュ リカバリ領域のディスク領域がいっぱいになると バックアップ済または廃止になったアーカイブ REDO ログ ファイルを削除して領域を解放します NONE 句の使用バックアップ済または廃止になったフラッシュ リカバリ領域内のアーカイブ REDO ログが Recovery Manager の保存ポリシーに基づいて削除対象となるように NONE 句を使用します これがデフォルト構成です フラッシュ リカバリ領域のディスク領域がいっぱいになると バックアップ済または廃止になったアーカイブ REDO ログ ファイルが削除され 領域が解放されます CONFIGURE ARCHIVELOG DELETION POLICY コマンドの例スタンバイ データベースでアーカイブ REDO ログ ファイルのバックアップを作成する場合の手順は 次のとおりです 1. プライマリ データベースで次のコマンドを発行します CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY; 2. スタンバイ データベースで次のコマンドを発行します CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; プライマリ データベースでアーカイブ REDO ログ ファイルのバックアップを作成する場合の手順は 次のとおりです 1. スタンバイ データベースで次のコマンドを発行します CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY; 2. プライマリ データベースで次のコマンドを発行します CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; Oracle Data Guard 概要および管理

205 その他のバックアップ状況 ロールが推移した後の削除ポリシーの再構成 スイッチオーバーまたはフェイルオーバーの後に 各データベースで Recovery Manager の CONFIGURE ARCHIVELOG DELETION POLICY コマンドの再発行が必要になる場合があります アーカイブ REDO ログ ファイルのバックアップ サイトが同一の場合 何も実行する必要はありません それ以外の場合は バックアップが作成されないデータベースで CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY 文を発行し バックアップが作成されるデータベースで CONFIGURE ARCHIVELOG DELETION POLICY TO NONE 文を発行して ARCHIVELOG 削除ポリシーを切り替える必要があります 現行の削除ポリシーの表示 データベースに対する現行の設定 (APPLIED ON STANDBY CLEAR NONE) を確認するには 次の問合せを発行します SELECT NAME, VALUE FROM V$RMAN_CONFIGURATION WHERE NAME LIKE '%ARCHIVELOG DELETION POLICY%'; NAME VALUE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY 次のように Recovery Manager の SHOW ARCHIVELOG DELETION POLICY コマンドを使用して既存の構成を検索することもできます RMAN> SHOW ARCHIVELOG DELETION POLICY RMAN configuration parameters are: CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY; Recovery Manager を使用したファイルのバックアップおよびリストア 10-11

206 その他のバックアップ状況 Oracle Data Guard 概要および管理

207 11 SQL Apply を使用した Oracle Database のアップグレード Oracle Database 10g リリース 1( ) からは ロジカル スタンバイ データベースを使用して Oracle Database 10g ソフトウェアのローリング アップグレードを実行できます ローリング アップグレード中は プライマリ データベースとロジカル スタンバイ データベースで異なるリリースの Oracle データベースを実行しながら プライマリ データベースの停止時間を最短に抑えて各リリースを 1 度に 1 つずつアップグレードできます 注意 : この章では ロジカル スタンバイ データベースが存在する場合にローリング アップグレードを行って停止時間を最短に抑える方法を説明します 2 つ目の方法は B.3 項 ロジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード に説明されている従来からのアップグレード処理で アップグレード処理中に停止時間が発生します 完全なアップグレードを実行するには どちらか一方の方法の手順のみを使用してください 両方の方法を使用したり 2 つの方法の手順を組み合せようとしないでください この章の各手順では Oracle データベースのアップグレード中の停止時間を最短に抑える方法について説明します この章は 次の項目で構成されています SQL Apply を使用するローリング アップグレードのメリット SQL Apply を使用してローリング アップグレードを実行するための要件 アップグレード手順に使用する図と表記規則 アップグレードの準備 データベースのアップグレード SQL Apply を使用した Oracle Database のアップグレード 11-1

208 SQL Apply を使用するローリング アップグレードのメリット 11.1 SQL Apply を使用するローリング アップグレードのメリット SQL Apply を使用してローリング アップグレードを実行する方法には 次のように複数のメリットがあります データベースの停止時間が最短で済みます 停止時間全体がスイッチオーバーの実行所要時間と同様に短時間です PL/SQL の再コンパイルによるアプリケーションの停止時間は発生しません プライマリ データベースに影響を与えずに アップグレード後のデータベース リリースを検証できます 11.2 SQL Apply を使用してローリング アップグレードを実行するための要件 ローリング アップグレード手順の要件は 次のとおりです Oracle Database リリース x を実行中のプライマリ データベースと Oracle Database リリース y を実行中のロジカル スタンバイ データベース データベースが Data Guard Broker 構成に含まれていないこと Broker 構成からデータベースを削除する方法の詳細は Oracle Data Guard Broker を参照してください Data Guard の保護モードが最大可用性モードまたは最大パフォーマンス モードに設定されていること 現在の保護モード設定を確認するには V$DATABASE ビューの PROTECTION_LEVEL 列を問い合せます ロジカル スタンバイ データベースの宛先の LOG_ARCHIVE_DEST_n 初期化パラメータが OPTIONAL に設定されていること これにより ロジカル スタンバイ データベースのアップグレード中もプライマリ データベースで処理を進行できます 関連項目 : LOG_ARCHIVE_DEST_n 初期化パラメータの MANDATORY および OPTIONAL 属性の使用方法の詳細は Oracle Data Guard 概要および管理 を参照してください COMPATIBLE 初期化パラメータがアップグレード前のソフトウェア リリースと一致していること つまり リリース x からリリース y へのローリング アップグレードでは プライマリ データベースとスタンバイ データベースの両方で COMPATIBLE 初期化パラメータをリリース x に設定する必要があります 11-2 Oracle Data Guard 概要および管理

209 アップグレードの準備 11.3 アップグレード手順に使用する図と表記規則 図 11-1 に アップグレード開始前の Data Guard 構成を示します この例では プライマリ データベースとロジカル スタンバイ データベースでは 同じリリースの Oracle Database ソフトウェアが実行されています 図 11-1 アップグレード前の Data Guard 構成 アップグレード処理中に Data Guard 構成は何度か混合データベース リリースで動作します リリース間にまたがるデータ保護は使用できません これらの手順では データ保護を提供するために Data Guard 構成に第 2 のスタンバイ データベースがある場合を考えます アップグレード手順と図では データベースを プライマリ データベース と スタンバイ データベース ではなく データベース A および データベース B と呼びます これは アップグレード手順の実行中にデータベースのロールが切り替わるためです 最初は 図 11-1 に示すようにデータベース A がプライマリ データベースでデータベース B がロジカル スタンバイ データベースです 11.4 アップグレードの準備 プライマリ データベースとスタンバイ データベースをアップグレードできるように準備する手順は 次のとおりです 手順 1 COMPATIBLE 初期化パラメータを設定する COMPATIBLE 初期化パラメータに アップグレード前のプライマリ データベースで実行されている Oracle Database ソフトウェアのリリース番号が指定されていることを確認します たとえば プライマリ データベースでリリース 10.1 が実行されている場合は COMPATIBLE 初期化パラメータを両方のデータベースで 10.1 に設定します COMPATIBLE パラメータは スタンバイ データベースで設定してからプライマリ データベースで設定します 手順 2 サポートされない表に関する情報を取得するデータベース A で PL/SQL プロシージャ DBMS_LOGSTDBY を使用して プライマリ データベースで実行中でロジカル スタンバイ データベースではサポートされないトランザクションの情報を取得します 次のプロシージャを実行して情報を取得し DBA_LOGSTDBY_EVENTS 表にイベントとして記録します EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',DBMS_LOGSTDBY.MAX_EVENTS); EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE'); SQL Apply を使用した Oracle Database のアップグレード 11-3

210 アップグレードの準備 注意 : Oracle Database 10g リリース 1(10.1) では DBMS_LOGSTDBY.MAX_EVENTS 定数は DBMS_LOGSTDBY_PUBLIC.MAX_EVENTS と呼ばれていました この 2 つの定数の効果は同じですが リリース 2(10.2) では DBMS_LOGSTDBY_PUBLIC パッケージが廃止され 定数の定義が DBMS_LOGSTDBY パッケージに移動されています これらの PL/SQL プロシージャをデータベース A で実行しても プライマリ データベースには影響しません ただし ロジカル スタンバイ データベース ( およびロジカル スタンバイ データベース制御ファイル ) を作成する前に これらのプロシージャをプライマリ データベースで実行すると 手順 4 でロジカル スタンバイ データベースを作成するときに自動的に設定が転送されます アップグレード手順に使用できるロジカル スタンバイ データベース ( データベース B) が存在している場合は 両方のデータベースで PL/SQL コマンド DBMS_LOGSTDBY を発行してから手順 3 にスキップします 関連項目 : DBMS_LOGSTDBY プロシージャの詳細は Oracle Database PL/SQL パッケージ プロシージャおよびタイプ リファレンス を参照してください 手順 3 サポートされないデータ型および記憶域属性を識別するプライマリ データベースでサポートされないデータベース オブジェクトを識別し その処理方法を決定する手順は 次のとおりです 1. 表についてサポートされないデータ型および記憶域属性を識別します 付録 C ロジカル スタンバイ データベースでサポートされるデータ型および DDL を参照し サポートされないデータ型および記憶域属性のリストを確認します プライマリ データベースで DBA_LOGSTDBY_UNSUPPORTED および DBA_LOGSTDBY_SKIP ビューを問い合せます プライマリ データベースで表示された表およびスキーマに対して行われた変更は ロジカル スタンバイ データベースに適用されません 次の問合せを実行すると サポートされない表のリストの例が表示されます SQL> SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED; OWNER TABLE_NAME OE CATEGORIES_TAB OE CUSTOMERS OE WAREHOUSES PM ONLINE_MEDIA PM PRINT_MEDIA SCOTT MYCOMPRESS SH MVIEW$_EXCEPTIONS 7 rows selected. SQL> SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP 2 WHERE STATEMENT_OPT = 'INTERNAL SCHEMA'; OWNER CTXSYS DBSNMP DIP ORDPLUGINS ORDSYS OUTLN SI_INFORMTN_SCHEMA SYS 11-4 Oracle Data Guard 概要および管理

211 アップグレードの準備 SYSTEM WMSYS 10 rows selected. 2. サポートされない表の処理方法を決定します サポートされないオブジェクトがプライマリ データベースで変更されると 次のいずれかの方法でアップグレードを実行できるようになる可能性があります アップグレード手順の実行所要時間中は サポートされない表に対する変更を一時的に停止します サポートされない表に対する変更を防止できる場合は SQL Apply を使用してアップグレード手順を実行できる場合があります この方法では ロジカル スタンバイ制御ファイルの作成時からアップグレード完了時までは サポートされない表に対するユーザー変更を禁止する必要があります DBA_LOGSTDBY_EVENTS ビューでトランザクション アクティビティを監視し 最初のスイッチオーバーの実行時までアップグレードを中断できます ( 必要な場合 ) ユーザーがサポートされない表を変更していないときにアップグレードを実行します 要件の異なる複数部門をサポートするロジカル スタンバイ データベースの場合は ユーザーによるデータベース表へのアクセス方法がわかっていれば SQL Apply を使用してアップグレードを実行できます たとえば 給与管理部門はオブジェクト表を更新しますが この部門がデータベースを更新するのは月曜から金曜のみであるとします 一方 カスタマ サービス部門は 1 日 24 時間 1 週 7 日間のデータベース アクセスを必要としますが 使用するのはサポートされるデータ型および表のみであるとします この使用例では 週末にアップグレードを実行できます サポートされない表に対する変更をアップグレード中に防止できない場合 発生したサポートされないトランザクションはロジカル スタンバイ データベースの DBA_LOGSTDBY_EVENTS 表に記録されます アップグレードの完了後に Oracle Data Pump またはエクスポート / インポート ユーティリティを使用して 変更された表をアップグレード後のデータベースにインポートできます 変更された表のサイズにより データベース操作が使用できなくなる期間が決定するため データをエクスポートしてスタンバイ データベースにインポートするには表が大きすぎないかどうかを判断する必要があります たとえば 4TB の表は エクスポート / インポート処理に適した候補ではありません 注意 : アプリケーションのデータ型がサポートされないためにロジカル スタンバイ データベースを使用できない場合は Oracle Database アップグレード ガイド の説明に従ってアップグレードを実行してください 手順 4 ロジカル スタンバイ データベースを作成するロジカル スタンバイ データベースを作成するには 第 4 章の手順に従います 停止時間を最短に抑えるために ロジカル スタンバイ データベースでスタンバイ REDO ログを構成することをお薦めします 注意 : すでにロジカル スタンバイ データベースが存在する場合は 11.5 項 データベースのアップグレード に進んでアップグレード手順を開始します SQL Apply を使用した Oracle Database のアップグレード 11-5

212 データベースのアップグレード 11.5 データベースのアップグレード この項では ロジカル スタンバイ データベースとプライマリ データベースをアップグレードする手順について説明します 表 11-1 に手順を示します 表 11-1 Oracle Database ソフトウェアをアップグレードする手順 手順説明 1 SQL Apply を停止してロジカル スタンバイ データベースをアップグレードする 2 SQL Apply を再開する 3 アップグレード後のスタンバイ データベースでイベントを監視する 4 スイッチオーバーを開始する 5 サポートされないオブジェクトがアップグレード中に変更されたかどうかを判断する 6 スイッチオーバーを完了してユーザー アプリケーションをアクティブ化する 7 前のプライマリ データベースをアップグレードする 8 SQL Apply を開始する 9 必要な場合は 両方のデータベースの互換性レベルを上げる 10 新規ロジカル スタンバイ データベースでイベントを監視する 11 必要な場合は 再度スイッチオーバーを実行する 注意 : ビジネスにプライマリ データベースをサポートするロジカル スタンバイ データベースが不要な場合は 手順 7 ~ 11 をスキップできます 手順 1 SQL Apply を停止してロジカル スタンバイ データベースをアップグレードするアップグレードを開始するには SQL Apply を停止して ロジカル スタンバイ データベース ( データベース B) の Oracle Database ソフトウェアをリリース y にアップグレードします SQL Apply を停止するには データベース B で次の文を発行します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Oracle Database ソフトウェアをアップグレードするには 該当する Oracle Database リリースの Oracle Database アップグレード ガイド を参照してください 図 11-2 に リリース x を実行中のデータベース A とリリース y を実行中のデータベース B を示します アップグレード中は REDO データがプライマリ システムに蓄積されます 図 11-2 ロジカル スタンバイ データベースのリリースのアップグレード 11-6 Oracle Data Guard 概要および管理

213 データベースのアップグレード 手順 2 SQL Apply を再開する SQL Apply を再開し データベース A ではリリース x データベース B ではリリース y で動作させます SQL Apply を開始するには データベース B で次の文を発行します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; プライマリ システムに蓄積された REDO データは 新しくアップグレードしたロジカル スタンバイ データベースに自動的に転送され 適用されます Data Guard 構成では アップグレード後の Oracle Database ソフトウェア リリースが本番環境で正常に実行されるかどうかを確認するために 任意の期間だけ図 11-3 に示す混合リリースを実行できます 図 11-3 混合リリースの実行 データベース B がデータベース A とどの程度迅速に一致するかを監視するには 次のようにデータベース B で V$LOGSTDBY_PROGRESS ビューを問い合せます SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS'; Session altered. SQL> SELECT SYSDATE, APPLIED_TIME FROM V$LOGSTDBY_PROGRESS; SYSDATE APPLIED_TIME JUN-05 17:07:06 27-JUN-05 17:06:50 手順 3 アップグレード後のスタンバイ データベースでイベントを監視する頻繁に DBA_LOGSTDBY_EVENTS ビューを問い合せ データベース B に適用されなかった DDL 文と DML 文があるかどうかを確認する必要があります 例 11-1 に イベントの監視により 2 つのデータベースにおける潜在的な差異を把握する方法を示します 例 11-1 DBA_LOGSTDBY_EVENTS を使用したイベントの監視 SQL> SET LONG 1000 SQL> SET PAGESIZE 180 SQL> SET LINESIZE 79 SQL> SELECT EVENT_TIMESTAMP, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS ORDER BY EVENT_TIMESTAMP; EVENT_TIMESTAMP EVENT STATUS SQL Apply を使用した Oracle Database のアップグレード 11-7

214 データベースのアップグレード 24-MAY PM CREATE TABLE SYSTEM.TST (one number) ORA-16226: サポートされていないため DDL はスキップされました 24-MAY PM "SYSTEM"."TST" ORA-16129: サポートされていない dml を検出しました 前述の例で 各エラーの意味は次のとおりです ORA エラーは サポートできない DDL 文を示します この場合は 内部スキーマに属しているためにサポートできません ORA エラーは 適用されなかった DML 文を示します この種のエラーは データベース A で発生した変更の一部がデータベース B に適用されなかったことを示します この時点で アップグレード手順を続行するかどうかを判断する必要があります ロジカル スタンバイ データベースとプライマリ データベース間で この差異が許容可能であることが確実な場合は アップグレード手順を続行します 不確実な場合は アップグレード手順を中断してデータベース B を破棄し 別の時点でアップグレード手順を実行します 手順 4 スイッチオーバーを開始するアップグレード後のデータベース ソフトウェアが正常に動作していることを確認した後 データベース A で次の文を発行してスイッチオーバーを実行し データベース ロールを元に戻します SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY; この文は 既存のトランザクションの完了まで待機する必要があるかどうかに応じて 数秒しかかからないことがあります 引き続きデータベース A に接続しているユーザーは 即時にログオフしてデータベース B に再接続する必要があります 注意 : データベース A がプライマリ データベースのときに そこでサポートされない表またはパッケージに対するアクティビティを一時停止した場合 最終的にデータベース A に切り替える計画であれば データベース B がプライマリ データベースになっている間にデータベース B でも引き続き同じアクティビティを一時停止する必要があります 手順 5 サポートされないオブジェクトがアップグレード中に変更されたかどうかを判断する手順 3 の アップグレード後のスタンバイ データベースでイベントを監視する では 変更中のサポートされない表をリストする方法について説明しました プライマリ データベースでサポートされない DML 文が発行された場合は ( 例 11-1 を参照 ) Oracle Data Pump などのインポート ユーティリティを使用して 各表の最新バージョンをインポートします 注意 : インポートする表は 11.4 項 アップグレードの準備 の手順 3 に示したデータ型の要件を満たしている必要があります たとえば 次のインポート コマンドは scott.emp 表を切り捨て 前のプライマリ データベース (A) と一致するデータを移入します IMPDP SYSTEM/MANAGER NETWORK_LINK=DATABASEA TABLES=SCOTT.EMP TABLE_EXIST_ ACTION=TRUNCATE 11-8 Oracle Data Guard 概要および管理

215 データベースのアップグレード 手順 6 スイッチオーバーを完了してユーザー アプリケーションをアクティブ化するアップグレード後のデータベース ソフトウェアが正常に動作していることを確認した後 スイッチオーバーを完了してデータベース ロールを元に戻します 1. データベース B で 次のように V$DATABASE ビューの SWITCHOVER_STATUS 列を問い合せます SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS TO PRIMARY 2. SWITCHOVER_STATUS 列に TO PRIMARY が表示される場合は データベース B で次の文を発行してスイッチオーバーを完了します SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL PRIMARY; 3. 現在はプライマリ データベース ロールで実行中のデータベース B で ユーザー アプリケーションとサービスをアクティブ化します スイッチオーバー後は 新規データベース ソフトウェア リリースを実行中の新規プライマリ データベース (B) から旧ソフトウェア リリースを実行中の新規スタンバイ データベース (A) には REDO データを送信できません これは次のことを意味します REDO データは 新規プライマリ データベースに蓄積されます 新規プライマリ データベースは この時点では保護されていません 図 11-4 に 前はスタンバイ データベース ( リリース y を実行 ) で現在はプライマリ データベースになっているデータベース B と 前はプライマリ データベース ( リリース x を実行 ) で現在はスタンバイ データベースになっているデータベース A を示します ユーザーはデータベース B に接続されます データベース B がプライマリ データベースとして適切に機能でき ビジネスにプライマリ データベースをサポートするためのロジカル スタンバイ データベースが不要な場合 これでローリング アップグレード処理は完了です ユーザーにデータベース B へのログインとそこでの作業開始を許可し 問題のない時点でデータベース A を破棄します それ以外の場合は 手順 7 に進みます 図 11-4 スイッチオーバー後 SQL Apply を使用した Oracle Database のアップグレード 11-9

216 データベースのアップグレード 手順 7 前のプライマリ データベースをアップグレードするデータベース A では引き続きリリース x が実行されており アップグレードして SQL Apply を開始するまでは データベース B からの REDO データを適用できません Oracle Database ソフトウェアのアップグレードの詳細は 該当する Oracle Database リリースの Oracle Database アップグレード ガイド を参照してください 図 11-5 に 両方のデータベースがアップグレードされた後のシステムを示します 図 11-5 両方のデータベースがアップグレードされた後 手順 8 SQL Apply を開始するデータベース A で次の文を発行して SQL Apply を開始し 必要に応じてデータベース B へのデータベース リンクを作成します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY db_link_to_b; 注意 : この文を発行する前にデータベース リンクを作成するのは データベース リンクが設定されていない場合のみです データベース A で SQL Apply を開始すると プライマリ データベース (B) に蓄積された REDO データがロジカル スタンバイ データベース (B) に送信されます すべての REDO データがスタンバイ データベースで使用可能になると プライマリ データベースはデータ消失から保護されます 手順 9 必要な場合は 両方のデータベースの互換性レベルを上げる COMPATIBLE 初期化パラメータを設定して 両方のデータベースの互換性レベルを上げます COMPATIBLE パラメータは スタンバイ データベースで設定してからプライマリ データベースで設定します COMPATIBLE 初期化パラメータの詳細は Oracle Database リファレンス を参照してください 手順 10 新規ロジカル スタンバイ データベースでイベントを監視するデータベース B で実行されるすべての変更がロジカル スタンバイ データベース (A) に適切に適用されることを確認するために 手順 3 でデータベース A に対して実行した場合と同様に DBA_LOGSTDBY_EVENTS ビューを頻繁に問い合せる必要があります ( 例 11-1 を参照 ) 変更が行われたためにデータベース A が既存のプライマリ データベースのコピーとして無効になった場合は データベース A を破棄し かわりに新規のロジカル スタンバイ データベースを作成できます 詳細は 第 4 章 ロジカル スタンバイ データベースの作成 を参照してください Oracle Data Guard 概要および管理

217 データベースのアップグレード 手順 11 必要な場合は 再度スイッチオーバーを実行する必要な場合は データベース A がプライマリ データベース ロールで再実行されるように ( 図 11-1 を参照 ) データベースのスイッチオーバーを再度実行します 関連項目 : 項 ロジカル スタンバイ データベースが関与するスイッチオーバー SQL Apply を使用した Oracle Database のアップグレード 11-11

218 データベースのアップグレード Oracle Data Guard 概要および管理

219 12 Data Guard の使用例 この章では Data Guard 構成の管理中に遭遇する可能性がある例を説明します 使用例はそれぞれ ユーザー固有の環境に適応できます 表 12-1 は この章で説明する使用例のリストです 表 12-1 Data Guard の使用例 参照先 使用例 12.1 項アーカイブ先の設定および確認 12.2 項ロールの推移に最適なスタンバイ データベースの選択 12.3 項新規プライマリ データベースをサポートするロジカル スタンバイ データベースの構成 12.4 項フェイルオーバー後のフラッシュバック データベースの使用 12.5 項 Open Resetlogs 文の発行後のフラッシュバック データベースの使用 12.6 項フィジカル スタンバイ データベースを使用した読取り / 書込みテストとレポート生成 12.7 項 Recovery Manager の増分バックアップによるフィジカル スタンバイ データベースのロールフォワード 12.8 項タイム ラグのあるフィジカル スタンバイ データベースの使用 12.9 項ネットワーク障害のリカバリ 項 NOLOGGING 句を指定した後のリカバリ 項手動によるアーカイブ ギャップの解決 項 OMF または ASM を使用するスタンバイ データベースの作成 Data Guard の使用例 12-1

220 アーカイブ先の設定および確認 12.1 アーカイブ先の設定および確認 次の各項で ロール固有のアーカイブを使用可能および使用不可にする LOG_ARCHIVE_DEST_n 初期化パラメータとその他の関連パラメータの設定方法を説明します プライマリ データベースおよびフィジカル スタンバイ データベースの構成 プライマリ データベースおよびロジカル スタンバイ データベースの構成 フィジカルおよびロジカル スタンバイ データベースの構成 各宛先について現行の VALID_FOR 属性設定の確認 プライマリ データベースおよびフィジカル スタンバイ データベースの構成 図 12-1 に chicago プライマリ データベース boston フィジカル スタンバイ データベース および各システムの初期化パラメータを示します 図 12-1 ロールの推移前のプライマリおよびフィジカル スタンバイ データベース 表 12-2 に 図 12-1 で示された構成の初期化パラメータを示します 表 12-2 プライマリ データベースとフィジカル スタンバイ データベースの初期化パラメータの設定 Chicago データベース ( プライマリ ロール ) DB_UNIQUE_NAME=chicago LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(chicago,boston)' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=boston VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE STANDBY_ARCHIVE_DEST=/arch1/chicago/ REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE Boston データベース ( フィジカル スタンバイ データベース ロール ) DB_UNIQUE_NAME=boston LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(chicago,boston)' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=chicago VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE STANDBY_ARCHIVE_DEST=/arch1/boston/ REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE 12-2 Oracle Data Guard 概要および管理

221 アーカイブ先の設定および確認 次の表で 図 12-1 で示されたアーカイブ プロセスについて説明します LOG_ARCHIVE_DEST_1 LOG_ARCHIVE_DEST_2 STANDBY_ARCHIVE_DEST Chicago データベース ( プライマリ ロール ) /arch1/chicago/ 内のローカル アーカイブ REDO ログ ファイルに REDO データをアーカイブするよう指示 リモート フィジカル スタンバイ データベース boston に REDO データを転送するよう指示 無視 chicago がスタンバイ ロールで稼働している場合にのみ有効 Boston データベース ( フィジカル スタンバイ ロール ) /arch1/boston/ 内のローカル アーカイブ REDO ログ ファイルに REDO データをアーカイブするよう指示 無視 boston がプライマリ ロールで稼働している場合にのみ有効 ローカルの /arch1/boston/ ディレクトリ内のアーカイブ REDO ログ ファイルに REDO データをアーカイブするよう指示 図 12-2 に スイッチオーバー後の同一構成を示します 図 12-2 ロールの推移後のプライマリおよびフィジカル スタンバイ データベース 次の表で 図 12-2 で示されたアーカイブ プロセスについて説明します LOG_ARCHIVE_DEST_1 LOG_ARCHIVE_DEST_2 STANDBY_ARCHIVE_DEST Chicago データベース ( フィジカル スタンバイ ロール ) ローカルの /arch1/chicago/ ディレクトリに REDO データをアーカイブするよう指示 無視 chicago がプライマリ ロールで稼働している場合にのみ有効 ローカルの /arch1/chicago/ ディレクトリ内のアーカイブ REDO ログ ファイルに REDO データをアーカイブするよう指示 Boston データベース ( プライマリ ロール ) /arch1/boston/ 内のローカル アーカイブ REDO ログ ファイルに REDO データをアーカイブするよう指示 リモート フィジカル スタンバイ宛先 chicago に REDO データを転送するよう指示 無視 boston がスタンバイ ロールで稼働している場合にのみ有効 Data Guard の使用例 12-3

222 アーカイブ先の設定および確認 プライマリ データベースおよびロジカル スタンバイ データベースの構成 図 12-3 に プライマリ ロールで稼働している chicago データベース ロジカル スタンバイ ロールで稼働している denver データベース および各システムの初期化パラメータを示します アクティブでないコンポーネントはグレー表示されています 図 12-3 プライマリ データベースおよびロジカル スタンバイ データベースの宛先の構成 表 12-3 に 図 12-3 で示された構成の初期化パラメータを示します 表 12-3 プライマリ データベースとロジカル スタンバイ データベースの初期化パラメータの設定 Chicago データベース ( プライマリ ロール ) DB_UNIQUE_NAME=chicago LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(chicago,denver)' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_2= 'LOCATION=/arch2/chicago/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_3= 'SERVICE=denver VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=denver' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE STANDBY_ARCHIVE_DEST=/arch2/chicago/ REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE Denver データベース ( ロジカル スタンバイ データベース ロール ) DB_UNIQUE_NAME=denver LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(chicago,denver)' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/denver/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver' LOG_ARCHIVE_DEST_2= 'LOCATION=/arch2/denver/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver' LOG_ARCHIVE_DEST_3= 'SERVICE=chicago VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE STANDBY_ARCHIVE_DEST=/arch2/denver/ REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE 12-4 Oracle Data Guard 概要および管理

223 アーカイブ先の設定および確認 次の表で 図 12-3 で示されたアーカイブ プロセスについて説明します LOG_ARCHIVE_DEST_1 LOG_ARCHIVE_DEST_2 LOG_ARCHIVE_DEST_3 STANDBY_ARCHIVE_DEST Chicago データベース ( プライマリ ロール ) /arch1/chicago/ 内のローカル アーカイブ REDO ログ ファイルにローカル オンライン REDO ログ ファイルからプライマリ データベースによって生成された REDO データをアーカイブするよう指示 無視 chicago がスタンバイ ロールで稼働している場合にのみ有効 ( スイッチオーバーを実行するには このサイトでスタンバイ REDO ログを構成する必要があります ) リモート ロジカル スタンバイ宛先 denver に REDO データを転送するよう指示 無視 chicago がスタンバイ ロールで稼働している場合にのみ有効 Denver データベース ( ロジカル スタンバイ ロール ) /arch1/denver/ 内のローカル アーカイブ REDO ログ ファイルにローカル オンライン REDO ログ ファイルからロジカル スタンバイ データベースによって生成された REDO データをアーカイブするよう指示 /arch2/denver/ 内のローカル アーカイブ REDO ログ ファイルにスタンバイ REDO ログ ファイルからの REDO データをアーカイブするよう指示 無視 denver がプライマリ ロールで稼働している場合にのみ有効 /arch2/denver/ 内のアーカイブ REDO ログ ファイルにプライマリ データベースから受信した REDO データを直接アーカイブするよう指示 フィジカル スタンバイ データベースと異なり ロジカル スタンバイ データベースは REDO データを生成し 複数のログ ファイル ( オンライン REDO ログ ファイル アーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイル ) を持つオープン状態のデータベースです 次のものに対し 別々のローカル宛先を指定することをお薦めします ロジカル スタンバイ データベースによって生成された REDO データを格納するアーカイブ REDO ログ ファイル 図 12-3 では これは LOG_ARCHIVE_DEST_ 1=LOCATION=/arch1/denver 宛先として構成されています プライマリ データベースから受信した REDO データを格納するアーカイブ REDO ログ ファイル 図 12-3 では これは LOG_ARCHIVE_DEST_2=LOCATION=/arch2/denver 宛先として構成されています 図 12-3 では 次の目的に対し STANDBY_ARCHIVE_DEST パラメータは同じ位置が構成されています スタンバイ REDO ログ ファイルがいっぱいになると プライマリ データベースから受信した REDO データは この位置のアーカイブ REDO ログ ファイルに直接アーカイブされます (5.7.1 項で説明 ) アーカイブ ギャップが存在する場合 他のデータベースから受信したアーカイブ REDO ログ ファイルは この位置にコピーされます (5.8 項で説明 ) 図 12-3( および図 12-4) で示される構成例にはフィジカル スタンバイ データベースが含まれていないため ロジカル スタンバイ データベースを使用したスイッチオーバー用に LOG_ARCHIVE_DEST_3 宛先が構成によって設定されます 図 12-4 に スイッチオーバー後の同一構成を示します Data Guard の使用例 12-5

224 アーカイブ先の設定および確認 図 12-4 ロールの推移後のプライマリおよびロジカル スタンバイ データベース 次の表で 図 12-4 で示されたアーカイブ プロセスについて説明します LOG_ARCHIVE_DEST_1 LOG_ARCHIVE_DEST_2 LOG_ARCHIVE_DEST_3 Chicago データベース ( ロジカル スタンバイ ロール ) /arch1/chicago/ 内のローカル アーカイブ REDO ログ ファイルにローカル オンライン REDO ログ ファイルからロジカル スタンバイ データベースによって生成された REDO データをアーカイブするよう指示 /arch2/chicago/ 内のアーカイブ REDO ログ ファイルにスタンバイ REDO ログ ファイルからの REDO データをアーカイブするよう指示 無視 chicago がプライマリ ロールで稼働している場合にのみ有効 STANDBY_ARCHIVE_DEST /arch2/chicago/ 内のアーカイブ REDO ログ ファイルにプライマリ データベースから受信した REDO データを直接アーカイブするよう指示 Denver データベース ( プライマリ ロール ) /arch1/denver/ 内のローカル アーカイブ REDO ログ ファイルにローカル オンライン REDO ログ ファイルからの REDO データをアーカイブするよう指示 無視 denver がスタンバイ ロールで稼働している場合にのみ有効 リモート ロジカル スタンバイ宛先 chicago に REDO データを転送するよう指示 無視 denver がスタンバイ ロールで稼働している場合にのみ有効 12-6 Oracle Data Guard 概要および管理

225 アーカイブ先の設定および確認 フィジカルおよびロジカル スタンバイ データベースの構成 図 12-5 に プライマリ ロールで稼働している chicago データベース フィジカル スタンバイ ロールで稼働している boston データベース およびロジカル スタンバイ データベース ロールで稼働している denver データベースを示します 初期化パラメータは各システムの下に示されています グレー表示されているコンポーネントは そのデータベースの現行ロールではアクティブないことを示します この例は スイッチオーバーが chicago と boston の間でのみ発生することを前提としています この構成では denver ロジカル スタンバイ データベースはレポート用データベースのみを目的としています denver は スイッチオーバーの対象にはならず プライマリ ロールで稼働することもありません 図 12-5 フィジカルおよびロジカル スタンバイ データベースを備えたプライマリ データベースの構成 表 12-4 に 図 12-5 で示されたデータベースの初期化パラメータを示します 表 12-4 プライマリ データベース フィジカル スタンバイ データベースおよびロジカル スタンバイ データベースの初期化パラメータ Boston データベース ( スタンバイ ロール ) DB_UNIQUE_NAME=boston LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(chicago,boston,denver)' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/ VALID_FOR=(ONLINE_ LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=denver VALID_FOR=(ONLINE_ LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=denver' LOG_ARCHIVE_DEST_3= 'SERVICE=chicago VALID_FOR= (ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE STANDBY_ARCHIVE_DEST=/arch1/boston/ REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE Chicago データベース ( プライマリ ロール ) DB_UNIQUE_NAME=chicago LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(chicago,boston,denver)' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/ VALID_FOR=(ONLINE_ LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_2= 'SERVICE=denver VALID_FOR=(ONLINE_ LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=denver' LOG_ARCHIVE_DEST_3= 'SERVICE=boston VALID_FOR= (ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE STANDBY_ARCHIVE_DEST=/arch1/chicago/ REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE Denver データベース ( スタンバイ ロール ) DB_UNIQUE_NAME=denver LOG_ARCHIVE_CONFIG= 'DG_ CONFIG=(chicago,boston,denver)' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/denver/ VALID_FOR=(ONLINE_ LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver' LOG_ARCHIVE_DEST_2= 'LOCATION=/arch2/denver/ VALID_FOR=(STANDBY_ LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE STANDBY_ARCHIVE_DEST=/arch2/denver/ REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE Data Guard の使用例 12-7

226 アーカイブ先の設定および確認 次の表で 図 12-5 で示されたアーカイブ プロセスについて説明します LOG_ARCHIVE_DEST_1 LOG_ARCHIVE_DEST_2 LOG_ARCHIVE_DEST_3 Chicago データベース ( プライマリ ロール ) /arch1/chicago/ 内のローカル アーカイブ REDO ログ ファイルにオンライン REDO ログ ファイルからの REDO データをアーカイブするよう指示 リモート ロジカル スタンバイ宛先 denver に REDO データを転送するよう指示 リモート フィジカル スタンバイ宛先 boston に REDO データを転送するよう指示 STANDBY_ARCHIVE_DEST 無視 スタンバイ ロールでのみ有効 Boston データベース ( スタンバイ ロール ) /arch1/boston/ 内のローカル アーカイブ REDO ログ ファイルにスタンバイ REDO ログ ファイルからの REDO データをアーカイブするよう指示 無視 boston がプライマリ ロールで稼働している場合にのみ有効 無視 boston がプライマリ ロールで稼働している場合にのみ有効 /arch1/boston/ 内のアーカイブ REDO ログ ファイルにプライマリ データベースから受信した REDO データを直接アーカイブするよう指示 Denver データベース ( スタンバイ ロール ) /arch1/denver/ 内のローカル アーカイブ REDO ログ ファイルにローカル オンライン REDO ログ ファイルからロジカル スタンバイ データベースによって生成された REDO データをアーカイブするよう指示 /arch2/denver/ 内のローカル アーカイブ REDO ログ ファイルにスタンバイ REDO ログ ファイルからの REDO データをアーカイブするよう指示 このデータベースに対しては定義なし /arch2/denver/ 内のアーカイブ REDO ログ ファイルにプライマリ データベースから受信した REDO データを直接アーカイブするよう指示 図 12-6 に スイッチオーバーによって chicago データベースがスタンバイ ロールに変更され boston データベースがプライマリ ロールに変更された後の同一構成を示します 図 12-6 ロールの推移後のプライマリ フィジカルおよびロジカル スタンバイ データベース 12-8 Oracle Data Guard 概要および管理

227 アーカイブ先の設定および確認 次の表で 図 12-6 で示されたアーカイブ プロセスについて説明します LOG_ARCHIVE_DEST_1 LOG_ARCHIVE_DEST_2 LOG_ARCHIVE_DEST_3 STANDBY_ARCHIVE_DEST Chicago データベース ( スタンバイ ロール ) /arch1/chicago/ 内のローカル アーカイブ REDO ログ ファイルにスタンバイ REDO ログ ファイルからの REDO データをアーカイブするよう指示 無視 chicago がプライマリ ロールで稼働している場合にのみ有効 無視 chicago がプライマリ ロールで稼働している場合にのみ有効 /arch1/chicago/ 内のアーカイブ REDO ログ ファイルにプライマリ データベースから受信した REDO データを直接アーカイブするよう指示 Boston データベース ( プライマリ ロール ) /arch1/boston/ 内のローカル アーカイブ REDO ログ ファイルにオンライン REDO ログ ファイルからの REDO データをアーカイブするよう指示 リモート ロジカル スタンバイ宛先 denver に REDO データを転送するよう指示 リモート フィジカル スタンバイ宛先 chicago に REDO データを転送するよう指示 無視 スタンバイ ロールでのみ有効 Denver データベース ( スタンバイ ロール ) /arch1/denver/ 内のローカル アーカイブ REDO ログ ファイルにローカル オンライン REDO ログ ファイルからロジカル スタンバイ データベースによって生成された REDO データをアーカイブするよう指示 /arch2/denver/ 内のローカル アーカイブ REDO ログ ファイルにスタンバイ REDO ログ ファイルからの REDO データをアーカイブするよう指示 このデータベースに対しては定義なし /arch2/denver/ 内のアーカイブ REDO ログ ファイルにプライマリ データベースから受信した REDO データを直接アーカイブするよう指示 各宛先について現行の VALID_FOR 属性設定の確認 Data Guard 構成の各宛先で 現行の VALID_FOR 属性の設定が有効であるかを即時確認するには 例 12-1 に示すように V$ARCHIVE_DEST ビューを問い合せます 例 12-1 V$ARCHIVE_DEST ビューでの VALID_FOR 情報の検索 SQL> SELECT DEST_ID,VALID_TYPE,VALID_ROLE,VALID_NOW FROM V$ARCHIVE_DEST; DEST_ID VALID_TYPE VALID_ROLE VALID_NOW ALL_LOGFILES ALL_ROLES YES 2 STANDBY_LOGFILE STANDBY_ROLE WRONG VALID_TYPE 3 ONLINE_LOGFILE STANDBY_ROLE WRONG VALID_ROLE 4 ALL_LOGFILES ALL_ROLES UNKNOWN 5 ALL_LOGFILES ALL_ROLES UNKNOWN 6 ALL_LOGFILES ALL_ROLES UNKNOWN 7 ALL_LOGFILES ALL_ROLES UNKNOWN 8 ALL_LOGFILES ALL_ROLES UNKNOWN 9 ALL_LOGFILES ALL_ROLES UNKNOWN 10 ALL_LOGFILES ALL_ROLES UNKNOWN 10 rows selected. Data Guard の使用例 12-9

228 ロールの推移に最適なスタンバイ データベースの選択 例 12-1 の各行は Data Guard 構成にある 10 の宛先のいずれかを表しています 最初の行は LOG_ARCHIVE_DEST_1 の VALID_FOR 属性が (ALL_LOGFILES,ALL_ROLES) に設定されていることを示します これは 常に有効な唯一のキーワード ペアです さらに重要な箇所は ビューの 2 行目と 3 行目です 現時点では両方とも無効ですが それぞれ異なる理由から無効になっています LOG_ARCHIVE_DEST_2 は (STANDBY_LOGFILES,STANDBY_ROLE) に設定されていますが このスタンバイ宛先にはスタンバイ REDO ログが実装されていないため WRONG VALID_TYPE が戻されます LOG_ARCHIVE_DEST_3 は (ONLINE_LOGFILES,STANDBY_ROLE) に設定されていますが この宛先は現在プライマリ データベース ロールで稼働しているため WRONG VALID_ROLE が戻されます 他の宛先はすべて UNKNOWN と表示されています これは 宛先が未定義であるか データベースは起動済およびマウント済であるがアーカイブが現在実行されていないことを示します これらの列および他の列の詳細は Oracle Database リファレンス の V$ARCHIVE_DEST ビューに関する項を参照してください 12.2 ロールの推移に最適なスタンバイ データベースの選択 次の各項では フェイルオーバーに最適なスタンバイ データベースの選択方法を段階的に説明します 例 : フェイルオーバーに最適なフィジカル スタンバイ データベース 例 : フェイルオーバーに最適なロジカル スタンバイ データベース 関連項目 : スイッチオーバーとフェイルオーバーのターゲット スタンバイ データベースの選択に関する一般的なガイドラインは 項を参照してください 構成にフィジカル スタンバイ データベースとロジカル スタンバイ データベースの両方が含まれている場合は 最適なフィジカル スタンバイ データベースを使用してロールの推移を実行することをお薦めします これには次の理由があります ロジカル スタンバイ データベースには プライマリ データベース内にあるデータのサブセットのみが含まれている可能性があります ロジカル スタンバイ データベースが関与するロールの推移では 既存のフィジカル スタンバイ データベースは ロールの推移が完了した後も Data Guard 構成に継続して含まれるように 新しいプライマリ データベースのコピーから再作成する必要があります これらの制限があるため ロジカル スタンバイ データベースをロールの推移のターゲットとして考慮するのは 次のような特別な状況の場合に限定してください 構成にロジカル スタンバイ データベースのみが含まれている場合 スタンバイ データベースのプライマリ ロールへの迅速なフェイルオーバーが重要で 構成内の最新のロジカル スタンバイ データベースが構成内の最新のフィジカル スタンバイ データベースに比較して大幅に更新されている場合 フィジカルまたはロジカル スタンバイ データベースの使用を決定すると ロールの推移のターゲットとして選択する特定のスタンバイ データベースは スタンバイ データベースにある最新のプライマリ データベースの変更量によって判断されます プライマリ データベースはスイッチオーバー中もアクセス可能な状態であるため データの消失はありません また スイッチオーバー中に使用されるスタンバイ データベースの選択によって影響を受けるのは スイッチオーバーの完了に必要な時間のみです ただし フェイルオーバーの場合 スタンバイ データベースの選択では データ消失に関するリスクの増加と スタンバイ データベースのプライマリ ロールへの推移に必要な時間との間でトレードオフが必要となります Oracle Data Guard 概要および管理

229 ロールの推移に最適なスタンバイ データベースの選択 例 : フェイルオーバーに最適なフィジカル スタンバイ データベース 障害時に DBA にとって最も重要な作業は より迅速でかつ安全なのはプライマリ データベースの修正か スタンバイ データベースへのフェイルオーバーかを判断することです フェイルオーバーが必要と判断し 複数のフィジカル スタンバイ データベースが構成されている場合は DBA がフェイルオーバーのターゲットとして最適なフィジカル スタンバイ データベースを選択する必要があります 最適なスタンバイ データベースの判断に影響を与える環境上の要因は様々ですが この使用例では データ消失の査定を明確にするために これらの要因が等しいと仮定します この使用例では HQ プライマリ データベースと 2 つのフィジカル スタンバイ データベース (SAT と NYC) で構成した Data Guard 構成を前提に説明します HQ データベースは最大可用性保護モードで動作し スタンバイ データベースはそれぞれ 3 つのスタンバイ REDO ログ ファイルで構成されています フィジカル スタンバイ データベースの最大可用性保護モードの詳細は 1.4 項を参照してください 表 12-5 に この使用例で使用されているデータベースに関する情報を示します 表 12-5 フィジカル スタンバイ データベースの例で使用される識別子 識別子 HQ データベース SAT データベース NYC データベース 場所 サンフランシスコ シアトル ニューヨーク市 データベース名 HQ HQ HQ インスタンス名 HQ SAT NYC 初期化パラメータ ファイル hq_init.ora sat_init.ora nyc_init.ora 制御ファイル hq_cf1.f sat_cf1.f nyc_cf1.f データファイル hq_db1.f sat_db1.f nyc_db1.f REDO ログ ファイル 1 hq_log1.f sat_log1.f nyc_log1.f REDO ログ ファイル 2 hq_log2.f sat_log2.f nyc_log2.f スタンバイ REDO ログ ファイル 1 hq_srl1.f sat_srl1.f nyc_srl1.f スタンバイ REDO ログ ファイル 2 hq_srl2.f sat_srl2.f nyc_srl2.f スタンバイ REDO ログ ファイル 3 hq_srl3.f sat_srl3.f nyc_srl3.f プライマリ保護モード最大可用性該当なし該当なし スタンバイ保護モード 該当なし 最大可用性 ( 同期 ) 最大パフォーマンス ( 非同期 ) ネットワーク サービス名 ( クライアント定義 ) hq_net sat_net nyc_net リスナー hq_listener sat_listener nyc_listener 注意 : ピーク ワークロード時に HQ から NYC に REDO データを同期させて送信することは プライマリ データベースのパフォーマンスに影響を与える可能性があるため ニューヨーク市のデータベースは最大パフォーマンス モードで動作しています ただし ニューヨーク市のスタンバイ データベースは スタンバイ REDO ログを使用しているため フェイルオーバーの有効な候補とみなされたままです Data Guard の使用例 12-11

230 ロールの推移に最適なスタンバイ データベースの選択 プライマリ サイトがあるサンフランシスコでイベントが発生し 適時に修正できないような被害を受けたと仮定します スタンバイ データベースの 1 つにフェイルオーバーする必要があります 複数のスタンバイ データベース構成を設定した DBA が どのスタンバイ データベースにフェイルオーバーするのが適切であるかを必ずしも決定できる状態にあるとは限りません したがって 各スタンバイ サイトで プライマリ サイト同様に障害時リカバリ計画を立てることが必要になります 障害時リカバリ チームの各メンバーは 障害時リカバリ計画を知っており 実行する手順を認識している必要があります この使用例では フェイルオーバーのターゲットとなるスタンバイ データベースの判断に必要な情報を識別します 障害時リカバリ チームに情報を提供する 1 つの方法は 各スタンバイ サイトに ReadMe ファイルを用意しておく方法です この ReadMe ファイルは DBA によって作成およびメンテナンスされ 次の方法を記述している必要があります DBA としてのローカル Oracle データベースへのログオン方法 スタンバイ データベースが存在する各システムへのログオン方法 システム間にはファイアウォールが存在する可能性があるため ファイアウォールを通過する手順の取得方法 DBA として他の Oracle データベースへログオンする方法 最も新しいログが適用されているスタンバイ データベースの識別方法 スタンバイ データベース フェイルオーバーの実行方法 クライアント アプリケーションが 元のプライマリ データベースではなく 新しいプライマリ データベースにアクセスできるようなネットワーク設定の構成方法 スタンバイ データベースの選択に際しては 2 つの重要な考慮事項があります 1 つは最新の REDO データを受信したスタンバイ データベース もう 1 つは最多の REDO を適用したスタンバイ データベースです 次の手順に従って フィジカル スタンバイ データベースのみで構成されている場合に どのスタンバイ データベースがフェイルオーバーに最適な候補であるかを決定します 常に 最高の保護レベルを提供しているスタンバイ データベースから考慮します この使用例では シアトルのスタンバイ データベースが最大可用性保護モードで動作しているため このデータベースが最高の保護レベルを提供しています 手順 1 SAT フィジカル スタンバイ データベースに接続する次のような SQL 文を発行します SQL> CONNECT SYS/CHANGE_ON_INSTALL AS SYSDBA; 手順 2 アーカイブ REDO ログ ファイルで使用可能なカレント REDO データの量を判別する次のように V$MANAGED_STANDBY ビューの列を問い合せます SQL> SELECT THREAD#, SEQUENCE#, BLOCK#, BLOCKS 2> FROM V$MANAGED_STANDBY WHERE STATUS='RECEIVING'; THREAD# SEQUENCE# BLOCK# BLOCKS このスタンバイ データベースは プライマリ データベースから 249 ブロックの REDO データを受信しています 受信したブロック数を計算するには BLOCKS 列の値を BLOCK# 列の値に加えて 1 を引きます 1 を引く理由は ブロック番号 234 が受信した 16 ブロックに含まれているためです 注意 : プライマリ データベースが使用不可能であった期間によっては 前述の問合せで指定した行が戻らない場合があります これは RFS プロセスがネットワークの切断を検出し プロセス自体が終了する場合があるためです この場合の最善策は REDO データを同期モードで受信するように構成されたスタンバイ データベースを常に選択することです Oracle Data Guard 概要および管理

231 ロールの推移に最適なスタンバイ データベースの選択 手順 3 SAT データベースに適用した または適用を保留しているアーカイブ REDO ログ ファイルのリストを取得する V$ARCHIVED_LOG ビューを問い合せます SQL> SELECT SUBSTR(NAME,1,25) FILE_NAME, SEQUENCE#, APPLIED 2> FROM V$ARCVHIVED_LOG ORDER BY SEQUENCE#; FILE_NAME SEQUENCE# APP /oracle/dbs/hq_sat_2.log 2 YES /oracle/dbs/hq_sat_3.log 3 YES /oracle/dbs/hq_sat_4.log 4 YES /oracle/dbs/hq_sat_5.log 5 YES /oracle/dbs/hq_sat_6.log 6 YES /oracle/dbs/hq_sat_7.log 7 YES /oracle/dbs/hq_sat_8.log 8 YES /oracle/dbs/hq_sat_9.log 9 YES /oracle/dbs/hq_sat_10.log 10 YES /oracle/dbs/hq_sat_11.log 11 YES /oracle/dbs/hq_sat_13.log 13 NO この出力は アーカイブ REDO ログ ファイル 11 がスタンバイ データベースに完全に適用されたことを示しています ( 出力例では ログ ファイル 11 の行を確認しやすいように太字で示していますが 実際の出力は太字ではありません ) SEQUENCE# 列の順序番号にギャップがあることにも注意してください この例の場合は SAT スタンバイ データベースでアーカイブ REDO ログ ファイル番号 12 が欠落していることを示しています 手順 4 NYC データベースに接続して NYC データベースが SAT スタンバイ データベースよりも新しいかどうかを判断する次のような SQL 文を発行します SQL> CONNECT SYS/CHANGE_ON_INSTALL AS SYSDBA; 手順 5 アーカイブ REDO ログ ファイルで使用可能なカレント REDO データの量を判別する次のように V$MANAGED_STANDBY ビューの列を問い合せます SQL> SELECT THREAD#, SEQUENCE#, BLOCK#, BLOCKS 2> FROM V$MANAGED_STANDBY WHERE STATUS='RECEIVING'; THREAD# SEQUENCE# BLOCK# BLOCKS このスタンバイ データベースも プライマリ データベースから 249 ブロックの REDO 情報を受信しています 受信したブロック数を計算するには BLOCKS 列の値を BLOCK# 列の値に加えて 1 を引きます 1 を引く理由は ブロック番号 157 が受信した 93 ブロックに含まれているためです Data Guard の使用例 12-13

232 ロールの推移に最適なスタンバイ データベースの選択 SQL> SELECT SUBSTR(NAME,1,25) FILE_NAME, SEQUENCE#, APPLIED 2> FROM V$ARCVHIVED_LOG ORDER BY SEQUENCE#; FILE_NAME SEQUENCE# APP /oracle/dbs/hq_nyc_2.log 2 YES /oracle/dbs/hq_nyc_3.log 3 YES /oracle/dbs/hq_nyc_4.log 4 YES /oracle/dbs/hq_nyc_5.log 5 YES /oracle/dbs/hq_nyc_6.log 6 YES /oracle/dbs/hq_nyc_7.log 7 YES /oracle/dbs/hq_nyc_8.log 8 NO /oracle/dbs/hq_nyc_9.log 9 NO /oracle/dbs/hq_nyc_10.log 10 NO /oracle/dbs/hq_nyc_11.log 11 NO /oracle/dbs/hq_nyc_12.log 12 NO /oracle/dbs/hq_nyc_13.log 13 NO この出力は アーカイブ REDO ログ ファイル 7 がスタンバイ データベースに完全に適用されたことを示しています ( 出力例では ログ ファイル 7 の行を確認しやすいように太字で示していますが 実際の出力は太字ではありません ) この場所で受信した REDO データはシアトルの場合よりも多数ですが スタンバイ データベースに適用されたデータはシアトルの場合より少数です 手順 6 NYC データベースに適用した または適用を保留しているアーカイブ REDO ログ ファイルのリストを取得する V$ARCHIVED_LOG ビューを問い合せます 手順 7 最適なターゲット スタンバイ データベースを選択するほとんどの場合 フェイルオーバーのターゲットとして選択するフィジカル スタンバイ データベースは データ消失のリスクと ロールの推移の実行に必要な時間とのバランスを備えている必要があります この情報を分析して この使用例で最適なフェイルオーバー候補を決定するときに 次のことを考慮してください フェイルオーバー時のデータ消失のリスクを最小にするには 最適なターゲット スタンバイ データベースとして NYC データベースを選択します これは 手順 5 と 6 からわかるように リカバリ可能な REDO が NYC サイトに多数存在するためです フェイルオーバー操作時のプライマリ データベース停止時間を最小にするには 最適なターゲット スタンバイ データベースとして SAT データベースを選択します SAT データベースの方が適切な候補である理由は 手順 2 から 6 でわかるように NYC データベースよりもアーカイブ REDO ログ ファイルを 5 つ多く適用している点です ただし 欠落しているアーカイブ REDO ログ ファイル ( この例ではログ 12) のコピーの取得と適用が不可能な場合は SAT データベースを NYC データベースと同じ最新の状態にすることはできません したがって 未適用のデータ ( この例ではログ ファイル およびログ ファイル 14 の一部 ) は失われます 最適なターゲット スタンバイ データベースは ビジネス要件に基づいて選択します Oracle Data Guard 概要および管理

233 ロールの推移に最適なスタンバイ データベースの選択 手順 8 選択したスタンバイ データベースを最新の状態にする ビジネス要件に基づいて最適なターゲットとして SAT を選択した場合は 次の手順を実行します 1. オペレーティング システムのコピー ユーティリティを使用して 欠落しているアーカイブ REDO ログ ファイルを取得します ( この例では UNIX の cp コマンドを使用しています ) この使用例の SAT データベースでは アーカイブ REDO ログ ファイル 12 が欠落しています NYC データベースはこのアーカイブ REDO ログ ファイルを受信しているため 次のように SAT データベースにコピーできます % cp /net/nyc/oracle/dbs/hq_nyc_12.log /net/sat/oracle/dbs/hq_sat_12.log 2. 次の順序番号に対して 部分的なアーカイブ REDO ログ ファイルが存在しているかどうかを判別します この例では 次の順序番号は 14 となります 次の UNIX コマンドでは SAT データベースのディレクトリが検索され hq_sat_14.log という名のアーカイブ REDO ログ ファイルが存在しているかどうかが調べられます % ls -l /net/sat/oracle/dbs/hq_sat_14.log /net/sat/oracle/dbs/hq_sat_14.log: No such file or directory SAT スタンバイ データベースはスタンバイ REDO ログ ファイルを使用しているため 部分的なアーカイブ REDO ログ ファイルが存在していることはありません 3. 取得したアーカイブ REDO ログ ファイルを登録します ( ログ適用サービスを停止する必要はありません ) SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '/oracle/dbs/hq_sat_12.log'; 4. V$ARCHIVED_LOG ビューを再度問い合せて アーカイブ REDO ログ ファイルが正常に適用されたことを確認します SQL> SELECT SUBSTR(NAME,1,25) FILE_NAME, SEQUENCE#, APPLIED 2> FROM V$ARCVHIVED_LOG ORDER BY SEQUENCE#; FILE_NAME SEQUENCE# APP /oracle/dbs/hq_sat_2.log 2 YES /oracle/dbs/hq_sat_3.log 3 YES /oracle/dbs/hq_sat_4.log 4 YES /oracle/dbs/hq_sat_5.log 5 YES /oracle/dbs/hq_sat_6.log 6 YES /oracle/dbs/hq_sat_7.log 7 YES /oracle/dbs/hq_sat_8.log 8 YES /oracle/dbs/hq_sat_9.log 9 YES /oracle/dbs/hq_sat_10.log 10 YES /oracle/dbs/hq_sat_11.log 11 YES /oracle/dbs/hq_sat_12.log 12 YES /oracle/dbs/hq_sat_13.log 13 YES ビジネス要件に基づいて最適なターゲットとして NYC を選択した場合は 次の手順を実行します 1. 次の順序番号に対して 部分的なアーカイブ REDO ログ ファイルが存在しているかどうかを判別します 次の UNIX コマンドで NYC データベースのディレクトリを検索して 次の順序の名前が付いた hq_nyc_14 というアーカイブ REDO ログ ファイルが存在しているかどうかを調べます % ls -l /net/nyc/oracle/dbs/hq_nyc_14.log /net/nyc/oracle/dbs/hq_nyc_14.log: No such file or directory NYC スタンバイ データベースはスタンバイ REDO ログ ファイルを使用しているため 部分的なアーカイブ REDO ログ ファイルが存在していることはありません Data Guard の使用例 12-15

234 ロールの推移に最適なスタンバイ データベースの選択 2. ログ適用サービスを開始して 最新のログ ファイルを適用します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> DISCONNECT FROM SESSION; 3. V$ARCHIVED_LOG ビューを再度問い合せて アーカイブ REDO ログ ファイルが正常に適用されたことを確認します SQL> SELECT SUBSTR(NAME,1,25) FILE_NAME, SEQUENCE#, APPLIED 2> FROM V$ARCVHIVED_LOG ORDER BY SEQUENCE#; FILE_NAME SEQUENCE# APP /oracle/dbs/hq_nyc_2.log 2 YES /oracle/dbs/hq_nyc_3.log 3 YES /oracle/dbs/hq_nyc_4.log 4 YES /oracle/dbs/hq_nyc_5.log 5 YES /oracle/dbs/hq_nyc_6.log 6 YES /oracle/dbs/hq_nyc_7.log 7 YES /oracle/dbs/hq_nyc_8.log 8 YES /oracle/dbs/hq_nyc_9.log 9 YES /oracle/dbs/hq_nyc_10.log 10 YES /oracle/dbs/hq_nyc_11.log 11 YES /oracle/dbs/hq_nyc_12.log 12 NO /oracle/dbs/hq_nyc_13.log 13 NO アーカイブ REDO ログ ファイルの適用では 完了までに時間がかかる場合があります したがって 次のようにすべてのアーカイブ REDO ログ ファイルが指定されるまで待機する必要があります SQL> SELECT SUBSTR(NAME,1,25) FILE_NAME, SEQUENCE#, APPLIED 2> FROM V$ARCVHIVED_LOG ORDER BY SEQUENCE#; FILE_NAME SEQUENCE# APP /oracle/dbs/hq_nyc_2.log 2 YES /oracle/dbs/hq_nyc_3.log 3 YES /oracle/dbs/hq_nyc_4.log 4 YES /oracle/dbs/hq_nyc_5.log 5 YES /oracle/dbs/hq_nyc_6.log 6 YES /oracle/dbs/hq_nyc_7.log 7 YES /oracle/dbs/hq_nyc_8.log 8 YES /oracle/dbs/hq_nyc_9.log 9 YES /oracle/dbs/hq_nyc_10.log 10 YES /oracle/dbs/hq_nyc_11.log 11 YES /oracle/dbs/hq_nyc_12.log 12 YES /oracle/dbs/hq_nyc_13.log 13 YES 手順 9 フェイルオーバーを実行するログ適用サービスを停止し 選択したフィジカル スタンバイ データベースをプライマリ ロールにフェイルオーバーする準備が整いました フィジカル スタンバイ データベースに対するフェイルオーバーの実行方法の詳細は 項を参照してください Oracle Data Guard 概要および管理

235 ロールの推移に最適なスタンバイ データベースの選択 例 : フェイルオーバーに最適なロジカル スタンバイ データベース 障害時にロジカル スタンバイ データベースのみが使用可能な場合 重要な作業は どのロジカル スタンバイ データベースがフェイルオーバーに最適かを判断することです 最適なターゲット スタンバイ データベースの判断に影響を与える環境上の要因は様々ですが この使用例では データ消失の査定を明確にするために これらの要因が等しいと仮定します ロジカル スタンバイ データベースの最大可用性保護モードの詳細は 1.4 項を参照してください この使用例では HQ プライマリ データベースと 2 つのロジカル スタンバイ データベース (SAT と NYC) で構成した Data Guard 構成を前提に説明します 表 12-6 に これらのデータベースに関する情報を示します 表 12-6 ロジカル スタンバイ データベースの例で使用される識別子 識別子 HQ データベース SAT データベース NYC データベース 場所 サンフランシスコ シアトル ニューヨーク市 データベース名 HQ SAT NYC インスタンス名 HQ SAT NYC 初期化パラメータ ファイル hq_init.ora sat_init.ora nyc_init.ora 制御ファイル hq_cf1.f sat_cf1.f nyc_cf1.f データファイル hq_db1.f sat_db1.f nyc_db1.f REDO ログ ファイル 1 hq_log1.f sat_log1.f nyc_log1.f REDO ログ ファイル 2 hq_log2.f sat_log2.f nyc_log2.f データベース リンク ( クライアント定義 ) ネットワーク サービス名 ( クライアント定義 ) hq_link sat_link nyc_link hq_net sat_net nyc_net リスナー hq_listener sat_listener nyc_listener 次の手順に従って ロジカル スタンバイ データベースのみで構成されている場合に どのスタンバイ データベースがフェイルオーバーに最適な候補であるかを決定します 手順 1 SAT ロジカル スタンバイ データベースに接続する次のような SQL 文を発行します SQL> CONNECT SYS/CHANGE_ON_INSTALL AS SYSDBA; 手順 2 SAT データベースに適用された最大の SCN と適用可能な最大 ( 最新 ) の SCN を判断する V$LOGSTDBY_PROGRESS ビューで 次の列を問い合せます SQL> SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN LATEST_SCN Data Guard の使用例 12-17

236 ロールの推移に最適なスタンバイ データベースの選択 手順 3 SAT データベースに適用した または適用を保留しているアーカイブ REDO ログ ファイルのリストを取得する DBA_LOGSTDBY_LOG ビューを問い合せます SQL> SELECT SUBSTR(FILE_NAME,1,25) FILE_NAME, SUBSTR(SEQUENCE#,1,4) "SEQ#", 2> FIRST_CHANGE#, NEXT_CHANGE#, TO_CHAR(TIMESTAMP, 'HH:MI:SS') TIMESTAMP, 3> DICT_BEGIN BEG, DICT_END END, SUBSTR(THREAD#,1,4) "THR#" 4> FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#; FILE_NAME SEQ# FIRST_CHANGE# NEXT_CHANGE# TIMESTAM BEG END THR# /oracle/dbs/hq_sat_2.log :02:57 NO NO 1 /oracle/dbs/hq_sat_3.log :02:01 NO NO 1 /oracle/dbs/hq_sat_4.log :02:09 NO NO 1 /oracle/dbs/hq_sat_5.log :02:47 YES YES 1 /oracle/dbs/hq_sat_6.log :02:09 NO NO 1 /oracle/dbs/hq_sat_7.log :02:00 NO NO 1 /oracle/dbs/hq_sat_8.log :02:00 NO NO 1 /oracle/dbs/hq_sat_9.log :02:15 NO NO 1 /oracle/dbs/hq_sat_10.log :02:20 NO NO 1 /oracle/dbs/hq_sat_11.log :02:25 NO NO 1 /oracle/dbs/hq_sat_13.log :02:40 NO NO 1 手順 2 に記載されているログ ファイル 11 の SCN は FIRST_CHANGE# 列の値 と NEXT_CHANGE# 列の値 の間にあります これは ログ ファイル 11 が現在適用中であることを示します SEQ# 列の順序番号にギャップがあることにも注意してください この例の場合は SAT データベースでアーカイブ REDO ログ ファイル 12 が欠落していることを示しています 手順 4 NYC データベースに接続する次のような SQL 文を発行します SQL> CONNECT SYS/CHANGE_ON_INSTALL AS SYSDBA; 手順 5 NYC データベースに適用された最大の SCN と適用可能な最大の SCN を判断する V$LOGSTDBY_PROGRESS ビューで 次の列を問い合せます SQL> SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN LATEST_SCN 手順 6 NYC データベースで処理済または現在処理が保留中のログ ファイルのリストを取得する次のような SQL 文を発行します SQL> SELECT SUBSTR(FILE_NAME,1,25) FILE_NAME, SUBSTR(SEQUENCE#,1,4) "SEQ#", 2> FIRST_CHANGE#, NEXT_CHANGE#, TO_CHAR(TIMESTAMP, 'HH:MI:SS') TIMESTAMP, 3> DICT_BEGIN BEG, DICT_END END, SUBSTR(THREAD#,1,4) "THR#" 4> FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#; FILE_NAME SEQ# FIRST_CHANGE# NEXT_CHANGE# TIMESTAM BEG END THR# /oracle/dbs/hq_nyc_2.log :02:58 NO NO 1 /oracle/dbs/hq_nyc_3.log :02:02 NO NO 1 /oracle/dbs/hq_nyc_4.log :02:10 NO NO 1 /oracle/dbs/hq_nyc_5.log :02:48 YES YES 1 /oracle/dbs/hq_nyc_6.log :02:10 NO NO 1 /oracle/dbs/hq_nyc_7.log :02:11 NO NO 1 /oracle/dbs/hq_nyc_8.log :02:01 NO NO 1 /oracle/dbs/hq_nyc_9.log :02:16 NO NO 1 /oracle/dbs/hq_nyc_10.log :02:21 NO NO Oracle Data Guard 概要および管理

237 ロールの推移に最適なスタンバイ データベースの選択 /oracle/dbs/hq_nyc_11.log :02:26 NO NO 1 /oracle/dbs/hq_nyc_12.log :02:30 NO NO 1 /oracle/dbs/hq_nyc_13.log :02:41 NO NO 1 手順 5 に記載されているログ ファイル 6 の SCN は FIRST_CHANGE# 列の値 と NEXT_CHANGE# 列の値 の間にあります これは ログ ファイル 6 が現在適用中であることを示します 処理が残っているログ ファイルの順序番号にギャップがないことも注意してください 手順 7 最適なターゲット スタンバイ データベースを選択するほとんどの場合 フェイルオーバーのターゲットとして選択するロジカル スタンバイ データベースは データ消失のリスクと ロールの推移の実行に必要な時間とのバランスを備えている必要があります この情報を分析して この使用例で最適なフェイルオーバー候補を決定するときに 次のことを考慮してください フェイルオーバー時のデータ消失のリスクを最小にするには 最適なターゲット スタンバイ データベースとして NYC データベースを選択します これは 手順 5 と 6 からわかるように リカバリ可能なアーカイブ REDO ログ ファイルが NYC サイトに多数存在するためです フェイルオーバー時のプライマリ データベース停止時間を最小にするには 最適なターゲット スタンバイ データベースとして SAT データベースを選択します このデータベースの方が適切な候補である理由は 手順 2 から 6 の問合せでわかるように SAT データベースの方がアーカイブ REDO ログ ファイルを NYC データベースより 5 つ多く適用しているためです ( ただし NYC データベースによるアーカイブ REDO ログ ファイルの受信にかかった遅延 ( ラグ ) は 1 秒ほどです ) ただし 欠落しているアーカイブ REDO ログ ファイル ( この例ではログ ファイル 12) のコピーの取得と適用が不可能な場合は SAT データベースを NYC データベースと同じ最新の状態にすることはできません したがって リカバリされないデータ ( この例ではログ ファイル およびログ ファイル 14 の一部 ) は失われます 最適なターゲット スタンバイ データベースは ビジネス要件に基づいて選択します 手順 8 選択したスタンバイ データベースを最新の状態にするビジネス要件に基づいて最適なターゲットとして SAT を選択した場合は 次の手順を実行します 1. オペレーティング システムのユーティリティを使用して 欠落しているアーカイブ REDO ログ ファイルを手動で取得します ( この例では UNIX の cp コマンドを使用しています ) この使用例の SAT データベースでは アーカイブ REDO ログ ファイル 12 が欠落しています NYC データベースはこのアーカイブ REDO ログ ファイルを受信しているため 次のように SAT データベースにコピーできます %cp /net/nyc/oracle/dbs/hq_nyc_12.log /net/sat/oracle/dbs/hq_sat_12.log 2. 次の順序番号に対して 部分的なアーカイブ REDO ログ ファイルが存在しているかどうかを判別します この例では 次の順序番号は 14 となります 次の UNIX コマンドでは SAT データベースのディレクトリが表示され hq_sat_14.log という名のアーカイブ REDO ログ ファイルが存在しているかどうかが調べられます %ls -l /net/sat/oracle/dbs/hq_sat_14.log -rw-rw oracle dbs Feb 12 1:03 hq_sat_14.log 3. ログ適用サービスを停止し 取得したアーカイブ REDO ログ ファイルと部分的なアーカイブ REDO ログ ファイルの両方を登録します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/oracle/dbs/hq_sat_12.log'; SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/oracle/dbs/hq_sat_14.log'; Data Guard の使用例 12-19

238 ロールの推移に最適なスタンバイ データベースの選択 4. ログ適用サービスを開始して 最新のログ ファイルを適用します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; 5. V$LOGSTDBY_PROGRESS ビューを問い合せて SAT データベースで適用済の最大の SCN を判断し APPLIED_SCN 列の値が LATEST_SCN 列の値と等しいかどうかを調べます SQL> SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN LATEST_SCN SCN の値が一致しているため プライマリ データベースの現在のログ ファイルと SAT データベースに適用された最後のログ ファイルの間の遅延 ( ラグ ) がなくなったことを確認できます ビジネス要件に基づいて最適なターゲットとして NYC を選択した場合は 次の手順を実行します 1. 次の順序番号に対して 部分的なアーカイブ REDO ログ ファイルが存在しているかどうかを判別します この例では 次の順序番号は 14 となります 次の UNIX コマンドでは NYC データベースのディレクトリが表示され hq_nyc_14 という名のアーカイブ REDO ログ ファイルが存在しているかどうかが調べられます %ls -l /net/nyc/oracle/dbs/hq_nyc_14.log -rw-rw oracle dbs Feb 12 1:03 hq_nyc_14.log 2. 部分的なアーカイブ REDO ログ ファイルを NYC データベースに登録します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/oracle/dbs/hq_nyc_14.log'; 3. ログ適用サービスを開始して 最新のログ ファイルを適用します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; 4. V$LOGSTDBY_PROGRESS ビューを問い合せて NYC データベースで適用済の最大の SCN を判別し APPLIED_SCN 列の値が LATEST_SCN 列の値と等しいかどうかを調べます SQL> SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN LATEST_SCN SCN の値が一致しているため プライマリ データベースの現在のログ ファイルと NYC データベースで受信され適用された最後のログ ファイルの間の遅延 ( ラグ ) がなくなったことを確認できます 手順 9 フェイルオーバーを実行するログ適用サービスを停止し 選択したロジカル スタンバイ データベースをプライマリ ロールにフェイルオーバーする準備が整いました フェイルオーバーの実行方法の詳細は 項を参照してください Oracle Data Guard 概要および管理

239 新規プライマリ データベースをサポートするロジカル スタンバイ データベースの構成 12.3 新規プライマリ データベースをサポートするロジカル スタンバイ データベースの構成 この項では プライマリ データベースを別のスタンバイ データベースにフェイルオーバーした後に ロジカル スタンバイ データベースで実行する必要のある手順について説明します フェイルオーバーの発生後 ロジカル スタンバイ データベースは 元のプライマリ データベースからの最後の REDO が適用されるまで 新規プライマリ データベースのスタンバイ データベースとして機能できません これは フェイルオーバー中に新規のプライマリ データベースで最後の REDO が適用される場合と同じです 実行する必要のある手順は 新規プライマリ データベースがフェイルオーバー前にフィジカル スタンバイ データベースであったかロジカル スタンバイ データベースであったかに応じて異なります 項 新規プライマリ データベースがフィジカル スタンバイ データベースだった場合 項 新規プライマリ データベースがロジカル スタンバイ データベースだった場合 新規プライマリ データベースがフィジカル スタンバイ データベースだった場合 この使用例では フェイルオーバー後の NYC データベースを使用して SAT ロジカル スタンバイ データベースを構成する方法について説明します この使用例は 項で説明した例の続きです ただし この例では NYC データベースはフェイルオーバー前はフィジカル スタンバイ データベースでした 新規プライマリ データベースを使用してロジカル スタンバイ データベースを構成する手順は 次のとおりです 手順 1 プライマリ データベースからのアーカイブを使用不可にする NYC データベースで 次の文を発行します (LOG_ARCHIVE_DEST_4 が SAT データベースにアーカイブするように構成されているとします ) SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=DEFER; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 手順 2 ロジカル スタンバイ データベースが新規プライマリ データベースのスタンバイ データベースとして機能できることを確認する SAT データベースで 次の文を発行します SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY(- former_standby_type => 'PHYSICAL' - dblink => 'nyc_link'); 注意 : ORA メッセージが戻され alert.log に LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required. という警告が書き込まれる場合は 次の手順を実行します 1. データベースを警告に示された SCN までフラッシュバックします 2. 続行する前に この手順を繰り返します ロジカル スタンバイ データベースを適用 SCN までフラッシュバックする方法の例は 項を参照してください Data Guard の使用例 12-21

240 新規プライマリ データベースをサポートするロジカル スタンバイ データベースの構成 手順 3 プライマリ データベースでアーカイブを使用可能にする NYC データベースで 次の文を発行します (LOG_ARCHIVE_DEST_4 が SAT データベースにアーカイブするように構成されているとします ) SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=ENABLE; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 手順 4 新規プライマリ データベースを問い合せ ロジカル スタンバイ データベースでリアルタイム適用を有効化できる SCN を判断する NYC データベースで 次の問合せを発行して必要な SCN を判断します SQL> SELECT MAX(NEXT_CHANGE#) -1 AS WAIT_FOR_SCN FROM V$ARCHIVED_LOG; 手順 5 SQL Apply を開始する SAT データベースで 次の文を発行します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; この文は 常にリアルタイム適用オプションを指定せずに発行する必要があることに注意してください 手順 4 で戻された過去の WAIT_FOR_SCN が SQL Apply により適用されるまで待機した後で リアルタイム適用を有効化する必要があります ロジカル スタンバイ データベースでリアルタイム適用を安全に再開できる時点を判断するには V$LOGSTDBY_PROGRESS ビューを監視します SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS; 戻される値が手順 4 で戻された WAIT_FOR_SCN 値以上の場合は SQL Apply を停止し リアルタイム適用オプションを指定して再開できます SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 新規プライマリ データベースがロジカル スタンバイ データベースだった場合 この使用例では フェイルオーバー後の NYC データベースを使用して SAT ロジカル スタンバイ データベースを構成する方法について説明します この使用例は 項で説明した例の続きです ただし この例では NYC データベースはフェイルオーバー前はロジカル スタンバイ データベースでした 新規プライマリ データベースを使用してロジカル スタンバイ データベースを構成する手順は 次のとおりです 手順 1 新規プライマリ データベースで ロジカル スタンバイ データベースのサポート準備が完了していることを確認する NYC データベースで 次の問合せにより値 READY が戻されることを確認します それ以外の場合 LSP1 バックグラウンド プロセスの処理が完了しておらず このロジカル スタンバイ データベースの構成は待機する必要があります 次に例を示します SQL> SELECT VALUE FROM DBA_LOGSTDBY_PARAMETERS WHERE 2> NAME = 'REINSTATEMENT_STATUS'; VALUE READY 注意 : VALUE 列に NOT POSSIBLE が含まれている場合は 新規プライマリ データベースでロジカル スタンバイ データベースを構成できず データベースを元に戻す必要があることを意味します Oracle Data Guard 概要および管理

241 新規プライマリ データベースをサポートするロジカル スタンバイ データベースの構成 手順 2 プライマリ データベースからのアーカイブを使用不可にする NYC データベースで 次の文を発行します (LOG_ARCHIVE_DEST_4 が SAT データベースにアーカイブするように構成されているとします ) SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=DEFER; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 手順 3 ロジカル スタンバイ データベースが新規プライマリ データベースのスタンバイ データベースとして機能できることを確認する SAT データベースで 次の文を発行します SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY(- former_standby_type => 'LOGICAL' - dblink => 'nyc_link'); 注意 : ORA メッセージが戻され alert.log ファイルに LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required. という警告が書き込まれる場合は 次の手順を実行します 1. データベースを警告に示された SCN までフラッシュバックします 2. 続行する前に この手順を繰り返します ロジカル スタンバイ データベースを適用 SCN までフラッシュバックする方法の例は 項を参照してください 手順 4 ローカル システムにコピーする必要のあるログ ファイルを判別する SAT データベースで DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY プロシージャの出力を調べます このプロシージャでは ローカル システムにコピーする必要のあるログ ファイルが識別されます 手順 3 でフェイルオーバーを非データ消失フェイルオーバーとして識別した場合は 表示されたログ ファイルを新規プライマリ データベースからコピーする必要があります 他のロジカル スタンバイ データベースまたは前のプライマリ データベースからは取得しないでください たとえば Linux システムでは grep コマンドを入力します %grep 'LOGSTDBY: Terminal log' alert_sat.log LOGSTDBY: Terminal log: [/oracle/dbs/hq_nyc_13.log] 注意 : 前の手順を複数回実行した場合 関連があるのは最後の試行で得られた出力のみです ファイル パスは新規プライマリ データベースとの相対パスであり ローカル ファイル システムでは解決できない場合があります 手順 5 ログ ファイルをローカル システムにコピーする SAT データベースで 端末のログ ファイルをローカル システムにコピーします 次の例に この操作に Linux コマンドを使用する方法を示します %cp /net/nyc/oracle/dbs/hq_nyc_13.log /net/sat/oracle/dbs/hq_sat_13.log 手順 6 端末のログをロジカル スタンバイ データベースに登録する SAT データベースで 次の文を発行します SQL> ALTER DATABASE REGISTER OR REPLACE LOGICAL LOGFILE - '/net/sat/oracle/dbs/hq_sat_13.log'; Data Guard の使用例 12-23

242 フェイルオーバー後のフラッシュバック データベースの使用 手順 7 SQL Apply を開始する SAT データベースで 次の文を発行します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY nyc_link; この文は 常にリアルタイム適用オプションを指定せずに発行する必要があることに注意してください ロジカル スタンバイ データベースでリアルタイム適用を使用可能にする必要がある場合は 前述の文が正常終了するまで待機してから 次の文を発行します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 手順 8 プライマリ データベースでロジカル スタンバイ データベースへのアーカイブを使用可能にする NYC データベースで 次の文を発行します (LOG_ARCHIVE_DEST_4 が SAT データベースにアーカイブするように構成されているとします ) SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=ENABLE; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 12.4 フェイルオーバー後のフラッシュバック データベースの使用 フェイルオーバーの発生後 元のプライマリ データベースは 修正され 新しい構成のスタンバイ データベースとして確立されるまで Data Guard 構成に含められません これを行うには フラッシュバック データベース機能を使用して 障害の発生したプライマリ データベースを障害発生前の時点にフラッシュバックし その後新しい構成内のフィジカルまたはロジカル スタンバイ データベースに変換します 次の各項で 次の内容を説明します 障害が発生したプライマリ データベースのフィジカル スタンバイ データベースへのフラッシュバック 障害が発生したプライマリ データベースのロジカル スタンバイ データベースへのフラッシュバック 注意 : フェイルオーバー前に 元のプライマリ データベースでフラッシュバック データベースが使用可能になっている必要があります 詳細は Oracle Database バックアップおよびリカバリ基礎 を参照してください 特定の適用済 SCN へのロジカル スタンバイ データベースのフラッシュバック 関連項目 : 障害の発生したプライマリ データベースを ( フラッシュバック データベースとして使用するかわりに ) 自動的に新規スタンバイ データベースに戻す方法は Oracle Data Guard Broker を参照してください Oracle Data Guard 概要および管理

243 フェイルオーバー後のフラッシュバック データベースの使用 障害が発生したプライマリ データベースのフィジカル スタンバイ データベースへのフラッシュバック 次の手順では ユーザーがすでにフィジカル スタンバイ データベースを使用したフェイルオーバーを実行済で 古いプライマリ データベースでフラッシュバック データベースが使用可能にされていることを前提としています この手順では 古いプライマリ データベースを新しいフィジカル スタンバイ データベースとして Data Guard 構成に戻します 手順 1 古いスタンバイ データベースがプライマリ データベースになった SCN を判別する新しいプライマリ データベース上で次の問合せを発行し 古いスタンバイ データベースが新しいプライマリ データベースになった SCN を判別します SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE; 手順 2 障害の発生したプライマリ データベースをフラッシュバックする新しいフィジカル スタンバイ データベースを作成するには 必要に応じて古いプライマリ データベースを停止し マウントして 手順 1 で判別した STANDBY_BECAME_PRIMARY_SCN の値にフラッシュバックします SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> FLASHBACK DATABASE TO SCN standby_became_primary_scn; 手順 3 データベースからフィジカル スタンバイ データベースに変換する古いプライマリ データベースを変換する手順は 次のとおりです 1. 古いプライマリ データベースで次の文を発行します SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; 制御ファイルからスタンバイ制御ファイルへ正常に変換後 この文はデータベースをマウントしません 2. データベースを停止して 再開します SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; 手順 4 新しいフィジカル スタンバイ データベースへの REDO 転送を再開する新しいスタンバイ データベースの作成前に 新しいプライマリ データベースは リモート宛先への REDO の転送を停止しているはずです REDO 転送サービスを再開するには 新しいプライマリ データベースで次の手順を実行します 1. 次の問合せを発行し アーカイブ宛先の現在の状態を調べます SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL 2> FROM V$ARCHIVE_DEST_STATUS; 2. 必要に応じて 宛先を使用可能にします SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE; 3. スタンバイ データベースが新しいプライマリ データベースからの REDO データの受信を確実に開始するよう ログ スイッチを実行し これが成功したことを確認します SQL プロンプトで次の文を入力します SQL> ALTER SYSTEM SWITCH LOGFILE; SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL 2> FROM V$ARCHIVE_DEST_STATUS; 新しいスタンバイ データベースで REDO 転送サービスが REDO データを別のデータベースに転送しないよう LOG_ARCHIVE_DEST_n 初期化パラメータも変更する必要があります 1 つのサーバー パラメータ ファイル (SPFILE) でプライマリおよびスタンバ Data Guard の使用例 12-25

244 フェイルオーバー後のフラッシュバック データベースの使用 イ データベース ロールの両方が VALID_FOR 属性で設定されている場合 この手順を実行する必要はありません これにより Data Guard 構成は ロールの推移後も正しく動作します 手順 5 REDO Apply を開始する新しいフィジカル スタンバイ データベースで REDO Apply またはリアルタイム適用を開始します REDO Apply を開始する場合 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; リアルタイム適用を開始する場合 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE DISCONNECT; 障害が発生したプライマリ データベースがリストアされてスタンバイ ロールで稼働し始めた後 オプションでスイッチオーバーを実行し それぞれのデータベースを元の ( 障害発生前の ) ロールに推移できます 詳細は 項 フィジカル スタンバイ データベースが関与するスイッチオーバー を参照してください 障害が発生したプライマリ データベースのロジカル スタンバイ データベースへのフラッシュバック 次の手順では Data Guard 構成ですでにロジカル スタンバイ データベースを使用したフェイルオーバーが実行済で 古いプライマリ データベースでフラッシュバック データベースが使用可能にされていることを前提としています この手順は 新しいプライマリ データベースから古いプライマリ データベースに戻すのではなく 古いプライマリ データベースを新しいロジカル スタンバイ データベースとして Data Guard 構成に戻します 手順 1 障害が発生したプライマリ データベースのフラッシュバック先 SCN を判別する新しいプライマリ データベース上で次の問合せを発行し 障害が発生したプライマリ データベースをフラッシュバックする SCN を判別します SQL> SELECT APPLIED_SCN AS FLASHBACK_SCN FROM V$LOGSTDBY_PROGRESS; 手順 2 障害が発生したプライマリ データベースにフラッシュバック データベース用としてコピーする必要のあるログ ファイルを判別する新しいプライマリ データベースで 次の問合せを発行し フラッシュバック データベースが一貫した状態に到達できるように 障害が発生したプライマリ データベースにコピーする必要のあるログ ファイルを判別します SQL> SELECT NAME FROM DBA_LOGSDTBY_LOG 2> WHERE NEXT_CHANGE# > 3> (SELECT VALUE FROM DBA_LOGSTDBY_PARAMETERS 4> WHERE NAME = 'STANDBY_BECAME_PRIMARY_SCN') 5> AND FIRST_CHANGE <= (FLASHBACK_SCN from step 1); 手順 3 障害の発生したプライマリ データベースをフラッシュバックする新しいロジカル スタンバイ データベースを作成するには 必要に応じてデータベースを停止し 障害が発生したプロトタイプ データベースをマウントし 手順 1 で判別した FLASHBACK_SCN にフラッシュバックして データベース ガードを使用可能にします SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> FLASHBACK DATABASE TO SCN became_primary_scn; SQL> ALTER DATABASE GUARD ALL; Oracle Data Guard 概要および管理

245 フェイルオーバー後のフラッシュバック データベースの使用 手順 4 RESETLOGS オプションでデータベースをオープンします SQL> ALTER DATABASE OPEN RESETLOGS; 手順 5 新しいプライマリ データベースへのデータベース リンクを作成して SQL Apply を開始する SQL> CREATE PUBLIC DATABASE LINK mylink 2> CONNECT TO system IDENTIFIED BY password 3> USING 'service_name_of_new_primary_database'; SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY mylink; これで ロールの可逆的な推移が完了しました 障害が発生したプライマリ データベースがリストアされてスタンバイ ロールで稼働し始めた後 オプションでスイッチオーバーを実行し それぞれのデータベースを元の ( 障害発生前の ) ロールに推移できます 詳細は 項 ロジカル スタンバイ データベースが関与するスイッチオーバー を参照してください 特定の適用済 SCN へのロジカル スタンバイ データベースのフラッシュバック スタンバイ データベースのメリットの 1 つは プライマリ データベース サービスに影響を与えずに スタンバイ データベースでフラッシュバック データベースを実行できることです データベースを特定の時点までフラッシュバックするタスクは簡単ですが ロジカル スタンバイ データベースでは 既知のトランザクションがコミットされる直前の時点までフラッシュバックする操作が必要になる場合があります このような必要が生じるのは フェイルオーバー後に新しいプライマリ データベースを使用してロジカル スタンバイ データベースを構成する場合です 次の手順では フラッシュバック データベースと SQL Apply を使用して既知の適用済 SCN までリカバリする方法について説明します 手順 1 Apply_SCN を含むログ ファイルを識別するロジカル スタンバイ データベースで 次の問合せを発行し Apply_SCN を含むログ ファイルを識別します SQL> SELECT FILE_NAME FROM DBA_LOGSTDBY_LOG 5> WHERE FIRST_CHANGE# <= APPLY_SCN 6> AND NEXT_CHANGE# > APPLY_SCN 7> ORDER BY FIRST_CHANGE# ASCENDING; FILE_NAME /net/sat/oracle/dbs/hq_sat_13.log 手順 2 最初のログ ファイルで SQL Apply の初期読取りに関連付けられているタイムスタンプを検索する alert.log ファイル内で 手順 1 で表示された最初のログ ファイルの SQL Apply 初期読取りに関連付けられているタイムスタンプを検索します 次に例を示します %grep -B 1 '^LOGMINER: Begin mining logfile' alert_gap2.log grep -B 1 hq_sat_13.log Tue Jun 7 02:38: LOGMINER: Begin mining logfile: /net/sat/oracle/dbs/hq_sat_13.log Data Guard の使用例 12-27

246 Open Resetlogs 文の発行後のフラッシュバック データベースの使用 手順 3 データベースをタイムスタンプまでフラッシュバックするデータベースを手順 2 で識別したタイムスタンプまでフラッシュバックします SQL> SHUTDOWN; SQL> STARTUP MOUNT EXCLUSIVE; SQL> FLASHBACK DATABASE TO TIMESTAMP - TO_TIMESTAMP('07-Jun-05 02:38:18', 'DD-Mon-RR HH24:MI:SS'); SQL> ALTER DATABASE OPEN RESETLOGS; 手順 4 SQL Apply が APPLY_SCN まで適用されたことを確認する次の問合せを発行します SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS; 12.5 Open Resetlogs 文の発行後のフラッシュバック データベースの使用 スタンバイ データベースがリアルタイム適用を使用している Data Guard 構成で プライマリ データベースでエラーが発生したとします この場合 同じエラーがスタンバイ データベースにも適用されます ただし フラッシュバック データベースが使用可能になっている場合 プライマリおよびスタンバイ データベースをエラー前の状態に戻せます これには ログ適用サービスを再開する前に プライマリ データベースで FLASHBACK DATABASE および OPEN RESETLOGS 文を発行し 次に同様の FLASHBACK STANDBY DATABASE 文をスタンバイ データベースで発行します ( フラッシュバック データベースが使用可能でない場合 第 3 章および第 4 章で説明されているように プライマリ データベースで Point-in-Time リカバリが実行された後 スタンバイ データベースを再作成する必要があります ) 特定時点へのフィジカル スタンバイ データベースのフラッシュバック 次の手順では プライマリ データベースで OPEN RESETLOGS 文を発行した後 フィジカル スタンバイ データベースの再作成を回避する方法を説明します 手順 1 RESETLOGS 操作が発生した前の SCN を判別するプライマリ データベースで 次の問合せを使用して RESETLOGS 操作がプライマリ データベースで発生したよりも 2 つ前のシステム変更番号 (SCN) の値を取得します SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE; 手順 2 スタンバイ データベースの現行の SCN を取得するスタンバイ データベースで 次の問合せを使用して現行の SCN を取得します SQL> SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE; 手順 3 データベースをフラッシュバックする必要があるかどうかを判別する CURRENT_SCN の値が resetlogs_change# - 2 の値より大きい場合 次の文を発行してスタンバイ データベースをフラッシュバックします SQL> FLASHBACK STANDBY DATABASE TO SCN resetlogs_change# -2; CURRENT_SCN の値が resetlogs_change# - 2 の値より小さい場合 手順 4 に進みます スタンバイ データベースの SCN がプライマリ データベースの SCN より大幅に小さい場合 ログ適用サービスは停止せずに OPEN RESETLOGS 文中も継続して動作できます この場合 ログ適用サービスは REDO データ内の OPEN RESETLOGS 文に到達しても停止しないため データベースのフラッシュバックは不要です Oracle Data Guard 概要および管理

247 Open Resetlogs 文の発行後のフラッシュバック データベースの使用 手順 4 REDO Apply を再開するフィジカル スタンバイ データベースで REDO Apply を開始するには 次の文を発行します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; スタンバイ データベースはプライマリ データベースから REDO を受信し適用できます プライマリのフラッシュバック後のロジカル スタンバイ データベースのフラッシュバック 次の手順では プライマリ データベースをフラッシュバックし OPEN RESETLOGS 文を発行してオープンした後 ロジカル スタンバイ データベースの再作成を回避する方法を説明します 手順 1 プライマリ データベースの SCN を判別するプライマリ データベースで 次の問合せを使用して RESETLOGS 操作がプライマリ データベースで発生したよりも 2 つ前のシステム変更番号 (SCN) の値を取得します SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) AS FLASHBACK_SCN FROM V$DATABASE; 手順 2 SQL Apply を停止するロジカル スタンバイ データベースで SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN が resetlogs_change#-2 の値より小さい場合 スタンバイ データベースをフラッシュバックする必要はないため 手順 6 に進みます SQL Apply が遅延して動作している場合 このようになります それ以外の場合は 手順 5 に進みます 手順 3 FLASHBACK_SCN を含むアーカイブ REDO ログ ファイルを判別するロジカル スタンバイ データベースで 手順 1 で判別した FLASHBACK_SCN を含むアーカイブ REDO ログ ファイルを判別します SQL> SELECT FILE_NAME FROM DBA_LOGSTDBY_LOG 2> WHERE FIRST_CHANGE# <= FLASHBACK_SCN 3> AND NEXT_CHANGE# > FLASHBACK_SCN 4> ORDER BY FIRST_CHANGE# ASCENDING; FILE_NAME /net/sat/oracle/dbs/hq_sat_146.log 手順 4 alert.log ファイル内でタイムスタンプを検索する alert.log ファイル内で 手順 1 で表示された最初のログ ファイルの SQL Apply 初期読取りに関連付けられているタイムスタンプを検索します 次に例を示します %grep -B 1 '^LOGMINER: Begin mining logfile' alert.log grep -B 1 hq_sat_146.log Tue Mar 7 12:38: LOGMINER: Begin mining logfile: /net/sat/oracle/dbs/hq_sat_146.log Data Guard の使用例 12-29

248 フィジカル スタンバイ データベースを使用した読取り / 書込みテストとレポート生成 手順 5 ロジカル スタンバイ データベースをタイムスタンプまでフラッシュバックする次の SQL 文を発行し ロジカル スタンバイ データベースを手順 4 で識別した時点にフラッシュバックし RESETLOGS オプションを指定してロジカル スタンバイ データベースをオープンします SQL> SHUTDOWN; SQL> STARTUP MOUNT EXCLUSIVE; SQL> FLASHBACK DATABASE TO TIMESTAMP('07-Mar-05 12:38:18', 'DD-Mon-RR HH24:MI:SS'); SQL> ALTER DATABASE OPEN RESETLOGS; 手順 6 SQL Apply が Apply SCN まで適用されたことを確認するロジカル スタンバイ データベースで 次の問合せを発行します SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS; 手順 7 SQL Apply を開始する SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 12.6 フィジカル スタンバイ データベースを使用した読取り / 書込みテストとレポート生成 Data Guard リストア ポイントおよびフラッシュバック データベースを使用すると フィジカル スタンバイ データベースを開発 レポート生成またはテストのために読取り / 書込みモードで一時的にオープンしてから 過去の特定時点までフラッシュバックして元に戻すことができます データベースがフラッシュバックされると Data Guard では自動的にスタンバイ データベースをプライマリ データベースと同期化します プライマリ データベースのバックアップ コピーからフィジカル スタンバイ データベースを再作成する必要はありません 図 12-7 に フィジカル スタンバイ データベースを読取り / 書込み用クローン データベースとしてアクティブ化して プライマリ データベースと再同期化し 最後にフラッシュバックして元のフィジカル スタンバイ データベース ロールに戻す様子を示します このようにアクティブ化し フラッシュバックして元に戻すというサイクルは 必要な回数だけ繰り返すことができます 図 12-7 テストおよびレポート生成用データベースとしてのフィジカル スタンバイ データベースの使用 Oracle Data Guard 概要および管理

249 フィジカル スタンバイ データベースを使用した読取り / 書込みテストとレポート生成 注意 : データベースがアクティブ化されている間は プライマリ データベースから REDO データを受信せず 障害時保護を提供できません プライマリ データベースがデータ消失に対して引き続き保護されるように 構成内に複数のフィジカル スタンバイ データベースを加えるようにしてください フィジカル スタンバイ データベースを本番データベースとしてアクティブ化し 後でプライマリ データベースと再同期化する手順は 次のとおりです 手順 1 フィジカル スタンバイ データベースをアクティブ化できるように準備する 1. フラッシュ リカバリ領域を設定します 読取り / 書込みアクセス用にアクティブ化されるフィジカル スタンバイ データベースで 保証付きのリストア ポイントを作成できるように次の初期化パラメータを設定する必要があります この使用例では /arch/oradata ディレクトリにフラッシュ リカバリ領域を設定します SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=20G; SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/arch/oradata'; 2. REDO Apply を取り消して保証付きリストア ポイントを作成します フィジカル スタンバイ データベースで REDO Apply を停止してリストア ポイントを作成します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> CREATE RESTORE POINT before_application_patch GUARANTEE FLASHBACK DATABASE; 保証付きリストア ポイントの作成時には 後で SCN または時点そのものを指定するかわりに名前でデータベースをフラッシュバックできるように タイムスタンプまたは SCN に覚えやすい名前を関連付けます 手順 2 フィジカル スタンバイの内容とのずれが生じるようにプライマリ データベースを準備する 1. 現行のログ ファイルをアーカイブします プライマリ データベースで リストア ポイント ( 手順 1 で作成 ) の SCN がフィジカル スタンバイ データベースにアーカイブされるように ログを切り替えます SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; スタンバイ REDO ログ ファイルを使用する場合 データベースをリストア ポイントに正常にフラッシュバックするには この手順が重要です 2. アクティブ化するスタンバイを指しているログ アーカイブ先を遅延させます プライマリ データベース ( これが Real Application Clusters の場合は全インスタンス上 ) で オープンするフィジカル スタンバイ データベースに関連付けられている宛先への REDO データのアーカイブを遅延させます 次に例を示します SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER; Data Guard の使用例 12-31

250 フィジカル スタンバイ データベースを使用した読取り / 書込みテストとレポート生成 手順 3 フィジカル スタンバイ データベースをアクティブ化するフィジカル スタンバイ データベースで次の手順を実行します 1. フィジカル スタンバイ データベースをアクティブ化します SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE; 2. フィジカル スタンバイ データベースがインスタンスの起動後に読取り専用でオープンされている場合は 次の手順を実行します それ以外の場合は 手順 3 にスキップします 次の文を入力してフィジカル スタンバイ データベースを停止した後再起動します SQL> STARTUP MOUNT FORCE; 3. 保護モードを最大パフォーマンスに設定してデータベースを読取り / 書込みアクセス用にオープンします SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE; SQL> ALTER DATABASE OPEN; スタンバイ データベースがアクティブ化された後 保護モードが最大パフォーマンス モードにダウングレードします これは 一時的に本番データベースとしてアクティブ化される間 データベースをデータ消失から保護するように構成されているスタンバイ データベースがないためです この保護モード設定は 元のプライマリ データベースの保護モードには影響せず アクティブ化されたスタンバイ データベースにのみ影響することに注意してください アクティブ化されたスタンバイ データベースが元のフィジカル スタンバイ データベースに変換されると 保護モードは自動的に元のプライマリ データベースにあわせて変更されます 一時的に読取り / 書込み用にオープンされたスタンバイ データベースにリモート アーカイブ ログ宛先があると その宛先を使用不可にする操作が必要になることがあります これにより 読取り / 書込みテストまたはレポート用データベースでの一時的な変更は 元の Data Guard 環境に含まれる他のスタンバイ データベースに伝播しなくなります 手順 4 アクティブ化されたデータベースをレポートまたはテストに使用するスタンバイ データベースがアクティブ化された後 プライマリ データベースに依存せずにレポート生成ツールを実行したり 他のテストやアクティビティを数日から数週間実行できます 注意 : データベースがアクティブ化されている間は プライマリ データベースから REDO データを受信せず 障害時保護を提供できません プライマリ データベースがデータ消失に対して引き続き保護されるように 構成内に複数のフィジカル スタンバイ データベースを加えるようにしてください また アクティブ化されたデータベースに格納された結果は 後でデータベースをフラッシュバックすると消失します 保存する必要のある結果は アクティブ化されたデータベースをフラッシュバックする前に 他のデータベースにコピーする必要があります 手順 5 アクティブ化されたデータベースを元のフィジカル スタンバイ データベースに戻すテストを完了した後 アクティブ化されたデータベースをプライマリ データベースと再同期化する必要があります アクティブ化されたデータベースで次の文を発行して 保証付きリストア ポイントに迅速にフラッシュバックし プライマリ データベースと再同期化します SQL> STARTUP MOUNT FORCE; SQL> FLASHBACK DATABASE TO RESTORE POINT before_application_patch; SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SQL> STARTUP MOUNT FORCE; Oracle Data Guard 概要および管理

251 フィジカル スタンバイ データベースを使用した読取り / 書込みテストとレポート生成 手順 6 スタンバイ データベースをプライマリ データベースと一致させる使用する方法は アクティブ化されたスタンバイ データベースが REDO データの適用に関してプライマリ データベースからどの程度遅れているかに応じて異なります アーカイブ ギャップ解消に 欠落しているアーカイブ REDO ログ ファイルをすべてフェッチさせ REDO Apply でギャップを適用できるようにします アクティブ化されたデータベースが元のプライマリ データベースからあまり遅れていない場合は スタンバイ データベースで次の文を発行し プライマリ データベースと再同期化して REDO Apply を再開します 次に例を示します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; その後 手順 7 に進みます プライマリ データベースで増分バックアップを作成してスタンバイ データベースに適用します アクティブ化されたデータベースが元のプライマリ データベースから大幅に遅れている場合 ( 十分なログ ファイルが使用可能でない場合など ) は プライマリ データベースから増分バックアップを作成して スタンバイ データベースに適用できます Recovery Manager の増分バックアップを使用してスタンバイ データベースをプライマリ データベースと再同期化する方法については 項を参照してください 注意 : スタンバイ データベースがプライマリ データベースから大幅に遅れている場合は 項で説明する手順でプライマリ データベースから作成した増分バックアップを適用する方が迅速な場合があります スタンバイ データベースに増分バックアップを適用した後 通常はスタンバイ データベースにさらに REDO を適用し フィジカル スタンバイ データベースを再び読取り / 書込みテストおよびレポート生成用にアクティブ化する必要があります さらに 増分バックアップの実行中にプライマリ データベースにより生成された REDO の適用も必要になる場合があります 適用しないと ALTER DATABSE ACTIVATE STANDBY DATABASE を発行した場合にエラーが戻されます 手順 7 フィジカル スタンバイ データベースの宛先へのアーカイブを再び使用可能にするプライマリ データベースで 次の文を発行して フィジカル スタンバイ データベースへのアーカイブを再び使用可能にします SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE; Data Guard の使用例 12-33

252 Recovery Manager の増分バックアップによるフィジカル スタンバイ データベースのロールフォワード 12.7 Recovery Manager の増分バックアップによるフィジカル スタンバイ データベースのロールフォワード Recovery Manager の増分バックアップを使用して フィジカル スタンバイ データベースをプライマリ データベースと同期化できる場合があります Recovery Manager の BACKUP INCREMENTAL FROM SCN コマンドを使用すると プライマリ データベースでスタンバイ データベースの現行 SCN から始まるバックアップを作成し それを使用してスタンバイ データベースをロールフォワードできます 次の各項では Recovery Manager の増分バックアップが役立つ状況について説明します フィジカル スタンバイ データベースがプライマリ データベースから大幅に遅れている場合 フィジカル スタンバイ データベースのデータファイルのサブセットにロギングなしの変更がある場合 フィジカル スタンバイ データベースの広範囲にロギングなしの変更がある場合 関連項目 : Recovery Manager の増分バックアップの詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください フィジカル スタンバイ データベースがプライマリ データベースから大幅に遅れている場合 フィジカル スタンバイ データベースがプライマリ データベースから大幅に遅れている場合は Recovery Manager の増分バックアップを使用すると REDO ログ適用より高速でスタンバイ データベースをロールフォワードできます この手順では Recovery Manager の BACKUP INCREMENTAL FROM SCN コマンドを使用して スタンバイ データベースの現行 SCN から始まる増分バックアップをプライマリ データベースで作成し それを使用してスタンバイ データベースをロールフォワードします 注意 : フィジカル スタンバイ データベースのアーカイブ REDO データが消失または破損した場合や 解消できないアーカイブ ギャップがある場合も この項で説明する手順に従って問題を解決できます 1. スタンバイ データベースで 管理リカバリ プロセス (MRP) を停止します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 2. スタンバイ データベースで プライマリ データベースでの増分バックアップに使用する SCN を見つけます SQL> SELECT CURRENT_SCN FROM V$DATABASE; 3. Recovery Manager で プライマリ データベースに接続し 前の手順で見つけた SCN から増分バックアップを作成します RMAN> BACKUP INCREMENTAL FROM SCN <SCN from previous step> DATABASE FORMAT '/tmp/forstandby_%u' tag 'FORSTANDBY'; Oracle Data Guard 概要および管理

253 Recovery Manager の増分バックアップによるフィジカル スタンバイ データベースのロールフォワード 注意 : Recovery Manager では 増分バックアップはソース データベースのバックアップ対策の一部とはみなされません したがって 次のようになります このバックアップは ソース データベースで通常の RECOVER DATABASE 操作に使用するには適していません このバックアップは ソース データベースではカタログに追加されません ディスク バックアップのデフォルトとしてフラッシュ リカバリ領域または他のバックアップ先が定義されている場合も このコマンドで生成されるバックアップ セットはデフォルトで /dbs ディレクトリに書き込まれます この増分バックアップを使用するには ディスクに作成する必要があります 増分バックアップをスタンバイ データベースに移動するときに スタンバイ データベースでカタログに追加する必要があります 詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください テープ上のバックアップはカタログに追加できません 4. プライマリ システムで作成されたすべてのバックアップ セットを スタンバイ システムに転送します ( 複数のバックアップ ファイルが作成される場合があることに注意してください ) 次に例を示します SCP /tmp/forstandby_* standby:/tmp 5. Recovery Manager ターゲットとしてスタンバイ データベースに接続し すべての増分バックアップ ピースをカタログに追加します RMAN> CATALOG START WITH '/tmp/forstandby'; 6. カタログ化された増分バックアップを使用して スタンバイ データベースをリカバリします RMAN> RECOVER DATABASE NOREDO; 7. Recovery Manager でプライマリ データベースに接続し スタンバイ制御ファイルのバックアップを作成します RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/tmp/forstandbyctrl.bck'; 8. スタンバイ システムにスタンバイ制御ファイルのバックアップをコピーします 次に例を示します SCP /tmp/forstandbyctrl.bck standby:/tmp 9. スタンバイ データベースを停止し ノーマウント状態で起動します RMAN> SHUTDOWN; RMAN> STARTUP NOMOUNT; 10. Recovery Manager でスタンバイ データベースに接続し スタンバイ制御ファイルをリストアします RMAN> RESTORE STANDBY CONTROLFILE FROM '/tmp/forstandbyctrl.bck'; 11. スタンバイ データベースを停止し マウント状態で起動します RMAN> SHUTDOWN; RMAN> STARTUP MOUNT; Data Guard の使用例 12-35

254 Recovery Manager の増分バックアップによるフィジカル スタンバイ データベースのロールフォワード 12. プライマリおよびスタンバイ データベースのデータファイル ディレクトリが同一である場合は 手順 13 に進みます プライマリおよびスタンバイ データベースのデータファイル ディレクトリが異なる場合は Recovery Manager でスタンバイ データベースに接続し スタンバイ データファイルをカタログ化し そのカタログ化したデータファイルを使用するようにスタンバイ データベースを切り替えます 次に例を示します RMAN> CATALOG START WITH '+DATA_1/CHICAGO/DATAFILE/'; RMAN> SWITCH DATABASE TO COPY; 13. プライマリおよびスタンバイ データベースの REDO ログ ディレクトリが同一である場合は 手順 14 に進みます 異なる場合は スタンバイ データベースで OS のユーティリティまたは asmcmd ユーティリティ (ASM 管理データベースである場合 ) を使用して スタンバイ ディレクトリからすべてのオンライン REDO ログおよびスタンバイ REDO ログを削除し ログ ディレクトリ パスを変換するように LOG_FILE_NAME_CONVERT パラメータが適切に定義されていることを確認します 例 : LOG_FILE_NAME_CONVERT='/BOSTON/','/CHICAGO/' など 14. スタンバイ データベースで スタンバイ REDO ログ グループをすべて消去します (3 つを超える可能性があります ) SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1; SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2; SQL> ALTER DATABASE CLEAR LOGFILE GROUP 3; 15. スタンバイ データベースで フラッシュバック データベースを再起動します SQL> ALTER DATABASE FLASHBACK OFF; SQL> ALTER DATABASE FLASHBACK ON; 16. スタンバイ データベースで MRP を再開します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; フィジカル スタンバイ データベースのデータファイルのサブセットにロギングなしの変更がある場合 ロギングなしの変更が小さいサブセットに適用されたフィジカル スタンバイ データベースをロールフォワードする手順は 次のとおりです 1. スタンバイ データベースで V$DATAFILE ビューを問い合せ ロギングなしの変更が適用されたファイルをリストします 次に例を示します SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE 2> WHERE FIRST_NONLOGGED_SCN > 0; FILE# FIRST_NONLOGGED_SCN スタンバイ データベースで REDO Apply を停止します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 3. スタンバイ データベースで ロギングなしの変更を含むデータファイル ( 手順 1 で記録 ) をオフラインにします これらのデータファイルをオフラインにすると 増分バックアップの実行中に破損ブロックの REDO データがスキップされなくなります SQL> ALTER DATABASE DATAFILE 4 OFFLINE FOR DROP; SQL> ALTER DATABASE DATAFILE 5 OFFLINE FOR DROP; 4. スタンバイ データベースで REDO Apply を開始します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE DISCONNECT; Oracle Data Guard 概要および管理

255 Recovery Manager の増分バックアップによるフィジカル スタンバイ データベースのロールフォワード 5. Recovery Manager ターゲットとしてプライマリ データベースに接続し FIRST_NONLOGGED_SCN 列に表示されたデータファイルごとに ( 手順 1 で記録 ) 増分バックアップを作成します 次に例を示します RMAN> BACKUP INCREMENTAL FROM SCN DATAFILE 4 FORMAT '/tmp/forstandby_%u' TAG 'FOR STANDBY'; RMAN> BACKUP INCREMENTAL FROM SCN DATAFILE 5 FORMAT '/tmp/forstandby_%u' TAG 'FOR STANDBY'; 6. プライマリ システムに作成されたすべてのバックアップ セットを スタンバイ システムに転送します ( 複数のバックアップ ファイルが作成されている場合があることに注意してください ) SCP /tmp/forstandby_* standby:/tmp 7. Recovery Manager ターゲットとしてフィジカル スタンバイ データベースに接続し すべての増分バックアップ ピースをカタログに追加します 次に例を示します RMAN> CATALOG START WITH '/tmp/forstandby_'; 8. スタンバイ データベースで REDO Apply を停止します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 9. スタンバイ データベースでデータファイルをオンラインにします SQL> ALTER DATABASE DATAFILE 4 ONLINE; SQL> ALTER DATABASE DATAFILE 5 ONLINE; 10. Recovery Manager ターゲットとしてフィジカル スタンバイ データベースに接続している間に 増分バックアップ セットを適用します RMAN> RECOVER DATAFILE 4, 5 NOREDO; 11. スタンバイ データベースで V$DATAFILE ビューを問い合せ ロギングなしの変更を含むデータファイルがないことを確認します 次の問合せでは 0( ゼロ ) 行が戻されます SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE 2> WHERE FIRST_NONLOGGED_SCN > 0; 12. スタンバイ システムから増分バックアップを削除します RMAN> DELETE BACKUP TAG 'FOR STANDBY'; 13. プライマリ システムから増分バックアップを手動で削除します たとえば 次の例では Linux の rm コマンドを使用しています rm /tmp/forstandby_* 14. スタンバイ データベースで REDO Apply を開始します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; Data Guard の使用例 12-37

256 Recovery Manager の増分バックアップによるフィジカル スタンバイ データベースのロールフォワード フィジカル スタンバイ データベースの広範囲にロギングなしの変更がある場合 ロギングなしの変更が大部分に適用されたフィジカル スタンバイ データベースをロールフォワードする手順は 次のとおりです 1. スタンバイ データベースで V$DATAFILE ビューを問い合せ 最小の FIRST_NONLOGGED_SCN を記録します SQL> SELECT MIN(FIRST_NONLOGGED_SCN) FROM V$DATAFILE 2> WHERE FIRST_NONLOGGED_SCN>0; MIN(FIRST_NONLOGGED_SCN) スタンバイ データベースで REDO Apply を停止します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 3. Recovery Manager ターゲットとしてプライマリ データベースに接続している間に 最小の FIRST_NONLOGGED_SCN( 手順 1 で記録 ) から増分バックアップを作成します RMAN> BACKUP INCREMENTAL FROM SCN DATABASE FORMAT '/tmp/forstandby_%u' tag 'FOR STANDBY'; 4. プライマリ システムに作成されたすべてのバックアップ セットを スタンバイ システムに転送します ( 複数のバックアップ ファイルが作成されている場合があることに注意してください ) 次の例では scp コマンドを使用してファイルをコピーします scp /tmp/forstandby_* standby:/tmp 5. Recovery Manager ターゲットとしてスタンバイ データベースに接続している間に すべての増分バックアップ ピースをカタログに追加します RMAN> CATALOG START WITH '/tmp/forstandby_'; 6. Recovery Manager ターゲットとしてスタンバイ データベースに接続している間に 増分バックアップを適用します RMAN> RECOVER DATABASE NOREDO; 7. V$DATAFILE ビューを問い合せ ロギングなしの変更を含むデータファイルがないことを確認します スタンバイ データベースで次の問合せを実行すると 0( ゼロ ) の行が戻されます SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE 2> WHERE FIRST_NONLOGGED_SCN > 0; 8. スタンバイ システムから増分バックアップを削除します RMAN> DELETE BACKUP TAG 'FOR STANDBY'; 9. プライマリ システムから増分バックアップを手動で削除します たとえば 次の例では Linux の rm コマンドを使用してバックアップを削除しています rm /tmp/forstandby_* 10. スタンバイ データベースで REDO Apply を開始します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE DISCONNECT; Oracle Data Guard 概要および管理

257 タイム ラグのあるフィジカル スタンバイ データベースの使用 12.8 タイム ラグのあるフィジカル スタンバイ データベースの使用 ログ適用サービスがスタンバイ データベースで実行されている場合 デフォルトでは REDO データはアーカイブ ログ ファイルに書き込まれて適用されるか リアルタイム適用が使用可能であれば REDO はプライマリ データベースからの送信時にスタンバイ データベースへ書き込まれます ただし プライマリ サイトのオンライン REDO ログ ファイルのアーカイブとスタンバイ サイトのアーカイブ REDO ログ ファイルの適用の間にタイム ラグを作成することが必要な場合があります タイム ラグによって プライマリ サイトからスタンバイ サイトへ破損したまたは誤ったデータが送られてもスタンバイ データベースを保護できます タイム ディレイを設定すると スタンバイ データベースへの REDO データの転送が遅延することはありません かわりに 指定したタイム ラグは REDO データがスタンバイ宛先で完全にアーカイブされたときに開始します たとえば 毎晩プライマリ データベースでバッチ ジョブを実行するとします 誤ってバッチ ジョブを 2 回実行してしまい しかも 2 回の実行が完了するまでその誤操作に気づかなかったとします 理想的には バッチ ジョブを開始する前の状態までデータベースをロールバックする必要があります タイム ラグのあるスタンバイ データベースを持つプライマリ データベースを使用すると リカバリに役立ちます タイム ラグのあるスタンバイ データベースにフェイルオーバーして それを新規のプライマリ データベースとして使用できます タイム ラグのあるスタンバイ データベースを作成するには プライマリ データベースの初期化パラメータ ファイルにある LOG_ARCHIVE_DEST_n 初期化パラメータの DELAY 属性を使用します 注意 : リアルタイム適用が使用可能な宛先に遅延を定義した場合 その遅延は無視されます REDO データは通常どおりプライマリ データベースからスタンバイ データベースに自動転送され アーカイブ REDO ログ ファイル ( 実装されている場合は スタンバイ REDO ログ ファイルにも ) に書き込まれますが ログ ファイルはすぐにはスタンバイ データベースに適用されません ログ ファイルが適用されるのは 指定した時間が経過した後です この例では 4 時間のタイム ラグが採用されています この例に含まれる項目は 次のとおりです フィジカル スタンバイ データベースでのタイム ラグの設定 タイム ラグのあるフィジカル スタンバイ データベースへのフェイルオーバー タイム ラグのあるフィジカル スタンバイ データベースへのスイッチオーバー この例では 読者が通常のスタンバイ データベースの作成手順を理解していることを前提にしています したがって この例で示す手順では詳細を省略しています フィジカル スタンバイ データベースの作成の詳細は 第 3 章を参照してください Data Guard の使用例 12-39

258 タイム ラグのあるフィジカル スタンバイ データベースの使用 フィジカル スタンバイ データベースでのタイム ラグの設定 タイム ラグのあるフィジカル スタンバイ データベースを作成するには プライマリ データベースの LOG_ARCHIVE_DEST_n 初期化パラメータを変更して スタンバイ データベースの遅延を設定します 次に 4 時間の遅延を LOG_ARCHIVE_DEST_n 初期化パラメータに追加する方法の例を示します SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stdby DELAY=240'; この DELAY 属性は スタンバイ サイトでは 4 時間が経過しないと アーカイブ REDO ログ ファイルがリカバリに使用されないことを示します アーカイブ REDO ログ ファイルがスタンバイ サイトに正常にアーカイブされると 設定された時間間隔 ( 分で表示 ) が始まります REDO 情報は通常どおりスタンバイ データベースに送信され ディスクに書き込まれます フィジカルおよびロジカル スタンバイ データベースでのタイム ラグの設定の詳細は 項を参照してください タイム ラグのあるフィジカル スタンバイ データベースへのフェイルオーバー アーカイブ REDO ログ ファイルの適用を遅延するように構成したスタンバイ データベースは プライマリ データベースでのユーザーのミスやデータ破損のリカバリに使用できます ほとんどの場合は タイム ディレイが設定されているスタンバイ データベースを問い合せて プライマリ データベースの修正 ( 誤って削除した表の内容のリカバリなど ) に必要なデータを取得できます プライマリ データベースの被害が不明な場合やプライマリ データベースの修正にかなりの時間が必要な場合は タイム ディレイが設定されているスタンバイ データベースへのフェイルオーバーも考慮できます 不注意によって バックアップ ファイルがプライマリ データベースに 2 回適用され プライマリ データベースの修正にかなりの時間が必要であると仮定します ここでは アーカイブ REDO ログ ファイルの適用が遅延されているフィジカル スタンバイ データベースへのフェイルオーバーを選択します これによって スタンバイ データベースを 問題が発生する以前の時点のプライマリ ロールに推移させますが 一部のデータは消失することになります 処理の手順は 次のとおりです 1. タイム ディレイが設定されているフィジカル スタンバイ データベースで適切な SQL 文を発行することで フェイルオーバーを開始します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE; SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP ACTIVATE 文は スタンバイ データベースをプライマリ ロールに即時に推移させ スタンバイ ロケーションに存在している可能性のある他の REDO データの適用は行いません この文を使用する場合は スタンバイ ロケーションでのデータ消失のコストと プライマリ データベースの完全修正に必要な停止時間の延長のバランスを注意深く調整する必要があります 2. この新しいプライマリ データベースのコピーから 構成内にある他のすべてのスタンバイ データベースを再作成します Oracle Data Guard 概要および管理

259 タイム ラグのあるフィジカル スタンバイ データベースの使用 タイム ラグのあるフィジカル スタンバイ データベースへのスイッチオーバー スタンバイ サイトが使用可能になると REDO データはすべてそこに転送されます したがって タイム ディレイがスタンバイ データベースに指定されている場合でも SQL 文 ALTER DATABASE RECOVER MANAGED STANDBY を使用して遅延を無視することで スタンバイ データベースを最新の状態にできます 注意 : 論理的なエラーのリカバリには スイッチオーバーではなく フェイルオーバーを実行する必要があります 次の手順に従って タイム ディレイが設定されたフィジカル スタンバイ データベース ( タイム ラグをバイパスする ) へのスイッチオーバーを実行する方法を説明します この例では プライマリ データベースはニューヨークに スタンバイ データベースはボストンにあると仮定します 手順 1 すべてのアーカイブ REDO ログ ファイルを タイム ラグをバイパスしている元の ( タイム ディレイが設定された ) スタンバイ データベースに適用するスタンバイ データベースですべてのアーカイブ REDO ログ ファイルが適用されるまで スイッチオーバーは開始しません NODELAY キーワードを使用して遅延を解除することにより スタンバイ データベースは アーカイブ REDO ログ ファイルの適用前に指定した時間が経過するのを待たずに処理を続行できます 遅延を解除するには 次の SQL 文を発行します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY 2> DISCONNECT FROM SESSION THROUGH LAST SWITCHOVER; 手順 2 プライマリ データベースとスタンバイ データベースでの読取りまたは更新アクティビティを停止するスイッチオーバーを開始するには 排他的なデータベース アクセス権限が必要です ユーザーにプライマリおよびスタンバイ データベースからログオフするように求めるか V$SESSION ビューを問い合せてデータベースに接続しているユーザーを識別し スイッチオーバー文を実行する SQL*Plus セッションを除くすべてのオープン セッションをクローズします ユーザーの管理の詳細は Oracle Database 管理者ガイド を参照してください 手順 3 プライマリ データベースをフィジカル スタンバイ ロールに切り換えるニューヨークのプライマリ データベースで 次の文を実行します SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY 2> WITH SESSION SHUTDOWN; この文は次のことを行います プライマリ データベースをクローズし アクティブなセッションを終了します アーカイブされていない REDO ログ ファイルを転送し それらをボストンのスタンバイ データベースに適用します 最後にアーカイブされるログ ファイルのヘッダーに end-of-redo マーカーを追加します 現行の制御ファイルのバックアップを作成します 現行の制御ファイルをスタンバイ制御ファイルに変換します 手順 4 元のプライマリ インスタンスを停止して起動し データベースをマウントするニューヨークにある元のプライマリ データベースで次の文を実行します SQL> SHUTDOWN NORMAL; SQL> STARTUP MOUNT; Data Guard の使用例 12-41

260 ネットワーク障害のリカバリ 手順 5 元のスタンバイ データベースをプライマリ ロールに切り替える次の SQL 文を発行します SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY DATABASE; 手順 6 新しいプライマリ データベース インスタンスを停止して再起動する次の SQL 文を発行します SQL> SHUTDOWN; 12.9 ネットワーク障害のリカバリ 次の手順に従って ネットワーク障害後のリカバリ方法を説明します 手順 1 ネットワーク障害を識別する V$ARCHIVE_DEST ビューは ネットワーク エラーを格納し 到達できないスタンバイ データベースを識別します プライマリ データベースでは ネットワーク障害が発生した宛先に対して次の SQL 文を実行します 次に例を示します SQL> SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID = 2; DEST_ID STATUS ERROR ERROR ORA-12224: TNS:no listener 問合せの結果 スタンバイ データベースへのアーカイブにエラーがあり 原因は TNS: リスナーがありません であることがわかりました スタンバイ サイトでリスナーが起動されているかどうかを調べる必要があります リスナーが停止している場合は 起動してください 手順 2 プライマリ データベースが停止するのを回避するネットワーク問題を迅速に解決できない場合 およびスタンバイ データベースが必須の宛先として指定されている場合は 次のいずれかを実行して データベースが停止しないようにしてください 必須のアーカイブ先へのアーカイブを遅延します SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = DEFER; ネットワーク問題が解決すると アーカイブ先をもう一度使用可能にできます SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = ENABLE; 必須のアーカイブ先をオプションに変更します SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'SERVICE=standby1 2> OPTIONAL REOPEN=60'; ネットワーク問題が解決すると アーカイブ先をオプションから必須に戻すことができます SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'SERVICE=standby1 2> MANDATORY REOPEN=60'; 手順 3 カレント オンライン REDO ログ ファイルをアーカイブするプライマリ データベースで カレント オンライン REDO ログ ファイルをアーカイブします SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; ネットワークが再開され フィジカル スタンバイ データベースで REDO Apply が再開されると ログ適用サービスによるアーカイブ ギャップの自動的な検出と解決が可能となります Oracle Data Guard 概要および管理

261 NOLOGGING 句を指定した後のリカバリ NOLOGGING 句を指定した後のリカバリ 一部の SQL 文には NOLOGGING 句を指定するオプションがあります このオプションによって データベースに関する操作をオンライン REDO ログ ファイルに記録しないように指定できます ユーザーがこの句を指定しても REDO レコードはオンライン REDO ログ ファイルに書き込まれます ただし このレコードに関連したデータはありません これが結果的に スタンバイ サイトでのログ適用エラーやデータ アクセス エラーの原因となり ログ ファイルの適用の再開で 手動によるリカバリが必要となります 注意 : この問題を回避するには CREATE DATABASE または ALTER DATABASE 文に FORCE LOGGING 句を常に指定することをお薦めします Oracle Database 管理者ガイド を参照してください ロジカル スタンバイ データベースのリカバリ手順 ロジカル スタンバイ データベースの場合は SQL Apply で NOLOGGING 句を使用した操作の REDO ログ レコードが検出されると そのレコードはスキップされ 後続のレコードから変更の適用が続行されます その後 NOLOGGING を実際に使用して更新されたレコードの 1 つにアクセスしようとすると ORA データが見つかりません エラーが戻されます NOLOGGING 句を指定した後のリカバリには 項に説明されているように プライマリ データベースから 1 つ以上の表を再作成します 注意 : 通常 NOLOGGING 句の使用はお薦めしません また プライマリ データベース内の特定の表で NOLOGGING 句を使用する操作が実行されることが事前にわかっている場合は DBMS_LOGSTDBY.SKIP プロシージャを使用して これらの表に関連付けられている SQL 文をロジカル スタンバイ データベースに適用しないようにできます フィジカル スタンバイ データベースのリカバリ手順 スタンバイ サイトにコピーされたアーカイブ REDO ログ ファイルがフィジカル スタンバイ データベースに適用されると データファイルの一部が使用不可能となり リカバリ不能のマークが付けられます フィジカル スタンバイ データベースにフェイルオーバーするか 読取り専用アクセスでスタンバイ データベースをオープンし UNRECOVERABLE のマークが付けられたブロックの範囲を読み取ろうとすると 次のようなエラー メッセージが表示されます ORA-01578: Oracle データ ブロックに障害が発生しました ( ファイル番号 1 ブロック番号 2521) ORA-01110: データファイル 1: '/oracle/dbs/stdby/tbs_1.dbf' ORA-26040: データ ブロックが NOLOGGING オプションを使用してロードされました NOLOGGING 句が指定された後でリカバリするには 欠落している REDO データが含まれているデータファイルをプライマリ サイトからフィジカル スタンバイ サイトにコピーする必要があります 次の手順に従ってください Data Guard の使用例 12-43

262 NOLOGGING 句を指定した後のリカバリ 手順 1 コピーするデータファイルを判別する次の手順に従います 1. プライマリ データベースを問い合せます SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE; NAME UNRECOVERABLE /oracle/dbs/tbs_1.dbf 5216 /oracle/dbs/tbs_2.dbf 0 /oracle/dbs/tbs_3.dbf 0 /oracle/dbs/tbs_4.dbf 0 4 rows selected. 2. スタンバイ データベースを問い合せます SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE; NAME UNRECOVERABLE /oracle/dbs/stdby/tbs_1.dbf 5186 /oracle/dbs/stdby/tbs_2.dbf 0 /oracle/dbs/stdby/tbs_3.dbf 0 /oracle/dbs/stdby/tbs_4.dbf 0 4 rows selected. 3. プライマリ データベースの問合せ結果とスタンバイ データベースの問合せ結果を比較します 両方の問合せ結果の UNRECOVERABLE_CHANGE# 列の値を比較します プライマリ データベースの UNRECOVERABLE_CHANGE# 列の値の方が スタンバイ データベースの同じ列の値より大きい場合は データファイルをプライマリ サイトからスタンバイ サイトへコピーする必要があります この例では tbs_1.dbf データファイルのプライマリ データベースにある UNRECOVERABLE_CHANGE# の値の方が大きいため tbs_1.dbf データファイルをスタンバイ サイトへコピーする必要があります 手順 2 プライマリ サイトで スタンバイ サイトにコピーする必要があるデータファイルのバックアップを作成する次の SQL 文を発行します SQL> ALTER TABLESPACE system BEGIN BACKUP; SQL> EXIT; % cp tbs_1.dbf /backup SQL> ALTER TABLESPACE system END BACKUP; 手順 3 データファイルをスタンバイ データベースにコピーする欠落している REDO データが含まれているデータファイルを プライマリ サイトからリカバリ関連のファイルが格納されているフィジカル スタンバイ サイトにコピーします Oracle Data Guard 概要および管理

263 NOLOGGING 句を指定した後のリカバリ 手順 4 スタンバイ データベースで REDO Apply を再開する次の SQL 文を発行します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; REDO Apply を再開しようとすると 次のエラー メッセージが ( 通常アラート ログに ) 表示されることがあります ORA-00308: アーカイブ ログ standby1 をオープンできません ORA-27037: ファイル ステータスを取得できません SVR4 Error: 2: No such file or directory Additional information: 3 ORA-01547: 警告 : RECOVER は成功しましたが OPEN RESETLOGS が次のエラーを受け取りました ORA-01152: ファイル 1 は十分に古いバックアップからリストアされていません ORA-01110: データファイル 1: '/oracle/dbs/stdby/tbs_1.dbf' ORA エラーが表示され REDO Apply が自動的に終了しない場合は 別の端末のウィンドウから次の文を発行して リカバリを取り消すことができます SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; これらのエラー メッセージは アーカイブ ギャップ内にある 1 つ以上のログ ファイルが正常に適用されなかった場合に戻されます これらのエラーを受け取った場合は ギャップを手動で解決し 手順 4 を繰り返します アーカイブ ギャップの手動による解決方法については 項を参照してください リカバリ不能処理後にバックアップが必要かどうかの判断 プライマリ データベースでリカバリ不能な操作を実行した場合は 次の手順に従って新しいバックアップ操作が必要かどうかを判断します 1. プライマリ データベースで V$DATAFILE ビューを問い合せ システム変更番号 (SCN) ( または Oracle データベースが無効な REDO データを生成した最新の時刻を判別します 2. プライマリ データベースで次の SQL 文を発行して 新たにバックアップを実行する必要があるかどうかを判断します SELECT UNRECOVERABLE_CHANGE#, TO_CHAR(UNRECOVERABLE_TIME, 'mm-dd-yyyy hh:mi:ss') FROM V$DATAFILE; 3. 前の手順での問合せで データファイルが最後にバックアップされた時刻より後のデータファイル リカバリ不能時刻が報告された場合は 問題となっているデータファイルのバックアップを新たに作成します V$DATAFILE ビューの詳細は Oracle Database リファレンス を参照してください Data Guard の使用例 12-45

264 手動によるアーカイブ ギャップの解決 手動によるアーカイブ ギャップの解決 アーカイブ ギャップとは アーカイブ REDO ログ ファイルの特定の範囲を指します この範囲は プライマリ データベースで生成される次のアーカイブ REDO ログ ファイルをスタンバイ データベースに適用できないときは常に発生します この項は 次の項目で構成されています アーカイブ ギャップの発生原因 アーカイブ ギャップが存在するかどうかの判断 スタンバイ サイトへのアーカイブ ギャップ ログ ファイルの手動による転送 スタンバイ データベースへのアーカイブ ギャップ ログ ファイルの手動による適用 注意 : 通常 アーカイブ ギャップは手動操作を行うことなく自動的に解決されます ログ適用サービスがアーカイブ REDO ログ ファイル内にあるギャップを自動的にリカバリする方法の詳細は 5.8 項を参照してください アーカイブ ギャップの発生原因 アーカイブ ギャップは プライマリ データベースでカレント オンライン REDO ログ ファイルがローカルにアーカイブされても REDO データがスタンバイ サイトにアーカイブされなかった場合は常に発生する可能性があります スタンバイ データベースにはログ ファイルを順序番号順に適用する必要があるため メディア リカバリは 最初の欠落ログ ファイルに遭遇すると停止します アーカイブ ギャップは次の状況で発生することがあります スタンバイ データベースの作成 プライマリ データベースがオープンしている間のスタンバイ データベースの停止 REDO の転送を妨げるネットワーク障害 スタンバイ データベースの作成 アーカイブ ギャップは スタンバイ データベースを古いバックアップから作成すると発生します たとえば スタンバイ データベースが ログ ファイル 100 の変更を含むバックアップから作成されているとします このときプライマリ データベースに 現在ログ ファイル 150 の変更が含まれているとすると スタンバイ データベースは ログ ファイル 101 からログ ファイル 150 までの適用を要求します オープン データベースのホット バックアップからスタンバイ データベースを生成する場合も 通常アーカイブ ギャップが発生します たとえば 図 12-8 の使用例を想定します Oracle Data Guard 概要および管理

265 手動によるアーカイブ ギャップの解決 図 12-8 アーカイブ ギャップ内にあるアーカイブ REDO ログ ファイルの手動リカバリ 次の手順を実行します 1. プライマリ データベースのホット バックアップを取得します 2. ネットワーク ファイルを構築している時間 t で プライマリはログ ファイル順序の 4 および 5 をアーカイブします 3. 時間 t + 1 で スタンバイ インスタンスを起動します 4. プライマリは REDO ログ ファイル順序 6 7 および 8 をプライマリ サイトにアーカイブし REDO をスタンバイ サイトに転送します アーカイブ REDO ログ ファイルの順序 4 および 5 はこれでアーカイブ ギャップの一部となり これらのログ ファイルはスタンバイ データベースに適用する必要があります プライマリ データベースがオープンしている間のスタンバイ データベースの停止 メンテナンス問題を解決するため スタンバイ データベースの停止が必要になることがあります たとえば プライマリ データベース内で MAXDATAFILE のような制御ファイル パラメータを変更するときには スタンバイ データベースを停止する必要があります アーカイブ ギャップの発生を避けるために 次のルールを実行します プライマリ データベースを起動する前にスタンバイ データベースとリスナーを起動します スタンバイ データベースを停止する前にプライマリ データベースを停止します Data Guard の使用例 12-47

266 手動によるアーカイブ ギャップの解決 これら 2 つのルールに違反すると プライマリ データベースがオープンし アーカイブを実行しているときにスタンバイ データベースが停止します 結果として アーカイブ ギャップが発生します 注意 : スタンバイ サイトが プライマリ初期化パラメータ ファイルの LOG_ARCHIVE_DEST_n パラメータの 1 つにおいて MANDATORY と指定されている場合は スタンバイ データベースを停止する前に それを動的に OPTIONAL に変更します これを行わないと プライマリ データベースはオンライン REDO ログ ファイルをアーカイブできないため停止します REDO の転送を妨げるネットワーク障害 Data Guard 環境をメンテナンスしているときにネットワークが停止すると プライマリ データベースはディスクへの書込みを継続しますが スタンバイ サイトには REDO を送信できません この状況では アーカイブ REDO ログ ファイルは通常どおり プライマリ サイトに蓄積されますが スタンバイ データベースはこれらのログ ファイルを認識できません 関連項目 : スタンバイ アーカイブにおける OPTIONAL 属性および MANDATORY 属性の重要性の詳細は 項を参照してください 関連する使用例については 12.9 項を参照してください アーカイブ ギャップが存在するかどうかの判断 アーカイブ ギャップが存在するかどうかを判断するには V$ARCHIVED_LOG ビューと V$LOG ビューを問い合せます アーカイブ ギャップが存在する場合 問合せの出力により アーカイブ ギャップ内にあるすべてのログ ファイルのスレッド番号およびログ順序番号が特定されます 指定されたスレッドにアーカイブ ギャップがない場合 問合せで戻される行はありません アーカイブ ギャップ内にあるログ ファイルの識別スタンバイ データベースの V$ARCHIVED_LOG ビューと V$LOG ビューを問い合せます たとえば 次の問合せは DEST_ID=2 で指定した宛先の RECD と SENT の順序番号に相違がある つまりギャップがあることを示しています SQL> SELECT MAX(R.SEQUENCE#) LAST_SEQ_RECD, MAX(L.SEQUENCE#) LAST_SEQ_SENT FROM 2> V$ARCHIVED_LOG R, V$LOG L WHERE 3> R.DEST_ID=2 AND L.ARCHIVED='YES'; LAST_SEQ_RECD LAST_SEQ_SENT 次の問合せを使用して ギャップが発生したスタンバイ システムにコピーすることが必要な ローカル システム上のアーカイブ REDO ログ ファイルの名前を判別します SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND 2> SEQUENCE# BETWEEN 7 AND 10; NAME /primary/thread1_dest/arcr_1_7.arc /primary/thread1_dest/arcr_1_8.arc /primary/thread1_dest/arcr_1_9.arc /primary/thread1_dest/arcr_1_10.arc Oracle Data Guard 概要および管理

267 手動によるアーカイブ ギャップの解決 スタンバイ サイトへのアーカイブ ギャップ ログ ファイルの手動による転送 アーカイブ ギャップ内にあるログ ファイル順序番号の取得後 プライマリ サイトの V$ARCHIVED_LOG ビューを問い合せて ファイル名を取得できます スタンバイ サイトのアーカイブ REDO ログ パス名は スタンバイ初期化パラメータ ファイルの STANDBY_ARCHIVE_DEST パラメータおよび LOG_ARCHIVE_FORMAT パラメータによって生成されます スタンバイ データベースがプライマリ データベースと同じサイトにある場合 またはスタンバイ データベースがプライマリ データベースと異なるディレクトリ構造を持つリモート サイトにある場合 スタンバイ サイトのログ ファイルのパス名は プライマリ データベースでアーカイブされたログ ファイルのパス名と同じにはなりません REDO データをスタンバイ サイトに転送する前に スタンバイ サイトでアーカイブ REDO ログ ファイルの正しいパス名を判別してください スタンバイ サイトにアーカイブ ギャップ内にあるログ ファイルをコピーする方法 1. 以前取得したアーカイブ ギャップ ログ ファイルのリストを見直します たとえば 次のアーカイブ ギャップがあると想定します THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# このビューに表示されているスレッドには アーカイブ ギャップが存在します したがって スレッド 1 ~ 3 のログ ファイルをコピーする必要があります 2. プライマリ データベースによって転送されたアーカイブ ギャップのログ ファイルのパス名を判別します プライマリ データベースに接続後 SQL 問合せを発行して各スレッドのログ ファイル名を取得します たとえば 次の SQL 文を使用して スレッド 1 のログ ファイルの名前を取得します SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 2> AND SEQUENCE# > 459 AND SEQUENCE# < 464; NAME /primary/thread1_dest/arcr_1_460.arc /primary/thread1_dest/arcr_1_461.arc /primary/thread1_dest/arcr_1_462.arc /primary/thread1_dest/arcr_1_463.arc 4 rows selected スレッド 2 と 3 について 同様の問合せを実行します 3. スタンバイ サイトで スタンバイ初期化パラメータ ファイル内の STANDBY_ARCHIVE_DEST および LOG_ARCHIVE_FORMAT の設定を見直します たとえば 次を発見したと想定します STANDBY_ARCHIVE_DEST = /standby/arc_dest/ LOG_ARCHIVE_FORMAT = log_%t_%s_%r.arc これらのパラメータの設定から スタンバイ サイトのアーカイブ REDO ログ ファイルのファイル名を判別できます Data Guard の使用例 12-49

268 手動によるアーカイブ ギャップの解決 4. プライマリ サイトで アーカイブ ギャップ ログ ファイルをプライマリ サイトからスタンバイ サイトへコピーし ログ ファイルの名前を STANDBY_ARCHIVE_DEST および LOG_ARCHIVE_FORMAT の値に応じて変更します たとえば 次の copy コマンドを入力して スレッド 1 に必要なアーカイブ ギャップ ログ ファイルをコピーします % cp /primary/thread1_dest/arcr_1_460.arc /standby/arc_dest/log_1_460.arc % cp /primary/thread1_dest/arcr_1_461.arc /standby/arc_dest/log_1_461.arc % cp /primary/thread1_dest/arcr_1_462.arc /standby/arc_dest/log_1_462.arc % cp /primary/thread1_dest/arcr_1_463.arc /standby/arc_dest/log_1_463.arc 同様のコマンドを使用して スレッド 2 と 3 のアーカイブ ギャップ ログ ファイルをコピーします 5. スタンバイ サイトで LOG_ARCHIVE_DEST パラメータと STANDBY_ARCHIVE_DEST パラメータの値が異なる場合は STANDBY_ARCHIVE_DEST ディレクトリのアーカイブ ギャップ ログ ファイルを LOG_ARCHIVE_DEST ディレクトリにコピーします これらのパラメータの値が同じ場合 この手順を実行する必要はありません たとえば 次のスタンバイ初期化パラメータが設定されているとします STANDBY_ARCHIVE_DEST = /standby/arc_dest/ LOG_ARCHIVE_DEST = /log_dest/ パラメータの値が異なるため アーカイブ REDO ログ ファイルを LOG_ARCHIVE_DEST の場所にコピーします % cp /standby/arc_dest/* /log_dest/ 手動リカバリを開始すると Oracle データベースは LOG_ARCHIVE_DEST 値を参照してログ ファイルの位置を判別します これで 必要なログ ファイルがすべて STANDBY_ARCHIVE_DEST ディレクトリにあるため 項に進んで アーカイブ ギャップ ログ ファイルをスタンバイ データベースに適用できます 項および第 16 章の V$ARCHIVED_LOG ビューも参照してください スタンバイ データベースへのアーカイブ ギャップ ログ ファイルの手動による適用 アーカイブ ギャップ内のログ ファイルをスタンバイ サイトにコピーした後 RECOVER AUTOMATIC 文を使用してそれらを適用できます アーカイブ ギャップ内にあるアーカイブ REDO ログ ファイルを適用する方法 1. スタンバイ データベースを起動してマウントします ( まだマウントされていない場合 ) たとえば 次のように入力します SQL> STARTUP MOUNT PFILE=/oracle/admin/pfile/initSTBY.ora 2. AUTOMATIC オプションを使用してデータベースをリカバリします SQL> ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE; AUTOMATIC オプションは リカバリ操作の継続に必要な次のアーカイブ REDO ログ ファイルの名前を自動的に生成します 利用可能なログ ファイルをリカバリすると Oracle データベースは現在存在しないログ ファイルの名前の入力を促します たとえば 次のように表示されます ORA-00308: アーカイブ ログ /oracle/standby/standby_logs/arcr_1_540.arc をオープンできません ORA-27037: ファイル ステータスを取得できません SVR4 Error: 2: No such file or directory Additional information: 3 Specify log: {<RET>=suggested filename AUTO CANCEL} Oracle Data Guard 概要および管理

269 OMF または ASM を使用するスタンバイ データベースの作成 3. Oracle データベースで利用可能なログ ファイルの適用後 CTRL+C キーによってリカバリを取り消します SQL> <CTRL/C> Media recovery cancelled. リカバリ取消し後に出力される次のエラー メッセージは許容できるもので 問題はありません ORA-01547: 警告 : RECOVER は成功しましたが OPEN RESETLOGS が次のエラーを受け取りました ORA-01194: ファイル 1 は一貫した状態にするためにさらにリカバリが必要です ORA-01110: データファイル 1: 'some_filename' ORA-01112: メディア リカバリが開始されていません 4. 欠落しているログ ファイルを手動で適用した後 次のようにしてスタンバイ データベースでログ適用サービスを再開できます SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; OMF または ASM を使用するスタンバイ データベースの作成 第 3 章および第 4 章では フィジカルおよびロジカル スタンバイ データベースの作成方法を説明しました この項では プライマリ データベースで Oracle Managed Files(OMF) または自動ストレージ管理 (ASM) を使用する場合に実行する必要のある追加手順を説明し これらの章を補完します 注意 : この項の説明は 読者がすでにフィジカル スタンバイ データベースの作成方法を理解しており Recovery Manager OMF および ASM 機能に習熟していることを前提としています 詳細は 次の資料を参照してください フィジカルおよびロジカル スタンバイ データベースの作成方法は 第 3 章 第 4 章および付録 F を参照してください OMF および ASM の詳細は Oracle Database 管理者ガイド 参照してください Recovery Manager の詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド および Oracle Database Recovery Manager リファレンス を参照してください スタンバイ データベースを作成する前に 次の準備作業を実行します 1. プライマリ データベースで強制ロギングを使用可能にします 2. プライマリ データベースでアーカイブを有効にします 3. プライマリ データベースで必要な初期化パラメータをすべて設定します 4. スタンバイ データベース用に初期化パラメータ ファイルを作成します 5. プライマリ データベースが OMF を使用するよう構成されている場合 スタンバイ データベースも OMF を使用するよう構成することをお薦めします これを行うには DB_CREATE_FILE_DEST および DB_CREATE_ONLINE_LOG_DEST_n 初期化パラメータに適切な値を設定します プライマリおよびスタンバイ データベースの両方で同じディスク グループ名が使用されている場合 メンテナンスや後のロールの推移が簡易化されます 6. STANDBY_FILE_MANAGEMENT 初期化パラメータに AUTO を設定します 7. スタンバイ データベースに接続するために 必要に応じて Oracle Net を構成します Data Guard の使用例 12-51

270 OMF または ASM を使用するスタンバイ データベースの作成 8. スタンバイ データベース用のリモート ログイン パスワード ファイルを作成します プライマリ データベースと同じパスワードを SYS アカウントに使用します 9. 制御ファイルをマウントせずにスタンバイ データベース インスタンスを起動します スタンバイ データベースを作成するには 次の作業を実行します 1. スタンバイ データベースで ASM を使用する場合 スタンバイ データベース システムに ASM インスタンスが存在していなければ インスタンスを作成します 2. Recovery Manager の BACKUP コマンドを使用して プライマリ データベースのデータファイル アーカイブ ログ ファイルおよびスタンバイ制御ファイルのコピーが含まれているバックアップ セットを作成します 3. Recovery Manager の DUPLICATE FOR STANDBY コマンドを使用して バックアップ セットのデータファイル アーカイブ REDO ログ ファイルおよびスタンバイ制御ファイルをスタンバイ データベースの格納場所にコピーします DUPLICATE FOR STANDBY コマンドは スタンバイ インスタンスでの実際のデータ移動を実行します バックアップ セットがテープ上に存在する場合 スタンバイ インスタンスがバックアップ セットを読み取れるよう メディア マネージャを構成する必要があります バックアップ セットがディスク上に存在する場合 バックアップ ピースはスタンバイ インスタンスによって読み取れる必要があります これには プライマリ パス名を NFS を介して取得可能にするか これらをスタンバイ システムにコピーし Recovery Manager の CATALOG BACKUPPIECE コマンドを使用してバックアップ ピースをリストア前にカタログに追加します これらの手順を完了した後 項の手順を実行してフィジカル スタンバイ データベースの構成を確認します ロジカル スタンバイ データベースを作成するには 第 4 章で説明されているスタンバイ データベースの作成プロセスを実行しますが 次の点を変更します 1. ロジカル スタンバイ データベースの場合 DB_CREATE_FILE_DEST パラメータを設定しても OMF ファイル名を強制的に作成しません ただし このパラメータをプライマリ データベースで設定する場合 スタンバイ データベースでも設定する必要があります 2. プライマリ システムでロジカル スタンバイ制御ファイルを作成した後 このファイルをスタンバイ システムにコピーするために オペレーティング システムのコマンドを使用しないでください かわりに Recovery Manager の RESTORE CONTROLFILE コマンドを使用して ロジカル スタンバイ制御ファイルのコピーをスタンバイ システムにリストアします 3. プライマリ データベースで OMF ファイルを使用する場合 スタンバイ データベースに作成された新しい OMF ファイルをスタンバイ データベース制御ファイルが使用するよう Recovery Manager を使用してスタンバイ データベース制御ファイルを更新します この操作を実行するには 次の例に示すように スタンバイ データベースにのみ接続します > RMAN TARGET sys/oracle@lstdby RMAN> CATALOG START WITH '+stby_diskgroup'; RMAN> SWITCH DATABASE TO COPY; これらの手順を完了した後 項の手順を実行してロジカル スタンバイ データベースの起動 リカバリおよび検証を行います Oracle Data Guard 概要および管理

271 第 II 部 参照先 この部では Oracle Data Guard のスタンバイ データベースの特長について参考となる資料を提供します 詳細は Oracle Database 10g のマニュアルを参照してください この部は 次の章で構成されています 第 13 章 初期化パラメータ 第 14 章 LOG_ARCHIVE_DEST_n パラメータの属性 第 15 章 Data Guard に関連する SQL 文 第 16 章 Oracle Data Guard に関連するビュー

272

273 13 初期化パラメータ この章では Data Guard 環境のデータベースに影響を与える初期化パラメータについて説明します 初期化パラメータ 13-1

274 表 13-1 に初期化パラメータのリストと そのパラメータがプライマリ データベース ロール スタンバイ データベース ロール あるいはその両方のいずれに適用されるかを示します また これらのパラメータを Data Guard 環境で設定する場合に固有の注意点および推奨事項も記載します 初期化パラメータに関する完全な情報は Oracle Database リファレンス に記載されています これには 更新初期化パラメータの設定方法として ALTER SYSTEM SET または ALTER SESSION 文 ( たとえば ALTER SYSTEM SET LOG_ARCHIVE_TRACE) を発行する方法および初期化パラメータ ファイルを編集する方法の説明も含まれています 初期化パラメータの設定方法の詳細は オペレーティング システム固有の Oracle マニュアルを参照してください 表 13-1 Data Guard 構成内のインスタンスの初期化パラメータ プライマリ スタンバイ パラメータ ロール ロール 注意点および推奨事項 ARCHIVE_LAG_TARGET = seconds 可 フィジカルのみ オプション 指定秒数の経過後 ログ スイッチを強制します COMPATIBLE = release_number 可 ロジカルおよび フィジカル CONTROL_FILE_RECORD_KEEP_ TIME = number_of_days CONTROL_FILES = 'control_file_ name', control_file_name', '...') DB_FILE_NAME_CONVERT = (location_of_primary_database_datafile', 'location_of_standby_database_ datafile_name', '...' 可 可 ロジカルおよびフィジカル ロジカルおよびフィジカル Data Guard では 以上の値を必要とします Oracle Database 10g の新機能を使用するには 以上に設定してください スイッチオーバーを実行すると思われる場合は 同じ値をプライマリ データベースおよびスタンバイ データベースに指定します 値が異なる場合は REDO 転送サービスが REDO データをプライマリ データベースからスタンバイ データベースに転送できない可能性があります 例については 項を参照してください SQL Apply を使用したローリング アップグレードの場合は このパラメータを 11.4 項 アップグレードの準備 で説明したガイドラインに従って設定します オプション このパラメータを使用して 指定された日数 (0 ~ 365) 内に 制御ファイル内 ( アーカイブ REDO ログ ファイルなどの必要な情報が含まれている ) の再使用可能レコードが上書きされないようにします 項を参照してください 必須 1 つ以上の制御ファイルのパス名とファイル名を指定します 制御ファイルはすでにデータベースに存在している必要があります 2 つの制御ファイルを使用することをお薦めします 現行の制御ファイルの別のコピーが存在していれば 問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後 容易にインスタンスを再開できます 項の例を参照してください 不可 フィジカルのみ スタンバイ データベースがプライマリ データベースと同じシステムにある場合 またはデータファイルが格納されているスタンバイ システムのディレクトリがプライマリ システムと異なる場合は必須 このパラメータには 文字列をペアで指定する必要があります 最初の文字列は プライマリ データベース ファイル名の中で検索される文字列です その文字列が一致すると スタンバイ データベース ファイル名を構成する 2 番目の文字列に置き換えられます 複数のペアのファイル名を指定できます 例 3-3 も参照してください 13-2 Oracle Data Guard 概要および管理

275 表 13-1 Data Guard 構成内のインスタンスの初期化パラメータ ( 続き ) パラメータ DB_UNIQUE_NAME = unique_service_ provider_name_for_this_database FAL_CLIENT = Oracle_Net_service_ name FAL_SERVER = Oracle_Net_service_ name プライマリ スタンバイ ロールロール 可 ロジカルおよびフィジカル 注意点および推奨事項 推奨 ただし LOG_ARCHIVE_CONFIG パラメータを指定している場合は必須 このデータベースの一意の名前を指定します プライマリ データベースとスタンバイ データベースのロールが交代しても この名前は変更されません DB_UNIQUE_NAME パラメータのデフォルトは DB_NAME パラメータの値です LOG_ ARCHIVE_CONFIG パラメータおよび 項も参照してください 可 フィジカルのみ FAL_SERVER パラメータが指定されている場合は必須 FAL サーバー ( 通常はプライマリ データベース ) が FAL クライアント ( スタンバイ データベース ) への接続に使用する Oracle Net サービス名を指定します 項を参照してください 不可 フィジカルのみ FAL_CLIENT パラメータが指定されている場合は必須 欠落しているアーカイブ REDO ログ ファイルをこのスタンバイ データベースがフェッチ ( 要求 ) できるフェッチ元データベースの Oracle Net サービス名を 1 つ以上指定します 項を参照してください INSTANCE_NAME 可 ロジカルおよび フィジカル LOG_ARCHIVE_CONFIG='DG_ CONFIG=(db_unique_name, db_ unique_name,...)' LOG_ARCHIVE_DEST_n = {LOCATION=path_name SERVICE=service_name, attribute, attribute,... } LOG_ARCHIVE_DEST_STATE_n = {ENABLE DISABLE ALTERNATE} 可 可 可 ロジカルおよびフィジカル ロジカルおよびフィジカル ロジカルおよびフィジカル オプション このパラメータが定義されており プライマリ データベースとスタンバイ データベースが同じホストに存在する場合は スタンバイ データベースに対してプライマリ データベースとは異なる名前を指定します 項の例を参照してください 推奨 Data Guard 構成内のプライマリ データベースおよび各スタンバイ データベースの DB_UNIQUE_NAME を識別する場合 DG_ CONFIG 属性を指定します このパラメータのデフォルト値は プライマリ データベースが REDO データをリモート宛先に送信し スタンバイ データベースが REDO データを受信することを可能にします Data Guard 構成内で Real Application Clusters プライマリ データベースが最大保護モードまたは最大可用性モードで稼働している場合 この Data Guard 構成へのスタンバイ データベースの動的追加を使用可能するには DG_CONFIG 属性を設定する必要があります 項を参照してください 必須 最大 10(n = 1, 2, 3,... 10) の宛先を定義します いずれも LOCATION または SERVICE 属性を指定する必要があります 各 LOG_ ARCHIVE_DEST_n パラメータに対し それぞれ対応する LOG_ARCHIVE_DEST_STATE_n パラメータを指定します 詳細は 項および第 14 章を参照してください 必須 LOG_ARCHIVE_DEST_STATE_n パラメータを指定して 指定された ( または代替の ) 宛先への REDO 転送サービスによる REDO データの転送を可能または不可に設定します 各 LOG_ ARCHIVE_DEST_n パラメータに対し LOG_ ARCHIVE_DEST_STATE_n パラメータを指定します 項および第 14 章も参照してください 初期化パラメータ 13-3

276 表 13-1 Data Guard 構成内のインスタンスの初期化パラメータ ( 続き ) パラメータ LOG_ARCHIVE_FORMAT=log%d_ %t_%s_%r.arc LOG_ARCHIVE_LOCAL_FIRST =[TRUE FALSE] LOG_ARCHIVE_MAX_PROCESSES =integer LOG_ARCHIVE_MIN_SUCCEED_ DEST=integer 可 ロジカルおよびフィジカル STANDBY_ARCHIVE_DEST パラメータを指定している場合は必須 これらのパラメータは連結され スタンバイ データベースに完全修飾されたアーカイブ REDO ログ ファイル名を生成します 項も参照してください 可 不可 オプション オンライン REDO ログ ファイルが 1 つ以上のローカル宛先に正常にアーカイブされた後 (TRUE) またはオンライン REDO ログ ファイルがローカル宛先にアーカイブされるのと同時 (FALSE) の いずれの時点でアーカイバ プロセス (ARCn) が転送を実行するかを制御する場合に指定します 項も参照してください 可 ロジカルおよびフィジカル LOG_ARCHIVE_TRACE=integer 可 ロジカルおよび フィジカル LOG_FILE_NAME_CONVERT ='location_of_primary_database_redo_ logs', 'location_of_standby_database_ redo_logs' プライマリ スタンバイ ロールロール オプション Oracle ソフトウェアが最初に起動するアーカイバ (ARCn) プロセスの数 (1 ~ 30) を指定します デフォルト値は 4 です ARCn プロセスの詳細は 項を参照してください 可 不可 オプション プライマリ データベースのログ ライター プロセスがオンライン REDO ログ ファイルを再利用する前に REDO データを正常に受信する必要がある 宛先の最小数 (1 ~ 10) を定義します 不可 ロジカルおよびフィジカル 注意点および推奨事項 オプション スタンバイ サイトへの REDO データの転送をトレースするには このパラメータを設定します 有効な整数値 ( または 4096) については 付録 G で説明されています スタンバイ データベースがプライマリ データベースと同じシステムにある場合 またはログ ファイルが存在するスタンバイ サイトのディレクトリ構造がプライマリ サイトと異なる場合は必須 このパラメータは プライマリ データベースのオンライン REDO ログ ファイルのパス名をスタンバイ データベースのパス名に変換します 項の例を参照してください PARALLEL_MAX_SERVERS=integer 可 ロジカルのみ 必須 ロジカル スタンバイ データベースで動作するパラレル サーバーの最大数を指定します ロジカル スタンバイ データベースでは このパラメータの値は 5 未満に設定しないでください 最高の結果を得るためには PARALLEL_MAX_SERVERS を 9 以上に設定してください REMOTE_LOGIN_PASSWORDFILE= {EXCLUSIVE SHARED} 可 ロジカルおよびフィジカル 必須 プライマリ データベースおよびすべてのスタンバイ データベースで指定します SHARED_POOL_SIZE = bytes 可 ロジカルおよび フィジカル オプション オンライン REDO ログ ファイルから読み込んだ情報を処理する System Global Area(SGA) の指定に使用します 使用可能な SGA が大きいと 処理できる情報量も大きくなります 13-4 Oracle Data Guard 概要および管理

277 表 13-1 Data Guard 構成内のインスタンスの初期化パラメータ ( 続き ) パラメータ SORT_AREA_SIZE = bytes 可 ロジカルおよび フィジカル STANDBY_ARCHIVE_DEST= filespec 不可 ロジカルおよび フィジカル STANDBY_FILE_MANAGEMENT = {AUTO MANUAL} USER_DUMP_DEST = directory_ path_name_of_trace_file プライマリ スタンバイ ロールロール オプション 大量のソートの効率を上げるには SORT_AREA_SIZE のサイズ ( デフォルト サイズは バイト ) を増加します 8.2 項も参照してください オプション プライマリ データベースから受信する スタンバイ データベース上のアーカイブ REDO ログ ファイルの位置を指定します STANDBY_ARCHIVE_DEST 初期化パラメータは LOG_ARCHIVE_DEST_n パラメータで指定されたディレクトリの場所よりも優先されます STANDBY_ARCHIVE_DEST と LOG_ARCHIVE_ FORMAT が連結して 完全修飾されたログ ファイル名が生成されます 項を参照してください 可 フィジカルのみ データファイルがプライマリ データベースに追加または削除された場合に 手動で変更しなくてもスタンバイ データベースに対応する変更が加えられるよう STANDBY_FILE_ MANAGEMENT パラメータを AUTO に設定します プライマリ データベースとスタンバイ データベースのディレクトリ構造が異なる場合は DB_FILE_NAME_CONVERT 初期化パラメータも設定して プライマリ データベースのデータファイルの 1 つ以上のセットのファイル名をスタンバイ データベースのファイル名に変換する必要があります 詳細および例は 例 3-3 を参照してください 可 ロジカルおよびフィジカル 注意点および推奨事項 LOG_ARCHIVE_TRACE パラメータを指定している場合は必須 USER_DUMP_DEST により サーバーによるデバッグ トレース ファイルの書込み先ディレクトリのパス名を指定します 付録 G を参照してください 初期化パラメータ 13-5

278 13-6 Oracle Data Guard 概要および管理

279 14 LOG_ARCHIVE_DEST_n パラメータの属性 この章では LOG_ARCHIVE_DEST_n 初期化パラメータの属性のリファレンス情報を提供します 属性には次のものがあります AFFIRM および NOAFFIRM ALTERNATE ARCH および LGWR DB_UNIQUE_NAME DELAY DEPENDENCY LOCATION および SERVICE MANDATORY および OPTIONAL MAX_CONNECTIONS MAX_FAILURE NET_TIMEOUT NOREGISTER REOPEN SYNC および ASYNC TEMPLATE VALID_FOR VERIFY 各 LOG_ARCHIVE_DEST_n 宛先には ローカル ディスクのディレクトリまたはリモートからアクセスするデータベースを指定する LOCATION または SERVICE 属性が含まれている必要があります 他の属性はすべてオプションです 注意 : LOG_ARCHIVE_DEST_n 初期化パラメータの複数の属性が廃止になりました これらの属性は下位互換性のためにのみサポートされています 詳細は Oracle Database リファレンス を参照してください 関連項目 : LOG_ARCHIVE_DEST_n 宛先を定義して REDO 転送サービスを設定する方法の詳細は 第 5 章を参照してください LOG_ARCHIVE_DEST_n パラメータの属性 14-1

280 AFFIRM および NOAFFIRM AFFIRM および NOAFFIRM REDO 転送サービスでディスクへの REDO データの書込みに同期 I/O を使用するか非同期 I/O を使用するかを制御します AFFIRM: アーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイルに対するディスク I/O をすべて同期して実行し ログ ライター プロセスの続行前に正常に完了するように指定します NOAFFIRM: アーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイルに対するディスク I/O がすべて非同期で実行され プライマリ データベースのログ ライター プロセスはディスク I/O が完了するまで待機せずに続行されるように指定します カテゴリ AFFIRM NOAFFIRM データ型キーワードキーワード 有効な値該当なし該当なし デフォルト値該当なし該当なし 必須属性 該当なし 該当なし 属性との競合 NOAFFIRM AFFIRM 対応先 V$ARCHIVE_DEST ビューの AFFIRM および ASYNC_ BLOCKS 列 V$ARCHIVE_DEST ビューの AFFIRM および ASYNC_ BLOCKS 列 使用方法 この 2 つの属性はオプションです AFFIRM 属性および NOAFFIRM 属性が指定されていない場合 デフォルトは NOAFFIRM です AFFIRM 属性は アーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイルに対するディスク I/O をすべて同期して実行し ログ ライター プロセスの続行前に完了する必要があることを指定します AFFIRM 属性の使用方法は 次のとおりです プライマリ データベースに障害が発生してもデータ消失が発生しないことを保証するための必須属性の 1 つです ローカルまたはリモートの宛先にアーカイブ操作を行う場合 LOCATION 属性または SERVICE 属性に指定できます 次のように プライマリ データベースのパフォーマンスに影響を与えることがあります * LGWR 属性と AFFIRM 属性を指定した場合 ログ ライター プロセスは REDO データを同期してディスクに書き込みます また ディスク I/O が完了するまでは 制御がユーザーに戻されないため プライマリ データベース上のオンライン REDO ログ ファイルが アーカイブが完了するまで再使用できないことがあります * ARCH 属性と AFFIRM 属性を指定した場合 ARCn プロセスは REDO データを同期してディスクに書き込みます また アーカイブ操作に時間がかかることがあるため プライマリ データベース上のオンライン REDO ログ ファイルが アーカイブが完了するまで再使用できない場合があります * ASYNC 属性と AFFIRM 属性を指定しても パフォーマンスには影響しません 注意 : プライマリ データベースが最大保護モードまたは最大可用性モードである場合 LGWR および SYNC 属性で定義された宛先は 自動的に AFFIRM モードになります 14-2 Oracle Data Guard 概要および管理

281 AFFIRM および NOAFFIRM NOAFFIRM 属性は アーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイルに対するディスク I/O がすべて非同期で実行され プライマリ データベースのログ ライター プロセスはディスク I/O が完了するまで待機せずに続行されるように指定します AFFIRM および NOAFFIRM 属性の適用先は リモート スタンバイ宛先のアーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイルのみであるため プライマリ データベースのオンライン REDO ログ ファイルに対するディスク I/O には影響を与えません これらの属性は ローカル宛先の場合は LOCATION 属性に リモート宛先の場合は SERVICE 属性に指定できます 関連項目 : ページの SYNC および ASYNC 属性 例 次の例は リモート宛先の AFFIRM 属性を示しています LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR SYNC AFFIRM' LOG_ARCHIVE_DEST_STATE_3=ENABLE LOG_ARCHIVE_DEST_n パラメータの属性 14-3

282 ALTERNATE ALTERNATE 元のアーカイブ先で障害が発生したときに使用する代替アーカイブ先を指定します カテゴリデータ型有効な値デフォルト値必須属性 ALTERNATE=LOG_ARCHIVE_DEST_n 文字列 LOG_ARCHIVE_DEST_n 宛先先 なし 代替アーカイブ先が指定されていない場合 REDO 転送サービスでは自動的に別のアーカイブ先に変更されません 該当なし 属性との競合なし 1 対応先 V$ARCHIVE_DEST ビューの ALTERNATE および STATUS 列 1 REOPEN 属性が 0( ゼロ ) ではない値で指定されている場合 ALTERNATE 属性は無視されます MAX_ FAILURE 属性に 0( ゼロ ) ではない値が指定され 障害件数が指定した障害しきい値を超過する場合は ALTERNATE 宛先が有効になります このため ALTERNATE 属性は 0( ゼロ ) ではない REOPEN 属性値と競合しません 使用方法 ALTERNATE 属性はオプションです 代替アーカイブ先が指定されていない場合 元のアーカイブ先に障害が発生しても REDO 転送サービスでは自動的に別のアーカイブ先に変更されません 指定できる代替アーカイブ先は LOG_ARCHIVE_DEST_n パラメータごとに 1 つのみですが 複数の有効なアーカイブ先で同じ代替アーカイブ先を共有できます 代替アーカイブ先に次のいずれかを指定することが理想的です 同じローカル スタンバイ データベース システム上の異なるディスクの場所 (14-5 ページの例 14-1 を参照 ) 同じスタンバイ データベース システムへの異なるネットワーク ルート (14-5 ページの例 14-2 を参照 ) 有効なアーカイブ先を厳密に反映するリモート スタンバイ データベース システム 代替アーカイブ先を参照する有効な宛先がない場合は 代替アーカイブ先が保留されていることを意味します これは 代替アーカイブ先を有効にする自動手段がないためです ただし ALTER SYSTEM を使用すると 代替アーカイブ先を実行時に有効にする ( または遅延させる ) ことができます 代替アーカイブ先に指定できる宛先には 次の制限事項があります ローカルの必須の宛先を少なくとも 1 つは有効にする 有効な宛先数は LOG_ARCHIVE_MIN_SUCCEED_DEST パラメータでの定義と一致させる必要がある 宛先をそれ自身の代替先にすることはできない 有効な宛先数を増加させると 利用可能な代替アーカイブ先の数が減少します 宛先に障害が発生すると 次のアーカイブ操作時に代替アーカイブ先が有効になります アーカイブ操作の途中で 代替アーカイブ先を有効にすることはできません これは すでに処理済のブロックなどを 再度読み込む必要が生じるためです これは REOPEN 属性の機能と同じです 14-4 Oracle Data Guard 概要および管理

283 ALTERNATE REOPEN 属性が 0( ゼロ ) ではない値で指定されている場合 MAX_FAILURE 属性が 0( ゼロ ) ではない値で指定されていなければ ALTERNATE 属性は無視されます MAX_FAILURE 属性と REOPEN 属性の値が 0( ゼロ ) ではない場合は 障害件数が指定の障害しきい値を超過すると ALTERNATE 宛先が有効になります このため ALTERNATE 属性は 0( ゼロ ) ではない REOPEN 属性値と競合しません 例 例 14-1 のサンプル初期化パラメータ ファイルでは エラーが発生したり デバイスがいっぱいになった場合 LOG_ARCHIVE_DEST_1 が LOG_ARCHIVE_DEST_2 へのフェイルオーバーを次回のアーカイブ操作で自動的に実行します 例 14-1 代替アーカイブ先への自動フェイルオーバー LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY' LOG_ARCHIVE_DEST_STATE_2=ALTERNATE こがローカル宛先の例では LOG_ARCHIVE_DEST_STATE_n 初期化パラメータの指定に従って 宛先を ALTERNATE 状態にすることができることもわかります ALTERNATE 状態では この宛先への REDO 転送サービスによる REDO データの転送は 別の宛先の失敗によって自動的にこの宛先が有効になるまで遅延します LOG_ARCHIVE_DEST_STATE_n パラメータの詳細は 項を参照してください 例 14-2 スタンバイ データベースに対する代替の Oracle Net サービス名の定義 この例は 同じスタンバイ データベースに代替 Oracle Net サービス名を定義する方法を示しています LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='SERVICE=stby1_path1 OPTIONAL ALTERNATE=LOG_ARCHIVE_DEST_3' LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_3='SERVICE=stby1_path2 OPTIONAL' LOG_ARCHIVE_DEST_STATE_3=ALTERNATE LOG_ARCHIVE_DEST_n パラメータの属性 14-5

284 ARCH および LGWR ARCH および LGWR REDO 転送サービスによるトランザクション REDO データの収集とスタンバイ宛先への転送に アーカイバ プロセス (ARCn) を使用するか ログ ライター プロセス (LGWR) を使用するかを指定します ARCH 属性および LGWR 属性が指定されていない場合 デフォルトは ARCH です カテゴリ ARCH LGWR データ型 キーワード キーワード 有効な値 該当なし 該当なし デフォルト値 該当なし 該当なし 必須属性 なし なし 属性との競合 LGWR ASYNC NET_TIMEOUT ARCH 対応先 V$ARCHIVE_DEST ビューの ARCHIVER PROCESS および SCHEDULE 列 V$ARCHIVE_DEST ビューの ARCHIVER PROCESS および SCHEDULE 列 使用方法例 この 2 つの属性はオプションです ARCH 属性および LGWR 属性が指定されていない場合 デフォルトは ARCH です REDO 転送サービスでは ARCH 属性を指定すると ARCn プロセス LGWR 属性を指定するとログ ライター プロセスが使用されます デフォルトで アーカイブは ARCn プロセスによって実行されるようになっているため REDO 転送サービスで LGWR プロセスを使用するには LGWR 属性を明示的に指定する必要があります 同じ宛先に LGWR プロセスと ARCn プロセスの両方を指定することはできませんが ある宛先にはログ ライター プロセスを使用するよう指定し 別の宛先にはアーカイバ プロセスを使用して REDO データを転送するよう指定することは可能です 宛先の現行のアーカイブ プロセスを変更した場合 (ARCn プロセスから LGWR プロセスへの変更など ) アーカイブ プロセスは次にログ スイッチが行われるまで変更されません 次の例は LGWR 属性が指定されている LOG_ARCHIVE_DEST_n パラメータを示しています その他の例は 5.3 項を参照してください LOG_ARCHIVE_DEST_3='SERVICE=denver LGWR' LOG_ARCHIVE_DEST_STATE_3=ENABLE 14-6 Oracle Data Guard 概要および管理

285 DB_UNIQUE_NAME DB_UNIQUE_NAME この宛先にあるデータベースの一意の名前を指定します カテゴリデータ型有効な値デフォルト値必須属性属性との競合対応先 DB_UNIQUE_NAME=name 文字列 name は DB_UNIQUE_NAME パラメータを使用してこのデータベースに定義された値と一致している必要があります なし なし なし V$ARCHIVE_DEST ビューの DB_UNIQUE_NAME 列 使用方法 この属性は 次の場合にはオプションです LOG_ARCHIVE_CONFIG=DG_CONFIG 初期化パラメータが指定されていない場合 これがローカル宛先 (LOCATION 属性で指定 ) の場合 この属性が必須となるのは LOG_ARCHIVE_CONFIG=DG_CONFIG 初期化パラメータが指定されており かつ これがリモート宛先 (SERVICE 属性で指定 ) の場合です プライマリ データベースとスタンバイ データベースの関係を明確に識別するには DB_UNIQUE_NAME 属性を使用します この属性は Data Guard 構成に複数のスタンバイ データベースが存在する場合に特に有用です DB_UNIQUE_NAME で指定する名前は DG_CONFIG リストの DB_UNIQUE_NAME 値の 1 つと一致している必要があります REDO 転送サービスにより 指定された宛先のデータベースの DB_UNIQUE_NAME 属性が DB_UNIQUE_NAME 属性と一致していること またはその宛先への接続が拒否されていることが検証されます DB_UNIQUE_NAME 属性で指定する名前は 宛先で識別されるデータベースの DB_UNIQUE_ NAME 初期化パラメータで指定されている名前と一致している必要があります 例 次の例では DB_UNIQUE_NAME パラメータでは boston(db_unique_name=boston) が指定されており これは LOG_ARCHIVE_DEST_1 パラメータの DB_UNIQUE_NAME 属性にも指定されています LOG_ARCHIVE_DEST_2 パラメータの DB_UNIQUE_NAME 属性は 宛先として chicago を指定しています boston と chicago は どちらも LOG_ARCHIVE_CONFIG=DG_ CONFIG パラメータにリストされています DB_UNIQUE_NAME=boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)' LOG_ARCHIVE_DEST_1='LOCATION=/arch1/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2='SERVICE=Sales_DR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_n パラメータの属性 14-7

286 DELAY DELAY フィジカル スタンバイ サイトで REDO データがアーカイブされてから フィジカル スタンバイ データベースにアーカイブ REDO ログ ファイルが適用されるまでのタイム ラグを指定します 注意 : この属性は フィジカル スタンバイ データベースにのみ設定できます ロジカル スタンバイ データベースでアーカイブ REDO ログ ファイルの適用を遅延するには Oracle Database PL/SQL パッケージ プロシージャおよびタイプ リファレンス で説明されているように DBMS_LOGSTDBY.APPLY_SET プロシージャを使用します カテゴリデータ型有効な値デフォルト値必須属性属性との競合対応先 DELAY[=minutes] 数値 0 分以上 30 分 SERVICE LOCATION NODELAY V$ARCHIVE_DEST ビューの DELAY_MINS および DESTINATION 列 使用方法 DELAY 属性はオプションです デフォルトでは 遅延は発生しません DELAY 属性は スタンバイ宛先のアーカイブ REDO ログ ファイルが 指定した時間が経過するまでリカバリに利用されないことを示します 時間間隔は分で表され 転送された REDO データがスタンバイ サイトに正常に到達した時点から計測されます DELAY 属性を使用すると 破損したプライマリ データまたは誤ったプライマリ データからフィジカル スタンバイ データベースを保護できます ただし フェイルオーバー中は 破損が発生した時点までのすべての REDO を適用するための所要時間が長くなるため トレードオフを伴います DELAY 属性は REDO データのフィジカル スタンバイ宛先への転送に影響しません リアルタイム適用が使用可能になっている場合 設定した遅延は無視されます DELAY 属性の変更は 次に REDO データをアーカイブすると ( ログ スイッチ後に ) 有効になります 進行中のアーカイブ操作には 影響しません スタンバイ サイトでの指定した遅延間隔は上書きできます 時間間隔が経過する前に アーカイブ REDO ログ ファイルをフィジカル スタンバイ データベースに即時に適用するには RECOVER MANAGED STANDBY DATABASE 句の NODELAY キーワードを使用します 次に例を示します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY; 関連項目 : ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 文の NODELAY キーワードの詳細は Oracle Database SQL リファレンス を参照してください 14-8 Oracle Data Guard 概要および管理

287 DELAY 例 DELAY 属性を使用すれば プライマリ データベースと様々なレベルで同期させる複数のスタンバイ データベースを維持する構成を設定できます ただし REDO Apply で破損時点までのすべての REDO を適用するまでにかかる時間が長くなるため フェイルオーバー中は この保護はなんらかのオーバーヘッドを伴います たとえば プライマリ データベース A にはスタンバイ データベース B および C がある場合を考えます スタンバイ データベース B は 障害時リカバリ データベースとして設定するため タイム ラグは設定しません スタンバイ データベース C は 2 時間の遅延に設定されています これは スタンバイ データベースに伝播する前にユーザー エラーを検出するには十分な時間です 次の例は この構成用に DELAY 属性を指定する方法を示しています LOG_ARCHIVE_DEST_1='LOCATION=/oracle/dbs/' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='SERVICE=stbyB LGWR SYNC AFFIRM' LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_3='SERVICE=stbyC DELAY=120' LOG_ARCHIVE_DEST_STATE_3=ENABLE 注意 : または 十分なフラッシュバック ログ データがあれば フラッシュバック データベースを使用して データベースを障害発生時点または他のデータベース インカネーションの SCN まで戻すこともできます フラッシュバック データベースの使用方法は Oracle Database バックアップおよびリカバリ基礎 を参照してください LOG_ARCHIVE_DEST_n パラメータの属性 14-9

288 DEPENDENCY DEPENDENCY この属性は 他の宛先にあるアーカイブ場所への共有アクセスを介して REDO データを受信するスタンバイ宛先について指定します この属性を使用して定義された宛先には DEPENDENCY 属性で指定した他の宛先への依存性があります カテゴリデータ型有効な値デフォルト値必須属性属性との競合対応先 DEPENDENCY=LOG_ARCHIVE_DEST_n 文字列値該当なしなし SERVICE LOCATION NOREGISTER V$ARCHIVE_DEST ビューの DEPENDENCY 列 使用方法 DEPENDENCY 属性はオプションです DEPENDENCY 属性を指定しない場合 REDO 転送サービスでは REDO データは宛先に直接転送されます DEPENDENCY 属性は フィジカル スタンバイ データベースまたはロジカル スタンバイ データベースで指定できます 関連項目 : 項 複数のスタンバイ データベース間でのログ ファイル宛先の共有 依存する宛先で REDO データを使用できるかどうかは DEPENDENCY 属性で指定された宛先への REDO 転送が成功するか失敗するかによって決定します DEPENDENCY 属性には 次の制限事項があります 依存性を持つことができるのはスタンバイ宛先のみである DEPENDENCY 属性で指定する宛先には LOCATION または SERVICE 属性を使用できる DEPENDENCY 属性は セッション レベルでは変更できない 1 つ以上の宛先が同じ宛先に依存する場合 依存する宛先のすべての属性も適用されます 実際にはアーカイブ操作が 1 回のみ発生した場合でも アーカイブ操作が各宛先に対して実行されたように見えます たとえば 2 つのスタンバイ データベースが同じ宛先に依存する場合を考えます 各宛先には異なる DELAY 属性を指定できるため プライマリ データベースと各スタンバイ データベース間で タイム ラグをずらして維持できます 同じように 依存する宛先には ALTERNATE アーカイブ先を指定できますが 同じ親宛先に依存するようにもしないようにも指定できます 依存する宛先には データ消失なしのフェイルオーバーは実行できません Oracle Data Guard 概要および管理

289 DEPENDENCY 例 DEPENDENCY 属性を使用する理由の 1 つは 同一システム上に 2 つのスタンバイ データベースがある場合です 親および子のスタンバイ データベースには フィジカル スタンバイ データベースとロジカル スタンバイ データベースを混在させることができます 次に例を示します # Set up the mandatory local destination: # LOG_ARCHIVE_DEST_1='LOCATION=/oracle/dbs/ MANDATORY' LOG_ARCHIVE_DEST_STATE_1=ENABLE # # Set up the remote standby database that will receive the redo data: # LOG_ARCHIVE_DEST_2='SERVICE=dest2 OPTIONAL' LOG_ARCHIVE_DEST_STATE_2=ENABLE # # Set up the remote standby database that resides on the same system as, and is # dependent on, the first standby database: # LOG_ARCHIVE_DEST_3='SERVICE=dest3 DEPENDENCY=LOG_ARCHIVE_DEST_2 OPTIONAL' LOG_ARCHIVE_DEST_STATE_3=ENABLE LOG_ARCHIVE_DEST_n パラメータの属性 14-11

290 LOCATION および SERVICE LOCATION および SERVICE 各宛先には LOCATION 属性または SERVICE 属性を指定して REDO 転送サービスがローカル ディスクのディレクトリまたはリモート データベースのどちらに REDO データを転送できるかを明示する必要があります カテゴリ LOCATION=local_disk_directory または USE_DB_RECOVERY_FILE_DEST データ型文字列値文字列値 有効な値該当なし該当なし デフォルト値なしなし 必須属性該当なし該当なし 属性との競合 SERVICE DELAY DEPENDENCY NOREGISTER ASYNC TEMPLATE NET_TIMEOUT SERVICE=net_service_name LOCATION 対応先 V$ARCHIVE_DEST ビューの DESTINATION および TARGET 列 V$ARCHIVE_DEST ビューの DESTINATION および TARGET 列 使用方法 LOCATION または SERVICE 属性を指定する必要があります デフォルトはありません 複数の属性を指定している場合は 属性のリストの最初に LOCATION 属性または SERVICE 属性を指定します LOCATION で属性で少なくとも 1 つのローカル ディスクのディレクトリを指定する必要があります これにより プライマリ データベースのメディア リカバリが必要な場合は ローカルのアーカイブ REDO ログ ファイルに確実にアクセスできるようになります ローカルまたはリモートの追加宛先は最大 9 個まで指定できます SERVICE 属性を使用してリモート宛先を指定すると Data Guard では 障害時リカバリに備えて トランザクション一貫性のあるプライマリ データベースのリモート コピーを確実に維持できます LOCATION 属性には 次のいずれかを指定できます LOCATION=local_disk_directory これは データベースを置くシステム上のディスク ディレクトリの一意のディレクトリ パス名を指定します これは アーカイブ REDO ログ ファイルのローカル宛先です LOCATION=USE_DB_RECOVERY_FILE_DEST フラッシュ リカバリ領域を構成するには DB_RECOVERY_FILE_DEST 初期化パラメータを使用して フラッシュ リカバリ領域として機能するディレクトリまたは Oracle Storage Manager のディスク グループを指定します フラッシュ リカバリ領域が構成されていて ローカルの宛先が定義されていない場合 Data Guard により暗黙的に LOG_ARCHIVE_DEST_10 の宛先がフラッシュ リカバリ領域に使用されます フラッシュ リカバリ領域の詳細は 項を参照してください Oracle Data Guard 概要および管理

291 LOCATION および SERVICE SERVICE 属性を指定する場合は 次のようにします SERVICE 属性と REDO データの送信先となるリモート Oracle データベース インスタンスを識別する有効な Oracle Net サービス名 (SERVICE=net_service_name) を指定して リモート宛先を識別します SERVICE 属性で指定する Oracle Net サービス名は リモート データベースへの接続に必要な情報を含む接続記述子に変換されます 関連項目 : Oracle Net サービス名の設定方法は Oracle Database Net Services 管理者ガイド を参照してください リモート宛先に REDO データを転送するには 着信するアーカイブ REDO データを受け取るために ネットワーク接続と リモート宛先に対応付けられた Oracle データベース インスタンスが必要です LOCATION および SERVICE 属性の現行の設定を確認するには V$ARCHIVE_DEST 固定ビューを問い合せます TARGET 列は 宛先がプライマリ データベースにとってローカルかリモートかを示します DESTINATION 列は 宛先に指定されている値を示します たとえば 宛先パラメータ値は アーカイブ REDO ログ ファイルが配置されているリモートの Oracle インスタンスを示す Oracle Net サービス名を指定します 例 例 1 LOCATION 属性の指定 LOG_ARCHIVE_DEST_2='LOCATION=/disk1/oracle/oradata/payroll/arch/' LOG_ARCHIVE_DEST_STATE_2=ENABLE 例 2 SERVICE 属性の指定 LOG_ARCHIVE_DEST_3='SERVICE=stby1' LOG_ARCHIVE_DEST_STATE_3=ENABLE LOG_ARCHIVE_DEST_n パラメータの属性 14-13

292 MANDATORY および OPTIONAL MANDATORY および OPTIONAL オンライン REDO ログ ファイルを再利用するためのポリシーを指定します MANDATORY: いっぱいになったオンライン ログ ファイルが再利用可能になる前に 宛先へのアーカイブの成功が必要になるように指定します OPTIONAL: 宛先へのアーカイブに成功していなくても オンライン REDO ログ ファイルが再利用可能になるように指定します カテゴリ MANDATORY OPTIONAL データ型キーワードキーワード 有効な値該当なし該当なし デフォルト値該当なし該当なし 必須属性 該当なし 該当なし 属性との競合 OPTIONAL MANDATORY 対応先 V$ARCHIVE_DEST ビューの BINDING 列 V$ARCHIVE_DEST ビューの BINDING 列 使用方法 MANDATORY 属性および OPTIONAL 属性が指定されていない場合 デフォルトは OPTIONAL です すべての宛先がオプションとして指定されている場合にも 最低 1 つの宛先は成功する必要があります 宛先に OPTIONAL を指定すると その宛先へのアーカイブが失敗する場合があります さらに オンライン REDO ログ ファイルが再利用され 最終的に上書きされる場合があります 必須の宛先へのアーカイブ操作が失敗した場合 オンライン REDO ログ ファイルは上書きされません LOG_ARCHIVE_MIN_SUCCEED_DEST=n パラメータ (n は 1 から 10 の整数 ) は ログ ライター プロセスがオンライン REDO ログ ファイルを上書きできるようになる前に 正常にアーカイブしておく必要がある宛先の数を指定します LOG_ARCHIVE_MIN_SUCCEED_DEST=n の件数は すべての MANDATORY の宛先とスタンバイ以外の OPTIONAL の宛先によって満たされます LOG_ARCHIVE_MIN_SUCCEED_ DEST パラメータに設定した値 ( プライマリ データベースのログ ライター プロセスがオンライン REDO ログ ファイルを再利用する前に REDO データを正常に受信する必要がある宛先の最小数を定義します ) が一致すると オンライン REDO ログ ファイルは再利用可能になります たとえば 次のようにパラメータを設定できます # Database must archive to at least two locations before # overwriting the online redo log files. LOG_ARCHIVE_MIN_SUCCEED_DEST = 2 1 つ以上のローカル宛先が必要であり それらに OPTIONAL または MANDATORY を宣言できます LOG_ARCHIVE_MIN_SUCCEED_DEST パラメータの最小値は 1 のため 最低 1 つのローカル宛先が操作上必須です 必須の宛先のいずれかに ( 必須のスタンバイ宛先を含む ) 障害が発生すると LOG_ARCHIVE_MIN_SUCCEED_DEST パラメータは不適切になります LOG_ARCHIVE_MIN_SUCCEED_DEST パラメータ値を 必須の宛先数にオプションのローカル宛先数を加えた数よりも大きく設定することはできません この 2 つの属性は 宛先のデータ保護モードに影響を与えません V$ARCHIVE_DEST 固定ビューの BINDING 列は アーカイブ操作に障害がどのように影響するのかを指定します Oracle Data Guard 概要および管理

293 MANDATORY および OPTIONAL 例 次の例は MANDATORY 属性を示しています LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest MANDATORY' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_3='SERVICE=denver MANDATORY' LOG_ARCHIVE_DEST_STATE_3=ENABLE LOG_ARCHIVE_DEST_n パラメータの属性 14-15

294 MAX_CONNECTIONS MAX_CONNECTIONS 宛先に対するリモート アーカイブの実行に使用されるネットワーク接続の最大数を指定します MAX_CONNECTIONS 属性を 2 以上の値に設定すると REDO 転送サービスでは複数のネットワーク接続を使用してリモート アーカイブが実行されます これらの各接続には個別のアーカイバ (ARCn) プロセスが使用されます カテゴリ データ型 説明 整数 有効な値 1 ~ 5 デフォルト値 1 必須属性 属性との競合 なし なし 対応先 プライマリ データベースの V$ARCHIVE_DEST ビューの MAX_CONNECTIONS 列 LOG_ARCHIVE_MAX_PROCESSES および PARALLEL_ MAX_SERVERS 初期化パラメータ 使用方法例 MAX_CONNECTIONS 属性はオプションです REDO 転送サービスでは デフォルトで 1 つのネットワーク接続を使用してリモート アーカイブが実行されます MAX_CONNECTIONS 属性を 2 以上の値に設定すると REDO 転送サービスでは複数のネットワーク接続を使用して宛先へのリモート アーカイブが実行されます LOG_ARCHIVE_MAX_PROCESSES および PARALLEL_MAX_SERVERS 初期化パラメータは MAX_CONNECTIONS 属性に関連付けられており インスタンスで実際に使用される ARCn プロセスの数に影響します たとえば すべての宛先の MAX_CONNECTIONS 属性の合計が LOG_ARCHIVE_MAX_ PROCESSES の値を超えている場合 Data Guard ではできるだけ多数の ARCn プロセスが使用されますが 接続数は MAX_CONNECTIONS に指定されている値より少ない場合があります 次の例は MAX_CONNECTIONS 属性を示しています LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_3='SERVICE=denver MAX_CONNECTIONS=3' LOG_ARCHIVE_DEST_STATE_3=ENABLE Oracle Data Guard 概要および管理

295 MAX_FAILURE MAX_FAILURE プライマリ データベースが失敗した宛先を放棄する前に REDO 転送サービスが通信を再確立してその宛先への REDO データを転送する連続試行回数を制御します カテゴリ データ型 数値 有効な値 >=0 デフォルト値 なし 必須属性属性との競合 MAX_FAILURE=count REOPEN 対応先 V$ARCHIVE_DEST ビューの MAX_FAILURE FAILURE_COUNT および REOPEN_SECS 列 なし 使用方法 MAX_FAILURE 属性はオプションです デフォルトでは 失敗した宛先に対するアーカイブの試行回数に制限はありません この属性は 失敗後に回数制限付きで REDO データの転送を再試行するように 宛先に対する障害の解決方法を指定するときに役立ちます MAX_FAILURE 属性を指定した場合は REOPEN 属性も設定する必要があります 指定した連続試行回数を超過すると その宛先は REOPEN 属性が指定されていないものとして処理されます V$ARCHIVE_DEST 固定ビューの FAILURE_COUNT 列で障害件数を確認できます 関連する REOPEN_SECS 列は REOPEN 属性値を示します 注意 : 宛先の障害件数が 指定した MAX_FAILURE 属性の値に達した場合 その宛先を再利用するには MAX_FAILURE 属性値または他の属性を修正する必要があります この結果 障害件数がゼロ (0) にリセットされます ALTER SYSTEM SET 文によって宛先が変更されると 障害件数は 0( ゼロ ) にリセットされます このため 現在の障害件数の値よりも小さな値に MAX_FAILURE 属性を設定する問題が回避されます 障害件数が MAX_FAILURE 属性に設定された値以上になると REOPEN 属性値は暗黙的に 0 ( ゼロ ) に設定されます これによって REDO 転送サービスは 次のアーカイブ操作では REDO データを代替アーカイブ先 (ALTERNATE 属性で指定 ) に転送するようになります MAX_FAILURE 属性を指定せずに ( または MAX_FAILURE=0 を指定し ) REOPEN 属性に 0 ( ゼロ ) ではない値を指定すると REDO 転送サービスは 失敗した宛先に対して無制限にアーカイブを試行します 宛先が MANDATORY 属性を持つ場合 オンライン REDO ログ ファイルはこの宛先にアーカイブされるまで再利用できません LOG_ARCHIVE_DEST_n パラメータの属性 14-17

296 MAX_FAILURE 例 次の例は REDO 転送サービスが 宛先 arc_dest に対して アーカイブ操作を最高 3 回 5 秒ごとに試行できる指定を示しています 3 回目の試行後 アーカイブ操作に失敗すると その宛先は REOPEN 属性が指定されていないものとして扱われます LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3' LOG_ARCHIVE_DEST_STATE_1=ENABLE Oracle Data Guard 概要および管理

297 NET_TIMEOUT NET_TIMEOUT ネットワーク接続を終了する前に プライマリ システム上のログ ライター プロセスがネットワーク サーバー (LNSn) プロセスからのステータスを待機する時間を秒単位で指定します カテゴリデータ型 NET_TIMEOUT=seconds 数値 有効な値 1 1 ~ 1200 デフォルト値 必須属性 180 秒 LGWR と SYNC 属性との競合 ARCH LOCATION LGWR と ASYNC 2 対応先 プライマリ データベースの V$ARCHIVE_DEST ビューの NET_TIMEOUT 列 1 2 最小値は 1 秒に設定できますが 不適切なエラーやスタンバイ データベースからの切断を回避するために 最小値は 8 ~ 10 秒に設定することをお薦めします LGWR および ASYNC 属性を指定すると REDO 転送デバイスでは無視され エラーは戻されません 使用方法 NET_TIMEOUT 属性はオプションです ただし NET_TIMEOUT 属性を指定しないと 180 秒に設定されますが プライマリ データベースが停止する可能性があります この状況を回避するには NET_TIMEOUT に 0( ゼロ ) 以外の小さい値を指定することによって ネットワーク サーバーからステータスを待機する際 ユーザーが指定したタイムアウト時間の期限が切れた後に プライマリ データベースが操作を続行できます NET_TIMEOUT 属性が使用されるのは ログ ライター プロセスがネットワーク サーバー (LNSn) プロセスを使用して REDO データを転送する場合のみです ログ ライター プロセスは 指定時間が経過するまで ネットワーク I/O に関するステータスの受信を待機します ネットワーク切断の可能性がある場合 ネットワーク タイムアウトによって終了した切断であっても ログ ライター プロセスはスタンバイ データベースへの再接続を自動的に試行して ネットワークの停止およびネットワーク終了エラーを解決します 通常は ネットワークが物理的に破損している場合を除いて ログ ライター プロセスはネットワークに正常に再接続できます 再接続の試行が継続される時間は 次の要因によって決まります プライマリ データベースの NET_TIMEOUT 属性の値 プライマリ データベースの保護モード これによって 再接続が行われる最大時間が判断されます ログ ライター プロセスがスタンバイ データベースへの再接続を試行する期間のガイドラインとして 次の見積りを使用してください 最大保護モードでは ログ ライター プロセスはおよそ 5 分間再接続を試行します 最大可用性モードでは ログ ライター プロセスは NET_TIMEOUT 値の範囲内で再接続を試行します たとえば NET_TIMEOUT 属性値が 60 秒に設定されているプライマリ データベースが最大可用性保護モードで動作している場合 接続には少なくとも 1 分 スタンバイ データベースへの接続を終了するには最大 3 分の時間が実際には必要と考えられます 注意 : 最大保護モードで実行している場合は NET_TIMEOUT に適切な値を指定するよう注意してください 不適切なネットワークの障害を検出すると プライマリ インスタンスが停止する可能性があります LOG_ARCHIVE_DEST_n パラメータの属性 14-19

298 NET_TIMEOUT プライマリ システムとスタンバイ システムのタイムアウト パラメータ値は慎重に調整してください 不適切な場合 プライマリ システムでネットワーク上の問題が発生してネットワークが切断されたときに スタンバイ データベースでデフォルトのネットワーク タイムアウト値が過度に高く設定されていると スタンバイ データベースがネットワークの切断を認識しない可能性があります ネットワーク タイマーが適切に設定されていない場合 スタンバイ データベースはタイムアウトしておらず 中断したネットワーク接続は依然として有効に見えるため スタンバイ データベースと連結しているプライマリ データベースでのログ ライター プロセスによって行われる その後の試行はエラーとなります Oracle Database Net Services 管理者ガイド を参照してください 例 次の例は NET_TIMEOUT 属性を使用して プライマリ データベースのネットワーク タイムアウト値を 40 秒に指定する方法を示しています LOG_ARCHIVE_DEST_2='SERVICE=stby1 LGWR NET_TIMEOUT=40 SYNC' LOG_ARCHIVE_DEST_STATE_2=ENABLE Oracle Data Guard 概要および管理

299 NOREGISTER NOREGISTER アーカイブ REDO ログ ファイルの位置が 対応する宛先に記録されることを示します カテゴリデータ型有効な値デフォルト値必須属性属性との競合対応先 NOREGISTER キーワード 該当なし 該当なし SERVICE LOCATION V$ARCHIVE_DEST ビューの DESTINATION および TARGET 列 使用方法 NOREGISTER 属性は スタンバイ データベースの宛先が Data Guard 構成の一部である場合はオプションです NOREGISTER 属性は 宛先が Data Guard 構成の一部でない場合は必須です これは リモートの宛先のみの属性です 各アーカイブ REDO ログ ファイルの位置は 常にプライマリ データベースの制御ファイルに記録されます 例 次の例は NOREGISTER 属性を示しています LOG_ARCHIVE_DEST_5='NOREGISTER' LOG_ARCHIVE_DEST_n パラメータの属性 14-21

300 REOPEN REOPEN REDO 転送サービスが失敗した宛先の再オープンを試行するまでの最小秒数を指定します カテゴリデータ型有効な値デフォルト値必須属性属性との競合対応先 REOPEN [=seconds] 数値 0 秒以上 300 秒 なし 該当なし V$ARCHIVE_DEST ビューの REOPEN_SECS および MAX_FAILURE 列 使用方法 REOPEN 属性はオプションです REDO 転送サービスは 失敗した宛先の再オープンをログ スイッチ時に試行します REDO 転送サービスは 最後のエラーの時刻に REOPEN 間隔を加算した時刻が現在の時刻に達していないかどうかをチェックします 達していない場合 REDO 転送サービスは宛先の再オープンを試行します REOPEN は 接続障害のみでなく すべてのエラーに適用されます エラーには ネットワーク障害 ディスク エラー クオータ例外などがありますが これらに制限されません OPTIONAL 宛先に REOPEN を指定すると エラーが発生した場合に Oracle データベースでオンライン REDO ログ ファイルを上書きできます MANDATORY 宛先に REOPEN を指定すると REDO 転送サービスは REDO データを正常に転送できない場合にプライマリ データベースを停止します この場合には 次のオプションを考慮します 宛先を遅延させる 宛先を OPTIONAL として指定する または SERVICE 属性値を変更することで宛先を変更 代替宛先の指定 宛先の無効化 関連項目 : REOPEN MAX_FAILURES および ALTERNATE 属性を使用して 宛先へのアーカイブ プロセスに失敗した場合に実行する処置を指定する方法の詳細は 5.5 項 エラーが発生した場合の対処方法 を参照してください 例 次の例は REOPEN 属性を示しています LOG_ARCHIVE_DEST_3='SERVICE=stby1 MANDATORY REOPEN=60' LOG_ARCHIVE_DEST_STATE_3=ENABLE Oracle Data Guard 概要および管理

301 SYNC および ASYNC SYNC および ASYNC ログ ライター プロセス (LGWR) を使用したアーカイブの実行時に ネットワーク I/O が同期で実行されるか (SYNC) 非同期で実行されるか (ASYNC) を指定します 注意 : プライマリ データベースが最大保護モードまたは最大可用性モードの場合 スタンバイ REDO ログ ファイルのアーカイブ先とログ ライター プロセスによる宛先は 自動的に SYNC モードになります カテゴリ SYNC ASYNC データ型 キーワード 数値 有効な値 該当なし 該当なし デフォルト値 該当なし なし 必須属性 なし LGWR 属性との競合 ASYNC SYNC LOCATION ARCH 対応先 V$ARCHIVE_DEST ビューの TRANSMIT_MODE 列 V$ARCHIVE_DEST ビューの TRANSMIT_MODE および ASYNC_ BLOCKS 列 使用方法 SYNC および ASYNC 属性はオプションです LGWR 属性を指定して SYNC 属性または ASYNC 属性のいずれも指定しない場合 デフォルトは SYNC です ARCH 属性を指定する場合は SYNC 属性のみが有効です ARCH 属性と ASYNC 属性を一緒に指定すると エラー メッセージが戻されます SYNC 属性は 宛先に対するネットワーク I/O が同期して実行されることを指定します これは I/O が開始されると ログ ライター プロセスが I/O の完了を待ってから処理を続行することを意味します SYNC 属性は非データ消失環境の設定に必要です つまり この属性によって REDO レコードは 処理を継続する前にスタンバイ宛先に正常に転送されるようになります ASYNC 属性は 宛先に対するネットワーク I/O が非同期で実行されることを指定します 例 次の例は SYNC 属性が指定されている LOG_ARCHIVE_DEST_n パラメータを示しています LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR SYNC' LOG_ARCHIVE_DEST_STATE_3=ENABLE LOG_ARCHIVE_DEST_n パラメータの属性 14-23

302 TEMPLATE TEMPLATE 宛先のディレクトリ仕様およびアーカイブ REDO ログ ファイル名の形式テンプレートを定義します このテンプレートは スタンバイ宛先の STANDBY_ARCHIVE_DEST および LOG_ ARCHIVE_FORMAT 初期化パラメータで定義されたデフォルトのファイル名形式とは異なるファイル名を生成する場合に使用されます カテゴリデータ型有効な値デフォルト値必須属性属性との競合対応先 TEMPLATE=filename_template_%t_%s_%r 文字列値 該当なし なし SERVICE LOCATION V$ARCHIVE_DEST ビューの REMOTE_TEMPLATE および REGISTER 列 使用方法 TEMPLATE 属性はオプションです TEMPLATE が指定されていない場合 アーカイブ REDO ログ名には STANDBY_ARCHIVE_DEST および LOG_ARCHIVE_FORMAT 初期化パラメータの値が使用されます TEMPLATE 属性は リモート アーカイブ先の初期化パラメータ STANDBY_ARCHIVE_ DEST および LOG_ARCHIVE_FORMAT の設定を上書きします TEMPLATE 属性は リモート アーカイブ先 ( つまり SERVICE 属性で指定されている宛先 ) でのみ有効です LGWR 属性も指定されている宛先で指定した場合 ARCn プロセスによる再アーカイブでは TEMPLATE ファイル名指定は使用されません filename_template 値には 表 14-1 に示す %s %t および %r ディレクティブを指定する必要があります 表 14-1 TEMPLATE 属性のディレクティブ ディレクティブ 説明 %t インスタンス スレッド番号を代入します %T 0( ゼロ ) を埋め込んだインスタンス スレッド番号を代入します %s ログ ファイル順序番号を代入します %S 0( ゼロ ) を埋め込んだログ ファイル順序番号を代入します %r リセットログ ID を代入します %R 0( ゼロ ) を埋め込んだリセットログ ID を代入します filename_template 値は スタンバイ宛先に転送され そこで変換および検証された後 ファイル名が作成されます Oracle Data Guard 概要および管理

303 TEMPLATE 例 次の例では prmy1 は リモート宛先 stby1 に REDO データを転送します TEMPLATE 属性は stby1 が p1_thread#_sequence#_resetlogs.dbf のファイル名形式で ディレクトリ /usr/oracle/prmy1 に配置されることを示します LOG_ARCHIVE_DEST_1='SERVICE=boston MANDATORY REOPEN=5 TEMPLATE=/usr/oracle/prmy1/p1_%t_%s_%r.dbf' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_n パラメータの属性 14-25

304 VALID_FOR VALID_FOR 次の要因に基づき REDO 転送サービスが REDO データを宛先にいつ転送できるかを識別します データベースがプライマリ ロールとスタンバイ ロールのどちらで現在実行されているか オンライン REDO ログ ファイルまたはスタンバイ REDO ログ ファイル ( あるいはその両方 ) が 現在この宛先のデータベースでアーカイブされているかどうか カテゴリデータ型有効な値 VALID_FOR=(redo_log_type, database_role) 文字列値 該当なし デフォルト値 VALID_FOR=(ALL_LOGFILES, ALL_ROLES) 1 必須属性 属性との競合 対応先 なし なし V$ARCHIVE_DEST ビューの VALID_NOW VALID_TYPE および VALID_ROLE 列 1 ロジカル スタンバイ データベースには デフォルト値 VALID_FOR=(ALL LOGFILES, ALL_ ROLES) を使用しないでください 詳細は 項および 項の使用例を参照してください 使用方法 VALID_FOR 属性はオプションです ただし 各宛先に対してそれぞれ VALID_FOR 属性を定義し ロールの推移後に Data Guard 構成が正しく動作するようにすることをお薦めします 注意 : (ALL_LOGFILES,ALL_ROLES) キーワードのペアはデフォルトですが すべての宛先に適切とはかぎりません たとえば 宛先がロジカル スタンバイ データベース ( 独自の REDO データを作成するオープン状態のデータベース ) の場合 REDO 転送サービスによって転送される REDO データは ロジカル スタンバイ データベースのローカル オンライン REDO ログ ファイルを上書きする可能性があります LOG_ARCHIVE_DEST_n 宛先ごとにこれらの要因を構成するには キーワードのペア (VALID_FOR=(redo_log_type,database_role)) を使用してこの属性を指定します redo_log_type キーワードは 次のいずれかをアーカイブする場合に有効な宛先を識別します ONLINE_LOGFILE: この宛先は オンライン REDO ログ ファイルをアーカイブする場合のみ有効です STANDBY_LOGFILE: この宛先は スタンバイ REDO ログ ファイルをアーカイブする場合のみ有効です ALL_LOGFILES: この宛先は オンライン REDO ログ ファイルまたはスタンバイ REDO ログ ファイルをアーカイブする場合に有効です Oracle Data Guard 概要および管理

305 VALID_FOR 表 14-2 VALID_FOR 属性の値 VALID_FOR 定義 database_role キーワードは この宛先がアーカイブに有効なロールを識別します PRIMARY_ROLE: この宛先は データベースがプライマリ ロールで実行されている場合のみ有効です STANDBY_ROLE: この宛先は データベースがスタンバイ ロールで実行されている場合のみ有効です ALL_ROLES: この宛先は データベースがプライマリ ロールまたはスタンバイ ロールで実行されている場合に有効です 次の表は VALID_FOR 属性の値と それぞれの値が使用されるロールを示しています ONLINE_LOGFILE PRIMARY_ROLE アクティブ非アクティブ無効 ONLINE_LOGFILE STANDBY_ROLE 非アクティブ無効アクティブ ONLINE_LOGFILE ALL_ROLES アクティブ無効アクティブ STANDBY_LOGFILE PRIMARY_ROLE エラーエラーエラー STANDBY_LOGFILE STANDBY_ROLE 無効アクティブアクティブ STANDBY_LOGFILE ALL_ROLES 無効アクティブアクティブ ALL_LOGFILES PRIMARY_ROLE アクティブ非アクティブ無効 ALL_LOGFILES STANDBY_ROLE 無効アクティブアクティブ ALL_LOGFILES ALL_ROLES アクティブアクティブアクティブ プライマリ ロール フィジカル スタンバイ ロール ロジカル スタンバイ ロール 注意 : VALID_FOR=(STANDBY_LOGFILE, PRIMARY_ROLE) キーワードのペアは指定できません プライマリ データベースでスタンバイ REDO ログ ファイルを構成する場合は有効ですが プライマリ ロールで実行されているデータベースは スタンバイ REDO ログ ファイルを使用できません 宛先に VALID_FOR 属性を指定しないと データベースがプライマリ ロールまたはスタンバイ ロールで実行されているかどうかに関係なく デフォルトで オンライン REDO ログ ファイルとスタンバイ REDO ログ ファイルのアーカイブが宛先で有効になります このデフォルトの動作は VALID_FOR 属性で (ALL_LOGFILES,ALL_ROLES) キーワード ペアを設定した場合と同様です 次に例を示します LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll/arch/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) VALID_FOR 属性を使用すると 同じ初期化パラメータ ファイルをプライマリ ロールとスタンバイ ロールの両方に使用できます 例 次の例は VALID_FOR のデフォルトのキーワードのペアを示します LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata VALID_FOR=(ALL LOGFILES, ALL_ROLES)' このデータベースがプライマリ ロールまたはスタンバイ ロールで実行されている場合 宛先 1 は すべてのログ ファイルをローカル ディレクトリ /disk1/oracle/oradata にアーカイブします VALID_FOR 属性を使用した各種の Data Guard 構成の詳しい例は 12.1 項の使用例を参照してください LOG_ARCHIVE_DEST_n パラメータの属性 14-27

306 VERIFY VERIFY アーカイブ操作を正常に完了した後に アーカイバ (ARCn) プロセスでローカルまたはリモートで完了したアーカイブ REDO ログ ファイルをスキャンして その内容が正しいことを確認する必要があるかどうかを示します カテゴリデータ型有効な値デフォルト値必須属性属性との競合対応先 VERIFY キーワード該当なし該当なしなし LGWR V$ARCHIVE_DEST ビューの VERIFY および ARCHIVER 列 使用方法 VERIFY 属性を指定しない場合 アーカイブ REDO ログ ファイルは確認されません 確認は 常に実行される通常のチェックサム確認よりも詳細に行われます REDO 確認は 完了するまでにかなりの時間がかかる場合があります VERIFY 属性を使用すると プライマリ データベースのパフォーマンスに影響することがあります 例 次の例は VERIFY 属性を示しています LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata VERIFY' LOG_ARCHIVE_DEST_2='LOCATION=/arch1/SRLs/ VALID_FOR=(STANDBY_LOGFILE, STANDBY_ROLE) VERIFY' LOG_ARCHIVE_DEST_3='SERVICE=denver VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) VERIFY' Oracle Data Guard 概要および管理

307 15 Data Guard に関連する SQL 文 この章では Data Guard 環境のスタンバイ データベースで操作を実行するときに役立つ SQL および SQL*Plus 文の概要について説明します この章は 次の項目で構成されています ALTER DATABASE 文 ALTER SESSION 文 この章では 特定の SQL 文について その構文と簡単な概要を示します これらの SQL 文およびその他の SQL 文の完全な構文および説明は Oracle Database SQL リファレンス を参照してください ALTER SYSTEM SET 文を使用して設定および動的な更新を行うことができる初期化パラメータについては 第 13 章を参照してください Data Guard に関連する SQL 文 15-1

308 ALTER DATABASE 文 15.1 ALTER DATABASE 文 表 15-1 で Data Guard に関連のある ALTER DATABASE 文について説明します 表 15-1 Data Guard 環境で使用される ALTER DATABASE 文 ALTER DATABASE 文 ADD [STANDBY] LOGFILE [THREAD integer] [GROUP integer] filespec ADD [STANDBY] LOGFILE MEMBER 'filename' [REUSE] TO logfile-descriptor [ADD DROP] SUPPLEMENTAL LOG DATA {PRIMARY KEY UNIQUE INDEX} COLUMNS COMMIT TO SWITCHOVER TO [[PRIMARY] [[PHYSICAL LOGICAL] [STANDBY]] [WITH WITHOUT] SESSION SHUTDOWN] [WAIT NOWAIT] CREATE [PHYSICAL LOGICAL] STANDBY CONTROLFILE AS 'filename' [REUSE] 説明 指定したスレッドに 1 つ以上のオンライン REDO ログ ファイル グループまたはスタンバイ REDO ログ ファイル グループを追加し スレッドが割り当てられたインスタンスでログ ファイルを使用できるようにします この文の例は 項を参照してください 既存のオンライン REDO ログ ファイル グループまたはスタンバイ REDO ログ ファイル グループに新しいメンバーを追加します この文の例は 項を参照してください この文は ロジカル スタンバイ データベース専用です ロジカル スタンバイ データベースを作成する前に サプリメンタル ロギングを使用可能にするために使用します サプリメンタル ロギングがロジカル スタンバイ データベースに対する変更のソースであるため このようにする必要があります 完全なサプリメンタル ロギングを実装するには この文で PRIMARY KEY COLUMNS または UNIQUE INDEX COLUMNS キーワードを指定する必要があります 詳細は Oracle Database SQL リファレンス を参照してください 次のスイッチオーバーを実行します カレント プライマリ データベースをスタンバイ データベース ロールに変更する 1 つのスタンバイ データベースをプライマリ データベース ロールに変更する注意 : ロジカル スタンバイ データベースでは ALTER DATABASE COMMIT TO SWITCHOVER 文を発行する前に ALTER DATABASE PREPARE TO SWITCHOVER 文を発行し スイッチオーバーのためにデータベースを準備します この文の例は 項および 項を参照してください フィジカルまたはロジカル スタンバイ データベースの維持に使用される制御ファイルを作成します この文はプライマリ データベースで発行します この文の例は 項を参照してください DROP [STANDBY] LOGFILE logfile_descriptor オンライン REDO ログ ファイル グループまたはスタンバイ REDO ログ ファイル グループのすべてのメンバーを削除します この文の例は 項を参照してください DROP [STANDBY] LOGFILE MEMBER 'filename' [NO]FORCE LOGGING オンライン REDO ログ ファイル グループまたはスタンバイ REDO ログ ファイル グループの 1 つ以上のメンバーを削除します 一時表領域および一時セグメントに対する変更を除くデータベースに対するすべての変更を Oracle データベースが記録するかどうかを制御します [NO]FORCE LOGGING 句は スタンバイ データベース間の一貫性の欠如を防止するために必要です この文を発行する場合 プライマリ データベースがマウントされている必要があります ただし オープンする必要はありません この文の例は 項を参照してください 15-2 Oracle Data Guard 概要および管理

309 ALTER DATABASE 文 表 15-1 Data Guard 環境で使用される ALTER DATABASE 文 ( 続き ) ALTER DATABASE 文 MOUNT [STANDBY DATABASE] OPEN PREPARE TO SWITCHOVER TO [PRIMARY] [[PHYSICAL LOGICAL] [STANDBY]] [WITH WITHOUT] SESSION SHUTDOWN] [WAIT NOWAIT] RECOVER MANAGED STANDBY DATABASE [ [NODELAY] [DISCONNECT [FROM SESSION]] [NOPARALLEL PARALLEL [integer]] [NOTIMEOUT TIMEOUT [integer]] [UNTIL CHANGE scn] [USING CURRENT LOGFILE] ] RECOVER MANAGED STANDBY DATABASE CANCEL [[NOWAIT] [WAIT] [IMMEDIATE] ] RECOVER MANAGED STANDBY DATABASE FINISH [FORCE] [NOWAIT WAIT] ] REGISTER [OR REPLACE] [PHYSICAL LOGICAL] LOGFILE filespec RECOVER TO LOGICAL STANDBY new_database_ name RESET DATABASE TO INCARNATION integer SET STANDBY DATABASE TO MAXIMIZE {PROTECTION AVAILABILITY PERFORMANCE} 説明 スタンバイ データベースをマウントし スタンバイ インスタンスが REDO データをプライマリ インスタンスから受信できるようにします すでに起動され マウントされたデータベースをオープンします フィジカル スタンバイ データベースは読取り専用モードでオープンされ ユーザーを読取り専用トランザクションに制限し REDO データの生成を防ぎます ロジカル スタンバイ データベースは読取り / 書込みモードでオープンされます この文の例は 項を参照してください この文は ロジカル スタンバイ データベース専用です スイッチオーバーが実行される前に LogMiner ディクショナリを構築することにより プライマリ データベースおよびロジカル スタンバイ データベースをスイッチオーバー用に準備します ディクショナリ構築の完了後 ALTER DATABASE COMMIT TO SWITCHOVER 文を発行し プライマリおよびロジカル スタンバイ データベースのロールを切り替えます この文の例は 項を参照してください この文は フィジカル スタンバイ データベースに対する REDO Apply を開始して制御します RECOVER MANAGED STANDBY DATABASE 句は マウント オープンまたはクローズされているフィジカル スタンバイ データベースで使用できます 例については 項の手順 2 および 6.3 項を参照してください 注意 : 複数の句およびキーワードが廃止され 下位互換性のためにのみサポートされています CANCEL 句は 現在のアーカイブ REDO ログ ファイルを適用した後に フィジカル スタンバイ データベースで REDO Apply を取り消します FINISH 句は ターゲット フィジカル スタンバイ データベースでフェイルオーバーを開始し 現行のスタンバイ REDO ログ ファイルをリカバリします FINISH 句を使用するのは プライマリ データベースに障害が発生した場合のみです この句により 指定の遅延間隔がオーバーライドされます RFS プロセスを終了し RFS プロセスの終了を待たずに即時にフェイルオーバーできるようにするには FORCE を挿入します リカバリ プロセスの完了後ではなく即時に制御を戻させるには NOWAIT を指定します 例については 項の手順 4 を参照してください 手動でアーカイブ REDO ログ ファイルを登録できます この文の例は 項を参照してください ログ適用サービスに対して データベースをロジカル スタンバイ データベースに変換するコマンドを発行するまでは 引き続き変更をフィジカル スタンバイ データベースに適用するように指示します 詳細は 項を参照してください データベースのターゲット リカバリ インカネーションを 現在のインカネーションから別のインカネーションにリセットします この句を使用して Data Guard 構成におけるデータの保護レベルを指定します この句は マウント済でオープンされていないプライマリ データベースから指定します Data Guard に関連する SQL 文 15-3

310 ALTER SESSION 文 表 15-1 Data Guard 環境で使用される ALTER DATABASE 文 ( 続き ) ALTER DATABASE 文 START LOGICAL STANDBY APPLY INITIAL [scn-value] ][NEW PRIMARY dblink] {STOP ABORT} LOGICAL STANDBY APPLY ACTIVATE [PHYSICAL LOGICAL] STANDBY DATABASE FINISH APPLY] 説明 この文は ロジカル スタンバイ データベース専用です ロジカル スタンバイ データベースで SQL Apply を起動します この文の例は 項を参照してください この文は ロジカル スタンバイ データベース専用です ロジカル スタンバイ データベースで SQL Apply を正しく停止するには STOP 句を使用します SQL Apply を強制的に停止するには ABORT 句を使用します この文の例は 項を参照してください フェイルオーバーを実行します スタンバイ データベースは マウント後に この文を使用してアクティブ化する必要があります 注意 : ALTER DATABASE ACTIVATE STANDBY DATABASE 文をフェイルオーバーに使用しないでください データ消失が発生します かわりに 次のベスト プラクティスに従ってください フィジカル スタンバイ データベースの場合 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 文で FINISH キーワードを使用します これにより ロールの推移がすばやく実行されるため データ消失は防止されるかまたは最小限に抑えられ 他のスタンバイ データベースが使用できなくなることはありません 注意 : フェイルオーバー操作は 最後にアーカイブされるログ ファイルのヘッダーに end-of-redo マーカーを追加し プライマリ ロールに指定できるすべての有効な宛先 (VALID_FOR=(PRIMARY_ROLE, *_LOGFILES) または VALID_FOR=(ALL_ROLES, *_LOGFILES) 属性で指定されます ) に REDO を送信します ロジカル スタンバイ データベースの場合 ALTER DATABASE PREPARE TO SWITCHOVER および ALTER DATABASE COMMIT TO SWITCHOVER 文を使用します 15.2 ALTER SESSION 文 表 15-2 で Data Guard に関連のある ALTER SESSION 文について説明します 表 15-2 Data Guard 環境で使用される ALTER SESSION 文 ALTER SESSION 文 ALTER SESSION [ENABLE DISABLE] GUARD 説明 この文は ロジカル スタンバイ データベース専用です 権限を付与されているユーザーは この文を使用して 現在のセッションでデータベース ガードを選択または解除できます この文の例は 項を参照してください 15-4 Oracle Data Guard 概要および管理

311 16 Oracle Data Guard に関連するビュー この章では Data Guard 環境で重要であるビューについて説明します この章で説明されているビューは Oracle データベースで使用可能なビューのサブセットです 表 16-1 では各ビューについて説明し そのビューがフィジカル スタンバイ データベース ロジカル スタンバイ データベース プライマリ データベースのいずれに適用されるのかを示します 各ビューの詳細は Oracle Database リファレンス を参照してください 表 16-1 Data Guard 構成に関連のあるビュー ビュー データベース 説明 DBA_LOGSTDBY_EVENTS ロジカルのみ ロジカル スタンバイ データベースのアクティビティに関する情報が格納されます このビューは SQL Apply によって REDO がロジカル スタンバイ データベースに適用されるときに発生する障害の原因究明に役立ちます DBA_LOGSTDBY_HISTORY ロジカルのみ Data Guard 構成内のロジカル スタンバイ データベースに関するスイッチオーバーとフェイルオーバーの履歴を表示します そのために すべてのロールの推移間で ローカル システム上にて処理または作成された REDO ログ ストリームの順序全体が表示されます ( ロールの推移後は新規のログ ストリームが開始され 新しいプライマリ データベースによりログ ストリーム順序番号が増分されます ) DBA_LOGSTDBY_LOG ロジカルのみ ロジカル スタンバイ データベースにレジストリされている ログ ファイルを表示します DBA_LOGSTDBY_NOT_UNIQUE ロジカルのみ 主キー制約または NOT NULL の一意制約がない表を識別しま す DBA_LOGSTDBY_PARAMETERS ロジカルのみ SQL Apply で使用されるパラメータのリストが格納されます DBA_LOGSTDBY_SKIP ロジカルのみ SQL Apply によってスキップされる表をリスト表示します DBA_LOGSTDBY_SKIP_ TRANSACTION ロジカルのみ 選択されているスキップ設定をリスト表示します DBA_LOGSTDBY_UNSUPPORTED ロジカルのみ サポートされないデータ型が含まれているスキーマおよび表 ( およびその表の列 ) を識別します このビューは ロジカル スタンバイ データベースの作成を準備する際に使用します V$ARCHIVE_DEST プライマリ フィジカルおよびロジカル Data Guard 構成内のすべての宛先の現在の値 モードおよび状況を含めた説明を表示します 注意 : このビューに表示される情報は インスタンスの停止後には保存されません Oracle Data Guard に関連するビュー 16-1

312 表 16-1 Data Guard 構成に関連のあるビュー ( 続き ) ビュー V$ARCHIVE_DEST_STATUS V$ARCHIVE_GAP V$ARCHIVED_LOG V$DATABASE V$DATABASE_INCARNATION V$DATAFILE データベース プライマリ フィジカルおよびロジカル フィジカルおよびロジカル プライマリ フィジカルおよびロジカル プライマリ フィジカルおよびロジカル プライマリ フィジカルおよびロジカル プライマリ フィジカルおよびロジカル 説明 アーカイブ REDO ログ宛先の実行時および構成用の情報を表示します 注意 : このビューに表示される情報は インスタンスの停止後には保存されません アーカイブ REDO ログ ファイルのギャップの識別に役立つ情報を表示します 制御ファイルのアーカイブ REDO ログ情報を アーカイブ REDO ログ ファイル名を含めて表示します 制御ファイルからのデータベース情報を表示します ファスト スタート フェイルオーバー (Data Guard Broker でのみ使用可能 ) に関する情報が含まれます すべてのデータベース インカネーションに関する情報を表示します Oracle Database では RESETLOGS オプションを使用してデータベースがオープンされるたびに 新しいインカネーションが作成されます V$DATABASE ビューには 現在のインカネーションのみでなく 前のインカネーションのレコードも表示されます 制御ファイルからのデータファイル情報を表示します V$DATAGUARD_CONFIG V$DATAGUARD_STATS V$DATAGUARD_STATUS V$LOG V$LOGFILE V$LOG_HISTORY プライマリ フィジカルおよびロジカル プライマリ フィジカルおよびロジカル プライマリ フィジカルおよびロジカル プライマリ フィジカルおよびロジカル プライマリ フィジカルおよびロジカル プライマリ フィジカルおよびロジカル DB_UNIQUE_NAME および LOG_ARCHIVE_CONFIG 初期化パラメータで定義された一意のデータベース名をリスト表示します プライマリ データベースで生成され まだスタンバイ データベースで使用できない REDO データの量を表示するとともに このビューの問合せ時点でプライマリ データベースが仮にクラッシュした場合に失われる可能性のある REDO データの量も表示します Data Guard 構成では スタンバイ データベースのどのインスタンスでもこのビューを問い合せることができます プライマリ データベースでこのビューを問い合せた場合 列の値は消去されます 通常はアラート ログまたはサーバー プロセスのトレース ファイルへのメッセージによってトリガーされるイベントが表示および記録されます オンライン REDO ログ ファイルのログ ファイル情報が格納されます オンライン REDO ログ ファイルとスタンバイ REDO ログ ファイルに関する情報が格納されます 制御ファイルからのログ履歴情報が格納されます V$LOGSTDBY_PROCESS ロジカルのみ SQL Apply の動作に関する動的な情報を表示します このビューは ロジカル スタンバイ データベースで SQL Apply を実行しているときのパフォーマンス上の問題を診断する場合に非常に有用です このビューはまた その他の問題の解決にも役立ちます V$LOGSTDBY_PROGRESS ロジカルのみ ロジカル スタンバイ データベースでの SQL Apply の進捗 状況を表示します 16-2 Oracle Data Guard 概要および管理

313 表 16-1 Data Guard 構成に関連のあるビュー ( 続き ) ビュー データベース 説明 V$LOGSTDBY_STATE ロジカルのみ SQL Apply とロジカル スタンバイ データベースの実行状態 に関して V$LOGSTDBY_PROCESS および V$LOGSTDBY_STATS ビューの情報を連結します V$LOGSTDBY_STATS ロジカルのみ LogMiner 統計 現行のステータスおよび SQL Apply 時のロジカル スタンバイ データベースのステータス情報を表示します SQL Apply が実行されていない場合 統計の値は消去されます V$LOGSTDBY_TRANSACTION ロジカルのみ ロジカル スタンバイ データベースで SQL Apply により処 理中のすべてのアクティブ トランザクションに関する情報を 表示します V$MANAGED_STANDBY フィジカルのみ フィジカル スタンバイ データベースに関連する Oracle デー タベース プロセスの現在の状態を表示します V$STANDBY_LOG フィジカルおよびロジカル 注意 : このビューに表示される情報は インスタンスの停止後には保存されません スタンバイ REDO ログ ファイルのログ ファイル情報が格納されます Oracle Data Guard に関連するビュー 16-3

314 16-4 Oracle Data Guard 概要および管理

315 第 III 部 付録 この部は 次の付録で構成されています 付録 A Data Guard のトラブルシューティング 付録 B Data Guard 構成におけるデータベースのアップグレード 付録 C ロジカル スタンバイ データベースでサポートされるデータ型および DDL 付録 D Data Guard および Real Application Clusters 付録 E カスケードされた宛先 付録 F Recovery Manager を使用したスタンバイ データベースの作成 付録 G アーカイブ トレースの設定

316

317 A Data Guard のトラブルシューティング この付録は スタンバイ データベースのトラブルシューティングのヘルプとしてご利用いただけます この項は 次の項目で構成されています 一般的な問題 ログ ファイル宛先の障害 ロジカル スタンバイ データベース障害の処理 スタンバイ データベースへのスイッチオーバーの問題 SQL Apply が停止した場合の処置 REDO データ転送のネットワーク調整 スタンバイ データベースのディスクのパフォーマンスが遅い プライマリ データベースの停止を回避するにはログ ファイルを一致させる必要がある ロジカル スタンバイ データベースのトラブルシューティング Data Guard のトラブルシューティング A-1

318 一般的な問題 A.1 一般的な問題 スタンバイ データベースの使用時に発生する問題の原因には 次のようなものがあります スタンバイ アーカイブ宛先が適切に定義されていない ALTER DATABASE 文によるデータファイル名の変更 スタンバイ データベースがプライマリ データベースから REDO データを受信しない フィジカル スタンバイ データベースをマウントできない A.1.1 スタンバイ アーカイブ宛先が適切に定義されていない STANDBY_ARCHIVE_DEST 初期化パラメータでスタンバイ データベースの有効なディレクトリ名を指定していない場合 Oracle データベースは アーカイブ REDO ログ ファイルを格納するディレクトリを決定できません 次の問合せを入力して V$ARCHIVE_DEST ビューの DESTINATION 列および ERROR 列を調べ 宛先が有効であることを確認します SQL> SELECT DESTINATION, ERROR FROM V$ARCHIVE_DEST; A.1.2 ALTER DATABASE 文によるデータファイル名の変更 STANDBY_FILE_MANAGEMENT 初期化パラメータを AUTO に設定すると スタンバイ サイトのデータファイルを改名できません STANDBY_FILE_MANAGEMENT 初期化パラメータを AUTO に設定した場合 次の SQL 文は使用できなくなります ALTER DATABASE RENAME ALTER DATABASE ADD/DROP LOGFILE ALTER DATABASE ADD/DROP STANDBY LOGFILE MEMBER ALTER DATABASE CREATE DATAFILE AS スタンバイ データベースでこれらの文のいずれかを使用しようとすると エラーが表示されます 次に例を示します SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/t_db2.log' to 'dummy'; alter database rename file '/disk1/oracle/oradata/payroll/t_db2.log' to 'dummy' * ERROR at line 1: ORA-01511: ログ / データファイルの名前の変更中にエラーが発生しました ORA-01270: STANDBY_PRESERVES_NAMES が TRUE の場合 RENAME 操作はできません フィジカル スタンバイ データベースにデータファイルを追加する方法は 項を参照してください A-2 Oracle Data Guard 概要および管理

319 一般的な問題 A.1.3 スタンバイ データベースがプライマリ データベースから REDO データを受信しない スタンバイ サイトが REDO データを受信していない場合は V$ARCHIVE_DEST ビューを問い合せて エラー メッセージをチェックします たとえば 次のような問合せを入力します SQL> SELECT DEST_ID "ID", 2> STATUS "DB_status", 3> DESTINATION "Archive_dest", 4> ERROR "Error" 5> FROM V$ARCHIVE_DEST WHERE DEST_ID <=5; ID DB_status Archive_dest Error VALID /vobs/oracle/work/arc_dest/arc 2 ERROR standby1 ORA-16012: アーカイブ ログのスタンバイ データベース識別子が一致しません 3 INACTIVE 4 INACTIVE 5 INACTIVE 5 rows selected. 問合せの出力によって解決しない場合は 次の問題リストを確認します 次のいずれかの条件に該当する場合 REDO 転送サービスはスタンバイ データベースに REDO データを転送できません プライマリ データベースの tnsnames.ora ファイル内でスタンバイ インスタンスのサービス名が正しく構成されていない場合 プライマリ データベースの LOG_ARCHIVE_DEST_n パラメータで指定された Oracle Net サービス名が不適切な場合 スタンバイ データベースの LOG_ARCHIVE_DEST_STATE_n パラメータが値 ENABLE に設定されていない場合 listener.ora ファイルがスタンバイ データベース用に正しく構成されていない場合 スタンバイ サイトでリスナーが開始されていない場合 スタンバイ インスタンスが起動されていない場合 スタンバイ アーカイブ先をプライマリ SPFILE またはテキスト初期化パラメータ ファイルに追加したが その変更をまだ使用可能にしていない場合 Data Guard 構成にパスワード ファイルを使用していないデータベースがあるか このパスワード ファイル内の SYS パスワードが全システムで同一でない場合 スタンバイ データベースのベースとして無効なバックアップを使用した場合 ( たとえば 間違ったデータベースからのバックアップを使用 または正しい方法でスタンバイ制御ファイルを作成しなかったなど ) A.1.4 フィジカル スタンバイ データベースをマウントできない スタンバイ制御ファイルが ALTER DATABASE CREATE [LOGICAL] STANDBY CONTROLFILE... 文または Recovery Manager のコマンドを使用して作成されていない場合 スタンバイ データベースをマウントすることはできません 次のタイプの制御ファイル バックアップは使用できません オペレーティング システムで作成されたバックアップ PHYSICAL STANDBY または LOGICAL STANDBY オプションのない ALTER DATABASE 文を使用して作成されたバックアップ Data Guard のトラブルシューティング A-3

320 ログ ファイル宛先の障害 A.2 ログ ファイル宛先の障害 OPTIONAL 宛先に REOPEN を指定した場合は 問題の宛先へのアーカイブ時にエラーが発生した場合でも Oracle データベースはオンライン REDO ログ ファイルを再利用できます MANDATORY 宛先に REOPEN を指定した場合 REDO 転送サービスは REDO データを正常に転送できなかったとき プライマリ データベースを停止します MAX_FAILURE 属性を使用する場合は REOPEN 属性は必須です 例 A-1 に 再試行時間を 5 秒に設定し 再試行回数を 3 回に制限する方法を示します 例 A-1 再試行時間の設定と制限 LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3' LOG_ARCHIVE_DEST_n パラメータの ALTERNATE 属性を使用して代替アーカイブ先を指定します スタンバイ データベースへの REDO データの転送に失敗した場合は 代替アーカイブ先を使用できます 転送に失敗したときに REOPEN 属性が指定されていなかった場合 または MAX_FAILURE 属性のしきい値を超えた場合 REDO 転送サービスは 次のアーカイブ操作時に代替先への REDO データの転送を試みます 元のアーカイブ先で障害が発生したときに 元のアーカイブ先が自動的に代替アーカイブ先に変更されることを防ぐには NOALTERNATE 属性を使用します 例 A-2 は エラー発生時に 単一 必須のローカル宛先が異なる宛先へ自動的にフェイルオーバーするように初期化パラメータを設定する方法を示します 例 A-2 代替宛先の指定 LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY' LOG_ARCHIVE_DEST_STATE_2=ALTERNATE 宛先 LOG_ARCHIVE_DEST_1 で障害が発生した場合 アーカイブ プロセスは プライマリ データベースでの次のログ ファイル スイッチで宛先を LOG_ARCHIVE_DEST_2 に自動的に切り替えます A.3 ロジカル スタンバイ データベース障害の処理 ロジカル スタンバイ データベース障害を処理するための重要なツールは DBMS_ LOGSTDBY.SKIP_ERROR プロシージャです 表の重要度に基づいて 次のいずれかを実行できます 表や特定の DDL に関する障害を無視する ストアド プロシージャをフィルタに関連付ける これによって 文のスキップ 文の実行または代用文の実行について実行時に決定できます これらの処理のいずれかを実行すると SQL Apply の停止を回避できます 存在している問題は 後で DBA_LOGSTDBY_EVENTS ビューを問い合せて検索し 訂正できます DBMS_ LOGSTDBY パッケージの PL/SQL コールアウト プロシージャの使用方法については Oracle Database PL/SQL パッケージ プロシージャおよびタイプ リファレンス を参照してください A-4 Oracle Data Guard 概要および管理

321 スタンバイ データベースへのスイッチオーバーの問題 A.4 スタンバイ データベースへのスイッチオーバーの問題 通常 第 7 章で説明した手順に従うと スイッチオーバーは正常に行われます ただし スイッチオーバーが失敗した場合でも 次の項を読むと 問題の解決に役立ちます REDO データが転送されていないためスイッチオーバーできない SQL セッションがアクティブなためスイッチオーバーできない ユーザー セッションがアクティブなためスイッチオーバーできない ORA エラーによりスイッチオーバーできない スイッチオーバー後に REDO データが適用されない 失敗したスイッチオーバーをロールバックして最初からやり直す A.4.1 REDO データが転送されていないためスイッチオーバーできない スイッチオーバーが正常に完了しない場合は V$ARCHIVED_LOG ビューの SEQUENCE# 列を問い合せて 元のプライマリ データベースから転送された最後の REDO データが スタンバイ データベースに適用されているかどうかを確認します 最後の REDO データがスタンバイ データベースに転送されていない場合は その REDO データが含まれるアーカイブ REDO ログ ファイルを元のプライマリ データベースから古いスタンバイ データベースに手動でコピーし SQL の ALTER DATABASE REGISTER LOGFILE file_specification 文を使用して登録します 次に ログ適用サービスを開始すると アーカイブ REDO ログ ファイルが自動的に適用されます V$DATABASE ビューの SWITCHOVER_STATUS 列を問い合せます SWITCHOVER_STATUS 列の値 TO PRIMARY は プライマリ ロールへのスイッチオーバーが可能になったことを示します SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS TO PRIMARY 1 row selected V$DATABASE ビューの SWITCHOVER_STATUS 列に対するその他の有効な値については 第 16 章を参照してください スイッチオーバーを続行するには 項 ( フィジカル スタンバイ データベースの場合 ) または 項 ( ロジカル スタンバイ データベースの場合 ) の説明に従って ターゲットのスタンバイ データベースをプライマリ ロールに切り替える操作を再度実行します A.4.2 SQL セッションがアクティブなためスイッチオーバーできない ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY 文に WITH SESSION SHUTDOWN 句を組み込んでいない場合 アクティブな SQL セッションがあると スイッチオーバーを継続できません アクティブな SQL セッションには 他の Oracle Database プロセスが含まれていることがあります セッションがアクティブのときは スイッチオーバーの試行が次のエラー メッセージを伴って失敗します SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY; ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY * ORA-01093: ALTER DATABASE CLOSE は接続中のセッションがない場合にのみ実行できます Data Guard のトラブルシューティング A-5

322 スタンバイ データベースへのスイッチオーバーの問題 処置 : V$SESSION ビューを問い合せ エラーの原因となっているプロセスを判断します 次に例を示します SQL> SELECT SID, PROCESS, PROGRAM FROM V$SESSION 2> WHERE TYPE = 'USER' 3> AND SID <> (SELECT DISTINCT SID FROM V$MYSTAT); SID PROCESS PROGRAM oracle@nhclone2 (CJQ0) rows selected. この例では JOB_QUEUE_PROCESSES パラメータが CJQ0 プロセス エントリに対応しています ジョブ キュー プロセスはユーザー プロセスなので スイッチオーバーの発生を妨げるのは SQL セッションであると考えられます プロセスまたはプログラム情報のないエントリは ジョブ キュー コントローラによって開始されるスレッドです 次の SQL 文を使用して JOB_QUEUE_PROCESSES パラメータが設定されていることを確認してください SQL> SHOW PARAMETER JOB_QUEUE_PROCESSES; NAME TYPE VALUE job_queue_processes integer 5 さらに パラメータを 0( ゼロ ) に設定してください 次に例を示します SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0; Statement processed. JOB_QUEUE_PROCESSES は動的パラメータであるため 値を変更した際にインスタンスを再起動しなくても 変更を即時に有効にできます これで スイッチオーバー手順を再試行できます 初期化パラメータ ファイル内のパラメータは変更しないでください インスタンスを停止し スイッチオーバーが完了した後で再起動すると パラメータが元の値にリセットされます これは プライマリ データベースとフィジカル スタンバイ データベースの両方に適用されます 表 A-1 に スイッチオーバーを妨げる共通のプロセスと 実行する必要のある対処措置をまとめます 表 A-1 スイッチオーバーを妨げる共通のプロセス プロセスのタイプ プロセスの説明 対処措置 CJQ0 Job Queue Scheduler Process JOB_QUEUE_PROCESSES 動的パラメータを値 0 ( ゼロ ) に変更してください 変更は インスタンスを再起動しなくても即時に有効になります QMN0 Advanced Queue Time Manager AQ_TM_PROCESSES 動的パラメータを値 0( ゼロ ) に変更してください 変更は インスタンスを再起動しなくても即時に有効になります DBSNMP Oracle Enterprise Manager Management Agent オペレーティング システム プロンプトから agentctl stop コマンドを発行してください A-6 Oracle Data Guard 概要および管理

323 スタンバイ データベースへのスイッチオーバーの問題 A.4.3 ユーザー セッションがアクティブなためスイッチオーバーできない スイッチオーバーに失敗し エラー ORA-01093: ALTER DATABASE CLOSE は接続中のセッションがない場合にのみ実行できます が戻された場合 通常これは ALTER DATABASE COMMIT TO SWITCHOVER 文が暗黙的にデータベースのクローズを実行したときに その他のユーザー セッションがデータベースに接続されていてクローズできなかったことが原因と考えられます このエラーが発生した場合は データベースに接続されているユーザー セッションをすべて切断します これを実行するには 次の例に示すように V$SESSION 固定ビューを問い合せて まだアクティブなセッションを確認します SQL> SELECT SID, PROCESS, PROGRAM FROM V$SESSION; SID PROCESS PROGRAM oracle@dbuser-sun (PMON) oracle@dbuser-sun (DBW0) oracle@dbuser-sun (LGWR) oracle@dbuser-sun (CKPT) oracle@dbuser-sun (SMON) oracle@dbuser-sun (RECO) oracle@dbuser-sun (ARC0) sqlplus@dbuser-sun (TNS V1-V3) sqlplus@dbuser-sun (TNS V1-V3) 9 rows selected. この例の最初の 7 つのセッションはすべて Oracle Database のバックグラウンド プロセスです 2 つの SQL*Plus セッションの内 一方は問合せを発行中のカレントの SQL*Plus セッションで 他方はスイッチオーバーを再試行する前に切断される必要のある余分のセッションです A.4.4 ORA エラーによりスイッチオーバーできない スタンバイ データベースとプライマリ データベースが同じサイトに存在するとします ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY 文および ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY 文の両方が正常に実行された後 フィジカル スタンバイ データベースとプライマリ データベースを停止し 再起動します 注意 : フィジカル スタンバイ データベースが起動後に読取り専用モードでオープンされていない場合 停止して再起動する必要はありません ただし 2 つ目のデータベースの起動はエラー メッセージ ORA データベースを排他モードでマウントすることができません を伴って失敗します スタンバイ データベース ( つまり元のプライマリ データベース ) で使用される初期化パラメータ ファイルに DB_UNIQUE_NAME パラメータを設定していないと スイッチオーバー中にこの現象が発生することがあります スタンバイ データベースの DB_UNIQUE_NAME パラメータが設定されていない場合 スタンバイ データベースとプライマリ データベースの両方が同じマウント ロックを使用するため 2 つ目のデータベースの起動時に ORA エラーが発生します 処置 : DB_UNIQUE_NAME=unique_database_name をスタンバイ データベースが使用する初期化パラメータ ファイルに追加して スタンバイ データベースとプライマリ データベースを停止し 再起動します Data Guard のトラブルシューティング A-7

324 スタンバイ データベースへのスイッチオーバーの問題 A.4.5 スイッチオーバー後に REDO データが適用されない スイッチオーバー後にアーカイブ REDO ログ ファイルが新しいスタンバイ データベースに適用されません これは スイッチオーバー後 環境パラメータまたは初期化パラメータが適切に設定されていなかったことが原因と考えられます 処置 : 新しいプライマリ サイトの tnsnames.ora ファイルおよび新しいスタンバイ サイトの listener.ora ファイルを調べます スタンバイ サイトにはリスナーのエントリ プライマリ サイトにはそれに対応するサービス名が必要です リスナーがまだ起動されていない場合は スタンバイ サイトで起動します プライマリ サイトからスタンバイ サイトに REDO データを正しく転送するための LOG_ARCHIVE_DEST_n 初期化パラメータが設定されているかどうかを調べます たとえば プライマリ サイトで V$ARCHIVE_DEST 固定ビューを次のように問い合せます SQL> SELECT DEST_ID, STATUS, DESTINATION FROM V$ARCHIVE_DEST; スタンバイ サイトに対応するエントリが見つからない場合 LOG_ARCHIVE_DEST_n 初期化パラメータおよび LOG_ARCHIVE_DEST_STATE_n 初期化パラメータを設定する必要があります スタンバイ サイトに STANDBY_ARCHIVE_DEST 初期化パラメータおよび LOG_ARCHIVE_ FORMAT 初期化パラメータを正しく設定し アーカイブ REDO ログ ファイルが適切な場所に適用されるようにします スタンバイ サイトで DB_FILE_NAME_CONVERT 初期化パラメータおよび LOG_FILE_ NAME_CONVERT 初期化パラメータを設定します プライマリ サイトで作成された新しいデータファイルがスタンバイ サイトに自動的に追加されるようにするには STANDBY_ FILE_MANAGEMENT 初期化パラメータを AUTO に設定します A.4.6 失敗したスイッチオーバーをロールバックして最初からやり直す フィジカル スタンバイ データベースでエラーが発生し スイッチオーバーを続行できない場合は 次の手順に従って 新しいフィジカル スタンバイ データベースをプライマリ ロールに戻すことができます 1. 新しいスタンバイ データベース ( 元のプライマリ ) に接続し 次の文を発行して このスタンバイ データベースをプライマリ ロールに戻します SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; この文が正常に実行された場合は 必要に応じてデータベースを停止し 再起動します 再起動すると データベースはプライマリ データベース ロールで実行されるため それ以降の手順を実行する必要はありません この文が正常に実行されなかった場合は 手順 3 に進んでください 2. プライマリからフィジカル スタンバイにロールを変更するスイッチオーバーを開始したときに トレース ファイルがログ ディレクトリに書き込まれています このトレース ファイルには 元のプライマリ制御ファイルを再作成するために必要な SQL 文が含まれています トレース ファイルの位置を特定し SQL 文を一時ファイルに抽出します SQL*Plus から一時ファイルを実行します これによって 新しいスタンバイ データベースはプライマリ ロールに戻されます 3. 元のフィジカル スタンバイ データベースを停止します 4. 新しいスタンバイ制御ファイルを作成します このファイルは プライマリ データベースとフィジカル スタンバイ データベースの再同期化に必要です フィジカル スタンバイ制御ファイルを元のフィジカル スタンバイ システムにコピーします フィジカル スタンバイ制御ファイルの作成方法については 項を参照してください A-8 Oracle Data Guard 概要および管理

325 SQL Apply が停止した場合の処置 5. 元のフィジカル スタンバイ インスタンスを再起動します この手順が正常終了し アーカイブ ギャップ管理が使用可能になると FAL プロセスが起動し 欠落したアーカイブ REDO ログ ファイルをフィジカル スタンバイ データベースに再アーカイブします プライマリ データベース上でログ スイッチを強制実行し プライマリ データベースとフィジカル スタンバイ データベースの両方のアラート ログを調べて アーカイブ REDO ログ ファイルの順序番号が正しいことを確認します アーカイブ ギャップ管理の詳細は 5.8 項を トレース ファイルの場所については付録 G を参照してください 6. スイッチオーバーを再度実行します この時点で Data Guard 構成は初期状態にロールバックされています 最初に失敗したスイッチオーバーの問題をすべて解決した後 スイッチオーバー操作を再度実行できます A.5 SQL Apply が停止した場合の処置 ログ適用サービスでは サポートされない DML 文 DDL 文およびオラクル社が提供するパッケージを SQL Apply が実行されているロジカル スタンバイ データベースに適用できません サポートされない文やパッケージが検出されると SQL Apply は停止します 表 A-2 で説明する処理を実行して問題を解決した後 ロジカル スタンバイ データベースで SQL Apply を再開してください 表 A-2 一般的な SQL Apply エラーの解決方法 エラー サポートされない文またはオラクル社が提供するパッケージが検出された可能性を示すエラー データベース管理を要求するエラー ( 特定の表領域内の領域不足など ) 不適切な SQL 文の入力によるエラー ( 不適切なスタンバイ データベースのファイル名が表領域文に入力された場合など ) 解決方法 DBA_LOGSTDBY_EVENTS ビューで 最後の文を検索してください この結果 SQL Apply の失敗の原因となった文とエラーが表示されます 不適切な SQL 文が原因で SQL Apply に失敗した場合は その文とエラーに関する情報とともにトランザクション情報を表示できます このトランザクション情報は 問題の原因を正確に判断するために LogMiner ツールで使用できます 問題を解決した後 ALTER DATABASE START LOGICAL STANDBY APPLY 文を使用して SQL Apply を再開してください 適切な SQL 文を入力した後 DBMS_LOGSTDBY.SKIP_ TRANSACTION プロシージャを使用して 次回 SQL Apply が実行されたときに不適切な文が無視されるようにしてください その後 ALTER DATABASE START LOGICAL STANDBY APPLY 文を使用して SQL Apply を再開してください 不適切な SKIP パラメータの設定によるエラー DBMS_LOGSTDBY.SKIP('TABLE','schema_name','table_ ( 特定の表で全 DML がスキップされるように指定 name',null) プロシージャを発行した後 SQL Apply を再開してしたが CREATE ALTER および DROP TABLE のください 各文がスキップされるように指定していないなど ) 障害の原因を特定するために DBA_LOGSTDBY_EVENTS ビューを問い合せる方法は 第 16 章を参照してください Data Guard のトラブルシューティング A-9

326 REDO データ転送のネットワーク調整 A.6 REDO データ転送のネットワーク調整 最適なパフォーマンスを得るには REDO 転送サービスで使用される各 Oracle Net 接続記述子で Oracle Net SDU パラメータを 32 KB に設定します 次の例は リモート宛先 netserv を定義するデータベース初期化パラメータ ファイル セグメントを示します LOG_ARCHIVE_DEST_3='SERVICE=netserv' 次の例は tnsnames.ora ファイル内のサービス名の定義を示します netserv=(description=(sdu=32768)(address=(protocol=tcp)(host=host) (PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=srvc))) 次の例は listener.ora ファイル内の定義を示します LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp) (HOST=host)(PORT=1521)))) SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SDU=32768)(SID_NAME=sid) (GLOBALDBNAME=srvc)(ORACLE_HOME=/oracle))) 待機時間が長いかまたは帯域幅が大きいネットワーク リンクを使用してリモート サイトへのアーカイブを行う場合は Oracle Net プロファイル パラメータ SQLNET.SEND_BUF_SIZE および SQLNET.RECV_BUF_SIZE を使用して ネットワークの送受信 I/O バッファのサイズを大きくすることでパフォーマンスを改善できます Oracle Database Net Services 管理者ガイド を参照してください A.7 スタンバイ データベースのディスクのパフォーマンスが遅い ファイル システム上の非同期 I/O がパフォーマンス上の問題を示している場合は ダイレクト I/O オプションを使用してファイル システムをマウントするか または FILESYSTEMIO_ OPTIONS=SETALL 初期化パラメータを設定します 最大 I/O のサイズ設定は 1MB です A.8 プライマリ データベースの停止を回避するにはログ ファイルを一致させる必要がある 構成内の 1 つ以上のスタンバイ データベースでスタンバイ REDO ログを構成した場合は 各スタンバイ データベースのスタンバイ REDO ログ ファイルのサイズが プライマリ データベースのオンライン REDO ログ ファイルのサイズと正確に一致していることを確認してください ログ スイッチが発生したときに プライマリ データベースに新しい現行のオンライン REDO ログ ファイルのサイズと一致する使用可能なスタンバイ REDO ログ ファイルがない場合 次のようになります プライマリ データベースが最大保護モードで作動しているときは停止します または スタンバイ データベース上の RFS プロセスにより スタンバイ データベースにアーカイブ REDO ログ ファイルが作成され 次のメッセージがアラート ログに書き込まれます No standby log files of size <#> blocks available. たとえば プライマリ データベースで ログ ファイルが 100K のオンライン REDO ログ グループを 2 つ使用する場合 スタンバイ データベースは ログ ファイル サイズが 100K のスタンバイ REDO ログ グループを 3 つ持ちます A-10 Oracle Data Guard 概要および管理

327 ロジカル スタンバイ データベースのトラブルシューティング また REDO ログ グループをプライマリ データベースに追加した場合は 対応するスタンバイ REDO ログ グループをスタンバイ データベースに追加する必要があります これにより プライマリ データベースが悪影響を受ける可能性が低くなります これは ログ スイッチが発生したときに 必要なサイズのスタンバイ REDO ログ ファイルが使用できないためです 詳細は 項 スタンバイ REDO ログの構成 および 5.7 項 ログ ファイルの管理 を参照してください A.9 ロジカル スタンバイ データベースのトラブルシューティング この項は 次の項目で構成されています エラーのリカバリ SQL*Loader セッションのトラブルシューティング 長時間実行トランザクションのトラブルシューティング フラッシュバック トランザクションでの ORA-1403 エラーのトラブルシューティング A.9.1 エラーのリカバリ ロジカル スタンバイ データベースでは ユーザー表 順序およびジョブがメンテナンスされます 他のオブジェクトをメンテナンスするには REDO データ ストリームにある DDL 文を再発行する必要があリます SQL Apply に障害が発生した場合 エラーは DBA_LOGSTDBY_EVENTS 表に記録されます 次の各項では このようなエラーのリカバリ方法を説明します A ファイル仕様が含まれている DDL トランザクション DDL 文は プライマリ データベースとロジカル スタンバイ データベースでは同じ方法で実行されます 基礎となるファイル構造が両方のデータベースで同じ場合 DDL はスタンバイ データベース上で予想どおりに実行されます エラーの原因が ロジカル スタンバイ データベース環境に適合しないファイル仕様を含んだ DDL トランザクションにある場合は 次の手順を実行して問題を解決してください 1. ALTER SESSION DISABLE GUARD 文を使用してデータベース ガードをバイパスし ロジカル スタンバイ データベースへの変更を可能にします SQL> ALTER SESSION DISABLE GUARD; 2. 正しいファイル仕様を使用して DDL 文を実行し データベース ガードを再び使用可能にします 次に例を示します SQL> ALTER TABLESPACE t_table ADD DATAFILE '/dbs/t_db.f' SIZE 100M REUSE; SQL> ALTER SESSION ENABLE GUARD; 3. ロジカル スタンバイ データベースで SQL Apply を開始し 障害が発生したトランザクションをスキップします SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE 2> SKIP FAILED TRANSACTION; トランザクション障害の原因となった問題を修正し トランザクションをスキップせずに SQL Apply を再開できる場合があります たとえば 使用可能領域がすべて使用された場合などです (DDL トランザクションをスキップするときに プライマリおよびロジカル スタンバイ データベースの内容にずれを生じさせないようにしてください 可能な場合は スキップされたトランザクションのかわりに補足用トランザクションを手動で実行する必要があります ) Data Guard のトラブルシューティング A-11

328 ロジカル スタンバイ データベースのトラブルシューティング 次の例に SQL Apply の停止 エラーの修正および SQL Apply の再開を示します SQL> SET LONG 1000 SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS'; Session altered. SQL> SELECT EVENT_TIME, COMMIT_SCN, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS; EVENT_TIME COMMIT_SCN EVENT STATUS OCT-03 15:47:58 ORA-16111: ログのマイニングと設定の適用 22-OCT-03 15:48: insert into "SCOTT"."EMP" values "EMPNO" = 7900, "ENAME" = 'ADAMS', "JOB" = 'CLERK', "MGR" IS NULL, "HIREDATE" = TO_DATE('22-OCT-03', 'DD-MON-RR'), "SAL" = 950, "COMM" IS NULL, "DEPTNO" IS NULL ORA-01653: 表 SCOTT.EMP を拡張できません (%200 バイト分 表領域 T_TABLE) この例で ORA メッセージは 表領域がいっぱいで表を拡張できないことを示しています 問題を修正するには 新しいデータファイルを表領域に追加します 次に例を示します SQL> ALTER TABLESPACE t_table ADD DATAFILE '/dbs/t_db.f' SIZE 60M; Tablespace altered. 次に SQL Apply を再開します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered. SQL Apply を再開すると 障害が発生したトランザクションが再実行され ロジカル スタンバイ データベースに適用されます A DML 障害のリカバリ DML 障害のフィルタ処理には SKIP_TRANSACTION プロシージャを使用しないでください また スキップされたイベント表にある DML のみでなく トランザクションに関連しているすべての DML についても注意が必要です これが複数の表の原因となります DML 障害は通常 特定の表に関する問題を示しています たとえば 障害が即時に解決できない記憶域の不足に関するエラーであるとします 次の手順は この問題に応答する 1 つの方法を示しています 1. 表をスキップ リストに追加することによって トランザクションではなく 表をバイパスします SQL> EXECUTE DBMS_LOGSTDBY.SKIP('DML','SCOTT','EMP'); SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; A-12 Oracle Data Guard 概要および管理

329 ロジカル スタンバイ データベースのトラブルシューティング この時点から SCOTT.EMP 表に関する DML アクティビティは適用されません 表は 記憶域の問題を解決した後で修正できます ただし 表を修正するには DBMS_LOGSTDBY パッケージ内のプロシージャを実行するための管理者権限がある プライマリ データベースへのデータベース リンクを設定していることが必要です 2. プライマリ データベースへのデータベース リンクを使用して ローカルな SCOTT.EMP 表を削除し 表を再作成して データをスタンバイ データベースに転送します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE('SCOTT','EMP','PRIMARYDB'); SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 3. 新規にインスタンス化された表とデータベースの残りの部分にまたがってビューの一貫性が得られるように SQL Apply がプライマリ データベースと一致するまで待機した後で この表を問い合せます 詳細な例は 項 ロジカル スタンバイ データベースでの表の追加または再作成 を参照してください A.9.2 SQL*Loader セッションのトラブルシューティング Oracle SQL*Loader には 様々なソースから Oracle Database にデータをロードする方法が用意されています この項では SQL*Loader ユーティリティの一部の SQL Apply 関連機能について説明します 選択したデータ ロード方法に関係なく SQL*Loader 制御ファイルには APPEND および REPLACE キーワードを介して 新規データのロード先となる Oracle 表の現在の内容に対して実行する作業を示す指示が含まれています 次の例に これらのキーワードを LOAD_STOK という表に使用する方法を示します APPEND キーワードを使用すると 新規にロードされるデータは LOAD_STOK 表の内容に追加されます LOAD DATA INTO TABLE LOAD_STOK APPEND REPLACE キーワードを使用すると LOAD_STOK 表の内容が削除されてから新規のデータがロードされます SQL*Loader では DELETE 文を使用して表の内容が 1 つのトランザクションでパージされます LOAD DATA INTO TABLE LOAD_STOK REPLACE SQL*Loader スクリプトで REPLACE キーワードを使用するかわりに データをロードする前にプライマリ データベースの表に対して SQL*Plus の TRUNCATE TABLE コマンドを発行することをお薦めします これは プライマリ データベースとスタンバイ データベースの両方から高速かつ効率的な方法で表のコピーをパージするのと同じ効果があります これは TRUNCATE TABLE コマンドはオンライン REDO ログ ファイルに記録され ロジカル スタンバイ データベースで SQL Apply により発行されるためです SQL*Loader スクリプトに引き続き REPLACE キーワードを挿入することはできますが プライマリ データベースではオブジェクトからの 0( ゼロ ) 行の DELETE が試行されます プライマリ データベースから行が削除されていないため REDO ログ ファイルに REDO は記録されません したがって ロジカル スタンバイ データベースに対して DELETE 文は発行されません Data Guard のトラブルシューティング A-13

330 ロジカル スタンバイ データベースのトラブルシューティング DDL コマンド TRUNCATE TABLE を使用せずに REPLACE キーワードを発行すると トランザクションをロジカル スタンバイ データベースに適用する必要がある場合に SQL Apply に次のような問題が発生する可能性があります 現在 表に多数の行が含まれている場合は その行をスタンバイ データベースから削除する必要があります SQL Apply では文の元の構文を判別できないため プライマリ データベースからパージする行ごとに DELETE 文を発行する必要があります たとえば プライマリ データベースの表に最初は 10,000 行含まれていた場合 Oracle SQL*Loader は 1 つの DELETE 文を発行して 10,000 行をパージします スタンバイ データベースでは SQL Apply はすべての行がパージされることを認識しないかわりに 10,000 の DELETE 文を個別に発行し それぞれの文で 1 行ずつパージする必要があります スタンバイ データベースの表に SQL Apply で使用可能な索引が含まれていない場合 DELETE 文では情報をパージするために全表スキャンが発行されます 前述の例では SQL Apply は 10,000 の DELETE 文を個別に発行しているため スタンバイ データベースに対して 10,000 の全表スキャンが発行される可能性があります A.9.3 長時間実行トランザクションのトラブルシューティング SQL Apply 環境における長時間実行トランザクションの主な原因の 1 つは 全表スキャンです また 索引の作成時や再作成時のように DDL 操作がスタンバイ データベースに複製されるために 長時間実行トランザクションが発生することもあります 長時間実行トランザクションの識別 SQL Apply で 1 つの SQL 文が長時間実行されている場合は SQL Apply インスタンスのアラート ログに次のような警告メッセージがレポートされます Mon Feb 17 14:40: WARNING: the following transaction makes no progress WARNING: in the last 30 seconds for the given message! WARNING: xid = 0x b6 cscn = , message# = 28, slavid = 1 knacrb: no offending session found (not ITL pressure) この警告メッセージの注意事項は次のとおりです この警告は Interested Transaction List(ITL) が不十分な場合に戻される警告メッセージに似ていますが 最終行が knacrb で始まります この最終行は 次のことを示しています 全表スキャンが発生している可能性がある この発行では Interested Transaction List(ITL) が不十分な状態に対して何も実行されない この警告メッセージがレポートされるのは 1 つの文の実行時間が 30 秒を超える場合のみです 長時間実行文で実行されている SQL 文を判別できない場合がありますが 次の SQL 文を発行すると SQL Apply が作業中のデータベース オブジェクトを識別できます SQL> SELECT SAS.SERVER_ID 2, SS.OWNER 3, SS.OBJECT_NAME 4, SS.STATISTIC_NAME 5, SS.VALUE 6 FROM V$SEGMENT_STATISTICS SS 7, V$LOCK L 8, V$STREAMS_APPLY_SERVER SAS 9 WHERE SAS.SERVER_ID = &SLAVE_ID 10 AND L.SID = SAS.SID 11 AND L.TYPE = 'TM' 12 AND SS.OBJ# = L.ID1; A-14 Oracle Data Guard 概要および管理

331 ロジカル スタンバイ データベースのトラブルシューティング また 次の SQL 文を発行すると 実行ごとに多数のディスク読取りを発生させた SQL 文を識別できます SQL> SELECT SUBSTR(SQL_TEXT,1,40) 2, DISK_READS 3, EXECUTIONS 4, DISK_READS/EXECUTIONS 5, HASH_VALUE 6, ADDRESS 7 FROM V$SQLAREA 8 WHERE DISK_READS/GREATEST(EXECUTIONS,1) > 1 9 AND ROWNUM < ORDER BY DISK_READS/GREATEST(EXECUTIONS,1) DESC すべての表に主キー制約を定義することをお薦めします これにより自動的に列が NOT NULL として定義されます 主キー制約を定義できない表の場合は NOT NULL として定義されている適切な列に索引を定義する必要があります 表に適切な列が存在しない場合はその表を見直し 可能な場合は SQL Apply でスキップしてください SCOTT スキーマの FTS 表に対して発行された DML 文をすべてスキップする手順は 次のとおりです 1. SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered 2. SCOTT.FTS 表について すべての DML トランザクションのスキップ プロシージャを構成します SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', - schema_name => 'SCOTT', - object_name => 'FTS'); PL/SQL procedure successfully completed 3. SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered ITL が不十分な状態のトラブルシューティング Interested Transaction List(ITL) が不十分な状態は SQL Apply インスタンスのアラート ログでレポートされます 例 A-3 に 警告メッセージの例を示します 例 A-3 ITL が不十分な状態に関してレポートされる警告メッセージ Tue Apr 22 15:50: WARNING: the following transaction makes no progress WARNING: in the last 30 seconds for the given message! WARNING: xid = 0x fa cscn = , message# = 2, slavid = 17 Data Guard のトラブルシューティング A-15

332 ロジカル スタンバイ データベースのトラブルシューティング リアルタイム適用の分析例 A-3 のメッセージは SQL Apply プロセス (slavid)#17 が過去 30 秒にわたって進捗しなかったことを示しています 適用プロセスにより発行されている SQL 文を判別するには 次の問合せを発行します SQL> SELECT SA.SQL_TEXT 2 FROM V$SQLAREA SA 3, V$SESSION S 4, V$STREAMS_APPLY_SERVER SAS 5 WHERE SAS.SERVER_ID = &SLAVEID 6 AND S.SID = SAS.SID 7 AND SA.ADDRESS = S.SQL_ADDRESS SQL_TEXT insert into "APP"."LOAD_TAB_1" p("pk","text")values(:1,:2) ITL が不十分な状態を識別するには 次の例に示すように V$LOCK ビューを問い合せる方法もあります TX ロックの要求値が 4 のセッションは ITL が使用可能になるまで待機中です SQL> SELECT SID,TYPE,ID1,ID2,LMODE,REQUEST 2 FROM V$LOCK 3 WHERE TYPE = 'TX' SID TY ID1 ID2 LMODE REQUEST TX TX この例では SID 10 は SID 8 が保持している TX ロックを待機中です 障害後のレビューセグメントの ITL が不十分な状態が長時間続くことはまずありません また この状態の継続時間が 30 秒未満の場合 スタンバイ データベースのアラート ログではレポートされません したがって ITL が不十分な状態になっているオブジェクトを判別するには 次の文を発行します SQL> SELECT SEGMENT_OWNER, SEGMENT_NAME, SEGMENT_TYPE 2 FROM V$SEGMENT_STATISTICS 3 WHERE STATISTIC_NAME = 'ITL WAITS' 4 AND VALUE > 0 5 ORDER BY VALUE この文では インスタンスが前回起動された後に ITL が不十分な状態になったことのあるデータベース セグメントがすべてレポートされます 注意 : この SQL 文は Data Guard 環境のロジカル スタンバイ データベースに限定されません すべての Oracle データベースに適用可能です ITL が不十分な状態の解消特定のデータベース オブジェクトの INITRANS の整数を増やすには 最初に SQL Apply を停止する必要があります 関連項目 : INITRANS の整数を指定する方法の詳細は Oracle Database SQL リファレンス を参照してください これは データベース オブジェクトに割り当てられた各データ ブロック内で割り当てられる初期同時トランザクション エントリ数です A-16 Oracle Data Guard 概要および管理

333 ロジカル スタンバイ データベースのトラブルシューティング 次の例に app スキーマ内の表 load_tab_1 の INITRANS を増やすための手順を示します 1. SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered. 2. データベース ガードを一時的にバイパスします SQL> ALTER SESSION DISABLE GUARD; Session altered. 3. スタンバイ データベースで INITRANS を増やします 次に例を示します SQL> ALTER TABLE APP.LOAD_TAB_1 INITRANS 30; Table altered 4. データベース ガードを再び使用可能にします SQL> ALTER SESSION ENABLE GUARD; Session altered 5. SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered. また スイッチオーバー時に新しいスタンバイ データベースでエラーが発生しないように プライマリ データベースでデータベース オブジェクトを変更することを考慮してください A.9.4 フラッシュバック トランザクションでの ORA-1403 エラーのトラブルシューティング SQL Apply が ORA-1403: データが見つかりません エラーを戻す場合は フラッシュバック トランザクションを使用して欠落しているデータを再構成できる場合があります これは スタンバイ データベース インスタンスで指定されている UNDO_RETENTION 初期化パラメータに依存します 通常 ロジカル スタンバイ データベース環境で ORA-1403 エラーは表示されません このエラーが発生するのは SQL Apply の管理対象である表のデータがスタンバイ データベースで直接変更された後 同じデータがプライマリ データベースで変更された場合です 変更されたデータがプライマリ データベースで更新されてからロジカル スタンバイ データベースで受信されると SQL Apply はデータのオリジナル バージョンがスタンバイ データベースに存在することを確認してから レコードを更新します この確認に失敗すると ORA-1403: データが見つかりません エラーが戻されます 初期エラー SQL Apply が検証に失敗すると ロジカル スタンバイ データベースのアラート ログでエラー メッセージがレポートされ DBA_LOGSTDBY_EVENTS ビューにレコードが挿入されます アラート ログ内の情報は切り捨てられますが エラー全体がデータベース ビューでレポートされます 次に例を示します LOGSTDBY stmt: UPDATE "SCOTT"."MASTER" SET "NAME" = 'john' WHERE "PK" = 1 and "NAME" = 'andrew' and ROWID = 'AAAAAAAAEAAAAAPAAA' LOGSTDBY status: ORA-01403: データが見つかりません LOGSTDBY PID 1006, oracle@staco03 (P004) LOGSTDBY XID 0x e , Thread 1, RBA 0x02dd Data Guard のトラブルシューティング A-17

334 ロジカル スタンバイ データベースのトラブルシューティング 調査最初のステップは エラーの原因となった表の履歴データを分析することです そのためには SELECT 文の VERSIONS 句を使用します たとえば プライマリ データベースで次の問合せを発行できます SELECT VERSIONS_XID, VERSIONS_STARTSCN, VERSIONS_ENDSCN, VERSIONS_OPERATION, PK, NAME FROM SCOTT.MASTER VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE WHERE PK = 1 ORDER BY NVL(VERSIONS_STARTSCN,0); VERSIONS_XID VERSIONS_STARTSCN VERSIONS_ENDSCN V PK NAME EE I 1 andrew 02000D00E D 1 andrew データベースが保持するように構成されている UNDO 保存 (UNDO_RETENTION) の量と表に対するアクティビティによっては 戻される情報が広範囲にわたり その量を制限するために構文間でバージョンの変更が必要になる場合があります 戻された情報から レコードが最初に SCN で挿入され SCN でトランザクション ID 02000D00E の一部として削除されたことがわかります このトランザクション ID を使用してデータベースを問い合せ トランザクションの有効範囲を確認する必要があります そのためには FLASHBACK_TRANSACTION_QUERY ビューを問い合せます SELECT OPERATION, UNDO_SQL FROM FLASHBACK_TRANSACTION_QUERY WHERE XID = HEXTORAW('02000D00E '); OPERATION UNDO_SQL DELETE insert into "SCOTT"."MASTER"("PK","NAME") values ('1','andrew'); BEGIN トランザクションの開始を表す 1 行が必ず戻されることに注意してください このトランザクションでは マスター表から削除されたのは 1 行のみです 実行時の UNDO_SQL 列では 元のデータが表にリストアされます SQL> INSERT INTO "SCOTT"."MASTER"("PK","NAME") VALUES ('1','ANDREW'); SQL> COMMIT; SQL Apply を再開すると トランザクションがスタンバイ データベースに適用されます SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; A-18 Oracle Data Guard 概要および管理

335 B Data Guard 構成におけるデータベースのアップグレード この付録の手順では 構成にフィジカル スタンバイ データベースまたはロジカル スタンバイ データベースが存在する場合に Oracle Database 10g リリース 2(10.2) にアップグレードする方法を説明します この付録は 次の項目で構成されています Oracle Database ソフトウェアをアップグレードする前の注意事項 フィジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード ロジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード Data Guard 構成におけるデータベースのアップグレード B-1

336 Oracle Database ソフトウェアをアップグレードする前の注意事項 B.1 Oracle Database ソフトウェアをアップグレードする前の注意事項 Oracle Database ソフトウェアのアップグレードを開始する前に 次のことに注意してください 構成の管理に Data Guard Broker を使用している場合 ブローカ構成を削除または無効にする方法の詳細は Oracle Data Guard Broker の指示を参照してください この付録で説明する手順は Oracle Database アップグレード ガイド に記載されている手順とともに使用します この付録で説明する手順では データベース アップグレード アシスタント (DBUA) を使用してアップグレードを実行します アップグレードを手動で実行する手順は Oracle Database アップグレード ガイド を参照してください DBUA の使用を言及している場合にも 記載されている手動のアップグレード手順は実行する必要があります NOLOGGING 操作をチェックします NOLOGGING 操作が実行されていた場合は スタンバイ データベースを更新する必要があります 詳細は 項 NOLOGGING 句を指定した後のリカバリ を参照してください OFFLINE IMMEDIATE が原因でリカバリを必要とする表領域またはデータファイルを書き留めておきます アップグレード前に表領域またはデータファイルをリカバリし オンライン化またはオフライン化する必要があります B.2 フィジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード 構成にフィジカル スタンバイ データベースが存在する場合に Oracle Database 10g リリース 2(10.2) にアップグレードする手順は 次のとおりです 1. Oracle Database アップグレード ガイド の第 2 章 アップグレードの準備 に記載されている手順を確認して実行します 2. プライマリ システムとスタンバイ システムに Oracle ソフトウェア ディレクトリの所有者としてログインし 環境を既存の ( リリース 9.2 または 10.1) インストールに設定します 3. プライマリ データベースで すべてのユーザー アクティビティを停止します 4. Real Application Clusters を使用している場合は 1 つを除くすべてのプライマリ データベース インスタンスで SHUTDOWN NORMAL または SHUTDOWN IMMEDIATE 文を発行します SQL> SHUTDOWN IMMEDIATE; 次に 残りのアクティブなデータベース インスタンスで 現行のログ ファイルをアーカイブします 次に例を示します SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; これにより Real Application Clusters インスタンスから使用可能なアーカイブ REDO データが すべてスタンバイ データベースに転送されます 5. アクティブなプライマリ データベース インスタンスで 現行のログ スレッドと順序番号を識別し 記録します 次に 現行のログをアーカイブします SQL> SELECT THREAD#, SEQUENCE# FROM V$LOG WHERE STATUS='CURRENT'; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; B-2 Oracle Data Guard 概要および管理

337 フィジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード 6. NORMAL または IMMEDIATE の優先順位を指定して アクティブなプライマリ データベース インスタンスを停止します ORACLE_HOME に対して実行中のリスナー エージェントおよび他のプロセスをすべて停止します SQL> SHUTDOWN IMMEDIATE; % agentctl stop % lsnrctl stop 7. スタンバイ システムで Real Application Clusters を使用している場合は 1 つを除くすべてのスタンバイ データベース インスタンスを停止 (NORMAL または IMMEDIATE) します 残りのスタンバイ データベース インスタンスは この時点で管理リカバリ状態になります 8. REDO Apply を実行中のアクティブなスタンバイ インスタンスで V$LOG_HISTORY ビューを問い合せ 手順 5 でアーカイブした各ログ ファイルがスタンバイ データベースに受信され 適用されていることを確認します 次に例を示します SQL> SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY; 9. 最後のログが適用された後 REDO Apply を停止してスタンバイ データベースを停止し 現行 ( リリース 9.2 または 10.1) のデータベースに対して実行されているリスナーとエージェントをすべて停止します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> SHUTDOWN IMMEDIATE; % agentctl stop % lsnrctl stop 10. スタンバイ システムで Oracle Universal Installer を使用して Oracle Database 10g リリース 2(10.2) を固有の Oracle ホームにインストールします 詳細は Oracle Database アップグレード ガイド を参照してください エラーなしで確実にアップグレードされるように Companion CD もインストールすることをお薦めします 他のアップグレード手順は実行しないでください 11. サーバー パラメータ ファイル (SPFILE) パスワード ファイルおよび必要なネットワーク ファイルを 古い ( リリース 9.2 または 10.1 の )ORACLE_HOME ディレクトリから新しいリリース 10.2 の ORACLE_HOME ディレクトリにコピーします スタンバイ データベースがプライマリ データベースから REDO を受信するには スタンバイ データベースの REMOTE_LOGIN_EXCLUSIVE 初期化パラメータが SHARED または EXCLUSIVE に設定され パスワード ファイルが存在し スタンバイ データベースの SYS パスワードがプライマリ データベースの SYS パスワードと一致する必要があります 12. プライマリ システムで Oracle Universal Installer を使用して Oracle Database 10g リリース 2(10.2) を固有の Oracle ホームにインストールします 詳細は Oracle Database アップグレード ガイド を参照してください エラーなしで確実にアップグレードされるように Companion CD もインストールすることをお薦めします 13. リリース 10.2 の Oracle_Home にある TNSNAMES.ORA ファイルに Oracle Net サービス名を挿入します 14. リリース 10.2 のインストール後も 環境はまだ古い (9.2 または 10.1 の ) インストールに設定されています 次のように プライマリ データベースを UPGRADE モードで起動します SQL> STARTUP UPGRADE; 15. リリース 10.2 の Oracle_Home からデータベース アップグレード アシスタントを起動し プライマリ データベースをアップグレードします % cd /u01/app/oracle/product/10.2/bin %./dbua Data Guard 構成におけるデータベースのアップグレード B-3

338 フィジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード 注意 : 古い ( リリース 9.2 または 10.1 の ) データベースがデータベース アップグレード アシスタントで表示されるには oratab ファイルに含まれている必要があります DBUA の使用方法の詳細は Oracle Database アップグレード ガイド を参照してください 注意 : プライマリ データベースのアラート ログに プライマリ データベースがスタンバイ データベースに接続できないことを示すエラーが記録される場合があります このエラーは無視できます この時点まではスタンバイ データベースが再起動されていないため このエラーは予期されたものです 16. プライマリ データベースでアップグレード処理が開始された後 新しい Oracle Database 10g リリース 2(10.2) ソフトウェアを実行中のスタンバイ データベースで スタンバイ リスナーを起動します 17. 環境が新規のリリース 10.2 ソフトウェア インストールに設定された状態で スタンバイ データベースで STARTUP NOMOUNT 文を発行します スタンバイ データベースで STANDBY_FILE_MANAGEMENT 初期化パラメータが AUTO に設定されていることと FAL_ SERVER および FAL_CLIENT が適切に構成されていることを確認します FAL_SERVER は スタンバイ データベースの TNSNAMES.ORA ファイルに存在する Oracle Net サービス名に設定する必要があります FAL_CLIENT に設定する Oracle Net サービス名は プライマリ データベースの TNSNAMES.ORA ファイルに存在し かつスタンバイ データベース リスナーを指す必要があります Oracle Net サービス名は 新しいリリース 10.2 の Oracle_Home 内で解決できる必要があります 次に例を示します SQL> STARTUP NOMOUNT SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO SCOPE=BOTH; SQL> ALTER SYSTEM SET FAL_SERVER=MTS SCOPE=BOTH; SQL> ALTER SYSTEM SET FAL_CLIENT=MTS_PHY SCOPE=BOTH; 18. スタンバイ データベースをマウントして REDO Apply を開始します SQL> ALTER DATABASE MOUNT STANDBY DATABASE; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; 19. データベース アップグレード アシスタントが完了した後 プライマリ システムで環境を新しいリリース 10.2 の Oracle_Home に設定し プライマリ データベースに接続します 現行のログのスレッドと順序番号を識別して記録します 次に 現行のログをアーカイブします SQL> SELECT THREAD#, SEQUENCE# FROM V$LOG WHERE STATUS='CURRENT'; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 20. スタンバイ インスタンスで V$LOG_HISTORY ビューを問い合せ 手順 19 でアーカイブした各ログ ファイルがスタンバイ データベースで受信され 適用されていることを確認します SQL> SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY; B-4 Oracle Data Guard 概要および管理

339 ロジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード B.3 ロジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード 構成にロジカル スタンバイ データベースが存在する場合に Oracle Database 10g リリース 2(10.2) にアップグレードする手順は 次のとおりです 1. Oracle Database アップグレード ガイド の第 2 章 アップグレードの準備 に記載されている手順を確認して実行します 2. プライマリ システムとスタンバイ システムに Oracle ソフトウェア ディレクトリの所有者としてログインし 環境を既存の ( リリース 9.2 または 10.1) インストールに設定します 3. プライマリ システムで プライマリ データベースにおけるすべてのユーザー アクティビティを停止します 4. Real Application Clusters を使用している場合は 1 つを除くすべてのプライマリ データベース インスタンスで SHUTDOWN NORMAL または SHUTDOWN IMMEDIATE 文を発行します SQL> SHUTDOWN IMMEDIATE; 次に 残りのアクティブなデータベース インスタンスで 現行のログ ファイルをアーカイブします SQL> SHUTDOWN IMMEDIATE; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; これにより Real Application Clusters インスタンスから使用可能なアーカイブ REDO データが すべてスタンバイ データベースに転送されます 5. アクティブなプライマリ データベース インスタンスで 現行のログ スレッドと順序番号を識別し 記録します 次に 現行のログをアーカイブします SQL> SELECT THREAD#, SEQUENCE# FROM V$LOG WHERE STATUS='CURRENT'; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 6. スタンバイ システムで Real Application Clusters を使用している場合は 1 つを除くすべてのスタンバイ インスタンスで SHUTDOWN NORMAL または SHUTDOWN IMMEDIATE 文を発行します 7. アクティブなスタンバイ インスタンスで DBA_LOGSTDBY_LOG ビューを問い合せ 手順 5 でアーカイブした各ログ ファイルがスタンバイ データベースで受信されたことを確認します たとえば スレッド番号 1 および順序番号 12 に関連付けられているログ ファイルがロジカル スタンバイ データベースで受信されたことを確認するには アーカイブ REDO ログ ファイル名が戻されるまで 次の問合せをスタンバイ データベースで繰返し実行できます SQL> SELECT FILE_NAME FROM DBA_LOGSTDBY_LOG WHERE THREAD#=1 AND SEQUENCE#=12 8. スタンバイ データベースで DBA_LOGSTDBY_PROGRESS ビューを問い合せ 残りの REDO ログ ファイルがすべて適用されたことを確認します 次に例を示します SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS; APPLIED_SCN および NEWEST_SCN 列の番号が同一の場合は スタンバイ データベースが受信した REDO ログ ファイル内で使用可能なデータがすべて適用されています 9. スタンバイ データベースで SQL Apply を停止します SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Data Guard 構成におけるデータベースのアップグレード B-5

340 ロジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード 10. NORMAL または IMMEDIATE の優先順位を指定して アクティブなスタンバイ データベース インスタンスをすべて停止します Oracle ホームに対して実行中のリスナー エージェントおよび他のプロセスをすべて停止します SQL> SHUTDOWN IMMEDIATE; % agentctl stop % lsnrctl stop 11. NORMAL または IMMEDIATE の優先順位を指定して プライマリ データベース インスタンスを停止します Oracle ホームに対して実行中のリスナー エージェントおよび他のプロセスをすべて停止します SQL> SHUTDOWN IMMEDIATE; % agentctl stop % lsnrctl stop 12. プライマリ システムで Oracle Universal Installer を使用して Oracle Database 10g リリース 2(10.2) を固有の Oracle ホームにインストールします 詳細は Oracle Database アップグレード ガイド を参照してください エラーなしで確実にアップグレードされるように Companion CD もインストールすることをお薦めします 他のアップグレード手順は実行しないでください 13. Oracle Database 10g リリース 2(10.2) のインストール後も 環境はまだ古い ( リリース 9.2 または 10.1 の ) インストールに設定されています 次のように プライマリ データベースを UPGRADE モードで起動します SQL> STARTUP UPGRADE; SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=BOTH; 14. リリース 10.2 の ORACLE_HOME からデータベース アップグレード アシスタントを起動して プライマリ データベースをアップグレードします 次に例を示します % cd /u01/app/oracle/product/10.2/bin %./dbua 注意 : 古い (9.2 または 10.1 の ) データベースがデータベース アップグレード アシスタントで表示されるには oratab ファイルに含まれている必要があります DBUA の使用方法の詳細は Oracle Database アップグレード ガイド を参照してください 15. データベースのアップグレード後に 新しい Oracle Database 10g リリース 2(10.2) インストールを指すように環境を変更して プライマリ データベース インスタンスを停止し エージェントとリスナーを再起動します SQL> SHUTDOWN IMMEDIATE; % agentctl start % lsnrctl start 16. プライマリ データベース インスタンスを起動し ユーザーまたはアプリケーションが DML または DDL 操作を実行する可能性を低下させるために制限付きセッションを使用可能にします SQL> STARTUP MOUNT; SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION; 注意 : 手順 18 で制限付きセッション モードを使用不可にするまでは DML 操作または DDL 操作の発生を許可しないでください 17. プライマリ データベースをオープンして LogMiner ディクショナリを作成します SQL> ALTER DATABASE OPEN; SQL> EXECUTE DBMS_LOGSTDBY.BUILD; B-6 Oracle Data Guard 概要および管理

341 ロジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード 18. プライマリ データベースで制限付きセッション モードを使用不可にして 現行のログ ファイルをアーカイブします SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 19. プライマリ データベース インスタンスで次の問合せを発行して 最新の LogMiner ディクショナリ作成ログ ファイルを判別します SQL> SELECT NAME FROM V$ARCHIVED_LOG 2> WHERE (SEQUENCE#=(SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG 3> WHERE DICTIONARY_BEGIN = 'YES' AND STANDBY_DEST= 'NO')); 後で参照できるように この問合せで戻されたログ ファイル名を記録します 20. スタンバイ システムで Oracle Universal Installer を使用して Oracle Database 10g リリース 2(10.2) を固有の Oracle ホームにインストールします 詳細は Oracle Database アップグレード ガイド を参照してください エラーなしで確実にアップグレードされるように Companion CD もインストールすることをお薦めします 他のアップグレード手順は実行しないでください 21. Oracle Database 10g リリース 2(10.2) のインストール後も 環境はまだ古い (9.2 または 10.1 の ) インストールに設定されています 次のように ロジカル スタンバイ データベースを UPGRADE モードで起動し アクティブ化して リモート アーカイブを遅延させます SQL> STARTUP UPGRADE; SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE; SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=BOTH; 注意 : 変更はプライマリ データベースに伝播しないため ユーザーにはアクティブ化したスタンバイ データベースの更新を許可しないでください 22. リリース 10.2 の Oracle_Home ディレクトリから データベース アップグレード アシスタント (DBUA) を起動して ロジカル スタンバイ データベースをアップグレードします % cd /u01/app/oracle/product/10.2/bin %./dbua 23. ロジカル スタンバイ データベースのアップグレード後に インスタンスを停止してエージェントとリスナーを再起動します SQL> SHUTDOWN IMMEDIATE; % agentctl start % lsnrctl start 24. プライマリ システムから 最新の LogMiner ディクショナリ作成ログ ファイル ( 手順 19 で識別済 ) をスタンバイ システムにコピーします 25. ロジカル スタンバイ データベース インスタンスを起動し ユーザーがロジカル スタンバイ データベースのオブジェクトを更新しないようにデータベース ガードを有効にします SQL> STARTUP MOUNT; SQL> ALTER DATABASE GUARD ALL; SQL> ALTER DATABASE OPEN; 26. コピーしたログ ファイルをロジカル スタンバイ データベースに登録します 次に例を示します SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE 2> '/database/lgstby/arch/arc1_48.arc'; Data Guard 構成におけるデータベースのアップグレード B-7

342 ロジカル スタンバイ データベースが存在する場合の Oracle Database のアップグレード 27. ロジカル スタンバイ データベースで SQL Apply を開始します SQL> ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL; 注意 : 前述のコマンドは 最初は失敗して次のエラーが戻されます ORA-16101: 有効な開始 SCN が見つかりませんでした このエラーを解決するには 手順 26 の説明に従って論理ログ ファイルを登録し SQL Apply を開始する文を再発行します 28. Real Application Clusters を使用している場合は 他のスタンバイ データベース インスタンスを起動します 29. プライマリ システムで アップグレードしたロジカル スタンバイ データベースへのアーカイブを使用可能にします SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE; 30. Real Application Clusters を使用している場合は 他のプライマリ データベース インスタンスを起動します B-8 Oracle Data Guard 概要および管理

343 C ロジカル スタンバイ データベースでサポートされるデータ型および DDL ロジカル スタンバイ データベースを設定する際 ロジカル スタンバイ データベースが プライマリ データベースのデータ型と表をメンテナンスできることを確認する必要があります この付録では 様々なデータベース オブジェクト 記憶域および PL/SQL パッケージについて ロジカル スタンバイ データベースでサポートされるものとサポートされないものを示します この章は 次の項目で構成されています データ型に関する考慮事項 記憶域型に関する考慮事項 PL/SQL パッケージに関する考慮事項 サポートされない表 順序およびビュー ロジカル スタンバイ データベースでスキップされる SQL 文 ロジカル スタンバイ データベースでサポートされる DDL 文 ロジカル スタンバイ データベースでサポートされるデータ型および DDL C-1

344 データ型に関する考慮事項 C.1 データ型に関する考慮事項 次の各項では データベース オブジェクトについて サポートされるものとサポートされないものを示します ロジカル スタンバイ データベースでサポートされるデータ型 ロジカル スタンバイ データベースでサポートされないデータ型 C.1.1 ロジカル スタンバイ データベースでサポートされるデータ型 ロジカル スタンバイ データベースでは 次のデータ型がサポートされます CHAR NCHAR VARCHAR2 および VARCHAR NVARCHAR2 NUMBER DATE TIMESTAMP TIMESTAMP WITH TIMEZONE TIMESTAMP WITH LOCAL TIMEZONE INTERVAL YEAR TO MONTH INTERVAL DAY TO SECOND RAW CLOB および NCLOB BLOB LONG LONG RAW BINARY_FLOAT BINARY_DOUBLE C.1.2 ロジカル スタンバイ データベースでサポートされないデータ型 ロジカル スタンバイ データベースでは 次のデータ型がサポートされません BFILE ROWID UROWID ユーザー定義型コレクション (VARRAYS およびネストした表を含む ) XML 型暗号化された列マルチメディア データ型 (Spatial Image および Context を含む ) C-2 Oracle Data Guard 概要および管理

345 PL/SQL パッケージに関する考慮事項 C.2 記憶域型に関する考慮事項 次の各項では 記憶域型について サポートされるものとサポートされないものを示します サポートされる記憶域型 サポートされない記憶域型 C.2.1 サポートされる記憶域型 ロジカル スタンバイ データベースでは 次の記憶域型がサポートされます ヒープ構成表 ( パーティション化および非パーティション化 ) 索引構成表 ( オーバーフロー セグメントを含むパーティション化および非パーティション化 ) クラスタ表 ( 索引クラスタおよびヒープ クラスタを含む ) C.2.2 サポートされない記憶域型 ロジカル スタンバイ データベースでは セグメント圧縮記憶域型はサポートされません C.3 PL/SQL パッケージに関する考慮事項 次の各項では PL/SQL パッケージについて サポートされるものとサポートされないものを示します サポートされる PL/SQL パッケージ サポートされない PL/SQL パッケージ 関連項目 : オラクル社が提供する PL/SQL パッケージの詳細は Oracle Database PL/SQL パッケージ プロシージャおよびタイプ リファレンス を参照してください C.3.1 サポートされる PL/SQL パッケージ システムのメタデータやユーザー データを変更しない オラクル社が提供する PL/SQL パッケージは アーカイブ REDO ログ ファイルにフットプリントを残さないため プライマリ データベースで安全に使用できます この種のパッケージの例には DBMS_OUTPUT DBMS_ RANDOM DBMS_PIPE DBMS_DESCRIBE DBMS_OBFUSCATION_TOOLKIT DBMS_TRACE DBMS_METADATA があります システムのメタデータは変更しませんが ユーザー データを変更する場合がある オラクル社が提供する PL/SQL パッケージは 変更されるデータが C.1.1 項に記載のサポートされるデータ型に属するかぎり SQL Apply でサポートされます この種のパッケージの例には DBMS_LOB DBMS_SQL DBMS_TRANSACTION があります C.3.2 サポートされない PL/SQL パッケージ システムのメタデータを変更する オラクル社が提供する PL/SQL パッケージは 通常 SQL Apply ではサポートされないため その影響はロジカル スタンバイ データベースでは参照できません この種のパッケージの例には DBMS_JAVA DBMS_REGISTRY DBMS_ALERT DBMS_SPACE_ADMIN DBMS_REFRESH DBMS_REDEFINITION DBMS_SCHEDULER DBMS_ AQ があります DBMS_JOB に対する特定のサポートが用意されています ジョブの実行はロジカル スタンバイ データベース上で一時停止され スタンバイ データベース上ではジョブを直接スケジュールできません ただし プライマリ データベースで発行されたジョブは スタンバイ データベースにレプリケートされます スイッチオーバーまたはフェイルオーバーが発生すると 元のプライマリ データベースでスケジュールされていたジョブの実行は 新規のプライマリ データベースで自動的に開始されます ロジカル スタンバイ データベースでサポートされるデータ型および DDL C-3

346 サポートされない表 順序およびビュー C.4 サポートされない表 順序およびビュー ロジカル スタンバイ データベースを作成する前に プライマリ データベースでサポートされないデータベース オブジェクトを識別することが重要です その理由は プライマリ データベースでのサポートされないデータ型 表 順序またはビューに対する変更は ロジカル スタンバイ データベースに伝播されないためです さらに エラー メッセージは戻されません Oracle Database に付属するほとんどのスキーマ (SQL Apply でスキップされる ) スキップされるスキーマを正確に判断するには DBA_LOGSTDBY_SKIP ビューを問い合せます SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT = 'INTERNAL SCHEMA'; サポートされないデータ型を使用した表 表圧縮を使用した表 暗号化された列を使用した表 プライマリ データベースにサポートされないオブジェクトが含まれているかどうかを判断するには DBA_LOGSTDBY_UNSUPPORTED ビューを問い合せます 詳細は 第 16 章 Oracle Data Guard に関連するビュー を参照してください たとえば ロジカル スタンバイ データベースでサポートされないプライマリ データベース表のスキーマと表名をリストするには プライマリ データベースで次の問合せを使用します SQL> SELECT DISTINCT OWNER,TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED 2> ORDER BY OWNER,TABLE_NAME; OWNER TABLE_NAME HR COUNTRIES OE ORDERS OE CUSTOMERS OE WAREHOUSES 前述の問合せでリストされたいずれかの表の列名とデータ型を表示するには 次のような SELECT 文を使用します SQL> SELECT COLUMN_NAME,DATA_TYPE FROM DBA_LOGSTDBY_UNSUPPORTED 2> WHERE OWNER='OE' AND TABLE_NAME = 'CUSTOMERS'; COLUMN_NAME DATA_TYPE CUST_ADDRESS CUST_ADDRESS_TYP PHONE_NUMBERS PHONE_LIST_TYP CUST_GEO_LOCATION SDO_GEOMETRY プライマリ データベースにサポートされない表が含まれている場合 REDO データをロジカル スタンバイ データベースに適用すると SQL Apply サービスによって その表が自動的に除外されます 注意 : プライマリ データベースの重要な表がロジカル スタンバイ データベースでサポートされない場合は フィジカル スタンバイ データベースの使用を考慮することもできます C-4 Oracle Data Guard 概要および管理

347 ロジカル スタンバイ データベースでサポートされる DDL 文 C.5 ロジカル スタンバイ データベースでスキップされる SQL 文 デフォルトでは SQL 文がプライマリ データベースで実行された場合 次のリスト内の SQL 文以外はすべて ロジカル スタンバイ データベースに適用されます ALTER DATABASE ALTER SESSION ALTER MATERIALIZED VIEW ALTER MATERIALIZED VIEW LOG ALTER SYSTEM CREATE CONTROL FILE CREATE DATABASE CREATE DATABASE LINK CREATE PFILE FROM SPFILE CREATE SCHEMA AUTHORIZATION CREATE MATERIALIZED VIEW CREATE MATERIALIZED VIEW LOG CREATE SPFILE FROM PFILE DROP DATABASE LINK DROP MATERIALIZED VIEW DROP MATERIALIZED VIEW LOG EXPLAIN LOCK TABLE SET CONSTRAINTS SET ROLE SET TRANSACTION C.6 ロジカル スタンバイ データベースでサポートされる DDL 文 次の表に DBMS_LOGSTDBY.SKIP プロシージャ および SQL DDL 文スキップ用の文のオプションの stmt パラメータについて サポートされる値を示します 表 C-1 DBMS_LOGSTDBY.SKIP プロシージャの stmt パラメータの値 表 C-2 SQL DDL 文スキップ用の文のオプション 関連項目 : DBMS_LOGSTDBY パッケージの詳細は Oracle Database PL/SQL パッケージ プロシージャおよびタイプ リファレンス を また 項 DDL 文のスキップ ハンドラの設定 も参照してください 表 C-1 に DBMS_LOGSTDBY.SKIP プロシージャの stmt パラメータについて サポートされる値を示します 表の左側の列には キーワードの右側にある SQL 文セットの識別に使用される可能性のあるキーワードを示します また 右側の列の SQL 文はすべて有効な値です キーワードは 通常 データベース オブジェクトによって定義されます 表 C-1 DBMS_LOGSTDBY.SKIP プロシージャの stmt パラメータの値 キーワード NON_SCHEMA_DDL SCHEMA_DDL DML CLUSTER 関連する SQL 文 特定のスキーマに関連付けられていないすべての DDL スキーマ オブジェクト ( 例 : 表 索引 列 ) の作成 変更または削除を行うすべての DDL 文 表内の DML 文を含む ( 例 : INSERT UPDATE DELETE) CREATE CLUSTER AUDIT CLUSTER DROP CLUSTER TRUNCATE CLUSTER ロジカル スタンバイ データベースでサポートされるデータ型および DDL C-5

348 ロジカル スタンバイ データベースでサポートされる DDL 文 表 C-1 DBMS_LOGSTDBY.SKIP プロシージャの stmt パラメータの値 ( 続き ) キーワード CONTEXT DATABASE LINK DIMENSION DIRECTORY INDEX PROCEDURE 1 PROFILE PUBLIC DATABASE LINK PUBLIC SYNONYM ROLE ROLLBACK STATEMENT SEQUENCE SESSION SYNONYM SYSTEM AUDIT SYSTEM GRANT TABLE TABLESPACE 関連する SQL 文 CREATE CONTEXT DROP CONTEXT CREATE DATABASE LINK DROP DATABASE LINK CREATE DIMENSION ALTER DIMENSION DROP DIMENSION CREATE DIRECTORY DROP DIRECTORY CREATE INDEX ALTER INDEX DROP INDEX CREATE FUNCTION CREATE LIBRARY CREATE PACKAGE CREATE PACKAGE BODY CREATE PROCEDURE DROP FUNCTION DROP LIBRARY DROP PACKAGE DROP PROCEDURE CREATE PROFILE ALTER PROFILE DROP PROFILE CREATE PUBLIC DATABASE LINK DROP PUBLIC DATABASE LINK CREATE PUBLIC SYNONYM DROP PUBLIC SYNONYM CREATE ROLE ALTER ROLE DROP ROLE SET ROLE CREATE ROLLBACK SEGMENT ALTER ROLLBACK SEGMENT DROP ROLLBACK SEGMENT CREATE SEQUENCE DROP SEQUENCE Log-ons CREATE SYNONYM DROP SYNONYM AUDIT SQL_statements NOAUDIT SQL_statements GRANT system_privileges_and_roles REVOKE system_privileges_and_roles CREATE TABLE DROP TABLE TRUNCATE TABLE CREATE TABLESPACE DROP TABLESPACE TRUNCATE TABLESPACE C-6 Oracle Data Guard 概要および管理

349 ロジカル スタンバイ データベースでサポートされる DDL 文 表 C-1 DBMS_LOGSTDBY.SKIP プロシージャの stmt パラメータの値 ( 続き ) キーワード TRIGGER TYPE USER VIEW 関連する SQL 文 CREATE TRIGGER ENABLE および DISABLE 句を使用した ALTER TRIGGER DROP TRIGGER ENABLE ALL TRIGGERS 句を使用した ALTER TABLE DISABLE ALL TRIGGERS 句を使用した ALTER TABLE CREATE TYPE CREATE TYPE BODY ALTER TYPE DROP TYPE DROP TYPE BODY CREATE USER ALTER USER DROP USER CREATE VIEW DROP VIEW 1 Java スキーマ オブジェクト ( ソース クラス リソース ) は SQL 文をスキップ ( 無視 ) するためのプロシージャと同等とみなされます 表 C-2 に SQL DDL 文スキップ用の文のオプションを示します 表 C-2 SQL DDL 文スキップ用の文のオプション 文のオプション ALTER SEQUENCE ALTER TABLE COMMENT TABLE DELETE TABLE EXECUTE PROCEDURE GRANT DIRECTORY GRANT PROCEDURE GRANT SEQUENCE GRANT TABLE GRANT TYPE INSERT TABLE LOCK TABLE SELECT SEQUENCE SQL 文および操作 ALTER SEQUENCE ALTER TABLE COMMENT ON TABLE table, view, materialized view COMMENT ON COLUMN table.column, view.column, materialized_view.column DELETE FROM table, view CALL パッケージ内のすべての変数 ライブラリまたはカーソルに対するすべてのプロシージャ 機能またはアクセスの実行 GRANT privilege ON directory REVOKE privilege ON directory GRANT privilege ON procedure, function, package REVOKE privilege ON procedure, function, package GRANT privilege ON sequence REVOKE privilege ON sequence GRANT privilege ON table, view, materialized view REVOKE privilege ON table, view, materialized view GRANT privilege ON TYPE REVOKE privilege ON TYPE INSERT INTO table, view LOCK TABLE table, view sequence.currval を含むすべての文 ロジカル スタンバイ データベースでサポートされるデータ型および DDL C-7

350 ロジカル スタンバイ データベースでサポートされる DDL 文 表 C-2 SQL DDL 文スキップ用の文のオプション ( 続き ) 文のオプション SQL 文および操作 SELECT TABLE SELECT FROM table, view, materialized view REVOKE privilege ON table, view, materialized view UPDATE TABLE UPDATE table, view C-8 Oracle Data Guard 概要および管理

351 D Data Guard および Real Application Clusters Oracle Data Guard 構成は 単一インスタンスおよび複数インスタンスの RAC データベースの組合せで構成されます この章では Oracle Data Guard を Oracle Real Application Clusters データベースとともに使用する場合に適用される構成要件と考慮事項の概要を説明します 次の項目で構成されています Real Application Clusters 環境でのスタンバイ データベースの構成 Real Application Clusters 環境での構成に関する考慮事項 トラブルシューティング Data Guard および Real Application Clusters D-1

352 Real Application Clusters 環境でのスタンバイ データベースの構成 D.1 Real Application Clusters 環境でのスタンバイ データベースの構成 スタンバイ データベースを構成すると Real Application Clusters を使用しているプライマリ データベースを保護できます 次の表では プライマリ データベースとスタンバイ データベースのインスタンスの可能な組合せについて説明します 複数インスタンス スタンバイ データベース可可 インスタンスの組合せ単一インスタンス プライマリ データベース複数インスタンス プライマリ データベース 単一インスタンス スタンバイ データベース可可 それぞれの組合せでは プライマリ データベースの各インスタンスが REDO データをスタンバイ データベースのインスタンスへ転送します D.1.1 複数インスタンス プライマリ データベースと単一インスタンス スタンバイ データベースの設定 図 D-1 では プライマリ データベース インスタンスが 2 つある Real Application Clusters データベース ( 複数インスタンス プライマリ データベース ) が 単一インスタンス スタンバイ データベースへ REDO データを転送しています 図 D-1 複数インスタンス プライマリ データベースからの REDO データの転送 この場合は プライマリ データベースのインスタンス 1 がローカル アーカイブ REDO ログ ファイル に REDO データをアーカイブし スタンバイ データベース宛先に REDO データを転送するのに対し インスタンス 2 がローカル アーカイブ REDO ログ ファイル に REDO データをアーカイブし 同じスタンバイ データベース宛先に REDO データを転送します スタンバイ データベースでは アーカイブ REDO ログ ファイルを適用する正しい順序が自動的に判断されます D-2 Oracle Data Guard 概要および管理

353 Real Application Clusters 環境でのスタンバイ データベースの構成 Real Application Clusters 環境でプライマリ データベースを設定する手順各プライマリ インスタンスを構成するには 第 3 章 ( フィジカル スタンバイ データベース作成の場合 ) または第 4 章 ( ロジカル スタンバイ データベース作成の場合 ) の説明に従ってください 単一インスタンス スタンバイ データベースを設定する手順 STANDBY_ARCHIVE_DEST パラメータおよび LOG_ARCHIVE_FORMAT パラメータを定義して アーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイルの場所を指定するには 第 3 章 ( フィジカル スタンバイ データベース作成の場合 ) または第 4 章 ( ロジカル スタンバイ データベース作成の場合 ) の説明に従ってください D.1.2 複数インスタンス プライマリ データベースと複数インスタンス スタンバイ データベースの設定 図 D-2 に Real Application Clusters 環境のプライマリおよびスタンバイ データベースの構成を示します これによって スタンバイ データベースで REDO 転送サービスの処理とログ適用サービスの処理を分離できるため プライマリとスタンバイの両方で データベース全体のパフォーマンスが向上します 図 D-2 Real Application Clusters のスタンバイ データベース 図 D-2 で 丸で囲まれた数字はローカル接続を示し 四角で囲まれた数字はリモート接続を示します Real Application Clusters 環境では スタンバイ インスタンスは REDO データをプライマリ データベースから受信できます これは受信インスタンス受信インスタンスと呼ばれます ただし アーカイブ REDO ログ ファイルは 最終的には リカバリ インスタンスリカバリ インスタンスからアクセスが可能なディスク デバイスに存在する必要があります スタンバイ データベースのアーカイブ REDO ログ ファイルの 受信インスタンスからリカバリ インスタンスへの転送は インスタンス間アーカイブ操作を使用して実現されます Data Guard および Real Application Clusters D-3

354 Real Application Clusters 環境でのスタンバイ データベースの構成 スタンバイ データベースのインスタンス間アーカイブ操作のためには スタンバイ REDO ログ ファイルを プライマリ データベースのアーカイブ REDO ログ ファイルの一時リポジトリとして使用する必要があります スタンバイ REDO ログ ファイルを使用することにより スタンバイ データベースのパフォーマンスと信頼性が向上するだけでなく クラスタ ファイル システムを持っていないクラスタで インスタンス間アーカイブ操作の実行が可能になります ただし インスタンス間アーカイブ操作を行うためにはスタンバイ REDO ログ ファイルが必要なため プライマリ データベースは ログ ライター プロセス (LGWR) またはアーカイバ プロセス (ARCn) を使用して プライマリ データベースでアーカイブ操作を実行する必要があります プライマリ データベースとスタンバイ データベースの両方が Real Application Clusters 構成の場合 スタンバイ データベースの単一のインスタンスが プライマリ インスタンスによって転送されるログ ファイルのすべてのセットを適用します この場合 REDO データを適用しないスタンバイ インスタンスを REDO Apply の進行時に読取り専用モードにすることはできません Real Application Clusters 環境でスタンバイ データベースを設定する手順スタンバイ データベースで REDO 転送サービスを設定するには 次の手順を実行します 1. スタンバイ REDO ログ ファイルを作成します Real Application Clusters 環境では スタンバイ REDO ログ ファイルは すべてのインスタンスに共有されるディスク デバイスに存在する必要があります 詳細は 項を参照してください 2. リカバリ インスタンスで ローカルでアーカイブするように LOG_ARCHIVE_DEST_1 初期化パラメータの LOCATION 属性を定義します これは インスタンス間アーカイブが不要なためです 3. 受信インスタンスで リカバリ インスタンスにアーカイブするように LOG_ARCHIVE_ DEST_1 初期化パラメータの SERVICE 属性を定義します 4. リカバリ インスタンスでログ適用サービスを開始します Real Application Clusters 環境でプライマリ データベースを設定する手順プライマリ データベースで REDO 転送サービスを設定するには 次の手順を実行します 1. すべてのインスタンスで LOG_ARCHIVE_DEST_n パラメータに LGWR 属性を定義して LGWR プロセスがアーカイブ操作を実行するように指定します 2. LOG_ARCHIVE_DEST_n パラメータを適切な値に設定することで 受信インスタンスに REDO データを送信するように各スタンバイ インスタンスを構成します 各プライマリ データベース インスタンスが 対応するスタンバイ データベース インスタンスにアーカイブできれば理想的です ただし これは必須ではありません D-4 Oracle Data Guard 概要および管理

355 Real Application Clusters 環境での構成に関する考慮事項 D.2 Real Application Clusters 環境での構成に関する考慮事項 この項では Real Application Clusters 環境に固有の Data Guard 構成情報を提供します この章は 次の項目で構成されています アーカイブ REDO ログ ファイル名の形式 アーカイブ先の割当て制限 データ保護モード ロールの推移 D.2.1 アーカイブ REDO ログ ファイル名の形式 アーカイブ REDO ログ ファイル名は log_%parameter の形式になります %parameter には 表 D-1 のパラメータを 1 つ以上含めることができます 表 D-1 LOG_ARCHIVE_FORMAT 初期化パラメータのディレクティブ ディレクティブ 説明 %a データベース アクティブ ID %A 0( ゼロ ) を埋め込んだデータベース アクティブ ID %d データベース ID %D 0( ゼロ ) を埋め込んだデータベース ID %t インスタンス スレッド番号 %T 0( ゼロ ) を埋め込んだインスタンス スレッド番号 %s ログ ファイル順序番号 %S 0( ゼロ ) を埋め込んだログ ファイル順序番号 %r リセットログ ID %R 0( ゼロ ) を埋め込んだリセットログ ID 次に例を示します LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc Real Application Clusters が LOG_ARCHIVE_FORMAT パラメータを持つアーカイブ REDO ログ ファイルを一意に識別するためには スレッド パラメータ %t または %T が必須です アーカイブ ログ ファイルの格納場所に関する詳細は 項を参照してください D.2.2 アーカイブ先の割当て制限 LOG_ARCHIVE_DEST_n 初期化パラメータの QUOTA_SIZE 属性を使用すると アーカイブ先で使用できるディスク デバイスの物理記憶域の量を指定できます 宛先に割り当てられた物理ディスクの全部または一部を占有できるようにアーカイブ先を指定できます たとえば Real Application Clusters 環境では 物理的なディスク デバイスを 2 つ以上の別々のノードで共有できます インスタンス間では 初期化パラメータの情報が共有されていないため Real Application Clusters ノードは 物理ディスク デバイスが他のインスタンスと共有されていることを認識していません このため 宛先ディスク デバイスがいっぱいになったときには重大な問題が発生します すなわち すべてのインスタンスがすでにいっぱいになったデバイスへのアーカイブを実行するまで エラーは検出されません これはデータベースの可用性に影響を及ぼします Data Guard および Real Application Clusters D-5

356 Real Application Clusters 環境での構成に関する考慮事項 D.2.3 データ保護モード D.2.4 ロールの推移 最大保護モードまたは最大可用性モードで稼働している Real Application Clusters 構成では インスタンスがスタンバイ宛先との接続を失うと 他のすべてのインスタンスがその宛先へのデータ送信を停止します ( これによって 宛先に転送されたデータの整合性が維持されます ) 障害のあったスタンバイ宛先が復旧すると Data Guard は ギャップなしになるまで そのサイトを再同期化モードで実行します これによって そのスタンバイ宛先は Data Guard 構成に再び含まれます 次のリストで Real Application Clusters 環境における保護モードの動作を説明します 最大保護の構成 接続を失った宛先が最後の LGWR SYNC 宛先の場合 インスタンスは接続を失い 停止します Real Application Clusters 構成内でスタンバイ宛先への接続を維持している宛先は 接続を失ったインスタンスをリカバリし スタンバイ宛先への送信を継続します Real Application Clusters 構成内のすべてのインスタンスが最後のスタンバイ宛先への接続を失った場合にのみ プライマリ データベースが停止します この項は 次の項目で構成されています スイッチオーバー フェイルオーバー D スイッチオーバー Real Application Clusters データベースの場合は 1 つのプライマリ インスタンスと 1 つのスタンバイ インスタンスのみをスイッチオーバー時にアクティブにできます したがって スイッチオーバーの前に 1 つのプライマリ インスタンスと 1 つのスタンバイ インスタンス以外はすべて停止します スイッチオーバーの完了後 スイッチオーバーの実行時に停止したプライマリ インスタンスとスタンバイ インスタンスを再起動します 注意 : SQL ALTER DATABASE 文を使用してスイッチオーバーを実行すると REDO ログ ファイルが存在していない場合は自動的に作成されます これによって COMMIT 操作の完了に必要な時間が大幅に長くなる場合があるため フィジカル スタンバイ データベースを作成するときは REDO ログ ファイルを手動で追加することをお薦めします D フェイルオーバー Real Application Clusters スタンバイ データベースへのフェイルオーバーを実行するには 最初に 1 つのスタンバイ インスタンス以外はすべて停止します フェイルオーバーの完了後 停止したインスタンスを再起動します D-6 Oracle Data Guard 概要および管理

357 トラブルシューティング D.3 トラブルシューティング この項は Real Application Clusters で発生する問題のトラブルシューティングのヘルプとしてご利用いただけます 次の項目で構成されています Real Application Clusters 構成でスイッチオーバーできない ネットワーク停止時に Real Application Clusters の停止時間を回避する D.3.1 Real Application Clusters 構成でスイッチオーバーできない データベースが Real Application Clusters を使用すると アクティブ インスタンスによってスイッチオーバーの実行が妨げられます 他のインスタンスがアクティブの場合は スイッチオーバーの試行が次のエラー メッセージを伴って失敗します SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY; ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY * ORA-01105: マウントは別のインスタンスによるマウントと矛盾します 処置 : 次のように GV$INSTANCE ビューを問い合せ 問題の原因となっているインスタンスを判断します SQL> SELECT INSTANCE_NAME, HOST_NAME FROM GV$INSTANCE 2> WHERE INST_ID <> (SELECT INSTANCE_NUMBER FROM V$INSTANCE); INSTANCE_NAME HOST_NAME INST2 standby2 この例では 識別されたインスタンスを手動で停止しないと スイッチオーバーを継続できません 識別されたインスタンスには使用中のインスタンスから接続でき SHUTDOWN 文をリモートで発行できます 次に例を示します SQL> CONNECT SYS/CHANGE_ON_INSTALL@standby2 AS SYSDBA SQL> SHUTDOWN; SQL> EXIT D.3.2 ネットワーク停止時に Real Application Clusters の停止時間を回避する Real Application Clusters 環境でプライマリ データベースをサポートするように Data Guard を構成し プライマリ データベースが最大保護モードで稼働している場合 プライマリ データベースとそのすべてのスタンバイ データベース間のネットワークが停止すると ネットワーク接続がリストアされるまで プライマリ データベースは使用不可能になります 最大保護モードでは 最後のスタンバイ データベースが使用不可能になった場合 プライマリ データベースも停止します ネットワークの停止時間が長い場合は ネットワーク接続がリストアされるまで プライマリ データベースを最大可用性モードまたは最大パフォーマンス モードのいずれかで実行するように変更することを考慮してください プライマリ データベースを最大可用性モードに変更すると プライマリ データベースとスタンバイ データベースの間にラグが発生する可能性があります ただし ネットワークの問題が解決するまで プライマリ データベースを使用することができます プライマリ データベースを最大可用性モードに変更する場合は 次のプロシージャを使用してデータの破損を防止することが重要です 次に ネットワークが停止し Real Application Clusters 構成の保護モードを変更する場合の手順を説明します この例では PFILE ではなく サーバー パラメータ ファイル (SPFILE) を使用していることを前提とします 1. この時点では Real Application Clusters プライマリ インスタンスはすべて停止しています STARTUP MOUNT コマンドを発行して 1 つのインスタンスを開始します STARTUP MOUNT; Data Guard および Real Application Clusters D-7

358 トラブルシューティング 2. 最大保護モードを最大可用性モードまたは最大パフォーマンス モードのいずれかに変更する場合は 項の説明に従ってください また ブローカを使用している場合は Oracle Data Guard Broker を参照してください たとえば 次の文は 最大可用性保護モードを設定します ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY; 3. Real Application Clusters プライマリ データベースをオープンし 通常にアクセスします 後でネットワークが回復したときに 次の手順を実行して最大保護モードに戻ります 1. Real Application Clusters プライマリ データベースのすべてのインスタンスを停止します 2. Real Application Clusters プライマリ データベースのシングル インスタンスをオープンせずにマウントし 通常にアクセスします 3. Real Application Clusters プライマリ データベースのモードを現行モード ( 最大可用性または最大パフォーマンス ) から最大保護モードに変更します 4. Real Application Clusters プライマリ データベースをオープンし 通常にアクセスします D-8 Oracle Data Guard 概要および管理

359 E カスケードされた宛先 プライマリ システムの負荷を軽減するために カスケードされた宛先カスケードされた宛先を実装できます これによって スタンバイ データベースは REDO データをプライマリ データベースから直接受信するのではなく 別のスタンバイ データベースから受信します 次のデータベースを構成できます フィジカル スタンバイ データベース プライマリ データベースから受信した着信 REDO データを プライマリ データベースと同じ方法で他のリモートの宛先に再転送します ロジカル スタンバイ データベース 読取り / 書込みモードでオープンされるため プライマリ データベースから受信した REDO データのフィルタ処理と適用が完了した後に生成した REDO データを 独自のフィジカルまたはロジカルのスタンバイ データベースのセットに送信します 図 E-1 は フィジカル スタンバイ データベースとロジカル スタンバイ データベースへのカスケードされた宛先を示しています 図 E-1 カスケードされた宛先の構成例 スタンバイ データベースでは REDO データを最大 9 個の宛先までカスケードできます ただし 実際には カスケードされた REDO データを受信するように構成するのは 主としてレポート生成またはバックアップのオフロード専用のスタンバイ データベースのみです ロールの推移に関与する可能性のあるスタンバイ データベースは プライマリ データベースから直接 REDO データを受信するように構成し LOG_ARCHIVE_DEST_n パラメータの VALID_ FOR 属性を定義します この結果 スイッチオーバー操作またはフェイルオーバー操作を実行した場合も 引き続き新しいプライマリ データベースから直接 REDO データを受信できます カスケードされた宛先 E-1

360 この項は 次の項目で構成されています カスケードされた宛先の構成 カスケードされた宛先を使用したロールの推移 カスケードされた宛先の例 注意 : Oracle Data Guard Broker は カスケードされた宛先の構成または管理には使用できませんが 許容することはできます E-2 Oracle Data Guard 概要および管理

361 カスケードされた宛先の構成 E.1 カスケードされた宛先の構成 次の各項では カスケードされた宛先を使用できるように Data Guard 構成を設定する方法について説明します フィジカル スタンバイ データベースに対するカスケードされた宛先の構成 ロジカル スタンバイ データベースに対するカスケードされた宛先の構成 E.1.1 フィジカル スタンバイ データベースに対するカスケードされた宛先の構成 フィジカル スタンバイ データベースが着信 REDO データを別の宛先セットに送信できるようにするには 次の項目を定義する必要があります プライマリ データベースの LOG_ARCHIVE_DEST_n 初期化パラメータを定義して カスケードの開始点となるフィジカル スタンバイ データベースを設定します 次の属性を使用する宛先を定義します 転送方法を指定する ARCH または LGWR 属性 LGWR 転送方法を使用すると 要件に応じて SYNC または ASYNC ネットワーク プロトコルを使用できます カスケードされた宛先 元のプライマリ宛先およびスタンバイ宛先を処理する VALID_FOR 属性 カスケードされたスタンバイ データベースに加えて プライマリ データベースとその他のスタンバイ データベースの宛先も定義します 受信側のフィジカル スタンバイ データベースで 通常の数以上のスタンバイ REDO ログ ファイルを定義し アーカイブが可能であることを確認します この時点で カスケードのエンド ポイントを定義するフィジカル スタンバイ データベースの LOG_ARCHIVE_DEST_n 初期化パラメータの定義を開始できます 表 E-1 に初期化パラメータを示します この例では ボストンのプライマリ データベースは REDO をシカゴのフィジカル スタンバイ データベースに送信し シカゴのフィジカル スタンバイ データベースはそのアーカイブ REDO ログ ファイルをデンバーのスタンバイ データベースにカスケードします 例では デンバーのデータベースはロジカル スタンバイ データベースですが フィジカル スタンバイ データベースが フィジカルまたはロジカル スタンバイ データベースのいずれかに REDO をカスケードできます 表 E-1 プライマリ データベース フィジカル スタンバイ データベースおよびロジカル スタンバイ データベースの初期化パラメータ Boston データベース ( プライマリ ロール ) DB_UNIQUE_NAME=boston LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(chicago,boston,denver)' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/ VALID_FOR=(ONLINE_ LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=denver VALID_FOR=(STANDBY_ LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver' LOG_ARCHIVE_DEST_3= 'SERVICE=chicago VALID_FOR= (ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' STANDBY_ARCHIVE_DEST=/arch1/boston/ REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE Chicago データベース ( スタンバイ ロール ) DB_UNIQUE_NAME=chicago LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(chicago,boston,denver)' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/ VALID_FOR=(ONLINE_ LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_2= 'SERVICE=denver VALID_FOR=(STANDBY_ LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver' LOG_ARCHIVE_DEST_3= 'SERVICE=boston VALID_FOR= (ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston' STANDBY_ARCHIVE_DEST=/arch1/chicago/ REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE Denver データベース ( スタンバイ ロール ) DB_UNIQUE_NAME=denver LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(chicago,boston,denver)' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/denver/ VALID_FOR=(ONLINE_ LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver' LOG_ARCHIVE_DEST_2= 'LOCATION=/arch2/denver/ VALID_FOR=(STANDBY_ LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver' STANDBY_ARCHIVE_DEST=/arch2/denver/ REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE カスケードされた宛先 E-3

362 カスケードされた宛先の構成 ボストンのプライマリ データベースおよびシカゴのフィジカル スタンバイ データベースでは LOG_ARCHIVE_DEST_2 初期化パラメータを 'SERVICE=denver VALID_ FOR=(STANDBY_LOGFILES, STANDBY_ROLE) として定義しています そのため ボストンのデータベースおよびシカゴのデータベースでロールが切り替えられても REDO データはデンバーのデータベースに引き続きカスケードされます フィジカル スタンバイ データベースの元の設定の一部として フィジカル スタンバイ データベースがプライマリ ロールに推移した際にローカル アーカイブに使用する ローカルの宛先 VALID_FOR=(ONLINE_ LOGFILE, PRIMARY_ROLE) を定義する必要があることに注意してください E.1.2 ロジカル スタンバイ データベースに対するカスケードされた宛先の構成 プライマリ データベースから直接 REDO データを受信するロジカル スタンバイ データベースは プライマリ データベースから受信した REDO データのフィルタ処理と適用が完了した後に生成した REDO データを 他のスタンバイ データベースにカスケードするように構成できます ロジカル スタンバイ データベースからカスケードされた REDO データは プライマリ データベースで生成された元の REDO データと同一ではないため プライマリ データベースから直接作成されたスタンバイ データベースには適用できません かわりに ロジカル スタンバイ データベースからカスケードされた REDO データを受信するスタンバイ データベースは ロジカル スタンバイ データベースのコピーから作成する必要があります この場合 次のようになります ロジカル スタンバイ データベースから作成されたフィジカル スタンバイ データベースは ロジカル スタンバイ データベースのブロック単位のコピーとなり 元のプライマリ データベースの論理的なコピーとなります ロジカル スタンバイ データベースから作成されたロジカル スタンバイ データベースは 親のロジカル スタンバイ データベースの論理的なコピーとなり 元のプライマリ データベースに一部類似しています これは 元のプライマリ データベースのデータ以外に 親のロジカル スタンバイ データベースに格納されたすべての内容 ( 異なる索引やマテリアライズド ビューなどの変更も含む ) が存在するためです ロジカル スタンバイ データベースからカスケードされた REDO データを受信するスタンバイ データベースの場合は プライマリ データベースから直接 REDO データを受信するフィジカル スタンバイ データベースまたはロジカル スタンバイ データベースと同じ設定タスクを実行する必要があります フィジカル スタンバイ データベースと同様に 任意の転送モード (LGWR または ARCH) およびネットワーク プロトコル (SYNC または ASYNC) が使用できます スタンバイ データベースでスタンバイ REDO ログ ファイルを構成する必要があります E-4 Oracle Data Guard 概要および管理

363 カスケードされた宛先の例 E.2 カスケードされた宛先を使用したロールの推移 ほとんどのロールの推移は 別のスタンバイ データベースからカスケードされた REDO ログ ファイルを受信するスタンバイ データベースを使用して実行できます ただし データ消失のリスクを最小限に抑え ロールの推移を最速で行うには 障害リカバリ用に構成されたすべてのスタンバイ データベースで REDO データをプライマリ データベースから直接受信することをお薦めします E.2.1 フィジカル スタンバイ データベースから REDO データを受信するスタンバイ データベース 再転送されたプライマリ データベースの REDO データを受信するフィジカル スタンバイ データベースはすべて同一であり ロールの推移に対して有効であるため スイッチオーバーやフェイルオーバーの実行プロセスは カスケードされた構成内のプロセスとまったく同じです 唯一の違いは end-of-redo データをスタンバイ データベースにカスケードする際に余分な時間がかかる場合があるという点です フィジカル スタンバイ データベースを使用してロールの推移を行う方法については 7.2 項を参照してください E.2.2 ロジカル スタンバイ データベースから REDO データを受信するスタンバイ データベース ロジカル スタンバイ データベースからカスケードされた REDO データを受信するスタンバイ データベースは プライマリ データベースが関与するスイッチオーバーに使用できません スイッチオーバーで使用できるのは プライマリ データベースから REDO データを直接受信するロジカル スタンバイ データベースのみです ロジカル スタンバイ データベースで生成された REDO データを受信するデータベースにフェイルオーバーする場合は 同じロジカル スタンバイ データベースからカスケードされた REDO データを受信する それ以外のロジカル スタンバイ データベースのみ フェイルオーバー後の Data Guard 構成に引き続き使用することができます ロジカル スタンバイ データベースを使用してロールの推移を行う方法については 7.3 項を参照してください E.3 カスケードされた宛先の例 次の使用例では カスケードされた宛先の構成オプションと使用方法を説明します E.3.1 ローカル フィジカル スタンバイとカスケードされたリモート フィジカル スタンバイ 本社のオフィスにプライマリ データベースがあり 別のビルにスタンバイ データベースを作成して Local Area Network(LAN) で接続するとします さらに 社内の保護要件により REDO データとバックアップ コピーを地理的に離れた位置にあるオフサイトで保管し LAN ではなく Wide Area Network(WAN) で接続するとします この両方のサイトに REDO データを転送できるように プライマリ データベースで 2 つの宛先を定義できますが WAN を介した REDO データ送信のネットワーク待機時間が原因で プライマリ データベースのスループットに余分なワークロードがかかります この問題を解決するために LGWR および SYNC ネットワーク転送とスタンバイ REDO ログ ファイルを使用して LAN 上のプライマリ データベースとフィジカル スタンバイ データベースとの間に緊密な接続を定義できます これによって プライマリ データベースへの接続が失われないように保護し プライマリ データベースでメンテナンスが必要になった場合は 本番用の代替サイトを提供できます WAN で接続されたセカンダリ ロケーションには フィジカル スタンバイ データベースがサービスを提供し REDO データを確実にオフサイトで格納できるようにします 本番データベースの毎晩のバックアップは WAN を介してリモート スタンバイ データベースに移送できるため オフサイトの格納場所にテープを発送する必要がなくなります カスケードされた宛先 E-5

364 カスケードされた宛先の例 プライマリ データベースと LAN 上のフィジカル スタンバイ データベースの両方に接続できない最悪の状況が発生した場合は 最小限のデータ消失でリモート スタンバイ データベースにフェイルオーバーできます 元のスタンバイ データベースからの 最後のスタンバイ データベースの REDO ログ ファイルにアクセスできた場合は リモート スタンバイ データベースでリカバリできるため データ消失はありません WAN を介した情報の送信によって問題が発生するのは スイッチオーバーまたはフェイルオーバー時 ( フィジカル スタンバイ データベースがプライマリ ロールに推移したとき ) のみです しかし この構成は企業の保護要件を満たしています E.3.2 ローカル フィジカル スタンバイとカスケードされたリモート ロジカル スタンバイ 離れた位置にプライマリ データベースがあり レポート生成のためにそのデータにローカルでアクセスする必要があるとします プライマリ データベースには 障害時の回復に備えて すでに 1 つのスタンバイ データベースが設定されています このスタンバイ データベースはオフサイトの位置にあり LAN で接続されています プライマリ データベースで このサイトに情報を送信するように宛先を指定すると プライマリ データベースのパフォーマンスに悪影響を与えます この問題の解決策は 使用例 1 で説明した解決策と似ています ただし すでに 1 つのフィジカル スタンバイ データベースが準備されているため REDO データはロジカル スタンバイ データベースに送信することにします 最初に スタンバイ ログ ファイルが使用されていることを確認します スタンバイ REDO ログ ファイルが未定義の場合は スタンバイ データベースで動的に定義できます スタンバイ データベースは プライマリ データベースで次回ログ スイッチが発生した後に スタンバイ REDO ログ ファイルの使用を開始します 次に ロジカル スタンバイ データベースの通常の設定タスクを実行します ロジカル スタンバイ データベースの使用準備に必要な手順は すべて通常プライマリ ロケーションで実行する必要があります ロジカル スタンバイ データベースが起動して稼働した後 フィジカル スタンバイ データベースで宛先パラメータを定義し REDO データが WAN を介して送信され ロジカル スタンバイ データベースに適用されるようにします E.3.3 ローカルおよびリモート フィジカル スタンバイとカスケードされたローカル ロジカル スタンバイ 製造サイトにあるプライマリ データベースには すでに 2 つのフィジカル スタンバイ データベースが構成されています 1 つのスタンバイ データベースは 別のビルに配置され LAN で接続されており もう 1 つのスタンバイ データベースは離れた位置にある本社のオフィスに配置され WAN で接続されています この 2 つのスタンバイ データベースは 非データ消失モードで実行する必要があるため WAN で接続されたスタンバイ データベースにカスケードされた宛先を使用できません また マーケティング部門では 販売予測のために製造データにアクセスする必要があります マーケティング部門は毎日データにアクセスし 販売データと製造データを照合して 販売時期に対する製造時期を正確に判断する必要があります 解決策の 1 つとして マーケティング部門が 本社にあるフィジカル スタンバイ データベースに読取り専用モードでアクセスできるようにする方法があります しかし スタンバイ データベースを読取り専用モードに設定するには REDO Apply を停止する必要があります この結果 プライマリ データベースの内容がフィジカル スタンバイ データベースに反映されるのが夜間のみになり その間も プライマリ データベースは 製造工場での第 2 シフトおよび第 3 シフト作業によるデータを受信していることになります さらに スタンバイ データベースでは アーカイブ REDO ログ ファイルの適用が常に 12 時間以上遅れます プライマリ データベースに別の宛先を追加して REDO データを本社オフィス内の異なるロジカル スタンバイ データベースに送信することもできます 本社オフィスで使用されているシステムが フィジカル スタンバイ データベースと計画済のロジカル スタンバイ データベースとでは異なるため スタンバイ宛先の定義時に DEPENDENCY 属性は使用できません WAN を介して REDO データを送信する必要があるため REDO データを 2 回送信するこ E-6 Oracle Data Guard 概要および管理

365 カスケードされた宛先の例 とは プライマリ データベースのパフォーマンスを許容できないレベルまで低下させると考えられます この問題は カスケードされた宛先によって解決できます カスケード スタンバイ データベースを設定するには 第 4 章の説明に従ってロジカル スタンバイ データベースを作成します また 本社のフィジカル スタンバイ データベースが LAN を介してこの新しいロジカル スタンバイ データベースに REDO データを転送するように設定する必要もあります この方法では プライマリ データベースは WAN を介してデータを 1 回のみフィジカル スタンバイ データベースに送信します また ロジカル スタンバイ データベースは 新しいマテリアライズド ビューを使用して変更できるため マーケティング グループは データを効率的に管理できます ロジカル スタンバイ データベースは オープンされて読取り / 書込みモードになるため マーケティング グループは プライマリ データベースのパフォーマンス あるいはフィジカル スタンバイ データベースの実行可能性や現行の状態に影響を与えずに 販売データに対する新規スキーマの追加やロードを実行できます E.3.4 カスケードされたロジカル スタンバイ宛先の統合レポート生成 世界各地に 5 つの販売オフィスがあり 各オフィスに独自のプライマリ データベースが配置されているとします すべてのオフィスに 障害時の回復対策を導入するとします その際 各プライマリ データベースへの影響を最小限に抑えながら すべてのデータに適時にアクセスできる方法も考慮します この問題を解決するには 最初に 5 箇所の各オフィスに非データ消失環境を実装します これを行うには LGWR および SYNC 属性を使用して 各オフィスにローカルのフィジカル スタンバイ データベースを作成します このフィジカル スタンバイ データベースは LAN で接続できます 次に 5 個の各プライマリ データベースからロジカル スタンバイ データベースを作成して 本社に配置します ただし REDO データは 5 個の各プライマリ データベースの REDO 転送サービスによって送信されるのではなく 5 個の各スタンバイ データベースから WAN を介してロジカル スタンバイ データベースに送信されるように構成します 1 つまたはすべてのロジカル スタンバイ データベースで 別のロジカル スタンバイ データベースへのデータベース リンクを定義し このリンクによって 全販売データにアクセスできるようにします 5 個の各プライマリ データベースの全情報ではなく 特定の表のみ必要な場合は SKIP ルーチンを使用して 各ロジカル スタンバイ データベースに不要なデータの適用を停止できます E.3.5 ネットワーク アップグレード時のカスケードされた宛先の一時使用 現在 夜間のバックアップのみで保護されているプライマリ データベースがあるとします 優れた障害時リカバリ対策をすぐに導入する必要があります 社内に 同じハードウェア タイプの別のシステムがありますが フェイルオーバー用のスタンバイ データベースとして使用するには処理能力が低く データベース全体を格納するディスクも不足しています データベース全体の格納に十分に対応できる唯一の別のシステムは LAN で接続するには離れた場所にあり WAN で接続すると極端に低速になります この対策の導入期限は いずれかのネットワークがアップグレードされるまでです プライマリ データベースで宛先を追加して REDO データをリモート ロケーションに送信すると パフォーマンスに重大な影響を与えます この問題の暫定的な解決策は リモート システムでフィジカル スタンバイ データベースを作成し 小規模なローカル システムに分散リポジトリを作成することです 分散リポジトリには スタンバイ制御ファイル スタンバイ REDO ログ ファイルおよびスタンバイ データベースのアーカイブ REDO ログ ファイルのみが含まれ データファイルは含まれません REDO データがローカルのリポジトリに送信されるようにプライマリ データベースを構成するには ログ ライター プロセス (LGWR) を同期モード (SYNC) で使用します LAN で接続されるため パフォーマンスへの影響は最小限で済みます 次に リポジトリからデータが WAN を介して実際のスタンバイ データベースに送信されるように構成します この構成のリスクは プライマリ データベースの障害時に プライマリ データベースからスタンバイ データベースへの全データの転送が完了していても リポジトリからリモート スタンバイ データベースへのデータ送信が完了していない可能性があることです この環境では 両方のシステムに同時に障害が発生しないかぎり リモート スタンバイ データベースでは 最後のログ スイッチまでに送信された全データを受信できます 現行の REDO ログ ファイルを 手動で送信することが必要な場合もあります カスケードされた宛先 E-7

366 カスケードされた宛先の例 WAN がアップグレードされて リモート スタンバイ データベースに直接接続できるようになった場合は リポジトリの宛先を変更して リモート スタンバイ データベースを直接指すようにするか 新たにリモート スタンバイ データベースの宛先を作成し リポジトリへの転送は アーカイブ ログ リポジトリとして継続します E-8 Oracle Data Guard 概要および管理

367 Recovery Manager を使用したスタンバイ データベースの作成 F この付録では Oracle Recovery Manager を使用してスタンバイ データベースを作成する方法を説明します この付録は 次の項目で構成されています スタンバイ データベースを作成するための Recovery Manager の準備 Recovery Manager を使用したスタンバイ データベースの作成 : 概要 スタンバイ データベースの設定 同一のディレクトリ構造のスタンバイ データベースの作成 異なるディレクトリ構造のスタンバイ データベースの作成 ローカル ホスト上へのスタンバイ データベースの作成 イメージ コピーを使用したスタンバイ データベースの作成 使用例 Recovery Manager を使用したスタンバイ データベースの作成 F-1

368 スタンバイ データベースを作成するための Recovery Manager の準備 F.1 スタンバイ データベースを作成するための Recovery Manager の準備 Recovery Manager を使用してスタンバイ データベースを作成すると 次のような利点があります プライマリ データベースのバックアップを使用してスタンバイ データベースが作成され データファイルがバックアップからスタンバイ サイトにリストアされます したがって スタンバイ データベースの作成中にプライマリ データベースが影響を受けることはありません Oracle Managed Files(OMF) などのファイルやディレクトリ構造の名前の変更が自動化されます アーカイブ REDO ログ ファイルがバックアップからリストアされ スタンバイ データベースがプライマリ データベースと一致するまでリカバリが実行されます Recovery Manager を使用してスタンバイ データベースを準備する手順は 基本的に 複製データベースの準備と同じです ただし スタンバイ データベース固有の問題に対処するために Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド で説明されている複製手順を変更する必要があります この章で説明する Recovery Manager での作成手順を実行する前に 第 3 章 フィジカル スタンバイ データベースの作成 および第 4 章 ロジカル スタンバイ データベースの作成 のスタンバイ データベースの作成方法を理解してください この項は 次の項目で構成されています Recovery Manager を使用したスタンバイ データベースの準備について Recovery Manager を使用したスタンバイ制御ファイルの作成 Recovery Manager を使用した場合のスタンバイ データベース データファイルのネーミング Recovery Manager を使用した場合のスタンバイ データベース ログ ファイルのネーミング F.1.1 Recovery Manager を使用したスタンバイ データベースの準備について プライマリ データベースのバックアップからスタンバイ データベースを作成するには 手動での作成 または Recovery Manager の DUPLICATE コマンドのどちらでも使用できます 作成手順を実行する前に スタンバイ インスタンスを準備する必要があります 表 F-1 で説明されている準備タスクには Recovery Manager を使用できます 表 F-1 Recovery Manager を使用したスタンバイ データベースの準備 タスク スタンバイ データベースの作成に使用するプライマリ データベースのバックアップの作成 スタンバイ制御ファイルとして使用可能なプライマリ制御ファイルのバックアップの作成 ( 存在しない場合 ) スタンバイ データファイルのファイル名の選択 スタンバイ データベースのアーカイブ REDO ログ ファイルおよびスタンバイ REDO ログ ファイルのファイル名の選択 手順の詳細 Oracle Database バックアップおよびリカバリ基礎 の説明に従い プライマリ データベースの通常のバックアップ手順を実行します F.1.2 項 Recovery Manager を使用したスタンバイ制御ファイルの作成 を参照してください F.1.3 項 Recovery Manager を使用した場合のスタンバイ データベース データファイルのネーミング を参照してください F.1.4 項 Recovery Manager を使用した場合のスタンバイ データベース ログ ファイルのネーミング を参照してください F-2 Oracle Data Guard 概要および管理

369 スタンバイ データベースを作成するための Recovery Manager の準備 表 F-1 で示されている Recovery Manager のタスクに加え スタンバイ データベースをセットアップするために次のタスクを実行する必要があります プライマリ データベースで必要な初期化パラメータをすべて設定します スタンバイ データベース用の初期化パラメータ ファイルを作成し 必要なパラメータをすべて構成します スタンバイ インスタンスに接続するために 必要に応じて Oracle Net をセットアップおよび構成します 制御ファイルをマウントせずにスタンバイ インスタンスを起動します 初期化パラメータの設定など フィジカル スタンバイ データベースの準備の詳細は 第 3 章を参照してください Recovery Manager によってスタンバイ データベース ファイルを正常に作成し スタンバイ データベースをマウントする前に この章で説明されている必要な準備タスクをすべて実行する必要があります F.1.2 Recovery Manager を使用したスタンバイ制御ファイルの作成 スタンバイ制御ファイルを作成するには Recovery Manager の BACKUP コマンドまたは COPY コマンドを使用して 次の手順を実行します 手順 1 プライマリ データベースに接続するプライマリ データベース および必要に応じてリカバリ カタログ データベースへ接続します たとえば 次のように入力します % rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb 手順 2 スタンバイ制御ファイルを作成する次のいずれかのコマンドを使用して スタンバイ制御ファイルを作成します BACKUP コマンドと COPY コマンドの唯一の相違は バックアップ ファイル形式が異なる点です BACKUP コマンドを使用する プライマリ データベースをマウントし BACKUP CURRENT CONTROLFILE FOR STANDBY コマンドを使用して スタンバイ制御ファイルを作成します 次の例では 構成済チャネルを使用してスタンバイ制御ファイルを作成します その後 データベースをオープンして アーカイブされていない REDO ログ ファイルをすべてアーカイブし 一度もバックアップされていないログ ファイルをバックアップします STARTUP MOUNT BACKUP CURRENT CONTROLFILE FOR STANDBY; SQL> ALTER DATABASE OPEN; SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; # so backup is consistent and recoverable BACKUP ARCHIVELOG ALL NOT BACKED UP 1 TIMES; COPY コマンドを使用する 現行のプライマリ制御ファイルをコピーします COPY CURRENT CONTROLFILE コマンドの FOR STANDBY オプションを指定し スタンバイ制御ファイルとして使用可能な 現行の制御ファイルのコピーを作成します 次に例を示します COPY CURRENT CONTROLFILE FOR STANDBY TO '/tmp/sby_control01.ctl'; Recovery Manager を使用したスタンバイ データベースの作成 F-3

370 スタンバイ データベースを作成するための Recovery Manager の準備 手順 1 バックアップ セットまたはイメージ コピーをリストする必要に応じて LIST コマンドを発行してバックアップ セットをリストするか LIST COPY コマンドを発行してイメージ コピーをリストします 注意 : SQL ALTER DATABASE CREATE STANDBY CONTROLFILE AS 文によってスタンバイ制御ファイルがすでに作成されている場合は 次のように Recovery Manager の CATALOG コマンドを使用して リカバリ カタログにスタンバイ制御ファイルのメタデータを追加できます CATALOG CONTROLFILECOPY '/tmp/sby_control01.ctl'; F.1.3 Recovery Manager を使用した場合のスタンバイ データベース データファイルのネーミング スタンバイ データベースは プライマリ データベースと同じホストまたは異なるホストのいずれにでも常駐することが可能です 次の表に ホスト上のディレクトリ構造が同じであるかどうかにより スタンバイ データベースのデータファイル名の変更にどのように影響するかを示します スタンバイ データベースのホスト ディレクトリ構造 名前の変更 プライマリと同じホストプライマリ ホストと異なる必須 プライマリと同じホスト プライマリ ホストと同じ 無効 スタンバイ データベースのデータファイルは プライマリ データベースのデータファイルと同じホストの同じディレクトリには常駐できません プライマリと異なるホストプライマリ ホストと同じ必須ではない プライマリと異なるホストプライマリ ホストと異なる必須 ディレクトリ構造がプライマリおよびスタンバイ ホストで異なる場合 スタンバイ データファイルのネーミングには次のオプションがあります スタンバイ データベース初期化パラメータ DB_FILE_NAME_CONVERT の構成 Recovery Manager の DUPLICATE コマンドの DB_FILE_NAME_CONVERT オプションの使用 スタンバイ データベースを作成する際の CONFIGURE AUXNAME または SET NEWNAME コマンドの使用 プライマリおよびスタンバイ ホストのディレクトリ構造が同じ場合 ネーミングには次のオプションがあります スタンバイ ファイル名をプライマリ ファイル名と同じにし (DB_FILE_NAME_ CONVERT を設定したり CONFIGURE AUXNAME または SET NEWNAME コマンドを発行しない ) DUPLICATE コマンドの NOFILENAMECHECK オプションを使用する DB_FILE_NAME_CONVERT パラメータまたは CONFIGURE AUXNAME または SET NEWNAME コマンドを使用してスタンバイ データファイルの名前を変更する DB_FILE_NAME_CONVERT を使用する場合 書式は次のとおりです DB_FILE_NAME_CONVERT = 'oldstring1', 'newstring1', 'oldstring2', 'newstring2',... たとえば DB_FILE_NAME_CONVERT 初期化パラメータは次のように指定します DB_FILE_NAME_CONVERT = '/dbs/t1/', '/dbs/t1/s_', '/dbs/t2/', '/dbs/t2/s_' F-4 Oracle Data Guard 概要および管理

371 スタンバイ データベースを作成するための Recovery Manager の準備 スタンバイ制御ファイル内のデータファイル名を指定する方法が複数存在するため 設定の優先順位を決定する方法が必要です 表 F-2 に スタンバイ データベース内のデータファイルのネーミングの階層を指定します 表 F-2 スタンバイ データベース内のデータファイルのネーミング優先順位 スタンバイ データファイルの ネーミング方法 要件 1 SET NEWNAME コマンドを発行する スタンバイ データベースを作成するには このコマンドを RUN ブロック内で発行する必要があります 2 Recovery Manager の DUPLICATE コマンドの DB_FILE_NAME_CONVERT オプションを使用する なし 3 CONFIGURE AUXNAME コマンドを発行する 4 スタンバイ制御ファイルで現在指定されているデータファイルのファイル名 スタンバイ ファイル名は プライマリ ファイル名と同じか または DB_FILE_ NAME_CONVERT パラメータを使用してネーミングされています リカバリ カタログに接続し データファイル用に NULL 以外の AUXNAME をカタログに格納する必要があります ファイル名が同じ場合 スタンバイの初期化パラメータ ファイルで DB_FILE_NAME_CONVERT パラメータを設定する必要があります ファイル名が同じ場合 DUPLICATE コマンドの NOFILENAMECHECK 句を指定する必要があります スタンバイ データベースで DB_FILE_NAME_CONVERT を使用してファイルをネーミングする方法は Oracle Database リファレンス を参照してください F.1.4 Recovery Manager を使用した場合のスタンバイ データベース ログ ファイルのネーミング REDO ログ ファイルは Recovery Manager によってスタンバイ データベースに作成されません ただし 第 3 章で説明しているように スタンバイ データベースで他のアクションを実行することにより ログ ファイルが作成される場合もあります ログ ファイルは作成後 ログ ファイルの通常のルールに従って管理およびアーカイブされます スタンバイ データベースの REDO ログ ファイルをネーミングする際の唯一のオプションは スタンバイ制御ファイルで指定されるログ ファイルのファイル名です スタンバイ上のログ ファイル名をプライマリ上のファイル名と異なる名前にする必要がある場合は スタンバイ初期化パラメータ ファイルで LOG_FILE_NAME_CONVERT を設定して REDO ログのファイル名を指定する方法を選択できます スタンバイ データベース上で REDO ログ ファイルのファイル名を指定する際 次の制限事項に注意してください プライマリ データベースおよびスタンバイ データベースでログ ファイルに異なるネーミング規則を使用している場合 REDO ログ ファイルのネーミングには LOG_ FILE_NAME_CONVERT パラメータを使用する必要があります REDO ログ ファイルの名前の変更には SET NEWNAME または CONFIGURE AUXNAME コマンドを使用できません REDO ログ ファイルのファイル名の指定には DUPLICATE コマンドの LOGFILE 句は使用できません スタンバイ データベース上の REDO ログ ファイル名をプライマリ データベースの REDO ログ ファイル名と同じ名前にする場合 DUPLICATE コマンドの NOFILENAMECHECK 句を指定する必要があります 指定しない場合 スタンバイ データベースが異なるホスト上で作成されていても Recovery Manager によりエラーが発生します Recovery Manager を使用したスタンバイ データベースの作成 F-5

372 Recovery Manager を使用したスタンバイ データベースの作成 : 概要 F.2 Recovery Manager を使用したスタンバイ データベースの作成 : 概要 スタンバイ データベースを作成する際 スタンバイ データベースがプライマリ データベースと同じホスト上に存在するか または異なるホスト上に存在するかにより 手順が異なります この章の手順は 第 3 章で説明したスタンバイのセットアップと準備が完了していることを前提としています すべての必要な初期化パラメータの設定とネットワーク構成の変更が完了するまでは 次の手順を実行しないでください スタンバイ インスタンスの準備に必要な手順を完了した後 Recovery Manager の DUPLICATE... FOR STANDBY コマンドを実行し プライマリ データベースのバックアップからスタンバイ データベースを作成します FOR STANDBY OPTION を使用せずに DUPLICATE コマンドを使用して作成された複製データベースと異なり スタンバイ データベースには新規 DBID が設定されません したがって スタンバイ データベースをリカバリ カタログに登録しないでください スタンバイ データベースの作成手順は 次の条件に応じて異なります Recovery Manager でスタンバイ データベースを作成後にリカバリするように指定するかどうか Oracle Managed Files(OMF) を使用するかどうか DUPLICATE コマンドを使用して スタンバイ データベースではない複製データベースを作成する方法は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください F.2.1 リカバリを実行しない Recovery Manager によるスタンバイの作成 デフォルトで Recovery Manager はスタンバイ データベースの作成後 リカバリを実行しません DUPLICATE コマンドの DORECOVER オプションを指定しない場合 Recovery Manager は 複製時のスタンバイ作成手順のうち 次の手順を自動化します 1. Recovery Manager は プライマリ データベースおよびスタンバイ データベースの両方 およびリカバリ カタログ ( 使用されている場合 ) への接続を確立します 2. Recovery Manager は リポジトリ ( プライマリ制御ファイルまたはリカバリ カタログのいずれか ) を問い合せ プライマリ データベースのデータファイルおよびスタンバイ制御ファイルを識別します 3. メディア マネージャを使用している場合 Recovery Manager はスタンバイ ホストのメディア マネージャにバックアップ データを要求します 4. Recovery Manager はスタンバイ ホストにスタンバイ制御ファイルをリストアし これによってスタンバイ制御ファイルを作成します 5. Recovery Manager はスタンバイ ホストにプライマリ データファイルのバックアップおよびコピーをリストアし これによってスタンバイ データベースのデータファイルを作成します 6. Recovery Manager はスタンバイ データベースをマウントした状態にしますが スタンバイ データベースを手動または管理リカバリ モードには設定しません Recovery Manager は接続を切断し スタンバイ データベースのメディア リカバリを実行しません スタンバイ データベースはリカバリ カタログに登録しないでください F-6 Oracle Data Guard 概要および管理

373 Recovery Manager を使用したスタンバイ データベースの作成 : 概要 F.2.2 リカバリを実行する Recovery Manager によるスタンバイの作成 DUPLICATE コマンドの DORECOVER オプションを指定した場合 Recovery Manager は F.2.1 項の手順 1 ~ 5 と同じ手順を実行します その後 手順 6 のかわりに 次の手順を実行します 1. すべてのデータのリストア後 Recovery Manager はメディア リカバリを開始します アーカイブ REDO ログ ファイルを必要とするリカバリで そのログ ファイルがディスクにない場合 Recovery Manager はバックアップからログ ファイルのリストアを試みます 2. Recovery Manager は 指定された時間 システム変更番号 (SCN) またはログ ファイル順序番号にスタンバイ データベースをリカバリします そのいずれも指定されていない場合は 最新の生成済アーカイブ REDO ログ ファイルにリカバリします 3. Recovery Manager は メディア リカバリの完了後 スタンバイ データベースをマウントしたままにしますが スタンバイ データベースを手動または管理リカバリ モードには設定しません スタンバイ データベースはリカバリ カタログに登録しないでください 注意 : Recovery Manager でスタンバイ データベースを作成した後 スタンバイ データベースを手動または管理リカバリ モードに設定したり読取り専用モードでオープンする前に ギャップ シーケンスを解決する必要があります ギャップ シーケンスの解決方法の詳細は 5.8 項を参照してください Recovery Manager によってスタンバイ データベースの作成後にリカバリを行う場合 実行するリカバリに対してスタンバイ制御ファイルが使用可能である必要があります したがって 次の条件を満たしている必要があります スタンバイ データベースのリカバリ終了時刻は スタンバイ制御ファイルのチェックポイント SCN 以上である必要があります スタンバイ制御ファイルのチェックポイント SCN が含まれているアーカイブ REDO ログ ファイルは リカバリ用にスタンバイ サイトから使用可能である必要があります これらの条件が満たされていることを確認するには スタンバイ制御ファイルの作成後に ALTER SYSTEM ARCHIVE LOG CURRENT 文を発行する方法があります この文は プライマリ データベースのオンライン REDO ログ ファイルをアーカイブします その後 最新のアーカイブ REDO ログ ファイルを Recovery Manager でバックアップするか またはアーカイブ REDO ログ ファイルをスタンバイ サイトに移動します 注意 : この章の手順では スタンバイ データベースの作成に Recovery Manager のバックアップを使用していることを前提としています Recovery Manager のイメージ コピーを使用している場合 F.7 項を参照してください Recovery Manager でスタンバイ データベースを作成する際の DUPLICATE の制限事項については Oracle Database Recovery Manager リファレンス を参照してください Recovery Manager を使用したスタンバイ データベースの作成 F-7

374 スタンバイ データベースの設定 F.3 スタンバイ データベースの設定 スタンバイのいずれの作成使用例を選択した場合でも まずスタンバイ データベースを起動し 次に Recovery Manager をこのデータベースに接続する必要があります この手順の詳細は スタンバイ システムとプライマリ システムのディレクトリ構造が異なるかどうか および Oracle Managed Files(OMF) が使用されるかどうかに応じて異なります ファイルが Oracle Managed Files ではない場合のスタンバイ データベースのセットアップ すべてのファイルが Oracle Managed Files の場合のスタンバイ データベースのセットアップ ファイルのサブセットが Oracle Managed Files の場合のスタンバイ データベースのセットアップ F.3.1 ファイルが Oracle Managed Files ではない場合のスタンバイ データベースのセットアップ OMF を使用しないスタンバイ データベースをセットアップする手順は 次のとおりです 1. オペレーティング システムのユーティリティを使用して SPFILE( または初期化パラメータ ファイル ) をターゲット ホストからスタンバイ ホストにコピーします 項で説明しているように スタンバイ データベースの初期化パラメータ ファイルの必須パラメータをすべて設定します たとえば 異なるディレクトリ構造を持つ異なるホスト上にスタンバイ データベースを作成する場合 次のパラメータを編集します _DEST および _PATH で終わるパラメータを編集し パス名を指定します すべてのターゲット データファイルを取得して適切に変換するように DB_FILE_ NAME_CONVERT を編集します たとえば tbs_* を sbytbs_* に変更します すべての REDO ログ ファイルを取得して適切に変換するように LOG_FILE_NAME_ CONVERT を編集します たとえば log_* を sbylog_* に変更します たとえば 次にスタンバイ データベース初期化パラメータ ファイルのサンプルのパラメータ設定を示します STANDBY_ARCHIVE_DEST = /fs3/arc_dest/ LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc DB_FILE_NAME_CONVERT = '/oracle', '/fs3/oracle', '/dbf', '/fs3/oracle' LOG_FILE_NAME_CONVERT = '/oracle', '/fs3/oracle' 2. SQL*Plus を使用して スタンバイ インスタンスをマウントせずに起動します たとえば SYS(SYSDBA 権限がある ) として sbdb1 に接続し データベースを起動するには 次のコマンドを入力します SQL> CONNECT SYS/sys_pwd@sbdb1 AS SYSDBA SQL> STARTUP NOMOUNT PFILE=initSBDB1.ora 3. プライマリ データベースがマウントまたはオープンされていない場合 SQL*Plus を使用してデータベースをマウントまたはオープンします たとえば SYS として prod1 に接続し データベースをオープンするには 次のコマンドを入力します SQL> CONNECT SYS/sys_pwd@prod1 AS SYSDBA SQL> STARTUP PFILE=initPROD1.ora リカバリ カタログ データベースがオープンされていることを確認します たとえば SYS として catdb に接続し リカバリ カタログ データベースをオープンするには 次のコマンドを入力します SQL> CONNECT SYS/oracle@catdb AS SYSDBA SQL> STARTUP PFILE=initCATDB.ora F-8 Oracle Data Guard 概要および管理

375 スタンバイ データベースの設定 4. スタンバイ サイト インスタンスは Oracle Net からアクセスできる必要があります 次の手順を実行する前に SQL*Plus を使用して スタンバイ インスタンスへの接続を確立できることを確認します スタンバイ インスタンスには SYSDBA 権限で接続する必要があるため パスワード ファイルが存在している必要があります 5. ターゲット データベース スタンバイ インスタンス およびリカバリ カタログ データベース ( 使用している場合 ) へ接続します プライマリ データベースは TARGET キーワードで指定し スタンバイ インスタンスは AUXILIARY キーワードで指定します 次の例では オペレーティング システムの認証を使用し リカバリ カタログなしで接続を確立します % rman TARGET / AUXILIARY SYS/sys_pwd@sbdb1 F.3.2 すべてのファイルが Oracle Managed Files の場合のスタンバイ データベースのセットアップ スタンバイ データベースですべてのファイルに OMF を使用する場合は Recovery Manager で複製を実行する前に スタンバイ データベースまたは補助インスタンスで次のパラメータを設定する必要があります データベース制御ファイルが OMF ファイルの場合は サーバー パラメータ ファイル (SPFILE) を使用することをお薦めします それ以外の場合は 次の手順に従って CONTROL_FILE 初期化パラメータを V$CONTROLFILE ビューの制御ファイル名列の値で更新してください 必須の初期化パラメータの変更 1. 複製データベース用に別の DB_NAME パラメータを設定し スタンバイ データベース用に別の DB_UNIQUE_NAME パラメータを設定します 2. LOG_FILE_NAME_CONVERT および DB_FILE_NAME_CONVERT パラメータは設定しません 3. CONTROL_FILE パラメータは設定しません ( データベース制御ファイルを OMF ファイルにする場合 ) 4. DB_CREATE_FILE_DEST パラメータを設定します ( すべてのデータファイル 制御ファイルおよびオンライン REDO ログが この宛先に作成されます ) 5. STANDBY_FILE_MANAGEMENT=AUTO パラメータを設定します ( スタンバイ データベースの複製のみ ) ALTER SYSTEM RESET 文を使用すると 手順 2 および 3 の SPFILE の初期化パラメータを消去できます 次に例を示します ALTER SYSTEM RESET CONTROL_FILE SCOPE=SPFILE SID='*' オプションの初期化パラメータの変更制御ファイルのコピー 1 つとオンライン REDO ログのメンバー 1 つが作成されるように DB_ CREATE_FILE_DEST パラメータを設定します 複数の制御ファイルおよびオンライン REDO ログ ファイルを作成するには 必要な多重コピーの数に応じて DB_CREATE_ONLINE_LOG_ DEST_n パラメータ (n は 1 ~ 5 の整数 ) を設定します 設定されている DB_CREATE_ ONLINE_LOG_DEST_n パラメータが 1 つの場合 DB_CREATE_FILE_DEST には制御ファイルとオンライン REDO ログ ファイルが作成されません たとえば DB_CREATE_ONLINE_ LOG_DEST_1 および DB_CREATE_ONLINE_LOG_DEST_2 を設定すると 各宛先に制御ファイルとオンライン REDO ファイルのコピーが 2 つ作成されます Recovery Manager を使用したスタンバイ データベースの作成 F-9

376 同一のディレクトリ構造のスタンバイ データベースの作成 F.3.3 ファイルのサブセットが Oracle Managed Files の場合のスタンバイ データベースのセットアップ プライマリ データベース ファイルの一部のみが OMF ファイルの場合 またはデータファイルが複数のディスク グループにまたがって散在している場合は まったく同じ構造を持つ複製データベースを作成できます たとえば 高速のデータファイルが +'FAST' ディスク グループにあり 低速のデータファイルが '+SLOW' ディスク グループにあるとします データベースの複製後 データファイルを '+FAST2' ディスク グループに置き 低速のデータファイルを '+SLOW2' ディスク グループに置く必要があるとします スタンバイ データベースを設定するには LOG_FILE_ NAME_CONVERT および DB_FILE_NAME_CONVERT パラメータを ('+FAST', '+FAST2', '+SLOW', '+SLOW2') として構成します データベースを同じディスク グループに異なる名前で置く必要がある場合は 名前の中間部分を変更します たとえば ('/boston/', '/sfo/') を使用します boston はプライマリ データベースの DB_UNIQUE_NAME で sfo は複製データベースの DB_UNIQUE_NAME です Recovery Manager で複製を実行する前に スタンバイ データベースまたは補助インスタンスで次の手順に従って初期化パラメータを設定します 必須の初期化パラメータの変更 1. 複製データベース用に別の DB_NAME パラメータを設定し スタンバイ データベース用に別の DB_UNIQUE_NAME パラメータを設定します 2. ファイル名を変換するように LOG_FILE_NAME_CONVERT および DB_FILE_NAME_ CONVERT パラメータを設定します 3. CONTROL_FILE パラメータを変更して新規制御ファイルを指定します F.4 同一のディレクトリ構造のスタンバイ データベースの作成 スタンバイ データベースの最も単純な作成方法は 異なるホストに作成し 同一のディレクトリ構造を使用することです この場合 スタンバイ初期化パラメータ ファイルで DB_ FILE_NAME_CONVERT または LOG_FILE_NAME_CONVERT パラメータを設定する必要がなく スタンバイ データファイルの新規のファイル名を設定する必要もありません プライマリおよびスタンバイ データファイル およびログ ファイルのファイル名は同じです F.4.1 リカバリを実行しないスタンバイ データベースの作成 リカバリを実行せずにスタンバイ データベースを作成する場合 DUPLICATE コマンドの DORECOVER オプションを指定しないでください デフォルトで Recovery Manager はスタンバイ データベースをマウントした状態にし リカバリを実行しません リカバリを実行せずにスタンバイ データベースを作成するには 次の手順を実行します 1. F.3 項 スタンバイ データベースの設定 の手順を実行します スタンバイ初期化パラメータ ファイルで必要なパラメータをすべて設定していることを確認してください 2. スタンバイ データファイルの作成のみ行い リカバリを実行しない場合 複製時に次の手順を実行します a. 自動チャネルが構成されていない場合 1 つ以上の補助チャネルを割り当てます このチャネルにより 複製作業が実行されます b. DUPLICATE コマンドで NOFILENAMECHECK を指定します スタンバイおよびプライマリ データファイル およびログ ファイルに同じ名前を使用する場合 NOFILENAMECHECK オプションは必須です 指定しない場合 Recovery Manager によりエラーが戻されます たとえば スタンバイ データベースを作成するには 次のコマンドを実行します DUPLICATE TARGET DATABASE FOR STANDBY NOFILENAMECHECK; F-10 Oracle Data Guard 概要および管理

377 同一のディレクトリ構造のスタンバイ データベースの作成 F.4.2 スタンバイ データベースの作成およびリカバリの実行 スタンバイ データベースを作成し リカバリを実行する場合 DUPLICATE コマンドの DORECOVER オプションを指定します スタンバイ データベースを作成し リカバリを実行するには 次の手順を実行します 1. F.3 項の手順を実行します スタンバイ初期化パラメータ ファイルで必要なパラメータをすべて設定していることを確認してください 2. スタンバイ データファイルのリストアおよびリカバリを実行するには 次の手順を実行します a. リカバリ終了時刻がスタンバイ制御ファイルのチェックポイント SCN 以上であり チェックポイント SCN が含まれているログ ファイルがリカバリ用に使用可能であることを確認します b. 必要に応じて SET コマンドを発行し 不完全リカバリの終了時刻 SCN またはログ順序番号を指定します c. 自動チャネルが構成されていない場合 1 つ以上の補助チャネルを手動で割り当てます d. DUPLICATE コマンドで NOFILENAMECHECK パラメータを指定し DORECOVER オプションを使用します たとえば 構成済チャネルを使用してスタンバイ データベースを作成するには Recovery Manager のプロンプトで次のコマンドを入力します # If desired, issue a LIST command to determine the SCN of the standby control file. # The SCN to which you recover must be greater than or equal to the standby control # file SCN. LIST BACKUP OF CONTROLFILE; LIST COPY OF CONTROLFILE; RUN { # If desired, issue a SET command to terminate recovery at a specified point. # SET UNTIL SCN ; DUPLICATE TARGET DATABASE FOR STANDBY NOFILENAMECHECK DORECOVER; } Recovery Manager により すべての増分バックアップ アーカイブ REDO ログ ファイルのバックアップおよびアーカイブ REDO ログ ファイルを使用した不完全リカバリが実行されます スタンバイ データベースはマウントされた状態になります Recovery Manager を使用したスタンバイ データベースの作成 F-11

378 異なるディレクトリ構造のスタンバイ データベースの作成 F.5 異なるディレクトリ構造のスタンバイ データベースの作成 異なるディレクトリ構造のホスト上にスタンバイ データベースを作成する場合 スタンバイ データベースのデータファイルおよび REDO ログ ファイルに新規のファイル名を指定する必要があります 次の方法があります スタンバイ初期化パラメータ ファイルで LOG_FILE_NAME_CONVERT パラメータを設定して スタンバイ データベースの REDO ログ ファイルをネーミングします LOG_ FILE_NAME_CONVERT を設定しない場合 DUPLICATE コマンドの NOFILENAMECHECK オプションを使用する必要があります スタンバイ初期化パラメータ ファイルで DB_FILE_NAME_CONVERT パラメータを設定して スタンバイ データファイルをネーミングします データファイルをネーミングするように Recovery Manager の DUPLICATE コマンドの使用時に SET NEWNAME コマンドまたは CONFIGURE AUXNAME コマンドを発行します 異なるディレクトリ構造のホスト上にスタンバイ データベースを作成する場合 次のいずれかの項の手順を実行します DB_FILE_NAME_CONVERT を使用したスタンバイ データベース ファイルのネーミング SET NEWNAME を使用したスタンバイ データベース ファイルのネーミング CONFIGURE AUXNAME を使用したスタンバイ データベース ファイルのネーミング SET NEWNAME および CONFIGURE AUXNAME の相違点については Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を フィジカル スタンバイ データベースの準備と作成の詳細は第 3 章を参照してください F.5.1 DB_FILE_NAME_CONVERT を使用したスタンバイ データベース ファイルのネーミング この手順では DB_FILE_NAME_CONVERT パラメータを使用してスタンバイ データファイルをネーミングし LOG_FILE_NAME_CONVERT パラメータを使用してスタンバイ データベースの REDO ログ ファイルをネーミングします DB_FILE_NAME_CONVERT および LOG_ FILE_NAME_CONVERT パラメータを使用したスタンバイ データベース ファイルのネーミングの例は 項を参照してください F リカバリを実行しないスタンバイ データベースの作成 リカバリを実行せずにスタンバイ データベースを作成する場合 DUPLICATE コマンドの DORECOVER オプションを指定しないでください デフォルトで Recovery Manager はスタンバイ データベースをマウントした状態にし リカバリを実行しません パラメータを使用して リカバリを実行せずにスタンバイ ファイルをネーミングするには 次の手順を実行します 1. F.3 項の手順を実行します スタンバイ初期化パラメータ ファイルで必要なパラメータをすべて設定していることを確認してください 2. DUPLICATE コマンドを実行します たとえば 次のコマンドを実行します DUPLICATE TARGET DATABASE FOR STANDBY; バックアップのリストア後 Recovery Manager はスタンバイ データベースをマウントした状態にします F スタンバイ データベースの作成およびリカバリの実行 DB_FILE_NAME_CONVERT パラメータを使用してスタンバイ データファイルをネーミングし LOG_FILE_NAME_CONVERT パラメータを使用してスタンバイ データベースのログ ファイルをネーミングした後 DUPLICATE コマンドの DORECOVER オプションを指定してスタンバイ データベースを作成し リカバリを実行します この場合の手順は F.4.2 項と同じです F-12 Oracle Data Guard 概要および管理

379 異なるディレクトリ構造のスタンバイ データベースの作成 F.5.2 SET NEWNAME を使用したスタンバイ データベース ファイルのネーミング この場合 SET NEWNAME コマンドを使用してスタンバイ データファイルをネーミングします F リカバリを実行しないスタンバイ データベースの作成 リカバリを実行せずにスタンバイ データベースを作成する場合 DUPLICATE コマンドの DORECOVER オプションを指定しないでください デフォルトで Recovery Manager はスタンバイ データベースをマウントした状態にし リカバリを実行しません リカバリを実行せずに SET NEWNAME コマンドを使用してスタンバイ データベース ファイルをネーミングするには 次の手順を実行します 1. F.3 項の手順を実行します スタンバイ初期化パラメータ ファイルで必要なパラメータをすべて設定していることを確認してください 2. DUPLICATE コマンドを実行します 次の手順に従ってください a. 自動チャネルが構成されていない場合 1 つ以上の補助チャネルを手動で割り当てます b. SET NEWNAME コマンドを使用して スタンバイ データベースのデータファイルの新規ファイル名を指定します c. DUPLICATE コマンドを発行します 次の例では 構成済チャネルを使用してスタンバイ データベースを作成します RUN { # set new file names for the data files SET NEWNAME FOR DATAFILE 1 TO '?/dbs/standby_data_01.f'; SET NEWNAME FOR DATAFILE 2 TO '?/dbs/standby_data_02.f';... # run the DUPLICATE command DUPLICATE TARGET DATABASE FOR STANDBY; } F スタンバイ データベースの作成およびリカバリの実行 スタンバイ データベースを作成し リカバリを実行する場合 DUPLICATE コマンドの DORECOVER オプションを指定します SET NEWNAME コマンドを使用してスタンバイ データベース ファイルをネーミングし リカバリを実行するには 次の手順を実行します 1. F.3 項の手順を実行します スタンバイ初期化パラメータ ファイルで必要なパラメータをすべて設定していることを確認してください 2. DUPLICATE コマンドを実行します 次の手順に従います a. リカバリ終了時刻がスタンバイ制御ファイルのチェックポイント SCN 以上であり チェックポイント SCN が含まれているログ ファイルがリカバリ用に使用可能であることを確認します (F.2.2 項で説明しています ) b. 必要に応じて SET コマンドを発行し 不完全リカバリの終了時刻 SCN またはログ順序番号を指定します c. 自動チャネルが構成されていない場合 1 つ以上の補助チャネルを手動で割り当てます d. スタンバイ データベースのデータファイル用に新規のファイル名を指定します e. DORECOVER オプションを指定して DUPLICATE コマンドを発行します Recovery Manager を使用したスタンバイ データベースの作成 F-13

380 異なるディレクトリ構造のスタンバイ データベースの作成 たとえば 構成済チャネルを使用してスタンバイ データベースを作成するには Recovery Manager のプロンプトで次のコマンドを入力します # If desired, issue a LIST command to determine the SCN of the standby control file. # The SCN to which you recover must be greater than or equal to the control file SCN. LIST BACKUP OF CONTROLFILE; LIST COPY OF CONTROLFILE; RUN { # If desired, issue a SET command to terminate recovery at a specified point. # SET UNTIL TIME 'SYSDATE-7'; # Set new file names for the data files SET NEWNAME FOR DATAFILE 1 TO '?/dbs/standby_data_01.f'; SET NEWNAME FOR DATAFILE 2 TO '?/dbs/standby_data_02.f';... DUPLICATE TARGET DATABASE FOR STANDBY DORECOVER; } Recovery Manager により すべての増分バックアップ アーカイブ REDO ログ ファイルのバックアップおよびアーカイブ REDO ログ ファイルを使用した不完全リカバリが実行されます スタンバイ データベースはマウントされた状態になります F.5.3 CONFIGURE AUXNAME を使用したスタンバイ データベース ファイルのネーミング この場合 CONFIGURE AUXNAME コマンドを使用してスタンバイ データファイルをネーミングします F リカバリを実行しないスタンバイ データベースの作成 リカバリを実行せずにスタンバイ データベースを作成する場合 DUPLICATE コマンドの DORECOVER オプションを指定しないでください デフォルトで Recovery Manager はスタンバイ データベースをマウントした状態にし リカバリを実行しません CONFIGURE AUXNAME を使用して リカバリを実行せずにスタンバイ データベース ファイルをネーミングするには 次の手順を実行します 1. F.3 項の手順を実行します スタンバイ初期化パラメータ ファイルで必要なパラメータをすべて設定していることを確認してください 2. データファイルの補助名を構成します たとえば 次のように入力します # set auxiliary names for the data files CONFIGURE AUXNAME FOR DATAFILE 1 TO '/oracle/auxfiles/aux_1.f'; CONFIGURE AUXNAME FOR DATAFILE 2 TO '/oracle/auxfiles/aux_2.f';... CONFIGURE AUXNAME FOR DATAFILE n TO '/oracle/auxfiles/aux_n.f'; F-14 Oracle Data Guard 概要および管理

381 異なるディレクトリ構造のスタンバイ データベースの作成 3. DUPLICATE コマンドを実行します 自動チャネルが構成されていない場合 次の例のように DUPLICATE コマンドを発行する前に 1 つ以上の補助チャネルを手動で割り当てます RUN { # allocate at least one auxiliary channel of type DISK or sbt ALLOCATE AUXILIARY CHANNEL standby1 DEVICE TYPE sbt;... # issue the DUPLICATE command DUPLICATE TARGET DATABASE FOR STANDBY; } 4. データファイルの補助名を誤って上書きしないように 指定を解除します たとえば Recovery Manager のプロンプトで 次のように入力します # un-specify auxiliary names for the data files CONFIGURE AUXNAME FOR DATAFILE 1 CLEAR; CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR;... CONFIGURE AUXNAME FOR DATAFILE n CLEAR; F スタンバイ データベースの作成およびリカバリの実行 スタンバイ データベースを作成し リカバリを実行する場合 DUPLICATE コマンドの DORECOVER オプションを指定します CONFIGURE AUXNAME を使用して スタンバイ ファイルをネーミングし リカバリを実行するには 次の手順を実行します 1. F.3 項の手順を実行します スタンバイ初期化パラメータ ファイルで必要なパラメータをすべて設定していることを確認してください 2. データファイルの補助名を設定します たとえば 次のコマンドを入力します # set auxiliary names for the data files CONFIGURE AUXNAME FOR DATAFILE 1 TO '/oracle/auxfiles/aux_1.f'; CONFIGURE AUXNAME FOR DATAFILE 2 TO '/oracle/auxfiles/aux_2.f';... CONFIGURE AUXNAME FOR DATAFILE n TO '/oracle/auxfiles/aux_n.f'; 3. DUPLICATE コマンドを実行します 次の手順に従います リカバリ終了時刻がスタンバイ制御ファイルのチェックポイント SCN 以上であり チェックポイント SCN が含まれているログ ファイルがリカバリ用に使用可能であることを確認します (F.2.2 項で説明しています ) 必要に応じて SET コマンドを発行し 不完全リカバリの終了時刻 SCN またはログ順序番号を指定します 自動チャネルが構成されていない場合 1 つ以上の補助チャネルを手動で割り当てます DUPLICATE TARGET DATABASE FOR STANDBY コマンドを発行します Recovery Manager を使用したスタンバイ データベースの作成 F-15

382 ローカル ホスト上へのスタンバイ データベースの作成 たとえば 構成済チャネルを使用してスタンバイ データベースを作成するには Recovery Manager のプロンプトで次のコマンドを入力します # If desired, issue a LIST command to determine the SCN of the standby control file. # The SCN to which you recover must be greater than or equal to the control file SCN. LIST BACKUP OF CONTROLFILE; LIST COPY OF CONTROLFILE; DUPLICATE TARGET DATABASE FOR STANDBY DORECOVER; Recovery Manager により すべての増分バックアップ アーカイブ REDO ログ ファイルのバックアップおよびアーカイブ REDO ログ ファイルを使用した不完全リカバリが実行されます スタンバイ データベースはマウントされた状態になります 4. データファイルの補助名を誤って上書きしないように 補助名の設定を消去します たとえば Recovery Manager のプロンプトで 次のように入力します # un-specify auxiliary names for the data files CONFIGURE AUXNAME FOR DATAFILE 1 CLEAR; CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR;... CONFIGURE AUXNAME FOR DATAFILE n CLEAR; F.6 ローカル ホスト上へのスタンバイ データベースの作成 プライマリ データベースと同一ホスト上にスタンバイ データベースを作成する場合 F.5 項で説明されている 異なるディレクトリ構造のリモート ホスト上への複製と同じ手順を実行します プライマリ データベースと同一ホスト上にスタンバイ データベースを作成する場合 次の制限事項に注意してください ターゲット データベースと同一の Oracle ホーム上にスタンバイ データベースを作成できますが 異なるホスト上でのファイル名の変換と同じ方法でファイル名を変換する必要があります つまり 同一の Oracle ホーム内のスタンバイ データベースを 異なるディレクトリ構造を持つ異なるホスト上のデータベースのように扱う必要があります スタンバイ データベース ファイルおよびプライマリ データベース ファイルが同一のマシンに存在する場合 これらに同じ名前を使用できません 両方のデータベースで DB_UNIQUE_NAME 初期化パラメータを設定する必要があります 注意 : プライマリ データベースと同一の Oracle ホーム内にスタンバイ データベースを作成する場合 NOFILENAMECHECK オプションを使用しないでください 使用すると ターゲット データベース ファイルを上書きしたり DUPLICATE コマンドでエラーが発生して失敗する可能性があります F-16 Oracle Data Guard 概要および管理

383 イメージ コピーを使用したスタンバイ データベースの作成 F.7 イメージ コピーを使用したスタンバイ データベースの作成 この項は 次の項目で構成されています 概要 コピーおよびデータファイルで同一の名前を使用する場合 コピーおよびデータファイルで異なる名前を使用する場合 F.7.1 概要 Recovery Manager のイメージ コピーを使用してスタンバイ データファイルを作成する際の主な制限事項は プライマリ ホストおよびスタンバイ ホスト上のデータファイルおよびアーカイブ REDO ログ ファイルのイメージ コピー ファイル名が同一であることが必要な点です たとえば プライマリ ホスト上のデータファイル 1 の名前が /oracle/dbs/df1.f であるとします Recovery Manager の COPY コマンドを使用してこのデータファイルを /data/df1.f にコピーする場合 このイメージ コピーは スタンバイ ホスト上で /data/df1.f という同一のファイル名で存在する必要があります そうでない場合 Recovery Manager はスタンバイ イメージ コピーのメタデータをリポジトリ内で検出できません スタンバイ ホストにイメージ コピーを移入する方法は 主に 2 種類あります ftp またはその他のユーティリティを使用した手動での送信 ネットワーク ファイル システム (NFS) の使用によるプライマリ ホストへのスタンバイ ディレクトリ構造のマウント NFS 方式を使用する場合 スタンバイ ホスト上のディレクトリにマップされるディレクトリを プライマリ ホスト上に作成できます この方式を使用する場合 両マシン上の NFS マウント ポイントのディレクトリ名が同一である必要があります たとえば プライマリ ホスト上の /data をスタンバイ ホスト上の /data にマップできますが プライマリ ホスト上の /data をスタンバイ ホスト上の /dir にマップすることはできません (UNIX のシンボリック リンクまたは Windows の論理ドライブなどの機能を使用した場合を除きます ) スタンバイ ホスト上のイメージ コピーのファイル名は プライマリ ホスト上のイメージ コピーと同じファイル名である必要があります ただし SET NEWNAME コマンドまたは DB_FILE_NAME_CONVERT 初期化パラメータを使用することにより スタンバイ データファイルに異なるパス名を指定することが可能です たとえば スタンバイ ホスト上のデータファイル 1 のイメージ コピーの名前が /data/df1.f であっても 初期化パラメータまたは Recovery Manager のコマンドを使用することにより スタンバイ制御ファイルでパス名 /oracle/sb/df1.f を指定できます 物理イメージ コピーの名前は 手動で変更できない点に注意してください DUPLICATE コマンドを実行すると Recovery Manager によってイメージ コピー /data/df1.f がリストアされ 初期化パラメータまたは Recovery Manager のコマンドの情報に基づき スタンバイ データファイル 1 が /oracle/sb/df1.f として作成されます 表 F-3 に 1 つのデータファイルでのスタンバイ データベースの作成に NFS を使用した 2 つの使用例を示します 表 F-3 イメージ コピーを使用したスタンバイ データベースの作成 : 使用例 NFS マウント ポイント /data ( 両ホストで同じ ) /data ( 両ホストで同じ ) プライマリ データファイルのファイル名 イメージ コピーのファイル名 スタンバイ データファイルのファイル名 /oracle/dbs/df1.f /data/df1.f /data/df1.f ( イメージ コピーと 同じパス名 ) /oracle/dbs/df1.f /data/df1.f /oracle/sb/df1.f ( イメージ コピーと 異なるパス名 ) 手順の詳細 F.7.2 項 コピーおよびデータファイルで同一の名前を使用する場合 を参照してください F.7.3 項 コピーおよびデータファイルで異なる名前を使用する場合 を参照してください Recovery Manager を使用したスタンバイ データベースの作成 F-17

384 イメージ コピーを使用したスタンバイ データベースの作成 表 F-3 では スタンバイ ディレクトリ構造がプライマリ ホストにマウントされており 両ホストのマウント ポイントが /data であることを前提としています プライマリ ホストがスタンバイ ホストのディレクトリ構造をマウントするため プライマリ ホスト上にイメージ コピー /data/df1.f を作成すると 実質的にはスタンバイ ホスト上にイメージ コピー /data/df1.f を作成することになります 最初の使用例では スタンバイ データファイルにイメージ コピーと同じファイル名を使用しています この場合は スタンバイ データベースの作成に Recovery Manager を使用する必要がないため 最も単純な例です まず プライマリ データファイルのファイル名 /oracle/dbs/df1.f をスタンバイ ファイル名 /data/df1.f に変換するように スタンバイ初期化パラメータ ファイルの DB_FILE_NAME_CONVERT パラメータを設定します その後 ファイルをスタンバイ ホストにコピーし スタンバイ データベースをマウントします 2 つ目の使用例では スタンバイ データファイルおよびイメージ コピーに異なるファイル名を使用しています このスタンバイ データベースを作成するには DUPLICATE コマンドを実行します DUPLICATE コマンドにより データファイル 1 のイメージ コピーがリストアされ SET NEWNAME コマンドまたは DB_FILE_NAME_CONVERT 初期化パラメータに基づいて名前が変更されます F.7.2 コピーおよびデータファイルで同一の名前を使用する場合 この手順では スタンバイ データファイルおよびプライマリ データファイルのイメージ コピーに同一のファイル名を使用していることを前提としています コピーおよびスタンバイ データファイルの名前が同一の場合にスタンバイ データベースを作成するには 次の手順を実行します 1. プライマリ データベース および必要に応じてリカバリ カタログ データベースに接続した後 プライマリ データベースをマウントします ただし オープンしないでください このとき データベースが正常にクローズされてからマウントが行われたことを確認します たとえば 次のように入力します RMAN> STARTUP MOUNT PFILE=init.ora; 2. スタンバイ データファイルのファイル名がプライマリ データファイルのファイル名から変換されるように スタンバイ初期化パラメータ ファイルで DB_FILE_NAME_ CONVERT が設定されていることを確認します 次に例を示します DB_FILE_NAME_CONVERT = '/oracle/dbs', '/dsk2/oracle' 3. すべてのデータファイルおよびスタンバイ制御ファイルをコピーします たとえば 次のように入力します COPY DATAFILE 1 TO '/dsk2/oracle/df_1.f', DATAFILE 2 TO '/dsk2/oracle/df_2.f', DATAFILE 3 TO '/dsk2/oracle/df_3.f', DATAFILE 4 to '/dsk2/oracle/df_4.f', DATAFILE 5 TO '/dsk2/oracle/df_5.f', DATAFILE 6 TO '/dsk2/oracle/df_6.f', DATAFILE 7 TO '/dsk2/oracle/df_7.f', DATAFILE 8 to '/dsk2/oracle/df_8.f', DATAFILE 9 TO '/dsk2/oracle/df_9.f', DATAFILE 10 TO '/dsk2/oracle/df_10.f', DATAFILE 11 TO '/dsk2/oracle/df_11.f', DATAFILE 12 to '/dsk2/oracle/df_12.f', CURRENT CONTROLFILE FOR STANDBY TO '/dsk2/oracle/cf.f'; 4. スタンバイ インスタンスを起動し スタンバイ制御ファイルをマウントします たとえば SQL*Plus を起動し 次のように入力します SQL> STARTUP NOMOUNT PFILE=/dsk2/oracle/dbs/initSTANDBY1.ora SQL> ALTER DATABASE MOUNT; F-18 Oracle Data Guard 概要および管理

385 イメージ コピーを使用したスタンバイ データベースの作成 F.7.3 コピーおよびデータファイルで異なる名前を使用する場合 この手順では スタンバイ データファイルおよびプライマリ データファイルのイメージ コピーに異なるファイル名を使用していることを前提としています F リカバリを実行しないスタンバイ データベースの作成 スタンバイ データベースを作成してリカバリを実行しない場合 DUPLICATE コマンドを実行する必要はありません デフォルトで Recovery Manager はスタンバイ データベースをマウントした状態にし リカバリを実行しません コピーおよびスタンバイ データファイルの名前が異なる場合に リカバリを実行せずにスタンバイ データベースを作成するには 次の手順を実行します 1. プライマリ データベース スタンバイ インスタンス および必要に応じてリカバリ カタログ データベースへ接続します たとえば 次のように入力します % rman TARGET sys/sys_pwd@prod1 AUXILIARY sys/sys_pwd@sbdb1 CATALOG rman/cat@catdb 2. プライマリ データベースをマウントします ただし オープンしないでください このとき データベースが正常にクローズされてからマウントが行われたことを確認します たとえば 次のように入力します STARTUP MOUNT PFILE=initPROD1.ora 3. スタンバイ データファイルのファイル名がプライマリ データファイルのファイル名から変換されるように スタンバイ データベースで DB_FILE_NAME_CONVERT 初期化パラメータを設定するか または SET NEWNAME コマンドを発行します たとえば DB_FILE_ NAME_CONVERT パラメータを次のように設定します DB_FILE_NAME_CONVERT = '/oracle/dbs', '/dsk2/oracle' 4. COPY コマンドを使用して すべてのデータファイルおよびスタンバイ制御ファイルをコピーします たとえば 次のコマンドを発行します COPY DATAFILE 1 TO '/dsk2/oracle/df_1.f', DATAFILE 2 TO '/dsk2/oracle/df_2.f', DATAFILE 3 TO '/dsk2/oracle/df_3.f', DATAFILE 4 to '/dsk2/oracle/df_4.f', DATAFILE 5 TO '/dsk2/oracle/df_5.f', DATAFILE 6 TO '/dsk2/oracle/df_6.f', DATAFILE 7 TO '/dsk2/oracle/df_7.f', DATAFILE 8 to '/dsk2/oracle/df_8.f', DATAFILE 9 TO '/dsk2/oracle/df_9.f', DATAFILE 10 TO '/dsk2/oracle/df_10.f', DATAFILE 11 TO '/dsk2/oracle/df_11.f', DATAFILE 12 to '/dsk2/oracle/df_12.f', CURRENT CONTROLFILE FOR STANDBY TO '/dsk2/oracle/cf.f'; # To ensure the control file checkpoint is archived, archive the # current redo log file SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; 5. 補助インスタンスを起動し スタンバイ制御ファイルをマウントします たとえば SQL*Plus を起動し 次のように入力します SQL> STARTUP MOUNT PFILE=/dsk2/oracle/dbs/initSTANDBY1.ora Recovery Manager を使用したスタンバイ データベースの作成 F-19

386 イメージ コピーを使用したスタンバイ データベースの作成 F スタンバイ データベースの作成およびリカバリの実行 スタンバイ データベースを作成し リカバリを実行する場合 DUPLICATE コマンドの DORECOVER オプションを指定します コピーおよびスタンバイ データファイルの名前が異なる場合に スタンバイ データベースを作成し リカバリを実行するには 次の手順を実行します 1. プライマリ データベース スタンバイ インスタンス および必要に応じてリカバリ カタログ データベースへ接続します たとえば 次のように入力します % rman TARGET sys/sys_pwd@prod1 AUXILIARY sys/sys_pwd@sbdb1 CATALOG rman/cat@catdb 2. プライマリ データベースをマウントします ただし オープンしないでください このとき データベースが正常にクローズされてからマウントが行われたことを確認します たとえば 次のように入力します STARTUP MOUNT PFILE=initPROD1.ora 3. スタンバイ データファイルのファイル名がプライマリ データファイルのファイル名から変換されるように スタンバイ初期化パラメータ ファイルで DB_FILE_NAME_ CONVERT 初期化パラメータを設定するか または SET NEWNAME コマンドを発行します たとえば DB_FILE_NAME_CONVERT パラメータを次のように設定します DB_FILE_NAME_CONVERT = '/oracle/dbs', '/dsk2/oracle' 4. DUPLICATE コマンドを実行します 次の手順に従います a. リカバリ終了時刻がスタンバイ制御ファイルのチェックポイント SCN 以上であり チェックポイント SCN が含まれているログ ファイルがリカバリ用に使用可能であることを確認します (F.2.2 項で説明しています ) b. 必要に応じて SET コマンドを発行し リカバリの終了時刻 SCN またはログ順序番号を指定します c. 自動チャネルが構成されていない場合 複製用に 1 つ以上の補助チャネルを手動で割り当てます d. すべてのデータファイルおよびスタンバイ制御ファイルをコピーします e. 現行のオンライン REDO ログ ファイルをアーカイブします f. DORECOVER オプションを指定して DUPLICATE コマンドを発行します たとえば 次のコマンドを入力します COPY DATAFILE 1 TO '/dsk2/oracle/df_1.f', DATAFILE 2 TO '/dsk2/oracle/df_2.f', DATAFILE 3 TO '/dsk2/oracle/df_3.f', DATAFILE 4 to '/dsk2/oracle/df_4.f', DATAFILE 5 TO '/dsk2/oracle/df_5.f', DATAFILE 6 TO '/dsk2/oracle/df_6.f', DATAFILE 7 TO '/dsk2/oracle/df_7.f', DATAFILE 8 to '/dsk2/oracle/df_8.f', DATAFILE 9 TO '/dsk2/oracle/df_9.f', DATAFILE 10 TO '/dsk2/oracle/df_10.f', DATAFILE 11 TO '/dsk2/oracle/df_11.f', DATAFILE 12 to '/dsk2/oracle/df_12.f', CURRENT CONTROLFILE FOR STANDBY TO '/dsk2/oracle/cf.f'; SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; DUPLICATE TARGET DATABASE FOR STANDBY DORECOVER; Recovery Manager により すべての増分バックアップ アーカイブ REDO ログ ファイルのバックアップおよびアーカイブ REDO ログ ファイルを使用した不完全リカバリが実行されます スタンバイ データベースはマウントされた状態になります F-20 Oracle Data Guard 概要および管理

387 使用例 F.8 使用例 この使用例では プライマリ データファイルのバックアップおよびイメージ コピーの両方を使用する複製を実行します この使用例の中で Recovery Manager によってデータファイルのバックアップおよびデータファイルのコピーの両方がスタンバイ ファイルに使用され さらに スタンバイ データベースのリカバリに増分バックアップおよびアーカイブ REDO ログ ファイルの両方が使用されることが示されています スタンバイ データベース環境について 次のことを前提とします プライマリ データベースは host1 スタンバイ データベースは host2 に存在します データベース prod1 には 30 のデータファイルが存在し データファイル 1 ~ 25 は /dev/rdsk### というパターンの名前を持つ RAW ディスク上にあり (### は 001 で始まり 025 で終了する数値 ) データファイル 26 ~ 30 は /primary/datafile ディレクトリに存在します 次のアクションを 1 週間にわたって実行します 1. 月曜日には 次の増分レベル 0 のデータベース バックアップを実行します BACKUP DEVICE TYPE sbt INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG; 2. 火曜日には データファイル 1 ~ 5 を host1 の /standby/datafile ディレクトリにコピーし BACKUP ARCHIVELOG ALL コマンドを実行します 3. 水曜日には データファイル 6 ~ 9 を host1 の /standby/datafile ディレクトリにコピーし BACKUP ARCHIVELOG ALL コマンドを実行します 4. 木曜日には 次の増分レベル 1 のデータベース バックアップを実行します BACKUP DEVICE TYPE sbt INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG; 5. 金曜日には データファイル 10 ~ 15 を host1 の /standby/datafile ディレクトリにコピーし BACKUP ARCHIVELOG ALL コマンドを実行します 6. 土曜日の朝には 次の Recovery Manager のコマンドを実行します COPY CURRENT CONTROLFILE FOR STANDBY TO '/standby/datafile/cf.f'; SQL 'ALTER SYSTEM ARCHIVELOG CURRENT'; BACKUP DEVICE TYPE sbt ARCHIVELOG ALL; 7. 土曜日の夜には host1 の /standby/datafile 内のすべてのイメージ コピーを host2 の /standby/datafile に FTP で送信し さらに host1 のすべてのログ ファイルを host2 に FTP で送信します また host2 にアクセス可能な prod1 のテープ バックアップも作成します 日曜日に スタンバイ データベースを作成し 土曜日のバックアップの時点までリカバリすることを決定します すべてのスタンバイ データファイルを host2 の /standby/datafile ディレクトリ内に格納することにします スタンバイ データファイルのネーミング方式を選択する必要があります DB_FILE_NAME_ CONVERT パラメータを使用して RAW ディスクのデータファイルの各パターンを変更することが可能です この場合 パラメータには 25 の値のペア ( 名前を変更する各 RAW ディスク ファイル名につき 1 つのペア ) を指定する必要があります かわりに RAW ディスク上の 25 のデータファイルには SET NEWNAME コマンドを使用し /primary/datafile 内の 5 つのデータファイルの名前を /standby/datafile に変換するためにのみ DB_FILE_NAME_ CONVERT パラメータを使用します イメージ コピーは host2 の /standby/datafile 内に存在しますが データファイル 1 ~ 15 のコピーしか作成していません ただし すべてのデータファイルの増分バックアップが存在するため これは問題ありません Recovery Manager では リストアにはバックアップよりもイメージ コピーを優先して使用しますが イメージ コピーが存在しない場合は バックアップがリストアされます したがって 次のスクリプトを実行します Recovery Manager を使用したスタンバイ データベースの作成 F-21

388 使用例 RUN { # run SET NEWNAME commands for data files 1-25 SET NEWNAME FOR DATAFILE 1 TO '/standy/datafile/df1.f'; SET NEWNAME FOR DATAFILE 2 TO '/standby/datafile/df2.f';... SET NEWNAME FOR DATAFILE 25 TO '/standby/datafile/df25.f'; DUPLICATE TARGET DATABASE FOR STANDBY DORECOVER; } Recovery Manager により 複製時に次のアクションが実行されます データファイル 1 ~ 15 のイメージ コピーが使用されます データファイル 16 ~ 30 のバックアップがリストアされます ( これらのデータファイルにはイメージ コピーが存在しないため ) 増分バックアップを使用してデータファイル 1 ~ 9 およびデータファイル 16 ~ 30 がリカバリされますが データファイル 10 ~ 15 のリカバリには使用されません これらのコピーは木曜日の増分レベル 1 バックアップの後 金曜日に作成されているためです バックアップされた最後のアーカイブ REDO ログ ファイルの時点までデータファイル 1 ~ 30 がリストアされ 必要に応じてアーカイブ REDO ログ ファイルが適用されます 最後のアーカイブ REDO ログ ファイルの時点まで アーカイブ REDO ログ ファイルがディスクに適用されます F-22 Oracle Data Guard 概要および管理

389 G アーカイブ トレースの設定 Oracle データベースは プライマリ データベースから受信したアーカイブ REDO ログ ファイルの監査証跡をトレース ファイルに書き込みます LOG_ARCHIVE_TRACE パラメータは ARCn プロセス LGWR プロセス プライマリ データベースでのフォアグラウンド プロセス およびスタンバイ データベースでの RFS プロセスと FAL サーバー プロセスによって生成されるトレース出力を制御します アーカイブ トレースの設定 G-1

390 LOG_ARCHIVE_TRACE 初期化パラメータ G.1 LOG_ARCHIVE_TRACE 初期化パラメータ スタンバイ サイトへのアーカイブを確認するには プライマリおよびスタンバイ初期化パラメータ ファイルに LOG_ARCHIVE_TRACE パラメータを設定します LOG_ARCHIVE_TRACE パラメータを設定すると Oracle データベースは 次のように監査証跡をトレース ファイルに書き込みます プライマリ データベースの場合 Oracle データベースは プライマリ データベース上のアーカイブ プロセス アクティビティ (ARCn プロセスとフォアグラウンド プロセス LGWR および FAL アクティビティ ) の監査証跡をトレース ファイルに書き込みます このトレース ファイルのファイル名は USER_DUMP_DEST 初期化パラメータで指定されます スタンバイ データベースの場合 Oracle データベースは スタンバイ データベース上のアーカイブ REDO ログ ファイルに関連する RFS プロセスと ARCn プロセス アクティビティの監査証跡をトレース ファイルに書き込みます このトレース ファイルのファイル名は USER_DUMP_DEST 初期化パラメータで指定されます G.2 トレース ファイルの位置の判別 データベースのトレース ファイルは 初期化パラメータ ファイル内で USER_DUMP_DEST パラメータで指定されたディレクトリ内にあります 位置を判別するには SQL*Plus を使用してプライマリおよびスタンバイ インスタンスに接続し SHOW 文を発行します 次に例を示します SQL> SHOW PARAMETER USER_DUMP_DEST NAME TYPE VALUE user_dump_dest string?/rdbms/log G.2.1 LOG_ARCHIVE_TRACE 初期化パラメータの設定 アーカイブ トレース パラメータの書式は次のとおりです trace_level は整数です LOG_ARCHIVE_TRACE=trace_level フィジカル スタンバイ データベースで LOG_ARCHIVE_TRACE パラメータの有効化 無効化または変更を行うには 次のような SQL 文を発行します SQL> ALTER SYSTEM SET LOG_ARCHIVE_TRACE=15; この例では LOG_ARCHIVE_TRACE パラメータを 15 に設定したため G.2.2 項で説明するように トレース レベルが および 8 に設定されます 次のアーカイブ REDO ログ ファイルをプライマリ データベースから受信したときに リモート ファイル サーバー (RFS) および ARCn プロセスによって生成されたトレース出力に影響するように 別のスタンバイ セッションから ALTER SYSTEM 文を発行します たとえば 次のように入力します SQL> ALTER SYSTEM SET LOG_ARCHIVE_TRACE=32; G-2 Oracle Data Guard 概要および管理

391 トレース ファイルの位置の判別 G.2.2 整数値の選択 LOG_ARCHIVE_TRACE パラメータの整数値は データのトレース レベルを表します 一般的には レベルが高いほど 情報が詳細になります 次の整数値を使用できます レベル意味 0 アーカイブ REDO ログのトレースを使用不可能にします ( デフォルト設定 ) 1 ログ ファイルのアーカイブを追跡します 2 アーカイブ ログ ファイルの宛先ごとにアーカイブ状況を追跡します 4 アーカイブ操作のフェーズを追跡します 8 アーカイブ ログの宛先のアクティビティを追跡します 16 アーカイブ ログの宛先の詳細なアクティビティを追跡します 32 アーカイブ ログの宛先のパラメータ修正を追跡します 64 ARCn プロセスの状態のアクティビティを追跡します 128 FAL サーバー プロセスのアクティビティを追跡します 256 RFS の論理的なクライアントを追跡します 512 LGWR の REDO 転送ネットワーク アクティビティを追跡します 1024 RFS の物理的なクライアントを追跡します 2048 RFS/ARCn の ping のハートビートを追跡します 4096 リアルタイム適用アクティビティを追跡します 8192 REDO Apply アクティビティ ( メディア リカバリまたはフィジカル スタンバイ ) を追跡します LOG_ARCHIVE_TRACE パラメータの値をいくつかのトレース レベルを合計した値に設定すると トレース レベルを組み合せることができます たとえば パラメータを 6 に設定すると レベル 2 とレベル 4 のトレース出力が生成されます 次に ログ ファイル 387 を 2 つの異なる宛先 ( サービス standby1 およびローカル ディレクトリ /oracle/dbs) にアーカイブすることによってプライマリ サイトに生成される ARC0 トレース データの例を示します 注意 : レベルの数値は実際のトレース出力には表示されません ここでは説明の目的で示してあります Level Corresponding entry content (sample) ( 1) ARC0: Begin archiving log# 1 seq# 387 thrd# 1 ( 4) ARC0: VALIDATE ( 4) ARC0: PREPARE ( 4) ARC0: INITIALIZE ( 4) ARC0: SPOOL ( 8) ARC0: Creating archive destination 2 : 'standby1' (16) ARC0: Issuing standby Create archive destination at 'standby1' ( 8) ARC0: Creating archive destination 1 : '/oracle/dbs/d1arc1_387.log' (16) ARC0: Archiving block 1 count 1 to : 'standby1' (16) ARC0: Issuing standby Archive of block 1 count 1 to 'standby1' (16) ARC0: Archiving block 1 count 1 to : '/oracle/dbs/d1arc1_387.log' ( 8) ARC0: Closing archive destination 2 : standby1 (16) ARC0: Issuing standby Close archive destination at 'standby1' ( 8) ARC0: Closing archive destination 1 : /oracle/dbs/d1arc1_387.log アーカイブ トレースの設定 G-3

392 トレース ファイルの位置の判別 ( 4) ARC0: FINISH ( 2) ARC0: Archival success destination 2 : 'standby1' ( 2) ARC0: Archival success destination 1 : '/oracle/dbs/d1arc1_387.log' ( 4) ARC0: COMPLETE, all destinations archived (16) ARC0: ArchivedLog entry added: /oracle/dbs/d1arc1_387.log (16) ARC0: ArchivedLog entry added: standby1 ( 4) ARC0: ARCHIVED ( 1) ARC0: Completed archiving log# 1 seq# 387 thrd# 1 (32) Propagating archive 0 destination version 0 to version 2 Propagating archive 0 state version 0 to version 2 Propagating archive 1 destination version 0 to version 2 Propagating archive 1 state version 0 to version 2 Propagating archive 2 destination version 0 to version 1 Propagating archive 2 state version 0 to version 1 Propagating archive 3 destination version 0 to version 1 Propagating archive 3 state version 0 to version 1 Propagating archive 4 destination version 0 to version 1 Propagating archive 4 state version 0 to version 1 (64) ARCH: changing ARC0 KCRRNOARCH->KCRRSCHED ARCH: STARTING ARCH PROCESSES ARCH: changing ARC0 KCRRSCHED->KCRRSTART ARCH: invoking ARC0 ARC0: changing ARC0 KCRRSTART->KCRRACTIVE ARCH: Initializing ARC0 ARCH: ARC0 invoked ARCH: STARTING ARCH PROCESSES COMPLETE ARC0 started with pid=8 ARC0: Archival started 次に示すトレース データは スタンバイ サイトで ディレクトリ /stby にアーカイブ REDO ログ ファイル 387 を受信し それをスタンバイ データベースに適用する RFS プロセスによって生成されたものです level trace output (sample) ( 4) RFS: Startup received from ARCH pid 9272 ( 4) RFS: Notifier ( 4) RFS: Attaching to standby instance ( 1) RFS: Begin archive log# 2 seq# 387 thrd# 1 (32) Propagating archive 5 destination version 0 to version 2 (32) Propagating archive 5 state version 0 to version 1 ( 8) RFS: Creating archive destination file: /stby/parc1_387.log (16) RFS: Archiving block 1 count 11 ( 1) RFS: Completed archive log# 2 seq# 387 thrd# 1 ( 8) RFS: Closing archive destination file: /stby/parc1_387.log (16) RFS: ArchivedLog entry added: /stby/parc1_387.log ( 1) RFS: Archivelog seq# 387 thrd# 1 available 04/02/99 09:40:53 ( 4) RFS: Detaching from standby instance ( 4) RFS: Shutdown received from ARCH pid 9272 G-4 Oracle Data Guard 概要および管理

393 索引 A AFFIRM 属性,5-21,14-2 ALTER DATABASE 文 ABORT LOGICAL STANDBY 句,15-4 ACTIVATE STANDBY DATABASE 句,7-10,7-18, 10-7,12-32,12-40,15-4 ACTIVATE STANDBY DATABASE 文,12-32 ADD STANDBY LOGFILE GROUP 句,3-4 ADD STANDBY LOGFILE MEMBER 句,5-25,15-2, A-2 ADD STANDBY LOGFILE 句,3-4,8-14,15-2,A-2 ADD SUPPLEMENTAL LOG DATA 句,15-2 ALTER STANDBY LOGFILE GROUP 句,3-4 ALTER STANDBY LOGFILE 句,3-4 CLEAR UNARCHIVED LOGFILES 句,8-17 COMMIT TO SWITCHOVER 句,7-8,7-12,7-16, 12-41,12-42,15-2 Real Application Clusters,D-7 トラブルシューティング,A-5,A-7 CREATE CONTROLFILE 句,8-16 CREATE DATAFILE AS 句,A-2 CREATE STANDBY CONTROLFILE 句,3-8,A-3 REUSE 句,15-2 DROP LOGFILE 句,A-2 DROP STANDBY LOGFILE MEMBER 句,15-2,A-2 FORCE LOGGING 句,2-6,3-2,12-43,15-2 MOUNT STANDBY DATABASE 句,15-3 OPEN READ ONLY 句,15-3 OPEN RESETLOGS 句,3-8,8-17 PREPARE TO SWITCHOVER 句,7-14,7-15,15-3 RECOVER MANAGED STANDBY DATABASE 句, 3-12,4-8,6-4,8-6,12-16,12-40,15-3 REDO Apply の制御,6-5 スイッチオーバーの使用例,12-41 遅延間隔の上書き,6-4,14-8 取消し,6-6 バックグラウンド プロセス,6-5,8-2 フェイルオーバー,15-4 フェイルオーバーの開始,7-11 フォアグラウンド セッション,6-5 リアルタイム適用の開始,6-5 ログ適用サービスの取消し,8-6 REGISTER LOGFILE 句,15-3,A-5 REGISTER LOGICAL LOGFILE 句,12-19 RENAME FILE 句,8-12,A-2 SET STANDBY DATABASE 句 TO MAXIMIZE AVAILABILITY 句,15-3 TO MAXIMIZE PERFORMANCE 句,7-6 TO MAXIMIZE PROTECTION 句,15-3 START LOGICAL STANDBY APPLY 句,6-6,7-19, 11-7,A-9 IMMEDIATE キーワード,6-6,9-15 NEW PRIMARY キーワード,7-19 SQL Apply の開始,4-8 STOP LOGICAL STANDBY APPLY 句,6-6,7-18, 11-6,12-19,15-4 ALTER SESSION DISABLE GUARD 文データベース ガードのオーバーライド,9-17 ALTER SESSION GUARD DISABLE データベース リンクを定義するためのデータベース ガードの無効化,7-18 ALTER SESSION 文 GUARD ENABLE 句,15-4 ALTER SYSTEM 文 ARCHIVE LOG CURRENT 句,3-12,3-13,12-21, 12-22,12-23,12-24,12-31,12-42 ALTER TABLESPACE 文,8-12,12-44,A-12 FORCE LOGGING 句,8-14 ALTERNATE 属性,14-4 LOG_ARCHIVE_DEST_n 初期化パラメータ,A-4 LOG_ARCHIVE_DEST_STATE_n 初期化パラメータ, 5-4 ANALYZER プロセス,9-2 APPLIED_SCN 列 V$LOGSTDBY_PROGRESS ビュー,12-18 APPLIER プロセス,9-3 AQ_TM_PROCESSES 動的パラメータ,A-6 ARCHIVE LOG CURRENT 句 ALTER SYSTEM の,3-12,3-13,12-21,12-22, 12-23,12-24,12-31,12-42 ARCHIVELOG モードソフトウェア要件,2-6 ARCH 属性,14-6 LOG_ARCHIVE_DEST_n 初期化パラメータデータ保護の設定,5-21 ARCn プロセス アーカイバ プロセス (ARCn) を参照 ASM 自動ストレージ管理 (ASM) を参照 Asynchronous AutoLog,5-3 ASYNC 属性,14-23 LOG_ARCHIVE_DEST_n 初期化パラメータデータ保護の設定,5-21 索引 -1

394 B BACKUP INCREMENTAL FROM SCN コマンド使用例,12-34 BFILE データ型ロジカル スタンバイ データベース,C-2 BINARY_DEGREE データ型ロジカル スタンバイ データベース,C-2 BINARY_FLOAT データ型ロジカル スタンバイ データベース,C-2 BLOB データ型ロジカル スタンバイ データベース,C-2 BUILDER プロセス,9-2 C CANCEL オプション管理リカバリと,8-3 CHAR データ型ロジカル スタンバイ データベース,C-2 CJQ0 プロセス,A-6 CLEAR UNARCHIVED LOGFILES 句 ALTER DATABASE の,8-7,8-17 CLOB データ型ロジカル スタンバイ データベース,C-2 COMMIT TO SWITCHOVER TO PRIMARY 句 ALTER DATABASE の,7-16 COMMIT TO SWITCHOVER 句 ALTER DATABASE の,7-8,7-12,7-16,12-41, 12-42,15-2 Real Application Clusters,D-7 トラブルシューティング,A-5,A-7 COMPATIBLE 初期化パラメータアーカイブ REDO ログ ファイルのディレクトリ位置に対する影響,5-23 ローリング アップグレード用の設定,11-2,11-3, Context サポートされないデータ型,C-2 Context データ型ロジカル スタンバイ データベース,C-2 CONTROL_FILE_RECORD_KEEP_TIME 初期化パラメータ,5-26 COORDINATOR プロセス,9-2 LSP バックグラウンド プロセス,9-2 CREATE CONTROLFILE 句 ALTER DATABASE の,8-16 CREATE DATABASE 文 FORCE LOGGING 句,12-43 CREATE DATAFILE AS 句 ALTER DATABASE の,A-2 CREATE RESTORE POINT コマンド,12-31 CREATE RESTORE POINT 文クローン データベースのアクティブ化,12-31 CREATE STANDBY CONTROLFILE 句 ALTER DATABASE の,3-8,15-2,A-3 CREATE TABLE AS SELECT(CTAS) 文ロジカル スタンバイ データベースで適用,9-5 D Data Guard Broker カスケードされた宛先,E-2 スイッチオーバー,7-1 定義,1-6 ファスト スタート フェイルオーバー,1-6 フェイルオーバー,1-6 手動,1-6,7-1 ファスト スタート,7-1 分散管理フレームワーク,7-1 Data Guard 構成 Oracle Database ソフトウェアのアップグレード,B-1 REDO 転送サービス,5-2 アーカイブ プロセスを使用したスタンバイ宛先へのアーカイブ,5-5 定義,1-2 保護モード,1-8 ログ ライター プロセスを使用したスタンバイ宛先へのアーカイブ,5-12,6-3 Data Pump ユーティリティフィジカル スタンバイ データベースでのトランスポータブル表領域の使用,8-12 DATE データ型ロジカル スタンバイ データベース,C-2 DB_FILE_NAME_CONVERT オプション Recovery Manager の DUPLICATE コマンド,F-5 DB_FILE_NAME_CONVERT 初期化パラメータトランスポータブル表領域の位置,8-12 DB_NAME 初期化パラメータ,3-6 DB_RECOVERY_FILE_DEST_SIZE 初期化パラメータクローン データベース用の設定,12-31 DB_RECOVERY_FILE_DEST 初期化パラメータクローン データベース用の設定,12-31 リカバリ領域の設定,5-6 DB_ROLE_CHANGE システム イベント,7-5,7-7 DB_UNIQUE_NAME 初期化パラメータ,A-7 LOG_ARCHIVE_CONFIG パラメータとともに必須, 13-3 共有フラッシュ リカバリ領域に必須,5-8 データベース初期化パラメータの設定,3-5 DB_UNIQUE_NAME 属性,14-7 DBA_DATA_FILES ビュー,8-16 DBA_LOGMNR_PURGED_LOG ビュー削除できるアーカイブ REDO ログ ファイルのリスト,9-14 DBA_LOGSTDBY_EVENTS ビュー,9-5,16-1,A-9 ロジカル スタンバイの取得,11-3 DBA_LOGSTDBY_HISTORY ビュー,16-1 DBA_LOGSTDBY_LOG ビュー,9-6,16-1 アーカイブ REDO ログ ファイルのリスト,12-18 ロジカル スタンバイ データベースでのギャップの検出,5-31 DBA_LOGSTDBY_NOT_UNIQUE ビュー,16-1 DBA_LOGSTDBY_PARAMETERS ビュー,16-1 DBA_LOGSTDBY_SKIP_TRANSACTION ビュー,16-1 DBA_LOGSTDBY_SKIP ビュー,16-1 スキーマに対する SQL Apply サポートの判断,C-4 DBA_LOGSTDBY_UNSUPPORTED ビュー,16-1,C-4 DBA_TABLESPACES ビュー,8-16 DBMS_ALERT,C-3 DBMS_AQ,C-3 DBMS_DESCRIBE,C-3 索引 -2

395 DBMS_JAVA,C-3 DBMS_JOB,C-3 DBMS_LOB,C-3 DBMS_LOGSTDBY.APPLY_SET プロシージャアーカイブ REDO ログ ファイルの適用遅延,6-4 DBMS_LOGSTDBY.BUILD サブプログラムフラッシュバック問合せの使用,4-6 DBMS_LOGSTDBY.BUILD プロシージャ REDO データでのディクショナリの構築,4-6 DBMS_LOGSTDBY パッケージ INSTANTIATE_TABLE プロシージャ,9-19 SKIP_ERROR プロシージャ,A-4 SKIP_TRANSACTION プロシージャ,A-9 SKIP プロシージャ,A-9 DBMS_LOGSTDBY プロシージャ DBA_LOGSTDBY_EVENTS 表内のイベントの取得, 11-3 DBMS_METADATA,C-3 DBMS_OBFUSCATION_TOOLKIT,C-3 DBMS_OUTPUT,C-3 DBMS_PIPE,C-3 DBMS_RANDOM,C-3 DBMS_REDEFINITION,C-3 DBMS_REFRESH,C-3 DBMS_REGISTRY,C-3 DBMS_SCHEDULER,C-3 DBMS_SPACE_ADMIN,C-3 DBMS_SQL,C-3 DBMS_TRACE,C-3 DBMS_TRANSACTION,C-3 DBSNMP プロセス,A-6 DDL トランザクションロジカル スタンバイ データベースで適用,9-5 ロジカル スタンバイ データベースへの適用,9-5 DDL 文 SQL Apply によるサポート,C-1 DEFER 属性 LOG_ARCHIVE_DEST_STATE_n 初期化パラメータ, 5-4,12-42 DELAY オプション ALTER DATABASE RECOVER MANAGED STANDBY DATABASE の取消し,6-4 DELAY 属性,14-8 LOG_ARCHIVE_DEST_n 初期化パラメータ,6-4, DEPENDENCY 属性,14-10 LOG_ARCHIVE_DEST_n 初期化パラメータ,5-27 DG_CONFIG 属性,14-7 LOG_ARCHIVE_CONFIG 初期化パラメータ,5-21 DGMGRL コマンドライン インタフェーススイッチオーバーの単純化,1-6,7-1 フェイルオーバーの起動,1-6,7-1 DISCONNECT FROM SESSION,8-2 DML ロジカル スタンバイ データベースでのバッチ更新,9-4 DML トランザクションロジカル スタンバイ データベースへの適用,9-4 DROP STANDBY LOGFILE MEMBER 句 ALTER DATABASE の,15-2,A-2 DROP STANDBY LOGFILE 句 ALTER DATABASE の,A-2 E ENABLE 属性 LOG_ARCHIVE_DEST_STATE_n 初期化パラメータ, 5-4,12-42 F FAL_CLIENT 初期化パラメータ,5-29 FAL_SERVER 初期化パラメータ,5-29 FORCE LOGGING 句 ALTER DATABASE の,2-6,3-2,12-43,15-2 ALTER TABLESPACE の,8-14 CREATE DATABASE の,12-43 FORCE キーワード RECOVER MANAGED STANDBY DATABASE FINISH,7-11 G GUARD DISABLE 句 ALTER SESSION,7-18 GUARD ENABLE 句 ALTER SESSION,15-4 GV$INSTANCE ビュー,D-7 GV$ 固定ビュー,8-17 ビュー も参照 I Image データ型ロジカル スタンバイ データベース,C-2 INITIALIZING 状態,9-11 INSTANTIATE_TABLE プロシージャ DBMS_LOGSTDBY の,9-19 INTERVAL データ型ロジカル スタンバイ データベース,C-2 J JOB_QUEUE_PROCESSES 動的パラメータ,A-6 L LGWR 属性,14-6 LOG_ARCHIVE_DEST_n 初期化パラメータデータ保護の設定,5-21 非同期 REDO 転送,5-13,14-6,14-23 LGWR プロセス ログ ライター プロセス (LGWR) を参照 listener.ora ファイル REDO 転送サービス調整,A-10 構成,3-11 トラブルシューティング,12-42,A-3,A-10 LOCATION 属性,14-12 設定 LOG_ARCHIVE_DEST_n 初期化パラメータ,A-4 フラッシュ リカバリ領域の設定に USE_DB_ RECOVERY_FILE_DEST を使用,5-7 索引 -3

396 LOG_ARCHIVE_CONFIG 初期化パラメータ,3-5,3-6, 3-9,5-17,13-3 DB_UNIQUE_NAME パラメータとの関係,13-3 DG_CONFIG 属性,5-21 DG_CONFIG 属性との関係,14-7 定義済の一意のデータベース名のリスト表示,16-2 例,14-7 LOG_ARCHIVE_DEST_10 初期化パラメータデフォルトのフラッシュ リカバリ領域,5-6,5-7, LOG_ARCHIVE_DEST_n 初期化パラメータ,5-11 AFFIRM 属性,5-21,14-2 ALTERNATE 属性,14-4,A-4 ARCH 属性,5-21,14-6 ASYNC 属性,14-23 データ保護の設定,5-21 DB_UNIQUE_NAME 属性,14-7 DELAY 属性,6-4,12-39,14-8 DEPENDENCY 属性,5-27,14-10 LGWR 属性,14-6 データ保護の設定,5-21 LOCATION 属性,14-12,A-4 MANDATORY 属性,14-14 MAX_CONNECTIONS 属性,14-16 MAX_FAILURE 属性,14-17 NET_TIMEOUT 属性,14-19 NOAFFIRM 属性,14-2 NOALTERNATE 属性,A-4 NODELAY 属性,6-4 NOREGISTER 属性,14-21 NOREOPEN 属性,5-18 OPTIONAL 属性,14-14 QUOTA_SIZE 属性,D-5 REGISTER 属性,14-21 REOPEN 属性,5-18,14-22 SERVICE 属性,14-12 SYNC 属性,14-23 データ保護の設定,5-21 TEMPLATE 属性,14-24 VALID_FOR 属性,5-16,14-26 VERIFY 属性,14-28 概要,5-4 廃止になった属性,14-1 リカバリ領域の設定,5-6 LOG_ARCHIVE_DEST_STATE_n 初期化パラメータ, 5-4 ALTERNATE 属性,5-4 DEFER 属性,5-4,12-42 ENABLE 属性,5-4,12-42 RESET 属性,5-4 LOG_ARCHIVE_FORMAT 初期化パラメータ,5-23 LOG_ARCHIVE_MIN_SUCCEED_DEST 初期化パラメータ,14-14 LOG_ARCHIVE_TRACE 初期化パラメータ,5-33,G-2, G-3 LogMiner ディクショナリ DBMS_LOGSTDBY.BUILD プロシージャを使用した構築,4-6 ロジカル スタンバイ データベースの作成時,4-6 LONG RAW データ型ロジカル スタンバイ データベース,C-2 LONG データ型ロジカル スタンバイ データベース,C-2 M MANDATORY 属性,14-14 LOG_ARCHIVE_DEST_n 初期化パラメータ,5-24 MAX_CONNECTIONS 属性,14-16 MAX_FAILURE 属性,14-17 MOUNT STANDBY DATABASE 句 ALTER DATABASE の,15-3 MRP 管理リカバリ プロセス を参照 N NCHAR データ型ロジカル スタンバイ データベース,C-2 CLOB データ型ロジカル スタンバイ データベース,C-2 NET_TIMEOUT 属性,14-19 LGWR ASYNC 宛先の場合は無視,5-14 NEWEST_SCN 列 V$LOGSTDBY_PROGRESS ビュー,12-18 NOAFFIRM 属性,14-2 NOALTERNATE 属性 LOG_ARCHIVE_DEST_n 初期化パラメータ,A-4 NODELAY オプション REDO Apply 操作,12-41 NODELAY 属性 LOG_ARCHIVE_DEST_n 初期化パラメータ,6-4 NOREGISTER 属性,14-21 NOREOPEN 属性 LOG_ARCHIVE_DEST_n 初期化パラメータ,5-18 NUMBER データ型ロジカル スタンバイ データベース,C-2 NVARCHAR2 データ型ロジカル スタンバイ データベース,C-2 O OMF Oracle Managed Files(OMF) を参照 OPEN READ ONLY 句 ALTER DATABASE の,15-3 OPEN RESETLOGS 後のフラッシュバック,12-28 OPEN RESETLOGS 句 ALTER DATABASE の,3-8,8-17 データベース インカネーションの変更,8-15 リカバリ,8-15 Optimal Flexible Architecture(OFA) ディレクトリ構造,2-7 OPTIONAL 属性,14-14 LOG_ARCHIVE_DEST_n 初期化パラメータ,5-24 ORA メッセージスイッチオーバー障害の原因となる,A-7 Oracle Advanced Security セキュアな REDO の転送の提供,5-15 Oracle Automatic Storage Management(ASM),2-7 Oracle Change Data Capture のアーカイブ,5-3 Oracle Database SQL Apply を使用したアップグレード,11-2 SQL Apply を使用したアップグレードの要件,11-2 アップグレード,2-6,B-2 Oracle Database Enterprise Edition ソフトウェア要件,2-6 索引 -4

397 Oracle Enterprise Manager スイッチオーバーの起動,1-6,7-1 フェイルオーバーの起動,1-6,7-1 Oracle Managed Files(OMF),2-7 使用するスタンバイ データベースの作成,12-51, F-8,F-9 Oracle Net Data Guard 構成のデータベース間の通信,1-2 Oracle Recovery Manager ユーティリティ (RMAN) フィジカル スタンバイ データベースのバックアップ ファイルの作成,10-1 Oracle Standard Edition スタンバイ データベース環境の再現,2-6 Oracle Streams アーカイブ,5-3 ダウンストリーム取得データベース,5-3 P PARALLEL_MAX_SERVERS 初期化パラメータ指定ロジカル スタンバイ データベースの作成, 8-25,13-4 PARALLEL オプション REDO Apply のログ適用レートのチューニング,8-25 PL/SQL パッケージサポートされない,C-3 サポートされる,C-3 PREPARE TO SWITCHOVER 句 ALTER DATABASE の,7-14,7-15,15-3 PREPARER プロセス,9-2 SGA 内での LCR のステージング,9-2 Q QMN0 プロセス,A-6 QUOTA_SIZE 属性 LOG_ARCHIVE_DEST_n 初期化パラメータ,D-5 R RAW データ型ロジカル スタンバイ データベース,C-2 RAW デバイススタンバイ REDO ログ ファイルの常駐,2-10 READER プロセス,9-2 Real Application Clusters,D-3 Data Guard を補完する特性,1-9 インスタンス間アーカイブ,D-3 スイッチオーバーの実行と,D-6 スタンバイ REDO ログの使用,2-10 スタンバイ REDO ログ ファイルの使用,3-4,D-4 スタンバイ データベースと,1-2,D-2,D-4 設定最大データ保護,D-6 プライマリ データベース,1-2,D-3,D-4 RECOVER MANAGED STANDBY DATABASE CANCEL 句中止,4-6 RECOVER MANAGED STANDBY DATABASE 句 ALTER DATABASE の,3-12,4-8,6-4,6-5,8-6, 12-16,12-40,15-3,15-4 REDO Apply の制御,6-5 スイッチオーバーの使用例,12-41 遅延間隔の上書き,6-4,14-8 バックグラウンド プロセス,6-5,8-2 フェイルオーバーの開始,7-11 フォアグラウンド セッション,6-5 リアルタイム適用の開始,6-5 DELAY 制御オプションの取消し,6-4 FORCE キーワード,7-11 RECOVER TO LOGICAL STANDBY 句フィジカル スタンバイ データベースからロジカル スタンバイ データベースへの変換,4-6 Recovery Manager Data Guard を補完する特性,1-10 DUPLICATE コマンドの DB_FILE_NAME_ CONVERT オプション,F-5 コマンド DUPLICATE,F-2 スタンバイ データベース DB_FILE_NAME_CONVERT 初期化パラメータ, F-5 LOG_FILE_NAME_CONVERT 初期化パラメータ,F-5 OMF を使用したセットアップ,F-8,F-9 Recovery Manager およびスタンバイ インスタンスの起動,F-8 Recovery Manager の準備,F-2 イメージ コピーを使用した作成,F-17 作成,F-2,F-6 スタンバイ制御ファイルの作成,F-3 スタンバイ データファイルのネーミング,F-4 増分バックアップ,12-34 データファイルの小さいサブセットに対するロギングなし変更適用時のデータベースのロールフォワード,12-36 ロギングなしの変更が広範囲にある場合のデータベースのロールフォワード,12-38 フィジカル スタンバイ データベースのロールフォワード,12-34 Recovery Manager の使用イメージ コピーの使用,F-17 REDO Apply アーカイブ ギャップの解決,5-30 オプション NODELAY,12-41 開始,3-12,6-5 監視,8-23 定義,1-4,2-2,6-2 停止,8-3 テクノロジ,1-4 パラレル リカバリ プロセスと MRP,5-10 フェイルオーバー後のフラッシュバック,12-25, 読取り / 書込みテストとレポート生成,12-30 ロールの推移とカスケードされた構成,E-5 ログ適用レートのチューニング,8-25 索引 -5

398 REDO データ検証,1-10 手動による転送,2-6 スタンバイ システムでのアーカイブ,1-4,6-2 ディクショナリの構築,4-6 適用 REDO Apply テクノロジの使用,1-4 SQL Apply テクノロジの使用,1-5 スタンバイ データベースへ,1-2,6-2 転送,1-2,1-4,5-1 ~ 5-19 フィジカル スタンバイ データベースからロジカル スタンバイ データベースヘの変換中の適用,4-6 REDO 転送サービス,5-2 ~ 5-33 アーカイブ REDO ログ ファイル V$ARCHIVED_LOG ビューでリストを表示,5-24 ディレクトリ位置の指定,5-23 ファイル名の生成,5-23 アーカイブ先 LOG_ARCHIVE_DEST_n 初期化パラメータで指定,5-5 Oracle Change Data Capture,5-3 Oracle Streams,5-3 アーカイブ REDO ログ リポジトリ,5-3 共有,5-27,14-10 失敗した宛先への再アーカイブ,5-18,14-22 代替,A-4 ロール固有,5-16 割当て制限,D-5 アーカイブ障害の処理,5-18,14-22 監視,5-32,5-33 スタンバイ REDO ログ ファイル構成,3-3 セキュアな REDO の転送,5-15 定義,1-4,5-2 同期および非同期ディスク I/O,14-2 ネットワーク ASYNC ネットワーク転送,5-11 SYNC ネットワーク転送,5-11 調整,A-10 保護モード最大可用性モード,1-8,5-20 最大パフォーマンス モード,1-8,5-20 最大保護モード,1-8,5-20 設定,5-21 選択,5-20 非データ消失の実現,5-11 ログ ライター プロセスの使用,5-13,14-6,14-23 REDO ログ Data Guard 構成内,2-9 構成上の考慮事項,2-10 スタンバイ データベース表の更新,1-10 セキュアな REDO の転送,5-15 フィジカル スタンバイ データベースでの自動適用,6-5 REDO ログ ファイル適用の遅延,6-4 REGISTER LOGFILE 句,5-30,5-31 ALTER DATABASE の,15-3,A-5 欠落しているログ ファイルの登録,5-30,5-31 REGISTER LOGICAL LOGFILE 句,12-20 ALTER DATABASE の,5-31,7-17,12-19 REGISTER 属性,14-21 RELY 制約作成,4-3 REMOTE_LOGIN_PASSWORDFILE 初期化パラメータセキュアな REDO の転送,5-15 RENAME FILE 句 ALTER DATABASE の,A-2 REOPEN 属性,14-22 LOG_ARCHIVE_DEST_n 初期化パラメータ,5-18 RESETLOGS_ID 列 V$DATABASE_INCARNATION ビューでの表示, 8-19 RESET 属性 LOG_ARCHIVE_DEST_STATE_n 初期化パラメータ, 5-4 RFS リモート ファイル サーバー プロセス (RFS) を参照 RMAN BACKUP INCREMENTAL FROM SCN コマンド, ROWID データ型ロジカル スタンバイ データベース,C-2 S SCN 増分バックアップに使用,12-34 適用可能な最大の ( 最新の ) 判断,12-17 SERVICE 属性,14-12 SET STANDBY DATABASE 句 ALTER DATABASE の,7-6,15-3 ALTER DATA の,15-3 SKIP_ERROR プロシージャ DBMS_LOGSTDBY パッケージ,A-4 SKIP_TRANSACTION プロシージャ DBMS_LOGSTDBY の,A-9 SKIP プロシージャ DBMS_LOGSTDBY の,A-9 Spatial データ型ロジカル スタンバイ データベース,C-2 SQL Apply,6-6,9-4 ANALYZER プロセス,9-2 APPLIER プロセス,9-3 BUILDER プロセス,9-2 COORDINATOR プロセス,9-2 CREATE TABLE AS SELECT(CTAS) 文の適用,9-5 DDL トランザクションの適用,9-5 DDL 文のサポート,C-1 DML トランザクションの適用,9-4 OPEN RESETLOGS の後,9-22 PL/SQL パッケージのサポート,C-3 PREPARER プロセス,9-2 READER プロセス,9-2 アーカイブ REDO ログ ファイルの削除,9-14 アーキテクチャ,9-2,9-11 開始リアルタイム適用,6-6 記憶域型のサポート,C-3 現行のアクティビティの表示,9-3 プロセス,9-3 索引 -6

399 再開の考慮事項,9-4 サポートされない PL/SQL パッケージ,C-3 サポートされない記憶域型,C-3 サポートされないデータ型,C-2 サポートされない表データ型,C-4 サポートされるデータ型,C-2 スキップされるスキーマ,C-4 定義,1-5,6-2 停止リアルタイム適用,6-6 停止した場合の処置,A-9 トランザクション サイズの考慮事項,9-3 パラレル DDL トランザクション,9-5 パラレル DML(PDML) トランザクション,9-4 表圧縮を使用したサポートされない表,C-4 リアルタイム適用,9-15 ローリング アップグレード,2-6 ローリング アップグレードの実行,11-2 ローリング アップグレードの要件,11-2 ロールの推移とカスケードされた構成,E-5 SQL Apply によるアーカイブ ギャップの解決,5-30 SQL セッションスイッチオーバー障害の原因となる,A-5 SQL 文スイッチオーバーと,7-8 ロジカル スタンバイ データベースでの実行,1-2, 1-5 ロジカル スタンバイ データベースでのスキップ, C-5 STANDBY_ARCHIVE_DEST 初期化パラメータ,5-23 暗黙的なデフォルト値,5-23 リカバリ領域へのアーカイブ,5-8 STANDBY_FILE_MANAGEMENT 初期化パラメータデータファイルの改名時,8-12 トランスポータブル表領域に対する設定,8-12 START LOGICAL STANDBY APPLY 句 ALTER DATABASE の,4-8,6-6,7-19,11-7,A-9 IMMEDIATE キーワード,6-6,9-15 STOP LOGICAL STANDBY APPLY 句 ALTER DATABASE の,6-6,7-18,11-6,12-19, 15-4 SWITCHOVER_STATUS 列 V$DATABASE ビューの,7-7,7-8,A-5 SYNC 属性,14-23 LOG_ARCHIVE_DEST_n 初期化パラメータ,5-11 データ保護の設定,5-21 SYS ユーザー アカウント REMOTE_LOGIN_PASSWORDFILE 初期化パラメータ,5-15 パスワード ファイルの要件,5-15 T TEMPLATE 属性,14-24 TIMESTAMP データ型ロジカル スタンバイ データベース,C-2 tnsnames.ora ファイル REDO 転送サービス調整,A-10 トラブルシューティング,12-42,A-3,A-8,A-10 U UNDO_RETENTION 初期化パラメータ推奨,4-6 UROWID データ型ロジカル スタンバイ データベース,C-2 USER_DUMP_DEST 初期化パラメータ,G-2 USING CURRENT LOGFILE 句,8-6 リアルタイム適用の開始,6-5 V V$ARCHIVE_DEST_STATUS ビュー,5-32,8-23,16-2 ログ適用サービスと MANAGED REAL TIME 列, 8-23 V$ARCHIVE_DEST ビュー,5-32,12-42,16-1,A-3 STANDBY_ARCHIVE_DEST パラメータの暗黙的なデフォルト値の表示,5-23 すべての宛先の情報の表示,16-2 V$ARCHIVE_GAP ビュー,16-2 フィジカル スタンバイ データベースでのギャップの検出,5-30 V$ARCHIVED_LOG ビュー,5-24,5-32,8-23,12-48, 16-2,A-5 欠落しているログ ファイルの検出,5-30 最新のアーカイブ REDO ログ ファイルの判定, 5-32 V$DATABASE_INCARNATION ビュー,16-2 データベース インカネーション情報の取得,8-19 V$DATABASE ビュー,16-2 SWITCHOVER_STATUS 列と,7-7,7-8,A-5 スイッチオーバーと,7-7,7-8 ファスト スタート フェイルオーバーの監視,8-16 V$DATAFILE ビュー,12-44,12-45,16-2 V$DATAGUARD_CONFIG ビュー,16-2 LOG_ARCHIVE_CONFIG で定義済のデータベース名のリスト表示,16-2 V$DATAGUARD_STATS ビュー,16-2 V$DATAGUARD_STATUS ビュー,8-24,16-2 V$LOG_HISTORY ビュー,8-20,8-23,16-2 V$LOGFILE ビュー,16-2 V$LOGSTDBY_PROCESS ビュー,9-3,9-7,9-8,9-12, 9-24,9-25,16-2,16-3 V$LOGSTDBY_PROGRESS ビュー,9-8,16-2 RESTART_SCN 列,9-4 SCN 情報の問合せと,12-18 V$LOGSTDBY_STATE ビュー,7-3,9-9,9-11,16-3 V$LOGSTDBY_STATS ビュー,9-3,9-10,16-3 フェイルオーバー特性,9-7 V$LOGSTDBY_TRANSACTION ビュー,16-3 V$LOGSTDBY ビュー,xxviii V$LOG ビュー,5-32,16-2 V$MANAGED_STANDBY ビュー,8-22,16-3 V$RECOVER_FILE ビュー,8-16 V$SESSION ビュー,A-6,A-7 V$STANDBY_LOG ビュー,7-20,16-3 V$THREAD ビュー,8-16 VALID_FOR 属性,14-26 値とロールベースの条件,14-27 概要,5-16 確認,12-9 例,5-16 索引 -7

400 VARCHAR2 データ型ロジカル スタンバイ データベース,C-2 VARCHAR データ型ロジカル スタンバイ データベース,C-2 VERIFY 属性,14-28 W WAITING FOR DICTIONARY LOGS 状態,9-11 X XML 型データ型ロジカル スタンバイ データベース,C-2 あ アーカイバ プロセス (ARCn) 完了したアーカイブ REDO ログ ファイルの内容の確認,14-28 定義,5-9 アーカイブ REDO 転送サービス も参照 アーカイブ REDO ログ ファイル も参照開始,3-12 失敗した宛先へ,5-18,14-22 指定 STANDBY_ARCHIVE_DEST 初期化パラメータを使用,5-8 障害解決ポリシー,5-18,14-22 ネットワーク転送モード,5-11 リアルタイム適用,6-3 アーカイブ REDO ログ ファイル COMPATIBLE 初期化パラメータの影響,5-23 宛先 DBA_LOGSTDBY_LOG ビューに表示,12-18 V$ARCHIVE_DEST_STATUS ビューに表示,16-2 使用可能,5-4 無効化,5-4 一時記憶域,5-3 概要,2-10 ギャップ管理,1-11,5-28 ギャップ管理 も参照,1-11 欠落しているログの取得,12-19 最新のアーカイブを判定,5-32 指定スタンバイ データベースでのディレクトリ位置, 5-23 手動による転送,2-6,12-49 情報へのアクセス,8-20,8-23 スイッチオーバーの問題のトラブルシューティング, A-5 スタンバイ データベースと,6-6,6-7,8-22 適用 REDO Apply テクノロジ,1-4 SQL Apply テクノロジ,1-5 適用の遅延,12-39,14-8 スタンバイ データベースでの,6-4 転送された REDO データ,1-4,6-2 登録,5-31,12-19 フェイルオーバー時,7-17 部分的な,12-20 内容の確認,14-28 フィジカル スタンバイ データベースでのギャップの検出,5-30 不要なファイルの削除,9-14 リスト,12-18 ロジカル スタンバイ データベースでのギャップの検出,5-31 アーカイブ REDO ログ リポジトリ,5-3 アーカイブ ギャップ DBA_LOGSTDBY_LOG ビューでの検出,5-31 V$ARCHIVE_GAP ビューでの検出,5-30 欠落しているログ ファイルの登録,5-30,5-31 原因,12-46 手動によるログのコピー,12-49 スタンバイ データベースへの REDO ログの手動による適用,12-50 定義,5-28 フィジカル スタンバイ データベースでの手動による解決,5-30 防止,12-47 ログの識別,12-48 アーカイブ先代替,A-4 アーカイブ トレーススタンバイ データベースと,5-33,G-2 アイドル状態,9-13 アクティブ化クローン データベース,12-32 フィジカル スタンバイ データベース,7-10, 10-7,12-32,12-33,12-40,15-4 読取り / 書込み用フィジカル スタンバイ データベース,12-30 ロジカル スタンバイ データベース,7-18,15-4, B-7 アップグレード Oracle Database,B-1,B-2 Oracle Database ソフトウェア,2-6,11-2 Oracle Database ソフトウェア バージョン,11-2 要件,11-2 宛先 Oracle Change Data Capture のアーカイブ,5-3 Oracle Streams のアーカイブ,5-3 V$ARCHIVE_DEST に表示,16-2 アーカイブ REDO ログ リポジトリ,5-3 インスタンス間アーカイブ,D-3 共有,5-27,14-10 指定,5-4 ロールの推移の設定の確認,12-9 ロールベースの定義,14-26 暗号化された列,C-4 ロジカル スタンバイ データベース,C-2 い 一意索引列サプリメンタル ロギングを使用したログ,4-6,9-4 インスタンス間アーカイブ Real Application Clusters 構成,D-3 スタンバイ REDO ログ ファイル,D-4 ログ ライター プロセスの使用,D-4 索引 -8

401 お オフサイトでの REDO データのアーカイブ,5-3 オペレーティング システム Data Guard 構成の要件,2-5 オンライン REDO ログ ファイルアーカイブ ギャップ管理,5-28 削除,8-14 追加,8-14 か 解決論理的な破損,1-10 開始 REDO Apply,3-12,6-5,8-2 SQL Apply,4-8,6-6 フィジカル スタンバイ データベース,3-12 リアルタイム適用,6-6 フィジカル スタンバイ データベース,6-5 ロジカル スタンバイ データベース,6-6,9-15 ロジカル スタンバイ データベース,4-8 改名データファイル STANDBY_FILE_MANAGEMENT パラメータの設定,8-12 プライマリ データベースでの,8-12 拡張可能索引ロジカル スタンバイ データベースでサポートされる,C-2 確認アーカイブ REDO ログ ファイルの内容,14-28 スタンバイ REDO ログ グループ,3-4 フィジカル スタンバイ データベース,3-13 ロール ベースの宛先設定,12-9 ロジカル スタンバイ データベース,4-8 カスケードされた宛先使用例,E-5 ~ E-8 スタンバイ REDO ログ ファイルの必要性,2-10 定義,E-1 フィジカル スタンバイ データベース,E-1,E-3 ロールの推移,E-5 REDO Apply,E-5 SQL Apply,E-5 ロジカル スタンバイ データベース,E-4 ロジカル スタンバイ データベースでのマテリアライズド ビュー,E-7 監視 REDO 転送サービス,5-32 スタンバイ データベース,8-7 表領域の状態,8-16 プライマリ データベース イベント,8-16 ログ適用サービス,8-23 管理リカバリ操作 REDO Apply を参照管理リカバリ プロセス (MRP) ARCn アーカイブ プロセス,5-10 LGWR SYNC アーカイブ プロセス,5-12 REDO Apply も参照パラレル リカバリ プロセスの起動,5-10 き 記憶域型クラスタ表,C-3 索引構成表,C-3 サポートされない,C-3 サポートされる,C-3 セグメント圧縮,C-3 ヒープ構成表,C-3 ロジカル スタンバイ データベース,C-3 記憶域属性ローリング アップグレード中にサポートされない, 11-4 基本的に読取り可能なスタンバイ データベース, スタンバイ データベース環境の再現 を参照ギャップ管理,5-28 アーカイブ REDO ログ ファイル も参照アーカイブ REDO ログ ファイルの登録,5-31 フェイルオーバー時,7-17 欠落しているログ ファイルの検出,1-11 自動検出と自動解消,1-4,1-11 定義,5-28 ギャップ待機中状態,9-13 ギャップの順序判断,5-30,5-31 共有宛先,5-27,14-10 フラッシュ リカバリ領域,5-8 く クラスタ表ロジカル スタンバイ データベース,C-3 クローニング CREATE RESTORE POINT コマンド,12-31 フィジカル スタンバイ データベース,12-30 読取り / 書込み用データベースのアクティブ化, リストア ポイントの作成,12-31 グローバル動的パフォーマンス ビュー,8-17 ビュー も参照クローン データベース ACTIVATE STANDBY DATABASE 句,12-32 DB_RECOVERY_FILE_DEST_SIZE 初期化パラメータ,12-31 DB_RECOVERY_FILE_DEST 初期化パラメータ, アクティブ化,12-32 フィジカル スタンバイ データベースのアクティブ化,12-30 フィジカル スタンバイ データベースの変換, リストア ポイントの作成,12-31 クローン データベースのアクティブ化,12-32 索引 -9

402 け 欠落しているログ順序番号 ギャップ管理 も参照検出,1-11 欠落しているログ ファイルの自動検出,1-4,1-11, 5-28 検出欠落しているアーカイブ REDO ログ ファイル, 1-4,1-11,5-28 欠落しているログ ファイル,5-30 プライマリ データベースとスタンバイ データベース間のネットワーク切断,14-19 検証 REDO データ,1-10 こ 高可用性 Data Guard による実現,1-1 RAC および Data Guard による実現,1-9 メリット,1-10 構成 REDO ログ,2-10 カスケードされた宛先,E-3 障害時リカバリ,1-3 初期化パラメータ REDO 転送サービスの設定,5-5 代替アーカイブ先,A-4 タイム ラグのあるスタンバイ データベースの作成,12-39 フィジカル スタンバイ データベース用,3-9 スタンバイ REDO ログ グループ,3-3 スタンバイ REDO ログ ファイル,3-3 スタンバイ データベースでのバックアップ,1-3 非データ消失,1-5 フィジカル スタンバイ データベース,2-7 フィジカル スタンバイ データベースのリスナー, 3-11 リモート位置のスタンバイ データベース,1-3 ロジカル スタンバイ データベースでのレポート生成操作,1-3 構成オプション Data Guard Broker での作成,1-6 REDO ログ,2-10 一般的な,1-3 概要,1-2 スタンバイ データベースアーカイブ REDO ログ リポジトリ,5-3 遅延されたアーカイブ REDO ログ ファイルの適用,12-39 遅延スタンバイ,6-4 パスワード ファイルの要件,5-15 フィジカル スタンバイ データベース位置とディレクトリ構造,2-7 固定ビュー ビュー を参照コピー制御ファイル,3-11 コマンド Recovery Manager DUPLICATE,F-2 コマンドライン インタフェースブローカ,1-11 コレクション データ型ロジカル スタンバイ データベース,C-2 さ 再開の考慮事項 SQL Apply,9-4 再現スタンバイ データベース環境,2-6 再作成ロジカル スタンバイ データベース上の表,9-19 再接続ネットワーク接続最大可用性モードの場合,14-19 最大保護モードの場合,14-19 ネットワーク タイムアウト後,14-19 最大可用性モード概要,1-8 スタンバイ REDO ログ ファイルの必要性,2-10 設定,5-21 定義,5-20 ネットワーク接続への影響,14-19 最大パフォーマンス モード,7-6 概要,1-8,5-20 設定,5-21 最大保護モード Real Application Clusters,D-6 概要,1-8,5-20 スタンバイ REDO ログ ファイルの必要性,2-10 スタンバイ データベースと,7-6 設定,5-21 ネットワーク接続への影響,14-19 再同期化フィジカル スタンバイ データベースと REDO の新規ブランチ,8-15 ロジカル スタンバイ データベースと REDO の新規ブランチ,9-22 索引構成表ロジカル スタンバイ データベース,C-3 削除アーカイブ REDO ログ ファイル DBA_LOGMNR_PURGED_LOG ビューに表示, 9-14 SQL Apply で不要,9-14 オンライン REDO ログ ファイル,8-14 データファイル,8-11 例,8-11 プライマリ データベースから表領域を,8-11 作成従来の初期化パラメータ ファイルフィジカル スタンバイ データベース用,3-9 新規パスワード ファイル,4-6 スタンバイ REDO ログ ファイル,3-4 スタンバイ データベース OMF を使用,F-8,F-9 データベース リンク,7-18 ロジカル スタンバイ データベースでの索引,9-17 サプリメンタル ロギング主キーおよび一意索引の列のログへの記録の設定, 4-6 主キー列と一意索引列を記録するための設定,9-4 索引 -10

403 サポートされない PL/SQL パッケージ,C-3 サポートされない記憶域型,C-3 サポートされないデータ型ローリング アップグレード中,11-4 サポートされない表ローリング アップグレード中のロジカル スタンバイ データベース,11-3 サポートされる PL/SQL パッケージ,C-3 サポートされる記憶域型,C-3 サポートされるデータ型ロジカル スタンバイ データベース,C-1,C-5 し システム イベント DB_ROLE_CHANGE のトリガーの記述,7-5,7-7 システム グローバル領域 (SGA) 論理変更レコードのステージング,9-2 システム リソース効率的な使用,1-10 自動スイッチオーバー,1-5,7-1 スイッチオーバー も参照自動ストレージ管理 (ASM) 使用するスタンバイ データベースの作成,12-51 自動フェイルオーバー,1-5,7-1 終了ネットワーク接続,14-19 主キー列サプリメンタル ロギングを使用したログ,4-6,9-4 取得欠落しているアーカイブ REDO ログ ファイル, 1-4,1-11,5-28,12-19 順序ロジカル スタンバイ データベースでサポートされない,C-4 障害解決ポリシー REDO 転送サービスに関する指定,5-18,14-22 障害時リカバリ Data Guard による実現,1-1 構成,1-3 スタンバイ サイトの ReadMe ファイル,12-12 スタンバイ データベースによる実現,1-3 メリット,1-10 使用可能アーカイブ REDO ログ ファイルの宛先,5-4 リアルタイム適用,8-6 フィジカル スタンバイ データベース,6-5 ロジカル スタンバイ データベース,6-6,9-15 ロジカル スタンバイ データベースにおけるデータベース ガード,15-4 使用例 REDO ログでのタイム ラグ,12-39 カスケードされた宛先,E-5 ~ E-8 リカバリ NOLOGGING 指定後,12-43 ネットワーク障害の,12-42 ロジカル スタンバイ データベース,12-43 ロールの推移に最適なスタンバイ データベースの選択,12-10 初期化パラメータ CONTROL_FILE_RECORD_KEEP_TIME,5-26 DB_FILE_NAME_CONVERT,F-5 DB_UNIQUE_NAME,3-5,A-7 FAL_CLIENT,5-29 FAL_SERVER,5-29 LOG_ARCHIVE_DEST,12-50 LOG_ARCHIVE_DEST_STATE_n,5-4 LOG_ARCHIVE_FORMAT,5-23 LOG_ARCHIVE_MIN_SUCCEED_DEST,14-14 LOG_ARCHIVE_TRACE,5-33,G-2,G-3 LOG_FILE_NAME_CONVERT,F-5 STANDBY_ARCHIVE_DEST,5-23 USER_DUMP_DEST,G-2 フィジカル スタンバイ データベース用に変更, 3-9 プライマリ ロールおよびスタンバイ ロールの設定,14-26 初期化パラメータ ファイルサーバー パラメータ ファイルから作成フィジカル スタンバイ データベース用,3-9 変更フィジカル スタンバイ データベース用,3-9 す スイッチオーバー,1-5 Data Guard Broker での単純化,1-6,7-1 DBA_LOGSTDBY_HISTORY に履歴を表示,16-1 ORA による失敗,A-7 Real Application Clusters の使用と,D-6 SQL 文と,7-8 V$DATABASE ビューと,7-7,7-8 後の DB_ROLE_CHANGE システム イベントの使用,7-5 後のデータベースのフラッシュバック,7-21 確認,7-8 カスケードされた構成,E-5 REDO Apply,E-5 SQL Apply,E-5 監視,8-16 関与しないスタンバイ データベース,7-9 最後のアーカイブ REDO ログ ファイルが転送されたかどうかの確認,A-5 最初からやり直し,A-8 妨げの原因 CJQ0 プロセス,A-6 DBSNMP プロセス,A-6 QMN0 プロセス,A-6 アクティブな SQL セッション,A-5 アクティブなユーザー セッション,A-7 プロセス,A-6 手動と自動,1-5,7-1 準備,7-5 制御ファイルと,7-8 ターゲット スタンバイ データベースの選択,7-3 代表的な使用例,7-4 定義,1-5,7-2 非データ消失と,7-2 フィジカル スタンバイ データベースと,7-5,7-8 プライマリ データベースでの開始,7-8 ロジカル スタンバイ データベースと,7-14 索引 -11

404 スキーマ SQL Apply でスキップ,C-4 スキップ対象を示す DBA_LOGSTDBY_SKIP リスト, C-4 プライマリ データベースと同一,1-2 ロジカル スタンバイ データベースでのデータ操作,1-10 スタンバイ REDO ログ グループ十分かどうかの判断,5-25 推奨数,3-3 メンバーの追加,5-25 スタンバイ REDO ログ ファイル RAW デバイス上,2-10 Real Application Clusters,3-4,D-4 インスタンス間アーカイブ,D-4 概要,2-10 作成,3-3,3-4 ログ グループとメンバー,3-3 適用スタンバイ データベースへ,1-3 ネットワーク転送モード,5-11 要件カスケードされた宛先,2-10 最大可用性モード,2-10 最大保護モード,2-10 保護モード,1-8 リアルタイム適用,2-10 リアルタイム適用,2-9,6-3 利点,2-10 スタンバイ データベース DB_FILE_NAME_CONVERT 初期化パラメータ,F-5 LOG_FILE_NAME_CONVERT 初期化パラメータ, F-5 NETWORK_TIMEOUT 属性の設定,5-14 OMF ファイルを使用するためのセットアップ,F-8, F-9 OPEN RESETLOGS を使用したリカバリ,8-15 Recovery Manager およびスタンバイ インスタンスの起動,F-8 Recovery Manager の準備,F-2 Recovery Manager の増分バックアップによるロールフォワード,12-34 Recovery Manager を使用した作成について,F-2 Recovery Manager を使用したデータファイルのネーミング,F-4 REDO データの適用,6-1 REDO ログ ファイルの適用,1-4,1-10 RESETLOGS_ID の表示,8-19 SET AUXNAME コマンド,F-5 SET NEWNAME コマンド,F-5 カスケード,E-1 共有フラッシュ リカバリ領域,5-8 構成,1-2 Real Application Clusters,1-2,D-2,D-4 アーカイブ REDO ログ リポジトリ,5-3 インスタンス間アーカイブ,D-3 オプションの宛先,5-24 最大数,2-1 シングル インスタンス,1-2 遅延されたアーカイブ REDO ログ ファイルの適用,12-39 必須の宛先,5-24 リモート位置,1-3 作成,1-2,3-1,F-17 Recovery Manager の使用,F-6 タイム ラグのある,6-4,12-40 タスクのチェックリスト,4-4 ディレクトリ構造の考慮点,2-7 プライマリが ASM または OMF を使用する場合, リモート ホスト上で異なるディレクトリ構造, F-12 リモート ホスト上で同一のディレクトリ構造, F-10 ローカル ホスト上,F-16 制御ファイルの作成 Recovery Manager の使用,F-3 制御ファイルの変更,8-12 ソフトウェア要件,2-6 待機イベントの構成,5-33 定義,2-2 データベース インカネーション情報の表示,8-19 動作要件,2-5,2-6 ハードウェア要件,2-5 フィジカル スタンバイ データベースでのログ適用サービスの開始,6-5 フィジカル スタンバイ データベース も参照フェイルオーバー,7-6 準備,7-6 フェイルオーバー後に再作成,7-10 プライマリ データベースとの再同期化,1-11 プライマリ データベースへの復帰,A-8 ロールの推移のターゲットの選択,12-10 ログ適用サービス,6-2 ロジカル スタンバイ データベース も参照ロジカルの作成,4-1 スタンバイ ロール,1-2 スナップショットフラッシュバック問合せによる取得,4-6 スループットロジカル スタンバイ データベース,9-4,9-5 せ 制御ファイル ALTER DATABASE RENAME FILE 文で変更,8-12 コピー,3-11 サイズ拡大の計画,5-26 スイッチオーバーと,7-8 スタンバイ データベース用に作成,3-8 制御ファイルのレコードの再利用,5-26 制約ロジカル スタンバイ データベースでの処理,9-21 セキュアな REDO の転送,5-15 セキュアな REDO の転送に関する推奨事項,5-15 セグメント圧縮記憶域型ロジカル スタンバイ データベース,C-3 設定 VALID_FOR 属性フィジカル スタンバイ データベース用,12-2 ロジカル スタンバイ データベース,12-4 データ保護モード,5-21 索引 -12

405 そ 属性 LOG_ARCHIVE_DEST_n 初期化パラメータについて廃止,14-1 ソフトウェア要件,2-6 Oracle Database Enterprise Edition,2-6 ローリング アップグレード,2-6 た ターゲット スタンバイ データベーススイッチオーバー,7-3 フェイルオーバー用のフィジカル スタンバイ データベースの選択,12-11 フェイルオーバー用のロジカル スタンバイ データベースの選択,12-17 代替アーカイブ先初期化パラメータの設定,A-4 待機イベント,5-33 REDO 転送モードのパフォーマンスの監視,5-33 スタンバイ宛先,5-33 待機時間ロジカル スタンバイ データベース,9-4,9-5 タイム ラグアーカイブ REDO ログ ファイルの適用の遅延, 6-4,12-39,14-8 スタンバイ データベースでの,6-4,12-40,14-8 ダイレクト パス インサート SQL Apply の DML の考慮事項,9-4 ダウンストリーム取得データベース Oracle Streams と Data Guard の REDO 転送サービス, 5-3 ち チェックポイント V$LOGSTDBY_PROGRESS ビュー,9-4 チェックリストスタンバイ データベース作成に関するタスク,4-4 フィジカル スタンバイ データベース作成に関するタスク,3-8 遅延 REDO ログ ファイルの適用,6-4 アーカイブ REDO ログ ファイルの適用,12-39, 14-8 チャンクトランザクション,9-3 調整 REDO Apply のログ適用レート,8-25 初期化パラメータ ファイルロジカル スタンバイ データベース用,4-7 スタンバイ REDO ログ グループが十分かどうかの判断,5-25 つ 追加オンライン REDO ログ ファイル,5-25,8-14 新規または既存のスタンバイ データベース,1-6 スタンバイ REDO ログ,3-3 スタンバイ REDO ログ グループのメンバー,5-25 データファイル,8-8,A-11,A-12 表領域,8-8 ロジカル スタンバイ データベースでの索引, 1-10,2-4,9-17 通信 Data Guard 構成のデータベース間,1-2 て ディクショナリ LogMiner の構築,4-6 ディクショナリ ロード中状態,9-12 停止 REDO Apply,6-6 SQL Apply,6-6 フィジカル スタンバイ データベース,8-3 フィジカル スタンバイ データベースでのリアルタイム適用,6-6 リアルタイム適用ロジカル スタンバイ データベース,6-6 停止時間ゼロのインスタンス化ロジカル スタンバイ データベース,4-4 ディスク I/O AFFIRM および NOAFFIRM 属性で制御,14-2 ディスク上のデータベース構造フィジカル スタンバイ データベース,1-2 ディレクトリ位置 STANDBY_ARCHIVE_DEST 初期化パラメータで指定,5-23 アーカイブ REDO ログ ファイル,5-23 ディレクトリの場所 ASM を使用したセットアップ,2-7 OMF を使用したセットアップ,2-7 Optimal Flexible Architecture(OFA),2-7 スタンバイ データベースの構造,2-7 データ型 BFILE,C-2 BINARY_DEGREE,C-2 BINARY_FLOAT,C-2 BLOB,C-2 CHAR,C-2 CLOB,C-2 DATE,C-2 INTERVAL,C-2 LONG,C-2 LONG RAW,C-2 NCHAR,C-2 NCLOB,C-2 NUMBER,C-2 NVARCHAR2,C-2 RAW,C-2 ROWID,C-2 Spatial Image および Context,C-2 TIMESTAMP,C-2 UROWID,C-2 VARCHAR,C-2 VARCHAR2,C-2 索引 -13

406 XML 型,C-2 暗号化された列,C-2 ユーザー定義,C-2 ロジカル スタンバイ データベースのコレクション, C-2 データ可用性システム パフォーマンス要件とのバランス,1-10 データ消失最小化,7-10 スイッチオーバーと,7-2 フェイルオーバーによる,1-5 データ消失なし 非データ消失 を参照データ破損保護対策,1-10 データファイル監視,8-16,12-44 プライマリ データベースから削除,8-11 プライマリ データベースでの改名,8-12 プライマリ データベースへの追加,8-8 データベースカスケード スタンバイ データベース, カスケードされた宛先 を参照クローニング,12-30 障害とデータ破損からの保護,1-1 ソフトウェア バージョンのアップグレード,11-2 パスワード ファイルの使用,5-15 フェイルオーバーと,7-6 プライマリ, プライマリ データベース を参照ロールの推移と,7-2 データベース インカネーション OPEN RESETLOGS を使用した変更,8-15 データベース ガード,6-2 オーバーライド,9-17 データベース スキーマフィジカル スタンバイ データベース,1-2 データベースのインカネーション変更,8-15 データベースのロール推移,1-5 スタンバイ,1-2,7-2 プライマリ,1-2,7-2 データベース リンク作成,7-18 データベース アップグレード アシスタント (DBUA),B-2 データ保護 Data Guard による実現,1-1 柔軟性,1-10 パフォーマンスとのバランス,1-10 非データ消失の保証,2-3 メリット,1-10 データ保護モード REDO 転送サービスによる施行,1-4 一連の最低要件,5-21 概要,1-8 最大可用性モード,5-21 最大パフォーマンス モード,5-21 最大保護モード,5-21 指定,5-21 同期および非同期ネットワーク I/O 操作の設定, ネットワーク接続への影響,14-19 ネットワーク タイムアウトへの影響,14-19 テキスト索引ロジカル スタンバイ データベースでサポートされる,C-2 適用 REDO データの即時,6-3 SQL 文をロジカル スタンバイ データベースに, 6-6 スタンバイ データベースへの REDO データ,1-3, 1-4,2-2,6-1 適用中状態,9-13 と 問合せスタンバイ データベースでのオフロード,1-10 パフォーマンスの改善,1-10 動作要件,2-5,2-6 スタンバイ データベースオペレーティング システム要件,2-5 動的パフォーマンス ビュー,8-17 ビュー も参照動的パラメータ AQ_TM_PROCESSES,A-6 JOB_QUEUE_PROCESSES,A-6 登録アーカイブ REDO ログ ファイル,5-31,12-19 フェイルオーバー時,7-17 欠落しているログ ファイル,5-30,5-31 部分的なアーカイブ REDO ログ ファイル,12-20 トラブルシューティング listener.ora ファイル,12-42,A-3,A-10 SQL Apply,A-9 SQL Apply が停止した場合,A-9 tnsnames.ora ファイル,12-42,A-3,A-8,A-10 最後の REDO データが転送されていない,A-5 スイッチオーバー,A-5 ORA メッセージ,A-7 アクティブな SQL セッション,A-5 アクティブなユーザー セッション,A-7 ロールバックおよび最初からやり直し,A-8 スイッチオーバーを妨げるプロセス,A-6 ロジカル スタンバイ データベース障害,A-4 トランザクション サイズの考慮事項 SQL Apply,9-3 トランスポータブル表領域 DB_FILE_NAME_CONVERT パラメータで位置を定義,8-12 STANDBY_FILE_MANAGEMENT パラメータの設定,8-12 フィジカル スタンバイ データベースでの使用, 8-12 トリガーロジカル スタンバイ データベースでの処理,9-21 取消しログ適用サービス,8-6 トレース ファイル位置,G-2 設定,G-2 データのトレース レベル,G-3 リアルタイム適用の追跡,G-3 索引 -14

407 に 認証 REDO データの送信,5-15 SYS 資格証明を使用したチェック,5-15 ね ネットワーク I/O 操作切断の検出,14-19 タイムアウト パラメータ値の調整,14-20 調整 REDO 転送サービス,A-10 データ保護モードの影響,14-19 同期または非同期の設定,14-23 ネットワーク タイマー NET_TIMEOUT 属性,14-19 不適切な障害,14-19 ネットワーク タイムアウト LGWR ASYNC 宛先,5-14 応答,14-19 は バージョン Oracle Database ソフトウェアのアップグレード, 11-2 ハードウェア Data Guard 構成の要件,2-5 廃止になった属性 LOG_ARCHIVE_DEST_n 初期化パラメータ,14-1 パスワード ファイル REMOTE_LOGIN_PASSWORDFILE 初期化パラメータの設定,5-15 新規の作成,4-6 要件,5-15 バックアップ操作 Recovery Manager の DUPLICATE コマンドの DB_ FILE_NAME_CONVERT オプション,F-5 Recovery Manager の使用,10-1 スタンバイ データベースでのオフロード,1-10 データファイル,12-44 フィジカル スタンバイ データベースの構成,1-3 フェイルオーバー後,7-12,7-19 プライマリ データベース,1-2 ブローカによる使用,1-6 リカバリ不能処理後,12-45 バッチ処理ロジカル スタンバイ データベース,9-4 パッチ セット リリースアップグレード,2-6 パフォーマンス REDO 転送サービスの監視,5-33 データ可用性とのバランス,1-10 データ保護とのバランス,1-10 パラレル DDL(PDDL) トランザクション SQL Apply,9-5 パラレル DML(PDML) トランザクション SQL Apply,9-4 パラレル実行処理指定 PARALLEL_MAX_SERVERS 初期化パラメータ, 8-25,13-4 フィジカル スタンバイ データベース,5-10 ログ適用レートのチューニング,8-25 ロジカル スタンバイ データベース,5-10 パラレル リカバリ プロセス REDO Apply のために開始,5-10 判断適用可能な最大の ( 最新の )SCN,12-17 ひ ヒープ構成表ロジカル スタンバイ データベース,C-3 非データ消失環境,5-11 最大可用性モードによる実現,1-8,5-20 最大保護モードによる実現,1-8,5-20 データ保護モードの概要,1-8 保証,1-5,2-3 メリット,1-10 非同期 REDO 転送,5-13,14-6,14-23 ビュー,8-17,16-1 DBA_LOGSTDBY_EVENTS,9-5,16-1,A-9 DBA_LOGSTDBY_HISTORY,16-1 DBA_LOGSTDBY_LOG,9-6,12-18,16-1 DBA_LOGSTDBY_NOT_UNIQUE,16-1 DBA_LOGSTDBY_PARAMETERS,16-1 DBA_LOGSTDBY_SKIP,16-1 DBA_LOGSTDBY_SKIP_TRANSACTION,16-1 DBA_LOGSTDBY_UNSUPPORTED,16-1,C-4 DBA_TABLESPACES,8-16 GV$INSTANCE,D-7 V$ARCHIVE_DEST,5-32,12-42,16-1,A-3 V$ARCHIVE_DEST_STATUS,5-32,8-23,16-2 V$ARCHIVE_GAP,16-2 V$ARCHIVED_LOG,5-24,5-32,8-23,12-48,16-2 V$DATABASE,16-2 V$DATABASE_INCARNATION,16-2 V$DATAFILE,12-44,12-45,16-2 V$DATAGUARD_CONFIG,16-2 V$DATAGUARD_STATS,16-2 V$DATAGUARD_STATUS,8-24,16-2 V$LOG,5-32,16-2 V$LOG_HISTORY,8-20,8-23,16-2 V$LOGFILE,16-2 V$LOGSTDBY,xxviii V$LOGSTDBY_PROCESS,9-3,9-7,16-2 V$LOGSTDBY_PROGRESS,9-8,16-2 V$LOGSTDBY_STATE,9-9,16-3 V$LOGSTDBY_STATS,9-3,9-10,16-3 V$LOGSTDBY_TRANSACTION,16-3 V$MANAGED_STANDBY,8-22,16-3 V$RECOVER_FILE,8-16 V$SESSION,A-6,A-7 V$STANDBY_LOG,3-4,7-20,16-3 V$THREAD,8-16 スイッチオーバーおよびフェイルオーバーの履歴の表示,16-1 索引 -15

408 表 SQL Apply でサポートされないデータ型,C-4 暗号化された列,C-4 表圧縮を使用,C-4 ロジカル スタンバイ データベースサポートされない,C-4 追加,9-19 表の再作成,9-19 ロジカル スタンバイ データベースでサポートされない,11-3 表領域状態の変更の監視,8-16 追加新規データファイル,A-12 プライマリ データベースへの,8-8 データベース間の移動,8-12 プライマリ データベースから削除,8-11 ふ ファスト スタート フェイルオーバー監視,8-16 自動フェイルオーバー,1-6,7-1 フィジカル スタンバイ データベース BACKUP INCREMENTAL FROM SCN コマンドによるロールフォワード,12-34 DDL のサポート,2-3 DML のサポート,2-3 OPEN RESETLOGS を使用したリカバリ,8-15 REDO Apply,1-4,2-2 REDO データの適用,6-2,6-5 REDO Apply テクノロジ,6-5 カスケード,E-1 REDO のプライマリ データベース ブランチとの再同期化,8-15 REDO ログ ファイルの適用開始,6-5 V$ARCHIVE_GAP ビューでのギャップの検出,5-30 VALID_FOR 属性の設定,12-2 アップグレード,B-2 オンライン バックアップおよび,2-3 開始リアルタイム適用,6-5 ログ適用サービス,6-5 監視,6-6,8-7,8-22,16-1 クローニングテスト 開発およびレポート生成,12-30 リストア ポイントの作成,12-31 クローン データベースとしてアクティブ化,12-32 構成オプション,2-7 作成 Data Guard Broker,1-6 従来の初期化パラメータ ファイル,3-9 初期化パラメータ,3-9 タスクのチェックリスト,3-8 ディレクトリ構造,2-8 リスナーの構成,3-11 手動によるアーカイブ ギャップの解決,5-30 定義,1-2 停止,8-3 トランスポータブル表領域の使用,8-12 フェイルオーバー更新をチェック,7-7 フェイルオーバー後のフラッシュバック,12-25 フェイルオーバーのターゲットの選択,12-11 プライマリ データベースとの同期化,12-34 変更オンライン REDO ログ ファイル,8-14 メリット,2-3 読取り / 書込みテストとレポート生成,12-30 読取り / 書込み用データベースへの変換,12-30 読取り専用,2-2,8-3 読取り専用または読取り / 書込みアクセス用にオープン,8-3 ロールの推移と,7-7 ロールフォワードデータファイルの小さいサブセットに対するロギングなし変更の適用時,12-36 ロギングなしの変更が広範囲にある場合,12-38 ログ適用レートのチューニング,8-25 ロジカル スタンバイ データベースへの変換,4-6 フェイルオーバー,1-5 Data Guard Broker,1-6,7-1 Data Guard Broker での単純化,7-1 DBA_LOGSTDBY_HISTORY に履歴を表示,16-1 FINISH FORCE,7-11 REDO データの事前転送,7-6 後の DB_ROLE_CHANGE システム イベントの使用,7-7 後のデータベースのフラッシュバック,7-21 後のバックアップの実行,7-12,7-19 カスケードされた構成,E-5 最小データ消失と,12-19 最小のパフォーマンス影響,12-19 最大パフォーマンス モード,7-6 最大保護モード,7-6 手動と自動,1-5,7-1 準備,7-6 ターゲット スタンバイ データベースの選択, 12-10,12-17 定義,1-5,7-2 ファスト スタート フェイルオーバー,7-1 フィジカル スタンバイ データベースと,7-10, 15-4 フェイルオーバー後に再作成,7-10 ロジカル スタンバイ データベースと,7-17, ロジカル スタンバイ データベースの特性の表示, 9-7 不適切なネットワーク障害検出,14-19 部分的なアーカイブ REDO ログ ファイル登録,12-20 プライマリ データベース ARCHIVELOG モード,2-6 Real Application Clusters 設定,D-3,D-4 REDO 転送サービス,1-4 REDO ログ アーカイブ情報の収集,5-32 アーカイブ トレースの設定,5-33 イベントの監視,8-16 ギャップの解決,1-11 欠落しているログ ファイルの V$ARCHIVED_LOG ビューによる検出,5-30 索引 -16

409 構成 Real Application Clusters,1-2 インスタンス間アーカイブ,D-4 シングル インスタンス,1-2 準備フィジカル スタンバイ データベースの作成, 3-2 初期化パラメータフィジカル スタンバイ データベース,3-9 スイッチオーバー,7-4 開始,7-8 ソフトウェア要件,2-6 定義,1-2 データファイル改名,8-11 追加,8-8 ネットワーク接続切断の検出,14-19 ネットワーク タイムアウトの処理,14-19 ネットワーク停止の回避,14-19 バックアップと,7-12,7-19 表領域削除,8-11 追加,8-8 フェイルオーバーと,7-2 フラッシュ リカバリ領域の共有,5-8 要件ロジカル スタンバイ データベースの作成,4-2 ワークロードの低減,1-10 プライマリ ロール,1-2 フラッシュバック データベース Data Guard を補完する特性,1-9 OPEN RESETLOGS 後,12-28 クローン データベース,12-30 フィジカル スタンバイ データベース,12-25 保証付きリストア ポイントに対する有効化,12-31 ロールの推移後,7-21 ロジカル スタンバイ データベース,12-26 フラッシュバック問合せ DBMS_LOGSTDBY.BUILD サブプログラムによる使用,4-6 フラッシュ リカバリ領域 STANDBY_ARCHIVE_DEST=LOCATION パラメータ,5-8 設定,5-6 デフォルトの場所,5-6,5-7,14-12 複数のデータベース間で共有,5-8 ブローカグラフィカル ユーザー インタフェース,1-11 コマンドライン インタフェース,1-11 定義,1-6 プロセス CJQ0,A-6 DBSNMP,A-6 QMN0,A-6 SQL Apply のアーキテクチャ,9-2,9-11 アーカイバ (ARCn),5-9 管理リカバリ プロセス (MRP) も参照スイッチオーバーの妨げ,A-6 ログ ライター (LGWR),5-11 へ ページアウト SQL Apply,9-4 ページアウトの考慮事項,9-4 変換フィジカル スタンバイ データベースからロジカル スタンバイ データベースへ,4-6 ロジカル スタンバイ データベースからフィジカル スタンバイ データベースへ中止,4-6 変更スタンバイ制御ファイル,8-12 フィジカル スタンバイ データベース用の初期化パラメータ,3-9 ロジカル スタンバイ データベース,9-17 ほ 補完テクノロジ,1-9 保護モード監視,8-16 最大可用性モード,1-8,5-20 最大パフォーマンス モード,1-8,5-20 最大保護モード,1-8,5-20 データ保護モード を参照保証付きリストア ポイント DB_RECOVERY_FILE_DEST_SIZE 初期化パラメータの設定,12-31 DB_RECOVERY_FILE_DEST 初期化パラメータの設定,12-31 作成,12-31 フラッシュバック データベースに対するフラッシュバック リカバリ領域の有効化,12-31 本番データベース プライマリ データベース を参照 ま マテリアライズド ビューカスケードされた宛先,E-4 ロジカル スタンバイ データベースでの作成, 1-10,2-4,E-7 マルチメディア データ型ロジカル スタンバイ データベース,C-2 ロジカル スタンバイ データベースでサポートされない,C-2 む 無効化アーカイブ REDO ログ ファイルの宛先,5-4 データベース リンクを定義するためのデータベース ガードの,7-18 索引 -17

410 め メディア リカバリパラレル,8-25 メモリー全体が使用済の LCR キャッシュ,9-4 メリット Data Guard,1-10 スタンバイ REDO ログおよびアーカイブ REDO ログ, 2-10 フィジカル スタンバイ データベース,2-3 ローリング アップグレード,11-2 ロジカル スタンバイ データベース,2-4 ゆ ユーザー セッションスイッチオーバー障害の原因となる,A-7 ユーザー定義データ型ロジカル スタンバイ データベース,C-2 ユーザーのミス保護対策,1-10 優先適用遅延間隔,6-4 よ 要件データ保護モード,5-21 ローリング アップグレード,11-2 読取り / 書込み用データベース,12-30 読取り専用操作,1-4 定義,2-2 フィジカル スタンバイ データベースと,8-3 ロジカル スタンバイ データベース,1-10 り リアルタイム適用 LOG_ARCHIVE_TRACE 初期化パラメータによるデータの追跡,G-3 RFS プロセス,6-2 SQL Apply,9-15 V$ARCHIVE_DEST_STATUS での進捗の監視,8-23 開始,6-5 ロジカル スタンバイ上での,6-6 スタンバイ REDO ログ ファイルの使用,2-9 スタンバイ REDO ログ ファイルの必要性,2-10 定義,6-2,6-3 停止フィジカル スタンバイ データベース,8-3 ロジカル スタンバイ上での,6-6 フィジカル スタンバイ データベース上での開始, 6-5 ログ適用サービスの概要,1-3 ロジカル スタンバイ データベース上での開始, 6-6,9-15 リカバリ NOLOGGING 句指定後,12-43 エラーの,A-11 フィジカル スタンバイ データベース OPEN RESETLOGS の後,8-15 リセットログの使用,8-15,9-22 ロジカル スタンバイ データベース,9-22 リカバリ不能処理,12-43 直後のバックアップ,12-45 リストアーカイブ REDO ログ ファイル,12-18 リストア ポイント CREATE RESTORE POINT コマンドの使用,12-31 作成,12-31 保証付きの作成,12-31 リポジトリアーカイブ REDO ログ ファイルの一時記憶域,5-3 リモート ファイル サーバー プロセス (RFS) スタンバイ REDO ログ ファイルの再利用,5-25 定義,2-9,5-12,6-2 ログ ライター プロセス,6-3 れ レポート生成操作構成,1-3 スタンバイ データベースでのオフロード,1-10 ロジカル スタンバイ データベースでの実行,1-2 ろ ローリング アップグレード COMPATIBLE 初期化パラメータの設定,11-2, 11-3,11-10 サポートされないデータ型および記憶域属性,11-4 ソフトウェア要件,2-6 パッチ セット リリース,2-6 メリット,11-2 要件,11-2 ロール管理サービス定義,7-1 ロールの推移,1-5,7-2 後のデータベースのフラッシュバック,7-21 可逆的な,1-5,7-2 カスケードされた構成,E-5 監視,8-16 最適なスタンバイ データベースの選択,12-10 推移後のタスクを管理するトリガーの記述,7-5,7-7 タイプの選択,7-2 定義,1-5 フィジカル スタンバイ データベースと,7-7 ロジカル スタンバイ データベースと,7-14 ロールバックスイッチオーバー障害後の,A-8 ロールベースの宛先設定,14-26 ログ適用サービス REDO Apply 開始,6-5,8-2 監視,6-6,8-18,8-22 定義,6-2,6-5 停止,6-6,8-3 ログ適用レートのチューニング,8-25 REDO Apply に関するチューニング,8-25 REDO データの適用遅延,6-4,12-39,14-8 SQL Apply 開始,6-6 監視,6-7 定義,1-4,6-2 停止,6-6 索引 -18

411 定義,1-4,6-2 リアルタイム適用 LOG_ARCHIVE_TRACE による監視,G-3 V$ARCHIVE_DEST_STATUS ビューで監視,8-23 スタンバイ REDO ログ ファイル,2-9 定義,6-2,6-3 ログ ライター プロセス (LGWR) ASYNC ネットワーク転送,5-11,14-23 NET_TIMEOUT 属性,14-19 SYNC ネットワーク転送,14-23 定義,5-11 ネットワーク タイムアウト後の再接続,14-19 ローカルのアーカイブ,5-4 ロジカル スタンバイ データベース,1-2 SQL Apply,1-5 DBMS_LOGSTDBY.APPLY_SET プロシージャ, 6-4 DDL 文のスキップ,C-5 REDO のプライマリ データベース ブランチとの再同期化,9-22 SQL 文のスキップ,C-5 遅延,6-4 停止,6-6 テクノロジ,6-2 トランザクション サイズの考慮事項,9-3 リアルタイム適用の開始,6-6,9-15 SQL 文の実行,1-2 UNDO_RETENTION 初期化パラメータ,4-6 VALID_FOR 属性の設定,12-4 アーカイブ ギャップ DBA_LOGSTDBY_LOG ビューでの検出,5-31 手動による解決,5-31 アップグレード,B-5 ローリング アップグレード,2-6 開始リアルタイム適用,6-6 カスケード,E-1,E-4 監視,6-7,16-1 作成,4-1 Data Guard Broker,1-6 フィジカル スタンバイ データベースからの変換,4-6 状態アイドル,9-13 ギャップ待機中,9-13 初期化中,9-11 ディクショナリ ロード中,9-12 適用,9-13 スイッチオーバー,7-14 スループットと待機時間,9-4,9-5 追加索引,1-10,2-4,9-17 データファイル,A-11 表,9-19 データ型サポートされない,C-2 サポートされる,C-1,C-2 データベース ガードオーバーライド,9-17 パスワード ファイル,4-6 バックグラウンド プロセス,9-2 フェイルオーバー,7-17 V$LOGSTDBY_STATS に特性を表示,9-7 後のフラッシュバック,12-26 障害の処理,A-4 ターゲット,12-17 履歴の表示,16-1 マテリアライズド ビュー作成,1-10,2-4,E-4,E-7 サポート,C-5 メリット,1-10,2-4 読取り専用操作,1-10 ロジカル スタンバイ プロセス (LSP) と,9-2 ロジカル スタンバイ プロセス (LSP) ARCn アーカイブ プロセス,5-10 COORDINATOR プロセス,9-2 LGWR SYNC アーカイブ プロセス,5-12 論理的な破損解決,1-10 論理変更レコード (LCR) PREPARER プロセスによる変換,9-2 ステージング,9-2 全体が使用済のキャッシュ メモリー,9-4 索引 -19

412 索引 -20