Oracle® Data Guard

Broker

11gリリース2 (11.2)

B56304-09(原本部品番号:E40771-07)

2015年11月

Oracle Data Guard Broker, 11gリリース2(11.2)

B56304-09

Copyright © 1999, 2015, Oracle and/or its affiliatesAll rights reserved.

原本著者: Kathy Rich

原本協力者: Gary Allison, George Claborn, Sean Connolly, Jay Davison, Ray Dutcher, Mahesh Girkar, Michael Harvey, Nitin Karkhanis, Sadhana Kyathappala, Steve Lee, Jiangbin Luo, Venkat Maddali, Bob McGuirk, Ashish Ray, Vivian Schupmann, Lawrence To, Stephen Vivian, Hongjie Yang

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

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

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

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 Data Guard Broker 11.2.0.4の新機能

- Oracle Data Guard Broker 11.2.0.3の新機能

- Oracle Data Guard Broker 11.2の新機能

- Oracle Data Guard Broker 11.1の新機能

1 Oracle Data Guard Brokerの概要

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

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

- 1.1.2 Oracle Data Guard Broker

- 1.2 Data Guard Brokerのメリット

- 1.3 Data Guard Brokerの管理モデル

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

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

- 1.5.1 Oracle Enterprise Manager

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

- 1.6 Data Guardモニター

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

- 1.6.2 構成管理

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

2 Oracle Data Guardのインストール

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

- 2.2 前提条件

3 ブローカ構成の管理

- 3.1 構成のサポート

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

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

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

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

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

- 3.2.2.3 構成ファイルに対するRAWデバイスの使用

- 3.3 Data Guard Brokerの起動

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

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

- 3.6 構成ステータス

4 データベースの管理

- 4.1 データベース・オブジェクト

- 4.2 データベースの状態

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

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

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

- 4.3.2 構成可能(変更可能)なデータベースのプロパティ

- 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 Oracle RACデータベース環境でのREDO転送サービス

- 4.4.7 転送ラグ

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

- 4.5.1 遅延適用の管理

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

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

- 4.5.4 SQL Applyフィルタの管理

- 4.5.5 SQL Applyエラー処理の管理

- 4.5.6 DBA_LOGSTDBY_EVENTS表の管理

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

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

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

- 4.5.8 適用ラグ

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

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

- 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.7.1 ファスト・スタート・フェイルオーバーをチューニングするプロパティの構成

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

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

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

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

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 ブローカによる完全フェイルオーバー操作の実行方法

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

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

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

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

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

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

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

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

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

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

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

- 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.8 ブローカ構成に含まれる元のプライマリ・データベースの回復

- 5.5.8.1 要件

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

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

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

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

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

- 5.6.1.1 Oracle Netの構成要件

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

- 5.6.1.3 ONSの構成要件

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

- 6.1 初期使用の前提条件

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

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

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

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

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

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

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

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

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

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

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

- 6.7.2.1 構成の無効化

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

- 6.7.3 構成またはスタンバイ・データベースの削除

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

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

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

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

- 6.12 使用例11: Data Guard構成の監視

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

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

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

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

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

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

- ADD DATABASE

- CONNECT

- CONVERT DATABASE

- CREATE CONFIGURATION

- DISABLE CONFIGURATION

- DISABLE DATABASE

- DISABLE FAST_START FAILOVER

- DISABLE FAST_START FAILOVER CONDITION

- EDIT CONFIGURATION(プロパティ)

- EDIT CONFIGURATION(保護モード)

- EDIT DATABASE(プロパティ)

- EDIT DATABASE(名前の変更)

- EDIT DATABASE(状態)

- EDIT INSTANCE (AUTO PFILE)

- EDIT INSTANCE(プロパティ)

- ENABLE CONFIGURATION

- ENABLE DATABASE

- ENABLE FAST_START FAILOVER

- ENABLE FAST_START FAILOVER CONDITION

- EXIT

- FAILOVER

- HELP

- QUIT

- REINSTATE DATABASE

- REMOVE CONFIGURATION

- REMOVE DATABASE

- REMOVE INSTANCE

- SHOW CONFIGURATION

- SHOW DATABASE

- SHOW FAST_START FAILOVER

- SHOW INSTANCE

- SHUTDOWN

- START OBSERVER

- STARTUP

- STOP OBSERVER

- SWITCHOVER

8 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 LsbySkipTable(ロジカル・スタンバイ・スキップ表)

- 8.2.7 LsbySkipTxnTable(SQL Applyスキップ・トランザクション表)

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

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

- 8.2.10 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 LsbyASkipCfgPr

- 8.3.19 LsbyASkipErrorCfgPr

- 8.3.20 LsbyASkipTxnCfgPr

- 8.3.21 LsbyDSkipCfgPr

- 8.3.22 LsbyDSkipErrorCfgPr

- 8.3.23 LsbyDSkipTxnCfgPr

- 8.3.24 LsbyMaxEventsRecorded

- 8.3.25 LsbyMaxSga

- 8.3.26 LsbyMaxServers

- 8.3.27 LsbyPreserveCommitOrder

- 8.3.28 LsbyRecordAppliedDdl

- 8.3.29 LsbyRecordSkipDdl

- 8.3.30 LsbyRecordSkipErrors

- 8.3.31 MaxConnections

- 8.3.32 MaxFailure

- 8.3.33 NetTimeout

- 8.3.34 ObserverConnectIdentifier

- 8.3.35 PreferredApplyInstance

- 8.3.36 RedoCompression

- 8.3.37 ReopenSecs

- 8.3.38 SidName

- 8.3.39 StandbyArchiveLocation

- 8.3.40 StandbyFileManagement

- 8.3.41 StaticConnectIdentifier

- 8.3.42 TransportDisconnectedThreshold

- 8.3.43 TransportLagThreshold

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

- 9.1 診断情報のソース

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

- 9.2.1 ORA-16596: データベースがData Guard Broker構成の一部ではありません

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

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

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

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

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

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

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

- 9.3.1.1 元のプライマリ・データベースの変換の失敗

- 9.3.1.2 ターゲット・フィジカル・スタンバイ・データベースの変換の失敗

- 9.3.1.3 新規プライマリ・データベースのオープンの失敗

- 9.3.2 ロジカル・スタンバイ・データベースへのスイッチオーバーの失敗

- 9.3.2.1 元のプライマリ・データベースの変換の失敗

- 9.3.2.2 ターゲット・ロジカル・スタンバイ・データベースの変換の失敗

- 9.3.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 変更および非推奨になった機能

- A.1 変更があった機能

- A.1.1 変更があった一般機能

- A.1.1.1 リリース11.2で変更があった機能

- A.1.1.2 リリース11.1で変更があった機能

- A.1.1.3 リリース10.2で変更があった機能

- A.1.2 変更があったプロパティ

- A.1.2.1 リリース11.2で変更があったプロパティ

- A.1.2.2 リリース11.1で変更があったプロパティ

- A.1.2.3 リリース10.2で変更があったプロパティ

- A.1.3 変更があった状態名

- A.1.4 リリース10.2で変更があったDGMGRL機能

- A.2 非推奨および使用中止になった機能

- A.2.1 リリース11.2で非推奨および使用中止になった機能

- A.2.2 リリース11.1で非推奨および使用中止になった機能

- A.2.2.1 リリース11.1で非推奨および使用中止になったプロパティ

- A.2.3 リリース10.2で非推奨および使用中止になった機能

- A.2.3.1 リリース10.2で非推奨および使用中止になったプロパティ

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

- B.1 リリース9.2.0からリリース11.2へのアップグレード

- B.2 リリース10.nおよび11.1からリリース11.2へのアップグレード

- B.3 リリース11.2.0.1から11.2.0.2および他のパッチ・リリースへのアップグレード

- B.4 リリース11.2からのダウングレード

用語集

索引

例一覧

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

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

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

- 6-1 ローカル・システム上のプライマリ・データベースへの接続

- 6-2 リモート・システム上のプライマリ・データベースへの接続

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

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

- 6-5 構成とプライマリ・データベースの無効化

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

図一覧

- 1-1 Data Guard Brokerにより管理されるオブジェクトの関係

- 1-2 Oracle Data Guard Broker

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

- 3-1 Oracle Data Guard Broker構成

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

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

- 3-4 RAWデバイスでのブローカ構成の設定

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

- 5-1 プライマリ・データベースおよびスタンバイ・データベースとオブザーバの関係

- 5-2 ファスト・スタート・フェイルオーバー環境でのオブザーバ

表一覧

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

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

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

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

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

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

- 7-2 健全性条件の例

- 8-1 構成プロパティ

- A-1 リリース11.2で変更があったプロパティ

- A-2 リリース11.1で変更があったプロパティ

- A-3 リリース10.2で変更があったプロパティ

- A-4 リリース11.1でのデータベースの状態名の変更

- A-5 リリース11.1で非推奨および使用中止になったプロパティ

- A-6 リリース10.2で非推奨および使用中止になったプロパティ

はじめに

このマニュアルでは、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、Oracle Real Application Clustersおよび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インストレーション・ガイド

- Oracle Enterprise ManagerによるOracle Data Guardの管理の詳細は、このグラフィカル・ユーザー・インタフェースで利用できるオンライン・ヘルプを参照してください。オンライン・ヘルプのトピックにアクセスするには、Enterprise Managerでメニュー・バーの「ヘルプ」をクリックします。

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

Oracle Data Guard Brokerの新機能

この章では、Oracle Database 11gのOracle Data Guard Brokerに追加された新機能について説明し、関連項目へのリンクを示します。旧リリースで導入された機能については、そのリリースのドキュメントを参照してください。

Oracle Data Guard Broker 11.2.0.4の新機能

この項では、Oracle Database 11gリリース2(11.2.0.4)のOracle Data Guard Brokerに追加された新機能および機能拡張について説明します。

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

- ExternalDestination1およびExternalDestination2構成プロパティにより、現在のプライマリ・データベースからREDOデータを受信できるREDO転送先を設定できます。8.1.3項および8.1.4項を参照してください。

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

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

- PrimaryLostWriteAction構成プロパティは、プライマリ・データベースでの書込み欠落発生をスタンバイ・データベースで検出した場合の動作を決定します。8.1.12項を参照してください。

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

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

- 新しいV$FS_OBSERVER_HISTOGRAMビューで示される情報を使用すると、FastStartFailoverThreshold構成プロパティに対する適切な値の判断に役立ちます。8.1.8項を参照してください。

Oracle Data Guard Broker 11.2.0.3の新機能

この項では、Oracle Database 11gリリース2 (11.2.0.3)のOracle Data Guard Brokerに追加された新機能および機能拡張について説明します

- 新しいTraceLevel構成プロパティは、構成のすべてのデータベースに対してブローカが実行するトレースの量を制御できます。8.1.13項を参照してください。

Oracle Data Guard Broker 11.2の新機能

この項では、Oracle Database 11gリリース2(11.2)のOracle Data Guard Brokerに追加された新機能および機能拡張について説明します。

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

- ブローカ構成は、1つのプライマリ・データベースと最大30個のスタンバイ・データベースで構成できるようになりました。

- すべてのインスタンスのインスタンス固有のプロパティ値を、1つのコマンドで変更できます。

- REDO転送圧縮では、REDOギャップが解決される場合にのみREDOデータを圧縮するという制限がなくなりました。転送先に対して圧縮が有効である場合、その転送先に送信されるREDOデータはすべて圧縮されます。

- フィジカル・スタンバイまたはロジカル・スタンバイ・フェイルオーバー後の、その他のロジカル・スタンバイ・データベースの回復。

- 即時フェイルオーバー後のその他のデータベースの回復。

- 即時フェイルオーバー後の元のプライマリ・データベースの回復。

- ロール変更のために、ターゲット・フィジカル・スタンバイ上のインスタンスのうち1つを残して他のすべてのインスタンスを停止する必要はなくなりました。

- Oracle Clusterwareを使用して構成されたデータベースおよびOracle Restartに登録された単一インスタンス・データベースのフェイルオーバー後、高速アプリケーション通知/Oracle Notification Service(FAN/ONS)通知が送信されます。

- ロジカル・スタンバイ・データベースへのフェイルオーバー後、高速アプリケーション通知/アドバンスト・キューイング(FAN/AQ)通知が送信されます。

- SHOW CONFIGURATIONおよびSHOW DATABASEコマンドに関するステータスおよびエラーのレポートの改善。

- SHOW DATABASEコマンドで、スタンバイ・データベースの適用ラグと転送ラグが表示されます。

- 適用インスタンスがオープンされるときの、Active Data Guardとの統合(Applyの自動停止および自動再起動)。

- ブローカ構成ファイルを、4KB以下のセクター・サイズ(物理ブロック・サイズ)のディスクに格納できるようになりました。

- ブローカのネットワーク通信でのハングの検出および解決が改善されました。また、新しい構成プロパティCommunicationTimeoutにより、環境に適したタイムアウト値を選択できるようになりました。

- 新しいデータベース・プロパティStaticConnectIdentifierを使用して、DGMGRLクライアントがデータベース・インスタンスの起動に使用する静的接続識別子を指定できます。

- 保護モードを最大可用性から最大保護にアップグレードする際、プライマリ・データベースの再起動が不要になりました。
最大パフォーマンス・モードから最大保護モードにアップグレードする際、まず最大可用性モードにアップグレードすることで、プライマリ・データベースの再起動を回避できます。最大可用性モードにしたら、次に最大保護モードにアップグレードします。

- データ・リカバリ・アドバイザはData Guardを使用して、適時に修復できないプライマリ・データベースに対する有効な修復オプションを提案するようになりました。

Oracle Data Guard Broker 11.1の新機能

この項では、Oracle Database 11gリリース1(11.1)のOracle Data Guard Brokerに追加された新機能および機能拡張について説明します。

- ファスト・スタート・フェイルオーバーの機能拡張
次の機能により、Data Guardを使用した障害時リカバリ構成の柔軟性と管理性が向上します。

- 最大パフォーマンス・モードで動作している構成のファスト・スタート・フェイルオーバー
最大パフォーマンス・モードで動作しているData Guard Broker構成でファスト・スタート・フェイルオーバーを有効化できます。管理者は、ファスト・スタート・フェイルオーバーが開始された場合の最大消失データ量を選択できます。

- 新しいDBMS_DG PL/SQLパッケージ
DBMS_DG PL/SQLパッケージを使用すると、アプリケーションでオブザーバ・プロセスに通知して、ターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーを開始できます。

- 構成可能な条件でのファスト・スタート・フェイルオーバー
特定のデータベース条件が検出されたときにファスト・スタート・フェイルオーバーを実行するように構成できます。データベース健全性チェック・メカニズムによって検出される特定の条件やOracleサーバーが生成するエラー(ORAエラーなど)を、ファスト・スタート・フェイルオーバーが発生する条件として指定できます。

- フェイルオーバー後、オブザーバによりその他のスタンバイ・データベースの回復が自動的に試行されます。

参照:

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

- 『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_DG PL/SQLパッケージ

- 管理性の機能拡張
次の機能拡張により、Data Guard Brokerをより広範囲の障害時リカバリ構成で使用できます。

- スナップショット・スタンバイ・データベースのサポート

参照:
DGMGRLのCONVERT DATABASEコマンド

- 読取り専用でオープンされているフィジカル・スタンバイ・データベースでのREDO Applyのサポート

- REDO転送オプションのサポートの向上。管理者がREDO転送サービスの接続識別子を指定できるようになりました。

- 保護モードを最大可能性と最大パフォーマンスの間で変更する際のデータベース停止時間の削除

- Data Guard Broker構成のプライマリ・データベースまたはロジカル・スタンバイ・データベースは、自動的にオープンされずにマウント可能

- 構成にスタンバイ・データベースを追加するとき、DGMGRLクライアントのADD DATABASEコマンドを使用して、LOG_ARCHIVE_DEST_nパラメータから事前構成済のサービス属性をインポート可能。

- ブローカにより管理されるデータベースの状態の簡素化。プライマリ・データベースの状態は、TRANSPORT-OFFまたはTRANSPORT-ONのいずれかです。スタンバイ・データベースの状態は、APPLY-OFFまたはAPPLY-ONのいずれかです。

- Data Guard構成内でのネットワーク経由によるREDOトラフィックの圧縮
この機能は、スタンバイ・データベースの差分を満たすためにログが送信される際に、ネットワーク経由でスタンバイ・データベースに転送されるため、アーカイブREDOログを圧縮することにより、Data Guard構成内のネットワーク帯域幅の使用率を向上させます。

参照:
8.3.36項「RedoCompression」

- データベース・リカバリ領域との統合の向上。USE_DB_RECOVERY_FILE_DESTをインスタンス固有のプロパティAlternateLocationおよびStandbyArchiveLocationの値として指定できるようになりました。

- Data Guardコマンドライン・インタフェース(DGMGRL)の新規コマンドは、次のとおりです。

- CONVERT DATABASE TO [SNAPSHOT | PHYSICAL] STANDBY

- DISABLE FAST_START FAILOVER CONDITION

- ENABLE FAST_START FAILOVER CONDITION

- SHOW FAST_START FAILOVER

参照:
第7章「Data Guardコマンドライン・インタフェース・リファレンス」

- 新しいデータベース・プロパティは、次のとおりです。

- DGConnectIdentifier(InitialConnectIdentifierにかわるプロパティ)

- ObserverConnectIdentifier

- RedoCompression

- 新しい構成プロパティは、次のとおりです。

- FastStartFailoverAutoReinstate

- FastStartFailoverLagLimit

- FastStartFailoverPmyShutdown

- データベース・プロパティLsbyTxnConsistencyは、LsbyPreserveCommitOrderに名前が変更されました。

- データベース・プロパティLogXptModeのデフォルトがASYNCになりました。

参照:
第8章「Data Guard Brokerプロパティ」

1 Oracle Data Guard Brokerの概要

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

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

- Data Guard Brokerのメリット

- Data Guard Brokerの管理モデル

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

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

- Data Guardモニター

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

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

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

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

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

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

1.1.2 Oracle Data Guard Broker

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

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

- 既存のData Guard構成に対する新規または既存の(フィジカル、スナップショット、ロジカル、Oracle RACまたは非Oracle RAC)スタンバイ・データベースの追加。合計で、同一構成内に1つのプライマリ・データベースと1～30個のスタンバイ・データベースを構成します。

- 構成に含まれる任意のデータベースへのクライアント接続を介したData Guard構成全体の管理。管理対象には、すべてのデータベース、REDO転送サービスおよびログ適用サービスが含まれます。

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

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

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

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

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

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

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

ブローカがある場合

ブローカがない場合

全般

プライマリ・データベースとスタンバイ・データベースの管理が1つに統一された構成となります。

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

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

Enterprise Managerのウィザードによって、各サイトで単一のOracleデータベースによる構成を作成するための作業が自動化および簡素化されます。これらの作業には、スタンバイ制御ファイル、オンラインREDOログ・ファイル、データファイルおよびサーバー・パラメータ・ファイルの作成が含まれます。

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

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

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

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

- プライマリ・データベース・パスワード・ファイルをスタンバイ・データベース・システムにコピーします。

構成と管理

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

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

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

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

制御

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

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

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

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

- Enterprise ManagerのGrid Controlによって管理および監視できます。

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

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

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

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

監視

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

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

- Oracle Enterprise Managerイベントに統合されます。

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

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

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

1.2 Data Guard Brokerのメリット

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

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

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

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

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

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

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

Data Guard構成の作成の自動化: ブローカを使用すると、プライマリ・データベースとスタンバイ・データベース(フィジカルまたはロジカル、スナップショット、Oracle RACまたは非Oracle RAC)で構成されるData Guard構成を、論理的に定義および作成できます。Data Guard構成内のデータベース間での通信は、Oracle Net Servicesを使用して自動的に実行されます。データベースは、LANで接続されたローカル・データベースでも、WANを介して接続された地理的に散在するリモート・データベースでもかまいません。

Oracle Enterprise Managerには、次のように、ブローカ構成の作成に関連した複雑な作業を自動化するウィザードが用意されています。

- 既存のスタンバイ・データベースまたは新規に(Enterprise Managerを介して作成された既存のバックアップから)作成されたスタンバイ・データベースの追加

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

- スタンバイ・データベースとの通信の実行

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

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

DGMGRLでは新規スタンバイ・データベースを自動的に作成できませんが、DGMGRLコマンドを使用して、既存のスタンバイ・データベースを構成および監視できます。これには、Enterprise Managerを使用して作成されたスタンバイ・データベースが含まれます。

追加のスタンバイ・データベースの簡単な構成: プライマリ・データベースとスタンバイ・データベースで構成されるData Guard構成を作成した後は、各Data Guard構成に、新規または既存のフィジカル、スナップショットまたはロジカル・スタンバイ・データベースを29個まで追加できます。Oracle Enterprise Managerのスタンバイ・データベースの追加ウィザードを使用すると、指示に従って、さらにデータベースを追加できます。

管理の簡素化、集中化および拡張: コマンドを発行して、ブローカ構成の多くの側面を管理できます。次のような操作が可能です。

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

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

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

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

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

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

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

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

ビルトイン監視、アラート・メカニズムおよび制御メカニズム: ブローカには、構成に含まれるすべてのデータベースの健全性を監視するビルトインの検証機能が用意されています。構成内の任意のデータベースに接続している間、診断情報を取得し、集中化された監視、テストおよびパフォーマンスの各ツールを使用して、明白な問題と潜在的な問題を迅速に検出できます。Enterprise ManagerとDGMGRLはどちらも、プライマリ・データベース上のREDO転送サービスの進捗と、スタンバイ・データベース上のREDO ApplyまたはSQL Applyの進捗について、完全な構成ビューを取得します。

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

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

参照:
スタンバイ・データベースの作成に必要な個々の手順と、ブローカにより自動化または簡素化されている他の監視および制御操作の詳細は、『Oracle Data Guard概要および管理』を参照してください。

1.3 Data Guard Brokerの管理モデル

ブローカにより、次の論理オブジェクトに対する操作が実行され、Data Guard環境の管理が簡素化されます。

- データベースの構成

- 単一データベース

ブローカは、1つ以上のData Guard構成をサポートします。各構成には、プライマリ・データベースと各スタンバイ・データベースのプロファイルが含まれます。サポートされるブローカ構成は、次のオブジェクトで構成されます。

- 構成オブジェクト。このオブジェクトはデータベース・プロファイルの名前付きコレクションです。データベース・プロファイルは、現在の状態、現在のステータスおよびプロパティを含むデータベース・オブジェクトの記述です。構成オブジェクトのプロファイルには、1つのプライマリ・データベースとそのスタンバイ・データベース(フィジカル、スナップショットおよびロジカル・スタンバイ・データベースの混在が可能)が含まれます。特定の構成に含まれるデータベースは通常、複数のホスト・システム間に分散されます。

- データベース・オブジェクト。このオブジェクトは、プライマリ・データベースまたはスタンバイ・データベースに対応します。ブローカは、データベース・オブジェクトのプロファイルを使用して、特定システム上の単一データベースの状態を管理および制御します。Oracle RACデータベースの場合は、データベース・オブジェクトを1つ以上のインスタンス・オブジェクトで構成できます。

- インスタンス・オブジェクト。ブローカは、データベースを1つ以上の名前付きインスタンスのコレクションとして扱います。インスタンスは自動的に検出され、データベースに関連付けられます。

図1-1に、これらのオブジェクトの関係を示します。

図1-1 Data Guard Brokerにより管理されるオブジェクトの関係

参照:
構成とデータベース・オブジェクトの管理の詳細は、第3章、第4章および第5章を参照してください。

1.4 Data Guard Brokerのコンポーネント

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

- Oracle Enterprise Manager

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

- Data Guardモニター

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

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

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

図1-2 Oracle Data Guard Broker

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

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

- Oracle Enterprise Manager

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

1.5.1 Oracle Enterprise Manager

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.6 Data Guardモニター

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

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

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

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

参照:
ブローカの起動方法は、3.3項を参照してください。

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

参照:
Oracleデータベースで使用されるメモリー構造とプロセスの詳細は、『Oracle Database概要』を参照してください。

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

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

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

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

1.6.2 構成管理

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

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

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

参照:
詳細は、4.3項を参照してください。

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

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

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

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

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

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

参照:
詳細は、4.3.2項を参照してください。

2 Oracle Data Guardのインストール

この章の内容は、次のとおりです。

- Oracle Data Guardのインストール

- 前提条件

参照:
Data Guard Broker構成での新規リリースへのアップグレードに関するヘルプは、付録Bを参照してください。

2.1 Oracle Data Guardのインストール

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

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

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

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

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

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

2.2 前提条件

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

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

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

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

- DG_BROKER_START初期化パラメータの値は、TRUEに設定されている必要があります。詳細は、3.3項を参照してください。(このパラメータはEnterprise Managerによって自動的に設定されます。)

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

参照:
1.6.2項の構成ファイル情報を参照してください。また、ブローカ構成ファイルの設定の詳細は3.2項、RAWデバイスのサイズ設定の詳細は3.2.2.3項を参照してください。

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

参照:
『Oracle Database Net Services管理者ガイド』

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

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

- データベースは自分自身にアクセスできます。

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

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

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

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

- DGMGRLでブローカ操作中にインスタンスを再起動できるようにするには、各インスタンスのローカル・リスナーに静的サービスを登録する必要があります。また、ファスト・スタート・フェイルオーバーが発生した後、元のプライマリ・データベースの自動回復の一部としてオブザーバーがインスタンスを再起動できるようにするには、サービスを静的に登録する必要があります。デフォルトで、ブローカは静的サービス名を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 Clusterware環境では、この他に次の考慮事項も認識しておいてください。

- 静的サービスは、すべてのノードのGRID_HOMEにあるlistener.oraファイルで設定されている必要があります。

- 静的サービス定義のORACLE_HOME listener.oraパラメータは、GRID_HOMEではなく、インスタンスのORACLE_HOMEに設定する必要があります。

- ENVS listener.oraパラメータは、TNS_ADMIN環境変数を適切なネットワーク管理ディレクトリ(通常はOracleデータベースのOracleホームの管理ディレクトリ)に明示的に設定するために、静的サービス定義で使用する必要があります。

- Oracle RAC One Nodeまたはポリシー管理のOracle RAC環境では、可能な各インスタンスのSID_NAMEは、SID_LISTで指定されている必要があります。各インスタンスのSID_NAMEは、そのインスタンスのINSTANCE_NAMEデータベース初期化パラメータと一致する必要があります。Oracle RAC One Nodeまたはポリシー管理のOracle RAC環境では、INSTANCE_NAMEパラメータのデフォルト値は、db_unique_name_instance_numberです。

参照:

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

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

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

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

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

参照:

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

- ネットワーク・ファイルの設定の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- 『Oracle Database Net Services管理者ガイド』

3 ブローカ構成の管理

この章の内容は、次のとおりです。

- 構成のサポート

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

- Data Guard Brokerの起動

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

- 操作の有効化と無効化

- 構成ステータス

3.1 構成のサポート

ブローカを使用すると、プライマリ・データベースおよび1つ以上のスタンバイ・データベースから構成されるData Guard構成を論理的に定義できます。ブローカを使用して、ブローカ構成を定義します。これは、REDO転送サービスおよびログ適用サービスを含め、データベースを論理的にグループ化したものです。ブローカはDBAの裁量に従って、構成内の論理オブジェクトの制御、実行時のオブジェクト動作の変更、構成全体の健全性の監視、および健全性と他の操作特性のレポートを行います。これらの作業には、Oracle Enterprise Managerを使用している場合はOracle Enterprise Managerの通知メカニズム、DGMGRLを使用している場合はSHOWコマンドが使用されます。

ブローカは、Data Guard構成をサポートします。各構成は、1つのプライマリ・データベースと、そのプライマリ・データベースに対してローカルまたはリモートのスタンバイ・データベース(最大30個)で構成されます。データベースのいずれかにOracle Real Application Clusters(RAC)データベースを使用できます。

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

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

- 1から30個のフィジカル、スナップショットまたはロジカル(Oracle RACまたは非Oracle RAC)スタンバイ・データベース

- プライマリ・データベースとスタンバイ・データベースを管理する物理システム

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

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

- REDOデータをプライマリ・データベースからスタンバイ・データベースに転送するREDO転送サービス

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

Data Guardのログ適用サービスでは、スタンバイ・データベースが、REDO転送サービスによりプライマリ・データベースから自動的に転送されるREDOデータで更新されます。アーカイブREDOログ・ファイルとスタンバイREDOログ・ファイルには、リカバリ不能な変更や記録されていない変更を除き、すべてのデータベース変更が含まれています。フィジカル・スタンバイ・データベースでは、REDO ApplyによりREDOデータが適用され、スタンバイ・データベースとプライマリ・データベースとの一貫性が保たれます。ロジカル・スタンバイ・データベースでは、SQL ApplyによりREDOデータが適用され、スタンバイ・データベースとプライマリ・データベースとの一貫性が保たれます。スナップショット・スタンバイ・データベースでは、REDOデータを受け取りますが、スナップショット・スタンバイ・データベースがフィジカル・スタンバイ・データベースに逆変換されるまでは適用されません。

ブローカの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 ブローカ構成ファイルの設定

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

DG_BROKER_CONFIG_FILE1
DG_BROKER_CONFIG_FILE2

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

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

- これらのパラメータには、すべてのOracle RACインスタンスで共有するRAWデバイス、Oracle ASMファイルまたはクラスタ・ファイル・システムのファイルを指定する必要があります。

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

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

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

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

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

1. DGMGRL DISABLEコマンドを使用してブローカ構成を無効化します。3.5項を参照してください。

2. 次のSQL文を使用して、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. ファイルを移動する方法は、現在ファイルが格納されている場所およびファイルの移動先によって異なります。

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

- ファイルがRAWデバイスに格納されている場合は、新しい場所にファイルを手動で転送します。

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

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

SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;

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

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

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

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

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

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

- 構成ファイルに対するRAWデバイスの使用

3.2.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.2.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.2.2.3 構成ファイルに対するRAWデバイスの使用

CFSを使用できず、Oracle ASMを使用していない場合は、ファイルをRAWデバイスに格納する必要があります。この場合、各インスタンスのパラメータ値はRAWデバイスを指すように設定します。図3-4に、RAWデバイス上のブローカ構成ファイルの設定を示します。UNIXシステムでは、各ノードで次のように設定します。

% ln -s /dev/rdsk/c1t2d3s5 dr1inst1.dat
% ln -s /dev/rdsk/c1t2d3s6 dr2inst2.dat

図3-4 RAWデバイスでのブローカ構成の設定

ブローカ構成ファイルをRAWデバイスに格納する必要がある場合は、それぞれ1MBのRAWデバイスを2つ追加設定します。DG_BROKER_CONFIG_FILE1およびDG_BROKER_CONFIG_FILE2パラメータの値が、RAWデバイスを指すように設定します。1MBの構成ファイルは、データベース間に合計45のインスタンスを持つ10個のデータベースに対応します。

この構成のインスタンス数が46以上の場合は、さらに大きいデバイスが必要になる可能性があります。追加のインスタンスごとに15KBが必要になります。

3.3 Data Guard Brokerの起動

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

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

- Oracle Enterprise Managerを使用している場合、新規に作成されるスタンバイ・データベースの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

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

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

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

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

ブローカ構成の作成

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

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

ブローカ構成の有効化

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

注意:
DGMGRLを使用すると構成を有効化または無効化できます。Enterprise Managerを使用して構成を無効化することはできません。前にDGMGRLを使用して無効化した構成は、Enterprise Managerを使用して有効化できます。

ブローカ構成は、Enterprise Managerを使用して最初に作成された時点で、スタンバイ・データベースの追加ウィザードの完了後すぐに自動的に有効化されます。

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

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

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

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

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

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

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

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

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

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

参照:
ロール変更の詳細は、第5章を参照してください。

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

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

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

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

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

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

参照:
データベースの状態変更の詳細は、第4章を参照してください。

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

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

参照:
データベース・プロパティの詳細は、第4章および第8章を参照してください。

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

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

参照:
データ保護モードの管理の詳細は、4.6項を参照してください。

構成の監視

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

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

3.5 操作の有効化と無効化

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

- 指定されたデータベースの管理および監視

- 各データベースのブローカ構成ファイル内のプロファイル情報の管理

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

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

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

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

参照:
4.6.2項「保護モードによるブローカ操作への影響」

3.6 構成ステータス

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

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

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

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

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

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

4 データベースの管理

この章では、データベースに関係のある状態およびプロパティの管理について説明します。この章の内容は、次のとおりです。

- データベース・オブジェクト

- データベースの状態

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

- REDO転送サービスの管理

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

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

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

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

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

4.1 データベース・オブジェクト

データベース・オブジェクトは、ブローカにより管理されます。データベース・オブジェクトは、プライマリまたはスタンバイのデータベース・インスタンスに対応します。ブローカでは、各オブジェクトのプロファイルを使用して単一データベースの状態が管理および監視されます。

ブローカでは、フィジカル、スナップショットおよびロジカルの各スタンバイ・データベースが区別されます。これらのデータベースは、それぞれのスタンバイ・タイプに適した状態とプロパティを記述するプロファイルを使用して構成されます。

4.2 データベースの状態

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

スナップショット・スタンバイ・データベースは、状態を持たず、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コマンドの詳細は、第7章を参照してください。

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

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

プライマリ・データベースをTRANSPORT-ON状態に遷移する際に、ブローカはスタンバイ・データベースのREDO転送関連プロパティを使用して、すべての管理対象スタンバイ・データベースへのREDO転送サービスを設定します(すべてのREDO関連プロパティのリストは、4.4項を参照してください)。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転送サービスの管理の詳細は、4.4項を参照してください。

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

フィジカル・スタンバイ・データベースをAPPLY-ON状態に遷移する際に、ブローカはREDO Apply関連プロパティで指定されたオプションを使用してREDO Applyを起動します(プロパティ・リストについては4.5項を参照してください)。スタンバイ・データベースが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で記録された開始オプションと一致しないモードで開始される可能性があります。

スナップショット・スタンバイ・データベースの状態遷移

スナップショット・スタンバイ・データベースには状態がありません。REDOデータを受信するのみです。

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

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

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

参照:

- SQL Applyの管理の詳細は、4.5項を参照してください。

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

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

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

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

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

参照:
すべてのデータベース・プロパティの詳細リストについては、第8章を参照してください。

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

例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                      = 'sync'
DelayMins                       = '0'
Binding                         = 'optional'
MaxFailure                      = '0'
MaxConnections                  = '1'
ReopenSecs                      = '300'
NetTimeout                      = '30'
RedoCompression                 = 'DISABLE'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/bt, dbs/t'
LogFileNameConvert              = 'dbs/bt, dbs/t'
FastStartFailoverTarget         = 'South_Sales'
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
SidName                         = 'north_sales1'
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'
LatestLog                       = '(monitor)'
TopWaitEvents                   = '(monitor)'

Database Status:
SUCCESS

参照:
DGMGRLコマンドライン・インタフェースの詳細は、第7章を参照してください。

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

Enterprise Managerでは、これらのプロパティの情報は「プロパティの編集」ページに表示されます。

4.3.2 構成可能(変更可能)なデータベースのプロパティ

構成可能なデータベース・プロパティは、データベースの操作や構成に影響を与えます。DGMGRLまたはEnterprise Managerを使用して、新規ブローカ構成に、プライマリ・データベース・オブジェクトを作成したり既存のスタンバイ・データベースをインポートすると、最初にプロパティ値がデータベース設定からインポートされます。

多くのプロパティ値は、データベースが無効の場合でも有効の場合でも更新できます。構成に新規データベースを追加すると、ブローカはそのデータベースに接続し、現行のデータベース設定からデータベース・プロパティの初期値をインポートします。次に例を示します。

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.4 REDO転送サービスの管理

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

- DGConnectIdentifier

- AlternateLocation

- Binding

- LogShipping

- LogXptMode

- MaxConnections

- MaxFailure

- NetTimeout

- RedoCompression

- 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プロパティの初期値は、ADD DATABASEコマンドに指定したデータベースのDB_UNIQUE_NAMEと一致するDB_UNIQUE_NAME属性を持つLOG_ARCHIVE_DEST_n初期化パラメータのSERVICE属性から抽出されます。

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

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

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

REDO転送サービスにSYNCまたはASYNCモードを設定するには、データベース・プロパティLogXptModeを使用します。保護モードとREDO転送サービスの詳細は、表4-2を参照してください。

次に、LogXptModeプロパティの値について説明します。

SYNC

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

ASYNC

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

4.4.3 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-2および例4-3に、REDO転送サービスをオフにする方法を2つの使用例により示します。

例4-2 すべてのスタンバイ・データベースへの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-3 特定のスタンバイ・データベースへのREDO転送サービスをオフにする場合

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

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

4.4.4 アーカイブ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.5 その他のREDO転送設定

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

新規スタンバイ・データベースの作成時に、ブローカはこれらのプロパティをデフォルト値に設定します。既存のスタンバイ・データベースのインポート時には、現行の宛先のサービス文字列と、構成にデータベースを追加したときに指定した接続識別子との間で一致が見つかった場合、ブローカはこれらのプロパティに対応する既存の設定をインポートします。一致が見つからなかった場合は、現行の宛先のdb_unique_nameと、構成にデータベースを追加したときに指定した名前との間で一致を探します。

ほとんどの場合、通常の操作にはデフォルト値またはインポートされる値で十分です。なんらかの理由でこれらのプロパティ値を変更する必要がある場合は、DGMGRLコマンドラインを使用して各プロパティを設定できます。Enterprise Managerでは、これらの各プロパティを変更するためのインタフェースを提供していません。

参照:
これらのデータベース・プロパティの詳細は、第8章を参照してください。

4.4.6 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.7 転送ラグ

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

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

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

DGMGRL> show database 'South_Sales';
Database - South_Sales
Role:            PHYSICAL STANDBY
Intended State:  APPLY-ON
Transport Lag:   0 seconds
Apply Lag:       0 seconds
Real Time Query: OFF
Instance(s):
south_sales1

Database Status:
SUCCESS

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

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

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

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

- ApplyInstanceTimeout

- DelayMins

- PreferredApplyInstance

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

- ApplyParallel

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

- LsbyASkipTxnCfgPr

- LsbyDSkipTxnCfgPr

- LsbyASkipCfgPr

- LsbyDSkipCfgPr

- LsbyASkipErrorCfgPr

- LsbyDSkipErrorCfgPr

- LsbyMaxEventsRecorded

- LsbyPreserveCommitOrder

- LsbyRecordSkipErrors

- LsbyRecordSkipDdl

- LsbyRecordAppliedDdl

- LsbyMaxSga

- LsbyMaxServers

現在のデータベースの状態がAPPLY-ONの場合、SQL Apply関連のプロパティを変更すると、SQL Applyの再起動が必要になる場合があります。SQL Applyの再起動が必要なプロパティを調べるには、第8章の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は、Enterprise Managerの「プロパティの編集」ページには表示されません。

参照:
8.3.4項「ApplyParallel」のApplyParallelプロパティ

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

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

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

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

参照:
8.3.25項「LsbyMaxSga」および8.3.26項「LsbyMaxServers」

4.5.4 SQL Applyフィルタの管理

ロジカル・スタンバイ・データベースの利点の1つは、何を適用して何を適用しないかを制御できることです。そのためにはSQL Applyフィルタを設定します。フィルタの粒度は、データベース・オブジェクトに対する特定のトランザクション、特定のスキーマ上の特定クラスのSQL文などです。

Data Guard BrokerにSQL Applyフィルタを追加するには、データベース・プロパティLsbyASkip*(LsbyASkipTxnCfgPrまたはLsbyASkipCfgPrなど)を使用します。前に追加したSQL Applyフィルタを削除するには、データベース・プロパティLsbyDSkip*(LsbyDSkipTxnCfgPrまたはLsbyDSkipCfgPrなど)を使用します。

参照:
これらのプロパティの詳細は、第8章を参照してください。

4.5.5 SQL Applyエラー処理の管理

SQL Applyを微調整して、特定のスキーマの指定のSQL文セットに関する適用エラーを処理できます。この種のSQL Applyエラーが発生した場合、Data GuardではエラーをスキップしてSQL Applyを続行するか、またはエラー発生時に指定のストアド・プロシージャをコールできます。

このエラー処理機能を追加するには、データベース・プロパティLsbyASkipErrorCfgPrを使用します。前に追加したエラー処理指定を削除するには、データベース・プロパティLsbyDSkipErrorCfgPrを使用します。

データベースの現在の状態がAPPLY-ONの場合は、これらのプロパティを変更するとSQL Applyが再起動されます。データベースの現在の状態がAPPLY-OFFの場合、プロパティ変更はデータベースの状態が次回にAPPLY-ONに変化したときに有効になります。

4.5.6 DBA_LOGSTDBY_EVENTS表の管理

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

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

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

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

注意:
この項の情報は、スナップショット・スタンバイ・データベースには適用されません。

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

- 第1の方法では、適用インスタンスをOracle RACスタンバイ・データベースで実行される前に選択します。そのためには、データベース・プロパティPreferredApplyInstanceの値を、適用インスタンスとして指定するインスタンスの名前(SidNameプロパティを参照)に設定します。ブローカは、Oracle RACスタンバイ・データベースで適用インスタンスが選択されていない場合に、PreferredApplyInstanceプロパティで指定されたインスタンス上でログ適用サービスを起動します。この方法を使用するのは、スタンバイ・データベースをまだ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
Apply Lag:       0 seconds
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
Apply Lag:       0 seconds
Real Time Query: OFF
Instance(s):
south_sales1
south_sales2 (apply instance)

Database Status:
SUCCESS

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

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

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

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

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

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

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

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

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

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

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

参照:

- リアルタイム問合せモードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

- Active Data GuardのOracle RACスタンバイにおける適用インスタンス障害の詳細は、http://support.oracle.comにあるMy Oracle Supportノート1357597.1を参照してください。

4.5.8 適用ラグ

適用ラグは、REDOのスタンバイ・データベースへの伝播および適用の遅延により、スタンバイ・データベースのデータがプライマリ・データベースのデータからどの程度遅れているかを測定する尺度です。

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

DGMGRL> show database 'South_Sales';
Database - South_Sales
Role:            PHYSICAL STANDBY
Intended State:  APPLY-ON
Transport Lag:   0 seconds
Apply Lag:       0 seconds
Real Time Query: OFF
Instance(s):
south_sales1

Database Status:
SUCCESS

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

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

ブローカによって、様々なレベルのデータ保護(最大保護、最大可用性、最大パフォーマンス)に対する構成の設定処理を簡素化できます。

この項では、構成の適切な保護に役立つ項目について説明します。

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

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

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

保護モードを設定するには、次の手順を実行します。

手順1   使用するデータ保護モードの決定

各データ保護モードでは、データ保護、データ可用性およびデータベース・パフォーマンスが様々なバランスで提供されます。ビジネス・ニーズに合うデータ保護モードを選択するには、データ保護の要件とユーザーが要求するパフォーマンスを慎重に考慮します。

注意:
構成内の唯一のスタンバイ・データベースがスナップショット・スタンバイの場合、最大保護モードと最大可用性モードは使用できません。

最大可用性: この保護モードは、プライマリ・データベースの可用性を低下させずに、可能なかぎり高いレベルのデータ保護を提供します。トランザクションのリカバリに必要なすべてのREDOデータがオンラインREDOログと1つ以上の同期スタンバイ・データベース上のスタンバイREDOログに書き込まれるまで、トランザクションはコミットされません。1つ以上の同期スタンバイ・データベースにREDOストリームを書き込めない場合、プライマリ・データベースは最大パフォーマンス・モードの場合と同様に動作して、同期スタンバイ・データベースへのREDOストリームの書込みが再び可能になるまでプライマリ・データベースの可用性を維持します。

このモードでは、プライマリ・データベースの障害発生時に、第2の障害が発生してもプライマリ・データベースから1つ以上のスタンバイ・データベースにREDOデータの完全なセットを送信できるときにのみ、データが消失しないことが保証されます。

保護モードが最大可用性の場合、ファスト・スタート・フェイルオーバーを有効化できます。

最大パフォーマンス: この保護モードは、プライマリ・データベースのパフォーマンスへの影響なしに、可能なかぎり高いレベルのデータ保護を提供します。これを実現するため、トランザクションで生成されたすべてのREDOデータがオンライン・ログに書き込まれると、トランザクションをすぐにコミットできます。REDOデータは1つ以上のスタンバイ・データベースにも書き込まれますが、この書込みはトランザクションのコミットとは非同期に実行されるため、スタンバイ・データベースへのREDOデータの書込みの遅延は、プライマリ・データベースのパフォーマンスに影響を与えません。

最大可用性モードと比較して、この保護モードではデータ保護が若干弱くなり、プライマリ・データベースのパフォーマンスへの影響を最小限に抑えます。

これはデフォルトの保護モードです。

保護モードが最大パフォーマンスの場合、ファスト・スタート・フェイルオーバーを有効化できます。

最大保護: この保護モードでは、プライマリ・データベースの障害時にもデータの消失が発生しないことが保証されます。この保護レベルを提供するには、トランザクションのコミット前に、トランザクションのリカバリに必要なREDOデータを、オンラインREDOログと1つ以上の同期スタンバイ・データベース上のスタンバイREDOログに書き込む必要があります。データの消失が起こり得ないようにするため、1つ以上の同期スタンバイ・データベースにREDOストリームを書き込めない場合、プライマリ・データベースは停止し、トランザクション処理を継続しません。

Data GuardがREDOデータをスタンバイREDOログ・ファイルの永久記憶域に書き込むとすぐに、プライマリのトランザクションは保護されたものとみなされます。その後すぐにプライマリ・データベースに確認通知を戻し、次のトランザクションに進めるようにします。これによって、プライマリ・データベースでの同期転送スループットやレスポンス時間による影響を最小化できます。スタンバイ・データベースでの完全なData Guardの検証機能を最大限活用するには、必ずリアルタイムの適用モードで操作し、REDOの変更を受信と同時にスタンバイ・データベースに適用します。Data Guardは検出したすべての破損を通知するので、迅速な修正処理を実行できます。

このデータ保護モードでは、プライマリ・データベースの可用性よりもデータ保護を優先するため、単一のスタンバイ・データベースの障害によってプライマリ・データベースが停止しないように、少なくとも2つのスタンバイ・データベースを使用して最大保護モードで実行するプライマリ・データベースを保護することをお薦めします。1つのスタンバイ・データベースのみが最大保護モードをサポートしている場合、Data Guard Brokerは適用インスタンスのシャットダウンを禁止します。これによりプライマリ・データベースはシャットダウンされなくなります。

保護モードが最大保護の場合、ファスト・スタート・フェイルオーバーを有効化できません。

参照:

- ファスト・スタート・フェイルオーバーの詳細は、5.5項を参照してください。

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

手順2   スタンバイREDOログ・ファイルの設定

使用している保護モードに関係なく、スタンバイREDOログ・ファイルをすべてのスタンバイ・データベースに追加する必要があります。また、スイッチオーバーやフェイルオーバーに備えてプライマリ・データベース上にもスタンバイREDOログ・ファイルを追加する必要があります。ファスト・スタート・フェイルオーバーを有効にする場合は、プライマリ・データベース上にスタンバイREDOログ・ファイルが必要です。

Enterprise Managerでは、構成内の1つ以上のスタンバイ・データベースを選択するように要求され、将来のロール変更に備えて、スタンバイ・データベースおよびプライマリ・データベース上にスタンバイREDOログ(SRL)ファイルが設定されます。

参照:
DGMGRLコマンドライン・インタフェースを使用する場合は、スタンバイREDOログ・ファイルを構成する際に、『Oracle Data Guard概要および管理』の指示に従ってください。

手順3   構成可能なデータベース・プロパティLogXptModeの設定(必要な場合)

データ保護モードで、いずれかのスタンバイ・データベースが使用するREDO転送サービスを変更する必要がある場合は、各スタンバイ・データベースでデータベース・プロパティLogXptModeの設定を適切に変更してください。REDO転送サービスの設定の詳細は、4.4項を参照してください。表4-2では、保護モードおよび対応するREDO転送サービスを示します。

Enterprise Managerでは自動的に、将来のスイッチオーバーに備えて、プライマリ・データベース上に適切なREDO転送サービスが設定されます。

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

保護モード

REDO転送

スタンバイREDOログ・ファイルの要否

ファスト・スタート・フェイルオーバーとの併用

MAXPROTECTION

SYNC

必要

いいえ

MAXAVAILABILITY

SYNC

必要

必要

MAXPERFORMANCE

ASYNC

はい

可

手順4   保護モードの設定

DGMGRLコマンドまたはEnterprise Managerを使用した保護モードの設定

DGMGRLを使用する場合

1. EDIT DATABASE(プロパティ)コマンドを使用して、設定する保護モードに対応するようにREDO転送サービスを変更する必要のあるスタンバイ・データベースを指定します。たとえば、Data Guard構成全体を最大可用性モードで動作するように設定する場合は、EDIT DATABASEコマンドを使用して、REDO転送サービスに対してSYNCモードを設定する必要があります。次に例を示します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogXptMode'='SYNC';

この確認を構成内のプライマリ・データベースまたは他のスタンバイ・データベースについても行い、選択した保護モードをスイッチオーバー後もサポートできることを確認します。

2. EDIT CONFIGURATION SET PROTECTION MODE AS protection-modeコマンドを使用して、構成全体の保護モードを設定します。次に例を示します。

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

保護モードの設定方法を示すDGMGRLの使用例については、6.5項を参照してください。

Enterprise Managerを使用する場合

1. Data Guardの概要ページで、「保護モード」ラベルの右にあるリンクをクリックします。

2. 「最大保護」、「最大可用性」または「最大パフォーマンス」を選択して「続行」をクリックします。

3. プロンプトが表示される場合は、SYSDBA権限でデータベースにログインして「ログイン」をクリックします。

4. 選択した保護モードをサポートする1つ以上のスタンバイ・データベースを選択します。スタンバイREDOログ・ファイルが必要な場合は、ログ・ファイル名を確認します。「OK」をクリックします。

5. 「確認」ページで「はい」をクリックします。

最大保護モードにアップグレードする場合、DGMGRLまたはEnterprise Managerを使用して保護モードを最大パフォーマンス・モードから最大保護モードにアップグレードすると、プライマリ・データベースは自動的に再起動されます。保護モードをダウングレードした後でプライマリ・データベースを再起動する必要はありません。

保護モードを最大パフォーマンスから最大可用性に、または最大可用性から最大保護にアップグレードする場合、再起動は不要です。

注意:
最大パフォーマンス・モードから最大保護モードにアップグレードする際、まず最大可用性モードにアップグレードすることで、プライマリ・データベースの再起動を回避できます。最大可用性モードにしたら、次に最大保護モードにアップグレードします。

注意:
Oracle RAC One Nodeのオンライン・データベース再配置は、最大保護モードをサポートするフィジカル・スタンバイ・データベースのみで実行することはできません。
オンライン・データベース再配置を実行する必要がある場合、まず、保護モードを最大可用性にダウングレードします。フィジカル・スタンバイ・データベースのオンライン・データベース再配置を実行した後で、保護モードを最大保護にアップグレードすることができます。プライマリ・データベースの再起動は必要ありません。

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

この項では、スイッチオーバー、フェイルオーバー、Data Guard構成の無効化または有効化などの操作が、構成の保護モードやREDO転送サービスに与える影響について説明します。この項の内容は、次のとおりです。

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

- スイッチオーバー操作

- フェイルオーバー操作

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

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

- その他の操作要件

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

現在のData Guard保護モードを最大可用性モードにアップグレードする場合または現在のData Guard保護モードをダウングレードする場合、再起動は不要です。Data Guard保護モードのアップグレード時またはダウングレード時には、次の推奨事項に従ってください。

- 保護モードをアップグレードするときは、全体の保護モードをアップグレードする前にREDO転送サービスをアップグレードします。保護モードの変更時やスタンバイ・データベースのREDO転送サービスのリセット時に、ブローカは、必要なレベルの保護をサポートできるスタンバイ・データベースが構成内に少なくとも1つ存在していることを確認します。この条件が満たされない場合、保護モードは変更されず、エラーが戻されます。

- 保護モードをダウングレードするときは、最初に保護モードをダウングレードしてから、REDO転送サービスを変更します(必要な場合)。REDO転送サービスの変更によって現在の全体の保護モードが無効になる場合、ブローカはREDO転送サービスの変更を許可しません。

保護モードを最大パフォーマンス・モードからアップグレードする場合、ブローカは、少なくとも1つのスタンバイ・データベースのデータベース・プロパティLogXptModeがSYNCに設定されていることを確認します。また、最大保護モードへのアップグレードの場合、ブローカは、スタンバイ・データベースのREDOデータにギャップがないことを確認します。これらの要件を満たすスタンバイ・データベースが構成内に存在していない場合、保護モードのアップグレード要求はエラーとなり拒否されます。

ファスト・スタート・フェイルオーバーが有効化されても、保護モードは変更されません。

警告:

保護モードを最大パフォーマンスから最大保護にアップグレードすると、プライマリ・データベースは、停止され再起動されます。まず最大可用性にアップグレードすると、この動作を回避できます。最大可用性モードにしたら、次に最大保護モードにアップグレードします。

4.6.2.2 スイッチオーバー操作

スイッチオーバーでは、全体のData Guard保護モードは変更されません。保護モードはスイッチオーバー前と同じです。

スイッチオーバーの完了後に現在の保護モードをサポートするために、適切に構成されているスタンバイ・データベースが必要です。これは、構成内の他のスタンバイ・データベースでも、スイッチオーバー完了後にスタンバイ・データベースとなる現行のプライマリ・データベースでもかまいません。

必要な場合は、スイッチオーバーを起動する前に、現行のプライマリ・データベース上または構成内の他のスタンバイ・データベース上に、スタンバイREDOログ・ファイルを追加して、REDO転送サービスをData Guard保護モードのサポートに必要なSYNCまたはASYNCモードに設定できます。その後スイッチオーバーが開始されると、次の処理が実行されます。

- ブローカでは、各スタンバイ・データベース上と現行のプライマリ・データベース上で、スタンバイREDOログ・ファイルが存在することとREDO転送サービスの設定が検証されます。

- ブローカは、ターゲット・スタンバイ・データベースに存在するREDOデータに差分がないことを検証します。

検証が正常終了した場合は、スイッチオーバーが続行されます。正常終了しなかった場合、スイッチオーバーは失敗し、データベース・ロールとブローカ構成ファイルは変更されません。

警告:

スイッチオーバー・ターゲットがフィジカル・スタンバイ・データベースの場合、ブローカにより、プライマリ・データベースが停止され再起動されます。

参照:
スイッチオーバーの詳細は、5.3項を参照してください。

4.6.2.3 フェイルオーバー操作

保護モードが最大保護だった場合、手動フェイルオーバーを実行した後に、Data Guard保護モードが最大パフォーマンス・モードにダウングレードされます。必要な場合、保護モードは後でアップグレードできます。保護モードが最大可用性または最大パフォーマンスだった場合は、変更されません。スタンバイ・データベースのREDO転送サービスは変更されません。

ファスト・スタート・フェイルオーバーが実行された場合、ブローカにより、フェイルオーバー前に有効になっていた保護モードが保持されます。

参照:
手動フェイルオーバーおよびファスト・スタート・フェイルオーバーの詳細はそれぞれ、5.4項および5.5項を参照してください。

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

あるスタンバイ・データベースのブローカ管理を無効化すると、ブローカによって、残りのスタンバイ・データベースのいずれかが、全体の保護モードの要件を引き続き満たしているかがチェックされます。この条件が満たされない場合、無効化操作はブローカによって拒否されます。この条件が満たされる場合は、ファスト・スタート・フェイルオーバーが有効化されていないかぎり、無効化操作は続行されます。ファスト・スタート・フェイルオーバーが有効化されている場合でも、そのスタンバイ・データベースが、ファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースでなければ、無効化操作は続行されます。

注意:

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

スタンバイ・データベースが正常に無効化された後は、そのデータベースのREDO転送サービスを変更できます。変更内容は、ブローカによってブローカ構成ファイルに記録されます。この変更が全体の保護モードに影響を与えることはありません。これは、有効なスタンバイ・データベースの少なくとも1つが、全体の保護モード要件をすでに満たしているためです。

ファスト・スタート・フェイルオーバーが有効化されていないかぎり、構成全体は保護モードに関係なく無効化できます。ファスト・スタート・フェイルオーバーが有効化されている場合は、構成を無効にできません。詳細は、5.5.2.2項「ファスト・スタート・フェイルオーバーが有効化されている場合の制限事項」を参照してください。

構成全体が無効な場合は、スタンバイ・データベースのREDO転送サービスや構成の保護モードなどのブローカの設定を変更できます。ブローカはブローカ構成ファイルに変更を保存しますが、データベース自体には変更は行われません。

構成全体のブローカ管理を有効化するときは、ブローカによって、有効化されるスタンバイ・データベースのREDO転送サービスが保護モードの要件を満たしているかどうかが最初にチェックされます。この条件が満たされていない場合、有効化操作は失敗し、構成は無効のままになります。条件が満たされている場合は、有効化操作によって構成が正常に有効化され、ブローカは、ブローカ構成ファイルに保存されている設定を使用してデータベースを有効化します。

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

ブローカ構成からスタンバイ・データベースを削除するときは、ブローカによって、保護モードの要件が満たされているかどうかがチェックされます。次の場合、操作は失敗します。

- そのデータベースの削除により保護モードに影響がある場合

- ファスト・スタート・フェイルオーバーが有効化されているのに、ファスト・スタート・フェイルオーバーのターゲットとなるスタンバイ・データベースを削除しようとした場合

ファスト・スタート・フェイルオーバーが有効化されていない場合は、いつでも構成を削除できます。

4.6.2.6 その他の操作要件

ブローカ構成で行われる一部の操作、特にREDO転送サービスに関連する操作は、全体の保護モードに影響を与える場合があります。次のような操作があります。

- プライマリ・データベースのREDO転送サービスを停止する操作

- 個々のスタンバイ・データベースへのREDO転送サービスを停止する操作

- 最大可用性モードまたは最大保護モードで動作している構成をサポートする唯一のスタンバイ・データベースで、データベース・プロパティLogXptModeをSYNCからASYNCにダウングレードする操作

これらの操作の前には、ブローカによって、操作完了後にスタンバイ・データベースのREDO転送モード設定が保護モードをサポートするかどうかがチェックされます。この条件が満たされていない場合、操作は失敗し、エラーが戻されます。

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

完全自動管理の場合、ファスト・スタート・フェイルオーバーを有効にすると、ブローカによるフェイルオーバーの必要性の判断と、事前に指定されたターゲット・スタンバイ・データベースへのフェイルオーバーの開始が可能になります。これに伴うデータの消失はない場合と、構成可能なデータ量を消失する場合があります。また、フェイルオーバーが開始される条件やエラーも指定できます。DBMS_DG PL/SQLパッケージを使用すると、アプリケーションでファスト・スタート・フェイルオーバーを要求できます。

次の構成プロパティを使用して、ファスト・スタート・フェイルオーバーの動作を制御します。

- FastStartFailoverThreshold

- FastStartFailoverPmyShutdown

- FastStartFailoverLagLimit

- FastStartFailoverAutoReinstate

- FastStartFailoverTarget

また、Oracle Enterprise ManagerまたはDGMGRLのENABLE FAST_START FAILOVER CONDITIONコマンドおよびDISABLE FAST_START FAILOVER CONDITIONコマンドを使用して、ファスト・スタート・フェイルオーバーが実行される条件を指定することもできます。

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

ファスト・スタート・フェイルオーバーに関する構成可能なプロパティは、次のとおりです。

- FastStartFailoverThreshold
FastStartFailoverThreshold構成プロパティを設定して、(プライマリ・データベースが使用できないことが検出されてから)フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。詳細および例は、5.5.2項「ファスト・スタート・フェイルオーバーの有効化」を参照してください。

- 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に保護モードを変更する場合も、ファスト・スタート・フェイルオーバーを無効にしてから、プライマリとターゲット・スタンバイのLogXptModeプロパティをASYNCに変更する必要があります。元のプライマリの回復は、ASYNCターゲット・スタンバイへのファスト・スタート・フェイルオーバー後に可能になります。オブザーバは元のプライマリを再検出すると、自動的に元のプライマリを回復し、指定されたラグ以内で生成されたすべてのREDOが失われます。

参照:
プロパティの詳細は、第8章「Data Guard Brokerプロパティ」を参照してください。

- FastStartFailoverAutoReinstate
FastStartFailoverAutoReinstate構成プロパティは、プライマリ・データベースがクラッシュしたか、FastStartFailoverThresholdの秒数を超えて停止したためにファスト・スタート・フェイルオーバーが発生した場合、元のプライマリ・データベースを自動的に回復するかどうかを制御します。FastStartFailoverAutoReinstateのデフォルト値はTRUEです。

フェイルオーバーの完了後に診断または修復作業を行う場合は、FastStartFailoverAutoReinstate構成プロパティをFALSEに設定すると、自動回復を回避できます。

注意:
ユーザーによる構成可能なファスト・スタート・フェイルオーバー条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを開始した場合、元のプライマリ・データベースの自動回復は実行されません。

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

デフォルトでは、構成済の時間しきい値(FastStartFailoverThreshold)の経過後にオブザーバもスタンバイもプライマリにアクセスできないと、ファスト・スタート・フェイルオーバーが実行されます。また、別の条件でファスト・スタート・フェイルオーバーを実行する必要がある場合もあります。

構成可能な条件は、データベースの健全性チェック・メカニズムによって検出されるものとOracleサーバーで発生するエラー(ORAエラーなど)によって検出されるものの2種類に分類されます。指定された条件が発生すると、オブザーバは、スタンバイがフェイルオーバーを受け入れるために適した状態であれば、FastStartFailoverThresholdを超えるまで待機せずにファスト・スタート・フェイルオーバーを開始します。

各条件は、個別に有効化または無効化できます。Data Guard構成では、ユーザー指定のすべての構成可能なファスト・スタート・フェイルオーバー条件がブローカ構成ファイルに保持されます。

プライマリ・データベースが有効な健全性チェック条件のいずれかを示すと、オブザーバによって検出され、スタンバイがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)ただちにファスト・スタート・フェイルオーバーが開始されます。

Oracle ORAエラー条件が指定されている場合、エラーが示されるとプライマリ・データベースがオブザーバに通知し、オブザーバは、スタンバイがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)ただちにファスト・スタート・フェイルオーバーを開始します。

注意:
プライマリ・データベースは停止し、オブザーバは元のプライマリ・データベースの自動回復を試行しません。

参照:

- Oracle Enterprise Managerのオンライン・ヘルプ

- ENABLE FAST_START FAILOVER CONDITION

- DISABLE FAST_START FAILOVER CONDITION

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

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

参照:
DBMS_DGパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

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

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.9 データベースのステータス

データベースのステータスは、データベースの健全性を示します。通常、ブローカは、実際のデータベースの状態と設定がブローカ構成ファイル内の記述と一致するかどうかを検証し、データベースの健全性をチェックします。そのためには、Data Guard構成のコンポーネントで正常に機能していないものがないかどうか(REDO転送サービスにエラーがないかどうかなど)、その他の必須のデータベースの設定が正しく行われているかどうか(サーバー・パラメータ・ファイルが使用可能かどうか、ARCHIVELOGモードがオンになっているかどうかなど)をチェックします。ここでは、ブローカによりプライマリ・データベース上とスタンバイ・データベース上でチェックされる項目を詳しく説明します。

プライマリ・データベースの健全性チェックでは、次の条件が満たされているかどうかを判別します。

- データベースが、ユーザーが指定してブローカ構成ファイルに記録された状態であるかどうか。

- データベースが正しいデータ保護モードであるかどうか。

- データベースでサーバー・パラメータ・ファイルが使用されているかどうか。

- データベースがARCHIVELOGモードであるかどうか。

- データベース・ガードがオフになっているかどうか。

- 補助ロギングがオンになっているかどうか(構成にロジカル・スタンバイ・データベースが含まれている場合)。

- REDO転送サービスにエラーがあるかどうか。

- データベース設定が、ブローカの構成可能なプロパティで指定された設定と一致しているかどうか。

- REDO転送設定が、スタンバイ・データベースのREDO転送関連プロパティで指定された設定と一致しているかどうか。

- 現行のデータ保護レベルが構成済のデータ保護モードと一致しているかどうか。

- プライマリ・データベースで、すべてのスタンバイ・データベースのすべてのギャップを解決できるかどうか。

スタンバイ・データベースの健全性チェックでは、次の条件が満たされているかどうかを判別します。

- データベースが、ユーザーが指定してブローカ構成ファイルに記録された状態であるかどうか。

- データベースでサーバー・パラメータ・ファイルが使用されているかどうか。

- データベース設定が、ブローカの構成可能なプロパティで指定された設定と一致しているかどうか。

- データベース・ガードがオンになっているかどうか(データベースがロジカル・スタンバイ・データベースの場合)。

- ファスト・スタート・フェイルオーバーが有効化されている場合は、プライマリ・データベースおよびターゲット・スタンバイ・データベースが同期化されているかどうか、またはラグ制限内であるかどうか。

データベース・ステータスの問合せには、次の監視可能なデータベース・プロパティを使用できます。

- LogXptStatus

- InconsistentProperties

- InconsistentLogXptProps

注意:
これらのプロパティには、DGMGRLコマンドライン・インタフェースを介して直接アクセスします。Enterprise Managerでは、これらのプロパティの値が並べ替えられて、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

参照:
データベース・プロパティの詳細は、第8章を参照してください。

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

この章では、ブローカによるスイッチオーバーおよびフェイルオーバー中のデータベース管理について説明します。内容は次のとおりです。

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

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

- スイッチオーバー

- 手動フェイルオーバー

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

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

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

Oracleデータベースは、プライマリまたはスタンバイという2つのロールのいずれかで動作します。Data Guardにより、スイッチオーバーまたはフェイルオーバーのいずれかを使用してデータベースのロールを変更できます。

- スイッチオーバーは、プライマリ・データベースとそのいずれかのスタンバイ・データベース間のロール・リバーサルです。スイッチオーバーでは、データの消失がないことが保証され、通常は予定されたプライマリ・システムのメンテナンスの際に実行されます。スイッチオーバー中は、プライマリ・データベースがスタンバイ・ロールに遷移し、スタンバイ・データベースがプライマリ・ロールに遷移します。

- フェイルオーバーは、プライマリ・データベース(Oracle RACプライマリ・データベースのすべてのインスタンス)に障害が発生するかアクセス不能になり、いずれかのスタンバイ・データベースが遷移してプライマリ・ロールを引き継ぐときに実行されます。フェイルオーバーでは、フェイルオーバー時に有効な保護モードによって、データが消失する場合としない場合があります。

ブローカを使用しない場合、ロール遷移を実行するには、一連のSQL文を発行します(『Oracle Data Guard概要および管理』を参照)。ブローカでは、Oracle Enterprise Managerでキーを1回クリックするか、DGMGRLコマンドライン・インタフェースで単一のコマンドを使用してスイッチオーバーおよびフェイルオーバーを起動できるため(このマニュアルでは手動フェイルオーバーと呼びます)、これらの操作が簡素化されます。また、ファスト・スタート・フェイルオーバーを有効化すると、ファスト・スタート・フェイルオーバーの条件が満たされたときに自動的にフェイルオーバーが実行されます。ファスト・スタート・フェイルオーバーが有効化されている場合、ブローカによってフェイルオーバーの必要性が判断され、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーが自動的に開始されます。DBAによる操作は不要です。

ファスト・スタート・フェイルオーバーにより、手動操作の必要性を少なくして可用性を高め、管理コストを削減できます。手動フェイルオーバーでは、フェイルオーバーを実行する正確なタイミングおよび対象となるターゲット・スタンバイ・データベースを管理できます。選択する方法に関係なく、ブローカによって構成内のすべてのデータベースのロール遷移が調整されます。

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

スイッチオーバーまたはフェイルオーバー後に次のプライマリ・データベースにするスタンバイ・データベースを選択する際には、多数の考慮事項があります。Data Guard構成を構築する際には、フィジカル・スタンバイ、ロジカル・スタンバイおよびスナップショット・スタンバイの各特性、スタンバイ・データベース・サイトに対するネットワーク待機時間、将来のプライマリ・データベース・サイトにおけるコンピューティング機能などの要素を含む、すべてのオプションを考慮する必要があります。

注意:
スナップショット・スタンバイを、スイッチオーバーまたはファスト・スタート・フェイルオーバー操作のターゲットにすることはできません。ただし、スナップショット・スタンバイへの手動フェイルオーバーは実行できます。

スイッチオーバーについては、すべての要素を理解することで、新規プライマリ・データベースとみなすスタンバイ・データベースを簡単に選択できます。フェイルオーバーが必要な障害が発生した場合、障害のあるプライマリ・データベースのアクティビティを再開するのに最適なスタンバイ・データベースは、スイッチオーバーの場合よりも絞られる可能性があります。次の各項では、ターゲット・スタンバイ・データベースの選択に役立つガイドラインを示します。

注意:
ファスト・スタート・フェイルオーバーの場合、使用するターゲット・スタンバイ・データベースを事前に選択する必要があります。ファスト・スタート・フェイルオーバーの詳細は、5.5項を参照してください。

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

スタンバイ・データベースがすべて同じタイプである(すべてフィジカルまたはすべてロジカル・スタンバイ・データベース)構成内でスイッチオーバーを実行する場合、未適用のREDOの数が最も少ないスタンバイ・データベースを選択します。未適用のREDOの数が最も少ないスタンバイ・データベースを選択することで、スイッチオーバー操作が完了するまでの全体の所要時間を最小限にできます。次に例を示します。

- DGMGRLを使用する場合、構成内にある各スタンバイ・データベースのSHOW DATABASE出力のApply Lag行を調査します。

- Enterprise Managerを使用する場合は、Data Guardの概要ページの「スタンバイ・データベース」セクションで、各スタンバイ・データベースのApplyLag列の値を表示できます。

構成にフィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの両方が含まれる場合、ターゲット・スタンバイ・データベースとして(未適用REDOの数が最も少ない)フィジカル・スタンバイ・データベースを選択することを考慮します。スイッチオーバー操作の完了後は、構成内のすべてのデータベースが新規プライマリ・データベースに対するスタンバイ・データベースとして使用可能になるため、フィジカル・スタンバイ・データベースへのスイッチオーバーをお薦めします。一方、ロジカル・スタンバイ・データベースにスイッチオーバーすると、構成内のフィジカルおよびスナップショット・スタンバイ・データベースがすべて無効化されます。そのため、フィジカル・スタンバイ・データベースを再有効化するには、新規プライマリ・データベースのコピーからフィジカル・スタンバイ・データベースを再作成する必要があります。

スナップショット・スタンバイ・データベースへのスイッチオーバーを実行するには、最初にフィジカル・スタンバイ・データベースに戻す必要があります。

注意:
Data Guard構成が最大保護モードで動作している場合、ブローカではロジカル・スタンバイ・データベースへのスイッチオーバーが許可されません。ロジカル・スタンバイ・データベースへのスイッチオーバーを実行するには、構成が最大可用性モードまたは最大パフォーマンス・モードのいずれかで動作している必要があります。

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

フェイルオーバーを実行するとき、構成内のスタンバイがすべて同じタイプである場合は、最も転送ラグの小さいスタンバイ・データベースを選択します。これにより、データの消失量を最小限に抑え、場合によってはデータの消失をゼロにすることができます。

構成にフィジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースおよびロジカル・スタンバイ・データベースが含まれる場合、ターゲット・スタンバイ・データベースとしてフィジカル・スタンバイ・データベースを選択することを考慮します。フェイルオーバー操作の完了後は、構成内のすべてのスタンバイ・データベースが新規プライマリ・データベースに対するスタンバイ・データベースとして使用可能になる可能性が高いため、フィジカル・スタンバイ・データベースへのフェイルオーバーをお薦めします。

スナップショット・スタンバイ・データベースにフェイルオーバーすることもできます。ただし、スナップショット・スタンバイ・データベースにフェイルオーバーするには、ブローカがこのデータベースを最初にフィジカル・スタンバイ・データベースに戻す必要があるため、時間がかかります。変換した後、ブローカは、プライマリ・ロールへのデータベースのフェイルオーバーを実行する前に、REDO Applyを起動して累積REDOデータを適用します。スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに変換してからフェイルオーバーが実行されるため、フェイルオーバー操作の完了後、構成内のすべてのスタンバイ・データベースを新しいプライマリ・データベースへのスタンバイ・データベースとして使用することが可能になります。

ロジカル・スタンバイ・データベースにフェイルオーバーするには、フェイルオーバーの完了後に、新しいプライマリ・データベースのコピーからすべてのフィジカルおよびスナップショット・スタンバイ・データベースを再作成する必要があります。さらに、ロジカル・スタンバイ・データベースには、プライマリ・データベースに存在するデータのサブセットのみが含まれる可能性があります。(たとえば、プライマリ・データベース上で実行されるデータベース操作のうちロジカル・スタンバイ・データベースに適用しない操作を指定する際に、DBMS_LOGSTDBY.SKIPプロシージャが使用された場合など。)

ただし、例外として、ターゲット・スタンバイ・データベースとしてフィジカル・スタンバイ・データベースを選択することをお薦めできない場合があります。たとえば、フィジカル・スタンバイ・データベースもすべて利用できない場合は、ロジカル・スタンバイ・データベースへのフェイルオーバーが唯一の選択肢となります。

5.3 スイッチオーバー

データベースは、プライマリ・ロールからスタンバイ・ロール、またはスタンバイ・ロールからプライマリ・ロールに切り替えることができます。この操作は、データを消失させることなく、指定したスタンバイ・データベースがプライマリ・データベースになり、元のプライマリ・データベースがスタンバイ・データベースになるため、データベースのスイッチオーバーと呼ばれます。

可能な場合は必ず、フィジカル・スタンバイ・データベースに対してスイッチオーバーしてください。

- スイッチオーバーによりフィジカル・スタンバイ・データベースをプライマリ・ロールに遷移する場合、次のようになります。

- 元のプライマリ・データベースはフィジカル・スタンバイ・ロールに切り替えられます。

- オンラインREDOログ・ファイルは、新しいプライマリ・データベースから構成内のすべてのスタンバイ・データベースに継続的にアーカイブされます。

- スイッチオーバー操作の一部として、元のプライマリ・データベースが再起動されます。新しいプライマリ・データベースを再起動する必要がないことに注意してください。
スイッチオーバーに関係しないスタンバイ・データベース(その他のスタンバイ・データベース)は、スイッチオーバーが発生する前の状態で引き続き動作し、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。

- スイッチオーバーによりロジカル・スタンバイ・データベースをプライマリ・ロールに遷移する場合、次のようになります。

- 元のプライマリ・データベースはロジカル・スタンバイ・ロールに切り替えられます。

- スイッチオーバーの完了後、プライマリ・データベースおよびロジカル・スタンバイ・データベースのどちらも再起動の必要はありません。
ブローカ構成内の他のロジカル・スタンバイ・データベースは、スイッチオーバー後も実行可能です。どのデータベースも再起動する必要はありません。ロジカル・スタンバイ・データベースへのスイッチオーバーの後、すべてのフィジカルおよびスナップショット・スタンバイ・データベースは無効化されるため、新しいプライマリ・データベースのコピーから再作成する必要があります。

構成が最大保護モードで動作している場合、ロジカル・スタンバイ・データベースへのスイッチオーバーは許可されません。

警告:

ロジカル・スタンバイ・データベースにスイッチオーバーすると、ブローカ構成内のスナップショット・スタンバイ・データベースとフィジカル・スタンバイ・データベースはブローカにより無効化され、これらのデータベースはスタンバイ・データベースとして実行できなくなります。スタンバイ・データベースとして実行可能な状態にリストアする方法は、5.4.3項を参照してください。

比較的すぐに元のプライマリ・データベースにスイッチバックする場合は、フィジカルおよびスナップショット・スタンバイ・データベースを無効なままにしておくことができます。フィジカルおよびスナップショット・スタンバイ・データベースはまだ元のプライマリ・データベースの実行可能なスタンバイ・データベースであるため、元のプライマリ・データベースへのスイッチバックの完了後、これらを再有効化できます。

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

スイッチオーバーを開始する前に、次の点を考慮してください。

- スイッチオーバーを開始すると、ブローカは、スイッチオーバーの完了後に少なくとも1つのスタンバイ・データベース(スタンバイ・ロールに遷移する予定のプライマリ・データベースも含む)が、全体の保護モード(最大保護、最大可用性または最大パフォーマンス)をサポートするように構成されているかどうかを検証します。

- 全体の保護モードとの関連で、将来考えられるスタンバイ・データベースとしてのロールに備えて、あらかじめプライマリ・データベースを準備しておきます(4.6項を参照してください)。こうした準備には、次の操作が含まれます。

- プライマリ・データベースでスタンバイREDOログ・ファイルが構成されていることを確認します。

- LogXptMode、NetTimeout、StandbyArchiveLocationおよびAlternateLocationなど、REDO転送サービス関連のデータベース・プロパティをあらかじめ設定します。データベース・プロパティを使用したREDO転送サービスの管理の詳細は、4.4項を参照してください。

- DelayMinsなど、REDO Applyサービス関連のデータベース・プロパティをあらかじめ設定します。プロパティを使用したREDO Applyサービスの管理の詳細は、4.5項を参照してください。

- 一時表ごとに、プライマリ・データベース上の一時表に関連付けられた一時ファイルがスタンバイ・データベースにも存在することを確認します。

これらのプロパティは、実際にプライマリ・データベースをスタンバイ・ロールに切り替えるまで、ブローカによってREDO転送サービスとREDO Applyサービスの設定に使用されないことに注意してください。そのため、これらのプロパティの値の妥当性は、スイッチオーバー後まで検証されません。これらのプロパティを設定すると、その値はスイッチオーバーおよびフェイルオーバー時のロール変更を通じて存続します。

- リアルタイム問合せモードにあるフィジカル・スタンバイ・データベースへのスイッチオーバーを実行する前に、できるだけ迅速に、クリーンにロール・トランジションを実施させるために、そのスタンバイ・データベースのすべてのインスタンスを、マウント済だがオープンされていない状態にすることを検討します。

- 最大可用性モードまたは最大パフォーマンス・モードのいずれかでファスト・スタート・フェイルオーバーが有効化されている場合、スイッチオーバーを実行できるのは、事前に指定されたターゲット・スタンバイ・データベースに対してのみであり、スタンバイ・データベースがプライマリ・データベースと同期化されている場合に限られます。ファスト・スタート・フェイルオーバーの有効化の詳細は、5.5.2項を参照してください。

スイッチオーバーの完了後、ブローカにより、保護モードがスイッチオーバー前と同じ保護レベル(最大保護、最大可用性または最大パフォーマンス)に維持され、スイッチオーバー・プロセスの一部として全体のData Guard保護モードが保持されます。また、その他のスタンバイ・データベースにREDOを転送するためのネットワーク転送モード(SYNCまたはASYNC)は、スイッチオーバー後も変更されません。他のすべてのその他のスタンバイ・データベースに対する適用サービスは、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。

構成内にフィジカルまたはスナップショット・スタンバイ・データベースが存在するとき、ロジカル・スタンバイ・データベースへのスイッチオーバーが発生した場合は、5.4.3項に示すように、新しいプライマリ・データベースのコピーからこれらのデータベースを再作成し、データベースを再び有効化する必要があります。

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

ロールの切替えは、慎重に計画して実行する必要があります。スイッチオーバーに関係するプライマリ・データベースとスタンバイ・データベースのREDOラグは、できるかぎり低くする必要があります。スイッチオーバーに備えたデータベースの設定方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。

Enterprise Managerを使用してスイッチオーバーを開始するには、プライマリ・ロールに変更するスタンバイ・データベースを選択して「スイッチオーバー」をクリックします。DGMGRLを使用する場合は、SWITCHOVERコマンドを1つのみ発行し、プライマリ・ロールに変更するスタンバイ・データベースの名前を指定します。

5.3.3項で説明するように、スイッチオーバーに関するその他の作業はブローカによって制御されます。

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

スイッチオーバーを開始すると、ブローカは次の作業を実行します。

1. プライマリ・データベースとターゲットのスタンバイ・データベースが次の状態であることを検証します。

1. プライマリ・データベースが有効化されてTRANSPORT-ON状態であること。

2. ターゲット・スタンバイ・データベースが有効化されてAPPLY-ON状態であること。

ブローカは、スイッチオーバー操作に関連して選択したプライマリ・データベースとスタンバイ・データベースにエラーがないかぎり、スイッチオーバーを続行します。その他のスタンバイ・データベースにエラーが発生しても、スイッチオーバーは影響を受けません。

2. 必要に応じて、インスタンスのうち1つを残して、他のすべてのインスタンスを停止します。
フィジカル・スタンバイ・データベースへのスイッチオーバーを実行する場合、ブローカは、現在のプライマリ・データベース上のインスタンスのうち1つを残して他のすべてのインスタンスを停止します。ターゲット・フィジカル・スタンバイ・データベース上のインスタンスは停止されません。

ロジカル・スタンバイ・データベースへのスイッチオーバーの場合は、インスタンスを停止しません。スナップショット・スタンバイ・データベースにスイッチオーバーすることはできません。

3. プライマリ・データベースとスタンバイ・データベースの間でロールを切り替えます。
ブローカは最初に、元のプライマリ・データベースを変換してスタンバイ・ロールで実行するようにします。次に、ターゲットのスタンバイ・データベースをプライマリ・ロールに遷移させます。いずれかの変換時にエラーが発生すると、ブローカはスイッチオーバーを停止します。詳細は、9.3項「スイッチオーバー操作時の問題のトラブルシューティング」を参照してください。

4. ブローカ構成ファイルを更新し、ロールの変更を記録します。
構成ファイルには構成内のデータベース・オブジェクトがすべて記述されるため、なんらかの原因で後から再起動された場合にも、各データベースが確実に適切なロールおよび状態で動作します。

5. フィジカル・スタンバイ・データベースへのスイッチオーバーを行った場合は新しいスタンバイ・データベース(元のプライマリ・データベース)を再起動すると、REDO Applyが新しいプライマリ・データベースからのREDOデータの適用を開始します。Oracle RACのフィジカル・スタンバイ・データベースの場合は、ブローカの指示により、Oracle Clusterwareがスイッチオーバーの前に停止されたインスタンスを再起動します。最大保護モードで動作している構成では、新しいプライマリ・データベースも再起動されます。

6. 新しいプライマリ・データベースが読取り/書込みモードでオープンし、REDO転送サービスが開始します。
リアルタイム問合せが有効な状態で元のフィジカル・スタンバイ・データベースが実行されていた場合、新しいフィジカル・スタンバイ・データベースはリアルタイム問合せが有効な状態で実行されます。

ブローカは各データベースの状態とステータスを検証し、スイッチオーバーによって、各データベースが新しいロールにそれぞれ正常に遷移していることを確認します。スイッチオーバー後にブローカにより無効化されていないその他のスタンバイ・データベースは、スイッチオーバー前の状態で引き続き動作します。他のすべてのその他のスタンバイ・データベースに対するREDO ApplyおよびSQL Applyは、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。

5.4 手動フェイルオーバー

元のプライマリ・データベースで障害が発生し、プライマリ・データベースを適時にリカバリできる可能性がない場合は、スタンバイ・データベースをプライマリ・データベースに変換できます。これは手動フェイルオーバーと呼ばれます。プライマリ・データベースに障害が発生した時点でプライマリ・データベースとターゲット・スタンバイ・データベースが同期化されていたかどうかによって、データが消失する場合があります。手動という用語は、このタイプのフェイルオーバーとファスト・スタート・フェイルオーバー(5.5項を参照)を比較する目的で使用します。

注意:
ファスト・スタート・フェイルオーバーが有効化されている場合でも、手動フェイルオーバーを実行できます。詳細は、5.5.2.4項を参照してください。

次の各項では、手動フェイルオーバーの実行方法について説明します。

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

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

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

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

Enterprise ManagerまたはDGMGRLを使用して、完全フェイルオーバー(推奨)または即時フェイルオーバーを実行できます。

- 完全フェイルオーバーは、推奨方法でありデフォルトのフェイルオーバー・オプションです。完全フェイルオーバーでは、構成が動作している保護モードに応じて最大量のREDOデータが自動的にリカバリされます。また、フェイルオーバーのターゲットではないスタンバイ・データベースの無効化をできるかぎり回避して、新しいプライマリ・データベースに対するスタンバイ・データベースとして機能し続けられるようにします。
フェイルオーバーのターゲットではないスタンバイ・データベース(その他のスタンバイ・データベース)を無効にするか否かは、フェイルオーバーのターゲットと比較して、ターゲットでないスタンバイに適用されたREDOデータの量、およびフェイルオーバー・ターゲットのスタンバイ・タイプに応じて異なります。

- フェイルオーバーのターゲットがフィジカルまたはスナップショット・スタンバイ・データベースの場合、新しいプライマリ・データベースのスタンバイ・データベースにするには、元のプライマリ・データベースを回復または再作成する必要があります。また、一部のスタンバイ・データベースで新規プライマリ・データベースによる適用を超えてREDOを適用したことが検出された場合、ブローカはそれらのデータベースをフェイルオーバー中に無効化する場合があります。ブローカにより無効化されたデータベースは、新しいプライマリ・データベースのスタンバイ・データベースにする前に、5.4.3項で説明する手順に従って回復または再作成する必要があります。
スナップショット・スタンバイ・データベースでフェイルオーバーを実行した場合は、元のプライマリをフィジカル・スタンバイ・データベースとして回復または再作成する必要があることに注意してください。

- フェイルオーバーのターゲットがロジカル・スタンバイ・データベースである場合、元のプライマリ・データベースおよび構成内のすべてのフィジカルおよびスナップショット・スタンバイ・データベースが無効化されます。フラッシュバック・データベースが有効化されている場合、プライマリ・データベースを回復できます。フィジカルおよびスナップショット・スタンバイ・データベースは、新規プライマリ・データベースのコピーから再作成する必要があります。詳細は、5.4.3項を参照してください。

プライマリ・データベースをマウントできる場合は、ALTER SYSTEM FLUSH REDO SQL文を使用して、プライマリ・データベースからターゲット・スタンバイ・データベースへの未送信REDOデータをすべてフラッシュできます。この操作が正常に完了すると、プライマリ・データベースがデータ消失ゼロの保護モードでなくても、データ消失がゼロのフェイルオーバーが可能になります。ALTER SYSTEM FLUSH REDO文の使用の詳細は、『Oracle Data Guard概要および管理』を参照してください。

完全フェイルオーバー中は、5.4.2.1項に示すフェイルオーバー手順がブローカによって実行されます。

- 即時フェイルオーバーは、最も高速なタイプのフェイルオーバーです。ただし、フェイルオーバーの起動後は、スタンバイ・データベースに追加データが適用されません。即時フェイルオーバーを実行した場合は、構成内の他のすべてのデータベースが無効化されます。新規プライマリ・データベースのスタンバイ・データベースとして機能させるには、これらのデータベースを回復または再作成する必要があります。この方法については、5.4.3項を参照してください。即時フェイルオーバー中は、5.4.2.2項に示すフェイルオーバー手順がブローカによって実行されます。

注意:
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   使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースを判断します。

5.2項「ターゲット・スタンバイ・データベースの選択」に示したガイドラインに従います。

手順2   フェイルオーバーを開始します。

Enterprise ManagerまたはDGMGRLを使用して、完全フェイルオーバー(推奨)または即時フェイルオーバーを実行します。

Enterprise Managerを使用した手動フェイルオーバー

Enterprise Managerの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データは適用されずに、データベースのロールがプライマリに変更されます。

フィジカルまたはロジカル・スタンバイ・データベースにフェイルオーバーする場合は、インスタンスを停止しません。

手順3   保護モードをリセットします。

手動フェイルオーバー(完全または即時)の後、全体のData Guard保護モードは次のように処理されます。

- 保護モードが最大保護だった場合は、最大パフォーマンスにリセットされます。その後、必要な場合は、4.6.1項の説明に従って保護モードをアップグレードできます。

- 保護モードが最大可用性または最大パフォーマンスだった場合は、変更されません。

注意:
ファスト・スタート・フェイルオーバーが有効化されている場合に手動フェイルオーバーを実行すると、次のようになります。

- フェイルオーバーは、事前に選択されたターゲット・スタンバイ・データベースに対してのみ実行できます。

- ブローカにより、フェイルオーバー前に有効になっていた保護モードが維持されます。

手順4   障害時リカバリ構成を再確立します。

他の障害が発生した場合に実行可能な障害時リカバリ・ソリューションを維持するには、5.4.3項で説明する追加手順を実行し、次の操作を行う必要があります。

- 元のプライマリ・データベースを回復し、新規構成のスタンバイ・データベースとして機能させます。

注意:
ORA-752またはORA-600 [3020]エラーがフェイルオーバー・ターゲットで発生した場合に、古いプライマリ・データベースを回復しようとすると、データ損失が発生する場合があるため、回復操作は行わないでください。かわりに、5.4.3.2項で説明されている手順に従い、古いプライマリ・データベースを新しいプライマリのバックアップからスタンバイとして再作成する必要があります。

- ブローカによって無効化された構成内のスタンバイ・データベースを回復または再作成します。
完全フェイルオーバーが完了すると、新しいプライマリ・データベースのスタンバイとして実行可能でないその他のスタンバイ・データベースは、ブローカにより無効化されます。これは次のいずれかの理由で実行されます。

- その他のスタンバイ・データベースに、新しいプライマリ・データベースがスタンバイ・データベースであったときに適用されたよりも多くのREDOデータが適用された場合。新しいプライマリ・データベースのスタンバイとして機能させるには、このスタンバイ・データベースを再作成または回復する必要があります。

- ロジカル・スタンバイ・データベースにフェイルオーバーした場合。構成内のすべてのフィジカルおよびスナップショット・スタンバイ・データベースがブローカにより無効化されます。新しいプライマリ・データベースのスタンバイとして機能させるには、これらを再作成する必要があります。

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

完全フェイルオーバーを開始すると、ブローカは次の作業を実行します。

1. ターゲット・スタンバイ・データベースが有効化されていることを確認します。データベースが有効化されていない場合、このデータベースに対するフェイルオーバーは実行できません。

2. ターゲットのスタンバイ・データベースで未適用のREDOデータの適用が完了するまで待機し、適用が完了した後でREDO Apply(ターゲットがフィジカル・スタンバイ・データベースの場合)またはSQL Apply(ターゲットがロジカル・スタンバイ・データベースの場合)を停止します。
ターゲットがスナップショット・スタンバイ・データベースの場合、ブローカは、最初にデータベースをフィジカル・スタンバイに戻し、次にREDO Applyを起動してすべての累積REDOを適用してから、フェイルオーバーを完了してデータベースをプライマリ・データベースとしてオープンします。

3. ターゲット・スタンバイ・データベースを、次のように、プライマリ・データベース・ロールに遷移させます。

1. データベースのロールをスタンバイからプライマリに変更します。

2. 新しいプライマリ・データベースを読取り/書込みモードでオープンします。

3. フェイルオーバー操作に関係しなかったスタンバイ・データベースを、新しいプライマリ・データベースより多くのREDOデータが適用されたために無効化する必要があるかどうかを判断します。
このフェイルオーバー中に、その他のスタンバイ・データベースがブローカにより無効化されない場合は、フェイルオーバー前と同じ状態のままになります。たとえば、APPLY-OFF状態であったフィジカル・スタンバイ・データベースは、APPLY-OFF状態のままになります。

デフォルトでは、ブローカは、完全フェイルオーバーを実行するたびにその他のスタンバイ・データベースが新しいプライマリに対する実行可能なスタンバイ・データベースであるかどうかを判別します。完全フェイルオーバーの実行時に、その他のスタンバイ・データベースの実行可能性のチェックをスキップして、全フェイルオーバー時間を短縮するには、BystandersFollowRoleChange構成プロパティをNONEに設定してください。

このプロパティをNONEに設定すると、ブローカは、新しいプライマリ・データベースよりも多くのREDOデータが適用されているかどうかのチェックを実行せずに、その他のすべてのスタンバイ・データベースを無効にします。フェイルオーバーの完了後にスタンバイ・データベースを回復または再作成(5.4.3項を参照)する必要があります。SHOW CONFIGURATIONコマンドを使用して、回復可能なデータベースと再作成する必要のあるデータベースを表示します。このプロパティの値を表示するには、SHOW CONFIGURATION BystandersFollowRoleChangeコマンドを使用します。デフォルト値はALLです。

このプロパティは、ファスト・スタート・フェイルオーバーの発生時にその他のスタンバイ・データベースの実行可能性チェックをスキップするかどうかにも影響を与えます。

4. REDO転送サービスを起動して、無効化されていないすべてのその他のスタンバイ・データベースへのREDOデータの転送を開始します。

注意:
フェイルオーバー中には、その他のスタンバイ・データベースがブローカにより無効化される場合があります。新しいプライマリ・データベースのスタンバイ・データベースとして機能させるには、これらのデータベースを回復または再作成する必要があります。すべてのデータベースでフラッシュバック・データベースを構成し、フィジカル・スタンバイ・データベースにフェイルオーバーを実行した場合に、無効化されたスタンバイ・データベースをより簡単に回復できるようにすることをお薦めします。ロジカル・スタンバイ・データベースにフェイルオーバーを実行した場合、すべてのフィジカルおよびスナップショット・スタンバイ・データベースがブローカにより無効化されます。この場合、データベースの回復にフラッシュバック・データベースは使用できません。新しいプライマリ・データベースのコピーから再作成する必要があります。フェイルオーバー中に無効化されたロジカル・スタンバイ・データベースは回復できます。

4. Oracle RACのフィジカルまたはスナップショット・スタンバイ・データベースがフェイルオーバー・ターゲット・データベースである場合は、ブローカの指示により、Oracle Clusterwareがフェイルオーバーの前に停止されたインスタンスをすべて再起動します。

ブローカは、フェイルオーバーに関連して選択したスタンバイ・データベースにエラーがないかぎり、フェイルオーバーを続行します。その他のスタンバイ・データベースにエラーが発生しても、フェイルオーバーは停止されません。完全フェイルオーバーを開始して失敗した場合は、即時フェイルオーバーを使用する必要があります。

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

即時フェイルオーバーを開始すると、ブローカは次の作業を実行します。

1. ターゲット・スタンバイ・データベースが有効化されていることを確認します。スタンバイ・データベースがブローカによる管理に対応していない場合、フェイルオーバーは実行できません。

2. 使用可能なREDOデータがすべて適用されるまで待機せずに、スタンバイ・データベースのREDO ApplyまたはSQL Applyを即時停止します。この作業によってデータが失われる可能性があります。

3. ターゲットのスタンバイ・データベースをプライマリ・ロールに遷移させ、新しいプライマリ・データベースを読取り/書込みモードでオープンし、REDO転送サービスを起動します。
即時フェイルオーバーが完了すると、構成内のすべてのスタンバイ・データベースはタイプに関係なく無効化されます。それらのデータベースでフラッシュバック・データベースが有効化されている場合、データベースは回復されます。それ以外の場合は、新しいプライマリ・データベースのコピーから再作成する必要があります。

ブローカは、フェイルオーバーに関係するように選択したスタンバイ・データベースにエラーがないかぎり、完全フェイルオーバーを続行します。

ブローカは、フェイルオーバーに関係するように選択したスタンバイ・データベースにエラーがあっても、即時フェイルオーバーを続行します。

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

ロジカル・スタンバイ・データベースへのスイッチオーバー後またはいずれかのスタンバイ・データベースへのフェイルオーバー後に元の障害時リカバリ・ソリューションをリストアするには、追加手順を実行する必要があります。

ロール遷移後に無効化されたデータベースは、ブローカ構成から削除されませんが、ブローカによって管理されなくなります。

これらのデータベースのブローカによる管理を再び有効化するには、次のいずれかの手順でデータベースを回復または再作成する必要があります。

- データベースが回復可能な場合は、データベースで次のステータスが示されます。

ORA-16661: the standby database needs to be reinstated

データベースの回復方法に関する項の説明に従って、DGMGRLのREINSTATE DATABASEコマンドまたはEnterprise Managerの回復オプションを使用してデータベースを回復します。 ブローカにより、データベースは回復処理の一部として再有効化されます。

- 新規プライマリ・データベースのコピーからデータベースを再作成する必要がある場合、データベースのステータスが次のようになります。

ORA-16795: the standby database needs to be re-created

プライマリ・データベースのコピーからスタンバイ・データベースを再作成し、再び有効化します。スタンバイ・データベースの作成手順は、『Oracle Data Guard概要および管理』を参照してください。詳細は、5.4.3.2項「無効化されたデータベースの再作成および再有効化の方法」を参照してください。

注意:
複数のロール変更が実行されたときに無効化されたデータベースは、回復できません。現在のプライマリ・データベースのコピーからデータベースを手動で再作成し、ブローカ構成でデータベースを再有効化する必要があります。

データベースを回復するか再作成するかは、スイッチオーバーとフェイルオーバーのどちらを実行したか、さらに操作のターゲットとなったスタンバイ・データベースのタイプに応じて決まります。ロジカルおよびスナップショット・スタンバイ・データベースにロール変更すると、常にその他のフィジカル・スタンバイ・データベースは無効化されることに注意してください。これらのデータベースは回復できません。新しいプライマリ・データベースのコピーから再作成する必要があります。

次の各項では、データベースの回復または再有効化方法を説明します。

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

ブローカの回復機能を使用して、障害が発生したしたプライマリ・データベースを新しいプライマリ・データベースの実行可能なスタンバイ・データベースにすることができます。この処理は、フェイルオーバーがフィジカル、ロジカルまたはスナップショット・スタンバイ・データベースのいずれに実行されたかに関係なく行うことができます。

フェイルオーバー操作中に無効化されたその他のスタンバイ・データベースも回復できます。

回復可能なデータベースは、ステータス値が次のようになります。

ORA-16661: the standby database needs to be reinstated

REINSTATEコマンドを正常に実行するには、フェイルオーバー前にデータベース上でフラッシュバック・データベースが有効化されており、そのデータベースに十分なフラッシュバック・ログが存在する必要があります。さらに、回復するデータベースおよび新規プライマリ・データベースにネットワーク接続が必要です。

データベースを回復する手順は、次のとおりです。

1. データベースを再起動してマウント済状態にします。

2. 新規プライマリ・データベースに接続します。

3. Enterprise ManagerまたはDGMGRLを使用してデータベースを回復します。

ブローカは、障害が発生したプライマリ・データベースを元のスタンバイ・データベースと同じタイプのスタンバイ・データベース(フィジカルまたはロジカル・スタンバイ・データベース)として回復します。唯一の例外は、スナップショット・スタンバイ・データベースへのフェイルオーバーです。そのような場合は、障害が発生したプライマリ・データベースがフィジカル・スタンバイ・データベースとして回復されます。

ブローカは、フェイルオーバー中に無効化されたその他のスタンバイ・データベースを、新しいプライマリ・データベースのスタンバイ・データベースとして回復します。

Enterprise Managerを使用した回復

Data Guardの概要ページで、「データベースを回復する必要があります」リンクをクリックします。これにより、「回復」ボタンが表示された「一般プロパティ」ページが開きます。「回復」ボタンをクリックすると、Enterprise Managerでデータベースの回復が開始されます。

プロセスが完了すると、データベースが新規プライマリ・データベースのスタンバイ・データベースとして有効化され、Enterprise ManagerでData Guardの概要ページが表示されます。

DGMGRLを使用した回復

ブローカ構成内のデータベース(回復するデータベースを除く)に接続しているときに、次のコマンドを発行します。

DGMGRL> REINSTATE DATABASE db_unique_name;

新しく回復したスタンバイ・データベースは、新規プライマリ・データベースのスタンバイ・データベースとして機能し始めます。データベースの回復に失敗した場合、ステータスは「ORA-16795: スタンバイ・データベースを再作成する必要があります」に変更されます。この場合、5.4.3.2項の説明に従って、新しいプライマリ・データベースのコピーから再作成して再有効化する必要があります。

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

障害が発生したプライマリ・データベースまたはロール遷移時に無効化されたスタンバイ・データベースの再作成が必要なフェイルオーバーまたはスイッチオーバーを実行した場合、『Oracle Data Guard概要および管理』の「フィジカル・スタンバイ・データベースの作成」および「ロジカル・スタンバイ・データベースの作成」の手順を実行します。

元のプライマリ・データベースを作成する場合、元のスタンバイ・データベースのスタンバイ・タイプで作成する必要があることに注意してください。たとえば、元のスタンバイがフィジカルまたはスナップショット・スタンバイだった場合は、元のプライマリをフィジカル・スタンバイとして再作成する必要があります。

データベースが再作成された後、DGMGRLのENABLE DATABASEコマンドを使用して、再作成されたスタンバイ・データベースのブローカ管理を有効化します。

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

ファスト・スタート・フェイルオーバーでは、プライマリ・データベースが消失した場合、ブローカにより、事前に選択されたスタンバイ・データベースに自動的にフェイルオーバーできます。ファスト・スタート・フェイルオーバーでは、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールに迅速かつ確実にフェイルオーバーされます。このとき、手動手順を実行してフェイルオーバーを起動する必要はありません。。ファスト・スタート・フェイルオーバーはブローカ構成でのみ使用でき、DGMGRLまたはEnterprise Managerによってのみ構成できます。

ファスト・スタート・フェイルオーバーでは、最大可用性モードまたは最大パフォーマンス・モードのいずれかを使用できます。最大可用性モードは、データが消失しないことを保証する自動フェイルオーバー環境を提供します。最大パフォーマンス・モードによる自動フェイルオーバー環境では、消失データがFastStartFailoverLagLimit構成プロパティで指定したデータ量(秒単位)以下であることが保証されます。このプロパティは、自動フェイルオーバーの実行に許容される最大消失データ量を示します。このプロパティは、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作している場合にのみ使用されます。

ファスト・スタート・フェイルオーバーが有効化されると、ブローカでは、構成されている消失データ量が保証される場合にのみファスト・スタート・フェイルオーバーの実行が可能となります。構成されている消失データ量を保証できない場合、プライマリ・データベースのREDO生成が停止します。長期にわたる停止を回避するため、ファスト・スタート・フェイルオーバーを実行できないと記録された後、オブザーバまたはターゲット・スタンバイ・データベースにより、プライマリ・データベースでのREDO生成の続行が可能になる場合があります。

構成済の消失データ量の保証がリストアされると、ブローカは自動フェイルオーバー機能をリストアします。このリストアが起こるのは、最大可用性モードで動作している構成の場合、ターゲットのスタンバイ・データベースがREDOデータの不足をすべて受信し終わったときです。最大パフォーマンス・モードで動作している構成の場合は、プライマリ・データベースのREDO生成時点とターゲット・スタンバイ・データベースのREDO適用時点の間に、FastStartFailoverLagLimit構成プロパティに指定された値の遅れがなくなったときです。

この項では、ファスト・スタート・フェイルオーバーおよびファスト・スタート・フェイルオーバー環境を監視するオブザーバ・サイトを有効化する方法を説明します。オブザーバは、プライマリ・データベースおよびスタンバイ・データベースとは異なるコンピュータ上で動作する、独立したOCIクライアント側コンポーネントであり、プライマリ・データベースの可用性を監視します。オブザーバについては、5.5.7項で詳しく説明されています。

オブザーバの起動が完了したら、ユーザーによる操作は必要ありません。オブザーバおよび指定されたスタンバイ・データベースの両方で、FastStartFailoverThreshold構成プロパティに指定された秒数を超えてプライマリ・データベースとの接続が失われた場合、オブザーバはスタンバイ・データベースへのファスト・スタート・フェイルオーバーを開始します。また、FastStartFailoverPmyShutdown構成プロパティがTRUEに設定されている場合、FastStartFailoverThresholdの秒数よりも長い期間に及ぶ接続の消失を検出すると、プライマリ・データベースは停止します。FastStartFailoverAutoReinstate構成プロパティがTRUEに設定されている場合、フェイルオーバーの完了後、元のプライマリ・データベースへの接続が再度確立されたときに、元のプライマリ・データベースがスタンバイ・データベースとして自動的に回復されます。

注意:
ユーザーが構成可能なファスト・スタート・フェイルオーバー条件が検出されてファスト・スタート・フェイルオーバーが発生した場合、またはアプリケーションからDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてファスト・スタート・フェイルオーバーを開始した場合、元のプライマリ・データベースは必ず停止し、自動的に回復されることはありません。これは、FastStartFailoverPmyShutdownおよびFastStartFailoverAutoReinstate構成プロパティの設定には関係ありません。詳細は、5.5.2項を参照してください。

図5-1に、ファスト・スタート・フェイルオーバー時のプライマリ・データベース、ターゲット・スタンバイ・データベースおよびオブザーバの関係を示しています。

- ファスト・スタート・フェイルオーバー前: Data Guardは安定した状態で動作しており、プライマリ・データベースがターゲット・スタンバイ・データベースにREDOデータを転送し、オブザーバが全体の構成の状態を監視しています。

- ファスト・スタート・フェイルオーバーの実行: プライマリ・データベースに障害が発生し、オブザーバおよびターゲット・スタンバイ・データベースへのネットワーク接続がどちらも失われます。オブザーバは、通信の切断を検出すると、ファスト・スタート・フェイルオーバーの開始前にFastStartFailoverThresholdプロパティによって定義された時間内において、プライマリ・データベースとの接続の再確立を試行します。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できず、ターゲット・スタンバイ・データベースがファスト・スタート・フェイルオーバー可能な状態である場合、ファスト・スタート・フェイルオーバーが実行されます。

- ファスト・スタート・フェイルオーバー後: ファスト・スタート・フェイルオーバーが完了し、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールで動作しています。元のプライマリ・データベースが修復された後、オブザーバはそのデータベースとの接続を再確立し、新規スタンバイ・データベースとして回復します。新規プライマリ・データベースが新規スタンバイ・データベースへのREDOデータの転送を開始します。

図5-1 プライマリ・データベースおよびスタンバイ・データベースとオブザーバの関係

以降の各項の内容は、次のとおりです。

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

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

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

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

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

- オブザーバの管理

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

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

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

ブローカでファスト・スタート・フェイルオーバーを有効化するには、次の前提条件を満たしている必要があります。

- ブローカ構成が最大可用性モードまたは最大パフォーマンス・モードのいずれかで動作していることを確認します。
保護モード、スタンバイREDOログおよびLogXptModeプロパティの構成の詳細は、4.6.1項を参照してください。

- ファスト・スタート・フェイルオーバーのターゲットに選択したスタンバイ・データベースのLogXptModeプロパティがSYNC(最大可用性モードでファスト・スタート・フェイルオーバーを有効化する場合)またはASYNC(最大パフォーマンス・モードでファスト・スタート・フェイルオーバーを有効化する場合)に設定されていることを確認します。現在のプライマリ・データベースは、LogXptModeプロパティが適切に設定され、スタンバイREDOログが構成されている必要があります。

- フラッシュバック・データベースを有効化し、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方でファスト・リカバリ領域を設定します。
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- 2.1項の説明に従って、オブザーバ・コンピュータにDGMGRLコマンドライン・インタフェースをインストールします。

- オブザーバ・システムでTNSNAMES.ORAファイルを構成し、オブザーバがプライマリ・データベースおよび事前に選択されたターゲット・スタンバイ・データベースに接続できるようにします。

- 静的なサービス名を作成して、回復処理の一部としてオブザーバがデータベースを自動的に再起動できるようにします。詳細は、2.2項「前提条件」を参照してください。

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

ブローカ構成のデータベースに接続されている間は、任意のサイトからファスト・スタート・フェイルオーバーを有効化できます。ファスト・スタート・フェイルオーバーを有効化しても、フェイルオーバーは起動されません。かわりに、フェイルオーバーの条件が満たされた場合に、構成を監視しているオブザーバがファスト・スタート・フェイルオーバーを起動できるようになります。

ファスト・スタート・フェイルオーバーを有効化し、オブザーバを起動するには、次の手順を実行します。これらの手順では、SYSとして接続しており、ブローカ構成でプライマリ・データベースおよびスタンバイ・データベースがすでに設定されていることを前提としています。

手順1   使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースを判断します。

5.2項「ターゲット・スタンバイ・データベースの選択」に示したガイドラインに従います。

手順2   FastStartFailoverTarget構成プロパティを使用してターゲット・スタンバイ・データベースを指定します。

現行のプライマリ・データベースのFastStartFailoverTarget構成プロパティを設定する場合、ターゲット・スタンバイ・データベースを1つのみ指定できます。

- 構成内のスタンバイ・データベースが1つのみである場合、この手順をスキップして手順3に進みます。ファスト・スタート・フェイルオーバーを有効化する際、ブローカにより、プライマリ・データベースおよびスタンバイ・データベースのFastStartFailoverTargetプロパティが、フェイルオーバー時にお互いをそれぞれのターゲットとして指すように自動的に設定されます。

- 構成内に複数のスタンバイ・データベースがある場合、プライマリ・データベースでFastStartFailoverTargetプロパティを明示的に設定して、ターゲット・スタンバイ・データベースを選択する必要があります。ファスト・スタート・フェイルオーバーを有効化する際、ブローカによりこのプロパティが既存のスタンバイ・データベースを指していることが確認され、今度は反対にこのスタンバイ・データベースのFastStartFailoverTargetプロパティがプライマリ・データベースを指すように設定されます。

注意:
FastStartFailoverTargetプロパティを変更して別のスタンバイ・データベースを指すようにするには、ファスト・スタート・フェイルオーバーを無効化し、FastStartFailoverTargetプロパティを設定し、さらにファスト・スタート・フェイルオーバーを再有効化してください。

このプロパティの詳細は、8.3.10項「FastStartFailoverTarget」を参照してください。

手順3   使用する保護モードを決定します。

ファスト・スタート・フェイルオーバーは、最大可用性モードまた最大パフォーマンス・モードに対して有効化できます。いかなるデータの消失も許容できない場合は、構成の保護モードが最大可用性に設定されていることを確認してください。それには、プライマリ・データベースとターゲット・スタンバイ・データベースの両方でデータベース・プロパティLogXptModeがSYNCに設定されている必要があります。その後、構成保護モードを最大可用性に設定してください。次に例を示します。

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;

わずかなデータの消失よりもプライマリ・データベースのパフォーマンスを重視する場合は、構成の保護モードを最大パフォーマンスに設定してファスト・スタート・フェイルオーバーを有効化することを検討してください。このモードでは、どれだけのデータ消失を許容できるかを秒単位で検討し、それに従って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;

手順4   FastStartFailoverThreshold構成プロパティを設定します。

オブザーバおよびターゲット・スタンバイ・データベースの両方で、FastStartFailoverThreshold構成プロパティで指定された時間にわたってプライマリ・データベースへの接続が失われた場合、ファスト・スタート・フェイルオーバーが実行されます。

FastStartFailoverThresholdプロパティを設定し、(プライマリ・データベースが使用できないことが検出されてから)フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。次に例を示します。

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 45;

FastStartFailoverThresholdプロパティのデフォルト値は30秒で、設定できる最小値は6秒です。Oracle RACプライマリ・データベースが存在する場合、インスタンス障害が発生したときに誤ってフェイルオーバーが実行される可能性を最小限にするには、これより大きい値を指定することを考慮します。

この時間間隔は、オブザーバでプライマリ・データベースへの接続が最初に失われたときに開始されます。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できない場合、スタンバイ・データベースがフェイルオーバー可能な状態であれば、オブザーバによりファスト・スタート・フェイルオーバーが開始されます。デフォルト値の30秒は、通常はほとんどの構成で停止および障害を検出できる値ですが、このプロパティでフェイルオーバーの感度を調整することで、一時的に不安定になった環境でフェイルオーバーが誤って実行される可能性を低くすることができます。

REDOの生成が停止し、プライマリ・データベースがオブザーバまたはターゲット・スタンバイ・データベースとの接続を再確立できない場合、FastStartFailoverPmyShutdown構成プロパティがTRUEに設定されていると、FastStartFailoverThresholdの秒数が経過した後にプライマリ・データベースが停止します。

ファスト・スタート・フェイルオーバーが有効化されている場合でもFastStartFailoverThresholdプロパティを変更できることに注意してください。

参照:
FastStartFailoverThresholdプロパティの詳細は、8.1.8項を参照してください。

手順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プロパティの値を使用してプライマリおよびターゲット・スタンバイ・データベースに接続し、監視します。

手順6   追加のファスト・スタート・フェイルオーバー条件を有効化します(オプション)。

デフォルトでは、構成された時間しきい値(FastStartFailoverThreshold)の経過後にオブザーバもスタンバイもプライマリにアクセスできないと、ファスト・スタート・フェイルオーバーが実行されます。

必要に応じて、ファスト・スタート・フェイルオーバーを発生させるデータベース健全性条件を指定することができます。次の表に、これらの条件を示します。

健全性条件

説明

デフォルトで有効化

データファイル・オフライン

書込みエラーのためにデータファイルがオフラインになりました。

はい

破損したディクショナリ

重要なデータベース・オブジェクトのディクショナリが破損しました。現時点では、この状態は、データベースがオープンされている場合にのみ検出されます。

はい

破損した制御ファイル

ディスク障害のために制御ファイルが永続的に破損しました。

はい

アクセス不可能なログ・ファイル

I/OエラーのためにLGWRがログ・グループのどのメンバーにも書き込むことができません。

いいえ

スタック・アーカイバ

デバイスに空き容量がないかデバイスを使用できないためにアーカイバがREDOログをアーカイブできません。

いいえ

Oracle RAC構成では、アクセス不可能なログ・ファイルおよびスタック・アーカイバの健全性条件は、単一インスタンスにのみ適用できます。これらの条件によるファスト・スタート・フェイルオーバーは、Oracle Clusterwareによって提供される可用性オプションに優先して実行されるので、有効化する前によく検討してください。

Oracleサーバーで発生するエラー(ORAエラー)をファスト・スタート・フェイルオーバーが発生するための条件として指定することもできます。

Oracle Enterprise ManagerまたはDGMGRLのENABLE FAST_START FAILOVER CONDITIONコマンドおよびDISABLE FAST_START FAILOVER CONDITIONコマンドを使用して、ファスト・スタート・フェイルオーバーが実行される特定条件を指定することができます。

手順7   ファスト・スタート・フェイルオーバーを有効化します。

Enterprise Managerのファスト・スタート・フェイルオーバー・ウィザードまたはDGMGRLのENABLE FAST_START FAILOVERコマンドを使用して、ファスト・スタート・フェイルオーバーを有効化します。ファスト・スタート・フェイルオーバーを有効化するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方が動作しており、接続され、さらに5.5.1項にリストされた前提条件をすべて満たしている必要があります。

Enterprise Managerを使用したファスト・スタート・フェイルオーバーの有効化

Enterprise Managerでファスト・スタート・フェイルオーバーを有効化するには、ファスト・スタート・フェイルオーバー・ウィザードを使用します。「ファスト・スタート・フェイルオーバー」ステータス・フィールドの横にあるData Guardの概要ページで、「無効」をクリックして「ファスト・スタート・フェイルオーバー」ページを開きます。次に、「ファスト・スタート・フェイルオーバー: モードを変更」ページで、「有効」をクリックします。Enterprise Managerがオブザーバを起動します。次に、「ファスト・スタート・フェイルオーバー: 構成」ページで、フェイルオーバーのターゲットとするスタンバイ・データベースを選択します。役立つアドバイスについては、5.2項「ターゲット・スタンバイ・データベースの選択」を参照してください。このページでは、保護モードを変更できません。ファスト・スタート・フェイルオーバーは、現在の保護モードに従って有効化されます。現在構成されているモードが最大保護の場合、Enterprise Managerは、モードを最大可用性にダウングレードします。

DGMGRLを使用したファスト・スタート・フェイルオーバーの有効化

DGMGRLを使用してファスト・スタート・フェイルオーバーを有効化するには、オブザーバ・コンピュータ上のデータベースを含むブローカ構成内のいずれかのデータベースに接続している間に、ENABLE FAST_START FAILOVERコマンドを発行します。次に例を示します。

DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.

参照:

- ENABLE FAST_START FAILOVER

- 6.6項「使用例5: ファスト・スタート・フェイルオーバーの有効化とオブザーバの起動」

注意:
スタンバイ・データベースが事前の予告なしにプライマリ・ロールを引き継ぐ場合があるため、ターゲット・スタンバイ・サイトでの管理はプライマリ・サイトでの管理と同じくらい包括的である必要があります。スタッフ・サポート、ハードウェアとソフトウェア、セキュリティ(ソフトウェアとサイトの両方)、ネットワーク接続および帯域幅が両方のサイトで同等である必要があります。

手順8   オブザーバを起動します。

オブザーバを起動するには、プライマリ・データベースが実行されている必要があります。

ファスト・スタート・フェイルオーバーを有効化する前または後にオブザーバを起動できます。ファスト・スタート・フェイルオーバーが有効化されている場合、オブザーバは、プライマリ・データベースおよびターゲット・スタンバイ・データベースのステータスおよび接続の監視をただちに開始します。ファスト・スタート・フェイルオーバーが有効化されていない場合、オブザーバは、ファスト・スタート・フェイルオーバーが有効化されるまで待機してから監視を開始します。

Enterprise Managerを使用したオブザーバの起動

Enterprise Managerエージェントがオブザーバ・コンピュータにインストールされている場合、Enterprise Managerを使用してファスト・スタート・フェイルオーバーを有効化すると、Enterprise Managerによりオブザーバが自動的に起動されます。エージェントが存在しない場合、DGMGRLコマンドライン・インタフェースに関する次の手順を実行して、オブザーバを手動で起動する必要があります。

DGMGRLを使用したオブザーバの起動

DGMGRLを使用してオブザーバを起動するには、オブザーバ・コンピュータで次のコマンドを発行します。

DGMGRL> START OBSERVER;

オブザーバはSTART OBSERVERコマンドを発行したときに作成され、継続的に実行されるプロセスです。そのため、別のDGMGRLセッションからSTOP OBSERVERコマンドを発行するまで、オブザーバ・コンピュータ上のコマンドライン・プロンプトは戻されません。コマンドを発行し、ブローカ構成と対話するには、別のDGMGRLクライアント・セッションにより接続する必要があります。

詳細は、START OBSERVERコマンドを参照してください。

手順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

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.1 ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行

ファスト・スタート・フェイルオーバーを有効化してオブザーバを起動した後は、オブザーバが継続的に環境を監視してプライマリ・データベースが使用可能であることを確認します。この項では、オブザーバがファスト・スタート・フェイルオーバーの必要性を判別し、必要に応じてフェイルオーバーを実行するための手順をリストしています。

手順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   ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態であることを確認します。

ファスト・スタート・フェイルオーバーが開始されると、オブザーバはターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーする準備ができているかどうかを確認します。

次の場合、ファスト・スタート・フェイルオーバーは実行できません。

- ファスト・スタート・フェイルオーバーが有効でない場合

- オブザーバがターゲット・スタンバイ・データベースに接続できない場合

参照:
オブザーバが動作していない場合は、5.5.7.3項「オブザーバに障害が発生した場合の動作」を参照してください。

- ブローカ構成の現在の状態に関して、オブザーバおよびターゲット・スタンバイ・データベースに一貫性がない場合

- オブザーバが動作していない場合

- 保護モードが最大可用性で、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていない場合

- 保護モードが最大パフォーマンスで、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースのREDO適用時点がプライマリ・データベースのREDO生成時点からFastStartFailoverLagLimit構成プロパティで指定された時間を超えて遅れる場合

- ターゲット・スタンバイ・データベースがプライマリ・データベースと通信している場合

- ターゲット・スタンバイ・データベースのV$DATABASEビュー内のFS_FAILOVER_STATUS列に、ファスト・スタート・フェイルオーバーを実行できない理由が表示された場合

- 手動フェイルオーバーがすでに進行中です。手動フェイルオーバーの詳細は、5.4項を参照してください。

- ABORTオプションを使用せずにプライマリ・データベースを停止した場合

手順4   ファスト・スタート・フェイルオーバーを開始します。

ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態である場合、オブザーバの指示により、ただちにターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーします。他のなんらかの理由でフェイルオーバーを実行できない場合、オブザーバはスタンバイ・データベースでフェイルオーバーの準備ができたかどうかをチェックし続けます。ただし、オブザーバはプライマリ・データベースへの再接続も無期限に試行し続けます。スタンバイがフェイルオーバーに同意する前にプライマリ・データベースに再接続すると、オブザーバはファスト・スタート・フェイルオーバーの開始の試行を中止します。

手順5   元のプライマリ・データベースを新規スタンバイ・データベースとして回復します。

ファスト・スタート・フェイルオーバーが正常に完了した後、元のプライマリ・データベースへの接続が再確立され、FastStartFailoverAutoReinstate構成プロパティがTRUEに設定されている場合、オブザーバは元のプライマリ・データベースの新規スタンバイ・データベースとしての回復を試行します。FastStartFailoverPmyShutdown構成プロパティをTRUEに設定した場合、元のプライマリ・データベースは自動的に停止しているため、オブザーバが回復を試行する前に、手動で再起動する必要があります。

プライマリがクラッシュしたか、オブザーバおよびターゲット・スタンバイ・データベースから分離したためにファスト・スタート・フェイルオーバーが発生した場合にのみ、これらのプロパティがプライマリの停止および自動回復の実行を左右する点に注意してください。

参照:
回復の詳細は、5.5.8項を参照してください。

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

ファスト・スタート・フェイルオーバーが有効化されている場合、次の操作は禁止されています。

- 変更:

- 構成保護モード

- プライマリ・データベースまたはターゲット・スタンバイ・データベースのデータベース・プロパティLogXptMode

- プライマリ・データベースまたはターゲット・スタンバイ・データベースのFastStartFailoverTarget構成プロパティ

- 無効化または削除:

- ブローカ構成

- ファスト・スタート・フェイルオーバーのターゲットであるスタンバイ・データベース

- 手動フェイルオーバーの実行:

- 5.5.2.4項にリストした条件を満たしていない場合の実行

- ファスト・スタート・フェイルオーバーのターゲットとして構成されていないスタンバイ・データベースに対する実行

構成がファスト・スタート・フェイルオーバーを実行可能な状態かどうかを判断するには、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分未満で完了しないと、このエラーが戻されることがあります。

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

プライマリ・データベースまたはスタンバイ・データベースが通常の方法で(SHUTDOWN NORMAL、SHUTDOWN IMMEDIATEまたはSHUTDOWN TRANSACTIONALを使用して)停止された場合、ファスト・スタート・フェイルオーバーは起動されません。通常の停止では、プライマリ・データベースおよびスタンバイ・データベースが再度接続され通信状態になるまで、ファスト・スタート・フェイルオーバーを実行できません。

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

ファスト・スタート・フェイルオーバーが有効化されている場合でも、次の条件を満たしているかぎり、スイッチオーバーまたは手動フェイルオーバーを実行できます。

- ロール変更の対象が、FastStartFailoverTarget構成プロパティで指定されたスタンバイ・データベースと同一であること。

- ターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていること(最大可用性モードで動作している構成の場合)またはターゲット・スタンバイ・データベースがラグ制限内にあること(最大パフォーマンス・モードで動作している構成の場合)。

- 手動フェイルオーバーの場合、オブザーバが起動しており、ターゲット・スタンバイ・データベースと通信していること。手動フェイルオーバーを実行する前に、プライマリ・データベースが停止されていることを確認する必要があります。

注意:
必要な場合は、FORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化できます。5.5.5項「ファスト・スタート・フェイルオーバーの無効化」を参照してください。

参照:
スイッチオーバーおよび手動フェイルオーバーの詳細は、それぞれ5.3項および5.4項を参照してください。

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

DBMS_DG PL/SQLパッケージを使用して、特定の条件が満たされたときにアプリケーションによりファスト・スタート・フェイルオーバーを指示することができます。アプリケーションに独自に認識される重大な条件が検出されたとき、DBMS_DG.INITIATE_FS_FAILOVER機能をコールして、プライマリ・データベースまたはファスト・スタート・フェイルオーバーのターゲットになっているスタンバイ・データベースに、ファスト・スタート・フェイルオーバーをすぐに開始することを通知するアラートを送信できます。プロシージャがコールされたデータベースは、オブザーバにそれを通知します。スタンバイがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)、オブザーバによりただちにファスト・スタート・フェイルオーバーが開始されます。オブザーバによってファスト・スタート・フェイルオーバーが開始されると、プライマリ・データベースは自動的に停止します。オブザーバは元のプライマリ・データベースの回復を試行しません。

構成がフェイルオーバー不能の場合、DBMS_DG.INITIATE_FS_FAILOVER機能は、ORAエラー番号(例外ではなく)を返して、ファスト・スタート・フェイルオーバーを実行できないことをコール元に通知します。

注意:
可能でさえあればオブザーバがフェイルオーバーを開始するため、アプリケーションは、この機能をコールする際に注意が必要です。

参照:
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

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構成のファスト・スタート・フェイルオーバー情報を示しています。

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
North_Sales  - Primary database
South_Sales  - (*) Physical standby database

(*) Fast-Start Failover target

Properties:
FastStartFailoverThreshold      = '60'
OperationTimeout                = '30'
FastStartFailoverLagLimit       = '30'
CommunicationTimeout            = '180'
FastStartFailoverAutoReinstate  = 'TRUE'
FastStartFailoverPmyShutdown    = 'TRUE'
BystandersFollowRoleChange      = 'ALL'

Fast-Start Failover: ENABLED

Threshold:        180 seconds
Target:           South_Sales
Observer:         observer.example.com
Lag Limit:        30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate:   TRUE

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*ログ・ファイルの詳細は、9.1項を参照してください。

完了済

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 ファスト・スタート・フェイルオーバーの無効化

ファスト・スタート・フェイルオーバーを無効化すると、オブザーバはターゲット・スタンバイ・データベースへのフェイルオーバーを開始できなくなります。この場合、手動フェイルオーバーが可能な場合があります。手動フェイルオーバーの詳細は、5.4項を参照してください。

注意:
ファスト・スタート・フェイルオーバーを無効にしても、オブザーバは停止されません。オブザーバを停止するには、5.5.7.4項「オブザーバの停止」を参照してください。

ファスト・スタート・フェイルオーバーを無効化するには、Enterprise Managerのファスト・スタート・フェイルオーバー・ウィザードまたはDGMGRLのDISABLE FAST_START FAILOVER [FORCE]コマンドを使用します。FORCEオプションを使用すると、エラーが発生した場合でも、接続先のデータベースでファスト・スタート・フェイルオーバーが無効化されます。FORCEオプションが必要かどうかは、プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在するかどうかによって決まります。

- プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在し、接続先のデータベースがプライマリ・データベースとネットワークで接続されている場合、FORCEオプションを使用しても効果はありません。オプションを指定せずにDISABLE FAST_START FAILOVERを使用してください。この方法では、ブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーが無効化されます。
無効化操作中にエラーが発生した場合、ブローカによりエラー・メッセージが戻され、無効化操作が停止されます。

- プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在しないか、または接続先のデータベースにプライマリ・データベースとのネットワーク接続が存在しない場合、DISABLE FAST_START FAILOVERをFORCEオプションとともに使用することを考慮します。
DISABLE FAST_START FAILOVER FORCEコマンドを発行した場合、ブローカはブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーを無効化できない場合があります。その結果、フェイルオーバーの条件を満たしているとオブザーバが判別した場合に、オブザーバがターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーを実行しないという保証がなくなります。次のリストに、プライマリ・データベース、ターゲット・スタンバイ・データベースおよびファスト・スタート・フェイルオーバーのターゲットでないスタンバイ・データベースで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オプションを使用してファスト・スタート・フェイルオーバーを無効にします。プライマリ・データベースとターゲット・スタンバイ・データベースとの接続が回復すると、構成内のすべてのデータベースでファスト・スタート・フェイルオーバーが無効化されます。

Enterprise Managerを使用したファスト・スタート・フェイルオーバーの無効化

ファスト・スタート・フェイルオーバー・ウィザードで「無効化」をクリックします。次に、「続行」をクリックして次のページに進みます。詳細は、Enterprise Managerのオンライン・ヘルプ・システムを参照してください。

DGMGRLを使用したファスト・スタート・フェイルオーバーの無効化

DISABLE FAST_START FAILOVERコマンドまたはDISABLE FAST_START FAILOVER FORCEコマンドを発行します。詳細は、第7章のDISABLE FAST_START FAILOVERコマンドに関する項を参照してください。

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

ファスト・スタート・フェイルオーバーを使用する際のパフォーマンスを向上させるには、次の推奨事項を考慮します。

- フェイルオーバー時間は、ターゲット・スタンバイ・データベース(フィジカルまたはロジカル・スタンバイ・データベース)がプライマリ・データベースから受け取ったREDOデータをすべて適用したかどうかによって決まります。

- 最大パフォーマンス・モードで動作している構成でファスト・スタート・フェイルオーバーを有効化すると、REDOデータが非同期でターゲット・スタンバイに転送されるため、プライマリ・データベースでの全体的なパフォーマンスが向上します。この場合はデータが消失しないことが保証されないことに注意してください。

- スタンバイ・データベースへのREDOデータの適用がプライマリ・データベースのREDO適用率と一致した状態が保たれるように、リカバリを最適化する手順を実行すると、ファスト・スタート・フェイルオーバーが高速になります。ログ適用率を最適化するには、次のようにします。

- データベース・プロパティDelayMinsを設定することにより、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用を遅延させないでください(詳細は、4.5項を参照してください)。

- フィジカル・スタンバイ・データベースのログ適用率のチューニングの詳細は、『Oracle Data Guard概要および管理』を参照してください。

- 次の場所にあるホワイト・ペーパー『Oracle Maximum Availability Architecture』を参照してください。
http://www.oracle.com/goto/maa

- FastStartFailoverLagLimit構成プロパティを設定する際は、パフォーマンスとデータ消失の可能性の間のトレードオフを考慮してください。

- ラグ制限を低くすると、データの消失は最小限に抑えられますが、プライマリ・データベースのパフォーマンスに影響を与える場合があります。

- ラグ制限を高くすると、消失データ量が増加する可能性がありますが、プライマリ・データベースのパフォーマンスへの影響は緩和されます。

5.5.7 オブザーバの管理

オブザーバは、ブローカのDGMGRLクライアント側コンポーネントに統合されており、プライマリ・データベースまたはスタンバイ・データベースおよびブローカ構成を管理するコンピュータとは異なるコンピュータ上で動作します。オブザーバは、ファスト・スタート・フェイルオーバー環境を継続的に監視し、プライマリ・データベースが使用可能であることを確認します(5.5.2.1項を参照)。オブザーバの主な目的は、停止時間が長くなる可能性がある、手動フェイルオーバー・プロセスで必要な人的操作を少なくすることで、高可用性および完全自動コンピューティングを強化することです。

Oracle Enterprise ManagerのData Guardの概要ページまたはDGMGRLコマンドを使用して、オブザーバを管理できます。図5-2に、オブザーバによるファスト・スタート・フェイルオーバー構成の監視を示しています。

図5-2 ファスト・スタート・フェイルオーバー環境でのオブザーバ

次の各項では、オブザーバの管理情報を説明します。

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

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

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

- オブザーバの停止

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

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

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

オブザーバは、プライマリ・システムおよびスタンバイ・システムとは別のコンピュータ・システムにインストールし、動作させる必要があります。オブザーバのインストールおよび起動は、ファスト・スタート・フェイルオーバーの使用における必須部分であり、次の各項で詳細に説明しています。

- 2.1項では、オブザーバ・システムでのOracle Database Enterprise EditionまたはOracle Personal Editionのインストールについて説明しています。

- 5.5.2項では、ファスト・スタート・フェイルオーバーを有効化する段階的なプロセスの一部として、オブザーバの起動方法を説明しています。DGMGRLを使用したオブザーバの起動例は、6.6項に示しています。

ブローカ構成を監視するオブザーバは1つのみ存在できます。別のオブザーバを起動しようとすると、ブローカにより次のエラー・メッセージが戻されます。

ORA-16647: could not start more than one observer

オブザーバを起動するには、SYSDBA権限を持つアカウントでDGMGRLにログインできる必要があります。オブザーバは、DGMGRLでData Guard構成に接続したときに使用したSYS資格証明を使用してプライマリ・データベースおよびターゲット・スタンバイ・データベースに接続するOCIクライアントです。

オブザーバとDGMGRLは同じOracle Databaseリリースを実行している必要があります。たとえば、DGMGRLがOracle Databaseリリース2 (11.2.0.4)システムで実行されている場合は、オブザーバも11.2.0.4で実行されている必要があります。

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.4項「ファスト・スタート・フェイルオーバー構成の統計およびステータスの表示」

5.5.7.4 オブザーバの停止

ファスト・スタート・フェイルオーバーを使用しない場合(5.5.5項「ファスト・スタート・フェイルオーバーの無効化」を参照)、またはオブザーバを別のホスト・マシンに移動する場合は(5.5.7.5項「オブザーバの別のコンピュータへの移動」を参照)、オブザーバを停止できます。

ファスト・スタート・フェイルオーバーが有効化されているときにオブザーバを停止するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースが接続されており、相互に通信している必要があります。オブザーバを停止しても、ファスト・スタート・フェイルオーバーは無効化されません。ただし、ターゲット・スタンバイ・データベースが監視されない状態の場合、ファスト・スタート・フェイルオーバーは実行できません。

ファスト・スタート・フェイルオーバーが有効化されているが、プライマリ・データベースとスタンバイ・データベースが相互に分離している場合にオブザーバを停止するには、FORCEオプションを使用してまずファスト・スタート・フェイルオーバーを無効化してから、オブザーバを停止する必要があります。(FORCEオプションを使用する際に考慮すべき重要事項については、5.5.5項「ファスト・スタート・フェイルオーバーの無効化」を参照してください。)

ファスト・スタート・フェイルオーバーが有効化されていない場合にオブザーバを停止するには、プライマリ・データベースが動作している必要があります。プライマリ・データベースとネットワークで接続されたブローカ構成内のデータベースに接続しているときは、次の方法でオブザーバを停止できます。

- Enterprise Managerの使用
ファスト・スタート・フェイルオーバー・ウィザードの1ページ目で「オブザーバを停止」オプションを選択し、ページ下部の「続行」をクリックします。詳細は、Enterprise Managerのオンライン・ヘルプ・システムを参照してください。

- DGMGRLの使用
次のコマンドを発行します。

DGMGRL> STOP OBSERVER;

詳細は、STOP OBSERVERコマンドを参照してください。

注意:
オブザーバは、STOP OBSERVERコマンドを発行してすぐには停止しません。ブローカがSTOP OBSERVER要求を受け取ると、要求は次回オブザーバがブローカと通信する際にオブザーバに渡され、その後にオブザーバは停止します。

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

オブザーバを別のコンピュータに移動する手順は、次のとおりです。

1. 5.5.7.4項の説明に従って、ブローカ構成内の任意のコンピュータ・システムからオブザーバを停止します。

2. 5.5.2項の手順8の説明に従って、新規コンピュータ・システムでオブザーバを起動します。

オブザーバを移動する際にファスト・スタート・フェイルオーバーを無効化する必要はありません。

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

オブザーバでは、オブザーバを起動した作業ディレクトリに作成されているバイナリ・ファイルで、ファスト・スタート・フェイルオーバー構成に関する情報が永続的にメンテナンスされます。デフォルトでは、オブザーバの起動時に、現行の作業ディレクトリにこのファイルが作成され、fsfo.datという名前が付けられます。このファイルには、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方に対する接続識別子が含まれます。

権限のないユーザーはこのファイルを読めないことを確認します。

オブザーバの起動後は、ファイルの名前および場所を変更できません。ただし、オブザーバの起動にDGMGRLのSTART OBSERVERコマンドを使用し、FILE修飾子を含める場合は、ファイルの名前または場所を変更できます。詳細は、START OBSERVERコマンドを参照してください。

注意:
オブザーバが通常と異なる方法で(CTRL/Cを入力するなど)停止された場合、オブザーバを再起動し、FILE修飾子を含む既存のfsfo.datファイルを参照してください。

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.8 ブローカ構成に含まれる元のプライマリ・データベースの回復

FastStartFailoverAutoReinstate構成プロパティをTRUEに設定すると、プライマリ・データベースがクラッシュするか、オブザーバおよびターゲット・スタンバイ・データベースとの接続が失われたことが原因でファスト・スタート・フェイルオーバーが開始された場合、オブザーバは元のプライマリ・データベースのスタンバイ・データベースとしての回復を自動的に試行します。回復により、ブローカ構成に対する高可用性がリストアされるため、新規プライマリ・データベースに障害が発生した場合に、別のファスト・スタート・フェイルオーバーが実行されます。回復されたデータベースは、新規プライマリ・データベースのファスト・スタート・フェイルオーバーのターゲットとして機能し、後続のファスト・スタート・フェイルオーバーが可能になります。新規スタンバイ・データベースは、新規プライマリ・データベースからのREDOデータの受信を開始した時点で、フェイルオーバーの実行可能なターゲットとなります。

オブザーバによる元のプライマリ・データベースの自動回復を可能にするには、データベースを起動およびマウントする必要がありますが、オープンしないでください。オープンしている場合、オブザーバは元のプライマリ・データベースを再起動してマウント済状態にしてからデータベースを回復します。ブローカは、データベースを新しいプライマリ・データベースのスタンバイ・データベース(元のスタンバイと同じタイプ)として回復します。

元のプライマリ・データベースが自動的に回復されない場合、DGMGRLのREINSTATEコマンドまたはEnterprise Managerを使用して手動で回復できます。手動回復の段階的な手順は、5.4.3項を参照してください。

5.5.8.1 要件

回復がサポートされるのは、ブローカ構成でフェイルオーバーを実行した後に限られます。また、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方でフラッシュバック・データベースを有効化する必要があります。すべてのファスト・スタート・フェイルオーバーおよび回復の要件の詳細は、5.5.1項を参照してください。

5.5.8.2 回復に関する制限事項

次の場合、ブローカでは元のプライマリ・データベースを自動的に回復できません。

- ユーザーが構成可能な条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションで要求した場合

- FastStartFailoverAutoReinstateがFALSEに設定されている場合

- ファスト・スタート・フェイルオーバーの完了後、元のプライマリ・データベースが再起動されるまでに別のフェイルオーバーまたはスイッチオーバーが発生した場合

- ファスト・スタート・フェイルオーバーが無効化されている場合

- オブザーバが元のプライマリ・データベースに接続できない場合

- 元のプライマリ・データベースが新規プライマリ・データベースに接続できない場合

- 元のプライマリ・データベースおよび新規プライマリ・データベースが、同じファスト・スタート・フェイルオーバー環境内で構成されていない場合

- ファスト・スタート・フェイルオーバーが無効化されているとき、手動フェイルオーバーによって元のプライマリ・データベースが無効化された場合

注意:
スイッチオーバー、手動フェイルオーバーまたはファスト・スタート・フェイルオーバーの実行時にスタンバイ・データベースを無効した場合は、自動的に回復されません。

自動回復に失敗した場合、ブローカによりエラーがログに記録され、元のプライマリ・データベースはマウントされた状態のままとなります。この時点で、次のいずれかを実行できます。

- ファスト・スタート・フェイルオーバーを無効化し(5.5.5項を参照)、元のプライマリ・データベースのオープンを試行する。

- 5.4.3項の説明に従って、元のプライマリ・データベースを手動で回復する。

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

回復操作(自動または手動)が進行中のときに障害が発生した場合、ブローカにより、ブローカ構成ファイルおよびブローカ・ログ・ファイルに、適切な情報が記録されます。元のプライマリ・データベースは無効化されます。進行中の障害のほとんどは再起動できません(プライマリ・データベースにおけるアーカイブREDOログ・ファイルの破損など)。データベースをスタンバイ・データベースとして手動で再作成してから再有効化する必要があります。

参照:
5.4.3.2項「無効化されたデータベースの再作成および再有効化の方法」

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

プライマリ・データベースまたはスタンバイ・データベースを停止する必要がある場合、次の手順を実行します。

1. オブザーバを停止し、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方について、V$DATABASE固定ビューのFS_FAILOVER_OBSERVER_PRESENT列に値「NO」が含まれるまで待機します。こうすると、プライマリ・データベースの停止中に、ファスト・スタート・フェイルオーバーは実行されません。

2. DGMGRLのSHUTDOWNコマンドまたはSQL*PlusのSHUTDOWN文を使用して、プライマリ・データベースおよびターゲット・スタンバイ・データベースを停止します。

データベースを再起動する場合、任意の順序で実行できます。両方のデータベースを再起動したら、オブザーバを再起動できます。

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

この項では、ブローカ管理のフェイルオーバーが発生したときにデータベース・クライアントで使用可能な、イベント通知およびデータベース接続フェイルオーバーのサポートについて説明します。

フェイルオーバー後、ブローカは高速アプリケーション通知(FAN)イベントを発行します。FANイベントは次の方法で使用できます。

- アプリケーションでOracle Database JDBC、Oracle Database Oracle Call Interface(OCI)、Oracle Data Provider for .NET(ODP.NET)のいずれかのOracle統合データベース・クライアントを使用している場合、プログラムを変更せずにFANを使用できます。これらのクライアントには、フェイルオーバー後に自動的に新規プライマリ・データベースに接続する高速接続フェイルオーバー(FCF)を構成できます。

- JAVAアプリケーションはJDBC FANアプリケーション・プログラミング・インタフェースを利用してFANをプログラムで使用することで、FANイベントにサブスクライブし、イベント受信時にイベント処理アクションを実行できます。

- FANのサーバー側コールアウトをデータベース層で構成できます。

FANイベントは、Oracle Notification Service(ONS)とOracle Streamsアドバンスト・キューイング(AQ)を使用して発行されます。

注意:
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 Data Guard固有のFANおよびFCFの構成要件

この項では、ブローカ管理のフェイルオーバーによって生成されたFANイベントを発行および適切に処理するために満たす必要のある構成要件について説明します。

これらの要件は、前述のマニュアルおよび次のクライアント固有ガイドに記載されている要件を補足するものです。

- 『Oracle Database JDBC開発者ガイド』

- Oracle Call Interfaceプログラマーズ・ガイド

- Oracle Data Provider for .NET開発者ガイド

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を使用して発行されます。ただし、データベースが新規プライマリ・データベースでプライマリ・ロールになっている場合、フェイルオーバーを通知するイベントは、アクティブに構成されているデータベース・サービスに対してのみ発行されます。FANイベントがAQを使用して発行されるように、サービスを構成することもできます。OCIまたはODP.NETクライアントを使用している場合、これらのクライアントが使用するFANイベント通知メカニズムである、AQによるFANイベント発行を明示的に有効化する必要があります。

任意のデータベース・ロールでアクティブでなければならないサービス(プライマリ、フィジカル・スタンバイ、ロジカル・スタンバイまたはスナップショット・スタンバイ)は、サービスがアクティブでなければならない各データベースで明示的にSRVCTLユーティリティによって構成する必要があります。次のコマンドの例では、サービスPAYROLLがプライマリ・データベースNORTHのPRIMARYロール(-lオプション)でアクティブになるように構成されています。また、スタンバイ・データベースSOUTHのPRIMARYロールでもアクティブになるように構成されているため、ロール・トランジションが発生した場合にはそのデータベースでアクティブになります。AQによるFANイベント通知も有効化されています。

次をプライマリ・データベースNORTHで実行します。

srvctl add service –d NORTH –s PAYROLL –l PRIMARY -q TRUE -e SELECT -m BASIC -w 10 -z 150

次をスタンバイ・データベースSOUTHで実行します。

srvctl add service –d SOUTH –s PAYROLL –l PRIMARY -q TRUE -e SELECT -m BASIC -w 10 -z 150

サービスを現在のプライマリ・データベースで起動するかどうかにかかわらず、データベースがフィジカル・スタンバイ・ロールになっているときにアクティブにするサービスも、そのデータベースで作成および起動する必要があります。これは、サービス定義がREDOストリームを介してフィジカル・スタンバイ・データベースに伝播されるようにするためです。これにより、サービスをフィジカル・スタンバイ・データベースで起動できるようになります。サービスをフィジカル・スタンバイで起動できるのは、サービスを起動することによって生成されたREDOが適用された後のみです。次のSRVCTL追加サービスオプションを指定して、すべてのデータベース上で同じ値を持つことは重要です。

オプション

説明

-B

ロード・バランシング・アドバイザの目標。

-x

分散トランザクション処理を有効化するかどうかを示します。

-q

AQ HA通知を有効化するかどうかを示します。

-m

フェイルオーバーのメソッド。

-e

フェイルオーバーのタイプ。

-z

フェイルオーバー再試行。

-w

フェイルオーバーの遅延。

-j

接続ロード・バランシングの目標。

-t

エディション名。

すべてのデータベースが同じ値を持たない場合、SRVCTLは値を上書きしようとしますが、フィジカル・スタンバイ・データベースで失敗します。これは、データベースが読取り専用でオープンであるためです。次のコマンドの例では、サービスsalesがプライマリ・データベースNORTHのPHYSICAL_STANDBYロール(-lオプション)でアクティブになるように構成されています。その後、プライマリ・データベースで起動および停止されます。このサービスを現在のプライマリ・データベース上で実行しない場合は、オプションでプライマリ・データベースから削除することもできます。これは、フィジカル・スタンバイ・データベースSOUTHのPHYSICAL_STANDBYロールでもアクティブになるように構成されます。

次をプライマリ・データベースNORTHで実行します。

srvctl add service -d NORTH -s sales -l PHYSICAL_STANDBY -q TRUE -e SELECT -m BASIC -w 10 -z 150
srvctl start service –d NORTH –s sales
srvctl stop service –d NORTH –s sales

次をフィジカル・スタンバイ・データベースSOUTHで実行します。

srvctl add service -d SOUTH -s sales -l PHYSICAL_STANDBY -q TRUE -e SELECT -m BASIC -w 10 -z 150

注意:
サービスが自動的に起動するように構成されている場合(-y AUTOMATIC)、データベース・ロールが変更された後にのみ、自動的に起動します。

参照:

- Oracle Restartにより管理される単一インスタンス・データベースでの、SRVCTLユーティリティを使用するデータベース・サービスの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

- Oracle RACデータベースでの、SRVCTLユーティリティを使用するデータベース・サービスの構成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

5.6.1.3 ONSの構成要件

クライアント側のONS構成を使用する場合、クライアント側のONS構成ファイルで、プライマリ・データベースおよび各スタンバイ・データベースのONSデーモンのホスト名およびポートを指定する必要があります。

クライアントでリモートONSサブスクリプションを使用する場合、クライアントでプライマリ・データベースおよび各スタンバイ・データベースのONSデーモンのホスト名およびポートを指定する必要があります。

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

この章では、Data Guardコマンドライン・インタフェース(DGMGRL)の使用を開始するための前提条件について説明します。また、DGMGRLを使用してブローカ構成を作成、管理および監視する方法について例をあげて説明します。

この章の内容は、次のとおりです。

- 初期使用の前提条件

- 使用例1: 構成の作成

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

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

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

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

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

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

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

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

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

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

6.1 初期使用の前提条件

DGMGRL使用の前提条件の1つは、1つのプライマリ・データベースと任意の数のスタンバイ・データベースが存在していることです。構成内のすべてのデータベースについて、DG_BROKER_START初期化パラメータをTRUEに設定する必要があります。ブローカではサーバー・パラメータ・ファイルを使用してください(2.1項および7.1.3項を参照してください)。

必要な場合は、プライマリ・データベースとスタンバイ・データベースの初期化パラメータ・ファイル(PFILE)をサーバー・パラメータ・ファイル(SPFILE)に変換します。次のSQL*Plusコマンドを使用します。

CREATE SPFILE 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の起動

DGMGRLを起動するには、Oracle Data Guardがインストールされているシステム上で、コマンドライン・プロンプトからdgmgrlと入力します。

$ dgmgrl

DGMGRLプロンプトが表示されます。

DGMGRL>

手順2   プライマリ・データベースへの接続

任意のコマンド(HELP、EXITまたはQUIT以外)を指定する前に、まずDGMGRL CONNECTコマンドを使用してプライマリ・データベースに接続する必要があります。

データベースへの接続に使用するアカウント(この例ではSYS)には、プライマリ・データベースとスタンバイ・データベースでのSYSDBA権限が必要です。

注意:
SYSDBAはCONNECTコマンドのデフォルト設定であるため、このコマンドでAS SYSDBAを指定する必要はありません。

次の例は、CONNECTコマンドの2つのバリエーションを示しています。例6-1に、ローカル・システム上のデフォルト・データベースに接続する方法を示し、例6-2に、リモート・システムにあるデータベースに接続するためのOracle Net Services接続識別子(
North_Sales.example.com)を示します。この2つの例ではどちらもパスワードの入力を要求されます。

例6-1 ローカル・システム上のプライマリ・データベースへの接続

DGMGRL> CONNECT sys;
Password: password
Connected.

例6-2 リモート・システム上のプライマリ・データベースへの接続

DGMGRL> CONNECT sys@North_Sales.example.com;
Password: password
Connected.

手順3   ブローカ構成の作成

ブローカ構成を作成するには、まずプライマリ・データベース(この例では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初期化パラメータの値です。

手順4   構成情報の表示

SHOW CONFIGURATIONコマンドを使用して、構成に関する簡単なサマリーを表示します。

DGMGRL> SHOW CONFIGURATION;

DGMGRLは次の情報を戻します。

Configuration - DRSolution

Protection Mode: MaxPerformance
Databases:
North_Sales - Primary database

Fast-Start Failover: DISABLED

Configuration Status:
DISABLED

手順5   構成へのスタンバイ・データベースの追加

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)
Real Time Query: OFF
Instance(s):
south_sales1

Properties:
DGConnectIdentifier             = 'South_Sales.example.com'
ObserverConnectIdentifier       = ''
LogXptMode                      = 'ASYNC'
DelayMins                       = '0'
Binding                         = 'optional'
MaxFailure                      = '0'
MaxConnections                  = '1'
ReopenSecs                      = '300'
NetTimeout                      = '30'
RedoCompression                 = 'DISABLE'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/t, dbs/bt'
LogFileNameConvert              = 'dbs/t, dbs/bt'
FastStartFailoverTarget         = ''
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
SidName                         = 'south_sales1'
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                = 'db2r_%d_%t_%s_%R.arc'
LatestLog                       = '(monitor)'
TopWaitEvents                   = '(monitor)'

Database Status:
DISABLED

データベースのブローカ管理が有効な場合は、データベース・プロパティ値を設定すると、対応するデータベースの基礎となるパラメータ値が変更され、変更されたパラメータの値がサーバー・パラメータ・ファイルに反映されます。したがって、データベースがOracle Enterprise Managerおよび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
Apply Lag:       0 seconds
Real Time Query: OFF
Instance(s):
south_sales1

Database Status:
SUCCESS

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

構成の保護モードはいつでも変更できます。ただし、最大保護モードまたは最大可用性モードに移行する場合は、構成内でアクティビティが発生していないときに変更することをお薦めします。

注意:
保護モードを最大パフォーマンス・モードから最大保護モードに変更すると、ブローカによりプライマリ・データベースが自動的に再起動されます。データベースの再起動を回避するには、まず保護モードを最大可用性モードに変更してから、次に保護モードを最大保護モードに変更します。
保護モードを次のように変更する場合、プライマリ・データベースの再起動は不要です。

- 最大パフォーマンスから最大可用性

- 最大可用性から最大保護

この使用例では、構成の保護モードをMAXAVAILABILITYモードに設定します。この保護モードに設定するには、少なくとも1つのスタンバイ・データベースをスタンバイREDOログ・ファイルを使用するように構成し、データベース・プロパティLogXptModeをSYNCに設定する必要があります。

手順1   スタンバイREDOログ・ファイルの構成(必要な場合)

保護モードをMAXAVAILABILITYモードに設定するため、スタンバイ・データベースに十分なスタンバイREDOログ・ファイルが構成されていることを確認する必要があります。

手順2   データベース・プロパティLogXptModeの適切な設定

EDIT DATABASE(プロパティ)コマンドをスタンバイ・データベースで使用し、設定する保護モードに対応するREDO転送サービスを設定します。保護モードをMAXAVAILABILITYに設定する場合は、少なくとも1つのスタンバイ・データベースのREDO転送サービスをSYNCに設定する必要があります。次に例を示します。

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
Databases:
North_Sales  - Primary database
South_Sales  - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

参照:
4.6項「データ保護モード管理」

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

ブローカ構成のデータベースに接続されているかぎり、オブザーバ・サイトを含め、任意のサイトからファスト・スタート・フェイルオーバーを有効化できます。ファスト・スタート・フェイルオーバーを有効化しても、フェイルオーバーは起動されません。かわりに、フェイルオーバーの条件が満たされた場合に、構成を監視しているオブザーバがファスト・スタート・フェイルオーバーを起動できるようになります。

ファスト・スタート・フェイルオーバーは、最大パフォーマンス保護モードまた最大可用性保護モードで動作している構成で有効化できます。この項では、ファスト・スタート・フェイルオーバーを有効化し、構成の保護モードが最大可用性モードに設定されるオブザーバを起動する手順を説明します。

手順1   スタンバイREDOログがプライマリ・データベースおよびターゲット・スタンバイ・データベースで構成されていることの確認

スタンバイREDOログは、プライマリ・データベースおよびスタンバイ・データベースで構成されている必要があります。スタンバイREDOログを構成する前に、ログ適用サービスを停止する必要があります。

参照:
スタンバイREDOログ・ファイルの構成方法は、『Oracle Data Guard概要および管理』を参照してください。

手順2   LogXptModeプロパティがSYNCに設定されていることの確認

データベース・プロパティLogXptModeは、プライマリ・データベースとターゲット・スタンバイ・データベースでSYNCに設定されている必要があります。

設定する保護モードに対応するREDO転送サービスを設定するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースでEDIT DATABASE(プロパティ)コマンドを使用します。たとえば、保護モードをMAXAVAILABILITYに設定する場合、次の例に示すように、プライマリ・データベースおよびターゲット・スタンバイ・データベースで、LogXptModeプロパティをSYNCに設定する必要があります。

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   FastStartFailoverTarget構成プロパティの設定

2つ以上のスタンバイ・データベースがある場合、プライマリ・データベースのFastStartFailoverTarget構成プロパティを設定して目的のターゲット・スタンバイ・データベースを指定します。ファスト・スタート・フェイルオーバーが実際に有効化される際、ブローカにより、今度は反対にターゲット・スタンバイ・データベースのこのプロパティが将来のターゲット・スタンバイ・データベースとしてプライマリ・データベースを指すように設定されます。このプロパティは自動的に設定されるため、ターゲット・スタンバイ・データベースでこのプロパティを設定する必要はありません。次に例を示します。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget='South_Sales';
Property "FastStartFailoverTarget" updated

手順4 保護モードのMAXAVAILABILITYへのアップグレード(必要な場合)

保護モードのアップグレードが必要な場合、次の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を実行します。SYSDBA権限を持つユーザーとして構成に接続し、START OBSERVERコマンドを発行します。このコマンドでは戻り値がない点に注意してください。つまり、コマンドを発行してもDGMGRLプロンプトを取得しません。

DGMGRL> CONNECT sys@North_Sales.example.com;
Password: password
Connected.
DGMGRL> START OBSERVER;
Observer started

対話形式でオブザーバを起動する場合、接続資格証明をDGMGRL接続コマンドに対するコマンドライン・パラメータとして指定しないことをお薦めします。この処理により、システムの他のユーザーがユーティリティ(UNIXのpsユーティリティなど)を使用して接続資格証明を表示することを回避できます。また、クリアテキストのパスワードがユーザーの端末に表示されるのを防ぐことができます。

スクリプトからオブザーバを起動する場合、データベース接続資格証明をスクリプト内に埋め込まなくてすむように、「connect/」をサポートする方法を使用することをお薦めします。クライアント側のOracleウォレットをセキュアな外部パスワード・ストアとして使用する場合(『Oracle Database Advanced Security管理者ガイド』を参照)、プライマリ・データベースおよびファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースの資格証明を追加する必要があります。各データベースの資格証明を追加するとき、指定するデータベース接続文字列は、データベース・プロパティObserverConnectIdentiferまたはDGConnectIdentifierと一致している必要があります。

手順7   ファスト・スタート・フェイルオーバーの有効化

ブローカ構成のデータベースに接続されている間は、ファスト・スタート・フェイルオーバーを有効化できます。次に例を示します。

DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.

手順8   ファスト・スタート・フェイルオーバー構成の検証

SHOW FAST_START FAILOVERコマンドを使用して、ファスト・スタート・フェイルオーバーの設定を表示します。

DGMGRL> SHOW FAST_START FAILOVER;

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

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.7 使用例6: 定期的な管理タスクの実施

1つ以上のデータベースの定期的なメンテナンスを実行するために、ブローカ構成に含まれるデータベースの状態やプロパティの変更が必要になる場合があります。また、構成に含まれるデータベースのブローカ管理を一時的に無効化する必要が生じる場合もあります。

6.7.1 プロパティと状態の変更

構成の監視中に、データベースやそのプロパティの状態を動的に変更する操作が必要になる場合があります。次の各項で、構成内のデータベースの状態またはプロパティを変更する方法について説明します。

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

データベース・プロパティの値は、データベースが有効か無効かに関係なくいつでも変更できます。

例6-3に、EDIT DATABASEコマンドを使用してNorth_Salesデータベースのデータベース・プロパティLogXptModeを値ASYNCに変更する方法を示します。

例6-3 データベース・プロパティの変更

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogXptMode'=ASYNC;

DGMGRLは次のメッセージを戻します。このメッセージは、LogXptModeプロパティがData Guard構成ファイル内で正常に更新されたことを示します。

Property "LogXptMode" updated

構成が現在無効の場合は、ENABLE CONFIGURATIONコマンドでブローカ構成を有効化するまで、データベースで新規プロパティ値が使用されません。

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

フィジカル・スタンバイのREDO Applyを一時的に停止します。スタンバイ・データベースの状態をAPPLY-OFFに変更するには、例6-4のようにEDIT DATABASEコマンドを入力します。

例6-4 スタンバイ・データベースの状態変更

DGMGRL> EDIT DATABASE 'South_Sales' SET STATE='APPLY-OFF';
Succeeded.

フィジカル・スタンバイ・データベースをAPPLY-OFF状態にしても、REDOデータは引き続き受信されます。

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

スタンバイ・データベースへのREDOデータの転送を停止します。これに対応してプライマリ・データベースの状態を変更するには、次のコマンドを使用します。

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

Succeeded.

プライマリ・データベースの状態をTRANSPORT-ONに戻すには、次のコマンドを使用します。

DGMGRL> EDIT DATABASE North_Sales SET STATE=TRANSPORT-ON;

Succeeded.

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

ブローカ構成またはそのデータベースのいずれかを無効化すると、それらのオブジェクトのブローカによる管理が無効化されるため、DGMGRLを使用して無効なオブジェクトを管理および監視できなくなります。ただし、ブローカによるブローカ構成の管理を無効にしても、基礎となるData Guard構成またはデータベースの実際の操作には影響しません。たとえば、Data Guard構成内のREDO転送サービスとログ適用サービスは、管理できなくなりますが、そのまま機能し続けます。

6.7.2.1 構成の無効化

プライマリ・データベースを含むブローカ構成全体の管理を無効化するには、例6-5のように、DISABLE CONFIGURATIONコマンドを使用する必要があります。

例6-5 構成とプライマリ・データベースの無効化

DGMGRL> DISABLE CONFIGURATION;

プライマリ・データベースのブローカ管理を無効化するには、DISABLE CONFIGURATIONコマンドを使用する必要があります。DISABLE DATABASEコマンドで無効化されるのは、スタンバイ・データベースの管理のみです。

注意:
スタンバイ・データベースへの接続中に構成の管理を無効化した場合は、構成を再び有効化するために、プライマリ・データベースに接続する必要があります。

ブローカによるオブジェクトの管理を無効にしても、そのプロファイルはブローカ構成ファイルから削除されません。該当するENABLE CONFIGURATIONまたはENABLE DATABASEコマンドを入力すると、DGMGRL(またはEnterprise Manager)によるオブジェクト管理機能を再び有効化できます。

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

ブローカによるスタンバイ・データベースの管理と監視が一時的に不要になった場合は、DISABLE DATABASEコマンドを使用します。

構成の他の部分が有効な場合は、スタンバイ・データベースが有効化されないようにブローカ管理を明示的に無効化できます。例6-6に、スタンバイ・データベースSouth_Salesを無効化する方法を示します。

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

DGMGRL> DISABLE DATABASE 'South_Sales';
Disabled.

注意:
構成内のスタンバイ・データベースを無効にするとき、ファスト・スタート・フェイルオーバーが有効化されている場合、ターゲット・スタンバイ・データベースは無効化できません。

注意:
スタンバイ・データベースへの接続中にそのスタンバイ・データベースの管理を無効化した場合は、スタンバイ・データベースのブローカ管理を再び有効化するために、プライマリ・データベースまたは別の有効化されたスタンバイ・データベースに接続する必要があります。

注意:

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

最大保護モードまたは最大可用性モードのいずれかで動作している場合、ブローカでは、保護モードをサポートする最後の1つのスタンバイ・データベースを無効化できません。

6.7.3 構成またはスタンバイ・データベースの削除

REMOVE CONFIGURATIONまたはREMOVE DATABASEコマンドを使用すると、ブローカ構成ファイルから構成またはスタンバイ・データベースのプロファイルが削除され、Data Guard Brokerによる構成の管理機能またはスタンバイ・データベース管理機能がそれぞれ削除されます。

削除操作でPRESERVE DESTINATIONS句を使用した場合、実際のData Guard構成は削除されず、実際のData Guard構成とそのデータベースの操作には影響しません。

注意:
REMOVE CONFIGURATIONまたはREMOVE DATABASEコマンドを使用した後は、ブローカ構成ファイルから削除された構成またはデータベース・プロファイルをリカバリできません。必要な場合は6.2項の手順に従って、DGMGRL(またはEnterprise Manager)で管理できるブローカ構成を作成する必要があります。

注意:
構成内のスタンバイ・データベースを削除するとき、ファスト・スタート・フェイルオーバーが有効化されている場合、ターゲット・スタンバイ・データベースは削除できません。

手順1   構成からのスタンバイ・データベースの削除

REMOVE DATABASEコマンドを使用すると、ブローカによるデータベースの管理と監視が停止され、データベースのプロファイルがブローカ構成ファイルから削除されます。

South_Salesスタンバイ・データベースを削除する前の構成を示します。

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データベース情報を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

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

最大保護モードまたは最大可用性モードのいずれかで動作している場合、ブローカでは、保護モードをサポートする最後の1つのスタンバイ・データベースを削除できません。

手順2   ブローカ構成の削除

次のコマンドを使用すると、構成全体がブローカによって管理および監視されなくなります。

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.8 使用例7: スイッチオーバー操作の実行

プライマリ・データベースとスタンバイ・データベースのロールは、SWITCHOVERコマンドを使用して切り替えることができます。SWITCHOVERコマンドを発行する前に、次のことを確認する必要があります。

- プライマリ・データベースとスタンバイ・データベースの状態がそれぞれTRANSPORT-ONおよびAPPLY-ONであること。

- 関係するすべてのデータベースが健全な状態で、エラーや警告がないこと。

- スタンバイ・データベースのプロパティがプライマリ・データベース上で設定されていること。これにより、プライマリ・データベースはスタンバイ・データベースへ遷移するときに正常に機能できます(次の例の太字表記を参照してください)。

- プライマリ・データベース上でスタンバイREDOログ・ファイルが設定されていること。さらに、最大可用性モードまたは最大保護モードのいずれかで動作している場合、データベース・プロパティLogXptModeがSYNCに設定されていること。

- ファスト・スタート・フェイルオーバーが有効化されている場合は、ターゲット・スタンバイ・データベースとして指定されたスタンバイ・データベースへのスイッチオーバーのみ実行できる。

手順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                      = 'sync'
DelayMins                       = '0'
Binding                         = 'optional'
MaxFailure                      = '0'
MaxConnections                  = '1'
ReopenSecs                      = '300'
NetTimeout                      = '30'
RedoCompression                 = 'DISABLE'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/bt, dbs/t'
LogFileNameConvert              = 'dbs/bt, dbs/t'
FastStartFailoverTarget         = 'South_Sales'
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
SidName                         = 'north_sales1'
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'
LatestLog                       = '(monitor)'
TopWaitEvents                   = '(monitor)'

Database Status:
SUCCESS

DGMGRL>

特に、プライマリ・データベースの太字のプロパティおよび現在のステータスをチェックする必要があります。データベースの管理方法については、第4章を参照してください。

手順2   スイッチオーバーのターゲットとなるスタンバイ・データベースのチェック

SHOW DATABASE VERBOSEコマンドを使用して、スイッチオーバーのターゲットとなるスタンバイ・データベースの状態、健全性およびプロパティをチェックします。次に例を示します。

DGMGRL> SHOW DATABASE VERBOSE 'South_Sales';

Database - South_Sales

Role:            PHYSICAL STANDBY
Intended State:  ONLINE
Transport Lag:   0
Apply Lag:       0
Real Time Query: OFF
Instance(s):
south_sales1
Properties:
DGConnectIdentifier             = 'South_Sales.example.com'
ObserverConnectIdentifier       = ''
LogXptMode                      = 'ASYNC'
DelayMins                       = '0'
Binding                         = 'optional'
MaxFailure                      = '0'
MaxConnections                  = '1'
ReopenSecs                      = '300'
NetTimeout                      = '30'
RedoCompression                 = 'DISABLE'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/t, dbs/bt'
LogFileNameConvert              = 'dbs/t, dbs/bt'
FastStartFailoverTarget         = 'North_Sales'
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
SidName                         = 'south_sales1'
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                = 'db2r_%d_%t_%s_%R.arc'
LatestLog                       = '(monitor)'
TopWaitEvents                   = '(monitor)'

Database Status:
SUCCESS

特に、データベースの現在のステータスをチェックする必要があります。

手順3   スイッチオーバー・コマンドの発行

SWITCHOVERコマンドを発行して、プライマリ・データベースとスタンバイ・データベースのロールを交換します。次の例では、ブローカが、元のプライマリ・データベースの停止および再起動を、スイッチオーバーの一部として自動的に実行する方法を示します。(DGMGRLによってプライマリ・データベースとスタンバイ・データベースが自動的に再起動されるようにブローカ環境を設定する方法については、7.1.3項を参照してください。)

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"

スイッチオーバーの完了後、SHOW CONFIGURATIONおよびSHOW DATABASEコマンドを使用して、スイッチオーバー操作が正常終了したかどうかを検証します。

手順4   構成の表示

SHOW CONFIGURATIONコマンドを発行し、スイッチオーバーが正常終了したことを確認します。

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

6.9 使用例8: 手動フェイルオーバー操作の実行

フェイルオーバー操作は、緊急時(通常はプライマリ・データベースにアクセスできない場合または使用できない場合)の対応策として起動します。フェイルオーバー前に5.2項を参照し、どのスタンバイ・データベースをフェイルオーバーのターゲットにするかを判断してください。次の使用例では、リモート・データベースSouth_Salesへのフェイルオーバーについて説明します。

注意:
ファスト・スタート・フェイルオーバーが有効化されている場合、ファスト・スタート・フェイルオーバーのターゲットとして指定されているスタンバイ・データベースにかぎり、またオブザーバが実行中で現在スタンバイ・データベースと接続されている場合のみ、手動フェイルオーバーを実行できます。
ファスト・スタート・フェイルオーバーのターゲットではないスタンバイ・データベースへの手動フェイルオーバーを実行する場合は、まずフェイルオーバー先のスタンバイ・データベースでFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にする必要があります。FORCEオプションの詳細は、5.5.5項「ファスト・スタート・フェイルオーバーの無効化」を参照してください。

手順1   ターゲット・スタンバイ・データベースへの接続

フェイルオーバー操作を実行するには、SYSDBA権限を持つユーザーとしてフェイルオーバー先のスタンバイ・データベースに接続する必要があります。次に例を示します。

DGMGRL> CONNECT sys@South_Sales.example.com;
Password: password
Connected.

手順2   フェイルオーバー・コマンドの発行

フェイルオーバー・コマンドを発行すると、ターゲットのスタンバイ・データベースを構成の新しいプライマリ・データベースにできます。

DGMGRL> FAILOVER TO 'South_Sales';
Performing failover NOW, please wait...
Failover succeeded, new primary is "South_Sales"

フェイルオーバーの完了後は、5.4.3項の説明に従って回復または再作成しないかぎり、元のプライマリ・データベースは新しいプライマリ・データベースのスタンバイ・データベースとして使用できないことに注意してください。

手順3   構成の表示

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コマンドにより、有効なフィジカル・スタンバイ・データベースがないために警告が発生したことがわかります。その結果、警告ステータスは、構成の保護レベルと構成済のモードが同じでないことを示しています。

手順4   新しいプライマリ・データベースの表示

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

手順5   元のプライマリ・データベースの表示

SHOW DATABASEコマンドを発行し、フェイルオーバーの結果として(障害が発生した)元のプライマリ・データベースがブローカにより無効化されたことを確認します。元のプライマリ・データベースは、5.4.3項の説明に従って再作成する必要があります。

DGMGRL> SHOW DATABASE 'North_Sales';
Database - North_Sales

Role:            PHYSICAL STANDBY
Intended State:  APPLY-ON
Transport Lag:   (unknown)
Apply Lag:       (unknown)
Real Time Query: OFF
Instance(s):
north_sales1

Database Status:
ORA-16661: the standby database needs to be reinstated

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

プライマリ・データベースがフラッシュバック・データベースを使用して構成されている場合は、障害が発生したプライマリ・データベースを新しいプライマリ・データベースのスタンバイ・データベースとしてすぐに回復できます。障害が発生したプライマリ・データベースは、元のスタンバイ・データベースと同じスタンバイ・タイプとして回復します。たとえば、フィジカル・スタンバイ・データベースへのフェイルオーバーであった場合、元のプライマリはフィジカル・スタンバイ・データベースとして回復されます。

障害が発生したプライマリ・データベースを回復するには、データベースを起動してマウントされた状態にします。次に、DGMGRLを実行し、新しいプライマリ・データベースに接続して元のプライマリ・データベースを回復します。

手順1   元のプライマリ・データベースの再起動

% sqlplus sys as sysdba
Enter password: password

SQL> STARTUP MOUNT;
ORACLE instance started.

Total System Global Area  234364928 bytes
Fixed Size                  1296352 bytes
Variable Size             209717280 bytes
Database Buffers           16777216 bytes
Redo Buffers                6574080 bytes
Database mounted.

手順2   元のプライマリ・データベースの回復

% dgmgrl connect sys
Password: password
Connected.
DGMGRL> REINSTATE DATABASE 'North_Sales';
Reinstating database "North_Sales", please wait...
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.
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
Apply Lag:       0 seconds
Real Time Query: OFF
Instance(s):
north_sales1

Database Status:
SUCCESS

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

スナップショット・スタンバイ・データベースに変換するフィジカル・スタンバイ・データベースがある場合は、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" ...
Operation requires shutdown of instance "south_sales1" on database "South_Sales"
Shutting down instance "south_sales1"...
ORA-01109: database not open
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.
Database "South_Sales" converted successfully

6.12 使用例11: Data Guard構成の監視

この項の使用例は、SHOWコマンドとデータベースの監視可能なプロパティを使用し、障害状況を識別して解決する方法を示しています。

手順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

手順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

手順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のリスナーを起動します。

手順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)ともData Guard Brokerのプロパティ値(255)とも異なっています。データベース・メモリー値が正しいと判断した場合は、次のコマンドを使用してData Guard Brokerのプロパティ値を更新できます。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogArchiveTrace'=511;
Property "LogArchiveTrace" updated

このコマンドを発行すると、LogArchiveTraceの値の一貫性が保たれるようにサーバー・パラメータ・ファイル(SPFILE)の値が更新されます。

手順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)は、Data Guard Brokerのプロパティ値(300)と一致しません。ブローカのプロパティ値が正しいと判断した場合は、次の例に示すように、スタンバイ・データベースのプロパティを同じ値で再編集して一貫性のある値にできます。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'ReopenSecs'=300;
Property "ReopenSecs" updated

スタンバイ・データベースを再び有効化するか、プライマリ・データベースの状態をTRANSPORT-ONにリセットして、非一貫性を解決することもできます。

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

Data Guardコマンドライン・インタフェース(DGMGRL)を使用すると、Data Guard Broker構成とそのデータベースを、コマンドラインから直接、あるいはバッチ・プログラムやスクリプトから管理できます。Data Guardコマンドライン・インタフェースは、Data Guard構成を管理するためのOracle Enterprise Managerの代替手段として使用できます。

この章では、Data Guardのコマンドライン・インタフェースの参照情報を示します。この章の内容は、次のとおりです。

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

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

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

DGMGRLを実行するには、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コマンド

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

- -silent
DGMGRLのコマンド・プロンプト(DGMGRL>)をデフォルトの表示デバイスに表示しません。このオプションは、コマンド出力をファイルまたは他の表示ツールに送る場合に役立ちます。

- <logon>は次のとおりです。

- username [@connect-identifier]
データベースに接続するには、usernameと、オプションでconnect-identifierを入力します。次に、パスワードの入力を求められます。connect-identifierは、完全指定の接続記述子またはOracleネーミング・メソッド(TNSなど)により解決される名前です。

警告:

DGMGRLの起動時にコマンドラインでパスワードを指定することには、安全上のリスクがあります。このリスクは、DGMGRLの起動時はパスワードを省略し、後で求められたときに入力するか、外部の認証方式を使用することで回避できます。

- オペレーティング・システム認証(リモート・データベースの再起動を除く)、Secure Sockets Layer(SSL)プロトコルまたはウォレットに格納されたデータベース資格証明を使用する場合は、'/'として接続できます。

- <command>は1つのコマンドです。
次に例を示します。

% dgmgrl sys/ "show database 'North_Sales'"

Password: パスワード

次の各項で、DGMGRL>コマンド・プロンプトから入力するコマンドの書式について説明します。

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

DGMGRLコマンドを使用すると、一度に1つのブローカ構成を作成およびメンテナンスできます。ブローカ構成は、1つのプライマリ・データベースと最大30個のスタンバイ・データベースで構成できます。

コマンドライン・インタフェースの起動後は、表7-1に示す任意のDGMGRLコマンドを入力できます。各コマンドとその関連パラメータの詳細は後述します。

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

コマンド

効果

ADD DATABASE

既存のブローカ構成に新しいスタンバイ・データベースのプロファイルを追加します。

CONNECT

指定のユーザー名を使用して指定のデータベースに接続します。

CONVERT DATABASE

指定されたデータベースをスナップショット・スタンバイ・データベースまたはフィジカル・スタンバイ・データベースに変換します。

CREATE CONFIGURATION

ブローカ構成を作成し、プライマリ・データベースのプロファイルを構成に追加します。

DISABLE CONFIGURATION

構成とそのすべてのデータベースがブローカによる管理対象から外れるように、構成のブローカ管理を無効化します。

DISABLE DATABASE

指定したスタンバイ・データベースのブローカ管理を無効化します。

DISABLE FAST_START FAILOVER

ファスト・スタート・フェイルオーバーを無効化します。

DISABLE FAST_START FAILOVER CONDITION

ユーザーによるファスト・スタート・フェイルオーバーの実行条件の削除を可能にします。

EDIT CONFIGURATION(プロパティ)

ブローカ構成のプロパティ値を変更します。

EDIT CONFIGURATION(保護モード)

ブローカ構成の現在の保護モード設定を変更します。

EDIT DATABASE(プロパティ)

指定したデータベースのプロパティ値を変更します。

EDIT DATABASE(名前の変更)

ブローカにより指定したデータベースの参照に使用される名前を変更します。

EDIT DATABASE(状態)

指定したデータベースの状態を変更します。

EDIT INSTANCE (AUTO PFILE)

指定したインスタンスの初期化パラメータ・ファイル名を設定します。

EDIT INSTANCE(プロパティ)

指定したインスタンスのプロパティ値を変更します。

ENABLE CONFIGURATION

ブローカ構成とそのすべてのデータベースのブローカ管理を有効化します。

ENABLE DATABASE

指定したデータベースのブローカ管理を有効化します。

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 INSTANCE

インスタンスに関する情報を、ブローカ構成の既存のデータベース・プロファイルから削除します。

SHOW CONFIGURATION

ブローカ構成に関する情報を表示します。

SHOW DATABASE

指定したデータベースに関する情報を表示します。

SHOW FAST_START FAILOVER

すべてのファスト・スタート・フェイルオーバー関連情報を表示します。

SHOW INSTANCE

指定したインスタンスに関する情報を表示します。

SHUTDOWN

現在実行中のOracleデータベースを停止します。

START OBSERVER

オブザーバを開始します。

STARTUP

データベースのマウントやオープンなど、SQL*Plusと同じオプションを指定してOracleインスタンスを起動します。

STOP OBSERVER

オブザーバを停止します。

SWITCHOVER

スイッチオーバー操作を実行します。現行のプライマリ・データベースがスタンバイ・データベースになり、指定したスタンバイ・データベースがプライマリ・データベースになります。

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

DGMGRLを使用するには、次の条件が満たされている必要があります。

- DG_BROKER_START動的初期化パラメータをTRUEに設定します。

- 手動操作なしでインスタンスを再起動する必要のあるブローカ操作を有効化するには、プライマリとスタンバイのデータベース・インスタンスを含む各ホスト上でOracle Net Servicesを構成する必要があります。特に、listener.oraファイルにインスタンスの静的構成情報が含まれていることが必要です。GLOBAL_DBNAME属性を、db_unique_name_DGMGRL.db_domainに設定する必要があります。詳細は、2.2項を参照してください。

- 構成の作成時またはデータベースの追加時に使用する接続識別子は、構成内のすべてのホストから解決可能である必要があります。

参照:
Oracle Data Guard Brokerの準備および起動の詳細は、第6章を参照してください。スタンバイ・データベースでのネットワーク・ファイルとリスナーの設定の詳細は、『Oracle Database管理者ガイド』を参照してください。

- Data Guardコマンドライン・インタフェースを使用するには、SYSDBA権限が必要です。SYSDBAはCONNECTコマンドのデフォルト設定であるため、このコマンドではAS SYSDBAを指定しないでください。

- コマンドで複数のオプションを指定する場合、指定する順序は問われません。

- 各DGMGRLコマンドの末尾にセミコロンを付ける必要があります。

- DGMGRLコマンド文字列の値で指定する文字は、二重引用符(")または一重引用符(')で囲まれていない場合、小文字として解釈されます。たとえば、databaseとDatAbaSeは同じですが、"database"と"DatAbaSe"は異なります。

- 一重引用符(')、二重引用符(")およびバックスラッシュ(\)が文字列に含まれている場合は、これらの文字のエスケープ文字としてバックスラッシュ(\)を使用できます。

- ブローカ構成では、1つ以上のデータベースのシャットダウンと再起動が必要となる操作がいくつかあります。次の条件を満たす場合はほとんど、特定のデータベースのシャットダウンと再起動がDGMGRLによって自動的に行われます。

- instance-nameがSID(これは、DGMGRLのみでなくEnterprise Managerにも適用されます)。

- ブローカは、最後のCONNECTコマンドが別のデータベースへの接続に使用された場合でも、最後のCONNECTコマンドに指定された資格証明を使用してデータベースに接続できる必要があります。

コマンドの例

例1

この例は、ローカル・システム上でDGMGRLコマンドライン・インタフェースに接続する方法を示しています。

% dgmgrl
.
.
.
Welcome to DGMGRL, type "help" for information.

DGMGRL> CONNECT sys;
Password: password
Connected.

例2

この例は、リモート・システム上でData Guard(DGMGRL)コマンドライン・インタフェースに接続する方法を示しています。

DGMGRL> CONNECT sys@remote-stby;
Password: password
Connected.

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

コマンドライン・インタフェースでの作業を完了し、オペレーティング・システムに戻るには、DGMGRLコマンド・プロンプトからEXITまたはQUITコマンドを入力します。次に例を示します。

DGMGRL> EXIT;

ADD DATABASE

新しいスタンバイ・データベースのプロファイルを作成して既存のブローカ構成に追加します。AS CONNECT IDENTIFIER句は、オプションです。この句を指定しなかった場合、ブローカはプライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータを検索して、追加するデータベースに対応するエントリを探します。

MAINTAINED AS句を使用して、スタンバイ・データベースのタイプを指定できます。この句を指定しなければ、スタンバイ・データベースのタイプがフィジカル、ロジカルまたはスナップショットであるかをブローカが自動的に判別します。

書式

ADD DATABASE database-name

[AS CONNECT IDENTIFIER IS connect-identifier]

コマンド・パラメータ

database-name

ブローカでこのスタンバイ・データベースを参照するために使用される名前。この名前は、対応するデータベースのDB_UNIQUE_NAME初期化パラメータの値と一致する(大/小文字は区別されません)必要があります。

connect-identifier

完全指定の接続記述子またはOracle Net Servicesのネーミング・メソッド(TNSなど)により解決される名前です。指定した値は、データベース・プロパティDGConnectIdentifierの初期値としても使用されます。このオプションを指定しない場合、ブローカがプライマリ・データベースのLOG_ARCHIVE_DEST_nパラメータを検索して、対応するスタンバイ・データベースのエントリを探し、そのSERVICE値を接続識別子として使用します。

使用上の注意

- このコマンドを発行するには、プライマリ・データベースまたは構成内にすでに存在する有効化されたスタンバイ・データベースに接続する必要があります。

- ブローカでは、指定したconnect-identifierが、他のデータベースから指定したデータベースへの通信に使用されます。したがって、構成内のすべてのデータベースから指定のデータベースへのアドレス指定に、connect-identifierを使用できることを確認する必要があります。たとえば、TNSをネーミング・メソッドとして使用する場合、構成内のすべてのデータベースとインスタンスのtnsnames.oraファイルにconnect-identifierのエントリが含まれることを確認する必要があります。接続識別子は同じ接続記述子に解決される必要があります。追加するデータベースがOracle RACデータベースである場合、Oracle RACのすべてのインスタンスにアクセスできる接続識別子を指定する必要があります。FAILOVER属性を設定することをお薦めします。

参照:
『Oracle Database Net Services管理者ガイド』

- 接続できない場合、ブローカでは新しいデータベースが構成に追加されません。

- MAINTAINED AS句は、このリリースで非推奨になりました。スタンバイ・データベースのタイプは、ブローカによって自動的に判別されます。

コマンドの例

例1

次の例に、データベースSouth_Salesを追加する方法を示します。

DGMGRL> ADD DATABASE South_Sales AS CONNECT IDENTIFIER IS South_Sales.example.com;
Database "South_Sales" added

CONNECT

指定したデータベースに特定のユーザー名で接続します。

書式

CONNECT username [@connect-identifier];

コマンド・パラメータ

username

データベースへの接続に使用するユーザー名。ユーザー名と、オプションでconnect-identifierを入力すると、パスワードの入力を求められます。

connect-identifier

このパラメータはオプションです。このパラメータは、接続先データベースのOracle Net Services接続識別子です。正確な構文は、Oracleのインストールで使用されるOracle Net Services通信プロトコルによって異なります。

使用上の注意

- 接続先データベースに有効なユーザー名とパスワードを指定する必要があります。指定するユーザー名には、SYSDBA権限が必要です。SYSDBAはCONNECTコマンドのデフォルト設定であるため、このコマンドでAS SYSDBAを指定する必要はありません。

- CONNECTコマンドでエラーが戻される場合は、有効なconnect-identifierを指定したことを確認してください。

コマンドの例

例1

この例では、ローカル・システム上のデフォルト・データベースに接続しています。

DGMGRL> CONNECT sys;
Password: password
Connected.

例2

この例では、connect-identifierがNorth_Sales.example.comのリモート・データベースに接続します。

DGMGRL> CONNECT sys@North_Sales.example.com;
Password: password
Connected.

例3

この例では、コマンドラインで接続資格証明を表示できないように、CONNECT '/'を使用してデータベースに接続しています。

DGMGRL> CONNECT /@North_Sales.example.com;

CONNECT '/'を使用するには、OracleウォレットまたはSSLを設定する必要があります。OracleウォレットまたはSSLを設定することで、スクリプトでデータベース資格証明を指定せずに、オブザーバをバックグラウンド・ジョブとして安全に起動および実行するためのスクリプトを記述できます。

参照:
OracleウォレットおよびSSLの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

CONVERT DATABASE

フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換するか、スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに戻します。

スナップショット・スタンバイ・データベースは完全に更新可能なスタンバイ・データベースです。フィジカルまたはロジカル・スタンバイ・データベースと同様に、スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信し、アーカイブします。フィジカルまたはロジカル・スタンバイ・データベースとは異なり、スナップショット・スタンバイ・データベースは、受信したREDOデータを適用しません。スナップショット・スタンバイ・データベースが受信したREDOデータは、スナップショット・スタンバイが元のフィジカル・スタンバイ・データベースに変換され、スナップショット・スタンバイ・データベースに対するすべてのローカルな更新が破棄された後に適用されます。

スナップショット・スタンバイ・データベースの最適な使用例は、更新可能なフィジカル・スタンバイ・データベースのスナップショットが一時的に必要な場合です。スナップショット・スタンバイ・データベースでは、フィジカル・スタンバイに戻るまで受信したREDOデータが適用されないため、ロール遷移の実行に要する時間は、適用する必要があるREDOデータの量に正比例します。

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

書式

CONVERT DATABASE db_unique_name TO {SNAPSHOT | PHYSICAL} STANDBY;

使用上の注意

- ファスト・スタート・フェイルオーバーのターゲットである場合、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換できません。「ORA-16668: ファスト・スタート・フェイルオーバー・ターゲットのスタンバイ・データベースでは操作を実行できません」というエラーが表示されます。

- DGMGRL ADD DATABASEコマンドを使用して、既存のスナップショット・スタンバイ・データベースを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" ...
Operation requires shutdown of instance "south_sales1" on database "South_Sales"
Shutting down instance "south_sales1"...
ORA-01109: database not open

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.
Database "South_Sales" converted successfully

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の初期値としても使用されます。このオプションを指定しない場合、ブローカがプライマリ・データベースのLOG_ARCHIVE_DEST_nパラメータを検索して、対応するスタンバイ・データベースのエントリを探し、そのSERVICE値を接続識別子として使用します。

使用上の注意

- ブローカ構成は、グループとして管理する必要のある1つ以上のデータベースの名前付きコレクションです。各コマンド・パラメータの値を指定する必要があります。デフォルト値はありません。

- このコマンドを発行するには、プライマリ・データベースに接続する必要があります。

- ブローカでは、指定したconnect-identifierが、他のデータベースから指定したデータベースへの通信に使用されます。したがって、構成内のすべてのデータベースから指定のデータベースへのアドレス指定に、connect-identifierを使用できることを確認する必要があります。たとえば、TNSをネーミング・メソッドとして使用する場合、構成内のすべてのデータベースとインスタンスのtnsnames.oraファイルにconnect-identifierのエントリが含まれることを確認する必要があります。接続識別子は同じ接続記述子に解決される必要があります。追加するデータベースがOracle RACデータベースである場合、Oracle RACのすべてのインスタンスにアクセスできる接続識別子を指定する必要があります。FAILOVER属性を設定することをお薦めします。

参照:
『Oracle Database Net Services管理者ガイド』

- ブローカ構成の作成後にスタンバイ・データベースを追加するには、ADD DATABASEコマンドを使用します。

コマンドの例

例1

次の例では、プライマリ・データベース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"

DISABLE CONFIGURATION

構成とそのすべてのデータベースがブローカによる管理対象から外れるように、構成のブローカ管理を無効化します。

書式

DISABLE CONFIGURATION

コマンド・パラメータ

なし。

使用上の注意

- 無効化された構成およびそこに含まれるすべてのデータベースが、ブローカで管理されなくなります。

- プライマリ・データベースのブローカ管理を無効にするには、DISABLE CONFIGURATIONコマンドを使用する必要があります。

- このコマンドは、構成ファイルからブローカ構成を削除しません。構成を削除する方法の詳細は、REMOVE CONFIGURATIONコマンドを参照してください。

- 構成が無効になっている間、データベース・プロパティを編集したり構成の保護モードを変更できます。ただし、プロパティや保護モードの変更結果は、構成が有効化されるまで有効になりません。

- このコマンドは、ファスト・スタート・フェイルオーバーが有効になっている場合は実行できません。

コマンドの例

例1

次の例では、ブローカ構成およびそのすべてのデータベースの管理を無効化しています。

DGMGRL> DISABLE CONFIGURATION;
Disabled.

DISABLE DATABASE

指定したスタンバイ・データベースのブローカ管理を無効化します。つまり、ブローカではこのデータベースの状態を変更できなくなり、ブローカはデータベースの健全性ステータスや監視可能なデータベース・プロパティを監視しません。

書式

DISABLE DATABASE database-name;

コマンド・パラメータ

database-name

無効化するスタンバイ・データベースの名前。

使用上の注意

- プライマリ・データベース名は指定できません。

- プライマリ・データベースとすべてのスタンバイ・データベースを無効化するには、DISABLE CONFIGURATIONコマンドを使用します。

- スタンバイ・データベースを1つのみ無効化する場合、フェイルオーバー・オプションを使用できません。このスタンバイ・データベースは、再び有効化するまでは実行できなくなります。

- ファスト・スタート・フェイルオーバーが有効化されているとき、このコマンドを使用してファスト・スタート・フェイルオーバーのターゲット・データベースを無効にすることはできません。

コマンドの例

例1

次の例に、データベースSouth_Salesを無効化する方法を示します。

DGMGRL> DISABLE DATABASE 'South_Sales';
Disabled.

DISABLE FAST_START FAILOVER

ファスト・スタート・フェイルオーバーを無効化し、オブザーバによりターゲット・スタンバイ・データベースへのフェイルオーバーが開始されないようにします。詳細は、5.5.5項「ファスト・スタート・フェイルオーバーの無効化」を参照してください。

書式

DISABLE FAST_START FAILOVER [ FORCE ];

コマンド・パラメータ

なし。

使用上の注意

- プライマリ・データベースとターゲット・スタンバイ・データベースにネットワーク接続がある場合、ブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーを無効化するには、FORCEオプションを指定せずにDISABLE FAST_START FAILOVERを使用します。無効化操作中にエラーが発生した場合、ブローカによりエラー・メッセージが戻され、無効化操作が停止されます。エラー状態をオーバーライドし、接続先データベースのファスト・スタート・フェイルオーバーを無効化するには、FORCEオプションを指定してDISABLE FAST_START FAILOVERコマンドを再発行する必要があります。詳細は、5.5.5項「ファスト・スタート・フェイルオーバーの無効化」を参照してください。

- プライマリ・データベースとターゲット・スタンバイ・データベース間のネットワークが切断されている場合、またはコマンドを受信するデータベースに、プライマリ・データベースとの接続がない場合には、FORCEオプションを指定してDISABLE FAST_START FAILOVERを使用します。FORCEオプションは、エラー発生時でも、接続先データベースのファスト・スタート・フェイルオーバーを無効化します。

- オブザーバおよびターゲットのスタンバイ・データベースから切断されたプライマリ・データベース上でFORCEオプションを指定してファスト・スタート・フェイルオーバーを無効化しても、オブザーバによる、ターゲットのスタンバイ・データベースへのファスト・スタート・フェイルオーバーの開始を無効にはできません。

- ブローカ構成のいずれかのデータベースに接続している場合、そのデータベースとプライマリ間が接続されていれば、ファスト・スタート・フェイルオーバーを無効化できます。

- ターゲットのスタンバイ・データベース上で強制オプション付きで無効化され、その後プライマリ・データベースとの接続が再開された場合、ファスト・スタート・フェイルオーバーは、構成内のすべてのデータベースで無効化されています。

- プライマリ・データベースとターゲット・スタンバイ・データベースがネットワークで接続されている場合、プライマリに接続しているときにFORCEオプションを指定してファスト・スタート・フェイルオーバーを無効化すると、ターゲット・スタンバイ・データベースのファスト・スタート・フェイルオーバーが無効になります。

コマンドの例

例1

次の例に、ファスト・スタート・フェイルオーバーを無効化する方法を示します。

DGMGRL> DISABLE FAST_START FAILOVER;
Disabled.

DISABLE FAST_START FAILOVER CONDITION

ユーザーによるファスト・スタート・フェイルオーバーの実行条件の削除を可能にします。

書式

DISABLE FAST_START FAILOVER CONDITION value;

コマンド・パラメータ

value

可能な値は、SHOW FAST_START FAILOVERコマンドで健全性条件またはOracleエラー番号として示される値です。

使用上の注意

条件が認識されないか設定されていないとエラーが発生します。

コマンドの例

例1

DISABLE FAST_START FAILOVER CONDITION "Corrupted Controlfile";

破損した制御ファイルが検出されてもすぐに自動的にファスト・スタート・フェイルオーバーが開始されないように指定します。

例2

DISABLE FAST_START FAILOVER CONDITION 27102;

ORA-27102エラーによってすぐに自動的にファスト・スタート・フェイルオーバーが開始されないように指定します。

EDIT CONFIGURATION(プロパティ)

ブローカ構成のプロパティ値を変更します。

書式

EDIT CONFIGURATION SET PROPERTY property-name = value;

コマンド・パラメータ

property-name

構成プロパティの名前

value

新しいプロパティ値。

参照:
構成プロパティの詳細は、第4章および第8章を参照してください。

使用上の注意

- プライマリ・データベースに、またはそのプライマリ・データベースと接続された構成内の任意のスタンバイ・データベースに接続されている場合に、このコマンドを発行します。

- 構成の現在のプロパティ情報を表示するには、SHOW CONFIGURATIONコマンドを使用します。

コマンドの例

例1

次の例に、FastStartFailoverThreshold構成プロパティを90秒に設定する方法を示します。

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold=90;

EDIT CONFIGURATION(保護モード)

ブローカ構成の現在の保護モード設定を編集します。

書式

EDIT CONFIGURATION SET PROTECTION MODE ASprotection-mode;

コマンド・パラメータ

protection-mode

構成が有効な場合に、その構成で実行するデータ保護モード。可能な保護モードは次のとおりです。

MAXPROTECTION
MAXAVAILABILITY
MAXPERFORMANCE

使用上の注意

- EDIT CONFIGURATIONコマンドを使用して保護モードをMAXPROTECTIONモードまたはMAXAVAILABILITYモードに設定する前に、1つ以上のスタンバイ・データベースでデータベース・プロパティLogXptModeがSYNCに設定されていることを確認してください。

- 次の表は、構成の保護モードと、REDO転送サービスの対応する最低限の設定を示しています。

保護モード

REDO転送

スタンバイREDOログ・ファイルの要否

ファスト・スタート・フェイルオーバーとの併用

MAXPROTECTION

SYNC

必要

いいえ

MAXAVAILABILITY

SYNC

必要

はい

MAXPERFORMANCE

ASYNC

必要

はい

構成のデフォルトの保護モードはMAXPERFORMANCEです。

参照:
保護モードとREDO転送サービスの詳細は、第4章を参照してください。

- ファスト・スタート・フェイルオーバーを有効化するには、MAXAVAILABILITYまたはMAXPERFORMANCEが必要です。

- このコマンドは、ファスト・スタート・フェイルオーバーが有効になっている場合は実行できません。

- 保護モードの変更後、必要な場合はブローカによりプライマリ・データベースが自動的に再起動されます。

- 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コマンドを使用して構成を有効化するまで有効にはなりません。

コマンドの例

例1

次の例は、ブローカ構成を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.

EDIT DATABASE(プロパティ)

指定したデータベースのプロパティ値を変更します。

書式

EDIT DATABASE database-name

SET PROPERTY property-name value;

コマンド・パラメータ

database-name

プロパティ値を変更するデータベースの名前。

property-name

データベース固有の既存のプロパティの名前。これがOracle RACデータベースの場合、このプロパティを変更するとデータベースのインスタンスすべてに影響します。

参照:
プロパティの情報については、第4章および第8章を参照してください。

value

新しいプロパティ値。

注意:
このコマンドを使用してインスタンス固有のプロパティの値を変更できるのは、指定したデータベースに関してブローカでインスタンスが1つしか認識されていない場合のみです。ブローカでデータベースのインスタンスが複数認識されている場合は、このコマンドを使用してインスタンス固有のプロパティを変更しようとしても拒否されます。インスタンス固有のプロパティの値の変更には、EDIT INSTANCE(プロパティ)のみを使用することをお薦めします。

コマンドの例

例1

データベース・レベルの構成可能なデータベース固有のプロパティを編集します。

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

例2

非Oracle RACデータベースの構成可能なインスタンス固有のプロパティを編集します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY
> 'StandbyArchiveLocation'='/archfs/arch/';
Property "StandbyArchiveLocation" updated

例3

Oracle RACデータベースの構成可能なインスタンス固有のプロパティを編集します。プロパティの変更が適用されるインスタンスが明らかでないため、このコマンドは失敗します。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY
> 'StandbyArchiveLocation'='/archfs/arch/';
Error: ORA-16587: ambiguous object specified to Data Guard broker

Failed.

EDIT DATABASE(名前の変更)

指定されたデータベースを参照するためにブローカが使用する、ブローカ構成内のそのデータベースのプロファイルに記録されている名前を変更します。

書式

EDIT DATABASE database-name

RENAME TO new-database-name;

コマンド・パラメータ

database-name

変更するデータベース名。

new-database-name

新しいデータベース名。

使用上の注意

- このコマンドを使用して、このデータベースのDB_UNIQUE_NAME初期化パラメータの変更を追跡します。

注意:
database-nameは、そのデータベースのDB_UNIQUE_NAME初期化パラメータの値と常に一致する必要があります。

- このコマンドを実行できるのは、名前を変更するデータベースのブローカ管理が無効化されている場合のみです。

コマンドの例

例1

次の例に、データベースを編集して名前を変更する方法を示します。

DGMGRL> DISABLE DATABASE 'South_Sales_typo';
Disabled.

DGMGRL> EDIT DATABASE 'South_Sales_typo' RENAME TO 'South_Sales';
Succeeded.

DGMGRL> ENABLE DATABASE 'South_Sales';
Enabled.

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データベースのすべてのインスタンスに影響します。

コマンドの例

次の各例に、データベースの状態を変更する方法を示します。

例1

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

EDIT INSTANCE (AUTO PFILE)

指定したインスタンスの初期化パラメータ・ファイル名を設定します。

書式

EDIT DATABASE 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を再指定する必要があります。

コマンドの例

例1

次の例に、データベースのインスタンスの起動に使用するパラメータ・ファイルを変更する方法を示します。

DGMGRL> EDIT INSTANCE 'south_sales1' ON DATABASE 'South_Sales'
> SET AUTO PFILE='initsales1.ora';
Instance 'south_sales1' updated

EDIT INSTANCE(プロパティ)

指定したインスタンスのインスタンス固有のプロパティ値を変更します。

書式

EDIT INSTANCE { {instance-name [ON DATABASE database-name] } | {* ON DATABASE database-name} }

SET PROPERTY property-name = value;

コマンド・パラメータ

instance-name

インスタンス固有のプロパティ値を変更するインスタンスの名前(SID)。インスタンス名にアスタリスクが付いている場合、ON DATABASE句も指定し、この変更をそのデータベースに関連する各インスタンスの指定プロパティに適用する必要があります。EDIT INSTANCE * ON DATABASE database-nameコマンドを使用して変更可能なインスタンス固有のプロパティについては、第8章を参照してください。

database-name

instance-nameが関連付けられているデータベースの名前。instance-nameにアスタリスクが付けられている場合、または構成内でinstance-nameが一意でない場合は、このパラメータを指定する必要があります。

property-name

新しい値を設定するインスタンス固有のプロパティの名前。

参照:
プロパティの情報については、第4章および第8章を参照してください。

value

新しいプロパティ値。

使用上の注意

- instance-nameには、構成全体で一意の名前を指定できます。instance-nameが一意ではない場合、database-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データベースのすべてのインスタンスのインスタンス固有のプロパティを変更します。

DGMGRL> EDIT INSTANCE * ON DATABASE 'North_Sales' LogArchiveTrace=4095;

ENABLE CONFIGURATION

すべてのデータベースを含むブローカ構成をブローカでアクティブに管理できるようにします。

書式

ENABLE CONFIGURATION

コマンド・パラメータ

なし。

使用上の注意

- このコマンドを使用すると、プライマリ・データベースとすべてのスタンバイ・データベース(スタンバイ・データベースがユーザーによって明示的に無効化されていない場合)をブローカで管理できるようになります。

- このコマンドを発行するには、プライマリ・データベースに接続する必要があります。

- デフォルトでは、構成のデータベースのブローカ管理は、プライマリ・データベースではTRANSPORT-ON状態で有効化され、REDO転送サービスがオンになり、スタンバイ・データベースではAPPLY-ON状態で有効化され、ログ適用サービスが起動します。EDIT DATABASE(状態)コマンドを使用して任意のデータベースの状態を変更できますが、対象のデータベースまたは構成全体が無効になっている場合は変更できません。

- 構成に関する情報を表示するには、SHOW CONFIGURATIONコマンドを使用します。

コマンドの例

例1

次の例では、ブローカ構成の管理を有効化しています。

DGMGRL> ENABLE CONFIGURATION;
Enabled.

ENABLE DATABASE

指定したスタンバイ・データベースのブローカ管理を有効化します。

注意:
回復する必要があるスタンバイ・データベースでENABLE DATABASEコマンドを発行しないでください。詳細は、5.4.3項を参照してください。

書式

ENABLE DATABASE database-name;

コマンド・パラメータ

database-name

ブローカ管理を有効化するスタンバイ・データベースの名前。

使用上の注意

- このコマンドを発行するには、プライマリ・データベースまたはすでに有効化されたスタンバイ・データベースに接続する必要があります。

- 前のフェイルオーバー操作またはスイッチオーバー操作の結果、ブローカによりスタンバイ・データベースが無効化されている場合があります。データベースを回復または再作成する方法は、5.4.3項を参照してください。

- デフォルトでは、フィジカルまたはロジカル・スタンバイ・データベースのブローカ管理はAPPLY-ON状態で有効化され、ログ適用サービスが有効化されます。データベースが有効になっている場合にのみ、EDIT DATABASE(状態)コマンドを使用してスタンバイ・データベースの状態を変更できます。

- 構成に関する情報を表示するには、SHOW DATABASEコマンドを使用します。

- Oracle RACデータベースの場合は、インスタンスを1つ起動してマウントすれば、このコマンドが正常に実行されます。

コマンドの例

例1

次の例に、データベースSouth_Salesを有効化する方法を示します。

DGMGRL> ENABLE DATABASE 'South_Sales';
Enabled.

ENABLE FAST_START FAILOVER

プライマリ・データベースが消失した場合、ブローカによる、具体的に選択されたスタンバイ・データベースへのフェイルオーバーが可能になり、フェイルオーバーを起動するために手動による手順を実行する必要がありません。詳細は、5.5.2項「ファスト・スタート・フェイルオーバーの有効化」を参照してください。

書式

ENABLE FAST_START FAILOVER;

コマンド・パラメータ

なし。

使用上の注意

- このコマンドを発行してファスト・スタート・フェイルオーバーを有効化する前に、5.5.1項で説明する前提条件を満たす必要があります。

- 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ログが構成されていること

- データベース・プロパティLogXptModeがSYNCに設定され、保護モードがMAXAVAILABILITYに設定されているか、LogXptModeプロパティがASYNCに設定され、保護モードがMAXPERFORMANCEに設定されていること

- プライマリ・データベースとスタンバイ・データベースの両方で「データベースをフラッシュバック」が有効化されていること

FastStartFailoverTarget構成プロパティの詳細は、5.5.2項の手順2、および8.3.10項を参照してください。

- ファスト・スタート・フェイルオーバーを有効化した後は、5.5.2.2項「ファスト・スタート・フェイルオーバーが有効化されている場合の制限事項」の説明にある制約に従う必要があります。

コマンドの例

例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

Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile          YES
Corrupted Dictionary           YES
Inaccessible Logfile            NO
Stuck Archiver                  NO
Datafile Offline               YES

Oracle Error Conditions:
(none)

ENABLE FAST_START FAILOVER CONDITION

ファスト・スタート・フェイルオーバーを実行する追加条件を指定します。

書式

ENABLE FAST_START FAILOVER CONDITION value;

コマンド・パラメータ

value

可能な値は、SHOW FAST_START FAILOVERコマンドで健全性条件またはOracleエラー番号として示される値です。

使用上の注意

- 可能な値は、データベース健全性チェック機能によって保持されるセットまたはいずれかのORA-xxxxエラーに対応する番号です。

- 健全性チェック機能によって保持される条件は将来変更される場合がありますが、いくつかの一般的な例が表7-2に示されています。

表7-2 健全性条件の例

健全性条件

説明

データファイル・オフライン

書込みエラーによってデータファイルがオフラインになりました。

破損した制御ファイル

制御ファイルが破損しました。

破損したディクショナリ

重要なデータベース・オブジェクトのディクショナリが破損しました。

アクセス不可能なログ・ファイル

I/Oエラーにより、LGWRがログ・グループのどのメンバーにも書き込むことができません。

スタック・アーカイバ

デバイスに空き容量がないかデバイスを使用できないためにアーカイバがREDOログをアーカイブできません。

Oracleエラー番号(例: 27102)

エラー番号が発生すると、ファスト・スタート・フェイルオーバーが実行されます。

デフォルトでは、「データファイル・オフライン」、「破損した制御ファイル」、「破損したディクショナリ」が有効になっています。

- SHOW FAST_START FAILOVERコマンドでこれらの構成可能な条件を表示できます。

コマンドの例

例1

ENABLE FAST_START FAILOVER CONDITION "Corrupted Controlfile";

破損した制御ファイルが検出された場合、ファスト・スタート・フェイルオーバーを実行するように指定します。

例2

ENABLE FAST_START FAILOVER CONDITION 27102;

ORA-27102エラーが発生した場合、ファスト・スタート・フェイルオーバーを実行するように指定します。

EXIT

コマンドライン・インタフェースを終了します。

書式

EXIT;

コマンド・パラメータ

なし。

使用上の注意

- このコマンドの効果は、QUITコマンドと同じです。

- このコマンドの実行には、データベース接続は不要です。ただし、接続されている場合は、このコマンドにより接続が解除されます。

コマンドの例

例1

次の例に、コマンドライン・インタフェースを終了する方法を示します。

DGMGRL> EXIT;

FAILOVER

指定したターゲットのスタンバイ・データベースをプライマリ・データベースのロールに遷移するフェイルオーバーを開始します。このタイプのフェイルオーバーは、手動フェイルオーバーと呼びます。詳細は、5.4項「手動フェイルオーバー」を参照してください。

注意:
フェイルオーバーを実行すると、スタンバイ・データベースがプライマリ・データベースのロールに遷移するため、フェイルオーバーは、プライマリ・データベースに障害が発生するか使用不可になり、適時にリカバリできない場合に実行してください。フェイルオーバーの結果、実行時に有効になっている保護モード、およびターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていたかどうかによっては、データが消失する場合があります。
プライマリ・データベースに障害がなく、データの消失なしに現在のプライマリ・データベースとスタンバイ・データベースのロールを切り替えるには、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ログ・ファイルが構成されている場合でも、アプリケーション・データが消失する可能性があります。また、構成内の他のスタンバイ・データベースは、回復または再作成されるまで機能しません。詳細は、5.4.3項を参照してください。

- 手動フェイルオーバーを実行するか、ブローカをファスト・スタート・フェイルオーバーを実行するように設定できます。フェイルオーバーの条件が満たされた場合に、ブローカにより自動的にフェイルオーバーを起動させる方法については、ENABLE FAST_START FAILOVERコマンドを参照してください。

- ファスト・スタート・フェイルオーバーが有効になっている場合は、完全手動フェイルオーバーを、ファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースに対してのみ、そのスタンバイ・データベースがプライマリ・データベースと同期化されているかプライマリ・データベースのラグ制限内である場合にのみ、およびオブザーバーが開始されている場合にのみ実行できます。ファスト・スタート・フェイルオーバーが有効になっている場合に、即時手動フェイルオーバーは実行できません。

- 障害が発生した元のプライマリ・データベース上で、フェイルオーバーの前に「データベースをフラッシュバック」が有効化されていた場合は、ブローカのREINSTATEコマンド(REINSTATE DATABASEコマンドを参照)を使用して、そのプライマリ・データベースを回復できます。
フィジカル・スタンバイ・データベースに対してフェイルオーバーが実行された場合は、そのスタンバイ・データベースで「データベースをフラッシュバック」が有効化されていて、使用可能なフラッシュバック・ログ情報が不足なくある場合にのみ、そのフェイルオーバーにより無効化されたその他のフィジカル・スタンバイ・データベースも回復できます。手順については、5.4.3項「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

- 元のプライマリ・データベースは、回復または再作成後、スタンバイ・データベースとしてのみ構成に関係できます。

注意:
フェイルオーバー前にまだアクティブなインスタンスが実行されている場合は、元のプライマリ・データベースを停止してください。

参照:
プライマリ・データベースのスタンバイ・データベースとして機能するように、元のプライマリ・データベースを再有効化する方法については、5.4.3項を参照してください。

コマンドの例

例1

次の例では、スタンバイ・データベース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

HELP

Data Guardコマンドライン・インタフェースのオンライン・ヘルプを表示します。

書式

HELP [topic];

コマンド・パラメータ

topic

ヘルプ情報を表示するトピック。トピックを指定しない場合、すべてのトピックおよび書式が表示されます。有効なトピックは、次のとおりです。

ADD
CONNECT
CONVERT
CREATE
DISABLE
EDIT
ENABLE
EXIT
FAILOVER
HELP
QUIT
REINSTATE
REM
REMOVE
SHOW
SHUTDOWN
START
STARTUP
STOP
SWITCHOVER

使用上の注意

- このコマンドの実行には、データベース接続は不要です。

コマンドの例

例1

次の例では、EDITコマンドのヘルプを取得しています。

DGMGRL> HELP EDIT;

Edits a configuration, database, or instance

Syntax:

EDIT CONFIGURATION SET PROTECTION MODE AS
{MaxProtection|MaxAvailability|MaxPerformance};

EDIT CONFIGURATION SET PROPERTY <property name> = <value>;

EDIT DATABASE <database name> SET PROPERTY <property name> = <value>;

EDIT DATABASE <database name> RENAME TO <new database name>;

EDIT DATABASE <database name> SET STATE = <state>
[WITH APPLY INSTANCE = <instance name>];

EDIT INSTANCE <instance name> [ON DATABASE <database name>]
SET AUTO PFILE [ = {<initialization file path>|OFF} ];

EDIT INSTANCE <instance name> [ON DATABASE <database name>]
SET PROPERTY <property name> = <value>;

EDIT INSTANCE * ON DATABASE <database name>
SET PROPERTY <property name> = <value>;

QUIT

Data Guardコマンドライン・インタフェースを終了します。

書式

QUIT

コマンド・パラメータ

なし。

使用上の注意

- このコマンドの効果は、EXITコマンドと同じです。

- このコマンドの実行には、データベース接続は不要です。ただし、接続されている場合は、このコマンドにより接続が解除されます。

コマンドの例

例1

次の例に、コマンドライン・インタフェースを終了する方法を示します。

DGMGRL> QUIT;

REINSTATE DATABASE

ブローカ構成内で、データベースを現在のプライマリ・データベースの新規スタンバイ・データベースとして回復します。

書式

REINSTATE DATABASE database-name;

コマンド・パラメータ

database-name

ブローカ構成内の回復するデータベースの名前

使用上の注意

- 5.5.8項で説明する回復の条件が満たされていない場合、回復処理は失敗し、対応するエラー・ステータスが表示され、指定されたデータベースは無効なままになります。

- database-nameに、元のプライマリの名前が指定され、ファスト・スタート・フェイルオーバーが有効化されている場合、元のプライマリ・データベースは、新規プライマリ・データベースのスタンバイとして回復し、ファスト・スタート・フェイルオーバー環境は、新規スタンバイ・データベースの可用性を反映して更新されます。新規スタンバイ・データベースは、新規プライマリ・データベースに障害が発生した場合、新規プライマリ・データベースからREDOデータを受け取り、ファスト・スタート・フェイルオーバーのターゲットとなります。FastStartFailoverAutoReinstate構成プロパティがFALSEに設定されている場合を除き、オブザーバが実行中であれば自動的に回復が実行されます。

- このコマンドでは、ファスト・スタート・フェイルオーバーが有効化されている必要はありません。このコマンドは、完全手動フェイルオーバーが実行された後、元のプライマリ・データベースを回復する場合に使用できます。完全または即時フェイルオーバー後に無効化されたその他のスタンバイ・データベースを回復するために使用することもできます。

- このコマンドは、ブローカ構成内で回復させるデータベース以外のデータベースに接続されている場合に発行します。

コマンドの例

例1

次の例に、South_Salesデータベースを、ブローカ構成のスタンバイ・データベースとして回復させる方法を示します。

DGMGRL> REINSTATE DATABASE 'North_Sales';
Reinstating database "North_Sales", please wait...
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.
Continuing to reinstate database "North_Sales" ...
Reinstatement of database "North_Sales" succeeded

REMOVE CONFIGURATION

Data Guardブローカ構成ファイルから、すべてのデータベース・プロファイルを含む全ブローカ構成情報を削除し、ブローカ構成に関連付けられているすべてのデータベースのブローカ管理を終了します。

注意:
REMOVE CONFIGURATIONコマンドを使用すると、Data Guardブローカ構成ファイルからすべてのプロファイル情報が削除され、リカバリできません。

書式

REMOVE CONFIGURATION [ PRESERVE DESTINATIONS ];

コマンド・パラメータ

なし。

使用上の注意

- ブローカ構成を削除すると、その構成に関連付けられているすべてのデータベース管理が無効化されます。

- デフォルトでは、このコマンドを実行すると、プライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータと構成内の全データベースのLOG_ARCHIVE_CONFIG初期化パラメータから、対応するブローカ設定が削除されます。これらの設定を保持するには、PRESERVE DESTINATIONSオプションを使用します。

- このコマンドでは、基礎となるData Guard構成の実際のプライマリまたはスタンバイ・データベース・インスタンス、データベース、データファイル、制御ファイル、初期化パラメータ・ファイル、サーバー・パラメータ・ファイルまたはログ・ファイルは削除されず、影響を受けません。

- ファスト・スタート・フェイルオーバーが有効化されている場合は、その構成を削除できません。

コマンドの例

次の例では、REMOVE CONFIGURATIONコマンドの成功例と失敗例を示します。

例1   REMOVE CONFIGURATIONコマンドの成功例

次のコマンドは、構成ファイルから構成情報を削除する方法を示します。

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   REMOVE CONFIGURATIONコマンドの失敗例

次のコマンドは、ファスト・スタート・フェイルオーバーが有効になっているために失敗しています。

DGMGRL> REMOVE CONFIGURATION;
Error: ORA-16654: fast-start failover is enabled

Failed.

DGMGRL> SHOW CONFIGURATION;

Configuration - The SUPER cluster

Protection Mode: MaxAvailability
Databases:
North_Sales  - Primary database
South_Sales  - (*) Physical standby database

Fast-Start Failover: ENABLED

Configuration status:
SUCCESS

REMOVE DATABASE

指定したスタンバイ・データベースのプロファイルをブローカ構成から削除し、スタンバイ・データベースのブローカ管理を終了します。

注意:
REMOVE DATABASEコマンドを使用すると、ブローカ構成ファイルからデータベースのプロファイル情報が削除され、リカバリできません。

書式

REMOVE DATABASE database-name [ PRESERVE DESTINATIONS ];

コマンド・パラメータ

database-name

ブローカ構成からプロファイルを削除するスタンバイ・データベースの名前。

使用上の注意

- ブローカ構成に含まれるプライマリ・データベースの名前を指定すると、エラーが戻されます。

- デフォルトでは、このコマンドを実行すると、プライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータと構成内の全データベースのLOG_ARCHIVE_CONFIG初期化パラメータから、対応するブローカ設定が削除されます。これらの設定を保持するには、PRESERVE DESTINATIONSオプションを使用します。

- このコマンドは、ファスト・スタート・フェイルオーバーが有効になっている場合は実行できません。また、database-nameには、ターゲットのスタンバイ・データベースの名前を指定します。

コマンドの例

例1

次の例に、Data Guard Broker構成からデータベースを削除する方法を示します。

DGMGRL> SHOW CONFIGURATION;

Configuration - The SUPER cluster

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 - The SUPER cluster

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database

Fast-Start Failover: DISABLED

Configuration status:
SUCCESS

REMOVE INSTANCE

ブローカ構成の既存のデータベース・プロファイルからインスタンスを削除します。

書式

REMOVE INSTANCE instance-name

[ON DATABASE database-name];

コマンド・パラメータ

instance-name

ブローカ構成から削除するインスタンスの名前(SID)。

database-name

instance-nameが関連付けられているデータベースの名前。

使用上の注意

- Oracle RACデータベースの場合は、ブローカにより自動的に、対応するデータベース・プロファイルに起動済インスタンスが追加されます。ただし、データベース・プロファイルからはインスタンスを自動的に削除できません。REMOVE INSTANCEコマンドを使用すると、存在しなくなったインスタンスをデータベース・プロファイルから手動で削除できます。

- instance-nameには、構成全体で一意の名前を指定できます。instance-nameが一意ではない場合、database-nameおよびinstance-nameの両方を指定してインスタンスを完全に識別する必要があります。

- ブローカ構成内で現在アクティブなインスタンスの場合は、このコマンドが拒否されます。

- 現在そのインスタンスのみがデータベース・プロファイルに関連付けられている場合、このコマンドは拒否されます。

コマンドの例

例1

次の例に、データベースのインスタンスを削除する方法を示します。

DGMGRL> REMOVE INSTANCE 'south_sales3' ON DATABASE 'South_Sales';
Removed instance "south_sales3" from the database "South_Sales"

SHOW CONFIGURATION

ブローカ構成のサマリーおよびステータスを表示します。サマリーには、ブローカ構成に含まれるすべてのデータベースと、ファスト・スタート・フェイルオーバーのステータスなど、ブローカ構成自体に関するその他の情報が表示されます。

書式

SHOW CONFIGURATION [VERBOSE | property-name];

コマンド・パラメータ

property-name

サマリー情報を表示するプロパティの名前。

プロパティの詳細は、第8章「Data Guard Brokerプロパティ」を参照してください。

使用上の注意

- ファスト・スタート・フェイルオーバーに関連するプロパティを表示するには、SHOW CONFIGURATION VERBOSEコマンド(またはSHOW FAST_START FAILOVERコマンド)を使用します。

- VERBOSEまたはproperty-nameのどちらかをオプションで指定できますが、両方指定することはできません。

コマンドの例

例1   DRSolution構成のサマリーの表示

次の例では、ファスト・スタート・フェイルオーバーが無効化されているDRSolution構成のサマリーを表示しています。

DGMGRL> SHOW CONFIGURATION;

Configuration - The SUPER cluster

Protection Mode: MaxPerformance
Databases:
North_Sales  - Primary database
South_Sales  - Physical standby database

Fast-Start Failover: DISABLED

Configuration status:
SUCCESS

例2   DRSolution構成の詳細な説明の表示

次の例では、DRSolution構成の詳細な情報を、構成プロパティ、ファスト・スタート・フェイルオーバー関連の情報を含めて表示しています。

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration - DRSolution

Protection Mode: MaxAvailability
Databases:
North_Sales  - Primary database
South_Sales  - (*) Physical standby database

(*) Fast-Start Failover target

Properties:
FastStartFailoverThreshold      = '60'
OperationTimeout                = '30'
FastStartFailoverLagLimit       = '30'
CommunicationTimeout            = '180'
FastStartFailoverAutoReinstate  = 'TRUE'
FastStartFailoverPmyShutdown    = 'TRUE'
BystandersFollowRoleChange      = 'ALL'

Fast-Start Failover: ENABLED

Threshold:        180 seconds
Target:           South_Sales
Observer:         observer.example.com
Lag Limit:        30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate:   TRUE

Configuration Status:
SUCCESS

SHOW DATABASE

指定したデータベースとそのインスタンスに関する情報またはプロパティ値を表示します。

書式

SHOW DATABASE [VERBOSE] database-name [property-name];

コマンド・パラメータ

database-name

情報を表示するデータベースの名前。VERBOSEキーワードを使用する場合は、database-nameの前に指定する必要があります。そうしないとエラーが戻ります。

property-name

値を表示するプロパティの名前。プロパティ名を指定すると、VERBOSEキーワードを指定したかどうかにかかわらず、出力には指定したプロパティのみ(データベースのすべてのプロパティではなく)が表示されます。

参照:
プロパティの情報については、第4章および第8章を参照してください。

使用上の注意

- 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:   0 seconds
Apply Lag:       0 seconds
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:   0
Apply Lag:       0
Real Time Query: OFF
Instance(s):
south_sales1

Properties:
DGConnectIdentifier             = 'South_Sales.example.com'
ObserverConnectIdentifier       = ''
LogXptMode                      = 'SYNC'
DelayMins                       = '0'
Binding                         = 'optional'
MaxFailure                      = '0'
MaxConnections                  = '1'
ReopenSecs                      = '300'
NetTimeout                      = '30'
RedoCompression                 = 'DISABLE'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/t, dbs/bt'
LogFileNameConvert              = 'dbs/t, dbs/bt'
FastStartFailoverTarget         = 'North_Sales'
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
SidName                         = 'south_sales1'
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                = 'db2r_%d_%t_%s_%R.arc'
LatestLog                       = '(monitor)'
TopWaitEvents                   = '(monitor)'

Database Status:
SUCCESS

SHOW FAST_START FAILOVER

すべてのファスト・スタート・フェイルオーバー関連情報を表示します。

書式

SHOW FAST_START FAILOVER;

COMMAND PARAMETERS

なし。

使用上の注意

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

Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile          YES
Corrupted Dictionary           YES
Inaccessible Logfile            NO
Stuck Archiver                  NO
Datafile Offline               YES

Oracle Error Conditions:
ORA-27102: out of memory

SHOW INSTANCE

指定したインスタンスの情報またはプロパティ値を表示します。

書式

SHOW INSTANCE [VERBOSE] instance-name [property-name] [ON DATABASE database-name];

コマンド・パラメータ

instance-name

情報を表示するインスタンスの名前。VERBOSEキーワードを使用する場合は、インスタンス名の前に指定する必要があります。

property-name

値を表示するプロパティの名前。プロパティ名を指定すると、VERBOSEキーワードを指定したかどうかにかかわらず、出力には指定したプロパティのみ(すべてのプロパティではなく)が表示されます。

参照:
プロパティの情報については、第4章および第8章を参照してください。

database-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

SHUTDOWN

現在実行中のOracleインスタンスを停止します。

書式

SHUTDOWN [ ABORT | IMMEDIATE | NORMAL ];

コマンド・パラメータ

なし。

使用上の注意

- 引数を指定せずにSHUTDOWNコマンドを使用すると、SHUTDOWN NORMALコマンドを使用した場合と同じ結果になります。

- SHUTDOWNコマンドのオプションを次に示します。

- ABORT
コールの完了やデータベースからのユーザーの切断を待たずに、データベースを可能なかぎり高速でシャットダウンします。コミットされていないトランザクションはロールバックされません。処理中のクライアントのSQL文は終了します。データベースに接続されているユーザー全員が暗黙的に切断され、次回のデータベース起動時にはインスタンスのリカバリが必要になります。バックグラウンド・プロセスが異常終了した場合は、このオプションを使用する必要があります。

注意:
ファスト・スタート・フェイルオーバーが有効化され、オブザーバが実行されている場合に、プライマリ・データベースにABORTオプションを使用すると、ファスト・スタート・フェイルオーバーが実行される場合があります。意図しないファスト・スタート・フェイルオーバーの実行を防ぐには、IMMEDIATEまたはNORMALオプションを使用します。

- IMMEDIATE
現在のコールが完了したり、ユーザーがデータベースから切断するまで待機しません。それ以降の接続は禁止されます。データベースはクローズされ、ディスマウントされます。インスタンスはシャットダウンされ、次回のデータベース起動時にインスタンスのリカバリは不要です。

- NORMAL
これはデフォルトのオプションです。プロセスは、ユーザーがデータベースから切断するまで待機します。それ以降の接続は禁止されます。データベースはクローズされ、ディスマウントされます。インスタンスはシャットダウンされ、次回のデータベース起動時にインスタンスのリカバリは不要です。

コマンドの例

例1

次のコマンドにより、プライマリ・データベースをNORMALモードでシャットダウンします。

DGMGRL > SHUTDOWN;

Database closed.
Database dismounted.
Oracle instance shut down.

START OBSERVER

ファスト・スタート・フェイルオーバーを開始します。

書式

START OBSERVER [ FILE=observer_configuration_filename ];

コマンド・パラメータ

observer_configuration_filename

オブザーバ・コンピュータ上で明示的なディレクトリ・パスおよびファイル名を指定します。

使用上の注意

- ファスト・スタート・フェイルオーバーを有効化する予定のブローカ構成を監視するには、Oracle Client Administratorキット、Oracle Database Enterprise EditionまたはOracle Database Personal Editionのフルキットを、オブザーバ・コンピュータ上にインストールする必要があります。詳細は、5.5.1項を参照してください。

- START OBSERVERコマンドは、オブザーバ・コンピュータ上で発行する必要があります。オブザーバが正常に開始されると、制御は、(別のクライアント接続からのSTOP OBSERVERのコマンドの発行などにより)オブザーバが停止されるまでユーザーには戻されません。そのブローカ構成とさらに交信する場合は、他のクライアントを介して接続する必要があります。

- オブザーバは、正常に起動すると自動的に動作します。このため、START OBSERVERコマンドを発行する目的でDGMGRLを起動する場合、オブザーバとして機能する間に生成された出力が失われないように、コマンドラインでオプション・パラメータ-logfileを指定することをお薦めします。このパラメータの詳細は7.1.1項を参照し、-logfileオプションの使用例は9.5.3項を参照してください。

- ディレクトリ・パスが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 sys@North_Sales.example.com;
Password: password
Connected.
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と一致している必要があります。

参照:
Oracleウォレットの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

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つの起動方法を示します。各コマンドでは、標準パラメータ・ファイルを使用してデータベース・インスタンスを起動し、デフォルト・データベースを排他モードでマウントしてオープンしています。

DGMGRL> STARTUP;
DGMGRL> STARTUP OPEN;

例2

次のコマンドでは、現行のインスタンスをシャットダウンし、その直後にマウントもオープンもせずにデータベースを再起動し、制限付きセッション権限のあるユーザーにのみ接続を許可しています。

DGMGRL > STARTUP FORCE RESTRICT NOMOUNT;

例3

次のコマンドでは、パラメータ・ファイルtestparmを使用して、データベースをマウントせずにインスタンスを起動しています。

DGMGRL > STARTUP PFILE=testparm NOMOUNT;

例4

次の例では、データベース・インスタンスを起動してマウントしていますが、オープンはしていません。

DGMGRL> STARTUP MOUNT;

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コマンドを再度入力できます。旧オブザーバがまだ自身の停止を検出していない場合でも、新規オブザーバを即座に開始できます。ブローカ構成では新しいオブザーバがすでに開始されているため、元のオブザーバの開始を試行すると失敗します。

コマンドの例

例1

次の例ではオブザーバを停止しています。

DGMGRL> STOP OBSERVER;

SWITCHOVER

スイッチオーバー操作は、プライマリ・データベースがスタンバイ・データベースの1つとロールを交換する計画的な遷移です。SWITCHOVERコマンドを発行すると、現行のプライマリ・データベースがスタンバイ・データベースになり、指定したスタンバイ・データベースがプライマリ・データベースになります。

書式

SWITCHOVER TO database-name;

コマンド・パラメータ

database-name

プライマリ・データベースのロールに変更するスタンバイ・データベースの名前。

使用上の注意

- ファスト・スタート・フェイルオーバーが有効な場合は、ファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースへのスイッチオーバーのみ実行できます。

- スイッチオーバーの起動前に、ブローカによって、プライマリ・データベースおよびスタンバイ・データベースが次の状態であることが検証されます。

- REDO転送サービスが起動するように、プライマリ・データベースが有効化され、TRANSPORT-ON状態になっている必要があります。

- スタンバイ・データベースが有効化され、TRANSPORT-ON状態になっており、ログ適用サービスが起動している必要があります。

- ブローカは、スイッチオーバーに関係するように選択したスタンバイ・データベースにREDO転送サービスのエラーがないかぎり、スイッチオーバーを続行します。その他のスタンバイ・データベースにエラーが発生しても、スイッチオーバーの続行には影響しません。

- ロジカル・スタンバイ・データベースへのスイッチオーバーは、構成が最大保護モードで動作している場合には許可されません。

- ブローカ構成が最大保護モードまたは最大可用性モードで動作している場合、スイッチオーバーの操作後も同じ保護モードが維持されます(5.3.1項を参照)。スイッチオーバーのターゲットとなるスタンバイ・データベースが保護モード要件を満たす唯一のスタンバイであったためにモードを維持できない場合、スイッチオーバーは許可されません。

- プライマリ・ロールを引き継ぐスタンバイ・データベースがフィジカル・スタンバイ・データベースの場合は、スイッチオーバーの完了後に、元のプライマリ・データベースが再起動されます。スタンバイ・データベースがロジカル・スタンバイ・データベースの場合は、プライマリ・データベースもロジカル・スタンバイ・データベースも再起動されません。

- プライマリ・ロールを引き継ぐスタンバイ・データベースがフィジカル・スタンバイ・データベースの場合、元のプライマリ・データベースはフィジカル・スタンバイ・データベースとなります。

- プライマリ・ロールを引き継ぐスタンバイ・データベースがロジカル・スタンバイ・データベースの場合、元のプライマリ・データベースはロジカル・スタンバイ・データベースとなります。

- Oracle RACプライマリ・データベースがフィジカル・スタンバイ・データベースになる場合、スイッチオーバーを実行する前に、プライマリ・データベース上のインスタンスのうち1つを残してそれ以外はすべては停止されます。詳細は、5.3項を参照してください。

- スナップショット・スタンバイ・データベースにスイッチオーバーすることはできません。

- プライマリ・ロールを引き継ぐスタンバイ・データベースがロジカル・スタンバイ・データベースで、構成にフィジカル・スタンバイ・データベースが含まれている場合、スイッチオーバー後、フィジカル・スタンバイ・データベースは無効化されます。

注意:
このため、通常、スイッチオーバーには、ロジカル・スタンバイ・データベースのかわりにフィジカル・スタンバイ・データベースを指定することをお薦めします。ロジカル・スタンバイ・データベースへのスイッチオーバーが必要な場合、フィジカル・スタンバイ・データベースを再作成する方法については、5.4.3項を参照してください。
比較的すぐに元のプライマリ・データベースにスイッチバックする場合は、フィジカルおよびスナップショット・スタンバイ・データベースを無効なままにしておくことができます。フィジカルおよびスナップショット・スタンバイ・データベースはまだ元のプライマリ・データベースの実行可能なスタンバイ・データベースであるため、元のプライマリ・データベースへのスイッチバックの完了後、これらを再有効化できます。

コマンドの例

例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

オペレーティング・システム認証を使用してデータベースに接続する場合は、任意のユーザー名およびパスワードを使用して接続できます。ただし、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コマンドを手動で発行して、新しいプライマリおよび停止されたスタンバイ・インスタンスを再起動する必要があります。

8 Data Guard Brokerプロパティ

この章では、ブローカ構成全体、個別のデータベース、REDO転送サービスおよびログ適用サービスの動作を表示および制御するのに役立つ、様々なデータベース構成とデータベース・プロパティについて説明します。

この章の内容は、次のとおりです。

- 構成プロパティ

- 監視可能な(読取り専用)データベース・プロパティ

- 構成可能なデータベース・プロパティ

プロパティの範囲は、構成全体、データベース全体またはインスタンス固有のいずれかです。構成全体を範囲とするプロパティは構成内のすべてのデータベースのブローカの動作を制御します。このようなプロパティの値は、構成内のすべてのデータベースで均一に適用されます。

データベース全体を範囲とするプロパティにより、特定のデータベースの動作を表示または制御できます。データベース(プライマリまたはスタンバイ)は複数のインスタンスから構成されるOracle RACデータベースであり、このようなプロパティの値はデータベースのすべてのインスタンスで均一に適用されます。

インスタンス固有のプロパティにより、個別のデータベース・インスタンスの動作を表示または制御できます。このようなプロパティはOracle RACデータベースのすべてのインスタンスに存在しますが、その値はインスタンスごとに異なる可能性があります。

注意:
この章では、主にData Guardコマンドライン・インタフェース(DGMGRL)の視点からプロパティについて説明します。DGMGRLを使用すると、この章で説明するプロパティを、個別のDGMGRLコマンドを使用して表示または変更できます。
Enterprise Managerでは、これらのプロパティの一部が「プロパティの編集」ページに明示的に表示されます。他のプロパティからの情報は、Enterprise Managerで表示される他のWebページに暗黙的に組み込まれている場合があります。この章では、各プロパティについて説明するとともに、そのプロパティがEnterprise Managerにどのように表示されるかについても説明します。

8.1 構成プロパティ

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

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

次の項で、構成プロパティについて説明します。

- BystandersFollowRoleChange

- CommunicationTimeout

- ExternalDestination1

- ExternalDestination2

- FastStartFailoverAutoReinstate

- FastStartFailoverLagLimit

- FastStartFailoverPmyShutdown

- FastStartFailoverThreshold

- ObserverOverride

- ObserverReconnect

- OperationTimeout

- PrimaryLostWriteAction

- TraceLevel

8.1.1 BystandersFollowRoleChange

BystandersFollowRoleChange構成プロパティは、完全フェイルオーバー処理の一部として、その他のスタンバイ・データベースが新しいプライマリ・データベースの実行可能なスタンバイ・データベースであるかどうかをブローカで判定する必要があるかどうかを指定します。このプロパティをALLに設定すると、ブローカは、フェイルオーバー処理の一部として、各スタンバイ・データベースを評価し、新しいプライマリ・データベースの実行可能なスタンバイ・データベースを検出します。このプロパティをNONEに設定すると、ブローカは実行可能なスタンバイ・データベースかどうかを評価せずにフェイルオーバーを実行します。このオプションを指定すると、フェイルオーバーの処理時間は短縮されますが、構成内のすべてのデータベースのブローカ管理が無効になります。ファスト・スタート・フェイルオーバーが有効な場合は、フェイルオーバーの完了後にオブザーバがスタンバイ・データベースを自動的に回復します。それ以外の場合は、フェイルオーバーの完了後にスタンバイ・データベースを手動で回復する必要があります。

カテゴリ

説明

データ型

文字列

有効値

ALLまたはNONE

ブローカ・デフォルト

ALL

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、完全フェイルオーバーのターゲットであるデータベースでブローカによって使用されます。

Enterprise Manager名

該当なし

8.1.2 CommunicationTimeout

CommunicationTimeout構成プロパティは、ブローカが構成内のデータベース間のネットワーク通信をタイムアウトするまで待機する秒数を指定します。値が0(ゼロ)の場合は、ネットワーク通信をタイムアウトしないことを示します。

カテゴリ

説明

データ型

整数

有効値

>= 0

ブローカ・デフォルト

180秒

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、構成内のすべてのデータベースでブローカによって使用されます。

Enterprise Manager名

該当なし

8.1.3 ExternalDestination1

ExternalDestination1構成プロパティは、現在のプライマリ・データベースからREDOデータを受信できるREDO転送先を指定するために使用されます。指定された宛先へのREDOデータの転送を設定するために、ブローカは指定された値をこのパラメータに使用し、LOG_ARCHIVE_DEST_n初期化パラメータをプライマリ・データベースに定義します。さらにブローカは、指定された宛先への転送の健全性を監視します。

注意:
Oracle Database 11gリリース2 (11.2.0.4)で、ExternalDestination1構成プロパティはREDO転送先としてZero Data Loss Recovery Applianceをサポートします。

ロール変更後、ブローカは新しいプライマリ・データベースに対し、自動的にLOG_ARCHIVE_DEST_n初期化パラメータを設定し、REDOデータを指定された宛先に転送します。

カテゴリ

説明

データ型

文字列

有効値

任意のLOG_ARCHIVE_DEST_n属性(例外は次のとおり)

- ALTERNATE

- LOCATION

- MAX_FAILURES

- SYNC

- VALID_FOR

- TEMPLATE

- MANDATORY

- DELAY

- NET_TIMEOUT

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

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

構成

Enterprise Manager名

該当なし

8.1.4 ExternalDestination2

ExternalDestination2構成プロパティは、現在のプライマリ・データベースからREDOデータを受信できるREDO転送先を指定するために使用されます。指定された宛先へのREDOデータの転送を設定するために、ブローカは指定された値をこのパラメータに使用し、LOG_ARCHIVE_DEST_n初期化パラメータをプライマリ・データベースに定義します。さらにブローカは、指定された宛先への転送の健全性を監視します。

注意:
Oracle Database 11gリリース2 (11.2.0.4)で、ExternalDestination2構成プロパティはREDO転送先としてZero Data Loss Recovery Applianceをサポートします。

ロール変更後、ブローカは新しいプライマリ・データベースに対し、自動的にLOG_ARCHIVE_DEST_n初期化パラメータを設定し、REDOデータを指定された宛先に転送します。

カテゴリ

説明

データ型

文字列

有効値

任意のLOG_ARCHIVE_DEST_n属性(例外は次のとおり)

- ALTERNATE

- LOCATION

- MAX_FAILURES

- SYNC

- VALID_FOR

- TEMPLATE

- MANDATORY

- DELAY

- NET_TIMEOUT

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

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

構成

Enterprise Manager名

該当なし

8.1.5 FastStartFailoverAutoReinstate

FastStartFailoverAutoReinstate構成プロパティを使用すると、プライマリ・データベースが分離またはクラッシュしたためにファスト・スタート・フェイルオーバーが開始した場合に、元のプライマリ・データベースが自動的に回復されます。この場合に元のプライマリ・データベースを自動的に回復しないようにするには、この構成プロパティをFALSEに設定します。

ユーザー構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを要求した場合は、ブローカは元のプライマリ・データベースを自動的に回復しません。

カテゴリ

説明

データ型

ブール

有効値

TRUEまたはFALSE

ブローカ・デフォルト

TRUE

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、ファスト・スタート・フェイルオーバーが有効化された後オブザーバにより使用されます。

Enterprise Manager名

プライマリを自動的に回復

8.1.6 FastStartFailoverLagLimit

FastStartFailoverLagLimit構成プロパティは、REDOの適用に関して、プライマリよりスタンバイが遅れることができる許容範囲を秒単位で確立します。この値を超えて遅れる場合は、ファスト・スタート・フェイルオーバーが実行されません。設定可能な最小値は10秒です。

このプロパティは、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作しているときに使用します。

カテゴリ

説明

データ型

整数

有効値

整数(秒数)。10以上にする必要があります。

ブローカ・デフォルト

30秒

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、ファスト・スタート・フェイルオーバーが有効化された後、プライマリ・データベースより使用されます。

Enterprise Manager名

ラグ制限

8.1.7 FastStartFailoverPmyShutdown

FastStartFailoverPmyShutdown構成プロパティにより、ファスト・スタート・フェイルオーバーが有効化されていてプライマリがFastStartFailoverThresholdの秒数よりも長くSTALLEDになったことをV$DATABASE.FS_FAILOVER_STATUSが示すと、プライマリ・データベースが停止します。この場合、プライマリが分離され、ファスト・スタート・フェイルオーバーが実行されている可能性があります。TRUEの値は、分離されたプライマリ・データベースがユーザーの問合せに対応できないことを確認するのに役立ちます。

ユーザーの構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを要求した場合、このプロパティをFALSEに設定してもプライマリ・データベースの停止を防止できません。

カテゴリ

説明

データ型

ブール

有効値

TRUEまたはFALSE

ブローカ・デフォルト

TRUE

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、ファスト・スタート・フェイルオーバーが有効化された後、プライマリ・データベースより使用されます。

Enterprise Manager名

プライマリを自動的に停止

8.1.8 FastStartFailoverThreshold

FastStartFailoverThreshold構成プロパティは、ターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーを開始するまでに、オブザーバーがプライマリ・データベースとの再接続を試行する時間(秒数)を指定します。この時間間隔は、オブザーバのプライマリ・データベースとの接続が最初に失われたときに開始されます。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できない場合、オブザーバによりファスト・スタート・フェイルオーバーが開始されます。このプロパティの設定方法の詳細は、5.5.2項の手順4を参照してください。

構成可能なファスト・スタート・フェイルオーバー条件が検出された場合、またはアプリケーションでファスト・スタート・フェイルオーバーの開始を要求した場合、オブザーバはしきい値を完全に無視します。

このプロパティに対する適切な値を判断するうえで、V$FS_OBSERVER_HISTOGRAMビューで示される情報が役立ちます。このビューでは、異なる時間間隔のオブザーバとプライマリ・データベース間のpingの成功頻度に基づいた統計が表示されます。(V$FS_OBSERVER_HISTOGRAMビューの詳細は、『Oracle Databaseリファレンス』を参照してください。)

カテゴリ

説明

データ型

整数

有効値

整数(秒数)。6以上にする必要があります。

ブローカ・デフォルト

30秒

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリ・ロールにフェイルオーバーするターゲット・スタンバイ・データベース

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、ファスト・スタート・フェイルオーバーが有効化された後オブザーバにより使用されます。

Enterprise Manager名

Oracle Enterprise Managerでは、この値は「フェイルオーバーのしきい値」としてData Guardの概要ページに表示されます。

8.1.9 ObserverOverride

ObserverOverride構成プロパティをTRUEに設定すると、スタンバイがプライマリに正常に接続していても、オブザーバのプライマリへの接続が失われた場合、自動フェイルオーバーが発生します。

ObserverOverride構成プロパティはOracle Database 11gリリース2 (11.2.0.4)以降のデータベースでのみ使用可能です。

カテゴリ

説明

データ型

ブール

有効値

TRUEまたはFALSE

ブローカ・デフォルト

FALSE

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、ファスト・スタート・フェイルオーバーが有効化された後オブザーバにより使用されます。

Enterprise Manager名

該当なし

8.1.10 ObserverReconnect

ObserverReconnect構成プロパティは、オブザーバがプライマリ・データベースに対して新しい接続を確立する頻度を指定します。このプロパティがデフォルト値の0に設定されている場合、オブザーバはプライマリ・データベースへの接続を作成、維持しますが、プライマリ・データベースへの新しい接続を定期的に作成することはしません。これによりプライマリ・データベースに新しいオブザーバ接続を定期的に確立することによる処理オーバーヘッドがなくなる一方、オブザーバがプライマリ・データベースに新しい接続を作成できないことを検出できなくなります。このプロパティは、プライマリ・データベースの障害を適時に検出できる程度には小さいが、定期的なオブザーバ接続によるオーバーヘッドが許容できるレベルに収まる程度には大きい値に設定することをお薦めします。

ObserverReconnect構成プロパティはOracle Database 11gリリース2 (11.2.0.4)以降のデータベースでのみ使用可能です。

カテゴリ

説明

データ型

整数

有効値

>=0

ブローカ・デフォルト

0

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、ファスト・スタート・フェイルオーバーが有効化された後オブザーバにより使用されます。

Enterprise Manager名

該当なし

8.1.11 OperationTimeout

OperationTimeout構成プロパティは、ブローカがヘルス・チェック、監視可能なプロパティの取得およびプロパティの操作の設定を完了するまでの待機時間の最大値を指定します。

カテゴリ

説明

データ型

整数

有効値

>= 30および<= 600

ブローカ・デフォルト

30秒

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成。このプロパティは、構成内のすべてのデータベースでブローカによって使用されます。

Enterprise Manager名

該当なし

8.1.12 PrimaryLostWriteAction

PrimaryLostWriteAction構成プロパティは、プライマリ・データベースで書込み欠落が発生したことをスタンバイ・データベースが検出した場合の動作を決定します。

- CONTINUE - プライマリ・データベースで書込み欠落が発生したことをスタンバイ・データベースが検出した場合、プライマリ・データベースは動作を継続します。これはデフォルトのアクションです。

- SHUTDOWN - プライマリ・データベースで書込み欠落が発生したことをスタンバイ・データベースが検出した場合、プライマリ・データベースは強制終了を実行します。

プライマリ・データベースで書込み欠落が発生したことをスタンバイ・データベースが検出した場合、ファスト・スタート・フェイルオーバーは無効化されます。そのため、プライマリ・データベースで書込み欠落が発生したことをスタンバイが検出した場合、PrimaryLostWriteActionがSHUTDOWNに設定されている場合であっても、自動フェイルオーバーは発生しません。

プライマリ・データベースおよび書込み欠落を検出したスタンバイ・データベースのデータベース・アラートおよびブローカ・ログに診断情報が記述されます。

プライマリ・データベースで書込み欠落が発生した場合は、My Oracle Supportノート1265884.1 (http://support.oracle.com)のスタンバイ・リカバリ時のORA-752またはORA-600 [3020]の解決のガイドラインに従います。

PrimaryLostWriteAction構成プロパティはOracle Database 11gリリース2 (11.2.0.4)でのみ使用可能です。

注意:
プライマリ・データベースおよび構成内の各スタンバイ・データベースでDB_LOST_WRITE_PROTECTデータベース初期化パラメータをTYPICALまたはFULLに設定し、構成内のすべてのスタンバイ・データベースで、プライマリの書込み欠落を検出できるようにする必要があります。

カテゴリ

説明

データ型

文字列

有効値

CONTINUEまたはSHUTDOWN

ブローカ・デフォルト

CONTINUE

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

ブローカ構成

Enterprise Manager名

該当なし

8.1.13 TraceLevel

TraceLevel構成プロパティは、構成のすべてのメンバーに対してブローカが実行するトレースの量を制御するために使用されます。プロパティをUSERに設定すると、トレース対象は、完了した操作と、操作またはヘルス・チェックから発生する警告またはエラー・メッセージに制限されます。プロパティをSUPPORTに設定すると、Oracleサポート・サービスが必要とするより低レベルの情報が含まれ、トレースの量が増大します。

TraceLevel構成プロパティはOracle Database 11gリリース2 (11.2.0.3)以降のデータベースでのみ使用可能です。

カテゴリ

説明

データ型

文字列

有効値

USER、SUPPORT

ブローカ・デフォルト

USER

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

該当なし

対応

該当なし

有効範囲

データベース

Enterprise Manager名

該当なし

8.2 監視可能な(読取り専用)データベース・プロパティ

監視可能なデータベース・プロパティを使用すると、データベースまたはインスタンスに関連する情報を表示できますが、これらのプロパティの値は変更できません。監視可能なプロパティはすべて、DGMGRLのSHOWコマンドを使用して表示できます。

注意:
監視可能なプロパティの情報を表示できるのは、データベースのブローカ管理が有効な場合のみです。Enterprise Managerでは、これらのプロパティの情報は「プロパティ」ページに表示されます。

データベースがOracle RACデータベースの場合、一部のプロパティの出力値にインスタンス固有の情報も示されることがあります。たとえば、プライマリ・データベースがOracle RACデータベースの場合、LogXptStatusは、Standby2にREDOデータを転送しているInstance1にエラーがあることと、Standby4にREDOデータを転送しているInstance2にエラーがあることを示す場合があります。

次の各項で、監視可能なデータベース・プロパティについて説明します。

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

- InconsistentProperties(非一貫性データベース・プロパティ)

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

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

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

- LsbySkipTable(ロジカル・スタンバイ・スキップ表)

- LsbySkipTxnTable(SQL Applyスキップ・トランザクション表)

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

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

- TopWaitEvents

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

監視可能なデータベース・プロパティInconsistentLogXptPropsは、プロパティの値が、ブローカ構成ファイルとデータベース内のランタイム値の間で一貫性がないすべてのREDO転送サービスに関連するプロパティを示す表を戻します。

この表にレポートされるプロパティはデータベース固有のプロパティですが、非一貫性についてはインスタンス固有ベースでレポートされます。データベース固有のプロパティの場合、ブローカ構成ファイル内では、データベースを共有する全インスタンスの値は同一ですが(唯一の条件)、ランタイム値はインスタンス間で異なる可能性があります。つまり、一部のインスタンスでのみデータベース固有のプロパティに一貫性がない場合があります。

これはプライマリ・データベース関連のプロパティです。この表の列は、次のとおりです。

- INSTANCE_NAME
インスタンスのSIDを識別する値

- STANDBY_NAME
このREDO転送サービス・プロパティに関連するスタンバイ・データベースのデータベース一意名(DB_UNIQUE_NAME)

- PROPERTY_NAME
一貫性のない値が含まれるREDO転送サービス・プロパティの名前

- MEMORY_VALUE
データベースで使用されているランタイム値

- BROKER_VALUE
ブローカ構成ファイルに保存されているREDO転送サービス・プロパティの値

8.2.2 InconsistentProperties(非一貫性データベース・プロパティ)

監視可能なデータベース・プロパティInconsistentPropertiesは、ブローカ構成ファイルに含まれている値が、対応するサーバー・パラメータ・ファイル内の値またはデータベース内のランタイム値と一貫性がないすべてのデータベース・プロパティを示す表を戻します。

この表にレポートされるプロパティは、データベース固有のプロパティの場合やインスタンス固有のプロパティの場合があります。データベース固有のプロパティの場合、データベースを共有するすべてのインスタンスについて、ブローカ構成ファイルに値が1つあることのみが保証され、ランタイム・メモリーの値またはSPFILEの値はインスタンス間で異なる可能性があります。つまり、一部のインスタンスでのみデータベース固有のプロパティに一貫性がない場合があります。

このプロパティは各データベースに個別に存在します。この表の列は、次のとおりです。

- INSTANCE_NAME
インスタンスのSIDを識別する値

- PROPERTY_NAME
一貫性のない値が含まれるデータベース・プロパティの名前

- MEMORY_VALUE
データベースで使用されている対応するランタイム値

- SPFILE_VALUE
サーバー・パラメータ・ファイル(SPFILE)に保存されている対応する値

- BROKER_VALUE
ブローカ構成ファイルに保存されているデータベース・プロパティの値

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

監視可能なデータベース・プロパティLogXptStatusは、有効な各スタンバイ・データベースに対するREDO転送サービスのエラー・ステータスを含む表を戻します。これはプライマリ・データベース関連のプロパティです。

この表の列は、次のとおりです。

- PRIMARY_INSTANCE_NAME
プライマリ・データベースのインスタンスのSIDを識別する値

- STANDBY_DATABASE_NAME
スタンバイ・データベースのデータベース一意名(DB_UNIQUE_NAME)

- ERROR
REDO転送エラーのテキスト。エラーがない場合、フィールドは空です。

この表の各エントリは、あるプライマリ・インスタンスから1つのスタンバイ・データベースへの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 LsbySkipTable(ロジカル・スタンバイ・スキップ表)

監視可能なデータベース・プロパティLsbySkipTableプロパティは、SQL Applyスキップ指定をリストします。これらのスキップ指定では、SQL Applyにロジカル・スタンバイ・データベース上で特定クラスのオンラインREDOログ・ファイルの適用をスキップさせるためのフィルタが指定されています。このプロパティは、DBA_LOGSTDBY_SKIPビューからの次の列を含む表を戻します。

- ERROR
文をスキップするか(Y)、または文に関するエラーを戻すか(N)を示します。

- STATEMENT_OPT
スキップする文のタイプを示します。

- SCHEMA
このスキップ・オプションが使用されるスキーマ名。

- NAME
このスキップ・オプションが使用されるオブジェクトの名前。

- PROCEDURE
スキップ・オプションの処理時に実行するストアド・プロシージャの名前。

これはロジカル・スタンバイ・データベース関連のプロパティです。

8.2.7 LsbySkipTxnTable(SQL Applyスキップ・トランザクション表)

監視可能なデータベース・プロパティLsbySkipTxnTableは、選択されたスキップ設定をリストします。このプロパティは、次の列を含む表を戻します。

- XIDUSN: トランザクションIDのUNDOセグメント番号

- XIDSLT: トランザクションIDのスロット番号

- XIDSQN: トランザクションIDの順序番号

- ACTIVE: プロセスの現行アクティビティの説明、またはSQL Applyの停止理由

これはSQL Apply関連のプロパティです。

8.2.8 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

注意:
Enterprise Managerでは、この情報は「ログ・ファイルの詳細」ページに表示されます。

8.2.9 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

注意:
Enterprise Managerでは、この情報は「ログ・ファイルの詳細」ページに表示されます。

8.2.10 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またはEnterprise Managerを使用して表示し、動的に更新できます。ただし、一部のプロパティは、DGMGRLを使用しなければ更新できません。

ほとんどの場合、構成可能なデータベース・プロパティにはデータベース単位の有効範囲があります。つまり、プロパティに対して設定した値は、データベースの各インスタンスに均一に適用されます。ただし、一部の構成可能なデータベース・プロパティにはインスタンス固有の有効範囲が設定されています。これは、一部の特定のプロパティの値が、複数インスタンスのデータベース環境では、データベースのインスタンスごとに異なる可能性があることを意味します。表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転送サービス

LsbyASkipCfgPr

データベース

SQL Apply

LsbyASkipErrorCfgPr

データベース

SQL Apply

LsbyASkipTxnCfgPr

データベース

SQL Apply

LsbyDSkipCfgPr

データベース

SQL Apply

LsbyDSkipErrorCfgPr

データベース

SQL Apply

LsbyDSkipTxnCfgPr

データベース

SQL Apply

LsbyMaxEventsRecorded

データベース

SQL Apply

LsbyMaxSga

インスタンス*

SQL Apply

LsbyMaxServers

インスタンス*

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転送サービス

ReopenSecs

データベース

REDO転送サービス

SidName

インスタンス

インスタンス識別

StandbyArchiveLocation

インスタンス

REDO転送サービス

StandbyFileManagement

データベース

REDO ApplyおよびSQL Apply

StaticConnectIdentifier

インスタンス

インスタンス起動

TransportDisconnectedThreshold

データベース

REDO転送サービス

TransportLagThreshold

データベース

REDO転送サービス

参照:
データベース・プロパティの管理の詳細は、第4章を参照してください。

注意:
プライマリ・データベースとともにブローカ構成が作成され、スタンバイ・データベースが構成に追加されると、ブローカは、多数のプロパティを設定するために、データベースから既存の設定をインポートします。既存の設定のインポートに失敗したり、プロパティ値がインポートされなかった場合、ブローカは、ブローカ・デフォルト値を使用します。プロパティがインポートされたかどうか、およびデフォルト値を、各プロパティの説明で示します。

8.3.1 AlternateLocation

構成可能なデータベース・プロパティAlternateLocationは、StandbyArchiveLocationで指定された位置に格納できない場合に、アーカイブREDOログ・ファイルの格納先としてスタンバイ内の代替ディスク位置を指定します。このプロパティの有効範囲はインスタンス固有であるため、指定する位置はインスタンスからアクセスできる必要があります。

カテゴリ

説明

データ型

文字列

有効値

スタンバイ・インスタンスがあるシステム上のディレクトリ指定

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

動的

ロール

スタンバイ脚注1

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

- スタンバイ・インスタンスの場合は構成可能なデータベース・プロパティStandbyArchiveLocationと一致するローカル格納先の代替格納先を表すLOG_ARCHIVE_DEST_n初期化パラメータのLOCATION属性

- プライマリ・データベースの場合は、代替格納先を表すLOG_ARCHIVE_DEST_n初期化パラメータのTEMPLATE属性

有効範囲

インスタンス

Enterprise Manager名

スタンバイの代替場所

脚注1 このプロパティはスタンバイ・インスタンスに対して設定されますが、プライマリ・データベースのREDO転送サービスに間接的に関係します。ブローカはスタンバイ・インスタンスにはローカルの代替格納先、プライマリ・データベースにはリモートの代替格納先を設定します。

注意:
ロジカル・スタンバイ・データベースの場合は、ローカルの格納先を示すLOG_ARCHIVE_DEST_n初期化パラメータのLOCATION属性と構成可能なデータベース・プロパティAlternateLocationの値には別の値を設定することをお薦めします。

8.3.2 ApplyInstanceTimeout

構成可能なデータベース・プロパティApplyInstanceTimeoutは、現行の適用インスタンスの障害を検出してから適用インスタンスのフェイルオーバーを開始するまでの、ブローカの待機秒数を指定します。

カテゴリ

説明

データ型

整数

有効値

>=0(秒)

ブローカ・デフォルト

0(即時適用インスタンス・フェイルオーバーとなります)

インポート

不要

パラメータ・クラス

該当なし

ロール

スタンバイ

スタンバイ・タイプ

フィジカルまたはロジカル

対応

該当なし

有効範囲

データベース

Enterprise Manager名

該当なし

8.3.3 ApplyLagThreshold

構成可能なデータベース・プロパティApplyLagThresholdは、ロジカルまたはフィジカルのスタンバイでのデータベースの適用ラグがプロパティで指定された値を上回った場合の警告ステータスを生成します。プロパティ値を表す単位は秒です。値が0秒の場合、適用ラグが存在しても警告を生成しません。

ApplyLagThreshold構成プロパティはOracle Database 11gリリース2 (11.2.0.4)以降のデータベースでのみ使用可能です。

カテゴリ

説明

データ型

数値

有効値

>=0

ブローカ・デフォルト

0秒

インポート

不要

パラメータ・クラス

該当なし

ロール

スタンバイ

スタンバイ・タイプ

フィジカル、ロジカル

対応

該当なし

有効範囲

データベース

Enterprise Manager名

該当なし

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句に対応

有効範囲

データベース

Enterprise Manager名

該当なし

8.3.5 ArchiveLagTarget

構成可能なデータベース・プロパティArchiveLagTargetは、指定した期間(秒単位)が経過した後にログ・スイッチを強制して、失われる可能性のあるデータ量を制限し、スタンバイ・データベースの可用性を向上させます。つまり、スタンバイ・データベースでは、ARCHIVE_LAG_TARGET初期化パラメータに設定された値を超える期間に生成されたREDOレコードは失われなくなります。

カテゴリ

説明

データ型

数値

有効値

秒(0秒、または60から7200秒の数値)

ブローカ・デフォルト

0(無効)

インポート

ARCHIVE_LAG_TARGET初期化パラメータからインポート

パラメータ・クラス

動的

ロール

プライマリ

スタンバイ・タイプ

該当なし

対応

ARCHIVE_LAG_TARGET=seconds初期化パラメータ

有効範囲

データベース

Enterprise Manager名

アーカイブ・タイムラグ・ターゲット

8.3.6 バインド

構成可能なデータベース・プロパティBindingは、スタンバイ接続先がMANDATORYであるかOPTIONALであるかを指定します。

カテゴリ

説明

データ型

文字列

有効値

- MANDATORY
MANDATORY値を使用すると、オンラインREDOログ・ファイルの再利用ポリシーを指定できます。必須接続先のアーカイブ操作に失敗すると、オンラインREDOログ・ファイルを上書きできません。

- OPTIONAL
OPTIONAL値を使用すると、オンラインREDOログ・ファイルの再利用ポリシーを指定できます。オプションの接続先のアーカイブ操作に失敗すると、オンラインREDOログ・ファイルが上書きされます。

ブローカ・デフォルト

OPTIONAL

インポート

プライマリ・データベースのV$ARCHIVE_DESTビューのBINDING列からインポート

パラメータ・クラス

動的

ロール

スタンバイ脚注1

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

- プライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータのMANDATORYおよびOPTIONAL属性

- プライマリ・データベースのV$ARCHIVE_DESTビューのBINDING列

有効範囲

データベース

Enterprise Manager名

該当なし

脚注1 このプロパティはスタンバイ・データベースに対して設定されますが、プライマリ・データベースの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初期化パラメータ

有効範囲

データベース

Enterprise Manager名

DBファイル名の変換

8.3.8 DelayMins

構成可能なデータベース・プロパティDelayMinsは、ログ適用サービスで、スタンバイ・データベースでのアーカイブREDOログ・データの適用を遅延する時間(分)を指定します。DelayMinsプロパティがデフォルト値の0(分)に設定されている場合、ログ適用サービスは、REDOデータをできるかぎり速やかに適用します。

DelayMinsプロパティが0に設定されている場合は、ログ適用サービスを次の手順で開始します。

- 次のSQL文を使用して、フィジカル・スタンバイ・データベース上でREDO Applyを開始します。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

- 次のSQL文を使用して、ロジカル・スタンバイ・データベース上でSQL Applyを開始します。

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

カテゴリ

説明

データ型

整数

有効値

>=0(分)

ブローカ・デフォルト

0

インポート

プライマリ・データベースのV$ARCHIVE_DESTビューのDELAY_MINS列からインポート

パラメータ・クラス

動的

ロール

スタンバイ脚注1

スタンバイ・タイプ

フィジカルおよびロジカル

対応

- プライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータのDELAY属性

- プライマリ・データベースのV$ARCHIVE_DESTビューのDELAY_MINS列

- REDO ApplyおよびSQL Applyの開始に使用するオプション

有効範囲

データベース

Enterprise Manager名

遅延の適用(分)

脚注1 このプロパティはスタンバイ・データベースに対して設定されますが、プライマリ・データベースのREDO転送サービスに間接的に関係します。スタンバイ・データベースに指定した設定は、ブローカによりプライマリ・データベースのLOG_ARCHIVE_DEST_n値の対応する属性に伝播されます。

8.3.9 DGConnectIdentifier

構成可能なデータベース・プロパティDGConnectIdentifierは、ブローカでデータベースへの接続の際に使用される接続識別子を指定します。DGMGRLを使用する場合は、CREATE CONFIGURATIONまたはADD DATABASEコマンドの入力時に値を指定します。Enterprise Managerを使用する場合、値は自動的に設定されます。データベースの接続識別子は、次の条件を満たす必要があります。

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

- データベースは自分自身にアクセスできます。

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

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

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

このプロパティの値は、ブローカがプライマリ・データベース上でREDO転送サービスを構成する際にLOG_ARCHIVE_DEST_nパラメータのSERVICE属性で指定されます。

カテゴリ

説明

データ型

文字列

有効値

このデータベースの接続に使用できる接続識別子

ブローカ・デフォルト

該当なし

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

プライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータのSERVICE_NAME属性

有効範囲

データベース

Enterprise Manager名

該当なし

注意:
Oracle Databaseリリース11.1以前には、構成可能なデータベース・プロパティDGConnectIdentifierは、InitialConnectIdentifierプロパティと呼ばれていました。10g構成をこのリリースにアップグレードする場合、InitialConnectIdentifier値は、そのデータベースの新しいDGConnectIdentifier値として保持されます。
これがOracle RACデータベースの場合は、必ず、アップグレードする前に、InitialConnectIdentifierがDGConnectIdentifierのために列記された基準に一致していることを確認してください。

参照:
『Oracle Database Net Services管理者ガイド』

8.3.10 FastStartFailoverTarget

FastStartFailoverTarget構成プロパティは、このデータベースがプライマリ・データベースの場合、ファスト・スタート・フェイルオーバーのターゲットになるデータベースのDB_UNIQUE_NAMEを指定します。このプロパティの設定方法の詳細は、5.5.2項の手順2を参照してください。

カテゴリ

説明

データ型

文字列

有効値

ファスト・スタート・フェイルオーバーのターゲットとなるデータベースのDB_UNIQUE_NAME

ブローカ・デフォルト

フィジカルまたはロジカル・スタンバイ・データベースが1つのみ存在している場合、ブローカはそのデータベースを、ファスト・スタート・フェイルオーバーが有効化されたときに、プライマリ・データベースのこのプロパティのデフォルト値として選択します。
複数のフィジカルまたはロジカル・スタンバイ・データベースが存在する場合は、ファスト・スタート・フェイルオーバーを有効化する前に、このFastStartFailoverTargetの値を明示的に指定する必要があります。ファスト・スタート・フェイルオーバーが有効化されると、指定されたターゲットが検証されます。

ターゲット・スタンバイ・データベース側では、ブローカは、ファスト・スタート・フェイルオーバーが有効化されたときに自動的に、このプロパティの値として現在のプライマリ・データベースを選択します。

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリまたはスタンバイ

スタンバイ・タイプ

フィジカルまたはロジカル

対応

該当なし

有効範囲

データベース

Enterprise Manager名

Enterprise Managerでは、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コマンドを使用して、すべてのインスタンスでこのプロパティに同じ値を指定することができます。)

Enterprise Manager名

該当なし

8.3.12 LogArchiveMaxProcesses

構成可能なデータベース・プロパティLogArchiveMaxProcessesは、Oracleデータベースが最初に起動するアーカイバ・プロセス数(ARCn)を指定します。使用されるアーカイバ・プロセスの実際の数は、アーカイブのワークロードに基づき後で増える場合があります。

カテゴリ

説明

データ型

整数

有効値

1から30

ブローカ・デフォルト

4

インポート

LOG_ARCHIVE_MAX_PROCESSES初期化パラメータからインポート

パラメータ・クラス

動的

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

LOG_ARCHIVE_MAX_PROCESSES初期化パラメータ

有効範囲

データベース

Enterprise Manager名

アーカイバ・プロセス

8.3.13 LogArchiveMinSucceedDest

構成可能なデータベース・プロパティLogArchiveMinSucceedDestは、オンラインREDOログ・ファイルが再利用可能になる時期を制御します。オンラインREDOログ・ファイルが再利用可能になるには、最小数のアーカイブ先に対するアーカイブが正常終了する必要があります。

カテゴリ

説明

データ型

整数

有効値

1から10

ブローカ・デフォルト

1

インポート

LOG_ARCHIVE_MIN_SUCCEED_DEST初期化パラメータからインポート

パラメータ・クラス

動的

ロール

プライマリ

スタンバイ・タイプ

該当なし

対応

LOG_ARCHIVE_MIN_SUCCEED_DEST初期化パラメータ

有効範囲

データベース

Enterprise Manager名

該当なし

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の追跡(メディア・リカバリまたはフィジカル・スタンバイ)

ブローカ・デフォルト

255

インポート

LOG_ARCHIVE_TRACE初期化パラメータからインポート

パラメータ・クラス

動的

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

LOG_ARCHIVE_TRACE初期化パラメータ

有効範囲

インスタンス(Oracle RACデータベースでは、EDIT INSTANCE * ON DATABASEコマンドを使用して、すべてのインスタンスでこのプロパティに同じ値を指定することができます。)

Enterprise Manager名

ログ・アーカイブ・トレース

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初期化パラメータ

有効範囲

データベース

Enterprise Manager名

ログ・ファイル名の変換

8.3.16 LogShipping

構成可能なデータベース・プロパティLogShippingは、REDO転送サービスで、特定のスタンバイ・データベースへのREDOデータの送信を可能にするかどうかを指定します。ブローカは、プライマリ・データベースがTRANSPORT-ON状態の場合にのみ、LogShippingプロパティの値を使用します。

- プライマリ・データベースがTRANSPORT-OFF状態の場合は、LogShippingプロパティのON/OFFに関係なく、REDO転送サービスはすべてのスタンバイ・データベースに対して無効化されます。

- プライマリ・データベースがTRANSPORT-ON状態で、LogShippingプロパティの値がONの場合は、REDO転送サービスによる特定スタンバイ・データベースへのREDOデータの送信が有効化されます。LogShippingプロパティがOFFの場合は、REDO転送サービスによる特定スタンバイ・データベースへのREDOデータの送信が無効化されます。

カテゴリ

説明

データ型

文字列

有効値

ONまたはOFF

ブローカ・デフォルト

ON

インポート

不要

パラメータ・クラス

動的

ロール

スタンバイ脚注1

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

プライマリ・データベースのLOG_ARCHIVE_DEST_STATE_n初期化パラメータのENABLEおよびDEFER値

有効範囲

データベース

Enterprise Manager名

ログ送信

脚注1 このプロパティはスタンバイ・データベースに対して設定されますが、プライマリ・データベースの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に比べるとパフォーマンスへの影響も小さくなります。

カテゴリ

説明

データ型

文字列

有効値

SYNCまたはASYNC

ブローカ・デフォルト

ASYNC

インポート

プライマリ・データベースのV$ARCHIVE_DESTビューのARCHIVER、TRANSMIT_MODEおよびAFFIRM列からインポート

パラメータ・クラス

動的

ロール

スタンバイ脚注1

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

- プライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータのSYNC、ASYNC、AFFIRMおよびNOAFFIRM属性

- プライマリ・データベースのV$ARCHIVE_DESTビューのARCHIVER、TRANSMIT_MODEおよびAFFIRM列

有効範囲

データベース

Enterprise Manager名

REDOトランスポート・サービス

脚注1 このプロパティはスタンバイ・データベースに対して設定されますが、プライマリ・データベースのREDO転送サービスに間接的に関係します。スタンバイ・データベースに指定した設定は、ブローカによりプライマリ・データベースのLOG_ARCHIVE_DEST_n値の対応する属性に伝播されます。

参照:
REDO転送サービスのデータ保護モードの設定方法の詳細は、第4章を参照してください。

8.3.18 LsbyASkipCfgPr

構成可能なデータベース・プロパティLsbyASkipCfgPrは、適用サービスを制御して、ロジカル・スタンバイ・データベースに適用しないSQL文をスキップ(無視)するために、スキップ指定をSQL Applyに追加する方法を提供します。SKIP操作の内容は、次のとおりです。

- スタンバイ・データベースに適用しないSQL文を識別する基準を設定します。

- 必要な場合は、実行する追加の処理を指定します。

スタンバイ・データベースの管理が無効化されている場合は、このプロパティの値を指定しても効果はなく、無視されます。

カテゴリ

説明

データ型

文字列

有効値

DBMS_LOGSTDBY.SKIPプロシージャの有効な引数のセット

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

動的。SQL Applyには再起動は必要ではありません。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.SKIPプロシージャ

有効範囲

データベース

Enterprise Manager名

スキップする表エントリの追加

参照:
Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

8.3.19 LsbyASkipErrorCfgPr

構成可能なデータベース・プロパティLsbyASkipErrorCfgPrは、SQL Applyにスキップ・エラー指定を追加します。エラーが発生したときにSQL Applyを停止するかどうかを判断する基準を提供します。スキップ対象のすべてのエラーが、例外の処理方法を記述したシステム表に格納されます。

スタンバイ・データベースの管理が無効化されている場合は、このプロパティの値を指定しても効果はなく、無視されます。

カテゴリ

説明

データ型

文字列

有効値

DBMS_LOGSTDBY.SKIP_ERRORプロシージャの有効な引数のセット。文字列は、引数の間をカンマで区切る必要があります。

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

動的。SQL Applyには再起動は必要ではありません。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.SKIP_ERRORプロシージャ

有効範囲

データベース

Enterprise Manager名

スキップする表エントリの追加

参照:
Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

8.3.20 LsbyASkipTxnCfgPr

構成可能なデータベース・プロパティLsbyASkipTxnCfgPrは、SQL Applyがロジカル・スタンバイ・データベースへのトランザクションの適用を停止する原因となったトランザクションをスキップします。このプロパティでは、SQL Applyの処理対象から除外する、問題のあるトランザクションのトランザクションID(XIDSQN NUMBER)を指定できます。SQL Applyを再起動する前に、スキップされたトランザクションにかわってロジカル・スタンバイ・データベースを正常に更新するSQLトランザクションを発行する必要があります。補足的なトランザクションを適用すると、ロジカル・スタンバイ・データベースとプライマリ・データベースとのトランザクション的な一貫性を維持できます。

スタンバイ・データベースの管理が無効化されている場合は、このプロパティの値を指定しても効果はなく、無視されます。

カテゴリ

説明

データ型

文字列

有効値

DBMS_LOGSTDBY.SKIP_TRANSACTIONプロシージャの有効な引数のセット。引数の間をカンマで区切ります。

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

動的。SQL Applyには再起動は必要ではありません。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.SKIP_TRANSACTIONプロシージャ

有効範囲

データベース

Enterprise Manager名

プロパティの編集のスキップ

注意:
Enterprise Managerでは、プロパティの編集のスキップ・ページを使用してトランザクションをスキップする操作が間接的にサポートされます。

参照:
Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

8.3.21 LsbyDSkipCfgPr

構成可能なデータベース・プロパティLsbyDSkipCfgPrは、SQL Applyから既存のスキップ指定を削除します。レコードを検索してすべてのパラメータを照合し、システム表からレコードを削除して、LsbyASkipCfgPrプロパティの処理を元に戻すか削除します。照合は正確に行う必要があります。複数のスキップ処理は、一致するアンスキップ処理のみを削除できます。このプロパティの値にワイルドカード文字を使用して複数のスキップ処理を削除することはできません。

スタンバイ・データベースの管理が無効化されている場合は、このプロパティの値を指定しても効果はなく、無視されます。

カテゴリ

説明

データ型

文字列

有効値

DBMS_LOGSTDBY.UNSKIPプロシージャの有効な引数のセット

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

動的。SQL Applyには再起動は必要ではありません。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.UNSKIPプロシージャ

有効範囲

データベース

Enterprise Manager名

スキップする表エントリの削除

参照:
Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

8.3.22 LsbyDSkipErrorCfgPr

構成可能なデータベース・プロパティLsbyDSkipErrorCfgPrは、SQL Applyから既存のスキップ・エラー指定を削除します。レコードを検索してすべてのパラメータを照合し、システム表からレコードを削除して、LsbyASkipErrorCfgPrプロパティの処理を元に戻すか削除します。照合は正確に行う必要があります。複数のスキップ処理は、一致するアンスキップ処理のみを削除できます。このプロパティの値にワイルドカード文字を使用して複数のスキップ処理を削除することはできません。

スタンバイ・データベースの管理が無効化されている場合は、このプロパティの値を指定しても効果はなく、無視されます。

カテゴリ

説明

データ型

文字列

有効値

DBMS_LOGSTDBY.UNSKIP_ERRORプロシージャの有効な引数のセット。文字列は、引数の間をカンマで区切る必要があります。

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

動的。SQL Applyには再起動は必要ではありません。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.UNSKIP_ERRORプロシージャ

有効範囲

データベース

Enterprise Manager名

スキップする表エントリの削除

参照:
Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

8.3.23 LsbyDSkipTxnCfgPr

構成可能なデータベース・プロパティLsbyDSkipTxnCfgPrは、LsbyASkipTxnCfgPrプロパティの処理を元に戻すか削除します。トランザクションIDは正確に一致する必要があります。複数のスキップ・トランザクション処理は、一致するアンスキップ・トランザクションの処理のみを削除できます。このプロパティの値にワイルドカード文字を使用して複数のスキップ・トランザクション処理を削除することはできません。

スタンバイ・データベースの管理が無効化されている場合は、このプロパティの値を指定しても効果はなく、無視されます。

カテゴリ

説明

データ型

文字列

有効値

DBMS_LOGSTDBY.UNSKIP_TRANSACTIONプロシージャの有効な引数のセット

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

動的。SQL Applyには再起動は必要ではありません。

ロール

スタンバイ

スタンバイ・タイプ

ロジカル

対応

DBMS_LOGSTDBY.UNSKIP_TRANSACTIONプロシージャ

有効範囲

データベース

Enterprise Manager名

該当なし

参照:
Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

8.3.24 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')プロシージャ

有効範囲

データベース

Enterprise Manager名

最大記録済イベント数

8.3.25 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コマンドを使用して、すべてのインスタンスでこのプロパティに同じ値を指定することができます。)

Enterprise Manager名

最大SGA(MB)

8.3.26 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コマンドを使用して、すべてのインスタンスでこのプロパティに同じ値を指定することができます。)

Enterprise Manager名

最大サーバー数

8.3.27 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')プロシージャ

有効範囲

データベース

Enterprise Manager名

コミット順序を保持

8.3.28 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')プロシージャ

有効範囲

データベース

Enterprise Manager名

レコード適用DDL

8.3.29 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')プロシージャ

有効範囲

データベース

Enterprise Manager名

レコード・スキップDDL

8.3.30 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')プロシージャ

有効範囲

データベース

Enterprise Manager名

レコード・スキップ・エラー

8.3.31 MaxConnections

構成可能なデータベース・プロパティMaxConnectionsは、プライマリ・データベースの単一のアーカイブREDOログからリモート・サイトのアーカイブREDOログにREDOデータを転送するために同時にいくつのARCnプロセスを使用するかを指定します。MaxConnectionsプロパティが1よりも大きい値に設定されている場合、REDO転送サービスでは、複数のARCnプロセスを使用してREDOデータをリモートの保存先のアーカイブREDOログ・ファイルに転送します。

カテゴリ

説明

データ型

整数

有効値

1から20

ブローカ・デフォルト

1

インポート

される(プライマリ・データベースのV$ARCHIVE_DESTビューのMAX_CONNECTIONS列からインポート)

パラメータ・クラス

動的

ロール

スタンバイ

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

- LOG_ARCHIVE_MAX_PROCESSES初期化パラメータ脚注1

- プライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータのMAX_CONNECTIONS属性

- プライマリ・データベースのV$ARCHIVE_DESTビューのMAX_CONNECTIONS列

有効範囲

データベース

Enterprise Manager名

該当なし

脚注1 LOG_ARCHIVE_MAX_PROCESSES初期化パラメータは、インスタンスが実際に使用するARCnプロセスの数に影響します。

8.3.32 MaxFailure

構成可能なデータベース・プロパティMaxFailureは、連続してアーカイブに失敗する最大許容数を指定します。この回数を超えると、REDO転送サービスにより、スタンバイ・データベースへのアーカイブREDOログ・ファイルの転送が停止されます。値が0(ゼロ)の場合は、障害の発生が無制限に許容されることを示します。

カテゴリ

説明

データ型

整数

有効値

>=0

ブローカ・デフォルト

0

インポート

プライマリ・データベースのV$ARCHIVE_DESTビューのMAX_FAILURE列からインポート

パラメータ・クラス

動的

ロール

スタンバイ脚注1

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

- プライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータのMAX_FAILURE属性

- プライマリ・データベースのV$ARCHIVE_DESTビューのMAX_FAILURE列

有効範囲

データベース

Enterprise Manager名

該当なし

脚注1 このプロパティはスタンバイ・データベースに対して設定されますが、プライマリ・データベースのREDO転送サービスに間接的に関係します。スタンバイ・データベースに指定した設定は、ブローカによりプライマリ・データベースのLOG_ARCHIVE_DEST_n値の対応する属性に伝播されます。

8.3.33 NetTimeout

構成可能なデータベース・プロパティNetTimeoutは、Oracle Net ServicesがLGWR要求に応答するまでLGWRが待機する秒数を指定します。このプロパティを使用して、TCPでの長い接続タイムアウトが迂回されます。

カテゴリ

説明

データ型

整数

有効値

0、15から1200

ブローカ・デフォルト

30

インポート

プライマリ・データベースのV$ARCHIVE_DESTビューのNET_TIMEOUT列からインポート

パラメータ・クラス

動的

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

- プライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータのNET_TIMEOUT属性

- プライマリ・データベースのV$ARCHIVE_DESTビューのNET_TIMEOUT列

有効範囲

データベース

Enterprise Manager名

該当なし

8.3.34 ObserverConnectIdentifier

構成可能なデータベース・プロパティObserverConnectIdentifierは、このデータベースとの接続のためにオブザーバが使用できる接続識別子を指定します。ファスト・スタート・フェイルオーバーが有効化されている場合は、プライマリ・データベースまたはターゲット・スタンバイ・データベースにのみ関連があります。

カテゴリ

説明

データ型

文字列

有効値

このデータベースの接続にオブザーバが使用できる接続識別子

ブローカ・デフォルト

空の文字列脚注1

インポート

不要

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

フィジカルまたはロジカル

対応

該当なし

有効範囲

データベース

Enterprise Manager名

オブザーバの接続識別子

脚注1 空の文字列である場合(ユーザーが設定しなかった場合)、このデータベースのDGConnectIdentifierプロパティで指定された接続識別子がオブザーバによって使用されます。

8.3.35 PreferredApplyInstance

構成可能なデータベース・プロパティPreferredApplyInstanceは、特定のインスタンスがログ適用サービス提供に関して優先候補であることを示します。このプロパティを使用するのは、スタンバイOracle RACデータベースの場合のみです。空の文字列(デフォルト)を指定できます。この場合、ブローカでは適用インスタンスが選択されます。

カテゴリ

説明

データ型

文字列

有効値

インスタンス名(SID)または空の文字列。特定のプラットフォームでは、SIDの大/小文字が区別される場合があることに注意してください。

ブローカ・デフォルト

空の文字列

インポート

不要

パラメータ・クラス

該当なし

ロール

スタンバイ

スタンバイ・タイプ

フィジカルまたはロジカル

対応

該当なし

有効範囲

データベース

Enterprise Manager名

適用インスタンス

参照:

- SIDの詳細は、『Oracle Database管理者ガイド』を参照してください。

- Oracle RAD環境での適用サービスの詳細は、4.5.7項を参照してください。

8.3.36 RedoCompression

構成可能なデータベース・プロパティRedoCompressionは、スタンバイ・データベースに転送されるREDOデータが圧縮形式か非圧縮形式かを指定します。

注意:
REDO転送圧縮は、Oracle Advanced Compressionオプションの機能です。REDO転送圧縮機能を使用する前にこのオプションのライセンスを購入する必要があります。

カテゴリ

説明

データ型

文字列

有効値

DISABLEまたはENABLE

ブローカ・デフォルト

DISABLE

インポート

プライマリ・データベースのV$ARCHIVE_DESTビューのCOMPRESSION列からインポート

パラメータ・クラス

動的

ロール

スタンバイ脚注1

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

- プライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータのCOMPRESSION属性

- プライマリ・データベースのV$ARCHIVE_DESTビューのCOMPRESSION列

有効範囲

データベース

Enterprise Manager名

該当なし

脚注1 このプロパティはスタンバイ・データベースに対して設定されますが、プライマリ・データベースのREDO転送サービスに間接的に関係します。スタンバイ・データベースに指定した設定は、ブローカによりプライマリ・データベースのLOG_ARCHIVE_DEST_n値の対応する属性に伝播されます。

8.3.37 ReopenSecs

構成可能なデータベース・プロパティReopenSecsは、アーカイバ・プロセス(ARCn、フォアグラウンドまたはログ・ライター・プロセス)が、以前失敗した宛先に再度アクセスしようとするまでの最小時間(秒)を指定します。

カテゴリ

説明

データ型

整数

有効値

>=0(秒)

ブローカ・デフォルト

300

インポート

プライマリ・データベースのV$ARCHIVE_DESTビューのREOPEN_SECS列からインポート

パラメータ・クラス

動的

ロール

スタンバイ脚注1

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

- プライマリ・データベースのLOG_ARCHIVE_DEST_n初期化パラメータのREOPEN属性

- プライマリ・データベースのV$ARCHIVE_DESTビューのREOPEN_SECS列

有効範囲

データベース

Enterprise Manager名

該当なし

脚注1 このプロパティはスタンバイ・データベースに対して設定されますが、プライマリ・データベースのREDO転送サービスに間接的に関係します。スタンバイ・データベースに指定した設定は、ブローカによりプライマリ・データベースのLOG_ARCHIVE_DEST_n値の対応する属性に伝播されます。

8.3.38 SidName

構成可能なデータベース・プロパティSidNameは、インスタンスのOracleシステム識別子(SID)を指定します。このプロパティは、データベースのブローカ管理が無効化されている場合にのみ更新できます。このプロパティの値は、SIDを変更する場合にのみ更新してください。その場合は、データベースのブローカ管理を無効化し、SidNameプロパティを新しいSIDに合せて更新してから、ブローカ管理を再び有効化する必要があります。

注意:
名前がこのインスタンスのdb_unique_nameと一致し、SidNameプロパティの値がこのインスタンスの実際のSID値と一致するデータベース・オブジェクトの既存インスタンス・オブジェクトがブローカ構成にない場合は、このインスタンスのdb_unique_nameを持つデータベースの新しいインスタンス・オブジェクトがブローカによって作成されます。詳細は、1.3項「Data Guard Brokerの管理モデル」を参照してください。

カテゴリ

説明

データ型

文字列

有効値

インスタンスのSID。特定のプラットフォームでは、SIDの大/小文字が区別される場合があることに注意してください。

ブローカ・デフォルト

該当なし

インポート

はい

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

V$INSTANCEビューのINSTANCE_NAME列

有効範囲

インスタンス

Enterprise Manager名

該当なし

参照:
SIDの詳細は、『Oracle Database管理者ガイド』を参照してください。

8.3.39 StandbyArchiveLocation

構成可能なデータベース・プロパティStandbyArchiveLocationは、プライマリ・データベースから受け取るアーカイブREDOログ・ファイルの場所を指定します。値は常に明示的に設定することをお薦めします。

カテゴリ

説明

データ型

文字列

有効値

空ではないファイル。スタンバイ・データベース上にあるアーカイブREDOログ・ファイルの場所を指定。データベース・リカバリ領域が必要な場合は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列

有効範囲

インスタンス

Enterprise Manager名

スタンバイ・アーカイブの場所

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

8.3.40 StandbyFileManagement

構成可能なデータベース・プロパティStandbyFileManagementは、プライマリ・データベース上でのデータファイル追加操作をスタンバイ・データベースに適用する方法に影響します。このプロパティをAUTOに設定し、構成可能なデータベース・プロパティDbFileNameConvertを有効な値に設定すると、対応する新規データファイルがスタンバイ・データベース上で自動的に作成されます。この新規スタンバイ・データファイルの位置は、DbFileNameConvertプロパティの値により決定されます。

このプロパティをMANUALに設定した場合は、スタンバイ・データベース上で適切な新規データファイルを手動で作成する必要があります。

カテゴリ

説明

データ型

文字列

有効値

AUTOまたはMANUAL

ブローカ・デフォルト

AUTO

インポート

STANDBY_FILE_MANAGEMENT初期化パラメータからインポート

パラメータ・クラス

動的

ロール

スタンバイ

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

STANDBY_FILE_MANAGEMENT初期化パラメータ

有効範囲

データベース

Enterprise Manager名

該当なし

8.3.41 StaticConnectIdentifier

構成可能なインスタンス固有のプロパティStaticConnectIdentifierは、データベース・インスタンスの起動時にDGMGRLクライアントが使用する接続識別子を指定します。

カテゴリ

説明

データ型

文字列

有効値

静的に登録されているサービスを参照する接続識別子。

ブローカ・デフォルト

次の値の連結である接続識別子。脚注1

- LOCAL_LISTENER初期化パラメータに指定されているリスナーのADDRESS属性の値

- db_unique_name_DGMGRL.db_domainの連結した値に設定されるSERVICE_NAME属性の値

インポート

LOCAL_LISTENERおよびDB_UNIQUE_NAME初期化パラメータからインポート

パラメータ・クラス

該当なし

ロール

プライマリおよびスタンバイ

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット

対応

該当なし

有効範囲

インスタンス

Enterprise Manager名

該当なし

脚注1SidNameプロパティで指定されたインスタンスが、以前開始されたホストとは異なるホスト(V$INSTANCEビューのHOST_NAME列から読み取られた)で開始される場合、ブローカはStaticConnectIdentifierプロパティのデフォルト値を、LOCAL_LISTENER初期化パラメータに指定したリスナーの現在のADDRESS属性に組み込むように自動的に更新します。

参照:
静的に登録されたサービスの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

8.3.42 TransportDisconnectedThreshold

構成可能なデータベース・プロパティTransportDisconnectedThresholdは、プライマリ・データベースからの最後の通信がプロパティによって指定された値を超過した場合に、ロジカル・スタンバイ、フィジカル・スタンバイまたはスナップショット・スタンバイについての警告ステータスを生成するために使用できます。プロパティ値を表す単位は秒です。値が0秒の場合、警告を生成しません。

TransportDisconnectedThreshold構成プロパティはOracle Database 11gリリース2 (11.2.0.4)以降のデータベースでのみ使用可能です。

カテゴリ

説明

データ型

数値

有効値

>=0

ブローカ・デフォルト

30秒

インポート

不要

パラメータ・クラス

該当なし

ロール

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

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット・スタンバイ

対応

該当なし

有効範囲

データベース

Enterprise Manager名

該当なし

8.3.43 TransportLagThreshold

構成可能なデータベース・プロパティTransportLagThresholdは、データベースの転送ラグがプロパティで指定された値を上回った場合に、ロジカル、フィジカルまたはスナップショットのスタンバイについての警告ステータスを生成するために使用できます。プロパティ値を表す単位は秒です。値が0秒の場合、転送ラグが存在しても警告を生成しません。

TransportLagThreshold構成プロパティはOracle Database 11gリリース2 (11.2.0.4)以降のデータベースでのみ使用可能です。

カテゴリ

説明

データ型

数値

有効値

>=0

ブローカ・デフォルト

0秒

インポート

不要

パラメータ・クラス

該当なし

ロール

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

スタンバイ・タイプ

フィジカル、ロジカルまたはスナップショット・スタンバイ

対応

該当なし

有効範囲

データベース

Enterprise Manager名

該当なし

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

この章では、様々なエラーとその解決方法について説明します。この章の内容は、次のとおりです。

- 診断情報のソース

- 一般的な問題と解決策

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

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

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

9.1 診断情報のソース

Data Guard Brokerのアクティビティに関する情報は、次の形式で提供されます。

- データベース・ステータス情報(4.9項を参照)

- Oracleアラート・ログ・ファイル
ブローカでは、ブローカ構成に含まれる各データベースのインスタンスごとのアラート・ログ・ファイルに重要情報が記録されます。Data Guardのトラブルシューティング時には、このアラート・ログ・ファイル内の情報をチェックできます。

- Data Guardのブローカ・ログ・ファイル
ブローカ構成に含まれる各データベースのインスタンスごとに、ブローカのDMONプロセスにより重要な動作およびステータス情報がブローカ・ログ・ファイルに記録されます。このファイルは、Data Guardの障害を診断する際に役立ちます。

ブローカ・ログ・ファイルは、アラート・ログと同じディレクトリに作成され、drc<$ORACLE_SID>.logという名前が付けられます。

9.2 一般的な問題と解決策

この項では、一般的な問題と解決策について説明します。この項の内容は、次のとおりです。

- ORA-16596: データベースがData Guard Broker構成の一部ではありません

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

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

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

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

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

9.2.1 ORA-16596: データベースがData Guard Broker構成の一部ではありません

ブローカに対して要求が発行されましたが、接続に使用するデータベース・インスタンスはブローカ構成に含まれていません。ブローカが実行中のデータベースのブローカ構成プロファイルを検出できない場合に、このエラーが表示されることがあります。

解決策 ブローカ構成に含まれている他のデータベースを介して構成に再接続してください。ORA-16596エラーを戻したデータベースのdb_unique_name値と名前が一致するデータベースがブローカ構成に存在することを確認してください。

構成を有効化しようとして、そのデータベースの1つのブローカ構成ファイルが意図せずに削除されていた場合や陳腐化している場合にも、この問題が発生することがあります。その場合は、データベースをブローカ構成から削除し、(プライマリ・データベースではなく)そのスタンバイ・データベースの構成ファイルを手動で削除してから、構成の有効化を再試行してください。構成が有効化された後、前に削除したスタンバイ・データベースの新しいデータベース・プロファイルを作成するには、Enterprise Managerのスタンバイ・データベースの追加ウィザードを使用し、「既存のスタンバイ・データベースの追加」オプションを選択するか、DGMGRLコマンドライン・インタフェースを使用し、ADD DATABASEコマンドを発行します。

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

Enterprise Managerの「ログ・ファイルの詳細」ページを表示すると、ログ・ファイルがプライマリ・データベースに累積され、ブローカ構成内の一部のスタンバイ・データベースにアーカイブされていないことがわかります。

解決策 問題を絞り込むには、次の操作を実行します。

- プライマリ・データベースの状態が(TRANSPORT-OFFではなく)TRANSPORT-ONであることを確認します。

- 問題のスタンバイ・データベースのデータベース・プロパティLogShippingの値がONであることを確認します。

- 監視可能なデータベース・プロパティLogXptStatusを使用して、プライマリ・データベースのREDO転送サービスのステータスをチェックします。REDO転送サービスにエラーがある場合は、エラー・メッセージを参考にして詳細なチェックおよび解決処置を判断します。次に例を示します。

- スタンバイ・データベースが使用不可能であることをエラーが示している場合は、スタンバイ・データベースを再起動する必要があります。

- リスナーが存在しないことをエラーが示している場合は、リスナーを再起動する必要があります。

- スタンバイ・データベースにローカルの宛先がないことをエラーが示している場合は、プライマリ・データベースからのアーカイブREDOログ・ファイルを格納するスタンバイ位置を設定する必要があります。

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

Enterprise Managerの「パフォーマンス」ページまたは「ログ・ファイルの詳細」ページを表示すると、スタンバイ・データベースに適用されないまま累積しているログ・ファイルが多すぎることがわかります。

解決策 アーカイブREDOログ・ファイルがスタンバイ・データベースに適用されない場合は、様々な原因が考えられます。ログ・ファイルが累積されている原因を調べて、妥当な理由を排除してください。

スタンバイ・データベースの現在のステータスが正常でない場合

- ログ適用サービスが予期せず停止しているかどうかを判別します。詳細は、ORA-16766(フィジカル・スタンバイ・データベースの場合)またはORA-16768(ロジカル・スタンバイ・データベースの場合)のエラーの説明と解決策を参照してください。

- これがロジカル・スタンバイ・データベースの場合は、障害トランザクションが発生したかどうかを確認します。

- 問題の調査中にエラーを抑止する場合は、データベースのブローカ管理を一時的に無効化できます。

参照:
DGMGRLコマンドライン・インタフェースを使用してデータベースを無効化する方法の詳細は、第7章を参照してください。

スタンバイ・データベースの現在のステータスが正常な場合

- スタンバイ・データベースの状態が(APPLY-OFFではなく)APPLY-ONであることを確認します。

- プライマリ・データベースの状態が(TRANSPORT-OFFではなく)TRANSPORT-ONであることを確認します。

参照:
データベース・プロパティLogShippingの詳細は、第8章を参照してください。

- ログ・ファイルが累積されている原因が、DelayMinsプロパティの設定値が大きすぎるためかどうかを調べます。(ログ適用サービスでは、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用が、指定した時間(分)だけ遅延されます。)

参照:
データベース・プロパティDelayMinsの詳細は、第8章を参照してください。

- 何もエラーが表示されない場合は、Enterprise Managerの「パフォーマンス」ページでアーカイブ率を適用率と比較して、適用率がアーカイブ率より低いかどうかを調べます。

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

ブローカの要求が通常のタイムアウト・パラメータ内に完了しない場合、次の処置を試行して問題を解決します。

1. ネットワークが適切に動作しているかどうか確認します。

2. 構成内のすべてのノードに対してpingを試行します。

3. 他のデータベースにより再接続を試行し、操作を再試行します。

4. VERIFYコマンドを実行し、ブローカが要求を処理できないデータベースを特定します。

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

プライマリ・データベースがフラッシュバックされる場合、構成内のスタンバイ・データベースも、スイッチオーバーまたはフェイルオーバーの実行可能なターゲットとなるように、フラッシュバックまたは再作成される必要があります。プライマリ・データベースがフラッシュバックされた場合、ブローカによりスタンバイ・データベースのエラーがレポートされます。

ブローカにより無効化されたスタンバイ・データベースの実行可能性をリストアする方法の詳細は、5.4.3項を参照してください。

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

ブローカを使用するための、これを含む様々な前提条件の詳細は、2.2項を参照してください。

3. リスナー制御ユーティリティのステータス・コマンドを使用して、静的サービス名が、構成可能なプロパティStaticConnectIdentiferの値で指定されたリスナーに登録されていることを確認します。静的サービス名が正しくリスナーに登録されている場合、次のコマンドで生成される出力に含まれます。

lsnrctl status

4. Oracle RAC環境で作業している場合、各インスタンスに対して手順1と2を繰り返し、静的サービス名がそれぞれのリスナーに正しく登録されていることを確認することをお薦めします。

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

構成に問題があるためにスイッチオーバーに失敗すると、ブローカにより検出された問題はアラート・ログ・ファイルまたはブローカ・ログ・ファイルでレポートされます(9.1項を参照してください)。通常は、スイッチオーバー用に別のデータベースを選択するか、または構成をスイッチオーバー前の状態にリストアしてから、スイッチオーバーを再試行できます。次の各項では、最も一般的ないくつかの問題からのリカバリ方法を説明します。

ファスト・スタート・フェイルオーバーが有効化されている場合、ブローカでは、ターゲット・スタンバイ・データベース以外のどのスタンバイ・データベースにもスイッチオーバーを実行できません。さらに、ターゲット・スタンバイ・データベースへのスイッチオーバーは、ターゲット・スタンバイ・データベースのV$DATABASEビュー内のFS_FAILOVER_STATUS列の値が、READYまたはSUSPENDEDのいずれかである場合にのみ可能です。

参照:
5.5.2.1項「ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行」

9.3.1 フィジカル・スタンバイ・データベースへのスイッチオーバーの失敗

元のプライマリ・データベースとターゲット・スタンバイ・データベースでアラートおよびDRCログ・ファイルを調べて、失敗した原因を確認します。次の項ではフィジカル・スタンバイ・データベースへのスイッチオーバーの失敗からリカバリする手順を、ログ・ファイルに含まれるエラーの種類に基づいて説明します。

- 元のプライマリ・データベースの変換の失敗

- ターゲット・フィジカル・スタンバイ・データベースの変換の失敗

- 新規プライマリ・データベースのオープンの失敗

9.3.1.1 元のプライマリ・データベースの変換の失敗

ブローカのスイッチオーバーが失敗して、V$DATABASEビューのDATABASE_ROLE列にPRIMARYという値が含まれている場合は、次の手順に従います。

1. ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。

2. 元のプライマリ・データベースがクローズされている場合は、オープンします。

3. アラートとDRCログ・ファイルで報告されたエラーを修正します。

4. ブローカのスイッチオーバーを再試行します。

5. ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。

V$DATABASEのDATABASE_ROLE列にPHYSICAL STANDBYという値が含まれている場合は、次のどちらかの手順を実行します。

1. ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。

2. 新規フィジカル・スタンバイ・データベース(元のプライマリ・データベース)に接続して、ブローカ構成を無効化します。

3. 新規フィジカル・スタンバイ・データベースを再起動します。

4. ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY DATABASE SQL文を使用して、新規フィジカル・スタンバイ・データベースを変換してプライマリ・データベースに戻します。

5. 新規プライマリ・データベースをオープンします。

6. ブローカ構成を再び有効化します。

7. ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。

8. ブローカのスイッチオーバーを再試行します。

または

1. ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。

2. 新規フィジカル・スタンバイ・データベース(元のプライマリ・データベース)に接続して、ブローカ構成を削除します。

3. ターゲット・スタンバイ・データベースに接続します。

4. ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY DATABASE SQL文を使用して、ターゲット・フィジカル・スタンバイ・データベースへのスイッチオーバーを完了します。

5. 新規プライマリ・データベースをオープンします。

6. 新規フィジカル・スタンバイ・データベースを停止して、再起動します。

7. 新規プライマリ・データベースに接続して、ブローカ構成を再作成します。

8. ブローカ構成を有効化します。

9. ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。

9.3.1.2 ターゲット・フィジカル・スタンバイ・データベースの変換の失敗

ブローカのスイッチオーバーが失敗して、ターゲット・フィジカル・スタンバイ・データベースのV$DATABASEビューのDATABASE_ROLE列にPHYSICAL STANDBYという値が含まれている場合は、次の手順に従います。

1. ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。

2. アラートとDRCログ・ファイルを調べて、スイッチオーバーの失敗の原因を確認して修正します。問題の修正が完了したら、次のどちらかの手順を実行します。

1. 新規フィジカル・スタンバイ・データベースに接続して、構成を無効化します。

2. 新規フィジカル・スタンバイ・データベースを停止して、再起動します。

3. ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY DATABASE SQL文を使用して、新規フィジカル・スタンバイ・データベースを変換してプライマリ・データベースに戻します。

4. 構成を再び有効化します。

5. スイッチオーバーを再試行します。

または

1. 新規フィジカル・スタンバイ・データベース(元のプライマリ・データベース)に接続して、ブローカ構成を削除します。

2. ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY DATABASE SQL文を使用して、ターゲット・フィジカル・スタンバイ・データベースへのスイッチオーバーを完了します。新規プライマリ・データベースをオープンします。

3. 新規フィジカル・スタンバイ・データベースを停止して、再起動します。

4. 新規プライマリ・データベースに接続して、ブローカ構成を再作成します。

5. ブローカ構成を有効化します。

3. ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。

9.3.1.3 新規プライマリ・データベースのオープンの失敗

新規プライマリ・データベースをオープンできないためにブローカのスイッチオーバーが失敗した場合は、次の手順に従います。

1. ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。

2. 新規フィジカル・スタンバイ・データベース(元のプライマリ・データベース)に接続して、ブローカ構成を削除します。

3. 新規プライマリ・データベースのアラート・ログ・ファイルでデータベースをオープンできない原因を調べて、それを修正してからデータベースをオープンします。

4. 新規フィジカル・スタンバイ・データベースを停止して、再起動します。

5. 新規プライマリ・データベースに接続して、ブローカ構成を再作成します。

6. ブローカ構成を有効化します。

7. ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。

9.3.2 ロジカル・スタンバイ・データベースへのスイッチオーバーの失敗

元のプライマリ・データベースとターゲット・スタンバイ・データベースでアラートおよびDRCログ・ファイルを調べて、失敗した原因を確認します。次の項ではロジカル・スタンバイ・データベースへのスイッチオーバーの失敗からリカバリする手順を、ログ・ファイルに含まれるエラーの種類に基づいて説明します。

- 元のプライマリ・データベースの変換の失敗

- ターゲット・ロジカル・スタンバイ・データベースの変換の失敗

9.3.2.1 元のプライマリ・データベースの変換の失敗

プライマリ・データベースの変換時のエラーのためにブローカのスイッチオーバーが失敗した場合は、次の手順に従います。

1. ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。

2. ブローカ構成を無効化します。

3. 『Oracle Data Guard概要および管理』に記載されている修正処理を実行します。
修正処理の実行後の場合は、次のどちらかの状況に応じて対処します。

- 元のプライマリ・データベースをプライマリ・ロールにリストアしている場合は、次の手順に従います。

1. ブローカ構成を再び有効化します。

2. ブローカのスイッチオーバーを再試行します。

- ターゲット・ロジカル・スタンバイ・データベースを手動でプライマリ・データベースにスイッチオーバーしている場合は、次の手順に従います。

1. 元のプライマリ・データベースに接続して、ブローカ構成を削除します。

2. ターゲット・ロジカル・スタンバイ・データベースに接続して、ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY SQL文を使用してそれをプライマリ・データベースに変換します。

3. 新規プライマリ・データベースに接続して、ブローカ構成を再作成します。

4. ブローカ構成を有効化します。

4. ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、有効化します。

9.3.2.2 ターゲット・ロジカル・スタンバイ・データベースの変換の失敗

ブローカのスイッチオーバーが失敗してV$DATABASEビューのDATABASE_ROLE列にPRIMARYという値が含まれている場合、もしくは列にLOGICAL STANDBYという値が含まれていてスイッチオーバーを完了する場合は、次の手順に従います。

1. ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。

2. ターゲット・ロジカル・スタンバイ・データベースに接続して、ブローカ構成を無効化します。

3. 『Oracle Data Guard概要および管理』に記載されている修正処理を実行します。

4. ブローカ構成を再び有効化します。

5. ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、有効化します。

9.3.3 スイッチオーバー操作時に発生するその他の問題

問題: REDO転送サービスの問題が原因でブローカのスイッチオーバーに失敗します。

解決策: Enterprise ManagerのData Guardの「概要」ページの情報を参照するか、DGMGRLクライアントのSHOW DATABASEコマンドを使用して、プライマリ・データベースおよびスタンバイ・データベースの状態とステータスを検証します。

Enterprise Managerを使用している場合は、次にスイッチオーバー完了後に検証操作を実行して、新しいプライマリ・データベースのアラート・ログ・ファイルを調べて、構成のステータスを検証します。

問題: Data Guard Brokerによる検証チェック中にスイッチオーバーに失敗する場合があります(スイッチオーバーに関係するデータベース上でREDO転送サービスがエラーを戻す場合など)。

解決策: スイッチオーバー用に別のデータベースを選択するか、アーカイブREDOログ・ファイルを転送して問題を修正してください。

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

フェイルオーバーを停止することは可能ですが、これはお薦めしません。ほとんどのエラーは、スタンバイ・データベースがプライマリ・ロールに遷移しているときに発生します。次のガイドラインに従って問題を修正し、ブローカのフェイルオーバーを続行します。

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

フィジカル・スタンバイ・データベースへのブローカのフェイルオーバーの失敗からリカバリする手順は、次のとおりです。

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

ターゲット・スタンバイ・データベースでアラートおよびDRCログ・ファイルを調べて、失敗した原因を確認し、それを修正します。ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH SQL文でエラーが返された場合、もしくはSQL文は正常に実行されたのにデータベースがプライマリ・データベースに変換されなかった場合は、次の手順に従います。

1. ターゲット・スタンバイ・データベースに接続し、ファスト・スタート・フェイルオーバーが有効な場合はFORCEオプションを使用して無効化します。

2. 次のどちらかの操作を実行します。

- 別のフィジカル・スタンバイ・データベースに接続して、ブローカの完全フェイルオーバーを実行します。

- ターゲット・フィジカル・スタンバイ・データベースへのブローカの即時フェイルオーバーを実行します。

3. 元のプライマリ・データベースと、回復を要求するステータス(ORA-16661)を持つその他の無効なフィジカル・スタンバイ・データベースを回復します。

4. ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。

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

ターゲット・スタンバイ・データベースでアラートおよびDRCログ・ファイルを調べて、失敗した原因を確認し、それを修正します。問題が修正可能な場合は、ブローカの即時フェイルオーバーを再試行します。それ以外の場合は、別のフィジカル・スタンバイ・データベースに接続して、ブローカの完全フェイルオーバーまたは即時フェイルオーバーを実行します。

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

1. ターゲット・スタンバイ・データベースでアラートおよびDRCログ・ファイルを調べて、失敗した原因を確認し、それを修正します。

2. ターゲット・スタンバイ・データベースに接続し、ファスト・スタート・フェイルオーバーが有効な場合はFORCEオプションを使用して無効化します。

3. ブローカのフェイルオーバーを再試行します。

4. 元のプライマリ・データベースを回復します。その他のスタンバイ・データベースはすべて、新規プライマリ・データベースのコピーから再作成されます。

5. ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。

ブローカのフェイルオーバーが引き続き失敗する場合は、Data Guard構成ですべてのデータベース上のブローカを停止します(DG_BROKER_START初期化パラメータをFALSEに設定します)。すべてのデータベースからData Guardブローカ構成ファイルを削除します。『Oracle Data Guard概要および管理』のロール遷移に関するガイドラインを使用して、手動フェイルオーバーを実行します。

注意:
DGMGRLのENABLE CONFIGURATIONおよびDISABLE CONFIGURATIONコマンドを使用すると、ブローカ構成を有効化または無効化できます。Enterprise Managerを使用して構成を無効化することはできません。前にDGMGRLを使用して無効化した構成は、Enterprise Managerを使用した場合のみ有効化できます。

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

(*) Fast-Start Failover target

Properties:
FastStartFailoverThreshold      = '60'
OperationTimeout                = '30'
FastStartFailoverLagLimit       = '30'
CommunicationTimeout            = '180'
FastStartFailoverAutoReinstate  = 'TRUE'
FastStartFailoverPmyShutdown    = 'TRUE'
BystandersFollowRoleChange      = 'ALL'

Fast-Start Failover: ENABLED

Threshold:        180 seconds
Target:           South_Sales
Observer:         observer.example.com
Lag Limit:        30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate:   TRUE

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
South_Sales  - (*) Physical standby database

(*) Fast-Start Failover target

Properties:
FastStartFailoverThreshold      = '60'
OperationTimeout                = '30'
FastStartFailoverLagLimit       = '30'
CommunicationTimeout            = '180'
FastStartFailoverAutoReinstate  = 'TRUE'
FastStartFailoverPmyShutdown    = 'TRUE'
BystandersFollowRoleChange      = 'ALL'

Fast-Start Failover: ENABLED

Threshold:        180 seconds
Target:           South_Sales
Observer:         (none)
Lag Limit:        30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate:   TRUE

Configuration Status:
SUCCESS

3. オブザーバが実際に停止していることを確認する際に、DGMGRLのSHOW CONFIGURATIONコマンドを発行する必要はないので注意してください。DGMGRLのSTOP OBSERVERコマンドを正常に完了すると、新規オブザーバを構成に関連付けることが可能になります。

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

DGMGRLの-logfileオプションを使用してオブザーバを起動できます。これにより、9.5.1項で実行したトラブルシューティング処理をすべてファイルに取得できます。次に例を示します。

% dgmgrl -logfile observer.log / "start observer"

オブザーバの出力はすべて、DGMGRLコマンドを発行した現在の作業ディレクトリ内のobserver.logファイルに記録されます。指定したログにアクセスできない場合、ログ・ファイルが指定されていない場合と同様に、オブザーバーの出力が標準出力に送信されます。

これはオブザーバの問題のトラブルシューティングに役立つだけではなく、ファスト・スタート・フェイルオーバー全般の問題のトラブルシューティングにも役立ちます。

A 変更および非推奨になった機能

この付録では、Data Guard Brokerで変更、非推奨または使用中止になった機能について説明します。この付録の内容は、次のとおりです。

- 変更があった機能

- 非推奨および使用中止になった機能

A.1 変更があった機能

この項では、Data Guard Brokerで変更があった機能について説明します。

- 変更があった一般機能

- 変更があったプロパティ

- 変更があった状態名

- リリース10.2で変更があったDGMGRL機能

A.1.1 変更があった一般機能

次の各項で、変更があった機能をリストしています。

- リリース11.2で変更があった機能

- リリース11.1で変更があった機能

- リリース10.2で変更があった機能

A.1.1.1 リリース11.2で変更があった機能

- 保護モードを最大可用性から最大保護にアップグレードする際、プライマリ・データベースの再起動は実行されません。最大パフォーマンス・モードから最大保護モードにアップグレードする場合、まず構成を最大可用性モードにアップグレードすれば、再起動を回避できます。

A.1.1.2 リリース11.1で変更があった機能

- データベースの起動動作の変更。
Data Guard Brokerでは、データベース管理者が指定した起動オプションが優先されます。これにより、Data Guard構成に属しているデータベースのみがマウントされるという現在の要件がなくなります。以前は、DBAがプライマリ・データベースまたはロジカル・スタンバイ・データベースをマウントすると、これらのデータベースがオープンされましたが、これは発生しなくなりました。したがって、プライマリまたはロジカル・スタンバイ・データベースの場合、データベースをオープンするまでData Guardの処理は開始されません。DBAは、明示的にデータベースをオープンする必要があります。

- データベースの状態と説明が変更されました。
表A-4「リリース11.1でのデータベースの状態名の変更」を参照してください。

- 既存のスタンバイを構成に追加する場合、ADD DATABASE CONNECT IDENTIFIER IS句はオプションになりました。

A.1.1.3 リリース10.2で変更があった機能

- フェイルオーバーの動作の変更
ロジカル・スタンバイ・データベースへのフェイルオーバーの後、ブローカはフェイルオーバーに直接関係していない構成内のスタンバイ・データベースをすべて無効化します。新しいプライマリ・データベースのスタンバイとして機能させるには、無効化されたデータベースを再作成する必要があります。以前は、ロジカル・スタンバイ・データベースへのフェイルオーバーにより、ブローカはフィジカル・スタンバイ・データベースのみを無効化していました。

- データベース・プロパティDelayMinsの動作の変更
DelayMinsプロパティを0(ゼロ)に設定すると、ログ適用サービスは、できるかぎり速やかにREDOデータをスタンバイ・データベースに適用します。また、スタンバイ・データベースがスタンバイREDOログを使用して構成されている場合は、リアルタイム適用も使用されます。

さらに、リリース10.1データベースでDelayMinsプロパティおよびRealTimeApplyプロパティを指定していた場合、遅延の動作が予期せずに変更される可能性があります。これは、リリース10.2でRealTimeApplyプロパティが非推奨になっているためです。

たとえば、リリース10.1データベースでDelayMinsプロパティを0(ゼロ)以外の値に設定し、RealTimeApplyプロパティをYESに設定していた場合、リアルタイム適用設定がすべての遅延設定をオーバーライドするため、遅延設定は無視されていました。ところが、リリース10.2ではRealTimeApplyプロパティが非推奨になっているため、リリース10.2データベースはRealTimeApplyプロパティの影響を受けなくなりました。そのため、REDOの適用は、DelayMinsプロパティで指定された時間に従って、予期せず遅延することがあります。

A.1.2 変更があったプロパティ

次の各項で、変更があったプロパティをリストしています。

- リリース11.2で変更があったプロパティ

- リリース11.1で変更があったプロパティ

- リリース10.2で変更があったプロパティ

A.1.2.1 リリース11.2で変更があったプロパティ

リリース11.2では、次のプロパティの動作が変更されました。

表A-1 リリース11.2で変更があったプロパティ

プロパティ名

変更の説明

StatusReport

StatusReportプロパティは、SHOW DATABASEコマンドが発行されたときに自動的に含まれるようになったので、コマンドラインで指定する必要がなくなりました。この新しい動作により、SHOW DATABASEコマンドの出力は、データベースのステータスに関するエラーまたは警告のリストが含まれるように拡張されました。Oracle RACデータベース環境では、実行中のすべてのインスタンスのステータスも含まれます。この機能はOracle Database 11gリリース2(11.2.0.2)から使用可能です。

A.1.2.2 リリース11.1で変更があったプロパティ

リリース11.1では、次のプロパティが変更されました。

表A-2 リリース11.1で変更があったプロパティ

プロパティ名

変更の説明

InitialConnectIdentifier

このプロパティは、DGConnectIdentifierに変更されました。DGConnectIdentifierの値は、いつでも、すべてのData Guardネットワーク・トラフィックに使用できます。

10g構成をOracle Databaseリリース11.1にアップグレードする場合、InitialConnectIdentifier値は、そのデータベースの新しいDGConnectIdentifier値として保持されます。Oracle RACデータベースの場合は、必ず、アップグレードする前に、InitialConnectIdentifierですべてのインスタンスにアクセスできることを確認してください。

LsbyTxnConsistency

このプロパティは、LsbyPreserveCommitOrderに変更されました。

A.1.2.3 リリース10.2で変更があったプロパティ

リリース10.2では、次のプロパティが変更されました。

表A-3 リリース10.2で変更があったプロパティ

プロパティ名

変更の説明

ApplyInstanceTimeout

デフォルト値が120秒から0(ゼロ)秒に変更されています。

ApplyParallel

新しいデフォルトはAUTOです。

DelayMins

このプロパティの使用は、スタンバイ・データベースへのREDOデータの適用を遅延させるための推奨される方法です。DelayMinsプロパティを0(ゼロ)に設定した場合、次のようになります。

- 以前に構成したDelayMins設定は無視されます。

- スタンバイ・データベースではREDOデータができるかぎり早く適用されます。スタンバイ・データベースがスタンバイREDOログを使用して構成されている場合にリアルタイム適用を使用する場合も含まれます。

構成内に複数のフィジカル・スタンバイ・データベースが存在する場合、フィジカル・スタンバイ・データベースへのフェイルオーバーの後で、「データベースをフラッシュバック」を使用することをお薦めします。「データベースをフラッシュバック」を使用することで、無効化されていたがフェイルオーバーのターゲットではなかったフィジカル・スタンバイ・データベースを回復できます。

LogArchiveMaxProcesses

有効な値の範囲が1から30になりました(以前は1から10)。

LsbyTxnConsistency

TRANSACTION_CONSISTENCYではなくSYSTEM.LOGSTDBY$PARAMETERSからPRESERVE_COMMIT_ORDERの値をインポートします。

NetTimeout

デフォルト値が30秒から180秒に変更されています。

A.1.3 変更があった状態名

表A-4に、リリース11.1で変更されたデータベースの状態名を示しています。

表A-4 リリース11.1でのデータベースの状態名の変更

データベースのタイプ

Oracle Database 11.1より前の状態名

Oracle Database 11.1での新しい状態名

プライマリ

ONLINE

TRANSPORT-ON

プライマリ

LOG-TRANSPORT-OFF

TRANSPORT-OFF

フィジカル・スタンバイ

ONLINE

APPLY-ON

フィジカル・スタンバイ

LOG-APPLY-OFF

APPLY-OFF

フィジカル・スタンバイ

READ-ONLY

なし脚注1

ロジカル・スタンバイ

ONLINE

APPLY-ON

ロジカル・スタンバイ

LOG-APPLY-OFF

APPLY-OFF

すべて

OFFLINE

なし脚注2

脚注1 リリース11.1以前には、READ-ONLY状態で、フィジカル・スタンバイ・データベースは読取り専用でオープンされました。リリース11.1では、フィジカル・スタンバイ・データベースは読取り専用でオープンされると同時にREDOを適用できるので、このデータベース状態は非推奨になりました。このため、ブローカによるこの状態変更操作は不要になりました。

脚注2 このデータベース状態は非推奨になりました。SQL*PlusのSHUTDOWNコマンドまたはDGMGRLのSHUTDOWNコマンドを使用してデータベースを停止できます。

参照:
4.2項「データベースの状態」

A.1.4 リリース10.2で変更があったDGMGRL機能

Oracle Database 10g(10.2)で変更されたData Guardコマンドライン・インタフェース(DGMGRL)コマンドは、次のとおりです。

- FAILOVER

- EDIT CONFIGURATION

- EDIT DATABASE

- SHOW CONFIGURATION

参照:
第7章「Data Guardコマンドライン・インタフェース・リファレンス」

A.2 非推奨および使用中止になった機能

次の各項で、非推奨または使用中止になった機能をリストしています。

- リリース11.2で非推奨および使用中止になった機能

- リリース11.1で非推奨および使用中止になった機能

- リリース10.2で非推奨および使用中止になった機能

A.2.1 リリース11.2で非推奨および使用中止になった機能

この項では、Data Guard Brokerで非推奨または使用中止になった機能について説明します。

- 構成可能なインスタンス固有のプロパティHostNameは非推奨になりました。これはOracle Database 11gリリース2(11.2.0.2)から有効です。

A.2.2 リリース11.1で非推奨および使用中止になった機能

この項では、Data Guard Brokerで非推奨または使用中止になった機能について説明します。

- 非推奨になったデータベース・プロパティは、次のとおりです。

- LocalListenerAddress

- フィジカル・スタンバイ・データベースのREAD-ONLY状態は非推奨になりました。

- OFFLINEおよびONLINE状態は非推奨になりました。

- ADD DATABASE ... MAINTAINED AS {PHYSICAL|LOGICAL}文は非推奨になりました。具体的には、ADD DATABASEコマンドのMAINTAINED AS句が非推奨になりました。ブローカは、スタンバイ・データベースのタイプを自動的に判別するようになりました。

A.2.2.1 リリース11.1で非推奨および使用中止になったプロパティ

表A-5 リリース11.1で非推奨および使用中止になったプロパティ

非推奨になったプロパティ

代替プロパティ(存在する場合)

LsbyTxnConsistency

LsbyPreserveCommitOrder

A.2.3 リリース10.2で非推奨および使用中止になった機能

この項では、Data Guard Brokerで非推奨または使用中止になった機能について説明します。

A.2.3.1 リリース10.2で非推奨および使用中止になったプロパティ

表A-6 リリース10.2で非推奨および使用中止になったプロパティ

非推奨になったプロパティ

代替プロパティ(存在する場合)

ApplyNext

代替なし

ApplyNoDelay

DelayMinsプロパティを0(ゼロ)に設定します。

AsyncBlocks

なし。ブロック数の指定は必要なくなりました。転送モードはData Guard構成に定義された保護モードに基づき、REDO転送サービスにより自動的に決定されます。

RealTimeApply

DelayMinsプロパティを0(ゼロ)に設定します。

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

この付録では、ブローカ構成におけるOracleデータベースおよびOracle Enterprise Managerのアップグレードまたはダウングレードのプロセスを順序立てて説明します。内容は次のとおりです。

- リリース9.2.0からリリース11.2へのアップグレード

- リリース10.nおよび11.1からリリース11.2へのアップグレード

- リリース11.2.0.1から11.2.0.2および他のパッチ・リリースへのアップグレード

- リリース11.2からのダウングレード

参照:
第2章「Oracle Data Guardのインストール」

B.1 リリース9.2.0からリリース11.2へのアップグレード

Oracle Data Guardリリース9.2.0構成を現在実行している場合は、次の手順でOracle Databaseリリース11.2にアップグレードし、ブローカ構成を再作成する必要があります。

1. Data Guard ManagerまたはDGMGRLリリース9.2.0を使用して、リリース9.2.0のブローカ構成を削除します。たとえば、DGMGRL REMOVE CONFIGURATIONコマンドを使用できます。

2. DGMGRLを使用している場合は、ALTER SYSTEM SET LOG_ARCHIVE_DEST_n=" " SQL*Plusコマンドを使用して、LOG_ARCHIVE_DEST_n初期化パラメータの設定をクリアします。

3. データベース・ソフトウェアをOracleリリース11.2にアップグレードします。使用しているオペレーティング・システムに適したOracle Databaseインストレーション・ガイドを参照してください。

4. Oracle Enterprise ManagerおよびData Guard Managerリリース9.2.0では、Oracle Data Guardリリース11.2を実行するブローカ構成を管理できません。

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

5. DGMGRLリリース9.2.0を使用している場合は、Data Guardコマンドライン・インタフェースのリリース11.2にアップグレードする必要があります。

- DGMGRLリリース9.2.0は、Oracle Data Guardリリース11.2と互換性がありません。

注意:
非Oracle RACデータベースの場合は、既存のOracle9iコマンドライン・スクリプトがOracle Database 11.2でサポートされています。非推奨になったコマンドの詳細は、付録Aを参照してください。

- DGMGRLリリース11.2は、Oracle Data Guardリリース9.2.0と互換性がありません。

注意:
Oracle Database 11.2のコマンドライン・スクリプトは、Oracle9iではサポートされません。

6. Enterprise ManagerまたはDGMGRLコマンドライン・インタフェースを起動し、ブローカ構成を再作成します。

B.2 リリース10.nおよび11.1からリリース11.2へのアップグレード

Oracle Data Guardリリース10.nまたは11.1構成を現在実行している場合は、使用しているオペレーティング・システムに適したOracle Databaseインストレーション・マニュアルを参照して、データベース・ソフトウェアをOracleリリース11.2にアップグレードできます。

注意:
リリース11.2より前は、構成ファイルは最初に作成されたときと同じセクター・サイズ(物理ブロック・サイズ)のディスクにのみ格納するように制限されていました。一般にブローカ構成では1つのセクター・サイズが使用されていたため、これは問題にはなりませんでした。任意のブローカ構成内でセクター・サイズが混在する可能性があるため、11.2のブローカ構成ファイルは、4KB以下であれば、最初に作成されたときのセクター・サイズの影響をまったく受けないようになりました。
次の手順5のアップグレード・プロセス中に、最初に作成されたときのセクター・サイズの影響を受けないように構成ファイルが変換されます。

手順1   ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。

次のDGMGRLコマンドを発行して、ファスト・スタート・フェイルオーバーを無効化します。

DGMGRL> DISABLE FAST_START FAILOVER;

手順2   実行しているバージョン10.nまたは11.1のData Guard Brokerを停止します。

構成のブローカによる管理を無効化してから、ブローカを停止します。次に例を示します。

1. 次のDGMGRLコマンドを発行して、Data Guard構成におけるデータベースのブローカによるアクティブな管理を無効化します。

DGMGRL> DISABLE CONFIGURATION;

2. 次のSQL*Plus文を発行してブローカを停止します。

SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;

手順3   現行のブローカ構成ファイルのコピーを作成します。

初期化パラメータDG_BROKER_CONFIG_FILE1およびDG_BROKER_CONFIG_FILE2で示しているように、現行のブローカ構成ファイルのコピーを作成します。

手順4   Oracle Databaseソフトウェアをリリース11.2にアップグレードします。

アップグレード手順については、使用しているオペレーティング・システムに適したOracle Databaseインストレーション・ガイドを参照してください。

Oracle Data Guardリリース11.2を実行するブローカ構成を管理および監視するには、DGMGRLコマンドライン・インタフェースもリリース11.2にアップグレードする必要があります。DGMGRLリリース11.2を使用してData Guardリリース10.nまたは11.1を管理することはできません。

注意:
既存のリリース10.nまたは11.1のDGMGRLコマンドライン・スクリプトは、リリース11.2で使用可能なDGMGRLコマンドライン・インタフェースによりサポートされています。
リリース11.nのDGMGRLコマンドライン・スクリプトは、Oracle Databaseリリース10.nによるサポートが保証されていません。

手順5   ブローカを起動します。

アップグレード後、リリース11.2のData Guard Brokerを起動します。次に例を示します。

1. 次のSQL*Plus文を発行してブローカを起動します。

SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;

2. 次のDGMGRLコマンドを発行して、Data Guard構成におけるデータベースのブローカによるアクティブな管理を有効化します。

DGMGRL> ENABLE CONFIGURATION

リリース11.2のブローカを初めて起動したとき、リリース10.nおよび11.1のブローカ構成ファイルの存在が検出され、リリース11.2で導入された新規プロパティ(ファスト・スタート・フェイルオーバーのプロパティなど)が含まれるように自動的にアップグレードされます。この自動変換は透過的かつ永続的であり、1回のみ実行されます。

注意:
手順5で行われるこの自動アップグレードで、構成ファイルはサポートされている4KBセクター以下のディスク・セクター・サイズ(物理ブロック・サイズ)のディスクに格納されます。

注意:
アップグレード前に起動されたオブザーバは自動的に停止し、アップグレードの完了後は構成を監視できなくなります。リリース11.2以上の実行中のOracleデータベースを監視するには、リリース11.2のOracleオブザーバ・ソフトウェアを使用する必要があります。

参照:
付録A「変更および非推奨になった機能」

B.3 リリース11.2.0.1から11.2.0.2および他のパッチ・リリースへのアップグレード

Data Guard Brokerの構成では、あるパッチ・リリースから次のパッチ・リリースへのアップグレード・プロセス(たとえば、11.2.0.1から11.2.0.2または11.2.0.2から11.2.0.3など)は、リリース10.nおよび11.1からRelease 11.2へのアップグレードに関する項で説明されているプロセスと同じです。ブローカはアップグレード前に無効にし、アップグレード終了後に再度有効化する必要があります。

B.4 リリース11.2からのダウングレード

リリース11.2へのアップグレードを完了していて、以前のリリースにダウングレードする場合は、次の手順でデータベース・リリースをダウングレードし、ブローカ構成を再作成する必要があります。

1. リリース11.2のEnterprise ManagerまたはDGMGRLを使用して、リリース11.2のブローカ構成を削除します。たとえば、DGMGRL REMOVE CONFIGURATIONコマンドを使用できます。

2. Oracle Databaseソフトウェアを以前のOracleリリースにダウングレードします。使用しているオペレーティング・システムに適したOracle Databaseのマニュアルを参照してください。

3. Data Guard Brokerをリリース10.nまたは11.1にダウングレードするには、次のようにします。

- リリース11.2へのアップグレード後にブローカ構成に変更を加えていないことが明白である場合、アップグレード手順で作成したブローカ構成ファイルをコピーできます(B.2項を参照)。続いて、Enterprise ManagerまたはDGMGRLコマンドライン・インタフェースを起動し、そのコピーの作成時点で存在したとおりにブローカ構成を再度有効化します。

- あるいは、Enterprise ManagerまたはDGMGRLコマンドライン・インタフェースを起動し、ブローカ構成を再作成できます。

4. Data Guard BrokerをOracleリリース9.2.0にダウングレードするには、次のようにします。

- Enterprise Managerを使用していた場合、引き続きOracle Enterprise Managerリリース10.2を使用して、リリース9.2.0のブローカ構成を管理できます。また、Oracle Enterprise Managerリリース9.2.0を再インストールして、Data Guard Managerにダウングレードすることもできます。

- Enterprise Manager、Data Guard ManagerまたはDGMGRLコマンドライン・インタフェースを起動し、ブローカ構成を再作成します。

用語集

適用インスタンス

Oracle Real Application Clusters(Oracle RAC)データベース環境で、アーカイブREDOデータをスタンバイ・データベースに適用する1つのインスタンスです。

ブローカ

Data Guard構成の作成、制御および監視に必要な、複雑な操作の大半を自動化および簡素化する分散管理フレームワーク。

ブローカ構成

Data Guard構成のプライマリ・データベースとスタンバイ・データベース(REDO転送サービスとログ適用サービスを含む)を論理的にグループ化したものです。

「Data Guard構成」も参照してください。

その他のスタンバイ・データベース

スイッチオーバー操作またはフェイルオーバー操作の対象でない、またはこれらの操作に直接関係のないスタンバイ・データベース。

構成オブジェクト

データベース・オブジェクトの名前付きの集合。Data Guard構成を抽象化したものです。

データベース・ガード

データベース・ガードは、ロジカル・スタンバイ・データベース内の表を変更可能かどうかを制御します。

データベース・オブジェクト

Data Guard構成内のプライマリ・データベースまたはスタンバイ・データベースに対応する名前付きオブジェクト。ブローカは、このオブジェクトを使用して単一データベースの状態を管理および制御し、プロパティをデータベースに関連付けます。

Data Guardコマンドライン・インタフェース

Data Guardコマンドライン・インタフェース(DGMGRL)を使用すると、DGMGRLのプロンプトまたはスクリプトからData Guard構成を制御および監視できます。

Data Guard構成

予定されている停止時間(定期点検など)に加え、予定外のイベント(人為的エラー、環境災害、データの破損など)による損害を回避または最小限に抑える分散コンピュータ・システム。

「ブローカ構成」も参照してください。

Data Guard環境

プライマリ・データベースおよびスタンバイ・データベースの物理構成。環境は、次の項目を含む多数の要因に依存します。

- プライマリ・データベースと関連付けられているスタンバイ・データベースの数

- データベースで使用されるホスト・システムの数

- データベースで使用されるマシンのディレクトリ構造

- ネットワーク構成

- REDO転送サービス

- ログ適用サービス

Data Guard環境には、DBAが手動で管理する方法、Enterprise ManagerまたはData Guardコマンドライン・インタフェース(DGMGRL)を使用して自動的に管理する方法、これらすべてを組み合せて行う方法があります。

デフォルト状態

構成のブローカ管理を有効化するときに、データベース・オブジェクトが実行される初期のランタイム状態。実際のデフォルト状態は、データベースが実行中のロール(プライマリまたはスタンバイ)によって異なることもあります。

「インテンド状態」も参照してください。

フェイルオーバー

スタンバイ・データベースをプライマリ・データベースのロールに変更し、元のプライマリ・データベースを無効化する操作。

「ファスト・スタート・フェイルオーバー」および「手動フェイルオーバー」も参照してください。

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

プライマリ・データベースが使用できなくなった場合にフェイルオーバーを自動的に有効化します。ファスト・スタート・フェイルオーバーを有効化すると、ブローカはフェイルオーバーの必要性を判断し、指定されたスタンバイに自動的、迅速かつ確実にフェイルオーバーを実行します。このとき、フェイルオーバーの起動に手動の手順を実行する必要はありません。

「手動フェイルオーバー」も参照してください。

インスタンス・オブジェクト

名前付きオブジェクト。データベース・オブジェクトは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つのプライマリ・データベースは、複数のスタンバイ・データベースをサポートできます。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

スタンバイ・データベースの追加ウィザード

ブローカ構成の作成, 3.4

定義, 1.5.1

概要, 1.5.1

追加

ブローカ構成に対するスタンバイ・データベース, 6.2

ALTER SYSTEM文

ブローカの起動, 6.1

変更

プロパティ

データベース, 6.7.1.1

状態

データベース, 6.7.1.2, 6.7.1.3

AlternateLocationプロパティ, 8.3.1

ログ適用サービスの設定, 4.4.4

アプリケーション統合, 1.2 適用エラー

管理, 4.5.5

適用インスタンス, 4.5.7

フェイルオーバー, 4.5.7

PreferredApplyInstanceプロパティ, 4.5.7.1

選択, 4.5.7.1

ApplyInstanceTimeoutプロパティ, 4.5.7.2, 8.3.2 ApplyLagThresholdプロパティ, 8.3.3, 8.3.3 ApplyParallelプロパティ, 4.5.2, 8.3.4 アーキテクチャ

Data Guard Broker, 1.4

ARCHIVE_LAG_TARGET初期化パラメータ

ブローカ構成での設定, 8.3.5

アーカイブREDOログ

接続先および構成パラメータ, 3.1

Data Guard構成, 3.1

プライマリ・データベースの設定, 2.2

ArchiveLagTargetプロパティ, 8.3.5 ASYNC REDO転送サービス, 4.4.2 自動ストレージ管理(ASM)

ASMを使用したスタンバイ・データベースの作成, 2.2

B

バックグラウンド・プロセス

DMON, 1.6.1

バナー

DGMGRLコマンドライン・インタフェース出力からの抑止, 7.1.1

スイッチオーバー実行前の考慮事項, 5.3.1 DGMGRLの使用前, 6.1 メリット

Data Guard Broker, 1.2

高可用性, 1.2

スケーラビリティ, 1.2

Oracle Real Application Clustersを使用, 1.2

バイナリ構成ファイル, 1.6.2 Bindingプロパティ, 8.3.6 ブローカ

コンポーネント, 1.4

構成, 1.1.1

Data Guard構成ファイル, 1.6.2

drc*ログ・ファイル, 9.1

インストール, 2.2

概要, 1.1.2

データベースの管理, 4.1

ユーザー・インタフェース, 1.5

ブローカ構成

メリット, 1.2

ロールの変更, 3.4

コンポーネント, 3.1

作成, 6.2, 6.2, 7.2

Data Guard構成ファイル, 1.6.1

データベース・オブジェクト, 1.3

データベース・プロファイル, 1.3

データベースの無効化, 3.5, 7.2

メタデータを削除する効果, 7.2

有効化, 6.4, 7.2

データベースの有効化, 3.4, 3.5, 6.4, 7.2

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

健全性, 1.6.1, 3.6

インスタンス・オブジェクト, 1.3

ライフ・サイクル, 3.4

管理, 1.3, 1.5.1, 1.5.2, 1.6.2

監視, 6.12

オブジェクト, 1.3

Oracle Net Services構成, 1.2, 1.5.1

概要, 3.1

プロパティ, 4.3

保護モード, 7.2

保護モードの設定, 4.6.1

ステータス・モード, 3.6

サポート対象, 1.3, 3.1, 3.1

その他のスタンバイ・データベース, 5.3

構成への再統合, 5.4.2.1

BystandersFollowRoleChangeプロパティ, 8.1.1

C

CFS

「クラスタ・ファイル・システム」を参照

変更があった機能, A 変更

プロパティ

ブローカ構成内のデータベース, 3.4, 4.3.2

ロール

ブローカ構成内, 3.4

状態

ブローカ構成内のデータベース, 4.2.1

ブローカ構成内のデータベース, 6.7

「編集」も参照 クラスタ・ファイル・システム(CFS)

ブローカ構成ファイル, 3.2.2.1

コマンド・プロンプト

DGMGRLコマンドライン・インタフェース出力からの抑止, 7.1.1

コマンドライン・インタフェース

「Data Guardコマンドライン・インタフェース(DGMGRL)」を参照

CommunicationTimeoutプロパティ, 8.1.2 COMPATIBLE初期化パラメータ

設定要件, 2.2

完全フェイルオーバー, 5.4.1, 7.2 コンポーネント

ブローカ, 1.4

Data Guard構成, 3.1

構成可能なプロパティ, 4.3

AlternateLocation, 8.3.1

ApplyInstanceTimeout, 8.3.2

ApplyLagThreshold, 8.3.3, 8.3.3

ApplyParallel, 8.3.4

ArchiveLagTarget, 8.3.5

バインド, 8.3.6

データベース, 4.3.2, 4.3.2, 8.3

DbFileNameConvert, 8.3.7

DelayMins, 8.3.8

DGConnectIdentifier, 8.3.9

FastStartFailoverTarget, 8.3.10

LogArchiveFormat, 8.3.11

LogArchiveMaxProcesses, 8.3.12

LogArchiveMinSucceedDest, 8.3.13

LogArchiveTrace, 8.3.14

LogFileNameConvert, 8.3.15

LogShipping, 8.3.16

LogXptMode, 8.3.17

LsbyASkipCfgPr, 8.3.18

LsbyASkipErrorCfgPr, 8.3.19

LsbyASkipTxnCfgPr, 8.3.20

LsbyDSkipCfgPr, 8.3.21

LsbyDSkipErrorCfgPr, 8.3.22

LsbyDSkipTxnCfgPr, 8.3.23

LsbyMaxEventsRecorded, 8.3.24

LsbyMaxServers, 8.3.26

LsbyMaxSga, 8.3.25

LsbyPreserveCommitOrder, 8.3.27

LsbyRecordAppliedDdl, 8.3.28

LsbyRecordSkipDdl, 8.3.29

LsbyRecordSkipErrors, 8.3.30

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

MaxConnections, 8.3.31

MaxFailure, 8.3.32

NetTimeout, 8.3.33

PreferredApplyInstance, 8.3.35

RedoCompression, 8.3.36

ReopenSecs, 8.3.37

SidName, 8.3.38

StandbyArchiveLocation, 8.3.39

StandbyFileManagement, 8.3.40

StaticConnectIdentifier, 8.3.41

TransportDisconnectedThreshold, 8.3.42, 8.3.42

TransportLagThreshold, 8.3.43, 8.3.43

構成ファイル

ファスト・スタート・フェイルオーバー構成(fsfo.dat)ファイル, 5.5.7.6

「Data Guard構成ファイル」も参照

構成プロパティ

BystandersFollowRoleChange, 8.1.1

CommunicationTimeout, 8.1.2

ExternalDestination1, 8.1.3

ExternalDestination2, 8.1.4

FastStartFailoverAutoReinstate, 8.1.5

FastStartFailoverLagLimit, 8.1.6

FastStartFailoverPmyShutdown, 8.1.7

FastStartFailoverThreshold, 8.1.8

ObserverOverride, 8.1.9, 8.1.9

ObserverReconnect, 8.1.10, 8.1.10

OperationTimeout, 8.1.11

PrimaryLostWriteAction, 8.1.12, 8.1.12

TraceLevel, 8.1.13

CONNECTコマンド, 6.2, 7.2 接続

Data Guard Broker構成に必要な権限, 7.1.3

オブザーバの起動, 6.6

プライマリ・データベース, 6.2

制御

使用可能なSGAメモリー, 4.5.3

トランザクションのコミット順序, 4.5.3

CREATE CONFIGURATIONコマンド, 6.2, 7.2 作成

ブローカ構成, 6.2, 6.2, 6.2, 7.2

スタンバイ・データベースの追加ウィザードを使用, 3.4

スタンバイ・データベース, 3.4

D

Data Guard

トラブルシューティング, 9

Data Guard Broker

変更があった機能, A

非推奨になった機能, A

「ブローカ」も参照

Data Guardコマンドライン・インタフェース

コマンド

ENABLE FAST_START FAILOVER, 7.2

SET STATE, 4.5.7.1

DG_BROKER_START初期化パラメータ, 2.2 データベースの有効化, 6.4 概要, 1.1.2, 1.5.2 Data Guardコマンドライン・インタフェース(DGMGRL)

出力からのバナー, 7.1.1

コマンド

CONNECT, 7.2

CREATE CONFIGURATION, 7.2

DISABLE CONFIGURATION, 7.2

DISABLE DATABASE, 7.2

DISABLE FAST_START FAILOVER, 5.5.5, 7.2

DISABLE FAST_START FAILOVER CONDITION, 7.2

EDIT CONFIGURATION(プロパティ), 7.2

EDIT CONFIGURATION(保護モード), 7.2

EDIT DATABASE(プロパティ), 7.2

EDIT DATABASE(名前の変更), 7.2

EDIT DATABASE(状態), 7.2

EDIT INSTANCE(AUTO PFILE), 7.2

EDIT INSTANCE(プロパティ), 7.2

ENABLE CONFIGURATION, 7.2

ENABLE DATABASE, 7.2

ENABLE FAST_START FAILOVER CONDITION, 7.2

EXIT, 7.2

FAILOVER, 6.9

HELP, 7.2

QUIT, 7.2

REMOVE CONFIGURATION, 7.2

REMOVE DATABASE, 7.2

REMOVE INSTANCE, 7.2

SHOW CONFIGURATION, 7.2

SHOW DATABASE, 7.2

SHOW FAST_START FAILOVER, 7.2

SHOW INSTANCE, 7.2

SHUTDOWN, 7.2

STARTUP, 7.2

SWITCHOVER, 6.8, 7.2

構成の作成, 6.2 DG_BROKER_START初期化パラメータ, 7.1.3 構成の有効化, 6.4 FSFO.DATファイルの作成, 7.2 ブローカ構成の監視, 6.12 定期的な管理タスクの実施, 6.7 前提条件, 6.1 重要なデータベース・プロパティの設定, 6.3 スタンバイREDOログ・ファイルの設定, 4.6.1 単一コマンド・モード, 7.1.1 起動, 6.2, 7.1 停止, 7.2 文字列値, 7.1.3 コマンドの概要, 7.1.2 コマンド・プロンプトの抑止, 7.1.1 Data Guard構成ファイル

Oracle RACデータベース, 3.2.2

CFS領域, 3.2.2.1

サーバー・パラメータ・ファイルとの一貫性がない値, 8.2.2

RAWデバイス, 3.2.2.3

DMONプロセスに関連, 1.6.1

名前の変更, 1.6.2

設定, 3.2

Data Guard構成

自動作成, 1.2

バックグラウンド, 3.1

サポート対象, 3.1

Data Guardモニター(DMON), 1.6

Oracleデータベースとの相互作用, 1.6.1

構成データのメンテナンス, 1.6.2

オブジェクトの管理, 3.1, 3.4, 6.4

Oracleデータベースのバックグラウンド・プロセス, 1.6.1

概要, 1.6.1

オブジェクトの削除, 6.7.3

DG_BROKER_STARTパラメータを使用した起動, 3.3

双方向ネットワーク通信, 1.6.1

データ保護モード

「保護モード」を参照

データベース・リソース

監視, 1.2

データベース

状態の変更, 6.7

接続, 6.2

作成およびブローカ構成への追加, 1.5.1

依存性, 4.2

管理の無効化, 7.2

条件

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

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

スイッチオーバー, 5.3

有効化, 6.4 健全性, 4.9 ブローカ管理のためのインストール, 2.2 監視可能なデータベース・プロパティ, 4.3.1, 8.2 ネットワーク設定, 1.6.1, 2.2 オブジェクト, 1.3

定義, 1.3

ブローカ構成, 1.3

ブローカ構成の前提条件, 2.2 プロパティ, 1.5.1, 4.3.2, 8.3 プロパティ管理, 1.6.3 ロール遷移後の再有効化, 5.4.3 削除

ブローカ構成から, 6.7.3

再起動

ファスト・スタート・フェイルオーバーの後, 5.5.9

停止

ファスト・スタート・フェイルオーバーへの影響, 5.5.2.1, 5.5.2.3, 5.5.9

状態, 4.2

依存性, 4.2

遷移, 4.2.1

ステータス, 4.9 DB_FILE_NAME_CONVERT初期化パラメータ

初期化パラメータ

ブローカ構成でのDB_FILE_NAME_CONVERTの設定, 8.3.7

DBA_LOGSTDBY_EVENTS表

管理, 4.5.6

DbFileNameConvertプロパティ, 8.3.7 遅延

DelayMinsプロパティによるREDOデータの適用, 4.5.1

DelayMinsプロパティ, 8.3.8

ログ適用サービスの遅延, 4.5.1

非推奨になった機能, A 接続先

アーカイブREDOログ・ファイルのパラメータ, 3.1

viewing the LogXptStatusプロパティ, 8.2.3

DG_BROKER_CONFIG_FILEnファイル, 1.6.2, 3.2.2

CFS領域, 3.2.2.1

RAWデバイス, 3.2.2.3

DG_BROKER_START初期化パラメータ, 2.2, 6.1, 7.1.3 DGConnectIdentifierプロパティ, 8.3.9 DGMGRL

データベースの回復, 5.4.3.1

DGMGRLコマンド

FAILOVER, 7.2

SWITCHOVER, 7.2

診断情報

ソース, 9.1

DISABLE CONFIGURATIONコマンド, 7.2

例, 6.7.2.1

DISABLE DATABASEコマンド, 7.2

例, 6.7.2.2

DISABLE FAST_START FAILOVERコマンド, 5.5.5, 7.2 DISABLE FAST_START FAILOVER CONDITIONコマンド, 7.2 無効化

ブローカ構成, 6.7.2, 7.2

スタンバイ・データベースのブローカ管理, 7.2

データベース, 3.5, 6.7.2.1, 6.7.2.2

ファスト・スタート・フェイルオーバー, 5.5.5, 7.2

スタンバイ・データベース, 5.5.5

各DISABLEコマンドも参照 障害時の保護

メリット, 1.2

表示

構成情報, 7.2

DGMGRLコマンドのヘルプ, 7.2

プロパティ, 4.3

分散管理フレームワーク, 1.1.2 DMON

「Data Guardモニター(DMON)」を参照

ダウングレード

Data Guard, B.4

Oracle Enterprise Manager, B.4

保護モード, 4.6.2.1

drc*ログ・ファイル

ブローカ診断情報, 9.1

回復時, 5.5.4.1

失敗した回復の記録, 5.5.8.3

E

EDIT CONFIGURATION(プロパティ)コマンド, 7.2

EDIT CONFIGURATION(保護モード)コマンド, 7.2

EDIT DATABASE(プロパティ)コマンド, 7.2

例, 6.7.1.1

EDIT DATABASE(名前の変更)コマンド, 7.2 EDIT DATABASE(状態)コマンド, 7.2

例, 6.7.1.2

EDIT INSTANCE(AUTO PFILE)コマンド, 7.2 EDIT INSTANCE(プロパティ)コマンド, 7.2 編集

構成可能なプロパティ, 7.2

データベース・インスタンス, 7.2, 7.2

データベース名, 7.2

データベース・プロパティ, 7.2

データベースの状態, 7.2

保護モード, 7.2

スイッチオーバーによる影響, 5.3.3 電子メール

イベントのレポート, 1.5.1

ENABLE CONFIGURATIONコマンド, 6.4, 7.2 ENABLE DATABASEコマンド, 7.2 ENABLE FAST_START FAILOVERコマンド, 7.2 ENABLE FAST_START FAILOVER CONDITIONコマンド, 7.2 有効化

ブローカ構成, 3.4, 6.4, 6.4, 6.4

ブローカ構成内のデータベース, 3.5

ファスト・スタート・フェイルオーバー, 5.5.1, 5.5.2

各ENABLEコマンドも参照

Enterprise Editionデータベース

インストール, 2.1

Enterprise Manager

ファスト・スタート・フェイルオーバー・ウィザード

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

ウィザード

スタンバイ・データベースの自動作成, 1.1.2

エラー・メッセージ

ORA-16795, 5.4.3, 5.4.3

ERRORステータス, 3.6 イベント

管理

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

Oracle Enterprise Managerを使用した監視, 1.1.2 Oracle Enterprise Manager, 1.2 レポート, 1.5.1 応答, 1.2 EXITコマンド, 7.2

「QUITコマンド」も参照

ExternalDestination1プロパティ, 8.1.3 ExternalDestination2プロパティ, 8.1.4

F

フェイルオーバー

スタンバイ・データベースへのフェイルオーバー, 7.2

Oracle Enterprise Manager, 1.5.1

FAILOVERコマンド, 6.9, 7.2 フェイルオーバー

FastStartFailoverTargetプロパティ, 6.6

メリット, 1.2

ブローカの作業, 5.4.2.1

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

完全, 5.4.2.1

定義済, 5.1

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

データ保護モードへの影響, 5.5.1

V$DATABASE, 5.5.4.1

即時, 5.4.2.2 管理, 5

ファスト・スタート, 5.5

手動, 5.4

手動

完全オプション, 5.4.1

データ保護モードへの影響, 5.4.2

即時オプション, 5.4.1

無効化されたデータベースの再有効化, 5.4.2.1 手動による起動, 5.4.2 DGMGRLの使用, 6.9 障害

オブザーバ, 5.5.7.3

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

fsfo.datファイル内の構成情報, 5.5.7.6

定義済, 5.5

オブザーバとしてのDGMGRLクライアント, 1.5.2

無効化, 5.5.5, 5.5.5

手動フェイルオーバーを実行, 5.5.5

有効化, 5.5.2, 7.2 インスタンス障害, 5.5.2.1 オブザーバによる監視, 5.5.2.1 オブザーバの監視, 5.5.2.1 オブザーバの概要, 5.5 有効化されている場合の手動フェイルオーバーの実行, 5.5.2.4 有効化されている場合のスイッチオーバーの実行, 5.5.2.4 V$DATABASEの問合せ, 5.5.2.2 元のプライマリ・データベースの回復, 5.5.8 要件, 5.5.1 停止後のデータベースの再起動, 5.5.9 FastStartFailoverTargetプロパティの設定, 5.5.2, 5.5.2, 6.6 FastStartFailoverThresholdプロパティの設定, 5.5.2 強制終了, 5.5.2.1, 5.5.2.3 データベースの停止, 5.5.9 Oracle RACデータベース・インスタンス, 5.5.2.1 監視されない, 5.5.7.3 環境の検証, 5.5.2 フェイルオーバー構成統計の表示, 5.5.4.1 FastStartFailoverAutoReinstateプロパティ, 8.1.5 FastStartFailoverLagLimitプロパティ, 8.1.6 FastStartFailoverPmyShutdownプロパティ, 8.1.7 FastStartFailoverTargetプロパティ, 8.3.10

設定, 5.5.2, 5.5.2, 6.6

FastStartFailoverThresholdプロパティ, 8.1.8

設定, 5.5.2

ファイル

サーバー・パラメータ・ファイルのネーミング, 1.6.3

フラッシュバック・データベース

データベースの回復, 5.4.3.1

フェイルオーバー後に使用, 5.4.2.1

フラッシュバック・ログ

障害が発生したプライマリ・データベースの回復, 5.4.3.1

FORCEオプション

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

手動フェイルオーバーの実行, 5.5.5

FS_FAILOVER_OBSERVER_HOST列

V$DATABASEビュー, 5.5.7.2

FS_FAILOVER_OBSERVER_PRESENT列

V$DATABASEビュー, 5.5.7.2

FS_FAILOVER_STATUS列

V$DATABASEビュー

失敗した回復, 5.5.4.1

FSFO.DATファイル

概要, 5.5.7.6

START OBSERVERコマンド, 7.2

H

健全性チェック, 1.2

監視, 1.6.1, 1.6.1

プライマリ・データベース, 4.9

スタンバイ・データベース, 4.9

構成ステータス, 3.6

HELPコマンド, 7.2 高可用性

メリット, 1.2

データ保護のレベル, 4.6, 8.3.17

LogXptModeプロパティ, 8.3.17

ファスト・スタート・フェイルオーバー後のリストア, 5.5.8

I

即時フェイルオーバー, 5.4.1, 7.2

InconsistentLogXptPropsプロパティ, 8.2.1

InconsistentPropertiesプロパティ, 8.2.2

スケーラビリティの向上

メリット, 1.2

初期化パラメータ

COMPATIBLE, 2.2

データベースの構成可能なプロパティ, 4.3.2

DG_BROKER_CONFIG_FILEn, 3.2.2

DG_BROKER_START, 2.2, 6.1

動的, 4.3.2

一貫性のない, 8.2.2

LOG_ARCHIVE_DEST_n, 4.4.5

静的, 4.3.2

「サーバー・パラメータ・ファイル」も参照

インストール

ARCHIVELOGモードの設定, 2.2

Data Guard, 2.1

Oracle Enterprise Manager, 2.1

Oracle Instant Client, 2.1, 7.2

前提条件, 2.2

インスタンス

障害, 5.5.2.1

オブジェクト

ブローカ構成, 1.3

削除, 7.2, 7.2, 7.2 停止, 7.2 起動, 7.2 インテンド状態

構成の健全性チェック, 3.6

起動

Data Guardコマンドライン・インタフェース, 6.2

L

ブローカ構成のライフ・サイクル, 3.4

ログ適用サービス

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

パラレル適用, 4.5.2

適用インスタンス, 4.5.7

構成, 1.5.1

Data Guard構成, 3.1

REDOデータの適用の遅延, 4.5.1

遅延, 8.3.8

Oracle RACデータベース, 4.5.7

管理, 4.5

適用インスタンスの選択, 4.5.7.1

確認, 1.2

ログ・ファイル

ブローカ, 5.5.8.3

FSFO.DAT

作成, 7.2

LOG_ARCHIVE_DEST_n初期化パラメータ

REDO転送サービスの設定, 4.4.5

DELAY属性の設定, 8.3.8

ENABLEおよびDEFER属性の設定, 8.3.16

MANDATORYまたはOPTIONAL属性の設定, 8.3.6

LOG_ARCHIVE_FORMAT初期化パラメータ, 8.3.11 LOG_ARCHIVE_MAX_PROCESSES初期化パラメータ, 8.3.12 LOG_ARCHIVE_MIN_SUCCEED初期化パラメータ, 8.3.13 LOG_ARCHIVE_TRACE初期化パラメータ

LogArchiveTraceプロパティの設定, 8.3.14

LOG_FILE_NAME_CONVERT初期化パラメータ

LogFileNameConvertプロパティの設定, 8.3.15

LogArchiveFormatプロパティ, 8.3.11 LogArchiveMaxProcessesプロパティ, 8.3.12 LogArchiveMinSucceedDestプロパティ, 8.3.13 LogArchiveTraceプロパティ, 8.3.14 LogFileNameConvertプロパティ, 8.3.15 ロジカル・スタンバイ・データベース

SQL Applyエラー処理, 4.5.5

SQL Applyフィルタ, 4.5.4

イベントの管理, 4.5.6

SQL Apply, 4.5.3

状態遷移, 4.2.1

プライマリ・ロールへのスイッチオーバー, 5.3

LogShippingプロパティ, 8.3.16 LogXptModeプロパティ, 8.3.17 LogXptStatusプロパティ, 8.2.3 LsbyASkipCfgPrプロパティ, 8.3.18 LsbyASkipErrorCfgPrプロパティ, 4.5.5, 8.3.19 LsbyASkipTxnCfgPrプロパティ, 8.3.20 LsbyDSkipCfgPrプロパティ, 8.3.21 LsbyDSkipErrorCfgPrプロパティ, 4.5.5, 8.3.22 LsbyDSkipTxnCfgPrプロパティ, 8.3.23 LsbyFailedTxnInfoプロパティ, 8.2.4 LsbyMaxEventsRecordedプロパティ, 8.3.24 LsbyMaxServersプロパティ, 8.3.26 LsbyMaxSgaプロパティ, 4.5.3, 8.3.25 LsbyParametersプロパティ, 8.2.5 LsbyPreserveCommitOrderプロパティ, 4.5.3, 8.3.27 LsbyRecordAppliedDdlプロパティ, 8.3.28 LsbyRecordSkipDdlプロパティ, 8.3.29 LsbyRecordSkipErrorsプロパティ, 8.3.30 LsbySkipTableプロパティ, 8.2.6 LsbySkipTxnTableプロパティ, 8.2.7

M

管理

メリット, 1.2

モデル, 1.3

Oracle Enterprise Manager, 1.5.1

管理

ブローカ構成, 3, 6

適用エラー, 4.5.5

データベース, 4

DBA_LOGSTDBY_EVENTS表, 4.5.6

イベント

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

ファスト・スタート・フェイルオーバー, 5.5 ローカル操作, 1.1.2 ログ適用サービス, 4.5 手動フェイルオーバー, 5.4 ブローカ構成のオブジェクト, 1.3 フィジカル・スタンバイ・データベースでのパラレル適用, 4.5.2 リモート操作, 1.1.2 ロール, 5

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

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

スイッチオーバー, 5.3

スイッチオーバー, 5.3 MANDATORY属性

Bindingプロパティでの設定, 8.3.6

手動フェイルオーバー, 1.2, 5.1

完全オプション, 5.4.1

保護モードへの影響, 4.6.2.3

即時オプション, 5.4.1

ファスト・スタート・フェイルオーバーが有効化されている場合の実行, 5.5.2.4, 5.5.5

起動, 5.4.2

手動ロール変更

ファスト・スタート・フェイルオーバーが有効化されている場合の実行, 5.5.2.4

MaxConnectionsプロパティ, 8.3.31 MaxFailureプロパティ, 8.3.32 最大可用性, 1.2, 3.4, 8.3.17 最大データ保護, 1.2, 3.4, 8.3.17 最大パフォーマンス, 1.2, 3.4, 8.3.17 最大可用性

データ保護モード, 4.6.1

最大パフォーマンス

データ保護モード, 4.6.1

最大保護

データ保護モード, 4.6.1

監視可能なプロパティ, 4.3

データベース, 4.3.1

InconsistentLogXptProps, 8.2.1

InconsistentProperties, 8.2.2

LogXptStatus, 8.2.3, 8.2.3

LsbyFailedTxnInfo, 8.2.4, 8.2.4

LsbyParameters, 8.2.5

LsbySkipTable, 8.2.6

LsbySkipTxnTable, 8.2.7

RecvQEntries, 8.2.8

SendQEntries, 8.2.9

TopWaitEvents, 8.2.10

監視

ブローカ構成, 1.6.1, 6, 6.12

ローカルおよびリモート・データベース, 1.2

オブザーバ

ファスト・スタート・フェイルオーバー環境, 5.5.2.1

Oracle Enterprise Managerパフォーマンス・ページ, 3.4 コマンドライン・インタフェースを使用, 1.5.2

N

NetTimeoutプロパティ, 8.3.33

ネットワーク

Data Guard構成, 3.1

ファイルの設定, 2.2

双方向通信, 1.6.1

NORMALステータス, 3.6

O

オブジェクト

ブローカ構成, 1.3, 3.1

無効化, 6.7.2

データベースのプロパティ, 1.6.3

関係, 1.3

オブザーバ, 5.5

FastStartFailoverThresholdプロパティ, 5.5.2

構成に接続, 6.6

ローカル・コンピュータへの接続, 5.5.7.2

検出

データベース停止, 5.5.2.1, 5.5.2.3

インスタンス障害, 5.5.2.1

障害, 5.5.7.3 ホスト・マシン名の検索, 5.5.7.2 Oracle Instant Clientキットのインストール, 2.1, 7.2 接続の消失, 5.5.7.3 ファスト・スタート・フェイルオーバー構成情報のメンテナンス, 5.5.7.6 監視, 5.5.2.1, 5.5.2.1 停止, 5.5.9 接続資格証明に対するOracleウォレットの使用, 7.2 ObserverOverrideプロパティ, 8.1.9, 8.1.9 ObserverReconnectプロパティ, 8.1.10, 8.1.10 操作

完全フェイルオーバー, 7.2

ブローカ管理の無効化

保護モードへの影響, 4.6.2.4

ダウングレード

保護モードへの影響, 4.6.2.1

保護モードへの影響, 4.6.2 ブローカ管理の有効化

保護モードへの影響, 4.6.2.4

フェイルオーバー, 6.9 即時フェイルオーバー, 7.2 手動フェイルオーバー

保護モードへの影響, 4.6.2.3

構成からのデータベースの削除

保護モードへの影響, 4.6.2.5

OperationTimeoutプロパティ, 8.1.11 OPTIONAL属性

Bindingプロパティでの設定, 8.3.6

ORA-16661メッセージ

データベースの回復, 5.4.3, 5.4.3, 5.4.3.1

ORA-16795メッセージ

データベースの再作成, 5.4.3

Oracle Clusterware, 1.2

Oracle RACデータベースのインスタンス, 1.2

Data Guard Brokerとの統合, 1.2

障害インスタンスのリカバリ, 1.2

Oracle Enterprise Manager, 1.5.1

スタンバイ・データベースの追加ウィザード, 1.5.1

データベース・プロパティ・ページ, 1.5.1

ダウングレード, B.4

イベント管理システム, 1.2

統合, 1.5.1

Data Guardモニターとの統合, 1.5.1

概要, 1.1.2, 1.4

Oracle Net Servicesの構成変更, 1.2, 1.5.1

イベントの監視, 1.1.2

パフォーマンス・ツールとグラフ, 1.5.1

スタンバイREDOログ・ファイルの設定, 4.6.1

アップグレード, B.1

ウィザード

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

Oracle Instant Client

インストール, 2.1, 7.2

Oracle Managed Files(OMF)

ASMを使用したスタンバイ・データベースの作成, 2.2

Oracle Net Services

構成変更, 1.2, 1.5.1

インストールの前提条件, 2.2

サポートされる構成, 3.1

双方向通信, 1.6.1

Oracle Real Application Clusters

ログ適用サービス, 4.5.7

適用インスタンスの設定, 4.5.7.1

Oracle Clusterwareにおけるインスタンスの可用性, 1.2

メリット, 1.2

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

オブザーバの動作, 5.5.2.1

オブザーバのインスタンスへの接続, 5.5.7.2

Oracle Clusterware, 1.2

Oracle Universal Installer

Oracle Instant Clientのインストール, 2.1, 7.2

Oracleウォレット

オブザーバの起動, 7.2

P

パラレル適用

ログ適用サービス, 4.5.2

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

パフォーマンス

Oracle Enterprise Managerツール, 1.5.1

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

パラレル適用の管理, 4.5.2

状態遷移, 4.2.1

プライマリ・ロールへのスイッチオーバー, 5.3

PreferredApplyInstanceプロパティ, 4.5.7.1, 8.3.35 前提条件

インストール, 2.2

スイッチオーバー, 5.3.1

プライマリ・データベース

ARCHIVELOGモード, 2.2

構成, 3.1

接続, 6.2, 6.2

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

Data Guard構成, 3.1

フェイルオーバー時, 1.5.1

スイッチオーバー時, 5.3.3

フラッシュバック・データベース, 5.4.3.1

健全性チェック, 4.9

スイッチオーバーの準備, 5.3.1

ファスト・スタート・フェイルオーバー後の回復, 5.5.8

ファスト・スタート・フェイルオーバーが有効化されている場合の停止, 5.5.9

スタンバイREDOログ・ファイル, 4.6.1

状態遷移, 4.2.1

スタンバイ・ロールへの切替え, 7.2

PrimaryLostWriteActionプロパティ, 8.1.12, 8.1.12 プロセス

DMON, 1.6.1

Oracleデータベース, 1.6.1

プロパティ, 4.3.2

AlternateLocation, 4.4.4

ApplyInstanceTimeout, 4.5.7.2

ApplyParallel, 4.5.2

構成可能, 4.3

データベース, 4.3

DelayMins, 4.5.1

LsbyASkipErrorCfgPr, 4.5.5

LsbyDSkipErrorCfgPr, 4.5.5

LsbyMaxSga, 4.5.3

LsbyPreserveCommitOrder, 4.5.3

管理, 1.6.3

監視可能, 4.3

PreferredApplyInstance, 4.5.7.1

設定, 3.4, 6.3

サーバー・パラメータ・ファイル内, 1.6.3, 2.2

StandbyArchiveLocation, 4.4.4 プロパティ・ページ

データベース, 1.5.1

保護モード

フェイルオーバー後, 4.6.2.3, 5.4.2, 5.5.1

メリット, 1.2

構成, 7.2

ダウングレード, 4.6.2.1

REDO転送サービス設定, 8.3.17

ブローカ構成に関する設定, 4.6

更新, 3.4

アップグレード, 4.6.2.1

Q

QUITコマンド, 7.2

「EXITコマンド」も参照

R

RAWデバイス

ブローカ構成ファイル, 3.2.2.3

サイズ設定, 3.2.2.3

RecvQEntriesプロパティ, 8.2.8 REDO Apply, 3.1, 5.3.3 REDO転送サービス

ASYNCモード, 4.4.2, 8.3.17

構成, 1.5.1

データ保護モード, 8.3.17

Data Guard構成, 3.1 LogShippingプロパティ, 8.3.16 管理, 4.4 SYNCモード, 4.4.2, 8.3.17 チューニング, 4.4.5 オフへの切替え, 4.4.3 オンへの切替え, 4.4.3 確認, 1.2 RedoCompressionプロパティ, 8.3.36 回復, 5.5.8

ブローカのdrc*ログ・ファイルに記録された障害, 5.5.4.1

フラッシュバック・データベースの要件, 5.4.3.1

フラッシュバック・ログの要件, 5.4.3.1

方法, 5.4.3.1

ブローカ・ログ・ファイルに記録, 5.5.8.3

ORA-16661メッセージ, 5.4.3, 5.4.3, 5.4.3.1

スタンバイREDOログ・ファイルが必要, 4.6.1

DGMGRLの使用, 5.4.3.1

Enterprise Managerの使用, 5.4.3.1

関係

ブローカ構成のオブジェクト, 1.3

REMOVE CONFIGURATIONコマンド, 7.2

例, 6.7.3

REMOVE DATABASEコマンド, 7.2 REMOVE INSTANCEコマンド, 7.2 削除

スタンバイ・データベース, 4.6.2.5

各REMOVEコマンドを参照

ReopenSecsプロパティ, 8.3.37 要求

サイト間のやりとり, 1.6.1

要件

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

再起動

データベース

ファスト・スタート・フェイルオーバーが有効化されている場合, 5.5.9

ロール遷移

変更, 3.4

管理, 5

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

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

スイッチオーバー, 5.3

S

スクリプト

Data Guardコマンドライン・インタフェース(DGMGRL)の使用, 7

適用インスタンスの選択, 4.5.7.1 SendQEntriesプロパティ, 8.2.9 サーバー・パラメータ・ファイル

ブローカのプロパティ管理, 1.6.3, 2.2

ファイル名, 1.6.3

Data Guard構成ファイルとの一貫性がない値, 8.2.2

サーバー側ソフトウェア, 1.6 SET STATEコマンド

適用インスタンスの設定, 4.5.7.1

設定

構成の保護モード, 4.6.1

データベース・プロパティ, 6.3

ログ適用サービス, 4.4.4

REDO転送サービス, 4.4.5

SGAメモリー

SQL Apply, 4.5.3

SHOW CONFIGURATIONコマンド, 6.2, 6.2, 6.4, 7.2 SHOW CONFIGURATION VERBOSE

例, 5.5.4

SHOW DATABASEコマンド, 7.2 SHOW DATABASE VERBOSEコマンド

プロパティの表示, 4.3

SHOW FAST_START FAILOVERコマンド, 7.2 SHOW FAST-START FAILOVERコマンド

例, 5.5.4

SHOW INSTANCEコマンド, 7.2 表示

各SHOWコマンドを参照

停止

FS_FAILOVER_OBSERVER_PRESENTビュー, 5.5.9

強制終了, 5.5.2.1

ファスト・スタート・フェイルオーバーへの影響, 5.5.2.3

SHUTDOWNコマンド, 7.2 Oracleインスタンスの停止, 7.2 SidNameプロパティ, 8.3.38 単一コマンド・モード

Data Guardコマンドライン・インタフェース, 7.1.1

SQL Apply, 3.1

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

スイッチオーバーによる影響, 5.3.3

エラー処理

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

フィルタ

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

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

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

バックアップからの作成, 3.4, 6.1

作成, 1.5.1

プライマリ・データベースでASMまたはOMFが使用されている場合, 2.2

Data Guard構成, 3.1 健全性チェック, 4.9 スイッチオーバーに関係しない, 5.3.3 フェイルオーバー後に再有効化, 5.4.2.1 削除, 4.6.2.5, 7.2 スタンバイREDOログ・ファイルが必要, 4.6.1 ファスト・スタート・フェイルオーバーが有効化されている場合の停止, 5.5.9 アーカイブREDOログの場所を指定, 4.4.4 プライマリ・ロールへの切替え, 7.2 スタンバイREDOログ・ファイル

設定, 4.6.1

DGMGRLによる設定, 4.6.1

StandbyArchiveLocationプロパティ, 8.3.39

ログ適用サービスの設定, 4.4.4

StandbyFileManagementプロパティ, 8.3.40 START OBSERVERコマンド

ファスト・スタート・フェイルオーバー構成ファイル(fsfo.dat), 5.5.7.6

起動

Data Guardコマンドライン・インタフェース(DGMGRL), 6.2, 7.1

Data Guardモニター(DMON), 3.3

手動フェイルオーバー, 5.4.2

Oracleインスタンス, 7.2

スイッチオーバー, 5.3.2

STARTUPコマンド, 7.2 状態遷移

データベースの状態への影響, 4.2.1

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

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

プライマリ・データベース, 4.2.1

状態, 3.5

変更, 6.7

データベース, 4.2

データベースの遷移, 4.2.1

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

APPLY-OFF, 4.2

APPLY-ON, 4.2

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

APPLY-OFF, 4.2

APPLY-ON, 4.2

プライマリ・データベース

TRANSPORT-OFF, 4.2

TRANSPORT-ON, 4.2

StaticConnectIdentifierプロパティ, 8.3.41 ステータス

構成, 3.6

プライマリ・データベースでの健全性チェック, 4.9

スタンバイ・データベースでの健全性チェック, 4.9

データベースの健全性, 4.9

構成のインテンド状態, 3.6

ステータス・メッセージ

ORA-16661, 5.4.3, 5.4.3

ORA-16795, 5.4.3

文字列値

Data Guardコマンドライン・インタフェース, 7.1.3

サポートされるブローカ構成, 1.3 SWITCHOVERコマンド, 6.8, 7.2 スイッチオーバー

メリット, 1.2

ブローカの作業, 5.3.3

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

DGMGRL SWITCHOVERコマンド, 6.8

影響

データベースの起動, 7.2

プライマリ・データベース, 5.3.3

保護モード, 4.6.2.2

スイッチオーバーに関係しないスタンバイ・データベース, 5.3.3

管理, 5, 5.3 概要, 5.1

Oracle Enterprise Manager, 1.5.1

ファスト・スタート・フェイルオーバーが有効化されている場合の実行, 5.5.2.4 プライマリ・データベースの準備, 5.3.1 前提条件, 5.3.1 無効化されたスタンバイ・データベースの再有効化, 5.4.3 起動, 5.3.2 遷移

ロジカル・スタンバイ・データベースをプライマリ・ロールへ, 5.3

フィジカル・スタンバイ・データベースをプライマリ・ロールへ, 5.3

DGMGRL SWITCHOVERコマンドの使用, 7.2 SYNC REDO転送モード, 4.4.2 SYSDBA権限, 6.2

データベースへの接続, 7.1.3

T

ターゲット・スタンバイ・データベース

選択, 5.2

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

FastStartFailoverTargetプロパティによる設定, 5.5.2, 6.6

TopWaitEventsプロパティ, 8.2.10 Tracelevelプロパティ, 8.1.13 トランザクションのコミット順序

制御, 4.5.3

TransportDisconnectedThresholdプロパティ, 8.3.42, 8.3.42 TransportLagThresholdプロパティ, 8.3.43, 8.3.43 TRANSPORT-OFF状態

LogShippingプロパティ設定, 8.3.16

TRANSPORT-ON状態

LogShippingプロパティの設定, 8.3.16

トラブルシューティング

Data Guard, 9

ブローカのdrc*ログ・ファイルに記録された診断, 9.1

チューニング

REDO転送サービス, 4.4.5

双方向通信チャネル, 1.6.1

U

監視されない構成, 5.5.7.3

構成プロパティの更新, 4.3

アップグレード

Data Guard, B.1, B.2

Oracle Enterprise Manager, B.1

保護モード, 4.6.2.1

ユーザー・インタフェース

概要, 1.5

V

V$DATABASEビュー

ファスト・スタート・フェイルオーバーの列, 5.5.2.2, 5.5.4.1

FS_FAILOVER_OBSERVER_HOST列, 5.5.7.2

FS_FAILOVER_OBSERVER_PRESENT列, 5.5.7.2

データベースの停止時, 5.5.9

確認

ファスト・スタート・フェイルオーバー環境, 5.5.2

表示

ファスト・スタート・フェイルオーバーの統計, 5.5.4.1

V$FS_FAILOVER_STATSビュー, 5.5.4.2 確認

ファスト・スタート・フェイルオーバー環境, 5.5.2

表示

データベースのプロパティ情報, 4.3.1, 8.2

W

WARNINGステータス, 3.6

ウィザード

スタンバイ・データベースの追加, 1.5.1

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, 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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork 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を参照してください。