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

Oracle® Data Guard
概要および管理
10g リリース 1（10.1）
部品番号 : B12480-01
2004 年 1 月
このマニュアルでは、企業データの高可用性、データ保
護および障害時リカバリを保証するスタンバイ・データ
ベースの実装および管理のための Oracle Data Guard の
概要について説明します。
Oracle Data Guard 概要および管理 , 10g リリース 1（10.1）
部品番号 : B12480-01
原本名 : Oracle Data Guard Concepts and Administration, 10g Release 1 (10.1)
原本部品番号 : B10823-01
原本著者 : Viv Schupmann
原本協力者 : Lance Ashdown, Rick Anderson, Cathy Baird, Tammy Bednar, Anand Beldalker, Barbara
Benton, Lucy Burgess, Larry Carpenter, Wei Chen, Laurence Clarke, Rhonda Day, Jeff Detjen, Ray
Dutcher, Chuck Freiwald, Mahesh Girkar, Roshan Gupta, Ray Guzman, Susan Hillson, Mark Johnson,
Sadhana Kyathappala, Steve Lee, Steve McGee, Bob McGuirk, Jeff Nesheiwat, Muthu Olagappan,
Deborah Owens, Ashish Ray, Charles Sondey, Ingrid Stuart, Lawrence To, Mike Smith, Randy Urbano,
Ric Van Dyke, Lik Wong
Copyright © 1999, 2003 Oracle Corporation. 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 Corporation, 500 Oracle Parkway, Redwood
City, CA 94065.
このプログラムは、核、航空産業、大量輸送、医療あるいはその他の危険が伴うアプリケーションへの
用途を目的としておりません。このプログラムをかかる目的で使用する際、上述のアプリケーションを
安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）
、その他の対策を講じ
ることは使用者の責任となります。万一かかるプログラムの使用に起因して損害が発生いたしましても、
オラクル社およびその関連会社は一切責任を負いかねます。
Oracle は Oracle Corporation およびその関連会社の登録商標です。その他の名称は、Oracle
Corporation または各社が所有する商標または登録商標です。
目次
例
図
表
はじめに .........................................................................................................................................................................
xix
対象読者 .................................................................................................................................................................... xx
このマニュアルの構成 ............................................................................................................................................ xx
関連ドキュメント ................................................................................................................................................. xxiii
表記規則 ................................................................................................................................................................. xxiv
Oracle Data Guard の新機能 ......................................................................................................................
xxvii
フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースに共通の
新機能 ................................................................................................................................................................... xxviii
フィジカル・スタンバイ・データベース固有の新機能 ................................................................................. xxxi
ロジカル・スタンバイ・データベース固有の新機能 .................................................................................... xxxii
第 I 部 概要および管理
1
Oracle Data Guard の概要
Data Guard 構成 .................................................................................................................................................... 1-2
プライマリ・データベース ........................................................................................................................... 1-2
スタンバイ・データベース ........................................................................................................................... 1-2
構成例 ............................................................................................................................................................... 1-3
Data Guard サービス ............................................................................................................................................ 1-4
ログ転送サービス ........................................................................................................................................... 1-4
ログ適用サービス ........................................................................................................................................... 1-5
ロール管理サービス ....................................................................................................................................... 1-6
i
Data Guard Broker ................................................................................................................................................ 1-7
Oracle Enterprise Manager の使用 .............................................................................................................. 1-7
Data Guard コマンドライン・インタフェースの使用 ............................................................................. 1-9
Data Guard 保護モード ........................................................................................................................................ 1-9
Data Guard と補完テクノロジ .......................................................................................................................... 1-10
Data Guard のメリットの要約 .......................................................................................................................... 1-12
2
Data Guard スタート・ガイド
スタンバイ・データベースのタイプ ................................................................................................................... 2-2
フィジカル・スタンバイ・データベース ................................................................................................... 2-2
ロジカル・スタンバイ・データベース ....................................................................................................... 2-4
Data Guard 構成の管理のためのユーザー・インタフェース ........................................................................ 2-5
Data Guard の動作要件 ........................................................................................................................................ 2-6
ハードウェアおよびオペレーティング・システムの要件 ....................................................................... 2-6
Oracle ソフトウェア要件 .............................................................................................................................. 2-7
スタンバイ・データベースのディレクトリ構造に関する考慮事項 ............................................................... 2-9
オンライン REDO ログ、アーカイブ REDO ログおよびスタンバイ REDO ログ ................................... 2-12
オンライン REDO ログおよびアーカイブ REDO ログ .......................................................................... 2-12
スタンバイ REDO ログ ............................................................................................................................... 2-13
3
フィジカル・スタンバイ・データベースの作成
スタンバイ・データベースを作成するためのプライマリ・データベースの準備 ....................................... 3-2
強制ロギングの有効化 ................................................................................................................................... 3-3
パスワード・ファイルの作成 ....................................................................................................................... 3-3
プライマリ・データベースの初期化パラメータの設定 ........................................................................... 3-3
アーカイブの有効化 ....................................................................................................................................... 3-7
フィジカル・スタンバイ・データベースの作成 ............................................................................................... 3-8
プライマリ・データベース・データ・ファイルのバックアップ・コピーの作成 ............................... 3-8
スタンバイ・データベース用の制御ファイルの作成 ............................................................................... 3-9
スタンバイ・データベース用の初期化パラメータ・ファイルの準備 ................................................... 3-9
プライマリ・システムからスタンバイ・システムへのファイルのコピー ......................................... 3-13
スタンバイ・データベースをサポートする環境の設定 ......................................................................... 3-13
フィジカル・スタンバイ・データベースの起動 ..................................................................................... 3-15
フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認 ......................... 3-17
その他の準備 ......................................................................................................................................................... 3-19
ii
4
ロジカル・スタンバイ・データベースの作成
ロジカル・スタンバイ・データベースを作成するための準備 ....................................................................... 4-2
表のデータ型および記憶域属性のサポートの判別 ................................................................................... 4-2
プライマリ・データベース内の表の行が一意に識別できることの確認 ............................................... 4-6
ロジカル・スタンバイ・データベースの作成 ................................................................................................... 4-8
フィジカル・スタンバイ・データベースの作成 ....................................................................................... 4-8
ロジカル・スタンバイ・データベースをサポートするためのプライマリ・データベースの準備 ... 4-9
ロジカル・スタンバイ・データベースに推移するための準備 ............................................................. 4-12
ロジカル・スタンバイ・データベースの起動 ......................................................................................... 4-15
ロジカル・スタンバイ・データベースが正しく実行されているかどうかの確認 ............................. 4-19
その他の準備 ......................................................................................................................................................... 4-23
5
ログ転送サービス
ログ転送サービスの概要 ....................................................................................................................................... 5-2
REDO データの送信先 .......................................................................................................................................... 5-3
宛先タイプ ....................................................................................................................................................... 5-3
LOG_ARCHIVE_DEST_n パラメータを使用した宛先の構成 ................................................................ 5-4
フラッシュ・リカバリ領域を宛先とした設定 ........................................................................................... 5-7
REDO データの送信方法 .................................................................................................................................... 5-11
アーカイバ・プロセス（ARCn）を使用した REDO データのアーカイブ ........................................ 5-11
ログ・ライター・プロセス（LGWR）を使用した REDO データのアーカイブ ............................... 5-16
セキュアな REDO データの転送の提供 ................................................................................................... 5-22
REDO データの送信時間 .................................................................................................................................... 5-23
VALID_FOR 属性を使用したロール・ベースの宛先の指定 ................................................................. 5-23
一意のプライマリ・データベース名とスタンバイ・データベース名の指定 .................................... 5-24
エラーが発生した場合の対処方法 ..................................................................................................................... 5-26
データ保護モードの設定 ..................................................................................................................................... 5-27
データ保護モードの選択 ............................................................................................................................. 5-27
スタンバイ REDO ログ・ファイルの構成 ............................................................................................... 5-29
Data Guard 構成のデータ保護モードの設定 ........................................................................................... 5-31
ログ・ファイルの管理 ......................................................................................................................................... 5-34
アーカイブ REDO ログ・ファイルの代替ディレクトリ位置の指定 ................................................... 5-34
オンライン REDO ログ・ファイルの再利用 ........................................................................................... 5-36
スタンバイ REDO ログ・ファイルの管理 ............................................................................................... 5-36
iii
制御ファイルのサイズ拡大と再利用の計画 ............................................................................................. 5-38
複数のスタンバイ・データベース間でのログ・ファイル宛先の共有 ................................................. 5-39
アーカイブ・ギャップの管理 ............................................................................................................................. 5-40
アーカイブ・ギャップの検出時期 ............................................................................................................. 5-40
ギャップの解決方法 ..................................................................................................................................... 5-41
フェッチ・アーカイブ・ログ（FAL）プロセスを使用したアーカイブ・ギャップの解決 ............. 5-41
手動によるアーカイブ・ギャップの判断および解決 ............................................................................. 5-43
確認 ......................................................................................................................................................................... 5-45
ログ・ファイル・アーカイブ情報の監視 ................................................................................................. 5-45
ログ転送サービスのパフォーマンスの監視 ............................................................................................. 5-47
6
ログ適用サービス
ログ適用サービスの概要 ....................................................................................................................................... 6-2
ログ適用サービスの構成オプション ................................................................................................................... 6-3
リアルタイム適用による REDO データの即時適用 ................................................................................. 6-3
アーカイブ REDO ログ・ファイルの適用に対するタイム・ディレイの指定 ..................................... 6-5
REDO データのフィジカル・スタンバイ・データベースへの適用 .............................................................. 6-7
REDO Apply の開始 ...................................................................................................................................... 6-7
リアルタイム適用の開始 ............................................................................................................................... 6-8
ログ適用サービスの停止 ............................................................................................................................... 6-8
フィジカル・スタンバイ・データベースでのログ適用サービスの監視 ............................................... 6-8
REDO データのロジカル・スタンバイ・データベースへの適用 ................................................................ 6-12
SQL Apply の開始 ........................................................................................................................................ 6-12
リアルタイム適用の開始 ............................................................................................................................. 6-12
ロジカル・スタンバイ・データベースでのログ適用サービスの停止 ................................................. 6-12
ロジカル・スタンバイ・データベースに関するログ適用サービスの監視 ......................................... 6-13
フィジカル・スタンバイ・データベースに関するログ適用レートのチューニング ................................. 6-18
7
ロール管理
ロールの推移の概要 ............................................................................................................................................... 7-2
使用するロールの推移の選択 ....................................................................................................................... 7-3
スイッチオーバー ........................................................................................................................................... 7-5
フェイルオーバー ........................................................................................................................................... 7-9
iv
フィジカル・スタンバイ・データベースが関与するロールの推移 ............................................................. 7-12
フィジカル・スタンバイ・データベースが関与するスイッチオーバー ............................................. 7-12
フィジカル・スタンバイ・データベースが関与するフェイルオーバー ............................................. 7-15
ロジカル・スタンバイ・データベースが関与するロールの推移 ................................................................. 7-20
ロジカル・スタンバイ・データベースが関与するスイッチオーバー ................................................. 7-20
ロジカル・スタンバイ・データベースが関与するフェイルオーバー ................................................. 7-23
8
フィジカル・スタンバイ・データベースの管理
フィジカル・スタンバイ・データベースの起動と停止 ................................................................................... 8-2
フィジカル・スタンバイ・データベースの起動 ....................................................................................... 8-2
フィジカル・スタンバイ・データベースの停止 ....................................................................................... 8-3
読取り専用アクセス用にオープンしたスタンバイ・データベースの使用 ................................................... 8-4
読取り専用アクセス用にスタンバイ・データベースをオープンするかどうかの評価 ....................... 8-5
読取り専用アクセス用にフィジカル・スタンバイ・データベースをオープン ................................... 8-6
読取り専用アクセス用にオープンしたスタンバイ・データベースのソートに関する考慮事項 ....... 8-7
スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理 ..................... 8-10
データ・ファイルの追加または表領域の作成 ......................................................................................... 8-11
プライマリ・データベースの表領域の削除 ............................................................................................. 8-14
フィジカル・スタンバイ・データベースでのトランスポータブル表領域の使用 ............................. 8-15
プライマリ・データベースのデータ・ファイルの改名 ......................................................................... 8-16
オンライン REDO ログ・ファイルの追加または削除 ........................................................................... 8-18
プライマリ・データベースの制御ファイルの変更 ................................................................................. 8-19
ログに記録されていないまたはリカバリ不能な操作 ............................................................................. 8-19
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップ
およびリストア ..................................................................................................................................................... 8-20
バックアップ処理 ......................................................................................................................................... 8-20
スイッチオーバー、フェイルオーバーおよび制御ファイル作成がバックアップに与える影響 ..... 8-22
その他のバックアップ状況 ......................................................................................................................... 8-28
フラッシュ・リカバリ領域のアーカイブ REDO ログ・ファイルに関する削除ポリシー ............... 8-31
OPEN RESETLOGS 文を使用したリカバリ ................................................................................................... 8-33
v
プライマリおよびスタンバイ・データベースの監視 ..................................................................................... 8-35
アラート・ログ ............................................................................................................................................. 8-37
動的パフォーマンス・ビュー（固定ビュー）........................................................................................... 8-37
リカバリの進捗の監視 ................................................................................................................................. 8-38
9
ロジカル・スタンバイ・データベースの管理
ロジカル・スタンバイ・データベースの構成と管理 ....................................................................................... 9-2
SQL Apply の管理 .......................................................................................................................................... 9-3
ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスの制御 ........................... 9-4
SQL Apply で不要になったアーカイブ REDO ログ・ファイルの削除 ................................................ 9-5
ロジカル・スタンバイ・データベースの変更 ........................................................................................... 9-6
ロジカル・スタンバイ・データベースでのトリガーと制約の処理方法 ............................................... 9-8
ロジカル・スタンバイ・データベースでの SQL 文のスキップ ............................................................. 9-8
ロジカル・スタンバイ・データベースでの表の追加または再作成 ..................................................... 9-10
ロジカル・スタンバイ・イベントの表示と制御 ..................................................................................... 9-11
SQL Apply アクティビティの理解と表示 ................................................................................................ 9-12
リアルタイム適用の使用可能化 ................................................................................................................. 9-14
適用された REDO データ量の判別 ........................................................................................................... 9-15
エラーのリカバリ ......................................................................................................................................... 9-16
マテリアライズド・ビューのリフレッシュ ............................................................................................. 9-19
Oracle Database ソフトウェア・バージョンのアップグレード ..................................................................
OPEN RESETLOGS 文を使用したリカバリ ...................................................................................................
ロジカル・スタンバイ・データベースのチューニング .................................................................................
主キー RELY 制約の作成 .............................................................................................................................
9-19
9-24
9-26
9-26
コストベース・オプティマイザの統計の収集 ......................................................................................... 9-26
トランザクションの一貫性の調整 ............................................................................................................. 9-27
パラレル実行処理の最大数の調整 ............................................................................................................. 9-29
ロジカル・スタンバイ・データベースでのメモリー使用量の制御 ..................................................... 9-29
10
Data Guard の使用例
アーカイブ先の設定および確認 ......................................................................................................................... 10-2
プライマリ・データベースおよびフィジカル・スタンバイ・データベースの構成 ......................... 10-2
プライマリ・データベースおよびロジカル・スタンバイ・データベースの構成 ............................. 10-5
フィジカルおよびロジカル・スタンバイ・データベースの構成 ......................................................... 10-9
各宛先について現行の VALID_FOR 属性設定の確認 .......................................................................... 10-13
vi
ロールの推移に最適なスタンバイ・データベースの選択 ........................................................................... 10-14
例 : フェイルオーバーに最適なフィジカル・スタンバイ・データベース ........................................ 10-15
例 : フェイルオーバー操作に最適なロジカル・スタンバイ・データベース .................................... 10-22
フェイルオーバー後のフラッシュバック・データベースの使用 ............................................................... 10-28
障害が発生したプライマリ・データベースのフィジカル・スタンバイ・データベースへの
変換 ............................................................................................................................................................... 10-28
障害が発生したロジカル・データベースのフィジカル・スタンバイ・データベースへの変換 ... 10-31
Open Resetlogs 文の発行後のフラッシュバック・データベースの使用 ................................................. 10-32
フィジカル・スタンバイ・データベースのフラッシュバック ........................................................... 10-32
ロジカル・スタンバイ・データベースのフラッシュバック ............................................................... 10-33
タイム・ラグのあるフィジカル・スタンバイ・データベースの使用 ....................................................... 10-35
フィジカル・スタンバイ・データベースでのタイム・ラグの設定 ................................................... 10-36
タイム・ラグのあるフィジカル・スタンバイ・データベースへのフェイルオーバー ................... 10-36
タイム・ラグのあるフィジカル・スタンバイ・データベースへのスイッチオーバー ................... 10-37
ネットワーク障害のリカバリ ........................................................................................................................... 10-39
NOLOGGING 句を指定した後のリカバリ .................................................................................................. 10-40
ロジカル・スタンバイ・データベースのリカバリ手順 ....................................................................... 10-40
フィジカル・スタンバイ・データベースのリカバリ手順 ................................................................... 10-41
リカバリ不能処理後にバックアップが必要かどうかの判断 ............................................................... 10-43
手動によるアーカイブ・ギャップの解決 ....................................................................................................... 10-43
アーカイブ・ギャップの発生原因 ........................................................................................................... 10-44
アーカイブ・ギャップが存在するかどうかの判断 ............................................................................... 10-47
スタンバイ・サイトへのアーカイブ・ギャップ・ログ・ファイルの手動による転送 ................... 10-48
スタンバイ・データベースへのアーカイブ・ギャップ・ログ・ファイルの手動による適用 ....... 10-50
OMF または ASM を使用するスタンバイ・データベースの作成 ............................................................. 10-51
第 II 部 リファレンス
11
初期化パラメータ
12
LOG_ARCHIVE_DEST_n パラメータの属性
宛先属性の変更 .....................................................................................................................................................
宛先の初期化パラメータに関する現行設定の表示 .........................................................................................
AFFIRM および NOAFFIRM ............................................................................................................................
ALTERNATE および NOALTERNATE ...........................................................................................................
12-2
12-3
12-4
12-6
vii
ARCH および LGWR ........................................................................................................................................
DB_UNIQUE_NAME および NODB_UNIQUE_NAME ...........................................................................
DELAY および NODELAY ...............................................................................................................................
DEPENDENCY および NODEPENDENCY .................................................................................................
LOCATION および SERVICE .........................................................................................................................
MANDATORY および OPTIONAL ...............................................................................................................
MAX_FAILURE および NOMAX_FAILURE ...............................................................................................
NET_TIMEOUT および NONET_TIMEOUT ..............................................................................................
QUOTA_SIZE および NOQUOTA_SIZE ......................................................................................................
QUOTA_USED および NOQUOTA_USED .................................................................................................
REGISTER および NOREGISTER .................................................................................................................
REOPEN および NOREOPEN ........................................................................................................................
SYNC および ASYNC .......................................................................................................................................
TEMPLATE および NOTEMPLATE ..............................................................................................................
VALID_FOR .......................................................................................................................................................
VERIFY および NOVERIFY ............................................................................................................................
アーカイブ先の属性の互換性 ...........................................................................................................................
13
12-11
12-13
12-15
12-17
12-21
12-24
12-26
12-29
12-32
12-35
12-37
12-39
12-42
12-46
12-49
12-53
12-54
Data Guard に関連する SQL 文
ALTER DATABASE 文 ....................................................................................................................................... 13-2
ALTER SESSION 文 ............................................................................................................................................ 13-7
14
Oracle Data Guard に関連するビュー
第 III 部 付録
A
Data Guard のトラブルシューティング
一般的な問題 ........................................................................................................................................................... A-2
スタンバイ・アーカイブ宛先が適切に定義されていない ....................................................................... A-2
ALTER DATABASE 文によるデータ・ファイル名の変更 ...................................................................... A-2
スタンバイ・データベースがプライマリ・データベースから REDO データを受信しない ............. A-3
フィジカル・スタンバイ・データベースをマウントできない ............................................................... A-4
ログ・ファイル宛先の障害 ................................................................................................................................... A-4
ロジカル・スタンバイ・データベース障害の処理 ........................................................................................... A-5
viii
スタンバイ・データベースへのスイッチオーバーの問題 ............................................................................... A-5
REDO データが転送されていないためスイッチオーバーできない ...................................................... A-5
SQL セッションがアクティブなためスイッチオーバーできない .......................................................... A-6
ユーザー・セッションがアクティブなためスイッチオーバーできない ............................................... A-8
ORA-01102 エラーによりスイッチオーバーできない ............................................................................. A-9
スイッチオーバー後に REDO データが適用されないためスイッチオーバーできない ..................... A-9
失敗したスイッチオーバーをロールバックして最初からやり直す .................................................... A-10
SQL Apply が停止した場合の処置 ..................................................................................................................
REDO データ転送のネットワーク調整 ...........................................................................................................
Data Guard によるネットワーク・タイムアウトの管理 .............................................................................
スタンバイ・データベースのディスクのパフォーマンスが遅い ................................................................
プライマリ・データベースの停止を回避するにはログ・ファイルを一致させる必要がある ................
B
A-11
A-12
A-13
A-15
A-15
Data Guard および Real Application Clusters
Real Application Clusters 環境でのスタンバイ・データベースの構成 ....................................................... B-2
複数インスタンス・プライマリ・データベースと単一インスタンス・スタンバイ・データベース
の設定 ............................................................................................................................................................... B-2
複数インスタンス・プライマリ・データベースと複数インスタンス・スタンバイ・データベース
の設定 ............................................................................................................................................................... B-4
インスタンス間アーカイブ・データベース環境の設定 ........................................................................... B-6
Real Application Clusters 環境での構成に関する考慮事項 .......................................................................... B-7
アーカイブ REDO ログ・ファイル名の形式 ............................................................................................. B-7
アーカイブ先の割当て制限 ........................................................................................................................... B-8
データ保護モード ........................................................................................................................................... B-8
ロールの推移 ................................................................................................................................................... B-9
トラブルシューティング .................................................................................................................................... B-10
Real Application Clusters 構成でスイッチオーバーできない ............................................................. B-10
ネットワーク停止時に Real Application Clusters の停止時間を回避する ........................................ B-11
C
カスケードされた REDO ログ宛先
カスケードされた REDO ログ宛先の構成 ........................................................................................................ C-3
フィジカル・スタンバイ・データベースに対するカスケードされた REDO ログ宛先の構成 ........ C-3
ロジカル・スタンバイ・データベースに対するカスケードされた REDO ログ宛先の構成 ............ C-4
カスケードされた REDO ログ宛先を使用したロールの推移 ........................................................................ C-5
フィジカル・スタンバイ・データベースから REDO データを受信するスタンバイ・データベース ... C-5
ロジカル・スタンバイ・データベースから REDO データを受信するスタンバイ・データベース ...... C-5
ix
カスケードされた REDO ログ宛先の例 ............................................................................................................ C-6
ローカル・フィジカル・スタンバイとカスケードされたリモート・フィジカル・スタンバイ ...... C-6
ローカル・フィジカル・スタンバイとカスケードされたリモート・ロジカル・スタンバイ .......... C-7
ローカルおよびリモート・フィジカル・スタンバイとカスケードされたローカル・ロジカル・
スタンバイ ...................................................................................................................................................... C-8
カスケードされたロジカル・スタンバイ宛先の統合レポート生成 ...................................................... C-9
ネットワーク・アップグレード時のカスケードされた宛先の一時使用 .............................................. C-9
D
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
スタンバイ・データベースを作成するための Recovery Manager の準備 .................................................. D-2
Recovery Manager を使用したスタンバイ・データベースの準備について ....................................... D-3
Recovery Manager を使用したスタンバイ制御ファイルの作成 ........................................................... D-4
Recovery Manager を使用した場合のスタンバイ・データベースのデータ・ファイルの
ネーミング ...................................................................................................................................................... D-5
Recovery Manager を使用した場合のスタンバイ・データベース・ログ・ファイルのネーミング ... D-7
Recovery Manager を使用したスタンバイ・データベースの作成 : 概要 .................................................... D-8
リカバリを実行しない Recovery Manager によるスタンバイの作成 .................................................. D-8
リカバリを実行する Recovery Manager によるスタンバイの作成 ...................................................... D-9
スタンバイ・インスタンスの設定 .................................................................................................................... D-10
同一のディレクトリ構造のスタンバイ・データベースの作成 .................................................................... D-12
リカバリを実行しないスタンバイ・データベースの作成 .................................................................... D-12
スタンバイ・データベースの作成およびリカバリの実行 .................................................................... D-13
異なるディレクトリ構造のスタンバイ・データベースの作成 .................................................................... D-14
DB_FILE_NAME_CONVERT を使用したスタンバイ・データベース・ファイルのネーミング ... D-15
SET NEWNAME を使用したスタンバイ・データベース・ファイルのネーミング ........................ D-16
CONFIGURE AUXNAME を使用したスタンバイ・データベース・ファイルのネーミング ........ D-18
ローカル・ホスト上へのスタンバイ・データベースの作成 ........................................................................ D-21
イメージ・コピーを使用したスタンバイ・データベースの作成 ................................................................ D-22
概要 ................................................................................................................................................................ D-22
コピーおよびデータ・ファイルで同一の名前を使用する場合 ............................................................ D-24
コピーおよびデータ・ファイルで異なる名前を使用する場合 ............................................................ D-25
使用例 .................................................................................................................................................................... D-28
x
E
アーカイブ・トレースの設定
LOG_ARCHIVE_TRACE 初期化パラメータ ................................................................................................... E-2
トレース・ファイルの位置の判別 ....................................................................................................................... E-2
LOG_ARCHIVE_TRACE 初期化パラメータの設定 ................................................................................. E-3
整数値の選択 ................................................................................................................................................... E-3
F
障害時リカバリに関する ReadMe ファイルのサンプル
索引
xi
xii
例
3-1
3-2
3-3
4-1
4-2
4-3
4-4
5-1
5-2
5-3
5-4
5-5
5-6
5-7
5-8
5-9
5-10
5-11
9-1
9-2
9-3
10-1
12-1
12-2
A-1
A-2
B-1
F-1
プライマリ・データベース : プライマリ・ロールの初期化パラメータ ........................................ 3-4
プライマリ・データベース : スタンバイ・ロールの初期化パラメータ ........................................ 3-4
フィジカル・スタンバイ・データベース用の初期化パラメータの変更 ..................................... 3-10
プライマリ・データベース : ロジカル・スタンバイ・ロールの初期化パラメータ .................. 4-11
ロジカル・スタンバイ・データベース用の初期化パラメータの変更 ......................................... 4-13
初期化フェーズ時の V$LOGSTDBY 出力 ........................................................................................ 4-21
適用フェーズ時の V$LOGSTDBY 出力 ............................................................................................ 4-22
ローカルのアーカイブ先の指定 ........................................................................................................... 5-5
リモートのアーカイブ先の指定 ........................................................................................................... 5-7
共有リカバリ領域に関するプライマリ・データベースの初期化パラメータ ............................. 5-10
共有リカバリ領域に関するスタンバイ・データベースの初期化パラメータ ............................. 5-10
プライマリ・データベース : ARCn アーカイブの初期化パラメータ .......................................... 5-14
LGWR 同期アーカイブのための初期化パラメータ ....................................................................... 5-18
LGWR 非同期アーカイブのための初期化パラメータ ................................................................... 5-20
再試行時間の設定と制限 ..................................................................................................................... 5-26
特定のスレッドへのスタンバイ REDO ログ・ファイル・グループの追加 ............................... 5-30
特定のグループ番号へのスタンバイ REDO ログ・ファイル・グループの追加 ....................... 5-30
必須のアーカイブ先の設定 ................................................................................................................. 5-36
ロジカル・スタンバイ・データベース内の表のスキップ ............................................................... 9-9
ALTER または CREATE TABLESPACE 文のスキップ .................................................................... 9-9
ロジカル・スタンバイ・データベースへの表の追加 ..................................................................... 9-11
V$ARCHIVE_DEST ビューでの VALID_FOR 情報の検索 ......................................................... 10-13
代替アーカイブ先への自動フェイルオーバー ............................................................................... 12-10
スタンバイ・データベースに対する代替の Oracle Net サービス名の定義 ............................. 12-10
再試行時間の設定と制限 ....................................................................................................................... A-4
代替宛先の指定 ....................................................................................................................................... A-4
インスタンス間アーカイブの宛先の設定 ........................................................................................... B-6
障害時リカバリに関する ReadMe ファイルのサンプル .................................................................. F-2
xiii
xiv
図
1-1
1-2
1-3
1-4
2-1
5-1
5-2
5-3
5-4
5-5
5-6
5-7
6-1
7-1
7-2
7-3
7-4
7-5
8-1
9-1
9-2
9-3
9-4
9-5
9-6
9-7
10-1
10-2
10-3
10-4
10-5
10-6
10-7
12-1
12-2
B-1
B-2
C-1
一般的な Data Guard 構成 .................................................................................................................... 1-3
フィジカル・スタンバイ・データベースの自動更新 ....................................................................... 1-5
ロジカル・スタンバイ・データベースの自動更新 ........................................................................... 1-6
Oracle Enterprise Manager の Data Guard 概要ページ ................................................................... 1-8
可能なスタンバイ構成 ......................................................................................................................... 2-10
REDO データの転送 .............................................................................................................................. 5-2
スタンバイ・データベースがない場合のプライマリ・データベースのアーカイブ処理 .......... 5-6
リモートの宛先にアーカイブする前にローカルの宛先にアーカイブする ................................. 5-13
ローカルおよびリモートの宛先へ同時にアーカイブする ............................................................. 5-15
スタンバイ REDO ログ・ファイルを使用したリモートの宛先への LGWR SYNC アーカイブ ... 5-19
ネットワーク・サーバー（LNSn）プロセスを使用した LGWR ASYNC アーカイブ ............. 5-21
依存する宛先を含む Data Guard 構成 .............................................................................................. 5-39
リアルタイム適用を使用したスタンバイ宛先への REDO データの適用 ..................................... 6-4
ロールの推移を選択するための意思決定ツリー ............................................................................... 7-4
スイッチオーバー前の Data Guard 構成 ............................................................................................ 7-5
新しいプライマリ・データベースへのスイッチオーバー前のスタンバイ・データベース ....... 7-6
スイッチオーバー後の Data Guard 環境 ............................................................................................ 7-6
スタンバイ・データベースへのフェイルオーバー ........................................................................... 7-9
読取り専用アクセス用にオープンしたスタンバイ・データベース ............................................... 8-4
SQL Apply の処理 ................................................................................................................................ 9-12
アップグレード前の Data Guard 構成 .............................................................................................. 9-20
ロジカル・スタンバイ・データベースのバージョンのアップグレード ..................................... 9-21
混合バージョンの実行 ......................................................................................................................... 9-22
スイッチオーバー後 ............................................................................................................................. 9-23
両方のデータベースがアップグレードされた後 ............................................................................. 9-23
SQL Apply でのトランザクション一貫性の例 ................................................................................ 9-28
ロールの推移前のプライマリおよびフィジカル・スタンバイ・データベース ......................... 10-2
ロールの推移後のプライマリおよびフィジカル・スタンバイ・データベース ......................... 10-4
プライマリ・データベースおよびロジカル・スタンバイ・データベースの宛先の構成 ......... 10-5
ロールの推移後のプライマリおよびロジカル・スタンバイ・データベース ............................. 10-8
フィジカルおよびロジカル・スタンバイ・データベースを備えたプライマリ・データベース
の構成 ..................................................................................................................................................... 10-9
ロールの推移後のプライマリ、フィジカルおよびロジカル・スタンバイ・データベース ... 10-11
アーカイブ・ギャップ内にあるアーカイブ REDO ログ・ファイルの手動リカバリ ............. 10-45
代替アーカイブ先のデバイスへのアーカイブ操作 ......................................................................... 12-8
宛先へのディスク・クオータの指定 ............................................................................................... 12-33
複数インスタンス・プライマリ・データベースからの REDO データの転送 ............................. B-3
Real Application Clusters のスタンバイ・データベース ................................................................ B-4
カスケードされた REDO ログ宛先の構成例 .................................................................................... C-2
xv
xvi
表
2-1
3-1
3-2
4-1
4-2
5-1
5-2
5-3
5-4
5-5
5-6
8-1
8-2
9-1
10-1
10-2
10-3
11-1
12-1
12-2
12-3
12-4
13-1
13-2
14-1
A-1
A-2
B-1
D-1
D-2
D-3
スタンバイ・データベースの位置とディレクトリ・オプション ................................................. 2-11
フィジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備 ... 3-2
フィジカル・スタンバイ・データベースの作成 ................................................................................. 3-8
ロジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備 ... 4-2
ロジカル・スタンバイ・データベースの作成 ................................................................................... 4-8
LOG_ARCHIVE_DEST_STATE_n 初期化パラメータの属性 ......................................................... 5-4
データ保護モードの最低要件 ............................................................................................................. 5-32
ARCH 属性で構成される宛先の待機イベント ................................................................................ 5-47
LGWR SYNC 属性で構成される宛先の待機イベント .................................................................... 5-48
LGWR ASYNC 属性で構成される宛先の待機イベント ................................................................ 5-48
LGWR ASYNC または LGWR SYNC=PARALLEL 属性の待機イベント ................................... 5-49
プライマリ・データベースでの変更後にスタンバイ・データベースで必要なアクション ..... 8-10
プライマリ・データベースの共通アクションを監視できる場所 ................................................. 8-35
PL/SQL パッケージ DBMS_LOGSTDBY のプロシージャ .............................................................. 9-3
Data Guard の使用例 ........................................................................................................................... 10-1
フィジカル・スタンバイ・データベースの例で使用される識別子 ........................................... 10-15
ロジカル・スタンバイ・データベースの例で使用される識別子 ............................................... 10-22
Data Guard 構成内のインスタンスの初期化パラメータ ............................................................... 11-2
SQL を使用した宛先属性の変更 ........................................................................................................ 12-2
TEMPLATE 属性のディレクティブ ................................................................................................ 12-47
VALID_FOR 属性の値 ....................................................................................................................... 12-50
LOG_ARCHIVE_DEST_n 属性の互換性 ........................................................................................ 12-54
Data Guard 環境で使用される ALTER DATABASE 文 ................................................................. 13-2
Data Guard 環境で使用される ALTER SESSION 文 ...................................................................... 13-7
Data Guard 構成に関連のあるビュー ............................................................................................... 14-2
スイッチオーバーを妨げる共通のプロセス ....................................................................................... A-7
一般的な SQL Apply エラーの解決方法 .......................................................................................... A-11
LOG_ARCHIVE_FORMAT 初期化パラメータのディレクティブ ................................................. B-7
Recovery Manager を使用したスタンバイ・データベースの準備 ............................................... D-3
スタンバイ・データベース内のデータ・ファイルのネーミング優先順位 .................................. D-6
イメージ・コピーを使用したスタンバイ・データベースの作成 : 使用例 ................................. D-23
xvii
xviii
はじめに
Oracle Data Guard は、現在使用できる最も効率的なソリューションで、企業の中核となる
資産、つまりデータを保護し、障害やその他の災害が発生しても、24 時間 365 日そのデータ
を使用できるようにします。
このマニュアルでは、Oracle Data Guard テクノロジとその概要、スタンバイ・データベー
スの構成および実装方法について説明します。
「はじめに」は、次の項目で構成されています。
■
対象読者
■
このマニュアルの構成
■
関連ドキュメント
■
表記規則
xix
対象読者
『Oracle Data Guard 概要および管理』は、Oracle データベース・システムのバックアップ、
リストアおよびリカバリ操作を管理するデータベース管理者を対象としています。
このマニュアルは、読者がリレーショナル・データベースの概念と、基本的なバックアップ
およびリカバリ管理に精通していることを前提としています。また、Oracle ソフトウェアを
実行するオペレーティング・システム環境をよく理解している必要があります。
このマニュアルの構成
このマニュアルの構成は次のとおりです。
第 I 部「概要および管理」
第 1 章「Oracle
Data Guard の概要」
章「
Oracle Data Guard のアーキテクチャの概要について説明します。
第 2 章「Data
Guard スタート・ガイド」
章「
フィジカル・データベースおよびロジカル・データベースについて詳しく説明し、Data
Guard 構成の管理に使用できる様々なインタフェースを示します。また、Data Guard を使用
するための動作要件と、スタンバイ・データベースでディレクトリ構造を設定するための推
奨事項も示します。
第 3 章「フィジカル・スタンバイ・データベースの作成」
フィジカル・スタンバイ・データベースの作成方法について説明します。
第 4 章「ロジカル・スタンバイ・データベースの作成」
ロジカル・スタンバイ・データベースの作成方法について説明します。
第 5 章「ログ転送サービス」
ログ転送サービスについて紹介します。本番データベースが予期せず停止した場合に、デー
タ消失を防ぐためのデータ保護モードについて説明します。また、プライマリ・データベー
スとスタンバイ・データベースでログ転送サービスを構成するための手順とガイドラインも
示します。
第 6 章「ログ適用サービス」
ログ適用サービスについて説明します。フィジカル・スタンバイ・データベースとロジカ
ル・スタンバイ・データベース用のログ適用サービスを管理するためのガイドラインを示し
ます。
xx
第 7 章「ロール管理」
ロール管理サービスについて説明します。フェイルオーバーおよびスイッチオーバー時の
データベース・ロールの推移に関する情報を提供します。
第 8 章「フィジカル・スタンバイ・データベースの管理」
フィジカル・スタンバイ・データベースの管理方法について説明します。スタンバイ・デー
タベースに影響を与えるイベントの監視と応答に関する情報を提供します。
第 9 章「ロジカル・スタンバイ・データベースの管理」
ロジカル・スタンバイ・データベースの管理方法について説明します。SQL Apply の管理、
システム・チューニングおよび表領域管理に関する情報を提供します。
第 10 章「Data
Guard の使用例」
章「
スタンバイおよびプライマリ・データベースの作成、リカバリ、フェイルオーバー、切替
え、構成およびバックアップなどの共通のデータベース操作について説明します。
第 II 部「リファレンス」
第 11 章「初期化パラメータ」
Data Guard 環境のプライマリ・データベースと各スタンバイ・データベースを含む、各
Oracle インスタンスの初期化パラメータについて説明します。
第 12 章「LOG_ARCHIVE_DEST_n
パラメータの属性」
章「
LOG_ARCHIVE_DEST_n 初期化パラメータの属性の構文と例を示します。
第 13 章「Data
Guard に関連する SQL 文」
章「
Data Guard 構成で操作を実行するときに役立つ SQL 文を紹介します。
第 14 章「Oracle
Data Guard に関連するビュー」
章「
Data Guard 環境の監視に役立つ情報を含むビューをリストします。各ビューに表示される
列をまとめ、それぞれの列について説明します。
第 III 部「付録および用語集」
付録 A「
「Data Guard のトラブルシューティング」
Data Guard およびスタンバイ・データベースのトラブルシューティングのヒントについて
説明します。
xxi
付録 B「
「Data Guard および Real Application Clusters」
」
Real Application Clusters 環境のプライマリおよびスタンバイ・データベースの構成につい
て説明します。
付録 C「カスケードされた
「カスケードされた REDO ログ宛先」
カスケードされた REDO ログ・ファイル宛先の実装方法について説明します。これによっ
て、スタンバイ・データベースは、REDO データをプライマリ・データベースから直接受信
するのではなく、別のスタンバイ・データベースから受信します。
付録 D「
「Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成」
この付録では、Recovery Manager を使用してフィジカル・スタンバイ・データベースを作
成する方法を説明します。
付録 E「アーカイブ・トレースの設定」
「アーカイブ・トレースの設定」
この付録では、ARCn プロセス、LGWR プロセス、プライマリ・データベースのフォアグラ
ウンド・プロセス、およびスタンバイ・データベースの RFS プロセスと FAL サーバー・プ
ロセスによって生成されるトレース出力を、LOG_ARCHIVE_TRACE パラメータで制御する
方法について説明します。
付録 F「障害時リカバリに関する
「障害時リカバリに関する ReadMe ファイルのサンプル」
障害時リカバリを行う担当者が、どのスタンバイ・データベースをフェイルオーバー操作の
ターゲットとするかを決定する上で必要な情報が含まれた、ReadMe ファイルのサンプルを
提供します。
xxii
関連ドキュメント
『Oracle Data Guard 概要および管理』の読者は、次のマニュアルをすでに読んでいることが
前提となります。
■
■
■
■
『Oracle Database 概要』の冒頭部分。Oracle データベースに関連する概念と用語の概要
が説明されており、このマニュアルに記載されている詳細情報の基礎となっています。
『Oracle Database 管理者ガイド』の中で、制御ファイル、オンライン REDO ログ・ファ
イルおよびアーカイブ REDO ログ・ファイルの管理について説明している章。
『Oracle Database ユーティリティ』の中で、LogMiner テクノロジについて説明してい
る章。
『Oracle Data Guard Broker』。Data Guard 構成の作成、メンテナンスおよび監視を自動
化および集中化するグラフィカル・ユーザー・インタフェースとコマンドライン・イン
タフェースについて説明しています。
このマニュアルの説明では、次の各マニュアルも取り上げています。
■
『Oracle Database SQL リファレンス』
■
『Oracle Database リファレンス』
■
『Oracle Database バックアップおよびリカバリ基礎』
■
『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』
■
『Oracle Net Services 管理者ガイド』
■
『SQL*Plus ユーザーズ・ガイドおよびリファレンス』
■
『Oracle 高可用性アーキテクチャおよびベスト・プラクティス』
既存の Data Guard 構成をこの Oracle リリースにアップグレードする場合の詳細な手順は、
『Oracle Database アップグレード・ガイド』を参照してください。障害時リカバリと高可用
性ソリューションを提供するその他の Oracle 製品と特性に関する情報は、『Oracle Database
概要』を参照してください。
Oracle Streams および Streams のダウンストリーム・キャプチャ・データベースの詳細は、
『Oracle Streams 概要および管理』も参照してください。Streams のダウンストリーム・キャ
プチャ・プロセスは、Oracle Data Guard のログ転送サービスを使用して、REDO データを
リモート・データベース上のログ・ファイルに転送します。リモート・データベースでは、
Streams キャプチャ・プロセスにより、リモート宛先のアーカイブ REDO ログ・ファイルの
変更がキャプチャされます。
リリース・ノート、インストール関連ドキュメント、ホワイト・ペーパーまたはその他の関
連ドキュメントは、OTN-J（Oracle Technology Network Japan）から、無償でダウンロード
できます。OTN-J を使用するには、オンラインでの登録が必要です。登録は、次の Web サ
イトから無償で行えます。
http://otn.oracle.co.jp/membership/
xxiii
OTN-J のユーザー名およびパスワードを取得している場合は、次の URL で OTN-J Web サイ
トのドキュメントのセクションに直接接続できます。
http://otn.oracle.co.jp/document/
表記規則
この項では、このマニュアルの本文とコード例に使用されている表記規則について説明しま
す。次の表は、本文の表記規則と使用例を示します。
表記
意味
例
[]
大カッコは、カッコ内の項目を任意に選択
することを表します。大カッコは、入力し
ないでください。
DECIMAL (digits [ , precision ])
{}
中カッコは、カッコ内の項目のうち、1 つが {ENABLE | DISABLE}
必須であることを表します。中カッコは入
力しないでください。
|
縦線は、大カッコまたは中カッコ内の複数
の選択項目の区切りに使用します。項目の
うちの 1 つを入力します。縦線は入力しな
いでください。
...
■
.
[COMPRESS | NOCOMPRESS]
水平の省略記号は、次のいずれかを示しま
す。
■
.
{ENABLE | DISABLE}
例に直接関連しないコードの一部が省
略されている。
CREATE TABLE ...AS subquery;
コードの一部を繰り返すことができる。 SELECT col1, col2, ..., coln FROM
employees;
垂直の省略記号は、例に直接関連しない複
数の行が省略されていることを示します。
.
太字
太字は、本文中で定義されている用語およ この句を指定すると、索引構成表
索引構成表が作成されます。
索引構成表
び用語集に記載されている用語を示します。
固定幅フォントの
大文字
固定幅フォントの大文字は、システム指定
の要素を示します。
BACKUP コマンドを使用して、データベースの
バックアップを作成できます。
DBMS_STATS.GENERATE_STATS プロシージャを
使用します。
xxiv
表記
意味
例
固定幅フォントの
小文字
固定幅フォントの小文字は、実行可能ファ
イル、ファイル名、ディレクトリ名および
ユーザーが指定する要素のサンプルを示し
ます。
sqlplus と入力して SQL*Plus をオープンしま
す。
/disk1/oracle/dbs ディレクトリ内のデータ・
ファイルおよび制御ファイルのバックアップを作
成します。
hr.departments 表には、department_id、
department_name および location_id 列があ
ります。
固定幅フォントの
小文字の
イタリック
固定幅フォントの小文字のイタリックは、
プレースホルダまたは変数を示します。
大小文字が
混在した
固定幅フォント
大小文字が混在した固定幅フォントは、
Data Guard Broker のデータベースのプロパ
ティを示します。大小文字の混在により、
Data Guard Broker のプロパティと、他のシ
ステム指定の要素を視覚的に区別できます。
システム指定の要素は、常に大文字で示さ
れます。
parallel_clause を指定できます。
Uold_release.SQL を実行します。old_
release は、アップグレード前にインストールし
たリリースを示します。
StandbyFileManagement プロパティは、
STANDBY_FILE_MANAGEMENT 初期化パラメータ
に対応しています。
これらのメソッドは JRepUtil クラスに実装され
ます。
大小文字が混在した固定幅フォントは、他
のプログラム要素を示すこともあります。
この場合は、記載されているとおりに入力
してください。
xxv
xxvi
Oracle Data Guard の新機能
リリース 10.1 の Oracle Data Guard には、この項で説明する新機能と拡張機能が追加されま
した。新機能を、次の主な内容にわけて説明します。
■
フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースに
共通の新機能
■
フィジカル・スタンバイ・データベース固有の新機能
■
ロジカル・スタンバイ・データベース固有の新機能
xxvii
フィジカル・スタンバイ・データベースおよびロジカル・スタ
ンバイ・データベースに共通の新機能
リリース 10.1 の Oracle Data Guard に対する次の拡張機能により、利便性、管理性およびパ
フォーマンスが向上し、障害時リカバリ機能を改善する新機能が追加されています。
■
リアルタイム適用
Data Guard ログ適用サービスで、REDO データをロジカル・スタンバイ・データベー
スまたはフィジカル・スタンバイ・データベースで受信した時点で適用できるようにな
りました。現行のスタンバイ・オンライン REDO ログ・ファイルがアーカイブされる
まで待機する必要がありません。これにより、これまで以上に最新の情報のレポート作
成、すばやいフェイルオーバーおよびスイッチオーバーが可能になり、計画的および計
画外の停止時間が削減されます。
関連項目 :
■
第 6 章「ログ適用サービス」
オープンなリセットログによるリカバリ
Data Guard は、スタンバイ・データベースで RESETLOGS 操作に適切に対応したリカ
バリを許容することにより、オープンなリセットログによるリカバリをサポートしてい
ます。スタンバイ・データベースを再作成する必要はありません。ALTER DATABASE
OPEN RESETLOGS 文は、常に Point-in-Time リカバリまたはフラッシュバック・データ
ベース操作の後に発行されるため、リセットログによるリカバリ機能で、スタンバイ・
データベースの再開が可能になります。
関連項目 : 10-32 ページ「Open Resetlogs 文の発行後のフラッシュバッ
ク・データベースの使用」
■
フラッシュバック・データベースのサポート
Data Guard は新しいフラッシュバック・データベース機能をサポートしており、これ
により、スタンバイ・データベースを任意の時点まで、すばやく容易にフラッシュ・
バックできます。この機能を Data Guard と同時に使用することにより、次の利点が得
られます。
xxviii
–
フラッシュバック・データベースにより、フェイルオーバー後のプライマリ・デー
タベースの再作成の必要がなくなります。フェイルオーバー後、元のプライマリ・
データベースをフェイルオーバー以前の時点にフラッシュ・バックし、スタンバ
イ・データベースに変換できます。すべてのログを適用した後、元のプライマリ・
データベースをプライマリ・ロールに切り換えることが可能です。
–
ユーザー・エラーまたは論理的な破損から保護するための、REDO データ適用の遅
延に対する代替手段が提供されます。そのため、スタンバイ・データベースは、プ
ライマリ・データベースとより密接に同期できるため、フェイルオーバーおよびス
イッチオーバーの回数が少なくなります。
関連項目 : フラッシュバック・データベースの使用方法の詳細は、6-5
ページの「アーカイブ REDO ログ・ファイルの適用に対するタイム・
ディレイの指定」および『Oracle Database バックアップおよびリカバリ・
アドバンスト・ユーザーズ・ガイド』を参照してください。
■
REDO データ転送のセキュリティの向上
Data Guard のログ転送サービスでは、Data Guard 構成メンバー間での REDO データ転
送に認証ネットワーク・セッションを使用するようになりました。Oracle Advanced
Security Option がインストールされている場合、REDO データのネットワーク転送に暗
号化および整合性チェックサムを使用することにより、セキュリティをさらに強化でき
ます。
関連項目 : 5-22 ページの「セキュアな REDO データの転送の提供」, 第
12 章「LOG_ARCHIVE_DEST_n パラメータの属性」および 『Oracle
Advanced Security 管理者ガイド』
■
Real Application Clusters に対する Data Guard のサポートの改善
Real Application Clusters のプライマリ・データベースまたはスタンバイ・データベー
スが含まれている Data Guard 構成の管理に Data Guard Broker を使用できるようにな
りました。
関連項目 : 『Oracle Data Guard Broker』
■
Real Application Clusters へのスタンバイ・データベースの動的追加
Real Application Clusters のプライマリ・データベースが最大保護または最大可用性保
護レベルで実行されている場合、Real Application Clusters のプライマリ・データベー
スが含まれている Data Guard 構成に、プライマリ・データベースを停止せずにスタン
バイ・データベースを動的に追加できるようになりました。
この拡張機能を使用するには、Oracle Database 10g リリース 1（10.1）で新しく導入さ
れた初期化パラメータを使用する必要があります。
–
DB_UNIQUE_NAME
–
LOG_ARCHIVE_CONFIG
関連項目 : 第 5 章「ログ転送サービス」および 第 12 章「LOG_
ARCHIVE_DEST_n パラメータの属性」
xxix
■
Data Guard 構成管理の単純化
LOG_ARCHIVE_DEST_n 初期化パラメータの新規の VALID_FOR 属性を使用して、ロー
ルに依存しない初期化パラメータ・ファイルを作成できます。データベース・ロールの
推移後にロール固有のアーカイブ先を可能または不可能に設定する必要がないため、ス
イッチオーバーおよびフェイルオーバーが単純化されます。この機能により、データ
ベースがプライマリ・ロールまたはスタンバイ・ロールのいずれで稼働していても、同
じパラメータ・ファイルを使用できます。
関連項目 : 第 5 章「ログ転送サービス」および 第 12 章「LOG_
ARCHIVE_DEST_n パラメータの属性」
■
自動化されたディスクベースのバックアップおよびフラッシュバック・リカバリ
・リカバリ
自動化されたディスクベースのバックアップおよび
バックアップおよびリカバリに必要なファイルをフラッシュ・リカバリ領域に格納する
と、これらのファイルの管理が単純になります。フラッシュ・リカバリ領域が構成され
ると、Data Guard は暗黙的に LOG_ARCHIVE_DEST_10 初期化パラメータをフラッ
シュ・リカバリ領域を指すよう設定し、別のローカル・アーカイブ先が明示的に構成さ
れていないかぎり、これをローカル・アーカイブに使用します。
関連項目 : 第 5 章「ログ転送サービス」および 『Oracle Database バック
アップおよびリカバリ基礎』
■
アーカイバ・プロセスによるリモート・スタンバイ REDO ログ・ファイルのサポート
スタンバイ REDO ログ・ファイルを使用するよう構成されているリモートの宛先に、
アーカイバ・プロセス（ARCn）を使用して REDO データを転送できるようになりまし
た。この機能を使用すると、フェイルオーバーの実行前に部分的なアーカイブ REDO ロ
グ・ファイルを登録する必要がないため、フェイルオーバーが単純化されます。
関連項目 :
■
第 5 章「ログ転送サービス」
デフォルトのアーカイブ動作の変更
Data Guard 構成のデフォルトのアーカイブ・プロセスが変更され、プライマリ・デー
タベースのアーカイバ・プロセス（ARCn）は REDO データをリモート・スタンバイ宛
先に転送する前に、ローカル・オンライン REDO ログ・ファイルを完全に正しくアー
カイブするようになりました。リリース 10.1 より前のデフォルトの動作では、スタンバ
イ宛先への REDO データの転送は、ローカル・オンライン REDO ログ・ファイルへの
オンライン REDO ログ・ファイルのアーカイブと同時に実行されていました。この変更
により、REDO ログ・グループはより速く再利用が可能になり、使用可能な REDO ロ
グ・グループがないためにデータベースが停止する可能性が低下します。
関連項目 : 5-11 ページ「アーカイバ・プロセス（ARCn）を使用した
REDO データのアーカイブ」
xxx
■
REDO ログ・アーカイブの管理の単純化
データベースを ARCHIVELOG モードに設定すると、デフォルトで自動アーカイブが有
効になります。
関連項目 :
ガイド』
■
第 5 章「ログ転送サービス」および 『Oracle Database 管理者
セキュアな REDO の転送
ログ転送サービスは、REDO データの送信に認証ネットワーク・セッションを使用する
ようになりました。これらのセッションは、パスワード・ファイル内の SYS ユーザー・
パスワードを使用して認証されます。Data Guard 構成内の全データベースでパスワー
ド・ファイルを使用する必要があり、このパスワード・ファイル内の SYS パスワード
は、全システムで同一である必要があります。Oracle Advanced Security がインストー
ルされていない場合もこの認証は実行可能で、REDO の転送の際にある程度のセキュリ
ティを提供します。
関連項目 : 5-22 ページの「セキュアな REDO データの転送の提供」およ
び 『Oracle Advanced Security 管理者ガイド』
フィジカル・スタンバイ・データベース固有の新機能
次のリストに、Oracle Database 10g のフィジカル・スタンバイ・データベース固有の新機能
を示します。
■
STARTUP、MOUNT および OPEN 文の新規デフォルト動作
STARTUP、MOUNT および OPEN 文のデフォルト動作が新しくなり、フィジカル・スタ
ンバイ・データベースでの使用方法が単純化されました。
–
STARTUP コマンドは、1 つの手順で読取り専用モードのフィジカル・スタンバイ・
データベースを起動、マウントおよびオープンします。
–
フィジカル・スタンバイ・データベースのマウントに ALTER DATABASE MOUNT
文を使用する際、STANDBY DATABASE キーワードはオプションです。
–
フィジカル・スタンバイ・データベースのオープンに ALTER DATABASE OPEN 文
を使用する際、READ ONLY キーワードはオプションです。
関連項目 : 第 13 章「Data Guard に関連する SQL 文」および 『Oracle
Database SQL リファレンス』
xxxi
ロジカル・スタンバイ・データベース固有の新機能
Oracle Database のリリース 9.2 で初めてリリースされたロジカル・スタンバイ・データベー
スは、今回のリリースで拡張され、ローリング・アップグレードの使用、利便性および管理
性全般の改善、障害時リカバリ機能の拡張およびロジカル・スタンバイ・データベースの作
成手順の単純化が導入されています。次のリストに、Oracle Database 10g のロジカル・スタ
ンバイ・データベースの新機能を示します。
■
停止時間 0（ゼロ）でのインスタンス化
（ゼロ）でのインスタンス化
プライマリ・データベースを停止または静止せずにロジカル・スタンバイ・データベー
スを作成できるようになりました。これには、プライマリ・データベースのオンライ
ン・バックアップを使用し、ロジカル・スタンバイ制御ファイルを作成します。
関連項目 :
■
第 4 章「ロジカル・スタンバイ・データベースの作成」
SQL Apply によるローリング・データベース・アップグレード
Oracle Database 10g の将来のパッチセット・リリースでは、ロジカル・スタンバイ・
データベースを使用してローリング・アップグレードを実行できるようになります。
ローリング・アップグレードの基礎は現在 SQL Apply テクノロジに実装されており、
Data Guard 構成内の各データベースで Oracle Database ソフトウェアをアップグレード
する際、プライマリ・データベースでの停止時間は最低限となっています。たとえば、
SQL Apply とロジカル・スタンバイ・データベースを使用して、Oracle Database ソフ
トウェアをパッチセット・リリース 10.1.0.n から次のデータベース 10.1.0.(n+1) パッチ
セット・リリースにアップグレードできます。
関連項目 : 詳細は、9-19 ページの「Oracle Database ソフトウェア・バー
ジョンのアップグレード」
、および該当する Oracle Database 10g パッチ
セット・リリースの README ファイルを参照してください。
■
最大保護モードのサポート
スタンバイ REDO ログ・ファイルがサポートされるようになったため、ロジカル・ス
タンバイ・データベースを最大保護モードで稼働している Data Guard 構成の一部とし
て含めることが可能になりました。
関連項目 :
■
5-27 ページ「データ保護モードの設定」
追加データ型のサポート
ロジカル・スタンバイ・データベースは、LONG、LONG RAW および NCLOB データ型を
サポートするようになりました。また、索引構成表にオーバーフロー・セグメントまた
は LOB 列が含まれていない場合にかぎり、索引構成表もサポートします。
関連項目 :
別」
xxxii
4-2 ページ「表のデータ型および記憶域属性のサポートの判
第I部
概要および管理
この部は、次の章で構成されています。
■
第 1 章「Oracle Data Guard の概要」
■
第 2 章「Data Guard スタート・ガイド」
■
第 3 章「フィジカル・スタンバイ・データベースの作成」
■
第 4 章「ロジカル・スタンバイ・データベースの作成」
■
第 5 章「ログ転送サービス」
■
第 6 章「ログ適用サービス」
■
第 7 章「ロール管理」
■
第 8 章「フィジカル・スタンバイ・データベースの管理」
■
第 9 章「ロジカル・スタンバイ・データベースの管理」
■
第 10 章「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 のメリットの要約
Oracle Data Guard の概要
1-1
Data Guard 構成
Data Guard 構成
Data Guard 構成には、1
つの本番データベースと 1 つ以上のスタンバイ・データベースが
構成
含まれます。Data Guard 構成のデータベースは、Oracle Net で接続され、地理的に分散し
ている場合があります。データベースの配置場所に制限はありませんが、相互に通信できる
必要があります。たとえば、1 個のスタンバイ・データベースを本番データベースと同じシ
ステム上に配置し、2 個のスタンバイ・データベースをリモート位置の別のシステム上に配
置できます。
プライマリ・データベースとスタンバイ・データベースは、SQL コマンドライン・インタ
フェースまたは Data Guard Broker インタフェースを使用して管理できます。Data Guard
Broker インタフェースには、コマンドライン・インタフェース（DGMGRL）や、Oracle
Enterprise Manager に統合されたグラフィカル・ユーザー・インタフェースなどがありま
す。
プライマリ・データベース
Data Guard 構成には、1 個の本番データベースが含まれています。これはプライマリ・デー
タベースとも呼ばれ、プライマリ・ロールで機能します。アプリケーションは主としてこの
データベースにアクセスします。
プライマリ・データベースは、シングル・インスタンスの Oracle データベースまたは
Oracle Real Application Clusters データベースのいずれかです。
スタンバイ・データベース
スタンバイ・データベースは、プライマリ・データベースのトランザクション一貫性のある
コピーです。プライマリ・データベースのバックアップ・コピーを使用すると、最大 9 個の
スタンバイ・データベースを作成して、Data Guard 構成に組み込むことができます。スタン
バイ・データベースが作成されると、Data Guard では、プライマリ・データベースからス
タンバイ・データベースに REDO データを転送し、スタンバイ・データベースに REDO を
適用することによって、各スタンバイ・データベースを自動的にメンテナンスします。
プライマリ・データベースと同様、スタンバイ・データベースは、シングル・インスタンス
の Oracle データベースまたは Oracle Real Application Clusters データベースのいずれかで
す。
スタンバイ・データベースは、次のフィジカル・スタンバイ・データベースまたはロジカ
ル・スタンバイ・データベースのいずれかです。
■
フィジカル・スタンバイ・データベース
プライマリ・データベースと物理的に同一になるようコピーしたものです。ディスク上
のデータベース構造は、ブロック単位でプライマリ・データベースと同一です。索引な
どのデータベース・スキーマも同一です。フィジカル・スタンバイ・データベースで
は、プライマリ・データベースから受信した REDO データをリカバリすることによっ
て、プライマリ・データベースとの同期を維持します。
1-2　Oracle Data Guard 概要および管理
Data Guard 構成
■
ロジカル・スタンバイ・データベース
本番データベースと同じ論理情報が格納されますが、データの物理的な構成と構造は異
なる場合があります。ロジカル・スタンバイ・データベースでは、プライマリ・データ
ベースから受信した REDO データを SQL 文に変換し、スタンバイ・データベース上で
その SQL 文を実行することによって、プライマリ・データベースとの同期を維持しま
す。ロジカル・スタンバイ・データベースは、障害時リカバリ要件に加えて、その他の
ビジネス用途にも使用できます。このため、ロジカル・スタンバイ・データベースに
は、問合せやレポート生成の目的でいつでもアクセスできます。また、ロジカル・スタ
ンバイ・データベースを使用すると、ほとんどの場合、データベースを停止することな
く、Oracle Database ソフトウェアやパッチ・セットをアップグレードできます。つま
り、ロジカル・スタンバイ・データベースは、データ保護、レポート生成およびデータ
ベースのアップグレードに同時に使用できます。
構成例
図 1-1 は、REDO データをフィジカル・スタンバイ・データベースに転送するプライマリ・
データベース・インスタンスが含まれている一般的な Data Guard 構成を示しています。
フィジカル・スタンバイ・データベースは、障害時リカバリ操作とバックアップ操作に備え
て、プライマリ・データベース・インスタンスから離れた位置に配置されます。スタンバ
イ・データベースはプライマリ・データベースと同じ位置にも構成できます。ただし、障害
時リカバリに使用する場合は、スタンバイ・データベースを離れた位置に構成することをお
薦めします。
図 1-1 は、アーカイブ REDO ログ・ファイルをフィジカル・スタンバイ・データベースに適
用する一般的な Data Guard 構成を示しています。
図 1-1 一般的な Data Guard 構成
Oracle Data Guard の概要
1-3
Data Guard サービス
Data Guard サービス
次の各項では、Data Guard による REDO データの転送、REDO データの適用およびデータ
ベース・ロールの変更の管理方法について説明します。
■
ログ転送サービス
本番データベースから 1 つ以上のアーカイブ先に対する REDO データの自動転送を制
御します。
■
ログ適用サービス
REDO データをスタンバイ・データベースに適用し、プライマリ・データベースとのト
ランザクションの同期を維持します。REDO データは、アーカイブ REDO ログ・ファイ
ルから適用できます。また、リアルタイム適用が可能な場合は、スタンバイ・データ
ベースで最初に REDO データをアーカイブしなくても、いっぱいになったときにスタ
ンバイ REDO ログ・ファイルから直接適用することもできます。
■
ロール管理サービス
データベースのロールを、スイッチオーバー操作またはフェイルオーバー操作を使用し
て、スタンバイ・データベースからプライマリ・データベースに、またはプライマリ・
データベースからスタンバイ・データベースに変更します。
ログ転送サービス
ログ転送サービスは、本番データベースから
1 つ以上のアーカイブ先に対する REDO デー
ログ転送サービス
タの自動転送を制御します。
ログ転送サービスでは、次のタスクを実行します。
■
■
■
■
REDO データを構成内のプライマリ・システムからスタンバイ・システムに転送しま
す。
ネットワーク障害により発生したアーカイブ REDO ログ・ファイル内のギャップを解決
するプロセスを管理します。
データベース保護モード（
「Data Guard 保護モード」を参照）を施行します。
スタンバイ・システム上の欠落または破損しているアーカイブ REDO ログ・ファイルを
自動的に検出し、プライマリ・データベースまたは別のスタンバイ・データベースから
かわりのアーカイブ REDO ログ・ファイルを自動的に取得します。
1-4　Oracle Data Guard 概要および管理
Data Guard サービス
ログ適用サービス
プライマリ・データベースから転送された REDO データは、スタンバイ・システム上でス
タンバイ REDO ログ・ファイルに書き込まれ（そのように構成されている場合）、アーカイ
ブ REDO ログ・ファイルにアーカイブされます。ログ適用サービスは、アーカイブ
REDO
ログ適用サービス
データをスタンバイ・データベースに自動的に適用し、プライマリ・データベースとの一貫
性を維持します。データを読取り専用にすることも可能です。
フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの主な相違
点は、ログ適用サービスによるアーカイブ REDO データの適用方法にあります。
■
フィジカル・スタンバイ・データベースの場合、Data Guard では REDO Apply テクノ
ロジを使用します。このテクノロジでは、図 1-2 に示すように、Oracle データベースの
標準リカバリ技法を使用して REDO データがスタンバイ・データベースに適用されま
す。
図 1-2 フィジカル・スタンバイ・データベースの自動更新
■
ロジカル・スタンバイ・データベースの場合、Data Guard では SQL Apply テクノロジ
を使用します。このテクノロジでは、図 1-3 に示すように、まず、受信した REDO デー
タが SQL 文に変換されてから、生成された SQL 文がロジカル・スタンバイ・データ
ベース上で実行されます。
Oracle Data Guard の概要
1-5
Data Guard サービス
図 1-3 ロジカル・スタンバイ・データベースの自動更新
ロール管理サービス
Oracle データベースは、プライマリ・ロールまたはスタンバイ・ロールのいずれかで実行さ
れます。Data Guard では、スイッチオーバー操作またはフェイルオーバー操作のいずれか
を使用してデータベースのロールを変更できます。このロールを制御するサービスは、ロー
ロー
ル管理サービスと呼ばれます。
ル管理サービス
スイッチオーバーとは、プライマリ・データベースとそのスタンバイ・データベースの
1つ
スイッチオーバー
との間でロールを可逆的に推移させる操作です。スイッチオーバーにより、データ消失のな
い状態が保証されます。この操作は通常、プライマリ・システムの計画的なメンテナンスに
対して実行します。スイッチオーバー時には、プライマリ・データベースがスタンバイ・
ロールに、あるいはスタンバイ・データベースがプライマリ・ロールに推移します。推移
は、いずれのデータベースも再作成せずに実行されます。
フェイルオーバーは、プライマリ・データベースが使用不可能な場合に発生します。
フェイ
フェイルオーバー
ルオーバーは、プライマリ・データベースで災害などの障害が起きたときのみに実行され、
スタンバイ・データベースをプライマリ・ロールに不可逆的（復元不能）に推移させます。
データベース管理者は、データが消失しないように、Data Guard を構成できます。
1-6　Oracle Data Guard 概要および管理
Data Guard Broker
Data Guard Broker
Data Guard Broker は分散管理フレームワークで、Data Guard 構成の作成、メンテナンスお
よび監視を自動化および集中化します。Oracle Enterprise Manager のグラフィカル・ユー
ザー・インタフェース（GUI）またはコマンドライン・インタフェース（CLI）を使用する
と、次の操作が自動化および単純化されます。
■
ログ転送サービスやログ適用サービスの設定など、Data Guard 構成の作成と有効化
■
構成内の任意のシステムによる Data Guard 構成全体の管理
■
Real Application Clusters のプライマリ・データベースまたはスタンバイ・データベー
スが含まれる Data Guard 構成の管理と監視
さらに、Oracle Enterprise Manager GUI を使用すると、次の操作が自動化および単純化され
ます。
■
■
■
プライマリ・データベースのバックアップ・コピーからのフィジカル・スタンバイ・
データベースまたはロジカル・スタンバイ・データベースの作成
Data Guard 構成への新規または既存のスタンバイ・データベースの追加
ログ適用レートの監視、診断情報の獲得、および集中化した監視ツール、テスト・ツー
ル、パフォーマンス・ツールなどを使用した問題の早期検出
Oracle Enterprise Manager の使用
Oracle Enterprise Manager（以下 Enterprise Manager と呼びます）は、Data Guard 構成内
のプライマリ・データベースおよびスタンバイ・データベースを表示、監視および管理する
ための、Web ベースのインタフェースを提供します。Enterprise Manager の使いやすいイン
タフェースと、Broker による Data Guard 構成の集中化された管理および監視を組み合せる
ことで、企業内の高可用性、サイト保護およびデータ保護を実現するための Data Guard ソ
リューションが強化されます。図 1-4 は、Enterprise Manager の Data Guard 管理概要ペー
ジを示しています。
Oracle Data Guard の概要
1-7
Data Guard Broker
図 1-4 Oracle Enterprise Manager の Data Guard 概要ページ
Enterprise Manager Grid Console から、すべての管理操作をローカルまたはリモートで実行
できます。プライマリ・データベースとスタンバイ・データベース、およびプライマリ・イ
ンスタンスとスタンバイ・インスタンスを含む、Oracle データベースのホーム・ページの表
示、既存のスタンバイ・データベースの作成または追加、インスタンスの開始および停止、
インスタンスのパフォーマンスの監視、イベントの表示、ジョブのスケジュール、バック
アップ操作およびリカバリ操作の実行が可能です。『Oracle Data Guard Broker』および
Oracle Enterprise Manager のオンライン・ヘルプを参照してください。
1-8　Oracle Data Guard 概要および管理
Data Guard 保護モード
Data Guard コマンドライン・インタフェースの使用
Data Guard の CLI を使用すると、CLI プロンプト（DGMGRL）またはスクリプト内から
Data Guard 構成を制御および監視できます。CLI を使用すると、構成でデータベースを管
理および監視するために必要なアクティビティのほとんどを実行できます。CLI のリファレ
ンスの詳細と例は、
『Oracle Data Guard Broker』を参照してください。
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 データを作成する
トランザクションのコミットメントについて非同期で書き込まれます。
Oracle Data Guard の概要
1-9
Data Guard と補完テクノロジ
十分な帯域幅を持つネットワーク・リンクが使用される場合、このモードは、プライマリ・
データベースのパフォーマンスに対する影響を最小限にして、最大可用性モードのレベルに
近いデータ保護レベルを提供します。
最大保護モードおよび最大可用性モードでは、構成内の少なくとも 1 つのスタンバイ・デー
タベースに、スタンバイ REDO ログを構成する必要があります。3 つの保護モードはいずれ
も、REDO データが少なくとも 1 つのスタンバイ・データベースに送信されるよう、LOG_
ARCHIVE_DEST_n 初期化パラメータで特定のログ転送属性を指定する必要があります。
データ保護モードの詳細は、5-27 ページの「データ保護モードの設定」を参照してくださ
い。
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 の統合の詳細は、付録 B「Data Guard および Real Application Clusters」および
『Oracle 高可用性アーキテクチャおよびベスト・プラクティス』を参照してください。
1-10　Oracle Data Guard 概要および管理
Data Guard と補完テクノロジ
■
フラッシュバック・データベース
フラッシュバック・データベース機能により、論理データの破損やユーザー・エラーか
ら迅速にリカバリできます。適切なときにフラッシュバックを許可することで、誤って
変更または削除された可能性のある以前のバージョンのビジネス情報に再度アクセスで
きるようになります。この機能により、次のことが実現します。
–
バックアップをリストアして、エラーや破損が発生した時点までロールフォワード
変更を行う必要がなくなります。かわりに、フラッシュバック・データベースでは、
データ・ファイルをリストアせずに、以前の時点まで Oracle データベースをロー
ルバックできます。
–
REDO の適用を遅延してユーザー・エラーや論理的な破損から保護するための、代
替手段を提供します。したがって、スタンバイ・データベースは、プライマリ・
データベースとより密接に同期できるため、フェイルオーバーおよびスイッチオー
バーの回数が少なくなります。
–
フェイルオーバー後に、元のプライマリ・データベースを完全に作成しなおす必要
がなくなります。障害が発生したプライマリ・データベースを、フェイルオーバー
前の時点にフラッシュ・バックして、新しいプライマリ・データベースのスタンバ
イ・データベースになるように変換できます。
フラッシュバック・データベースの詳細は『Oracle Database バックアップおよびリカ
バリ・アドバンスト・ユーザーズ・ガイド』を、REDO データの適用を遅延させる方法
は 6-5 ページの「アーカイブ REDO ログ・ファイルの適用に対するタイム・ディレイの
指定」を参照してください。
■
Recovery Manager
Recovery Manager は、データベース・ファイルのバックアップ、リストアおよびリカ
バリを単純化する Oracle ユーティリティです。Data Guard と同様に、Recovery
Manager は Oracle データベースの機能の 1 つであるため、個別にインストールする必
要はありません。Data Guard と Recovery Manager は密接に統合されているため、次の
ことが実現されます。
–
Recovery Manager の DUPLICATE コマンドを使用して、プライマリ・データベー
スのバックアップからスタンバイ・データベースを作成できます。
–
本番データベースではなくフィジカル・スタンバイ・データベースからバックアッ
プを取得して、本番データベースの負荷を軽減し、スタンバイ・サイトのシステ
ム・リソースを効率的に使用できます。また、フィジカル・スタンバイ・データ
ベースが REDO を適用しているときに、バックアップを取得することもできます。
–
バックアップの実行後、入力に使用されたアーカイブ REDO ログ・ファイルを自
動的に削除することで、アーカイブ REDO ログ・ファイルの管理を容易にします。
付録 D「Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成」
および『Oracle Database バックアップおよびリカバリ基礎』を参照してください。
Oracle Data Guard の概要
1-11
Data Guard のメリットの要約
Data Guard のメリットの要約
Data Guard には次のようなメリットがあります。
■
障害時リカバリ、データ保護および高可用性
Data Guard は、効率のよい包括的な障害時リカバリおよび高可用性ソリューションを
提供します。管理が容易なスイッチオーバー機能とフェイルオーバー機能を使用する
と、プライマリ・データベースとスタンバイ・データベース間でロールを可逆的に推移
できるため、計画的および計画外の停止によるプライマリ・データベースの停止時間が
最小限になります。
■
完全なデータ保護
スタンバイ・データベースを使用することで、予期しない障害が発生した場合でもデー
タが消失しないことが保証されます。スタンバイ・データベースには、データの破損や
ユーザーのミスに対する保護対策が用意されています。プライマリ・データベースの記
憶域レベルの物理破損は、スタンバイ・データベースに伝播されません。同様に、プラ
イマリ・データベースの完全な破損の原因となった論理的な破損やユーザーのミスも解
決できます。最後に、REDO データが、スタンバイ・データベースへの適用時に検証さ
れます。
■
システム・リソースの効率的な使用
プライマリ・データベースから受信した REDO データで更新されたスタンバイ・デー
タベース表は、バックアップ、レポート生成、要約および問合せなどの他のタスクにも
使用できます。したがって、これらのタスクの実行に必要なプライマリ・データベース
のワークロードを低減し、貴重な CPU と I/O のサイクルを節約できます。ロジカル・
スタンバイ・データベースを使用すると、プライマリ・データベースに基づいて更新さ
れていないスキーマ内の各表で通常のデータ操作を実行できます。ロジカル・スタンバ
イ・データベースは、表をプライマリ・データベースから更新する間、オープン状態の
ままにしておくことができるため、表は読取り専用アクセスに同時に使用できます。最
後に、メンテナンスされている表に追加の索引やマテリアライズド・ビューを作成する
ことによって、問合せパフォーマンスを改善し、特定のビジネス要件を満たすことがで
きます。
■
可用性とパフォーマンス要件とのバランスを保つことができるデータ保護の柔軟性
Oracle Data Guard には、各企業がデータ可用性とシステム・パフォーマンス要件との
バランスを保つことができるように、最大保護、最大可用性および最大パフォーマンス
の 3 つのモードが用意されています。
■
ギャップの自動検出と自動解消
ネットワークの問題などで、プライマリ・データベースと 1 つ以上のスタンバイ・デー
タベースとの間の接続が失われた場合、プライマリ・データベース上に生成される
REDO データは、宛先のスタンバイ・データベースに送信されません。接続が再度確立
された時点で、Data Guard によって、欠落しているアーカイブ REDO ログ・ファイル
（ギャップと呼ばれます）が自動的に検出され、それらのファイルがスタンバイ・デー
1-12　Oracle Data Guard 概要および管理
Data Guard のメリットの要約
タベースに自動的に転送されます。スタンバイ・データベースはプライマリ・データ
ベースと同期化されるため、DBA による手動操作は不要です。
■
集中化された単純な管理
Data Guard Broker は、グラフィカル・ユーザー・インタフェースとコマンドライン・
インタフェースを提供し、Data Guard 構成の複数のデータベース全体の管理タスクと
操作タスクを自動化します。また、ブローカは、単一の Data Guard 構成内のすべての
システムを監視します。
■
Oracle Database との統合
Data Guard では Oracle Database Enterprise Edition の機能の 1 つであるため、個別に
インストールする必要はありません。
Oracle Data Guard の概要
1-13
Data Guard のメリットの要約
1-14　Oracle Data Guard 概要および管理
2
Data Guard スタート・ガイド
Data Guard 構成には、1 つのプライマリ・データベースと、それに対応付けられた最大 9 個
のスタンバイ・データベースが含まれます。この章では、Data Guard の使用を開始するた
めの次の考慮事項について説明します。
■
スタンバイ・データベースのタイプ
■
Data Guard 構成の管理のためのユーザー・インタフェース
■
Data Guard の動作要件
■
スタンバイ・データベースのディレクトリ構造に関する考慮事項
■
オンライン REDO ログ、アーカイブ REDO ログおよびスタンバイ REDO ログ
Data Guard スタート・ガイド
2-1
スタンバイ・データベースのタイプ
スタンバイ・データベースのタイプ
スタンバイ・データベースは、Oracle
本番データベースのトランザクション一貫性のあるコ
スタンバイ・データベース
ピーで、最初はプライマリ・データベースのバックアップ・コピーから作成されます。スタ
ンバイ・データベースが作成および構成されると、Data Guard は、プライマリ・データ
ベースの REDO データをスタンバイ・システムに転送し、スタンバイ・データベースに適
用することによって、スタンバイ・データベースを自動的にメンテナンスします。
スタンバイ・データベースには、フィジカル・スタンバイ・データベース
フィジカル・スタンバイ・データベースとロジカル・スタ
フィジカル・スタンバイ・データベース ロジカル・スタ
ンバイ・データベースの
ンバイ・データベース 2 つのタイプがあります。いずれのタイプのスタンバイ・データ
ベースも、必要に応じてプライマリ・データベースのロールを引き継ぎ、本番処理を継続で
きます。Data Guard 構成には、フィジカル・スタンバイ・データベース、ロジカル・スタ
ンバイ・データベース、または両方のタイプの組合せを含めることができます。
次の各項では、スタンバイ・データベースを詳細に説明します。ビジネスに最適なタイプを
決定するために役立つ情報は、
『Oracle 高可用性アーキテクチャおよびベスト・プラクティ
ス』を参照してください。
フィジカル・スタンバイ・データベース
フィジカル・スタンバイ・データベースは、プライマリ・データベースと物理的に同一で、
フィジカル・スタンバイ・データベース
ディスク上のデータベース構造は、ブロック単位でプライマリ・データベースと同一です。
索引などのデータベース・スキーマも同一です。
Data Guard では、REDO Apply を実行することによって、フィジカル・スタンバイ・デー
タベースのメンテナンスが行われます。リカバリが実行されていないときは、フィジカル・
スタンバイ・データベースを読取り専用モードでオープンできます。
■
REDO Apply
フィジカル・スタンバイ・データベースは、Oracle リカバリ・メカニズムを使用して、
スタンバイ・システムでアーカイブ REDO ログ・ファイルの REDO データを適用する
か、またはスタンバイ REDO ログ・ファイルを直接適用することによってメンテナン
スされます。リカバリ操作では、データ・ブロック・アドレスを使用してブロックごと
に変更が適用されます。REDO の適用中、データベースはオープンできません。
■
読取り専用オープン
フィジカル・スタンバイ・データベースは読取り専用モードでオープンできるため、
データベース上で問合せを実行できます。読取り専用モードでオープンしている間、ス
タンバイ・データベースは REDO データの受信を継続できますが、ログ・ファイルか
らの REDO データの適用は、データベースで REDO Apply が再開されるまで遅延され
ます。
フィジカル・スタンバイ・データベースでは、REDO Apply と読取り専用モードのオープン
を同時に実行することはできませんが、これらの操作を切り替えることはできます。たとえ
ば、フィジカル・スタンバイ・データベースで REDO Apply を実行し、次にアプリケー
ションでレポートが実行できるようにデータベースを読取り専用モードでオープンした後、
2-2　Oracle Data Guard 概要および管理
スタンバイ・データベースのタイプ
データベースを元に戻して REDO Apply を実行し、未処理のアーカイブ REDO ログ・ファ
イルを適用できます。このサイクルを繰り返し、REDO Apply と読取り専用操作を適宜実行
できます。
いずれの場合も、フィジカル・スタンバイ・データベースはバックアップの実行に使用でき
ます。さらに、フィジカル・スタンバイ・データベースは、アーカイブ REDO ログ・ファイ
ルまたはスタンバイ REDO ログ・ファイルがその時点で適用されない場合でも、REDO
データの受信を継続します。
フィジカル・スタンバイ・データベースのメリット
フィジカル・スタンバイ・データベースには次のメリットがあります。
■
障害時リカバリと高可用性
フィジカル・スタンバイ・データベースによって、堅牢で効率的な障害時リカバリと可
用性の高いソリューションを実現できます。管理が容易なスイッチオーバー機能とフェ
イルオーバー機能を使用すると、プライマリ・データベースとフィジカル・スタンバ
イ・データベース間でロールを可逆的に推移できるため、計画的および計画外の停止に
よるプライマリ・データベースの停止時間が最小限になります。
■
データ保護
フィジカル・スタンバイ・データベースを使用することで、予期しない障害が発生した
場合でもデータが消失しないことが保証されます。フィジカル・スタンバイ・データ
ベースでは、プライマリ・データベースでサポートされるすべてのデータ型、および
DDL 操作と DML 操作がサポートされます。また、データの破損やユーザーのミスに対
する保護対策も用意されています。プライマリ・データベースの記憶域レベルの物理破
損は、スタンバイ・データベースに伝播されません。同様に、プライマリ・データベー
スの完全な破損の原因となった論理的な破損やユーザーのミスも解決できます。最後
に、REDO データが、スタンバイ・データベースへの適用時に検証されます。
■
プライマリ・データベースのワークロードの低減
Oracle Recovery Manager は、フィジカル・スタンバイ・データベースを使用してプラ
イマリ・データベースからバックアップをオフロードし、貴重な CPU と I/O のサイク
ルを節約できます。フィジカル・スタンバイ・データベースを読取り専用モードでオー
プンすると、レポート生成および問合せを実行することもできます。
■
パフォーマンス
フィジカル・スタンバイ・データベースで使用される REDO Apply テクノロジは、低
レベルのリカバリ・メカニズムを使用して変更を適用します。このメカニズムは、SQL
レベルのコード・レイヤーをすべてバイパスするため、変更の適用に関しては最も効率
的です。このため、REDO Apply テクノロジは、データベース間で変更を伝播する効率
的なメカニズムです。
Data Guard スタート・ガイド
2-3
スタンバイ・データベースのタイプ
ロジカル・スタンバイ・データベース
ロジカル・スタンバイ・データベースは、最初はプライマリ・データベースと同じ内容のコ
ロジカル・スタンバイ・データベース
ピーで作成されますが、後で異なる構造に変更できます。ロジカル・スタンバイ・データ
ベースは、SQL 文を実行して更新されます。これにより、ユーザーは問合せとレポート生成
の目的で、スタンバイ・データベースにいつでもアクセスできます。このように、ロジカ
ル・スタンバイ・データベースは、データ保護操作とレポート生成操作に同時に使用できま
す。
Data Guard は、ログ・ファイルのデータを SQL 文に変換し、ロジカル・スタンバイ・デー
タベースでその SQL 文を実行することによって、アーカイブ REDO ログ・ファイルまたは
スタンバイ REDO ログ・ファイルの情報をロジカル・スタンバイ・データベースに自動的
に適用します。ロジカル・スタンバイ・データベースは SQL 文を使用して更新されるため、
オープン状態のままであることが必要です。ロジカル・スタンバイ・データベースは読取り
/ 書込みモードでオープンされますが、再生成された SQL に対するターゲット表は、読取り
専用操作用にのみ使用可能です。更新中、これらの表は、レポート生成、要約、問合せなど
の他のタスクで同時に使用できます。さらに、これらのタスクは、メンテナンスされている
表に追加の索引やマテリアライズド・ビューを作成することによって最適化できます。
ロジカル・スタンバイ・データベースには、データ型、表のタイプおよび DDL 操作や DML
操作のタイプに関していくつかの制限があります。サポートされないデータ型および表の記
憶域属性は、4-2 ページの「表のデータ型および記憶域属性のサポートの判別」で説明して
います。
ロジカル・スタンバイ・データベースのメリット
ロジカル・スタンバイ・データベースには、フィジカル・スタンバイ・データベースと同様
の障害時リカバリ、高可用性およびデータ保護のメリットがあります。その他に、次のメ
リットもあります。
■
スタンバイ・ハードウェア資源の効率的な使用
ロジカル・スタンバイ・データベースは、障害時リカバリ要件に加えて、その他のビジ
ネス用途にも使用できます。Data Guard 構成内で保護されているデータベース・スキー
マ以外に別のデータベース・スキーマをホスティングできるため、ユーザーは、これら
のスキーマ上で通常の DDL 操作または DML 操作をいつでも実行できます。Data
Guard で保護されているロジカル・スタンバイ表は、プライマリ・データベースとは異
なる物理的なレイアウトで格納できるため、追加の索引やマテリアライズド・ビューを
作成して、問合せのパフォーマンスを改善したり、特定のビジネス要件にあわせること
ができます。
■
プライマリ・データベースのワークロードの低減
ロジカル・スタンバイ・データベースは、その表をプライマリ・データベースから更新
するとき、オープン状態のままにしておくことができるため、これらの表は読取りアク
セスに同時に使用できます。このことによって、ロジカル・スタンバイ・データベース
は、問合せ、要約およびレポート生成の各アクティビティを実行する際の優れたデータ
ベースとなり、これらのタスクからプライマリ・データベースがオフロードされ、貴重
な CPU と I/O のサイクルが節約されます。
2-4　Oracle Data Guard 概要および管理
Data Guard 構成の管理のためのユーザー・インタフェース
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 文にはスタンバイ固有の構文はありません
が、スタンバイ・データベースで操作を実行するときに役立ちます。関連する文のリス
トは、第 13 章を参照してください。
–
初期化パラメータ
Data Guard 環境の定義には、いくつかの初期化パラメータが使用されます。関連する初
期化パラメータのリストは、第 11 章を参照してください。
■
Data Guard Broker コマンドライン・インタフェース
Data Guard Broker のコマンドライン・インタフェースは、Enterprise Manager の GUI
の代替手段です。コマンドライン・インタフェースは、ブローカを使用してバッチ・プ
ログラムまたはスクリプトから Data Guard 構成を管理する場合に役立ちます。詳細は、
『Oracle Data Guard Broker』を参照してください。
Data Guard スタート・ガイド
2-5
Data Guard の動作要件
Data Guard の動作要件
次の各項で、Data Guard 使用時の動作要件を説明します。
■
ハードウェアおよびオペレーティング・システムの要件
■
Oracle ソフトウェア要件
ハードウェアおよびオペレーティング・システムの要件
次のリストに、Data Guard 使用時のハードウェアおよびオペレーティング・システムの要
件を示します。
■
プライマリ・ロケーションとスタンバイ・ロケーションのオペレーティング・システム
およびプラットフォームのアーキテクチャは同じであることが必要です。
たとえば、32 ビットの Solaris システムにプライマリ・データベースが存在している
Data Guard 構成の場合、そのスタンバイ・データベースは 32 ビットの Solaris システ
ムに構成されている必要があります。同様に、64 ビットの HP-UX システムに存在する
プライマリ・データベースは、64 ビットの HP-UX システム上にあるスタンバイ・デー
タベースとともに構成される必要があり、32 ビットの Intel システムの Linux に存在す
るプライマリ・データベースは、32 ビットの Intel システムの Linux 上にあるスタンバ
イ・データベースとともに構成されている必要があり、その他の場合も同様です。
■
ハードウェア（CPU の数、メモリー・サイズ、記憶域構成など）は、プライマリ・シス
テムとスタンバイ・システムで異なっていても構いません。
スタンバイ・システムがプライマリ・システムより小規模な場合は、スイッチオーバー
またはフェイルオーバー後にスタンバイ・システムで実行可能な作業を制限する必要が
あります。スタンバイ・システムには、プライマリ・データベースからすべての REDO
データを受信して適用するための十分なリソースが必要です。ロジカル・スタンバイ・
データベースには、REDO データを SQL 文に変換し、その SQL をロジカル・スタンバ
イ・データベースで実行するための追加のリソースが必要です。
■
プライマリ・ロケーションとスタンバイ・ロケーションのオペレーティング・システム
は同じであることが必要ですが、同じリリースである必要はありません。また、スタン
バイ・データベースではプライマリ・データベースと異なるディレクトリ構造を使用で
きます。
2-6　Oracle Data Guard 概要および管理
Data Guard の動作要件
Oracle ソフトウェア要件
次のリストに、Data Guard 使用時の Oracle ソフトウェア要件を示します。
■
Oracle Data Guard は、Oracle Database Enterprise Edition の機能としてのみ提供されて
います。Oracle Database Standard Edition には付属していません。したがって、Data
Guard 構成のプライマリ・データベースおよびすべてのスタンバイ・データベースに、
同じリリースの Oracle Database Enterprise Edition がインストールされている必要があ
ります。
注意 : Oracle Database Standard Edition を実行しているデータベースで
スタンバイ・データベース環境を再現することが可能です。これを行うに
は、オペレーティング・システムのコピー・ユーティリティ、または定期
的にアーカイブ REDO ログ・ファイルをデータベースからデータベース
に送信するカスタム・スクリプトを使用して、手動でアーカイブ REDO
ログ・ファイルを転送します。したがって、この構成では、Data Guard に
よって提供される利便性、管理性、パフォーマンスおよび障害時リカバリ
機能を得られません。
Data Guard SQL Apply を使用して、Oracle Database ソフトウェアをパッチセット・リ
リース 10.1.0.n から次のデータベース 10.1.0.(n+1) パッチセット・リリースにローリン
グ・アップグレードできます。ローリング・アップグレード時には、プライマリおよび
ロジカル・スタンバイ・データベースを 1 つずつアップグレードする間、異なるリリー
スの Oracle Database（10.1.0.1 以上）を実行できます。詳細は、9-19 ページの「アーカ
イブ REDO ログ・ファイルの適用に対するタイム・ディレイの指定」、および該当する
Oracle Database 10g パッチセット・リリースの README ファイルを参照してくださ
い。
■
■
■
■
現在 Oracle8i データベース・ソフトウェア上で Oracle Data Guard を実行している場合、
Oracle Data Guard をアップグレードする場合の詳細は、
『Oracle Database アップグ
レード・ガイド』を参照してください。
プライマリ・データベースは ARCHIVELOG モードで実行する必要があります。
プライマリ・データベースは、シングル・インスタンス・データベースまたは複数イン
スタンスの Real Application Clusters データベースです。スタンバイ・データベースは、
シングル・インスタンス・データベースまたは複数インスタンスの Real Application
Clusters（RAC）データベースで、フィジカル・タイプとロジカル・タイプを組み合せ
ることができます。Oracle Data Guard を RAC とともに構成および使用する方法につい
ては、
『Oracle 高可用性アーキテクチャおよびベスト・プラクティス』を参照してくだ
さい。
プライマリ・データベースとスタンバイ・データベースには、それぞれ独自の制御ファ
イルが必要です。
Data Guard スタート・ガイド
2-7
Data Guard の動作要件
■
■
■
■
スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、ス
タンバイ・データベースのアーカイブ・ディレクトリは、プライマリ・データベースと
は異なるディレクトリ構造を使用する必要があります。同じ構造を使用すると、スタン
バイ・データベースがプライマリ・データベース・ファイルを上書きする可能性があり
ます。
プライマリ・データベースに対して、ログに記録されず、スタンバイ・データベースに
伝播できないダイレクト書込みが行われるのを防ぐには、プライマリ・データベースで
FORCE LOGGING をオンにした後で、スタンバイ作成用にデータ・ファイルのバック
アップを実行します。スタンバイ・データベースが必要な間は、データベースを FORCE
LOGGING モードに保持してください。
プライマリ・データベースとスタンバイ・データベースのインスタンスの管理に使用す
るユーザー・アカウントには、SYSDBA システム権限が必要です。
Oracle Automatic Storage Management（ASM）および Oracle Managed Files（OMF）
を Data Guard 構成でセットアップする際、プライマリおよびスタンバイ・データベー
スに対称的にセットアップすることをお薦めします。つまり、Data Guard 構成のいずれ
かのデータベースで ASM、OMF、またはその両方を使用する場合、構成内のすべての
データベースでもそれぞれ ASM、OMF またはその両方を使用する必要があります。詳
細は、10-51 ページの「OMF または ASM を使用するスタンバイ・データベースの作
成」の使用例を参照してください。
注意 : 更新の際に時間ベースのデータが使用される一部のアプリケー
ションでは、複数のタイムゾーンで入力されたデータを処理できないた
め、ロールの推移後もレコードの時間的順序が維持されるよう、プライマ
リおよびリモート・スタンバイ・システムに同じタイムゾーンを設定する
ことをお薦めします。
2-8　Oracle Data Guard 概要および管理
スタンバイ・データベースのディレクトリ構造に関する考慮事項
スタンバイ・データベースのディレクトリ構造に関する考慮事項
各種スタンバイ・データベースのディレクトリ構造によってスタンバイ・データ・ファイ
ル、アーカイブ 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 のセットアップ方法を説明する使用例は、第 10 章を参照してく
ださい。
Data Guard スタート・ガイド
2-9
スタンバイ・データベースのディレクトリ構造に関する考慮事項
図 2-1 可能なスタンバイ構成
表 2-1 で、プライマリ・データベースとスタンバイ・データベースの可能な構成、およびそ
れぞれの結果的な注意事項について説明します。表内で、サービス名のデフォルトはグロー
バル・データベース名です。グローバル・データベース名は、データベース名（DB_NAME）
とドメイン名（DB_DOMAIN）パラメータを連結したものです。プライマリ・データベースと
スタンバイ・データベースが同じシステムに常駐し、一意のサービス名を明示的に指定しな
い場合、プライマリ・データベースとスタンバイ・データベースの両方で同じデフォルトの
グローバル・データベース名が適用されます。
2-10　Oracle Data Guard 概要および管理
スタンバイ・データベースのディレクトリ構造に関する考慮事項
表 2-1 スタンバイ・データベースの位置とディレクトリ・オプション
スタン
バイ・
システム
プライマ
リ・シス
テムと
同じ
ディレクトリ
構造
プライマリ・
システムと異
なる（必須）
結果的な注意事項
■
■
■
■
離れた
システム
プライマリ・
システムと
同じ
■
■
離れた
システム
プライマリ・
システムと異
なる
■
■
DB_UNIQUE_NAME 初期化パラメータを設定する必要がありま
す。
スタンバイ・データベース制御ファイル内のプライマリ・デー
タベースのデータ・ファイル、アーカイブ REDO ログ・ファ
イルおよびスタンバイ REDO ログ・ファイルのパス名を自動
的に更新するには、ファイル名を手動で変更するか、スタンバ
イ・データベースで DB_FILE_NAME_CONVERT 初期化パラ
メータと LOG_FILE_NAME_CONVERT 初期化パラメータを設
定します。
（3-3 ページの「プライマリ・データベースの初期
化パラメータの設定」を参照。
）
SERVICE_NAMES 初期化パラメータを使用して、プライマリ・
データベースおよびスタンバイ・データベースの一意のサービ
ス名を明示的に設定する必要があります。
スタンバイ・データベースは、プライマリ・データベースとス
タンバイ・データベースが存在しているシステムを破壊するよ
うな障害に対する保護には役立ちませんが、計画的なメンテナ
ンスに対するスイッチオーバー機能は提供します。
スタンバイ・データベース制御ファイル内のプライマリ・デー
タベースのファイル名、アーカイブ REDO ログ・ファイルお
よびスタンバイ REDO ログ・ファイル名を変更する必要はあ
りません。ただし、新しいネーミング計画が必要な場合（複数
のディスクにファイルを分散する場合など）は、変更しても構
いません。
スタンバイ・データベースを別の物理メディアに置くことによ
り、プライマリ・システムを破壊するような障害からプライマ
リ・データベースのデータを保護できます。
ファイル名を手動で変更するか、またはスタンバイ・データ
ベースで DB_FILE_NAME_CONVERT 初期化パラメータおよび
LOG_FILE_NAME_CONVERT 初期化パラメータを設定し、デー
タ・ファイル名を自動的に変更できます（3-3 ページの「プラ
イマリ・データベースの初期化パラメータの設定」を参照）。
スタンバイ・データベースを別の物理メディアに置くことによ
り、プライマリ・システムを破壊するような障害からプライマ
リ・データベースのデータを保護できます。
Data Guard スタート・ガイド
2-11
オンライン REDO ログ、アーカイブ REDO ログおよびスタンバイ REDO ログ
オンライン REDO ログ、アーカイブ REDO ログおよびスタンバイ
REDO ログ
Data Guard リカバリ操作の最も重要な構造は、オンライン REDO ログ、アーカイブ REDO
ログおよびスタンバイ REDO ログです。プライマリ・データベースから転送された REDO
データは、スタンバイ・システムのリモート・ファイル・サーバー（RFS）プロセスによっ
て受信されます。RFS プロセスは、この REDO データをアーカイブ・ログ・ファイルまたは
スタンバイ REDO ログ・ファイルのいずれかに書き込みます。REDO データは、REDO が
アーカイブ REDO ログ・ファイルまたはスタンバイ REDO ログ・ファイルに書き込まれた
後、もしくはリアルタイム適用が使用可能になっている場合は、いっぱいになったスタンバ
イ REDO ログ・ファイルから直接、適用できます。
このマニュアルでは、オンライン REDO ログおよびアーカイブ REDO ログの概要を理解し
ていることを前提としています。
「オンライン REDO ログおよびアーカイブ REDO ログ」で
は、Data Guard 構成固有の情報を説明することにより、基本概念を強化しています。「スタ
ンバイ REDO ログ」では、スタンバイ REDO ログ・ファイルの使用方法の詳細を説明して
います。
REDO ログおよびアーカイブ・ログの詳細は、『Oracle Database 管理者ガイド』を参照して
ください。リアルタイム適用の詳細は、6-3 ページの「リアルタイム適用による REDO デー
タの即時適用」を参照してください。
オンライン REDO ログおよびアーカイブ REDO ログ
Data Guard 環境では、オンライン REDO ログおよびアーカイブ REDO ログの両方が必要で
す。
■
オンライン REDO ログ
インスタンス障害の際にデータベースを保護するために、Oracle プライマリ・データ
ベースおよびロジカル・スタンバイ・データベースのすべてのインスタンスには、関連
付けられたオンライン REDO ログが存在します。フィジカル・スタンバイ・データベー
スは読取り / 書込み I/O のためにオープンされることがなく、データベースが変更され
ず、REDO データが生成されないため、フィジカル・スタンバイ・データベースには関
連付けられたオンライン REDO ログが存在しません。
■
アーカイブ REDO ログ
スタンバイ・データベースとプライマリ・データベースのトランザクション一貫性を維
持するためにアーカイブが使用されるため、アーカイブ REDO ログは必須です。プライ
マリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタン
バイ・データベースには、それぞれアーカイブ REDO ログが存在します。Oracle データ
ベースは、デフォルトで、ARCHIVELOG モードで稼働するよう設定されています。こ
れにより、いっぱいになった各オンライン REDO ログ・ファイルが、アーカイバ
（ARCn）プロセスによって自動的に 1 つ以上のアーカイブ REDO ログ・ファイルにコ
ピーされます。
2-12　Oracle Data Guard 概要および管理
オンライン REDO ログ、アーカイブ REDO ログおよびスタンバイ REDO ログ
プライマリ・サイトでのアーカイブ REDO ログ・ファイルの生成には、オンライン REDO
ログ・ファイルのサイズとログ・スイッチの発生頻度の両方が影響します。『Oracle 高可用
性アーキテクチャおよびベスト・プラクティス』では、ログ・グループのサイズ決定の際の
推奨事項を説明しています。
Oracle データベースは各ログ・スイッチでチェックポイントを試行します。したがって、オ
ンライン REDO ログ・ファイルのサイズが小さすぎる場合は、ログ・スイッチの発生頻度
が高いために、チェックポイントの発生頻度も高くなり、スタンバイ・データベースのシス
テム・パフォーマンスに悪影響を及ぼします。
スタンバイ REDO ログ
スタンバイ REDO ログは全体的にオンライン REDO ログと類似していますが、スタンバイ
REDO ログの場合、プライマリ・データベースから受信した REDO データを格納するスタ
ンバイ・ロールで稼働しているデータベースでのみ使用される点が異なります。
次のものを実装するには、スタンバイ REDO ログが必要です。
■
データ保護の最大保護および最大可用性レベル（1-9 ページの「Data Guard 保護モー
ド」
、および詳細を 5-27 ページの「データ保護モードの設定」で説明）
■
リアルタイム適用（6-3 ページの「ログ適用サービスの構成オプション」で説明）
■
カスケードされた REDO ログ宛先（付録 C で説明）
Data Guard 構成では、すべてのスタンバイ・データベースでスタンバイ REDO ログ・ファ
イルを構成することをお薦めします。次の利点があるためです。
■
■
■
■
スタンバイ REDO ログは事前割当て済ファイルで構成されるため、スタンバイ REDO ロ
グを使用すると、順次ファイル（アーカイブ・ログなど）によく見られるファイル・シ
ステムのメタデータ更新というオペレーティング・システムのオーバーヘッドを回避で
きます。
スタンバイ REDO ログ・ファイルは RAW デバイスに常駐可能です。プライマリおよび
スタンバイ・データベースの一方または両方が Real Application Clusters 環境に常駐す
る場合、この点が重要になります。
スタンバイ REDO ログ・ファイルは、複数のメンバーを使用して多重化可能で、これに
よってアーカイブ・ログ・ファイルの信頼性が向上します。
フェイルオーバー時には、Data Guard はアーカイブ・ログ・ファイルのみに比べ、ス
タンバイ REDO ログ・ファイルからより多くの REDO データをリカバリおよび適用で
きます。
Data Guard スタート・ガイド
2-13
オンライン REDO ログ、アーカイブ REDO ログおよびスタンバイ REDO ログ
■
プライマリ・データベース上のアーカイバ（ARCn）プロセスまたはログ・ライター
（LGWR）プロセスは、リモート・スタンバイ REDO ログ・ファイルに直接 REDO デー
タを転送でき、これによって部分的にアーカイブ・ログ・ファイルを登録する必要がな
くなります（たとえば、スタンバイ・データベースのクラッシュ後のリカバリ時）
。詳
細は、第 5 章を参照してください。
5-29 ページの「スタンバイ REDO ログ・ファイルの構成」では、スタンバイ REDO ログ・
ファイルの構成手順を説明します。
2-14　Oracle Data Guard 概要および管理
3
フィジカル・スタンバイ・データベースの作成
この章では、フィジカル・スタンバイ・データベースを作成する手順について説明します。
この章は、次の主な項目で構成されています。
■
スタンバイ・データベースを作成するためのプライマリ・データベースの準備
■
フィジカル・スタンバイ・データベースの作成
■
その他の準備
この章で説明する手順では、スタンバイ・データベースが最大パフォーマンス・モードで構
成されます。このモードは、デフォルトのデータ保護モードです。別のデータ保護モードの
構成については、第 5 章を参照してください。また、この章の説明は、テキストの初期化パ
ラメータ・ファイル（PFILE）ではなく、サーバー・パラメータ・ファイル（SPFILE）に初
期化パラメータを指定することを前提としています。
関連項目 :
■
■
サーバー・パラメータ・ファイルの作成方法と使用方法については、
『Oracle Database 管理者ガイド』を参照してください。
グラフィカル・ユーザー・インタフェースを使用してフィジカル・ス
タンバイ・データベースを自動的に作成する方法については、
『Oracle Data Guard Broker』および Enterprise Manager のオンライ
ン・ヘルプを参照してください。
フィジカル・スタンバイ・データベースの作成
3-1
スタンバイ・データベースを作成するためのプライマリ・データベースの準備
スタンバイ・データベースを作成するためのプライマリ・
データベースの準備
スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されて
いることを確認する必要があります。
表 3-1 は、フィジカル・スタンバイ・データベースを作成するための準備としてプライマ
リ・データベースで実行するタスクのチェックリストです。各タスクを詳細に説明している
参照先の項も記載されています。
表 3-1 フィジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備
参照先
タスク
3-3 ページ
強制ロギングの有効化
3-3 ページ
パスワード・ファイルの作成
3-3 ページ
プライマリ・データベースの初期化パラメータの設定
3-7 ページ
アーカイブの有効化
注意 : これらの準備のためのタスクは、1 回のみ実行してください。これ
らの手順を完了すると、データベースは、1 つ以上のスタンバイ・データ
ベースに対するプライマリ・データベースとして機能する準備が整いま
す。
3-2　Oracle Data Guard 概要および管理
スタンバイ・データベースを作成するためのプライマリ・データベースの準備
強制ロギングの有効化
データベースの作成後、次の SQL 文を使用して、プライマリ・データベースを FORCE
LOGGING モードにします。
SQL> ALTER DATABASE FORCE LOGGING;
この文は、完了までに非常に時間がかかる場合があります。これは、ログに記録されないダ
イレクト書込み I/O がすべて完了するまで待機するためです。
パスワード・ファイルの作成
パスワード・ファイルが存在しない場合は、作成します。Data Guard 構成内のすべてのデー
タベースにパスワード・ファイルが必要です。また、SYS ユーザーのパスワードは、REDO
データを正常に転送するために、すべてのシステムで同じである必要があります。『Oracle
Database 管理者ガイド』を参照してください。
プライマリ・データベースの初期化パラメータの設定
プライマリ・データベースでは、データベースがプライマリ・ロールで動作している間のロ
グ転送サービスを制御する初期化パラメータを定義します。また、プライマリ・データベー
スがスタンバイ・ロールに推移したときに REDO データの受信とログ適用サービスを制御
するパラメータを追加する必要があります。
例 3-1 に、プライマリ・データベースでメンテナンスする、プライマリ・ロールの初期化パ
ラメータを示します。この例は、シカゴにプライマリ・データベースがあり、ボストンに
フィジカル・スタンバイ・データベースが 1 つある Data Guard 構成を示しています。例 3-1
に示すパラメータは、シカゴのデータベースがプライマリ・データベース・ロールまたはス
タンバイ・データベース・ロールで実行されている場合に有効です。この構成例では、次の
表に示す名前を使用しています。
データベース
DB_UNIQUE_NAME
Oracle Net サービス名
プライマリ
chicago
chicago
フィジカル・スタンバイ
boston
boston
フィジカル・スタンバイ・データベースの作成
3-3
スタンバイ・データベースを作成するためのプライマリ・データベースの準備
例 3-1 プライマリ・データベース : プライマリ・ロールの初期化パラメータ
DB_NAME=chicago
DB_UNIQUE_NAME=chicago
SERVICE_NAMES=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=boston
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
これらのパラメータは、ログ転送サービスが REDO データをスタンバイ・システムに転送
する方法と、ローカル・ファイル・システムでの REDO データのアーカイブ処理を制御し
ます。この例では、REDO データの転送に ARCn プロセス（デフォルト）を使用することを
前提としています。ローカルとリモートの両方の宛先に REDO データを転送する LGWR プ
ロセスを指定する場合は、LOG_ARCHIVE_DEST_2 初期化パラメータに NET_TIMEOUT 属性
（第 12 章を参照）も含めます。
例 3-2 に、プライマリ・データベースで定義するスタンバイ・ロールの追加の初期化パラ
メータを示します。これらのパラメータは、プライマリ・データベースがスタンバイ・ロー
ルに推移すると有効になります。
例 3-2 プライマリ・データベース : スタンバイ・ロールの初期化パラメータ
FAL_SERVER=boston
FAL_CLIENT=chicago
DB_FILE_NAME_CONVERT=
'/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/'
LOG_FILE_NAME_CONVERT=
'/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/'
STANDBY_FILE_MANAGEMENT=AUTO
例 3-2 に示す初期化パラメータを指定すると、プライマリ・データベースはギャップを解決
して新しいプライマリ・データベースからの新規データ・ファイルとログ・ファイルのパス
名を変換するように設定され、このデータベースがスタンバイ・ロールで動作している間は
着信 REDO データがアーカイブされます。説明に従ってプライマリおよびスタンバイ・ロー
ルについて初期化パラメータを設定した場合、ロールの推移後に変更が必要なパラメータは
ありません。
3-4　Oracle Data Guard 概要および管理
スタンバイ・データベースを作成するためのプライマリ・データベースの準備
次の表に、例 3-1 および 3-2 に示した各パラメータ設定に関する簡単な説明を示します。
パラメータ
推奨する設定
DB_NAME
8 文字の名前を指定します。すべてのスタンバイ・データベースに同じ名前を使
用してください。
DB_UNIQUE_NAME
各データベースの一意の名前を指定します。この名前はデータベースと固定さ
れ、プライマリ・データベースとスタンバイ・データベースのロールが逆になっ
ても変更されません。
SERVICE_NAMES
このスタンバイ・データベースのサービス名として、プライマリ・データベース
のサービス名とは異なる一意の名前を指定します。プライマリ・データベースと
スタンバイ・データベースが同じシステム上にある場合に、一意のサービス名を
明示的に指定しないと、両方のデータベースで同じデフォルト・グローバル名
（データベース名の DB_NAME およびドメイン名の DB_DOMAIN パラメータで構
成）が有効になります。
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-1 は、2
つの制御ファイルのパス名を指定する方法を示しています。不良制御ファイルの
位置に正常な制御ファイルをコピーした後でインスタンスを簡単に再起動できる
ように、制御ファイルの第 2 コピーを使用可能にしておくことをお薦めします。
LOG_ARCHIVE_DEST_n
REDO データがアーカイブされるプライマリ・システムおよびスタンバイ・シス
テムの位置を指定します。例 3-1 では、次のようになっています。
■
■
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-7 ページの「フラッシュ・リカバリ領域を宛先とした設定」を参照してくださ
い。また、LOG_ARCHIVE_DEST_n の詳細は、第 12 章を参照してください。
フィジカル・スタンバイ・データベースの作成
3-5
スタンバイ・データベースを作成するためのプライマリ・データベースの準備
パラメータ
推奨する設定
LOG_ARCHIVE_DEST_STATE_n
ログ転送サービスが REDO データを指定した宛先に転送するのを許可するには、
ENABLE を指定します。
REMOTE_LOGIN_PASSWORDFILE
プライマリ・データベースとスタンバイ・データベースの両方で、SYS に同じパ
スワードを設定します。推奨する設定は、EXCLUSIVE または SHARED です。
LOG_ARCHIVE_FORMAT
スレッド（%t）、順序番号（%s）およびリセットログ ID（%r）を使用して、
アーカイブ REDO ログ・ファイルのフォーマットを指定します。もう 1 つの例に
ついては、5-34 ページの「アーカイブ REDO ログ・ファイルの代替ディレクト
リ位置の指定」を参照してください。
FAL_SERVER
FAL サーバー（通常はプライマリ・ロールで実行中のデータベース）の Oracle
Net サービス名を指定します。シカゴのデータベースがスタンバイ・ロールで実
行されている場合、ボストンのデータベースが欠落しているログ・ファイルを自
動的に送信できなければ、ボストンのデータベースが FAL サーバーとして使用
され、そこから欠落しているアーカイブ REDO ログ・ファイルがフェッチ（要
求）されます。5-40 ページの「アーカイブ・ギャップの管理」を参照してくださ
い。
FAL_CLIENT
シカゴのデータベースの Oracle Net サービス名を指定します。FAL サーバー（ボ
ストン）は、欠落しているアーカイブ REDO ログ・ファイルをシカゴのスタン
バイ・データベースにコピーします。5-40 ページの「アーカイブ・ギャップの管
理」を参照してください。
DB_FILE_NAME_CONVERT
プライマリ・データベースのデータ・ファイルのパス名とファイル名の位置を指
定し、その後にスタンバイの位置を指定します。このパラメータにより、プライ
マリ・データベースのデータ・ファイルのパス名がスタンバイ・データ・ファイ
ルのパス名に変換されます。スタンバイ・データベースがプライマリ・データ
ベースと同じシステムにある場合、またはデータ・ファイルが格納されているス
タンバイ・サイトのディレクトリ構造がプライマリ・サイトと異なる場合は、こ
のパラメータが必要です。このパラメータは、フィジカル・スタンバイ・データ
ベースのパス名の変換にのみ使用されることに注意してください。
LOG_FILE_NAME_CONVERT
プライマリ・データベースのオンライン REDO ログ・ファイルの位置を指定し、
その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・
データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に
変換されます。スタンバイ・データベースがプライマリ・データベースと同じシ
ステムにある場合、またはログ・ファイルが格納されているスタンバイ・システ
ムのディレクトリ構造がプライマリ・システムと異なる場合は、このパラメータ
が必要です。
STANDBY_FILE_MANAGEMENT
データ・ファイルがプライマリ・データベースに追加または削除された場合に、
それに対応してスタンバイ・データベースも自動的に変更されるように、AUTO
に設定します。
3-6　Oracle Data Guard 概要および管理
スタンバイ・データベースを作成するためのプライマリ・データベースの準備
注意 : 変更の必要性がある他のパラメータについては、初期化パラメー
タ・ファイルを調べてください。たとえば、ダンプ出力先パラメータ
（BACKGROUND_DUMP_DEST、CORE_DUMP_DEST、USER_DUMP_DEST）の
変更が必要な場合があります。これは、スタンバイ・データベースのディ
レクトリ位置がプライマリ・データベースで指定したディレクトリ位置と
異なる場合に必要です。さらに、スタンバイ・システムにまだ存在してい
ないディレクトリがある場合は、そのディレクトリを作成する必要があり
ます。
アーカイブの有効化
アーカイブが有効になっていない場合は、次の文を発行して、プライマリ・データベースを
ARCHIVELOG モードにし、自動アーカイブを有効にします。
SQL>
SQL>
SQL>
SQL>
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
アーカイブについては、
『Oracle Database 管理者ガイド』を参照してください。
フィジカル・スタンバイ・データベースの作成
3-7
フィジカル・スタンバイ・データベースの作成
フィジカル・スタンバイ・データベースの作成
この項では、フィジカル・スタンバイ・データベースの作成で実行するタスクについて説明
します。
表 3-2 は、フィジカル・スタンバイ・データベースの作成で実行するタスク、および各タス
クを実行するデータベースのチェックリストです。各タスクを詳細に説明している参照先の
項も記載されています。
表 3-2 フィジカル・スタンバイ・データベースの作成
参照先
タスク
データベース
3-8 ページ
プライマリ・データベース・データ・ファイルのバックアップ・コピーの作成
プライマリ
3-9 ページ
スタンバイ・データベース用の制御ファイルの作成
プライマリ
3-9 ページ
スタンバイ・データベース用の初期化パラメータ・ファイルの準備
プライマリ
3-13 ページ
プライマリ・システムからスタンバイ・システムへのファイルのコピー
プライマリ
3-13 ページ
スタンバイ・データベースをサポートする環境の設定
スタンバイ
3-15 ページ
フィジカル・スタンバイ・データベースの起動
スタンバイ
3-17 ページ
フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認
スタンバイ
プライマリ・データベース・データ・ファイルのバックアップ・コピーの
作成
データベースを完全にリカバリするのに必要なアーカイブ REDO ログ・ファイルがあるか
ぎり、プライマリ・データベースのバックアップ・コピーを使用して、フィジカル・スタン
バイ・データベースを作成できます。Recovery Manager（RMAN）ユーティリティを使用す
ることをお薦めします。
バックアップの推奨事項は『Oracle 高可用性アーキテクチャおよびベスト・プラクティス』
を、RMAN バックアップ操作の実行方法については『Oracle Database バックアップおよび
リカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。
3-8　Oracle Data Guard 概要および管理
フィジカル・スタンバイ・データベースの作成
スタンバイ・データベース用の制御ファイルの作成
バックアップ処理のために、プライマリ・データベースを停止する必要がある場合は、次の
SQL*Plus 文を発行して、プライマリ・データベースを起動します。
SQL> STARTUP MOUNT;
スタンバイ・データベース用の制御ファイルを作成してから、ユーザー・アクセス用にプラ
イマリ・データベースをオープンします。次に例を示します。
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/boston.ctl';
SQL> ALTER DATABASE OPEN;
注意 : プライマリ・データベースとスタンバイ・データベースの両方に
単一の制御ファイルを使用することはできません。
スタンバイ・データベース用の初期化パラメータ・ファイルの準備
次の手順を実行して、スタンバイの初期化パラメータ・ファイルを作成します。
手順 1 スタンバイ・データベースにプライマリ・データベース・パラメータ・ファイルを
コピーする
プライマリ・データベースで使用されているサーバー・パラメータ・ファイル（SPFILE）か
ら、テキストの初期化パラメータ・ファイル（PFILE）を作成します。テキストの初期化パ
ラメータ・ファイルは、スタンバイの位置にコピーして変更できます。次に例を示します。
SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;
このファイルを変更して、フィジカル・スタンバイ・データベースでの使用に適したパラ
メータ値を含めます。このファイルは、後述の「スタンバイ・データベースをサポートする
環境の設定」で、サーバー・パラメータ・ファイルに変換し直します。
手順 2 フィジカル・スタンバイ・データベースで初期化パラメータを設定する
プライマリ・システムからコピーしたテキストの初期化パラメータ・ファイルの初期化パラ
メータ設定の多くは、フィジカル・スタンバイ・データベースにも適していますが、一部を
変更する必要があります。
例 3-3 は、スタンバイの初期化パラメータ・ファイルの一部です。この中の値は、フィジカ
ル・スタンバイ・データベース用に変更されています。例 3-1 および例 3-2 と異なるパラ
メータ値は、太字で示されています。例 3-3 に示すパラメータは、ボストンのデータベース
がプライマリ・データベース・ロールまたはスタンバイ・データベース・ロールで実行され
ている場合に有効です。
フィジカル・スタンバイ・データベースの作成
3-9
フィジカル・スタンバイ・データベースの作成
例 3-3 フィジカル・スタンバイ・データベース用の初期化パラメータの変更
.
.
.
DB_NAME=chicago
DB_UNIQUE_NAME=boston
SERVICE_NAMES=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl'
DB_FILE_NAME_CONVERT=
'/arch1/chicago/','/arch1/boston/','/arch2/chicago/','/arch2/boston/'
LOG_FILE_NAME_CONVERT=
'/arch1/chicago/','/arch1/boston/','/arch2/chicago/','/arch2/boston/'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/boston/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2=
'SERVICE=chicago
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
STANDBY_FILE_MANAGEMENT=AUTO
INSTANCE_NAME=boston
FAL_SERVER=chicago
FAL_CLIENT=boston
.
.
.
この例では、REDO データの転送に ARCn プロセス（デフォルト）を使用することを前提と
しています。ローカルとリモートの両方の宛先に REDO データを転送する LGWR プロセス
を指定する場合は、LOG_ARCHIVE_DEST_2 初期化パラメータに NET_TIMEOUT 属性（第
12 章を参照）も含めます。
また、プライマリ・データベースとスタンバイ・データベースでは、COMPATIBLE 初期化パ
ラメータを同じ値に設定する必要があります。値が異なる場合は、ログ転送サービスが
REDO データをプライマリ・データベースからスタンバイ・データベースに転送できないこ
とがあります。Data Guard 構成では、COMPATIBLE を少なくとも 9.2.0.1.0 に設定する必要
があります。ただし、Oracle Database 10g の新機能を利用する場合は、COMPATIBLE パラ
メータを 10.1.0.0 以上に設定します。
SHOW PARAMETERS コマンドを使用して、他に変更を必要とするパラメータがないかどうか
を確認することをお薦めします。
3-10　Oracle Data Guard 概要および管理
フィジカル・スタンバイ・データベースの作成
次の表に、例 3-3 のうち、プライマリ・データベースの設定と異なるパラメータ設定に関す
る簡単な説明を示します。
パラメータ
推奨する設定
DB_UNIQUE_NAME
このデータベースの一意の名前を指定します。この名前はデータベースと固定さ
れ、プライマリ・データベースとスタンバイ・データベースのロールが逆になっ
ても変更されません。
SERVICE_NAMES
このスタンバイ・データベースのサービス名として、プライマリ・データベース
のサービス名とは異なる一意の名前を指定します。プライマリ・データベースと
スタンバイ・データベースが同じシステム上にある場合に、一意のサービス名を
明示的に指定しないと、両方のデータベースで同じデフォルト・グローバル名
（データベース名の DB_NAME およびドメイン名の DB_DOMAIN パラメータで構
成）が有効になります。
CONTROL_FILES
スタンバイ・データベースの制御ファイルのパス名を指定します。例 3-3 は、2
つの制御ファイルのパス名を指定する方法を示しています。不良制御ファイルの
位置に正常な制御ファイルをコピーした後でインスタンスを簡単に再起動できる
ように、制御ファイルの第 2 コピーを使用可能にしておくことをお薦めします。
DB_FILE_NAME_CONVERT
プライマリ・データベースのデータ・ファイルのパス名とファイル名の位置を指
定し、その後にスタンバイの位置を指定します。このパラメータにより、プライ
マリ・データベースのデータ・ファイルのパス名がスタンバイ・データ・ファイ
ルのパス名に変換されます。スタンバイ・データベースがプライマリ・データ
ベースと同じシステムにある場合、またはデータ・ファイルが格納されているス
タンバイ・サイトのディレクトリ構造がプライマリ・サイトと異なる場合は、こ
のパラメータが必要です。
LOG_FILE_NAME_CONVERT
プライマリ・データベースのオンライン REDO ログ・ファイルの位置を指定し、
その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・
データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に
変換されます。スタンバイ・データベースがプライマリ・データベースと同じシ
ステムにある場合、またはログ・ファイルが格納されているスタンバイ・システ
ムのディレクトリ構造がプライマリ・システムと異なる場合は、このパラメータ
が必要です。
フィジカル・スタンバイ・データベースの作成
3-11
フィジカル・スタンバイ・データベースの作成
パラメータ
推奨する設定
LOG_ARCHIVE_DEST_n
REDO データのアーカイブ先を指定します。例 3-3 では、次のようになっていま
す。
■
■
LOG_ARCHIVE_DEST_1 を指定すると、プライマリ・データから受信した
REDO データは /arch1/boston/ のアーカイブ REDO ログ・ファイルに
アーカイブされます。
LOG_ARCHIVE_DEST_2 はプライマリ・ロールのみに有効であるため、この
宛先は現在は無視されます。スイッチオーバーが発生して、このインスタン
スがプライマリ・データベースになる場合は、REDO データがリモートの
シカゴの宛先に転送されます。
注意 : フラッシュ・リカバリ領域を（DB_RECOVERY_FILE_DEST 初期化パラ
メータを使用して）構成しており、LOCATION 属性でローカル・アーカイブ先を
明示的に構成していない場合は、デフォルトのローカル・アーカイブ先として
LOG_ARCHIVE_DEST_10 初期化パラメータが自動的に使用されます。詳細は、
5-7 ページの「フラッシュ・リカバリ領域を宛先とした設定」を参照してくださ
い。また、LOG_ARCHIVE_DEST_n の詳細は、第 12 章を参照してください。
INSTANCE_NAME
プライマリ・データベースとスタンバイ・データベースが同じシステムに存在す
るときに、スタンバイ・データベースに対してプライマリ・データベースとは異
なる値を指定します。
FAL_SERVER
FAL サーバー（通常はプライマリ・ロールで実行中のデータベース）の Oracle
Net サービス名を指定します。ボストンのデータベースがスタンバイ・ロールで
実行されている場合、シカゴのデータベースが欠落しているログ・ファイルを自
動的に送信できなければ、シカゴのデータベースが FAL サーバーとして使用さ
れ、そこから欠落しているアーカイブ REDO ログ・ファイルがフェッチ（要求）
されます。5-40 ページの「アーカイブ・ギャップの管理」を参照してください。
FAL_CLIENT
ボストンのデータベースの Oracle Net サービス名を指定します。FAL サーバー
（シカゴ）は、欠落しているアーカイブ REDO ログ・ファイルをボストンのスタ
ンバイ・データベースにコピーします。5-40 ページの「アーカイブ・ギャップの
管理」を参照してください。
注意 : 変更の必要性がある他のパラメータについては、初期化パラメー
タ・ファイルを調べてください。たとえば、ダンプ出力先パラメータ
（BACKGROUND_DUMP_DEST、CORE_DUMP_DEST、USER_DUMP_DEST）の
変更が必要な場合があります。これは、スタンバイ・データベースのディ
レクトリ位置がプライマリ・データベースで指定したディレクトリ位置と
異なる場合に必要です。さらに、スタンバイ・システムにまだ存在してい
ないディレクトリがある場合は、そのディレクトリを作成する必要があり
ます。
3-12　Oracle Data Guard 概要および管理
フィジカル・スタンバイ・データベースの作成
プライマリ・システムからスタンバイ・システムへのファイルのコピー
オペレーティング・システムのコピー・ユーティリティを使用して、次のバイナリ・ファイ
ルをプライマリ・システムからスタンバイ・システムにコピーします。
■
■
■
「プライマリ・データベース・データ・ファイルのバックアップ・コピーの作成」で作
成したバックアップ・データ・ファイル
「スタンバイ・データベース用の制御ファイルの作成」で作成したスタンバイ制御ファ
イル
「スタンバイ・データベース用の初期化パラメータ・ファイルの準備」で作成した初期
化パラメータ・ファイル
スタンバイ・データベースをサポートする環境の設定
次の手順を実行して、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 Net Services 管理者ガイド』を参照してください。
フィジカル・スタンバイ・データベースの作成
3-13
フィジカル・スタンバイ・データベースの作成
手順 4 スタンバイ・システムで中断された接続の検出を有効化する
スタンバイ・システムの SQLNET.ORA パラメータ・ファイルで SQLNET.EXPIRE_TIME パ
ラメータを 2（分）に設定して、中断された接続の検出を使用可能にします。次に例を示し
ます。
SQLNET.EXPIRE_TIME=2
『Oracle Net Services 管理者ガイド』を参照してください。
手順 5 Oracle Net サービス名を作成する
プライマリ・システムとスタンバイ・システムの両方で、Oracle Net Manager を使用して、
プライマリ・データベースとスタンバイ・データベースのネットワーク・サービス名を作成
します。ネットワーク・サービス名はログ転送サービスで使用されます。
Oracle Net ネット・サービス名は、プライマリ・データベースとスタンバイ・データベース
に対するリスナーの構成時に指定したのと同じプロトコル、ホスト・アドレス、ポートおよ
び SID を使用する接続記述子に解析される必要があります。この接続記述子は、専用サー
バーが使用されるように指定する必要もあります。『Oracle Net Services 管理者ガイド』お
よび『Oracle Database 管理者ガイド』を参照してください。
手順 6 スタンバイ・データベース用のサーバー・パラメータ・ファイルを作成する
フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースに即時に
推移する場合は（第 4 章「ロジカル・スタンバイ・データベースの作成」を参照）
、この手
順をスキップして「フィジカル・スタンバイ・データベースの起動」の指示に進みます。
アイドル状態のスタンバイ・データベースで、SQL の CREATE 文を使用して、3-9 ページの
手順 2 で編集したテキストの初期化パラメータ・ファイルから、スタンバイ・データベース
用のサーバー・パラメータ・ファイルを作成します。次に例を示します。
SQL> CREATE SPFILE FROM PFILE='initboston.ora';
3-14　Oracle Data Guard 概要および管理
フィジカル・スタンバイ・データベースの作成
フィジカル・スタンバイ・データベースの起動
フィジカル・スタンバイ・データベースおよび REDO Apply を起動するには、次の手順を
実行します。
手順 1 フィジカル・スタンバイ・データベースを起動する
スタンバイ・データベースで、次の SQL 文を発行して、データベースを読取り専用モード
で起動し、マウントします。
SQL> STARTUP OPEN READ ONLY;
データベースをオープンしないでください。データベースはユーザー・アクセスに対してク
ローズしたままにする必要があります。また、フィジカル・スタンバイ・データベースは、
REDO データを受信するためにマウントされている（または読取り専用モードでオープンし
ている）必要があります。
手順 2 フィジカル・スタンバイ・データベースに対する新規一時ファイルを作成する
フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースに即時に
推移する場合は（第 4 章「ロジカル・スタンバイ・データベースの作成」を参照）
、この手
順をスキップして手順 3 の指示に進みます。
フィジカル・スタンバイ・データベース上では、後でではなくこの時点で新規一時ファイル
を作成しておくと便利です。一時ファイルにより、データベースが読取り専用モードでオー
プンしているときにディスクをソートし、将来のロールの推移に備えてデータベースを準備
できます。
フィジカル・スタンバイ・データベースに一時ファイルを追加するには、次のタスクを実行
します。
1.
一時ファイルを格納する表領域を識別します。これを実行するには、スタンバイ・デー
タベースで次のコマンドを入力します。
SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES
2> WHERE CONTENTS = 'TEMPORARY';
TABLESPACE_NAME
-------------------------------TEMP1
TEMP2
2.
スタンバイ・データベースに新しい一時ファイルを追加します。
前の問合せで識別された表領域ごとに、スタンバイ・データベースに新しい一時ファイ
ルを追加します。次の例は、プライマリ・データベースの一時ファイルと一致するサイ
ズおよび再利用の特性を使用して、TEMP1 という名前の新しい一時ファイルを追加しま
す。
フィジカル・スタンバイ・データベースの作成
3-15
フィジカル・スタンバイ・データベースの作成
SQL> ALTER TABLESPACE TEMP1 ADD TEMPFILE
2> '/arch1/boston/temp01.dbf'
3> SIZE 40M REUSE;
注意 : プライマリ・データベースの一時ファイルと一致する一時ファイ
ルをフィジカル・スタンバイ・データベースで作成するには、プライマ
リ・データベースの V$TEMPFILE ビューを問い合せて、プライマリ・
データベースの一時ファイルの詳細を取得します。
手順 3 REDO Apply を開始する
スタンバイ・データベースで、次のコマンドを発行して REDO Apply を開始します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
この文は、データベースを自動的にマウントします。また、この文には DISCONNECT FROM
SESSION オプションが指定されているため、REDO Apply はバックグラウンド・セッショ
ンで実行されます。詳細は、6-7 ページの「REDO データのフィジカル・スタンバイ・デー
タベースへの適用」を参照してください。
手順 4 フィジカル・スタンバイ・データベースへのアーカイブ操作をテストする
リモート・スタンバイ・ロケーションへの REDO データの転送は、ログ・スイッチ後まで
行われません。デフォルトでは、ログ・スイッチはオンライン REDO ログ・ファイルがいっ
ぱいになったときに発生します。REDO データを即時に転送するためにログ・スイッチを強
制実行するには、プライマリ・データベースで次の ALTER SYSTEM 文を使用します。次に
例を示します。
SQL> ALTER SYSTEM SWITCH LOGFILE;
3-16　Oracle Data Guard 概要および管理
フィジカル・スタンバイ・データベースの作成
フィジカル・スタンバイ・データベースが正しく実行されているかどうか
の確認
フィジカル・スタンバイ・データベースを作成し、ログ転送サービスを設定した後、データ
ベースの変更がプライマリ・データベースからスタンバイ・データベースに正常に転送され
ていることの確認が必要な場合があります。
スタンバイ・データベースで 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#
---------8
9
10
FIRST_TIME
-----------------11-JUL-02 17:50:45
11-JUL-02 17:50:53
11-JUL-02 17:50:58
NEXT_TIME
-----------------11-JUL-02 17:50:53
11-JUL-02 17:50:58
11-JUL-02 17:51:03
3 rows selected.
手順 2 ログ・スイッチを強制実行してカレント・オンライン REDO ログ・ファイルを
アーカイブする
プライマリ・データベースで、ALTER SYSTEM ARCHIVE LOG CURRENT 文を発行して、
ログ・スイッチを強制実行し、カレント・オンライン REDO ログ・ファイル・グループを
アーカイブします。
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
手順 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
フィジカル・スタンバイ・データベースの作成
3-17
フィジカル・スタンバイ・データベースの作成
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:11
4 rows selected.
アーカイブ REDO ログ・ファイルは、フィジカル・スタンバイ・データベースに適用でき
ます。
手順 4 新規アーカイブ REDO ログ・ファイルの適用を確認する
スタンバイ・データベースで、V$ARCHIVED_LOG ビューを問い合せて、アーカイブ REDO
ログ・ファイルが適用されたことを確認します。
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG
2 ORDER BY SEQUENCE#;
SEQUENCE#
--------8
9
10
11
APP
--YES
YES
YES
YES
4 rows selected.
ログ転送サービスとログ適用サービスが正常に動作しているかどうかの確認方法は、5-45
ページの「ログ・ファイル・アーカイブ情報の監視」および 6-8 ページの「フィジカル・ス
タンバイ・データベースでのログ適用サービスの監視」を参照してください。
3-18　Oracle Data Guard 概要および管理
その他の準備
その他の準備
この時点で、フィジカル・スタンバイ・データベースが実行中であり、最大パフォーマン
ス・レベルのデータ保護を提供できます。次のリストに、フィジカル・スタンバイ・データ
ベースに対して実行できるその他の準備について説明します。
■
データ保護モードのアップグレード
Data Guard 構成は、最初は最大パフォーマンス・モード（デフォルト）で設定されま
す。データ保護モードの詳細と現行の保護モードをアップグレードまたはダウングレー
ドする方法は、5-27 ページの「データ保護モードの設定」を参照してください。
■
スタンバイ REDO ログの構成
スタンバイ・データベースを最大保護モードおよび最大可用性モードで実行するには、
スタンバイ REDO ログが必要です。ただし、すべてのスタンバイ・データベースでスタ
ンバイ REDO ログを構成することをお薦めします。これは、フェイルオーバー中に、
アーカイブ REDO ログ・ファイルのみを使用する場合よりも多くの REDO データを、
スタンバイ REDO ログ・ファイルからリカバリして適用できるためです。スタンバイ
REDO ログは、プライマリ・データベースとスタンバイ・データベースの両方に同じサ
イズと名前で存在する必要があります。詳細は、5-29 ページの「スタンバイ REDO ロ
グ・ファイルの構成」を参照してください。
■
フラッシュバック・データベースの有効化
フラッシュバック・データベースを使用すると、フェイルオーバー後にプライマリ・
データベースを再作成する必要がなくなります。フラッシュバック・データベースは従
来の Point-in-Time リカバリと同様の機能で、データベースを過去の最新時点の状態に
戻すことができます。フラッシュバック・データベースでは、データ・ファイルをバッ
クアップからリストアしたり REDO データを広範囲に適用する必要がないため、
Point-in-Time リカバリよりも高速です。フラッシュバック・データベースは、プライマ
リ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できま
す。詳細は、
『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザー
ズ・ガイド』を参照してください。
フィジカル・スタンバイ・データベースの作成
3-19
その他の準備
3-20　Oracle Data Guard 概要および管理
4
ロジカル・スタンバイ・データベースの作成
この章では、ロジカル・スタンバイ・データベースを作成する手順について説明します。こ
の章は、次の主な項目で構成されています。
■
ロジカル・スタンバイ・データベースを作成するための準備
■
ロジカル・スタンバイ・データベースの作成
■
その他の準備
この章で説明する手順では、スタンバイ・データベースが最大パフォーマンス・モードで構
成されます。このモードは、デフォルトのデータ保護モードです。別のデータ保護モードの
構成については、第 5 章を参照してください。
関連項目 :
■
■
サーバー・パラメータ・ファイルの作成方法と使用方法については、
『Oracle Database 管理者ガイド』を参照してください。
グラフィカル・ユーザー・インタフェースを使用してロジカル・スタ
ンバイ・データベースを自動的に作成する方法については、
『Oracle
Data Guard Broker』および Oracle Enterprise Manager のオンライ
ン・ヘルプを参照してください。
ロジカル・スタンバイ・データベースの作成
4-1
ロジカル・スタンバイ・データベースを作成するための準備
ロジカル・スタンバイ・データベースを作成するための準備
スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されて
いることを確認する必要があります。
表 4-1 は、ロジカル・スタンバイ・データベースを作成するための準備としてプライマリ・
データベースで実行するタスクのチェックリストです。各タスクを詳細に説明している参照
先の項も記載されています。
表 4-1 ロジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備
参照先
タスク
4-2 ページ
表のデータ型および記憶域属性のサポートの判別
4-6 ページ
プライマリ・データベース内の表の行が一意に識別できることの確認
表のデータ型および記憶域属性のサポートの判別
ロジカル・スタンバイ・データベースを設定する前に、ロジカル・スタンバイ・データベー
スが、プライマリ・データベースのデータ型と表をメンテナンスできることを確認する必要
があります。
次のリストに、様々なデータベース・オブジェクトについて、ロジカル・スタンバイ・デー
タベースでサポートされるものとサポートされないものを示します。
表のサポートされるデータ型および記憶域属性
CHAR
NCHAR
VARCHAR2 および VARCHAR
NVARCHAR2
NUMBER
DATE
TIMESTAMP
TIMESTAMP WITH TIME ZONE
TIMESTAMP WITH LOCAL TIME ZONE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
RAW
CLOB（固定幅および可変幅のキャラクタ・セットを含む）
NCLOB
BLOB
LONG
LONG RAW
BINARY_FLOAT
BINARY_DOUBLE
索引構成表（オーバーフローおよび LOB 列なし）
4-2　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースを作成するための準備
サポートされないデータ型
BFILE
ROWID
UROWID
ユーザー定義型
オブジェクト型 REF
VARRAY
ネストした表
XMLType
サポートされない表、順序およびビュー
■
Oracle Database に付属するほとんどのスキーマ（SQL Apply でスキップされる）
■
サポートされないデータ型を使用した表
■
表圧縮を使用した表
スキップされるスキーマを正確に判断するには、DBA_LOGSTDBY_SKIP ビューを問い合せ
ます。
プライマリ・データベースにサポートされないオブジェクトが含まれているかどうかを判断
するには、DBA_LOGSTDBY_UNSUPPORTED ビューを問い合せます。DBA_LOGSTDBY_
UNSUPPORTED ビューの詳細は、第 14 章「Oracle Data Guard に関連するビュー」を参照し
てください。
ロジカル・スタンバイ・データベースを作成する前に、プライマリ・データベースでサポー
トされないデータベース・オブジェクトを識別することが重要です。その理由は、プライマ
リ・データベースでのサポートされないデータ型、表、順序またはビューに対する変更は、
ロジカル・スタンバイ・データベースに伝播されないためです。さらに、エラー・メッセー
ジは戻されません。
たとえば、ロジカル・スタンバイ・データベースでサポートされないプライマリ・データ
ベース表のスキーマと表名をリストするには、プライマリ・データベースで次の問合せを使
用します。
SQL> SELECT DISTINCT OWNER,TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED
2> ORDER BY OWNER,TABLE_NAME;
OWNER
----------HR
OE
OE
OE
TABLE_NAME
-------------------------COUNTRIES
ORDERS
CUSTOMERS
WAREHOUSES
ロジカル・スタンバイ・データベースの作成
4-3
ロジカル・スタンバイ・データベースを作成するための準備
前述の問合せでリストされたいずれかの表の列名とデータ型を表示するには、次のような
SELECT 文を使用します。
SQL> SELECT COLUMN_NAME,DATA_TYPE FROM DBA_LOGSTDBY_UNSUPPORTED
2> WHERE OWNER='OE' AND TABLE_NAME = 'CUSTOMERS';
COLUMN_NAME
------------------------------CUST_ADDRESS
PHONE_NUMBERS
CUST_GEO_LOCATION
DATA_TYPE
------------------CUST_ADDRESS_TYP
PHONE_LIST_TYP
SDO_GEOMETRY
プライマリ・データベースにサポートされない表が含まれている場合、REDO データをロジ
カル・スタンバイ・データベースに適用すると、ログ適用サービスによって、その表が自動
的に除外されます。
注意 : プライマリ・データベースの重要な表がロジカル・スタンバイ・
データベースでサポートされない場合は、フィジカル・スタンバイ・デー
タベースの使用を考慮することもできます。
ロジカル・スタンバイ・データベースでスキップされる SQL 文
デフォルトでは、SQL 文がプライマリ・データベースで実行された場合、次のリスト内の
SQL 文以外はすべて、ロジカル・スタンバイ・データベースに適用されます。
ALTER DATABASE
ALTER SESSION
ALTER MATERIALIZED VIEW
ALTER MATERIALIZED VIEW LOG
ALTER SYSTEM
CREATE CONTROL FILE
CREATE DATABASE
CREATE DATABASE LINK
CREATE PFILE FROM SPFILE
CREATE SCHEMA AUTHORIZATION
CREATE MATERIALIZED VIEW
CREATE MATERIALIZED VIEW LOG
CREATE SPFILE FROM PFILE
DROP DATABASE LINK
DROP MATERIALIZED VIEW
DROP MATERIALIZED VIEW LOG
EXPLAIN
LOCK TABLE
SET CONSTRAINTS
4-4　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースを作成するための準備
SET ROLE
SET TRANSACTION
サポートされるオブジェクトおよび操作
システムのメタデータやユーザー・データを変更しない、オラクル社が提供する PL/SQL
パッケージは、アーカイブ REDO ログ・ファイルにフットプリントを残さないため、プラ
イマリ・データベースで安全に使用できます。この種のパッケージの例には、DBMS_
OUTPUT、DBMS_RANDOM、DBMS_PIPE、DBMS_DESCRIBE、DBMS_OBFUSCATION_
TOOLKIT、DBMS_TRACE、DBMS_METADATA などがあります。
システムのメタデータは変更しないが、ユーザー・データを変更する場合がある、オラクル
社が提供する PL/SQL パッケージは、変更されるユーザー・データがサポートされるデータ
型のカテゴリに含まれるかぎり SQL Apply でサポートされます。この種のパッケージの例に
は、DBMS_LOB、DBMS_SQL、DBMS_TRANSACTION などがあります。
システムのメタデータを変更する、オラクル社が提供する PL/SQL パッケージは、通常、
SQL Apply ではサポートされないため、その影響はロジカル・スタンバイ・データベースで
は参照できません。この種のパッケージの例には、DBMS_JAVA、DBMS_REGISTRY、DBMS_
ALERT、DBMS_SPACE_ADMIN、DBMS_REFRESH、DBMS_SCHEDULER、DBMS_AQ などがあ
ります。
DBMS_JOB に対する特定のサポートが用意されています。ジョブの実行はロジカル・スタン
バイ・データベース上で一時停止され、スタンバイ・データベース上ではジョブを直接スケ
ジュールできません。ただし、プライマリ・データベースで発行されたジョブは、スタンバ
イ・データベースにレプリケートされます。スイッチオーバーまたはフェイルオーバーが発
生すると、元のプライマリ・データベースでスケジュールされていたジョブの実行は、新規
のプライマリ・データベースで自動的に開始されます。
オラクル社が提供する PL/SQL パッケージすべての詳細は、
『PL/SQL パッケージ・プロ
シージャおよびタイプ・リファレンス』を参照してください。
ロジカル・スタンバイ・データベースの作成
4-5
ロジカル・スタンバイ・データベースを作成するための準備
プライマリ・データベース内の表の行が一意に識別できることの確認
ロジカル・スタンバイ・データベースの ROWID はプライマリ・データベースの ROWID と
異なる可能性があるため、プライマリ・データベースで更新した行をロジカル・スタンバ
イ・データベースの対応する行と照合するために、別の方法を使用する必要があります。次
のいずれかを使用して、対応する行を照合します。
■
主キー
■
一意索引
SQL Apply で、データの更新をロジカル・スタンバイ・データベースに効率的に適用できる
ように、適切で可能な場合には、必ずプライマリ・データベースの表に主キーまたは一意索
引を追加することをお薦めします。
SQL Apply で表の行を必ず一意に識別できるようにするには、次の手順を実行してくださ
い。
手順 1 プライマリ・データベース内の一意識別子のない表を検索する
プライマリ・データベース内で NOT NULL 列に主キーまたは一意索引のない表を識別するに
は、DBA_LOGSTDBY_NOT_UNIQUE ビューを問い合せます。次の問合せでは、SQL Apply で
一意に識別できない可能性がある表のリストが表示されます。
SQL> SELECT OWNER, TABLE_NAME,BAD_COLUMN FROM DBA_LOGSTDBY_NOT_UNIQUE
2> WHERE TABLE_NAME NOT IN (SELECT TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED);
DBA_LOGSTDBY_NOT_UNIQUE ビューに表示される表の一部は、サポートされている場合も
あります。これは、サプリメンタル・ロギング
サプリメンタル・ロギング（
サプリメンタル・ロギング 「サプリメンタル・ロギングが使用可能で
あることの確認」で使用可能にします）によって、REDO データを含む行を一意に識別する
情報が追加されるためです。主キーまたは一意索引が存在するかどうかが、サプリメンタ
ル・ロギングに次のような影響を与える場合があります。
■
■
表の NOT NULL 列に主キーまたは一意索引がある場合、サプリメンタル・ロギング時に
オンライン REDO ログ・ファイルに追加される情報の量は最小限となります。
表に主キーまたは一意索引がない場合、サプリメンタル・ロギングは、各行に対するす
べてのスカラー値を自動的にオンライン REDO ログ・ファイルに記録します。
BAD_COLUMN 列の値は Y または N です。次にその内容を説明します。
■
Y
表の列が、CLOB または BLOB などのバインドされないデータ型を使用して定義されて
いることを示します。SQL Apply はこれらの表のメンテナンスを試みますが、ユーザー
は、バインドされていない列以外でアプリケーションが一意性を提供するように配慮す
る必要があります。表内の 2 つの行が、LOB 列以外で一致している場合、その表は適切
にメンテナンスできず、SQL Apply が停止します。
4-6　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースを作成するための準備
■
N
ロジカル・スタンバイ・データベース内の表をメンテナンスするための十分な列情報が
その表にあることを示します。
手順 2 無効化された RELY 主キー制約を追加する
アプリケーションで、表内の行が一意であることが保証される場合は、表に無効化された
RELY 主キー制約を作成できます。これによって、プライマリ・データベースでの主キーの
メンテナンスに関するオーバーヘッドを回避できます。ALTER TABLE 文の構文と使用情報
については、
『Oracle Database SQL リファレンス』を参照してください。
無効化された RELY 制約をプライマリ・データベース表に作成するには、RELY DISABLE
句を指定して ALTER TABLE 文を使用します。次の例では、無効化された RELY 制約が
mytab という表に作成されます。各行は、id 列と name 列を使用して一意に識別されます。
SQL> ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE;
RELY 制約は、行が一意であると仮定するようシステムに指示します。行を一意に識別する、
無効化された RELY 制約用に列を選択する場合は、注意が必要です。RELY 制約用に選択され
た列で行が一意に識別されない場合、SQL Apply は、アーカイブ REDO ログ・ファイルま
たはスタンバイ REDO ログ・ファイルからロジカル・スタンバイ・データベースへのデー
タの適用に失敗します。
SQL Apply のパフォーマンスを改善するには、ロジカル・スタンバイ・データベースで行を
一意に識別する列に索引を追加します。追加しない場合は、全表スキャンを実行する必要が
あります。
DBA_LOGSTDBY_NOT_UNIQUE ビューの詳細は『Oracle Database リファレンス』を、RELY
制約の作成方法の詳細は『Oracle Database SQL リファレンス』を、また、RELY 制約および
ロジカル・スタンバイ・データベースでのパフォーマンスを向上させるための処置について
は、9-26 ページの「ロジカル・スタンバイ・データベースのチューニング」を参照してくだ
さい。
ロジカル・スタンバイ・データベースの作成
4-7
ロジカル・スタンバイ・データベースの作成
ロジカル・スタンバイ・データベースの作成
この項では、ロジカル・スタンバイ・データベースの作成で実行するタスクについて説明し
ます。
表 4-2 は、ロジカル・スタンバイ・データベースの作成で実行するタスクのチェックリスト
で、各タスクを実行するデータベースを指定します。各タスクを詳細に説明している参照先
の項も記載されています。
表 4-2 ロジカル・スタンバイ・データベースの作成
参照先
タスク
データベース
4-8 ページ
フィジカル・スタンバイ・データベースの作成
プライマリ
4-9 ページ
ロジカル・スタンバイ・データベースをサポートするためのプライマリ・
データベースの準備
プライマリ
4-12 ページ
ロジカル・スタンバイ・データベースに推移するための準備
スタンバイ
4-15 ページ
ロジカル・スタンバイ・データベースの起動
スタンバイ
4-19 ページ
ロジカル・スタンバイ・データベースが正しく実行されているかどうかの
確認
スタンバイ
フィジカル・スタンバイ・データベースの作成
ロジカル・スタンバイ・データベースを作成するには、次のように最初にフィジカル・スタ
ンバイ・データベースを作成してから、ロジカル・スタンバイ・データベースへと推移させ
ます。
手順 1 フィジカル・スタンバイ・データベースを作成する
第 3 章の指示に従ってフィジカル・スタンバイ・データベースを作成します。
手順 2 フィジカル・スタンバイ・データベースがプライマリ・データベースと一致するこ
とを確認する
3-15 ページの「フィジカル・スタンバイ・データベースの起動」の手順を完了し、フィジカ
ル・スタンバイ・データベースと REDO Apply を起動した後は、すべてのデータベース構
造変更（データ・ファイルの追加や削除など）を含め、フィジカル・スタンバイ・データ
ベースがプライマリ・データベースと一貫した状態になるまでリカバリを続行できます。
4-8　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの作成
ロジカル・スタンバイ・データベースをサポートするためのプライマリ・
データベースの準備
この項は、次の項目で構成されています。
■
サプリメンタル・ロギングが使用可能であることの確認
■
ロールの推移のためのプライマリ・データベースの準備
サプリメンタル・ロギングが使用可能であることの確認
ロジカル・スタンバイ・データベースをサポートするために、プライマリ・データベースで
サプリメンタル・ロギングを使用可能にする必要があります。Oracle Database では変更され
た列のみがログに記録されるため、変更された行を一意に識別するのに十分でない場合があ
ります。このため、REDO データのストリームには追加の（補足）情報を記録する必要があ
ります。REDO データに追加される補足情報によって、SQL Apply は、ロジカル・スタンバ
イ・データベースの表を正しく識別し、メンテナンスできます。
手順 1 サプリメンタル・ロギングが使用可能であるかどうかを判別する
サプリメンタル・ロギングがプライマリ・データベースで使用可能かどうかを判別するに
は、V$DATABASE 固定ビューを問い合せます。次に例を示します。
SQL> SELECT SUPPLEMENTAL_LOG_DATA_PK AS PK_LOG,
2> SUPPLEMENTAL_LOG_DATA_UI AS UI_LOG
3> FROM V$DATABASE;
PK_LOG
-----NO
UI_LOG
-----NO
この例で、NO という値は、サプリメンタル・ロギングがプライマリ・データベースで使用
可能でないことを示しています。
サプリメンタル・ロギングが使用可能である場合は、「ロールの推移のためのプライマリ・
データベースの準備」に進んでください。サプリメンタル・ロギングが使用可能でない場合
は、次の手順を実行してサプリメンタル・ロギングを使用可能にします。
手順 2 サプリメンタル・ロギングを有効化する
プライマリ・データベースで、次の文を発行して、主キーと一意索引の情報をアーカイブ
REDO ログ・ファイルに追加します。
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;
この SQL 文によって、プライマリ・データベースで変更された行を一意に識別する情報が
追加されるため、SQL Apply は、スタンバイ・データベースの同じ行を正しく識別し、メン
テナンスできます。
ロジカル・スタンバイ・データベースの作成
4-9
ロジカル・スタンバイ・データベースの作成
この文は、進行中のすべてのトランザクションが完了するのを待機するため、オープン状態
のデータベースでは、完了するまでに時間がかかることがあります。この文の完了後に生成
された REDO はすべて、サプリメンタル・ロギング情報を持っていることが保証されます。
手順 3 サプリメンタル・ロギングが使用可能であることを確認する
プライマリ・データベースで、前述の問合せと同じ問合せを発行して、サプリメンタル・ロ
ギングが使用可能であることを確認します。次に例を示します。
SQL> SELECT SUPPLEMENTAL_LOG_DATA_PK AS PK_LOG,
2> SUPPLEMENTAL_LOG_DATA_UI AS UI_LOG
3> FROM V$DATABASE;
PK_LOG UI_LOG
------ -----YES
YES
この例で、YES という値は、サプリメンタル・ロギングがプライマリ・データベースで使用
可能であることを示しています。主キー（SUPPLEMENTAL_LOG_DATA_PK）または一意索引
（SUPPLEMENTAL_LOG_DATA_UI）が設定されている表の場合はすべて、更新操作の実行時
に、主キーと一意索引のすべての列がオンライン REDO ログ・ファイルに記録されます。
注意 : フィジカル・スタンバイ・データベースも含まれている Data
Guard 構成内のプライマリ・データベースでサプリメンタル・ロギングを
使用可能にする場合は、スイッチオーバーが正しく実行されるように、各
フィジカル・スタンバイ・データベースで ALTER DATABASE ADD
SUPPLEMENTAL LOG DATA 文を発行する必要があります。
V$DATABASE ビューの詳細は第 14 章「Oracle Data Guard に関連するビュー」を、ALTER
DATABASE ADD SUPPLEMENTAL LOG DATA 文の詳細は『Oracle Database SQL リファレン
ス』を参照してください。
4-10　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの作成
ロールの推移のためのプライマリ・データベースの準備
3-3 ページの「プライマリ・データベースの初期化パラメータの設定」では、プライマリ・
データベースがフィジカル・スタンバイ・ロールに推移する場合に有効になるように、複数
のスタンバイ・ロールの初期化パラメータを設定しました。プライマリ・データベースをロ
ジカル・スタンバイ・ロールに推移させる場合は、ロールの推移後にパラメータを変更せず
にすむように、プライマリ・データベースで例 4-1 に示すパラメータを変更する必要があり
ます。
例 4-1 プライマリ・データベース : ロジカル・スタンバイ・ロールの初期化パラメータ
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=boston
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_3=
'LOCATION=/arch2/chicago/
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE
UNDO_RETENTION=3600
LOG_ARCHIVE_DEST_n パラメータを動的に設定するには、SQL ALTER SYSTEM SET 文を
使用し、変更が即時に有効になってデータベースを停止して再起動した後も存続するように
SCOPE=BOTH 句を指定します。また、UNDO_RETENTION パラメータを 3600 に設定します。
このパラメータでは、データベースに保持されるコミット済 UNDO 情報の量を秒単位で指
定します。ロジカル・スタンバイ・データベースの LogMiner ディレクトリを作成する場合
に最高の結果が得られるように、この値を 3600 に設定することをお薦めします。
次の表に、例 4-1 に示した初期化パラメータで定義されるアーカイブ・プロセスを示します。
LOG_ARCHIVE_DEST_1
シカゴのデータベースがプライマリ・
ロールで稼働している場合
シカゴのデータベースがロジカル・スタンバイ・
ロールで稼働している場合
/arch1/chicago/ 内のローカル・アー
カイブ REDO ログ・ファイルにローカル・
オンライン REDO ログ・ファイルからプ
ライマリ・データベースによって生成され
た REDO データをアーカイブ。
/arch1/chicago/ 内のローカル・アーカイブ
REDO ログ・ファイルにローカル・オンライン
REDO ログ・ファイルからロジカル・スタンバ
イ・データベースによって生成された REDO
データをアーカイブ。
ロジカル・スタンバイ・データベースの作成
4-11
ロジカル・スタンバイ・データベースの作成
シカゴのデータベースがプライマリ・
ロールで稼働している場合
シカゴのデータベースがロジカル・スタンバイ・
ロールで稼働している場合
LOG_ARCHIVE_DEST_2
リモート・ロジカル・スタンバイ・データ 無視。LOG_ARCHIVE_DEST_2 は、chicago が
ベース boston に REDO データを転送。 プライマリ・ロールで稼働している場合にのみ有
効。
LOG_ARCHIVE_DEST_3
無視。LOG_ARCHIVE_DEST_3 は、
chicago がスタンバイ・ロールで稼働し
ている場合にのみ有効。
/arch2/chicago/ 内のローカル・アーカイブ
REDO ログ・ファイルにプライマリ・データベー
スから受信した REDO データをアーカイブ。
ロジカル・スタンバイ・データベースに推移するための準備
この項では、ロジカル・スタンバイ・データベースに推移するために、フィジカル・スタン
バイ・データベースを準備する方法について説明します。この章は、次の項目で構成されて
います。
■
サプリメンタル・ロギングが使用可能であることの確認
■
ロジカル・スタンバイ・データベース用の初期化パラメータ・ファイルの準備
■
ロジカル・スタンバイ・データベース用の制御ファイルの作成
サプリメンタル・ロギングが使用可能であることの確認
将来のロールの推移に備えてデータベースを準備するには、後でではなくこの時点で、ロジ
カル・スタンバイ・データベースにサプリメンタル・ロギングを使用可能にすると便利で
す。「サプリメンタル・ロギングが使用可能であることの確認」に示す手順を、プライマ
リ・データベースではなくロジカル・スタンバイ・データベースで実行します。
ロジカル・スタンバイ・データベース用の初期化パラメータ・ファイル
の準備
次の手順を実行して、スタンバイの初期化パラメータ・ファイルを作成します。
手順 1 ロジカル・スタンバイ・データベースで初期化パラメータを設定する
3-9 ページの「スタンバイ・データベース用の初期化パラメータ・ファイルの準備」で作成
したテキスト形式の初期化パラメータ・ファイル（PFILE）で、LOG_ARCHIVE_DEST_n パ
ラメータをさらに変更し、PARALLEL_MAX_SERVERS パラメータを追加する必要がありま
す。
LOG_ARCHIVE_DEST_n パラメータを変更する必要があります。これは、フィジカル・スタ
ンバイ・データベースとは異なり、ロジカル・スタンバイ・データベースは REDO データ
を生成するオープン・データベースであり、複数のログ・ファイル（オンライン REDO ロ
グ・ファイル、アーカイブ REDO ログ・ファイルおよびスタンバイ REDO ログ・ファイル）
があるためです。次のファイル用に個別のローカル宛先を指定することをお薦めします。
4-12　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの作成
■
■
ロジカル・スタンバイ・データベースで生成された 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
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_3=
'LOCATION=/arch2/boston/
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE
PARALLEL_MAX_SERVERS=9
UNDO_RETENTION=3600
次の表に、例 4-2 に示した初期化パラメータで定義されるアーカイブ・プロセスを示します。
ボストンのデータベースがプライマリ・
ロールで稼働している場合
ボストンのデータベースがロジカル・スタンバ
イ・ロールで稼働している場合
LOG_ARCHIVE_DEST_1
/arch1/boston/ 内のローカル・アーカ
イブ REDO ログ・ファイルにローカル・
オンライン REDO ログ・ファイルからプ
ライマリ・データベースによって生成され
た REDO データをアーカイブするよう指
示。
/arch1/boston/ 内のローカル・アーカイブ
REDO ログ・ファイルにローカル・オンライン
REDO ログ・ファイルからロジカル・スタンバ
イ・データベースによって生成された REDO
データをアーカイブするよう指示。
LOG_ARCHIVE_DEST_2
リモート・ロジカル・スタンバイ・データ 無視。LOG_ARCHIVE_DEST_2 は、boston がプ
ベース chicago に REDO データを転送す ライマリ・ロールで稼働している場合にのみ有
るよう指示。
効。
ロジカル・スタンバイ・データベースの作成
4-13
ロジカル・スタンバイ・データベースの作成
LOG_ARCHIVE_DEST_3
ボストンのデータベースがプライマリ・
ロールで稼働している場合
ボストンのデータベースがロジカル・スタンバ
イ・ロールで稼働している場合
無視。LOG_ARCHIVE_DEST_3 は、
boston がスタンバイ・ロールで稼働して
いる場合にのみ有効。
/arch2/boston/ 内のローカル・アーカイブ
REDO ログ・ファイルにプライマリ・データベー
スから受信した REDO データをアーカイブする
よう指示。
例 4-2 では、パラメータ・ファイルに PARALLEL_MAX_SERVERS 初期化パラメータが追加さ
れ、ロジカル・スタンバイ・データベースで動作するパラレル・サーバーの最大数が指定さ
れています。ロジカル・スタンバイ・データベースの場合、このパラメータは必須です。
PARALLEL_MAX_SERVERS を 5 未満の値に設定しないでください。最高の結果を得るには、
9 以上に設定します。詳細は、9-26 ページの「ロジカル・スタンバイ・データベースの
チューニング」を参照してください。
注意 : 変更の必要性がある他のパラメータについては、初期化パラメー
タ・ファイルを調べてください。たとえば、ダンプ出力先パラメータ
（BACKGROUND_DUMP_DEST、CORE_DUMP_DEST、USER_DUMP_DEST）の
変更が必要な場合があります。これは、スタンバイ・データベースのディ
レクトリ位置がプライマリ・データベースで指定したディレクトリ位置と
異なる場合に必要です。さらに、スタンバイ・システムにまだ存在してい
ないディレクトリがある場合は、そのディレクトリを作成する必要があり
ます。SHOW PARAMETERS コマンドを使用して、他に変更を必要とする初
期化パラメータがないかどうかを確認します。
手順 2 ロジカル・スタンバイ・データベースを停止する
ロジカル・スタンバイ・データベースを停止するには、次のコマンドを発行します。
SQL> SHUTDOWN IMMEDIATE;
後述の「ロジカル・スタンバイ・データベースの起動」で、新しい初期化パラメータ・ファ
イルを使用して、ロジカル・スタンバイ・データベースをマウントします。
4-14　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの作成
ロジカル・スタンバイ・データベース用の制御ファイルの作成
次の手順を実行して、スタンバイ・データベース用の制御ファイルを作成します。
手順 1 ロジカル・スタンバイ制御ファイルを作成します。
ALTER DATABASE CREATE LOGICAL STANDBY CONTROLFILE 文を発行して、スタンバ
イ・データベース用の制御ファイルを作成します。次の例に示すように、ロジカル・スタン
バイ・データベースを作成する場合は、LOGICAL キーワードを含める必要があります。
SQL> ALTER DATABASE CREATE LOGICAL STANDBY CONTROLFILE AS '/tmp/boston.ctl';
注意 : プライマリ・データベースとスタンバイ・データベースの両方に
単一の制御ファイルを使用することはできません。
手順 2 制御ファイルをロジカル・スタンバイ・システムにコピーする
プライマリ・システムで、オペレーティング・システムのコピー・ユーティリティを使用し
て、スタンバイ制御ファイルをロジカル・スタンバイ・システムにコピーします。たとえば、
次の例では、UNIX の cp コマンドを使用しています。
cp /tmp/boston.ctl /arch1/boston/control1.ctl
cp /tmp/boston.ctl /arch2/boston/control2.ctl
ロジカル・スタンバイ・データベースの起動
ロジカル・スタンバイ・データベースおよび SQL Apply を起動、マウントおよびアクティ
ブ化するには、次の手順を実行します。
手順 1 ロジカル・スタンバイ・データベースを起動およびマウントする
ロジカル・スタンバイ・データベースで、STARTUP MOUNT 文を発行して、データベースを
起動およびマウントします。データベースをオープンしないでください。後続の作成プロセ
スまで、データベースはユーザー・アクセスに対してクローズの状態のままにしておく必要
があります。次に例を示します。
SQL> STARTUP MOUNT PFILE=initboston.ora;
手順 2 SQL Apply を準備する
ロジカル・スタンバイ・データベースで、次の文を発行して、SQL Apply に使用できるよう
にします。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
ロジカル・スタンバイ・データベースの作成
4-15
ロジカル・スタンバイ・データベースの作成
手順 3 ロジカル・スタンバイ・データベースをアクティブ化する
次の文を発行して、このデータベースをロジカル・スタンバイ・データベースとしてアク
ティブ化します。
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
手順 4 ロジカル・スタンバイ・データベースのデータベース名をリセットする
Oracle の DBNEWID（nid）ユーティリティを実行して、ロジカル・スタンバイ・データ
ベースのデータベース名を変更します。名前の変更によって、このプライマリ・データベー
スのコピーと元のプライマリ・データベース間での相互作用を防止します。
DBNEWID（nid）ユーティリティを実行する前に、次のようにデータベースを停止してマ
ウントする必要があります。
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT PFILE=initboston.ora;
ここで、ロジカル・スタンバイ・データベースで Oracle の DBNEWID ユーティリティを実
行し、データベース名を変更してデータベースを停止します。
nid TARGET=SYS/password@boston DBNAME=boston
Connected to database chicago (DBID=1456557175)
Control Files in database:
/arch1/boston/control1.ctl
Change database ID and database name chicago to boston? (Y/[N]) => y
Proceeding with operation
Changing database ID from 1456557175 to 416458362
Changing database name from chicago to boston
Control File /arch1/boston/control1.ctl - modified
Datafile /arch1/boston/system01.dbf - dbid changed, wrote new name
Datafile /arch1/boston/undotbs01.dbf -dbid changed, wrote new name
.
.
.
Control File /arch1/boston/control1.ctl-dbid changed, wrote new name
Database name changed to boston.
Modify parameter file and generate a new password file before restarting.
Database ID for database boston change to 416458362.
All previous backups and archive logs for this database are unusable.
Database has been shut down, open database with RESETLOGS option.
Successfully changed database name and ID.
DBNEWID - Completed successfully.
Oracle DBNEWID（nid）ユーティリティの実行後に、パスワード・ファイルを再作成する
必要があります。
4-16　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの作成
手順 5 パラメータ・ファイルでロジカル・スタンバイ・データベース名を変更する
DBNEWID ユーティリティの出力に、初期化パラメータ・ファイルの更新が必要であること
が示されます。次の手順で、このタスクの実行方法を説明します。
1.
DB_NAME 初期化パラメータを変更します。
ロジカル・スタンバイ・データベース用の初期化パラメータ・ファイルの準備で使用し
たテキスト初期化パラメータ・ファイルの DB_NAME 初期化パラメータを、新規名と一
致するように設定します。
.
.
.
DB_NAME=boston
.
.
.
2.
ロジカル・スタンバイ・データベース用のサーバー・パラメータ・ファイルを作成しま
す。
ロジカル・スタンバイ・データベースのアイドル・インスタンスに接続し、テキスト初
期化パラメータ・ファイルからスタンバイ・データベース用のサーバー・パラメータ・
ファイルを作成します。次に例を示します。
SQL> CREATE SPFILE FROM PFILE=initboston.ora;
3.
ロジカル・スタンバイ・データベースを再起動する
次のように、ユーザー・アクセス用にロジカル・スタンバイ・データベースを起動して
オープンします。
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE OPEN RESETLOGS;
手順 6 ロジカル・スタンバイ・データベースのグローバル名を変更する
各データベースには一意のグローバル名が必要です。スタンバイ・データベースのグローバ
ル名を boston に変更するには、次の文を発行します。
SQL> ALTER DATABASE RENAME GLOBAL_NAME TO boston;
手順 7 ロジカル・スタンバイ・データベースに対する新規一時ファイルを作成する
将来のロールの推移に備えてデータベースを準備するには、後でではなくこの時点で、ロジ
カル・スタンバイ・データベースに新しい一時ファイルを作成すると便利です。
ロジカル・スタンバイ・データベースに一時ファイルを追加するには、次のタスクを実行し
ます。
ロジカル・スタンバイ・データベースの作成
4-17
ロジカル・スタンバイ・データベースの作成
1.
一時ファイルを格納する表領域を識別します。これを実行するには、スタンバイ・デー
タベースで次の文を入力します。
SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES
2> WHERE CONTENTS = 'TEMPORARY';
TABLESPACE_NAME
-------------------------------TEMP1
TEMP2
2.
スタンバイ・データベースに新しい一時ファイルを追加します。
前の問合せで識別された表領域ごとに、スタンバイ・データベースに新しい一時ファイ
ルを追加します。次の例は、プライマリ・データベースの一時ファイルと一致するサイ
ズおよび再利用の特性を使用して、TEMP1 という名前の新しい一時ファイルを追加しま
す。
SQL> ALTER TABLESPACE TEMP1 ADD TEMPFILE
2> '/arch1/boston/temp01.dbf'
3> SIZE 40M REUSE;
注意 : プライマリ・データベースの一時ファイルと一致する一時ファイ
ルをロジカル・スタンバイ・データベースで作成するには、プライマリ・
データベースの V$TEMPFILE ビューを問い合せて、プライマリ・データ
ベースの一時ファイルの詳細を取得します。
手順 8 SQL Apply を開始する
次の文を発行して、ロジカル・スタンバイ・データベースに対する REDO データの適用を
開始します。次に例を示します。
SQL>
ALTER DATABASE START LOGICAL STANDBY APPLY;
ロジカル・スタンバイ・データベースが正しく実行されていることを確認するには、「ロジ
カル・スタンバイ・データベースが正しく実行されているかどうかの確認」を続行します。
スタンバイ REDO ログ・ファイルを構成するには 5-29 ページの「スタンバイ REDO ログ・
ファイルの構成」を、SQL Apply およびリアルタイム適用の詳細は、6-12 ページの「REDO
データのロジカル・スタンバイ・データベースへの適用」を参照してください。
4-18　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの作成
ロジカル・スタンバイ・データベースが正しく実行されているかどうかの
確認
ロジカル・スタンバイ・データベースを作成し、ログ転送サービスとログ適用サービスを設
定した後は、REDO データがプライマリ・データベースから転送され、スタンバイ・データ
ベースに適用されていることを確認します。これをチェックするには、次の手順を実行しま
す。
手順 1 アーカイブ REDO ログ・ファイルの登録を確認する
アーカイブ REDO ログ・ファイルがロジカル・スタンバイ・システムに登録されたことを
確認するには、ロジカル・スタンバイ・データベースに接続し、DBA_LOGSTDBY_LOG
ビューを問い合せます。次に例を示します。
SQL> ALTER SESSION SET NLS_DATE_FORMAT
Session altered.
SQL>
SQL>
SQL>
2>
= 'DD-MON-YY HH24:MI:SS';
COLUMN DICT_BEGIN FORMAT A10
COLUMN DICT_END FORMAT A8
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN, DICT_END
FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
SEQUENCE#
---------24
25
26
27
28
29
30
31
FIRST_TIME
-----------------23-JUL-02 18:19:05
23-JUL-02 18:19:48
23-JUL-02 18:19:51
23-JUL-02 18:19:54
23-JUL-02 18:19:59
23-JUL-02 18:20:03
23-JUL-02 18:20:13
23-JUL-02 18:20:18
NEXT_TIME
-----------------23-JUL-02 18:19:48
23-JUL-02 18:19:51
23-JUL-02 18:19:54
23-JUL-02 18:19:59
23-JUL-02 18:20:03
23-JUL-02 18:20:13
23-JUL-02 18:20:18
23-JUL-02 18:20:21
DIC
--YES
NO
NO
NO
NO
NO
NO
NO
DIC
--YES
NO
NO
NO
NO
NO
NO
NO
8 rows selected.
手順 2 スタンバイ・データベースに REDO データを送信する
プライマリ・データベースに接続し、次の文を入力して、スタンバイ・データベースへの
REDO データの送信を開始します。
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
System altered.
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
System altered.
ロジカル・スタンバイ・データベースの作成
4-19
ロジカル・スタンバイ・データベースの作成
手順 3 DBA_LOGSTDBY_LOG ビューを再度問い合せる
ロジカル・スタンバイ・データベースに接続し、DBA_LOGSTDBY_LOG ビューを再度問い合
せます。
SQL> ALTER SESSION SET NLS_DATE_FORMAT
Session altered.
SQL>
SQL>
SQL>
2
= 'DD-MON-YY HH24:MI:SS';
COLUMN DICT_BEGIN FORMAT A10
COLUMN DICT_END FORMAT A8
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN, DICT_END
FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
SEQUENCE#
---------24
25
26
27
28
29
30
31
32
33
FIRST_TIME
-----------------23-JUL-02 18:19:05
23-JUL-02 18:19:48
23-JUL-02 18:19:51
23-JUL-02 18:19:54
23-JUL-02 18:19:59
23-JUL-02 18:20:03
23-JUL-02 18:20:13
23-JUL-02 18:20:18
23-JUL-02 18:20:21
23-JUL-02 18:32:11
NEXT_TIME
-----------------23-JUL-02 18:19:48
23-JUL-02 18:19:51
23-JUL-02 18:19:54
23-JUL-02 18:19:59
23-JUL-02 18:20:03
23-JUL-02 18:20:13
23-JUL-02 18:20:18
23-JUL-02 18:20:21
23-JUL-02 18:32:11
23-JUL-02 18:32:19
DIC
--YES
NO
NO
NO
NO
NO
NO
NO
NO
NO
DIC
--YES
NO
NO
NO
NO
NO
NO
NO
NO
NO
10 rows selected.
スタンバイ・データベースでファイルをチェックし、ログ・ファイルをいくつかアーカイブ
して、再度スタンバイ・データベースをチェックすることによって、新しいアーカイブ
REDO ログ・ファイルが登録されたことを確認できます。これらのログ・ファイルは、ログ
適用サービスがログの適用を開始するために使用できます。
手順 4 REDO データが正しく適用されていることを確認する
ロジカル・スタンバイ・データベースで、V$LOGSTDBY_STATS ビューを問い合せて、
REDO データが正しく適用されていることを確認します。次に例を示します。
SQL> COLUMN NAME FORMAT A30
SQL> COLUMN VALUE FORMAT A30
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'coordinator state';
NAME
VALUE
------------------------------ -----------------------------coordinator state
INITIALIZING
例では、V$LOGSTDBY_STATS ビューの出力は、コーディネータ・プロセスが初期化状態で
あることを示しています。コーディネータ・プロセスが初期化中の場合、ログ適用サービス
4-20　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの作成
は SQL Apply 操作の開始準備中ですが、アーカイブ REDO ログ・ファイルのデータはロジ
カル・スタンバイ・データベースに適用されていません。
コーディネータ・プロセスの状態を認識することは特に重要です。これは、その他のすべて
のロジカル・スタンバイ・プロセスに指示する LSP バックグラウンド・プロセスであるため
です。LSP バックグラウンド・プロセスの詳細は、9-12 ページの「SQL Apply アクティビ
ティの理解と表示」を参照してください。
手順 5 V$LOGSTDBY ビューを表示して現在の SQL Apply アクティビティを確認する
ロジカル・スタンバイ・データベースで、V$LOGSTDBY ビューを問い合せて、SQL Apply
アクティビティの現在のスナップショットを確認します。変更の読込みおよび適用に関係す
る各プロセスの現在のアクティビティを示すテキスト・メッセージが表示されます。
例 4-3 は、初期化フェーズ時の一般的な出力です。
例 4-3 初期化フェーズ時の V$LOGSTDBY 出力
SQL> COLUMN STATUS FORMAT A50
SQL> COLUMN TYPE FORMAT A12
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE
HIGH_SCN STATUS
------------ ---------- -------------------------------------------------COORDINATOR
ORA-16115: Log Miner ディクショナリ・データをロードしています
READER
ORA-16127: 追加のトランザクションが適用されるまで待機して
停止しました。
BUILDER
ORA-16117: 処理中です。
PREPARER
ORA-16116: 使用できる作業はありません
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE
HIGH_SCN STATUS
------------ ---------- -------------------------------------------------COORDINATOR
ORA-16126: 表またはシーケンス・オブジェクト番号 %d のロード中
READER
ORA-16116: 使用できる作業はありません
BUILDER
ORA-16116: 使用できる作業はありません
PREPARER
ORA-16116: 使用できる作業はありません
コーディネータ・プロセスがロジカル・スタンバイ・データベースに対する REDO データ
の適用を開始すると、V$LOGSTDBY ビューは、APPLYING ステートを表示して適用開始を示
します。
例 4-4 は、適用フェーズ時の一般的な出力です。HIGH_SCN 列の値が増加していることに注
意してください。この列の数は、変更が適用されているかぎり増加し続けます。HIGH_SCN
列は、進捗のインジケータとしてのみ機能します。
ロジカル・スタンバイ・データベースの作成
4-21
ロジカル・スタンバイ・データベースの作成
例 4-4 適用フェーズ時の V$LOGSTDBY 出力
SQL> COLUMN NAME FORMAT A30
SQL> COLUMN VALUE FORMAT A30
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'coordinator state';
NAME
VALUE
------------------------------ -----------------------------coordinator state
APPLYING
SQL> COLUMN STATUS FORMAT A50
SQL> COLUMN TYPE FORMAT A12
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE
HIGH_SCN STATUS
------------ ---------- -------------------------------------------------COORDINATOR
ORA-16117: 処理中です。
READER
ORA-16127: 追加のトランザクションが適用されるまで待機して
停止しました。
BUILDER
191896 ORA-16116: 使用できる作業はありません
PREPARER
191902 ORA-16117: 処理中です。
ANALYZER
191820 ORA-16120: SCN 0x0000.0002ed4e でのトランザクションに
対する依存性を計算中です。
APPLIER
APPLIER
APPLIER
191209 ORA-16124: トランザクション 1 16 1598 は待機中です。
191205 ORA-16116: 使用できる作業はありません
191206 ORA-16124: トランザクション 1 5 1603 は待機中です。
APPLIER
APPLIER
191213 ORA-16117: 処理中です。
191212 ORA-16124: トランザクション 1 20 1601 は待機中です。
APPLIER
191216 ORA-16124: トランザクション 1 4 1602 は待機中です。
11 rows selected.
手順 6 SQL Apply 全体の進捗をチェックする
SQL Apply 全体の進捗をチェックするには、スタンバイ・データベースで DBA_LOGSTDBY_
PROGRESS ビューを問い合せます。次に例を示します。
SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN NEWEST_SCN
----------- ---------180702
180702
スタンバイ REDO ログ・ファイルが構成されていない場合、APPLIED_SCN 列と NEWEST_
SCN 列の値は（問合せの例に示すように）等しくなります。これは、アーカイブ REDO ロ
グ・ファイルで使用可能なデータがすべて適用されたことを示します。これらの値を DBA_
4-22　Oracle Data Guard 概要および管理
その他の準備
LOGSTDBY_LOG ビューの FIRST_CHANGE# 列の値と比較すると、適用されたログ・ファイ
ル情報量と未適用のログ・ファイル情報量を確認できます。スタンバイ REDO ログ・ファイ
ルが構成されている場合、APPLIED_SCN 列と NEWEST_SCN 列の値は近接することがありま
すが、一致することはほとんどありません。
ログ転送サービスとログ適用サービスの両方が正常に動作していることの確認方法は、5-45
ページの「ログ・ファイル・アーカイブ情報の監視」および 6-13 ページの「ロジカル・スタ
ンバイ・データベースに関するログ適用サービスの監視」を参照してください。
その他の準備
この時点で、ロジカル・スタンバイ・データベースが実行中であり、最大パフォーマンス・
レベルのデータ保護を提供できます。次のリストに、ロジカル・スタンバイ・データベース
に対して実行できるその他の準備について説明します。
■
データ保護モードのアップグレード
Data Guard 構成は、最初は最大パフォーマンス・モード（デフォルト）で設定されま
す。データ保護モードの詳細と現行の保護モードをアップグレードまたはダウングレー
ドする方法は、5-27 ページの「データ保護モードの設定」を参照してください。
■
スタンバイ REDO ログの構成
スタンバイ・データベースを最大保護モードおよび最大可用性モードで実行するには、
スタンバイ REDO ログが必要です。ただし、すべてのスタンバイ・データベースでスタ
ンバイ REDO ログを構成することをお薦めします。これは、フェイルオーバー中に、
アーカイブ REDO ログ・ファイルのみを使用する場合よりも多くの REDO データを、
スタンバイ REDO ログ・ファイルからリカバリして適用できるためです。スタンバイ
REDO ログは、プライマリ・データベースとスタンバイ・データベースの両方に同じサ
イズと名前で存在する必要があります。詳細は、5-29 ページの「スタンバイ REDO ロ
グ・ファイルの構成」を参照してください。
■
フラッシュバック・データベースの有効化
フラッシュバック・データベースを使用すると、フェイルオーバー後にプライマリ・
データベースを再作成する必要がなくなります。フラッシュバック・データベースは従
来の Point-in-Time リカバリと同様の機能で、データベースを過去の最新時点の状態に
戻すことができます。フラッシュバック・データベースでは、データ・ファイルをバッ
クアップからリストアしたり REDO データを広範囲に適用する必要がないため、
Point-in-Time リカバリよりも高速です。フラッシュバック・データベースは、プライマ
リ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できま
す。詳細は、
『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザー
ズ・ガイド』を参照してください。
ロジカル・スタンバイ・データベースの作成
4-23
その他の準備
4-24　Oracle Data Guard 概要および管理
5
ログ転送サービス
この章では、本番データベースから 1 つ以上のアーカイブ先に REDO を転送するようにロ
グ転送サービスを構成する方法について説明します。この章は、次の項目で構成されていま
す。
■
ログ転送サービスの概要
■
REDO データの送信先
■
REDO データの送信方法
■
REDO データの送信時間
■
エラーが発生した場合の対処方法
■
データ保護モードの設定
■
ログ・ファイルの管理
■
アーカイブ・ギャップの管理
■
確認
ログ転送サービス
5-1
ログ転送サービスの概要
ログ転送サービスの概要
ログ転送サービスは、本番データベースまたはプライマリ・データベースの宛先から他の
ログ転送サービス
（スタンバイ）データベースの宛先への REDO データの自動転送を制御します。また、ネッ
トワーク障害によるアーカイブ REDO ログ・ファイルのギャップを解決するプロセスも管
理します。
ログ転送サービスは、ローカルとリモートの宛先に REDO データを転送できます。リモート
の宛先には、複数のタイプがあります。フィジカルおよびロジカル・スタンバイ・データ
ベース、アーカイブ REDO ログ・リポジトリ、インスタンス間アーカイブ・データベース
環境、Oracle Change Data Capture ステージング・データベース、Oracle Streams ダウンス
トリーム取得データベースなどです。
図 5-1 に、ログ転送サービスを使用して REDO データをプライマリ・データベース上のロー
カルの宛先にアーカイブし、同時にリモート・スタンバイ・データベースの宛先にアーカイ
ブ REDO ログ・ファイルまたはスタンバイ REDO ログ・ファイルを転送する単純な Data
Guard 構成を示します。
図 5-1 REDO データの転送
5-2　Oracle Data Guard 概要および管理
REDO データの送信先
REDO データの送信先
この項は、次の項目で構成されています。
■
宛先タイプ
■
LOG_ARCHIVE_DEST_n パラメータを使用した宛先の構成
■
フラッシュ・リカバリ領域を宛先とした設定
宛先タイプ
ログ転送サービスは、次のように複数タイプの宛先をサポートしています。
■
Oracle Data Guard スタンバイ・データベース
スタンバイ・データベースの宛先には、フィジカル・スタンバイ・データベースまたは
ロジカル・スタンバイ・データベースを使用できます。スタンバイ・データベースにつ
いては、1-2 ページの「スタンバイ・データベース」を参照してください。
■
アーカイブ REDO ログ・リポジトリ
このタイプのアーカイブ先では、REDO データのアーカイブがオフサイトで可能です。
アーカイブ・ログ・リポジトリは、フィジカル・スタンバイ制御ファイルを使用し、イ
ンスタンスを起動して、データベースをマウントすることによって作成されます。この
データベースにはデータ・ファイルは含まれず、スイッチオーバーまたはフェイルオー
バーには使用できません。短期間（たとえば 1 日）アーカイブ REDO ログ・ファイルを
保持し、その後ログ・ファイルを削除する方法として便利です。これによって、他の完
全に構成されたスタンバイ・データベースの格納と処理の手間をほとんど省くことがで
きます。
■
インスタンス間アーカイブ・データベース環境
インスタンス間アーカイブ・データベース環境は、プライマリ・データベースとスタン
バイ・データベースで作成可能です。Real Application Clusters 環境内では、各インス
タンスがその REDO データをクラスタの単一インスタンスに転送します。このインスタ
ンスは、リカバリ・インスタンスと呼ばれ、一般的には管理リカバリが実行されるイン
スタンスです。リカバリ・インスタンスには一般的に、Recovery Manager によるバッ
クアップとリストア・サポートに使用できるテープ・ドライブがあります。インスタン
ス間アーカイブ環境については、付録 B を参照してください。RAC および Data Guard
構成の追加情報は、
『Oracle 高可用性アーキテクチャおよびベスト・プラクティス』を
参照してください。
■
Oracle Streams ダウンストリーム取得データベース
この宛先タイプを使用すると、Oracle Streams によって取得プロセスをダウンストリー
ム・データベースでリモートに構成できます。Streams ダウンストリーム取得プロセス
は、ログ転送サービスを使用して REDO データをダウンストリーム・データベースに
転送し、ここで Streams の取得プロセスが、リモート宛先でのアーカイブ REDO ログ・
ログ転送サービス
5-3
REDO データの送信先
ファイルの変更点を取得します。詳細は、
『Oracle Streams 概要および管理』を参照し
てください。
■
Oracle Change Data Capture ステージング・データベース
この宛先タイプを使用すると、Asynchronous AutoLog 用のチェンジ・データ・キャプ
チャでログ転送サービスを使用して、ソース・データベースからリモートのステージン
グ・データベースに REDO データを転送し、そこでプロセスがアーカイブ REDO ロ
グ・ファイルから変更データを取得できます。詳細は、
『Oracle データ・ウェアハウ
ス・ガイド』を参照してください。
このマニュアルの説明では、本番データベースをプライマリ・データベース、アーカイブ先
をスタンバイ・データベースと呼びます（定義については 1-2 ページの「Data Guard 構成」
を参照してください）
。Oracle Change Data Capture を使用している場合は、プライマリ・
データベースおよびスタンバイ・データベースという用語をそれぞれソースおよびステージ
ング・データベースに置き換えてください。Oracle Streams を使用している場合は、プライ
マリ・データベースおよびスタンバイ・データベースという用語をそれぞれソースおよびダ
ウンストリーム取得データベースに置き換えてください。
LOG_ARCHIVE_DEST_n パラメータを使用した宛先の構成
LOG_ARCHIVE_DEST_n 初期化パラメータでは、最大 10（n= 1, 2, 3, ... 10）アーカイブ先を
定義します。いずれも LOCATION または SERVICE 属性を使用して REDO データのアーカイ
ブ先を指定する必要があります （また、すべての LOG_ARCHIVE_DEST_n 属性の詳細は、
第 12 章を参照してください）。
LOCATION および SERVICE 属性では、ローカル・ディスクの場所、またはログ転送サービ
スが REDO データを転送するスタンバイ宛先を示す Oracle Net サービス名を記述します。
SERVICE 属性でリモートの宛先を指定することにより、障害時リカバリに備え、Data
Guard がトランザクション一貫性のあるプライマリ・データベースのリモート・コピーを確
実に維持できます。
定義する各 LOG_ARCHIVE_DEST_n 初期化パラメータに対し、それぞれ対応する LOG_
ARCHIVE_DEST_STATE_n パラメータを指定できます。LOG_ARCHIVE_DEST_STATE_n（n
は 1 から 10 の整数）初期化パラメータは、対応する宛先が現在オン（有効）とオフ（無効）
のどちらになっているかを指定します。表 5-1 に、LOG_ARCHIVE_DEST_STATE_n パラ
メータの属性を示します。
表 5-1 LOG_ARCHIVE_DEST_STATE_n 初期化パラメータの属性
属性
説明
ENABLE
ログ転送サービスはこの宛先に REDO データを転送できる。
ENABLE がデフォルト。
DEFER
ログ転送サービスはこの宛先に REDO データを転送しない。これ
は有効だが使用されない宛先である。
5-4　Oracle Data Guard 概要および管理
REDO データの送信先
表 5-1 LOG_ARCHIVE_DEST_STATE_n 初期化パラメータの属性（続き）
属性
説明
ALTERNATE
この宛先は使用可能ではないが、関連付けられている宛先への通
信に障害が起きると使用可能になる。
RESET
機能は DEFER と同じだが、前に失敗している場合は宛先に関する
エラー・メッセージを消去する。
例 5-1 に、LOCATION 属性を持つ単一の宛先の例を示します。
例 5-1 ローカルのアーカイブ先の指定
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
図 5-2 に、単一のローカル宛先で構成される、この単純な構成を示します。ログ・ライター・
プロセスは、REDO データをオンライン REDO ログ・ファイルに書き込みます。各オンライ
ン REDO ログ・ファイルがいっぱいになると、ログ・スイッチが発生し、ARCn プロセス
は、いっぱいになったオンライン REDO ログ・ファイルをアーカイブ REDO ログ・ファイ
ルにアーカイブします。これによって、いっぱいになったオンライン REDO ログ・ファイル
が再利用できます。
ログ転送サービス
5-5
REDO データの送信先
図 5-2 スタンバイ・データベースがない場合のプライマリ・データベースのアーカイブ処理
図 5-2 で示されている構成にはスタンバイ・データベースが含まれておらず、障害リカバリ
に対して保護しない点に注意してください。この単純な構成を、障害時リカバリを提供する
基本的な Data Guard 構成にするには、SERVICE 属性を指定してリモートの宛先にスタンバ
イ・データベースを追加する必要があります。
例 5-2 に、ログ転送サービスによってオンライン REDO ログをローカルの宛先 chicago に
アーカイブし、REDO データを Oracle Net サービス名が boston のリモート・スタンバイ・
データベースに転送することを可能にする初期化パラメータを示します。この例では、他の
すべての LOG_ARCHIVE_DEST_n 属性にデフォルト値を使用しています。
5-6　Oracle Data Guard 概要および管理
REDO データの送信先
例 5-2 リモートのアーカイブ先の指定
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='SERVICE=boston'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
これらの初期化パラメータは、ログ転送サービスがアーカイバ（ARCn）プロセスを使用し
てローカルとリモートの宛先にアーカイブする構造に基づく基本的な Data Guard 構成を設
定します。この構成は、最大パフォーマンス・レベルのデータ保護を提供します。
LOG_ARCHIVE_DEST_n パラメータの LOCATION または SERVICE 属性のみを指定して、基
本的な Data Guard 構成を作成できますが、オプションで他の属性を指定することにより、
各宛先の動作をより詳細に指定できます。次の各項では、LOG_ARCHIVE_DEST_n パラメー
タの複数の属性について説明します。
フラッシュ・リカバリ領域を宛先とした設定
Oracle データベースでは、フラッシュ・リカバリ領域と呼ばれるディスク領域を構成できま
す。これは、ディレクトリ、ファイル・システムまたは Oracle Storage Manager ディスク・
グループで、リカバリに関連のあるファイルのデフォルトの格納場所として機能します。
フラッシュ・リカバリ領域を構成するには、DB_RECOVERY_FILE_DEST 初期化パラメータ
を使用して、フラッシュ・リカバリ領域として機能するディレクトリ、ファイル・システム
または Oracle Storage Manager ディスク・グループを指定します。ローカルの宛先が定義さ
れていない場合、Data Guard により、暗黙的に、LOG_ARCHIVE_DEST_10 の宛先を使用し
てフラッシュ・リカバリ領域のデフォルトのディスクの場所が参照され、アーカイブ REDO
ログ・ファイルの格納先として使用されます （フラッシュ・リカバリ領域の構成方法は
『Oracle Database バックアップおよびリカバリ基礎』を、Oracle Storage Manager と Oracle
Managed Files の詳細は『Oracle Database 管理者ガイド』を参照してください）
。
注意 : フラッシュ・リカバリ領域に格納されたアーカイブ REDO ログ・
ファイルのファイル名は、Oracle Managed Files（OMF）によって自動的
に生成されます。LOG_ARCHIVE_FORMAT 初期化パラメータによって指定
された形式には基づいていません。
ログ転送サービス
5-7
REDO データの送信先
フラッシュ・リカバリ領域ではデフォルトで LOG_ARCHIVE_DEST_10 の宛先が使用されま
すが、他の 1 つ以上の LOG_ARCHIVE_DEST_n の宛先または STANDBY_ARCHIVE_DEST の
宛先を使用するようにフラッシュ・リカバリ領域を明示的に設定できます。この項は、次の
項目で構成されています。
■
LOG_ARCHIVE_DEST_10 のデフォルト・フラッシュ・リカバリ領域の使用
■
フラッシュ・リカバリ領域を他の LOG_ARCHIVE_DEST_n の宛先に設定する
■
フラッシュ・リカバリ領域を STANDBY_ARCHIVE_DEST の宛先に設定する
■
プライマリ・データベースとスタンバイ・データベースでフラッシュ・リカバリ領域を
共有する
注意 : プライマリ・データベースからロジカル・スタンバイ・データ
ベースのフラッシュ・リカバリ領域には、REDO データを転送できませ
ん。
フラッシュ・リカバリ領域の構成方法については『Oracle Database バックアップおよびリ
カバリ基礎』を、フラッシュ・リカバリ領域内のアーカイブ REDO ログ・ファイルに対す
る削除ポリシーの設定方法については 8-31 ページの「フラッシュ・リカバリ領域のアーカイ
ブ REDO ログ・ファイルに関する削除ポリシー」を参照してください。
LOG_ARCHIVE_DEST_10 のデフォルト・フラッシュ・リカバリ領域の使用
フラッシュ・リカバリ領域が構成されていて、ローカルの宛先が定義されていない場合、
Data Guard により、暗黙的に、LOG_ARCHIVE_DEST_10 の宛先を使用してフラッシュ・リ
カバリ領域のデフォルトのディスクの場所が参照され、アーカイブ REDO ログ・ファイル
の格納先として使用されます
LOG_ARCHIVE_DEST_10 の宛先がフラッシュ・リカバリ領域に使用される場合、Data
Guard は、自動的にすべての LOG_ARCHIVE_DEST_10 パラメータ属性のデフォルト値を使
用します。デフォルトを無視するには、LOG_ARCHIVE_DEST_10 パラメータを明示的に指定
して、ほとんどの1 属性の値を動的に設定します。たとえば、次の 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)'
1
フラッシュ・リカバリ領域の宛先を定義する際、QUOTA_SIZE および QUOTA_USED 属性のみ、
指定できません。フラッシュ・リカバリ領域に割り当てられる領域は、DB_RECOVERY_FILE_
DEST_SIZE パラメータによって定義されるためです。
5-8　Oracle Data Guard 概要および管理
REDO データの送信先
LOG_ARCHIVE_DEST_n の属性を設定すると、LOG_ARCHIVE_DEST_n パラメータの
TEMPLATE 属性は、フラッシュ・リカバリ領域のその他すべての指定に優先されます。リ
モートの宛先について TEMPLATE 属性が指定され、その宛先では REDO データがフラッ
シュ・リカバリ領域にアーカイブされる場合、アーカイブ REDO ログ・ファイルには、
TEMPLATE 属性で指定されたディレクトリおよびファイル名が使用されます。
フラッシュ・リカバリ領域を他の LOG_ARCHIVE_DEST_n の宛先に設定
する
デフォルトでは、ローカルの宛先が定義されていない場合、フラッシュ・リカバリ領域では
LOG_ARCHIVE_DEST_10 の宛先が使用されますが、他の 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-9
REDO データの送信先
フラッシュ・リカバリ領域を STANDBY_ARCHIVE_DEST の宛先に設定する
STANDBY_ARCHIVE_DEST パラメータを定義すると、フィジカル・スタンバイ・データベー
スでフラッシュ・リカバリ領域を使用できます。次に例を示します。
STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'
注意 : ロジカル・スタンバイ・データベース（SQL Apply）で、
STANDBY_ARCHIVE_DEST パラメータを使用して指定したフラッシュ・リ
カバリ領域の宛先は無視されます。
プライマリ・データベースとスタンバイ・データベースでフラッシュ・
リカバリ領域を共有する
フラッシュ・リカバリ領域を共有する各データベースに、DB_UNIQUE_NAME 初期化パラ
メータで一意のデータベース名が指定されている場合は、データベース間でフラッシュ・リ
カバリ領域を共有できます。
次の例に、/arch/oradata ディレクトリにあるフラッシュ・リカバリ領域を共有するプラ
イマリおよびスタンバイ・データベースで、初期化パラメータを指定する方法を示します。
例 5-3 では DB_UNIQUE_NAME パラメータが指定されていませんが、デフォルトで DB_NAME
初期化パラメータに指定されている名前 PAYROLL に設定されます。
例 5-3 共有リカバリ領域に関するプライマリ・データベースの初期化パラメータ
DB_NAME=PAYROLL
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'
DB_RECOVERY_FILE_DEST='/arch/oradata'
DB_RECOVERY_FILE_DEST_SIZE=20G
例 5-4 共有リカバリ領域に関するスタンバイ・データベースの初期化パラメータ
DB_NAME=PAYROLL
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'
STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'
DB_RECOVERY_FILE_DEST='/arch/oradata'
DB_RECOVERY_FILE_DEST_SIZE=5G
複数のデータベース間でフラッシュ・リカバリ領域を共有する方法の詳細は、
『Oracle
Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してく
ださい。
5-10　Oracle Data Guard 概要および管理
REDO データの送信方法
REDO データの送信方法
この項は、次の項目で構成されています。
■
アーカイバ・プロセス（ARCn）を使用した REDO データのアーカイブ
■
ログ・ライター・プロセス（LGWR）を使用した REDO データのアーカイブ
■
セキュアな REDO データの転送の提供
アーカイバ・プロセス（ARCn）を使用した
）を使用した REDO データのアーカイブ
アーカイバ・プロセス（
デフォルトで、ログ転送サービスは REDO データをリモート・スタンバイ宛先に送信する
前に、ARCn プロセスを使用してローカルのオンライン REDO ログ・ファイルをプライマ
リ・データベースにアーカイブします。この項では、アーカイブ処理に ARCn プロセスを使
用する方法を説明します。
■
ARCn のアーカイブ動作を制御する初期化パラメータ
■
ARCn のデフォルトのアーカイブ処理
■
ARCn のデフォルト以外のアーカイブ処理
ARCn アーカイブ・プロセスは、Data Guard 構成で最大パフォーマンス・レベルのデータ
保護のみをサポートします。他のデータ保護モードで動作するスタンバイの場所に REDO
データを転送するには、LGWR プロセスを使用する必要があります。Data Guard のデータ
保護モードの詳細は、
「データ保護モードの設定」を参照してください。
ARCn のアーカイブ動作を制御する初期化パラメータ
ARCn アーカイブ・プロセスは、LOG_ARCHIVE_LOCAL_FIRST 初期化パラメータ、LOG_
ARCHIVE_DEST_n パラメータの ARCH 属性および LOG_ARCHIVE_DEST_STATE_n パラメー
タによって制御されます。次の項では、アーカイブ・プロセスを制御するこれらのパラメー
タの設定について説明します。
ログ転送サービスの使用可能化による ARCn プロセスの使用
LOG_ARCHIVE_DEST_n パラメータの ARCH 属性を使用すると、ログ転送サービスで ARCn
プロセスを使用して REDO データをアーカイブ先に転送できます。
■
■
LOG_ARCHIVE_DEST_n パラメータの ARCH および LOCATION 属性を指定すると、ARCn
プロセスはローカルの宛先にアーカイブします。
LOG_ARCHIVE_DEST_n パラメータの ARCH および SERVICE 属性を指定すると、ARCn
プロセスは REDO データをリモートの宛先に転送します。
ログ転送サービス
5-11
REDO データの送信方法
ARCn プロセスによる REDO データ転送時期の制御
LOG_ARCHIVE_LOCAL_FIRST 初期化パラメータは、アーカイバ・プロセス（ARCn）が
REDO データをリモート・スタンバイ・データベース宛先にいつ転送するかを制御します。
次の表に、このパラメータに可能な値を示します。
値
いつ REDO データをリモート・スタンバイ宛先に転送するか . .
TRUE
オンライン REDO ログが完全かつ正常に 1 つ以上のローカルの宛先にアーカ
イブされた後。これはデフォルト値です。このデフォルトの ARCn 動作の詳細
は、「ARCn のデフォルトのアーカイブ処理」を参照してください。
FALSE
オンライン REDO ログ・ファイルがローカルの宛先にアーカイブされるのと
同時。この ARCn 動作の詳細は、
「ARCn のデフォルト以外のアーカイブ処理」
を参照してください。
次の各項では、LOG_ARCHIVE_LOCAL_FIRST 初期化パラメータの値に応じた ARCn 処理の
動作の詳細を説明します。
ARCn のデフォルトのアーカイブ処理
図 5-3 に、Data Guard 構成におけるデフォルトのアーカイブ処理の例を示します。この構成
は、プライマリ・データベースがシカゴにあり、フィジカル・スタンバイ・データベースが
ボストンにある場合の、Data Guard 構成におけるデフォルトの ARCn アーカイブ・プロセ
スを表しています （これは、第 3 章で作成した構成です）
。
プライマリ・データベースでログ・スイッチが発生すると、アーカイブが実行されます。
ARC0 プロセスが正常にローカル・オンライン REDO ログをローカルの宛先（LOG_
ARCHIVE_DEST_1）にアーカイブした後、ARC1 プロセスがローカル・アーカイブ REDO
ログ・ファイル（オンライン REDO ログ・ファイルではない）をリモート・スタンバイ宛
先（LOG_ARCHIVE_DEST_2）に転送します。リモートの宛先では、リモート・ファイル・
サーバー・プロセス（RFS）が REDO データをスタンバイ REDO ログ・ファイルからアー
カイブ REDO ログ・ファイルに書き込みます（スタンバイ REDO ログ・ファイルの構成方
法については、
「スタンバイ REDO ログ・ファイルの構成」を参照してください）
。ログ適用
サービスは、REDO Apply（MRP プロセス1）または SQL Apply（LSP プロセス2）を使用し
て、REDO をスタンバイ・データベースに適用します。オンライン REDO ログ・ファイルは
まずローカルにアーカイブされるため、ローカルの宛先と同時に ARCn プロセスをスタンバ
イ・データベースにアーカイブする場合に比べ、LGWR プロセスによるオンライン REDO
ログ・ファイルの再利用が非常に早くなります。アーカイブ先のリモートの宛先のネット
ワーク接続が遅い場合、たとえば遠距離の Wide Area Network（WAN）を使用する場合な
1
2
管理リカバリ・プロセス（MRP）では、アーカイブ REDO ログ・ファイルがフィジカル・スタ
ンバイ・データベースに適用され、追加のパラレル実行（Pnnn）プロセスを開始してワーク
ロードのバランスを調整できます。
ロジカル・スタンバイ・プロセス（LSP）は、パラレル実行（Pnnn）プロセスと SQL インタ
フェースを使用して、アーカイブ REDO ログ・ファイルをロジカル・スタンバイ・データベー
スに適用します。
5-12　Oracle Data Guard 概要および管理
REDO データの送信方法
ど、この動作が便利です。デフォルトの ARCn アーカイブ動作には、ローカル・アーカイブ
およびプライマリ・データベースでの処理が、必須でないリモート宛先へのアーカイブの影
響を受けないという利点があります。また、ログ・ライター・プロセスによる再利用のため
にオンライン REDO ログ・ファイルをリサイクルするには時間がかかるため、作成するオ
ンライン REDO ログ・ファイルの数を増加する必要がある場合があります。
図 5-3 に示すように、ローカル・アーカイブをリモート・アーカイブから分離するには、2
つ以上の ARCn プロセスが必要です。このように分離するには、LOG_ARCHIVE_MAX_
PROCESSES 初期化パラメータを設定します（デフォルト設定は 2）。
図 5-3 リモートの宛先にアーカイブする前にローカルの宛先にアーカイブする
ログ転送サービス
5-13
REDO データの送信方法
デフォルトの ARCn アーカイブ・プロセスでは、ローカルのアーカイブとリモートのアーカ
イブの関連付けが解除されるため、バックアップ直後にプライマリ・データベース上のアー
カイブ REDO ログ・ファイルを削除するためのポリシーを持つサイトでは、プライマリ・
データベースのアーカイブ REDO ログ・ファイルを削除する前に、スタンバイの宛先が対
応する REDO データを受信することを確認する必要があります。V$ARCHIVED_LOG ビュー
を問い合せると、スタンバイの宛先で REDO データが受信されたことを確認できます。
ARCn のデフォルト以外のアーカイブ処理
オンライン REDO ログ・ファイルがローカルのオンライン REDO ログ・ファイルにアーカ
イブされるのと同時に、REDO データをスタンバイの宛先に転送するには、LOG_ARCHIVE_
LOCAL_FIRST=FALSE 初期化パラメータを設定します。
注意 : 10.1 より前のリリースの場合、デフォルトの ARCn アーカイブ動
作では、オンライン REDO ログ・ファイルのアーカイブと同時に REDO
データがスタンバイの宛先に転送されました。
例 5-5 に、LOG_ARCHIVE_LOCAL_FIRST=FALSE に設定されているプライマリ・ロール初
期化パラメータの一部を示します。これはデフォルトのアーカイブ設定であるため、LOG_
ARCHIVE_DEST_n パラメータの ARCH 属性の指定はオプションであることに注意してくだ
さい。
例 5-5 プライマリ・データベース : ARCn アーカイブの初期化パラメータ
LOG_ARCHIVE_LOCAL_FIRST=FALSE
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/
LOG_ARCHIVE_DEST_2='SERVICE=boston ARCH
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
図 5-4 に、Data Guard 構成のアーカイブ・プロセスを示します。この場合、プライマリ・
データベースの ARCn プロセスは、ローカルのオンライン REDO ログ・ファイルのアーカ
イブと同時に、REDO データをリモートの宛先に転送します。この構成では、アーカイブ操
作は、ローカルのオンライン REDO ログ・ファイルの REDO データを使用して、ローカル
およびリモート・スタンバイ宛先の両方で行われます。これにより、REDO データはリモー
ト・スタンバイ・データベースの宛先に迅速に送られます。
高速 Local Area Network（LAN）などの高速のネットワーク接続を使用している場合、
LOG_ARCHIVE_LOCAL_FIRST=FALSE を指定すると特に便利です。
5-14　Oracle Data Guard 概要および管理
REDO データの送信方法
図 5-4 ローカルおよびリモートの宛先へ同時にアーカイブする
ログ転送サービス
5-15
REDO データの送信方法
ログ・ライター・プロセス（LGWR）を使用した
）を使用した REDO データのアーカイブ
ログ・ライター・プロセス（
LGWR プロセスを選択した場合は、REDO がプライマリ・データベースで生成されると、
REDO データがローカルとリモート両方の宛先に転送されます。この項は、次の項目で構成
されています。
■
LGWR アーカイブ・プロセスに関する LOG_ARCHIVE_DEST_n 属性
■
LGWR SYNC アーカイブ・プロセス
■
LGWR ASYNC アーカイブ・プロセス
最大保護および最大可用性のデータ保護モードを使用するには、Data Guard 構成で LGWR
および SYNC 属性を指定して、1 つ以上の宛先でスタンバイ REDO ログ・ファイルを構成す
る必要があります。Data Guard のデータ保護モードの詳細は、
「データ保護モードの設定」
を参照してください。
LGWR アーカイブ・プロセスに関する LOG_ARCHIVE_DEST_n 属性
オプションでログ転送サービスを使用可能にし、LGWR プロセスを使用して、REDO が
ローカルのオンライン REDO ログ・ファイルに書き込まれると同時に REDO データをリ
モートの宛先に転送できます。
LGWR プロセスの使用方法は、デフォルトの ARCn プロセス（「アーカイバ・プロセス
（ARCn）を使用した REDO データのアーカイブ」を参照）とは異なります。これは、
LGWR プロセスは、プライマリ・データベースでオンライン REDO ログが切り替わるまで
待機してから、リモートの宛先すべてでアーカイブ REDO ログ全体を一度に書き込むかわ
りに、プライマリ・データベースの現行のオンライン REDO ログのログ順序番号（および
サイズ）を反映する新規 REDO ログ・ファイルをスタンバイ・サイトで作成するためです。
その後、プライマリ・データベースで REDO が生成されると、それがリモートの宛先にも
伝播します。リモートの宛先への伝播は、LOG_ARCHIVE_DEST_n パラメータに設定されて
いる属性（SYNC または ASYNC）に基づいて同期または非同期で実行されます。Data Guard
構成では、データ保護の最大保護および最大可用性モードには、同期 LGWR 処理が必須で
す。
次の各項では、LGWR、SYNC および ASYNC 属性について説明します。
ログ転送サービスでの LGWR プロセスの使用可能化
LOG_ARCHIVE_DEST_n パラメータの LGWR 属性は、ログ転送サービスで LGWR プロセス
を使用して REDO データをアーカイブ先に転送できるようにします。LOG_ARCHIVE_
DEST_n パラメータの LGWR および SERVICE 属性を指定すると、REDO データをリモート・
スタンバイ宛先に転送できます。
5-16　Oracle Data Guard 概要および管理
REDO データの送信方法
ネットワーク転送モードの指定
デフォルトでは、LGWR プロセスはリモートの宛先に REDO データを転送すると同時に、
同期させてローカルのオンライン REDO ログ・ファイルにアーカイブします。これは、
LOG_ARCHIVE_DEST_n パラメータの LGWR および SYNC 属性を指定した場合と同じです。
■
SYNC 属性を指定すると、すべてのネットワーク I/O が、オンライン REDO ログ・ファ
イルへの各書込み操作と同期して実行されます。トランザクションのリカバリに必要な
REDO データが宛先で受信されるまで、プライマリ・データベースではトランザクショ
ンがコミットされません。
「LGWR SYNC アーカイブ・プロセス」に、Data Guard 構成
における同期的なネットワーク転送の例を示します。
REDO データを複数のリモートの宛先に転送する必要がある場合は、オプションで
SYNC=PARALLEL を指定して、複数の宛先に対するネットワーク I/O をパラレルに開始
できます。LOG_ARCHIVE_DEST_n パラメータで LGWR および SYNC=PARALLEL 属性の
両方を指定すると、LGWR プロセスは REDO データを 1 つ以上のネットワーク・サー
バー（LNSn）プロセスに対して発行し、各プロセスでネットワーク I/O がパラレルに
開始されます。
SYNC 属性も ASYNC 属性も指定しない場合、デフォルトは SYNC=PARALLEL です。
■
ASYNC 属性を指定すると、すべてのネットワーク I/O は非同期で実行され、制御は即時
に実行側アプリケーションまたはユーザーに戻ります。この属性を指定すると、LGWR
プロセスはローカルのオンライン REDO ログ・ファイルにアーカイブし、その宛先の
ネットワーク・サーバー（LNSn）プロセスにネットワーク I/O 要求を発行します。さ
らに、ネットワーク I/O の完了を待たずに次の要求の処理を続行します。
ASYNC 属性を指定する場合は、ブロック数を指定して、使用する SGA ネットワーク・
バッファのサイズを決定できます。許容ブロック数は 0 ～ 102,400 です。ASYNC 属性で
は、オプションの接尾辞値 K を使用して 1,000 を表すことができます（値 1K は 1,000
個の 512 バイト・ブロックを示します）
。通常は、ネットワーク接続が低速であるほど、
大きいブロック数を使用してください。Data Guard 構成での非同期ネットワーク転送
の例については、
「LGWR ASYNC アーカイブ・プロセス」を参照してください。
LGWR および ASYNC 属性が有効な場合、LGWR プロセスはローカルのオンライン
REDO ログ・ファイルにアーカイブして REDO データを 1 つ以上の LNSn プロセスに
発行し、そこから REDO データがネットワークを介して非同期で転送されます。ログ転
送サービスが REDO データを複数のリモートの宛先に転送する場合、LNSn プロセス
（宛先ごとに 1 つずつ）は、すべての宛先に対するネットワーク I/O をパラレルに開始
します。詳細は、第 12 章を参照してください。
注意 : LGWR プロセスを使用するように宛先を構成しても、なんらかの
原因で LGWR プロセスが宛先にアーカイブできなくなると、ログ転送
サービスは ARCn プロセスの使用に戻り、デフォルト（LOG_ARCHIVE_
LOCAL_FIRST=TRUE）の動作を使用してアーカイブ操作を完了します。
この動作については、
「ARCn のデフォルトのアーカイブ処理」を参照し
てください。
ログ転送サービス
5-17
REDO データの送信方法
LGWR SYNC アーカイブ・プロセス
例 5-6 に、同期ネットワーク転送用に LGWR プロセスを構成するプライマリ・ロールの
LOG_ARCHIVE_DEST_n パラメータを示します。同期ネットワーク転送は LGWR アーカイ
ブ・プロセスのデフォルトであるため、LOG_ARCHIVE_DEST_n パラメータの SYNC 属性の
指定はオプションであることに注意してください。また、この例では、NET_TIMEOUT=30
属性を指定して、LGWR プロセスがネットワーク接続を終了する前にネットワーク・サー
バー・プロセスからのステータスを待機する時間を制御しています。30 秒以内にリプライが
ないと、LGWR プロセスはエラー・メッセージを戻します。
例 5-6 LGWR 同期アーカイブのための初期化パラメータ
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR SYNC NET_TIMEOUT=30'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
図 5-5 に、LGWR プロセスを使用して、REDO データをプライマリ・データベースのオンラ
イン REDO ログ・ファイルに書き込むと同時に、同期させてスタンバイ・システムに転送
する Data Guard 構成を示します。スタンバイ・システムでは、リモート・ファイル・サー
バー（RFS）がネットワークを介して LGWR プロセスから REDO データを受信し、スタン
バイ REDO ログ・ファイルに書き込みます。
プライマリ・データベースのログ・スイッチによって、スタンバイ・データベースのログ・
スイッチがトリガーされると、スタンバイ・データベースの ARCn プロセスは、スタンバイ
REDO ログ・ファイルをスタンバイ・データベースのアーカイブ REDO ログ・ファイルに
アーカイブします。ログ適用サービスは、REDO Apply（MRP プロセス）または SQL
Apply（LSP プロセス）を使用して、REDO データをスタンバイ・データベースに適用しま
す。
リアルタイム適用が使用可能な場合、Data Guard では、現行のスタンバイ REDO ログ・
ファイルが RFS プロセスによっていっぱいになったときに、そのファイルから REDO デー
タを直接リカバリします。
5-18　Oracle Data Guard 概要および管理
REDO データの送信方法
図 5-5 スタンバイ REDO ログ・ファイルを使用したリモートの宛先への LGWR SYNC アーカイブ
ログ転送サービス
5-19
REDO データの送信方法
LGWR ASYNC アーカイブ・プロセス
例 5-7 に、非同期ネットワーク転送用に LGWR プロセスを構成するプライマリ・ロールの
LOG_ARCHIVE_DEST_n パラメータを示します。
例 5-7 LGWR 非同期アーカイブのための初期化パラメータ
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC=61440'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
図 5-6 に、LNSn プロセスを使用して、スタンバイ・データベース上の RFS プロセスに
REDO データを Oracle Net を介して転送する様子を示します。プライマリ・データベース上
の LNSn および LGWR プロセスでは、通信にプロセス間通信（IPC）が使用されています。
5-20　Oracle Data Guard 概要および管理
REDO データの送信方法
図 5-6 ネットワーク・サーバー（LNSn）プロセスを使用した
）プロセスを使用した LGWR ASYNC アーカイブ
ネットワーク・サーバー（
ログ転送サービス
5-21
REDO データの送信方法
セキュアな REDO データの転送の提供
セキュアな環境を提供することは、ミッションクリティカルなアプリケーションをサポート
しているサイトでは重要な要件です。セキュリティの欠如は、可用性に直接影響を与えるた
めです。Data Guard は、セキュアな環境を提供し、REDO データがスタンバイ・データ
ベースに転送される際に改ざんされる可能性を防止します。
ログ転送サービスは、REDO データの送信に認証ネットワーク・セッションを使用します。
これらのセッションは、パスワード・ファイル内の SYS ユーザー・パスワードを使用して認
証されます。Data Guard 構成内の全データベースでパスワード・ファイルを使用する必要が
あり、このパスワード・ファイル内の SYS パスワードは、全システムで同一である必要があ
ります。Oracle Advanced Security がインストールされていない場合もこの認証は実行可能
で、REDO の転送の際にある程度のセキュリティを提供します。
注意 : REDO をさらに強力に保護するには（たとえば、REDO を暗号化
したり、ネットワーク上の REDO 通信の整合性チェックサム値を計算し、
ネットワーク上での REDO の改ざんを防止する）
、Oracle Advanced
Security をインストールし、使用することをお薦めします。『Oracle
Advanced Security 管理者ガイド』を参照してください。
セキュアな REDO の転送を提供するには、Data Guard 構成内のすべてのデータベースでパ
スワード・ファイルを使用するよう設定し、SYS ユーザーのパスワードをすべてのシステム
で同様に設定する必要があります。セキュアな環境を設定するには、プライマリ・データ
ベースおよび各スタンバイ・データベースで、次の手順を実行します。
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 リファレンス』を参照してください。
これらの手順を実行して Data Guard 構成内のすべてのデータベースでセキュリティを設定
すると、SYS 資格証明を使用した適切な認証チェックが正しく行われた場合にのみ Data
Guard は REDO データを転送します。
5-22　Oracle Data Guard 概要および管理
REDO データの送信時間
REDO データの送信時間
この項は、次の項目で構成されています。
■
VALID_FOR 属性を使用したロール・ベースの宛先の指定
■
一意のプライマリ・データベース名とスタンバイ・データベース名の指定
VALID_FOR 属性を使用したロール・ベースの宛先の指定
VALID_FOR 属性を使用すると、プライマリおよびスタンバイ・データベース・ロールの両
方の宛先属性を 1 つのサーバー・パラメータ・ファイル（SPFILE）で構成でき、Data
Guard 構成はロールの推移後も正しく動作します。ロールの推移後にロール固有のパラメー
タ・ファイルを使用可能または使用不可能にする必要がないため、スイッチオーバーおよび
フェイルオーバーが単純化されます。
LOG_ARCHIVE_DEST_n パラメータの VALID_FOR 属性を指定する場合は、次の要因に基づ
き、ログ転送サービスが 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 構成
ログ転送サービス
5-23
REDO データの送信時間
用の VALID_FOR 属性の設定例については 10-2 ページの「アーカイブ先の設定および確認」
の使用例を、VALID_FOR 属性の詳細は第 12 章を参照してください。
宛先の構成に VALID_FOR 属性を使用しない場合、データベースがプライマリ・ロールで動
作している場合とスタンバイ・ロールで動作している場合のためにそれぞれ 1 つずつ、合計
2 つのデータベース・サーバー・パラメータ・ファイル（SPFILE）を維持する必要がありま
す。構成例については、第 10 章を参照してください。
一意のプライマリ・データベース名とスタンバイ・データベース名の指定
DB_UNIQUE_NAME 属性を使用すると、宛先の構成時に一意のデータベース名を指定できま
す。これにより、Real Application Clusters のプライマリ・データベースが最大保護レベルま
たは最大可用性保護レベルで実行されている場合、そのプライマリ・データベースが含まれ
ている Data Guard 構成にスタンバイ・データベースを動的に追加できるようになります。
注意 : リモートの宛先のスタンバイ・データベースが DB_UNIQUE_NAME
初期化パラメータで識別されていない場合は、プライマリ・インスタンス
を起動する前にスタンバイ・データベースにアクセスできる必要がありま
す。
また、LOG_ARCHIVE_DEST_n パラメータの DB_UNIQUE_NAME 属性と LOG_ARCHIVE_
CONFIG パラメータの DG_CONFIG 属性では、Data Guard 構成の各データベースの一意の名
前を指定します。DB_UNIQUE_NAME 初期化パラメータで各データベースに対して定義した
名前を指定してください。
たとえば、次の初期化パラメータは、第 3 章で説明した Data Guard 構成内のプライマリ・
データベース（chicago）の DB_UNIQUE_NAME および LOG_ARCHIVE_CONFIG 定義を示
しています。
DB_NAME=chicago
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago, boston)'
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
LOG_ARCHIVE_DEST_2=
'SERVICE=boston
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
SERVICE 属性で指定されているリモートの宛先には、DB_UNIQUE_NAME 属性が必須です。
この例で、LOG_ARCHIVE_DEST_2 パラメータではリモートの宛先に DB_UNIQUE_
NAME=boston が指定されています。ログ転送サービスは、この情報をリモートの宛先で検
証します。名前が一致しなければ、その宛先への接続が拒否されます。
5-24　Oracle Data Guard 概要および管理
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 を受信できません。
デフォルトで、LOG_ARCHIVE_CONFIG パラメータは、プライマリ・データベースからスタ
ンバイ・データベースへの REDO データの送信を許可し、また、スタンバイ・データベー
スによるプライマリ・データベースからのアーカイブ用の REDO の受信を許可します。これ
は、LOG_ARCHIVE_CONFIG パラメータの SEND および RECEIVE 属性を設定した場合と同
じです。
注意 : LOG_ARCHIVE_CONFIG 初期化パラメータは、REMOTE_
ARCHIVE_ENABLE 初期化パラメータ（将来のリリースで使用されなくな
る）を置き換えます。これら両方のパラメータを同じ SPFILE またはテキ
スト初期化パラメータ・ファイルで指定しないでください。
ログ転送サービス
5-25
エラーが発生した場合の対処方法
エラーが発生した場合の対処方法
アーカイブ障害を処理するために、LOG_ARCHIVE_DEST_n パラメータの REOPEN および
MAX_FAILURES 属性を使用して、宛先へのアーカイブ・プロセスに失敗した場合に実行す
る処置を指定できます。これには次の処置が含まれます。
■
指定した期間が経過した後、失敗した宛先へのアーカイブ操作を上限回数まで再試行
する
■
代替宛先を使用する
■
接続を再確立して失敗した宛先への REDO データ送信を再開する試行回数を制御する
REOPEN 属性を使用して、ARCn プロセスまたは LGWR プロセスがエラー発生後に失敗し
た宛先への REDO データ再送信を試行するかどうかと、その時期を指定します。
REOPEN=seconds 属性を使用して、エラー発生後にアーカイブ・プロセスが失敗した宛先へ
のアクセスを再試行するまでの最小経過秒数を指定します。デフォルト値は 300 秒です。
REOPEN 属性に設定した値は、接続障害のみでなくすべてのエラーに適用されます。
NOREOPEN を指定すると、このオプションをオフにすることができます。これにより、障害
発生後は宛先へのアクセスが再試行されなくなります。
MAX_FAILURE 属性を使用して、ログ転送サービスが失敗した宛先への REDO データの転送
を継続的に試行する最大回数を指定します。MAX_FAILURE 属性とともに REOPEN 属性を使
用すると、失敗した宛先との接続を再確立するための継続的な試行回数を制限できます。指
定した継続試行回数を超えると、宛先は NOREOPEN 属性を指定した場合と同様に処理されま
す。
MAX_FAILURE 属性を使用する場合は、REOPEN 属性は必須です。例 5-8 に、再試行時間を
60 秒に設定し、再試行回数を 3 回に制限する方法を示します。
例 5-8 再試行時間の設定と制限
LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=60 MAX_FAILURE=3'
5-26　Oracle Data Guard 概要および管理
データ保護モードの設定
データ保護モードの設定
Data Guard には、次の 3 つのデータ保護モードが用意されています。最大保護、最大可用性
および最大パフォーマンスの 3 つです。選択したデータ保護レベルにより、プライマリ・
データベースからスタンバイ・データベースへの接続が失われた場合の動作が制御されま
す。この項は、次の項目で構成されています。
■
データ保護モードの選択
■
スタンバイ REDO ログ・ファイルの構成
■
Data Guard 構成のデータ保護モードの設定
データ保護モードの選択
適切なデータ保護モードを判断するには、次のデータ保護モードの説明を参考にして、デー
タ可用性に対するビジネス要件を応答時間とパフォーマンスに対するユーザーのニーズに基
づいて査定します。また、データ保護モードの設定方法については、「Data Guard 構成の
データ保護モードの設定」を参照してください。
最大保護モード
最大保護モード
この保護モードは、プライマリ・データベースに障害が発生した場合でも、データ消失がな
いことを保証します。このレベルの保護を提供するには、トランザクションがコミットされ
る前に、各トランザクションをリカバリするために必要な REDO データを、少なくとも 1
つのスタンバイ・データベース上のローカルのオンライン REDO ログおよびスタンバイ
REDO ログに書き込む必要があります。障害によって、少なくとも 1 つのリモート・スタン
バイ REDO ログに REDO ストリームを書込みできない場合、データ消失が発生しないよう
に、プライマリ・データベースが停止します。複数インスタンス RAC データベースでは、
Data Guard は正しく構成された少なくとも 1 つのデータベース・インスタンスに REDO レ
コードを書き込めない場合に、プライマリ・データベースを停止します。最大保護モードの
要件は、次のとおりです。
■
■
1 つ以上のスタンバイ・データベースでスタンバイ REDO ログ・ファイルを構成します。
1 つ以上のスタンバイ・データベースの宛先について、LOG_ARCHIVE_DEST_n パラ
メータの SYNC、LGWR および AFFIRM 属性を設定します。
最大可用性モード
この保護モードは、プライマリ・データベースの可用性を低下させない範囲で可能な最高レ
ベルのデータ保護を提供します。最大保護モードと同様に、トランザクションは、そのトラ
ンザクションのリカバリに必要な REDO が、ローカルのオンライン REDO ログおよび少な
くとも 1 つのリモート・スタンバイ REDO ログに書き込まれるまでコミットされません。障
害によって、リモート・スタンバイ REDO ログに REDO ストリームを書込みできない場合、
最大保護モードとは異なり、プライマリ・データベースは停止しません。かわりに、障害が
解決され、REDO ログ・ファイルのすべてのギャップが解決されるまで、プライマリ・デー
ログ転送サービス
5-27
データ保護モードの設定
タベースは最大パフォーマンス・モードで動作します。すべてのギャップが解決されると、
プライマリ・データベースは、最大可用性モードでの動作を自動的に再開します。
このモードは、プライマリ・データベースに障害が発生しても、2 回目の障害で、プライマ
リ・データベースから少なくとも 1 つのスタンバイ・データベースに REDO データの完全
なセットが送信された場合のみ、データ消失が発生しないことを保証します。
最大保護モードと同様に、最大可用性モードには次の要件があります。
■
■
1 つ以上のスタンバイ・データベースでスタンバイ REDO ログ・ファイルを構成します。
1 つ以上のスタンバイ・データベースについて、LOG_ARCHIVE_DEST_n パラメータの
SYNC、LGWR および AFFIRM 属性を設定します。
最大パフォーマンス・モード
この保護モード（デフォルト）は、プライマリ・データベースのパフォーマンスに影響しな
い範囲で可能な最高レベルのデータ保護を提供します。これは、トランザクションのリカバ
リに必要な REDO データがローカルのオンライン REDO ログに書き込まれた直後に、その
トランザクションのコミットを許可することで実行されます。プライマリ・データベースの
REDO データ・ストリームは、少なくとも 1 つのスタンバイ・データベースにも書き込まれ
ますが、その REDO ストリームは、REDO データを作成するトランザクションのコミット
メントについて非同期で書き込まれます。
十分な帯域幅を持つネットワーク・リンクが使用される場合、このモードは、プライマリ・
データベースのパフォーマンスに対する影響を最小限にして、最大可用性モードのレベルに
近いデータ保護レベルを提供します。
最大パフォーマンス・モードでは、スタンバイ・データベースの宛先について、LOG_
ARCHIVE_DEST_n パラメータの LGWR および ASYNC 属性を設定するか、または ARCH 属性
を設定できます。LGWR および ASYNC 属性を設定すると、プライマリ・データベースに障害
が発生した場合に、スタンバイ宛先で受信されないデータの量を減少させることができま
す。
5-28　Oracle Data Guard 概要および管理
データ保護モードの設定
スタンバイ REDO ログ・ファイルの構成
スタンバイ REDO ログ・ファイルは、最大保護モードと最大可用性モードに必須であり、
すべてのスタンバイ・データベースに使用することをお薦めします。これは、Data Guard
では、アーカイブ REDO ログ・ファイルのみの場合に比べて、スタンバイ REDO ログ・
ファイルも使用する方が多くのデータをリカバリして適用できるためです。
スタンバイ・データベースを作成する前または直後に、スタンバイ REDO ログ構成を計画
して、必要なすべてのグループとグループのメンバーを作成する必要があります。可用性を
向上するには、オンライン REDO ログ・ファイルの多重化と同様に、スタンバイ REDO ロ
グ・ファイルを多重化することを検討してください。
次の手順を実行して、多重化スタンバイ REDO ログ・ファイルを構成します。
手順 1 プライマリ・データベースおよびスタンバイ・データベースのログ・ファイルのサ
イズが同一であることを確認します。
現行のスタンバイ REDO ログ・ファイルのサイズは、現行のプライマリ・データベースの
オンライン REDO ログ・ファイルのサイズと正確に一致している（またはそれ以上である）
必要があります。たとえば、プライマリ・データベースが、ログ・サイズが 200K の 2 つの
オンライン REDO ログ・グループを使用する場合、スタンバイ REDO ログ・グループのロ
グ・ファイルのサイズも 200K である必要があります。
手順 2 スタンバイ REDO ログ・ファイル・グループの適切な数を決定します。
最小の構成では、プライマリ・データベースのオンライン REDO ログ・ファイル・グルー
プの数より 1 つ以上多いスタンバイ REDO ログ・ファイル・グループが必要です。ただし、
スタンバイ REDO ログ・ファイル・グループの推奨数は、プライマリ・データベース上の
スレッド数によって異なります。次の数式を使用して、スタンバイ REDO ログ・ファイル・
グループの適切な数を決定します。
( スレッド当たりのログ・ファイルの最大数 + 1) ×スレッドの最大数
この数式を使用することにより、スタンバイ REDO ログ・ファイルがスタンバイ・データ
ベースに割り当てられないためにプライマリ・インスタンスのログ・ライター（LGWR）プ
ロセスがブロックされる可能性が減少します。たとえば、プライマリ・データベースにス
レッド当たり 2 つのログ・ファイルと 2 つのスレッドが存在する場合、スタンバイ・データ
ベースに 6 つのスタンバイ REDO ログ・ファイル・グループが必要になります。
注意 : ロジカル・スタンバイ・データベースでは、ワークロードにより、
これ以上のスタンバイ REDO ログ・ファイル（または追加の ARCn プロ
セス）が必要になる可能性があります。ロジカル・スタンバイ・データ
ベースはオンライン REDO ログ・ファイルにも書込みを行い、これはス
タンバイ REDO ログ・ファイルより優先されるためです。このため、ス
タンバイ REDO ログ・ファイルはオンライン REDO ログ・ファイルほど
すばやくアーカイブされない可能性があります。「スタンバイ REDO ロ
グ・ファイル・グループの構成が適切であるかの判断」も参照してくださ
い。
ログ転送サービス
5-29
データ保護モードの設定
手順 3 関連するデータベース・パラメータおよび設定を確認します。
SQL CREATE DATABASE 文の MAXLOGFILES および MAXLOGMEMBERS 句に設定されている
値により、追加できるスタンバイ REDO ログ・ファイル・グループ数と各グループのメン
バー数が制限されないことを確認します。MAXLOGFILES および MAXLOGMEMBERS 句で指定
されている制限を無視するには、プライマリ・データベースまたは制御ファイルを再作成す
る必要があります。
MAXLOGFILES および MAXLOGMEMBERS 句のデフォルト値および有効な値の詳細は、
『Oracle Database SQL リファレンス』およびオペレーティング・システム固有の Oracle ド
キュメントを参照してください。
手順 4 スタンバイ REDO ログ・ファイル・グループを作成します。
新しいスタンバイ REDO ログ・ファイル・グループとメンバーの作成には、ALTER
DATABASE システム権限が必要です。スタンバイ・データベースは、プライマリ・データ
ベースで次回ログ・スイッチが発生したときに、新規に作成されたスタンバイ REDO ログ・
ファイルの使用を開始します。例 5-9 および 5-10 に、ALTER DATABASE 文の ADD
STANDBY LOGFILE GROUP 句を使用し、スタンバイ REDO ログ・ファイルの新しいグルー
プを作成する方法を示します。
例 5-9 特定のスレッドへのスタンバイ 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 ログ・ファイル・グループが
スレッドに自動的に割り当てられます。
例 5-10 特定のグループ番号へのスタンバイ 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-30　Oracle Data Guard 概要および管理
データ保護モードの設定
注意 : スタンバイ REDO ログ・ファイルが使用されるのは、データベー
スがスタンバイ・ロールで実行されているときのみですが、プライマリ・
データベースにスタンバイ REDO ログ・ファイルを作成して、プライマ
リ・データベースが DBA による介入なしにスタンバイ・ロールに迅速に
切り替えられるようにすることをお薦めします。プライマリ・データベー
スおよびスタンバイ・データベースの両方で自動的にスタンバイ REDO
ログ・ファイルを構成するために、Oracle Enterprise Manager GUI を使用
することを考慮してください。
手順 5 スタンバイ REDO ログ・ファイル・グループが作成されたことを確認します。
スタンバイ REDO ログ・ファイル・グループが作成されて正しく実行していることを確認
するには、プライマリ・データベースでログ・スイッチを起動してから、スタンバイ・デー
タベースで V$STANDBY_LOG ビューまたは V$LOGFILE ビューを問い合せます。次に例を示
します。
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
GROUP#
THREAD#
SEQUENCE# ARC
---------- ---------- ---------- --3
1
16 NO
4
0
0 YES
5
0
0 YES
STATUS
---------ACTIVE
UNASSIGNED
UNASSIGNED
Data Guard 構成のデータ保護モードの設定
ログ転送サービスを設定して Data Guard 構成のデータ保護レベルを指定する手順は、次の
とおりです。
手順 1 プライマリ・データベースで LOG_ARCHIVE_DEST_n パラメータを構成する
プライマリ・データベースで、LOG_ARCHIVE_DEST_n パラメータの属性を適切に構成しま
す。Data Guard の各データ保護モードでは、構成内の少なくとも 1 つのスタンバイ・データ
ベースが表 5-2 に記載された一連の最低要件を満たしている必要があります。
ログ転送サービス
5-31
データ保護モードの設定
表 5-2 データ保護モードの最低要件
最大保護
最大可用性
最大パフォーマンス
REDO アーカイブ・プロセス
LGWR
LGWR
LGWR または ARCH
ネットワーク転送モード
SYNC
SYNC
LGWR プロセスを使用する場合
は SYNC または ASYNC。ARCH
プロセスを使用する場合は
SYNC。
ディスク書込みオプション
AFFIRM
AFFIRM
AFFIRM または NOAFFIRM
スタンバイ REDO ログの必要性
可
可
オプション。ただし推奨。
注意 : 最大保護モードで実行する Data Guard 構成には、表 5-2 に記載さ
れた要件を満たす少なくとも 2 つのスタンバイ・データベースを含めるこ
とをお薦めします。これによって、1 つのスタンバイ・データベースがプ
ライマリ・データベースから REDO データを受信できない場合でも、プ
ライマリ・データベースは処理を継続できます。
次の例に、最大可用性モードの構成方法を示します。
SQL>
2>
3>
4>
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=chicago
OPTIONAL LGWR SYNC AFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
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 構成へのスタ
ンバイ・データベースの動的追加が使用可能になります。
手順 2 保護モードをアップグレードする場合は次の手順を実行する
この手順を実行するのは、保護モードを（最大パフォーマンス・モードから最大可用性モー
ドへなど）アップグレードする場合のみです。それ以外の場合は、手順 3 に進みます。
この例では、Data Guard 構成を最大パフォーマンス・モードから最大可用性モードにアッ
プグレードすると仮定します。プライマリ・データベースを停止し、マウント済モードで再
起動します。
5-32　Oracle Data Guard 概要および管理
データ保護モードの設定
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
Real Application Clusters データベースの場合は、すべてのプライマリ・インスタンスを停
止し、その中の 1 つのみを起動してマウントします。
手順 3 データ保護モードを設定する
データ保護モードを指定するには、プライマリ・データベースで SQL ALTER DATABASE
SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY |
PERFORMANCE} 文を発行します。たとえば、次の文は最大可用性モードを指定します。
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;
手順 4 プライマリ・データベースをオープンする
手順 2 で保護モードをアップグレードした場合は、データベースをオープンします。
SQL> ALTER DATABASE OPEN;
保護モードをダウングレードしている場合、データベースはすでにオープンしています。
手順 5 スタンバイ・データベースで LOG_ARCHIVE_DEST_n パラメータを構成する
スタンバイ・データベースで、スイッチオーバー後も構成が新しい保護モードで操作を継続
できるように、LOG_ARCHIVE_DEST_n パラメータ属性を構成します。次に例を示します。
SQL>
2>
3>
4>
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=boston
OPTIONAL LGWR SYNC AFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston';
手順 6 構成が新しい保護モードで動作していることを確認する
V$DATABASE ビューを問い合せ、Data Guard 構成が新しい保護モードで動作していること
を確認します。次に例を示します。
SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;
PROTECTION_MODE
--------------------MAXIMUM AVAILABILITY
PROTECTION_LEVEL
--------------------MAXIMUM AVAILABILITY
SQL 文については、第 13 章および『Oracle Database SQL リファレンス』を参照してくださ
い。
ログ転送サービス
5-33
ログ・ファイルの管理
ログ・ファイルの管理
この項は、次の項目で構成されています。
■
アーカイブ REDO ログ・ファイルの代替ディレクトリ位置の指定
■
オンライン REDO ログ・ファイルの再利用
■
スタンバイ REDO ログ・ファイルの管理
■
制御ファイルのサイズ拡大と再利用の計画
■
複数のスタンバイ・データベース間でのログ・ファイル宛先の共有
アーカイブ REDO ログ・ファイルの代替ディレクトリ位置の指定
通常、プライマリ・データベースから受信された REDO データは、LOG_ARCHIVE_DEST_n
パラメータの LOCATION 属性で指定したディレクトリに格納されているアーカイブ REDO
ログ・ファイルに書き込まれます。かわりに、スタンバイ・データベースの STANDBY_
ARCHIVE_DEST 初期化パラメータで、アーカイブ REDO ログ・ファイルがプライマリ・
データベースから受信された際の代替格納先ディレクトリを指定することも可能です。
両方のパラメータを指定すると、STANDBY_ARCHIVE_DEST 初期化パラメータは LOG_
ARCHIVE_DEST_n パラメータで指定したディレクトリ位置より優先されます。
スタンバイ・データベースでのアーカイブ REDO ログ・ファイルの格納場所は、次に示す
一連の規則に従って決定されます。データベース・インスタンスの起動時には、アーカイブ
REDO ログ・ファイルが次の順序で評価されます。
1.
スタンバイ・データベースで STANDBY_ARCHIVE_DEST 初期化パラメータが指定され
ている場合は、その位置が使用されます。
2.
LOG_ARCHIVE_DEST_n パラメータに VALID_FOR=(STANDBY_LOGFILE,*) 属性が含
まれている場合は、この宛先に指定されている位置が使用されます。
3.
COMPATIBLE パラメータが 10.0 以上に設定され、どの LOG_ARCHIVE_DEST_n パラ
メータにも VALID_FOR=(STANDBY_LOGFILE,*) 属性が含まれていない場合は、宛先
に有効な任意の LOG_ARCHIVE_DEST_n パラメータが使用されます。
4.
どの初期化パラメータも指定されていない場合、アーカイブ REDO ログ・ファイルは
STANDBY_ARCHIVE_DEST 初期化パラメータのデフォルト位置に格納されます。
STANDBY_ARCHIVE_DEST 初期化パラメータの暗黙的なデフォルト値を表示するには、
V$ARCHIVE_DEST ビューを問い合せます。
5-34　Oracle Data Guard 概要および管理
ログ・ファイルの管理
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
ログ転送サービスでは、STANDBY_ARCHIVE_DEST 初期化パラメータで指定された値ととも
に、LOG_ARCHIVE_FORMAT パラメータを使用して、スタンバイ・サイトでアーカイブ
REDO ログ・ファイルまたはスタンバイ REDO ログ・ファイルのファイル名を生成します。
次に例を示します。
STANDBY_ARCHIVE_DEST='/arc_dest/arls'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
この例で、%s は順序番号、%r はリセットログ ID です。これらによってデータベースの複
数のインカネーションにわたり、一意の名前がアーカイブ・ログ・ファイルに対して確実に
構成されます。Real Application Clusters の構成に必要な %t は、スレッド番号に対応してい
ます。
フィジカル・スタンバイ・データベースの場合、ログ転送サービスはスタンバイ・データ
ベースの制御ファイルに完全修飾名を格納し、ログ適用サービスはこの情報を使用してスタ
ンバイ・データベースでリカバリを実行します。
注意 : LOG_ARCHIVE_DEST_n パラメータの TEMPLATE 属性を指定する
と、STANDBY_ARCHIVE_DEST および LOG_ARCHIVE_FORMAT パラメー
タで生成されるファイル名は無視されます。TEMPLATE および
NOTEMPLATE 属性の詳細は、第 12 章を参照してください。
スタンバイ・システム上のアーカイブ 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-35
ログ・ファイルの管理
オンライン REDO ログ・ファイルの再利用
LOG_ARCHIVE_DEST_n パラメータの OPTIONAL または MANDATORY 属性を設定して、オン
ライン REDO ログ・ファイルを再利用するためのポリシーを指定できます。デフォルトで、
リモートの宛先は OPTIONAL に設定されます。OPTIONAL の宛先のアーカイブ操作に障害
が発生した場合、REDO データの転送とログの内容の書込みが失敗した場合にも、オンライ
ン REDO ログ・ファイルを再利用できます。MANDATORY の宛先へのアーカイブ操作に障
害が発生した場合は、その宛先への失敗したアーカイブが完了するまで、オンライン REDO
ログ・ファイルは上書きできません。
デフォルトでは、すべてのローカル宛先を OPTIONAL に指定しても、1 つの宛先は
MANDATORY になります。
例 5-11 に、必須のローカル・アーカイブ先を設定してその宛先を使用可能にする方法を示し
ます。MANDATORY 属性を指定する場合は、障害条件を処理するために、「エラーが発生した
場合の対処方法」の説明に従って REOPEN および MAX_FAILURE 属性を指定することも考慮
してください。
例 5-11 必須のアーカイブ先の設定
LOG_ARCHIVE_DEST_3 = 'LOCATION=/arc_dest MANDATORY'
スタンバイ REDO ログ・ファイルの管理
この項は、次の項目で構成されています。
■
スタンバイ REDO ログ・ファイル・グループの構成が適切であるかの判断
■
スタンバイ REDO ログ・メンバーを既存のグループに追加
■
スタンバイ REDO ログ・グループのスレッドへの再割当て
スタンバイ REDO ログ・ファイル・グループの構成が適切であるかの判断
スタンバイ REDO ログのログ・ファイル・グループ数が適切かどうかを確認する最も容易
な方法は、RFS プロセスのトレース・ファイルとデータベースのアラート・ログを検討する
ことです。アーカイブが完了しないために RFS プロセスが頻繁にグループを待つ必要がある
ことを示すメッセージがいずれかのログに含まれている場合は、スタンバイ REDO ログに
ログ・ファイル・グループを追加します。スタンバイ REDO ログ・ファイル・グループを
追加することにより、スタンバイ REDO ログ・ファイルが RFS プロセスで再利用される前
に、アーカイブ操作を完了する時間が確保されます。
5-36　Oracle Data Guard 概要および管理
ログ・ファイルの管理
注意 : オンライン REDO ログ・ファイル・グループをプライマリ・デー
タベースに追加した場合は、対応するスタンバイ REDO ログ・ファイル・
グループをスタンバイ・データベースに追加する必要があります。スタン
バイ REDO ログ・ファイル・グループの数がオンライン REDO ログ・
ファイル・グループの数に対して不十分な場合、プライマリ・データベー
スが最大保護モードで作動しているときは停止し、最大可用性モードで作
動しているときは最大パフォーマンス・モードに切り替わります。
スタンバイ REDO ログ・メンバーを既存のグループに追加
スタンバイ REDO ログ・ファイルの完全なグループを作成する必要がない場合もあります。
グループがすでに存在するものの、1 つ以上のメンバーが削除されているため完全ではない
ことがあります（たとえば、ディスク障害のために）
。この場合には、新しいメンバーを既
存のグループに追加できます。
スタンバイ REDO ログ・ファイル・グループに新しいメンバーを追加するには、ALTER
DATABASE 文と ADD STANDBY LOGFILE MEMBER 句を使用します。次の文は、新しいメン
バーをスタンバイ REDO ログ・ファイル・グループの番号 2 に追加します。
SQL> ALTER DATABASE ADD STANDBY LOGFILE MEMBER '/disk1/oracle/dbs/log2b.rdo'
2> TO GROUP 2;
ファイルの作成場所を示すために新しいメンバーの完全修飾されたファイル名を使用しま
す。完全修飾されたファイル名を使用しないと、データベースのデフォルト・ディレクトリ
またはカレント・ディレクトリのいずれかにファイルが作成されます。
スタンバイ REDO ログ・グループのスレッドへの再割当て
THREAD 句を使用してスタンバイ REDO ログ・グループを特定のスレッドに事前割当てし、
後にスレッドを再割り当てする必要がある場合、まずスタンバイ REDO ログ・グループを
削除し（DROP LOGFILE 句を使用）
、ALTER DATABASE ADD STANDBY LOGFILE
THREAD n 文を使用して再び追加します。
ログ転送サービス
5-37
ログ・ファイルの管理
制御ファイルのサイズ拡大と再利用の計画
この項は、次の項目で構成されています。
■
制御ファイルを含むディスク・ボリュームのサイズ設定
■
制御ファイル内のレコードの再利用の指定
制御ファイルを含むディスク・ボリュームのサイズ設定
アーカイブ REDO ログ・ファイルが生成され、Recovery Manager のバックアップが作成さ
れると、制御ファイルの再利用可能セクションに新規レコードが追加されます。再利用可能
なレコードがない場合（すべてのレコードが CONTROL_FILE_RECORD_KEEP_TIME で指定
された日数の範囲内にあるためなど）
、制御ファイルが拡張され、新規レコードが追加され
ます。
制御ファイルの最大サイズは 20000 データベース・ブロックです。DB_BLOCK_SIZE が 8192
の場合、制御ファイルの最大サイズは 156 MB です。制御ファイルが事前作成済ボリューム
に格納される場合は、プライマリおよびスタンバイ制御ファイルを含むボリュームのサイズ
を最大サイズの制御ファイルが収まるように設定する必要があります。制御ファイルのボ
リュームが小さすぎ、拡張できない場合は、意図した再利用の前に制御ファイル内の既存の
レコードが上書きされます。この動作は、アラート・ログの次のメッセージで示されます。
krcpwnc: following controlfile record written over:
制御ファイル内のレコードの再利用の指定
CONTROL_FILE_RECORD_KEEP_TIME 初期化パラメータは、制御ファイル内の再使用可能
レコードが再使用可能になるまでの最小日数を指定します。このパラメータを適切に設定す
ると、ログ転送サービスでは制御ファイル内の再利用可能なレコードが上書きされなくな
り、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-5 ページの「アー
カイブ REDO ログ・ファイルの適用に対するタイム・ディレイの指定」を参照）、十分に大
5-38　Oracle Data Guard 概要および管理
ログ・ファイルの管理
きい値を指定してください。このパラメータの値の範囲は 0 ～ 365 日です。デフォルト値は
7 日です。
CONTROL_FILE_RECORD_KEEP_TIME 初期化パラメータの詳細は、
『Oracle Database リ
ファレンス』を参照してください。また、
『Oracle Database バックアップおよびリカバリ・
アドバンスト・ユーザーズ・ガイド』も参照してください。
複数のスタンバイ・データベース間でのログ・ファイル宛先の共有
LOG_ARCHIVE_DEST_n 初期化パラメータの DEPENDENCY 属性を使用して、各宛先に
REDO データを個別に転送するのではなく、複数の宛先のかわりに REDO データを受信す
るアーカイブ先を 1 つ定義します。
図 5-7 に、Data Guard 構成例を示します。この構成では、プライマリ・データベースは 1 つ
のアーカイブ先に REDO データを転送し、そのアーカイブ REDO ログ・ファイルはロジカ
ル・スタンバイ・データベースおよびフィジカル・スタンバイ・データベースの両方で共有
されます。これらの宛先は、親の宛先へのアーカイブ操作が正常に完了することに依存しま
す。
図 5-7 依存する宛先を含む Data Guard 構成
宛先依存性を指定すると、次に示すような場合に便利です。
■
■
フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースを同じ
システム上で構成する場合。
スタンバイ・データベースとプライマリ・データベースを同じシステム上で構成する場
合。このため、アーカイブ REDO ログ・ファイルが暗黙的にスタンバイ・データベース
の影響を受けやすい状態にあります。
ログ転送サービス
5-39
アーカイブ・ギャップの管理
■
■
クラスタ化されたファイル・システムが、リモートのスタンバイ・データベースにプラ
イマリ・データベースのアーカイブ REDO ログ・ファイルへのアクセスを提供するた
めに使用される場合。
オペレーティング・システム固有のネットワーク・ファイル・システムが使用され、リ
モートのスタンバイ・データベースに、プライマリ・データベースのアーカイブ REDO
ログ・ファイルへのアクセスを提供する場合。
このような場合、ARCn プロセスによって各スタンバイの宛先に REDO データが物理的に
アーカイブされることはありませんが、スタンバイの宛先はアーカイブ REDO ログ・ファ
イルの位置を認識する必要があります。このため、スタンバイ・データベースは、アーカイ
ブ REDO ログ・ファイルがログ適用サービスで適用可能になると、そのアーカイブ REDO
ログ・ファイルにアクセスできます。他（親）の宛先の成功または失敗に依存するように、
アーカイブ先を指定する必要があります。
アーカイブ・ギャップの管理
アーカイブ・ギャップは、スタンバイ・システムが、プライマリ・データベースによって生
アーカイブ・ギャップ
成された 1 つ以上のアーカイブ REDO ログ・ファイルを受信していないときに、スタンバ
イ・システムで発生する可能性があります。欠落しているアーカイブ REDO ログ・ファイル
がギャップです。ギャップがある場合、そのギャップは Data Guard によって自動的に検出
され、欠落しているログ・ファイルの順序番号をスタンバイ宛先にコピーすることで解決さ
れます。たとえば、アーカイブ・ギャップは、ネットワークが使用不可能になり、プライマ
リ・データベースからスタンバイ・データベースへの自動アーカイブが一時的に停止すると
発生する可能性があります。ネットワークが再度使用可能になると、プライマリ・データ
ベースからスタンバイ・データベースへの REDO データの自動転送が再開します。
Data Guard の場合、このようなギャップの検出と解決に、DBA による手動操作は必要あり
ません。次の各項では、ギャップの検出と解決について説明します。
アーカイブ・ギャップの検出時期
アーカイブ・ギャップは、プライマリ・データベースがローカルにアーカイブしたログが、
スタンバイ・サイトでは受信されなかった場合に発生する可能性があります。プライマリ・
データベースは、1 分ごとにスタンバイ・データベースをポーリングして、アーカイブ
REDO ログ・ファイルの順序番号にギャップがあるかどうかを確認します。
5-40　Oracle Data Guard 概要および管理
アーカイブ・ギャップの管理
ギャップの解決方法
ギャップ・リカバリは、ポーリング・メカニズムを使用して処理されます。フィジカルおよ
びロジカル・スタンバイ・データベース、Oracle Change Data Capture および Oracle
Streams の場合、Data Guard はギャップ検出を実行し、欠落しているアーカイブ REDO ロ
グ・ファイルをプライマリ・データベースから自動的に取得することで解決します。スタン
バイ・データベースのポーリング、ギャップの検出または解決のために、余分な構成設定を
行う必要はありません。
ここで重要なことは、自動ギャップ・リカバリの実行には、プライマリ・データベースの可
用性が不可欠であることです。プライマリ・データベースが使用不可能な場合、構成に複数
のフィジカル・スタンバイ・データベースが含まれていれば、REDO Apply によって別のス
タンバイ・データベースからアーカイブ・ギャップを解決できるように初期化パラメータを
追加設定できます。詳細は、
「フェッチ・アーカイブ・ログ（FAL）プロセスを使用した
アーカイブ・ギャップの解決」を参照してください。ギャップを手動で解決する方法を示す
使用例については、10-43 ページの「手動によるアーカイブ・ギャップの解決」を参照して
ください。
注意 : Oracle Database 10g リリース 1（10.1）までは、プライマリ・デー
タベースからのギャップを解決するために FAL クライアントおよびサー
バーが使用されていました。
フェッチ・アーカイブ・ログ（FAL）プロセスを使用したアーカイブ・
）プロセスを使用したアーカイブ・
フェッチ・アーカイブ・ログ（
ギャップの解決
フェッチ・アーカイブ・ログ（FAL）プロセスは、プライマリ・データベースで生成されて
フィジカル・スタンバイ・データベースで受信されたアーカイブ REDO ログ・ファイルの
範囲内で、検出されたギャップを解決します。
■
FAL クライアントは、アーカイブ REDO ログ・ファイルの転送を自動的に要求します。
■
FAL サーバーは、FAL クライアントからの FAL 要求を処理します。
FAL メカニズムでは、次のタイプのアーカイブ・ギャップと問題が処理されます。
■
■
フィジカルまたはロジカル・スタンバイ・データベースの作成時に、FAL メカニズムで
は、プライマリ・データベースのホット・バックアップ中に生成されたアーカイブ
REDO ログ・ファイルを自動的に取得できます。
すでにスタンバイ・データベースで受信されているアーカイブ REDO ログ・ファイルに
問題があると、FAL メカニズムはアーカイブ REDO ログ・ファイルを自動的に取得し
て、次の状況を解決できます。
–
アーカイブ REDO ログ・ファイルが、スタンバイ・データベースに適用される前
にディスクから削除された場合。
–
ディスク破損のためにアーカイブ REDO ログ・ファイルを適用できない場合。
ログ転送サービス
5-41
アーカイブ・ギャップの管理
–
■
REDO データがスタンバイ・データベースに適用される前に、アーカイブ REDO
ログ・ファイルがそれ以外のファイル（テキスト・ファイルなど）によって意図せ
ずに置換された場合。
複数のフィジカル・スタンバイ・データベースがある場合、FAL メカニズムは欠落して
いるアーカイブ REDO ログ・ファイルを別のフィジカル・スタンバイ・データベース
から自動的に取得できます。
FAL クライアントおよびサーバーは、スタンバイ・データベースで設定される FAL_
CLIENT および FAL_SERVER 初期化パラメータを使用して構成されます。初期化パラメー
タ・ファイルの FAL_CLIENT および FAL_SERVER 初期化パラメータを、フィジカル・スタ
ンバイ・データベースに対してのみ次の表に従って定義してください。
パラメータ
機能
構文
FAL_SERVER
このパラメータは、スタン
バイ・データベースが FAL
サーバーへの接続に使用す
るネットワーク・サービス
名を指定します。リストに
は複数の値を指定できます。
構文
FAL_CLIENT
このパラメータは、FAL
サーバーがスタンバイ・
データベースへの接続に使
用するネットワーク・サー
ビス名を指定します。
5-42　Oracle Data Guard 概要および管理
FAL_SERVER=net_service_name
例
FAL_SERVER=standby2_db,standby3_db
構文
FAL_CLIENT=net_service_name
例
FAL_CLIENT=standby1_db
アーカイブ・ギャップの管理
手動によるアーカイブ・ギャップの判断および解決
自動ギャップ・リカバリを実行できず、ギャップ・リカバリを手動で実行する必要がある場
合があります。たとえば、ロジカル・スタンバイ・データベースの使用中にプライマリ・
データベースが使用不可能になった場合は、ギャップ・リカバリを手動で実行する必要があ
ります。
次の各項では、適切なビューを問い合せて欠落しているログ・ファイルを判断し、手動によ
るリカバリを実行する方法を説明します。
フィジカル・スタンバイ・データベースの場合
フィジカル・スタンバイ・データベースにアーカイブ・ギャップが存在するかどうかを判断
するには、次の例に示すように、V$ARCHIVE_GAP ビューを問い合せます。
SQL> SELECT * FROM V$ARCHIVE_GAP;
THREAD#
----------1
LOW_SEQUENCE#
------------7
HIGH_SEQUENCE#
-------------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 を
再開できます。
ログ転送サービス
5-43
アーカイブ・ギャップの管理
注意 : フィジカル・スタンバイ・データベースの V$ARCHIVE_GAP 固定
ビューが戻すのは、REDO Apply の続行をブロックしている次のギャップ
のみです。そのギャップを解決して REDO Apply を開始した後、
V$ARCHIVE_GAP 固定ビューをフィジカル・スタンバイ・データベースで
再度問い合せて、次のギャップ・シーケンス（存在する場合）を判断しま
す。この処理をギャップがなくなるまで繰り返します。
ロジカル・スタンバイ・データベースの場合
アーカイブ・ギャップが存在するかどうかを判断するには、ロジカル・スタンバイ・データ
ベースで DBA_LOGSTDBY_LOG ビューを問い合せます。たとえば、次の問合せでは、ロジカ
ル・スタンバイ・データベースの THREAD 1 に、2 つのファイルが表示されているため、
アーカイブ REDO ログ・ファイルの順序番号にギャップがあることを示しています
（ギャップがない場合、問合せで表示されるのは、スレッドごとに 1 つのファイルのみで
す）
。この出力は、登録されたファイルの最大の順序番号は 10 ですが、順序番号 6 で示され
るファイルにギャップがあることを示しています。
SQL>
SQL>
2>
3>
4>
COLUMN FILE_NAME FORMAT a55
SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L
WHERE NEXT_CHANGE# NOT IN
(SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#)
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-44　Oracle Data Guard 概要および管理
確認
確認
この項は、次の項目で構成されています。
■
ログ・ファイル・アーカイブ情報の監視
■
ログ転送サービスのパフォーマンスの監視
ログ・ファイル・アーカイブ情報の監視
この項では、ビューを使用してプライマリ・データベースの REDO ログ・アーカイブ・ア
クティビティを監視する方法を説明します。Data Guard 環境の監視に関係する多数のタスク
を自動化するグラフィカル・ユーザー・インタフェースの詳細は、
『Oracle Data Guard
Broker』および Oracle Enterprise Manager のオンライン・ヘルプを参照してください。
手順 1 カレント・アーカイブ REDO ログ・ファイルの順序番号を判定する
プライマリ・データベースで次の問合せを入力して、カレント・アーカイブ REDO ログ・
ファイルの順序番号を判定します。
SQL> SELECT THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$LOG
2> WHERE STATUS='CURRENT';
手順 2 最新のアーカイブ REDO ログ・ファイルを判定する
プライマリ・データベースで次の問合せを入力して、最後に転送された REDO データが含
まれているアーカイブ 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
-----------------/private1/prmy/lad
standby1
STATUS
-----VALID
VALID
ARCHIVED_THREAD#
---------------1
1
ARCHIVED_SEQ#
------------947
947
最後に書き込まれたアーカイブ REDO ログ・ファイルは、リストされた各アーカイブ先で
同じである必要があります。同じでない場合は、その宛先へのアーカイブ操作の間に検出さ
れたエラーは VALID 以外のステータスで表示されます。
ログ転送サービス
5-45
確認
手順 4 アーカイブ REDO ログ・ファイルが受信されたかどうかを確認する
アーカイブ REDO ログ・ファイルが特定のサイトで受信されなかったかどうかは、プライ
マリ・データベースで問合せを発行して確認できます。各宛先には対応付けられた ID 番号
があります。プライマリ・データベースの V$ARCHIVE_DEST 固定ビューの DEST_ID 列に問
合せを発行して、各宛先の ID 番号を特定できます。
カレント・ローカル宛先が 1 で、リモート・スタンバイ宛先の ID の 1 つが 2 とします。こ
の場合、どのログ・ファイルがこのスタンバイ宛先で欠落しているかを特定するために、次
の問合せを発行します。
SQL>
2>
3>
4>
5>
6>
SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM
(SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1)
LOCAL WHERE
LOCAL.SEQUENCE# NOT IN
(SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND
THREAD# = LOCAL.THREAD#);
THREAD#
--------1
1
1
SEQUENCE#
--------12
13
14
プライマリ・データベースのアーカイブ・ステータス監視の詳細は、付録 A を参照してくだ
さい。
手順 5 スタンバイ・サイトで転送された REDO の進行状況をトレースする
スタンバイ宛先への REDO データの転送の進行状況を確認するには、プライマリおよびス
タンバイ初期化パラメータ・ファイルに LOG_ARCHIVE_TRACE パラメータを設定します。
詳細と例は、付録 E を参照してください。
5-46　Oracle Data Guard 概要および管理
確認
ログ転送サービスのパフォーマンスの監視
この項では、ログ転送サービスのパフォーマンスを監視する待機イベントについて説明しま
す。これらのログ転送サービスは、プライマリ・データベースで、LOG_ARCHIVE_DEST_n
初期化パラメータの ARCH、LGWR、SYNC および ASYNC 属性で指定されます。
次の各項では、V$SYSTEM_EVENT ビューで表示される待機イベントおよび関連する時間情
報について説明します。
■
ARCn プロセスの待機イベント
■
LGWR SYNC=NOPARALLEL 待機イベント
■
LGWR ASYNC 待機イベント
■
ネットワーク・サーバー（LNSn）待機イベント
ARCn プロセスの待機イベント
表 5-3 に、ARCn アーカイブ・プロセスについて、プライマリ・データベースのオンライン
REDO ログ・ファイルに REDO データを書き込む所要時間を監視する待機イベントを示し
ます。ARCn アーカイブ・プロセスについては、「アーカイバ・プロセス（ARCn）を使用し
た REDO データのアーカイブ」を参照してください。
表 5-3 ARCH 属性で構成される宛先の待機イベント
待機イベント
待機時間の監視対象 . .
ARCH wait on ATTACH
すべての ARCn プロセスによる RFS 接続の生成。
ARCH wait on SENDREQ
すべての ARCn プロセスによる、受信した REDO データのディス
クへの書込み、およびリモートのアーカイブ REDO ログ・ファイ
ルのオープンおよびクローズ。
ARCH wait on DETACH
すべての ARCn プロセスによる RFS 接続の削除。
LGWR SYNC=NOPARALLEL 待機イベント
表 5-4 に、LGWR SYNC=NOPARALLEL アーカイブ・プロセスについて、プライマリ・データ
ベースの LGWR プロセスによる次の操作の実行所要時間を監視する待機イベントを示しま
す。
■
プライマリ・データベースのオンライン REDO ログ・ファイルへの書込み完了
■
リモート・スタンバイ宛先への REDO データの転送
■
スタンバイ REDO ログ・ファイルへの REDO データ書込みの待機
■
リモート・スタンバイ宛先からの応答の受信
LGWR SYNC アーカイブ・プロセスについては、
「ログ・ライター・プロセス（LGWR）を使
用した REDO データのアーカイブ」を参照してください。
ログ転送サービス
5-47
確認
表 5-4 LGWR SYNC 属性で構成される宛先の待機イベント
待機イベント
待機時間の監視対象 . .
LGWR wait on ATTACH
すべての LGWR プロセスによる RFS 接続の生成。
LGWR wait on SENDREQ
すべての LGWR プロセスによる、受信した REDO データのディ
スクへの書込み、およびリモートのアーカイブ REDO ログ・ファ
イルのオープンおよびクローズ。
LGWR wait on DETACH
すべての LGWR プロセスによる RFS 接続の削除。
LGWR ASYNC 待機イベント
表 5-5 に、LGWR ASYNC アーカイブ・プロセスについて、プライマリ・データベースのオン
ライン REDO ログ・ファイルに REDO データを書き込む所要時間を監視する待機イベント
を示します。LGWR ASYNC アーカイブ・プロセスについては、「ログ・ライター・プロセス
（LGWR）を使用した REDO データのアーカイブ」を参照してください。
表 5-5 LGWR ASYNC 属性で構成される宛先の待機イベント
待機イベント
待機時間の監視対象 . .
LNS wait on ATTACH
すべてのネットワーク・サーバーによる RFS 接続の生成。
LNS wait on SENDREQ
すべてのネットワーク・サーバーによる、受信した REDO データ
のディスクへの書込み、およびリモートのアーカイブ REDO ロ
グ・ファイルのオープンおよびクローズ。
LNS wait on DETACH
すべてのネットワーク・サーバーによる RFS 接続の削除。
LGWR wait on full LNS
buffer
ネットワーク・サーバー（LNS）が ASYNC バッファ領域を解放
するまでの、LGWR プロセスの待機。バッファ領域が適切な時間
内に解放されない場合、ARCn プロセスが REDO データを転送す
るため、プライマリ・データベースの可用性は影響を受けない。
注意 : この待機イベントは、LGWR SYNC=NOPARALLEL 属性で構
成されている宛先には関係がありません。
5-48　Oracle Data Guard 概要および管理
確認
ネットワーク・サーバー（LNSn）待機イベント
）待機イベント
ネットワーク・サーバー（
LGWR および ASYNC 属性、または LGWR および SYNC=PARALLEL 属性が有効な場合、
LGWR プロセスはローカルのオンライン REDO ログ・ファイルにアーカイブし、REDO
データをネットワーク経由で非同期で転送する 1 つ以上の LNSn プロセス（宛先ごとに 1
つ）に発行します。表 5-6 に、LGWR および LNSn プロセスによるプロセス間通信（IPC）
チャネルを介した通信の所要時間を監視する待機イベントを示します。LGWR および LNSn
プロセスを使用した構成の詳細は、
「LGWR ASYNC アーカイブ・プロセス」を参照してく
ださい。
表 5-6 LGWR ASYNC または LGWR SYNC=PARALLEL 属性の待機イベント
待機イベント
待機時間の監視対象 . .
LGWR wait on LNS
ネットワーク・サーバーから IPC チャネルでメッセージを受信す
るまでの LGWR プロセスの待機。
LNS wait on LGWR
LGWR プロセスから IPC チャネルでメッセージを受信するまでの
ネットワーク・サーバーの待機。
LGWR-LNS wait on channel IPC チャネルでメッセージを受信するまでの LGWR プロセスまた
はネットワーク・サーバー・プロセスの待機。
ログ転送サービス
5-49
確認
5-50　Oracle Data Guard 概要および管理
6
ログ適用サービス
この章では、REDO データをスタンバイ・データベースに適用する方法について説明しま
す。この章は、次の項目で構成されています。
■
ログ適用サービスの概要
■
ログ適用サービスの構成オプション
■
REDO データのフィジカル・スタンバイ・データベースへの適用
■
REDO データのロジカル・スタンバイ・データベースへの適用
■
フィジカル・スタンバイ・データベースに関するログ適用レートのチューニング
ログ適用サービス
6-1
ログ適用サービスの概要
ログ適用サービスの概要
ログ適用サービスは、スタンバイ・データベースに
REDO を自動的に適用して、プライマ
ログ適用サービス
リ・データベースとの同期を維持します。また、データに対するトランザクションの一貫性
のあるアクセスを可能にします。
デフォルトでは、ログ適用サービスは、いっぱいになったアーカイブ REDO ログ・ファイ
ルがスタンバイ・データベースで受信されるのを待機してから、スタンバイ・データベース
にリカバリします。5-11 ページの「アーカイバ・プロセス（ARCn）を使用した REDO デー
タのアーカイブ」および 5-16 ページの「ログ・ライター・プロセス（LGWR）を使用した
REDO データのアーカイブ」では、プライマリ・データベースから転送された REDO デー
タが、スタンバイ・システムのリモート・ファイル・サーバー・プロセス（RFS）でどのよ
うに受信されるかについて説明しました。スタンバイ・システムでは、RFS プロセスによ
り、アーカイブ REDO ログ・ファイルまたはスタンバイ REDO ログ・ファイル（オプショ
ン）に REDO データが書き込まれます。ただし、スタンバイ REDO ログ・ファイルを使用
している場合は、オプションでリアルタイム適用
リアルタイム適用を使用可能にできます。リアルタイム適用
リアルタイム適用
により、Data Guard では、現在のスタンバイ REDO ログ・ファイルが RFS プロセスによっ
ていっぱいになったときに、現在のスタンバイ REDO ログ・ファイルから REDO データを
リカバリできます。リアルタイム適用については、「リアルタイム適用による REDO データ
の即時適用」を参照してください。
ログ適用サービスは、次の方法でフィジカル・スタンバイ・データベースとロジカル・スタ
ンバイ・データベースをメンテナンスします。
■
REDO Apply（フィジカル・スタンバイ・データベースのみ）
メディア・リカバリを使用して、プライマリ・データベースとフィジカル・スタンバ
イ・データベースの同期を維持します。
注意 : ユーザーがレポート生成のためにスタンバイ・データベースを問
合せできるように、フィジカル・スタンバイ・データベースを読取り専用
モードでオープンすることもできます。オープン中も REDO データは受信
されます。ただし、REDO Apply は停止し、フィジカル・スタンバイ・
データベースでは、プライマリ・データベースとのトランザクションの同
期が維持されません。このときに障害が発生すると、フェイルオーバー操
作が完了するまでに時間がかかる場合があります。詳細は、8-4 ページの
「読取り専用アクセス用にオープンしたスタンバイ・データベースの使用」
を参照してください。
6-2　Oracle Data Guard 概要および管理
ログ適用サービスの構成オプション
■
SQL Apply（ロジカル・スタンバイ・データベースのみ）
プライマリ・データベースから受信した REDO に基づいて SQL 文を再構成し、その
SQL 文をロジカル・スタンバイ・データベースに対して実行します。
ロジカル・スタンバイ・データベースは、読取り / 書込みモードでオープンできます
が、レポート生成のためにロジカル・スタンバイ・データベースでメンテナンスされて
いるターゲット表は読取り専用モードでオープンします（9-4 ページの「ロジカル・ス
タンバイ・データベース内の表に対するユーザー・アクセスの制御」で説明するよう
に、データベース・ガードが適切に設定されている場合）
。SQL Apply を使用すると、
SQL 文が適用されている間でも、ロジカル・スタンバイ・データベースをレポート・ア
クティビティで使用できます。
この章の各項では、REDO Apply、SQL Apply、リアルタイム適用および適用の遅延につい
て詳細に説明します。
ログ適用サービスの構成オプション
この項は、次の項目で構成されています。
■
リアルタイム適用による REDO データの即時適用
■
アーカイブ REDO ログ・ファイルの適用に対するタイム・ディレイの指定
リアルタイム適用による REDO データの即時適用
リアルタイム適用機能が使用可能になっている場合、ログ適用サービスでは、現在のスタン
バイ REDO ログ・ファイルがアーカイブされるのを待機せずに REDO データを受信したと
きに、REDO データを適用できます。これにより、スイッチオーバーおよびフェイルオー
バーが高速化されます。これは、フェイルオーバーまたはスイッチオーバーが開始されるま
でに、スタンバイ REDO ログ・ファイルがスタンバイ・データベースにすでに適用されて
いるためです （リアルタイム適用を使用するには、スタンバイ REDO ログ・ファイルが必
要です）
。
図 6-1 に、ローカル宛先とスタンバイ宛先がある Data Guard 構成を示します。リモート・
ファイル・サーバー（RFS）プロセスは、スタンバイ・データベース上のスタンバイ REDO
ログ・ファイルに REDO データを書き込むため、ログ適用サービスでは、いっぱいになっ
たときにスタンバイ REDO ログ・ファイルから REDO をリカバリできます。
ログ適用サービス
6-3
ログ適用サービスの構成オプション
図 6-1 リアルタイム適用を使用したスタンバイ宛先への REDO データの適用
次のように、ALTER DATABASE 文を使用して、リアルタイム適用機能を使用可能にします。
■
■
フィジカル・スタンバイ・データベースの場合は、ALTER DATABASE RECOVER
MANAGED STANDBY DATABASE USING CURRENT LOGFILE 文を発行します。
ロジカル・スタンバイ・データベースの場合は、ALTER DATABASE START LOGICAL
STANDBY APPLY IMMEDIATE 文を発行します。
リアルタイム適用が使用可能になっているかどうかを判断するには、V$ARCHIVE_DEST_
STATUS ビューの RECOVERY_MODE 列を問い合せます。リアルタイム適用が使用可能になっ
ている場合は、MANAGED REAL TIME APPLY が表示されます。
6-4　Oracle Data Guard 概要および管理
ログ適用サービスの構成オプション
アーカイブ REDO ログ・ファイルの適用に対するタイム・ディレイの指定
プライマリ・サイトから REDO データを受信した後、その REDO データをスタンバイ・
データベースに適用するまでの間にタイム・ラグを作成することが必要な場合があります。
時間間隔（分単位）を指定すると、破損したデータや誤ったデータがスタンバイ・サイトに
適用されるのを防止できます。DELAY 間隔を設定すると、スタンバイ・データベースへの
REDO データの転送が遅延することはありません。かわりに、指定したタイム・ラグは、
REDO データがスタンバイ宛先で完全にアーカイブされたときに開始します。
注意 : リアルタイム適用が使用可能になっている宛先に遅延を定義する
と、その遅延は無視されます。
タイム・ディレイの指定
次のように、プライマリ・データベースとスタンバイ・データベースでタイム・ディレイを
設定できます。
■
■
プライマリ・データベースおよびフィジカル・スタンバイ・データベースで、LOG_
ARCHIVE_DEST_n 初期化パラメータの DELAY=minutes 属性を使用して、スタンバイ・
データベースへのアーカイブ REDO ログ・ファイルの適用を遅延します。この属性の
デフォルト設定は、NODELAY です。値を指定せずに DELAY 属性を指定すると、デフォ
ルトの遅延間隔は 30 分になります。
ロジカル・スタンバイ・データベースで、DBMS_LOGSTDBY.APPLY_SET プロシージャ
を使用します。
スタンバイ・データベースで時間遅延を設定すると、プライマリ・データベースに指定され
た時間遅延より優先されます。次に例を示します。
SQL> RECOVER MANAGED STANDBY DATABASE DELAY <minutes>
複数のスタンバイ・データベースがある構成では、1 つ以上のスタンバイ・データベースに
タイム・ラグを設定すると非常に便利な場合があります。たとえば、プライマリ・データ
ベースと様々なレベルで同期させる各スタンバイ・データベースを維持する構成を設定でき
ます。
タイム・ディレイの取消し
次のように、指定した遅延間隔を取り消すことができます。
■
プライマリ・データベースおよびフィジカル・スタンバイ・データベースで、RECOVER
MANAGED STANDBY DATABASE 句の NODELAY キーワードを使用します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
ログ適用サービス
6-5
ログ適用サービスの構成オプション
■
ロジカル・スタンバイ・データベースで、次の PL/SQL コマンドを指定します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;
これらのコマンドにより、時間間隔が経過する前に、ログ適用サービスで、スタンバイ・
データベースへのアーカイブ REDO ログ・ファイルの適用が即時に開始されます。次の項お
よびマニュアルも参照してください。
■
■
■
10-35 ページの「タイム・ラグのあるフィジカル・スタンバイ・データベースの使用」
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 文の DELAY 属性につい
ては、
『Oracle Database SQL リファレンス』を参照してください。
DBMS_LOGSTDBY.APPLY_SET プロシージャを使用したロジカル・スタンバイ・データ
ベースについては、
『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』
を参照してください。
タイム・ディレイ設定の代替策としてのフラッシュバック・データ
ベースの使用
適用遅延構成オプションのかわりにフラッシュバック・データベースを使用して、スタンバ
イ・データベースへの破損データやエラー・データの適用を防止できます。フラッシュバッ
ク・データベースを使用すると、スタンバイ・データベースを任意の時点まで、すばやく容
易にフラッシュ・バックできます。フラッシュバック・データベースを有効にして使用する
方法の詳細は、
『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザー
ズ・ガイド』を参照してください。
Data Guard とフラッシュバック・データベースの併用方法の使用例は第 10 章を、フラッ
シュバック・データベースを有効にして使用する方法の詳細は『Oracle Database バック
アップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。
6-6　Oracle Data Guard 概要および管理
REDO データのフィジカル・スタンバイ・データベースへの適用
REDO データのフィジカル・スタンバイ・データベースへの適用
デフォルトでは、アーカイブ REDO ログ・ファイルからの REDO データが適用されます。
REDO Apply を実行している場合、フィジカル・スタンバイ・データベースはリアルタイム
機能を使用して、スタンバイ REDO ログ・ファイルが RFS プロセスによって書き込まれて
いるときに、スタンバイ REDO ログ・ファイルから直接 REDO を適用できます。また、ロ
グ適用サービスは、フィジカル・スタンバイ・データベースが読取り専用でオープンしてい
るときは、REDO データをデータベースに適用できません。
この項は、次の項目で構成されています。
■
REDO Apply の開始
■
リアルタイム適用の開始
■
ログ適用サービスの停止
■
フィジカル・スタンバイ・データベースでのログ適用サービスの監視
REDO Apply の開始
フィジカル・スタンバイ・データベースでログ適用サービスを開始するには、フィジカル・
スタンバイ・データベースが起動されマウントされていることを確認してから、SQL ALTER
DATABASE RECOVER MANAGED STANDBY DATABASE 文を使用して REDO Apply を開始し
ます。
REDO Apply をフォアグラウンド・セッションとして実行するか、バックグラウンド・プロ
セスとして実行するかを指定できます。
■
フィジカル・スタンバイ・データベースでアーカイブ REDO ログを使用してデータベー
スをリカバリするフォアグラウンド・セッションを開始するには、次の SQL 文を発行
します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
フォアグラウンド・セッションを開始すると、デフォルトでは、別のセッションでリカ
バリが取り消されるまで、制御がコマンド・プロンプトに戻りません。
■
フィジカル・スタンバイ・データベースでアーカイブ REDO ログを使用してデータベー
スをリカバリするバックグラウンド・プロセスを開始するには、SQL 文で
DISCONNECT キーワードを使用する必要があります。次に例を示します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
この文によって、分離されたサーバー・プロセスが起動し、即時に制御がユーザーに戻
されます。管理リカバリ・プロセスがバックグラウンドでリカバリを実行している間、
RECOVER 文を発行したフォアグラウンド・プロセスは、他のタスクの実行を継続でき
ます。これによって、カレント SQL セッションが切断されることはありません。
ログ適用サービス
6-7
REDO データのフィジカル・スタンバイ・データベースへの適用
リアルタイム適用の開始
リアルタイム適用を開始するには、SQL 文に USING CURRENT LOGFILE 句を含めます。次
に例を示します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
ログ適用サービスの停止
REDO Apply またはリアルタイム適用を停止するには、別のウィンドウで次の SQL 文を発
行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
フィジカル・スタンバイ・データベースでのログ適用サービスの監視
フィジカル・スタンバイ・データベースのアーカイブ REDO ログの状況を監視し、ログ適
用サービスに関する情報を取得するには、この項で説明する固定ビューを問い合せます。ス
タンバイ・データベースは、Oracle Enterprise Manager GUI を使用して監視することもでき
ます。
この項は、次の項目で構成されています。
■
V$MANAGED_STANDBY 固定ビューへのアクセス
■
V$ARCHIVE_DEST_STATUS 固定ビューへのアクセス
■
V$ARCHIVED_LOG 固定ビューへのアクセス
■
V$LOG_HISTORY 固定ビューへのアクセス
■
V$DATAGUARD_STATUS 固定ビューへのアクセス
ビューの詳細は、
『Oracle Database リファレンス』を参照してください。
V$MANAGED_STANDBY 固定ビューへのアクセス
スタンバイ・サイトでログ適用サービスおよびログ転送サービスのアクティビティを監視す
るには、フィジカル・スタンバイ・データベースを問い合せます。
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS
2> FROM V$MANAGED_STANDBY;
PROCESS
------RFS
MRP0
STATUS
-----------ATTACHED
APPLYING_LOG
6-8　Oracle Data Guard 概要および管理
THREAD#
---------1
1
SEQUENCE#
---------947
946
BLOCK#
---------72
10
BLOCKS
---------72
72
REDO データのフィジカル・スタンバイ・データベースへの適用
この問合せ出力は、RFS プロセスが REDO ログ・ファイル順序番号 947 のアーカイブを完了
したことを示しています。また、この出力は、アーカイブ REDO ログ・ファイル順序番号
946 を適用している REDO Apply も示しています。このリカバリ操作では現在、72 ブロッ
クのアーカイブ REDO ログ・ファイルのブロック番号 10 をリカバリしている最中です。
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 つ分遅れていることを示しています。これは、単一のリカバリ処
理では、受信しているアーカイブ REDO ログ・ファイルのボリュームに追いつくことがで
きないことを示している可能性があります。これを解決するには、PARALLEL オプションを
使用します。
リアルタイム適用が使用可能になっているかどうかを判断するには、V$ARCHIVE_DEST_
STATUS ビューの RECOVERY_MODE 列を問い合せます。リアルタイム適用が使用可能になっ
ている場合は、次の例に示すように、値 MANAGED REAL TIME が含まれます。
SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2 ;
RECOVERY_MODE
----------------------MANAGED REAL-TIME APPLY
V$ARCHIVED_LOG 固定ビューへのアクセス
フィジカル・スタンバイ・データベース上の V$ARCHIVED_LOG 固定ビューには、プライマ
リ・データベースから受信したすべてのアーカイブ REDO ログ・ファイルが表示されます。
このビューが役に立つのは、スタンバイ・サイトが REDO データの受信を開始した後のみ
です。それ以前のビューは、プライマリ制御ファイルから生成された旧アーカイブ REDO
ログ・レコードによって移入されたものであるためです。
たとえば、次の SQL*Plus 文を実行できます。
SQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#, FIRST_CHANGE#,
2> NEXT_CHANGE# FROM V$ARCHIVED_LOG;
ログ適用サービス
6-9
REDO データのフィジカル・スタンバイ・データベースへの適用
REGISTRAR
--------RFS
RFS
RFS
CREATOR
------ARCH
ARCH
ARCH
THREAD#
---------1
1
1
SEQUENCE#
---------945
946
947
FIRST_CHANGE#
------------74651
74739
74772
NEXT_CHANGE#
-----------74739
74772
74774
この問合せ出力は、プライマリ・データベースから受信した 3 つのアーカイブ REDO ログ・
ファイルを示しています。
V$LOG_HISTORY 固定ビューへのアクセス
フィジカル・スタンバイ・データベースで V$LOG_HISTORY 固定ビューを問い合せると、適
用されたすべてのアーカイブ REDO ログ・ファイルが表示されます。
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE#
2> FROM V$LOG_HISTORY;
THREAD#
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- -----------1
945
74651
74739
この問合せ出力は、最も最近適用されたアーカイブ REDO ログ・ファイルが順序番号 945 で
あったことを示しています。
V$DATAGUARD_STATUS 固定ビューへのアクセス
V$DATAGUARD_STATUS 固定ビューには、通常はアラート・ログまたはサーバー・プロセス
のトレース・ファイルへのメッセージによってトリガーされるイベントが表示されます。
次の例は、プライマリ・データベースでの V$DATAGUARD_STATUS ビューの出力を示しま
す。
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
MESSAGE
-------------------------------------------------------------------------------ARC0: Archival started
ARC1: Archival started
Archivelog destination LOG_ARCHIVE_DEST_2 validated for no-data-loss
recovery
Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2'
ARCH: Transmitting activation ID 0
LGWR: Completed archiving log 3 thread 1 sequence 11
Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2'
LGWR: Transmitting activation ID 6877c1fe
LGWR: Beginning to archive log 4 thread 1 sequence 12
ARC0: Evaluating archive
log 3 thread 1 sequence 11
ARC0: Archive destination LOG_ARCHIVE_DEST_2: Previously completed
6-10　Oracle Data Guard 概要および管理
REDO データのフィジカル・スタンバイ・データベースへの適用
ARC0: Beginning to archive log 3 thread 1 sequence 11
Creating archive destination LOG_ARCHIVE_DEST_1:
'/oracle/arch/arch_1_11.arc'
ARC0: Completed archiving log 3 thread 1 sequence 11
ARC1: Transmitting activation ID 6877c1fe
15 rows selected.
次の例は、フィジカル・スタンバイ・データベースでの V$DATAGUARD_STATUS ビューの内
容を示します。
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
MESSAGE
-------------------------------------------------------------------------------ARC0: Archival started
ARC1: Archival started
RFS: Successfully opened standby logfile 6: '/oracle/dbs/sorl2.log'
ARC1: Evaluating archive
log 6 thread 1 sequence 11
ARC1: Beginning to archive log 6 thread 1 sequence 11
Creating archive destination LOG_ARCHIVE_DEST_1:
'/oracle/arch/arch_1_11.arc'
ARC1: Completed archiving log 6 thread 1 sequence 11
RFS: Successfully opened standby logfile 5: '/oracle/dbs/sorl1.log'
Attempt to start background Managed Standby Recovery process
Media Recovery Log /oracle/arch/arch_1_9.arc
10 rows selected.
ログ適用サービス
6-11
REDO データのロジカル・スタンバイ・データベースへの適用
REDO データのロジカル・スタンバイ・データベースへの適用
ログ適用サービスは、アーカイブ REDO ログまたはスタンバイ REDO ログのデータを SQL
文に変換してから、その SQL 文をロジカル・スタンバイ・データベースで実行します。ロ
ジカル・スタンバイ・データベースはオープン状態のままであるため、メンテナンスされる
表は、レポート生成、要約、問合せなどの他のタスクで同時に使用できます。
この項は、次の項目で構成されています。
■
SQL Apply の開始
■
リアルタイム適用の開始
■
ロジカル・スタンバイ・データベースでのログ適用サービスの停止
■
ロジカル・スタンバイ・データベースに関するログ適用サービスの監視
SQL Apply の開始
SQL Apply を開始するには、ロジカル・スタンバイ・データベースを起動し、次の文を発行
して、ロジカル・スタンバイ・データベースのアーカイブ REDO ログ・ファイルから
REDO データをリカバリします。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
リアルタイム適用の開始
ロジカル・スタンバイ・データベースでリアルタイム適用を開始して、ロジカル・スタンバ
イ・データベースのスタンバイ REDO ログ・ファイルから REDO データを即時にリカバリ
するには、次の文に示すように、IMMEDIATE キーワードを含めます。
SQL>
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
ロジカル・スタンバイ・データベースでのログ適用サービスの停止
SQL Apply を停止するには、ロジカル・スタンバイ・データベースで次の文を発行します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
6-12　Oracle Data Guard 概要および管理
REDO データのロジカル・スタンバイ・データベースへの適用
ロジカル・スタンバイ・データベースに関するログ適用サービスの監視
アーカイブ REDO ログ・ファイルの状況を監視し、SQL Apply に関する情報を取得するに
は、この項で説明する固定ビューを問い合せます。スタンバイ・データベースは、Oracle
Enterprise Manager GUI を使用して監視することもできます。付録 A「Data Guard のトラ
ブルシューティング」および『Oracle Data Guard Broker』を参照してください。
この項は、次の項目で構成されています。
■
DBA_LOGSTDBY_EVENTS ビューへのアクセス
■
DBA_LOGSTDBY_LOG ビューへのアクセス
■
DBA_LOGSTDBY_PROGRESS ビューへのアクセス
■
V$LOGSTDBY 固定ビューへのアクセス
■
V$LOGSTDBY_STATS 固定ビューへのアクセス
また、ビューの詳細は、
「V$ARCHIVE_DEST_STATUS 固定ビューへのアクセス」の
V$ARCHIVE_DEST_STATUS 固定ビューの説明および『Oracle Database リファレンス』を参
照してください。
DBA_LOGSTDBY_EVENTS ビューへのアクセス
SQL Apply が突然停止した場合は、このビューにその原因が表示されます。
注意 : SQL Apply の停止原因となったエラーは、システム表領域に十分
な領域があるかぎり、イベント表に記録されます。これらのイベントは、
ALERT.LOG ファイルにも格納され、テキストには、LOGSTDBY キーワー
ドが含まれます。このビューを問い合せたときは、EVENT_TIME、
COMMIT_SCN、CURRENT_SCN の順で列を選択してください。この順序に
よって、停止障害がビューの最後に表示されます。
ログ適用サービス
6-13
REDO データのロジカル・スタンバイ・データベースへの適用
このビューには、適用された DDL 文やスキップされた DDL 文などの他の情報も表示されま
す。次に例を示します。
SQL> ALTER SESSION SET NLS_DATE_FORMAT
Session altered.
= 'DD-MON-YY HH24:MI:SS';
SQL> COLUMN STATUS FORMAT A60
SQL> SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS
2 ORDER BY EVENT_TIME, COMMIT_SCN;
EVENT_TIME
STATUS
-----------------------------------------------------------------------------EVENT
------------------------------------------------------------------------------23-JUL-02 18:20:12 ORA-16111: ログのマイニングと設定の適用
23-JUL-02 18:20:12 ORA-16128: ユーザーが開始した停止は、正常に完了しました。
23-JUL-02 18:20:12 ORA-16112: ログのマイニングと停止の適用
23-JUL-02 18:20:23 ORA-16111: ログのマイニングと設定の適用
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 mytable (one number, two varchar(30))
23-JUL-02 20:22:55 ORA-16205: DDL はスキップ設定のためスキップされました create database
link mydblink
8 rows selected.
この問合せは、SQL Apply の開始と停止が数回繰り返されたことを示しています。適用され
た DDL とスキップされた DDL も示しています。SQL Apply が停止した場合は、問合せの最
後のレコードに問題の原因が表示されます。
DBA_LOGSTDBY_LOG ビューへのアクセス
DBA_LOGSTDBY_LOG ビューには、SQL Apply の処理状況に関する動的な情報が表示されま
す。このビューは、アーカイブ REDO ログ・ファイルをロジカル・スタンバイ・データベー
スに適用するときの SQL Apply のパフォーマンスに関する問題の診断に役立ちます。また、
他の問題にも役立ちます。
次に例を示します。
SQL>
SQL>
2>
3>
COLUMN DICT_BEGIN FORMAT A10;
SELECT FILE_NAME, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE#,
TIMESTAMP, DICT_BEGIN, DICT_END, THREAD# AS THR# FROM DBA_LOGSTDBY_LOG
ORDER BY SEQUENCE#;
6-14　Oracle Data Guard 概要および管理
REDO データのロジカル・スタンバイ・データベースへの適用
FILE_NAME
------------------------/oracle/dbs/hq_nyc_2.log
/oracle/dbs/hq_nyc_3.log
/oracle/dbs/hq_nyc_4.log
/oracle/dbs/hq_nyc_5.log
/oracle/dbs/hq_nyc_6.log
/oracle/dbs/hq_nyc_7.log
/oracle/dbs/hq_nyc_8.log
/oracle/dbs/hq_nyc_9.log
/oracle/dbs/hq_nyc_10.log
/oracle/dbs/hq_nyc_11.log
/oracle/dbs/hq_nyc_12.log
/oracle/dbs/hq_nyc_13.log
SEQ# FIRST_CHANGE# NEXT_CHANGE# TIMESTAM BEG
---- ------------- ------------ -------- --2
101579
101588 11:02:58 NO
3
101588
142065 11:02:02 NO
4
142065
142307 11:02:10 NO
5
142307
142739 11:02:48 YES
6
142739
143973 12:02:10 NO
7
143973
144042 01:02:11 NO
8
144042
144051 01:02:01 NO
9
144051
144054 01:02:16 NO
10
144054
144057 01:02:21 NO
11
144057
144060 01:02:26 NO
12
144060
144089 01:02:30 NO
13
144089
144147 01:02:41 NO
END
--NO
NO
NO
YES
NO
NO
NO
NO
NO
NO
NO
NO
THR#
---1
1
1
1
1
1
1
1
1
1
1
1
この問合せ出力は、LogMiner ディクショナリの作成がログ・ファイルの順序番号 5 で開始
したことを示しています。最新のアーカイブ REDO ログ・ファイルは順序番号 13 で、ロジ
カル・スタンバイ・データベースでは 1 時 2 分 41 秒に受信されています。
DBA_LOGSTDBY_PROGRESS ビューへのアクセス
このビューには、LSP プロセスの状態、およびロジカル・スタンバイ・データベースで実行
された SQL トランザクションに関する情報が表示されます。ログ・ファイルからすべての
REDO が適用されたかどうかを迅速に判断するには、ロジカル・スタンバイ・データベース
で次の問合せを発行します。
SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM D BA_LOGSTDBY_PROGRESS;
APPLIED_SCN NEWEST_SCN
----------- ---------211301
211357
APPLIED_SCN が NEWEST_SCN と一致している場合は、使用可能なすべてのログ情報が適用
されています。使用可能なログ・ファイル全体の進捗状況を調べるには、次の例に示すよう
に、DBA_LOGSTDBY_LOG ビューを問い合せます。
SQL> ALTER SESSION SET NLS_DATE_FORMAT
Session altered.
= 'DD-MON-YY HH24:MI:SS';
SQL> SELECT SEQUENCE#, FIRST_TIME, APPLIED
2
FROM DBA_LOGSTDBY_LOG
3 ORDER BY SEQUENCE#;
ログ適用サービス
6-15
REDO データのロジカル・スタンバイ・データベースへの適用
SEQUENCE# FIRST_TIME
---------- -----------------24 23-JUL-02 18:19:05
25 23-JUL-02 18:19:48
26 23-JUL-02 18:19:51
27 23-JUL-02 18:19:54
28 23-JUL-02 18:19:59
29 23-JUL-02 18:20:03
30 23-JUL-02 18:20:13
31 23-JUL-02 18:20:18
32 23-JUL-02 18:20:21
33 23-JUL-02 18:32:11
34 23-JUL-02 18:32:19
35 23-JUL-02 19:13:20
36 23-JUL-02 19:13:43
37 23-JUL-02 19:13:46
38 23-JUL-02 19:13:50
39 23-JUL-02 19:13:54
40 23-JUL-02 19:14:01
41 23-JUL-02 19:15:11
42 23-JUL-02 19:15:54
19 rows selected.
APPLIED
------YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
CURRENT
CURRENT
CURRENT
CURRENT
CURRENT
CURRENT
CURRENT
NO
NO
この問合せでは、計算結果列の APPLIED 列に、YES、CURRENT または NO が表示されます。
YES が表示されたログ・ファイルは完全に適用されているため、そのログ・ファイルはロジ
カル・スタンバイ・データベースでは不要です。CURRENT が表示されたログ・ファイルに
は、処理中の情報が含まれています。ロジカル・スタンバイがトランザクションを適用し、
トランザクションが複数のログ・ファイルを使用しているため、通常、SQL Apply では複数
のログの変更を適用します。NO が表示されたログの場合、ログ・ファイルの情報は適用さ
れていません。ただし、ファイルはオープンして読み込まれている可能性があります。
V$LOGSTDBY 固定ビューへのアクセス
SQL Apply のプロセス・アクティビティを調べるには、ロジカル・スタンバイ・データベー
スで V$LOGSTDBY 固定ビューを問い合せます。このビューには、REDO データを読み込ん
でいる処理および REDO データをロジカル・スタンバイ・データベースに適用している処
理に関する情報が表示されます。次に例を示します。
SQL> COLUMN STATUS FORMAT A50
SQL> COLUMN TYPE FORMAT A12
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE
HIGH_SCN STATUS
------------ ---------- -------------------------------------------------COORDINATOR
ORA-16117: 処理中です。
READER
ORA-16127: 追加のトランザクションが適用されるまで待機して
停止しました。
6-16　Oracle Data Guard 概要および管理
REDO データのロジカル・スタンバイ・データベースへの適用
BUILDER
191896 ORA-16116: 使用できる作業はありません
PREPARER
191902 ORA-16117: 処理中です。
ANALYZER
191820 ORA-16120: SCN 0x0000.0002ed4e でのトランザクションに
対する依存性を計算中です。
APPLIER
APPLIER
APPLIER
191209 ORA-16124: トランザクション 1 16 1598 は待機中です。
191205 ORA-16116: 使用できる作業はありません
191206 ORA-16124: ランザクション 1 5 1603 は待機中です。
APPLIER
191213 ORA-16117: 処理中です。
APPLIER
191212 ORA-16124: トランザクション 1 20 1601 は待機中です。
APPLIER
191216 ORA-16124: トランザクション 1 4 1602 は待機中です。
11 rows selected
この問合せでは、アーカイブ REDO ログ・ファイルの読取りと適用に関係するプロセスご
とに 1 行が表示されます。TYPE 列に示されているように、プロセスごとに異なる機能を実
行します。HIGH_SCN 列は、進捗状況を示すインジケータです。このインジケータが問合せ
ごとに変化している間は、処理が進行しています。STATUS 列には、アクティビティの説明
テキストが表示されます。
V$LOGSTDBY_STATS 固定ビューへのアクセス
V$LOGSTDBY_STATS 固定ビューには、SQL Apply に関する一連の状態と統計情報が表示さ
れます。ほとんどのオプションにはデフォルト値があり、このビューには現在使用されてい
る値が表示されます。進捗を示す統計情報も表示されます。データベースの状態情報を表示
するには、次の問合せを発行します。
SQL>
SQL>
SQL>
2>
COLUMN NAME FORMAT A35
COLUMN VALUE FORMAT A35
SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME LIKE 'coordinator%' or NAME LIKE 'transactions%';
NAME
----------------------------------coordinator state
transactions ready
transactions applied
coordinator uptime
VALUE
----------------------------------APPLYING
7821
7802
73
この問合せでは、SQL Apply の実行時間とその間に適用されたトランザクションの数が表示
されます。適用可能なトランザクションの数も表示され、さらに作業が必要なことを示して
います。
ログ適用サービス
6-17
フィジカル・スタンバイ・データベースに関するログ適用レートのチューニング
フィジカル・スタンバイ・データベースに関するログ適用
レートのチューニング
次の方法を使用して、フィジカル・スタンバイ・データベースに対する REDO 適用の所要
時間を最適化することを考慮してください。詳細は、次の URL にアクセスして『Oracle
Media Recovery Best Practices』ホワイト・ペーパーを参照してください。
http://otn.oracle.com/deploy/availability/htdocs/maa.htm
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 パラメータは、パラレル問合せ操作でも使用され
ます。いずれかのパラレル問合せ操作でテストして、システムに十分なメモリーがあること
6-18　Oracle Data Guard 概要および管理
フィジカル・スタンバイ・データベースに関するログ適用レートのチューニング
を確認する必要があります。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 を
使用すると、データベース・ファイルのパラレル読取りが大幅に減少し、リカバリ時間全体
が短縮されます。
ログ適用サービス
6-19
フィジカル・スタンバイ・データベースに関するログ適用レートのチューニング
6-20　Oracle Data Guard 概要および管理
7
ロール管理
Data Guard 構成は、プライマリ・ロールで機能する 1 つのデータベース、およびスタンバ
イ・ロールで機能する 1 つ以上のデータベースで構成されています。通常、各データベース
のロールは変更されません。ただし、プライマリ・データベースが停止したとき、または
ハードウェアやソフトウェアのメンテナンスを実行したときに、Data Guard を使用して
サービスを維持する場合、構成内のプライマリ・データベースおよび 1 つのスタンバイ・
データベースのロールを推移させる必要があります。データベースの現行のロールを表示す
るには、V$DATABASE ビューの DATABASE_ROLE 列を問い合せます。
Data Guard 構成内のスタンバイ・データベースの数、位置、タイプ（フィジカルまたはロ
ジカル）
、およびプライマリ・データベースからの REDO データを各スタンバイ・データ
ベースに伝播する方法に応じて、計画的および計画外のプライマリ・データベースの停止に
対して設定できるロール管理オプションが事前に決まります。
この章では、Data Guard 構成内でデータベースのロールを変更および管理するための Data
Guard のロール管理サービスと操作について説明します。この章は、次の項目で構成されて
います。
■
ロールの推移の概要
■
フィジカル・スタンバイ・データベースが関与するロールの推移
■
ロジカル・スタンバイ・データベースが関与するロールの推移
Oracle Data Guard Broker の分散管理フレームワークを使用してスイッチオーバー・プロセ
スとフェイルオーバー・プロセスを 1 つのコマンドで自動化する方法については、
『Oracle
Data Guard Broker』を参照してください。Data Guard Broker には、Data Guard 構成の作
成、メンテナンスおよび監視を自動化および集中化する GUI およびコマンドライン・イン
タフェースが用意されています。
ロール管理
7-1
ロールの推移の概要
ロールの推移の概要
データベースは、相互に排他的な次の 2 つのロールのいずれかで実行されます。2 つのロー
ルとは、プライマリ
プライマリとスタンバイ
Data Guard では、この章で説明する SQL 文を発行
プライマリ スタンバイです。
スタンバイ
するか、Data Guard Broker の GUI またはコマンドライン・インタフェースを使用して、こ
れらのロールを動的に変更できます。Oracle Data Guard は、ロールを推移するための 2 つ
の操作をサポートしています。
■
スイッチオーバー
プライマリ・データベースが、スタンバイ・データベースの 1 つを使用してロールを切
り替えられるようにします。スイッチオーバー時には、データは消失しません。スイッ
チオーバーの完了後、各データベースは、新しいロールとともに Data Guard 構成に継
続して含まれます。
■
フェイルオーバー
プライマリ・データベースの障害時にスタンバイ・データベースをプライマリ・ロール
に推移します。障害の前にプライマリ・データベースが最大保護モードまたは最大可用
性モードで動作していなかった場合、データ消失が発生することがあります。フェイル
オーバーの完了後、障害の発生したデータベースは Data Guard 構成に含まれなくなり
ます。
「使用するロールの推移の選択」では、停止時間およびデータ消失のリスクを最小限にする
ために、どのロールの推移を選択するかについて説明します。「スイッチオーバー」および
「フェイルオーバー」では、それぞれスイッチオーバーとフェイルオーバーの詳細を説明し
ます。
注意 : Oracle Data Guard のスイッチオーバーとフェイルオーバーは、自
動的に起動しません。スイッチオーバーまたはフェイルオーバーは、SQL
文または Data Guard Broker インタフェースを使用して手動で開始する必
要があります。
7-2　Oracle Data Guard 概要および管理
ロールの推移の概要
使用するロールの推移の選択
ロールを推移するとき、操作の完了までに必要な停止時間、データ消失の可能性、および構
成内の他のスタンバイ・データベースへの影響は次の要因から判断します。
■
推移直前のプライマリ・データベースの状態
■
ロールの推移の対象として選択されたスタンバイ・データベースの推移時の状態
■
選択されたスタンバイ・データベースがフィジカル・スタンバイ・データベースとして
構成されているか、またはロジカル・スタンバイ・データベースとして構成されている
か
■
ロールの推移がスイッチオーバーか、またはフェイルオーバーか
■
選択したスタンバイ・データベースに適用されていない REDO データの量
■
スタンバイ・データベースでスタンバイ REDO ログが構成されているかどうか
■
ターゲット・スタンバイ・データベースに対して REDO ログ・ファイルが以前に作成さ
れたかどうか
目標は、データをまったく消失せず、可能なかぎり迅速にロールの推移を実行することで
す。
注意 : 6-3 ページの「リアルタイム適用による REDO データの即時適用」
に説明されているように、リアルタイム適用機能が使用可能でアクティブ
になっている場合、ロールの推移を完了するのに必要な時間が最小限にな
ります。リアルタイム適用により、ログ適用サービスは、スタンバイ
REDO ログ・ファイルがプライマリ・データベースから新しい REDO
データを受信するのと同時に、これらのファイルから REDO データをリ
カバリおよび適用できます。これにより、スタンバイ・データベースとプ
ライマリ・データベースの間のラグが最小限になります。
図 7-1 に示す意思決定ツリーは、停止時間およびデータ消失のリスクを最小限にするために、
どのロールの推移を選択するかを決定するのに役立ちます。
ロール管理
7-3
ロールの推移の概要
図 7-1 ロールの推移を選択するための意思決定ツリー
通常は、プライマリ・データベースの修正とロールの推移のどちらが速いかを検討します。
プライマリ・データベースを修正できる場合は、クライアント・アプリケーションを新しい
データベースに接続するように再構成する必要はありません。ただし、修正操作によって
データが消失した場合は、10-32 ページの「Open Resetlogs 文の発行後のフラッシュバッ
ク・データベースの使用」で説明するようにスタンバイ・データベースをフラッシュ・バッ
クできます。フラッシュバック・データベースが使用可能になっていない場合は、修正した
プライマリ・データベースのバックアップ・コピーから、構成内の他のすべてのスタンバ
イ・データベースを再作成する必要があります。
ロールの推移が適切と判断し、構成内に 1 つ以上のフィジカル・スタンバイ・データベース
が含まれる場合は、最適なフィジカル・スタンバイ・データベースを使用したロールの推移
をお薦めします。ロジカル・スタンバイ・データベースが関与するロールの推移では、次の
点を考慮してください。
■
■
ロジカル・スタンバイ・データベースがプライマリ・データベースに存在するデータの
サブセットのみメンテナンス対象にする構成の場合は、データが消失する可能性があり
ます。
既存のフィジカル・スタンバイ・データベースは、ロールの推移後も Data Guard 構成
に継続して含まれるように、新しいプライマリ・データベースのコピーから再作成する
必要があります。
最適なフィジカルまたはロジカル・スタンバイ・データベースを選択する方法については、
10-14 ページの「ロールの推移に最適なスタンバイ・データベースの選択」を参照してくだ
さい。
実行するロールの推移のタイプを決定した後、次のいずれかの項に進んでください。
■
スイッチオーバーについては、
「スイッチオーバー」を参照してください。
■
フェイルオーバーについては、
「フェイルオーバー」を参照してください。
7-4　Oracle Data Guard 概要および管理
ロールの推移の概要
スイッチオーバー
スイッチオーバーは、通常、オペレーティング・システムやハードウェアのアップグレー
ド、または Oracle データベース・ソフトウェアとパッチ・セットのローリング・アップグ
レードなど、計画的な停止によるプライマリ・データベースの停止時間を短縮するために使
用します（9-19 ページの「Oracle Database ソフトウェア・バージョンのアップグレード」
を参照）
。
スイッチオーバーは、2 つのフェーズで実行されます。最初のフェーズで、既存のプライマ
リ・データベースがスタンバイ・ロールに推移します。2 番目のフェーズで、スタンバイ・
データベースがプライマリ・ロールに推移します。
図 7-2 は、データベースのロールを切り替える前の 2 つのサイトにある Data Guard 構成を
示します。この構成では、プライマリ・データベースはサンフランシスコにあり、スタンバ
イ・データベースはボストンにあります。
図 7-2 スイッチオーバー前の Data Guard 構成
図 7-3 に、元のプライマリ・データベースがスタンバイ・データベースにスイッチオーバー
された後、元のスタンバイ・データベースがまだ新しいプライマリ・データベースになって
いない Data Guard 環境を示します。このとき、Data Guard 構成には一時的に 2 つのスタン
バイ・データベースが存在することになります。
ロール管理
7-5
ロールの推移の概要
図 7-3 新しいプライマリ・データベースへのスイッチオーバー前のスタンバイ・データベース
図 7-4 は、スイッチオーバー実行後の Data Guard 環境を示します。元のスタンバイ・デー
タベースは新しいプライマリ・データベースになります。現在、プライマリ・データベース
はボストンにあり、スタンバイ・データベースはサンフランシスコにあります。
図 7-4 スイッチオーバー後の Data Guard 環境
7-6　Oracle Data Guard 概要および管理
ロールの推移の概要
スイッチオーバーの準備
スイッチオーバーは、Data Guard 構成内のプライマリ・データベースとロジカルまたは
フィジカル・スタンバイ・データベースとの間で実行できますが、「使用するロールの推移
の選択」で説明したように、フィジカル・スタンバイ・データベースとの間で実行すること
をお薦めします。停止時間を最短にするために、各スイッチオーバーを慎重に計画して、ス
イッチオーバーに関与するプライマリおよびスタンバイ・データベースのトランザクション
上の遅延が最小限になるようにします。また、Data Guard Broker を使用してスイッチオー
バー手順を 1 つの簡単な手順に自動化および単純化することも考慮してください。詳細は、
『Oracle Data Guard Broker』を参照してください。
スイッチオーバーを開始する前に、次の作業を行ってください。
■
各データベースの初期化パラメータが正しく構成されていることを確認してください。
ロールの推移後に Data Guard 構成が正しく動作するように、プライマリおよびスタン
バイ・データベースで初期化パラメータを構成する方法については、第 3 章および第 4
章を参照してください。
注意 : Data Guard Broker を使用しない場合は、すべてのスタンバイ・サ
イトで LOG_ARCHIVE_DEST_n および LOG_ARCHIVE_DEST_STATE_n パ
ラメータを定義する必要があります。これによって、スイッチオーバーま
たはフェイルオーバーが発生したとき、すべてのスタンバイ・サイトで新
しいプライマリ・データベースからの REDO データの受信を継続できま
す。LOG_ARCHIVE_DEST_n VALID_FOR 属性を使用して、将来のロール
の推移に備えてロールベースの宛先を定義する方法については、5-23 ペー
ジの「VALID_FOR 属性を使用したロール・ベースの宛先の指定」および
第 12 章を参照してください。
Data Guard Broker（コマンドライン・インタフェースまたは GUI）で設
定した構成では、LOG_ARCHIVE_DEST_n パラメータと LOG_ARCHIVE_
DEST_STATE_n パラメータが自動的に定義されます。これには、プライ
マリ・データベースおよび他のすべてのスタンバイ・データベースを指し
示すための LOG_ARCHIVE_DEST_n パラメータの定義も含まれます。
■
プライマリ・データベースとスタンバイ・データベースの間にネットワーク接続がある
ことを確認します。
Data Guard 構成内の各位置で、Oracle Net を介してプライマリ・データベースおよび
関連する他のすべてのスタンバイ・データベースに接続できる必要があります。
■
■
新たにプライマリ・データベースになるスタンバイ・データベースが ARCHIVELOG
モードで動作していることを確認します。
スタンバイ・データベースに存在する一時ファイルが、プライマリ・データベースの一
時ファイルと一致することを確認します。スタンバイ・データベースで一時ファイルを
作成する方法については、3-15 ページの「フィジカル・スタンバイ・データベースの起
動」
（フィジカル・スタンバイ・データベース）および 4-15 ページの「ロジカル・スタ
ロール管理
7-7
ロールの推移の概要
ンバイ・データベースの起動」
（ロジカル・スタンバイ・データベース）を参照してく
ださい。
■
■
■
新たにプライマリ・データベースになるスタンバイ・データベースで現在有効になって
いる REDO データの適用遅延を解除します。
データベースに接続しているアクティブなユーザーがいないことを確認します。
Real Application Clusters 構成の場合は、1 つのプライマリ・インスタンスと 1 つのスタ
ンバイ・インスタンスを除いて、構成内のすべてのインスタンスが停止していることを
確認します。
Real Application Clusters データベースの場合は、1 つのプライマリ・インスタンスと 1
つのスタンバイ・インスタンスのみをスイッチオーバー時にオンラインにできます。
フェイルオーバーを開始する前に、他のすべてのインスタンスを停止しておいてくださ
い。スイッチオーバーの完了後、これらのインスタンスをオンラインに戻します。
注意 : スイッチオーバー中にオープンしているスタンバイ・インスタン
スが 1 つしかない場合も、すべてのスタンバイ・データベース・インスタ
ンスが自動的に新しいロールに正しく推移します。
■
フィジカル・スタンバイ・データベースが関与するスイッチオーバーの場合は、プライ
マリ・データベース・インスタンスがオープンし、スタンバイ・データベース・インス
タンスがマウントされていることを確認します。
スイッチオーバーの開始前に、プライマリ・ロールに推移するスタンバイ・データベー
スをマウントする必要があります。また、データベースのロールが切り替えられたとき、
フィジカル・スタンバイ・データベースがアーカイブ REDO ログ・ファイルをリカバ
リするのが理想的です。フィジカル・スタンバイ・データベースが読取り専用アクセス
のためにオープンされている場合、スイッチオーバーは実行されますが時間がかかりま
す。REDO Apply の詳細は、6-7 ページの「REDO データのフィジカル・スタンバイ・
データベースへの適用」を参照してください。
■
ロジカル・スタンバイ・データベースが関与するスイッチオーバーの場合は、プライマ
リおよびスタンバイ・データベース・インスタンスの両方がオープンし、SQL Apply が
アクティブであることを確認します。SQL Apply の詳細は、6-12 ページの「REDO デー
タのロジカル・スタンバイ・データベースへの適用」を参照してください。
フィジカル・スタンバイ・データベースが関与するスイッチオーバーについては、「フィジ
カル・スタンバイ・データベースが関与するスイッチオーバー」を参照してください。ロジ
カル・スタンバイ・データベースが関与するスイッチオーバーについては、「ロジカル・ス
タンバイ・データベースが関与するスイッチオーバー」を参照してください。Oracle Data
Guard Broker の分散管理フレームワークを使用して環境を構成している場合、Switchover
Wizard を使用してスイッチオーバー・プロセスを自動化する方法については、
『Oracle Data
Guard Broker』を参照してください。
7-8　Oracle Data Guard 概要および管理
ロールの推移の概要
フェイルオーバー
通常、フェイルオーバーは、プライマリ・データベースが使用不可能になり、適正な時間内
にプライマリ・データベースをリストアしてサービスを再開できない場合にのみ使用しま
す。フェイルオーバー時に実行するアクションは、フェイルオーバーに関与するスタンバ
イ・データベースがロジカルかフィジカルか、フェイルオーバー時の Data Guard 構成の状
態、およびフェイルオーバーを開始するために使用する特定の SQL 文によって異なります。
図 7-5 に、サンフランシスコにあるプライマリ・データベースからボストンにあるフィジカ
ル・スタンバイ・データベースへのフェイルオーバーの結果を示します。
図 7-5 スタンバイ・データベースへのフェイルオーバー
フェイルオーバーの準備
可能な場合は、フェイルオーバーを実行する前に、この項で説明する手順に従って、使用可
能な未適用のプライマリ・データベース REDO データを可能なかぎりスタンバイ・データ
ベースに転送する必要があります。Data Guard Broker を使用してフェイルオーバー手順を 1
つの簡単な手順に自動化および単純化することも考慮してください。詳細は、
『Oracle Data
Guard Broker』を参照してください。
フェイルオーバーを開始する前に、次の手順を実行します。
■
Data Guard 構成内の既存のデータベースの初期化パラメータが正しく構成されている
ことを確認してください。ロールの推移後に Data Guard 構成が正しく動作するように、
プライマリおよびフィジカル・スタンバイ・データベースで初期化パラメータを構成す
る方法については、第 3 章を参照してください。
ロール管理
7-9
ロールの推移の概要
注意 : Data Guard Broker を使用しない場合は、すべてのスタンバイ・サ
イトで LOG_ARCHIVE_DEST_n および LOG_ARCHIVE_DEST_STATE_n パ
ラメータを定義する必要があります。これによって、スイッチオーバーま
たはフェイルオーバーが発生したとき、すべてのスタンバイ・サイトで新
しいプライマリ・データベースからの REDO データの受信を継続できま
す。LOG_ARCHIVE_DEST_n VALID_FOR 属性を使用して、将来のロール
の推移に備えてロールベースの宛先を定義する方法については、5-23 ペー
ジの「VALID_FOR 属性を使用したロール・ベースの宛先の指定」および
第 12 章を参照してください。
Data Guard Broker（コマンドライン・インタフェースまたは GUI）で設
定した構成では、LOG_ARCHIVE_DEST_n パラメータと LOG_ARCHIVE_
DEST_STATE_n パラメータが自動的に定義されます。これには、プライ
マリ・データベースおよび他のすべてのスタンバイ・データベースを指し
示すための LOG_ARCHIVE_DEST_n パラメータの定義も含まれます。
■
■
■
■
■
Data Guard 構成内の残りの各位置で、Oracle Net を介して新たにプライマリ・データ
ベースになるデータベースおよび関連する他のすべてのスタンバイ・データベースに接
続できることを確認します。
新たにプライマリ・データベースになるスタンバイ・データベースが ARCHIVELOG
モードで動作していることを確認します。
スタンバイ・データベースに存在する一時ファイルが、プライマリ・データベースの一
時ファイルと一致することを確認します。スタンバイ・データベースで一時ファイルを
作成する方法については、3-15 ページの「フィジカル・スタンバイ・データベースの起
動」
（フィジカル・スタンバイ・データベース）および 4-15 ページの「ロジカル・スタ
ンバイ・データベースの起動」
（ロジカル・スタンバイ・データベース）を参照してく
ださい。
新たにプライマリ・データベースになるスタンバイ・データベースで現在有効になって
いる REDO データの適用遅延を解除します。
新たにプライマリ・データベースになるスタンバイ・データベースが Real Application
Clusters データベースの場合は、フェイルオーバーを開始する前に、1 つのスタンバ
イ・インスタンスを除いて、すべてのインスタンスを停止します。フェイルオーバーの
完了後、他のインスタンスをオンラインに戻します。Real Application Clusters データ
ベースの場合、フェイルオーバー中は 1 つのスタンバイ・インスタンスのみアクティブ
にできます。
7-10　Oracle Data Guard 概要および管理
ロールの推移の概要
■
最大保護モードで実行中のスタンバイ・データベースがフェイルオーバーに関与する場
合は、スタンバイ・データベースで次の文を発行して、データベースを最大パフォーマ
ンス・モードにします。
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
適切なスタンバイ・データベースが使用できる場合は、フェイルオーバーが完了した後
に、新しいプライマリ・データベースで希望の保護モードをリセットできます。
最大保護モードに設定されているスタンバイ・データベースはフェイルオーバーできな
いため、この作業が必要になります。さらに、最大保護モードのプライマリ・データ
ベースがスタンバイ・データベースと通信中の場合は、スタンバイ・データベースを最
大保護モードから最大パフォーマンス・モードに変更するために ALTER DATABASE 文
を発行しても失敗します。フェイルオーバーを実行すると、元のプライマリ・データ
ベースは Data Guard 構成から削除されて元に戻せないため、この機能によって、最大
保護モードで実行されているプライマリ・データベースを計画外のフェイルオーバーの
影響から保護します。
注意 : スタンバイ・データベースが正しく更新されているかどうかをテ
ストするために、スタンバイ・データベースにフェイルオーバーしないで
ください。かわりに、次のようにします。
■
■
フィジカル・スタンバイ・データベースが正しく動作していることを
確認する方法については、3-17 ページの「フィジカル・スタンバイ・
データベースが正しく実行されているかどうかの確認」を参照してく
ださい。
ロジカル・スタンバイ・データベースが正しく動作していることを確
認する方法については、4-19 ページの「ロジカル・スタンバイ・デー
タベースが正しく実行されているかどうかの確認」を参照してくださ
い。
フィジカル・スタンバイ・データベースが関与するフェイルオーバーを実行するには、
「フィジカル・スタンバイ・データベースが関与するフェイルオーバー」を参照してくださ
い。ロジカル・スタンバイ・データベースが関与するフェイルオーバーを実行するには、「ロ
ジカル・スタンバイ・データベースが関与するフェイルオーバー」を参照してください。
ロール管理
7-11
フィジカル・スタンバイ・データベースが関与するロールの推移
フィジカル・スタンバイ・データベースが関与するロールの推移
この項では、フィジカル・スタンバイ・データベースが関与するスイッチオーバーおよび
フェイルオーバーの実行方法を説明します。
フィジカル・スタンバイ・データベースが関与するスイッチオーバー
この項では、プライマリ・データベースとフィジカル・スタンバイ・データベースの間で
ロールを変更するスイッチオーバーの実行方法を説明します。スイッチオーバーは、現行の
プライマリ・データベースで開始し、ターゲット・スタンバイ・データベースで完了する必
要があります。次に、スイッチオーバーを実行する手順を説明します。
現行のプライマリ・データベースでの手順
手順 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 ページの「スタンバ
イ・データベースへのスイッチオーバーの問題」で説明する手順を実行して、スイッチオー
バーの処理を妨げている可能性のあるアクティブなユーザーまたは SQL セッションを識別
して終了します。これらの手順を実行した後も SWITCHOVER_STATUS 列に SESSIONS
ACTIVE と表示される場合は、手順 2 で説明した ALTER DATABASE COMMIT TO
SWITCHOVER TO PHYSICAL STANDBY 文に WITH SESSION SHUTDOWN 句を追加すること
でスイッチオーバーを正常に実行できます。
V$DATABASE ビューの SWITCHOVER_STATUS 列に対するその他の有効な値については、
『Oracle Database リファレンス』を参照してください。
7-12　Oracle Data Guard 概要および管理
フィジカル・スタンバイ・データベースが関与するロールの推移
手順 2 プライマリ・データベースでスイッチオーバーを開始する
現行のプライマリ・データベースをフィジカル・スタンバイ・データベース・ロールに推移
するには、プライマリ・データベースで次の SQL 文を使用します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
この文が完了すると、プライマリ・データベース・ロールはスタンバイ・データベースに変
換されます。現行の制御ファイルは、スイッチオーバーの前にカレント SQL セッション・
トレース・ファイルにバックアップされます。これによって、必要に応じて現行の制御ファ
イルを再作成できるようになります。
手順 3 元のプライマリ・インスタンスを停止して再起動する
元のプライマリ・インスタンスを停止し、データベースを再起動およびマウントします。
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
スイッチオーバー・プロセスのこの時点では、両方のデータベースがスタンバイ・データ
ベースとして構成されています（図 7-3 を参照）。
ターゲット・フィジカル・スタンバイ・データベースでの手順
手順 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 ページの「スタンバ
イ・データベースへのスイッチオーバーの問題」で説明する手順を実行して、スイッチオー
バーの処理を妨げている可能性のあるアクティブなユーザーまたは SQL セッションを識別
して終了します。これらの手順を実行した後も SWITCHOVER_STATUS 列に SESSIONS
ACTIVE と表示される場合は、手順 5 に進んでスイッチオーバー文に WITH SESSION
SHUTDOWN 句を追加できます。V$DATABASE ビューの SWITCHOVER_STATUS 列に対するそ
の他の有効な値については、
『Oracle Database リファレンス』を参照してください。
ロール管理
7-13
フィジカル・スタンバイ・データベースが関与するロールの推移
手順 5 ターゲット・フィジカル・スタンバイ・データベース・ロールからプライマリ・
ロールに切り替える
フィジカル・スタンバイ・データベースをスタンバイ・ロールからプライマリ・ロールに切
り替えることができるのは、そのスタンバイ・データベースのインスタンスが REDO Apply
モードでマウントされているか、あるいは読取り専用アクセスのためにオープンされている
ときです。フィジカル・スタンバイ・データベースは、いずれかのモードでマウントする必
要があります。これによって、プライマリ・データベースのスイッチオーバー要求を調整で
きます。適切なモードでスタンバイ・データベースをマウントした後、プライマリ・ロール
に推移するフィジカル・スタンバイ・データベースで次の SQL 文を発行します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
フィジカル・スタンバイ・データベースを作成するときに手動で REDO ログ・ファイルを
追加する方法については、第 3 章を参照してください。
手順 6 ターゲット・スタンバイ・データベースを停止して再起動する
ターゲット・スタンバイ・データベースを停止し、プライマリ・ロールの適切な初期化パラ
メータを使用して再起動します。
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
ターゲット・フィジカル・スタンバイ・データベースがプライマリ・データベース・ロール
に推移します。
注意 : スイッチオーバー時にオンラインでもスイッチオーバーに関与し
ない他のスタンバイ・データベースは、停止して再起動する必要はありま
せん。これらのスタンバイ・データベースは、スイッチオーバーの完了後
も正常に機能し続けます。
新しいフィジカル・スタンバイ・データベースおよび他のすべてのスタンバイ・データベー
スでの手順
手順 7 必要に応じてスタンバイ・データベースでログ適用サービスを再開する
新しいフィジカル・スタンバイ・データベース、および Data Guard 構成内の他のフィジカ
ルまたはロジカル・スタンバイ・データベースの場合、スイッチオーバー後も動作を継続す
るようにログ適用サービスが構成されていないときは、適切なコマンドを使用して、ログ適
用サービスを再開します。ログ適用サービスを構成および開始する方法については、第 6 章
を参照してください。
7-14　Oracle Data Guard 概要および管理
フィジカル・スタンバイ・データベースが関与するロールの推移
新しいプライマリ・データベースでの手順
手順 8 スタンバイ・データベースへの REDO データの送信を開始する
新しいプライマリ・データベースで次の文を発行します。
SQL> ALTER SYSTEM SWITCH LOGFILE;
フィジカル・スタンバイ・データベースが関与するフェイルオーバー
この項では、フィジカル・スタンバイ・データベースが関与するフェイルオーバーの実行方
法を説明します。
フィジカル・スタンバイ・データベースが関与するフェイルオーバー時に、次の処理が実行
されます。
■
■
■
すべての場合、フェイルオーバーの完了後、元のプライマリ・データベースは Data
Guard 構成に含まれなくなります。
ほとんどの場合、フェイルオーバーに直接関与しない他のロジカルまたはフィジカル・
スタンバイ・データベースは構成内に残り、停止して再起動する必要はありません。
新しいプライマリ・データベースを構成した後、すべてのスタンバイ・データベースの
再作成が必要な場合があります。
フェイルオーバーを開始する前に、
「フェイルオーバーの準備」で説明した手順を可能なか
ぎり実行し、選択したスタンバイ・データベースのフェイルオーバー操作の準備をしてか
ら、
「フェイルオーバーの手順」に進んでください。
注意 : フェイルオーバーを実行するには、次の項で説明するフェイル
オーバーの手順およびコマンドのみを使用することをお薦めします。
ALTER DATABASE ACTIVATE STANDBY DATABASE 文によりデータ消失
が発生するため、フェイルオーバーの実行にこの文を使用しないでくださ
い。
ロール管理
7-15
フィジカル・スタンバイ・データベースが関与するロールの推移
フェイルオーバーの手順
この項では、選択したフィジカル・スタンバイ・データベースをプライマリ・ロールに推移
するために必要な手順について説明します。構成の一部でもある他のフィジカルまたはロジ
カル・スタンバイ・データベースは構成内に残り、停止して再起動する必要はありません。
ターゲット・スタンバイ・データベースが最大保護モードで動作していた場合、アーカイブ
REDO ログ・ファイル内にギャップが存在しないため、手順 4 に直接進むことができます。
それ以外の場合は、ギャップ解決の手順を手動で実行する必要があるかどうかを判断するた
めに、手順 1 から始めます。
手順 1 アーカイブ REDO ログ・ファイルのギャップを識別して解決する
ターゲット・スタンバイ・データベースでアーカイブ REDO ログ・ファイルにギャップが
存在するかどうかを判断するには、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';
手順 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;
7-16　Oracle Data Guard 概要および管理
フィジカル・スタンバイ・データベースが関与するロールの推移
THREAD
LAST
---------- ---------1
100
ターゲット・スタンバイ・データベースで最も大きい順序番号より大きい順序番号を含むプ
ライマリ・データベースから、使用可能なアーカイブ REDO ログ・ファイルをターゲット・
スタンバイ・データベースにコピーして登録します。この処理は、スレッドごとに実行する
必要があります。
次に例を示します。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
使用可能なアーカイブ REDO ログ・ファイルをすべて登録した後に、手順 1 で説明したよ
うに、V$ARCHIVE_GAP ビューを問い合せて、手順 3 に他のギャップが追加されていないこ
とを確認します。
注意 : 手順 1 から 3 を実行しているときに、アーカイブ REDO ログ・
ファイル内のギャップを解決できない場合（障害の発生したプライマリ・
データベースが置かれているシステムへのアクセス権がない場合など）
、
フェイルオーバー時にデータが消失する可能性があります。
手順 4 ターゲット・フィジカル・スタンバイ・データベースでフェイルオーバー操作を開
始する
ターゲット・フィジカル・スタンバイ・データベースでスタンバイ REDO ログ・ファイル
が構成されている場合は、次の文を発行してフェイルオーバーを開始します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
ターゲット・フィジカル・スタンバイ・データベースでスタンバイ REDO ログ・ファイル
が構成されていない場合は、次のように FINISH SKIP STANDBY LOGFILE 句を含めます。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> FINISH SKIP STANDBY LOGFILE;
注意 : フェイルオーバー操作により、アーカイブされる最後のログ・
ファイルのヘッダーに end-of-redo マーカーが追加され、この REDO はプ
ライマリ・ロール（VALID_FOR=(PRIMARY_ROLE, *_LOGFILES) または
VALID_FOR=(ALL_ROLES, *_LOGFILES) 属性で指定）として妥当なすべ
ての使用可能な宛先に送信されます。
ロール管理
7-17
フィジカル・スタンバイ・データベースが関与するロールの推移
手順 5 フィジカル・スタンバイ・データベース・ロールからプライマリ・ロールに変換する
SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE...FINISH 文が正常に
完了した後、次の SQL 文を発行して、フィジカル・スタンバイ・データベースをプライマ
リ・データベース・ロールに推移させます。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
この SQL 文を発行した後、ターゲット・スタンバイ・データベースがプライマリ・ロール
に推移します。その結果、このデータベースはスタンバイ・データベースとして使用できな
くなり、元のプライマリ・データベースから受信した後続の REDO は適用できません。
フェイルオーバー・プロセスでは、スタンバイ REDO ログ・ファイルが自動的にアーカイ
ブされ、元のプライマリ・データベースから作成した他のすべてのスタンバイ・データベー
スでリカバリされます。この処理は、新しいプライマリ・データベースでスタンバイ宛先を
適切に定義した場合のみ実行されます。
フェイルオーバーに関与しない構成内の他のスタンバイ・データベースは、停止して再起動
する必要はありません。
新しいプライマリ・データベースでの手順
手順 6 新しいプライマリ・データベースを停止して再起動する
フェイルオーバーを完了するには、プライマリ・ロールに対して適切な従来の初期化パラ
メータ・ファイル（またはサーバー・パラメータ・ファイル）を使用して、新しいプライマ
リ・データベースを停止して読取り / 書込みモードで再起動する必要があります。
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
ロールの推移後に Data Guard 構成が正しく動作するように、プライマリおよびスタンバ
イ・データベースの両方で初期化パラメータを構成する方法については、第 3 章および第 4
章を参照してください。
手順 7 新しいプライマリ・データベースをバックアップする（オプション）
STARTUP 文を発行する前に、必要に応じて新しいプライマリ・データベースのクローズ状
態のバックアップを実行できます。クローズ状態のバックアップのかわりに、STARTUP 文を
発行した後に、データベースのオープン状態のバックアップを実行することもできます。
バックアップを即時に実行することは、必要がない場合にも推奨される安全な手段です。こ
れは、データベースの完全なバックアップ・コピーを作成せずにフェイルオーバーを行う
と、変更をリカバリできないためです。
フェイルオーバーの結果、元のプライマリ・データベースは Data Guard 構成に含まれなく
なり、他のすべてのスタンバイ・データベースは新しいプライマリ・データベースから
REDO データを受信して適用します。
7-18　Oracle Data Guard 概要および管理
フィジカル・スタンバイ・データベースが関与するロールの推移
手順 8 障害の発生したプライマリ・データベースをリストアする（オプション）
フェイルオーバーの完了後、元のプライマリ・データベースは構成に含まれなくなります。
フェイルオーバーの実行後、必要に応じて次のどちらかの方法を使用して、障害の発生した
プライマリ・データベースを新規スタンバイ・データベースとしてリストアすることもでき
ます。
■
フラッシュバック・データベースを使用して、障害の発生したプライマリ・データベー
スをフェイルオーバー発生前の時点までリストアしてから、10-28 ページの「フェイル
オーバー後のフラッシュバック・データベースの使用」の手順に従ってスタンバイ・
データベースに変換します。
注意 : フェイルオーバーの前に、旧プライマリ・データベースでフラッ
シュバック・データベースを使用可能にしておく必要があります。詳細
は、
『Oracle Database バックアップおよびリカバリ・アドバンスト・ユー
ザーズ・ガイド』を参照してください。
■
障害の発生したデータベースを再作成し、新規スタンバイ・データベースとして構成に
追加します。古いプライマリ・データベースを新しい構成内で再利用するには、新しい
プライマリ・データベースのバックアップ・コピーを使用し、スタンバイ・データベー
スとして再作成する必要があります。この手順については、3-8 ページのフィジカル・ス
タンバイ・データベースの作成または 4-8 ページの「ロジカル・スタンバイ・データ
ベースの作成」を参照してください。
障害の発生したプライマリ・データベースがリストアされ、スタンバイ・ロールで稼働して
いる場合は、オプションでスイッチオーバーを実行し、データベースを元（障害前）のロー
ルに推移できます。詳細は、7-12 ページの「フィジカル・スタンバイ・データベースが関与
するスイッチオーバー」を参照してください。
ロール管理
7-19
ロジカル・スタンバイ・データベースが関与するロールの推移
ロジカル・スタンバイ・データベースが関与するロールの推移
この項では、ロジカル・スタンバイ・データベースが関与するスイッチオーバーおよびフェ
イルオーバーの実行方法を説明します。
ロジカル・スタンバイ・データベースが関与するスイッチオーバー
プライマリ・データベースとロジカル・スタンバイ・データベースとの間でスイッチオー
バーを実行する場合、スイッチオーバーは、常にプライマリ・データベースで開始し、ロジ
カル・スタンバイ・データベースで完了してください。次に、スイッチオーバーを実行する
手順を説明します。
プライマリ・データベースの場合
手順 1 スイッチオーバーを実行できるかどうかを確認する
スイッチオーバーを実行できるかどうかを確認するには、現行のプライマリ・データベース
で V$DATABASE 固定ビューの SWITCHOVER_STATUS 列を問い合せます。次に例を示しま
す。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
----------------TO STANDBY
1 row selected
SWITCHOVER_STATUS 列の値 TO STANDBY、TO LOGICAL 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 データの受信を開始することを、現行の
プライマリ・データベースに通知します。
7-20　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースが関与するロールの推移
ターゲット・ロジカル・スタンバイ・データベースでの手順
手順 3 ターゲット・ロジカル・スタンバイ・データベースのスイッチオーバーを準備する
スイッチオーバーのターゲットであるロジカル・スタンバイ・データベースで LogMiner
ディクショナリを作成するには、次の文を使用します。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
また、この文は、現行のプライマリ・データベース、および Data Guard 構成内の他のスタ
ンバイ・データベースに REDO データの転送を開始するロジカル・スタンバイ・データ
ベースで、ログ転送サービスを開始します。このロジカル・スタンバイ・データベースから
REDO データを受信するサイトは、REDO データを受け入れますが、適用はしません。
この操作は、処理量とデータベースのサイズによって完了までに時間がかかる場合がありま
す。
現行のプライマリ・データベースでの手順
手順 4 スイッチオーバーの状態を V$DATABASE ビューで確認する
プライマリ・データベースをロジカル・スタンバイ・ロールに推移する前に、プライマリ・
データベースで V$DATABASE 固定ビューの SWITCHOVER_STATUS 列を問い合せて、プライ
マリ・データベースで LogMiner ディクショナリが受信されていることを確認します。
SWITCHOVER_STATUS 列は、スイッチオーバーの進捗を示します。
問合せが TO LOGICAL STANDBY 値を戻した場合は、手順 5 に進むことができます。次に例
を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
----------------TO LOGICAL STANDBY
1 row selected
手順 5 プライマリ・データベースをロジカル・スタンバイ・データベース・ロールに切り
替える
プライマリ・データベースをロジカル・スタンバイ・データベース・ロールに推移するに
は、次の SQL 文を発行します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
この文によって、プライマリ・データベースでの現在のトランザクションがすべて終了する
まで待機し、新規ユーザーによる新規トランザクションの開始を防止します。また、ロジカ
ル・スタンバイ・データベース処理の同期点を示すために、REDO データにマーカーを付け
ます。この文を実行すると、ユーザーはロジカル・スタンバイ・データベースでメンテナン
スされているデータの変更もできなくなります。スイッチオーバーを迅速に実行するには、
スイッチオーバー文を発行する前に、プライマリ・データベースが静止状態で更新アクティ
ロール管理
7-21
ロジカル・スタンバイ・データベースが関与するロールの推移
ビティが実行されていないことを確認してください（たとえば、すべてのユーザーをプライ
マリ・データベースから一時的にログオフします）
。V$TRANSACTIONS ビューを問い合せる
と、この文の実行を遅延させる可能性のある現在進行中のトランザクションのステータス情
報を取得できます。
この時点でプライマリ・データベースが推移して、スタンバイ・データベース・ロールが実
行されます。
プライマリ・データベースをロジカル・スタンバイ・データベース・ロールに推移した場合
は、データベースを停止して再起動する必要はありません。
ターゲット・ロジカル・スタンバイ・データベース（新しいプライマリ・データベース）で
の手順
手順 6 スイッチオーバーの状態を V$DATABASE ビューで確認する
プライマリ・データベースをロジカル・スタンバイ・ロールに推移させ、構成内のスタンバ
イ・データベースがスイッチオーバー通知を受け取った後、ターゲット・スタンバイ・デー
タベースで V$DATABASE 固定ビューの SWITCHOVER_STATUS 列を問い合せて、ターゲッ
ト・スタンバイ・データベースがスイッチオーバー通知を処理したかどうかを確認する必要
があります。スイッチオーバー中に SWITCHOVER_STATUS 値が更新され、進捗を示します。
TO PRIMARY 状態の場合は、手順 7 に進むことができます。
次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
----------------TO PRIMARY
1 row selected
V$DATABASE ビューの SWITCHOVER_STATUS 列に対するその他の有効な値については、
『Oracle Database リファレンス』を参照してください。
手順 7 ターゲット・ロジカル・スタンバイ・データベースをプライマリ・データベース・
ロールに切り替える
プライマリ・ロールに切り替えるロジカル・スタンバイ・データベースで、次の SQL 文を
使用し、ロジカル・スタンバイ・データベースをプライマリ・ロールに切り替えます。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Data Guard 構成内のロジカル・スタンバイ・データベースは、停止して再起動する必要は
ありません。他の既存のロジカル・スタンバイ・データベースは、スイッチオーバーの完了
後も正常に機能し続けます。ただし、既存のすべてのフィジカル・スタンバイ・データベー
スは、スイッチオーバー後は Data Guard 構成に含まれなくなります。
7-22　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースが関与するロールの推移
手順 8 すべてのスタンバイ・データベースで REDO データの受信を開始する
すべてのロジカル・スタンバイ・データベースで新しいプライマリ・データベースから
REDO データの受信を開始できるように、新しいプライマリ・データベースでログ・スイッ
チを実行します。
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
新しいロジカル・スタンバイ・データベースで SQL Apply を開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
ロジカル・スタンバイ・データベースが関与するフェイルオーバー
この項では、ロジカル・スタンバイ・データベースが関与するフェイルオーバーの実行方法
を説明します。
ロジカル・スタンバイ・データベースが関与するフェイルオーバー時に、次の処理が実行さ
れます。
■
■
■
すべての場合、元のプライマリ・データベースおよびすべてのフィジカル・スタンバ
イ・データベースは非互換となり、Data Guard 構成に残れなくなります。
ほとんどの場合、フェイルオーバーに直接関与しない他のロジカル・スタンバイ・デー
タベースは構成内に残り、停止して再起動する必要はありません。
新しいプライマリ・データベースを構成した後、すべてのスタンバイ・データベースの
再作成が必要な場合があります。
フェイルオーバーを開始する前に、
「フェイルオーバーの準備」で説明した手順を可能なか
ぎり実行し、選択したスタンバイ・データベースのフェイルオーバーの準備をしてくださ
い。構成に対する保護モードおよびログ転送サービスに対して選択した属性に従って、プラ
イマリ・データベースの修正の一部またはすべてを自動的にリカバリすることも可能です。
ターゲット・スタンバイ・データベースが非データ消失モードで動作していた場合、アーカ
イブ REDO ログ・ファイル内にギャップが存在しないため、手順 3 に直接進むことができ
ます。それ以外の場合は、ギャップ解決の手順を手動で実行する必要があるかどうかを判断
するために、手順 1 から始めます。
ロール管理
7-23
ロジカル・スタンバイ・データベースが関与するロールの推移
プライマリ・ロールに推移するロジカル・スタンバイ・データベースでの手順
手順 1 欠落したアーカイブ REDO ログ・ファイルをコピーして登録する
構成に含まれるコンポーネントの状態によっては、プライマリ・データベースのアーカイブ
REDO ログ・ファイルにアクセスできる場合があります。アクセスする場合の手順は、次の
とおりです。
1.
ロジカル・スタンバイ・データベースでアーカイブ REDO ログ・ファイルが欠落してい
るかどうかを判断します。
2.
欠落しているログ・ファイルを、プライマリ・データベースからロジカル・スタンバ
イ・データベースにコピーします。
3.
コピーしたログ・ファイルを登録します。
ロジカル・スタンバイ・データベースで DBA_LOGSTDBY_LOG ビューを問い合せて、欠落し
ているログ・ファイルを判断して登録します。たとえば、次の問合せでは、ロジカル・スタ
ンバイ・データベースの THREAD 1 に、2 つのファイルが表示されているため、アーカイブ
REDO ログ・ファイルの順序番号にギャップがあることを示しています（ギャップがない場
合、問合せで表示されるのは、スレッドごとに 1 つのファイルのみです）
。この出力は、登録
されたファイルの最大の順序番号は 10 ですが、順序番号 6 で示されるファイルにギャップ
があることを示しています。
SQL>
SQL>
2>
3>
4>
COLUMN FILE_NAME FORMAT a55;
SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L
WHERE NEXT_CHANGE# NOT IN
(SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#)
ORDER BY THREAD#,SEQUENCE#;
THREAD# SEQUENCE# FILE_NAME
---------- ---------- ----------------------------------------------1
6 /disk1/oracle/dbs/log-1292880008_6_1.arc
1
10 /disk1/oracle/dbs/log-1292880008_10_1.arc
ギャップを解決するには、THREAD 1 の欠落しているアーカイブ REDO ログ・ファイル
（順序番号 7、8 および 9）をコピーします。次に、それらのアーカイブ REDO ログ・ファイ
ルをロジカル・スタンバイ・データベースに登録します。次に例を示します。
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE
2> '/disk1/oracle/dbs/log-%r_%s_%t.arc';
Database altered.
欠落したアーカイブ REDO ログ・ファイルをコピーしてロジカル・スタンバイ・システム
に登録した後、DBA_LOGSTDBY_LOG ビューを再度問い合せて、ギャップがないこと、およ
びターゲット・ロジカル・スタンバイ・データベースで必要な次のスレッドと順序番号が存
在しないことを確認します。
7-24　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースが関与するロールの推移
手順 2 使用可能なすべてのアーカイブ REDO ログ・ファイルが適用されたことを確認する
プライマリ・ロールに推移させるロジカル・スタンバイ・データベースで DBA_LOGSTDBY_
PROGRESS ビューを問い合せて、使用可能なすべてのアーカイブ REDO ログ・ファイルが
適用されたことを確認します。次に例を示します。
SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN NEWEST_SCN
----------- ---------190725
190725
APPLIED_SCN と NEWEST_SCN の値が等しい場合は、取得可能なすべてのデータが適用さ
れ、ロジカル・スタンバイ・データベースにはプライマリ・データベースからのデータが可
能なかぎり含まれています。
注意 : ターゲット・ロジカル・スタンバイ・データベースで SQL Apply
がアクティブになっていない場合は、ターゲット・スタンバイ・データ
ベースで次の文を発行して、SQL Apply を開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY FINISH;
Database altered.
DBA_LOGSTDBY_PROGRESS ビューについては、第 9 章および第 10 章を参照してください。
手順 3 リモート宛先を使用可能にする
「フェイルオーバーの準備」で説明したように、ロールベースの宛先を以前に構成していな
い場合は、新しいプライマリ・データベースのリモート・ロジカル・スタンバイ宛先に対応
する初期化パラメータを識別して、これらの宛先ごとに REDO データのアーカイブを手動
で使用可能にします。
たとえば、LOG_ARCHIVE_DEST_2 パラメータで定義したリモート宛先のアーカイブを可能
にするには、次の文を発行します。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;
後で新しいプライマリ・データベースを再起動した場合にもこの変更を保持するには、適切
なテキスト初期化パラメータ・ファイルまたはサーバー・パラメータ・ファイルを更新しま
す。通常、データベースがプライマリ・ロールで動作する場合はリモート宛先へのアーカイ
ブを可能にし、データベースがスタンバイ・ロールで動作する場合はリモート宛先へのアー
カイブを不可能にする必要があります。
LOG_ARCHIVE_DEST_n VALID_FOR 属性を使用して、将来のロールの推移に備えてロール
ベースの宛先を定義する方法については、5-23 ページの「VALID_FOR 属性を使用したロー
ル・ベースの宛先の指定」および第 12 章を参照してください。
ロール管理
7-25
ロジカル・スタンバイ・データベースが関与するロールの推移
手順 4 新しいプライマリ・データベースをアクティブにする
新しいプライマリ・ロールに推移させるターゲット・ロジカル・スタンバイ・データベース
で次の文を発行して SQL Apply を停止し、データベースをプライマリ・データベース・
ロールでアクティブにします。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE;
他のすべてのロジカル・スタンバイ・データベースでの手順
手順 5 他のスタンバイ・データベースのリカバリを準備する
新しいプライマリ・データベースに適用された REDO データの量に従って、既存の他のロ
ジカル・スタンバイ・データベースを Data Guard 構成に再度追加して新しいプライマリ・
データベースのスタンバイ・データベースとして使用できる場合があります。ロジカル・ス
タンバイ・データベースを Data Guard 構成に再度追加するには、各ロジカル・スタンバ
イ・データベースで次の手順を実行します。
1.
各ロジカル・スタンバイ・データベースでデータベース・リンクを作成します。
ALTER SESSION DATABASE DISABLE GUARD 文を使用してデータベース・ガードを
バイパスし、ロジカル・スタンバイ・データベース内の表に対する変更を可能にしま
す。たとえば、次の文はプライマリ・データベース chicago へのデータベース・リン
クを作成します。
SQL>
SQL>
2>
SQL>
ALTER SESSION DISABLE GUARD;
CREATE DATABASE LINK chicago
CONNECT TO username IDENTIFIED BY password USING 'chicago';
ALTER SESSION ENABLE GUARD;
CREATE DATABASE LINK 文で指定したデータベース・ユーザー・アカウントには、プ
ライマリ・データベースに対する SELECT_CATALOG_ROLE ロールが付与されている必
要があります。
データベース・リンクを作成する方法については、
『Oracle Database 管理者ガイド』を
参照してください。
2.
データベース・リンクを確認します。
ロジカル・スタンバイ・データベースで、データベース・リンクを使用して次の問合せ
を実行し、データベース・リンクが正しく構成されていることを確認します。
SQL> SELECT * FROM DBA_LOGSTDBY_PARAMETERS@chicago;
問合せが成功した場合は、手順 1 で作成したデータベース・リンクをロールの推移時に
使用できることを示します。
7-26　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースが関与するロールの推移
手順 6 SQL Apply を開始する
各ロジカル・スタンバイ・データベースで次の SQL 文を発行して、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 新しいプライマリ・データベースをバックアップする（オプション）
必要に応じて、新しいプライマリ・データベースのクローズ状態のバックアップを実行しま
す。クローズ状態のバックアップのかわりに、データベースのオープン状態のバックアップ
を実行することもできます。バックアップを即時に実行することは、必要がない場合にも推
奨される安全な手段です。これは、データベースの完全なバックアップ・コピーを作成せず
にフェイルオーバーを行うと、変更をリカバリできないためです。
手順 8 障害の発生したプライマリ・データベースをリストアする（オプション）
フェイルオーバーの実行後、必要に応じて次のどちらかの方法を使用して、障害の発生した
プライマリ・データベースを新規スタンバイ・データベースとしてリストアすることもでき
ます。
■
フラッシュバック・データベースを使用して、障害の発生したプライマリ・データベー
スをフェイルオーバー発生前の時点に変換してから、10-28 ページの「フェイルオー
バー後のフラッシュバック・データベースの使用」の手順に従ってスタンバイ・データ
ベースに変換します。
ロール管理
7-27
ロジカル・スタンバイ・データベースが関与するロールの推移
注意 : フェイルオーバーの前に、旧プライマリ・データベースでフラッ
シュバック・データベースを使用可能にしておく必要があります。詳細
は、
『Oracle Database バックアップおよびリカバリ・アドバンスト・ユー
ザーズ・ガイド』を参照してください。
■
3-8 ページの「フィジカル・スタンバイ・データベースの作成」または 4-8 ページの「ロ
ジカル・スタンバイ・データベースの作成」の手順に従って、障害の発生したデータ
ベースを再作成し、新規スタンバイ・データベースとして構成に追加します。
障害の発生したプライマリ・データベースがリストアされ、スタンバイ・ロールで稼働して
いる場合は、オプションでスイッチオーバーを実行し、データベースを元（障害前）のロー
ルに推移できます。詳細は、7-20 ページの「ロジカル・スタンバイ・データベースが関与す
るスイッチオーバー」を参照してください。
7-28　Oracle Data Guard 概要および管理
8
フィジカル・スタンバイ・データベースの管理
この章では、フィジカル・スタンバイ・データベースの管理方法について説明します。この
章は、次の項目で構成されています。
■
フィジカル・スタンバイ・データベースの起動と停止
■
読取り専用アクセス用にオープンしたスタンバイ・データベースの使用
■
スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理
■
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルの
バックアップおよびリストア
■
OPEN RESETLOGS 文を使用したリカバリ
■
プライマリおよびスタンバイ・データベースの監視
この章の各項では、フィジカル・スタンバイ・データベースを管理するための SQL 文、初
期化パラメータおよびビューの使用方法について、それぞれ説明します。
この章で説明する管理タスクを自動化するために Data Guard Broker を使用する場合は、
『Oracle Data Guard Broker』を参照してください。
フィジカル・スタンバイ・データベースの管理
8-1
フィジカル・スタンバイ・データベースの起動と停止
フィジカル・スタンバイ・データベースの起動と停止
この項では、フィジカル・スタンバイ・データベースの起動および停止に使用する
SQL*Plus 文について説明します。
フィジカル・スタンバイ・データベースの起動
フィジカル・スタンバイ・データベースを起動するには、管理者権限で SQL*Plus を使用し
てデータベースに接続し、SQL*Plus STARTUP または STARTUP MOUNT 文を使用します。こ
れらをフィジカル・スタンバイ・データベースで使用すると、次のことが実行されます。
■
■
STARTUP 文は、データベースを起動し、フィジカル・スタンバイ・データベースとして
マウントして、読取り専用アクセス用にデータベースをオープンします。
STARTUP MOUNT 文は、データベースを起動し、フィジカル・スタンバイ・データベー
スとしてマウントしますが、データベースをオープンしません。
マウントされたデータベースは、プライマリ・データベースからアーカイブ REDO
データを受信できます。次に、REDO Apply を開始するか、またはデータベースを読取
り専用アクセス用にオープンします。通常は、REDO Apply を開始します。次の例で、
フィジカル・スタンバイ・データベースの起動方法を示します。
1.
データベースを起動し、マウントします。
SQL> STARTUP MOUNT;
2.
ログ適用サービスを開始します。
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$ARCHIVED_DEST_STATUS ビューの RECOVERY_
MODE 列を問い合せ、スタンバイ・データベースの操作を REDO Apply の場合は
MANAGED_RECOVERY、リアルタイム適用の場合は MANAGED REAL TIME APPLY とし
て表示します。
REDO Apply については 6-7 ページの「REDO データのフィジカル・スタンバイ・データ
ベースへの適用」
、リアルタイム適用については 6-3 ページの「リアルタイム適用による
REDO データの即時適用」、スタンバイ・データベースを読取り専用アクセス用にオープン
する方法については 8-4 ページの「読取り専用アクセス用にオープンしたスタンバイ・デー
タベースの使用」を参照してください。
8-2　Oracle Data Guard 概要および管理
フィジカル・スタンバイ・データベースの起動と停止
注意 : 新しく作成して、プライマリ・データベースからの REDO データ
をまだ受信していないフィジカル・スタンバイ・データベース上では、初
めてログ適用サービスを開始すると、ORA-01112 メッセージが戻される
ことがあります。このメッセージは、MRP がメディア・リカバリ用の開始
順序番号を判別できないことを示します。このエラーが発生した場合は、
スタンバイ・データベースでアーカイブ REDO ログ・ファイルを手動で
検索して登録するか、または自動アーカイブが発生するまで待ってから、
ログ適用サービスを再開する必要があります。
フィジカル・スタンバイ・データベースの停止
フィジカル・スタンバイ・データベースを停止し、ログ適用サービスを停止するには、
SQL*Plus の SHUTDOWN IMMEDIATE 文を使用します。停止処理が完了するまで、データ
ベース停止を開始したセッションに制御が戻されません。
プライマリ・データベースが起動して実行中の場合は、スタンバイ・データベースを停止す
る前に、プライマリ・データベースで宛先を遅延し、ログ・スイッチ操作を実行します。
ログ適用サービスを停止してからデータベースを停止する手順は、次のとおりです。
1.
次の問合せを発行し、スタンバイ・データベースが REDO Apply またはリアルタイム
適用を実行しているかどうかを識別します。MRP0 または MRP プロセスが存在する場
合は、スタンバイ・データベースが REDO Apply を実行しています。
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
2.
ログ適用サービスが実行中の場合は、次の例に示すように取り消します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
3.
スタンバイ・データベースを停止します。
SQL> SHUTDOWN;
フィジカル・スタンバイ・データベースの管理
8-3
読取り専用アクセス用にオープンしたスタンバイ・データベースの使用
読取り専用アクセス用にオープンしたスタンバイ・データベー
スの使用
スタンバイ・データベースが読取り専用アクセス用にオープンしている場合、ユーザーはス
タンバイ・データベースを問い合せることができますが、更新はできません。したがって、
レポートを生成するためにスタンバイ・データベースを使用すると、プライマリ・データ
ベース負荷を低減できます。スタンバイ・データベースを読取り専用アクセス用に定期的に
オープンし、ログ適用サービスがスタンバイ・データベースを適切に更新していることを確
認するために、非定型問合せを実行できます。（分散問合せの場合、読取り専用データベー
スに対して問合せを発行する前に、まず ALTER DATABASE SET TRANSACTION READ
ONLY 文を発行する必要があります。）
図 8-1 に、読取り専用アクセス用にオープンしたスタンバイ・データベースを示します。
図 8-1 読取り専用アクセス用にオープンしたスタンバイ・データベース
8-4　Oracle Data Guard 概要および管理
読取り専用アクセス用にオープンしたスタンバイ・データベースの使用
この項は、次の項目で構成されています。
■
読取り専用アクセス用にスタンバイ・データベースをオープンするかどうかの評価
■
読取り専用アクセス用にフィジカル・スタンバイ・データベースをオープン
■
読取り専用アクセス用にオープンしたスタンバイ・データベースのソートに関する考慮
事項
読取り専用アクセス用にスタンバイ・データベースをオープンするかどう
かの評価
フィジカル・スタンバイ・データベースを読取り専用アクセス用にオープンするかどうかを
判断する場合は、次のことを考慮してください。
■
■
フィジカル・スタンバイ・データベースが読取り専用アクセス用にオープンされている
場合、プライマリ・データベースからの REDO データはスタンバイ・データベースに
よって受信されますが、ログ・ファイルは適用されません。したがって、読取り専用ア
クセス用にオープンしたスタンバイ・データベースは、プライマリ・データベースとの
同期が維持されません。スタンバイ・データベースで REDO Apply を再開し、アーカイ
ブ REDO ログ・ファイルを適用して、スタンバイ・データベースをプライマリ・デー
タベースと再同期化させることが必要となる場合があります。蓄積されたアーカイブ
REDO ログ・ファイルの適用には余分に時間がかかるため、スタンバイ・データベース
を読取り専用アクセス用にオープンしておくと、フェイルオーバーまたはスイッチオー
バーに時間がかかる場合があります。
スタンバイ・システムに複数のスタンバイ・データベースを構成すると、スタンバイ・
システムをレポート生成に使用し、同時にすばやくフェイルオーバーまたはスイッチ
オーバーを実行することが可能です。たとえば、ビジネス要件およびスタンバイ・シス
テムで使用可能なシステム・リソースに基づき、次の構成が可能です。
–
スタンバイ・システムに 2 つのフィジカル・スタンバイ・データベースを構成しま
す。1 つのスタンバイ・データベースでは、常に REDO Apply を実行することによ
り、プライマリ・データベースと可能なかぎり同期を取り、もう一方のスタンバ
イ・データベースは、営業時間中はレポート生成のために読取り専用モードでオー
プンにします。
–
スタンバイ・システムにフィジカル・スタンバイ・データベースを構成し、障害時
リカバリに備えてプライマリ・データベースのブロック単位のコピーを維持しま
す。また、ロジカル・スタンバイ・データベースを構成し、プライマリ・データ
ベースの最新データへのアクセスが必要なレポート生成タスクをオフロードしま
す。
同じシステム上で複数のスタンバイ・データベースを構成する場合は、REDO データを
各アーカイブ先に個別に転送するのではなく、LOG_ARCHIVE_DEST_n 初期化パラメー
タの DEPENDENCY 属性を使用して、1 つのアーカイブ先がすべてのアーカイブ先のかわ
りに REDO データを受信するように定義することを考慮してください。詳細は、5-39
フィジカル・スタンバイ・データベースの管理
8-5
読取り専用アクセス用にオープンしたスタンバイ・データベースの使用
ページの「複数のスタンバイ・データベース間でのログ・ファイル宛先の共有」を参照
してください。
読取り専用アクセス用にフィジカル・スタンバイ・データベースをオープン
フィジカル・スタンバイ・データベースは、次の手順に従って、読取り専用アクセス用オー
プンから REDO Apply の実行に（またはその逆に）変更できます。
スタンバイ・データベースが停止しているときに読取り専用アクセス用に
オープンする方法
次の文を使用して、データベースを起動し、マウントし、読取り専用アクセス用にオープン
します。
SQL> STARTUP;
スタンバイ・データベースが REDO Apply またはリアルタイム適用を実行
しているときに読取り専用アクセス用にオープンする方法
1.
REDO Apply またはリアルタイム適用を取り消します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
2.
次のように入力してデータベースを読取り専用アクセス用にオープンします。
SQL> ALTER DATABASE OPEN;
読取り専用アクセス用にオープンするために、インスタンスを停止する必要はありません。
注意 : デフォルトで、ALTER DATABASE OPEN 文は読取り専用モードで
フィジカル・スタンバイ・データベースをオープンします。Oracle データ
ベースは、制御ファイルの情報に基づいて、このデータベースがフィジカ
ル・スタンバイ・データベースであるかどうかを判断します。
スタンバイ・データベースを読取り専用アクセス用オープンから REDO
Apply 実行に変更する方法
1.
スタンバイ・データベースのすべてのアクティブ・ユーザー・セッションを終了しま
す。
2.
REDO Apply またはリアルタイム適用を再開します。REDO Apply を開始するには、次
の文を発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> DISCONNECT FROM SESSION;
リアルタイム適用を開始するには、次の文を発行します。
8-6　Oracle Data Guard 概要および管理
読取り専用アクセス用にオープンしたスタンバイ・データベースの使用
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> USING CURRENT LOGFILE;
これらの適用モードを開始するために、インスタンスを停止する必要はありません。
読取り専用アクセス用にオープンしたスタンバイ・データベースのソート
に関する考慮事項
スタンバイ・データベースを読取り専用アクセス用にオープンする前に、ソート操作に関す
る次の項目を考慮してください。
■
データベースが読取り専用アクセス用にオープンしているときのソート操作
■
一時表領域を使用しないソート操作
データベースが読取り専用アクセス用にオープンしているときのソート
操作
読取り専用アクセス用にオープンしているスタンバイ・データベースで大量のデータをソー
トする問合せを実行するには、Oracle データベースがディスク上ソートを実行できることが
必要です。Oracle ソフトウェアによるデータ・ディクショナリへの書込みが発生するため、
ソートのための領域を表領域に割り当てることはできません。
一時表領域を使用すると、問合せ作成の目的でデータベースが読取り専用アクセス用にオー
一時表領域
プンしているときに、ディクショナリ・ファイルまたは REDO 項目の生成に影響を与えず
に tempfile 項目を追加できます。したがって、一時表領域を作成するための次の要件に従
うかぎり、一時表領域を使用できます。
■
■
■
表領域は一時的なもので、ローカルで管理される必要があり、一時ファイルのみが格納
されている必要があります。
ユーザー・レベルの割当てと、ローカルで管理される一時表領域を使用する許可が、プ
ライマリ・データベース上の適所に存在する必要があります。これらの設定は、スタン
バイ・データベースでは変更できません。
一時表領域の一時ファイルをスタンバイ・データベースで作成して関連付ける必要があ
ります。
フィジカル・スタンバイ・データベースの管理
8-7
読取り専用アクセス用にオープンしたスタンバイ・データベースの使用
読取り専用フィジカル・スタンバイ・データベースで使用するために一時表
領域を作成する方法
フィジカル・スタンバイ・データベースを作成したときに一時表領域がプライマリ・データ
ベースに存在しない場合は、プライマリ・データベースで次の手順を実行します。
1.
次の SQL 文を入力します。
SQL> CREATE TEMPORARY TABLESPACE temp1
TEMPFILE '/disk1/oracle/oradata/payroll/temp1.dbf'
SIZE 20M REUSE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16M;
2.
ログ・ファイルを切り替えて、REDO データをスタンバイ・データベースに送信しま
す。
SQL> ALTER SYSTEM SWITCH LOGFILE;
読取り専用フィジカル・スタンバイ・データベースで一時ファイルを作成し
て一時表領域に関連付ける方法
プライマリ・データベースで生成された REDO データは、アーカイブ REDO ログ・ファイ
ルがフィジカル・スタンバイ・データベースに適用された後、スタンバイ制御ファイル内に
一時表領域を自動的に作成します。ただし、フィジカル・スタンバイ・データベースを作成
する前にプライマリ・データベースに一時表領域が存在している場合でも、実際にスタンバ
イ・データベースにディスク・ファイルを作成するには ADD TEMPFILE 句を使用する必要
があります。
フィジカル・スタンバイ・データベースで、次の手順を実行します。
1.
必要に応じて REDO Apply またはリアルタイム適用を開始し、アーカイブ REDO ロ
グ・ファイルを適用します。REDO Apply を開始するには、次の SQL*Plus 文を発行し
ます。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> DISCONNECT FROM SESSION;
リアルタイム適用を開始するには、次の文を発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> USING CURRENT LOGFILE;
2.
スタンバイ・データベースに接続し、V$ARCHIVED_LOG ビューを問い合せて、すべて
のアーカイブ REDO ログ・ファイルが適用されたことを確認します。
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG
2> ORDER BY SEQUENCE#;
SEQUENCE# APP
--------- --8 YES
8-8　Oracle Data Guard 概要および管理
読取り専用アクセス用にオープンしたスタンバイ・データベースの使用
9 YES
10 YES
11 YES
4 rows selected.
3.
次の SQL 文を使用して、ログ適用サービスを取り消し、フィジカル・スタンバイ・
データベースを読取り専用アクセス用にオープンします。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE OPEN;
フィジカル・スタンバイ・データベースを読取り専用アクセス用にオープンすると、一
時ファイルを追加できます。一時ファイルを追加しても REDO データは生成されない
ため、データベースを読取り専用アクセス用にオープンできます。
4.
一時表領域の一時ファイルを作成します。一時ファイルのサイズと名前は、プライマ
リ・データベースと異なっていても構いません。次に例を示します。
SQL> ALTER TABLESPACE temp1
ADD TEMPFILE '/disk1/oracle/oradata/payroll/s_temp1.dbf'
SIZE 10M REUSE;
一時表領域を使用しないソート操作
一時ファイルがスタンバイ・データベースに存在しない場合、またはスタンバイ・データ
ベースがオープンしていない場合に大量のデータのソートを試行すると、次の例に示すよう
に、エラーが戻されます。
SQL> SELECT * FROM V$PARAMETER;
select * from v$parameter
*
ERROR at line 1:
ORA-01220: データベースのオープン前のファイル・ベースのソートは無効です。
ただし、サーバー・パラメータ・ファイルで SORT_AREA_SIZE パラメータを十分な値に設
定した場合は、少量のデータをソートできます（SORT_AREA_SIZE パラメータは静的パラ
メータです。この初期化パラメータの設定方法は、『Oracle Database リファレンス』を参照
してください。
）
フィジカル・スタンバイ・データベースの管理
8-9
スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理
スタンバイ・データベースに影響を与えるプライマリ・データ
ベース・イベントの管理
問題が起きないようにするには、スタンバイ・データベースに影響するプライマリ・データ
ベースのイベントを認識し、それらに応答する方法を見極める必要があります。この項で
は、それらのイベントについて説明し、イベントに対して推奨される応答についても説明し
ます。
プライマリ・データベースで発生するイベントまたは変更の一部は、アーカイブ REDO ロ
グ・ファイルを介してスタンバイ・データベースに自動的に伝播されるため、スタンバイ・
データベースでそれ以上のアクションは不要です。それ以外の場合は、スタンバイ・データ
ベースでメンテナンス・タスクを実行する必要があります。
プライマリ・データベースで行われた変更をスタンバイ・データベースへ伝播するために
は、データベース管理者（DBA）の介入が必要かどうかを表 8-1 に示します。また、これら
のイベントに応答する方法についても簡単に説明します。応答の詳細は、表に示されている
参照先の項で説明します。
次のイベントは、ログ転送サービスおよびログ適用サービスによって自動的に管理されるた
め、データベース管理者の介入は不要です。
■
■
■
ENABLE THREAD または DISABLE THREAD 句を使用した SQL ALTER DATABASE 文の
発行
表領域の状態の変更（読取り / 書込みまたは読取り専用に変更され、オンラインまたは
オフラインにされる）
STANDBY_FILE_MANAGEMENT 初期化パラメータが AUTO に設定されている場合のデー
タ・ファイルの追加または表領域の作成
表 8-1 プライマリ・データベースでの変更後にスタンバイ・データベースで必要なアクション
参照先
プライマリ・データベースで行われた
変更
スタンバイ・データベースで必要なアクション
8-11 ページ
データ・ファイルの追加または表領域
の作成
STANDBY_FILE_MANAGEMENT 初期化パラメータを AUTO
に設定していない場合は、新しいデータ・ファイルをスタ
ンバイ・データベースにコピーする必要がある。
8-14 ページ
表領域またはデータ・ファイルの削除
DROP または DELETE コマンドが含まれているアーカイブ
REDO ログ・ファイルの適用後に、プライマリ・データ
ベースとスタンバイ・データベースからデータ・ファイル
を削除する。
8-15 ページ
トランスポータブル表領域の使用
プライマリ・データベースとスタンバイ・データベースの
間で表領域を移動する。
8-16 ページ
データ・ファイルの改名
スタンバイ・データベースでデータ・ファイルを改名する。
8-18 ページ
REDO ログ・ファイルの追加または
削除
変更をスタンバイ・データベースで同期化する。
8-10　Oracle Data Guard 概要および管理
スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理
表 8-1 プライマリ・データベースでの変更後にスタンバイ・データベースで必要なアクション（続き）
参照先
プライマリ・データベースで行われた
変更
スタンバイ・データベースで必要なアクション
8-19 ページ
プライマリ・データベース制御ファイ
ルの変更（SQL ALTER DATABASE
CREATE CONTROLFILE 文を使用）
変更に応じて、スタンバイ制御ファイルまたはスタンバ
イ・データベースを再作成する。
8-19 ページ
NOLOGGING または UNRECOVERABLE
句を使用した DML または DDL 操作
の実行
ログに記録されていない変更を含むデータ・ファイルをス
タンバイ・データベースに送信する。
第 11 章
初期化パラメータの変更
スタンバイ・パラメータを動的に変更するか、またはスタ
ンバイ・データベースを停止し、初期化パラメータ・ファ
イルを更新する。
データ・ファイルの追加または表領域の作成
STANDBY_FILE_MANAGEMENT 初期化パラメータを使用して、次のように、プライマリ・
データベースへのデータ・ファイルの追加がスタンバイ・データベースに自動的に伝播され
るかどうかを制御できます。
■
■
スタンバイ・データベースのサーバー・パラメータ・ファイル（SPFILE）で STANDBY_
FILE_MANAGEMENT 初期化パラメータを AUTO に設定した場合は、プライマリ・データ
ベースで作成された新しいデータ・ファイルがスタンバイ・データベースでも自動的に
作成されます。
STANDBY_FILE_MANAGEMENT 初期化パラメータを指定していない場合、またはこのパ
ラメータを MANUAL に設定した場合は、新しいデータ・ファイルをプライマリ・データ
ベースに追加するときに、そのデータ・ファイルをスタンバイ・データベースに手動で
コピーする必要があります。
既存のデータ・ファイルを別のデータベースからプライマリ・データベースへコピーする場
合は、STANDBY_FILE_MANAGEMENT 初期化パラメータの設定に関係なく、新しいデータ・
ファイルをスタンバイ・データベースにコピーし、スタンバイ制御ファイルを再作成する必
要があります。
次の各項では、STANDBY_FILE_MANAGEMENT 初期化パラメータが AUTO または MANUAL に
設定されている場合に、データ・ファイルをプライマリおよびスタンバイ・データベースに
追加する例を示します。
フィジカル・スタンバイ・データベースの管理
8-11
スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理
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-12　Oracle Data Guard 概要および管理
スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理
STANDBY_FILE_MANAGEMENT が MANUAL に設定されている場合の表領域
およびデータ・ファイルの追加
次の例は、STANDBY_FILE_MANAGEMENT 初期化パラメータが MANUAL に設定されている場
合に、新しいデータ・ファイルをプライマリおよびスタンバイ・データベースに追加する手
順を示しています。スタンバイ・データ・ファイルが RAW デバイスに存在する場合は、
STANDBY_FILE_MANAGEMENT 初期化パラメータを MANUAL に設定する必要があります。
1.
プライマリ・データベースに新しい表領域を追加します。
SQL> CREATE TABLESPACE new_ts DATAFILE '/disk1/oracle/oradata/payroll/t_db2.dbf'
2> SIZE 1m AUTOEXTEND ON MAXSIZE UNLIMITED;
2.
新しいデータ・ファイルがプライマリ・データベースに追加されたかどうかを確認しま
す。
SQL> SELECT NAME FROM V$DATAFILE;
NAME
---------------------------------------------------------------------/disk1/oracle/oradata/payroll/t_db1.dbf
/disk1/oracle/oradata/payroll/t_db2.dbf
3.
次の手順を実行して、表領域をリモート・スタンバイ・ロケーションにコピーします。
a.
新しい表領域をオフラインにします。
SQL> ALTER TABLESPACE new_ts OFFLINE;
b.
オペレーティング・システム・ユーティリティの copy コマンドを使用して、新し
い表領域をローカルの一時的な位置にコピーします。ファイルを一時的な位置にコ
ピーすると、表領域をオフラインにする時間が短縮されます。次の例では、UNIX
の cp コマンドを使用して表領域をコピーします。
% cp /disk1/oracle/oradata/payroll/t_db2.dbf
/disk1/oracle/oradata/payroll/s2t_db2.dbf
c.
新しい表領域をオンラインに戻します。
SQL> ALTER TABLESPACE new_ts ONLINE;
d.
オペレーティング・システム・ユーティリティのコマンドを使用して、表領域の
ローカル・コピーをリモート・スタンバイ・ロケーションにコピーします。次の例
では、UNIX の rcp コマンドを使用しています。
%rcp /disk1/oracle/oradata/payroll/s2t_db2.dbf standby_location
フィジカル・スタンバイ・データベースの管理
8-13
スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理
4.
スタンバイ・データベースに転送されるように、プライマリ・データベースでカレント
のオンライン REDO ログ・ファイルをアーカイブします。
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
5.
次の問合せを使用して、REDO Apply が実行中であることを確認します。MRP または
MRP0 プロセスが戻された場合、REDO Apply は実行されています。
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
6.
アーカイブ REDO ログ・ファイルがスタンバイ・データベースに適用された後、デー
タ・ファイルがスタンバイ・データベースに追加されたかどうかを確認します。
SQL> SELECT NAME FROM V$DATAFILE;
NAME
---------------------------------------------------------------------/disk1/oracle/oradata/payroll/s2t_db1.dbf
/disk1/oracle/oradata/payroll/s2t_db2.dbf
プライマリ・データベースの表領域の削除
プライマリ・データベースで 1 つ以上のデータ・ファイルまたは表領域を削除した場合は、
次の手順に従って、スタンバイ・データベースでも対応するデータ・ファイルを削除する必
要があります。次の各項では、STANDBY_FILE_MANAGEMENT 初期化パラメータが AUTO ま
たは MANUAL に設定されている場合に、データ・ファイルをプライマリおよびスタンバイ・
データベースから削除する例を示します。削除されたデータ・ファイルがデータベースに属
していないことを確認するには、V$DATAFILE ビューを問い合せます。
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 ビューを問い合せ、削除したデータ・ファイルがデータ
ベースに含まれていないことを確認できます。
8-14　Oracle Data Guard 概要および管理
スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理
3.
アーカイブ REDO ログ・ファイルがスタンバイ・データベースに適用された後、スタン
バイ・サイトで対応するデータ・ファイルを削除します。次に例を示します。
% rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf
4.
削除した表領域の REDO 情報がスタンバイ・データベースで適用されたことを確認した
後、プライマリ・データベースで表領域のデータ・ファイルを削除できます。次に例を
示します。
% rm /disk1/oracle/oradata/payroll/tbs_4.dbf
STANDBY_FILE_MANAGEMENT が AUTO に設定されている場合の表領域
およびデータ・ファイルの削除
プライマリ・データベースで SQL DROP TABLESPACE INCLUDING CONTENTS AND
DATAFILES 文を発行すると、プライマリ・データベースとスタンバイ・データベースの両
方からデータ・ファイルを削除できます。この文を使用するには、STANDBY_FILE_
MANAGEMENT 初期化パラメータを AUTO に設定する必要があります。たとえば、プライマ
リ・サイトで表領域を削除するには、次のように入力します。
SQL> DROP TABLESPACE NCLUDING CONTENTS AND DATAFILES tbs_4;
SQL> ALTER SYSTEM SWITCH LOGFILE;
フィジカル・スタンバイ・データベースでのトランスポータブル表領域の
使用
Oracle トランスポータブル表領域機能を使用すると、Oracle データベースのサブセットを移
動して、別の Oracle データベースにプラグインできます。これにより、実際には表領域が
データベース間で移動します。
フィジカル・スタンバイの使用中に表領域セットを移動またはコピーする手順は、次のとお
りです。
1.
トランスポートする表領域セットのデータ・ファイルとその表領域セットの構造情報を
含むエクスポート・ファイルで構成される、トランスポータブル表領域セットを生成し
ます。
2.
次の手順で表領域セットをトランスポートします。
a.
データ・ファイルとエクスポート・ファイルをプライマリ・データベースにコピー
します。
b.
データ・ファイルをスタンバイ・データベースにコピーします。
データ・ファイルは、DB_FILE_NAME_CONVERT 初期化パラメータで定義したディレク
トリに置く必要があります。DB_FILE_NAME_CONVERT が定義されていない場合は、ト
ランスポータブル表領域を含む REDO データが適用されて失敗した後に、ALTER
DATABASE RENAME FILE 文を発行してスタンバイの制御ファイルを変更します。
STANDBY_FILE_MANAGEMENT 初期化パラメータは AUTO に設定する必要があります。
フィジカル・スタンバイ・データベースの管理
8-15
スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理
3.
表領域をプラグインします。
Data Pump ユーティリティを起動して、表領域セットをプライマリ・データベースにプ
ラグインします。スタンバイ・サイトで REDO データが生成されて適用され、表領域が
スタンバイ・データベースにプラグインされます。
トランスポータブル表領域の詳細は、
『Oracle Database 管理者ガイド』を参照してくださ
い。
プライマリ・データベースのデータ・ファイルの改名
プライマリ・データベースで 1 つ以上のデータ・ファイルを改名した場合、その変更はスタ
ンバイ・データベースに伝播されません。STANDBY_FILE_MANAGEMENT 初期化パラメータ
を AUTO に設定しても変更処理は自動的に実行されないため、スタンバイ・データベースに
ある同じデータ・ファイルを改名する場合は、スタンバイ・データベースで同じ変更を手動
で行う必要があります。
次の手順では、プライマリ・データベースでデータ・ファイルを改名し、その変更をスタン
バイ・データベースに手動で伝播する方法について説明します。スタンバイ・データベース
をプライマリ・データベースと同じ物理構造にしない場合は、次の手順を実行する必要はあ
りません。
1.
プライマリ・データベースでデータ・ファイルを改名するには、表領域をオフラインに
します。
SQL> ALTER TABLESPACE tbs_4 OFFLINE;
2.
SQL プロンプトを終了し、UNIX の mv コマンドなどのオペレーティング・システム・
コマンドを発行して、プライマリ・システム上のデータ・ファイルを改名します。
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf
/disk1/oracle/oradata/payroll/tbs_x.dbf
3.
プライマリ・データベース内のデータ・ファイルを改名し、表領域をオンラインに戻し
ます。
SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE
2> '/disk1/oracle/oradata/payroll/tbs_4.dbf'
3> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
SQL> ALTER TABLESPACE tbs_4 ONLINE;
4.
スタンバイ・データベースに接続し、V$ARCHIVED_LOG ビューを問い合せてすべての
アーカイブ REDO ログ・ファイルが適用されたことを確認した後、REDO Apply を停
止します。
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# APP
--------- --8 YES
8-16　Oracle Data Guard 概要および管理
スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理
9 YES
10 YES
11 YES
4 rows selected.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
5.
スタンバイ・データベースを停止します。
SQL> SHUTDOWN;
6.
UNIX の mv コマンドなどのオペレーティング・システム・コマンドを使用して、スタ
ンバイ・サイトでデータ・ファイルを改名します。
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_
x.dbf
7.
スタンバイ・データベースを起動し、マウントします。
SQL> STARTUP MOUNT;
8.
スタンバイ制御ファイルのデータ・ファイルを改名します。STANDBY_FILE_
MANAGEMENT 初期化パラメータは MANUAL に設定する必要があります。
SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf'
2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
9.
スタンバイ・データベースで、REDO Apply を再開します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> DISCONNECT FROM SESSION;
スタンバイ・システムで対応するデータ・ファイルを改名せず、スタンバイ・データベース
制御ファイルをリフレッシュしようとすると、スタンバイ・データベースは改名されたデー
タ・ファイルの使用を試みますが、改名されたデータ・ファイルは見つかりません。した
がって、アラート・ログに次のようなエラー・メッセージが表示されます。
ORA-00283: エラーによってリカバリ・セッションは取り消されました。
ORA-01157: データ・ファイル 4 を識別 / ロックできません - DBWR トレース・ファイルを参照してください
ORA-01110: データファイル 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf'
フィジカル・スタンバイ・データベースの管理
8-17
スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理
オンライン REDO ログ・ファイルの追加または削除
データベースをチューニングするために、オンライン REDO ログ・ファイルのサイズと数
を変更する場合があります。スタンバイ・データベースへの影響なしに、プライマリ・デー
タベースへオンライン REDO ログ・ファイル・グループまたはメンバーを追加できます。
同様に、スタンバイ・データベースへの影響なしに、プライマリ・データベースからログ・
ファイル・グループまたはメンバーを削除できます。ただし、これらの変更は、スイッチ
オーバー後にスタンバイ・データベースのパフォーマンスに影響します。
注意 : オンライン REDO ログ・ファイルをプライマリ・データベースに
追加した場合は、対応するスタンバイ REDO ログ・ファイルをスタンバ
イ・データベースに追加する必要があります。
たとえば、オンライン REDO ログ・ファイルがプライマリ・データベースに 10 個、スタン
バイ・データベースに 2 個ある場合、新しいプライマリ・データベースとして機能するよう
にスタンバイ・データベースにスイッチオーバーすると、新しいプライマリ・データベース
は元のプライマリ・データベースより頻繁にアーカイブするように強制されます。
したがって、プライマリ・サイトでオンライン REDO ログ・ファイルを追加または削除し
た場合は、次の手順に従って、スタンバイ・データベースで変更を同期化することが重要で
す。
1.
REDO Apply が実行中の場合は、ログ・ファイルを変更する前に REDO Apply を取り
消す必要があります。
2.
STANDBY_FILE_MANAGEMENT 初期化パラメータを AUTO に設定している場合は、値を
MANUAL に変更します。
3.
オンライン REDO ログ・ファイルを追加または削除します。
■
オンライン REDO ログ・ファイルを追加するには、次のような SQL 文を使用しま
す。
SQL> ALTER DATABASE ADD LOGFILE '/disk1/oracle/oradata/payroll/prmy3.log'
SIZE 100M;
■
オンライン REDO ログ・ファイルを削除するには、次のような SQL 文を使用しま
す。
SQL> ALTER DATABASE DROP LOGFILE '/disk1/oracle/oradata/payroll/prmy3.log';
4.
手順 3 で使用した文を各スタンバイ・データベースで繰り返します。
5.
STANDBY_FILE_MANAGEMENT 初期化パラメータおよび REDO Apply オプションを元
の状態にリストアします。
8-18　Oracle Data Guard 概要および管理
スタンバイ・データベースに影響を与えるプライマリ・データベース・イベントの管理
プライマリ・データベースの制御ファイルの変更
プライマリ・データベースで SQL CREATE CONTROLFILE 文を使用して RESETLOGS オプ
ションを指定すると、プライマリ・データベースを次にオープンしたときにオンライン
REDO ログ・ファイルが強制的にリセットされるので、スタンバイ・データベースが無効に
なります。
スタンバイ・データベースの制御ファイルを無効にした場合は、4-15 ページの「ロジカル・
スタンバイ・データベース用の制御ファイルの作成」の手順に従ってファイルを再作成して
ください。
スタンバイ・データベースを無効にした場合は、第 4 章の手順に従ってスタンバイ・データ
ベースを再作成する必要があります。
ログに記録されていないまたはリカバリ不能な操作
NOLOGGING または UNRECOVERABLE 句を使用して DML または DDL 操作を実行するとス
タンバイ・データベースは無効になるため、修正のために多大な DBA 管理アクティビティ
が必要になる場合があります。SQL ALTER DATABASE または SQL ALTER TABLESPACE
文で FORCELOGGING 句を指定すると、NOLOGGING 設定を上書きできます。ただし、この
文はすでに無効になっているデータベースを修正しません。
リカバリ不能処理（ダイレクト・パス・ロードなど）を実行するとプライマリ・データベー
スのパフォーマンスは改善されますが、スタンバイ・データベースでは対応するリカバリ処
理のパフォーマンスの改善はなく、データを手動でスタンバイ・データベースに移動する必
要があります。
NOLOGGING 句を使用した後のリカバリについては、10-40 ページの「NOLOGGING 句を指
定した後のリカバリ」を参照してください。
フィジカル・スタンバイ・データベースの管理
8-19
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップおよびリストア
Recovery Manager を使用したフィジカル・スタンバイ・データ
ベースのファイルのバックアップおよびリストア
この項では、Data Guard およびフィジカル・スタンバイ・データベースとともに Oracle
Recovery Manager ユーティリティ（RMAN）を使用するバックアップ対策について説明し
ます。Recovery Manager は使用しやすいツールであり、最小限の労力でプライマリ・データ
ベースのバックアップを作成し、個々のデータ・ファイルの消失から、またはデータベース
全体をすばやくリカバリできます。Recovery Manager と Data Guard を併用すると、Data
Guard 構成の管理作業を簡素化できます。
注意 : ロジカル・スタンバイ・データベースはプライマリ・データベー
スのブロック単位のコピーではないため、ロジカル・スタンバイ・データ
ベースを使用してプライマリ・データベースをバックアップすることはで
きません。
バックアップ処理
この項では、データ・ファイルとアーカイブ REDO ログ・ファイルのバックアップをプラ
イマリ・データベースからスタンバイ・データベースにオフロードするように、Recovery
Manager のバックアップ処理を設定する方法について説明します。これにより、バックアッ
プ操作が本番システムに与える影響を最小限に抑えることができます。
スタンバイ環境では、プライマリまたはスタンバイ・システム上のデータ・ファイルとアー
カイブ REDO ログ・ファイルのバックアップを作成すると、両方のシステムでリカバリに
使用できます。制御ファイルや SPFILE など、一部のファイルのバックアップはプライマリ・
データベースで作成する必要がありますが、データ・ファイルとアーカイブ REDO ログ・
ファイルのバックアップ処理をスタンバイ・システムにオフロードして、バックアップ操作
が本番システムに与える影響を最小限に抑えることができます。
スタンバイ・サイトで作成できるのは、スタンバイ・インスタンスによって作成されたアー
カイブ REDO ログ・ファイルのバックアップのみです。スタンバイ・データベースの起動前
に生成されたアーカイブ REDO ログ・ファイルが存在する場合は、そのバックアップをプ
ライマリ・データベースで作成する必要があります。たとえば、プライマリ・データベース
からスタンバイに送信された最初のログがログ順序番号 100、スレッド 1 の場合は、プライ
マリ・データベースで 99 以下のログ順序番号を持つアーカイブ REDO ログ・ファイルの
バックアップを実行する必要があります。
フラッシュ・リカバリ領域が構成されている場合、Oracle ソフトウェアでは必要に応じてフ
ラッシュ・リカバリ領域からファイルが削除されます。フラッシュ・リカバリ領域は、テー
プ・バックアップ用のディスク・キャッシュとして機能します。
8-20　Oracle Data Guard 概要および管理
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップおよびリストア
テープ・バックアップ用キャッシュとしてのディスクの使用
この項では、フラッシュ・リカバリ領域が構成されており（5-7 ページの「フラッシュ・リ
カバリ領域を宛先とした設定」を参照）
、他の Recovery Manager の永続構成が設定されてい
ると仮定します。プライマリ・データベースで、次の Recovery Manager コマンドを使用し
て、制御ファイルと SPFILE の最新バックアップを作成し、プライマリ・インスタンスに
よって作成されたフラッシュ・リカバリ領域内のファイルをテープにバックアップします。
BACKUP DEVICE TYPE DISK CURRENT CONTROLFILE;
BACKUP RECOVERY AREA;
これらのコマンドは、現行の制御ファイルがすべて消失した場合に許容できる REDO デー
タの適用量に応じて（プライマリ制御ファイルの消失からのリカバリを参照）
、毎日または 1
週間に 1 回発行（またはスクリプトで使用）します。
フィジカル・スタンバイ・データベースで、次のコマンドを毎日使用して、データベースの
レベル 0 のコピーをロールフォーワードします。これらのコマンドは、前日に実行されたレ
ベル 1 の増分を適用して、新しいレベル 1 の増分を作成し、アーカイブ REDO ログ・ファ
イルをフラッシュ・リカバリ領域にバックアップして、スタンバイ・インスタンスによって
作成されたファイルをフラッシュ・リカバリ領域からテープにバックアップします。
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;
テープへの直接バックアップの実行
すべてのバックアップがテープに直接書き込まれる場合は、Recovery Manager の
CONFIGURE DEFAULT DEVICE TYPE TO SBT コマンドを使用してデフォルトのデバイ
ス・タイプを SBT に構成します。
プライマリ・データベースで、次の Recovery Manager コマンドを使用して、現行の制御
ファイルのバックアップを作成し、プライマリ・インスタンスによって作成された自動バッ
クアップをテープにコピーします。
BACKUP AS BACKUPSET CURRENT CONTROLFILE;
BACKUP RECOVERY AREA;
これらのコマンドは、現行の制御ファイルがすべて消失した場合に許容できる REDO デー
タの適用量に応じて（
「プライマリ制御ファイルの消失からのリカバリ」を参照）、毎日また
は 1 週間に 1 回発行します。
完全データベース・バックアップが毎週日曜に実行される場合は、スタンバイ・データベー
スで次のコマンドを実行してレベル 0 のデータベース・バックアップを作成できます。
BACKUP AS BACKUPSET INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG NOT BACKED UP 2 TIMES;
フィジカル・スタンバイ・データベースの管理
8-21
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップおよびリストア
バックアップ・サイクルの別の曜日に、次のコマンドを実行して、データベースとまだ 2 回
バックアップされていないすべてのアーカイブ REDO ログ・ファイルのレベル 1 増分バッ
クアップを作成します。
BACKUP AS BACKUPSET INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG NOT BACKED UP 2 TIMES;
スイッチオーバー、フェイルオーバーおよび制御ファイル作成がバック
アップに与える影響
この項では、スイッチオーバー、フェイルオーバーおよび制御ファイル作成が Recovery
Manager のバックアップ処理（データ・ファイル消失、制御ファイル消失、オンライン
REDO ログ・ファイル消失からのリカバリ、データベースの不完全リカバリ）に与える影響
について説明します。
次のいずれかのイベントが発生した場合は、Recovery Manager の CATALOG ARCHIVELOG
'archivelog_name_complete_path' コマンドを使用して、バックアップが実行されたシステム
上で最後のバックアップ以後に生成されたアーカイブ REDO ログ・ファイルをすべて手動
でカタログ化する必要があります。
■
■
■
プライマリまたはスタンバイ制御ファイルが再作成された場合。
プライマリ・データベース・ロールが、スイッチオーバー後にスタンバイに変更された
場合。
スタンバイ・データベース・ロールが、スイッチオーバーまたはフェイルオーバー後に
プライマリに変更された場合。
新規アーカイブ REDO ログ・ファイルがカタログ化されていない場合、Recovery Manager
ではバックアップを作成できません。
次の各項の例では、バックアップを作成したのと同じシステムにテープからファイルをリス
トアすると仮定しています。ファイルを異なるシステムにリストアする場合は、メディア構
成を変更するか、リストア中に Recovery Manager チャネルで異なる PARMS を指定するか、
あるいはその両方の操作が必要になることがあります。異なるシステムから Recovery
Manager バックアップにアクセスする方法の詳細は、メディア管理のドキュメントを参照し
てください。
プライマリ・データベースのデータ・ファイル消失からのリカバリ
次の Recovery Manager コマンドを実行してデータ・ファイルをリストアおよびリカバリし
ます。プライマリ・データベースとリカバリ・カタログ・データベースの両方に接続する必
要があります。
RESTORE DATAFILE <n,m...>;
RECOVER DATAFILE <n,m...>;
8-22　Oracle Data Guard 概要および管理
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップおよびリストア
次の Recovery Manager コマンドを実行して、表領域をリストアおよびリカバリします。プ
ライマリ・データベースとリカバリ・カタログ・データベースの両方に接続する必要があり
ます。
RESTORE TABLESPACE <tbs_name1, tbs_name2, ...>
RECOVER TABLESPACE <tbs_name1, tbs_name2, ...>
スタンバイ・データベースのデータ・ファイル消失からのリカバリ
1 つ以上のデータ・ファイルが消失した後にスタンバイ・データベースをリカバリするには、
Recovery Manager の RESTORE DATAFILE コマンドを使用して、消失したファイルをバッ
クアップからスタンバイ・データベースにリストアする必要があります。破損ファイルのリ
カバリに必要なアーカイブ REDO ログ・ファイルすべてにスタンバイがディスク上でアク
セス可能な場合は、REDO Apply を再開します。
リカバリに必要なアーカイブ REDO ログ・ファイルにディスク上でアクセスできない場合
は、次の手順に従って Recovery Manager を使用し、リストアしたデータ・ファイルをスタ
ンバイ・データベースに最後に適用されたログよりも大きい SCN/ ログ順序番号までリカバ
リし、REDO Apply を再開して REDO データの適用を続行します。
1.
REDO Apply を停止します。
2.
次のように入力して UNTIL_SCN 列の値を判別します。
SQL> SELECT MAX(NEXT_CHANGE#)+1 UNTIL_SCN FROM V$LOG_HISTORY LH, V$DATABASE DB
WHERE LH.RESETLOGS_CHANGE#=DB.RESETLOGS_CHANGE# AND LH.RESETLOGS_TIME =
DB.RESETLOGS_TIME;
UNTIL_SCN
------- ---------------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 を再開します。
フィジカル・スタンバイ・データベースの管理
8-23
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップおよびリストア
スタンバイ制御ファイルの消失からのリカバリ
Oracle ソフトウェアでは、スタンバイ制御ファイルを多重化できます。スタンバイ制御ファ
イルが多重化されているかどうかを確認するには、次のように CONTROL_FILES 初期化パラ
メータを調べます。
SQL> SHOW PARAMETER CONTROL_FILES
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------control_files
string
<cfilepath1>,<cfilepath2>
多重スタンバイ制御ファイルの 1 つが消失しているかアクセスできないと、Oracle ソフト
ウェアはインスタンスを停止して、アラート・ログに次のメッセージを書き込みます。
ORA-00210: 指定された制御ファイルをオープンできません。
ORA-00202: 制御ファイル : '/ade/banand_hosted6/oracle/dbs/scf3_2.f'
ORA-27041: ファイルをオープンできません。
制御ファイルの元のコピーを消失したコピーに上書きコピーし、次の SQL 文を使用してス
タンバイ・インスタンスを再起動できます。
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
スタンバイ制御ファイルがすべて消失した場合は、プライマリ・データベースから新規制御
ファイルを作成し、それをスタンバイ・データベースのすべての多重化位置にコピーして、
スタンバイ・インスタンスを再起動し、REDO Apply を再開する必要があります。作成され
た制御ファイルからは、作成前に生成されていたアーカイブ REDO ログ・ファイルに関す
る情報がすべて失われています。Recovery Manager はバックアップ対象となるアーカイブ
REDO ログ・ファイルのリストを制御ファイル内で検索するため、「スイッチオーバー、
フェイルオーバーおよび制御ファイル作成がバックアップに与える影響」で説明したよう
に、前回のバックアップ以後に生成されたアーカイブ REDO ログ・ファイルをすべて手動
でカタログ化する必要があります。
プライマリ制御ファイルの消失からのリカバリ
Oracle ソフトウェアでは、プライマリ・データベースの制御ファイルを多重化できます。プ
ライマリ・データベースで制御ファイルの 1 つを更新できない場合は、プライマリ・データ
ベース・インスタンスが自動的に停止します。「スタンバイ制御ファイルの消失からのリカ
バリ」で説明したように、リストアまたはリカバリ操作を実行しなくても、制御ファイルの
元のコピーをコピーしてインスタンスを再起動できます。
制御ファイルがすべて消失した場合は、許容できるダウンタイムに応じて次の手順から選択
できます。
8-24　Oracle Data Guard 概要および管理
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップおよびリストア
新規制御ファイルの作成 制御ファイルのコピーがすべて消失した場合は、メディア・リカ
バリの実行後に 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.1 からは、RESETLOGS 操作の前に作成したバックアップすべてをリ
カバリに使用できます。そのため、本番に使用可能にする前にデータベースのバックアップ
を作成する必要はありません。
フィジカル・スタンバイ・データベースの管理
8-25
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップおよびリストア
オンライン REDO ログ・ファイルの消失からのリカバリ
オンライン REDO ログ・ファイルは多重化することをお薦めします。オンライン REDO ロ
グ・グループのメンバーがすべて消失すると、Oracle ソフトウェアはインスタンスを終了し
ます。書込みできないのがログ・ファイル・グループの一部のメンバーのみの場合、そのメ
ンバーはアクセス可能になるまで使用されません。V$LOGFILE および V$LOG ビューには、
プライマリ・データベース・インスタンスのログ・ファイル・メンバーの現在のステータス
に関する詳細情報が含まれます。
Oracle ソフトウェアがオンライン REDO ログ・ファイルのメンバーの 1 つに書込みできな
い場合は、次のアラート・メッセージが戻されます。
ORA-00313: ログ・グループ 1（スレッド 1）のメンバーをオープンできません。
ORA-00312: オンライン・ログ 1 スレッド 1: '/ade/banand_hosted6/oracle/dbs/t1_log1.f'
ORA-27037: ファイル・ステータスを取得できません。
SVR4 Error: 2: No such file or directory
Additional information: 3
アクセスの問題がハードウェア・エラーによる一時的なものの場合は、問題を解決すると処
理が自動的に続行されます。消失が永続的な場合は、新規メンバーを追加して古いメンバー
をグループから削除できます。
REDO ログ・グループに新規メンバーを追加するには、SQL ALTER DATABASE ADD
LOGFILE MEMBER 'log_file_name' REUSE TO GROUP n 文を使用します。この操作は、
データベースがオープン状態の場合にも、データベースの可用性に影響を与えずに実行でき
ます。
アーカイブ済の非アクティブ・グループのメンバーがすべて消失した場合は、そのグループ
を削除して再作成できます。
他のすべての場合（現行の ACTIVE グループまたはアーカイブされていない非アクティブ・
グループのオンライン・ログ・メンバーすべてが消失した場合）は、スタンバイ・データ
ベースにフェイルオーバーする必要があります。手順については第 7 章を参照してください。
データベースの不完全リカバリ
プライマリ・データベースの不完全リカバリを実行するのは、通常、データベースが論理的
に（ユーザーまたはアプリケーションが原因で）破損した場合や、表領域またはデータ・
ファイルがデータベースから意図せずに削除された場合などです。
スタンバイ・データベース・インスタンス上の現在のデータベース・チェックポイント SCN
に応じて、次のいずれかの手順でデータベースの不完全リカバリを実行できます。すべての
手順は、最も所要時間が短いものから優先順位順になっています。
8-26　Oracle Data Guard 概要および管理
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップおよびリストア
フラッシュバック・データベースの使用 フラッシュバック・データベースの使用は、プラ
イマリ・データベースでフラッシュバック機能が使用可能で、データベース・ファイルが 1
つも消失しておらず、Point-in-Time リカバリが最も古いフラッシュバック SCN より大きい
か、最も早いフラッシュバック時間よりも後の場合の推奨手順です。フラッシュバック・
データベースを使用して Point-in-Time リカバリを実行する手順については、10-32 ページの
「Open Resetlogs 文の発行後のフラッシュバック・データベースの使用」を参照してくださ
い。
スタンバイ・データベース・インスタンスの使用 これは、スタンバイ・データベースが必
要な不完全リカバリ時間より後のもので、プライマリまたはスタンバイ・データベースでフ
ラッシュバック・データベースが使用可能でない場合の推奨手順です。
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
スタンバイ・データベースを読取り専用モードでオープンし、データベースの状態を確
認します。
必要な状態になっていない場合は、LogMiner ユーティリティを使用してアーカイブ
REDO ログ・ファイルを調べ、不完全リカバリに適切なターゲット時刻または SCN を
確認します。または、ターゲット時刻より前の判明している時点までスタンバイをリカ
バリしてから、データベースを読取り専用モードでオープンし、データの状態を検査す
ることもできます。データベースの状態が正常であると確認されるまで、このプロセス
を繰り返します。データベースのリカバリ終了時点が遅すぎると（つまり、エラーが発
生した SCN より後までリカバリすると）、それより前の SCN に戻せないことに注意し
てください。
2.
SQL ALTER DATABASE ACTIVATE STANDBY DATABASE 文を使用してスタンバイ・
データベースをアクティブ化します。これにより、スタンバイ・データベースがプライ
マリ・データベースに変換され、新しいリセットログ・ブランチが作成され、データ
ベースがオープンします。新規リセットログ・ブランチへのスタンバイ・データベース
の対応については、
「OPEN RESETLOGS 文を使用したリカバリ」を参照してください。
プライマリ・データベース・インスタンスの使用 すべてのスタンバイ・データベース・イ
ンスタンスがすでに必要な時点より後までリカバリされており、プライマリまたはスタンバ
イ・データベースでフラッシュバック・データベースが使用可能な場合は、この方法で操作
する必要があります。
次の手順に従ってプライマリ・データベースで不完全リカバリを実行します。
フィジカル・スタンバイ・データベースの管理
8-27
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップおよびリストア
1.
LogMiner または他の手段を使用して、データベースのすべてのデータが正常と判明し
ている時点または SCN を識別します。
2.
その時点または SCN を使用して次の Recovery Manager コマンドを実行し、不完全
データベース・リカバリを実行し、RESETLOGS オプションを使用して（カタログ・
データベースと MOUNT 状態のプライマリ・インスタンスに接続した後で）データベー
スをオープンします。
RUN
{
SET UNTIL TIME '<time>';
RESTORE DATABASE;
RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;
この処理の後に、Data Guard 構成内ですべてのスタンバイ・データベース・インスタンス
を再確立する必要があります。
その他のバックアップ状況
この項では、スタンバイ・データベースがプライマリ・データベースから地理的に離れてい
る場合や、スタンバイ・データベースのファイル名がプライマリ・データベースとは異なる
場合など、特殊な状況で Recovery Manager のバックアップ処理を使用する方法について説
明します。
次の各項では、スタンバイ・データベースとプライマリ・データベースでバックアップ・
ファイルを共有できない場合、REDO ログ・ファイルのリモート・アーカイブにスタンバ
イ・インスタンスのみが使用される場合、またはスタンバイ・データベースのファイル名が
プライマリ・データベースとは異なる場合など、その他の構成にあわせてバックアップ処理
を変更する方法について説明します。
スタンバイ・データベースが地理的に離れすぎているためにバックアッ
プを共有できない場合
この場合、プライマリ・システムや他のスタンバイ・システムからは、スタンバイ・システ
ム上で作成されたバックアップに簡単にアクセスできません。すべてのシステム上でデータ
ベースの完全バックアップを実行して、リカバリ操作を実行します。フラッシュ・リカバリ
領域は、プライマリおよびスタンバイ・システム上にローカルに置くことができます（プラ
イマリ・データベースとスタンバイ・データベースでフラッシュ・リカバリ領域が異なる場
合など）
。
この使用例でも、
「スイッチオーバー、フェイルオーバーおよび制御ファイル作成がバック
アップに与える影響」で説明した一般的な対策を使用できますが、次の例外があります。
■
Recovery Manager で作成されるバックアップ・ファイルには、タグとしてローカル・
システム名を指定し、そのタグを RESTORE 操作で使用して、Recovery Manager による
8-28　Oracle Data Guard 概要および管理
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-40 ページの「アーカイブ・ギャップの管理」で説明したように、スタンバイ・インスタン
スにより残りのアーカイブ REDO ログ・ファイルがフェッチされます。
フェッチ・アーカイブ・ログ（FAL）サーバーとして使用されるスタン
）サーバーとして使用されるスタン
フェッチ・アーカイブ・ログ（
バイ・データベースにデータ・ファイルが含まれていない場合
「バックアップ処理」で説明した手順を使用しますが、データベース・ファイルをバック
アップする Recovery Manager コマンドは FAL サーバーに対して実行できません。FAL サー
バーは、すべてのアーカイブ REDO ログ・ファイルのバックアップ・ソースとして使用で
きるため、アーカイブ REDO ログ・ファイルのバックアップを FAL サーバーにオフロード
します。
フィジカル・スタンバイ・データベースの管理
8-29
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップおよびリストア
スタンバイ・データベースのファイル名がプライマリ・データベースと
は異なる場合
プライマリ・データベースとスタンバイ・データベースでデータベース・ファイル名が異な
る場合は、少し異なる 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 オプションを使用
して、スタンバイ・データベースの作成中に新規ファイル名を指定する必要があります。
8-30　Oracle Data Guard 概要および管理
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップおよびリストア
フラッシュ・リカバリ領域のアーカイブ 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 句を使用します。次の表に、この句を指定した場合に実行さ
れるアクションを示します。
APPLIED ON STANDBY 句の構成場所 . .
削除対象となるファイル . .
プライマリ・データベース
すべての必須スタンバイ・データベースに適用済の、
フラッシュ・リカバリ領域内のアーカイブ REDO ロ
グ・ファイル
1 つ以上の必須のカスケード・スタンバイ・
データベースを持つスタンバイ・データ
ベース
すべての必須カスケード・スタンバイ・データベース
に適用済の、フラッシュ・リカバリ領域内のアーカイ
ブ REDO ログ・ファイル
必須のカスケード・スタンバイ・データベー
スを持たないスタンバイ・データベース
スタンバイ・データベースに適用済の、フラッシュ・
リカバリ領域内のアーカイブ REDO ログ・ファイル
カスケードされた REDO ログ宛先の詳細は、付録 C を参照してください。
CLEAR 句の使用
CLEAR 句を使用して、Recovery Manager の CONFIGURE ARCHIVELOG DELETION
POLICY コマンドで前に設定した削除ポリシーを使用不可能にします。Oracle データベース
は、デフォルトの削除ポリシー動作を再開します。つまり、フラッシュ・リカバリ領域の
ディスク領域がいっぱいになると、バックアップ済または廃止になったアーカイブ REDO
ログ・ファイルを削除して領域を解放します。
フィジカル・スタンバイ・データベースの管理
8-31
Recovery Manager を使用したフィジカル・スタンバイ・データベースのファイルのバックアップおよびリストア
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;
ロールが推移した後の削除ポリシーの再構成
スイッチオーバーまたはフェイルオーバーの後に、各データベースで Recovery Manager の
CONFIGURE ARCHIVELOG DELETION POLICY コマンドの再発行が必要になる場合があり
ます。アーカイブ REDO ログ・ファイルのバックアップ・サイトが同一の場合、何も実行す
る必要はありません。それ以外の場合は、バックアップが作成されないデータベースで
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY 文を発行し、
バックアップが作成されるデータベースで CONFIGURE ARCHIVELOG DELETION POLICY
TO NONE 文を発行して、ARCHIVELOG 削除ポリシーを切り替える必要があります。
8-32　Oracle Data Guard 概要および管理
OPEN RESETLOGS 文を使用したリカバリ
現行の削除ポリシーの表示
データベースに対する現行の設定（APPLIED ON STANDBY、CLEAR、NONE）を確認するに
は、次の問合せを発行します。
SELECT NAME, VALUE FROM V$RMAN_CONFIGURATION WHERE
NAME LIKE '%ARCHIVELOG DELETION POLICY%';
NAME
----------------------------ARCHIVELOG DELETION POLICY
VALUE
-------------TO APPLIED ON STANDBY
次のように、Recovery Manager の SHOW ARCHIVELOG DELETION POLICY コマンドを使
用して既存の構成を検索することもできます。
RMAN> SHOW ARCHIVELOG DELETION POLICY
RMAN configuration parameters are:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
OPEN RESETLOGS 文を使用したリカバリ
Data Guard では、RESETLOGS オプションを使用してプライマリ・データベースがオープン
された後も、フィジカル・スタンバイ・データベースでリカバリを続行できます。プライマ
リ・データベースで ALTER DATABASE OPEN RESETLOGS 文を発行すると、データベース
のインカネーションが変更され、REDO データの新規ブランチが作成されます。
フィジカル・スタンバイ・データベースが REDO データの新規ブランチを受信すると、
REDO Apply が停止し、スタンバイ・データベースでの管理リカバリ・プロセス（MRP）
が終了します。この時点で、次の表に示すようにスタンバイ・データベースとプライマリ・
データベースのブランチを再同期化できます。
フィジカル・スタンバイ・データベースの管理
8-33
OPEN RESETLOGS 文を使用したリカバリ
スタンバイ・データベースの状態 . .
新規リセットログの SCN の後
（REDO データの新規ブランチの開
始より後）の REDO データが適用さ
れていない場合。
操作 . .
実行する手順 . .
メディア・リカバリを再開す
ると、スタンバイ・データ
ベースが新規ブランチに自動
的にリカバリされます。
REDO Apply を再開して REDO データの適用
を続行します。MRP は、自動的にスタンバイ・
データベースを REDO データの新規ブランチ
と再同期化します。
新規リセットログの SCN の後
スタンバイ・データベースは、 1.
REDO データの将来の新規ブ
（REDO データの新規ブランチの開
始より後）の REDO データが適用さ ランチでリカバリされます。
れ、スタンバイ・データベースでフ
ラッシュバック・データベースが使
用可能になっている場合。
2.
10-32 ページの「フィジカル・スタンバ
イ・データベースのフラッシュバック」
の手順に従ってフィジカル・スタンバイ・
データベースをフラッシュ・バックしま
す。
REDO Apply を再開し、新規リセットロ
グ・ブランチへの REDO データの適用を
続行します。
MRP は、自動的にスタンバイ・データベース
を新規ブランチと再同期化します。
新規リセットログの SCN の後
（REDO データの新規ブランチの開
始より後）の REDO データが適用さ
れ、スタンバイ・データベースでフ
ラッシュバック・データベースが使
用可能になっていない場合。
指定のプライマリ・データ
第 3 章の手順に従ってフィジカル・スタンバ
ベース・ブランチで、プライ イ・データベースを再作成します。
マリ・データベースとスタン
バイの内容にずれが生じます。
REDO データの新規ブランチから介 MRP は欠落しているログ・
入するアーカイブ REDO ログ・ファ ファイルが取得されるまで続
行できません。
イルが欠落している場合。
各ブランチから欠落しているアーカイブ
REDO ログ・ファイルを検索して登録します。
REDO データの前のブランチの終わ MRP は欠落しているログ・
りからアーカイブ REDO ログ・ファ ファイルが取得されるまで続
行できません。
イルが欠落している場合。
前のブランチから欠落しているアーカイブ
REDO ログ・ファイルを検索して登録します。
データベース・インカネーション、OPEN RESETLOGS 操作を介したリカバリおよびフラッ
シュバック・データベースの詳細は、
『Oracle Database バックアップおよびリカバリ・アド
バンスト・ユーザーズ・ガイド』を参照してください。
8-34　Oracle Data Guard 概要および管理
プライマリおよびスタンバイ・データベースの監視
プライマリおよびスタンバイ・データベースの監視
この項では、Data Guard 環境のプライマリおよびスタンバイ・データベースを監視するた
めの情報の検索方法について概要を説明します。
この項は、次の項目で構成されています。
■
アラート・ログ
■
動的パフォーマンス・ビュー（固定ビュー）
■
リカバリの進捗の監視
表 8-2 に、プライマリ・データベースで発生する共通イベント、およびプライマリ・サイト
とスタンバイ・サイトでこれらのイベントを監視できるファイルとビューに関する情報をま
とめます。
表 8-2 プライマリ・データベースの共通アクションを監視できる場所
プライマリ・データベース・イベント
ENABLE THREAD または DISABLE
THREAD 句を指定した SQL ALTER
DATABASE 文の発行
REDO ログの変更
プライマリ・サイト情報
CREATE CONTROLFILE 文の発行
アラート・ログ
■
アラート・ログ
■
V$THREAD ビュー
■
アラート・ログ
■
V$LOG ビュー
■
スタンバイ・サイト情報
アラート・ログ
V$LOGFILE ビューの STATUS
列
アラート・ログ
アラート・ログ
注意 : CREATE CONTROLFILE 文を
プライマリ・データベースで発行し
た場合、スタンバイ・データベース
は初期化パラメータに応じて、
REDO データを検出しないかぎり
正常に機能します。
管理リカバリの実行
表領域の状態の変更（読取り / 書込み
または読取り専用にされ、オンライン
またはオフラインにされる）
データ・ファイルの追加または表領域
の作成
表領域の削除
アラート・ログ
アラート・ログ
■
DBA_TABLESPACES ビュー
■
アラート・ログ
■
DBA_DATA_FILES ビュー
V$DATAFILE ビュー
■
アラート・ログ
アラート・ログ
■
DBA_DATA_FILES ビュー
V$DATAFILE ビュー
■
アラート・ログ
アラート・ログ
V$RECOVER_FILE ビュー
フィジカル・スタンバイ・データベースの管理
8-35
プライマリおよびスタンバイ・データベースの監視
表 8-2 プライマリ・データベースの共通アクションを監視できる場所（続き）
プライマリ・データベース・イベント
表領域またはデータ・ファイルをオフ
ラインにする、またはデータ・ファイ
ルをオフラインで削除する
データ・ファイルの改名
ログに記録されていないまたはリカバ
リ不能な操作
リカバリの進捗
プライマリ・サイト情報
スタンバイ・サイト情報
■
V$RECOVER_FILE ビュー
■
アラート・ログ
■
V$DATAFILE
V$DATAFILE ビュー
■
アラート・ログ
アラート・ログ
■
V$DATAFILE ビュー
アラート・ログ
■
V$DATABASE ビュー
■
■
V$ARCHIVE_DEST_STATUS
ビュー
アラート・ログ
V$RECOVER_FILE ビュー
V$ARCHIVED_LOG ビュー
V$LOG_HISTORY ビュー
V$MANAGED_STANDBY ビュー
アラート・ログ
ログ転送のステータスと進捗
■
V$ARCHIVE_DEST_STATUS
ビュー
■
V$ARCHIVED_LOG ビュー
■
V$ARCHIVE_DEST ビュー
■
アラート・ログ
V$ARCHIVED_LOG ビュー
アラート・ログ
データ・ファイルの自動拡張
アラート・ログ
アラート・ログ
OPEN RESETLOGS または CLEAR
UNARCHIVED LOGFILES 文の発行
アラート・ログ
アラート・ログ
初期化パラメータの変更
アラート・ログ
アラート・ログ
8-36　Oracle Data Guard 概要および管理
プライマリおよびスタンバイ・データベースの監視
アラート・ログ
データベースのアラート・ログは、メッセージとエラーに関する時系列のレコードです。ア
ラート・ログには、Oracle データベースに関する情報に加えて、次のような Data Guard 固
有の操作に関する情報も含まれています。
■
■
■
SQL 文の ALTER DATABASE RECOVER MANAGED STANDBY、STARTUP、SHUTDOWN、
ARCHIVE LOG、RECOVER などの管理操作に関連するメッセージ
ARC0、MRP0、RFS、LGWR などのバックグラウンド・プロセスでレポートされる管理
操作に関連するエラー
管理操作の完了タイムスタンプ
アラート・ログは、特定のプロセスで生成されたトレース・ファイルまたはダンプ・ファイ
ルに関する情報も提供します。
動的パフォーマンス・ビュー（固定ビュー）
Oracle データベースには、基礎となるビューのセットがあります。これらのビューは、デー
タベースがオープン状態および使用中の場合に連続的に更新されるため、動的パフォーマン
動的パフォーマン
ス・ビューと呼ばれることがあります。その内容は主にパフォーマンスに関連しています。
ス・ビュー
また、これらのビューは、データベース管理者が変更または削除できないので、固定ビュー
固定ビュー
と呼ばれることもあります。
これらのビューの名前には、V$ または GV$ という接頭辞が付き、たとえば V$ARCHIVE_
DEST や GV$ARCHIVE_DEST のようになります。
標準の動的パフォーマンス・ビュー（V$ 固定ビュー）には、ローカル・インスタンスの情
報が格納されます。それに対して、グローバル動的パフォーマンス・ビュー（GV$ 固定
ビュー）には、すべてのオープン・インスタンスの情報が格納されます。各 V$ 固定ビュー
には対応する GV$ 固定ビューがあります。GV$ 固定ビューを選択すると、全インスタンス
の情報を取得するために、パラレル問合せのスレーブが使用されます。追加情報は、第 14 章
「Oracle Data Guard に関連するビュー」および『Oracle Database リファレンス』を参照し
てください。
フィジカル・スタンバイ・データベースの管理
8-37
プライマリおよびスタンバイ・データベースの監視
リカバリの進捗の監視
この項では、
「動的パフォーマンス・ビュー（固定ビュー）」で説明した、Data Guard 環境
でリカバリの進捗を監視するビューの例をいくつか示します。この項は、次の例で構成され
ています。
■
プロセス・アクティビティの監視
■
REDO Apply の進捗の確認
■
アーカイブ REDO ログ・ファイルの位置および作成者の確認
■
OPEN RESETLOGS 操作の前後のデータベース・インカネーションの表示
■
アーカイブ REDO ログ履歴の表示
■
スタンバイ・データベースに適用されたログ・ファイルの確認
■
スタンバイ・サイトが受信しなかったログ・ファイルの確認
プロセス・アクティビティの監視
次のプロセスを実行してアクティビティを監視することにより、スタンバイ・データベース
での REDO Apply に関する情報を取得できます。
参照名
システム・プロセス名
ARCH
ARC0,ARC1,ARC2,…
MRP
MRP、MRP0
RFS
ORACLE{SID}
スタンバイ・データベース・サイトの V$MANAGED_STANDBY ビューには、Data Guard 環境
内でログ転送プロセスおよびログ適用プロセスの両方で実行されたアクティビティが表示さ
れます。次の問合せ出力の CLIENT_P 列で、対応するプライマリ・データベース・プロセス
を識別します。
SQL> SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;
PROCESS
------ARCH
ARCH
MRP0
RFS
RFS
CLIENT_P SEQUENCE# STATUS
-------- ---------- -----------ARCH
0 CONNECTED
ARCH
0 CONNECTED
N/A
204 WAIT_FOR_LOG
LGWR
204 WRITING
N/A
0 RECEIVING
8-38　Oracle Data Guard 概要および管理
プライマリおよびスタンバイ・データベースの監視
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
アーカイブ REDO ログ・ファイルの位置および作成者の確認
スタンバイ・データベースで V$ARCHIVED_LOG ビューを問い合せて、アーカイブ REDO ロ
グに関する追加情報を検索できます。このビューから、アーカイブ REDO ログの位置、アー
カイブ REDO ログを作成したプロセス、各アーカイブ REDO ログ・ファイルの REDO ログ
順序番号、各ログ・ファイルがアーカイブされた時期、アーカイブ REDO ログ・ファイル
が適用されたかどうかなどの情報を取得できます。次に例を示します。
SQL> SELECT NAME, CREATOR, SEQUENCE#, APPLIED, COMPLETION_TIME
2> FROM V$ARCHIVED_LOG;
NAME
---------------------------------------------H:¥ORACLE¥ORADATA¥PAYROLL¥STANDBY¥ARC00198.001
H:¥ORACLE¥ORADATA¥PAYROLL¥STANDBY¥ARC00199.001
H:¥ORACLE¥ORADATA¥PAYROLL¥STANDBY¥ARC00200.001
H:¥ORACLE¥ORADATA¥PAYROLL¥STANDBY¥ARC00201.001
H:¥ORACLE¥ORADATA¥PAYROLL¥STANDBY¥ARC00202.001
H:¥ORACLE¥ORADATA¥PAYROLL¥STANDBY¥ARC00203.001
CREATOR SEQUENCE# APP COMPLETIO
------- --------- --- --------ARCH
198 YES 30-MAY-02
ARCH
199 YES 30-MAY-02
ARCH
200 YES 30-MAY-02
LGWR
201 YES 30-MAY-02
ARCH
202 YES 30-MAY-02
LGWR
203 YES 30-MAY-02
6 rows selected.
フィジカル・スタンバイ・データベースの管理
8-39
プライマリおよびスタンバイ・データベースの監視
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,SEQUENCE#,STATUS,ARCHIVED FROM V$ARCHIVED_LOG
2 ORDER BY RESETLOGS_ID,SEQUENCE# ;
RESETLOGS_ID
-----------509275501
509275501
509275501
509275501
509275501
THREAD#
------1
1
1
1
1
SEQUENCE#
--------1
2
3
4
5
S
A
A
A
A
A
ARC
---YES
YES
YES
YES
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,SEQUENCE#,STATUS,ARCHIVED FROM V$ARCHIVED_LOG
2 ORDER BY RESETLOGS_ID,SEQUENCE# ;
RESETLOGS_ID
-----------509275501
509275501
509275501
509275501
THREAD#
------1
1
1
1
8-40　Oracle Data Guard 概要および管理
SEQUENCE#
--------1
2
3
4
S
A
A
A
A
ARC
--YES
YES
YES
YES
プライマリおよびスタンバイ・データベースの監視
509275501
509278970
509278970
509278970
8 rows selected.
1
1
1
1
5
1
2
3
A
A
A
A
YES
YES
YES
YES
アーカイブ 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
1
13-MAY-02
214480
234595
2
13-MAY-02
234595
254713
3
.
.
.
30-MAY-02
3418615
3418874
201
30-MAY-02
3418874
3419280
202
30-MAY-02
3419280
3421165
203
203 rows selected.
スタンバイ・データベースに適用されたログ・ファイルの確認
スタンバイ・データベースで V$LOG_HISTORY ビューを問い合せてください。このビューに
は、適用された最新のログ順序番号が記録されています。たとえば、次のような問合せを発
行します。
SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG"
2> FROM V$LOG_HISTORY
3> GROUP BY THREAD#;
THREAD# LAST_APPLIED_LOG
------- ---------------1
967
この例では、ログ順序番号 967 のアーカイブ REDO ログ・ファイルが最新の適用済ログ・
ファイルです。
また、スタンバイ・データベースで V$ARCHIVED_LOG 固定ビューの APPLIED 列を使用す
ると、スタンバイ・データベースに適用されたログ・ファイルを識別できます。適用された
ログ・ファイルの場合は列に YES と表示されます。次に例を示します。
フィジカル・スタンバイ・データベースの管理
8-41
プライマリおよびスタンバイ・データベースの監視
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.
スタンバイ・サイトが受信しなかったログ・ファイルの確認
各アーカイブ先には、割り当てられた宛先 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-42　Oracle Data Guard 概要および管理
9
ロジカル・スタンバイ・データベースの管理
この章では、ロジカル・スタンバイ・データベースの管理方法を説明します。この章は、次
の項目で構成されています。
■
ロジカル・スタンバイ・データベースの構成と管理
■
Oracle Database ソフトウェア・バージョンのアップグレード
■
OPEN RESETLOGS 文を使用したリカバリ
■
ロジカル・スタンバイ・データベースのチューニング
この章の各項では、ロジカル・スタンバイ・データベースを管理するための SQL 文、初期
化パラメータ、ビューおよび PL/SQL パッケージ DBMS_LOGSTDBY の使用方法について、
それぞれ説明します。
この章で説明する管理タスクを自動化するために Data Guard Broker を使用する場合は、
『Oracle Data Guard Broker』を参照してください。
ロジカル・スタンバイ・データベースの管理
9-1
ロジカル・スタンバイ・データベースの構成と管理
ロジカル・スタンバイ・データベースの構成と管理
この PL/SQL パッケージ DBMS_LOGSTDBY には、ロジカル・スタンバイ・データベースの
構成と管理に役立つプロシージャが用意されています。PL/SQL パッケージ DBMS_
LOGSTDBY を使用すると、ロジカル・スタンバイ・データベースに関する次のような管理タ
スクを実行できます。
■
SQL Apply の管理
■
ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスの制御
■
SQL Apply で不要になったアーカイブ REDO ログ・ファイルの削除
■
ロジカル・スタンバイ・データベースの変更
■
ロジカル・スタンバイ・データベースでのトリガーと制約の処理方法
■
ロジカル・スタンバイ・データベースでの SQL 文のスキップ
■
ロジカル・スタンバイ・データベースでの表の追加または再作成
■
ロジカル・スタンバイ・イベントの表示と制御
■
SQL Apply アクティビティの理解と表示
■
リアルタイム適用の使用可能化
■
適用された REDO データ量の判別
■
エラーのリカバリ
■
マテリアライズド・ビューのリフレッシュ
注意 : DBMS_LOGSTDBY パッケージへのアクセスが必要なユーザーには、
LOGSTDBY_ADMINISTRATOR ロールを付与する必要があります。
9-2　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの構成と管理
SQL Apply の管理
DBMS_LOGSTDBY PL/SQL パッケージには、ロジカル・スタンバイ・データベースでの SQL
Apply の管理に役立つプロシージャが含まれています。このパッケージを使用すると、次の
ことができます。
■
スタンバイ・データベース内の選択した表またはスキーマ全体へのアーカイブ REDO ロ
グ・ファイルまたはスタンバイ REDO ログ・ファイルの適用をスキップする方法を提
供する
■
SQL Apply で使用される初期化パラメータを管理する
■
サプリメンタル・ロギングが正しく使用できることを保証する
■
ロジカル・スタンバイ・データベースには適用の必要がない一連の操作を説明する
■
DML または DDL の変更を一時表に適用しない
■
CREATE、ALTER または DROP INDEX の各操作を適用しない
■
■
DDL 文の適用時にエラーが発生したときは、そのエラーを記録し、ロジカル・スタンバ
イ・データベースへのアーカイブ REDO ログ・ファイルまたはスタンバイ REDO ロ
グ・ファイルの適用を継続する
エラーが DDL 文で発生したときは、SQL Apply を停止し、DBA による処置の指定を待
機する
表 9-1 に、PL/SQL パッケージ DBMS_LOGSTDBY のプロシージャをまとめます。
表 9-1 PL/SQL パッケージ DBMS_LOGSTDBY のプロシージャ
サブプログラム
説明
APPLY_SET
特定の初期化パラメータの値を設定して、SQL Apply の構成お
よびメンテナンスを可能にする。
APPLY_UNSET
特定の初期化パラメータの値をシステムのデフォルト値にリ
セットする。
BUILD
サプリメンタル・ロギングが正しく使用できることを保証し、
LogMiner ディクショナリを作成する。
INSTANTIATE_TABLE
プライマリ・データベース内の対応する表から、スタンバイ・
データベースに表を作成して移入する。
SKIP
プライマリ・データベースで完了したデータベース操作の中
で、ロジカル・スタンバイ・データベースに適用しない操作を
指定できる。
SKIP_ERROR
エラーが発生した場合に従う条件を指定する。SQL Apply を停
止するか、またはエラーを無視できる。
ロジカル・スタンバイ・データベースの管理
9-3
ロジカル・スタンバイ・データベースの構成と管理
表 9-1 PL/SQL パッケージ DBMS_LOGSTDBY のプロシージャ（続き）
サブプログラム
説明
SKIP_TRANSACTION
特定のトランザクションをロジカル・スタンバイ・データベー
スに適用するときにスキップ（無視）するトランザクション識
別情報を指定する。このサブプログラムでは、代替文も実行で
きる。
UNSKIP
SKIP プロシージャで設定したオプションを変更する。
UNSKIP_ERROR
SKIP_ERROR プロシージャで設定したオプションを変更する。
UNSKIP_TRANSACTION
SKIP_TRANSACTION プロシージャで設定したオプションを変
更する。
DBMS_LOGSTDBY パッケージの詳細は、
『PL/SQL パッケージ・プロシージャおよびタイプ・
リファレンス』を参照してください。
ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセス
の制御
ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスは、SQL 文
ALTER DATABASE GUARD によって制御されます。ロジカル・スタンバイ・データベースで
は、データベース・ガードはデフォルトで ALL に設定されます。
ALTER DATABASE GUARD 文で使用できるキーワードは、次のとおりです。
■
ALL
ALL を指定すると、SYS 以外のすべてのユーザーがロジカル・スタンバイ・データベー
ス内のデータを変更できないように保護されます。
■
STANDBY
STANDBY を指定すると、SYS 以外のすべてのユーザーが、SQL Apply を介してメンテ
ナンスされている表または順序を DML および DDL によって変更できないように保護
されます。
■
NONE
データベース内の全データに対して通常のセキュリティが必要な場合は、NONE を指定
します。
たとえば、次の文を使用して、SQL Apply でメンテナンスされない表をユーザーが修正でき
るようにします。
SQL> ALTER DATABASE GUARD STANDBY;
権限を付与されているユーザーは、ALTER SESSION DISABLE GUARD 文および ALTER
SESSION ENABLE GUARD 文をそれぞれ使用して、現行のセッションでデータベース・ガー
9-4　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの構成と管理
ドを一時的にオフおよびオンにできます。Oracle9i で同じ機能を実行していた DBMS_
LOGSTDBY.GUARD_BYPASS PL/SQL プロシージャは、この文により置き換えられています。
ALTER SESSION [ENABLE|DISABLE] GUARD 文は、
「ロジカル・スタンバイ・データベー
スの変更」で説明されているように、データベースを変更するためにデータベース・ガード
を一時的に無効にする場合に役立ちます。
注意 : データベース・ガードが無効になっている間に、プライマリ・
データベースとロジカル・スタンバイ・データベースの内容にずれが生じ
ないように注意してください。
SQL Apply で不要になったアーカイブ REDO ログ・ファイルの削除
SQL Apply で不要になったアーカイブ REDO ログ・ファイルを定期的に削除して、ディス
ク領域を再度使用可能にする必要があります。次の手順を実行して、ファイル・システムか
らアーカイブ 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 ログ・ファイルを削除します。
ロジカル・スタンバイ・データベースの管理
9-5
ロジカル・スタンバイ・データベースの構成と管理
ロジカル・スタンバイ・データベースの変更
データベース・ガードを無視して、ロジカル・スタンバイ・データベースを変更可能にする
には、ALTER SESSION DISABLE GUARD 文を実行します。権限を付与されているユー
ザーは、この文を発行して、現行のセッションでデータベース・ガードをオフにできます。
次の各項で、例を示します。これらの例では、データベース・ガードが ALL または
STANDBY に設定されていると仮定しています。
ロジカル・スタンバイ・データベースでの DDL の実行
この項では、SQL Apply を介してメンテナンスされている表に索引を追加する方法を説明し
ます。
デフォルトでは、SYS 権限を持つアカウントのみがデータベースを変更でき、データベー
ス・ガードは ALL または STANDBY に設定されています。SYSTEM または権限を付与されて
いる別のアカウントでログインした場合、最初はセッションに対するデータベース・ガード
をバイパスしていないので、ロジカル・スタンバイ・データベースでは DDL 文を発行でき
ません。
次の例は、SQL Apply を停止し、データベース・ガードをバイパスしてロジカル・スタンバ
イ・データベースで SQL 文を実行した後、データベース・ガードを再び使用可能にする方
法を示しています。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.
SQL> ALTER SESSION DISABLE GUARD;
PL/SQL procedure successfully completed.
SQL> ALTER TABLE SCOTT.EMP ADD CONSTRAINT EMPID UNIQUE (EMPNO);
Table altered.
SQL> ALTER SESSION ENABLE GUARD;
PL/SQL procedure successfully completed.
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
Database altered.
このサンプル・プロシージャは、その他の DDL 文の実行にも使用できます。オラクル社で
は、データベース・ガードのバイパスが使用可能になっている間は DML 操作を実行しない
ことをお薦めします。DML 操作を実行すると、プライマリ・データベースとスタンバイ・
データベース間で違いが生じ、ロジカル・スタンバイ・データベースをメンテナンスできな
いようになります。多くの場合、ロジカル・スタンバイ・データベースで行が段階的にメン
テナンスされるのと同じ方法で、表の行を変更することはできません。
9-6　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの構成と管理
SQL Apply でメンテナンスされていない表の変更
場合によっては、レポート生成アプリケーションが、要約した結果を収集してその結果を一
時的に格納したり、レポートが実行された回数を追跡する必要があります。アプリケーショ
ンの主な目的はレポート・アクティビティを実行することですが、ロジカル・スタンバイ・
データベースに対して DML（挿入、更新および削除）操作の発行が必要な場合があります。
さらに、アプリケーションで表の作成や削除が必要になることもあります。
データが SQL Apply を介してメンテナンスされていない場合は、レポート生成操作でデー
タを変更できるように、データベース・ガードを設定できます。次の設定を行う必要があり
ます。
■
■
DBMS_LOGSTDBY.SKIP プロシージャを実行して、アプリケーションによるデータの書
込みを可能にする、ロジカル・スタンバイ・データベース上の表のセットを指定しま
す。スキップされた表は、SQL Apply でメンテナンスされません。
スタンバイ表のみを保護するようにデータベース・ガードを設定します。
次の例では、レポートによって書込みが行われる表がプライマリ・データベース上にあると
仮定しています。
この例では、変更をロジカル・スタンバイ・データベースに適用できるように、SQL Apply
を停止し、表をスキップした後、SQL Apply を再開しています。この操作によって、レポー
ト生成アプリケーションは、MYSCHEMA の MYTABLES% に書込みができるようになります。
スキップされた表は、SQL Apply でメンテナンスされません。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.
SQL> EXECUTE DBMS_LOGSTDBY.SKIP('SCHEMA_DDL','MYSCHEMA','MYTABLES%');
PL/SQL procedure successfully completed.
SQL> EXECUTE DBMS_LOGSTDBY.SKIP('DML','MYSCHEMA','MYTABLES%');
PL/SQL procedure successfully completed.
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
Database altered.
次に、DBA_LOGSTDBY_PARAMETERS ビューを問い合せ、ロジカル・スタンバイ・データ
ベースが更新されることを確認します。次の例のように、列が戻らなくなるまで問合せを繰
り返す必要があるため、確認に時間がかかることがあります。
SQL> SELECT VALUE FROM DBA_LOGSTDBY_PARAMETERS WHERE NAME = 'GUARD_STANDBY';
VALUE
--------Ready
ロジカル・スタンバイ・データベースの管理
9-7
ロジカル・スタンバイ・データベースの構成と管理
最後に、表を更新できるようにデータベース・ガードを設定します。
SQL> ALTER DATABASE GUARD STANDBY;
Database altered.
ロジカル・スタンバイ・データベースでのトリガーと制約の処理方法
ロジカル・スタンバイ・データベースでトリガーおよび制約を使用可能にするか処理するた
めに、いかなる処置も行う必要はありません。スタンバイ・データベースの場合、トリガー
と制約は使用可能ですが実行されません。トリガーおよび制約がロジカル・スタンバイ・
データベースでどのように処理されるかを、次に説明します。
SQL Apply でメンテナンスされる表にトリガーおよび制約がある場合 :
■
■
制約 : CHECK 制約はプライマリ・データベースで評価されます。ロジカル・スタンバ
イ・データベースでの再評価は不要です。
トリガー : プライマリ・データベースで実行されたトリガーの影響は、スタンバイ・
データベースでログに記録され、適用されます。
SQL Apply でメンテナンスされない表にトリガーおよび制約がある場合 :
■
制約は評価されます。
■
トリガーは発行されます。
ロジカル・スタンバイ・データベースでの SQL 文のスキップ
スタンバイ・データベース上で関連しているものが、プライマリ・データベース上にあるア
クティビティのサブセットのみの場合は、DBMS_LOGSTDBY.SKIP プロシージャを使用し
て、SQL Apply がロジカル・スタンバイ・データベースで SQL 文を発行しないように保護
するフィルタを定義します。
（自動的にスキップされる SQL 文の詳細は、4-4 ページの「ロ
ジカル・スタンバイ・データベースでスキップされる SQL 文」を参照してください）。
サポートされないデータ型または文がフィルタ処理で自動的に除外された後、表での SQL
文の適用が続行されます。ただし、ロジカル・スタンバイ・データベースに適用しない表を
スキップするには、DBMS_LOGSTDBY.SKIP プロシージャを使用する必要があります。次の
リストは、ロジカル・スタンバイ・データベースに適用されないようにフィルタ処理または
スキップできる一般的な SQL 文の例を示しています。
■
表に対する DML または DDL 変更
■
CREATE、ALTER または DROP INDEX DDL 文
■
CREATE、ALTER、DROP または TRUNCATE TABLE 文
■
CREATE、ALTER または DROP TABLESPACE 文
■
CREATE または DROP VIEW 文
9-8　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの構成と管理
例 9-1 は、ロジカル・スタンバイ・データベース内の EMP 表を参照する SQL 文をすべてス
キップする方法を示しています。
例 9-1 ロジカル・スタンバイ・データベース内の表のスキップ
SQL>
SQL>
SQL>
SQL>
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
EXECUTE DBMS_LOGSTDBY.SKIP('SCHEMA_DDL', 'SCOTT', 'EMP', NULL);
EXECUTE DBMS_LOGSTDBY.SKIP('DML', 'SCOTT', 'EMP', NULL);
ALTER DATABASE START LOGICAL STANDBY APPLY;
スキーマおよび非スキーマ操作のために DML 文と DDL 文をスキップすることに加え、特
定の DML 操作と DDL 操作もスキップできます。例 9-2 は、非スキーマの DDL 操作のため
に ALTER TABLESPACE および CREATE TABLESPACE をスキップする方法も示しています。
例 9-2 ALTER または CREATE TABLESPACE 文のスキップ
SQL> EXEC DBMS_LOGSTDBY.SKIP('CREATE TABLESPACE', NULL, NULL, NULL);
SQL> EXEC DBMS_LOGSTDBY.SKIP('ALTER TABLESPACE', NULL, NULL, NULL);
SQL>
SQL>
SQL>
SQL>
SQL>
SQL>
ERROR
----N
N
COLUMN
COLUMN
COLUMN
COLUMN
COLUMN
SELECT
ERROR FORMAT a5;
STATEMENT_OPT FORMAT a20;
OWNER FORMAT a10
NAME FORMAT a15;
PROC FORMAT a20;
* FROM DBA_LOGSTDBY_SKIP;
STATEMENT_OPT
OWNER
NAME
PROC
----------------- ---------- --------------- -------------------CREATE TABLESPACE
ALTER TABLESPACE
ロジカル・スタンバイ・データベースの管理
9-9
ロジカル・スタンバイ・データベースの構成と管理
ロジカル・スタンバイ・データベースでの表の追加または再作成
通常、リカバリ不能な操作の後に表を再作成するには、表のインスタンス化を使用します。
また、プロシージャを使用して、以前はスキップしていた表に対する SQL Apply を使用可
能にすることもできます。
表を作成する前に、4-6 ページの「プライマリ・データベース内の表の行が一意に識別でき
ることの確認」および 4-9 ページの「サプリメンタル・ロギングが使用可能であることの確
認」に記載されている要件を満たす必要があります。これらの項では、次の方法が説明され
ています。
■
■
プライマリ・データベース内の表の行が一意に識別できることを確認する方法
ロジカル・スタンバイ・データベースでサポートされないデータ型や表がプライマリ・
データベースに含まれているかどうかを判断する方法
次のリストおよび例 9-3 は、表を再作成し、その表に対して SQL Apply を再開する方法を示
しています。
1.
SQL Apply を停止します。
2.
DBA_LOGSTDBY_SKIP ビューを問い合せて、その表で操作がスキップされていないこ
とを確認します。
その表で操作がスキップされている場合は、DBMS_LOGSTDBY.UNSKIP プロシージャを
使用して、現在スキップされている各操作の適用を再開します。表に対して複数のフィ
ルタが作成されている場合は、プロシージャを複数回実行する必要があります。
3.
DBMS_LOGSTDBY.INSTANTIATE_TABLE プロシージャを使用して、ロジカル・スタン
バイ・データベースに表を再作成します。表の作成の他に、データベース・リンクを使
用してプライマリ表からのデータのインポートも実行されます。
4.
SQL Apply を再開します。
新しく追加した表のデータにアクセスする前に、プライマリ・データベースのカレント・オ
ンライン REDO ログ・ファイルをアーカイブし、そのアーカイブ REDO ログ・ファイルが
ロジカル・スタンバイ・データベースに適用されていることを確認する必要があります。
例 9-3 は、EMP 表をロジカル・スタンバイ・データベースに追加する方法を示しています。
9-10　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの構成と管理
例 9-3 ロジカル・スタンバイ・データベースへの表の追加
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> SELECT * FROM DBA_LOGSTDBY_SKIP;
ERROR STATEMENT_OPT
OWNER
NAME
PROC
--------------------------------------------------------------------N
SCHEMA_DDL
SCOTT
EMP
N
DML
SCOTT
EMP
SQL>
SQL>
SQL>
SQL>
EXECUTE DBMS_LOGSTDBY.UNSKIP('DML','SCOTT','EMP');
EXECUTE DBMS_LOGSTDBY.UNSKIP('SCHEMA_DDL','SCOTT','EMP');
EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE('SCOTT','EMP','DBLINK');
ALTER DATABASE START LOGICAL STANDBY APPLY;
プライマリ・データベースにログオンし、次の文を発行します。
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
SQL> SELECT FIRST_CHANGE# FROM V$LOG WHERE STATUS = 'CURRENT';
DBA_LOGSTDBY_PROGRESS.APPLIED_SCN プロシージャで戻された値が、(FIRST_
CHANGE# - 1) と等しいかまたは V$LOG ビューの問合せで選択された値よりも少ない場
合、そのデータベースには一貫性があるため、レポートは安全に再実行できます。
ロジカル・スタンバイ・イベントの表示と制御
DBA_LOGSTDBY_EVENTS ビューを問い合せると、SQL Apply のアクティビティが記録され
たイベント表が表示されます。このイベント表には、特に、DDL の実行やエラーの原因と
なった実行が記録されています。イベント表に記録するアクティビティの内容と量は、制御
できます。デフォルトでは、この表に格納できるレコード数は 100 件ですが、レコード数は
増加できます。次に例を示します。
SQL> DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED', 200);
さらに、記録するイベントのタイプを設定できます。デフォルトでは、すべてのタイプが表
に記録されます。ただし、RECORD_SKIP_DDL、RECORD_SKIP_ERRORS および RECORD_
APPLIED_DDL の各パラメータを FALSE に設定して、これらのイベントの記録を回避でき
ます。
SQL Apply の停止原因となったエラーは、システム表領域に十分な領域があるかぎり、必ず
イベント表に記録されます。これらのイベントは、常に ALERT.LOG ファイルにも格納さ
れ、テキストには、'LOGSTDBY' というキーワードが含まれます。このビューを問い合せた
ときは、EVENT_TIME、COMMIT_SCN、CURRENT_SCN の順で列を選択してください。この
順序によって、停止障害がビューの最後に表示されます。
ロジカル・スタンバイ・データベースの管理
9-11
ロジカル・スタンバイ・データベースの構成と管理
SQL Apply アクティビティの理解と表示
SQL Apply では、プライマリ・データベースの変更をロジカル・スタンバイ・データベース
に適用するパラレル実行サーバーとバックグラウンド・プロセスの集合が使用されます。図
9-1 に、情報の流れと各プロセスで実行されるロールを示します。
図 9-1 SQL Apply の処理
図 9-1 では、次のようになっています。
■
■
■
■
READER プロセスでは、REDO レコードがアーカイブ REDO ログ・ファイルから読み込
まれます。
PREPARER プロセスでは、ブロックの変更を表の変更または論理変更レコード（LCR）
に変換するための重要な計算が行われます。この時点では、LCR は特定のトランザク
ションを表しません。
BUILDER プロセスでは、個々の LCR からの完了したトランザクションのアセンブルが
行われます。
ANALYZER プロセスでは、レコードが検査され、通常は、トランザクションが排除さ
れ、異なるトランザクション間の依存性が識別されます。
9-12　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの構成と管理
■
■
COORDINATOR プロセス（LSP）では、次の操作が実行されます。
–
トランザクションの割当て
–
トランザクション間の依存性の監視と、スケジュールの調整
–
ロジカル・スタンバイ・データベースに対する変更のコミットの認可
APPLIER プロセスでは、次の操作が実行されます。
–
データベースに対する LCR の適用
–
COORDINATOR プロセスに対する、依存性が解決されていないトランザクションの
承認の要求
–
トランザクションのコミット
V$LOGSTDBY ビューを問い合せ、各プロセスで現在実行されている内容を表示できます。
TYPE 列には、実行中のタスクに関する説明が表示されます。V$LOGSTDBY ビューを問い合
せたときは、特に HIGH_SCN 列に注意してください。この列は、アクティビティのインジ
ケータです。V$LOGSTDBY ビューを問い合せるたびに、この列の内容が変化している間は、
作業が進行しています。STATUS 列には、現行のアクティビティの説明テキストが表示され
ます。次に例を示します。
SQL> COLUMN NAME FORMAT A30
SQL> COLUMN VALUE FORMAT A30
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'coordinator state';
NAME
VALUE
------------------------------ -----------------------------coordinator state
APPLYING
SQL> COLUMN STATUS FORMAT A50
SQL> COLUMN TYPE FORMAT A12
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE
HIGH_SCN STATUS
------------ ---------- -------------------------------------------------COORDINATOR
ORA-16117: 処理中です。
READER
ORA-16127: 追加のトランザクションが適用されるまで待機して
停止しました。
BUILDER
191896 ORA-16116: 使用できる作業はありません
PREPARER
191902 ORA-16117: 処理中です。
ANALYZER
191820 ORA-16120: SCN 0x0000.0002ed4e でのトランザクションに
対する依存性を計算中です。
APPLIER
.
.
191209 ORA-16124: トランザクション 1 16 1598 は待機中です。
ロジカル・スタンバイ・データベースの管理
9-13
ロジカル・スタンバイ・データベースの構成と管理
現行のアクティビティに関する情報を取得するもう 1 つの場所は V$LOGSTDBY_STATS
ビューです。このビューには、状態とステータスに関する情報が表示されます。DBMS_
LOGSTDBY.APPLY_SET プロシージャに関するすべてのオプションにはデフォルト値があり
ます。これらの値（デフォルトまたは設定済み）は、V$LOGSTDBY_STATS ビューで参照で
きます。さらに、適用されたトランザクションや準備が完了したトランザクションの件数に
よって、トランザクションが読込みと同時に適用されているかどうかを知ることができま
す。他の統計値には、システムのすべての部分に関する情報が含まれています。次に例を示
します。
SQL>
SQL>
SQL>
2>
COLUMN NAME FORMAT A35
COLUMN VALUE FORMAT A35
SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME LIKE 'coordinator%' or NAME LIKE 'transactions%';
NAME
----------------------------------coordinator state
transactions ready
transactions applied
coordinator uptime
VALUE
----------------------------------APPLYING
7821
7802
73
この問合せでは、SQL Apply の実行時間とその間に適用されたトランザクションの数が表示
されます。また、適用可能なトランザクションの数も表示されます。
リアルタイム適用の使用可能化
デフォルトでは、Data Guard はいっぱいになったアーカイブ REDO ログ・ファイルがスタ
ンバイ・データベースで受信されるのを待機してから、スタンバイ・データベースにリカバ
リします。ただし、スタンバイ REDO ログをスタンバイ・データベースで構成している場
合、オプションでリアルタイム適用を使用可能にできます。リアルタイム適用により、スタ
ンバイ REDO ログ・ファイルがリモート・ファイル・サーバー（RFS）プロセスによって
いっぱいになったときに、スタンバイ REDO ログ・ファイルから REDO データをリカバリ
できます。リアルタイム適用を使用可能にすると、SQL Apply では、ログ・ファイルが書き
込まれるのと同時にスタンバイ REDO ログ・ファイルから REDO データがリカバリされま
す。これは、ログ・スイッチが発生する場合とは逆になります。このような方法でスタンバ
イ REDO ログ・ファイルを即時に適用することにより、スタンバイ REDO ログ・ファイル
をスタンバイ・サイトでアーカイブする必要なしに、ロジカル・スタンバイ・データベース
の内容をプライマリ・データベースの内容とかぎりなく一致させることができます。この結
果、スイッチオーバーとフェイルオーバーをより迅速に実行できます。
ロジカル・スタンバイ・データベースでリアルタイム適用を開始するには、次の文を発行し
ます。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
9-14　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの構成と管理
適用された REDO データ量の判別
REDO ストリームのトランザクション・データは、複数の REDO ログ・ファイルを使用す
る場合があります。このため、ロジカル・スタンバイ・データベースでは、SQL Apply の進
捗をレポートするために、個々のアーカイブ REDO ログ・ファイルではなく、REDO デー
タの SCN 範囲が使用されます。
DBA_LOGSTDBY_PROGRESS ビューには、APPLIED_SCN、NEWEST_SCN および READ_SCN
に関する情報が表示されます。APPLIED_SCN は、その SCN 以下のコミット済トランザク
ションが適用されたことを示します。NEWEST_SCN は、追加の REDO データを受信しない
場合にデータを適用できる最大 SCN です。この値は通常、リスト内にギャップがない場合、
DBA_LOGSTDBY_LOG の MAX(NEXT_CHANGE#)-1 です。
READ_SCN 値未満の NEXT_CHANGE# 値を持つアーカイブ REDO ログ・ファイルは不要にな
りました。これらのログ・ファイルの情報は、すでに適用されたか、あるいはデータベース
に永続的に格納された情報です。これらの SCN の値に関連付けられた時間の値は、ログ時
間に基づいた単なる推測値です。これらの値は、SCN の値がプライマリ・データベースに書
き込まれた正確な時間を示していません。
適用済または未適用のアーカイブ REDO ログ・ファイルを確認するには、次の問合せを発
行します。
SQL> ALTER SESSION SET NLS_DATE_FORMAT
Session altered.
= 'DD-MON-YY HH24:MI:SS';
SQL> SELECT SEQUENCE#, FIRST_TIME, APPLIED
2 FROM DBA_LOGSTDBY_LOG
3 ORDER BY SEQUENCE#;
SEQUENCE#
---------24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
FIRST_TIME
-----------------23-JUL-02 18:19:05
23-JUL-02 18:19:48
23-JUL-02 18:19:51
23-JUL-02 18:19:54
23-JUL-02 18:19:59
23-JUL-02 18:20:03
23-JUL-02 18:20:13
23-JUL-02 18:20:18
23-JUL-02 18:20:21
23-JUL-02 18:32:11
23-JUL-02 18:32:19
23-JUL-02 19:13:20
23-JUL-02 19:13:43
23-JUL-02 19:13:46
23-JUL-02 19:13:50
23-JUL-02 19:13:54
23-JUL-02 19:14:01
APPLIED
------YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
CURRENT
CURRENT
CURRENT
CURRENT
CURRENT
CURRENT
CURRENT
ロジカル・スタンバイ・データベースの管理
9-15
ロジカル・スタンバイ・データベースの構成と管理
41 23-JUL-02 19:15:11 NO
42 23-JUL-02 19:15:54 NO
19 rows selected.
エラーのリカバリ
ロジカル・スタンバイ・データベースでは、ユーザー表、順序およびジョブがメンテナンス
されます。他のオブジェクトをメンテナンスするには、REDO データ・ストリームにある
DDL 文を再発行する必要があリます。SYS スキーマ内の表がメンテナンスされることはあ
りません。これは、この SYS スキーマでメンテナンスされるのは、Oracle のメタデータの
みであるためです。
SQL Apply に障害が発生した場合、エラーは DBA_LOGSTDBY_EVENTS 表に記録されます。
次の各項では、このようなエラーのリカバリ方法を説明します。
ファイル仕様が含まれている DDL トランザクション
DDL 文は、プライマリ・データベースとロジカル・スタンバイ・データベースでは同じ方
法で実行されます。基礎となるファイル構造が両方のデータベースで同じ場合、DDL はス
タンバイ・データベース上で予想どおりに実行されます。ただし、スタンバイ・システムの
ファイル・システム構造がプライマリ・システムのファイル・システム構造と異なる場合、
DB_FILE_NAME_CONVERT では、プライマリ・データベース上の 1 つ以上のセットのデー
タ・ファイルのファイル名が、ロジカル・スタンバイ・データベース用のスタンバイ・デー
タベース上のファイル名に変換されないため、エラーが発生する可能性があります。
エラーの原因が、ロジカル・スタンバイ・データベース環境に適合しないファイル仕様を含
んだ DDL トランザクションにある場合は、次の手順を実行して問題を解決してください。
1.
ALTER SESSION DISABLE GUARD 文を使用してデータベース・ガードをバイパスし、
ロジカル・スタンバイ・データベースへの変更を可能にします。
SQL> ALTER SESSION DISABLE GUARD;
2.
正しいファイル仕様を使用して DDL 文を実行し、データベース・ガードを再び使用可
能にします。次に例を示します。
SQL> ALTER TABLESPACE t_table ADD DATAFILE 'dbs/t_db.f' SIZE 100M REUSE;
SQL> ALTER SESSION ENABLE GUARD;
3.
ロジカル・スタンバイ・データベースで SQL Apply を開始し、障害が発生したトラン
ザクションをスキップします。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY
2> SKIP FAILED TRANSACTION;
9-16　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの構成と管理
トランザクション障害の原因となった問題を修正し、トランザクションをスキップせずに
SQL Apply を再開できる場合があります。たとえば、使用可能領域がすべて使用された場合
などです （トランザクションをスキップするときに、プライマリおよびロジカル・スタンバ
イ・データベースの内容にずれを生じさせないようにしてください。可能な場合は、スキッ
プされたトランザクションのかわりに補足用トランザクションを手動で実行する必要があり
ます）
。
次の例に、SQL Apply の停止、エラーの修正および SQL Apply の再開を示します。
SQL> SET LONG 1000
SQL> ALTER SESSION SET NLS_DATE_FORMAT
= 'DD-MON-YY HH24:MI:SS';
Session altered.
SQL> SELECT EVENT_TIME, COMMIT_SCN, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS;
EVENT_TIME
COMMIT_SCN
------------------ --------------EVENT
------------------------------------------------------------------------------STATUS
------------------------------------------------------------------------------22-OCT-03 15:47:58
ORA-16111: ログのマイニングと設定の適用
22-OCT-03 15:48:04
209627
insert into "SCOTT"."EMP"
values
"EMPNO" = 7900,
"ENAME" = 'ADAMS',
"JOB" = 'CLERK',
"MGR" IS NULL,
"HIREDATE" = TO_DATE('22-OCT-03', 'DD-MON-RR'),
"SAL" = 950,
"COMM" IS NULL,
"DEPTNO" IS NULL
ORA-01653: 表 SCOTT.EMP を拡張できません（%d 分、表領域 %s）
この例で、ORA-01653 メッセージは、表領域がいっぱいで表を拡張できないことを示して
います。問題を修正するには、新しいデータ・ファイルを表領域に追加します。次に例を示
します。
SQL> ALTER TABLESPACE t_table ADD DATAFILE 'dbs/t_db.f' SIZE 60M;
Tablespace altered.
ロジカル・スタンバイ・データベースの管理
9-17
ロジカル・スタンバイ・データベースの構成と管理
次に、SQL Apply を再開します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
Database altered.
SQL Apply を再開すると、障害が発生したトランザクションが再実行され、ロジカル・スタ
ンバイ・データベースに適用されます。
DML 障害のリカバリ
DML 障害のフィルタ処理には、SKIP_TRANSACTION プロシージャを使用しないでくださ
い。また、スキップされたイベント表にある DML のみでなく、トランザクションに関連し
ているすべての DML についても注意が必要です。このような処理によって、複数の表が破
損する場合があります。
DML 障害は通常、特定の表に関する問題を示しています。たとえば、障害が即時に解決で
きない記憶域の不足に関するエラーであるとします。次の手順は、この問題に応答する 1 つ
の方法を示しています。
1.
表をスキップ・リストに追加することによって、トランザクションではなく、表をバイ
パスします。
SQL> EXECUTE DBMS_LOGSTDBY.SKIP('DML','SCOTT','EMP');
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
この時点から、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;
3.
SCOTT.EMP 表には、INSTANTIATE_TABLE プロシージャ実行時のレコードが格納され
る（手順 2）ため、SCOTT.DEPT 表にはない部門に関するレコードが格納される可能性
があります。
9-18　Oracle Data Guard 概要および管理
Oracle Database ソフトウェア・バージョンのアップグレード
マテリアライズド・ビューのリフレッシュ
プライマリ・データベースでリフレッシュされたマテリアライズド・ビューが、ロジカル・
スタンバイ・データベースでそれぞれ自動的にリフレッシュされることはありません。ロジ
カル・スタンバイ・データベース上のマテリアライズド・ビューをリフレッシュするには、
ALTER SESSION DISABLE GUARD 文および ENABLE GUARD 文を使用します。次に例を示
します。
SQL> ALTER SESSION DISABLE GUARD;
SQL> EXECUTE DBMS_MVIEW.REFRESH ( 'BMVIEW', 'F', '',TRUE,FALSE,0,0,0,FALSE);
SQL> ALTER SESSION ENABLE GUARD;
DBMS_LOGSTDBY パッケージの詳細は、
『PL/SQL パッケージ・プロシージャおよびタイプ・
リファレンス』を参照してください。
DBMS_LOGSTDBY.APPLY_SET プロシージャを使用し、TRANSACTION_CONSISTENCY パラ
メータに FULL オプション（デフォルト）を使用していない場合は、ロジカル・スタンバ
イ・データベース上のマテリアライズド・ビューをリフレッシュする前に、SQL Apply を停
止してください。
Oracle Database ソフトウェア・バージョンのアップグレード
ロジカル・スタンバイ・データベースを使用して、ほとんど停止時間なしで Oracle
Database ソフトウェアとパッチセットをアップグレードできます。この項では、アップグ
レード処理の概要について説明します。データベース・アップグレードの詳細は、該当する
Oracle Database 10g パッチセット・リリースの README ファイルを参照してください。
注意 : アプリケーションのデータ型の関係でロジカル・スタンバイ・
データベースを使用できない場合は、
『Oracle Database アップグレード・
ガイド』の説明に従ってアップグレードを実行してください。
図 9-2 に、アップグレード開始前の Data Guard 構成を示します。この例では、プライマリ・
データベースとロジカル・スタンバイ・データベースでは、同じバージョンの Oracle ソフ
トウェアが実行されています。
ロジカル・スタンバイ・データベースの管理
9-19
Oracle Database ソフトウェア・バージョンのアップグレード
図 9-2 アップグレード前の Data Guard 構成
アップグレード処理中に、次の操作が実行されます。
■
■
Data Guard 構成は、アップグレードを検証できるように何度か混合データベース・
バージョンで動作します。この項で示す手順は、データ消失なしでソフトウェアのアッ
プグレードとダウングレードを終了できる場合を示しています。
これらの手順では、追加のデータ保護を提供するために Data Guard 構成に第 2 のスタン
バイ・データベースがある場合を考えます。
手順 1 SQL Apply を停止してロジカル・スタンバイ・データベースをアップグレードする
アップグレードを開始するには、SQL Apply を停止して、ロジカル・スタンバイ・データ
ベースの Oracle Database ソフトウェアをバージョン n+1 にアップグレードします。
Oracle Database ソフトウェア・バージョンのアップグレードの詳細は、該当する Oracle
Database 10g パッチセット・リリースの README ファイルを参照してください。
図 9-3 に、バージョン n を実行中のプライマリ・データベースと、バージョン n+1 を実行中
のロジカル・スタンバイ・データベースを示します。アップグレード中は、REDO データが
プライマリ・システムに蓄積されます。
9-20　Oracle Data Guard 概要および管理
Oracle Database ソフトウェア・バージョンのアップグレード
図 9-3 ロジカル・スタンバイ・データベースのバージョンのアップグレード
手順 2 SQL Apply を再開する
SQL Apply を再開し、プライマリ・データベースではバージョン n、スタンバイ・データ
ベースではバージョン n+1 で動作させます。Data Guard 構成では、アップグレード後の
Oracle ソフトウェア・バージョンが本番環境で正常に実行されるかどうかを確認するため
に、任意の期間だけ図 9-4 に示す混合バージョンを実行できます。
プライマリ・システムに蓄積された REDO データは、新しくアップグレードしたロジカル・
スタンバイ・データベースに自動的に転送され、適用されます。
ロジカル・スタンバイ・データベースの管理
9-21
Oracle Database ソフトウェア・バージョンのアップグレード
図 9-4 混合バージョンの実行
手順 3 スイッチオーバーを実行する
アップグレードのソフトウェアが正常に動作していることを確認した後、スイッチオーバー
を実行してデータベースのロールを逆転できます（7-20 ページの「ロジカル・スタンバイ・
データベースが関与するスイッチオーバー」を参照）
。この操作には数秒しかかかりません。
新規プライマリ・データベースでユーザー・アプリケーションとサービスをアクティブ化し
ます。アプリケーションのサービス・レベルがなんらかの原因で低下した場合は、以前のプ
ライマリ・データベースを再びオープンし、ユーザーを切り替えて前の手順を終了できま
す。
スイッチオーバー後は、新規データベース・ソフトウェア・バージョンを実行中の新規プラ
イマリ・データベース（B）から、旧ソフトウェア・バージョンを実行中の新規スタンバ
イ・データベース（A）には、REDO データを送信できません。これは、次のことを意味し
ます。
■
REDO データは、新規プライマリ・データベースに蓄積されます。
■
新規プライマリ・データベースは、この時点では保護されていません。
図 9-5 に、前のスタンバイ・データベース（バージョン n+1）がプライマリ・データベース
になり、前のプライマリ・データベース（バージョン n）がスタンバイ・データベースに
なっている状態を示します。ユーザーは新規プライマリ・データベースに接続されます。
9-22　Oracle Data Guard 概要および管理
Oracle Database ソフトウェア・バージョンのアップグレード
図 9-5 スイッチオーバー後
手順 4 新規ロジカル・スタンバイ・データベースをアップグレードする
新規ロジカル・スタンバイ・データベースをアップグレードします。
Oracle Database ソフトウェア・バージョンのアップグレードの詳細は、該当する Oracle
Database 10g パッチセット・リリースの README ファイルを参照してください。図 9-6 に、
両方のデータベースがバージョン n+1 にアップグレードされた後のシステムを示します。
図 9-6 両方のデータベースがアップグレードされた後
ロジカル・スタンバイ・データベースの管理
9-23
OPEN RESETLOGS 文を使用したリカバリ
手順 5 SQL Apply を開始する
SQL Apply を開始すると、プライマリ・データベースに蓄積された REDO がロジカル・ス
タンバイ・データベースに送信されます。REDO データがスタンバイ・データベースで使用
可能になると、プライマリ・データベースはデータ消失から保護されます。
手順 6 両方のデータベースの互換性レベルを上げる
COMPATIBLE 初期化パラメータを設定して、両方のデータベースの互換性レベルを上げま
す。COMPATIBLE パラメータは、スタンバイ・データベースで設定してからプライマリ・
データベースで設定します。COMPATIBLE 初期化パラメータの詳細は、第 11 章を参照して
ください。
手順 7 必要な場合は、再度スイッチオーバーを実行する
必要な場合は、元のプライマリ・データベースが本番データベース・ロールで実行されるよ
うに（図 9-2 を参照）、データベースのスイッチオーバーを再度実行します。
OPEN RESETLOGS 文を使用したリカバリ
Data Guard では、RESETLOGS オプションを使用してプライマリ・データベースがオープン
された後も、ロジカル・スタンバイ・データベースでリカバリを続行できます。プライマ
リ・データベースで ALTER DATABASE OPEN RESETLOGS 文を発行すると、データベース
のインカネーションが変更され、REDO データの新規ブランチが作成されます。
ロジカル・スタンバイ・データベースが REDO データの新規ブランチを受信すると、SQL
Apply が停止し、スタンバイ・データベースでのロジカル・スタンバイ・プロセス（LSP）
が終了します。ロジカル・スタンバイ・データベースの場合、スタンバイ・データベースに
より新規リセットログの SCN より後（REDO データの新規ブランチの開始より後）の
REDO データが適用されていなければ、手動による介入は必要ありません。次の表に、スタ
ンバイ・データベースとプライマリ・データベースのブランチを再同期化する方法を示しま
す。
9-24　Oracle Data Guard 概要および管理
OPEN RESETLOGS 文を使用したリカバリ
スタンバイ・データベースの状態 . .
操作 . .
実行する手順 . .
新規リセットログの SCN の後（REDO
データの新規ブランチの開始より後）の
REDO データが適用されていない場合。
手動による介入は必要ありま
せん。SQL Apply は自動的に
REDO データの新規ブランチ
を使用します。
SQL Apply を再開して REDO データの適
用を続行します。LSP は、自動的にスタ
ンバイ・データベースを REDO データの
新規ブランチと再同期化します。
新規リセットログの SCN の後（REDO
データの新規ブランチの開始より後）の
REDO データが適用され、スタンバイ・
データベースでフラッシュバック・デー
タベースが使用可能になっている場合。
スタンバイ・データベースは、 1.
REDO データの将来の新規ブ
ランチでリカバリされます。
10-33 ページの「ロジカル・スタンバ
イ・データベースのフラッシュバッ
ク」の手順に従ってロジカル・スタ
ンバイ・データベースをフラッ
シュ・バックします。
2.
SQL Apply を再開し、新規リセット
ログ・ブランチへの REDO の適用を
続行します。
LSP は、自動的にスタンバイ・データ
ベースを新規ブランチと再同期化します。
新規リセットログの SCN の後（REDO
指定のプライマリ・データ
第 4 章の手順に従ってロジカル・スタン
データの新規ブランチの開始より後）の ベース・ブランチで、プライ バイ・データベースを再作成します。
REDO データが適用され、スタンバイ・ マリ・データベースとスタン
データベースでフラッシュバック・デー バイの内容にずれが生じます。
タベースが使用可能になっていない場合。
REDO データの新規ブランチから介入す LSP は欠落しているログ・
るアーカイブ REDO ログ・ファイルが欠 ファイルが取得されるまで続
行できません。
落している場合。
各ブランチから欠落しているアーカイブ
REDO ログ・ファイルを検索して登録し
ます。
REDO データの前のブランチの終わりか LSP は欠落しているログ・
らアーカイブ REDO ログ・ファイルが欠 ファイルが取得されるまで続
行できません。
落している場合。
前のブランチから欠落しているアーカイ
ブ REDO ログ・ファイルを検索して登録
します。
データベース・インカネーション、OPEN RESETLOGS 操作を介したリカバリおよびフラッ
シュバック・データベースの詳細は、
『Oracle Database バックアップおよびリカバリ・アド
バンスト・ユーザーズ・ガイド』を参照してください。
ロジカル・スタンバイ・データベースの管理
9-25
ロジカル・スタンバイ・データベースのチューニング
ロジカル・スタンバイ・データベースのチューニング
次の各項では、システム・パフォーマンスを改善するために実行できる処置について説明し
ます。
主キー RELY 制約の作成
プライマリ・データベースで、表に主キーまたは一意索引がなく、他の方法で確認したため
に実際には一意である行がわかっている場合は、主キーの RELY 制約を作成します。ロジカ
ル・スタンバイ・データベースでは、主キーを構成する列に索引を作成します。次の問合せ
は、ロジカル・スタンバイ・データベースで行を一意に識別するために適用できる索引情報
がない表のリストを生成します。次の表に索引を作成することによって、パフォーマンスが
大幅に向上する可能性があります。
SQL>
2>
3>
3>
4>
5>
6>
SELECT OWNER, TABLE_NAME FROM DBA_TABLES
WHERE OWNER NOT IN('SYS','SYSTEM','OUTLN','DBSNMP')
MINUS
SELECT DISTINCT TABLE_OWNER, TABLE_NAME FROM DBA_INDEXES
WHERE INDEX_TYPE NOT LIKE ('FUNCTION-BASED%')
MINUS
SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED;
次の例は、EMP 表に索引を作成する文を示しています。これらの文は、前述の問合せで戻さ
れたすべての表に対して実行してください。
SQL> ALTER SESSION DISABLE GUARD;
SQL> CREATE INDEX EMPI ON EMP (EMPNO);
SQL> ALTER SESSION ENABLE GUARD;
RELY 制約の詳細は、4-6 ページの「プライマリ・データベース内の表の行が一意に識別でき
ることの確認」および『Oracle Database SQL リファレンス』を参照してください。
コストベース・オプティマイザの統計の収集
コストベース・オプティマイザ（CBO）で最適の問合せ実行パスを判別するために使用され
るため、スタンバイ・データベースで統計を収集する必要があります。以前の統計情報が正
確でなくなるような変更をスキーマ・オブジェクトのデータまたは構造に対して実行した場
合は、その後に新しい統計を収集してください。たとえば、多数の行を表に挿入または削除
した後は、行数に関する新しい統計を収集します。
プライマリ・データベースでの DML および DDL 操作はワークロードの機能として実行さ
れるため、統計はスタンバイ・データベースで収集してください。スタンバイ・データベー
スがプライマリ・データベースと論理的に等しい場合、SQL Apply ではワークロードを異な
る方法で実行する場合があります。そのため、ロジカル・スタンバイ・データベースで統計
パッケージおよび V$SYSSTAT ビューを使用すると、リソースおよび表スキャンを最も多く
使用している表を判断する際に役立ちます。
9-26　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースのチューニング
トランザクションの一貫性の調整
DBMS_LOGSTDBY.APPLY_SET プロシージャの TRANSACTION_CONSISTENCY パラメータを
使用して、ロジカル・スタンバイ・データベースへのトランザクションの適用方法を制御し
ます。デフォルト設定は FULL です。この設定では、プライマリ・データベースでコミット
された順序で、トランザクションがロジカル・スタンバイ・データベースに適用されます。
SQL Apply が正常に停止した場合は、選択した一貫性レベルを問わず、ロジカル・スタンバ
イ・データベースのデータにはプライマリ・データベースとのトランザクション一貫性があ
ります。
次の値のいずれかを指定します。
■
FULL（デフォルト）
トランザクションは、プライマリ・データベースでコミットされた順序に正確に従っ
て、ロジカル・スタンバイ・データベースに適用されます。このオプションを指定する
とパフォーマンスは最低になります。ただし、これはロジカル・スタンバイ・データ
ベースを汎用レポート・アプリケーションに使用する場合の推奨設定です。
■
READ_ONLY
トランザクションは順不同でコミットされますが、スタンバイ・データベースで実行さ
れる SQL SELECT 文は、SQL Apply で認識された最後の一貫した SCN に基づいて常に
一貫した結果を戻します。
READ_ONLY オプションによって、FULL オプションよりも高いパフォーマンスが提供さ
れ、SQL の SELECT 文によって、読取り一貫性のある結果が戻されます。この値は、レ
ポートの生成にロジカル・スタンバイ・データベースを使用している場合、特に役立ち
ます。ロジカル・スタンバイ・データベースを読取り専用レポートに使用する場合には、
READ_ONLY オプションを指定することをお薦めします。
注意 : READ_ONLY オプションは、ALTER DATABASE GUARD ALL が設
定されている場合にのみ使用してください。
■
NONE
トランザクションは、プライマリ・データベースでのコミット順序に関係なく適用され
ます。この値の結果は、3 つの値の中で最高のパフォーマンスとなります。NONE オプ
ションが役立つのは、ネットワーク接続が一時的に失われた後でロジカル・スタンバ
イ・データベースがキャッチアップ・モードになっている場合、または多数のログが適
用される場合です。また、ロジカル・スタンバイ・データベースを読み取っているアプ
リケーションに、トランザクションの順序についての条件がない場合にも、このオプ
ションは効果があります。次に例を示します。
–
プライマリ・データベースで、あるトランザクションが新規の顧客を追加し、第 2
のトランザクションがその顧客に関する新規オーダーを追加する場合。
ロジカル・スタンバイ・データベースの管理
9-27
ロジカル・スタンバイ・データベースのチューニング
–
スタンバイ・データベースでは、この 2 つのトランザクションが逆転する場合があ
ります。新規顧客に関するオーダーが最初に追加される場合があります。新規オー
ダーの顧客が見つかると思われるスタンバイ・データベースでレポート・アプリ
ケーションを実行すると、制約がチェックされずトリガーが実行されないため、レ
ポート・アプリケーションが失敗することがあります。
たとえば、図 9-7 の時系列は、トランザクション 1 が終了する前後にトランザクション 2 を
開始し、トランザクション 1 がコミットした直後にトランザクション 2 がコミットすること
を示しています。次に TRANSACTION_CONSISTENCY の設定とその結果を示します。
■
■
■
FULL: SQL Apply はトランザクション 2 の前にトランザクション 1 がコミットすること
を保証します。
READ_ONLY: SQL Apply は次のどちらかを保証します。
–
トランザクション 1 がトランザクション 2 の前にコミットすること。
–
トランザクション 1 とトランザクション 2 が同時にコミットすること。
NONE: SQL Apply は順序を保証しません。トランザクション 1 より前にトランザクショ
ン 2 がコミットする可能性があります。
図 9-7 SQL Apply でのトランザクション一貫性の例
ロジカル・スタンバイ・データベースを使用する予定の場合は、次のオプションを指定して
ください。
■
■
レポートまたは意志決定支援の場合は、FULL または READ_ONLY 値を使用します。
–
ロジカル・スタンバイ・データベースのインスタンスが 1 つのみの場合は、READ_
ONLY を選択します。
–
ロジカル・スタンバイ・データベースに複数のインスタンスがある場合（Real
Application Clusters）は、FULL を選択します。
障害時リカバリまたは SQL Apply のキャッチアップが必要な場合は、NONE を使用しま
す。
9-28　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースのチューニング
DBMS_LOGSTDBY.APPLY_SET プロシージャの詳細は、『PL/SQL パッケージ・プロシー
ジャおよびタイプ・リファレンス』を参照してください。
パラレル実行処理の最大数の調整
SQL Apply では、パラレル実行プロセスを使用して処理が実行され、パラレル適用アルゴリ
ズムを使用して高水準の SQL Apply パフォーマンスが維持されます。PARALLEL_MAX_
SERVERS 初期化パラメータを設定して、インスタンスに対するパラレル実行処理の最大数
を調整できます。このパラメータのデフォルト値は、CPU_COUNT、PARALLEL_
AUTOMATIC_TUNING および PARALLEL_ADAPTIVE_MULTI_USER の各初期化パラメータの
値から導出されます。ロジカル・スタンバイ・データベースでは、このパラメータの値は、
5 未満に設定しないでください。ただし、最高の結果を得るためには、PARALLEL_MAX_
SERVERS を 9 以上に設定してください。
DBMS_LOGSTDBY.APPLY_SET プロシージャの MAX_SERVERS パラメータを使用して、SQL
Apply が使用するパラレル・サーバーの数を制限できます。このパラメータのデフォルト値
は 9 に設定されます。このパラメータを明示的に設定する場合は、5 未満の値または
PARALLEL_MAX_SERVERS 初期化パラメータより大きい値には設定しないでください。
インスタンスに対するパラレル実行処理数を増やすと、実行操作を高速化できます。ただ
し、この改善は、プロセスにより追加されるシステム・リソースの消費とバランスを取る必
要があります。
ロジカル・スタンバイ・データベースでのメモリー使用量の制御
DBMS_LOGSTDBY.APPLY_SET プロシージャの MAX_SGA パラメータを使用して、SQL
Apply が REDO キャッシュに使用する共有プールの最大領域を設定できます。デフォルトで
は、SQL Apply により全体の 25 パーセントの共有プールが使用されます。一般的には、
SQL Apply が使用する共有プールのサイズまたは領域の増加によって、ロジカル・スタンバ
イ・データベースのパフォーマンスは向上します。DBMS_LOGSTDBY.APPLY_SET プロシー
ジャの詳細は、
『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照
してください。
ロジカル・スタンバイ・データベースの管理
9-29
ロジカル・スタンバイ・データベースのチューニング
9-30　Oracle Data Guard 概要および管理
10
Data Guard の使用例
この章では、Data Guard 構成の管理中に遭遇する可能性がある例を説明します。使用例はそ
れぞれ、ユーザー固有の環境に適応できます。表 10-1 は、この章で説明する使用例のリスト
です。
表 10-1 Data Guard の使用例
参照先
使用例
10-2 ページ
アーカイブ先の設定および確認
10-14 ページ
ロールの推移に最適なスタンバイ・データベースの選択
10-28 ページ
フェイルオーバー後のフラッシュバック・データベースの使用
10-32 ページ
Open Resetlogs 文の発行後のフラッシュバック・データベースの使用
10-35 ページ
タイム・ラグのあるフィジカル・スタンバイ・データベースの使用
10-39 ページ
ネットワーク障害のリカバリ
10-40 ページ
NOLOGGING 句を指定した後のリカバリ
10-43 ページ
手動によるアーカイブ・ギャップの解決
10-51 ページ
OMF または ASM を使用するスタンバイ・データベースの作成
Data Guard の使用例
10-1
アーカイブ先の設定および確認
アーカイブ先の設定および確認
次の各項で、ロール固有のアーカイブを使用可能および使用不可にする LOG_ARCHIVE_
DEST_n 初期化パラメータとその他の関連パラメータの設定方法を説明します。
■
プライマリ・データベースおよびフィジカル・スタンバイ・データベースの構成
■
プライマリ・データベースおよびロジカル・スタンバイ・データベースの構成
■
フィジカルおよびロジカル・スタンバイ・データベースの構成
■
各宛先について現行の VALID_FOR 属性設定の確認
プライマリ・データベースおよびフィジカル・スタンバイ・データベース
の構成
図 10-1 に、chicago プライマリ・データベース、boston フィジカル・スタンバイ・デー
タベース、および各システムの初期化パラメータを示します。
図 10-1 ロールの推移前のプライマリおよびフィジカル・スタンバイ・データベース
10-2　Oracle Data Guard 概要および管理
アーカイブ先の設定および確認
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG=
'DG_CONFIG=(chicago,boston)'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=boston
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
STANDBY_ARCHIVE_DEST=/arch1/chicago/
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG=
'DG_CONFIG=(chicago,boston)'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/boston/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2=
'SERVICE=chicago
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
STANDBY_ARCHIVE_DEST=/arch1/boston/
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
次の表で、図 10-1 で示されたアーカイブ・プロセスについて説明します。
Chicago データベース
（プライマリ・ロール）
Boston データベース
（フィジカル・スタンバイ・ロール）
LOG_ARCHIVE_DEST_1
/arch1/chicago/ 内のローカル・アーカイ
ブ REDO ログ・ファイルに REDO データを
アーカイブするよう指示。
/arch1/boston/ 内のローカル・アーカイブ
REDO ログ・ファイルに REDO データをアー
カイブするよう指示。
LOG_ARCHIVE_DEST_2
リモート・フィジカル・スタンバイ・データ
ベース boston に REDO データを転送するよ
う指示。
無視。boston がプライマリ・ロールで稼働
している場合にのみ有効。
STANDBY_ARCHIVE_DEST
無視。chicago がスタンバイ・ロールで稼働
している場合にのみ有効。
ローカルの /arch1/boston/ ディレクトリ
内のアーカイブ REDO ログ・ファイルに
REDO データをアーカイブするよう指示。
図 10-2 に、スイッチオーバー後の同一構成を示します。
Data Guard の使用例
10-3
アーカイブ先の設定および確認
図 10-2 ロールの推移後のプライマリおよびフィジカル・スタンバイ・データベース
次の表で、図 10-2 で示されたアーカイブ・プロセスについて説明します。
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
データをアーカイブするよう指示。
10-4　Oracle Data Guard 概要および管理
無視。boston がスタンバイ・ロールで稼働
している場合にのみ有効。
アーカイブ先の設定および確認
プライマリ・データベースおよびロジカル・スタンバイ・データベースの
構成
図 10-3 に、プライマリ・ロールで稼働している chicago データベース、ロジカル・スタン
バイ・ロールで稼働している denver データベース、および各システムの初期化パラメータ
を示します。アクティブでないコンポーネントはグレー表示されています。
図 10-3 プライマリ・データベースおよびロジカル・スタンバイ・データベースの宛先の構成
Data Guard の使用例
10-5
アーカイブ先の設定および確認
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG=
'DG_CONFIG=(chicago,denver)'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'LOCATION=/arch2/chicago/
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_3=
'SERVICE=denver
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE
STANDBY_ARCHIVE_DEST=/arch2/chicago/
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
DB_UNIQUE_NAME=denver
LOG_ARCHIVE_CONFIG=
'DG_CONFIG=(chicago,denver)'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/denver/
VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_2=
'LOCATION=/arch2/denver/
VALID_FOR=(STANDBY_LOGFILES,STANDBY_
ROLE)
DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_3=
'SERVICE=chicago
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE
STANDBY_ARCHIVE_DEST=/arch2/denver
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
次の表で、図 10-3 で示されたアーカイブ・プロセスについて説明します。
Chicago データベース
（プライマリ・ロール）
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 がスタンバイ・ロールで稼働して
いる場合にのみ有効。
10-6　Oracle Data Guard 概要および管理
/arch2/denver/ 内のアーカイブ
REDO ログ・ファイルにプライマリ・
データベースから受信した REDO データ
を直接アーカイブするよう指示。
アーカイブ先の設定および確認
フィジカル・スタンバイ・データベースと異なり、ロジカル・スタンバイ・データベース
は、REDO データを生成し、複数のログ・ファイル（オンライン REDO ログ・ファイル、
アーカイブ REDO ログ・ファイルおよびスタンバイ REDO ログ・ファイル）を持つオープ
ン状態のデータベースです。次のものに対し、別々のローカル宛先を指定することをお薦め
します。
■
■
ロジカル・スタンバイ・データベースによって生成された REDO データを格納するアー
カイブ REDO ログ・ファイル。図 10-3 では、これは LOG_ARCHIVE_DEST_
1=LOCATION=/arch1/denver 宛先として構成されています。
プライマリ・データベースから受信した REDO データを格納するアーカイブ REDO ロ
グ・ファイル。図 10-3 では、これは LOG_ARCHIVE_DEST_
2=LOCATION=/arch2/denver 宛先として構成されています。
図 10-3 では、次の目的に対し、STANDBY_ARCHIVE_DEST パラメータは同じ位置が構
成されています。
–
スタンバイ REDO ログ・ファイルがいっぱいになると、プライマリ・データベー
スから受信した REDO データは、この位置のアーカイブ REDO ログ・ファイルに
直接アーカイブされます（5-34 ページの「アーカイブ REDO ログ・ファイルの代
替ディレクトリ位置の指定」で説明）
。
–
アーカイブ・ギャップが存在する場合、他のデータベースから受信したアーカイブ
REDO ログ・ファイルは、この位置にコピーされます（5-40 ページの「アーカイ
ブ・ギャップの管理」で説明）
。
図 10-3（および図 10-4）で示される構成例にはフィジカル・スタンバイ・データベースが含
まれていないため、ロジカル・スタンバイ・データベースを使用したスイッチオーバー用に
LOG_ARCHIVE_DEST_3 宛先が構成によって設定されます。図 10-4 に、スイッチオーバー
後の同一構成を示します。
Data Guard の使用例
10-7
アーカイブ先の設定および確認
図 10-4 ロールの推移後のプライマリおよびロジカル・スタンバイ・データベース
次の表で、図 10-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 データを直接アーカイブするよ
う指示。
10-8　Oracle Data Guard 概要および管理
無視。denver がスタンバイ・ロールで稼
働している場合にのみ有効。
アーカイブ先の設定および確認
フィジカルおよびロジカル・スタンバイ・データベースの構成
図 10-5 に、プライマリ・ロールで稼働している chicago データベース、フィジカル・スタ
ンバイ・ロールで稼働している boston データベース、およびロジカル・スタンバイ・デー
タベース・ロールで稼働している denver データベースを示します。初期化パラメータは各
システムの下に示されています。グレー表示されているコンポーネントは、そのデータベー
スの現行ロールではアクティブないことを示します。この例は、スイッチオーバーが
chicago と boston の間でのみ発生することを前提としています。この構成では、denver
ロジカル・スタンバイ・データベースはレポート用データベースのみを目的としています。
denver は、スイッチオーバーの対象にはならず、プライマリ・ロールで稼働することもあ
りません。
図 10-5 フィジカルおよびロジカル・スタンバイ・データベースを備えたプライマリ・データベースの構成
Data Guard の使用例
10-9
アーカイブ先の設定および確認
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG=
'DG_CONFIG=(chicago,boston,
denver)'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/boston/
VALID_FOR=
(ONLINE_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2=
'SERVICE=denver
VALID_FOR=
(ONLINE_LOGFILES,PRIMARY_
ROLE)
DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_3=
'SERVICE=chicago
VALID_FOR=
(ONLINE_LOGFILES,PRIMARY_
ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_
1=ENABLE
LOG_ARCHIVE_DEST_STATE_
2=ENABLE
LOG_ARCHIVE_DEST_STATE_
3=ENABLE
STANDBY_ARCHIVE_DEST=
/arch1/boston/
REMOTE_LOGIN_
PASSWORDFILE=EXCLUSIVE
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG=
'DG_CONFIG=(chicago,boston,
denver)'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=
(ONLINE_LOGFILES,ALL_
ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=denver
VALID_FOR=
(ONLINE_LOGFILES,PRIMARY_
ROLE)
DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_3=
'SERVICE=boston
VALID_FOR=
(ONLINE_LOGFILES,PRIMARY_
ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_
1=ENABLE
LOG_ARCHIVE_DEST_STATE_
2=ENABLE
LOG_ARCHIVE_DEST_STATE_
3=ENABLE
STANDBY_ARCHIVE_DEST=
/arch1/chicago/
REMOTE_LOGIN_
PASSWORDFILE=EXCLUSIVE
DB_UNIQUE_NAME=denver
LOG_ARCHIVE_CONFIG=
'DG_
CONFIG=(chicago,boston,
denver)'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/denver/
VALID_FOR=
(ONLINE_LOGFILES,ALL_
ROLES)
DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_2=
'LOCATION=/arch2/denver/
VALID_FOR=
(STANDBY_
LOGFILES,STANDBY_ROLE)
DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_STATE_
1=ENABLE
LOG_ARCHIVE_DEST_STATE_
2=ENABLE
STANDBY_ARCHIVE_
DEST=/arch2/denver
REMOTE_LOGIN_
PASSWORDFILE=EXCLUSIVE
次の表で、図 10-5 で示されたアーカイブ・プロセスについて説明します。
Chicago データベース
（プライマリ・ロール）
LOG_ARCHIVE_DEST_1
/arch1/chicago/ 内のロー
カル・アーカイブ REDO ロ
グ・ファイルにオンライン
REDO ログ・ファイルからの
REDO データをアーカイブす
るよう指示。
10-10　Oracle Data Guard 概要および管理
Boston データベース
（スタンバイ・ロール）
/arch1/boston/ 内のローカ
ル・アーカイブ REDO ログ・
ファイルにスタンバイ REDO
ログ・ファイルからの REDO
データをアーカイブするよう
指示。
Denver データベース
（スタンバイ・ロール）
/arch1/denver/ 内のローカ
ル・アーカイブ REDO ログ・
ファイルにローカル・オンラ
イン REDO ログ・ファイルか
らロジカル・スタンバイ・
データベースによって生成さ
れた REDO データをアーカイ
ブするよう指示。
アーカイブ先の設定および確認
Chicago データベース
（プライマリ・ロール）
Boston データベース
（スタンバイ・ロール）
Denver データベース
（スタンバイ・ロール）
LOG_ARCHIVE_DEST_2
リモート・ロジカル・スタン
バイ宛先 denver に REDO
データを転送するよう指示。
無視。boston がプライマリ・ /arch2/denver/ 内のローカ
ロールで稼働している場合に
ル・アーカイブ REDO ログ・
のみ有効。
ファイルにスタンバイ REDO
ログ・ファイルからの REDO
データをアーカイブするよう
指示。
LOG_ARCHIVE_DEST_3
リモート・フィジカル・スタ
ンバイ宛先 boston に REDO
データを転送するよう指示。
無視。boston がプライマリ・ このデータベースに対しては
定義なし。
ロールで稼働している場合に
のみ有効。
STANDBY_ARCHIVE_DEST 無視。スタンバイ・ロールで
のみ有効。
/arch1/boston/ 内のアーカ
イブ REDO ログ・ファイルに
プライマリ・データベースか
ら受信した REDO データを直
接アーカイブするよう指示。
/arch2/denver/ 内のアーカ
イブ REDO ログ・ファイルに
プライマリ・データベースか
ら受信した REDO データを直
接アーカイブするよう指示。
図 10-6 に、スイッチオーバーによって chicago データベースがスタンバイ・ロールに変更
され、boston データベースがプライマリ・ロールに変更された後の同一構成を示します。
図 10-6 ロールの推移後のプライマリ、フィジカルおよびロジカル・スタンバイ・データベース
次の表で、図 10-6 で示されたアーカイブ・プロセスについて説明します。
Data Guard の使用例
10-11
アーカイブ先の設定および確認
Chicago データベース
（スタンバイ・ロール）
Boston データベース
（プライマリ・ロール）
Denver データベース
（スタンバイ・ロール）
LOG_ARCHIVE_DEST_1
/arch1/chicago/ 内のロー
カル・アーカイブ REDO ログ・
ファイルにスタンバイ REDO
ログ・ファイルからの REDO
データをアーカイブするよう指
示。
/arch1/boston/ 内のロー
カル・アーカイブ REDO ロ
グ・ファイルにオンライン
REDO ログ・ファイルからの
REDO データをアーカイブす
るよう指示。
/arch1/denver/ 内のローカ
ル・アーカイブ REDO ログ・
ファイルにローカル・オンラ
イン REDO ログ・ファイルか
らロジカル・スタンバイ・
データベースによって生成さ
れた REDO データをアーカイ
ブするよう指示。
LOG_ARCHIVE_DEST_2
無視。chicago がプライマリ・ リモート・ロジカル・スタン
ロールで稼働している場合にの バイ宛先 denver に REDO
み有効。
データを転送するよう指示。
/arch2/denver/ 内のローカ
ル・アーカイブ REDO ログ・
ファイルにスタンバイ REDO
ログ・ファイルからの REDO
データをアーカイブするよう
指示。
LOG_ARCHIVE_DEST_3
無視。chicago がプライマリ・ リモート・フィジカル・スタ
ロールで稼働している場合にの ンバイ宛先 chicago に
み有効。
REDO データを転送するよう
指示。
このデータベースに対しては
定義なし。
STANDBY_ARCHIVE_DEST /arch1/chicago/ 内のアー
無視。スタンバイ・ロールで
のみ有効。
カイブ REDO ログ・ファイル
にプライマリ・データベースか
ら受信した REDO データを直
接アーカイブするよう指示。
10-12　Oracle Data Guard 概要および管理
/arch2/denver/ 内のアーカ
イブ REDO ログ・ファイルに
プライマリ・データベースか
ら受信した REDO データを直
接アーカイブするよう指示。
アーカイブ先の設定および確認
各宛先について現行の VALID_FOR 属性設定の確認
Data Guard 構成の各宛先で、現行の VALID_FOR 属性の設定が有効であるかを即時確認す
るには、例 10-1 に示すように、V$ARCHIVE_DEST ビューを問い合せます。
例 10-1 V$ARCHIVE_DEST ビューでの VALID_FOR 情報の検索
SQL> SELECT DEST_10,VALID_TYPE,VALID_ROLE,VALID_NOW FROM V$ARCHIVE_DEST;
DEST_10 VALID_TYPE
VALID_ROLE
VALID_NOW
------- --------------- ------------ ---------------1
ALL_LOGFILES
ALL_ROLES
YES
2
STANDBY_LOGFILE STANDBY_ROLE WRONG VALID_TYPE
3
ONLINE_LOGFILE STANDBY_ROLE WRONG VALID_ROLE
4
ALL_LOGFILES
ALL_ROLES
UNKNOWN
5
ALL_LOGFILES
ALL_ROLES
UNKNOWN
6
ALL_LOGFILES
ALL_ROLES
UNKNOWN
7
ALL_LOGFILES
ALL_ROLES
UNKNOWN
8
ALL_LOGFILES
ALL_ROLES
UNKNOWN
9
ALL_LOGFILES
ALL_ROLES
UNKNOWN
10
ALL_LOGFILES
ALL_ROLES
UNKNOWN
10 rows selected.
例 10-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 ビューの説明を参照してください。
Data Guard の使用例
10-13
ロールの推移に最適なスタンバイ・データベースの選択
ロールの推移に最適なスタンバイ・データベースの選択
各スタンバイ・データベースは、1 つのプライマリ・データベースのみと対応付けられてい
ます。ただし、各プライマリ・データベースは、複数のフィジカルまたはロジカル・スタン
バイ・データベースをサポートできます。この使用例では、フェイルオーバーまたはスイッ
チオーバーに最適なスタンバイ・データベースの選択に必要な情報の判断方法を示します。
構成内にフィジカル・スタンバイ・データベースが含まれ、環境でフィジカルおよびロジカ
ル・スタンバイ・データベースの両方を使用する場合は、最適なフィジカル・スタンバイ・
データベースを使用したロールの推移の実行をお薦めします。これには次の理由がありま
す。
■
■
ロジカル・スタンバイ・データベースには、プライマリ・データベース内にあるデータ
のサブセットのみが含まれている可能性があります。
ロジカル・スタンバイ・データベースが関与するロールの推移では、既存のフィジカ
ル・スタンバイ・データベースは、ロールの推移が完了した後も Data Guard 構成に継
続して含まれるように、新しいプライマリ・データベースのコピーから再作成する必要
があります。
これらの制限があるため、ロジカル・スタンバイ・データベースをロールの推移のターゲッ
トとして考慮するのは、次のような特別な状況の場合に限定してください。
■
■
構成にロジカル・スタンバイ・データベースのみが含まれている場合。
スタンバイ・データベースのプライマリ・ロールへの迅速なフェイルオーバーが重要
で、構成内の最新のロジカル・スタンバイ・データベースが構成内の最新のフィジカ
ル・スタンバイ・データベースに比較して大幅に更新されている場合。
フィジカルまたはロジカル・スタンバイ・データベースの使用を決定すると、ロールの推移
のターゲットとして選択する特定のスタンバイ・データベースは、スタンバイ・ロケーショ
ンにある最新のプライマリ・データベースの変更量とそれらの変更がスタンバイ・データ
ベースに適用された量によって判断されます。プライマリ・データベースはスイッチオー
バー中もアクセス可能な状態であるため、データの消失はありません。また、スイッチオー
バー中に使用されるスタンバイ・データベースの選択によって影響を受けるのは、スイッチ
オーバーの完了に必要な時間のみです。ただし、フェイルオーバーの場合、スタンバイ・
データベースの選択では、データ消失に関するリスクの増加と、スタンバイ・データベース
のプライマリ・ロールへの推移に必要な時間との間でトレードオフが必要となります。
10-14　Oracle Data Guard 概要および管理
ロールの推移に最適なスタンバイ・データベースの選択
例 : フェイルオーバーに最適なフィジカル・スタンバイ・データベース
障害時に DBA にとって最も重要な作業は、より迅速でかつ安全なのはプライマリ・データ
ベースの修正か、スタンバイ・データベースへのフェイルオーバーかを判断することです。
フェイルオーバーが必要と判断し、複数のフィジカル・スタンバイ・データベースが構成さ
れている場合は、DBA がフェイルオーバーのターゲットとして最適なフィジカル・スタン
バイ・データベースを選択する必要があります。最適なスタンバイ・データベースの判断に
影響を与える環境上の要因は様々ですが、この使用例では、データ消失の査定を明確にする
ために、これらの要因が等しいと仮定します。
この使用例では、HQ プライマリ・データベースと 2 つのフィジカル・スタンバイ・データ
ベース（SAT と NYC）で構成した Data Guard 構成を前提に説明します。HQ データベース
は最大可用性保護モードで動作し、スタンバイ・データベースはそれぞれ 3 つのスタンバイ
REDO ログ・ファイルで構成されています。フィジカル・スタンバイ・データベースの最大
可用性保護モードの詳細は、1-9 ページの「Data Guard 保護モード」を参照してください。
表 10-2 に、この使用例で使用されているデータベースに関する情報を示します。
表 10-2 フィジカル・スタンバイ・データベースの例で使用される識別子
識別子
HQ データベース
SAT データベース NYC データベース
場所
サンフランシスコ シアトル
ニューヨーク市
データベース名
HQ
HQ
HQ
インスタンス名
HQ
SAT
NYC
初期化パラメータ・ファイル
hq_init.ora
sat_init.ora
nyc_init.ora
制御ファイル
hq_cf1.f
sat_cf1.f
nyc_cf1.f
データ・ファイル
hq_db1.f
sat_db1.f
nyc_db1.f
REDO ログ・ファイル 1
hq_log1.f
sat_log1.f
nyc_log1.f
REDO ログ・ファイル 2
hq_log2.f
sat_log2.f
nyc_log2.f
スタンバイ REDO ログ・ファイル 1 hq_srl1.f
sat_srl1.f
nyc_srl1.f
スタンバイ REDO ログ・ファイル 2 hq_srl2.f
sat_srl2.f
nyc_srl2.f
スタンバイ REDO ログ・ファイル 3 hq_srl3.f
sat_srl3.f
nyc_srl3.f
プライマリ保護モード
最大可用性
該当なし
該当なし
スタンバイ保護モード
該当なし
ネットワーク・サービス名
（クライアント定義）
リスナー
最大可用性
（同期）
最大パフォーマンス
（非同期）
hq_net
sat_net
nyc_net
hq_listener
sat_listener
nyc_listener
Data Guard の使用例
10-15
ロールの推移に最適なスタンバイ・データベースの選択
注意 : ピーク・ワークロード時に HQ から NYC に REDO データを同期
させて送信することは、プライマリ・データベースのパフォーマンスに影
響を与える可能性があるため、ニューヨーク市のデータベースは最大パ
フォーマンス・モードで動作しています。ただし、ニューヨーク市のスタ
ンバイ・データベースは、スタンバイ REDO ログを使用しているため、
フェイルオーバーの有効な候補とみなされたままです。
プライマリ・サイトがあるサンフランシスコでイベントが発生し、適時に修正できないよう
な被害を受けたと仮定します。スタンバイ・データベースの 1 つにフェイルオーバーする必
要があります。複数のスタンバイ・データベース構成を設定した DBA が、どのスタンバ
イ・データベースにフェイルオーバーするのが適切であるかを必ずしも決定できる状態にあ
るとは限りません。したがって、各スタンバイ・サイトで、プライマリ・サイト同様に障害
時リカバリ計画を立てることが必要になります。障害時リカバリ・チームの各メンバーは、
障害時リカバリ計画を知っており、実行する手順を認識している必要があります。この使用
例では、フェイルオーバーのターゲットとなるスタンバイ・データベースの判断に必要な情
報を識別します。
障害時リカバリ・チームに情報を提供する 1 つの方法は、各スタンバイ・サイトに ReadMe
ファイルを用意しておく方法です。この ReadMe ファイルは DBA によって作成およびメン
テナンスされ、次の方法を記述している必要があります。
■
DBA としてのローカル Oracle データベースへのログオン方法
■
スタンバイ・データベースが存在する各システムへのログオン方法
■
システム間にはファイアウォールが存在する可能性があるため、ファイアウォールを通
過する手順の取得方法
■
DBA として他の Oracle データベースへログオンする方法
■
最も新しいログが適用されているスタンバイ・データベースの識別方法
■
スタンバイ・データベース・フェイルオーバーの実行方法
■
クライアント・アプリケーションが、元のプライマリ・データベースではなく、新しい
プライマリ・データベースにアクセスできるようなネットワーク設定の構成方法
ReadMe ファイルのサンプルは、付録 F を参照してください。
スタンバイ・データベースの選択に際しては、2 つの重要な考慮事項があります。1 つは最
新の REDO データを受信したスタンバイ・データベース、もう 1 つは最多の REDO を適用
したスタンバイ・データベースです。
次の手順に従って、フィジカル・スタンバイ・データベースのみで構成されている場合に、
どのスタンバイ・データベースがフェイルオーバーに最適な候補であるかを決定します。常
に、最高の保護レベルを提供しているスタンバイ・データベースから考慮します。この使用
10-16　Oracle Data Guard 概要および管理
ロールの推移に最適なスタンバイ・データベースの選択
例では、シアトルのスタンバイ・データベースが最大可用性保護モードで動作しているた
め、このデータベースが最高の保護レベルを提供しています。
手順 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
Data Guard の使用例
10-17
ロールの推移に最適なスタンバイ・データベースの選択
/oracle/dbs/hq_sat_10.log
/oracle/dbs/hq_sat_11.log
/oracle/dbs/hq_sat_13.log
10 YES
11 YES
13 NO
この出力は、アーカイブ REDO ログ・ファイル 11 がスタンバイ・データベースに完全に適
用されたことを示しています。
（出力例では、ログ・ファイル 11 の行を確認しやすいように
太字で示していますが、実際の出力は太字ではありません）。
SEQUENCE# 列の順序番号にギャップがあることにも注意してください。この例の場合は、
SAT スタンバイ・データベースでアーカイブ REDO ログ・ファイル番号 12 が欠落している
ことを示しています。
手順 4 NYC データベースに接続して、NYC
データベースが SAT スタンバイ・データベー
データベースに接続して、
スよりも新しいかどうかを判断する
次のような SQL 文を発行します。
SQL> CONNECT SYS/CHANGE_ON_INSTALL AS SYSDBA;
手順 5 アーカイブ REDO ログ・ファイルで使用可能なカレント REDO データの量を判別する
次のように、V$MANAGED_STANDBY ビューの列を問い合せます。
SQL> SELECT THREAD#, SEQUENCE#, BLOCK#, BLOCKS
2> FROM V$MANAGED_STANDBY WHERE STATUS='RECEIVING';
THREAD# SEQUENCE#
BLOCK#
BLOCKS
---------- ---------- ---------- ---------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
10-18　Oracle Data Guard 概要および管理
ロールの推移に最適なスタンバイ・データベースの選択
/oracle/dbs/hq_nyc_8.log
/oracle/dbs/hq_nyc_9.log
/oracle/dbs/hq_nyc_10.log
/oracle/dbs/hq_nyc_11.log
/oracle/dbs/hq_nyc_12.log
/oracle/dbs/hq_nyc_13.log
8
9
10
11
12
13
NO
NO
NO
NO
NO
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
Data Guard の使用例
10-19
ロールの推移に最適なスタンバイ・データベースの選択
2.
次の順序番号に対して、部分的なアーカイブ REDO ログ・ファイルが存在しているかど
うかを判別します。この例では、次の順序番号は 14 となります。次の UNIX コマンド
では、SAT データベースのディレクトリが検索され、hq_sat_14.log という名のアー
カイブ REDO ログ・ファイルが存在しているかどうかが調べられます。
% ls -l /net/sat/oracle/dbs/hq_sat_14.log
/net/sat/oracle/dbs/hq_sat_14.log: No such file or directory
SAT スタンバイ・データベースはスタンバイ REDO ログ・ファイルを使用しているた
め、部分的なアーカイブ REDO ログ・ファイルが存在していることはありません。
3.
取得したアーカイブ REDO ログ・ファイルを登録します。（ログ適用サービスを停止す
る必要はありません）
。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '/oracle/dbs/hq_sat_12.log';
4.
V$ARCHIVED_LOG ビューを再度問い合せて、アーカイブ REDO ログ・ファイルが正常
に適用されたことを確認します。
SQL> SELECT SUBSTR(NAME,1,25) FILE_NAME, SEQUENCE#, APPLIED
2> FROM V$ARCVHIVED_LOG ORDER BY SEQUENCE#;
FILE_NAME
SEQUENCE# APP
------------------------- ---------- --/oracle/dbs/hq_sat_2.log
2 YES
/oracle/dbs/hq_sat_3.log
3 YES
/oracle/dbs/hq_sat_4.log
4 YES
/oracle/dbs/hq_sat_5.log
5 YES
/oracle/dbs/hq_sat_6.log
6 YES
/oracle/dbs/hq_sat_7.log
7 YES
/oracle/dbs/hq_sat_8.log
8 YES
/oracle/dbs/hq_sat_9.log
9 YES
/oracle/dbs/hq_sat_10.log
10 YES
/oracle/dbs/hq_sat_11.log
11 YES
/oracle/dbs/hq_sat_12.log
12 YES
/oracle/dbs/hq_sat_13.log
13 YES
10-20　Oracle Data Guard 概要および管理
ロールの推移に最適なスタンバイ・データベースの選択
ビジネス要件に基づいて最適なターゲットとして 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.
ログ適用サービスを開始して、最新のログ・ファイルを適用します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> DISCONNECT FROM SESSION;
3.
V$ARCHIVED_LOG ビューを再度問い合せて、アーカイブ REDO ログ・ファイルが正常
に適用されたことを確認します。
SQL> SELECT SUBSTR(NAME,1,25) FILE_NAME, SEQUENCE#, APPLIED
2> FROM V$ARCVHIVED_LOG ORDER BY SEQUENCE#;
FILE_NAME
SEQUENCE# APP
------------------------- ---------- --/oracle/dbs/hq_nyc_2.log
2 YES
/oracle/dbs/hq_nyc_3.log
3 YES
/oracle/dbs/hq_nyc_4.log
4 YES
/oracle/dbs/hq_nyc_5.log
5 YES
/oracle/dbs/hq_nyc_6.log
6 YES
/oracle/dbs/hq_nyc_7.log
7 YES
/oracle/dbs/hq_nyc_8.log
8 YES
/oracle/dbs/hq_nyc_9.log
9 YES
/oracle/dbs/hq_nyc_10.log
10 YES
/oracle/dbs/hq_nyc_11.log
11 YES
/oracle/dbs/hq_nyc_12.log
12 NO
/oracle/dbs/hq_nyc_13.log
13 NO
アーカイブ REDO ログ・ファイルの適用では、完了までに時間がかかる場合がありま
す。したがって、次のようにすべてのアーカイブ REDO ログ・ファイルが指定されるま
で待機する必要があります。
SQL> SELECT SUBSTR(NAME,1,25) FILE_NAME, SEQUENCE#, APPLIED
2> FROM V$ARCVHIVED_LOG ORDER BY SEQUENCE#;
FILE_NAME
SEQUENCE# APP
------------------------- ---------- --/oracle/dbs/hq_nyc_2.log
2 YES
Data Guard の使用例
10-21
ロールの推移に最適なスタンバイ・データベースの選択
/oracle/dbs/hq_nyc_3.log
/oracle/dbs/hq_nyc_4.log
/oracle/dbs/hq_nyc_5.log
/oracle/dbs/hq_nyc_6.log
/oracle/dbs/hq_nyc_7.log
/oracle/dbs/hq_nyc_8.log
/oracle/dbs/hq_nyc_9.log
/oracle/dbs/hq_nyc_10.log
/oracle/dbs/hq_nyc_11.log
/oracle/dbs/hq_nyc_12.log
/oracle/dbs/hq_nyc_13.log
3
4
5
6
7
8
9
10
11
12
13
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
手順 9 フェイルオーバーを実行する
ログ適用サービスを停止し、選択したフィジカル・スタンバイ・データベースをプライマ
リ・ロールにフェイルオーバーする準備が整いました。
フィジカル・スタンバイ・データベースに対するフェイルオーバーの実行方法の詳細は、
7-15 ページの「フィジカル・スタンバイ・データベースが関与するフェイルオーバー」を参
照してください。
例 : フェイルオーバー操作に最適なロジカル・スタンバイ・データベース
障害時にロジカル・スタンバイ・データベースのみが使用可能な場合、重要な作業は、どの
ロジカル・スタンバイ・データベースがフェイルオーバーに最適かを判断することです。最
適なターゲット・スタンバイ・データベースの判断に影響を与える環境上の要因は様々です
が、この使用例では、データ消失の査定を明確にするために、これらの要因が等しいと仮定
します。ロジカル・スタンバイ・データベースの最大可用性保護モードの詳細は、1-9 ページ
の「Data Guard 保護モード」を参照してください。
この使用例では、HQ プライマリ・データベースと 2 つのロジカル・スタンバイ・データ
ベース（SAT と NYC）で構成した Data Guard 構成を前提に説明します。表 10-3 に、これ
らのデータベースに関する情報を示します。
表 10-3 ロジカル・スタンバイ・データベースの例で使用される識別子
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
識別子
10-22　Oracle Data Guard 概要および管理
ロールの推移に最適なスタンバイ・データベースの選択
表 10-3 ロジカル・スタンバイ・データベースの例で使用される識別子（続き）
識別子
HQ データ
ベース
SAT データ
ベース
NYC データ
ベース
データ・ファイル
hq_db1.f
sat_db1.f
nyc_db1.f
REDO ログ・ファイル 1
hq_log1.f
sat_log1.f
nyc_log1.f
REDO ログ・ファイル 2
hq_log2.f
sat_log2.f
nyc_log2.f
データベース・リンク
（クライアント定義）
hq_link
sat_link
nyc_link
ネットワーク・サービス名
（クライアント定義）
hq_net
sat_net
nyc_net
hq_listener
sat_listener
nyc_listener
リスナー
次の手順に従って、ロジカル・スタンバイ・データベースのみで構成されている場合に、ど
のスタンバイ・データベースがフェイルオーバーに最適な候補であるかを決定します。
手順 1 SAT ロジカル・スタンバイ・データベースに接続する
次のような SQL 文を発行します。
SQL> CONNECT SYS/CHANGE_ON_INSTALL AS SYSDBA;
手順 2 SAT データベースに適用された最大の SCN と適用可能な最大（最新）の SCN を判
断する
DBA_LOGSTDBY_PROGRESS ビューで、次の列を問い合せます。
SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN NEWEST_SCN
----------- ---------144059
144059
手順 3 SAT データベースに適用した、または適用を保留しているアーカイブ REDO ログ・
ファイルのリストを取得する
DBA_LOGSTDBY_LOG ビューを問い合せます。
SQL>
2>
3>
4>
SELECT SUBSTR(FILE_NAME,1,25) FILE_NAME, SUBSTR(SEQUENCE#,1,4) "SEQ#",
FIRST_CHANGE#, NEXT_CHANGE#, TO_CHAR(TIMESTAMP, 'HH:MI:SS') TIMESTAMP,
DICT_BEGIN BEG, DICT_END END, SUBSTR(THREAD#,1,4) "THR#"
FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
FILE_NAME
SEQ# FIRST_CHANGE# NEXT_CHANGE# TIMESTAM BEG END THR#
------------------------- ---- ------------- ------------ -------- --- --- ----
Data Guard の使用例
10-23
ロールの推移に最適なスタンバイ・データベースの選択
/oracle/dbs/hq_sat_2.log
/oracle/dbs/hq_sat_3.log
/oracle/dbs/hq_sat_4.log
/oracle/dbs/hq_sat_5.log
/oracle/dbs/hq_sat_6.log
/oracle/dbs/hq_sat_7.log
/oracle/dbs/hq_sat_8.log
/oracle/dbs/hq_sat_9.log
/oracle/dbs/hq_sat_10.log
/oracle/dbs/hq_sat_11.log
/oracle/dbs/hq_sat_13.log
2
3
4
5
6
7
8
9
10
11
13
101579
101588
142065
142307
142739
143973
144042
144051
144054
144057
144089
101588
142065
142307
142739
143973
144042
144051
144054
144057
144060
144147
11:02:57
11:02:01
11:02:09
11:02:47
12:02:09
01:02:00
01:02:00
01:02:15
01:02:20
01:02:25
01:02:40
NO
NO
NO
YES
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
YES
NO
NO
NO
NO
NO
NO
NO
1
1
1
1
1
1
1
1
1
1
1
手順 2 に記載されているログ・ファイル 11 の SCN144059 は、FIRST_CHANGE# 列の値
144057 と NEXT_CHANGE# 列の値 144060 の間にあります。これは、ログ・ファイル 11 が現
在適用中であることを示します。
（出力例では、ログ・ファイル 11 の行を確認しやすいよう
に太字で示していますが、実際の出力は太字ではありません）。SEQ# 列の順序番号にギャッ
プがあることにも注意してください。この例の場合は、SAT データベースでアーカイブ
REDO ログ・ファイル 12 が欠落していることを示しています。
手順 4 NYC データベースに接続する
次のような SQL 文を発行します。
SQL> CONNECT SYS/CHANGE_ON_INSTALL AS SYSDBA;
手順 5 NYC データベースに適用された最大の SCN と適用可能な最大の SCN を判断する
DBA_LOGSTDBY_PROGRESS ビューで、次の列を問い合せます。
SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN NEWEST_SCN
----------- ---------143970
144146
手順 6 NYC データベースで処理済または現在処理が保留中のログ・ファイルのリストを取
得する
次のような SQL 文を発行します。
SQL>
2>
3>
4>
SELECT SUBSTR(FILE_NAME,1,25) FILE_NAME, SUBSTR(SEQUENCE#,1,4) "SEQ#",
FIRST_CHANGE#, NEXT_CHANGE#, TO_CHAR(TIMESTAMP, 'HH:MI:SS') TIMESTAMP,
DICT_BEGIN BEG, DICT_END END, SUBSTR(THREAD#,1,4) "THR#"
FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
FILE_NAME
------------------------/oracle/dbs/hq_nyc_2.log
/oracle/dbs/hq_nyc_3.log
/oracle/dbs/hq_nyc_4.log
10-24　Oracle Data Guard 概要および管理
SEQ# FIRST_CHANGE# NEXT_CHANGE# TIMESTAM BEG
---- ------------- ------------ -------- --2
101579
101588 11:02:58 NO
3
101588
142065 11:02:02 NO
4
142065
142307 11:02:10 NO
END
--NO
NO
NO
THR#
---1
1
1
ロールの推移に最適なスタンバイ・データベースの選択
/oracle/dbs/hq_nyc_5.log
/oracle/dbs/hq_nyc_6.log
/oracle/dbs/hq_nyc_7.log
/oracle/dbs/hq_nyc_8.log
/oracle/dbs/hq_nyc_9.log
/oracle/dbs/hq_nyc_10.log
/oracle/dbs/hq_nyc_11.log
/oracle/dbs/hq_nyc_12.log
/oracle/dbs/hq_nyc_13.log
5
6
7
8
9
10
11
12
13
142307
142739
143973
144042
144051
144054
144057
144060
144089
142739
143973
144042
144051
144054
144057
144060
144089
144147
11:02:48
12:02:10
01:02:11
01:02:01
01:02:16
01:02:21
01:02:26
01:02:30
01:02:41
YES
NO
NO
NO
NO
NO
NO
NO
NO
YES
NO
NO
NO
NO
NO
NO
NO
NO
1
1
1
1
1
1
1
1
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 の一部）は失われます。
最適なターゲット・スタンバイ・データベースは、ビジネス要件に基づいて選択します。
Data Guard の使用例
10-25
ロールの推移に最適なスタンバイ・データベースの選択
手順 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
3.
1:03 hq_sat_14.log
ログ適用サービスを停止し、取得したアーカイブ 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';
4.
ログ適用サービスを開始して、最新のログ・ファイルを適用します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
5.
DBA_LOGSTDBY_PROGRESS ビューを問い合せて SAT データベースで適用済みの最大の
SCN を判断し、APPLIED_SCN 列の値が NEWEST_SCN 列の値と等しいかどうかを調べ
ます。
SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN NEWEST_SCN
----------- ---------144205
144205
SCN の値が一致しているため、プライマリ・データベースの現在のログ・ファイルと、
SAT データベースに適用された最後のログ・ファイルの間の遅延（ラグ）がなくなった
ことを確認できます。
10-26　Oracle Data Guard 概要および管理
ロールの推移に最適なスタンバイ・データベースの選択
ビジネス要件に基づいて最適なターゲットとして 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
2.
1:03 hq_nyc_14.log
部分的なアーカイブ REDO ログ・ファイルを NYC データベースに登録します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/oracle/dbs/hq_nyc_14.log';
3.
ログ適用サービスを開始して、最新のログ・ファイルを適用します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
4.
DBA_LOGSTDBY_PROGRESS ビューを問い合せて NYC データベースで適用済の最大の
SCN を判別し、APPLIED_SCN 列の値が NEWEST_SCN 列の値と等しいかどうかを調べ
ます。
SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN NEWEST_SCN
----------- ---------144205
144205
SCN の値が一致しているため、プライマリ・データベースの現在のログ・ファイルと、
NYC データベースで受信され適用された最後のログ・ファイルの間の遅延（ラグ）が
なくなったことを確認できます。
手順 9 フェイルオーバーを実行する
ログ適用サービスを停止し、選択したロジカル・スタンバイ・データベースをプライマリ・
ロールにフェイルオーバーする準備が整いました。
フェイルオーバーの実行方法の詳細は、7-23 ページの「ロジカル・スタンバイ・データベー
スが関与するフェイルオーバー」を参照してください。
Data Guard の使用例
10-27
フェイルオーバー後のフラッシュバック・データベースの使用
フェイルオーバー後のフラッシュバック・データベースの使用
フェイルオーバーの発生後、元のプライマリ・データベースは、修正され、新しい構成のス
タンバイ・データベースとして確立されるまで、Data Guard 構成に含められません。これを
行うには、フラッシュバック・データベース機能を使用して、障害の発生したプライマリ・
データベースを障害発生前の時点にフラッシュバックし、その後新しい構成内のフィジカル
またはロジカル・スタンバイ・データベースに変換します。次の各項で、次の内容を説明し
ます。
■
■
障害が発生したプライマリ・データベースのフィジカル・スタンバイ・データベースへ
の変換
障害が発生したロジカル・データベースのフィジカル・スタンバイ・データベースへの
変換
注意 : フェイルオーバー前に、元のプライマリ・データベースでフラッ
シュバック・データベースが使用可能になっている必要があります。詳細
は、
『Oracle Database バックアップおよびリカバリ・アドバンスト・ユー
ザーズ・ガイド』を参照してください。
障害が発生したプライマリ・データベースのフィジカル・スタンバイ・
データベースへの変換
次の手順では、ユーザーがすでにフィジカル・スタンバイ・データベースを使用したフェイ
ルオーバーを実行済で、古いプライマリ・データベースでフラッシュバック・データベース
が使用可能にされていることを前提としています。この手順では、古いプライマリ・データ
ベースを新しいフィジカル・スタンバイ・データベースとして 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;
古いプライマリ・データベースは、新しいフィジカル・スタンバイ・データベースとなりま
した。以後のステップでは、これをフィジカル・スタンバイ・データベースと呼びます。
10-28　Oracle Data Guard 概要および管理
フェイルオーバー後のフラッシュバック・データベースの使用
手順 3 新しいフィジカル・スタンバイ・データベースをマウントする
新しいフィジカル・スタンバイ・データベースで、次の手順を実行します。
1.
フラッシュバック・データベース機能を使用不可にします。これにより、スタンバイ制
御ファイルのリストア後は古くなったフラッシュバック・ログが削除されます。
SQL> ALTER DATABASE FLASHBACK OFF;
2.
スタンバイ制御ファイルを作成し、データベースを停止します。
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS control_file_name;
SQL> SHUTDOWN IMMEDIATE;
3.
オペレーティング・システムのコピー・コマンドを発行し、現行の制御ファイルを新し
いスタンバイ制御ファイルで置換します。
4.
新しいスタンバイ制御ファイルを使用して新しいフィジカル・スタンバイ・データベー
スをマウントします。
SQL> STARTUP MOUNT;
5.
リスナーが実行中であることを確認します。
LSNRCTL STAT list_name;
6.
フラッシュバック・データベースを使用可能にします。
SQL> ALTER DATABASE FLASHBACK ON;
手順 4 新しいフィジカル・スタンバイ・データベースへのログ転送サービスを再開する
新しいスタンバイ・データベースの作成前に、新しいプライマリ・データベースは、リモー
ト宛先への 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 データの受
信を確実に開始するよう、ログ・スイッチを実行し、これが成功したことを確認しま
す。
Data Guard の使用例
10-29
フェイルオーバー後のフラッシュバック・データベースの使用
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR, SRL
2> FROM V$ARCHIVE_DEST_STATUS;
新しいスタンバイ・データベースで、ログ転送サービスが 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 DISCONNECT;
■
リアルタイム適用を開始する場合
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> USING CURRENT LOGFILE DISCONNECT;
障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始
めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の（障害発
生前の）ロールに推移できます。詳細は、7-12 ページの「フィジカル・スタンバイ・データ
ベースが関与するスイッチオーバー」を参照してください。
10-30　Oracle Data Guard 概要および管理
フェイルオーバー後のフラッシュバック・データベースの使用
障害が発生したロジカル・データベースのフィジカル・スタンバイ・デー
タベースへの変換
次の手順では、Data Guard 構成ですでにロジカル・スタンバイ・データベースを使用した
フェイルオーバーが実行済で、古いプライマリ・データベースでフラッシュバック・データ
ベースが使用可能にされていることを前提としています。この手順は、古いプライマリ・
データベースを再作成せずに新しいスタンバイ・データベースとして Data Guard 構成に戻
します。
手順 1 古いスタンバイ・データベースがプライマリ・データベースになった SCN を判別する
新しいプライマリ・データベース上で次の問合せを使用して、古いスタンバイ・データベー
スが新しいプライマリ・データベースになった SCN を判別します。
SQL> SELECT VALUE AS BECAME_PRIMARY_SCN FROM DBA_LOGSTDBY_PARAMETERS
2> WHERE NAME = 'END_PRIMARY_SCN';
手順 2 障害の発生したプライマリ・データベースをフラッシュバックする
新しいロジカル・スタンバイ・データベースを作成するには、必要に応じてデータベースを
停止し、古いプライマリ・データベースをマウントし、手順 1 で判別した BECAME_
PRIMARY_SCN の値にフラッシュバックして、データベース・ガードを使用可能にします。
SQL>
SQL>
SQL>
SQL>
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
FLASHBACK DATABASE TO SCN <became_primary_scn>;
ALTER DATABASE GUARD ALL;
手順 3 RESETLOGS オプションでデータベースをオープンします。
SQL> ALTER DATABASE OPEN RESETLOGS;
手順 4 新しいプライマリ・データベースへのデータベース・リンクを作成して SQL Apply
を開始する
SQL>
2>
3>
SQL>
CREATE PUBLIC DATABASE LINK mylink
CONNECT TO system IDENTIFIED BY password
USING 'service_name_of_new_primary_database';
ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY mylink;
これで、ロールの可逆的な推移が完了しました。
障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始
めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の（障害発
生前の）ロールに推移できます。詳細は、7-20 ページの「ロジカル・スタンバイ・データ
ベースが関与するスイッチオーバー」を参照してください。
Data Guard の使用例
10-31
Open Resetlogs 文の発行後のフラッシュバック・データベースの使用
Open Resetlogs 文の発行後のフラッシュバック・データベース
の使用
スタンバイ・データベースがリアルタイム適用を使用している Data Guard 構成で、プライ
マリ・データベースでエラーが発生したとします。この場合、同じエラーがスタンバイ・
データベースにも適用されます。
ただし、フラッシュバック・データベースが使用可能になっている場合、プライマリおよび
スタンバイ・データベースをエラー前の状態に戻せます。これには、ログ適用サービスを再
開する前に、プライマリ・データベースで FLASHBACK DATABASE および OPEN
RESETLOGS 文を発行し、次に同様の FLASHBACK STANDBY DATABASE 文をスタンバイ・
データベースで発行します。（フラッシュバック・データベースが使用可能でない場合、第
3 章および第 4 章で説明されているように、プライマリ・データベースで Point-in-Time リ
カバリが実行された後、スタンバイ・データベースを再作成する必要があります。
）
フィジカル・スタンバイ・データベースのフラッシュバック
次の手順で、プライマリ・データベースで OPEN RESETLOGS 文を発行した後、フィジカ
ル・スタンバイ・データベースの再作成を回避する方法を説明します。
手順 1 RESETLOGS 操作が発生した前の SCN を判別する
プライマリ・データベースで、次の問合せを使用して RESETLOGS 操作がプライマリ・デー
タベースで発生したよりも 2 つ前のシステム変更番号（SCN）の値を取得します。
SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE;
手順 2 スタンバイ・データベースの現行の SCN を取得する
スタンバイ・データベースで、次の問合せを使用して現行の SCN を取得します。
SQL> SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE;
手順 3 データベースをフラッシュバックする必要があるかどうかを判別する
■
CURRENT_SCN の値が <resetlogs_change# - 2> の値より大きい場合、次の文を発行してス
タンバイ・データベースをフラッシュバックします。
SQL> FLASHBACK STANDBY DATABASE TO SCN <resetlogs_change# -2>;
■
CURRENT_SCN の値が <resetlogs_change# - 2> の値より小さい場合、手順 4 に進みます。
スタンバイ・データベースの SCN がプライマリ・データベースの SCN より大幅に小さ
い場合、ログ適用サービスは停止せずに OPEN RESETLOGS 文中も継続して動作できま
す。この場合、ログ適用サービスは REDO データ内の OPEN RESETLOGS 文に到達して
も停止しないため、データベースのフラッシュバックは不要です。
10-32　Oracle Data Guard 概要および管理
Open Resetlogs 文の発行後のフラッシュバック・データベースの使用
手順 4 ログ適用サービスを再開する
■
REDO Apply をフィジカル・スタンバイ・データベースで開始する場合
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
■
SQL Apply をロジカル・スタンバイ・データベースで開始する場合
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
スタンバイ・データベースはプライマリ・データベースから REDO を受信し適用できます。
ロジカル・スタンバイ・データベースのフラッシュバック
次の手順で、プライマリ・データベースで OPEN RESETLOGS 文を発行した後、ロジカル・
スタンバイ・データベースの再作成を回避する方法を説明します。
手順 1 プライマリ・データベースをフラッシュバックする
プライマリ・データベースで次の SQL 文を実行し、データベースをフラッシュバックし、
RESETLOGS オプションでオープンします。
SQL> FLASHBACK DATABASE TO TIMESTAMP <timestamp you want to flash back to>;
SQL> ALTER DATABASE OPEN RESETLOGS;
手順 2 プライマリ・データベースの SCN を判別する
プライマリ・データベースで、次の問合せを使用して RESETLOGS 操作がプライマリ・デー
タベースで発生したよりも 2 つ前のシステム変更番号（SCN）の値を取得します。
SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE;
手順 3 SQL Apply を停止する
ロジカル・スタンバイ・データベースで、SQL Apply を停止します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> SELECT APPLIED_SCN FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN が <resetlogs_change#-2> の値より小さい場合、スタンバイ・データベースを
フラッシュバックする必要はないため、手順 6 に進みます。SQL Apply が遅延して動作して
いる場合、このようになります。それ以外の場合、手順 4 に従ってスタンバイ・データベー
スをフラッシュバックします。
Data Guard の使用例
10-33
Open Resetlogs 文の発行後のフラッシュバック・データベースの使用
手順 4 ロジカル・スタンバイ・データベースをフラッシュバックする
次の SQL 文を発行して、プライマリ・データベースのフラッシュバックに使用したのと同
じ時点にロジカル・スタンバイ・データベースをフラッシュバックします。
SQL>
SQL>
SQL>
SQL>
SQL>
SHUTDOWN;
STARTUP MOUNT EXCLUSIVE;
FLASHBACK DATABASE TO TIMESTAMP <time of primary database flashback>;
ALTER DATABASE OPEN READ ONLY;
SELECT APPLIED_SCN FROM DBA_LOGSTDBY_PROGRESS;
手順 5 RESETLOGS オプションでロジカル・スタンバイ・データベースをオープンする
RESETLOGS オプションでロジカル・スタンバイ・データベースをオープンします。
SQL> SHUTDOWN;
SQL> STARTUP MOUNT EXCLUSIVE;
SQL> ALTER DATABASE OPEN RESETLOGS;
手順 6 プライマリ・データベースの現行のログをアーカイブする
ログ・スイッチを実行します。
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
手順 7 SQL Apply を開始する
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
10-34　Oracle Data Guard 概要および管理
タイム・ラグのあるフィジカル・スタンバイ・データベースの使用
タイム・ラグのあるフィジカル・スタンバイ・データベースの
使用
ログ適用サービスがスタンバイ・データベースで実行されている場合、デフォルトでは、
REDO データはアーカイブ・ログ・ファイルに書き込まれて適用されるか、リアルタイム適
用が使用可能であれば、REDO はプライマリ・データベースからの送信時にスタンバイ・
データベースへ書き込まれます。ただし、プライマリ・サイトのオンライン REDO ログ・
ファイルのアーカイブとスタンバイ・サイトのアーカイブ REDO ログ・ファイルの適用の
間にタイム・ラグを作成することが必要な場合があります。タイム・ラグによって、プライ
マリ・サイトからスタンバイ・サイトへ破損したまたは誤ったデータが送られてもスタンバ
イ・データベースを保護できます。
たとえば、毎晩プライマリ・データベースでバッチ・ジョブを実行するとします。誤って
バッチ・ジョブを 2 回実行してしまい、しかも 2 回の実行が完了するまでその誤操作に気づ
かなかったとします。理想的には、バッチ・ジョブを開始する前の状態までデータベースを
ロールバックする必要があります。タイム・ラグのあるスタンバイ・データベースを持つプ
ライマリ・データベースを使用すると、リカバリに役立ちます。タイム・ラグのあるスタン
バイ・データベースにフェイルオーバーして、それを新規のプライマリ・データベースとし
て使用できます。
タイム・ラグのあるスタンバイ・データベースを作成するには、プライマリ・データベース
の初期化パラメータ・ファイルにある LOG_ARCHIVE_DEST_n 初期化パラメータの DELAY
属性を使用します。
注意 : リアルタイム適用が使用可能な宛先に遅延を定義した場合、その
遅延は無視されます。
REDO データは通常どおりプライマリ・データベースからスタンバイ・データベースに自動
転送され、アーカイブ REDO ログ・ファイル（実装されている場合は、スタンバイ REDO
ログ・ファイルにも）に書き込まれますが、ログ・ファイルはすぐにはスタンバイ・データ
ベースに適用されません。ログ・ファイルが適用されるのは、指定した時間が経過した後で
す。
この例では 4 時間のタイム・ラグが採用されています。この例に含まれる項目は、次のとお
りです。
■
フィジカル・スタンバイ・データベースでのタイム・ラグの設定
■
タイム・ラグのあるフィジカル・スタンバイ・データベースへのフェイルオーバー
■
タイム・ラグのあるフィジカル・スタンバイ・データベースへのスイッチオーバー
この例では、読者が通常のスタンバイ・データベースの作成手順を理解していることを前提
にしています。したがって、この例で示す手順では詳細を省略しています。フィジカル・ス
タンバイ・データベースの作成の詳細は、第 3 章を参照してください。
Data Guard の使用例
10-35
タイム・ラグのあるフィジカル・スタンバイ・データベースの使用
フィジカル・スタンバイ・データベースでのタイム・ラグの設定
タイム・ラグのあるフィジカル・スタンバイ・データベースを作成するには、プライマリ・
データベースの 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-5 ページの「アーカイブ REDO ログ・ファイルの適用に対するタイム・ディレイの指定」
を参照してください。
タイム・ラグのあるフィジカル・スタンバイ・データベースへのフェイル
オーバー
アーカイブ REDO ログ・ファイルの適用を遅延するように構成したスタンバイ・データ
ベースは、プライマリ・データベースでのユーザーのミスやデータ破損のリカバリに使用で
きます。ほとんどの場合は、タイム・ディレイが設定されているスタンバイ・データベース
を問い合せて、プライマリ・データベースの修正（誤って削除した表の内容のリカバリな
ど）に必要なデータを取得できます。プライマリ・データベースの被害が不明な場合やプラ
イマリ・データベースの修正にかなりの時間が必要な場合は、タイム・ディレイが設定され
ているスタンバイ・データベースへのフェイルオーバーも考慮できます。
不注意によって、バックアップ・ファイルがプライマリ・データベースに 2 回適用され、プ
ライマリ・データベースの修正にかなりの時間が必要であると仮定します。ここでは、アー
カイブ REDO ログ・ファイルの適用が遅延されているフィジカル・スタンバイ・データ
ベースへのフェイルオーバーを選択します。これによって、スタンバイ・データベースを、
問題が発生する以前の時点のプライマリ・ロールに推移させますが、一部のデータは消失す
ることになります。処理の手順は、次のとおりです。
1.
タイム・ディレイが設定されているフィジカル・スタンバイ・データベースで適切な
SQL 文を発行することで、フェイルオーバーを開始します。
SQL>
SQL>
SQL>
SQL>
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE SKIP STANDBY LOGFILE;
SHUTDOWN IMMEDIATE;
STARTUP
ACTIVATE 文は、スタンバイ・データベースをプライマリ・ロールに即時に推移させ、
スタンバイ・ロケーションに存在している可能性のある他の REDO データの適用は行
10-36　Oracle Data Guard 概要および管理
タイム・ラグのあるフィジカル・スタンバイ・データベースの使用
いません。この文を使用する場合は、スタンバイ・ロケーションでのデータ消失のコス
トと、プライマリ・データベースの完全修正に必要な停止時間の延長のバランスを注意
深く調整する必要があります。
2.
この新しいプライマリ・データベースのコピーから、構成内にある他のすべてのスタン
バイ・データベースを再作成します。
タイム・ラグのあるフィジカル・スタンバイ・データベースへのスイッチ
オーバー
スタンバイ・サイトが使用可能になると、REDO データはすべてそこに転送されます。した
がって、タイム・ディレイがスタンバイ・データベースに指定されている場合でも、SQL 文
ALTER DATABASE RECOVER MANAGED STANDBY を使用して遅延を無視することで、スタ
ンバイ・データベースを最新の状態にできます。
注意 : 論理的なエラーのリカバリには、スイッチオーバーではなく、
フェイルオーバーを実行する必要があります。
次の手順に従って、タイム・ディレイが設定されたフィジカル・スタンバイ・データベース
（タイム・ラグをバイパスする）へのスイッチオーバーを実行する方法を説明します。この
例では、プライマリ・データベースはニューヨークに、スタンバイ・データベースはボスト
ンにあると仮定します。
手順 1 すべてのアーカイブ REDO ログ・ファイルを、タイム・ラグをバイパスしている元
の（タイム・ディレイが設定された）スタンバイ・データベースに適用する
スタンバイ・データベースですべてのアーカイブ REDO ログ・ファイルが適用されるまで、
スイッチオーバーは開始しません。遅延を解除することにより、スタンバイ・データベース
は、アーカイブ REDO ログ・ファイルの適用前に指定した時間が経過するのを待たずに処
理を続行できます。
遅延を解除するには、次の SQL 文を発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY
2> DISCONNECT FROM SESSION THROUGH LAST SWITCHOVER;
手順 2 プライマリ・データベースとスタンバイ・データベースでの読取りまたは更新アク
ティビティを停止する
スイッチオーバーを開始するには、排他的なデータベース・アクセス権限が必要です。ユー
ザーにプライマリおよびスタンバイ・データベースからログオフするように求めるか、
V$SESSION ビューを問い合せてデータベースに接続しているユーザーを識別し、スイッチ
オーバー文を実行する SQL*Plus セッションを除くすべてのオープン・セッションをクロー
ズします。ユーザーの管理の詳細は、『Oracle Database 管理者ガイド』を参照してください。
Data Guard の使用例
10-37
タイム・ラグのあるフィジカル・スタンバイ・データベースの使用
手順 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;
SQL> STARTUP PFILE=Failover.ora;
10-38　Oracle Data Guard 概要および管理
ネットワーク障害のリカバリ
ネットワーク障害のリカバリ
次の手順に従って、ネットワーク障害後のリカバリ方法を説明します。
手順 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:
リスナーがありません。
」であることがわかりました。スタンバイ・サイトでリスナーが起
動されているかどうかを調べる必要があります。リスナーが停止している場合は、起動して
ください。
手順 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';
Data Guard の使用例
10-39
NOLOGGING 句を指定した後のリカバリ
手順 3 カレント・オンライン REDO ログ・ファイルをアーカイブする
プライマリ・データベースで、カレント・オンライン REDO ログ・ファイルをアーカイブ
します。
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
ネットワークが再開され、フィジカル・スタンバイ・データベースで REDO Apply が再開
されると、ログ適用サービスによるアーカイブ・ギャップの自動的な検出と解決が可能とな
ります。
NOLOGGING 句を指定した後のリカバリ
一部の SQL 文には、NOLOGGING 句を指定するオプションがあります。このオプションに
よって、データベースに関する操作をオンライン REDO ログ・ファイルに記録しないよう
に指定できます。ユーザーがこの句を指定しても、REDO レコードはオンライン REDO ロ
グ・ファイルに書き込まれます。ただし、このレコードに関連したデータはありません。こ
れが結果的に、スタンバイ・サイトでのログ適用エラーやデータ・アクセス・エラーの原因
となり、ログ・ファイルの適用の再開で、手動によるリカバリが必要となります。
注意 : この問題を回避するには、CREATE DATABASE または ALTER
DATABASE 文に FORCE LOGGING 句を常に指定することをお薦めします。
『Oracle Database 管理者ガイド』を参照してください。
ロジカル・スタンバイ・データベースのリカバリ手順
ロジカル・スタンバイ・データベースの場合は、SQL Apply で NOLOGGING 句を使用した操
作の REDO ログ・レコードが検出されると、そのレコードはスキップされ、後続のレコー
ドから変更の適用が続行されます。その後、NOLOGGING を実際に使用して更新されたレ
コードの 1 つにアクセスしようとすると、
「ORA-01403 データが見つかりません。
」エラー
が戻されます。
NOLOGGING 句を指定した後のリカバリには、9-10 ページの「ロジカル・スタンバイ・デー
タベースでの表の追加または再作成」に説明されているように、プライマリ・データベース
から 1 つ以上の表を再作成します。
注意 : 通常、NOLOGGING 句の使用はお薦めしません。また、プライマ
リ・データベース内の特定の表で NOLOGGING 句を使用する操作が実行さ
れることが事前にわかっている場合は、DBMS_LOGSTDBY.SKIP プロシー
ジャを使用して、これらの表に関連付けられている SQL 文をロジカル・
スタンバイ・データベースに適用しないようにできます。
10-40　Oracle Data Guard 概要および管理
NOLOGGING 句を指定した後のリカバリ
フィジカル・スタンバイ・データベースのリカバリ手順
スタンバイ・サイトにコピーされたアーカイブ REDO ログ・ファイルがフィジカル・スタ
ンバイ・データベースに適用されると、データ・ファイルの一部が使用不可能となり、リカ
バリ不能のマークが付けられます。フィジカル・スタンバイ・データベースにフェイルオー
バーするか、読取り専用アクセスでスタンバイ・データベースをオープンし、
UNRECOVERABLE のマークが付けられたブロックの範囲を読み取ろうとすると、次のような
エラー・メッセージが表示されます。
ORA-01578: Oracle データ・ブロックに障害が発生しました ( ファイル番号 1、ブロック番号 2521)
ORA-01110: データファイル 1: '/oracle/dbs/stdby/tbs_1.dbf'
ORA-26040: データ・ブロックが NOLOGGING オプションを使用してロードされました。
NOLOGGING 句が指定された後でリカバリするには、記録されていないデータが含まれてい
るデータ・ファイルをプライマリ・サイトからフィジカル・スタンバイ・サイトにコピーす
る必要があります。次の手順に従ってください。
手順 1 コピーするデータ・ファイルを判別する
次の手順に従います。
1.
プライマリ・データベースを問い合せます。
SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;
NAME
UNRECOVERABLE
----------------------------------------------------- ------------/oracle/dbs/tbs_1.dbf
5216
/oracle/dbs/tbs_2.dbf
0
/oracle/dbs/tbs_3.dbf
0
/oracle/dbs/tbs_4.dbf
0
4 rows selected.
2.
スタンバイ・データベースを問い合せます。
SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;
NAME
UNRECOVERABLE
----------------------------------------------------- ------------/oracle/dbs/stdby/tbs_1.dbf
5186
/oracle/dbs/stdby/tbs_2.dbf
0
/oracle/dbs/stdby/tbs_3.dbf
0
/oracle/dbs/stdby/tbs_4.dbf
0
4 rows selected.
3.
プライマリ・データベースの問合せ結果とスタンバイ・データベースの問合せ結果を比
較します。
両方の問合せ結果の UNRECOVERABLE_CHANGE# 列の値を比較します。プライマリ・
データベースの UNRECOVERABLE_CHANGE# 列の値の方が、スタンバイ・データベース
Data Guard の使用例
10-41
NOLOGGING 句を指定した後のリカバリ
の同じ列の値より大きい場合は、データ・ファイルをプライマリ・サイトからスタンバ
イ・サイトへコピーする必要があります。
この例では、tbs_1.dbf データ・ファイルのプライマリ・データベースにある
UNRECOVERABLE_CHANGE# の値の方が大きいので、tbs_1.dbf データ・ファイルを
スタンバイ・サイトへコピーする必要があります。
手順 2 プライマリ・サイトで、スタンバイ・サイトにコピーする必要があるデータ・ファ
イルをバックアップする
次の SQL 文を発行します。
SQL>
SQL>
% cp
SQL>
ALTER TABLESPACE system BEGIN BACKUP;
EXIT;
tbs_1.dbf /backup
ALTER TABLESPACE system END BACKUP;
手順 3 スタンバイ・データベースで、REDO
Apply を再開する
スタンバイ・データベースで、
次の SQL 文を発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM
2>SESSION;
REDO Apply を再開しようとすると、次のエラー・メッセージが（通常アラート・ログに）
表示されることがあります。
ORA-00308: アーカイブ・ログ standby1 をオープンできません。
ORA-27037: ファイル・ステータスを取得できません。
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-01547: 警告 : RECOVER は成功しましたが OPEN RESETLOGS が次のエラーを受け取りました。
ORA-01152: ファイル 1 は十分に古いバックアップからリストアされていません。
ORA-01110: データファイル 1: '/oracle/dbs/stdby/tbs_1.dbf'
ORA-00308 エラーが表示され、REDO Apply が自動的に終了しない場合は、別の端末の
ウィンドウから次の文を発行して、リカバリを取り消すことができます。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
これらのエラー・メッセージは、アーカイブ・ギャップ内にある 1 つ以上のログ・ファイル
が正常に適用されなかった場合に戻されます。これらのエラーを受け取った場合は、ギャッ
プを手動で解決し、手順 3 を繰り返します。アーカイブ・ギャップの手動による解決方法に
ついては、5-43 ページの「手動によるアーカイブ・ギャップの判断および解決」を参照して
ください。
10-42　Oracle Data Guard 概要および管理
手動によるアーカイブ・ギャップの解決
リカバリ不能処理後にバックアップが必要かどうかの判断
プライマリ・データベースでリカバリ不能な操作を実行した場合は、次の手順に従って新し
いバックアップ操作が必要かどうかを判断します。
1.
プライマリ・データベースで V$DATAFILE ビューを問い合せて、システム変更番号
システム変更番号
）
、または Oracle データベースが無効な REDO データを生成した最新の時刻を判
（SCN）
別します。
2.
プライマリ・データベースで次の SQL 文を発行して、新たにバックアップを実行する
必要があるかどうかを判断します。
SELECT UNRECOVERABLE_CHANGE#,
TO_CHAR(UNRECOVERABLE_TIME, 'mm-dd-yyyy hh:mi:ss')
FROM
V$DATAFILE;
3.
前の手順での問合せで、データ・ファイルが最後にバックアップされた時刻より後の
データ・ファイル・リカバリ不能時刻が報告された場合は、問題となっているデータ・
ファイルのバックアップを新たに作成します。
V$DATAFILE ビューの詳細は、
『Oracle Database リファレンス』を参照してください。
手動によるアーカイブ・ギャップの解決
アーカイブ・ギャップとは、アーカイブ
REDO ログ・ファイルの特定の範囲を指します。
アーカイブ・ギャップ
この範囲は、プライマリ・データベースで生成される次のアーカイブ REDO ログ・ファイ
ルをスタンバイ・データベースに適用できないときは常に発生します。この項は、次の項目
で構成されています。
■
アーカイブ・ギャップの発生原因
■
アーカイブ・ギャップが存在するかどうかの判断
■
スタンバイ・サイトへのアーカイブ・ギャップ・ログ・ファイルの手動による転送
■
スタンバイ・データベースへのアーカイブ・ギャップ・ログ・ファイルの手動による適用
注意 : 通常、アーカイブ・ギャップは手動操作を行うことなく自動的に
解決されます。ログ適用サービスがアーカイブ REDO ログ・ファイル内に
あるギャップを自動的にリカバリする方法の詳細は、5-40 ページの「アー
カイブ・ギャップの管理」を参照してください。
Data Guard の使用例
10-43
手動によるアーカイブ・ギャップの解決
アーカイブ・ギャップの発生原因
アーカイブ・ギャップは、プライマリ・データベースでカレント・オンライン REDO ログ・
ファイルがローカルにアーカイブされても、REDO データがスタンバイ・サイトにアーカイ
ブされなかった場合は常に発生する可能性があります。スタンバイ・データベースにはロ
グ・ファイルを順序番号順に適用する必要があるため、メディア・リカバリは、最初の欠落
ログ・ファイルに遭遇すると停止します。
アーカイブ・ギャップは次の状況で発生することがあります。
■
スタンバイ・データベースの作成
■
プライマリ・データベースがオープンしている間のスタンバイ・データベースの停止
■
アーカイブ・ログ・ファイルの転送を妨げるネットワーク障害
スタンバイ・データベースの作成
アーカイブ・ギャップは、スタンバイ・データベースを古いバックアップから作成すると発
生します。たとえば、スタンバイ・データベースが、ログ・ファイル 100 の変更を含むバッ
クアップから作成されているとします。このときプライマリ・データベースに、現在ログ・
ファイル 150 の変更が含まれているとすると、スタンバイ・データベースは、ログ・ファイ
ル 101 からログ・ファイル 150 までの適用を要求します。オープン・データベースのホッ
ト・バックアップからスタンバイ・データベースを生成する場合も、通常アーカイブ・
ギャップが発生します。
たとえば、図 10-7 の使用例を想定します。
10-44　Oracle Data Guard 概要および管理
手動によるアーカイブ・ギャップの解決
図 10-7 アーカイブ・ギャップ内にあるアーカイブ REDO ログ・ファイルの手動リカバリ
次の手順を実行します。
1.
プライマリ・データベースのホット・バックアップを取得します。
2.
ネットワーク・ファイルを構築している時間 t で、プライマリはログ・ファイル順序の
4 および 5 をアーカイブします。
3.
時間 t + 1 で、スタンバイ・インスタンスを起動します。
4.
プライマリは、REDO ログ・ファイル順序 6、7 および 8 をプライマリ・サイトにアー
カイブし、REDO をスタンバイ・サイトに転送します。
Data Guard の使用例
10-45
手動によるアーカイブ・ギャップの解決
アーカイブ REDO ログ・ファイルの順序 4 および 5 はこれでアーカイブ・ギャップの一部
となり、これらのログ・ファイルはスタンバイ・データベースに適用する必要があります。
プライマリ・データベースがオープンしている間のスタンバイ・データ
ベースの停止
メンテナンス問題を解決するため、スタンバイ・データベースの停止が必要になることがあ
ります。たとえば、プライマリ・データベース内で MAXDATAFILE のような制御ファイル・
パラメータを変更するときには、スタンバイ・データベースを停止する必要があります。
アーカイブ・ギャップの発生を避けるために、次のルールを実行します。
■
■
プライマリ・データベースを起動する前にスタンバイ・データベースとリスナーを起動
します。
スタンバイ・データベースを停止する前にプライマリ・データベースを停止します。
これら 2 つのルールに違反すると、プライマリ・データベースがオープンし、アーカイブを
実行しているときにスタンバイ・データベースが停止します。結果として、アーカイブ・
ギャップが発生します。
注意 : スタンバイ・サイトが、プライマリ初期化パラメータ・ファイル
の LOG_ARCHIVE_DEST_n パラメータの 1 つにおいて MANDATORY と指定
されている場合は、スタンバイ・データベースを停止する前に、それを動
的に OPTIONAL に変更します。これを行わないと、プライマリ・データ
ベースはオンライン REDO ログ・ファイルをアーカイブできないため停
止します。
アーカイブ・ログ・ファイルの転送を妨げるネットワーク障害
Data Guard 環境をメンテナンスしているときにネットワークが停止すると、プライマリ・
データベースはディスクへのアーカイブを継続しますが、スタンバイ・サイトへのアーカイ
ブは実行できません。この状況では、アーカイブ REDO ログ・ファイルは通常どおり、プラ
イマリ・サイトに蓄積されますが、スタンバイ・データベースはこれらのログ・ファイルを
認識できません。
関連項目 :
■
■
スタンバイ・アーカイブにおける OPTIONAL 属性および MANDATORY 属性の重要性の詳
細は、5-36 ページの「オンライン REDO ログ・ファイルの再利用」を参照してくださ
い。
関連する使用例については、
「ネットワーク障害のリカバリ」を参照してください。
10-46　Oracle Data Guard 概要および管理
手動によるアーカイブ・ギャップの解決
アーカイブ・ギャップが存在するかどうかの判断
アーカイブ・ギャップが存在するかどうかを判断するには、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
Data Guard の使用例
10-47
手動によるアーカイブ・ギャップの解決
スタンバイ・サイトへのアーカイブ・ギャップ・ログ・ファイルの手動に
よる転送
アーカイブ・ギャップ内にあるログ・ファイル順序番号の取得後、プライマリ・サイトの
V$ARCHIVED_LOG ビューを問い合せて、ファイル名を取得できます。スタンバイ・サイト
のアーカイブ REDO ログ・パス名は、スタンバイ初期化パラメータ・ファイルの
STANDBY_ARCHIVE_DEST パラメータおよび LOG_ARCHIVE_FORMAT パラメータによって
生成されます。
スタンバイ・データベースがプライマリ・データベースと同じサイトにある場合、またはス
タンバイ・データベースがプライマリ・データベースと異なるディレクトリ構造を持つリ
モート・サイトにある場合、スタンバイ・サイトのログ・ファイルのパス名は、プライマ
リ・データベースでアーカイブされたログ・ファイルのパス名と同じにはなりません。
REDO データをスタンバイ・サイトに転送する前に、スタンバイ・サイトでアーカイブ
REDO ログ・ファイルの正しいパス名を判別してください。
スタンバイ・サイトにアーカイブ・ギャップ内にあるログ・ファイルをコ
ピーする方法
1.
以前取得したアーカイブ・ギャップ・ログ・ファイルのリストを見直します。たとえ
ば、次のアーカイブ・ギャップがあると想定します。
THREAD#
LOW_SEQUENCE#
---------- ------------1
460
2
202
3
100
HIGH_SEQUENCE#
-------------463
204
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.arc
4 rows selected
スレッド 2 と 3 について、同様の問合せを実行します。
10-48　Oracle Data Guard 概要および管理
手動によるアーカイブ・ギャップの解決
3.
スタンバイ・サイトで、スタンバイ初期化パラメータ・ファイル内の STANDBY_
ARCHIVE_DEST および LOG_ARCHIVE_FORMAT の設定を見直します。たとえば、次を
発見したと想定します。
STANDBY_ARCHIVE_DEST = /standby/arc_dest/
LOG_ARCHIVE_FORMAT = log_%t_%s_d.arc
これらのパラメータの設定から、スタンバイ・サイトのアーカイブ REDO ログ・ファ
イルのファイル名を判別できます。
4.
プライマリ・サイトで、アーカイブ・ギャップ・ログ・ファイルをプライマリ・サイト
からスタンバイ・サイトへコピーし、ログ・ファイルの名前を STANDBY_ARCHIVE_
DEST および LOG_ARCHIVE_FORMAT の値に応じて変更します。たとえば、次の copy
コマンドを入力して、スレッド 1 に必要なアーカイブ・ギャップ・ログ・ファイルをコ
ピーします。
%
%
%
%
cp
cp
cp
cp
/primary/thread1_dest/arcr_1_460.arc
/primary/thread1_dest/arcr_1_461.arc
/primary/thread1_dest/arcr_1_462.arc
/primary/thread1_dest/arcr_1_463.arc
/standby/arc_dest/log_1_460.arc
/standby/arc_dest/log_1_461.arc
/standby/arc_dest/log_1_462.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 ディレクトリにあるた
め、
「スタンバイ・データベースへのアーカイブ・ギャップ・ログ・ファイルの手動による
適用」に進んで、アーカイブ・ギャップ・ログ・ファイルをスタンバイ・データベースに適
用できます。6-9 ページの「V$ARCHIVED_LOG 固定ビューへのアクセス」および第 14 章
の V$ARCHIVED_LOG ビューも参照してください。
Data Guard の使用例
10-49
手動によるアーカイブ・ギャップの解決
スタンバイ・データベースへのアーカイブ・ギャップ・ログ・ファイルの
手動による適用
アーカイブ・ギャップ内のログ・ファイルをスタンバイ・サイトにコピーした後、RECOVER
AUTOMATIC 文を使用してそれらを適用できます。
アーカイブ・ギャップ内にあるアーカイブ REDO ログ・ファイルを適用す
る方法
1.
スタンバイ・データベースを起動してマウントします（まだマウントされていない場
合）
。たとえば、次のように入力します。
SQL> STARTUP MOUNT PFILE=/oracle/admin/pfile/initSTBY.ora
2.
AUTOMATIC オプションを使用してデータベースをリカバリします。
SQL> ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE;
AUTOMATIC オプションは、リカバリ操作の継続に必要な次のアーカイブ REDO ログ・
ファイルの名前を自動的に生成します。
利用可能なログ・ファイルをリカバリすると、Oracle データベースは現在存在しないロ
グ・ファイルの名前の入力を促します。たとえば、次のように表示されます。
ORA-00308: アーカイブ・ログ /oracle/standby/standby_logs/arcr_1_540.arc をオープンでき
ません。
ORA-27037: ファイル・ステータスを取得できません。
SVR4 Error: 2: No such file or directory
Additional information: 3
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
3.
Oracle データベースで利用可能なログ・ファイルの適用後、CTRL+C キーによってリカ
バリを取り消します。
SQL> <CTRL/C>
Media recovery cancelled.
リカバリ取消し後に出力される次のエラー・メッセージは許容できるもので、問題はあ
りません。
ORA-01547:
ORA-01194:
ORA-01110:
ORA-01112:
4.
警告 : RECOVER は成功しましたが OPEN RESETLOGS が次のエラーを受け取りました。
ファイル 1 は一貫した状態にするためにさらにリカバリが必要です。
データファイル 1: 'some_filename'
メディア・リカバリが開始されていません
欠落しているログ・ファイルを手動で適用した後、次のようにしてスタンバイ・データ
ベースでログ適用サービスを再開できます。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
10-50　Oracle Data Guard 概要および管理
OMF または ASM を使用するスタンバイ・データベースの作成
OMF または ASM を使用するスタンバイ・データベースの作成
第 3 章および第 4 章では、フィジカルおよびロジカル・スタンバイ・データベースの作成方
法を説明しました。この項では、プライマリ・データベースで Oracle Managed Files
（OMF）または Automatic Storage Management（ASM）を使用する場合に実行する必要の
ある追加手順を説明し、これらの章を補完します。
注意 : この項の説明は、読者がすでにフィジカル・スタンバイ・データ
ベースの作成方法を理解しており、Recovery Manager、OMF および
ASM 機能に習熟していることを前提としています。詳細は、次の資料を参
照してください。
■
■
■
フィジカルおよびロジカル・スタンバイ・データベースの作成方法
は、第 3 章、第 4 章および付録 D を参照してください。
OMF および ASM の詳細は、
『Oracle Database 管理者ガイド』を参照
してください。
Recovery Manager の詳細は、
『Oracle Database バックアップおよびリ
カバリ・アドバンスト・ユーザーズ・ガイド』および『Oracle
Database Recovery Manager リファレンス』を参照してください。
スタンバイ・データベースを作成する前に、次の準備作業を実行します。
1.
プライマリ・データベースで強制ロギングを使用可能にします。
2.
プライマリ・データベースでアーカイブを使用可能にします。
3.
プライマリ・データベースで必要な初期化パラメータをすべて設定します。
4.
スタンバイ・データベース用に初期化パラメータ・ファイルを作成します。
5.
プライマリ・データベースが OMF を使用するよう構成されている場合、スタンバイ・
データベースも OMF を使用するよう構成することをお薦めします。これを行うには、
DB_CREATE_FILE_DEST および DB_CREATE_ONLINE_LOG_DEST_n 初期化パラメータ
に適切な値を設定します。プライマリおよびスタンバイ・データベースの両方で同じ
ディスク・グループ名が使用されている場合、メンテナンスや後のロールの推移が簡易
化されます。
6.
STANDBY_FILE_MANAGEMENT 初期化パラメータに AUTO を設定します。
7.
スタンバイ・データベースに接続するために、必要に応じて Oracle Net を構成します。
8.
スタンバイ・データベース用のリモート・ログイン・パスワード・ファイルを作成しま
す。プライマリ・データベースと同じパスワードを SYS アカウントに使用します。
9.
制御ファイルをマウントせずにスタンバイ・データベース・インスタンスを起動しま
す。
Data Guard の使用例
10-51
OMF または ASM を使用するスタンバイ・データベースの作成
スタンバイ・データベースを作成するには、次の作業を実行します。
1.
スタンバイ・データベースで ASM を使用する場合、スタンバイ・データベース・シス
テムに ASM インスタンスが存在していなければ、インスタンスを作成します。
2.
Recovery Manager の BACKUP コマンドを使用して、プライマリ・データベースのデー
タ・ファイル、アーカイブ・ログ・ファイルおよびスタンバイ制御ファイルのコピーが
含まれているバックアップ・セットを作成します。
3.
Recovery Manager の DUPLICATE … FOR STANDBY コマンドを使用して、バックアッ
プ・セットのデータ・ファイル、アーカイブ REDO ログ・ファイルおよびスタンバイ
制御ファイルをスタンバイ・データベースの格納場所にコピーします。
DUPLICATE … FOR STANDBY コマンドは、スタンバイ・インスタンスでの実際のデー
タ移動を実行します。バックアップ・セットがテープ上に存在する場合、スタンバイ・
インスタンスがバックアップ・セットを読み取れるよう、メディア・マネージャを構成
する必要があります。バックアップ・セットがディスク上に存在する場合、バックアッ
プ・ピースはスタンバイ・インスタンスによって読み取れる必要があります。これに
は、プライマリ・パス名を NFS を介して取得可能にするか、これらをスタンバイ・シ
ステムにコピーし、Recovery Manager の CATALOG BACKUPPIECE コマンドを使用し
てバックアップ・ピースをリストア前にカタログに追加します。
これらの手順を完了した後、3-17 ページの「フィジカル・スタンバイ・データベースが正し
く実行されているかどうかの確認」の手順を実行してフィジカル・スタンバイ・データベー
スの構成を確認します。
ロジカル・スタンバイ・データベースを作成するには、第 4 章で説明されているスタンバ
イ・データベースの作成プロセスを実行しますが、次の点を変更します。
1.
ロジカル・スタンバイ・データベースの場合、DB_CREATE_FILE_DEST パラメータを
設定しても、OMF ファイル名を強制的に作成しません。ただし、このパラメータをプラ
イマリ・データベースで設定する場合、スタンバイ・データベースでも設定する必要が
あります。
2.
プライマリ・システムでロジカル・スタンバイ制御ファイルを作成した後、このファイ
ルをスタンバイ・システムにコピーするために、オペレーティング・システムのコマン
ドを使用しないでください。かわりに Recovery Manager の RESTORE CONTROLFILE
コマンドを使用して、ロジカル・スタンバイ制御ファイルのコピーをスタンバイ・シス
テムにリストアします。
3.
プライマリ・データベースで OMF ファイルを使用する場合、スタンバイ・データベー
スに作成された新しい OMF ファイルをスタンバイ・データベース制御ファイルが使用
するよう、Recovery Manager を使用してスタンバイ・データベース制御ファイルを更
新します。この操作を実行するには、次の例に示すように、スタンバイ・データベース
にのみ接続します。
> RMAN TARGET sys/oracle@lstdby
RMAN> CATALOG START WITH '+stby_diskgroup';
RMAN> SWITCH DATABASE TO COPY;
10-52　Oracle Data Guard 概要および管理
OMF または ASM を使用するスタンバイ・データベースの作成
これらの手順を完了した後、4-15 ページの「ロジカル・スタンバイ・データベースの起動」
の手順を実行してロジカル・スタンバイ・データベースの起動、リカバリおよび検証を行い
ます。
Data Guard の使用例
10-53
OMF または ASM を使用するスタンバイ・データベースの作成
10-54　Oracle Data Guard 概要および管理
第 II 部
リファレンス
この部では、Oracle Data Guard のスタンバイ・データベースの特長について参考となる資
料を提供します。詳細は、Oracle Database 10g のマニュアルを参照してください。
この部は、次の章で構成されています。
■
第 11 章「初期化パラメータ」
■
第 12 章「LOG_ARCHIVE_DEST_n パラメータの属性」
■
第 13 章「Data Guard に関連する SQL 文」
■
第 14 章「Oracle Data Guard に関連するビュー」
11
初期化パラメータ
この章では、Data Guard 環境のデータベースに影響を与える初期化パラメータについて説
明します。
表 11-1 に初期化パラメータのリストと、そのパラメータがプライマリ・データベース・ロー
ル、スタンバイ・データベース・ロール、あるいはその両方のいずれに適用されるかを示し
ます。また、これらのパラメータを Data Guard 環境で設定する場合に固有の注意点および
推奨事項も記載します。初期化パラメータに関する完全な情報は、
『Oracle Database リファ
レンス』に記載されています。これには、更新初期化パラメータの設定方法として、ALTER
SYSTEM SET または ALTER SESSION 文（たとえば ALTER SYSTEM SET LOG_ARCHIVE_
TRACE）を発行する方法および初期化パラメータ・ファイルを編集する方法の説明も含まれ
ています。初期化パラメータの設定方法の詳細は、オペレーティング・システム固有の
Oracle マニュアルを参照してください。
初期化パラメータ
11-1
表 11-1 Data Guard 構成内のインスタンスの初期化パラメータ
パラメータ
プライマリ・ スタンバイ・
ロール
ロール
注意点および推奨事項
ARCHIVE_LAG_TARGET = seconds
可
不可
COMPATIBLE = release_number
可
ロジカル
および
フィジカル
CONTROL_FILE_RECORD_KEEP_
TIME = number_of_days
可
ロジカル
オプション。このパラメータを使用して、指定さ
および
れた日数（0 ～ 365）内に、制御ファイル内
フィジカル （アーカイブ REDO ログ・ファイルなどの必要な
情報が含まれている）の再使用可能レコードが上
書きされないようにします。5-38 ページの「制御
ファイルのサイズ拡大と再利用の計画」を参照。
CONTROL_FILES = 'control_file_name' 可
, control_file_name', '...')
11-2　Oracle Data Guard 概要および管理
ロジカル
および
フィジカル
オプション。指定秒数の経過後、ログ・スイッチ
を強制します。
Data Guard では 9.2.0.1.0 以上の値を必要としま
す。Oracle Database 10g の新機能を使用するに
は、10.0.0.0 以上に設定してください。同じ値を
プライマリ・データベースおよびスタンバイ・
データベースに指定します。値が異なる場合は、
ログ転送サービスが REDO データをプライマ
リ・データベースからスタンバイ・データベース
に転送できないことがあります。3-9 ページの
「スタンバイ・データベース用の初期化パラメー
タ・ファイルの準備」および 4-12 ページの「ロ
ジカル・スタンバイ・データベース用の初期化パ
ラメータ・ファイルの準備」の例を参照。
必須。1 つ以上の制御ファイルのパス名とファイ
ル名を指定します。制御ファイルはすでにデータ
ベースに存在している必要があります。 2 つの制
御ファイルを使用することをお薦めします。現行
の制御ファイルの別のコピーが存在していれば、
問題のない制御ファイルを問題のある制御ファイ
ルの場所にコピーした後、容易にインスタンスを
再開できます。3-9 ページの「スタンバイ・デー
タベース用の初期化パラメータ・ファイルの準
備」および 4-12 ページの「ロジカル・スタンバ
イ・データベース用の初期化パラメータ・ファイ
ルの準備」の例を参照。
表 11-1 Data Guard 構成内のインスタンスの初期化パラメータ（続き）
構成内のインスタンスの初期化パラメータ（続き）
パラメータ
プライマリ・ スタンバイ・
ロール
ロール
注意点および推奨事項
DB_FILENAME_CONVERT = (location_ 不可
of_primary_database_datafile' ,
'location_of_standby_database_datafile_
name' , '...'
ロジカル
および
フィジカル
スタンバイ・データベースがプライマリ・データ
ベースと同じシステムにある場合、またはデー
タ・ファイルが格納されているスタンバイ・シス
テムのディレクトリがプライマリ・システムと異
なる場合は必須。このパラメータには、文字列を
ペアで指定する必要があります。最初の文字列
は、プライマリ・データベース・ファイル名の中
で検索される文字列です。その文字列が一致する
と、スタンバイ・データベース・ファイル名を構
成する 2 番目の文字列に置き換えられます。複数
のペアのファイル名を指定できます。例 3-2 も参
照。
DB_FILES = number_of_database_
files_that_can_be_open_for_this_
database
可
ロジカル
および
フィジカル
オプション。同じデータベース・ファイル数をプ
ライマリ・データベースおよびスタンバイ・デー
タベースに指定します。
DB_NAME = 8-character_database_name 可
ロジカル
および
フィジカル
必須。フィジカル・スタンバイ・データベースの
場合、プライマリ・データベースの場合と同じ
DB_NAME を指定します。ロジカル・スタンバ
イ・データベースの場合、DBNEWID ユーティ
リティを使用して、プライマリ・データベースと
異なる名前を指定するよう、DB_NAME をリセッ
トします。4-15 ページの「ロジカル・スタンバ
イ・データベースの起動」を参照。
DB_UNIQUE_NAME = unique_service_
provider_name_for_this_database
可
ロジカル
および
フィジカル
リモート宛先の場合は必須。このデータベースの
一意の名前を指定します。プライマリ・データ
ベースとスタンバイ・データベースのロールが交
代しても、この名前は変更されません。DB_
UNIQUE_NAME パラメータのデフォルトは、DB_
NAME パラメータの値です。
FAL_CLIENT = Oracle_Net_service_
name
可
フィジカル
のみ
FAL_SERVER パラメータが指定されている場合
は必須。FAL サーバー（通常はプライマリ・
データベース）が FAL クライアント（スタンバ
イ・データベース）への接続に使用する Oracle
Net サービス名を指定します。5-41 ページの
「フェッチ・アーカイブ・ログ（FAL）プロセス
を使用したアーカイブ・ギャップの解決」を参
照。
初期化パラメータ
11-3
表 11-1 Data Guard 構成内のインスタンスの初期化パラメータ（続き）
構成内のインスタンスの初期化パラメータ（続き）
パラメータ
プライマリ・ スタンバイ・
ロール
ロール
注意点および推奨事項
FAL_SERVER = Oracle_Net_service_
name
不可
フィジカル
のみ
FAL_CLIENT パラメータが指定されている場合
は必須。欠落しているアーカイブ REDO ログ・
ファイルをこのスタンバイ・データベースが
フェッチ（要求）できるフェッチ元データベース
の Oracle Net サービス名を 1 つ以上指定します。
5-41 ページの「フェッチ・アーカイブ・ログ
（FAL）プロセスを使用したアーカイブ・ギャッ
プの解決」を参照。
INSTANCE_NAME
可
ロジカル
および
フィジカル
オプション。このパラメータが定義されており、
プライマリ・データベースとスタンバイ・データ
ベースが同じホストに存在する場合は、スタンバ
イ・データベースに対してプライマリ・データ
ベースとは異なる名前を指定します。3-9 ページ
の「スタンバイ・データベース用の初期化パラ
メータ・ファイルの準備」および 4-12 ページの
「ロジカル・スタンバイ・データベース用の初期
化パラメータ・ファイルの準備」の例を参照。
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-24 ページの「一意のプライマリ・データ
ベース名とスタンバイ・データベース名の指定」
を参照。
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-4 ページの「LOG_
ARCHIVE_DEST_n パラメータを使用した宛先の
構成」および第 12 章を参照。
11-4　Oracle Data Guard 概要および管理
表 11-1 Data Guard 構成内のインスタンスの初期化パラメータ（続き）
構成内のインスタンスの初期化パラメータ（続き）
パラメータ
プライマリ・ スタンバイ・
ロール
ロール
注意点および推奨事項
LOG_ARCHIVE_DEST_STATE_n =
{ENABLE|DISABLE|ALTERNATE}
可
ロジカル
および
フィジカル
必須。LOG_ARCHIVE_DEST_STATE_n パラメー
タを指定して、指定された（または代替の）宛先
へのログ転送サービスによる REDO データの転
送を可能または不可に設定します。各 LOG_
ARCHIVE_DEST_n パラメータに対し、LOG_
ARCHIVE_DEST_STATE_n パラメータを指定し
ます。5-4 ページの「LOG_ARCHIVE_DEST_n パ
ラメータを使用した宛先の構成」および第 12 章
も参照。
LOG_ARCHIVE_FORMAT=log%d_%t_
%s_%r.arc
可
ロジカル
および
フィジカル
STANDBY_ARCHIVE_DEST パラメータを指定し
ている場合は必須。これらのパラメータは連結さ
れ、スタンバイ・データベースに完全修飾された
アーカイブ REDO ログ・ファイル名を生成しま
す。5-34 ページの「アーカイブ REDO ログ・
ファイルの代替ディレクトリ位置の指定」も参
照。
LOG_ARCHIVE_LOCAL_FIRST
=[TRUE|FALSE]
可
不可
オプション。オンライン REDO ログ・ファイル
が 1 つ以上のローカル宛先に正常にアーカイブさ
れた後（TRUE）、またはオンライン REDO ログ・
ファイルがローカル宛先にアーカイブされるのと
同時（FALSE）の、いずれの時点でアーカイバ・
プロセス（ARCn）が転送を実行するかを制御す
る場合に指定します。
5-11 ページの「アーカイバ・プロセス（ARCn）
を使用した REDO データのアーカイブ」も参照。
LOG_ARCHIVE_MAX_PROCESSES
=integer
可
ロジカル
および
フィジカル
オプション。Oracle ソフトウェアが最初に起動す
るアーカイバ・プロセスの数（1 ～ 10）を指定し
ます。
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）については、付録 E で説明されています。
初期化パラメータ
11-5
表 11-1 Data Guard 構成内のインスタンスの初期化パラメータ（続き）
構成内のインスタンスの初期化パラメータ（続き）
パラメータ
プライマリ・ スタンバイ・
ロール
ロール
注意点および推奨事項
LOG_FILE_NAME_CONVERT
='location_of_primary_database_redo_
logs' , 'location_of_standby_database_
redo_logs'
不可
ロジカル
および
フィジカル
スタンバイ・データベースがプライマリ・データ
ベースと同じシステムにある場合、またはログ・
ファイルが存在するスタンバイ・サイトのディレ
クトリ構造がプライマリ・サイトと異なる場合は
必須。このパラメータは、プライマリ・データ
ベースのオンライン REDO ログ・ファイルのパ
ス名をスタンバイ・データベースのパス名に変換
します。3-9 ページの「スタンバイ・データベー
ス用の初期化パラメータ・ファイルの準備」およ
び 4-12 ページの「ロジカル・スタンバイ・デー
タベース用の初期化パラメータ・ファイルの準
備」の例を参照。
PARALLEL_MAX_SERVERS=integer
可
ロジカル
のみ
必須。ロジカル・スタンバイ・データベースで動
作するパラレル・サーバーの最大数を指定しま
す。ロジカル・スタンバイ・データベースでは、
このパラメータの値は、5 未満に設定しないでく
ださい。最適の動作を得るには、PARALLEL_
MAX_SERVERS を 9 以上に設定します。9-26 ペー
ジの「ロジカル・スタンバイ・データベースの
チューニング」も参照。
REMOTE_LOGIN_PASSWORDFILE=
{EXCLUSIVE|SHARED}
可
ロジカル
および
フィジカル
必須。SYS 資格証明を使用した適切な認証チェッ
クが正しく行われた場合にのみ Data Guard が
REDO データを転送するようにするには、プラ
イマリ・データベースおよびすべてのスタンバ
イ・データベースでこのパラメータを指定しま
す。EXCLUSIVE または SHARED 値を含めること
により、パスワード・ファイルを使用できるデー
タベースの数を制御します。5-22 ページの「セ
キュアな REDO データの転送の提供」も参照。
SERVICE_NAMES
可
可
プライマリ・データベース・サービス名に対して
一意である、このスタンバイ・データベースの
サービス名を指定します。プライマリ・データ
ベースとスタンバイ・データベースが同じシステ
ムに常駐し、一意のサービス名を明示的に指定し
ない場合、両データベースで同じデフォルトのグ
ローバル・データベース名（データベース名 DB_
NAME とドメイン名 DB_DOMAIN パラメータで構
成される）が適用されます。
11-6　Oracle Data Guard 概要および管理
表 11-1 Data Guard 構成内のインスタンスの初期化パラメータ（続き）
構成内のインスタンスの初期化パラメータ（続き）
パラメータ
プライマリ・ スタンバイ・
ロール
ロール
注意点および推奨事項
SHARED_POOL_SIZE = bytes
可
ロジカル
および
フィジカル
オプション。オンライン REDO ログ・ファイル
から読み込んだ情報を処理する System Global
Area（SGA）の指定に使用します。使用可能な
SGA が大きいと、処理できる情報量も大きくな
ります。
SORT_AREA_SIZE = bytes
可
ロジカル
および
フィジカル
オプション。大量のソートの効率を上げるには、
SORT_AREA_SIZE のサイズ（デフォルト・サイ
ズは 65536 バイト）を増加します。8-4 ページの
「読取り専用アクセス用にオープンしたスタンバ
イ・データベースの使用」も参照。
STANDBY_ARCHIVE_DEST= filespec
不可
ロジカル
および
フィジカル
オプション。スタンバイ・データベース上のアー
カイブ REDO ログ・ファイルの位置を指定しま
す。STANDBY_ARCHIVE_DEST 初期化パラメータ
は、LOG_ARCHIVE_DEST_n パラメータで指定さ
れたディレクトリの場所よりも優先されます。
STANDBY_ARCHIVE_DEST と LOG_ARCHIVE_
FORMAT が連結して、完全修飾されたログ・ファ
イル名が生成されます。5-34 ページの「アーカイ
ブ REDO ログ・ファイルの代替ディレクトリ位
置の指定」を参照。
STANDBY_FILE_MANAGEMENT =
{AUTO|MANUAL}
可
ロジカル
および
フィジカル
データ・ファイルがプライマリ・データベースに
追加または削除された場合に、手動で変更しなく
てもスタンバイ・データベースに対応する変更が
加えられるよう、STANDBY_FILE_MANAGEMENT
パラメータを AUTO に設定します。プライマリ・
データベースとスタンバイ・データベースのディ
レクトリ構造が異なる場合は、DB_FILE_NAME_
CONVERT 初期化パラメータも設定して、プライ
マリ・データベースのデータ・ファイルの 1 つ以
上のセットのファイル名をスタンバイ・データ
ベースのファイル名に変換する必要があります。
詳細および例は、例 3-2 を参照。
USER_DUMP_DEST = directory_path_ 可
name_of_trace_file
ロジカル
および
フィジカル
LOG_ARCHIVE_TRACE パラメータを指定してい
る場合は必須。USER_DUMP_DEST により、サー
バーによるデバッグ・トレース・ファイルの書込
み先ディレクトリのパス名を指定します。付録 E
を参照。
初期化パラメータ
11-7
11-8　Oracle Data Guard 概要および管理
12
LOG_ARCHIVE_DEST_n パラメータの属性
この章では、LOG_ARCHIVE_DEST_n 初期化パラメータのアーカイブ属性の構文、値および
妥当性に関する情報について説明します。属性には次のものがあります。
AFFIRM および NOAFFIRM
ALTERNATE および NOALTERNATE
ARCH および LGWR
DB_UNIQUE_NAME および NODB_UNIQUE_NAME
DELAY および NODELAY
DEPENDENCY および NODEPENDENCY
LOCATION および SERVICE
MANDATORY および OPTIONAL
MAX_FAILURE および NOMAX_FAILURE
NET_TIMEOUT および NONET_TIMEOUT
QUOTA_SIZE および NOQUOTA_SIZE
QUOTA_USED および NOQUOTA_USED
REGISTER および NOREGISTER
REOPEN および NOREOPEN
SYNC および ASYNC
TEMPLATE および NOTEMPLATE
VALID_FOR
VERIFY および NOVERIFY
定義した各 LOG_ARCHIVE_DEST_n 宛先には、ローカル・ディスクのディレクトリまたはリ
モートからアクセスするデータベースを指定する、LOCATION または SERVICE 属性が含ま
れている必要があります。
LOG_ARCHIVE_DEST_n 宛先を定義して、ログ転送サービスを設定する方法は、第 5 章を参
照してください。
LOG_ARCHIVE_DEST_n パラメータの属性
12-1
宛先属性の変更
宛先属性の変更
LOG_ARCHIVE_DEST_n および LOG_ARCHIVE_DEST_STATE_n パラメータのほとんどの属
性値は、ALTER SYSTEM SET 文および ALTER SESSION 文を使用して、設定したり、動的
に更新したりできます。表 12-1 は、ALTER SYSTEM 文または ALTER SESSION 文で変更で
きる属性を示しています。
表 12-1 SQL を使用した宛先属性の変更
属性
ALTER SYSTEM
ALTER SESSION
[NO]AFFIRM
可
可
[NO]ALTERNATE=destination
可
可
ARCH
可
可
ASYNC[=blocks]
可
不可
[NO]DELAY
可
可
[NO]DEPENDENCY=destination
可
不可
LGWR
可
不可
LOCATION=local_disk_directory
可
可
MANDATORY
可
可
[NO]MAX_FAILURE=count
可
不可
OPTIONAL
可
可
[NO]NET_TIMEOUT[=seconds]
可
不可
[NO]QUOTA_SIZE=blocks
可
不可
[NO]QUOTA_USED=blocks
可
不可
[NO]REGISTER
可
可
[NO]REOPEN[=seconds]
可
可
SERVICE=net_service_name
可
可
[NO]DB_UNIQUE_NAME
可
不可
SYNC[=PARALLEL|NOPARALLEL]
可
可
[NO]TEMPLATE=filename_template
可
可
VALID_FOR
可
可
[NO]VERIFY
可
可
12-2　Oracle Data Guard 概要および管理
宛先の初期化パラメータに関する現行設定の表示
変更は、次にプライマリ・データベースでログ・スイッチを行った後、有効になります。た
とえば、ログ転送サービスが、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;
この方法で属性値を更新すると、パラメータ値全体を再指定せずに、1 つ以上の他の属性を
1 つずつ変更できます。たとえば、次の文は、LOG_ARCHIVE_DEST_2 宛先に REOPEN 属性
を設定し、さらに LOG_ARCHIVE_DEST_1 宛先には複数の属性を、それぞれ個別の行を使用
して 1 つずつ設定しています。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='REOPEN=60';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='OPTIONAL';
LOCATION 属性または SERVICE 属性を指定すると、宛先の初期化パラメータがデフォルト
値にリセットされるため、これらの属性は 1 行目のみに指定する必要があります。この場合、
各文は、LOG_ARCHIVE_DEST_1 宛先がそのつどリセットされるため、増分式にはなりませ
ん。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/ REOPEN=60';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/';
以前に入力した宛先の指定を消去するには、次のように NULL 値を入力します。
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/'
LOG_ARCHIVE_DEST_1=''
宛先の初期化パラメータに関する現行設定の表示
LOG_ARCHIVE_DEST_n 初期化パラメータの現行の設定を表示するには、V$ARCHIVE_
DEST ビューを問合せます。
注意 : LOG_ARCHIVE_DEST_n パラメータ値を確認するときは、
V$PARAMETER ビューを使用しないでください。V$PARAMETER ビューに
は、各パラメータに最後に指定された値のみが表示されるため、増分変更
の場合、実際の LOG_ARCHIVE_DEST_n パラメータ値が表示されません。
LOG_ARCHIVE_DEST_n パラメータの属性
12-3
AFFIRM および NOAFFIRM
AFFIRM および NOAFFIRM
AFFIRM 属性および NOAFFIRM 属性は、リモート・スタンバイ REDO ログ・ファイルまた
はアーカイブ REDO ログ・ファイルへの REDO データの書込みに、同期または非同期の
ネットワーク I/O を使用するかどうかを制御します。
■
■
AFFIRM: スタンバイ宛先のアーカイブ REDO ログ・ファイルまたはスタンバイ REDO ロ
グ・ファイルに対するディスク I/O をすべて同期して実行し、プライマリ・データベー
ス上のオンライン REDO ログ・ファイルが再利用される前に、正常に完了するように
します。データの消失を防ぐには、AFFIRM 属性は必須です。
NOAFFIRM: アーカイブ REDO ログ・ファイルおよびスタンバイ REDO ログ・ファイル
に対するディスク I/O をすべて非同期して実行します。プライマリ・データベース上の
オンライン REDO ログ・ファイルは、スタンバイ宛先のディスク I/O が完了する前に
再利用できます。
注意 : AFFIRM および NOAFFIRM 属性の適用先は、リモート・スタンバ
イ宛先のアーカイブ REDO ログ・ファイルおよびスタンバイ REDO ロ
グ・ファイルのみであるため、プライマリ・データベースのオンライン
REDO ログ・ファイルに対するディスク I/O には影響を与えません。
AFFIRM 属性および NOAFFIRM 属性が指定されていない場合、デフォルトは NOAFFIRM で
す。
カテゴリ
AFFIRM
NOAFFIRM
属性のデータ型
キーワード
キーワード
最小属性値
該当なし
該当なし
最大属性値
該当なし
該当なし
デフォルト属性値
該当なし
該当なし
必須属性
該当なし
該当なし
属性との競合
NOAFFIRM
AFFIRM
属性クラス
ALTER SESSION と ALTER
SYSTEM
ALTER SESSION と ALTER
SYSTEM
対応する V$ARCHIVE_DEST 列
AFFIRM
AFFIRM
関連する V$ARCHIVE_DEST 列
ASYNC_BLOCKS
ASYNC_BLOCKS
12-4　Oracle Data Guard 概要および管理
AFFIRM および NOAFFIRM
AFFIRM
AFFIRM 属性は、REDO データがリモート・スタンバイ・データベースに転送される場合に
も、アーカイブ REDO ログ・ファイルおよびスタンバイ REDO ログ・ファイルに対する
ディスク I/O がすべて同期して実行されることを示します。ローカルまたはリモートの宛先
にアーカイブ操作を行う場合、LOCATION 属性または SERVICE 属性に AFFIRM 属性を指定
できます。
この属性は、次のように、プライマリ・データベースのパフォーマンスに影響を与えること
があります。
■
■
■
LGWR 属性と AFFIRM 属性を指定した場合、ログ・ライター・プロセスは REDO データ
を同期してディスクに書き込みます。また、ディスク I/O が完了するまでは、制御が
ユーザーに戻されないため、プライマリ・データベース上のオンライン REDO ログ・
ファイルが、アーカイブが完了するまで再使用できないことがあります。
ARCH 属性と AFFIRM 属性を指定した場合、ARCn プロセスは REDO データを同期して
ディスクに書き込みます。また、アーカイブ操作に時間がかかることがあるため、プラ
イマリ・データベース上のオンライン REDO ログ・ファイルが、アーカイブが完了す
るまで再使用できない場合があります。
ASYNC 属性と AFFIRM 属性を指定しても、パフォーマンスには影響しません。
V$ARCHIVE_DEST 固定ビューの AFFIRM 列を問合せると、AFFIRM 属性が、対応付けられ
た宛先に使用されるかどうかを確認できます。
注意 : プライマリ・データベースが最大保護モードまたは最大可用性
モードである場合、ログ・ライター・プロセスによる宛先は、自動的に
AFFIRM モードになります。
12-42 ページの SYNC および ASYNC 属性も参照してください。
NOAFFIRM
NOAFFIRM 属性は、アーカイブ REDO ログ・ファイルおよびスタンバイ REDO ログ・ファ
イルに対するディスク I/O がすべて非同期で実行されることを示します。この場合、プライ
マリ・データベースの LGWR プロセスは、ディスク I/O が完了するまで待機せずに続行さ
れます。NOAFFIRM 属性は、ローカル宛先の場合は LOCATION 属性に、リモート宛先の場
合は SERVICE 属性に指定できます。
例
次の例は、リモート宛先の AFFIRM 属性を示しています。
LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR SYNC AFFIRM'
LOG_ARCHIVE_DEST_STATE_3=ENABLE
LOG_ARCHIVE_DEST_n パラメータの属性
12-5
ALTERNATE および NOALTERNATE
ALTERNATE および NOALTERNATE
次の属性は、元のアーカイブ先で障害が発生したときに、代替アーカイブ先を使用するかど
うかを制御します。
■
ALTERNATE: 代替アーカイブ先を定義します。
■
NOALTERNATE: 代替アーカイブ先にアーカイブしないようにします。
ALTERNATE 属性および NOALTERNATE 属性が指定されていない場合、デフォルトは
NOALTERNATE です。NOALTERNATE 属性が指定されている場合、または代替アーカイブ先
が指定されていない場合、障害が発生しても宛先は自動的に別の宛先に変更されません。
カテゴリ
ALTERNATE=LOG_
ARCHIVE_DEST_n
NOALTERNATE
属性のデータ型
文字列値
キーワード
最小属性値
該当なし
該当なし
最大属性値
該当なし
該当なし
デフォルト属性値
なし
該当なし
必須属性
該当なし
該当なし
属性との競合
NOALTERNATE
ALTERNATE
属性クラス
ALTER SYSTEM と ALTER
SYSTEM
ALTER SESSION と ALTER
SYSTEM
対応する V$ARCHIVE_DEST 列
ALTERNATE
ALTERNATE
関連する V$ARCHIVE_DEST 列
STATUS
STATUS
12-6　Oracle Data Guard 概要および管理
ALTERNATE および NOALTERNATE
ALTERNATE=LOG_ARCHIVE_DEST_n
ALTERNATE 属性は、当初のアーカイブ先へのアーカイブ操作に失敗した場合に使用される、
別の宛先 LOG_ARCHIVE_DEST_n を指定します。代替アーカイブ先には、ローカルまたはリ
モートのアーカイブ先を参照できます。たとえば、次のパラメータは、宛先 LOG_
ARCHIVE_DEST_1 に失敗すると、アーカイブ操作が自動的に宛先を LOG_ARCHIVE_DEST_
2 に切り替えるように指定します。
LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY'
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
LOG_ARCHIVE_DEST_n パラメータごとに、代替アーカイブ先を 1 つのみ指定できます。代
替アーカイブ先は、プライマリ・サイトからスタンバイ・サイトへの REDO データの転送
に失敗した場合に使用されます。REDO データの転送に失敗し、REOPEN 属性の値に 0（ゼ
ロ）が指定されている場合または NOREOPEN 属性が指定されている場合、REDO データは、
次にアーカイブされるときに、代替アーカイブ先に転送されます。
宛先は、ALTERNATE 状態にすることも可能です。この状態は、LOG_ARCHIVE_DEST_
STATE_n 初期化パラメータを使用して指定します。ALTERNATE 状態の宛先の処理は、代替
アーカイブ先属性が有効な場合、別の宛先の失敗によって、自動的にこの宛先が有効になる
まで遅延します。LOG_ARCHIVE_DEST_STATE_n パラメータの詳細は、5-4 ページの
「LOG_ARCHIVE_DEST_n パラメータを使用した宛先の構成」を参照してください。
図 12-1 では、REDO データがローカルのディスク・デバイスにアーカイブされています。
当初のアーカイブ先のデバイスがいっぱいであったり、利用できない場合、アーカイブ操作
は自動的に代替アーカイブ先のデバイスにリダイレクトされます。
LOG_ARCHIVE_DEST_n パラメータの属性
12-7
ALTERNATE および NOALTERNATE
図 12-1 代替アーカイブ先のデバイスへのアーカイブ操作
REOPEN 属性は、ALTERNATE 属性よりも優先されます。代替アーカイブ先は、次のいずれ
かの場合にのみ使用されます。
NOREOPEN 属性が指定されている。
■
REOPEN 属性に、値 0（ゼロ）が指定されている。
■
0（ゼロ）ではない REOPEN 属性で 0（ゼロ）ではない MAX_FAILURE の件数を超過して
いる。
■
ALTERNATE 属性は、MANDATORY 属性よりも優先されます。これは、現在の宛先が必須で
あっても、有効な代替アーカイブ先に宛先をフェイルオーバーすることを意味します。
次の表は、スタンバイ宛先の属性の優先順位を示しています。左側の列の中で、1 が最も高
い優先順位、4 が最も低い優先順位を示します。
優先順位
属性
1
MAX_FAILURE
2
REOPEN
3
ALTERNATE
4
MANDATORY
スタンバイ・データベースを代替アーカイブ先のターゲットとして使用する場合は、注意が
必要です。スタンバイの代替アーカイブ先は、同じスタンバイ・データベース・システムへ
の異なるネットワーク・ルートを指定するためにのみ使用するのが理想的です。
12-8　Oracle Data Guard 概要および管理
ALTERNATE および NOALTERNATE
代替アーカイブ先を参照する有効な宛先がない場合は、代替アーカイブ先が保留されている
ことを意味します。これは、代替アーカイブ先を有効にする自動手段がないためです。
代替アーカイブ先は、実行時に手動で有効にできます。逆に言えば、代替アーカイブ先は、
実行時に手動で無効にできます。実行時に SQL を使用した初期化パラメータ設定の変更の
詳細は、
『Oracle Database 管理者ガイド』を参照してください。
代替スタンバイ宛先の一般プールはありません。データベース管理者が、すべての有効な宛
先に対して、参照する宛先を厳密に反映する代替アーカイブ先を選択することが理想的です
（ただし、代替アーカイブ先の指定は必須ではありません）。
有効な宛先は、それぞれ固有の代替アーカイブ先を持つことができます。逆に言えば、複数
の有効な宛先が、同じ代替アーカイブ先を共有できます。これは、宛先のオーバーラップ・
セットと呼ばれます。代替アーカイブ先を有効にすると、その宛先が属するセットが決まり
ます。
有効な宛先数を増加させると、利用可能な代替アーカイブ先の数が減少します。
注意 : 代替アーカイブ先は、次回に実行するアーカイブ操作で有効にな
ります。アーカイブ操作の途中で、代替アーカイブ先を有効にすることは
できません。これは、すでに処理済みのブロックなどを、再度読み込む必
要が生じるためです。これは、REOPEN 属性の機能と同じです。
代替に指定できる宛先には、次の制限事項があります。
■
■
■
ローカルの必須の宛先を少なくとも 1 つは有効にする。
有効な宛先数は、LOG_ARCHIVE_MIN_SUCCEED_DEST パラメータでの定義と一致させ
る必要がある。
宛先をそれ自身の代替先にすることはできない。
SQL の ALTER SESSION 文を使用して定義した宛先は、システム・レベルで定義された代
替アーカイブ先をアクティブ化しません。逆に言えば、システム定義の宛先は、セッショ
ン・レベルで定義された代替アーカイブ先をアクティブ化しません。
REOPEN 属性が 0（ゼロ）ではない値で指定されている場合、ALTERNATE 属性は無視されま
す。MAX_FAILURE 属性に 0（ゼロ）ではない値が指定され、障害件数が指定した障害しき
い値を超過する場合は、ALTERNATE 宛先が有効になります。このため、ALTERNATE 属性は
0（ゼロ）ではない REOPEN 属性値と競合しません。
NOALTERNATE
LOG_ARCHIVE_DEST_n パラメータの NOALTERNATE 属性を使用すると、当初の宛先で失敗
した場合に、当初の宛先から代替アーカイブ先に自動的に変更されることを防止できます。
LOG_ARCHIVE_DEST_n パラメータの属性
12-9
ALTERNATE および NOALTERNATE
例
例 12-1 のサンプル初期化パラメータ・ファイルでは、エラーが発生したり、デバイスがいっ
ぱいになった場合、LOG_ARCHIVE_DEST_1 が、LOG_ARCHIVE_DEST_2 へのフェイルオー
バーを次回のアーカイブ操作で自動的に実行します。
例 12-1 代替アーカイブ先への自動フェイルオーバー
LOG_ARCHIVE_DEST_1=
'LOCATION=/disk1 MANDATORY NOREOPEN ALTERNATE=LOG_ARCHIVE_DEST_2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY'
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
例 12-2 のサンプルの初期化パラメータ・ファイルは、同じスタンバイ・データベースに代替
Oracle Net サービス名を定義する方法を示しています。
例 12-2 スタンバイ・データベースに対する代替の Oracle Net サービス名の定義
LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='SERVICE=stby1_path1 NOREOPEN OPTIONAL ALTERNATE=LOG_ARCHIVE_DEST_3'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=stby1_path2 NOREOPEN OPTIONAL'
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE
12-10　Oracle Data Guard 概要および管理
ARCH および LGWR
ARCH および LGWR
オプションの ARCH 属性と LGWR 属性は、アーカイブ操作を実行するプロセスを指定します。
■
■
ARCH: アーカイバ・プロセス（ARCn）が REDO データをアーカイブ先に転送します。
LGWR: ログ・ライター・プロセス（LGWR）は、REDO データをアーカイブ先に転送し
ます。
デフォルトで、アーカイブは ARCn プロセスによって実行されるようになっているため、ロ
グ転送サービスで LGWR プロセスを使用するには、LGWR 属性を明示的に指定する必要が
あります。同じ宛先に LGWR プロセスと ARCn プロセスの両方を指定することはできませ
んが、ある宛先にはログ・ライター・プロセスを使用するよう指定し、別の宛先にはアーカ
イバ・プロセスを使用して REDO データを転送するよう指定することは可能です。
宛先の現行のアーカイブ・プロセスを変更した場合（ARCn プロセスから LGWR プロセス
への変更など）
、アーカイブ・プロセスは次にログ・スイッチが行われるまで変更されませ
ん。
ARCH 属性および LGWR 属性が指定されていない場合、デフォルトは ARCH です。
カテゴリ
ARCH
LGWR
属性のデータ型
キーワード
キーワード
最小属性値
該当なし
該当なし
最大属性値
該当なし
該当なし
デフォルト属性値
該当なし
該当なし
必須属性
該当なし
該当なし
属性との競合
LGWR、ASYNC、NET_TIMEOUT
ARCH
属性クラス
ALTER SESSION と ALTER
SYSTEM
ALTER SYSTEM
対応する V$ARCHIVE_DEST 列
ARCHIVER
ARCHIVER
関連する V$ARCHIVE_DEST 列
PROCESS、SCHEDULE
PROCESS、SCHEDULE
ローカルおよびリモートのスタンバイ宛先への REDO データの転送を制御する方法は、
LOCATION および SERVICE 属性を参照してください。
LOG_ARCHIVE_DEST_n パラメータの属性
12-11
ARCH および LGWR
ARCH
ARCH 属性は、プライマリ・データベースで REDO ログ・スイッチが行われたときに、アー
カイバ・プロセス（ARCn）によって、現行の REDO データが対応付けられた宛先に転送さ
れることを示します。REDO データは、スタンバイ・システムに転送されると、RFS プロセ
スによってアーカイブ REDO ログ・ファイルおよびスタンバイ REDO ログ・ファイル（実
装されている場合）に書き込まれます。ARCH 属性はデフォルトの設定値です。
宛先に ARCH 属性を指定すると、ログ転送サービスでは同期式のネットワーク転送のみが行
われます。ARCH 属性と ASYNC 属性を一緒に指定すると、エラー・メッセージが戻されま
す。
LGWR
LGWR 属性は、REDO データが、バックグラウンドの LGWR プロセスによって、プライマ
リ・データベース上のオンライン REDO ログ・ファイルの書込みと同時にスタンバイ宛先
に転送されることを示します。REDO データはプライマリ・データベースに生成されるとス
タンバイ・システムにも伝播され、そこで RFS プロセスによって、スタンバイ REDO ログ・
ファイルまたはアーカイブ REDO ログ・ファイルに書き込まれます。
ただし、LGWR 属性と ASYNC 属性、または LGWR 属性と SYNC=PARALLEL 属性を指定する
と、LGWR プロセスでは、LGWR プロセスのかわりにスタンバイ宛先に REDO データを転
送する、ネットワーク・サーバー（LNS）プロセスが使用されます。詳細は、5-16 ページの
「ログ・ライター・プロセス（LGWR）を使用した REDO データのアーカイブ」を参照して
ください。
REDO データをリモートの宛先に転送すると、LGWR プロセスは、宛先インスタンスに
ネットワーク接続を確立します。REDO データは同時に転送されるため、アーカイブ操作時
に対応する宛先に REDO データが再転送されることはありません。最大可用性モードまたは
最大パフォーマンス・モードで実行中の宛先に障害が発生した場合、その宛先は問題が修正
されるまで、自動的に ARCn プロセスを使用するよう再設定されます。
例
次の例は、LGWR 属性が指定されている LOG_ARCHIVE_DEST_n パラメータを示していま
す。これらの属性のその他の使用例は、5-11 ページの「REDO データの送信方法」を参照し
てください。
LOG_ARCHIVE_DEST_3='SERVICE=denver LGWR'
LOG_ARCHIVE_DEST_STATE_3=ENABLE
12-12　Oracle Data Guard 概要および管理
DB_UNIQUE_NAME および NODB_UNIQUE_NAME
DB_UNIQUE_NAME および NODB_UNIQUE_NAME
DB_UNIQUE_NAME 属性は、この宛先にデータベースの一意の名前を指定します。DB_
UNIQUE_NAME 属性は、DB_UNIQUE_NAME 初期化パラメータを使用してこのデータベース
に最初に定義された値と一致している必要があります。
この属性にはデフォルト値はありません。
カテゴリ
DB_UNIQUE_NAME=name
NODB_UNIQUE_NAME
属性のデータ型
文字列
文字列
最小属性値
該当なし
該当なし
最大属性値
該当なし
該当なし
デフォルト属性値
該当なし
NODB_UNIQUE_NAME
必須属性
該当なし
該当なし
属性との競合
NODB_UNIQUE_NAME
DB_UNIQUE_NAME
属性クラス
ALTER SYSTEM
ALTER SYSTEM
対応する V$ARCHIVE_DEST 列
DB_UNIQUE_NAME
DB_UNIQUE_NAME
関連する V$ARCHIVE_DEST 列
DB_UNIQUE_NAME
DB_UNIQUE_NAME
DB_UNIQUE_NAME=name
DB_UNIQUE_NAME=name 属性は、宛先で識別されるデータベースの DB_UNIQUE_NAME 初期
化パラメータと一致している必要があります。LOG_ARCHIVE_CONFIG=DG_CONFIG パラ
メータが指定されていない場合、DB_UNIQUE_NAME 属性はオプションです。LOG_
ARCHIVE_CONFIG=DG_CONFIG パラメータが指定されている場合、DB_UNIQUE_NAME 属性
は、次のように必須またはオプションになります。
■
■
リモート宛先（SERVICE 属性で指定されます）の場合は必須です。DG_CONFIG リスト
の DB_UNIQUE_NAME の値の 1 つと一致している必要があります。さらに、ログ転送
サービスにより、指定された宛先のデータベースの DB_UNIQUE_NAME が、DB_
UNIQUE_NAME 属性と一致していること、またはその宛先への接続が拒否されているこ
とが検証されます。
ローカル宛先（LOCATION 属性で指定されます）の場合はオプションです。ただし、
ローカル宛先を指定する場合、DB_UNIQUE_NAME 属性を使用して指定する名前は、
データベースの DB_UNIQUE_NAME 初期化パラメータに指定した名前と一致している必
要があります。
LOG_ARCHIVE_DEST_n パラメータの属性
12-13
DB_UNIQUE_NAME および NODB_UNIQUE_NAME
NODB_UNIQUE_NAME
NODB_UNIQUE_NAME 属性を指定して、LOG_ARCHIVE_CONFIG パラメータを定義しない
と、宛先のデータベースの一意名がリセットされます。つまり、NODB_UNIQUE_NAME 属性
は、DB_UNIQUE_NAME 属性で以前に指定した値を消去します。LOG_ARCHIVE_CONFIG パ
ラメータが定義されていない場合、NODB_UNIQUE_NAME 属性は有効ではありません。
例
次の例は、LOG_ARCHIVE_DEST_n パラメータで DB_UNIQUE_NAME 属性を指定する方法を
示す、テキスト初期化パラメータ・ファイルの一部です。DB_UNIQUE_NAME および LOG_
ARCHIVE_CONFIG 初期化パラメータは、明確にするために定義されています。
例では、このデータベースの DB_UNIQUE_NAME は boston（DB_UNIQUE_NAME=boston）
と指定されており、これは LOG_ARCHIVE_DEST_1 パラメータの DB_UNIQUE_NAME 属性に
も指定されています。LOG_ARCHIVE_DEST_2 パラメータの DB_UNIQUE_NAME 属性は、宛
先として chicago を指定しています。boston と chicago は、どちらも LOG_ARCHIVE_
CONFIG=DG_CONFIG パラメータにリストされています。
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_
NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='SERVICE=Sales_DR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_
NAME=chicago'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
.
.
.
12-14　Oracle Data Guard 概要および管理
DELAY および NODELAY
DELAY および NODELAY
フィジカル・スタンバイ・データベースでログ適用サービスが使用可能になっている場合、
REDO データは、アーカイブ REDO ログ・ファイルまたはスタンバイ REDO ログ・ファイ
ルに書き込まれた後に適用されます（リアルタイム適用が使用可能になっている場合を除き
ます。リアルタイム適用により、Data Guard は、いっぱいになっている現在のスタンバイ
REDO ログ・ファイルから REDO データをリカバリできます）。ただし、DELAY 属性は、ス
タンバイ・サイトでの REDO データのアーカイブから、スタンバイ・データベースへの
アーカイブ REDO ログ・ファイルの適用までのタイム・ラグを指定するため、この属性を
使用すると、破損したプライマリ・データまたは誤ったプライマリ・データからスタンバ
イ・データベースを保護できます。
注意 : この属性は、フィジカル・スタンバイ・データベースにのみ設定
できます。ロジカル・スタンバイ・データベースでアーカイブ REDO ロ
グ・ファイルの適用を遅延するには、
『PL/SQL パッケージ・プロシー
ジャおよびタイプ・リファレンス』で説明されているように、DBMS_
LOGSTDBY.APPLY_SET プロシージャを使用します。
DELAY 属性および NODELAY 属性が指定されていない場合、デフォルトは NODELAY です。
カテゴリ
DELAY[=minutes]
NODELAY
属性のデータ型
数値
キーワード
最小属性値
0分
該当なし
最大属性値
無制限
該当なし
デフォルト属性値
30 分
該当なし
必須属性
SERVICE
該当なし
属性との競合
LOCATION、NODELAY
DELAY
属性クラス
ALTER SESSION と ALTER
SYSTEM
ALTER SESSION と ALTER
SYSTEM
対応する V$ARCHIVE_DEST 列
DELAY_MINS
DELAY_MINS
関連する V$ARCHIVE_DEST 列
DESTINATION
DESTINATION
LOG_ARCHIVE_DEST_n パラメータの属性
12-15
DELAY および NODELAY
DELAY[=minutes]
LOG_ARCHIVE_DEST_n 初期化パラメータの DELAY 属性を使用して、フィジカル・スタン
バイ・データベースにアーカイブ REDO ログ・ファイルを適用する際のタイム・ラグを指
定します。DELAY 属性は、REDO データのフィジカル・スタンバイ宛先への転送に影響しま
せん。リアルタイム適用が使用可能になっている場合、設定した遅延は無視されます。
注意 : DELAY 属性の変更は、次に REDO データをアーカイブすると有効
になります。進行中のアーカイブ操作には、影響しません。
DELAY 属性は、スタンバイ宛先のアーカイブ REDO ログ・ファイルが、指定した時間が経
過するまでリカバリに利用されないことを示します。時間間隔は分で表され、転送された
REDO データがスタンバイ・サイトに正常に到達した時点から計測されます。
DELAY 属性を使用すれば、プライマリ・データベースと様々なレベルで同期させる複数のス
タンバイ・データベースを維持する構成を設定できます。たとえば、プライマリ・データ
ベース A がスタンバイ・データベース B、C、D をサポートしている場合を考えます。スタ
ンバイ・データベース B は、障害時リカバリ・データベースとして設定するため、タイム・
ラグは設定しません。スタンバイ・データベース C は、論理的、または物理的な破損に対し
て保護するように設定され、2 時間の遅延があります。スタンバイ・データベース D には 4
時間の遅延があり、破損が拡大された場合の保護を提供します。
スタンバイ・サイトでの指定した遅延間隔は上書きできます。時間間隔が経過する前に、
アーカイブ REDO ログ・ファイルをスタンバイ・データベースに即時に適用するには、
RECOVER MANAGED STANDBY DATABASE 句の NODELAY キーワードを使用します。次に例
を示します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
NODELAY
NODELAY 属性を指定し、フィジカル・スタンバイ・データベースで REDO Apply が使用可
能になっている場合は、プライマリ・データベースでログ・スイッチが発生したときに、
アーカイブ REDO ログ・ファイルが適用されます。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 文の DELAY 属性の詳細は、
『Oracle Database SQL リファレンス』を参照してください。
例
次の例は、DELAY 属性が指定されている LOG_ARCHIVE_DEST_n パラメータを示していま
す。
LOG_ARCHIVE_DEST_3='SERVICE=stby1 DELAY=240'
LOG_ARCHIVE_DEST_STATE_3=ENABLE
12-16　Oracle Data Guard 概要および管理
DEPENDENCY および NODEPENDENCY
DEPENDENCY および NODEPENDENCY
DEPENDENCY 属性を指定すると、REDO データは、複数のスタンバイ・データベース間で
アーカイブ REDO ログ・ファイルを共有する宛先に転送されます。
■
■
DEPENDENCY: 複数の宛先の代表として REDO データを受信する 1 つのアーカイブ先を定
義します。
NODEPENDENCY: アーカイブの実行が、別の宛先に対するアーカイブ操作の成功または
失敗に依存しないことを指定します。
リモート宛先に対する REDO データの転送によって、子宛先が、親宛先に対するアーカイ
ブ操作の成功または失敗に依存するかどうかが決まります。
DEPENDENCY 属性および NODEPENDENCY 属性が指定されていない場合、デフォルトは
NODEPENDENCY です。
カテゴリ
DEPENDENCY=destination
NODEPENDENCY
属性のデータ型
文字列値
キーワード
最小属性値
該当なし
該当なし
最大属性値
該当なし
該当なし
デフォルト属性値
該当なし
該当なし
必須属性
SERVICE、REGISTER
該当なし
属性との競合
NODEPENDENCY、LOCATION、 DEPENDENCY
NOREGISTER、QUOTA_SIZE、
QUOTA_USED
属性クラス
ALTER SYSTEM
ALTER SYSTEM
対応する V$ARCHIVE_DEST 列
DEPENDENCY
DEPENDENCY
関連する V$ARCHIVE_DEST 列
該当なし
該当なし
LOG_ARCHIVE_DEST_n パラメータの属性
12-17
DEPENDENCY および NODEPENDENCY
DEPENDENCY=destination
DEPENDENCY 属性を指定して、ローカルの宛先、フィジカル・スタンバイ・データベースま
たはロジカル・スタンバイ・データベースを定義します。宛先依存性を指定すると、次に示
すような構成の場合に便利です。
■
■
■
■
■
スタンバイ・データベースとプライマリ・データベースが同じノード上にある。このた
め、アーカイブ REDO ログ・ファイルが暗黙的にスタンバイ・データベースの影響を
受けやすい状態にある。
クラスタ化されたファイル・システムが、リモートのスタンバイ・データベースにプラ
イマリ・データベースのアーカイブ REDO ログ・ファイルへのアクセスを提供する。
オペレーティング・システム固有のネットワーク・ファイル・システムが、リモートの
スタンバイ・データベースに、プライマリ・データベースのアーカイブ REDO ログ・
ファイルへのアクセスを提供する。
ミラー・ディスク・テクノロジによって、地理的に距離の離れた地点間の透過的なネッ
トワーキング・サポートを提供する。
複数のスタンバイ・データベースが同じリモート・システムに存在し、共通のアーカイ
ブ REDO ログ・ファイルへのアクセスを共有する。
このような状況では、物理的なアーカイブ操作が、依存する宛先に対して発生することはあ
りませんが、スタンバイ・データベースはアーカイブ REDO ログ・ファイルの位置を知っ
ておく必要があります。このためスタンバイ・データベースでは、アーカイブ REDO ログ・
ファイルが使用可能になると、そのアーカイブ REDO ログ・ファイルにアクセスできるよ
うになります。
2 つのノードがクラスタ化されている場合を考えます。この構成のプライマリ・ノードは、
宛先へのアクセスを、ミラー化されたディスク・デバイスからスタンバイ・データベースと
共有します。この構成は、ローカルにスタンバイ・データベースを維持するため、オフロー
ドの非定型問合せとレポート機能に便利です。
プライマリ・データベースは、オンライン REDO ログ・ファイルをローカルにアーカイブ
します。これが正常に完了すると、アーカイブ REDO ログ・ファイルは即時にスタンバイ・
データベースで利用できるようになり、フィジカル・スタンバイ・データベースによって
REDO Apply が開始されます。このとき、スタンバイ宛先には、物理的なリモートのアーカ
イブ操作を必要としません。この場合、2 つの宛先、つまりローカルのアーカイブ操作用の
宛先とスタンバイ・サイトでのアーカイブ操作用の宛先が使用されます。スタンバイ宛先
は、プライマリ宛先が成功しない場合は有効ではありません。このためスタンバイ宛先は、
ローカルの宛先の成功、または失敗に依存します。
12-18　Oracle Data Guard 概要および管理
DEPENDENCY および NODEPENDENCY
制限事項
DEPENDENCY 属性には、次の制限事項があります。
■
依存性を持つことができるのはスタンバイ宛先のみである。
■
親宛先には、ローカルの宛先、またはスタンバイ宛先がなり得る。
■
DEPENDENCY 属性は、セッション・レベルでは変更できない。
■
REGISTER 属性が必要。
■
SERVICE 属性が必要。
1 つ以上の宛先が同じ親宛先に依存する場合、依存する宛先のすべての属性が、その宛先に
適用されます。実際にはアーカイブ操作が 1 回のみ発生した場合でも、アーカイブ操作が各
宛先に対して実行されたように見えます。
たとえば、2 つのスタンバイ・データベースが同じ親宛先に依存する場合を考えます。各宛
先には異なる DELAY 属性を指定できるため、プライマリ・データベースと各スタンバイ・
データベース間で、タイム・ラグをずらして維持できます。
同じように、依存する宛先には、代替アーカイブ先を指定できますが、同じ親宛先に依存す
るようにもしないようにも指定できます。
注意 :
ん。
依存する宛先は、Data Guard の非データ消失環境には含まれませ
NODEPENDENCY
アーカイブの実行が、別の宛先に対するアーカイブ操作の成功または失敗に依存しないこと
を指定します。
LOG_ARCHIVE_DEST_n パラメータの属性
12-19
DEPENDENCY および NODEPENDENCY
例
DEPENDENCY 属性を使用する理由の 1 つは、スタンバイ・データベースがプライマリ・デー
タベースと同一のサイト上にある場合です。この構成を使用すると、スタンバイ・データ
ベースがローカル・システムに存在することになり、同じアーカイブ REDO ログ・ファイ
ルにアクセスできるため、REDO データに必要なアーカイブが 1 度のみですみます。次の例
は、この構成を使用した場合の LOG_ARCHIVE_DEST_n パラメータを示しています。
# Set up the mandatory local destination:
#
LOG_ARCHIVE_DEST_1='LOCATION=/oracle/dbs/ MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
#
# Set up the dependent standby database that resides on the local system:
#
LOG_ARCHIVE_DEST_2='SERVICE=dest2 DEPENDENCY=LOG_ARCHIVE_DEST_1 OPTIONAL'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
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
12-20　Oracle Data Guard 概要および管理
LOCATION および SERVICE
LOCATION および SERVICE
各宛先には LOCATION 属性または SERVICE 属性を指定して、ログ転送サービスがローカ
ル・ディスクのディレクトリまたはリモート・データベースのどちらに REDO データを転
送できるかを明示する必要があります。Data Guard 構成ごとに、LOCATION 属性で少なく
とも 1 つのローカル・ディスクのディレクトリを指定する必要があります。これにより、プ
ライマリ・データベースのメディア・リカバリが必要な場合は、ローカルのアーカイブ
REDO ログ・ファイルに確実にアクセスできるようになります。ローカルまたはリモートの
追加宛先は最大 9 個まで指定できます。SERVICE 属性を使用してリモート宛先を指定する
と、Data Guard では、障害時リカバリに備えて、トランザクション一貫性のあるプライマ
リ・データベースのリモート・コピーを確実に維持できます。
LOCATION または SERVICE 属性を指定する必要があります。デフォルトはありません。
LOCATION 属性は、USE_DB_RECOVERY_FILE_DEST 値を指定した場合のみ、QUOTA_SIZE
および QUOTA_USED と競合します。
カテゴリ
LOCATION=local_disk_directory
または
USE_DB_RECOVERY_FILE_DEST
SERVICE=net_service_name
データ型
文字列値
文字列値
最小属性値
該当なし
該当なし
最大属性値
該当なし
該当なし
デフォルト属性値
該当なし
該当なし
必須属性
該当なし
該当なし
属性との競合
SERVICE、DELAY、DEPENDENCY、
NOREGISTER、ASYNC、TEMPLATE、
NET_TIMEOUT、QUOTA_SIZE、
QUOTA_USED
LOCATION、QUOTA_USED、
QUOTA_SIZE
属性クラス
ALTER SESSION と ALTER SYSTEM
ALTER SESSION と ALTER
SYSTEM
対応する
V$ARCHIVE_
DEST 列
DESTINATION
DESTINATION
関連する
V$ARCHIVE_
DEST 列
TARGET
TARGET
LOG_ARCHIVE_DEST_n パラメータの属性
12-21
LOCATION および SERVICE
注意 : 複数の属性を指定している場合は、属性のリストの最初に
LOCATION 属性または SERVICE 属性を指定します。
LOCATION および SERVICE の現行の設定を確認するには、V$ARCHIVE_DEST 固定ビュー
を問い合せます。
■
■
V$ARCHIVE_DEST 固定ビューの TARGET 列は、宛先がプライマリ・データベースに
とってローカルかリモートかを示します。
V$ARCHIVE_DEST 固定ビューの DESTINATION 列は、宛先に指定されている値を示し
ます。たとえば、宛先パラメータ値は、アーカイブ REDO ログ・ファイルが配置されて
いるリモートの Oracle インスタンスを示す Oracle Net サービス名を指定します。
LOCATION=local_disk_directory
LOCATION 属性を指定すると、次のいずれかを指定できます。
■
LOCATION=local_disk_directory
これは、データベースを置くシステム上のディスク・ディレクトリへの有効なパス名を
指定します。LOCATION 属性を指定する各宛先は、一意のディレクトリ・パス名を示す
必要があります。これは、アーカイブ REDO ログ・ファイルのローカル宛先です。
ローカル宛先は、アーカイブ REDO ログ・ファイルが、ローカル・データベースで利
用できるファイル・システム内に常駐していることを示します。ローカル・アーカイブ
REDO ログ・ファイルは、物理的にはプライマリ・データベースのネームスペース内に
維持されます。宛先パラメータ値は、ログ・ファイルがコピーされるローカル・ファイ
ル・システム・ディレクトリのパスを指定します。
■
LOCATION=USE_DB_RECOVERY_FILE_DEST
フラッシュ・リカバリ領域を構成するには、DB_RECOVERY_FILE_DEST 初期化パラ
メータを使用して、フラッシュ・リカバリ領域として機能するディレクトリ、ファイ
ル・システムまたは Oracle Storage Manager のディスク・グループを指定します。ロー
カル宛先を定義しない場合、Data Guard では、LOG_ARCHIVE_DEST_10 宛先が、デ
フォルトのフラッシュ・リカバリのディスク領域およびアーカイブ REDO ログ・ファ
イルの格納先として暗黙的に使用されます。フラッシュ・リカバリ領域の詳細は、5-7
ページの「フラッシュ・リカバリ領域を宛先とした設定」を参照してください。
注意 : アーカイブ・プロセスを使用可能にするために ALTER DATABASE
ARCHIVELOG 文を発行すると、LOG_ARCHIVE_DEST_n パラメータの
LOCATION 属性からローカルのアーカイブ先が自動的に導出されます。
12-22　Oracle Data Guard 概要および管理
LOCATION および SERVICE
SERVICE=network_service_name
SERVICE 属性と、REDO データの送信先となるリモート Oracle データベース・インスタン
スを識別する有効な Oracle Net サービス名（SERVICE=net_service_name）を指定して、リ
モート宛先を識別します。
リモート宛先に REDO データを転送するには、着信するアーカイブ REDO データを受け取
るために、ネットワーク接続と、リモート宛先に対応付けられた Oracle データベース・イ
ンスタンスが必要です。
SERVICE 属性で指定する Oracle Net サービス名は、リモート・データベースへの接続に必
要な情報を含む接続記述子に変換されます。
Oracle Net サービス名の設定方法は、
『Oracle Net Services 管理者ガイド』を参照してくだ
さい。
例
次の例は、LOCATION 属性が指定されている LOG_ARCHIVE_DEST_n パラメータを示してい
ます。
LOG_ARCHIVE_DEST_2='LOCATION=/disk1/oracle/oradata/payroll/arch/'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
次の例は、SERVICE 属性が指定されている LOG_ARCHIVE_DEST_n パラメータを示してい
ます。
LOG_ARCHIVE_DEST_3='SERVICE=stby1'
LOG_ARCHIVE_DEST_STATE_3=ENABLE
LOG_ARCHIVE_DEST_n パラメータの属性
12-23
MANDATORY および OPTIONAL
MANDATORY および OPTIONAL
OPTIONAL または MANDATORY 属性を使用して、オンライン REDO ログ・ファイルを再利用
するためのポリシーを指定できます。宛先に OPTIONAL を指定すると、その宛先へのアー
カイブが失敗する場合があります。さらに、オンライン REDO ログ・ファイルが再利用さ
れて、最終的に上書きされる場合があります。必須の宛先へのアーカイブ操作が失敗した場
合、オンライン REDO ログ・ファイルは上書きされません。
MANDATORY 属性および OPTIONAL 属性が指定されていない場合、デフォルトは OPTIONAL
です。すべての宛先がオプションに指定されている場合にも、最低 1 つの宛先は成功する必
要があります。
カテゴリ
MANDATORY
OPTIONAL
属性のデータ型
キーワード
キーワード
最小属性値
該当なし
該当なし
最大属性値
該当なし
該当なし
デフォルト属性値
該当なし
該当なし
必須属性
該当なし
該当なし
属性との競合
OPTIONAL
MANDATORY
属性クラス
ALTER SESSION と ALTER
SYSTEM
ALTER SESSION と ALTER
SYSTEM
対応する V$ARCHIVE_DEST 列
BINDING
BINDING
関連する V$ARCHIVE_DEST 列
該当なし
該当なし
LOG_ARCHIVE_MIN_SUCCEED_DEST=n パラメータ（n は 1 から 10 の整数）は、ログ・ラ
イター・プロセスがオンライン REDO ログ・ファイルを上書きできるようになる前に、正
常にアーカイブしておく必要がある宛先の数を指定します。LOG_ARCHIVE_MIN_SUCCEED_
DEST=n の件数は、すべての必須の宛先とスタンバイ以外のオプションの宛先によって満た
されます。たとえば、次のようにパラメータを設定できます。
# Database must archive to at least two locations before
# overwriting the online redo log files.
LOG_ARCHIVE_MIN_SUCCEED_DEST = 2
12-24　Oracle Data Guard 概要および管理
MANDATORY および OPTIONAL
パラメータを設定する際は、次のことに注意します。
■
■
この属性は、宛先のデータ保護モードに影響を与えません。
1 つ以上のローカル宛先が必要であり、それらに OPTIONAL または MANDATORY を宣言
できます。
LOG_ARCHIVE_MIN_SUCCEED_DEST パラメータの最小値は 1 のため、最低 1 つのロー
カル宛先が操作上必須です。
■
■
■
必須の宛先のいずれかに（必須のスタンバイ宛先を含む）障害が発生すると、LOG_
ARCHIVE_MIN_SUCCEED_DEST パラメータは不適切になります。
LOG_ARCHIVE_MIN_SUCCEED_DEST パラメータ値を、宛先の数および必須の宛先数に
オプションのローカル宛先数を加えた数よりも大きく設定することはできません。
必須の宛先を遅延させたり、オンライン REDO ログ・ファイルの上書きを、スタンバ
イ・サイトへ REDO データを転送せずに実行する場合は、REDO ログ・ファイルをス
タンバイ・サイトに手動で転送する必要があります。
V$ARCHIVE_DEST 固定ビューの BINDING 列は、アーカイブ操作に障害がどのように影響す
るのかを指定します。
MANDATORY
ローカル・オンライン REDO ログ・ファイルが再利用可能になる前に、宛先への REDO
データの転送に成功する必要があることを指定します。
OPTIONAL
オンライン REDO ログ・ファイルが再利用可能になる前に、宛先への REDO データの転送
に成功する必要があることを指定します。LOG_ARCHIVE_MIN_SUCCEED_DEST パラメータ
に設定した値（プライマリ・データベースのログ・ライター・プロセスがオンライン REDO
ログ・ファイルを再利用する前に、REDO データを正常に受信する必要がある宛先の最小数
を定義します）が一致すると、オンライン REDO ログ・ファイルには再利用のためのマー
クが設定されます。
例
次の例は、MANDATORY 属性を示しています。
LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=denver MANDATORY'
LOG_ARCHIVE_DEST_STATE_3=ENABLE
LOG_ARCHIVE_DEST_n パラメータの属性
12-25
MAX_FAILURE および NOMAX_FAILURE
MAX_FAILURE および NOMAX_FAILURE
これらの属性は、障害が発生した宛先に対して、ログ転送サービスが通信の再確立を試行す
る回数を制御します。
■
■
MAX_FAILURE: プライマリ・データベースがスタンバイ・データベースでの再オープン
を完全に中止するまでの最大試行回数を指定します。
NOMAX_FAILURE: この属性を指定すると、障害が発生した宛先へのアーカイブ REDO
ログ・ファイルの転送を、繰返し無制限に試行できます。
MAX_FAILURE 属性および NOMAX_FAILURE 属性が指定されていない場合、デフォルトは
NOMAX_FAILURE です。
カテゴリ
MAX_FAILURE=count
NOMAX_FAILURE
属性のデータ型
数値
キーワード
最小属性値
0
該当なし
最大属性値
なし
該当なし
デフォルト属性値
なし
該当なし
必須属性
REOPEN
該当なし
属性との競合
NOMAX_FAILURE
MAX_FAILURE
SQL 文による動的な変更
ALTER SYSTEM
ALTER SYSTEM
対応する V$ARCHIVE_DEST 列
MAX_FAILURE
MAX_FAILURE
関連する V$ARCHIVE_DEST 列
FAILURE_COUNT、REOPEN_
SECS
該当なし
12-26　Oracle Data Guard 概要および管理
MAX_FAILURE および NOMAX_FAILURE
MAX_FAILURE=count
MAX_FAILURE 属性は、障害が発生した宛先に対し、ログ転送サービスが REDO データの転
送を繰返し試行する最大回数を指定します。これにより、障害が発生した宛先との通信を再
確立して REDO データの送信を再開するためのログ転送サービスでの試行回数が制限され
ます。MAX_FAILURE 属性を指定するときは、REOPEN 属性も指定して、障害が発生した宛
先との通信を再確立するための試行回数を制限する必要があります。指定した試行回数を超
過すると、その宛先は NOREOPEN 属性が指定されたものとして処理されます。
この属性を使用すると、失敗後に回数制限付きで REDO データの転送を再試行するように、
宛先に対する障害の解決方法を指定できます。MAX_FAILURE 属性を指定する場合は、
REOPEN 属性も指定し、特定の宛先に対するアーカイブ操作の頻度を指定する必要がありま
す。
再試行の回数を制限する設定 MAX_FAILURE 属性と REOPEN 属性の両方を 0（ゼロ）では
ない値に設定すると、ログ転送サービスは、アーカイブ操作の試行回数を MAX_FAILURE 属
性で指定されている回数に制限します。各宛先には、連続的に発生したアーカイブ障害の回
数を追跡する内部障害カウンタがあります。V$ARCHIVE_DEST 固定ビューの FAILURE_
COUNT 列で障害件数を確認できます。関連する REOPEN_SECS 列は、REOPEN 属性値を示し
ます。
なんらかの理由でアーカイブ操作に失敗すると、次の状態になるまで障害件数が増加しま
す。
■
障害が発生しなくなり、アーカイブが再開されるまで
■
障害件数が MAX_FAILURE 属性に設定されている値以上になるまで
注意 : 宛先の障害件数が、指定した MAX_FAILURE 属性の値に達した場
合、その宛先を再利用するには、MAX_FAILURE 属性値または他の属性を
修正する必要があります。この結果、障害件数がゼロ（0）にリセットされ
ます。
■
ALTER SYSTEM SET 文を発行して、MAX_FAILURE 属性（または宛先のその他の属性）
を動的に変更します。ALTER SYSTEM SET 文によって宛先が変更されると、障害件数
は 0（ゼロ）にリセットされます。このため、現在の障害件数の値よりも小さな値に
MAX_FAILURE 属性を設定する問題が回避されます。
注意 : QUOTA_USED 属性の変更など、実行時に宛先に対して行われる修
正は、障害件数に影響しません。
LOG_ARCHIVE_DEST_n パラメータの属性
12-27
MAX_FAILURE および NOMAX_FAILURE
障害件数が MAX_FAILURE 属性に設定された値以上になると、REOPEN 属性値は、暗黙的に
0（ゼロ）の値に設定されます。これによって、ログ転送サービスは、次のアーカイブ操作
では REDO データを代替アーカイブ先（ALTERNATE 属性で指定）に転送するようになりま
す。
アーカイブ操作を無制限に試行する設定 MAX_FAILURE 属性を指定せずに（または MAX_
FAILURE=0 または NOMAX_FAILURE 属性を指定し）
、REOPEN 属性に 0（ゼロ）ではない値
を指定すると、ログ転送サービスは、失敗した宛先に対して無制限にアーカイブを試行しま
す。宛先に MANDATORY 属性を設定すると、繰返し発生する障害の場合、オンライン REDO
ログ・ファイルは再利用されません。
NOMAX_FAILURE
NOMAX_FAILURE 属性を指定すると、失敗した宛先に対するアーカイブ操作を無制限に試行
できます。
NOMAX_FAILURE 属性は、MAX_FAILURE=0 に指定することと等価です。
例
次の例は、ログ転送サービスが、宛先 arc_dest に対して、アーカイブ操作を最高 3 回、5
秒ごとに試行できる指定を示しています。3 回目の試行後、アーカイブ操作に失敗すると、
その宛先は NOREOPEN 属性が指定されているものとして扱われます。
LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
12-28　Oracle Data Guard 概要および管理
NET_TIMEOUT および NONET_TIMEOUT
NET_TIMEOUT および NONET_TIMEOUT
NET_TIMEOUT 属性および NONET_TIMEOUT 属性は、ネットワーク接続を終了する前に、
ログ・ライター・プロセスが待機する時間を判断します。
■
■
NET_TIMEOUT: ネットワーク接続を終了する前に、プライマリ・システム上のログ・ラ
イター・プロセスがネットワーク・サーバー（LNSn）プロセスからのステータスを待
機する時間を秒単位で指定します。
NONET_TIMEOUT: 以前に NET_TIMEOUT 属性で指定したタイムアウト値を中止または無
効にします。
NET_TIMEOUT 属性を指定しない場合（または NONET_TIMEOUT 属性を指定した場合）
、プ
ライマリ・データベースは停止する可能性があります。この状況を回避するには、NET_
TIMEOUT に 0（ゼロ）以外の小さい値を指定することによって、ネットワーク・サーバーか
らステータスを待機する際、ユーザーが指定したタイムアウト時間の期限が切れた後に、プ
ライマリ・データベースが操作を続行できます。
NET_TIMEOUT 属性および NONET_TIMEOUT 属性が指定されていない場合、デフォルトは
NONET_TIMEOUT です。
1
カテゴリ
NET_TIMEOUT=seconds
NONET_TIMEOUT
属性のデータ型
数値
該当なし
最小属性値
1
該当なし
最大属性値
1200
該当なし
デフォルト属性値
180 秒
該当なし
必須属性
LGWR と SYNC=PARALLEL、または
LGWR と ASYNC > 0
該当なし
属性との競合
ARCH、LOCATION、NONET_
TIMEOUT、LGWR と
SYNC=NOPARALLEL、LGWR と
ASYNC=0
NET_TIMEOUT
属性クラス
ALTER SYSTEM
ALTER SYSTEM
対応する V$ARCHIVE_DEST 列
NET_TIMEOUT
NET_TIMEOUT
関連する V$ARCHIVE_DEST 列
該当なし
該当なし
1
最小値は 1 秒まで設定できますが、不適切なエラーやスタンバイ・データベースからの切断を回避す
るために、最小値は 8 ～ 10 秒に設定することをお薦めします。
LOG_ARCHIVE_DEST_n パラメータの属性
12-29
NET_TIMEOUT および NONET_TIMEOUT
NET_TIMEOUT=seconds
NET_TIMEOUT 属性が使用されるのは、ログ・ライター・プロセスがネットワーク・サー
バー（LNSn）プロセスを使用して REDO データを転送する場合、および ASYNC 属性また
は SYNC=PARALLEL 属性のいずれかが指定されている場合のみです。
ログ・ライター・プロセスは、指定時間が経過するまで、ネットワーク I/O に関するステー
タスの受信を待機します。ネットワーク切断の可能性がある場合、ネットワーク・タイムア
ウトによって終了した切断であっても、ログ・ライター・プロセスはスタンバイ・データ
ベースへの再接続を自動的に試行して、ネットワークの停止およびネットワーク終了エラー
を解決します。通常は、ネットワークが物理的に破損している場合を除いて、ログ・ライ
ター・プロセスはネットワークに正常に再接続できます。再接続の試行が継続される時間
は、次の要因によって決まります。
■
■
プライマリ・データベースの NET_TIMEOUT 属性の値
スタンバイ・データベースの EXPIRE_TIME パラメータ値またはキープ・アライブ間隔
の値
プライマリ・データベースのネットワーク接続が終了した可能性がある場合にも、スタ
ンバイ・データベースのネットワーク接続は、対応する TCP/IP ネットワーク・タイ
マーが期限切れになるまでアクティブなままです。このため、各スタンバイ・データ
ベースに設定されている Oracle Net の EXPIRE_TIME パラメータを使用して、プライ
マリ・データベースの NET_TIMEOUT 属性の設定を調整する必要があります。
注意 : 通常、スタンバイ・システムの Oracle Net EXPIRE_TIME パラ
メータは、プライマリ・システムの NET_TIMEOUT 属性に指定されている
タイムアウト時間までに期限切れとなるように設定してください。
EXPIRE_TIME パラメータは分単位で示します。
■
プライマリ・データベースの保護モード。これによって、再接続が行われる最大時間が
判断されます。ログ・ライター・プロセスがスタンバイ・データベースへの再接続を試
行する期間のガイドラインとして、次の見積りを使用してください。
–
最大保護モードでは、ログ・ライター・プロセスはおよそ 5 分間再接続を試行しま
す。
–
最大可用性モードでは、ログ・ライター・プロセスは約 15 秒間再接続を試みます。
–
最大パフォーマンス・モードでは、ログ・ライター・プロセスは約 15 秒間再接続
を試みます。
たとえば、NET_TIMEOUT 属性値が 60 秒、EXPIRE_TIME が 1 分に設定されているプライマ
リ・データベースが最大可用性保護モードで動作している場合、接続には 1 分、スタンバ
イ・データベースへの接続を終了するには最大 3 分の時間が実際には必要と考えられます。
12-30　Oracle Data Guard 概要および管理
NET_TIMEOUT および NONET_TIMEOUT
注意 : 最大保護モードで実行している場合は、NET_TIMEOUT に適切な
値を指定するよう注意してください。不適切なネットワークの障害を検出
すると、プライマリ・インスタンスが停止する可能性があります。
プライマリ・システムとスタンバイ・システムのタイムアウト・パラメータ値は慎重に調整
してください。不適切な場合、プライマリ・システムでネットワーク上の問題が発生して
ネットワークが切断されたときに、スタンバイ・データベースでデフォルトのネットワー
ク・タイムアウト値が過度に高く設定されていると、スタンバイ・データベースがネット
ワークの切断を認識しない可能性があります。ネットワーク・タイマーが適切に設定されて
いない場合、スタンバイ・データベースはタイムアウトしておらず、中断したネットワーク
接続は依然として有効に見えるため、スタンバイ・データベースと連結しているプライマ
リ・データベースでのログ・ライター・プロセスによって行われる、その後の試行はエラー
となります。『Oracle Net Services 管理者ガイド』を参照してください。
NONET_TIMEOUT
NONET_TIMEOUT 属性は、ログ・ライター・プロセスが、システムに設定されているデフォ
ルトのネットワーク・タイムアウト時間が経過するまで待機することを意味します。デフォ
ルトのネットワーク・タイムアウト時間は、システムによって異なります。
例
次の例は、NET_TIMEOUT 属性を使用して、プライマリ・データベースのネットワーク・タ
イムアウト値を 40 秒に指定する方法を示しています。
LOG_ARCHIVE_DEST_2='SERVICE=stby1 LGWR NET_TIMEOUT=40 SYNC=PARALLEL'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_n パラメータの属性
12-31
QUOTA_SIZE および NOQUOTA_SIZE
QUOTA_SIZE および NOQUOTA_SIZE
LOG_ARCHIVE_DEST_n パラメータの QUOTA_SIZE 属性および NOQUOTA_SIZE 属性は、
ローカル宛先で使用できるディスク・デバイス上の物理記憶域にある、512 バイトのブロッ
クの最大数を示します。
QUOTA_SIZE 属性および NOQUOTA_SIZE 属性が指定されていない場合、デフォルトは
NOQUOTA_SIZE です。LOCATION 属性は、USE_DB_RECOVERY_FILE_DEST 値を指定した
場合のみ、QUOTA_SIZE および QUOTA_USED と競合します。
カテゴリ
QUOTA_SIZE=blocks
NOQUOTA_SIZE
属性のデータ型
数値
キーワード
最小属性値
0 ブロック
該当なし
最大属性値
無制限ブロック
該当なし
デフォルト属性値
該当なし
該当なし
必須属性
LOCATION
該当なし
属性との競合
NOQUOTA_SIZE、
DEPENDENCY、SERVICE、
LOCATION
QUOTA_SIZE
属性クラス
ALTER SYSTEM
ALTER SYSTEM
対応する V$ARCHIVE_DEST
列
QUOTA_SIZE
QUOTA_SIZE
関連する V$ARCHIVE_DEST
列
QUOTA_USED
QUOTA_USED
12-32　Oracle Data Guard 概要および管理
QUOTA_SIZE および NOQUOTA_SIZE
QUOTA_SIZE=blocks
QUOTA_SIZE 属性は、ローカル宛先で使用できるディスク・デバイス上の物理記憶域にあ
る、512 バイトのブロックの最大数を示します。物理デバイスで異なるブロック・サイズが
使用されている場合でも、この値は 512 バイトのブロック数で指定します。オプションの接
尾辞の値、K、M、G はそれぞれ、千、百万、十億を表します（1K の値は 1,000 の 512 バイ
トのブロックを意味します）
。
ローカルのアーカイブ先は、物理ディスクのすべて、または一部を占有できるように指定で
きます。たとえば、Real Application Clusters 環境では、Sun Clusters などで使用可能なクラ
スタ化ファイル・システムを介して、1 つの物理的なアーカイブ REDO ログ・ファイルの
ディスク・デバイスを 2 つ以上の個別のノードで共有できます。インスタンス間では、初期
化パラメータの情報が共有されていないため、Real Application Clusters ノードは、アーカ
イブ REDO ログ・ファイルの物理ディスク・デバイスが他のインスタンスと共有されてい
ることを認識していません。このため、宛先ディスク・ドライブがいっぱいになったとき
に、重大な問題が発生します。すなわち、すでにいっぱいになっているデバイスに対し、す
べてのインスタンスがアーカイブを実行するまで、エラーは検出されません。これはデータ
ベースの可用性に影響を及ぼします。
たとえば、8GB ディスク・デバイス /dev/arc_dest について考えます。このデバイスは
さらに、ノード固有のディレクトリ、node_a、node_b、node_c に副分割されます。デー
タベース管理者は、これらの各インスタンスが最大 2GB を使用できるように指定できます。
これによって、その他の目的に追加の 2GB が使用できるようになります。この例を図 12-2
に示します。
図 12-2 宛先へのディスク・クオータの指定
LOG_ARCHIVE_DEST_n パラメータの属性
12-33
QUOTA_SIZE および NOQUOTA_SIZE
インスタンスは、割当て制限を超えるディスク・デバイスを使用することはありません。
割当て制限は、フォアグラウンドのアーカイブ操作、アーカイバ・プロセス、ログ・ライ
ター・プロセスなどの宛先のすべてのユーザーに共通です。
オラクル社では、ALTERNATE 属性と QUOTA_SIZE 属性を一緒に使用することをお薦めしま
す。ただし、これは必須ではありません。
12-6 ページの ALTERNATE および NOALTERNATE 属性も参照してください。
NOQUOTA_SIZE
NOQUOTA_SIZE 属性、または値が 0（ゼロ）値の QUOTA_SIZE 属性を使用すると、この宛
先によるディスク・デバイスの使用が無制限であることを示します。これはデフォルトの動
作です。
例
次の例は、QUOTA_SIZE 属性が指定されている LOG_ARCHIVE_DEST_n パラメータを示し
ています。
LOG_ARCHIVE_DEST_4='QUOTA_SIZE=100K'
12-34　Oracle Data Guard 概要および管理
QUOTA_USED および NOQUOTA_USED
QUOTA_USED および NOQUOTA_USED
LOG_ARCHIVE_DEST_n パラメータの QUOTA_USED 属性および NOQUOTA_USED 属性は、指
定した宛先にアーカイブされたデータの 512 バイトのブロック数を示します。
QUOTA_USED 属性および NOQUOTA_USED 属性が指定されていない場合、デフォルトは
NOQUOTA_USED です。QUOTA_USED 属性のリモートのアーカイブ先に対するデフォルト値
は 0（ゼロ）です。LOCATION 属性は、USE_DB_RECOVERY_FILE_DEST 値を指定した場合
のみ、QUOTA_SIZE および QUOTA_USED と競合します。
カテゴリ
QUOTA_USED=blocks
NOQUOTA_USED
属性のデータ型
数値
キーワード
最小属性値
0 ブロック
該当なし
最大属性値
無制限ブロック
該当なし
デフォルト属性値
該当なし
該当なし
必須属性
LOCATION
該当なし
属性との競合
NOQUOTA_USED、
DEPENDENCY、SERVICE、
LOCATION
QUOTA_USED
属性クラス
ALTER SYSTEM
ALTER SYSTEM
対応する V$ARCHIVE_DEST 列
QUOTA_USED
QUOTA_USED
関連する V$ARCHIVE_DEST 列
QUOTA_SIZE
QUOTA_SIZE
QUOTA_USED=blocks
QUOTA_USED 属性は、指定のローカル宛先にアーカイブされたデータの 512 バイトのブロッ
ク数を示します。物理デバイスで異なるブロック・サイズが使用されている場合でも、この
値は 512 バイトのブロック数で指定します。オプションの接尾辞の値、K、M、G はそれぞ
れ、千、百万、十億を表します（1K の値は 1,000 の 512 バイトのブロックを意味します）。
この属性は、セッション・レベルでは修正できません。
宛先に対して QUOTA_SIZE 属性の値を 0（ゼロ）よりも大きな値に指定し、データベース初
期化パラメータ・ファイルの QUOTA_USED 属性を指定しない場合、QUOTA_USED 属性値は
データベースを最初にマウントしたときに自動的に決定されます。QUOTA_USED 属性値のデ
フォルトはローカルのアーカイブ先デバイス上にある実際のブロック数になります。計算し
た QUOTA_USED 属性値が QUOTA_SIZE 属性値を超過すると、QUOTA_SIZE 属性値は自動的
に調整され、実際に使用した記憶域が反映されます。このように自動的に計算された
QUOTA_USED 値は、ローカルのアーカイブ先に対してのみ適用されます。
LOG_ARCHIVE_DEST_n パラメータの属性
12-35
QUOTA_USED および NOQUOTA_USED
注意 : QUOTA_USED 属性の実行時の値は、アーカイブ操作が開始される
と自動的に変更されます。QUOTA_USED 属性値は、宛先の割当て制限サイ
ズに対して事前に自動的に割り当てられます。この属性の値を変更する必
要はありません。
実行時に QUOTA_SIZE 属性値が動的に修正され、QUOTA_USED 属性値が修正されない場合、
QUOTA_USED 属性値は動的に再計算されません。
ローカル宛先の場合、QUOTA_USED 属性値はアーカイブ操作の開始時に増加されます。その
結果の値が QUOTA_SIZE 属性値よりも大きい場合、宛先の状態が FULL に変化し、その宛
先はアーカイブ操作の開始前に拒否されます。
QUOTA_SIZE と QUOTA_USED 属性は、一緒に使用すると、アーカイブ操作が始まる前に
ディスク領域の不足を検出できるため、非常に重要です。QUOTA_SIZE 属性値が 100K、
QUOTA_USED 属性値も 100K の場合を考えます。宛先の状態は、この時点では VALID です。
しかし、1 ブロックをアーカイブすると、その結果 QUOTA_USED 属性値は 101K に変更され
ます。これは、QUOTA_SIZE 属性値を超過しています。このため、宛先の状態は、FULL に
変更され、この宛先はアーカイブ操作が始まる前に拒否されます。
NOQUOTA_USED
指定の宛先でアーカイブできるデータのブロック数を制限しないことを指定します。
例
この値は Data Guard によって自動的に設定されます。QUOTA_USED 属性および NOQUOTA_
USED 属性の値を変更する必要はありません。
12-36　Oracle Data Guard 概要および管理
REGISTER および NOREGISTER
REGISTER および NOREGISTER
LOG_ARCHIVE_DEST_n パラメータの REGISTER 属性および NOREGISTER 属性は、アーカ
イブ REDO ログ・ファイルの位置を宛先サイトに記録するかどうかを示します。
REGISTER 属性および NOREGISTER 属性が指定されていない場合、デフォルトは
REGISTER です。
カテゴリ
REGISTER
NOREGISTER
属性のデータ型
キーワード
キーワード
最小属性値
該当なし
該当なし
最大属性値
該当なし
該当なし
デフォルト属性値
該当なし
該当なし
必須属性
該当なし
SERVICE
属性との競合
NOREGISTER、NOALTERNATE
REGISTER、LOCATION
属性クラス
ALTER SESSION と ALTER
SYSTEM
ALTER SESSION と
ALTER SYSTEM
対応する V$ARCHIVE_DEST 列
DESTINATION
DESTINATION
関連する $ARCHIVE_DEST 列
TARGET
TARGET
LOG_ARCHIVE_DEST_n パラメータの属性
12-37
REGISTER および NOREGISTER
REGISTER
REGISTER 属性は、アーカイブ REDO ログ・ファイルの位置が、対応する宛先に記録され
ることを示します。
フィジカル・スタンバイ宛先の場合、アーカイブ REDO ログ・ファイルの名前は、宛先
データベースの制御ファイルに記録され、REDO Apply で使用されます。
ロジカル・スタンバイ・データベースの場合、アーカイブ REDO ログ・ファイルの名前は、
ロジカル・スタンバイ・データベースの制御ファイルで管理されている表領域に記録され、
SQL Apply で使用されます。
REGISTER 属性は、宛先が Data Guard のスタンバイ・データベースであることを意味しま
す。
デフォルトでは、リモート宛先でのアーカイブ REDO ログ・ファイルの位置は、宛先の
STANDBY_ARCHIVE_DEST および LOG_ARCHIVE_FORMAT 初期化パラメータによって決ま
ります。
注意 : 各スタンバイ・データベースで SQL の ALTER DATABASE
REGISTER LOGFILE filespec 文を実行して、REGISTER 属性を設定す
ることもできます。この SQL 文の例は、7-16 ページの「フェイルオー
バーの手順」を参照してください。
NOREGISTER
オプションの NOREGISTER 属性は、アーカイブ REDO ログ・ファイルの位置が、対応する
宛先に記録されないことを示します。これは、リモートの宛先についてのみの設定です。各
アーカイブ REDO ログ・ファイルの位置は、常にプライマリ・データベースの制御ファイ
ルに記録されます。
NOREGISTER 属性は、宛先が Data Guard 構成の一部ではないスタンバイ・データベースで
ある場合に必要です。たとえば、プライマリ・データベースがスタンバイ・データベースに
REDO データを自動転送するのは、スタンバイ・データベースが Data Guard 環境で実装さ
れている場合に限られます。したがって、スタンバイ・データベースが Data Guard 構成の
一部として確立されていない場合は、オペレーティング・システムのコピー・ユーティリ
ティなどの手段を使用して、ログ・ファイルを手動で転送する必要があります。
例
次の例は、REGISTER 属性が指定されている LOG_ARCHIVE_DEST_n パラメータを示してい
ます。
LOG_ARCHIVE_DEST_5='REGISTER'
12-38　Oracle Data Guard 概要および管理
REOPEN および NOREOPEN
REOPEN および NOREOPEN
LOG_ARCHIVE_DEST_n パラメータの REOPEN 属性および NOREOPEN 属性は、アーカイバ・
プロセス（ARCn）またはログ・ライター・プロセス（LGWR）が以前に障害が発生した宛
先に再度アクセスしようとするまでの最小時間を秒単位で指定します。NOREOPEN を指定す
ると、この属性をオフにできます。
REOPEN 属性および NOREOPEN 属性が指定されていない場合、デフォルトは REOPEN です。
カテゴリ
REOPEN [=seconds]
NOREOPEN
属性のデータ型
数値
キーワード
最小属性値
0秒
該当なし
最大属性値
無制限秒数
該当なし
デフォルト属性値
300 秒
該当なし
必須属性
該当なし
該当なし
属性との競合
NOREOPEN
REOPEN
属性クラス
ALTER SESSION と ALTER
SYSTEM
ALTER SESSION と ALTER
SYSTEM
対応する V$ARCHIVE_DEST 列
REOPEN_SECS
REOPEN_SECS
関連する V$ARCHIVE_DEST 列
MAX_FAILURE
MAX_FAILURE
LOG_ARCHIVE_DEST_n パラメータの属性
12-39
REOPEN および NOREOPEN
REOPEN[=seconds]
REOPEN は、接続障害のみでなく、すべてのエラーに適用されます。エラーには、ネット
ワーク障害、ディスク・エラー、クオータ例外などがありますが、これらに制限されませ
ん。
OPTIONAL 宛先に REOPEN を指定すると、エラーが発生した場合でも、Oracle データベース
でオンライン REDO ログ・ファイルを上書きできます。MANDATORY 宛先に REOPEN を指定
すると、ログ転送サービスは、REDO データを正常に転送できない場合に、プライマリ・
データベースを停止します。この場合には、次のオプションを考慮します。
■
宛先を遅延させる、宛先を OPTIONAL として指定する、または SERVICE 属性値を変更
することで宛先を変更。
■
代替宛先の指定。
■
宛先の無効化。
REOPEN 属性を使用する場合は、次のことに注意します。
■
■
■
アーカイバ・プロセスまたはログ・ライター・プロセスが宛先を再オープンするのは、
ログ・ファイルの先頭からアーカイブ操作を開始するときのみで、現行の操作の途中で
宛先を再オープンすることはありません。アーカイブ・プロセスでは常に先頭からロ
グ・ファイルのコピーが行われます。
アーカイブ・プロセスは、記録されたエラーの時刻に REOPEN の間隔を加算した時刻が
現在の時刻に達していないかどうかによって、REOPEN 属性に使用した値が指定した値
であるかデフォルト値であるかをチェックします。現在の時刻に達していない場合は、
その宛先に対するアーカイブ操作が再試行されます。
LOG_ARCHIVE_DEST_n 初期化パラメータの MAX_FAILURE=count 属性を指定すること
で、ログ・アーカイブに障害が起きた後に宛先に対し再試行する回数を制御できます。
NOREOPEN
NOREOPEN を指定すると、障害が発生した宛先は、次の手順を実行するまで無効のままにな
ります。
■
■
■
手動で宛先を再度使用可能にする。
ALTER SYSTEM SET 文または ALTER SESSION SET 文を REOPEN 属性を指定して実行
する。
インスタンスを再起動する。
12-40　Oracle Data Guard 概要および管理
REOPEN および NOREOPEN
例
次の例は、REOPEN 属性が指定されている
LOG_ARCHIVE_DEST_n パラメータを示しています。
LOG_ARCHIVE_DEST_3='SERVICE=stby1 MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_3=ENABLE
LOG_ARCHIVE_DEST_n パラメータの属性
12-41
SYNC および ASYNC
SYNC および ASYNC
LOG_ARCHIVE_DEST_n パラメータの SYNC 属性および ASYNC 属性は、ログ・ライター・
プロセス（LGWR）を使用している場合にネットワーク I/O が同期または非同期のいずれで
実行されるかを指定します。
注意 : プライマリ・データベースが最大保護モードまたは最大可用性
モードの場合、スタンバイ REDO ログ・ファイルのアーカイブ先とログ・
ライター・プロセスによる宛先は、自動的に SYNC モードになります。
LGWR 属性を指定して、SYNC 属性または ASYNC 属性のいずれも指定しない場合、デフォル
トは SYNC=PARALLEL です。宛先に ARCH 属性が指定されている場合は、SYNC 属性のみが
有効になります。ARCH 属性と ASYNC 属性を一緒に指定すると、エラー・メッセージが戻さ
れます。
カテゴリ
SYNC[=parallel_option]
ASYNC[=blocks]
属性のデータ型
キーワード
数値
最小属性値
該当なし
0
最大属性値
該当なし
102,400
注意 : オペレーティング・シ
ステムによっては、実際の許
容値が小さくなることがあり
ます。Data Guard では、必要
に応じて、値が適切なブロッ
ク数に動的に調整されます。
デフォルト属性値
該当なし
61,440
必須属性
該当なし
LGWR
属性との競合
ASYNC
SYNC、LOCATION、ARCH
属性クラス
ALTER SESSION と ALTER
SYSTEM
ALTER SYSTEM
対応する V$ARCHIVE_DEST 列
TRANSMIT_MODE
TRANSMIT_MODE
関連する V$ARCHIVE_DEST 列
該当なし
ASYNC_BLOCKS
12-42　Oracle Data Guard 概要および管理
SYNC および ASYNC
注意 : LGWR プロセスを使用するよう宛先が明示的に構成されており
（LOG_ARCHIVE_DEST_n 初期化パラメータの LGWR 属性が指定されてい
る）
、なんらかの理由でログ・ライター・プロセスが宛先へのアーカイブ
を実行できなくなった場合、ログ転送サービスは、LOG_ARCHIVE_
LOCAL_FIRST=FALSE が指定されていても、アーカイブ操作がデフォル
ト（LOG_ARCHIVE_LOCAL_FIRST=TRUE）の動作で実行されるように、
ARCn プロセスを使用します。
たとえば、スタンバイ・データベースの障害またはネットワーク障害に
よって LGWR プロセスが失敗すると、ARCn プロセスがリモート宛先へ
の REDO データの転送を実行します。Data Guard は、オンライン REDO
ログ・ファイルを LGWR プロセスで迅速に使用できるようにするために、
まずローカルの宛先にアーカイブすることによって、プライマリ・データ
ベースへの影響を最小限に抑えます。
SYNC=PARALLEL
SYNC=NOPARALLEL
SYNC 属性は、宛先に対するネットワーク I/O が同期して実行されることを指定します。こ
れは、I/O が開始されると、LGWR プロセスが I/O の完了を待ってから処理を続行するこ
とを意味します。SYNC 属性は非データ消失環境の設定に必要です。つまり、この属性に
よって、REDO レコードは、処理を継続する前にスタンバイ・サイトに正常に転送されるよ
うになります。
LGWR プロセスが、SYNC 属性を使用する複数のスタンバイ宛先への転送を行うものと定義
されている場合、ユーザーは、それらの各宛先に対して SYNC=PARALLEL または
SYNC=NOPARALLEL を指定できます。
■
■
SYNC=NOPARALLEL を使用すると、LGWR プロセスは、最初の宛先への I/O を開始し、
それが終了するのを待ってから、次の宛先への I/O を開始します。SYNC=NOPARALLEL
を指定することは、ASYNC=0 を指定することと同じです。
SYNC=PARALLEL を使用すると、LGWR プロセスは、その宛先の LNSn プロセスにネッ
トワーク I/O 要求を発行して、LNSn プロセスからの応答を待ちます。LNSn プロセス
は REDO データをバッファに書き込むのではなく、スタンバイ・データベースに即時
に転送し、ネットワーク I/O に関するステータス情報を使用して、待機している
LGWR プロセスに応答します。
SYNC 属性で定義された宛先が 1 つ以上ある場合、SYNC=PARALLEL を指定すると便利
です。これは、LGWR プロセスが宛先ごとに個別の LNSn プロセスを使用するためで
す。したがって、LGWR は、複数の宛先へのネットワーク I/O をパラレルで開始する
LNSn プロセスに対して、I/O 要求を発行します。I/O が開始されると、LNSn プロセス
はすべての I/O 要求が完了するのを待ってから処理を続行し、LGWR はすべての LNSn
プロセスからの応答を待ちます。事実上、これは同時に複数の同期 I/O 要求を実行する
ことと同じです。LGWR 属性および SYNC 属性で定義された宛先が 1 つ以上ある場合、
LOG_ARCHIVE_DEST_n パラメータの属性
12-43
SYNC および ASYNC
SYNC=PARALLEL は、SYNC=NOPARALLEL よりも高い頻度で使用される可能性がありま
す。Data Guard 構成における LNSn プロセスについては、図 5-6 を参照してください。
PARALLEL 修飾子および NOPARALLEL 修飾子では、複数の宛先が関係している場合のみ相
違が生じるため、すべての宛先に同じ値を使用することをお薦めします。
ASYNC[=blocks]
ASYNC 属性は、宛先に対するネットワーク I/O が非同期で実行されることを指定します。オ
プションでブロック数（0 ～ 102,400）を指定して、使用する SGA ネットワーク・バッファ
のサイズを決定できます。オペレーティング・システムによっては、実際の最大許容値が小
さくなることがあります。Data Guard では、必要に応じて、値が適切なブロック数に動的に
調整されます。
非同期処理では、LGWR プロセスは、その宛先の LNSn プロセスにネットワーク I/O 要求
を発行し、その I/O の完了を待たずに（すなわち I/O の完了ステータスをチェックしない
まま）
、次の要求の処理を続行します。ASYNC 属性を使用すると、プライマリ・データベー
スにほとんど影響を与えることなくスタンバイ環境をメンテナンスできます。
LNSn プロセスが遅いと（ネットワークの速度が遅い場合など）
、LGWR プロセスが指定さ
れた容量まで ASYNC バッファでいっぱいになり、非同期アーカイブ操作のときにエラーが
発生します。この場合、ARCn プロセスは、宛先の REOPEN 属性および MAX_FAILURE 属性
の現在の値に基づいて、REDO データを転送します。Data Guard 構成における LNSn プロセ
スについては、図 5-6 を参照してください。
ASYNC 属性の使用では、ネットワーク I/O を開始するためのイベントがいくつかあります。
■
■
■
■
■
LGWR 要求が、現行の使用可能バッファ領域を超えた場合は、既存のバッファがスタン
バイ・データベースに転送されます。LGWR プロセスは、十分なバッファ領域が再び確
保されるまで待機状態になります。
プライマリ・データベースのログ・スイッチは、ログ・スイッチが完了する前にバッ
ファ内のすべての REDO データをスタンバイ・データベースに転送します。
プライマリ・データベースが正常に停止した場合。プライマリ・データベースを即時停
止すると、バッファ内の REDO データは廃棄されます。スタンバイ・データベースを停
止した場合も、宛先に対するバッファ内の REDO データは廃棄されます。
プライマリ・データベースが、一定期間 REDO アクティビティを行わなかったとき。
データベースが非アクティブな状態を維持する時間はシステムで決定されるため、変更
できません。
REDO 生成の速さが、実行時のネットワーク待機時間を超え、十分な領域が使用可能な
場合、LGWR 要求はバッファに書き込まれます。領域が十分でない場合は、既存のバッ
ファがスタンバイ・データベースへ転送されます。LGWR プロセスは、十分なバッファ
領域が再び確保されるまで待機状態になります。
12-44　Oracle Data Guard 概要および管理
SYNC および ASYNC
例
次の例は、SYNC 属性が指定されている LOG_ARCHIVE_DEST_n パラメータを示していま
す。
LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR SYNC'
LOG_ARCHIVE_DEST_STATE_3=ENABLE
LOG_ARCHIVE_DEST_n パラメータの属性
12-45
TEMPLATE および NOTEMPLATE
TEMPLATE および NOTEMPLATE
LOG_ARCHIVE_DEST_n パラメータの TEMPLATE 属性および NOTEMPLATE 属性は、スタン
バイ宛先のディレクトリ仕様、およびアーカイブ REDO ログ・ファイル名またはスタンバ
イ REDO ログ・ファイル名の形式テンプレートを定義します。これらの属性は、プライマ
リまたはスタンバイ初期化パラメータ・ファイルのいずれかに指定できます。ただし、属性
が適用されるのは、アーカイブしているデータベース・ロールに対してのみです。
TEMPLATE 属性は、リモート・アーカイブ先の初期化パラメータ STANDBY_ARCHIVE_DEST
および LOG_ARCHIVE_FORMAT の設定を上書きします。
TEMPLATE 属性および NOTEMPLATE 属性は、リモート・アーカイブ先（つまり、SERVICE
属性で指定される宛先）でのみ有効です。
注意 : LGWR 属性も指定されている宛先で使用した場合、ARCn プロセス
による再アーカイブでは、TEMPLATE 指定は使用されません。これは、保
護されている宛先にとって重要です。
この属性にはデフォルト値はありません。
カテゴリ
TEMPLATE=filename_template
NOTEMPLATE
属性のデータ型
文字列値
該当なし
最小属性値
該当なし
該当なし
最大属性値
該当なし
該当なし
デフォルト属性値
該当なし
該当なし
必須属性
SERVICE
該当なし
属性との競合
NOTEMPLATE、LOCATION、
REGISTER=location_format
TEMPLATE
属性クラス
ALTER SESSION と ALTER SYSTEM ALTER SESSION と
ALTER SYSTEM
対応する
V$ARCHIVE_DEST 列
REMOTE_TEMPLATE
REMOTE_TEMPLATE
関連する V$ARCHIVE_DEST 列
REGISTER
REGISTER
12-46　Oracle Data Guard 概要および管理
TEMPLATE および NOTEMPLATE
TEMPLATE=filename_template
オプションの TEMPLATE 属性を使用して、スタンバイ宛先のディレクトリ指定、およびアー
カイブ REDO ログ・ファイル名またはスタンバイ REDO ログ・ファイル名の形式を定義し
ます。この定義は、スタンバイ宛先の STANDBY_ARCHIVE_DEST および LOG_ARCHIVE_
FORMAT 初期化パラメータで定義されたデフォルトのファイル名形式とは異なるファイル名
を生成する場合に使用されます。
TEMPLATE 属性の filename_template 値には、表 12-2 に示す %s、%t および %r ディレクティ
ブを指定する必要があります。
表 12-2 TEMPLATE 属性のディレクティブ
ディレクティブ
説明
%a
データベース・アクティブ ID を代入します。
%A
0（ゼロ）を埋め込んだデータベース・アクティブ ID を代入しま
す。
%d
データベース ID を代入します。
%D
0（ゼロ）を埋め込んだデータベース ID を代入します。
%t
インスタンス・スレッド番号を代入します。
%T
0（ゼロ）を埋め込んだインスタンス・スレッド番号を代入しま
す。
%s
ログ・ファイル順序番号を代入します。
%S
0（ゼロ）を埋め込んだログ・ファイル順序番号を代入します。
%r
リセットログ ID を代入します。
%R
0（ゼロ）を埋め込んだリセットログ ID を代入します。
filename_template 値は、スタンバイ宛先に転送され、そこで変換および検証された後、ファ
イル名が作成されます。
TEMPLATE 属性が指定されていない場合、設定は、REGISTER と同じになります。
NOTEMPLATE
オプションの NOTEMPLATE 属性を使用すると、以前に指定した TEMPLATE 属性を取り消し
て、初期化パラメータ STANDBY_ARCHIVE_DEST および LOG_ARCHIVE_FORMAT によって
定義されたファイル名形式テンプレートを有効にできます。
LOG_ARCHIVE_DEST_n パラメータの属性
12-47
TEMPLATE および NOTEMPLATE
例
次の例では、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
12-48　Oracle Data Guard 概要および管理
VALID_FOR
VALID_FOR
LOG_ARCHIVE_DEST_n パラメータの VALID_FOR 属性により、次の要因に基づき、ログ転
送サービスが REDO データを宛先にいつ転送できるかを識別します。
■
■
データベースがプライマリ・ロールとスタンバイ・ロールのどちらで現在実行されてい
るか
オンライン REDO ログ・ファイルまたはスタンバイ REDO ログ・ファイル（あるいはそ
の両方）が、現在この宛先のデータベースでアーカイブされているかどうか
この属性のデフォルト値は、VALID_FOR=(ALL_LOGFILES, ALL_ROLES) です。
カテゴリ
VALID_FOR=(redo_log_type, database_role)
属性のデータ型
文字列値
最小属性値
該当なし
最大属性値
該当なし
デフォルト属性値
VALID_FOR=(ALL LOGFILES, ALL_ROLES)
注意 : ロジカル・スタンバイ・データベースには、デフォル
ト値 VALID_FOR=(ALL LOGFILES, ALL_ROLES) を使用
しないでください。詳細は、5-23 ページの「VALID_FOR 属
性を使用したロール・ベースの宛先の指定」および 10-5
ページの「プライマリ・データベースおよびロジカル・スタ
ンバイ・データベースの構成」の使用例を参照してくださ
い。
必須属性
該当なし
属性との競合
該当なし
属性クラス
ALTER SESSION と ALTER SYSTEM
対応する
V$ARCHIVE_DEST 列
VALID_NOW、VALID_TYPE および VALID_ROLE
関連する V$ARCHIVE_DEST 列
該当なし
LOG_ARCHIVE_DEST_n パラメータの属性
12-49
VALID_FOR
LOG_ARCHIVE_DEST_n 宛先ごとにこれらの要因を構成するには、キーワードのペア
（VALID_FOR=(redo_log_type,database_role)）を使用してこの属性を指定します。
■
■
redo_log_type キーワードは、次のいずれかにアーカイブする場合に有効な宛先を識別し
ます。
–
ONLINE_LOGFILE: この宛先は、オンライン REDO ログ・ファイルをアーカイブす
る場合のみ有効です。
–
STANDBY_LOGFILE: この宛先は、スタンバイ REDO ログ・ファイルをアーカイブ
する場合のみ有効です。
–
ALL_LOGFILES: この宛先は、オンライン REDO ログ・ファイルまたはスタンバイ
REDO ログ・ファイルをアーカイブする場合に有効です。
database_role キーワードは、この宛先がアーカイブに有効なロールを識別します。
–
PRIMARY_ROLE: この宛先は、データベースがプライマリ・ロールで実行されてい
る場合のみ有効です。
–
STANDBY_ROLE: この宛先は、データベースがスタンバイ・ロールで実行されてい
る場合のみ有効です。
–
ALL_ROLES: この宛先は、データベースがプライマリ・ロールまたはスタンバイ・
ロールで実行されている場合に有効です。
注意 : キーワードには、単数形も複数形も使用できます。たとえば、
PRIMARY_ROLE や PRIMARY_ROLES、および ONLINE_LOGFILE や
ONLINE_LOGFILES のいずれも指定できます。
次の表は、VALID_FOR 属性の値と、それぞれの値が使用されるロールを示しています。
表 12-3 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
アクティブ
非アクティブ
無効
12-50　Oracle Data Guard 概要および管理
VALID_FOR
表 12-3 VALID_FOR 属性の値（続き）
VALID_FOR 定義
プライマリ・
ロール
フィジカル・スタンバイ・
ロール
ロジカル・スタンバイ・
ロール
ALL_LOGFILES、STANDBY_ROLE
無効
アクティブ
アクティブ
ALL_LOGFILES、ALL_ROLES
アクティブ
アクティブ
アクティブ
注意 : VALID_FOR=(STANDBY_LOGFILE, PRIMARY_ROLE) キーワー
ドのペアは指定できません。プライマリ・データベースでスタンバイ
REDO ログ・ファイルを構成する場合は有効ですが、プライマリ・ロール
で実行されているデータベースは、スタンバイ REDO ログ・ファイルを
使用できません。
宛先に VALID_FOR 属性を指定しないと、データベースがプライマリ・ロールまたはスタン
バイ・ロールで実行されているかどうかに関係なく、デフォルトで、オンライン REDO ロ
グ・ファイルとスタンバイ REDO ログ・ファイルのアーカイブが宛先で有効になります。
このデフォルトの動作は、VALID_FOR 属性で (ALL_LOGFILES,ALL_ROLES) キーワード・
ペアを設定した場合と同様です。次に例を示します。
LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll/arch/ VALID_FOR=(ALL_
LOGFILES,ALL_ROLES)
(ALL_LOGFILES,ALL_ROLES) キーワードのペアはデフォルトですが、すべての宛先に適
切とはかぎりません。たとえば、宛先がロジカル・スタンバイ・データベース（独自の
REDO データを作成するオープン状態のデータベース）の場合、ログ転送サービスによって
転送される REDO データは、ロジカル・スタンバイ・データベースのローカル・オンライ
ン REDO ログ・ファイルを上書きする可能性があります。
そのため、各宛先に対してそれぞれ VALID_FOR 属性を定義し、ロールの推移後を含め、常
に Data Guard 構成が正しく動作するようにすることをお薦めします。
VALID_FOR 属性を使用すると、同じ初期化パラメータ・ファイルで、プライマリ・ロール
およびスタンバイ・ロールの初期化パラメータを設定できます。したがって、将来のスイッ
チオーバーまたはフェイルオーバーでロール・リバーサルが予測される場合に、個別の初期
化パラメータ・ファイルを保持する必要はありません。
LOG_ARCHIVE_DEST_n パラメータの属性
12-51
VALID_FOR
例
例1
次の例は、VALID_FOR のデフォルトのキーワードのペアを示します。
LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata VALID_FOR=(ALL LOGFILES, ALL_ROLES)'
このデータベースがプライマリ・ロールまたはスタンバイ・ロールで実行されている場合、
宛先 1 は、すべてのログ・ファイルをローカル・ディレクトリ /disk1/oracle/oradata
にアーカイブします。
VALID_FOR 属性を使用した各種の Data Guard 構成の詳しい例は、10-2 ページの「アーカ
イブ先の設定および確認」の使用例を参照してください。
12-52　Oracle Data Guard 概要および管理
VERIFY および NOVERIFY
VERIFY および NOVERIFY
VERIFY 属性および NOVERIFY 属性は、アーカイバ（ARCn）プロセスが、完了したアーカ
イブ REDO ログ・ファイルの内容が正しいことを確認する必要があるかどうかを示します。
■
■
VERIFY: 完了したアーカイブ REDO ログ・ファイル（ローカルまたはリモート）を完全
にスキャンして、正しいことを確認します。
NOVERIFY: アーカイブ REDO ログ・ファイルの内容が確認されないことを示します。
VERIFY 属性および NOVERIFY 属性が指定されていない場合、デフォルトは NOVERIFY で
す。
カテゴリ
VERIFY
NOVERIFY
属性のデータ型
キーワード
キーワード
最小属性値
該当なし
該当なし
最大属性値
該当なし
該当なし
デフォルト属性値
該当なし
該当なし
必須属性
該当なし
該当なし
属性との競合
NOVERIFY、LGWR
VERIFY
属性クラス
ALTER SYSTEM
ALTER SYSTEM
対応する
V$ARCHIVE_DEST 列
VERIFY
VERIFY
関連する V$ARCHIVE_DEST 列
ARCHIVER
ARCHIVER
VERIFY
VERIFY 属性を使用して、アーカイブ操作が正常に完了した後に、完了したアーカイブ
REDO ログ・ファイル（ローカルまたはリモート）をスキャンし、正しいことを確認しま
す。確認は、常に実行される通常のチェックサム確認よりも詳細に行われます。REDO 確認
は、完了するまでにかなりの時間がかかる場合があります。したがって、アーカイブ REDO
ログ・ファイルの確認は、アーカイバ・プロセスを使用する場合のみ実行されます。
VERIFY 属性を使用すると、プライマリ・データベースのパフォーマンスに影響することが
あります。
LOG_ARCHIVE_DEST_n パラメータの属性
12-53
アーカイブ先の属性の互換性
NOVERIFY
デフォルト値は NOVERIFY です。これは、アーカイブ REDO ログ・ファイルが確認されな
いことを示します。NOVERIFY 属性を指定すると、アーカイブ REDO ログ・ファイルの通常
のチェックサム確認は行われますが、REDO の内容の確認は行われません。
アーカイブ先の属性の互換性
LOG_ARCHIVE_DEST_n 初期化パラメータには、多数の属性があります。これらの属性の中
には、他の属性と競合するものがあります。また、属性によっては、他の属性の定義が必要
になるものがあります。表 12-4 は、サポートされている属性と、ぞれぞれに関連する要件を
示しています。
表 12-4 LOG_ARCHIVE_DEST_n 属性の互換性
属性
必須
競合する属性
AFFIRM
該当なし
NOAFFIRM
NOAFFIRM
該当なし
AFFIRM
ALTERNATE=destination
該当なし
NOALTERNATE
NOALTERNATE
該当なし
ALTERNATE
ARCH
該当なし
LGWR
ASYNC
NET_TIMEOUT
ASYNC[=blocks]
LGWR
SYNC
LOCATION
ARCH
DB_UNIQUE_NAME
DB_UNIQUE_NAME
NODB_UNIQUE_NAME
NODB_UNIQUE_NAME
該当なし
該当なし
DELAY
SERVICE
LOCATION
NODELAY
NODELAY
該当なし
DELAY
DEPENDENCY
SERVICE
REGISTER
LOCATION
NODEPENDENCY
NOREGISTER
QUOTA_SIZE
QUOTA_USED
NODEPENDENCY
該当なし
DEPENDENCY
LGWR
該当なし
ARCH
12-54　Oracle Data Guard 概要および管理
アーカイブ先の属性の互換性
表 12-4 LOG_ARCHIVE_DEST_n 属性の互換性（続き）
属性
必須
競合する属性
LOCATION
該当なし
SERVICE
DEPENDENCY
REGISTER=location_format
NOREGISTER
DELAY
ASYNC
NET_TIMEOUT
TEMPLATE
QUOTA_SIZE および QUOTA_USED
MANDATORY
該当なし
OPTIONAL
MAX_FAILURE
REOPEN
NOMAX_FAILURE
NOMAX_FAILURE
該当なし
MAX_FAILURE
NET_TIMEOUT
LGWR と SYNC=PARALLEL
または
LGWR と ASYNC > 0
ARCH
LOCATION
NONET_TIMEOUT
LGWR と SYNC=NOPARALLEL
LGWR と ASYNC=0
NONET_TIMEOUT
該当なし
NET_TIMEOUT
OPTIONAL
該当なし
MANDATORY
QUOTA_SIZE
LOCATION
DEPENDENCY
SERVICE
NOQUOTA_SIZE
LOCATION
NOQUOTA_SIZE
該当なし
QUOTA_SIZE
QUOTA_USED
LOCATION
DEPENDENCY
SERVICE
NOQUOTA_USED
LOCATION
NOQUOTA_USED
該当なし
QUOTA_USED
REGISTER
該当なし
NOALTERNATE
NOREGISTER
NOREGISTER
SERVICE
LOCATION
REGISTER
REGISTER=location_
format
DEPENDENCY
LOCATION
NOREGISTER
TEMPLATE
REOPEN
該当なし
NOREOPEN
LOG_ARCHIVE_DEST_n パラメータの属性
12-55
アーカイブ先の属性の互換性
表 12-4 LOG_ARCHIVE_DEST_n 属性の互換性（続き）
属性
必須
競合する属性
NOREOPEN
該当なし
REOPEN
SERVICE
該当なし
LOCATION
QUOTA_USED
QUOTA_SIZE
SYNC[=parallel_option]
該当なし
ASYNC
TEMPLATE
SERVICE
NOTEMPLATE
LOCATION
REGISTER=location_format
NOTEMPLATE
該当なし
TEMPLATE
VALID_FOR
該当なし
該当なし
VERIFY
該当なし
NOVERIFY、LGWR
NOVERIFY
該当なし
VERIFY
LOCATION 属性は、USE_DB_RECOVERY_FILE_DEST を指定した場合のみ、QUOTA_SIZE
および QUOTA_USED と競合します。
12-56　Oracle Data Guard 概要および管理
13
Data Guard に関連する SQL 文
この章では、Data Guard 環境のスタンバイ・データベースで操作を実行するときに役立つ
SQL および SQL*Plus 文の概要について説明します。この章は、次の項目で構成されていま
す。
■
ALTER DATABASE 文
■
ALTER SESSION 文
この章では、特定の SQL 文について、その構文と簡単な概要を示します。これらの SQL 文
およびその他の SQL 文の完全な構文および説明は、『Oracle Database SQL リファレンス』
を参照してください。
ALTER SYSTEM SET 文または ALTER SESSION 文を使用して設定および動的な更新を行う
ことができる初期化パラメータについては、第 11 章を参照してください。
Data Guard に関連する SQL 文
13-1
ALTER DATABASE 文
ALTER DATABASE 文
表 13-1 で、Data Guard に関連のある ALTER DATABASE 文について説明します。
表 13-1 Data Guard 環境で使用される ALTER DATABASE 文
ALTER DATABASE 文
説明
ADD [STANDBY] LOGFILE
[THREAD integer]
[GROUP integer] filespec
指定したスレッドに 1 つ以上のオンライン REDO ログ・ファ
イル・グループまたはスタンバイ REDO ログ・ファイル・グ
ループを追加し、スレッドが割り当てられたインスタンスで
ログ・ファイルを使用できるようにします。
この文の例は、8-18 ページの「オンライン REDO ログ・ファ
イルの追加または削除」を参照してください。
ADD [STANDBY] LOGFILE MEMBER 'filename'
[REUSE] TO logfile-descriptor
既存のオンライン REDO ログ・ファイル・グループまたはス
タンバイ REDO ログ・ファイル・グループに新しいメンバー
を追加します。
この文の例は、5-37 ページの「スタンバイ REDO ログ・メン
バーを既存のグループに追加」を参照してください。
[ADD|DROP] SUPPLEMENTAL LOG DATA {PRIMARY
KEY|UNIQUE INDEX} COLUMNS
この文は、ロジカル・スタンバイ・データベース専用です。
ロジカル・スタンバイ・データベースを作成する前に、サプ
リメンタル・ロギングを使用可能にするために使用します。
サプリメンタル・ロギングがロジカル・スタンバイ・データ
ベースに対する変更のソースであるため、このようにする必
要があります。完全なサプリメンタル・ロギングを実装するに
は、この文で PRIMARY KEY COLUMNS または UNIQUE
INDEX COLUMNS キーワードを指定する必要があります。
この文の例は、4-9 ページの「サプリメンタル・ロギングが使
用可能であることの確認」を参照してください。
13-2　Oracle Data Guard 概要および管理
ALTER DATABASE 文
表 13-1 Data Guard 環境で使用される ALTER DATABASE 文（続き）
ALTER DATABASE 文
説明
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-12 ページの「フィジカル・スタンバイ・
データベースが関与するスイッチオーバー」および 7-20 ペー
ジの「ロジカル・スタンバイ・データベースが関与するス
イッチオーバー」を参照してください。
CREATE [PHYSICAL|LOGICAL] STANDBY
CONTROLFILE AS 'filename' [REUSE]
フィジカルまたはロジカル・スタンバイ・データベースの維
持に使用される制御ファイルを作成します。この文はプライ
マリ・データベースで発行します。
フィジカルおよびロジカル・スタンバイ・データベースにお
けるこの文の例は、それぞれ 3-9 ページの「スタンバイ・デー
タベース用の制御ファイルの作成」および 4-15 ページの「ロ
ジカル・スタンバイ・データベース用の制御ファイルの作成」
を参照してください。
DROP [STANDBY] LOGFILE logfile_descriptor
オンライン REDO ログ・ファイル・グループまたはスタンバ
イ REDO ログ・ファイル・グループのすべてのメンバーを削
除します。
この文の例は、8-18 ページの「オンライン REDO ログ・ファ
イルの追加または削除」を参照してください。
DROP [STANDBY] LOGFILE MEMBER 'filename'
オンライン REDO ログ・ファイル・グループまたはスタンバ
イ REDO ログ・ファイル・グループの 1 つ以上のメンバーを
削除します。
Data Guard に関連する SQL 文
13-3
ALTER DATABASE 文
表 13-1 Data Guard 環境で使用される ALTER DATABASE 文（続き）
ALTER DATABASE 文
説明
[NO]FORCE LOGGING
一時表領域および一時セグメントに対する変更を除くデータ
ベースに対するすべての変更を、Oracle データベースが記録
するかどうかを制御します。[NO]FORCE LOGGING 句の用途
は、次のとおりです。
■
■
フィジカル・スタンバイ・データベースの場合は、スタ
ンバイ・データベース間の一貫性の欠如を防止するため
に必要です。
ロジカル・スタンバイ・データベースの場合は、スタン
バイ・データベースでのデータの可用性を確実にするた
めに、この指定を使用することをお薦めします。
この文を発行する場合、プライマリ・データベースがマウン
トされている必要があります。ただし、オープンする必要は
ありません。この文の例は、3-3 ページの「強制ロギングの有
効化」を参照してください。
MOUNT [STANDBY DATABASE]
スタンバイ・データベースをマウントし、スタンバイ・イン
スタンスが REDO データをプライマリ・インスタンスから受
信できるようにします。
OPEN
すでに起動され、マウントされたデータベースをオープンし
ます。
■
■
フィジカル・スタンバイ・データベースは読取り専用
モードでオープンされ、ユーザーを読取り専用トランザ
クションに制限し、REDO データの生成を防ぎます。
ロジカル・スタンバイ・データベースは読取り / 書込み
モードでオープンされます。
この文の例は、4-15 ページの「ロジカル・スタンバイ・デー
タベースの起動」の手順 5 を参照してください。
PREPARE TO SWITCHOVER
この文は、ロジカル・スタンバイ・データベース専用です。
スイッチオーバーが実行される前に、LogMiner ディクショナ
リを構築することにより、プライマリ・データベースおよび
ロジカル・スタンバイ・データベースをスイッチオーバー用
に準備します。ディクショナリ構築の完了後、ALTER
DATABASE COMMIT TO SWITCHOVER 文を発行し、プライマ
リおよびロジカル・スタンバイ・データベースのロールを切
り替えます。
この文の例は、7-20 ページの「ロジカル・スタンバイ・デー
タベースが関与するスイッチオーバー」を参照してください。
13-4　Oracle Data Guard 概要および管理
ALTER DATABASE 文
表 13-1 Data Guard 環境で使用される ALTER DATABASE 文（続き）
ALTER DATABASE 文
説明
RECOVER MANAGED STANDBY DATABASE [
[NO TIMEOUT|TIMEOUT [integer] ]
[NODELAY|DELAY [integer] ]
[DEFAULT DELAY]
[DISCONNECT]
[NO EXPIRE|EXPIRE [integer] ]
[NEXT [integer]]
[NOPARALLEL|PARALLEL [integer]]
[THROUGH {ALL|NEXT|LAST SWITCHOVER]
[THROUGH [THREAD n] SEQUENCE n]
[ALL ARCHIVELOG]
[FINISH [SKIP[STANDBY LOGFILE]
[NOWAIT|WAIT]]
[UNTIL CHANGE scn]
[USING CURRENT LOGFILE] ]
この文は、フィジカル・スタンバイ・データベース専用です。
この文を使用して、フィジカル・スタンバイ・データベース
に対するログ適用サービスの開始および制御を行います。
RECOVER MANAGED STANDBY DATABASE 句は、マウント、
オープンまたはクローズされているフィジカル・スタンバイ・
データベースで使用できます。この句には、Redo Apply を制
御するための様々なオプションが用意されています。
この文の例は、3-15 ページの「フィジカル・スタンバイ・
データベースの起動」の手順 3 および 6-7 ページの「REDO
データのフィジカル・スタンバイ・データベースへの適用」
を参照してください。
RECOVER MANAGED STANDBY DATABASE CANCEL
[[NOWAIT]|[WAIT]|[IMMEDIATE] ]
この文は、フィジカル・スタンバイ・データベースでの Redo
Apply を取り消します。
REGISTER [OR REPLACE]
[PHYSICAL|LOGICAL] LOGFILE filespec
手動でアーカイブ REDO ログ・ファイルを登録できます。
RESET DATABASE TO INCARNATION
integer
SET STANDBY DATABASE TO MAXIMIZE
{PROTECTION|AVAILABILITY|PERFORMANCE}
この文の例は、5-43 ページの「手動によるアーカイブ・
ギャップの判断および解決」を参照してください。
データベースのターゲット・リカバリ・インカネーションを、
現在のインカネーションから以前のインカネーションにリ
セットします。
この文は、マウントされているが、オープンされていないプ
ライマリ・データベースで発行されます。Data Guard 構成の
3 つのデータ保護モードのうち、1 つを指定します。全 3 モー
ドとも高レベルのデータ保護を提供しますが、各保護モード
ごとに、プライマリ・データベースの可用性およびパフォー
マンスに与える影響が異なります。
この文の例は、5-31 ページの「Data Guard 構成のデータ保護
モードの設定」を参照してください。
START LOGICAL STANDBY APPLY
INITIAL [scn-value] ]
[NEW PRIMARY dblink]
この文は、ロジカル・スタンバイ・データベース専用です。
ロジカル・スタンバイ・データベースで SQL Apply を起動し
ます。この文の例は、6-12 ページの「SQL Apply の開始」を
参照してください。
Data Guard に関連する SQL 文
13-5
ALTER DATABASE 文
表 13-1 Data Guard 環境で使用される ALTER DATABASE 文（続き）
ALTER DATABASE 文
説明
{STOP|ABORT} LOGICAL STANDBY APPLY
この文は、ロジカル・スタンバイ・データベース専用です。
ロジカル・スタンバイ・データベースで SQL Apply を正しく
停止するには、STOP 句を使用します。SQL Apply を強制的に
停止するには、ABORT 句を使用します。この文の例は、7-23
ページの「ロジカル・スタンバイ・データベースが関与する
フェイルオーバー」を参照してください。
ACTIVATE [PHYSICAL|LOGICAL] STANDBY
DATABASE [SKIP [STANDBY LOGFILE]]
フェイルオーバーを実行します。これによって、プライマリ・
データベースは Data Guard 環境から削除され、1 つのスタン
バイ・データベースがプライマリ・データベース・ロールに
推移します。スタンバイ・データベースは、マウント後に、
この文を使用してアクティブ化する必要があります。
注意 : ALTER DATABASE ACTIVATE STANDBY DATABASE
文をフェイルオーバーに使用しないでください。データ消失
が発生します。かわりに、次のようにします。
■
フィジカル・スタンバイ・データベースの場合、ALTER
DATABASE RECOVER MANAGED STANDBY DATABASE
文で FINISH または FINISH SKIP キーワードを使用し
ます。これにより、ロールの推移がすばやく実行される
ため、データ消失は防止されるかまたは最小限に抑えら
れ、他のスタンバイ・データベースが使用できなくなる
ことはありません。
注意 : フェイルオーバー操作は、最後にアーカイブされ
るログ・ファイルのヘッダーに end-of-redo マーカーを追
加し、プライマリ・ロールに指定できるすべての有効な
宛先（VALID_FOR=(PRIMARY_ROLE, *_LOGFILES)
または VALID_FOR=(ALL_ROLES, *_LOGFILES) 属性
で指定されます）に REDO を送信します。
■
13-6　Oracle Data Guard 概要および管理
ロジカル・スタンバイ・データベースの場合、ALTER
DATABASE PREPARE TO SWITCHOVER および ALTER
DATABASE COMMIT TO SWITCHOVER 文を使用します。
ALTER SESSION 文
ALTER SESSION 文
表 13-2 で、Data Guard に関連のある ALTER SESSION 文について説明します。
表 13-2 Data Guard 環境で使用される ALTER SESSION 文
ALTER SESSION 文
説明
ALTER SESSION [ENABLE|DISABLE] GUARD
この文は、ロジカル・スタンバイ・データベース専用です。
権限を付与されているユーザーは、この文を使用して、現在の
セッションでデータベース・ガードを選択または解除できま
す。
この文の例は、7-23 ページの「ロジカル・スタンバイ・データ
ベースが関与するフェイルオーバー」を参照してください。
Data Guard に関連する SQL 文
13-7
ALTER SESSION 文
13-8　Oracle Data Guard 概要および管理
14
Oracle Data Guard に関連するビュー
この章では、Data Guard 環境で重要であるビューについて説明します。この章で説明され
ているビューは、Oracle データベースで使用可能なビューのサブセットです。
Oracle Data Guard に関連するビュー
14-1
表 14-1 では各ビューについて説明し、そのビューがフィジカル・スタンバイ・データベー
ス、ロジカル・スタンバイ・データベース、プライマリ・データベースのいずれに適用され
るのかを示します。各ビューの詳細は、
『Oracle Database リファレンス』を参照してくださ
い。
表 14-1 Data Guard 構成に関連のあるビュー
ビュー
データベース
説明
DBA_LOGSTDBY_EVENTS
ロジカルのみ
ロジカル・スタンバイ・データベース・システムのアクティ
ビティに関する情報が格納されます。このビューは、SQL
Apply によって REDO がロジカル・スタンバイ・データ
ベースに適用されるときに発生する障害の原因究明に役立ち
ます。
DBA_LOGSTDBY_LOG
ロジカルのみ
ロジカル・スタンバイ・データベースにレジストリされてい
るログ・ファイルを表示します。
DBA_LOGSTDBY_NOT_UNIQUE
ロジカルのみ
主キー制約または NOT NULL の一意制約がない表を識別し
ます。
DBA_LOGSTDBY_PARAMETERS
ロジカルのみ
SQL Apply で使用されるパラメータのリストが格納されま
す。
DBA_LOGSTDBY_PROGRESS
ロジカルのみ
ロジカル・スタンバイ・データベースでの SQL Apply の進
捗状況を表示します。
DBA_LOGSTDBY_SKIP
ロジカルのみ
SQL Apply によってスキップされる表をリスト表示します。
DBA_LOGSTDBY_SKIP_
TRANSACTION
ロジカルのみ
選択されているスキップ設定をリスト表示します。
DBA_LOGSTDBY_UNSUPPORTED
ロジカルのみ
V$ARCHIVE_DEST
プライマリ、
現在のインスタンスについて、Data Guard 構成内のすべて
フィジカルおよび の宛先の現在の値、モードおよび状況を含めた説明を表示し
ロジカル
ます。
サポートされないデータ型が含まれているスキーマおよび表
（およびその表の列）を識別します。このビューは、ロジカ
ル・スタンバイ・データベースの作成を準備する際に使用し
ます。
注意 : このビューに表示される情報は、インスタンスの停止
後には保存されません。
V$ARCHIVE_DEST_STATUS
プライマリ、
アーカイブ REDO ログ宛先の実行時および構成用の情報を
フィジカルおよび 表示します。
ロジカル
注意 : このビューに表示される情報は、インスタンスの停止
後には保存されません。
V$ARCHIVE_GAP
フィジカルおよび アーカイブ REDO ログ・ファイルのギャップの識別に役立
ロジカル
つ情報を表示します。
14-2　Oracle Data Guard 概要および管理
表 14-1 Data Guard 構成に関連のあるビュー（続き）
ビュー
データベース
説明
V$ARCHIVED_LOG
プライマリ、
制御ファイルのアーカイブ REDO ログ情報を、アーカイブ
フィジカルおよび REDO ログ・ファイル名を含めて表示します。
ロジカル
V$DATABASE
プライマリ、
制御ファイルからのデータベース情報を表示します。
フィジカルおよび
ロジカル
V$DATABASE_INCARNATION
プライマリ、
すべてのデータベース・インカネーションに関する情報を表
フィジカルおよび 示します。Oracle Database では、RESETLOGS オプションを
ロジカル
使用してデータベースがオープンされるたびに、新しいイン
カネーションが作成されます。V$DATABASE ビューには、現
在のインカネーションのみでなく、前のインカネーションの
レコードも表示されます。
V$DATAFILE
プライマリ、
制御ファイルからのデータ・ファイル情報を表示します。
フィジカルおよび
ロジカル
V$DATAGUARD_CONFIG
プライマリ、
DB_UNIQUE_NAME および LOG_ARCHIVE_CONFIG 初期化パ
フィジカルおよび ラメータで定義された一意のデータベース名をリスト表示し
ロジカル
ます。
V$DATAGUARD_STATUS
プライマリ、
通常はアラート・ログまたはサーバー・プロセスのトレー
フィジカルおよび ス・ファイルへのメッセージによってトリガーされるイベン
ロジカル
トが表示および記録されます。
V$LOG
プライマリ、
オンライン REDO ログ・ファイルのログ・ファイル情報が
フィジカルおよび 格納されます。
ロジカル
V$LOGFILE
プライマリ、
オンライン REDO ログ・ファイルとスタンバイ REDO ロ
フィジカルおよび グ・ファイルに関する情報が格納されます。
ロジカル
V$LOG_HISTORY
プライマリ、
制御ファイルからのログ履歴情報が格納されます。
フィジカルおよび
ロジカル
V$LOGSTDBY
ロジカルのみ
SQL Apply の動作に関する動的な情報を表示します。この
ビューは、ロジカル・スタンバイ・データベースで SQL
Apply を実行しているときのパフォーマンス上の問題を診断
する場合に非常に有用です。このビューはまた、その他の問
題の解決にも役立ちます。
V$LOGSTDBY_STATS
ロジカルのみ
LogMiner 統計、現行のステータスおよび SQL Apply 時の
ロジカル・スタンバイ・データベースのステータス情報を表
示します。SQL Apply が実行されていない場合、統計の値は
消去されます。
Oracle Data Guard に関連するビュー
14-3
表 14-1 Data Guard 構成に関連のあるビュー（続き）
ビュー
データベース
説明
V$MANAGED_STANDBY
フィジカルのみ
フィジカル・スタンバイ・データベースに関連する Oracle
データベース・プロセスの現在の状態を表示します。
注意 : このビューに表示される情報は、インスタンスの停止
後には保存されません。
V$STANDBY_LOG
フィジカルおよび スタンバイ REDO ログ・ファイルのログ・ファイル情報が
ロジカル
格納されます。
14-4　Oracle Data Guard 概要および管理
第 III 部
付録
この部は、次の章で構成されています。
■
付録 A「Data Guard のトラブルシューティング」
■
付録 B「Data Guard および Real Application Clusters」
■
付録 C「カスケードされた REDO ログ宛先」
■
付録 D「Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成」
■
付録 E「アーカイブ・トレースの設定」
■
付録 F「障害時リカバリに関する ReadMe ファイルのサンプル」
A
Data Guard のトラブルシューティング
この付録は、スタンバイ・データベースのトラブルシューティングのヘルプとしてご利用い
ただけます。この項は、次の項目で構成されています。
■
一般的な問題
■
ログ・ファイル宛先の障害
■
ロジカル・スタンバイ・データベース障害の処理
■
スタンバイ・データベースへのスイッチオーバーの問題
■
SQL Apply が停止した場合の処置
■
REDO データ転送のネットワーク調整
■
Data Guard によるネットワーク・タイムアウトの管理
■
スタンバイ・データベースのディスクのパフォーマンスが遅い
■
プライマリ・データベースの停止を回避するにはログ・ファイルを一致させる必要がある
Data Guard のトラブルシューティング
A-1
一般的な問題
一般的な問題
スタンバイ・データベースの使用時に発生する問題の原因には、次のようなものがありま
す。
■
スタンバイ・アーカイブ宛先が適切に定義されていない
■
ALTER DATABASE 文によるデータ・ファイル名の変更
■
スタンバイ・データベースがプライマリ・データベースから REDO データを受信しない
■
フィジカル・スタンバイ・データベースをマウントできない
スタンバイ・アーカイブ宛先が適切に定義されていない
STANDBY_ARCHIVE_DEST 初期化パラメータでスタンバイ・データベースの有効なディレク
トリ名を指定していない場合、Oracle データベースは、アーカイブ REDO ログ・ファイル
を格納するディレクトリを決定できません。次の問合せを入力して、V$ARCHIVE_DEST
ビューの DESTINATION 列および ERROR 列を調べ、宛先が有効であることを確認します。
SQL> SELECT DESTINATION, ERROR FROM V$ARCHIVE_DEST;
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_FILE_MANAGEMENT が自動の場合、RENAME 操作はできません。
フィジカル・スタンバイ・データベースにデータ・ファイルを追加する方法は、8-11 ページ
の「データ・ファイルの追加または表領域の作成」を参照してください。
A-2　Oracle Data Guard 概要および管理
一般的な問題
スタンバイ・データベースがプライマリ・データベースから REDO データ
を受信しない
スタンバイ・サイトが REDO データを受信していない場合は、V$ARCHIVE_DEST ビューを
問い合せて、エラー・メッセージをチェックします。たとえば、次のような問合せを入力し
ます。
SQL>
2>
3>
4>
5>
SELECT DEST_ID "ID",
STATUS "DB_status",
DESTINATION "Archive_dest",
ERROR "Error"
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 データを転送
できません。
■
■
■
■
プライマリ・データベースの tnsnames.ora ファイル内でスタンバイ・インスタンス
のサービス名が正しく構成されていない場合。
プライマリ・データベースの LOG_ARCHIVE_DEST_n パラメータで指定された Oracle
Net サービス名が不適切な場合。
スタンバイ・データベースの LOG_ARCHIVE_DEST_STATE_n パラメータが値 ENABLE
に設定されていない場合。
listener.ora ファイルがスタンバイ・データベース用に正しく構成されていない場
合。
■
スタンバイ・サイトでリスナーが開始されていない場合。
■
スタンバイ・インスタンスが起動されていない場合。
■
■
スタンバイ・アーカイブ先をプライマリ SPFILE またはテキスト初期化パラメータ・
ファイルに追加したが、その変更をまだ使用可能にしていない場合。
スタンバイ・データベースのベースとして無効なバックアップを使用した場合（たとえ
ば、間違ったデータベースからのバックアップを使用、または正しい方法でスタンバイ
制御ファイルを作成しなかったなど）
。
Data Guard のトラブルシューティング
A-3
ログ・ファイル宛先の障害
フィジカル・スタンバイ・データベースをマウントできない
スタンバイ制御ファイルが、ALTER DATABASE CREATE [LOGICAL] STANDBY
CONTROLFILE ... 文または Recovery Manager のコマンドを使用して作成されていない場
合、スタンバイ・データベースをマウントすることはできません。次のタイプの制御ファイ
ル・バックアップは使用できません。
■
■
オペレーティング・システムで作成されたバックアップ
[PHYSICAL] STANDBY または LOGICAL STANDBY オプションのない ALTER DATABASE
文を使用して作成されたバックアップ
ログ・ファイル宛先の障害
OPTIONAL 宛先に REOPEN を指定した場合は、問題の宛先へのアーカイブ時にエラーが発生
した場合でも、Oracle データベースはオンライン REDO ログ・ファイルを再利用できます。
MANDATORY 宛先に REOPEN を指定した場合、ログ転送サービスは、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 データの転送に失敗した場合は、代替アーカ
イブ先を使用できます。転送に失敗したときに、NOREOPEN 属性が指定されていなかった場
合、または MAX_FAILURE 属性のしきい値を超えた場合、ログ転送サービスは、次のアーカ
イブ操作時に代替先への REDO データの転送を試みます。
元のアーカイブ先で障害が発生したときに、元のアーカイブ先が自動的に代替アーカイブ先
に変更されることを防ぐには、NOALTERNATE 属性を使用します。
例 A-2 は、エラー発生時に、単一、必須のローカル宛先が異なる宛先へ自動的にフェイル
オーバーするように初期化パラメータを設定する方法を示します。
例 A-2 代替宛先の指定
LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY'
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
宛先 LOG_ARCHIVE_DEST_1 で障害が発生した場合、アーカイブ・プロセスは、プライマ
リ・データベースでの次のログ・ファイル・スイッチで宛先を LOG_ARCHIVE_DEST_2 に自
動的に切り替えます。
A-4　Oracle Data Guard 概要および管理
スタンバイ・データベースへのスイッチオーバーの問題
ロジカル・スタンバイ・データベース障害の処理
ロジカル・スタンバイ・データベース障害を処理するための重要なツールは、DBMS_
LOGSTDBY.SKIP_ERROR プロシージャです。表の重要度に基づいて、次のいずれかを実行
できます。
■
■
表や特定の DDL に関する障害を無視する。
ストアド・プロシージャをフィルタに関連付ける。これによって、文のスキップ、文の
実行または代用文の実行について実行時に決定できます。
これらの処理のいずれかを実行すると、SQL Apply の停止を回避できます。存在している問
題は、後で DBA_LOGSTDBY_EVENTS ビューを問い合せて検索し、訂正できます。DBMS_
LOGSTDBY パッケージの PL/SQL コールアウト・プロシージャの使用方法については、
『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
スタンバイ・データベースへのスイッチオーバーの問題
通常、第 7 章で説明した手順に従うと、スイッチオーバーは正常に行われます。ただし、ス
イッチオーバーが失敗した場合でも、次の項を読むと、問題の解決に役立ちます。
■
REDO データが転送されていないためスイッチオーバーできない
■
SQL セッションがアクティブなためスイッチオーバーできない
■
ユーザー・セッションがアクティブなためスイッチオーバーできない
■
ORA-01102 エラーによりスイッチオーバーできない
■
スイッチオーバー後に REDO データが適用されないためスイッチオーバーできない
■
失敗したスイッチオーバーをロールバックして最初からやり直す
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 は、プライマリ・ロールへのスイッ
チオーバーが可能になったことを示します。
Data Guard のトラブルシューティング
A-5
スタンバイ・データベースへのスイッチオーバーの問題
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
----------------TO PRIMARY
1 row selected
V$DATABASE ビューの SWITCHOVER_STATUS 列に対するその他の有効な値については、第
14 章を参照してください。
スイッチオーバーを続行するには、7-12 ページの「フィジカル・スタンバイ・データベース
が関与するスイッチオーバー」
（フィジカル・スタンバイ・データベースの場合）または
7-20 ページの「ロジカル・スタンバイ・データベースが関与するスイッチオーバー」（ロジ
カル・スタンバイ・データベースの場合）の説明に従って、ターゲットのスタンバイ・デー
タベースをプライマリ・ロールに切り替える操作を再度実行します。
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 プロセス・エントリに対応して
います。ジョブ・キュー・プロセスはユーザー・プロセスなので、スイッチオーバーの発生
A-6　Oracle Data Guard 概要および管理
スタンバイ・データベースへのスイッチオーバーの問題
を妨げるのは 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
QMN0
Advanced Queue Time
Manager
AQ_TM_PROCESSES 動的パラメータを値 0（ゼ
ロ）に変更してください。変更は、インスタン
スを再起動しなくても即時に有効になります。
DBSNMP
Oracle Enterprise Manager
Management Agent
オペレーティング・システム・プロンプトから
agentctl stop コマンドを発行してください。
対処措置
JOB_QUEUE_PROCESSES 動的パラメータを値 0
（ゼロ）に変更してください。変更は、インスタ
ンスを再起動しなくても即時に有効になります。
Data Guard のトラブルシューティング
A-7
スタンバイ・データベースへのスイッチオーバーの問題
ユーザー・セッションがアクティブなためスイッチオーバーできない
スイッチオーバーに失敗し、エラー「ORA-01093: ALTER DATABASE CLOSE は接続中の
セッションがない場合にのみ実行できます」が戻された場合、通常これは、ALTER
DATABASE COMMIT TO SWITCHOVER 文が暗黙的にデータベースのクローズを実行したと
きに、その他のユーザー・セッションがデータベースに接続されていてクローズできなかっ
たことが原因と考えられます。
このエラーが発生した場合は、データベースに接続されているユーザー・セッションをすべ
て切断します。これを実行するには、次の例に示すように、V$SESSION 固定ビューを問い
合せて、まだアクティブなセッションを確認します。
SQL> SELECT SID, PROCESS, PROGRAM FROM V$SESSION;
SID
---------1
2
3
4
5
6
7
8
11
PROCESS
--------26900
26902
26904
26906
26908
26910
26912
26897
26917
PROGRAM
-----------------------------------------------oracle@dbuser-sun (PMON)
oracle@dbuser-sun (DBW0)
oracle@dbuser-sun (LGWR)
oracle@dbuser-sun (CKPT)
oracle@dbuser-sun (SMON)
oracle@dbuser-sun (RECO)
oracle@dbuser-sun (ARC0)
sqlplus@dbuser-sun (TNS V1-V3)
sqlplus@dbuser-sun (TNS V1-V3)
9 rows selected.
この例の最初の 7 つのセッションはすべて、Oracle Database のバックグラウンド・プロセ
スです。2 つの SQL*Plus セッションの内、一方は問合せを発行中のカレントの SQL*Plus
セッションで、他方はスイッチオーバーを再試行する前に切断される必要のある余分のセッ
ションです。
A-8　Oracle Data Guard 概要および管理
スタンバイ・データベースへのスイッチオーバーの問題
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 をスタンバイ・データベースが使用する初
期化パラメータ・ファイルに追加して、スタンバイ・データベースとプライマリ・データ
ベースを停止し、再起動します。
スイッチオーバー後に 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 初期化パラメータを設定する
必要があります。
Data Guard のトラブルシューティング
A-9
スタンバイ・データベースへのスイッチオーバーの問題
■
■
スタンバイ・サイトに STANDBY_ARCHIVE_DEST 初期化パラメータおよび LOG_
ARCHIVE_FORMAT 初期化パラメータを正しく設定し、アーカイブ REDO ログ・ファイ
ルが適切な場所に適用されるようにします。
スタンバイ・サイトで DB_FILE_NAME_CONVERT 初期化パラメータおよび LOG_FILE_
NAME_CONVERT 初期化パラメータを設定します。プライマリ・サイトで作成された新
しいデータ・ファイルがスタンバイ・サイトに自動的に追加されるようにするには、
STANDBY_FILE_MANAGEMENT 初期化パラメータを AUTO に設定します。
失敗したスイッチオーバーをロールバックして最初からやり直す
フィジカル・スタンバイ・データベースでエラーが発生し、スイッチオーバーを続行できな
い場合は、次の手順に従って、新しいフィジカル・スタンバイ・データベースをプライマ
リ・ロールに戻すことができます。
1.
新しいスタンバイ・データベース（元のプライマリ）に接続し、次の文を発行して、こ
のスタンバイ・データベースをプライマリ・ロールに戻します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
この文が正常に実行された場合は、データベースを停止し、再起動します。再起動する
と、データベースはプライマリ・データベース・ロールで実行されるため、それ以降の
手順を実行する必要はありません。
この文が正常に実行されなかった場合は、手順 3 に進んでください。
2.
プライマリからフィジカル・スタンバイにロールを変更するスイッチオーバーを開始し
たときに、トレース・ファイルがログ・ディレクトリに書き込まれています。このト
レース・ファイルには、元のプライマリ制御ファイルを再作成するために必要な SQL
文が含まれています。トレース・ファイルの位置を特定し、SQL 文を一時ファイルに抽
出します。SQL*Plus から一時ファイルを実行します。これによって、新しいスタンバ
イ・データベースはプライマリ・ロールに戻されます。
3.
元のフィジカル・スタンバイ・データベースを停止します。
4.
新しいスタンバイ制御ファイルを作成します。このファイルは、プライマリ・データ
ベースとフィジカル・スタンバイ・データベースの再同期化に必要です。フィジカル・
スタンバイ制御ファイルを元のフィジカル・スタンバイ・システムにコピーします。
フィジカル・スタンバイ制御ファイルの作成方法については、3-9 ページの「スタンバ
イ・データベース用の制御ファイルの作成」を参照してください。
5.
元のフィジカル・スタンバイ・インスタンスを再起動します。
この手順が正常終了し、アーカイブ・ギャップ管理が使用可能になると、FAL プロセス
が起動し、欠落したアーカイブ REDO ログ・ファイルをフィジカル・スタンバイ・
データベースに再アーカイブします。プライマリ・データベース上でログ・スイッチを
強制実行し、プライマリ・データベースとフィジカル・スタンバイ・データベースの両
方のアラート・ログを調べて、アーカイブ REDO ログ・ファイルの順序番号が正しい
ことを確認します。
A-10　Oracle Data Guard 概要および管理
SQL Apply が停止した場合の処置
アーカイブ・ギャップ管理の詳細は 5-40 ページの「アーカイブ・ギャップの管理」を、
トレース・ファイルの場所については付録 E を参照してください。
6.
スイッチオーバーを再度実行します。
この時点で、Data Guard 構成は初期状態にロールバックされています。最初に失敗し
たスイッチオーバーの問題をすべて解決した後、スイッチオーバー操作を再度実行でき
ます。
SQL Apply が停止した場合の処置
ログ適用サービスでは、サポートされない DML 文、DDL 文およびオラクル社が提供する
パッケージを、SQL Apply が実行されているロジカル・スタンバイ・データベースに適用で
きません。
サポートされない文やパッケージが検出されると、SQL Apply は停止します。表 A-2 で説明
する処理を実行して問題を解決した後、ロジカル・スタンバイ・データベースで SQL Apply
を再開してください。
表 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 を再開し
てください。
障害の原因を特定するために DBA_LOGSTDBY_EVENTS ビューを問い合せる方法は、第 14
章を参照してください。
Data Guard のトラブルシューティング
A-11
REDO データ転送のネットワーク調整
REDO データ転送のネットワーク調整
REDO データの転送プロセスには、オンライン REDO ログ・ファイルからのバッファの読
込みとアーカイブ REDO ログ・ファイルへの書込みが含まれます。宛先がリモートの場合
は、バッファは Oracle Net サービスを使用するネットワークを介して、アーカイブ REDO
ログ・ファイルに書き込まれます。
デフォルトのアーカイブ REDO ログ・ファイルのバッファ・サイズは 1MB です。Oracle
Net のデフォルトの転送バッファのサイズは 2KB です。このため、アーカイブ REDO ログ・
ファイル・バッファは、転送用として約 2KB のユニットに分割されます。これらのユニッ
トは、基のネットワーク・インタフェースの最大転送ユニット（MTU）に応じてさらに分
割されることがあります。
転送サイズを制御する Oracle Net のパラメータは、セッション・データ・ユニット（
セッション・データ・ユニット（SDU）
）
セッション・データ・ユニット（
です。このパラメータは、転送されるネットワーク・パケット数を削減するために調整する
ことができます。このパラメータは、512 バイト～ 32KB まで許されます。
最適なパフォーマンスを得るには、関連する SERVICE 宛先パラメータとして、Oracle Net
SDU パラメータを 32KB に設定します。
次の例は、リモート宛先 netserv を定義するデータベース初期化パラメータ・ファイル・
セグメントを示します。
LOG_ARCHIVE_DEST_3='SERVICE=netserv'
SERVICE_NAMES=srvc
次の例は、tnsnames.ora ファイル内のサービス名の定義を示します。
netserv=(DESCRIPTION=(SDU=32768)(ADDRESS=(PROTOCOL=tcp)(HOST=host) (PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=srvc)(ORACLE_HOME=/oracle)))
次の例は、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)))
待機時間が長いかまたは帯域幅が大きい接続を使用してリモート・サイトへのアーカイブを
行う場合は、TCP の送受信ウィンドウのサイズを大きくすることによってパフォーマンスを
改善できます。
高速の WAN リンクを使用して Data Guard 構成内のサイトに接続する場合、
SQLNET.SEND_BUF_SIZE および SQLNET.RECV_BUF_SIZE Oracle Net プロファイル・パ
ラメータを使用して、ネットワークの送受信 I/O バッファのサイズを大きくすることで、
ネットワーク・スループットが大幅に改善されることがよくあります。
『Oracle Net Services 管理者ガイド』を参照してください。
A-12　Oracle Data Guard 概要および管理
Data Guard によるネットワーク・タイムアウトの管理
Data Guard によるネットワーク・タイムアウトの管理
Oracle Data Guard ネットワーク接続を指定した場合、ネットワーク間の通信には 2 つのプ
ロセスが存在します。ネットワーク接続が突然中断された場合、この 2 つのプロセスの対応
は大きく異なります。次の説明は、ネットワーク接続が中断した場合に実際に発生する状態
と、それが Data Guard 環境と構成に与える影響について述べています。この説明は、フィ
ジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方に適用さ
れます。
Data Guard では、peer-to-peer 接続プロトコルが使用されます。このプロトコルによって、
プライマリ・データベース・プロセスがログ・ライター・プロセス（LGWR）またはアーカ
イバ・プロセス（ARCn）の場合に、スタンバイ・データベースへのネットワーク接続が確
立されます。ネットワーク接続の要求があると、スタンバイ・サイトのリスナーは、スタン
バイ・データベース上に個別のプロセスを作成します。このプロセスは、リモート・ファイ
ル・サーバー（RFS）
・プロセスと呼ばれます。この RFS プロセスは、プライマリ・データ
ベースのネットワーク・メッセージを使用します。つまり、ネットワークのメッセージを読
み込んで要求を処理した後、応答メッセージをプライマリ・データベースに返します。
通常の Data Guard 操作で、REDO データがプライマリ・データベースからスタンバイ・
データベースに転送される場合は、ネットワーク・メッセージがプライマリ・データベース
（ネットワーク・クライアント）から発行され、常にスタンバイ・データベース（ネット
ワーク・サーバー）によって認識されます。この場合、LGWR プロセスと ARCH プロセス
がネットワーク・クライアントで、RFS プロセスがネットワーク・サーバーです。
簡単な使用例として、プライマリ・システムとスタンバイ・システム間のネットワークが切
断された場合を考えてみます。LGWR プロセスがこの接続を介して新しいメッセージを RFS
プロセスに送信しようとすると、LGWR プロセスは、TCP タイムアウト後に、Oracle Net
から接続が切断されたことを示すエラーを受け取ります。この方法で、LGWR はネットワー
ク接続が失われていることを確認した後、対処措置を実行することができます。Data Guard
の属性 [NO]MAX_FAILURE、[NO]REOPEN および [NO]NET_TIMEOUT は、LOG_ARCHIVE_
DEST_n パラメータのオプションです。これを使用すると、LGWR は応答していないネット
ワーク接続に関連付けられたタイムアウト間隔と再試行の回数を柔軟に制御できます。
LGWR プロセスとは対照的に、スタンバイ・データベースの RFS プロセスは、常に新しい
メッセージがプライマリ・データベースから同期で着信するのを待機しています。ネット
ワークの読込み操作を実行する RFS プロセスは、データが着信するか、または基礎となる
ネットワーク・ソフトウェアで接続が無効になったと判断されるまで、ブロックされます。
Oracle Net は、定期的にネットワーク・プローブを送信して、クライアント / サーバー接続
がアクティブであることを確認します。このため、クライアントの異常終了が原因で接続が
無制限にオープン状態のままになることはありません。プローブは、切断された接続を検出
すると、エラーを戻します。これにより、RFS プロセスが終了します。
Oracle Net の SQLNET.EXPIRE_TIME パラメータを使用すると、ネットワーク・セッション
がアクティブであることを確認するためにプローブを送信する間隔を分単位で指定できま
す。このパラメータを小さい値に設定すると、切断された接続がタイムリに検出される可能
性が高くなります。このプローブ信号に応答しない接続は、切断されています。このパラ
Data Guard のトラブルシューティング
A-13
Data Guard によるネットワーク・タイムアウトの管理
メータは、将来スイッチオーバーする場合に備えて、プライマリ・データベースのみでな
く、スタンバイ・データベースにも設定してください。
この機能には、次のような使用上の制限があります。
■
■
プローブ・パケットは、小規模であっても、追加の通信量が発生します。ただし、プラ
イマリ・データベースのワークロードをベースにする Data Guard によって発生する
ネットワーク通信量と比較すると、この追加パケットの通信量はごく少量です。
使用しているオペレーティング・システムによっては、サーバーで追加の処理を実行し
て、接続プローブ・イベントと、発生したその他のイベントを区別する必要がありま
す。この処理は、ネットワークのパフォーマンスに影響を与える場合があります。
RFS プロセスは、切断されたネットワーク接続の通知を受信すると、プロセスを終了しま
す。ただし、RFS プロセスが終了するまでの間、スタンバイ・サイトのアーカイブ REDO ロ
グ・ファイルに関する情報、つまりプライマリ・データベースから受信していた REDO
データが含まれるスタンバイ REDO ログ・ファイルは、ロックされたままになります。この
間、新しい RFS プロセスはすべて、同じアーカイブ REDO ログ・ファイル（またはスタン
バイ REDO ログ・ファイル）の REDO データをプライマリ・データベースから受信できま
せん。
Oracle Net の SQLNET.EXPIRE_TIME パラメータを、1 分に設定することをお薦めします。
この値は、ほとんどのシステムにとって適正な値です。パラメータを小さい値に設定しても
本番システムに重大な影響を与えることはありません。
ネットワークの問題が解決し、プライマリ・データベースのプロセスがスタンバイ・データ
ベースへのネットワーク接続を再度確立できるようになると、新しいネットワーク接続ごと
に、新しい RFS プロセスがスタンバイ・データベース上で自動的に起動します。これらの新
しい RFS プロセスは、プライマリ・データベースからの REDO データの受信を再開します。
A-14　Oracle Data Guard 概要および管理
プライマリ・データベースの停止を回避するにはログ・ファイルを一致させる必要がある
スタンバイ・データベースのディスクのパフォーマンスが遅い
ファイル・システム上の非同期 I/O がパフォーマンス上の問題を示している場合は、ダイレ
クト I/O オプションを使用してファイル・システムをマウントするか、または
FILESYSTEMIO_OPTIONS=SETALL 初期化パラメータを設定します。設定できる最大 I/O
サイズは、1MB です。
プライマリ・データベースの停止を回避するにはログ・ファイ
ルを一致させる必要がある
構成の 1 つ以上のスタンバイ・データベースでスタンバイ REDO ログを構成した場合は、
各スタンバイ・データベースの現在のスタンバイ REDO ログ・ファイルのサイズが、プラ
イマリ・データベースの現行のオンライン REDO ログ・ファイルのサイズと正確に一致し
ていることを確認してください。
ログ・スイッチが発生したときに、プライマリ・データベースに新しい現行のオンライン
REDO ログ・ファイルのサイズと一致する使用可能なスタンバイ REDO ログ・ファイルが
ない場合、次のようになります。
■
■
プライマリ・データベースは、最大保護モードで動作している場合は停止し、最大可用
性モードで動作している場合は、最大パフォーマンス・モードに変更されます。
スタンバイ・データベース上の RFS プロセスにより、スタンバイ・データベースにアー
カイブ REDO ログ・ファイルが作成され、次のメッセージがアラート・ログに書き込
まれます。
No standby log files of size <#> blocks available.
たとえば、プライマリ・データベースが、ログ・ファイルが 100K および 200K の 2 つのオ
ンライン REDO ログ・グループをそれぞれ使用する場合、スタンバイ・データベースは、
ログ・ファイル・サイズが 100K および 200K の 4 つのスタンバイ REDO ログ・グループを
持ちます。
また、REDO ログ・グループをプライマリ・データベースに追加した場合は、対応するスタ
ンバイ REDO ログ・グループをスタンバイ・データベースに追加する必要があります。こ
れにより、プライマリ・データベースが悪影響を受ける可能性が低くなります。これは、ロ
グ・スイッチが発生したときに、必要なサイズのスタンバイ REDO ログ・ファイルが使用
できないためです。
詳細は、5-29 ページの「スタンバイ REDO ログ・ファイルの構成」を参照してください。
Data Guard のトラブルシューティング
A-15
プライマリ・データベースの停止を回避するにはログ・ファイルを一致させる必要がある
A-16　Oracle Data Guard 概要および管理
B
Data Guard および Real Application
Clusters
Oracle Data Guard 構成は、単一インスタンスおよび複数インスタンスの RAC データベース
の組合せで構成されます。この章では、Oracle Data Guard を Oracle Real Application
Clusters データベースとともに使用する場合に適用される構成要件と考慮事項の概要を説明
します。次の項目で構成されています。
■
Real Application Clusters 環境でのスタンバイ・データベースの構成
■
Real Application Clusters 環境での構成に関する考慮事項
■
トラブルシューティング
Data Guard および Real Application Clusters
B-1
Real Application Clusters 環境でのスタンバイ・データベースの構成
Real Application Clusters 環境でのスタンバイ・データベースの
構成
スタンバイ・データベースを構成すると、Real Application Clusters を使用しているプライ
マリ・データベースを保護できます。次の表では、プライマリ・データベースとスタンバ
イ・データベースのインスタンスの可能な組合せについて説明します。
単一インスタンス・
スタンバイ・
データベース
複数インスタンス・
スタンバイ・
データベース
単一インスタンス・プライマリ・
データベース
可
可
複数インスタンス・プライマリ・
データベース
可
可
インスタンスの組合せ
それぞれの組合せでは、プライマリ・データベースの各インスタンスが、独自の REDO
データをスタンバイ・データベースのアーカイブ REDO ログ・ファイルへ転送します。
複数インスタンス・プライマリ・データベースと単一インスタンス・スタ
ンバイ・データベースの設定
図 B-1 では、プライマリ・データベース・インスタンスが 2 つある Real Application
Clusters データベース（複数インスタンス・プライマリ・データベース）が、単一インスタ
ンス・スタンバイ・データベースへ REDO データを転送しています。
B-2　Oracle Data Guard 概要および管理
Real Application Clusters 環境でのスタンバイ・データベースの構成
図 B-1 複数インスタンス・プライマリ・データベースからの REDO データの転送
この場合は、プライマリ・データベースのインスタンス 1 がローカル・アーカイブ REDO
ログ・ファイル 1、2、3、4、5 に REDO データをアーカイブし、スタンバイ・データベース
宛先に REDO データを転送するのに対し、インスタンス 2 がローカル・アーカイブ REDO
ログ・ファイル 32、33、34、35、36 に REDO データをアーカイブし、同じスタンバイ・
データベース宛先に REDO データを転送します。スタンバイ・データベースでは、アーカイ
ブ REDO ログ・ファイルを適用する正しい順序が自動的に判断されます。
Real Application Clusters 環境でプライマリ・データベースを設定する手順
各プライマリ・インスタンスを構成するには、第 3 章（フィジカル・スタンバイ・データ
ベース作成の場合）
、または第 4 章（ロジカル・スタンバイ・データベース作成の場合）の
説明に従ってください。
単一インスタンス・スタンバイ・データベースを設定する手順
STANDBY_ARCHIVE_DEST パラメータおよび LOG_ARCHIVE_FORMAT パラメータを定義し
て、アーカイブ REDO ログ・ファイルおよびスタンバイ REDO ログ・ファイルの場所を指
定するには、第 3 章（フィジカル・スタンバイ・データベース作成の場合）
、または第 4 章
（ロジカル・スタンバイ・データベース作成の場合）の説明に従ってください。
Data Guard および Real Application Clusters
B-3
Real Application Clusters 環境でのスタンバイ・データベースの構成
複数インスタンス・プライマリ・データベースと複数インスタンス・
スタンバイ・データベースの設定
図 B-2 に、Real Application Clusters 環境のプライマリおよびスタンバイ・データベースの
構成を示します。これによって、スタンバイ・データベースでログ転送サービスの処理とロ
グ適用サービスの処理を分離できるため、プライマリとスタンバイの両方で、データベース
全体のパフォーマンスが向上します。
図 B-2 Real Application Clusters のスタンバイ・データベース
図 B-2 で、丸で囲まれた数字はローカル接続を示し、四角で囲まれた数字はリモート接続を
示します。
Real Application Clusters 環境では、スタンバイ・インスタンスは、REDO データをプライ
マリ・データベースから受信できます。これは受信インスタンス
受信インスタンスと呼ばれます。
ただし、
受信インスタンス
アーカイブ REDO ログ・ファイルは、最終的には、リカバリ・インスタンス
リカバリ・インスタンスからアクセス
リカバリ・インスタンス
が可能なディスク・デバイスに存在する必要があります。スタンバイ・データベースのアー
B-4　Oracle Data Guard 概要および管理
Real Application Clusters 環境でのスタンバイ・データベースの構成
カイブ REDO ログ・ファイルの、受信インスタンスからリカバリ・インスタンスへの転送
は、インスタンス間アーカイブ操作を使用して実現されます。
スタンバイ・データベースのインスタンス間アーカイブ操作のためには、スタンバイ REDO
ログ・ファイルを、プライマリ・データベースのアーカイブ REDO ログ・ファイルの一時
リポジトリとして使用する必要があります。スタンバイ REDO ログ・ファイルを使用する
ことにより、スタンバイ・データベースのパフォーマンスと信頼性が向上するだけでなく、
クラスタ・ファイル・システムを持っていないクラスタで、インスタンス間アーカイブ操作
の実行が可能になります。ただし、インスタンス間アーカイブ操作を行うためにはスタンバ
イ REDO ログ・ファイルが必要なため、プライマリ・データベースは、ログ・ライター・
プロセス（LGWR）またはアーカイバ・プロセス（ARCn）を使用して、プライマリ・デー
タベースでアーカイブ操作を実行する必要があります。
プライマリ・データベースとスタンバイ・データベースの両方が Real Application Clusters
構成の場合、スタンバイ・データベースの単一のインスタンスが、プライマリ・インスタン
スによって転送されるログ・ファイルのすべてのセットを適用します。この場合、REDO
データを適用しないスタンバイ・インスタンスを、REDO Apply の進行時に読取り専用モー
ドにすることはできません。
Real Application Clusters 環境でスタンバイ・データベースを設定する手順
スタンバイ・データベースでログ転送サービスを設定するには、次の手順を実行します。
1.
スタンバイ REDO ログ・ファイルを作成します。Real Application Clusters 環境では、
スタンバイ REDO ログ・ファイルは、すべてのインスタンスに共有されるディスク・
デバイスに存在する必要があります。詳細は、5-29 ページの「スタンバイ REDO ログ・
ファイルの構成」を参照してください。
2.
リカバリ・インスタンスで、ローカルでアーカイブするように、LOG_ARCHIVE_DEST_
1 初期化パラメータの LOCATION 属性を定義します。これは、インスタンス間アーカイ
ブが不要なためです。
3.
リカバリ・インスタンスで、リカバリ・インスタンスにアーカイブするように、LOG_
ARCHIVE_DEST_1 初期化パラメータの SERVICE 属性を定義します。
4.
リカバリ・インスタンスでログ適用サービスを開始します。
Real Application Clusters 環境でプライマリ・データベースを設定する手順
プライマリ・データベースでログ転送サービスを設定するには、次の手順を実行します。
1.
すべてのインスタンスで、LOG_ARCHIVE_DEST_n パラメータに LGWR 属性を定義し
て、LGWR プロセスがアーカイブ操作を実行するように指定します。
2.
LOG_ARCHIVE_DEST_n パラメータを適切な値に設定することで、受信インスタンスに
REDO データを送信するように各スタンバイ・インスタンスを構成します。
各プライマリ・データベース・インスタンスが、対応するスタンバイ・データベース・イン
スタンスにアーカイブできれば理想的です。ただし、これは必須ではありません。
Data Guard および Real Application Clusters
B-5
Real Application Clusters 環境でのスタンバイ・データベースの構成
インスタンス間アーカイブ・データベース環境の設定
インスタンス間アーカイブ環境内では、各インスタンスがそのアーカイブ REDO ログ・
ファイルをクラスタの単一インスタンスに転送します。このインスタンスは、リカバリ・イ
リカバリ・イ
ンスタンスと呼ばれます。このインスタンスには一般的に、Recovery
Manager によりバッ
ンスタンス
クアップとリストア・サポートに使用できるテープ・ドライブがあります。例 B-1 に、複数
インスタンスにわたって REDO データをアーカイブするための LOG_ARCHIVE_DEST_n 初
期化パラメータを設定する方法を示します。リカバリ・インスタンスを除くすべてのインス
タンスでこれらの文を実行してください。
例 B-1 インスタンス間アーカイブの宛先の設定
SQL>
SQL>
SQL>
SQL>
ALTER
ALTER
ALTER
ALTER
SYSTEM
SYSTEM
SYSTEM
SYSTEM
SET
SET
SET
SET
LOG_ARCHIVE_DEST_1 = 'LOCATION=archivelog MANDATORY REOPEN=120';
LOG_ARCHIVE_DEST_STATE_1 = enable;
LOG_ARCHIVE_DEST_2 = 'SERVICE=prmy1 MANDATORY REOPEN=300';
LOG_ARCHIVE_DEST_STATE_2 = enable;
宛先 1 は、インスタンス・リカバリに必要なローカル・アーカイブ REDO ログ・ファイル
が格納されているリポジトリです。これは必須の宛先です。失敗する原因としてディスク領
域不足が予測されるので、再試行間隔は 2 分間です。これは、DBA が不要なアーカイブ
REDO ログ・ファイルをパージするのに十分な時間です。宛先の障害の通知は、プライマ
リ・データベースのアラート・ログを手動で検索することによって実行されます。
宛先 2 は、ローカル・ディスク記憶域からテープへ、アーカイブ REDO ログ・ファイルを
バックアップするために Recovery Manager が使用される、リカバリ・インスタンス・デー
タベースです。これは必須の宛先で、再接続のしきい値は 5 分間です。これは、ネットワー
ク関連の障害を修正するのに必要な時間です。宛先の障害の通知は、プライマリまたはスタ
ンバイ・データベースのアラート・ログを手動で検索することによって実行されます。
インスタンス間アーカイブが使用できるのは、ARCn プロセスを使用したときのみです。イ
ンスタンス間アーカイブに LGWR プロセスを使用すると、RFS プロセスで障害が発生し、
アーカイブ・ログの宛先がエラー状態になります。
B-6　Oracle Data Guard 概要および管理
Real Application Clusters 環境での構成に関する考慮事項
Real Application Clusters 環境での構成に関する考慮事項
この項では、Real Application Clusters 環境に固有の Data Guard 構成情報を提供します。こ
の章は、次の項目で構成されています。
■
アーカイブ REDO ログ・ファイル名の形式
■
アーカイブ先の割当て制限
■
データ保護モード
■
ロールの推移
アーカイブ REDO ログ・ファイル名の形式
アーカイブ REDO ログ・ファイル名は、log_%parameter の形式になります。%parameter に
は、表 B-1 のパラメータを 1 つ以上含めることができます。
表 B-1 LOG_ARCHIVE_FORMAT 初期化パラメータのディレクティブ
ディレクティブ
説明
%a
データベース・アクティブ ID
%A
0（ゼロ）を埋め込んだデータベース・アクティブ ID
%d
データベース ID
%D
0（ゼロ）を埋め込んだデータベース ID
%t
インスタンス・スレッド番号
%T
0（ゼロ）を埋め込んだインスタンス・スレッド番号
%s
ログ・ファイル順序番号
%S
0（ゼロ）を埋め込んだログ・ファイル順序番号
%r
リセットログ ID
%R
0（ゼロ）を埋め込んだリセットログ ID
次に例を示します。
LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc
Real Application Clusters が、LOG_ARCHIVE_FORMAT パラメータを持つアーカイブ REDO
ログ・ファイルを一意に識別するためには、スレッド・パラメータ %t または %T が必須で
す。アーカイブ・ログ・ファイルの格納場所に関する詳細は、5-34 ページの「アーカイブ
REDO ログ・ファイルの代替ディレクトリ位置の指定」を参照してください。
Data Guard および Real Application Clusters
B-7
Real Application Clusters 環境での構成に関する考慮事項
アーカイブ先の割当て制限
LOG_ARCHIVE_DEST_n 初期化パラメータの QUOTA_SIZE 属性を使用すると、アーカイブ
先で使用できるディスク・デバイスの物理記憶域の量を指定できます。宛先に割り当てられ
た物理ディスクの全部または一部を占有できるようにアーカイブ先を指定できます。たとえ
ば、Real Application Clusters 環境では、物理的なディスク・デバイスを 2 つ以上の別々の
ノードで共有できます。インスタンス間では、初期化パラメータの情報が共有されていない
ため、Real Application Clusters ノードは、物理ディスク・デバイスが他のインスタンスと
共有されていることを認識していません。このため、宛先ディスク・デバイスがいっぱいに
なったときには重大な問題が発生します。すなわち、すべてのインスタンスがすでにいっぱ
いになったデバイスへのアーカイブを実行するまで、エラーは検出されません。これはデー
タベースの可用性に影響を及ぼします。
データ保護モード
最大保護モードまたは最大可用性モードで稼働している Real Application Clusters 構成では、
インスタンスがスタンバイ宛先との接続を失うと、他のすべてのインスタンスがその宛先へ
のデータ送信を停止します（これによって、宛先に転送されたデータの整合性が維持され、
リカバリが可能になります）
。
障害のあったスタンバイ宛先が復旧すると、Data Guard は、ギャップなしになるまで、そ
のサイトを再同期化モードで実行します。これによって、そのスタンバイ宛先は Data
Guard 構成に再び含まれます。
次のリストで、Real Application Clusters 環境における保護モードの動作を説明します。
■
最大保護の構成
接続を失った宛先が最後のスタンバイ宛先の場合、インスタンスは接続を失い、停止し
ます。Real Application Clusters 構成内でスタンバイ宛先への接続を維持している宛先
は、接続を失ったインスタンスをリカバリし、スタンバイ宛先への送信を継続します。
Real Application Clusters 構成内のすべてのインスタンスが最後のスタンバイ宛先への
接続を失った場合のみ、プライマリ・データベースが停止します。
B-8　Oracle Data Guard 概要および管理
Real Application Clusters 環境での構成に関する考慮事項
ロールの推移
この項は、次の項目で構成されています。
■
スイッチオーバー
■
フェイルオーバー
スイッチオーバー
Real Application Clusters データベースの場合は、1 つのプライマリ・インスタンスと 1 つの
スタンバイ・インスタンスのみをスイッチオーバー時にアクティブにできます。したがっ
て、スイッチオーバーの前に、1 つのプライマリ・インスタンスと 1 つのスタンバイ・イン
スタンス以外はすべて停止します。スイッチオーバーの完了後、スイッチオーバーの実行時
に停止したプライマリ・インスタンスとスタンバイ・インスタンスを再起動します。
注意 : SQL ALTER DATABASE 文を使用してスイッチオーバーを実行す
ると、REDO ログ・ファイルが存在していない場合は自動的に作成されま
す。これによって、COMMIT 操作の完了に必要な時間が大幅に長くなる場
合があるため、フィジカル・スタンバイ・データベースの RAW デバイス
を構成するときは、REDO ログ・ファイルを常に手動で追加することをお
薦めします。
フェイルオーバー
Real Application Clusters スタンバイ・データベースへのフェイルオーバーを実行するには、
最初に 1 つのスタンバイ・インスタンス以外はすべて停止します。フェイルオーバーの完了
後、停止したインスタンスを再起動します。
Data Guard および Real Application Clusters
B-9
トラブルシューティング
トラブルシューティング
この項は、Real Application Clusters で発生する問題のトラブルシューティングのヘルプと
してご利用いただけます。次の項目で構成されています。
■
Real Application Clusters 構成でスイッチオーバーできない
■
ネットワーク停止時に Real Application Clusters の停止時間を回避する
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
B-10　Oracle Data Guard 概要および管理
トラブルシューティング
ネットワーク停止時に Real Application Clusters の停止時間を回避する
Real Application Clusters 環境でプライマリ・データベースをサポートするように Data
Guard を構成し、プライマリ・データベースが最大保護モードで稼働している場合、プライ
マリ・データベースとそのすべてのスタンバイ・データベース間のネットワークが停止する
と、ネットワーク接続がリストアされるまで、プライマリ・データベースは使用不可能にな
ります。最大保護モードでは、最後に使用したスタンバイ・データベースが使用不可能に
なった場合、プライマリ・データベースも停止します。
ネットワークの停止時間が長い場合は、ネットワーク接続がリストアされるまで、プライマ
リ・データベースを最大可用性モードまたは最大パフォーマンス・モードのいずれかで実行
するように変更することを考慮してください。プライマリ・データベースを最大可用性モー
ドに変更すると、プライマリ・データベースとスタンバイ・データベースの間にラグが発生
する可能性があります。ただし、ネットワークの問題が解決するまで、プライマリ・データ
ベースを使用することができます。
プライマリ・データベースを最大可用性モードに変更する場合は、次のプロシージャを使用
してデータの破損を防止することが重要です。
次に、ネットワークが停止し、Real Application Clusters 構成の保護モードを変更する場合
の手順を説明します。この例では、PFILE ではなく、サーバー・パラメータ・ファイル
（SPFILE）を使用していることを前提とします。
1.
この時点では、Real Application Clusters プライマリ・インスタンスはすべて停止して
います。STARTUP MOUNT コマンドを発行して、1 つのインスタンスを開始します。
STARTUP MOUNT;
2.
最大保護モードを最大可用性モードまたは最大パフォーマンス・モードのいずれかに変
更する場合は、5-31 ページの「Data Guard 構成のデータ保護モードの設定」の説明に
従ってください。また、ブローカを使用している場合は、
『Oracle Data Guard Broker』
を参照してください。たとえば、次の文は、最大可用性保護モードを設定します。
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;
3.
Real Application Clusters プライマリ・データベースをオープンし、通常にアクセスし
ます。
後でネットワークが回復したときに、次の手順を実行して最大保護モードに戻ります。
1.
Real Application Clusters プライマリ・データベースのすべてのインスタンスを停止し
ます。
2.
Real Application Clusters プライマリ・データベースのシングル・インスタンスをオー
プンせずにマウントし、通常にアクセスします。
Data Guard および Real Application Clusters
B-11
トラブルシューティング
3.
Real Application Clusters プライマリ・データベースのモードを現行モード（最大可用
性または最大パフォーマンス）から最大保護モードに変更します。
4.
Real Application Clusters プライマリ・データベースをオープンし、通常にアクセスし
ます。
B-12　Oracle Data Guard 概要および管理
C
カスケードされた REDO ログ宛先
プライマリ・システムの負荷を軽減するために、カスケードされた
カスケードされた REDO ログ宛先を実装
ログ宛先
できます。これによって、スタンバイ・データベースは、REDO データをプライマリ・デー
タベースから直接受信するのではなく、別のスタンバイ・データベースから受信します。次
のデータベースを構成できます。
■
■
フィジカル・スタンバイ・データベース。プライマリ・データベースから受信した着信
REDO データを、プライマリ・データベースと同じ方法で他のリモートの宛先に再転送
します。
ロジカル・スタンバイ・データベース。読取り / 書込みモードでオープンされるため、
プライマリ・データベースから受信した REDO データのフィルタ処理と適用が完了し
た後に生成した REDO データを、独自のフィジカルまたはロジカルのスタンバイ・
データベースのセットに送信します。
図 C-1 は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベース
へのカスケードされた REDO ログ宛先を示しています。
カスケードされた REDO ログ宛先
C-1
図 C-1 カスケードされた REDO ログ宛先の構成例
スタンバイ・データベースでは、REDO データを最大 9 個の宛先までカスケードできます。
ただし、実際には、カスケードされた REDO データを受信するように構成するのは、主と
してレポート生成またはバックアップのオフロード専用のスタンバイ・データベースのみで
す。ロールの推移に関与する可能性のあるスタンバイ・データベースは、プライマリ・デー
タベースから直接 REDO データを受信するように構成し、LOG_ARCHIVE_DEST_n パラメー
タと LOG_ARCHIVE_DEST_STATE_n パラメータを定義します。この結果、スイッチオー
バー操作またはフェイルオーバー操作を実行した場合も、引き続き新しいプライマリ・デー
タベースから直接 REDO データを受信できます。
この項は、次の項目で構成されています。
■
カスケードされた REDO ログ宛先の構成
■
カスケードされた REDO ログ宛先を使用したロールの推移
■
カスケードされた REDO ログ宛先の例
C-2　Oracle Data Guard 概要および管理
カスケードされた REDO ログ宛先の構成
カスケードされた REDO ログ宛先の構成
次の各項では、カスケードされた REDO ログ宛先を使用できるように Data Guard 構成を設
定する方法について説明します。
■
フィジカル・スタンバイ・データベースに対するカスケードされた REDO ログ宛先の構成
■
ロジカル・スタンバイ・データベースに対するカスケードされた REDO ログ宛先の構成
フィジカル・スタンバイ・データベースに対するカスケードされた REDO
ログ宛先の構成
フィジカル・スタンバイ・データベースが着信 REDO データを別の宛先セットに送信でき
るようにするには、次の項目を定義する必要があります。
■
■
プライマリ・データベースの LOG_ARCHIVE_DEST_n 初期化パラメータを定義して、
LGWR 転送方法を使用するカスケードの開始点となるフィジカル・スタンバイ・データ
ベースを設定します。要件に応じて、SYNC または ASYNC ネットワーク・プロトコルを
使用します。
受信側のフィジカル・スタンバイ・データベースで、十分なスタンバイ REDO ログ・
ファイルを定義し、アーカイブが可能であることを確認します。
この時点で、カスケードのエンド・ポイントを定義するフィジカル・スタンバイ・データ
ベースの LOG_ARCHIVE_DEST_n 初期化パラメータの定義を開始できます。フィジカル・ス
タンバイ・データベースの元の設定の一部として、フィジカル・スタンバイ・データベース
がプライマリ・ロールに推移した際にローカル・アーカイブに使用する、ローカル・アーカ
イブ先を定義していることに注意してください。たとえば、LOG_ARCHIVE_DEST_1 初期化
パラメータを 'LOCATION=/physical1/arch' の位置に定義したとします。フィジカル・
スタンバイ・データベースがロールを切り替えると、アーカイブされたすべての REDO ロ
グ・ファイルは、LOG_ARCHIVE_FORMAT 初期化パラメータで定義した書式で、このディレ
クトリに格納されます。このローカル・アーカイブ先は、STANDBY_ARCHIVE_DEST パラ
メータで定義した宛先と同じにできますが、これは必須ではありません。
この構成の副作用は、スタンバイ・データベースのアーカイブ・プロセスが、カスケードの
エンド・ポイントのみではなく、他のスタンバイ・データベースおよびプライマリ・データ
ベース（定義済で使用可能な場合）に対して、REDO データの送信を試行することです。受
信側のデータベースがプライマリ・データベースであるか、または同じ REDO データを正
常に受信済のスタンバイ・データベースである場合は、その受信データベースで受信を拒否
するため問題にはなりません。宛先のスタンバイ・データベースがログ・ファイルを正常に
受信していない場合、この副作用はアクティブなギャップ解消として機能します。この副作
用を回避するには、カスケードに関与しないすべての宛先の状態を DEFER に設定します。
ただし、スイッチオーバー操作またはフェイルオーバー操作を行う場合は、これらの宛先を
再び使用可能にする必要があります。
1 つの初期化パラメータ・ファイルを使用して、カスケードされた REDO ログ宛先と元のプ
ライマリ / スタンバイの宛先の両方を処理する場合は、カスケード・スタンバイ・データ
カスケードされた REDO ログ宛先
C-3
カスケードされた REDO ログ宛先の構成
ベースの宛先に加えて、プライマリ・データベースとその他のスタンバイ・データベースの
宛先も定義します。ただし、リモート宛先の合計数は、ローカル・アーカイブ先も含めて 10
を超えることはできません。
ロジカル・スタンバイ・データベースに対するカスケードされた REDO ロ
グ宛先の構成
プライマリ・データベースから直接 REDO データを受信するロジカル・スタンバイ・デー
タベースは、プライマリ・データベースから受信した REDO データのフィルタ処理と適用
が完了した後に生成した REDO データを、他のスタンバイ・データベースにカスケードす
るように構成できます。ロジカル・スタンバイ・データベースからカスケードされた REDO
データは、プライマリ・データベースで生成された元の REDO データと同一ではないため、
プライマリ・データベースから直接作成されたスタンバイ・データベースには適用できませ
ん。かわりに、ロジカル・スタンバイ・データベースからカスケードされた REDO データを
受信するスタンバイ・データベースは、ロジカル・スタンバイ・データベースのコピーから
作成する必要があります。この場合、次のようになります。
■
■
ロジカル・スタンバイ・データベースから作成されたフィジカル・スタンバイ・データ
ベースは、ロジカル・スタンバイ・データベースのブロック単位のコピーとなり、元の
プライマリ・データベースの論理的なコピーとなります。
ロジカル・スタンバイ・データベースから作成されたロジカル・スタンバイ・データ
ベースは、親のロジカル・スタンバイ・データベースの論理的なコピーとなり、元のプ
ライマリ・データベースに一部類似しています。これは、元のプライマリ・データベー
スのデータ以外に、親のロジカル・スタンバイ・データベースに格納されたすべての内
容（異なる索引やマテリアライズド・ビューなどの変更も含む）が存在するためです。
ロジカル・スタンバイ・データベースからカスケードされた REDO データを受信するスタ
ンバイ・データベースの場合は、プライマリ・データベースから直接 REDO データを受信
するフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースと
同じ設定タスクを実行する必要があります。任意の転送モード（LGWR または ARCH）および
ネットワーク・プロトコル（SYNC または ASYNC）が使用できます。LGWR 転送モードを使
用する場合は、オプションでスタンバイ・データベース上のスタンバイ REDO ログを使用
できます。
C-4　Oracle Data Guard 概要および管理
カスケードされた REDO ログ宛先を使用したロールの推移
カスケードされた REDO ログ宛先を使用したロールの推移
ほとんどのロールの推移は、別のスタンバイ・データベースからカスケードされた REDO
ログ・ファイルを受信するスタンバイ・データベースを使用して実行できます。ただし、
データ消失のリスクを最小限に抑え、ロールの推移を最速で行うには、障害リカバリ用に構
成されたすべてのスタンバイ・データベースで、REDO データをプライマリ・データベース
から直接受信することをお薦めします。
フィジカル・スタンバイ・データベースから REDO データを受信するスタ
ンバイ・データベース
再転送されたプライマリ・データベースの REDO データを受信するフィジカル・スタンバ
イ・データベースはすべて同一であり、ロールの推移に対して有効であるため、スイッチ
オーバーやフェイルオーバーの実行プロセスは、カスケードされた REDO ログ構成内のプ
ロセスとまったく同じです。唯一の違いは、end-of-redo データをスタンバイ・データベース
にカスケードする際に余分な時間がかかる場合があるという点です。フィジカル・スタンバ
イ・データベースを使用してロールの推移を行う方法については、7-12 ページの「フィジカ
ル・スタンバイ・データベースが関与するロールの推移」を参照してください。
ロジカル・スタンバイ・データベースから REDO データを受信するスタン
バイ・データベース
ロジカル・スタンバイ・データベースからカスケードされた REDO データを受信するスタ
ンバイ・データベースは、プライマリ・データベースが関与するスイッチオーバーに使用で
きません。スイッチオーバーで使用できるのは、プライマリ・データベースから REDO デー
タを直接受信するロジカル・スタンバイ・データベースのみです。ロジカル・スタンバイ・
データベースで生成された REDO データを受信するデータベースにフェイルオーバーする
場合は、同じロジカル・スタンバイ・データベースからカスケードされた REDO データを
受信する、それ以外のロジカル・スタンバイ・データベースのみ、フェイルオーバー後の
Data Guard 構成に引き続き使用することができます。ロジカル・スタンバイ・データベース
を使用してロールの推移を行う方法については、7-20 ページの「ロジカル・スタンバイ・
データベースが関与するロールの推移」を参照してください。
カスケードされた REDO ログ宛先
C-5
カスケードされた REDO ログ宛先の例
カスケードされた REDO ログ宛先の例
次の使用例では、カスケードされた REDO ログ宛先の構成オプションと使用方法を説明し
ます。
ローカル・フィジカル・スタンバイとカスケードされたリモート・フィジ
カル・スタンバイ
本社のオフィスにプライマリ・データベースがあり、別のビルにスタンバイ・データベース
を作成して、Local Area Network（LAN）で接続するとします。さらに、社内の保護要件に
より、REDO データとバックアップ・コピーを地理的に離れた位置にあるオフサイトで保管
し、LAN ではなく Wide Area Network（WAN）で接続するとします。
この両方のサイトに REDO データを転送できるように、プライマリ・データベースで 2 つ
の宛先を定義できますが、WAN を介した REDO データ送信のネットワーク待機時間が原因
で、プライマリ・データベースのスループットに余分なワークロードがかかります。
この問題を解決するために、LGWR および SYNC ネットワーク転送とスタンバイ REDO ロ
グ・ファイルを使用して、LAN 上のプライマリ・データベースとフィジカル・スタンバイ・
データベースとの間に緊密な接続を定義できます。これによって、プライマリ・データベー
スへの接続が失われないように保護し、プライマリ・データベースでメンテナンスが必要に
なった場合は、本番用の代替サイトを提供できます。WAN で接続されたセカンダリ・ロ
ケーションには、フィジカル・スタンバイ・データベースがサービスを提供し、REDO デー
タを確実にオフサイトで格納できるようにします。本番データベースの毎晩のバックアップ
は、WAN を介してリモート・スタンバイ・データベースに移送できるため、オフサイトの
格納場所にテープを発送する必要がなくなります。
プライマリ・データベースと LAN 上のフィジカル・スタンバイ・データベースの両方に接
続できない最悪の状況が発生した場合は、最小限のデータ消失でリモート・スタンバイ・
データベースにフェイルオーバーできます。元のスタンバイ・データベースからの、最後の
スタンバイ・データベースの REDO ログ・ファイルにアクセスできた場合は、リモート・
スタンバイ・データベースでリカバリできるため、データ消失はありません。
WAN を介した情報の送信によって問題が発生するのは、スイッチオーバーまたはフェイル
オーバー時（フィジカル・スタンバイ・データベースがプライマリ・ロールに推移したと
き）のみです。しかし、この構成は企業の保護要件を満たしています。
C-6　Oracle Data Guard 概要および管理
カスケードされた REDO ログ宛先の例
ローカル・フィジカル・スタンバイとカスケードされたリモート・ロジカ
ル・スタンバイ
離れた位置にプライマリ・データベースがあり、レポート生成のためにそのデータにローカ
ルでアクセスする必要があるとします。プライマリ・データベースには、障害時の回復に備
えて、すでに 1 つのスタンバイ・データベースが設定されています。このスタンバイ・デー
タベースはオフサイトの位置にあり、LAN で接続されています。プライマリ・データベー
スで、このサイトに情報を送信するように宛先を指定すると、プライマリ・データベースの
パフォーマンスに悪影響を与えます。
この問題の解決策は、使用例 1 で説明した解決策と似ています。ただし、すでに 1 つのフィ
ジカル・スタンバイ・データベースが準備されているため、REDO データはロジカル・スタ
ンバイ・データベースに送信することにします。最初に、次のことを確認します。
■
■
フィジカル・スタンバイ・データベースが、プライマリ・データベースのログ・ライ
ターから REDO データを受信していること。
スタンバイ REDO ログ・ファイルが定義済で使用されていること。
スタンバイ REDO ログ・ファイルが未定義の場合は、スタンバイ・データベースで動
的に定義できます。スタンバイ・データベースは、プライマリ・データベースで次回ロ
グ・スイッチが発生した後に、スタンバイ REDO ログ・ファイルの使用を開始します。
LGWR ネットワーク転送が使用されていない場合は、プライマリ・データベースでログ
転送サービスを動的に設定できます。これによって、プライマリ・データベースは、次
回のログ・スイッチの発生時にログ・ライターの使用を開始します。
次に、ロジカル・スタンバイ・データベースの通常の設定タスクを実行します。ロジカル・
スタンバイ・データベースの使用準備に必要な手順は、すべて通常プライマリ・ロケーショ
ンで実行する必要があります。ロジカル・スタンバイ・データベースが起動して稼働した
後、フィジカル・スタンバイ・データベースで宛先パラメータを定義し、REDO データが
WAN を介して送信され、ロジカル・スタンバイ・データベースに適用されるようにします。
カスケードされた REDO ログ宛先
C-7
カスケードされた REDO ログ宛先の例
ローカルおよびリモート・フィジカル・スタンバイとカスケードされた
ローカル・ロジカル・スタンバイ
製造サイトにあるプライマリ・データベースには、すでに 2 つのフィジカル・スタンバイ・
データベースが構成されています。1 つのスタンバイ・データベースは、別のビルに配置さ
れ、LAN で接続されており、もう 1 つのスタンバイ・データベースは離れた位置にある本
社のオフィスに配置され、WAN で接続されています。この 2 つのスタンバイ・データベー
スは、非データ消失モードで実行する必要があるため、WAN で接続されたスタンバイ・
データベースにカスケードされた REDO ログ宛先は使用できません。また、マーケティング
部門では、販売予測のために製造データにアクセスする必要があります。マーケティング部
門は毎日データにアクセスし、販売データと製造データを照合して、販売時期に対する製造
時期を正確に判断する必要があります。
解決策の 1 つとして、マーケティング部門が、本社にあるフィジカル・スタンバイ・データ
ベースに読取り専用モードでアクセスできるようにする方法があります。しかし、スタンバ
イ・データベースを読取り専用モードに設定するには、REDO Apply を停止する必要があり
ます。この結果、プライマリ・データベースの内容がフィジカル・スタンバイ・データベー
スに反映されるのが夜間のみになり、その間も、プライマリ・データベースは、製造工場で
の第 2 シフトおよび第 3 シフト作業によるデータを受信していることになります。さらに、
スタンバイ・データベースでは、アーカイブ REDO ログ・ファイルの適用が常に 12 時間以
上遅れます。プライマリ・データベースに別の宛先を追加して、REDO データを本社オフィ
ス内の異なるロジカル・スタンバイ・データベースに送信することもできます。本社オフィ
スで使用されているシステムが、フィジカル・スタンバイ・データベースと計画済みのロジ
カル・スタンバイ・データベースとでは異なるため、スタンバイ宛先の定義時に
DEPENDENCY 属性は使用できません。WAN を介して REDO データを送信する必要がある
ため、REDO データを 2 回送信することは、プライマリ・データベースのパフォーマンスを
許容できないレベルまで低下させると考えられます。
この問題は、カスケードされた REDO ログ宛先によって解決できます。カスケード・スタ
ンバイ・データベースを設定するには、第 4 章の説明に従ってロジカル・スタンバイ・デー
タベースを作成します。また、本社のフィジカル・スタンバイ・データベースが LAN を介
してこの新しいロジカル・スタンバイ・データベースに REDO データを転送するように設
定する必要もあります。この方法では、プライマリ・データベースは WAN を介してデータ
を 1 回のみ送信します。また、ロジカル・スタンバイ・データベースは、新しいマテリアラ
イズド・ビューを使用して変更できるため、マーケティング・グループは、データを効率的
に管理できます。ロジカル・スタンバイ・データベースは、オープンされて読取り / 書込み
モードになるため、マーケティング・グループは、プライマリ・データベースのパフォーマ
ンス、あるいはフィジカル・スタンバイ・データベースの実行可能性や現行の状態に影響を
与えずに、販売データに対する新規スキーマの追加やロードを実行できます。
C-8　Oracle Data Guard 概要および管理
カスケードされた REDO ログ宛先の例
カスケードされたロジカル・スタンバイ宛先の統合レポート生成
世界各地に 5 つの販売オフィスがあり、各オフィスに独自のプライマリ・データベースが配
置されているとします。すべてのオフィスに、障害時の回復対策を導入するとします。その
際、各プライマリ・データベースへの影響を最小限に抑えながら、すべてのデータに適時に
アクセスできる方法も考慮します。
この問題を解決するには、最初に、5 箇所の各オフィスに非データ消失環境を実装します。
これを行うには、LGWR および SYNC 属性を使用して、各オフィスにローカルのフィジカル・
スタンバイ・データベースを作成します。このフィジカル・スタンバイ・データベースは、
LAN または WAN で接続できます。次に、5 個の各プライマリ・データベースからロジカ
ル・スタンバイ・データベースを作成して、本社に配置します。ただし、REDO データは、
5 個の各プライマリ・データベースのログ転送サービスによって送信されるのではなく、5
個の各スタンバイ・データベースから WAN を介してロジカル・スタンバイ・データベース
に送信されるように構成します。1 つまたはすべてのロジカル・スタンバイ・データベース
で、別のロジカル・スタンバイ・データベースへのデータベース・リンクを定義し、このリ
ンクによって、全販売データにアクセスできるようにします。5 個の各プライマリ・データ
ベースの全情報ではなく、特定の表のみ必要な場合は、SKIP ルーチンを使用して、各ロジ
カル・スタンバイ・データベースに不要なデータの適用を停止できます。
ネットワーク・アップグレード時のカスケードされた宛先の一時使用
現在、夜間のバックアップのみで保護されているプライマリ・データベースがあるとしま
す。優れた障害時リカバリ対策をすぐに導入する必要があります。社内に、同じハードウェ
ア・タイプの別のシステムがありますが、フェイルオーバー用のスタンバイ・データベース
として使用するには処理能力が低く、データベース全体を格納するディスクも不足していま
す。データベース全体の格納に十分に対応できる唯一の別のシステムは、LAN で接続する
には離れた場所にあり、WAN で接続すると極端に低速になります。この対策の導入期限は、
いずれかのネットワークがアップグレードされるまでです。プライマリ・データベースで宛
先を追加して、REDO データをリモート・ロケーションに送信すると、パフォーマンスに重
大な影響を与えます。
この問題の暫定的な解決策は、リモート・システムでフィジカル・スタンバイ・データベー
スを作成し、小規模なローカル・システムに分散リポジトリを作成することです。分散リポ
ジトリには、スタンバイ制御ファイルとスタンバイ・データベースのアーカイブ REDO ロ
グ・ファイルのみが含まれ、データ・ファイルは含まれません。REDO データがローカルの
リポジトリに送信されるようにプライマリ・データベースを構成するには、ログ・ライ
ター・プロセス（LGWR）を同期モード（SYNC）で使用します。LAN で接続されるため、パ
フォーマンスへの影響は最小限で済みます。次に、リポジトリからデータが WAN を介して
実際のスタンバイ・データベースに送信されるように構成します。
この構成のリスクは、プライマリ・データベースの障害時に、プライマリ・データベースか
らスタンバイ・データベースへの全データの転送が完了していても、リポジトリからリモー
ト・スタンバイ・データベースへのデータ送信が完了していない可能性があることです。こ
の環境では、両方のシステムに同時に障害が発生しないかぎり、リモート・スタンバイ・
カスケードされた REDO ログ宛先
C-9
カスケードされた REDO ログ宛先の例
データベースでは、最後のログ・スイッチまでに送信された全データを受信できます。現行
の REDO ログ・ファイルを、手動で送信することが必要な場合もあります。
WAN がアップグレードされて、リモート・スタンバイ・データベースに直接接続できるよ
うになった場合は、リポジトリの宛先を変更して、リモート・スタンバイ・データベースを
直接指すようにするか、新たにリモート・スタンバイ・データベースの宛先を作成し、リポ
ジトリへの転送は、アーカイブ・ログ・リポジトリとして継続します。
C-10　Oracle Data Guard 概要および管理
D
Recovery Manager を使用したフィジカル・
スタンバイ・データベースの作成
この付録では、Oracle Recovery Manager を使用してフィジカル・スタンバイ・データベー
スを作成する方法を説明します。この付録は、次の項目で構成されています。
■
スタンバイ・データベースを作成するための Recovery Manager の準備
■
Recovery Manager を使用したスタンバイ・データベースの作成 : 概要
■
スタンバイ・インスタンスの設定
■
同一のディレクトリ構造のスタンバイ・データベースの作成
■
異なるディレクトリ構造のスタンバイ・データベースの作成
■
ローカル・ホスト上へのスタンバイ・データベースの作成
■
イメージ・コピーを使用したスタンバイ・データベースの作成
■
使用例
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-1
スタンバイ・データベースを作成するための Recovery Manager の準備
スタンバイ・データベースを作成するための Recovery Manager
の準備
Recovery Manager を使用してスタンバイ・データベースを作成すると、次のような利点が
あります。
■
■
■
プライマリ・データベースのバックアップを使用してスタンバイ・データベースが作成
され、データ・ファイルがバックアップからスタンバイ・サイトにリストアされます。
したがって、スタンバイ・データベースの作成中にプライマリ・データベースが影響を
受けることはありません。
ファイルやディレクトリ構造の名前変更が自動化されます。
アーカイブ REDO ログ・ファイルがバックアップからリストアされ、スタンバイ・デー
タベースがプライマリ・データベースと一致するまでリカバリが実行されます。
Recovery Manager を使用してスタンバイ・データベースを準備する手順は、基本的に、複
製データベースの準備と同じです。ただし、スタンバイ・データベース固有の問題に対処す
るために、
『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガ
イド』で説明されている複製手順を変更する必要があります。
この章で説明する Recovery Manager での作成手順を実行する前に、第 3 章のフィジカル・
スタンバイ・データベースの作成方法を理解してください。
この項は、次の項目で構成されています。
■
Recovery Manager を使用したスタンバイ・データベースの準備について
■
Recovery Manager を使用したスタンバイ制御ファイルの作成
■
■
Recovery Manager を使用した場合のスタンバイ・データベースのデータ・ファイルの
ネーミング
Recovery Manager を使用した場合のスタンバイ・データベース・ログ・ファイルの
ネーミング
D-2　Oracle Data Guard 概要および管理
スタンバイ・データベースを作成するための Recovery Manager の準備
Recovery Manager を使用したスタンバイ・データベースの準備について
プライマリ・データベースのバックアップからスタンバイ・データベースを作成するには、
手動での作成、または Recovery Manager の DUPLICATE コマンドのどちらでも使用できま
す。作成手順を実行する前に、スタンバイ・インスタンスを準備する必要があります。表
D-1 で説明されている準備タスクには、Recovery Manager を使用できます。
表 D-1 Recovery Manager を使用したスタンバイ・データベースの準備
タスク
手順の詳細
スタンバイ・データベースの作成に使用する 『Oracle Database バックアップおよびリカバリ
プライマリ・データベースのバックアップの 基礎』の説明に従い、プライマリ・データベー
作成
スの通常のバックアップ手順を実行します。
スタンバイ制御ファイルとして使用可能なプ 「Recovery Manager を使用したスタンバイ制御
ライマリ制御ファイルのバックアップの作成 ファイルの作成」を参照してください。
（存在しない場合）
スタンバイ・データ・ファイルのファイル名 「Recovery Manager を使用した場合のスタンバ
の選択
イ・データベースのデータ・ファイルのネーミ
ング」を参照してください。
スタンバイ・データベースのアーカイブ
REDO ログ・ファイルおよびスタンバイ
REDO ログ・ファイルのファイル名の選択
「Recovery Manager を使用した場合のスタンバ
イ・データベース・ログ・ファイルのネーミン
グ」を参照してください。
表 D-1 で示されている Recovery Manager のタスクに加え、スタンバイ・データベースを
セットアップするために次の追加タスクを実行する必要があります。
■
■
■
■
プライマリ初期化パラメータ・ファイルで必要な初期化パラメータをすべて設定しま
す。
スタンバイ・データベース用の初期化パラメータ・ファイルを作成し、必要なパラメー
タをすべて構成します。
スタンバイ・インスタンスに接続するために、必要に応じて Oracle Net をセットアップ
および構成します。
制御ファイルをマウントせずにスタンバイ・インスタンスを起動します。
初期化パラメータの設定など、フィジカル・スタンバイ・データベースの準備の詳細は、第
3 章を参照してください。Recovery Manager によってスタンバイ・データベース・ファイル
を正常に作成し、スタンバイ・データベースをマウントする前に、この章で説明されている
必要な準備タスクをすべて実行する必要があります。
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-3
スタンバイ・データベースを作成するための Recovery Manager の準備
Recovery Manager を使用したスタンバイ制御ファイルの作成
スタンバイ制御ファイルを作成するには、Recovery Manager の BACKUP コマンドまたは
COPY コマンドを使用して、次の手順を実行します。
手順 1 プライマリ・データベースに接続する
プライマリ・データベース、および必要に応じてリカバリ・カタログ・データベースへ接続
します。たとえば、次のように入力します。
% rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb
手順 2 スタンバイ制御ファイルを作成する
次のいずれかのコマンドを使用して、スタンバイ制御ファイルを作成します。BACKUP コマ
ンドと COPY コマンドの唯一の相違は、バックアップ・ファイル形式が異なる点です。
■
BACKUP コマンドを使用する
プライマリ・データベースをマウントし、BACKUP CURRENT CONTROLFILE FOR
STANDBY コマンドを使用して、スタンバイ制御ファイルを作成します。次の例では、構
成済チャネルを使用してスタンバイ制御ファイルを作成します。その後、データベース
をオープンして、アーカイブされていない REDO ログ・ファイルをすべてアーカイブ
し、一度もバックアップされていないログ・ファイルをバックアップします。
STARTUP MOUNT
BACKUP CURRENT CONTROLFILE FOR STANDBY;
SQL> ALTER DATABASE OPEN;
SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; # so backup is consistent and
recoverable
BACKUP ARCHIVELOG ALL NOT BACKED UP 1 TIMES;
■
COPY コマンドを使用する
現行のプライマリ制御ファイルをコピーします。COPY CURRENT CONTROLFILE コマン
ドの FOR STANDBY オプションを指定し、スタンバイ制御ファイルとして使用可能な、
現行の制御ファイルのコピーを作成します。次に例を示します。
COPY CURRENT CONTROLFILE FOR STANDBY TO '/tmp/sby_control01.ctl';
手順 3 バックアップ・セットまたはイメージ・コピーをリストする
必要に応じて、LIST コマンドを発行してバックアップ・セットをリストするか、LIST
COPY コマンドを発行してイメージ・コピーをリストします。
D-4　Oracle Data Guard 概要および管理
スタンバイ・データベースを作成するための Recovery Manager の準備
注意 : SQL ALTER DATABASE CREATE STANDBY CONTROLFILE AS 文
によってスタンバイ制御ファイルがすでに作成されている場合は、次のよ
うに Recovery Manager の CATALOG コマンドを使用して、リカバリ・カ
タログにスタンバイ制御ファイルのメタデータを追加できます。
CATALOG CONTROLFILECOPY '/tmp/sby_control01.ctl';
Recovery Manager を使用した場合のスタンバイ・データベースのデータ・
ファイルのネーミング
スタンバイ・データベースは、プライマリ・データベースと同じホストまたは異なるホスト
のいずれにでも常駐することが可能です。次の表に、ホスト上のディレクトリ構造が同じで
あるかどうかにより、スタンバイ・データベースのデータ・ファイル名の変更にどのように
影響するかを示します。
スタンバイ・データベースの
ホスト
ディレクトリ構造
名前の変更
プライマリと同じホスト
プライマリ・ホストと異なる
必須。
プライマリと同じホスト
プライマリ・ホストと同じ
無効。スタンバイ・データ
ベースのデータ・ファイルは、
プライマリ・データベースの
データ・ファイルと同じホス
トの同じディレクトリに常駐
できません。
プライマリと異なるホスト
プライマリ・ホストと同じ
必須ではない。
プライマリと異なるホスト
プライマリ・ホストと異なる
必須。
ディレクトリ構造がプライマリおよびスタンバイ・ホストで異なる場合、スタンバイ・デー
タ・ファイルのネーミングには次のオプションがあります。
■
■
■
スタンバイ・データベース初期化パラメータ DB_FILE_NAME_CONVERT の構成
Recovery Manager の DUPLICATE コマンドの DB_FILE_NAME_CONVERT オプションの
使用
スタンバイ・データベースを作成する際の CONFIGURE AUXNAME または SET NEWNAME
コマンドの使用
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-5
スタンバイ・データベースを作成するための Recovery Manager の準備
プライマリおよびスタンバイ・ホストのディレクトリ構造が同じ場合、ネーミングには次の
オプションがあります。
スタンバイ・ファイル名をプライマリ・ファイル名と同じにし（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_'
スタンバイ制御ファイル内のデータ・ファイル名を指定する方法が複数存在するため、設定
の優先順位を決定する方法が必要です。表 D-2 に、スタンバイ・データベース内のデータ・
ファイルのネーミングの階層を指定します。
表 D-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 句を指定する必要が
あります。
DB_FILE_NAME_CONVERT を使用したスタンバイ・ファイルのネーミングの方法は、
『Oracle Database リファレンス』を参照してください。
D-6　Oracle Data Guard 概要および管理
スタンバイ・データベースを作成するための Recovery Manager の準備
Recovery Manager を使用した場合のスタンバイ・データベース・ログ・
ファイルのネーミング
REDO ログ・ファイルは、Recovery Manager によってスタンバイ・データベースに作成さ
れません。ただし、第 3 章で説明しているように、スタンバイ・データベースで他のアク
ションを実行することにより、ログ・ファイルが作成される場合もあります。ログ・ファイ
ルは作成後、ログ・ファイルの通常のルールに従って管理およびアーカイブされます。
スタンバイ・データベースの REDO ログ・ファイルをネーミングする際、唯一のオプショ
ンは、スタンバイ制御ファイルで指定されるログ・ファイルのファイル名です。スタンバイ
上のログ・ファイル名をプライマリ上のファイル名と異なる名前にする必要がある場合は、
スタンバイ初期化パラメータ・ファイルで LOG_FILE_NAME_CONVERT を設定して、REDO
ログのファイル名を指定する方法を選択できます。
スタンバイ・データベース上で REDO ログ・ファイルのファイル名を指定する際、次の制
限事項に注意してください。
■
■
■
■
プライマリ・データベースおよびスタンバイ・データベースでログ・ファイルに異なる
ネーミング規則を使用している場合、REDO ログ・ファイルのネーミングには LOG_
FILE_NAME_CONVERT パラメータを使用する必要があります。
REDO ログ・ファイルの名前の変更には、SET NEWNAME または CONFIGURE AUXNAME
コマンドを使用できません。
REDO ログ・ファイルのファイル名の指定には、DUPLICATE コマンドの LOGFILE 句は
使用できません。
スタンバイ・データベース上の REDO ログ・ファイル名をプライマリ・データベースの
REDO ログ・ファイル名と同じ名前にする場合、DUPLICATE コマンドの
NOFILENAMECHECK 句を指定する必要があります。指定しない場合、スタンバイ・デー
タベースが異なるホスト上で作成されていても、Recovery Manager によりエラーが発
生します。
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-7
Recovery Manager を使用したスタンバイ・データベースの作成 : 概要
Recovery Manager を使用したスタンバイ・データベースの作成 :
概要
スタンバイ・データベースを作成する際、スタンバイ・データベースがプライマリ・データ
ベースと同じホスト上に存在するか、または異なるホスト上に存在するかにより、手順が異
なります。この章の手順は、第 3 章で説明したスタンバイのセットアップと準備が完了して
いることを前提としています。すべての必要な初期化パラメータの設定とネットワーク構成
の変更が完了するまでは、次の手順を実行しないでください。
スタンバイ・インスタンスの準備に必要な手順を完了した後、Recovery Manager の
DUPLICATE ... FOR STANDBY コマンドを実行し、プライマリ・データベースのバックアッ
プからスタンバイ・データベースを作成します。FOR STANDBY OPTION を使用せずに
DUPLICATE コマンドを使用して作成された複製データベースと異なり、スタンバイ・デー
タベースには新規 DBID が設定されません。したがって、スタンバイ・データベースをリカ
バリ・カタログに登録しないでください。
Recovery Manager がスタンバイ・データベースを作成後にリカバリするよう指定するかど
うかで、スタンバイ・データベースの作成手順が異なります。
DUPLICATE コマンドを使用して、スタンバイ・データベースではない複製データベースを
作成する方法は、
『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザー
ズ・ガイド』を参照してください。
リカバリを実行しない 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
D-8　Oracle Data Guard 概要および管理
Recovery Manager を使用したスタンバイ・データベースの作成 : 概要
Manager は接続を切断し、スタンバイ・データベースのメディア・リカバリを実行しま
せん。スタンバイ・データベースはリカバリ・カタログに登録しないでください。
リカバリを実行する Recovery Manager によるスタンバイの作成
DUPLICATE コマンドの DORECOVER オプションを指定した場合、Recovery Manager は、
「リカバリを実行しない Recovery Manager によるスタンバイの作成」の手順 1 ～ 5 と同じ手
順を実行します。その後、手順 6 のかわりに、次の手順を実行します。
1.
すべてのデータのリストア後、Recovery Manager はメディア・リカバリを開始します。
アーカイブ REDO ログ・ファイルを必要とするリカバリで、そのログ・ファイルが
ディスクにない場合、Recovery Manager はバックアップからログ・ファイルのリスト
アを試みます。
2.
Recovery Manager は、指定された時間、システム変更番号（SCN）またはログ・ファ
イル順序番号にスタンバイ・データベースをリカバリします。そのいずれも指定されて
いない場合は、最新の生成済アーカイブ REDO ログ・ファイルにリカバリします。
3.
Recovery Manager は、メディア・リカバリの完了後、スタンバイ・データベースをマ
ウントしたままにしますが、スタンバイ・データベースを手動または管理リカバリ・
モードには設定しません。スタンバイ・データベースはリカバリ・カタログに登録しな
いでください。
注意 : Recovery Manager でスタンバイ・データベースを作成した後、ス
タンバイ・データベースを手動または管理リカバリ・モードに設定した
り、読取り専用モードでオープンする前に、ギャップ・シーケンスを解決
する必要があります。ギャップ・シーケンスの解決方法の詳細は、5-40
ページの「アーカイブ・ギャップの管理」を参照してください。
Recovery Manager によってスタンバイ・データベースの作成後にリカバリを行う場合、実
行するリカバリに対してスタンバイ制御ファイルが使用可能である必要があります。した
がって、次の条件を満たしている必要があります。
■
■
スタンバイ・データベースのリカバリ終了時刻は、スタンバイ制御ファイルのチェック
ポイント SCN 以上である必要があります。
スタンバイ制御ファイルのチェックポイント SCN が含まれているアーカイブ REDO ロ
グ・ファイルは、リカバリ用にスタンバイ・サイトから使用可能である必要がありま
す。
これらの条件が満たされていることを確認するには、スタンバイ制御ファイルの作成後に
ALTER SYSTEM ARCHIVE LOG CURRENT 文を発行する方法があります。この文は、プライマ
リ・データベースのオンライン REDO ログ・ファイルをアーカイブします。その後、最新の
アーカイブ REDO・ログ・ファイルを Recovery Manager でバックアップするか、または
アーカイブ REDO ログ・ファイルをスタンバイ・サイトに移動します。
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-9
スタンバイ・インスタンスの設定
注意 : この章の手順では、スタンバイ・データベースの作成に Recovery
Manager のバックアップを使用していることを前提としています。
Recovery Manager のイメージ・コピーを使用している場合、「イメージ・
コピーを使用したスタンバイ・データベースの作成」を参照してくださ
い。
Recovery Manager でスタンバイ・データベースを作成する際の DUPLICATE の制限事項に
ついては、
『Oracle Database Recovery Manager リファレンス』を参照してください。
スタンバイ・インスタンスの設定
スタンバイのいずれの作成使用例を選択した場合でも、まずスタンバイ・インスタンスを起
動し、次に Recovery Manager をこのインスタンスに接続する必要があります。この手順の
詳細は、スタンバイ・サイトとプライマリ・サイトのディレクトリ構造が同じかどうかに
よって異なります。
スタンバイ・インスタンスを起動するには、次の手順を実行します。
1.
オペレーティング・システムのユーティリティを使用して、SPFILE（または初期化パラ
メータ・ファイル）をターゲット・ホストからスタンバイ・ホストにコピーします。3-9
ページの「スタンバイ・データベース用の初期化パラメータ・ファイルの準備」で説明
されているように、スタンバイ・データベース初期化パラメータ・ファイルの必須パラ
メータをすべて設定します。たとえば、異なるディレクトリ構造を持つ異なるホスト上
にスタンバイ・データベースを作成する場合、次の部分を編集します。
■
■
■
_DEST および _PATH で終わる初期化パラメータを編集し、パス名を指定します。
すべてのターゲット・データ・ファイルを獲得し、適切に変換するよう、DB_
FILE_NAME_CONVERT を編集します。たとえば、tbs_* を sbytbs_* に変更しま
す。
すべての REDO ログ・ファイルを獲得し、適切に変換するよう、LOG_FILE_
NAME_CONVERT を編集します。たとえば、log_* を sbylog_* に変更します。
たとえば、次にスタンバイ・データベース初期化パラメータ・ファイルのサンプルのパ
ラメータ設定を示します。
STANDBY_ARCHIVE_DEST = /fs3/arc_dest/
LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc
DB_FILE_NAME_CONVERT = '/oracle', '/fs3/oracle', '/dbf', '/fs3/oracle'
LOG_FILE_NAME_CONVERT = '/oracle', '/fs3/oracle'
D-10　Oracle Data Guard 概要および管理
スタンバイ・インスタンスの設定
2.
SQL*Plus を使用して、スタンバイ・インスタンスをマウントせずに起動します。たと
えば、SYS（SYSDBA 権限がある）として sbdb1 に接続し、データベースを起動するに
は、次のコマンドを入力します。
SQL> CONNECT SYS/sys_pwd@sbdb1 AS SYSDBA
SQL> STARTUP NOMOUNT PFILE=initSBDB1.ora
3.
プライマリ・データベースがマウントまたはオープンされていない場合、SQL*Plus を
使用してデータベースをマウントまたはオープンします。たとえば、SYS として prod1
に接続し、データベースをオープンするには、次のコマンドを入力します。
SQL> CONNECT SYS/sys_pwd@prod1 AS SYSDBA
SQL> STARTUP PFILE=initPROD1.ora
リカバリ・カタログ・データベースがオープンされていることを確認します。たとえ
ば、SYS として catdb に接続し、リカバリ・カタログ・データベースをオープンする
には、次のコマンドを入力します。
SQL> CONNECT SYS/oracle@catdb AS SYSDBA
SQL> STARTUP PFILE=initCATDB.ora
4.
スタンバイ・サイト・インスタンスは、Oracle Net からアクセスできる必要がありま
す。次の手順を実行する前に、SQL*Plus を使用して、スタンバイ・インスタンスへの接
続を確立できることを確認します。スタンバイ・インスタンスには SYSDBA 権限で接続
する必要があるため、パスワード・ファイルが存在している必要があります。
5.
ターゲット・データベース、スタンバイ・インスタンス、およびリカバリ・カタログ・
データベース（使用している場合）へ接続します。プライマリ・データベースは
TARGET キーワードで指定し、スタンバイ・インスタンスは AUXILIARY キーワードで
指定します。
次の例では、オペレーティング・システムの認証を使用し、リカバリ・カタログなしで
接続を確立します。
% rman TARGET / AUXILIARY SYS/sys_pwd@sbdb1
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-11
同一のディレクトリ構造のスタンバイ・データベースの作成
同一のディレクトリ構造のスタンバイ・データベースの作成
スタンバイ・データベースの最も単純な作成方法は、異なるホストに作成し、同一のディレ
クトリ構造を使用することです。この場合、スタンバイ初期化パラメータ・ファイルで DB_
FILE_NAME_CONVERT または LOG_FILE_NAME_CONVERT パラメータを設定する必要がな
く、スタンバイ・データ・ファイルの新規のファイル名を設定する必要もありません。プラ
イマリおよびスタンバイ・データ・ファイル、およびログ・ファイルのファイル名は同じで
す。
リカバリを実行しないスタンバイ・データベースの作成
リカバリを実行せずにスタンバイ・データベースを作成する場合、DUPLICATE コマンドの
DORECOVER オプションを指定しないでください。デフォルトで、Recovery Manager はスタ
ンバイ・データベースをマウントした状態にし、リカバリを実行しません。
リカバリを実行せずにスタンバイ・データベースを作成するには、次の手順を実行します。
1. 「スタンバイ・インスタンスの設定」の手順を実行します。スタンバイ初期化パラメー
タ・ファイルで必要なパラメータをすべて設定していることを確認してください。
2.
スタンバイ・データ・ファイルの作成のみ行い、リカバリを実行しない場合、複製時に
次の手順を実行します。
a.
自動チャネルが構成されていない場合、1 つ以上の補助チャネルを手動で割り当て
ます。このチャネルにより、複製作業が実行されます。
b.
DUPLICATE コマンドで NOFILENAMECHECK を指定します。スタンバイおよびプラ
イマリ・データ・ファイル、およびログ・ファイルに同じ名前を使用する場合、
NOFILENAMECHECK オプションは必須です。指定しない場合、Recovery Manager
によりエラーが戻されます。
たとえば、スタンバイ・データベースを作成するには、次のコマンドを実行します。
DUPLICATE TARGET DATABASE FOR STANDBY
NOFILENAMECHECK;
D-12　Oracle Data Guard 概要および管理
同一のディレクトリ構造のスタンバイ・データベースの作成
スタンバイ・データベースの作成およびリカバリの実行
スタンバイ・データベースを作成し、リカバリを実行する場合、DUPLICATE コマンドの
DORECOVER オプションを指定します。
スタンバイ・データベースを作成し、リカバリを実行するには、次の手順を実行します。
1. 「スタンバイ・インスタンスの設定」の手順を実行します。スタンバイ初期化パラメー
タ・ファイルで必要なパラメータをすべて設定していることを確認してください。
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 ログ・ファイルを使用した不完全リカバ
リが実行されます。スタンバイ・データベースはマウントされた状態になります。
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-13
異なるディレクトリ構造のスタンバイ・データベースの作成
異なるディレクトリ構造のスタンバイ・データベースの作成
異なるディレクトリ構造のホスト上にスタンバイ・データベースを作成する場合、スタンバ
イ・データベースのデータ・ファイルおよび 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 章を参照してください。
D-14　Oracle Data Guard 概要および管理
異なるディレクトリ構造のスタンバイ・データベースの作成
DB_FILE_NAME_CONVERT を使用したスタンバイ・データベース・ファイル
のネーミング
この手順では、DB_FILE_NAME_CONVERT パラメータを使用してスタンバイ・データ・ファ
イルをネーミングし、LOG_FILE_NAME_CONVERT パラメータを使用してスタンバイ・デー
タベースの REDO ログ・ファイルをネーミングします。DB_FILE_NAME_CONVERT および
LOG_FILE_NAME_CONVERT パラメータを使用したスタンバイ・データベース・ファイルの
ネーミングの例は、3-3 ページの「プライマリ・データベースの初期化パラメータの設定」
を参照してください。
リカバリを実行しないスタンバイ・データベースの作成
リカバリを実行せずにスタンバイ・データベースを作成する場合、DUPLICATE コマンドの
DORECOVER オプションを指定しないでください。デフォルトで、Recovery Manager はスタ
ンバイ・データベースをマウントした状態にし、リカバリを実行しません。
パラメータを使用して、リカバリを実行せずにスタンバイ・ファイルをネーミングするに
は、次の手順を実行します。
1. 「スタンバイ・インスタンスの設定」の手順を実行します。スタンバイ初期化パラメー
タ・ファイルで必要なパラメータをすべて設定していることを確認してください。
2.
DUPLICATE コマンドを実行します。たとえば、次のコマンドを実行します。
DUPLICATE TARGET DATABASE FOR STANDBY;
バックアップのリストア後、Recovery Manager はスタンバイ・データベースをマウン
トした状態にします。
スタンバイ・データベースの作成およびリカバリの実行
DB_FILE_NAME_CONVERT パラメータを使用してスタンバイ・データ・ファイルをネーミン
グし、LOG_FILE_NAME_CONVERT パラメータを使用してスタンバイ・データベースのロ
グ・ファイルをネーミングした後、DUPLICATE コマンドの DORECOVER オプションを指定
してスタンバイ・データベースを作成し、リカバリを実行します。この場合の手順は、「ス
タンバイ・データベースの作成およびリカバリの実行」と同じです。
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-15
異なるディレクトリ構造のスタンバイ・データベースの作成
SET NEWNAME を使用したスタンバイ・データベース・ファイルのネーミ
ング
この場合、SET NEWNAME コマンドを使用してスタンバイ・データ・ファイルをネーミング
します。
リカバリを実行しないスタンバイ・データベースの作成
リカバリを実行せずにスタンバイ・データベースを作成する場合、DUPLICATE コマンドの
DORECOVER オプションを指定しないでください。デフォルトで、Recovery Manager はスタ
ンバイ・データベースをマウントした状態にし、リカバリを実行しません。
リカバリを実行せずに、SET
NEWNAME コマンドを使用してスタンバイ・データベース・
リカバリを実行せずに、
ファイルをネーミングするには、次の手順を実行します。
1. 「スタンバイ・インスタンスの設定」の手順を実行します。スタンバイ初期化パラメー
タ・ファイルで必要なパラメータをすべて設定していることを確認してください。
2.
DUPLICATE コマンドを実行します。次の手順に従ってください。
a.
自動チャネルが構成されていない場合、1 つ以上の補助チャネルを手動で割り当て
ます。
b.
SET NEWNAME コマンドを使用して、スタンバイ・データベースのデータ・ファイ
ルの新規ファイル名を指定します。
c.
DUPLICATE コマンドを発行します。
次の例では、構成済チャネルを使用してスタンバイ・データベースを作成します。
RUN
{
# set new filenames for the datafiles
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;
}
D-16　Oracle Data Guard 概要および管理
異なるディレクトリ構造のスタンバイ・データベースの作成
スタンバイ・データベースの作成およびリカバリの実行
スタンバイ・データベースを作成し、リカバリを実行する場合、DUPLICATE コマンドの
DORECOVER オプションを指定します。
SET NEWNAME コマンドを使用してスタンバイ・データベース・ファイルをネーミング
し、リカバリを実行するには、次の手順を実行します。
1. 「スタンバイ・インスタンスの設定」の手順を実行します。スタンバイ初期化パラメー
タ・ファイルで必要なパラメータをすべて設定していることを確認してください。
2.
DUPLICATE コマンドを実行します。次の手順に従います。
a. 「リカバリを実行する Recovery Manager によるスタンバイの作成」で説明したよう
に、リカバリ終了時刻がスタンバイ制御ファイルのチェックポイント SCN 以上で
あり、チェックポイント SCN が含まれているログ・ファイルがリカバリ用に使用
可能であることを確認します。
b.
必要に応じて SET コマンドを発行し、不完全リカバリの終了時刻、SCN またはロ
グ順序番号を指定します。
c.
自動チャネルが構成されていない場合、1 つ以上の補助チャネルを手動で割り当て
ます。
d.
スタンバイ・データベースのデータ・ファイルの新規のファイル名を指定します。
e.
DORECOVER オプションを指定して DUPLICATE コマンドを発行します。
たとえば、構成済チャネルを使用してスタンバイ・データベースを作成するには、
Recovery Manager のプロンプトで次のコマンドを入力します。
# If desired, issue a LIST command to determine the SCN of the standby control
file.
# The SCN to which you recover must be greater than or equal to the control file
SCN.
LIST BACKUP OF CONTROLFILE;
LIST COPY OF CONTROLFILE;
RUN
{
# If desired, issue a SET command to terminate recovery at a specified point.
# SET UNTIL TIME 'SYSDATE-7';
# Set new filenames for the datafiles
SET NEWNAME FOR DATAFILE 1 TO '?/dbs/standby_data_01.f';
SET NEWNAME FOR DATAFILE 2 TO '?/dbs/standby_data_02.f';
.
.
.
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-17
異なるディレクトリ構造のスタンバイ・データベースの作成
DUPLICATE TARGET DATABASE FOR STANDBY
DORECOVER;
}
Recovery Manager により、すべての増分バックアップ、アーカイブ REDO ログ・ファ
イルのバックアップおよびアーカイブ REDO ログ・ファイルを使用した不完全リカバ
リが実行されます。スタンバイ・データベースはマウントされた状態になります。
CONFIGURE AUXNAME を使用したスタンバイ・データベース・ファイルの
ネーミング
この場合、CONFIGURE AUXNAME コマンドを使用してスタンバイ・データ・ファイルをネー
ミングします。
リカバリを実行しないスタンバイ・データベースの作成
リカバリを実行せずにスタンバイ・データベースを作成する場合、DUPLICATE コマンドの
DORECOVER オプションを指定しないでください。デフォルトで、Recovery Manager はスタ
ンバイ・データベースをマウントした状態にし、リカバリを実行しません。
CONFIGURE AUXNAME を使用して、リカバリを実行せずにスタンバイ・データベース・
ファイルをネーミングするには、次の手順を実行します。
1. 「スタンバイ・インスタンスの設定」の手順を実行します。スタンバイ初期化パラメー
タ・ファイルで必要なパラメータをすべて設定していることを確認してください。
2.
データ・ファイルの補助名を構成します。たとえば、次のように入力します。
# set auxiliary names
CONFIGURE AUXNAME FOR
CONFIGURE AUXNAME FOR
.
.
.
CONFIGURE AUXNAME FOR
3.
for the datafiles
DATAFILE 1 TO '/oracle/auxfiles/aux_1.f';
DATAFILE 2 TO '/oracle/auxfiles/aux_2.f';
DATAFILE n TO '/oracle/auxfiles/aux_n.f';
DUPLICATE コマンドを実行します。自動チャネルが構成されていない場合、次の例の
ように、DUPLICATE コマンドを発行する前に 1 つ以上の補助チャネルを手動で割り当
てます。
RUN
{
# allocate at least one auxiliary channel of type DISK or sbt
ALLOCATE AUXILIARY CHANNEL standby1 DEVICE TYPE sbt;
.
.
.
D-18　Oracle Data Guard 概要および管理
異なるディレクトリ構造のスタンバイ・データベースの作成
# issue the DUPLICATE command
DUPLICATE TARGET DATABASE FOR STANDBY;
}
4.
データ・ファイルの補助名を誤って上書きしないよう、指定を解除します。たとえば、
Recovery Manager のプロンプトで、次のように入力します。
# un-specify auxiliary names for
CONFIGURE AUXNAME FOR DATAFILE 1
CONFIGURE AUXNAME FOR DATAFILE 2
.
.
.
CONFIGURE AUXNAME FOR DATAFILE n
the datafiles
CLEAR;
CLEAR;
CLEAR;
スタンバイ・データベースの作成およびリカバリの実行
スタンバイ・データベースを作成し、リカバリを実行する場合、DUPLICATE コマンドの
DORECOVER オプションを指定します。
CONFIGURE AUXNAME を使用して、スタンバイ・ファイルをネーミングし、リカバリを
実行するには、次の手順を実行します。
1. 「スタンバイ・インスタンスの設定」の手順を実行します。スタンバイ初期化パラメー
タ・ファイルで必要なパラメータをすべて設定していることを確認してください。
2.
データ・ファイルの補助名を設定します。たとえば、次のコマンドを入力します。
# set auxiliary names
CONFIGURE AUXNAME FOR
CONFIGURE AUXNAME FOR
.
.
.
CONFIGURE AUXNAME FOR
3.
for the datafiles
DATAFILE 1 TO '/oracle/auxfiles/aux_1.f';
DATAFILE 2 TO '/oracle/auxfiles/aux_2.f';
DATAFILE n TO '/oracle/auxfiles/aux_n.f';
DUPLICATE コマンドを実行します。次の手順に従います。
■
■
■
■
リカバリ終了時刻がスタンバイ制御ファイルのチェックポイント SCN 以上であり、
チェックポイント SCN が含まれているログ・ファイルがリカバリ用に使用可能で
あることを確認します（
「リカバリを実行する Recovery Manager によるスタンバイ
の作成」で説明しています）
。
必要に応じて SET コマンドを発行し、不完全リカバリの終了時刻、SCN またはログ
順序番号を指定します。
自動チャネルが構成されていない場合、1 つ以上の補助チャネルを手動で割り当て
ます。
DUPLICATE TARGET DATABASE FOR STANDBY コマンドを発行します。
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-19
異なるディレクトリ構造のスタンバイ・データベースの作成
たとえば、構成済チャネルを使用してスタンバイ・データベースを作成するには、
Recovery Manager のプロンプトで次のコマンドを入力します。
# If desired, issue a LIST command to determine the SCN of the standby control
file.
# The SCN to which you recover must be greater than or equal to the control file
SCN.
LIST BACKUP OF CONTROLFILE;
LIST COPY OF CONTROLFILE;
DUPLICATE TARGET DATABASE FOR STANDBY
DORECOVER;
Recovery Manager により、すべての増分バックアップ、アーカイブ REDO ログ・ファ
イルのバックアップおよびアーカイブ REDO ログ・ファイルを使用した不完全リカバ
リが実行されます。スタンバイ・データベースはマウントされた状態になります。
4.
データ・ファイルの補助名を誤って上書きしないよう、補助名の設定を消去します。た
とえば、Recovery Manager のプロンプトで、次のように入力します。
# un-specify auxiliary names for
CONFIGURE AUXNAME FOR DATAFILE 1
CONFIGURE AUXNAME FOR DATAFILE 2
.
.
.
CONFIGURE AUXNAME FOR DATAFILE n
D-20　Oracle Data Guard 概要および管理
the datafiles
CLEAR;
CLEAR;
CLEAR;
ローカル・ホスト上へのスタンバイ・データベースの作成
ローカル・ホスト上へのスタンバイ・データベースの作成
プライマリ・データベースと同一ホスト上にスタンバイ・データベースを作成する場合、
「異なるディレクトリ構造のスタンバイ・データベースの作成」で説明されている、異なる
ディレクトリ構造のリモート・ホスト上への複製と同じ手順を実行します。
プライマリ・データベースと同一ホスト上にスタンバイ・データベースを作成する場合、次
の制限事項に注意してください。
■
■
ターゲット・データベースと同一の Oracle ホーム上にスタンバイ・データベースを作成
できますが、異なるホスト上でのファイル名の変換と同じ方法でファイル名を変換する
必要があります。つまり、同一の Oracle ホーム内のスタンバイ・データベースを、異
なるディレクトリ構造を持つ異なるホスト上のデータベースのように扱う必要がありま
す。スタンバイ・データベース・ファイルおよびプライマリ・データベース・ファイル
が同一のマシンに存在する場合、これらに同じ名前を使用できません。
両方のデータベースで DB_UNIQUE_NAME 初期化パラメータを設定する必要があります。
注意 : プライマリ・データベースと同一の Oracle ホーム内にスタンバ
イ・データベースを作成する場合、NOFILENAMECHECK オプションを使用
しないでください。使用すると、ターゲット・データベース・ファイルを
上書きしたり、DUPLICATE コマンドでエラーが発生して失敗する可能性
があります。
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-21
イメージ・コピーを使用したスタンバイ・データベースの作成
イメージ・コピーを使用したスタンバイ・データベースの作成
この項は、次の項目で構成されています。
■
概要
■
コピーおよびデータ・ファイルで同一の名前を使用する場合
■
コピーおよびデータ・ファイルで異なる名前を使用する場合
概要
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 NT の論理ドライブなどの機能を使用した
場合を除きます）
。
スタンバイ・ホスト上のイメージ・コピーのファイル名は、プライマリ・ホスト上のイメー
ジ・コピーと同じファイル名である必要があります。ただし、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 として作成されます。
D-22　Oracle Data Guard 概要および管理
イメージ・コピーを使用したスタンバイ・データベースの作成
表 D-3 に、1 つのデータ・ファイルでのスタンバイ・データベースの作成に NFS を使用した
2 つの使用例を示します。
表 D-3 イメージ・コピーを使用したスタンバイ・データベースの作成 : 使用例
NFS マウン
ト・ポイント
プライマリ・データ・
ファイルのファイル名
イメージ・
コピーの
ファイル名
/data
/oracle/dbs/df1.f
/data/df1.f
（両ホストで
同じ）
/data
（両ホストで
同じ）
スタンバイ・データ・
ファイルのファイル名
/data/df1.f
（イメージ・コピーと
同じパス名）
/oracle/dbs/df1.f
/data/df1.f
/oracle/sb/df1.f
（イメージ・コピーと
異なるパス名）
手順の詳細
「コピーおよびデータ・ファ
イルで同一の名前を使用する
場合」を参照してください。
「コピーおよびデータ・ファ
イルで異なる名前を使用する
場合」を参照してください。
表 D-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 初期化パラ
メータに基づいて名前が変更されます。
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-23
イメージ・コピーを使用したスタンバイ・データベースの作成
コピーおよびデータ・ファイルで同一の名前を使用する場合
この手順では、スタンバイ・データ・ファイルおよびプライマリ・データ・ファイルのイ
メージ・コピーに同一のファイル名を使用していることを前提としています。
コピーおよびスタンバイ・データ・ファイルの名前が同一の場合にスタンバイ・データベー
スを作成するには、次の手順を実行します。
1.
プライマリ・データベース、および必要に応じてリカバリ・カタログ・データベースに
接続した後、プライマリ・データベースをマウントします。ただし、オープンしないで
ください。このとき、データベースが正常にクローズされてからマウントが行われたこ
とを確認します。たとえば、次のように入力します。
RMAN> STARTUP MOUNT PFILE=init.ora;
2.
スタンバイ・データ・ファイルのファイル名がプライマリ・データ・ファイルのファイ
ル名から変換されるよう、スタンバイ初期化パラメータ・ファイルで DB_FILE_NAME_
CONVERT が設定されていることを確認します。次に例を示します。
DB_FILE_NAME_CONVERT = '/oracle/dbs', '/dsk2/oracle'
3.
すべてのデータ・ファイルおよびスタンバイ制御ファイルをコピーします。たとえば、
次のように入力します。
COPY
DATAFILE 1 TO '/dsk2/oracle/df_1.f',
DATAFILE 2 TO '/dsk2/oracle/df_2.f',
DATAFILE 3 TO '/dsk2/oracle/df_3.f',
DATAFILE 4 to '/dsk2/oracle/df_4.f',
DATAFILE 5 TO '/dsk2/oracle/df_5.f',
DATAFILE 6 TO '/dsk2/oracle/df_6.f',
DATAFILE 7 TO '/dsk2/oracle/df_7.f',
DATAFILE 8 to '/dsk2/oracle/df_8.f',
DATAFILE 9 TO '/dsk2/oracle/df_9.f',
DATAFILE 10 TO '/dsk2/oracle/df_10.f',
DATAFILE 11 TO '/dsk2/oracle/df_11.f',
DATAFILE 12 to '/dsk2/oracle/df_12.f',
CURRENT CONTROLFILE FOR STANDBY TO '/dsk2/oracle/cf.f';
4.
スタンバイ・インスタンスを起動し、スタンバイ制御ファイルをマウントします。たと
えば、SQL*Plus を起動し、次のように入力します。
SQL> STARTUP NOMOUNT PFILE=/dsk2/oracle/dbs/initSTANDBY1.ora
SQL> ALTER DATABASE MOUNT;
D-24　Oracle Data Guard 概要および管理
イメージ・コピーを使用したスタンバイ・データベースの作成
コピーおよびデータ・ファイルで異なる名前を使用する場合
この手順では、スタンバイ・データ・ファイルおよびプライマリ・データ・ファイルのイ
メージ・コピーに異なるファイル名を使用していることを前提としています。
リカバリを実行しないスタンバイ・データベースの作成
スタンバイ・データベースを作成してリカバリを実行しない場合、DUPLICATE コマンドを
実行する必要はありません。デフォルトで、Recovery Manager はスタンバイ・データベー
スをマウントした状態にし、リカバリを実行しません。
コピーおよびスタンバイ・データ・ファイルの名前が異なる場合に、リカバリを実行せずに
スタンバイ・データベースを作成するには、次の手順を実行します。
1.
プライマリ・データベース、スタンバイ・インスタンス、および必要に応じてリカバ
リ・カタログ・データベースへ接続します。たとえば、次のように入力します。
% rman TARGET sys/sys_pwd@prod1 AUXILIARY sys/sys_pwd@sbdb1 CATALOG
rman/cat@catdb
2.
プライマリ・データベースをマウントします。ただし、オープンしないでください。こ
のとき、データベースが正常にクローズされてからマウントが行われたことを確認しま
す。たとえば、次のように入力します。
STARTUP MOUNT PFILE=initPROD1.ora
3.
スタンバイ・データ・ファイルのファイル名がプライマリ・データ・ファイルのファイ
ル名から変換されるよう、スタンバイ初期化パラメータ・ファイルで DB_FILE_NAME_
CONVERT を設定するか、または SET NEWNAME コマンドを発行します。たとえば、DB_
FILE_NAME_CONVERT パラメータを次のように設定します。
DB_FILE_NAME_CONVERT = '/oracle/dbs', '/dsk2/oracle'
4.
COPY コマンドを使用して、すべてのデータ・ファイルおよびスタンバイ制御ファイル
をコピーします。たとえば、次のコマンドを発行します。
COPY
DATAFILE
DATAFILE
DATAFILE
DATAFILE
DATAFILE
DATAFILE
DATAFILE
DATAFILE
DATAFILE
DATAFILE
DATAFILE
DATAFILE
1 TO '/dsk2/oracle/df_1.f',
2 TO '/dsk2/oracle/df_2.f',
3 TO '/dsk2/oracle/df_3.f',
4 to '/dsk2/oracle/df_4.f',
5 TO '/dsk2/oracle/df_5.f',
6 TO '/dsk2/oracle/df_6.f',
7 TO '/dsk2/oracle/df_7.f',
8 to '/dsk2/oracle/df_8.f',
9 TO '/dsk2/oracle/df_9.f',
10 TO '/dsk2/oracle/df_10.f',
11 TO '/dsk2/oracle/df_11.f',
12 to '/dsk2/oracle/df_12.f',
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-25
イメージ・コピーを使用したスタンバイ・データベースの作成
CURRENT CONTROLFILE FOR STANDBY TO '/dsk2/oracle/cf.f';
# To ensure the control file checkpoint is archived, archive the
# current redo log file
SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
5.
補助インスタンスを起動し、スタンバイ制御ファイルをマウントします。たとえば、
SQL*Plus を起動し、次のように入力します。
SQL> STARTUP MOUNT PFILE=/dsk2/oracle/dbs/initSTANDBY1.ora
スタンバイ・データベースの作成およびリカバリの実行
スタンバイ・データベースを作成し、リカバリを実行する場合、DUPLICATE コマンドの
DORECOVER オプションを指定します。
コピーおよびスタンバイ・データ・ファイルの名前が異なる場合に、スタンバイ・データ
ベースを作成し、リカバリを実行するには、次の手順を実行します。
1.
プライマリ・データベース、スタンバイ・インスタンス、および必要に応じてリカバ
リ・カタログ・データベースへ接続します。たとえば、次のように入力します。
% rman TARGET sys/sys_pwd@prod1 AUXILIARY sys/sys_pwd@sbdb1 CATALOG
rman/cat@catdb
2.
プライマリ・データベースをマウントします。ただし、オープンしないでください。こ
のとき、データベースが正常にクローズされてからマウントが行われたことを確認しま
す。たとえば、次のように入力します。
STARTUP MOUNT PFILE=initPROD1.ora
3.
スタンバイ・データ・ファイルのファイル名がプライマリ・データ・ファイルのファイ
ル名から変換されるよう、スタンバイ初期化パラメータ・ファイルで DB_FILE_NAME_
CONVERT を設定するか、または SET NEWNAME コマンドを発行します。たとえば、DB_
FILE_NAME_CONVERT パラメータを次のように設定します。
DB_FILE_NAME_CONVERT = '/oracle/dbs', '/dsk2/oracle'
4.
DUPLICATE コマンドを実行します。次の手順に従います。
a.
リカバリ終了時刻がスタンバイ制御ファイルのチェックポイント SCN 以上であり、
チェックポイント SCN が含まれているログ・ファイルがリカバリ用に使用可能で
あることを確認します（
「リカバリを実行する Recovery Manager によるスタンバイ
の作成」で説明しています）
。
b.
必要に応じて SET コマンドを発行し、リカバリの終了時刻、SCN またはログ順序
番号を指定します。
c.
自動チャネルが構成されていない場合、複製用に 1 つ以上の補助チャネルを手動で
割り当てます。
D-26　Oracle Data Guard 概要および管理
イメージ・コピーを使用したスタンバイ・データベースの作成
d.
すべてのデータ・ファイルおよびスタンバイ制御ファイルをコピーします。
e.
現行のオンライン REDO ログ・ファイルをアーカイブします。
f.
DORECOVER オプションを指定して DUPLICATE コマンドを発行します。
たとえば、次のコマンドを入力します。
COPY
DATAFILE 1 TO '/dsk2/oracle/df_1.f',
DATAFILE 2 TO '/dsk2/oracle/df_2.f',
DATAFILE 3 TO '/dsk2/oracle/df_3.f',
DATAFILE 4 to '/dsk2/oracle/df_4.f',
DATAFILE 5 TO '/dsk2/oracle/df_5.f',
DATAFILE 6 TO '/dsk2/oracle/df_6.f',
DATAFILE 7 TO '/dsk2/oracle/df_7.f',
DATAFILE 8 to '/dsk2/oracle/df_8.f',
DATAFILE 9 TO '/dsk2/oracle/df_9.f',
DATAFILE 10 TO '/dsk2/oracle/df_10.f',
DATAFILE 11 TO '/dsk2/oracle/df_11.f',
DATAFILE 12 to '/dsk2/oracle/df_12.f',
CURRENT CONTROLFILE FOR STANDBY TO '/dsk2/oracle/cf.f';
SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
DUPLICATE TARGET DATABASE FOR STANDBY
DORECOVER;
Recovery Manager により、すべての増分バックアップ、アーカイブ REDO ログ・ファ
イルのバックアップおよびアーカイブ REDO ログ・ファイルを使用した不完全リカバ
リが実行されます。スタンバイ・データベースはマウントされた状態になります。
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-27
使用例
使用例
この使用例では、プライマリ・データ・ファイルのバックアップおよびイメージ・コピーの
両方を使用する複製を実行します。この使用例の中で、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 ディレクトリ内に格納することにします。
D-28　Oracle Data Guard 概要および管理
使用例
スタンバイ・データ・ファイルのネーミング方式を選択する必要があります。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 datafiles 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 ログ・ファイル
がディスクに適用されます。
Recovery Manager を使用したフィジカル・スタンバイ・データベースの作成
D-29
使用例
D-30　Oracle Data Guard 概要および管理
E
アーカイブ・トレースの設定
Oracle データベースは、プライマリ・データベースから受信したアーカイブ REDO ログ・
ファイルの監査証跡をトレース・ファイルに書き込みます。LOG_ARCHIVE_TRACE パラ
メータは、ARCn プロセス、LGWR プロセス、プライマリ・データベースでのフォアグラウ
ンド・プロセス、およびスタンバイ・データベースでの RFS プロセスと FAL サーバー・プ
ロセスによって生成されるトレース出力を制御します。
アーカイブ・トレースの設定
E-1
LOG_ARCHIVE_TRACE 初期化パラメータ
LOG_ARCHIVE_TRACE 初期化パラメータ
スタンバイ・サイトへのアーカイブの進行状況を確認するには、プライマリおよびスタンバ
イ初期化パラメータ・ファイルに LOG_ARCHIVE_TRACE パラメータを設定します。LOG_
ARCHIVE_TRACE パラメータを設定すると、Oracle データベースは、次のように監査証跡を
トレース・ファイルに書き込みます。
■
プライマリ・データベースの場合
Oracle データベースは、プライマリ・データベース上のアーカイブ・プロセス・アク
ティビティ（ARCn プロセスとフォアグラウンド・プロセス、LGWR および FAL アク
ティビティ）の監査証跡をトレース・ファイルに書き込みます。このトレース・ファイ
ルのファイル名は、USER_DUMP_DEST 初期化パラメータで指定されます。
■
スタンバイ・データベースの場合
Oracle データベースは、スタンバイ・データベース上のアーカイブ REDO ログ・ファ
イルに関連する RFS プロセスと ARCn プロセス・アクティビティの監査証跡をトレー
ス・ファイルに書き込みます。このトレース・ファイルのファイル名は、USER_DUMP_
DEST 初期化パラメータで指定されます。
トレース・ファイルの位置の判別
データベースのトレース・ファイルは、初期化パラメータ・ファイル内で USER_DUMP_
DEST パラメータで指定されたディレクトリ内にあります。位置を判別するには、SQL*Plus
を使用してプライマリおよびスタンバイ・インスタンスに接続し、SHOW 文を発行します。
次に例を示します。
SQL> SHOW PARAMETER USER_DUMP_DEST
NAME
TYPE
VALUE
------------------------------------ ------- -----------------------------user_dump_dest
string ?/rdbms/log
E-2　Oracle Data Guard 概要および管理
トレース・ファイルの位置の判別
LOG_ARCHIVE_TRACE 初期化パラメータの設定
アーカイブ・トレース・パラメータの書式は次のとおりです。trace_level は整数です。
LOG_ARCHIVE_TRACE=trace_level
REDO Apply を実行しているか、または読取り専用モードに設定されているフィジカル・ス
タンバイ・データベースで LOG_ARCHIVE_TRACE パラメータの有効化、無効化または変更
を行うには、次のような SQL 文を発行します。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_TRACE=15;
この例では、LOG_ARCHIVE_TRACE パラメータを 15 に設定したので、「整数値の選択」で
説明するようにトレース・レベルが 1、2、4 および 8 に設定されます。
次のアーカイブ REDO ログ・ファイルをプライマリ・データベースから受信したときに、
リモート・ファイル・サーバー（RFS）および ARCn プロセスによって生成されたトレース
出力に影響するように、別のスタンバイ・セッションから ALTER SYSTEM 文を発行します。
たとえば、次のように入力します。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_TRACE=32;
整数値の選択
LOG_ARCHIVE_TRACE パラメータの整数値は、データのトレース・レベルを表します。一
般的には、レベルが高いほど、情報が詳細になります。次の整数値を使用できます。
レベル
意味
0
アーカイブ REDO ログのトレースを使用不可能にします（デフォ
ルト設定）
。
1
ログ・ファイルのアーカイブを追跡します。
2
アーカイブ・ログ・ファイルの宛先ごとにアーカイブ状況を追跡し
ます。
4
アーカイブ操作のフェーズを追跡します。
8
アーカイブ・ログの宛先のアクティビティを追跡します。
16
アーカイブ・ログの宛先の詳細なアクティビティを追跡します。
32
アーカイブ・ログの宛先のパラメータ修正を追跡します。
64
ARCn プロセスの状態のアクティビティを追跡します。
128
FAL サーバー・プロセスのアクティビティを追跡します。
256
将来のリリースでサポートされます。
512
非同期 LGWR アクティビティを追跡します。
アーカイブ・トレースの設定
E-3
トレース・ファイルの位置の判別
レベル
意味
1024
RFS の物理的なクライアントを追跡します。
2048
ARCn または RFS のハートビートを追跡します。
4096
リアルタイム適用アクティビティを追跡します。
LOG_ARCHIVE_TRACE パラメータの値をいくつかのトレース・レベルを合計した値に設定
すると、トレース・レベルを組み合せることができます。たとえば、パラメータを 6 に設定
すると、レベル 2 とレベル 4 のトレース出力が生成されます。
次に、ログ・ファイル 387 を 2 つの異なる宛先（サービス standby1 およびローカル・ディ
レクトリ /oracle/dbs）にアーカイブすることによってプライマリ・サイトに生成される
ARC0 トレース・データの例を示します。
注意 : レベルの数値は実際のトレース出力には表示されません。ここで
は説明の目的で示してあります。
Level
----( 1)
( 4)
( 4)
( 4)
( 4)
( 8)
(16)
( 8)
(16)
(16)
(16)
( 8)
(16)
( 8)
( 4)
( 2)
( 2)
( 4)
(16)
(16)
( 4)
( 1)
Corresponding entry content (sample)
-------------------------------ARC0: Begin archiving log# 1 seq# 387 thrd# 1
ARC0: VALIDATE
ARC0: PREPARE
ARC0: INITIALIZE
ARC0: SPOOL
ARC0: Creating archive destination 2 : 'standby1'
ARC0: Issuing standby Create archive destination at 'standby1'
ARC0: Creating archive destination 1 : '/oracle/dbs/d1arc1_387.log'
ARC0: Archiving block 1 count 1 to : 'standby1'
ARC0: Issuing standby Archive of block 1 count 1 to 'standby1'
ARC0: Archiving block 1 count 1 to : '/oracle/dbs/d1arc1_387.log'
ARC0: Closing archive destination 2 : standby1
ARC0: Issuing standby Close archive destination at 'standby1'
ARC0: Closing archive destination 1 : /oracle/dbs/d1arc1_387.log
ARC0: FINISH
ARC0: Archival success destination 2 : 'standby1'
ARC0: Archival success destination 1 : '/oracle/dbs/d1arc1_387.log'
ARC0: COMPLETE, all destinations archived
ARC0: ArchivedLog entry added: /oracle/dbs/d1arc1_387.log
ARC0: ArchivedLog entry added: standby1
ARC0: ARCHIVED
ARC0: Completed archiving log# 1 seq# 387 thrd# 1
E-4　Oracle Data Guard 概要および管理
トレース・ファイルの位置の判別
(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
Propagating archive 1 state version 0 to version 2
Propagating archive 2 destination version 0 to version
Propagating archive 2 state version 0 to version 1
Propagating archive 3 destination version 0 to version
Propagating archive 3 state version 0 to version 1
Propagating archive 4 destination version 0 to version
Propagating archive 4 state version 0 to version 1
2
1
1
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
---( 4)
( 4)
( 4)
( 1)
(32)
(32)
( 8)
(16)
( 1)
( 8)
(16)
( 1)
( 4)
( 4)
trace output (sample)
-----------------RFS: Startup received from ARCH pid 9272
RFS: Notifier
RFS: Attaching to standby instance
RFS: Begin archive log# 2 seq# 387 thrd# 1
Propagating archive 5 destination version 0 to version 2
Propagating archive 5 state version 0 to version 1
RFS: Creating archive destination file: /stby/parc1_387.log
RFS: Archiving block 1 count 11
RFS: Completed archive log# 2 seq# 387 thrd# 1
RFS: Closing archive destination file: /stby/parc1_387.log
RFS: ArchivedLog entry added: /stby/parc1_387.log
RFS: Archivelog seq# 387 thrd# 1 available 04/02/99 09:40:53
RFS: Detaching from standby instance
RFS: Shutdown received from ARCH pid 9272
アーカイブ・トレースの設定
E-5
トレース・ファイルの位置の判別
E-6　Oracle Data Guard 概要および管理
F
障害時リカバリに関する ReadMe ファイルの
サンプル
複数のスタンバイ・データベース構成では、複数のスタンバイ・データベース構成を設定し
たデータベース管理者（DBA）が、どのスタンバイ・データベースにフェイルオーバーする
のが適切であるかを必ずしも決定できる状態にあるとは限りません。したがって、各スタン
バイ・サイトで、プライマリ・サイト同様に障害時リカバリ計画を立てることが必要になり
ます。障害時リカバリ・チームの各メンバーは、障害時リカバリ計画を知っており、実行す
る手順を認識している必要があります。
例 F-1 は、どのスタンバイ・データベースをフェイルオーバーのターゲットとするかを決定
する上で必要な情報を示しています。
ReadMe ファイルは、DBA によって作成およびメンテナンスされ、次の方法を記述してい
る必要があります。
■
DBA としてのローカル・データベースへのログオン方法
■
スタンバイ・データベースが存在する各システムへのログオン方法
システム間にはファイアウォールが存在する可能性があります。ReadMe ファイルに
は、ファイアウォールを通過する手順も記載されている必要があります。
■
DBA としての他のデータベースへのログオン方法
■
最も新しいログが適用されているスタンバイ・データベースの識別方法
■
スタンバイ・データベース・フェイルオーバーの実行方法
■
クライアント・アプリケーションが、元のプライマリ・データベースではなく、新しい
プライマリ・データベースにアクセスできるネットワーク設定の構成方法
障害時リカバリに関する ReadMe ファイルのサンプル
F-1
例 F-1 障害時リカバリに関する ReadMe ファイルのサンプル
----------------Standby Database Disaster Recovery ReadMe File---------------Warning:
********************************************************************************
Perform the steps in this procedure only if you are responsible for failing over to
a standby database after the primary database fails.
If you perform the steps outlined in this file unnecessarily, you might corrupt the
entire database system.
********************************************************************************
Multiple Standby Database Configuration:
No.
Location
Type
IP Address
--- --------------- --------- -------------1
San Francisco
Primary
128.1.124.25
2
San Francisco
Standby
128.1.124.157
3
Boston
Standby
136.132.1.55
4
Los Angeles
Standby
145.23.82.16
5
San Francisco
Standby
128.1.135.24
You are in system No. 3, which is located in Boston.
Perform the following steps to fail over to the most up-to-date and available
standby database:
1. Log on to the local standby database as a DBA.
a)
Log on with the following user name and password:
username: Standby3
password: zkc722Khn
b)
Invoke SQL*Plus as follows:
% sqlplus
c)
Connect as the DBA as follows:
CONNECT sys/s23LsdIc AS SYSDBA
2.
Connect to as many remote systems as possible. You can connect to a maximum
of four systems. System 4 does not have a firewall, so you can connect to it
directly. Systems 1, 2, and 5 share the same firewall host. You need to go
to the firewall host first and then connect to each system. The IP address
for the firewall host is 128.1.1.100. Use the following user name and
F-2　Oracle Data Guard 概要および管理
password:
username: Disaster
password: 82lhsIW32
3.
Log on to as many remote systems as possible with the following user names
and passwords:
Login information:
No.
--1
2
3
4
5
4.
Location
IP Address
username
password
--------------- ------------- ---------- ---------San Francisco
128.1.124.25
Oracle9i
sdd290Ec
San Francisco
128.1.124.157 Standby2
ei23nJHb
(L o c a l)
Los Angeles
145.23.82.16
Standby4
23HHoe2a
San Francisco
128.1.135.24
Standby5
snc#$dnc
Invoke SQL*Plus on each remote system you are able to log on to as follows:
% sqlplus
5.
Connect to each remote database as follows:
CONNECT sys/password AS SYSDBA
The DBA passwords for each location are:
No.
--1
2
3
4
5
6.
Location
Password
--------------- ----------San Francisco
x2dwlsd91
San Francisco
a239s1DAq
(L o c a l)
Los Angeles
owKL(@as23
San Francisco
sad_KS13x
If you are able to log on to System 1, invoke SQL*Plus and execute the
following statements:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP PFILE=PRMYinit.ora;
Note: If you are able to execute the STARTUP statement successfully, the
primary database has not been damaged. Do not continue with this
procedure.
7.
Execute the following SQL statements on each standby database (including the
one on this system) that you were able to connect to:
障害時リカバリに関する ReadMe ファイルのサンプル
F-3
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> SELECT THREAD#, MAX(SEQUENCE#) FROM V$LOG_HISTORY GROUP BY THREAD#;
Compare the query results of each standby database. Fail over to the
standby database with the largest sequence number.
8.
Fail over to the standby database with the largest sequence number.
On the standby database with the largest sequence number, invoke SQL*Plus
and execute the following SQL statements:
SQL>
2>
SQL>
SQL>
SQL>
SQL>
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT FROM SESSION;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SHUTDOWN IMMEDIATE;
STARTUP PFILE=Failover.ora;
9. Update the other standby databases with the new primary database information and
ensure the log transport and log apply services are working correctly.
------------End of Standby Database Disaster Recovery ReadMe File-------------
F-4　Oracle Data Guard 概要および管理
索引
A
ABORT LOGICAL STANDBY 句
ALTER DATABASE の，13-6
ACTIVATE STANDBY DATABASE 句
ALTER DATABASE の，7-26，10-36，13-6
ADD STANDBY LOGFILE GROUP 句
ALTER DATABASE の，5-30，13-2
ADD STANDBY LOGFILE MEMBER 句
ALTER DATABASE の，5-37，13-2，A-2
ADD STANDBY LOGFILE 句
ALTER DATABASE の，5-30，8-18，A-2
ADD STANDBY MEMBER 句
ALTER DATABASE の，5-37
ADD SUPPLEMENTAL LOG DATA 句
ALTER DATABASE の，4-9，4-10，13-2
ADD TEMPFILE 句
ALTER TABLESPACE の，8-8
AFFIRM 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-2，
12-4
データ保護の設定，5-32
ALTER DATABASE RECOVER MANAGED
STANDBY DATABASE
DELAY 制御オプションの取消し，6-5
ALTER DATABASE RENAME FILE 文
スタンバイ制御ファイルの変更，8-15
ALTER DATABASE RENAME GLOBAL_NAME 文，
4-17
ALTER DATABASE 文，8-15
ABORT LOGICAL STANDBY 句，13-6
ACTIVATE STANDBY DATABASE 句，7-26，
10-36，13-6
ADD STANDBY LOGFILE GROUP 句，5-30
ADD STANDBY LOGFILE MEMBER 句，5-37，
13-2，A-2
ADD STANDBY LOGFILE 句，5-30，8-18，13-2，
A-2
ADD SUPPLEMENTAL LOG DATA 句，4-9，4-10，
13-2
ALTER STANDBY LOGFILE GROUP 句，5-30
ALTER STANDBY LOGFILE 句，5-30
CLEAR UNARCHIVED LOGFILES 句，8-36
COMMIT TO SWITCHOVER 句，7-13，7-18，7-21，
7-22，10-38，13-3，F-4
Real Application Clusters，B-10
トラブルシューティング，A-6，A-8，A-9
CREATE CONTROLFILE 句，8-11，8-35
CREATE DATAFILE AS 句，A-2
CREATE STANDBY CONTROLFILE 句，3-9，
4-15，A-4
REUSE 句，13-3
DROP LOGFILE 句，A-2
DROP STANDBY LOGFILE MEMBER 句，13-3，
A-2
FORCE LOGGING 句，2-8，3-3，10-40，13-4
GUARD 句，9-4
キーワード，9-4
MOUNT STANDBY DATABASE 句，13-4
OPEN READ ONLY 句，13-4
OPEN RESETLOGS 句，3-9，4-17，8-36
PREPARE TO SWITCHOVER 句，7-20，7-21，13-4
RECOVER MANAGED STANDBY DATABASE 句，
3-16，4-15，4-18，6-6，8-6，8-9，10-21，
10-36，13-5
REDO Apply の制御，6-7
スイッチオーバーの使用例，10-37
遅延間隔の上書き，6-5，12-16
取消し，6-8
索引 -1
バックグラウンド・プロセス，6-7，8-2
フェイルオーバー，13-6
フェイルオーバーの開始，7-17
フォアグラウンド・セッション，6-7
リアルタイム適用の開始，6-8
ログ適用サービスの取消し，8-6
REGISTER LOGFILE 句，12-38，13-5，A-5
REGISTER LOGICAL LOGFILE 句，10-26
RENAME FILE 句，A-2
SET STANDBY DATABASE 句
TO MAXIMIZE AVAILABILITY 句，13-5
TO MAXIMIZE PERFORMANCE 句，7-11
TO MAXIMIZE PROTECTION 句，13-5
START LOGICAL STANDBY APPLY 句，6-12，
7-27，13-5，A-11
IMMEDIATE キーワード，6-12，9-14
NEW PRIMARY キーワード，7-27
SQL Apply の開始，4-18
STOP LOGICAL STANDBY APPLY 句，6-12，
7-26，10-26，13-6
TEMPFILE 句，3-16，4-18
制限事項，A-2
ALTER DATABASE 文の RENAME GLOBAL_NAME 句，
4-17
ALTER SESSION GUARD DISABLE
データベース・リンクを定義するためのデータベー
ス・ガードの無効化，7-26
ALTER SESSION 文
GUARD ENABLE 句，13-7
ALTER SYSTEM 文
ARCHIVE LOG CURRENT 句，3-16，10-40
ALTER TABLESPACE 文，8-13，8-16，9-17，10-42
ADD TEMPFILE 句，8-8
FORCE LOGGING 句，8-19
スキップ，8-13，9-9
ALTERNATE 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-6，
A-4
LOG_ARCHIVE_DEST_STATE_n 初期化パラ
メータ，5-5
ANALYZER プロセス，9-12
APPLIED_SCN 列
DBA_LOGSTDBY_PROGRESS ビューの，10-24
APPLIER プロセス，9-13
APPLY_SET プロシージャ
DBMS_LOGSTDBY の，9-3
索引 -2
APPLY_UNSET プロシージャ
DBMS_LOGSTDBY の，9-3
AQ_TM_PROCESSES 動的パラメータ，A-7
ARCHIVE LOG CURRENT 句
ALTER SYSTEM の，3-16，10-40
ARCH 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-11
データ保護の設定，5-32
ARCn プロセス
「アーカイバ・プロセス（ARCn）」を参照
Asynchronous AutoLog，5-4
ASYNC 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-42
データ保護の設定，5-32
ネットワーク I/O 操作の開始，12-44
Automatic Storage Management（ASM）
使用するスタンバイ・データベースの作成，10-51
B
BUILDER プロセス，9-12
BUILD プロシージャ
DBMS_LOGSTDBY の，9-3
C
CANCEL オプション
管理リカバリと，8-3
CJQ0 プロセス，A-7
CLEAR UNARCHIVED LOGFILES 句
ALTER DATABASE の，8-10，8-36
COMMIT TO SWITCHOVER TO PRIMARY 句
ALTER DATABASE の，7-22
COMMIT TO SWITCHOVER 句
ALTER DATABASE の，7-13，7-18，7-21，7-22，
10-38，13-3，F-4
Real Application Clusters，B-10
トラブルシューティング，A-6，A-8，A-9
COMPATIBLE 初期化パラメータ
アーカイブ REDO ログ・ファイルのディレクトリ
位置に対する影響，5-34
CONTROL_FILE_RECORD_KEEP_TIME 初期化パラ
メータ，5-38
COORDINATOR プロセス，9-13
LSP バックグラウンド・プロセス，4-21，9-13
CREATE CONTROLFILE 句
ALTER DATABASE の，8-11，8-35
フィジカル・スタンバイ・データベースでの影響，
8-19
CREATE DATABASE 文
FORCE LOGGING 句，10-40
CREATE DATAFILE AS 句
ALTER DATABASE の，A-2
CREATE STANDBY CONTROLFILE 句
ALTER DATABASE の，3-9，4-15，13-3，A-4
CREATE TABLESPACE 文
スキップ，9-9
CREATE TEMPORARY TABLESPACE 文，8-8
TEMPFILE 句，8-8
D
Data Guard Broker
定義，1-7
Data Guard 構成
アーカイブ・プロセスを使用したスタンバイ宛先へ
のアーカイブ，5-7
定義，1-2
保護モード，1-9
ログ転送サービス，5-2
ログ・ライター・プロセスを使用したスタンバイ宛
先へのアーカイブ，5-18，6-3
Data Pump ユーティリティ
フィジカル・スタンバイ・データベースでのトラン
スポータブル表領域の使用，8-16
DB_FILE_NAME_CONVERT オプション
Recovery Manager の DUPLICATE コマンド，D-6
DB_FILE_NAME_CONVERT 初期化パラメータ
トランスポータブル表領域の位置，8-15
DB_NAME 初期化パラメータ，3-5，11-3
DB_RECOVERY_FILE_DEST 初期化パラメータ
リカバリ領域の設定，5-7
DB_UNIQUE_NAME 初期化パラメータ，A-9
共有フラッシュ・リカバリ領域に必須，5-10
DB_UNIQUE_NAME 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-13
DBA_DATA_FILES ビュー，8-35
DBA_LOGMNR_PURGED_LOG ビュー
削除できるアーカイブ REDO ログ・ファイルのリ
スト，9-5
DBA_LOGSTDBY_EVENTS ビュー，9-11，14-2，A-11
DBA_LOGSTDBY_LOG ビュー，6-14，14-2
アーカイブ REDO ログ・ファイルのリスト，10-23
DBA_LOGSTDBY_NOT_UNIQUE ビュー，4-6，14-2
DBA_LOGSTDBY_PARAMETERS ビュー，14-2
DBA_LOGSTDBY_PROGRESS ビュー，6-15，9-15，
14-2
SCN 情報の問合せと，10-24
DBA_LOGSTDBY_SKIP_TRANSACTION ビュー，
14-2
DBA_LOGSTDBY_SKIP ビュー，14-2
スキーマに対する SQL Apply サポートの判断，4-3
DBA_LOGSTDBY_UNSUPPORTED ビュー，4-3，14-2
DBA_TABLESPACES ビュー，8-35
DBMS_LOGSTDBY.APPLY_SET プロシージャ
アーカイブ REDO ログ・ファイルの適用遅延，6-6
DBMS_LOGSTDBY.GUARD_BYPASS_OFF プロシー
ジャ，9-19
DBMS_LOGSTDBY.GUARD_BYPASS_ON プロシー
ジャ，9-19
DBMS_LOGSTDBY パッケージ
APPLY_SET プロシージャ，9-3
APPLY_UNSET プロシージャ，9-3
BUILD プロシージャ，9-3
INSTANTIATE_TABLE プロシージャ，9-3，9-10
SKIP_ERROR プロシージャ，9-3，A-5
SKIP_TRANSACTION プロシージャ，9-4，A-11
SKIP プロシージャ，9-3，9-8，A-11
SQL Apply の管理に使用，9-3
UNSKIP_ERROR プロシージャ，9-4
UNSKIP_TRANSACTION プロシージャ，9-4
UNSKIP プロシージャ，9-4，9-10
DBMS_MVIEW.REFRESH ルーチン
マテリアライズド・ビューのリフレッシュ，9-19
DBNEWID（nid）ユーティリティ，4-16
DBSNMP プロセス，A-7
DDL トランザクション
SQL Apply からのフィルタ処理，9-8
DEFER 属性
LOG_ARCHIVE_DEST_STATE_n 初期化パラ
メータ，5-4，10-39
DELAY オプション
ALTER DATABASE RECOVER MANAGED
STANDBY DATABASE の
取消し，6-5
DELAY 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，6-5，
10-35，12-15
索引 -3
DEPENDENCY 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，5-39，
12-17
DISCONNECT FROM SESSION，8-2
DML トランザクション
SQL Apply からのフィルタ処理，9-8
DROP STANDBY LOGFILE MEMBER 句
ALTER DATABASE の，13-3，A-2
DROP STANDBY LOGFILE 句
ALTER DATABASE の，A-2
E
ENABLE 属性
LOG_ARCHIVE_DEST_STATE_n 初期化パラ
メータ，5-4，10-39
EXPIRE_TIME パラメータ
スタンバイ・データベースでの設定，12-30
F
FAL_CLIENT 初期化パラメータ，5-42
FAL_SERVER 初期化パラメータ，5-42
FORCE LOGGING 句
ALTER DATABASE の，2-8，3-3，10-40，13-4
ALTER TABLESPACE の，8-19
CREATE DATABASE の，10-40
G
GUARD DISABLE 句
ALTER SESSION の，7-26
GUARD ENABLE 句
ALTER SESSION，13-7
GUARD 句
ALTER DATABASE の，9-4
GV$INSTANCE ビュー，B-10
GV$ 固定ビュー，8-37
「ビュー」も参照
I
INSTANTIATE_TABLE プロシージャ
DBMS_LOGSTDBY の，9-3，9-10
索引 -4
J
JOB_QUEUE_PROCESSES 動的パラメータ，A-7
L
LGWR 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-11
データ保護の設定，5-32
LGWR プロセス
「ログ・ライター・プロセス（LGWR）」を参照
listener.ora ファイル
構成，3-13
トラブルシューティング，10-39，A-3，A-12
ログ転送サービス調整と，A-12
LOCATION 属性
設定
LOG_ARCHIVE_DEST_n 初期化パラメータ，
12-21，A-4
フラッシュ・リカバリ領域の設定に USE_DB_
RECOVERY_FILE_DEST を使用，5-9
LOG_ARCHIVE_DEST_10 初期化パラメータ
デフォルトのフラッシュ・リカバリ領域，5-7，5-8，
12-22
LOG_ARCHIVE_DEST_n 初期化パラメータ，
12-1 ～ 12-54
AFFIRM 属性，12-2，12-4
データ保護の設定，5-32
ALTERNATE 属性，12-6，A-4
ARCH 属性，12-11
データ保護の設定，5-32
ASYNC 属性，12-42
データ保護の設定，5-32
DB_UNIQUE_NAME 属性，12-13
DELAY 属性，6-5，10-35，12-15
DEPENDENCY 属性，5-39，12-17
LGWR 属性，12-11
データ保護の設定，5-32
LOCATION 属性，12-21，A-4
MANDATORY 属性，12-24
MAX_FAILURE 属性，12-26，12-40
NET_TIMEOUT 属性，12-29
NOAFFIRM 属性，12-4
NOALTERNATE 属性，12-6，A-4
NODB_UNIQUE_NAME 属性，12-13
NODELAY 属性，6-5，12-15
NODEPENDENCY 属性，12-17
NOMAX_FAILURE 属性，12-26，12-40
NONET_TIMEOUT 属性，12-29
NOQUOTA_SIZE 属性，12-32
NOQUOTA_USED 属性，12-35
NOREGISTER 属性，12-37
NOREOPEN 属性，5-26，12-39
NOTEMPLATE 属性，12-46
NOVERIFY 属性，12-53
ONDEMAND 属性，12-32
OPTIONAL 属性，12-24
QUOTA_SIZE 属性，12-32，B-8
QUOTA_USED 属性，12-35
REGISTER=location_format 属性，12-39
REGISTER 属性，12-37
REOPEN 属性，5-26，12-39
SERVICE 属性，12-21
SYNC 属性，5-17，12-42
データ保護の設定，5-32
TEMPLATE 属性，12-46
VALID_FOR 属性，5-23，12-49
VERIFY 属性，12-53
概要，5-4
属性の互換性，12-54
リカバリ領域の設定，5-7
LOG_ARCHIVE_DEST_STATE_n 初期化パラメータ，
5-4
ALTERNATE 属性，5-5
DEFER 属性，5-4，10-39
ENABLE 属性，5-4，10-39
RESET 属性，5-5
LOG_ARCHIVE_FORMAT 初期化パラメータ，5-35
LOG_ARCHIVE_MIN_SUCCEED_DEST 初期化パラ
メータ，12-24
LOG_ARCHIVE_TRACE 初期化パラメータ，5-46，
E-2，E-3
M
MANDATORY 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，5-36，
12-24
MAX_FAILURE 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，
12-26，12-40
MOUNT STANDBY DATABASE 句
ALTER DATABASE の，13-4
MRP
「管理リカバリ・プロセス」を参照
N
NET_TIMEOUT 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-29
NEWEST_SCN 列
DBA_LOGSTDBY_PROGRESS ビューの，10-24
NOAFFIRM 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-4
NOALTERNATE 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-6，
A-4
NODB_UNIQUE_NAME 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-13
NODELAY オプション
REDO Apply 操作，10-37
NODELAY 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，6-5，
12-15
NODEPENDENCY 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-17
NOMAX_FAILURE 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，
12-26，12-40
NONET_TIMEOUT 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-29
NOQUOTA_SIZE 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-32
NOQUOTA_USED 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-35
NOREGISTER 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-37
NOREOPEN 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，5-26，
12-39
NOTEMPLATE 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-46
NOVERIFY 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-53
索引 -5
O
ONDEMAND 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-32
OPEN READ ONLY 句
ALTER DATABASE の，13-4
OPEN RESETLOGS 句
ALTER DATABASE の，3-9，4-17，8-36
データベース・インカネーションの変更，8-33，
9-24
リカバリ，8-33，9-24
Optimal Flexible Architecture（OFA）
ディレクトリ構造，2-9
OPTIONAL 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，5-36，
12-24
ORA-01102 メッセージ
スイッチオーバー障害の原因となる，A-9
Oracle Advanced Security
セキュアな REDO の転送の提供，5-22
Oracle Automatic Storage Management（ASM）
，2-8，
2-9
Oracle Change Data Capture のアーカイブ，5-4
Oracle Managed Files（OMF），2-8，2-9
使用するスタンバイ・データベースの作成，10-51
Oracle Net
Data Guard 構成のデータベース間の通信，1-2
EXPIRE_TIME パラメータの設定，12-30
Oracle Recovery Manager ユーティリティ（RMAN）
フィジカル・スタンバイ・データベースのバック
アップ・ファイルの作成，8-20
Oracle Streams
アーカイブ，5-3
ダウンストリーム取得データベース，5-4
P
PARALLEL_MAX_SERVERS 初期化パラメータ，4-14，
9-29
指定
ロジカル・スタンバイ・データベースの作成，
4-12，6-18，11-6
PARALLEL オプション
REDO Apply 操作，6-9
REDO Apply のログ適用レートのチューニング，
6-18
索引 -6
PREPARE TO SWITCHOVER 句
ALTER DATABASE の，7-20，7-21，13-4
PREPARER プロセス，9-12
Q
QMN0 プロセス，A-7
QUOTA_SIZE 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，
12-32，B-8
QUOTA_USED 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-35
R
RAW デバイス
スタンバイ REDO ログ・ファイルの常駐，2-13
READER プロセス，9-12
Real Application Clusters，5-3，B-4
Data Guard を補完する特性，1-10
インスタンス間アーカイブ，B-5
インスタンス・リカバリ，B-6
スイッチオーバーの実行と，7-8，B-9
スタンバイ REDO ログの使用，2-13
スタンバイ REDO ログ・ファイルの使用，5-30，
B-5
スタンバイ・データベースと，1-2，B-2，B-5
設定
インスタンス間アーカイブ，B-6
最大データ保護，B-8
プライマリ・データベース，1-2，B-3，B-5
RECOVER MANAGED STANDBY DATABASE 句
ALTER DATABASE の，3-16，4-15，4-18，6-6，
6-7，8-6，8-9，10-21，10-36，13-5，13-6
REDO Apply の制御，6-7
スイッチオーバーの使用例，10-37
遅延間隔の上書き，6-5，12-16
取消し
ログ適用サービス，6-8，8-6
バックグラウンド・プロセス，6-7，8-2
フェイルオーバーの開始，7-17
フォアグラウンド・セッション，6-7
リアルタイム適用の開始，6-8
Recovery Manager
Data Guard を補完する特性，1-11
DUPLICATE コマンドの DB_FILE_NAME_
CONVERT オプション，D-6
コマンド
DUPLICATE，D-3
スタンバイ・データベース
DB_FILE_NAME_CONVERT 初期化パラメータ，
D-6
LOG_FILE_NAME_CONVERT 初期化パラ
メータ，D-7
Recovery Manager およびスタンバイ・インスタ
ンスの起動，D-10
Recovery Manager の準備，D-2
イメージ・コピーを使用した作成，D-22
作成，D-3，D-8
スタンバイ制御ファイルの作成，D-4
スタンバイ・データ・ファイルのネーミング，
D-5
REDO Apply
オプション
NODELAY，10-37
PARALLEL，6-9
開始，3-16，6-8
監視，6-9
定義，1-5，2-2，6-2
停止，8-3
テクノロジ，1-5
フェイルオーバー後のフラッシュバック，10-28，
10-31
ロールの推移とカスケードされた REDO ログ構成，
C-5
ログ適用レートのチューニング，6-18
REDO データ
検証，1-12
スタンバイ・システムでのアーカイブ，1-5，6-2
適用
REDO Apply テクノロジの使用，1-5
SQL Apply テクノロジの使用，1-5
スタンバイ・データベースへ，1-2，6-2
転送，1-2，1-4，5-1 ～ 5-26
REDO ログ
Data Guard 構成内，2-12
構成上の考慮事項，2-13
スタンバイ・データベース表の更新，1-12
セキュアな REDO の転送，5-22
フィジカル・スタンバイ・データベースでの自動
適用，6-7
補足情報のロギング，4-9，4-10
REDO ログ・ファイル
適用の遅延，6-5
REGISTER LOGFILE 句
ALTER DATABASE の，12-38，13-5，A-5
REGISTER LOGICAL LOGFILE 句，10-27
ALTER DATABASE の，5-44，7-24，10-26
REGISTER=location_format 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-39
REGISTER 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-37
RELY 制約
作成，4-7
REMOTE_LOGIN_PASSWORDFILE 初期化パラメータ
セキュアな REDO の転送，5-22
RENAME FILE 句，8-15
ALTER DATABASE の，A-2
REOPEN 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，5-26，
12-39
RESETLOGS_ID 列
V$DATABASE_INCARNATION ビューでの表示，
8-40
RESET 属性
LOG_ARCHIVE_DEST_STATE_n 初期化パラ
メータ，5-5
RFS
「リモート・ファイル・サーバー・プロセス（RFS）
」
を参照
S
SCN
適用可能な最大の（最新の）判断，10-23
SERVICE 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-21
SET STANDBY DATABASE 句
ALTER DATABASE の，7-11，13-5
SKIP_ERROR プロシージャ
DBMS_LOGSTDBY の，9-3
DBMS_LOGSTDBY パッケージ，A-5
SKIP_TRANSACTION プロシージャ
DBMS_LOGSTDBY の，9-4，A-11
索引 -7
SKIP プロシージャ
DBMS_LOGSTDBY の，9-3，9-8，A-11
SORT_AREA_SIZE 初期化パラメータ，8-9
SQL Apply，6-12
ANALYZER プロセス，9-12
APPLIER プロセス，9-13
BUILDER プロセス，9-12
COORDINATOR プロセス，9-13
DBMS_LOGSTDBY PL/SQL パッケージ，9-3
PREPARER プロセス，9-12
READER プロセス，9-12
V$LOGSTDBY ビューによるアクティビティの
表示，9-12
アーカイブ REDO ログ・ファイルの削除，9-5
開始
リアルタイム適用，6-12
管理，9-3
サポートされない表のデータ型，4-3
スキップされるスキーマ，4-3
定義，1-5，6-3
停止
リアルタイム適用，6-12
停止した場合の処置，A-11
表圧縮を使用したサポートされない表，4-3
表の行の一意識別，4-6
リアルタイム適用，9-14
ロールの推移とカスケードされた REDO ログ構成，
C-5
SQL セッション
スイッチオーバー障害の原因となる，A-6
SQL 文
スイッチオーバーと，7-13
ロジカル・スタンバイ・データベースでの実行，
1-3，1-5
ロジカル・スタンバイ・データベースでの
スキップ，4-4，9-8
STANDBY_ARCHIVE_DEST 初期化パラメータ，5-34
暗黙的なデフォルト値，5-34
リカバリ領域へのアーカイブ，5-10
STANDBY_FILE_MANAGEMENT 初期化パラメータ
データ・ファイルの改名時，8-16
トランスポータブル表領域に対する設定，8-15
START LOGICAL STANDBY APPLY 句
ALTER DATABASE の，4-18，6-12，7-27，13-5，
A-11
IMMEDIATE キーワード，6-12，9-14
索引 -8
STOP LOGICAL STANDBY APPLY 句
ALTER DATABASE の，6-12，7-26，10-26，13-6
SUPPLEMENTAL_LOG_DATA_PK 列
V$DATABASE，4-10
SUPPLEMENTAL_LOG_DATA_UI 列
V$DATABASE，4-10
SWITCHOVER_STATUS 列
V$DATABASE ビューの，7-12，7-13，A-6
SYNC 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，5-17，
12-42
データ保護の設定，5-32
SYS ユーザー・アカウント
REMOTE_LOGIN_PASSWORDFILE 初期化パラ
メータ，5-22
パスワード・ファイルの要件，5-22
T
TCP/IP ネットワーク・インターコネクト
期限切れのネットワーク・タイマー，12-30
TEMPFILE 句
ALTER DATABASE の，3-16，4-18
CREATE TEMPORARY TABLESPACE，8-8
TEMPLATE 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-46
tnsnames.ora ファイル
トラブルシューティング，10-39，A-3，A-9，A-12
ログ転送サービス調整と，A-12
U
UNSKIP_ERROR プロシージャ
DBMS_LOGSTDBY の，9-4
UNSKIP_TRANSACTION プロシージャ
DBMS_LOGSTDBY の，9-4
UNSKIP プロシージャ
DBMS_LOGSTDBY の，9-4，9-10
USER_DUMP_DEST 初期化パラメータ，E-2
USING CURRENT LOGFILE 句
リアルタイム適用の開始，6-8
V
V$ARCHIVE_DEST_STATUS ビュー，5-45，6-9，14-2
ログ適用サービスと MANAGED REAL TIME 列，
6-9
V$ARCHIVE_DEST ビュー，5-46，10-39，14-2，A-3
STANDBY_ARCHIVE_DEST パラメータの暗黙的な
デフォルト値の表示，5-34
すべての宛先の情報の表示，14-2
V$ARCHIVE_GAP ビュー，14-2
V$ARCHIVED_LOG ビュー，5-35，5-45，6-9，10-47，
14-3，A-5
最新のアーカイブ REDO ログ・ファイルの判定，
5-45
V$DATABASE_INCARNATION ビュー，14-3
データベース・インカネーション情報の取得
スタンバイ・データベース
データベース・インカネーション情報の表示，
8-40
V$DATABASE ビュー，14-3
SUPPLEMENTAL_LOG_DATA_PK 列，4-10
SUPPLEMENTAL_LOG_DATA_UI 列，4-10
SWITCHOVER_STATUS 列と，7-12，7-13，A-6
スイッチオーバーと，7-12，7-13
V$DATAFILE ビュー，10-41，10-43，14-3
V$DATAGUARD_CONFIG ビュー，14-3
V$DATAGUARD_STATUS ビュー，6-10，14-3
V$LOG_HISTORY ビュー，6-10，8-41，14-3
V$LOGFILE ビュー，14-3
V$LOGSTDBY_STATS ビュー，9-14，14-3
V$LOGSTDBY ビュー，9-13，14-3
SQL Apply の表示，9-12
V$LOG ビュー，5-45，14-3
V$MANAGED_STANDBY ビュー，6-8，14-4
V$RECOVER_FILE ビュー，8-35，8-36
V$SESSION ビュー，A-6，A-8
V$STANDBY_LOG ビュー，14-4
V$THREAD ビュー，8-35
VALID_FOR 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-49
値とロールベースの条件，12-50
概要，5-23
確認，10-13
キーワードの書式，12-50
例，5-24
ロールベースの宛先の定義，7-10
VERIFY 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-53
あ
アーカイバ・プロセス（ARCn）
インスタンス間アーカイブの設定，B-6
完了したアーカイブ REDO ログ・ファイルの内容
の確認，12-53
定義，5-11
アーカイブ
「アーカイブ REDO ログ・ファイル」も参照
インスタンス間，B-6
開始，3-16
失敗した宛先へ，5-26
指定
STANDBY_ARCHIVE_DEST 初期化パラメータ
を使用，5-10
障害解決ポリシー，5-26
ネットワーク転送モード，5-16，5-17
リアルタイム適用，6-3
「ログ転送サービス」も参照
アーカイブ REDO ログ・ファイル
COMPATIBLE 初期化パラメータの影響，5-34
宛先
DBA_LOGSTDBY_LOG ビューに表示，10-23
V$ARCHIVE_DEST_STATUS ビューに表示，
14-2
使用可能，5-4
無効化，5-4
概要，2-12
ギャップ管理，1-13，5-40
「ギャップ管理」も参照，1-12
欠落しているログの取得，10-26
最新のアーカイブを判定，5-45
指定
スタンバイ・データベースでのディレクトリ
位置，5-34
手動による転送，10-48
情報へのアクセス，6-9，8-41
スイッチオーバーの問題のトラブルシュー
ティング，A-5
スタンバイ・データベースと，6-8，6-13
索引 -9
適用
REDO Apply テクノロジ，1-5
SQL Apply テクノロジ，1-5
フィジカル・スタンバイ・データベースとロジ
カル・スタンバイ・データベース，1-3
適用の遅延，10-35，12-15
スタンバイ・データベースでの，6-5
転送された REDO データ，1-5，6-2
登録，5-44，10-26
フェイルオーバー時，7-24
部分的な，10-27
内容の確認，12-53
不要なファイルの削除，9-5
リスト，10-23
アーカイブ・ギャップ
原因，10-44
手動によるログのコピー，10-48
スタンバイ・データベースへの REDO ログの手動
による適用，10-50
定義，5-40
防止，10-46
ログの識別，10-47
アーカイブ先
代替，A-4
アーカイブ・トレース
スタンバイ・データベースと，5-46，E-2
アップグレード
Oracle Database ソフトウェア・バージョン，9-19
宛先
Oracle Change Data Capture のアーカイブ，5-4
Oracle Streams のアーカイブ，5-3
V$ARCHIVE_DEST に表示，14-2
VALID_FOR 属性が指定されたロールベースのロー
ルの推移の定義，7-10
インスタンス間アーカイブ，5-3，B-5
インスタンス間アーカイブ操作の設定，B-6
共有，5-39，12-17
指定，5-4
属性の変更，12-2
ロールの推移の設定の確認，10-13
ロールベースの定義，12-49
索引 -10
い
一時表領域
一時ファイル項目の追加，8-7
作成，8-8
フィジカル・スタンバイ・データベース，8-8
一時ファイル
「一時ファイル」を参照
作成，3-15，4-17，8-9
一時表領域への関連付け，8-8
追加，3-16，4-18，8-7
イベント
記録，9-11
ロジカル・スタンバイ・データベースでの表示，
9-11
インスタンス間アーカイブ，5-3
Real Application Clusters 構成，B-5
宛先の設定，B-6
スタンバイ REDO ログ・ファイル，B-5
ログ・ライター・プロセスの使用，B-5
お
オペレーティング・システム
Data Guard 構成の要件，2-6
オンライン REDO ログ・ファイル
アーカイブ・ギャップ管理，5-40
削除，8-18
追加，8-18
か
解決
論理的な破損，1-12
開始
REDO Apply，3-16，6-8，8-2
SQL Apply，4-18，6-12
ネットワーク I/O 操作，12-44
フィジカル・スタンバイ・データベース，3-15
リアルタイム適用，6-12
フィジカル・スタンバイ・データベース，6-8
ロジカル・スタンバイ・データベース，6-12，
9-14
ロジカル・スタンバイ・データベース，4-15，4-16，
4-17
改名
データ・ファイル
STANDBY_FILE_MANAGEMENT パラメータの
設定，8-16
プライマリ・データベースでの，8-16
確認
アーカイブ REDO ログ・ファイルの内容，12-53
スタンバイ REDO ログ・グループ，5-31
フィジカル・スタンバイ・データベース，3-17
ロール・ベースの宛先設定，10-13
ロジカル・スタンバイ・データベース，4-19
カスケードされた REDO ログ宛先
使用例，C-6 ～ C-10
スタンバイ REDO ログ・ファイルの必要性，2-13
定義，C-1
フィジカル・スタンバイ・データベース，C-1，C-3
ロールの推移，C-5
REDO Apply，C-5
SQL Apply，C-5
ロジカル・スタンバイ・データベース，C-4
ロジカル・スタンバイ・データベースでのマテリア
ライズド・ビュー，C-8
監視
スタンバイ・データベース，8-10
ログ適用サービス，6-9
ログ転送サービス，5-45
管理リカバリ操作
「REDO Apply」を参照
管理リカバリ・プロセス（MRP）
ARCn アーカイブ・プロセス，5-13，5-14
LGWR SYNC アーカイブ・プロセス，5-18
「REDO Apply」も参照
き
キーワード
VALID_FOR 属性，12-50
ギャップ管理，5-40
アーカイブ REDO ログ・ファイルの登録，5-44
フェイルオーバー時，7-24
「アーカイブ REDO ログ・ファイル」も参照
欠落しているログ・ファイルの検出，1-13
自動検出と自動解消，1-4，1-12
定義，5-40
共有
宛先，5-39，12-17
フラッシュ・リカバリ領域，5-10
く
グローバル動的パフォーマンス・ビュー，8-37
「ビュー」も参照
グローバル名
変更
ロジカル・スタンバイ・データベース，4-17
け
欠落しているログ順序番号
「ギャップ管理」も参照
検出，1-12，1-13
欠落しているログ・ファイルの自動検出，1-4，1-12，
5-40
検出
欠落しているアーカイブ REDO ログ・ファイル，
1-4，1-12，5-40
プライマリ・データベースとスタンバイ・データ
ベース間のネットワーク切断，12-30
検証
REDO データ，1-12
こ
高可用性
Data Guard による実現，1-1
RAC および Data Guard による実現，1-10
メリット，1-12
構成
REDO ログ，2-13
カスケードされた REDO ログ宛先，C-3
障害時リカバリ，1-3
初期化パラメータ
スイッチオーバーの準備，7-7
代替アーカイブ先，A-4
タイム・ラグのあるスタンバイ・データベース
の作成，10-35
フィジカル・スタンバイ・データベース用，3-9
フェイルオーバーの準備，7-9
ログ転送サービスの設定，5-6
スタンバイ REDO ログ・グループ，5-29
スタンバイ REDO ログ・ファイル，5-29
スタンバイ・データベースでのバックアップ，1-3
非データ消失，1-6
フィジカル・スタンバイ・データベース，2-9
索引 -11
フィジカル・スタンバイ・データベースのリス
ナー，3-13
リモート位置のスタンバイ・データベース，1-3
ロジカル・スタンバイ・データベースでのレポート
生成操作，1-3
構成オプション
Data Guard Broker での作成，1-7
REDO ログ，2-13
一般的な，1-3
概要，1-2
スタンバイ・データベース
インスタンス間アーカイブ，5-3，B-6
遅延されたアーカイブ REDO ログ・ファイルの
適用，10-35
遅延スタンバイ，6-5
パスワード・ファイルの要件，5-22
フィジカル・スタンバイ・データベース
位置とディレクトリ構造，2-9
固定ビュー
「ビュー」を参照
コピー
新しい表領域をリモート・スタンバイ・データベー
スに，8-13
制御ファイル，3-13
表領域をリモート・スタンバイ・ロケーションに，
8-13
コマンド、Recovery Manager
DUPLICATE，D-3
コマンドライン・インタフェース
ブローカ，1-13
さ
再作成
ロジカル・スタンバイ・データベース上の表，9-10
再接続
ネットワーク接続
最大可用性モードの場合，12-30
最大パフォーマンス・モードの場合，12-30
最大保護モードの場合，12-30
ネットワーク・タイムアウト後，12-30
最大可用性モード
概要，1-9
スタンバイ REDO ログ・ファイルの必要性，2-13
設定，5-32
定義，5-27
ネットワーク接続への影響，12-30
索引 -12
最大パフォーマンス・モード，7-11
概要，1-9，5-28
設定，5-32
ネットワーク接続への影響，12-30
最大保護モード
Real Application Clusters，B-8
概要，1-9，5-27
スタンバイ REDO ログ・ファイルの必要性，2-13
スタンバイ・データベースと，7-11
設定，5-32
ネットワーク接続への影響，12-30
再同期化
フィジカル・スタンバイ・データベースと REDO
の新規ブランチ，8-33，9-24
削除
アーカイブ REDO ログ・ファイル
DBA_LOGMNR_PURGED_LOG ビューに表示，
9-5
SQL Apply で不要，9-5
オンライン REDO ログ・ファイル，8-18
データ・ファイル，8-14
例，8-14
プライマリ・データベースから表領域を，8-14
作成
一時表領域
読取り専用フィジカル・スタンバイ・データ
ベース，8-8
一時ファイル，3-15，4-17
読取り専用フィジカル・スタンバイ・データ
ベース，8-8
従来の初期化パラメータ・ファイル
スタンバイ・データベース用，4-12
フィジカル・スタンバイ・データベース用，3-9
スタンバイ REDO ログ・ファイル，5-30
データベース・リンク，7-26
プライマリ・データベースのバックアップ・
ファイル，8-20
ロジカル・スタンバイ・データベースでの索引，
9-6
サプリメンタル・ロギング
一意キーの作成，4-6
データの REDO ログへの追加，4-9，4-10
プライマリ・データベース，4-9
ロジカル・スタンバイ・データベースで使用可能，
4-12
し
システム・リソース
効率的な使用，1-12
自動スイッチオーバー，7-2
「スイッチオーバー」も参照
自動フェイルオーバー，7-2
終了
ネットワーク接続，12-29
取得
欠落しているアーカイブ REDO ログ・ファイル，
1-4，1-12，5-40，10-26
順序
ロジカル・スタンバイ・データベースでサポートさ
れない，4-3
障害解決ポリシー
ログ転送サービスに関する指定，5-26
障害時リカバリ
Data Guard による実現，1-1
構成，1-3
スタンバイ・サイトの ReadMe ファイル，10-16
スタンバイ・データベースによる実現，1-3
メリット，1-12
使用可能
アーカイブ REDO ログ・ファイルの宛先，5-4
サプリメンタル・ロギング，4-10
リアルタイム適用
ロジカル・スタンバイ・データベース，9-14
ロジカル・スタンバイ・データベースにおけるデー
タベース・ガード，13-7
使用不能接続
トラブルシューティング，A-13
使用例
REDO ログでのタイム・ラグ，10-35
カスケードされた REDO ログ宛先，C-6 ～ C-10
リカバリ
NOLOGGING 指定後，10-40
ネットワーク障害の，10-39
ロジカル・スタンバイ・データベース，10-40
ロールの推移に最適なスタンバイ・データベースの
選択，10-14
初期化パラメータ
CONTROL_FILE_RECORD_KEEP_TIME，5-38
DB_FILE_NAME_CONVERT，D-6
DB_UNIQUE_NAME，A-9
FAL_CLIENT，5-42
FAL_SERVER，5-42
LOG_ARCHIVE_DEST，10-49
LOG_ARCHIVE_DEST_n，12-1 ～ 12-54
LOG_ARCHIVE_DEST_STATE_n，5-4
LOG_ARCHIVE_FORMAT，5-35
LOG_ARCHIVE_MIN_SUCCEED_DEST，12-24
LOG_ARCHIVE_TRACE，5-46，E-2，E-3
LOG_FILE_NAME_CONVERT，D-7
PARALLEL_MAX_SERVERS，4-14，9-29
SORT_AREA_SIZE，8-9
STANDBY_ARCHIVE_DEST，5-34
USER_DUMP_DEST，E-2
フィジカル・スタンバイ・データベース用に変更，
3-9
プライマリ・ロールおよびスタンバイ・ロールの
設定，12-49
初期化パラメータ・ファイル
サーバー・パラメータ・ファイルから作成
スタンバイ・データベース用，4-12
フィジカル・スタンバイ・データベース用，3-9
変更
フィジカル・スタンバイ・データベース用，3-9
す
スイッチオーバー，1-6
ORA-01102 による失敗，A-9
Real Application Clusters の使用と，7-8，B-9
REDO データを適用できない，A-9
SQL 文と，7-13
V$DATABASE ビューと，7-12，7-13
確認，7-13
カスケードされた REDO ログ構成，C-5
REDO Apply，C-5
SQL Apply，C-5
関与しないスタンバイ・データベース，7-14
最後のアーカイブ REDO ログ・ファイルが転送さ
れたかどうかの確認，A-5
最初からやり直し，A-10
妨げの原因
CJQ0 プロセス，A-7
DBSNMP プロセス，A-7
QMN0 プロセス，A-7
アクティブな SQL セッション，A-6
アクティブなユーザー・セッション，A-8
プロセス，A-7
手動と自動，7-2
準備，7-7
索引 -13
制御ファイルと，7-13
代表的な使用例，7-5
定義，1-6，7-2
非データ消失と，7-2
フィジカル・スタンバイ・データベースと，7-8，
7-12，7-14，10-14
プライマリ・データベースでの開始，7-13
リアルタイム適用が使用可能な，7-3
ロジカル・スタンバイ・データベースと，7-20，
10-14
スキーマ
SQL Apply でスキップ，4-3
スキップ対象を示す DBA_LOGSTDBY_SKIP
リスト，4-3
プライマリ・データベースと同一，1-2
ロジカル・スタンバイ・データベースでのデータ
操作，1-12
スキップ
ALTER TABLESPACE，9-9
スタンバイ REDO ログ・ファイル，10-36
スタンバイ REDO ログ・グループ
十分かどうかの判断，5-36
推奨数，5-29
メンバーの追加，5-37
スタンバイ REDO ログ・ファイル
RAW デバイス上，2-13
Real Application Clusters，5-30，B-5
インスタンス間アーカイブ，B-5
概要，2-13
作成，5-29，5-30
ログ・グループとメンバー，5-29
ネットワーク転送モード，5-16
要件
カスケードされたログ宛先，2-13
最大可用性モード，2-13
最大保護モード，2-13
保護モード，1-10
リアルタイム適用，2-13
リアルタイム適用，2-12，6-3
利点，2-13
スタンバイ・データベース
DB_FILE_NAME_CONVERT 初期化パラメータ，
D-6
LOG_FILE_NAME_CONVERT 初期化パラメータ，
D-7
OPEN RESETLOGS を使用したリカバリ，8-33，
9-24
索引 -14
Recovery Manager およびスタンバイ・インスタン
スの起動，D-10
Recovery Manager の準備，D-2
Recovery Manager を使用した作成について，D-3
Recovery Manager を使用したデータ・ファイルの
ネーミング，D-5
REDO データの適用，6-1
REDO ログ・ファイルの適用，1-5，1-12
RESETLOGS_ID の表示，8-40
SET AUXNAME コマンド，D-7
SET NEWNAME コマンド，D-6，D-7
カスケード，C-1
共有
フラッシュ・リカバリ領域，5-10
構成，1-2
Real Application Clusters，1-2，B-2，B-5
インスタンス間アーカイブ，5-3，B-5，B-6
オプションの宛先，5-36
最大数，2-1
シングル・インスタンス，1-2
遅延されたアーカイブ REDO ログ・ファイルの
適用，10-35
ネットワーク接続，12-30
必須の宛先，5-36
リモート位置，1-3
作成，1-2，3-1，4-1
Recovery Manager の使用，D-8
イメージ・コピーの使用，D-22
従来の初期化パラメータ・ファイル，4-12
タイム・ラグのある，6-5，10-36
タスクのチェックリスト，4-8
ディレクトリ構造の考慮点，2-9
プライマリが ASM または OMF を使用する
場合，10-51
リモート・ホスト上で異なるディレクトリ構造，
D-14
リモート・ホスト上で同一のディレクトリ構造，
D-12
ローカル・ホスト上，D-21
スタンバイ REDO ログ・ファイルのスキップ，
10-36
制御ファイルの作成
Recovery Manager の使用，D-4
制御ファイルの変更，8-15
待機イベントの構成，5-47
定義，2-2
動作要件，2-6，2-7
ハードウェア要件，2-6
フィジカル・スタンバイ・データベースでのログ適
用サービスの開始，6-7
「フィジカル・スタンバイ・データベース」も参照
フェイルオーバー，7-9
フェイルオーバー後に再作成，7-15
プライマリ・データベースとの再同期化，1-13
プライマリ・データベースへの復帰，A-10
ログ適用サービス，6-2
「ロジカル・スタンバイ・データベース」も参照
スタンバイ・ロール，1-2
せ
制御ファイル
ALTER DATABASE RENAME FILE 文で変更，8-15
コピー，3-13
サイズ拡大の計画，5-38
スイッチオーバーと，7-13
スタンバイ・データベース用に作成，3-9，4-15
フィジカル・スタンバイ・データベースでの影響，
8-19
変更，8-19
制御ファイルのレコードの再利用，5-38
制約
ロジカル・スタンバイ・データベースでの処理，
9-8
セキュアな REDO の転送，5-22
セキュアな REDO の転送に関する推奨事項，5-22
設定
VALID_FOR 属性
フィジカル・スタンバイ・データベース用，10-2
ロジカル・スタンバイ・データベース，10-5
データ保護モード，5-31
プライマリ・データベースとスタンバイ・データ
ベースのネットワーク・タイマー，12-30
そ
属性の互換性
LOG_ARCHIVE_DEST_n 初期化パラメータ，12-54
た
待機イベント，5-47
スタンバイ宛先，5-47
ログ転送モードのパフォーマンスの監視，5-47
タイム・ラグ
アーカイブ REDO ログ・ファイルの適用の遅延，
6-5，10-35，12-15
スタンバイ・データベースでの，6-5，10-36，12-15
ダイレクト・パス・ロード処理
フィジカル・スタンバイ・データベースと，8-19
ダウンストリーム取得データベース
Oracle Streams と Data Guard のログ転送サービス，
5-4
ち
チェックリスト
スタンバイ・データベース作成に関するタスク，
4-8
フィジカル・スタンバイ・データベース作成に関す
るタスク，3-8
遅延
REDO ログ・ファイルの適用，6-5
アーカイブ REDO ログ・ファイルの適用，10-35，
12-15
調整
スタンバイ REDO ログ・グループが十分かどうか
の判断，5-36
ロジカル・スタンバイ・データベース，9-26
つ
追加
一時ファイル，3-16，4-18
オンライン REDO ログ・ファイル，5-37，8-18
新規または既存のスタンバイ・データベース，1-7
スタンバイ REDO ログ・グループのメンバー，5-37
データ・ファイル，8-11，9-16，9-17
例，8-11
表領域，8-11
ロジカル・スタンバイ・データベースでの索引，
1-12，2-4，9-6
通信
Data Guard 構成のデータベース間，1-2
代替アーカイブ先
初期化パラメータの設定，A-4
索引 -15
て
停止
REDO Apply，6-8
SQL Apply，6-12
フィジカル・スタンバイ・データベース，8-3
フィジカル・スタンバイ・データベースでのリアル
タイム適用，6-8
リアルタイム適用
ロジカル・スタンバイ・データベース，6-12
停止時間ゼロのインスタンス化
ロジカル・スタンバイ・データベース，4-8
ディスク上のデータベース構造
フィジカル・スタンバイ・データベース，1-2
ディレクトリ位置
STANDBY_ARCHIVE_DEST 初期化パラメータで
指定，5-34
アーカイブ REDO ログ・ファイル，5-34
ディレクトリの場所
ASM を使用したセットアップ，2-8，2-9
OMF を使用したセットアップ，2-8，2-9
Optimal Flexible Architecture（OFA）
，2-9
スタンバイ・データベースの構造，2-9
データ型
SQL Apply でサポートされない表，4-3
サポートされないものを SQL Apply から除外，9-8
ロジカル・スタンバイ・データベース
サポートされない，4-3
サポートされる，4-2
データ可用性
システム・パフォーマンス要件とのバランス，1-12
データ消失
最小化，7-16
スイッチオーバーと，7-2
フェイルオーバーによる，1-6
データ消失なし
「非データ消失」を参照
データ破損
保護対策，1-12
データ・ファイル
プライマリ・データベースから削除，8-14
プライマリ・データベースでの改名，8-16
プライマリ・データベースへの追加，8-11
データベース
カスケード・スタンバイ・データベース，
「カス
ケードされた REDO ログ宛先」を参照
障害とデータ破損からの保護，1-1
索引 -16
ソフトウェア・バージョンのアップグレード，9-19
パスワード・ファイルの使用，5-22
フェイルオーバーと，7-9
プライマリ，
「プライマリ・データベース」を参照
ロールの推移と，7-2
データベース・インカネーション
OPEN RESETLOGS を使用した変更，8-33，9-24
データベース・スキーマ
フィジカル・スタンバイ・データベース，1-2
データベースのインカネーション
変更，8-33，9-24
データベースのロール
LOGSTDBY_ADMINISTRATOR，9-2
SELECT_CATALOG_ROLE，9-2
推移，7-2
スタンバイ，1-2，7-2
不可逆的な推移，1-6
プライマリ，1-2，7-2
ロール管理サービス，1-6
ロールの可逆的な推移，1-6
データベース・リンク
作成，7-26
データ保護
Data Guard による実現，1-1
柔軟性，1-12
パフォーマンスとのバランス，1-12
非データ消失の保証，2-3
メリット，1-12
データ保護モード
一連の最低要件，5-31
概要，1-9
最大可用性モード，5-32，13-5
最大パフォーマンス・モード，5-32，13-5
最大保護モード，5-32，13-5
指定，5-31
同期および非同期ネットワーク I/O 操作の設定，
12-42
ネットワーク接続への影響，12-30
ネットワーク・タイムアウトへの影響，12-30
ログ転送サービスによる施行，1-4
適用
REDO データの即時，6-3
SQL 文をロジカル・スタンバイ・データベースに，
6-12
スタンバイ・データベースへの REDO データ，1-4，
1-5，2-2，6-1
と
問合せ
スタンバイ・データベースでのオフロード，1-12
パフォーマンスの改善，1-12
動作要件，2-6，2-7
スタンバイ・データベース
オペレーティング・システム要件，2-6
動的パフォーマンス・ビュー，8-37
「ビュー」も参照
動的パラメータ
AQ_TM_PROCESSES，A-7
JOB_QUEUE_PROCESSES，A-7
登録
アーカイブ REDO ログ・ファイル，5-44，10-26
フェイルオーバー時，7-24
部分的なアーカイブ REDO ログ・ファイル，10-27
トラブルシューティング
listener.ora ファイル，10-39，A-3，A-12
SQL Apply，A-11
SQL Apply が停止した場合，A-11
tnsnames.ora ファイル，10-39，A-3，A-9，A-12
最後の REDO データが転送されていない，A-5
使用不能ネットワーク接続，A-13
スイッチオーバー，A-5
ORA-01102 メッセージ，A-9
アクティブな SQL セッション，A-6
アクティブなユーザー・セッション，A-8
成功したスイッチオーバーの後に REDO が適用
されていない，A-9
ロールバックおよび最初からやり直し，A-10
スイッチオーバーを妨げるプロセス，A-7
ロジカル・スタンバイ・データベース障害，A-5
トランスポータブル表領域
DB_FILE_NAME_CONVERT パラメータで位置を
定義，8-15
STANDBY_FILE_MANAGEMENT パラメータの
設定，8-15
フィジカル・スタンバイ・データベースでの使用，
8-15
トリガー
ロジカル・スタンバイ・データベースでの処理，
9-8
取消し
ログ適用サービス，8-6
トレース・ファイル
位置，E-2
設定，E-3
データのトレース・レベル，E-3
リアルタイム適用の追跡，E-4
に
認証
REDO データの送信，5-22
SYS 資格証明を使用したチェック，5-22
ね
ネットワーク I/O 操作
開始，12-44
切断の検出，12-30
タイムアウト・パラメータ値の調整，12-31
調整
ログ転送サービス，A-12
データ保護モードの影響，12-30
同期または非同期の設定，12-42
トラブルシューティング，A-13
ネットワーク・タイマー
EXPIRE_TIME パラメータ，12-30
NET_TIMEOUT 属性，12-29
プライマリ・データベースとスタンバイ・デー
タベースで同等に設定，12-30
不適切な障害，12-30，12-31
ネットワーク・タイムアウト
応答，12-30
は
バージョン
Oracle Database ソフトウェアのアップグレード，
9-19
ハードウェア
Data Guard 構成の要件，2-6
パスワード・ファイル
REMOTE_LOGIN_PASSWORDFILE 初期化パラ
メータの設定，5-22
要件，5-22
バックアップ操作
Recovery Manager の DUPLICATE コマンドの DB_
FILE_NAME_CONVERT オプション，D-6
Recovery Manager の使用，8-20
索引 -17
スタンバイ・データベースでのオフロード，1-12
データ・ファイル，10-42
フィジカル・スタンバイ・データベースの構成，
1-3
プライマリ・データベース，1-2，7-18
ブローカによる使用，1-7
リカバリ不能処理後，10-43
パフォーマンス
データ可用性とのバランス，1-12
データ保護とのバランス，1-12
ログ転送サービスの監視，5-47
パラレル実行処理
指定
DBMS_LOGSTDBY.APPLY_SET プロシージャの
MAX_SERVERS パラメータ，9-29
PARALLEL_MAX_SERVERS 初期化パラメータ，
4-12，4-13，4-14，6-18，9-29，11-6
フィジカル・スタンバイ・データベース，5-12
ログ適用レートのチューニング，6-18
ロジカル・スタンバイ・データベース，5-12
調整，9-29
パラレル・リカバリ
フィジカル・スタンバイ・データベース，6-9
判断
適用可能な最大の（最新の）SCN，10-23
適用された REDO ログ・データ，9-15
ひ
非データ消失
環境，5-17
最大可用性モードによる実現，1-9，5-27
最大保護モードによる実現，1-9，5-27
データ保護モードの概要，1-9
保証，1-6，2-3
メリット，1-12
非同期ネットワーク I/O 操作，12-42
ビュー，8-37，14-1
DBA_LOGSTDBY_EVENTS，9-11，14-2，A-11
DBA_LOGSTDBY_LOG，6-14，10-23，14-2
DBA_LOGSTDBY_NOT_UNIQUE，4-6，14-2
DBA_LOGSTDBY_PARAMETERS，14-2
DBA_LOGSTDBY_PROGRESS，6-15，9-15，14-2
DBA_LOGSTDBY_SKIP，14-2
DBA_LOGSTDBY_SKIP_TRANSACTION，14-2
DBA_LOGSTDBY_UNSUPPORTED，4-3，14-2
索引 -18
DBA_TABLESPACES，8-35
GV$INSTANCE，B-10
V$ARCHIVE_DEST，5-46，10-39，14-2，A-3
V$ARCHIVE_DEST_STATUS，5-45，6-9，14-2
V$ARCHIVE_GAP，14-2
V$ARCHIVED_LOG，5-35，5-45，6-9，10-47，
14-3
V$DATABASE，14-3
V$DATABASE_INCARNATION，14-3
V$DATAFILE，10-41，10-43，14-3
V$DATAGUARD_CONFIG，14-3
V$DATAGUARD_STATUS，6-10，14-3
V$LOG，5-45，14-3
V$LOG_HISTORY，6-10，8-41，14-3
V$LOGFILE，14-3
V$LOGSTDBY，9-13，14-3
V$LOGSTDBY_STATS，9-14，14-3
V$MANAGED_STANDBY，6-8，14-4
V$RECOVER_FILE，8-35，8-36
V$SESSION，A-6，A-8
V$STANDBY_LOG，5-31，14-4
V$THREAD，8-35
表
SQL Apply でサポートされないデータ型，4-3
表圧縮を使用，4-3
ロジカル・スタンバイ・データベース
行の識別，4-6
サポートされない，4-3
スキップ，9-8
追加，9-10
表の再作成，9-10
表領域
一時ファイルの作成および関連付け，8-7
使用しないソート，8-9
追加
新規データ・ファイル，9-17
プライマリ・データベースへの，8-11
データベース間の移動，8-15
プライマリ・データベースから削除，8-14
ふ
フィジカル・スタンバイ・データベース
DDL のサポート，2-3
DML のサポート，2-3
OPEN RESETLOGS を使用したリカバリ，8-33
REDO Apply，2-2
REDO のプライマリ・データベース・ブランチとの
再同期化，8-33，9-24
REDO ログ・ファイルの適用，1-5，6-2
開始，6-7
カスケード，C-1
VALID_FOR 属性の設定，10-2
オンライン・バックアップおよび，2-3
開始
ログ適用サービス，6-7
監視，6-8，8-10，14-1
構成オプション，2-9
遅延スタンバイ，6-5
作成
Data Guard Broker，1-7
一時表領域，8-8
従来の初期化パラメータ・ファイル，3-9
初期化パラメータ，3-9
タスクのチェックリスト，3-8
ディレクトリ構造，2-11
リスナーの構成，3-13
作成および一時表領域への一時ファイルの関連
付け，8-8
スイッチオーバー，7-12，10-14
ダイレクト・パス・ロード処理，8-19
定義，1-2
停止，8-3
トランスポータブル表領域の使用，8-15
フェイルオーバー，10-14
更新をチェック，7-11
準備，7-9
変更
オンライン REDO ログ・ファイル，8-18
制御ファイル，8-19
メリット，2-3
読取り専用，2-2，8-4
ロールの推移と，7-12
フェイルオーバー，1-6
REDO データの事前転送，7-9
カスケードされた REDO ログ構成，C-5
最小データ消失と，10-25
最小のパフォーマンス影響，10-25
最大パフォーマンス・モード，7-11
最大保護モード，7-11
手動と自動，7-2
準備，7-9
ターゲット・ロジカル・スタンバイ・データベース
の決定，10-22
定義，1-6，7-2
フィジカル・スタンバイ・データベースと，7-15，
10-14，13-6
フェイルオーバー後に再作成，7-15
リアルタイム適用が使用可能な，7-3
ロジカル・スタンバイ・データベースと，7-23，
10-14，10-22
不適切なネットワーク障害検出，12-30，12-31
部分的なアーカイブ REDO ログ・ファイル
登録，10-27
プライマリ・データベース
Real Application Clusters
設定，B-3，B-5
REDO ログ・アーカイブ情報の収集，5-45
アーカイブ・トレースの設定，5-46
ギャップの解決，1-13
構成
Real Application Clusters，1-2
インスタンス間アーカイブ，B-5
シングル・インスタンス，1-2
準備
フィジカル・スタンバイ・データベースの作成，
3-2
ロジカル・スタンバイ・データベースの作成，
4-2
初期化パラメータ
フィジカル・スタンバイ・データベース，3-9
スイッチオーバー，7-5
開始，7-13
定義，1-2
データ・ファイル
改名，8-14
追加，8-11
ネットワーク接続
終了，12-30
切断の検出，12-30
ネットワーク・タイムアウトの処理，12-30
ネットワーク停止の回避，12-29
バックアップと，7-18，8-20
表領域
削除，8-14
追加，8-11
フェイルオーバーと，7-2
フラッシュ・リカバリ領域の共有，5-10
索引 -19
ログ転送サービス，1-4
ワークロードの低減，1-12
プライマリ・ロール，1-2
フラッシュバック・データベース
Data Guard を補完する特性，1-11
OPEN RESETLOGS 後，10-32
フィジカル・スタンバイ・データベース，10-28
ロジカル・スタンバイ・データベース，10-31
フラッシュ・リカバリ領域
STANDBY_ARCHIVE_DEST=LOCATION パラ
メータ，5-10
設定，5-7
デフォルトの場所，5-7，5-8，12-22
複数のデータベース間で共有，5-10
ブローカ
グラフィカル・ユーザー・インタフェース，1-13
コマンドライン・インタフェース，1-13
定義，1-7
プロセス
CJQ0，A-7
DBSNMP，A-7
QMN0，A-7
アーカイバ（ARCn）
，5-11
「管理リカバリ・プロセス（MRP）」も参照
スイッチオーバーの妨げ，A-7
ログ・ライター（LGWR）
，5-16
へ
変更
宛先属性，12-2
グローバル名
ロジカル・スタンバイ・データベース，4-17
制御ファイル，8-19
フィジカル・スタンバイ・データベース用の初期化
パラメータ，3-9
ロジカル・スタンバイ・データベース，9-6
ロジカル・スタンバイ・データベース名，4-16
ロジカル・スタンバイ・データベース用の初期化パ
ラメータ，4-14
ほ
補完テクノロジ，1-10
保護モード
最大可用性モード，1-9，5-27
最大パフォーマンス・モード，1-9，5-28
索引 -20
最大保護モード，1-9，5-27
「データ保護モード」を参照
本番データベース
「プライマリ・データベース」を参照
ま
マテリアライズド・ビュー
カスケードされた REDO ログ宛先，C-4
ロジカル・スタンバイ・データベースでの作成，
1-12，2-4，C-8
ロジカル・スタンバイ・データベースでのリフレッ
シュ，9-19
マテリアライズド・ビューのリフレッシュ，9-19
む
無効化
アーカイブ REDO ログ・ファイルの宛先，5-4
データベース・リンクを定義するためのデータベー
ス・ガードの，7-26
め
メディア・リカバリ
パラレル，6-18
メリット
Data Guard，1-12
スタンバイ REDO ログおよびアーカイブ REDO
ログ，2-13
フィジカル・スタンバイ・データベース，2-3
ロジカル・スタンバイ・データベース，2-4
ゆ
ユーザー・セッション
スイッチオーバー障害の原因となる，A-8
ユーザーのミス
保護対策，1-12
優先
適用遅延間隔，6-6
よ
れ
要件
データ保護モード，5-31
読取り専用操作，1-5
定義，2-2
フィジカル・スタンバイ・データベースと，8-4
ロジカル・スタンバイ・データベース，1-12
レポート生成操作
構成，1-3
スタンバイ・データベースでのオフロード，1-12
ロジカル・スタンバイ・データベースでの実行，
1-3
り
リアルタイム適用
LOG_ARCHIVE_TRACE 初期化パラメータによる
データの追跡，E-4
RFS プロセス，6-2
SQL Apply，9-14
V$ARCHIVE_DEST_STATUS での進捗の監視，6-9
開始，6-8
ロジカル・スタンバイ上での，6-12
スタンバイ REDO ログ・ファイルの使用，2-12
スタンバイ REDO ログ・ファイルの必要性，2-13
定義，6-2，6-3
停止
フィジカル・スタンバイ・データベース上での，
8-3
ロジカル・スタンバイ上での，6-12
ロールの推移，7-3
ログ適用サービスの概要，1-4
ロジカル・スタンバイ・データベース上での開始，
9-14
リカバリ
NOLOGGING 句指定後，10-40
エラーの，9-16
フィジカル・スタンバイ・データベース
OPEN RESETLOGS の後，8-33，9-24
リセットログの使用，8-33，9-24
リカバリ不能処理，10-41
直後のバックアップ，10-43
リスト
アーカイブ REDO ログ・ファイル，10-23
リモート・ファイル・サーバー・プロセス（RFS）
スタンバイ REDO ログ・ファイルの再利用，5-36
定義，2-12，5-18，6-2
ログ・ライター・プロセス，6-3，12-12
ろ
ロール管理サービス
定義，1-6，7-1
ロールの推移，7-2
VALID_FOR 属性が指定されたロールベースのロー
ルの推移の定義，7-10
可逆的な，1-6，7-2
カスケードされた REDO ログ構成，C-5
タイプの選択，7-3
フィジカル・スタンバイ・データベースと，7-12
リアルタイム適用，7-3
ロジカル・スタンバイ・データベースと，7-20
ロールの不可逆的な推移，1-6
ロールバック
スイッチオーバー障害後の，A-10
ロールベースの宛先
設定，12-49
ログ適用サービス
REDO Apply
開始，6-7，8-2
監視，6-8，8-38
定義，6-2
停止，6-8，8-3
ログ適用レートのチューニング，6-18
REDO データの適用遅延，6-5，10-35，12-15
SQL Apply
DBMS_LOGSTDBY パッケージを使用した管理，
9-3
開始，4-15，6-12
監視，6-13，9-12
定義，1-5，6-2，6-3
停止，6-12
定義，1-5，6-2
リアルタイム適用
LOG_ARCHIVE_TRACE による監視，E-4
V$ARCHIVE_DEST_STATUS ビューで監視，6-9
スタンバイ REDO ログ・ファイル，2-12
索引 -21
定義，6-2，6-3
ロールの推移，7-3
ロールの推移，A-9
ログ転送サービス，5-2 ～ 5-46
アーカイブ REDO ログ・ファイル
V$ARCHIVED_LOG ビューでリストを表示，
5-35
ディレクトリ位置の指定，5-34
ファイル名の生成，5-35
アーカイブ先
LOG_ARCHIVE_DEST_n 初期化パラメータで
指定，5-6
Oracle Change Data Capture，5-4
Oracle Streams，5-3
インスタンス間，5-3
共有，5-39，12-17
失敗した宛先への再アーカイブ，5-26
代替，A-4
ロール固有，5-23
割当て制限，B-8
アーカイブ障害の処理，5-26
監視，5-45，5-47
スタンバイ REDO ログ・ファイル
構成，5-29
セキュアな REDO の転送，5-22
定義，1-4，5-2
ネットワーク
ASYNC ネットワーク転送，5-17
SYNC ネットワーク転送，5-17
調整，A-12
保護モード
最大可用性モード，1-9，5-27
最大パフォーマンス・モード，1-9，5-28
最大保護モード，1-9，5-27
設定，5-31
選択，5-27
非データ消失の実現，5-17
ログ・ライタープロセス（LGWR）
ASYNC ネットワーク転送，5-17
定義，5-16
ローカルのアーカイブ，5-5
ログ・ライター・プロセス（LGWR）
ASYNC ネットワーク転送，12-42
NET_TIMEOUT 属性
LOG_ARCHIVE_DEST_n 初期化パラメータ，
12-30
索引 -22
SYNC ネットワーク転送，12-42
ネットワーク・タイムアウト後の再接続，12-30
ロジカル・スタンバイ・データベース
OPEN RESETLOGS を使用したリカバリ，9-24
Oracle Database ソフトウェアのアップグレード，
9-19
REDO データの適用，6-12
REDO ログ・ファイルの適用
DBMS_LOGSTDBY.APPLY_SET プロシージャ，
6-6
SQL Apply テクノロジ，1-5，6-2
サポートされないオブジェクト，4-3
サポートされるデータ型，4-2
遅延，6-6
SQL Apply テクノロジ，6-3，1-5
SQL 文の実行，1-3
VALID_FOR 属性の設定，10-5
開始
SQL Apply，4-15，6-12
リアルタイム適用，6-12，9-14
カスケード，C-1，C-4
監視，9-11，14-1
SQL Apply，6-13
管理，9-1 ～ 9-29
グローバル名の変更，4-17
作成
Data Guard Broker，1-7
初期化パラメータの変更，4-14
サポートされない
順序，4-3
データ型，4-3
表，4-3
サポートされるデータ型，4-2
システム・パフォーマンスのチューニング，9-26
自動的にスキップされる DDL 文，4-4
障害の処理，A-5
使用可能
サプリメンタル・ロギング，4-12
使用例
リカバリ，10-40
スイッチオーバー，7-20，10-14
スキップ
SQL 文，4-4，9-8
表，9-8
追加
索引，1-12，2-4，9-6
データ・ファイル，9-16
表，9-10
定義，1-3
停止
SQL Apply，6-12
停止時間ゼロのインスタンス化，4-8
データベース表に対するユーザー・アクセスの
制御，9-4
問合せおよびレポート生成目的でのアクセス，1-3
バックグラウンド・プロセス，4-21，9-13
パラレル実行処理，9-29
表の一意識別，4-6
フェイルオーバー，7-23，10-14
ターゲット，10-22
マテリアライズド・ビュー
作成，1-12，2-4，C-4，C-8
サポート，4-4
リフレッシュ，9-19
メリット，1-12，2-4
読取り専用操作，1-12
ロジカル・スタンバイ・プロセス（LSP）と，4-21，
9-13
ロジカル・スタンバイ・データベースのイベントの
記録，9-11
ロジカル・スタンバイ・プロセス（LSP）
ARCn アーカイブ・プロセス，5-13，5-14
COORDINATOR プロセス，4-21，9-13
LGWR SYNC アーカイブ・プロセス，5-18
論理的な破損
解決，1-12
索引 -23
索引 -24