Oracle® Data Guardotndnld.oracle.co.jp/document/products/oracle10g/102/doc...Oracle Data Guard 概要および管理, 10g リリース2（10.2）部品番号: B19233-03 Oracle Data

Oracle® Data Guard概要および管理

10g リリース 2（10.2）

部品番号部品番号部品番号部品番号 : B19233-03

2008 年 10 月

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

部品番号 : B19233-03

Oracle Data Guard Concepts and Administration, 10g Release 2 (10.2)

原本部品番号 : B14239-05

原本著者 : 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 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このプログラムは、核、航空、大量輸送、医療あるいはその他の本質的に危険を伴うアプリケーションで使用されることを意図しておりません。このプログラムをかかる目的で使用する際、上述のアプリケーションを安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。万一かかるプログラムの使用に起因して損害が発生いたしましても、オラクル社およびその関連会社は一切責任を負いかねます。

Oracle、JD Edwards、PeopleSoft、Siebel は米国 Oracle Corporation およびその子会社、関連会社の登録商標です。その他の名称は、他社の商標の可能性があります。

このプログラムは、第三者の Web サイトへリンクし、第三者のコンテンツ、製品、サービスへアクセスすることがあります。オラクル社およびその関連会社は第三者の Web サイトで提供されるコンテンツについては、一切の責任を負いかねます。当該コンテンツの利用は、お客様の責任になります。第三者の製品またはサービスを購入する場合は、第三者と直接の取引となります。オラクル社およびその関連会社は、第三者の製品およびサービスの品質、契約の履行（製品またはサービスの提供、保証義務を含む）に関しては責任を負いかねます。また、第三者との取引により損失や損害が発生いたしましても、オラクル社およびその関連会社は一切の責任を負いかねます。

目次目次目次目次

はじめにはじめにはじめにはじめに .............................................................................................................................................................................. xix

対象読者 ......................................................................................................................................................................... xxドキュメントのアクセシビリティについて ............................................................................................................. xx関連ドキュメント ......................................................................................................................................................... xx

表記規則 ........................................................................................................................................................................ xxiサポートおよびサービス ............................................................................................................................................ xxi

Oracle Data Guard の新機能の新機能の新機能の新機能 ............................................................................................................................. xxiii

第第第第 I 部部部部概要および管理概要および管理概要および管理概要および管理

1 Oracle Data Guard の概要の概要の概要の概要

1.1 Data Guard 構成 .......................................................................................................................................... 1-2

1.1.1 プライマリ・データベース ................................................................................................................ 1-2

1.1.2 スタンバイ・データベース ................................................................................................................ 1-2

1.1.3 構成例 .................................................................................................................................................... 1-3

1.2 Data Guard サービス .................................................................................................................................. 1-31.2.1 REDO 転送サービス ........................................................................................................................... 1-4

1.2.2 ログ適用サービス ................................................................................................................................ 1-4

1.2.3 ロールの推移 ........................................................................................................................................ 1-5

1.3 Data Guard Broker ...................................................................................................................................... 1-61.3.1 Oracle Enterprise Manager の使用 ................................................................................................... 1-6

1.3.2 Data Guard コマンドライン・インタフェースの使用 .................................................................. 1-7

1.4 Data Guard 保護モード .............................................................................................................................. 1-81.5 Data Guard と補完テクノロジ .................................................................................................................. 1-91.6 Data Guard のメリットの要約 ................................................................................................................ 1-10

2 Data Guard スタート・ガイドスタート・ガイドスタート・ガイドスタート・ガイド

2.1 スタンバイ・データベースのタイプ ........................................................................................................ 2-22.1.1 フィジカル・スタンバイ・データベース ........................................................................................ 2-2

2.1.2 ロジカル・スタンバイ・データベース ............................................................................................ 2-4

2.2 Data Guard 構成の管理のためのユーザー・インタフェース .............................................................. 2-5

i

2.3 Data Guard の動作要件 .............................................................................................................................. 2-52.3.1 ハードウェアおよびオペレーティング・システムの要件 ............................................................ 2-5

2.3.2 Oracle ソフトウェア要件 ................................................................................................................... 2-6

2.4 スタンバイ・データベースのディレクトリ構造に関する考慮事項 .................................................... 2-72.5 オンライン REDO ログ、アーカイブ REDO ログおよびスタンバイ REDO ログ ............................ 2-92.5.1 オンライン REDO ログおよびアーカイブ REDO ログ ................................................................. 2-9

2.5.2 スタンバイ REDO ログ ..................................................................................................................... 2-10

3 フィジカル・スタンバイ・データベースの作成フィジカル・スタンバイ・データベースの作成フィジカル・スタンバイ・データベースの作成フィジカル・スタンバイ・データベースの作成

3.1 スタンバイ・データベースを作成するためのプライマリ・データベースの準備 ............................ 3-2

3.1.1 強制ロギングの有効化 ........................................................................................................................ 3-2

3.1.2 パスワード・ファイルの作成 ............................................................................................................ 3-2

3.1.3 スタンバイ REDO ログの構成 ........................................................................................................... 3-3

3.1.4 プライマリ・データベースの初期化パラメータの設定 ................................................................ 3-5

3.1.5 アーカイブの有効化 ............................................................................................................................ 3-7

3.2 フィジカル・スタンバイ・データベースの作成手順 ............................................................................ 3-83.2.1 プライマリ・データベース・データファイルのバックアップ・コピーの作成 ........................ 3-8

3.2.2 スタンバイ・データベース用の制御ファイルの作成 .................................................................... 3-8

3.2.3 スタンバイ・データベース用の初期化パラメータ・ファイルの準備 ........................................ 3-9

3.2.4 プライマリ・システムからスタンバイ・システムへのファイルのコピー .............................. 3-11

3.2.5 スタンバイ・データベースをサポートする環境の設定 .............................................................. 3-11

3.2.6 フィジカル・スタンバイ・データベースの起動 .......................................................................... 3-12

3.2.7 フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認 .............. 3-13

3.3 作成後の手順 .............................................................................................................................................. 3-14

4 ロジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースの作成

4.1 ロジカル・スタンバイ・データベースの作成要件 ................................................................................ 4-24.1.1 表のデータ型および記憶域属性のサポートの判別 ........................................................................ 4-2

4.1.2 プライマリ・データベース内の表の行が一意に識別できることの確認 .................................... 4-2

4.2 ロジカル・スタンバイ・データベースの作成手順 ................................................................................ 4-44.2.1 フィジカル・スタンバイ・データベースの作成 ............................................................................ 4-4

4.2.2 フィジカル・スタンバイ・データベースでの REDO Apply の停止 .......................................... 4-4

4.2.3 ロジカル・スタンバイ・データベースをサポートするためのプライマリ・データベースの

準備 ........................................................................................................................................................ 4-5

4.2.3.1 ロールの推移のためのプライマリ・データベースの準備 .................................................... 4-54.2.3.2 REDO データでのディクショナリの構築 ................................................................................ 4-64.2.4 ロジカル・スタンバイ・データベースへの推移 ............................................................................ 4-6

4.2.4.1 ロジカル・スタンバイ・データベースへの変換 .................................................................... 4-64.2.4.2 新規パスワード・ファイルの作成 ............................................................................................ 4-64.2.4.3 ロジカル・スタンバイ・データベース用の初期化パラメータの調整 ................................ 4-7

4.2.5 ロジカル・スタンバイ・データベースのオープン ........................................................................ 4-8

4.2.6 ロジカル・スタンバイ・データベースが正しく実行されているかどうかの確認 .................... 4-8

4.3 作成後の手順 ................................................................................................................................................ 4-8

ii

5 REDO 転送サービス転送サービス転送サービス転送サービス

5.1 REDO 転送サービスの概要 ....................................................................................................................... 5-2

5.2 REDO データの送信先 ............................................................................................................................... 5-35.2.1 宛先タイプ ............................................................................................................................................ 5-3

5.2.2 LOG_ARCHIVE_DEST_n パラメータを使用した宛先の構成 ..................................................... 5-4

5.2.2.1 宛先属性の変更 ............................................................................................................................ 5-65.2.2.2 V$ARCHIVE_DEST ビューを使用した属性の表示 ............................................................... 5-65.2.3 フラッシュ・リカバリ領域の設定 .................................................................................................... 5-6

5.2.3.1 LOG_ARCHIVE_DEST_10 の宛先の使用 ............................................................................... 5-75.2.3.2 他の LOG_ARCHIVE_DEST_n の宛先の使用 ........................................................................ 5-75.2.3.3 STANDBY_ARCHIVE_DEST の宛先の使用 ........................................................................... 5-85.2.3.4 プライマリ・データベースとスタンバイ・データベースでフラッシュ・リカバリ領域

を共有する .................................................................................................................................... 5-85.3 REDO データの送信方法 ........................................................................................................................... 5-9

5.3.1 アーカイバ・プロセス（ARCn）を使用した REDO データのアーカイブ ............................... 5-9

5.3.1.1 ARCn のアーカイブ動作を制御する初期化パラメータ ........................................................ 5-95.3.1.2 ARCn のアーカイブ処理 .......................................................................................................... 5-10

5.3.2 ログ・ライター・プロセス（LGWR）を使用した REDO データのアーカイブ .................... 5-11

5.3.2.1 LGWR アーカイブ・プロセスに関する LOG_ARCHIVE_DEST_n 属性 ......................... 5-115.3.2.2 LGWR SYNC アーカイブ・プロセス ..................................................................................... 5-125.3.2.3 LGWR ASYNC アーカイブ・プロセス ................................................................................. 5-13

5.3.3 セキュアな REDO データの転送の提供 ........................................................................................ 5-15

5.4 REDO データの送信時間 ......................................................................................................................... 5-165.4.1 VALID_FOR 属性を使用したロール・ベースの宛先の指定 ...................................................... 5-16

5.4.2 一意のプライマリ・データベース名とスタンバイ・データベース名の指定 .......................... 5-17

5.5 エラーが発生した場合の対処方法 .......................................................................................................... 5-185.5.1 アーカイブ操作の再試行 .................................................................................................................. 5-18

5.5.2 代替アーカイブ先の使用 .................................................................................................................. 5-18

5.5.3 再試行回数の制御 .............................................................................................................................. 5-19

5.6 データ保護モードの設定 .......................................................................................................................... 5-205.6.1 データ保護モードの選択 .................................................................................................................. 5-20

5.6.1.1 大保護モード .......................................................................................................................... 5-205.6.1.2 大可用性モード ...................................................................................................................... 5-205.6.1.3 大パフォーマンス・モード .................................................................................................. 5-20

5.6.2 Data Guard 構成のデータ保護モードの設定 ................................................................................ 5-21

5.7 ログ・ファイルの管理 .............................................................................................................................. 5-235.7.1 アーカイブ REDO ログ・ファイルの代替ディレクトリ位置の指定 ........................................ 5-23

5.7.2 オンライン REDO ログ・ファイルの再利用 ................................................................................ 5-24

5.7.3 スタンバイ REDO ログ・ファイルの管理 .................................................................................... 5-25

5.7.3.1 スタンバイ REDO ログ・ファイル・グループの構成が適切であるかの判断 ................ 5-25

5.7.3.2 スタンバイ REDO ログ・メンバーを既存のグループに追加 ............................................ 5-255.7.4 制御ファイルのサイズ拡大と再利用の計画 .................................................................................. 5-26

5.7.4.1 制御ファイルを含むディスク・ボリュームのサイズ設定 .................................................. 5-265.7.4.2 制御ファイル内のレコードの再利用の指定 .......................................................................... 5-26

5.7.5 複数のスタンバイ・データベース間でのログ・ファイル宛先の共有 ...................................... 5-27

iii

5.8 アーカイブ・ギャップの管理 .................................................................................................................. 5-285.8.1 アーカイブ・ギャップの検出時期 .................................................................................................. 5-28

5.8.2 ギャップの解決方法 .......................................................................................................................... 5-28

5.8.3 フェッチ・アーカイブ・ログ（FAL）を使用したアーカイブ・ギャップの解決 .................. 5-29

5.8.4 手動によるアーカイブ・ギャップの判断および解決 .................................................................. 5-30

5.9 確認 .............................................................................................................................................................. 5-32

5.9.1 ログ・ファイル・アーカイブ情報の監視 ...................................................................................... 5-32

5.9.2 REDO 転送サービスのパフォーマンスの監視 .............................................................................. 5-33

5.9.2.1 ARCn プロセスの待機イベント .............................................................................................. 5-33

5.9.2.2 LGWR SYNC 待機イベント ..................................................................................................... 5-345.9.2.3 LGWR ASYNC 待機イベント .................................................................................................. 5-34

6 ログ適用サービスログ適用サービスログ適用サービスログ適用サービス

6.1 ログ適用サービスの概要 ............................................................................................................................ 6-2

6.2 ログ適用サービスの構成オプション ........................................................................................................ 6-36.2.1 リアルタイム適用による REDO データの即時適用 ....................................................................... 6-3

6.2.2 アーカイブ REDO ログ・ファイルの適用に対するタイム・ディレイの指定 ........................... 6-4

6.2.2.1 タイム・ディレイ設定の代替策としてのフラッシュバック・データベースの使用 ........ 6-46.3 REDO データのフィジカル・スタンバイ・データベースへの適用 .................................................... 6-56.3.1 REDO Apply の開始 ........................................................................................................................... 6-5

6.3.2 リアルタイム適用の開始 .................................................................................................................... 6-5

6.3.3 ログ適用サービスの停止 .................................................................................................................... 6-6

6.3.4 フィジカル・スタンバイ・データベースでのログ適用サービスの監視 .................................... 6-6

6.4 REDO データのロジカル・スタンバイ・データベースへの適用 ........................................................ 6-6

6.4.1 SQL Apply の開始 ............................................................................................................................... 6-6

6.4.2 リアルタイム適用の開始 .................................................................................................................... 6-6

6.4.3 ロジカル・スタンバイ・データベースでのログ適用サービスの停止 ........................................ 6-6

6.4.4 ロジカル・スタンバイ・データベースでのログ適用サービスの監視 ........................................ 6-7

7 ロールの推移ロールの推移ロールの推移ロールの推移

7.1 ロールの推移の概要 .................................................................................................................................... 7-2

7.1.1 ロールの推移（フェイルオーバーまたはスイッチオーバー）の準備 ........................................ 7-2

7.1.2 ロールの推移のターゲット・スタンバイ・データベースの選択 ................................................ 7-3

7.1.3 スイッチオーバー ................................................................................................................................ 7-4

7.1.4 フェイルオーバー ................................................................................................................................ 7-6

7.2 フィジカル・スタンバイ・データベースが関与するロールの推移 .................................................... 7-77.2.1 フィジカル・スタンバイ・データベースが関与するスイッチオーバー .................................... 7-7

7.2.2 フィジカル・スタンバイ・データベースが関与するフェイルオーバー .................................. 7-10

7.3 ロジカル・スタンバイ・データベースが関与するロールの推移 ...................................................... 7-147.3.1 ロジカル・スタンバイ・データベースが関与するスイッチオーバー ...................................... 7-14

7.3.2 ロジカル・スタンバイ・データベースが関与するフェイルオーバー ...................................... 7-17

7.4 ロールの推移後のフラッシュバック・データベースの使用 .............................................................. 7-217.4.1 スイッチオーバー後のフラッシュバック・データベースの使用 .............................................. 7-21

7.4.2 フェイルオーバー後のフラッシュバック・データベースの使用 .............................................. 7-21

iv

8 フィジカル・スタンバイ・データベースの管理フィジカル・スタンバイ・データベースの管理フィジカル・スタンバイ・データベースの管理フィジカル・スタンバイ・データベースの管理

8.1 フィジカル・スタンバイ・データベースの起動と停止 ........................................................................ 8-2

8.1.1 フィジカル・スタンバイ・データベースの起動 ............................................................................ 8-2

8.1.2 フィジカル・スタンバイ・データベースの停止 ............................................................................ 8-3

8.2 スタンバイ・データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法 ... 8-3

8.2.1 スタンバイ・データベースをオープンするかどうかの評価 ........................................................ 8-5

8.2.2 読取り専用アクセス用にフィジカル・スタンバイ・データベースをオープン ........................ 8-6

8.3 スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理 ............ 8-7

8.3.1 データファイルの追加または表領域の作成 .................................................................................... 8-8

8.3.1.1 STANDBY_FILE_MANAGEMENT が AUTO に設定されている場合 .............................. 8-88.3.1.2 STANDBY_FILE_MANAGEMENT が MANUAL に設定されている場合 ....................... 8-98.3.2 表領域の削除とデータファイルの削除 .......................................................................................... 8-11

8.3.2.1 STANDBY_FILE_MANAGEMENT が AUTO または MANUAL に設定されている場合 .............................................................................................................................................. 8-11

8.3.2.2 DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES の使用 ................. 8-118.3.3 フィジカル・スタンバイ・データベースでのトランスポータブル表領域の使用 .................. 8-12

8.3.4 プライマリ・データベースのデータファイルの改名 .................................................................. 8-12

8.3.5 オンライン REDO ログ・ファイルの追加または削除 ................................................................ 8-14

8.3.6 ログに記録されていないまたはリカバリ不能な操作 .................................................................. 8-14

8.4 OPEN RESETLOGS 文を使用したリカバリ .......................................................................................... 8-15

8.5 プライマリおよびスタンバイ・データベースの監視 .......................................................................... 8-168.5.1 アラート・ログ .................................................................................................................................. 8-17

8.5.2 動的パフォーマンス・ビュー（固定ビュー） ................................................................................ 8-17

8.5.3 リカバリの進捗の監視 ...................................................................................................................... 8-18

8.5.3.1 プロセス・アクティビティの監視 .......................................................................................... 8-188.5.3.2 REDO Apply の進捗の確認 ..................................................................................................... 8-188.5.3.3 アーカイブ REDO ログ・ファイルの位置および作成者の確認 ........................................ 8-19

8.5.3.4 OPEN RESETLOGS の前後のデータベース・インカネーションの表示 ......................... 8-198.5.3.5 アーカイブ REDO ログ履歴の表示 ........................................................................................ 8-208.5.3.6 スタンバイ・データベースに適用されたログ・ファイルの確認 ...................................... 8-20

8.5.3.7 スタンバイ・サイトが受信しなかったログ・ファイルの確認 .......................................... 8-218.5.4 フィジカル・スタンバイ・データベースでのログ適用サービスの監視 .................................. 8-22

8.5.4.1 V$DATABASE ビューへのアクセス ...................................................................................... 8-228.5.4.2 V$MANAGED_STANDBY 固定ビューへのアクセス ......................................................... 8-22

8.5.4.3 V$ARCHIVE_DEST_STATUS 固定ビューへのアクセス .................................................... 8-238.5.4.4 V$ARCHIVED_LOG 固定ビューへのアクセス ................................................................... 8-238.5.4.5 V$LOG_HISTORY 固定ビューへのアクセス ....................................................................... 8-23

8.5.4.6 V$DATAGUARD_STATUS 固定ビューへのアクセス ........................................................ 8-248.6 フィジカル・スタンバイ・データベースに関するログ適用レートのチューニング ...................... 8-25

9 ロジカル・スタンバイ・データベースの管理ロジカル・スタンバイ・データベースの管理ロジカル・スタンバイ・データベースの管理ロジカル・スタンバイ・データベースの管理

9.1 SQL Apply アーキテクチャの概要 ........................................................................................................... 9-2

9.1.1 SQL Apply に関する各種の考慮事項 ............................................................................................... 9-3

9.1.1.1 トランザクション・サイズの考慮事項 .................................................................................... 9-39.1.1.2 ページアウトの考慮事項 ............................................................................................................ 9-4

9.1.1.3 再開の考慮事項 ............................................................................................................................ 9-49.1.1.4 DML 適用の考慮事項 ................................................................................................................. 9-49.1.1.5 DDL 適用の考慮事項 .................................................................................................................. 9-5

v

9.2 ロジカル・スタンバイ・データベースの管理および監視関連のビュー ............................................ 9-59.2.1 DBA_LOGSTDBY_EVENTS ビュー ................................................................................................. 9-5

9.2.2 DBA_LOGSTDBY_LOG ビュー ........................................................................................................ 9-6

9.2.3 V$LOGSTDBY_STATS ビュー ........................................................................................................... 9-7

9.2.4 V$LOGSTDBY_PROCESS ビュー ..................................................................................................... 9-7

9.2.5 V$LOGSTDBY_PROGRESS ビュー .................................................................................................. 9-8

9.2.6 V$LOGSTDBY_STATE ビュー .......................................................................................................... 9-9

9.2.7 V$LOGSTDBY_STATS ビュー ......................................................................................................... 9-10

9.3 ロジカル・スタンバイ・データベースの監視 ...................................................................................... 9-11

9.3.1 SQL Apply の進捗の監視 ................................................................................................................. 9-11

9.3.2 ログ・ファイルの自動削除 .............................................................................................................. 9-14

9.4 ロジカル・スタンバイ・データベースのカスタマイズ ...................................................................... 9-159.4.1 ロジカル・スタンバイ・データベースでのリアルタイム適用の使用 ...................................... 9-15

9.4.2 DBA_LOGSTDBY_EVENTS ビューでのイベントのロギングのカスタマイズ ....................... 9-15

9.4.3 DBMS_LOGSTDBY.SKIP による特定のスキーマ・オブジェクトに対する変更の防止 ........ 9-16

9.4.4 DDL 文のスキップ・ハンドラの設定 ............................................................................................ 9-16

9.4.5 ロジカル・スタンバイ・データベースの変更 .............................................................................. 9-17

9.4.5.1 ロジカル・スタンバイ・データベースでの DDL の実行 ................................................... 9-179.4.5.2 SQL Apply でメンテナンスされていない表の変更 ............................................................. 9-18

9.4.6 ロジカル・スタンバイ・データベースでの表の追加または再作成 .......................................... 9-19

9.5 ロジカル・スタンバイ・データベースのコンテキストにおける特定のワークロードの管理 ...... 9-209.5.1 プライマリ・データベースへのトランスポータブル表領域のインポート .............................. 9-20

9.5.2 マテリアライズド・ビューの使用 .................................................................................................. 9-21

9.5.3 ロジカル・スタンバイ・データベースでのトリガーと制約の処理方法 .................................. 9-21

9.5.4 OPEN RESETLOGS 文を使用したリカバリ .................................................................................. 9-22

9.6 ロジカル・スタンバイ・データベースのチューニング ...................................................................... 9-23

9.6.1 主キー RELY 制約の作成 .................................................................................................................. 9-23

9.6.2 コストベース・オプティマイザの統計の収集 .............................................................................. 9-24

9.6.3 プロセス数の調整 .............................................................................................................................. 9-24

9.6.3.1 APPLIER プロセス数の調整 .................................................................................................... 9-249.6.3.2 PREPARER プロセス数の調整 ................................................................................................ 9-259.6.4 LCR キャッシュ用メモリーの調整 ................................................................................................. 9-26

9.6.5 ロジカル・スタンバイ・データベースにおけるトランザクションの適用方法の調整 .......... 9-27

10 Recovery Manager を使用したファイルのバックアップおよびリストアを使用したファイルのバックアップおよびリストアを使用したファイルのバックアップおよびリストアを使用したファイルのバックアップおよびリストア

10.1 バックアップ処理 ...................................................................................................................................... 10-210.1.1 テープ・バックアップ用キャッシュとしてのディスクの使用 .................................................. 10-2

10.1.2 テープへの直接バックアップの実行 .............................................................................................. 10-3

10.2 スイッチオーバー、フェイルオーバーおよび制御ファイル作成がバックアップに与える影響 ... 10-310.2.1 プライマリ・データベースのデータファイル消失からのリカバリ .......................................... 10-4

10.2.2 スタンバイ・データベースのデータファイル消失からのリカバリ .......................................... 10-4

10.2.3 スタンバイ制御ファイルの消失からのリカバリ .......................................................................... 10-5

10.2.4 プライマリ制御ファイルの消失からのリカバリ .......................................................................... 10-5

10.2.5 オンライン REDO ログ・ファイルの消失からのリカバリ ......................................................... 10-6

10.2.6 データベースの不完全リカバリ ...................................................................................................... 10-7

vi

10.3 その他のバックアップ状況 ...................................................................................................................... 10-810.3.1 スタンバイ・データベースが地理的に離れすぎているためにバックアップを共有できない

場合 ...................................................................................................................................................... 10-8

10.3.2 FAL サーバーとして使用されるスタンバイ・データベースにデータファイルが含まれて

いない場合 .......................................................................................................................................... 10-9

10.3.3 スタンバイ・データベースのファイル名がプライマリ・データベースとは異なる場合 ...... 10-9

10.3.4 フラッシュ・リカバリ領域のアーカイブ REDO ログ・ファイルに関する削除ポリシー .... 10-9

10.3.4.1 ロールが推移した後の削除ポリシーの再構成 .................................................................... 10-1110.3.4.2 現行の削除ポリシーの表示 .................................................................................................... 10-11

11 SQL Apply を使用したを使用したを使用したを使用した Oracle Database のアップグレードのアップグレードのアップグレードのアップグレード

11.1 SQL Apply を使用するローリング・アップグレードのメリット ..................................................... 11-211.2 SQL Apply を使用してローリング・アップグレードを実行するための要件 ................................. 11-211.3 アップグレード手順に使用する図と表記規則 ...................................................................................... 11-311.4 アップグレードの準備 .............................................................................................................................. 11-3

11.5 データベースのアップグレード .............................................................................................................. 11-6

12 Data Guard の使用例の使用例の使用例の使用例

12.1 アーカイブ先の設定および確認 .............................................................................................................. 12-2

12.1.1 プライマリ・データベースおよびフィジカル・スタンバイ・データベースの構成 .............. 12-2

12.1.2 プライマリ・データベースおよびロジカル・スタンバイ・データベースの構成 .................. 12-4

12.1.3 フィジカルおよびロジカル・スタンバイ・データベースの構成 .............................................. 12-7

12.1.4 各宛先について現行の VALID_FOR 属性設定の確認 ................................................................. 12-9

12.2 ロールの推移に適なスタンバイ・データベースの選択 ................................................................ 12-1012.2.1 例 : フェイルオーバーに適なフィジカル・スタンバイ・データベース ............................. 12-11

12.2.2 例 : フェイルオーバーに適なロジカル・スタンバイ・データベース ................................. 12-17

12.3 新規プライマリ・データベースをサポートするロジカル・スタンバイ・データベースの構成 ... 12-2112.3.1 新規プライマリ・データベースがフィジカル・スタンバイ・データベースだった場合 .... 12-21

12.3.2 新規プライマリ・データベースがロジカル・スタンバイ・データベースだった場合 ........ 12-22

12.4 フェイルオーバー後のフラッシュバック・データベースの使用 .................................................... 12-2412.4.1 障害が発生したプライマリ・データベースのフィジカル・スタンバイ・データベースへの

フラッシュバック ............................................................................................................................ 12-25

12.4.2 障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへの

フラッシュバック ............................................................................................................................ 12-26

12.4.3 特定の適用済 SCN へのロジカル・スタンバイ・データベースのフラッシュバック ......... 12-27

12.5 Open Resetlogs 文の発行後のフラッシュバック・データベースの使用 ....................................... 12-2812.5.1 特定時点へのフィジカル・スタンバイ・データベースのフラッシュバック ........................ 12-28

12.5.2 プライマリのフラッシュバック後のロジカル・スタンバイ・データベースの

フラッシュバック ............................................................................................................................ 12-29

12.6 フィジカル・スタンバイ・データベースを使用した読取り / 書込みテストとレポート生成 ... 12-3012.7 Recovery Manager の増分バックアップによるフィジカル・スタンバイ・データベースの

ロールフォワード .................................................................................................................................... 12-3412.7.1 フィジカル・スタンバイ・データベースがプライマリ・データベースから大幅に遅れて

いる場合 ............................................................................................................................................ 12-34

12.7.2 フィジカル・スタンバイ・データベースのデータファイルのサブセットにロギングなしの

変更がある場合 ................................................................................................................................ 12-36

12.7.3 フィジカル・スタンバイ・データベースの広範囲にロギングなしの変更がある場合 ........ 12-38

vii

12.8 タイム・ラグのあるフィジカル・スタンバイ・データベースの使用 ............................................ 12-3912.8.1 フィジカル・スタンバイ・データベースでのタイム・ラグの設定 ........................................ 12-40

12.8.2 タイム・ラグのあるフィジカル・スタンバイ・データベースへのフェイルオーバー ........ 12-40

12.8.3 タイム・ラグのあるフィジカル・スタンバイ・データベースへのスイッチオーバー ........ 12-41

12.9 ネットワーク障害のリカバリ ................................................................................................................ 12-4212.10 NOLOGGING 句を指定した後のリカバリ ......................................................................................... 12-43

12.10.1 ロジカル・スタンバイ・データベースのリカバリ手順 ............................................................ 12-43

12.10.2 フィジカル・スタンバイ・データベースのリカバリ手順 ........................................................ 12-43

12.10.3 リカバリ不能処理後にバックアップが必要かどうかの判断 .................................................... 12-45

12.11 手動によるアーカイブ・ギャップの解決 ............................................................................................ 12-4612.11.1 アーカイブ・ギャップの発生原因 ................................................................................................ 12-46

12.11.1.1 スタンバイ・データベースの作成 ........................................................................................ 12-4612.11.1.2 プライマリ・データベースがオープンしている間のスタンバイ・データベースの

停止 ............................................................................................................................................ 12-4712.11.1.3 REDO の転送を妨げるネットワーク障害 ............................................................................ 12-48

12.11.2 アーカイブ・ギャップが存在するかどうかの判断 .................................................................... 12-48

12.11.3 スタンバイ・サイトへのアーカイブ・ギャップ・ログ・ファイルの手動による転送 ........ 12-49

12.11.4 スタンバイ・データベースへのアーカイブ・ギャップ・ログ・ファイルの手動による

適用 .................................................................................................................................................... 12-50

12.12 OMF または ASM を使用するスタンバイ・データベースの作成 ................................................... 12-51

第第第第 II 部部部部参照先参照先参照先参照先

13 初期化パラメータ初期化パラメータ初期化パラメータ初期化パラメータ

14 LOG_ARCHIVE_DEST_n パラメータの属性パラメータの属性パラメータの属性パラメータの属性

AFFIRM および NOAFFIRM ................................................................................................................... 14-2

ALTERNATE .............................................................................................................................................. 14-4

ARCH および LGWR ................................................................................................................................ 14-6

DB_UNIQUE_NAME .............................................................................................................................. 14-7

DELAY ........................................................................................................................................................ 14-8

DEPENDENCY ........................................................................................................................................ 14-10

LOCATION および SERVICE ................................................................................................................ 14-12

MANDATORY および OPTIONAL ..................................................................................................... 14-14

MAX_CONNECTIONS .......................................................................................................................... 14-16

MAX_FAILURE ....................................................................................................................................... 14-17

NET_TIMEOUT ...................................................................................................................................... 14-19

NOREGISTER .......................................................................................................................................... 14-21

REOPEN .................................................................................................................................................... 14-22

SYNC および ASYNC ............................................................................................................................. 14-23

TEMPLATE ............................................................................................................................................... 14-24

VALID_FOR ............................................................................................................................................. 14-26

VERIFY ...................................................................................................................................................... 14-28

viii

15 Data Guard に関連するに関連するに関連するに関連する SQL 文文文文

15.1 ALTER DATABASE 文 ............................................................................................................................. 15-2

15.2 ALTER SESSION 文 .................................................................................................................................. 15-4

16 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-4A.3 ロジカル・スタンバイ・データベース障害の処理 ................................................................................ A-4A.4 スタンバイ・データベースへのスイッチオーバーの問題 .................................................................... A-5

A.4.1 REDO データが転送されていないためスイッチオーバーできない ........................................... A-5

A.4.2 SQL セッションがアクティブなためスイッチオーバーできない ............................................... A-5

A.4.3 ユーザー・セッションがアクティブなためスイッチオーバーできない .................................... A-7

A.4.4 ORA-01102 エラーによりスイッチオーバーできない .................................................................. A-7

A.4.5 スイッチオーバー後に REDO データが適用されない .................................................................. A-8

A.4.6 失敗したスイッチオーバーをロールバックして初からやり直す ............................................ A-8

A.5 SQL Apply が停止した場合の処置 ........................................................................................................... A-9A.6 REDO データ転送のネットワーク調整 ................................................................................................. A-10A.7 スタンバイ・データベースのディスクのパフォーマンスが遅い ...................................................... A-10A.8 プライマリ・データベースの停止を回避するにはログ・ファイルを一致させる必要がある ...... A-10

A.9 ロジカル・スタンバイ・データベースのトラブルシューティング .................................................. A-11A.9.1 エラーのリカバリ .............................................................................................................................. A-11

A.9.1.1 ファイル仕様が含まれている DDL トランザクション ....................................................... A-11

A.9.1.2 DML 障害のリカバリ ............................................................................................................... A-12A.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-2B.2 フィジカル・スタンバイ・データベースが存在する場合の Oracle Database のアップグレード ... B-2

B.3 ロジカル・スタンバイ・データベースが存在する場合の Oracle Database のアップグレード ..... B-5

ix

C ロジカル・スタンバイ・データベースでサポートされるデータ型およびロジカル・スタンバイ・データベースでサポートされるデータ型およびロジカル・スタンバイ・データベースでサポートされるデータ型およびロジカル・スタンバイ・データベースでサポートされるデータ型および DDLC.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-4C.5 ロジカル・スタンバイ・データベースでスキップされる SQL 文 ..................................................... C-5

C.6 ロジカル・スタンバイ・データベースでサポートされる DDL 文 .................................................... C-5

D Data Guard およびおよびおよびおよび Real Application ClustersD.1 Real Application Clusters 環境でのスタンバイ・データベースの構成 ............................................. D-2

D.1.1 複数インスタンス・プライマリ・データベースと単一インスタンス・スタンバイ・

データベースの設定 ........................................................................................................................... D-2

D.1.2 複数インスタンス・プライマリ・データベースと複数インスタンス・スタンバイ・

データベースの設定 ........................................................................................................................... D-3

D.2 Real Application Clusters 環境での構成に関する考慮事項 ................................................................ D-5D.2.1 アーカイブ REDO ログ・ファイル名の形式 .................................................................................. D-5

D.2.2 アーカイブ先の割当て制限 ............................................................................................................... D-5

D.2.3 データ保護モード ............................................................................................................................... D-6

D.2.4 ロールの推移 ....................................................................................................................................... D-6

D.2.4.1 スイッチオーバー ....................................................................................................................... D-6D.2.4.2 フェイルオーバー ....................................................................................................................... D-6

D.3 トラブルシューティング ........................................................................................................................... D-7D.3.1 Real Application Clusters 構成でスイッチオーバーできない ..................................................... D-7

D.3.2 ネットワーク停止時に Real Application Clusters の停止時間を回避する ................................ D-7

E カスケードされた宛先カスケードされた宛先カスケードされた宛先カスケードされた宛先

E.1 カスケードされた宛先の構成 .................................................................................................................... E-3E.1.1 フィジカル・スタンバイ・データベースに対するカスケードされた宛先の構成 .................... E-3

E.1.2 ロジカル・スタンバイ・データベースに対するカスケードされた宛先の構成 ........................ E-4

E.2 カスケードされた宛先を使用したロールの推移 .................................................................................... E-5E.2.1 フィジカル・スタンバイ・データベースから REDO データを受信するスタンバイ・

データベース ........................................................................................................................................ E-5

E.2.2 ロジカル・スタンバイ・データベースから REDO データを受信するスタンバイ・

データベース ......................................................................................................................................... E-5

E.3 カスケードされた宛先の例 ........................................................................................................................ E-5E.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

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-8F.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.5.1.1 リカバリを実行しないスタンバイ・データベースの作成 .................................................. F-12

F.5.1.2 スタンバイ・データベースの作成およびリカバリの実行 .................................................. F-12F.5.2 SET NEWNAME を使用したスタンバイ・データベース・ファイルのネーミング .............. F-13


F.5.2.2 スタンバイ・データベースの作成およびリカバリの実行 .................................................. F-13F.5.3 CONFIGURE AUXNAME を使用したスタンバイ・データベース・ファイルのネーミング ... F-14


F.5.3.2 スタンバイ・データベースの作成およびリカバリの実行 .................................................. F-15F.6 ローカル・ホスト上へのスタンバイ・データベースの作成 .............................................................. F-16F.7 イメージ・コピーを使用したスタンバイ・データベースの作成 ...................................................... F-17F.7.1 概要 ...................................................................................................................................................... F-17

F.7.2 コピーおよびデータファイルで同一の名前を使用する場合 ...................................................... F-18

F.7.3 コピーおよびデータファイルで異なる名前を使用する場合 ...................................................... F-19


F.7.3.2 スタンバイ・データベースの作成およびリカバリの実行 .................................................. F-20F.8 使用例 .......................................................................................................................................................... F-21

G アーカイブ・トレースの設定アーカイブ・トレースの設定アーカイブ・トレースの設定アーカイブ・トレースの設定

G.1 LOG_ARCHIVE_TRACE 初期化パラメータ .......................................................................................... G-2G.2 トレース・ファイルの位置の判別 ............................................................................................................ G-2G.2.1 LOG_ARCHIVE_TRACE 初期化パラメータの設定 ...................................................................... G-2

G.2.2 整数値の選択 ........................................................................................................................................ G-3

索引索引索引索引

xi

xii

例例例例

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

xiii

xiv

図図図図

1-1 一般的な Data Guard 構成 ......................................................................................................................... 1-31-2 フィジカル・スタンバイ・データベースの自動更新 ............................................................................ 1-41-3 ロジカル・スタンバイ・データベースの自動更新 ................................................................................ 1-51-4 Oracle Enterprise Manager の Data Guard 概要ページ ........................................................................ 1-72-1 可能なスタンバイ構成 ................................................................................................................................ 2-85-1 REDO データの転送 ................................................................................................................................... 5-25-2 スタンバイ・データベースがない場合のプライマリ・データベースのアーカイブ処理 ................ 5-55-3 リモートの宛先にアーカイブする前にローカルの宛先にアーカイブする ...................................... 5-105-4 スタンバイ REDO ログ・ファイルを使用したリモートの宛先への LGWR SYNC アーカイブ ... 5-135-5 ネットワーク・サーバー（LNSn）プロセスを使用した LGWR ASYNC アーカイブ .................. 5-145-6 代替アーカイブ先のデバイスへのアーカイブ操作 .............................................................................. 5-195-7 依存する宛先を含む Data Guard 構成 ................................................................................................... 5-276-1 リアルタイム適用を使用したスタンバイ宛先への REDO データの適用 .......................................... 6-37-1 スイッチオーバー前の Data Guard 構成 ................................................................................................. 7-47-2 新しいプライマリ・データベースへのスイッチオーバー前のスタンバイ・データベース ............ 7-47-3 スイッチオーバー後の Data Guard 環境 ................................................................................................. 7-57-4 スタンバイ・データベースへのフェイルオーバー ................................................................................ 7-68-1 読取り専用アクセス用にオープンしたスタンバイ・データベース .................................................... 8-49-1 SQL Apply の処理 ....................................................................................................................................... 9-29-2 SQL Apply 処理中の進捗状態 ................................................................................................................. 9-1111-1 アップグレード前の Data Guard 構成 ................................................................................................... 11-311-2 ロジカル・スタンバイ・データベースのリリースのアップグレード .............................................. 11-611-3 混合リリースの実行 .................................................................................................................................. 11-711-4 スイッチオーバー後 .................................................................................................................................. 11-911-5 両方のデータベースがアップグレードされた後 ................................................................................ 11-1012-1 ロールの推移前のプライマリおよびフィジカル・スタンバイ・データベース .............................. 12-212-2 ロールの推移後のプライマリおよびフィジカル・スタンバイ・データベース .............................. 12-312-3 プライマリ・データベースおよびロジカル・スタンバイ・データベースの宛先の構成 .............. 12-412-4 ロールの推移後のプライマリおよびロジカル・スタンバイ・データベース .................................. 12-612-5 フィジカルおよびロジカル・スタンバイ・データベースを備えたプライマリ・データベースの

構成 .............................................................................................................................................................. 12-712-6 ロールの推移後のプライマリ、フィジカルおよびロジカル・スタンバイ・データベース .......... 12-812-7 テストおよびレポート生成用データベースとしてのフィジカル・スタンバイ・データベースの

使用 ............................................................................................................................................................ 12-3012-8 アーカイブ・ギャップ内にあるアーカイブ REDO ログ・ファイルの手動リカバリ .................. 12-47D-1 複数インスタンス・プライマリ・データベースからの REDO データの転送 .................................. D-2D-2 Real Application Clusters のスタンバイ・データベース ..................................................................... D-3E-1 カスケードされた宛先の構成例 ................................................................................................................ E-1

xv

xvi

表表表表

2-1 スタンバイ・データベースの位置とディレクトリ・オプション ........................................................ 2-83-1 フィジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備 .... 3-23-2 フィジカル・スタンバイ・データベースの作成 .................................................................................... 3-84-1 ロジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備 ........ 4-24-2 ロジカル・スタンバイ・データベースの作成 ........................................................................................ 4-45-1 LOG_ARCHIVE_DEST_STATE_n 初期化パラメータの属性 .............................................................. 5-45-2 データ保護モードの低要件 .................................................................................................................. 5-215-3 ARCH 属性で構成される宛先の待機イベント ..................................................................................... 5-335-4 LGWR SYNC 属性で構成される宛先の待機イベント ......................................................................... 5-345-5 LGWR ASYNC 属性で構成される宛先の待機イベント ..................................................................... 5-348-1 プライマリ・データベースでの変更後にスタンバイ・データベースで必要なアクション ............ 8-78-2 プライマリ・データベースの共通アクションを監視できる場所 ...................................................... 8-1611-1 Oracle Database ソフトウェアをアップグレードする手順 ................................................................ 11-612-1 Data Guard の使用例 ................................................................................................................................ 12-112-2 プライマリ・データベースとフィジカル・スタンバイ・データベースの初期化パラメータの

設定 .............................................................................................................................................................. 12-212-3 プライマリ・データベースとロジカル・スタンバイ・データベースの初期化パラメータの

設定 .............................................................................................................................................................. 12-412-4 プライマリ・データベース、フィジカル・スタンバイ・データベースおよび

ロジカル・スタンバイ・データベースの初期化パラメータ .............................................................. 12-712-5 フィジカル・スタンバイ・データベースの例で使用される識別子 ................................................ 12-1112-6 ロジカル・スタンバイ・データベースの例で使用される識別子 .................................................... 12-1713-1 Data Guard 構成内のインスタンスの初期化パラメータ .................................................................... 13-214-1 TEMPLATE 属性のディレクティブ ..................................................................................................... 14-2414-2 VALID_FOR 属性の値 ............................................................................................................................ 14-2715-1 Data Guard 環境で使用される ALTER DATABASE 文 ...................................................................... 15-215-2 Data Guard 環境で使用される ALTER SESSION 文 ........................................................................... 15-416-1 Data Guard 構成に関連のあるビュー .................................................................................................... 16-1A-1 スイッチオーバーを妨げる共通のプロセス ............................................................................................ A-6A-2 一般的な SQL Apply エラーの解決方法 .................................................................................................. A-9C-1 DBMS_LOGSTDBY.SKIP プロシージャの stmt パラメータの値 ........................................................ C-5C-2 SQL DDL 文スキップ用の文のオプション ............................................................................................. C-7D-1 LOG_ARCHIVE_FORMAT 初期化パラメータのディレクティブ ...................................................... D-5E-1 プライマリ・データベース、フィジカル・スタンバイ・データベースおよび

ロジカル・スタンバイ・データベースの初期化パラメータ ................................................................ E-3F-1 Recovery Manager を使用したスタンバイ・データベースの準備 ..................................................... F-2F-2 スタンバイ・データベース内のデータファイルのネーミング優先順位 ............................................ F-5F-3 イメージ・コピーを使用したスタンバイ・データベースの作成 : 使用例 ....................................... F-17

xvii

xviii

はじめにはじめにはじめにはじめに

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

xix

対象読者対象読者対象読者対象読者『Oracle Data Guard 概要および管理』は、Oracle データベース・システムのバックアップ、リストアおよびリカバリ操作を管理するデータベース管理者を対象としています。

このマニュアルは、読者がリレーショナル・データベースの概念と、基本的なバックアップおよびリカバリ管理に精通していることを前提としています。また、Oracle ソフトウェアを実行するオペレーティング・システム環境をよく理解している必要があります。

ドキュメントのアクセシビリティについてドキュメントのアクセシビリティについてドキュメントのアクセシビリティについてドキュメントのアクセシビリティについてオラクル社は、障害のあるお客様にもオラクル社の製品、サービスおよびサポート・ドキュメントを簡単にご利用いただけることを目標としています。オラクル社のドキュメントには、ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています。HTML 形式のドキュメントで用意されており、障害のあるお客様が簡単にアクセスできるようにマークアップされています。標準規格は改善されつつあります。オラクル社はドキュメントをすべてのお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています。オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility Program の Web サイト http://www.oracle.com/accessibility/ を参照してください。

ドキュメント内のサンプル・コードのアクセシビリティについてドキュメント内のサンプル・コードのアクセシビリティについてドキュメント内のサンプル・コードのアクセシビリティについてドキュメント内のサンプル・コードのアクセシビリティについて

一部スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じ括弧だけを行に記述する必要があります。しかし 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

� 『SQL*Plus ユーザーズ・ガイドおよびリファレンス』

� 『Oracle Database 高可用性概要』

Oracle Streams および Streams のダウンストリーム取得データベースの詳細は、『Oracle Streams 概要および管理』も参照してください。 Streams のダウンストリーム取得プロセスは、Oracle Data Guard の REDO 転送サービスを使用して、REDO データをリモート・データベース上のログ・ファイルに転送します。リモート・データベースでは、Streams の取得プロセスにより、リモート宛先でのアーカイブ REDO ログ・ファイルの変更点が取得されます。

表記規則表記規則表記規則表記規則このマニュアルの本文では、次の表記規則が使用されています。

サポートおよびサービスサポートおよびサービスサポートおよびサービスサポートおよびサービス次の各項に、各サービスに接続するための URL を記載します。

Oracle サポート・サービスサポート・サービスサポート・サービスサポート・サービスオラクル製品サポートの購入方法、および Oracle サポート・サービスへの連絡方法の詳細は、次の URL を参照してください。

http://www.oracle.com/lang/jp/support/index.html

製品マニュアル製品マニュアル製品マニュアル製品マニュアル製品のマニュアルは、次の URL にあります。

http://www.oracle.com/technology/global/jp/documentation/index.html

研修およびトレーニング研修およびトレーニング研修およびトレーニング研修およびトレーニング研修に関する情報とスケジュールは、次の URL で入手できます。

http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=3

その他の情報その他の情報その他の情報その他の情報オラクル製品やサービスに関するその他の情報については、次の URL から参照してください。

http://www.oracle.com/lang/jp/index.htmlhttp://www.oracle.com/technology/global/jp/index.html

規則規則規則規則意味意味意味意味

太字太字太字太字太字は、操作に関連する Graphical User Interface 要素、または本文中で定

義されている用語および用語集に記載されている用語を示します。

イタリック体イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面

に表示されるテキスト、または入力するテキストを示します。

注意注意注意注意 : ドキュメント内に記載されている URL や参照ドキュメントには、Oracle Corporation が提供する英語の情報も含まれています。日本語版の情報については、前述の URL を参照してください。

xxi

xxii

Oracle Data Guard の新機能の新機能の新機能の新機能

この項では、Oracle Data Guard リリース 10.2 に追加された新機能について説明し、詳細情報へのリンクを提供します。 10g リリース 2（10.2）の Oracle Data Guard には、この項で説明する新機能と拡張機能が追加されました。新機能を、次の主な内容にわけて説明します。

� REDO Apply と SQL Apply に共通する新機能

� REDO Apply およびフィジカル・スタンバイ・データベース固有の新機能

� SQL Apply およびロジカル・スタンバイ・データベース固有の新機能

xxiii

REDO Apply とととと SQL Apply に共通する新機能に共通する新機能に共通する新機能に共通する新機能

10g リリース 2（10.2）の Oracle Data Guard に対する次の拡張機能により、利便性、管理性およびパフォーマンスが向上し、障害時リカバリ機能を改善する新機能が追加されています。

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

ファスト・スタート・フェイルオーバーは、プライマリ・データベースが消失した場合に、指定した同期スタンバイ・データベースに自動的に、迅速かつ確実にフェイルオーバーする機能を提供します。フェイルオーバーを起動するために複雑な手動ステップを実行する必要はありません。

また、ファスト・スタート・フェイルオーバーの発生後は、構成に再接続すると自動的に古いプライマリ・データベースが新しいスタンバイ・データベースとして再構成されます。これにより、Data Guard は複雑な手動ステップなしで容易に構成に障害時保護をリストアできるため、Data Guard の障害時リカバリ機能の堅牢性が向上するのみでなく、Data Guard の管理性も向上します。

これらの新機能により、稼働時間を維持して可用性を高め、障害時リカバリの堅牢性も改善できます。さらに、手動による介入の必要性が減少することで、管理コストが削減されます。

� Data Guard のスイッチオーバー間のフラッシュバック・データベースのスイッチオーバー間のフラッシュバック・データベースのスイッチオーバー間のフラッシュバック・データベースのスイッチオーバー間のフラッシュバック・データベース

プライマリ・データベースとスタンバイ・データベースを、スイッチオーバー操作前の時点または SCN までフラッシュバックできるようになりました。このフラッシュバック・データベースの機能をフィジカル・スタンバイ・データベースで使用すると、スタンバイ・ロールが保持されます。ロジカル・スタンバイ・データベースでは、スタンバイ・データベースのロールがターゲット SCN またはターゲット時点でのロールに変更されます。

この機能によりフラッシュバック・ウィンドウが拡張され、より柔軟に人為的エラーを検出して修正できます。

� 非同期非同期非同期非同期 REDO 転送転送転送転送

ログ・ライター・プロセス（LGWR ASYNC）を使用する非同期 REDO 転送は、プライマリ・データベースのパフォーマンス低下を軽減するように改善されました。非同期 REDO転送中は、ネットワーク・サーバー（LNSn）プロセスがプライマリ・データベースのオンライン REDO ログ・ファイルから REDO データを転送します。ログ・ライター・プロセスと直接相互作用することはなくなりました。

この動作変更により、ログ・ライター・プロセスは現行のオンライン REDO ログ・ファイルに REDO データを書き込み、プロセス間通信やネットワーク I/O の完了を待機せずに次の要求の処理を続行できます。

� LOG_ARCHIVE_DEST_n パラメータの新しいパラメータの新しいパラメータの新しいパラメータの新しい MAX_CONNECTIONS 属性属性属性属性

この属性は、プライマリ・データベースのアーカイバ（ARCn）プロセスで REDO データをスタンバイ・データベースに送信するタイミングを調整する方法を指定します。 MAX_CONNECTIONS属性を 0（ゼロ）以外の値に設定すると、REDO 転送サービスでは複数のネットワーク接続とアーカイバ・プロセスを使用して REDO データが転送されます。

関連項目関連項目関連項目関連項目 : 『Oracle Data Guard Broker』

関連項目関連項目関連項目関連項目 : 7.4 項「ロールの推移後のフラッシュバック・データベースの使用」

関連項目関連項目関連項目関連項目 : 5.3.2.3 項「LGWR ASYNC アーカイブ・プロセス」および第14 章の「SYNC および ASYNC」属性の説明を参照してください。

関連項目関連項目関連項目関連項目 : 14-16 ページの「MAX_CONNECTIONS」属性

xxiv

� 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

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

ファスト・スタート・フェイルオーバーが使用可能な場合にファスト・スタート・フェイルオーバーが発生すると、このメトリックにより新しいプライマリ・データベース（古いスタンバイ・データベース）でクリティカル・アラートが生成されます。ファスト・スタート・フェイルオーバーの SCN は、メトリックによりアラートが生成される前の値に初期化する必要があります。通常、これは 1 収集間隔です。ファスト・スタート・フェイルオーバーが発生した場合に新しいプライマリ・データベースの準備が完了していると、ファスト・スタート・フェイルオーバー・アラートが生成されます。このアラートは、1 収集間隔後に消去されます。デフォルトではクリティカル・アラートが構成されます。


* 値は、メトリックのトリガー準備が完了していることを示します。

– ファスト・スタート・フェイルオーバーの時間

ファスト・スタート・フェイルオーバーが使用可能な場合にファスト・スタート・フェイルオーバーが発生すると、このメトリックにより新しいプライマリ・データベース（古いスタンバイ・データベース）でクリティカル・アラートが生成されます。ファスト・スタート・フェイルオーバーの SCN は、メトリックによりアラートが作成される前の値に初期化する必要があります。通常、これは 1 収集間隔です。ファスト・スタート・フェイルオーバーが発生した場合に新しいプライマリ・データベースの準備が完了していると、ファスト・スタート・フェイルオーバー・アラートが実行されます。その後、1 収集間隔後に消去されます。デフォルトではクリティカル・アラートが構成されます。


* ファスト・スタート・フェイルオーバーが発生した場合は、タイムスタンプが表示されます。

� Change Data Capture および Streams の新規サポート

– Distributed（異機種間）Asynchronous Change Data Capture

– Downstream Capture Hot Mining

REDO Apply およびフィジカル・スタンバイ・データベース固有の新機能およびフィジカル・スタンバイ・データベース固有の新機能およびフィジカル・スタンバイ・データベース固有の新機能およびフィジカル・スタンバイ・データベース固有の新機能

次のリストに、Oracle Database 10g リリース 2（10.2）の REDO Apply およびフィジカル・スタンバイ・データベース固有の新機能を示します。

� 高速化された高速化された高速化された高速化された REDO Apply フェイルオーバーフェイルオーバーフェイルオーバーフェイルオーバー

スタンバイ・データベースが前回の起動時以後に読取り専用モードでオープンされていなければ、データベースを再起動せずに、フィジカル・スタンバイ・データベースをプライマリ・データベース・ロールに推移させることができます。

これにより、障害や停止からのリカバリが高速化され、システムの可用性が向上します。

関連項目関連項目関連項目関連項目 : Oracle Enterprise Manager のオンライン・ヘルプ・システム

関連項目関連項目関連項目関連項目 : 『Oracle Streams 概要および管理』および『Oracle Database データ・ウェアハウス・ガイド』（Change Data Capture 情報）

関連項目関連項目関連項目関連項目 : 7.2.2 項「フィジカル・スタンバイ・データベースが関与するフェイルオーバー」

xxvi

� フィジカル・スタンバイ・データベースからレポート用データベースへの容易な変換フィジカル・スタンバイ・データベースからレポート用データベースへの容易な変換フィジカル・スタンバイ・データベースからレポート用データベースへの容易な変換フィジカル・スタンバイ・データベースからレポート用データベースへの容易な変換

フィジカル・スタンバイ・データベースをプライマリ・データベースとしてアクティブ化してレポート生成のために読取り / 書込み用にオープンし、元のフィジカル・スタンバイ・データベースに容易に変換できるように過去の時点へフラッシュバックできます。この時点で、Data Guard により自動的にスタンバイ・データベースがプライマリ・データベースと同期化されます。これにより、フィジカル・スタンバイ・データベースをレポート・アクティビティや読取り / 書込みクローニング・アクティビティに使用できます。

� RECOVER MANAGED STANDBY DATABASE FINISH の新しいの新しいの新しいの新しい FORCE キーワードキーワードキーワードキーワード

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH文の新しいFORCEオプションを使用すると、ターゲット・スタンバイ・データベースでアクティブなRFS プロセスを停止できます。これにより、ログが適用された直後にフェイルオーバーが進行します。

� Recovery Manager によるリカバリ後の一時ファイルの自動再作成によるリカバリ後の一時ファイルの自動再作成によるリカバリ後の一時ファイルの自動再作成によるリカバリ後の一時ファイルの自動再作成

Recovery Manager によるリカバリ操作中に、ローカルで管理される一時表領域に属する一時データファイルが自動的に作成されるため、一時ファイルを作成してフィジカル・スタンバイ・データベースの一時表領域に関連付ける必要がなくなりました。

� 使用性と管理性を向上させるその他の変更点使用性と管理性を向上させるその他の変更点使用性と管理性を向上させるその他の変更点使用性と管理性を向上させるその他の変更点

不要な初期化パラメータおよび特定の SQL 文の句とキーワードを廃止することで、フィジカル・スタンバイ・データベースの使用性と管理性が改善されました。

SQL Apply およびロジカル・スタンバイ・データベース固有の新機能およびロジカル・スタンバイ・データベース固有の新機能およびロジカル・スタンバイ・データベース固有の新機能およびロジカル・スタンバイ・データベース固有の新機能

次のリストに、Oracle Database 10g リリース 2（10.2）の SQL Apply およびロジカル・スタンバイ・データベースの新機能を示します。

� 高速化された高速化された高速化された高速化された SQL Apply フェイルオーバーフェイルオーバーフェイルオーバーフェイルオーバー

フェイルオーバー操作の一部として SQL Apply を再起動する必要がなくなったため、ロジカル・スタンバイ・データベースへのフェイルオーバー完了までの所要時間が大幅に短縮されました。これにより、障害や停止からの Data Guard 構成のリカバリが高速化され、システムの可用性が向上します。

� 索引編成表のデータ型サポートの追加索引編成表のデータ型サポートの追加索引編成表のデータ型サポートの追加索引編成表のデータ型サポートの追加

SQL Apply では、LOB 列およびオーバーフロー・セグメントを含む索引編成表により生成された REDO レコードのマイニングがサポートされるようになりました。

関連項目関連項目関連項目関連項目 : 12.6 項「フィジカル・スタンバイ・データベースを使用した読取り / 書込みテストとレポート生成」

関連項目関連項目関連項目関連項目 : 7.2.2 項「フィジカル・スタンバイ・データベースが関与するフェイルオーバー」および『Oracle Database SQL リファレンス』のALTER DATABASE構文に関する項

関連項目関連項目関連項目関連項目 : 『Oracle Database SQL リファレンス』の Data Guard 関連の SQL文に関する項および『Oracle Database リファレンス』の LOG_ARCHIVE_DEST_n初期化パラメータに関する項

関連項目関連項目関連項目関連項目 : 7.3.2 項「ロジカル・スタンバイ・データベースが関与するフェイルオーバー」

関連項目関連項目関連項目関連項目 : 4.1.1 項「表のデータ型および記憶域属性のサポートの判別」

xxvii

� 適用済アーカイブ適用済アーカイブ適用済アーカイブ適用済アーカイブ REDO ログ・ファイルの自動削除ログ・ファイルの自動削除ログ・ファイルの自動削除ログ・ファイルの自動削除

アーカイブ・ログ・ファイルは、ロジカル・スタンバイ・データベースでの適用後に SQL Apply により自動的に削除されます。これにより、ロジカル・スタンバイ・データベースの記憶域使用量が減少し、Data Guard の管理性が向上します。

� 適化されたロジカル・スタンバイ・データベース作成適化されたロジカル・スタンバイ・データベース作成適化されたロジカル・スタンバイ・データベース作成適化されたロジカル・スタンバイ・データベース作成

Recovery Manager では使用できない特化されたロジカル・スタンバイ制御ファイルを作成せずに、ロジカル・スタンバイ・データベースを作成できるようになりました。フィジカル・スタンバイ・データベースから容易にロジカル・スタンバイ・データベースを作成できます。これにより、ロジカル・スタンバイ・データベースを作成するための特別な手動操作が減少し、Data Guard の管理性が向上します。

� ロジカル・スタンバイ・データベース管理のために追加された複数の拡張機能ロジカル・スタンバイ・データベース管理のために追加された複数の拡張機能ロジカル・スタンバイ・データベース管理のために追加された複数の拡張機能ロジカル・スタンバイ・データベース管理のために追加された複数の拡張機能

– 新規のビュー

* 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.3.2 項「ログ・ファイルの自動削除」

関連項目関連項目関連項目関連項目 : 4.2 項「ロジカル・スタンバイ・データベースの作成手順」

関連項目関連項目関連項目関連項目 : 第 9 章「ロジカル・スタンバイ・データベースの管理」

xxviii

第第第第 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 の使用例」

Oracle Data Guard の

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 のメリットの要約

概要 1-1

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 に統合されたグラフィカル・ユーザー・インタフェースなどがあります。

1.1.1 プライマリ・データベースプライマリ・データベースプライマリ・データベースプライマリ・データベースData Guard 構成には、1 個の本番データベースが含まれています。これはプライマリ・データベースとも呼ばれ、プライマリ・ロールで機能します。アプリケーションは主としてこのデータベースにアクセスします。

プライマリ・データベースは、シングル・インスタンスの Oracle データベースまたは Oracle Real Application Clusters データベースのいずれかです。

1.1.2 スタンバイ・データベーススタンバイ・データベーススタンバイ・データベーススタンバイ・データベーススタンバイ・データベースは、プライマリ・データベースのトランザクション一貫性のあるコピーです。プライマリ・データベースのバックアップ・コピーを使用すると、大 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 概要および管理

Data Guard サービス

1.1.3 構成例構成例構成例構成例図 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


1.2.1 REDO 転送サービス転送サービス転送サービス転送サービスREDO 転送サービス転送サービス転送サービス転送サービスは、本番データベースから 1 つ以上のアーカイブ先に対する REDO データの自動転送を制御します。

REDO 転送サービスでは、次のタスクを実行します。

� REDO データを構成内のプライマリ・システムからスタンバイ・システムに転送します。

� ネットワーク障害により発生したアーカイブ REDO ログ・ファイル内のギャップを解決するプロセスを管理します。

� データベース保護モード（1.4 項を参照）を施行します。

� スタンバイ・システム上の欠落または破損しているアーカイブ REDO ログ・ファイルを自動的に検出し、プライマリ・データベースまたは別のスタンバイ・データベースからかわりのアーカイブ REDO ログ・ファイルを自動的に取得します。

1.2.2 ログ適用サービスログ適用サービスログ適用サービスログ適用サービスプライマリ・データベースから転送された REDO データは、スタンバイ・システム上でスタンバイ REDO ログ・ファイルに書き込まれ（そのように構成されている場合）、アーカイブREDO ログ・ファイルにアーカイブされます。ログ適用サービスログ適用サービスログ適用サービスログ適用サービスは、REDO データをスタンバイ・データベースに自動的に適用し、プライマリ・データベースとの一貫性を維持します。データを読取り専用にすることも可能です。

フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの主な相違点は、ログ適用サービスによるアーカイブ REDO データの適用方法にあります。

� フィジカル・スタンバイ・データベースの場合、Data Guard では REDO Apply テクノロジを使用します。このテクノロジでは、図 1-2 に示すように、Oracle データベースの標準リカバリ技法を使用して REDO データがスタンバイ・データベースに適用されます。

図図図図 1-2 フィジカル・スタンバイ・データベースの自動更新フィジカル・スタンバイ・データベースの自動更新フィジカル・スタンバイ・データベースの自動更新フィジカル・スタンバイ・データベースの自動更新



� ロジカル・スタンバイ・データベースの場合、Data Guard では SQL Apply テクノロジを使用します。このテクノロジでは、図 1-3 に示すように、まず、受信した REDO データがSQL 文に変換されてから、生成された SQL 文がロジカル・スタンバイ・データベース上で実行されます。

図図図図 1-3 ロジカル・スタンバイ・データベースの自動更新ロジカル・スタンバイ・データベースの自動更新ロジカル・スタンバイ・データベースの自動更新ロジカル・スタンバイ・データベースの自動更新

1.2.3 ロールの推移ロールの推移ロールの推移ロールの推移Oracle データベースは、プライマリ・ロールまたはスタンバイ・ロールのいずれかで実行されます。Data Guard では、スイッチオーバー操作またはフェイルオーバー操作のいずれかを使用してデータベースのロールを変更できます。

スイッチオーバースイッチオーバースイッチオーバースイッチオーバーとは、プライマリ・データベースとそのスタンバイ・データベースの 1 つとの間でロールを可逆的に推移させる操作です。スイッチオーバーにより、データ消失のない状態が保証されます。この操作は通常、プライマリ・システムの計画的なメンテナンスに対して実行します。スイッチオーバー時には、プライマリ・データベースがスタンバイ・ロールに、あるいはスタンバイ・データベースがプライマリ・ロールに推移します。推移は、いずれのデータベースも再作成せずに実行されます。

フェイルオーバーフェイルオーバーフェイルオーバーフェイルオーバーは、プライマリ・データベースが使用不可能な場合に発生します。フェイルオーバーは、プライマリ・データベースで災害などの障害が起きたときのみに実行され、スタンバイ・データベースをプライマリ・ロールに推移させます。データベース管理者は、データが消失しないように、Data Guard を構成できます。

このマニュアルで説明しているロールの推移は、SQL 文を使用して手動で行います。また、1.3項で説明しているように、Oracle Data Guard Broker を使用してロールの推移を単純化させ、Oracle Enterprise Manager または DGMGRL コマンドライン・インタフェースを使用してフェイルオーバーを自動化することもできます。


Data Guard Broker

1.3 Data Guard BrokerData 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 構成への新規または既存のスタンバイ・データベースの追加

� ログ適用レートの監視、診断情報の獲得、および集中化した監視ツール、テスト・ツール、パフォーマンス・ツールなどを使用した問題の早期検出

1.3.1 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 のオンライン・ヘルプを参照してください。

関連項目関連項目関連項目関連項目 : 詳細は、『Oracle Data Guard Broker』を参照してください。


Data Guard Broker

図 1-4 は、Enterprise Manager の Data Guard 管理概要ページを示しています。

図図図図 1-4 Oracle Enterprise Manager のののの Data Guard 概要ページ概要ページ概要ページ概要ページ

1.3.2 Data Guard コマンドライン・インタフェースの使用コマンドライン・インタフェースの使用コマンドライン・インタフェースの使用コマンドライン・インタフェースの使用Data Guard のコマンドライン・インタフェース（DGMGRL）を使用すると、DGMGRL プロンプトまたはスクリプト内から Data Guard 構成を制御および監視できます。 DGMGRL を使用すると、構成でデータベースを管理および監視するために必要なアクティビティのほとんどを実行できます。 DGMGRL のリファレンスの詳細と例は、『Oracle Data Guard Broker』を参照してください。


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 項を参照してください。


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 データの適用を遅延させる方法は6.2.2 項を参照してください。


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 つ以上のスタンバイ・データベースとの間の接続が失われた場合、プライマリ・データベース上に生成される 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 による操作の必要なしに同期化されたスタンバイ・サイトにフェイルオーバーされます。また、アプリケーションにロールの推移が自動的に通知されます。




Data Guard スタート・ガ

2
Data Guard スタート・ガイドスタート・ガイドスタート・ガイドスタート・ガイド
Data Guard 構成には、1 つのプライマリ・データベースと、それに対応付けられた大 9 個のスタンバイ・データベースが含まれます。この章では、Data Guard の使用を開始するための次の考慮事項について説明します。

� スタンバイ・データベースのタイプ

� Data Guard 構成の管理のためのユーザー・インタフェース

� Data Guard の動作要件

� スタンバイ・データベースのディレクトリ構造に関する考慮事項

� オンライン REDO ログ、アーカイブ REDO ログおよびスタンバイ REDO ログ

イド 2-1

スタンバイ・データベースのタイプ

2.1 スタンバイ・データベースのタイプスタンバイ・データベースのタイプスタンバイ・データベースのタイプスタンバイ・データベースのタイプスタンバイ・データベーススタンバイ・データベーススタンバイ・データベーススタンバイ・データベースは、Oracle 本番データベースのトランザクション一貫性のあるコピーで、初はプライマリ・データベースのバックアップ・コピーから作成されます。スタンバイ・データベースが作成および構成されると、Data Guard は、プライマリ・データベースのREDO データをスタンバイ・システムに転送し、スタンバイ・データベースに適用することによって、スタンバイ・データベースを自動的にメンテナンスします。

スタンバイ・データベースには、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの 2 つのタイプがあります。いずれのタイプのスタンバイ・データベースも、必要に応じてプライマリ・データベースのロールを引き継ぎ、本番処理を継続できます。Data Guard 構成には、フィジカル・スタンバイ・データベース、ロジカル・スタンバイ・データベース、または両方のタイプの組合せを含めることができます。

2.1.1 フィジカル・スタンバイ・データベースフィジカル・スタンバイ・データベースフィジカル・スタンバイ・データベースフィジカル・スタンバイ・データベースフィジカル・スタンバイ・データベースは、プライマリ・データベースと物理的に同一で、ディスク上のデータベース構造は、ブロック単位でプライマリ・データベースと同一です。索引などのデータベース・スキーマも同一です。

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 データを受信せず、障害時保護を提供できません。



フィジカル・スタンバイ・データベースを開発、レポートまたはテストのために読取り /書込みモードで一時的にオープンしてから、過去の特定時点までフラッシュバックして元に戻すことができます。データベースがフラッシュバックされると、Data Guard では自動的にスタンバイ・データベースをプライマリ・データベースと同期化します。プライマリ・データベースのバックアップ・コピーからフィジカル・スタンバイ・データベースを再作成する必要はありません。

フィジカル・スタンバイ・データベースのメリットフィジカル・スタンバイ・データベースのメリットフィジカル・スタンバイ・データベースのメリットフィジカル・スタンバイ・データベースのメリット

フィジカル・スタンバイ・データベースには次のメリットがあります。

� 障害時リカバリと高可用性

フィジカル・スタンバイ・データベースによって、堅牢で効率的な障害時リカバリと可用性の高いソリューションを実現できます。管理が容易なスイッチオーバー機能とフェイルオーバー機能を使用すると、プライマリ・データベースとフィジカル・スタンバイ・データベース間でロールを可逆的に推移できるため、計画的および計画外の停止によるプライマリ・データベースの停止時間が小限になります。

� データ保護

フィジカル・スタンバイ・データベースを使用することで、予期しない障害が発生した場合でもデータが消失しないことが保証されます。フィジカル・スタンバイ・データベースでは、プライマリ・データベースでサポートされるすべてのデータ型、およびすべてのDDL 操作と DML 操作がサポートされます。また、データの破損やユーザーのミスに対する保護対策も用意されています。プライマリ・データベースの記憶域レベルの物理破損は、スタンバイ・データベースに伝播されません。同様に、プライマリ・データベースの完全な破損の原因となった論理的な破損やユーザーのミスも解決できます。後に、REDOデータが、スタンバイ・データベースへの適用時に検証されます。

� プライマリ・データベースのワークロードの低減

Oracle Recovery Manager は、フィジカル・スタンバイ・データベースを使用してプライマリ・データベースからバックアップをオフロードし、貴重な CPU と I/O のサイクルを節約できます。フィジカル・スタンバイ・データベースを読取り専用モードでオープンすると、レポート生成および問合せを実行することもできます。

� パフォーマンス

フィジカル・スタンバイ・データベースで使用される REDO Apply テクノロジは、低レベルのリカバリ・メカニズムを使用して変更を適用します。このメカニズムは、SQL レベルのコード・レイヤーをすべてバイパスするため、大量の REDO データの適用に関してはも効率的です。

関連項目関連項目関連項目関連項目 : 使用例は、12.6 項を参照してください。

Data Guard スタート・ガイド 2-3


2.1.2 ロジカル・スタンバイ・データベースロジカル・スタンバイ・データベースロジカル・スタンバイ・データベースロジカル・スタンバイ・データベースロジカル・スタンバイ・データベースは、初はプライマリ・データベースと同じ内容のコピーで作成されますが、後で異なる構造に変更できます。ロジカル・スタンバイ・データベースは、SQL 文を実行して更新されます。これにより、ユーザーは問合せとレポート生成の目的で、スタンバイ・データベースにいつでもアクセスできます。このように、ロジカル・スタンバイ・データベースは、データ保護操作とレポート生成操作に同時に使用できます。

Data Guard は、ログ・ファイルのデータを SQL 文に変換し、ロジカル・スタンバイ・データベースでその SQL 文を実行することによって、アーカイブ REDO ログ・ファイルまたはスタンバイ REDO ログ・ファイルの情報をロジカル・スタンバイ・データベースに自動的に適用します。ロジカル・スタンバイ・データベースは SQL 文を使用して更新されるため、オープン状態のままであることが必要です。ロジカル・スタンバイ・データベースは読取り / 書込みモードでオープンされますが、再生成された SQL に対するターゲット表は、読取り専用操作用にのみ使用可能です。更新中、これらの表は、レポート生成、要約、問合せなどの他のタスクで同時に使用できます。さらに、これらのタスクは、メンテナンスされている表に追加の索引やマテリアライズド・ビューを作成することによって適化できます。

ロジカル・スタンバイ・データベースには、データ型、表のタイプおよび DDL 操作や DML 操作のタイプに関していくつかの制限があります。サポートされないデータ型および表の記憶域属性は、4.1.1 項で説明しています。

ロジカル・スタンバイ・データベースのメリットロジカル・スタンバイ・データベースのメリットロジカル・スタンバイ・データベースのメリットロジカル・スタンバイ・データベースのメリット

ロジカル・スタンバイ・データベースには、フィジカル・スタンバイ・データベースと同様の障害時リカバリ、高可用性およびデータ保護のメリットがあります。その他に、次のメリットもあります。

� スタンバイ・ハードウェア資源の効率的な使用

ロジカル・スタンバイ・データベースは、障害時リカバリ要件に加えて、その他のビジネス用途にも使用できます。Data Guard 構成内で保護されているデータベース・スキーマ以外に別のデータベース・スキーマをホスティングできるため、ユーザーは、これらのスキーマ上で通常の DDL 操作または DML 操作をいつでも実行できます。Data Guard で保護されているロジカル・スタンバイ表は、プライマリ・データベースとは異なる物理的なレイアウトで格納できるため、追加の索引やマテリアライズド・ビューを作成して、問合せのパフォーマンスを改善したり、特定のビジネス要件にあわせることができます。

� プライマリ・データベースのワークロードの低減

ロジカル・スタンバイ・データベースは、その表をプライマリ・データベースから更新するとき、オープン状態のままにしておくことができるため、これらの表は読取りアクセスに同時に使用できます。このことによって、ロジカル・スタンバイ・データベースは、問合せ、要約およびレポート生成の各アクティビティを実行する際の優れたデータベースとなり、これらのタスクからプライマリ・データベースがオフロードされ、貴重な CPU とI/O のサイクルが節約されます。


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 ソフトウェア要件

2.3.1 ハードウェアおよびオペレーティング・システムの要件ハードウェアおよびオペレーティング・システムの要件ハードウェアおよびオペレーティング・システムの要件ハードウェアおよびオペレーティング・システムの要件次のリストに、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.3.2 Oracle ソフトウェア要件ソフトウェア要件ソフトウェア要件ソフトウェア要件次のリストに、Data Guard 使用時の Oracle ソフトウェア要件を示します。

� Oracle Data Guard は、Oracle Database Enterprise Edition の機能としてのみ提供されています。Oracle Database Standard Edition には付属していません。したがって、Data Guard構成のプライマリ・データベースおよびすべてのスタンバイ・データベースに、同じリリースの Oracle Database Enterprise Edition がインストールされている必要があります。

� Data Guard SQL Apply を使用して、Oracle Database ソフトウェアをパッチ・セット・リリース n（10.1.0.3 以上）から次のデータベース 10.1.0.(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、またはその両方を使用する場合、構成内のすべてのデータベー

注意注意注意注意 : Oracle Database Standard Edition を実行しているデータベースでスタンバイ・データベース環境を再現することが可能です。これを行うには、オペレーティング・システムのコピー・ユーティリティ、または定期的にアーカイブ REDO ログ・ファイルをデータベースからデータベースに送信するカスタム・スクリプトを使用して、手動でアーカイブ REDOログ・ファイルを転送します。したがって、この構成では、Data Guardによって提供される利便性、管理性、パフォーマンスおよび障害時リカバリ機能を得られません。


スタンバイ・データベースのディレクトリ構造に関する考慮事項

スでもそれぞれ ASM、OMF またはその両方を使用する必要があります。詳細は、12.12 項の使用例を参照してください。

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 章を参照してください。


スタンバイ・データベースのディレクトリ構造に関する考慮事項

図図図図 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 項を参

照。）

� スタンバイ・データベースは、プライマリ・データベースとスタンバイ・データベースが存在しているシステムを破壊するような障害に対する保護には役立ちませんが、計画的なメンテナンスに対するスイッチオーバー機能は提供します。


オンライン REDO ログ、アーカイブ REDO ログおよびスタンバイ REDO ログ

2.5 オンラインオンラインオンラインオンライン REDO ログ、アーカイブログ、アーカイブログ、アーカイブログ、アーカイブ REDO ログおよびスタンログおよびスタンログおよびスタンログおよびスタンバイバイバイバイ REDO ログログログログ

Data Guard リカバリ操作のも重要な構造は、オンライン REDO ログ、アーカイブ REDO ログおよびスタンバイ REDO ログです。プライマリ・データベースから転送された REDO データは、スタンバイ・システムのリモート・ファイル・サーバー（RFS）プロセスによって受信されます。RFS プロセスは、この REDO データをアーカイブ・ログ・ファイルまたはスタンバイ REDO ログ・ファイルのいずれかに書き込みます。REDO データは、REDO がアーカイブREDO ログ・ファイルまたはスタンバイ REDO ログ・ファイルに書き込まれた後、もしくはリアルタイム適用が使用可能になっている場合は、いっぱいになったスタンバイ REDO ログ・ファイルから直接、適用できます。

このマニュアルでは、オンライン REDO ログおよびアーカイブ REDO ログの概要を理解していることを前提としています。2.5.1 項では、Data Guard 構成固有の情報を説明することにより、基本概念を強化しています。2.5.2 項では、スタンバイ REDO ログ・ファイルの使用方法の詳細を説明しています。

REDO ログおよびアーカイブ・ログの詳細は、『Oracle Database 管理者ガイド』を参照してください。リアルタイム適用の詳細は、6.2.1 項を参照してください。

2.5.1 オンラインオンラインオンラインオンライン REDO ログおよびアーカイブログおよびアーカイブログおよびアーカイブログおよびアーカイブ REDO ログログログログプライマリ・データベースとスタンバイ・データベースのトランザクション一貫性を維持するには、REDO の転送が不可欠です。Data Guard 環境では、オンライン REDO ログおよびアーカイブ REDO ログの両方が必要です。

� オンライン REDO ログ

インスタンス障害の際にデータベースを保護するために、Oracle プライマリ・データベースおよびロジカル・スタンバイ・データベースのすべてのインスタンスには、オンラインREDO ログが存在します。フィジカル・スタンバイ・データベースは読取り / 書込み I/Oのためにオープンされないため、オンライン REDO ログは使用されません。フィジカル・スタンバイ・データベースが変更されることはなく、新規 REDO データは生成されません。

離れたシステムプライマリ・システムと同じ

� スタンバイ・データベース制御ファイル内のプライマリ・データベースのファイル名、アーカイブ REDO ログ・

ファイルおよびスタンバイ REDO ログ・ファイル名を変

更する必要はありません。ただし、新しいネーミング計画が必要な場合（複数のディスクにファイルを分散する場合など）は、変更しても構いません。

� スタンバイ・データベースを別の物理メディアに置くことにより、プライマリ・システムを破壊するような障害からプライマリ・データベースのデータを保護できます。

離れたシステムプライマリ・システムと異なる

� ファイル名を手動で変更するか、またはスタンバイ・データベースで DB_FILE_NAME_CONVERT初期化パラメータ

および LOG_FILE_NAME_CONVERT初期化パラメータを設

定し、データファイル名を自動的に変更できます（3.1.4項を参照）。

� スタンバイ・データベースを別の物理メディアに置くことにより、プライマリ・システムを破壊するような障害からプライマリ・データベースのデータを保護できます。

表表表表 2-1 スタンバイ・データベースの位置とディレクトリ・オプション（続き）スタンバイ・データベースの位置とディレクトリ・オプション（続き）スタンバイ・データベースの位置とディレクトリ・オプション（続き）スタンバイ・データベースの位置とディレクトリ・オプション（続き）

スタンバイ・スタンバイ・スタンバイ・スタンバイ・システムシステムシステムシステム

ディレクトリディレクトリディレクトリディレクトリ構造構造構造構造結果的な注意事項結果的な注意事項結果的な注意事項結果的な注意事項


オンライン REDO ログ、アーカイブ REDO ログおよびスタンバイ REDO ログ

� アーカイブ REDO ログ

スタンバイ・データベースとプライマリ・データベースのトランザクション一貫性を維持するためにアーカイブが使用されるため、アーカイブ REDO ログは必須です。プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースでは、いずれもアーカイブ REDO ログが使用されます。Oracle データベースは、デフォルトで、ARCHIVELOG モードで稼働するよう設定されています。これにより、いっぱいになった各オンライン REDO ログ・ファイルが、アーカイバ（ARCn）プロセスによって自動的に 1 つ以上のアーカイブ REDO ログ・ファイルにコピーされます。

フィジカル・スタンバイ・データベースと異なり、ロジカル・スタンバイ・データベースは、REDO データを生成し、複数のログ・ファイルを持つオープン状態のデータベースです。ログ・ファイルは、オンライン REDO ログ・ファイル、アーカイブ REDO ログ・ファイルおよびスタンバイ REDO ログ・ファイル（構成されている場合）などです。

プライマリ・サイトでのアーカイブ REDO ログ・ファイルの生成には、オンライン REDO ログ・ファイルのサイズとログ・スイッチの発生頻度の両方が影響します。『Oracle Database 高可用性概要』では、ログ・グループのサイズ決定の際の推奨事項を説明しています。

Oracle データベースは各ログ・スイッチでチェックポイントを試行します。したがって、オンライン REDO ログ・ファイルのサイズが小さすぎる場合は、ログ・スイッチの発生頻度が高いために、チェックポイントの発生頻度も高くなり、スタンバイ・データベースのシステム・パフォーマンスに悪影響を及ぼします。

2.5.2 スタンバイスタンバイスタンバイスタンバイ REDO ログログログログスタンバイ 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 章を参照してください。

3.1.3 項では、スタンバイ REDO ログ・ファイルの構成手順を説明します。

関連項目関連項目関連項目関連項目 : REDO ログ、アーカイブ・ログおよびログ・グループの構成方法の詳細は、『Oracle Database 管理者ガイド』を参照してください。


フィジカル・スタンバイ・データベースの

3
フィジカル・スタンバイ・データベースの作成フィジカル・スタンバイ・データベースの作成フィジカル・スタンバイ・データベースの作成フィジカル・スタンバイ・データベースの作成
この章では、フィジカル・スタンバイ・データベースを作成する手順について説明します。この章は、次の主な項目で構成されています。

� スタンバイ・データベースを作成するためのプライマリ・データベースの準備

� フィジカル・スタンバイ・データベースの作成手順

� 作成後の手順

この章で説明する手順では、スタンバイ・データベースが大パフォーマンス・モードで構成されます。このモードは、デフォルトのデータ保護モードです。別のデータ保護モードの構成については、第 5 章を参照してください。この章の説明は、テキストの初期化パラメータ・ファイル（PFILE）ではなく、サーバー・パラメータ・ファイル（SPFILE）に初期化パラメータを指定することを前提としています。

関連項目

� サーバー・パラメータ・ファイルの作成方法および使用方法は、『Oracle Database 管理者ガイド』を参照してください。

� グラフィカル・ユーザー・インタフェースを使用してフィジカル・スタンバイ・データベースを自動的に作成する方法は、『Oracle Data Guard Broker』および Enterprise Manager のオンライン・ヘルプを参照してください。

作成 3-1

スタンバイ・データベースを作成するためのプライマリ・データベースの準備

3.1 スタンバイ・データベースを作成するためのプライマリ・スタンバイ・データベースを作成するためのプライマリ・スタンバイ・データベースを作成するためのプライマリ・スタンバイ・データベースを作成するためのプライマリ・データベースの準備データベースの準備データベースの準備データベースの準備

スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されていることを確認する必要があります。

表 3-1 は、フィジカル・スタンバイ・データベースを作成するための準備としてプライマリ・データベースで実行するタスクのチェックリストです。各タスクを詳細に説明している参照先の項も記載されています。

3.1.1 強制ロギングの有効化強制ロギングの有効化強制ロギングの有効化強制ロギングの有効化データベースの作成後、次の SQL 文を使用して、プライマリ・データベースを FORCE LOGGINGモードにします。

SQL> ALTER DATABASE FORCE LOGGING;

この文は、完了までに非常に時間がかかる場合があります。これは、ログに記録されないダイレクト書込み I/O がすべて完了するまで待機するためです。

3.1.2 パスワード・ファイルの作成パスワード・ファイルの作成パスワード・ファイルの作成パスワード・ファイルの作成パスワード・ファイルが存在しない場合は、作成します。Data Guard 構成内のすべてのデータベースにパスワード・ファイルが必要です。また、SYSユーザーのパスワードは、REDO データを正常に転送するために、すべてのシステムで同じである必要があります。『Oracle Database 管理者ガイド』を参照してください。

表表表表 3-1 フィジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備フィジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備フィジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備フィジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備

参照先参照先参照先参照先タスクタスクタスクタスク

3.1.1 項強制ロギングの有効化

3.1.2 項パスワード・ファイルの作成

3.1.3 項スタンバイ REDO ログの構成

3.1.4 項プライマリ・データベースの初期化パラメータの設定

3.1.5 項アーカイブの有効化

注意注意注意注意 : これらの準備のためのタスクは、1 回のみ実行してください。これらの手順を完了すると、データベースは、1 つ以上のスタンバイ・データベースに対するプライマリ・データベースとして機能する準備が整います。



3.1.3 スタンバイスタンバイスタンバイスタンバイ 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 ログ・ファイル・グループが必要になります。

手順手順手順手順 3 関連するデータベース・パラメータおよび設定を確認します。関連するデータベース・パラメータおよび設定を確認します。関連するデータベース・パラメータおよび設定を確認します。関連するデータベース・パラメータおよび設定を確認します。

SQL CREATE DATABASE文の MAXLOGFILESおよび MAXLOGMEMBERS句に使用されている値により、追加できるスタンバイ REDO ログ・ファイル・グループ数とメンバー数が制限されないことを確認します。MAXLOGFILESおよび MAXLOGMEMBERS句で指定されている制限を無視するには、プライマリ・データベースまたは制御ファイルを再作成する必要があります。

MAXLOGFILESおよび MAXLOGMEMBERS句のデフォルト値および有効な値の詳細は、『Oracle Database SQL リファレンス』およびオペレーティング・システム固有の Oracle ドキュメントを参照してください。

注意注意注意注意 : ロジカル・スタンバイ・データベースでは、ワークロードにより、これ以上のスタンバイ REDO ログ・ファイル（または追加の ARCn プロセス）が必要になる可能性があります。ロジカル・スタンバイ・データベースはオンライン REDO ログ・ファイルにも書込みを行い、これはスタンバイ REDO ログ・ファイルより優先されるためです。このため、スタンバイ REDO ログ・ファイルはオンライン REDO ログ・ファイルほどすばやくアーカイブされない可能性があります。5.7.3.1 項も参照してください。

フィジカル・スタンバイ・データベースの作成 3-3


手順手順手順手順 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句の値の間であることが必要です。ログ・ファイル・グループ番号はスキップしないでください（つまり、グループに 10、20、30 などの番号を付けないでください）。スキップすると、スタンバイ・データベースの制御ファイルの領域が余分に使用されます。

手順手順手順手順 5 スタンバイスタンバイスタンバイスタンバイ REDO ログ・ファイル・グループが作成されたことを確認します。ログ・ファイル・グループが作成されたことを確認します。ログ・ファイル・グループが作成されたことを確認します。ログ・ファイル・グループが作成されたことを確認します。

スタンバイ REDO ログ・ファイル・グループが作成されて正しく実行していることを確認するには、作成後、プライマリ・データベースでログ・スイッチを起動してから、スタンバイ・データベースで V$STANDBY_LOGビューまたは V$LOGFILEビューを問い合せます。次に例を示します。

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;

GROUP# THREAD# SEQUENCE# ARC STATUS ---------- ---------- ---------- --- ---------- 3 1 16 NO ACTIVE 4 0 0 YES UNASSIGNED 5 0 0 YES UNASSIGNED

注意注意注意注意 : スタンバイ REDO ログが使用されるのは、データベースがスタンバイ・ロールで実行されているときのみですが、プライマリ・データベースにスタンバイ REDO ログ・ファイルを作成して、プライマリ・データベースが DBA による介入なしにスタンバイ・ロールに迅速に切り替えられるようにすることをお薦めします。プライマリ・データベースおよびスタンバイ・データベースの両方で自動的にスタンバイ REDO ログを構成するために、Oracle Enterprise Manager を使用することを考慮してください。



3.1.4 プライマリ・データベースの初期化パラメータの設定プライマリ・データベースの初期化パラメータの設定プライマリ・データベースの初期化パラメータの設定プライマリ・データベースの初期化パラメータの設定プライマリ・データベースでは、データベースがプライマリ・ロールで動作している間のREDO 転送サービスを制御する初期化パラメータを定義します。また、プライマリ・データベースがスタンバイ・ロールに推移したときに REDO データの受信とログ適用サービスを制御するパラメータを追加する必要があります。

例 3-3 に、プライマリ・データベースでメンテナンスする、プライマリ・ロールの初期化パラメータを示します。この例は、シカゴにプライマリ・データベースがあり、ボストンにフィジカル・スタンバイ・データベースが 1 つある Data Guard 構成を示しています。例 3-3 に示すパラメータは、シカゴのデータベースがプライマリ・データベース・ロールまたはスタンバイ・データベース・ロールで実行されている場合に有効です。この構成例では、次の表に示す名前を使用しています。

例例例例 3-3 プライマリ・データベースプライマリ・データベースプライマリ・データベースプライマリ・データベース : プライマリ・ロールの初期化パラメータプライマリ・ロールの初期化パラメータプライマリ・ロールの初期化パラメータプライマリ・ロールの初期化パラメータ

DB_NAME=chicagoDB_UNIQUE_NAME=chicagoLOG_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=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLEREMOTE_LOGIN_PASSWORDFILE=EXCLUSIVELOG_ARCHIVE_FORMAT=%t_%s_%r.arcLOG_ARCHIVE_MAX_PROCESSES=30

これらのパラメータは、REDO 転送サービスが REDO データをスタンバイ・システムに転送する方法と、ローカル・ファイル・システムでの REDO データのアーカイブ処理を制御します。例では、LGWRプロセスと、LOG_ARCHIVE_DEST_2初期化パラメータ上で REDO データを転送する非同期（ASYNC）ネットワーク転送を指定します。これらは推奨設定であり、スタンバイ REDO ログ・ファイルが必要です（3-3 ページの 3.1.3 項「スタンバイ REDO ログの構成」を参照）。

例 3-4 に、プライマリ・データベースで定義するスタンバイ・ロールの追加の初期化パラメータを示します。これらのパラメータは、プライマリ・データベースがスタンバイ・ロールに推移すると有効になります。

例例例例 3-4 プライマリ・データベースプライマリ・データベースプライマリ・データベースプライマリ・データベース : スタンバイ・ロールの初期化パラメータスタンバイ・ロールの初期化パラメータスタンバイ・ロールの初期化パラメータスタンバイ・ロールの初期化パラメータ

FAL_SERVER=bostonFAL_CLIENT=chicagoDB_FILE_NAME_CONVERT='boston','chicago'LOG_FILE_NAME_CONVERT= '/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/' STANDBY_FILE_MANAGEMENT=AUTO

例 3-4 に示す初期化パラメータを指定すると、プライマリ・データベースはギャップを解決して新しいプライマリ・データベースからの新規データファイルとログ・ファイルのパス名を変換するように設定され、このデータベースがスタンバイ・ロールで動作している間は着信

データベースデータベースデータベースデータベース DB_UNIQUE_NAME Oracle Net サービス名サービス名サービス名サービス名

プライマリ chicago chicago

フィジカル・スタンバイ boston boston



REDO データがアーカイブされます。説明に従ってプライマリおよびスタンバイ・ロールについて初期化パラメータを設定した場合、ロールの推移後に変更が必要なパラメータはありません。

次の表に、例 3-3 および例 3-4 に示した各パラメータ設定に関する簡単な説明を示します。

パラメータパラメータパラメータパラメータ推奨する設定推奨する設定推奨する設定推奨する設定

DB_NAME 8 文字の名前を指定します。すべてのスタンバイ・データベースに同じ名前を使用

してください。

DB_UNIQUE_NAME 各データベースの一意の名前を指定します。この名前はデータベースと固定され、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。

LOG_ARCHIVE_CONFIG このパラメータの DG_CONFIG属性を指定して Data Guard 構成のプライマリ・デー

タベースとスタンバイ・データベースの DB_UNIQUE_NAMEをリストすると、Real Application Clusters プライマリ・データベースが大保護モードまたは大可用性

モードで稼働している Data Guard 構成に、スタンバイ・データベースを動的に追

加できます。デフォルトでは、LOG_ARCHIVE_CONFIGパラメータを指定すると、

データベースは REDO を送受信できます。ロールの推移後は、SEND、NOSEND、RECEIVEまたは NORECEIVEキーワードを使用して、これらの設定を再指定する操

作が必要になることがあります。

CONTROL_FILES プライマリ・データベースの制御ファイルのパス名を指定します。例 3-3 は、2 つの

制御ファイルのパス名を指定する方法を示しています。不良制御ファイルの位置に正常な制御ファイルをコピーした後でインスタンスを簡単に再起動できるように、制御ファイルの第 2 コピーを使用可能にしておくことをお薦めします。

LOG_ARCHIVE_DEST_n 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初期化パラメータが自動的に使用されます。詳細は、5.2.3 項を

参照してください。また、LOG_ARCHIVE_DEST_nの詳細は、第 14 章を参照してく

ださい。

LOG_ARCHIVE_DEST_STATE_n REDO 転送サービスが REDO データを指定した宛先に転送するのを許可するには、

ENABLEを指定します。

REMOTE_LOGIN_PASSWORDFILE プライマリ・データベースとスタンバイ・データベースの両方で、SYSに同じパス

ワードを設定します。推奨する設定は、EXCLUSIVEまたは SHAREDです。

LOG_ARCHIVE_FORMAT スレッド（%t）、順序番号（%s）およびリセットログ ID（%r）を使用して、アーカ

イブ REDO ログ・ファイルのフォーマットを指定します。もう 1 つの例について

は、5.7.1 項を参照してください。

LOG_ARCHIVE_MAX_PROCESSES =integer

Oracle ソフトウェアが初に起動するアーカイバ（ARCn）・プロセスの大数

（1 ～ 30）を指定します。デフォルト値は 4 です。ARCn 処理の詳細は、5.3.1.2 項を

参照してください。

FAL_SERVER FAL サーバー（通常はプライマリ・ロールで実行中のデータベース）の Oracle Netサービス名を指定します。シカゴのデータベースがスタンバイ・ロールで実行されている場合、ボストンのデータベースが欠落しているログ・ファイルを自動的に送信できなければ、ボストンのデータベースが FAL サーバーとして使用され、そこか

ら欠落しているアーカイブ REDO ログ・ファイルがフェッチ（要求）されます。 5.8項を参照してください。



3.1.5 アーカイブの有効化アーカイブの有効化アーカイブの有効化アーカイブの有効化アーカイブが有効になっていない場合は、次の文を発行して、プライマリ・データベースをARCHIVELOG モードにし、自動アーカイブを有効にします。

SQL> SHUTDOWN IMMEDIATE;SQL> STARTUP MOUNT;SQL> ALTER DATABASE ARCHIVELOG;SQL> ALTER DATABASE OPEN;

アーカイブについては、『Oracle Database 管理者ガイド』を参照してください。

FAL_CLIENT シカゴのデータベースの Oracle Net サービス名を指定します。FAL サーバー（ボス

トン）は、欠落しているアーカイブ REDO ログ・ファイルをシカゴのスタンバイ・

データベースにコピーします。 5.8 項を参照してください。

DB_FILE_NAME_CONVERT プライマリ・データベースのデータファイルのパス名とファイル名の位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・

データベースのデータファイルのパス名がスタンバイ・データファイルのパス名に変換されます。スタンバイ・データベースがプライマリ・データベースと同じシス

テムにある場合、またはデータファイルが格納されているスタンバイ・サイトのディレクトリ構造がプライマリ・サイトと異なる場合は、このパラメータが必要です。このパラメータは、フィジカル・スタンバイ・データベースのパス名の変換にのみ使用されることに注意してください。このパラメータにより、複数のペアのパ

スを指定できます。

LOG_FILE_NAME_CONVERT プライマリ・データベースのオンライン REDO ログ・ファイルの位置を指定し、そ

の後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に変換されます。スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはログ・ファイルが格納されているスタンバイ・システムのディレクトリ構造がプライマリ・システムと異なる場合は、このパラメータが必要です。このパラメータにより、複数のペアのパスを指定できます。

STANDBY_FILE_MANAGEMENT データファイルがプライマリ・データベースに追加または削除された場合に、それに対応してスタンバイ・データベースも自動的に変更されるように、AUTOに設定

します。

注意注意注意注意 : 変更の必要性がある他のパラメータについては、初期化パラメータ・ファイルを調べてください。たとえば、ダンプ出力先パラメータ

（BACKGROUND_DUMP_DEST、CORE_DUMP_DEST、USER_DUMP_DEST）の変更が必要な場合があります。これは、スタンバイ・データベースのディレクトリ位置がプライマリ・データベースで指定したディレクトリ位置と異なる場合に必要です。さらに、スタンバイ・システムにまだ存在していないディレクトリがある場合は、そのディレクトリを作成する必要があります。



フィジカル・スタンバイ・データベースの作成手順

3.2 フィジカル・スタンバイ・データベースの作成手順フィジカル・スタンバイ・データベースの作成手順フィジカル・スタンバイ・データベースの作成手順フィジカル・スタンバイ・データベースの作成手順この項では、フィジカル・スタンバイ・データベースの作成で実行するタスクについて説明します。

表 3-2 は、フィジカル・スタンバイ・データベースの作成で実行するタスク、および各タスクを実行するデータベースのチェックリストです。各タスクを詳細に説明している参照先の項も記載されています。

3.2.1 プライマリ・データベース・データファイルのバックアップ・コピーのプライマリ・データベース・データファイルのバックアップ・コピーのプライマリ・データベース・データファイルのバックアップ・コピーのプライマリ・データベース・データファイルのバックアップ・コピーの作成作成作成作成

データベースを完全にリカバリするのに必要なアーカイブ REDO ログ・ファイルがあるかぎり、プライマリ・データベースのバックアップ・コピーを使用して、フィジカル・スタンバイ・データベースを作成できます。Recovery Manager（RMAN）ユーティリティを使用することをお薦めします。

バックアップの推奨事項は『Oracle 高可用性アーキテクチャおよびベスト・プラクティス』を、RMAN バックアップ操作の実行方法については『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

3.2.2 スタンバイ・データベース用の制御ファイルの作成スタンバイ・データベース用の制御ファイルの作成スタンバイ・データベース用の制御ファイルの作成スタンバイ・データベース用の制御ファイルの作成バックアップ処理のために、プライマリ・データベースを停止する必要がある場合は、次のSQL*Plus 文を発行して、プライマリ・データベースを起動します。

SQL> STARTUP MOUNT;

スタンバイ・データベース用の制御ファイルを作成してから、ユーザー・アクセス用にプライマリ・データベースをオープンします。次に例を示します。

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/boston.ctl';SQL> ALTER DATABASE OPEN;

表表表表 3-2 フィジカル・スタンバイ・データベースの作成フィジカル・スタンバイ・データベースの作成フィジカル・スタンバイ・データベースの作成フィジカル・スタンバイ・データベースの作成

参照先参照先参照先参照先タスクタスクタスクタスクデータベースデータベースデータベースデータベース

3.2.1 項プライマリ・データベース・データファイルのバックアップ・コピーの作成プライマリ

3.2.2 項スタンバイ・データベース用の制御ファイルの作成プライマリ

3.2.3 項スタンバイ・データベース用の初期化パラメータ・ファイルの準備プライマリ

3.2.4 項プライマリ・システムからスタンバイ・システムへのファイルのコピープライマリ

3.2.5 項スタンバイ・データベースをサポートする環境の設定スタンバイ

3.2.6 項フィジカル・スタンバイ・データベースの起動スタンバイ

3.2.7 項フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認スタンバイ

注意注意注意注意 : プライマリ・データベースとスタンバイ・データベースの両方に単一の制御ファイルを使用することはできません。



3.2.3 スタンバイ・データベース用の初期化パラメータ・ファイルの準備スタンバイ・データベース用の初期化パラメータ・ファイルの準備スタンバイ・データベース用の初期化パラメータ・ファイルの準備スタンバイ・データベース用の初期化パラメータ・ファイルの準備次の手順を実行して、スタンバイの初期化パラメータ・ファイルを作成します。

手順手順手順手順 1 スタンバイ・データベースにプライマリ・データベース・パラメータ・ファイルをスタンバイ・データベースにプライマリ・データベース・パラメータ・ファイルをスタンバイ・データベースにプライマリ・データベース・パラメータ・ファイルをスタンバイ・データベースにプライマリ・データベース・パラメータ・ファイルをコピーするコピーするコピーするコピーする

プライマリ・データベースで使用されているサーバー・パラメータ・ファイル（SPFILE）から、テキストの初期化パラメータ・ファイル（PFILE）を作成します。テキストの初期化パラメータ・ファイルは、スタンバイの位置にコピーして変更できます。次に例を示します。

SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;

このファイルを変更して、フィジカル・スタンバイ・データベースでの使用に適したパラメータ値を含めます。このファイルは、後述の 3.2.5 項で、サーバー・パラメータ・ファイルに変換し直します。

手順手順手順手順 2 フィジカル・スタンバイ・データベースで初期化パラメータを設定するフィジカル・スタンバイ・データベースで初期化パラメータを設定するフィジカル・スタンバイ・データベースで初期化パラメータを設定するフィジカル・スタンバイ・データベースで初期化パラメータを設定する

プライマリ・システムからコピーしたテキストの初期化パラメータ・ファイルの初期化パラメータ設定の多くは、フィジカル・スタンバイ・データベースにも適していますが、一部を変更する必要があります。

例 3-5 は、スタンバイの初期化パラメータ・ファイルの一部です。この中の値は、フィジカル・スタンバイ・データベース用に変更されています。例 3-3 および例 3-4 と異なるパラメータ値は、太字で示されています。例 3-5 に示すパラメータは、ボストンのデータベースがプライマリ・データベース・ロールまたはスタンバイ・データベース・ロールで実行されている場合に有効です。

例例例例 3-5 フィジカル・スタンバイ・データベース用の初期化パラメータを変更するフィジカル・スタンバイ・データベース用の初期化パラメータを変更するフィジカル・スタンバイ・データベース用の初期化パラメータを変更するフィジカル・スタンバイ・データベース用の初期化パラメータを変更する

.

.

.DB_NAME=chicagoDB_UNIQUE_NAME=bostonLOG_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.arcLOG_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=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLEREMOTE_LOGIN_PASSWORDFILE=EXCLUSIVESTANDBY_FILE_MANAGEMENT=AUTOFAL_SERVER=chicagoFAL_CLIENT=boston...

例では、LOG_ARCHIVE_DEST_2初期化パラメータのローカルおよびリモート両方の宛先にREDO データを転送するのに、LGWR プロセスを使用することを前提としています。



また、プライマリ・データベースとスタンバイ・データベースでは、COMPATIBLE初期化パラメータを同じ値に設定する必要があります。値が異なる場合は、REDO 転送サービスが REDOデータをプライマリ・データベースからスタンバイ・データベースに転送できないことがあります。 Data Guard 構成では、COMPATIBLEを少なくとも 9.2.0.1.0 に設定する必要があります。ただし、Oracle Database 10g の新機能を利用する場合は、COMPATIBLEパラメータを 10.2.0.0以上に設定します。

SHOW PARAMETERSコマンドを使用して、他に変更を必要とするパラメータがないかどうかを確認することをお薦めします。

次の表に、例 3-5 のうち、プライマリ・データベースの設定と異なるパラメータ設定に関する簡単な説明を示します。


DB_UNIQUE_NAME このデータベースの一意の名前を指定します。この名前はデータベースと固定され、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。

CONTROL_FILES スタンバイ・データベースの制御ファイルのパス名を指定します。例 3-5 は、2 つの

制御ファイルのパス名を指定する方法を示しています。不良制御ファイルの位置に正常な制御ファイルをコピーした後でインスタンスを簡単に再起動できるように、制御ファイルの第 2 コピーを使用可能にしておくことをお薦めします。

DB_FILE_NAME_CONVERT プライマリ・データベースのデータファイルのパス名とファイル名の位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・

データベースのデータファイルのパス名がスタンバイ・データファイルのパス名に変換されます。スタンバイ・データベースがプライマリ・データベースと同じシス

テムにある場合、またはデータファイルが格納されているスタンバイ・サイトのディレクトリ構造がプライマリ・サイトと異なる場合は、このパラメータが必要です。

LOG_FILE_NAME_CONVERT プライマリ・データベースのオンライン REDO ログ・ファイルの位置を指定し、そ

の後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に変換されます。スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはログ・ファイルが格納されているスタンバイ・システムのディレクトリ構造がプライマリ・システムと異なる場合は、このパラメータが必要です。

LOG_ARCHIVE_DEST_n 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初期化パラメータが自動的に使用されます。詳細は、5.2.3 項を

参照してください。また、LOG_ARCHIVE_DEST_nの詳細は、第 14 章を参照してく

ださい。

FAL_SERVER FAL サーバー（通常はプライマリ・ロールで実行中のデータベース）の Oracle Netサービス名を指定します。ボストンのデータベースがスタンバイ・ロールで実行されている場合、シカゴのデータベースが欠落しているログ・ファイルを自動的に送信できなければ、シカゴのデータベースが FAL サーバーとして使用され、そこから

欠落しているアーカイブ REDO ログ・ファイルがフェッチ（要求）されます。 5.8 項

を参照してください。

FAL_CLIENT ボストンのデータベースの Oracle Net サービス名を指定します。FAL サーバー（シ

カゴ）は、欠落しているアーカイブ REDO ログ・ファイルをボストンのスタンバ

イ・データベースにコピーします。 5.8 項を参照してください。



3.2.4 プライマリ・システムからスタンバイ・システムへのファイルのコピープライマリ・システムからスタンバイ・システムへのファイルのコピープライマリ・システムからスタンバイ・システムへのファイルのコピープライマリ・システムからスタンバイ・システムへのファイルのコピーオペレーティング・システムのコピー・ユーティリティを使用して、次のバイナリ・ファイルをプライマリ・システムからスタンバイ・システムにコピーします。

� 3.2.1 項で作成したバックアップ・データファイル

� 3.2.2 項で作成したスタンバイ制御ファイル

� 3.2.3 項で作成した初期化パラメータ・ファイル

3.2.5 スタンバイ・データベースをサポートする環境の設定スタンバイ・データベースをサポートする環境の設定スタンバイ・データベースをサポートする環境の設定スタンバイ・データベースをサポートする環境の設定次の手順を実行して、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 管理者ガイド』を参照してください。

注意注意注意注意 : 変更の必要性がある他のパラメータについては、初期化パラメータ・ファイルを調べてください。たとえば、ダンプ出力先パラメータ

（BACKGROUND_DUMP_DEST、CORE_DUMP_DEST、USER_DUMP_DEST）の変更が必要な場合があります。これは、スタンバイ・データベースのディレクトリ位置がプライマリ・データベースで指定したディレクトリ位置と異なる場合に必要です。さらに、スタンバイ・システムにまだ存在していないディレクトリがある場合は、そのディレクトリを作成する必要があります。



手順手順手順手順 4 Oracle Net サービス名を作成するサービス名を作成するサービス名を作成するサービス名を作成する

プライマリ・システムとスタンバイ・システムの両方で、Oracle Net Manager を使用して、プライマリ・データベースとスタンバイ・データベースのネットワーク・サービス名を作成します。ネットワーク・サービス名は REDO 転送サービスで使用されます。

Oracle Net ネット・サービス名は、プライマリ・データベースとスタンバイ・データベースに対するリスナーの構成時に指定したものと同じプロトコル、ホスト・アドレス、ポートおよびサービスを使用する接続記述子に解析される必要があります。この接続記述子は、専用サーバーが使用されるように指定する必要もあります。

『Oracle Database Net Services 管理者ガイド』および『Oracle Database 管理者ガイド』を参照してください。

手順手順手順手順 5 スタンバイ・データベース用のサーバー・パラメータ・ファイルを作成するスタンバイ・データベース用のサーバー・パラメータ・ファイルを作成するスタンバイ・データベース用のサーバー・パラメータ・ファイルを作成するスタンバイ・データベース用のサーバー・パラメータ・ファイルを作成する

フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースに即時に推移する場合は（第 4 章「ロジカル・スタンバイ・データベースの作成」を参照）、この手順をスキップして 3.2.6 項の指示に進みます。

アイドル状態のスタンバイ・データベースで、SQL の CREATE文を使用して、3-9 ページの手順 2 で編集したテキストの初期化パラメータ・ファイルから、スタンバイ・データベース用のサーバー・パラメータ・ファイルを作成します。次に例を示します。

SQL> CREATE SPFILE FROM PFILE='initboston.ora';

3.2.6 フィジカル・スタンバイ・データベースの起動フィジカル・スタンバイ・データベースの起動フィジカル・スタンバイ・データベースの起動フィジカル・スタンバイ・データベースの起動フィジカル・スタンバイ・データベースおよび 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.2.7 フィジカル・スタンバイ・データベースが正しく実行されているかフィジカル・スタンバイ・データベースが正しく実行されているかフィジカル・スタンバイ・データベースが正しく実行されているかフィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認どうかの確認どうかの確認どうかの確認

フィジカル・スタンバイ・データベースを作成して 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---------- ------------------ ------------------ 8 11-JUL-02 17:50:45 11-JUL-02 17:50:53 9 11-JUL-02 17:50:53 11-JUL-02 17:50:58 10 11-JUL-02 17:50:58 11-JUL-02 17:51:03

3 rows selected.

手順手順手順手順 2 ログ・スイッチを強制実行してカレント・オンラインログ・スイッチを強制実行してカレント・オンラインログ・スイッチを強制実行してカレント・オンラインログ・スイッチを強制実行してカレント・オンライン REDO ログ・ファイルをログ・ファイルをログ・ファイルをログ・ファイルをアーカイブするアーカイブするアーカイブするアーカイブする

プライマリ・データベースで、ALTER SYSTEM SWITCH LOGFILE文を発行して、ログ・スイッチを強制実行し、カレント・オンライン REDO ログ・ファイル・グループをアーカイブします。


手順手順手順手順 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---------- ------------------ ------------------ 8 11-JUL-02 17:50:45 11-JUL-02 17:50:53 9 11-JUL-02 17:50:53 11-JUL-02 17:50:58 10 11-JUL-02 17:50:58 11-JUL-02 17:51:03 11 11-JUL-02 17:51:03 11-JUL-02 18:34:114 rows selected.

アーカイブ REDO ログ・ファイルは、フィジカル・スタンバイ・データベースに適用できます。


作成後の手順

手順手順手順手順 4 新規アーカイブ新規アーカイブ新規アーカイブ新規アーカイブ REDO ログ・ファイルの適用を確認するログ・ファイルの適用を確認するログ・ファイルの適用を確認するログ・ファイルの適用を確認する

スタンバイ・データベースで、V$ARCHIVED_LOGビューを問い合せて、アーカイブ REDO ログ・ファイルが適用されたことを確認します。

SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG 2 ORDER BY SEQUENCE#;

SEQUENCE# APP--------- --- 8 YES 9 YES 10 YES 11 YES

4 rows selected.

ログ転送サービスとログ適用サービスが正常に動作しているかどうかの確認方法は、5.9.1 項「ログ・ファイル・アーカイブ情報の監視」および 8.5.4 項「フィジカル・スタンバイ・データベースでのログ適用サービスの監視」を参照してください。

3.3 作成後の手順作成後の手順作成後の手順作成後の手順この時点で、フィジカル・スタンバイ・データベースが実行中であり、大パフォーマンス・レベルのデータ保護を提供できます。次のリストに、フィジカル・スタンバイ・データベースに対して実行できるその他の準備について説明します。

� データ保護モードのアップグレード

Data Guard 構成は、初は大パフォーマンス・モード（デフォルト）で設定されます。データ保護モードの詳細と現行の保護モードをアップグレードまたはダウングレードする方法は、5.6 項を参照してください。

� フラッシュバック・データベースの有効化

フラッシュバック・データベースにより、フェイルオーバー後のプライマリ・データベースの再作成の必要がなくなります。フラッシュバック・データベースは従来のPoint-in-Time リカバリと同様の機能で、データベースを過去の新時点の状態に戻すことができます。フラッシュバック・データベースでは、データファイルをバックアップからリストアしたり REDO データを広範囲に適用する必要がないため、Point-in-Time リカバリよりも高速です。フラッシュバック・データベースは、プライマリ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できます。 Data Guard 環境でのフラッシュバック・データベースの使用例は、12.4 項および 12.5 項を参照してください。フラッシュバック・データベースの詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。


ロジカル・スタンバイ・データベースの

4
ロジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースの作成
この章では、ロジカル・スタンバイ・データベースを作成する手順について説明します。この章は、次の主な項目で構成されています。

� ロジカル・スタンバイ・データベースの作成要件

� ロジカル・スタンバイ・データベースの作成手順

� 作成後の手順

関連項目関連項目関連項目関連項目 :

� サーバー・パラメータ・ファイルの作成方法と使用方法は、『Oracle Database 管理者ガイド』を参照してください。

� グラフィカル・ユーザー・インタフェースを使用してロジカル・スタンバイ・データベースを自動的に作成する方法は、『Oracle Data Guard Broker』および Oracle Enterprise Manager のオンライン・ヘルプを参照してください。

作成 4-1

ロジカル・スタンバイ・データベースの作成要件

4.1 ロジカル・スタンバイ・データベースの作成要件ロジカル・スタンバイ・データベースの作成要件ロジカル・スタンバイ・データベースの作成要件ロジカル・スタンバイ・データベースの作成要件ロジカル・スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されていることを初に確認する必要があります。表 4-1 は、ロジカル・スタンバイ・データベースを作成するための準備としてプライマリ・データベースで実行するタスクのチェックリストです。各タスクを詳細に説明している参照先の項も記載されています。

4.1.1 表のデータ型および記憶域属性のサポートの判別表のデータ型および記憶域属性のサポートの判別表のデータ型および記憶域属性のサポートの判別表のデータ型および記憶域属性のサポートの判別ロジカル・スタンバイ・データベースを設定する前に、ロジカル・スタンバイ・データベースが、プライマリ・データベースのデータ型と表をメンテナンスできることを確認する必要があります。データ型および記憶域型に関する考慮事項の詳細リストは、付録 C を参照してください。

4.1.2 プライマリ・データベース内の表の行が一意に識別できることの確認プライマリ・データベース内の表の行が一意に識別できることの確認プライマリ・データベース内の表の行が一意に識別できることの確認プライマリ・データベース内の表の行が一意に識別できることの確認ロジカル・スタンバイ・データベースがプライマリ・データベースのバックアップ・コピーから作成されていても、ロジカル・スタンバイ・データベースの物理的な構成は、プライマリ・データベースの構成とは異なります。そのため、プライマリ・データベースによって生成された REDO レコードに含まれている ROWID は、ロジカル・スタンバイ・データベース内の対応する行を識別するためには使用できません。

Oracle では、ロジカル・スタンバイ・データベース内の変更された行をロジカルに識別するために、主キーまたは一意索引サプリメンタル・ロギングを使用します。また、データベース全体の主キーおよび一意索引サプリメンタル・ロギングが使用可能になると、各 UPDATE文により、ロジカル・スタンバイ・データベース内の変更された行を一意に識別するために、REDOログに必要な列の値が書き込まれます。

� 表に主キーが定義されている場合、主キーは変更された行を識別するために、UPDATE文の一部としてログに記録されます。

� 主キーがない場合、一番短く、NULL 値が許容されていない一意キーが、変更された行を識別するために、UPDATE文の一部としてログに記録されます。

� 主キーも NULL 値が許容されていない一意キーもない場合、バインドされているサイズのすべての列が、変更された行を識別するために、UPDATE文の一部としてログに記録されます。つまり、LONG、LOB、LONG ROW、オブジェクト型およびコレクション以外のすべての列が、ログに記録されます。

SQL Apply で、REDO データの更新をロジカル・スタンバイ・データベースに効率的に適用できるように、適切で可能な場合には、必ずプライマリ・データベースの表に主キーまたはNULL 値が許容されていない一意索引を追加することをお薦めします。

表表表表 4-1 ロジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備ロジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備ロジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備ロジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備

参照先参照先参照先参照先タスクタスクタスクタスク

4.1.1 項表のデータ型および記憶域属性のサポートの判別

4.1.2 項プライマリ・データベース内の表の行が一意に識別できることの確認


ロジカル・スタンバイ・データベースの作成要件

ロジカル・スタンバイ・データベース内のレプリケートされている各表の行を 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 ページの9.6.1 項「主キー RELY 制約の作成」を参照してください。

ロジカル・スタンバイ・データベースの作成 4-3

ロジカル・スタンバイ・データベースの作成手順

4.2 ロジカル・スタンバイ・データベースの作成手順ロジカル・スタンバイ・データベースの作成手順ロジカル・スタンバイ・データベースの作成手順ロジカル・スタンバイ・データベースの作成手順この項では、ロジカル・スタンバイ・データベースの作成で実行するタスクについて説明します。

表 4-2 は、ロジカル・スタンバイ・データベースの作成で実行するタスクのチェックリストで、各タスクを実行するデータベースを指定します。各タスクを詳細に説明している参照先の項も記載されています。

4.2.1 フィジカル・スタンバイ・データベースの作成フィジカル・スタンバイ・データベースの作成フィジカル・スタンバイ・データベースの作成フィジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースを作成するには、次のように初にフィジカル・スタンバイ・データベースを作成してから、ロジカル・スタンバイ・データベースへと推移させます。第 3 章「フィジカル・スタンバイ・データベースの作成」の指示に従ってフィジカル・スタンバイ・データベースを作成します。

4.2.2 フィジカル・スタンバイ・データベースでのフィジカル・スタンバイ・データベースでのフィジカル・スタンバイ・データベースでのフィジカル・スタンバイ・データベースでの REDO Apply の停止の停止の停止の停止ロジカル・スタンバイ・データベースに変換する前に、実行時間に関係なく、新規フィジカル・スタンバイ・データベースで REDO Apply を実行できます。ただし、ロジカル・スタンバイ・データベースに変換する前に、フィジカル・スタンバイ・データベースで REDO Apply を停止する必要があります。 REDO Apply の停止は、LogMiner ディクショナリを含む REDO の後に変更が適用されることを避けるために必要です（4-6 ページの 4.2.3.2 項「REDO データでのディクショナリの構築」で説明）。

REDO Apply を停止するには、フィジカル・スタンバイ・データベースで次の文を発行します。データベースが複数のインスタンスから構成される RAC データベースの場合、この文を発行する前に、初にインスタンスの数を 1 に削減する必要があります。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

表表表表 4-2 ロジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースの作成

参照先参照先参照先参照先タスクタスクタスクタスクデータベースデータベースデータベースデータベース

4.2.1 項フィジカル・スタンバイ・データベースの作成プライマリ

4.2.2 項フィジカル・スタンバイ・データベースでの REDO Apply の停止スタンバイ

4.2.3 項ロジカル・スタンバイ・データベースをサポートするためのプライマリ・データベースの準備

プライマリ

4.2.4 項ロジカル・スタンバイ・データベースへの推移スタンバイ

4.2.5 項ロジカル・スタンバイ・データベースのオープンスタンバイ

4.2.6 項ロジカル・スタンバイ・データベースが正しく実行されているかどうかの確認スタンバイ



4.2.3 ロジカル・スタンバイ・データベースをサポートするためのプライマリ・ロジカル・スタンバイ・データベースをサポートするためのプライマリ・ロジカル・スタンバイ・データベースをサポートするためのプライマリ・ロジカル・スタンバイ・データベースをサポートするためのプライマリ・データベースの準備データベースの準備データベースの準備データベースの準備

この項は、次の項目で構成されています。

� ロールの推移のためのプライマリ・データベースの準備

� REDO データでのディクショナリの構築

4.2.3.1 ロールの推移のためのプライマリ・データベースの準備ロールの推移のためのプライマリ・データベースの準備ロールの推移のためのプライマリ・データベースの準備ロールの推移のためのプライマリ・データベースの準備3-5 ページの 3.1.4 項「プライマリ・データベースの初期化パラメータの設定」では、プライマリ・データベースがフィジカル・スタンバイ・ロールに推移する場合に有効になるように、複数のスタンバイ・ロールの初期化パラメータを設定しました。プライマリ・データベースをロジカル・スタンバイ・ロールに推移させる場合は、ロールの推移後にパラメータを変更せずにすむように、プライマリ・データベースに例 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.2.3.2 REDO データでのディクショナリの構築データでのディクショナリの構築データでのディクショナリの構築データでのディクショナリの構築LogMiner ディクショナリは、SQL Apply の LogMiner コンポーネントによって REDO での変更が適切に解釈できるように、REDO データに構築される必要があります。また、サプリメンタル・ロギングを設定して、主キーおよび一意索引の列がログに記録されるようにします。サプリメンタル・ロギング情報により、各更新に、文によって変更された各行をロジカルに識別するための十分な情報が含まれていることが保証されます。

LogMiner ディクショナリを構築するには、次の文を発行します。

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

DBMS_LOGSTDBY.BUILDプロシージャでは、既存のトランザクションがすべて完了するのを待機します。プライマリ・データベースで長時間実行されているトランザクションは、このコマンドの適時性に影響を与えます。

DBMS_LOGSTDBY.BUILDプロシージャでは、フラッシュバック問合せを使用して、REDO ストリームにログが記録されるデータ・ディクショナリの一貫性のあるスナップショットを取得します。プライマリ・データベースおよびロジカル・スタンバイ・データベースの両方で、UNDO_RETENTION初期化パラメータを 3600 に設定することをお薦めします。

4.2.4 ロジカル・スタンバイ・データベースへの推移ロジカル・スタンバイ・データベースへの推移ロジカル・スタンバイ・データベースへの推移ロジカル・スタンバイ・データベースへの推移この項では、ロジカル・スタンバイ・データベースに推移するために、フィジカル・スタンバイ・データベースを準備する方法について説明します。この章は、次の項目で構成されています。

� ロジカル・スタンバイ・データベースへの変換

� 新規パスワード・ファイルの作成

� ロジカル・スタンバイ・データベース用の初期化パラメータの調整

4.2.4.1 ロジカル・スタンバイ・データベースへの変換ロジカル・スタンバイ・データベースへの変換ロジカル・スタンバイ・データベースへの変換ロジカル・スタンバイ・データベースへの変換REDO ログには、フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換するために必要な情報が含まれています。ロジカル・スタンバイ・データベースへの変換準備が完了するまで REDO データをフィジカル・スタンバイ・データベースに適用し続けるには、次の SQL 文を発行します。

SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY new-db_name;

この文では、ログ・ファイル内に LogMiner ディクショナリが見つかるまで、REDO データを適用しながら待機します。 4.2.3.2 項「REDO データでのディクショナリの構築」に生成されたREDO がスタンバイ・データベースに推移されるのにかかる時間と、適用する必要のあるREDO データの量にもよりますが、この作業には数分かかります。プライマリ・データベースでディクショナリ構築が正常に実行されるまで、このコマンドは完了しません。 SQL 文を取り消すには、別の SQL セッションから ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL文を発行します。

4.2.4.2 新規パスワード・ファイルの作成新規パスワード・ファイルの作成新規パスワード・ファイルの作成新規パスワード・ファイルの作成変換プロセスにより、ロジカル・スタンバイ・データベース用のデータベース名（DB_NAME初期化パラメータを使用して初に設定したデータベース名）が変更されるため、パスワード・ファイルを再作成する必要があります。詳細は、『Oracle Database 管理者ガイド』を参照してください。

関連項目関連項目関連項目関連項目 : 『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』の DBMS_LOGSTDBY.BUILD PL/SQL パッケージおよび

『Oracle Database リファレンス』の UNDO_RETENTION初期化パラメータ



4.2.4.3 ロジカル・スタンバイ・データベース用の初期化パラメータの調整ロジカル・スタンバイ・データベース用の初期化パラメータの調整ロジカル・スタンバイ・データベース用の初期化パラメータの調整ロジカル・スタンバイ・データベース用の初期化パラメータの調整ロジカル・スタンバイ・データベースで、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=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_DEST_STATE_3=ENABLE

次の表に、例 4-2 に示した初期化パラメータで定義されるアーカイブ・プロセスを示します。

ボストンのデータベースがプライマリ・ボストンのデータベースがプライマリ・ボストンのデータベースがプライマリ・ボストンのデータベースがプライマリ・ロールで稼働している場合ロールで稼働している場合ロールで稼働している場合ロールで稼働している場合

ボストンのデータベースがロジカル・ボストンのデータベースがロジカル・ボストンのデータベースがロジカル・ボストンのデータベースがロジカル・スタンバイ・ロールで稼働している場合スタンバイ・ロールで稼働している場合スタンバイ・ロールで稼働している場合スタンバイ・ロールで稼働している場合

LOG_ARCHIVE_DEST_1 /arch1/boston/内のローカル・アー

カイブ REDO ログ・ファイルにローカ

ル・オンライン REDO ログ・ファイルか

らプライマリ・データベースによって生成された REDO データをアーカイブする

よう指示。

/arch1/boston/内のローカル・アーカイブ

REDO ログ・ファイルにローカル・オンライン

REDO ログ・ファイルからロジカル・スタンバ

イ・データベースによって生成された REDOデータをアーカイブするよう指示。

LOG_ARCHIVE_DEST_2 リモート・ロジカル・スタンバイ・データベース chicagoに REDO データを転

送するよう指示。

無視。LOG_ARCHIVE_DEST_2は、bostonが

プライマリ・ロールで稼働している場合にのみ有効。

LOG_ARCHIVE_DEST_3 無視。LOG_ARCHIVE_DEST_3は、

bostonがスタンバイ・ロールで稼働し

ている場合にのみ有効。


REDO ログ・ファイルにプライマリ・データ

ベースから受信した REDO データをアーカイブ

するよう指示。


作成後の手順

4.2.5 ロジカル・スタンバイ・データベースのオープンロジカル・スタンバイ・データベースのオープンロジカル・スタンバイ・データベースのオープンロジカル・スタンバイ・データベースのオープン新規データベースはプライマリ・データベースと論理的には同じですが、プライマリ・データベースとのトランザクション一貫性に欠けるため、リカバリ操作が異なります。

新規ロジカル・スタンバイ・データベースをオープンするには、次の文を発行し、RESETLOGSオプションを使用してオープンする必要があります。

SQL> ALTER DATABASE OPEN RESETLOGS;

データベースがオープンされるのはこれが初めてなため、データベースのグローバル名は、新しい DB_NAME初期化パラメータと一致するように自動的に調整されます。

次の文を発行して、ロジカル・スタンバイ・データベースに対する REDO データの適用を開始します。次に例を示します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

4.2.6 ロジカル・スタンバイ・データベースが正しく実行されているかどうかロジカル・スタンバイ・データベースが正しく実行されているかどうかロジカル・スタンバイ・データベースが正しく実行されているかどうかロジカル・スタンバイ・データベースが正しく実行されているかどうかの確認の確認の確認の確認

ロジカル・スタンバイ・データベースが適切に実行されていることを検証するには、次の項を参照してください。

� 5.9.1 項「ログ・ファイル・アーカイブ情報の監視」 5-32 ページ

� 6.4.4 項「ロジカル・スタンバイ・データベースでのログ適用サービスの監視」6-7 ページ

� 第 9 章「ロジカル・スタンバイ・データベースの管理」9-1 ページ

4.3 作成後の手順作成後の手順作成後の手順作成後の手順この時点で、ロジカル・スタンバイ・データベースが実行中であり、大パフォーマンス・レベルのデータ保護を提供できます。次のリストに、ロジカル・スタンバイ・データベースに対して実行できるその他の準備について説明します。

� データ保護モードのアップグレード

Data Guard 構成は、初は大パフォーマンス・モード（デフォルト）で設定されます。データ保護モードの詳細と現行の保護モードをアップグレードまたはダウングレードする方法は、5-20 ページの 5.6 項「データ保護モードの設定」を参照してください。

� フラッシュバック・データベースの有効化

フラッシュバック・データベースにより、フェイルオーバー後のプライマリ・データベースの再作成の必要がなくなります。フラッシュバック・データベースは従来のPoint-in-Time リカバリと同様の機能で、データベースを過去の新時点の状態に戻すことができます。フラッシュバック・データベースでは、データファイルをバックアップからリストアしたり REDO データを広範囲に適用する必要がないため、Point-in-Time リカバリよりも高速です。フラッシュバック・データベースは、プライマリ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できます。 Data Guard 環境でのフラッシュバック・データベースの使用例は、12-24 ページの 12.4 項「フェイルオーバー後のフラッシュバック・データベースの使用」および 12-28 ページの 12.5 項「Open Resetlogs 文の発行後のフラッシュバック・データベースの使用」を参照してください。フラッシュバック・データベースの詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。


REDO 転送サー

5
REDO 転送サービス転送サービス転送サービス転送サービス
この章では、本番データベースから 1 つ以上の宛先に REDO を転送するように REDO 転送サービスを構成する方法について説明します。この章は、次の項目で構成されています。

� REDO 転送サービスの概要

� REDO データの送信先

� REDO データの送信方法

� REDO データの送信時間

� エラーが発生した場合の対処方法

� データ保護モードの設定

� ログ・ファイルの管理

� アーカイブ・ギャップの管理

� 確認

ビス 5-1

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 データの転送データの転送データの転送データの転送


REDO データの送信先

5.2 REDO データの送信先データの送信先データの送信先データの送信先この項は、次の項目で構成されています。

� 宛先タイプ

� REDO データの送信方法

� フラッシュ・リカバリ領域の設定

5.2.1 宛先タイプ宛先タイプ宛先タイプ宛先タイプREDO 転送サービスは、次のように複数タイプの宛先をサポートしています。

� Oracle Data Guard スタンバイ・データベース

スタンバイ・データベースの宛先には、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースを使用できます。スタンバイ・データベースについては、1.1.2 項を参照してください。

� アーカイブ 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


5.2.2 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 に、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-1 LOG_ARCHIVE_DEST_STATE_n 初期化パラメータの属性初期化パラメータの属性初期化パラメータの属性初期化パラメータの属性

属性属性属性属性説明説明説明説明

ENABLE REDO ログ転送サービスはこの宛先に REDO データを転送できる。これはデフォル

トです。

DEFER REDO 転送サービスはこの宛先に REDO データを転送しない。これは有効ですが、

使用されない宛先です。

ALTERNATE この宛先は使用可能ではないが、関連付けられている宛先への通信に障害が起きると使用可能になる。

RESET 機能は DEFERと同じだが、前に失敗している場合は宛先に関するエラー・メッセー

ジを消去する。



図図図図 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=ENABLELOG_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 章を参照してください。



5.2.2.1 宛先属性の変更宛先属性の変更宛先属性の変更宛先属性の変更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;

5.2.2.2 V$ARCHIVE_DEST ビューを使用した属性の表示ビューを使用した属性の表示ビューを使用した属性の表示ビューを使用した属性の表示LOG_ARCHIVE_DEST_n初期化パラメータの現行の設定を表示するには、V$ARCHIVE_DESTビューを問合せます。

5.2.3 フラッシュ・リカバリ領域の設定フラッシュ・リカバリ領域の設定フラッシュ・リカバリ領域の設定フラッシュ・リカバリ領域の設定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 管理者ガイド』を参照してください）。


� LOG_ARCHIVE_DEST_10 の宛先の使用

� 他の LOG_ARCHIVE_DEST_n の宛先の使用

� STANDBY_ARCHIVE_DEST の宛先の使用

� プライマリ・データベースとスタンバイ・データベースでフラッシュ・リカバリ領域を共有する

フラッシュ・リカバリ領域の構成方法については『Oracle Database バックアップおよびリカバリ基礎』を、フラッシュ・リカバリ領域内のアーカイブ REDO ログ・ファイルに対する削除ポリシーの設定方法については 10.3.4 項を参照してください。

注意注意注意注意 : フラッシュ・リカバリ領域に格納されたアーカイブ REDO ログ・ファイルのファイル名は、Oracle Managed Files（OMF）によって自動的に生成されます。LOG_ARCHIVE_FORMAT初期化パラメータによって指定された形式には基づいていません。

注意注意注意注意 : プライマリ・データベースからロジカル・スタンバイ・データベースのフラッシュ・リカバリ領域には、REDO データを書き込めません。



5.2.3.1 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属性で指定されたディレクトリおよびファイル名が使用されます。

5.2.3.2 他の他の他の他の 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)'



5.2.3.3 STANDBY_ARCHIVE_DEST の宛先の使用の宛先の使用の宛先の使用の宛先の使用フィジカル・スタンバイ・データベースの場合は、フラッシュ・リカバリ領域を指すようにSTANDBY_ARCHIVE_DESTパラメータを定義できます。次に例を示します。

STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'

5.2.3.4 プライマリ・データベースとスタンバイ・データベースでプライマリ・データベースとスタンバイ・データベースでプライマリ・データベースとスタンバイ・データベースでプライマリ・データベースとスタンバイ・データベースでフラッシュ・リカバリ領域を共有するフラッシュ・リカバリ領域を共有するフラッシュ・リカバリ領域を共有するフラッシュ・リカバリ領域を共有するフラッシュ・リカバリ領域を共有する各データベースに、DB_UNIQUE_NAME初期化パラメータで一意のデータベース名が指定されている場合は、データベース間でフラッシュ・リカバリ領域を共有できます。

次の例に、/arch/oradataディレクトリにあるフラッシュ・リカバリ領域を共有するプライマリおよびスタンバイ・データベースで、初期化パラメータを指定する方法を示します。例 5-3では DB_UNIQUE_NAMEパラメータが指定されていませんが、デフォルトで DB_NAME初期化パラメータに指定されている名前 PAYROLLに設定されます。

例例例例 5-3 共有リカバリ領域に関するプライマリ・データベースの初期化パラメータ共有リカバリ領域に関するプライマリ・データベースの初期化パラメータ共有リカバリ領域に関するプライマリ・データベースの初期化パラメータ共有リカバリ領域に関するプライマリ・データベースの初期化パラメータ

DB_NAME=PAYROLLLOG_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=PAYROLLDB_UNIQUE_NAME=bostonLOG_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 バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

注意注意注意注意 : ロジカル・スタンバイ・データベース（SQL Apply）でSTANDBY_ARCHIVE_DESTパラメータを使用して指定したフラッシュ・リカバリ領域の宛先は無視されます。


REDO データの送信方法

5.3 REDO データの送信方法データの送信方法データの送信方法データの送信方法プライマリ・データベースでは、Oracle Data Guard はアーカイバ・プロセス（ARCn）またはログ・ライター・プロセス（LGWR）を使用し、トランザクション REDO データを収集してスタンバイ宛先に転送します。同じ宛先への REDO データ送信にアーカイバ・プロセスとログ・ライター・プロセスの両方を使用することはできませんが、ある宛先にはログ・ライター・プロセスを使用し、他の宛先にはアーカイバ・プロセスを使用して REDO データを送信するように選択することはできます。


� アーカイバ・プロセス（ARCn）を使用した REDO データのアーカイブ

� ログ・ライター・プロセス（LGWR）を使用した REDO データのアーカイブ

� セキュアな REDO データの転送の提供

また、Data Guard では、ギャップの自動解消および再同期化のために、フェッチ・アーカイブ・ログ（FAL）クライアントおよびサーバーを使用して、ネットワーク停止後にアーカイブREDO ログ・ファイルがスタンバイ宛先に送信されます。 FAL プロセスとギャップの解消については、5.8 項を参照してください。

5.3.1 アーカイバ・プロセス（アーカイバ・プロセス（アーカイバ・プロセス（アーカイバ・プロセス（ARCn）を使用した）を使用した）を使用した）を使用した REDO データのアーカイブデータのアーカイブデータのアーカイブデータのアーカイブデフォルトで、REDO 転送サービスは ARCn プロセスを使用して、オンライン REDO ログ・ファイルをプライマリ・データベースにアーカイブします。ARCn アーカイブ・プロセスは、Data Guard 構成で大パフォーマンス・レベルのデータ保護のみをサポートします。他のデータ保護モードで動作するスタンバイの場所に REDO データを転送するには、LGWR プロセスを使用する必要があります。（Data Guard のデータ保護モードの詳細は、5.6 項を参照してください。）


� ARCn のアーカイブ動作を制御する初期化パラメータ

� ARCn のアーカイブ処理

5.3.1.1 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;



5.3.1.2 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 ログ・ファイルをロジカル・スタンバイ・データベースに適用します。



デフォルトの ARCn アーカイブ・プロセスでは、ローカルのアーカイブとリモートのアーカイブの関連付けが解除されるため、バックアップ直後にプライマリ・データベース上のアーカイブ REDO ログ・ファイルを削除するためのポリシーを持つサイトでは、プライマリ・データベースのアーカイブ REDO ログ・ファイルを削除する前に、スタンバイの宛先が対応するREDO データを受信することを確認する必要があります。 V$ARCHIVED_LOGビューを問い合せると、スタンバイの宛先で REDO データが受信されたことを確認できます。

5.3.2 ログ・ライター・プロセス（ログ・ライター・プロセス（ログ・ライター・プロセス（ログ・ライター・プロセス（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 アーカイブ・プロセス

5.3.2.1 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構成における同期的なネットワーク転送の例については、5.3.2.2 項を参照してください。これは、デフォルトのネットワーク転送設定です。

� ASYNC属性を指定すると、すべてのネットワーク I/O は非同期的に実行され、ネットワーク I/O の完了を待たずに、実行中のアプリケーションまたはユーザーへ制御が即時に戻されます。Data Guard 構成における非同期ネットワーク転送の例については、5.3.2.3 項を参照してください。

注意注意注意注意 : LGWR プロセスを使用するように宛先を構成しても、なんらかの原因で LGWR プロセスが宛先にアーカイブできなくなると、REDO 転送は ARCn プロセスの使用に戻ってアーカイブ操作を完了します。



5.3.2.2 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=ENABLELOG_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-4 スタンバイスタンバイスタンバイスタンバイ REDO ログ・ファイルを使用したリモートの宛先へのログ・ファイルを使用したリモートの宛先へのログ・ファイルを使用したリモートの宛先へのログ・ファイルを使用したリモートの宛先への LGWR SYNC アーカイブアーカイブアーカイブアーカイブ

5.3.2.3 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=ENABLELOG_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 ログ・ファイルがいっぱいになると、ログ・スイッチが発生し、アーカイバ・プロセスはログ・ファイルを通常どおりローカルにアーカイブします。



図図図図 5-5 ネットワーク・サーバー（ネットワーク・サーバー（ネットワーク・サーバー（ネットワーク・サーバー（LNSn）プロセスを使用した）プロセスを使用した）プロセスを使用した）プロセスを使用した LGWR ASYNC アーカイブアーカイブアーカイブアーカイブ

注意注意注意注意 : Oracle Database 10g リリース 10.2 からは、LGWR属性と ASYNC属性の両方で構成されている LOG_ARCHIVE_DEST_nの宛先には、NET_TIMEOUT属性を指定する必要はありません。これは、リリース 10.2 では、どのような理由であれログ・ライター・プロセスが LNSn を待機することはないためです。そのため、NET_TIMEOUT属性を指定する必要はありません。

注意注意注意注意 : フラッシュ・リカバリ領域の宛先指定には、LOG_ARCHIVE_DESTまたは LOG_ARCHIVE_DUPLEX_DEST初期化パラメータを使用しないでください。



5.3.3 セキュアなセキュアなセキュアなセキュアな REDO データの転送の提供データの転送の提供データの転送の提供データの転送の提供Data Guard は、セキュアな環境を提供し、REDO データがスタンバイ・データベースに転送される際に改ざんされる可能性を防止します。

REDO 転送サービスは、REDO データの送信に認証ネットワーク・セッションを使用します。これらのセッションは、パスワード・ファイル内の SYS ユーザー・パスワードを使用して認証されます。Data Guard 構成内の全データベースでパスワード・ファイルを使用する必要があり、このパスワード・ファイル内の SYS パスワードは、全システムで同一である必要があります。Oracle Advanced Security がインストールされていない場合もこの認証は実行可能で、REDO の転送の際にある程度のセキュリティを提供します。

プライマリ・データベースと各スタンバイ・データベースで、次の手順を実行します。

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 をさらに強力に保護するには（たとえば、REDO を暗号化したり、ネットワーク上の REDO 通信の整合性チェックサム値を計算し、ネットワーク上での REDO の改ざんを防止する）、Oracle Advanced Security をインストールし、使用することをお薦めします。『Oracle Database Advanced Security 管理者ガイド』を参照してください。


REDO データの送信時間

5.4 REDO データの送信時間データの送信時間データの送信時間データの送信時間この項は、次の項目で構成されています。

� VALID_FOR 属性を使用したロール・ベースの宛先の指定

� 一意のプライマリ・データベース名とスタンバイ・データベース名の指定

5.4.1 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 章を参照してください。


REDO データの送信時間

5.4.2 一意のプライマリ・データベース名とスタンバイ・データベース名の一意のプライマリ・データベース名とスタンバイ・データベース名の一意のプライマリ・データベース名とスタンバイ・データベース名の一意のプライマリ・データベース名とスタンバイ・データベース名の指定指定指定指定

DB_UNIQUE_NAME属性を使用すると、宛先の構成時に一意のデータベース名を指定できます。これにより、Real Application Clusters のプライマリ・データベースが大保護レベルまたは大可用性保護レベルで実行されている場合、そのプライマリ・データベースが含まれているData Guard 構成にスタンバイ・データベースを動的に追加できるようになります。 LOG_ARCHIVE_CONFIGパラメータが定義されている場合、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=chicagoDB_UNIQUE_NAME=chicagoLOG_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 を受信できません。

注意注意注意注意 : リモートの宛先のスタンバイ・データベースが DB_UNIQUE_NAME初期化パラメータで識別されていない場合は、プライマリ・インスタンスを起動する前にスタンバイ・データベースにアクセスできる必要があります。


エラーが発生した場合の対処方法

デフォルトで、LOG_ARCHIVE_CONFIGパラメータは、プライマリ・データベースからスタンバイ・データベースへの REDO データの送信を許可し、また、スタンバイ・データベースによるプライマリ・データベースからのアーカイブ用の REDO の受信を許可します。これは、LOG_ARCHIVE_CONFIGパラメータの SENDおよび RECEIVE属性を設定した場合と同じです。

5.5 エラーが発生した場合の対処方法エラーが発生した場合の対処方法エラーが発生した場合の対処方法エラーが発生した場合の対処方法アーカイブ障害を処理するために、LOG_ARCHIVE_DEST_nパラメータの REOPEN、MAX_FAILURESおよび ALTERNATE属性を使用して、宛先へのアーカイブ・プロセスが失敗した場合に実行する処置を指定できます。これには次の処置が含まれます。

� 指定した期間が経過した後、失敗した宛先へのアーカイブ操作を上限回数まで再試行する

� 代替宛先を使用する

� 接続を再確立して失敗した宛先への REDO データ送信を再開する試行回数を制御する

5.5.1 アーカイブ操作の再試行アーカイブ操作の再試行アーカイブ操作の再試行アーカイブ操作の再試行REOPEN属性を使用して、ARCn プロセスまたは LGWR プロセスがエラー発生後に失敗した宛先への REDO データ再送信を試行するかどうかと、その時期を指定します。

REOPEN=seconds 属性を使用して、エラー発生後にアーカイブ・プロセスが失敗した宛先へのアクセスを再試行するまでの小経過秒数を指定します。デフォルト値は 300 秒です。REOPEN属性に設定した値は、接続障害のみでなくすべてのエラーに適用されます。 REOPEN=0を指定すると、このオプションをオフにすることができます。これにより、障害発生後は宛先へのアクセスが再試行されなくなります。

代替アーカイブ先への転送に失敗した場合に REOPEN属性が 0（ゼロ）に設定されていると、REDO 転送サービスは次回の REDO データのアーカイブ時に、データを代替アーカイブ先に送信しようとします。

5.5.2 代替アーカイブ先の使用代替アーカイブ先の使用代替アーカイブ先の使用代替アーカイブ先の使用ALTERNATE属性では、元のアーカイブ先で障害が発生したときに使用できる代替アーカイブ先を定義します。代替アーカイブ先が指定されていない場合は、障害発生時に宛先が自動的に他の宛先に変更されることはありません。

図 5-6 では、REDO データがローカルのディスク・デバイスにアーカイブされています。当初のアーカイブ先のデバイスがいっぱいであったり、利用できない場合、アーカイブ操作は自動的に代替アーカイブ先のデバイスにリダイレクトされます。

注意注意注意注意 : LOG_ARCHIVE_CONFIG初期化パラメータは、廃止になったREMOTE_ARCHIVE_ENABLE初期化パラメータを置き換えます。これら両方のパラメータを同じ SPFILE またはテキスト初期化パラメータ・ファイルで指定しないでください。


エラーが発生した場合の対処方法

図図図図 5-6 代替アーカイブ先のデバイスへのアーカイブ操作代替アーカイブ先のデバイスへのアーカイブ操作代替アーカイブ先のデバイスへのアーカイブ操作代替アーカイブ先のデバイスへのアーカイブ操作

REOPEN属性は、ALTERNATE属性よりも優先されます。代替アーカイブ先は、次のいずれかの条件が満たされている場合にのみ使用されます。

� REOPEN属性に、値 0（ゼロ）が指定されている。

� 0（ゼロ）ではない REOPEN属性で、0（ゼロ）ではない MAX_FAILUREの件数を超過している。

ALTERNATE属性は、MANDATORY属性よりも優先されます。これは、現在の宛先が必須であっても、有効な代替アーカイブ先に宛先をフェイルオーバーすることを意味します。

5.5.3 再試行回数の制御再試行回数の制御再試行回数の制御再試行回数の制御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'

関連項目関連項目関連項目関連項目 : 14-4 ページ「ALTERNATE」


データ保護モードの設定

5.6 データ保護モードの設定データ保護モードの設定データ保護モードの設定データ保護モードの設定Data Guard には、大保護、大可用性および大パフォーマンスという 3 つのデータ保護モードが用意されています。選択したデータ保護レベルにより、プライマリ・データベースからスタンバイ・データベースへの接続が失われた場合の動作が制御されます。この項は、次の項目で構成されています。

� データ保護モードの選択

� Data Guard 構成のデータ保護モードの設定

5.6.1 データ保護モードの選択データ保護モードの選択データ保護モードの選択データ保護モードの選択適切なデータ保護モードを判断するには、次のデータ保護モードの説明を参考にして、データ可用性に対するビジネス要件を応答時間とパフォーマンスに対するユーザーのニーズに基づいて査定します。また、データ保護モードの設定方法については、5.6.2 項を参照してください。

5.6.1.1 大保護モード大保護モード大保護モード大保護モードこの保護モードは、プライマリ・データベースに障害が発生した場合にも、データ消失がないことを保証します。このレベルの保護を提供するには、トランザクションがコミットされる前に、各トランザクションをリカバリするために必要な REDO データを、少なくとも 1 つのスタンバイ・データベース上のローカル・オンライン REDO ログおよびスタンバイ REDO ログに書き込む必要があります。障害によって少なくとも 1 つのリモート・スタンバイ REDO ログにREDO ストリームを書込みできない場合、データ消失が発生しないようにプライマリ・データベースが停止します。複数インスタンス RAC データベースでは、Data Guard は正しく構成された少なくとも 1 つのデータベース・インスタンスに REDO レコードを書き込めない場合に、プライマリ・データベースを停止します。大保護モードでは、少なくとも 1 つのスタンバイ・インスタンスにスタンバイ REDO ログがあり、この宛先について LOG_ARCHIVE_DEST_nパラメータに LGWR、SYNCおよび AFFIRM属性が使用されている必要があります。

5.6.1.2 大可用性モード大可用性モード大可用性モード大可用性モードこの保護モードは、プライマリ・データベースの可用性を低下させない範囲で可能な高レベルのデータ保護を提供します。大保護モードと同様に、トランザクションは、そのトランザクションのリカバリに必要な REDO が、ローカルのオンライン REDO ログおよび少なくとも 1つのリモート・スタンバイ REDO ログに書き込まれるまでコミットされません。障害によってリモート・スタンバイ REDO ログに REDO ストリームを書込みできない場合、大保護モードとは異なり、プライマリ・データベースは停止しません。かわりに、障害が解決され、REDO ログ・ファイルのすべてのギャップが解決されるまで、プライマリ・データベースは大パフォーマンス・モードで動作します。すべてのギャップが解決されると、プライマリ・データベースは、大可用性モードでの動作を自動的に再開します。

このモードでは、プライマリ・データベースに障害が発生した場合、ただし、2 回目の障害でプライマリ・データベースから少なくとも 1 つのスタンバイ・データベースに REDO データの完全なセットが送信される場合にのみ、データが消失しないことを保証します。

大保護モードと同様に、大可用性モードには次の要件があります。

� 1 つ以上のスタンバイ・データベースでスタンバイ REDO ログ・ファイルを構成します。

� 1 つ以上のスタンバイ・データベースについて、LOG_ARCHIVE_DEST_nパラメータのSYNC、LGWRおよび AFFIRM属性を設定します。

5.6.1.3 大パフォーマンス・モード大パフォーマンス・モード大パフォーマンス・モード大パフォーマンス・モードこの保護モード（デフォルト）は、プライマリ・データベースのパフォーマンスに影響しない範囲で可能な高レベルのデータ保護を提供します。これは、トランザクションのリカバリに必要な REDO データがローカルのオンライン REDO ログに書き込まれた直後に、そのトランザクションのコミットを許可することで実行されます。プライマリ・データベースの REDOデータ・ストリームは、少なくとも 1 つのスタンバイ・データベースにも書き込まれますが、その REDO ストリームは、REDO データを作成するトランザクションのコミットメントについて非同期で書き込まれます。



十分な帯域幅を持つネットワーク・リンクが使用される場合、このモードは、プライマリ・データベースのパフォーマンスに対する影響を小限にして、大可用性モードのレベルに近いデータ保護レベルを提供します。

大パフォーマンス・モードでは、スタンバイ・データベースの宛先について、LOG_ARCHIVE_DEST_nパラメータの LGWRおよび ASYNC属性を設定するか、または ARCH属性を設定できます。LGWRおよび ASYNC属性を設定すると、プライマリ・データベースに障害が発生した場合に、スタンバイ宛先で受信されないデータの量を減少させることができます。

5.6.2 Data Guard 構成のデータ保護モードの設定構成のデータ保護モードの設定構成のデータ保護モードの設定構成のデータ保護モードの設定REDO 転送サービスを設定して Data Guard 構成のデータ保護レベルを指定する手順は、次のとおりです。

手順手順手順手順 1 プライマリ・データベースでプライマリ・データベースでプライマリ・データベースでプライマリ・データベースで LOG_ARCHIVE_DEST_n パラメータを構成するパラメータを構成するパラメータを構成するパラメータを構成する

プライマリ・データベースで、LOG_ARCHIVE_DEST_nパラメータの属性を適切に構成します。 Data Guard の各データ保護モードでは、構成内の少なくとも 1 つのスタンバイ・データベースが表 5-2 に記載された一連の低要件を満たしている必要があります。

次の例に、大可用性モードの構成方法を示します。

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 構成にスタンバイ・データベースを動的に追加できます。

表表表表 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 データを受信できない場合でも、プライマリ・データベースは処理を継続できます。



手順手順手順手順 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.7 ログ・ファイルの管理ログ・ファイルの管理ログ・ファイルの管理ログ・ファイルの管理この項は、次の項目で構成されています。

� アーカイブ REDO ログ・ファイルの代替ディレクトリ位置の指定

� オンライン REDO ログ・ファイルの再利用

� スタンバイ REDO ログ・ファイルの管理

� 制御ファイルのサイズ拡大と再利用の計画

� 複数のスタンバイ・データベース間でのログ・ファイル宛先の共有

5.7.1 アーカイブアーカイブアーカイブアーカイブ 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 転送サービスはスタンバイ・データベースの制御ファイルに完全修飾名を格納し、REDO Apply はこの情報を使用してスタンバイ・データベースでリカバリを実行します。

スタンバイ・システム上のアーカイブ 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

5.7.2 オンラインオンラインオンラインオンライン 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'

注意注意注意注意 : LOG_ARCHIVE_DEST_nパラメータの TEMPLATE属性を指定すると、STANDBY_ARCHIVE_DESTおよび LOG_ARCHIVE_FORMATパラメータで生成されるファイル名は無視されます。TEMPLATE 属性の詳細は、第 14 章を参照してください。



5.7.3 スタンバイスタンバイスタンバイスタンバイ REDO ログ・ファイルの管理ログ・ファイルの管理ログ・ファイルの管理ログ・ファイルの管理この項は、次の項目で構成されています。

� スタンバイ REDO ログ・ファイル・グループの構成が適切であるかの判断

� スタンバイ REDO ログ・メンバーを既存のグループに追加

5.7.3.1 スタンバイスタンバイスタンバイスタンバイ REDO ログ・ファイル・グループの構成が適切であるかログ・ファイル・グループの構成が適切であるかログ・ファイル・グループの構成が適切であるかログ・ファイル・グループの構成が適切であるかの判断の判断の判断の判断スタンバイ REDO ログのログ・ファイル・グループ数が適切かどうかを確認するも容易な方法は、RFS プロセスのトレース・ファイルとデータベースのアラート・ログを検討することです。アーカイブが完了しないために RFS プロセスが頻繁にグループを待つ必要があることを示すメッセージがいずれかのログに含まれている場合は、スタンバイ REDO ログにログ・ファイル・グループを追加します。スタンバイ REDO ログ・ファイル・グループを追加することにより、スタンバイ REDO ログ・ファイルが RFS プロセスで再利用される前に、アーカイブ操作を完了する時間が確保されます。

5.7.3.2 スタンバイスタンバイスタンバイスタンバイ 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 ログ・ファイル・グループをプライマリ・データベースに追加した場合は、対応するスタンバイ REDO ログ・ファイル・グループをスタンバイ・データベースに追加する必要があります。スタンバイ REDO ログ・ファイル・グループの数が不十分な場合、プライマリ・データベースが大保護モードで作動しているときは停止し、大可用性モードで作動しているときは大パフォーマンス・モードに切り替わります。



5.7.4 制御ファイルのサイズ拡大と再利用の計画制御ファイルのサイズ拡大と再利用の計画制御ファイルのサイズ拡大と再利用の計画制御ファイルのサイズ拡大と再利用の計画この項は、次の項目で構成されています。

� 制御ファイルを含むディスク・ボリュームのサイズ設定

� 制御ファイル内のレコードの再利用の指定

5.7.4.1 制御ファイルを含むディスク・ボリュームのサイズ設定制御ファイルを含むディスク・ボリュームのサイズ設定制御ファイルを含むディスク・ボリュームのサイズ設定制御ファイルを含むディスク・ボリュームのサイズ設定アーカイブ REDO ログ・ファイルが生成され、Recovery Manager のバックアップが作成されると、制御ファイルの再利用可能セクションに新規レコードが追加されます。再利用可能なレコードがない場合（すべてのレコードが CONTROL_FILE_RECORD_KEEP_TIMEで指定された日数の範囲内にあるためなど）、制御ファイルが拡張され、新規レコードが追加されます。

制御ファイルの大サイズは 20000 データベース・ブロックです。DB_BLOCK_SIZEが 8192 の場合、制御ファイルの大サイズは 156 MB です。制御ファイルが事前作成済ボリュームに格納される場合は、プライマリおよびスタンバイ制御ファイルを含むボリュームのサイズを大サイズの制御ファイルが収まるように設定する必要があります。制御ファイルのボリュームが小さすぎ、拡張できない場合は、意図した再利用の前に制御ファイル内の既存のレコードが上書きされます。この動作は、アラート・ログの次のメッセージで示されます。

krcpwnc: following controlfile record written over:

5.7.4.2 制御ファイル内のレコードの再利用の指定制御ファイル内のレコードの再利用の指定制御ファイル内のレコードの再利用の指定制御ファイル内のレコードの再利用の指定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.7.5 複数のスタンバイ・データベース間でのログ・ファイル宛先の共有複数のスタンバイ・データベース間でのログ・ファイル宛先の共有複数のスタンバイ・データベース間でのログ・ファイル宛先の共有複数のスタンバイ・データベース間でのログ・ファイル宛先の共有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 データを stdby2ではなく stdby1に転送します。かわりに、stdby2データベースは stdby1に送信されたアーカイブ REDO ログ・ファイルから REDO をリカバリします。

5.8 アーカイブ・ギャップの管理アーカイブ・ギャップの管理アーカイブ・ギャップの管理アーカイブ・ギャップの管理アーカイブ・ギャップアーカイブ・ギャップアーカイブ・ギャップアーカイブ・ギャップは、スタンバイ・システムがプライマリ・データベースによって生成された 1 つ以上のアーカイブ REDO ログ・ファイルを受信していないときに、スタンバイ・システムで発生する可能性があります。欠落しているアーカイブ REDO ログ・ファイルがギャップです。ギャップがある場合、そのギャップは Data Guard によって自動的に検出され、欠落しているログ・ファイルの順序番号をスタンバイ宛先にコピーすることで解決されます。たとえば、アーカイブ・ギャップは、ネットワークが使用不可能になり、プライマリ・データベースからスタンバイ・データベースへの自動アーカイブが一時的に停止すると発生する可能性があります。ネットワークが再度使用可能になると、プライマリ・データベースからスタンバイ・データベースへの REDO データの自動転送が再開します。

Data Guard の場合、このようなギャップの検出と解決に、DBA による手動操作は必要ありません。次の各項では、ギャップの検出と解決について説明します。

5.8.1 アーカイブ・ギャップの検出時期アーカイブ・ギャップの検出時期アーカイブ・ギャップの検出時期アーカイブ・ギャップの検出時期アーカイブ・ギャップは、プライマリ・データベースがローカルにアーカイブしたログが、スタンバイ・サイトでは受信されなかった場合に発生する可能性があります。プライマリ・データベースは、1 分ごとにスタンバイ・データベースをポーリングして、アーカイブ REDO ログ・ファイルの順序番号にギャップがあるかどうかを確認します。

5.8.2 ギャップの解決方法ギャップの解決方法ギャップの解決方法ギャップの解決方法ギャップ・リカバリは、ポーリング・メカニズムを使用して処理されます。フィジカルおよびロジカル・スタンバイ・データベース、Oracle Change Data Capture および Oracle Streams の場合、Data Guard はギャップ検出を実行し、欠落しているアーカイブ REDO ログ・ファイルをプライマリ・データベースから自動的に取得することで解決します。スタンバイ・データベースのポーリング、ギャップの検出または解決のために、余分な構成設定を行う必要はありません。

ここで重要なことは、自動ギャップ・リカバリの実行には、プライマリ・データベースの可用性が不可欠であることです。プライマリ・データベースが使用不可能な場合、構成に複数のフィジカル・スタンバイ・データベースが含まれていれば、REDO Apply によって別のスタンバイ・データベースからアーカイブ・ギャップを解決できるように初期化パラメータを追加設定できます。詳細は、5.8.3 項を参照してください。

ギャップを手動で解決する方法を示す使用例については、12.11 項を参照してください。

関連項目関連項目関連項目関連項目 : 14-10 ページ「DEPENDENCY」

注意注意注意注意 : Oracle Database 10g リリース 1（10.1）までは、プライマリ・データベースからのギャップを解決するために FAL クライアントおよびサーバーが使用されていました。



5.8.3 フェッチ・アーカイブ・ログ（フェッチ・アーカイブ・ログ（フェッチ・アーカイブ・ログ（フェッチ・アーカイブ・ログ（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 サーバーへの接続に使

用するネットワーク・サービス名を指定します。リストには複数の値を指定できます。

構文構文構文構文

FAL_SERVER=net_service_name

例例例例

FAL_SERVER=standby2_db,standby3_db

FAL_CLIENT FAL サーバーがスタンバイ・

データベースへの接続に使用するネットワーク・サービス名を指定します。

構文構文構文構文

FAL_CLIENT=net_service_name

例例例例

FAL_CLIENT=standby1_db



5.8.4 手動によるアーカイブ・ギャップの判断および解決手動によるアーカイブ・ギャップの判断および解決手動によるアーカイブ・ギャップの判断および解決手動によるアーカイブ・ギャップの判断および解決自動ギャップ・リカバリを実行できず、ギャップ・リカバリを手動で実行する必要がある場合があります。たとえば、ロジカル・スタンバイ・データベースの使用中にプライマリ・データベースが使用不可能になった場合は、ギャップ・リカバリを手動で実行する必要があります。

次の各項では、適切なビューを問い合せて欠落しているログ・ファイルを判断し、手動によるリカバリを実行する方法を説明します。

フィジカル・スタンバイ・データベースの場合フィジカル・スタンバイ・データベースの場合フィジカル・スタンバイ・データベースの場合フィジカル・スタンバイ・データベースの場合

フィジカル・スタンバイ・データベースにアーカイブ・ギャップが存在するかどうかを判断するには、次の例に示すように、V$ARCHIVE_GAPビューを問い合せます。

SQL> SELECT * FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#----------- ------------- -------------- 1 7 10

この出力例は、現在フィジカル・スタンバイ・データベースでスレッド 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固定ビューをフィジカル・スタンバイ・データベースで再度問い合せて、次のギャップ・シーケンス（存在する場合）を判断します。この処理をギャップがなくなるまで繰り返します。



ロジカル・スタンバイ・データベースの場合ロジカル・スタンバイ・データベースの場合ロジカル・スタンバイ・データベースの場合ロジカル・スタンバイ・データベースの場合

アーカイブ・ギャップが存在するかどうかを判断するには、ロジカル・スタンバイ・データベースで DBA_LOGSTDBY_LOGビューを問い合せます。たとえば、次の問合せでは、ロジカル・スタンバイ・データベースの THREAD 1 に、2 つのファイルが表示されているため、アーカイブ REDO ログ・ファイルの順序番号にギャップがあることを示しています（ギャップがない場合、問合せで表示されるのは、スレッドごとに 1 つのファイルのみです）。この出力は、登録されたファイルの大の順序番号は 10 ですが、順序番号 6 で示されるファイルにギャップがあることを示しています。

SQL> COLUMN FILE_NAME FORMAT a55SQL> 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---------- ---------- ----------------------------------------------- 1 6 /disk1/oracle/dbs/log-1292880008_6.arc 1 10 /disk1/oracle/dbs/log-1292880008_10.arc

順序番号 7、8 および 9 の欠落しているログ・ファイルをロジカル・スタンバイ・システムにコピーし、コピーしたログを ALTER DATABASE REGISTER LOGICAL LOGFILE文を使用してロジカル・スタンバイ・データベースに登録します。


SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/disk1/oracle/dbs/log-1292880008_10.arc';

ログ・ファイルをロジカル・スタンバイ・データベースに登録した後は、SQL Apply を再開できます。

注意注意注意注意 : ロジカル・スタンバイ・データベースの DBA_LOGSTDBY_LOGビューが戻すのは、SQL Apply の続行をブロックしている次のギャップのみです。識別したギャップを解決して SQL Apply を開始した後、DBA_LOGSTDBY_LOGビューをロジカル・スタンバイ・データベースで再度問い合せて、次のギャップ・シーケンス（存在する場合）を判断します。この処理をギャップがなくなるまで繰り返します。


確認

5.9 確認確認確認確認この項は、次の項目で構成されています。

� ログ・ファイル・アーカイブ情報の監視

� REDO 転送サービスのパフォーマンスの監視

5.9.1 ログ・ファイル・アーカイブ情報の監視ログ・ファイル・アーカイブ情報の監視ログ・ファイル・アーカイブ情報の監視ログ・ファイル・アーカイブ情報の監視この項では、ビューを使用してプライマリ・データベースの 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 1 947standby1 VALID 1 947

後に書き込まれたアーカイブ 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#);


確認

THREAD# SEQUENCE#--------- --------- 1 12 1 13 1 14

プライマリ・データベースのアーカイブ・ステータス監視の詳細は、付録 A を参照してください。

手順手順手順手順 5 スタンバイ・サイトで転送されたスタンバイ・サイトで転送されたスタンバイ・サイトで転送されたスタンバイ・サイトで転送された REDO の進行状況をトレースするの進行状況をトレースするの進行状況をトレースするの進行状況をトレースする

スタンバイ宛先への REDO データの転送の進行状況を確認するには、プライマリおよびスタンバイ初期化パラメータ・ファイルに LOG_ARCHIVE_TRACEパラメータを設定します。詳細と例は、付録 G を参照してください。

5.9.2 REDO 転送サービスのパフォーマンスの監視転送サービスのパフォーマンスの監視転送サービスのパフォーマンスの監視転送サービスのパフォーマンスの監視この項では、REDO 転送サービスのパフォーマンスを監視する待機イベントについて説明します。これらのログ転送サービスは、プライマリ・データベースで、LOG_ARCHIVE_DEST_n初期化パラメータの ARCH、LGWR、SYNCおよび ASYNC属性を使用して指定されます。

次の各項では、V$SYSTEM_EVENTビューで表示される待機イベントおよび関連する時間情報について説明します。

� ARCn プロセスの待機イベント

� LGWR SYNC 待機イベント

� LGWR ASYNC 待機イベント

5.9.2.1 ARCn プロセスの待機イベントプロセスの待機イベントプロセスの待機イベントプロセスの待機イベント表 5-3 に、ARCn アーカイブ・プロセスについて、転送モードで ARCH を使用している場合の複数の待機イベントを示しています。各待機イベントは、RFS 接続の起動または削除の所要時間、およびスタンバイ・データベースに対する REDO データの送信所要時間を監視します。ARCn アーカイブ・プロセスについては、5.3.1 項を参照してください。

表表表表 5-3 ARCH 属性で構成される宛先の待機イベント属性で構成される宛先の待機イベント属性で構成される宛先の待機イベント属性で構成される宛先の待機イベント

待機イベント待機イベント待機イベント待機イベント待機時間の監視対象待機時間の監視対象待機時間の監視対象待機時間の監視対象

ARCH wait on ATTACH すべての ARCn プロセスによる RFS 接続の生成。

ARCH wait on SENDREQ すべての ARCn プロセスによる、受信した REDO データのディスク

への書込み、およびリモートのアーカイブ REDO ログ・ファイルの

オープンおよびクローズ。

ARCH wait on DETACH すべての ARCn プロセスによる RFS 接続の削除。


確認

5.9.2.2 LGWR SYNC 待機イベント待機イベント待機イベント待機イベント表 5-4 に、LGWR SYNCアーカイブ・プロセスについて、プライマリ・データベースの LGWR プロセスによる次の操作の実行所要時間を監視する複数の待機イベントを示します。

� プライマリ・データベースのオンライン REDO ログ・ファイルへの書込み完了

� リモート・スタンバイ宛先への REDO データの転送

� スタンバイ REDO ログ・ファイルへの REDO データ書込みの待機

� リモート・スタンバイ宛先からの応答の受信

LGWR SYNCアーカイブ・プロセスについては、5.3.2 項を参照してください。

5.9.2.3 LGWR ASYNC 待機イベント待機イベント待機イベント待機イベント表 5-5 に、LGWR ASYNCアーカイブ・プロセスについて、プライマリ・データベースのオンライン REDO ログ・ファイルに REDO データを書き込む所要時間を監視する複数の待機イベントを示します。LGWR ASYNCアーカイブ・プロセスについては、5.3.2 項を参照してください。

表表表表 5-4 LGWR SYNC 属性で構成される宛先の待機イベント属性で構成される宛先の待機イベント属性で構成される宛先の待機イベント属性で構成される宛先の待機イベント


LGWR wait on LNS LNSn プロセスからメッセージを受信するまでの LGWR プロセスの

待機。

LNS wait on ATTACH すべてのネットワーク・サーバーによる RFS 接続の生成。

LNS wait on SENDREQ すべてのネットワーク・サーバーによる、受信した REDO データの

ディスクへの書込み、およびリモートのアーカイブ REDO ログ・

ファイルのオープンおよびクローズ。

LNS wait on DETACH すべてのネットワーク・サーバーによる RFS 接続の削除。

表表表表 5-5 LGWR ASYNC 属性で構成される宛先の待機イベント属性で構成される宛先の待機イベント属性で構成される宛先の待機イベント属性で構成される宛先の待機イベント


LNS wait on DETACH すべてのネットワーク・サーバーによる RFS 接続の削除。

LNS wait on ATTACH すべてのネットワーク・サーバーによる RFS 接続の生成。

LNS wait on SENDREQ すべてのネットワーク・サーバーによる、受信した REDO データの

ディスクへの書込み、およびリモートのアーカイブ REDO ログ・

ファイルのオープンおよびクローズ。

True ASYNC Control FileTXN Wait

LNSn プロセスによるライフタイム中の制御ファイル・トランザク

ションの保留。

True ASYNC Wait for ARCH log

アーカイブ REDO ログを参照するまでの LNSn プロセスの待機

（LNSn プロセスが現行のログ・ファイルをアーカイブ中でログ・ス

イッチが発生する場合）。

Waiting for ASYNC dest activation

アクティブでない宛先がアクティブになるまでの LNSn プロセスの

待機。

True ASYNC log-end-of-file wait

論理的なファイルの終わりに達した後で次の REDO ビットに達する

までの LNSn プロセスの待機。


ログ適用サー

6
ログ適用サービスログ適用サービスログ適用サービスログ適用サービス
この章では、REDO データをスタンバイ・データベースに適用する方法について説明します。この章は、次の項目で構成されています。

� ログ適用サービスの概要

� ログ適用サービスの構成オプション

� REDO データのフィジカル・スタンバイ・データベースへの適用

� REDO データのロジカル・スタンバイ・データベースへの適用

ビス 6-1

ログ適用サービスの概要

6.1 ログ適用サービスの概要ログ適用サービスの概要ログ適用サービスの概要ログ適用サービスの概要ログ適用サービスログ適用サービスログ適用サービスログ適用サービスは、スタンバイ・データベースに REDO を自動的に適用して、プライマリ・データベースとの同期を維持します。また、データに対するトランザクションの一貫性のあるアクセスを可能にします。

デフォルトでは、ログ適用サービスは、いっぱいになったアーカイブ REDO ログ・ファイルがスタンバイ・データベースで受信されるのを待機してから、スタンバイ・データベースに適用します。5.3.1 項および 5.3.2 項では、プライマリ・データベースから転送された REDO データが、スタンバイ・システムのリモート・ファイル・サーバー・プロセス（RFS）でどのように受信されるかについて説明しました。スタンバイ・システムでは、RFS プロセスにより、アーカイブ REDO ログ・ファイルまたはスタンバイ REDO ログ・ファイル（オプション）にREDO データが書き込まれます。ただし、スタンバイ REDO ログ・ファイルを使用している場合は、オプションでリアルタイム適用リアルタイム適用リアルタイム適用リアルタイム適用を使用可能にできます。リアルタイム適用により、Data Guard では、現在のスタンバイ REDO ログ・ファイルが RFS プロセスによっていっぱいになったときに、現在のスタンバイ REDO ログ・ファイルから REDO データをリカバリできます。リアルタイム適用については、6.2.1 項を参照してください。

ログ適用サービスは、次の方法でフィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースをメンテナンスします。

� REDO Apply（フィジカル・スタンバイ・データベースのみ）

メディア・リカバリを使用して、プライマリ・データベースとフィジカル・スタンバイ・データベースの同期を維持します。

� SQL Apply（ロジカル・スタンバイ・データベースのみ）

プライマリ・データベースから受信した REDO に基づいて SQL 文を再構成し、その SQL文をロジカル・スタンバイ・データベースに対して実行します。

ロジカル・スタンバイ・データベースは読取り / 書込みモードでオープンできますが、レポート生成のためにロジカル・スタンバイ・データベースでメンテナンスされているターゲット表は読取り専用モードでオープンします（データベース・ガードが適切に設定されている場合）。SQL Apply を使用すると、SQL 文が適用されている間でも、ロジカル・スタンバイ・データベースをレポート・アクティビティで使用できます。

この章の各項では、REDO Apply、SQL Apply、リアルタイム適用および適用の遅延について詳細に説明します。

注意注意注意注意 : ユーザーがレポート生成のためにスタンバイ・データベースを問合せできるように、フィジカル・スタンバイ・データベースを読取り専用モードでオープンすることもできます。オープン中も REDO データは受信されます。ただし、REDO Apply は停止し、フィジカル・スタンバイ・データベースでは、プライマリ・データベースとのトランザクションの同期が維持されません。このときに障害が発生すると、フェイルオーバー操作が完了するまでに時間がかかる場合があります。詳細は、8.2 項「スタンバイ・データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法」を参照してください。


ログ適用サービスの構成オプション

6.2 ログ適用サービスの構成オプションログ適用サービスの構成オプションログ適用サービスの構成オプションログ適用サービスの構成オプションこの項は、次の項目で構成されています。

� リアルタイム適用による REDO データの即時適用

� アーカイブ REDO ログ・ファイルの適用に対するタイム・ディレイの指定

6.2.1 リアルタイム適用によるリアルタイム適用によるリアルタイム適用によるリアルタイム適用による 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

ログ適用サービスの構成オプション

6.2.2 アーカイブアーカイブアーカイブアーカイブ 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 パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

6.2.2.1 タイム・ディレイ設定の代替策としてのフラッシュバック・データタイム・ディレイ設定の代替策としてのフラッシュバック・データタイム・ディレイ設定の代替策としてのフラッシュバック・データタイム・ディレイ設定の代替策としてのフラッシュバック・データベースの使用ベースの使用ベースの使用ベースの使用適用遅延を設定するかわりにフラッシュバック・データベースを使用して、スタンバイ・データベースへの破損データやエラー・データの適用からリカバリできます。フラッシュバック・データベースを使用すると、スタンバイ・データベースを任意の時点まで、すばやく容易にフラッシュ・バックできます。

Data Guard とフラッシュバック・データベースの併用方法の使用例は第 12 章を、フラッシュバック・データベースを有効にして使用する方法の詳細は『Oracle Database バックアップおよびリカバリ基礎』を参照してください。

注意注意注意注意 : リアルタイム適用が使用可能になっている宛先に遅延を定義すると、その遅延は無視されます。


REDO データのフィジカル・スタンバイ・データベースへの適用

6.3 REDO データのフィジカル・スタンバイ・データベースへのデータのフィジカル・スタンバイ・データベースへのデータのフィジカル・スタンバイ・データベースへのデータのフィジカル・スタンバイ・データベースへの適用適用適用適用

デフォルトでは、アーカイブ REDO ログ・ファイルからの REDO データが適用されます。 REDO Apply を実行している場合、フィジカル・スタンバイ・データベースはリアルタイム機能を使用して、スタンバイ REDO ログ・ファイルが RFS プロセスによって書き込まれているときに、スタンバイ REDO ログ・ファイルから直接 REDO を適用できます。ログ適用サービスは、フィジカル・スタンバイ・データベースが読取り専用でオープンしているときは、REDOデータをデータベースに適用できないことに注意してください。


� REDO Apply の開始

� リアルタイム適用の開始

� ログ適用サービスの停止

� フィジカル・スタンバイ・データベースでのログ適用サービスの監視

6.3.1 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 セッションが切断されることはありません。

6.3.2 リアルタイム適用の開始リアルタイム適用の開始リアルタイム適用の開始リアルタイム適用の開始リアルタイム適用を開始するには、SQL 文に USING CURRENT LOGFILE句を含めます。次に例を示します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;


REDO データのロジカル・スタンバイ・データベースへの適用

6.3.3 ログ適用サービスの停止ログ適用サービスの停止ログ適用サービスの停止ログ適用サービスの停止REDO Apply またはリアルタイム適用を停止するには、別のウィンドウで次の SQL 文を発行します。


6.3.4 フィジカル・スタンバイ・データベースでのログ適用サービスの監視フィジカル・スタンバイ・データベースでのログ適用サービスの監視フィジカル・スタンバイ・データベースでのログ適用サービスの監視フィジカル・スタンバイ・データベースでのログ適用サービスの監視フィジカル・スタンバイ・データベースでのログ適用サービスのステータスを監視するには、8.5.4 項を参照してください。スタンバイ・データベースは、Oracle Enterprise Manager を使用して監視することもできます。また、ビューの詳細は『Oracle Database リファレンス』を参照してください。

6.4 REDO データのロジカル・スタンバイ・データベースへの適用データのロジカル・スタンバイ・データベースへの適用データのロジカル・スタンバイ・データベースへの適用データのロジカル・スタンバイ・データベースへの適用ログ適用サービスは、アーカイブ REDO ログまたはスタンバイ REDO ログのデータを SQL 文に変換してから、その SQL 文をロジカル・スタンバイ・データベースで実行します。ロジカル・スタンバイ・データベースはオープン状態のままであるため、メンテナンスされる表は、レポート生成、要約、問合せなどの他のタスクで同時に使用できます。


� SQL Apply の開始

� リアルタイム適用の開始

� ロジカル・スタンバイ・データベースでのログ適用サービスの停止

� ロジカル・スタンバイ・データベースでのログ適用サービスの監視

6.4.1 SQL Apply の開始の開始の開始の開始SQL Apply を開始するには、ロジカル・スタンバイ・データベースを起動し、次の文を発行して、ロジカル・スタンバイ・データベースのアーカイブ REDO ログ・ファイルから REDOデータをリカバリします。


6.4.2 リアルタイム適用の開始リアルタイム適用の開始リアルタイム適用の開始リアルタイム適用の開始ロジカル・スタンバイ・データベースでリアルタイム適用を開始して、ロジカル・スタンバイ・データベースのスタンバイ REDO ログ・ファイルから REDO データを即時にリカバリするには、次の文に示すように、IMMEDIATEキーワードを含めます。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

6.4.3 ロジカル・スタンバイ・データベースでのログ適用サービスの停止ロジカル・スタンバイ・データベースでのログ適用サービスの停止ロジカル・スタンバイ・データベースでのログ適用サービスの停止ロジカル・スタンバイ・データベースでのログ適用サービスの停止SQL Apply を停止するには、ロジカル・スタンバイ・データベースで次の文を発行します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

この文を発行すると、SQL Apply は適用対象プロセス内の完了トランザクションがすべてコミットされるまで待機します。つまり、このコマンドを実行しても、SQL Apply プロセスが即時に停止しない場合があります。

SQL Apply を即時に停止する場合は、次の文を発行します。

SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY;



6.4.4 ロジカル・スタンバイ・データベースでのログ適用サービスの監視ロジカル・スタンバイ・データベースでのログ適用サービスの監視ロジカル・スタンバイ・データベースでのログ適用サービスの監視ロジカル・スタンバイ・データベースでのログ適用サービスの監視SQL Apply を監視するには、9.2 項を参照してください。スタンバイ・データベースは、Oracle Enterprise Manager を使用して監視することもできます。付録 A「Data Guard のトラブルシューティング」および『Oracle Data Guard Broker』を参照してください。

また、ビューの詳細は、8.5.4.3 項の V$ARCHIVE_DEST_STATUS固定ビューの説明、および『Oracle Database リファレンス』を参照してください。




ロールの

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

ロールの推移の概要

7.1 ロールの推移の概要ロールの推移の概要ロールの推移の概要ロールの推移の概要データベースは、相互に排他的な次の 2 つのロールのいずれかで実行されます。2 つのロールとは、プライマリプライマリプライマリプライマリとスタンバイスタンバイスタンバイスタンバイです。Data Guard では、この章で説明する SQL 文を発行するか、Data Guard Broker の GUI またはコマンドライン・インタフェースを使用して、これらのロールを動的に変更できます。 Oracle Data Guard は、次のロールの推移をサポートしています。

� スイッチオーバースイッチオーバースイッチオーバースイッチオーバー

プライマリ・データベースが、スタンバイ・データベースの 1 つを使用してロールを切り替えられるようにします。スイッチオーバー時には、データは消失しません。スイッチオーバーの完了後、各データベースは、新しいロールとともに Data Guard 構成に継続して含まれます。

� フェイルオーバーフェイルオーバーフェイルオーバーフェイルオーバー

プライマリ・データベースの障害時に、スタンバイ・データベースをプライマリ・ロールに変更します。障害の前にプライマリ・データベースが大保護モードまたは大可用性モードで動作していなかった場合、データ消失が発生することがあります。フラッシュバック・データベースが使用可能になっている場合は、障害の原因が修正された後、障害が発生したデータベースを元どおり新規プライマリ・データベースのスタンバイに戻すことができます。

7-2 ページ 7.1.1 項「ロールの推移（フェイルオーバーまたはスイッチオーバー）の準備」では、停止時間およびデータ消失のリスクを小限にするために、どのロールの推移を選択するかについて説明します。7-4 ページ 7.1.3 項「スイッチオーバー」および 7-6 ページ 7.1.4 項「フェイルオーバー」では、それぞれスイッチオーバーとフェイルオーバーの詳細を説明します。

7.1.1 ロールの推移（フェイルオーバーまたはスイッチオーバー）の準備ロールの推移（フェイルオーバーまたはスイッチオーバー）の準備ロールの推移（フェイルオーバーまたはスイッチオーバー）の準備ロールの推移（フェイルオーバーまたはスイッチオーバー）の準備ロールの推移を開始する前に、次の準備を実行します。

� 各データベースの初期化パラメータが正しく構成されていることを確認してください。ロールの推移後に Data Guard 構成が正しく動作するように、プライマリおよびスタンバイ・データベースで初期化パラメータを構成する方法については、第 3 章「フィジカル・スタンバイ・データベースの作成」および第 4 章「ロジカル・スタンバイ・データベースの作成」を参照してください。

フィジカル・スタンバイ・データベースを作成するときに手動で REDO ログ・ファイルを追加する方法については、3-3 ページの 3.1.3 項「スタンバイ REDO ログの構成」を参照してください。

� 新たにプライマリ・データベースになるスタンバイ・データベースが ARCHIVELOG モードで動作していることを確認します。

� スタンバイ・データベースに存在する一時ファイルが、プライマリ・データベースの一時ファイルと一致することを確認します。

� 新たにプライマリ・データベースになるスタンバイ・データベースで現在有効になっている REDO の適用遅延を解除します。

� Real Application Clusters 構成で、1 つのスタンバイ・インスタンスを除いて、構成内のすべてのインスタンスが停止していることを確認します。

注意注意注意注意 : スイッチオーバーまたはフェイルオーバーの発生時に、すべてのスタンバイ・サイトが新規プライマリ・データベースから引き続き REDO データを受信するように、各スタンバイ・データベース上で LOG_ARCHIVE_DEST_nおよび LOG_ARCHIVE_DEST_STATE_nパラメータを定義する必要があります。LOG_ARCHIVE_DEST_n VALID_FOR属性を使用して、将来のロールの推移に備えてロールベースの宛先を定義する方法については、5-16 ページ5.4.1 項「VALID_FOR 属性を使用したロール・ベースの宛先の指定」および第 14 章「LOG_ARCHIVE_DEST_n パラメータの属性」を参照してください。



Real Application Clusters データベースの場合、ロールの推移中は 1 つのスタンバイ・インスタンスのみをオンラインにできます。ロールの推移を開始する前に、他のすべてのインスタンスを停止しておいてください。ロールの推移の完了後、これらのインスタンスをオンラインに戻します。

7.1.2 ロールの推移のターゲット・スタンバイ・データベースの選択ロールの推移のターゲット・スタンバイ・データベースの選択ロールの推移のターゲット・スタンバイ・データベースの選択ロールの推移のターゲット・スタンバイ・データベースの選択ロールの推移のターゲット・スタンバイ・データベースを選択する際には、多数の要因を考慮する必要があります。次のような要因があります。

� スタンバイ・データベースのローカリティ。

� スタンバイ・データベースの機能（CPU 数、使用可能な I/O 帯域幅などのハードウェア仕様）。

� ロールの推移の実行所要時間。これは、スタンバイ・データベースが REDO データの適用に関してどの程度遅れているか、およびアプリケーションの可用性とデータ消失をどの程度柔軟にトレードオフできるかに影響を受けます。

Data Guard には V$DATAGUARD_STATSビューが用意されています。このビューを使用して、データの新性に関する各スタンバイ・データベースの実行可能性と、使用可能な REDO データがすべてスタンバイ・データベースに適用された場合の、ロールの推移の実行所要時間を見積もることができます。次に例を示します。

SQL> COLUMN NAME FORMAT A18SQL> COLUMN VALUE FORMAT A16SQL> COLUMN UNIT FORMAT A10SQL> COLUMN TIME_COMPUTED FORMAT A24SQL> SELECT * FROM V$DATAGUARD_STATS;NAME VALUE UNIT TIME_COMPUTED------------------ ---------------- ---------- ------------------------apply finish time +00 00:00:02.4 day(2) to 15-MAY-2005 10:32:49 second(1) intervalapply lag +00 0:00:04 day(2) to 15-MAY-2005 10:32:49 second(0) intervaltransport lag +00 00:00:00 day(2) to 15-MAY-2005 10:32:49 second(0) interval

この例は、トランスポート・ラグがないこと、ログ適用サービスでは過去 4 秒間に生成されたREDO が適用されていないこと（apply lag）、およびログ適用サービスで未適用の REDO の適用が完了するまでに 2.4 秒かかること（apply finish time）を示しています。それぞれの統計の計算時刻は、TIME_COMPUTED列に示されています。

構成にフィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方が含まれている場合は、フィジカル・スタンバイ・データベースをターゲット・スタンバイ・データベースとして選択することを考慮してください。ロールの推移が完了すると、構成内のすべてのデータベースが新規プライマリ・データベースのスタンバイ・データベースとして実行可能になるため、フィジカル・スタンバイ・データベースにスイッチオーバーまたはフェイルオーバーする方が適切です。これに対して、ロジカル・スタンバイ・データベースにスイッチオーバーまたはフェイルオーバーすると、他方のフィジカル・スタンバイ・データベースは元のプライマリ・データベースに対して無効化されます。その場合は、新規プライマリ・データベースのバックアップからフィジカル・スタンバイ・データベースを再作成した後に、再び有効化する必要があります。

注意注意注意注意 : スイッチオーバー中にオープン状態のスタンバイ・インスタンスが1 つしかない場合も、他のすべてのスタンバイ・データベース・インスタンスはオープン時に自動的に新しいロールに正しく推移します。

ロールの推移 7-3


7.1.3 スイッチオーバースイッチオーバースイッチオーバースイッチオーバースイッチオーバーは、通常、オペレーティング・システムやハードウェアのアップグレード、または 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-3 は、スイッチオーバー実行後の Data Guard 環境を示します。元のスタンバイ・データベースは新しいプライマリ・データベースになります。現在、プライマリ・データベースはボストンにあり、スタンバイ・データベースはサンフランシスコにあります。

データベースがスイッチオーバー後に初めてオープンされると、DB_ROLE_CHANGEシステム・イベントが実行されます。このシステム・イベントに関連付けるトリガーを記述して、スイッチオーバーの発生後にタスクを管理できます。 V$DATABASEビューの DATABASE_ROLE列を問い合せると、現行のロールを判断できます。詳細は、『Oracle Database アプリケーション開発者ガイド - 基礎編』のシステム・マネージャ・イベントの表を参照してください。

図図図図 7-3 スイッチオーバー後のスイッチオーバー後のスイッチオーバー後のスイッチオーバー後の Data Guard 環境環境環境環境

スイッチオーバーの準備スイッチオーバーの準備スイッチオーバーの準備スイッチオーバーの準備

7.1.1 項に示した前提条件が満たされていることを確認します。また、スイッチオーバーの場合は、次の前提条件が満たされている必要があります。

� フィジカル・スタンバイ・データベースが関与するスイッチオーバーの場合は、プライマリ・データベース・インスタンスがオープンし、スタンバイ・データベース・インスタンスがマウントされていることを確認します。

スイッチオーバーの開始前に、プライマリ・ロールに変更するスタンバイ・データベースをマウントする必要があります。また、データベースのロールが切り替えられたとき、フィジカル・スタンバイ・データベースが 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.1.4 フェイルオーバーフェイルオーバーフェイルオーバーフェイルオーバー通常、フェイルオーバーは、プライマリ・データベースが使用不可能になり、適正な時間内にプライマリ・データベースをリストアしてサービスを再開できない場合にのみ使用します。フェイルオーバー時に実行するアクションは、フェイルオーバーに関与するスタンバイ・データベースがロジカルかフィジカルか、フェイルオーバー時の Data Guard 構成の状態、およびフェイルオーバーを開始するために使用する特定の SQL 文によって異なります。

図 7-4 に、サンフランシスコにあるプライマリ・データベースからボストンにあるフィジカル・スタンバイ・データベースへのフェイルオーバーの結果を示します。

図図図図 7-4 スタンバイ・データベースへのフェイルオーバースタンバイ・データベースへのフェイルオーバースタンバイ・データベースへのフェイルオーバースタンバイ・データベースへのフェイルオーバー

フェイルオーバーの準備フェイルオーバーの準備フェイルオーバーの準備フェイルオーバーの準備

可能な場合は、フェイルオーバーを実行する前に、使用可能な未適用のプライマリ・データベース REDO データを可能なかぎりスタンバイ・データベースに転送する必要があります。

7-2 ページの 7.1.1 項「ロールの推移（フェイルオーバーまたはスイッチオーバー）の準備」に示した前提条件が満たされていることを確認します。また、フェイルオーバーの場合は、次の前提条件が満たされている必要があります。

� 大保護モードで実行中のスタンバイ・データベースがフェイルオーバーに関与する場合は、スタンバイ・データベースで次の文を発行して、データベースを大パフォーマンス・モードにします。

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

適切なスタンバイ・データベースが使用できる場合は、フェイルオーバーが完了した後に、新しいプライマリ・データベースで希望の保護モードをリセットできます。

大保護モードに設定されているスタンバイ・データベースはフェイルオーバーできないため、この作業が必要になります。さらに、大保護モードのプライマリ・データベースがスタンバイ・データベースと通信中の場合は、スタンバイ・データベースを大保護モードから大パフォーマンス・モードに変更するために ALTER DATABASE文を発行しても失敗します。フェイルオーバーを実行すると元のプライマリ・データベースは Data Guard 構成から削除されるため、この機能によって、大保護モードで実行されているプライマリ・データベースを計画外のフェイルオーバーの影響から保護します。


フィジカル・スタンバイ・データベースが関与するロールの推移

フェイルオーバーに成功すると、DB_ROLE_CHANGEシステム・イベントが実行されます（フィジカル・スタンバイ・データベースへのフェイルオーバーの場合は、フェイルオーバー操作後に初めてデータベースがオープンされた時点でシステム・イベントが実行されます）。 V$DATABASEビューの DATABASE_ROLE列を問い合せると、現行のロールを判断できます。このシステム・イベントに関連付けるトリガーを記述して、フェイルオーバーの発生後にタスクを管理できます。詳細は、『Oracle Database アプリケーション開発者ガイド - 基礎編』のシステム・マネージャ・イベントの表を参照してください。

フィジカル・スタンバイ・データベースが関与するフェイルオーバーを実行するには、7-10ページの 7.2.2 項「フィジカル・スタンバイ・データベースが関与するフェイルオーバー」を参照してください。ロジカル・スタンバイ・データベースが関与するフェイルオーバーを実行するには、7-17 ページの 7.3.2 項「ロジカル・スタンバイ・データベースが関与するフェイルオーバー」を参照してください。

7.2 フィジカル・スタンバイ・データベースが関与するロールのフィジカル・スタンバイ・データベースが関与するロールのフィジカル・スタンバイ・データベースが関与するロールのフィジカル・スタンバイ・データベースが関与するロールの推移推移推移推移

この項では、フィジカル・スタンバイ・データベースが関与するスイッチオーバーおよびフェイルオーバーの実行方法を説明します。

7.2.1 フィジカル・スタンバイ・データベースが関与するスイッチオーバーフィジカル・スタンバイ・データベースが関与するスイッチオーバーフィジカル・スタンバイ・データベースが関与するスイッチオーバーフィジカル・スタンバイ・データベースが関与するスイッチオーバーこの項では、スイッチオーバーの実行方法について説明します。スイッチオーバーは、現行のプライマリ・データベースで開始し、ターゲット・スタンバイ・データベースで完了する必要があります。次に、スイッチオーバーを実行する手順を説明します。

手順手順手順手順 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句を追加することでスイッチオーバーを正常に実行できます。

注意注意注意注意 : スタンバイ・データベースが正しく更新されているかどうかをテストするために、スタンバイ・データベースにフェイルオーバーしないでください。かわりに、次のようにします。

� 3.2.7 項「フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認」を参照してください。

� 4.2.6 項「ロジカル・スタンバイ・データベースが正しく実行されているかどうかの確認」を参照してください。



V$DATABASEビューの SWITCHOVER_STATUS列に対するその他の有効な値については、『Oracle Database リファレンス』を参照してください。

手順手順手順手順 2 プライマリ・データベースでスイッチオーバーを開始するプライマリ・データベースでスイッチオーバーを開始するプライマリ・データベースでスイッチオーバーを開始するプライマリ・データベースでスイッチオーバーを開始する

現行のプライマリ・データベースをフィジカル・スタンバイ・データベース・ロールに変更するには、プライマリ・データベースで次の SQL 文を使用します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

この文が完了すると、プライマリ・データベース・ロールはスタンバイ・データベースに変換されます。現行の制御ファイルは、スイッチオーバーの前にカレント SQL セッション・トレース・ファイルにバックアップされます。これによって、必要に応じて現行の制御ファイルを再作成できるようになります。

手順手順手順手順 3 元のプライマリ・インスタンスを停止して再起動する元のプライマリ・インスタンスを停止して再起動する元のプライマリ・インスタンスを停止して再起動する元のプライマリ・インスタンスを停止して再起動する

元のプライマリ・インスタンスを停止し、データベースを再起動およびマウントします。


スイッチオーバー・プロセスのこの時点では、両方のデータベースがスタンバイ・データベースとして構成されています（図 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;



手順手順手順手順 6 スタンバイ・データベースからプライマリ・ロールへの推移を終了するスタンバイ・データベースからプライマリ・ロールへの推移を終了するスタンバイ・データベースからプライマリ・ロールへの推移を終了するスタンバイ・データベースからプライマリ・ロールへの推移を終了する

実行するタスクは、フィジカル・スタンバイ・データベースが読取り専用モードでオープンされたことがあるかどうかに応じて異なります。

� フィジカル・スタンバイ・データベースが前回の起動後に読取り専用モードでオープンされていない場合は、SQL ALTER DATABASE OPEN文を発行して新規プライマリ・データベースをオープンします。


その後、7-9 ページの手順 7 に進みます。

� フィジカル・スタンバイ・データベースが前回の起動後に読取り専用モードでオープンされている場合は、ターゲット・スタンバイ・データベースを停止して再起動する必要があります。

SQL> SHUTDOWN IMMEDIATE;SQL> STARTUP;

ターゲット・フィジカル・スタンバイ・データベースがプライマリ・データベース・ロールに推移します。 LOG_ARCHIVE_DEST_nの VALID_FOR属性を使用して Data Guard 構成をロールの推移後も確実に正常に動作させる方法については、5.4.1 項「VALID_FOR 属性を使用したロール・ベースの宛先の指定」および第 14 章「LOG_ARCHIVE_DEST_n パラメータの属性」を参照してください。

手順手順手順手順 7 必要に応じてスタンバイ・データベースでログ適用サービスを再開する必要に応じてスタンバイ・データベースでログ適用サービスを再開する必要に応じてスタンバイ・データベースでログ適用サービスを再開する必要に応じてスタンバイ・データベースでログ適用サービスを再開する

新しいフィジカル・スタンバイ・データベース、および Data Guard 構成内の他のフィジカルまたはロジカル・スタンバイ・データベースの場合、スイッチオーバー後も動作を継続するようにログ適用サービスが構成されていないときは、適切なコマンドを使用して、ログ適用サービスを再開します。ログ適用サービスを構成および開始する方法については、第 6 章「ログ適用サービス」を参照してください。

手順手順手順手順 8 スタンバイ・データベースへのスタンバイ・データベースへのスタンバイ・データベースへのスタンバイ・データベースへの REDO データの送信を開始するデータの送信を開始するデータの送信を開始するデータの送信を開始する

新しいプライマリ・データベースで次の文を発行します。


注意注意注意注意 : スイッチオーバー時にオンラインでもスイッチオーバーに関与しない他のスタンバイ・データベースは、停止して再起動する必要はありません。これらのスタンバイ・データベースは、スイッチオーバーの完了後も正常に機能し続けます。



7.2.2 フィジカル・スタンバイ・データベースが関与するフェイルオーバーフィジカル・スタンバイ・データベースが関与するフェイルオーバーフィジカル・スタンバイ・データベースが関与するフェイルオーバーフィジカル・スタンバイ・データベースが関与するフェイルオーバーこの項では、フィジカル・スタンバイ・データベースが関与するフェイルオーバーの実行方法を説明します。

フィジカル・スタンバイ・データベースが関与するフェイルオーバー時に、次の処理が実行されます。

� すべての場合、フェイルオーバーの完了後、元のプライマリ・データベースは Data Guard構成に含まれなくなります。

� ほとんどの場合、フェイルオーバーに直接関与しない他のロジカルまたはフィジカル・スタンバイ・データベースは構成内に残り、停止して再起動する必要はありません。

� 新しいプライマリ・データベースを構成した後、すべてのスタンバイ・データベースの再作成が必要な場合があります。

フェイルオーバーを開始する前に、7.1.4 項「フェイルオーバー」で説明した手順を可能なかぎり実行し、選択したスタンバイ・データベースのフェイルオーバーの準備をしてから、7.2.2 項

「フィジカル・スタンバイ・データベースが関与するフェイルオーバー」に進んでください。

フェイルオーバーの手順フェイルオーバーの手順フェイルオーバーの手順フェイルオーバーの手順

この項では、選択したフィジカル・スタンバイ・データベースをプライマリ・ロールに推移するために必要な手順について説明します。構成の一部でもある他のフィジカルまたはロジカル・スタンバイ・データベースは構成内に残り、停止して再起動する必要はありません。

ターゲット・スタンバイ・データベースがログ・ライター・プロセス（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 90 92

この例では、スレッド 1 の順序 90、91 および 92 のアーカイブ REDO ログ・ファイルがギャップです。可能であれば、欠落が識別されたすべてのアーカイブ REDO ログ・ファイルを、プライマリ・データベースからターゲット・スタンバイ・データベースにコピーして登録します。スレッドごとに実行する必要があります。


SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

注意注意注意注意 : フェイルオーバーを実行するには、次の項で説明するフェイルオーバーの手順およびコマンドのみを使用することをお薦めします。 ALTER DATABASE ACTIVATE STANDBY DATABASE文によりデータ消失が発生する場合があるため、フェイルオーバーの実行にはこの文を使用しないでください。



手順手順手順手順 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---------- ---------- 1 100

ターゲット・スタンバイ・データベースでも大きい順序番号より大きい順序番号を含むプライマリ・データベースから、使用可能なアーカイブ REDO ログ・ファイルをターゲット・スタンバイ・データベースにコピーして登録します。スレッドごとに実行する必要があります。


SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

使用可能なアーカイブ REDO ログ・ファイルをすべて登録した後に、手順 1 で説明したように、V$ARCHIVE_GAPビューを問い合せて、手順 3 に他のギャップが追加されていないことを確認します。

手順手順手順手順 4 ターゲット・フィジカル・スタンバイ・データベースでフェイルオーバーを開始するターゲット・フィジカル・スタンバイ・データベースでフェイルオーバーを開始するターゲット・フィジカル・スタンバイ・データベースでフェイルオーバーを開始するターゲット・フィジカル・スタンバイ・データベースでフェイルオーバーを開始する

次の文を発行してフェイルオーバーを開始します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;

FORCEキーワードは、ターゲット・フィジカル・スタンバイ・データベース上のアクティブなRFS プロセスを終了します。これにより、フェイルオーバーはネットワーク接続のタイムアウトを待たずに即時に進行できます。

注意注意注意注意 : 手順 1 から 3 を実行しているときに、アーカイブ REDO ログ・ファイル内のギャップを解決できない場合（障害の発生したプライマリ・データベースが置かれているシステムへのアクセス権がない場合など）、フェイルオーバー時にデータが消失する可能性があります。

注意注意注意注意 : フェイルオーバーにより、アーカイブされる後のログ・ファイルのヘッダーに end-of-redo マーカーが追加され、この REDO はプライマリ・ロール（VALID_FOR=(PRIMARY_ROLE, *_LOGFILES) またはVALID_FOR=(ALL_ROLES, *_LOGFILES) 属性で指定）として妥当なすべての使用可能な宛先に送信されます。

注意注意注意注意 : FINISHキーワードは、SQL 文で FORCE、WAITまたは NOWAITを除く他のすべてのキーワードの後に置く必要があります。



手順手順手順手順 5 フィジカル・スタンバイ・データベース・ロールからプライマリ・ロールに変換するフィジカル・スタンバイ・データベース・ロールからプライマリ・ロールに変換するフィジカル・スタンバイ・データベース・ロールからプライマリ・ロールに変換するフィジカル・スタンバイ・データベース・ロールからプライマリ・ロールに変換する

SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE...FINISH FORCE文が正常に完了した後、次の SQL 文を発行して、フィジカル・スタンバイ・データベースをプライマリ・データベース・ロールに変更します。


この SQL 文を発行した後、ターゲット・スタンバイ・データベースがプライマリ・ロールに推移します。その結果、このデータベースはスタンバイ・データベースとして使用できなくなり、元のプライマリ・データベースから受信した後続の REDO は適用できません。フェイルオーバー・プロセスでは、スタンバイ REDO ログ・ファイルが自動的にアーカイブされ、元のプライマリ・データベースから作成した他のすべてのスタンバイ・データベースでリカバリされます。この処理は、新しいプライマリ・データベースでスタンバイ宛先を適切に定義した場合のみ実行されます。

フェイルオーバーに関与しない構成内の他のスタンバイ・データベースは、停止して再起動する必要はありません。

手順手順手順手順 6 スタンバイ・データベースからプライマリ・データベース・ロールへの推移を終了するスタンバイ・データベースからプライマリ・データベース・ロールへの推移を終了するスタンバイ・データベースからプライマリ・データベース・ロールへの推移を終了するスタンバイ・データベースからプライマリ・データベース・ロールへの推移を終了する

この手順で実行するタスクは、フィジカル・スタンバイ・データベースが読取り専用モードでオープンされたことがあるかどうかに応じて異なります。

� フィジカル・スタンバイ・データベースが前回の起動後に読取り専用モードでオープンされていない場合は、SQL ALTER DATABASE OPEN文を発行して新規プライマリ・データベースをオープンします。


その後、手順 7 に進みます。

� フィジカル・スタンバイ・データベースが前回の起動後に読取り専用モードでオープンされている場合は、ターゲット・スタンバイ・データベースを停止して再起動する必要があります。

SQL> SHUTDOWN IMMEDIATE;SQL> STARTUP;

ターゲット・フィジカル・スタンバイ・データベースがプライマリ・データベース・ロールに推移します。

LOG_ARCHIVE_DEST_nの VALID_FOR属性を使用して Data Guard 構成をロールの推移後も正常に動作させる方法については、5.4.1 項「VALID_FOR 属性を使用したロール・ベースの宛先の指定」および第 14 章「LOG_ARCHIVE_DEST_n パラメータの属性」を参照してください。

手順手順手順手順 7 新しいプライマリ・データベースをバックアップする新しいプライマリ・データベースをバックアップする新しいプライマリ・データベースをバックアップする新しいプライマリ・データベースをバックアップする

STARTUP文を発行する前に、新しいプライマリ・データベースのバックアップを作成します。バックアップを即時に実行することは、必要な安全策です。これは、データベースの完全なバックアップ・コピーを作成せずにフェイルオーバーを行うと、変更をリカバリできないためです。

フェイルオーバーの結果、元のプライマリ・データベースは Data Guard 構成に含まれなくなり、他のすべてのスタンバイ・データベースは新しいプライマリ・データベースから REDOデータを受信して適用します。



手順手順手順手順 8 障害の発生したプライマリ・データベースをリストアする（オプション）障害の発生したプライマリ・データベースをリストアする（オプション）障害の発生したプライマリ・データベースをリストアする（オプション）障害の発生したプライマリ・データベースをリストアする（オプション）

フェイルオーバーの完了後、元のプライマリ・データベースは構成に含まれなくなります。フェイルオーバーの実行後、次のどちらかの方法を使用して、障害の発生したプライマリ・データベースを新規スタンバイ・データベースとしてリストアすることもできます。

� フラッシュバック・データベースを使用して、障害の発生したプライマリ・データベースをフェイルオーバー発生前の時点までリストアしてから、12-24 ページの 12.4 項「フェイルオーバー後のフラッシュバック・データベースの使用」の手順に従ってスタンバイ・データベースに変換します。

� 障害の発生したデータベースを再作成し、新規スタンバイ・データベースとして構成に追加します。古いプライマリ・データベースを新しい構成内で再利用するには、新しいプライマリ・データベースのバックアップ・コピーを使用し、スタンバイ・データベースとして再作成する必要があります。この手順については、3.2 項「フィジカル・スタンバイ・データベースの作成手順」または 4.2 項「ロジカル・スタンバイ・データベースの作成手順」を参照してください。

� 接続が再確立された時点で、Oracle Data Guard Broker の REINSTATEコマンド（Oracle Enterprise Manager または DGMGRL の REINSTATE DATABASEコマンド）を使用して、障害が発生したプライマリ・データベースを新規構成のスタンバイ・データベースとして再作成します。元に戻すための手順については、『Oracle Data Guard Broker』を参照してください。このオプションでは、フェイルオーバー前にフラッシュバック・データベースが有効化されている必要があります。

障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、元の（障害発生前の）ロールへのそれぞれのデータベースの推移を実行できます。詳細は、7.2.1 項「フィジカル・スタンバイ・データベースが関与するスイッチオーバー」を参照してください。

注意注意注意注意 : フェイルオーバーの前に、旧プライマリ・データベースでフラッシュバック・データベースを使用可能にしておく必要があります。詳細は、

『Oracle Database バックアップおよびリカバリ基礎』を参照してください。


ロジカル・スタンバイ・データベースが関与するロールの推移

7.3 ロジカル・スタンバイ・データベースが関与するロールのロジカル・スタンバイ・データベースが関与するロールのロジカル・スタンバイ・データベースが関与するロールのロジカル・スタンバイ・データベースが関与するロールの推移推移推移推移

この項では、ロジカル・スタンバイ・データベースが関与するスイッチオーバーおよびフェイルオーバーの実行方法を説明します。

7.3.1 ロジカル・スタンバイ・データベースが関与するスイッチオーバーロジカル・スタンバイ・データベースが関与するスイッチオーバーロジカル・スタンバイ・データベースが関与するスイッチオーバーロジカル・スタンバイ・データベースが関与するスイッチオーバープライマリ・データベースとロジカル・スタンバイ・データベースとの間でスイッチオーバーを実行する場合、スイッチオーバーは、常にプライマリ・データベースで開始し、ロジカル・スタンバイ・データベースで完了してください。次の手順を記載されているとおりの順序で実行しなかった場合、スイッチオーバーは成功しません。

手順手順手順手順 1 プライマリ・データベースでスイッチオーバーを実行できるかどうかを確認するプライマリ・データベースでスイッチオーバーを実行できるかどうかを確認するプライマリ・データベースでスイッチオーバーを実行できるかどうかを確認するプライマリ・データベースでスイッチオーバーを実行できるかどうかを確認する

スイッチオーバーを実行できるかどうかを確認するには、現行のプライマリ・データベースでV$DATABASE固定ビューの SWITCHOVER_STATUS列を問い合せます。


SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;SWITCHOVER_STATUS-----------------TO STANDBY1 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が表示されます。

注意注意注意注意 : プライマリ・データベースが RAC データベースの場合は、スイッチオーバーを開始する前に、1 つを除くすべてのインスタンスが停止していることと、対応するスレッドが無効化されていることを確認してください。同様に、ロジカル・スタンバイ・データベースが RAC データベースの場合は、スイッチオーバーを開始する前に、SQL Apply を実行中の 1 つを除くすべてのインスタンスが停止していることと、対応するスレッドが無効化されていることを確認してください。スイッチオーバー操作が正常に完了した後、スレッドを再び有効化してインスタンスを起動できます。インスタンスが停止されていても、ロールの変更は再起動時にこれらのインスタンスへ自動的に伝播します。



手順手順手順手順 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 STANDBY1 row selected

注意注意注意注意 : 次の文を順番に発行すると、スイッチオーバー操作を取り消すことができます。

1. プライマリ・データベースでスイッチオーバーを取り消します。

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY CANCEL;

2. ロジカル・スタンバイ・データベースでスイッチオーバーを取り消します。

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL PRIMARY CANCEL;



手順手順手順手順 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 PRIMARY1 row selected

V$DATABASEビューの SWITCHOVER_STATUS列に対するその他の有効な値については、『Oracle Database リファレンス』を参照してください。

手順手順手順手順 7 ターゲット・ロジカル・スタンバイ・データベースをプライマリ・データベース・ターゲット・ロジカル・スタンバイ・データベースをプライマリ・データベース・ターゲット・ロジカル・スタンバイ・データベースをプライマリ・データベース・ターゲット・ロジカル・スタンバイ・データベースをプライマリ・データベース・ロールに切り替えるロールに切り替えるロールに切り替えるロールに切り替える

プライマリ・ロールに切り替えるロジカル・スタンバイ・データベースで、次の SQL 文を使用し、ロジカル・スタンバイ・データベースをプライマリ・ロールに切り替えます。


Data Guard 構成内のロジカル・スタンバイ・データベースは、停止して再起動する必要はありません。他の既存のロジカル・スタンバイ・データベースは、スイッチオーバーの完了後も正常に機能し続けます。ただし、既存のすべてのフィジカル・スタンバイ・データベースは、スイッチオーバー後は Data Guard 構成に含まれなくなります。

手順手順手順手順 8 新規のロジカル・スタンバイ・データベースで新規のロジカル・スタンバイ・データベースで新規のロジカル・スタンバイ・データベースで新規のロジカル・スタンバイ・データベースで SQL Apply を開始するを開始するを開始するを開始する

新しいロジカル・スタンバイ・データベースで SQL Apply を開始します。




7.3.2 ロジカル・スタンバイ・データベースが関与するフェイルオーバーロジカル・スタンバイ・データベースが関与するフェイルオーバーロジカル・スタンバイ・データベースが関与するフェイルオーバーロジカル・スタンバイ・データベースが関与するフェイルオーバーこの項では、ロジカル・スタンバイ・データベースが関与するフェイルオーバーの実行方法を説明します。ロジカル・スタンバイ・データベースが関与するフェイルオーバーによるロールの推移では、障害の発生したプライマリ・データベースとすべてのロジカル・スタンバイ・データベースで対処措置を実行する必要があります。障害の発生したプライマリ・データベースでフラッシュバック・データベースが有効化されていない場合は、現行のプライマリ・データベースから作成したバックアップを使用してデータベースを再作成する必要があります。それ以外の場合は、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----------- ---------- 190725 190725

APPLIED_SCNと LATEST_SCNの値が等しい場合は、取得可能なすべてのデータが適用され、ロジカル・スタンバイ・データベースにはプライマリ・データベースからのデータが可能なかぎり含まれています。

V$LOGSTDBY_PROGRESSビューについては、第 9 章「ロジカル・スタンバイ・データベースの管理」および第 12 章「Data Guard の使用例」を参照してください。

注意注意注意注意 : ターゲット・ロジカル・スタンバイ・データベースで SQL Applyがアクティブになっていない場合は、ターゲット・スタンバイ・データベースで次の文を発行して、SQL Apply を開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY FINISH;Database altered.



手順手順手順手順 3 リモート宛先を使用可能にするリモート宛先を使用可能にするリモート宛先を使用可能にするリモート宛先を使用可能にする

5-16 ページの 5.4.1 項「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 ページの 5.4.1 項「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ロールが付与されている必要があります。



データベース・リンクを作成する方法については、『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-16109エラーが表示された場合は、新しいプライマリ・データベースのバックアップ・コピーからロジカル・スタンバイ・データベースを再作成して 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 のデータベース・フェイルオーバー直後に、新しいプライマリ・データベースのバックアップを作成します。バックアップを即時に実行することは、必要な安全策です。これは、データベースの完全なバックアップ・コピーを作成せずにフェイルオーバーを行うと、変更をリカバリできないためです。

注意注意注意注意 : プライマリ・データベースがオープンされた後、DDL 文が実行される前に、ディクショナリ作成操作を実行する必要があります。ディクショナリ作成操作を実行する前に DDL 文が実行されると、バックアップがロジカル・スタンバイ・データベースの作成ソースとして無効になります。



手順手順手順手順 8 障害の発生したプライマリ・データベースをリストアする障害の発生したプライマリ・データベースをリストアする障害の発生したプライマリ・データベースをリストアする障害の発生したプライマリ・データベースをリストアする

フェイルオーバーの実行後、必要に応じて次のいずれかの方法を使用して、障害の発生したプライマリ・データベースを新規スタンバイ・データベースとしてリストアすることもできます。

� フラッシュバック・データベースを使用して、障害の発生したプライマリ・データベースをフェイルオーバー発生前の時点に変換してから、12-24 ページの 12.4 項「フェイルオーバー後のフラッシュバック・データベースの使用」の手順に従ってスタンバイ・データベースに変換します。

� 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.3.1 項「ロジカル・スタンバイ・データベースが関与するスイッチオーバー」を参照してください。

注意注意注意注意 : フェイルオーバーの前に、旧プライマリ・データベースでフラッシュバック・データベースを使用可能にしておく必要があります。詳細は、『Oracle Database バックアップおよびリカバリ基礎』を参照してください。


ロールの推移後のフラッシュバック・データベースの使用

7.4 ロールの推移後のフラッシュバック・データベースの使用ロールの推移後のフラッシュバック・データベースの使用ロールの推移後のフラッシュバック・データベースの使用ロールの推移後のフラッシュバック・データベースの使用ロールの推移後に、必要に応じて FLASHBACK DATABASEコマンドを使用して、データベースをロールの推移が発生する前の時点またはシステム変更番号（SCN）まで戻すことができます。

フィジカル・スタンバイ・データベース環境では、Data Guard 構成を維持するためにプライマリ・データベースとすべてのスタンバイ・データベースのフラッシュバックが必要になる場合があります。プライマリ・データベースを特定の SCN または時点までフラッシュバックする場合は、すべてのスタンバイ・データベースを同じ（またはそれ以前の）SCN または時点までフラッシュバックする必要があります。これにより、REDO Apply の開始後に、フィジカル・スタンバイ・データベースではプライマリ・データベースから受信した REDO データの適用が自動的に開始されます。

この方法でプライマリ・データベースまたはスタンバイ・データベースをフラッシュバックすると、過去のスイッチオーバーを認識する必要がありません。 Oracle では、SCN または時点が過去のスイッチオーバーより前であれば、過去のスイッチオーバーにまたがって自動的にフラッシュバックできます。

7.4.1 スイッチオーバー後のフラッシュバック・データベースの使用スイッチオーバー後のフラッシュバック・データベースの使用スイッチオーバー後のフラッシュバック・データベースの使用スイッチオーバー後のフラッシュバック・データベースの使用スイッチオーバー後に FLASHBACK DATABASEコマンドを使用して、データベースをスイッチオーバー発生前の時点またはシステム変更番号（SCN）に戻すことができます。

スイッチオーバーにフィジカル・スタンバイ・データベースが関与していた場合、フラッシュバック操作中はプライマリおよびスタンバイ・データベース・ロールが保持されます。つまり、データベースが実行中のロールは、フラッシュバックした時点またはターゲット SCN までデータベースがフラッシュバックされても変化しません。スイッチオーバー後からフラッシュバックの前までフィジカル・スタンバイ・ロールで実行されていたデータベースは、フラッシュバック・データベース操作後もフィジカル・スタンバイ・データベースで実行されます。

スイッチオーバーにロジカル・スタンバイ・データベースが関与していた場合、フラッシュバックするとスタンバイ・データベースのロールはフラッシュバックした時点またはターゲット SCN でのロールに変更されます。

7.4.2 フェイルオーバー後のフラッシュバック・データベースの使用フェイルオーバー後のフラッシュバック・データベースの使用フェイルオーバー後のフラッシュバック・データベースの使用フェイルオーバー後のフラッシュバック・データベースの使用フラッシュバック・データベースを使用して、障害の発生したプライマリ・データベースをフェイルオーバー発生前の時点に変換してから、スタンバイ・データベースに変換できます。手順の詳細は、12.4 項「フェイルオーバー後のフラッシュバック・データベースの使用」を参照してください。

注意注意注意注意 : ロールの推移が発生する前に、データベースでフラッシュバック・データベースを有効化しておく必要があります。詳細は、『Oracle Database バックアップおよびリカバリ基礎』を参照してください。


ロールの推移後のフラッシュバック・データベースの使用


フィジカル・スタンバイ・データベースの

8
フィジカル・スタンバイ・データベースの管理フィジカル・スタンバイ・データベースの管理フィジカル・スタンバイ・データベースの管理フィジカル・スタンバイ・データベースの管理
この章では、フィジカル・スタンバイ・データベースの管理方法について説明します。この章は、次の項目で構成されています。

� フィジカル・スタンバイ・データベースの起動と停止

� スタンバイ・データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法

� スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理

� OPEN RESETLOGS 文を使用したリカバリ

� プライマリおよびスタンバイ・データベースの監視

� フィジカル・スタンバイ・データベースに関するログ適用レートのチューニング

この章の各項では、フィジカル・スタンバイ・データベースを管理するための SQL 文、初期化パラメータおよびビューの使用方法について、それぞれ説明します。

この章で説明する管理タスクを自動化するために Data Guard Broker を使用する場合は、『Oracle Data Guard Broker』を参照してください。

管理 8-1

フィジカル・スタンバイ・データベースの起動と停止

8.1 フィジカル・スタンバイ・データベースの起動と停止フィジカル・スタンバイ・データベースの起動と停止フィジカル・スタンバイ・データベースの起動と停止フィジカル・スタンバイ・データベースの起動と停止この項では、フィジカル・スタンバイ・データベースの起動および停止に使用する SQL*Plus文について説明します。

8.1.1 フィジカル・スタンバイ・データベースの起動フィジカル・スタンバイ・データベースの起動フィジカル・スタンバイ・データベースの起動フィジカル・スタンバイ・データベースの起動フィジカル・スタンバイ・データベースを起動するには、管理者権限で 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 項、リアルタイム適用については 6.2.1 項、フィジカル・スタンバイ・データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法については 8.2 項を参照してください。

注意注意注意注意 : 新しく作成した、プライマリ・データベースからの REDO データをまだ受信していないフィジカル・スタンバイ・データベース上では、初めて REDO Apply を開始すると ORA-01112メッセージが戻されることがあります。このメッセージは、REDO Apply がメディア・リカバリ用の開始順序番号を判別できないことを示します。このエラーが発生した場合は、スタンバイ・データベースでアーカイブ REDO ログ・ファイルを手動で検索して登録するか、または自動アーカイブが発生するまで待機したあと、REDO Apply を再開する必要があります。


スタンバイ・データベースを読取り専用または読取り / 書込みアクセス用にオープンする方法

8.1.2 フィジカル・スタンバイ・データベースの停止フィジカル・スタンバイ・データベースの停止フィジカル・スタンバイ・データベースの停止フィジカル・スタンバイ・データベースの停止フィジカル・スタンバイ・データベースを停止し、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 が実行中の場合は、次の例に示すように取り消します。


3. スタンバイ・データベースを停止します。

SQL> SHUTDOWN IMMEDIATE;

8.2 スタンバイ・データベースを読取り専用または読取りスタンバイ・データベースを読取り専用または読取りスタンバイ・データベースを読取り専用または読取りスタンバイ・データベースを読取り専用または読取り / 書込み書込み書込み書込みアクセス用にオープンする方法アクセス用にオープンする方法アクセス用にオープンする方法アクセス用にオープンする方法

スタンバイ・データベースが読取り専用アクセス用にオープンしている場合、ユーザーはスタンバイ・データベースを問い合せることができますが、更新はできません。したがって、レポートを生成するためにスタンバイ・データベースを使用すると、プライマリ・データベース負荷を低減できます。スタンバイ・データベースを定期的に読取り専用アクセス用としてオープンし、REDO Apply がスタンバイ・データベースを適切に更新していることを確認するために、非定型問合せを実行できます。（分散問合せの場合、読取り専用データベースに対して問合せを発行する前に、まず ALTER DATABASE SET TRANSACTION READ ONLY文を発行する必要があります。）

図 8-1 に、読取り専用アクセス用にオープンしたスタンバイ・データベースを示します。

フィジカル・スタンバイ・データベースの管理 8-3


図図図図 8-1 読取り専用アクセス用にオープンしたスタンバイ・データベース読取り専用アクセス用にオープンしたスタンバイ・データベース読取り専用アクセス用にオープンしたスタンバイ・データベース読取り専用アクセス用にオープンしたスタンバイ・データベース

フィジカル・スタンバイ・データベースを開発、レポートまたはテストのために読取り / 書込みモードで一時的にオープンしてから、過去の特定時点までフラッシュバックして元に戻すことができます。データベースがフラッシュバックされると、Data Guard では自動的にスタンバイ・データベースをプライマリ・データベースと同期化します。プライマリ・データベースのバックアップ・コピーからフィジカル・スタンバイ・データベースを再作成する必要はありません。


� スタンバイ・データベースをオープンするかどうかの評価

� 読取り専用アクセス用にフィジカル・スタンバイ・データベースをオープン

関連項目関連項目関連項目関連項目 : フィジカル・スタンバイ・データベースを読取り / 書込みレポート用データベースとしてアクティブにした後、プライマリ・データベースと再同期化する方法を示す使用例は、12.6 項を参照してください。



8.2.1 スタンバイ・データベースをオープンするかどうかの評価スタンバイ・データベースをオープンするかどうかの評価スタンバイ・データベースをオープンするかどうかの評価スタンバイ・データベースをオープンするかどうかの評価フィジカル・スタンバイ・データベースを読取り専用または読取り / 書込みアクセス用にオープンするかどうかを判断する場合は、次のことを考慮してください。

� フィジカル・スタンバイ・データベースを読取り専用でオープンすると、フェイルオーバー後は再起動する必要があるため、障害や停止からのリカバリ所要時間が長くなることがあります。

フィジカル・スタンバイ・データベースが前回の起動後に読取り専用でオープンされていなければ、フェイルオーバー後に再起動する必要はないため、システムの可用性が向上します。

� スタンバイ・データベースが読取り専用または読取り / 書込みアクセス用にオープンされている間は、プライマリ・データベースから受信した REDO データが適用されないため、プライマリ・データベースとのトランザクション一貫性が維持されません。

フィジカル・スタンバイ・データベースがオープンされている場合、プライマリ・データベースからの REDO データはスタンバイ・データベースによって受信されますが、ログ・ファイルは適用されません。スタンバイ・データベースで REDO Apply を再開し、アーカイブ REDO ログ・ファイルを適用して、スタンバイ・データベースをプライマリ・データベースと再同期化させることが必要となる場合があります。蓄積されたアーカイブ REDOログ・ファイルの適用には余分に時間がかかるため、スタンバイ・データベースを読取り専用アクセス用にオープンしておくと、フェイルオーバーまたはスイッチオーバーに時間がかかる場合があります。

スタンバイ・システムに複数のスタンバイ・データベースを構成すると、フィジカル・スタンバイ・データベースをレポート生成用またはクローン・データベースとして使用すると同時に、すばやくフェイルオーバーまたはスイッチオーバーを実行することが可能です。

たとえば、ビジネス要件に基づき、次の構成が可能です。

� 1 つのスタンバイ・データベースに 2 つのフィジカル・スタンバイ・データベースを構成します。常に REDO Apply を実行することにより、プライマリ・データベースと可能なかぎり同期を取り、もう一方のスタンバイ・データベースは、営業時間中はレポート生成のために読取り専用モードでオープンにします。

� 1 つのフィジカル・スタンバイ・データベースを構成し、障害時リカバリに備えてプライマリ・データベースのコピーを維持します。また、ロジカル・スタンバイ・データベースを構成し、プライマリ・データベースの新データへのアクセスが必要なレポート生成タスクをオフロードします。

同じシステム上で複数のスタンバイ・データベースを構成する場合は、REDO データを各アーカイブ先に個別に転送するのではなく、LOG_ARCHIVE_DEST_n初期化パラメータのDEPENDENCY属性を使用して、1 つのアーカイブ先がすべてのアーカイブ先のかわりに REDOデータを受信するように定義することを考慮してください。詳細は、5.7.5 項を参照してください。



8.2.2 読取り専用アクセス用にフィジカル・スタンバイ・データベースを読取り専用アクセス用にフィジカル・スタンバイ・データベースを読取り専用アクセス用にフィジカル・スタンバイ・データベースを読取り専用アクセス用にフィジカル・スタンバイ・データベースをオープンオープンオープンオープン

フィジカル・スタンバイ・データベースは、次の手順に従って、読取り専用アクセス用オープンから REDO Apply の実行に（またはその逆に）変更できます。

スタンバイ・データベースが停止しているときに読取り専用アクセス用にスタンバイ・データベースが停止しているときに読取り専用アクセス用にスタンバイ・データベースが停止しているときに読取り専用アクセス用にスタンバイ・データベースが停止しているときに読取り専用アクセス用にオープンする方法オープンする方法オープンする方法オープンする方法次の文を使用して、データベースを起動し、マウントし、読取り専用アクセス用にオープンします。

SQL> STARTUP;

REDO Apply の実行中にスタンバイ・データベースを読取り専用アクセス用にの実行中にスタンバイ・データベースを読取り専用アクセス用にの実行中にスタンバイ・データベースを読取り専用アクセス用にの実行中にスタンバイ・データベースを読取り専用アクセス用にオープンする方法オープンする方法オープンする方法オープンする方法1. REDO Apply を取り消します。


2. 次のように入力してデータベースを読取り専用アクセス用にオープンします。


読取り専用アクセス用にオープンするために、インスタンスを停止する必要はありません。

スタンバイ・データベースを読取り専用アクセス用オープンからスタンバイ・データベースを読取り専用アクセス用オープンからスタンバイ・データベースを読取り専用アクセス用オープンからスタンバイ・データベースを読取り専用アクセス用オープンから REDO Apply実行に変更する方法実行に変更する方法実行に変更する方法実行に変更する方法1. スタンバイ・データベースのすべてのアクティブ・ユーザー・セッションを終了します。

2. REDO Apply を再開します。REDO Apply を開始するには、次の文を発行します。


リアルタイム適用を有効にするには、USING CURRENT LOGFILE句を使用します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE;

これらの適用モードを開始するために、インスタンスを停止する必要はありません。

注意注意注意注意 : デフォルトで、ALTER DATABASE OPEN文は読取り専用モードでフィジカル・スタンバイ・データベースをオープンします。Oracle データベースは、制御ファイルの情報に基づいて、このデータベースがフィジカル・スタンバイ・データベースであるかどうかを判断します。


スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理

8.3 スタンバイ・データベースに影響を与えるプライマリ・スタンバイ・データベースに影響を与えるプライマリ・スタンバイ・データベースに影響を与えるプライマリ・スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理データベース・イベントの管理データベース・イベントの管理データベース・イベントの管理

問題が起きないようにするには、スタンバイ・データベースに影響するプライマリ・データベースのイベントを認識し、それらに応答する方法を見極める必要があります。この項では、それらのイベントについて説明し、イベントに対して推奨される応答についても説明します。

プライマリ・データベースで発生するイベントまたは変更の一部は、REDO データを介してスタンバイ・データベースに自動的に伝播されるため、スタンバイ・データベースでそれ以上のアクションは不要です。それ以外の場合は、スタンバイ・データベースでメンテナンス・タスクを実行する必要があります。

プライマリ・データベースで行われた変更をスタンバイ・データベースへ伝播するためには、データベース管理者（DBA）の介入が必要かどうかを表 8-1 に示します。また、これらのイベントに応答する方法についても簡単に説明します。応答の詳細は、表に示されている参照先の項で説明します。

次のイベントは、REDO 転送サービスおよび REDO Apply によって自動的に管理されるため、データベース管理者の介入は不要です。

� ENABLE THREADまたは DISABLE THREAD句を使用した SQL ALTER DATABASE文の発行

� 表領域の状態の変更（読取り / 書込みまたは読取り専用に変更され、オンラインまたはオフラインにされる）

� STANDBY_FILE_MANAGEMENT初期化パラメータが AUTOに設定されている場合のデータファイルの追加または表領域の作成

表表表表 8-1 プライマリ・データベースでの変更後にスタンバイ・データベースで必要なアクションプライマリ・データベースでの変更後にスタンバイ・データベースで必要なアクションプライマリ・データベースでの変更後にスタンバイ・データベースで必要なアクションプライマリ・データベースでの変更後にスタンバイ・データベースで必要なアクション

参照先参照先参照先参照先プライマリ・データベースで行われた変更プライマリ・データベースで行われた変更プライマリ・データベースで行われた変更プライマリ・データベースで行われた変更スタンバイ・データベースで必要なアクションスタンバイ・データベースで必要なアクションスタンバイ・データベースで必要なアクションスタンバイ・データベースで必要なアクション

8.3.1 項データファイルの追加または表領域の作成 STANDBY_FILE_MANAGEMENT初期化パラメータを AUTOに設定

していない場合は、新しいデータファイルをスタンバイ・データベースにコピーする必要がある。

8.3.2 項表領域またはデータファイルの削除 DROPまたは DELETEコマンドが含まれているアーカイブ REDOログ・ファイルの適用後に、プライマリ・データベースとスタンバイ・データベースからデータファイルを削除する。

8.3.3 項トランスポータブル表領域の使用プライマリ・データベースとスタンバイ・データベースの間で表領域を移動する。

8.3.4 項データファイル名の変更スタンバイ・データベースでデータファイルを改名する。

8.3.5 項 REDO ログ・ファイルの追加または削除変更をスタンバイ・データベースで同期化する。

8.3.6 項 NOLOGGINGまたは UNRECOVERABLE句を

使用した DML または DDL 操作の実行

ログに記録されていない変更を含むデータファイルをスタンバイ・データベースに送信する。

第 13 章初期化パラメータの変更スタンバイ・パラメータを動的に変更するか、またはスタンバイ・データベースを停止し、初期化パラメータ・ファイルを更新する。



8.3.1 データファイルの追加または表領域の作成データファイルの追加または表領域の作成データファイルの追加または表領域の作成データファイルの追加または表領域の作成STANDBY_FILE_MANAGEMENT初期化パラメータを使用して、次のように、プライマリ・データベースへのデータファイルの追加がスタンバイ・データベースに自動的に伝播されるかどうかを制御できます。

� スタンバイ・データベースのサーバー・パラメータ・ファイル（SPFILE）で STANDBY_FILE_MANAGEMENT初期化パラメータを AUTOに設定した場合は、プライマリ・データベースで作成された新しいデータファイルがスタンバイ・データベースでも自動的に作成されます。

� STANDBY_FILE_MANAGEMENT初期化パラメータを指定していない場合、またはこのパラメータを MANUALに設定した場合は、新しいデータファイルをプライマリ・データベースに追加するときに、そのデータファイルをスタンバイ・データベースに手動でコピーする必要があります。

既存のデータファイルを別のデータベースからプライマリ・データベースへコピーする場合は、STANDBY_FILE_MANAGEMENT初期化パラメータの設定に関係なく、新しいデータファイルをスタンバイ・データベースにコピーし、スタンバイ制御ファイルを再作成する必要があります。

次の各項では、STANDBY_FILE_MANAGEMENT初期化パラメータが AUTOまたは MANUALに設定されている場合に、データファイルをプライマリおよびスタンバイ・データベースに追加する例を示します。

8.3.1.1 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.3.1.2 STANDBY_FILE_MANAGEMENT がががが MANUAL に設定されている場合に設定されている場合に設定されている場合に設定されている場合この項では、STANDBY_FILE_MANAGEMENT初期化パラメータが MANUALに設定されている場合に、新しいデータファイルをプライマリおよびスタンバイ・データベースに追加する方法について説明します。スタンバイ・データファイルが RAW デバイスに存在する場合は、STANDBY_FILE_MANAGEMENT初期化パラメータを MANUALに設定する必要があります。また、この項では、発生したエラーからのリカバリ方法についても説明します。

8.3.1.2.1 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:31 2005Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1_mf_1_7_15ffgt0z_.arcRecovery created file /dev/raw/raw100Successfully added datafile 6 to media recoveryDatafile #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.

注意注意注意注意 : 次の手順は、Oracle Managed Files を使用するデータベースには使用しないでください。また、RAW デバイスのパス名がプライマリ・サーバー上とスタンバイ・サーバー上で異なる場合は、DB_FILE_NAME_CONVERT初期化パラメータを使用してパス名を変換してください。



スタンバイ・システムには、RAW デバイス /Dave/raw/raw101が作成されていません。アーカイブをリカバリすると、スタンバイ・アラート・ログに次のメッセージが示されます。

Fri Apr 8 10:00:22 2005Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1_mf_1_8_15ffjrov_.arcFile #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 1274Fri Apr 8 10:00:22 2005Errors 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 deniedAdditional information: 1Some recovered datafiles maybe left media fuzzyMedia recovery may continue but open resetlogs may failFri Apr 8 10:00:22 2005Errors 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 deniedAdditional information: 1Fri Apr 8 10:00:22 2005MTS; MRP0: Background Media Recovery process shutdownARCH: Connecting to console port...

8.3.1.2.2 エラーのリカバリエラーのリカバリエラーのリカバリエラーのリカバリ

8.3.1.2.1 項で説明した問題を修正する手順は、次のとおりです。

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';



3. スタンバイ・アラート・ログに、次のような情報が表示されます。

Fri Apr 8 10:09:30 2005alter database create datafile'/dev/raw/raw101' as '/dev/raw/raw101'Fri Apr 8 10:09:30 2005Completed: 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 デバイスのデータファイルを使用し、リカバリが続行されます。

8.3.2 表領域の削除とデータファイルの削除表領域の削除とデータファイルの削除表領域の削除とデータファイルの削除表領域の削除とデータファイルの削除プライマリ・データベースで 1 つ以上のデータファイルまたは表領域を削除した場合は、次の手順に従って、スタンバイ・データベースでも対応するデータファイルを削除する必要があります。次の各項では、STANDBY_FILE_MANAGEMENT初期化パラメータが AUTOまたは MANUALに設定されている場合に、表領域およびデータファイル削除する例を示します。

8.3.2.1 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

8.3.2.2 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.3.3 フィジカル・スタンバイ・データベースでのトランスポータブル表領域フィジカル・スタンバイ・データベースでのトランスポータブル表領域フィジカル・スタンバイ・データベースでのトランスポータブル表領域フィジカル・スタンバイ・データベースでのトランスポータブル表領域の使用の使用の使用の使用

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 管理者ガイド』を参照してください。

8.3.4 プライマリ・データベースのデータファイルの改名プライマリ・データベースのデータファイルの改名プライマリ・データベースのデータファイルの改名プライマリ・データベースのデータファイルの改名プライマリ・データベースで 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;



4. スタンバイ・データベースに接続し、V$ARCHIVED_LOGビューを問い合せてすべてのアーカイブ REDO ログ・ファイルが適用されたことを確認した後、REDO Apply を停止します。

SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;SEQUENCE# APP--------- ---8 YES9 YES10 YES11 YES4 rows selected.


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 を再開します。


スタンバイ・システムで対応するデータファイルを改名しないでスタンバイ・データベース制御ファイルをリフレッシュしようとすると、スタンバイ・データベースは改名されたデータファイルの使用を試みますが、改名されたデータファイルは見つかりません。したがって、アラート・ログに次のようなエラー・メッセージが表示されます。

ORA-00283: エラーによってリカバリ・セッションは取り消されました。

ORA-01157: データファイル 4を識別 /ロックできません - DBWRトレース・ファイルを参照してくださいORA-01110: データファイル 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf'



8.3.5 オンラインオンラインオンラインオンライン 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 オプションを元の状態にリストアします。

8.3.6 ログに記録されていないまたはリカバリ不能な操作ログに記録されていないまたはリカバリ不能な操作ログに記録されていないまたはリカバリ不能な操作ログに記録されていないまたはリカバリ不能な操作NOLOGGINGまたは UNRECOVERABLE句を使用して DML または DDL 操作を実行するとスタンバイ・データベースは無効になるため、修正のために多大な DBA 管理アクティビティが必要になる場合があります。SQL ALTER DATABASEまたは SQL ALTER TABLESPACE文でFORCELOGGING句を指定すると、NOLOGGING 設定を上書きできます。ただし、この文はすでに無効になっているデータベースを修正しません。

NOLOGGING句を使用した後のリカバリについては、12.10 項を参照してください。

注意注意注意注意 : オンライン REDO ログ・ファイルをプライマリ・データベースに追加した場合は、対応するオンライン REDO ログ・ファイルおよびスタンバイ REDO ログ・ファイルをスタンバイ・データベースに追加する必要があります。


OPEN RESETLOGS 文を使用したリカバリ

8.4 OPEN RESETLOGS 文を使用したリカバリ文を使用したリカバリ文を使用したリカバリ文を使用したリカバリData Guard では、RESETLOGSオプションを使用してプライマリ・データベースがオープンされた後も、フィジカル・スタンバイ・データベースでリカバリを続行できます。プライマリ・データベースで ALTER DATABASE OPEN RESETLOGS文を発行すると、データベースのインカネーションが変更され、REDO データの新規ブランチが作成されます。

フィジカル・スタンバイ・データベースが REDO データの新規ブランチを受信すると、REDO Apply ではそれが自動的に使用されます。フィジカル・スタンバイ・データベースの場合、スタンバイ・データベースにより新規リセットログの SCN より後（REDO データの新規ブランチの開始より後）の REDO データが適用されていなければ、手動による介入は必要ありません。次の表に、スタンバイ・データベースとプライマリ・データベースのブランチを再同期化する方法を示します。

データベース・インカネーション、OPEN RESETLOGS操作を介したリカバリおよびフラッシュバック・データベースの詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

スタンバイ・データベースの状態スタンバイ・データベースの状態スタンバイ・データベースの状態スタンバイ・データベースの状態操作操作操作操作実行する手順実行する手順実行する手順実行する手順

新規リセットログの SCN の後

（REDO データの新規ブランチの開始

より後）の REDO データが適用され

ていない場合。

REDO Apply は自動的に

REDO の新規ブランチを使用

します。

手動による介入は必要ありません。MRP は、自

動的にスタンバイ・データベースを REDO デー

タの新規ブランチと再同期化します。



より後）の REDO データが適用さ

れ、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっている場合。

スタンバイ・データベースは、REDO データの将来の新規ブ

ランチでリカバリされます。

1. 12.5.1 項の手順に従ってフィジカル・スタ

ンバイ・データベースをフラッシュ・バックします。

2. REDO Apply を再開し、新規リセットロ

グ・ブランチへの REDO データの適用を続

行します。

MRP は、自動的にスタンバイ・データベースを

新規ブランチと再同期化します。



より後）の REDO データが適用さ

れ、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっていない場合。

指定のプライマリ・データベース・ブランチで、プライマリ・データベースとスタンバイの内容にずれが生じます。

第 3 章の手順に従ってフィジカル・スタンバ

イ・データベースを再作成します。

REDO データの新規ブランチから介

入するアーカイブ REDO ログ・ファ

イルが欠落している場合。

MRP は欠落しているログ・

ファイルが取得されるまで続行できません。

各ブランチから欠落しているアーカイブ REDOログ・ファイルを検索して登録します。

REDO データの前のブランチの終わ

りからアーカイブ REDO ログ・ファ

イルが欠落している場合。

MRP は欠落しているログ・


前のブランチから欠落しているアーカイブREDO ログ・ファイルを検索して登録します。


プライマリおよびスタンバイ・データベースの監視

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ビュー


V$RECOVER_FILEビュー

データファイルの追加または表領域の作成

� DBA_DATA_FILESビュー


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.5.1 アラート・ログアラート・ログアラート・ログアラート・ログデータベースのアラート・ログは、メッセージとエラーに関する時系列のレコードです。アラート・ログには、Oracle データベースに関する情報に加えて、次のような Data Guard 固有の操作に関する情報も含まれています。

� SQL 文の ALTER DATABASE RECOVER MANAGED STANDBY、STARTUP、SHUTDOWN、ARCHIVE LOG、RECOVERなどの管理操作に関連するメッセージ

� ARC0、MRP0、RFS、LGWR などのバックグラウンド・プロセスでレポートされる管理操作に関連するエラー

� 管理操作の完了タイムスタンプ

アラート・ログは、特定のプロセスで生成されたトレース・ファイルまたはダンプ・ファイルに関する情報も提供します。

8.5.2 動的パフォーマンス・ビュー（固定ビュー）動的パフォーマンス・ビュー（固定ビュー）動的パフォーマンス・ビュー（固定ビュー）動的パフォーマンス・ビュー（固定ビュー）Oracle データベースには、基礎となるビューのセットがあります。これらのビューは、データベースがオープン状態および使用中の場合に連続的に更新されるため、動的パフォーマンス・動的パフォーマンス・動的パフォーマンス・動的パフォーマンス・ビュービュービュービューと呼ばれることがあります。その内容は主にパフォーマンスに関連しています。また、これらのビューは、データベース管理者が変更または削除できないので、固定ビュー固定ビュー固定ビュー固定ビューと呼ばれることもあります。

これらのビューの名前には、V$ または GV$ という接頭辞が付き、たとえば V$ARCHIVE_DESTや GV$ARCHIVE_DESTのようになります。

標準の動的パフォーマンス・ビュー（V$ 固定ビュー）には、ローカル・インスタンスの情報が格納されます。それに対して、グローバル動的パフォーマンス・ビュー（GV$ 固定ビュー）には、Real Application Clusters（RAC）のすべてのオープン・インスタンスの情報が格納されます。各 V$ 固定ビューには対応する GV$ 固定ビューがあります。GV$ 固定ビューを選択すると、全インスタンスの情報を取得するために、パラレル問合せのスレーブが使用されます。追加情報は、第 16 章「Oracle Data Guard に関連するビュー」および『Oracle Database リファレンス』を参照してください。

REDO 転送のステータスと進捗 � V$ARCHIVE_DEST_STATUSビュー

� V$ARCHIVED_LOGビュー

� V$ARCHIVE_DEST ビュー


V$ARCHIVED_LOGビュー


データファイルの自動拡張アラート・ログアラート・ログ

OPEN RESETLOGSまたは CLEAR UNARCHIVED LOGFILES文の発行

アラート・ログアラート・ログ

初期化パラメータの変更アラート・ログアラート・ログ

表表表表 8-2 プライマリ・データベースの共通アクションを監視できる場所（続き）プライマリ・データベースの共通アクションを監視できる場所（続き）プライマリ・データベースの共通アクションを監視できる場所（続き）プライマリ・データベースの共通アクションを監視できる場所（続き）

プライマリ・データベース・イベントプライマリ・データベース・イベントプライマリ・データベース・イベントプライマリ・データベース・イベントプライマリ・サイト情報プライマリ・サイト情報プライマリ・サイト情報プライマリ・サイト情報スタンバイ・サイト情報スタンバイ・サイト情報スタンバイ・サイト情報スタンバイ・サイト情報



8.5.3 リカバリの進捗の監視リカバリの進捗の監視リカバリの進捗の監視リカバリの進捗の監視この項では、8.5.2 項で説明した、Data Guard 環境でリカバリの進捗を監視するビューの例をいくつか示します。この項は、次の例で構成されています。

� プロセス・アクティビティの監視

� REDO Apply の進捗の確認

� アーカイブ REDO ログ・ファイルの位置および作成者の確認

� OPEN RESETLOGS の前後のデータベース・インカネーションの表示

� アーカイブ REDO ログ履歴の表示

� スタンバイ・データベースに適用されたログ・ファイルの確認

� スタンバイ・サイトが受信しなかったログ・ファイルの確認

8.5.3.1 プロセス・アクティビティの監視プロセス・アクティビティの監視プロセス・アクティビティの監視プロセス・アクティビティの監視次のプロセスを実行してアクティビティを監視することにより、スタンバイ・データベースでの REDO Apply に関する情報を取得できます。

スタンバイ・データベース・サイトの 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 CONNECTEDARCH ARCH 0 CONNECTEDMRP0 N/A 204 WAIT_FOR_LOGRFS LGWR 204 WRITINGRFS N/A 0 RECEIVING

8.5.3.2 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#---------------- ------------- --------------- ------------1 947 1 945

参照名参照名参照名参照名システム・プロセス名システム・プロセス名システム・プロセス名システム・プロセス名

ARCH ARC0,ARC1,ARC2,…

MRP MRP、MRP0

RFS ORACLE{SID}



8.5.3.3 アーカイブアーカイブアーカイブアーカイブ 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¥ARC00198.001 ARCH 198 YES 30-MAY-02H:¥ORACLE¥ORADATA¥PAYROLL¥STANDBY¥ARC00199.001 ARCH 199 YES 30-MAY-02H:¥ORACLE¥ORADATA¥PAYROLL¥STANDBY¥ARC00200.001 ARCH 200 YES 30-MAY-02H:¥ORACLE¥ORADATA¥PAYROLL¥STANDBY¥ARC00201.001 LGWR 201 YES 30-MAY-02H:¥ORACLE¥ORADATA¥PAYROLL¥STANDBY¥ARC00202.001 ARCH 202 YES 30-MAY-02H:¥ORACLE¥ORADATA¥PAYROLL¥STANDBY¥ARC00203.001 LGWR 203 YES 30-MAY-02

6 rows selected.

8.5.3.4 OPEN RESETLOGS の前後のデータベース・インカネーションの表示の前後のデータベース・インカネーションの表示の前後のデータベース・インカネーションの表示の前後のデータベース・インカネーションの表示スタンバイ・データベースで V$DATABASE_INCARNATIONビューを問い合せ、データベース・インカネーションと RESETLOGS_ID列を監視します。

プライマリ・データベースで OPEN RESETLOGS文が発行される前に、スタンバイ・データベースで次の問合せが発行されたとします。

SQL> SELECT INCARNATION#, RESETLOGS_ID, STATUS FROM V$DATABASE_INCARNATION ;

INCARNATION# RESETLOGS_ID STATUS------------ ------------ ------- 1 509191005 PARENT 2 509275501 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------------ ------- --------- - ---- 509275501 1 1 A YES 509275501 1 2 A YES 509275501 1 3 A YES 509275501 1 4 A YES 509275501 1 5 A YES

5 rows selected.



プライマリ・データベースで OPEN RESETLOGS文が発行され、スタンバイ・データベースが起動されて新規の REDO ブランチで REDO データを受信する前に、スタンバイ・データベースで次の問合せが発行されたとします。

SQL> SELECT INCARNATION#, RESETLOGS_ID, STATUS FROM V$DATABASE_INCARNATION ;

INCARNATION# RESETLOGS_ID STATUS------------ ------------ ------- 1 509191005 PARENT 2 509275501 PARENT 3 509278970 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------------ ------- --------- - --- 509275501 1 1 A YES 509275501 1 2 A YES 509275501 1 3 A YES 509275501 1 4 A YES 509275501 1 5 A YES 509278970 1 1 A YES 509278970 1 2 A YES 509278970 1 3 A YES8 rows selected.

8.5.3.5 アーカイブアーカイブアーカイブアーカイブ 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#--------- ------------- ------------ ----------13-MAY-02 190578 214480 113-MAY-02 214480 234595 213-MAY-02 234595 254713 3...30-MAY-02 3418615 3418874 20130-MAY-02 3418874 3419280 20230-MAY-02 3419280 3421165 203203 rows selected.

8.5.3.6 スタンバイ・データベースに適用されたログ・ファイルの確認スタンバイ・データベースに適用されたログ・ファイルの確認スタンバイ・データベースに適用されたログ・ファイルの確認スタンバイ・データベースに適用されたログ・ファイルの確認スタンバイ・データベースで 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------- ---------------- 1 967

この例では、ログ順序番号 967 のアーカイブ REDO ログ・ファイルが新の適用済ログ・ファイルです。



また、スタンバイ・データベースで V$ARCHIVED_LOG固定ビューの APPLIED列を使用すると、スタンバイ・データベースに適用されたログ・ファイルを識別できます。次に例を示します。

SQL> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG; THREAD# SEQUENCE# APP ---------- ---------- --- 1 2 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.

8.5.3.7 スタンバイ・サイトが受信しなかったログ・ファイルの確認スタンバイ・サイトが受信しなかったログ・ファイルの確認スタンバイ・サイトが受信しなかったログ・ファイルの確認スタンバイ・サイトが受信しなかったログ・ファイルの確認各アーカイブ先には、割り当てられた宛先 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# ---------- ---------- 1 12 1 13 1 14

この例には、スタンバイ宛先 2 が受信しなかったログ・ファイルが示されています。



8.5.4 フィジカル・スタンバイ・データベースでのログ適用サービスの監視フィジカル・スタンバイ・データベースでのログ適用サービスの監視フィジカル・スタンバイ・データベースでのログ適用サービスの監視フィジカル・スタンバイ・データベースでのログ適用サービスの監視フィジカル・スタンバイ・データベースのログ適用サービスの状況を監視するには、この項で説明する固定ビューを問い合せます。スタンバイ・データベースは、Oracle Enterprise Manager GUI を使用して監視することもできます。


� V$DATABASE ビューへのアクセス

� V$MANAGED_STANDBY 固定ビューへのアクセス

� V$ARCHIVE_DEST_STATUS 固定ビューへのアクセス

� V$ARCHIVED_LOG 固定ビューへのアクセス

� V$LOG_HISTORY 固定ビューへのアクセス

� V$DATAGUARD_STATUS 固定ビューへのアクセス

また、ビューの詳細は、『Oracle Database リファレンス』を参照してください。

8.5.4.1 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;

8.5.4.2 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 1 947 72 72MRP0 APPLYING_LOG 1 946 10 72

この問合せ出力は、RFS プロセスが REDO ログ・ファイル順序番号 947 のアーカイブを完了したことを示しています。また、この出力は、REDO Apply がアーカイブ REDO ログ・ファイル順序番号 946 を適用していることも示しています。このリカバリ操作では現在、72 ブロックのアーカイブ REDO ログ・ファイルのブロック番号 10 をリカバリしている中です。



8.5.4.3 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#---------------- ------------- --------------- ------------1 947 1 945

この問合せ出力は、スタンバイ・データベースが、プライマリ・データベースからアーカイブ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

8.5.4.4 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 1 945 74651 74739RFS ARCH 1 946 74739 74772RFS ARCH 1 947 74772 74774

この問合せ出力は、プライマリ・データベースから受信した 3 つのアーカイブ REDO ログ・ファイルを示しています。

8.5.4.5 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#---------- ---------- ------------- ------------1 945 74651 74739

この問合せ出力は、も近適用されたアーカイブ REDO ログ・ファイルが順序番号 945 であったことを示しています。



8.5.4.6 V$DATAGUARD_STATUS 固定ビューへのアクセス固定ビューへのアクセス固定ビューへのアクセス固定ビューへのアクセスV$DATAGUARD_STATUS固定ビューには、通常はアラート・ログまたはサーバー・プロセスのトレース・ファイルへのメッセージによってトリガーされるイベントが表示されます。

次の例は、プライマリ・データベースでの V$DATAGUARD_STATUSビューの出力を示します。

SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;

MESSAGE--------------------------------------------------------------------------------ARC0: Archival startedARC1: Archival startedArchivelog destination LOG_ARCHIVE_DEST_2 validated for no-data-lossrecoveryCreating archive destination LOG_ARCHIVE_DEST_2: 'dest2'ARCH: Transmitting activation ID 0LGWR: Completed archiving log 3 thread 1 sequence 11Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2'LGWR: Transmitting activation ID 6877c1feLGWR: Beginning to archive log 4 thread 1 sequence 12ARC0: Evaluating archive log 3 thread 1 sequence 11ARC0: Archive destination LOG_ARCHIVE_DEST_2: Previously completedARC0: Beginning to archive log 3 thread 1 sequence 11Creating archive destination LOG_ARCHIVE_DEST_1:'/oracle/arch/arch_1_11.arc'ARC0: Completed archiving log 3 thread 1 sequence 11ARC1: Transmitting activation ID 6877c1fe15 rows selected.

次の例は、フィジカル・スタンバイ・データベースでの V$DATAGUARD_STATUSビューの内容を示します。

SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;

MESSAGE--------------------------------------------------------------------------------ARC0: Archival startedARC1: Archival startedRFS: Successfully opened standby logfile 6: '/oracle/dbs/sorl2.log'ARC1: Evaluating archive log 6 thread 1 sequence 11ARC1: Beginning to archive log 6 thread 1 sequence 11Creating archive destination LOG_ARCHIVE_DEST_1:'/oracle/arch/arch_1_11.arc'ARC1: Completed archiving log 6 thread 1 sequence 11RFS: Successfully opened standby logfile 5: '/oracle/dbs/sorl1.log'Attempt to start background Managed Standby Recovery processMedia Recovery Log /oracle/arch/arch_1_9.arc

10 rows selected.


フィジカル・スタンバイ・データベースに関するログ適用レートのチューニング

8.6 フィジカル・スタンバイ・データベースに関するログ適用フィジカル・スタンバイ・データベースに関するログ適用フィジカル・スタンバイ・データベースに関するログ適用フィジカル・スタンバイ・データベースに関するログ適用レートのチューニングレートのチューニングレートのチューニングレートのチューニング

次の方法を使用して、フィジカル・スタンバイ・データベースに対する REDO 適用の所要時間を適化することを考慮してください。詳細は、URL http://otn.oracle.com/deploy/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 を使用すると、データベース・ファイルのパラレル読取りが大幅に減少し、リカバリ時間全体が短縮されます。


フィジカル・スタンバイ・データベースに関するログ適用レートのチューニング


ロジカル・スタンバイ・データベースの

9
ロジカル・スタンバイ・データベースの管理ロジカル・スタンバイ・データベースの管理ロジカル・スタンバイ・データベースの管理ロジカル・スタンバイ・データベースの管理
この章は、次の項目で構成されています。

� SQL Apply アーキテクチャの概要

� ロジカル・スタンバイ・データベースの管理および監視関連のビュー

� ロジカル・スタンバイ・データベースの監視

� ロジカル・スタンバイ・データベースのカスタマイズ

� ロジカル・スタンバイ・データベースのコンテキストにおける特定のワークロードの管理

� ロジカル・スタンバイ・データベースのチューニング

管理 9-1

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）では、次の操作が実行されます。

– トランザクションの割当て

– トランザクション間の依存性の監視と、スケジュールの調整

– ロジカル・スタンバイ・データベースに対する変更のコミットの認可



� APPLIERプロセスでは、次の操作が実行されます。

– データベースに対する LCR の適用

– COORDINATORプロセスに対する、依存性が解決されていないトランザクションの承認の要求

– トランザクションのコミット

V$LOGSTDBY_PROCESSビューを問い合せると、SQL Apply プロセスのアクティビティを検査できます。現行のアクティビティに関する情報は、V$LOGSTDBY_STATSビューでも提供されます。このビューには、SQL Apply アクティビティ中のロジカル・スタンバイ・データベースに関する統計、現在の状態およびステータス情報が表示されます。この 2 つのビューと他の関連ビューの詳細は、9.2 項「ロジカル・スタンバイ・データベースの管理および監視関連のビュー」を参照してください。

9.1.1 SQL Apply に関する各種の考慮事項に関する各種の考慮事項に関する各種の考慮事項に関する各種の考慮事項この項は、次の項目で構成されています。

� トランザクション・サイズの考慮事項

� ページアウトの考慮事項

� 再開の考慮事項

� DML 適用の考慮事項

� DDL 適用の考慮事項

9.1.1.1 トランザクション・サイズの考慮事項トランザクション・サイズの考慮事項トランザクション・サイズの考慮事項トランザクション・サイズの考慮事項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


9.1.1.2 ページアウトの考慮事項ページアウトの考慮事項ページアウトの考慮事項ページアウトの考慮事項LCR キャッシュのメモリーがすべて使用され、SQL Apply を進捗させるために領域の解放が必要になると、SQL Apply のコンテキスト内でページアウトが発生します。

たとえば、LCR キャッシュに 100MB のメモリーが割り当てられている場合に、SQL Apply でサイズが 300MB の LONG列を含む表に対する INSERTトランザクションが検出されるとします。この場合、ログ・マイニング・コンポーネントは、LONGデータの初の部分をページアウトして列変更の後半部分を読み取ります。適切にチューニングされているロジカル・スタンバイ・データベースの場合、ページアウト・アクティビティはほとんど発生せず、システム全体のスループットには影響しません。

9.1.1.3 再開の考慮事項再開の考慮事項再開の考慮事項再開の考慮事項トランザクションのコミット・レコードが 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はワークロードの存続期間中は進行しなくなります。

9.1.1.4 DML 適用の考慮事項適用の考慮事項適用の考慮事項適用の考慮事項SQL Apply がロジカル・スタンバイ・データベースのスループットと待機時間に影響するDML トランザクションを適用する場合、次の特性があります。

� 1 つの文で複数の行が変更されるバッチ更新または削除をプライマリ・データベースで実行した場合、ロジカル・スタンバイ・データベースでは行の個別変更として適用されます。そのため、保守されている各表に一意キーまたは主キーが必要になります。詳細は、4.1.2項「プライマリ・データベース内の表の行が一意に識別できることの確認」を参照してください。

� プライマリ・データベースで実行されたダイレクト・パス・インサートは、ロジカル・スタンバイ・データベースで従来型の INSERT文を使用して適用されます。

� パラレル DML（PDML）トランザクションは、ロジカル・スタンバイ・データベースではパラレルに実行されません。

関連項目関連項目関連項目関連項目 : 問題のあるページアウトを識別して対処措置を実行する方法の詳細は、9.4 項「ロジカル・スタンバイ・データベースのカスタマイズ」を参照してください。


ロジカル・スタンバイ・データベースの管理および監視関連のビュー

9.1.1.5 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 ビュー

9.2.1 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の順で列を選択してください。この順序によって、停止障害がビューの後に表示されます。



このビューには、適用された DDL 文やスキップされた DDL トランザクションなどの他の情報も表示されます。次に例を示します。

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS';Session altered.SQL> COLUMN STATUS FORMAT A60SQL> SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS 2 ORDER BY EVENT_TIMESTAMP, COMMIT_SCN;

EVENT_TIME STATUS------------------------------------------------------------------------------EVENT-------------------------------------------------------------------------------23-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_inst7 rows selected.

この問合せは、SQL Apply の開始と停止が数回繰り返されたことを示しています。適用されたDDL とスキップされた DDL も示しています。SQL Apply が停止した場合は、問合せの後のレコードに問題の原因が表示されます。

9.2.2 DBA_LOGSTDBY_LOG ビュービュービュービューDBA_LOGSTDBY_LOGビューには、SQL Apply で処理中のアーカイブ・ログに関する動的な情報が表示されます。


SQL> COLUMN DICT_BEGIN FORMAT A10;SQL> SET NUMF 9999999SQL> 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 2 101579 101588 11:02:58 NO NO 1 YES/oracle/dbs/hq_nyc_3.log 3 101588 142065 11:02:02 NO NO 1 YES/oracle/dbs/hq_nyc_4.log 4 142065 142307 11:02:10 NO NO 1 YES/oracle/dbs/hq_nyc_5.log 5 142307 142739 11:02:48 YES YES 1 YES/oracle/dbs/hq_nyc_6.log 6 142739 143973 12:02:10 NO NO 1 YES/oracle/dbs/hq_nyc_7.log 7 143973 144042 01:02:11 NO NO 1 YES/oracle/dbs/hq_nyc_8.log 8 144042 144051 01:02:01 NO NO 1 YES/oracle/dbs/hq_nyc_9.log 9 144051 144054 01:02:16 NO NO 1 YES/oracle/dbs/hq_nyc_10.log 10 144054 144057 01:02:21 NO NO 1 YES/oracle/dbs/hq_nyc_11.log 11 144057 144060 01:02:26 NO NO 1 CURRENT/oracle/dbs/hq_nyc_12.log 12 144060 144089 01:02:30 NO NO 1 CURRENT/oracle/dbs/hq_nyc_13.log 13 144089 144147 01:02:41 NO NO 1 NO

この問合せ出力は、LogMiner ディクショナリの作成がログ・ファイルの順序番号 5 で開始したことを示しています。新のアーカイブ REDO ログ・ファイルは順序番号 13 で、ロジカル・スタンバイ・データベースでは 1 時 2 分 41 秒に受信されています。

APPLIED列は、SQL Apply により SCN 144057 までの REDO がすべて適用されたことを示しています。トランザクションでは複数のアーカイブ・ログ・ファイルを使用している場合があるため、複数のアーカイブ・ログ・ファイルの APPLIED列に値 CURRENTが表示されることがあります。



9.2.3 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 00:00:00.1 07-APR-2005 08:29:23lag time +00 00:00:00.1 07-APR-2005 08:29:23potential data loss +00 00:00:00 07-APR-2005 08:29:23

表示される各列の単位（メトリック）は、日（2）から秒（1）までの間隔です。この出力は、ロジカル・スタンバイ・データベースがプライマリ・データベースと 0.1 秒以内に一致することと、プライマリ・データベースに障害が発生した場合もデータ消失が発生しないことを示しています。

9.2.4 V$LOGSTDBY_PROCESS ビュービュービュービューこのビューには、次のように、SQL Apply 関連の各種プロセスの現在の状態に関する情報が表示されます。

� 識別情報（sid | serial# | spid）

� SQL Apply プロセス : COORDINATOR、READER、BUILDER、PREPARER、ANALYZERまたは APPLIER（type）

� プロセスの現行のアクティビティのステータス（status_code | status）

� このプロセスで処理された上位の REDO レコード（high_scn）


SQL> COLUMN LID FORMAT 9999SQL> COLUMN SERIAL# FORMAT 9999SQL> COLUMN SID FORMAT 9999SQL> SELECT SID, SERIAL#, LOGSTDBY_ID AS LID, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL# LID SPID TYPE HIGH_SCN ----- ------- ----- ------------ ---------------- ---------- 48 6 -1 11074 COORDINATOR 7178242899 56 56 0 10858 READER 7178243497 46 1 1 10860 BUILDER 7178242901 45 1 2 10862 PREPARER 7178243295 37 1 3 10864 ANALYZER 7178241034 36 1 4 10866 APPLIER 7178239467 35 3 5 10868 APPLIER 7178239463 34 7 6 10870 APPLIER 7178239461 33 1 7 10872 APPLIER 7178239472 9 rows selected.

HIGH_SCN列は、READER プロセスが他のすべてのプロセスに先行することと、PREPARERおよび BUILDERプロセスが残りのプロセスに先行することを示しています。

関連項目関連項目関連項目関連項目 : 『Oracle Database リファレンス』の V$LOGSTDBY_STATSビューに関する項



SQL> COLUMN STATUS FORMAT A40SQL> SELECT TYPE, STATUS_CODE, STATUS FROM V$LOGSTDBY_PROCESS; TYPE STATUS_CODE STATUS---------------- ----------- -----------------------------------------COORDINATOR 16117 ORA-16117: 処理中です。READER 16127 ORA-16127: 追加のトランザクションが適用されるまで

待機して停止しました。BUILDER 16116 ORA-16116: 使用できる作業はありません

PREPARER 16116 ORA-16117: 処理中です。ANALYZER 16120 ORA-16120: SCN 0x0001.abdb440aでの

トランザクションに対する依存性を計算中です。APPLIER 16124 ORA-16124: トランザクション 1 13 1427 は待機中です。

APPLIER 16121 ORA-16121: コミット SCN 0x0001.abdb4390にトランザクションを適用していますAPPLIER 16123 ORA-16123: トランザクション 1 23 1231 はコミットの認証を待機中ですAPPLIER 16116 ORA-16116: 使用できる作業はありません

出力は、実行中の SQL Apply のスナップショットを示しています。マイニング側では、READERプロセスはさらに読み取れるように追加のメモリーが使用可能になるまで待機中で、PREPARERプロセスは REDO レコードの処理中、BUILDERプロセスに使用可能な処理はありません。適用側では、COORDINATORは APPLIERプロセスにさらにトランザクションを割当中で、ANALYZERは SCN 7178241034 で依存性を計算中、APPLIERの 1 つは使用可能な処理がなく、2 つにはまだ満たされていない未処理の依存性があります。

9.2.5 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----------- ----------- ---------- ----------- 7178240496 7178240507 7178240507 7178219805

この出力は次のことを示しています。

� SQL Apply により、SCN 7178240496 以前にコミットされた全トランザクションが適用されました。

� ロジカル・スタンバイ・データベースで受信された新 REDO レコードは、SCN 7178240507 で生成されました。

� マイニング・コンポーネントにより、SCN 7178240507 以前に生成された全 REDO レコードが処理されました。

関連項目関連項目関連項目関連項目 : リファレンス情報については『Oracle Database リファレンス』の V$LOGSTDBY_PROCESSビューに関する項、出力例については 9.3.1 項

「SQL Apply の進捗の監視」を参照してください。



� SQL Apply がなんらかの理由で停止されて再開されると、SCN 7178219805 以降に生成された 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 ----------------- ----------------- ----------------- -----------------05-05-12 10:38:21 05-05-12 10:41:21 05-05-12 10:41:53 05-05-12 10:09:30

この出力は次のことを示しています。

� SQL Apply により、時刻 05-05-12 10:38:21 以前にコミットされた全トランザクションが適用されました（APPLIED_TIME）。

� 後の REDO は、プライマリ・データベースで時刻 05-05-12 10:41:53 に生成されました（LATEST_TIME）。

� マイニング・エンジンにより、05-05-12 10:41:21 以前に生成された全 REDO レコードが処理されました（MINING_TIME）。

� SQL Apply の再開時には、05-05-12 10:09:30 以後に生成された REDO レコードのマイニングが開始されます。

9.2.6 V$LOGSTDBY_STATE ビュービュービュービューこのビューには、次のように、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 a15SQL> COLUMN STATE FORMAT a16SQL> SELECT * FROM V$LOGSTDBY_STATE;

PRIMARY_DBID SESSION_ID REALTIME_APPLY STATE------------ ---------- --------------- ---------------- 1562626987 1 Y APPLYING

この出力は、SQL Apply がリアルタイム適用モードで実行中で、現在はプライマリ・データベースから受信した REDO データを適用中であり、プライマリ・データベースの DBIDが1562626987 で、SQL Apply セッションに関連付けられている LogMiner セッション ID が 1 であることを示しています。

関連項目関連項目関連項目関連項目 : リファレンス情報については『Oracle Database リファレンス』の V$DATAGUARD_PROGRESSビューに関する項、出力例については 9.3.1 項

「SQL Apply の進捗の監視」を参照してください。

関連項目関連項目関連項目関連項目 : リファレンス情報については『Oracle Database リファレンス』の V$LOGSTDBY_STATEビューに関する項、出力例については 9.3.1 項「SQL Apply の進捗の監視」を参照してください。



9.2.7 V$LOGSTDBY_STATS ビュービュービュービューこのビューには、SQL Apply 統計が表示されます。


SQL> COLUMN NAME FORMAT a32SQL> COLUMN VALUE FORMAT a32SQL> SELECT * FROM V$LOGSTDBY_STATS; NAME VALUE-------------------------------- --------------------------------number of preparers 1number of appliers 4maximum SGA for LCR cache 30parallel servers in use 8maximum events recorded 1000preserve commit order TRUErecord skip errors Yrecord skip DDL Yrecord applied DDL Nrecord unsupported operations Ncoordinator state APPLYINGtransactions ready 132412transactions applied 132118coordinator uptime 132102realtime logmining Yapply delay 0Log Miner session ID 1bytes of redo processed 130142100140txns delivered to client 131515DML txns delivered 128DDL txns delivered 23CTAS txns delivered 0Recursive txns delivered 874Rolled back txns seen 40LCRs delivered to client 2246414bytes paged out 0secs spent in pageout 0bytes checkpointed 0secs spent in checkpoint 0bytes rolled back 0secs spent in rollback 0secs system is idle 2119 32 rows selected.

関連項目関連項目関連項目関連項目 : 『Oracle Database リファレンス』の V$LOGSTDBY_STATSビューに関する項


ロジカル・スタンバイ・データベースの監視

9.3 ロジカル・スタンバイ・データベースの監視ロジカル・スタンバイ・データベースの監視ロジカル・スタンバイ・データベースの監視ロジカル・スタンバイ・データベースの監視この項は、次の項目で構成されています。

� SQL Apply の進捗の監視

� ログ・ファイルの自動削除

9.3.1 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---------- -------------1 INITIALIZING

SESSION_ID列は、SQL Apply により作成された永続 LogMiner セッションを示します。このセッションで、プライマリ・データベースで生成されたアーカイブ REDO ログ・ファイルがマイニングされます。

ディクショナリ・ログ待機中ディクショナリ・ログ待機中ディクショナリ・ログ待機中ディクショナリ・ログ待機中

SQL Apply は、初回の開始時に、REDO ログ・ファイルで取得された LogMiner マルチバージョン・データ・ディクショナリをロードする必要があります。 SQL Apply は、LogMiner マルチバージョン・データ・ディクショナリのロードに必要な REDO データをすべて受信するまで、WAITING FOR DICTIONARY LOGS状態にとどまります。



ディクショナリ・ロード中状態ディクショナリ・ロード中状態ディクショナリ・ロード中状態ディクショナリ・ロード中状態

ディクショナリ・ロード中状態は、しばらく継続する場合があります。大型データベースでLogMiner マルチバージョン・データ・ディクショナリをロードするには、長時間かかることがあります。 V$LOGSTDBY_STATEビューを問い合せると、ディクショナリのロード中は次の出力が戻されます。

SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;

SESSION_ID STATE---------- ------------------1 LOADING DICTIONARY

LogMiner ディクショナリが完全にロードされるまでに起動されるのは、COORDINATORプロセスとマイニング・プロセスのみです。したがって、この時点で V$LOGSTDBY_PROCESSを問い合せると、APPLIERプロセスは表示されません。次に例を示します。

SQL> SELECT SID, SERIAL#, SPID, TYPE FROM V$LOGSTDBY_PROCESS;

SID SERIAL# SPID TYPE------ --------- --------- ---------------------47 3 11438 COORDINATOR50 7 11334 READER45 1 11336 BUILDER44 2 11338 PREPARER43 2 11340 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------------- -------------------------------40 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 トランザクションの進捗を監視してください。



適用中状態適用中状態適用中状態適用中状態

この状態では、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-------------------- ----------- -------------------- -----------10-JAN-2005 12:00:05 346791023 10-JAN-2005 12:10:05 3468810134

プライマリ・データベース上で 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.3.2 ログ・ファイルの自動削除ログ・ファイルの自動削除ログ・ファイルの自動削除ログ・ファイルの自動削除SQL Apply では、不要になったアーカイブ REDO ログ・ファイルが自動的に削除されます。

次の PL/SQL プロシージャを実行すると、この動作をオーバーライドできます。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', FALSE);

ロジカル・スタンバイ・データベースでアーカイブ 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_509538672.log /boston/arc_dest/arc_1_41_509538672.log /boston/arc_dest/arc_1_42_509538672.log /boston/arc_dest/arc_1_43_509538672.log /boston/arc_dest/arc_1_44_509538672.log /boston/arc_dest/arc_1_45_509538672.log /boston/arc_dest/arc_1_46_509538672.log /boston/arc_dest/arc_1_47_509538672.log

3. オペレーティング・システム固有のコマンドを使用して、問合せにより表示されたアーカイブ REDO ログ・ファイルを削除します。

注意注意注意注意 : デフォルトでは、不要になったアーカイブ REDO ログ・ファイルはSQL Apply により削除されます。ロジカル・スタンバイ・データベースをフラッシュバックすると、アーカイブ REDO ログ・ファイルが SQL Apply メタデータには存在しますが（DBA_LOGSTDBY_LOGSビューに反映）、ファイル・システムには存在しない状態になる場合があります。フラッシュバック・データベース操作後に SQL Apply を再開すると、失敗してアラート・ログに次のエラーが記録される場合があります。

Errors in file /home/oracle/DGR2/logical/stdl/bdump/stdl_lsp0_11310.trc:ORA-00308: アーカイブ・ログ '/home/oracle/DGR2/logical/stdl/stlog/1_15_559399019.dbf'をオープンできません。ORA-27037: ファイル・ステータスを取得できません。

自動削除ポリシーにより削除されたアーカイブ REDO ログ・ファイルを適切なディレクトリにコピーし、SQL Apply を再開する必要があります。


ロジカル・スタンバイ・データベースのカスタマイズ

9.4 ロジカル・スタンバイ・データベースのカスタマイズロジカル・スタンバイ・データベースのカスタマイズロジカル・スタンバイ・データベースのカスタマイズロジカル・スタンバイ・データベースのカスタマイズこの項は、次の項目で構成されています。

� ロジカル・スタンバイ・データベースでのリアルタイム適用の使用

� DBA_LOGSTDBY_EVENTS ビューでのイベントのロギングのカスタマイズ

� DBMS_LOGSTDBY.SKIP による特定のスキーマ・オブジェクトに対する変更の防止

� DDL 文のスキップ・ハンドラの設定

� ロジカル・スタンバイ・データベースの変更

� ロジカル・スタンバイ・データベースでの表の追加または再作成

9.4.1 ロジカル・スタンバイ・データベースでのリアルタイム適用の使用ロジカル・スタンバイ・データベースでのリアルタイム適用の使用ロジカル・スタンバイ・データベースでのリアルタイム適用の使用ロジカル・スタンバイ・データベースでのリアルタイム適用の使用デフォルトでは、Data Guard はいっぱいになったアーカイブ REDO ログ・ファイルがスタンバイ・データベースで受信されるのを待機してから、スタンバイ・データベースに適用します。ただし、スタンバイ REDO ログをスタンバイ・データベースで構成している場合、オプションでリアルタイム適用を使用可能にできます。リアルタイム適用を使用可能にすると、SQL Apply では、ログ・ファイルが書き込まれるのと同時にスタンバイ REDO ログ・ファイルからREDO データが適用されます。これは、ログ・スイッチが発生する場合とは逆になります。このような方法でスタンバイ REDO ログ・ファイルを即時に適用することにより、スタンバイREDO ログ・ファイルをスタンバイ・サイトでアーカイブする必要なしに、ロジカル・スタンバイ・データベースの内容をプライマリ・データベースの内容とかぎりなく一致させることができます。この結果、スイッチオーバーとフェイルオーバーをより迅速に実行できます。

ロジカル・スタンバイ・データベースでリアルタイム適用を開始するには、次の文を発行します。


SQL Apply をリアルタイム適用モードで実行することをお薦めします。スタンバイ REDO ログの構成の詳細は、3.1.3 項「スタンバイ REDO ログの構成」も参照してください。

9.4.2 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の順で列を選択してください。この順序によって、停止障害がビューの後に表示されます。

関連項目関連項目関連項目関連項目 : 『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』の DBMS_LOGSTDBYパッケージに関する項



9.4.3 DBMS_LOGSTDBY.SKIP による特定のスキーマ・オブジェクトに対するによる特定のスキーマ・オブジェクトに対するによる特定のスキーマ・オブジェクトに対するによる特定のスキーマ・オブジェクトに対する変更の防止変更の防止変更の防止変更の防止

デフォルトでは、プライマリ・データベース内でサポートされる表は、すべてロジカル・スタンバイ・データベースで複製されます。このデフォルト動作は、特定の表に対する変更の適用をスキップするルールを指定することで変更できます。たとえば、HR.EMPLOYEES表に対する変更を省略するには、特定の表に対する DML 変更と DDL 変更の適用を防止するルールを指定できます。次に例を示します。

1. SQL 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 を開始します。


9.4.4 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;



EXCEPTION WHEN OTHERS THEN ACTION := DBMS_LOGSTDBY.SKIP_ACTION_ERROR; NEW_STMT := NULL;END HANDLE_TBS_DDL;



3. スキップ・プロシージャを SQL Apply に登録します。

SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'TABLESPACE', - proc_name => 'sys.handle_tbs_ddl');



9.4.5 ロジカル・スタンバイ・データベースの変更ロジカル・スタンバイ・データベースの変更ロジカル・スタンバイ・データベースの変更ロジカル・スタンバイ・データベースの変更デフォルトでは、ロジカル・スタンバイ・データベースはデータベース・ガードが ALL（も限定的な設定）に設定されている状態で作動し、ユーザーはデータベースに対して変更を実行できません。データベース・ガードを無視して、ロジカル・スタンバイ・データベースを変更可能にするには、ALTER SESSION DISABLE GUARD文を実行します。権限を付与されているユーザーは、この文を発行して、現行のセッションでデータベース・ガードをオフにできます。

次の各項で、例を示します。これらの例では、データベース・ガードが ALLまたは STANDBYに設定されていると仮定しています。

9.4.5.1 ロジカル・スタンバイ・データベースでのロジカル・スタンバイ・データベースでのロジカル・スタンバイ・データベースでのロジカル・スタンバイ・データベースでの 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.4.5.2 SQL Apply でメンテナンスされていない表の変更でメンテナンスされていない表の変更でメンテナンスされていない表の変更でメンテナンスされていない表の変更場合によっては、レポート生成アプリケーションが、要約した結果を収集してその結果を一時的に格納したり、レポートが実行された回数を追跡する必要があります。アプリケーションの主な目的はレポート・アクティビティを実行することですが、ロジカル・スタンバイ・データベースに対して DML（挿入、更新および削除）操作の発行が必要な場合があります。さらに、アプリケーションで表の作成や削除が必要になることもあります。

データが SQL Apply を介してメンテナンスされていない場合は、レポート生成操作でデータを変更できるように、データベース・ガードを設定できます。次の設定を行う必要があります。

� DBMS_LOGSTDBY.SKIPプロシージャを実行して、アプリケーションによるデータの書込みを可能にする、ロジカル・スタンバイ・データベース上の表のセットを指定します。スキップされた表は、SQL Apply でメンテナンスされません。

� スタンバイ表のみを保護するようにデータベース・ガードを設定します。

次の例では、レポートによって書込みが行われる表がプライマリ・データベース上にあると仮定しています。

この例では、変更をロジカル・スタンバイ・データベースに適用できるように、SQL Apply を停止し、表をスキップした後、SQL Apply を再開しています。この操作によって、レポート生成アプリケーションは、MYSCHEMAの MYTABLES%に書込みができるようになります。スキップされた表は、SQL Apply でメンテナンスされません。


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.4.6 ロジカル・スタンバイ・データベースでの表の追加または再作成ロジカル・スタンバイ・データベースでの表の追加または再作成ロジカル・スタンバイ・データベースでの表の追加または再作成ロジカル・スタンバイ・データベースでの表の追加または再作成通常、リカバリ不能な操作の後に表を再作成するには、表のインスタンス化を使用します。また、プロシージャを使用して、以前はスキップしていた表に対する SQL Apply を使用可能にすることもできます。

表を作成する前に、4.1.2 項「プライマリ・データベース内の表の行が一意に識別できることの確認」に記載されている要件を満たす必要があります。その後、次の手順に従って表HR.EMPLOYEESを再作成し、SQL Apply を再開できます。この手順は、プライマリ・データベースにアクセスするデータベース・リンク BOSTONが定義済であることを前提としています。

次のリストは、表を再作成し、その表に対して SQL Apply を再開する方法を示しています。



2. DBA_LOGSTDBY_SKIPビューを問い合せ、問題の表で操作がスキップされていないことを確認します。

SQL> SELECT * FROM DBA_LOGSTDBY_SKIP;ERROR STATEMENT_OPT OWNER NAME PROC----- ------------------- ------------- ---------------- -----N SCHEMA_DDL HR EMPLOYEESN DML HR EMPLOYEESN SCHEMA_DDL OE TEST_ORDERN 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');



関連項目関連項目関連項目関連項目 : DBMS_LOGSTDBY.UNSKIPおよび DBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャについては、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。


ロジカル・スタンバイ・データベースのコンテキストにおける特定のワークロードの管理

新規にインスタンス化された表とデータベースの残りの部分にまたがってビューの一貫性が得られるように、SQL Apply がプライマリ・データベースと一致するまで待機してから、この表を問い合せます。手順は次のとおりです。

1. プライマリ・データベースで、V$DATABASEビューを問い合せて現在の SCN を判別します。

SQL> SELECT CURRENT_SCN FROM V$DATABASE@BOSTON;CURRENT_SCN---------------------345162788

2. 前の問合せで戻された CURRENT_SCNより前のコミット済のトランザクションがすべて、SQL Apply により適用されていることを確認します。

SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS;

APPLIED_SCN--------------------------345161345

この問合せで戻された APPLIED_SCNが初の問合せで戻された CURRENT_SCNよりも大きい場合は、新規に再作成された表を問い合せても安全です。

9.5 ロジカル・スタンバイ・データベースのコンテキストにおけるロジカル・スタンバイ・データベースのコンテキストにおけるロジカル・スタンバイ・データベースのコンテキストにおけるロジカル・スタンバイ・データベースのコンテキストにおける特定のワークロードの管理特定のワークロードの管理特定のワークロードの管理特定のワークロードの管理


� プライマリ・データベースへのトランスポータブル表領域のインポート

� マテリアライズド・ビューの使用

� ロジカル・スタンバイ・データベースでのトリガーと制約の処理方法

� OPEN RESETLOGS 文を使用したリカバリ

9.5.1 プライマリ・データベースへのトランスポータブル表領域のインポートプライマリ・データベースへのトランスポータブル表領域のインポートプライマリ・データベースへのトランスポータブル表領域のインポートプライマリ・データベースへのトランスポータブル表領域のインポート表領域をプライマリ・データベースにインポートする手順は、次のとおりです。

1. ロジカル・スタンバイ・データベースを変更できるように、ガード設定を無効にします。

SQL> ALTER SESSION DISABLE GUARD;

2. ロジカル・スタンバイ・データベースで表領域をインポートします。

3. データベース・ガード設定を有効にします（または、セッションから切断します）。

SQL> ALTER SESSION ENABLE GUARD;

4. プライマリ・データベースで表領域をインポートします。



9.5.2 マテリアライズド・ビューの使用マテリアライズド・ビューの使用マテリアライズド・ビューの使用マテリアライズド・ビューの使用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プロシージャを使用してリフレッシュする必要があります。

9.5.3 ロジカル・スタンバイ・データベースでのトリガーと制約の処理方法ロジカル・スタンバイ・データベースでのトリガーと制約の処理方法ロジカル・スタンバイ・データベースでのトリガーと制約の処理方法ロジカル・スタンバイ・データベースでのトリガーと制約の処理方法デフォルトでは、トリガーと制約はロジカル・スタンバイ・データベースで自動的に使用可能になり、処理されます。スタンバイ・データベースの場合、トリガーと制約は使用可能ですが、次に示すように実行はされません。

SQL Apply でメンテナンスされる表にトリガーおよび制約がある場合 :

� 制約 : CHECK 制約はプライマリ・データベースで評価されます。ロジカル・スタンバイ・データベースでの再評価は不要です。

� トリガー : プライマリ・データベースで実行されたトリガーの影響は、スタンバイ・データベースでログに記録され、適用されます。

SQL Apply でメンテナンスされない表にトリガーおよび制約がある場合 :

� 制約は評価されます。

� トリガーは発行されます。



9.5.4 OPEN RESETLOGS 文を使用したリカバリ文を使用したリカバリ文を使用したリカバリ文を使用したリカバリロジカル・スタンバイ・データベースが REDO データの新規ブランチを受信すると、SQL Apply ではそれが自動的に使用されます。ロジカル・スタンバイ・データベースの場合、スタンバイ・データベースにより新規リセットログの SCN より後（REDO データの新規ブランチの開始より後）の REDO データが適用されていなければ、手動による介入は必要ありません。次の表に、スタンバイ・データベースとプライマリ・データベースのブランチを再同期化する方法を示します。

データベース・インカネーション、OPEN RESETLOGS操作を介したリカバリおよびフラッシュバック・データベースの詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

スタンバイ・データベースの状態スタンバイ・データベースの状態スタンバイ・データベースの状態スタンバイ・データベースの状態操作操作操作操作実行する手順実行する手順実行する手順実行する手順


（REDO データの新規ブランチの

開始より後）の REDO データが適用

されていない場合。

SQL Apply は、自動的に

REDO データの新規ブランチ

を使用します。

手動による介入は必要ありません。ロジカル・

スタンバイ・プロセス（LSP）は、自動的にス

タンバイ・データベースを REDO データの新規

ブランチと再同期化します。




され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっている場合。

スタンバイ・データベースは、REDO データの将来の新規ブ

ランチでリカバリされます。

1. 12.5.2 項「プライマリのフラッシュバック

後のロジカル・スタンバイ・データベースのフラッシュバック」の手順に従ってロジカル・スタンバイ・データベースをフラッシュ・バックします。

2. SQL Apply を再開し、新規リセットログ・

ブランチへの REDO の適用を続行します。

LSP は、自動的にスタンバイ・データベースを

新規ブランチと再同期化します。




され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっていない場合。

指定のプライマリ・データベース・ブランチで、プライマリ・データベースとスタンバイの内容にずれが生じます。

第 4 章「ロジカル・スタンバイ・データベース

の作成」の手順に従ってロジカル・スタンバイ・データベースを再作成します。

REDO データの新規ブランチから

介入するアーカイブ REDO ログ・

ファイルが欠落している場合。

LSP は欠落しているログ・


各ブランチから欠落しているアーカイブ REDOログ・ファイルを検索して登録します。

REDO データの前のブランチの

終わりからアーカイブ REDO ログ・

ファイルが欠落している場合。

LSP は欠落しているログ・


前のブランチから欠落しているアーカイブREDO ログ・ファイルを検索して登録します。


ロジカル・スタンバイ・データベースのチューニング

9.6 ロジカル・スタンバイ・データベースのチューニングロジカル・スタンバイ・データベースのチューニングロジカル・スタンバイ・データベースのチューニングロジカル・スタンバイ・データベースのチューニングこの項は、次の項目で構成されています。

� 主キー RELY 制約の作成

� コストベース・オプティマイザの統計の収集

� プロセス数の調整

� LCR キャッシュ用メモリーの調整

� ロジカル・スタンバイ・データベースにおけるトランザクションの適用方法の調整

9.6.1 主キー主キー主キー主キー 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制約の詳細は、4.1.2 項「プライマリ・データベース内の表の行が一意に識別できることの確認」および『Oracle Database SQL リファレンス』を参照してください。



3. ロジカル・スタンバイ・データベースでメンテナンスされる表を変更できるように、ガードを無効にします。


4. EMPNO列に一意索引を追加します。

SQL> CREATE UNIQUE INDEX UI_TEST_EMP ON HR.TEST_EMPLOYEES (EMPNO);

5. ガードを有効にします。

SQL> ALTER SESSION ENABLE GUARD;





9.6.2 コストベース・オプティマイザの統計の収集コストベース・オプティマイザの統計の収集コストベース・オプティマイザの統計の収集コストベース・オプティマイザの統計の収集コストベース・オプティマイザ（CBO）で適の問合せ実行パスを判別するために使用されるため、スタンバイ・データベースで統計を収集する必要があります。以前の統計情報が正確でなくなるような変更をスキーマ・オブジェクトのデータまたは構造に対して実行した場合は、その後に新しい統計を収集してください。たとえば、多数の行を表に挿入または削除した後は、行数に関する新しい統計を収集します。

プライマリ・データベースでの DML および DDL 操作はワークロードの機能として実行されるため、統計はスタンバイ・データベースで収集してください。スタンバイ・データベースがプライマリ・データベースと論理的に等しい場合、SQL Apply ではワークロードを異なる方法で実行する場合があります。そのため、ロジカル・スタンバイ・データベースで STATS パッケージおよび V$SYSSTATビューを使用すると、リソースおよび表スキャンをも多く使用している表を判断する際に役立ちます。

9.6.3 プロセス数の調整プロセス数の調整プロセス数の調整プロセス数の調整次の各項で、次の内容を説明します。

� APPLIER プロセス数の調整

� PREPARER プロセス数の調整

9.6.3.1 APPLIER プロセス数の調整プロセス数の調整プロセス数の調整プロセス数の調整APPLIERプロセスの数を調整することでスループットを改善できるかどうかを判断する手順は、次のとおりです。

1. 次の問合せを発行して、APPLIERプロセスがビジーかどうかを判断します。

SQL> SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER' and status_code = 16166;

IDLE_APPLIER-------------------------0

2. アイドル状態の APPLIERプロセスがないことを確認した後、次の問合せを発行し、APPLIERの数を調整した場合に追加分の APPLIERプロセスに十分な処理が使用可能かどうかを確認します。

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE 'TRANSACTIONS%';

NAME VALUE--------------------- -------transactions ready 27896transactions applied 25671

この 2 つの統計では、APPLIERプロセスによる適用準備が完了しているトランザクション数とすでに適用済のトランザクション数の累計が維持されます。

この数値（transactions ready - transactions applied）が使用可能な APPLIERプロセス数の 2 倍を超えている場合は、APPLIERプロセス数を増やすことでスループットを改善できます。

関連項目関連項目関連項目関連項目 : RELY制約の詳細は、4.1.2 項「プライマリ・データベース内の表の行が一意に識別できることの確認」および『Oracle Database SQLリファレンス』を参照してください。



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

9.6.3.2 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-------------0

2. 適用準備が完了しているトランザクションの数が APPLIERプロセスの数よりも少ないことを確認します。

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE 'transactions%';NAME VALUE--------------------- -------transactions ready 27896transactions applied 27892

SQL> SELECT COUNT(*) AS APPLIER_COUNT FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER';APPLIER_COUNT-------------20

注意注意注意注意 : これが一時イベントでないことを確認するために、この問合せは数回発行してください。

注意注意注意注意 : この数値は準備作業の概算です。ワークロードによっては、準備が完了したトランザクション間の依存性が、使用可能な追加の APPLIERプロセスによる適用の妨げになる場合があります。たとえば、適用準備の完了しているトランザクションの大多数が DDL トランザクションの場合は、さらにAPPLIERプロセスを追加してもスループットは改善されません。



3. アイドル状態の APPLIERプロセスがあることを確認します。

SQL> SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER' and status_code = 16166;IDLE_APPLIER-------------------------19

この例では、すべての条件に該当しています。したがって、次の手順を実行して、PREPARERプロセスの数を 4 に（デフォルト値の 1 から）増やすことができます。



2. PREPARE_SERVERSの数を 4 に設定します。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS', 4);PL/SQL procedure successfully completed



9.6.4 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 894856bytes paged out 20000microsecs spent in pageout 2system idle time in secs 1000

2. この問合せを 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 895156bytes paged out 1020000secs spent in pageout 100system idle time in secs 1000

3. 正規化されたページアウト・アクティビティを計算します。次に例を示します。

Change in coordinator uptime (C)= (895156 – 894856) = 300 secsAmount of additional idle time (I)= (1000 – 1000) = 0Change in time spent in pageout (P) = (100 – 2) = 98 secsPageout time in comparison to uptime = P/(C-I) = 98/300 ~ 32.67%



ページアウト・アクティビティによる消費量が稼働時間全体の 5% 以下であれば理想的です。間隔を長くして引き続きスナップショットを取得し、ページアウト・アクティビティが引き続き適用時間の大部分を占めていることがわかった場合は、メモリー・サイズを大きくするとスループットが改善される可能性があります。 SQL Apply に割当済のメモリーを増やす手順は、次のとおりです。



2. LCR キャッシュに割当済のメモリーを設定します（この例では、SGA は 1GB に設定されています）。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 1024);PL/SQL procedure successfully completed

MAX_SGAは MB 単位で指定されているため、この例ではメモリーを 1GB に増やすために1024（MB）と指定しています。



9.6.5 ロジカル・スタンバイ・データベースにおけるトランザクションのロジカル・スタンバイ・データベースにおけるトランザクションのロジカル・スタンバイ・データベースにおけるトランザクションのロジカル・スタンバイ・データベースにおけるトランザクションの適用方法の調整適用方法の調整適用方法の調整適用方法の調整

デフォルトでは、トランザクションは、プライマリ・データベースでコミットされた順序に正確に従って、ロジカル・スタンバイ・データベースに適用されます。トランザクションのデフォルトのコミット順序では、レポート・アプリケーションをロジカル・スタンバイ・データベースで透過的に実行できます。ただし、ロジカル・スタンバイ・データベースをプライマリ・データベースと一致させる必要があり、しばらくはレポート・アプリケーションを実行しなくてもよい場合があります（ハードウェア障害やアップグレードが原因でロジカル・スタンバイ・データベースの停止が長引いた後など）。この場合は、次の手順でデフォルトの適用モードを変更できます。



2. PRESERVE_COMMIT_ORDERを FALSEに設定します。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER', 'FALSE');PL/SQL procedure successfully completed



プライマリ・データベースと一致し（V$LOGSTDBY_STATSビューを問い合せて確認し）、ロジカル・スタンバイ・データベースをレポート・アプリケーションに対してオープンする準備が完了した時点で、次のように適用モードを変更できます。



2. PRESERVE_COMMIT_ORDERパラメータのデフォルト値をリストアします。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER');PL/SQL procedure successfully completed





一般的なオンライン・トランザクション処理（OLTP）のワークロードでは、デフォルト以外のモードにすると、デフォルトの適用モードに比べてスループットを 50% 以上改善できます。


Recovery Manager を使用したファイルのバックアッ

10
Recovery Manager を使用したファイルのを使用したファイルのを使用したファイルのを使用したファイルの
バックアップおよびリストアバックアップおよびリストアバックアップおよびリストアバックアップおよびリストア

この章では、Data Guard およびスタンバイ・データベースとともに Oracle Recovery Managerユーティリティ（RMAN）を使用するバックアップ対策について説明します。 Recovery Manager を使用すると、小限の労力でプライマリ・データベースのバックアップを実行し、個々のデータファイルの消失から、またはデータベース全体をすばやくリカバリできます。Recovery Manager と Data Guard を併用すると、Data Guard 構成の管理作業を簡素化できます。

この章は、次の項目で構成されています。

� バックアップ処理

� スイッチオーバー、フェイルオーバーおよび制御ファイル作成がバックアップに与える影響

� その他のバックアップ状況

注意注意注意注意 : ロジカル・スタンバイ・データベースはプライマリ・データベースのブロック単位のコピーではないため、ロジカル・スタンバイ・データベースを使用してプライマリ・データベースをバックアップすることはできません。

プおよびリストア 10-1

バックアップ処理

10.1 バックアップ処理バックアップ処理バックアップ処理バックアップ処理スタンバイ環境では、プライマリまたはスタンバイ・システム上のデータファイルとアーカイブ REDO ログ・ファイルのバックアップを作成すると、両方のシステムでリカバリに使用できます。制御ファイルや SPFILE など、一部のファイルのバックアップはプライマリ・データベースで作成する必要がありますが、データファイルとアーカイブ REDO ログ・ファイルのバックアップ処理をスタンバイ・システムにオフロードして、バックアップが本番システムに与える影響を小限に抑えることができます。

スタンバイ・サイトで作成できるのは、スタンバイ・インスタンスによって作成されたアーカイブ REDO ログ・ファイルのバックアップのみです。スタンバイ・データベースの起動前に生成されたアーカイブ REDO ログ・ファイルが存在する場合は、そのバックアップをプライマリ・データベースで作成する必要があります。たとえば、プライマリ・データベースからスタンバイに送信された初のログがログ順序番号 100、スレッド 1 の場合は、プライマリ・データベースで 99 以下のログ順序番号を持つアーカイブ REDO ログ・ファイルのバックアップを実行する必要があります。

フラッシュ・リカバリ領域が構成されている場合、Oracle ソフトウェアでは必要に応じてフラッシュ・リカバリ領域からファイルが削除されます。フラッシュ・リカバリ領域は、テープ・バックアップ用のディスク・キャッシュとして機能します。

10.1.1 テープ・バックアップ用キャッシュとしてのディスクの使用テープ・バックアップ用キャッシュとしてのディスクの使用テープ・バックアップ用キャッシュとしてのディスクの使用テープ・バックアップ用キャッシュとしてのディスクの使用次の手順では、フラッシュ・リカバリ領域が構成されており（5.2.3 項を参照）、他の Recovery Manager の永続構成が設定されていると仮定します。次の手順に従ってください。

1. プライマリ・データベースで、次の Recovery Manager コマンドを発行して制御ファイルと SPFILE の新バックアップを作成し、プライマリ・インスタンスによって作成されたフラッシュ・リカバリ領域内のファイルをテープにバックアップします。

BACKUP DEVICE TYPE DISK CURRENT CONTROLFILE;BACKUP RECOVERY AREA;

これらのコマンドは、現行の制御ファイルがすべて消失した場合に許容できる REDO データの適用量に応じて（10.2.4 項を参照）、毎日または 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.1.2 テープへの直接バックアップの実行テープへの直接バックアップの実行テープへの直接バックアップの実行テープへの直接バックアップの実行すべてのバックアップがテープに直接書き込まれる場合は、Recovery Manager の CONFIGURE DEFAULT DEVICE TYPE TO SBTコマンドを使用してデフォルトのデバイス・タイプを SBTに構成します。

プライマリ・データベースで、次の Recovery Manager コマンドを使用して、現行の制御ファイルのバックアップを作成し、プライマリ・インスタンスによって作成された自動バックアップをテープにコピーします。

BACKUP AS BACKUPSET CURRENT CONTROLFILE;BACKUP RECOVERY AREA;

これらのコマンドは、現行の制御ファイルがすべて消失した場合に許容できる REDO データの適用量に応じて（10.2.4 項を参照）、毎日または 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


10.2.1 プライマリ・データベースのデータファイル消失からのリカバリプライマリ・データベースのデータファイル消失からのリカバリプライマリ・データベースのデータファイル消失からのリカバリプライマリ・データベースのデータファイル消失からのリカバリ次の Recovery Manager コマンドを発行し、データファイルをリストアおよびリカバリします。プライマリ・データベースとリカバリ・カタログ・データベースの両方に接続する必要があります。

RESTORE DATAFILE n,m...;RECOVER DATAFILE n,m...;

次の Recovery Manager コマンドを発行して、表領域をリストアおよびリカバリします。プライマリ・データベースとリカバリ・カタログ・データベースの両方に接続する必要があります。

RESTORE TABLESPACE tbs_name1, tbs_name2, ...RECOVER TABLESPACE tbs_name1, tbs_name2, ...

10.2.2 スタンバイ・データベースのデータファイル消失からのリカバリスタンバイ・データベースのデータファイル消失からのリカバリスタンバイ・データベースのデータファイル消失からのリカバリスタンバイ・データベースのデータファイル消失からのリカバリ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------- ----------------967786

3. 次の Recovery Manager コマンドを発行して、スタンバイ・データベースでデータファイルをリストアおよびリカバリします。スタンバイ・データベースとリカバリ・カタログ・データベースの両方に接続する必要があります。（スタンバイ・インスタンスへの接続にはTARGETキーワードを使用します）。

RESTORE DATAFILE <n,m,...>;RECOVER DATABASE UNTIL SCN 967786;

表領域をリストアするには、Recovery Manager の 'RESTORE TABLESPACE tbs_name1, tbs_name2, ...' コマンドを使用します。

4. REDO Apply を再開します。



10.2.3 スタンバイ制御ファイルの消失からのリカバリスタンバイ制御ファイルの消失からのリカバリスタンバイ制御ファイルの消失からのリカバリスタンバイ制御ファイルの消失からのリカバリOracle ソフトウェアでは、スタンバイ制御ファイルを多重化できます。スタンバイ制御ファイルが多重化されているかどうかを確認するには、次のように CONTROL_FILES初期化パラメータを調べます。

SQL> SHOW PARAMETER CONTROL_FILESNAME 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 ログ・ファイルをすべて手動でカタログ化する必要があります。

10.2.4 プライマリ制御ファイルの消失からのリカバリプライマリ制御ファイルの消失からのリカバリプライマリ制御ファイルの消失からのリカバリプライマリ制御ファイルの消失からのリカバリOracle ソフトウェアでは、プライマリ・データベースの制御ファイルを多重化できます。プライマリ・データベースで制御ファイルの 1 つを更新できない場合は、プライマリ・データベース・インスタンスが自動的に停止します。10.2.3 項で説明したように、リストアまたはリカバリ操作を実行しなくても、制御ファイルの元のコピーをコピーしてインスタンスを再起動できます。

制御ファイルがすべて消失した場合は、許容できるダウンタイムに応じて次の手順から選択できます。

新規制御ファイルの作成新規制御ファイルの作成新規制御ファイルの作成新規制御ファイルの作成制御ファイルのコピーがすべて消失した場合は、メディア・リカバリの実行後に NORESETLOGSオプションを使用して新規制御ファイルを作成し、データベースをオープンできます。既存のスタンバイ・データベース・インスタンスでは、次の文を使用して新規制御ファイルを作成するためのスクリプトを生成できます。

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS;

プライマリ・データベースとスタンバイ・データベースでデータベース・ファイル名が異なる場合は、生成されたスクリプトを編集してファイル名を訂正する必要があります。

この文を定期的に使用して制御ファイル作成スクリプトを生成できます。リカバリ計画の一部として制御ファイル作成スクリプトを使用する場合は、データファイル、表領域または REDOログ・メンバーの追加や削除など、物理構造の変更後にこの文を使用する必要があります。

作成された制御ファイルからは、作成前に生成されていたアーカイブ REDO ログ・ファイルに関する情報がすべて失われています。プライマリ・データベースでアーカイブ REDO ログ・ファイルのバックアップを実行する場合は、前回のバックアップ以後に生成されたアーカイブREDO ログ・ファイルをすべて手動でカタログ化しておく必要があります。



バックアップ制御ファイルを使用したリカバリバックアップ制御ファイルを使用したリカバリバックアップ制御ファイルを使用したリカバリバックアップ制御ファイルを使用したリカバリ前述の手順で制御ファイルを作成できない場合は、バックアップ制御ファイルを使用し、完全リカバリを実行して、RESETLOGSオプションを指定してデータベースをオープンできます。

制御ファイルをリストアしてデータベースをリカバリするには、プライマリ・インスタンス（NOMOUNT状態）とカタログ・データベースに接続した後に、次の Recovery Manager コマンドを発行します。

RESTORE CONTROLFILE;ALTER DATABASE MOUNT;RECOVER DATABASE;ALTER DATABASE OPEN RESETLOGS;

Oracle リリース 10.1.0 からは、RESETLOGS操作の前に作成したバックアップすべてをリカバリに使用できます。そのため、本番に使用可能にする前にデータベースのバックアップを作成する必要はありません。

10.2.5 オンラインオンラインオンラインオンライン 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 directoryAdditional information: 3

アクセスの問題がハードウェア・エラーによる一時的なものの場合は、問題を解決すると処理が自動的に続行されます。消失が永続的な場合は、新規メンバーを追加して古いメンバーをグループから削除できます。

REDO ログ・グループに新規メンバーを追加するには、次の文を発行します。

SQL> ALTER DATABASE ADD LOGFILE MEMBER 'log_file_name' REUSE TO GROUP n

この文は、データベースがオープン状態の場合にも、データベースの可用性に影響を与えずに発行できます。

アーカイブ済の非アクティブ・グループのメンバーがすべて消失した場合は、そのグループを削除して再作成できます。

他のすべての場合（現行の ACTIVEグループまたはアーカイブされていない非アクティブ・グループのオンライン・ログ・メンバーすべてが消失した場合）は、スタンバイ・データベースにフェイルオーバーする必要があります。フェイルオーバー手順については第 7 章を参照してください。



10.2.6 データベースの不完全リカバリデータベースの不完全リカバリデータベースの不完全リカバリデータベースの不完全リカバリプライマリ・データベースの不完全リカバリを実行するのは、通常、データベースが論理的に

（ユーザーまたはアプリケーションが原因で）破損した場合や、表領域またはデータファイルがデータベースから意図せずに削除された場合などです。

スタンバイ・データベース・インスタンス上の現在のデータベース・チェックポイント 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 を識別します。


その他のバックアップ状況

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.3.1 スタンバイ・データベースが地理的に離れすぎているためにバックスタンバイ・データベースが地理的に離れすぎているためにバックスタンバイ・データベースが地理的に離れすぎているためにバックスタンバイ・データベースが地理的に離れすぎているためにバックアップを共有できない場合アップを共有できない場合アップを共有できない場合アップを共有できない場合

この場合、プライマリ・システムや他のスタンバイ・システムからは、スタンバイ・システム上で作成されたバックアップに簡単にアクセスできません。すべてのシステム上でデータベースの完全バックアップを実行して、リカバリ操作を実行します。フラッシュ・リカバリ領域は、プライマリおよびスタンバイ・システム上にローカルに置くことができます（プライマリ・データベースとスタンバイ・データベースでフラッシュ・リカバリ領域が異なる場合など）。

この使用例でも、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.3.2 FAL サーバーとして使用されるスタンバイ・データベースにデータサーバーとして使用されるスタンバイ・データベースにデータサーバーとして使用されるスタンバイ・データベースにデータサーバーとして使用されるスタンバイ・データベースにデータファイルが含まれていない場合ファイルが含まれていない場合ファイルが含まれていない場合ファイルが含まれていない場合

10.1 項で説明した手順を使用しますが、データベース・ファイルをバックアップする Recovery Manager コマンドは FAL サーバーに対して実行できません。FAL サーバーは、すべてのアーカイブ REDO ログ・ファイルのバックアップ・ソースとして使用できるため、アーカイブREDO ログ・ファイルのバックアップを FAL サーバーにオフロードします。

10.3.3 スタンバイ・データベースのファイル名がプライマリ・データベーススタンバイ・データベースのファイル名がプライマリ・データベーススタンバイ・データベースのファイル名がプライマリ・データベーススタンバイ・データベースのファイル名がプライマリ・データベースとは異なる場合とは異なる場合とは異なる場合とは異なる場合

プライマリ・データベースとスタンバイ・データベースでデータベース・ファイル名が異なる場合は、少し異なる 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オプションを使用し、スタンバイ・データベースの作成中に新規ファイル名を指定する必要があります。

10.3.4 フラッシュ・リカバリ領域のアーカイブフラッシュ・リカバリ領域のアーカイブフラッシュ・リカバリ領域のアーカイブフラッシュ・リカバリ領域のアーカイブ REDO ログ・ファイルにログ・ファイルにログ・ファイルにログ・ファイルに関する削除ポリシー関する削除ポリシー関する削除ポリシー関する削除ポリシー

デフォルトでは、3 次記憶装置にバックアップ済であるか廃止（Recovery Manager の保存ポリシーで定義）になったフラッシュ・リカバリ領域内のアーカイブ REDO ログ・ファイルは、削除対象となります。バックアップ済または廃止になったアーカイブ REDO ログ・ファイルは、終的には自動的に削除し、フラッシュ・リカバリ領域のディスク領域がいっぱいになった場

合に領域を解放できます。ただし、このデフォルトの削除ポリシーは、次の Recovery Managerコマンドを使用して変更できます。

CONFIGURE ARCHIVELOG DELETION POLICY TO [CLEAR | NONE | APPLIED ON STANDBY];

この項では、コマンド修飾子について説明し、削除ポリシーの設定例を示します。 Oracle ソフトウェアによるフラッシュ・リカバリ領域のディスク領域の管理方法の詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。



APPLIED ON STANDBY 句の使用句の使用句の使用句の使用

すべての必須スタンバイ宛先に適用済のアーカイブ REDO ログ・ファイルが削除されるように、APPLIED ON STANDBY句を使用します。次の表に、この句を指定した場合に実行されるアクションを示します。

カスケードされた宛先の詳細は、付録 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;

APPLIED ON STANDBY 句の構成場所句の構成場所句の構成場所句の構成場所削除対象となるファイル削除対象となるファイル削除対象となるファイル削除対象となるファイル

プライマリ・データベースすべての必須スタンバイ・データベースに適用済の、フラッシュ・リカバリ領域内のアーカイブREDO ログ・ファイル

1 つ以上の必須のカスケード・

スタンバイ・データベースを持つスタンバイ・データベース

すべての必須カスケード・スタンバイ・データベースに適用済の、フラッシュ・リカバリ領域内のアーカイブ REDO ログ・ファイル

カスケード・スタンバイ・データベースを持たないスタンバイ・データベース

スタンバイ・データベースに適用済の、フラッシュ・リカバリ領域内のアーカイブ REDO ログ・

ファイル



10.3.4.1 ロールが推移した後の削除ポリシーの再構成ロールが推移した後の削除ポリシーの再構成ロールが推移した後の削除ポリシーの再構成ロールが推移した後の削除ポリシーの再構成スイッチオーバーまたはフェイルオーバーの後に、各データベースで Recovery Manager のCONFIGURE ARCHIVELOG DELETION POLICYコマンドの再発行が必要になる場合があります。アーカイブ REDO ログ・ファイルのバックアップ・サイトが同一の場合、何も実行する必要はありません。それ以外の場合は、バックアップが作成されないデータベースで CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY文を発行し、バックアップが作成されるデータベースで CONFIGURE ARCHIVELOG DELETION POLICY TO NONE文を発行して、ARCHIVELOG 削除ポリシーを切り替える必要があります。

10.3.4.2 現行の削除ポリシーの表示現行の削除ポリシーの表示現行の削除ポリシーの表示現行の削除ポリシーの表示データベースに対する現行の設定（APPLIED ON STANDBY、CLEAR、NONE）を確認するには、次の問合せを発行します。

SELECT NAME, VALUE FROM V$RMAN_CONFIGURATION WHERENAME LIKE '%ARCHIVELOG DELETION POLICY%';

NAME VALUE----------------------------- --------------ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY

次のように、Recovery Manager の SHOW ARCHIVELOG DELETION POLICYコマンドを使用して既存の構成を検索することもできます。

RMAN> SHOW ARCHIVELOG DELETION POLICYRMAN configuration parameters are:CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;




SQL Apply を使用した Oracle Database のアップグ

11
SQL Apply を使用したを使用したを使用したを使用した Oracle Database のののの
アップグレードアップグレードアップグレードアップグレード

Oracle Database 10g リリース 1（10.1.0.3）からは、ロジカル・スタンバイ・データベースを使用して、Oracle Database 10g ソフトウェアのローリング・アップグレードを実行できます。ローリング・アップグレード中は、プライマリ・データベースとロジカル・スタンバイ・データベースで異なるリリースの Oracle データベースを実行しながら、プライマリ・データベースの停止時間を短に抑えて各リリースを 1 度に 1 つずつアップグレードできます。

この章の各手順では、Oracle データベースのアップグレード中の停止時間を短に抑える方法について説明します。この章は、次の項目で構成されています。

� SQL Apply を使用するローリング・アップグレードのメリット

� SQL Apply を使用してローリング・アップグレードを実行するための要件

� アップグレード手順に使用する図と表記規則

� アップグレードの準備

� データベースのアップグレード

注意注意注意注意 : この章では、ロジカル・スタンバイ・データベースが存在する場合にローリング・アップグレードを行って停止時間を短に抑える方法を説明します。2 つ目の方法は B.3 項「ロジカル・スタンバイ・データベースが存在する場合の Oracle Database のアップグレード」に説明されている従来からのアップグレード処理で、アップグレード処理中に停止時間が発生します。完全なアップグレードを実行するには、どちらか一方の方法の手順のみを使用してください。両方の方法を使用したり、2 つの方法の手順を組み合せようとしないでください。

レード 11-1

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に設定されていること。これにより、ロジカル・スタンバイ・データベースのアップグレード中もプライマリ・データベースで処理を進行できます。

� COMPATIBLE初期化パラメータがアップグレード前のソフトウェア・リリースと一致していること。つまり、リリース x からリリース y へのローリング・アップグレードでは、プライマリ・データベースとスタンバイ・データベースの両方で COMPATIBLE初期化パラメータをリリース x に設定する必要があります。

関連項目関連項目関連項目関連項目 : LOG_ARCHIVE_DEST_n初期化パラメータの MANDATORYおよびOPTIONAL属性の使用方法の詳細は、『Oracle Data Guard 概要および管理』を参照してください。


アップグレードの準備

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


これらの PL/SQL プロシージャをデータベース A で実行しても、プライマリ・データベースには影響しません。ただし、ロジカル・スタンバイ・データベース（およびロジカル・スタンバイ・データベース制御ファイル）を作成する前に、これらのプロシージャをプライマリ・データベースで実行すると、手順 4 でロジカル・スタンバイ・データベースを作成するときに自動的に設定が転送されます。

アップグレード手順に使用できるロジカル・スタンバイ・データベース（データベース B）が存在している場合は、両方のデータベースで PL/SQL コマンド DBMS_LOGSTDBYを発行してから手順 3 にスキップします。

手順手順手順手順 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_TABOE CUSTOMERSOE WAREHOUSESPM ONLINE_MEDIAPM PRINT_MEDIASCOTT MYCOMPRESSSH MVIEW$_EXCEPTIONS7 rows selected.

SQL> SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP 2 WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';

OWNER------------------------------CTXSYSDBSNMPDIPORDPLUGINSORDSYSOUTLNSI_INFORMTN_SCHEMASYS

注意注意注意注意 : Oracle Database 10g リリース 1（10.1）では、DBMS_LOGSTDBY.MAX_EVENTS定数はDBMS_LOGSTDBY_PUBLIC.MAX_EVENTSと呼ばれていました。この 2 つの定数の効果は同じですが、リリース 2（10.2）ではDBMS_LOGSTDBY_PUBLICパッケージが廃止され、定数の定義がDBMS_LOGSTDBYパッケージに移動されています。

関連項目関連項目関連項目関連項目 : DBMS_LOGSTDBYプロシージャの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。



SYSTEMWMSYS10 rows selected.

2. サポートされない表の処理方法を決定します。

サポートされないオブジェクトがプライマリ・データベースで変更されると、次のいずれかの方法でアップグレードを実行できるようになる可能性があります。

� アップグレード手順の実行所要時間中は、サポートされない表に対する変更を一時的に停止します。

サポートされない表に対する変更を防止できる場合は、SQL Apply を使用してアップグレード手順を実行できる場合があります。この方法では、ロジカル・スタンバイ制御ファイルの作成時からアップグレード完了時までは、サポートされない表に対するユーザー変更を禁止する必要があります。DBA_LOGSTDBY_EVENTSビューでトランザクション・アクティビティを監視し、初のスイッチオーバーの実行時までアップグレードを中断できます（必要な場合）。

� ユーザーがサポートされない表を変更していないときにアップグレードを実行します。

要件の異なる複数部門をサポートするロジカル・スタンバイ・データベースの場合は、ユーザーによるデータベース表へのアクセス方法がわかっていれば、SQL Apply を使用してアップグレードを実行できます。たとえば、給与管理部門はオブジェクト表を更新しますが、この部門がデータベースを更新するのは月曜から金曜のみであるとします。一方、カスタマ・サービス部門は 1 日 24 時間、1 週 7 日間のデータベース・アクセスを必要としますが、使用するのはサポートされるデータ型および表のみであるとします。この使用例では、週末にアップグレードを実行できます。

サポートされない表に対する変更をアップグレード中に防止できない場合、発生したサポートされないトランザクションはロジカル・スタンバイ・データベースのDBA_LOGSTDBY_EVENTS表に記録されます。アップグレードの完了後に、Oracle Data Pump またはエクスポート / インポート・ユーティリティを使用して、変更された表をアップグレード後のデータベースにインポートできます。

変更された表のサイズにより、データベース操作が使用できなくなる期間が決定するため、データをエクスポートしてスタンバイ・データベースにインポートするには表が大きすぎないかどうかを判断する必要があります。たとえば、4TB の表は、エクスポート / インポート処理に適した候補ではありません。

手順手順手順手順 4 ロジカル・スタンバイ・データベースを作成するロジカル・スタンバイ・データベースを作成するロジカル・スタンバイ・データベースを作成するロジカル・スタンバイ・データベースを作成する

ロジカル・スタンバイ・データベースを作成するには、第 4 章の手順に従います。

停止時間を短に抑えるために、ロジカル・スタンバイ・データベースでスタンバイ REDO ログを構成することをお薦めします。

注意注意注意注意 : アプリケーションのデータ型がサポートされないためにロジカル・スタンバイ・データベースを使用できない場合は、『Oracle Database アップグレード・ガイド』の説明に従ってアップグレードを実行してください。

注意注意注意注意 : すでにロジカル・スタンバイ・データベースが存在する場合は、11.5項「データベースのアップグレード」に進んでアップグレード手順を開始します。


データベースのアップグレード

11.5 データベースのアップグレードデータベースのアップグレードデータベースのアップグレードデータベースのアップグレードこの項では、ロジカル・スタンバイ・データベースとプライマリ・データベースをアップグレードする手順について説明します。表 11-1 に手順を示します。

手順手順手順手順 1 SQL Apply を停止してロジカル・スタンバイ・データベースをアップグレードするを停止してロジカル・スタンバイ・データベースをアップグレードするを停止してロジカル・スタンバイ・データベースをアップグレードするを停止してロジカル・スタンバイ・データベースをアップグレードする

アップグレードを開始するには、SQL Apply を停止して、ロジカル・スタンバイ・データベース（データベース B）の Oracle Database ソフトウェアをリリース y にアップグレードします。SQL Apply を停止するには、データベース B で次の文を発行します。


Oracle Database ソフトウェアをアップグレードするには、該当する Oracle Database リリースの『Oracle Database アップグレード・ガイド』を参照してください。

図 11-2 に、リリース x を実行中のデータベース A とリリース y を実行中のデータベース B を示します。アップグレード中は、REDO データがプライマリ・システムに蓄積されます。

図図図図 11-2 ロジカル・スタンバイ・データベースのリリースのアップグレードロジカル・スタンバイ・データベースのリリースのアップグレードロジカル・スタンバイ・データベースのリリースのアップグレードロジカル・スタンバイ・データベースのリリースのアップグレード

表表表表 11-1 Oracle Database ソフトウェアをアップグレードする手順ソフトウェアをアップグレードする手順ソフトウェアをアップグレードする手順ソフトウェアをアップグレードする手順

手順手順手順手順説明説明説明説明

1 SQL Apply を停止してロジカル・スタンバイ・データベースをアップグレードする

2 SQL Apply を再開する

3 アップグレード後のスタンバイ・データベースでイベントを監視する

4 スイッチオーバーを開始する

5 サポートされないオブジェクトがアップグレード中に変更されたかどうかを判断する

6 スイッチオーバーを完了してユーザー・アプリケーションをアクティブ化する

7 前のプライマリ・データベースをアップグレードする

8 SQL Apply を開始する

9 必要な場合は、両方のデータベースの互換性レベルを上げる

10 新規ロジカル・スタンバイ・データベースでイベントを監視する

11 必要な場合は、再度スイッチオーバーを実行する

注意注意注意注意 : ビジネスにプライマリ・データベースをサポートするロジカル・スタンバイ・データベースが不要な場合は、手順 7 ～ 11 をスキップできます。



手順手順手順手順 2 SQL Apply を再開するを再開するを再開するを再開する

SQL Apply を再開し、データベース A ではリリース x、データベース B ではリリース y で動作させます。SQL Apply を開始するには、データベース B で次の文を発行します。


プライマリ・システムに蓄積された 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------------------ ------------------27-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 1000SQL> SET PAGESIZE 180SQL> SET LINESIZE 79SQL> SELECT EVENT_TIMESTAMP, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTSORDER BY EVENT_TIMESTAMP;

EVENT_TIMESTAMP---------------------------------------------------------------------------EVENT--------------------------------------------------------------------------------STATUS--------------------------------------------------------------------------------…



24-MAY-05 05.18.29.318912 PMCREATE TABLE SYSTEM.TST (one number)ORA-16226: サポートされていないため、DDLはスキップされました

24-MAY-05 05.18.29.379990 PM"SYSTEM"."TST"ORA-16129: サポートされていない dmlを検出しました

前述の例で、各エラーの意味は次のとおりです。

� ORA-16226エラーは、サポートできない DDL 文を示します。この場合は、内部スキーマに属しているためにサポートできません。

� ORA-16129エラーは、適用されなかった DML 文を示します。

この種のエラーは、データベース A で発生した変更の一部がデータベース B に適用されなかったことを示します。この時点で、アップグレード手順を続行するかどうかを判断する必要があります。ロジカル・スタンバイ・データベースとプライマリ・データベース間で、この差異が許容可能であることが確実な場合は、アップグレード手順を続行します。不確実な場合は、アップグレード手順を中断してデータベース B を破棄し、別の時点でアップグレード手順を実行します。

手順手順手順手順 4 スイッチオーバーを開始するスイッチオーバーを開始するスイッチオーバーを開始するスイッチオーバーを開始する

アップグレード後のデータベース・ソフトウェアが正常に動作していることを確認した後、データベース A で次の文を発行してスイッチオーバーを実行し、データベース・ロールを元に戻します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;

この文は、既存のトランザクションの完了まで待機する必要があるかどうかに応じて、数秒しかかからないことがあります。引き続きデータベース A に接続しているユーザーは、即時にログオフしてデータベース B に再接続する必要があります。

手順手順手順手順 5 サポートされないオブジェクトがアップグレード中に変更されたかどうかを判断するサポートされないオブジェクトがアップグレード中に変更されたかどうかを判断するサポートされないオブジェクトがアップグレード中に変更されたかどうかを判断するサポートされないオブジェクトがアップグレード中に変更されたかどうかを判断する

手順 3 の「アップグレード後のスタンバイ・データベースでイベントを監視する」では、変更中のサポートされない表をリストする方法について説明しました。プライマリ・データベースでサポートされない DML 文が発行された場合は（例 11-1 を参照）、Oracle Data Pump などのインポート・ユーティリティを使用して、各表の新バージョンをインポートします。

たとえば、次のインポート・コマンドは scott.emp表を切り捨て、前のプライマリ・データベース（A）と一致するデータを移入します。

IMPDP SYSTEM/MANAGER NETWORK_LINK=DATABASEA TABLES=SCOTT.EMP TABLE_EXIST_ACTION=TRUNCATE

注意注意注意注意 : データベース A がプライマリ・データベースのときに、そこでサポートされない表またはパッケージに対するアクティビティを一時停止した場合、終的にデータベース A に切り替える計画であれば、データベース Bがプライマリ・データベースになっている間にデータベース B でも引き続き同じアクティビティを一時停止する必要があります。

注意注意注意注意 : インポートする表は、11.4 項「アップグレードの準備」の手順 3 に示したデータ型の要件を満たしている必要があります。



手順手順手順手順 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 スイッチオーバー後スイッチオーバー後スイッチオーバー後スイッチオーバー後



手順手順手順手順 7 前のプライマリ・データベースをアップグレードする前のプライマリ・データベースをアップグレードする前のプライマリ・データベースをアップグレードする前のプライマリ・データベースをアップグレードする

データベース A では引き続きリリース x が実行されており、アップグレードして SQL Applyを開始するまでは、データベース B からの REDO データを適用できません。

Oracle Database ソフトウェアのアップグレードの詳細は、該当する Oracle Database リリースの『Oracle Database アップグレード・ガイド』を参照してください。

図 11-5 に、両方のデータベースがアップグレードされた後のシステムを示します。

図図図図 11-5 両方のデータベースがアップグレードされた後両方のデータベースがアップグレードされた後両方のデータベースがアップグレードされた後両方のデータベースがアップグレードされた後


データベース 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 章「ロジカル・スタンバイ・データベースの作成」を参照してください。

注意注意注意注意 : この文を発行する前にデータベース・リンクを作成するのは、データベース・リンクが設定されていない場合のみです。



手順手順手順手順 11 必要な場合は、再度スイッチオーバーを実行する必要な場合は、再度スイッチオーバーを実行する必要な場合は、再度スイッチオーバーを実行する必要な場合は、再度スイッチオーバーを実行する

必要な場合は、データベース A がプライマリ・データベース・ロールで再実行されるように（図 11-1 を参照）、データベースのスイッチオーバーを再度実行します。

関連項目関連項目関連項目関連項目 : 7.3.1 項「ロジカル・スタンバイ・データベースが関与するスイッチオーバー」




Data Guard の

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 項ネットワーク障害のリカバリ

12.10 項 NOLOGGING 句を指定した後のリカバリ

12.11 項手動によるアーカイブ・ギャップの解決

12.12 項 OMF または ASM を使用するスタンバイ・データベースの作成

使用例 12-1

アーカイブ先の設定および確認

12.1 アーカイブ先の設定および確認アーカイブ先の設定および確認アーカイブ先の設定および確認アーカイブ先の設定および確認次の各項で、ロール固有のアーカイブを使用可能および使用不可にするLOG_ARCHIVE_DEST_n初期化パラメータとその他の関連パラメータの設定方法を説明します。

� プライマリ・データベースおよびフィジカル・スタンバイ・データベースの構成

� プライマリ・データベースおよびロジカル・スタンバイ・データベースの構成

� フィジカルおよびロジカル・スタンバイ・データベースの構成

� 各宛先について現行の VALID_FOR 属性設定の確認

12.1.1 プライマリ・データベースおよびフィジカル・スタンバイ・データプライマリ・データベースおよびフィジカル・スタンバイ・データプライマリ・データベースおよびフィジカル・スタンバイ・データプライマリ・データベースおよびフィジカル・スタンバイ・データベースの構成ベースの構成ベースの構成ベースの構成

図 12-1 に、chicagoプライマリ・データベース、bostonフィジカル・スタンバイ・データベース、および各システムの初期化パラメータを示します。

図図図図 12-1 ロールの推移前のプライマリおよびフィジカル・スタンバイ・データベースロールの推移前のプライマリおよびフィジカル・スタンバイ・データベースロールの推移前のプライマリおよびフィジカル・スタンバイ・データベースロールの推移前のプライマリおよびフィジカル・スタンバイ・データベース

表 12-2 に、図 12-1 で示された構成の初期化パラメータを示します。

表表表表 12-2 プライマリ・データベースとフィジカル・スタンバイ・データベースの初期化パラメータの設定プライマリ・データベースとフィジカル・スタンバイ・データベースの初期化パラメータの設定プライマリ・データベースとフィジカル・スタンバイ・データベースの初期化パラメータの設定プライマリ・データベースとフィジカル・スタンバイ・データベースの初期化パラメータの設定

Chicago データベース（プライマリ・ロール）データベース（プライマリ・ロール）データベース（プライマリ・ロール）データベース（プライマリ・ロール）Boston データベースデータベースデータベースデータベース（フィジカル・スタンバイ・データベース・ロール）（フィジカル・スタンバイ・データベース・ロール）（フィジカル・スタンバイ・データベース・ロール）（フィジカル・スタンバイ・データベース・ロール）

DB_UNIQUE_NAME=chicagoLOG_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=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLESTANDBY_ARCHIVE_DEST=/arch1/chicago/REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

DB_UNIQUE_NAME=bostonLOG_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=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLESTANDBY_ARCHIVE_DEST=/arch1/boston/REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE



次の表で、図 12-1 で示されたアーカイブ・プロセスについて説明します。

図 12-2 に、スイッチオーバー後の同一構成を示します。

図図図図 12-2 ロールの推移後のプライマリおよびフィジカル・スタンバイ・データベースロールの推移後のプライマリおよびフィジカル・スタンバイ・データベースロールの推移後のプライマリおよびフィジカル・スタンバイ・データベースロールの推移後のプライマリおよびフィジカル・スタンバイ・データベース


Chicago データベースデータベースデータベースデータベース（プライマリ・ロール）（プライマリ・ロール）（プライマリ・ロール）（プライマリ・ロール）

Boston データベースデータベースデータベースデータベース（フィジカル・スタンバイ・ロール）（フィジカル・スタンバイ・ロール）（フィジカル・スタンバイ・ロール）（フィジカル・スタンバイ・ロール）

LOG_ARCHIVE_DEST_1 /arch1/chicago/内のローカル・アーカ

イブ REDO ログ・ファイルに REDO デー

タをアーカイブするよう指示。


REDO ログ・ファイルに REDO データをアー

カイブするよう指示。

LOG_ARCHIVE_DEST_2 リモート・フィジカル・スタンバイ・データベース bostonに REDO データを転送す

るよう指示。

無視。bostonがプライマリ・ロールで稼働

している場合にのみ有効。

STANDBY_ARCHIVE_DEST 無視。chicagoがスタンバイ・ロールで稼

働している場合にのみ有効。

ローカルの /arch1/boston/ディレクトリ

内のアーカイブ REDO ログ・ファイルに

REDO データをアーカイブするよう指示。

Chicago データベースデータベースデータベースデータベース（フィジカル・スタンバイ・ロール）（フィジカル・スタンバイ・ロール）（フィジカル・スタンバイ・ロール）（フィジカル・スタンバイ・ロール）

Boston データベースデータベースデータベースデータベース（プライマリ・ロール）（プライマリ・ロール）（プライマリ・ロール）（プライマリ・ロール）

LOG_ARCHIVE_DEST_1 ローカルの /arch1/chicago/ディレクトリ

に REDO データをアーカイブするよう指示。

/arch1/boston/内のローカル・アーカ

イブ REDO ログ・ファイルに REDO デー

タをアーカイブするよう指示。

LOG_ARCHIVE_DEST_2 無視。chicagoがプライマリ・ロールで稼働


リモート・フィジカル・スタンバイ宛先chicagoに REDO データを転送するよう

指示。

STANDBY_ARCHIVE_DEST ローカルの /arch1/chicago/ディレクトリ

内のアーカイブ REDO ログ・ファイルに

REDO データをアーカイブするよう指示。

無視。bostonがスタンバイ・ロールで稼


Data Guard の使用例 12-3


12.1.2 プライマリ・データベースおよびロジカル・スタンバイ・データベープライマリ・データベースおよびロジカル・スタンバイ・データベープライマリ・データベースおよびロジカル・スタンバイ・データベープライマリ・データベースおよびロジカル・スタンバイ・データベースの構成スの構成スの構成スの構成

図 12-3 に、プライマリ・ロールで稼働している chicagoデータベース、ロジカル・スタンバイ・ロールで稼働している denverデータベース、および各システムの初期化パラメータを示します。アクティブでないコンポーネントはグレー表示されています。

図図図図 12-3 プライマリ・データベースおよびロジカル・スタンバイ・データベースの宛先の構成プライマリ・データベースおよびロジカル・スタンバイ・データベースの宛先の構成プライマリ・データベースおよびロジカル・スタンバイ・データベースの宛先の構成プライマリ・データベースおよびロジカル・スタンバイ・データベースの宛先の構成

表 12-3 に、図 12-3 で示された構成の初期化パラメータを示します。

表表表表 12-3 プライマリ・データベースとロジカル・スタンバイ・データベースの初期化パラメータの設定プライマリ・データベースとロジカル・スタンバイ・データベースの初期化パラメータの設定プライマリ・データベースとロジカル・スタンバイ・データベースの初期化パラメータの設定プライマリ・データベースとロジカル・スタンバイ・データベースの初期化パラメータの設定

Chicago データベース（プライマリ・ロール）データベース（プライマリ・ロール）データベース（プライマリ・ロール）データベース（プライマリ・ロール）Denver データベースデータベースデータベースデータベース（ロジカル・スタンバイ・データベース・ロール）（ロジカル・スタンバイ・データベース・ロール）（ロジカル・スタンバイ・データベース・ロール）（ロジカル・スタンバイ・データベース・ロール）

DB_UNIQUE_NAME=chicagoLOG_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=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_DEST_STATE_3=ENABLESTANDBY_ARCHIVE_DEST=/arch2/chicago/REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

DB_UNIQUE_NAME=denverLOG_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=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_DEST_STATE_3=ENABLESTANDBY_ARCHIVE_DEST=/arch2/denver/REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE




フィジカル・スタンバイ・データベースと異なり、ロジカル・スタンバイ・データベースは、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 に、スイッチオーバー後の同一構成を示します。


Denver データベースデータベースデータベースデータベース（ロジカル・スタンバイ・ロール）（ロジカル・スタンバイ・ロール）（ロジカル・スタンバイ・ロール）（ロジカル・スタンバイ・ロール）

LOG_ARCHIVE_DEST_1 /arch1/chicago/内のローカル・

アーカイブ REDO ログ・ファイルに

ローカル・オンライン REDO ログ・

ファイルからプライマリ・データベースによって生成された REDO データを

アーカイブするよう指示。

/arch1/denver/内のローカル・アーカイブ

REDO ログ・ファイルにローカル・オンライン

REDO ログ・ファイルからロジカル・スタンバ

イ・データベースによって生成された REDOデータをアーカイブするよう指示。

LOG_ARCHIVE_DEST_2 無視。chicagoがスタンバイ・ロール

で稼働している場合にのみ有効。（スイッチオーバーを実行するには、このサイトでスタンバイ REDO ログを構成す

る必要があります。）

/arch2/denver/内のローカル・アーカイブ

REDO ログ・ファイルにスタンバイ REDO ロ

グ・ファイルからの REDO データをアーカイブ


LOG_ARCHIVE_DEST_3 リモート・ロジカル・スタンバイ宛先denverに REDO データを転送するよう

指示。

無視。denverがプライマリ・ロールで稼働して

いる場合にのみ有効。

STANDBY_ARCHIVE_DEST 無視。chicagoがスタンバイ・ロール

で稼働している場合にのみ有効。

/arch2/denver/内のアーカイブ REDO ログ・

ファイルにプライマリ・データベースから受信した REDO データを直接アーカイブするよう指示。



図図図図 12-4 ロールの推移後のプライマリおよびロジカル・スタンバイ・データベースロールの推移後のプライマリおよびロジカル・スタンバイ・データベースロールの推移後のプライマリおよびロジカル・スタンバイ・データベースロールの推移後のプライマリおよびロジカル・スタンバイ・データベース


Chicago データベースデータベースデータベースデータベース（ロジカル・スタンバイ・ロール）（ロジカル・スタンバイ・ロール）（ロジカル・スタンバイ・ロール）（ロジカル・スタンバイ・ロール）

Denver データベースデータベースデータベースデータベース（プライマリ・ロール）（プライマリ・ロール）（プライマリ・ロール）（プライマリ・ロール）

LOG_ARCHIVE_DEST_1 /arch1/chicago/内のローカル・アーカイ

ブ REDO ログ・ファイルにローカル・オン

ライン REDO ログ・ファイルからロジカル・

スタンバイ・データベースによって生成された REDO データをアーカイブするよう指示。

/arch1/denver/内のローカル・アーカイ

ブ REDO ログ・ファイルにローカル・オン

ライン REDO ログ・ファイルからの REDOデータをアーカイブするよう指示。

LOG_ARCHIVE_DEST_2 /arch2/chicago/内のアーカイブ REDOログ・ファイルにスタンバイ REDO ログ・

ファイルからの REDO データをアーカイブ


無視。denverがスタンバイ・ロールで稼働


LOG_ARCHIVE_DEST_3 無視。chicagoがプライマリ・ロールで稼


リモート・ロジカル・スタンバイ宛先chicagoに REDO データを転送するよう指

示。

STANDBY_ARCHIVE_DEST /arch2/chicago/内のアーカイブ REDOログ・ファイルにプライマリ・データベースから受信した REDO データを直接アーカイ

ブするよう指示。

無視。denverがスタンバイ・ロールで稼働




12.1.3 フィジカルおよびロジカル・スタンバイ・データベースの構成フィジカルおよびロジカル・スタンバイ・データベースの構成フィジカルおよびロジカル・スタンバイ・データベースの構成フィジカルおよびロジカル・スタンバイ・データベースの構成図 12-5 に、プライマリ・ロールで稼働している chicagoデータベース、フィジカル・スタンバイ・ロールで稼働している bostonデータベース、およびロジカル・スタンバイ・データベース・ロールで稼働している denverデータベースを示します。初期化パラメータは各システムの下に示されています。グレー表示されているコンポーネントは、そのデータベースの現行ロールではアクティブないことを示します。この例は、スイッチオーバーが chicagoとbostonの間でのみ発生することを前提としています。この構成では、denverロジカル・スタンバイ・データベースはレポート用データベースのみを目的としています。denverは、スイッチオーバーの対象にはならず、プライマリ・ロールで稼働することもありません。

図図図図 12-5 フィジカルおよびロジカル・スタンバイ・データベースを備えたプライマリ・データベースの構成フィジカルおよびロジカル・スタンバイ・データベースを備えたプライマリ・データベースの構成フィジカルおよびロジカル・スタンバイ・データベースを備えたプライマリ・データベースの構成フィジカルおよびロジカル・スタンバイ・データベースを備えたプライマリ・データベースの構成

表 12-4 に、図 12-5 で示されたデータベースの初期化パラメータを示します。

表表表表 12-4 プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベープライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベープライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベープライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベー

スの初期化パラメータスの初期化パラメータスの初期化パラメータスの初期化パラメータ

Boston データベースデータベースデータベースデータベース（スタンバイ・ロール）（スタンバイ・ロール）（スタンバイ・ロール）（スタンバイ・ロール）


Denver データベースデータベースデータベースデータベース（スタンバイ・ロール）（スタンバイ・ロール）（スタンバイ・ロール）（スタンバイ・ロール）

DB_UNIQUE_NAME=bostonLOG_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=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_DEST_STATE_3=ENABLESTANDBY_ARCHIVE_DEST=/arch1/boston/REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

DB_UNIQUE_NAME=chicagoLOG_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=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_DEST_STATE_3=ENABLESTANDBY_ARCHIVE_DEST=/arch1/chicago/REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

DB_UNIQUE_NAME=denverLOG_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=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLESTANDBY_ARCHIVE_DEST=/arch2/denver/REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE




図 12-6 に、スイッチオーバーによって chicagoデータベースがスタンバイ・ロールに変更され、bostonデータベースがプライマリ・ロールに変更された後の同一構成を示します。

図図図図 12-6 ロールの推移後のプライマリ、フィジカルおよびロジカル・スタンバイ・データベースロールの推移後のプライマリ、フィジカルおよびロジカル・スタンバイ・データベースロールの推移後のプライマリ、フィジカルおよびロジカル・スタンバイ・データベースロールの推移後のプライマリ、フィジカルおよびロジカル・スタンバイ・データベース


Boston データベースデータベースデータベースデータベース（スタンバイ・ロール）（スタンバイ・ロール）（スタンバイ・ロール）（スタンバイ・ロール）


LOG_ARCHIVE_DEST_1 /arch1/chicago/内の

ローカル・アーカイブREDO ログ・ファイルにオ

ンライン REDO ログ・ファ

イルからの REDO データを


/arch1/boston/内のロー

カル・アーカイブ REDO ロ

グ・ファイルにスタンバイREDO ログ・ファイルから

の REDO データをアーカイ


/arch1/denver/内のローカ

ル・アーカイブ REDO ログ・

ファイルにローカル・オンライン REDO ログ・ファイルか

らロジカル・スタンバイ・データベースによって生成された REDO データをアーカイ


LOG_ARCHIVE_DEST_2 リモート・ロジカル・スタンバイ宛先 denverに

REDO データを転送するよ

う指示。

無視。bostonがプライマ

リ・ロールで稼働している場合にのみ有効。

/arch2/denver/内のローカ

ル・アーカイブ REDO ログ・

ファイルにスタンバイ REDOログ・ファイルからの REDOデータをアーカイブするよう指示。

LOG_ARCHIVE_DEST_3 リモート・フィジカル・スタンバイ宛先 bostonに


う指示。

無視。bostonがプライマ


このデータベースに対しては定義なし。

STANDBY_ARCHIVE_DEST 無視。スタンバイ・ロールでのみ有効。

/arch1/boston/内のアー

カイブ REDO ログ・ファイ

ルにプライマリ・データベースから受信した REDO デー

タを直接アーカイブするよう指示。

/arch2/denver/内のアーカ

イブ REDO ログ・ファイルに

プライマリ・データベースから受信した REDO データを直

接アーカイブするよう指示。




12.1.4 各宛先について現行の各宛先について現行の各宛先について現行の各宛先について現行の 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------- --------------- ------------ ----------------1 ALL_LOGFILES ALL_ROLES YES2 STANDBY_LOGFILE STANDBY_ROLE WRONG VALID_TYPE3 ONLINE_LOGFILE STANDBY_ROLE WRONG VALID_ROLE4 ALL_LOGFILES ALL_ROLES UNKNOWN5 ALL_LOGFILES ALL_ROLES UNKNOWN6 ALL_LOGFILES ALL_ROLES UNKNOWN7 ALL_LOGFILES ALL_ROLES UNKNOWN8 ALL_LOGFILES ALL_ROLES UNKNOWN9 ALL_LOGFILES ALL_ROLES UNKNOWN10 ALL_LOGFILES ALL_ROLES UNKNOWN 10 rows selected.

Chicago データベースデータベースデータベースデータベース（スタンバイ・ロール）（スタンバイ・ロール）（スタンバイ・ロール）（スタンバイ・ロール）



LOG_ARCHIVE_DEST_1 /arch1/chicago/内のロー


グ・ファイルにスタンバイREDO ログ・ファイルからの

REDO データをアーカイブす

るよう指示。

/arch1/boston/内のロー


グ・ファイルにオンラインREDO ログ・ファイルから

の REDO データをアーカイ


/arch1/denver/内のロー


グ・ファイルにローカル・オンライン REDO ログ・ファ

イルからロジカル・スタンバイ・データベースによって生成された REDO データを


LOG_ARCHIVE_DEST_2 無視。chicagoがプライマ


リモート・ロジカル・スタンバイ宛先 denverに


う指示。

/arch2/denver/内のロー


グ・ファイルにスタンバイREDO ログ・ファイルからの

REDO データをアーカイブす

るよう指示。

LOG_ARCHIVE_DEST_3 無視。chicagoがプライマ


リモート・フィジカル・スタンバイ宛先 chicagoに


う指示。

このデータベースに対しては定義なし。

STANDBY_ARCHIVE_DEST /arch1/chicago/内のアー




無視。スタンバイ・ロールでのみ有効。

/arch2/denver/内のアー





ロールの推移に適なスタンバイ・データベースの選択

例 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 構成に継続して含まれるように、新しいプライマリ・データベースのコピーから再作成する必要があります。

これらの制限があるため、ロジカル・スタンバイ・データベースをロールの推移のターゲットとして考慮するのは、次のような特別な状況の場合に限定してください。

� 構成にロジカル・スタンバイ・データベースのみが含まれている場合。

� スタンバイ・データベースのプライマリ・ロールへの迅速なフェイルオーバーが重要で、構成内の新のロジカル・スタンバイ・データベースが構成内の新のフィジカル・スタンバイ・データベースに比較して大幅に更新されている場合。

フィジカルまたはロジカル・スタンバイ・データベースの使用を決定すると、ロールの推移のターゲットとして選択する特定のスタンバイ・データベースは、スタンバイ・データベースにある新のプライマリ・データベースの変更量によって判断されます。プライマリ・データベースはスイッチオーバー中もアクセス可能な状態であるため、データの消失はありません。また、スイッチオーバー中に使用されるスタンバイ・データベースの選択によって影響を受けるのは、スイッチオーバーの完了に必要な時間のみです。ただし、フェイルオーバーの場合、スタンバイ・データベースの選択では、データ消失に関するリスクの増加と、スタンバイ・データベースのプライマリ・ロールへの推移に必要な時間との間でトレードオフが必要となります。

関連項目関連項目関連項目関連項目 : スイッチオーバーとフェイルオーバーのターゲット・スタンバイ・データベースの選択に関する一般的なガイドラインは、7.1.2 項を参照してください。



12.2.1 例例例例 : フェイルオーバーに適なフィジカル・スタンバイ・データベースフェイルオーバーに適なフィジカル・スタンバイ・データベースフェイルオーバーに適なフィジカル・スタンバイ・データベースフェイルオーバーに適なフィジカル・スタンバイ・データベース障害時に 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 ログ・ファイル 1 hq_srl1.f sat_srl1.f nyc_srl1.f



プライマリ保護モード大可用性該当なし該当なし

スタンバイ保護モード該当なし大可用性（同期）大パフォーマンス（非同期）

ネットワーク・サービス名（クライアント定義）

hq_net sat_net nyc_net

リスナー hq_listener sat_listener nyc_listener

注意注意注意注意 : ピーク・ワークロード時に HQ から NYC に REDO データを同期させて送信することは、プライマリ・データベースのパフォーマンスに影響を与える可能性があるため、ニューヨーク市のデータベースは大パフォーマンス・モードで動作しています。ただし、ニューヨーク市のスタンバイ・データベースは、スタンバイ REDO ログを使用しているため、フェイルオーバーの有効な候補とみなされたままです。



プライマリ・サイトがあるサンフランシスコでイベントが発生し、適時に修正できないような被害を受けたと仮定します。スタンバイ・データベースの 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---------- ---------- ---------- ---------- 1 14 234 16

このスタンバイ・データベースは、プライマリ・データベースから 249 ブロックの REDO データを受信しています。受信したブロック数を計算するには、BLOCKS列の値を BLOCK#列の値に加えて 1 を引きます。1 を引く理由は、ブロック番号 234 が受信した 16 ブロックに含まれているためです。

注意注意注意注意 : プライマリ・データベースが使用不可能であった期間によっては、前述の問合せで指定した行が戻らない場合があります。これは、RFS プロセスがネットワークの切断を検出し、プロセス自体が終了する場合があるためです。この場合の善策は、REDO データを同期モードで受信するように構成されたスタンバイ・データベースを常に選択することです。



手順手順手順手順 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 スタンバイ・データベースよスタンバイ・データベースよスタンバイ・データベースよスタンバイ・データベースよりも新しいかどうかを判断するりも新しいかどうかを判断するりも新しいかどうかを判断するりも新しいかどうかを判断する



手順手順手順手順 5 アーカイブアーカイブアーカイブアーカイブ REDO ログ・ファイルで使用可能なカレントログ・ファイルで使用可能なカレントログ・ファイルで使用可能なカレントログ・ファイルで使用可能なカレント REDO データの量を判別するデータの量を判別するデータの量を判別するデータの量を判別する

次のように、V$MANAGED_STANDBYビューの列を問い合せます。

SQL> SELECT THREAD#, SEQUENCE#, BLOCK#, BLOCKS 2> FROM V$MANAGED_STANDBY WHERE STATUS='RECEIVING';

THREAD# SEQUENCE# BLOCK# BLOCKS---------- ---------- ---------- ---------- 1 14 157 93

このスタンバイ・データベースも、プライマリ・データベースから 249 ブロックの REDO 情報を受信しています。受信したブロック数を計算するには、BLOCKS列の値を BLOCK#列の値に加えて 1 を引きます。1 を引く理由は、ブロック番号 157 が受信した 93 ブロックに含まれているためです。



手順手順手順手順 6 NYC データベースに適用した、または適用を保留しているアーカイブデータベースに適用した、または適用を保留しているアーカイブデータベースに適用した、または適用を保留しているアーカイブデータベースに適用した、または適用を保留しているアーカイブ 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_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 データはシアトルの場合よりも多数ですが、スタンバイ・データベースに適用されたデータはシアトルの場合より少数です。

手順手順手順手順 7 適なターゲット・スタンバイ・データベースを選択する適なターゲット・スタンバイ・データベースを選択する適なターゲット・スタンバイ・データベースを選択する適なターゲット・スタンバイ・データベースを選択する

ほとんどの場合、フェイルオーバーのターゲットとして選択するフィジカル・スタンバイ・データベースは、データ消失のリスクと、ロールの推移の実行に必要な時間とのバランスを備えている必要があります。この情報を分析して、この使用例で適なフェイルオーバー候補を決定するときに、次のことを考慮してください。

� フェイルオーバー時のデータ消失のリスクを小にするには、適なターゲット・スタンバイ・データベースとして NYC データベースを選択します。これは、手順 5 と 6 からわかるように、リカバリ可能な REDO が NYC サイトに多数存在するためです。

� フェイルオーバー操作時のプライマリ・データベース停止時間を小にするには、適なターゲット・スタンバイ・データベースとして SAT データベースを選択します。SAT データベースの方が適切な候補である理由は、手順 2 から 6 でわかるように、NYC データベースよりもアーカイブ REDO ログ・ファイルを 5 つ多く適用している点です。ただし、欠落しているアーカイブ REDO ログ・ファイル（この例ではログ 12）のコピーの取得と適用が不可能な場合は、SAT データベースを NYC データベースと同じ新の状態にすることはできません。したがって、未適用のデータ（この例ではログ・ファイル 12、13 およびログ・ファイル 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 /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 ログ・ファイルが正常に適用されたことを確認します。


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 ログ・ファイルが存在していることはありません。



2. ログ適用サービスを開始して、新のログ・ファイルを適用します。


3. V$ARCHIVED_LOGビューを再度問い合せて、アーカイブ REDO ログ・ファイルが正常に適用されたことを確認します。


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 ログ・ファイルが指定されるまで待機する必要があります。


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 フェイルオーバーを実行するフェイルオーバーを実行するフェイルオーバーを実行するフェイルオーバーを実行する

ログ適用サービスを停止し、選択したフィジカル・スタンバイ・データベースをプライマリ・ロールにフェイルオーバーする準備が整いました。

フィジカル・スタンバイ・データベースに対するフェイルオーバーの実行方法の詳細は、7.2.2項を参照してください。



12.2.2 例例例例 : フェイルオーバーに適なロジカル・スタンバイ・データベースフェイルオーバーに適なロジカル・スタンバイ・データベースフェイルオーバーに適なロジカル・スタンバイ・データベースフェイルオーバーに適なロジカル・スタンバイ・データベース障害時にロジカル・スタンバイ・データベースのみが使用可能な場合、重要な作業は、どのロジカル・スタンバイ・データベースがフェイルオーバーに適かを判断することです。適なターゲット・スタンバイ・データベースの判断に影響を与える環境上の要因は様々ですが、この使用例では、データ消失の査定を明確にするために、これらの要因が等しいと仮定します。ロジカル・スタンバイ・データベースの大可用性保護モードの詳細は、1.4 項を参照してください。

この使用例では、HQ プライマリ・データベースと 2 つのロジカル・スタンバイ・データベース（SAT と NYC）で構成した Data Guard 構成を前提に説明します。表 12-6 に、これらのデータベースに関する情報を示します。

次の手順に従って、ロジカル・スタンバイ・データベースのみで構成されている場合に、どのスタンバイ・データベースがフェイルオーバーに適な候補であるかを決定します。

手順手順手順手順 1 SAT ロジカル・スタンバイ・データベースに接続するロジカル・スタンバイ・データベースに接続するロジカル・スタンバイ・データベースに接続するロジカル・スタンバイ・データベースに接続する



手順手順手順手順 2 SAT データベースに適用された大のデータベースに適用された大のデータベースに適用された大のデータベースに適用された大の SCN と適用可能な大（新）のと適用可能な大（新）のと適用可能な大（新）のと適用可能な大（新）の SCN を判断を判断を判断を判断するするするする

V$LOGSTDBY_PROGRESSビューで、次の列を問い合せます。



表表表表 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



データベース・リンク（クライアント定義）

hq_link sat_link nyc_link

ネットワーク・サービス名（クライアント定義）

hq_net sat_net nyc_net

リスナー hq_listener sat_listener nyc_listener



手順手順手順手順 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 2 101579 101588 11:02:57 NO NO 1/oracle/dbs/hq_sat_3.log 3 101588 142065 11:02:01 NO NO 1/oracle/dbs/hq_sat_4.log 4 142065 142307 11:02:09 NO NO 1/oracle/dbs/hq_sat_5.log 5 142307 142739 11:02:47 YES YES 1/oracle/dbs/hq_sat_6.log 6 142739 143973 12:02:09 NO NO 1/oracle/dbs/hq_sat_7.log 7 143973 144042 01:02:00 NO NO 1/oracle/dbs/hq_sat_8.log 8 144042 144051 01:02:00 NO NO 1/oracle/dbs/hq_sat_9.log 9 144051 144054 01:02:15 NO NO 1/oracle/dbs/hq_sat_10.log 10 144054 144057 01:02:20 NO NO 1/oracle/dbs/hq_sat_11.log 11 144057 144060 01:02:25 NO NO 1/oracle/dbs/hq_sat_13.log 13 144089 144147 01:02:40 NO NO 1

手順 2 に記載されているログ・ファイル 11 の SCN144059 は、FIRST_CHANGE#列の値 144057と NEXT_CHANGE#列の値 144060 の間にあります。これは、ログ・ファイル 11 が現在適用中であることを示します。SEQ#列の順序番号にギャップがあることにも注意してください。この例の場合は、SAT データベースでアーカイブ REDO ログ・ファイル 12 が欠落していることを示しています。

手順手順手順手順 4 NYC データベースに接続するデータベースに接続するデータベースに接続するデータベースに接続する



手順手順手順手順 5 NYC データベースに適用された大のデータベースに適用された大のデータベースに適用された大のデータベースに適用された大の SCN と適用可能な大のと適用可能な大のと適用可能な大のと適用可能な大の SCN を判断するを判断するを判断するを判断する

V$LOGSTDBY_PROGRESSビューで、次の列を問い合せます。

SQL> SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS;APPLIED_SCN LATEST_SCN----------- ---------- 143970 144146

手順手順手順手順 6 NYC データベースで処理済または現在処理が保留中のログ・ファイルのリストを取得データベースで処理済または現在処理が保留中のログ・ファイルのリストを取得データベースで処理済または現在処理が保留中のログ・ファイルのリストを取得データベースで処理済または現在処理が保留中のログ・ファイルのリストを取得するするするする


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 2 101579 101588 11:02:58 NO NO 1/oracle/dbs/hq_nyc_3.log 3 101588 142065 11:02:02 NO NO 1/oracle/dbs/hq_nyc_4.log 4 142065 142307 11:02:10 NO NO 1/oracle/dbs/hq_nyc_5.log 5 142307 142739 11:02:48 YES YES 1/oracle/dbs/hq_nyc_6.log 6 142739 143973 12:02:10 NO NO 1/oracle/dbs/hq_nyc_7.log 7 143973 144042 01:02:11 NO NO 1/oracle/dbs/hq_nyc_8.log 8 144042 144051 01:02:01 NO NO 1/oracle/dbs/hq_nyc_9.log 9 144051 144054 01:02:16 NO NO 1/oracle/dbs/hq_nyc_10.log 10 144054 144057 01:02:21 NO NO 1



/oracle/dbs/hq_nyc_11.log 11 144057 144060 01:02:26 NO NO 1/oracle/dbs/hq_nyc_12.log 12 144060 144089 01:02:30 NO NO 1/oracle/dbs/hq_nyc_13.log 13 144089 144147 01:02:41 NO NO 1

手順 5 に記載されているログ・ファイル 6 の SCN143970 は、FIRST_CHANGE#列の値 142739と NEXT_CHANGE#列の値 143973 の間にあります。これは、ログ・ファイル 6 が現在適用中であることを示します。処理が残っているログ・ファイルの順序番号にギャップがないことも注意してください。

手順手順手順手順 7 適なターゲット・スタンバイ・データベースを選択する適なターゲット・スタンバイ・データベースを選択する適なターゲット・スタンバイ・データベースを選択する適なターゲット・スタンバイ・データベースを選択する

ほとんどの場合、フェイルオーバーのターゲットとして選択するロジカル・スタンバイ・データベースは、データ消失のリスクと、ロールの推移の実行に必要な時間とのバランスを備えている必要があります。この情報を分析して、この使用例で適なフェイルオーバー候補を決定するときに、次のことを考慮してください。

� フェイルオーバー時のデータ消失のリスクを小にするには、適なターゲット・スタンバイ・データベースとして NYC データベースを選択します。これは、手順 5 と 6 からわかるように、リカバリ可能なアーカイブ REDO ログ・ファイルが NYC サイトに多数存在するためです。

� フェイルオーバー時のプライマリ・データベース停止時間を小にするには、適なターゲット・スタンバイ・データベースとして SAT データベースを選択します。このデータベースの方が適切な候補である理由は、手順 2 から 6 の問合せでわかるように、SAT データベースの方がアーカイブ REDO ログ・ファイルを NYC データベースより 5 つ多く適用しているためです（ただし、NYC データベースによるアーカイブ REDO ログ・ファイルの受信にかかった遅延（ラグ）は 1 秒ほどです）。ただし、欠落しているアーカイブ REDOログ・ファイル（この例ではログ・ファイル 12）のコピーの取得と適用が不可能な場合は、SAT データベースを NYC データベースと同じ新の状態にすることはできません。したがって、リカバリされないデータ（この例ではログ・ファイル 12、13 およびログ・ファイル 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---- 1 oracle dbs 333280 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';





5. V$LOGSTDBY_PROGRESSビューを問い合せて SAT データベースで適用済の大の SCN を判断し、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---- 1 oracle dbs 333330 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';



4. V$LOGSTDBY_PROGRESSビューを問い合せて NYC データベースで適用済の大の SCNを判別し、APPLIED_SCN列の値が LATEST_SCN列の値と等しいかどうかを調べます。



SCN の値が一致しているため、プライマリ・データベースの現在のログ・ファイルと、NYC データベースで受信され適用された後のログ・ファイルの間の遅延（ラグ）がなくなったことを確認できます。

手順手順手順手順 9 フェイルオーバーを実行するフェイルオーバーを実行するフェイルオーバーを実行するフェイルオーバーを実行する

ログ適用サービスを停止し、選択したロジカル・スタンバイ・データベースをプライマリ・ロールにフェイルオーバーする準備が整いました。

フェイルオーバーの実行方法の詳細は、7.3.2 項を参照してください。


新規プライマリ・データベースをサポートするロジカル・スタンバイ・データベースの構成

12.3 新規プライマリ・データベースをサポートするロジカル・新規プライマリ・データベースをサポートするロジカル・新規プライマリ・データベースをサポートするロジカル・新規プライマリ・データベースをサポートするロジカル・スタンバイ・データベースの構成スタンバイ・データベースの構成スタンバイ・データベースの構成スタンバイ・データベースの構成

この項では、プライマリ・データベースを別のスタンバイ・データベースにフェイルオーバーした後に、ロジカル・スタンバイ・データベースで実行する必要のある手順について説明します。フェイルオーバーの発生後、ロジカル・スタンバイ・データベースは、元のプライマリ・データベースからの後の REDO が適用されるまで、新規プライマリ・データベースのスタンバイ・データベースとして機能できません。これは、フェイルオーバー中に新規のプライマリ・データベースで後の REDO が適用される場合と同じです。実行する必要のある手順は、新規プライマリ・データベースがフェイルオーバー前にフィジカル・スタンバイ・データベースであったかロジカル・スタンバイ・データベースであったかに応じて異なります。

� 12.3.1 項「新規プライマリ・データベースがフィジカル・スタンバイ・データベースだった場合」

� 12.3.2 項「新規プライマリ・データベースがロジカル・スタンバイ・データベースだった場合」

12.3.1 新規プライマリ・データベースがフィジカル・スタンバイ・データ新規プライマリ・データベースがフィジカル・スタンバイ・データ新規プライマリ・データベースがフィジカル・スタンバイ・データ新規プライマリ・データベースがフィジカル・スタンバイ・データベースだった場合ベースだった場合ベースだった場合ベースだった場合

この使用例では、フェイルオーバー後の NYC データベースを使用して SAT ロジカル・スタンバイ・データベースを構成する方法について説明します。この使用例は、12.2.2 項で説明した例の続きです。ただし、この例では、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-16109メッセージが戻され、alert.log に「LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required.」という警告が書き込まれる場合は、次の手順を実行します。

1. データベースを警告に示された SCN までフラッシュバックします。

2. 続行する前に、この手順を繰り返します。

ロジカル・スタンバイ・データベースを適用 SCN までフラッシュバックする方法の例は、12.4.3 項を参照してください。



手順手順手順手順 3 プライマリ・データベースでアーカイブを使用可能にするプライマリ・データベースでアーカイブを使用可能にするプライマリ・データベースでアーカイブを使用可能にするプライマリ・データベースでアーカイブを使用可能にする


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;




この文は、常にリアルタイム適用オプションを指定せずに発行する必要があることに注意してください。手順 4 で戻された過去の WAIT_FOR_SCNが SQL Apply により適用されるまで待機した後で、リアルタイム適用を有効化する必要があります。ロジカル・スタンバイ・データベースでリアルタイム適用を安全に再開できる時点を判断するには、V$LOGSTDBY_PROGRESSビューを監視します。


戻される値が手順 4 で戻された WAIT_FOR_SCN値以上の場合は、SQL Apply を停止し、リアルタイム適用オプションを指定して再開できます。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

12.3.2 新規プライマリ・データベースがロジカル・スタンバイ・データベース新規プライマリ・データベースがロジカル・スタンバイ・データベース新規プライマリ・データベースがロジカル・スタンバイ・データベース新規プライマリ・データベースがロジカル・スタンバイ・データベースだった場合だった場合だった場合だった場合

この使用例では、フェイルオーバー後の NYC データベースを使用して SAT ロジカル・スタンバイ・データベースを構成する方法について説明します。この使用例は、12.2.2 項で説明した例の続きです。ただし、この例では、NYC データベースはフェイルオーバー前はロジカル・スタンバイ・データベースでした。

新規プライマリ・データベースを使用してロジカル・スタンバイ・データベースを構成する手順は、次のとおりです。

手順手順手順手順 1 新規プライマリ・データベースで、ロジカル・スタンバイ・データベースのサポート準新規プライマリ・データベースで、ロジカル・スタンバイ・データベースのサポート準新規プライマリ・データベースで、ロジカル・スタンバイ・データベースのサポート準新規プライマリ・データベースで、ロジカル・スタンバイ・データベースのサポート準備が完了していることを確認する備が完了していることを確認する備が完了していることを確認する備が完了していることを確認する

NYC データベースで、次の問合せにより値 READYが戻されることを確認します。それ以外の場合、LSP1 バックグラウンド・プロセスの処理が完了しておらず、このロジカル・スタンバイ・データベースの構成は待機する必要があります。次に例を示します。

SQL> SELECT VALUE FROM DBA_LOGSTDBY_PARAMETERS WHERE 2> NAME = 'REINSTATEMENT_STATUS';

VALUE--------------------READY

注意注意注意注意 : VALUE列に NOT POSSIBLEが含まれている場合は、新規プライマリ・データベースでロジカル・スタンバイ・データベースを構成できず、データベースを元に戻す必要があることを意味します。



手順手順手順手順 2 プライマリ・データベースからのアーカイブを使用不可にするプライマリ・データベースからのアーカイブを使用不可にするプライマリ・データベースからのアーカイブを使用不可にするプライマリ・データベースからのアーカイブを使用不可にする


SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=DEFER;SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

手順手順手順手順 3 ロジカル・スタンバイ・データベースが新規プライマリ・データベースのスタンバイ・ロジカル・スタンバイ・データベースが新規プライマリ・データベースのスタンバイ・ロジカル・スタンバイ・データベースが新規プライマリ・データベースのスタンバイ・ロジカル・スタンバイ・データベースが新規プライマリ・データベースのスタンバイ・データベースとして機能できることを確認するデータベースとして機能できることを確認するデータベースとして機能できることを確認するデータベースとして機能できることを確認する


SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY(- former_standby_type => 'LOGICAL' - dblink => 'nyc_link');

手順手順手順手順 4 ローカル・システムにコピーする必要のあるログ・ファイルを判別するローカル・システムにコピーする必要のあるログ・ファイルを判別するローカル・システムにコピーする必要のあるログ・ファイルを判別するローカル・システムにコピーする必要のあるログ・ファイルを判別する

SAT データベースで、DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARYプロシージャの出力を調べます。このプロシージャでは、ローカル・システムにコピーする必要のあるログ・ファイルが識別されます。手順 3 でフェイルオーバーを非データ消失フェイルオーバーとして識別した場合は、表示されたログ・ファイルを新規プライマリ・データベースからコピーする必要があります。他のロジカル・スタンバイ・データベースまたは前のプライマリ・データベースからは取得しないでください。たとえば、Linux システムでは、grepコマンドを入力します。

%grep 'LOGSTDBY: Terminal log' alert_sat.logLOGSTDBY: 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 端末のログをロジカル・スタンバイ・データベースに登録する端末のログをロジカル・スタンバイ・データベースに登録する端末のログをロジカル・スタンバイ・データベースに登録する端末のログをロジカル・スタンバイ・データベースに登録する


SQL> ALTER DATABASE REGISTER OR REPLACE LOGICAL LOGFILE - '/net/sat/oracle/dbs/hq_sat_13.log';

注意注意注意注意 : ORA-16109メッセージが戻され、alert.log ファイルに「LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required.」という警告が書き込まれる場合は、次の手順を実行します。

1. データベースを警告に示された SCN までフラッシュバックします。

2. 続行する前に、この手順を繰り返します。

ロジカル・スタンバイ・データベースを適用 SCN までフラッシュバックする方法の例は、12.4.3 項を参照してください。

注意注意注意注意 : 前の手順を複数回実行した場合、関連があるのは後の試行で得られた出力のみです。ファイル・パスは新規プライマリ・データベースとの相対パスであり、ローカル・ファイル・システムでは解決できない場合があります。


フェイルオーバー後のフラッシュバック・データベースの使用



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 プライマリ・データベースでロジカル・スタンバイ・データベースへのアーカイブを使プライマリ・データベースでロジカル・スタンバイ・データベースへのアーカイブを使プライマリ・データベースでロジカル・スタンバイ・データベースへのアーカイブを使プライマリ・データベースでロジカル・スタンバイ・データベースへのアーカイブを使用可能にする用可能にする用可能にする用可能にする


SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=ENABLE;SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

12.4 フェイルオーバー後のフラッシュバック・データベースのフェイルオーバー後のフラッシュバック・データベースのフェイルオーバー後のフラッシュバック・データベースのフェイルオーバー後のフラッシュバック・データベースの使用使用使用使用

フェイルオーバーの発生後、元のプライマリ・データベースは、修正され、新しい構成のスタンバイ・データベースとして確立されるまで、Data Guard 構成に含められません。これを行うには、フラッシュバック・データベース機能を使用して、障害の発生したプライマリ・データベースを障害発生前の時点にフラッシュバックし、その後新しい構成内のフィジカルまたはロジカル・スタンバイ・データベースに変換します。次の各項で、次の内容を説明します。

� 障害が発生したプライマリ・データベースのフィジカル・スタンバイ・データベースへのフラッシュバック

� 障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへのフラッシュバック

� 特定の適用済 SCN へのロジカル・スタンバイ・データベースのフラッシュバック

注意注意注意注意 : フェイルオーバー前に、元のプライマリ・データベースでフラッシュバック・データベースが使用可能になっている必要があります。詳細は、『Oracle Database バックアップおよびリカバリ基礎』を参照してください。

関連項目関連項目関連項目関連項目 : 障害の発生したプライマリ・データベースを（フラッシュバック・データベースとして使用するかわりに）自動的に新規スタンバイ・データベースに戻す方法は、『Oracle Data Guard Broker』を参照してください。



12.4.1 障害が発生したプライマリ・データベースのフィジカル・スタンバイ・障害が発生したプライマリ・データベースのフィジカル・スタンバイ・障害が発生したプライマリ・データベースのフィジカル・スタンバイ・障害が発生したプライマリ・データベースのフィジカル・スタンバイ・データベースへのフラッシュバックデータベースへのフラッシュバックデータベースへのフラッシュバックデータベースへのフラッシュバック

次の手順では、ユーザーがすでにフィジカル・スタンバイ・データベースを使用したフェイルオーバーを実行済で、古いプライマリ・データベースでフラッシュバック・データベースが使用可能にされていることを前提としています。この手順では、古いプライマリ・データベースを新しいフィジカル・スタンバイ・データベースとして 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. データベースを停止して、再開します。


手順手順手順手順 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）でプライマリおよびスタンバ



イ・データベース・ロールの両方が VALID_FOR属性で設定されている場合、この手順を実行する必要はありません。これにより、Data Guard 構成は、ロールの推移後も正しく動作します。

手順手順手順手順 5 REDO Apply を開始するを開始するを開始するを開始する

新しいフィジカル・スタンバイ・データベースで REDO Apply またはリアルタイム適用を開始します。

� REDO Apply を開始する場合


� リアルタイム適用を開始する場合

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE DISCONNECT;

障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の（障害発生前の）ロールに推移できます。詳細は、7.2.1 項「フィジカル・スタンバイ・データベースが関与するスイッチオーバー」を参照してください。

12.4.2 障害が発生したプライマリ・データベースのロジカル・スタンバイ・障害が発生したプライマリ・データベースのロジカル・スタンバイ・障害が発生したプライマリ・データベースのロジカル・スタンバイ・障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへのフラッシュバックデータベースへのフラッシュバックデータベースへのフラッシュバックデータベースへのフラッシュバック

次の手順では、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;



手順手順手順手順 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;

これで、ロールの可逆的な推移が完了しました。

障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の（障害発生前の）ロールに推移できます。詳細は、7.3.1 項「ロジカル・スタンバイ・データベースが関与するスイッチオーバー」を参照してください。

12.4.3 特定の適用済特定の適用済特定の適用済特定の適用済 SCN へのロジカル・スタンバイ・データベースのフラッへのロジカル・スタンバイ・データベースのフラッへのロジカル・スタンバイ・データベースのフラッへのロジカル・スタンバイ・データベースのフラッシュバックシュバックシュバックシュバック

スタンバイ・データベースのメリットの 1 つは、プライマリ・データベース・サービスに影響を与えずに、スタンバイ・データベースでフラッシュバック・データベースを実行できることです。データベースを特定の時点までフラッシュバックするタスクは簡単ですが、ロジカル・スタンバイ・データベースでは、既知のトランザクションがコミットされる直前の時点までフラッシュバックする操作が必要になる場合があります。このような必要が生じるのは、フェイルオーバー後に新しいプライマリ・データベースを使用してロジカル・スタンバイ・データベースを構成する場合です。

次の手順では、フラッシュバック・データベースと SQL Apply を使用して既知の適用済 SCNまでリカバリする方法について説明します。

手順手順手順手順 1 Apply_SCN を含むログ・ファイルを識別するを含むログ・ファイルを識別するを含むログ・ファイルを識別するを含むログ・ファイルを識別する

ロジカル・スタンバイ・データベースで、次の問合せを発行し、Apply_SCNを含むログ・ファイルを識別します。

SQL> SELECT FILE_NAME FROM DBA_LOGSTDBY_LOG5> WHERE FIRST_CHANGE# <= APPLY_SCN6> AND NEXT_CHANGE# > APPLY_SCN7> 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:18 2005LOGMINER: Begin mining logfile: /net/sat/oracle/dbs/hq_sat_13.log


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 まで適用されたことを確認するまで適用されたことを確認するまで適用されたことを確認するまで適用されたことを確認する

次の問合せを発行します。


12.5 Open Resetlogs 文の発行後のフラッシュバック・データベース文の発行後のフラッシュバック・データベース文の発行後のフラッシュバック・データベース文の発行後のフラッシュバック・データベースの使用の使用の使用の使用

スタンバイ・データベースがリアルタイム適用を使用している Data Guard 構成で、プライマリ・データベースでエラーが発生したとします。この場合、同じエラーがスタンバイ・データベースにも適用されます。

ただし、フラッシュバック・データベースが使用可能になっている場合、プライマリおよびスタンバイ・データベースをエラー前の状態に戻せます。これには、ログ適用サービスを再開する前に、プライマリ・データベースで FLASHBACK DATABASEおよび OPEN RESETLOGS文を発行し、次に同様の FLASHBACK STANDBY DATABASE文をスタンバイ・データベースで発行します。（フラッシュバック・データベースが使用可能でない場合、第 3 章および第 4 章で説明されているように、プライマリ・データベースで Point-in-Time リカバリが実行された後、スタンバイ・データベースを再作成する必要があります。）

12.5.1 特定時点へのフィジカル・スタンバイ・データベースのフラッシュ特定時点へのフィジカル・スタンバイ・データベースのフラッシュ特定時点へのフィジカル・スタンバイ・データベースのフラッシュ特定時点へのフィジカル・スタンバイ・データベースのフラッシュバックバックバックバック

次の手順では、プライマリ・データベースで 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文に到達しても停止しないため、データベースのフラッシュバックは不要です。


Open Resetlogs 文の発行後のフラッシュバック・データベースの使用

手順手順手順手順 4 REDO Apply を再開するを再開するを再開するを再開する

フィジカル・スタンバイ・データベースで REDO Apply を開始するには、次の文を発行します。


スタンバイ・データベースはプライマリ・データベースから REDO を受信し適用できます。

12.5.2 プライマリのフラッシュバック後のロジカル・スタンバイ・データプライマリのフラッシュバック後のロジカル・スタンバイ・データプライマリのフラッシュバック後のロジカル・スタンバイ・データプライマリのフラッシュバック後のロジカル・スタンバイ・データベースのフラッシュバックベースのフラッシュバックベースのフラッシュバックベースのフラッシュバック

次の手順では、プライマリ・データベースをフラッシュバックし、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:18 2005LOGMINER: Begin mining logfile: /net/sat/oracle/dbs/hq_sat_146.log


フィジカル・スタンバイ・データベースを使用した読取り / 書込みテストとレポート生成

手順手順手順手順 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 まで適用されたことを確認するまで適用されたことを確認するまで適用されたことを確認するまで適用されたことを確認する

ロジカル・スタンバイ・データベースで、次の問合せを発行します。




12.6 フィジカル・スタンバイ・データベースを使用した読取りフィジカル・スタンバイ・データベースを使用した読取りフィジカル・スタンバイ・データベースを使用した読取りフィジカル・スタンバイ・データベースを使用した読取り /書込みテストとレポート生成書込みテストとレポート生成書込みテストとレポート生成書込みテストとレポート生成

Data Guard、リストア・ポイントおよびフラッシュバック・データベースを使用すると、フィジカル・スタンバイ・データベースを開発、レポート生成またはテストのために読取り / 書込みモードで一時的にオープンしてから、過去の特定時点までフラッシュバックして元に戻すことができます。データベースがフラッシュバックされると、Data Guard では自動的にスタンバイ・データベースをプライマリ・データベースと同期化します。プライマリ・データベースのバックアップ・コピーからフィジカル・スタンバイ・データベースを再作成する必要はありません。

図 12-7 に、フィジカル・スタンバイ・データベースを読取り / 書込み用クローン・データベースとしてアクティブ化して、プライマリ・データベースと再同期化し、後にフラッシュバックして元のフィジカル・スタンバイ・データベース・ロールに戻す様子を示します。このようにアクティブ化し、フラッシュバックして元に戻すというサイクルは、必要な回数だけ繰り返すことができます。

図図図図 12-7 テストおよびレポート生成用データベースとしてのフィジカル・スタンバイ・データベーステストおよびレポート生成用データベースとしてのフィジカル・スタンバイ・データベーステストおよびレポート生成用データベースとしてのフィジカル・スタンバイ・データベーステストおよびレポート生成用データベースとしてのフィジカル・スタンバイ・データベースの使用の使用の使用の使用



フィジカル・スタンバイ・データベースを本番データベースとしてアクティブ化し、後でプライマリ・データベースと再同期化する手順は、次のとおりです。

手順手順手順手順 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 がフィジカル・スタンバイ・データベースにアーカイブされるように、ログを切り替えます。


スタンバイ REDO ログ・ファイルを使用する場合、データベースをリストア・ポイントに正常にフラッシュバックするには、この手順が重要です。

2. アクティブ化するスタンバイを指しているログ・アーカイブ先を遅延させます。

プライマリ・データベース（これが Real Application Clusters の場合は全インスタンス上）で、オープンするフィジカル・スタンバイ・データベースに関連付けられている宛先へのREDO データのアーカイブを遅延させます。次に例を示します。

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;

注意注意注意注意 : データベースがアクティブ化されている間は、プライマリ・データベースから REDO データを受信せず、障害時保護を提供できません。プライマリ・データベースがデータ消失に対して引き続き保護されるように、構成内に複数のフィジカル・スタンバイ・データベースを加えるようにしてください。



手順手順手順手順 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 アクティブ化されたデータベースをレポートまたはテストに使用するアクティブ化されたデータベースをレポートまたはテストに使用するアクティブ化されたデータベースをレポートまたはテストに使用するアクティブ化されたデータベースをレポートまたはテストに使用する

スタンバイ・データベースがアクティブ化された後、プライマリ・データベースに依存せずにレポート生成ツールを実行したり、他のテストやアクティビティを数日から数週間実行できます。

また、アクティブ化されたデータベースに格納された結果は、後でデータベースをフラッシュバックすると消失します。保存する必要のある結果は、アクティブ化されたデータベースをフラッシュバックする前に、他のデータベースにコピーする必要があります。

手順手順手順手順 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;

注意注意注意注意 : データベースがアクティブ化されている間は、プライマリ・データベースから REDO データを受信せず、障害時保護を提供できません。プライマリ・データベースがデータ消失に対して引き続き保護されるように、構成内に複数のフィジカル・スタンバイ・データベースを加えるようにしてください。



手順手順手順手順 6 スタンバイ・データベースをプライマリ・データベースと一致させるスタンバイ・データベースをプライマリ・データベースと一致させるスタンバイ・データベースをプライマリ・データベースと一致させるスタンバイ・データベースをプライマリ・データベースと一致させる

使用する方法は、アクティブ化されたスタンバイ・データベースが REDO データの適用に関してプライマリ・データベースからどの程度遅れているかに応じて異なります。

� アーカイブ・ギャップ解消に、欠落しているアーカイブ REDO ログ・ファイルをすべてフェッチさせ、REDO Apply でギャップを適用できるようにします。

アクティブ化されたデータベースが元のプライマリ・データベースからあまり遅れていない場合は、スタンバイ・データベースで次の文を発行し、プライマリ・データベースと再同期化して REDO Apply を再開します。次に例を示します。


その後、手順 7 に進みます。

� プライマリ・データベースで増分バックアップを作成してスタンバイ・データベースに適用します。

アクティブ化されたデータベースが元のプライマリ・データベースから大幅に遅れている場合（十分なログ・ファイルが使用可能でない場合など）は、プライマリ・データベースから増分バックアップを作成して、スタンバイ・データベースに適用できます。Recovery Manager の増分バックアップを使用してスタンバイ・データベースをプライマリ・データベースと再同期化する方法については、12.7.1 項を参照してください。

スタンバイ・データベースに増分バックアップを適用した後、通常はスタンバイ・データベースにさらに REDO を適用し、フィジカル・スタンバイ・データベースを再び読取り /書込みテストおよびレポート生成用にアクティブ化する必要があります。さらに、増分バックアップの実行中にプライマリ・データベースにより生成された REDO の適用も必要になる場合があります。適用しないと、ALTER DATABSE ACTIVATE STANDBY DATABASEを発行した場合にエラーが戻されます。

手順手順手順手順 7 フィジカル・スタンバイ・データベースの宛先へのアーカイブを再び使用可能にするフィジカル・スタンバイ・データベースの宛先へのアーカイブを再び使用可能にするフィジカル・スタンバイ・データベースの宛先へのアーカイブを再び使用可能にするフィジカル・スタンバイ・データベースの宛先へのアーカイブを再び使用可能にする

プライマリ・データベースで、次の文を発行して、フィジカル・スタンバイ・データベースへのアーカイブを再び使用可能にします。

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

注意注意注意注意 : スタンバイ・データベースがプライマリ・データベースから大幅に遅れている場合は、12.7.1 項で説明する手順でプライマリ・データベースから作成した増分バックアップを適用する方が迅速な場合があります。


Recovery Manager の増分バックアップによるフィジカル・スタンバイ・データベースのロールフォワード

12.7 Recovery Manager の増分バックアップによるフィジカル・の増分バックアップによるフィジカル・の増分バックアップによるフィジカル・の増分バックアップによるフィジカル・スタンバイ・データベースのロールフォワードスタンバイ・データベースのロールフォワードスタンバイ・データベースのロールフォワードスタンバイ・データベースのロールフォワード

Recovery Manager の増分バックアップを使用して、フィジカル・スタンバイ・データベースをプライマリ・データベースと同期化できる場合があります。Recovery Manager の BACKUP INCREMENTAL FROM SCNコマンドを使用すると、プライマリ・データベースでスタンバイ・データベースの現行 SCN から始まるバックアップを作成し、それを使用してスタンバイ・データベースをロールフォワードできます。

次の各項では、Recovery Manager の増分バックアップが役立つ状況について説明します。

� フィジカル・スタンバイ・データベースがプライマリ・データベースから大幅に遅れている場合

� フィジカル・スタンバイ・データベースのデータファイルのサブセットにロギングなしの変更がある場合

� フィジカル・スタンバイ・データベースの広範囲にロギングなしの変更がある場合

12.7.1 フィジカル・スタンバイ・データベースがプライマリ・データベースフィジカル・スタンバイ・データベースがプライマリ・データベースフィジカル・スタンバイ・データベースがプライマリ・データベースフィジカル・スタンバイ・データベースがプライマリ・データベースから大幅に遅れている場合から大幅に遅れている場合から大幅に遅れている場合から大幅に遅れている場合

フィジカル・スタンバイ・データベースがプライマリ・データベースから大幅に遅れている場合は、Recovery Manager の増分バックアップを使用すると REDO ログ適用より高速でスタンバイ・データベースをロールフォワードできます。この手順では、Recovery Manager のBACKUP INCREMENTAL FROM SCNコマンドを使用して、スタンバイ・データベースの現行SCN から始まる増分バックアップをプライマリ・データベースで作成し、それを使用してスタンバイ・データベースをロールフォワードします。

1. スタンバイ・データベースで、管理リカバリ・プロセス（MRP）を停止します。


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';

関連項目関連項目関連項目関連項目 : Recovery Manager の増分バックアップの詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

注意注意注意注意 : フィジカル・スタンバイ・データベースのアーカイブ REDO データが消失または破損した場合や、解消できないアーカイブ・ギャップがある場合も、この項で説明する手順に従って問題を解決できます。



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;

注意注意注意注意 : Recovery Manager では、増分バックアップはソース・データベースのバックアップ対策の一部とはみなされません。したがって、次のようになります。

� このバックアップは、ソース・データベースで通常の RECOVER DATABASE操作に使用するには適していません。

� このバックアップは、ソース・データベースではカタログに追加されません。

� ディスク・バックアップのデフォルトとしてフラッシュ・リカバリ領域または他のバックアップ先が定義されている場合も、このコマンドで生成されるバックアップ・セットはデフォルトで /dbsディレクトリに書き込まれます。

� この増分バックアップを使用するには、ディスクに作成する必要があります。増分バックアップをスタンバイ・データベースに移動するときに、スタンバイ・データベースでカタログに追加する必要があります。詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。テープ上のバックアップはカタログに追加できません。



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 を再開します。


12.7.2 フィジカル・スタンバイ・データベースのデータファイルのサブセットフィジカル・スタンバイ・データベースのデータファイルのサブセットフィジカル・スタンバイ・データベースのデータファイルのサブセットフィジカル・スタンバイ・データベースのデータファイルのサブセットにロギングなしの変更がある場合にロギングなしの変更がある場合にロギングなしの変更がある場合にロギングなしの変更がある場合

ロギングなしの変更が小さいサブセットに適用されたフィジカル・スタンバイ・データベースをロールフォワードする手順は、次のとおりです。

1. スタンバイ・データベースで V$DATAFILEビューを問い合せ、ロギングなしの変更が適用されたファイルをリストします。次に例を示します。

SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE 2> WHERE FIRST_NONLOGGED_SCN > 0;

FILE# FIRST_NONLOGGED_SCN---------- ------------------- 4 225979 5 230184

2. スタンバイ・データベースで REDO Apply を停止します。


3. スタンバイ・データベースで、ロギングなしの変更を含むデータファイル（手順 1 で記録）をオフラインにします。これらのデータファイルをオフラインにすると、増分バックアップの実行中に破損ブロックの REDO データがスキップされなくなります。

SQL> ALTER DATABASE DATAFILE 4 OFFLINE FOR DROP;SQL> ALTER DATABASE DATAFILE 5 OFFLINE FOR DROP;

4. スタンバイ・データベースで REDO Apply を開始します。




5. Recovery Manager ターゲットとしてプライマリ・データベースに接続し、FIRST_NONLOGGED_SCN列に表示されたデータファイルごとに（手順 1 で記録）、増分バックアップを作成します。次に例を示します。

RMAN> BACKUP INCREMENTAL FROM SCN 225979 DATAFILE 4 FORMAT '/tmp/ForStandby_%U' TAG 'FOR STANDBY';RMAN> BACKUP INCREMENTAL FROM SCN 230184 DATAFILE 5 FORMAT '/tmp/ForStandby_%U' TAG 'FOR STANDBY';

6. プライマリ・システムに作成されたすべてのバックアップ・セットを、スタンバイ・システムに転送します。（複数のバックアップ・ファイルが作成されている場合があることに注意してください。）

SCP /tmp/ForStandby_* standby:/tmp

7. Recovery Manager ターゲットとしてフィジカル・スタンバイ・データベースに接続し、すべての増分バックアップ・ピースをカタログに追加します。次に例を示します。

RMAN> CATALOG START WITH '/tmp/ForStandby_';



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（ゼロ）行が戻されます。


12. スタンバイ・システムから増分バックアップを削除します。

RMAN> DELETE BACKUP TAG 'FOR STANDBY';

13. プライマリ・システムから増分バックアップを手動で削除します。たとえば、次の例ではLinux の rmコマンドを使用しています。

rm /tmp/ForStandby_*


SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;



12.7.3 フィジカル・スタンバイ・データベースの広範囲にロギングなしの変更フィジカル・スタンバイ・データベースの広範囲にロギングなしの変更フィジカル・スタンバイ・データベースの広範囲にロギングなしの変更フィジカル・スタンバイ・データベースの広範囲にロギングなしの変更がある場合がある場合がある場合がある場合

ロギングなしの変更が大部分に適用されたフィジカル・スタンバイ・データベースをロールフォワードする手順は、次のとおりです。

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)------------------------ 223948



3. Recovery Manager ターゲットとしてプライマリ・データベースに接続している間に、小の FIRST_NONLOGGED_SCN（手順 1 で記録）から増分バックアップを作成します。

RMAN> BACKUP INCREMENTAL FROM SCN 223948 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（ゼロ）の行が戻されます。


8. スタンバイ・システムから増分バックアップを削除します。

RMAN> DELETE BACKUP TAG 'FOR STANDBY';

9. プライマリ・システムから増分バックアップを手動で削除します。たとえば、次の例ではLinux の rmコマンドを使用してバックアップを削除しています。

rm /tmp/ForStandby_*




タイム・ラグのあるフィジカル・スタンバイ・データベースの使用

12.8 タイム・ラグのあるフィジカル・スタンバイ・データベースタイム・ラグのあるフィジカル・スタンバイ・データベースタイム・ラグのあるフィジカル・スタンバイ・データベースタイム・ラグのあるフィジカル・スタンバイ・データベースの使用の使用の使用の使用

ログ適用サービスがスタンバイ・データベースで実行されている場合、デフォルトでは、REDO データはアーカイブ・ログ・ファイルに書き込まれて適用されるか、リアルタイム適用が使用可能であれば、REDO はプライマリ・データベースからの送信時にスタンバイ・データベースへ書き込まれます。ただし、プライマリ・サイトのオンライン REDO ログ・ファイルのアーカイブとスタンバイ・サイトのアーカイブ REDO ログ・ファイルの適用の間にタイム・ラグを作成することが必要な場合があります。タイム・ラグによって、プライマリ・サイトからスタンバイ・サイトへ破損したまたは誤ったデータが送られてもスタンバイ・データベースを保護できます。タイム・ディレイを設定すると、スタンバイ・データベースへの REDO データの転送が遅延することはありません。かわりに、指定したタイム・ラグは、REDO データがスタンバイ宛先で完全にアーカイブされたときに開始します。

たとえば、毎晩プライマリ・データベースでバッチ・ジョブを実行するとします。誤ってバッチ・ジョブを 2 回実行してしまい、しかも 2 回の実行が完了するまでその誤操作に気づかなかったとします。理想的には、バッチ・ジョブを開始する前の状態までデータベースをロールバックする必要があります。タイム・ラグのあるスタンバイ・データベースを持つプライマリ・データベースを使用すると、リカバリに役立ちます。タイム・ラグのあるスタンバイ・データベースにフェイルオーバーして、それを新規のプライマリ・データベースとして使用できます。

タイム・ラグのあるスタンバイ・データベースを作成するには、プライマリ・データベースの初期化パラメータ・ファイルにある LOG_ARCHIVE_DEST_n初期化パラメータの DELAY属性を使用します。

REDO データは通常どおりプライマリ・データベースからスタンバイ・データベースに自動転送され、アーカイブ REDO ログ・ファイル（実装されている場合は、スタンバイ REDO ログ・ファイルにも）に書き込まれますが、ログ・ファイルはすぐにはスタンバイ・データベースに適用されません。ログ・ファイルが適用されるのは、指定した時間が経過した後です。

この例では 4 時間のタイム・ラグが採用されています。この例に含まれる項目は、次のとおりです。

� フィジカル・スタンバイ・データベースでのタイム・ラグの設定

� タイム・ラグのあるフィジカル・スタンバイ・データベースへのフェイルオーバー

� タイム・ラグのあるフィジカル・スタンバイ・データベースへのスイッチオーバー

この例では、読者が通常のスタンバイ・データベースの作成手順を理解していることを前提にしています。したがって、この例で示す手順では詳細を省略しています。フィジカル・スタンバイ・データベースの作成の詳細は、第 3 章を参照してください。

注意注意注意注意 : リアルタイム適用が使用可能な宛先に遅延を定義した場合、その遅延は無視されます。



12.8.1 フィジカル・スタンバイ・データベースでのタイム・ラグの設定フィジカル・スタンバイ・データベースでのタイム・ラグの設定フィジカル・スタンバイ・データベースでのタイム・ラグの設定フィジカル・スタンバイ・データベースでのタイム・ラグの設定タイム・ラグのあるフィジカル・スタンバイ・データベースを作成するには、プライマリ・データベースの 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 情報は通常どおりスタンバイ・データベースに送信され、ディスクに書き込まれます。

フィジカルおよびロジカル・スタンバイ・データベースでのタイム・ラグの設定の詳細は、6.2.2 項を参照してください。

12.8.2 タイム・ラグのあるフィジカル・スタンバイ・データベースへのタイム・ラグのあるフィジカル・スタンバイ・データベースへのタイム・ラグのあるフィジカル・スタンバイ・データベースへのタイム・ラグのあるフィジカル・スタンバイ・データベースへのフェイルオーバーフェイルオーバーフェイルオーバーフェイルオーバー

アーカイブ 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. この新しいプライマリ・データベースのコピーから、構成内にある他のすべてのスタンバイ・データベースを再作成します。



12.8.3 タイム・ラグのあるフィジカル・スタンバイ・データベースへのタイム・ラグのあるフィジカル・スタンバイ・データベースへのタイム・ラグのあるフィジカル・スタンバイ・データベースへのタイム・ラグのあるフィジカル・スタンバイ・データベースへのスイッチオーバースイッチオーバースイッチオーバースイッチオーバー

スタンバイ・サイトが使用可能になると、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;

注意注意注意注意 : 論理的なエラーのリカバリには、スイッチオーバーではなく、フェイルオーバーを実行する必要があります。


ネットワーク障害のリカバリ

手順手順手順手順 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---------- --------- -------------------------------------------------------- 2 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 ログ・ファイルをアーカイブします。


ネットワークが再開され、フィジカル・スタンバイ・データベースで REDO Apply が再開されると、ログ適用サービスによるアーカイブ・ギャップの自動的な検出と解決が可能となります。


NOLOGGING 句を指定した後のリカバリ

12.10 NOLOGGING 句を指定した後のリカバリ句を指定した後のリカバリ句を指定した後のリカバリ句を指定した後のリカバリ一部の SQL 文には、NOLOGGING句を指定するオプションがあります。このオプションによって、データベースに関する操作をオンライン REDO ログ・ファイルに記録しないように指定できます。ユーザーがこの句を指定しても、REDO レコードはオンライン REDO ログ・ファイルに書き込まれます。ただし、このレコードに関連したデータはありません。これが結果的に、スタンバイ・サイトでのログ適用エラーやデータ・アクセス・エラーの原因となり、ログ・ファイルの適用の再開で、手動によるリカバリが必要となります。

12.10.1 ロジカル・スタンバイ・データベースのリカバリ手順ロジカル・スタンバイ・データベースのリカバリ手順ロジカル・スタンバイ・データベースのリカバリ手順ロジカル・スタンバイ・データベースのリカバリ手順ロジカル・スタンバイ・データベースの場合は、SQL Apply で NOLOGGING句を使用した操作の REDO ログ・レコードが検出されると、そのレコードはスキップされ、後続のレコードから変更の適用が続行されます。その後、NOLOGGINGを実際に使用して更新されたレコードの 1 つにアクセスしようとすると、「ORA-01403 データが見つかりません。」エラーが戻されます。

NOLOGGING句を指定した後のリカバリには、9.4.6 項に説明されているように、プライマリ・データベースから 1 つ以上の表を再作成します。

12.10.2 フィジカル・スタンバイ・データベースのリカバリ手順フィジカル・スタンバイ・データベースのリカバリ手順フィジカル・スタンバイ・データベースのリカバリ手順フィジカル・スタンバイ・データベースのリカバリ手順スタンバイ・サイトにコピーされたアーカイブ REDO ログ・ファイルがフィジカル・スタンバイ・データベースに適用されると、データファイルの一部が使用不可能となり、リカバリ不能のマークが付けられます。フィジカル・スタンバイ・データベースにフェイルオーバーするか、読取り専用アクセスでスタンバイ・データベースをオープンし、UNRECOVERABLEのマークが付けられたブロックの範囲を読み取ろうとすると、次のようなエラー・メッセージが表示されます。

ORA-01578: Oracleデータ・ブロックに障害が発生しました (ファイル番号 1、ブロック番号 2521)ORA-01110: データファイル 1: '/oracle/dbs/stdby/tbs_1.dbf'ORA-26040: データ・ブロックが NOLOGGINGオプションを使用してロードされました。

NOLOGGING句が指定された後でリカバリするには、欠落している REDO データが含まれているデータファイルをプライマリ・サイトからフィジカル・スタンバイ・サイトにコピーする必要があります。次の手順に従ってください。

注意注意注意注意 : この問題を回避するには、CREATE DATABASEまたは ALTER DATABASE文に FORCE LOGGING句を常に指定することをお薦めします。

『Oracle Database 管理者ガイド』を参照してください。

注意注意注意注意 : 通常、NOLOGGING句の使用はお薦めしません。また、プライマリ・データベース内の特定の表で NOLOGGING句を使用する操作が実行されることが事前にわかっている場合は、DBMS_LOGSTDBY.SKIPプロシージャを使用して、これらの表に関連付けられている SQL 文をロジカル・スタンバイ・データベースに適用しないようにできます。



手順手順手順手順 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 04 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 04 rows selected.

3. プライマリ・データベースの問合せ結果とスタンバイ・データベースの問合せ結果を比較します。

両方の問合せ結果の UNRECOVERABLE_CHANGE#列の値を比較します。プライマリ・データベースの UNRECOVERABLE_CHANGE#列の値の方が、スタンバイ・データベースの同じ列の値より大きい場合は、データファイルをプライマリ・サイトからスタンバイ・サイトへコピーする必要があります。

この例では、tbs_1.dbfデータファイルのプライマリ・データベースにあるUNRECOVERABLE_CHANGE#の値の方が大きいため、tbs_1.dbfデータファイルをスタンバイ・サイトへコピーする必要があります。

手順手順手順手順 2 プライマリ・サイトで、スタンバイ・サイトにコピーする必要があるデータファイルのプライマリ・サイトで、スタンバイ・サイトにコピーする必要があるデータファイルのプライマリ・サイトで、スタンバイ・サイトにコピーする必要があるデータファイルのプライマリ・サイトで、スタンバイ・サイトにコピーする必要があるデータファイルのバックアップを作成するバックアップを作成するバックアップを作成するバックアップを作成する


SQL> ALTER TABLESPACE system BEGIN BACKUP;SQL> EXIT;% cp tbs_1.dbf /backupSQL> ALTER TABLESPACE system END BACKUP;

手順手順手順手順 3 データファイルをスタンバイ・データベースにコピーするデータファイルをスタンバイ・データベースにコピーするデータファイルをスタンバイ・データベースにコピーするデータファイルをスタンバイ・データベースにコピーする

欠落している REDO データが含まれているデータファイルを、プライマリ・サイトからリカバリ関連のファイルが格納されているフィジカル・スタンバイ・サイトにコピーします。



手順手順手順手順 4 スタンバイ・データベースで、スタンバイ・データベースで、スタンバイ・データベースで、スタンバイ・データベースで、REDO Apply を再開するを再開するを再開するを再開する



REDO Apply を再開しようとすると、次のエラー・メッセージが（通常アラート・ログに）表示されることがあります。

ORA-00308: アーカイブ・ログ standby1をオープンできません。ORA-27037: ファイル・ステータスを取得できません。

SVR4 Error: 2: No such file or directoryAdditional information: 3ORA-01547: 警告 : RECOVERは成功しましたが OPEN RESETLOGSが次のエラーを受け取りました。ORA-01152: ファイル 1は十分に古いバックアップからリストアされていません。ORA-01110: データファイル 1: '/oracle/dbs/stdby/tbs_1.dbf'

ORA-00308エラーが表示され、REDO Apply が自動的に終了しない場合は、別の端末のウィンドウから次の文を発行して、リカバリを取り消すことができます。


これらのエラー・メッセージは、アーカイブ・ギャップ内にある 1 つ以上のログ・ファイルが正常に適用されなかった場合に戻されます。これらのエラーを受け取った場合は、ギャップを手動で解決し、手順 4 を繰り返します。アーカイブ・ギャップの手動による解決方法については、5.8.4 項を参照してください。

12.10.3 リカバリ不能処理後にバックアップが必要かどうかの判断リカバリ不能処理後にバックアップが必要かどうかの判断リカバリ不能処理後にバックアップが必要かどうかの判断リカバリ不能処理後にバックアップが必要かどうかの判断プライマリ・データベースでリカバリ不能な操作を実行した場合は、次の手順に従って新しいバックアップ操作が必要かどうかを判断します。

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 リファレンス』を参照してください。


手動によるアーカイブ・ギャップの解決

12.11 手動によるアーカイブ・ギャップの解決手動によるアーカイブ・ギャップの解決手動によるアーカイブ・ギャップの解決手動によるアーカイブ・ギャップの解決アーカイブ・ギャップアーカイブ・ギャップアーカイブ・ギャップアーカイブ・ギャップとは、アーカイブ REDO ログ・ファイルの特定の範囲を指します。この範囲は、プライマリ・データベースで生成される次のアーカイブ REDO ログ・ファイルをスタンバイ・データベースに適用できないときは常に発生します。この項は、次の項目で構成されています。

� アーカイブ・ギャップの発生原因

� アーカイブ・ギャップが存在するかどうかの判断

� スタンバイ・サイトへのアーカイブ・ギャップ・ログ・ファイルの手動による転送

� スタンバイ・データベースへのアーカイブ・ギャップ・ログ・ファイルの手動による適用

12.11.1 アーカイブ・ギャップの発生原因アーカイブ・ギャップの発生原因アーカイブ・ギャップの発生原因アーカイブ・ギャップの発生原因アーカイブ・ギャップは、プライマリ・データベースでカレント・オンライン REDO ログ・ファイルがローカルにアーカイブされても、REDO データがスタンバイ・サイトにアーカイブされなかった場合は常に発生する可能性があります。スタンバイ・データベースにはログ・ファイルを順序番号順に適用する必要があるため、メディア・リカバリは、初の欠落ログ・ファイルに遭遇すると停止します。

アーカイブ・ギャップは次の状況で発生することがあります。

� スタンバイ・データベースの作成

� プライマリ・データベースがオープンしている間のスタンバイ・データベースの停止

� REDO の転送を妨げるネットワーク障害

12.11.1.1 スタンバイ・データベースの作成スタンバイ・データベースの作成スタンバイ・データベースの作成スタンバイ・データベースの作成アーカイブ・ギャップは、スタンバイ・データベースを古いバックアップから作成すると発生します。たとえば、スタンバイ・データベースが、ログ・ファイル 100 の変更を含むバックアップから作成されているとします。このときプライマリ・データベースに、現在ログ・ファイル 150 の変更が含まれているとすると、スタンバイ・データベースは、ログ・ファイル 101からログ・ファイル 150 までの適用を要求します。オープン・データベースのホット・バックアップからスタンバイ・データベースを生成する場合も、通常アーカイブ・ギャップが発生します。

たとえば、図 12-8 の使用例を想定します。

注意注意注意注意 : 通常、アーカイブ・ギャップは手動操作を行うことなく自動的に解決されます。ログ適用サービスがアーカイブ REDO ログ・ファイル内にあるギャップを自動的にリカバリする方法の詳細は、5.8 項を参照してください。



図図図図 12-8 アーカイブ・ギャップ内にあるアーカイブアーカイブ・ギャップ内にあるアーカイブアーカイブ・ギャップ内にあるアーカイブアーカイブ・ギャップ内にあるアーカイブ REDO ログ・ファイルの手動リカバリログ・ファイルの手動リカバリログ・ファイルの手動リカバリログ・ファイルの手動リカバリ

次の手順を実行します。

1. プライマリ・データベースのホット・バックアップを取得します。

2. ネットワーク・ファイルを構築している時間 t で、プライマリはログ・ファイル順序の 4および 5 をアーカイブします。

3. 時間 t + 1 で、スタンバイ・インスタンスを起動します。

4. プライマリは、REDO ログ・ファイル順序 6、7 および 8 をプライマリ・サイトにアーカイブし、REDO をスタンバイ・サイトに転送します。

アーカイブ REDO ログ・ファイルの順序 4 および 5 はこれでアーカイブ・ギャップの一部となり、これらのログ・ファイルはスタンバイ・データベースに適用する必要があります。

12.11.1.2 プライマリ・データベースがオープンしている間のスタンバイ・プライマリ・データベースがオープンしている間のスタンバイ・プライマリ・データベースがオープンしている間のスタンバイ・プライマリ・データベースがオープンしている間のスタンバイ・データベースの停止データベースの停止データベースの停止データベースの停止メンテナンス問題を解決するため、スタンバイ・データベースの停止が必要になることがあります。たとえば、プライマリ・データベース内で MAXDATAFILEのような制御ファイル・パラメータを変更するときには、スタンバイ・データベースを停止する必要があります。

アーカイブ・ギャップの発生を避けるために、次のルールを実行します。

� プライマリ・データベースを起動する前にスタンバイ・データベースとリスナーを起動します。

� スタンバイ・データベースを停止する前にプライマリ・データベースを停止します。



これら 2 つのルールに違反すると、プライマリ・データベースがオープンし、アーカイブを実行しているときにスタンバイ・データベースが停止します。結果として、アーカイブ・ギャップが発生します。

12.11.1.3 REDO の転送を妨げるネットワーク障害の転送を妨げるネットワーク障害の転送を妨げるネットワーク障害の転送を妨げるネットワーク障害Data Guard 環境をメンテナンスしているときにネットワークが停止すると、プライマリ・データベースはディスクへの書込みを継続しますが、スタンバイ・サイトには REDO を送信できません。この状況では、アーカイブ REDO ログ・ファイルは通常どおり、プライマリ・サイトに蓄積されますが、スタンバイ・データベースはこれらのログ・ファイルを認識できません。

関連項目 :

� スタンバイ・アーカイブにおける OPTIONAL属性および MANDATORY属性の重要性の詳細は、5.7.2 項を参照してください。

� 関連する使用例については、12.9 項を参照してください。

12.11.2 アーカイブ・ギャップが存在するかどうかの判断アーカイブ・ギャップが存在するかどうかの判断アーカイブ・ギャップが存在するかどうかの判断アーカイブ・ギャップが存在するかどうかの判断アーカイブ・ギャップが存在するかどうかを判断するには、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------------- ------------- 7 10

次の問合せを使用して、ギャップが発生したスタンバイ・システムにコピーすることが必要な、ローカル・システム上のアーカイブ 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

注意注意注意注意 : スタンバイ・サイトが、プライマリ初期化パラメータ・ファイルの LOG_ARCHIVE_DEST_nパラメータの 1 つにおいて MANDATORYと指定されている場合は、スタンバイ・データベースを停止する前に、それを動的に OPTIONALに変更します。これを行わないと、プライマリ・データベースはオンライン REDO ログ・ファイルをアーカイブできないため停止します。



12.11.3 スタンバイ・サイトへのアーカイブ・ギャップ・ログ・ファイルのスタンバイ・サイトへのアーカイブ・ギャップ・ログ・ファイルのスタンバイ・サイトへのアーカイブ・ギャップ・ログ・ファイルのスタンバイ・サイトへのアーカイブ・ギャップ・ログ・ファイルの手動による転送手動による転送手動による転送手動による転送

アーカイブ・ギャップ内にあるログ・ファイル順序番号の取得後、プライマリ・サイトのV$ARCHIVED_LOGビューを問い合せて、ファイル名を取得できます。スタンバイ・サイトのアーカイブ REDO ログ・パス名は、スタンバイ初期化パラメータ・ファイルのSTANDBY_ARCHIVE_DESTパラメータおよび LOG_ARCHIVE_FORMATパラメータによって生成されます。

スタンバイ・データベースがプライマリ・データベースと同じサイトにある場合、またはスタンバイ・データベースがプライマリ・データベースと異なるディレクトリ構造を持つリモート・サイトにある場合、スタンバイ・サイトのログ・ファイルのパス名は、プライマリ・データベースでアーカイブされたログ・ファイルのパス名と同じにはなりません。REDO データをスタンバイ・サイトに転送する前に、スタンバイ・サイトでアーカイブ REDO ログ・ファイルの正しいパス名を判別してください。

スタンバイ・サイトにアーカイブ・ギャップ内にあるログ・ファイルをコピースタンバイ・サイトにアーカイブ・ギャップ内にあるログ・ファイルをコピースタンバイ・サイトにアーカイブ・ギャップ内にあるログ・ファイルをコピースタンバイ・サイトにアーカイブ・ギャップ内にあるログ・ファイルをコピーする方法する方法する方法する方法1. 以前取得したアーカイブ・ギャップ・ログ・ファイルのリストを見直します。たとえば、

次のアーカイブ・ギャップがあると想定します。

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#---------- ------------- -------------- 1 460 463 2 202 204 3 100 100

このビューに表示されているスレッドには、アーカイブ・ギャップが存在します。したがって、スレッド 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.arc4 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 ログ・ファイルのファイル名を判別できます。



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ディレクトリにあるため、12.11.4 項に進んで、アーカイブ・ギャップ・ログ・ファイルをスタンバイ・データベースに適用できます。8.5.4.4 項および第 16 章の V$ARCHIVED_LOGビューも参照してください。

12.11.4 スタンバイ・データベースへのアーカイブ・ギャップ・ログ・ファイルスタンバイ・データベースへのアーカイブ・ギャップ・ログ・ファイルスタンバイ・データベースへのアーカイブ・ギャップ・ログ・ファイルスタンバイ・データベースへのアーカイブ・ギャップ・ログ・ファイルの手動による適用の手動による適用の手動による適用の手動による適用

アーカイブ・ギャップ内のログ・ファイルをスタンバイ・サイトにコピーした後、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 directoryAdditional information: 3Specify log: {<RET>=suggested | filename | AUTO | CANCEL}


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. 欠落しているログ・ファイルを手動で適用した後、次のようにしてスタンバイ・データベースでログ適用サービスを再開できます。


12.12 OMF またはまたはまたはまたは ASM を使用するスタンバイ・データベースのを使用するスタンバイ・データベースのを使用するスタンバイ・データベースのを使用するスタンバイ・データベースの作成作成作成作成

第 3 章および第 4 章では、フィジカルおよびロジカル・スタンバイ・データベースの作成方法を説明しました。この項では、プライマリ・データベースで Oracle Managed Files（OMF）または自動ストレージ管理（ASM）を使用する場合に実行する必要のある追加手順を説明し、これらの章を補完します。

スタンバイ・データベースを作成する前に、次の準備作業を実行します。

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 を構成します。

注意注意注意注意 : この項の説明は、読者がすでにフィジカル・スタンバイ・データベースの作成方法を理解しており、Recovery Manager、OMF およびASM 機能に習熟していることを前提としています。詳細は、次の資料を参照してください。

� フィジカルおよびロジカル・スタンバイ・データベースの作成方法は、第 3 章、第 4 章および付録 F を参照してください。

� OMF および ASM の詳細は、『Oracle Database 管理者ガイド』参照してください。

� Recovery Manager の詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』および『Oracle Database Recovery Manager リファレンス』を参照してください。


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コマンドを使用してバックアップ・ピースをリストア前にカタログに追加します。

これらの手順を完了した後、3.2.7 項の手順を実行してフィジカル・スタンバイ・データベースの構成を確認します。

ロジカル・スタンバイ・データベースを作成するには、第 4 章で説明されているスタンバイ・データベースの作成プロセスを実行しますが、次の点を変更します。

1. ロジカル・スタンバイ・データベースの場合、DB_CREATE_FILE_DESTパラメータを設定しても、OMF ファイル名を強制的に作成しません。ただし、このパラメータをプライマリ・データベースで設定する場合、スタンバイ・データベースでも設定する必要があります。

2. プライマリ・システムでロジカル・スタンバイ制御ファイルを作成した後、このファイルをスタンバイ・システムにコピーするために、オペレーティング・システムのコマンドを使用しないでください。かわりに Recovery Manager の RESTORE CONTROLFILEコマンドを使用して、ロジカル・スタンバイ制御ファイルのコピーをスタンバイ・システムにリストアします。

3. プライマリ・データベースで OMF ファイルを使用する場合、スタンバイ・データベースに作成された新しい OMF ファイルをスタンバイ・データベース制御ファイルが使用するよう、Recovery Manager を使用してスタンバイ・データベース制御ファイルを更新します。この操作を実行するには、次の例に示すように、スタンバイ・データベースにのみ接続します。

> RMAN TARGET sys/oracle@lstdbyRMAN> CATALOG START WITH '+stby_diskgroup';RMAN> SWITCH DATABASE TO COPY;

これらの手順を完了した後、4.2.5 項の手順を実行してロジカル・スタンバイ・データベースの起動、リカバリおよび検証を行います。


第第第第 II 部部部部
参照先参照先参照先参照先
この部では、Oracle Data Guard のスタンバイ・データベースの特長について参考となる資料を提供します。詳細は、Oracle Database 10g のマニュアルを参照してください。

この部は、次の章で構成されています。

� 第 13 章「初期化パラメータ」

� 第 14 章「LOG_ARCHIVE_DEST_n パラメータの属性」

� 第 15 章「Data Guard に関連する SQL 文」

� 第 16 章「Oracle Data Guard に関連するビュー」

初期化パラ

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

メータ 13-1

表 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 可ロジカルおよびフィジカル

Data Guard では 9.2.0.1.0 以上の値を必要としま

す。Oracle Database 10g の新機能を使用するに

は、10.2.0.0 以上に設定してください。スイッチ

オーバーを実行すると思われる場合は、同じ値をプライマリ・データベースおよびスタンバイ・データベースに指定します。値が異なる場合は、

REDO 転送サービスが REDO データをプライマ

リ・データベースからスタンバイ・データベースに転送できない可能性があります。例について

は、3.2.3 項を参照してください。

SQL Apply を使用したローリング・アップグ

レードの場合は、このパラメータを 11.4 項

「アップグレードの準備」で説明したガイドラインに従って設定します。

CONTROL_FILE_RECORD_KEEP_TIME = number_of_days

可ロジカルおよびフィジカル

オプション。このパラメータを使用して、指定された日数（0 ～ 365）内に、制御ファイル内

（アーカイブ REDO ログ・ファイルなどの必要

な情報が含まれている）の再使用可能レコードが上書きされないようにします。 5.7.4 項を参照


CONTROL_FILES = 'control_file_name' , control_file_name', '...')


必須。1 つ以上の制御ファイルのパス名とファイ

ル名を指定します。制御ファイルはすでにデータベースに存在している必要があります。2 つの

制御ファイルを使用することをお薦めします。現行の制御ファイルの別のコピーが存在していれば、問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後、容易にインスタンスを再開できます。 3.2.3 項の例を参照し

てください。

DB_FILE_NAME_CONVERT = (location_of_primary_database_datafile' , 'location_of_standby_database_datafile_name' , '...'

不可フィジカルのみスタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはデータファイルが格納されているスタンバイ・システムのディレクトリがプライマリ・システムと異なる場合は必須。このパラメータには、文字列をペアで指定する必要があります。初の文字列は、プライマリ・データベース・ファイル名の中で検索される文字列です。その文字列が一致すると、スタンバイ・データベース・ファイル名を構成する 2 番目の文字列に置き換

えられます。複数のペアのファイル名を指定できます。例 3-3 も参照してください。


DB_UNIQUE_NAME = unique_service_provider_name_for_this_database


推奨。ただし、LOG_ARCHIVE_CONFIGパラ

メータを指定している場合は必須。このデータ

ベースの一意の名前を指定します。プライマリ・データベースとスタンバイ・データベースのロールが交代しても、この名前は変更されません。DB_UNIQUE_NAMEパラメータのデフォルト

は、DB_NAMEパラメータの値です。 LOG_ARCHIVE_CONFIGパラメータおよび 5.4.2 項も

参照してください。

FAL_CLIENT = Oracle_Net_service_name

可フィジカルのみ FAL_SERVERパラメータが指定されている場合

は必須。FAL サーバー（通常はプライマリ・

データベース）が FAL クライアント（スタンバ

イ・データベース）への接続に使用する Oracle Net サービス名を指定します。 5.8.3 項を参照し

てください。

FAL_SERVER = Oracle_Net_service_name

不可フィジカルのみ FAL_CLIENTパラメータが指定されている場合

は必須。欠落しているアーカイブ REDO ログ・

ファイルをこのスタンバイ・データベースがフェッチ（要求）できるフェッチ元データベースの Oracle Net サービス名を 1 つ以上指定しま

す。 5.8.3 項を参照してください。

INSTANCE_NAME 可ロジカルおよびフィジカル

オプション。このパラメータが定義されており、プライマリ・データベースとスタンバイ・データベースが同じホストに存在する場合は、スタンバイ・データベースに対してプライマリ・データベースとは異なる名前を指定します。 3.2.3項の例を参照してください。

LOG_ARCHIVE_CONFIG='DG_CONFIG=(db_unique_name, db_unique_name, ...)'


推奨。 Data Guard 構成内のプライマリ・データ

ベースおよび各スタンバイ・データベースのDB_UNIQUE_NAMEを識別する場合、DG_CONFIG属性を指定します。このパラメータのデ

フォルト値は、プライマリ・データベースがREDO データをリモート宛先に送信し、スタン

バイ・データベースが REDO データを受信する

ことを可能にします。Data Guard 構成内で Real Application Clusters プライマリ・データベース

が大保護モードまたは大可用性モードで稼働している場合、この Data Guard 構成へのスタ

ンバイ・データベースの動的追加を使用可能するには、DG_CONFIG属性を設定する必要があり

ます。 5.4.2 項を参照してください。

LOG_ARCHIVE_DEST_n ={LOCATION=path_name| SERVICE=service_name, attribute, attribute, ... }


必須。大 10（n = 1, 2, 3, ... 10）の宛先を定義し

ます。いずれも LOCATIONまたは SERVICE属

性を指定する必要があります。各 LOG_ARCHIVE_DEST_nパラメータに対し、それぞれ

対応する LOG_ARCHIVE_DEST_STATE_nパラ

メータを指定します。詳細は、5.2.2 項および第

14 章を参照してください。

LOG_ARCHIVE_DEST_STATE_n = {ENABLE|DISABLE|ALTERNATE}


必須。 LOG_ARCHIVE_DEST_STATE_nパラメー

タを指定して、指定された（または代替の）宛先への REDO 転送サービスによる REDO データ

の転送を可能または不可に設定します。各 LOG_ARCHIVE_DEST_nパラメータに対し、LOG_ARCHIVE_DEST_STATE_nパラメータを指定し

ます。5.2.2 項および第 14 章も参照してくださ

い。

表表表表 13-1 Data Guard 構成内のインスタンスの初期化パラメータ（続き）構成内のインスタンスの初期化パラメータ（続き）構成内のインスタンスの初期化パラメータ（続き）構成内のインスタンスの初期化パラメータ（続き）



初期化パラメータ 13-3

LOG_ARCHIVE_FORMAT=log%d_%t_%s_%r.arc


STANDBY_ARCHIVE_DESTパラメータを指定し

ている場合は必須。これらのパラメータは連結され、スタンバイ・データベースに完全修飾されたアーカイブ REDO ログ・ファイル名を生成

します。 5.7.1 項も参照してください。

LOG_ARCHIVE_LOCAL_FIRST =[TRUE|FALSE]

可不可オプション。オンライン REDO ログ・ファイル

が 1 つ以上のローカル宛先に正常にアーカイブ

された後（TRUE）、またはオンライン REDO ロ

グ・ファイルがローカル宛先にアーカイブされるのと同時（FALSE）の、いずれの時点でアー

カイバ・プロセス（ARCn）が転送を実行するか

を制御する場合に指定します。

5.3.1 項も参照してください。

LOG_ARCHIVE_MAX_PROCESSES =integer


オプション。 Oracle ソフトウェアが初に起動

するアーカイバ（ARCn）プロセスの数（1 ～

30）を指定します。デフォルト値は 4 です。

ARCn プロセスの詳細は、5.3.1.2 項を参照してく

ださい。

LOG_ARCHIVE_MIN_SUCCEED_DEST=integer

可不可オプション。プライマリ・データベースのログ・ライター・プロセスがオンライン REDO ログ・

ファイルを再利用する前に REDO データを正常

に受信する必要がある、宛先の小数（1 ～ 10）を定義します。

LOG_ARCHIVE_TRACE=integer 可ロジカルおよびフィジカル

オプション。スタンバイ・サイトへの REDOデータの転送をトレースするには、このパラメータを設定します。有効な整数値（0、1、2、4、8、16、32、64、128、256、512、1024、2048または 4096）については、付録 G で説明されて

います。

LOG_FILE_NAME_CONVERT='location_of_primary_database_redo_logs', 'location_of_standby_database_redo_logs'

不可ロジカルおよびフィジカル

スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはログ・ファイルが存在するスタンバイ・サイトのディレクトリ構造がプライマリ・サイトと異なる場合は必須。このパラメータは、プライマリ・データベースのオンライン REDO ログ・ファイ

ルのパス名をスタンバイ・データベースのパス名に変換します。 3.2.3 項の例を参照してくださ

い。

PARALLEL_MAX_SERVERS=integer 可ロジカルのみ必須。ロジカル・スタンバイ・データベースで動作するパラレル・サーバーの大数を指定します。ロジカル・スタンバイ・データベースでは、このパラメータの値は、5 未満に設定しない

でください。高の結果を得るためには、

PARALLEL_MAX_SERVERSを 9 以上に設定して

ください。

REMOTE_LOGIN_PASSWORDFILE= {EXCLUSIVE|SHARED}


必須。プライマリ・データベースおよびすべての

スタンバイ・データベースで指定します。

SHARED_POOL_SIZE = bytes 可ロジカルおよびフィジカル

オプション。オンライン REDO ログ・ファイル

から読み込んだ情報を処理する System Global Area（SGA）の指定に使用します。使用可能な

SGA が大きいと、処理できる情報量も大きくな

ります。





SORT_AREA_SIZE = bytes 可ロジカルおよびフィジカル

オプション。大量のソートの効率を上げるには、SORT_AREA_SIZEのサイズ（デフォルト・サイ

ズは 65536 バイト）を増加します。 8.2 項も参照


STANDBY_ARCHIVE_DEST= filespec 不可ロジカルおよびフィジカル

オプション。プライマリ・データベースから受信

する、スタンバイ・データベース上のアーカイブ REDO ログ・ファイルの位置を指定します。

STANDBY_ARCHIVE_DEST初期化パラメータは、

LOG_ARCHIVE_DEST_nパラメータで指定され

たディレクトリの場所よりも優先されます。STANDBY_ARCHIVE_DESTと LOG_ARCHIVE_FORMATが連結して、完全修飾されたログ・

ファイル名が生成されます。 5.7.1 項を参照して

ください。

STANDBY_FILE_MANAGEMENT = {AUTO|MANUAL}

可フィジカルのみデータファイルがプライマリ・データベースに追加または削除された場合に、手動で変更しなくてもスタンバイ・データベースに対応する変更が加えられるよう、STANDBY_FILE_MANAGEMENTパラメータを AUTOに設定します。

プライマリ・データベースとスタンバイ・データベースのディレクトリ構造が異なる場合は、DB_FILE_NAME_CONVERT初期化パラメータも

設定して、プライマリ・データベースのデータファイルの 1 つ以上のセットのファイル名をス

タンバイ・データベースのファイル名に変換する必要があります。詳細および例は、例 3-3 を参

照してください。

USER_DUMP_DEST = directory_path_name_of_trace_file


LOG_ARCHIVE_TRACEパラメータを指定してい

る場合は必須。USER_DUMP_DESTにより、サー

バーによるデバッグ・トレース・ファイルの書込み先ディレクトリのパス名を指定します。付録

G を参照してください。




初期化パラメータ 13-5


LOG_ARCHIVE_DEST_n パラメー

14
LOG_ARCHIVE_DEST_n パラメータの属性パラメータの属性パラメータの属性パラメータの属性
この章では、LOG_ARCHIVE_DEST_n初期化パラメータの属性のリファレンス情報を提供します。属性には次のものがあります。

AFFIRM および NOAFFIRMALTERNATEARCH および LGWRDB_UNIQUE_NAMEDELAYDEPENDENCYLOCATION および SERVICEMANDATORY および OPTIONALMAX_CONNECTIONSMAX_FAILURENET_TIMEOUTNOREGISTERREOPENSYNC および ASYNCTEMPLATEVALID_FORVERIFY

各 LOG_ARCHIVE_DEST_n宛先には、ローカル・ディスクのディレクトリまたはリモートからアクセスするデータベースを指定する、LOCATIONまたは SERVICE属性が含まれている必要があります。他の属性はすべてオプションです。

注意注意注意注意 : LOG_ARCHIVE_DEST_n初期化パラメータの複数の属性が廃止になりました。これらの属性は下位互換性のためにのみサポートされています。詳細は、『Oracle Database リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : LOG_ARCHIVE_DEST_n宛先を定義して REDO 転送サービスを設定する方法の詳細は、第 5 章を参照してください。

タの属性 14-1

AFFIRM および NOAFFIRM

AFFIRM およびおよびおよびおよび NOAFFIRM

REDO 転送サービスでディスクへの REDO データの書込みに同期 I/O を使用するか非同期 I/Oを使用するかを制御します。

� AFFIRM: アーカイブ REDO ログ・ファイルおよびスタンバイ REDO ログ・ファイルに対するディスク I/O をすべて同期して実行し、ログ・ライター・プロセスの続行前に正常に完了するように指定します。

� NOAFFIRM: アーカイブ REDO ログ・ファイルおよびスタンバイ REDO ログ・ファイルに対するディスク I/O がすべて非同期で実行され、プライマリ・データベースのログ・ライター・プロセスはディスク I/O が完了するまで待機せずに続行されるように指定します。

使用方法使用方法使用方法使用方法� この 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属性を指定しても、パフォーマンスには影響しません。

カテゴリカテゴリカテゴリカテゴリ AFFIRM NOAFFIRM

データ型キーワードキーワード

有効な値該当なし該当なし

デフォルト値該当なし該当なし

必須属性該当なし該当なし

属性との競合 NOAFFIRM AFFIRM

対応先 V$ARCHIVE_DESTビューの

AFFIRMおよび ASYNC_BLOCKS列

V$ARCHIVE_DESTビューの

AFFIRMおよび ASYNC_BLOCKS列

注意注意注意注意 : プライマリ・データベースが大保護モードまたは大可用性モードである場合、LGWRおよび SYNC属性で定義された宛先は、自動的に AFFIRMモードになります。


AFFIRM および NOAFFIRM

� NOAFFIRM属性は、アーカイブ REDO ログ・ファイルおよびスタンバイ REDO ログ・ファイルに対するディスク I/O がすべて非同期で実行され、プライマリ・データベースのログ・ライター・プロセスはディスク I/O が完了するまで待機せずに続行されるように指定します。

� AFFIRMおよび NOAFFIRM属性の適用先は、リモート・スタンバイ宛先のアーカイブREDO ログ・ファイルおよびスタンバイ REDO ログ・ファイルのみであるため、プライマリ・データベースのオンライン REDO ログ・ファイルに対するディスク I/O には影響を与えません。

� これらの属性は、ローカル宛先の場合は LOCATION属性に、リモート宛先の場合はSERVICE属性に指定できます。

例例例例次の例は、リモート宛先の AFFIRM属性を示しています。

LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR SYNC AFFIRM'LOG_ARCHIVE_DEST_STATE_3=ENABLE

関連項目関連項目関連項目関連項目 : 14-23 ページの「SYNC および ASYNC」属性

LOG_ARCHIVE_DEST_n パラメータの属性 14-3

ALTERNATE

ALTERNATE

元のアーカイブ先で障害が発生したときに使用する代替アーカイブ先を指定します。

使用方法使用方法使用方法使用方法� ALTERNATE属性はオプションです。代替アーカイブ先が指定されていない場合、元のアー

カイブ先に障害が発生しても、REDO 転送サービスでは自動的に別のアーカイブ先に変更されません。

� 指定できる代替アーカイブ先は LOG_ARCHIVE_DEST_nパラメータごとに 1 つのみですが、複数の有効なアーカイブ先で同じ代替アーカイブ先を共有できます。

� 代替アーカイブ先に次のいずれかを指定することが理想的です。

– 同じローカル・スタンバイ・データベース・システム上の異なるディスクの場所（14-5 ページの例 14-1 を参照）

– 同じスタンバイ・データベース・システムへの異なるネットワーク・ルート（14-5ページの例 14-2 を参照）

– 有効なアーカイブ先を厳密に反映するリモート・スタンバイ・データベース・システム

� 代替アーカイブ先を参照する有効な宛先がない場合は、代替アーカイブ先が保留されていることを意味します。これは、代替アーカイブ先を有効にする自動手段がないためです。ただし、ALTER SYSTEMを使用すると、代替アーカイブ先を実行時に有効にする（または遅延させる）ことができます。

� 代替アーカイブ先に指定できる宛先には、次の制限事項があります。

– ローカルの必須の宛先を少なくとも 1 つは有効にする。

– 有効な宛先数は、LOG_ARCHIVE_MIN_SUCCEED_DESTパラメータでの定義と一致させる必要がある。

– 宛先をそれ自身の代替先にすることはできない。

� 有効な宛先数を増加させると、利用可能な代替アーカイブ先の数が減少します。

� 宛先に障害が発生すると、次のアーカイブ操作時に代替アーカイブ先が有効になります。アーカイブ操作の途中で、代替アーカイブ先を有効にすることはできません。これは、すでに処理済のブロックなどを、再度読み込む必要が生じるためです。これは、REOPEN属性の機能と同じです。

カテゴリカテゴリカテゴリカテゴリ ALTERNATE=LOG_ARCHIVE_DEST_n

データ型文字列

有効な値 LOG_ARCHIVE_DEST_n宛先先

デフォルト値なし。代替アーカイブ先が指定されていない場合、REDO 転送

サービスでは自動的に別のアーカイブ先に変更されません。

必須属性該当なし

属性との競合なし1

1 REOPEN属性が 0（ゼロ）ではない値で指定されている場合、ALTERNATE属性は無視されます。MAX_FAILURE属性に 0（ゼロ）ではない値が指定され、障害件数が指定した障害しきい値を超過する場合は、ALTERNATE宛先が有効になります。このため、ALTERNATE属性は 0（ゼロ）ではない REOPEN属性値と競合しません。

対応先 V$ARCHIVE_DESTビューの ALTERNATEおよび STATUS列


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=ENABLELOG_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パラメータの詳細は、5.2.2 項を参照してください。

例例例例 14-2 スタンバイ・データベースに対する代替のスタンバイ・データベースに対する代替のスタンバイ・データベースに対する代替のスタンバイ・データベースに対する代替の Oracle Net サービス名の定義サービス名の定義サービス名の定義サービス名の定義

この例は、同じスタンバイ・データベースに代替 Oracle Net サービス名を定義する方法を示しています。

LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_2='SERVICE=stby1_path1 OPTIONAL ALTERNATE=LOG_ARCHIVE_DEST_3'LOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_DEST_3='SERVICE=stby1_path2 OPTIONAL'LOG_ARCHIVE_DEST_STATE_3=ALTERNATE


ARCH および LGWR

ARCH およびおよびおよびおよび LGWR

REDO 転送サービスによるトランザクション REDO データの収集とスタンバイ宛先への転送に、アーカイバ・プロセス（ARCn）を使用するか、ログ・ライター・プロセス（LGWR）を使用するかを指定します。 ARCH属性および LGWR属性が指定されていない場合、デフォルトはARCHです。

使用方法使用方法使用方法使用方法� この 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

カテゴリカテゴリカテゴリカテゴリ ARCH LGWR




必須属性なしなし

属性との競合 LGWR、ASYNC、NET_TIMEOUT ARCH


ARCHIVER、PROCESSおよび

SCHEDULE列


ARCHIVER、PROCESSおよび

SCHEDULE列


DB_UNIQUE_NAME

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=bostonLOG_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'

カテゴリカテゴリカテゴリカテゴリ DB_UNIQUE_NAME=name

データ型文字列

有効な値 name は、DB_UNIQUE_NAMEパラメータを使用してこのデータ

ベースに定義された値と一致している必要があります。

デフォルト値なし

必須属性なし

属性との競合なし

対応先 V$ARCHIVE_DESTビューの DB_UNIQUE_NAME列


DELAY

DELAY

フィジカル・スタンバイ・サイトで REDO データがアーカイブされてから、フィジカル・スタンバイ・データベースにアーカイブ REDO ログ・ファイルが適用されるまでのタイム・ラグを指定します。

使用方法使用方法使用方法使用方法� DELAY属性はオプションです。デフォルトでは、遅延は発生しません。

� DELAY属性は、スタンバイ宛先のアーカイブ REDO ログ・ファイルが、指定した時間が経過するまでリカバリに利用されないことを示します。時間間隔は分で表され、転送されたREDO データがスタンバイ・サイトに正常に到達した時点から計測されます。

� DELAY属性を使用すると、破損したプライマリ・データまたは誤ったプライマリ・データからフィジカル・スタンバイ・データベースを保護できます。ただし、フェイルオーバー中は、破損が発生した時点までのすべての REDO を適用するための所要時間が長くなるため、トレードオフを伴います。

� DELAY属性は、REDO データのフィジカル・スタンバイ宛先への転送に影響しません。

� リアルタイム適用が使用可能になっている場合、設定した遅延は無視されます。

� DELAY属性の変更は、次に REDO データをアーカイブすると（ログ・スイッチ後に）有効になります。進行中のアーカイブ操作には、影響しません。

� スタンバイ・サイトでの指定した遅延間隔は上書きできます。時間間隔が経過する前に、アーカイブ REDO ログ・ファイルをフィジカル・スタンバイ・データベースに即時に適用するには、RECOVER MANAGED STANDBY DATABASE句の NODELAYキーワードを使用します。次に例を示します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

注意注意注意注意 : この属性は、フィジカル・スタンバイ・データベースにのみ設定できます。ロジカル・スタンバイ・データベースでアーカイブ REDO ログ・ファイルの適用を遅延するには、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』で説明されているように、DBMS_LOGSTDBY.APPLY_SETプロシージャを使用します。

カテゴリカテゴリカテゴリカテゴリ DELAY[=minutes]

データ型数値

有効な値 0 分以上

デフォルト値 30 分

必須属性 SERVICE

属性との競合 LOCATION、NODELAY

対応先 V$ARCHIVE_DESTビューの DELAY_MINSおよび

DESTINATION列

関連項目関連項目関連項目関連項目 : ALTER DATABASE RECOVER MANAGED STANDBY DATABASE文の NODELAYキーワードの詳細は、『Oracle Database SQL リファレンス』を参照してください。


DELAY

例例例例DELAY属性を使用すれば、プライマリ・データベースと様々なレベルで同期させる複数のスタンバイ・データベースを維持する構成を設定できます。ただし、REDO Apply で破損時点までのすべての REDO を適用するまでにかかる時間が長くなるため、フェイルオーバー中は、この保護はなんらかのオーバーヘッドを伴います。

たとえば、プライマリ・データベース A にはスタンバイ・データベース B および C がある場合を考えます。スタンバイ・データベース B は、障害時リカバリ・データベースとして設定するため、タイム・ラグは設定しません。スタンバイ・データベース C は 2 時間の遅延に設定されています。これは、スタンバイ・データベースに伝播する前にユーザー・エラーを検出するには十分な時間です。

次の例は、この構成用に DELAY属性を指定する方法を示しています。

LOG_ARCHIVE_DEST_1='LOCATION=/oracle/dbs/'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_2='SERVICE=stbyB LGWR SYNC AFFIRM'LOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_DEST_3='SERVICE=stbyC DELAY=120'LOG_ARCHIVE_DEST_STATE_3=ENABLE

注意注意注意注意 : または、十分なフラッシュバック・ログ・データがあれば、フラッシュバック・データベースを使用して、データベースを障害発生時点または他のデータベース・インカネーションの SCN まで戻すこともできます。フラッシュバック・データベースの使用方法は、『Oracle Database バックアップおよびリカバリ基礎』を参照してください。


DEPENDENCY

DEPENDENCY

この属性は、他の宛先にあるアーカイブ場所への共有アクセスを介して REDO データを受信するスタンバイ宛先について指定します。この属性を使用して定義された宛先には、DEPENDENCY属性で指定した他の宛先への依存性があります。

使用方法使用方法使用方法使用方法� DEPENDENCY属性はオプションです。 DEPENDENCY属性を指定しない場合、REDO 転送

サービスでは REDO データは宛先に直接転送されます。

� DEPENDENCY属性は、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースで指定できます。

� 依存する宛先で REDO データを使用できるかどうかは、DEPENDENCY属性で指定された宛先への REDO 転送が成功するか失敗するかによって決定します。

� DEPENDENCY属性には、次の制限事項があります。

– 依存性を持つことができるのはスタンバイ宛先のみである。

– DEPENDENCY属性で指定する宛先には、LOCATIONまたは SERVICE属性を使用できる。

– DEPENDENCY属性は、セッション・レベルでは変更できない。

� 1 つ以上の宛先が同じ宛先に依存する場合、依存する宛先のすべての属性も適用されます。実際にはアーカイブ操作が 1 回のみ発生した場合でも、アーカイブ操作が各宛先に対して実行されたように見えます。

たとえば、2 つのスタンバイ・データベースが同じ宛先に依存する場合を考えます。各宛先には異なる DELAY属性を指定できるため、プライマリ・データベースと各スタンバイ・データベース間で、タイム・ラグをずらして維持できます。

同じように、依存する宛先には ALTERNATEアーカイブ先を指定できますが、同じ親宛先に依存するようにもしないようにも指定できます。

� 依存する宛先には、データ消失なしのフェイルオーバーは実行できません。

カテゴリカテゴリカテゴリカテゴリ DEPENDENCY=LOG_ARCHIVE_DEST_n

データ型文字列値

有効な値該当なし



属性との競合 LOCATION、NOREGISTER

対応先 V$ARCHIVE_DESTビューの DEPENDENCY列

関連項目関連項目関連項目関連項目 : 5.7.5 項「複数のスタンバイ・データベース間でのログ・ファイル宛先の共有」


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


LOCATION および SERVICE

LOCATION およびおよびおよびおよび SERVICE

各宛先には LOCATION属性または SERVICE属性を指定して、REDO 転送サービスがローカル・ディスクのディレクトリまたはリモート・データベースのどちらに REDO データを転送できるかを明示する必要があります。

使用方法使用方法使用方法使用方法� 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の宛先がフラッシュ・リカバリ領域に使用されます。フラッシュ・リカバリ領域の詳細は、5.2.3 項を参照してください。

カテゴリカテゴリカテゴリカテゴリ

LOCATION=local_disk_directoryまたはまたはまたはまたは USE_DB_RECOVERY_FILE_DEST SERVICE=net_service_name

データ型文字列値文字列値


デフォルト値なしなし


属性との競合 SERVICE、DELAY、DEPENDENCY、NOREGISTER、ASYNC、TEMPLATE、NET_TIMEOUT

LOCATION


DESTINATIONおよび TARGET列


DESTINATIONおよび TARGET列


LOCATION および SERVICE

� SERVICE属性を指定する場合は、次のようにします。

– SERVICE属性と、REDO データの送信先となるリモート Oracle データベース・インスタンスを識別する有効な Oracle Net サービス名（SERVICE=net_service_name）を指定して、リモート宛先を識別します。

SERVICE属性で指定する Oracle Net サービス名は、リモート・データベースへの接続に必要な情報を含む接続記述子に変換されます。

– リモート宛先に 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

関連項目関連項目関連項目関連項目 : Oracle Net サービス名の設定方法は、『Oracle Database Net Services 管理者ガイド』を参照してください。


MANDATORY および OPTIONAL

MANDATORY およびおよびおよびおよび OPTIONAL

オンライン REDO ログ・ファイルを再利用するためのポリシーを指定します。

� MANDATORY: いっぱいになったオンライン・ログ・ファイルが再利用可能になる前に、宛先へのアーカイブの成功が必要になるように指定します。

� OPTIONAL: 宛先へのアーカイブに成功していなくても、オンライン REDO ログ・ファイルが再利用可能になるように指定します。

使用方法使用方法使用方法使用方法� 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列は、アーカイブ操作に障害がどのように影響するのかを指定します。

カテゴリカテゴリカテゴリカテゴリ MANDATORY OPTIONAL





属性との競合 OPTIONAL MANDATORY


BINDING列


BINDING列


MANDATORY および OPTIONAL

例例例例次の例は、MANDATORY属性を示しています。

LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest MANDATORY'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_3='SERVICE=denver MANDATORY'LOG_ARCHIVE_DEST_STATE_3=ENABLE


MAX_CONNECTIONS

MAX_CONNECTIONS

宛先に対するリモート・アーカイブの実行に使用されるネットワーク接続の大数を指定します。 MAX_CONNECTIONS属性を 2 以上の値に設定すると、REDO 転送サービスでは複数のネットワーク接続を使用してリモート・アーカイブが実行されます。これらの各接続には個別のアーカイバ（ARCn）プロセスが使用されます。

使用方法使用方法使用方法使用方法� 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=ENABLELOG_ARCHIVE_DEST_3='SERVICE=denver MAX_CONNECTIONS=3'LOG_ARCHIVE_DEST_STATE_3=ENABLE

カテゴリカテゴリカテゴリカテゴリ説明説明説明説明

データ型整数

有効な値 1 ～ 5

デフォルト値 1

必須属性なし


対応先 � プライマリ・データベースの V$ARCHIVE_DESTビューの

MAX_CONNECTIONS列

� LOG_ARCHIVE_MAX_PROCESSESおよび PARALLEL_MAX_SERVERS初期化パラメータ


MAX_FAILURE

MAX_FAILURE

プライマリ・データベースが失敗した宛先を放棄する前に、REDO 転送サービスが通信を再確立してその宛先への REDO データを転送する連続試行回数を制御します。

使用方法使用方法使用方法使用方法� MAX_FAILURE属性はオプションです。デフォルトでは、失敗した宛先に対するアーカイブ

の試行回数に制限はありません。

� この属性は、失敗後に回数制限付きで REDO データの転送を再試行するように、宛先に対する障害の解決方法を指定するときに役立ちます。

� MAX_FAILURE属性を指定した場合は、REOPEN属性も設定する必要があります。指定した連続試行回数を超過すると、その宛先は REOPEN属性が指定されていないものとして処理されます。

� V$ARCHIVE_DEST固定ビューの FAILURE_COUNT列で障害件数を確認できます。関連するREOPEN_SECS列は、REOPEN属性値を示します。

� ALTER SYSTEM SET文によって宛先が変更されると、障害件数は 0（ゼロ）にリセットされます。このため、現在の障害件数の値よりも小さな値に MAX_FAILURE属性を設定する問題が回避されます。

� 障害件数が MAX_FAILURE属性に設定された値以上になると、REOPEN属性値は暗黙的に 0（ゼロ）に設定されます。これによって、REDO 転送サービスは、次のアーカイブ操作では

REDO データを代替アーカイブ先（ALTERNATE属性で指定）に転送するようになります。

� MAX_FAILURE属性を指定せずに（または MAX_FAILURE=0を指定し）、REOPEN属性に 0（ゼロ）ではない値を指定すると、REDO 転送サービスは、失敗した宛先に対して無制限にアーカイブを試行します。宛先が MANDATORY属性を持つ場合、オンライン REDO ログ・ファイルはこの宛先にアーカイブされるまで再利用できません。

カテゴリカテゴリカテゴリカテゴリ MAX_FAILURE=count

データ型数値

有効な値 >=0


必須属性 REOPEN


対応先 V$ARCHIVE_DESTビューの MAX_FAILURE、FAILURE_COUNTおよび REOPEN_SECS列

注意注意注意注意 : 宛先の障害件数が、指定した MAX_FAILURE属性の値に達した場合、その宛先を再利用するには、MAX_FAILURE属性値または他の属性を修正する必要があります。この結果、障害件数がゼロ（0）にリセットされます。


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


NET_TIMEOUT

NET_TIMEOUT

ネットワーク接続を終了する前に、プライマリ・システム上のログ・ライター・プロセスがネットワーク・サーバー（LNSn）プロセスからのステータスを待機する時間を秒単位で指定します。

使用方法使用方法使用方法使用方法� 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=seconds

データ型数値

有効な値 11 ～ 1200

1 小値は 1 秒に設定できますが、不適切なエラーやスタンバイ・データベースからの切断を回避するために、小値は 8 ～ 10 秒に設定することをお薦めします。

デフォルト値 180 秒

必須属性 LGWRと SYNC

属性との競合 ARCH、LOCATION、LGWRと ASYNC2

2 LGWRおよび ASYNC属性を指定すると、REDO 転送デバイスでは無視され、エラーは戻されません。

対応先プライマリ・データベースの V$ARCHIVE_DESTビューの NET_TIMEOUT列

注意注意注意注意 : 大保護モードで実行している場合は、NET_TIMEOUTに適切な値を指定するよう注意してください。不適切なネットワークの障害を検出すると、プライマリ・インスタンスが停止する可能性があります。


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


NOREGISTER

NOREGISTER

アーカイブ REDO ログ・ファイルの位置が、対応する宛先に記録されることを示します。

使用方法使用方法使用方法使用方法� NOREGISTER属性は、スタンバイ・データベースの宛先が Data Guard 構成の一部である場

合はオプションです。

� NOREGISTER属性は、宛先が Data Guard 構成の一部でない場合は必須です。

� これは、リモートの宛先のみの属性です。各アーカイブ REDO ログ・ファイルの位置は、常にプライマリ・データベースの制御ファイルに記録されます。

例例例例次の例は、NOREGISTER属性を示しています。

LOG_ARCHIVE_DEST_5='NOREGISTER'

カテゴリカテゴリカテゴリカテゴリ NOREGISTER

データ型キーワード


デフォルト値該当なし


属性との競合 LOCATION

対応先 V$ARCHIVE_DESTビューの DESTINATIONおよび

TARGET列


REOPEN

REOPEN

REDO 転送サービスが失敗した宛先の再オープンを試行するまでの小秒数を指定します。

使用方法使用方法使用方法使用方法� REOPEN属性はオプションです。

� REDO 転送サービスは、失敗した宛先の再オープンをログ・スイッチ時に試行します。

� REDO 転送サービスは、後のエラーの時刻に REOPEN間隔を加算した時刻が現在の時刻に達していないかどうかをチェックします。達していない場合、REDO 転送サービスは宛先の再オープンを試行します。

� REOPENは、接続障害のみでなく、すべてのエラーに適用されます。エラーには、ネットワーク障害、ディスク・エラー、クオータ例外などがありますが、これらに制限されません。

� OPTIONAL宛先に REOPENを指定すると、エラーが発生した場合に Oracle データベースでオンライン REDO ログ・ファイルを上書きできます。 MANDATORY宛先に REOPENを指定すると、REDO 転送サービスは、REDO データを正常に転送できない場合にプライマリ・データベースを停止します。この場合には、次のオプションを考慮します。

– 宛先を遅延させる、宛先を OPTIONAL として指定する、または SERVICE属性値を変更することで宛先を変更。

– 代替宛先の指定。

– 宛先の無効化。

例例例例次の例は、REOPEN属性を示しています。

LOG_ARCHIVE_DEST_3='SERVICE=stby1 MANDATORY REOPEN=60'LOG_ARCHIVE_DEST_STATE_3=ENABLE

カテゴリカテゴリカテゴリカテゴリ REOPEN [=seconds]

データ型数値

有効な値 0 秒以上

デフォルト値 300 秒

必須属性なし

属性との競合該当なし

対応先 V$ARCHIVE_DESTビューの REOPEN_SECSおよび

MAX_FAILURE列

関連項目関連項目関連項目関連項目 : REOPEN、MAX_FAILURESおよび ALTERNATE属性を使用して、宛先へのアーカイブ・プロセスに失敗した場合に実行する処置を指定する方法の詳細は、5.5 項「エラーが発生した場合の対処方法」を参照してください。


SYNC および ASYNC

SYNC およびおよびおよびおよび ASYNC

ログ・ライター・プロセス（LGWR）を使用したアーカイブの実行時に、ネットワーク I/O が同期で実行されるか（SYNC）、非同期で実行されるか（ASYNC）を指定します。

使用方法使用方法使用方法使用方法� 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

注意注意注意注意 : プライマリ・データベースが大保護モードまたは大可用性モードの場合、スタンバイ REDO ログ・ファイルのアーカイブ先とログ・ライター・プロセスによる宛先は、自動的に SYNCモードになります。

カテゴリカテゴリカテゴリカテゴリ SYNC ASYNC

データ型キーワード数値


デフォルト値該当なしなし

必須属性なし LGWR

属性との競合 ASYNC SYNC、LOCATION、ARCH


TRANSMIT_MODE列


TRANSMIT_MODEおよび ASYNC_BLOCKS列


TEMPLATE

TEMPLATE

宛先のディレクトリ仕様およびアーカイブ REDO ログ・ファイル名の形式テンプレートを定義します。このテンプレートは、スタンバイ宛先の STANDBY_ARCHIVE_DESTおよび LOG_ARCHIVE_FORMAT初期化パラメータで定義されたデフォルトのファイル名形式とは異なるファイル名を生成する場合に使用されます。

使用方法使用方法使用方法使用方法� 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 ディレクティブを指定する必要があります。

� filename_template 値は、スタンバイ宛先に転送され、そこで変換および検証された後、ファイル名が作成されます。

カテゴリカテゴリカテゴリカテゴリ TEMPLATE=filename_template_%t_%s_%r





属性との競合 LOCATION

対応先 V$ARCHIVE_DESTビューの REMOTE_TEMPLATEおよび REGISTER列

表表表表 14-1 TEMPLATE 属性のディレクティブ属性のディレクティブ属性のディレクティブ属性のディレクティブ

ディレクティブディレクティブディレクティブディレクティブ説明説明説明説明

%t インスタンス・スレッド番号を代入します。

%T 0（ゼロ）を埋め込んだインスタンス・スレッド番号を代入します。

%s ログ・ファイル順序番号を代入します。

%S 0（ゼロ）を埋め込んだログ・ファイル順序番号を代入します。

%r リセットログ ID を代入します。

%R 0（ゼロ）を埋め込んだリセットログ ID を代入します。


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


VALID_FOR

VALID_FOR

次の要因に基づき、REDO 転送サービスが REDO データを宛先にいつ転送できるかを識別します。

� データベースがプライマリ・ロールとスタンバイ・ロールのどちらで現在実行されているか

� オンライン REDO ログ・ファイルまたはスタンバイ REDO ログ・ファイル（あるいはその両方）が、現在この宛先のデータベースでアーカイブされているかどうか

使用方法使用方法使用方法使用方法� VALID_FOR属性はオプションです。ただし、各宛先に対してそれぞれ VALID_FOR属性を

定義し、ロールの推移後に Data Guard 構成が正しく動作するようにすることをお薦めします。

� LOG_ARCHIVE_DEST_n宛先ごとにこれらの要因を構成するには、キーワードのペア（VALID_FOR=(redo_log_type,database_role)）を使用してこの属性を指定します。

� redo_log_type キーワードは、次のいずれかをアーカイブする場合に有効な宛先を識別します。

– ONLINE_LOGFILE: この宛先は、オンライン REDO ログ・ファイルをアーカイブする場合のみ有効です。

– STANDBY_LOGFILE: この宛先は、スタンバイ REDO ログ・ファイルをアーカイブする場合のみ有効です。

– ALL_LOGFILES: この宛先は、オンライン REDO ログ・ファイルまたはスタンバイ REDO ログ・ファイルをアーカイブする場合に有効です。

カテゴリカテゴリカテゴリカテゴリ VALID_FOR=(redo_log_type, database_role)



デフォルト値 VALID_FOR=(ALL_LOGFILES, ALL_ROLES) 1

1 ロジカル・スタンバイ・データベースには、デフォルト値 VALID_FOR=(ALL LOGFILES, ALL_ROLES)を使用しないでください。詳細は、5.4.1 項および 12.1.2 項の使用例を参照してください。

必須属性なし


対応先 V$ARCHIVE_DESTビューの VALID_NOW、VALID_TYPEおよび VALID_ROLE列

注意注意注意注意 : (ALL_LOGFILES,ALL_ROLES)キーワードのペアはデフォルトですが、すべての宛先に適切とはかぎりません。たとえば、宛先がロジカル・スタンバイ・データベース（独自の REDO データを作成するオープン状態のデータベース）の場合、REDO 転送サービスによって転送される REDO データは、ロジカル・スタンバイ・データベースのローカル・オンライン REDOログ・ファイルを上書きする可能性があります。


VALID_FOR

� database_role キーワードは、この宛先がアーカイブに有効なロールを識別します。

– PRIMARY_ROLE: この宛先は、データベースがプライマリ・ロールで実行されている場合のみ有効です。

– STANDBY_ROLE: この宛先は、データベースがスタンバイ・ロールで実行されている場合のみ有効です。

– ALL_ROLES: この宛先は、データベースがプライマリ・ロールまたはスタンバイ・ロールで実行されている場合に有効です。

� 次の表は、VALID_FOR属性の値と、それぞれの値が使用されるロールを示しています。

� 宛先に 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 項の使用例を参照してください。

表表表表 14-2 VALID_FOR 属性の値属性の値属性の値属性の値

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 ログ・ファイルを使用できません。


VERIFY

VERIFY

アーカイブ操作を正常に完了した後に、アーカイバ（ARCn）プロセスでローカルまたはリモートで完了したアーカイブ REDO ログ・ファイルをスキャンして、その内容が正しいことを確認する必要があるかどうかを示します。

使用方法使用方法使用方法使用方法� 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'

カテゴリカテゴリカテゴリカテゴリ VERIFY

データ型キーワード


デフォルト値該当なし

必須属性なし

属性との競合 LGWR

対応先 V$ARCHIVE_DESTビューの VERIFYおよび ARCHIVER列


Data Guard に関連す

15
Data Guard に関連するに関連するに関連するに関連する SQL 文文文文
この章では、Data Guard 環境のスタンバイ・データベースで操作を実行するときに役立つ SQLおよび SQL*Plus 文の概要について説明します。この章は、次の項目で構成されています。

� ALTER DATABASE 文

� ALTER SESSION 文

この章では、特定の SQL 文について、その構文と簡単な概要を示します。これらの SQL 文およびその他の SQL 文の完全な構文および説明は、『Oracle Database SQL リファレンス』を参照してください。

ALTER SYSTEM SET文を使用して設定および動的な更新を行うことができる初期化パラメータについては、第 13 章を参照してください。

る SQL 文 15-1

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

指定したスレッドに 1 つ以上のオンライン REDO ログ・ファイ

ル・グループまたはスタンバイ REDO ログ・ファイル・グループ

を追加し、スレッドが割り当てられたインスタンスでログ・ファイルを使用できるようにします。

この文の例は、8.3.5 項を参照してください。

ADD [STANDBY] LOGFILE MEMBER 'filename' [REUSE] TO logfile-descriptor

既存のオンライン REDO ログ・ファイル・グループまたはスタン

バイ REDO ログ・ファイル・グループに新しいメンバーを追加し

ます。

この文の例は、5.7.3.2 項を参照してください。

[ADD|DROP] SUPPLEMENTAL LOG DATA {PRIMARY KEY|UNIQUE INDEX} COLUMNS

この文は、ロジカル・スタンバイ・データベース専用です。

ロジカル・スタンバイ・データベースを作成する前に、サプリメンタル・ロギングを使用可能にするために使用します。サプリメンタル・ロギングがロジカル・スタンバイ・データベースに対する変更のソースであるため、このようにする必要があります。完全なサプリメンタル・ロギングを実装するには、この文でPRIMARY KEY COLUMNSまたは UNIQUE INDEX COLUMNSキー

ワードを指定する必要があります。

詳細は、『Oracle Database SQL リファレンス』を参照してくださ

い。

COMMIT TO SWITCHOVER TO[[PRIMARY] | [[PHYSICAL|LOGICAL] [STANDBY]][WITH | WITHOUT] SESSION SHUTDOWN][WAIT | NOWAIT]

次のスイッチオーバーを実行します。

� カレント・プライマリ・データベースをスタンバイ・データベース・ロールに変更する

� 1 つのスタンバイ・データベースをプライマリ・データベー

ス・ロールに変更する

注意注意注意注意 : ロジカル・スタンバイ・データベースでは、ALTER DATABASE COMMIT TO SWITCHOVER文を発行する前に、

ALTER DATABASE PREPARE TO SWITCHOVER文を発行し、ス

イッチオーバーのためにデータベースを準備します。

この文の例は、7.2.1 項および 7.3.1 項を参照してください。

CREATE [PHYSICAL|LOGICAL] STANDBY CONTROLFILE AS 'filename' [REUSE]

フィジカルまたはロジカル・スタンバイ・データベースの維持に使用される制御ファイルを作成します。この文はプライマリ・データベースで発行します。


DROP [STANDBY] LOGFILE logfile_descriptor オンライン REDO ログ・ファイル・グループまたはスタンバイ

REDO ログ・ファイル・グループのすべてのメンバーを削除しま

す。


DROP [STANDBY] LOGFILE MEMBER 'filename' オンライン REDO ログ・ファイル・グループまたはスタンバイ

REDO ログ・ファイル・グループの 1 つ以上のメンバーを削除し

ます。

[NO]FORCE LOGGING 一時表領域および一時セグメントに対する変更を除くデータベースに対するすべての変更を、Oracle データベースが記録するかど

うかを制御します。 [NO]FORCE LOGGING句は、スタンバイ・

データベース間の一貫性の欠如を防止するために必要です。

この文を発行する場合、プライマリ・データベースがマウントされている必要があります。ただし、オープンする必要はありません。この文の例は、3.1.1 項を参照してください。


ALTER DATABASE 文

MOUNT [STANDBY DATABASE] スタンバイ・データベースをマウントし、スタンバイ・インスタンスが REDO データをプライマリ・インスタンスから受信できる

ようにします。

OPEN すでに起動され、マウントされたデータベースをオープンします。

� フィジカル・スタンバイ・データベースは読取り専用モードでオープンされ、ユーザーを読取り専用トランザクションに制限し、REDO データの生成を防ぎます。

� ロジカル・スタンバイ・データベースは読取り / 書込みモー

ドでオープンされます。


PREPARE TO SWITCHOVER TO[PRIMARY] | [[PHYSICAL|LOGICAL] [STANDBY]][WITH | WITHOUT] SESSION SHUTDOWN][WAIT | NOWAIT]


スイッチオーバーが実行される前に、LogMiner ディクショナリ

を構築することにより、プライマリ・データベースおよびロジカル・スタンバイ・データベースをスイッチオーバー用に準備します。ディクショナリ構築の完了後、ALTER DATABASE COMMIT TO SWITCHOVER文を発行し、プライマリおよびロジカル・スタ

ンバイ・データベースのロールを切り替えます。


RECOVER MANAGED STANDBY DATABASE [[NODELAY][DISCONNECT [FROM SESSION]][NOPARALLEL|PARALLEL [integer]][NOTIMEOUT|TIMEOUT [integer]][UNTIL CHANGE scn][USING CURRENT LOGFILE] ]

この文は、フィジカル・スタンバイ・データベースに対するREDO Apply を開始して制御します。RECOVER MANAGED STANDBY DATABASE句は、マウント、オープンまたはクローズ

されているフィジカル・スタンバイ・データベースで使用できます。例については、3.2.6 項の手順 2 および 6.3 項を参照してくだ

さい。

注意注意注意注意 : 複数の句およびキーワードが廃止され、下位互換性のため

にのみサポートされています。

RECOVER MANAGED STANDBY DATABASE CANCEL[[NOWAIT]|[WAIT][IMMEDIATE] ]

CANCEL句は、現在のアーカイブ REDO ログ・ファイルを適用し

た後に、フィジカル・スタンバイ・データベースで REDO Applyを取り消します。

RECOVER MANAGED STANDBY DATABASE FINISH [FORCE][NOWAIT|WAIT] ]

FINISH句は、ターゲット・フィジカル・スタンバイ・データ

ベースでフェイルオーバーを開始し、現行のスタンバイ REDO ロ

グ・ファイルをリカバリします。 FINISH句を使用するのは、プラ

イマリ・データベースに障害が発生した場合のみです。この句に

より、指定の遅延間隔がオーバーライドされます。

RFS プロセスを終了し、RFS プロセスの終了を待たずに即時に

フェイルオーバーできるようにするには、FORCEを挿入します。リカバリ・プロセスの完了後ではなく即時に制御を戻させるには、NOWAITを指定します。

例については、7.2.2 項の手順 4 を参照してください。

REGISTER [OR REPLACE][PHYSICAL|LOGICAL] LOGFILE filespec

手動でアーカイブ REDO ログ・ファイルを登録できます。


RECOVER TO LOGICAL STANDBY new_database_name

ログ適用サービスに対して、データベースをロジカル・スタンバイ・データベースに変換するコマンドを発行するまでは、引き続き変更をフィジカル・スタンバイ・データベースに適用するように指示します。詳細は、4.2.4.1 項を参照してください。

RESET DATABASE TO INCARNATION integer データベースのターゲット・リカバリ・インカネーションを、現在のインカネーションから別のインカネーションにリセットします。

SET STANDBY DATABASE TO MAXIMIZE {PROTECTION|AVAILABILITY|PERFORMANCE}

この句を使用して、Data Guard 構成におけるデータの保護レベル

を指定します。この句は、マウント済でオープンされていないプ

ライマリ・データベースから指定します。

表表表表 15-1 Data Guard 環境で使用される環境で使用される環境で使用される環境で使用される ALTER DATABASE 文（続き）文（続き）文（続き）文（続き）


Data Guard に関連する SQL 文 15-3

ALTER SESSION 文

15.2 ALTER SESSION 文文文文表 15-2 で、Data Guard に関連のある ALTER SESSION文について説明します。

START LOGICAL STANDBY APPLY INITIAL [scn-value] ][NEW PRIMARY dblink]


ロジカル・スタンバイ・データベースで SQL Apply を起動しま

す。この文の例は、6.4.1 項を参照してください。

{STOP|ABORT} LOGICAL STANDBY APPLY この文は、ロジカル・スタンバイ・データベース専用です。

ロジカル・スタンバイ・データベースで SQL Apply を正しく停止

するには、STOP句を使用します。SQL Apply を強制的に停止す

るには、ABORT句を使用します。この文の例は、7.3.2 項を参照し

てください。

ACTIVATE [PHYSICAL|LOGICAL] STANDBY DATABASE FINISH APPLY]

フェイルオーバーを実行します。スタンバイ・データベースは、マウント後に、この文を使用してアクティブ化する必要があります。

注意注意注意注意 : 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 Data Guard 環境で使用される環境で使用される環境で使用される環境で使用される ALTER SESSION 文文文文

ALTER SESSION 文文文文説明説明説明説明

ALTER SESSION [ENABLE|DISABLE] GUARD この文は、ロジカル・スタンバイ・データベース専用です。

権限を付与されているユーザーは、この文を使用して、現在のセッションでデータベース・ガードを選択または解除できます。


表表表表 15-1 Data Guard 環境で使用される環境で使用される環境で使用される環境で使用される ALTER DATABASE 文（続き）文（続き）文（続き）文（続き）



Oracle Data Guard に関連す

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 構成内のすべての宛先の現在の値、モードおよび状

況を含めた説明を表示します。

注意注意注意注意 : このビューに表示される情報は、インスタンスの停止後

には保存されません。

るビュー 16-1

V$ARCHIVE_DEST_STATUS プライマリ、フィジカルおよびロジカル

アーカイブ REDO ログ宛先の実行時および構成用の情報を表示

します。



V$ARCHIVE_GAP フィジカルおよびロジカル

アーカイブ REDO ログ・ファイルのギャップの識別に役立つ情

報を表示します。

V$ARCHIVED_LOG プライマリ、フィジカルおよびロジカル

制御ファイルのアーカイブ REDO ログ情報を、アーカイブ

REDO ログ・ファイル名を含めて表示します。

V$DATABASE プライマリ、フィジカルおよびロジカル

制御ファイルからのデータベース情報を表示します。ファスト・スタート・フェイルオーバー（Data Guard Broker でのみ

使用可能）に関する情報が含まれます。

V$DATABASE_INCARNATION プライマリ、フィジカルおよびロジカル

すべてのデータベース・インカネーションに関する情報を表示します。Oracle Database では、RESETLOGSオプションを使用

してデータベースがオープンされるたびに、新しいインカネーションが作成されます。V$DATABASEビューには、現在のイン

カネーションのみでなく、前のインカネーションのレコードも表示されます。

V$DATAFILE プライマリ、フィジカルおよびロジカル

制御ファイルからのデータファイル情報を表示します。

V$DATAGUARD_CONFIG プライマリ、フィジカルおよびロジカル

DB_UNIQUE_NAMEおよび LOG_ARCHIVE_CONFIG初期化パラ

メータで定義された一意のデータベース名をリスト表示します。

V$DATAGUARD_STATS プライマリ、フィジカルおよびロジカル

プライマリ・データベースで生成され、まだスタンバイ・データベースで使用できない REDO データの量を表示するととも

に、このビューの問合せ時点でプライマリ・データベースが仮にクラッシュした場合に失われる可能性のある REDO データの

量も表示します。 Data Guard 構成では、スタンバイ・データ

ベースのどのインスタンスでもこのビューを問い合せることができます。プライマリ・データベースでこのビューを問い合せ

た場合、列の値は消去されます。

V$DATAGUARD_STATUS プライマリ、フィジカルおよびロジカル

通常はアラート・ログまたはサーバー・プロセスのトレース・ファイルへのメッセージによってトリガーされるイベントが表示および記録されます。

V$LOG プライマリ、フィジカルおよびロジカル

オンライン REDO ログ・ファイルのログ・ファイル情報が格納

されます。

V$LOGFILE プライマリ、フィジカルおよびロジカル

オンライン REDO ログ・ファイルとスタンバイ REDO ログ・

ファイルに関する情報が格納されます。

V$LOG_HISTORY プライマリ、フィジカルおよびロジカル

制御ファイルからのログ履歴情報が格納されます。

V$LOGSTDBY_PROCESS ロジカルのみ SQL Apply の動作に関する動的な情報を表示します。この

ビューは、ロジカル・スタンバイ・データベースで SQL Applyを実行しているときのパフォーマンス上の問題を診断する場合に非常に有用です。このビューはまた、その他の問題の解決にも役立ちます。

V$LOGSTDBY_PROGRESS ロジカルのみロジカル・スタンバイ・データベースでの SQL Apply の進捗

状況を表示します。

表表表表 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 ログ・ファイルのログ・ファイル情報が格納

されます。

表表表表 16-1 Data Guard 構成に関連のあるビュー（続き）構成に関連のあるビュー（続き）構成に関連のあるビュー（続き）構成に関連のあるビュー（続き）


Oracle Data Guard に関連するビュー 16-3


第第第第 III 部部部部
付録付録付録付録
この部は、次の付録で構成されています。

� 付録 A「Data Guard のトラブルシューティング」

� 付録 B「Data Guard 構成におけるデータベースのアップグレード」

� 付録 C「ロジカル・スタンバイ・データベースでサポートされるデータ型および DDL」

� 付録 D「Data Guard および Real Application Clusters」

� 付録 E「カスケードされた宛先」

� 付録 F「Recovery Manager を使用したスタンバイ・データベースの作成」

� 付録 G「アーカイブ・トレースの設定」

Data Guard のトラブルシューティ

A
Data Guard のトラブルシューティングのトラブルシューティングのトラブルシューティングのトラブルシューティング
この付録は、スタンバイ・データベースのトラブルシューティングのヘルプとしてご利用いただけます。この項は、次の項目で構成されています。

� 一般的な問題

� ログ・ファイル宛先の障害

� ロジカル・スタンバイ・データベース障害の処理

� スタンバイ・データベースへのスイッチオーバーの問題

� SQL Apply が停止した場合の処置

� REDO データ転送のネットワーク調整

� スタンバイ・データベースのディスクのパフォーマンスが遅い

� プライマリ・データベースの停止を回避するにはログ・ファイルを一致させる必要がある

� ロジカル・スタンバイ・データベースのトラブルシューティング

ング A-1

一般的な問題

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操作はできません。

フィジカル・スタンバイ・データベースにデータファイルを追加する方法は、8.3.1 項を参照してください。

A-2 Oracle Data Guard 概要および管理

一般的な問題

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 -- --------- ------------------------------ ------------------------------------ 1 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

ログ・ファイル宛先の障害

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=ENABLELOG_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 スタンバイ・データベースへのスイッチオーバーの問題スタンバイ・データベースへのスイッチオーバーの問題スタンバイ・データベースへのスイッチオーバーの問題スタンバイ・データベースへのスイッチオーバーの問題通常、第 7 章で説明した手順に従うと、スイッチオーバーは正常に行われます。ただし、スイッチオーバーが失敗した場合でも、次の項を読むと、問題の解決に役立ちます。

� REDO データが転送されていないためスイッチオーバーできない

� SQL セッションがアクティブなためスイッチオーバーできない

� ユーザー・セッションがアクティブなためスイッチオーバーできない

� ORA-01102 エラーによりスイッチオーバーできない

� スイッチオーバー後に 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章を参照してください。

スイッチオーバーを続行するには、7.2.1 項（フィジカル・スタンバイ・データベースの場合）または 7.3.1 項（ロジカル・スタンバイ・データベースの場合）の説明に従って、ターゲットのスタンバイ・データベースをプライマリ・ロールに切り替える操作を再度実行します。

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は接続中のセッションがない場合にのみ実行できます



処置処置処置処置 : 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 --------- -------- ------------------------------------------------ 7 3537 oracle@nhclone2 (CJQ0) 10 14 16 19 21 6 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.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---------- --------- ------------------------------------------------ 1 26900 oracle@dbuser-sun (PMON) 2 26902 oracle@dbuser-sun (DBW0) 3 26904 oracle@dbuser-sun (LGWR) 4 26906 oracle@dbuser-sun (CKPT) 5 26908 oracle@dbuser-sun (SMON) 6 26910 oracle@dbuser-sun (RECO) 7 26912 oracle@dbuser-sun (ARC0) 8 26897 sqlplus@dbuser-sun (TNS V1-V3) 11 26917 sqlplus@dbuser-sun (TNS V1-V3)

9 rows selected.

この例の初の 7 つのセッションはすべて、Oracle Database のバックグラウンド・プロセスです。2 つの SQL*Plus セッションの内、一方は問合せを発行中のカレントの SQL*Plus セッションで、他方はスイッチオーバーを再試行する前に切断される必要のある余分のセッションです。

A.4.4 ORA-01102 エラーによりスイッチオーバーできないエラーによりスイッチオーバーできないエラーによりスイッチオーバーできないエラーによりスイッチオーバーできないスタンバイ・データベースとプライマリ・データベースが同じサイトに存在するとします。ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY文および ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY文の両方が正常に実行された後、フィジカル・スタンバイ・データベースとプライマリ・データベースを停止し、再起動します。

ただし、2 つ目のデータベースの起動はエラー・メッセージ ORA-01102「データベースを排他モードでマウントすることができません。」を伴って失敗します。

スタンバイ・データベース（つまり元のプライマリ・データベース）で使用される初期化パラメータ・ファイルに DB_UNIQUE_NAMEパラメータを設定していないと、スイッチオーバー中にこの現象が発生することがあります。スタンバイ・データベースの DB_UNIQUE_NAMEパラメータが設定されていない場合、スタンバイ・データベースとプライマリ・データベースの両方が同じマウント・ロックを使用するため、2 つ目のデータベースの起動時に ORA-01102 エラーが発生します。

処置処置処置処置 : DB_UNIQUE_NAME=unique_database_nameをスタンバイ・データベースが使用する初期化パラメータ・ファイルに追加して、スタンバイ・データベースとプライマリ・データベースを停止し、再起動します。

注意注意注意注意 : フィジカル・スタンバイ・データベースが起動後に読取り専用モードでオープンされていない場合、停止して再起動する必要はありません。



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. 新しいスタンバイ・データベース（元のプライマリ）に接続し、次の文を発行して、このスタンバイ・データベースをプライマリ・ロールに戻します。


この文が正常に実行された場合は、必要に応じてデータベースを停止し、再起動します。再起動すると、データベースはプライマリ・データベース・ロールで実行されるため、それ以降の手順を実行する必要はありません。

この文が正常に実行されなかった場合は、手順 3 に進んでください。

2. プライマリからフィジカル・スタンバイにロールを変更するスイッチオーバーを開始したときに、トレース・ファイルがログ・ディレクトリに書き込まれています。このトレース・ファイルには、元のプライマリ制御ファイルを再作成するために必要な SQL 文が含まれています。トレース・ファイルの位置を特定し、SQL 文を一時ファイルに抽出します。SQL*Plus から一時ファイルを実行します。これによって、新しいスタンバイ・データベースはプライマリ・ロールに戻されます。

3. 元のフィジカル・スタンバイ・データベースを停止します。

4. 新しいスタンバイ制御ファイルを作成します。このファイルは、プライマリ・データベースとフィジカル・スタンバイ・データベースの再同期化に必要です。フィジカル・スタンバイ制御ファイルを元のフィジカル・スタンバイ・システムにコピーします。フィジカル・スタンバイ制御ファイルの作成方法については、3.2.2 項を参照してください。


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 を再開してください。

障害の原因を特定するために DBA_LOGSTDBY_EVENTSビューを問い合せる方法は、第 16 章を参照してください。

表表表表 A-2 一般的な一般的な一般的な一般的な SQL Apply エラーの解決方法エラーの解決方法エラーの解決方法エラーの解決方法

エラーエラーエラーエラー解決方法解決方法解決方法解決方法

サポートされない文またはオラクル社が提供するパッケージが検出された可能性を示すエラー

DBA_LOGSTDBY_EVENTSビューで、後の文を検索してください。

この結果、SQL Apply の失敗の原因となった文とエラーが表示され

ます。不適切な SQL 文が原因で SQL Apply に失敗した場合は、そ

の文とエラーに関する情報とともにトランザクション情報を表示できます。このトランザクション情報は、問題の原因を正確に判断するために LogMiner ツールで使用できます。

データベース管理を要求するエラー（特定の表領域内の領域不足など）

問題を解決した後、ALTER DATABASE START LOGICAL STANDBY APPLY文を使用して SQL Apply を再開してください。

不適切な SQL 文の入力によるエラー（不適切なス

タンバイ・データベースのファイル名が表領域文に入力された場合など）

適切な SQL 文を入力した後、DBMS_LOGSTDBY.SKIP_TRANSACTIONプロシージャを使用して、次回 SQL Apply が実行さ

れたときに不適切な文が無視されるようにしてください。その後、ALTER DATABASE START LOGICAL STANDBY APPLY文を使用し

て SQL Apply を再開してください。

不適切な SKIP パラメータの設定によるエラー

（特定の表で全 DML がスキップされるように指定

したが、CREATE、ALTERおよび DROP TABLEの

各文がスキップされるように指定していないなど）

DBMS_LOGSTDBY.SKIP('TABLE','schema_name','table_name',null)プロシージャを発行した後、SQL Apply を再開して

ください。


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 つ持ちます。


ロジカル・スタンバイ・データベースのトラブルシューティング

また、REDO ログ・グループをプライマリ・データベースに追加した場合は、対応するスタンバイ REDO ログ・グループをスタンバイ・データベースに追加する必要があります。これにより、プライマリ・データベースが悪影響を受ける可能性が低くなります。これは、ログ・スイッチが発生したときに、必要なサイズのスタンバイ REDO ログ・ファイルが使用できないためです。

詳細は、3.1.3 項「スタンバイ REDO ログの構成」および 5.7 項「ログ・ファイルの管理」を参照してください。

A.9 ロジカル・スタンバイ・データベースのトラブルシューティロジカル・スタンバイ・データベースのトラブルシューティロジカル・スタンバイ・データベースのトラブルシューティロジカル・スタンバイ・データベースのトラブルシューティングングングング


� エラーのリカバリ

� SQL*Loader セッションのトラブルシューティング

� 長時間実行トランザクションのトラブルシューティング

� フラッシュバック・トランザクションでの ORA-1403 エラーのトラブルシューティング

A.9.1 エラーのリカバリエラーのリカバリエラーのリカバリエラーのリカバリロジカル・スタンバイ・データベースでは、ユーザー表、順序およびジョブがメンテナンスされます。他のオブジェクトをメンテナンスするには、REDO データ・ストリームにある DDL文を再発行する必要があリます。

SQL Apply に障害が発生した場合、エラーは DBA_LOGSTDBY_EVENTS表に記録されます。次の各項では、このようなエラーのリカバリ方法を説明します。

A.9.1.1 ファイル仕様が含まれているファイル仕様が含まれているファイル仕様が含まれているファイル仕様が含まれている DDL トランザクショントランザクショントランザクショントランザクションDDL 文は、プライマリ・データベースとロジカル・スタンバイ・データベースでは同じ方法で実行されます。基礎となるファイル構造が両方のデータベースで同じ場合、DDL はスタンバイ・データベース上で予想どおりに実行されます。

エラーの原因が、ロジカル・スタンバイ・データベース環境に適合しないファイル仕様を含んだ DDL トランザクションにある場合は、次の手順を実行して問題を解決してください。

1. 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 トランザクションをスキップするときに、プライマリおよびロジカル・スタンバイ・データベースの内容にずれを生じさせないようにしてください。可能な場合は、スキップされたトランザクションのかわりに補足用トランザクションを手動で実行する必要があります）。



次の例に、SQL Apply の停止、エラーの修正および SQL Apply の再開を示します。

SQL> SET LONG 1000SQL> 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-------------------------------------------------------------------------------22-OCT-03 15:47:58

ORA-16111: ログのマイニングと設定の適用

22-OCT-03 15:48:04 209627insert 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 NULLORA-01653: 表 SCOTT.EMPを拡張できません (%200バイト分、表領域 T_TABLE)。

この例で、ORA-01653メッセージは、表領域がいっぱいで表を拡張できないことを示しています。問題を修正するには、新しいデータファイルを表領域に追加します。次に例を示します。

SQL> ALTER TABLESPACE t_table ADD DATAFILE '/dbs/t_db.f' SIZE 60M;Tablespace altered.

次に、SQL Apply を再開します。


SQL Apply を再開すると、障害が発生したトランザクションが再実行され、ロジカル・スタンバイ・データベースに適用されます。

A.9.1.2 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;



この時点から、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 がプライマリ・データベースと一致するまで待機した後で、この表を問い合せます。詳細な例は、9.4.6 項「ロジカル・スタンバイ・データベースでの表の追加または再作成」を参照してください。

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 DATAINTO TABLE LOAD_STOK APPEND

� REPLACEキーワードを使用すると、LOAD_STOK表の内容が削除されてから新規のデータがロードされます。 SQL*Loader では、DELETE文を使用して表の内容が 1 つのトランザクションでパージされます。

LOAD DATAINTO TABLE LOAD_STOK REPLACE

SQL*Loader スクリプトで REPLACEキーワードを使用するかわりに、データをロードする前にプライマリ・データベースの表に対して SQL*Plus の TRUNCATE TABLEコマンドを発行することをお薦めします。これは、プライマリ・データベースとスタンバイ・データベースの両方から高速かつ効率的な方法で表のコピーをパージするのと同じ効果があります。これは、TRUNCATE TABLEコマンドはオンライン REDO ログ・ファイルに記録され、ロジカル・スタンバイ・データベースで SQL Apply により発行されるためです。

SQL*Loader スクリプトに引き続き REPLACEキーワードを挿入することはできますが、プライマリ・データベースではオブジェクトからの 0（ゼロ）行の DELETEが試行されます。プライマリ・データベースから行が削除されていないため、REDO ログ・ファイルに REDO は記録されません。したがって、ロジカル・スタンバイ・データベースに対して DELETE文は発行されません。



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:15 2003WARNING: the following transaction makes no progressWARNING: in the last 30 seconds for the given message!WARNING: xid =0x0016.007.000017b6 cscn = 1550349, message# = 28, slavid = 1knacrb: 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;



また、次の 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 < 10 10 ORDER BY DISK_READS/GREATEST(EXECUTIONS,1) DESC

すべての表に主キー制約を定義することをお薦めします。これにより自動的に列が NOT NULLとして定義されます。主キー制約を定義できない表の場合は、NOT NULLとして定義されている適切な列に索引を定義する必要があります。表に適切な列が存在しない場合はその表を見直し、可能な場合は SQL Apply でスキップしてください。

SCOTTスキーマの FTS表に対して発行された DML 文をすべてスキップする手順は、次のとおりです。



2. SCOTT.FTS表について、すべての DML トランザクションのスキップ・プロシージャを構成します。

SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML' , - schema_name => 'SCOTT' , - object_name => 'FTS');PL/SQL procedure successfully completed



ITL が不十分な状態のトラブルシューティングが不十分な状態のトラブルシューティングが不十分な状態のトラブルシューティングが不十分な状態のトラブルシューティング

Interested Transaction List（ITL）が不十分な状態は、SQL Apply インスタンスのアラート・ログでレポートされます。例 A-3 に、警告メッセージの例を示します。

例例例例 A-3 ITL が不十分な状態に関してレポートされる警告メッセージが不十分な状態に関してレポートされる警告メッセージが不十分な状態に関してレポートされる警告メッセージが不十分な状態に関してレポートされる警告メッセージ

Tue Apr 22 15:50:42 2003WARNING: the following transaction makes no progressWARNING: in the last 30 seconds for the given message!WARNING: xid =0x0006.005.000029fa cscn = 2152982, message# = 2, slavid = 17



リアルタイム適用の分析リアルタイム適用の分析リアルタイム適用の分析リアルタイム適用の分析

例 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_ADDRESSSQL_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---------- -- ---------- ---------- ---------- ---------- 8 TX 327688 48 6 0 10 TX 327688 48 0 4

この例では、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 が不十分な状態になったことのあるデータベース・セグメントがすべてレポートされます。

ITL が不十分な状態の解消が不十分な状態の解消が不十分な状態の解消が不十分な状態の解消

特定のデータベース・オブジェクトの INITRANSの整数を増やすには、初に SQL Apply を停止する必要があります。

注意注意注意注意 : この SQL 文は、Data Guard 環境のロジカル・スタンバイ・データベースに限定されません。すべての Oracle データベースに適用可能です。

関連項目関連項目関連項目関連項目 : INITRANSの整数を指定する方法の詳細は、『Oracle Database SQL リファレンス』を参照してください。これは、データベース・オブジェクトに割り当てられた各データ・ブロック内で割り当てられる初期同時トランザクション・エントリ数です。



次の例に、appスキーマ内の表 load_tab_1の INITRANSを増やすための手順を示します。



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



また、スイッチオーバー時に新しいスタンバイ・データベースでエラーが発生しないように、プライマリ・データベースでデータベース・オブジェクトを変更することを考慮してください。

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 0x0006.00e.00000417, Thread 1, RBA 0x02dd.00002221.10



調査調査調査調査

初のステップは、エラーの原因となった表の履歴データを分析することです。そのためには、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---------------- ----------------- --------------- - --- -------03001900EE070000 3492279 3492290 I 1 andrew02000D00E4070000 3492290 D 1 andrew

データベースが保持するように構成されている UNDO 保存（UNDO_RETENTION）の量と表に対するアクティビティによっては、戻される情報が広範囲にわたり、その量を制限するために構文間でバージョンの変更が必要になる場合があります。

戻された情報から、レコードが初に SCN 3492279 で挿入され、SCN 3492290 でトランザクション ID 02000D00E4070000 の一部として削除されたことがわかります。

このトランザクション ID を使用してデータベースを問い合せ、トランザクションの有効範囲を確認する必要があります。そのためには FLASHBACK_TRANSACTION_QUERYビューを問い合せます。

SELECT OPERATION , UNDO_SQL FROM FLASHBACK_TRANSACTION_QUERY WHERE XID = HEXTORAW('02000D00E4070000');

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 を再開すると、トランザクションがスタンバイ・データベースに適用されます。



Data Guard 構成におけるデータベース

B
Data Guard 構成におけるデータベースの構成におけるデータベースの構成におけるデータベースの構成におけるデータベースの
アップグレードアップグレードアップグレードアップグレード

この付録の手順では、構成にフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースが存在する場合に、Oracle Database 10g リリース 2（10.2）にアップグレードする方法を説明します。この付録は、次の項目で構成されています。

� Oracle Database ソフトウェアをアップグレードする前の注意事項

� フィジカル・スタンバイ・データベースが存在する場合の Oracle Database のアップグレード

� ロジカル・スタンバイ・データベースが存在する場合の Oracle Database のアップグレード

のアップグレード B-1

Oracle Database ソフトウェアをアップグレードする前の注意事項

B.1 Oracle Database ソフトウェアをアップグレードする前の注意ソフトウェアをアップグレードする前の注意ソフトウェアをアップグレードする前の注意ソフトウェアをアップグレードする前の注意事項事項事項事項

Oracle Database ソフトウェアのアップグレードを開始する前に、次のことに注意してください。

� 構成の管理に Data Guard Broker を使用している場合、ブローカ構成を削除または無効にする方法の詳細は、『Oracle Data Guard Broker』の指示を参照してください。

� この付録で説明する手順は、『Oracle Database アップグレード・ガイド』に記載されている手順とともに使用します。

� この付録で説明する手順では、データベース・アップグレード・アシスタント（DBUA）を使用してアップグレードを実行します。アップグレードを手動で実行する手順は、

『Oracle Database アップグレード・ガイド』を参照してください。 DBUA の使用を言及している場合にも、記載されている手動のアップグレード手順は実行する必要があります。

� NOLOGGING 操作をチェックします。 NOLOGGING 操作が実行されていた場合は、スタンバイ・データベースを更新する必要があります。詳細は、12.10 項「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文を発行します。


次に、残りのアクティブなデータベース・インスタンスで、現行のログ・ファイルをアーカイブします。次に例を示します。


これにより、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 概要および管理

フィジカル・スタンバイ・データベースが存在する場合の 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

フィジカル・スタンバイ・データベースが存在する場合の 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 NOMOUNTSQL> 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に設定し、プライマリ・データベースに接続します。現行のログのスレッドと順序番号を識別して記録します。次に、現行のログをアーカイブします。


20. スタンバイ・インスタンスで、V$LOG_HISTORYビューを問い合せ、手順 19 でアーカイブした各ログ・ファイルがスタンバイ・データベースで受信され、適用されていることを確認します。

SQL> SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY;

注意注意注意注意 : 古い（リリース 9.2 または 10.1 の）データベースがデータベース・アップグレード・アシスタントで表示されるには、oratabファイルに含まれている必要があります。 DBUA の使用方法の詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

注意注意注意注意 : プライマリ・データベースのアラート・ログに、プライマリ・データベースがスタンバイ・データベースに接続できないことを示すエラーが記録される場合があります。このエラーは無視できます。この時点まではスタンバイ・データベースが再起動されていないため、このエラーは予期されたものです。


ロジカル・スタンバイ・データベースが存在する場合の 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> ALTER SYSTEM ARCHIVE LOG CURRENT;

これにより、Real Application Clusters インスタンスから使用可能なアーカイブ REDOデータが、すべてスタンバイ・データベースに転送されます。

5. アクティブなプライマリ・データベース・インスタンスで、現行のログ・スレッドと順序番号を識別し、記録します。次に、現行のログをアーカイブします。


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 を停止します。




10. NORMALまたは IMMEDIATEの優先順位を指定して、アクティブなスタンバイ・データベース・インスタンスをすべて停止します。 Oracle ホームに対して実行中のリスナー、エージェントおよび他のプロセスをすべて停止します。


11. NORMALまたは IMMEDIATEの優先順位を指定して、プライマリ・データベース・インスタンスを停止します。 Oracle ホームに対して実行中のリスナー、エージェントおよび他のプロセスをすべて停止します。


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からデータベース・アップグレード・アシスタントを起動して、プライマリ・データベースをアップグレードします。次に例を示します。


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;

17. プライマリ・データベースをオープンして LogMiner ディクショナリを作成します。

SQL> ALTER DATABASE OPEN;SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

注意注意注意注意 : 古い（9.2 または 10.1 の）データベースがデータベース・アップグレード・アシスタントで表示されるには、oratabファイルに含まれている必要があります。 DBUA の使用方法の詳細は、『Oracle Database アップグレード・ガイド』を参照してください。

注意注意注意注意 : 手順 18 で制限付きセッション・モードを使用不可にするまでは、DML 操作または DDL 操作の発生を許可しないでください。



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）を起動して、ロジカル・スタンバイ・データベースをアップグレードします。


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';

注意注意注意注意 : 変更はプライマリ・データベースに伝播しないため、ユーザーにはアクティブ化したスタンバイ・データベースの更新を許可しないでください。



27. ロジカル・スタンバイ・データベースで SQL Apply を開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL;

28. Real Application Clusters を使用している場合は、他のスタンバイ・データベース・インスタンスを起動します。

29. プライマリ・システムで、アップグレードしたロジカル・スタンバイ・データベースへのアーカイブを使用可能にします。

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

30. Real Application Clusters を使用している場合は、他のプライマリ・データベース・インスタンスを起動します。

注意注意注意注意 : 前述のコマンドは、初は失敗して次のエラーが戻されます。

ORA-16101: 有効な開始 SCNが見つかりませんでした。

このエラーを解決するには、手順 26 の説明に従って論理ログ・ファイルを登録し、SQL Apply を開始する文を再発行します。


ロジカル・スタンバイ・データベースでサポートされる

C
ロジカル・スタンバイ・データベースでロジカル・スタンバイ・データベースでロジカル・スタンバイ・データベースでロジカル・スタンバイ・データベースで
サポートされるデータ型およびサポートされるデータ型およびサポートされるデータ型およびサポートされるデータ型および DDL

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

� データ型に関する考慮事項

� 記憶域型に関する考慮事項

� PL/SQL パッケージに関する考慮事項

� サポートされない表、順序およびビュー

� ロジカル・スタンバイ・データベースでスキップされる SQL 文

� ロジカル・スタンバイ・データベースでサポートされる DDL 文

データ型および DDL C-1

データ型に関する考慮事項

C.1 データ型に関する考慮事項データ型に関する考慮事項データ型に関する考慮事項データ型に関する考慮事項次の各項では、データベース・オブジェクトについて、サポートされるものとサポートされないものを示します。

� ロジカル・スタンバイ・データベースでサポートされるデータ型

� ロジカル・スタンバイ・データベースでサポートされないデータ型

C.1.1 ロジカル・スタンバイ・データベースでサポートされるデータ型ロジカル・スタンバイ・データベースでサポートされるデータ型ロジカル・スタンバイ・データベースでサポートされるデータ型ロジカル・スタンバイ・データベースでサポートされるデータ型ロジカル・スタンバイ・データベースでは、次のデータ型がサポートされます。

CHARNCHARVARCHAR2および VARCHARNVARCHAR2NUMBERDATETIMESTAMPTIMESTAMP WITH TIMEZONETIMESTAMP WITH LOCAL TIMEZONEINTERVAL YEAR TO MONTHINTERVAL DAY TO SECONDRAWCLOBおよび NCLOBBLOBLONGLONG RAWBINARY_FLOATBINARY_DOUBLE

C.1.2 ロジカル・スタンバイ・データベースでサポートされないデータ型ロジカル・スタンバイ・データベースでサポートされないデータ型ロジカル・スタンバイ・データベースでサポートされないデータ型ロジカル・スタンバイ・データベースでサポートされないデータ型ロジカル・スタンバイ・データベースでは、次のデータ型がサポートされません。

BFILEROWID、UROWIDユーザー定義型コレクション（VARRAYSおよびネストした表を含む） XML 型暗号化された列マルチメディア・データ型（Spatial、Image および Context を含む）

C-2 Oracle Data Guard 概要および管理

PL/SQL パッケージに関する考慮事項

C.2 記憶域型に関する考慮事項記憶域型に関する考慮事項記憶域型に関する考慮事項記憶域型に関する考慮事項次の各項では、記憶域型について、サポートされるものとサポートされないものを示します。

� サポートされる記憶域型

� サポートされない記憶域型

C.2.1 サポートされる記憶域型サポートされる記憶域型サポートされる記憶域型サポートされる記憶域型ロジカル・スタンバイ・データベースでは、次の記憶域型がサポートされます。

ヒープ構成表（パーティション化および非パーティション化）索引構成表（オーバーフロー・セグメントを含むパーティション化および非パーティション化）クラスタ表（索引クラスタおよびヒープ・クラスタを含む）

C.2.2 サポートされない記憶域型サポートされない記憶域型サポートされない記憶域型サポートされない記憶域型ロジカル・スタンバイ・データベースでは、セグメント圧縮記憶域型はサポートされません。

C.3 PL/SQL パッケージに関する考慮事項パッケージに関する考慮事項パッケージに関する考慮事項パッケージに関する考慮事項次の各項では、PL/SQL パッケージについて、サポートされるものとサポートされないものを示します。

� サポートされる PL/SQL パッケージ

� サポートされない 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に対する特定のサポートが用意されています。ジョブの実行はロジカル・スタンバイ・データベース上で一時停止され、スタンバイ・データベース上ではジョブを直接スケジュールできません。ただし、プライマリ・データベースで発行されたジョブは、スタンバイ・データベースにレプリケートされます。スイッチオーバーまたはフェイルオーバーが発生すると、元のプライマリ・データベースでスケジュールされていたジョブの実行は、新規のプライマリ・データベースで自動的に開始されます。

関連項目関連項目関連項目関連項目 : オラクル社が提供する PL/SQL パッケージの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

ロジカル・スタンバイ・データベースでサポートされるデータ型および DDL C-3

サポートされない表、順序およびビュー

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 COUNTRIESOE ORDERSOE CUSTOMERSOE 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_TYPPHONE_NUMBERS PHONE_LIST_TYPCUST_GEO_LOCATION SDO_GEOMETRY

プライマリ・データベースにサポートされない表が含まれている場合、REDO データをロジカル・スタンバイ・データベースに適用すると、SQL Apply サービスによって、その表が自動的に除外されます。

注意注意注意注意 : プライマリ・データベースの重要な表がロジカル・スタンバイ・データベースでサポートされない場合は、フィジカル・スタンバイ・データベースの使用を考慮することもできます。


ロジカル・スタンバイ・データベースでサポートされる DDL 文

C.5 ロジカル・スタンバイ・データベースでスキップされるロジカル・スタンバイ・データベースでスキップされるロジカル・スタンバイ・データベースでスキップされるロジカル・スタンバイ・データベースでスキップされるSQL 文文文文

デフォルトでは、SQL 文がプライマリ・データベースで実行された場合、次のリスト内の SQL文以外はすべて、ロジカル・スタンバイ・データベースに適用されます。

ALTER DATABASEALTER SESSIONALTER MATERIALIZED VIEWALTER MATERIALIZED VIEW LOGALTER SYSTEMCREATE CONTROL FILECREATE DATABASECREATE DATABASE LINKCREATE PFILE FROM SPFILECREATE SCHEMA AUTHORIZATIONCREATE MATERIALIZED VIEWCREATE MATERIALIZED VIEW LOGCREATE SPFILE FROM PFILEDROP DATABASE LINKDROP MATERIALIZED VIEWDROP MATERIALIZED VIEW LOGEXPLAINLOCK TABLESET CONSTRAINTSSET ROLESET TRANSACTION

C.6 ロジカル・スタンバイ・データベースでサポートされるロジカル・スタンバイ・データベースでサポートされるロジカル・スタンバイ・データベースでサポートされるロジカル・スタンバイ・データベースでサポートされるDDL 文文文文

次の表に、DBMS_LOGSTDBY.SKIPプロシージャ、および SQL DDL 文スキップ用の文のオプションの stmtパラメータについて、サポートされる値を示します。

� 表 C-1「DBMS_LOGSTDBY.SKIP プロシージャの stmt パラメータの値」

� 表 C-2「SQL DDL 文スキップ用の文のオプション」

表 C-1 に、DBMS_LOGSTDBY.SKIPプロシージャの stmtパラメータについて、サポートされる値を示します。表の左側の列には、キーワードの右側にある SQL 文セットの識別に使用される可能性のあるキーワードを示します。また、右側の列の SQL 文はすべて有効な値です。キーワードは、通常、データベース・オブジェクトによって定義されます。

関連項目関連項目関連項目関連項目 : DBMS_LOGSTDBYパッケージの詳細は『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を、また、9.4.4 項「DDL 文のスキップ・ハンドラの設定」も参照してください。

表表表表 C-1 DBMS_LOGSTDBY.SKIP プロシージャのプロシージャのプロシージャのプロシージャの stmt パラメータの値パラメータの値パラメータの値パラメータの値

キーワードキーワードキーワードキーワード関連する関連する関連する関連する SQL 文文文文

NON_SCHEMA_DDL 特定のスキーマに関連付けられていないすべての DDL

SCHEMA_DDL スキーマ・オブジェクト（例 : 表、索引、列）の作成、変更または

削除を行うすべての DDL 文

DML 表内の DML 文を含む（例 : INSERT、UPDATE、DELETE）

CLUSTER CREATE CLUSTERAUDIT CLUSTERDROP CLUSTERTRUNCATE CLUSTER



CONTEXT CREATE CONTEXTDROP CONTEXT

DATABASE LINK CREATE DATABASE LINKDROP DATABASE LINK

DIMENSION CREATE DIMENSIONALTER DIMENSIONDROP DIMENSION

DIRECTORY CREATE DIRECTORYDROP DIRECTORY

INDEX CREATE INDEXALTER INDEXDROP INDEX

PROCEDURE1 CREATE FUNCTIONCREATE LIBRARYCREATE PACKAGECREATE PACKAGE BODYCREATE PROCEDUREDROP FUNCTIONDROP LIBRARYDROP PACKAGEDROP PROCEDURE

PROFILE CREATE PROFILEALTER PROFILEDROP PROFILE

PUBLIC DATABASE LINK CREATE PUBLIC DATABASE LINKDROP PUBLIC DATABASE LINK

PUBLIC SYNONYM CREATE PUBLIC SYNONYMDROP PUBLIC SYNONYM

ROLE CREATE ROLEALTER ROLEDROP ROLESET ROLE

ROLLBACK STATEMENT CREATE ROLLBACK SEGMENTALTER ROLLBACK SEGMENTDROP ROLLBACK SEGMENT

SEQUENCE CREATE SEQUENCEDROP SEQUENCE

SESSION Log-ons

SYNONYM CREATE SYNONYMDROP SYNONYM

SYSTEM AUDIT AUDIT SQL_statementsNOAUDIT SQL_statements

SYSTEM GRANT GRANT system_privileges_and_rolesREVOKE system_privileges_and_roles

TABLE CREATE TABLEDROP TABLETRUNCATE TABLE

TABLESPACE CREATE TABLESPACEDROP TABLESPACETRUNCATE TABLESPACE

表表表表 C-1 DBMS_LOGSTDBY.SKIP プロシージャのプロシージャのプロシージャのプロシージャの stmt パラメータの値（続き）パラメータの値（続き）パラメータの値（続き）パラメータの値（続き）




表 C-2 に、SQL DDL 文スキップ用の文のオプションを示します。

TRIGGER CREATE TRIGGERENABLEおよび DISABLE句を使用した ALTER TRIGGERDROP TRIGGERENABLE ALL TRIGGERS句を使用した ALTER TABLEDISABLE ALL TRIGGERS句を使用した ALTER TABLE

TYPE CREATE TYPECREATE TYPE BODYALTER TYPEDROP TYPEDROP TYPE BODY

USER CREATE USERALTER USERDROP USER

VIEW CREATE VIEWDROP VIEW

1 Java スキーマ・オブジェクト（ソース、クラス、リソース）は、SQL 文をスキップ（無視）するためのプロシージャと同等とみなされます。

表表表表 C-2 SQL DDL 文スキップ用の文のオプション文スキップ用の文のオプション文スキップ用の文のオプション文スキップ用の文のオプション

文のオプション文のオプション文のオプション文のオプション SQL 文および操作文および操作文および操作文および操作

ALTER SEQUENCE ALTER SEQUENCE

ALTER TABLE ALTER TABLE

COMMENT TABLE COMMENT ON TABLE table, view, materialized view

COMMENT ON COLUMN table.column, view.column, materialized_view.column

DELETE TABLE DELETE FROM table, view

EXECUTE PROCEDURE CALL

パッケージ内のすべての変数、ライブラリまたはカーソルに対するすべてのプロシージャ、機能またはアクセスの実行

GRANT DIRECTORY GRANT privilege ON directory

REVOKE privilege ON directory

GRANT PROCEDURE GRANT privilege ON procedure, function, package

REVOKE privilege ON procedure, function, package

GRANT SEQUENCE GRANT privilege ON sequence

REVOKE privilege ON sequence

GRANT TABLE GRANT privilege ON table, view, materialized view

REVOKE privilege ON table, view, materialized view

GRANT TYPE GRANT privilege ON TYPE

REVOKE privilege ON TYPE

INSERT TABLE INSERT INTO table, view

LOCK TABLE LOCK TABLE table, view

SELECT SEQUENCE sequence.CURRVALを含むすべての文

表表表表 C-1 DBMS_LOGSTDBY.SKIP プロシージャのプロシージャのプロシージャのプロシージャの stmt パラメータの値（続き）パラメータの値（続き）パラメータの値（続き）パラメータの値（続き）




SELECT TABLE SELECT FROM table, view, materialized view

REVOKE privilege ON table, view, materialized view

UPDATE TABLE UPDATE table, view

表表表表 C-2 SQL DDL 文スキップ用の文のオプション（続き）文スキップ用の文のオプション（続き）文スキップ用の文のオプション（続き）文スキップ用の文のオプション（続き）

文のオプション文のオプション文のオプション文のオプション SQL 文および操作文および操作文および操作文および操作


Data Guard および Real Application Clu

D
Data Guard およびおよびおよびおよび Real Application Clusters
Oracle Data Guard 構成は、単一インスタンスおよび複数インスタンスの RAC データベースの組合せで構成されます。この章では、Oracle Data Guard を Oracle Real Application Clustersデータベースとともに使用する場合に適用される構成要件と考慮事項の概要を説明します。次の項目で構成されています。

� Real Application Clusters 環境でのスタンバイ・データベースの構成

� Real Application Clusters 環境での構成に関する考慮事項

� トラブルシューティング

sters D-1

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 ログ・ファイル 1、2、3、4、5 に REDO データをアーカイブし、スタンバイ・データベース宛先に REDO データを転送するのに対し、インスタンス 2 がローカル・アーカイブ REDO ログ・ファイル 32、33、34、35、36 に REDO データをアーカイブし、同じスタンバイ・データベース宛先に REDO データを転送します。スタンバイ・データベースでは、アーカイブ REDO ログ・ファイルを適用する正しい順序が自動的に判断されます。

インスタンスの組合せインスタンスの組合せインスタンスの組合せインスタンスの組合せ

単一インスタンス・単一インスタンス・単一インスタンス・単一インスタンス・スタンバイ・スタンバイ・スタンバイ・スタンバイ・データベースデータベースデータベースデータベース

複数インスタンス・複数インスタンス・複数インスタンス・複数インスタンス・スタンバイ・スタンバイ・スタンバイ・スタンバイ・データベースデータベースデータベースデータベース

単一インスタンス・プライマリ・単一インスタンス・プライマリ・単一インスタンス・プライマリ・単一インスタンス・プライマリ・データベースデータベースデータベースデータベース

可可

複数インスタンス・プライマリ・複数インスタンス・プライマリ・複数インスタンス・プライマリ・複数インスタンス・プライマリ・データベースデータベースデータベースデータベース

可可

D-2 Oracle Data Guard 概要および管理


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


スタンバイ・データベースのインスタンス間アーカイブ操作のためには、スタンバイ REDO ログ・ファイルを、プライマリ・データベースのアーカイブ REDO ログ・ファイルの一時リポジトリとして使用する必要があります。スタンバイ REDO ログ・ファイルを使用することにより、スタンバイ・データベースのパフォーマンスと信頼性が向上するだけでなく、クラスタ・ファイル・システムを持っていないクラスタで、インスタンス間アーカイブ操作の実行が可能になります。ただし、インスタンス間アーカイブ操作を行うためにはスタンバイ REDO ログ・ファイルが必要なため、プライマリ・データベースは、ログ・ライター・プロセス（LGWR）またはアーカイバ・プロセス（ARCn）を使用して、プライマリ・データベースでアーカイブ操作を実行する必要があります。

プライマリ・データベースとスタンバイ・データベースの両方が Real Application Clusters 構成の場合、スタンバイ・データベースの単一のインスタンスが、プライマリ・インスタンスによって転送されるログ・ファイルのすべてのセットを適用します。この場合、REDO データを適用しないスタンバイ・インスタンスを、REDO Apply の進行時に読取り専用モードにすることはできません。

Real Application Clusters 環境でスタンバイ・データベースを設定する手順環境でスタンバイ・データベースを設定する手順環境でスタンバイ・データベースを設定する手順環境でスタンバイ・データベースを設定する手順スタンバイ・データベースで REDO 転送サービスを設定するには、次の手順を実行します。

1. スタンバイ REDO ログ・ファイルを作成します。 Real Application Clusters 環境では、スタンバイ REDO ログ・ファイルは、すべてのインスタンスに共有されるディスク・デバイスに存在する必要があります。詳細は、3.1.3 項を参照してください。

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 データを送信するように各スタンバイ・インスタンスを構成します。

各プライマリ・データベース・インスタンスが、対応するスタンバイ・データベース・インスタンスにアーカイブできれば理想的です。ただし、これは必須ではありません。


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 つ以上含めることができます。


LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc

Real Application Clusters が、LOG_ARCHIVE_FORMATパラメータを持つアーカイブ REDO ログ・ファイルを一意に識別するためには、スレッド・パラメータ %t または %T が必須です。アーカイブ・ログ・ファイルの格納場所に関する詳細は、5.7.1 項を参照してください。

D.2.2 アーカイブ先の割当て制限アーカイブ先の割当て制限アーカイブ先の割当て制限アーカイブ先の割当て制限LOG_ARCHIVE_DEST_n初期化パラメータの QUOTA_SIZE属性を使用すると、アーカイブ先で使用できるディスク・デバイスの物理記憶域の量を指定できます。宛先に割り当てられた物理ディスクの全部または一部を占有できるようにアーカイブ先を指定できます。たとえば、Real Application Clusters 環境では、物理的なディスク・デバイスを 2 つ以上の別々のノードで共有できます。インスタンス間では、初期化パラメータの情報が共有されていないため、Real Application Clusters ノードは、物理ディスク・デバイスが他のインスタンスと共有されていることを認識していません。このため、宛先ディスク・デバイスがいっぱいになったときには重大な問題が発生します。すなわち、すべてのインスタンスがすでにいっぱいになったデバイスへのアーカイブを実行するまで、エラーは検出されません。これはデータベースの可用性に影響を及ぼします。

表表表表 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


Real Application Clusters 環境での構成に関する考慮事項

D.2.3 データ保護モードデータ保護モードデータ保護モードデータ保護モード大保護モードまたは大可用性モードで稼働している Real Application Clusters 構成では、

インスタンスがスタンバイ宛先との接続を失うと、他のすべてのインスタンスがその宛先へのデータ送信を停止します（これによって、宛先に転送されたデータの整合性が維持されます）。

障害のあったスタンバイ宛先が復旧すると、Data Guard は、ギャップなしになるまで、そのサイトを再同期化モードで実行します。これによって、そのスタンバイ宛先は Data Guard 構成に再び含まれます。

次のリストで、Real Application Clusters 環境における保護モードの動作を説明します。

� 大保護の構成

接続を失った宛先が後の LGWR SYNC宛先の場合、インスタンスは接続を失い、停止します。Real Application Clusters 構成内でスタンバイ宛先への接続を維持している宛先は、接続を失ったインスタンスをリカバリし、スタンバイ宛先への送信を継続します。 Real Application Clusters 構成内のすべてのインスタンスが後のスタンバイ宛先への接続を失った場合にのみ、プライマリ・データベースが停止します。

D.2.4 ロールの推移ロールの推移ロールの推移ロールの推移この項は、次の項目で構成されています。

� スイッチオーバー

� フェイルオーバー

D.2.4.1 スイッチオーバースイッチオーバースイッチオーバースイッチオーバーReal Application Clusters データベースの場合は、1 つのプライマリ・インスタンスと 1 つのスタンバイ・インスタンスのみをスイッチオーバー時にアクティブにできます。したがって、スイッチオーバーの前に、1 つのプライマリ・インスタンスと 1 つのスタンバイ・インスタンス以外はすべて停止します。スイッチオーバーの完了後、スイッチオーバーの実行時に停止したプライマリ・インスタンスとスタンバイ・インスタンスを再起動します。

D.2.4.2 フェイルオーバーフェイルオーバーフェイルオーバーフェイルオーバーReal Application Clusters スタンバイ・データベースへのフェイルオーバーを実行するには、初に 1 つのスタンバイ・インスタンス以外はすべて停止します。フェイルオーバーの完了後、停止したインスタンスを再起動します。

注意注意注意注意 : SQL ALTER DATABASE文を使用してスイッチオーバーを実行すると、REDO ログ・ファイルが存在していない場合は自動的に作成されます。これによって、COMMIT操作の完了に必要な時間が大幅に長くなる場合があるため、フィジカル・スタンバイ・データベースを作成するときは、REDO ログ・ファイルを手動で追加することをお薦めします。


トラブルシューティング

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;


トラブルシューティング

2. 大保護モードを大可用性モードまたは大パフォーマンス・モードのいずれかに変更する場合は、5.6.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 プライマリ・データベースをオープンし、通常にアクセスします。


カスケードされた

E
カスケードされた宛先カスケードされた宛先カスケードされた宛先カスケードされた宛先
プライマリ・システムの負荷を軽減するために、カスケードされた宛先カスケードされた宛先カスケードされた宛先カスケードされた宛先を実装できます。これによって、スタンバイ・データベースは、REDO データをプライマリ・データベースから直接受信するのではなく、別のスタンバイ・データベースから受信します。次のデータベースを構成できます。

� フィジカル・スタンバイ・データベース。プライマリ・データベースから受信した着信REDO データを、プライマリ・データベースと同じ方法で他のリモートの宛先に再転送します。

� ロジカル・スタンバイ・データベース。読取り / 書込みモードでオープンされるため、プライマリ・データベースから受信した REDO データのフィルタ処理と適用が完了した後に生成した REDO データを、独自のフィジカルまたはロジカルのスタンバイ・データベースのセットに送信します。

図 E-1 は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースへのカスケードされた宛先を示しています。

図図図図 E-1 カスケードされた宛先の構成例カスケードされた宛先の構成例カスケードされた宛先の構成例カスケードされた宛先の構成例

スタンバイ・データベースでは、REDO データを大 9 個の宛先までカスケードできます。ただし、実際には、カスケードされた REDO データを受信するように構成するのは、主としてレポート生成またはバックアップのオフロード専用のスタンバイ・データベースのみです。ロールの推移に関与する可能性のあるスタンバイ・データベースは、プライマリ・データベースから直接 REDO データを受信するように構成し、LOG_ARCHIVE_DEST_nパラメータの VALID_FOR属性を定義します。この結果、スイッチオーバー操作またはフェイルオーバー操作を実行した場合も、引き続き新しいプライマリ・データベースから直接 REDO データを受信できます。

宛先 E-1


� カスケードされた宛先の構成

� カスケードされた宛先を使用したロールの推移

� カスケードされた宛先の例

注意注意注意注意 : Oracle Data Guard Broker は、カスケードされた宛先の構成または管理には使用できませんが、許容することはできます。

E-2 Oracle Data Guard 概要および管理

カスケードされた宛先の構成

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 プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースプライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースプライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースプライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベース

の初期化パラメータの初期化パラメータの初期化パラメータの初期化パラメータ


Chicago データベースデータベースデータベースデータベース（スタンバイ・ロール）（スタンバイ・ロール）（スタンバイ・ロール）（スタンバイ・ロール）


DB_UNIQUE_NAME=bostonLOG_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

DB_UNIQUE_NAME=chicagoLOG_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

DB_UNIQUE_NAME=denverLOG_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

カスケードされた宛先の構成

ボストンのプライマリ・データベースおよびシカゴのフィジカル・スタンバイ・データベースでは、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.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 を介してリモート・スタンバイ・データベースに移送できるため、オフサイトの格納場所にテープを発送する必要がなくなります。



プライマリ・データベースと 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 回送信するこ



とは、プライマリ・データベースのパフォーマンスを許容できないレベルまで低下させると考えられます。

この問題は、カスケードされた宛先によって解決できます。カスケード・スタンバイ・データベースを設定するには、第 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 ログ・ファイルを、手動で送信することが必要な場合もあります。



WAN がアップグレードされて、リモート・スタンバイ・データベースに直接接続できるようになった場合は、リポジトリの宛先を変更して、リモート・スタンバイ・データベースを直接指すようにするか、新たにリモート・スタンバイ・データベースの宛先を作成し、リポジトリへの転送は、アーカイブ・ログ・リポジトリとして継続します。


Recovery Manager を使用したスタンバイ・データベースの

F
Recovery Manager を使用したスタンバイ・を使用したスタンバイ・を使用したスタンバイ・を使用したスタンバイ・
データベースの作成データベースの作成データベースの作成データベースの作成

この付録では、Oracle Recovery Manager を使用してスタンバイ・データベースを作成する方法を説明します。この付録は、次の項目で構成されています。

� スタンバイ・データベースを作成するための Recovery Manager の準備

� Recovery Manager を使用したスタンバイ・データベースの作成 : 概要

� スタンバイ・データベースの設定

� 同一のディレクトリ構造のスタンバイ・データベースの作成

� 異なるディレクトリ構造のスタンバイ・データベースの作成

� ローカル・ホスト上へのスタンバイ・データベースの作成

� イメージ・コピーを使用したスタンバイ・データベースの作成

� 使用例

作成 F-1

スタンバイ・データベースを作成するための 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 を使用したスタンバイ・データベースの準備を使用したスタンバイ・データベースの準備を使用したスタンバイ・データベースの準備を使用したスタンバイ・データベースの準備

タスクタスクタスクタスク手順の詳細手順の詳細手順の詳細手順の詳細

スタンバイ・データベースの作成に使用するプライマリ・データベースのバックアップの作成

『Oracle Database バックアップおよびリカバリ基

礎』の説明に従い、プライマリ・データベースの通常のバックアップ手順を実行します。

スタンバイ制御ファイルとして使用可能なプライマリ制御ファイルのバックアップの作成（存在しない場合）

F.1.2 項「Recovery Manager を使用したスタンバ

イ制御ファイルの作成」を参照してください。

スタンバイ・データファイルのファイル名の選択

F.1.3 項「Recovery Manager を使用した場合のス

タンバイ・データベース・データファイルのネーミング」を参照してください。

スタンバイ・データベースのアーカイブREDO ログ・ファイルおよびスタンバイ

REDO ログ・ファイルのファイル名の選択

F.1.4 項「Recovery Manager を使用した場合のス

タンバイ・データベース・ログ・ファイルのネーミング」を参照してください。

F-2 Oracle Data Guard 概要および管理


表 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 MOUNTBACKUP CURRENT CONTROLFILE FOR STANDBY;SQL> ALTER DATABASE OPEN;SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; # so backup is consistent and recoverableBACKUP 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


手順手順手順手順 1 バックアップ・セットまたはイメージ・コピーをリストするバックアップ・セットまたはイメージ・コピーをリストするバックアップ・セットまたはイメージ・コピーをリストするバックアップ・セットまたはイメージ・コピーをリストする

必要に応じて、LISTコマンドを発行してバックアップ・セットをリストするか、LIST COPYコマンドを発行してイメージ・コピーをリストします。

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_'

注意注意注意注意 : SQL ALTER DATABASE CREATE STANDBY CONTROLFILE AS文によってスタンバイ制御ファイルがすでに作成されている場合は、次のように Recovery Manager の CATALOGコマンドを使用して、リカバリ・カタログにスタンバイ制御ファイルのメタデータを追加できます。

CATALOG CONTROLFILECOPY '/tmp/sby_control01.ctl';

スタンバイ・データベースのスタンバイ・データベースのスタンバイ・データベースのスタンバイ・データベースのホストホストホストホストディレクトリ構造ディレクトリ構造ディレクトリ構造ディレクトリ構造名前の変更名前の変更名前の変更名前の変更

プライマリと同じホストプライマリ・ホストと異なる必須。

プライマリと同じホストプライマリ・ホストと同じ無効。スタンバイ・データベー

スのデータファイルは、プライマリ・データベースのデータファイルと同じホストの同じディレクトリには常駐できません。

プライマリと異なるホストプライマリ・ホストと同じ必須ではない。

プライマリと異なるホストプライマリ・ホストと異なる必須。



スタンバイ制御ファイル内のデータファイル名を指定する方法が複数存在するため、設定の優先順位を決定する方法が必要です。表 F-2 に、スタンバイ・データベース内のデータファイルのネーミングの階層を指定します。

スタンバイ・データベースで 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 によりエラーが発生します。

表表表表 F-2 スタンバイ・データベース内のデータファイルのネーミング優先順位スタンバイ・データベース内のデータファイルのネーミング優先順位スタンバイ・データベース内のデータファイルのネーミング優先順位スタンバイ・データベース内のデータファイルのネーミング優先順位

スタンバイ・データファイルのスタンバイ・データファイルのスタンバイ・データファイルのスタンバイ・データファイルのネーミング方法ネーミング方法ネーミング方法ネーミング方法要件要件要件要件

1 SET NEWNAMEコマンドを発行する。スタンバイ・データベースを作成するには、このコマンドを RUNブロック内で発行する必要があり

ます。

2 Recovery Manager の DUPLICATEコマンドの DB_FILE_NAME_CONVERTオプションを使用する。

なし。

3 CONFIGURE AUXNAMEコマンドを

発行する。

リカバリ・カタログに接続し、データファイル用に NULL以外の AUXNAMEをカタログに格納する

必要があります。

4 スタンバイ制御ファイルで現在指定されているデータファイルのファイル名。スタンバイ・ファイル名は、プライマリ・ファイル名と同じか、または DB_FILE_NAME_CONVERTパラメータを使用して

ネーミングされています。

ファイル名が同じ場合、スタンバイの初期化パラメータ・ファイルで DB_FILE_NAME_CONVERTパラメータを設定する必要があります。ファイル

名が同じ場合、DUPLICATEコマンドの

NOFILENAMECHECK句を指定する必要がありま

す。


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 は接続を切断し、スタンバイ・データベースのメディア・リカバリを実行しません。スタンバイ・データベースはリカバリ・カタログに登録しないでください。


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 によってスタンバイ・データベースの作成後にリカバリを行う場合、実行するリカバリに対してスタンバイ制御ファイルが使用可能である必要があります。したがって、次の条件を満たしている必要があります。

� スタンバイ・データベースのリカバリ終了時刻は、スタンバイ制御ファイルのチェックポイント SCN 以上である必要があります。

� スタンバイ制御ファイルのチェックポイント SCN が含まれているアーカイブ REDO ログ・ファイルは、リカバリ用にスタンバイ・サイトから使用可能である必要があります。

これらの条件が満たされていることを確認するには、スタンバイ制御ファイルの作成後にALTER SYSTEM ARCHIVE LOG CURRENT文を発行する方法があります。この文は、プライマリ・データベースのオンライン REDO ログ・ファイルをアーカイブします。その後、新のアーカイブ REDO・ログ・ファイルを Recovery Manager でバックアップするか、またはアーカイブ REDO ログ・ファイルをスタンバイ・サイトに移動します。

Recovery Manager でスタンバイ・データベースを作成する際の DUPLICATEの制限事項については、『Oracle Database Recovery Manager リファレンス』を参照してください。

注意注意注意注意 : Recovery Manager でスタンバイ・データベースを作成した後、スタンバイ・データベースを手動または管理リカバリ・モードに設定したり読取り専用モードでオープンする前に、ギャップ・シーケンスを解決する必要があります。ギャップ・シーケンスの解決方法の詳細は、5.8 項を参照してください。

注意注意注意注意 : この章の手順では、スタンバイ・データベースの作成に Recovery Manager のバックアップを使用していることを前提としています。Recovery Manager のイメージ・コピーを使用している場合、F.7 項を参照してください。


スタンバイ・データベースの設定

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（または初期化パラメータ・ファイル）をターゲット・ホストからスタンバイ・ホストにコピーします。 3.2.3項で説明しているように、スタンバイ・データベースの初期化パラメータ・ファイルの必須パラメータをすべて設定します。

たとえば、異なるディレクトリ構造を持つ異なるホスト上にスタンバイ・データベースを作成する場合、次のパラメータを編集します。

� _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.arcDB_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 SYSDBASQL> STARTUP NOMOUNT PFILE=initSBDB1.ora

3. プライマリ・データベースがマウントまたはオープンされていない場合、SQL*Plus を使用してデータベースをマウントまたはオープンします。たとえば、SYSとして prod1に接続し、データベースをオープンするには、次のコマンドを入力します。

SQL> CONNECT SYS/sys_pwd@prod1 AS SYSDBASQL> STARTUP PFILE=initPROD1.ora

リカバリ・カタログ・データベースがオープンされていることを確認します。たとえば、SYSとして catdbに接続し、リカバリ・カタログ・データベースをオープンするには、次のコマンドを入力します。

SQL> CONNECT SYS/oracle@catdb AS SYSDBASQL> STARTUP PFILE=initCATDB.ora


スタンバイ・データベースの設定

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 つ作成されます。


同一のディレクトリ構造のスタンバイ・データベースの作成

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.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 143508; DUPLICATE TARGET DATABASE FOR STANDBY NOFILENAMECHECK DORECOVER;}

Recovery Manager により、すべての増分バックアップ、アーカイブ REDO ログ・ファイルのバックアップおよびアーカイブ REDO ログ・ファイルを使用した不完全リカバリが実行されます。スタンバイ・データベースはマウントされた状態になります。


異なるディレクトリ構造のスタンバイ・データベースの作成

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パラメータを使用したスタンバイ・データベース・ファイルのネーミングの例は、3.1.4 項を参照してください。

F.5.1.1 リカバリを実行しないスタンバイ・データベースの作成リカバリを実行しないスタンバイ・データベースの作成リカバリを実行しないスタンバイ・データベースの作成リカバリを実行しないスタンバイ・データベースの作成リカバリを実行せずにスタンバイ・データベースを作成する場合、DUPLICATEコマンドのDORECOVERオプションを指定しないでください。デフォルトで、Recovery Manager はスタンバイ・データベースをマウントした状態にし、リカバリを実行しません。

パラメータを使用して、リカバリを実行せずにスタンバイ・ファイルをネーミングするには、パラメータを使用して、リカバリを実行せずにスタンバイ・ファイルをネーミングするには、パラメータを使用して、リカバリを実行せずにスタンバイ・ファイルをネーミングするには、パラメータを使用して、リカバリを実行せずにスタンバイ・ファイルをネーミングするには、次の手順を実行します。次の手順を実行します。次の手順を実行します。次の手順を実行します。


2. DUPLICATEコマンドを実行します。たとえば、次のコマンドを実行します。

DUPLICATE TARGET DATABASE FOR STANDBY;

バックアップのリストア後、Recovery Manager はスタンバイ・データベースをマウントした状態にします。

F.5.1.2 スタンバイ・データベースの作成およびリカバリの実行スタンバイ・データベースの作成およびリカバリの実行スタンバイ・データベースの作成およびリカバリの実行スタンバイ・データベースの作成およびリカバリの実行DB_FILE_NAME_CONVERTパラメータを使用してスタンバイ・データファイルをネーミングし、LOG_FILE_NAME_CONVERTパラメータを使用してスタンバイ・データベースのログ・ファイルをネーミングした後、DUPLICATEコマンドの DORECOVERオプションを指定してスタンバイ・データベースを作成し、リカバリを実行します。この場合の手順は、F.4.2 項と同じです。



F.5.2 SET NEWNAME を使用したスタンバイ・データベース・ファイルのを使用したスタンバイ・データベース・ファイルのを使用したスタンバイ・データベース・ファイルのを使用したスタンバイ・データベース・ファイルのネーミングネーミングネーミングネーミング

この場合、SET NEWNAMEコマンドを使用してスタンバイ・データファイルをネーミングします。


リカバリを実行せずに、リカバリを実行せずに、リカバリを実行せずに、リカバリを実行せずに、SET NEWNAME コマンドを使用してスタンバイ・データベース・コマンドを使用してスタンバイ・データベース・コマンドを使用してスタンバイ・データベース・コマンドを使用してスタンバイ・データベース・ファイルをネーミングするには、次の手順を実行します。ファイルをネーミングするには、次の手順を実行します。ファイルをネーミングするには、次の手順を実行します。ファイルをネーミングするには、次の手順を実行します。


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.5.2.2 スタンバイ・データベースの作成およびリカバリの実行スタンバイ・データベースの作成およびリカバリの実行スタンバイ・データベースの作成およびリカバリの実行スタンバイ・データベースの作成およびリカバリの実行スタンバイ・データベースを作成し、リカバリを実行する場合、DUPLICATEコマンドのDORECOVERオプションを指定します。

SET NEWNAME コマンドを使用してスタンバイ・データベース・ファイルをネーミングし、コマンドを使用してスタンバイ・データベース・ファイルをネーミングし、コマンドを使用してスタンバイ・データベース・ファイルをネーミングし、コマンドを使用してスタンバイ・データベース・ファイルをネーミングし、リカバリを実行するには、次の手順を実行します。リカバリを実行するには、次の手順を実行します。リカバリを実行するには、次の手順を実行します。リカバリを実行するには、次の手順を実行します。


2. DUPLICATEコマンドを実行します。次の手順に従います。

a. リカバリ終了時刻がスタンバイ制御ファイルのチェックポイント SCN 以上であり、チェックポイント SCN が含まれているログ・ファイルがリカバリ用に使用可能であることを確認します（F.2.2 項で説明しています）。

b. 必要に応じて SETコマンドを発行し、不完全リカバリの終了時刻、SCN またはログ順序番号を指定します。

c. 自動チャネルが構成されていない場合、1 つ以上の補助チャネルを手動で割り当てます。

d. スタンバイ・データベースのデータファイル用に新規のファイル名を指定します。

e. DORECOVERオプションを指定して DUPLICATEコマンドを発行します。




# 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;}


F.5.3 CONFIGURE AUXNAME を使用したスタンバイ・データベース・ファイルを使用したスタンバイ・データベース・ファイルを使用したスタンバイ・データベース・ファイルを使用したスタンバイ・データベース・ファイルのネーミングのネーミングのネーミングのネーミング

この場合、CONFIGURE AUXNAMEコマンドを使用してスタンバイ・データファイルをネーミングします。


CONFIGURE AUXNAME を使用して、リカバリを実行せずにスタンバイ・データベース・を使用して、リカバリを実行せずにスタンバイ・データベース・を使用して、リカバリを実行せずにスタンバイ・データベース・を使用して、リカバリを実行せずにスタンバイ・データベース・ファイルをネーミングするには、次の手順を実行します。ファイルをネーミングするには、次の手順を実行します。ファイルをネーミングするには、次の手順を実行します。ファイルをネーミングするには、次の手順を実行します。


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コマンドを実行します。自動チャネルが構成されていない場合、次の例のように、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 filesCONFIGURE AUXNAME FOR DATAFILE 1 CLEAR; CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR; ...CONFIGURE AUXNAME FOR DATAFILE n CLEAR;


CONFIGURE AUXNAME を使用して、スタンバイ・ファイルをネーミングし、リカバリを実を使用して、スタンバイ・ファイルをネーミングし、リカバリを実を使用して、スタンバイ・ファイルをネーミングし、リカバリを実を使用して、スタンバイ・ファイルをネーミングし、リカバリを実行するには、次の手順を実行します。行するには、次の手順を実行します。行するには、次の手順を実行します。行するには、次の手順を実行します。


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';


� リカバリ終了時刻がスタンバイ制御ファイルのチェックポイント SCN 以上であり、チェックポイント SCN が含まれているログ・ファイルがリカバリ用に使用可能であることを確認します（F.2.2 項で説明しています）。

� 必要に応じて SETコマンドを発行し、不完全リカバリの終了時刻、SCN またはログ順序番号を指定します。

� 自動チャネルが構成されていない場合、1 つ以上の補助チャネルを手動で割り当てます。

� DUPLICATE TARGET DATABASE FOR STANDBYコマンドを発行します。


ローカル・ホスト上へのスタンバイ・データベースの作成


# 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;


4. データファイルの補助名を誤って上書きしないように、補助名の設定を消去します。たとえば、Recovery Manager のプロンプトで、次のように入力します。

# un-specify auxiliary names for the data filesCONFIGURE 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.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

（両ホストで同じ）

/oracle/dbs/df1.f /data/df1.f /data/df1.f

（イメージ・コピーと同じパス名）

F.7.2 項「コピーおよびデー

タファイルで同一の名前を使用する場合」を参照してください。

/data

（両ホストで同じ）

/oracle/dbs/df1.f /data/df1.f /oracle/sb/df1.f

（イメージ・コピーと異なるパス名）

F.7.3 項「コピーおよびデー

タファイルで異なる名前を使用する場合」を参照してください。



表 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.oraSQL> ALTER DATABASE MOUNT;



F.7.3 コピーおよびデータファイルで異なる名前を使用する場合コピーおよびデータファイルで異なる名前を使用する場合コピーおよびデータファイルで異なる名前を使用する場合コピーおよびデータファイルで異なる名前を使用する場合この手順では、スタンバイ・データファイルおよびプライマリ・データファイルのイメージ・コピーに異なるファイル名を使用していることを前提としています。

F.7.3.1 リカバリを実行しないスタンバイ・データベースの作成リカバリを実行しないスタンバイ・データベースの作成リカバリを実行しないスタンバイ・データベースの作成リカバリを実行しないスタンバイ・データベースの作成スタンバイ・データベースを作成してリカバリを実行しない場合、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パラメータを次のように設定します。


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 fileSQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';

5. 補助インスタンスを起動し、スタンバイ制御ファイルをマウントします。たとえば、SQL*Plus を起動し、次のように入力します。

SQL> STARTUP MOUNT PFILE=/dsk2/oracle/dbs/initSTANDBY1.ora




コピーおよびスタンバイ・データファイルの名前が異なる場合に、スタンバイ・データベースコピーおよびスタンバイ・データファイルの名前が異なる場合に、スタンバイ・データベースコピーおよびスタンバイ・データファイルの名前が異なる場合に、スタンバイ・データベースコピーおよびスタンバイ・データファイルの名前が異なる場合に、スタンバイ・データベースを作成し、リカバリを実行するには、次の手順を実行します。を作成し、リカバリを実行するには、次の手順を実行します。を作成し、リカバリを実行するには、次の手順を実行します。を作成し、リカバリを実行するには、次の手順を実行します。

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パラメータを次のように設定します。



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;



使用例

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 では、リストアにはバックアップよりもイメージ・コピーを優先して使用しますが、イメージ・コピーが存在しない場合は、バックアップがリストアされます。したがって、次のスクリプトを実行します。


使用例

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 ログ・ファイルがディスクに適用されます。


アーカイブ・トレースの

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

設定 G-1

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_DESTNAME 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 項で説明するように、トレース・レベルが 1、2、4 および 8 に設定されます。

次のアーカイブ REDO ログ・ファイルをプライマリ・データベースから受信したときに、リモート・ファイル・サーバー（RFS）および ARCn プロセスによって生成されたトレース出力に影響するように、別のスタンバイ・セッションから ALTER SYSTEM文を発行します。たとえば、次のように入力します。

SQL> ALTER SYSTEM SET LOG_ARCHIVE_TRACE=32;

G-2 Oracle Data Guard 概要および管理

トレース・ファイルの位置の判別

G.2.2 整数値の選択整数値の選択整数値の選択整数値の選択LOG_ARCHIVE_TRACEパラメータの整数値は、データのトレース・レベルを表します。一般的には、レベルが高いほど、情報が詳細になります。次の整数値を使用できます。

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

レベルレベルレベルレベル意味意味意味意味

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 アクティビティ（メディア・リカバリまたはフィジカル・

スタンバイ）を追跡します。

注意注意注意注意 : レベルの数値は実際のトレース出力には表示されません。ここでは説明の目的で示してあります。

アーカイブ・トレースの設定 G-3

トレース・ファイルの位置の判別

( 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 概要および管理

索引索引索引索引

AAFFIRM 属性，5-21，14-2ALTER DATABASE 文

ABORT LOGICAL STANDBY 句，15-4ACTIVATE STANDBY DATABASE 句，7-10，7-18，

10-7，12-32，12-40，15-4ACTIVATE STANDBY DATABASE 文，12-32ADD STANDBY LOGFILE GROUP 句，3-4ADD STANDBY LOGFILE MEMBER 句，5-25，15-2，

A-2ADD STANDBY LOGFILE 句，3-4，8-14，15-2，A-2ADD SUPPLEMENTAL LOG DATA 句，15-2ALTER STANDBY LOGFILE GROUP 句，3-4ALTER STANDBY LOGFILE 句，3-4CLEAR UNARCHIVED LOGFILES 句，8-17COMMIT TO SWITCHOVER 句，7-8，7-12，7-16，

12-41，12-42，15-2Real Application Clusters，D-7トラブルシューティング，A-5，A-7

CREATE CONTROLFILE 句，8-16CREATE DATAFILE AS 句，A-2CREATE STANDBY CONTROLFILE 句，3-8，A-3

REUSE 句，15-2DROP LOGFILE 句，A-2DROP STANDBY LOGFILE MEMBER 句，15-2，A-2FORCE LOGGING 句，2-6，3-2，12-43，15-2MOUNT STANDBY DATABASE 句，15-3OPEN READ ONLY 句，15-3OPEN RESETLOGS 句，3-8，8-17PREPARE TO SWITCHOVER 句，7-14，7-15，15-3RECOVER MANAGED STANDBY DATABASE 句，

3-12，4-8，6-4，8-6，12-16，12-40，15-3REDO 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-5REGISTER LOGICAL LOGFILE 句，12-19RENAME FILE 句，8-12，A-2

SET STANDBY DATABASE 句TO MAXIMIZE AVAILABILITY 句，15-3TO MAXIMIZE PERFORMANCE 句，7-6TO MAXIMIZE PROTECTION 句，15-3

START LOGICAL STANDBY APPLY 句，6-6，7-19，11-7，A-9

IMMEDIATE キーワード，6-6，9-15NEW PRIMARY キーワード，7-19SQL Apply の開始，4-8

STOP LOGICAL STANDBY APPLY 句，6-6，7-18，11-6，12-19，15-4

ALTER SESSION DISABLE GUARD 文

データベース・ガードのオーバーライド，9-17ALTER SESSION GUARD DISABLE

データベース・リンクを定義するためのデータベー

ス・ガードの無効化，7-18ALTER SESSION 文

GUARD ENABLE 句，15-4ALTER 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-12FORCE LOGGING 句，8-14

ALTERNATE 属性，14-4LOG_ARCHIVE_DEST_n 初期化パラメータ，A-4LOG_ARCHIVE_DEST_STATE_n 初期化パラメータ，

5-4ANALYZER プロセス，9-2APPLIED_SCN 列

V$LOGSTDBY_PROGRESS ビュー，12-18APPLIER プロセス，9-3AQ_TM_PROCESSES 動的パラメータ，A-6ARCHIVE LOG CURRENT 句

ALTER SYSTEM の，3-12，3-13，12-21，12-22，12-23，12-24，12-31，12-42

ARCHIVELOG モード

ソフトウェア要件，2-6ARCH 属性，14-6

LOG_ARCHIVE_DEST_n 初期化パラメータデータ保護の設定，5-21

ARCn プロセス「アーカイバ・プロセス（ARCn）」を参照

ASM「自動ストレージ管理（ASM）」を参照

Asynchronous AutoLog，5-3ASYNC 属性，14-23

LOG_ARCHIVE_DEST_n 初期化パラメータ

データ保護の設定，5-21

索引索引索引索引 -1

BBACKUP INCREMENTAL FROM SCN コマンド

使用例，12-34BFILE データ型

ロジカル・スタンバイ・データベース，C-2BINARY_DEGREE データ型

ロジカル・スタンバイ・データベース，C-2BINARY_FLOAT データ型

ロジカル・スタンバイ・データベース，C-2BLOB データ型

ロジカル・スタンバイ・データベース，C-2BUILDER プロセス，9-2

CCANCEL オプション

管理リカバリと，8-3CHAR データ型

ロジカル・スタンバイ・データベース，C-2CJQ0 プロセス，A-6CLEAR UNARCHIVED LOGFILES 句

ALTER DATABASE の，8-7，8-17CLOB データ型

ロジカル・スタンバイ・データベース，C-2COMMIT TO SWITCHOVER TO PRIMARY 句

ALTER DATABASE の，7-16COMMIT 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，11-10

Contextサポートされないデータ型，C-2

Context データ型ロジカル・スタンバイ・データベース，C-2

CONTROL_FILE_RECORD_KEEP_TIME 初期化パラ

メータ，5-26COORDINATOR プロセス，9-2

LSP バックグラウンド・プロセス，9-2CREATE CONTROLFILE 句

ALTER DATABASE の，8-16CREATE DATABASE 文

FORCE LOGGING 句，12-43CREATE DATAFILE AS 句

ALTER DATABASE の，A-2CREATE RESTORE POINT コマンド，12-31CREATE RESTORE POINT 文

クローン・データベースのアクティブ化，12-31CREATE STANDBY CONTROLFILE 句

ALTER DATABASE の，3-8，15-2，A-3CREATE TABLE AS SELECT（CTAS）文

ロジカル・スタンバイ・データベースで適用，9-5

DData Guard Broker

カスケードされた宛先，E-2スイッチオーバー，7-1定義，1-6ファスト・スタート・フェイルオーバー，1-6フェイルオーバー，1-6

手動，1-6，7-1ファスト・スタート，7-1

分散管理フレームワーク，7-1Data Guard 構成

Oracle Database ソフトウェアのアップグレード，B-1REDO 転送サービス，5-2アーカイブ・プロセスを使用したスタンバイ宛先への

アーカイブ，5-5定義，1-2保護モード，1-8ログ・ライター・プロセスを使用したスタンバイ宛先

へのアーカイブ，5-12，6-3Data Pump ユーティリティ

フィジカル・スタンバイ・データベースでのトランス

ポータブル表領域の使用，8-12DATE データ型

ロジカル・スタンバイ・データベース，C-2DB_FILE_NAME_CONVERT オプション

Recovery Manager の DUPLICATE コマンド，F-5DB_FILE_NAME_CONVERT 初期化パラメータ

トランスポータブル表領域の位置，8-12DB_NAME 初期化パラメータ，3-6DB_RECOVERY_FILE_DEST_SIZE 初期化パラメータ

クローン・データベース用の設定，12-31DB_RECOVERY_FILE_DEST 初期化パラメータ

クローン・データベース用の設定，12-31リカバリ領域の設定，5-6

DB_ROLE_CHANGE システム・イベント，7-5，7-7DB_UNIQUE_NAME 初期化パラメータ，A-7

LOG_ARCHIVE_CONFIG パラメータとともに必須，13-3

共有フラッシュ・リカバリ領域に必須，5-8データベース初期化パラメータの設定，3-5

DB_UNIQUE_NAME 属性，14-7DBA_DATA_FILES ビュー，8-16DBA_LOGMNR_PURGED_LOG ビュー

削除できるアーカイブ REDO ログ・ファイルのリスト，9-14

DBA_LOGSTDBY_EVENTS ビュー，9-5，16-1，A-9ロジカル・スタンバイの取得，11-3

DBA_LOGSTDBY_HISTORY ビュー，16-1DBA_LOGSTDBY_LOG ビュー，9-6，16-1

アーカイブ REDO ログ・ファイルのリスト，12-18ロジカル・スタンバイ・データベースでのギャップの

検出，5-31DBA_LOGSTDBY_NOT_UNIQUE ビュー，16-1DBA_LOGSTDBY_PARAMETERS ビュー，16-1DBA_LOGSTDBY_SKIP_TRANSACTION ビュー，16-1DBA_LOGSTDBY_SKIP ビュー，16-1

スキーマに対する SQL Apply サポートの判断，C-4DBA_LOGSTDBY_UNSUPPORTED ビュー，16-1，C-4DBA_TABLESPACES ビュー，8-16DBMS_ALERT，C-3DBMS_AQ，C-3DBMS_DESCRIBE，C-3


DBMS_JAVA，C-3DBMS_JOB，C-3DBMS_LOB，C-3DBMS_LOGSTDBY.APPLY_SET プロシージャ

アーカイブ REDO ログ・ファイルの適用遅延，6-4DBMS_LOGSTDBY.BUILD サブプログラム

フラッシュバック問合せの使用，4-6DBMS_LOGSTDBY.BUILD プロシージャ

REDO データでのディクショナリの構築，4-6DBMS_LOGSTDBY パッケージ

INSTANTIATE_TABLE プロシージャ，9-19SKIP_ERROR プロシージャ，A-4SKIP_TRANSACTION プロシージャ，A-9SKIP プロシージャ，A-9

DBMS_LOGSTDBY プロシージャDBA_LOGSTDBY_EVENTS 表内のイベントの取得，

11-3DBMS_METADATA，C-3DBMS_OBFUSCATION_TOOLKIT，C-3DBMS_OUTPUT，C-3DBMS_PIPE，C-3DBMS_RANDOM，C-3DBMS_REDEFINITION，C-3DBMS_REFRESH，C-3DBMS_REGISTRY，C-3DBMS_SCHEDULER，C-3DBMS_SPACE_ADMIN，C-3DBMS_SQL，C-3DBMS_TRACE，C-3DBMS_TRANSACTION，C-3DBSNMP プロセス，A-6DDL トランザクション

ロジカル・スタンバイ・データベースで適用，9-5ロジカル・スタンバイ・データベースへの適用，9-5

DDL 文

SQL Apply によるサポート，C-1DEFER 属性

LOG_ARCHIVE_DEST_STATE_n 初期化パラメータ，5-4，12-42

DELAY オプションALTER DATABASE RECOVER MANAGED

STANDBY DATABASE の取消し，6-4DELAY 属性，14-8

LOG_ARCHIVE_DEST_n 初期化パラメータ，6-4，12-39

DEPENDENCY 属性，14-10LOG_ARCHIVE_DEST_n 初期化パラメータ，5-27

DG_CONFIG 属性，14-7LOG_ARCHIVE_CONFIG 初期化パラメータ，5-21

DGMGRL コマンドライン・インタフェース

スイッチオーバーの単純化，1-6，7-1フェイルオーバーの起動，1-6，7-1

DISCONNECT FROM SESSION，8-2DML

ロジカル・スタンバイ・データベースでのバッチ更新，9-4

DML トランザクションロジカル・スタンバイ・データベースへの適用，9-4

DROP STANDBY LOGFILE MEMBER 句

ALTER DATABASE の，15-2，A-2DROP STANDBY LOGFILE 句

ALTER DATABASE の，A-2

EENABLE 属性

LOG_ARCHIVE_DEST_STATE_n 初期化パラメータ，5-4，12-42

FFAL_CLIENT 初期化パラメータ，5-29FAL_SERVER 初期化パラメータ，5-29FORCE LOGGING 句

ALTER DATABASE の，2-6，3-2，12-43，15-2ALTER TABLESPACE の，8-14CREATE DATABASE の，12-43

FORCE キーワードRECOVER MANAGED STANDBY DATABASE

FINISH，7-11

GGUARD DISABLE 句

ALTER SESSION，7-18GUARD ENABLE 句

ALTER SESSION，15-4GV$INSTANCE ビュー，D-7GV$ 固定ビュー，8-17「ビュー」も参照

IImage データ型

ロジカル・スタンバイ・データベース，C-2INITIALIZING 状態，9-11INSTANTIATE_TABLE プロシージャ

DBMS_LOGSTDBY の，9-19INTERVAL データ型

ロジカル・スタンバイ・データベース，C-2

JJOB_QUEUE_PROCESSES 動的パラメータ，A-6

LLGWR 属性，14-6

LOG_ARCHIVE_DEST_n 初期化パラメータデータ保護の設定，5-21

非同期 REDO 転送，5-13，14-6，14-23LGWR プロセス「ログ・ライター・プロセス（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


LOG_ARCHIVE_CONFIG 初期化パラメータ，3-5，3-6，3-9，5-17，13-3

DB_UNIQUE_NAME パラメータとの関係，13-3DG_CONFIG 属性，5-21DG_CONFIG 属性との関係，14-7定義済の一意のデータベース名のリスト表示，16-2例，14-7

LOG_ARCHIVE_DEST_10 初期化パラメータデフォルトのフラッシュ・リカバリ領域，5-6，5-7，

14-12LOG_ARCHIVE_DEST_n 初期化パラメータ，5-11

AFFIRM 属性，5-21，14-2ALTERNATE 属性，14-4，A-4ARCH 属性，5-21，14-6ASYNC 属性，14-23

データ保護の設定，5-21DB_UNIQUE_NAME 属性，14-7DELAY 属性，6-4，12-39，14-8DEPENDENCY 属性，5-27，14-10LGWR 属性，14-6

データ保護の設定，5-21LOCATION 属性，14-12，A-4MANDATORY 属性，14-14MAX_CONNECTIONS 属性，14-16MAX_FAILURE 属性，14-17NET_TIMEOUT 属性，14-19NOAFFIRM 属性，14-2NOALTERNATE 属性，A-4NODELAY 属性，6-4NOREGISTER 属性，14-21NOREOPEN 属性，5-18OPTIONAL 属性，14-14QUOTA_SIZE 属性，D-5REGISTER 属性，14-21REOPEN 属性，5-18，14-22SERVICE 属性，14-12SYNC 属性，14-23

データ保護の設定，5-21TEMPLATE 属性，14-24VALID_FOR 属性，5-16，14-26VERIFY 属性，14-28概要，5-4廃止になった属性，14-1リカバリ領域の設定，5-6

LOG_ARCHIVE_DEST_STATE_n 初期化パラメータ，5-4

ALTERNATE 属性，5-4DEFER 属性，5-4，12-42ENABLE 属性，5-4，12-42RESET 属性，5-4

LOG_ARCHIVE_FORMAT 初期化パラメータ，5-23LOG_ARCHIVE_MIN_SUCCEED_DEST 初期化パラ

メータ，14-14LOG_ARCHIVE_TRACE 初期化パラメータ，5-33，G-2，

G-3LogMiner ディクショナリ

DBMS_LOGSTDBY.BUILD プロシージャを使用した構築，4-6

ロジカル・スタンバイ・データベースの作成時，4-6LONG RAW データ型

ロジカル・スタンバイ・データベース，C-2LONG データ型


MMANDATORY 属性，14-14

LOG_ARCHIVE_DEST_n 初期化パラメータ，5-24MAX_CONNECTIONS 属性，14-16MAX_FAILURE 属性，14-17MOUNT STANDBY DATABASE 句

ALTER DATABASE の，15-3MRP「管理リカバリ・プロセス」を参照

NNCHAR データ型

ロジカル・スタンバイ・データベース，C-2CLOB データ型

ロジカル・スタンバイ・データベース，C-2NET_TIMEOUT 属性，14-19

LGWR ASYNC 宛先の場合は無視，5-14NEWEST_SCN 列

V$LOGSTDBY_PROGRESS ビュー，12-18NOAFFIRM 属性，14-2NOALTERNATE 属性

LOG_ARCHIVE_DEST_n 初期化パラメータ，A-4NODELAY オプション

REDO Apply 操作，12-41NODELAY 属性

LOG_ARCHIVE_DEST_n 初期化パラメータ，6-4NOREGISTER 属性，14-21NOREOPEN 属性

LOG_ARCHIVE_DEST_n 初期化パラメータ，5-18NUMBER データ型

ロジカル・スタンバイ・データベース，C-2NVARCHAR2 データ型


OOMF「Oracle Managed Files（OMF）」を参照

OPEN READ ONLY 句

ALTER DATABASE の，15-3OPEN RESETLOGS

後のフラッシュバック，12-28OPEN RESETLOGS 句

ALTER DATABASE の，3-8，8-17データベース・インカネーションの変更，8-15リカバリ，8-15

Optimal Flexible Architecture（OFA）

ディレクトリ構造，2-7OPTIONAL 属性，14-14

LOG_ARCHIVE_DEST_n 初期化パラメータ，5-24ORA-01102 メッセージ

スイッチオーバー障害の原因となる，A-7Oracle Advanced Security

セキュアな REDO の転送の提供，5-15Oracle Automatic Storage Management（ASM），2-7Oracle Change Data Capture のアーカイブ，5-3Oracle Database

SQL Apply を使用したアップグレード，11-2SQL Apply を使用したアップグレードの要件，11-2アップグレード，2-6，B-2

Oracle Database Enterprise Editionソフトウェア要件，2-6


Oracle Enterprise Managerスイッチオーバーの起動，1-6，7-1フェイルオーバーの起動，1-6，7-1

Oracle Managed Files（OMF），2-7使用するスタンバイ・データベースの作成，12-51，

F-8，F-9Oracle Net

Data Guard 構成のデータベース間の通信，1-2Oracle Recovery Manager ユーティリティ（RMAN）

フィジカル・スタンバイ・データベースのバックアップ・ファイルの作成，10-1

Oracle Standard Editionスタンバイ・データベース環境の再現，2-6

Oracle Streamsアーカイブ，5-3ダウンストリーム取得データベース，5-3

PPARALLEL_MAX_SERVERS 初期化パラメータ

指定ロジカル・スタンバイ・データベースの作成，

8-25，13-4PARALLEL オプション

REDO Apply のログ適用レートのチューニング，8-25PL/SQL パッケージ

サポートされない，C-3サポートされる，C-3

PREPARE TO SWITCHOVER 句ALTER DATABASE の，7-14，7-15，15-3

PREPARER プロセス，9-2SGA 内での LCR のステージング，9-2

QQMN0 プロセス，A-6QUOTA_SIZE 属性

LOG_ARCHIVE_DEST_n 初期化パラメータ，D-5

RRAW データ型

ロジカル・スタンバイ・データベース，C-2RAW デバイス

スタンバイ REDO ログ・ファイルの常駐，2-10READER プロセス，9-2Real 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-4REDO Apply の制御，6-5スイッチオーバーの使用例，12-41遅延間隔の上書き，6-4，14-8バックグラウンド・プロセス，6-5，8-2フェイルオーバーの開始，7-11フォアグラウンド・セッション，6-5リアルタイム適用の開始，6-5

DELAY 制御オプションの取消し，6-4FORCE キーワード，7-11

RECOVER TO LOGICAL STANDBY 句

フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースへの変換，4-6

Recovery ManagerData Guard を補完する特性，1-10DUPLICATE コマンドの 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-9Recovery Manager およびスタンバイ・インスタ

ンスの起動，F-8Recovery Manager の準備，F-2イメージ・コピーを使用した作成，F-17作成，F-2，F-6スタンバイ制御ファイルの作成，F-3スタンバイ・データファイルのネーミング，F-4

増分バックアップ，12-34データファイルの小さいサブセットに対するロギ

ングなし変更適用時のデータベースのロール

フォワード，12-36ロギングなしの変更が広範囲にある場合のデータ

ベースのロールフォワード，12-38フィジカル・スタンバイ・データベースのロールフォ

ワード，12-34Recovery Manager の使用

イメージ・コピーの使用，F-17REDO 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-26読取り / 書込みテストとレポート生成，12-30ロールの推移とカスケードされた構成，E-5ログ適用レートのチューニング，8-25


REDO データ検証，1-10手動による転送，2-6スタンバイ・システムでのアーカイブ，1-4，6-2ディクショナリの構築，4-6適用

REDO Apply テクノロジの使用，1-4SQL 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-5Oracle Change Data Capture，5-3Oracle 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-11SYNC ネットワーク転送，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-23REDO ログ

Data Guard 構成内，2-9構成上の考慮事項，2-10スタンバイ・データベース表の更新，1-10セキュアな REDO の転送，5-15フィジカル・スタンバイ・データベースでの自動

適用，6-5REDO ログ・ファイル

適用の遅延，6-4REGISTER LOGFILE 句，5-30，5-31

ALTER DATABASE の，15-3，A-5欠落しているログ・ファイルの登録，5-30，5-31

REGISTER LOGICAL LOGFILE 句，12-20ALTER DATABASE の，5-31，7-17，12-19

REGISTER 属性，14-21RELY 制約

作成，4-3REMOTE_LOGIN_PASSWORDFILE 初期化パラメータ

セキュアな REDO の転送，5-15RENAME FILE 句

ALTER DATABASE の，A-2REOPEN 属性，14-22

LOG_ARCHIVE_DEST_n 初期化パラメータ，5-18RESETLOGS_ID 列

V$DATABASE_INCARNATION ビューでの表示，

8-19RESET 属性

LOG_ARCHIVE_DEST_STATE_n 初期化パラメータ，

5-4RFS「リモート・ファイル・サーバー・プロセス（RFS）」

を参照

RMAN BACKUP INCREMENTAL FROM SCN コマンド，12-34

ROWID データ型ロジカル・スタンバイ・データベース，C-2

SSCN

増分バックアップに使用，12-34適用可能な大の（新の）判断，12-17

SERVICE 属性，14-12SET STANDBY DATABASE 句

ALTER DATABASE の，7-6，15-3ALTER DATA の，15-3

SKIP_ERROR プロシージャ

DBMS_LOGSTDBY パッケージ，A-4SKIP_TRANSACTION プロシージャ

DBMS_LOGSTDBY の，A-9SKIP プロシージャ

DBMS_LOGSTDBY の，A-9Spatial データ型

ロジカル・スタンバイ・データベース，C-2SQL Apply，6-6，9-4

ANALYZER プロセス，9-2APPLIER プロセス，9-3BUILDER プロセス，9-2COORDINATOR プロセス，9-2CREATE TABLE AS SELECT（CTAS）文の適用，9-5DDL トランザクションの適用，9-5DDL 文のサポート，C-1DML トランザクションの適用，9-4OPEN RESETLOGS の後，9-22PL/SQL パッケージのサポート，C-3PREPARER プロセス，9-2READER プロセス，9-2アーカイブ REDO ログ・ファイルの削除，9-14アーキテクチャ，9-2，9-11開始

リアルタイム適用，6-6記憶域型のサポート，C-3現行のアクティビティの表示，9-3

プロセス，9-3


再開の考慮事項，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-30SQL セッション

スイッチオーバー障害の原因となる，A-5SQL 文

スイッチオーバーと，7-8ロジカル・スタンバイ・データベースでの実行，1-2，

1-5ロジカル・スタンバイ・データベースでのスキップ，

C-5STANDBY_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-9IMMEDIATE キーワード，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-23LOG_ARCHIVE_DEST_n 初期化パラメータ，5-11

データ保護の設定，5-21SYS ユーザー・アカウント

REMOTE_LOGIN_PASSWORDFILE 初期化パラ

メータ，5-15パスワード・ファイルの要件，5-15

TTEMPLATE 属性，14-24TIMESTAMP データ型

ロジカル・スタンバイ・データベース，C-2tnsnames.ora ファイル

REDO 転送サービス調整，A-10トラブルシューティング，12-42，A-3，A-8，A-10

UUNDO_RETENTION 初期化パラメータ

推奨，4-6UROWID データ型

ロジカル・スタンバイ・データベース，C-2USER_DUMP_DEST 初期化パラメータ，G-2USING CURRENT LOGFILE 句，8-6

リアルタイム適用の開始，6-5

VV$ARCHIVE_DEST_STATUS ビュー，5-32，8-23，16-2

ログ適用サービスと MANAGED REAL TIME 列，

8-23V$ARCHIVE_DEST ビュー，5-32，12-42，16-1，A-3

STANDBY_ARCHIVE_DEST パラメータの暗黙的なデフォルト値の表示，5-23

すべての宛先の情報の表示，16-2V$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-32V$DATABASE_INCARNATION ビュー，16-2

データベース・インカネーション情報の取得，8-19V$DATABASE ビュー，16-2

SWITCHOVER_STATUS 列と，7-7，7-8，A-5スイッチオーバーと，7-7，7-8ファスト・スタート・フェイルオーバーの監視，8-16

V$DATAFILE ビュー，12-44，12-45，16-2V$DATAGUARD_CONFIG ビュー，16-2

LOG_ARCHIVE_CONFIG で定義済のデータベース名のリスト表示，16-2

V$DATAGUARD_STATS ビュー，16-2V$DATAGUARD_STATUS ビュー，8-24，16-2V$LOG_HISTORY ビュー，8-20，8-23，16-2V$LOGFILE ビュー，16-2V$LOGSTDBY_PROCESS ビュー，9-3，9-7，9-8，9-12，

9-24，9-25，16-2，16-3V$LOGSTDBY_PROGRESS ビュー，9-8，16-2

RESTART_SCN 列，9-4SCN 情報の問合せと，12-18

V$LOGSTDBY_STATE ビュー，7-3，9-9，9-11，16-3V$LOGSTDBY_STATS ビュー，9-3，9-10，16-3

フェイルオーバー特性，9-7V$LOGSTDBY_TRANSACTION ビュー，16-3V$LOGSTDBY ビュー，xxviiiV$LOG ビュー，5-32，16-2V$MANAGED_STANDBY ビュー，8-22，16-3V$RECOVER_FILE ビュー，8-16V$SESSION ビュー，A-6，A-7V$STANDBY_LOG ビュー，7-20，16-3V$THREAD ビュー，8-16VALID_FOR 属性，14-26

値とロールベースの条件，14-27概要，5-16確認，12-9例，5-16


VARCHAR2 データ型ロジカル・スタンバイ・データベース，C-2

VARCHAR データ型

ロジカル・スタンバイ・データベース，C-2VERIFY 属性，14-28

WWAITING FOR DICTIONARY LOGS 状態，9-11

XXML 型データ型


ああああアーカイバ・プロセス（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-18V$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-4SQL 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-31V$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-2Oracle Database ソフトウェア，2-6，11-2Oracle Database ソフトウェア・バージョン，11-2要件，11-2

宛先

Oracle Change Data Capture のアーカイブ，5-3Oracle Streams のアーカイブ，5-3V$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


おおおおオフサイトでの REDO データのアーカイブ，5-3オペレーティング・システム

Data Guard 構成の要件，2-5オンライン REDO ログ・ファイル

アーカイブ・ギャップ管理，5-28削除，8-14追加，8-14

かかかか解決

論理的な破損，1-10開始

REDO Apply，3-12，6-5，8-2SQL 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-5SQL Apply，E-5

ロジカル・スタンバイ・データベース，E-4ロジカル・スタンバイ・データベースでのマテリアラ

イズド・ビュー，E-7監視

REDO 転送サービス，5-32スタンバイ・データベース，8-7表領域の状態，8-16プライマリ・データベース・イベント，8-16ログ適用サービス，8-23

管理リカバリ操作

「REDO Apply」を参照管理リカバリ・プロセス（MRP）

ARCn アーカイブ・プロセス，5-10LGWR 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-32リストア・ポイントの作成，12-31

グローバル動的パフォーマンス・ビュー，8-17「ビュー」も参照

クローン・データベース

ACTIVATE STANDBY DATABASE 句，12-32DB_RECOVERY_FILE_DEST_SIZE 初期化パラ

メータ，12-31DB_RECOVERY_FILE_DEST 初期化パラメータ，

12-31アクティブ化，12-32フィジカル・スタンバイ・データベースの

アクティブ化，12-30フィジカル・スタンバイ・データベースの変換，

12-30リストア・ポイントの作成，12-31

クローン・データベースのアクティブ化，12-32


けけけけ欠落しているログ順序番号

「ギャップ管理」も参照検出，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-1RAC および 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-6REDO ログ，2-10一般的な，1-3概要，1-2スタンバイ・データベース

アーカイブ REDO ログ・リポジトリ，5-3遅延されたアーカイブ REDO ログ・ファイルの

適用，12-39遅延スタンバイ，6-4

パスワード・ファイルの要件，5-15フィジカル・スタンバイ・データベース

位置とディレクトリ構造，2-7固定ビュー「ビュー」を参照

コピー制御ファイル，3-11

コマンド、Recovery ManagerDUPLICATE，F-2

コマンドライン・インタフェースブローカ，1-11

コレクション・データ型


ささささ再開の考慮事項

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


サポートされない 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-26DB_FILE_NAME_CONVERT，F-5DB_UNIQUE_NAME，3-5，A-7FAL_CLIENT，5-29FAL_SERVER，5-29LOG_ARCHIVE_DEST，12-50LOG_ARCHIVE_DEST_STATE_n，5-4LOG_ARCHIVE_FORMAT，5-23LOG_ARCHIVE_MIN_SUCCEED_DEST，14-14LOG_ARCHIVE_TRACE，5-33，G-2，G-3LOG_FILE_NAME_CONVERT，F-5STANDBY_ARCHIVE_DEST，5-23USER_DUMP_DEST，G-2フィジカル・スタンバイ・データベース用に変更，

3-9プライマリ・ロールおよびスタンバイ・ロールの

設定，14-26初期化パラメータ・ファイル

サーバー・パラメータ・ファイルから作成

フィジカル・スタンバイ・データベース用，3-9変更

フィジカル・スタンバイ・データベース用，3-9

すすすすスイッチオーバー，1-5

Data Guard Broker での単純化，1-6，7-1DBA_LOGSTDBY_HISTORY に履歴を表示，16-1ORA-01102 による失敗，A-7Real Application Clusters の使用と，D-6SQL 文と，7-8V$DATABASE ビューと，7-7，7-8後の DB_ROLE_CHANGE システム・イベントの

使用，7-5後のデータベースのフラッシュバック，7-21確認，7-8カスケードされた構成，E-5

REDO Apply，E-5SQL Apply，E-5

監視，8-16関与しないスタンバイ・データベース，7-9

後のアーカイブ REDO ログ・ファイルが転送され

たかどうかの確認，A-5初からやり直し，A-8

妨げの原因

CJQ0 プロセス，A-6DBSNMP プロセス，A-6QMN0 プロセス，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


スキーマSQL Apply でスキップ，C-4スキップ対象を示す DBA_LOGSTDBY_SKIP リスト，

C-4プライマリ・データベースと同一，1-2ロジカル・スタンバイ・データベースでのデータ

操作，1-10スタンバイ REDO ログ・グループ

十分かどうかの判断，5-25推奨数，3-3メンバーの追加，5-25

スタンバイ REDO ログ・ファイルRAW デバイス上，2-10Real 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-5LOG_FILE_NAME_CONVERT 初期化パラメータ，

F-5NETWORK_TIMEOUT 属性の設定，5-14OMF ファイルを使用するためのセットアップ，F-8，

F-9OPEN RESETLOGS を使用したリカバリ，8-15Recovery Manager およびスタンバイ・インスタンス

の起動，F-8Recovery Manager の準備，F-2Recovery Manager の増分バックアップによるロール

フォワード，12-34Recovery Manager を使用した作成について，F-2Recovery Manager を使用したデータファイルのネー

ミング，F-4REDO データの適用，6-1REDO ログ・ファイルの適用，1-4，1-10RESETLOGS_ID の表示，8-19SET AUXNAME コマンド，F-5SET 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-17Recovery Manager の使用，F-6タイム・ラグのある，6-4，12-40タスクのチェックリスト，4-4ディレクトリ構造の考慮点，2-7プライマリが ASM または OMF を使用する場合，

12-51リモート・ホスト上で異なるディレクトリ構造，

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


そそそそ属性

LOG_ARCHIVE_DEST_n 初期化パラメータについて廃止，14-1

ソフトウェア要件，2-6Oracle 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-6SQL 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-7OMF を使用したセットアップ，2-7Optimal Flexible Architecture（OFA），2-7スタンバイ・データベースの構造，2-7

データ型BFILE，C-2BINARY_DEGREE，C-2BINARY_FLOAT，C-2BLOB，C-2CHAR，C-2CLOB，C-2DATE，C-2INTERVAL，C-2LONG，C-2LONG RAW，C-2NCHAR，C-2NCLOB，C-2NUMBER，C-2NVARCHAR2，C-2RAW，C-2ROWID，C-2Spatial、Image および Context，C-2TIMESTAMP，C-2UROWID，C-2VARCHAR，C-2VARCHAR2，C-2


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-23

ネットワーク接続への影響，14-19ネットワーク・タイムアウトへの影響，14-19

テキスト索引

ロジカル・スタンバイ・データベースでサポートされる，C-2

適用REDO データの即時，6-3SQL 文をロジカル・スタンバイ・データベースに，

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-6JOB_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-10SQL Apply，A-9SQL Apply が停止した場合，A-9tnsnames.ora ファイル，12-42，A-3，A-8，A-10

後の REDO データが転送されていない，A-5スイッチオーバー，A-5

ORA-01102 メッセージ，A-7アクティブな SQL セッション，A-5アクティブなユーザー・セッション，A-7ロールバックおよび初からやり直し，A-8

スイッチオーバーを妨げるプロセス，A-6ロジカル・スタンバイ・データベース障害，A-4

トランザクション・サイズの考慮事項SQL Apply，9-3

トランスポータブル表領域DB_FILE_NAME_CONVERT パラメータで位置を

定義，8-12STANDBY_FILE_MANAGEMENT パラメータの

設定，8-12フィジカル・スタンバイ・データベースでの使用，

8-12トリガー

ロジカル・スタンバイ・データベースでの処理，9-21取消し

ログ適用サービス，8-6トレース・ファイル

位置，G-2設定，G-2データのトレース・レベル，G-3リアルタイム適用の追跡，G-3


にににに認証

REDO データの送信，5-15SYS 資格証明を使用したチェック，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-9DBA_LOGSTDBY_HISTORY，16-1DBA_LOGSTDBY_LOG，9-6，12-18，16-1DBA_LOGSTDBY_NOT_UNIQUE，16-1DBA_LOGSTDBY_PARAMETERS，16-1DBA_LOGSTDBY_SKIP，16-1DBA_LOGSTDBY_SKIP_TRANSACTION，16-1DBA_LOGSTDBY_UNSUPPORTED，16-1，C-4DBA_TABLESPACES，8-16GV$INSTANCE，D-7V$ARCHIVE_DEST，5-32，12-42，16-1，A-3V$ARCHIVE_DEST_STATUS，5-32，8-23，16-2V$ARCHIVE_GAP，16-2V$ARCHIVED_LOG，5-24，5-32，8-23，12-48，16-2V$DATABASE，16-2V$DATABASE_INCARNATION，16-2V$DATAFILE，12-44，12-45，16-2V$DATAGUARD_CONFIG，16-2V$DATAGUARD_STATS，16-2V$DATAGUARD_STATUS，8-24，16-2V$LOG，5-32，16-2V$LOG_HISTORY，8-20，8-23，16-2V$LOGFILE，16-2V$LOGSTDBY，xxviiiV$LOGSTDBY_PROCESS，9-3，9-7，16-2V$LOGSTDBY_PROGRESS，9-8，16-2V$LOGSTDBY_STATE，9-9，16-3V$LOGSTDBY_STATS，9-3，9-10，16-3V$LOGSTDBY_TRANSACTION，16-3V$MANAGED_STANDBY，8-22，16-3V$RECOVER_FILE，8-16V$SESSION，A-6，A-7V$STANDBY_LOG，3-4，7-20，16-3V$THREAD，8-16スイッチオーバーおよびフェイルオーバーの履歴の

表示，16-1


表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-3DML のサポート，2-3OPEN RESETLOGS を使用したリカバリ，8-15REDO Apply，1-4，2-2REDO データの適用，6-2，6-5

REDO Apply テクノロジ，6-5カスケード，E-1

REDO のプライマリ・データベース・ブランチとの再同期化，8-15

REDO ログ・ファイルの適用開始，6-5

V$ARCHIVE_GAP ビューでのギャップの検出，5-30VALID_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-5Data Guard Broker，1-6，7-1Data Guard Broker での単純化，7-1DBA_LOGSTDBY_HISTORY に履歴を表示，16-1FINISH FORCE，7-11REDO データの事前転送，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，

12-17ロジカル・スタンバイ・データベースの特性の表示，

9-7不適切なネットワーク障害検出，14-19部分的なアーカイブ REDO ログ・ファイル

登録，12-20プライマリ・データベース

ARCHIVELOG モード，2-6Real Application Clusters

設定，D-3，D-4REDO 転送サービス，1-4REDO ログ・アーカイブ情報の収集，5-32アーカイブ・トレースの設定，5-33イベントの監視，8-16ギャップの解決，1-11欠落しているログ・ファイルの V$ARCHIVED_LOG

ビューによる検出，5-30


構成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-9OPEN 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-6DBSNMP，A-6QMN0，A-6SQL 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-31DB_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


めめめめメディア・リカバリ

パラレル，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-2SQL Apply，9-15V$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-25REDO データの適用遅延，6-4，12-39，14-8SQL Apply

開始，6-6監視，6-7定義，1-4，6-2停止，6-6


定義，1-4，6-2リアルタイム適用

LOG_ARCHIVE_TRACE による監視，G-3V$ARCHIVE_DEST_STATUS ビューで監視，8-23スタンバイ REDO ログ・ファイル，2-9定義，6-2，6-3

ログ・ライター・プロセス（LGWR）ASYNC ネットワーク転送，5-11，14-23NET_TIMEOUT 属性，14-19SYNC ネットワーク転送，14-23定義，5-11ネットワーク・タイムアウト後の再接続，14-19ローカルのアーカイブ，5-4

ロジカル・スタンバイ・データベース，1-2SQL Apply，1-5

DBMS_LOGSTDBY.APPLY_SET プロシージャ，

6-4DDL 文のスキップ，C-5REDO のプライマリ・データベース・ブランチと

の再同期化，9-22SQL 文のスキップ，C-5遅延，6-4停止，6-6テクノロジ，6-2トランザクション・サイズの考慮事項，9-3リアルタイム適用の開始，6-6，9-15

SQL 文の実行，1-2UNDO_RETENTION 初期化パラメータ，4-6VALID_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-17V$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-10COORDINATOR プロセス，9-2LGWR SYNC アーカイブ・プロセス，5-12

論理的な破損解決，1-10

論理変更レコード（LCR）PREPARER プロセスによる変換，9-2ステージング，9-2全体が使用済のキャッシュ・メモリー，9-4



Documents

Oracle® Data Guardotndnld.oracle.co.jp/document/products/oracle10g/102/doc...Oracle Data Guard 概要および管理, 10g リリース2（10.2） 部品番号: B19233-03 Oracle Data

Oracle® Data Guardotndnld.oracle.co.jp/document/products/oracle10g/102/doc...Oracle Data Guard 概要および管理, 10g リリース2（10.2）部品番号: B19233-03 Oracle Data