Oracle® Data Guard

Broker

12cリリース1 (12.1)

B71305-08(原本部品番号:E48241-09)

2017年7月

Oracle Data Guard Broker, 12cリリース1 (12.1)

B71305-08

Copyright © 1999, 2017, Oracle and/or its affiliates.  All rights reserved.

原本著者: Kathy Rich

原本協力者:  Larry Carpenter、Laurence Clarke、Jeff Detjen、Mahesh Girkar、Michael Harvey、Nitin Karkhanis、Sadhana Kyathappala、Chang Kyu Lee、Steve Lee、Jiangbin Luo、Bob McGuirk、Joe Meeks、Darryl Presley、Ashish Ray、Lawrence To、Di Yang、Zaixian Xie

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

Oracle Data Guard Brokerのこのリリースにおける変更

- Oracle Database 12cリリース1 (12.1.0.2)での変更点

- 新機能

- その他の変更

- Oracle Database 12cリリース1 (12.1.0.1)での変更点

- 新機能

- 非推奨となった機能

- サポート対象外機能

- その他の変更

1 Oracle Data Guard Brokerの概要

- 1.1 Oracle Data Guardおよびブローカの概要

- 1.1.1 Oracle Data Guard構成およびブローカ構成

- 1.1.2 Oracle Data Guard Broker

- 1.1.3 Oracle Data Guard BrokerおよびCDB

- 1.1.4 Oracle Data Guard Brokerとコンテナ・データベース

- 1.2 Oracle Data Guard Brokerの利点

- 1.3 Oracle Data Guard Brokerのコンポーネント

- 1.4 Oracle Data Guard Brokerのユーザー・インタフェース

- 1.4.1 Oracle Enterprise Manager Cloud Control

- 1.4.2 Oracle Data Guardコマンドライン・インタフェース(DGMGRL)

- 1.5 Oracle Data Guardモニター

- 1.5.1 Oracle Data Guardモニター(DMON)プロセス

- 1.5.2 構成管理

- 1.5.3 データベース・プロパティ管理

2 Oracle Data Guardのインストール

- 2.1 Oracle Data Guardのインストール

- 2.2 前提条件

3 ブローカ構成の管理

- 3.1 構成のサポート

- 3.2 構成プロパティ

- 3.3 ブローカ構成ファイルの設定

- 3.3.1 ブローカ構成ファイルの名前の変更

- 3.3.2 Oracle RAC環境でのブローカ構成ファイルの管理

- 3.3.2.1 構成ファイルに対するクラスタ・ファイル・システム(CFS)の使用

- 3.3.2.2 構成ファイルに対するOracle ASMディスク・グループの使用

- 3.4 Data Guard Brokerの起動

- 3.5 ブローカ構成の管理サイクル

- 3.6 操作の有効化と無効化

- 3.7 構成ステータス

4 ブローカ構成のメンバーの管理

- 4.1 ブローカ構成メンバーの管理

- 4.2 ブローカ構成メンバーの状態管理

- 4.2.1 データベースの状態遷移

- 4.3 データベース・プロパティの管理

- 4.3.1 監視可能な(読取り専用)プロパティ

- 4.3.2 構成可能(変更可能)なプロパティ

- 4.3.2.1 ブローカの構成可能なプロパティのデフォルト値へのリセット

- 4.4 REDO転送サービスの管理

- 4.4.1 REDO転送の設定

- 4.4.2 データ保護モードに対応したREDO転送サービスの管理

- 4.4.3 高度なREDO転送設定

- 4.4.4 REDO転送サービスのオン/オフの切替え

- 4.4.5 アーカイブREDOログ・ファイルの位置の指定

- 4.4.6 その他のREDO転送設定

- 4.4.7 Oracle RACデータベース環境でのREDO転送サービス

- 4.4.8 転送ラグ

- 4.5 ログ適用サービスの管理

- 4.5.1 遅延適用の管理

- 4.5.2 REDO Applyでのパラレル適用の管理

- 4.5.3 SQL Applyに対するリソースの割当て

- 4.5.4 DBA_LOGSTDBY_EVENTS表の管理

- 4.5.5 Oracle RACデータベース環境での適用サービス

- 4.5.5.1 適用インスタンスの選択

- 4.5.5.2 適用インスタンスのフェイルオーバー

- 4.5.6 適用ラグ

- 4.6 データ保護モードの管理

- 4.6.1 構成に対する保護モードの設定

- 4.6.1.1 保護モードの設定(タスク1): 使用するデータ保護モードの決定

- 4.6.1.2 保護モードの設定(タスク2): スタンバイREDOログ・ファイルの設定

- 4.6.1.3 保護モードの設定(タスク3): REDO転送モードの設定

- 4.6.1.4 保護モードの設定(タスク4): DGMGRLまたはCloud Controlの使用

- 4.6.2 保護モードによるブローカ操作への影響

- 4.6.2.1 現在の保護モードのアップグレードまたはダウングレード

- 4.6.2.2 スイッチオーバー操作

- 4.6.2.3 フェイルオーバー操作

- 4.6.2.4 無効化操作と有効化操作

- 4.6.2.5 構成からデータベースを削除する際の要件

- 4.6.2.6 その他の操作要件

- 4.7 遠隔同期インスタンスの管理

- 4.8 ファスト・スタート・フェイルオーバーの管理

- 4.8.1 ファスト・スタート・フェイルオーバーをチューニングするプロパティの構成

- 4.8.2 ファスト・スタート・フェイルオーバーの条件の構成

- 4.8.3 アプリケーションによるファスト・スタート・フェイルオーバーの開始

- 4.9 データベース変換の管理

- 4.10 データベースのステータス

- 4.10.1 データベース・ステータスの問合せ

- 4.10.2 ロール変更前のデータベース検証

5 スイッチオーバー操作とフェイルオーバー操作

- 5.1 ブローカ環境でのスイッチオーバーおよびフェイルオーバーの概要

- 5.2 ターゲット・スタンバイ・データベースの選択

- 5.2.1 スイッチオーバーでのターゲット・スタンバイ・データベースの選択

- 5.2.2 フェイルオーバーでのターゲット・スタンバイ・データベースの選択

- 5.3 スイッチオーバー

- 5.3.1 スイッチオーバー操作実行前の考慮事項

- 5.3.2 スイッチオーバーの開始

- 5.3.3 ブローカによるスイッチオーバーの実行方法

- 5.4 手動フェイルオーバー

- 5.4.1 完全手動フェイルオーバーおよび即時手動フェイルオーバー

- 5.4.2 手動フェイルオーバー操作の実行

- 5.4.2.1 手動フェイルオーバーの実行(タスク1): 使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースの決定

- 5.4.2.2 手動フェイルオーバーの実行(タスク2): フェイルオーバーの開始

- 5.4.2.3 手動フェイルオーバーの実行(タスク3): 保護モードのリセット

- 5.4.2.4 手動フェイルオーバーの実行(タスク4): 障害時リカバリ構成の再確立

- 5.4.2.5 ブローカによる完全フェイルオーバー操作の実行方法

- 5.4.2.6 ブローカによる即時フェイルオーバー操作の実行方法

- 5.4.3 ロール変更後の無効化されたデータベースの再有効化

- 5.4.3.1 データベースの回復方法

- 5.4.3.2 無効化されたデータベースの再作成および再有効化の方法

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

- 5.5.1 ファスト・スタート・フェイルオーバーを有効化するための前提条件

- 5.5.2 ファスト・スタート・フェイルオーバーの有効化

- 5.5.2.1 ファスト・スタート・フェイルオーバーの有効化(タスク1): 使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースの決定

- 5.5.2.2 ファスト・スタート・フェイルオーバーの有効化(タスク2): FastStartFailoverTarget構成プロパティを使用したターゲット・スタンバイ・データベースの指定

- 5.5.2.3 ファスト・スタート・フェイルオーバーの有効化(タスク3): 使用する保護モードの決定

- 5.5.2.4 ファスト・スタート・フェイルオーバーの有効化(タスク4): FastStartFailoverThreshold構成プロパティの設定

- 5.5.2.5 ファスト・スタート・フェイルオーバーの有効化(タスク5): ファスト・スタート・フェイルオーバー関連の他のプロパティの設定(省略可能)

- 5.5.2.6 ファスト・スタート・フェイルオーバーの有効化(タスク6): 追加のファスト・スタート・フェイルオーバー条件の有効化(省略可能)

- 5.5.2.7 ファスト・スタート・フェイルオーバーの有効化(タスク7): DGMGRLまたはCloud Controlの使用

- 5.5.2.8 ファスト・スタート・フェイルオーバーの有効化(タスク8): オブザーバの起動

- 5.5.2.9 ファスト・スタート・フェイルオーバーの有効化(タスク9): ファスト・スタート・フェイルオーバー環境の検証

- 5.5.2.10 ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行

- 5.5.2.11 ファスト・スタート・フェイルオーバーが有効化されている場合の制限事項

- 5.5.2.12 ファスト・スタート・フェイルオーバーが有効化されている場合のプライマリ・データベースの停止

- 5.5.2.13 ファスト・スタート・フェイルオーバーが有効化されている場合の手動によるロール変更の実行

- 5.5.3 アプリケーションによるファスト・スタート・フェイルオーバーの指示

- 5.5.4 ファスト・スタート・フェイルオーバー構成の統計およびステータスの表示

- 5.5.4.1 V$DATABASEビュー

- 5.5.4.2 V$FS_FAILOVER_STATSビュー

- 5.5.5 ファスト・スタート・フェイルオーバーの無効化

- 5.5.6 ファスト・スタート・フェイルオーバーのパフォーマンスに関する考慮事項

- 5.5.7 オブザーバの管理

- 5.5.7.1 オブザーバのインストールおよび起動

- 5.5.7.2 オブザーバに関する情報の表示

- 5.5.7.3 オブザーバに障害が発生した場合の動作

- 5.5.7.4 オブザーバのプライマリへの接続の管理

- 5.5.7.5 オブザーバの停止

- 5.5.7.6 オブザーバの別のコンピュータへの移動

- 5.5.7.7 オブザーバによるファスト・スタート・フェイルオーバー構成情報のメンテナンス方法

- 5.5.7.8 オブザーバが実行中でファスト・スタート・フェイルオーバーが有効化されている場合の環境へのパッチ適用

- 5.5.8 ブローカ構成に含まれる元のプライマリ・データベースの回復

- 5.5.8.1 要件

- 5.5.8.2 回復に関する制限事項

- 5.5.8.3 失敗した回復のブローカによる処理方法

- 5.5.9 ファスト・スタート・フェイルオーバー環境でのデータベースの停止

- 5.6 データベース・クライアントに関する考慮事項

- 5.6.1 Oracle Data Guard固有のFANおよびFCF構成要件

- 5.6.1.1 Oracle Netの構成要件

- 5.6.1.2 データベース・サービスの構成要件

- 5.6.1.3 ONSの構成要件

- 5.6.1.4 アプリケーション・コンティニュイティ

6 DGMGRLコマンドライン・インタフェースの使用例

- 6.1 初期使用の前提条件

- 6.2 使用例1: 構成の作成

- 6.2.1 構成の作成(タスク1): DGMGRLの起動

- 6.2.2 構成の作成(タスク2): プライマリ・データベースへの接続

- 6.2.3 構成の作成(タスク3): 既存のリモートREDO転送先のクリア

- 6.2.4 構成の作成(タスク4): ブローカ構成の作成

- 6.2.5 構成の作成(タスク5): 構成情報の表示

- 6.2.6 構成の作成(タスク6): 構成へのスタンバイ・データベースの追加

- 6.3 使用例2: データベース・プロパティの設定

- 6.4 使用例3: 構成とデータベースの有効化

- 6.5 使用例4: 構成保護モードの設定

- 6.6 使用例5: 遠隔同期インスタンスでの「最大可用性」モードの設定

- 6.7 使用例6: ファスト・スタート・フェイルオーバーの有効化とオブザーバの起動

- 6.8 使用例7: 遠隔同期インスタンスが使用中の場合のファスト・スタート・フェイルオーバーの有効化

- 6.9 使用例8: 定期的な管理タスクの実施

- 6.9.1 プロパティと状態の変更

- 6.9.1.1 データベース・プロパティの変更

- 6.9.1.2 デフォルト値へのプロパティのリセット

- 6.9.1.3 スタンバイ・データベースの状態変更

- 6.9.1.4 プライマリ・データベースの状態変更

- 6.9.2 構成とデータベースの無効化

- 6.9.2.1 構成の無効化

- 6.9.2.2 スタンバイ・データベースの無効化

- 6.9.2.3 遠隔同期インスタンスの無効化

- 6.9.3 構成、スタンバイ・データベースまたは遠隔同期インスタンスの削除

- 6.9.3.1 構成からのスタンバイ・データベースの削除

- 6.9.3.2 構成からの遠隔同期インスタンスの削除

- 6.9.3.3 ブローカ構成の削除

- 6.10 使用例9: スイッチオーバー操作の実行

- 6.10.1 SWITCHOVERコマンドの使用(タスク1): プライマリ・データベースのチェック

- 6.10.2 SWITCHOVERコマンドの使用(タスク2): スイッチオーバーのターゲットとなるスタンバイ・データベースのチェック

- 6.10.3 SWITCHOVERコマンドの使用(タスク3): データベースのロール変更可能確認

- 6.10.4 SWITCHOVERコマンドの使用(タスク4): スイッチオーバー・コマンドの発行

- 6.10.5 SWITCHOVERコマンドの使用(タスク5): 構成の表示

- 6.11 使用例10: 手動フェイルオーバー操作の実行

- 6.12 使用例11: 障害が発生したプライマリ・データベースの回復

- 6.13 使用例12: フィジカル・スタンバイからスナップショット・スタンバイへの変換

- 6.14 使用例13: Data Guard構成の監視

- 6.14.1 構成の監視(タスク1): 構成のステータス・チェック

- 6.14.2 構成の監視(タスク2): データベースのステータス・チェック

- 6.14.3 構成の監視(タスク3): 監視可能なプロパティLogXptStatusのチェック

- 6.14.4 構成の監視(タスク4): 監視可能なプロパティInconsistentPropertiesのチェック

- 6.14.5 構成の監視(タスク5): 監視可能なプロパティInconsistentLogXptPropsのチェック

7 Oracle Data Guardコマンドライン・インタフェース・リファレンス

- 7.1 Data Guardコマンドライン・インタフェースの起動

- 7.1.1 DGMGRLのオプション・パラメータ

- 7.1.2 DGMGRLコマンドの書式とパラメータ

- 7.1.3 DGMGRLコマンドの使用上の注意

- 7.2 Data Guardコマンドライン・インタフェースの終了

- 7.3 ADD DATABASE

- 7.4 ADD FAR_SYNC

- 7.5 CONNECT

- 7.6 CONVERT DATABASE

- 7.7 CREATE CONFIGURATION

- 7.8 DISABLE CONFIGURATION

- 7.9 DISABLE DATABASE

- 7.10 DISABLE FAR_SYNC

- 7.11 DISABLE FAST_START FAILOVER

- 7.12 DISABLE FAST_START FAILOVER CONDITION

- 7.13 EDIT CONFIGURATION (プロパティ)

- 7.14 EDIT CONFIGURATION (保護モード)

- 7.15 EDIT CONFIGURATION (RENAME)

- 7.16 EDIT CONFIGURATION RESET (プロパティ)

- 7.17 EDIT DATABASE (プロパティ)

- 7.18 EDIT DATABASE (名前の変更)

- 7.19 EDIT DATABASE(状態)

- 7.20 EDIT DATABASE RESET (プロパティ)

- 7.21 EDIT FAR_SYNC

- 7.22 EDIT FAR_SYNC RESET (プロパティ)

- 7.23 EDIT INSTANCE(AUTO PFILE)

- 7.24 EDIT INSTANCE (プロパティ)

- 7.25 EDIT INSTANCE RESET (プロパティ)

- 7.26 ENABLE CONFIGURATION

- 7.27 ENABLE DATABASE

- 7.28 ENABLE FAR_SYNC

- 7.29 ENABLE FAST_START FAILOVER

- 7.30 ENABLE FAST_START FAILOVER CONDITION

- 7.31 EXIT

- 7.32 FAILOVER

- 7.33 HELP

- 7.34 QUIT

- 7.35 REINSTATE DATABASE

- 7.36 REMOVE CONFIGURATION

- 7.37 REMOVE DATABASE

- 7.38 REMOVE FAR_SYNC

- 7.39 REMOVE INSTANCE

- 7.40 SHOW CONFIGURATION

- 7.41 SHOW CONFIGURATION WHEN PRIMARY IS

- 7.42 SHOW DATABASE

- 7.43 SHOW FAR_SYNC

- 7.44 SHOW FAST_START FAILOVER

- 7.45 SHOW INSTANCE

- 7.46 SHUTDOWN

- 7.47 SQL

- 7.48 START OBSERVER

- 7.49 STARTUP

- 7.50 STOP OBSERVER

- 7.51 SWITCHOVER

- 7.52 VALIDATE DATABASE

- 7.53 VALIDATE FAR_SYNC

8 Oracle Data Guard Brokerのプロパティ

- 8.1 構成プロパティ

- 8.1.1 BystandersFollowRoleChange

- 8.1.2 CommunicationTimeout

- 8.1.3 ExternalDestination1

- 8.1.4 ExternalDestination2

- 8.1.5 FastStartFailoverAutoReinstate

- 8.1.6 FastStartFailoverLagLimit

- 8.1.7 FastStartFailoverPmyShutdown

- 8.1.8 FastStartFailoverThreshold

- 8.1.9 ObserverOverride

- 8.1.10 ObserverReconnect

- 8.1.11 OperationTimeout

- 8.1.12 PrimaryLostWriteAction

- 8.1.13 TraceLevel

- 8.2 監視可能な(読取り専用)プロパティ

- 8.2.1 InconsistentLogXptProps(非一貫性REDO転送プロパティ)

- 8.2.2 InconsistentProperties (非一貫性プロパティ)

- 8.2.3 LogXptStatus(REDO転送ステータス)

- 8.2.4 LsbyFailedTxnInfo(ロジカル・スタンバイ障害トランザクション情報)

- 8.2.5 LsbyParameters(ロジカル・スタンバイ・パラメータ)

- 8.2.6 RecvQEntries(受信キュー・エントリ)

- 8.2.7 SendQEntries(送信キュー・エントリ)

- 8.2.8 TopWaitEvents

- 8.3 構成可能なプロパティ

- 8.3.1 AlternateLocation

- 8.3.2 ApplyInstanceTimeout

- 8.3.3 ApplyLagThreshold

- 8.3.4 ApplyParallel

- 8.3.5 ArchiveLagTarget

- 8.3.6 バインド

- 8.3.7 DbFileNameConvert

- 8.3.8 DelayMins

- 8.3.9 DGConnectIdentifier

- 8.3.10 FastStartFailoverTarget

- 8.3.11 LogArchiveFormat

- 8.3.12 LogArchiveMaxProcesses

- 8.3.13 LogArchiveMinSucceedDest

- 8.3.14 LogArchiveTrace

- 8.3.15 LogFileNameConvert

- 8.3.16 LogShipping

- 8.3.17 LogXptMode

- 8.3.18 LsbyMaxEventsRecorded

- 8.3.19 LsbyMaxServers

- 8.3.20 LsbyMaxSga

- 8.3.21 LsbyPreserveCommitOrder

- 8.3.22 LsbyRecordAppliedDdl

- 8.3.23 LsbyRecordSkipDdl

- 8.3.24 LsbyRecordSkipErrors

- 8.3.25 MaxConnections

- 8.3.26 MaxFailure

- 8.3.27 NetTimeout

- 8.3.28 ObserverConnectIdentifier

- 8.3.29 PreferredApplyInstance

- 8.3.30 RedoCompression

- 8.3.31 RedoRoutes

- 8.3.31.1 REDOルーティング・ルール

- 8.3.32 ReopenSecs

- 8.3.33 SidName

- 8.3.34 StandbyArchiveLocation

- 8.3.35 StandbyFileManagement

- 8.3.36 StaticConnectIdentifier

- 8.3.37 TransportDisconnectedThreshold

- 8.3.38 TransportLagThreshold

9 Oracle Data Guardのトラブルシューティング

- 9.1 診断情報のソース

- 9.2 一般的な問題と解決策

- 9.2.1 ORA-16596: データベースがOracle Data Guard Broker構成に含まれていない

- 9.2.2 プライマリ・データベースに累積されたREDOが一部のスタンバイ・データベースに送信されない場合

- 9.2.3 スタンバイ・データベース上で多数のログ・ファイルが受信されるが適用されない場合

- 9.2.4 要求がタイムアウトしたか、Cloud Controlのパフォーマンスが低い場合

- 9.2.5 プライマリ・データベースがフラッシュバックされる場合

- 9.2.6 不明なサービスのためにスタンバイが自動開始できない場合(ORA-12514)

- 9.3 スイッチオーバー操作時の問題のトラブルシューティング

- 9.4 フェイルオーバー操作時の問題のトラブルシューティング

- 9.4.1 フィジカル・スタンバイ・データベースへのフェイルオーバーの失敗

- 9.4.1.1 ブローカの完全フィジカル・フェイルオーバーの失敗

- 9.4.1.2 ブローカの即時フィジカル・フェイルオーバーの失敗

- 9.4.2 ロジカル・スタンバイ・データベースへのフェイルオーバーの失敗

- 9.5 オブザーバに関する問題のトラブルシューティング

- 9.5.1 オブザーバの起動に関する問題

- 9.5.2 オブザーバが停止したことによる問題

- 9.5.3 オブザーバ・ログ・ファイルでのオブザーバの処理の取得

A Oracle Data Guard Brokerのアップグレードとダウングレード

- A.1 Oracle Database 9i リリース2 (9.2)からOracle Database 12c リリース1 12.1へのアップグレード

- A.2 Oracle Database 10gおよびOracle Database 11gからOracle Database 12c リリース1 (12.1)へのアップグレード

- A.3 Oracle Database 12c リリース1 (12.1)へのダウングレード

- A.4 ローリング・アップグレード時のブローカ構成の維持

用語集

索引

表一覧

- 1-1 ブローカがある場合とない場合の構成管理

- 4-1 データベースの状態と説明

- 4-2 Oracle Data Guard保護モードと要件

- 5-1 V$DATABASEビューのFS_FAILOVER_STATUS列

- 5-2 V$DATABASEビューのFS_FAILOVER_OBSERVER_PRESENT列

- 7-1 DGMGRLコマンドの要約

- 7-2 健全性条件の例

- 8-1 構成可能なプロパティ

はじめに

このドキュメントでは、Oracle Data Guard Brokerの構成、構成の監視および制御に使用する管理および監視インタフェースであるOracle Data Guard Brokerの詳細を説明します。

対象読者

『Oracle Data Guard Broker』は、Oracle Data Guardの構成および構成の監視に関連する多くの作業を自動化するためにOracle Data Guard Brokerを使用するデータベース管理者(DBA)およびシステム管理者を対象としています。

このマニュアルでは、Oracle Data Guard、Oracle Enterprise Manager Cloud Control (Cloud Control)、Oracle Real Application Clusters (Oracle RAC)、およびOracle Net Servicesにより提供されるネットワーク・サービスに関する知識を持つ読者を対象にしています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWeb サイト(Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

Oracle Data Guardの詳細は、次のOracleドキュメントを参照してください。

- 『Oracle Data Guard概要および管理』。

- オペレーティング・システム固有のOracleリリース・ノート。

- オペレーティング・システム固有のOracleインストレーション・ガイド。

- Cloud Controlのグラフィカル・ユーザー・インタフェース(GUI)を使用したOracle Data Guardの管理の詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

Oracle Data Guard Brokerのこのリリースにおける変更

この「はじめに」では、Oracle Data Guard Brokerの変更点を列挙します。

Oracle Database 12cリリース1 (12.1.0.2)での変更点

Oracle Database12 cリリース1 (12.1.0.2)のOracle Data Guard Brokerでの変更点を次に示します。

新機能

このリリースの新機能は次のとおりです。

- ExternalDestination1およびExternalDestination2構成プロパティにより、現在のプライマリ・データベースからREDOデータを受信できるREDO転送先を設定できます。「ExternalDestination1」および「ExternalDestination2」を参照してください。(これらのプロパティは、Oracle Database 12cリリース1 (12.1.0.2)以上で使用可能です。また、Oracle Database 11gリリース2 (11.2.0.4)でも使用できますが、Oracle Database 12cリリース1 (12.1.0.1)では使用できません。)

- PrimaryLostWriteAction構成プロパティは、プライマリ・データベースでの書込み欠落発生をスタンバイ・データベースで検出した場合の動作を決定します。「PrimaryLostWriteAction」を参照してください。(このプロパティは、Oracle Database 12cリリース1 (12.1.0.2)以上で使用可能です。また、Oracle Database 11gリリース2 (11.2.0.4)でも使用できますが、Oracle Database 12cリリース1 (12.1.0.1)では使用できません。)

- 新しいV$FS_OBSERVER_HISTOGRAMビューで示される情報を使用すると、FastStartFailoverThreshold構成プロパティに対する適切な値の判断に役立ちます。「FastStartFailoverThreshold」を参照してください。(このビューは、Oracle Database 12cリリース1 (12.1.0.2)以上で使用可能です。また、Oracle Database 11gリリース2 (11.2.0.4)でも使用できますが、Oracle Database 12cリリース1 (12.1.0.1)では使用できません。)

- RedoRoutesプロパティを使用して、最初の宛先に障害が発生した場合にREDOデータを送信する代替宛先を指定できるようになりました。これを行う方法の例については、「高度なREDO転送設定」を参照してください。

- 新しいSHOW CONFIGURATION WHEN PRIMARY ISコマンドによって、指定したデータベースがプライマリ・データベースであった場合に有効になるREDO転送構成が表示されます。「SHOW CONFIGURATION WHEN PRIMARY IS」を参照してください。

- 新しいVALIDATE FAR_SYNCコマンドによって、遠隔同期インスタンスを検証するための包括的な一連のチェックが実行されます。オプションのWHEN PRIMARY句を使用すると、プライマリ・データベースである別のデータベースに基づいて遠隔同期インスタンスを検証できます。「VALIDATE FAR_SYNC」を参照してください。

- Oracle Database 12cリリース1 (12.1.0.2)で、Data Guardブローカ構成はExternalDestination1およびExternalDestination2構成プロパティを使用して、現在のプライマリ・データベースからZero Data Loss Recovery Appliance (リカバリ・アプライアンス)へのREDO転送をサポートします。
リカバリ・アプライアンスは、すべてのOracleデータベースのバックアップに対して単一のリポジトリを提供するエンタプライズレベルのバックアップ・ソリューションです。

「ExternalDestination1」および「ExternalDestination2」を参照してください。(これらのプロパティは、Oracle Database 12cリリース1 (12.1.0.2)以上で使用可能です。また、Oracle Database 11gリリース2 (11.2.0.4)でも使用できますが、Oracle Database 12cリリース1 (12.1.0.1)では使用できません。

その他の変更

今回のリリースでのその他の変更は次のとおりです。

- 1つのOracle Data Guard Broker構成に、最大253のメンバー(1つのプライマリ・データベースと、プライマリ・データベースからREDOを直接受信するスタンバイ・データベースと遠隔同期インスタンスの組合せを含む)を含めることができるようになりました。

- 静的サービスの定義および登録が必要なのは、Oracle ClusterwareもOracle Restartも使用していない場合のみになりました。

- Oracle Data Guardのフィジカル・スタンバイ・データベースへのスイッチオーバーに対し、アプリケーション・コンティニュイティがサポートされています。最大可用性のデータ保護モードの場合、フィジカル・スタンバイへのファスト・スタート・フェイルオーバーもサポートされます。プライマリ・データベースとスタンバイ・データベースには、Oracle RACまたはOracle Active Data Guardのライセンスを付与して、アプリケーション・コンティニュイティを使用できるようにする必要があります。「アプリケーション・コンティニュイティ」を参照してください。

- 次のプロパティは使用できなくなりました。

- LsbyASkipCfgPr

- LsbyASkipErrorCfgPr

- LsbyAskipTxnCfgPr

- LsbyDskipCfgPr

- LsbyDSkipErrorCfgPr

- LsbyDSkipTxnCfgPr

- LsbySkipTable

- LsbySkipTxnTable

Oracle Database 12cリリース1 (12.1.0.1)での変更点

Oracle Database12 cリリース1 (12.1.0.2)のOracle Data Guard Brokerでの変更点を次に示します。

新機能

このリリースの新機能は次のとおりです。

- Oracle Data Guard Brokerは、ブローカ構成内のマルチテナント・コンテナ・データベース(CDB)をサポートします。
「Oracle Data Guard BrokerおよびCDB」を参照してください。

- DGMGRLを使用してデータベースに接続する際に、新しいOracle Data Guard SYSDG管理権限をサポートします。
「CONNECT」を参照してください。

- 新しいDGMGRLコマンドVALIDATE DATABASEを使用すると、データベースがロール変更を実行する準備ができているかどうか、短時間で簡単に判定できます。
「VALIDATE DATABASE」を参照してください。

- 新しいDGMGRLコマンドを使用すると、Oracle Data Guard構成に遠隔同期インスタンスを追加して、管理できます。
ブローカ構成の遠隔同期インスタンスの管理に関連するコマンドの詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」を参照してください。

- 新しい構成可能なプロパティRedoRoutesは、REDOカスケーディングと遠隔同期インスタンスをサポートします。
「RedoRoutes」を参照してください。

- 新しいEDIT CONFIGURATION (RENAME)コマンドを使用して、Oracle Data Guard Broker構成の名前を変更できます。異なる名前を使用する構成を削除して作成しなおす必要がなくなりました。
「EDIT CONFIGURATION (RENAME)」を参照してください。

- Oracle Data Guard Brokerのプロパティを簡単にデフォルト値に簡単にリセットできるようになりました。これは、構成、データベースまたはインスタンスのレベルで可能です。
「ブローカの構成可能なプロパティのデフォルト値へのリセット」を参照してください。

- 新しい高性能のREDO転送モードFASTSYNCにより、最大可用性データ保護モードをサポートします。
REDO転送モードの設定に関する情報は、「LogXptMode」を参照してください。

- ローリング・アップグレード時にOracle Data Guard Broker構成を維持できるため、アップグレードの完了後にリビルドする必要がありません。

- SQL文やPL/SQLストアド・プロシージャをData Guardコマンドライン・インタフェース(DGMGRL)から実行できるようになったため、定型業務のためにコマンドライン・インタフェースを何回も終了しては再起動する必要がなくなりました。
「SQL」を参照してください。

- Oracle Data Guardブローカは、Oracle Database 12cリリース1 (12.1)の新しいOracle Global Data Services(GDS)機能をサポートしています。
「Oracle Data Guard BrokerとOracle Global Data Services」を参照してください。

参照:

- GDSの詳細は、『Oracle Database Global Data Services概要および管理ガイド』を参照してください。

- ファスト・スタート・フェイルオーバー・ターゲット・スタンバイ・データベースからDBMS_DG PL/SQLプロシージャをコールできるようになりました。
「アプリケーションによるファスト・スタート・フェイルオーバーの指示」を参照してください。

- 障害後にスイッチオーバーを再開できるようになりました。
「スイッチオーバー操作時の問題のトラブルシューティング」を参照してください。

- 構成内のすべてのデータベースに対してブローカによって実行されるトレースの量を制御できるようになりました。
「TraceLevel」構成プロパティを参照してください。

- 新しいObserverReconnect構成プロパティを使用すると、オブザーバがプライマリおよびスタンバイの各データベースから切断し、再接続する間隔を指定できます。
「ObserverReconnect」プロパティを参照してください。

- 新しいObserverOverride構成プロパティを使用すると、スタンバイのプライマリとの接続状態が良好なときでも、オブザーバがプライマリとの接続を失ったら自動フェイルオーバーを開始するかどうかを指定できます。
「ObserverOverride」構成プロパティを参照してください。

- 新しい構成可能なプロパティApplyLagThresholdを使用すると、フィジカルおよびロジカル・スタンバイ上の適用ラグに最大値を設定できます。上限を超過すると警告が発行されます。
「ApplyLagThreshold」プロパティを参照してください。

- 新しい構成可能なプロパティTransportDisconnectedThresholdを使用すると、プライマリとの通信がないまま経過できる時間の長さに上限を設定できます。上限を超過すると警告が発行されます。
「TransportDisconnectedThreshold」プロパティを参照してください。

- 構成可能なプロパティTransportLagThresholdを使用すると、データベースの転送ラグに上限を設定できます。上限を超過すると警告が発行されます。
「TransportLagThreshold」プロパティを参照してください。

非推奨となった機能

次の機能はこのリリースでは非推奨となりました。将来のリリースではされなくなる可能性があります。

- 次の構成可能なプロパティは非推奨となりました。

- LsbyASkipCfgPr

- LsbyASkipErrorCfgPr

- LsbyAskipTxnCfgPr

- LsbyDskipCfgPr

- LsbyDSkipErrorCfgPr

- LsbyDSkipTxnCfgPr

- 次の監視可能なプロパティは非推奨となりました。

- LsbySkipTable

- LsbySkipTxnTable

サポート対象外機能

このドキュメントで以前に記述されていた機能の一部は、Oracle Database12cリリース1(12.1)ではサポートされません。サポートされなくなった機能の一覧は、『Oracle Databaseアップグレード・ガイド』を参照してください。

その他の変更

今回のリリースでのその他の変更は次のとおりです。

- ブローカ構成のプライマリ・データベースにリモートREDO転送先がある場合、ブローカ構成を作成することができません。ただし、それらのリモートREDO転送先がNOREGISTER属性を持っている場合を除きます。
プライマリ・データベースに、NOREGISTER属性がないリモートREDO転送先がある場合、それらをクリアしないと先に進めません。ブローカ構成が作成された後で、リモートREDO転送先を構成することができます。

1 Oracle Data Guard Brokerの概要

次のトピックでは、Oracle Data Guard Broker、そのアーキテクチャとコンポーネント、およびOracle Data Guard構成の作成、制御および監視の自動化の方法について説明します。

- Oracle Data Guardおよびブローカの概要

- Oracle Data Guard Brokerの利点

- Oracle Data Guard Brokerのコンポーネント

- Oracle Data Guard Brokerのユーザー・インタフェース

- Oracle Data Guardモニター

Oracle Data Guard構成の定義およびOracle Data Guardの概念と用語の詳細は、『Oracle Data Guard概要および管理』を参照してください。

1.1 Oracle Data Guardおよびブローカの概要

Oracle Data Guardは、企業データの高可用性、データ保護および障害時リカバリを保証します。Oracle Data Guardでは、1つ以上のスタンバイ・データベースを作成、維持、管理および監視する包括的なサービスのセットが用意されており、本番のOracleデータベースを障害やデータ破損からリカバリできます。Oracle Data Guardでは、これらのスタンバイ・データベースが、トランザクション的に一貫性のあるプライマリ・データベースのコピーとして維持されます。計画的または計画外の障害によりプライマリ・データベースが使用できなくなると、Oracle Data Guardは任意のスタンバイ・データベースを本番ロールに切り替えることができるため、障害に関連する停止時間が最短に抑えられます。Oracle Data Guardは、従来のバックアップ、リカバリおよびクラスタ・テクニック、フラッシュバック・データベース機能と併用でき、高水準のデータ保護およびデータ可用性を提供します。

Oracle Data GuardとOracle RAC One Node

Oracle Database 11gリリース2(11.2.0.2)では、Oracle Data GuardとOracle Data Guard BrokerがOracle Real Application Clusters One Node (Oracle RAC One Node)と完全に統合されました。

1.1.1 Oracle Data Guard構成およびブローカ構成

Oracle Data Guard構成は、1つのプライマリ・データベースと、プライマリ・データベースからREDOを直接受信する、スタンバイ・データベースと遠隔同期インスタンスの組合せによって構成されます。Oracle Data Guard構成内のデータベースはOracle Netで接続され、地理的に散在していてもかまいません。相互の通信が可能であれば、データベースの位置に制限はありません。たとえば、スタンバイ・データベースの1つをプライマリ・データベースと同じシステムに置き、別のシステムに2つのスタンバイ・データベースを置くこともできます。

Oracle Data Guard Brokerでは、これらのプライマリ・データベースとスタンバイ・データベースを統合ユニットとしてまとめて管理および監視できるようにブローカ構成として論理的にグループ化されます。ブローカ構成の管理には、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用する方法と、Oracle Data Guardコマンドライン・インタフェースを使用する方法があります。

1.1.2 『Oracle Data Guard Broker』

Oracle Data Guard Brokerは、Oracle Data Guard構成の作成、メンテナンスおよび監視を自動化および集中化する分散管理フレームワークです。次のリストは、ブローカによって自動化および簡素化される操作を示しています。

- 1つのプライマリ・データベース、新規または既存のスタンバイ(フィジカル、ロジカル、スナップショットおよび遠隔同期)、REDO転送サービスおよびログ適用サービスを含む、Oracle Data Guard構成の作成。スタンバイは、Oracle Real Application Clusters (Oracle RAC)データベースにすることができます。

- 追加の新規または既存のスタンバイ(フィジカル、ロジカル、スナップショット、遠隔同期、Oracle RACまたは非Oracle RAC)の、既存のOracle Data Guard構成への追加。

- ブローカ構成の保護モードの管理。

- 単一のコマンドによるスイッチオーバーまたはフェイルオーバーの起動と、構成内のすべてのデータベースにわたる複雑なロール変更の開始および制御。

- プライマリ・データベースの消失時に自動的に実行するフェイルオーバーの構成。手動操作なしで可用性が高まります。

- 構成全体のステータスの監視、診断情報の取得、REDO適用率やREDO生成率などの統計のレポート、および集中化された監視、テストやパフォーマンス・ツールを使用した迅速な問題検出。

- データベースがプライマリになる準備状況の評価。(「VALIDATE DATABASE」を参照してください)。

ブローカの使いやすいインタフェースである、Cloud Control内のOracle Data Guard管理ページ、およびDGMGRLと呼ばれるOracle Data Guardコマンドライン・インタフェースを使用すると、すべての管理操作をローカルまたはリモートで実行できます。

これらのインタフェースにより、Oracle Data Guard構成の構成および管理が簡素化されます。表1-1に、ブローカのインタフェースを使用する場合とSQL*Plusを使用する場合の構成管理の比較を示します。

表1-1 ブローカがある場合とない場合の構成管理

操作

ブローカがある場合

ブローカがない場合

全般

プライマリ・データベース、スタンバイ・データベースおよび遠隔同期インスタンスの管理を、単一の統一構成として提供します。

プライマリ・データベース、スタンバイ・データベースと遠隔同期インスタンスを別々に管理する必要があります。

スタンバイ・データベースの作成

Cloud Controlのウィザードによって、スタンバイ制御ファイル、オンラインREDOログ・ファイル、データファイルおよびサーバー・パラメータ・ファイルの作成を含む、各サイトでOracleデータベースによる構成を作成するために必要な手順が自動化および簡素化されます。

次の操作を手動で行う必要があります(RMANまたは他のツールを使用して)。

- データベース・ファイルをスタンバイ・データベース・システムにコピーします。

- スタンバイ・データベース・システム上で制御ファイルを作成します。

- スタンバイ・データベース・システム上でサーバー・パラメータ・ファイルまたは初期化パラメータ・ファイルを作成します。

- プライマリ・データベース・パスワード・ファイルをスタンバイ・データベース・システムにコピーします。
注意: ブローカを使用している場合でも、すべてのフィジカルおよびスナップショット・スタンバイ・データベースで、プライマリ・データベースからの現行のパスワード・ファイルのコピーを使用していることを確認する必要があります。管理権限(SYSDG、SYSOPER、SYSDBAなど)が付与または解除された場合、および管理権限を持つユーザーのパスワードが変更された場合は、コピーをリフレッシュする必要があります。

構成と管理

単一の場所から複数データベースの構成と管理を行うことができ、ブローカ構成内のすべてのデータベースが自動的に統一されます。

次の目的のために、複数の場所に手動で接続する必要があります。

- 構成に含まれる各データベースでREDO転送サービスおよびログ適用サービスを設定します。

- プライマリ・データベースとスタンバイ・データベースを個別に管理します。

制御

- REDO転送サービスおよびログ適用サービスが自動的に設定されます。これらのサービスの管理が(特にOracle RAC環境で)簡素化されます。

- スイッチオーバー、フェイルオーバー、回復、およびスナップショット・スタンバイ・データベースとの変換を単一のコマンドで起動できるため、これらの操作が簡素化されます。

- ブローカによってフェイルオーバーの必要性を判断し、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーを開始できることにより、フェイルオーバーが自動化されます。DBAによる操作は不要であり、消失データなしでフェイルオーバーする場合と、構成可能なデータ量を消失する場合があります。

- ロール変更がOracle Clusterwareと統合されます。

- Cloud Controlによって管理および監視できます。

- Oracle Global Data Servicesと統合して、ロール固有のグローバル・サービスをサポートします。

次の操作を手動で行う必要があります。

- 複数のSQL文を使用してデータベースを管理します。

- 複数データベース・サイト間で複数のコマンドの順序を調整し、スイッチオーバーおよびフェイルオーバー操作を実行します。

- 複数のコマンドの順序を調整して、ロール遷移中にサービスおよびインスタンスを管理します。

監視

- 構成の健全性、データベースの健全性および他のランタイム・パラメータが継続的に監視されます。

- 統一された更新済ステータス・レポートおよび詳細レポートが提供されます。

- Cloud Controlイベントに統合されます。

次の操作を手動で行う必要があります。

- 各データベースで固定ビューを使用してステータスおよびランタイム・パラメータを監視します。構成に含まれるすべてのデータベースに関して統一されたステータス・ビューはありません。

- Cloud Controlイベント監視用に独自の方法を用意します。

1.1.3 Oracle Data Guard BrokerおよびCDB

Oracle Data Guard Brokerは、ブローカ構成内のマルチテナント・コンテナ・データベース(CDB)をサポートします。次のことに注意してください。

- プライマリ・データベースがCDBの場合、ブローカ構成のすべてのスタンバイ・データベースもCDBである必要があります。

- ブローカ構成がCDBで構成されている場合、ブローカ・アクションはすべてルート・レベルにあります。個々のプラガブル・データベース(PDB)のレベルではありません。

- マルチテナント環境を管理するには、CDB_DBAロールを持っている必要があります。

- ロール変更の後で、ブローカは新しいプライマリのすべてのアクティブ・インスタンスを開きます。スナップショット・スタンバイとロジカル・スタンバイのすべてのアクティブ・インスタンスおよびフィジカル・スタンバイの最初のインスタンス(元のフィジカル・スタンバイが読取り可能の場合)も開かれます。

参照:

- CDBの詳細は、『Oracle Database概要』を参照してください。

- CDBとPDBにある権限とロールの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

1.1.4 Oracle Data Guard BrokerとOracle Global Data Services

Oracle Global Data Services (GDS)をサポートするブローカ構成を管理するには、ブローカのコマンドライン・インタフェース(DGMGRL)とGDSコマンドライン・インタフェース(GDSCTL)を使用します。ブローカ構成は、GDSプール(複数のGDSリージョンにまたがるGDSデータベースの論理的なグルーピング)に追加されます。

GDSプールでのブローカ構成の管理

GDSプールにブローカ構成を追加するには、GDSコマンドライン・インタフェース(GDSCTL)を使用します。ブローカ構成は、空のプールにのみ追加できます。ブローカ構成は複数のプールにまたがることができません。

プールにあるブローカ構成を削除するには、先にGDSCTL REMOVE BROKERCONFIG ...コマンドを使用してブローカ構成をプールから削除する必要があります。一致しない場合は、エラーが戻ります。

GDSCTLを使用して追加および削除できるのは全体のブローカ構成だけです。ブローカ構成に対して、個々のデータベースを追加および削除するには、ブローカのコマンドライン・インタフェース、DGMGRLを使用します。

個々の構成データベースがGDSプールの一部である場合の管理

GDSプールにすでにブローカ構成が含まれている場合、プールに追加できるのは、その構成に属するデータベースだけです。プール内のブローカ構成に対して個々のデータベースを追加または削除する唯一の方法は、ブローカのコマンドライン・インタフェース、DGMGRLを使用することです。

ブローカ構成に追加されたデータベースは、構成が属するGDSプールにも自動的に追加されます。

ブローカ構成から削除されたデータベースは、構成が属するGDSプールから自動的に削除されます。

ブローカはGDSと相互に作用してロールや構成の変更を通知し、適切なデータベース・サービスがアクティブになり、ロール変更後に適切なFANイベントが発行されるようにします。

参照:

- GDSの詳細は、『Oracle Database Global Data Services概要および管理ガイド』を参照してください。

1.2 Oracle Data Guard Brokerの利点

ブローカのインタフェースによって利便性が向上し、Oracle Data Guard構成の管理と監視が集中化されます。ブローカはOracle DatabaseのEnterprise EditionおよびPersonal Editionの機能として選択可能で、OracleデータベースおよびCloud Controlとも統合されます。これらのブローカ属性には次のようなメリットがあります。

障害時の保護:

ブローカを使用すると、Oracle Data Guard構成の構成と監視に必要な手動による作業の多くが自動化され、Oracle Data Guard本来の高可用性、データ保護および障害時保護機能が強化されます。Oracle Data Guard構成内のどのシステムのクライアントからでもアクセスが可能であるため、単一の障害箇所は排除されます。プライマリ・データベースに障害が発生すると、ブローカはプロセスを自動化し、いずれかのスタンバイ・データベースがプライマリ・データベースにかわって本番処理を引き継ぎます。Oracle Data Guardが提供するデータベースの可用性により、データの保護が容易になります。

Oracle Real Application Clusters (Oracle RAC)データベースでの高可用性とスケーラビリティ:

Oracle Data Guard Brokerでは、プライマリ・データベースの一貫したコピーをトランザクションごとに維持することで障害時保護が強化されますが、Oracle Real Application Clusters (RAC)データベースのようなOracleの高可用性ソリューションとともにOracle Data Guardを構成すると、そのデータベースの特定のコピーの可用性およびスケーラビリティがさらに拡張されます。Oracle RACデータベースのサイト内の高可用性により、Oracle Data Guard Brokerが提供するサイト間の保護が補完されます。

クラスタ・システムでプライマリOracle RACデータベースが管理されており、そのデータベースへのアクセスを複数のインスタンスが共有している場合を考えてみます。ここで、計画外の障害が発生したとします。Oracle Data Guard Brokerの観点からは、クラスタ化データベースの1つ以上のインスタンスが引き続きスタンバイ・データベースにREDOデータを転送可能であるかぎり、プライマリ・データベースは使用可能であるとみなされます。Oracle Clusterwareは、Oracle RACデータベースのインスタンスの可用性を管理します。プライマリ・データベースを使用可能な状態に保つために、障害が発生したインスタンスを迅速にリカバリしようとします。障害が発生したインスタンスをOracle Clusterwareがリカバリできない場合、ブローカは自動的に1つ少なくなったインスタンスで引き続き動作します。プライマリ・データベースの最後のインスタンスに障害が発生すると、ブローカは指定されたスタンバイ・データベースにフェイルオーバーする手段を提供します。プライマリ・データベースの最後のインスタンスに障害が発生し、ファスト・スタート・フェイルオーバーが有効化されている場合は、事前決定済のスタンバイ・データベースへのフェイルオーバーが自動的に実行され、継続的な高可用性を提供できます。

ブローカはOracle Clusterwareと統合されているため、データベース・ロールの変更はスムーズかつシームレスに実行されます。このことが特に明らかなのは、計画的なロール・スイッチオーバーの場合です(元のプライマリ・データベースがスタンバイのロールを引き継いでいる間に、フィジカル・スタンバイ・データベースがプライマリ・ロールを引き継ぐように指示される場合など)。ブローカとOracle Clusterwareは連動してプライマリ・データベースでのサービスの可用性を一時的に停止し、Oracle Clusterwareがブローカで動作し元のプライマリ・データベースで必要に応じてインスタンスを正常に再起動する間に、両方のデータベースについて実際のロール変更を行ってから、定義されたサービスを新規プライマリ・データベースで開始します。ブローカは基礎となるOracle Data Guard構成とそのデータベース・ロールを管理しますが、Oracle Clusterwareはロールに依存するサービスの可用性を管理します。サービスの可用性の管理をOracle Clusterwareに依存するアプリケーションでは、Oracle Data Guard構成内でロール変更が発生した場合に、サービスが一時停止していることのみ確認されます。

Oracle Clusterwareによって各Oracle RACデータベース・インスタンスの可用性が維持されることに加え、ブローカは地理的に離れた複数の場所で発生する処理を整理して1つ以上のフィジカルまたはロジカル・データベースのコピーを維持することで、障害時保護を提供します。また、ブローカとOracle Clusterwareは、Oracleの高可用性アーキテクチャに強力な基盤を提供します。

参照:

Oracle Clusterwareの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

Oracle RAC One Nodeのサポート:

Oracle Database 11gリリース2(11.2.0.2)では、Oracle Data GuardとOracle Data Guard BrokerがOracle Real Application Clusters One Node (Oracle RAC One Node)と完全に統合されました。このサポートによってOracle RAC構成について説明されたOracle Clusterwareの多数の利点を生かすことができ、ローカル・サイトでより高いレベルの可用性が実現されます。

Oracle Data Guard構成の自動作成。

ブローカにより、Oracle Data Guard構成を論理的に定義および作成できます。Oracle Data Guard構成内のメンバー間での通信は、Oracle Net Servicesを使用して自動的に実行されます。メンバーは、LANで接続されたローカルのメンバーでも、WANを介して接続された地理的に散在するリモートのメンバーでもかまいません。

Cloud Controlには、次のようなブローカ構成の作成に伴う複雑なタスクを自動化するウィザードが付属しています。

- 既存のスタンバイ・データベースの追加、またはCloud Controlを通じて取得された既存のバックアップからの新規スタンバイ・データベースの作成

- スタンバイ制御ファイル、サーバー・パラメータ・ファイルおよびデータファイルの構成

- スタンバイとの通信の初期化

- スタンバイREDOログ・ファイルの作成

- ファスト・スタート・フェイルオーバーを使用する場合のフラッシュバック・データベースの有効化

DGMGRLでは新規スタンバイを自動的に作成できませんが、DGMGRLコマンドを使用して、既存のスタンバイ(Cloud Controlを使用して作成されたスタンバイを含む)を構成および監視できます。

追加のスタンバイの構成が容易:

Oracle Data Guard構成を作成した後で、各Oracle Data Guard構成に新規または既存のスタンバイを追加できます。Cloud Controlのスタンバイ・データベースの追加ウィザードを使用すると、指示に従って、さらにデータベースを追加できます。

管理の簡素化、集中化および拡張:

コマンドを発行して、ブローカ構成の多くの側面を管理できます。次のような操作が可能です。

- プライマリ・データベース、スタンバイ、REDO転送サービスおよびログ適用サービスなど、構成内のすべてのコンポーネントの管理を簡素化できます。

- データベースの状態遷移を調整し、データベース・プロパティを動的に更新できます。このときブローカは、構成内の全データベースの情報を含むブローカ構成ファイルに変更を記録します。さらに、変更を構成内の全データベースとそのサーバー・パラメータ・ファイルに伝播します。

- 構成保護モード(最大保護、最大可用性または最大パフォーマンス)の制御を簡素化できます。

- Cloud Controlの検証操作を起動して、REDO転送サービスとログ適用サービスが正しく構成され、機能していることを確認します。

スイッチオーバー操作とフェイルオーバー操作の簡略化:

ブローカでは、Cloud Controlでキーを1回クリックするか、DGMGRLコマンドライン・インタフェースで単一のコマンドを使用してスイッチオーバーおよびフェイルオーバーを起動できるため(このマニュアルでは手動フェイルオーバーと呼びます)、これらの操作が簡素化されます。完全自動管理の場合、ファスト・スタート・フェイルオーバーを有効にすると、ブローカによるフェイルオーバーの必要性の判断と、事前に指定されたターゲット・スタンバイへのフェイルオーバーの自動開始が可能になり、DBAによる操作は不要です。ファスト・スタート・フェイルオーバーの構成により、消失データなしでフェイルオーバーする場合と、構成可能なデータ量を消失する場合があります。

ファスト・スタート・フェイルオーバーにより、手動操作の必要性を少なくして可用性を高め、管理コストを削減できます。手動フェイルオーバーでは、フェイルオーバーを実行する正確なタイミングおよび対象となるターゲット・スタンバイを管理できます。選択する方法に関係なく、ブローカによって構成内のすべてのデータベースのロール遷移が調整されます。フェイルオーバーが完了すると、ブローカが高速アプリケーション通知(FAN)イベントを発行して新しいプライマリが使用可能であることをアプリケーションに通知します。

DBMS_DG PL/SQLパッケージを使用すると、特定の条件が満たされたときにアプリケーションによるファスト・スタート・フェイルオーバーの開始が可能になります。詳細は、「アプリケーションによるファスト・スタート・フェイルオーバーの開始」を参照してください。

構成内の全データベースにわたるスイッチオーバー操作またはフェイルオーバー操作に関する複雑なロール変更の開始に必要なコマンドは、1つのみです。ブローカにより、ブローカ構成内の指定スタンバイ・データベースへのスイッチオーバーとフェイルオーバーが自動化されます。Cloud Controlを使用すると、実行可能な(有効化され、実行されているNORMALステータスの)スタンバイ・データベースのセットから、新しいプライマリ・データベースを選択できます。DGMGRLのSWITCHOVERコマンドとFAILOVERコマンドでは、ターゲット・スタンバイ・データベースを指定するだけで、構成内の複数のデータベースにわたるスイッチオーバー操作またはフェイルオーバー操作における多数の手順が自動的に開始および完了します。

組込みの監視、アラートおよび制御メカニズム:

ブローカには、構成内のすべてのデータベースの健全性を監視する組込みの検証機能があります。構成内の任意のデータベースに接続している間、診断情報を取得し、集中化された監視、テストおよびパフォーマンスの各ツールを使用して、明白な問題と潜在的な問題を迅速に検出できます。Cloud ControlとDGMGRLの両方で、プライマリ・データベースにおけるREDO転送サービスの進行状況と、スタンバイ・データベースにおけるREDO ApplyまたはSQL Applyの進行状況の詳細な構成ビューを取得できます。

ブローカの健全性チェック・メカニズムおよびCloud Controlのイベント管理システムとの緊密な統合により、ローカルとリモートのデータベースを監視し、イベントに応答する機能も大幅に強化されています。

アプリケーションに対する透過性:

ブローカはアプリケーションと透過的に動作するため、あらゆるデータベースで使用できます。ブローカで管理する構成にあわせたアプリケーション・コードの変更は不要です。

1.3 Oracle Data Guard Brokerのコンポーネント

Oracle Data Guard Brokerは、次のコンポーネントで構成されています。

- Oracle Enterprise Manager Cloud Control

- Oracle Data Guardコマンドライン・インタフェース(DGMGRL)

- Oracle Data Guardモニター

Cloud ControlおよびOracle Data Guardコマンドライン・インタフェース(DGMGRL)は、プライマリ・データベースとスタンバイ・データベースの集合からなる構成を定義および管理できるようにするブローカのクライアント・インタフェースです。DGMGRLには、ファスト・スタート・フェイルオーバーを容易にするプロセスである、オブザーバを作成するコマンドも含まれます。「Oracle Data Guard Brokerのユーザー・インタフェース」で、これらのインタフェースについてより詳しく説明します。

Oracle Data Guardモニターはブローカのサーバー側コンポーネントで、Oracleデータベースと統合されています。Oracle Data Guardモニターは、DMONプロセスなどのいくつかのプロセスとブローカ構成ファイルで構成されており、構成のデータベースの制御、実行時の動作の変更、構成全体の健全性の監視、およびその他の操作特性に関する通知の提供などを実行できます。「Oracle Data Guardモニター」で、Oracle Data Guardモニターについてより詳しく説明します。

図1-1に、ブローカのこれらのコンポーネントを示します。

図1-1 Oracle Data Guard Broker

1.4 Oracle Data Guard Brokerのユーザー・インタフェース

ブローカのいずれかのユーザー・インタフェースを使用してブローカ構成を作成し、構成を制御および監視できます。次の各項では、ブローカのユーザー・インタフェースについて説明します。

- Oracle Enterprise Manager Cloud Control

- Oracle Data Guardコマンドライン・インタフェース(DGMGRL)

1.4.1 Oracle Enterprise Manager Cloud Control

Oracle Enterprise Manager Cloud Control (Cloud Control)は、Oracle Data Guardモニターと連動して、Oracle Data Guard構成の管理を自動化および簡素化します。

Cloud Controlを使用すると、スタンバイ・データベースの作成と管理に関する複雑な操作が、次のようなOracle Data Guard管理ページおよびウィザードによって簡素化されます。

- スタンバイ・データベースの追加ウィザード。プライマリ・データベースとローカルまたはリモートのスタンバイ・データベースで構成されるブローカ構成が存在しない場合に、このウィザードを使用して新規に作成できます。このウィザードでは、フィジカル、スナップショットまたはロジカル・スタンバイ・データベースを作成したり、既存のフィジカル、スナップショットまたはロジカル(Oracle RACまたは非Oracle RAC)スタンバイ・データベースをインポートできます。フィジカル、スナップショットまたはロジカル・スタンバイ・データベースを作成すると、スタンバイ制御ファイル、サーバー・パラメータ・ファイル、オンラインREDOログ・ファイル、スタンバイREDOログ・ファイルおよびスタンバイ・データファイルも自動的に作成されます。

- スイッチオーバー操作。プライマリ・データベースとスタンバイ・データベース間でロールを切り替えることができます。

- フェイルオーバー操作。スタンバイ・データベースの1つがプライマリ・データベースのロールに変更されます。

- パフォーマンス・ツールとグラフ。REDO転送サービスとログ適用サービスの監視とチューニングに役立ちます。

- プロパティ・ページ。このページを使用すると、任意のデータベースに対してデータベース・プロパティを設定できます。可能な場合、この設定は、構成内の他のすべてのデータベースおよびサーバー・パラメータ・ファイルにただちに伝播されます。

- 電子メールを介したイベントのレポート。

さらに、REDO転送サービスおよびログ適用サービスのサポートに必要なOracle Net Servicesのすべての構成変更を行います。

参照:

Oracle Data Guardのすべての機能をOracle Databaseの各リリースで管理するために必要なCloud Controlのバージョンの詳細は、http://support.oracle.comにあるMy Oracle Supportノート787461.1を参照してください

1.4.2 Oracle Data Guardコマンドライン・インタフェース(DGMGRL)

Oracle Data Guard コマンドライン・インタフェース(DGMGRL)では、Oracle Data Guard構成をDGMGRLプロンプトまたはスクリプト内から制御および監視できます。構成内のデータベースの管理と監視に必要なアクティビティのほとんどは、DGMGRLコマンドを使用して実行できます。

DGMGRLには、プライマリ・データベースおよびターゲット・スタンバイ・データベースを継続的に監視し、フェイルオーバーの必要性を評価して、条件を満たしたときにファスト・スタート・フェイルオーバーを開始するオブザーバ・プロセスを作成するコマンドも含まれます。

参照:

Oracle Data Guardコマンドライン・インタフェースの参照情報の詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」を参照してください。表7-1にDGMGRLコマンドの概要を示します。

1.5 Oracle Data Guardモニター

ブローカの構成、制御および監視機能は、ブローカの管理対象となる各データベースでメンテナンスされるサーバー側ソフトウェアと構成ファイルにより実装されます。このソフトウェアは、Oracle Data Guardモニターと呼ばれます。

以降の各項では、ブローカ構成を管理するための、Oracle Data GuardモニターとOracleデータベースおよびリモートOracle Data Guardモニターの相互作用について説明します。

1.5.1 Oracle Data Guardモニター(DMON)プロセス

Oracle Data Guardモニター(DMON)プロセスは、ブローカの管理対象となる各データベース・インスタンスに対して実行されるOracleバックグラウンド・プロセスです。Oracle Data Guard Brokerを起動すると、DMONプロセスが作成されます。

参照:

ブローカの起動方法は、「Data Guard Brokerの起動」を参照してください

データベースの管理にCloud ControlとDGMGRLのどちらを使用する場合でも、DMONプロセスはサーバー側コンポーネントであり、ローカル・データベースおよび他のデータベースで実行中のDMONプロセスと相互に作用して、要求された機能を実行します。また、DMONプロセスはブローカ構成の健全性を監視し、構成に関する一貫した記述が各データベースに確実に存在するようにします。

図1-2に、Oracleデータベースのインスタンスを構成する複数のバックグラウンド・プロセスの1つであるブローカのDMONプロセスを示します。図中の各データベース・インスタンスには固有のDMONプロセスがあります。

図1-2 データベースとブローカ(DMON)プロセス

図1-2の中央にあるジグザグの矢印は、同じブローカ構成に含まれる2つのデータベースのDMONプロセス間に存在する双方向のOracle Net Services通信チャネルを表しています。

この双方向通信チャネルは、データベース間での要求のやりとりと、ブローカ構成に含まれるすべてのデータベースの健全性の監視に使用されます。

1.5.2 構成管理

ブローカのDMONプロセスは、ブローカ構成のすべてのメンバーに関する情報をバイナリ構成ファイルに永続的に維持します。このファイルのコピーは、ブローカ構成に属している各データベースに対するDMONプロセスによってメンテナンスされます。Oracle RACデータベースの場合は、このファイルのコピーが各データベースごとにすべてのインスタンスによって共有されます。

この構成ファイルには、構成内でのデータベースの状態とプロパティを記述する情報も含まれます。たとえば、このファイルには、構成内のデータベースと、各データベースのロール、プロパティおよび状態が記録されます。

構成データはDMONプロセスにより透過的に管理され、すべてのデータベース間で構成情報の一貫性が維持されます。ブローカは、構成ファイル内のデータを使用して、データベースの構成と起動、各データベースの動作の制御、およびDGMGRLとCloud Controlへの情報の提供を行います。

参照:

詳細は、「データベース・プロパティの管理」を参照してください

データベースをブローカ構成に追加したり、既存データベースのプロパティを変更すると、各DMONプロセスはその構成ファイルのコピーに新しい情報を記録します。

1.5.3 データベース・プロパティ管理

各データベースには、DMONプロセスがデータベースの動作を制御するための様々なプロパティが関連付けられています。プロパティは、構成ファイルに記録されます。Oracle Data Guard環境に関連するデータベース初期化パラメータの制御には、多数のデータベース・プロパティが使用されます。

ブローカがデータベース自体と構成ファイル内の両方でパラメータの値を確実に更新できるように、サーバー・パラメータ・ファイルを使用して、静的および動的な初期化パラメータを制御する必要があります。サーバー・パラメータ・ファイルを使用すると、ブローカは、データベース管理者(DBA)がブローカの使用時に選択したプロパティ値と、サーバー・パラメータ・ファイルに記録された関連する初期化パラメータ値を調整できます。

ブローカ構成内のデータベース・プロパティに値を設定すると、ブローカはその変更を構成ファイルに記録し、Oracle Data Guard構成内のすべてのデータベースに伝播します。

注意:

ブローカは、デフォルトおよび非デフォルトのサーバー・パラメータ・ファイル名の両方をサポートします。非デフォルトのサーバー・パラメータ・ファイル名を使用する場合は、初期化パラメータ・ファイルでサーバー・パラメータ・ファイルの完全なファイル名と位置を指定する必要があります。Oracle RACデータベースの場合は、すべてのインスタンス用に非デフォルトのサーバー・パラメータ・ファイルが1つ必要です。

参照:

詳細は、「構成可能(変更可能)なプロパティ」を参照してください

2 Oracle Data Guardのインストール

Oracle Data Guardのインストールの詳細は、次のトピックを参照してください。

- Oracle Data Guardのインストール

- 前提条件

参照:

Oracle Data Guard Broker構成での新規リリースへのアップグレードに関するヘルプは、「Oracle Data Guard Brokerのアップグレードとダウングレード」を参照してください

2.1 Oracle Data Guardのインストール

Oracle Data Guardは、Oracleデータベース・ソフトウェアのEnterprise EditionとPersonal Editionに組み込まれています。Oracle Data Guard構成は、SQL*Plus、Oracle Data Guard Brokerのコマンドライン・インタフェース(DGMGRL)、または互換性のあるバージョンのOracle Enterprise Manager Cloud Control (Cloud Control)を使用して管理できます。

Oracle Enterprise EditionまたはPersonal Editionのデータベース・ソフトウェアを、ブローカ構成に組み込む場所ごとにインストールします。Oracle Data Guardのグラフィカル・ユーザー・インタフェースを使用する場合は、互換性のあるバージョンのCloud Controlをインストールする必要があります。

さらに、ファスト・スタート・フェイルオーバーを使用するには、DGMGRLをインストールし、オブザーバ・ソフトウェアを実行する必要があります。オブザーバは、プライマリ・システムおよびスタンバイ・システムとは別のコンピュータ・システムで動作させることをお薦めします。DGMGRLをオブザーバ・コンピュータにインストールするには、次のリストに示すいずれかの方法を使用します。

- Oracle Universal Installerの「Administrator」オプションを選択し、Oracle Client Administratorを完全インストールします。
このインストールにはDGMGRLが含まれますが、Cloud Controlエージェントは含まれません。これによって、Cloud ControlではなくDGMGRLコマンドを使用してオブザーバを管理できます。(Cloud Controlエージェントは別個にインストールできます。)

- 完全なOracle Database Enterprise EditionまたはPersonal Editionソフトウェア・キットをインストールします
このインストールにはDGMGRLとCloud Controlエージェントが含まれるため、Cloud ControlまたはDGMGRLコマンドを使用してオブザーバを管理できます。

注意:

オブザーバはサポート対象のどのプラットフォームで実行することも可能であり、そのプラットフォームはプライマリ・データベースまたはターゲット・スタンバイ・データベースのプラットフォームと異なっていても構いません。

2.2 前提条件

ブローカを使用するには、次の条件を満たしている必要があります。

- プライマリおよびスタンバイ・データベースで、同じバージョンのOracle Databaseが使用されている必要があります。各データベースは、単一インスタンス環境または複数インスタンス環境にインストールできます。データベースには、Oracle Enterprise EditionまたはPersonal Editionのライセンスが必要です。

- ブローカ・プロパティと関連する初期化パラメータ値との間でブローカが値を永続的に調整できるように、サーバー・パラメータ・ファイル(SPFILE)を使用する必要があります。詳細は、「構成可能(変更可能)なプロパティ」を参照してください。
構成内のデータベースがOracle RACデータベースである場合、Oracle RAC環境で使用するために、サーバー・パラメータ・ファイル(SPFILE)を適切に構成する必要があります。

参照:

Oracle RACにおける初期化ファイルの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- DG_BROKER_START初期化パラメータの値は、TRUEに設定されている必要があります。詳細は、「Data Guard Brokerの起動」を参照してください。(このパラメータはCloud Controlによって自動的に設定されます。)

- 構成にOracle RACデータベースが含まれる場合は、そのデータベースのDG_BROKER_CONFIG_FILEn初期化パラメータを、そのデータベースの全インスタンスについて同じ共有ファイルを指すように設定する必要があります。共有ファイルには、クラスタ・ファイル・システム上のファイル(該当する場合)、ファイルまたはOracle自動ストレージ管理(Oracle ASM)を使用して格納されたファイルを使用できます。

参照:

「構成管理」の構成ファイル情報を参照してください。また、ブローカ構成ファイル設定の詳細は、「ブローカ構成ファイルの設定」を参照してください。

- 既存のスタンバイ・データベースをブローカ構成に含める場合は、Oracle Net Servicesネットワーク構成ファイルを、プライマリ・データベースとスタンバイ・データベースで設定する必要があります。Cloud Controlは、スタンバイ・データベースを作成する際の構成ファイルの作成を支援できます。

参照:

ネットワーク構成ファイルの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- ブローカ構成で、DGConnectIdentifierプロパティを使用して各データベースの接続識別子を指定します。データベースの接続識別子は、次の条件を満たす必要があります。

- 構成内のその他すべてのデータベースからアクセスできます。

- Oracle RACデータベースのすべてのインスタンスにアクセスできます。

- Oracle RACデータベース上の接続時フェイルオーバーを可能にするため、すべてのインスタンスが動的にリスナーに登録するサービスを指定します。

注意:
Oracle Clusterwareによって定義および管理されるサービスは指定できません。

- プライマリ・データベースのREDO転送サービスによるOracle RACスタンバイ・データベースへのREDOデータの転送が、そのスタンバイ・データベースの受信インスタンスでエラーが発生した場合でも続行されるようにフェイルオーバー属性が設定されています。

参照:

接続識別子の定義の詳細は、『Oracle Net Services管理者ガイド』を参照してください。

- DGMGRLでブローカ操作中にインスタンスを再起動できるようにするには、各インスタンスのローカル・リスナーに静的サービスを登録する必要があります。また、ファスト・スタート・フェイルオーバーが発生した後、元のプライマリ・データベースの自動回復の一部としてオブザーバーがインスタンスを再起動できるようにするには、サービスを静的に登録する必要があります。静的サービスを定義および登録する必要があるのは、Oracle ClusterwareもOracle Restartも使用していない場合のみです。
デフォルトで、ブローカは静的サービス名をdb_unique_name_DGMGRL.db_domainと仮定して、リスナーがlistener.oraファイルで次の内容で開始されたと予期します。

LISTENER = (DESCRIPTION =
(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=host_name)
(PORT=port_num))))
SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SID_NAME=sid_name)
(GLOBAL_DBNAME=db_unique_name_DGMGRL.db_domain)
(ORACLE_HOME=oracle_home)
(ENVS="TNS_ADMIN=oracle_home/network/admin")))

別の静的サービス名を使用することもできます。その場合は、登録されている静的サービスを反映するようにStaticConnectIdentifierインスタンス固有のプロパティを変更してください。

参照:

- 静的サービスの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- 静的サービスとStaticConnectIdentifier構成可能プロパティの使用に関する追加の情報は、My Oracle Supportノート1387859.1 (http://support.oracle.com)を参照してください

- プライマリ・データベースをARCHIVELOGモードでオープンする必要があります。

- プライマリ・データベースとスタンバイ・データベースの両方に対して、COMPATIBLE初期化パラメータ値を11.2以上に設定する必要があります。ただし、Oracle Database 12cリリース1 (12.1)の新機能を利用する場合は、Oracle Data Guard構成内のすべてのデータベースでCOMPATIBLEパラメータを12.1に設定します。
ブローカが機能するには、プライマリ・データベースとスタンバイ・データベースの両方で、COMPATIBLE初期化パラメータ値が同じ値に設定されている必要があります。値が異なる場合、REDO転送サービスでREDOデータをプライマリ・データベースからスタンバイ・データベースに転送できない場合があります。

- 『Oracle Data Guard概要および管理』の説明に従って、REDO転送認証方式を選択および構成してください。

- Oracle Database 12cリリース1 (12.1)では、ブローカ構成に追加されるすべてのデータベースで、SERVICE属性が設定され、NOREGISTER属性が設定されていない、すべてのLOG_ARCHIVE_DEST_nパラメータがクリアされる必要があります。

参照:

- Oracle Data Guard Brokerの準備および起動の詳細は、「Data Guard Brokerの起動」を参照してください

3 ブローカ構成の管理

次のトピックでは、ブローカ構成そのものを管理する方法について説明します。ブローカ構成のコンポーネント管理に関する情報は、「ブローカ構成のメンバーの管理」を参照してください。

- 構成のサポート

- 構成プロパティ

- ブローカ構成ファイルの設定

- Data Guard Brokerの起動

- ブローカ構成の管理サイクル

- 操作の有効化と無効化

- 構成ステータス

3.1 構成のサポート

Oracle Data Guard Brokerでは、最大253のメンバーからなるブローカ構成を作成して、1つのプライマリ・データベースと、プライマリ・データベースからREDOを直接受信する、スタンバイ・データベースと遠隔同期インスタンスの組合せを含めることができます。ブローカは、構成内のメンバーの制御、構成の健全性の監視、および健全性と他の操作特性のレポートを行います。これらの作業には、Oracle Enterprise Manager Cloud Controlを使用している場合はOracle Enterprise Managerの通知メカニズム、DGMGRLを使用している場合はSHOWコマンドが使用されます。

サポートされるOracle Data Guard構成には、次のコンポーネントが含まれています。

- プライマリ・データベース(Oracle RACまたは非Oracle RAC)

- プライマリ・データベースからREDOを直接受信する、スタンバイ・データベースと遠隔同期インスタンスの組合せ

- データベース間の接続を定義するOracle Net Servicesネットワーク構成

- スタンバイ(アーカイブREDOログ・ファイル)の接続先パラメータと構成プロパティ

- プライマリ・データベースからスタンバイおよび遠隔同期インスタンスにREDOデータを送信するREDO転送サービス

- アーカイブREDOログ・ファイルまたはスタンバイREDOログ・ファイルからREDOデータをスタンバイ・データベースに適用するログ適用サービス

Oracle Data Guardのログ適用サービスでは、スタンバイ・データベースが、REDO転送サービスによりプライマリ・データベースから自動的に転送されるREDOデータで更新されます。アーカイブREDOログ・ファイルとスタンバイREDOログ・ファイルには、リカバリ不能な変更や記録されていない変更を除き、すべてのデータベース変更が含まれています。

- フィジカル・スタンバイ・データベースでは、REDO ApplyによりREDOデータが適用され、スタンバイ・データベースとプライマリ・データベースとの一貫性が保たれます。

- ロジカル・スタンバイ・データベースでは、SQL ApplyによりREDOデータが適用され、スタンバイ・データベースとプライマリ・データベースとの一貫性が保たれます。

- スナップショット・スタンバイ・データベースでは、REDOデータを受け取りますが、スナップショット・スタンバイ・データベースがフィジカル・スタンバイ・データベースに逆変換されるまでは適用されません。

- 遠隔同期インスタンス上では、REDOデータが受け取られ、フィジカル・スタンバイ・データベースに転送されます。遠隔同期インスタンスはデータ・ファイルを持たず、受け取ったREDOデータを適用しません。

ブローカのOracle Data Guardモニター(DMON)プロセスによって、ブローカ構成はオブジェクトのグループとして構成およびメンテナンスされ、1つの単位として管理および監視できるようになります。したがって、複数のデータベースに影響するコマンドを入力すると、DMONプロセスでは次の操作が実行されます。

- プライマリ・データベースに対する要求を実行します。

- 要求に必要な相手側の各データベースのDMONプロセスと協調しながら動作します。

- ローカル・システム上の構成ファイルを更新します。

- 相手側の各データベースのDMONプロセスと通信して、構成ファイルのコピーを更新します。

DMONプロセスによって、データベースと構成を1単位として構成、監視および制御できるようになります。構成を無効にした場合は、その構成の全データベースのブローカ管理も無効になります。後で構成を有効化すると、その構成の各データベースに対してブローカ管理が有効化されます。

図3-1に、プライマリ・データベースとフィジカル・スタンバイ・データベースからなるブローカ構成を示します。

この図は、プライマリ・データベース上に、プライマリ・データベース、DMON、オンラインREDOログ・ファイルおよびアーカイブREDOログ・ファイルの主要コンポーネント、およびREDO転送サービスを示しています。この図は、プライマリ側のスタンバイREDOログ・ファイルも輪郭線で示しています。スタンバイREDOログは現在無効ですが、スタンバイ・ロールへのスイッチオーバーまたはフェイルオーバーに備えて構成済であることを示すために輪郭線で描かれています。フィジカル・スタンバイ・データベースには、スタンバイ・データベース、ログ適用サービス、DMON、アーカイブREDOログ・ファイル、スタンバイREDOログ・ファイルが含まれています。フィジカル・スタンバイ・データベース上のオンラインREDOログ・ファイルは、現在無効ですが、プライマリ・ロールへのスイッチオーバーまたはフェイルオーバーに備えて構成済であることを示すために輪郭線で描かれています。

参照:

スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。

図3-1 Oracle Data Guard Broker構成

3.2 構成プロパティ

構成プロパティは、ブローカ構成の動作を制御します。これらのプロパティの値は、DGMGRLまたはCloud Controlを使用して表示し、動的に更新できます。ただし、一部のプロパティは、DGMGRLを使用しなければ更新できません。

構成プロパティは構成全体が有効範囲です。つまり、プロパティに対して設定した値は、構成内の各データベースに均一に適用されます。

参照:

すべてのブローカ構成プロパティの詳細は、「Oracle Data Guard Brokerのプロパティ」を参照

3.3 ブローカ構成ファイルの設定

構成ファイルのコピーはデータベースごとに2つずつメンテナンスされるため、最後に認識された有効な構成の状態が常に記録されています。ブローカを初めて起動すると、オペレーティング・システム固有のデフォルト・パス名とファイル名を使用して、構成ファイルが自動的に作成されます。このデフォルト・パス名とファイル名を上書きするには、そのデータベースで次の初期化パラメータを設定します。

DG_BROKER_CONFIG_FILE1
DG_BROKER_CONFIG_FILE2

DG_BROKER_CONFIG_FILE1およびDG_BROKER_CONFIG_FILE2初期化パラメータを設定する場合、次の制限事項に注意してください。

- これらのパラメータは、Oracle Data Guard Brokerが実行中でない場合のみ設定または変更できます(DG_BROKER_START=FALSE)。

- これらのパラメータで、すべてのOracle RACインスタンスで共有されるOracle ASM、Oracle OCFSまたはNFSを指定する必要があります。

Oracle Data Guard Brokerは、Oracleにより管理されるデータファイルまたはユーザーが管理するデータファイルのいずれかを使用するデータベースと連動します。これらのデータファイルは、ファイル・システムまたはOracle ASMディスク・グループに格納できます。この項の内容は、次のとおりです。

- ブローカ構成ファイルの名前の変更

- Oracle RAC環境でのブローカ構成ファイルの管理

3.3.1 ブローカ構成ファイルの名前の変更

構成ファイル名は、SQL文ALTER SYSTEMを発行して動的に変更できます。ただし、これらのパラメータはブローカのDMONプロセスの実行中は変更できません。特定のデータベースでこれらの構成ファイルの名前を変更するには、次の手順を実行します。

1. DGMGRL DISABLEコマンドを使用してブローカ構成を無効化します。「操作の有効化と無効化」を参照してください。

2. 次のSQL文を使用して、Oracle Data Guard BrokerのDMONプロセスを停止します。

SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;

3. データベースの構成ファイル名を次のように変更します。

SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1=filespec1;
SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2=filespec2;

注意:

ブローカがOracle RACデータベースを管理している場合は、各インスタンスのDG_BROKER_CONFIG_FILE1の値とDG_BROKER_CONFIG_FILE2の値が、同じ物理ファイル・セットを指す必要があります。

4. ファイルを移動する方法は、現在ファイルが格納されている場所およびファイルの移動先によって異なります。

- ファイルがオペレーティング・システムのファイル・システムに格納されている場合は、オペレーティング・システムのコマンドを使用してファイルを新しい場所に移動します。

- 元の場所または新しい場所がOracle ASMディスク・グループである場合は、DBMS_FILE_TRANSFER.COPY_FILE関数を使用して、新しい場所にファイルを転送します。

5. 次のようにOracle Data Guard BrokerのDMONプロセスを再起動します。

SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;

6. DGMGRLのENABLEコマンドまたはCloud ControlのOracle Data Guard管理ページの「有効化」操作を使用して、ブローカ構成を有効化します。

注意:

リリース11.2以降、このファイルはサポートされている4KB以下のセクター・サイズ(物理ブロック・サイズ)を持つディスク上に格納できます。11.2より前のリリースで生成された構成ファイルは、最初にファイルが作成されたときと同じセクター・サイズを持つディスクにしか格納できないように制限されていました。これらのファイルは異なるセクター・サイズの場所に移動する前に、まずリリース11.2にアップグレードする必要があります。アップグレードしない場合、任意のブローカ構成内で、様々なセクター・サイズの場所に格納される可能性があります。詳細は、「Oracle Database 10gおよびOracle Database 11gからOracle Database 12cリリース1(12.1)へのアップグレード」参照してください。

3.3.2 Oracle RAC環境でのブローカ構成ファイルの管理

ブローカがOracle RACデータベースを管理している場合は、各インスタンスのDG_BROKER_CONFIG_FILE1の値とDG_BROKER_CONFIG_FILE2の値が、同じ物理ファイル・セットを指す必要があります。つまり、データベースのインスタンスがすべて同じ構成ファイル・セットを参照する必要があります。構成ファイルは、次のいずれかの方法でデプロイできます。

- 構成ファイルに対するクラスタ・ファイル・システム(CFS)の使用

- 構成ファイルに対するOracle ASMディスク・グループの使用

3.3.2.1 構成ファイルに対するクラスタ・ファイル・システム(CFS)の使用

クラスタ・ファイル・システム(CFS)が使用可能で、構成ファイルがCFSに格納されている場合は、すべてのインスタンスのDG_BROKER_CONFIG_FILEnパラメータに、CFS領域へのパスを含むファイル名を設定します。図3-2に、CFS上のブローカ構成ファイルの設定を示します。この使用例では、すべてのインスタンスのパラメータと値は次のとおりです。

DG_BROKER_CONFIG_FILE1=$ORACLE_BASE/admin/db_unique_name/dr1db_unique_name.dat
DG_BROKER_CONFIG_FILE2=$ORACLE_BASE/admin/db_unique_name/dr2db_unique_name.dat

図3-2 CFS領域でのブローカ構成の設定

3.3.2.2 構成ファイルに対するOracle ASMディスク・グループの使用

ブローカの構成ファイルは、Oracle ASMディスク・グループにも格納できます。図3-3に、Oracle ASMデバイス上のブローカ構成ファイルの設定を示します。この使用例では、パラメータと値は次のように指定されます。

ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1 = '+DG/DIRECTORY/DR1.DAT' SCOPE=BOTH;
ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2 = '+DG/DIRECTORY/DR2.DAT' SCOPE=BOTH;

図3-3 Oracle ASMでのブローカ構成の設定

構成ファイルにはユーザーが明示的に名前を付ける必要があるため、これらの構成ファイルはOracle Managed Files(OMF)ではありません。ブローカの構成ファイルをOracle ASMディスク・グループ上に作成するには、初期化パラメータDG_BROKER_CONFIG_FILE1およびDG_BROKER_CONFIG_FILE2を、既存のOracle ASMディスク・グループの名前、そのディスク・グループ内の既存のディレクトリおよび構成ファイル自体の名前を含む文字列値に設定します。

3.4 Data Guard Brokerの起動

構成ファイルの設定後に、各データベースのDG_BROKER_START初期化パラメータをTRUEに設定し、DMONプロセスを起動する必要があります。

デフォルトでは、DG_BROKER_START初期化パラメータはFALSEに設定されています。ただし、値は次の方法で設定できます。

- Cloud Controlを使用している場合、新規に作成されるスタンバイ・データベースのDG_BROKER_START初期化パラメータは自動的にTRUEに設定されます。

- DGMGRLを使用している場合、明示的にDG_BROKER_START初期化パラメータをTRUEに設定する必要があります。TRUEに設定しないと、ブローカは起動しません。次のSQL文を使用すると、DG_BROKER_START初期化パラメータを設定できます。

SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;

System altered.

SQL> SHOW PARAMETER DG_BROKER_START

NAME               TYPE      VALUE
------------------------------------
dg_broker_start    boolean   TRUE

Cloud ControlとDGMGRLのどちらを使用している場合も、プライマリとスタンバイの各データベース上で、サーバー・パラメータ・ファイルのDG_BROKER_START初期化パラメータの値をTRUEに設定します。これにより、いずれかのデータベース・インスタンスの次回起動時にOracle Data Guard Brokerが自動的に起動することが保証されます。

3.5 ブローカ構成の管理サイクル

ブローカを使用すると、新規構成を作成したり既存の構成を管理できます。図3-4に、ブローカ構成のライフ・サイクルを示します。

図3-4 ブローカ構成とそのデータベースのライフ・サイクル

ブローカ構成の作成

Cloud Controlを使用している場合は、スタンバイ・データベースの追加ウィザードを使用して、既存のスタンバイ・データベース(Oracle RACまたは非Oracle RAC)を構成に追加するか、新規のスタンバイ・データベース(Oracle RACまたは非Oracle RAC)を作成して構成に追加できます。スタンバイ・データベースは、フィジカル、ロジカルまたはスナップショットのどれでもかまいません。

DGMGRLを使用する場合は、プライマリ・データベースとスタンバイ・データベースがすでに存在している必要があります。スタンバイ・データベースは、プライマリ・データベースの制御ファイルとデータファイルのバックアップから作成し、リカバリ用に準備します。

ブローカ構成の有効化

Oracle Data Guard構成は、ブローカで管理または監視するために有効化する必要があります。逆に、ブローカで管理する必要がなくなった場合には、構成を無効化します。構成を無効化すると、そのすべてのデータベースに関するブローカ管理も無効化されます。

注意:

DGMGRLを使用すると構成を有効化または無効化できます。Cloud Controlを使用して構成を無効化することはできません。前にDGMGRLを使用して無効化した構成は、Cloud Controlを使用して有効化できます。

ブローカ構成は、初めてCloud Controlを使用して作成されると、スタンバイ・データベースの追加ウィザードの完了後すぐに自動的に有効化されます。

ブローカ構成は、最初にDGMGRLを使用して作成された時点では無効な状態になっています。つまり、その構成要素であるデータベースは、まだブローカの制御下にありません。DGMGRLを使用してデータベースをブローカ構成に組み込んだ後は、ブローカで管理できるように構成を有効化する必要があります。

次のいずれかを有効化できます。

- すべてのデータベースを含む構成全体

- 個々のスタンバイ・データベース

問題が発生して、ブローカ構成内のデータベースが正常に機能しない場合は、データベースを簡単に無効化できます。プライマリ・データベースは無効化できないことに注意してください。プライマリ・データベースを無効化するには、構成全体を無効にする必要があります。

さらに、構成を一時的に無効化し、実際のデータベース・プロパティに影響を与えずに、ブローカ構成内の一部のプロパティを変更することもできます。変更されたプロパティが有効になるのは、ブローカによる管理のために構成が再度有効化された場合です。

必要に応じたブローカ構成内のロール変更

単一のコマンドを発行することで、構成内のデータベースのロールをいつでも変更できます。なんらかのイベントによってプライマリ・データベースが使用不能になった場合は、スタンバイ・データベースの1つが新しいプライマリ・データベースになるようにフェイルオーバーできます。

以前のプライマリ・データベース上でフラッシュバック・データベースが有効な場合、フェイルオーバーの完了後、元のプライマリ・データベースを新しいプライマリ・データベースのスタンバイ・データベースとして回復できます。

また、メンテナンスのために予定されている停止時間を短縮できます。これは、本番処理を現行のプライマリ・データベースからスタンバイ・データベースにすばやく切り替えて、予定されたメンテナンスの完了後に逆の切替えをすばやく実行できるためです。

参照:

ロール変更の詳細は、「スイッチオーバー操作とフェイルオーバー操作」を参照

スナップショット・スタンバイ・データベースへの変換

いつでも、コマンドを発行して、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換できます。スナップショット・スタンバイ・データベースは完全に更新可能なデータベースで、プライマリ・データベースから生成されたREDOデータを受信しますが、適用しません。

スナップショット・スタンバイ・データベースを使用して処理を終了後、再びコマンドを発行してフィジカル・スタンバイ・データベースに変換できます。フィジカル・スタンバイ・データベースへの変換の完了後、REDO Applyサービス(状態がAPPLY-ONであれば)が開始され、すべての累積REDOデータが適用されます。

必要に応じたデータベースの状態変更

構成を初めて有効化すると、デフォルトで、プライマリのREDO転送サービスおよびスタンバイ(スナップショット・スタンバイを除く)のログ適用サービスが開始します。

どの時点でも、Cloud ControlまたはDGMGRLを介して単一のコマンドを発行して、データベースの状態を変更できます。たとえば、プライマリ・データベースをTRANSPORT-OFF状態にして、スタンバイ・データベースへのREDOデータの送信を一時的に停止できます。続いて、プライマリ・データベースをTRANSPORT-ON状態にして、REDOデータのスタンバイへの送信を再開できます。

参照:

データベースの状態の変更は、「ブローカ構成のメンバーの管理」を参照

必要に応じたデータベース・プロパティの更新

ブローカを使用すると、データベース・プロパティを設定できます。一部のプロパティは、データベース初期化パラメータに対応しています。これらのプロパティを変更すると、REDO転送、スタンバイ・ファイル管理、ログ適用などを動的に制御し、全体的な構成保護モードをサポートできます。ブローカは、Oracle Data Guard構成で各データベースのブローカ構成ファイルに変更を記録し、必要に応じて、サーバーのパラメータ・ファイルの関連初期化パラメータにその変更を伝播します。

参照:

データベース・プロパティの詳細は、「ブローカ構成のメンバーの管理」および「Oracle Data Guard Brokerのプロパティ」を参照

必要に応じたデータ保護モードの設定

ブローカでは、構成のデータ保護モードを設定できます。保護モードを構成することで、データ保護、可用性またはパフォーマンスを最大化できます。

注意:

データ保護モードの管理の詳細は、「データ保護モードの管理」を参照

構成の監視

構成の健全性をチェックし、データベースのプロパティを表示および更新し、Cloud Controlイベントを設定できます。

Cloud Controlには、指定の間隔でグラフ・データやステータスを自動的および動的にリフレッシュする動的パフォーマンス・ページも用意されています。パフォーマンス・グラフには、生成および適用されているREDOデータの遅れと量のサマリーがグラフ形式で示されます。

3.6 操作の有効化と無効化

ブローカによる管理についての重要な概念は、ブローカ構成におけるデータベースのブローカ管理の有効化および無効化です。有効化と無効化の操作は、ブローカ構成にあるデータベース用に定義されます。ブローカ構成にないデータベース上ではブローカ操作を実行できません。これは、ブローカ構成内のデータベースを有効または無効にすると、実際には、ブローカが指定されたデータベースを管理および監視する機能が有効または無効になるためです。

ただし、ブローカ構成を無効にしても、実際のOracle Data Guard構成内の現行のサービスと操作は影響を受けません。たとえば、ブローカ構成を無効にすると、Oracle Data Guard構成内のREDO転送サービスとログ適用サービスは引き続き機能しますが、ブローカ・インタフェース経由では管理できなくなります。

また、データベースを無効にしても、それがブローカ構成ファイルから削除されることはありません。無効化されたデータベースのプロパティを変更した後、DGMGRLのENABLE CONFIGURATIONまたはENABLE DATABASEコマンド、あるいはCloud ControlのOracle Data Guard管理ページの「有効化」オプションを使用して、ブローカによる管理機能を再び有効化できます。

注意:

ブローカ構成内のスタンバイ・データベースに関してブローカによる管理を無効化すると、プライマリ・データベースが消失した場合にも、そのスタンバイ・データベースはブローカでフェイルオーバー・ターゲットとして使用できなくなります。

ブローカによる構成管理を無効化すると、ブローカのデータベース監視および制御機能を削除する場合にも役立ちます。たとえば、構成を一時的に無効化し、ブローカ構成内の1つ以上のプロパティをすべて同時に変更すると便利な場合があります。無効化された構成でプロパティを変更した場合、その変更は構成を再び有効化するまで実行中のデータベースには適用されないため、制御対象となる実際のデータベース・プロパティに影響を与えることはありません。たとえば、無効化された構成で、構成の保護モード全体とREDO転送サービスのプロパティを変更し、次の有効化操作時にすべての変更を同時に構成へ適用できます。

参照:

保護モードによるブローカ操作への影響

3.7 構成ステータス

構成ステータスは、構成全体の健全性を示します。この情報は、そのすべてのデータベースのステータスから取得されます。

構成に可能なステータス・モードは、次のとおりです。

- 成功
構成は、内部で構成されているすべてのデータベースも含めて、エラーや警告なしでユーザーの指定どおりに動作しています。

- 警告
構成内の1つ以上のデータベースで、ユーザーの指定どおりに操作が行われていません。詳細情報を取得するには、DGMGRLのSHOW DATABASE <db-unique-name>コマンドまたはCloud Control画面を使用して各データベースを検索し、そのステータスを調べて問題の原因を明らかにします。

- エラー
構成内の1つ以上のデータベースで障害が発生したか、またはユーザーの指定どおりに操作が行われない可能性があります。詳細情報を取得するには、DGMGRLのSHOW DATABASE <db-unique-name>コマンドまたはCloud Control画面を使用して各データベースを検索し、そのステータスを調べて問題の原因を明らかにします。

- UNKNOWN/DISABLED
構成のブローカ管理は無効化されており、ブローカは構成内のデータベースのステータスを監視していません。

4 ブローカ構成のメンバーの管理

次のトピックでは、ブローカ構成の様々なメンバーを管理する方法を説明します。ブローカ構成そのものを管理する方法に関する情報は、「ブローカ構成の管理」を参照してください。

- ブローカ構成メンバーの管理

- ブローカ構成メンバーの状態管理

- データベース・プロパティの管理

- REDO転送サービスの管理

- ログ適用サービスの管理

- データ保護モードの管理

- 遠隔同期インスタンスの管理

- ファスト・スタート・フェイルオーバーの管理

- データベース変換の管理

- データベースのステータス

4.1 ブローカ構成メンバーの管理

ブローカは構成ファイルの情報を使用して、構成の各メンバーの状態を管理および監視します。

ブローカでは、ブローカ構成に含まれる様々なタイプのメンバーが区別されます。各タイプのメンバーは、そのタイプのメンバーに適切な、状態とプロパティの組合せを持っています。

4.2 ブローカ構成メンバーの状態管理

構成が有効化されている場合、構成内のメンバーの状態は、REDOデータの転送中またはREDOデータの適用中など、Oracle Data Guardの動作を指示するいずれかの状態になります。表4-1に、様々な状態を示します。

スナップショット・スタンバイ・データベースは、状態を持たず、REDOデータを受信するのみであるため、この表にはリストされていません。

状態がないため、遠隔同期インスタンスもこの表に含まれません。それはREDOを受け取って、スタンバイ・データベースに転送するだけです。

表4-1 データベースの状態と説明

データベース・ロール

状態名

説明

プライマリ

TRANSPORT-ON

REDO転送サービスは、プライマリ・データベースが読取り/書込みアクセス用にオープンされるとREDOデータをスタンバイ・データベースまたは遠隔同期インスタンスに転送するように設定されます。

これがOracle RACデータベースの場合は、読取り/書込みモードでオープンされているすべてのインスタンスでREDO転送サービスが実行されます。

これは、プライマリ・データベースが初めて有効化されるときのデフォルト状態です。

プライマリ

TRANSPORT-OFF

プライマリ・データベースのREDO転送サービスが停止します。

これがOracle RACデータベースの場合は、どのインスタンスでもREDO転送サービスが実行されません。

フィジカル・スタンバイ

APPLY-ON

フィジカル・スタンバイ・データベースのREDO Applyが開始します。

スタンバイ・データベースがOracle RACデータベースの場合、ブローカは適用インスタンスと呼ばれる単一のスタンバイ・インスタンスでのみREDO Applyを起動します。このインスタンスに障害が発生すると、ブローカは、マウントされているか読取り専用でオープンされている他のインスタンスを自動的に選択します。この新規インスタンスが適用インスタンスとなります。

これは、フィジカル・スタンバイ・データベースが初めて有効化されるときのデフォルト状態です。

Oracle Active Data Guardオプションのライセンスを購入済の場合は、REDO Applyがアクティブなときにフィジカル・スタンバイ・データベースをオープン状態にしておくことができます。この機能はリアルタイム問合せと呼ばれます。詳細は、『Oracle Data Guard概要および管理』を参照してください。

フィジカル・スタンバイ

APPLY-OFF

REDO Applyが停止します。

これがOracle RACデータベースの場合は、データベースの状態をAPPLY-ONに変更するまで、インスタンスでは適用サービスが実行されません。

ロジカル・スタンバイ

APPLY-ON

ロジカル・スタンバイ・データベースがオープンされている場合、ロジカル・スタンバイのデータベース・ガードがオンであれば、そのデータベースでSQL Applyが起動します。

これがOracle RACデータベースの場合は、単一のインスタンス(適用インスタンス)でSQL Applyが実行されます。このインスタンスに障害が発生すると、ブローカは自動的に他のオープン・インスタンスを選択します。この新規インスタンスが適用インスタンスとなります。

これは、ロジカル・スタンバイ・データベースが初めて有効化されるときのデフォルト状態です。

ロジカル・スタンバイ

APPLY-OFF

SQL Applyは実行されません。ロジカル・スタンバイのデータベース・ガードはオンです。

これがOracle RACデータベースの場合は、状態をAPPLY-ONに変更するまで、インスタンスではSQL Applyが実行されません。

4.2.1 データベースの状態遷移

DGMGRLのEDIT DATABASEコマンドを使用して、データベースの状態を明示的に変更できます。たとえば、次の例に示すEDIT DATABASEコマンドは、North_Salesデータベースの状態をTRANSPORT-OFFに変更します。

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='TRANSPORT-OFF';
Succeeded.

参照:

EDIT DATABASEコマンドの詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」を参照してください。

次の各項では、プライマリ・データベースおよびスタンバイ・データベースにおいて考えられる状態遷移について詳細に説明します。

プライマリ・データベースの状態遷移

プライマリ・データベースをTRANSPORT-ON状態に遷移する際に、ブローカは構成メンバーのREDO転送関連プロパティと、プライマリ・データベースのRedoRoutesプロパティを使用して、REDO転送サービスを設定します。(REDO転送関連のプロパティの一覧は「REDO転送サービスの管理」を、RedoRoutesプロパティの説明は「高度なREDO転送設定」を参照してください。)REDO転送サービスを設定するために、プライマリ・データベースのLOG_ARCHIVE_DEST_nおよびLOG_ARCHIVE_DEST_STATE_n初期化パラメータと全データベース(プライマリまたはスタンバイ)および遠隔同期インスタンスのLOG_ARCHIVE_CONFIG初期化パラメータが設定されます。必要な場合は、データベースのデータ保護モードもブローカ構成ファイルに記録されている保護モードに合せて設定されます。最後に、データベースがオープンされている場合、各スレッドのログが切り替えられ、REDO転送サービスが開始されます。

プライマリ・データベースをTRANSPORT-OFF状態に遷移する際、ブローカはLOG_ARCHIVE_DEST_STATE_n初期化パラメータをリセットし、すべての管理対象スタンバイへのREDO転送サービスをオフにします。ブローカ管理のすべてのスタンバイへのREDOデータの転送が停止されます。ログ・ファイルは、引き続きプライマリ・データベース側でアーカイブされます。

プライマリ・データベースがOracle RACデータベースの場合、ブローカはすべてのプライマリ・インスタンス上で、まったく同じ設定を使用してREDO転送サービスを構成します。

参照:

REDO転送サービスの管理の詳細は、「REDO転送サービスの管理」を参照してください

フィジカル・スタンバイ・データベースの状態遷移

フィジカル・スタンバイ・データベースをAPPLY-ON状態に遷移する際に、ブローカはREDO Apply関連プロパティで指定されたオプションを使用してREDO Applyを起動します(プロパティ・リストについては「ログ適用サービスの管理」を参照してください)。スタンバイがOracle RACデータベースの場合、ブローカは適用インスタンスと呼ばれる単一のスタンバイ・インスタンスでREDO Applyを起動します。

Oracle Active Data Guardオプションのライセンスを購入済の場合は、REDO Applyがアクティブなときにフィジカル・スタンバイ・データベースをオープン状態にしておくことができます。この機能はリアルタイム問合せと呼ばれます。詳細は、『Oracle Data Guard概要および管理』を参照してください。

注意:

他のインスタンスがオープンされている場合、REDO Applyを開始する前に適用インスタンスをオープンする必要があります。

APPLY-OFF状態に遷移すると、ブローカはREDO Applyを停止します。

注意:

フィジカル・スタンバイ上のOracle RAC One Nodeでオンライン・データベース再配置を実行する場合、新しいインスタンスは現在実行中のインスタンスと同じモードで開始されます。そのため、データベースが元のインスタンスにマウントされている場合、そのデータベースは新しいインスタンスにマウントされることになります。同様に、データベースが元のインスタンスでオープンしている場合、そのデータベースは新しいインスタンスでオープンされることになります。これにより、新しいインスタンスは、データベースのOracle Clusterwareで記録された開始オプションと一致しないモードで開始される可能性があります。

ロジカル・スタンバイ・データベースの状態遷移

ロジカル・スタンバイ・データベースがAPPLY-ON状態に遷移すると、ブローカは、データベースがオープンされるまで待機し、データベース・ガードを有効化してロジカル・スタンバイ・データベース内の表への変更を防ぎ、ログ適用関連プロパティで指定されたオプションを使用してSQL Applyを起動します。ロジカル・スタンバイ・データベースがOracle RACデータベースの場合、ブローカは単一のスタンバイ・インスタンス(適用インスタンス)でSQL Applyを起動します。

APPLY-OFF状態に遷移すると、ブローカはSQL Applyを停止します。

参照:

- SQL Applyの管理の詳細は、「ログ適用サービスの管理」を参照してください

- データベース・ガードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

4.3 データベース・プロパティの管理

データベース・プロパティには、監視可能なタイプと構成可能なタイプがあります。どちらのタイプのプロパティも、データベース単位の有効範囲を持つプロパティとインスタンス固有の有効範囲を持つプロパティとしてさらに分類できます。

- 監視可能なプロパティの値は、関連データベースが有効である場合にのみ表示できます。
監視可能なプロパティを使用するとデータベース関連のランタイム情報を表示できますが、このタイプのプロパティの値は変更できません。

- 構成可能なプロパティの値は、表示して動的に更新できます。
構成可能なプロパティは、ブローカの操作や構成に影響を与えます。これらのプロパティの値は、DGMGRLまたはCloud Controlを使用して変更できます。プロパティは、構成とそのメンバーが有効か無効かに関係なく編集できます。ただし、構成メンバーが無効化されている場合は、該当する構成またはメンバーを有効にするまで、新しいプロパティ値は有効になりません。

参照:

すべてのデータベース・プロパティの詳細リストは、「Oracle Data Guard Brokerのプロパティ」を参照してください

これらのプロパティを表示するには、DGMGRLのSHOWコマンドを使用するか、Cloud Controlの「プロパティの編集」ページを使用できます。例4-1では、SHOW DATABASE VERBOSEコマンドを使用して、North_Salesデータベースに関する情報を表示しています。

参照:

DGMGRLコマンドライン・インタフェースの詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」を参照

例4-1 SHOW DATABASE VERBOSEコマンドの使用によるプロパティの表示

DGMGRL> SHOW DATABASE VERBOSE 'North_Sales';

Database - North_Sales

Role:            PRIMARY
Intended State:  TRANSPORT-ON
Instance(s):
north_sales1

Properties:
DGConnectIdentifier             = 'North_Sales.example.com'
ObserverConnectIdentifier       = ''
LogXptMode                      = 'ASYNC'
RedoRoutes                      = ''
DelayMins                       = '0'
Binding                         = 'optional'
MaxFailure                      = '0'
MaxConnections                  = '1'
ReopenSecs                      = '30'
NetTimeout                      = '300'
RedoCompression                 = 'DISABLE'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyLagThreshold               = '0'
TransportLagThreshold           = '0'
TransportDisconnectedThreshold  = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/bt, dbs/t, dbs/ct, dbs/t'
LogFileNameConvert              = 'dbs/bt, dbs/t, dbs/ct, dbs/t'
FastStartFailoverTarget         = ''
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
(HOST=North_Sales.example.com)(PORT=2840))
(CONNECT_DATA=(SERVICE_NAME=North_Sales_DGMGRL.example.com)
(INSTANCE_NAME=north_sales1)(SERVER=DEDICATED)))'
StandbyArchiveLocation          = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation               = ''
LogArchiveTrace                 = '255'
LogArchiveFormat                = 'db1r_%d_%t_%s_%R.arc'
TopWaitEvents                   = '(monitor)'

Database Status:
SUCCESS

4.3.1 監視可能な(読取り専用)プロパティ

監視可能なプロパティを使用すると構成メンバー関連の情報を表示できますが、このタイプのプロパティの値は変更できません。これらのプロパティは、ブローカ構成内の問題を診断しようとするときに、非常に役立つ場合があります。たとえば、監視可能なプロパティInconsistentLogXptPropsを表示して、REDO転送サービス・プロパティの値に矛盾がある(ブローカ構成ファイルと、データベースで現在使用されている実際の値との間に一貫性がない)箇所を判断できます。

DGMGRLのSHOW DATABASE VERBOSEコマンドを使用すると、すべての監視可能なプロパティを表示できます。特定のプロパティの詳細を知るには、SHOW DATABASEコマンドを使用します。たとえば、次にInconsistentLogXptPropsプロパティの使用例を示します。

DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps';

INCONSISTENT LOG TRANSPORT PROPERTIES

INSTANCE_NAME     STANDBY_NAME  PROPERTY_NAME  MEMORY_VALUE  BROKER_VALUE
south_sales1      South_Sales     ReopenSecs           600           300

Cloud Controlでは、これらのプロパティから取得された情報が「プロパティの編集」ページに表示されます。

4.3.2 構成可能(変更可能)なプロパティ

構成可能なプロパティは、データベースまたは遠隔同期インスタンスの操作や構成に影響を与えます。DGMGRLまたはCloud Controlを使用してプライマリ・データベースを作成し、既存のスタンバイ・データベースおよび遠隔同期インスタンスを新しいブローカ構成にインポートすると、データベース・インスタンスまたは遠隔同期インスタンスの設定から、最初にプロパティ値がインポートされます。

多くのプロパティ値は、構成メンバーが無効の場合でも有効の場合でも更新できます。新しいメンバーが構成に追加されると、ブローカはそのメンバーに接続して、メンバーのプロパティの初期値を現在のメンバー設定からインポートします。次に例を示します。

DGMGRL> SHOW DATABASE 'North_Sales' 'ArchiveLagTarget';
ArchiveLagTarget = '0'

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'ArchiveLagTarget'=1200;
Property "ArchiveLagTarget" updated

DGMGRL> SHOW DATABASE 'North_Sales' 'ArchiveLagTarget';
ArchiveLagTarget = '1200'

構成が有効な場合、ブローカは、ブローカ構成ファイル内のメンバーのプロパティの値と、メンバーで使用されている値の一貫性を維持します。初期化パラメータ関連のプロパティの場合、ブローカは、ブローカ構成ファイル内の値、現在の値およびサーバー・パラメータ・ファイルの初期化パラメータ値の間の一貫性を次のように維持します。

- 動的パラメータの場合、ブローカは、そのインスタンスのシステム・グローバル領域(SGA)内、ブローカ構成ファイル内およびサーバー・パラメータ・ファイル内でパラメータの値の一貫性を維持します。

- 静的パラメータとプロパティの場合、インスタンスのシステム・グローバル領域(SGA)内のパラメータの値は、ブローカ構成ファイル内およびサーバー・パラメータ・ファイル内の値と一時的に異なる場合があります。通常、インメモリーの値は、次回にインスタンスの停止と再起動が行われたときに、サーバー・パラメータ・ファイルの値およびブローカ構成ファイルの値と同じになります。

プロパティの値は、構成が無効の場合でもブローカを使用して更新できます。ブローカはプロパティの設定を(値を検証せずに)保持し、次回ブローカ構成が有効化されたときに、サーバー・パラメータ・ファイル内の初期化パラメータおよびメモリー内の設定を更新します。

注意:

プロパティの値は構成が無効な場合にも変更できますが、変更結果は構成が有効化されるまで構成メンバーに対して有効になりません。また、一部のプロパティ値は無効な状態でのみ変更可能なことに注意してください。

4.3.2.1 ブローカの構成可能なプロパティのデフォルト値へのリセット

ブローカの大部分の構成可能なプロパティには、デフォルト値があります。異なる値を指定してデフォルトを上書きすることができます。Oracle Database 12cリリース1 (12.1)より前のリリースでは、一度デフォルト値を変更すると、プロパティを後で以前のデフォルト値に設定しなおした場合も、ユーザーが設定した値とみなされました。

Oracle Database 12cリリース1 (12.1)では、プロパティのデフォルト値が回復されたことを認識し、ユーザー設定の値とはみなさなくなりました。これはアップグレード・シナリオで好都合です。これにより、プロパティのデフォルト値がリリースによって異なっても、アップグレードの完了後、新しいデフォルト値が自動的に有効になります。ユーザー設定とみなされる値は、自動的にアップグレードされません。

デフォルト値をリセットするために実際のデフォルト値を知っている必要はありません。デフォルト値は、構成、構成メンバーまたはインスタンスのレベルでリセットすることができます。

参照:

- 「EDIT CONFIGURATION RESET (プロパティ)」

- 「EDIT DATABASE RESET (プロパティ)」

- 「EDIT INSTANCE RESET (プロパティ)」

- 「EDIT FAR_SYNC RESET (プロパティ)」

4.4 REDO転送サービスの管理

REDO転送サービスを管理するには、各構成メンバーに次の構成可能プロパティ・セットを指定します。

- DGConnectIdentifier

- AlternateLocation

- Binding

- LogShipping

- LogXptMode

- MaxConnections

- MaxFailure

- NetTimeout

- RedoCompression

- RedoRoutes

- ReopenSecs

- StandbyArchiveLocation

これらのプロパティを使用して、スタンバイ・データベースに対するREDO転送サービスのブローカによる設定方法を指定できます。LOG_ARCHIVE_DEST_n初期化パラメータの設定など、実際のREDO転送の設定(StandbyArchiveLocationプロパティを除く)は、ブローカによりプライマリ・データベース上で実行されます。プロパティの変更によりLOG_ARCHIVE_DEST_n初期化パラメータの属性変更が必要な場合、ブローカは各スレッド上でログを強制的に切り替えます。これにより、プライマリ・データベースでは新規設定が即時に使用されます。

また、スタンバイ・データベースに切り替える準備として、これらのプロパティをプライマリ・データベース上で事前に設定する必要があります。

4.4.1 REDO転送の設定

REDOデータは、Oracle Netを使用してスタンバイ・データベースに転送されます。Oracle Netサービス名は、LOG_ARCHIVE_DEST_n初期化パラメータのSERVICE属性で指定され、スタンバイ・データベースへのREDOデータの転送に使用されます。Oracle Netサービス名は、スタンバイ・データベースへの接続に必要な情報が記述された接続記述子に変換されます。

SERVICE属性は、データベース・プロパティDGConnectIdentifierを使用して設定または変更できます。DGConnectIdentifierプロパティは、構成にデータベースを初めて追加するときに設定されます。このプロパティの初期値は、ADD DATABASEコマンドのオプションのCONNECT IDENTIFIER IS句に指定した接続識別子です。

DGConnectIdentifierプロパティの値は、FAL_SERVER初期化パラメータの設定にも使用されます。いずれかのデータベースのDGConnectIdentifierプロパティが変更されると、対応するLOG_ARCHIVE_DEST_n初期化パラメータのSERVICE属性も変更されます。また、構成内で有効化されたすべてのスタンバイ・データベースで、FAL_SERVER初期化パラメータが更新されます。

4.4.2 データ保護モードに対応したREDO転送サービスの管理

ブローカによるデータ保護モードの処理方法については、「データ保護モードの管理」で説明します。構成全体の保護モードの一部として、REDO転送サービスも、選択したデータ保護モードに対して正しく設定されていることを確認する必要があります。

REDO転送サービスをSYNC、ASYNCまたはFASTSYNCモードに設定するには、LogXptModeまたはRedoRoutesデータベース・プロパティを使用します。

次のREDO転送モードがサポートされています。

SYNC

このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのSYNCおよびAFFIRM属性を使用して構成します。このモードとスタンバイREDOログ・ファイルは、最大保護モードまたは最大可用性モードのいずれかで動作している構成に必要です。このREDO転送サービスでは、プライマリ・データベースに対して最高レベルのデータ保護が可能ですが、パフォーマンスへの影響も大きくなる可能性があります。

ASYNC

このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのASYNCおよびNOAFFIRM属性を使用して構成します。このモードとスタンバイREDOログ・ファイルでは、プライマリ・データベースに対して適度なレベルのデータ保護が可能になり、パフォーマンスへの影響も小さくなります。

FASTSYNC

このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのSYNCおよびNOAFFIRM属性を使用して構成します。このモードは、最大可用性保護モードでのみ利用できます。

4.4.3 高度なREDO転送設定

デフォルトでは、プライマリ・データベースは、REDOを構成内のすべての可能なREDO転送先に送信します。RedoRoutesプロパティを使用すると、より複雑なREDO転送トポロジを作成することができます。たとえば、フィジカル・スタンバイまたは遠隔同期インスタンスが、プライマリ・データベースから受け取ったREDOを1つ以上の接続先に転送するものや、指定された接続先に対して使用されるREDO転送モードが、どのデータベースがプライマリ・ロールであるかによって異なるものなどです。

RedoRoutesプロパティは、1つ以上のREDOルーティング・ルールを含む文字列に、次に示すようにカッコに囲まれて設定されます。

(redo_routing_rule_1) [(redo_routing_rule_n)]

redo routing ruleには、redo sourceフィールドとredo destinationフィールドが含まれ、それらは次のようにコロンで区切られます。

(redo source : redo destination)

redo sourceフィールドには、次のように、キーワードLOCAL、ANY、またはDB_UNIQUE_NAME値のカンマ区切りリストが含まれる必要があります。

{LOCAL | ANY | db_unique_name_1,[,db_unique_name_n]}

- キーワードLOCALは、ローカル・データベース名の別名です。このキーワードは、遠隔同期インスタンスでは使用できません。

- ANYキーワードは、構成内の任意のデータベースの別名です。

- 1つのデータベースは、明示的にも、暗黙的(LOCALキーワードを使用)にも、指定されたデータベースで定義されている複数のREDOルーティング・ルールにおけるREDOソースとして指定することはできません。

redo destinationフィールドには、キーワードALL、またはデータベース名のカンマ区切りリストが含まれる必要があります。それぞれに続けて、オプションでREDO転送属性を指定することができます。

{ALL [attribute] | db_unique_name_1 [attribute] [,db_unique_name_n [attribute]]}

- ALLキーワードは、構成において可能なすべての接続先の別名です。

オプションのREDO転送属性は、REDOを関連の接続先に送信するために使用されるREDO転送モードを指定します。可能な値は、次の3つの値のいずれかです。

[ASYNC | SYNC | FASTSYNC]

REDO転送属性を指定しない場合、使用される転送モードは、そのREDO接続先のLogXptModeプロパティで指定されたものになります。

オプションのALTキーワードは、非代替宛先へのREDO転送ができない場合にREDOを受信する代替REDO宛先のDB_UNIQUE_NAMEを指定するために使用します。

[ALT=(alternate db_unique_name [ASYNC | SYNC | FASTSYNC] [FALLBACK])]

オプションのFALLBACKキーワードは、非代替メンバーへのREDO転送が可能になった時点で再開することを指定するために使用します。FALLBACKキーワードを使用することをお薦めします。それを省略し、その後にALTERNATE REDO転送先に障害が発生すると、代替転送先によりサービスが提供されるターミナル・スタンバイ・データベースにREDOが送信されません。

注意:

代替を指定するためには、非代替宛先で、そのMaxFailureプロパティがゼロ以外の値になっている必要があります。

高度なREDO転送設定の使用では、次のことに注意してください。

- RedoRoutesプロパティのデフォルト値はNULLです。プライマリ・データベースは、(LOCAL : ALL)として扱われます。

- REDOルーティング・ルールがアクティブになるのは、そのREDOソース・フィールドで現在のプライマリ・データベースが指定されている場合です。ルールがアクティブになっている場合、プライマリ・データベースのREDOは、ルールが定義されているデータベースによって、そのルールのREDO接続先フィールドで指定されている各接続先に送信されます。

- カスケード接続先で、その接続先へのリアルタイム・カスケーディングを有効にするには、ASYNCREDO転送属性を明示的に指定する必要があります。

- RedoRoutesプロパティは、ロジカルまたはスナップショットのスタンバイ・データベースでは設定できません。

- ロジカル・スタンバイ・データベースにRedoRoutesプロパティを設定できるのは、REDO宛先フィールドがLOCALに設定されている場合のみです。

- 代替を指定するためには、非代替メンバーで、その構成可能なプロパティMaxFailureがゼロ以外の値になっている必要があります。

参照:

- 「RedoRoutes」

例4-2 リアルタイム・カスケードに対するRedoRoutesプロパティの使用

プライマリ・データベース(North_Sales)と2つのフィジカル・スタンバイ・データベース(Local_SalesとRemote_Sales)がある構成を考えます。Local_Salesデータベースは、高可用性のために、プライマリと同じデータセンターに置かれています。Remote_Salesデータベースは、障害回復目的で、リモート・データセンターに置かれています。プライマリから両方のデータベースにREDOを送信するかわりに、RedoRoutesプロパティを使用して、ローカルのフィジカル・スタンバイ・データベースが、North_Salesからリモートのフィジカル・スタンバイ・データベース(Remote_Sales)にREDOを転送するようにリアルタイム・カスケードを構成することができます。そのためには、RedoRoutesプロパティを次のように設定する必要があります。

- North_Salesデータベースでは、North_Salesがプライマリ・ロールである場合、同期転送モードを使用してLocal_SalesデータベースにREDOを送信するように、RedoRoutesプロパティを指定する必要があります。このルールにより、プライマリがRemote_Salesデータベースに直接REDOデータを送信することがなくなります。

- Local_Salesデータベースでは、North_Salesがプライマリ・ロールの場合、Local_Salesが、North_Salesから受け取ったREDOをRemote_Salesに転送するように、RedoRoutesプロパティを指定する必要があります。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : Local_Sales SYNC)';
DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' = '(North_Sales : Remote_Sales ASYNC)';

実行時のRedoRoutes構成を表示するには、SHOW CONFIGURATIONコマンドを使用します。次に例を示します。

DGMGRL> SHOW CONFIGURATION;

Configuration - Sales_Configuration

Protection Mode: MaxAvailability
Databases:
North_Sales  - Primary database
Local_Sales  - Physical standby database
Remote_Sales  - Physical standby database (receiving current redo)

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

Remote_Sales接続先のREDOルート・ルールで、ASYNCREDO転送属性が明示的に指定されることで、その接続先へのREDOのリアルタイム・カスケーディングが有効にされたことに注意してください。

REDOのリアルタイム・カスケーディングを無効にするには、ASYNCREDO転送属性を指定しないでください。次に例を示します。

DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' = '(North_Sales : Remote_Sales)';

例4-3 リモート代替宛先に対するRedoRoutesプロパティの使用

RedoRoutesプロパティを使用すると、端末メンバーがREDOデータの受信元のメンバーに障害が発生してもREDOデータを受信できるように、(ALTキーワードを使用して)リモート代替宛先を設定することもできます。前述の例を使用すると、プライマリ・データベースとしてNorth_Salesを使用し、スタンバイ・データベースLocal_Salesに障害が発生したときにREDOデータを直接Remote_Salesに送信できます。また、FALLBACKキーワードを使用して、Local_Salesの障害が解決された時点でRemote_SalesへのREDOの送信を再開できるように設定することもできます。常にFALLBACKキーワードを使用することをお薦めします。設定せずにRemote_Salesへの接続に失敗した場合、Local_Salesが再度使用可能になっても、REDOはLocal_SalesとRemote_Salesのどちらにも送信されません。

リモート代替を設定するための最初の手順は、構成可能なプロパティMaxFailureを使用して、Local_Salesデータベースに最大障害件数を設定することです。Local_SalesのMaxFailureプロパティをゼロ以外の値に設定した場合、Local_Salesの最大障害件数に達すると、REDOは直接Remote_Salesに送信されます。次の例では、Local_Salesの最大障害件数は1に設定されています。

DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'MaxFailure' = 1;
Property "MaxFailure" updated

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' =
'(LOCAL : Local_Sales ASYNC ALT=(Remote_Sales ASYNC FALLBACK))';
Property "RedoRoutes" updated

DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' =
'(North_Sales : Remote_Sales ASYNC)';
Property "RedoRoutes" updated

DGMGRL> SHOW CONFIGURATION;

Configuration - Sales_Configuration

Protection Mode: MaxPerformance
Databases:
North_Sales    - Primary database
Local_Sales  - Physical standby database
Remote_Sales - Physical standby database
Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

RedoRoutes構成全部を表示するには、SHOW CONFIGURATION VERBOSEコマンドを使用します。次に例を示します。

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration - Sales_Configuration

Protection Mode: MaxPerformance
Members:
North_Sales - Primary database
Local_Sales - Physical standby database
Remote_Sales - Physical standby database
Remote_Sales - Physical standby database (alternate of Local_Sales)

Properties:
FastStartFailoverThreshold     = '30'
OperationTimeout               = '30'
TraceLevel                     = 'USER'
FastStartFailoverLagLimit      = '30'
CommunicationTimeout           = '180'
ObserverReconnect              = '0'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown   = 'TRUE'
BystandersFollowRoleChange     = 'ALL'
ObserverOverride               = 'FALSE'
ExternalDestination1           = ''
ExternalDestination2           = ''
PrimaryLostWriteAction         = 'CONTINUE'

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

4.4.4 REDO転送サービスのオン/オフの切替え

REDO転送サービスのオンとオフを切り替えるには、プライマリ・データベースの状態を設定します。プライマリ・データベースの状態をTRANSPORT-ONに設定するとプライマリ・データベースでREDO転送サービスが起動し、TRANSPORT-OFFに設定するとプライマリ・データベースのREDO転送サービスが停止します。

注意:

すべてのスタンバイ・データベースへのREDO転送サービスをオフにしないことをお薦めします。オフにすると、プライマリ・データベースに障害が発生した場合にデータが消失する危険性があります。

スタンバイ・データベースへのREDO転送サービスのオンとオフを個別に切り替えるには、対象のスタンバイ・データベースにデータベース・プロパティLogShippingを使用します。LogShippingプロパティは、値ONおよびOFFを受け入れます。スタンバイ・データベースに対してLogShippingプロパティをOFFに設定すると、そのスタンバイ・データベースへのREDO転送サービスはオフになりますが、他のデータベースへのREDO転送サービスは影響を受けません。LogShippingをONに設定すると、スタンバイ・データベースへのREDO転送サービスをオンに戻せます。

プライマリ・データベースの状態の設定とLogShippingプロパティの設定の関係は、次のとおりです。

- プライマリ・データベースの状態がTRANSPORT-OFFに設定されている場合、各スタンバイ・データベースの個々のLogShippingプロパティ値に関係なく、すべてのスタンバイ・データベースへのREDO転送サービスが停止します。

- プライマリ・データベースの状態がTRANSPORT-ONに設定されている場合は、各スタンバイ・データベースへのREDO転送サービスは、それぞれのデータベースのLogShippingプロパティにより決定されます。

例4-4および例4-5に、REDO転送サービスをオフにする方法を2つの使用例により示します。

例4-4 すべてのスタンバイ・データベースへのREDO転送サービスをオフにする場合

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='TRANSPORT-OFF';
DGMGRL> SHOW DATABASE 'North_Sales';

Database - North_Sales

Role:            PRIMARY
Intended State:  TRANSPORT-OFF
Instance(s):
north_sales1

Database Status:
SUCCESS

例4-5 特定のスタンバイ・データベースへのREDO転送サービスをオフにする場合

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogShipping'='OFF';
Property "LogShipping" updated

DGMGRL> SHOW DATABASE 'South_Sales' 'LogShipping';
LogShipping = 'OFF'

4.4.5 アーカイブREDOログ・ファイルの位置の指定

スタンバイ・データベースのログ適用サービスに使用されるアーカイブREDOログ・ファイルの格納場所をスタンバイ・データベース上に設定できます。そのためには、スタンバイ・データベース上でデータベース・プロパティStandbyArchiveLocationおよびAlternateLocationを設定します。

StandbyArchiveLocationでは、アーカイブREDOログ・ファイルが格納されるスタンバイ位置を指定します。ブローカが使用するのは、プライマリ・データベースから受け取ったアーカイブREDOログ・ファイルの格納場所のみです。データベースがプライマリ・データベースまたはロジカル・スタンバイ・データベースの場合、ローカルに生成されるアーカイブREDOログ・ファイルについては、LOG_ARCHIVE_DEST_n初期化パラメータを介して直接ローカルのアーカイブ先を設定する必要があります。ブローカでは、StandbyArchiveLocationの値をローカルに生成されるログ用に設定したのと同じ位置に設定できます。この場合、ブローカによりアーカイブ先のVALID_FOR属性が適切に設定されるため、プライマリ・データベースから受け取るアーカイブREDOログ・ファイルとローカルに生成されるアーカイブREDOログ・ファイルの両方に同じ位置を使用できます。

注意:

データベース・リカバリ領域を使用する場合を除き、ロジカル・スタンバイ・データベースでは、ローカルの格納先を示すLOG_ARCHIVE_DEST_n初期化パラメータのLOCATION属性とStandbyArchiveLocationプロパティまたはAlternateLocationプロパティのいずれかの値には、異なる値を設定することをお薦めします。

また、スタンバイ・データベース上でAlternateLocationプロパティを使用すると、スタンバイ・データベース上でのアーカイブREDOログ・ファイルについて代替格納場所を設定できます。これは、スタンバイ・データベースにプライマリREDOをアーカイブする場合に、ディスク容量の問題やディスク・エラーを回避する上で役立ちます。AlternateLocationでは、StandbyArchiveLocationで指定した位置に障害が発生した場合に、アーカイブREDOログ・ファイルが格納されるスタンバイ位置を指定します。ブローカは、LOG_ARCHIVE_DEST_n初期化パラメータのALTERNATE属性を使用して、代替位置を正しく設定します。

注意:

スタンバイ上のデータベース・リカバリ領域をアーカイブREDOログ・ファイルの格納に使用できます。この場合、StandbyArchiveLocationプロパティまたはAlternateLocationプロパティの値をUSE_DB_RECOVERY_FILE_DESTに設定できます。

4.4.6 その他のREDO転送設定

データベース・プロパティBinding、MaxFailure、MaxConnections、NetTimeout、RedoCompression、およびReopenSecsを使用して、REDO転送サービスのパフォーマンスをチューニングし、その障害ポリシーを設定できます。これらのプロパティは、LOG_ARCHIVE_DEST_n初期化パラメータの属性に対応します。

参照:

これらのデータベース・プロパティの詳細は「Oracle Data Guard Brokerのプロパティ」を参照

4.4.7 Oracle RACデータベース環境でのREDO転送サービス

プライマリ・データベースがOracle RACデータベースの場合、ブローカは各プライマリ・データベース・インスタンス上のREDO転送サービスが同一に設定されていることを確認します。各インスタンスのリモート接続先は同じで、すべてのインスタンスで、各リモート接続先には同じREDO転送サービス、パフォーマンス関連設定などが設定されます。インスタンスの設定が異なる場合、ブローカはそのインスタンスに関して健全性チェックの警告を発行します。

REDO転送サービスに関連する設定は、ブローカ構成ファイルにプロパティとして保存されます。スタンバイ・データベース上のREDO転送関連のプロパティを更新すると、すべてのプライマリ・データベース・インスタンス上のLOG_ARCHIVE_DEST_n初期化パラメータに対しても、ブローカによって自動的に対応する変更が実行されます。プライマリ・データベース上で新規インスタンスが作成されると、ブローカは現在管理している全スタンバイ・データベースのREDO転送関連プロパティを使用して、新規インスタンス用のREDO転送サービスを設定します。新規インスタンスがアクティビティ用にオープンされた後、このインスタンス上で生成された全アーカイブREDOログ・ファイルについて、スタンバイ・データベースへの転送が開始されます。

参照:

LOG_ARCHIVE_DEST_n初期化パラメータの詳細は、『Oracle Data Guard概要および管理』を参照してください。

4.4.8 転送ラグ

転送ラグは、スタンバイ・データベースへのREDOの転送がプライマリ・データベースでのREDOの生成からどの程度遅れているかを測定する尺度です。

スタンバイ・データベースで1つ以上のREDOギャップがある場合は、最初のREDOギャップの発生後にREDOは受信されなかったものとして、転送ラグが計算されます。

Cloud ControlとDGMGRLクライアントのいずれでも、管理対象スタンバイ・データベースごとにREDO転送ラグが表示されます。Cloud Controlでは、Oracle Data Guardホームページに転送ラグが表示されます。DGMGRLクライアントでは、スタンバイ・データベースのSHOW DATABASE出力に転送ラグが表示されます。プライマリ・データベースに対する転送ラグは表示されません。次に例を示します。

DGMGRL> show database 'South_Sales';

Database - South_Sales

Role:            PHYSICAL STANDBY
Intended State:  APPLY-ON
Transport Lag:   0 seconds (computed 0 seconds ago)
Apply Lag:       0 seconds (computed 0 seconds ago)
Apply Rate:      255.00 KByte/s
Real Time Query: OFF
Instance(s):
south_sales1

Database Status:
SUCCESS

転送ラグにより、REDO転送サービスで発生する可能性のある問題を識別することができます。

構成可能なデータベース・プロパティTransportLagThresholdを設定すると、スタンバイ・データベースへのREDOデータの転送がプライマリ・データベース上でのREDOデータの生成より遅れる場合にヘルス・チェック警告を生成することができます。

次のコマンドは、TransportLagThresholdプロパティを15秒に設定します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'TransportLagThreshold'=15;
Property TransportLagThreshold updated

さらに、構成可能なデータベース・プロパティTransportDisconnectedThresholdを設定すると、スタンバイがプライマリ・データベースとの間にいかなるREDO転送関連の通信も持っていないことを検出したときにヘルス・チェック警告を生成することができます。プロパティのデフォルト値は30秒です。

次のコマンドは、TransportDisconnectedThresholdプロパティを15秒に設定します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'TransportDisconnectedThreshold'=15;
Property TransportDisconnectedThreshold updated

4.5 ログ適用サービスの管理

次に示すログ適用に関連するデータベース・プロパティを使用して、フィジカルまたはロジカル・スタンバイ・データベース上のREDO ApplyおよびSQL Applyを管理できます。

- REDO ApplyおよびSQL Applyに共通のプロパティ

- ApplyInstanceTimeout

- DelayMins

- PreferredApplyInstance

- REDO Applyに固有のプロパティ

- ApplyParallel

- SQL Applyに固有のプロパティ

- LsbyMaxEventsRecorded

- LsbyPreserveCommitOrder

- LsbyRecordSkipErrors

- LsbyRecordSkipDdl

- LsbyRecordAppliedDdl

- LsbyMaxSga

- LsbyMaxServers

現在のデータベースの状態がAPPLY-ONの場合、SQL Apply関連のプロパティを変更すると、SQL Applyの再起動が必要になる場合があります。SQL Applyの再起動が必要なプロパティを調べるには、「Oracle Data Guard Brokerのプロパティ」のSQL Apply関連のプロパティの情報を参照してください。

データベースの現在の状態がAPPLY-OFFの場合、プロパティ変更はデータベースの状態が次回にAPPLY-ONに変化したときに有効になります。

4.5.1 遅延適用の管理

スタンバイ・データベースへのREDOの適用を遅延させるように適用サービスを設定できます。これにより、スタンバイ・データベースとプライマリ・データベース間にずれが生じ、この期間中にユーザー・エラー(表の削除など)が発生した場合も、スタンバイ・データベースには正しいデータが含まれているため、それをプライマリ・データベースに転送してデータを修復できます。

デフォルトでは遅延は設定されておらず、REDOデータはできるかぎり速やかにスタンバイ・データベースに適用されます。スタンバイ・データベースでREDOログが構成されると、ブローカは、リアルタイム適用を有効化します。REDO ApplyおよびSQL ApplyがリアルタイムでREDOを適用する場合、REDOデータは、書き込まれると同時に、スタンバイREDOログ・ファイルから直接リカバリされます。つまり、スタンバイ・データベースは、アーカイブREDOログ・ファイルからREDOデータを適用するのにログ・ファイルがアーカイブされるのを待つ必要はありません。これにより、プライマリとスタンバイのトランザクション・ラグが最小限に抑えられます。

データベース・プロパティDelayMinsを使用して、スタンバイ・データベースにREDOデータが適用されるまでのログ適用サービスの待機時間(分)を指定します。スタンバイ・データベースへのログ適用サービスのみが遅延されることに注意してください。プライマリ・データベースのREDO転送サービスは遅延されないため、プライマリ・データベースのデータは引き続きスタンバイ・データベースにより適切に保護されます。

注意:

ブローカではスタンバイ・データベースへのリアルタイム適用が自動的に有効化されるため、フラッシュバック・データベースを使用するようにすべてのデータベースを構成することをお薦めします。

4.5.2 REDO Applyでのパラレル適用の管理

REDO Applyでは、データベース・プロパティApplyParallelを使用して、プライマリ・データベースから受け取ったREDOデータの適用に複数のパラレル・プロセスを使用するかどうかを構成できます。並列性はデフォルトで有効化されています。つまり、REDO ApplyではシステムのCPUの数に基づいて最適なパラレル・プロセス数が自動的に選択されます。(これは、ApplyParallelプロパティをAUTOに設定することと同じです。)ApplyParallelプロパティをNOに設定することで並列性を無効化できます。

注意:

データベース・プロパティApplyParallelは、Cloud Controlの「プロパティの編集」ページには表示されません。

参照:

「ApplyParallel」のApplyParallelプロパティ

4.5.3 SQL Applyに対するリソースの割当て

SQL Applyに使用可能なSGAメモリーの量を制御できます。この設定には、データベース・プロパティLsbyMaxSgaを使用します。

SQL Applyで使用されるパラレル問合せサーバーの数を制御するには、データベース・プロパティLsbyMaxServersを使用します。

ユーザーは、SQL Applyのパフォーマンスとトランザクションのコミット順序との間のトレード・オフを制御できます。データベース・プロパティLsbyPreserveCommitOrderは、プライマリ・データベースでコミットされた順序と同じ順序でトランザクションがロジカル・スタンバイ・データベースにコミットされるかどうかを制御します。コミット順序を保持すると、パフォーマンスに影響する場合があります。

注意:

「LsbyMaxSga」および「LsbyMaxServers」

4.5.4 DBA_LOGSTDBY_EVENTS表の管理

DBA_LOGSTDBY_EVENTS表は、SQL Applyに影響する重要なイベントを記録します。この表に記録されるイベント・セットのうち、どのイベントが重要であるかはロジカル・スタンバイ・データベースごとに異なるため、Oracle Data Guardにはイベント記録を制御する手段が用意されています。Oracle Data Guard Brokerから、データベース・プロパティLsbyRecord* (LsbyRecordSkipDdlまたはLsbyRecordSkipErrorsなど)を使用して、特定のイベント・セットの記録を制御できます。これらのプロパティの値は、イベント記録のオンまたはオフを示すTRUEまたはFALSEです。

4.5.5 Oracle RACデータベース環境での適用サービス

スタンバイ・データベースがOracle RACデータベースの場合、ログ適用サービスが実行されるOracle RACデータベース・インスタンスは常に1つのみです。このインスタンスを適用インスタンスと呼びます。適用インスタンスに障害が発生すると、ブローカはログ適用サービスを自動的に異なるインスタンスに移動します。これを適用インスタンスのフェイルオーバーと呼びます。

4.5.5.1 適用インスタンスの選択

注意:

この項の情報は、スナップショット・スタンバイ・データベースまたは遠隔同期インスタンスには適用されません。

Oracle RACスタンバイ・データベースでどのインスタンスを適用インスタンスにしてもよい場合、ブローカが適用インスタンスを任意に選択します。特定のインスタンスを適用インスタンスとして選択するには、次の2つの方法があります。

- 最初の方法は、データベース・プロパティPreferredApplyInstanceの値を、適用インスタンスとして指定するインスタンスの名前(SidNameプロパティを参照)に設定することです。ブローカは、Oracle RACスタンバイ・データベースで適用インスタンスが選択されていない場合に、そのインスタンス上でログ適用サービスを起動します。この方法を使用するのは、スタンバイ・データベースをまだ1度も有効化していない場合、適用インスタンスに障害が発生したばかりで、ブローカが適用インスタンスをフェイルオーバーしようとしている場合、またはOracle RACデータベースが現在プライマリ・データベースとして稼働中で、スイッチオーバーの準備として適用インスタンスを指定する必要がある場合などです。適用インスタンスが選択されており、かつ、その適用インスタンスが実行中の場合は、PreferredApplyInstanceプロパティを変更しても、ブローカでは変更後の値が無視されます。

- 第2の方法では、選択され実行されている適用インスタンスを変更します。適用インスタンスを変更するには、特定の適用インスタンス引数を指定してDGMGRLのSET STATEコマンドを発行し、スタンバイ・データベースの状態をAPPLY-ONに設定します。SET STATEコマンドを実行すると、PreferredApplyInstanceプロパティが新しい適用インスタンスの値に更新されてから、ログ適用サービスが新規インスタンスに移動します。たとえば、DGMGRLのSHOWコマンドを使用してスタンバイ・データベースで使用可能なインスタンスを表示し、EDIT DATABASEコマンドを発行してログ適用サービスを新規インスタンスに移動します。

DGMGRL> SHOW DATABASE 'South_Sales'

Database - South_Sales

Role:            PHYSICAL STANDBY
Intended State:  APPLY-ON
Transport Lag:   0 seconds (computed 1 second ago)
Apply Lag:       0 seconds (computed 1 second ago)
Apply Rate:      1017.00 KByte/s
Real Time Query: OFF
Instance(s):
south_sales1   (apply instance)
south_sales2

Database Status:
SUCCESS

DGMGRL> EDIT DATABASE 'South_Sales' SET STATE='APPLY-ON' WITH APPLY INSTANCE='south_sales2';
Succeeded.

DGMGRL> SHOW DATABASE 'South_Sales' 'PreferredApplyInstance';
PreferredApplyInstance = 'south_sales2'

DGMGRL> SHOW DATABASE 'South_Sales'

Database - South_Sales

Role:            PHYSICAL STANDBY
Intended State:  APPLY-ON
Transport Lag:   0 seconds (computed 1 second ago)
Apply Lag:       0 seconds (computed 1 second ago)
Apply Rate:      1017.00 KByte/s
Real Time Query: OFF
Instance(s):
south_sales1
south_sales2   (apply instance)

Database Status:
SUCCESS

コマンドの発行時には、新規適用インスタンスが実行中であることを確認してください。それ以外の場合は、適用インスタンスが変更されません。

適用インスタンスの選択後、ブローカは適用インスタンス情報をブローカ構成ファイルに保存します。これにより、スタンバイ・データベースが停止されて再起動されても、ブローカは停止前と同じインスタンスを選択してログ適用サービスを起動できます。適用インスタンスは、ユーザーが変更するか、なんらかの原因で障害が発生してブローカが適用インスタンスのフェイルオーバーを実行すると決定するまで変更されません。

4.5.5.2 適用インスタンスのフェイルオーバー

適用インスタンスの障害に対するフォルト・トレラントを持たせるために、ブローカはログ適用サービスを異なるスタンバイ・インスタンスに自動的にフェイルオーバーすることで、Oracle RACスタンバイ・データベースの可用性を利用します。ブローカが提供する適用インスタンスのフェイルオーバー機能により、データ保護が強化されます。

適用インスタンスのフェイルオーバーを設定するには、データベース・プロパティApplyInstanceTimeoutを設定してブローカの待機時間を指定します。この待機時間は、適用インスタンス障害を検出してから適用インスタンスのフェイルオーバーを開始するまでの期間です。適切なタイムアウト値を選択するには、次のことを考慮する必要があります。

- クラスタに、障害が発生した適用インスタンスのリカバリを試みる他のメカニズムがあるかどうか(Oracle Clusterwareなど)。

- ビジネスで、REDOデータがスタンバイ・データベースに適用されないことを容認できる時間。

- ログ適用サービスを他のインスタンスに移動する操作に関連するオーバーヘッド。オーバーヘッドには、障害の発生した適用インスタンス上に累積されていて未適用のログ・ファイルすべてが、他のスタンバイ・インスタンスからアクセスできる共有ファイル・システムに保存されていない場合に、それをプライマリ・データベースから再転送する操作が含まれる場合があります。

ブローカのApplyInstanceTimeoutプロパティのデフォルト値は0秒です。これは、現在の適用インスタンスの障害検出後ただちに、適用インスタンスのフェイルオーバーが開始されることを示しています。

ブローカでは、適用インスタンスのフェイルオーバー開始後に、次のルールに従って新規の適用インスタンスが選択されます。PreferredApplyInstanceプロパティが現在実行中のインスタンスを示している場合は、それが新規の適用インスタンスとして選択されます。それ以外の場合は、現在実行中の任意のインスタンスが新規の適用インスタンスとして選択されます。

また、適用インスタンスの障害発生時にフィジカル・スタンバイ・データベースがリアルタイム問合せモードで動作していた場合、Oracleリカバリ・クリーンアップの完了後、自動的にクローズされたインスタンスはすべてブローカによってオープンされます。障害の発生した適用インスタンスが唯一のオープン・インスタンスであった場合、リアルタイム問合せを再度有効にするため、適用サービスを開始する前に、新しい適用インスタンスとして選択されたインスタンスがオープンされます。

参照:

- リアルタイム問合せモードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

- Oracle Active Data GuardのOracle RACスタンバイにおける適用インスタンス障害の詳細は、http://support.oracle.comにあるMy Oracle Supportノート1357597.1を参照してください。

4.5.6 適用ラグ

適用ラグは、REDOのスタンバイ・データベースへの伝播および適用の遅延により、スタンバイ・データベースのデータがプライマリ・データベースのデータからどの程度遅れているかを測定する尺度です。

Cloud ControlとDGMGRLクライアントのいずれでも、管理対象スタンバイ・データベースごとに適用ラグが表示されます。Cloud Controlでは、Oracle Data Guardホームページに適用ラグが表示されます。DGMGRLクライアントでは、スタンバイ・データベースのSHOW DATABASE出力に適用ラグが表示されます。プライマリ・データベースに対する適用ラグは表示されません。次に例を示します。

show database 'South_Sales';
Database - South_Sales

Role:            PHYSICAL STANDBY
Intended State:  APPLY-ON
Transport Lag:   0 seconds (computed 0 seconds ago)
Apply Lag:       0 seconds (computed 0 seconds ago)
Apply Rate:      255.00 KByte/s
Real Time Query: OFF
Instance(s):
south_sales1

Database Status:
SUCCESS

適用ラグでは、REDO転送サービスとログ適用サービスで発生する可能性のある問題を識別することができます。

構成可能なデータベース・プロパティApplyLagThresholdを設定すると、スタンバイ・データベースがプライマリ・データベースのデータに遅れを取る場合にヘルス・チェック警告を生成することができます。

次のコマンドは、ApplyLagThresholdプロパティを15秒に設定します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'ApplyLagThreshold'=15;
Property ApplyLagThreshold updated

4.6 データ保護モードの管理

ブローカによって、様々なレベルのデータ保護(最大保護、最大可用性、最大パフォーマンス)に対する構成の設定処理を簡素化できます。

この項では、構成の適切な保護に役立つ項目について説明します。

- 構成に対する保護モードの設定

- 保護モードによるブローカ操作への影響

4.6.1 構成に対する保護モードの設定

構成の保護モードを設定するには、次の手順を実行します。

- 保護モードの設定(タスク1): 使用するデータ保護モードの決定

- 保護モードの設定(タスク2): スタンバイREDOログ・ファイルの設定

- 保護モードの設定(タスク3): REDO転送モードの設定

- 保護モードの設定(タスク4): DGMGRLまたはCloud Controlの使用

4.6.1.1 保護モードの設定(タスク1): 使用するデータ保護モードの決定

各データ保護モードでは、データ保護、データ可用性およびデータベース・パフォーマンスが様々なバランスで提供されます。ビジネス・ニーズに合うデータ保護モードを選択するには、データ保護の要件とユーザーが要求するパフォーマンスを慎重に考慮します。

注意:

最大保護モードは、次の状況では使用できません。

- 構成の唯一のスタンバイ・データベースがスナップショット・スタンバイである場合

- 遠隔同期インスタンスが、プライマリ・データベースから同期モードでREDOを受け取っている唯一の構成メンバーである場合

最大可用性

この保護モードは、プライマリ・データベースの可用性を低下させない範囲で可能な最高レベルのデータ保護を提供します。トランザクションのリカバリに必要なすべてのREDOデータがオンラインREDOログと1つ以上の同期スタンバイ・データベース上のスタンバイREDOログに書き込まれるまで、トランザクションはコミットされません。1つ以上の同期スタンバイ・データベースにREDOストリームを書き込めない場合、プライマリ・データベースは最大パフォーマンス・モードの場合と同様に動作して、同期スタンバイ・データベースへのREDOストリームの書込みが再び可能になるまでプライマリ・データベースの可用性を維持します。

このモードでは、プライマリ・データベースの障害発生時に、第2の障害が発生してもプライマリ・データベースから1つ以上のスタンバイ・データベースにREDOデータの完全なセットを送信できるときにのみ、データが消失しないことが保証されます。

保護モードが最大可用性の場合、ファスト・スタート・フェイルオーバーを有効化できます。

最大パフォーマンス

この保護モードは、プライマリ・データベースのパフォーマンスに影響しない範囲で可能な最高レベルのデータ保護を提供します。これを実現するため、トランザクションで生成されたすべてのREDOデータがオンライン・ログに書き込まれると、トランザクションをすぐにコミットできます。REDOデータは1つ以上のスタンバイ・データベースにも書き込まれますが、この書込みはトランザクションのコミットとは非同期に実行されるため、スタンバイ・データベースへのREDOデータの書込みの遅延は、プライマリ・データベースのパフォーマンスに影響を与えません。

最大可用性モードと比較して、この保護モードではデータ保護が若干弱くなり、プライマリ・データベースのパフォーマンスへの影響を最小限に抑えます。

これはデフォルトの保護モードです。

保護モードが最大パフォーマンスの場合、ファスト・スタート・フェイルオーバーを有効化できます。

最大保護

この保護モードは、プライマリ・データベースに障害が発生した場合でも、データ消失がないことを保証します。この保護レベルを提供するには、トランザクションのコミット前に、トランザクションのリカバリに必要なREDOデータを、オンラインREDOログと1つ以上の同期スタンバイ・データベース上のスタンバイREDOログに書き込む必要があります。データの消失が起こり得ないようにするため、1つ以上の同期スタンバイ・データベースにREDOストリームを書き込めない場合、プライマリ・データベースは停止し、トランザクション処理を継続しません。

Oracle Data GuardがREDOデータをスタンバイREDOログ・ファイルの永久記憶域に書き込むとすぐに、プライマリのトランザクションは保護されたものとみなされます。その後すぐにプライマリ・データベースに確認通知を戻し、次のトランザクションに進めるようにします。これによって、プライマリ・データベースでの同期転送スループットやレスポンス時間による影響を最小化できます。スタンバイ・データベースでの完全なOracle Data Guardの検証機能を最大限活用するには、必ずリアルタイムの適用モードで操作し、REDOの変更を受信と同時にスタンバイ・データベースに適用します。Oracle Data Guardは検出したすべての破損を通知するので、迅速な修正処理を実行できます。

このデータ保護モードでは、プライマリ・データベースの可用性よりもデータ保護を優先するため、単一のスタンバイ・データベースの障害によってプライマリ・データベースが停止しないように、少なくとも2つのスタンバイ・データベースを使用して最大保護モードで実行するプライマリ・データベースを保護することをお薦めします。1つのスタンバイ・データベースのみが最大保護モードをサポートしている場合、Oracle Data Guard Brokerは適用インスタンスのシャットダウンを禁止します。これによりプライマリ・データベースはシャットダウンされなくなります。

保護モードが最大保護の場合、ファスト・スタート・フェイルオーバーを有効化できません。

参照:

- ファスト・スタート・フェイルオーバーの詳細は、「ファスト・スタート・フェイルオーバー」を参照

- データ保護モードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

4.6.1.2 保護モードの設定(タスク2): スタンバイREDOログ・ファイルの設定

使用している保護モードに関係なく、スタンバイREDOログ・ファイルをすべてのスタンバイ・データベースに追加する必要があります。また、スイッチオーバーやフェイルオーバーに備えてプライマリ・データベース上にもスタンバイREDOログ・ファイルを追加する必要があります。ファスト・スタート・フェイルオーバーを有効にする場合は、プライマリ・データベース上にスタンバイREDOログ・ファイルが必要です。

Cloud Controlでは、構成内の1つ以上のスタンバイ・データベースを選択するように要求され、将来のロール変更に備えて、スタンバイ・データベースおよびプライマリ・データベース上にスタンバイREDOログ(SRL)ファイルが設定されます。

参照:

DGMGRLコマンドライン・インタフェースを使用する場合は、スタンバイREDOログ・ファイルを構成する際に、『Oracle Data Guard概要および管理』の指示に従ってください。

4.6.1.3 保護モードの設定(タスク3): REDO転送モードの設定

データ保護モードによって、スタンバイ・データベースのいずれかが使用しているREDO転送モードの変更が必要になる場合、各スタンバイ・データベース上でLogXptModeデータベース・プロパティを変更するか、プライマリ・データベース上、またはスタンバイ・データベースに直接接続している遠隔同期インスタンス上で、RedoRoutesプロパティを設定します。REDO転送サービスの設定の詳細は、「REDO転送サービスの管理」を参照してください。表4-2では、保護モードおよび対応するREDO転送サービスを示します。

Cloud Controlでは自動的に、将来のスイッチオーバーに備えて、プライマリ・データベース上に適切なREDO転送サービスが設定されます。

表4-2 Oracle Data Guard保護モードと要件

保護モード

REDO転送

スタンバイREDOログ・ファイルの要否

ファスト・スタート・フェイルオーバーとの併用

MAXPROTECTION

SYNC

必要

いいえ

MAXAVAILABILITY

SYNC、FASTSYNC

必要

あり脚注1

MAXPERFORMANCE

ASYNC

必要

はい

脚注1

FASTSYNC転送モードはLOG_ARCHIVE_DEST_nパラメータのNOAFFIRM属性を使用するため、データが失われる可能性があります。FASTSYNCを使用していて、スタンバイにREDOデータがない場合、ファスト・スタート・フェイルオーバーを開始できません。

4.6.1.4 保護モードの設定(タスク4): DGMGRLまたはCloud Controlの使用

DGMGRLコマンドまたはCloud Controlを使用した保護モードの設定

DGMGRLを使用する場合

1. EDIT DATABASE(プロパティ)コマンドを使用して、設定する保護モードに対応するようにREDO転送サービスを変更する必要のあるスタンバイ・データベースを指定します。たとえば、Oracle Data Guard構成全体を最大可用性モードで動作するように設定する場合は、EDIT DATABASEコマンドを使用して、REDO転送サービスに対してSYNCモードを設定する必要があります。次に例を示します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY LogXptMode='SYNC';

この確認を構成内のプライマリ・データベースまたは他のスタンバイ・データベースについても行い、選択した保護モードをスイッチオーバー後もサポートできることを確認します。

次のように、RedoRoutesプロパティを使用することもできます。

EDIT DATABASE 'North_Sales' SET PROPERTY RedoRoutes = '(LOCAL : South_Sales SYNC)';

2. EDIT CONFIGURATION SET PROTECTION MODE AS protection-modeコマンドを使用して、構成全体の保護モードを設定します。次に例を示します。

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

保護モードの設定方法を示すDGMGRLの使用例については、「使用例4: 構成保護モードの設定」を参照してください。

Cloud Controlで、次の手順を実行します。

1. Oracle Data Guardの概要ページで、「保護モード」ラベルの右にあるリンクをクリックします。

2. 「最大保護」、「最大可用性」または「最大パフォーマンス」を選択して「続行」をクリックします。

3. プロンプトが表示される場合は、SYSDGまたはSYSDBA権限でデータベースにログインして「ログイン」をクリックします。

4. 選択した保護モードをサポートする1つ以上のスタンバイ・データベースを選択します。スタンバイREDOログ・ファイルが必要な場合は、ログ・ファイル名を確認します。「OK」をクリックします。

5. 「確認」ページで「はい」をクリックします。

最大保護モードにアップグレードする場合、DGMGRLまたはCloud Controlを使用して保護モードを最大パフォーマンス・モードから最大保護モードにアップグレードすると、プライマリ・データベースは自動的に再起動されます。保護モードをダウングレードした後でプライマリ・データベースを再起動する必要はありません。

保護モードを最大パフォーマンスから最大可用性に、または最大可用性から最大保護にアップグレードする場合、再起動は不要です。

注意:

最大パフォーマンス・モードから最大保護モードにアップグレードする際、まず最大可用性モードにアップグレードすることで、プライマリ・データベースの再起動を回避できます。最大可用性モードにしたら、次に最大保護モードにアップグレードします。

注意:

Oracle RAC One Nodeのオンライン・データベース再配置は、最大保護モードをサポートするフィジカル・スタンバイ・データベースのみで実行することはできません。

オンライン・データベース再配置を実行する必要がある場合、まず、保護モードを最大可用性にダウングレードします。フィジカル・スタンバイ・データベースのオンライン・データベース再配置を実行した後で、保護モードを最大保護にアップグレードすることができます。プライマリ・データベースの再起動は必要ありません。

4.6.2 保護モードによるブローカ操作への影響

この項では、スイッチオーバー、フェイルオーバー、Oracle Data Guard構成の無効化または有効化などの操作が、構成の保護モードやREDO転送サービスに与える影響について説明します。この項の内容は、次のとおりです。

- 現在の保護モードのアップグレードまたはダウングレード

- スイッチオーバー操作

- フェイルオーバー操作

- 無効化操作と有効化操作

- 構成からデータベースを削除する際の要件

- その他の操作要件

4.6.2.1 現在の保護モードのアップグレードまたはダウングレード

現在のOracle Data Guard保護モードを最大可用性モードにアップグレードする場合または現在のOracle Data Guard保護モードをダウングレードする場合、再起動は不要です。Oracle Data Guard保護モードのアップグレード時またはダウングレード時には、次の推奨事項に従ってください。

- 保護モードをアップグレードするときは、全体の保護モードをアップグレードする前にREDO転送サービスをアップグレードします。保護モードの変更時やスタンバイ・データベースのREDO転送サービスのリセット時に、ブローカは、必要なレベルの保護をサポートできるスタンバイ・データベースが構成内に少なくとも1つ存在していることを確認します。この条件が満たされない場合、保護モードは変更されず、エラーが戻されます。

- 保護モードをダウングレードするときは、最初に保護モードをダウングレードしてから、REDO転送サービスを変更します(必要な場合)。REDO転送サービスの変更によって現在の全体の保護モードが無効になる場合、ブローカはREDO転送サービスの変更を許可しません。

最大パフォーマンス・モードから保護モードをアップグレードする場合、ブローカは、直接、または、遠隔同期インスタンスを介して、SYNC転送を使用してREDOを受け取るスタンバイ・データベースが少なくとも1つあることを確認します。また、最大保護モードへのアップグレードの場合、ブローカは、スタンバイ・データベースのREDOデータにギャップがないことを確認します。これらの要件を満たすスタンバイ・データベースが構成内に存在していない場合、保護モードのアップグレード要求はエラーとなり拒否されます。

ファスト・スタート・フェイルオーバーが有効化されても、保護モードは変更されません。

警告:

保護モードを最大パフォーマンスから最大保護にアップグレードすると、プライマリ・データベースは、停止され再起動されます。まず最大可用性にアップグレードすると、この動作を回避できます。最大可用性モードにしたら、次に最大保護モードにアップグレードします。

4.6.2.2 スイッチオーバー操作

スイッチオーバーでは、全体のOracle Data Guard保護モードは変更されません。保護モードはスイッチオーバー前と同じです。

スイッチオーバーの完了後に現在の保護モードをサポートするために、適切に構成されているスタンバイ・データベースが必要です。これは、構成内の他のスタンバイ・データベースでも、スイッチオーバー完了後にスタンバイ・データベースとなる現行のプライマリ・データベースでもかまいません。

必要な場合は、スイッチオーバーを起動する前に、現行のプライマリ・データベース上または構成内の他のスタンバイ・データベース上に、スタンバイREDOログ・ファイルを追加して、REDO転送サービスをOracle Data Guard保護モードのサポートに必要な転送モードに設定できます。その後スイッチオーバーが開始されると、次の処理が実行されます。

- ブローカでは、各スタンバイ・データベース上と現行のプライマリ・データベース上で、スタンバイREDOログ・ファイルが存在することとREDO転送サービスの設定が検証されます。

- ブローカは、ターゲット・スタンバイ・データベースに存在するREDOデータに差分がないことを検証します。

検証が正常終了した場合は、スイッチオーバーが続行されます。正常終了しなかった場合、スイッチオーバーは失敗し、データベース・ロールとブローカ構成ファイルは変更されません。

警告:

- スイッチオーバーのターゲットがフィジカル・スタンバイ・データベースの場合、ブローカはシャットダウンして、プライマリ・データベースを再起動します。

- 構成された保護モードが最大保護モードで、そのモードをサポートするスタンバイが1つしかない場合、スイッチオーバーが実行されると、プライマリとスタンバイの両方が再起動されます。

参照:

スイッチオーバーの詳細は、「スイッチオーバー」を参照

4.6.2.3 フェイルオーバー操作

保護モードが最大保護だった場合、手動フェイルオーバーを実行した後に、Oracle Data Guard保護モードが最大パフォーマンス・モードにダウングレードされます。必要な場合、保護モードは後でアップグレードできます。保護モードが最大可用性または最大パフォーマンスだった場合は、変更されません。スタンバイ・データベースのREDO転送サービスは変更されません。

ファスト・スタート・フェイルオーバーが実行された場合、ブローカにより、フェイルオーバー前に有効になっていた保護モードが保持されます。

参照:

手動フェイルオーバーおよびファスト・スタート・フェイルオーバーの詳細はそれぞれ、「手動フェイルオーバー」および「ファスト・スタート・フェイルオーバー」を参照

4.6.2.4 無効化操作と有効化操作

あるスタンバイ・データベースのブローカ管理を無効化すると、ブローカによって、残りのスタンバイ・データベースのいずれかが、全体の保護モードの要件を引き続き満たしているかがチェックされます。この条件が満たされない場合、無効化操作はブローカによって拒否されます。この条件が満たされる場合は、ファスト・スタート・フェイルオーバーが有効化されていないかぎり、無効化操作は続行されます。ファスト・スタート・フェイルオーバーが有効化されている場合でも、そのスタンバイ・データベースが、ファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースでなければ、無効化操作は続行されます。

警告:

ブローカ構成内のスタンバイ・データベースに関してブローカによる管理を無効化すると、プライマリ・データベースが消失した場合にも、そのスタンバイ・データベースはブローカでフェイルオーバー・ターゲットとして使用できなくなります。

スタンバイ・データベースが正常に無効化された後は、そのデータベースのREDO転送サービスを変更できます。変更内容は、ブローカによってブローカ構成ファイルに記録されます。この変更が全体の保護モードに影響を与えることはありません。これは、有効なスタンバイ・データベースの少なくとも1つが、全体の保護モード要件をすでに満たしているためです。

ファスト・スタート・フェイルオーバーが有効化されていないかぎり、構成全体は保護モードに関係なく無効化できます。ファスト・スタート・フェイルオーバーが有効化されている場合は、構成を無効にできません。詳細は、「ファスト・スタート・フェイルオーバーが有効化されている場合の制限事項」を参照してください。

構成全体が無効な場合は、スタンバイ・データベースのREDO転送サービスや構成の保護モードなどのブローカの設定を変更できます。ブローカはブローカ構成ファイルに変更を保存しますが、データベース自体には変更は行われません。

構成全体のブローカ管理を有効化するときは、ブローカによって、有効化されるスタンバイ・データベースのREDO転送サービスが保護モードの要件を満たしているかどうかが最初にチェックされます。この条件が満たされていない場合、有効化操作は失敗し、構成は無効のままになります。条件が満たされている場合は、有効化操作によって構成が正常に有効化され、ブローカは、ブローカ構成ファイルに保存されている設定を使用してデータベースを有効化します。

4.6.2.5 構成からデータベースを削除する際の要件

ブローカ構成からスタンバイ・データベースを削除するときは、ブローカによって、保護モードの要件が満たされているかどうかがチェックされます。次の場合、操作は失敗します。

- そのデータベースの削除により保護モードに影響がある場合

- ファスト・スタート・フェイルオーバーが有効化されているのに、ファスト・スタート・フェイルオーバーのターゲットとなるスタンバイ・データベースを削除しようとした場合

- 削除する構成メンバーの構成可能なプロパティRedoRoutesがNullでない値に設定されている場合

ファスト・スタート・フェイルオーバーが有効化されていない場合は、いつでも構成を削除できます。

4.6.2.6 その他の操作要件

ブローカ構成で行われる一部の操作、特にREDO転送サービスに関連する操作は、全体の保護モードに影響を与える場合があります。次のような操作があります。

- プライマリ・データベースのREDO転送サービスを停止する操作

- 個々のスタンバイ・データベースへのREDO転送サービスを停止する操作

- 最大可用性モードまたは最大保護モードで動作している構成をサポートする唯一のスタンバイ・データベースで、REDO転送モードをSYNCからASYNCにダウングレードする操作

これらの操作の前には、ブローカによって、操作完了後にスタンバイ・データベースのREDO転送モード設定が保護モードをサポートするかどうかがチェックされます。この条件が満たされていない場合、操作は失敗し、エラーが戻されます。

4.7 遠隔同期インスタンスの管理

Oracle Data Guard遠隔同期インスタンスは、プライマリ・データベースからREDOを受け取るREDO転送先で、そのREDOを構成内の1つ以上のREDO接続先に転送します。それは制御ファイルを持つ点でフィジカル・スタンバイ・データベースに類似しており、REDOをスタンバイREDOログ・ファイル(SRL)に受信し、それらのSRLをローカルのアーカイブREDOログ(ARL)にアーカイブします。しかしスタンバイ・データベースとは異なり、遠隔同期インスタンスにはデータ・ファイルがなく、オープンすることもできず、受け取ったREDOを適用することもできません。これらの制限のために、ディスクと処理リソースの使用量が少なくなる利点があります。より重要なこととして、遠隔同期インスタンスは、同期転送モードを使用してREDOデータを受け取り、構成保護モードが最大可用性に設定されている場合、データ損失なしでターミナル・データベースにフェイルオーバーすることができます。

次の例は、ブローカ構成に遠隔同期インスタンスを追加する方法を示します。

DGMGRL> ADD FAR_SYNC FS1 AS CONNECT IDENTIFIER IS FS1.example.com;
Far Sync FS1 added
DGMGRL> ENABLE FAR_SYNC FS1;
Enabled.
DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
FS1        - Far Sync
South_Sales - Physical standby database

Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

遠隔同期インスタンスが構成に追加された後、REDO転送を設定して最大可用性をサポートし、その後で保護モードを次のようにアップグレードします。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : FS1 SYNC)';
DGMGRL> EDIT FAR_SYNC 'FS1' SET PROPERTY 'RedoRoutes' = '(North_Sales : South_Sales ASYNC)';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
North_Sales  - Primary database
FS1          - Far Sync
South_Sales - Physical standby database

Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

South_Salesがプライマリ・データベースの場合に、最大可用性保護モードを保持できるようにするには、スイッチオーバーまたはフェイルオーバー後に、2番目の遠隔同期インスタンスを構成に追加して、South_SalesがREDOを同期モードで送信できるようにし、ロール遷移後に新しいターミナル・データベースのNorth_Sales,にREDOが送信されるようにします。

次の例は、ブローカ構成に2番目の遠隔同期インスタンスを追加する方法を示します。

DGMGRL> ADD FAR_SYNC FS2 AS CONNECT IDENTIFIER IS FS2.example.com;
Far Sync FS2 added
DGMGRL> EDIT FAR_SYNC 'FS2' SET PROPERTY 'RedoRoutes' = '(South_Sales : North_Sales ASYNC)';
DGMGRL> ENABLE FAR_SYNC FS2;
Enabled.
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : FS2 SYNC)';
DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
North_Sales  - Primary database
FS1          - Far Sync
South_Sales - Physical standby database
FS2         - Far Sync (inactive)

Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

遠隔同期インスタンスの可用性が、(たとえばOracle Restart、Oracle Real Application Clusters (Oracle RAC)またはOracle RAC One Nodeのインストールにおいて) Oracle Clusterwareによって監視されている場合、SRVCTLユーティリティを使用して、デフォルトのオープン・マウント・モードを指定します。次のようなコマンドを使用できます。

srvctl modify database -d <db_unique_name> -startoption MOUNT

参照:

- 遠隔同期インスタンスの作成およびREDO転送の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- olink:ADMIN-GUID-79B9EC11-9711-424F-94D1-6B0EFCF77173『Oracle Database管理者ガイド』

4.8 ファスト・スタート・フェイルオーバーの管理

完全自動管理の場合、ファスト・スタート・フェイルオーバーを有効にすると、ブローカによるフェイルオーバーの必要性の判断と、事前に指定されたターゲット・スタンバイ・データベースへのフェイルオーバーの開始が可能になります。これに伴うデータの消失はない場合と、構成可能なデータ量を消失する場合があります。また、フェイルオーバーが開始される条件やエラーも指定できます。DBMS_DG PL/SQLパッケージを使用すると、アプリケーションでファスト・スタート・フェイルオーバーを要求できます。

ブローカ構成プロパティを使用して、ファスト・スタート・フェイルオーバーの動作を制御します。また、Cloud ControlまたはDGMGRLのENABLE FAST_START FAILOVER CONDITIONコマンドおよびDISABLE FAST_START FAILOVER CONDITIONコマンドを使用して、ファスト・スタート・フェイルオーバーが実行される条件を指定することもできます。

4.8.1 ファスト・スタート・フェイルオーバーをチューニングするプロパティの構成

ファスト・スタート・フェイルオーバーに関する構成可能なプロパティは、次のとおりです。

- FastStartFailoverThreshold
FastStartFailoverThreshold構成プロパティを設定して、(プライマリ・データベースが使用できないことが検出されてから)フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。詳細および例は、「ファスト・スタート・フェイルオーバーの有効化」を参照してください。

- FastStartFailoverPmyShutdown
FastStartFailoverPmyShutdown構成プロパティは、REDOの生成が停止され(V$DATABASEのFS_FAILOVER_STATUS列の値がSTALLED)、オブザーバおよびターゲット・スタンバイ・データベースとの接続が失われてから経過した時間がFastStartFailoverThreshold構成プロパティに指定された秒数を超過した場合、プライマリ・データベースを停止するかどうかを制御します。FastStartFailoverPmyShutdownのデフォルト値はTRUEです。

注意:

ユーザーによる構成可能な条件が検出された場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーが開始された場合、プライマリ・データベースは常に停止します。

- FastStartFailoverLagLimit
ファスト・スタート・フェイルオーバー機能は、最大パフォーマンス・モードで動作するデータベースで構成できます。ASYNCモードでREDOを受け取る宛先は、許容可能なファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースであり、これらの宛先はREDOの受取りおよび適用に関してプライマリより遅れる可能性があります。FastStartFailoverLagLimit構成プロパティを使用して、構成可能な時間ベースの制限を指定できます。スタンバイ・データベースでREDOが適用された時点がプライマリのREDO生成時点からこの秒数以内であれば、ファスト・スタート・フェイルオーバーが許可されます。適用時点がこの制限よりも遅れていると、ファスト・スタート・フェイルオーバーは許可されません。FastStartFailoverLagLimit構成プロパティは、構成が最大可用性モードで動作しているときに、ファスト・スタート・フェイルオーバーが有効化されている場合は使用されません。ASYNC宛先は、最大パフォーマンス・モードで動作している構成でのみ有効なファスト・スタート・フェイルオーバー・ターゲットです。保護モードを変更したり宛先をSYNCに変更する場合は、まず、ファスト・スタート・フェイルオーバーを無効化する必要があります。同様に、MAXAVAILABILITYからMAXPERFORMANCEに保護モードを変更する場合も、ファスト・スタート・フェイルオーバーを無効にしてから、REDOをプライマリとターゲット・スタンバイに送信するのに使用するREDO転送モードをASYNCに変更する必要があります。元のプライマリの回復は、ASYNCターゲット・スタンバイへのファスト・スタート・フェイルオーバー後に可能になります。オブザーバは元のプライマリを再検出すると、自動的に元のプライマリを回復し、指定されたラグ以内で生成されたすべてのREDOが失われます。

参照:

詳細は、「Oracle Data Guard Brokerのプロパティ」を参照

- FastStartFailoverAutoReinstate
FastStartFailoverAutoReinstate構成プロパティは、プライマリ・データベースがクラッシュしたか、FastStartFailoverThresholdの秒数を超えて停止したためにファスト・スタート・フェイルオーバーが発生した場合、元のプライマリ・データベースを自動的に回復するかどうかを制御します。FastStartFailoverAutoReinstateのデフォルト値はTRUEです。

フェイルオーバーの完了後に診断または修復作業を行う場合は、FastStartFailoverAutoReinstate構成プロパティをFALSEに設定すると、自動回復を回避できます。

注意:

ユーザーによる構成可能なファスト・スタート・フェイルオーバー条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを開始した場合、元のプライマリ・データベースの自動回復は実行されません。

- FastStartFailoverTarget
FastStartFailoverTarget構成プロパティは、このデータベースがプライマリ・データベースの場合、ファスト・スタート・フェイルオーバーのターゲットになるデータベースのDB_UNIQUE_NAMEを指定します。

- ObserverReconnect
ObserverReconnect構成プロパティは、オブザーバがプライマリ・データベースに対して新しい接続を確立する頻度を指定します。このプロパティがデフォルト値の0に設定されている場合、オブザーバはプライマリ・データベースへの新しい接続を定期的に確立しません。これによりプライマリ・データベースに新しいオブザーバ接続を定期的に確立することによる処理オーバーヘッドがなくなる一方、オブザーバがプライマリ・データベースに新しい接続を作成できないことを検出できなくなります。このプロパティは、プライマリ・データベースの障害を適時に検出できる程度には小さいが、定期的なオブザーバ接続によるオーバーヘッドが許容できるレベルに収まる程度には大きい値に設定することをお薦めします。

- ObserverOverride
ObserverOverride構成プロパティをTRUEに設定すると、スタンバイがプライマリに正常に接続していても、オブザーバのプライマリへの接続が失われた場合、自動フェイルオーバーが発生します。

4.8.2 ファスト・スタート・フェイルオーバーの条件の構成

デフォルトでは、構成済の時間しきい値(FastStartFailoverThreshold)の経過後にオブザーバもスタンバイもプライマリにアクセスできないと、ファスト・スタート・フェイルオーバーが実行されます。また、別の条件でファスト・スタート・フェイルオーバーを実行する必要がある場合もあります。

構成可能な条件は、データベースの健全性チェック・メカニズムによって検出されるものとOracleサーバーで発生するエラー(ORAエラーなど)によって検出されるものの2種類に分類されます。指定された条件が発生すると、オブザーバは、スタンバイがフェイルオーバーを受け入れるために適した状態であれば、FastStartFailoverThresholdを超えるまで待機せずにファスト・スタート・フェイルオーバーを開始します。

各条件は、個別に有効化または無効化できます。Oracle Data Guard構成では、ユーザー指定のすべての構成可能なファスト・スタート・フェイルオーバー条件がブローカ構成ファイルに保持されます。

プライマリ・データベースが有効な健全性チェック条件のいずれかを示すと、オブザーバによって検出され、スタンバイがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)ただちにファスト・スタート・フェイルオーバーが開始されます。

Oracle ORAエラー条件が指定されている場合、エラーが示されるとプライマリ・データベースがオブザーバに通知し、オブザーバは、スタンバイがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)ただちにファスト・スタート・フェイルオーバーを開始します。

注意:

プライマリ・データベースは停止し、オブザーバは元のプライマリ・データベースの自動回復を試行しません。

参照:

- Cloud Controlオンライン・ヘルプ

- ENABLE FAST_START FAILOVER CONDITION

- DISABLE FAST_START FAILOVER CONDITION

4.8.3 アプリケーションによるファスト・スタート・フェイルオーバーの開始

DBMS_DG PL/SQLパッケージを使用して、特定の条件が満たされたときにアプリケーションによりファスト・スタート・フェイルオーバーを指示することができます。「アプリケーションによるファスト・スタート・フェイルオーバーの指示」を参照してください。

4.9 データベース変換の管理

DGMGRLのCONVERT DATABASEコマンドを使用すると、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換できます。スナップショット・スタンバイ・データベースは完全に更新可能なスタンバイ・データベースです。

フィジカルまたはロジカル・スタンバイ・データベースと同様に、スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信し、アーカイブします。ただし、フィジカルまたはロジカル・スタンバイ・データベースとは異なり、スナップショット・スタンバイ・データベースは、受信したREDOデータを適用しません。スナップショット・スタンバイ・データベースが受信したREDOデータは、スナップショット・スタンバイが元のフィジカル・スタンバイ・データベースに変換され、スナップショット・スタンバイ・データベースに対するすべてのローカルな更新が破棄された後に適用されます。

フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換するには、フラッシュバック・データベースを有効にする必要があります。次の例に、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換する方法を示します。

DGMGRL> CONVERT DATABASE 'South_Sales' TO SNAPSHOT STANDBY;

スナップショットを元のフィジカル・スタンバイに戻すときは、次に示すように、DGMGRLのCONVERT DATABASEコマンドを使用します。

DGMGRL> CONVERT DATABASE 'South_Sales' TO PHYSICAL STANDBY;

4.10 データベースのステータス

データベースのステータスは、データベースの健全性を示します。通常、ブローカは、実際のデータベースの状態と設定がブローカ構成ファイル内の記述と一致するかどうかを検証し、データベースの健全性をチェックします。そのためには、Oracle Data Guard構成のコンポーネントで正常に機能していないものがないかどうか(REDO転送サービスにエラーがないかどうかなど)、その他の必須のデータベースの設定が正しく行われているかどうか(サーバー・パラメータ・ファイルが使用可能かどうか、ARCHIVELOGモードがオンになっているかどうかなど)をチェックします。ここでは、ブローカによりプライマリ・データベース上とスタンバイ・データベース上でチェックされる項目を詳しく説明します。

プライマリ・データベースの健全性チェックでは、次の条件が満たされているかどうかを判別します。

- データベースが、ユーザーが指定してブローカ構成ファイルに記録された状態であるかどうか。

- データベースが正しいデータ保護モードであるかどうか。

- データベースでサーバー・パラメータ・ファイルが使用されているかどうか。

- データベースがARCHIVELOGモードであるかどうか。

- データベース・ガードがオフになっているかどうか。

- 補助ロギングがオンになっているかどうか(構成にロジカル・スタンバイ・データベースが含まれている場合)。

- REDO転送サービスにエラーがあるかどうか。

- データベース設定が、ブローカの構成可能なプロパティで指定された設定と一致しているかどうか。

- REDO転送設定が、スタンバイ・データベースのREDO転送関連プロパティで指定された設定と一致しているかどうか。

- 現行のデータ保護レベルが構成済のデータ保護モードと一致しているかどうか。

- プライマリ・データベースで、すべてのスタンバイ・データベースのすべてのギャップを解決できるかどうか。

スタンバイ・データベースの健全性チェックでは、次の条件が満たされているかどうかを判別します。

- データベースが、ユーザーが指定してブローカ構成ファイルに記録された状態であるかどうか。

- データベースでサーバー・パラメータ・ファイルが使用されているかどうか。

- データベース設定が、ブローカの構成可能なプロパティで指定された設定と一致しているかどうか。

- データベース・ガードがオンになっているかどうか(データベースがロジカル・スタンバイ・データベースの場合)。

- ファスト・スタート・フェイルオーバーが有効化されている場合は、プライマリ・データベースおよびターゲット・スタンバイ・データベースが同期化されているかどうか、またはラグ制限内であるかどうか。

4.10.1 データベース・ステータスの問合せ

ステータスの問合せには、次の監視可能なデータベース・プロパティを使用できます。

- LogXptStatus

- InconsistentProperties

- InconsistentLogXptProps

注意:

これらのプロパティには、DGMGRLコマンドライン・インタフェースを介して直接アクセスします。Cloud Controlでは、GUIで表示するためにこれらのプロパティの値が並べ替えられます。

SHOW DATABASE <db_unique_name>コマンドを使用して、データベースの簡単な説明(名前、ロールなど)、データベースの状態、および健全性チェックの問題に関する情報を入手できます。たとえば、次のSHOW DATABASEコマンドの出力は、一部のREDO転送サービス・エラーおよびREDO転送関連プロパティの不一致という2つの問題を示しています。

DGMGRL> SHOW DATABASE 'North_Sales';

Database - North_Sales
Role: PRIMARY
Intended State: TRANSPORT-OFF
Instance(s):
north_sales1
Error: ORA-16737: the redo transport service for standby
database "South_Sales" has an error

north_sales2
Error: ORA-16737: the redo transport service for standby
database "South_Sales" has an error
Warning: ORA-16715: redo transport-related property
ReopenSecs of standby "South_Sales" is inconsistent
Database Status:
ERROR

データベース・ステータスの詳細をさらにチェックするには、監視可能なプロパティLogXptStatus、InconsistentPropertiesおよびInconsistentLogXptPropsを使用できます。LogXptStatusを使用すると、プライマリ・データベースの全インスタンス上で検出されたログ転送エラーがすべて表示されます。InconsistentPropertiesを使用すると、ブローカ構成ファイルとデータベース設定間で値が一致しないプロパティがすべて表示されます。InconsistentLogXptPropsを使用すると、ブローカ構成ファイルとREDO転送設定間で値が一致しない、スタンバイ・データベースのREDO転送関連プロパティがすべて表示されます。

次のSHOW DATABASEコマンドを発行して、問題の詳細を取得します。

DGMGRL> SHOW DATABASE 'North_Sales' 'LogXptStatus';
LOG TRANSPORT STATUS
PRIMARY_INSTANCE_NAME  STANDBY_DATABASE_NAME  STATUS
north_sales1            South_Sales  ORA-12541: TNS:no listener
north_sales2            South_Sales  ORA-12541: TNS:no listener

DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps';
INCONSISTENT LOG TRANSPORT PROPERTIES
INSTANCE_NAME  STANDBY_NAME  PROPERTY_NAME  MEMORY_VALUE  BROKER_VALUE
north_sales2   South_Sales     ReopenSecs           600           300

参照:

データベース・プロパティの詳細は、「Oracle Data Guard Brokerのプロパティ」を参照

4.10.2 ロール変更前のデータベース検証

VALIDATE DATABASEコマンドを使用して、ロール変更を実行する前に包括的なデータベース・チェックを実行できます。このコマンドは、次の項目を確認します。

- スタンバイ・データベースに、失われたREDOデータがあるかどうか

- フラッシュバックが有効かどうか

- 構成されている一時表領域ファイルの数

- オンライン・データ・ファイルの移動が進行中かどうか

- フィジカル・スタンバイ・データベースの場合、オンラインREDOログがクリアされているかどうか

- プライマリ・データベースの場合、スタンバイREDOログがクリアされているかどうか

- オンライン・ログ・ファイル構成

- スタンバイ・ログ・ファイル構成

- 適用関連のプロパティ設定

- 転送関連のプロパティ設定

- 自動診断リポジトリにエラーがあるかどうか(制御ファイルの破損、システム・データ・ファイルの問題、ユーザー・データ・ファイルの問題など)

参照:

- コマンドの説明や様々な使用例のコマンド出力の例示は、「VALIDATE DATABASE」を参照してください

5 スイッチオーバー操作とフェイルオーバー操作

次のトピックでは、ブローカによるスイッチオーバーおよびフェイルオーバー中のデータベースの管理方法について説明します。

- ブローカ環境でのスイッチオーバーおよびフェイルオーバーの概要

- ターゲット・スタンバイ・データベースの選択

- スイッチオーバー

- 手動フェイルオーバー

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

- データベース・クライアントに関する考慮事項

5.1 ブローカ環境でのスイッチオーバーおよびフェイルオーバーの概要

Oracleデータベースは、プライマリまたはスタンバイという2つのロールのいずれかで動作します。Oracle Data Guardにより、スイッチオーバーまたはフェイルオーバーのいずれかを使用してデータベースのロールを変更できます。

- スイッチオーバーとは、プライマリ・データベースとそのスタンバイ・データベースの1つとの間でロールを可逆的に推移させる操作です。スイッチオーバーでは、データの消失がないことが保証され、通常は予定されたプライマリ・システムのメンテナンスの際に実行されます。スイッチオーバー中は、プライマリ・データベースがスタンバイ・ロールに遷移し、スタンバイ・データベースがプライマリ・ロールに遷移します。

- フェイルオーバーは、プライマリ・データベース(Oracle RACデータベースの場合はすべてのインスタンス)に障害が発生するか、アクセス不能になった場合に、スタンバイ・データベースの1つがプライマリ・ロールに移行されるロール・トランジションです。フェイルオーバーでは、フェイルオーバー時に有効な保護モードによって、データが消失する場合としない場合があります。

ブローカを使用しない場合、ロール遷移を実行するには、一連のSQL文を発行します(『Oracle Data Guard概要および管理』を参照)。ブローカでは、Oracle Enterprise Manager Cloud Control (Cloud Control)でキーを1回クリックするか、DGMGRLコマンドライン・インタフェースで単一のコマンドを使用してスイッチオーバーおよびフェイルオーバーを起動できるため(このドキュメントでは手動フェイルオーバーと呼びます)、これらの操作が簡素化されます。また、ファスト・スタート・フェイルオーバーを有効化すると、ファスト・スタート・フェイルオーバーの条件が満たされたときに自動的にフェイルオーバーが実行されます。ファスト・スタート・フェイルオーバーが有効化されている場合、ブローカによってフェイルオーバーの必要性が判断され、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーが自動的に開始されます。DBAによる操作は不要です。

ファスト・スタート・フェイルオーバーにより、手動操作の必要性を少なくして可用性を高め、管理コストを削減できます。手動フェイルオーバーでは、フェイルオーバーを実行する正確なタイミングおよび対象となるターゲット・スタンバイ・データベースを管理できます。選択する方法に関係なく、ブローカによって構成内のすべてのデータベースのロール遷移が調整されます。

注意:

スイッチオーバーもフェイルオーバーも、遠隔同期インスタンスに対しては不可能です。

5.2 ターゲット・スタンバイ・データベースの選択

スイッチオーバーまたはフェイルオーバー後に次のプライマリ・データベースにするスタンバイ・データベースを選択する際には、多数の考慮事項があります。Oracle Data Guard構成を構築する際には、フィジカル・スタンバイ、ロジカル・スタンバイおよびスナップショット・スタンバイの各特性、スタンバイ・データベース・サイトに対するネットワーク待機時間、将来のプライマリ・データベース・サイトにおけるコンピューティング機能などの要素を含む、すべてのオプションを考慮する必要があります。

注意:

スナップショット・スタンバイを、スイッチオーバーまたはファスト・スタート・フェイルオーバー操作のターゲットにすることはできません。ただし、スナップショット・スタンバイへの手動フェイルオーバーは実行できます。

遠隔同期インスタンスはデータベースではなく、したがってロール遷移のターゲットにはなれません。

スイッチオーバーについては、すべての要素を理解することで、新規プライマリ・データベースとみなすスタンバイ・データベースを簡単に選択できます。フェイルオーバーが必要な障害が発生した場合、障害のあるプライマリ・データベースのアクティビティを再開するのに最適なスタンバイ・データベースは、スイッチオーバーの場合よりも絞られる可能性があります。「スイッチオーバーでのターゲット・スタンバイ・データベースの選択」と「フェイルオーバーでのターゲット・スタンバイ・データベースの選択」に、ターゲット・スタンバイ・データベースの選択に役立つガイドラインを示します。

注意:

ファスト・スタート・フェイルオーバーの場合、使用するターゲット・スタンバイ・データベースを事前に選択する必要があります。ファスト・スタート・フェイルオーバーの詳細は、「ファスト・スタート・フェイルオーバー」を参照してください。

データベースのロール変更可能状況の判定

適切なスイッチオーバーまたはフェイルオーバー・ターゲットの選択を助けるには、DGMGRL VALIDATE DATABASEコマンドを使用します。このコマンドは、データベースがロール変更を完了する準備ができているかどうかを決定する包括的なチェックを実行します。

参照:

- 「VALIDATE DATABASE」

- VALIDATE DATABASEコマンドを使用してデータベースのロール・スイッチオーバー実行可能状況を表示する例は、「使用例9: スイッチオーバー操作の実行」を参照してください

- VALIDATE DATABASEコマンドを使用してデータベースのロール・フェイルオーバー実行可能状況を表示する例は、「使用例10: 手動フェイルオーバー操作の実行」を参照してください

5.2.1 スイッチオーバーでのターゲット・スタンバイ・データベースの選択

スタンバイ・データベースがすべて同じタイプである(すべてフィジカルまたはすべてロジカル・スタンバイ・データベース)構成内でスイッチオーバーを実行する場合、未適用のREDOの数が最も少ないスタンバイ・データベースを選択します。未適用のREDOの数が最も少ないスタンバイ・データベースを選択することで、スイッチオーバー操作が完了するまでの全体の所要時間を最小限にできます。次に例を示します。

- DGMGRLを使用する場合、構成内にある各スタンバイ・データベースのSHOW DATABASE 出力のApply Lag行を調査します。

- Cloud Controlを使用する場合は、Oracle Data Guardの概要ページの「スタンバイ・データベース」セクションで、各スタンバイ・データベースのApplyLag列の値を表示できます。

構成にフィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの両方が含まれる場合、ターゲット・スタンバイ・データベースとして(未適用REDOの数が最も少ない)フィジカル・スタンバイ・データベースを選択することを考慮します。スイッチオーバー操作の完了後は、構成内のすべてのデータベースが新規プライマリ・データベースに対するスタンバイ・データベースとして使用可能になるため、フィジカル・スタンバイ・データベースへのスイッチオーバーをお薦めします。一方、ロジカル・スタンバイ・データベースにスイッチオーバーすると、構成内のフィジカルおよびスナップショット・スタンバイ・データベースがすべて無効化されます。そのため、フィジカル・スタンバイ・データベースを再有効化するには、新規プライマリ・データベースのコピーからフィジカル・スタンバイ・データベースを再作成する必要があります。

スナップショット・スタンバイ・データベースへのスイッチオーバーを実行するには、最初にフィジカル・スタンバイ・データベースに戻す必要があります。

注意:

Oracle Data Guard構成が最大保護モードで動作している場合、ブローカではロジカル・スタンバイ・データベースへのスイッチオーバーが許可されません。ロジカル・スタンバイ・データベースへのスイッチオーバーを実行するには、構成が最大可用性モードまたは最大パフォーマンス・モードのいずれかで動作している必要があります。

5.2.2 フェイルオーバーでのターゲット・スタンバイ・データベースの選択

フェイルオーバーを実行するとき、構成内のスタンバイがすべて同じタイプである場合は、最も転送ラグの小さいスタンバイ・データベースを選択します。これにより、データの消失量を最小限に抑え、場合によってはデータの消失をゼロにすることができます。

構成にフィジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースおよびロジカル・スタンバイ・データベースが含まれる場合、ターゲット・スタンバイ・データベースとしてフィジカル・スタンバイ・データベースを選択することを考慮します。フェイルオーバー操作の完了後は、構成内のすべてのスタンバイ・データベースが新規プライマリ・データベースに対するスタンバイ・データベースとして使用可能になる可能性が高いため、フィジカル・スタンバイ・データベースへのフェイルオーバーをお薦めします。

スナップショット・スタンバイ・データベースにフェイルオーバーすることもできます。ただし、スナップショット・スタンバイ・データベースにフェイルオーバーするには、ブローカがこのデータベースを最初にフィジカル・スタンバイ・データベースに戻す必要があるため、時間がかかります。変換した後、ブローカは、プライマリ・ロールへのデータベースのフェイルオーバーを実行する前に、REDO Applyを起動して累積REDOデータを適用します。スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに変換してからフェイルオーバーが実行されるため、フェイルオーバー操作の完了後、構成内のすべてのスタンバイ・データベースを新しいプライマリ・データベースへのスタンバイ・データベースとして使用することが可能になります。

ロジカル・スタンバイ・データベースにフェイルオーバーするには、フェイルオーバーの完了後に、新しいプライマリ・データベースのコピーからすべてのフィジカルおよびスナップショット・スタンバイ・データベースを再作成する必要があります。さらに、ロジカル・スタンバイ・データベースには、プライマリ・データベースに存在するデータのサブセットのみが含まれる可能性があります。(たとえば、プライマリ・データベース上で実行されるデータベース操作のうちロジカル・スタンバイ・データベースに適用しない操作を指定する際に、DBMS_LOGSTDBY.SKIPプロシージャが使用された場合など。)

ただし、例外として、ターゲット・スタンバイ・データベースとしてフィジカル・スタンバイ・データベースを選択することをお薦めできない場合があります。たとえば、フィジカル・スタンバイ・データベースもすべて利用できない場合は、ロジカル・スタンバイ・データベースへのフェイルオーバーが唯一の選択肢となります。

5.3 スイッチオーバー

データベースは、プライマリ・ロールからスタンバイ・ロール、またはスタンバイ・ロールからプライマリ・ロールに切り替えることができます。この操作は、データを消失させることなく、指定したスタンバイ・データベースがプライマリ・データベースになり、元のプライマリ・データベースがスタンバイ・データベースになるため、データベースのスイッチオーバーと呼ばれます。

可能な場合は必ず、フィジカル・スタンバイ・データベースに対してスイッチオーバーしてください。

- スイッチオーバーによりフィジカル・スタンバイ・データベースをプライマリ・ロールに遷移する場合、次のようになります。

- 元のプライマリ・データベースはフィジカル・スタンバイ・ロールに切り替えられます。

- その他のスタンバイは、新しいプライマリ・データベースからREDOを受け取ります。

- スイッチオーバー操作の一部として、元のプライマリ・データベースが再起動されます。新しいプライマリ・データベースを再起動する必要がないことに注意してください。
スイッチオーバーに関係しないスタンバイ・データベース(その他のスタンバイ・データベース)は、スイッチオーバーが発生する前の状態で引き続き動作し、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。

- スイッチオーバーによりロジカル・スタンバイ・データベースをプライマリ・ロールに遷移する場合、次のようになります。

- 元のプライマリ・データベースはロジカル・スタンバイ・ロールに切り替えられます。

- スイッチオーバーの完了後、プライマリ・データベースおよびロジカル・スタンバイ・データベースのどちらも再起動の必要はありません。
ブローカ構成内の他のロジカル・スタンバイ・データベースは、スイッチオーバー後も実行可能です。どのデータベースも再起動する必要はありません。ロジカル・スタンバイ・データベースへのスイッチオーバーの後、すべてのフィジカルおよびスナップショット・スタンバイ・データベースは無効化されるため、新しいプライマリ・データベースのコピーから再作成する必要があります。

構成が最大保護モードで動作している場合、ロジカル・スタンバイ・データベースへのスイッチオーバーは許可されません。

警告:

ロジカル・スタンバイ・データベースにスイッチオーバーすると、ブローカ構成内のスナップショット・スタンバイ・データベースとフィジカル・スタンバイ・データベースはブローカにより無効化され、これらのデータベースはスタンバイ・データベースとして実行できなくなります。スタンバイ・データベースとして実行可能な状態にリストアする方法は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

比較的すぐに元のプライマリ・データベースにスイッチバックする場合は、フィジカルおよびスナップショット・スタンバイ・データベースを無効なままにしておくことができます。フィジカルおよびスナップショット・スタンバイ・データベースはまだ元のプライマリ・データベースの実行可能なスタンバイ・データベースであるため、元のプライマリ・データベースへのスイッチバックの完了後、これらを再有効化できます。

5.3.1 スイッチオーバー操作実行前の考慮事項

スイッチオーバーを開始する前に、次の点を考慮してください。

- スイッチオーバーを開始すると、ブローカは、スイッチオーバーの完了後に少なくとも1つのスタンバイ・データベース(スタンバイ・ロールに遷移する予定のプライマリ・データベースも含む)が、全体の保護モード(最大保護、最大可用性または最大パフォーマンス)をサポートするように構成されているかどうかを検証します。

- 全体の保護モードとの関連で、将来考えられるスタンバイ・データベースとしてのロールに備えて、あらかじめプライマリ・データベースを準備しておきます(「データ保護モードの管理」を参照してください)。こうした準備には、次の操作が含まれます。

- プライマリ・データベースでスタンバイREDOログ・ファイルが構成されていることを確認します。

- LogXptMode、NetTimeout、StandbyArchiveLocation、AlternateLocationおよびRedoRoutesなど、REDO転送サービス関連のデータベース・プロパティをあらかじめ設定します。データベース・プロパティを使用したREDO転送サービスの管理の詳細は、「REDO転送サービスの管理」を参照してください。

- DelayMinsなど、REDO Applyサービス関連のデータベース・プロパティをリセットします。遅延の適用がある場合は、スイッチオーバーを開始する前にすべて削除する必要があります。遅延を解除しないと、スイッチオーバー時間が長くなり、今後のリリースでスイッチオーバーが許可されなくなります。プロパティを使用したREDO Applyサービスの管理の詳細は、「ログ適用サービスの管理」を参照してください。

- 一時表ごとに、プライマリ・データベース上の一時表に関連付けられた一時ファイルがスタンバイ・データベースにも存在することを確認します。

これらのプロパティは、実際にプライマリ・データベースをスタンバイ・ロールに切り替えるまで、ブローカによってREDO転送サービスとREDO Applyサービスの設定に使用されないことに注意してください。そのため、これらのプロパティの値の妥当性は、スイッチオーバー後まで検証されません。これらのプロパティを設定すると、その値はスイッチオーバーおよびフェイルオーバー時のロール変更を通じて存続します。

- リアルタイム問合せモードにあるフィジカル・スタンバイ・データベースへのスイッチオーバーを実行する前に、できるだけ迅速に、クリーンにロール・トランジションを実施させるために、そのスタンバイ・データベースのすべてのインスタンスを、マウント済だがオープンされていない状態にすることを検討します。

- ファスト・スタート・フェイルオーバーが有効化されている場合、スイッチオーバーを実行できるのは、事前に指定されたターゲット・スタンバイ・データベースに対してのみであり、スタンバイ・データベースがプライマリ・データベースと同期化されているか(最大可用性モード)、構成されている制限範囲内にラグが収まっている(最大パフォーマンス・モード)場合に限られます。ファスト・スタート・フェイルオーバーの有効化の詳細は、「ファスト・スタート・フェイルオーバーの有効化」を参照してください。

スイッチオーバーの完了後、ブローカにより、保護モードがスイッチオーバー前と同じ保護レベル(最大保護、最大可用性または最大パフォーマンス)に維持され、スイッチオーバー・プロセスの一部として全体のOracle Data Guard保護モードが保持されます。他のすべてのその他のスタンバイ・データベースに対する適用サービスは、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。

構成内にフィジカルまたはスナップショット・スタンバイ・データベースが存在するとき、ロジカル・スタンバイ・データベースへのスイッチオーバーが発生した場合は、「ロール変更後の無効化されたデータベースの再有効化」に示すように、新しいプライマリ・データベースのコピーからこれらのデータベースを再作成し、データベースを再び有効化する必要があります。

注意:

Oracle Data Guard構成では、スタンバイ・データベースのSRVCTL -startoptionは、スイッチオーバー後には、常にOPENに設定されます。ブローカとOracle Restartの対話に関する追加情報は、「データベース・サービスの構成要件」を参照してください。

5.3.2 スイッチオーバーの開始

ロールの切替えは、慎重に計画して実行する必要があります。スイッチオーバーに関係するプライマリ・データベースとスタンバイ・データベースのREDOラグは、できるかぎり低くする必要があります。スイッチオーバーに備えたデータベースの設定方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。

Cloud Controlを使用してスイッチオーバーを開始するには、プライマリ・ロールに変更するスタンバイ・データベースを選択して「スイッチオーバー」をクリックします。DGMGRLを使用する場合は、SWITCHOVERコマンドを1つのみ発行し、プライマリ・ロールに変更するスタンバイ・データベースの名前を指定します。

「ブローカによるスイッチオーバーの実行方法」で説明するように、スイッチオーバーに関するその他の作業はブローカによって制御されます。

5.3.3 ブローカによるスイッチオーバーの実行方法

スイッチオーバーを開始すると、ブローカは次の作業を実行します。

1. プライマリ・データベースとターゲットのスタンバイ・データベースが次の状態であることを検証します。

a. プライマリ・データベースが有効化されてTRANSPORT-ON状態であること。

b. ターゲット・スタンバイ・データベースが有効化されてAPPLY-ON状態であること。

ブローカは、スイッチオーバー操作に関連して選択したプライマリ・データベースとスタンバイ・データベースにエラーがないかぎり、スイッチオーバーを続行します。その他のスタンバイ・データベースにエラーが発生しても、スイッチオーバーは影響を受けません。

2. 必要に応じて、インスタンスのうち1つを残して、他のすべてのインスタンスを停止します。
フィジカル・スタンバイ・データベースへのスイッチオーバーを実行する場合、ブローカは、現在のプライマリ・データベース上のインスタンスのうち1つを残して他のすべてのインスタンスを停止します。ターゲット・フィジカル・スタンバイ・データベース上のインスタンスは停止されません。

ロジカル・スタンバイ・データベースへのスイッチオーバーの場合は、インスタンスを停止しません。スナップショット・スタンバイ・データベースにスイッチオーバーすることはできません。

3. プライマリ・データベースとスタンバイ・データベースの間でロールを切り替えます。
ブローカは最初に、元のプライマリ・データベースを変換してスタンバイ・ロールで実行するようにします。次に、ターゲットのスタンバイ・データベースをプライマリ・ロールに遷移させます。いずれかの変換時にエラーが発生すると、ブローカはスイッチオーバーを停止します。詳細は、「スイッチオーバー操作時の問題のトラブルシューティング」を参照してください。

4. ブローカ構成ファイルを更新し、ロールの変更を記録します。
これにより、その後なんらかの理由で各データベースが再起動した場合に、正しいロールと状態で動作することが保証されます。

5. フィジカル・スタンバイ・データベースへのスイッチオーバーを行った場合は新しいスタンバイ・データベース(元のプライマリ・データベース)を再起動すると、REDO Applyが新しいプライマリ・データベースからのREDOデータの適用を開始します。Oracle RACのフィジカル・スタンバイ・データベースの場合は、ブローカの指示により、Oracle Clusterwareがスイッチオーバーの前に停止されたインスタンスを再起動します。最大保護モードで動作している構成では、新しいプライマリ・データベースも再起動されます。

6. 新しいプライマリ・データベースが読取り/書込みモードでオープンし、REDO転送サービスが開始します。
リアルタイム問合せが有効な状態で元のフィジカル・スタンバイ・データベースが実行されていた場合、新しいフィジカル・スタンバイ・データベースはリアルタイム問合せが有効な状態で実行されます。

ブローカは各データベースの状態とステータスを検証し、スイッチオーバーによって、各データベースが新しいロールにそれぞれ正常に遷移していることを確認します。スイッチオーバー後にブローカにより無効化されていないその他のスタンバイ・データベースは、スイッチオーバー前の状態で引き続き動作します。他のすべてのその他のスタンバイ・データベースに対するREDO ApplyおよびSQL Applyは、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。

万一スイッチオーバー操作が失敗し、プライマリ・データベースがなくなった場合は、スイッチオーバー・コマンドを再試行します。元のプライマリにスイッチ・バックでき、その後、元のターゲット・スタンバイへのスイッチオーバーを再試行するか、スイッチオーバー先として構成内の別のスタンバイを選択できます。

5.4 手動フェイルオーバー

元のプライマリ・データベースで障害が発生し、プライマリ・データベースを適時にリカバリできる可能性がない場合は、スタンバイ・データベースをプライマリ・データベースに変換できます。これは手動フェイルオーバーと呼ばれます。プライマリ・データベースに障害が発生した時点でプライマリ・データベースとターゲット・スタンバイ・データベースが同期化されていたかどうかによって、データが消失する場合があります。手動という用語は、このタイプのフェイルオーバーとファスト・スタート・フェイルオーバー(「ファスト・スタート・フェイルオーバー」を参照)を比較する目的で使用します。

注意:

ファスト・スタート・フェイルオーバーが有効化されている場合でも、手動フェイルオーバーを実行できます。詳細は、「ファスト・スタート・フェイルオーバーが有効化されている場合の手動によるロール変更の実行」を参照してください。

次の各項では、手動フェイルオーバーの実行方法について説明します。

- 完全手動フェイルオーバーおよび即時手動フェイルオーバー

- 手動フェイルオーバー操作の実行

- ロール変更後の無効化されたデータベースの再有効化

5.4.1 完全手動フェイルオーバーおよび即時手動フェイルオーバー

Cloud ControlまたはDGMGRLを使用して、完全フェイルオーバー(推奨)または即時フェイルオーバーを実行できます。

- 完全フェイルオーバーは、推奨方法でありデフォルトのフェイルオーバー・オプションです。完全フェイルオーバーでは、構成が動作している保護モードに応じて最大量のREDOデータが自動的にリカバリされます。また、フェイルオーバーのターゲットではないスタンバイ・データベースの無効化をできるかぎり回避して、新しいプライマリ・データベースに対するスタンバイ・データベースとして機能し続けられるようにします。
フェイルオーバーのターゲットではないスタンバイ・データベース(その他のスタンバイ・データベース)を無効にするか否かは、フェイルオーバーのターゲットと比較して、ターゲットでないスタンバイに適用されたREDOデータの量、およびフェイルオーバー・ターゲットのスタンバイ・タイプに応じて異なります。

- フェイルオーバーのターゲットがフィジカルまたはスナップショット・スタンバイ・データベースの場合、新しいプライマリ・データベースのスタンバイ・データベースにするには、元のプライマリ・データベースを回復または再作成する必要があります。また、一部のスタンバイ・データベースで新規プライマリ・データベースによる適用を超えてREDOを適用したことが検出された場合、ブローカはそれらのデータベースをフェイルオーバー中に無効化する場合があります。ブローカにより無効化されたデータベースは、新しいプライマリ・データベースのスタンバイ・データベースにする前に、「ロール変更後の無効化されたデータベースの再有効化」で説明する手順に従って回復または再作成する必要があります。
スナップショット・スタンバイ・データベースでフェイルオーバーを実行した場合は、元のプライマリをフィジカル・スタンバイ・データベースとして回復または再作成する必要があることに注意してください。

- フェイルオーバーのターゲットがロジカル・スタンバイ・データベースである場合、元のプライマリ・データベースおよび構成内のすべてのフィジカルおよびスナップショット・スタンバイ・データベースが無効化されます。フラッシュバック・データベースが有効化されている場合、プライマリ・データベースを回復できます。フィジカルおよびスナップショット・スタンバイ・データベースは、新規プライマリ・データベースのコピーから再作成する必要があります。詳細は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

プライマリ・データベースをマウントできる場合は、ALTER SYSTEM FLUSH REDO SQL文を使用して、プライマリ・データベースからターゲット・スタンバイ・データベースへの未送信REDOデータをすべてフラッシュできます。この操作が正常に完了すると、プライマリ・データベースがデータ消失ゼロの保護モードでなくても、データ消失がゼロのフェイルオーバーが可能になります。ALTER SYSTEM FLUSH REDO文の使用の詳細は、『Oracle Data Guard概要および管理』を参照してください。

完全フェイルオーバー中は、「ブローカによる完全フェイルオーバー操作の実行方法」に示すフェイルオーバー手順がブローカによって実行されます。

- 即時フェイルオーバーは、最も高速なタイプのフェイルオーバーです。ただし、フェイルオーバーの起動後は、スタンバイ・データベースに追加データが適用されません。即時フェイルオーバーを実行した場合は、構成内の他のすべてのデータベースが無効化されます。新規プライマリ・データベースのスタンバイ・データベースとして機能させるには、これらのデータベースを回復または再作成する必要があります。この方法は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。即時フェイルオーバー中は、「ブローカによる即時フェイルオーバー操作の実行方法」に示すフェイルオーバー手順がブローカによって実行されます。

注意:

ORA-752またはORA-600 [3020]エラーにより、フェイルオーバー・ターゲットでREDO Applyが停止されていないかぎり、常に完全フェイルオーバーを最初に実行するようにします。これらのエラーのいずれかが発生した場合は、先に進む前に、My Oracle Supportノート1265884.1のスタンバイ・リカバリ時のORA-752またはORA-600 [3020]の解決のガイドラインに従います。このサポート・ノートは、http://support.oracle.comにあります。

即時フェイルオーバーは、完全フェイルオーバーが失敗するか、前述のエラーの場合にのみ実行してください。完全フェイルオーバーは、REDO転送サービスの宛先属性に応じて、データ損失なしで実行できますが、即時フェイルオーバーでは、通常データ損失が発生します。

5.4.2 手動フェイルオーバー操作の実行

プライマリ・データベースを適時リカバリできる可能性がないと判断した場合は、プライマリ・データベースが停止していることを確認し、フェイルオーバー操作を開始します。

この項の各手順では、手動フェイルオーバーの実行に関連するタスクについて説明します。フェイルオーバーおよび関係するスタンバイ・データベースのタイプによって、一部のデータベースの回復または再作成が必要となる場合があります。

- 手動フェイルオーバーの実行(タスク1): 使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースの決定

- 手動フェイルオーバーの実行(タスク2): フェイルオーバーの開始

- 手動フェイルオーバーの実行(タスク3): 保護モードのリセット

- 手動フェイルオーバーの実行(タスク4): 障害時リカバリ構成の再確立

5.4.2.1 手動フェイルオーバーの実行(タスク1): 使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースの決定

「ターゲット・スタンバイ・データベースの選択」に示したガイドラインに従います。

5.4.2.2 手動フェイルオーバーの実行(タスク2): フェイルオーバーの開始

Cloud ControlまたはDGMGRLを使用して、完全フェイルオーバー(推奨)または即時フェイルオーバーを実行します。

Cloud Controlを使用した手動フェイルオーバー:

Cloud ControlのOracle Data Guardの概要ページで、プライマリ・ロールに変更するスタンバイ・データベースを選択して「フェイルオーバー」をクリックします。その後、フェイルオーバーの確認ページで「はい」をクリックし、デフォルトの「完全」フェイルオーバー・オプションを起動します。

DGMGRLを使用した手動フェイルオーバー

ターゲット・スタンバイ・データベースに接続し、FAILOVERコマンドを発行してフェイルオーバーを実行し、プライマリ・データベースにするスタンバイ・データベースの名前を指定します。

DGMGRL> FAILOVER TO database-name;

次のいずれかの条件に当てはまる場合は、オプションのIMMEDIATE句を指定して、即時フェイルオーバーを実行します。

- ORA-752エラーがスタンバイ・データベースで発生した場合

- ORA-600 [3020]エラーがスタンバイ・データベースで発生し、その原因がプライマリ・データベースでの書込み欠落であるとOracleサポートが判断した場合

- 完全フェイルオーバーが不可能な場合

DGMGRL> FAILOVER TO database-name IMMEDIATE;

参照:

- FAILOVER

完全フェイルオーバーを実行する場合、データベース・ロールがプライマリに変更される前に、すべての累積REDOデータが適用されます。即時フェイルオーバーを実行する場合、累積REDOデータは適用されずに、データベース・ロールがプライマリに変更されます。

ターゲットがスナップショット・スタンバイ・データベースの場合、ブローカは、最初にデータベースをフィジカル・スタンバイ・データベースに変換します。

フィジカルまたはロジカル・スタンバイ・データベースにフェイルオーバーする場合は、インスタンスを停止しません。

5.4.2.3 手動フェイルオーバーの実行(タスク3): 保護モードのリセット

手動フェイルオーバー(完全または即時)の後、全体のOracle Data Guard保護モードは次のように処理されます。

- 保護モードが最大保護だった場合は、最大パフォーマンスにリセットされます。必要に応じて、保護モードを後でアップグレードできます(「構成に対する保護モードの設定」を参照)。

- 保護モードが最大可用性または最大パフォーマンスだった場合は、変更されません。

注意:

ファスト・スタート・フェイルオーバーが有効化されている場合に手動フェイルオーバーを実行すると、次のようになります。

- フェイルオーバーは、事前に選択されたターゲット・スタンバイ・データベースに対してのみ実行できます。

- ブローカにより、フェイルオーバー前に有効になっていた保護モードが維持されます。

5.4.2.4 手動フェイルオーバーの実行(タスク4): 障害時リカバリ構成の再確立

他の障害が発生した場合に実行可能な障害時リカバリ・ソリューションを維持するには、「ロール変更後の無効化されたデータベースの再有効化」で説明する追加手順を実行し、次の操作を行う必要があります。

- 元のプライマリ・データベースを回復し、新規構成のスタンバイ・データベースとして機能させます。

注意:

ORA-752またはORA-600 [3020]エラーがフェイルオーバー・ターゲットで発生した場合に、古いプライマリ・データベースを回復しようとすると、データ損失が発生する場合があるため、回復操作は行わないでください。かわりに、「無効化されたデータベースの再作成および再有効化の方法」で説明されている手順に従い、古いプライマリ・データベースを新しいプライマリのバックアップからスタンバイとして再作成する必要があります。

- ブローカによって無効化された構成内のスタンバイ・データベースを回復または再作成します。
完全フェイルオーバーが完了すると、新しいプライマリ・データベースのスタンバイとして実行可能でないその他のスタンバイ・データベースは、ブローカにより無効化されます。これは次のいずれかの理由で実行されます。

- その他のスタンバイ・データベースに、新しいプライマリ・データベースがスタンバイ・データベースであったときに適用されたよりも多くのREDOデータが適用された場合。新しいプライマリ・データベースのスタンバイとして機能させるには、このスタンバイ・データベースを再作成または回復する必要があります。

- ロジカル・スタンバイ・データベースにフェイルオーバーした場合。構成内のすべてのフィジカルおよびスナップショット・スタンバイ・データベースがブローカにより無効化されます。新しいプライマリ・データベースのスタンバイとして機能させるには、これらを再作成する必要があります。

5.4.2.5 ブローカによる完全フェイルオーバー操作の実行方法

完全フェイルオーバーを開始すると、ブローカは次の作業を実行します。

1. ターゲット・スタンバイ・データベースが有効化されていることを確認します。データベースが有効化されていない場合、このデータベースに対するフェイルオーバーは実行できません。

2. ターゲットのスタンバイ・データベースで未適用のREDOデータの適用が完了するまで待機し、適用が完了した後でREDO Apply(ターゲットがフィジカル・スタンバイ・データベースの場合)またはSQL Apply(ターゲットがロジカル・スタンバイ・データベースの場合)を停止します。
ターゲットがスナップショット・スタンバイ・データベースの場合、ブローカは、最初にデータベースをフィジカル・スタンバイに戻し、次にREDO Applyを起動してすべての累積REDOを適用してから、フェイルオーバーを完了してデータベースをプライマリ・データベースとしてオープンします。

3. ターゲット・スタンバイ・データベースを、次のように、プライマリ・データベース・ロールに遷移させます。

a. データベースのロールをスタンバイからプライマリに変更します。

b. 新しいプライマリ・データベースを読取り/書込みモードでオープンします。

c. フェイルオーバー操作に関係しなかったスタンバイ・データベースを、新しいプライマリ・データベースより多くのREDOデータが適用されたために無効化する必要があるかどうかを判断します。
このフェイルオーバー中に、その他のスタンバイ・データベースがブローカにより無効化されない場合は、フェイルオーバー前と同じ状態のままになります。たとえば、APPLY-OFF状態であったフィジカル・スタンバイ・データベースは、APPLY-OFF状態のままになります。

デフォルトでは、ブローカは、完全フェイルオーバーを実行するたびにその他のスタンバイ・データベースが新しいプライマリに対する実行可能なスタンバイ・データベースであるかどうかを判別します。完全フェイルオーバーの実行時に、その他のスタンバイ・データベースの実行可能性のチェックをスキップして、全フェイルオーバー時間を短縮するには、BystandersFollowRoleChange構成プロパティをNONEに設定してください。

このプロパティをNONEに設定すると、ブローカは、新しいプライマリ・データベースよりも多くのREDOデータが適用されているかどうかのチェックを実行せずに、その他のすべてのスタンバイ・データベースを無効にします。フェイルオーバーの完了後にスタンバイ・データベースを回復または再作成(「ロール変更後の無効化されたデータベースの再有効化」項を参照)する必要があります。SHOW CONFIGURATIONコマンドを使用して、回復可能なデータベースと再作成する必要のあるデータベースを表示します。このプロパティの値を表示するには、SHOW CONFIGURATION BystandersFollowRoleChangeコマンドを使用します。デフォルト値はALLです。

このプロパティは、ファスト・スタート・フェイルオーバーの発生時にその他のスタンバイ・データベースの実行可能性チェックをスキップするかどうかにも影響を与えます。

d. REDO転送サービスを起動して、無効化されていないすべてのその他のスタンバイ・データベースへのREDOデータの転送を開始します。

注意:

フェイルオーバー中には、その他のスタンバイ・データベースがブローカにより無効化される場合があります。新しいプライマリ・データベースのスタンバイ・データベースとして機能させるには、これらのデータベースを回復または再作成する必要があります。すべてのデータベースでフラッシュバック・データベースを構成し、フィジカル・スタンバイ・データベースにフェイルオーバーを実行した場合に、無効化されたスタンバイ・データベースをより簡単に回復できるようにすることをお薦めします。ロジカル・スタンバイ・データベースにフェイルオーバーを実行した場合、すべてのフィジカルおよびスナップショット・スタンバイ・データベースがブローカにより無効化されます。この場合、データベースの回復にフラッシュバック・データベースは使用できません。新しいプライマリ・データベースのコピーから再作成する必要があります。フェイルオーバー中に無効化されたロジカル・スタンバイ・データベースは回復できます。

4. Oracle RACのフィジカルまたはスナップショット・スタンバイ・データベースがフェイルオーバー・ターゲット・データベースである場合は、ブローカの指示により、Oracle Clusterwareがフェイルオーバーの前に停止されたインスタンスをすべて再起動します。

ブローカは、フェイルオーバーに関連して選択したスタンバイ・データベースにエラーがないかぎり、フェイルオーバーを続行します。その他のスタンバイ・データベースにエラーが発生しても、フェイルオーバーは停止されません。完全フェイルオーバーを開始して失敗した場合は、即時フェイルオーバーを使用する必要があります。

遠隔同期インスタンスを使用した構成内での完全フェイルオーバー

遠隔同期インスタンスからREDOデータを受け取るスタンバイ・データベースに、より完全なフェイルオーバーを手動で実行できます。フェイルオーバーするには、スタンバイ・データベースに接続し、DGMGRLのFAILOVER TO db-unique-nameコマンドを使用します。フィジカル・スタンバイをプライマリ・データベースに変換する前に、遠隔同期インスタンス上に存在して未送信のREDOデータがすべて、ターゲットのフィジカル・スタンバイに送信されます。

カスケーデッド・スタンバイを使用した構成内での完全フェイルオーバー

完全フェイルオーバーでは、別のスタンバイ・データベース(カスケーダ)からREDOを取得するスタンバイ・データベース(ターミナル・スタンバイ)にフェイルオーバーすることも可能です。この場合、未送信のREDOをカスケーダからターミナル・スタンバイに送信する試行は行われません。

5.4.2.6 ブローカによる即時フェイルオーバー操作の実行方法

即時フェイルオーバーは、次のDGMGRLコマンドで開始されます。

DGMGRL> FAILOVER TO database-name IMMEDIATE;

即時フェイルオーバーが開始されると、ブローカは次のことを行います。

1. ターゲット・スタンバイ・データベースが有効化されていることを確認します。スタンバイ・データベースがブローカによる管理に対応していない場合、フェイルオーバーは実行できません。

2. 使用可能なREDOデータがすべて適用されるまで待機せずに、スタンバイ・データベースのREDO ApplyまたはSQL Applyを即時停止します。この作業によってデータが失われる可能性があります。

3. ターゲットのスタンバイ・データベースをプライマリ・ロールに遷移させ、新しいプライマリ・データベースを読取り/書込みモードでオープンし、REDO転送サービスを起動します。
即時フェイルオーバーが完了すると、構成内のすべてのスタンバイ・データベースはタイプに関係なく無効化されます。それらのデータベースでフラッシュバック・データベースが有効化されている場合、データベースは回復されます。それ以外の場合は、新しいプライマリ・データベースのコピーから再作成する必要があります。

ブローカは、フェイルオーバーに関係するように選択したスタンバイ・データベースにエラーがないかぎり、完全フェイルオーバーを続行します。

ブローカは、フェイルオーバーに関係するように選択したスタンバイ・データベースにエラーがあっても、即時フェイルオーバーを続行します。

遠隔同期インスタンスを使用した構成内での即時フェイルオーバー

遠隔同期インスタンスからREDOデータを受け取るスタンバイ・データベースに、即時フェイルオーバーを手動で実行できます。この場合、フィジカル・スタンバイをプライマリ・データベースに変換する前に、遠隔同期インスタンスからターゲットのフィジカル・スタンバイに未送信のREDOを送信する試行は行われません。

カスケーデッド・スタンバイを使用した構成内での即時フェイルオーバー

即時フェイルオーバーでは、別のスタンバイ・データベース(カスケーダ)からREDOを取得するスタンバイ・データベース(ターミナル・スタンバイ)にフェイルオーバーすることも可能です。この場合、未送信のREDOをカスケーダからターミナル・スタンバイに送信する試行は行われません。

5.4.3 ロール変更後の無効化されたデータベースの再有効化

ロジカル・スタンバイ・データベースへのスイッチオーバー後またはいずれかのスタンバイ・データベースへのフェイルオーバー後に元の障害時リカバリ・ソリューションをリストアするには、追加手順を実行する必要があります。

ロール遷移後に無効化されたデータベースは、ブローカ構成から削除されませんが、ブローカによって管理されなくなります。

これらのデータベースのブローカによる管理を再び有効化するには、次のいずれかの手順でデータベースを回復または再作成する必要があります。

- データベースが回復可能な場合は、データベースで次のステータスが示されます。

ORA-16661: the standby database needs to be reinstated

「データベースの回復方法」の説明に従って、DGMGRLのREINSTATE DATABASEコマンドまたはCloud Controlの回復オプションを使用してデータベースを回復します。 ブローカにより、データベースは回復処理の一部として再有効化されます。

- 新規プライマリ・データベースのコピーからデータベースを再作成する必要がある場合、データベースのステータスが次のようになります。

ORA-16795: the standby database needs to be re-created

プライマリ・データベースのコピーからスタンバイ・データベースを再作成し、再び有効化します。スタンバイ・データベースの作成手順は、『Oracle Data Guard概要および管理』を参照してください。詳細は、「無効化されたデータベースの再作成および再有効化の方法」を参照してください。

注意:

複数のロール変更が実行されたときに無効化されたデータベースは、回復できません。現在のプライマリ・データベースのコピーからデータベースを手動で再作成し、ブローカ構成でデータベースを再有効化する必要があります。

データベースを回復するか再作成するかは、スイッチオーバーとフェイルオーバーのどちらを実行したか、さらに操作のターゲットとなったスタンバイ・データベースのタイプに応じて決まります。ロジカルおよびスナップショット・スタンバイ・データベースにロール変更すると、常にその他のフィジカル・スタンバイ・データベースは無効化されることに注意してください。これらのデータベースは回復できません。新しいプライマリ・データベースのコピーから再作成する必要があります。

次の各項では、データベースの回復または再有効化方法を説明します。

5.4.3.1 データベースの回復方法

ブローカの回復機能を使用して、障害が発生したしたプライマリ・データベースを新しいプライマリ・データベースの実行可能なスタンバイ・データベースにすることができます。この処理は、フェイルオーバーがフィジカル、ロジカルまたはスナップショット・スタンバイ・データベースのいずれに実行されたかに関係なく行うことができます。

フェイルオーバー操作中に無効化されたその他のスタンバイ・データベースも回復できます。

回復可能なデータベースは、ステータス値が次のようになります。

ORA-16661: the standby database needs to be reinstated

REINSTATEコマンドを正常に実行するには、フェイルオーバー前にデータベース上でフラッシュバック・データベースが有効化されており、そのデータベースに十分なフラッシュバック・ログが存在する必要があります。さらに、回復するデータベースおよび新規プライマリ・データベースにネットワーク接続が必要です。

データベースを回復する手順は、次のとおりです。

1. データベースを再起動してマウント済状態にします。

2. 新規プライマリ・データベースに接続します。

3. Cloud ControlまたはDGMGRLを使用して、データベースを回復します。

ブローカは、障害が発生したプライマリ・データベースを元のスタンバイ・データベースと同じタイプのスタンバイ・データベース(フィジカルまたはロジカル・スタンバイ・データベース)として回復します。唯一の例外は、スナップショット・スタンバイ・データベースへのフェイルオーバーです。そのような場合は、障害が発生したプライマリ・データベースがフィジカル・スタンバイ・データベースとして回復されます。

ブローカは、フェイルオーバー中に無効化されたその他のスタンバイ・データベースを、新しいプライマリ・データベースのスタンバイ・データベースとして回復します。

Cloud Controlを使用した回復

Oracle Data Guardの概要ページで、「データベースを回復する必要があります」をクリックします。これにより、「回復」ボタンが表示された「一般プロパティ」ページが開きます。「回復」ボタンをクリックすると、Cloud Controlでデータベースの回復が開始されます。

プロセスが完了すると、データベースが新規プライマリ・データベースのスタンバイ・データベースとして有効化され、Cloud ControlでOracle Data Guardの概要ページが表示されます。

DGMGRLを使用した回復

ブローカ構成内のデータベース(回復するデータベースを除く)に接続しているときに、次のコマンドを発行します。

DGMGRL> REINSTATE DATABASE db_unique_name;

新しく回復したスタンバイ・データベースは、新規プライマリ・データベースのスタンバイ・データベースとして機能し始めます。データベースの回復に失敗した場合、ステータスは「ORA-16795: スタンバイ・データベースを再作成する必要があります」に変更されます。この場合、「無効化されたデータベースの再作成および再有効化の方法」の説明に従って、新しいプライマリ・データベースのコピーから再作成して再有効化する必要があります。

5.4.3.2 無効化されたデータベースの再作成および再有効化の方法

障害が発生したプライマリ・データベースまたはロール遷移時に無効化されたスタンバイ・データベースの再作成が必要なフェイルオーバーまたはスイッチオーバーを実行した場合、『Oracle Data Guard概要および管理』の「フィジカル・スタンバイ・データベースの作成」、「ロジカル・スタンバイ・データベースの作成」および「Oracle Data Guard概要および管理」の手順を実行します。

元のプライマリ・データベースを作成する場合、元のスタンバイ・データベースのスタンバイ・タイプで作成する必要があることに注意してください。たとえば、元のスタンバイがフィジカルまたはスナップショット・スタンバイだった場合は、元のプライマリをフィジカル・スタンバイとして再作成する必要があります。

データベースが再作成された後、DGMGRLのENABLE DATABASEコマンドを使用して、再作成されたスタンバイ・データベースのブローカ管理を有効化します。

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

ファスト・スタート・フェイルオーバーでは、プライマリ・データベースが消失した場合、ブローカにより、事前に選択されたスタンバイ・データベースに自動的にフェイルオーバーできます。ファスト・スタート・フェイルオーバーでは、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールに迅速かつ確実にフェイルオーバーされます。このとき、手動手順を実行してフェイルオーバーを起動する必要はありません。ファスト・スタート・フェイルオーバーはブローカ構成でのみ使用でき、DGMGRLまたはCloud Controlによってのみ構成できます。

ファスト・スタート・フェイルオーバーでは、最大可用性モードまたは最大パフォーマンス・モードのいずれかを使用できます。最大可用性モードは、データが消失しないことを保証する自動フェイルオーバー環境を提供します。最大パフォーマンス・モードによる自動フェイルオーバー環境では、消失データがFastStartFailoverLagLimit構成プロパティで指定したデータ量(秒単位)以下であることが保証されます。このプロパティは、自動フェイルオーバーの実行に許容される最大消失データ量を示します。このプロパティは、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作している場合にのみ使用されます。

ファスト・スタート・フェイルオーバーが有効化されると、ブローカでは、構成されている消失データ量が保証される場合にのみファスト・スタート・フェイルオーバーの実行が可能となります。構成されている消失データ量を保証できない場合、プライマリ・データベースのREDO生成が停止します。長期にわたる停止を回避するため、ファスト・スタート・フェイルオーバーを実行できないと記録された後、オブザーバまたはターゲット・スタンバイ・データベースにより、プライマリ・データベースでのREDO生成の続行が可能になる場合があります。

構成済の消失データ量の保証が適用可能になると、ブローカは自動フェイルオーバー機能をリストアします。このリストアが起こるのは、最大可用性モードで動作している構成の場合、ターゲットのスタンバイ・データベースがREDOデータの不足をすべて受信し終わったときです。最大パフォーマンス・モードで動作している構成の場合は、プライマリ・データベースのREDO生成時点とターゲット・スタンバイ・データベースのREDO適用時点の間に、FastStartFailoverLagLimit構成プロパティに指定された値を超過する遅れがなくなったときです。

ファスト・スタート・フェイルオーバーのターゲットが、遠隔同期インスタンスからREDOデータを受け取る論理またはフィジカル・スタンバイ・データベースの場合、ファスト・スタート・フェイルオーバーを最大可用性モードで有効化できます。これにより、距離に関係なくデータ損失がゼロになる保護が設定された構成で、ブローカの自動フェイルオーバー機能の利点を活用できます。(ターゲット・スタンバイが遠隔同期インスタンスからREDOを受け取る場合、最大パフォーマンス・モードではファスト・スタート・フェイルオーバーを有効化できません。)この設定方法の例は、「使用例7: 遠隔同期インスタンスが使用中の場合のファスト・スタート・フェイルオーバーの有効化」を参照してください。

この項では、ファスト・スタート・フェイルオーバーおよびファスト・スタート・フェイルオーバー環境を監視するオブザーバ・サイトを有効化する方法を説明します。オブザーバは、プライマリ・データベースおよびスタンバイ・データベースとは異なるコンピュータ上で動作する、独立したOCIクライアント側コンポーネントであり、プライマリ・データベースの可用性を監視します。オブザーバについては、「オブザーバの管理」で詳しく説明されています。

オブザーバの起動が完了したら、ユーザーによる操作は必要ありません。オブザーバおよび指定されたスタンバイ・データベースの両方で、FastStartFailoverThreshold構成プロパティに指定された秒数を超えてプライマリ・データベースとの接続が失われた場合、オブザーバはスタンバイ・データベースへのファスト・スタート・フェイルオーバーを開始します。また、FastStartFailoverPmyShutdown構成プロパティがTRUEに設定されている場合、FastStartFailoverThresholdの秒数よりも長い期間に及ぶ接続の消失を検出すると、プライマリ・データベースは停止します。FastStartFailoverAutoReinstate構成プロパティがTRUEに設定されている場合、フェイルオーバーの完了後、元のプライマリ・データベースへの接続が再度確立されたときに、元のプライマリ・データベースがスタンバイ・データベースとして自動的に回復されます。

注意:

ユーザーが構成可能なファスト・スタート・フェイルオーバー条件が検出されてファスト・スタート・フェイルオーバーが発生した場合、またはアプリケーションからDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてファスト・スタート・フェイルオーバーを開始した場合、元のプライマリ・データベースは必ず停止し、自動的に回復されることはありません。これは、FastStartFailoverPmyShutdownおよびFastStartFailoverAutoReinstate構成プロパティの設定には関係ありません。詳細は、「ファスト・スタート・フェイルオーバーの有効化」を参照してください。

図5-1に、ファスト・スタート・フェイルオーバー時のプライマリ・データベース、ターゲット・スタンバイ・データベースおよびオブザーバの関係を示しています。

- ファスト・スタート・フェイルオーバー前: Oracle Data Guardは安定した状態で動作しており、プライマリ・データベースがターゲット・スタンバイ・データベースにREDOデータを転送し、オブザーバが全体の構成の状態を監視しています。

- ファスト・スタート・フェイルオーバーの実行: プライマリ・データベースに障害が発生し、オブザーバおよびターゲット・スタンバイ・データベースへのネットワーク接続がどちらも失われます。オブザーバは、通信の切断を検出すると、ファスト・スタート・フェイルオーバーの開始前にFastStartFailoverThresholdプロパティによって定義された時間内において、プライマリ・データベースとの接続の再確立を試行します。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できず、ターゲット・スタンバイ・データベースがファスト・スタート・フェイルオーバー可能な状態である場合、ファスト・スタート・フェイルオーバーが実行されます。

- ファスト・スタート・フェイルオーバー後: ファスト・スタート・フェイルオーバーが完了し、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールで動作しています。元のプライマリ・データベースが修復された後、オブザーバはそのデータベースとの接続を再確立し、新規スタンバイ・データベースとして回復します。新規プライマリ・データベースが新規スタンバイ・データベースへのREDOデータの転送を開始します。

図5-1 プライマリ・データベースおよびスタンバイ・データベースとオブザーバの関係

以降の各項の内容は、次のとおりです。

- ファスト・スタート・フェイルオーバーを有効化するための前提条件

- ファスト・スタート・フェイルオーバーの有効化

- ファスト・スタート・フェイルオーバー構成の統計およびステータスの表示

- ファスト・スタート・フェイルオーバーの無効化

- ファスト・スタート・フェイルオーバーのパフォーマンスに関する考慮事項

- オブザーバの管理

- ブローカ構成に含まれる元のプライマリ・データベースの回復

- ファスト・スタート・フェイルオーバー環境でのデータベースの停止

5.5.1 ファスト・スタート・フェイルオーバーを有効化するための前提条件

ブローカでファスト・スタート・フェイルオーバーを有効化するには、次の前提条件を満たしている必要があります。

- ブローカ構成が最大可用性モードまたは最大パフォーマンス・モードのいずれかで動作していることを確認します。
保護モード、スタンバイREDOログおよびREDO転送モードの構成の詳細は、「構成に対する保護モードの設定」を参照してください。

- ファスト・スタート・フェイルオーバー・ターゲットになる選択したスタンバイ・データベースは、プライマリ・データベースまたは遠隔同期インスタンスから直接REDOを受け取る必要があります。

- ファスト・スタート・フェイルオーバーのターゲットに選択したスタンバイ・データベースのLogXptModeプロパティがSYNCかFASTSYNC(最大可用性モードでファスト・スタート・フェイルオーバーを有効化する場合)、またはASYNC(最大パフォーマンス・モードでファスト・スタート・フェイルオーバーを有効化する場合)に設定されていることを確認します。現在のプライマリ・データベースは、LogXptModeプロパティが適切に設定され、スタンバイREDOログが構成されている必要があります。あるいは、RedoRoutesプロパティを使用して、ターゲット・スタンバイと、現在プライマリ・ロールになっているデータベースのためにREDO転送モードを構成します。

- ファスト・スタート・フェイルオーバーで遠隔同期インスタンスを使用するには、遠隔同期インスタンスの転送モードはSYNCまたはFASTSYNCに、ターゲット・スタンバイ・データベースの転送モードはASYNCに設定される必要があります。

- フラッシュバック・データベースを有効化し、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方でファスト・リカバリ領域を設定します。
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- 「Oracle Data Guardのインストール」の説明に従って、オブザーバ・コンピュータにDGMGRLコマンドライン・インタフェースをインストールします。

- オブザーバ・システムでTNSNAMES.ORAファイルを構成し、オブザーバがプライマリ・データベースおよび事前に選択されたターゲット・スタンバイ・データベースに接続できるようにします。

- Oracle ClusterwareもOracle Restartも使用していない場合、オブザーバが回復の一部として自動的にデータベースを再起動できるように、静的サービス名を作成する必要があります。詳細は、「前提条件」を参照してください。

5.5.2 ファスト・スタート・フェイルオーバーの有効化

ブローカ構成のデータベースに接続されている間は、任意のサイトからファスト・スタート・フェイルオーバーを有効化できます。ファスト・スタート・フェイルオーバーを有効化しても、フェイルオーバーは起動されません。かわりに、フェイルオーバーのデータベース条件が満たされた場合に、構成を監視しているオブザーバがファスト・スタート・フェイルオーバーを起動できるようになります。(ファスト・スタート・フェイルオーバーの条件を満たす、アプリケーションに固有の条件が他にある場合、これらの条件のいずれかが発生した場合に即時にDBMS_DG.INITIATE_FS_FAILOVER機能をコールしてファスト・スタート・フェイルオーバーを開始するように、アプリケーションを設定できます。「アプリケーションによるファスト・スタート・フェイルオーバーの指示」を参照してください)

ファスト・スタート・フェイルオーバーの有効化およびオブザーバの起動には、次のタスクがあります。これらのタスクでは、SYSとして接続しており、ブローカ構成でプライマリ・データベースおよびスタンバイ・データベースがすでに設定されていることを前提としています。

- ファスト・スタート・フェイルオーバーの有効化(タスク1): 使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースの決定

- ファスト・スタート・フェイルオーバーの有効化(タスク2): FastStartFailoverTarget構成プロパティを使用したターゲット・スタンバイ・データベースの指定

- ファスト・スタート・フェイルオーバーの有効化(タスク3): 使用する保護モードの決定

- ファスト・スタート・フェイルオーバーの有効化(タスク4): FastStartFailoverThreshold構成プロパティの設定

- ファスト・スタート・フェイルオーバーの有効化(タスク5): ファスト・スタート・フェイルオーバー関連の他のプロパティの設定(省略可能)

- ファスト・スタート・フェイルオーバーの有効化(タスク6): 追加のファスト・スタート・フェイルオーバー条件の有効化(省略可能)

- ファスト・スタート・フェイルオーバーの有効化(タスク7): DGMGRLまたはCloud Controlの使用

- ファスト・スタート・フェイルオーバーの有効化(タスク8): オブザーバの起動

- ファスト・スタート・フェイルオーバーの有効化(タスク9): ファスト・スタート・フェイルオーバー環境の検証

5.5.2.1 ファスト・スタート・フェイルオーバーの有効化(タスク1): 使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースの決定

「ターゲット・スタンバイ・データベースの選択」に示したガイドラインに従います。

5.5.2.2 ファスト・スタート・フェイルオーバーの有効化(タスク2): FastStartFailoverTarget構成プロパティを使用したターゲット・スタンバイ・データベースの指定

現行のプライマリ・データベースのFastStartFailoverTarget構成プロパティを設定する場合、ターゲット・スタンバイ・データベースを1つのみ指定できます。

- 構成内のスタンバイ・データベースが1つのみである場合、この手順をスキップして手順3に進みます。ファスト・スタート・フェイルオーバーを有効化する際、ブローカにより、プライマリ・データベースおよびスタンバイ・データベースのFastStartFailoverTargetプロパティが、フェイルオーバー時にお互いをそれぞれのターゲットとして指すように自動的に設定されます。

- 構成内に複数のスタンバイ・データベースがある場合、プライマリ・データベースでFastStartFailoverTargetプロパティを明示的に設定して、ターゲット・スタンバイ・データベースを選択する必要があります。ファスト・スタート・フェイルオーバーを有効化する際、ブローカによりこのプロパティが既存のスタンバイ・データベースを指していることが確認され、今度は反対にこのスタンバイ・データベースのFastStartFailoverTargetプロパティがプライマリ・データベースを指すように設定されます。(ターゲット・スタンバイは遠隔同期スタンバイになれないことに注意してください。ただし、ターゲットは遠隔同期インスタンスからREDOを受け取ることができます。)

注意:

FastStartFailoverTargetプロパティを変更して別のスタンバイ・データベースを指すようにするには、ファスト・スタート・フェイルオーバーを無効化し、FastStartFailoverTargetプロパティを設定し、さらにファスト・スタート・フェイルオーバーを再有効化してください。

このプロパティの詳細は、「FastStartFailoverTarget」を参照してください。

5.5.2.3 ファスト・スタート・フェイルオーバーの有効化(タスク3): 使用する保護モードの決定

ファスト・スタート・フェイルオーバーは、最大可用性モードまた最大パフォーマンス・モードに対して有効化できます。いかなるデータの消失も許容できない場合は、構成の保護モードが最大可用性に設定されていることを確認してください。そうするには、プライマリ・データベースとターゲット・スタンバイ・データベースの両方のLogXptModeデータベース・プロパティをSYNCまたはFASTSYNCに設定します。次に例を示します。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY LogXptMode=SYNC;
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY LogXptMode=SYNC;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;

あるいは、RedoRoutesプロパティを使用して、ターゲット・スタンバイと、現在プライマリ・ロールになっているデータベースのためにREDO転送モードを設定します。その後、構成保護モードを最大可用性に設定してください。

わずかなデータの消失よりもプライマリ・データベースのパフォーマンスを重視する場合は、構成の保護モードを最大パフォーマンスに設定してファスト・スタート・フェイルオーバーを有効化することを検討してください。このモードでは、どれだけのデータ消失を許容できるかを秒単位で検討し、それに従ってFastStartFailoverLagLimit構成プロパティを設定する必要があります。このプロパティは、REDO適用に関してターゲット・スタンバイ・データベースがプライマリ・データベースから遅れることができるデータ量を秒単位で指定します。スタンバイ・データベースでREDOが適用された時点がプライマリ・データベースのREDO生成時点からその秒数以内であれば、ファスト・スタート・フェイルオーバーが許可されます。FastStartFailoverLagLimit構成プロパティは、最大パフォーマンス・モードで動作している構成のファスト・スタート・フェイルオーバーが有効化されている場合にのみブローカによって使用されます。デフォルト値は30秒で、設定できる最小値は10秒です。

構成の保護モードを最大パフォーマンスに設定することに加えて、プライマリ・データベースとターゲットスタンバイ・データベースの両方でデータベース・プロパティLogXptModeがASYNCに設定されていることを確認する必要もあります。次に例を示します。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY LogXptMode=ASYNC;
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY LogXptMode=ASYNC;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxPerformance;
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverLagLimit=45;

あるいは、RedoRoutesプロパティを使用して、ターゲット・スタンバイと、現在プライマリ・ロールになっているデータベースのためにREDO転送モードをASYNCに設定します。

5.5.2.4 ファスト・スタート・フェイルオーバーの有効化(タスク4): FastStartFailoverThreshold構成プロパティの設定

オブザーバおよびターゲット・スタンバイ・データベースの両方で、FastStartFailoverThreshold構成プロパティで指定された時間にわたってプライマリ・データベースへの接続が失われた場合、ファスト・スタート・フェイルオーバーが実行されます。

FastStartFailoverThresholdプロパティを設定し、(プライマリ・データベースが使用できないことが検出されてから)フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。次に例を示します。

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 45;

FastStartFailoverThresholdプロパティのデフォルト値は30秒で、設定できる最小値は6秒です。Oracle RACプライマリ・データベースが存在する場合、インスタンス障害が発生したときに誤ってフェイルオーバーが実行される可能性を最小限にするには、これより大きい値を指定することを考慮します。

この時間間隔は、オブザーバでプライマリ・データベースへの接続が最初に失われたときに開始されます。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できない場合、スタンバイ・データベースがフェイルオーバー可能な状態であれば、オブザーバによりファスト・スタート・フェイルオーバーが開始されます。デフォルト値の30秒は、通常はほとんどの構成で停止および障害を検出できる値ですが、このプロパティでフェイルオーバーの感度を調整することで、一時的に不安定になった環境でフェイルオーバーが誤って実行される可能性を低くすることができます。

REDOの生成が停止し、プライマリ・データベースがオブザーバまたはターゲット・スタンバイ・データベースとの接続を再確立できない場合、FastStartFailoverPmyShutdown構成プロパティがTRUEに設定されていると、FastStartFailoverThresholdの秒数が経過した後にプライマリ・データベースが停止します。

ファスト・スタート・フェイルオーバーが有効化されている場合でもFastStartFailoverThresholdプロパティを変更できることに注意してください。

参照:

FastStartFailoverThresholdプロパティの詳細は、「FastStartFailoverThreshold」を参照してください

5.5.2.5 ファスト・スタート・フェイルオーバーの有効化(タスク5): ファスト・スタート・フェイルオーバー関連の他のプロパティの設定(省略可能)

必要に応じて、次の表に示されているデータベース・プロパティを設定できます。

プロパティ名

説明

デフォルト値

FastStartFailoverPmyShutdown

この構成プロパティにより、ファスト・スタート・フェイルオーバーが有効化されていてプライマリがFastStartFailoverThresholdの秒数よりも長くSTALLEDになったことをV$DATABASE.FS_FAILOVER_STATUSが示すと、プライマリ・データベースが停止します。TRUEの値は、分離されたプライマリ・データベースがユーザーの問合せに対応できないことを確認するのに役立ちます。

ユーザーの構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを要求した場合、このプロパティを使用してプライマリ・データベースの停止を防止することはできません。

TRUE

FastStartFailoverLagLimit

構成プロパティは、REDOの適用に関して、プライマリよりスタンバイが遅れることができる許容範囲を秒単位で確立します。この値を超えて遅れる場合は、ファスト・スタート・フェイルオーバーが実行されません。設定可能な最小値は10秒です。

このプロパティは、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作しているときに使用します。

30秒

FastStartFailoverAutoReinstate

この構成プロパティを使用すると、プライマリ・データベースが分離またはクラッシュしたためにファスト・スタート・フェイルオーバーが開始した場合に、元のプライマリ・データベースが自動的に回復されます。この場合に元のプライマリ・データベースを自動的に回復しないようにするには、この構成プロパティをFALSEに設定します。ユーザー構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを要求した場合は、ブローカは元のプライマリ・データベースを自動的に回復しません。

TRUE

ObserverConnectIdentifier

このデータベース・プロパティは、オブザーバがプライマリおよびスタンバイ・データベースに接続して監視する方法を指定するために使用されます。REDOデータの転送に使用される接続識別子とは異なる識別子(DGConnectIdentifierプロパティで指定される接続識別子)をオブザーバが使用する場合は、プライマリ・データベースとターゲット・スタンバイ・データベースにこのプロパティを設定してください。

オブザーバは、DGConnectIdentifierプロパティの値を使用してプライマリおよびターゲット・スタンバイ・データベースに接続し、監視します。

ObserverOverride

ObserverOverride構成プロパティをTRUEに設定すると、スタンバイがプライマリに正常に接続していても、オブザーバのプライマリへの接続が失われた場合、自動フェイルオーバーが発生します。

FALSE

ObserverReconnect

ObserverReconnect構成プロパティは、オブザーバがプライマリ・データベースに対して新しい接続を確立する頻度を指定します。このプロパティがデフォルト値の0に設定されている場合、オブザーバはプライマリ・データベースへの新しい接続を定期的に確立しません。これによりプライマリ・データベースに新しいオブザーバ接続を定期的に確立することによる処理オーバーヘッドがなくなる一方、オブザーバがプライマリ・データベースに新しい接続を作成できないことを検出できなくなります。このプロパティは、プライマリ・データベースの障害を適時に検出できる程度には小さいが、定期的なオブザーバ接続によるオーバーヘッドが許容できるレベルに収まる程度には大きい値に設定することをお薦めします。

0(ゼロ)

5.5.2.6 ファスト・スタート・フェイルオーバーの有効化(タスク6): 追加のファスト・スタート・フェイルオーバー条件の有効化(省略可能)

デフォルトでは、構成された時間しきい値(FastStartFailoverThreshold)の経過後にオブザーバもスタンバイもプライマリにアクセスできないと、ファスト・スタート・フェイルオーバーが実行されます。

必要に応じて、ファスト・スタート・フェイルオーバーを発生させるデータベース健全性条件を指定することができます。次の表に、これらの条件を示します。

健全性条件

説明

デフォルトで有効化

データファイル・オフライン

書込みエラーのためにデータファイルがオフラインになりました。

はい

破損したディクショナリ

重要なデータベースのディクショナリが破損しました。現時点では、この状態は、データベースがオープンされている場合にのみ検出されます。

はい

破損した制御ファイル

ディスク障害のために制御ファイルが永続的に破損しました。

はい

アクセス不可能なログ・ファイル

I/OエラーのためにLGWRがログ・グループのどのメンバーにも書き込むことができません。

いいえ

スタック・アーカイバ

デバイスに空き容量がないかデバイスを使用できないためにアーカイバがREDOログをアーカイブできません。

いいえ

Oracle RAC構成では、アクセス不可能なログ・ファイルおよびスタック・アーカイバの健全性条件は、単一インスタンスにのみ適用できます。これらの条件によるファスト・スタート・フェイルオーバーは、Oracle Clusterwareによって提供される可用性オプションに優先して実行されるので、有効化する前によく検討してください。

Cloud ControlまたはDGMGRLのENABLE FAST_START FAILOVER CONDITIONコマンドおよびDISABLE FAST_START FAILOVER CONDITIONコマンドを使用して、ファスト・スタート・フェイルオーバーが実行される特定の条件を指定できます。

5.5.2.7 ファスト・スタート・フェイルオーバーの有効化(タスク7): DGMGRLまたはCloud Controlの使用

Cloud Controlのファスト・スタート・フェイルオーバー・ウィザードまたはDGMGRLのENABLE FAST_START FAILOVERコマンドを使用して、ファスト・スタート・フェイルオーバーを有効化します。ファスト・スタート・フェイルオーバーを有効化するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方が動作しており、接続され、さらに「ファスト・スタート・フェイルオーバーを有効化するための前提条件」にリストされた前提条件をすべて満たしている必要があります。

Cloud Controlを使用したファスト・スタート・フェイルオーバーの有効化

Cloud Controlでファスト・スタート・フェイルオーバーを有効にするには、ファスト・スタート・フェイルオーバー・ウィザードを使用します。Oracle Data Guardの「概要」ページで、「ファスト・スタート・フェイルオーバー」ステータス・フィールドの横にある「無効」をクリックして、「ファスト・スタート・フェイルオーバー」ページを開きます。次に、「ファスト・スタート・フェイルオーバー: モードを変更」ページで、「有効」をクリックします。Cloud Controlによってオブザーバが起動されます。次に、「ファスト・スタート・フェイルオーバー: 構成」ページで、フェイルオーバーのターゲットとするスタンバイ・データベースを選択します。役立つアドバイスについては、「ターゲット・スタンバイ・データベースの選択」を参照してください。このページでは、保護モードを変更できません。ファスト・スタート・フェイルオーバーは、現在の保護モードに従って有効化されます。現在構成されているモードが最大保護の場合、Cloud Controlは、モードを最大可用性にダウングレードします。

DGMGRLを使用したファスト・スタート・フェイルオーバーの有効化

DGMGRLを使用してファスト・スタート・フェイルオーバーを有効化するには、オブザーバ・コンピュータ上のデータベースを含むブローカ構成内のいずれかのデータベースに接続している間に、ENABLE FAST_START FAILOVERコマンドを発行します。次に例を示します。

DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.

参照:

- ENABLE FAST_START FAILOVER

- 使用例6: ファスト・スタート・フェイルオーバーの有効化とオブザーバの起動

注意:

スタンバイ・データベースが事前の予告なしにプライマリ・ロールを引き継ぐ場合があるため、ターゲット・スタンバイ・サイトでの管理はプライマリ・サイトでの管理と同じくらい包括的である必要があります。スタッフ・サポート、ハードウェアとソフトウェア、セキュリティ(ソフトウェアとサイトの両方)、ネットワーク接続および帯域幅が両方のサイトで同等である必要があります。

5.5.2.8 ファスト・スタート・フェイルオーバーの有効化(タスク8): オブザーバの起動

オブザーバを起動するには、プライマリ・データベースが実行されている必要があります。

ファスト・スタート・フェイルオーバーを有効化する前または後にオブザーバを起動できます。ファスト・スタート・フェイルオーバーが有効化されている場合、オブザーバは、プライマリ・データベースおよびターゲット・スタンバイ・データベースのステータスおよび接続の監視をただちに開始します。ファスト・スタート・フェイルオーバーが有効化されていない場合、オブザーバは、ファスト・スタート・フェイルオーバーが有効化されるまで待機してから監視を開始します。

Cloud Controlを使用したオブザーバの起動

Cloud Controlエージェントがオブザーバ・コンピュータにインストールされている場合、Cloud Controlを介してファスト・スタート・フェイルオーバーを有効にすると、オブザーバが自動的に起動されます。エージェントが存在しない場合、DGMGRLコマンドライン・インタフェースに関する次の手順を実行して、オブザーバを手動で起動する必要があります。

DGMGRLを使用したオブザーバの起動

DGMGRLを使用してオブザーバを起動するには、オブザーバ・コンピュータで次のコマンドを発行します。

DGMGRL> START OBSERVER;

オブザーバはSTART OBSERVERコマンドを発行したときに作成され、継続的に実行されるプロセスです。そのため、別のDGMGRLセッションからSTOP OBSERVERコマンドを発行するまで、オブザーバ・コンピュータ上のコマンドライン・プロンプトは戻されません。コマンドを発行し、ブローカ構成と対話するには、別のDGMGRLクライアント・セッションにより接続する必要があります。

詳細は、START OBSERVERコマンドを参照してください。

5.5.2.9 ファスト・スタート・フェイルオーバーの有効化(タスク9): ファスト・スタート・フェイルオーバー環境の検証

ファスト・スタート・フェイルオーバー構成の準備が整っているかどうかを検証するには、プライマリ・データベースでDGMGRLのSHOW CONFIGURATION VERBOSEコマンドまたはSHOW FAST_START FAILOVERコマンドを発行します。次に例を示します。

DGMGRL> SHOW FAST_START FAILOVER;

Fast-Start Failover: ENABLED
Threshold: 60 seconds
Target: South_Sales
Observer: observer.example.com
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Observer Reconnect: (none)
Observer Override: FALSE

Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES

Oracle Error Conditions:
(none)

次の各項では、ファスト・スタート・フェイルオーバー環境の詳細を説明しています。

- ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行

- ファスト・スタート・フェイルオーバーが有効化されている場合の制限事項

- ファスト・スタート・フェイルオーバーが有効化されている場合のプライマリ・データベースの停止

- ファスト・スタート・フェイルオーバーが有効化されている場合の手動によるロール変更の実行

5.5.2.10 ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行

ファスト・スタート・フェイルオーバーを有効化してオブザーバを起動した後は、オブザーバが継続的に環境を監視してプライマリ・データベースが使用可能であることを確認します。この項では、オブザーバがファスト・スタート・フェイルオーバーの必要性を判別し、必要に応じてフェイルオーバーを実行するための手順をリストしています。

1. 環境を監視し、プライマリ・データベースが使用可能であることを確認します。
次の状況のように、プライマリ・データベースがクラッシュした場合、またはオブザーバとの接続が失われた場合、オブザーバはFastStartFailoverThreshold構成プロパティで指定されている秒数を待機してから、ファスト・スタート・フェイルオーバーを試行します。

- プライマリ・データベースと、オブザーバおよびターゲット・スタンバイ・データベースの両方との接続が失われた場合

- インスタンス障害
単一インスタンスのプライマリ・データベース(Oracle RACまたは非Oracle RAC)、またはOracle RACプライマリ・データベースのすべてのインスタンスに障害が発生した場合、オブザーバがファスト・スタート・フェイルオーバーを試行します。

- 強制終了
単一インスタンスのプライマリ・データベース(Oracle RACまたは非Oracle RAC)、またはOracle RACプライマリ・データベースのすべてのインスタンスがABORTオプションにより停止された場合、オブザーバがファスト・スタート・フェイルオーバーを試行します。他のタイプのデータベース停止(NORMAL、IMMEDIATE、TRANSACTIONAL)では、ファスト・スタート・フェイルオーバーは試行されません。

次の状況では、オブザーバはしきい値を超えるまで待機せずに、ファスト・スタート・フェイルオーバーを実行します。

- ユーザーが構成可能な条件
オブザーバは、ユーザーが構成可能な条件が検出されたと判断すると、ファスト・スタート・フェイルオーバーを試行します。

- DBMS_DG.INITIATE_FS_FAILOVERのアプリケーション・コール
アプリケーションがこの機能をコールし、SUCCESSステータスを受け取ると、オブザーバがファスト・スタート・フェイルオーバーを試行します。

2. FastStartFailoverThresholdにより指定された時間内に再接続します。
プライマリ・データベースに可用性の問題があることをオブザーバが検出した場合、オブザーバは通常、FastStartFailoverThreshold構成プロパティに指定された時間内にプライマリ・データベースに再接続しようとします。FastStartFailoverThresholdの時間間隔は、オブザーバがプライマリ・データベースに障害があることを最初に検出したときに開始されます。

ユーザーが構成可能な条件が発生したことをオブザーバが検出した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数でファスト・スタート・フェイルオーバーを要求した場合、FastStartFailoverThresholdプロパティに指定された時間間隔は無視されます。

プライマリ・データベースがOracle Real Application Clusters(Oracle RAC)データベースである場合、オブザーバは残りのプライマリ・インスタンスのいずれかに接続しようとします。Oracle RACプライマリ・データベースを構成するすべてのインスタンスに障害が発生したことが検出されていないかぎり、ファスト・スタート・フェイルオーバーは実行されません。オブザーバは、データベース・プロパティDGConnectIdentifierまたはObserverConnectIdentifierに指定された値を使用して、プライマリ・データベースおよびファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースに接続します。オブザーバは、これらのプロパティに指定された値を使用して、Oracle RACデータベースの任意のインスタンスに接続できる必要があります。

3. ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態であることを確認します。
ファスト・スタート・フェイルオーバーが開始されると、オブザーバはターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーする準備ができているかどうかを確認します。

次の場合、ファスト・スタート・フェイルオーバーは実行できません。

- ファスト・スタート・フェイルオーバーが有効でない場合

- オブザーバがターゲット・スタンバイ・データベースに接続できない場合

参照:

オブザーバが動作していない場合は、「オブザーバに障害が発生した場合の動作」を参照

- ブローカ構成の現在の状態に関して、オブザーバおよびターゲット・スタンバイ・データベースに一貫性がない場合

- オブザーバが動作していない場合

- 保護モードが最大可用性で、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていない場合

- 保護モードが最大パフォーマンスで、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースのREDO適用時点がプライマリ・データベースのREDO生成時点からFastStartFailoverLagLimit構成プロパティで指定された時間を超えて遅れる場合

- ターゲット・スタンバイ・データベースがプライマリ・データベースと通信している場合。ただし、ObserverOverride構成プロパティがTRUEに設定されている場合は、フェイルオーバーが試みられます。

- ターゲット・スタンバイ・データベースのV$DATABASEビュー内のFS_FAILOVER_STATUS列に、ファスト・スタート・フェイルオーバーを実行できない理由が表示された場合

- 手動フェイルオーバーがすでに進行中です。手動フェイルオーバーの詳細は、「手動フェイルオーバー」を参照してください。

- ABORTオプションを使用せずにプライマリ・データベースを停止した場合

4. ファスト・スタート・フェイルオーバーを開始します。
ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態である場合、オブザーバの指示により、ただちにターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーします。他のなんらかの理由でフェイルオーバーを実行できない場合、オブザーバはスタンバイ・データベースでフェイルオーバーの準備ができたかどうかをチェックし続けます。ただし、オブザーバはプライマリ・データベースへの再接続も無期限に試行し続けます。スタンバイがフェイルオーバーに同意する前にプライマリ・データベースに再接続すると、オブザーバはファスト・スタート・フェイルオーバーの開始の試行を中止します。

5. 元のプライマリ・データベースを新規スタンバイ・データベースとして回復します。
ファスト・スタート・フェイルオーバーが正常に完了した後、元のプライマリ・データベースへの接続が再確立され、FastStartFailoverAutoReinstate構成プロパティがTRUEに設定されている場合、オブザーバは元のプライマリ・データベースの新規スタンバイ・データベースとしての回復を試行します。FastStartFailoverPmyShutdown構成プロパティをTRUEに設定した場合、元のプライマリ・データベースは自動的に停止しているため、オブザーバが回復を試行する前に、手動で再起動する必要があります。

プライマリがクラッシュしたか、オブザーバおよびターゲット・スタンバイ・データベースから分離したためにファスト・スタート・フェイルオーバーが発生した場合にのみ、これらのプロパティがプライマリの停止および自動回復の実行を左右する点に注意してください。

参照:

回復の詳細は、「ブローカ構成に含まれる元のプライマリ・データベースの回復」を参照

5.5.2.11 ファスト・スタート・フェイルオーバーが有効化されている場合の制限事項

ファスト・スタート・フェイルオーバーが有効化されている場合、次の操作は禁止されています。

- 変更:

- 構成保護モード

- REDOをターゲット・スタンバイ・データベースまたは現在プライマリ・ロールになっているデータベースに送信するために使用されるREDO転送モード

- プライマリ・データベースまたはターゲット・スタンバイ・データベースのFastStartFailoverTarget構成プロパティ

- プライマリ・データベースまたはターゲット・スタンバイ・データベースのRedoRoutesプロパティ

- 遠隔同期インスタンスがプライマリ・データベースからREDOを受け取ってターゲット・スタンバイ・データベースにREDOを送信する場合、そのRedoRoutesプロパティ

- 無効化または削除:

- ブローカ構成

- ファスト・スタート・フェイルオーバーのターゲットであるスタンバイ・データベース

- プライマリ・データベースからREDOを受け取ってターゲット・スタンバイ・データベースにREDOを送信する場合の遠隔同期インスタンス

- 手動フェイルオーバーの実行:

- 「ファスト・スタート・フェイルオーバーが有効化されている場合の手動によるロール変更の実行」にリストされた条件を満たしていない場合

- ファスト・スタート・フェイルオーバーのターゲットとして構成されていないスタンバイ・データベースに対する実行
構成がファスト・スタート・フェイルオーバーを実行可能な状態かどうかを判断するには、DGMGRLのSHOW DATABASE <target-standby-database>コマンドを発行するか、プライマリ・データベースまたはターゲット・スタンバイ・データベースのいずれかでV$DATABASEビューを問い合せます。ファスト・スタート・フェイルオーバーを実行できる状態である場合、V$DATABASE.FS_FAILOVER_STATUSの列値は、最大可用性モードではSYNCHRONIZED、最大パフォーマンス・モードではTARGET UNDER LAG LIMITです。ターゲット・スタンバイ・データベースについては、FS_FAILOVER_OBSERVER_PRESENT列にはYESと表示されます。

- ファスト・スタート・フェイルオーバーのターゲットとして構成されていないスタンバイ・データベースへのスイッチオーバーの実行

- スタンバイ・データベースがプライマリ・データベースと同期化されている場合を除く、最大可用性モードで動作している構成のターゲット・スタンバイ・データベースへのスイッチオーバーの実行

- スタンバイ・データベースがプライマリ・データベースのラグ制限内にある場合を除く、最大パフォーマンス・モードで動作している構成のターゲット・スタンバイ・データベースへのスイッチオーバーの実行

- プライマリ・データベースのオープンの試行。オープンを試行すると、次のエラーが戻される場合あります。

ORA-16649: possible failover to another database prevents this database from being opened

ファスト・スタート・フェイルオーバーの妥当性チェックが失敗するか、2分未満で完了しないと、このエラーが戻されることがあります。

- スタンバイがマウントされているが、オープンされていない場合、SQL ALTER DATABASE MOVE DATAFILEコマンドを使用して、ファスト・スタート・フェイルオーバーのターゲットとなっているフィジカル・スタンバイ上のオンライン・データ・ファイルを名称変更するか、再配置します。

5.5.2.12 ファスト・スタート・フェイルオーバーが有効化されている場合のプライマリ・データベースの停止

プライマリ・データベースまたはスタンバイ・データベースが通常の方法で(SHUTDOWN NORMAL、SHUTDOWN IMMEDIATEまたはSHUTDOWN TRANSACTIONALを使用して)停止された場合、ファスト・スタート・フェイルオーバーは起動されません。通常の停止では、プライマリ・データベースおよびスタンバイ・データベースが再度接続され通信状態になるまで、ファスト・スタート・フェイルオーバーを実行できません。

5.5.2.13 ファスト・スタート・フェイルオーバーが有効化されている場合の手動によるロール変更の実行

ファスト・スタート・フェイルオーバーが有効化されている場合でも、次の条件を満たしているかぎり、スイッチオーバーまたは手動フェイルオーバーを実行できます。

- ロール変更の対象が、プライマリ・データベース上のFastStartFailoverTargetデータベース・プロパティで指定されたスタンバイ・データベースと同一であること。

- ターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていること(最大可用性モードで動作している構成の場合)またはターゲット・スタンバイ・データベースがラグ制限内にあること(最大パフォーマンス・モードで動作している構成の場合)。

- 手動フェイルオーバーの場合、オブザーバが起動しており、ターゲット・スタンバイ・データベースと通信していること。手動フェイルオーバーを実行する前に、プライマリ・データベースが停止されていることを確認する必要があります。

注意:

必要な場合は、FORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化できます。「ファスト・スタート・フェイルオーバーの無効化」を参照してください。

参照:

スイッチオーバーおよび手動フェイルオーバーの詳細は、それぞれ「スイッチオーバー」および「手動フェイルオーバー」を参照してください

5.5.3 アプリケーションによるファスト・スタート・フェイルオーバーの指示

DBMS_DG PL/SQLパッケージを使用して、特定のアプリケーションのファスト・スタート・フェイルオーバー設定をカスタマイズできます。アプリケーションに独自に認識される重大な条件が検出されたとき、アプリケーションはDBMS_DG.INITIATE_FS_FAILOVER機能をコールして、即時ファスト・スタート・フェイルオーバーを開始できます。この機能は、接続から構成内のプライマリ・データベースまたはいずれかのスタンバイ・データベースにコールできます。プロシージャがコールされたデータベースは、オブザーバにそれを通知します。フェイルオーバー・ターゲット・データベースがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)、オブザーバによりただちにファスト・スタート・フェイルオーバーが開始されます。オブザーバによってファスト・スタート・フェイルオーバーが開始されると、プライマリ・データベースは自動的に停止します。オブザーバは元のプライマリ・データベースの回復を試行しません。

構成がフェイルオーバー不能の場合、DBMS_DG.INITIATE_FS_FAILOVER機能は、ORAエラー番号(例外ではなく)を返して、ファスト・スタート・フェイルオーバーを実行できないことをコール元に通知します。

注意:

可能であればオブザーバがフェイルオーバーを開始するため、アプリケーションでDBMS_DG.INITIATE_FS_FAILOVER機能をコールする際には注意が必要です。

参照:

DBMS_DGパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

5.5.4 ファスト・スタート・フェイルオーバー構成の統計およびステータスの表示

オブザーバが起動しており、構成がファスト・スタート・フェイルオーバー可能な状態かどうかを確認するには、DGMGRLのSHOW DATABASE <target-standby-database>コマンドを発行するか、ターゲット・スタンバイ・データベースでV$DATABASEビューを問い合せます。

V$FS_FAILOVER_STATSビューを問い合せて、システムで発生しているファスト・スタート・フェイルオーバーに関する統計を表示することもできます。

次に、DGMGRL SHOWコマンドを使用してファスト・スタート・フェイルオーバー情報を表示する例を示します。次のビューについても説明します。

- V$DATABASEビュー

- V$FS_FAILOVER_STATSビュー

例1: SHOW FAST_START FAILOVER

DGMGRLのSHOW FAST-START FAILOVERコマンドは、すべてのファスト・スタート・フェイルオーバー関連情報を表示します。次に例を示します。

DGMGRL> SHOW FAST_START FAILOVER;

Fast-Start Failover: ENABLED
Threshold:           60 seconds
Target:              South_Sales
Observer:            observer.example.com
Lag Limit:           30 seconds (not in use)
Shutdown Primary:    TRUE
Auto-reinstate:      TRUE
Observer Reconnect: (none)
Observer Override: FALSE

Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile          YES
Corrupted Dictionary           YES
Inaccessible Logfile            NO
Stuck Archiver                  NO
Datafile Offline               YES

Oracle Error Conditions:
(none)

例2: SHOW CONFIGURATION VERBOSE

次の例は、DRSolution構成のファスト・スタート・フェイルオーバー情報を示しています。

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
North_Sales - Primary database
South_Sales - (*) Physical standby database

(*) Fast-Start Failover target

Properties:
FastStartFailoverThreshold     = '60'
OperationTimeout               = '30'
TraceLevel                     = 'USER'
FastStartFailoverLagLimit      = '30'
CommunicationTimeout           = '180'
ObserverReconnect              = '0'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown   = 'TRUE'
BystandersFollowRoleChange     = 'ALL'
ObserverOverride               = 'FALSE'
ExternalDestination1           = ''
ExternalDestination2           = ''
PrimaryLostWriteAction         = 'CONTINUE'

Fast-Start Failover: ENABLED

Threshold: 30 seconds
Target: South_Sales
Observer: observer.example.com
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Observer Reconnect: (none)
Observer Override: FALSE

Configuration Status:
SUCCESS

5.5.4.1 V$DATABASEビュー

V$DATABASEビューを問い合せて、オブザーバが起動しており、構成がファスト・スタート・フェイルオーバー可能な状態かどうかを確認できます。V$DATABASEビューを問い合せる場合、次の列に特に注意してください。

- 表5-1に示す値が含まれる可能性のあるFS_FAILOVER_STATUS列。V$DATABASE.FS_FAILOVER_STATUS列にDISABLEDの値が含まれる場合、ファスト・スタート・フェイルオーバーに関連する残りの列に対し戻される値(V$DATABASE.FS_FAILOVER_*)は無関係になります。

- オブザーバが実行され、データベースをアクティブにpingしているかどうかを示すFS_FAILOVER_OBSERVER_PRESENT列。

表5-1 V$DATABASEビューのFS_FAILOVER_STATUS列

列値

説明

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

BYSTANDER

ファスト・スタート・フェイルオーバーは有効化されていますが、このスタンバイ・データベースはファスト・スタート・フェイルオーバーのターゲットではありません。このデータベースはファスト・スタート・フェイルオーバーのステータス情報を提供できません。

有効

DISABLED

ファスト・スタート・フェイルオーバーは無効化されています。

不可

LOADING DICTIONARY

プライマリ・データベースのデータ・ディクショナリのコピーをロードし終えていないロジカル・スタンバイ・データベースにのみ表示されます。

不可

PRIMARY UNOBSERVED

ターゲット・スタンバイ・データベースが、プライマリ・データベースとSYNCHRONIZEDされているかプライマリ・データベースのTARGET UNDER LAG LIMITにあり、オブザーバに接続されているとき、プライマリ・データベースがオブザーバに接続されていない場合、ターゲット・スタンバイ・データベースにのみ表示されます。

不可

REINSTATE FAILED

障害が発生したプライマリ・データベースの新規スタンバイ・データベースとしての回復に失敗しました。ブローカのdrc*ログ・ファイルの詳細は、「診断情報のソース」を参照してください。

完了済

REINSTATE REQUIRED

障害が発生したプライマリ・データベースは、新規プライマリに対する新規スタンバイ・データベースとして回復する必要があります。オブザーバにより回復プロセスが自動的に開始されます。REINSTATE REQUIREDは、ファスト・スタート・フェイルオーバーの発生後にのみ存在し、新規プライマリ・データベースと回復を実行しているデータベースの両方に表示されます。回復が完了すると、両方のデータベースでクリアされます。

完了済

STALLED

ターゲット・スタンバイ・データベースとの接続が切断され、UNSYNCHRONIZED状態(最大可用性モード)またはTARGET OVER LAG LIMIT状態(最大パフォーマンス・モード)の変更がターゲット・スタンバイ・データベースとオブザーバのどちらからも確認できない場合、プライマリ・データベースに表示されます。これらの条件でプライマリが無期限にストールするには、FastStartFailoverPmyShutdown構成プロパティの値がFALSEである必要があることに注意してください。このプロパティの値がTRUEの場合、プライマリは、FastStartFailoverThresholdプロパティで指定された秒数の間ストールした後に停止します。

フェイルオーバーが実行された可能性が高いため、プライマリ・データベースが停止またはストールします。

注意: この状態は、ファスト・スタート・フェイルオーバーが可能で、ターゲット・スタンバイ・データベースもオブザーバも存在しないときに起動し、データベースのオープンを継続可能かどうかを確認した場合にもプライマリで発生します。

可

TARGET OVER LAG LIMIT

構成が最大パフォーマンス・モードで動作しているとき、プライマリ・データベースのREDO生成時点からのスタンバイ・データベースのREDO適用時点の遅れが、FastStartFailoverLagLimit構成プロパティに指定された秒数を超過した場合に表示されます。

不可

TARGET UNDER LAG LIMIT

構成が最大パフォーマンス・モードで動作しているとき、プライマリ・データベースのREDO生成時点からのスタンバイ・データベースのREDO適用時点の遅れが、FastStartFailoverLagLimit構成プロパティに指定された秒数を超過していない場合に表示されます。

可

SUSPENDED

プライマリ・データベースまたはターゲット・スタンバイ・データベースが制御された方法で(ABORTオプションではなく、NORMAL、IMMEDIATEまたはTRANSACTIONALオプションを使用して)停止された場合、ターゲット・スタンバイ・データベースにのみ表示されます。この場合、ファスト・スタート・フェイルオーバーは禁止されます。プライマリ・データベースとの接続がリストアされると、SUSPENDEDがクリアされます。

不可

SYNCHRONIZED

プライマリ・データベースとターゲット・スタンバイ・データベースが同期化されており、構成が最大可用性モードで動作している場合に表示されます。

ターゲット・スタンバイ・データベースがSYNCHRONIZEDを表示し、FS_FAILOVER_OBSERVER_PRESENT列がYESを表示する場合に可能です。

UNSYNCHRONIZED

ターゲット・スタンバイ・データベースがプライマリ・データベースのすべてのREDOデータを持たず、構成が最大可用性モードで動作している場合に表示されます。

不可

5.5.4.2 V$FS_FAILOVER_STATSビュー

ファスト・スタート・フェイルオーバーは完全に自動化されており、いつでも発生する可能性があるので、プライマリ・データベースのこのビューを問い合せて、システムで発生したファスト・スタート・フェイルオーバーに関する次の統計を表示する場合に役立ちます。

- LAST_FAILOVER_TIMEは、最後に発生したファスト・スタート・フェイルオーバーのタイムスタンプを示します。

- LAST_FAILOVER_REASONは、最後に発生したファスト・スタート・フェイルオーバーの原因を示します。

次に、V$FS_FAILOVER_STATSビューの問合せの例を示します。

SQL> SELECT LAST_FAILOVER_TIME, LAST_FAILOVER_REASON FROM V$FS_FAILOVER_STATS;

LAST_FAILOVER_TIME
--------------------
LAST_FAILOVER_REASON
------------------------------------------------------------------------------------------------------------------------------------
02/13/2007 16:53:10
Primary Disconnected

5.5.5 ファスト・スタート・フェイルオーバーの無効化

ファスト・スタート・フェイルオーバーを無効化すると、オブザーバはターゲット・スタンバイ・データベースへのフェイルオーバーを開始できなくなります。この場合、手動フェイルオーバーが可能な場合があります。手動フェイルオーバーの詳細は、「手動フェイルオーバー」を参照してください。

注意:

ファスト・スタート・フェイルオーバーを無効にしても、オブザーバは停止されません。オブザーバを停止するには、「オブザーバの停止」を参照してください。

ファスト・スタート・フェイルオーバーを無効にするには、Cloud Controlのファスト・スタート・フェイルオーバー・ウィザードまたはDGMGRLのDISABLE FAST_START FAILOVER [FORCE]コマンドを使用します。FORCEオプションを使用すると、エラーが発生した場合でも、接続先のデータベースでファスト・スタート・フェイルオーバーが無効化されます。FORCEオプションが必要かどうかは、プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在するかどうかによって決まります。

- プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在し、接続先のデータベースがプライマリ・データベースとネットワークで接続されている場合、FORCEオプションを使用しても効果はありません。オプションを指定せずにDISABLE FAST_START FAILOVERを使用してください。この方法では、ブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーが無効化されます。
無効化操作中にエラーが発生した場合、ブローカによりエラー・メッセージが戻され、無効化操作が停止されます。

- プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在しないか、または接続先のデータベースにプライマリ・データベースとのネットワーク接続が存在しない場合、DISABLE FAST_START FAILOVERをFORCEオプションとともに使用することを考慮します。
DISABLE FAST_START FAILOVER FORCEコマンドを発行した場合、ブローカはブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーをi無効化できない場合があります。その結果、フェイルオーバーの条件を満たしているとオブザーバが判別した場合に、オブザーバがターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーを実行しないという保証がなくなります。次のリストに、プライマリ・データベース、ターゲット・スタンバイ・データベースおよびファスト・スタート・フェイルオーバーのターゲットでないスタンバイ・データベースでDISABLE FAST_START FAILOVER FORCEコマンドが発行された場合に、ブローカ構成でファスト・スタート・フェイルオーバーが無効化される範囲を示しています。

次のデータベースでこのコマンドを発行した場合、次のようになります。

- プライマリ・データベースとの接続が存在しないターゲット・スタンバイ・データベースで発行した場合、ターゲット・スタンバイ・データベースでのみファスト・スタート・フェイルオーバーが無効化されます。この場合、オブザーバではフェイルオーバーの条件を満たしていてもファスト・スタート・フェイルオーバーを実行できません。ファスト・スタート・フェイルオーバーの発生を確実に防ぐには、ターゲット・スタンバイ・データベースに接続しているときにFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化します。
プライマリ・データベースおよびターゲット・スタンバイ・データベースのネットワーク接続が回復すると、ブローカによりブローカ構成全体のファスト・スタート・フェイルオーバーが無効化されます。

- プライマリ・データベースで発行した場合、構成内のネットワーク接続が確立されたすべてのデータベースで、ファスト・スタート・フェイルオーバーの無効化が試行されます。プライマリ・データベースとターゲット・スタンバイ・データベースとの接続が確立されていない場合、ターゲット・スタンバイ・データベースではファスト・スタート・フェイルオーバーが有効のままとなり、フェイルオーバーの条件を満たした場合にオブザーバによりファスト・スタート・フェイルオーバーが試行されます。

注意:

この処理を実行すると、ファスト・スタート・フェイルオーバーが発生した場合に、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。このため、ターゲット・スタンバイ・データベースにこのコマンドを最初に発行する必要があります。

- プライマリ・データベースとの接続が存在しない別のスタンバイ・データベースで発行した場合、このデータベースではファスト・スタート・フェイルオーバーが無効化されます。ターゲット・スタンバイ・データベースでファスト・スタート・フェイルオーバーが無効化されていないため、フェイルオーバーの条件を満たした場合に、オブザーバによりターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーが試行される場合があります。
プライマリ・データベースとスタンバイ・データベース(非ターゲット)のネットワーク接続が回復すると、ブローカの現在のファスト・スタート・フェイルオーバーの設定(ENABLEDまたはDISABLED)がターゲットでないスタンバイに伝播されます。

注意:

ネットワークが切断されており、プライマリ・データベースまたはプライマリ・データベースと接続されていないスタンバイ・データベースでDISABLE FAST_START FAILOVER FORCEコマンドを発行した場合、ブローカ構成内の一部のデータベースでファスト・スタート・フェイルオーバーが無効化されない場合があります。結果として、フェイルオーバーの条件を満たしている場合、オブザーバによりターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーが開始される可能性があります。これにより、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。

FORCEオプションを必要とする条件

FORCEオプションを使用しないファスト・スタート・フェイルオーバーの無効化が正常に実行されるのは、コマンドが発行されたデータベースとプライマリ・データベースの間にネットワーク接続が存在し、プライマリ・データベースとターゲット・スタンバイ・データベースの間にネットワーク接続が存在する場合のみです。ファスト・スタート・フェイルオーバーを無効化するには、この方法をお薦めします。

ただし、プライマリ・データベースとターゲット・スタンバイ・データベースの間にネットワーク接続が存在しない場合、またはファスト・スタート・フェイルオーバーの無効化コマンドを発行したデータベースとプライマリ・データベースとの間にネットワーク接続が存在しない場合に、ファスト・スタート・フェイルオーバーを無効化する必要があることも考えられます。ネットワーク接続が失われている場合、フェイルオーバーの条件を満たした場合に、オブザーバによりターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーが試行される場合があるので注意してください。次の場合は、ファスト・スタート・フェイルオーバーの無効化にFORCEオプションを使用することをお薦めします。

- ネットワーク障害により、プライマリ・データベースがオブザーバおよびターゲット・スタンバイ・データベースから分離された場合(フェイルオーバーの条件を満たす前)。
この場合、プライマリ・データベースが分離されている間にファスト・スタート・フェイルオーバーが実行された可能性があるため、プライマリ・データベースがストールし、トランザクションをコミットできなくなります。ネットワークの切断が長時間にわたると予想され、プライマリ・データベースを使用可能にする必要がある場合は、まず、ターゲット・スタンバイ・データベースにファスト・スタート・フェイルオーバーが実行されていないことを確認します。次に、プライマリ・データベースでFORCEオプションによりファスト・スタート・フェイルオーバーを無効化します。可能な場合、プライマリ・データベースでFORCEオプションによりファスト・スタート・フェイルオーバーを無効化する前に、ターゲット・スタンバイ・データベースにファスト・スタート・フェイルオーバーが実行されていないことを確認します。

注意:

この処理により、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。ターゲット・スタンバイでFORCEオプションによりファスト・スタート・フェイルオーバーを最初に無効化しておくと、これを回避できます。

- 構成内のスタンバイ・データベースに手動フェイルオーバーを実行する場合(たとえば、プライマリ・データベースおよびターゲット・スタンバイ・データベースがフェイルオーバー可能でないときにプライマリ・データベースで障害が発生したため)。
この場合、データベースがフェイルオーバー可能でないため、ファスト・スタート・フェイルオーバーを実行できません。同じ理由で、ターゲット・スタンバイ・データベースへの手動フェイルオーバーを実行できません。続行するには、まずFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にしてから、手動フェイルオーバーを実行する必要があります。

注意:

この処理によりデータが失われ、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。ターゲット・スタンバイでFORCEオプションによりファスト・スタート・フェイルオーバーを最初に無効化しておくと、これを回避できます。

- ターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーに失敗した場合。
なんらかの理由でフェイルオーバーに失敗した場合、ターゲット・スタンバイ・データベースがフェイルオーバー可能かどうかにかかわらず、ターゲット・スタンバイ・データベースが動作不能になる可能性があります。フェイルオーバーに使用できる別のスタンバイ・データベースが存在する場合、まずそのスタンバイ・データベースでFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化してから、そのスタンバイ・データベースへの手動フェイルオーバーを実行できます。

- まもなくプライマリ・データベースによりサービスが再開されるため、ファスト・スタート・フェイルオーバーを実行しないようにする場合。
この場合、ターゲット・スタンバイ・データベースでFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にします。プライマリ・データベースとターゲット・スタンバイ・データベースとの接続が回復すると、構成内のすべてのデータベースでファスト・スタート・フェイルオーバーが無効化されます。

Cloud Controlを使用したファスト・スタート・フェイルオーバーの無効化

ファスト・スタート・フェイルオーバー・ウィザードで「無効化」をクリックします。次に、「続行」をクリックして次のページに進みます。詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

DGMGRLを使用したファスト・スタート・フェイルオーバーの無効化

DISABLE FAST_START FAILOVERコマンドまたはDISABLE FAST_START FAILOVER FORCEコマンドを発行します。詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」の「DISABLE FAST_START FAILOVER」コマンドを参照してください。

5.5.6 ファスト・スタート・フェイルオーバーのパフォーマンスに関する考慮事項

ファスト・スタート・フェイルオーバーを使用する際のパフォーマンスを向上させるには、次の推奨事項を考慮します。

- フェイルオーバー時間は、ターゲット・スタンバイ・データベース(フィジカルまたはロジカル・スタンバイ・データベース)がプライマリ・データベースから受け取ったREDOデータをすべて適用したかどうかによって決まります。

- 最大パフォーマンス・モードで動作している構成でファスト・スタート・フェイルオーバーを有効化すると、REDOデータが非同期でターゲット・スタンバイに転送されるため、プライマリ・データベースでの全体的なパフォーマンスが向上します。この場合はデータが消失しないことが保証されないことに注意してください。

- スタンバイ・データベースへのREDOデータの適用がプライマリ・データベースのREDO適用率と一致した状態が保たれるように、リカバリを最適化する手順を実行すると、ファスト・スタート・フェイルオーバーが高速になります。ログ適用率を最適化するには、次のようにします。

- データベース・プロパティDelayMinsを設定することにより、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用を遅延させないでください(詳細は、「ログ適用サービスの管理」を参照してください)。

- フィジカル・スタンバイ・データベースのログ適用率のチューニングの詳細は、『Oracle Data Guard概要および管理』を参照してください。

- 次の場所にあるホワイト・ペーパー『Oracle Maximum Availability Architecture』を参照してください。
http://www.oracle.com/goto/maa

- FastStartFailoverLagLimit構成プロパティを設定する際は、パフォーマンスとデータ消失の可能性の間のトレードオフを考慮してください。

- ラグ制限を低くすると、データの消失は最小限に抑えられますが、プライマリ・データベースのパフォーマンスに影響を与える場合があります。

- ラグ制限を高くすると、消失データ量が増加する可能性がありますが、プライマリ・データベースのパフォーマンスへの影響は緩和されます。

5.5.7 オブザーバの管理

オブザーバは、ブローカのDGMGRLクライアント側コンポーネントに統合されており、プライマリ・データベースまたはスタンバイ・データベースおよびブローカ構成を管理するコンピュータとは異なるコンピュータ上で動作します。オブザーバは、継続的にファスト・スタート・フェイルオーバー環境を監視して、プライマリ・データベースが使用可能であることを確認します。(「ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行」を参照)。オブザーバの主な目的は、停止時間が長くなる可能性がある、手動フェイルオーバー・プロセスで必要な人的操作を少なくすることで、高可用性および完全自動コンピューティングを強化することです。

Cloud ControlのOracle Data Guardの概要ページまたはDGMGRLコマンドを使用して、オブザーバを管理できます。図5-2に、オブザーバによるファスト・スタート・フェイルオーバー構成の監視を示しています。

図5-2 ファスト・スタート・フェイルオーバー環境でのオブザーバ

次の各項では、オブザーバの管理情報を説明します。

- オブザーバのインストールおよび起動

- オブザーバに関する情報の表示

- オブザーバに障害が発生した場合の動作

- オブザーバの停止

- オブザーバの別のコンピュータへの移動

- オブザーバによるファスト・スタート・フェイルオーバー構成情報のメンテナンス方法

- オブザーバが実行中でファスト・スタート・フェイルオーバーが有効化されている場合の環境へのパッチ適用

5.5.7.1 オブザーバのインストールおよび起動

オブザーバは、プライマリ・システムおよびスタンバイ・システムとは別のコンピュータ・システムにインストールし、動作させる必要があります。オブザーバのインストールおよび起動は、ファスト・スタート・フェイルオーバーの使用における必須部分であり、次の各項で詳細に説明しています。

- 「Oracle Data Guardのインストール」では、オブザーバ・システムに、Oracle Client Administratorのみをインストールできるか、Oracle Database Enterprise EditionまたはPersonal Editionを完全インストールできるかのどちらかであることを説明しています。

- 「ファスト・スタート・フェイルオーバーの有効化」では、ファスト・スタート・フェイルオーバーを有効化する段階的なプロセスの一部として、オブザーバの起動方法を説明しています。DGMGRLを使用してオブザーバを起動する例は、「使用例6: ファスト・スタート・フェイルオーバーの有効化とオブザーバの起動」を参照してください。

ブローカ構成を監視するオブザーバは1つのみ存在できます。別のオブザーバを起動しようとすると、ブローカにより次のエラー・メッセージが戻されます。

ORA-16647: could not start more than one observer

オブザーバを起動するには、SYSDGまたはSYSDBA権限を持つアカウントでDGMGRLにログインできる必要があります。オブザーバは、DGMGRLでOracle Data Guard構成に接続したときに使用したSYS資格証明を使用してプライマリ・データベースおよびターゲット・スタンバイ・データベースに接続するOCIクライアントです。

参照:

- オブザーバとDGMGRLの間の互換性要件の詳細は、http://support.oracle.comにあるMy Oracle Supportノート1625597.1を参照してください

単一ホスト上での複数のオブザーバの起動

1つのOracleホームを使用して複数のオブザーバを起動し、各オブザーバで異なるファスト・スタート・フェイルオーバー構成を監視する場合は、FILE修飾子を使用して、監視する各構成に一意のオブザーバ構成ファイルの場所を指定してください。オブザーバが生成するロギングを取得する場合は、LOGFILEオプションを使用し、一意のファイル名を指定してください。次に例を示します。

% dgmgrl -logfile $ORACLE_HOME/rdbms/log/config1.log
DGMGRL> CONNECT /@primary1;
DGMGRL> START OBSERVER FILE=$ORACLE_HOME/dbs/config1.dat;

% dgmgrl -logfile $ORACLE_HOME/rdbms/log/config2.log
DGMGRL> CONNECT /@primary2;
DGMGRL> START OBSERVER FILE=$ORACLE_HOME/dbs/config2.dat;

5.5.7.2 オブザーバに関する情報の表示

オブザーバに関する情報を検索するには、V$DATABASEビューで次の列を問い合せます。

- FS_FAILOVER_OBSERVER_HOSTは、オブザーバが動作するコンピュータの名前を示します。

- FS_FAILOVER_OBSERVER_PRESENTは、オブザーバがローカル・データベースに接続しているかどうかを示します。

表5-2 V$DATABASEビューのFS_FAILOVER_OBSERVER_PRESENT列

列値(1)

説明

YES

オブザーバは現在ローカル・データベースに接続している

NO

オブザーバはローカル・データベースに接続していない

脚注1 この値は、Oracle Real Application Clusters(Oracle RAC)環境内の全インスタンスで一貫性が保たれています。つまり、オブザーバがOracle RAC内のインスタンスに接続されている場合、すべてのインスタンスにYESの値が示されます。

たとえば、ファスト・スタート・フェイルオーバーが実行可能かどうかを判断するには、ターゲット・スタンバイ・データベースで、FS_FAILOVER_STATUS列にSYNCHRONIZEDまたはTARGET UNDER LAG LIMITが表示されており、FS_FAILOVER_OBSERVER_PRESENT列にYESと表示されていることを確認します。次に例を示します。

データベース

FS_FAILOVER_STATUS

保護モード

FS_FAILOVER_OBSERVER_PRESENT

プライマリ

SYNCHRONIZED

最大可用性

YES

スタンバイ

SYNCHRONIZED

最大可用性

YES

プライマリ

TARGET UNDER LAG LIMIT

最大パフォーマンス

YES

スタンバイ

TARGET UNDER LAG LIMIT

最大パフォーマンス

YES

次の例では、プライマリ・データベースとオブザーバの間のネットワークに障害が発生したと仮定しています。この場合、FS_FAILOVER_STATUSおよびFS_FAILOVER_OBSERVER_PRESENT列は次の表に示すように表示され、ファスト・スタート・フェイルオーバーは実行されません。

データベース

FS_FAILOVER_STATUS

FS_FAILOVER_OBSERVER_PRESENT

プライマリ

SYNCHRONIZED

NO

スタンバイ

PRIMARY UNOBSERVED

YES

5.5.7.3 オブザーバに障害が発生した場合の動作

プライマリ・データベースとターゲット・スタンバイ・データベースの間の接続が維持された状態でオブザーバからの接続が失われた場合、ブローカにより、構成が監視されていないと報告されます。 構成およびデータベースのステータスにより、オブザーバが動作していないと報告され、次のいずれかのステータス・メッセージが戻されます。

ORA-16658: unobserved fast-start failover configuration
ORA-16820: fast-start failover observer is no longer observing this database

構成が監視されない状態の場合、ファスト・スタート・フェイルオーバーは実行できません。そのため、ターゲット・スタンバイ・データベースに障害が発生した場合でも、プライマリ・データベースはトランザクションの処理を続行できます。オブザーバとプライマリ・データベースとの接続が再確立され、プライマリ・データベースによりターゲット・スタンバイ・データベースに通知が送られると、構成ステータスによりSUCCESSステータスが戻されます。

参照:

ファスト・スタート・フェイルオーバー構成の統計およびステータスの表示

オブザーバの高可用性の実現

Oracle Enterprise Manager Cloud Control (Cloud Control)では、オブザーバ・プロセスが失敗したことを検出した場合の同じホスト上でのオブザーバの自動再起動がサポートされています。この自動再起動機能は、ファスト・スタート・フェイルオーバーが有効になるたびにアクティブ化されます。

Cloud Controlでは、最初のホストが失敗した場合の代替ホスト上でのオブザーバの自動再起動もサポートされています。代替オブザーバ・ホストの指定方法については、Cloud Controlオンライン・ヘルプを参照してください。

5.5.7.4 オブザーバのプライマリへの接続の管理

ObserverOverrideおよびObserverReconnectプロパティを使用すると、プライマリへの接続をさらに制御できます。

オブザーバが、FastStartFailoverThresholdプロパティで指定されているより長い期間、プライマリ・データベースへの接続を失った場合、スタンバイ・データベースへのフェイルオーバーが試みられます。FastStartFailoverThresholdプロパティで指定された期間内にスタンバイがプライマリからアクセスを受けた場合、フェイルオーバーは試行されません。

この動作をオーバーライドして、オブザーバがFastStartFailoverThresholdで指定された秒数より長い間プライマリにアクセスできない場合にファスト・スタート・フェイルオーバーが行われるようにするには、ObserverOverrideプロパティをTRUEに設定します。次に例を示します。

DGMGRL> EDIT CONFIGURATION SET PROPERTY ObserverOverride=TRUE;

通常、オブザーバは一度プライマリに接続したら、接続に障害が発生しないかぎり、再接続を試みません。プライマリへのネットワーク接続の健全性をテストする手段として、オブザーバがプライマリ・データベースに定期的に再接続する場合は、ObserverReconnect構成プロパティを使用します。これは、オブザーバがプライマリ・データベースに対して新しい接続を確立する頻度を指定します。次の例では、ObserverReconnectが30秒に設定されています。この場合、オブザーバは30秒ごとにプライマリ・データベースに対して新しい接続を確立します。

DGMGRL> EDIT CONFIGURATION SET PROPERTY ObserverReconnect=30;

5.5.7.5 オブザーバの停止

ファスト・スタート・フェイルオーバーを使用しない場合(「ファスト・スタート・フェイルオーバーの無効化」を参照)、またはオブザーバを別のホスト・マシンに移動する場合は(「オブザーバの別のコンピュータへの移動」を参照)、オブザーバを停止できます。

ファスト・スタート・フェイルオーバーが有効化されているときにオブザーバを停止するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースが接続されており、相互に通信している必要があります。オブザーバを停止しても、ファスト・スタート・フェイルオーバーは無効化されません。ただし、ターゲット・スタンバイ・データベースが監視されない状態の場合、ファスト・スタート・フェイルオーバーは実行できません。

ファスト・スタート・フェイルオーバーが有効化されているが、プライマリ・データベースとスタンバイ・データベースが相互に分離している場合にオブザーバを停止するには、FORCEオプションを使用してまずファスト・スタート・フェイルオーバーを無効化してから、オブザーバを停止する必要があります。(FORCEオプションを使用する際に考慮すべき重要事項については、「ファスト・スタート・フェイルオーバーの無効化」を参照してください。)

ファスト・スタート・フェイルオーバーが有効化されていない場合にオブザーバを停止するには、プライマリ・データベースが動作している必要があります。プライマリ・データベースとネットワークで接続されたブローカ構成内のデータベースに接続しているときは、次の方法でオブザーバを停止できます。

- Cloud Controlの使用
ファスト・スタート・フェイルオーバー・ウィザードの1ページ目で「オブザーバを停止」オプションを選択し、ページ下部の「続行」をクリックします。詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

- DGMGRLの使用
次のコマンドを発行します。

DGMGRL> STOP OBSERVER;

詳細は、STOP OBSERVERコマンドを参照してください。

注意:

オブザーバは、STOP OBSERVERコマンドを発行してすぐには停止しません。ブローカがSTOP OBSERVER要求を受け取ると、要求は次回オブザーバがブローカと通信する際にオブザーバに渡され、その後にオブザーバは停止します。

5.5.7.6 オブザーバの別のコンピュータへの移動

オブザーバを別のコンピュータに移動する手順は、次のとおりです。

1. 「オブザーバの停止」の説明に従って、ブローカ構成内の任意のコンピュータ・システムからオブザーバを停止します。

2. 「ファスト・スタート・フェイルオーバーの有効化」の手順8の説明に従って、新規コンピュータ・システムでオブザーバを起動します。

オブザーバを移動する際にファスト・スタート・フェイルオーバーを無効化する必要はありません。

5.5.7.7 オブザーバによるファスト・スタート・フェイルオーバー構成情報のメンテナンス方法

オブザーバでは、オブザーバを起動した作業ディレクトリに作成されているバイナリ・ファイルで、ファスト・スタート・フェイルオーバー構成に関する情報が永続的にメンテナンスされます。デフォルトでは、オブザーバの起動時に、現行の作業ディレクトリにこのファイルが作成され、fsfo.datという名前が付けられます。このファイルには、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方に対する接続識別子が含まれます。

権限のないユーザーはこのファイルを読めないことを確認します。

オブザーバの起動後は、ファイルの名前および場所を変更できません。ただし、オブザーバの起動にDGMGRLのSTART OBSERVERコマンドを使用し、FILE IS修飾子を含める場合は、ファイルの名前または場所を変更できます。詳細は、START OBSERVERコマンドを参照してください。

注意:

オブザーバが通常と異なる方法で(CTRL/Cを入力するなど)停止された場合、オブザーバを再起動し、FILE IS修飾子を含む既存のfsfo.datファイルを参照してください。

5.5.7.8 オブザーバが実行中でファスト・スタート・フェイルオーバーが有効化されている場合の環境へのパッチ適用

オブザーバが実行中でファスト・スタート・フェイルオーバーが有効化されている環境へパッチを適用する場合は、パッチを適用する前に次の手順を実行してください。

1. DGMGRL STOP OBSERVERコマンドを使用してオブザーバを停止します。このコマンドを正常に実行するには、プライマリとターゲット・スタンバイの接続が確立されている必要があります。

2. DGMGRL DISABLE FAST_START FAILOVERコマンドを使用してファスト・スタート・フェイルオーバーを無効化します。このコマンドを正常に実行するには、プライマリとターゲット・スタンバイの接続が確立されている必要があることに注意してください。

すべてのデータベースにパッチが正常に適用された後、次の手順に従ってファスト・スタート・フェイルオーバーを有効化しオブザーバを起動してください。

1. DGMGRL ENABLE FAST_START FAILOVERコマンドを使用してファスト・スタート・フェイルオーバーを有効化します。このコマンドを正常に実行するには、プライマリとターゲット・スタンバイの接続が確立されている必要があります。

2. DGMGRL START OBSERVERコマンドを使用してオブザーバを起動します。

5.5.8 ブローカ構成に含まれる元のプライマリ・データベースの回復

FastStartFailoverAutoReinstate構成プロパティをTRUEに設定すると、プライマリ・データベースがクラッシュするか、オブザーバおよびターゲット・スタンバイ・データベースとの接続が失われたことが原因でファスト・スタート・フェイルオーバーが開始された場合、オブザーバは元のプライマリ・データベースのスタンバイ・データベースとしての回復を自動的に試行します。回復により、ブローカ構成に対する高可用性がリストアされるため、新規プライマリ・データベースに障害が発生した場合に、別のファスト・スタート・フェイルオーバーが実行されます。回復されたデータベースは、新規プライマリ・データベースのファスト・スタート・フェイルオーバーのターゲットとして機能し、後続のファスト・スタート・フェイルオーバーが可能になります。新規スタンバイ・データベースは、新規プライマリ・データベースからのREDOデータの受信を開始した時点で、フェイルオーバーの実行可能なターゲットとなります。

オブザーバによる元のプライマリ・データベースの自動回復を可能にするには、データベースを起動およびマウントする必要がありますが、オープンしないでください。オープンしている場合、オブザーバは元のプライマリ・データベースを再起動してマウント済状態にしてからデータベースを回復します。ブローカは、データベースを新しいプライマリ・データベースのスタンバイ・データベース(元のスタンバイと同じタイプ)として回復します。

元のプライマリ・データベースが自動的に回復されない場合、DGMGRLのREINSTATEコマンドまたはCloud Controlを使用して手動で回復できます。手動回復の段階的な手順は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

5.5.8.1 要件

回復がサポートされるのは、ブローカ構成でフェイルオーバーを実行した後に限られます。また、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方でフラッシュバック・データベースを有効化する必要があります。すべてのファスト・スタート・フェイルオーバーおよび回復の要件の詳細は、「ファスト・スタート・フェイルオーバーを有効化するための前提条件」を参照してください。

5.5.8.2 回復に関する制限事項

次の場合、ブローカでは元のプライマリ・データベースを自動的に回復できません。

- ユーザーが構成可能な条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションで要求した場合

- FastStartFailoverAutoReinstateがFALSEに設定されている場合

- ファスト・スタート・フェイルオーバーの完了後、元のプライマリ・データベースが再起動されるまでに別のフェイルオーバーまたはスイッチオーバーが発生した場合

- ファスト・スタート・フェイルオーバーが無効化されている場合

- オブザーバが元のプライマリ・データベースに接続できない場合

- 元のプライマリ・データベースが新規プライマリ・データベースに接続できない場合

- 元のプライマリ・データベースおよび新規プライマリ・データベースが、同じファスト・スタート・フェイルオーバー環境内で構成されていない場合

- ファスト・スタート・フェイルオーバーが無効化されているとき、手動フェイルオーバーによって元のプライマリ・データベースが無効化された場合

注意:

スイッチオーバー、手動フェイルオーバーまたはファスト・スタート・フェイルオーバーの実行時にスタンバイ・データベースを無効した場合は、自動的に回復されません。

自動回復に失敗した場合、ブローカによりエラーがログに記録され、元のプライマリ・データベースはマウントされた状態のままとなります。この時点で、次のいずれかを実行できます。

- ファスト・スタート・フェイルオーバーを無効化し(「ファスト・スタート・フェイルオーバーの無効化」を参照)、元のプライマリ・データベースのオープンを試行する

- 「ロール変更後の無効化されたデータベースの再有効化」の説明に従って、元のプライマリ・データベースを手動で回復する

5.5.8.3 失敗した回復のブローカによる処理方法

回復操作(自動または手動)が進行中のときに障害が発生した場合、ブローカにより、ブローカ構成ファイルおよびブローカ・ログ・ファイルに、適切な情報が記録されます。元のプライマリ・データベースは無効化されます。進行中の障害のほとんどは再起動できません(プライマリ・データベースにおけるアーカイブREDOログ・ファイルの破損など)。データベースをスタンバイ・データベースとして手動で再作成してから再有効化する必要があります。

参照:

「無効化されたデータベースの再作成および再有効化の方法」

5.5.9 ファスト・スタート・フェイルオーバー環境でのデータベースの停止

プライマリまたはターゲット・スタンバイ・データベースをシャットダウンする必要がある場合、次の手順を実行します。

1. オブザーバを停止し、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方について、V$DATABASE固定ビューのFS_FAILOVER_OBSERVER_PRESENT列に値「NO」が含まれるまで待機します。こうすると、プライマリ・データベースの停止中に、ファスト・スタート・フェイルオーバーは実行されません。

2. DGMGRLのSHUTDOWNコマンドまたはSQL*PlusのSHUTDOWN文を使用して、プライマリ・データベースおよびターゲット・スタンバイ・データベースを停止します。

データベースを再起動する場合、任意の順序で実行できます。両方のデータベースを再起動したら、オブザーバを再起動できます。

その他のスタンバイ・データベースは、いつでも、任意の順序で、ファスト・スタート・フェイルオーバーに影響なくシャットダウンできます。

5.6 データベース・クライアントに関する考慮事項

この項では、ブローカ管理のフェイルオーバーが発生したときに、ローカル・データベース・サービスに接続しているデータベース・クライアントで使用可能な、イベント通知およびデータベース接続フェイルオーバーのサポートについて説明します。グローバル・サービスのイベント通知とデータベース接続フェイルオーバー・サポートの詳細は、『Oracle Database概要および管理ガイド』を参照してください。

フェイルオーバー後、ブローカは高速アプリケーション通知(FAN)イベントを発行します。FANイベントは次の方法で使用できます。

- アプリケーションでOracle Database JDBC、Oracle Database Oracle Call Interface(OCI)、Oracle Data Provider for .NET(ODP.NET)、Universal Connection Pool for JavaのいずれかのOracle統合データベース・クライアントを使用している場合、プログラムを変更せずにFANを使用できます。これらのクライアントには、フェイルオーバー後に自動的に新規プライマリ・データベースに接続する高速接続フェイルオーバー(FCF)を構成できます。

- JAVAアプリケーションはJDBC FANアプリケーション・プログラミング・インタフェースを利用してFANをプログラムで使用することで、FANイベントにサブスクライブし、イベント受信時にイベント処理アクションを実行できます。

- FANのサーバー側コールアウトをデータベース層で構成できます。

Oracle Database 12c以降のすべてのOracle統合データベース・クライアントでは、FANイベントは、Oracle Notification Service(ONS)を使用して発行されます。以前のリリースの場合、OCIとODP.NETクライアントは、Oracle Advanced Queuing (AQ)を介してFAN通知を受け取ります。

注意:

ONSを使用してFANイベントを発行するには、単一インスタンスのデータベースをOracle Restartに登録する必要があります。

参照:

- Oracle Real Application Clusters(Oracle RAC)データベースでのFAN、FCFおよびONSの構成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- 単一インスタンス・データベースでのOracle Restart、FAN、FCFおよびONSの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

5.6.1 Oracle Data Guard固有のFANおよびFCF構成要件

この項では、ブローカ管理のフェイルオーバーによって生成されたFANイベントを発行および適切に処理するために満たす必要のある構成要件について説明します。

これらの要件は、前述のマニュアルおよび次のクライアント固有ガイドに記載されている要件を補足するものです。

- 『Oracle Database JDBC開発者ガイド』

- Oracle Call Interfaceプログラマーズ・ガイド

- 『Oracle Data Provider for .NET開発者ガイドfor Microsoft Windows』

5.6.1.1 Oracle Netの構成要件

FCFを実行するには、クライアントはフェイルオーバー後に新しいプライマリ・データベースを検出できる必要があります。この項では、この要件に合せてOracle Netの接続記述子を構成する方法について説明します。

接続記述子は次のいずれかの方法で構成できます。

1. 接続時フェイルオーバーの接続記述子を構成します。プライマリ・データベースおよび各スタンバイ・データベースをアドレス・リストに追加します。ネットワーク・アドレスが指定されていない場合に遅延を最小限に抑えるために、CONNECT_TIMEOUTパラメータを小さい値に設定します。リソース競合により通常操作中に接続タイムアウトが発生する場合は、このパラメータの値を大きくします。

次に例を示します。

sales =
(DESCRIPTION=
(FAILOVER=ON)
(CONNECT_TIMEOUT=5)
(ADDRESS_LIST=
(ADDRESS=(HOST=boston-scan)(PORT=1521))
(ADDRESS=(HOST=dallas-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=sales)))

2. DNSやLDAPなどのグローバル・ネーミング・サービスを使用して登録された単一ネットワーク名で、接続記述子を構成します。DB_ROLE_CHANGEシステム・イベントに基づいてトリガーを作成します。このシステム・イベントは、フェイルオーバー後に、ネットワーク名に関連付けられているネットワーク・アドレスを新規プライマリ・データベースのネットワーク・アドレスに変更します。

参照:

- DB_ROLE_CHANGEシステム・イベントの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

どちらの場合も、接続記述子にSERVICE_NAMEパラメータを含める必要があります。

5.6.1.2 データベース・サービスの構成要件

注意:

この項で示した例では、必ずしもご使用の環境で使用する必要のある特定の属性を示しているわけではありません。必要な属性は構成によって異なります(ご使用の環境がOracle RACベースか単一インスタンスかどうかも含めて)。詳細は、適切なOracle RACまたはOracle Restartのマニュアルを参照してください。

データベース・サービスは、Oracle RACデータベースの特定のデータベース・ロール、およびOracle Restartにより管理される単一インスタンス・データベースでアクティブになるように構成できます。ブローカはOracle ClusterwareまたはOracle Restartと相互に作用して、適切なデータベース・サービスがアクティブになり、ロール変更後に適切なFANイベントが発行されるようにします。

FANイベントは常にONSを使用して発行されます。ただし、データベースが新規プライマリ・データベースでプライマリ・ロールになっている場合、フェイルオーバーを通知するイベントは、アクティブに構成されているデータベース・サービスに対してのみ発行されます。

任意のデータベース・ロールでアクティブでなければならないサービス(プライマリ、フィジカル・スタンバイ、ロジカル・スタンバイまたはスナップショット・スタンバイ)は、サービスがアクティブでなければならない各データベースで明示的にServer Controlユーティリティ(SRVCTL)によって構成する必要があります。次のコマンドの例では、サービスPAYROLLがプライマリ・データベースNORTHのPRIMARYでアクティブになるように構成されています。また、スタンバイ・データベースSOUTHのPRIMARYロールでもアクティブになるように構成されているため、ロール・トランジションが発生した場合にはそのデータベースでアクティブになります。これらのサンプル・コマンドで、省略記号(...)は、必要に応じて指定するadd serviceの他のオプションを示します。

プライマリ・データベースNORTH上で、次を実行します。

srvctl add service –db NORTH –service PAYROLL –role PRIMARY ...

スタンバイ・データベースSOUTH上で、次を実行します。

srvctl add service –db SOUTH –service PAYROLL –role PRIMARY ...

サービスを現在のプライマリ・データベースで起動するかどうかにかかわらず、データベースがフィジカル・スタンバイ・ロールになっているときにアクティブにするサービスも、そのデータベースで作成および起動する必要があります。これは、サービス定義がREDOストリームを介してフィジカル・スタンバイ・データベースに伝播されるようにするためです。これにより、サービスをフィジカル・スタンバイ・データベースで起動できるようになります。サービスをフィジカル・スタンバイで起動できるのは、サービスを起動することによって生成されたREDOが適用された後のみです。サービスがロール変更の前後で同じように動作するように、すべてのデータベース上ですべてのSRVCTL add serviceオプションが同一であることが重要です。

すべてのデータベースが同じ値を持たない場合、SRVCTLは値を上書きしようとしますが、フィジカル・スタンバイ・データベースで失敗します。これは、データベースが読取り専用でオープンであるためです。次のコマンドの例では、サービスsalesがプライマリ・データベースNORTHのPHYSICAL_STANDBYロールでアクティブになるように構成されています。その後、プライマリ・データベースで起動および停止されます。このサービスを現在のプライマリ・データベース上で実行しない場合は、オプションでプライマリ・データベースから削除することもできます。これは、フィジカル・スタンバイ・データベースSOUTHのPHYSICAL_STANDBYロールでもアクティブになるように構成されます。

次をプライマリ・データベースNORTHで実行します。

srvctl add service -db NORTH -service SALES -role PHYSICAL_STANDBY ...

srvctl start service –db NORTH –service SALES

srvctl stop service –db NORTH –service SALES

次をフィジカル・スタンバイ・データベースSOUTHで実行します。

srvctl add service -db SOUTH -service SALES -role PHYSICAL_STANDBY ...

ここでブローカによりスイッチオーバーまたはフェイルオーバーが実行されると、データベースのロールに基づいて、適切なデータベース上でSALESサービスが自動的に開始されます。

前述の各例では、データベースに1つのサービスのみを設定する方法を説明しました。次の例では、データベースに複数のサービスを設定する方法を示し、また、ブローカを使用することによって適切なサービスが適切なデータベース上で確実に開始される仕組みについて説明します。

プライマリ・データベースがBOSTON、スタンバイ・データベースがCHICAGOであると仮定します。次のSRVCTLコマンドを発行して、Data Guard構成内の両方のデータベースが、各データベースで実行する可能性のある2つのサービスについて認識するようにします。

BOSTONの場合

srvctl add service -db BOSTON -service SALESRW  -role PRIMARY -y AUTOMATIC
srvctl add service -db BOSTON  -service SALESRO  -role PHYSICAL_STANDBY -policy AUTOMATIC

CHICAGOの場合:

srvctl add service -db CHICAGO  -s SALESRW  -role PRIMARY -y AUTOMATIC
srvctl add service -db CHICAGO  -s SALESRO  -role PHYSICAL_STANDBY -policy AUTOMATIC

まず、正しいノード上でサービスを手動で開始する必要があります。また、SALESROサービスをプライマリ上で開始して停止し、このサービスをスタンバイ上で開始できるようにすることも必要です。次のSRVCTLコマンドを発行します。

BOSTONの場合:

srvctl start service -db BOSTON -service SALESRW
srvctl start service -db BOSTON -service SALESRO
srvctl stop service -db BOSTON -service SALESRO

CHICAGOの場合:

srvctl start service -db CHICAGO -service SALESRO

これで、適切なサービスが適切なデータベース上で実行されています。

ブローカによってスイッチオーバーまたはフェイルオーバーが実行されると、データベースの現在のロールに基づいて、サービスSALESRWまたはSALESROが開始されます。したがって、SALESRWはCHICAGO (現在のプライマリ)上で開始され、SALESROはBOSTON (現在のフィジカル・スタンバイ)上で開始されます。いずれかのデータベースが停止して起動した場合も、同じことが発生します。つまり、起動するデータベースのロールに適したサービスが開始されます。

これらのデータベースのそれぞれで次の手動コマンドを発行すると、SRVCTLの-role修飾子で以前に指定された内容に関係なく、SALESROおよびSALESRWの両方のサービスがこれらのデータベース上で開始されることに注意してください。これは、-role修飾子がData Guard Brokerによってのみ、データベースの起動時に考慮されるからです。

BOSTONの場合:

srvctl start service -db CHICAGO

CHICAGOの場合:

srvctl start service -db BOSTON

SRVCTLユーティリティではデータベース・ロールが自動的に考慮されないため、サービスを手動で開始するときは常に、開始するサービスの名前を指定する必要があります。

注意:

サービスが自動的に起動するように構成されている場合(-policy AUTOMATIC)、データベース・ロールが変更された後にのみ、自動的に起動します。

注意:

Oracle Data Guard構成では、スタンバイ・データベースのSRVCTL -startoptionは、スイッチオーバー後には、常にOPENに設定されます。

参照:

- Oracle Restartにより管理される単一インスタンス・データベースでの、SRVCTLユーティリティを使用するデータベース・サービスの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

- Oracle RACデータベースでの、SRVCTLユーティリティを使用するデータベース・サービスの構成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

5.6.1.3 ONSの構成要件

クライアント側のONS構成を使用する場合、クライアント側のONS構成ファイルで、プライマリ・データベースおよび各スタンバイ・データベースのONSデーモンのホスト名およびポートを指定する必要があります。

クライアントでリモートONSサブスクリプションを使用する場合、クライアントでプライマリ・データベースおよび各スタンバイ・データベースのONSデーモンのホスト名およびポートを指定する必要があります。

5.6.1.4 アプリケーション・コンティニュイティ

アプリケーション・コンティニュイティは、データベース・セッションを使用不可にするリカバリ可能なエラーの後に、データベースに対するリクエストを中断せず、迅速な方法でリプレイできるようにするOracle Databaseの機能です。

Oracle Data Guardのフィジカル・スタンバイ・データベースへのスイッチオーバーに対し、アプリケーション・コンティニュイティがサポートされています。最大可用性のデータ保護モードの場合、フィジカル・スタンバイへのファスト・スタート・フェイルオーバーもサポートされます。プライマリ・データベースとスタンバイ・データベースには、Oracle RACまたはOracle Active Data Guardのライセンスを付与して、アプリケーション・コンティニュイティを使用できるようにする必要があります。

参照:

- アプリケーション・コンティニュイティの詳細は、『Oracle Database開発ガイド』を参照してください

6 DGMGRLコマンドライン・インタフェースの使用例

次のトピックでは、Oracle Data Guardコマンドライン・インタフェース(DGMGRL)の使用を開始するための前提条件について説明します。また、DGMGRLを使用してブローカ構成を作成、管理および監視する方法について例をあげて説明します。

- 初期使用の前提条件

- 使用例1: 構成の作成

- 使用例2: データベース・プロパティの設定

- 使用例3: 構成とデータベースの有効化

- 使用例4: 構成保護モードの設定

- 使用例5: 遠隔同期インスタンスでの「最大可用性」モードの設定

- 使用例6: ファスト・スタート・フェイルオーバーの有効化とオブザーバの起動

- 使用例7: 遠隔同期インスタンスが使用中の場合のファスト・スタート・フェイルオーバーの有効化

- 使用例8: 定期的な管理タスクの実施

- 使用例9: スイッチオーバー操作の実行

- 使用例10: 手動フェイルオーバー操作の実行

- 使用例11: 障害が発生したプライマリ・データベースの回復

- 使用例12: フィジカル・スタンバイからスナップショット・スタンバイへの変換

- 使用例13: Data Guard構成の監視

6.1 初期使用の前提条件

DGMGRL使用の前提条件の1つは、1つのプライマリ・データベースと任意の数のスタンバイ・データベースが存在していることです。構成内のすべてのデータベースについて、DG_BROKER_START初期化パラメータをTRUEに設定する必要があります。ブローカではサーバー・パラメータ・ファイルを使用する必要があります(「Oracle Data Guardのインストール」および「DGMGRLコマンドの使用上の注意」を参照)。

必要な場合は、プライマリ・データベースとスタンバイ・データベースの初期化パラメータ・ファイル(PFILE)をサーバー・パラメータ・ファイル(SPFILE)に変換します。次のSQL*Plusコマンドを使用します。

CREATE SPFILE='spfilename' FROM PFILE='pfilename';

サーバー・パラメータ・ファイルを使用してインスタンスが起動されていない場合は、そのインスタンスを停止し、サーバー・パラメータ・ファイルを使用して再起動する必要があります。

Oracleインスタンスの起動後に、SQLのALTER SYSTEM文を使用してDG_BROKER_START=TRUE初期化パラメータを設定します。パラメータ値は、サーバー・パラメータ・ファイルに保存されます。Oracleインスタンスの次回起動時にブローカが自動的に起動されるため、SQLのALTER SYSTEM文の再発行は不要です。

参照:

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

これらの使用例では、次を前提としています。

- プライマリ・データベースとスタンバイ・データベースへの接続にTCP/IPが使用されていること

- プライマリ・データベースの制御ファイルとデータファイルのバックアップから、スタンバイ・データベースが作成されていること(詳細は『Oracle Data Guard概要および管理』を参照)

- 使用例は、次のブローカ構成を前提としています。

- 構成名はDRSolutionです。

- プライマリ・データベースの一意名(DB_UNIQUE_NAME)はNorth_Salesです。

- リモート・スタンバイ・データベースの一意名(DB_UNIQUE_NAME)はSouth_Salesです。

- 保護モードは最大パフォーマンス・モードです。

- プライマリ・データベースおよびスタンバイ・データベースの両方にスタンバイREDOログ・ファイルが構成されます。両方のデータベースの転送モードはASYNCです。

- スタンバイ・データベースはフィジカル・スタンバイ・データベースです。

6.2 使用例1: 構成の作成

この項では、プライマリ・データベースNorth_Salesおよびスタンバイ・データベースSouth_Salesを含むDRSolutionというブローカ構成の作成例を示します。

構成を作成してフィジカル・スタンバイ・データベースを1つ追加するには、次のタスクを実行します。

- 構成の作成(タスク1): DGMGRLの起動

- 構成の作成(タスク2): プライマリ・データベースへの接続

- 構成の作成(タスク3): 既存のリモートREDO転送先のクリア

- 構成の作成(タスク4): ブローカ構成の作成

- 構成の作成(タスク5): 構成情報の表示

- 構成の作成(タスク6): 構成へのスタンバイ・データベースの追加

6.2.1 構成の作成(タスク1): DGMGRLの起動

DGMGRLを起動するには、Oracle Data Guardがインストールされているシステム上で、コマンドライン・プロンプトからdgmgrlと入力します。

$ dgmgrl

DGMGRLプロンプトが表示されます。

DGMGRL>

6.2.2 構成の作成(タスク2): プライマリ・データベースへの接続

任意のコマンド(HELP、EXITまたはQUIT以外)を指定する前に、まずDGMGRL CONNECTコマンドを使用してプライマリ・データベースに接続する必要があります。

データベースへの接続に使用するアカウント(この例ではSYS)には、プライマリ・データベースとスタンバイ・データベースでのSYSDGまたはSYSDBA権限が必要です。

注意:

CONNECTコマンドのデフォルト設定であるため、AS SYSDBAを指定する必要はありません。

次の例は、CONNECTコマンドの2つのバリエーションを示しています。例6-1に、ローカル・システム上のデフォルト・データベースに接続する方法を示し、例6-2に、リモート・システムにあるデータベースに接続するためのOracle Net Services接続識別子(North_Sales.example.com)を示します。この2つの例ではどちらもパスワードの入力を要求されます。

例6-1 ローカル・システム上のプライマリ・データベースへの接続

DGMGRL> CONNECT sysdg;
Password: password
Connected as SYSDG.

例6-2 リモート・システム上のプライマリ・データベースへの接続

DGMGRL> CONNECT sysdg@North_Sales.example.com;
Password: password
Connected as SYSDG.

6.2.3 構成の作成(タスク3): 既存のリモートREDO転送先のクリア

NOREGISTER属性のないプライマリ・データベース上ですべてのリモートREDO転送先をクリアしてからでないと、構成を作成できません。それ以外の場合、構成の作成を試行すると次のエラー・メッセージが戻ります。

ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added

Failed.

LOG_ARCHIVE_DEST_n設定をクリアするには、SQL*PlusコマンドALTER SYSTEM SET LOG_ARCHIVE_DEST_n=" "を使用します。

6.2.4 構成の作成(タスク4): ブローカ構成の作成

ブローカ構成は、最初はプライマリ・データベースでのみ作成されます。この例ではNorth_Sales という名前です。後のコマンドで、スタンバイ・データベースSouth_Salesを追加します。

注意:

プライマリ・データベース名とスタンバイ・データベース名では、それぞれのデータベースの一意名が一致する必要があります。これらの一意名は、次のコマンドを使用してDB_UNIQUE_NAME初期化パラメータからフェッチします。

SQL> SHOW PARAMETER DB_UNIQUE_NAME;

CREATE CONFIGURATIONコマンドを使用し、DRSolution構成を作成してプライマリ・データベースNorth_Salesを定義します。

DGMGRL> CREATE CONFIGURATION 'DRSolution' AS
>  PRIMARY DATABASE IS 'North_Sales'
>  CONNECT IDENTIFIER IS North_Sales.example.com;

DGMGRLは次の情報を戻します。

Configuration "DRSolution" created with primary database "North_Sales"

名前North_Salesは、このデータベースのDB_UNIQUE_NAME初期化パラメータの値です。

6.2.5 構成の作成(タスク5): 構成情報の表示

SHOW CONFIGURATIONコマンドを使用して、構成に関する簡単なサマリーを表示します。

DGMGRL> SHOW CONFIGURATION;

DGMGRLは次の情報を戻します。

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales - Primary database

Fast-Start Failover: DISABLED

Configuration Status:
DISABLED

6.2.6 構成の作成(タスク6): 構成へのスタンバイ・データベースの追加

DRSolution構成にスタンバイ・データベースを追加するには、 ADD DATABASEコマンドを使用します。

次のコマンドは、スタンバイ・データベースとしてSouth_Salesを定義しています。これは、プライマリ・データベースNorth_Salesに関連付けられているスタンバイ・データベースです。

DGMGRL> ADD DATABASE 'South_Sales' AS
>  CONNECT IDENTIFIER IS South_Sales.example.com;

DGMGRLは次の情報を戻します。

Database "South_Sales" added

名前South_Salesは、データベースのDB_UNIQUE_NAME初期化パラメータの値です。

SHOW CONFIGURATIONコマンドを使用して、South_SalesデータベースがDRSolution構成に追加されたことを確認します。

DGMGRL> SHOW CONFIGURATION;

DGMGRLは次の情報を戻します。

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
South_Sales  - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
DISABLED

DGMGRL>

6.3 使用例2: データベース・プロパティの設定

DGMGRLを使用して構成を作成した後は、いつでもデータベース・プロパティを設定できます。たとえば、次の文は、South_Salesスタンバイ・データベースのデータベース・プロパティLogArchiveFormatおよびStandbyArchiveLocationを設定します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogArchiveFormat'='log_%t_%s_%r_%d.arc';
Property "LogArchiveFormat" updated.

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'StandbyArchiveLocation'='/archfs/arch/';
Property "StandbyArchiveLocation" updated.

データベースのすべてのプロパティとその値を表示するには、SHOW DATABASE VERBOSEコマンドを使用します。次の例は、South_Salesデータベースのプロパティを示しています。

DGMGRL> SHOW DATABASE VERBOSE 'South_Sales';

Database - South_Sales

Role:            PHYSICAL STANDBY
Intended State:  OFFLINE
Transport Lag:   (unknown)
Apply Lag:       (unknown)
Apply Rate:      (unknown)
Real Time Query: OFF
Instance(s):
south_sales1

Properties:
DGConnectIdentifier             = 'South_Sales.example.com'
ObserverConnectIdentifier       = ''
LogXptMode                      = 'ASYNC'
RedoRoutes                      = ''
DelayMins                       = '0'
Binding                         = 'optional'
MaxFailure                      = '0'
MaxConnections                  = '1'
ReopenSecs                      = '300'
NetTimeout                      = '30'
RedoCompression                 = 'DISABLE'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyLagThreshold               = '0'
TransportLagThreshold           = '0'
TransportDisconnectedThreshold  = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/t, dbs/ct, dbs/bt, dbs/ct'
LogFileNameConvert              = 'dbs/t, dbs/ct, dbs/bt, dbs/ct'
FastStartFailoverTarget         = ''
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=south_sales1.example.com)(PORT=2840))
(CONNECT_DATA=(SERVICE_NAME=South_Sales_DGMGRL.example.com)(INSTANCE_NAME=south_sales1)(SERVER=DEDICATED)))'
StandbyArchiveLocation          = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation               = ''
LogArchiveTrace                 = '255'
LogArchiveFormat                = 'db3r_%d_%t_%s_%R.arc'
TopWaitEvents                   = '(monitor)'

Database Status:
DISABLED

データベースのブローカ管理が有効な場合は、データベース・プロパティ値を設定すると、対応するデータベースの基礎となるパラメータ値が変更され、変更されたパラメータの値がサーバー・パラメータ・ファイルに反映されます。したがって、データベースがOracle Enterprise Manager Cloud Control (Cloud Control)およびDGMGRL以外(SQL*Plusインタフェースなど)から停止および再起動された場合は、更新されたサーバー・パラメータ・ファイルの新規パラメータ値がデータベースの起動時に使用されます。ただし、SQL文を使用してREDO転送サービスの初期化パラメータを変更しないでください。それを行うと、データベースとブローカ間の一貫性が失われます。

注意:

通常、データベース・プロパティは、対応する初期化パラメータ、SQL文またはPL/SQLプロシージャ(通常は大文字)と視覚的に区別しやすいように、大/小文字混合表記(LogArchiveFormatなど)で表示されます。ただし、プロパティ管理コマンドでは大/小文字は区別されないため、大文字、小文字または混合表記でコマンドを発行できます。

プロパティは、データベースが有効な場合でも無効な場合でも変更できます。ただし、プロパティの変更時にデータベースが無効な場合、変更結果はデータベースが有効化されるまで有効になりません。

6.4 使用例3: 構成とデータベースの有効化

これまでDRSolution構成は無効化されており、Data Guard Brokerの制御下にはありませんでした。ブローカ構成に対するデータベースの構成および必要なデータベース・プロパティの設定を完了した後に、構成を有効化してData Guard Brokerで管理できるようにする必要があります。

次のいずれかを有効化できます。

- すべてのデータベースを含む構成全体

- スタンバイ・データベース

構成全体の有効化

次のコマンドを使用すると、すべてのデータベースを含む構成全体を有効化できます。

DGMGRL> ENABLE CONFIGURATION;
Enabled.

構成の表示

SHOWコマンドを使用して、構成とそのデータベースが正常に有効化されていることを確認します。

DGMGRL> SHOW CONFIGURATION;

DGMGRLは次の情報を戻します。

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
South_Sales  - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

データベースの有効化

この手順は、前にDISABLE DATABASEコマンドを使用してスタンバイ・データベースを無効化している場合にのみ実行します。通常は、構成を有効化するとスタンバイ・データベースも有効化されます。

DGMGRL> ENABLE DATABASE 'South_Sales';
Enabled.

データベースの表示

DGMGRL> SHOW DATABASE 'South_Sales';

Database - South_Sales

Role:             PHYSICAL STANDBY
Intended State:   APPLY-ON
Transport Lag:    0 seconds (computed 1 second ago)
Apply Lag:        0 seconds (computed 1 second ago)
Apply Rate:       1.54 MByte/s
Real Time Query:  OFF
Instance(s):
south_sales1

Database Status:
SUCCESS

6.5 使用例4: 構成保護モードの設定

構成の保護モードはいつでも変更できます。

注意:

保護モードを最大パフォーマンス・モードから最大保護モードへは変更できません。まず保護モードを最大可用性に変更してから、最大保護モードに変更します。

保護モードを変更する場合、プライマリ・データベースの再起動は不要です。

この使用例では、構成の保護モードをMAXAVAILABILITYモードに設定します。この保護モードに設定するには、少なくとも1つのスタンバイ・データベースをスタンバイREDOログ・ファイルを使用するように構成し、同期またはFASTSYNCモードを介してREDOを受け取る必要があります。スタンバイが遠隔同期インスタンスを介してREDOを受け取る場合、遠隔同期インスタンスはSYNCまたはFASTYSYNCモードでREDOを受け取り、スタンバイはASYNCモードで遠隔同期インスタンスからREDOを受け取る必要があります。

1. スタンバイREDOログ・ファイルを構成します(必要な場合)。
保護モードをMAXAVAILABILITYモードに設定するため、スタンバイ・データベースに十分なスタンバイREDOログ・ファイルが構成されていることを確認する必要があります。REDO転送の設定方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。

2. REDO転送モードを適切に構成します。
スタンバイがプライマリ・データベースから直接REDOを受け取る場合、SYNCまたはFASTSYNCモードでREDOを受け取るようにスタンバイを構成します。スタンバイが遠隔同期インスタンスを介してプライマリREDOを受け取る場合、SYNCまたはFASTSYNCモードでREDOを受け取るように遠隔同期インスタンスを構成し、遠隔同期インスタンスからASYNCモードでREDOを受け取るようにスタンバイを構成します。次に例を示します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated

スタンバイREDOログ・ファイルを使用するように構成されたスタンバイ・データベースが構成内に含まれていないかぎり、このコマンドは正常終了しません。

3. 構成全体の保護モードを変更します。
EDIT CONFIGURATIONコマンドを使用して、ブローカ構成の保護モードをMAXAVAILABILITYにアップグレードします。

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
Succeeded.

このコマンドを入力したときに構成が無効な場合、実際の保護モードの変更は、ENABLE CONFIGURATIONコマンドで構成が有効化されるまで適用されません。保護モードの要件をサポートできるスタンバイ・データベースが構成内に存在しない場合、構成は有効化できません。

4. 保護モードが変更されたことを確認します。
SHOW CONFIGURATIONコマンドを使用して構成の現在の保護モードを表示します。

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxAvailability
Members:
North_Sales  - Primary database
South_Sales  - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

参照:

データ保護モードの管理

6.6 使用例5: 遠隔同期インスタンスでの「最大可用性」モードの設定

プライマリ・データベースとスタンバイ・データベースが地理的に遠すぎて同期転送モードが実用的でない場合、遠隔同期インスタンスを最大可用性保護モードで使用することができます。この項の例は、遠隔同期インスタンスを構成に追加し、構成のすべてのメンバーに対してRedoRoutesプロパティを設定する方法を示しています。遠隔同期インスタンスに対してRedoRoutesプロパティを設定すると、North_SalesデータベースとSouth_Salesデータベースのいずれかプライマリである方に基づいてREDOデータを送信できます。

1. ブローカ構成にFSという名前の遠隔同期インスタンスを追加するには、次のコマンドを発行します。

DGMGRL> ADD FAR_SYNC 'FS' AS CONNECT IDENTIFIER IS FS.EXAMPLE.COM;
DGMGRL> ENABLE FAR_SYNC 'FS';
DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales - Primary database
South_Sales - Physical standby database
FS - Far Sync

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

この出力で、South_SalesとFSは、North_Salesの配下にインデントされています。これは、プライマリがREDOデータをSouth_SalesとFSの両方に送信していることを示します。

2. 次のコマンドを発行して、North_Salesがプライマリである場合、現在のプライマリ(North_Sales)が遠隔同期インスタンスだけにREDOデータを送信し、遠隔同期インスタンスがREDOデータをSouth_Salesに送信するようにします。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY RedoRoutes='(LOCAL : FS SYNC)';
DGMGRL> EDIT FAR_SYNC 'FS' SET PROPERTY RedoRoutes='(North_Sales : South_Sales');
DGMGRL> SHOW CONFIGURATION;

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales - Primary database
FS - Far Sync
South_Sales - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

上の出力のインデント方式は、North_SalesがREDOデータをFSに送信し、FSがREDOデータをSouth_Salesに送信することを示しています。

3. 保護モードを最大可用性にアップグレードするには、次のコマンドを発行します。

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
North_Sales - Primary database
FS - Far Sync
South_Sales - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

South_Salesがプライマリに、North_Salesが遠隔同期インスタンス(FS)からREDOデータを受け取るスタンバイ・データベースになったことがある場合、RedoRoutesプロパティをSouth_Salesに設定する必要があります。さらに、South_Salesがプライマリ・データベースである場合にNorth_SalesにREDOデータを送信できるようにするには、FSのRedoRoutesプロパティに新しいルールを含める必要があります。

これらのルールが作成されていない場合、North_SalesはREDOログを受信できなくなります。適切なルールが設定されているかどうかを確認するには、SHOW CONFIGURATION WHEN PRIMARY ISコマンドを使用して、South_Salesがプライマリ・データベースであった場合にREDO転送構成がどのようになるかを確認します。次に例を示します。

DGMGRL> SHOW CONFIGURATION WHEN PRIMARY IS 'South_Sales';

Configuration when South_Sales is primary - DRSolution

Members:
South_Sales  - Primary database
FS     - Far Sync
North_Sales  - Physical standby database

Members Not Receiving Redo:
North_FS - Physical standby database
Warning: ORA-16685: database does not receive redo data

このエラーを修正するには、次のようにSouth_SalesおよびFSのRedoRoutesプロパティを設定します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY RedoRoutes='(LOCAL : FS SYNC)';
DGMGRL> EDIT FAR_SYNC 'FS' SET PROPERTY RedoRoutes=('North_Sales : South_Sales)(South_Sales : North_Sales)';

South_SalesおよびFSのRedoRoutesプロパティを変更した後、SHOW CONFIGURATION WHEN PRIMARY ISコマンドを使用して、エラーがクリアされたことを確認します。

DGMGRL> SHOW CONFIGURATION WHEN PRIMARY IS 'South_Sales';

Configuration when South_Sales is primary - DRSolution

Members:
South_Sales  - Primary database
FS     - Far Sync
North_Sales  - Physical standby database

6.7 使用例6: ファスト・スタート・フェイルオーバーの有効化とオブザーバの起動

ブローカ構成のデータベースに接続されているかぎり、オブザーバ・サイトを含め、任意のサイトからファスト・スタート・フェイルオーバーを有効化できます。ファスト・スタート・フェイルオーバーを有効化しても、フェイルオーバーは起動されません。かわりに、フェイルオーバーの条件が満たされた場合に、構成を監視しているオブザーバがファスト・スタート・フェイルオーバーを起動できるようになります。

ファスト・スタート・フェイルオーバーは、最大パフォーマンス保護モードまた最大可用性保護モードで動作している構成で有効化できます。この項では、ファスト・スタート・フェイルオーバーを有効化し、構成の保護モードが最大可用性モードに設定されるオブザーバを起動する手順を説明します。

1. スタンバイREDOログがプライマリ・データベースおよびターゲット・スタンバイ・データベースで構成されていることを確認します。スタンバイREDOログを構成する前に、ログ適用サービスを停止する必要があります。

参照:

スタンバイREDOログ・ファイルの構成方法は、『Oracle Data Guard概要および管理』を参照してください。

2. 遠隔同期インスタンスを介してではなく直接REDOを受け取る場合、プライマリ・データベースとスタンバイ・データベースを、SYNCまたはFASTSYNCモードでREDOを受け取るように構成します。いずれかのデータベースが遠隔同期インスタンスを介してREDOを受け取る場合、SYNCまたはFASTSYNCモードでREDOを受け取るように遠隔同期インスタンスを構成し、遠隔同期インスタンスからASYNCモードでREDOを受け取るようにデータベースを構成します。次に例を示します。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated

データベースがスタンバイREDOログ・ファイルで構成されていないかぎり、ブローカではこれらのコマンドが正常終了しません。

3. 2つ以上のスタンバイ・データベースがある場合、プライマリ・データベースのFastStartFailoverTarget構成プロパティを設定して目的のターゲット・スタンバイ・データベースを指定します。ファスト・スタート・フェイルオーバーが実際に有効化される際、ブローカにより、今度は反対にターゲット・スタンバイ・データベースのこのプロパティが将来のターゲット・スタンバイ・データベースとしてプライマリ・データベースを指すように設定されます。このプロパティは自動的に設定されるため、ターゲット・スタンバイ・データベースでこのプロパティを設定する必要はありません。次に例を示します。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget='South_Sales';
Property "FastStartFailoverTarget" updated

4. 保護モードのアップグレードが必要な場合、次のDGMGRL EDIT CONFIGURATIONコマンドを使用します。次に例を示します。

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

5. プライマリ・データベースおよびスタンバイ・データベースでまだ有効化されていない場合、各データベース上で次の文を発行し、「データベースをフラッシュバック」を有効にします。

ALTER SYSTEM SET UNDO_RETENTION=3600 SCOPE=SPFILE;
ALTER SYSTEM SET UNDO_MANAGEMENT='AUTO' SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
SHOW PARAMETER UNDO;
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320 SCOPE=BOTH;
ALTER DATABASE ARCHIVELOG;
ALTER SYSTEM SET db_recovery_file_dest_size=<size>;
ALTER SYSTEM SET db_recovery_file_dest=<directory-specification>;
ALTER DATABASE FLASHBACK ON;
ALTER DATABASE OPEN;

長時間の停止後でも回復が可能となるように、UNDO_RETENTIONおよびDB_FLASHBACK_RETENTION_TARGET初期化パラメータが十分に大きな値に設定されていることを確認します。

6. オブザーバを起動するには、オブザーバ・コンピュータにログインし、DGMGRLを実行します。SYSDGまたはSYSDBA権限を持つユーザーとして構成に接続し、START OBSERVERコマンドを発行します。このコマンドでは戻り値がない点に注意してください。つまり、コマンドを発行してもDGMGRLプロンプトを取得しません。

DGMGRL> CONNECT sysdg@North_Sales.example.com;
Password: password
Connected as SYSDG.
DGMGRL> START OBSERVER;
Observer started

対話形式でオブザーバを起動する場合、接続資格証明をDGMGRL接続コマンドに対するコマンドライン・パラメータとして指定しないことをお薦めします。この処理により、システムの他のユーザーがユーティリティ(UNIXのpsユーティリティなど)を使用して接続資格証明を表示することを回避できます。また、クリアテキストのパスワードがユーザーの端末に表示されるのを防ぐことができます。

スクリプトからオブザーバを起動する場合、データベース接続資格証明をスクリプト内に埋め込まなくてすむように、「connect/」をサポートする方法を使用することをお薦めします。クライアント側のOracleウォレットをセキュアな外部パスワード・ストアとして使用する場合(『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照)、プライマリ・データベースおよびファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースの資格証明を追加する必要があります。各データベースの資格証明を追加するとき、指定するデータベース接続文字列は、データベース・プロパティObserverConnectIdentiferまたはDGConnectIdentifierと一致している必要があります。

7. ファスト・スタート・フェイルオーバーを有効にします。ブローカ構成のデータベースに接続されている間は、ファスト・スタート・フェイルオーバーを有効化できます。次に例を示します。

DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.

8. ファスト・スタート・フェイルオーバー構成を検証します。SHOW FAST_START FAILOVERコマンドを使用して、ファスト・スタート・フェイルオーバーの設定を表示します。

DGMGRL> SHOW FAST_START FAILOVER;

Fast-Start Failover: DISABLED

Threshold: 30 seconds
Target: South_Sales
Observer: observer.example.com
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Observer Reconnect: (none)
Observer Override: FALSE

Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES

Oracle Error Conditions:
(none)

次のコマンドは、ファスト・スタート・フェイルオーバーが有効化された後、相互に指定しあうようにFastStartFailoverTargetプロパティが設定されることを示しています。最初のコマンドは現在のプライマリ・データベースNorth_Salesに対して発行されており、FastStartFailoverTargetプロパティの値として現在のターゲット・スタンバイSouth_Salesを指定しています。2つめのコマンドはターゲット・スタンバイSouth_Salesに対して発行されており、プライマリとして引き継ぐ際、ターゲット・スタンバイの将来のターゲット・スタンバイとして現在のプライマリNorth_Salesを指定しています。

DGMGRL> SHOW DATABASE 'North_Sales' FastStartFailoverTarget;
FastStartFailoverTarget='South_Sales';

DGMGRL> SHOW DATABASE 'South_Sales' FastStartFailoverTarget;
FastStartFailoverTarget='North_Sales';

6.8 使用例7: 遠隔同期インスタンスが使用中の場合のファスト・スタート・フェイルオーバーの有効化

ファスト・スタート・フェイルオーバーのターゲットが、遠隔同期インスタンスからREDOデータを受け取る論理またはフィジカル・スタンバイ・データベースの場合、ファスト・スタート・フェイルオーバーを最大可用性モードで有効化できます。

遠隔同期インスタンスを使用してREDOデータをスタンバイ・データベースに送信している場合にファスト・スタート・フェイルオーバーを有効にするには、次のようにして、先にプライマリおよびターゲット・スタンバイ・データベース上でFastStartFailoverTargetプロパティを設定する必要があります。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget='South_Sales';
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY FastStartFailoverTarget='North_Sales';

その場合、次のようにしてファスト・スタート・フェイルオーバーを有効化できます。

DGMGRL> ENABLE FAST_START FAILOVER;

遠隔同期インスタンス・データベースが、North_SalesやSouth_Salesのファスト・スタート・フェイルオーバー・ターゲットとして指定されていない点に注意してください。

6.9 使用例8: 定期的な管理タスクの実施

1つ以上のデータベースの定期的なメンテナンスを実行するために、ブローカ構成に含まれるデータベースの状態やプロパティの変更が必要になる場合があります。また、構成に含まれるデータベースのブローカ管理を一時的に無効化する必要が生じる場合もあります。

6.9.1 プロパティと状態の変更

構成の監視中に、データベースやそのプロパティの状態を動的に変更する操作が必要になる場合があります。次の各項で、構成内のデータベースの状態またはプロパティを変更する方法について説明します。

6.9.1.1 データベース・プロパティの変更

データベース・プロパティの値は、データベースが有効か無効かに関係なくいつでも変更できます。

次の例は、EDIT DATABASEコマンドを使用してNorth_Salesデータベースのデータベース・プロパティLogXptModeを値ASYNCに変更する方法を示しています。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogXptMode'=ASYNC;

DGMGRLは次のメッセージを戻します。このメッセージは、LogXptModeプロパティがData Guard構成ファイル内で正常に更新されたことを示します。

Property "LogXptMode" updated

構成が現在無効の場合は、ENABLE CONFIGURATIONコマンドでブローカ構成を有効化するまで、データベースで新規プロパティ値が使用されません。

6.9.1.2 デフォルト値へのプロパティのリセット

データベースや構成が有効/無効のいずれの場合も、構成や設定可能なプロパティを、いつでもそのデフォルト値にリセットすることができます。

次の例は、EDIT DATABASEコマンドを使用してLogXptModeデータベースの設定可能なプロパティをNorth_Salesデータベースのデフォルト値にリセットする方法を示しています。

EDIT DATABASE 'North_Sales' RESET PROPERTY LogXptMode;

次の例は、EDIT CONFIGURATIONコマンドを使用してTraceLevel構成プロパティをデフォルト値にリセットする方法を示しています。

EDIT CONFIGURATION RESET PROPERTY TraceLevel;

6.9.1.3 スタンバイ・データベースの状態変更

フィジカル・スタンバイのREDO Applyを一時的に停止します。スタンバイ・データベースの状態をAPPLY-OFFに変更するには、次の例のようにEDIT DATABASEコマンドを入力します。

DGMGRL> EDIT DATABASE 'South_Sales' SET STATE='APPLY-OFF';
Succeeded.

フィジカル・スタンバイ・データベースをAPPLY-OFF状態にしても、REDOデータは引き続き受信されます。

6.9.1.4 プライマリ・データベースの状態変更

スタンバイ・データベースへのREDOデータの転送を停止します。これに対応してプライマリ・データベースの状態を変更するには、次のコマンドを使用します。

DGMGRL> EDIT DATABASE North_Sales SET STATE=TRANSPORT-OFF;

Succeeded.

プライマリ・データベースの状態をTRANSPORT-ONに戻すには、次のコマンドを使用します。

DGMGRL> EDIT DATABASE North_Sales SET STATE=TRANSPORT-ON;

Succeeded.

6.9.2 構成とデータベースの無効化

ブローカ構成またはそのデータベースのいずれかを無効化すると、それらのブローカによる管理が無効化されるため、DGMGRLを使用してそれらを管理および監視できなくなります。ただし、ブローカによるブローカ構成の管理を無効にしても、基礎となるOracle Data Guard構成またはデータベースの実際の操作には影響しません。たとえば、Oracle Data Guard構成内のREDO転送サービスとログ適用サービスは、管理できなくなりますが、そのまま機能し続けます。

6.9.2.1 構成の無効化

プライマリ・データベースを含むブローカ構成全体の管理を無効化するには、次の例のように、DISABLE CONFIGURATIONコマンドを使用する必要があります。

DGMGRL> DISABLE CONFIGURATION;

プライマリ・データベースのブローカ管理を無効化するには、DISABLE CONFIGURATIONコマンドを使用する必要があります。DISABLE DATABASEコマンドで無効化されるのは、スタンバイ・データベースの管理のみです。同様に、DISABLE FAR_SYNCコマンドは、遠隔同期インスタンスの管理のみを無効にします。

注意:

スタンバイ・データベースまたは遠隔同期インスタンスへの接続時に構成の管理を無効化する場合、構成を再び有効化するには、プライマリ・データベース(制御ファイルのロールがプライマリであるデータベース)に接続する必要があります。

構成メンバーのブローカの管理を無効にしても、そのメンバーはブローカ構成ファイルから削除されません。該当するENABLE CONFIGURATIONまたはENABLE DATABASE コマンドを入力すると、DGMGRL (またはCloud Control)によるメンバー管理機能を再び有効化できます。

6.9.2.2 スタンバイ・データベースの無効化

ブローカによるスタンバイ・データベースの管理と監視が一時的に不要になった場合は、DISABLE DATABASEコマンドを使用します。

構成の他の部分が有効な場合は、スタンバイ・データベースが有効化されないようにブローカ管理を明示的に無効化できます。次の例は、スタンバイ・データベースSouth_Salesを無効化する方法を示しています。

DGMGRL> DISABLE DATABASE 'South_Sales';
Disabled.

注意:

構成内のスタンバイ・データベースを無効にするとき、ファスト・スタート・フェイルオーバーが有効化されている場合、ターゲット・スタンバイ・データベースは無効化できません。

注意:

スタンバイ・データベースへの接続中にそのスタンバイ・データベースの管理を無効化した場合は、スタンバイ・データベースのブローカ管理を再び有効化するために、プライマリ・データベースまたは別の有効化されたスタンバイ・データベースに接続する必要があります。

警告:

ブローカ構成内のスタンバイ・データベースに関してブローカによる管理を無効化すると、プライマリ・データベースが消失した場合にも、そのスタンバイ・データベースはブローカでフェイルオーバー・ターゲットとして使用できなくなります。

最大保護モードまたは最大可用性モードのいずれかで動作している場合、ブローカでは、保護モードをサポートする最後の1つのスタンバイ・データベースを無効化できません。

6.9.2.3 遠隔同期インスタンスの無効化

ブローカによる遠隔同期インスタンスの管理と監視が一時的に不要になった場合は、DISABLE FAR_SYNCコマンドを使用します。

構成の他の部分が有効な場合は、遠隔同期インスタンスが有効化されないようにブローカ管理を明示的に無効化できます。次の例は、遠隔同期インスタンスを無効化する方法を示しています。

DGMGRL> DISABLE FAR_SYNC 'FS';
Disabled.

注意:

遠隔同期インスタンスを無効にすると、次の制約が適用されます。

- 他の構成メンバーのRedoRoutesプロパティで指定されている遠隔同期インスタンスは無効化できません。

- 遠隔同期インスタンスに接続している間にその遠隔同期インスタンスの管理を無効にした場合、遠隔同期インスタンスのブローカ管理を再び有効化するには、プライマリ・データベースまたは別の有効なスタンバイ・データベースに接続する必要があります。

注意:

ブローカ構成で遠隔同期インスタンスのブローカ管理を無効にした場合、他の構成メンバーのRedoRoutesプロパティで、その遠隔同期インスタンスを指定することはできません。

6.9.3 構成、スタンバイ・データベースまたは遠隔同期インスタンスの削除

REMOVE CONFIGURATION、REMOVE DATABASE、またはREMOVE FAR_SYNCコマンドを使用すると、ブローカ構成ファイルから構成、スタンバイ・データベースまたは遠隔同期インスタンスが実質的に削除され、Oracle Data Guard Brokerを使用してそれらを管理できなくなります。

削除操作でPRESERVE DESTINATIONS句を使用した場合、実際のOracle Data Guard構成は削除されず、実際のOracle Data Guard構成とそのデータベースの操作には影響しません。

注意:

REMOVE CONFIGURATION、REMOVE DATABASEまたはREMOVE FAR_SYNCコマンドを使用した後で、削除したオブジェクトを再作成することに決めた場合、当初発行したコマンドを再び発行する必要があります。必要な場合は「使用例1: 構成の作成」の手順に従って、DGMGRL (またはCloud Control)で管理できるブローカ構成を作成する必要があります。

注意:

次の制限があります。

- 構成内のスタンバイ・データベースを削除するとき、ファスト・スタート・フェイルオーバーが有効化されている場合、ターゲット・スタンバイ・データベースは削除できません。

- スタンバイ・データベースまたは遠隔同期インスタンスが、構成に含まれる他のメンバーのRedoRoutesプロパティで指定されている場合、それらを削除することはできません。

6.9.3.1 構成からのスタンバイ・データベースの削除

REMOVE DATABASEコマンドを使用すると、ブローカによるデータベースの管理と監視が停止され、データベースがブローカ構成ファイルから削除されます。

South_Salesスタンバイ・データベースを削除する前の構成を示します。

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
FS - Far Sync
South_Sales  - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

DGMGRLのREMOVE DATABASEコマンドを発行して、South_Salesデータベース情報をData Guard構成ファイルから削除します。

DGMGRL> REMOVE DATABASE 'South_Sales';
Removed database "South_Sales" from the configuration

South_Salesスタンバイ・データベースを削除した後の構成を示します。

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
FS - Far Sync

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

最大保護モードまたは最大可用性モードのいずれかで動作している場合、ブローカでは、保護モードをサポートする最後の1つのスタンバイ・データベースを削除できません。

6.9.3.2 構成からの遠隔同期インスタンスの削除

Oracle Data Guard構成ファイルからFS遠隔同期インスタンス情報を削除するには、次のコマンドを使用します。

DGMGRL> REMOVE FAR_SYNC 'FS';
Removed far sync instance "FS" from the configuration

FS遠隔同期インスタンスを削除した後の構成を示します。

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales - Primary database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

6.9.3.3 ブローカ構成の削除

次のコマンドを使用すると、構成全体がブローカによって管理および監視されなくなります。

DGMGRL> REMOVE CONFIGURATION;

注意:

ファスト・スタート・フェイルオーバーが有効化されている場合、構成を削除できません。

DGMGRLは次のメッセージを戻します。このメッセージは、コマンドによりData Guard構成ファイルからすべての構成情報が正常に削除されたことを示します。

Removed configuration

DGMGRL> SHOW CONFIGURATION;
Error: ORA-16532: Data Guard broker configuration does not exist

Configuration details cannot be determined by DGMGRL

6.10 使用例9: スイッチオーバー操作の実行

プライマリ・データベースとスタンバイ・データベースのロールは、SWITCHOVERコマンドを使用して切り替えることができます。SWITCHOVERコマンドを発行する前に、次のことを確認する必要があります。

- プライマリ・データベースとスタンバイ・データベースの状態がそれぞれTRANSPORT-ONおよびAPPLY-ONであること。

- 関係するすべてのデータベースが健全な状態で、エラーや警告がないこと。

- スタンバイ・データベースのプロパティがプライマリ・データベース上で設定されていること。これにより、プライマリ・データベースはスタンバイ・データベースへ遷移するときに正常に機能できます(次の例の太字表記を参照してください)。

- プライマリ・データベースでスタンバイREDOログ・ファイルが構成されています。

- 構成が最大可用性モードの場合、現在のプライマリは、新しいプライマリから直接REDOを受け取る場合、SYNCまたはFASTSYNCモードでREDOを受け取るように構成されます。遠隔同期インスタンスを介してREDOを受け取る場合、遠隔同期インスタンスはSYNCまたはFASTSYNCモードでREDOを受け取るように構成され、現在のプライマリはASYNCモードでREDOを受け取るように構成されます。構成が最大保護モードの場合、現在のプライマリは、SYNCモードでREDOを受け取るように構成されます。

- ファスト・スタート・フェイルオーバーが有効化されている場合は、ターゲット・スタンバイ・データベースとして指定されたスタンバイ・データベースへのスイッチオーバーのみ実行できる。

SWITCHOVERコマンドを使用してスイッチオーバーを実行するために必要なタスクは次のとおりです。

- SWITCHOVERコマンドの使用(タスク1): プライマリ・データベースのチェック

- SWITCHOVERコマンドの使用(タスク2): スイッチオーバーのターゲットとなるスタンバイ・データベースのチェック

- SWITCHOVERコマンドの使用(タスク3): データベースのロール変更可能確認

- SWITCHOVERコマンドの使用(タスク4): スイッチオーバー・コマンドの発行

- SWITCHOVERコマンドの使用(タスク5): 構成の表示

6.10.1 SWITCHOVERコマンドの使用(タスク1): プライマリ・データベースのチェック

次のように、SHOW DATABASE VERBOSEコマンドを使用して、プライマリ・データベースの状態、健全性およびプロパティをチェックします。

DGMGRL> SHOW DATABASE VERBOSE 'North_Sales';

Database - North_Sales

Role:            PRIMARY
Intended State:  TRANSPORT-ON
Instance(s):
north_sales1

Properties:
DGConnectIdentifier             = 'North_Sales.example.com'
ObserverConnectIdentifier       = ''
LogXptMode                      = 'ASYNC'
RedoRoutes                      = ''
DelayMins                       = '0'
Binding                         = 'optional'
MaxFailure                      = '0'
MaxConnections                  = '1'
ReopenSecs                      = '300'
NetTimeout                      = '30'
RedoCompression                 = 'DISABLE'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyLagThreshold               = '0'
TransportLagThreshold           = '0'
TransportDisconnectedThreshold  = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/bt, dbs/t, dbs/ct, dbs/t'
LogFileNameConvert              = 'dbs/bt, dbs/t, dbs/ct, dbs/t'
FastStartFailoverTarget         = 'South_Sales'
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
StaticConnectIdentifier         = 'DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=north_sales1.example.com)(PORT=2840))
(CONNECT_DATA=(SERVICE_NAME=North_Sales_DGMGRL.example.com)(INSTANCE_NAME=north_sales1)(SERVER=DEDICATED)))'
StandbyArchiveLocation          = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation               = ''
LogArchiveTrace                 = '255'
LogArchiveFormat                = 'db1r_%d_%t_%s_%R.arc'
TopWaitEvents                   = '(monitor)'

Database Status:
SUCCESS

特に、プライマリ・データベースの太字のプロパティおよび現在のステータスをチェックする必要があります。データベースの管理の詳細は、「ブローカ構成のメンバーの管理」を参照してください。

6.10.2 SWITCHOVERコマンドの使用(タスク2): スイッチオーバーのターゲットとなるスタンバイ・データベースのチェック

SHOW DATABASEコマンドを使用して、スイッチオーバーのターゲットとなるスタンバイ・データベースのステータスをチェックします。次に例を示します。

DGMGRL> SHOW DATABASE 'South_Sales';

Database - South_Sales

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
Apply Rate: 1.44 MByte/s
Real Time Query: OFF
Instance(s):
south_sales1

Database Status:
SUCCESS

6.10.3 SWITCHOVERコマンドの使用(タスク3): データベースのロール変更可能確認

ロール変更を実行する前に、VALIDATE DATABASEコマンドを使用して、データベースがロール変更に即時対応可能かどうかを確認する、一連の徹底チェックを実行することができます。

この手順に示す例では、DRSolution構成の3つのデータベース(プライマリ、ロジカル・スタンバイおよびフィジカル・スタンバイの各データベース)すべてにVALIDATE DATABASEコマンドを使用しています。構成は次のようになります。

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
North_Sales - Primary database
West_Sales - Logical standby database
South_Sales - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

例: プライマリ・データベースの検証

DGMGRL> VALIDATE DATABASE 'North_Sales';

Database Role:    Primary database

Ready for Switchover:  Yes

例: ロジカル・スタンバイ・データベースの検証

次のようにしてロジカル・スタンバイ・データベースを検証します。

DGMGRL> VALIDATE DATABASE 'West_Sales';

Database Role:     Logical standby database
Primary Database:  North_Sales

Ready for Switchover:  Yes
Ready for Failover:    Yes (Primary Running)
Warning: Physical and snapshot standby databases will
be disabled if a role change is performed to this database

例: フィジカル・スタンバイ・データベースの検証

次のようにしてフィジカル・スタンバイ・データベースを検証します。

DGMGRL> VALIDATE DATABASE 'South_Sales';

Database Role:     Physical standby database
Protection Mode:   MaxAvailability
Error: Switchover to this standby is not possible since there
are no other standbys that can support the protection mode

Primary Database:  North_Sales

Ready for Switchover:  No
Ready for Failover:    Yes (Primary Running)

Transport-Related Property Settings:
Property                        North_Sales Value        South_Sales Value
LogXptMode                      ASYNC                    SYNC

構成保護は最大可用性モードに設定されており、データベースSouth_Salesのみ、LogXptModeプロパティがSYNCに設定されているため、スイッチオーバーできないことを示すエラーが表示されます。データベースが、RedoRoutesプロパティが転送モードに構成されているデータベースまたは遠隔同期インスタンスからREDOを受け取る場合、そのモードがLogXptModeで指定されている転送モードを上書きする点に注意してください。

6.10.4 SWITCHOVERコマンドの使用(タスク4): スイッチオーバー・コマンドの発行

SWITCHOVERコマンドを発行して、プライマリ・データベースとスタンバイ・データベースのロールを交換します。次の例では、ブローカが、元のプライマリ・データベースの停止および再起動を、スイッチオーバーの一部として自動的に実行する方法を示します。(DGMGRLによってプライマリ・データベースとスタンバイ・データベースが自動的に再起動されるようにブローカ環境を設定する方法は、DGMGRLコマンドの使用上の注意を参照してください。)

DGMGRL> SWITCHOVER TO 'South_Sales';
Performing switchover NOW, please wait...
Operation requires a connection to instance "south_sales1" on database "South_Sales"
Connecting to instance "south_sales1"...
Connected as SYSDBA.
New primary database "South_Sales" is opening...
Operation requires startup of instance "north_sales1" on database "North_Sales"
Starting instance "north_sales1"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "South_Sales"

スイッチオーバーの完了後、SHOW CONFIGURATIONおよびSHOW DATABASEコマンドを使用して、スイッチオーバー操作が正常終了したかどうかを検証します。

6.10.5 SWITCHOVERコマンドの使用(タスク5): 構成の表示

SHOW CONFIGURATIONコマンドを発行し、スイッチオーバーが正常終了したことを確認します。

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
South_Sales  - Primary database
West_Sales  - Logical standby database
North_Sales - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

6.11 使用例10: 手動フェイルオーバー操作の実行

フェイルオーバー操作は、緊急時(通常はプライマリ・データベースにアクセスできない場合または使用できない場合)の対応策として起動します。フェイルオーバー前にターゲット・スタンバイ・データベースの選択を参照し、どのスタンバイ・データベースをフェイルオーバーのターゲットにするかを判断してください。次の使用例では、リモート・データベースSouth_Salesへのフェイルオーバーについて説明します。

注意:

ファスト・スタート・フェイルオーバーが有効化されている場合、ファスト・スタート・フェイルオーバーのターゲットとして指定されているスタンバイ・データベースにかぎり、またオブザーバが実行中で現在スタンバイ・データベースと接続されている場合のみ、手動フェイルオーバーを実行できます。

ファスト・スタート・フェイルオーバーのターゲットではないスタンバイ・データベースへの手動フェイルオーバーを実行する場合は、まずフェイルオーバー先のスタンバイ・データベースでFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にする必要があります。FORCEオプションの詳細は、「ファスト・スタート・フェイルオーバーの無効化」を参照してください。

1. (オプション)ターゲット・スタンバイの準備状況の確認。

ターゲット・スタンバイ・データベースを検証し、新しいプライマリ・データベースになる準備ができていることを確認するには、次の例に示すように、VALIDATE DATABASEコマンドを使用します。

DGMGRL> VALIDATE DATABASE 'South_Sales';

Database Role: Physical standby database
Primary Database: South_Sales

Ready for Switchover: Yes
Ready for Failover: Yes

2. フェイルオーバー操作を実行するには、SYSDGまたはSYSDBA権限を持つユーザーとしてフェイルオーバー先のスタンバイ・データベースに接続する必要があります。次に例を示します。

DGMGRL> CONNECT sysdg@South_Sales.example.com;
Password: password
Connected as SYSDG.

3. フェイルオーバー・コマンドを発行すると、ターゲットのスタンバイ・データベースを構成の新しいプライマリ・データベースにできます。

DGMGRL> FAILOVER TO 'South_Sales';
Performing failover NOW, please wait...
Failover succeeded, new primary is "South_Sales"

フェイルオーバーの完了後は、「ロール変更後の無効化されたデータベースの再有効化」の説明に従って回復または再作成しないかぎり、元のプライマリ・データベースは新しいプライマリ・データベースのスタンバイ・データベースとして使用できないことに注意してください。

4. SHOW CONFIGURATIONコマンドを発行してフェイルオーバーを確認します。

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
South_Sales  - Primary database
Warning: ORA-16629: database reports a different protection level from the protection mode

North_Sales - Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated

Fast-Start Failover: DISABLED

Configuration Status:
WARNING

この例では、構成は最大可用性モードで動作していました。フェイルオーバーの後、保護モードは保持されました。構成では、警告ステータスも表示されています。新しいプライマリのSHOW DATABASEコマンドにより、有効なフィジカル・スタンバイ・データベースがないために警告が発生したことがわかります。その結果、警告ステータスは、構成の保護レベルと構成済のモードが同じでないことを示しています。

5. 新しいプライマリ・データベースを表示します。

DGMGRL> SHOW DATABASE South_Sales;
Database - South_Sales

Role:            PRIMARY
Intended State:  TRANSPORT-ON
Instance(s):
south_sales1

Database Warning(s):
ORA-16629: database reports a different protection level from the protection mode

Database Status:
WARNING

6. SHOW DATABASEコマンドを発行し、フェイルオーバーの結果として(障害が発生した)元のプライマリ・データベースがブローカにより無効化されたことを確認します。これは、「ロール変更後の無効化されたデータベースの再有効化」で説明されている手順に従って回復する必要があります。

DGMGRL> SHOW DATABASE 'North_Sales';
Database - North_Sales

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: (unknown)
Apply Lag: (unknown)
Apply Rate: (unknown)
Real Time Query: OFF
Instance(s):
north_sales1

Database Status:
ORA-16661: the standby database needs to be reinstated

6.12 使用例11: 障害が発生したプライマリ・データベースの回復

前のプライマリ・データベースがフラッシュバック・データベースを使用して構成された場合は、障害が発生したプライマリ・データベースを新しいプライマリ・データベースのスタンバイ・データベースとしてすぐに回復できます。障害が発生したプライマリ・データベースは、元のスタンバイ・データベースと同じスタンバイ・タイプとして回復します。たとえば、フィジカル・スタンバイ・データベースへのフェイルオーバーであった場合、元のプライマリはフィジカル・スタンバイ・データベースとして回復されます。

障害が発生したプライマリ・データベースを回復するには、データベースを起動してマウントされた状態にします。次に、DGMGRLを実行し、新しいプライマリ・データベースに接続して元のプライマリ・データベースを回復します。

1. 元のプライマリ・データベースの再起動

% dgmgrl connect sysdg
Password: password
Connected as SYSDG.
DGMGRL> startup mount;
ORACLE instance started.
Database mounted.

2. 元のプライマリ・データベースを回復します。

% dgmgrl connect sysdg
Password: password
Connected as SYSDG.
DGMGRL> REINSTATE DATABASE 'North_Sales';
Reinstating database "North_Sales", please wait...
Reinstatement of database "North_Sales" succeeded

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "north_sales1" on database "North_Sales"
Starting instance "north_sales1"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "North_Sales" ...
Reinstatement of database "North_Sales" succeeded

プライマリの回復が完了したら、SHOW CONFIGURATIONコマンドおよびSHOW DATABASEコマンドを発行して、元のプライマリが正常に回復したことを確認してください。

3. 構成およびデータベースを表示します。

DGMGRL> SHOW CONFIGURATION

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
South_Sales  - Primary database
North_Sales  - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

DGMGRL> SHOW DATABASE 'South_Sales';

Database - South_Sales

Role:            PRIMARY
Intended State:  TRANSPORT-ON
Instance(s):
south_sales1

Database Status:
SUCCESS

DGMGRL> SHOW DATABASE 'North_Sales'

Database - 'North_Sales'

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 0 seconds (computed 1 second ago)
Apply Rate: 0 Byte/s
Real Time Query: OFF
Instance(s):
north_sales1

Database Status:
SUCCESS

6.13 使用例12: フィジカル・スタンバイからスナップショット・スタンバイへの変換

スナップショット・スタンバイ・データベースに変換するフィジカル・スタンバイ・データベースがある場合は、DGMGRLのCONVERT DATABASEコマンドを使用します。データベースがスナップショット・スタンバイ・データベースとして動作中の間は、REDOデータはデータベースで引き続き受信されますが、スナップショット・スタンバイ・データベースが元のフィジカル・スタンバイ・データベースに変換されるまでREDOデータは適用されません。

フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換するには、フィジカル・スタンバイ・データベースをファスト・リカバリ領域で構成する必要があります。これは、変換プロセス中に作成される保証付きリストア・ポイントにファスト・リカバリ領域が必要であるためです。

DGMGRL> convert database 'South_Sales' to snapshot standby;
Converting database "South_Sales" to a Snapshot Standby database, please wait...
Database "South_Sales" converted successfully

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
South_Sales  - Snapshot standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

データベースを元のフィジカル・スタンバイ・データベースに戻すときは、次に示すように、DGMGRLのCONVERT DATABASEコマンドを再び使用します。スナップショット・スタンバイ・データベースとして動作中にデータベースに加えられた更新はすべて破棄されます。データベースが元のフィジカル・スタンバイ・データベースに変換されると、REDO Applyサービスによって、すべての累積REDOデータが適用されます。

DGMGRL> CONVERT DATABASE 'South_Sales' to PHYSICAL STANDBY;

Converting database "South_Sales" to a Physical Standby database, please wait...
Operation requires shutdown of instance "south_sales1" on database "South_Sales"
Shutting down instance "south_sales1"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "south_sales1" on database "South_Sales"
Starting instance "south_sales1"...
ORACLE instance started.
Database mounted.
Continuing to convert database "South_Sales" ...
Database "South_Sales" converted successfully

6.14 使用例13: Data Guard構成の監視

この項の使用例は、SHOWコマンドとデータベースの監視可能なプロパティを使用し、障害状況を識別して解決するために必要なタスクを示しています。

- 構成の監視(タスク1): 構成のステータス・チェック

- 構成の監視(タスク2): データベースのステータス・チェック

- 構成の監視(タスク3): 監視可能なプロパティLogXptStatusのチェック

- 構成の監視(タスク4): 監視可能なプロパティInconsistentPropertiesのチェック

- 構成の監視(タスク5): 監視可能なプロパティInconsistentLogXptPropsのチェック

6.14.1 構成の監視(タスク1): 構成のステータス・チェック

ブローカ構成のステータスは、ブローカ構成のすべてのデータベースとインスタンスのステータスが集計されたものです。最初に構成ステータスをチェックすると、さらに処置が必要かどうかを判断できます。構成ステータスがSUCCESSの場合は、ブローカ構成全体が正常に動作しています。一方、WARNINGまたはERRORステータスが表示される場合は、構成の一部に問題があることを意味します。

たとえば、次の例は、プライマリ・データベースに複数の警告があることを示しています。

DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
Warning: ORA-16809: multiple warnings detected for the database

South_Sales  - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
WARNING

6.14.2 構成の監視(タスク2): データベースのステータス・チェック

プライマリ・データベースの警告を確認するには、SHOW DATABASEコマンドを使用してステータスを表示します。

DGMGRL> SHOW DATABASE 'North_Sales';
Database - North_Sales

Role:            PRIMARY
Intended State:  TRANSPORT-ON
Instance(s):
north_sales1
Warning: ORA-16737: the redo transport service for standby "South_Sales" has an error
Warning: ORA-16714: the value of property LogArchiveTrace is inconsistent with the database setting
Warning: ORA-16715: redo transport-related property ReopenSecs of standby
database "South_Sales" is inconsistent

Database Status:
WARNING

6.14.3 構成の監視(タスク3): 監視可能なプロパティLogXptStatusのチェック

手順2のSHOW DATABASEの出力には、エラーORA-16737の警告が示されています。正確な転送エラーを確認するには、監視可能なプロパティLogXptStatusを使用します。

DGMGRL> SHOW DATABASE 'North_Sales' 'LogXptStatus';
LOG TRANSPORT STATUS
PRIMARY_INSTANCE_NAME  STANDBY_DATABASE_NAME  STATUS
north_sales1            South_Sales  ORA-12541: TNS:no listener

出力は、フィジカル・スタンバイ・データベースのリスナーが実行されていないことを示しています。このエラーを修正するには、フィジカル・スタンバイ・データベースSouth_Salesのリスナーを起動します。

6.14.4 構成の監視(タスク4): 監視可能なプロパティInconsistentPropertiesのチェック

手順2のSHOW DATABASEの出力には、エラーORA-16714の警告が示されています。正確なエラーを確認するには、監視可能なプロパティInconsistentPropertiesを使用します。

DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentProperties';
INCONSISTENT PROPERTIES
INSTANCE_NAME  PROPERTY_NAME   MEMORY_VALUE SPFILE_VALUE BROKER_VALUE
north_sales1   LogArchiveTrace 511          255          255

現在のデータベース・メモリー値(511)が、サーバー・パラメータ・ファイル(SPFILE)の値(255)ともOracle Data Guard Brokerのプロパティ値(255)とも異なっています。データベース・メモリー値が正しいと判断した場合は、次のコマンドを使用してOracle Data Guard Brokerのプロパティ値を更新できます。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogArchiveTrace'=511;
Property "LogArchiveTrace" updated

このコマンドを発行すると、LogArchiveTraceの値の一貫性が保たれるようにサーバー・パラメータ・ファイル(SPFILE)の値が更新されます。

6.14.5 構成の監視(タスク5): 監視可能なプロパティInconsistentLogXptPropsのチェック

手順2のSHOW DATABASEの出力には、もう1つの警告ORA-16715も示されています。REDO転送のデータベース・プロパティReopenSecsについて一貫性のない値を識別するには、監視可能なプロパティInconsistentLogXptPropsを使用します。

DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps';
INCONSISTENT LOG TRANSPORT PROPERTIES
INSTANCE_NAME  STANDBY_NAME  PROPERTY_NAME  MEMORY_VALUE  BROKER_VALUE
south_sales1   South_Sales     ReopenSecs           600           300

現行のデータベース・メモリー値(600)は、Oracle Data Guard Brokerのプロパティ値(300)と一致しません。ブローカのプロパティ値が正しいと判断した場合は、次の例に示すように、スタンバイ・データベースのプロパティを同じ値で再編集して一貫性のある値にできます。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'ReopenSecs'=300;
Property "ReopenSecs" updated

スタンバイ・データベースを再び有効化するか、プライマリ・データベースの状態をTRANSPORT-ONにリセットして、非一貫性を解決することもできます。

7 Oracle Data Guardコマンドライン・インタフェース・リファレンス

Data Guardコマンドライン・インタフェース(DGMGRL)を使用すると、Data Guard Broker構成とその様々なメンバーを、コマンドラインから直接、あるいはバッチ・プログラムやスクリプトから管理できます。Data Guardコマンドライン・インタフェースは、Data Guard構成を管理するためのOracle Enterprise Manager Cloud Control (Cloud Control)の代替手段として使用できます。

- Data Guardコマンドライン・インタフェースの起動

- Data Guardコマンドライン・インタフェースの終了

7.1 Data Guardコマンドライン・インタフェースの起動

DGMGRLを実行するには、SYSDGまたはSYSDBA管理権限を持つ必要があります。

コマンドライン・インタフェースを起動するには、Oracleがインストールされているシステム上で、コマンドライン・プロンプトからdgmgrlと入力します。

% dgmgrl

DGMGRLコマンド・プロンプトが表示されます。

DGMGRL>

7.1.1 DGMGRLのオプション・パラメータ

コマンドラインからオプション・パラメータを入力して、Data Guardコマンドライン・インタフェースでのコマンド・プロンプト、バナーおよびメッセージなどの出力の表示方法を指定できます。

また、単一コマンド・モードも使用可能です。このモードのDGMGRLでは、1つのコマンドが実行され、そのコマンドの終了時にDGMGRLも終了します。終了コードとしてコマンドの結果が戻されます。終了コードが0であれば、コマンドは正常終了しています。それ以外の場合は、エラーがあります。

DGMGRLのコマンドラインは次のとおりです。

% dgmgrl [<options>] [<logon> [<command>] ]

DGMGRLコマンドライン・インタフェースの起動時に、次の任意のキーワードを指定します。

- <options>には、次のいずれか1つを選択できます。

- -echo
コマンドの入力と出力をデフォルトの表示デバイスに表示します。このパラメータを使用しない場合、コマンドからの出力のみが表示されます。

- -logfile <file-spec> "<dgmgrl-command>"
DGMGRLコマンドライン・インタフェースの処理情報を取得するファイルを指定します。これは特に、ファスト・スタート・フェイルオーバーのオブザーバとして機能させるためにDGMGRLを起動する場合に役立ちます。詳細は、「START OBSERVER」コマンドを参照してください。

参照:

- 「START OBSERVER」コマンド

- オブザーバ・ログ・ファイルでのオブザーバの処理の取得

- -silent
DGMGRLのコマンド・プロンプト(DGMGRL>)をデフォルトの表示デバイスに表示しません。このオプションは、コマンド出力をファイルまたは他の表示ツールに送る場合に役立ちます。

- <logon>は次のとおりです。

- username [@connect-identifier]
データベースに接続するには、usernameと、オプションでconnect-identifierを入力します。次に、パスワードの入力を求められます。connect-identifierは、完全指定の接続記述子またはOracleネーミング・メソッド(TNSなど)により解決される名前です。

完全指定の接続記述子が使用されている場合は、適切に動作させるために一重引用符および二重引用符で記述子を囲む必要があります。次に例を示します。

dgmgrl sys@"'(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP) (HOST=sales-server) (PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=sales.us.example.com)))'"

Enter password: password

これは、簡易接続ネーミング・メソッドが使用される場合にも適用されます。

警告:

DGMGRLの起動時にコマンドラインでパスワードを指定することには、安全上のリスクがあります。このリスクは、DGMGRLの起動時はパスワードを省略し、後で求められたときに入力するか、外部の認証方式を使用することで回避できます。

- オペレーティング・システム認証(リモート・データベースの再起動を除く)、Secure Sockets Layer(SSL)プロトコルまたはウォレットに格納されたデータベース資格証明を使用する場合は、'/'として接続できます。

- <command>は1つのコマンドです。
次に例を示します。

% dgmgrl sys/ "show database 'North_Sales'"

Password: パスワード

次の各項で、DGMGRL>コマンド・プロンプトから入力するコマンドの書式について説明します。

7.1.2 DGMGRLコマンドの書式とパラメータ

DGMGRLコマンドを使用すると、一度に1つのブローカ構成を作成およびメンテナンスできます。

コマンドライン・インタフェースの起動後は、表7-1に示す任意のDGMGRLコマンドを入力できます。

表7-1 DGMGRLコマンドの要約

コマンド

効果

ADD DATABASE

既存のブローカ構成に新しいスタンバイ・データベースを追加します。

ADD FAR_SYNC

既存の遠隔同期インスタンスをOracle Data Guard Broker構成に追加します。

CONNECT

指定のユーザー名を使用して指定のデータベースに接続します。

CONVERT DATABASE

指定されたデータベースをスナップショット・スタンバイ・データベースまたはフィジカル・スタンバイ・データベースに変換します。

CREATE CONFIGURATION

ブローカ構成を作成し、プライマリ・データベースをその構成に追加します。

DISABLE CONFIGURATION

構成とそのすべてのデータベースがブローカによる管理対象から外れるように、構成のブローカ管理を無効化します。

DISABLE DATABASE

指定したスタンバイ・データベースのブローカ管理を無効化します。

DISABLE FAR_SYNC

遠隔同期インスタンスのブローカ管理を無効にします。

DISABLE FAST_START FAILOVER

ファスト・スタート・フェイルオーバーを無効化します。

DISABLE FAST_START FAILOVER CONDITION

ユーザーによるファスト・スタート・フェイルオーバーの実行条件の削除を可能にします。

EDIT CONFIGURATION(プロパティ)

ブローカ構成のプロパティ値を変更します。

EDIT CONFIGURATION(保護モード)

ブローカ構成の現在の保護モード設定を変更します。

EDIT CONFIGURATION (RENAME)

構成名を変更します。

EDIT CONFIGURATION RESET (プロパティ)

指定された構成プロパティをそのデフォルト値にリセットします。

EDIT DATABASE(プロパティ)

指定したデータベースのプロパティ値を変更します。

EDIT DATABASE(名前の変更)

ブローカにより指定したデータベースの参照に使用される名前を変更します。

EDIT DATABASE(状態)

指定したデータベースの状態を変更します。

EDIT DATABASE RESET (プロパティ)

指定されたデータベースの指定されたプロパティをそのデフォルト値にリセットします。

EDIT FAR_SYNC

遠隔同期インスタンスの名前、状態またはプロパティを変更します。

EDIT FAR_SYNC RESET (プロパティ)

指定された遠隔同期インスタンスの指定されたプロパティをそのデフォルト値にリセットします。

EDIT INSTANCE (AUTO PFILE)

指定したインスタンスの初期化パラメータ・ファイル名を設定します。

EDIT INSTANCE(プロパティ)

指定したインスタンスのプロパティ値を変更します。

EDIT INSTANCE RESET (プロパティ)

指定されたインスタンスのインスタンス固有のプロパティを、そのデフォルト値にリセットします。

ENABLE CONFIGURATION

ブローカ構成とそのすべてのデータベースのブローカ管理を有効化します。

ENABLE DATABASE

指定したデータベースのブローカ管理を有効化します。

ENABLE FAR_SYNC

指定した遠隔同期インスタンスのブローカ管理を有効化します。

ENABLE FAST_START FAILOVER

ブローカによるプライマリ・データベースからターゲット・スタンバイ・データベースへの自動的なフェイルオーバーを可能にします。

ENABLE FAST_START FAILOVER CONDITION

ユーザーによるファスト・スタート・フェイルオーバーの実行条件の追加を可能にします。

EXIT

Data Guardコマンドライン・インタフェースを終了します。

FAILOVER

データベース・フェイルオーバー操作を実行します。この操作では、現在DGMGRLが接続しているスタンバイ・データベースが、プライマリ・データベースのロールにフェイルオーバーされます。

HELP

Data Guardコマンドライン・インタフェースのオンライン・ヘルプを表示します。

QUIT

Data Guardコマンドライン・インタフェースを終了します。

REINSTATE DATABASE

フェイルオーバー後、データベースを回復します。

REMOVE CONFIGURATION

ブローカ構成を削除し、そのメンバーのブローカ管理を終了します。

REMOVE DATABASE

指定したスタンバイ・データベースをブローカ構成から削除します。

REMOVE FAR_SYNC

既存の遠隔同期インスタンスをOracle Data Guard Broker構成から削除します。

REMOVE INSTANCE

ブローカ構成からインスタンスを削除します。

SHOW CONFIGURATION

ブローカ構成に関する情報を表示します。

SHOW CONFIGURATION WHEN PRIMARY IS

指定したデータベースがプライマリ・データベースであった場合に有効になるREDO転送構成を表示します。

SHOW DATABASE

指定したデータベースに関する情報を表示します。

SHOW FAR_SYNC

遠隔同期インスタンスに関する情報を表示します。

SHOW FAST_START FAILOVER

すべてのファスト・スタート・フェイルオーバー関連情報を表示します。

SHOW INSTANCE

指定したインスタンスに関する情報を表示します。

SHUTDOWN

現在実行中のOracleデータベースを停止します。

SQL

Data Guardコマンドライン・インタフェース(DGMGRL)からのSQL文の入力を許可します。

START OBSERVER

オブザーバを開始します。

STARTUP

データベースのマウントやオープンなど、SQL*Plusと同じオプションを指定してOracleインスタンスを起動します。

STOP OBSERVER

オブザーバを停止します。

SWITCHOVER

スイッチオーバー操作を実行します。現行のプライマリ・データベースがスタンバイ・データベースになり、指定したスタンバイ・データベースがプライマリ・データベースになります。

VALIDATE DATABASE

ロール変更に先立って包括的なデータベース・チェックを実行します。

VALIDATE FAR_SYNC

遠隔同期インスタンスに対する一連の包括的なチェックを実行します。

7.1.3 DGMGRLコマンドの使用上の注意

DGMGRLを使用するには、次の条件が満たされている必要があります。

- DG_BROKER_START動的初期化パラメータをTRUEに設定します。

- 手動操作なしでインスタンスを再起動する必要のあるブローカ操作を有効化するには、プライマリとスタンバイのデータベース・インスタンスを含む各ホスト上でOracle Net Servicesを構成する必要があります。特に、listener.oraファイルにインスタンスの静的構成情報が含まれていることが必要です。GLOBAL_DBNAME属性を、db_unique_name_DGMGRL.db_domainに設定する必要があります。詳細は、「前提条件」を参照してください。

- 構成の作成時またはデータベースの追加時に使用する接続識別子は、構成内のすべてのホストから解決可能である必要があります。

- Oracle Data Guardコマンドライン・インタフェースを使用するには、SYSDGまたはSYSDBA権限が必要です。CONNECTコマンド上に、AS SYSDGまたはAS SYSDBAを含めないでください。DGMGRLは先にAS SYSDG接続を試み、それが失敗したら、AS SYSDBA接続を試みます。

- コマンドで複数のオプションを指定する場合、指定する順序は問われません。

- 各DGMGRLコマンドの末尾にセミコロンを付ける必要があります。

- DGMGRLコマンド文字列の値で指定する文字は、二重引用符(")または一重引用符(')で囲まれていない場合、小文字として解釈されます。たとえば、databaseとDatAbaSeは同じですが、"database"と"DatAbaSe"は異なります。

- 一重引用符(')、二重引用符(")およびバックスラッシュ(\)が文字列に含まれている場合は、これらの文字のエスケープ文字としてバックスラッシュ(\)を使用できます。

- ブローカ構成では、1つ以上のデータベースのシャットダウンと再起動が必要となる操作がいくつかあります。次の条件を満たす場合はほとんど、特定のデータベースのシャットダウンと再起動がDGMGRLによって自動的に行われます。

- instance-nameはSIDです(Cloud ControlとDGMGRLに適用されます)。

- ブローカは、最後のCONNECTコマンドが別のデータベースへの接続に使用された場合でも、最後のCONNECTコマンドに指定された資格証明を使用してデータベースに接続できる必要があります。

コマンドの例

例7-1 ローカル・システム上のDGMGRLへの接続

この例は、ローカル・システム上でDGMGRLコマンドライン・インタフェースに接続する方法を示しています。

% dgmgrl
.
.
.
Welcome to DGMGRL, type "help" for information.

DGMGRL> CONNECT sysdg;
Password: password
Connected as SYSDG.

例7-2 リモート・システム上のDGMGRLへの接続

この例は、リモート・システム上でOracle Data Guard (DGMGRL)コマンドライン・インタフェースに接続する方法を示しています。

DGMGRL> CONNECT sysdg@remote-stby;
Password: password
Connected as SYSDG.

例7-3 ASオプションを使用した接続

この例は、CONNECT ASオプションを使用してOracle Data Guard (DGMGRL)コマンドライン・インタフェースに接続する方法を示しています。

DGMGRL> CONNECT sys@remote-stby AS SYSDBA;
Password: password
Connect as SYSDBA.

7.2 Data Guardコマンドライン・インタフェースの終了

コマンドライン・インタフェースでの作業を完了し、オペレーティング・システムに戻るには、DGMGRLコマンド・プロンプトからEXITまたはQUITコマンドを入力します。次に例を示します。

DGMGRL> EXIT;

7.3 ADD DATABASE

DGMGRLのADD DATABASEコマンドは、既存のブローカ構成にスタンバイ・データベースを追加します。

書式

ADD DATABASE database-name AS CONNECT IDENTIFIER IS connect-identifier;

コマンド・パラメータ

database-name

ブローカでこのスタンバイ・データベースを参照するために使用される名前。この名前は、対応するデータベースのDB_UNIQUE_NAME初期化パラメータの値と一致する(大/小文字は区別されません)必要があります。

connect-identifier

完全指定の接続記述子またはOracle Net Servicesのネーミング・メソッド(TNSなど)により解決される名前です。指定した値は、データベース・プロパティDGConnectIdentifierの初期値としても使用されます。

使用上の注意

- このコマンドを発行するには、プライマリ・データベースまたは構成内にすでに存在する有効化されたスタンバイ・データベースに接続する必要があります。

- ブローカでは、指定したconnect-identifierが、他のデータベースから指定したデータベースへの通信に使用されます。したがって、構成内のすべてのデータベースから指定のデータベースへのアドレス指定に、connect-identifierを使用できることを確認する必要があります。たとえば、TNSをネーミング・メソッドとして使用する場合、構成内のすべてのデータベースとインスタンスのtnsnames.oraファイルにconnect-identifierのエントリが含まれることを確認する必要があります。接続識別子は同じ接続記述子に解決される必要があります。追加するデータベースがOracle RACデータベースである場合、Oracle RACのすべてのインスタンスにアクセスできる接続識別子を指定する必要があります。FAILOVER属性を設定することをお薦めします。

参照:

『Oracle Database Net Services管理者ガイド』

- 接続できない場合、ブローカでは新しいデータベースが構成に追加されません。

- リモートREDO転送先は、スタンバイ・データベース上ですべてクリアしてからでないと、構成に追加できません。

コマンドの例

次の例に、データベースSouth_Salesを追加する方法を示します。

DGMGRL> ADD DATABASE South_Sales AS CONNECT IDENTIFIER IS South_Sales.example.com;
Database "South_Sales" added

7.4 ADD FAR_SYNC

既存の遠隔同期インスタンスをOracle Data Guard Broker構成に追加します。

作成された遠隔同期インスタンスは無効化されています。ブローカがそれとの間でREDOをやりとりするには、それを明示的に有効にする必要があります。

書式

ADD FAR SYNC far_sync_instance_name AS CONNECT IDENTIFIER IS connect-identifier;

コマンド・パラメータ

far_sync_instance_name

ブローカでこの遠隔同期インスタンスを参照するために使用する名前。これは、対応する遠隔同期インスタンスの初期化パラメータDB_UNIQUE_NAMEの値と一致する必要があります(大/小文字は区別されません)。

connect-identifier

完全指定の接続記述子またはOracle Net Servicesのネーミング・メソッド(TNSなど)により解決される名前です。指定した値は、DGConnectIdentifierプロパティの初期値としても使用されます。

使用上の注意

- ブローカ構成に遠隔同期インスタンスを追加するには、先にそれが存在する必要があります。

- リモートREDO転送先は、遠隔同期インスタンス上ですべてクリアしてからでないと、構成に追加できません。

コマンドの例

次の例は、chicagoという名前の遠隔同期インスタンスを構成に追加します。

DGMGRL> ADD FAR_SYNC chicago AS CONNECT IDENTIFIER IS chicago.example.com;

7.5 CONNECT

DGMGRLのCONNECTコマンドを使用すると、Data Guard Broker構成のメンバーであるデータベースまたは遠隔同期インスタンスに接続できます。

書式

CONNECT username @connect-identifer;

コマンド・パラメータ

username

構成メンバーへの接続に使用するユーザー名。ユーザー名と、オプションでconnect-identifierを入力すると、パスワードの入力を求められます。

connect-identifier

このパラメータはオプションです。このパラメータは、接続先構成メンバーのOracle Net Services接続識別子です。正確な構文は、Oracleのインストールで使用されるOracle Net Services通信プロトコルによって異なります。

使用上の注意

- 接続を試みる構成メンバーに対してユーザー名とパスワードが有効である必要があります。
指定するユーザー名には、SYSDGまたはSYSDBA権限が必要です。CONNECTコマンド上に、AS SYSDGまたはAS SYSDBAを含めないでください。DGMGRLは先にAS SYSDG接続を試み、それが失敗したら、AS SYSDBA接続を試みます。

- CONNECTコマンドでエラーが戻される場合は、有効なconnect-identifierを指定したことを確認してください。

コマンドの例

例1: ローカルの構成メンバーへの接続

この例は、ローカル・システム上のデフォルトのデータベースまたは遠隔同期インスタンスに接続します。

DGMGRL> CONNECT sysdg;
Password: password
Connected as SYSDG.

例2: リモートの構成メンバーへの接続

この例は、ローカル・システム上のデフォルトのデータベースまたは遠隔同期インスタンスに接続します。

DGMGRL> CONNECT sysdg;
Password: password
Connected as SYSDG.

例3: 接続資格証明を表示しない接続

この例では、コマンドラインで接続資格証明を表示できないように、CONNECT '/'を使用して構成メンバーに接続しています。

DGMGRL> CONNECT /@North_Sales.example.com;

CONNECT '/'を使用するには、OracleウォレットまたはSSLを設定する必要があります。OracleウォレットまたはSSLを設定することで、スクリプトでデータベース資格証明を指定せずに、オブザーバをバックグラウンド・ジョブとして安全に起動および実行するためのスクリプトを記述できます。

7.6 CONVERT DATABASE

フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換するか、スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに戻します。

スナップショット・スタンバイ・データベースは完全に更新可能なスタンバイ・データベースです。フィジカルまたはロジカル・スタンバイ・データベースと同様に、スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信し、アーカイブします。フィジカルまたはロジカル・スタンバイ・データベースとは異なり、スナップショット・スタンバイ・データベースは、受信したREDOデータを適用しません。スナップショット・スタンバイ・データベースが受信したREDOデータは、スナップショット・スタンバイが元のフィジカル・スタンバイ・データベースに変換され、スナップショット・スタンバイ・データベースに対するすべてのローカルな更新が破棄された後に適用されます。

スナップショット・スタンバイ・データベースの最適な使用例は、更新可能なフィジカル・スタンバイ・データベースのスナップショットが一時的に必要な場合です。スナップショット・スタンバイ・データベースでは、フィジカル・スタンバイに戻るまで受信したREDOデータが適用されないため、ロール遷移の実行に要する時間は、適用する必要があるREDOデータの量に正比例します。

スナップショット・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。

書式

CONVERT DATABASE db_unique_name TO  {SNAPSHOT | PHYSICAL}  STANDBY;

使用上の注意

- ファスト・スタート・フェイルオーバーのターゲットである場合、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換できません。「ORA-16668: ファスト・スタート・フェイルオーバー・ターゲットのスタンバイ・データベースでは操作を実行できません」というエラーが表示されます。

- 構成可能なプロパティRedoRoutesがNullでない値に設定されている場合、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換できません。

- DGMGRL ADD DATABASEコマンドを使用して、既存のスナップショット・スタンバイ・データベースをOracle Data Guard Broker構成にインポートしてください。

- スナップショット・スタンバイ・データベースを、スイッチオーバーまたはファスト・スタート・フェイルオーバーのターゲットにすることはできません。

- ファスト・スタート・フェイルオーバーが無効化されている場合、スナップショット・スタンバイ・データベースは、手動フェイルオーバーのターゲットにすることができます。

- SHOW CONFIGURATIONまたはSHOW DATABASEコマンドを使用して、変換の結果を確認できます。次に例を示します。

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
South_Sales  - Snapshot standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

- スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに戻すと、フィジカル・スタンバイ・データベースのデフォルトのAPPLY-ONの状態になります。

コマンドの例

例1: フィジカル・スタンバイからスナップショット・スタンバイへの変換

次のコマンドを発行して、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換します。

DGMGRL> CONVERT DATABASE 'South_Sales' to SNAPSHOT STANDBY;
Converting database "South_Sales" to a Snapshot Standby database, please wait...
Database "South_Sales" converted successfully

例2: スナップショット・スタンバイからフィジカル・スタンバイへの再変換

次のコマンドを発行して、スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに戻します。

DGMGRL> CONVERT DATABASE 'South_Sales' to PHYSICAL STANDBY;
Converting database "South_Sales" to a Physical Standby database, please wait...
Operation requires shutdown of instance "south_sales1" on database "South_Sales"
Shutting down instance "south_sales1"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "south_sales1" on database "South_Sales"
Starting instance "south_sales1"...
ORACLE instance started.
Database mounted.
Continuing to convert database "South_Sales" ...
Database "South_Sales" converted successfully

7.7 CREATE CONFIGURATION

指定されたプライマリ・データベースを含む新しいブローカ構成を作成します。

書式

CREATE CONFIGURATION configuration_name AS PRIMARY DATABASE IS database-name CONNECT IDENTIFIER IS connect-identifier;

コマンド・パラメータ

configuration-name

作成する構成のわかりやすい名前。有効な名前には英数字が含まれます。名前に空白を含める場合は、その名前を二重引用符または一重引用符で囲む必要があります。名前は30バイト以内で指定してください。

database-name

ブローカでプライマリ・データベースを参照するために使用される名前。この名前は、プライマリ・データベースのDB_UNIQUE_NAME初期化パラメータの値と一致する(大/小文字は区別されません)必要があります。

connect-identifier

完全指定の接続記述子またはOracle Net Servicesのネーミング・メソッド(TNSなど)により解決される名前です。指定した値は、データベース・プロパティDGConnectIdentifierの初期値としても使用されます。

使用上の注意

- ブローカ構成は、グループとして管理する必要のある1つ以上のデータベースの名前付きコレクションです。各コマンド・パラメータの値を指定する必要があります。デフォルト値はありません。

- このコマンドを発行するには、プライマリ・データベースに接続する必要があります。

- ブローカでは、指定したconnect-identifierが、他のデータベースから指定したデータベースへの通信に使用されます。したがって、構成内のすべてのデータベースから指定のデータベースへのアドレス指定に、connect-identifierを使用できることを確認する必要があります。たとえば、TNSをネーミング・メソッドとして使用する場合、構成内のすべてのデータベースとインスタンスのtnsnames.oraファイルにconnect-identifierのエントリが含まれることを確認する必要があります。接続識別子は同じ接続記述子に解決される必要があります。追加するデータベースがOracle RACデータベースである場合、Oracle RACのすべてのインスタンスにアクセスできる接続識別子を指定する必要があります。FAILOVER属性を設定することをお薦めします。

参照:

『Oracle Database Net Services管理者ガイド』

- ブローカ構成の作成後にスタンバイ・データベースを追加するには、ADD DATABASEコマンドを使用します。

- NOREGISTER属性のないプライマリ・データベース上ですべてのリモートREDO転送先をクリアしてからでないと、構成を作成できません。

コマンドの例

次の例では、プライマリ・データベースNorth_Salesを含む新しいブローカ構成DRSolutionを作成しています。

DGMGRL> CREATE CONFIGURATION 'DRSolution' AS
> PRIMARY DATABASE IS 'North_Sales'
> CONNECT IDENTIFIER IS North_Sales.example.com;
Configuration "DRSolution" created with primary database "North_Sales"

7.8 DISABLE CONFIGURATION

構成とそのすべてのデータベースがブローカによる管理対象から外れるように、構成のブローカ管理を無効化します。

書式

DISABLE CONFIGURATION

コマンド・パラメータ

なし。

使用上の注意

- 無効化された構成およびそこに含まれるすべてのデータベースが、ブローカで管理されなくなります。

- プライマリ・データベースのブローカ管理を無効にするには、DISABLE CONFIGURATIONコマンドを使用する必要があります。

- このコマンドは、構成ファイルからブローカ構成を削除しません。構成を削除する方法の詳細は、REMOVE CONFIGURATIONコマンドを参照してください。

- 構成が無効になっている間、データベース・プロパティを編集したり構成の保護モードを変更できます。ただし、プロパティや保護モードの変更結果は、構成が有効化されるまで有効になりません。

- このコマンドは、ファスト・スタート・フェイルオーバーが有効になっている場合は実行できません。

コマンドの例

次の例では、ブローカ構成およびそのすべてのデータベースの管理を無効化しています。

DGMGRL> DISABLE CONFIGURATION;
Disabled.

7.9 DISABLE DATABASE

指定したスタンバイ・データベースのブローカ管理を無効化します。つまり、ブローカではこのデータベースの状態を変更できなくなり、ブローカはデータベースの健全性ステータスや監視可能なプロパティを監視しません。

書式

DISABLE DATABASE database-name;

コマンド・パラメータ

database-name

無効化するスタンバイ・データベースの名前。

使用上の注意

- プライマリ・データベース名は指定できません。

- プライマリ・データベースとすべてのスタンバイ・データベースを無効化するには、DISABLE CONFIGURATIONコマンドを使用します。

- スタンバイ・データベースを1つのみ無効化する場合、フェイルオーバー・オプションを使用できません。このスタンバイ・データベースは、再び有効化するまでは実行できなくなります。

- ファスト・スタート・フェイルオーバーが有効化されているとき、このコマンドを使用してファスト・スタート・フェイルオーバーのターゲット・データベースを無効にすることはできません。

コマンドの例

次の例に、データベースSouth_Salesを無効化する方法を示します。

DGMGRL> DISABLE DATABASE 'South_Sales';
Disabled.

7.10 DISABLE FAR_SYNC

遠隔同期インスタンスのブローカ管理を無効にします。

書式

DISABLE FAR_SYNC far_sync_instance_name;

コマンド・パラメータ

far_sync_instance_name

無効にする遠隔同期インスタンスの名前。

使用上の注意

- RedoRoutesプロパティが設定されている遠隔同期インスタンスは、無効化できません。

コマンドの例

次の例は、chicagoという名前の遠隔同期インスタンスのブローカ管理を無効にします。

DGMGRL> DISABLE FAR_SYNC 'chicago';

7.11 DISABLE FAST_START FAILOVER

ファスト・スタート・フェイルオーバーを無効化し、オブザーバによりターゲット・スタンバイ・データベースへのフェイルオーバーが開始されないようにします。詳細は、「ファスト・スタート・フェイルオーバーの無効化」を参照してください。

書式

DISABLE FAST_START FAILOVER [ FORCE ];

コマンド・パラメータ

なし。

使用上の注意

- プライマリ・データベースとターゲット・スタンバイ・データベースにネットワーク接続がある場合、ブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーを無効化するには、FORCEオプションを指定せずにDISABLE FAST_START FAILOVERを使用します。無効化操作中にエラーが発生した場合、ブローカによりエラー・メッセージが戻され、無効化操作が停止されます。エラー状態をオーバーライドし、接続先データベースのファスト・スタート・フェイルオーバーを無効化するには、FORCEオプションを指定してDISABLE FAST_START FAILOVERコマンドを再発行する必要があります。詳細は、「ファスト・スタート・フェイルオーバーの無効化」を参照してください。

- プライマリ・データベースとターゲット・スタンバイ・データベース間のネットワークが切断されている場合、またはコマンドを受信するデータベースに、プライマリ・データベースとの接続がない場合には、FORCEオプションを指定してDISABLE FAST_START FAILOVERを使用します。FORCEオプションは、エラー発生時でも、接続先データベースのファスト・スタート・フェイルオーバーを無効化します。

- オブザーバおよびターゲットのスタンバイ・データベースから切断されたプライマリ・データベース上でFORCE オプションを指定してファスト・スタート・フェイルオーバーを無効化しても、オブザーバによる、ターゲットのスタンバイ・データベースへのファスト・スタート・フェイルオーバーの開始を無効にはできません。

- ブローカ構成のいずれかのデータベースに接続している場合、そのデータベースとプライマリ間が接続されていれば、ファスト・スタート・フェイルオーバーを無効化できます。

- ターゲットのスタンバイ・データベース上で強制オプション付きで無効化され、その後プライマリ・データベースとの接続が再開された場合、ファスト・スタート・フェイルオーバーは、構成内のすべてのデータベースで無効化されています。

- プライマリ・データベースとターゲット・スタンバイ・データベースがネットワークで接続されている場合、プライマリに接続しているときにFORCEオプションを指定してファスト・スタート・フェイルオーバーを無効化すると、ターゲット・スタンバイ・データベースのファスト・スタート・フェイルオーバーが無効になります。

コマンドの例

例1: ファスト・スタート・フェイルオーバーの無効化

次の例に、ファスト・スタート・フェイルオーバーを無効化する方法を示します。

DGMGRL> DISABLE FAST_START FAILOVER;
Disabled.

例2: FORCEを使用したファスト・スタート・フェイルオーバーの無効化

次の例では、接続先のデータベースでファスト・スタート・フェイルオーバーを無効化するFORCEオプションを使用しています。

DGMGRL> DISABLE FAST_START FAILOVER FORCE;
Disabled.

7.12 DISABLE FAST_START FAILOVER CONDITION

ユーザーによるファスト・スタート・フェイルオーバーの実行条件の削除を可能にします。

書式

DISABLE FAST_START FAILOVER CONDITION value;

コマンド・パラメータ

value

有効な値は、ファスト・スタート・フェイルオーバーが有効化されている任意の条件です。

使用上の注意

条件が設定されていない場合、認識されていない条件の場合、エラーは発生しません。

コマンドの例

この例では、破損した制御ファイルが検出されても自動的に即時ファスト・スタート・フェイルオーバーが開始されないように指定します。

DGMGRL> DISABLE FAST_START FAILOVER CONDITION "Corrupted Controlfile";

7.13 EDIT CONFIGURATION (プロパティ)

ブローカ構成のプロパティ値を変更します。

書式

EDIT CONFIGURATION SET PROPERTY property-name=value;

コマンド・パラメータ

property-name

構成プロパティの名前

value

新しいプロパティ値。

参照:

構成プロパティの詳細は、「ブローカ構成のメンバーの管理」および「Oracle Data Guard Brokerのプロパティ」を参照

使用上の注意

- プライマリ・データベースに、またはそのプライマリ・データベースと接続された構成内の任意のスタンバイ・データベースに接続されている場合に、このコマンドを発行します。

- 構成の現在のプロパティ情報を表示するには、SHOW CONFIGURATIONコマンドを使用します。

コマンドの例

次の例に、FastStartFailoverThreshold構成プロパティを90秒に設定する方法を示します。

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold=90;

7.14 EDIT CONFIGURATION(保護モード)

ブローカ構成の現在の保護モード設定を編集します。

書式

EDIT CONFIGURATION SET PROTECTION MODE AS protection-mode;

コマンド・パラメータ

protection-mode

構成が有効な場合に、その構成で実行するデータ保護モード。可能な保護モードは次のとおりです。

- MAXPROTECTION

- MAXAVAILABILITY

- MAXPERFORMANCE

使用上の注意

- EDIT CONFIGURATIONコマンドを使用して保護モードをMAXPROTECTIONまたはMAXAVAILABILITYモードに設定する前に、少なくとも1つのスタンバイが、プライマリから直接REDOを受け取る場合にSYNCまたはFASTSYNCモードでREDOを受け取るように構成されていることを確認してください。スタンバイが遠隔同期インスタンスを介してREDOを受け取る場合、遠隔同期インスタンスはSYNCまたはFASTSYNCモードでREDOを受け取るように構成され、スタンバイはASYNCモードでREDOを受け取るように構成される必要があります。

- 次の表は、構成の保護モードと、REDO転送サービスの対応する最低限の設定を示しています。

保護モード

REDO転送

スタンバイREDOログ・ファイルの要否

ファスト・スタート・フェイルオーバーとの併用

MAXPROTECTION

SYNC

必要

いいえ

MAXAVAILABILITY

SYNCまたはFASTSYNC

必要

はい

MAXPERFORMANCE

ASYNC

必要

はい

構成のデフォルトの保護モードはMAXPERFORMANCEです。

参照:

保護モードとREDO転送サービスの詳細は、「ブローカ構成のメンバーの管理」を参照

- ファスト・スタート・フェイルオーバーを有効化するには、MAXAVAILABILITYまたはMAXPERFORMANCEが必要です。

- このコマンドは、ファスト・スタート・フェイルオーバーが有効になっている場合は実行できません。

- 最大パフォーマンス・モードから最大保護モードにアップグレードする際、まず最大可用性モードにアップグレードすることで、プライマリ・データベースの再起動を回避できます。次に、V$DATABASEのPROTECTION_LEVEL列にMAXIMUM AVAILABILITYの値が含まれるのを待ちます。列にその値が含まれたら、最大保護モードにアップグレードできます。

- SHOW CONFIGURATIONコマンドを使用して構成の現在の保護モードを表示します。

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
South_Sales     - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

EDIT CONFIGURATIONコマンドの入力時に構成のブローカ管理が無効になっている場合、構成の保護モードは、次回ENABLE CONFIGURATIONコマンドを使用して構成を有効化するまで有効にはなりません。

コマンドの例

次の例は、ブローカ構成をMAXAVAILABILITY保護モードにアップグレードする方法を示しています。

次のように、スタンバイ・データベースでスタンバイREDOログ・ファイルが構成されていること、REDO転送サービスがSYNCに設定されていることを確認します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
Succeeded.

7.15 EDIT CONFIGURATION (RENAME)

構成名を変更します。

書式

EDIT CONFIGURATION RENAME TO new_configuration-name;

コマンド・パラメータ

new-configuration-name

構成の新しい名前。

コマンドの例

次の例は、DR_Salesという名前の構成の名前をHA_Salesに変更する方法を示しています。

DGMGRL> show configuration

Configuration - DR_Sales

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
South_Sales  - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
DISABLED

DGMGRL> edit configuration rename to "HA_Sales";
Succeeded.
DGMGRL> enable configuration
Enabled.
DGMGRL> show configuration

Configuration - HA_Sales

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
South_Sales  - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

7.16 EDIT CONFIGURATION RESET (プロパティ)

指定された構成プロパティをそのデフォルト値にリセットします。

書式

EDIT CONFIGURATION RESET PROPERTY property-name;

コマンド・パラメータ

property-name

既存の構成プロパティの名前。

使用上の注意

- プライマリ・データベースに、またはそのプライマリ・データベースと接続された構成内の任意のスタンバイ・データベースに接続されている場合に、このコマンドを発行します。

- 構成の現在のプロパティ情報を表示するには、SHOW CONFIGURATIONコマンドを使用します。

コマンドの例

次の例では、BystandersFollowChangeプロパティをリセットする方法を示します。

DGMGRL> EDIT CONFIGURATION RESET PROPERTY BystandersFollowChange;
Succeeded.

7.17 EDIT DATABASE (プロパティ)

ブローカにより指定したデータベースに対して使用される名前を変更します。

書式

EDIT DATABASE database-name SET PROPERTY property-name=value;

コマンド・パラメータ

database-name

プロパティ値を変更するデータベースの名前。

property-name

データベース固有の既存のプロパティの名前。これがOracle RACデータベースの場合、このプロパティを変更するとデータベースのインスタンスすべてに影響します。

参照:

プロパティの詳細は、「ブローカ構成のメンバーの管理」および「Oracle Data Guard Brokerのプロパティ」を参照。

value

新しいプロパティ値。

注意:

このコマンドを使用してインスタンス固有のプロパティの値を変更できるのは、指定したデータベースに関してブローカでインスタンスが1つしか認識されていない場合のみです。ブローカでデータベースのインスタンスが複数認識されている場合は、このコマンドを使用してインスタンス固有のプロパティを変更しようとしても拒否されます。インスタンス固有のプロパティの値の変更には、EDIT INSTANCE(プロパティ)のみを使用することをお薦めします。

コマンドの例

例1: データベース・レベルの構成可能なプロパティの編集

データベース・レベルの構成可能なプロパティを編集します。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'ArchiveLagTarget'=1200;
Property "ArchiveLagTarget" updated

例2: 非Oracle RACデータベースの構成可能なインスタンス固有のプロパティの編集

非Oracle RACデータベースの構成可能なインスタンス固有のプロパティを編集します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY
> 'StandbyArchiveLocation'='/archfs/arch/';
Property "StandbyArchiveLocation" updated

例3: Oracle RACデータベースの構成可能なインスタンス固有のプロパティの編集

Oracle RACデータベースの構成可能なインスタンス固有のプロパティを編集します。プロパティの変更が適用されるインスタンスが明らかでないため、このコマンドは失敗します。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY
> 'StandbyArchiveLocation'='/archfs/arch/';
Error: ORA-16587: ambiguous object specified to Data Guard broker Failed.

7.18 EDIT DATABASE (名前の変更)

ブローカにより指定したデータベースの参照に使用される名前を変更します。

書式

EDIT DATABASE database-name RENAME TO new-database-name;

コマンド・パラメータ

database-name

変更するデータベース名。

new-database-name

データベースの新しい名前。

使用上の注意

- このコマンドを使用して、このデータベースのDB_UNIQUE_NAME初期化パラメータの変更を追跡します。

注意:

database-nameは、そのデータベースのDB_UNIQUE_NAME初期化パラメータの値と常に一致する必要があります。

- このコマンドを実行できるのは、名前を変更するデータベースのブローカ管理が無効化されている場合のみです。

コマンドの例

次の例に、データベースを編集して名前を変更する方法を示します。

DGMGRL> DISABLE DATABASE 'South_Sales_typo';
Disabled.

DGMGRL> EDIT DATABASE 'South_Sales_typo' RENAME TO 'South_Sales';
Succeeded.

DGMGRL> ENABLE DATABASE 'South_Sales';
Enabled.

7.19 EDIT DATABASE(状態)

指定したデータベースの状態を変更します。

書式

EDIT DATABASE database-name SET STATE=state [WITH APPLY INSTANCE=instance-name];

コマンド・パラメータ

database-name

状態を変更するデータベースの名前。

state

データベースを実行する状態。可能な状態は次のとおりです。

- TRANSPORT-ON (プライマリ・データベースのみ)

- TRANSPORT-OFF (プライマリ・データベースのみ)

- APPLY-ON (フィジカルまたはロジカル・スタンバイ・データベースのみ)

- APPLY-OFF (フィジカルまたはロジカル・スタンバイ・データベースのみ)

instance-name

Oracle RACスタンバイ・データベースの場合に、適用インスタンスにするインスタンスの名前。

使用上の注意

- ターゲットの状態がAPPLY-ONで、このデータベースが現在フィジカルまたはロジカル・スタンバイ・データベースである場合は、オプションのWITH APPLY INSTANCE句で適用インスタンスを指定します。

- ターゲットの状態がAPPLY-ONではない場合、またはデータベースが現在プライマリ・ロールになっている場合は、WITH APPLY INSTANCE句を指定しても無視されます。

- スナップショット・スタンバイ・データベースの状態は変更できません。

- このデータベースの状態変更は、Oracle RACデータベースのすべてのインスタンスに影響します。

コマンドの例

次の各例に、データベースの状態を変更する方法を示します。

DGMGRL> EDIT DATABASE 'South_Sales' SET STATE='APPLY-ON';
Succeeded.

7.20 EDIT DATABASE RESET (プロパティ)

指定されたデータベースの指定されたプロパティをそのデフォルト値にリセットしなおします。

書式

EDIT DATABASE database-name RESET PROPERTY property-name;

コマンド・パラメータ

database-name

プロパティ値をデフォルトにリセットするデータベースの名前。

property-name

データベース固有の既存の構成可能なプロパティの名前。

コマンドの例

次の例は、South_Salesという名前のデータベースのNetTimeoutプロパティをリセットする方法を示しています。

DGMGRL> EDIT DATABASE 'South_Sales' RESET PROPERTY NetTimeout;
Succeeded.

7.21 EDIT FAR_SYNC

遠隔同期インスタンスの名前またはプロパティを変更します。

書式

EDIT FAR_SYNC far_sync_instance_name  RENAME TO new_far_sync_instance_name;

EDIT FAR_SYNC far_sync_instance_name SET PROPERTY property_name = value;

コマンド・パラメータ

far_sync_instance_name

情報を編集する遠隔同期インスタンスの名前。この名前は、対応するデータベースのDB_UNIQUE_NAME初期化パラメータの値と一致する(大/小文字は区別されません)必要があります。

new_far_sync_instance_name

遠隔同期インスタンスの新しい名前。

property_name

遠隔同期インスタンス固有の既存の構成可能なプロパティの名前。

コマンドの例

次の例は、chicagoという名前の遠隔同期インスタンスの名前をdallasに変更します。

DGMGRL> DISABLE FAR_SYNC 'chicago_typo';EDIT FAR_SYNC 'chicago_typo' RENAME TO 'chicago';ENABLE FAR_SYNC 'chicago;

7.22 EDIT FAR_SYNC RESET (プロパティ)

指定された遠隔同期インスタンスの指定されたプロパティをそのデフォルト値にリセットします。

書式

EDIT FAR_SYNC far_sync_instance_name RESET PROPERTY property-name;

コマンド・パラメータ

far_sync_instance_name

情報を編集する遠隔同期インスタンスの名前。この名前は、対応するデータベースのDB_UNIQUE_NAME初期化パラメータの値と一致する(大/小文字は区別されません)必要があります。

property_name

デフォルト値にリセットするプロパティの名前。

コマンドの例

次の例は、dallasという名前の遠隔同期インスタンスのReopenSecsプロパティをデフォルト値にリセットする方法を示しています。

DGMGRL> EDIT FAR_SYNC 'dallas' RESET PROPERTY ReopenSecs;

7.23 EDIT INSTANCE (AUTO PFILE)

指定したインスタンスの初期化パラメータ・ファイル名を設定します。

書式

EDIT INSTANCE instance-name

[ON DATABASE database-name]    SET AUTO PFILE [= { initialization-file | OFF } ];

コマンド・パラメータ

instance-name

初期化パラメータ・ファイルを指定するインスタンスの名前(SID)。

database-name

instance-nameが関連付けられているデータベースの名前。

initialization-file

後続のブローカ操作でインスタンスを自動的に起動する必要がある場合は、そのインスタンスの起動操作を実行します。SET AUTO PFILEをOFFに設定すると、そのインスタンスの自動再起動は無効化されます。そのインスタンスを後続の操作で起動する必要がある場合は、手動で起動する必要があります。インスタンスに対してSET AUTO PFILEを指定しない場合、自動起動操作では初期化パラメータ・ファイルがデフォルト位置で検索されます。

使用上の注意

- instance-nameには、構成全体で一意の名前を指定できます。instance-nameが一意ではない場合、database-nameおよびinstance-nameの両方を指定してインスタンスを完全に識別する必要があります。

- SET AUTO PFILEは、現行のDGMGRLセッションの存続期間中にのみ有効です。DGMGRLを終了して再起動した場合は、SET AUTO PFILEを再指定する必要があります。

コマンドの例

次の例に、データベースのインスタンスの起動に使用するパラメータ・ファイルを変更する方法を示します。

DGMGRL> EDIT INSTANCE 'south_sales1' ON DATABASE 'South_Sales'
> SET AUTO PFILE='initsales1.ora';
Instance 'south_sales1' updated

7.24 EDIT INSTANCE (プロパティ)

指定したインスタンスのインスタンス固有のプロパティ値を変更します。

書式

EDIT INSTANCE     { {instance-name [ON {DATABASE database-name | FAR_SYNC far-sync-name}] } |      {*  ON {DATABASE database-name | FAR_SYNC far-sync-name} }  }

SET PROPERTY property-name=value;

コマンド・パラメータ

instance-name

インスタンス固有のプロパティ値を変更するインスタンスの名前(SID)。インスタンス名にアスタリスクが指定されている場合、ON DATABASE句またはON FAR_SYNC句も指定し、この変更をそのデータベースまたは遠隔同期に関連する各インスタンスの指定プロパティに適用する必要があります。このコマンドを使用して変更できるインスタンス固有プロパティについては、「Oracle Data Guard Brokerのプロパティ」を参照してください。

database-name

instance-nameが関連付けられているデータベースの名前。instance-nameにアスタリスクが付けられている場合、または構成内でinstance-nameが一意でない場合は、このパラメータを指定する必要があります

far-sync-name

instance-nameが関連付けられている遠隔同期の名前。

遠隔同期を指定するオプションは、Oracle Database 12cリリース1 (12.1.0.2)以上でのみ使用可能です。

property-name

新しい値を設定するインスタンス固有のプロパティの名前。

参照:

プロパティの詳細は、「ブローカ構成のメンバーの管理」および「Oracle Data Guard Brokerのプロパティ」を参照。

value

新しいプロパティ値。

使用上の注意

- instance-nameには、構成全体で一意の名前を指定できます。instance-nameが一意ではない場合、database-name (またはfar-sync-name)とinstance-nameの両方を指定してインスタンスを完全に識別する必要があります。

- このコマンドは、データベース固有のプロパティの変更には使用できません。

コマンドの例

例1: インスタンス固有のプロパティの編集

インスタンス固有のプロパティを編集します。

DGMGRL> EDIT INSTANCE 'north_sales1' ON DATABASE 'North_Sales'
> SET PROPERTY 'StandbyArchiveLocation'='/archfs/arch/';
Property "StandbyArchiveLocation" updated.

例2: データベース固有のプロパティの編集

データベース固有のプロパティを編集します。この操作は許可されません。

DGMGRL> EDIT INSTANCE 'north_sales1' ON DATABASE 'North_Sales'
> SET PROPERTY 'LogXptMode'='SYNC';
Error: ORA-16586: cannot change database property with EDIT INSTANCE command

Failed.

例3: Oracle RACデータベースのすべてのインスタンスのインスタンス固有のプロパティの変更

Oracle RACデータベースのすべてのインスタンスのインスタンス固有のプロパティを変更します。

DGMGRL> EDIT INSTANCE * ON DATABASE 'North_Sales'
> SET PROPERTY LogArchiveTrace=4095;

例4: Oracle RAC遠隔同期のすべてのインスタンスのインスタンス固有プロパティの変更

Oracle RAC遠隔同期インスタンスのすべてのインスタンスのインスタンス固有プロパティの値を変更します。

DGMGRL> EDIT INSTANCE * ON FAR_SYNC 'dallas' SET PROPERTY LogArchiveTrace=4095;

7.25 EDIT INSTANCE RESET (プロパティ)

指定されたインスタンスのインスタンス固有のプロパティを、そのデフォルト値にリセットします。

書式

EDIT INSTANCE  { {instance-name [ON {DATABASE database-name | FAR_SYNC far-sync-name}] }  |  {* ON {DATABASE database-name | FAR_SYNC far-sync-name} } }  RESET PROPERTY property-name;

コマンド・パラメータ

instance-name

インスタンス固有のプロパティ値をデフォルトにリセットするインスタンスの名前(SID)。インスタンス名にアスタリスクが付いている場合、ON DATABASE句も指定する必要があります。このプロパティはそのデータベースに関連する各インスタンスのデフォルトにリセットされます。

database-name

instance-nameが関連付けられているデータベースの名前。instance-nameにアスタリスクが付けられている場合、または構成内でinstance-nameが一意でない場合は、このパラメータを指定する必要があります。

property-name

デフォルト値にリセットするインスタンス固有のプロパティの名前。

参照:

プロパティの詳細は、「ブローカ構成のメンバーの管理」および「Oracle Data Guard Brokerのプロパティ」を参照。

value

新しいプロパティ値。

使用上の注意

- instance-nameには、構成全体で一意の名前を指定できます。instance-nameが一意ではない場合、database-nameおよびinstance-nameの両方を指定してインスタンスを完全に識別する必要があります。

- このコマンドは、データベース固有のプロパティの変更には使用できません。

コマンドの例

例1: 特定のインスタンスのプロパティのリセット

次のコマンドは、South_Salesという名前のデータベース上の、固有のインスタンスsouth1について、LogArchiveTraceプロパティをリセットする方法を表示します。

DGMGRL> EDIT INSTANCE 'south1' ON DATABASE 'South_Sales'
> RESET PROPERTY LogArchiveTrace;
Succeeded.

例2: データベースのすべてのインスタンスのプロパティのリセット

次の例は、South_Salesという名前のデータベースのすべてのインスタンスについてLogArchiveTraceプロパティをリセットする方法を、示しています。

DGMGRL> EDIT INSTANCE * ON DATABASE 'South_Sales' RESET PROPERTY LogArchiveTrace;
Succeeded.

7.26 ENABLE CONFIGURATION

すべてのデータベースを含むブローカ構成をブローカでアクティブに管理できるようにします。

書式

ENABLE CONFIGURATION

コマンド・パラメータ

なし。

使用上の注意

- このコマンドを使用して、プライマリ・データベースのブローカ管理と構成のすべてのメンバーを有効にします(これらのメンバーが明示的に無効にされていない場合)。

- このコマンドを発行するには、制御ファイルのロールがプライマリであるデータベースに接続する必要があります。

- デフォルトでは、構成のデータベースのブローカ管理は、プライマリ・データベースではTRANSPORT-ON状態で有効化され、REDO転送サービスがオンになり、スタンバイ・データベースではAPPLY-ON状態で有効化され、ログ適用サービスが起動します。遠隔同期インスタンスは、REDOデータを受け取り、REDOデータを送信するように有効化されます。EDIT DATABASE(状態)コマンドを使用して任意のデータベースの状態を変更できますが、対象のデータベースまたは構成全体が無効になっている場合は変更できません。遠隔同期インスタンスの状態は変更できません。

- 構成に関する情報を表示するには、SHOW CONFIGURATIONコマンドを使用します。

- フェイルオーバーまたはスイッチオーバーがDGMGRLやCloud ControlでなくSQL*Plusを使用して実行された場合、このコマンドを使用して、ブローカ構成に格納されているロールを更新します。

コマンドの例

次の例では、ブローカ構成の管理を有効化しています。

DGMGRL> ENABLE CONFIGURATION;
Enabled.

7.27 ENABLE DATABASE

指定したスタンバイ・データベースのブローカ管理を有効化します。

注意:

回復する必要があるスタンバイ・データベースでENABLE DATABASEコマンドを発行しないでください。詳細は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

書式

ENABLE DATABASE database-name;

コマンド・パラメータ

database-name

ブローカ管理を有効化するスタンバイ・データベースの名前。

使用上の注意

- このコマンドを発行するには、プライマリ・データベースまたはすでに有効化されたスタンバイ・データベースに接続する必要があります。

- 前のフェイルオーバー操作またはスイッチオーバー操作の結果、ブローカによりスタンバイ・データベースが無効化されている場合があります。データベースを回復または再作成する方法を理解するには、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

- デフォルトでは、フィジカルまたはロジカル・スタンバイ・データベースのブローカ管理はAPPLY-ON状態で有効化され、ログ適用サービスが有効化されます。データベースが有効になっている場合にのみ、EDIT DATABASE(状態)コマンドを使用してスタンバイ・データベースの状態を変更できます。

- 構成に関する情報を表示するには、SHOW DATABASEコマンドを使用します。

- Oracle RACデータベースの場合は、インスタンスを1つ起動してマウントすれば、このコマンドが正常に実行されます。

コマンドの例

次の例に、データベースSouth_Salesを有効化する方法を示します。

DGMGRL> ENABLE DATABASE 'South_Sales';
Enabled.

7.28 ENABLE FAR_SYNC

指定した遠隔同期インスタンスのブローカ管理を有効化します。

書式

ENABLE FAR_SYNC far_sync_instance_name ;

コマンド・パラメータ

far_sync_instance_name

ブローカ管理を有効化する遠隔同期インスタンスの名前。

コマンドの例

次の例は、dallasという名前の遠隔同期インスタンスのブローカ管理を有効にします。

DGMGRL> ENABLE FAR_SYNC 'dallas';

7.29 ENABLE FAST_START FAILOVER

プライマリ・データベースが消失した場合、ブローカによる、具体的に選択されたスタンバイ・データベースへのフェイルオーバーが可能になり、フェイルオーバーを起動するために手動による手順を実行する必要がありません。詳細は、「ファスト・スタート・フェイルオーバーの有効化」を参照してください。

書式

ENABLE FAST_START FAILOVER;

コマンド・パラメータ

なし。

使用上の注意

- このコマンドを発行してファスト・スタート・フェイルオーバーを有効化する前に、「ファスト・スタート・フェイルオーバーを有効化するための前提条件」で説明する前提条件を満たす必要があります。

- ENABLE FAST_START FAILOVERコマンドの発行により、フェイルオーバーが起動されることはありません。構成を監視しているオブザーバが、フェイルオーバーの条件が満たされた場合に、ファスト・スタート・フェイルオーバーを開始できるようにするだけです。

- ブローカ構成のデータベースに接続されている間は、ファスト・スタート・フェイルオーバーを有効化できます。

- ファスト・スタート・フェイルオーバーを有効化した後にオブザーバを開始しない場合、プライマリ・データベースとターゲットのスタンバイ・データベースにORA-16819の警告が表示されます。次に例を示します。

DGMGRL> SHOW DATABASE 'South_Sales';
Database - South_Sales

Role:            PRIMARY
Intended State:  TRANSPORT-ON
Instance(s):
south_sales1

Database Warning(s):
ORA-16819: fast-start failover observer not started

Database Status:
WARNING

- 複数のスタンバイ・データベースを含むブローカ構成でファスト・スタート・フェイルオーバーを有効化する場合は、目的のターゲット・スタンバイ・データベースを指すようにFastStartFailoverTarget構成プロパティをプライマリ・データベース上で設定する必要があります。プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方が次の条件を満たしている必要があります。

- スタンバイREDOログが構成されていること

- REDO転送が、両方のデータベース上で、構成された保護モードに正しく構成されていること

- プライマリ・データベースとスタンバイ・データベースの両方で「データベースをフラッシュバック」が有効化されていること

FastStartFailoverTarget構成プロパティの詳細は、「ファスト・スタート・フェイルオーバーの有効化」のタスク2および「FastStartFailoverTarget」を参照してください。

- ファスト・スタート・フェイルオーバーを有効化した後は、「ファスト・スタート・フェイルオーバーが有効化されている場合の制限事項」の説明にある制約に従う必要があります。

コマンドの例

例1: ファスト・スタート・フェイルオーバーの有効化

次の例では、ファスト・スタート・フェイルオーバーを有効化しています。

DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.

例2: ファスト・スタート・フェイルオーバーの有効化の成功例

次の例では、最大パフォーマンス・モードで動作している構成で、ファスト・スタート・フェイルオーバーが正常に有効化されました。

DGMGRL> SHOW FAST_START FAILOVER;

Fast-Start Failover: ENABLED

Threshold: 30 seconds
Target: South_Sales
Observer: (none)
Lag Limit: 30 seconds
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Observer Reconnect: (none)
Observer Override: FALSE

Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES

Oracle Error Conditions:
(none)

7.30 ENABLE FAST_START FAILOVER CONDITION

ファスト・スタート・フェイルオーバーを実行する追加条件を指定します。

書式

ENABLE FAST_START FAILOVER CONDITION value;

コマンド・パラメータ

value

可能な値は、SHOW FAST_START FAILOVERコマンドで健全性条件として示される値です。240の値を指定することにより、OracleエラーORA-00240を条件として指定することもできます。

使用上の注意

- 表7-2に、データベース健全性チェック機能によって管理される健全性条件の例を示します。

- 指定された値が認識されていないか、条件がすでに設定されている場合、エラーは発生しません。

- 表7-2 健全性条件の例

健全性条件

説明

データファイル・オフライン

書込みエラーによってデータファイルがオフラインになりました。この条件はデフォルトで有効になっています。

破損した制御ファイル

制御ファイルが破損しました。この条件はデフォルトで有効になっています。

破損したディクショナリ

重要なデータベース・オブジェクトのディクショナリが破損しました。この条件はデフォルトで有効になっています。

アクセス不可能なログ・ファイル

I/Oエラーにより、LGWRがログ・グループのどのメンバーにも書き込むことができません。

スタック・アーカイバ

デバイスに空き容量がないかデバイスを使用できないためにアーカイバがREDOログをアーカイブできません。

- SHOW FAST_START FAILOVERコマンドでこれらの構成可能な条件を表示できます。

コマンドの例

例1

次の例では、破損した制御ファイルが検出された場合、ファスト・スタート・フェイルオーバーを実行するように指定します。

ENABLE FAST_START FAILOVER CONDITION "Corrupted Controlfile";

例2

次の例では、ORA-00240エラーが発生した場合、ファスト・スタート・フェイルオーバーを実行するように指定します。

ENABLE FAST_START FAILOVER CONDITION 240;

7.31 EXIT

コマンドライン・インタフェースを終了します。

書式

EXIT;

コマンド・パラメータ

なし。

使用上の注意

- このコマンドの効果は、QUITコマンドと同じです。

- このコマンドの実行には、データベース接続は不要です。ただし、接続されている場合は、このコマンドにより接続が解除されます。

コマンドの例

次の例に、コマンドライン・インタフェースを終了する方法を示します。

DGMGRL> EXIT;

7.32 FAILOVER

指定したターゲットのスタンバイ・データベースをプライマリ・データベースのロールに遷移するフェイルオーバーを開始します。 このタイプのフェイルオーバーを、手動フェイルオーバーと呼びます。詳細は、「手動フェイルオーバー」を参照してください。

注意:

フェイルオーバーを実行すると、スタンバイ・データベースがプライマリ・データベースのロールに遷移するため、フェイルオーバーは、プライマリ・データベースに障害が発生するか使用不可になり、適時にリカバリできない場合に実行してください。フェイルオーバーの結果、実行時に有効になっている保護モード、およびターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていたかどうかによっては、データが消失する場合があります。

プライマリ・データベースに障害がなく、データの消失なしに現在のプライマリ・データベースとスタンバイ・データベースのロールを切り替えるには、SWITCHOVERコマンドを使用します。

書式

FAILOVER TO database-name

[ IMMEDIATE ];

コマンド・パラメータ

database-name

プライマリ・データベース・ロールへのフェイルオーバーの対象となるフィジカル、ロジカルまたはスナップショット・スタンバイ・データベースの名前。

使用上の注意

- ORA-752またはORA-600 [3020] エラーにより、フェイルオーバー・ターゲットでREDO Applyが停止されていないかぎり、常に完全フェイルオーバーを最初に実行するようにします。これらのエラーのいずれかが発生した場合は、先に進む前に、My Oracle Supportノート1265884.1 (http://support.oracle.com)のスタンバイ・リカバリ時のORA-752またはORA-600 [3020]の解決のガイドラインに従います。即時フェイルオーバーは、完全フェイルオーバーが失敗するか、前述のエラーの場合にのみ実行してください。

- 指定したスタンバイ・データベースは、プライマリ・データベースに障害が発生する前に有効化されている必要があります。ただし、有効化されているスタンバイ・データベースが停止している場合は、フェイルオーバー操作の候補とみなすことができます。この場合は、DGMGRLのSTARTUPコマンドを使用してスタンバイ・データベースを再起動してからFAILOVERコマンドを発行します。

- フェイルオーバーは、指定したスタンバイ・データベースに対して動作し、スタンバイ・データベースのロールがプライマリ・データベースのロールに変更されます。フェイルオーバーに関係しないその他のスタンバイ・データベースは、スタンバイ・ロールのままです。

- FAILOVERコマンドを発行する前に、新しいプライマリ・データベースになるスタンバイ・データベースに接続していることを確認します。必要な場合は、CONNECTコマンドを発行してフェイルオーバーするスタンバイ・データベースに接続します。

- オプションを指定せずにFAILOVERコマンドを発行すると、フェイルオーバー・ターゲットとして選択したスタンバイ・データベースにより、プライマリ・ロールへの変更前に受信した未適用のREDOがすべて適用されます。これを完全フェイルオーバーと呼びます。

- ブローカ構成が最大保護モードで動作している場合、手動フェイルオーバー操作を実行すると、保護モードが強制的に最大パフォーマンスに設定されます。REDO転送サービスの設定は影響を受けません。フェイルオーバー操作後に、構成に必要な保護モードをリストアする必要があります。

注意:

ファスト・スタート・フェイルオーバーの場合は、ブローカにより、フェイルオーバー前に有効になっていた保護モードが維持されます。ファスト・スタート・フェイルオーバーが有効化されている場合、ブローカ構成を最大保護モードにすることはできません。

- IMMEDIATEオプションを指定してFAILOVERコマンドを発行すると、受け取った未適用のREDOの適用は試行されません。このオプションを指定すると、スタンバイ・データベースでスタンバイREDOログ・ファイルが構成されている場合でも、アプリケーション・データが消失する可能性があります。また、構成内の他のスタンバイ・データベースは、回復または再作成されるまで機能しません。詳細は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

- 手動フェイルオーバーを実行するか、ブローカをファスト・スタート・フェイルオーバーを実行するように設定できます。フェイルオーバーの条件が満たされた場合に、ブローカにより自動的にフェイルオーバーを起動させる方法については、ENABLE FAST_START FAILOVERコマンドを参照してください。

- ファスト・スタート・フェイルオーバーが有効になっている場合は、完全手動フェイルオーバーを、ファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースに対してのみ、そのスタンバイ・データベースがプライマリ・データベースと同期化されているかプライマリ・データベースのラグ制限内である場合にのみ、およびオブザーバーが開始されている場合にのみ実行できます。ファスト・スタート・フェイルオーバーが有効になっている場合に、即時手動フェイルオーバーは実行できません。

- 障害が発生した元のプライマリ・データベース上で、フェイルオーバーの前に「データベースをフラッシュバック」が有効化されていた場合は、ブローカのREINSTATEコマンド(REINSTATE DATABASEコマンドを参照)を使用して、そのプライマリ・データベースを回復できます。
フィジカル・スタンバイ・データベースに対してフェイルオーバーが実行された場合は、そのスタンバイ・データベースで「データベースをフラッシュバック」が有効化されていて、使用可能なフラッシュバック・ログ情報が不足なくある場合にのみ、そのフェイルオーバーにより無効化されたその他のフィジカル・スタンバイ・データベースも回復できます。手順については、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

- 元のプライマリ・データベースは、回復または再作成後、スタンバイ・データベースとしてのみ構成に関係できます。

注意:

フェイルオーバー前にまだアクティブなインスタンスが実行されている場合は、元のプライマリ・データベースを停止してください。

参照:

プライマリ・データベースのスタンバイ・データベースとして機能するように、元のプライマリ・データベースを再有効化する方法については、「ロール変更後の無効化されたデータベースの再有効化」を参照してください

コマンドの例

次の例では、スタンバイ・データベースSouth_Salesがプライマリ・ロールに遷移するフェイルオーバーを実行しています。

DGMGRL> FAILOVER TO 'South_Sales';
Performing failover NOW, please wait...
Failover succeeded, new primary is "South_Sales"

DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
South_Sales - Primary database
North_Sales - Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated

Fast-Start Failover: DISABLED

Configuration Status:
WARNING

7.33 HELP

Data Guardコマンドライン・インタフェースのオンライン・ヘルプを表示します。

書式

HELP [command_name];

コマンド・パラメータ

command_name

ヘルプ情報を表示するコマンド。コマンドを指定しない場合は、すべてのコマンドがリストされます。次のコマンドを使用できます。

add  Adds a standby database to the broker configuration
connect  Connects to an Oracle database instance
convert  Converts a database from one type to another
create  Creates a broker configuration
disable  Disables a configuration, a database, or fast-start failover
edit  Edits a configuration, database, or instance
enable  Enables a configuration, a database, or fast-start failover
exit  Exits the program
failover  Changes a standby database to be the primary database
help  Displays description and syntax for a command
quit  Exits the program
reinstate  Changes a database marked for reinstatement into a viable standby
rem  Comment to be ignored by DGMGRL
remove  Removes a configuration, database, or instance
show  Displays information about a configuration, database, or instance
shutdown  Shuts down a currently running Oracle database instance
sql  Executes a SQL statement
start  Starts the fast-start failover observer
startup S tarts an Oracle database instance
stop  Stops the fast-start failover observer
switchover  Switches roles between a primary and standby database
validate  Performs an exhaustive set of validations for a database

個々のコマンドの構文を参照するには、help command_nameと入力します。

使用上の注意

- このコマンドの実行には、データベース接続は不要です。

コマンドの例

次の例では、EDITコマンドのヘルプを取得しています。

DGMGRL> HELP EDIT

7.34 QUIT

Data Guardコマンドライン・インタフェースを終了します。

書式

QUIT

コマンド・パラメータ

なし。

使用上の注意

- このコマンドの効果は、EXITコマンドと同じです。

- このコマンドの実行には、データベース接続は不要です。ただし、接続されている場合は、このコマンドにより接続が解除されます。

コマンドの例

次の例に、コマンドライン・インタフェースを終了する方法を示します。

DGMGRL> QUIT;

7.35 REINSTATE DATABASE

ブローカ構成内で、データベースを現在のプライマリ・データベースの新規スタンバイ・データベースとして回復します。

書式

REINSTATE DATABASE database-name;

コマンド・パラメータ

database-name

ブローカ構成内の回復するデータベースの名前

使用上の注意

- 「ブローカ構成に含まれる元のプライマリ・データベースの回復」で説明する回復の条件が満たされていない場合、回復処理は失敗し、対応するエラー・ステータスが表示され、指定されたデータベースは無効なままになります。

- database-nameに、元のプライマリの名前が指定され、ファスト・スタート・フェイルオーバーが有効化されている場合、元のプライマリ・データベースは、新規プライマリ・データベースのスタンバイとして回復し、ファスト・スタート・フェイルオーバー環境は、新規スタンバイ・データベースの可用性を反映して更新されます。新規スタンバイ・データベースは、新規プライマリ・データベースに障害が発生した場合、新規プライマリ・データベースからREDOデータを受け取り、ファスト・スタート・フェイルオーバーのターゲットとなります。FastStartFailoverAutoReinstate構成プロパティがFALSEに設定されている場合を除き、オブザーバが実行中であれば自動的に回復が実行されます。

- このコマンドでは、ファスト・スタート・フェイルオーバーが有効化されている必要はありません。このコマンドは、完全手動フェイルオーバーが実行された後、元のプライマリ・データベースを回復する場合に使用できます。完全または即時フェイルオーバー後に無効化されたその他のスタンバイ・データベースを回復するために使用することもできます。

- このコマンドは、ブローカ構成内で回復させるデータベース以外のデータベースに接続されている場合に発行します。

コマンドの例

次の例に、North_Salesデータベースを、ブローカ構成のスタンバイ・データベースとして回復させる方法を示します。

DGMGRL> REINSTATE DATABASE 'North_Sales';
Reinstating database "North_Sales", please wait...
Reinstatement of database "North_Sales" succeeded

7.36 REMOVE CONFIGURATION

Oracle Data Guard Broker構成を削除し、構成内のすべてのメンバーのブローカ管理を終了します。

書式

REMOVE CONFIGURATION [ PRESERVE DESTINATIONS ];

コマンド・パラメータ

なし。

使用上の注意

- ブローカ構成を削除すると、その構成に関連付けられているすべてのメンバーの管理が無効化されます。

- デフォルトでは、このコマンドを実行すると、プライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータと構成内の全メンバーのLOG_ARCHIVE_CONFIG初期化パラメータから、対応するブローカ設定が削除されます。これらの設定を保持するには、PRESERVE DESTINATIONSオプションを使用します。

- このコマンドでは、基礎となるOracle Data Guard構成の実際のプライマリまたはスタンバイ・データベース・インスタンス、データベース、遠隔同期インスタンス、データ・ファイル、制御ファイル、初期化パラメータ・ファイル、サーバー・パラメータ・ファイルまたはログ・ファイルは削除されず、影響を受けません。

- ファスト・スタート・フェイルオーバーが有効化されている場合は、その構成を削除できません。

コマンドの例

次の例では、REMOVE CONFIGURATIONコマンドの成功例と失敗例を示します。

例1

次のコマンドは、構成ファイルから構成情報を削除する方法を示します。

DGMGRL> REMOVE CONFIGURATION;
Removed configuration
DGMGRL> SHOW CONFIGURATION;
Error: ORA-16532: Data Guard broker configuration does not exist

Configuration details cannot be determined by DGMGRL

例2

次のコマンドは、ファスト・スタート・フェイルオーバーが有効になっているために失敗しています。

DGMGRL> REMOVE CONFIGURATION;
Error: ORA-16654: fast-start failover is enabled

Failed.

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
North_Sales  - Primary database
South_Sales  - (*) Physical standby database

Fast-Start Failover: ENABLED

Configuration status:
SUCCESS

7.37 REMOVE DATABASE

指定したスタンバイ・データベースをブローカ構成から削除し、そのスタンバイ・データベースのブローカ管理を終了します。

書式

REMOVE DATABASE database-name [ PRESERVE DESTINATIONS ];

コマンド・パラメータ

database-name

ブローカ構成から削除するスタンバイ・データベースの名前。

使用上の注意

- ブローカ構成に含まれるプライマリ・データベースの名前を指定すると、エラーが戻されます。

- デフォルトで、このコマンドは、構成の各メンバーにおける、すべてのREDO転送初期化パラメータから、指定されたデータベースへのすべての参照を削除します。これらの設定を保持するには、PRESERVE DESTINATIONSオプションを使用します。

- このコマンドは、ファスト・スタート・フェイルオーバーが有効になっている場合は実行できません。また、database-nameには、ターゲットのスタンバイ・データベースの名前を指定します。

コマンドの例

次の例に、Oracle Data Guard Broker構成からデータベースを削除する方法を示します。

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
South_Sales  - Physical standby database

Fast-Start Failover: DISABLED

Configuration status:
SUCCESS

DGMGRL> REMOVE DATABASE 'South_Sales';
Removed database "South_Sales" from the configuration.

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database

Fast-Start Failover: DISABLED

Configuration status:
SUCCESS

7.38 REMOVE FAR_SYNC

既存の遠隔同期インスタンスをOracle Data Guard Broker構成から削除します。

書式

REMOVE FAR_SYNC far_sync_instance_name;

コマンド・パラメータ

far_sync_instance_name

ブローカ構成から削除する遠隔同期インスタンスの名前。この名前は、対応するデータベースのDB_UNIQUE_NAME初期化パラメータの値と一致する(大/小文字は区別されません)必要があります。

使用上の注意

- RedoRoutesプロパティが設定されている遠隔同期インスタンスは、削除できません。

コマンドの例

次の例は、dallasという名前の遠隔同期インスタンスをブローカ構成から削除します。

DGMGRL> REMOVE FAR_SYNC 'dallas';

7.39 REMOVE INSTANCE

指定したインスタンスをブローカ構成から削除します。

書式

REMOVE INSTANCE instance-name  [ON { DATABASE | FAR_SYNC } object-name];

コマンド・パラメータ

instance-name

ブローカ構成から削除するインスタンスの名前(SID)。

object-name

instance-nameが関連付けられているデータベースまたは遠隔同期の名前。遠隔同期を指定するオプションは、Oracle Database 12cリリース1 (12.1.0.2)以上でのみ使用可能です。

使用上の注意

- 開始されたインスタンスは、ブローカにより自動的にブローカ構成に追加されます。ただし、インスタンスはデータベース・プロファイルから自動的に削除されません。REMOVE INSTANCEコマンドを使用すると、存在しなくなったインスタンスを構成から手動で削除できます。

- instance-nameが構成内で一意ではない場合、database-nameまたはfar sync-nameとinstance-nameの両方を指定してインスタンスを完全に識別する必要があります。

- ブローカ構成内で現在アクティブなインスタンスの場合は、このコマンドが拒否されます。

- 現在そのインスタンスのみがデータベースまたは遠隔同期に関連付けられている場合、このコマンドは拒否されます。

コマンドの例

次の例に、データベースのインスタンスを削除する方法を示します。

DGMGRL> REMOVE INSTANCE 'south_sales3' ON DATABASE 'South_Sales';
Removed instance "south_sales3" from the database "South_Sales"

7.40 SHOW CONFIGURATION

ブローカ構成のサマリーおよびステータスを表示します。サマリーには、ブローカ構成に含まれるすべてのメンバーと、ファスト・スタート・フェイルオーバーのステータスなど、ブローカ構成自体に関するその他の情報が表示されます。

書式

SHOW CONFIGURATION [VERBOSE | property-name];

コマンド・パラメータ

property-name

サマリー情報を表示するプロパティの名前。

プロパティの詳細は、「Oracle Data Guard Brokerのプロパティ」を参照してください。

使用上の注意

- ファスト・スタート・フェイルオーバーに関連するプロパティを表示するには、SHOW CONFIGURATION VERBOSEコマンド(またはSHOW FAST_START FAILOVERコマンド)を使用します。

- VERBOSEまたはproperty-nameのどちらかをオプションで指定できますが、両方指定することはできません。

- SHOW CONFIGURATIONコマンドを使用すると、最後に健全性が評価された時点での構成およびそのメンバーのステータスが表示されます。(構成およびそのメンバーの健全性は毎秒1回評価されます。)
VERBOSEキーワードを指定すると、健全性情報が表示される前に、構成およびそのメンバーの健全性評価が即時に実行されます。

コマンドの例

例1 DRSolution構成のサマリーの表示

次の例では、ファスト・スタート・フェイルオーバーが無効化されているDRSolution構成のサマリーを表示しています。出力に、ブローカ構成内のFSという名前の遠隔同期インスタンスが示されています。North_SalesデータベースはFSに、FSはSouth_Salesにデータを送信しています。

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxAvailability
Members:
North_Sales  - Primary database
FS- Far sync instance
South_Sales- Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 20 seconds ago)

例2 DRSolution構成の詳細な説明の表示

次の例では、DRSolution構成の詳細な情報を、構成プロパティ、ファスト・スタート・フェイルオーバー関連の情報を含めて表示しています。

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration - DRSolution

Protection Mode: MaxAvailability
Members:

North_Sales  - Primary database
FS- Far sync instance
South_Sales- (*) Physical standby database

(*) Fast-Start Failover target

Properties:
FastStartFailoverThreshold      = '30'
OperationTimeout                = '30'
TraceLevel                      = 'USER'
FastStartFailoverLagLimit       = '30'
CommunicationTimeout            = '180'
ObserverReconnect               = '0'
FastStartFailoverAutoReinstate  = 'TRUE'
FastStartFailoverPmyShutdown    = 'TRUE'
BystandersFollowRoleChange      = 'ALL'
ObserverOverride                = 'FALSE'
ExternalDestination1            = ''
ExternalDestination2            = ''
PrimaryLostWriteAction          = 'CONTINUE'

Fast-Start Failover: ENABLED

Threshold:          30 seconds
Target:             South_Sales
Observer:           observer.example.com
Lag Limit:          30 seconds (not in use)
Shutdown Primary:   TRUE
Auto-reinstate:     TRUE
Observer Reconnect: (none)
Observer Override:  FALSE

Configuration Status:
WARNING

7.41 SHOW CONFIGURATION WHEN PRIMARY IS

指定したデータベースがプライマリ・データベースであった場合に有効になるREDO転送構成を表示します。すべてのメンバーが表示されますが、SHOW CONFIGURATIONとは異なり、ステータス情報やその他の構成情報は表示されません。(このコマンドは、Oracle Database 12cリリース1 (12.1.0.2)以上で使用可能です。)

書式

SHOW CONFIGURATION WHEN PRIMARY IS database-name;

コマンド・パラメータ

database-name

このデータベース名がプライマリ・データベースであった場合にREDO転送構成がどうなるかを表示します。

使用上の注意

- SHOW CONFIGURATION WHEN PRIMARY ISコマンドを使用すると、指定したデータベースがプライマリ・データベースであった場合に有効になるREDO転送構成が表示されます。この情報を使用して、ロール変更の後に不適切になるREDO転送構成があれば事前に特定できます。

コマンドの例

次の例に、South_Salesデータベースに対するロール変更の前後のDRSolution構成のサマリーを示します。

DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

Protection Mode: MaxAvailability
Members:
North_Sales - Primary database
North_FS    - Far Sync
South_Sales - Physical standby database

Members Not Receiving Redo:
South_FS - Far Sync

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

DGMGRL> SHOW CONFIGURATION WHEN PRIMARY IS 'South_Sales';

Configuration when South_Sales is primary - DRSolution

Members:
South_Sales  - Primary database
South_FS     - Far Sync
North_Sales  - Physical standby database

Members Not Receiving Redo:
North_FS - Far Sync

これらの表示は、各メンバーに対して次のように設定されているRedoRoutesプロパティに基づいています。

DGMGRL> SHOW DATABASE 'North_Sales' RedoRoutes;
RedoRoutes = '(LOCAL : North_FS)'

DGMGRL> SHOW FAR_SYNC 'North_FS' RedoRoutes;
RedoRoutes = '(North_Sales : South_Sales)'

DGMGRL> SHOW DATABASE 'South_Sales' RedoRoutes;
RedoRoutes = '(LOCAL : South_FS)'

DGMGRL> SHOW FAR_SYNC 'South_FS' RedoRoutes;
RedoRoutes = '(South_Sales : North_Sales)'

7.42 SHOW DATABASE

指定したデータベースとそのインスタンスに関する情報またはプロパティ値を表示します。

書式

SHOW DATABASE [VERBOSE] database-name [property-name];

コマンド・パラメータ

database-name

情報を表示するデータベースの名前。VERBOSEキーワードを使用する場合は、database-nameの前に指定する必要があります。そうしないとエラーが戻ります。

property-name

値を表示するプロパティの名前。プロパティ名を指定すると、VERBOSEキーワードを指定したかどうかにかかわらず、出力には指定したプロパティのみ(データベースのすべてのプロパティではなく)が表示されます。

参照:

プロパティの詳細は、「ブローカ構成のメンバーの管理」および「Oracle Data Guard Brokerのプロパティ」を参照。

使用上の注意

- SHOW DATABASEコマンドを使用すると、データベースの簡潔なサマリーが表示されます。SHOW DATABASE VERBOSEコマンドを使用すると、簡潔なサマリーに加えてデータベースのプロパティが表示されます。データベースのステータスは、どちらのコマンドでも表示されます。

- SHOW DATABASE VERBOSEコマンドを使用すると、データベース固有のプロパティとインスタンス固有のプロパティが表示されます。非Oracle RACデータベースの場合、インスタンス固有のプロパティの値は、データベースの唯一のインスタンスの値です。Oracle RACデータベースの場合、プロパティ名は表示されますが、インスタンス固有のプロパティの値は表示されません。これらのプロパティについてインスタンス固有の値を表示するには、SHOW INSTANCEコマンドを使用します。

- SHOW DATABASE VERBOSEコマンドで表示されるプロパティは、データベース・ロールと構成の内容によって異なります。

- プライマリ・データベースの場合は、構成に少なくとも1つのフィジカルまたはスナップショット・スタンバイ・データベースが含まれている場合にのみ、フィジカルまたはスナップショット・スタンバイ・データベース固有のプロパティが表示されます。ロジカル・スタンバイ・データベース固有のプロパティは、構成に少なくとも1つロジカル・スタンバイ・データベースが含まれている場合にのみ表示されます。

- フィジカルおよびスナップショット・スタンバイ・データベースの場合、ロジカル・スタンバイ・データベース固有のプロパティは表示されません。

- ロジカル・スタンバイ・データベースの場合、フィジカルおよびスナップショット・スタンバイ・データベース固有のプロパティは表示されません。

- Oracle RACデータベースのインスタンス固有のプロパティを表示するためにSHOW DATABASE database-name property-nameコマンドを使用すると、このコマンドは拒否されます。

コマンドの例

例1: 簡略形式でのデータベース情報の表示

この例では、データベース情報を簡略形式で表示します。

DGMGRL> SHOW DATABASE South_Sales;

Database - South_Sales

Role:            PHYSICAL STANDBY
Intended State:  APPLY-ON
Transport Lag:   (unknown)
Apply Lag:       0 seconds (computed 0 seconds ago)
Apply Rate:      1.73 MByte/s
Real Time Query: OFF
Instance(s):
south_sales1

Database Status:
SUCCESS

例2: 拡張形式でのデータベース情報の表示

この例では、データベース情報を拡張形式で表示します。

DGMGRL> SHOW DATABASE VERBOSE 'South_Sales';

Database - South_Sales

Role:            PHYSICAL STANDBY
Intended State:  OFFLINE
Transport Lag:  (unknown)
Apply Lag:      (unknown)
Apply Rate:     (unknown)
Real Time Query: OFF
Instance(s):
south_sales1

Properties:
DGConnectIdentifier            = 'South_Sales.example.com'
ObserverConnectIdentifier      = ''
LogXptMode                     = 'ASYNC'
RedoRoutes                     = ''
DelayMins                      = '0'
Binding                        = 'optional'
MaxFailure                     = '0'
MaxConnections                 = '1'
ReopenSecs                     = '300'
NetTimeout                     = '30'
RedoCompression                = 'DISABLE'
LogShipping                    = 'ON'
PreferredApplyInstance         = ''
ApplyInstanceTimeout           = '0'
ApplyLagThreshold              = '0'
TransportLagThreshold          = '0'
TransportDisconnectedThreshold = '0'
ApplyParallel                  = 'AUTO'
StandbyFileManagement          = 'AUTO'
ArchiveLagTarget               = '0'
LogArchiveMaxProcesses         = '5'
LogArchiveMinSucceedDest       = '1'
DbFileNameConvert              = 'dbs/t, dbs/ct, dbs/bt, dbs/ct'
LogFileNameConvert             = 'dbs/t, dbs/ct, dbs/bt, dbs/ct'
FastStartFailoverTarget        = ''
InconsistentProperties         = '(monitor)'
InconsistentLogXptProps        = '(monitor)'
SendQEntries                   = '(monitor)'
LogXptStatus                   = '(monitor)'
RecvQEntries                   = '(monitor)'
StaticConnectIdentifier        = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
(HOST=south_     sales1.example.com)(PORT=2840))
(CONNECT_DATA=(SERVICE_NAME=South_Sales_DGMGRL.example.com)
(INSTANCE_NAME=south_sales1)(SERVER=DEDICATED)))'
StandbyArchiveLocation         = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation              = ''
LogArchiveTrace                = '255'
LogArchiveFormat               = 'db3r_%d_%t_%s_%R.arc'
TopWaitEvents                  = '(monitor)'

Database Status:
SUCCESS

7.43 SHOW FAR_SYNC

遠隔同期インスタンスに関する情報を表示します。

書式

SHOW FAR_SYNC [VERBOSE] far_sync_instance_name [property-name];

コマンド・パラメータ

far_sync_instance_name

ブローカが情報を表示する遠隔同期インスタンスの名前。この名前は、対応するデータベースのDB_UNIQUE_NAME初期化パラメータの値と一致する(大/小文字は区別されません)必要があります。

property-name

値を表示するプロパティの名前。プロパティ名を指定すると、VERBOSEキーワードを指定したかどうかにかかわらず、出力には(遠隔同期のすべてのプロパティではなく)指定したプロパティのみが表示されます。

参照:

プロパティの詳細は、「ブローカ構成のメンバーの管理」および「Oracle Data Guard Brokerのプロパティ」を参照。

コマンドの例

例1: SHOW FAR_SYNCの出力例(VERBOSEの指定なし)

次の例は、このコマンドからのサンプル出力を示しています。

DGMGRL> SHOW FAR_SYNC FS;

Far Sync - FS

Transport Lag: 0 seconds (computed 1 second ago)
Instance(s):
fs1

Far Sync Status:
SUCCESS

例2: SHOW FAR SYNCの出力例(VERBOSEの指定あり)

次の例は、VERBOSEオプションが使用された場合の、このコマンドからのサンプル出力を示しています。

DGMGRL> SHOW FAR_SYNC VERBOSE FS;

Far Sync - FS

Transport Lag: 0 seconds (computed 0 seconds ago)
Instance(s):
b02

Properties:
DGConnectIdentifier            = 'fs.example.com'
LogXptMode                     = 'sync'
RedoRoutes                     = '(North_Sales : South_Sales)
(South_Sales : North_Sales)'
Binding                        = 'optional'
MaxFailure                     = '0'
MaxConnections                 = '1'
ReopenSecs                     = '300'
NetTimeout                     = '30'
RedoCompression                = 'DISABLE'
LogShipping                    = 'ON'
TransportLagThreshold          = '0'
TransportDisconnectedThreshold = '0'
ArchiveLagTarget               = '0'
LogArchiveMaxProcesses         = '5'
LogArchiveMinSucceedDest       = '1'
InconsistentProperties         = '(monitor)'
InconsistentLogXptProps        = '(monitor)'
LogXptStatus                   = '(monitor)'
StaticConnectIdentifier        = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
(HOST=fs.example.com)(PORT=2202))
(CONNECT_DATA=(SERVICE_NAME=FS_DGMGRL.example.com)
(INSTANCE_NAME=fs1)(SERVER=DEDICATED)))'
StandbyArchiveLocation         = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation              = ''
LogArchiveTrace                = '255'
LogArchiveFormat               = 'db2r_%d_%t_%s_%R.arc'
TopWaitEvents                  = '(monitor)'

Far Sync Status:
SUCCESS

7.44 SHOW FAST_START FAILOVER

すべてのファスト・スタート・フェイルオーバー関連情報を表示します。

書式

SHOW FAST_START FAILOVER;

コマンド・パラメータ

なし。

使用上の注意

SHOW FAST_START FAILOVERコマンドは、ファスト・スタート・フェイルオーバー構成のサマリーを表示します。

コマンドの例

DGMGRL> SHOW FAST_START FAILOVER;

Fast-Start Failover: DISABLED

Threshold: 30 seconds
Target: (none)
Observer: (none)
Lag Limit: 30 seconds
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Observer Reconnect: (none)
Observer Override: FALSE

Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES

Oracle Error Conditions:
(none)

7.45 SHOW INSTANCE

指定したインスタンスの情報またはプロパティ値を表示します。

書式

SHOW INSTANCE [VERBOSE] instance-name [property-name]  [ON {DATABASE database-name | FAR_SYNC far-sync-name} ];

コマンド・パラメータ

instance-name

情報を表示するインスタンスの名前。VERBOSEキーワードを使用する場合は、インスタンス名の前に指定する必要があります。

property-name

値を表示するプロパティの名前。プロパティ名を指定すると、VERBOSEキーワードを指定したかどうかにかかわらず、出力には指定したプロパティのみ(すべてのプロパティではなく)が表示されます。

参照:

プロパティの詳細は、「ブローカ構成のメンバーの管理」および「Oracle Data Guard Brokerのプロパティ」を参照。

database-name | far-sync-name

情報を表示するインスタンスに関連付けられているデータベースまたは遠隔同期の名前。

使用上の注意

- SHOW INSTANCEコマンドを使用すると、インスタンスの簡潔なサマリーが表示されます。SHOW INSTANCE VERBOSEコマンドを使用すると、簡潔なサマリーに加えてインスタンスのプロパティが表示されます。インスタンスのステータスは、どちらのコマンドでも表示されます。

- SHOW INSTANCE VERBOSEコマンドでは、インスタンス固有のプロパティのみが表示されます。

- SHOW INSTANCE VERBOSEコマンドで表示されるプロパティは、データベース・ロールと構成の内容によって異なります。

- プライマリ・データベースのインスタンスの場合は、構成に少なくとも1つのフィジカルまたはスナップショット・スタンバイ・データベースが含まれている場合にのみ、フィジカルまたはスナップショット・スタンバイ・インスタンス固有のプロパティが表示されます。ロジカル・スタンバイ・インスタンス固有のプロパティは、構成に少なくとも1つロジカル・スタンバイ・データベースが含まれている場合にのみ表示されます。

- フィジカルまたはスナップショット・スタンバイ・データベースのインスタンスの場合、ロジカル・スタンバイ・インスタンス固有のプロパティは表示されません。

- ロジカル・スタンバイ・データベースのインスタンスの場合、フィジカルおよびスナップショット・スタンバイ・インスタンス固有のプロパティは表示されません。

- instance-nameには、構成全体で一意の名前を指定できます。instance-nameが一意ではない場合、database-nameおよびinstance-nameの両方を指定してインスタンスを完全に識別する必要があります。

コマンドの例

例1: 簡略形式でのインスタンス情報の表示

次の例では、データベースの特定のインスタンスに関する情報を表示します。

DGMGRL> SHOW INSTANCE 'north_sales1';

Instance 'north_sales1' of database 'North_Sales'

Instance Status:
SUCCESS

例2: 拡張形式でのインスタンス情報の表示

次の例では、インスタンス情報を拡張形式で表示します。

DGMGRL> SHOW INSTANCE VERBOSE 'north_sales1';

Instance 'north_sales1' of database 'North_Sales'

Host Name: north.example.com
PFILE:
Properties:
SidName                         = 'north_sales1'
StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
(HOST=north.example.com)(PORT=2094))
(CONNECT_DATA=(SERVICE_NAME=North_Sales_DGMGRL.example.com)
(INSTANCE_NAME=north_sales1)(SERVER=DEDICATED)))'
StandbyArchiveLocation          = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation               = ''
LogArchiveTrace                 = '255'
LogArchiveFormat                = 'r_%d_%t_%s_%R.arc'
LatestLog                       = '(monitor)'
TopWaitEvents                   = '(monitor)'

Instance Status:
SUCCESS

7.46 SHUTDOWN

現在実行中のOracleインスタンスを停止します。

書式

SHUTDOWN [ ABORT | IMMEDIATE | NORMAL ];

コマンド・パラメータ

なし。

使用上の注意

- 引数を指定せずにSHUTDOWNコマンドを使用すると、SHUTDOWN NORMALコマンドを使用した場合と同じ結果になります。

- SHUTDOWNコマンドのオプションを次に示します。

- ABORT
コールの完了やデータベースからのユーザーの切断を待たずに、データベースを可能なかぎり高速でシャットダウンします。コミットされていないトランザクションはロールバックされません。処理中のクライアントのSQL文は終了します。データベースに接続されているユーザー全員が暗黙的に切断され、次回のデータベース起動時にはインスタンスのリカバリが必要になります。バックグラウンド・プロセスが異常終了した場合は、このオプションを使用する必要があります。

注意:

ファスト・スタート・フェイルオーバーが有効化され、オブザーバが実行されている場合に、プライマリ・データベースにABORTオプションを使用すると、ファスト・スタート・フェイルオーバーが実行される場合があります。意図しないファスト・スタート・フェイルオーバーの実行を防ぐには、IMMEDIATEまたはNORMALオプションを使用します。

- IMMEDIATE
現在のコールが完了したり、ユーザーがデータベースから切断するまで待機しません。それ以降の接続は禁止されます。データベースはクローズされ、ディスマウントされます。インスタンスはシャットダウンされ、次回のデータベース起動時にインスタンスのリカバリは不要です。

- NORMAL
これはデフォルトのオプションです。プロセスは、ユーザーがデータベースから切断するまで待機します。それ以降の接続は禁止されます。データベースはクローズされ、ディスマウントされます。インスタンスはシャットダウンされ、次回のデータベース起動時にインスタンスのリカバリは不要です。

コマンドの例

次のコマンドにより、プライマリ・データベースをNORMALモードでシャットダウンします。

DGMGRL> SHUTDOWN;

Database closed.
Database dismounted.
Oracle instance shut down.

7.47 SQL

SQL文またはPL/SQLストアド・プロシージャを実行します。

書式

SQL "sql_statmement"

コマンド・パラメータ

sql_statement

実行するSQL文またはPL/SQLプロシージャ。

使用上の注意

- 実行するSQL文またはPL/SQLストアド・プロシージャは、二重引用符に入れる必要があります。

- 実行するSQL文の後にはセミコロン(;)を付けません。

- DGMGRLがPL/SQLに渡す文字列にファイル名が含まれる場合、ファイル名を一重引用符で囲み、SQLコマンドに続く文字列全体を二重引用符で囲む必要があります。たとえば、次の構文を使用します。

SQL "CREATE TABLESPACE temp1 DATAFILE '?/oradata/trgt/temp1.dbf' SIZE 10M TEMPORARY"

- SELECT文は実行できません。

コマンドの例

データベースをオープンするには、次のコマンドを入力します。

DGMGRL> SQL "alter database open"

7.48 START OBSERVER

ファスト・スタート・フェイルオーバーを開始します。

書式

START OBSERVER [ FILE=observer_configuration_filename ];

コマンド・パラメータ

observer_configuration_filename

オブザーバ・コンピュータ上で明示的なディレクトリ・パスおよびファイル名を指定します。

使用上の注意

- ファスト・スタート・フェイルオーバーを有効化する予定のブローカ構成を監視するには、Oracle Client Administratorキット、Oracle Database Enterprise EditionまたはOracle Database Personal Editionのフルキットを、オブザーバ・コンピュータ上にインストールする必要があります。詳細は、「ファスト・スタート・フェイルオーバーを有効化するための前提条件」を参照してください。

- START OBSERVERコマンドは、オブザーバ・コンピュータ上で発行する必要があります。オブザーバが正常に開始されると、制御は、(別のクライアント接続からのSTOP OBSERVERのコマンドの発行などにより)オブザーバが停止されるまでユーザーには戻されません。そのブローカ構成とさらに交信する場合は、他のクライアントを介して接続する必要があります。

- オブザーバは、正常に起動すると自動的に動作します。このため、START OBSERVERコマンドを発行する目的でDGMGRLを起動する場合、オブザーバとして機能する間に生成された出力が失われないように、コマンドラインでオプション・パラメータ-logfileを指定することをお薦めします。このパラメータの詳細は、「DGMGRLのオプション・パラメータ」を参照してください。-logfileオプションの使用例は、「オブザーバ・ログ・ファイルでのオブザーバの処理の取得」を参照してください。

- ディレクトリ・パスがFILEパラメータを使用して指定されていない場合、オブザーバは、現在の作業ディレクトリでfsfo.datファイルを検索します。fsfo.datファイルが検出されない場合で、START OBSERVERコマンドを初めて発行する場合には、オブザーバにより、fsfo.datファイルが作成されます。

- プライマリ・データベースおよびターゲット・スタンバイ・データベースのDB_UNIQUE_NAME初期化パラメータおよび接続識別子は、fsfo.dat構成ファイルに格納されています。このファイルの不正アクセスを確実に防止することをお薦めします。

- このコマンドを発行する前に、ファスト・スタート・フェイルオーバーを有効化しておく必要はありません。

- ファスト・スタート・フェイルオーバーが有効化されている場合、オブザーバは、プライマリおよびターゲット・スタンバイの接続識別子をブローカ構成から取得し、構成の監視を開始します。

- ファスト・スタート・フェイルオーバーが有効化されていない場合、オブザーバは、継続的にファスト・スタート・フェイルオーバーの有効化の時期を監視します。

- このコマンドの発行時、実行されている必要があるのはプライマリ・データベースのみです。コマンドを正常に実行するために、ファスト・スタート・フェイルオーバーのターゲットとなるスタンバイ・データベースが実行されている必要はありません。

- オブザーバおよびそのホスト・コンピュータのステータスを表示するには、SHOW FAST_START FAILOVERコマンドまたはSHOW CONFIGURATION VERBOSEコマンドを使用するか、プライマリ・データベースのV$DATABASEビューでFS_FAILOVER_*列を問い合せます。

- SHOW FAST_START FAILOVERコマンドは、オブザーバが起動済であるとブローカ構成で認識されているかどうかを示します。コマンドで次のように表示される場合、任意のコンピュータでSTART OBSERVERコマンドを発行しオブザーバを起動できます。

Observer:       (none)

SHOW FAST_START FAILOVERコマンドで「Observer:」の値が表示されたが、そのオブザーバの場所にあるオブザーバがなんらかの理由で実行されていない場合、次のいずれかの操作を実行できます。

- オブザーバを最初に起動したときに使用したオブザーバ構成ファイルを指定して、START OBSERVERコマンドを、最初にオブザーバを起動したオブザーバ・コンピュータ上で発行します。

- 任意のコンピュータ上で、STOP OBSERVERコマンドを発行してからSTART OBSERVERコマンドを発行してオブザーバを起動します。

SHOW FAST_START FAILOVERコマンドで「Observer:」の値が表示され、オブザーバがその場所ですでに実行されている場合、同じ場所で再度オブザーバを起動しようとすると、次のエラーが表示されて失敗します。

DGM-16954: Unable to open and lock the Observer configuration file

SHOW FAST_START FAILOVERコマンドで「Observer:」の値が表示された場合、別の場所でオブザーバを起動しようとすると、次のエラーが表示されてコマンドは失敗します。

ORA-16647: could not start more than one observer

- プライマリ・データベースとターゲットのスタンバイ・データベースの間の接続が維持されている状態でオブザーバとの接続が失われた場合、プライマリ・データベースは監視されない状態になります。この状態は、ブローカの健全性チェック機能により報告されます。

コマンドの例

例1: オブザーバの起動

次の例では、オブザーバの起動方法を示しています。

DGMGRL> CONNECT sysdg@North_Sales.example.com;
Password: password
Connected as SYSDG.
DGMGRL> START OBSERVER;
Observer started

例2: オブザーバの起動(資格証明の表示なし)

次の例は、コマンドラインで接続資格証明を表示できないように、CONNECT '/'を使用してオブザーバを起動する方法を示しています。

DGMGRL> CONNECT /@North_Sales.example.com;
DGMGRL> START OBSERVER;
Observer started.

CONNECT '/'を使用するには、OracleウォレットまたはSSLを設定する必要があります。OracleウォレットまたはSSLを設定することで、スクリプトでデータベース資格証明を指定せずに、オブザーバをバックグラウンド・ジョブとして安全に起動および実行するためのスクリプトを記述できます。Oracleウォレットをセキュアな外部パスワード・ストアとして使用する場合は、プライマリ・データベースおよびファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースの資格証明を追加する必要があります。各データベースの資格証明を追加するとき、指定するデータベース接続文字列は、データベース・プロパティObserverConnectIdentiferまたはDGConnectIdentifierと一致している必要があります。

7.49 STARTUP

次のいずれかのオプションを指定してOracleデータベース・インスタンスを起動します。

- FORCE: 現行のOracleインスタンスをSHUTDOWN ABORTモードでシャットダウンしてから、再起動します。

- RESTRICT: RESTRICTED SESSIONシステム権限を持つOracleユーザーにのみインスタンスへの接続を許可します。

- PFILE: データベース・インスタンスの起動時に使用するPFILE初期化パラメータ・ファイルを指定します。

- MOUNT: 指定したデータベースをオープンせずにマウントします。

- OPEN: 指定したデータベースをマウントしてオープンします。

- NOMOUNT: 指定したデータベース・インスタンスを、データベースをマウントせずに起動します。

書式

STARTUP [FORCE] [RESTRICT] [PFILE=filename] [MOUNT | OPEN [open_options] | NOMOUNT];

コマンド・パラメータ

filename

データベース・インスタンスの起動時に使用する初期化パラメータ・ファイルの名前。PFILEパラメータ・オプションを指定しない場合は、(オペレーティング・システム固有の)デフォルトのサーバー・パラメータ・ファイルが使用されます。

open-options

指定したデータベースを起動するためのアクセス・モード。可能なモードは次のとおりです。

- READ ONLY

- READ WRITE

使用上の注意

- 引数を指定せずにSTARTUPコマンドを使用すると、STARTUP OPENコマンドを使用した場合と同じ結果になります。

- STARTUPコマンドの使用時にFORCE句を指定せず、現行のデータベース・インスタンスが実行中の場合は、エラーになります。FORCE句は、デバッグ時やエラー条件の発生時に役立ちます。それ以外の場合は、使用しないでください。

- RESTRICT句を使用すると、RESTRICTED SESSIONシステム権限を持つOracleユーザーにのみインスタンスへの接続が許可されます。後でSQL*Plusを介しALTER SYSTEMコマンドを使用して、制限付きセッション機能を無効化できます。

- 初期化パラメータ・ファイルの指定にPFILE句を使用しない場合、STARTUPコマンドではデフォルトのサーバー・パラメータ・ファイル(存在する場合)が使用されます。それ以外の場合、STARTUPコマンドではデフォルトの初期化パラメータ・ファイルが使用されます。デフォルトのファイルはプラットフォーム固有です。
デフォルトのパラメータ・ファイルの詳細は、オペレーティング・システム固有のマニュアルを参照してください。

- 指定したデータベースをマウントしてオープンするには、OPEN句を使用します。

- NOMOUNT句を指定すると、データベースをマウントせずにデータベース・インスタンスを起動できます。NOMOUNT句は、MOUNTまたはOPENオプションと併用できません。

コマンドの例

例1: データベース・インスタンスの2つの起動方法

次の例では、データベース・インスタンスの2つの起動方法を示します。各コマンドでは、標準パラメータ・ファイルを使用してデータベース・インスタンスを起動し、デフォルト・データベースを排他モードでマウントしてオープンしています。

DGMGRL> STARTUP;
DGMGRL> STARTUP OPEN;

例2: 現在のインスタンスの停止および再起動(マウント/オープンなし)

次のコマンドでは、現行のインスタンスをシャットダウンし、その直後にマウントもオープンもせずにデータベースを再起動し、制限付きセッション権限のあるユーザーにのみ接続を許可しています。

DGMGRL> STARTUP FORCE RESTRICT NOMOUNT;

例3: パラメータ・ファイルを使用したインスタンスの起動(ただし、マウントなし)

次のコマンドでは、パラメータ・ファイルtestparmを使用して、データベースをマウントせずにインスタンスを起動しています。

DGMGRL> STARTUP PFILE=testparm NOMOUNT;

例4: インスタンスの起動およびマウント(オープンなし)

次の例では、データベース・インスタンスを起動してマウントしていますが、オープンはしていません。

DGMGRL> STARTUP MOUNT;

7.50 STOP OBSERVER

ファスト・スタート・フェイルオーバーを停止します。

書式

STOP OBSERVER

コマンド・パラメータ

なし。

使用上の注意

- このコマンドは、ブローカ構成内のいずれかのデータベースと接続されている場合に発行できます。

- このコマンドではファスト・スタート・フェイルオーバーを無効化できませんが、ファスト・スタート・フェイルオーバーはオブザーバがないと開始できません。

- このコマンドの発行時に、ファスト・スタート・フェイルオーバーが有効化されている必要はありません。

- STOP OBSERVERコマンドの発行時にファスト・スタート・フェイルオーバーが有効化されている場合は、プライマリ・データベースおよびスタンバイ・データベースが接続され、相互に交信している必要があります。そうでない場合は、次のエラーが戻されます。

ORA-16636 fast-start failover target standby in error state, cannot stop observer

プライマリ・データベースとスタンバイ・データベースが接続されていない場合、プライマリ・データベースでDISABLE FAST_START FAILOVER FORCEコマンドを発行してからSTOP OBSERVERコマンドを発行できます。オブザーバおよびターゲットのスタンバイ・データベースから切断されたプライマリ・データベース上でFORCEオプションを指定してファスト・スタート・フェイルオーバーを無効化しても、オブザーバによる、ターゲットのスタンバイ・データベースへのファスト・スタート・フェイルオーバーの開始を無効にはできません。

- STOP OBSERVERコマンドの発行時にファスト・スタート・フェイルオーバーが有効化されていない場合は、オブザーバの停止時にプライマリ・データベースのみが実行されている必要があります。

- オブザーバは、STOP OBSERVERコマンドの発行後すぐには停止されません。オブザーバは、次回オブザーバーがブローカと接続されるまで停止されたことを検出しません。
STOP OBSERVERコマンドの発行後ただちに、任意のコンピュータでSTART OBSERVERコマンドを再度入力できます。旧オブザーバがまだ自身の停止を検出していない場合でも、新規オブザーバを即座に開始できます。ブローカ構成では新しいオブザーバがすでに開始されているため、元のオブザーバの開始を試行すると失敗します。

コマンドの例

次の例ではオブザーバを停止しています。

DGMGRL> STOP OBSERVER;

7.51 SWITCHOVER

スイッチオーバー操作は、プライマリ・データベースがスタンバイ・データベースの1つとロールを交換する計画的な遷移です。SWITCHOVERコマンドを発行すると、現行のプライマリ・データベースがスタンバイ・データベースになり、指定したスタンバイ・データベースがプライマリ・データベースになります。

書式

SWITCHOVER TO database-name;

コマンド・パラメータ

database-name

プライマリ・データベースのロールに変更するスタンバイ・データベースの名前。

使用上の注意

- ファスト・スタート・フェイルオーバーが有効な場合は、ファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースへのスイッチオーバーのみ実行できます。

- スイッチオーバーの起動前に、ブローカによって、プライマリ・データベースおよびスタンバイ・データベースが次の状態であることが検証されます。

- REDO転送サービスが起動するように、プライマリ・データベースが有効化され、TRANSPORT-ON状態になっている必要があります。

- スタンバイ・データベースが有効化され、TRANSPORT-ON状態になっており、ログ適用サービスが起動している必要があります。

- ブローカは、スイッチオーバーに関係するように選択したスタンバイ・データベースにREDO転送サービスのエラーがないかぎり、スイッチオーバーを続行します。その他のスタンバイ・データベースにエラーが発生しても、スイッチオーバーの続行には影響しません。

- ロジカル・スタンバイ・データベースへのスイッチオーバーは、構成が最大保護モードで動作している場合には許可されません。

- ブローカ構成が最大保護モードまたは最大可用性モードで動作している場合、スイッチオーバーの操作後も同じ保護モードが維持されます(「スイッチオーバー操作実行前の考慮事項」を参照)。スイッチオーバーのターゲットとなるスタンバイ・データベースが保護モード要件を満たす唯一のスタンバイであったためにモードを維持できない場合、スイッチオーバーは許可されません。

- プライマリ・ロールを引き継ぐスタンバイ・データベースがフィジカル・スタンバイ・データベースの場合は、スイッチオーバーの完了後に、元のプライマリ・データベースが再起動されます。スタンバイ・データベースがロジカル・スタンバイ・データベースの場合は、プライマリ・データベースもロジカル・スタンバイ・データベースも再起動されません。

- プライマリ・ロールを引き継ぐスタンバイ・データベースがフィジカル・スタンバイ・データベースの場合、元のプライマリ・データベースはフィジカル・スタンバイ・データベースとなります。

- プライマリ・ロールを引き継ぐスタンバイ・データベースがロジカル・スタンバイ・データベースの場合、元のプライマリ・データベースはロジカル・スタンバイ・データベースとなります。

- Oracle RACプライマリ・データベースがフィジカル・スタンバイ・データベースになる場合、スイッチオーバーを実行する前に、プライマリ・データベース上のインスタンスのうち1つを残してそれ以外はすべては停止されます。詳細は、「スイッチオーバー」を参照してください。

- スナップショット・スタンバイ・データベースにスイッチオーバーすることはできません。

- プライマリ・ロールを引き継ぐスタンバイ・データベースがロジカル・スタンバイ・データベースで、構成にフィジカル・スタンバイ・データベースが含まれている場合、スイッチオーバー後、フィジカル・スタンバイ・データベースは無効化されます。

注意:

このため、通常、スイッチオーバーには、ロジカル・スタンバイ・データベースのかわりにフィジカル・スタンバイ・データベースを指定することをお薦めします。ロジカル・スタンバイ・データベースへのスイッチオーバーが必要な場合、フィジカル・スタンバイ・データベースを再作成する方法については、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

比較的すぐに元のプライマリ・データベースにスイッチバックする場合は、フィジカルおよびスナップショット・スタンバイ・データベースを無効なままにしておくことができます。フィジカルおよびスナップショット・スタンバイ・データベースはまだ元のプライマリ・データベースの実行可能なスタンバイ・データベースであるため、元のプライマリ・データベースへのスイッチバックの完了後、これらを再有効化できます。

コマンドの例

例1: フィジカルからプライマリへのスイッチオーバーの成功例

次の例では、フィジカル・スタンバイ・データベースSouth_Salesがプライマリ・ロールに遷移する正常なスイッチオーバーを示しています。

DGMGRL> switchover to 'South_Sales';
Performing switchover NOW, please wait...
New primary database "South_Sales" is opening...
Operation requires shutdown of instance "north_sales1" on database "North_Sales"
Shutting down instance "north_sales1"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "north_sales1" on database "North_Sales"
Starting instance "north_sales1"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "South_Sales"

例2: O/S認証を使用したことによるスイッチオーバーの失敗例

オペレーティング・システム認証を使用してデータベースに接続する場合は、任意のユーザー名およびパスワードを使用して接続できます。ただし、DGMGRLはリモートでは自己認証できないため、プライマリ・データベースとスタンバイ・データベースを自動的にシャットダウンして起動することができません。

次に、スイッチオーバーには成功したが、DGMGRLでプライマリ・データベースとスタンバイ・データベースのシャットダウンおよび起動ができなかったためにエラーが戻された例を示します。

DGMGRL> SWITCHOVER TO 'South_Sales';
Performing switchover NOW, please wait...
New primary database "South_Sales" is opening...
Operation requires shutdown of instance "north_sales1" on database "North_Sales"
Shutting down instance "north_sales1"...
ORA-01031: insufficient privileges

Warning: You are no longer connected to ORACLE.

Please complete the following steps to finish switchover:
shut down instance "north_sales1" of database "North_Sales"
start up and mount instance "north_sales1" of database "North_Sales"

注意:

DGMGRLでインスタンスを自動的に再起動するには、最後のCONNECTコマンドが別のデータベースへの接続に使用された場合でも、最後のCONNECTコマンドに指定された資格証明を使用してデータベースに接続する必要があります。

SHUTDOWNおよびSTARTUPコマンドを手動で発行して、新しいプライマリおよび停止されたスタンバイ・インスタンスを再起動する必要があります。

7.52 VALIDATE DATABASE

ロール変更に先立って包括的なデータベース・チェックを実行します。チェックでは、様々なOracle Data Guardビューや自動診断リポジトリで入手できる情報を使用します。

書式

VALIDATE DATABASE [VERBOSE] database-name;

コマンド・パラメータ

database-name

情報を表示するデータベースの名前。VERBOSEキーワードを使用する場合は、database-nameの前に指定する必要があります。そうしないとエラーが戻ります。

使用上の注意

VALIDATE DATABASEコマンドは、データベースのサマリーを表示し、エラーまたは警告が検出されたらレポートします。VALIDATE DATABASE VERBOSEは、簡潔なサマリーの全内容に加え、検証されたすべての項目を表示します。

コマンドの例

この項の例は、プライマリおよびスタンバイ・データベースでのVALIDATE DATABASEコマンドの出力の、簡潔表示と詳細表示の例を示します。

例1: プライマリに対するVALIDATE DATABASEの簡潔出力

次の例は、プライマリ・データベースの簡潔出力を示します。

DGMGRL> VALIDATE DATABASE 'South_Sales';

Database Role:    Primary database

Ready for Switchover:  Yes

例2: ロジカル・スタンバイに対するVALIDATE DATABASEの簡潔出力

次の例は、ロジカル・スタンバイ・データベースの簡潔出力を示します。

DGMGRL> VALIDATE DATABASE 'West_Sales';

Database Role:     Logical standby database
Primary Database:  South_Sales

Ready for Switchover:  Yes
Ready for Failover:    Yes (Primary Running)
Warning: Physical and snapshot standby databases will
be disabled if a role change is performed to this database

例3: フィジカル・スタンバイに対するVALIDATE DATABASEの簡潔出力

次の例は、フィジカル・スタンバイ・データベースの簡潔出力を示します。

DGMGRL> VALIDATE DATABASE 'North_Sales';

Database Role:     Physical standby database
Primary Database:  South_Sales

Ready for Switchover:  Yes
Ready for Failover:    Yes (Primary Running)

例4: プライマリに対するVALIDATE DATABASEの詳細出力

次の例は、プライマリ・データベースの詳細出力を示します。

DGMGRL> VALIDATE DATABASE VERBOSE 'South_Sales';

Database Role:    Primary database

Ready for Switchover:  Yes

Capacity Information:
Database     Instances        Threads
South_Sales      2                2

Temporary Tablespace File Information:
South_Sales TEMP Files:  2

Flashback Database Status:
South_Sales:  On

Data file Online Move in Progress:
South_Sales:  No

Transport-Related Information:
Transport On:  Yes

Log Files Cleared:
South_Sales Standby Redo Log Files:  Cleared

Automatic Diagnostic Repository Errors:
Error                       South_Sales
No logging operation        NO
Control file corruptions    NO
System data file missing    NO
System data file corrupted  NO
System data file offline    NO
User data file missing      NO
User data file corrupted    NO
User data file offline      NO
Block Corruptions found     NO

例5: ロジカル・スタンバイに対するVALIDATE DATABASEの詳細出力

次のコマンドは、ロジカル・スタンバイ・データベースの詳細出力を示します。

DGMGRL> VALIDATE DATABASE VERBOSE 'West_Sales';
Database Role:     Logical standby database
Primary Database:  South_Sales

Ready for Switchover:  Yes
Ready for Failover:    Yes (Primary Running)
Warning: Logical and snapshot standby databases will
be disabled if a role change is performed to this database

Capacity Information:
Database      Instances        Threads
South_Sales      2                2
West_Sales       2                2

Temporary Tablespace File Information:
South_Sales TEMP Files:   2
West_Sales TEMP Files:  2

Flashback Database Status:
South_Sales:   On
West_Sales:  On

Data file Online Move in Progress:
South_Sales:   No
West_Sales:  No

Standby Apply-Related Information:
Apply State:      Running
Apply Lag:        0 seconds
Apply Delay:      0 minutes

Transport-Related Information:
Transport On:      Yes
Gap Status:        No Gap
Transport Lag:     0 seconds
Transport Status:  Success

Log Files Cleared:
South_Sales Standby Redo Log Files: Cleared
West_Sales Online Redo Log Files:   Not applicable for this database
West_Sales Standby Redo Log Files:  Available

Current Log File Groups Configuration:
Thread #  Online Redo Log Groups   Standby Redo Log Groups  Status
(South_Sales)            (West_Sales)
1         4                        5                        Sufficient SRLs
2         4                        5                        Sufficient SRLs

Future Log File Groups Configuration:
Thread #  Online Redo Log Groups   Standby Redo Log Groups  Status
(West_Sales)             (South_Sales)
1         4                        5                        Sufficient SRLs
2         4                        5                        Sufficient SRLs

Current Configuration Log File Sizes:
Thread #   Smallest Online Redo      Smallest Standby Redo
Log File Size             Log File Size
(South_Sales)             (West_Sales)
1          25 MBytes                 25 MBytes
2          25 MBytes                 25 MBytes

Future Configuration Log File Sizes:
Thread #   Smallest Online Redo      Smallest Standby Redo
Log File Size             Log File Size
(West_Sales)              (South_Sales)
1          25 MBytes                 25 MBytes
2          25 MBytes                 25 MBytes

Apply-Related Property Settings:
Property                        South_Sales Value        West_Sales Value
DelayMins                       0                        0
LsbyMaxEventsRecorded           0                        0
LsbyPreserveCommitOrder         <empty>                  <empty>
LsbyRecordSkipErrors            <empty>                  <empty>
LsbyRecordSkipDdl               <empty>                  <empty>
LsbyRecordAppliedDdl            <empty>                  <empty>

Transport-Related Property Settings:
Property                        South_Sales Value        West_Sales Value
LogXptMode                      SYNC                     SYNC
Dependency                      <empty>                  <empty>
DelayMins                       0                        0
Binding                         optional                 optional
MaxFailure                      0                        0
MaxConnections                  1                        1
ReopenSecs                      30                       30
NetTimeout                      300                      300
RedoCompression                 DISABLE                  DISABLE
LogShipping                     ON                       ON

Automatic Diagnostic Repository Errors:
Error                       South_Sales     West_Sales
No logging operation        NO              NO
Control file corruptions    NO              NO
SRL Group Unavailable       NO              NO
System data file missing    NO              NO
System data file corrupted  NO              NO
System data file offline    NO              NO
User data file missing      NO              NO
User data file corrupted    NO              NO
User data file offline      NO              NO
Block Corruptions found     NO              NO

例6: フィジカル・スタンバイに対するVALIDATE DATABASEの詳細出力

次のコマンドは、フィジカル・スタンバイ・データベースの詳細出力を示します。

DGMGRL> VALIDATE DATABASE VERBOSE North_Sales';
Database Role:     Physical standby database
Primary Database:  South_Sales

Ready for Switchover:  Yes
Ready for Failover:    Yes (Primary Running)

Capacity Information:
Database     Instances        Threads
South_Sales      2                2
North_Sales      2                2

Temporary Tablespace File Information:
South_Sales TEMP Files:   2
North_Sales TEMP Files:  2

Flashback Database Status:
South_Sales:   On
North_Sales:  On

Data file Online Move in Progress:
South_Sales:   No
North_Sales:  No

Standby Apply-Related Information:
Apply State:      Running
Apply Lag:        0 seconds
Apply Delay:      0 minutes

Transport-Related Information:
Transport On:      Yes
Gap Status:        No Gap
Transport Lag:     0 seconds
Transport Status:  Success

Log Files Cleared:
South_Sales Standby Redo Log Files:  Cleared
North_Sales Online Redo Log Files:   Cleared
North_Sales Standby Redo Log Files:  Available

Current Log File Groups Configuration:
Thread #  Online Redo Log Groups   Standby Redo Log Groups  Status
(South_Sales)            (North_Sales)
1         4                        5                        Sufficient SRLs
2         4                        5                        Sufficient SRLs

Future Log File Groups Configuration:
Thread #  Online Redo Log Groups   Standby Redo Log Groups
(North_Sales)            (South_Sales)
1         4                        5                        Sufficient SRLs
2         4                        5                        Sufficient SRLs

Current Configuration Log File Sizes:
Thread #   Smallest Online Redo      Smallest Standby Redo
Log File Size             Log File Size
(South_Sales)             (North_Sales)
1          25 MBytes                 25 MBytes
2          25 MBytes                 25 MBytes

Future Configuration Log File Sizes:
Thread #   Smallest Online Redo      Smallest Standby Redo
Log File Size             Log File Size
(North_Sales)                   (South_Sales)
1          25 MBytes                 25 MBytes
2          25 MBytes                 25 MBytes

Apply-Related Property Settings:
Property                        South_Sales Value        North_Sales Value
DelayMins                       0                        0
ApplyParallel                   AUTO                     AUTO

Transport-Related Property Settings:
Property                        South_Sales Value        North_Sales Value
LogXptMode                      SYNC                     SYNC
Dependency                      <empty>                  <empty>
DelayMins                       0                        0
Binding                         optional                 optional
MaxFailure                      0                        0
MaxConnections                  1                        1
ReopenSecs                      30                       30
NetTimeout                      300                      300
RedoCompression                 DISABLE                  DISABLE
LogShipping                     ON                       ON

Automatic Diagnostic Repository Errors:
Error                       South_Sales     North_Sales
No logging operation        NO              NO
Control file corruptions    NO              NO
SRL Group Unavailable       NO              NO
System data file missing    NO              NO
System data file corrupted  NO              NO
System data file offline    NO              NO
User data file missing      NO              NO
User data file corrupted    NO              NO
User data file offline      NO              NO
Block Corruptions found     NO              NO

7.53 VALIDATE FAR_SYNC

遠隔同期インスタンスに対する一連の包括的なチェックを実行します。チェックでは、Oracle Data Guardの様々なビューで使用可能な情報が使用されます。

書式

VALIDATE FAR_SYNC [VERBOSE] far_sync_instance_name [WHEN PRIMARY IS database-name];

コマンド・パラメータ

far_sync_instance_name

情報を表示するイ遠隔同期ンスタンスの名前。VERBOSEキーワードを使用する場合は、far_sync_instance_nameの前に指定しないと、エラーが戻されます。

database-name

遠隔同期インスタンスの検証は、プライマリ・データベースである指定のデータベースに基づいて実行されます。

使用上の注意

VALIDATE FAR_SYNCコマンドは、遠隔同期インスタンスの簡潔なサマリーを表示し、エラーまたは警告が検出された場合は報告します。VALIDATE FAR_SYNC VERBOSEコマンドは、簡潔なサマリーの全内容に加え、REDO転送関連情報を表示します。

コマンドの例

この項では、様々なシナリオにおけるVALIDATE FAR_SYNCコマンドの出力例を示しています。

例1: VALIDATE FAR_SYNCの簡潔出力

次の例では、遠隔同期インスタンスの簡潔な出力を示しています。

DGMGRL> VALIDATE FAR_SYNC FS;

Member Role:        Far Sync Instance
When Primary Is:    North_Sales

Active Redo Source: North_Sales
Redo Destinations:
South_Sales

Thread #  Online Redo Log Groups  Standby Redo Log Groups Status
North_Sales             FS
1         4                       5                       Sufficient SRLs

例2: VALIDATE FAR_SYNCの詳細出力

次の例では、遠隔同期インスタンスの冗長な出力を示しています。

DGMGRL> VALIDATE FAR_SYNC VERBOSE FS;

Member Role:        Far Sync Instance
When Primary Is:    North_Sales

Active Redo Source: North_Sales
Redo Destinations:
South_Sales

Thread #  Online Redo Log Groups  Standby Redo Log Groups Status
North_Sales             FS
1         4                       5                       Sufficient SRLs

Transport-Related Information:
Transport On:      Yes
Gap Status:        No Gap
Transport Lag:     0 seconds (computed 0 seconds ago)
Transport Status:  Success

例3: South_Salesがプライマリの場合のVALIDATE FAR_SYNCの出力

次の例では、South_Salesデータベースをプライマリ・データベースとして指定したときの出力を示しています。

DGMGRL> VALIDATE FAR_SYNC FS WHEN PRIMARY IS 'South_Sales';

Member Role:        Far Sync Instance
When Primary Is:    South_Sales
Redo Destinations:
North_Sales

Thread #  Online Redo Log Groups  Standby Redo Log Groups Status
South_Sales             FS
1         4                       5                       Sufficient SRLs

8 Oracle Data Guard Brokerのプロパティ

Oracle Data Guard Brokerには、ブローカ構成全体、個別の構成メンバー、REDO転送サービスおよびログ適用サービスの動作を表示および制御するのに役立つ、様々なデータベース構成とデータベース・プロパティが用意されています。

- 構成プロパティ

- 監視可能な(読取り専用)プロパティ

- 構成可能なプロパティ

プロパティの範囲は、構成全体、データベース全体、遠隔同期インスタンス全体またはインスタンス固有のいずれかです。構成全体を範囲とするプロパティは構成内のすべてのメンバーのブローカの動作を制御します。このようなプロパティの値は、構成内のすべてのメンバーで均一に適用されます。

データベース全体を範囲とするプロパティにより、特定のデータベースの動作を表示または制御できます。データベース(プライマリまたはスタンバイ)は複数のインスタンスから構成されるOracle RACデータベースであり、このようなプロパティの値はデータベースのすべてのインスタンスで均一に適用されます。

遠隔同期インスタンス全体を範囲とするプロパティにより、遠隔同期インスタンスの動作を表示または制御できます。

インスタンス固有のプロパティにより、個別のデータベース・インスタンスの動作を表示または制御できます。このようなプロパティはOracle RACデータベースのすべてのインスタンスに存在しますが、その値はインスタンスごとに異なる可能性があります。

注意:

Oracle Data Guardコマンドライン・インタフェース(DGMGRL)を使用して、ブローカ・プロパティを表示または変更できます。

Oracle Enterprise Manager Cloud Control (Cloud Control)では、「プロパティの編集」ページに一部のブローカ・プロパティが明示的に表示されます。他のプロパティからの情報は、Cloud Controlで表示される他のWebページに暗黙的に組み込まれている場合があります。各プロパティがCloud Controlにどのように表示されるかについては、それぞれの個別の説明を参照してください。

8.1 構成プロパティ

構成プロパティは、ブローカ構成の動作を制御します。これらのプロパティの値は、DGMGRLまたはCloud Controlを使用して表示し、動的に更新できます。ただし、一部のプロパティは、DGMGRLを使用しなければ更新できません。

構成プロパティは構成全体が有効範囲です。つまり、プロパティに対して設定した値は、構成内の各メンバーに均一に適用されます。

構成プロパティは、次の例に示すように、EDIT CONFIGURATION SET PROPERTYコマンドを使用して設定します。

例1

この例では、FastStartFailoverThreshold構成プロパティを90秒に設定しています。

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold=90;

例2

この例では、ExternalDestination1構成プロパティを、サービス名としてSales、DB_UNIQUE_NAMEとしてchicagoを含むREDO転送先を指すように設定しています。

EDIT CONFIGURATION SET PROPERTY ExternalDestination1='SERVICE=Sales DB_UNIQUE_NAME=chicago';

注意:

一般に、プロパティ値の大文字と小文字の区別を保持する必要がないかぎり、プロパティ値を引用符で囲む必要はありません。DGMGRLでは、入力した文字列は、引用符で囲まれていないかぎり、デフォルトですべて小文字に変換されます。

空白または句読点を含むプロパティ値(RedoRoutes、LogFileNameConvert、DBFileNameConvertなど)には、引用符は必須です。

次の項で、構成プロパティについて説明します。

- BystandersFollowRoleChange

- CommunicationTimeout

- ExternalDestination1

- ExternalDestination2

- FastStartFailoverAutoReinstate

- FastStartFailoverLagLimit

- FastStartFailoverPmyShutdown

- FastStartFailoverThreshold

- ObserverOverride

- ObserverReconnect

- OperationTimeout

- PrimaryLostWriteAction

- TraceLevel

8.1.1 BystandersFollowRoleChange

BystandersFollowRoleChange構成プロパティは、その他のスタンバイ・データベースの評価が、フェイルオーバー時(値はALL)とフェイルオーバー後(値はNONE)のどちらに行われるかを指定します。

- ALL - フェイルオーバー・プロセスの際、その他のスタンバイ・データベースがフェイルオーバー・ターゲット・スタンバイ(つまり、新しいプライマリになるスタンバイ)の先であるか後であるかをブローカが判断します。
その他のスタンバイが先である場合、それらはフェイルオーバー操作の中で、ORA-16661のステータスを与えられて無効にされます。フェイルオーバーが完了した後でその他のスタンバイを回復する必要があります。ブローカは、ターゲット・スタンバイがプライマリ・データベースになったSCNへのフラッシュバックを介してスタンバイを回復させ、新しいプライマリからスタンバイにREDO転送構成を設定します。

その他のスタンバイが後の場合、ブローカは単に次期プライマリからこれらのスタンバイにREDO転送構成を設定して、フェイルオーバー・プロセスを完了します。

- NONE - フェイルオーバー・プロセスの際、ブローカはフェイルオーバー操作の一部としてその他のスタンバイのステータスを評価しません。無効としてマークされ、後で評価できるように、ステータスはORA-16661になります。ブローカは単にフェイルオーバーを完了して、できるだけ早く新しいプライマリ・データベースを作成します。
フェイルオーバーが完了したら、その他のスタンバイを回復させることができます。その他のデータベースを回復する際、ブローカは、新しいプライマリより先か後か判断します。その他のデータベースが新しいプライマリより先の場合、ブローカは自動的に、ターゲット・スタンバイがプライマリ・データベースになった時点のSCNにスタンバイをフラッシュバックし、新しいプライマリからスタンバイにREDO転送を設定します。(フラッシュバックが必要ない場合も、ブローカは新しいプライマリからこれらのスタンバイにREDO転送構成を設定します。)

NONEオプションを指定すると、フェイルオーバーの処理時間は短縮されますが、構成内のすべての他のデータベースのブローカ管理が無効になります。ファスト・スタート・フェイルオーバーが有効な場合は、フェイルオーバーの完了後にオブザーバがスタンバイ・データベースを自動的に回復します。それ以外の場合は、フェイルオーバーの完了後にスタンバイ・データベースを手動で回復する必要があります。

カテゴリ

説明

データ型

文字列

有効値

ALLまたはNONE

ブローカ・デフォルト

ALL

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、完全フェイルオーバーのターゲットであるデータベースでブローカによって使用されます。

Cloud Control名

該当なし

8.1.2 CommunicationTimeout

CommunicationTimeout構成プロパティは、ブローカが構成内のメンバー間のネットワーク通信をタイムアウトするまで待機する秒数を指定します。値が0(ゼロ)の場合は、ネットワーク通信をタイムアウトしないことを示します。

カテゴリ

説明

データ型

整数

有効値

>= 0

ブローカ・デフォルト

180秒

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、構成内のすべてのデータベースでブローカによって使用されます。

Cloud Control名

該当なし

8.1.3 ExternalDestination1

注意:

- Externaldestination1構成プロパティは、Oracle Database 11gリリース2 (11.2.0.4)およびOracle Database 12cリリース1 (12.1.0.2)以上でのみ使用可能です。

- Oracle Database 12cリリース1 (12.1.0.2)で、ExternalDestination1構成プロパティはREDO転送先としてZero Data Loss Recovery Appliance (リカバリ・アプライアンス)をサポートします。

ExternalDestination1構成プロパティは、現在のプライマリ・データベースからREDOデータを受信できるREDO転送先を指定するために使用されます。指定された宛先へのREDOデータの転送を設定するために、ブローカは指定された値をこのパラメータに使用し、LOG_ARCHIVE_DEST_n初期化パラメータをプライマリ・データベースに定義します。さらにブローカは、指定された宛先への転送の健全性を監視します。

ロール変更後、ブローカは新しいプライマリ・データベースに対し、自動的にLOG_ARCHIVE_DEST_n初期化パラメータを設定し、REDOデータを指定された宛先に転送します。

カテゴリ

説明

データ型

文字列

有効値

LOG_ARCHIVE_DEST_nの属性(次の値を除く):

- ALTERNATE

- DELAY

- LOCATION

- MANDATORY

- MAX_FAILURE

- NET_TIMEOUT

- SYNC

- VALID_FOR

LOG_ARCHIVE_DEST_nパラメータの詳細は、『Oracle Data Guard概要および管理』を参照してください。

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

構成

Cloud Control名

該当なし

8.1.4 ExternalDestination2

注意:

- Externaldestination2構成プロパティは、Oracle Database 11gリリース2 (11.2.0.4)およびOracle Database 12cリリース1 (12.1.0.2)以上でのみ使用可能です。

- Oracle Database 12cリリース1 (12.1.0.2)で、ExternalDestination2構成プロパティはREDO転送先としてZero Data Loss Recovery Appliance (リカバリ・アプライアンス)をサポートします。

ExternalDestination2構成プロパティは、現在のプライマリ・データベースからREDOデータを受信できるREDO転送先を指定するために使用されます。指定された宛先へのREDOデータの転送を設定するために、ブローカは指定された値をこのパラメータに使用し、LOG_ARCHIVE_DEST_n初期化パラメータをプライマリ・データベースに定義します。さらにブローカは、指定された宛先への転送の健全性を監視します。

ロール変更後、ブローカは新しいプライマリ・データベースに対し、自動的にLOG_ARCHIVE_DEST_n初期化パラメータを設定し、REDOデータを指定された宛先に転送します。

カテゴリ

説明

データ型

文字列

有効値

LOG_ARCHIVE_DEST_nの属性(次の値を除く):

- ALTERNATE

- DELAY

- LOCATION

- MANDATORY

- MAX_FAILURE

- NET_TIMEOUT

- SYNC

- VALID_FOR

LOG_ARCHIVE_DEST_nパラメータの詳細は、『Oracle Data Guard概要および管理』を参照してください。

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

構成

Cloud Control名

該当なし

8.1.5 FastStartFailoverAutoReinstate

FastStartFailoverAutoReinstate構成プロパティを使用すると、プライマリ・データベースが分離またはクラッシュしたためにファスト・スタート・フェイルオーバーが開始した場合に、元のプライマリ・データベースが自動的に回復されます。この場合に元のプライマリ・データベースを自動的に回復しないようにするには、この構成プロパティをFALSEに設定します。

ユーザー構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを要求した場合は、ブローカは元のプライマリ・データベースを自動的に回復しません。

カテゴリ

説明

データ型

ブール

有効値

TRUEまたはFALSE

ブローカ・デフォルト

TRUE

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、ファスト・スタート・フェイルオーバーが有効化された後オブザーバにより使用されます。

Cloud Control名

プライマリを自動的に回復

8.1.6 FastStartFailoverLagLimit

FastStartFailoverLagLimit構成プロパティは、REDOの適用に関して、プライマリよりスタンバイが遅れることができる許容範囲を秒単位で確立します。この値を超えて遅れる場合は、ファスト・スタート・フェイルオーバーが実行されません。設定可能な最小値は10秒です。

このプロパティは、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作しているときに使用します。

カテゴリ

説明

データ型

整数

有効値

整数(秒数)。10以上にする必要があります。

ブローカ・デフォルト

30秒

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、ファスト・スタート・フェイルオーバーが有効化された後、プライマリ・データベースより使用されます。

Cloud Control名

ラグ制限

8.1.7 FastStartFailoverPmyShutdown

FastStartFailoverPmyShutdown構成プロパティにより、ファスト・スタート・フェイルオーバーが有効化されていてプライマリがFastStartFailoverThresholdの秒数よりも長くSTALLEDになったことをV$DATABASE.FS_FAILOVER_STATUSが示すと、プライマリ・データベースが停止します。この場合、プライマリが分離され、ファスト・スタート・フェイルオーバーが実行されている可能性があります。TRUEの値は、分離されたプライマリ・データベースがユーザーの問合せに対応できないことを確認するのに役立ちます。

ユーザーの構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを要求した場合、このプロパティをFALSEに設定してもプライマリ・データベースの停止を防止できません。

カテゴリ

説明

データ型

ブール

有効値

TRUEまたはFALSE

ブローカ・デフォルト

TRUE

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、ファスト・スタート・フェイルオーバーが有効化された後、プライマリ・データベースより使用されます。

Cloud Control名

プライマリを自動的に停止

8.1.8 FastStartFailoverThreshold

FastStartFailoverThreshold構成プロパティは、ターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーを開始するまでに、オブザーバーがプライマリ・データベースとの再接続を試行する時間(秒数)を指定します。この時間間隔は、オブザーバのプライマリ・データベースとの接続が最初に失われたときに開始されます。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できない場合、オブザーバによりファスト・スタート・フェイルオーバーが開始されます。このプロパティの設定方法の詳細は、「ファスト・スタート・フェイルオーバーの有効化」の手順4を参照してください。

構成可能なファスト・スタート・フェイルオーバー条件が検出された場合、またはアプリケーションでファスト・スタート・フェイルオーバーの開始を要求した場合、オブザーバはしきい値を完全に無視します。

このプロパティに対する適切な値を判断するうえで、V$FS_OBSERVER_HISTOGRAMビューで示される情報が役立ちます。このビューでは、異なる時間間隔のオブザーバとプライマリ・データベース間のpingの成功頻度に基づいた統計が表示されます。(このビューは、Oracle Database 12cリリース1 (12.1.0.2)以上で使用可能です。また、Oracle Database 11gリリース2 (11.2.0.4)でも使用できますが、Oracle Database 12cリリース1 (12.1.0.1)では使用できません。)V$FS_OBSERVER_HISTOGRAMビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

カテゴリ

説明

データ型

整数

有効値

整数(秒数)。6以上にする必要があります。

ブローカ・デフォルト

30秒

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリ・ロールにフェイルオーバーするターゲット・スタンバイ・データベース

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、ファスト・スタート・フェイルオーバーが有効化された後オブザーバにより使用されます。

Cloud Control名

Cloud Controlでは、この値はOracle Data Guardの概要ページに「フェイルオーバーのしきい値」として表示されます。

8.1.9 ObserverOverride

ObserverOverride構成プロパティをTRUEに設定すると、スタンバイがプライマリに正常に接続していても、オブザーバのプライマリへの接続が失われた場合、自動フェイルオーバーが発生します。

カテゴリ

説明

データ型

ブール

有効値

TRUEまたはFALSE

ブローカ・デフォルト

FALSE

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、ファスト・スタート・フェイルオーバーが有効化された後オブザーバにより使用されます。

Cloud Control名

該当なし

8.1.10 ObserverReconnect

ObserverReconnect構成プロパティは、オブザーバがプライマリ・データベースに対して新しい接続を確立する頻度を指定します。このプロパティがデフォルト値の0に設定されている場合、オブザーバはプライマリ・データベースへの接続を作成、維持しますが、プライマリ・データベースへの新しい接続を定期的に作成することはしません。これによりプライマリ・データベースに新しいオブザーバ接続を定期的に確立することによる処理オーバーヘッドがなくなる一方、オブザーバがプライマリ・データベースに新しい接続を作成できないことを検出できなくなります。このプロパティは、プライマリ・データベースの障害を適時に検出できる程度には小さいが、定期的なオブザーバ接続によるオーバーヘッドが許容できるレベルに収まる程度には大きい値に設定することをお薦めします。

カテゴリ

説明

データ型

整数

有効値

整数(秒数)。0以上にする必要があります。

ブローカ・デフォルト

0

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、ファスト・スタート・フェイルオーバーが有効化された後オブザーバにより使用されます。

Cloud Control名

該当なし

8.1.11 OperationTimeout

OperationTimeout構成プロパティは、ブローカがヘルス・チェック、監視可能なプロパティの取得およびプロパティの操作の設定を完了するまでの待機時間の最大値を指定します。

カテゴリ

説明

データ型

整数

有効値

>= 30および<= 600

ブローカ・デフォルト

30秒

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、構成内のすべてのデータベースでブローカによって使用されます。

Cloud Control名

該当なし

8.1.12 PrimaryLostWriteAction

注意:

PrimaryLostWriteAction構成プロパティは、Oracle Database 11gリリース2 (11.2.0.4)およびOracle Database 12cリリース1 (12.1.0.2)以上でのみ使用可能です。

PrimaryLostWriteAction構成プロパティは、プライマリ・データベースで書込み欠落が発生したことをスタンバイ・データベースが検出した場合の動作を決定します。

- CONTINUE - プライマリ・データベースで書込み欠落が発生したことをスタンバイ・データベースが検出した場合でも、プライマリ・データベースは動作を継続します。これはデフォルトのアクションです。

- SHUTDOWN - プライマリ・データベースで書込み欠落が発生したことをスタンバイ・データベースが検出した場合、ファスト・スタート・フェイルオーバーは無効化され、プライマリ・データベースは強制終了を実行します。自動フェイルオーバーは発生しません。

- FAILOVER - 最大パフォーマンス・モードでファスト・スタート・フェイルオーバーが有効化されており、構成がFastStartFailoverLagLimitプロパティに指定されている許容限界の範囲内にある場合、オブザーバによってフェイルオーバーが開始されます。(FAILOVERオプションは、Oracle Database 12cリリース1 (12.1.0.2)以上でのみ使用可能です。)

- FORCEFAILOVER - (最大パフォーマンス・モードか最大可用性モードのいずれかで)ファスト・スタート・フェイルオーバーが有効化されている場合、オブザーバによってフェイルオーバーが開始されます。このオプションを使用すると、データ消失を伴うフェイルオーバーが発生します。(FORCEFAILOVERオプションは、Oracle Database 12cリリース1 (12.1.0.2)以上でのみ使用可能です。)

FAILOVERオプションとFORCEFAILOVERオプションの両方について、ファスト・スタート・フェイルオーバーが無効化されている場合、フェイルオーバーは発生しませんが、プライマリは停止します。

プライマリ・データベースで書込み欠落が発生したことをスタンバイ・データベースが検出した場合、ファスト・スタート・フェイルオーバーは無効化されます。そのため、プライマリ・データベースで書込み欠落が発生したことをスタンバイが検出した場合、PrimaryLostWriteActionがSHUTDOWNに設定されている場合であっても、自動フェイルオーバーは発生しません。

プライマリ・データベースおよび書込み欠落を検出したスタンバイ・データベースのデータベース・アラートおよびブローカ・ログに診断情報が記述されます。

プライマリ・データベースで書込み欠落が発生した場合は、My Oracle Supportノート1265884.1 (http://support.oracle.com)のスタンバイ・リカバリ時のORA-752またはORA-600 [3020]の解決のガイドラインに従います。

注意:

プライマリ・データベースおよび構成内の各スタンバイ・データベースでDB_LOST_WRITE_PROTECTデータベース初期化パラメータをTYPICALまたはFULLに設定し、構成内のすべてのスタンバイ・データベースで、プライマリの書込み欠落を検出できるようにする必要があります。

カテゴリ

説明

データ型

文字列

有効値

CONTINUE、SHUTDOWN、FAILOVERまたはFORCEFAILOVER

ブローカ・デフォルト

CONTINUE

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成

Cloud Control名

該当なし

8.1.13 TraceLevel

TraceLevel構成プロパティは、構成のすべてのメンバーに対してブローカが実行するトレースの量を制御するために使用されます。プロパティをUSERに設定すると、トレース対象は、完了した操作と、操作またはヘルス・チェックから発生する警告またはエラー・メッセージに制限されます。プロパティをSUPPORTに設定すると、Oracleサポート・サービスが必要とするより低レベルの情報が含まれ、トレースの量が増大します。

カテゴリ

説明

データ型

文字列

有効値

USER、SUPPORT

ブローカ・デフォルト

USER

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

データベース

Cloud Control名

該当なし

8.2 監視可能な(読取り専用)プロパティ

監視可能なプロパティを使用すると、データベース、データベース・インスタンスまたは遠隔同期インスタンスに関連する情報を表示できますが、これらのプロパティの値は変更できません。監視可能なプロパティはすべて、DGMGRLのSHOWコマンドを使用して表示できます。

注意:

監視可能なプロパティの情報を表示できるのは、エンティティのブローカ管理が有効な場合のみです。Cloud Controlでは、これらのプロパティから取得された情報が「プロパティ」ページに表示されます。

データベースがOracle RACデータベースの場合、一部のプロパティの出力値にインスタンス固有の情報も示されることがあります。たとえば、プライマリ・データベースがOracle RACデータベースの場合、LogXptStatusは、Standby2にREDOデータを転送しているInstance1にエラーがあることと、Standby4にREDOデータを転送しているInstance2にエラーがあることを示す場合があります。

次の各項で、監視可能なプロパティについて説明します。

- InconsistentLogXptProps(非一貫性REDO転送プロパティ)

- InconsistentProperties(非一貫性プロパティ)

- LogXptStatus(REDO転送ステータス)

- LsbyFailedTxnInfo(ロジカル・スタンバイ障害トランザクション情報)

- LsbyParameters(ロジカル・スタンバイ・パラメータ)

- RecvQEntries(受信キュー・エントリ)

- SendQEntries(送信キュー・エントリ)

- TopWaitEvents

8.2.1 InconsistentLogXptProps(非一貫性REDO転送プロパティ)

監視可能なプロパティInconsistentLogXptPropsは、プロパティの値が、ブローカ構成ファイルとランタイム値の間で一貫性がないすべてのREDO転送サービスに関連するプロパティを示す表を戻します。

この表にレポートされるプロパティはデータベース固有または遠隔同期インスタンス固有のプロパティですが、非一貫性についてはインスタンス固有ベースでレポートされます。データベースまたは遠隔同期インスタンス固有のプロパティは、ブローカの構成ファイルに、データベースまたは遠隔同期インスタンスのすべてのインスタンスに対する1つの値が存在することを保証するだけです。ランタイム値は異なる場合があります。つまり、一部のインスタンスでのみデータベースまたは遠隔同期インスタンス固有のプロパティに一貫性がない場合があります。

このプロパティは、プライマリ・データベース、REDOデータを送信するフィジカル・スタンバイ・データベースまたは遠隔同期インスタンスに関係します。この表の列は、次のとおりです。

- INSTANCE_NAME
インスタンスのSIDを識別する値

- STANDBY_NAME
このREDO転送サービス・プロパティに関連するスタンバイ・データベースまたは遠隔同期インスタンスのデータベース一意名(DB_UNIQUE_NAME)

- PROPERTY_NAME
一貫性のない値が含まれるREDO転送サービス・プロパティの名前

- MEMORY_VALUE
データベースまたは遠隔同期インスタンスで使用されているランタイム値。

- BROKER_VALUE
ブローカ構成ファイルに保存されているREDO転送サービス・プロパティの値

8.2.2 InconsistentProperties(非一貫性プロパティ)

監視可能なプロパティInconsistentPropertiesは、ブローカ構成ファイルに含まれている値が、対応するサーバー・パラメータ・ファイル内の値またはデータベース内のランタイム値と一貫性がないすべてのプロパティを示す表を戻します。

この表にレポートされるプロパティはデータベース固有または遠隔同期インスタンス固有のプロパティですが、非一貫性についてはインスタンス固有ベースでレポートされます。データベースまたは遠隔同期インスタンス固有のプロパティは、ブローカの構成ファイルに、データベースまたは遠隔同期インスタンスのすべてのインスタンスに対する1つの値が存在することを保証するだけです。ランタイム値は異なる場合があります。つまり、一部のインスタンスでのみデータベースまたは遠隔同期インスタンス固有のプロパティに一貫性がない場合があります。

個々の構成メンバーは、このプロパティを持っています。この表の列は、次のとおりです。

- INSTANCE_NAME
インスタンスのSIDを識別する値

- PROPERTY_NAME
一貫性のない値が含まれるプロパティの名前

- MEMORY_VALUE
使用されている対応するランタイム値

- SPFILE_VALUE
サーバー・パラメータ・ファイル(SPFILE)に保存されている対応する値

- BROKER_VALUE
ブローカ構成ファイルに保存されているプロパティの値

8.2.3 LogXptStatus(REDO転送ステータス)

監視可能なプロパティLogXptStatusは、有効な各構成メンバーに対するREDO転送サービスのエラー・ステータスを含む表を戻します。このプロパティは、プライマリ・データベース、REDOデータを送信するフィジカル・スタンバイ・データベースまたは遠隔同期インスタンスに関係します。

この表の列は、次のとおりです。

- PRIMARY_INSTANCE_NAME
プライマリ・データベースのインスタンスのSIDを識別する値

- STANDBY_DATABASE_NAME
スタンバイ・データベースまたは遠隔同期インスタンスのデータベース一意名(DB_UNIQUE_NAME)

- ERROR
REDO転送エラーのテキスト。エラーがない場合、フィールドは空です。

表の各エントリは、1つのREDOソース上での、1つのREDO接続先へのREDO転送サービスのステータスを示します。

エラー・ステータスは空の文字列の場合もあります。これは、エラーがないことを示します。

次の例では、South_Sales接続先にはエラーがないので、South_SalesのSTATUSは空です。South_Report接続先は、ORA-01034メッセージを戻します。

DGMGRL> SHOW DATABASE 'North_Sales' 'LogXptStatus' ;
LOG TRANSPORT STATUS
PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME               STATUS
north_sales1          South_Sales
north_sales1          South_Report    ORA-01034: ORACLE not available

8.2.4 LsbyFailedTxnInfo(ロジカル・スタンバイ障害トランザクション情報)

監視可能なプロパティLsbyFailedTxnInfoは、ログ適用サービスの停止の原因となった障害トランザクションを識別します。このプロパティには、DBA_LOGSTDBY_EVENTSビューからの次の値で構成される文字列が含まれています。

- XIDUSN: トランザクションIDのUNDOセグメント番号

- XIDSLT: トランザクションIDのスロット番号

- XIDSQN: トランザクションIDの順序番号

- STATUS_CODE: STATUSメッセージ内のステータス(またはOracleエラー・コード)

- STATUS: プロセスの現行アクティビティの説明、またはログ適用サービスの停止理由

トランザクションIDとステータス情報は、番号記号の文字列(###)で区切られます。

これはロジカル・スタンバイ・データベース関連のプロパティです。

8.2.5 LsbyParameters(ロジカル・スタンバイ・パラメータ)

監視可能なプロパティLsbyParametersには、ログ適用サービス用に特別に予約されたMAX_SGA(最大システム・グローバル領域)およびMAX_SERVERS(パラレル問合せサーバーの最大数)の値を識別する文字列が含まれています。これらの値は、LsbyParametersプロパティ内で番号記号の文字列(###)で区切られます。

これはロジカル・スタンバイ・データベース関連のプロパティです。

8.2.6 RecvQEntries(受信キュー・エントリ)

監視可能なプロパティRecvQEntriesプロパティは、スタンバイ・データベースで受信済で、まだ適用されていないすべてのログ・ファイルを示す表を戻します。行が戻されていない場合は、受信されたすべてのログ・ファイルが適用済であることを意味します。これはスタンバイ・データベース関連のプロパティです。

この表には、次の順序で列が含まれています。

- STATUS
ロジカル・スタンバイ・データベース上のログ・ファイルの場合は、STATUS列が次のいずれかの値に設定されます。

- NOT_APPLIED: このログ・ファイル内のREDOレコードは適用されていません。

- PARTIALLY_APPLIED: このログ・ファイル内のREDOレコードのうち、一部は適用済で残りは適用されていません。

- COMMITTED_TRANSACTIONS_APPLIED: このステータス値は、ロジカル・スタンバイ・データベースにのみ適用されます。コミット済トランザクションに属するREDOレコードはすべて適用済です。コミットされていないトランザクションに属するREDOレコードは、LogMinerにより読み取られておらず、まだ将来トランザクションがコミットされるときに必要になる可能性があります。したがって、このオンラインREDOログ・ファイルはまだ安全に破棄できません。

- RESETLOGS_ID
アーカイブREDOログ・ファイルに関連付けられたリセットログ識別子。

- THREAD
REDOスレッド番号。

- LOG_SEQ
オンラインREDOログ・ファイルの順序番号。

- TIME_GENERATED
オンラインREDOログ・ファイルがプライマリ・データベースに初めて書き込まれた時刻。

- TIME_COMPLETED
ログ・ファイルがプライマリ・データベースに2度目にアーカイブされた時刻(NEXT_CHANGE#列に対応)。

- FIRST_CHANGE#
アーカイブREDOログ・ファイル内の最初の変更番号。

- NEXT_CHANGE#
次のログ・ファイル内の最初の変更番号。

- SIZE (KB)
オンラインREDOログ・ファイルのSIZE(KB単位)。

次に例を示します。

DGMGRL> SHOW DATABASE 'South_Sales' 'RecvQEntries' ;
STATUS     RESETLOGS_ID           THREAD
LOG_SEQ          TIME_GENERATED       TIME_COMPLETED    FIRST_CHANGE#
NEXT_CHANGE#        SIZE (KBs)
NOT_APPLIED        497198843                1                    5
06/20/2003 14:55:38  06/20/2003 16:31:26           202138
210718             7364
NOT_APPLIED        497198843                1                    6
06/20/2003 16:31:26  06/20/2003 16:31:39           210718
210753               13
NOT_APPLIED        497198843                1                    7
06/20/2003 16:31:39  06/20/2003 16:31:54           210753
210758                1
NOT_APPLIED        497198843                1                    8
06/20/2003 16:31:54  06/20/2003 16:31:59           210758
210789               11

注意:

Cloud Controlでは、「ログ・ファイルの詳細」ページにこの情報が表示されます。

8.2.7 SendQEntries(送信キュー・エントリ)

監視可能なプロパティSendQEntriesは、1つ以上のスタンバイ・データベースに正常にアーカイブされていない、プライマリ・データベース上のすべてのログ・ファイルを示す表を戻します。これはプライマリ・データベース関連のプロパティです。

この表の列は、次のとおりです。

- STANDBY_NAME
この値は空か、またはスタンバイ・データベースのデータベース一意名(DB_UNIQUE_NAME)になります。空の場合、STATUS列にはCURRENTまたはNOT_ARCHIVEDの値が含まれます。

- STATUS
STATUS列は、次のいずれかの値に設定されます。

- CURRENT: 現在オンラインREDOを書込み中のログ・ファイル。

- NOT_ARCHIVED: ローカルにアーカイブされていない、完了済のオンラインREDOログ・ファイル。

- ARCHIVED: ローカルにアーカイブされているが、STANDBY_NAME列で指定されたスタンバイ・データベースには転送されていない完了済ログ・ファイル。

この表には、STATUS=CURRENTの値を持つ行が1つのみ含まれます。値がSTATUS=ARCHIVEDまたはSTATUS=NOT_ARCHIVEDの行は複数含まれる場合があります。

- RESETLOGS_ID
アーカイブREDOログ・ファイルに関連付けられたリセットログ識別子。

- THREAD
REDOスレッド番号。

- LOG_SEQ
ログ順序番号。複数行に(異なるSTANDBY_NAME値について)同じLOG_SEQ値が含まれる場合があります。

- TIME_GENERATED
オンラインREDOログ・ファイルがプライマリ・データベースに初めて書き込まれた時刻。

- TIME_COMPLETED
ログ・ファイルがプライマリ・データベースに2度目にアーカイブされた時刻(NEXT_CHANGE#列に対応)。

- FIRST_CHANGE#
アーカイブREDOログ・ファイル内の最初の変更番号。

- NEXT_CHANGE#
次のログ・ファイル内の最初の変更番号。

- SIZE (KB)
オンラインREDOログ・ファイルのSIZE(KB単位)。

SHOW DATABASEコマンドの出力例を次に示します。

DGMGRL> SHOW DATABASE 'North_Sales' 'SendQEntries' ;
PRIMARY_SEND_QUEUE
STANDBY_NAME       STATUS     RESETLOGS_ID
THREAD              LOG_SEQ       TIME_GENERATED       TIME_COMPLETED
FIRST_CHANGE#     NEXT_CHANGE#       SIZE (KBs)
South_Sales   ARCHIVED        497198843
1                    9  06/20/2003 16:31:59  06/20/2003 16:39:57
210789           211411              186
South_Sales   ARCHIVED        497198843
1                   10  06/20/2003 16:39:57  06/20/2003 16:40:01
211411           211415                1
South_Sales   ARCHIVED        497198843
1                   11  06/20/2003 16:40:01  06/20/2003 16:40:07
211415           211418                1
CURRENT        497198843
1                   12  06/20/2003 16:40:07
211418                                 1

注意:

Cloud Controlでは、「ログ・ファイルの詳細」ページにこの情報が表示されます。

8.2.8 TopWaitEvents

監視可能なプロパティTopWaitEventsは、指定したインスタンス内で待機時間が最長のイベントを5つ指定します。イベントとその待機時間はV$SYSTEM_EVENTから取得されます。構成内のインスタンスごとに、このプロパティがあります。これは、インスタンス固有の監視可能なプロパティです。この表には、次の順序で列が含まれています。

- イベント
システム待機イベント

- 待機時間
このイベントが待機されていた時間の合計(0.01秒単位)

SHOW INSTANCEコマンドの出力例を次に示します。

DGMGRL> SHOW INSTANCE north_sales1 'TopWaitEvents';
TOP SYSTEM WAIT EVENTS
Event            Wait Time
rdbms ipc message               671350
SQL*Net message from client         62390
pmon timer                47897
Queue Monitor Wait                43016
wakeup time manager                38508

8.3 構成可能なプロパティ

構成可能なプロパティは、ブローカ構成内のメンバーの動作を制御します。これらのプロパティの値は、DGMGRLまたはCloud Controlを使用して表示し、動的に更新できます。ただし、一部のプロパティは、DGMGRLを使用しなければ更新できません。

これらのプロパティは、Oracle Data Guard Broker構成を管理するために使用されるいくつかのデータベース初期化パラメータとSQL文を制御します。したがって、これらの初期化パラメータを手動で設定したり、これらのSQL文をブローカ構成に発行しないでください。「ブローカが制御するデータベース初期化パラメータとSQL文」を参照してください。

ほとんどの場合、構成可能なプロパティはメンバー全体に適用されます。つまり、プロパティに対して設定した値は、データベースの各メンバー(データベースまたは遠隔同期インスタンス)に適用されます。ただし、一部の構成可能なプロパティにはインスタンス固有の有効範囲が設定されています。これは、一部の特定のプロパティの値が、複数インスタンスのデータベースまたは遠隔同期インスタンスでは、インスタンス間で異なる可能性があることを意味します。表8-1に、構成可能な各プロパティと、その有効範囲がメンバー単位かインスタンス固有かを示します。有効範囲列の意味は、次のとおりです。

- メンバー: プロパティの値はインスタンスや構成に固有ではなくデータベースまたは遠隔同期インスタンス単位です。

- インスタンス: プロパティの値はインスタンス固有です。
アスタリスク(*)は、EDIT INSTANCE * ON DATABASEコマンドを使用して、Oracle RACデータベースのすべてのインスタンスにプロパティ値を設定できることを示します。

- 構成: プロパティの値はインスタンスやメンバーに固有ではなく構成単位です。

表8-1 構成プロパティ

構成可能なプロパティの名前

有効範囲

関連先

AlternateLocation

インスタンス

REDO転送サービス

ApplyInstanceTimeout

メンバー

REDO ApplyおよびSQL Apply

ApplyLagThreshold

メンバー

REDO転送サービス

ApplyParallel

メンバー

REDO Apply

ArchiveLagTarget

メンバー

REDO転送サービス

Binding

メンバー

REDO転送サービス

DbFileNameConvert

メンバー

REDO Apply

DelayMins

メンバー

REDO ApplyおよびSQL Apply

DGConnectIdentifier

メンバー

ブローカ通信、REDO転送サービス

FastStartFailoverTarget

メンバー

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

LogArchiveFormat

インスタンス*

REDO転送サービス

LogArchiveMaxProcesses

メンバー

REDO転送サービス

LogArchiveMinSucceedDest

メンバー

REDO転送サービス

LogArchiveTrace

インスタンス*

診断

LogFileNameConvert

メンバー

REDO Apply

LogShipping

メンバー

REDO転送サービス

LogXptMode

メンバー

REDO転送サービス

LsbyMaxEventsRecorded

メンバー

SQL Apply

LsbyMaxServers

インスタンス*

SQL Apply

LsbyMaxSga

インスタンス*

SQL Apply

LsbyPreserveCommitOrder

メンバー

SQL Apply

LsbyRecordAppliedDdl

メンバー

SQL Apply

LsbyRecordSkipDdl

メンバー

SQL Apply

LsbyRecordSkipErrors

メンバー

SQL Apply

MaxConnections

メンバー

REDO転送サービス

MaxFailure

メンバー

REDO転送サービス

NetTimeout

メンバー

REDO転送サービス

ObserverConnectIdentifier

メンバー

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

PreferredApplyInstance

メンバー

REDO ApplyおよびSQL Apply

RedoCompression

メンバー

REDO転送サービス

RedoRoutes

メンバー

REDO転送サービス

ReopenSecs

メンバー

REDO転送サービス

SidName

インスタンス

インスタンス識別

StandbyArchiveLocation

インスタンス

REDO転送サービス

StandbyFileManagement

メンバー

REDO ApplyおよびSQL Apply

StaticConnectIdentifier

インスタンス

インスタンスの起動および停止

TransportDisconnectedThreshold

メンバー

REDO転送サービス

TransportLagThreshold

メンバー

REDO転送サービス

参照:

プロパティ管理の詳細は、「ブローカ構成のメンバーの管理」を参照

注意:

プライマリ・データベースとともにブローカ構成が作成され、メンバーが構成に追加されると、ブローカは、多数のプロパティを設定するために、メンバーから既存の設定をインポートします。既存の設定のインポートに失敗したり、プロパティ値がインポートされなかった場合、ブローカは、ブローカ・デフォルト値を使用します。プロパティがインポートされたかどうか、およびデフォルト値を、各プロパティの説明で示します。

ブローカが制御するデータベース初期化パラメータとSQL文

次のデータベース初期化パラメータは、構成可能なブローカ・プロパティによって制御されます。このため、これらのパラメータは手動で設定しないでください。

- LOG_ARCHIVE_DEST_n

- LOG_ARCHIVE_DEST_STATE_n

- ARCHIVE_LAG_TARGET

- DB_FILE_NAME_CONVERT

- LOG_ARCHIVE_FORMAT

- LOG_ARCHIVE_MAX_PROCESSES

- LOG_ARCHIVE_MIN_SUCCEED_DEST

- LOG_ARCHIVE_TRACE

- LOG_FILE_NAME_CONVERT

- STANDBY_FILE_MANAGEMENT

ブローカで適用の開始方法を管理する場合、構成可能なプロパティ設定も使用されます。このため、次のSQL文は、ブローカによって自動的に管理されます。

- ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

- ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE

次の適用パラメータは、ブローカにより自動的にロジカル・スタンバイ上に設定されます。手動で設定しないでください。

- MAX_EVENTS_RECORDED

- MAX_SERVERS

- MAX_SGA

- PRESERVE_COMMIT_ORDER

- RECORD_APPLIES_DDL

- RECORD_SKIP_DDL

- RECORD_SKIP_ERRORS

8.3.1 AlternateLocation

構成可能なプロパティAlternateLocationは、StandbyArchiveLocationで指定された位置に格納できない場合に、アーカイブREDOログ・ファイルの格納先としてスタンバイ内の代替ディスク位置を指定します。このプロパティの有効範囲はインスタンス固有であるため、指定する位置はインスタンスからアクセスできる必要があります。

カテゴリ

説明

データ型

文字列

有効値

スタンバイ・インスタンスがあるシステム上のディレクトリ指定

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

動的

ロール

スタンバイ・データベース、遠隔同期インスタンス

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

- スタンバイ・データベースまたは遠隔同期インスタンスの場合は、構成可能なプロパティStandbyArchiveLocationと一致するローカル宛先の代替宛先を表すLOG_ARCHIVE_DEST_n初期化パラメータのLOCATION属性。

有効範囲

インスタンス

Cloud Control名

スタンバイの代替場所

注意:

ロジカル・スタンバイ・データベースの場合は、ローカルの格納先を示すLOG_ARCHIVE_DEST_n初期化パラメータのLOCATION属性と構成可能なプロパティAlternateLocationの値には別の値を設定することをお薦めします。

8.3.2 ApplyInstanceTimeout

構成可能なプロパティApplyInstanceTimeoutは、現行の適用インスタンスの障害を検出してから適用インスタンスのフェイルオーバーを開始するまでの、ブローカの待機秒数を指定します。

カテゴリ

説明

データ型

整数

有効値

>=0(秒)

ブローカ・デフォルト

0(即時適用インスタンス・フェイルオーバーとなります)

インポート

不要

パラメータ・クラス

該当なし

ロール

スタンバイ

スタンバイ・タイプ

フィジカル、ロジカル

対応

該当なし

有効範囲

データベース

Cloud Control名

該当なし

8.3.3 ApplyLagThreshold

構成可能なプロパティApplyLagThresholdは、ロジカルまたはフィジカルのスタンバイでのメンバーの適用ラグがプロパティで指定された値を上回った場合の警告ステータスを生成します。プロパティ値を表す単位は秒です。値が0秒の場合、適用ラグが存在しても警告を生成しません。

カテゴリ

説明

データ型

数値

有効値

>=0

ブローカ・デフォルト

30秒

インポート

不要

パラメータ・クラス

該当なし

ロール

スタンバイ

スタンバイ・タイプ

フィジカル、ロジカル

対応

該当なし

有効範囲

データベース

Cloud Control名

該当なし

8.3.4 ApplyParallel

構成可能なプロパティApplyParallelは、REDO Applyがフィジカル・スタンバイ・データベースへのREDOデータの適用に複数のプロセスを使用する必要があるかどうかを指定します。REDO Applyが停止している場合は、プロパティを設定してもすぐには有効になりません。ただし、REDO Applyが再び実行中になったとき、このプロパティの値によって、REDO Applyのパラレル適用動作が決定します。

カテゴリ

説明

データ型

文字列

有効値

- AUTO: REDO Applyに使用されるパラレル・プロセスの数は、システムのCPU数に基づいてOracleにより自動的に判断されます。

- NO: パラレル適用を使用しません。

- 2、3など: Redo Applyに使用されるパラレル・プロセスの数を手動で指定します。(0の指定はNOの指定と同じです。1の指定はAUTOの指定と同じです。)

ブローカ・デフォルト

AUTO

インポート

不要

パラメータ・クラス

該当なし

ロール

スタンバイ

スタンバイ・タイプ

フィジカル

対応

- AUTOはALTER DATABASE RECOVER MANAGED STANDBY DATABASE文のPARALLEL句に対応

- NOはALTER DATABASE RECOVER MANAGED STANDBY DATABASE文のNOPARALLEL句に対応

- 2、3などの数値は、ALTER DATABASE RECOVER MANAGED STANDBY DATABASE文のPARALLEL n句に対応

有効範囲

データベース

Cloud Control名

該当なし

8.3.5 ArchiveLagTarget

構成可能なプロパティArchiveLagTargetは、指定した期間(秒単位)が経過した後にログ・スイッチを強制して、失われる可能性のあるデータ量を制限し、スタンバイ・データベースの可用性を向上させます。つまり、スタンバイ・データベースでは、ARCHIVE_LAG_TARGET初期化パラメータに設定された値を超える期間に生成されたREDOレコードは失われなくなります。

カテゴリ

説明

データ型

数値

有効値

秒(0秒、または60から7200秒の数値)

ブローカ・デフォルト

0(無効)

インポート

ARCHIVE_LAG_TARGET初期化パラメータからインポート

パラメータ・クラス

動的

ロール

プライマリ・データベース、遠隔同期インスタンス

スタンバイ・タイプ

該当なし

対応

ARCHIVE_LAG_TARGET=seconds初期化パラメータ

有効範囲

データベース

Cloud Control名

アーカイブ・タイムラグ・ターゲット

8.3.6 Binding

構成可能なプロパティBindingは、接続先がMANDATORYであるかOPTIONALであるかを指定します。

カテゴリ

説明

データ型

文字列

有効値

- MANDATORY
MANDATORY値を使用すると、オンラインREDOログ・ファイルの再利用ポリシーを指定できます。必須接続先のアーカイブ操作に失敗すると、オンラインREDOログ・ファイルを上書きできません。

- OPTIONAL
OPTIONAL値を使用すると、オンラインREDOログ・ファイルの再利用ポリシーを指定できます。オプションの接続先のアーカイブ操作に失敗すると、オンラインREDOログ・ファイルが上書きされます。

ブローカ・デフォルト

OPTIONAL

インポート

不要

パラメータ・クラス

動的

ロール

スタンバイ・データベース、遠隔同期インスタンス脚注 1

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n初期化パラメータのためのMANDATORYおよびOPTIONAL属性

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのV$ARCHIVE_DESTビューのBINDING列

有効範囲

データベース、遠隔同期インスタンス

Cloud Control名

該当なし

脚注1

このプロパティはREDO接続先に対して設定されていますが、間接的には、REDOデータを送信するデータベースまたは遠隔同期インスタンスのためのREDO転送サービスに関連しています。指定した設定は、ブローカにより、REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n値の対応する属性に伝播されます。

8.3.7 DbFileNameConvert

構成可能なプロパティDbFileNameConvertは、プライマリ・データファイルのファイル名からフィジカル・スタンバイ・データファイルのファイル名を識別します。プライマリ・データベースにデータファイルを追加すると、このプロパティによりプライマリ・データベース上のデータファイル名がフィジカル・スタンバイ・データベース上のデータファイルに変換されます。

このプロパティは、次の場合に使用されます。

- フィジカル・スタンバイのマウント時に、フィジカル・スタンバイ・システム上のデータファイルのパスがプライマリ・データベース・システムと異なる場合は、このプロパティを使用してプライマリ・データファイルのファイル名がスタンバイ・データファイルのファイル名に変更されます。

- プライマリ・データベース上で新規データ・ファイルが作成されるときに、構成可能なプロパティStandbyFileManagementがAUTOに設定されている場合は、対応する新規データ・ファイルがフィジカル・スタンバイ・データベース上に作成されます。Oracleでは、DbFileNameConvertプロパティからのデータファイルのファイル・パス・マッピング情報を使用して、新規スタンバイ・データファイルのスタンバイ・ファイル・パスが判別されます。StandbyFileManagementプロパティが'MANUAL'に設定されている場合は、対応するファイルをフィジカル・スタンバイ・データベースに追加する必要があります。

注意:

データベースが構成に追加されると、ブローカはこのプロパティの初期値をDB_FILE_NAME_CONVERT初期化パラメータのインメモリーの値に設定します。このパラメータのインメモリーの値とサーバー・パラメータ・ファイル(SPFILE)の値は異なる可能性があります。パラメータのインメモリーの値を使用する場合は、データベースを有効化し、ブローカによりパラメータのSPFILEの値がインメモリーの値に設定されることが保証されるようにします。SPFILEの値を使用する場合は、プロパティの値をSPFILEに格納されているパラメータの値に設定します。その後でデータベースを有効化します。

カテゴリ

説明

データ型

文字列

有効値

このパラメータの値は、次のように文字列ペアのリストに設定します。

1. 最初の文字列は、プライマリ・データベース上のデータファイル名に含まれるサブストリングです。

2. 2番目の文字列は、スタンバイ・データベース上のデータファイル名に含まれるサブストリングです。

たとえば、('string1', 'string2', 'string3', 'string4',...)とします。

各項目の意味は次のとおりです。

- string1はプライマリ・データベース・ファイル名のサブストリング

- string2はスタンバイ・データベース・ファイル名のサブストリング

- string3はプライマリ・データベース・ファイル名のサブストリング

- string4はスタンバイ・データベース・ファイル名のサブストリング

ブローカ・デフォルト

空の文字列

インポート

DB_FILE_NAME_CONVERT初期化パラメータからインポート

パラメータ・クラス

静的

ロール

スタンバイ

スタンバイ・タイプ

フィジカル

対応

DB_FILE_NAME_CONVERT初期化パラメータ

有効範囲

データベース

Cloud Control名

DBファイル名の変換

8.3.8 DelayMins

構成可能なプロパティDelayMinsは、ログ適用サービスで、スタンバイ・データベースでのアーカイブREDOログ・データの適用を遅延する時間(分)を指定します。DelayMinsプロパティがデフォルト値の0(分)に設定されている場合、ログ適用サービスは、REDOデータをできるかぎり速やかに適用します。

DelayMinsプロパティが0に設定されている場合は、ログ適用サービスを次の手順で開始します。

- 次のSQL文を使用して、フィジカル・スタンバイ・データベース上でREDO Applyを開始します。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

- 次のSQL文を使用して、ロジカル・スタンバイ・データベース上でSQL Applyを開始します。

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

カテゴリ

説明

データ型

整数

有効値

>=0 (分)脚注 2

ブローカ・デフォルト

0

インポート

不要

パラメータ・クラス

動的

ロール

スタンバイ脚注3

スタンバイ・タイプ

フィジカル、ロジカル

対応

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n初期化パラメータのためのDELAY属性

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのV$ARCHIVE_DESTビューのDELAY_MINS列

- REDO ApplyおよびSQL Applyの開始に使用するオプション

有効範囲

データベース

Cloud Control名

遅延の適用(分)

脚注 2 DelayMinsが0よりも大きい値に設定されているスタンバイにスイッチオーバーするには、事前にDelayMinsプロパティを0にリセットする必要があります。

脚注3

このプロパティはスタンバイ・データベースに対して設定されていますが、間接的には、REDOデータを送信するデータベースまたは遠隔同期インスタンスのためのREDO転送サービスに関連しています。スタンバイ・データベースに指定した設定は、ブローカにより、REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n値の対応する属性に伝播されます。

8.3.9 DGConnectIdentifier

構成可能なプロパティDGConnectIdentifierは、構成メンバーに接続をするときにブローカが使用する接続識別子を指定します。DGMGRLを使用する場合、CREATE CONFIGURATION、ADD DATABASEまたはADD FAR_SYNCコマンドを入力時に値を指定します。Cloud Controlを使用している場合、値は自動的に設定されます。構成メンバーの接続識別子は、次の条件を満たす必要があります。

- 構成内のその他すべてのメンバーからアクセスできます。

- メンバーは自分自身にアクセスできます。

- Oracle RACデータベースのすべてのインスタンスにアクセスできます。

- Oracle RACデータベース上の接続時フェイルオーバーを可能にするため、すべてのインスタンスが動的にリスナーに登録するサービスを指定します。

注意:
Oracle Clusterwareによって定義および管理されるサービスは指定できません。

- プライマリ・データベースのREDO転送サービスによるOracle RACスタンバイ・データベースへのREDOデータの転送が、そのスタンバイ・データベースの受信インスタンスでエラーが発生した場合でも続行されるようにフェイルオーバー属性が設定されています。

このプロパティの値は、ブローカがプライマリ・データベース上でREDO転送サービスを構成する際にLOG_ARCHIVE_DEST_nパラメータのSERVICE属性で指定されます。

カテゴリ

説明

データ型

文字列

有効値

このデータベースの接続に使用できる接続識別子

ブローカ・デフォルト

該当なし

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリ、スタンバイ、遠隔同期インスタンス

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

REDOデータを送信する構成メンバーのLOG_ARCHIVE_DEST_n初期化パラメータのためのSERVICE_NAME属性

有効範囲

データベース、遠隔同期インスタンス

Cloud Control名

該当なし

参照:

『Oracle Database Net Services管理者ガイド』

8.3.10 FastStartFailoverTarget

FastStartFailoverTarget構成プロパティは、このデータベースがプライマリ・データベースの場合、ファスト・スタート・フェイルオーバーのターゲットになるデータベースのDB_UNIQUE_NAMEを指定します。このプロパティの設定方法の詳細は、「ファスト・スタート・フェイルオーバーの有効化」の手順2を参照してください。

FastStartFailoverTargetプロパティには、フィジカル・スタンバイまたはロジカル・スタンバイの名前のみを設定できます。スナップショット・スタンバイ・データベースまたは遠隔同期インスタンスの名前にすることはできません。

カテゴリ

説明

データ型

文字列

有効値

ファスト・スタート・フェイルオーバーのターゲットとなるデータベースのDB_UNIQUE_NAME

ブローカ・デフォルト

フィジカルまたはロジカル・スタンバイ・データベースが1つのみ存在している場合、ブローカはそのデータベースを、ファスト・スタート・フェイルオーバーが有効化されたときに、プライマリ・データベースのこのプロパティのデフォルト値として選択します。

複数のフィジカルまたはロジカル・スタンバイ・データベースが存在する場合は、ファスト・スタート・フェイルオーバーを有効化する前に、このFastStartFailoverTargetの値を明示的に指定する必要があります。ファスト・スタート・フェイルオーバーが有効化されると、指定されたターゲットが検証されます。

ターゲット・スタンバイ・データベース側では、ブローカは、ファスト・スタート・フェイルオーバーが有効化されたときに自動的に、このプロパティの値として現在のプライマリ・データベースを選択します。

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリまたはスタンバイ

スタンバイ・タイプ

フィジカルまたはロジカル

対応

該当なし

有効範囲

データベース

Cloud Control名

Cloud Controlでは、Oracle Data Guardの概要ページに、ファスト・スタート・フェイルオーバーが有効化されているかどうかの情報とともに、現在のプライマリ・データベースの値が表示されます。

8.3.11 LogArchiveFormat

構成可能なインスタンス固有のプロパティLogArchiveFormatは、データベースID(%d)、スレッド(%t)、順序番号(%s)およびリセットログID(%r)を使用して、アーカイブREDOログ・ファイルのファイル名の書式を指定します。

注意:

メンバーが構成に追加されると、ブローカはこのプロパティの初期値をLOG_ARCHIVE_FORMAT初期化パラメータのインメモリーの値に設定します。このパラメータのインメモリーの値とサーバー・パラメータ・ファイル(SPFILE)の値は異なる可能性があります。パラメータのインメモリーの値を使用する場合は、メンバーを有効化し、ブローカによりパラメータのSPFILEの値がインメモリーの値に設定されることが保証されるようにします。SPFILEの値を使用する場合は、プロパティの値をSPFILEに格納されているパラメータの値に設定します。その後で、メンバーを有効にします。

カテゴリ

説明

データ型

文字列

有効値

%d_%t_%s_%r

ブローカ・デフォルト

空の文字列

インポート

プライマリ・データベースのLOG_ARCHIVE_FORMAT初期化パラメータからインポート

パラメータ・クラス

静的

ロール

プライマリ、スタンバイ、遠隔同期インスタンス

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

LOG_ARCHIVE_FORMAT初期化パラメータ

有効範囲

インスタンス(Oracle RACデータベースでは、EDIT INSTANCE * ON DATABASEコマンドを使用して、すべてのインスタンスでこのプロパティに同じ値を指定することができます。)

Cloud Control名

該当なし

8.3.12 LogArchiveMaxProcesses

構成可能なプロパティLogArchiveMaxProcessesは、最初に起動されたアーカイバ・プロセス数(ARCn)を指定します。使用されるアーカイバ・プロセスの実際の数は、アーカイブのワークロードに基づき後で増える場合があります。

カテゴリ

説明

データ型

整数

有効値

1から30

ブローカ・デフォルト

4

インポート

LOG_ARCHIVE_MAX_PROCESSES初期化パラメータからインポート

パラメータ・クラス

動的

ロール

プライマリ、スタンバイ、遠隔同期インスタンス

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

LOG_ARCHIVE_MAX_PROCESSES初期化パラメータ

有効範囲

データベース、遠隔同期インスタンス

Cloud Control名

アーカイバ・プロセス

8.3.13 LogArchiveMinSucceedDest

構成可能なプロパティLogArchiveMinSucceedDestは、オンラインREDOログ・ファイルが再利用可能になる時期を制御します。オンラインREDOログ・ファイルが再利用可能になるには、最小数のアーカイブ先に対するアーカイブが正常終了する必要があります。

カテゴリ

説明

データ型

整数

有効値

1から10

ブローカ・デフォルト

1

インポート

LOG_ARCHIVE_MIN_SUCCEED_DEST初期化パラメータからインポート

パラメータ・クラス

動的

ロール

プライマリ・データベース、遠隔同期インスタンス

スタンバイ・タイプ

該当なし

対応

LOG_ARCHIVE_MIN_SUCCEED_DEST初期化パラメータ

有効範囲

データベース、遠隔同期インスタンス

Cloud Control名

該当なし

8.3.14 LogArchiveTrace

構成可能なインスタンス固有のプロパティLogArchiveTraceを整数値に設定して、プライマリ・データベースとスタンバイ・データベースでのオンラインREDOログ・ファイルのアーカイブの進行状況を確認します。Oracleデータベースでは、プライマリ・データベースから受け取ったアーカイブREDOログ・ファイルの監査証跡がプロセス・トレース・ファイルに書き込まれます。

カテゴリ

説明

データ型

整数

有効値

有効値は、次の任意の値の組合せです。

0: アーカイブREDOログのトレースの無効化

1: オンラインREDOログ・ファイルのアーカイブの追跡

2: 各アーカイブREDOログ接続先のアーカイブ・ステータスの追跡

4: アーカイブ操作フェーズの追跡

8: ARCHIVELOG接続先のアクティビティの追跡

16: ARCHIVELOG接続先のアクティビティ詳細の追跡

32: ARCHIVELOG接続先のパラメータ変更の追跡

64: ARCnプロセスの状態アクティビティの追跡

128: FAL(フェッチ・アーカイブ・ログ)サーバー関連のアクティビティの追跡

256: RFSロジカル・クライアントの追跡

512: LGWR REDO送信ネットワーク・アクティビティの追跡

1024: RFSフィジカル・クライアントの追跡

2048: RFS/ARCnのpingハートビートの追跡

4096: リアルタイム適用活動の追跡

8192: REDO Applyの追跡(メディア・リカバリまたはフィジカル・スタンバイ)

16384: アーカイブI/Oバッファを追跡します。

32768: LogMinerディクショナリのアーカイブを追跡します。

ブローカ・デフォルト

255

インポート

LOG_ARCHIVE_TRACE初期化パラメータからインポート

パラメータ・クラス

動的

ロール

プライマリ、スタンバイ、遠隔同期インスタンス

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

LOG_ARCHIVE_TRACE初期化パラメータ

有効範囲

インスタンス(Oracle RACデータベースでは、EDIT INSTANCE * ON DATABASEコマンドを使用して、すべてのインスタンスでこのプロパティに同じ値を指定することができます。)

Cloud Control名

ログ・アーカイブ・トレース

8.3.15 LogFileNameConvert

構成可能なプロパティLogFileNameConvertは、プライマリ・データベースのオンラインREDOログ・ファイルのファイル名を、フィジカル・スタンバイ・データベースの対応するオンラインREDOログ・ファイルのファイル名に変換します。

注意:

データベースが構成に追加されると、ブローカはこのプロパティの初期値をLOG_FILE_NAME_CONVERT初期化パラメータのインメモリーの値に設定します。このパラメータのインメモリーの値とサーバー・パラメータ・ファイル(SPFILE)の値は異なる可能性があります。パラメータのインメモリーの値を使用する場合は、データベースを有効化し、ブローカによりパラメータのSPFILEの値がインメモリーの値に設定されることが保証されるようにします。SPFILEの値を使用する場合は、プロパティの値をSPFILEに格納されているパラメータの値に設定します。その後でデータベースを有効化します。

カテゴリ

説明

データ型

文字列

有効値

このパラメータの値を、偶数個の文字列ペアのカンマで区切ったリストに設定します。

1. 最初の文字列は、プライマリ・データベース上のデータファイル名に含まれるサブストリングです。

2. 2番目の文字列は、スタンバイ・データベース上のデータファイル名に含まれるサブストリングです。

たとえば、('string1', 'string2', 'string3', 'string4',...)とします。

各項目の意味は次のとおりです。

- string1はプライマリ・データベース・ファイル名のサブストリング

- string2はスタンバイ・データベース・ファイル名のサブストリング

- string3はプライマリ・データベース・ファイル名のサブストリング

- string4はスタンバイ・データベース・ファイル名のサブストリング

ブローカ・デフォルト

空の文字列

インポート

される(LOG_FILE_NAME_CONVERT初期化パラメータからのインポート)

パラメータ・クラス

静的

ロール

スタンバイ

スタンバイ・タイプ

物理データベースと遠隔同期インスタンス

対応

LOG_FILE_NAME_CONVERT初期化パラメータ

有効範囲

データベース

Cloud Control名

ログ・ファイル名の変換

8.3.16 LogShipping

プライマリ・データベースがTRANSPORT-ON状態にあるか、フィジカル・スタンバイまたは遠隔同期インスタンスが別のメンバー(フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス)にREDOデータを転送する場合、ブローカはLogShippingプロパティの値を使用します。

- プライマリ・データベースがTRANSPORT-ON状態で、LogShippingプロパティの値がONの場合は、REDO転送サービスによる特定構成メンバーへのREDOデータの送信が有効化されます。LogShippingプロパティがOFFの場合は、そのメンバーへのREDO転送サービスが無効化されます。

- REDOデータを転送する構成メンバーのLogShippingプロパティがONに設定されていて、REDOデータ送信先のメンバーでもLogShippingプロパティがONに設定されている場合、REDOデータを送信するメンバーからREDOデータを受信するメンバーへのREDO転送サービスが有効化されます。
REDOデータを転送するメンバーのLogShippingプロパティがONに設定されているが、REDOデータ送信先のメンバーではLogShippingプロパティがOFFに設定されている場合、REDOデータを送信するメンバーからREDOデータを受信するメンバーへのREDO転送サービスは無効化されます。

カテゴリ

説明

データ型

文字列

有効値

ONまたはOFF

ブローカ・デフォルト

ON

インポート

不要

パラメータ・クラス

動的

ロール

スタンバイ・データベース、遠隔同期インスタンス脚注 4

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_STATE_n初期化パラメータのENABLEおよびDEFER値

有効範囲

データベース

Cloud Control名

ログ送信

脚注4

このプロパティはスタンバイ・データベースまたは遠隔同期インスタンスに対して設定されますが、REDOデータを送信するデータベースまたは遠隔同期インスタンスのREDO転送サービスには間接的に関係します。スタンバイ・データベースに指定した設定は、ブローカにより、REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n値の対応する属性に伝播されます。

8.3.17 LogXptMode

構成可能なプロパティLogXptModeでは、REDO転送サービスを設定できます。各構成メンバー上で、REDO転送サービスを次のモードのいずれかに設定してください。

- SYNC
この構成メンバーに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのSYNCおよびAFFIRM属性を使用して構成します。スタンバイREDOログ・ファイルが必要です。データ保護モードが最大保護、最大可用性の場合はこのモードを設定する必要があります。このREDO転送サービスでは、プライマリ・データベースに対して最高レベルのデータ保護が可能ですが、パフォーマンスへの影響も最大になります。

- ASYNC
この構成メンバーに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのASYNCおよびNOAFFIRM属性を使用して構成します。スタンバイREDOログ・ファイルが必要です。このモードではプライマリ・データベースに対して適度なレベルのデータ保護が可能になり、SYNCに比べるとパフォーマンスへの影響も小さくなります。

- FASTSYNC
この構成メンバーに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのSYNCおよびNOAFFIRM属性を使用して構成します。このモードは、最大可用性保護モードでのみ利用できます。FASTSYNC転送モードはLOG_ARCHIVE_DEST_nパラメータのNOAFFIRM属性を使用するため、データが失われる可能性があります。

カテゴリ

説明

データ型

文字列

有効値

SYNC、ASYNCまたはFASTSYNC

ブローカ・デフォルト

ASYNC

インポート

不要

パラメータ・クラス

動的

ロール

スタンバイ・データベースおよび遠隔同期インスタンス脚注5

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n初期化パラメータのためのSYNC、ASYNC、AFFIRMまたはNOAFFIRM属性

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのV$ARCHIVE_DESTビューのARCHIVER、TRANSMIT_MODEおよびAFFIRM列

有効範囲

データベース、遠隔同期インスタンス

Cloud Control名

REDOトランスポート・サービス

脚注5

このプロパティはスタンバイ・データベースまたは遠隔同期インスタンスに対して設定されますが、REDOデータを送信するデータベースまたは遠隔同期インスタンスのREDO転送サービスには間接的に関係します。ブローカは、スタンバイ・データベースまたは遠隔同期インスタンス上で指定した構成を、REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n値にある、対応する属性に伝播します。RedoRoutesプロパティがREDO転送モードに構成されている場合に、データベースがデータベースまたは遠隔同期インスタンスからREDOを受け取ると、そのRedoRoutesプロパティ値で指定されたモードはLogXptModeプロパティの値をオーバーライドする点に注意してください。

参照:

REDO転送サービスのデータ保護モードの設定方法の詳細は、「ブローカ構成のメンバーの管理」を参照してください

8.3.18 LsbyMaxEventsRecorded

構成可能なプロパティLsbyMaxEventsRecordedは、ロジカル・スタンバイのイベント情報が格納されているDBA_LOGSTDBY_EVENTS表に格納するイベントの数を指定します。

カテゴリ

説明

データ型

整数

有効値

>=0

ブローカ・デフォルト

0

インポート

SYSTEM.LOGSTDBY$PARAMETERSのMAX_EVENTS_RECORDED行からインポート

パラメータ・クラス

動的。SQL Applyには再起動は必要ではありません。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED')およびDBMS_LOGSTDBY.APPLY_UNSET('MAX_EVENTS_RECORDED')プロシージャ

有効範囲

データベース

Cloud Control名

最大記録済イベント数

8.3.19 LsbyMaxServers

構成可能なインスタンス固有のプロパティLsbyMaxServersは、SQL Applyのために確保されたパラレル問合せサーバー数を指定します。値が0(ゼロ)の場合、SQL Applyは使用可能なすべてのパラレル問合せサーバーを使用して、ログ・ファイルを読み取り、変更を適用します。

カテゴリ

説明

データ型

整数

有効値

>=0

ブローカ・デフォルト

0

インポート

SYSTEM.LOGSTDBY$PARAMETERSのMAX_SERVERS行からインポート

パラメータ・クラス

動的。SQL Applyには再起動は必要ではありません。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS')およびDBMS_LOGSTDBY.APPLY_UNSET('MAX_SERVERS')プロシージャ

有効範囲

インスタンス(Oracle RACデータベースでは、EDIT INSTANCE * ON DATABASEコマンドを使用して、すべてのインスタンスでこのプロパティに同じ値を指定することができます。)

Cloud Control名

最大サーバー数

8.3.20 LsbyMaxSga

構成可能なインスタンス固有のプロパティLsbyMaxSgaは、システム・グローバル領域(SGA)内でSQL Applyキャッシュ用に割り当てるMB数を指定します。値が0(ゼロ)の場合、SQL ApplyはSHARED_POOL_SIZE初期化パラメータに設定された値の4分の1を使用します。

カテゴリ

説明

データ型

整数

有効値

>=0

ブローカ・デフォルト

0

インポート

SYSTEM.LOGSTDBY$PARAMETERSのMAX_SGA行からインポート

パラメータ・クラス

動的。SQL Applyには再起動は必要ではありません。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.APPLY_SET('MAX_SGA')およびDBMS_LOGSTDBY.APPLY_UNSET('MAX_SGA')プロシージャ

有効範囲

インスタンス(Oracle RACデータベースでは、EDIT INSTANCE * ON DATABASEコマンドを使用して、すべてのインスタンスでこのプロパティに同じ値を指定することができます。)

Cloud Control名

最大SGA(MB)

8.3.21 LsbyPreserveCommitOrder

構成可能なプロパティLsbyPreserveCommitOrderは、プライマリ・データベースでコミットされた順序と同じ順序でトランザクションがロジカル・スタンバイ・データベースにコミットされるかどうかを制御します。次のいずれかの値を指定します。

- TRUE: トランザクションは、プライマリ・データベースでコミットされた順序と同じ順序でロジカル・スタンバイ・データベースに適用されます。

- FALSE: オーバーラップしていない行セットが含まれるトランザクションは、プライマリ・データベースでコミットされた順序とは異なる順序でコミットされる場合があります。

カテゴリ

説明

データ型

文字列

有効値

TRUEまたはFALSE

ブローカ・デフォルト

TRUE

インポート

SYSTEM.LOGSTDBY$PARAMETERSのPRESERVE_COMMIT_ORDER行からインポート

パラメータ・クラス

静的。SQL Applyには再起動が必要です。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER')およびDBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER')プロシージャ

有効範囲

データベース

Cloud Control名

コミット順序を保持

8.3.22 LsbyRecordAppliedDdl

構成可能なプロパティLsbyRecordAppliedDdlは、ロジカル・スタンバイ・データベースに適用されたSQL文をDBA_LOGSTDBY_EVENTS表に記録するかどうかを制御します。次のいずれかの値を指定します。

- TRUE: ロジカル・スタンバイ・データベースに適用されたDDL文はDBA_LOGSTDBY_EVENTS表に記録されます。このモードがデフォルトの設定です。

- FALSE: 適用したDDL文は記録されません。

カテゴリ

説明

データ型

文字列

有効値

TRUEまたはFALSE

ブローカ・デフォルト

TRUE

インポート

SYSTEM.LOGSTDBY$PARAMETERSのRECORD_APPLIED_DDL行からインポート

パラメータ・クラス

動的。SQL Applyには再起動は必要ではありません。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.APPLY_SET('RECORD_APPLIED_DDL')およびDBMS_LOGSTDBY.APPLY_UNSET('RECORD_APPLIED_DDL')プロシージャ

有効範囲

データベース

Cloud Control名

レコード適用DDL

8.3.23 LsbyRecordSkipDdl

構成可能なプロパティLsbyRecordSkipDdlは、スキップしたDDL文をDBA_LOGSTDBY_EVENTS表に記録するかどうかを制御します。次のいずれかの値を指定します。

- TRUE: スキップしたDDL文がDBA_LOGSTDBY_EVENTS表に記録されます。このモードがデフォルトの設定です。

- FALSE: スキップしたDDL文はDBA_LOGSTDBY_EVENTS表に記録されません。

カテゴリ

説明

データ型

文字列

有効値

TRUEまたはFALSE

ブローカ・デフォルト

TRUE

インポート

SYSTEM.LOGSTDBY$PARAMETERSのRECORD_SKIP_DDL行からインポート

パラメータ・クラス

動的。SQL Applyには再起動は必要ではありません。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.APPLY_SET('RECORD_SKIP_DDL')およびDBMS_LOGSTDBY.APPLY_UNSET('RECORD_SKIP_DDL')プロシージャ

有効範囲

データベース

Cloud Control名

レコード・スキップDDL

8.3.24 LsbyRecordSkipErrors

構成可能なプロパティLsbyRecordSkipErrorsは、スキップしたエラー(DBMS_LOGSTDBY.SKIP_ERRORプロシージャを参照)をDBA_LOGSTDBY_EVENTS表に記録するかどうかを制御します。次のいずれかの値を指定します。

- TRUE: スキップしたエラーがDBA_LOGSTDBY_EVENTS表に記録されます。

- FALSE: スキップしたエラーはDBA_LOGSTDBY_EVENTS表に記録されません。

カテゴリ

説明

データ型

文字列

有効値

TRUEまたはFALSE

ブローカ・デフォルト

TRUE

インポート

SYSTEM.LOGSTDBY$PARAMETERSのRECORD_SKIP_ERRORS行からインポート

パラメータ・クラス

動的。SQL Applyには再起動は必要ではありません。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.APPLY_SET('RECORD_SKIP_ERRORS')およびDBMS_LOGSTDBY.APPLY_UNSET('RECORD_SKIP_ERRORS')プロシージャ

有効範囲

データベース

Cloud Control名

レコード・スキップ・エラー

8.3.25 MaxConnections

構成可能プロパティMaxConnectionsは、データベースまたは遠隔同期インスタンスの単一のアーカイブREDOログからリモート・サイトのアーカイブREDOログにREDOデータを転送するために同時にいくつのARCnプロセスを使用するかを指定します。MaxConnectionsプロパティが1よりも大きい値に設定されている場合、REDO転送サービスでは、複数のARCnプロセスを使用してREDOデータをリモートの保存先のアーカイブREDOログ・ファイルに転送します。

カテゴリ

説明

データ型

整数

有効値

1から20

ブローカ・デフォルト

1

インポート

不要

パラメータ・クラス

動的

ロール

スタンバイ

スタンバイ・タイプ

フィジカル、ロジカル、スナップショット

対応

- LOG_ARCHIVE_MAX_PROCESSES初期化パラメータ脚注 6

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n初期化パラメータのためのMAX_CONNECTIONS属性

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのV$ARCHIVE_DESTビューのMAX_CONNECTIONS列

有効範囲

データベース

Cloud Control名

該当なし

脚注6

LOG_ARCHIVE_MAX_PROCESSES初期化パラメータは、インスタンスが実際に使用するARCnプロセスの数に影響します。

8.3.26 MaxFailure

構成可能なプロパティMaxFailureは、連続してアーカイブに失敗する最大許容数を指定します。この回数を超えると、REDO転送サービスにより、スタンバイ・データベースへのアーカイブREDOログ・ファイルの転送が停止されます。値が0(ゼロ)の場合は、障害の発生が無制限に許容されることを示します。

カテゴリ

説明

データ型

整数

有効値

>=0

ブローカ・デフォルト

0

インポート

不要

パラメータ・クラス

動的

ロール

スタンバイ脚注7

スタンバイ・タイプ

フィジカル、ロジカル、スナップショット

対応

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n初期化パラメータのためのMAX_FAILURE属性

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのV$ARCHIVE_DESTビューのMAX_FAILURE列

有効範囲

データベース

Cloud Control名

該当なし

脚注7

このプロパティはスタンバイ・データベースまたは遠隔同期インスタンスに対して設定されますが、REDOデータを送信するデータベースまたは遠隔同期インスタンスのREDO転送サービスには間接的に関係します。ブローカは、スタンバイ・データベースまたは遠隔同期インスタンス上で指定した構成を、REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n値にある、対応する属性に伝播します。

8.3.27 NetTimeout

構成可能なプロパティNetTimeoutは、Oracle Net ServicesがLGWR要求に応答するまでLGWRが待機する秒数を指定します。このプロパティを使用して、TCPでの長い接続タイムアウトが迂回されます。

カテゴリ

説明

データ型

整数

有効値

0、15から1200

ブローカ・デフォルト

30

インポート

不要

パラメータ・クラス

動的

ロール

プライマリ、スタンバイ、遠隔同期インスタンス

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n初期化パラメータのNET_TIMEOUT属性

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのV$ARCHIVE_DESTビューのNET_TIMEOUT列

有効範囲

データベース、遠隔同期インスタンス

Cloud Control名

該当なし

8.3.28 ObserverConnectIdentifier

構成可能なプロパティObserverConnectIdentifierは、このデータベースとの接続のためにオブザーバが使用できる接続識別子を指定します。ファスト・スタート・フェイルオーバーが有効化されている場合は、プライマリ・データベースまたはターゲット・スタンバイ・データベースにのみ関連があります。

カテゴリ

説明

データ型

文字列

有効値

このデータベースの接続にオブザーバが使用できる接続識別子

ブローカ・デフォルト

空の文字列脚注 8

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

フィジカルまたはロジカル

対応

該当なし

有効範囲

データベース

Cloud Control名

オブザーバの接続識別子

脚注8

空の文字列である場合(ユーザーが設定しなかった場合)、このデータベースのDGConnectIdentifierプロパティで指定された接続識別子がオブザーバによって使用されます。

8.3.29 PreferredApplyInstance

構成可能なプロパティPreferredApplyInstanceは、特定のインスタンスがログ適用サービス提供に関して優先候補であることを示します。このプロパティを使用するのは、スタンバイOracle RACデータベースの場合のみです。空の文字列(デフォルト)を指定できます。この場合、ブローカでは適用インスタンスが選択されます。

カテゴリ

説明

データ型

文字列

有効値

インスタンス名(SID)または空の文字列。特定のプラットフォームでは、SIDの大/小文字が区別される場合があることに注意してください。

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

該当なし

ロール

スタンバイ

スタンバイ・タイプ

フィジカルまたはロジカル

対応

該当なし

有効範囲

データベース

Cloud Control名

適用インスタンス

参照:

- SIDの詳細は、『Oracle Database管理者ガイド』を参照してください。

- Oracle RAC環境での適用サービスの詳細は、「Oracle RACデータベース環境での適用サービス」を参照してください

8.3.30 RedoCompression

構成可能プロパティRedoCompressionは、スタンバイ・データベースまたは遠隔同期インスタンスに転送されるREDOデータが圧縮形式か非圧縮形式かを指定します。

注意:

REDO転送圧縮は、Oracle Advanced Compressionオプションの機能です。REDO転送圧縮機能を使用する前にこのオプションのライセンスを購入する必要があります。

カテゴリ

説明

データ型

文字列

有効値

DISABLEまたはENABLE

ブローカ・デフォルト

DISABLE

インポート

不要

パラメータ・クラス

動的

ロール

スタンバイ・データベース、遠隔同期インスタンス脚注 9

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n初期化パラメータのためのCOMPRESSION属性

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのV$ARCHIVE_DESTビューのCOMPRESSION列

有効範囲

データベース、遠隔同期インスタンス

Cloud Control名

該当なし

脚注9

このプロパティはスタンバイ・データベースまたは遠隔同期インスタンスに対して設定されますが、REDOデータを送信するデータベースまたは遠隔同期インスタンスのREDO転送サービスには間接的に関係します。ブローカは、スタンバイ・データベースまたは遠隔同期インスタンス上で指定した構成を、REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n値にある、対応する属性に伝播します。

8.3.31 RedoRoutes

デフォルトでは、プライマリ・データベースは、生成したREDOを構成内のすべての他のREDO転送先に送信します。RedoRoutesプロパティを使用すると、より複雑なREDO転送トポロジを作成することができます。たとえば、フィジカル・スタンバイ・データベースまたは遠隔同期インスタンスが、プライマリ・データベースから受け取ったREDOを1つ以上の接続先に転送するものや、指定された接続先に対して使用されるREDO転送モードが、どのデータベースがプライマリ・ロールであるかによって異なるものなどです。

RedoRoutesプロパティは、1つ以上のREDOルーティング・ルールを含む文字列に設定されます。各ルールは、1つ以上のREDOソースと1つ以上のREDO接続先を含みます。REDOルーティング・ルールは、ルール内のREDOソースの1つがプライマリ・ロールであるときにアクティブになります。結果的に、プライマリ・データベースからのREDOは、ルール内のすべてのREDO接続先に送信されます。

カテゴリ

説明

データ型

文字列

有効値

それぞれ1組のカッコ内に含まれる、1つ以上のREDOルーティング・ルールを含む文字列:

(redo_routing_rule_1) [(redo_routing_rule_n)]

REDOルーティング・ルールの詳細は、「REDOルーティング・ルール」を参照してください。

ブローカ・デフォルト

Null

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリ、スタンバイ、遠隔同期インスタンス

スタンバイ・タイプ

フィジカル・スタンバイと遠隔同期インスタンス

対応

LOG_ARCHIVE_DEST_n

有効範囲

データベース、遠隔同期インスタンス

Cloud Control名

RedoRoutes

8.3.31.1 REDOルーティング・ルール

redo routing ruleには、redo sourceフィールドとredo destinationフィールドが含まれ、それらはコロンで区切られます。

(redo source : redo destination)

redo sourceフィールドには、キーワードLOCAL、ANY、またはDB_UNIQUE_NAME値のカンマ区切りリストが含まれる必要があります。

{LOCAL | ANY | db_unique_name_1,[,db_unique_name_n]}

- キーワードLOCALは、ローカル・データベース名の別名です。このキーワードは、遠隔同期インスタンスでは使用できません。

- ANYキーワードは、構成内の任意のデータベースの別名です。

- 1つのデータベースは、明示的にも、暗黙的(LOCALキーワードを使用)にも、指定されたデータベースで定義されている複数のREDOルーティング・ルールにおけるREDOソースとして指定することはできません。

redo destinationフィールドには、キーワードALL、またはデータベース名のカンマ区切りリストが含まれる必要があります。それぞれに続けて、オプションでREDO転送属性を指定することができます。

{ALL [attribute] | db_unique_name_1 [attribute] [,db_unique_name_n [attribute]]}

ALLキーワードは、構成において可能なすべての接続先の別名です。

オプションのREDO転送属性(attribute)は、REDOを関連の接続先に送信するために使用するREDO転送モードを指定します。可能な値は、次の3つの値のいずれかです。

[ASYNC | SYNC | FASTSYNC]

REDO転送属性(attribute)を指定しない場合、使用されるREDO転送モードは、その接続先のLogXptModeプロパティで指定されたものになります。

RedoRoutesプロパティを使用して、代替リモート宛先を設定することもできます。これを行うには、ALTキーワードを使用します。

[ALT=(alternate db_unique_name [ASYNC | SYNC | FASTSYNC] [FALLBACK])]

ALTキーワードは、非代替メンバーへのREDOデータの送信時に問題が発生した場合にREDOデータを直接送信できる構成の別(代替)メンバーのDB_UNIQUE_NAMEを受け入れます。オプションのFALLBACKキーワードを指定した場合、非代替メンバーへのREDO送信は可能になった時点で再開されます。FALLBACKキーワードを使用することをお薦めします。それを省略し、その後にALTERNATE REDO転送先に障害が発生すると、代替転送先によりサービスが提供されるターミナル・スタンバイ・データベースにREDOが送信されません。

次の使用上の注意が適用されます。

- RedoRoutesプロパティのデフォルト値はNULLです。プライマリ・データベースは、(LOCAL : ALL )として扱われます。

- REDOルーティング・ルールがアクティブになるのは、そのREDOソース・フィールドで現在のプライマリ・データベースが指定されている場合です。ルールがアクティブになっている場合、プライマリ・データベースのREDOは、ルールが定義されているデータベースによって、そのルールのREDO接続先フィールドで指定されている各接続先に送信されます。

- カスケード接続先で、その接続先へのリアルタイム・カスケーディングを有効にするには、ASYNCREDO転送属性を明示的に指定する必要があります。

- RedoRoutesプロパティは、ロジカルまたはスナップショットのスタンバイ・データベースでは設定できません。

- ロジカル・スタンバイ・データベースにRedoRoutesプロパティを設定できるのは、REDO宛先フィールドがLOCALに設定されている場合のみです。

- 代替を指定するためには、非代替メンバーで、その構成可能なプロパティMaxFailureがゼロ以外の値になっている必要があります。

8.3.32 ReopenSecs

構成可能なプロパティReopenSecsは、アーカイバ・プロセス(ARCn、フォアグラウンドまたはログ・ライター・プロセス)が、以前失敗した宛先に再度アクセスしようとするまでの最小時間(秒)を指定します。

カテゴリ

説明

データ型

整数

有効値

>=0(秒)

ブローカ・デフォルト

300

インポート

不要

パラメータ・クラス

動的

ロール

スタンバイ・データベース、遠隔同期インスタンス脚注 10

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n初期化パラメータのためのREOPEN属性

- REDOデータを送信するデータベースまたは遠隔同期インスタンスのV$ARCHIVE_DESTビューのREOPEN_SECS列

有効範囲

データベース、遠隔同期インスタンス

Cloud Control名

該当なし

脚注10

このプロパティはスタンバイ・データベースまたは遠隔同期インスタンスに対して設定されますが、REDOデータを送信するデータベースまたは遠隔同期インスタンスのREDO転送サービスには間接的に関係します。ブローカは、スタンバイ・データベースまたは遠隔同期インスタンス上で指定した構成を、REDOデータを送信するデータベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n値にある、対応する属性に伝播します。

8.3.33 SidName

構成可能なプロパティSidNameは、インスタンスのOracleシステム識別子(SID)を指定します。このプロパティは、データベースのブローカ管理が無効化されている場合にのみ更新できます。このプロパティの値は、SIDを変更する場合にのみ更新してください。その場合は、データベースのブローカ管理を無効化し、SidNameプロパティを新しいSIDに合せて更新してから、ブローカ管理を再び有効化する必要があります。

注意:

名前がこのインスタンスのdb_unique_nameと一致し、SidNameプロパティの値がこのインスタンスの実際のSID値と一致するデータベースの既存インスタンスがブローカ構成にない場合は、このインスタンスのdb_unique_nameを持つデータベースの新しいインスタンスがブローカによって作成されます。

カテゴリ

説明

データ型

文字列

有効値

インスタンスのSID。特定のプラットフォームでは、SIDの大/小文字が区別される場合があることに注意してください。

ブローカ・デフォルト

該当なし

インポート

はい

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

V$INSTANCEビューのINSTANCE_NAME列

有効範囲

インスタンス

Cloud Control名

該当なし

参照:

SIDの詳細は、『Oracle Database管理者ガイド』を参照してください。

8.3.34 StandbyArchiveLocation

構成可能プロパティStandbyArchiveLocationは、REDOソースから受け取るアーカイブREDOログ・ファイルの場所を指定します。値は常に明示的に設定することをお薦めします。

カテゴリ

説明

データ型

文字列

有効値

データベースまたは遠隔同期インスタンス上にアーカイブされたREDOログ・ファイルの場所を示す、空でないファイルの指定。データベース・リカバリ領域が必要な場合はUSE_DB_RECOVERY_FILE_DESTを指定。

ブローカ・デフォルト

dgsby_db_unique_name

インポート

接続先がローカルである、VALID_FOR属性に文字列(STANDBY_ROLE, STANDBY_LOGFILE)との互換性があるスタンバイ・データベースまたは遠隔同期インスタンスのV$ARCHIVE_DEST固定ビューのDESTINATION列からインポートし、この接続先が存在しない場合は、STANDBY_ARCHIVE_DEST初期化パラメータからインポートします。STANDBY_ARCHIVE_DESTパラメータは非推奨になっており、下位互換性のみがサポートされていることに注意してください。

パラメータ・クラス

動的

ロール

スタンバイ・データベースまたは遠隔同期インスタンス

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

- VALID_FORに(STANDBY_ROLE, STANDBY_LOGFILE)との互換性があるスタンバイ・データベースまたは遠隔同期インスタンスのLOG_ARCHIVE_DEST_n初期化パラメータのLOCATION属性

- スタンバイ・データベースのV$ARCHIVE_DESTビューのDESTINATION列

有効範囲

インスタンス

Cloud Control名

スタンバイ・アーカイブの場所

注意:

データベース・リカバリ領域を使用する場合を除き、ロジカル・スタンバイ・データベースで、ローカルの格納先を示すLOG_ARCHIVE_DEST_n初期化パラメータのLOCATION属性とStandbyArchiveLocationプロパティの値には別の値を設定することをお薦めします。

8.3.35 StandbyFileManagement

構成可能なプロパティStandbyFileManagementは、プライマリ・データベース上でのデータファイル追加操作をスタンバイ・データベースに適用する方法に影響します。このプロパティをAUTOに設定し、構成可能なプロパティDbFileNameConvertを有効な値に設定すると、対応する新規データファイルがスタンバイ・データベース上で自動的に作成されます。この新規スタンバイ・データファイルの位置は、DbFileNameConvertプロパティの値により決定されます。

このプロパティをMANUALに設定した場合は、スタンバイ・データベース上で適切な新規データファイルを手動で作成する必要があります。

カテゴリ

説明

データ型

文字列

有効値

AUTOまたはMANUAL

ブローカ・デフォルト

AUTO

インポート

STANDBY_FILE_MANAGEMENT初期化パラメータからインポート

パラメータ・クラス

動的

ロール

スタンバイ

スタンバイ・タイプ

フィジカルまたはスナップショット

対応

STANDBY_FILE_MANAGEMENT初期化パラメータ

有効範囲

データベース

Cloud Control名

該当なし

8.3.36 StaticConnectIdentifier

構成可能なインスタンス固有のプロパティStaticConnectIdentifierは、データベース・インスタンスの起動時にDGMGRLクライアントが使用する接続識別子を指定します。このプロパティの値がNullの場合、DGConnectIdentifier値は、インスタンスのシャットダウンと再起動を含む操作に対して使用されます。

カテゴリ

説明

データ型

文字列

有効値

静的に登録されているサービスを参照する接続識別子。

ブローカ・デフォルト

次の値の連結である接続識別子。脚注 11

- LOCAL_LISTENER初期化パラメータに指定されているリスナーのADDRESS属性の値

- db_unique_name_DGMGRL.db_domainの連結した値に設定されるSERVICE_NAME属性の値

インポート

LOCAL_LISTENERおよびDB_UNIQUE_NAME初期化パラメータからインポート

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

該当なし

有効範囲

インスタンス

Cloud Control名

該当なし

脚注11

SidNameプロパティで指定されたインスタンスが、以前開始されたホストとは異なるホスト(V$INSTANCEビューのHOST_NAME列から読み取られた)で開始される場合、ブローカはStaticConnectIdentifierプロパティのデフォルト値を、LOCAL_LISTENER初期化パラメータに指定したリスナーの現在のADDRESS属性に組み込むように自動的に更新します。

参照:

- 静的に登録されたサービスの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- 静的サービスとStaticConnectIdentifier構成可能プロパティの使用に関する追加の情報は、My Oracle Supportノート1387859.1 (http://support.oracle.com)を参照してください

8.3.37 TransportDisconnectedThreshold

TransportDisconnectedThreshold構成可能プロパティは、プライマリ・データベースからの最後の通信がプロパティで指定された値を超過した場合に、ロジカル、フィジカル、スナップショット・スタンバイまたは遠隔同期インスタンスの警告ステータスを生成するために使用できます。プロパティ値を表す単位は秒です。値が0秒の場合、警告を生成しません。

カテゴリ

説明

データ型

数値

有効値

>=0

ブローカ・デフォルト

30秒

インポート

不要

パラメータ・クラス

該当なし

ロール

スタンバイ・データベース、遠隔同期インスタンス

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

該当なし

有効範囲

データベース、遠隔同期インスタンス

Cloud Control名

該当なし

8.3.38 TransportLagThreshold

TransportLagThreshold構成可能プロパティは、メンバーのトランスポート・ラグが、プロパティで指定された値を超過した場合に、ロジカル、フィジカル、スナップショット・スタンバイまたは遠隔同期インスタンスの警告ステータスを生成するために使用できます。プロパティ値を表す単位は秒です。値が0秒の場合、転送ラグが存在しても警告を生成しません。

カテゴリ

説明

データ型

数値

有効値

>=0

ブローカ・デフォルト

30秒

インポート

不要

パラメータ・クラス

該当なし

ロール

スタンバイ・データベース、遠隔同期インスタンス

スタンバイ・タイプ

フィジカル・スタンバイ、ロジカル・スタンバイ、スナップショット・スタンバイまたは遠隔同期インスタンス

対応

該当なし

有効範囲

データベース、遠隔同期インスタンス

Cloud Control名

該当なし

9 Oracle Data Guardのトラブルシューティング

次のトピックでは、Oracle Data Guardの様々なエラーとその解決方法について説明します。

- 診断情報のソース

- 一般的な問題と解決策

- スイッチオーバー操作時の問題のトラブルシューティング

- フェイルオーバー操作時の問題のトラブルシューティング

- オブザーバに関する問題のトラブルシューティング

9.1 診断情報のソース

Oracle Data Guard Brokerのアクティビティに関する情報は、次の形式で提供されます。

- データベース・ステータス情報(「データベース・ステータス」を参照)

- Oracleアラート・ログ・ファイル
ブローカでは、ブローカ構成に含まれる各データベースのインスタンスごとのアラート・ログ・ファイルに重要情報が記録されます。Oracle Data Guardをトラブルシューティングする場合は、このような情報のアラート・ログ・ファイルを確認できます。

- Oracle Data Guardのブローカ・ログ・ファイル
ブローカ構成に含まれる各データベースのインスタンスごとに、ブローカのDMONプロセスにより重要な動作およびステータス情報がブローカ・ログ・ファイルに記録され、このファイルは、Oracle Data Guardの障害を診断する際に役立ちます。TraceLevel構成プロパティ(「TraceLevel」を参照)は、ブローカ・ログ・ファイルで報告される診断情報のレベルを指定するために使用されます。

ブローカ・ログ・ファイルは、アラート・ログと同じディレクトリに作成され、drc<$ORACLE_SID>.logという名前が付けられます。

- Oracle Data Guardコマンドライン(DGMGRL)ログファイル
DGMGRLコマンドライン・インタフェースを、-logfileオプション・パラメータ(「DGMGRLのオプション・パラメータ」を参照)を付けて開始すると、結果として生じるログ・ファイルに、過去の操作、エラー条件、またはその両方に関する、役に立つ記録が含まれる場合があります。

9.2 一般的な問題と解決策

この項では、一般的な問題と解決策について説明します。この項の内容は、次のとおりです。

- ORA-16596: データベースがOracle Data Guard Broker構成に含まれていない

- プライマリ・データベースに累積されたREDOが一部のスタンバイ・データベースに送信されない場合

- スタンバイ・データベース上で多数のログ・ファイルが受信されるが適用されない場合

- 要求がタイムアウトしたか、Cloud Controlのパフォーマンスが低い場合

- プライマリ・データベースがフラッシュバックされる場合

- 不明なサービスのためにスタンバイが自動開始できない場合(ORA-12514)

9.2.1 ORA-16596: データベースがOracle Data Guard Broker構成に含まれていない

ブローカに対して要求が発行されましたが、接続に使用するデータベース・インスタンスはブローカ構成に含まれていません。

解決策

ブローカ構成に含まれている他のデータベースを介して構成に再接続してください。ORA-16596エラーを戻したデータベースのdb_unique_name値と名前が一致するデータベースがブローカ構成に存在することを確認してください。

構成を有効化しようとして、そのデータベースの1つのブローカ構成ファイルが意図せずに削除されていた場合や陳腐化している場合にも、この問題が発生することがあります。その場合は、データベースをブローカ構成から削除し、(プライマリ・データベースではなく)そのスタンバイ・データベースの構成ファイルを手動で削除してから、構成の有効化を再試行してください。構成が有効化された後は、Cloud Controlのスタンバイ・データベースの追加ウィザードを使用して「既存のスタンバイ・データベースの追加」オプションを選択するか、DGMGRLコマンドライン・インタフェースを使用してADD DATABASE コマンドを発行できます。

9.2.2 プライマリ・データベースに累積されたREDOが一部のスタンバイ・データベースに送信されない場合

Cloud Controlの「ログ・ファイルの詳細」ページを表示すると、ログ・ファイルがプライマリ・データベースに累積され、ブローカ構成内の一部のスタンバイ・データベースにアーカイブされていないことがわかります。

解決策

問題を絞り込むには、次の手順を実行します。

- プライマリ・データベースの状態が(TRANSPORT-OFFではなく)TRANSPORT-ONであることを確認します。

- 問題のスタンバイ・データベースのデータベース・プロパティLogShippingの値がONであることを確認します。

- 監視可能なプロパティLogXptStatusを使用して、プライマリ・データベースのREDO転送サービスのステータスをチェックします。REDO転送サービスにエラーがある場合は、エラー・メッセージを参考にして詳細なチェックおよび解決処置を判断します。次に例を示します。

- スタンバイ・データベースが使用不可能であることをエラーが示している場合は、スタンバイ・データベースを再起動する必要があります。

- リスナーが存在しないことをエラーが示している場合は、リスナーを再起動する必要があります。

- スタンバイ・データベースにローカルの宛先がないことをエラーが示している場合は、プライマリ・データベースからのアーカイブREDOログ・ファイルを格納するスタンバイ位置を設定する必要があります。

9.2.3 スタンバイ・データベース上で多数のログ・ファイルが受信されるが適用されない場合

Cloud Controlの「パフォーマンス」ページまたは「ログ・ファイルの詳細」ページを表示すると、スタンバイ・データベースに適用されないまま累積しているログ・ファイルが多すぎることがわかります。

解決策

アーカイブREDOログ・ファイルがスタンバイ・データベースに適用されない場合は、様々な原因が考えられます。ログ・ファイルが累積されている原因を調べて、妥当な理由を排除してください。

スタンバイ・データベースの現在のステータスが正常でない場合

- ログ適用サービスが予期せず停止しているかどうかを判別します。詳細は、ORA-16766(フィジカル・スタンバイ・データベースの場合)またはORA-16768(ロジカル・スタンバイ・データベースの場合)のエラーの説明と解決策を参照してください。

- これがロジカル・スタンバイ・データベースの場合は、障害トランザクションが発生したかどうかを確認します。

- 問題の調査中にエラーを抑止する場合は、データベースのブローカ管理を一時的に無効化できます。

参照:

DGMGRLコマンドライン・インタフェースを使用してデータベースを無効化する方法の詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」を参照してください

スタンバイ・データベースの現在のステータスが正常な場合

- スタンバイ・データベースの状態が(APPLY-OFFではなく)APPLY-ONであることを確認します。

- プライマリ・データベースの状態が(TRANSPORT-OFFではなく)TRANSPORT-ONであることを確認します。

参照:

データベース・プロパティLogShippingの詳細は、「Oracle Data Guard Brokerのプロパティ」を参照してください

- ログ・ファイルが累積されている原因が、DelayMinsプロパティの設定値が大きすぎるためかどうかを調べます。(ログ適用サービスでは、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用が、指定した時間(分)だけ遅延されます。)

参照:

データベース・プロパティDelayMinsの詳細は、「Oracle Data Guard Brokerのプロパティ」を参照してください

- 何もエラーが表示されない場合は、Cloud Controlの「パフォーマンス」ページでアーカイブ率を適用率と比較して、適用率がアーカイブ率より低いかどうかを調べます。

9.2.4 要求がタイムアウトしたか、Cloud Controlのパフォーマンスが低い場合

ブローカの要求が通常のタイムアウト・パラメータ内に完了しない場合、次の処置を試行して問題を解決します。

1. ネットワークが適切に動作しているかどうか確認します。

2. 構成内のすべてのノードに対してpingを試行します。

3. 他のデータベースにより再接続を試行し、操作を再試行します。

4. VERIFYコマンドを実行し、ブローカが要求を処理できないデータベースを特定します。

9.2.5 プライマリ・データベースがフラッシュバックされる場合

プライマリ・データベースがフラッシュバックされる場合、構成内のスタンバイ・データベースも、スイッチオーバーまたはフェイルオーバーの実行可能なターゲットとなるように、フラッシュバックまたは再作成される必要があります。プライマリ・データベースがフラッシュバックされた場合、ブローカによりスタンバイ・データベースのエラーがレポートされます。

ブローカにより無効化されたスタンバイ・データベースの実行可能性をリストアする方法の詳細は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

9.2.6 不明なサービスのためにスタンバイが自動開始できない場合(ORA-12514)

ブローカ操作(たとえば、スイッチオーバー、回復、フィジカル・スタンバイへの変換、または保護モードの最大保護モードへのアップグレード)の後でDGMGRL CLIが自動的にインスタンスを開始できず、ORA-12514: TNS: リスナーは接続記述子でリクエストされたサービスを現在認識していませんエラーを受け取った場合、インスタンスを手動で開始してブローカ操作を完了または継続する必要があります。

次の手順を完了する前か後に、インスタンスを再起動できます。

1. 次のDGMGRL CLIコマンドを発行して、DGMGRL CLIが再起動できなかったインスタンスの構成可能なプロパティStaticConnectIdentiferの値を確認します。(このコマンドを発行するには、実行中の別のインスタンスに接続する必要があります)

DGMGRL> SHOW INSTANCE VERBOSE 'instance_name' ON DATABASE db_unique_name;

2. StaticConnectIdentiferインスタンス・プロパティの値で指定されている静的サービス名は、プロパティ値で指定されているリスナーに登録されている必要があります。静的サービス名のデフォルト値は、次の形式をとります。

db_unique_name_DGMGRL.db_domain

ブローカを使用するための、これを含む様々な前提条件の詳細は、「前提条件」を参照してください。

3. リスナー制御ユーティリティのステータス・コマンドを使用して、静的サービス名が、構成可能なプロパティStaticConnectIdentiferの値で指定されたリスナーに登録されていることを確認します。静的サービス名が正しくリスナーに登録されている場合、次のコマンドで生成される出力に含まれます。

lsnrctl status

4. Oracle RAC環境で作業している場合、各インスタンスに対して手順1と2を繰り返し、静的サービス名がそれぞれのリスナーに正しく登録されていることを確認することをお薦めします。

9.3 スイッチオーバー操作時の問題のトラブルシューティング

構成に問題があるためにスイッチオーバーに失敗すると、ブローカにより検出された問題はアラート・ログ・ファイルまたはブローカ・ログ・ファイルでレポートされます(「診断情報のソース」を参照してください)。報告された問題が修正できる場合、スイッチオーバー操作を再試行でき、それは通常成功します。報告された問題が修正できないか、修正した後でもスイッチオーバー操作が失敗する場合、スイッチオーバー用に別のデータベースを選択するか、または構成をスイッチオーバー前の状態にリストアしてから、スイッチオーバーを再試行できます。

ファスト・スタート・フェイルオーバーが有効化されている場合、ブローカでは、ターゲット・スタンバイ・データベース以外のどのスタンバイ・データベースにもスイッチオーバーを実行できません。さらに、ターゲット・スタンバイ・データベースへのスイッチオーバーは、ターゲット・スタンバイ・データベースのV$DATABASEビュー内のFS_FAILOVER_STATUS列の値が、READYまたはSUSPENDEDのいずれかである場合にのみ可能です。

参照:

ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行

9.4 フェイルオーバー操作時の問題のトラブルシューティング

フェイルオーバー操作を停止することは可能ですが、これはお薦めしません。エラーが発生した場合、次のサブセクションに記載のガイドラインを使用して問題を修正し、ブローカ・フェイルオーバーを再試行します。

9.4.1 フィジカル・スタンバイ・データベースへのフェイルオーバーの失敗

フィジカル・スタンバイ・データベースへのブローカのフェイルオーバーの失敗からリカバリする手順は、次のとおりです。

9.4.1.1 ブローカの完全フィジカル・フェイルオーバーの失敗

ターゲット・スタンバイ・データベースでアラート・ログ・ファイルおよびブローカ・ログ・ファイル(drc*.log)を調べて、失敗した原因を確認し、それを修正します。報告された問題が修正できる場合、スイッチオーバー操作を再試行します。報告された問題が修正できないか、報告された問題を修正した後でもフェイルオーバー操作がまだ失敗する場合、次の手順を実行します。

1. ターゲット・スタンバイ・データベースに接続し、ファスト・スタート・フェイルオーバーが有効な場合はFORCEオプションを使用して無効化します。

2. 次のどちらかの操作を実行します。

- 別のフィジカル・スタンバイ・データベースに接続して、ブローカの完全フェイルオーバーを実行します。

- ターゲット・フィジカル・スタンバイ・データベースへのブローカの即時フェイルオーバーを実行します。

3. 元のプライマリ・データベースと、回復を要求するステータス(ORA-16661)を持つその他の無効なフィジカル・スタンバイ・データベースを回復します。

4. ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。

9.4.1.2 ブローカの即時フィジカル・フェイルオーバーの失敗

ターゲット・スタンバイ・データベースでアラート・ログ・ファイルおよびブローカ・ログ・ファイル(drc*.log)を調べて、失敗した原因を確認し、それを修正します。問題が修正可能な場合は、ブローカの即時フェイルオーバーを再試行します。それ以外の場合は、別のフィジカル・スタンバイ・データベースに接続して、ブローカの完全フェイルオーバーまたは即時フェイルオーバーを実行します。

9.4.2 ロジカル・スタンバイ・データベースへのフェイルオーバーの失敗

1. ターゲット・スタンバイ・データベースでアラート・ログ・ファイルおよびブローカ・ログ・ファイル(drc*.log)を調べて、失敗した原因を確認し、それを修正します。

2. ターゲット・スタンバイ・データベースに接続し、ファスト・スタート・フェイルオーバーが有効な場合はFORCEオプションを使用して無効化します。

3. ブローカのフェイルオーバーを再試行します。

4. 元のプライマリ・データベースを回復します。その他のスタンバイ・データベースはすべて、新規プライマリ・データベースのコピーから再作成されます。

5. ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。

ブローカのフェイルオーバーが引き続き失敗する場合は、Oracle Data Guard構成ですべてのデータベース上のブローカを停止します(DG_BROKER_START初期化パラメータをFALSEに設定します)。すべてのデータベースからOracle Data Guard Broker構成ファイルを削除します。『Oracle Data Guard概要および管理』のロール遷移に関するガイドラインを使用して、手動フェイルオーバーを実行します。

注意:

DGMGRLのENABLE CONFIGURATIONおよびDISABLE CONFIGURATIONコマンドを使用すると、ブローカ構成を有効化または無効化できます。Cloud Controlを使用して構成を無効化することはできません。前にDGMGRLを使用して無効化した構成は、Cloud Controlを使用してのみ有効化できます。

9.5 オブザーバに関する問題のトラブルシューティング

オブザーバは、継続的にファスト・スタート・フェイルオーバー環境を監視して、プライマリ・データベースが使用可能であることを確認します。オブザーバのインストールおよび起動は、ファスト・スタート・フェイルオーバーの使用における必須部分です。次の各項で、オブザーバのトラブルシューティング方法について説明します。

- オブザーバの起動に関する問題

- オブザーバが停止したことによる問題

- オブザーバ・ログ・ファイルでのオブザーバの処理の取得

9.5.1 オブザーバの起動に関する問題

一度に1つのオブザーバのみブローカ構成を監視できます。2つ目のオブザーバを起動しようとすると、次のいずれかのエラーが戻されます。

ORA-16647: could not start more than one observer
DGM-16954: Unable to open and lock the Observer configuration file

現在ブローカ構成に関連付けられているオブザーバの位置を判別するには、DGMGRLのSHOW CONFIGURATION VERBOSEコマンドを使用します。

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
North_Sales- Primary database
South_Sales- Physical standby database

Properties:
FastStartFailoverThreshold     = '30'
OperationTimeout               = '30'
TraceLevel                     = 'USER'
FastStartFailoverLagLimit      = '30
CommunicationTimeout           = '180'
ObserverReconnect              = '0'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown   = 'TRUE'
BystandersFollowRoleChange     = 'ALL'
ObserverOverride               = 'FALSE'
ExternalDestination1           = ''ExternalDestination2             = ''PrimaryLostWriteAction           = 'CONTINUE'

Fast-Start Failover: ENABLED

Threshold: 30 seconds
Target: South_Sales
Observer: observer.example.com
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Observer Reconnect: (none)
Observer Override: FALSE

Configuration Status:
SUCCESS

9.5.2 オブザーバが停止したことによる問題

オブザーバのホスト・マシンがクラッシュした場合、ブローカ構成は監視されなくなり、ファスト・スタート・フェイルオーバーは実行できなくなります。この場合、元のホスト・マシンを適時に修復できないときは、オブザーバを新しいホストに移動する必要があります。オブザーバを移動するには、最初のオブザーバがこのブローカ構成を監視できないようにしてから、別のホストで新規オブザーバを起動する必要があります。

1. DGMGRLのSTOP OBSERVERコマンドを発行し、元のオブザーバとブローカ構成の間のリンクを切り離します。

DGMGRL> STOP OBSERVER;
Done.

2. DGMGRLの SHOW CONFIGURATION VERBOSEコマンドを発行し、構成が監視されていないことを確認します。

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
North_Sales - Primary database
Warning: ORA-16819: fast-start failover observer not started

South_Sales - (*) Physical standby database
Warning: ORA-16819: fast-start failover observer not started

(*) Fast-Start Failover target

Properties:
FastStartFailoverThreshold     = '30'
OperationTimeout               = '30'
TraceLevel                     = 'USER'
FastStartFailoverLagLimit      = '30'
CommunicationTimeout           = '180'
ObserverReconnect              = '0'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown   = 'TRUE'
BystandersFollowRoleChange     = 'ALL'
ObserverOverride               = 'FALSE'
ExternalDestination1           = ''
ExternalDestination2           = ''  PrimaryLostWriteAction         = 'CONTINUE'

Fast-Start Failover: ENABLED

Threshold: 30 seconds
Target: South_Sales
Observer: observer.example.com
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Observer Reconnect: (none)
Observer Override: FALSE

Configuration Status:
WARNING

3. オブザーバが実際に停止していることを確認する際に、DGMGRLのSHOW CONFIGURATIONコマンドを発行する必要はないので注意してください。DGMGRLのSTOP OBSERVERコマンドを正常に完了すると、新規オブザーバを構成に関連付けることが可能になります。

9.5.3 オブザーバ・ログ・ファイルでのオブザーバの処理の取得

DGMGRLの-logfileオプションを使用してオブザーバを起動できます。これにより、「オブザーバの起動に関する問題」で実行したトラブルシューティング処理をすべてファイルに取得できます。次に例を示します。

% dgmgrl -logfile observer.log / "start observer"

オブザーバの出力はすべて、DGMGRLコマンドを発行した現在の作業ディレクトリ内のobserver.logファイルに記録されます。指定したログにアクセスできない場合、ログ・ファイルが指定されていない場合と同様に、オブザーバーの出力が標準出力に送信されます。

これはオブザーバの問題のトラブルシューティングに役立つだけではなく、ファスト・スタート・フェイルオーバー全般の問題のトラブルシューティングにも役立ちます。

A Oracle Data Guard Brokerのアップグレードとダウングレード

この付録では、ブローカ構成におけるOracleデータベースおよびOracle Enterprise Manager Cloud Control (Cloud Control)のアップグレードまたはダウングレードのプロセスを順序立てて説明します。内容は次のとおりです。

- Oracle Database 9i リリース2 (9.2)からOracle Database 12c リリース1 (12.1)へのアップグレード

- Oracle Database 10gおよびOracle Database 11gからOracle Database 12c リリース1 (12.1)へのアップグレード

- Oracle Database 12c リリース1 (12.1)へのダウングレード

- ローリング・アップグレード時のブローカ構成の維持

注意:

Oracle Data Guard構成では、すべてのフィジカルおよびスナップショット・スタンバイ・データベースはプライマリ・データベースからパスワード・ファイルのコピーを使用する必要があり、管理権限(SYSDG、SYSOPERまたはSYSDBA)が付与または解除されるたびに、あるいは管理権限を持つユーザーのパスワード変更後、このコピーのリフレッシュが必要です。

参照:

Oracle Data Guardのインストール

A.1 Oracle Database 9i リリース2 (9.2)からOracle Database 12c リリース1 12.1へのアップグレード

現在、Oracle Database 9i リリース2 (9.2)でブローカ構成を実行している場合、Oracle Database 12c リリース1 (12.1)をアップグレードして、次のようにブローカ構成を再作成する必要があります。

1. Oracle Database 9i リリース2 (9.2)ブローカ構成を削除します。たとえば、DGMGRL REMOVE CONFIGURATIONコマンドを使用できます。削除を実行するには、Oracle Database 9i リリース2 (9.2)上で実行するOracle Data Guard ManagerまたはDGMGRLを使用する必要があります。

2. DGMGRLを使用している場合は、ALTER SYSTEM SET LOG_ARCHIVE_DEST_n=" " SQL*Plusコマンドを使用して、LOG_ARCHIVE_DEST_n初期化パラメータの設定をクリアします。

3. データベース・ソフトウェアをOracle Database 12c リリース1 (12.1)にアップグレードします。使用しているオペレーティング・システムに適したOracle Databaseインストレーション・ガイドを参照してください。

4. Oracle Database 9i リリース2 (9.2)上で実行するOracle Enterprise ManagerおよびOracle Data Guard Managerは、Oracle Database 12c リリース1 (12.1)上で実行するブローカ構成を管理できません。

参照:

My Oracle Supportノート787461.1 (http://support.oracle.com)に記載の、様々なOracle DatabaseリリースにおいてOracle Data Guardの全機能を管理するために必要なEnterprise Manager Cloud Control (旧称Grid Control)のバージョンに関する情報

5. Oracle Database 9i リリース2 (9.2)で実行するDGMGRLを使用する場合、Oracle Database 12c リリース1 (12.1)で実行するDGMGRLにアップグレードする必要があります。

- Oracle Database 9i リリース2 (9.2)上で実行するDGMGRLは、Oracle Database 12c リリース1 (12.1)上で実行するOracle Data Guardと互換性はありません。

- Oracle Database 12c リリース1 (12.1)上で実行するDGMGRLは、Oracle Database 9i リリース2 (9.2)上で実行するOracle Data Guardと互換性はありません。

注意:

Oracle Database 12cのコマンドライン・スクリプトは、Oracle9iではサポートされません。

6. Enterprise ManagerまたはDGMGRLコマンドライン・インタフェースを起動し、ブローカ構成を再作成します。

A.2 Oracle Database 10gおよびOracle Database 11gからOracle Database 12c リリース1 (12.1)へのアップグレード

現在、Oracle Database 10gまたはOracle Database 11g上でOracle Data Guardを実行している場合、ご使用のオペレーティング・システムに適切なOracle Databaseインストール・ドキュメントを使用して、データベース・ソフトウェアをOracle Database 12c リリース1 (12.1)にアップグレードできます。

注意:

Oracle Database 11g リリース2 (11.2)より前は、構成ファイルは最初に作成されたときと同じセクター・サイズ(物理ブロック・サイズ)のディスクにのみ格納するように制限されていました。一般にブローカ構成では1つのセクター・サイズが使用されていたため、これは問題にはなりませんでした。任意のブローカ構成内でセクター・サイズが混在する可能性があるため、ブローカ構成ファイルは、4KB以下であれば、最初に作成されたときのセクター・サイズの影響をまったく受けないようになりました。

次の手順5のアップグレード・プロセス中に、最初に作成されたときのセクター・サイズの影響を受けないように構成ファイルが変換されます。

1. 次のDGMGRLコマンドを発行して、ファスト・スタート・フェイルオーバーを無効化します。

DGMGRL> DISABLE FAST_START FAILOVER;

2. 実行しているバージョン10.nまたは11.nのOracle Data Guard Brokerを停止します。

a. 次のDGMGRLコマンドを発行して、Oracle Data Guard構成におけるデータベースのブローカによるアクティブな管理を無効化します。

DGMGRL> DISABLE CONFIGURATION;

b. 次のSQL*Plus文を発行してブローカを停止します。

SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;

3. 初期化パラメータDG_BROKER_CONFIG_FILE1およびDG_BROKER_CONFIG_FILE2で示しているように、現行のブローカ構成ファイルのコピーを作成します。

4. Oracle DatabaseソフトウェアをOracle Database 12cリリース1 (12.1)にアップグレードします。アップグレード手順については、使用しているオペレーティング・システムに適したOracle Databaseインストレーション・ガイドを参照してください。
Oracle Database 12c リリース1 (12.1)上で実行するブローカ構成を管理および監視するには、DGMGRLコマンドライン・インタフェースもアップグレードする必要があります。Oracle Database 12c リリース1 (12.1)上で実行するDGMGRLを使用して、Oracle Database 10gまたはOracle Database 11g上で実行するOracle Data Guardを管理することはできません。

注意:

Oracle Database 10gおよびOracle Database 11gの既存のDGMGRLコマンドライン・スクリプトは、Oracle Database 12c リリース1 (12.1)で利用できるDGMGRLコマンドライン・インタフェースでサポートされています。

Oracle Database 11gのDGMGRLコマンドライン・スクリプトは、Oracle Database 10gによるサポートが保証されていません。

5. Oracle Database 12c リリース1 (12.1)にアップグレード後、ブローカを起動します。次に例を示します。

a. 次のSQL*Plus文を発行してブローカを起動します。

SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;

b. 次のDGMGRLコマンドを発行して、Oracle Data Guard構成におけるデータベースのブローカによるアクティブな管理を有効化します。

DGMGRL> ENABLE CONFIGURATION

ブローカがOracle Database 12c リリース1 (12.1)上で起動すると、まずOracle Database 10gおよびOracle Database 11gブローカ構成ファイルが存在するか検出します。それらは、自動的にアップグレードされ、Oracle Database 12c リリース1 (12.1)で導入された新しいプロパティも含められます。この自動変換は透過的かつ永続的であり、1回のみ実行されます。

注意:

手順5で行われるこの自動アップグレードで、構成ファイルはサポートされている4KBセクター以下のディスク・セクター・サイズ(物理ブロック・サイズ)のディスクに格納されます。

注意:

アップグレード前に起動されたオブザーバは自動的に停止し、アップグレードの完了後は構成を監視できなくなります。Oracle Database 12cバージョンのOracleオブザーバ・ソフトウェアを使用して、Oracle Database 12c リリース1 (12.1)以上で実行するOracle Databaseを監視する必要があります。

A.3 Oracle Database 12c リリース1 (12.1)へのダウングレード

Oracle Database 12c リリース1 (12.1)へのアップグレードを完了していて、以前のリリースにダウングレードする場合は、次の手順でデータベース・リリースをダウングレードし、ブローカ構成を再作成する必要があります。

1. Oracle Database 12c リリース1 (12.1)上で実行するEnterprise ManagerまたはDGMGRLを使用してOracle Database 12c リリース1 (12.1)ブローカ構成を削除します。たとえば、DGMGRL REMOVE CONFIGURATIONコマンドを使用できます。

2. Oracle Databaseソフトウェアを以前のOracleリリースにダウングレードします。使用しているオペレーティング・システムに適したOracle Databaseのマニュアルを参照してください。

3. Oracle Data Guard BrokerをOracle Database 10gまたはOracle Database 11gにダウングレードするには、次のようにします。

- Oracle Database 12cリリース1 (12.1)へのアップグレード後にブローカ構成に変更を加えていないことが明白である場合、アップグレード手順で作成したブローカ構成ファイルをコピーできます(「Oracle Database 10gおよびOracle Database 11gからOracle Database 12c リリース1 (12.1)へのアップグレード」を参照)。続いて、Enterprise ManagerまたはDGMGRLコマンドライン・インタフェースを起動し、そのコピーの作成時点で存在したとおりにブローカ構成を再度有効化します。

- あるいは、Enterprise ManagerまたはDGMGRLコマンドライン・インタフェースを起動し、ブローカ構成を再作成できます。

4. Oracle Data Guard BrokerをOracle Database 9i リリース2 (9.2)にダウングレードするには、次のようにします。

- Oracle Enterprise Managerを使用していた場合、Oracle Database 10g リリース2 (10.2)上で実行するOracle Enterprise Managerを継続して使用し、Oracle Database 9i リリース2 (9.2)ブローカ構成を管理できます。また、Oracle Database 9i リリース2 (9.2) Enterprise Managerを再インストールして、Oracle Data Guard Managerにダウングレードすることもできます。

- Enterprise Manager、Oracle Data Guard ManagerまたはDGMGRLコマンドライン・インタフェースを起動し、ブローカ構成を再作成します。

A.4 ローリング・アップグレード時のブローカ構成の維持

Oracle Data Guard Brokerを使用してOracle Data Guard構成を管理し、ローリング・アップグレード時にその構成を保持する場合は、次の手順を実行する必要があります。

1. ブローカ構成を無効化します(DGMGRL DISABLE CONFIGURATIONコマンドを使用)。

2. ローリング・アップグレードを実行します。

3. 現在のプライマリ・データベース(制御ファイルのロールがPRIMARYであるデータベース)に接続して、ブローカ構成を再有効化します(DGMGRL ENABLE CONFIGURATIONコマンドを使用)。

この手順に従うと、ブローカ構成が維持され、ローリング・アップグレードの完了後にリビルドする必要がありません。

この手順には次の制限事項があります。

- ブローカ構成は、ローリング・アップグレードの完了後に有効化する必要があります。構成を有効にする前に、ローリング・アップグレードが完了していることを確認してください。

- ブローカ構成は、異なるバージョンのOracleを実行している複数のデータベースをサポートしません。プライマリ・データベースとして同じバージョンのOracleを実行していないスタンバイ・データベースはすべて無効になり、ORA-16673: 「スタンバイ・データベースで異なるOracleバージョンが実行されています」というエラー・メッセージが表示されます。

- ブローカ構成が無効化されている場合、ブローカ構成を有効化できるのは、制御ファイルのロールがプライマリであるデータベースに接続している間だけです(V$DATABASEビューのDATABASE_ROLE列を問い合せて、どれに値PRIMARYが含まれるかを確認します)。

参照:

- ローリング・アップグレードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

用語集

適用インスタンス

Oracle Real Application Clusters(Oracle RAC)データベース環境で、アーカイブREDOデータをスタンバイ・データベースに適用する1つのインスタンスです。

ブローカ

Oracle Data Guard構成の作成、制御および監視に必要な、複雑な操作の大半を自動化および簡素化する分散管理フレームワーク。

ブローカ構成

Oracle Data Guard構成のプライマリ・データベースとスタンバイ・データベース(REDO転送サービスとログ適用サービスを含む)を論理的にグループ化したものです。

「Data Guard構成」も参照してください。

その他のスタンバイ・データベース

スイッチオーバー操作またはフェイルオーバー操作の対象でない、またはこれらの操作に直接関係のないスタンバイ・データベース。

構成オブジェクト

データベース・オブジェクトの名前付きの集合。Oracle Data Guard構成を抽象化したものです。

データベース・ガード

データベース・ガードは、ロジカル・スタンバイ・データベース内の表を変更可能かどうかを制御します。

データベース・オブジェクト

Oracle Data Guard構成内のプライマリ・データベースまたはスタンバイ・データベースに対応する名前付きオブジェクト。ブローカは、このオブジェクトを使用して単一データベースの状態を管理および制御し、プロパティをデータベースに関連付けます。

Data Guardコマンドライン・インタフェース

Oracle Data Guardコマンドライン・インタフェース(DGMGRL)では、Oracle Data Guard構成をDGMGRLプロンプトまたはスクリプト内から制御および監視できます。

Data Guard構成

予定されている停止時間(定期点検など)に加え、予定外のイベント(人為的エラー、環境災害、データの破損など)による損害を回避または最小限に抑える分散コンピュータ・システム。

「ブローカ構成」も参照してください。

Data Guard環境

プライマリ・データベース、スタンバイ・データベースおよび遠隔同期インスタンスの物理構成。環境は、次の項目を含む多数の要因に依存します。

- プライマリ・データベースに関連するスタンバイ・データベースと遠隔同期インスタンスの数

- データベースで使用されるホスト・システムの数

- データベースで使用されるマシンのディレクトリ構造

- ネットワーク構成

- REDO転送サービス

- ログ適用サービス

Oracle Data Guard環境には、DBAが手動で管理する方法、Enterprise ManagerまたはData Guardコマンドライン・インタフェース(DGMGRL)を使用して自動的に管理する方法、これらすべてを組み合せて行う方法があります。

デフォルト状態

構成のブローカ管理を有効化するときに、データベース・オブジェクトが実行される初期のランタイム状態。実際のデフォルト状態は、データベースが実行中のロール(プライマリまたはスタンバイ)によって異なることもあります。

「インテンド状態」も参照してください。

フェイルオーバー

スタンバイ・データベースをプライマリ・データベースのロールに変更し、元のプライマリ・データベースを無効化する操作。

「ファスト・スタート・フェイルオーバー」および「手動フェイルオーバー」も参照してください。

遠隔同期インスタンス

プライマリ・データベースからREDOを受け取り、それをOracle Data Guard構成全体にわたって再分配する、リモートのOracle Data Guardの宛先です。それは制御ファイルを管理する点でフィジカル・スタンバイ・データベースに類似しており、REDOをスタンバイREDOログ・ファイル(SRL)に受信し、それらのSRLをローカルのアーカイブREDOログ(ARL)にアーカイブします。しかしスタンバイ・データベースとは異なり、遠隔同期インスタンスはデータ・ファイルを管理せず、アクセスに対してオープンすることもできず、REDO適用を実行することもできません。

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

プライマリ・データベースが使用できなくなった場合にフェイルオーバーを自動的に有効化します。ファスト・スタート・フェイルオーバーを有効化すると、ブローカはフェイルオーバーの必要性を判断し、指定されたスタンバイに自動的、迅速かつ確実にフェイルオーバーを実行します。このとき、フェイルオーバーの起動に手動の手順を実行する必要はありません。

「手動フェイルオーバー」も参照してください。

インスタンス・オブジェクト

名前付きオブジェクト。データベース・オブジェクトは1つ以上の名前付きインスタンス・オブジェクトの集合です。ブローカはこのオブジェクトを使用して、インスタンスが関連付けられているデータベースの状態を管理および制御し、このデータベース・インスタンスにインスタンス固有のプロパティを関連付けます。

インテンド状態

ブローカによる管理が有効な間のデータベース・オブジェクトのランタイム状態。

「デフォルト状態」も参照してください。

完全自動コンピューティング

操作が自動化されており、管理者による操作がほとんど、またはまったく必要ないコンピューティング装置またはソフトウェアを指します。

完全自動という語は、コンピューティング・センターが1つの部屋にあり、そこで多数のサーバーが施錠され秘密に保管されていた頃に生じたものです。通常の動作では、この部屋に管理者が入ることはなく、この部屋のすべての操作が自動化されていました。

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

ロジカル・スタンバイ・データベースは、標準のOracleアーカイブREDOログ・ファイルを取得し、SQLトランザクションに再変換した後で、オープン状態のスタンバイ・データベースに適用します。変更はエンド・ユーザー・アクセスと同時に適用されますが、再生成されたSQLトランザクションを介してメンテナンスされている表で許可されるのは、ロジカル・スタンバイ・データベースのユーザーに対する読取り専用アクセスです。データベースは、再構成されたSQLトランザクションを適用できるようにオープン状態になっているため、プライマリ・データベースとは物理的に異なります。データベース表の索引や物理特性は対応するプライマリ・データベースと異なる場合がありますが、スタンバイ・データ・ソースとしてのロールを遂行するために、表はアプリケーション・アクセスの観点から論理的な一貫性を保つ必要があります。

手動フェイルオーバー

DBAが開始するフェイルオーバー。DBAは、まずフェイルオーバーが必要であることを判断してから、Enterprise ManagerでFAILOVERをクリックするか、DGMGRLのFAILOVERコマンドを発行してフェイルオーバーを起動します。手動という用語は、このタイプのフェイルオーバーとファスト・スタート・フェイルオーバーを比較する目的で使用します。

「ファスト・スタート・フェイルオーバー」も参照してください。

オブザーバ

プライマリ・データベースおよびターゲット・スタンバイ・データベースを継続的に監視し、フェイルオーバーの必要性を評価して、条件を満たしたときにファスト・スタート・フェイルオーバーを開始するDGMGRLクライアント。

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

プライマリ・データベースの正確なコピーであるスタンバイ・データベース。プライマリ・データベースがオープンされてアクティブな状態で、REDO Applyによりプライマリ・データベースから受け取ったREDOデータがフィジカル・スタンバイ・データベースに適用されます。REDO Applyは、マウントされたフィジカル・スタンバイ・データベース・インスタンスで実行できます。Oracle Active Data Guardオプションのライセンスを購入済の場合は、REDO Applyをオープン状態のフィジカル・スタンバイ・データベース・インスタンスでも実行できます。詳細は、『Oracle Data Guard概要および管理』を参照してください。

プライマリ・データベース

1つ以上のスタンバイ・データベースが作成され、メンテナンスされる本番データベース。すべてのスタンバイ・データベースは、1つのプライマリ・データベースと関連付けられます。しかし、1つのプライマリ・データベースは、複数のスタンバイ・データベースをサポートできます。Oracle Data Guard Brokerモニター(DMON)は、プライマリ・データベースを使用してバイナリ構成ファイルのマスター・コピーをメンテナンスし、変更があった場合に各スタンバイ・データベースのファイル・コピーが確実に更新されるようにします。

ブローカは、グローバルで一意に定義されているDB_UNIQUE_NAME初期化パラメータの値を使用して、このデータベースを参照します。

読取り専用モード

このモードでデータベースをオープンすると、データベースの問合せは実行できますが、変更はできません。

フィジカル・スタンバイ・データベースを読取り専用でオープンすると、スタンバイ・データベースに対する問合せを実行できます。Oracle Active Data Guardオプションのライセンスを購入済の場合は、REDO Applyがアクティブなときにフィジカル・スタンバイ・データベースをオープン状態にしておくことができます。この機能はリアルタイム問合せと呼ばれます。詳細は、『Oracle Data Guard概要および管理』を参照してください。

REDO Apply

フィジカル・スタンバイ・データベースは、REDO Applyによってプライマリ・データベースとの同期が保たれます。REDO Applyでは、プライマリ・データベースから受け取ったREDOデータがリカバリされ、このREDOがフィジカル・スタンバイ・データベースに適用されます。

回復

回復とは、フェイルオーバー操作後に無効化された元のプライマリ・データベースなどのデータベースを、新規プライマリ・データベースの実行可能なスタンバイ・データベースにするプロセスです。データベースを回復するには、データベース上でフラッシュバック・データベースを有効化する必要があります。

スナップショット・スタンバイ・データベース

スナップショット・スタンバイ・データベースは、フィジカル・スタンバイ・データベースから作成される完全に更新可能なスタンバイ・データベースです。スナップショット・スタンバイ・データベースは、REDOデータを受け取りますが、スナップショット・スタンバイ・データベースがフィジカル・スタンバイ・データベースに逆変換されるまでは適用されません。

SQL Apply

ロジカル・スタンバイ・データベースは、SQL Applyによってプライマリ・データベースとの同期が保たれます。SQL Applyでは、プライマリ・データベースから受け取ったREDOのデータがSQL文に変換され、スタンバイ・データベースでこのSQL文が実行されます。

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

プライマリ・データベースのバックアップを使用して作成されたプライマリ・データベースのコピー。各スタンバイ・データベースにはプライマリ・データベースからアーカイブREDOデータが適用され、各スタンバイ・データベースとプライマリ・データベースとの同期が保たれます。スタンバイ・データベースは、プライマリ・データベースから処理を引き継ぐことができ、ほぼ継続的なデータベースの可用性を提供します。スタンバイ・データベースには、独自のサーバー・パラメータ・ファイル、制御ファイルおよびデータファイルがあります。また、ブローカ構成ファイルのコピーがあり、プライマリ・データベース・インスタンスで実行中のDMONプロセスにより常に最新の状態に保たれます。

ブローカは、スタンバイ・データベースをDB_UNIQUE_NAME初期化パラメータに格納されているグローバルな一意名で参照します。

「ロジカル・スタンバイ・データベース」、「フィジカル・スタンバイ・データベース」および「スナップショット・スタンバイ・データベース」も参照してください。

索引

A  B  C  D  E  F  H  I  L  M  N  O  P  Q  R  S  T  U  V  W

A

- ADD DATABASEコマンド 1

- ADD FAR_SYNCコマンド 1

- スタンバイ・データベースの追加ウィザード

- ブローカ構成の作成 1

- 定義 1

- 概要 1

- 変更

- プロパティ

- データベース 1

- 状態

- データベース 1 , 2

- AlternateLocationプロパティ

- ログ適用サービスの設定 1

- アプリケーション・コンティニュイティ

- Oracle Data Guard Brokerでのサポート 1

- アプリケーション統合 1

- 適用インスタンス

- フェイルオーバー 1

- PreferredApplyInstanceプロパティ 1

- 選択 1

- ApplyInstanceTimeoutプロパティ 1

- ApplyLagThresholdプロパティ 1

- ApplyParallelプロパティ 1

- アーキテクチャ

- Data Guard Broker 1

- ARCHIVE_LAG_TARGET初期化パラメータ

- ブローカ構成での設定 1

- アーカイブREDOログ

- 接続先および構成パラメータ 1

- Data Guard構成 1

- プライマリ・データベースの設定 1

- ArchiveLagTargetプロパティ 1

- ASYNC REDO転送サービス 1

- 自動ストレージ管理(ASM)

- 使用するスタンバイ・データベースの作成 1

B

- バックグラウンド・プロセス

- DMON 1

- バナー

- DGMGRLコマンドライン・インタフェース出力からの抑止 1

- スイッチオーバー実行前の考慮事項 1

- DGMGRLの使用前 1

- メリット

- Data Guard Broker 1

- 高可用性 1

- スケーラビリティ 1

- Oracle Real Application Clusters 1

- Bindingプロパティ 1

- ブローカ

- コンポーネント 1

- 構成 1

- Data Guard構成ファイル 1

- drc*ログ・ファイル 1

- インストール 1

- 概要 1

- ユーザー・インタフェース 1

- ブローカ構成

- メリット 1

- ロールの変更 1

- 作成 1

- Data Guard構成ファイル 1

- データベースの無効化 1 , 2

- メタデータを削除する効果 1

- 有効化 1 , 2

- データベースの有効化 1 , 2 , 3 , 4

- ファスト・スタート・フェイルオーバーの有効化 1

- 健全性 1 , 2

- ライフ・サイクル 1

- 管理 1 , 2 , 3

- 監視 1

- Oracle Net Services構成 1 , 2

- プロパティ 1

- 保護モード 1

- 保護モードの設定 1

- ステータス・モード 1

- サポート対象 1

- BystandersFollowRoleChangeプロパティ 1

- その他のスタンバイ・データベース

- 構成への再統合 1

C

- CDB

- Data Guard Brokerサポート 1

- CFS

- 「クラスタ・ファイル・システム」を参照

- 変更

- プロパティ

- ブローカ構成内のデータベース, 1 , 2

- ロール

- ブローカ構成内 1

- 状態

- ブローカ構成内のデータベース 1

- ブローカ構成内のデータベース 1

- クラスタ・ファイル・システム(CFS)

- ブローカ構成ファイル 1

- コマンドライン・インタフェース

- 「Data Guardコマンドライン・インタフェース(DGMGRL)」を参照

- コマンド・プロンプト

- DGMGRLコマンドライン・インタフェース出力からの抑止 1

- CommunicationTimeoutプロパティ 1

- 完全フェイルオーバー 1 2

- コンポーネント

- ブローカ 1

- Data Guard構成 1

- 構成可能なプロパティ

- AlternateLocation 1

- ApplyInstanceTimeout 1

- ApplyLagThreshold 1

- ApplyParallel 1

- ArchiveLagTarget 1

- Binding 1

- データベース 1 , 3

- DbFileNameConvert 1

- DelayMins 1

- DGConnectIdentifier 1

- FastStartFailoverTarget 1

- LogArchiveFormat 1

- LogArchiveMaxProcesses 1

- LogArchiveMinSucceedDest 1

- LogArchiveTrace 1

- LogFileNameConvert 1

- LogShipping 1

- LogXptMode 1

- LsbyMaxEventsRecorded 1

- LsbyMaxServers 1

- LsbyMaxSga 1

- LsbyPreserveCommitOrder 1

- LsbyRecordAppliedDdl 1

- LsbyRecordSkipDdl 1

- LsbyRecordSkipErrors 1

- REDO転送サービスの管理 1

- MaxConnections 1

- MaxFailure 1

- NetTimeout 1

- ObserverConnectIdentifier 1

- PreferredApplyInstance 1

- RedoCompression 1

- RedoRoutes 1

- ReopenSecs 1

- SidName 1

- StandbyArchiveLocation 1

- StandbyFileManagement 1

- StaticConnectIdentifier 1

- TransportDisconnectedThreshold 1

- TransportLagThreshold 1

- 構成ファイル

- ファスト・スタート・フェイルオーバー構成(fsfo.dat)ファイル 1

- 「Data Guard構成ファイル」も参照 1

- 構成プロパティ

- BystandersFollowRoleChange 1

- CommunicationTimeout 1

- FastStartFailoverAutoReinstate 1

- FastStartFailoverLagLimit 1

- FastStartFailoverPmyShutdown 1

- FastStartFailoverThreshold 1

- ObserverOverride 1

- ObserverReconnect 1

- OperationTimeout 1

- PrimaryLostWriteAction 1

- Tracelevel 1

- 接続

- Data Guard Broker構成に必要な権限 1

- オブザーバの起動 1

- 制御

- 使用可能なSGAメモリー 1

- CONVERT DATABASEコマンド 1

- CREATE CONFIGURATIONコマンド 1

- 作成

- ブローカ構成

- スタンバイ・データベースの追加ウィザードを使用 1

- スタンバイ・データベース 1

D

- データベース・リソース

- 監視 1

- データベース

- 状態の変更 1

- 作成およびブローカ構成への追加 1

- 依存性 1

- 管理の無効化 1

- 条件

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

- 手動フェイルオーバー 1

- スイッチオーバー 1

- 有効化 1

- 健全性 1

- ブローカ管理のためのインストール 1

- 監視可能なプロパティ 1

- ネットワーク設定 1 , 2

- ブローカ構成の前提条件 1

- プロパティ 1 , 2 , 3

- プロパティ管理 1

- ロール遷移後の再有効化 1

- 再起動

- ファスト・スタート・フェイルオーバーの後 1

- 停止

- ファスト・スタート・フェイルオーバーへの影響 1 , 2

- 状態

- 依存性 1

- 推移 1

- ステータス 1

- Data Guard

- トラブルシューティング 1

- Data Guard Broker

- 「ブローカ」も参照 1

- Data Guardコマンドライン・インタフェース

- コマンド

- ENABLE FAST_START FAILOVER 1

- SET STATE 1

- DG_BROKER_START初期化パラメータ 1

- データベースの有効化 1

- 概要 1

- Data Guardコマンドライン・インタフェース(DGMGRL)

- 出力からのバナー 1

- コマンド

- ADD DATABASE 1

- ADD FAR_SYNC 1

- CONVERT DATABASE 1

- CREATE CONFIGURATION 1

- DISABLE CONFIGURATION 1

- DISABLE DATABASE 1

- DISABLE FAR_SYNC 1 , 2

- DISABLE FAST_START FAILOVER 1

- DISABLE FAST_START FAILOVER CONDITION 1

- EDIT CONFIGURATION (プロパティ) 1

- EDIT CONFIGURATION(保護モード) 1

- EDIT CONFIGURATION (RENAME) 1 , 2

- EDIT CONFIGURATION RESET (プロパティ) 1 , 2

- EDIT DATABASE (プロパティ) 1 , 2

- EDIT DATABASE (名前の変更) 1

- EDIT DATABASE (状態) 1

- EDIT DATABASE RESET (プロパティ) 1

- EDIT FAR_SYNC 1

- EDIT FAR_SYNC RESET (プロパティ) 1

- EDIT INSTANCE(AUTO PFILE) 1

- EDIT INSTANCE (プロパティ) 1 , 2

- EDIT INSTANCE RESET (プロパティ) 1

- ENABLE CONFIGURATION 1

- ENABLE DATABASE 1

- ENABLE FAR_SYNC 1

- ENABLE FAST_START FAILOVER 1

- ENABLE FAST_START FAILOVER CONDITION 1

- EXIT 1

- FAILOVER 1

- HELP 1

- QUIT 1

- REINSTATE DATABASE 1

- REMOVE CONFIGURATION 1

- REMOVE DATABASE 1

- REMOVE FAR_SYNC 1

- REMOVE INSTANCE 1

- SHOW CONFIGURATION 1 , 2

- SHOW DATABASE 1

- SHOW FAR_SYNC 1

- SHOW FAST_START FAILOVER 1

- SHOW INSTANCE 1

- SHUTDOWN 1

- SQL 1

- START OBSERVER 1

- STARTUP 1

- STOP OBSERVER 1

- SWITCHOVER 1 , 2

- VALIDATE DATABASE 1

- VALIDATE FAR_SYNC 1

- 構成の作成 1

- DG_BROKER_START初期化パラメータ 1

- 構成の有効化 1

- ブローカ構成の監視 1

- 定期的な管理タスクの実施 1

- 前提条件 1

- 重要なデータベース・プロパティの設定 1

- スタンバイREDOログ・ファイルの設定 1

- 単一コマンド・モード 1

- 起動 1

- 停止 1

- 文字列値 1

- コマンドの概要 1

- コマンド・プロンプトの抑止 1

- Data Guard構成ファイル

- Oracle RACデータベース 1

- CFS領域 1

- サーバー・パラメータ・ファイルとの一貫性がない値 1

- DMONプロセスに関連 1

- 設定 1

- Data Guard構成

- 自動作成 1

- バックグラウンド 1

- Data Guardモニター(DMON)

- Oracleデータベースとの相互作用 1

- オブジェクトの管理 1 , 2 , 3

- Oracleデータベースのバックグラウンド・プロセス 1

- 概要 1

- 双方向ネットワーク通信 1

- データ保護モード

- 「保護モード」を参照

- DBA_LOGSTDBY_EVENTS表

- 管理 1

- DbFileNameConvertプロパティ 1

- DBMS_DGパッケージ

- ファスト・スタート・フェイルオーバーを指示するために使用 1

- 遅延

- DelayMinsプロパティによるREDOデータの適用 1

- DelayMinsプロパティ 1

- 接続先

- アーカイブREDOログ・ファイルのパラメータ 1

- LogXptStatusプロパティの表示 1

- DG_BROKER_CONFIG_FILEnファイル

- CFS領域 1

- DG_BROKER_START初期化パラメータ 1 , 2 , 3

- DGConnectIdentifierプロパティ 1

- DGMGRL

- データベースの回復 1

- 診断情報

- ソース 1

- DISABLE CONFIGURATIONコマンド

- 例 1

- DISABLE DATABASEコマンド

- 例 1

- DISABLE FAR_SYNCコマンド 1 , 2

- DISABLE FAST_START FAILOVERコマンド 1

- DISABLE FAST_START FAILOVER CONDITIONコマンド 1

- 無効化

- ブローカ構成 1 , 2

- スタンバイ・データベースのブローカ管理 1

- データベース 1 , 2

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

- スタンバイ・データベース 1

- 障害時の保護

- メリット 1

- 表示

- 構成情報 1

- DGMGRLコマンドのヘルプ 1

- 分散管理フレームワーク 1

- DMON

- 「Data Guardモニター(DMON)」を参照

- ダウングレード

- Data Guard 1

- Oracle Enterprise Manager 1

- 保護モード 1

- drc*ログ・ファイル

- ブローカ診断情報 1

- 回復時 1

- 失敗した回復の記録 1

E

- EDIT CONFIGURATION (プロパティ)コマンド 1

- EDIT CONFIGURATION (保護モード)コマンド 1

- EDIT CONFIGURATION (RENAME)コマンド 1 , 2

- EDIT CONFIGURATION RESET (プロパティ)コマンド 1 , 2

- EDIT DATABASE(プロパティ)コマンド

- 例 1

- EDIT DATABASE (プロパティ)コマンド 1 , 2

- EDIT DATABASE (名前の変更)コマンド 1

- EDIT DATABASE (状態)コマンド

- 例 1

- EDIT DATABASE RESET (プロパティ)コマンド 1

- EDIT FAR_SYNCコマンド 1

- EDIT FAR_SYNC RESET (プロパティ)コマンド 1

- 編集

- 構成可能なプロパティ 1

- データベース・インスタンス 1 , 2 , 3

- データベース名 1

- データベースの状態 1

- 保護モード 1

- EDIT INSTANCE (AUTO PFILE)コマンド 1

- EDIT INSTANCE (プロパティ)コマンド 1 , 2

- EDIT INSTANCE RESET (プロパティ)コマンド 1

- スイッチオーバーによる影響 1

- 電子メール

- イベントのレポート 1

- ENABLE CONFIGURATIONコマンド 1 , 2

- ENABLE DATABASEコマンド 1

- ENABLE FAR_SYNCコマンド 1

- ENABLE FAST_START FAILOVERコマンド 1

- ENABLE FAST_START FAILOVER CONDITIONコマンド 1

- 有効化

- ブローカ構成 1 , 2

- ブローカ構成内のデータベース 1

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

- Enterprise Editionデータベース

- インストール 1

- Enterprise Manager

- ファスト・スタート・フェイルオーバー・ウィザード

- ファスト・スタート・フェイルオーバーの無効化 1

- ウィザード

- スタンバイ・データベースの自動作成 1

- エラー・メッセージ

- ORA-16795 1

- ERRORステータス 1

- イベント

- 管理

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

- Oracle Enterprise Managerを使用した監視, 1

- Oracle Enterprise Manager 1

- レポート 1

- 応答 1

- EXITコマンド 1 , 2

- 「QUITコマンド」も参照

F

- フェイルオーバー

- スタンバイ・データベースへのフェイルオーバー 1

- Oracle Enterprise Manager 1

- FAILOVERコマンド 1 , 2

- フェイルオーバー

- メリット 1

- ブローカの作業 1

- ターゲット・スタンバイ・データベースの選択 1

- 完全 1

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

- データ保護モードへの影響 1

- 即時 1

- 管理

- ファスト・スタート 1

- 手動 1

- 手動

- 完全オプション 1

- データ保護モードへの影響 1

- 即時オプション 1

- 無効化されたデータベースの再有効化 1

- 手動による起動 1

- DGMGRLの使用 1

- 障害

- オブザーバ 1

- 遠隔同期インスタンス

- 管理 1

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

- fsfo.datファイル内の構成情報 1

- 定義済 1

- オブザーバとしてのDGMGRLクライアント 1

- アプリケーションからの指示 1

- 無効化

- 手動フェイルオーバーを実行 1

- 有効化 1

- インスタンス障害 1

- オブザーバによる監視 1

- オブザーバの概要 1

- 有効化されている場合の手動フェイルオーバーの実行 1

- 有効化されている場合のスイッチオーバーの実行 1

- V$DATABASEの問合せ 1

- 元のプライマリ・データベースの回復 1

- 要件 1

- 停止後のデータベースの再起動 1

- FastStartFailoverThresholdプロパティの設定 1

- 強制終了 1 , 2

- Oracle RACデータベース・インスタンス 1

- 監視されない 1

- フェイルオーバー構成統計の表示 1

- FastStartFailoverAutoReinstateプロパティ 1

- FastStartFailoverLagLimitプロパティ 1

- FastStartFailoverPmyShutdownプロパティ 1

- FastStartFailoverTargetプロパティ 1

- FastStartFailoverThresholdプロパティ

- 設定 1

- FASTSYNC REDO転送モード 1

- FASTSYNC REDO転送サービス 1

- ファイル

- サーバー・パラメータ・ファイルのネーミング 1

- フラッシュバック・データベース

- データベースの回復 1

- フェイルオーバー後に使用 1

- フラッシュバック・ログ

- 障害が発生したプライマリ・データベースの回復 1

- FORCEオプション

- 手動フェイルオーバーの実行 1

- FS_FAILOVER_OBSERVER_HOST列

- V$DATABASEビュー 1

- FS_FAILOVER_OBSERVER_PRESENT列

- V$DATABASEビュー 1

- FS_FAILOVER_STATUS列

- V$DATABASEビュー

- 失敗した回復 1

- FSFO.DATファイル

- 概要 1

H

- 健全性チェック

- 監視 1

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

- スタンバイ・データベース 1

- 構成ステータス 1

- HELPコマンド 1

- 高可用性

- メリット 1

- データ保護のレベル 1 , 2

- LogXptModeプロパティ 1

- ファスト・スタート・フェイルオーバー後のリストア 1

I

- 即時フェイルオーバー 1 , 2

- InconsistenLogXptPropsプロパティ 1

- InconsistentPropertiesプロパティ 1

- スケーラビリティの向上

- メリット 1

- 初期化パラメータ

- データベースの構成可能なプロパティ 1

- DG_BROKER_CONFIG_FILEn 1

- DG_BROKER_START 1 , 2

- 動的 1

- 静的 1

- インストール

- ARCHIVELOGモードの設定 1

- Data Guard 1

- Oracle Enterprise Manager 1

- Oracle Instant Client 1 , 2

- 前提条件 1

- インスタンス

- 障害 1

- 削除 1 , 2

- 停止 1

- 起動 1

- インテンド状態

- 構成の健全性チェック 1

L

- ブローカ構成のライフ・サイクル 1

- LOG_ARCHIVE_MIN_SUCCEED初期化パラメータ 1

- ログ適用サービス

- 適用インスタンスのフェイルオーバー 1

- パラレル適用 1

- 適用インスタンス 1

- 構成 1

- Data Guard構成 1

- REDOデータの適用の遅延 1

- 遅延 1

- Oracle RACデータベース 1

- 管理 1

- 適用インスタンスの選択 1

- 確認 1

- LogArchiveFormatプロパティ 1

- LogArchiveMaxProcessesプロパティ 1

- LogArchiveMinSucceedDestプロパティ 1

- LogArchiveTraceプロパティ 1

- LogFileNameConvertプロパティ 1

- ログ・ファイル

- ブローカ 1

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

- イベントの管理 1

- SQL Apply 1

- 状態遷移 1

- プライマリ・ロールへのスイッチオーバー 1

- LogShippingプロパティ 1

- LogXptModeプロパティ 1

- LogXptStatusプロパティ 1

- LsbyFailedTxnInfoプロパティ 1

- LsbyMaxEventsRecordedプロパティ 1

- LsbyMaxServersプロパティ 1

- LsbyMaxSgaプロパティ 1

- LsbyParametersプロパティ 1

- LsbyPreserveCommitOrderプロパティ 1

- LsbyRecordAppliedDdlプロパティ 1

- LsbyRecordSkipDdlプロパティ 1

- LsbyRecordSkipErrorsプロパティ 1

M

- 管理

- メリット 1

- Oracle Enterprise Manager 1

- 管理

- ブローカ構成 1 , 2

- データベース 1

- DBA_LOGSTDBY_EVENTS表 1

- イベント

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

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

- ローカル操作 1

- ログ適用サービス 1

- 手動フェイルオーバー 1

- フィジカル・スタンバイ・データベースでのパラレル適用 1

- リモート操作 1

- ロール

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

- 手動フェイルオーバー 1

- スイッチオーバー 1

- スイッチオーバー 1

- 手動フェイルオーバー

- 完全オプション 1

- 保護モードへの影響 1

- 即時オプション 1

- ファスト・スタート・フェイルオーバーが有効化されている場合の実行 1 , 2

- 起動 1

- 手動ロール変更

- ファスト・スタート・フェイルオーバーが有効化されている場合の実行 1

- MaxConnectionsプロパティ 1

- MaxFailureプロパティ 1

- 最大可用性 1 , 2 , 3

- 最大データ保護 1 , 2 , 3

- 最大パフォーマンス 1 , 2 , 3

- 最大可用性

- データ保護モード 1

- 最大パフォーマンス

- データ保護モード 1

- 最大保護

- データ保護モード 1

- 監視可能なプロパティ

- InconsistentLogXptProps 1

- InconsistentProperties 1

- LogXptStatus 1

- LsbyFailedTxnInfo 1

- LsbyParameters 1

- RecvQEntries 1

- SendQEntries 1

- TopWaitEvents 1

- 監視

- ブローカ構成 1 , 2 , 3

- ローカルおよびリモート・データベース 1

- Oracle Enterprise Managerパフォーマンス・ページ 1

- コマンドライン・インタフェースを使用 1

- マルチテナント・コンテナ・データベース

- 「CDB」を参照 1

N

- NetTimeoutプロパティ 1

- ネットワーク

- Data Guard構成 1

- ファイルの設定 1

- 双方向通信 1

- NORMALステータス 1

O

- オブジェクト

- ブローカ構成 1

- 無効化 1

- データベースのプロパティ 1

- オブザーバ

- FastStartFailoverThresholdプロパティ 1

- 構成に接続 1

- ローカル・コンピュータへの接続 1

- 検出

- データベース停止 1 , 2

- インスタンス障害 1

- 障害 1

- ホスト・マシン名の検索 1

- Oracle Instant Clientキットのインストール 1 , 2

- 接続の消失 1

- ファスト・スタート・フェイルオーバー構成情報のメンテナンス 1

- 監視 1

- 停止 1

- 接続資格証明に対するOracleウォレットの使用 1

- ObserverConnectIdentifierプロパティ 1

- ObserverOverrideプロパティ 1

- ObserverReconnectプロパティ 1

- 操作

- 完全フェイルオーバー 1

- ブローカ管理の無効化

- 保護モードへの影響 1

- ダウングレード

- 保護モードへの影響 1

- 保護モードへの影響 1

- ブローカ管理の有効化

- 保護モードへの影響 1

- フェイルオーバー 1

- 即時フェイルオーバー 1

- 手動フェイルオーバー

- 保護モードへの影響 1

- 構成からのデータベースの削除

- 保護モードへの影響 1

- OperationTimeoutプロパティ 1

- ORA-16661メッセージ

- データベースの回復 1 , 3

- ORA-16795メッセージ

- データベースの再作成 1

- Oracle Clusterware

- Oracle RACデータベースのインスタンス 1

- Data Guard Brokerとの統合 1

- 障害インスタンスのリカバリ 1

- Oracle Enterprise Manager

- スタンバイ・データベースの追加ウィザード 1

- データベース・プロパティ・ページ 1

- ダウングレード 1

- イベント管理システム 1

- 統合 1

- Data Guardモニターとの統合 1

- 概要 1 2

- Oracle Net Servicesの構成変更 1 , 2

- イベントの監視 1

- パフォーマンス・ツールとグラフ 1

- アップグレード 1

- ウィザード

- スタンバイ・データベースの作成 1

- Oracle Instant Client

- インストール 1 , 2

- Oracle Managed Files(OMF)

- 使用するスタンバイ・データベースの作成 1

- Oracle Net Services

- 構成変更 1 , 2

- インストールの前提条件 1

- サポートされる構成 1

- 双方向通信 1

- Oracle RAC One Node

- Oracle Data Guard Brokerでサポート 1

- Oracle Real Application Clusters

- ログ適用サービス 1

- 適用インスタンスの設定 1

- Oracle Clusterwareにおけるインスタンスの可用性 1

- メリット 1

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

- オブザーバの動作 1

- オブザーバのインスタンスへの接続 1

- Oracle Clusterware 1

- Oracle Universal Installer

- Oracle Instant Clientのインストール 1 , 2

- Oracleウォレット

- オブザーバの起動 1

P

- パラレル適用

- ログ適用サービス 1

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

- パフォーマンス

- Oracle Enterprise Managerツール 1

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

- パラレル適用の管理 1

- 状態遷移 1

- プライマリ・ロールへのスイッチオーバー 1

- PreferredApplyInstanceプロパティ 1

- 前提条件

- インストール 1

- スイッチオーバー 1

- プライマリ・データベース

- ARCHIVELOGモード 1

- スタンバイ・データベースの作成 1 , 2

- Data Guard構成 1

- フェイルオーバー時 1

- スイッチオーバー時 1

- フラッシュバック・データベース 1

- 健全性チェック 1

- スイッチオーバーの準備 1

- ファスト・スタート・フェイルオーバー後の回復 1

- 状態遷移 1

- スタンバイ・ロールへの切替え 1

- PrimaryLostWriteActionプロパティ 1

- プロセス

- DMON 1

- Oracle Database 1

- プロパティ

- 構成可能 1

- データベース 1

- 管理 1

- 監視可能 1

- 設定

- サーバー・パラメータ・ファイル内 1 , 2

- プロパティ・ページ

- データベース 1

- 保護モード

- フェイルオーバー後 1 , 2 , 3

- メリット 1

- 構成 1 , 2 , 3

- ダウングレード 1

- REDO転送サービス設定 1

- ブローカ構成に関する設定 1

- 更新 1

- アップグレード 1

Q

- QUITコマンド 1 , 2

- 「EXITコマンド」も参照

R

- RecvQEntriesプロパティ 1

- REDO Apply 1 , 2

- RedoCompressionプロパティ 1

- RedoRoutesプロパティ 1

- REDO転送サービス

- ASYNCモード 1

- 構成

- データ保護モード 1

- Data Guard構成 1

- FASTSYNCモード 1 2

- 管理 1

- SYNCモード 1

- チューニング 1

- 無効化 1

- 有効化 1

- 確認 1

- REINSTATE DATABASEコマンド 1

- 回復

- ブローカのdrc*ログ・ファイルに記録された障害 1

- フラッシュバック・データベースの要件 1

- フラッシュバック・ログの要件 1

- 方法 1

- ブローカ・ログ・ファイルに記録 1

- ORA-16661メッセージ 1 , 3

- DGMGRLの使用 1

- Enterprise Managerの使用 1

- REMOVE CONFIGURATIONコマンド

- 例 1

- REMOVE DATABASEコマンド 1

- REMOVE FAR_SYNCコマンド 1

- REMOVE INSTANCEコマンド 1

- 削除

- スタンバイ・データベース 1

- ReopenSecsプロパティ 1

- 要求

- サイト間のやりとり 1

- 要件

- ファスト・スタート・フェイルオーバーの有効化 1

- 再起動

- データベース

- ファスト・スタート・フェイルオーバーが有効化されている場合 1

- ロール遷移

- 変更 1

- 管理

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

- 手動フェイルオーバー 1

- スイッチオーバー 1

S

- スクリプト

- Data Guardコマンドライン・インタフェース(DGMGRL)の使用 1

- 適用インスタンスの選択 1

- SendQEntriesプロパティ 1

- サーバー・パラメータ・ファイル

- ブローカのプロパティ管理 1 , 2

- ファイル名 1

- Data Guard構成ファイルとの一貫性がない値 1

- サーバー側ソフトウェア 1

- SET STATEコマンド

- 適用インスタンスの設定 1

- 設定

- 構成の保護モード 1

- データベース・プロパティ 1

- ログ適用サービス 1

- REDO転送サービス 1

- SGAメモリー

- SQL Apply 1

- SHOW CONFIGURATIONコマンド 1 , 2 , 3

- SHOW DATABASEコマンド 1

- SHOW FAR_SYNCコマンド 1

- SHOW FAST_START FAILOVERコマンド 1

- 表示

- 各SHOWコマンドを参照

- SHOW INSTANCEコマンド 1

- 強制終了

- ファスト・スタート・フェイルオーバーへの影響 1

- SHUTDOWNコマンド 1

- Oracleインスタンスの停止 1

- SidNameプロパティ 1

- 単一コマンド・モード

- Data Guardコマンドライン・インタフェース 1

- SQL Apply

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

- スイッチオーバーによる影響 1

- SQLコマンド 1

- SQL文

- DGMGRLコマンドラインからの実行 1

- StandbyArchiveLocationプロパティ

- ログ適用サービスの設定 1

- スタンバイ・データベース

- ターゲット・スタンバイ・データベースの選択 1

- バックアップからの作成 1 , 2

- 作成

- プライマリ・データベースでASMまたはOMFが使用されている場合 1

- 健全性チェック 1

- スイッチオーバーに関係しない 1

- フェイルオーバー後に再有効化 1

- 削除 1

- アーカイブREDOログの場所を指定 1

- プライマリ・ロールへの切替え 1

- StandbyFileManagementプロパティ 1

- スタンバイREDOログ・ファイル

- DGMGRLによる設定 1

- 起動

- Data Guardコマンドライン・インタフェース(DGMGRL) 1 , 2

- Data Guardモニター(DMON) 1

- 手動フェイルオーバー 1

- Oracleインスタンス 1

- スイッチオーバー 1

- START OBSERVERコマンド

- ファスト・スタート・フェイルオーバー構成ファイル(fsfo.dat) 1

- STARTUPコマンド 1

- 状態

- 変更 1

- データベース 1

- データベースの遷移 1

- 状態遷移

- データベースの状態への影響 1

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

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

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

- StaticConnectIdentifierプロパティ 1

- ステータス

- 構成 1

- プライマリ・データベースでの健全性チェック 1

- スタンバイ・データベースでの健全性チェック 1

- データベースの健全性 1

- 構成のインテンド状態 1

- ステータス・メッセージ

- ORA-16661 1

- ORA-16795 1

- STOP OBSERVERコマンド 1 , 2

- 文字列値

- Data Guardコマンドライン・インタフェース 1

- SWITCHOVERコマンド 1 , 2

- スイッチオーバー

- メリット 1

- ブローカの作業 1

- ターゲット・スタンバイ・データベースの選択 1

- DGMGRL SWITCHOVERコマンド 1

- 影響

- データベースの起動 1

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

- 保護モード 1

- スイッチオーバーに関係しないスタンバイ・データベース 1

- 管理 1 , 2

- 概要

- Oracle Enterprise Manager 1

- ファスト・スタート・フェイルオーバーが有効化されている場合の実行 1

- プライマリ・データベースの準備 1

- 前提条件 1

- 無効化されたスタンバイ・データベースの再有効化 1

- 起動 1

- 遷移

- ロジカル・スタンバイ・データベースをプライマリ・ロールへ 1

- フィジカル・スタンバイ・データベースをプライマリ・ロールへ 1

- DGMGRL SWITCHOVERコマンドの使用 1

- SYNC REDO転送モード 1

- SYSDBA権限

- データベースへの接続 1

T

- ターゲット・スタンバイ・データベース

- 選択 1

- ファスト・スタート・フェイルオーバーの無効化 1

- TopWaitEventsプロパティ 1

- TraceLevelプロパティ 1

- トランザクションのコミット順序

- 制御 1

- TransportDisconnectedThresholdプロパティ 1

- TransportLagThresholdプロパティ 1

- TRANSPORT-ON状態

- LogShippingプロパティの設定 1

- トラブルシューティング

- Data Guard 1

- ブローカのdrc*ログ・ファイルに記録された診断 1

- チューニング

- REDO転送サービス 1

- 双方向通信チャネル 1

U

- 監視されない構成 1

- 構成プロパティの更新 1

- アップグレード

- Data Guard 1 , 2

- Oracle Enterprise Manager 1

- 保護モード 1

- ユーザー・インタフェース

- 概要 1

V

- V$DATABASEビュー

- ファスト・スタート・フェイルオーバーの列 1

- FS_FAILOVER_OBSERVER_HOST列 1

- FS_FAILOVER_OBSERVER_PRESENT列 1

- 表示

- ファスト・スタート・フェイルオーバーの統計 1

- V$FS_FAILOVER_STATSビュー 1

- VALIDATE DATABASEコマンド 1

- VALIDATE FAR_SYNCコマンド 1

- 表示

- データベースのプロパティ情報 1 , 2

W

- WARNINGステータス 1

- ウィザード

- スタンバイ・データベースの追加 1

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。