Oracle® Data Guard

概要および管理

11gリリース2(11.2)

B56302-06(原本部品番号:E41134-03)

2014年2月

Oracle Data Guard概要および管理, 11gリリース2(11.2)

B56302-06

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

原本著者:  Kathy Rich

原本協力者: Andy Adams、Beldalker Anand、Rick Anderson、Andrew Babb、Pam Bantis、Tammy Bednar、Barbara Benton、Chipper Brown、Larry Carpenter、George Claborn、Laurence Clarke、Jay Davison、Jeff Detjen、Ray Dutcher、B.G. Garin、Mahesh Girkar、Yosuke Goto、Ray Guzman、Susan Hillson、Mark Johnson、Rajeev Jain、Joydip Kundu、J.William Lee、Steve Lee、Steve Lim、Nitin Karkhanis、Steve McGee、Bob McGuirk、Joe Meeks、Steve Moriarty、Muthu Olagappan、Deborah Owens、Ashish Ray、Antonio Romero、Mike Schloss、Vivian Schupmann、Mike Smith、Vinay Srihali、Morris Tao、Lawrence To、Doug Utzig、Ric Van Dyke、Doug Voss、Ron Weiss、Jingming Zhang

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

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

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

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 およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

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

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

目次

例一覧

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

Oracle Data Guardの新機能

- Oracle Database 11gリリース2(11.2.0.3)のOracle Data Guardの新機能

- Oracle Data Guard 11.2の新機能

- Oracle Data Guard 11.1の新機能

第I部 概要および管理

1 Oracle Data Guardの概要

- 1.1 Data Guard構成

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

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

- 1.1.3 構成例

- 1.2 Data Guardサービス

- 1.2.1 REDO転送サービス

- 1.2.2 適用サービス

- 1.2.3 ロールの推移

- 1.3 Data Guard Broker

- 1.3.1 Oracle Enterprise Manager Grid Controlの使用

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

- 1.4 Data Guardの保護モード

- 1.5 クライアント・フェイルオーバー

- 1.6 Data Guardと補完テクノロジ

- 1.7 Data Guardのメリットの要約

2 Data Guardの概説

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

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

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

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

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

- 2.3 Data Guardの動作要件

- 2.3.1 ハードウェアおよびオペレーティング・システムの要件

- 2.3.2 Oracleソフトウェア要件

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

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

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

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

- 3.1.2 REDO転送の認証の構成

- 3.1.3 REDOデータを受信するためのプライマリ・データベースの構成

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

- 3.1.5 アーカイブの有効化

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

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

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

- 3.2.3 スタンバイ・データベース用のパラメータ・ファイルの作成

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

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

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

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

- 3.3 作成後の手順

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

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

- 4.1.1 表のデータ型および記憶域属性のサポートの確認

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

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

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

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

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

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

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

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

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

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

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

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

- 4.3 作成後の手順

5 Data Guardの保護モード

- 5.1 Data Guardの保護モード

- 5.2 プライマリ・データベースのデータ保護モードの設定

6 REDO転送サービス

- 6.1 REDO転送サービスの概要

- 6.2 REDO転送サービスの構成

- 6.2.1 REDO転送のセキュリティ

- 6.2.1.1 SSLを使用したREDO転送の認証

- 6.2.1.2 パスワード・ファイルを使用したREDO転送の認証

- 6.2.2 REDOデータを送信するためのOracleデータベースの構成

- 6.2.2.1 V$ARCHIVE_DESTビューを使用した属性の表示

- 6.2.3 REDOデータを受信するためのOracleデータベースの構成

- 6.2.3.1 スタンバイREDOログの作成および管理

- 6.2.3.2 スタンバイREDOログ・アーカイブの構成

- 6.2.3.3 REDOがアーカイブREDOログ・ファイルに直接書き込まれる場合

- 6.3 カスケードされたREDO転送先

- 6.3.1 カスケードされた宛先の構成

- 6.3.2 データ保護の考慮事項

- 6.3.3 カスケードのシナリオ

- 6.3.3.1 フィジカル・スタンバイへのカスケード

- 6.3.3.2 複数のフィジカル・スタンバイへのカスケード

- 6.4 REDO転送サービスの監視

- 6.4.1 REDO転送ステータスの監視

- 6.4.2 同期REDO転送のレスポンス時間の監視

- 6.4.3 REDOギャップの検出および解決

- 6.4.3.1 手動によるギャップの解決

- 6.4.4 REDO転送サービスの待機イベント

- 6.5 REDO転送のチューニング

7 適用サービス

- 7.1 適用サービスの概要

- 7.2 適用サービスの構成オプション

- 7.2.1 リアルタイム適用によるREDOデータの即時適用

- 7.2.2 アーカイブREDOログ・ファイルの適用に対する遅延時間の指定

- 7.2.2.1 遅延時間設定の代替策としてのフラッシュバック・データベースの使用

- 7.3 REDOデータのフィジカル・スタンバイ・データベースへの適用

- 7.3.1 REDO Applyの開始

- 7.3.2 REDO Applyの停止

- 7.3.3 フィジカル・スタンバイ・データベースでのREDO Applyの監視

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

- 7.4.1 SQL Applyの開始

- 7.4.2 ロジカル・スタンバイ・データベースでのSQL Applyの停止

- 7.4.3 ロジカル・スタンバイ・データベースでのSQL Applyの監視

8 ロールの推移

- 8.1 ロールの推移の概要

- 8.1.1 ロールの推移の準備

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

- 8.1.3 スイッチオーバー

- 8.1.4 フェイルオーバー

- 8.1.5 ロールの推移のトリガー

- 8.2 フィジカル・スタンバイ・データベースが関与するロールの推移

- 8.2.1 フィジカル・スタンバイ・データベースへのスイッチオーバーの実行

- 8.2.2 フィジカル・スタンバイ・データベースへのフェイルオーバーの実行

- 8.3 ロジカル・スタンバイ・データベースが関与するロールの推移

- 8.3.1 ロジカル・スタンバイ・データベースへのスイッチオーバーの実行

- 8.3.2 ロジカル・スタンバイ・データベースへのフェイルオーバーの実行

- 8.4 ロールの推移後のフラッシュバック・データベースの使用

- 8.4.1 スイッチオーバー後のフラッシュバック・データベースの使用

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

9 フィジカルおよびスナップショット・スタンバイ・データベースの管理

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

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

- 9.1.2 フィジカル・スタンバイ・データベースの停止

- 9.2 フィジカル・スタンバイ・データベースのオープン

- 9.2.1 リアルタイム問合せ

- 9.2.1.1 リアルタイム問合せ環境での適用ラグの監視

- 9.2.1.2 リアルタイム問合せ環境での適用ラグ許容差の構成

- 9.2.1.3 リアルタイム問合せ環境でのREDO Applyの強制同期

- 9.2.1.4 リアルタイム問合せの制限

- 9.2.1.5 破損データ・ブロックの自動修復

- 9.2.1.6 破損データ・ブロックの手動修復

- 9.2.1.7 フィジカル・スタンバイ・データベースでの問合せのチューニング

- 9.2.1.8 フィジカル・スタンバイ・データベースへの一時ファイルの追加

- 9.3 フィジカル・スタンバイでの手動操作が必要なプライマリ・データベースの変更

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

- 9.3.1.1 RAWデバイスでのSTANDBY_FILE_MANAGEMENTパラメータの使用

- 9.3.1.2 エラーのリカバリ

- 9.3.2 表領域の削除とデータファイルの削除

- 9.3.2.1 DROP TABLESPACE INCLUDING CONTENTS AND DATAFILESの使用

- 9.3.3 フィジカル・スタンバイ・データベースでのトランスポータブル表領域の使用

- 9.3.4 プライマリ・データベースのデータファイルの改名

- 9.3.5 REDOログ・ファイル・グループの追加または削除

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

- 9.3.7 パスワード・ファイルのリフレッシュ

- 9.3.8 TDEマスター暗号化キーのリセット

- 9.4 OPEN RESETLOGS文を使用したリカバリ

- 9.5 プライマリ、フィジカル・スタンバイおよびスナップショット・スタンバイ・データベースの監視

- 9.5.1 プライマリ、フィジカルおよびスナップショット・スタンバイ・データベースを監視するためのビューの使用

- 9.5.1.1 V$DATABASE

- 9.5.1.2 V$MANAGED_STANDBY

- 9.5.1.3 V$ARCHIVED_LOG

- 9.5.1.4 V$LOG_HISTORY

- 9.5.1.5 V$DATAGUARD_STATUS

- 9.5.1.6 V$ARCHIVE_DEST

- 9.6 REDO Applyのチューニング

- 9.7 スナップショット・スタンバイ・データベースの管理

- 9.7.1 スナップショット・スタンバイ・データベースへのフィジカル・スタンバイ・データベースの変換

- 9.7.2 スナップショット・スタンバイ・データベースの使用

- 9.7.3 フィジカル・スタンバイ・データベースへのスナップショット・スタンバイ・データベースの変換

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

- 10.1 SQL Applyアーキテクチャの概要

- 10.1.1 SQL Applyに関する各種の考慮事項

- 10.1.1.1 トランザクション・サイズの考慮事項

- 10.1.1.2 ページアウトの考慮事項

- 10.1.1.3 再起動の考慮事項

- 10.1.1.4 DML適用の考慮事項

- 10.1.1.5 DDL適用の考慮事項

- 10.1.1.6 パスワード検証関数

- 10.2 ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスの制御

- 10.3 ロジカル・スタンバイ・データベースの管理および監視関連のビュー

- 10.3.1 DBA_LOGSTDBY_EVENTSビュー

- 10.3.2 DBA_LOGSTDBY_LOGビュー

- 10.3.3 V$DATAGUARD_STATSビュー

- 10.3.4 V$LOGSTDBY_PROCESSビュー

- 10.3.5 V$LOGSTDBY_PROGRESSビュー

- 10.3.6 V$LOGSTDBY_STATEビュー

- 10.3.7 V$LOGSTDBY_STATSビュー

- 10.4 ロジカル・スタンバイ・データベースの監視

- 10.4.1 SQL Applyの進捗の監視

- 10.4.2 ログ・ファイルの自動削除

- 10.5 ロジカル・スタンバイ・データベースのカスタマイズ

- 10.5.1 DBA_LOGSTDBY_EVENTSビューでのイベントのロギングのカスタマイズ

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

- 10.5.3 DDL文のスキップ・ハンドラの設定

- 10.5.4 ロジカル・スタンバイ・データベースの変更

- 10.5.4.1 ロジカル・スタンバイ・データベースでのDDLの実行

- 10.5.4.2 SQL Applyでメンテナンスされていない表の変更

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

- 10.6 ロジカル・スタンバイ・データベースの下での特定のワークロードの管理

- 10.6.1 プライマリ・データベースへのトランスポータブル表領域のインポート

- 10.6.2 マテリアライズド・ビューの使用

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

- 10.6.4 サポートされていない表のレプリケートでのトリガーの使用

- 10.6.5 プライマリでのPoint-in-Timeリカバリの実行によるリカバリ

- 10.6.6 ロジカル・スタンバイ・データベースでのOracle Streams取得プロセスの実行

- 10.7 ロジカル・スタンバイ・データベースのチューニング

- 10.7.1 主キーRELY制約の作成

- 10.7.2 コストベース・オプティマイザの統計の収集

- 10.7.3 プロセス数の調整

- 10.7.3.1 APPLIERプロセス数の調整

- 10.7.3.2 PREPARERプロセス数の調整

- 10.7.4 LCRキャッシュ用メモリーの調整

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

- 10.8 ロジカル・スタンバイ・データベースの下でのバックアップおよびリカバリ

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

- 11.1 Data Guard構成におけるRecovery Managerファイル管理の概要

- 11.1.1 Data Guard環境におけるバックアップの互換性

- 11.1.2 Data Guard環境におけるバックアップの関連付け

- 11.1.3 Data Guard環境におけるバックアップのアクセス可能性

- 11.2 Data Guard環境におけるRecovery Manager構成の概要

- 11.3 推奨されるRecovery Manager構成およびOracle Database構成

- 11.3.1 プライマリおよびスタンバイ・データベースでのOracle Database構成

- 11.3.2 プライマリ・データベースでのRecovery Manager構成

- 11.3.3 バックアップが実行されるスタンバイ・データベースでのRecovery Manager構成

- 11.3.4 バックアップが実行されないスタンバイでのRecovery Manager構成

- 11.4 バックアップ手順

- 11.4.1 テープ・バックアップ用キャッシュとしてのディスクの使用

- 11.4.1.1 ディスクをキャッシュとして使用する日次テープ・バックアップ用のコマンド

- 11.4.1.2 ディスクをキャッシュとして使用する週次テープ・バックアップ用のコマンド

- 11.4.2 テープへの直接バックアップの実行

- 11.4.2.1 テープに直接実行する日次バックアップ用のコマンド

- 11.4.2.2 テープに直接実行する週次バックアップ用のコマンド

- 11.5 Data Guard環境でのデータベースの登録および登録解除

- 11.6 Data Guard環境におけるレポート生成

- 11.7 Data Guard環境におけるバックアップ・メンテナンスの実行

- 11.7.1 リカバリ・カタログのメタデータの変更

- 11.7.2 アーカイブ・ログまたはバックアップの削除

- 11.7.3 リカバリ・カタログのメタデータの検証

- 11.8 Data Guard環境におけるリカバリ例

- 11.8.1 プライマリ・データベースのデータファイル消失からのリカバリ

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

- 11.8.3 スタンバイ制御ファイルの消失からのリカバリ

- 11.8.4 プライマリ制御ファイルの消失からのリカバリ

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

- 11.8.6 プライマリ・データベースの不完全リカバリ

- 11.9 その他のバックアップ状況

- 11.9.1 スタンバイ・データベースが地理的に離れすぎているためにバックアップを共有できない場合

- 11.9.2 FALサーバーとして使用されるスタンバイ・データベースにデータファイルが含まれていない場合

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

- 11.10 Recovery Managerの増分バックアップによるフィジカル・スタンバイ・データベースのロールフォワード

- 11.10.1 Recovery Managerの増分バックアップを使用するための手順

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

- 12.1 SQL Applyを使用するローリング・アップグレードのメリット

- 12.2 SQL Applyを使用してローリング・アップグレードを実行するための要件

- 12.3 アップグレード手順に使用する図と表記規則

- 12.4 ロジカル・スタンバイ・データベースの新規作成によるローリング・アップグレードの実行

- 12.5 既存のロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行

- 12.6 既存のフィジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行

13 Data Guardの使用例

- 13.1 フェイルオーバー後のロジカル・スタンバイ・データベースの構成

- 13.1.1 新規プライマリ・データベースがフィジカル・スタンバイ・データベースだった場合

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

- 13.2 フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換

- 13.2.1 障害が発生したプライマリ・データベースのフィジカル・スタンバイ・データベースへのフラッシュバック

- 13.2.2 障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへのフラッシュバック

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

- 13.3 Open Resetlogs文の発行後のフラッシュバック・データベースの使用

- 13.3.1 特定時点へのフィジカル・スタンバイ・データベースのフラッシュバック

- 13.3.2 特定時点へのロジカル・スタンバイ・データベースのフラッシュバック

- 13.4 NOLOGGING句を指定した後のリカバリ

- 13.4.1 ロジカル・スタンバイ・データベースのリカバリ手順

- 13.4.2 フィジカル・スタンバイ・データベースのリカバリ手順

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

- 13.5 OMFまたはOracle ASMを使用するスタンバイ・データベースの作成

- 13.6 プライマリ・データベースでの書込みの欠落エラーからのリカバリ

- 13.7 Recovery Managerバックアップを使用した障害が発生したプライマリのスタンバイ・データベースへの変換

- 13.7.1 Recovery Managerバックアップを使用した、障害が発生したプライマリのフィジカル・スタンバイへの変換

- 13.7.2 Recovery Managerバックアップを使用した障害が発生したプライマリのロジカル・スタンバイへの変換

- 13.8 フィジカル・スタンバイの再作成を伴わないプライマリのキャラクタ・セットの変更

第II部 リファレンス

14 初期化パラメータ

15 LOG_ARCHIVE_DEST_nパラメータの属性

- AFFIRMおよびNOAFFIRM

- ALTERNATE

- COMPRESSION

- DB_UNIQUE_NAME

- DELAY

- LOCATIONおよびSERVICE

- MANDATORY

- MAX_CONNECTIONS

- MAX_FAILURE

- NET_TIMEOUT

- NOREGISTER

- REOPEN

- SYNCおよびASYNC

- TEMPLATE

- VALID_FOR

16 Data Guardに関連するSQL文

- 16.1 ALTER DATABASE文

- 16.2 ALTER SESSION文

- 16.3 ALTER SYSTEM文

17 Oracle Data Guardに関連するビュー

第III部 付録

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

- A.1 一般的な問題

- A.1.1 ALTER DATABASE文によるデータファイル名の変更

- A.1.2 スタンバイ・データベースがプライマリ・データベースからREDOデータを受信しない

- A.1.3 フィジカル・スタンバイ・データベースをマウントできない

- A.2 ログ・ファイル宛先の障害

- A.3 ロジカル・スタンバイ・データベース障害の処理

- A.4 フィジカル・スタンバイ・データベースへのスイッチオーバーの問題

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

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

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

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

- A.4.5 失敗したスイッチオーバーをロールバックして最初からやりなおす

- A.5 ロジカル・スタンバイ・データベースへのスイッチオーバーの問題

- A.5.1 スイッチオーバー操作の準備フェーズ中の障害

- A.5.1.1 プライマリ・データベースの準備中の障害

- A.5.1.2 ロジカル・スタンバイ・データベースの準備中の障害

- A.5.2 スイッチオーバー操作のコミット・フェーズ中の障害

- A.5.2.1 元のプライマリ・データベースの変換での障害

- A.5.2.2 ターゲット・ロジカル・スタンバイ・データベースの変換での障害

- A.6 SQL Applyが停止した場合の処置

- A.7 REDOデータ転送のネットワーク調整

- A.8 スタンバイ・データベースのディスクのパフォーマンスが遅い

- A.9 プライマリ・データベースの停止を回避するにはログ・ファイルを一致させる必要がある

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

- A.10.1 エラーのリカバリ

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

- A.10.1.2 DML障害のリカバリ

- A.10.2 SQL*Loaderセッションのトラブルシューティング

- A.10.3 長時間実行トランザクションのトラブルシューティング

- A.10.4 フラッシュバック・トランザクションでのORA-1403エラーのトラブルシューティング

B Data Guard構成におけるデータベースのアップグレードおよびダウングレード

- B.1 Oracle Databaseソフトウェアをアップグレードする前の注意事項

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

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

- B.4 アップグレード後のCOMPATIBLE初期化パラメータの変更

- B.5 ロジカル・スタンバイが存在しない場合のOracle Databaseのダウングレード

- B.6 ロジカル・スタンバイが存在する場合のOracle Databaseのダウングレード

C ロジカル・スタンバイ・データベースでサポートされるデータ型およびDDL

- C.1 データ型に関する考慮事項

- C.1.1 ロジカル・スタンバイ・データベースでサポートされるデータ型

- C.1.1.1 互換性要件

- C.1.2 ロジカル・スタンバイ・データベースでサポートされないデータ型

- C.2 透過的データ暗号化(TDE)のサポート

- C.3 表領域の暗号化のサポート

- C.4 行レベル・セキュリティおよびファイングレイン監査のサポート

- C.4.1 行レベルのセキュリティ

- C.4.2 ファイングレイン監査

- C.4.3 PL/SQLレプリケーションのスキップおよび有効化

- C.5 Oracle Label Security

- C.6 Oracle E-Business Suite

- C.7 サポートされる表記憶域タイプ

- C.8 サポートされない表記憶域タイプ

- C.9 PL/SQLパッケージに関する考慮事項

- C.9.1 サポートされているPL/SQLパッケージ

- C.9.2 サポートされていないPL/SQLパッケージ

- C.9.3 ロジカル・スタンバイでのXMLおよびXDB PL/SQLパッケージの処理

- C.9.3.1 DBMS_XMLSCHEMAスキーマ

- C.9.3.2 DBMS_XMLINDEXパッケージ

- C.9.3.3 サポートされないPL/SQLプロシージャの処理

- C.9.3.4 サポートされないPL/SQLの手動による補正

- C.9.3.5 サポートされないPL/SQLの事前対応的な補正

- C.9.3.6 順序に依存するサポートされないPL/SQLの補正

- C.10 サポートされない表

- C.11 ロジカル・スタンバイ・データベースでスキップされるSQL文

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

- C.12.1 DBLINKSを使用するDDL文

- C.12.2 ロジカル・スタンバイ・プロセス上のAUD$およびFGA_LOG$のレプリケーション

- C.13 分散トランザクションおよびXAのサポート

- C.14 SecureFile LOBのサポート

- C.15 キャラクタ・セットに関する考慮事項

D Data GuardおよびOracle Real Application Clusters

- D.1 Oracle RAC環境でのスタンバイ・データベースの構成

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

- D.1.2 Oracle RACプライマリおよびスタンバイ・データベースの設定

- D.1.2.1 REDOデータを受信するためのOracle RACスタンバイ・データベースの構成

- D.1.2.2 REDOデータを送信するためのOracle RACプライマリ・データベースの構成

- D.2 Oracle RAC環境での構成に関する考慮事項

- D.2.1 アーカイブREDOログ・ファイル名の形式

- D.2.2 データ保護モード

- D.2.3 ロールの推移

- D.2.3.1 スイッチオーバー

- D.3 トラブルシューティング

- D.3.1 Oracle RAC構成でスイッチオーバーできない

E Recovery Managerを使用したスタンバイ・データベースの作成

- E.1 前提条件

- E.2 Recovery Managerを使用したスタンバイ・データベースの作成の概要

- E.2.1 Recovery Managerを使用したスタンバイ・データベースの作成の目的

- E.2.2 Recovery Managerを使用したスタンバイ・データベースの作成の基本概念

- E.2.2.1 アクティブ・データベース複製とバックアップベース複製

- E.2.2.2 Recovery Manager環境におけるDB_UNIQUE_NAMEの値

- E.2.2.3 スタンバイ・データベースのリカバリ

- E.2.2.4 スタンバイ・データベースREDOログ・ファイル

- E.2.2.5 スタンバイ・データベースのパスワード・ファイル

- E.3 DUPLICATEコマンドを使用したスタンバイ・データベースの作成

- E.3.1 アクティブ・データベース複製によるスタンバイ・データベースの作成

- E.3.2 バックアップベース複製によるスタンバイ・データベースの作成

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

- F.1 LOG_ARCHIVE_TRACE初期化パラメータの設定

- F.2 整数値の選択

索引

例一覧

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

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

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

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

- 4-2 ロジカル・スタンバイ・データベース用の初期化パラメータの変更

- 6-1 REDOのカスケード時に使用される初期化パラメータの一部

- 12-1 DBA_LOGSTDBY_EVENTSを使用したイベントの監視

- 15-1 代替アーカイブ先への自動フェイルオーバー

- 15-2 同じスタンバイ・データベースに対する代替Oracle Netサービス名の定義

- A-1 再試行時間と制限の設定

- A-2 代替宛先の指定

- A-3 ITLが不十分な状態に関してレポートされる警告メッセージ

- C-1 RegisterSchema用のPL/SQLスキップ・プロシージャ

図一覧

- 1-1 一般的なData Guard構成

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

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

- 2-1 可能なスタンバイ構成

- 7-1 リアルタイム適用を使用したスタンバイ宛先へのREDOデータの適用

- 8-1 スイッチオーバー前のData Guard構成

- 8-2 新しいプライマリ・データベースへのスイッチオーバー前のスタンバイ・データベース

- 8-3 スイッチオーバー後のData Guard環境

- 8-4 スタンバイ・データベースへのフェイルオーバー

- 10-1 SQL Applyの処理

- 10-2 SQL Apply処理中の進捗状態

- 12-1 アップグレード前のData Guard構成

- 12-2 ロジカル・スタンバイ・データベースのリリースのアップグレード

- 12-3 混合リリースの実行

- 12-4 スイッチオーバー後

- 12-5 両方のデータベースがアップグレードされた後

- D-1 複数インスタンス・プライマリ・データベースからのREDOデータの転送

表一覧

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

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

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

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

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

- 5-1 データ保護モードに対するREDO転送の必須属性

- 6-1 LOG_ARCHIVE_DEST_STATE_n初期化パラメータの値

- 6-2 REDO転送の待機イベント

- 9-1 フィジカル・スタンバイでの手動操作が必要なプライマリ・データベースの変更

- 9-2 一般的なプライマリ・データベースの管理アクションに関する情報ソース

- 12-1 ロジカル・スタンバイの新規作成によってローリング・アップグレードを実行する手順

- 12-2 既存のロジカル・スタンバイを使用したローリング・アップグレードの実行手順

- 12-3 既存のフィジカル・スタンバイを使用したローリング・アップグレードの実行手順

- 13-1 Data Guardの使用例

- 14-1 Data Guard構成内のインスタンスの初期化パラメータ

- 15-1 TEMPLATE属性のディレクティブ

- 16-1 Data Guard環境で使用されるALTER DATABASE文

- 16-2 Data Guard環境で使用されるALTER SESSION文

- 16-3 Data Guard環境で使用されるALTER SYSTEM文

- 17-1 Data Guard構成に関連のあるビュー

- A-1 スイッチオーバーを妨げる共通のプロセス

- A-2 一般的なSQL Applyエラーの解決方法

- C-1 DBMS_LOGSTDBY.SKIPプロシージャのstmtパラメータの値

- D-1 LOG_ARCHIVE_FORMAT初期化パラメータのディレクティブ

はじめに

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

対象読者

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

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

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

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

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 Database概要』の冒頭部分は、Oracleデータベースに関する概念と用語を提供し、このガイドに記載された詳細な情報の基礎として機能します。

- 『Oracle Database管理者ガイド』の制御ファイル、REDOログ・ファイル、アーカイブREDOログ・ファイルの管理に関する章。

- 『Oracle Databaseユーティリティ』のLogMiner技術について説明している章。

- 『Oracle Data Guard Broker』。Oracle Data Guard構成の作成、メンテナンス、監視を自動化および集中管理するためのグラフィカル・ユーザー・インタフェースとコマンドライン・インタフェースについて説明しています。

- 『Oracle Database高可用性概要』。Oracle Data Guardが、高可用性および障害時リカバリ環境でキー・コンポーネントとしてどのように使用されるかについて説明します。

- Oracle Enterprise Managerのオンライン・ヘルプ・システム

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

Oracle Data Guardの新機能

Oracle Database 11gのOracle Data Guardには、ここで説明する新機能と拡張機能が追加されました。

Oracle Database 11gリリース2(11.2.0.3)のOracle Data Guardの新機能

Oracle Data Guard 11gリリース2(11.2.0.3)のSQL Apply固有の新機能は次のとおりです。

- バイナリXMLとして格納されたXMLTypeデータのサポート

- オブジェクト・リレーショナル形式で格納されたXMLTypeデータのサポート

これらの両方の格納形式のサポートには、11.2.0.3以上のREDO互換性が設定されたOracle Database 11gリリース2(11.2.0.3)以上でプライマリ・データベースを実行している必要があります。サポートされているデータ型の詳細は、「データ型の考慮」を参照してください。

Oracle Data Guard 11.2の新機能

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

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

- REDO Applyに固有の11.2の新機能

- SQL Applyに固有の11.2の新機能

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

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

- Data Guard構成は、1つのプライマリ・データベースの他に最大30個のスタンバイ・データベースを含むことができます。

- FAL_CLIENTデータベース初期化パラメータは必要なくなりました。

- Oracle Automatic Storage Management(Oracle ASM)機能および高速リカバリ領域機能で使用されるデフォルトのアーカイブ先が、LOG_ARCHIVE_DEST_10からLOG_ARCHIVE_DEST_1に変更されました。

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

- 新しいALTER SYSTEM FLUSH REDO SQL文をフェイルオーバー時に使用して、未送信のREDOをマウント済のプライマリ・データベースからスタンバイ・データベースにフラッシュすることができます。これにより、プライマリ・データベースをゼロ・データ損失データ保護モードで実行していない場合でも、ゼロ・データ損失のフェイルオーバーを実行できます。詳細は、第8.2.2項を参照してください。

REDO Applyに固有の11.2の新機能

- 新しいSTANDBY_MAX_DATA_DELAYパラメータを使用して、リアルタイム問合せ環境での適用ラグ許容差を構成できます。

- 新しいALTER SESSION SYNC WITH PRIMARY SQL文を使用し、この文の発行時に、適切に構成されたフィジカル・スタンバイ・データベースをプライマリ・データベースと確実に同期することができます。

- V$DATAGUARD_STATSビューは、適用ラグおよびトランスポート・ラグを含む多数の列で精度が高くなりました。

- フィジカル・スタンバイの適用ラグ値のヒストグラムを確認できます。これには、新しいV$STANDBY_EVENT_HISTOGRAMビューを問い合せます。

- プライマリ・データベースの破損データ・ブロックは、リアルタイム問合せモードで実行しているフィジカル・スタンバイ・データベースの対応するブロックの破損していないコピーで自動的に置換されます。フィジカル・スタンバイ・データベースの破損ブロックも、プライマリ・データベースの対応するブロックの破損していないコピーで自動的に置換されます。

関連項目:
それぞれの機能の詳細は、9.2項「フィジカル・スタンバイ・データベースのオープン」 を参照してください。

SQL Applyに固有の11.2の新機能

- ロジカル・スタンバイ・データベースは、基本表圧縮、OLTP表圧縮およびハイブリッド列圧縮機能を備えた表をサポートしています。

関連項目:

- ハイブリッド列圧縮の詳細は、『Oracle Database概要』を参照してください。

- ロジカル・スタンバイおよびLogMinerユーティリティはSecureFile LOB列を持つ表をサポートします。SecureFile LOB列での圧縮および暗号化操作もサポートされています。(重複除外操作、およびフラグメントベースの操作はサポートされていません。)

- Oracle RACプライマリ・データベースでXAグローバル・トランザクション中に行われた変更は、ロジカル・スタンバイ・データベースでレプリケートされます。

- DBMS_REDEFINITION PL/SQLパッケージを使用して、プライマリ・データベースで実行されたオンライン再定義は、ロジカル・スタンバイ・データベースで透過的にレプリケートされます。

- ロジカル・スタンバイは、停止時間を最短に抑えてアプリケーションをアップグレードするために、エディションベースの再定義の使用を含め、プライマリ・データベースでのエディションの使用をサポートします。

関連項目:

- エディションベースの再定義の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- ロジカル・スタンバイ・データベースでは、Streams取得がサポートされます。これにより、一方向の情報伝播構成でプライマリ・データベースから処理をオフロードし、ロジカル・スタンバイを複数のデータベースに情報を伝播するためのハブにすることができます。また、Streams取得は、ロジカル・スタンバイ・データベースに対してローカルである変更を伝播することもできます。

Oracle Data Guard 11.1の新機能

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

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

- REDO Applyに固有の11.1の新機能

- SQL Applyに固有の11.1の新機能

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

- Data Guard構成でネットワークを経由したREDOトラフィックの圧縮
この機能は、REDOギャップを解決するときに、ネットワーク経由で送信される前のREDOを圧縮することにより、REDO転送のパフォーマンスを向上させます。

関連項目:
COMPRESSION属性

- REDO転送レスポンス時間ヒストグラム
V$REDO_DEST_RESP_HISTOGRAM動的パフォーマンス・ビューには、SYNC REDO転送先ごとのレスポンス時間データのヒストグラムが格納されます。このビューのデータは、LOG_ARCHIVE_DEST_n NET_TIMEOUT属性の適正値の決定を支援するために使用できます。

関連項目:
NET_TIMEOUT属性

- ロールのより高速な推移

- REDO転送ネットワーク・セッションの強力な認証
SSLを使用して、REDO転送ネットワーク・セッションを認証できるようになりました。これにより、強力な認証が提供され、Data Guard構成でのリモート・ログイン・パスワード・ファイルの利用はオプションになります。

- 単純化されたData Guard管理インタフェース
冗長SQL句と初期化パラメータを非推奨にすることで、Data Guard構成の管理に使用されるSQL文と初期化パラメータが単純化されました。

関連項目:

- どの文の句が非推奨になったかについては、第16章「Data Guardに関連するSQL文」を参照してください。

- 第16章で説明しているSQL文関連の非推奨になった句の詳細は、『Oracle Database SQL言語リファレンス 』を参照してください。

- LOG_ARCHIVE_DEST_nパラメータで非推奨になった属性の詳細は、『Oracle Databaseリファレンス』を参照してください。

- DB_UNIQUE_NAMEに関連する拡張機能
このリリースから、V$DATABASEビューで新しいPRIMARY_DB_UNIQUE_NAME列を問い合せることにより、スタンバイ・データベースからプライマリ・データベースのDB_UNIQUE_NAMEを検索できるようになります。また、Oracle Data Guardリリース11gでは、各データベースのDB_UNIQUE_NAMEが異なることが保証されます。11gへのアップグレード後、同じDB_UNIQUE_NAMEのデータベース間の通信は行えなくなります。

- ローリング・アップグレードでのフィジカル・スタンバイ・データベースの使用
このリリースから、フィジカル・スタンバイ・データベースは、ロジカル・スタンバイにより提供されるローリング・アップグレード機能を利用できるようになります。SQLのALTER DATABASE RECOVER TO LOGICAL STANDBY文で新しいKEEP IDENTITY句オプションを使用することにより、ローリング・アップグレードのためにフィジカル・スタンバイ・データベースを一時的にロジカル・スタンバイ・データベースに変換してから、アップグレードの終了後、プライマリ・データベースとフィジカル・スタンバイ・データベースを元の構成に戻すことができます。

関連項目:
第12章「SQL Applyを使用したOracle Databaseのアップグレード」

- Data Guardの異種構成
この機能では、LinuxとWindowsのプライマリ・データベースとスタンバイ・データベースを同一のData Guard構成に混在させることができます。

REDO Applyに固有の11.1の新機能

- フィジカル・スタンバイのリアルタイム問合せ機能
この機能により、REDO Applyがアクティブの間、フィジカル・スタンバイ・データベースを問合せできます。

関連項目:
オープンされたフィジカル・スタンバイ・データベースが、どのようにプライマリ・データベースからREDOデータを受信し、適用し続けるかの詳細は、9.2項「フィジカル・スタンバイ・データベースのオープン」を参照してください。

- スナップショット・スタンバイ
スナップショット・スタンバイ・データベースは、プライマリ・データベースに完全なデータ保護を提供する新しいタイプの更新可能なスタンバイ・データベースです。

関連項目:
9.7項「スナップショット・スタンバイ・データベースの管理」

- フィジカル・スタンバイを使用した書込み欠落の検出
「書込み欠落」はデータベースに悪影響を及ぼす重大なデータ破損形式です。永続記憶域に書き込まれなかったにもかかわらず、I/Oサブシステムがデータベースへのブロック書込みの完了を通知する場合に発生します。この機能によって、フィジカル・スタンバイ・データベースは、プライマリ・データベースまたはフィジカル・スタンバイ・データベースへの書込み欠落を検出することができます。

関連項目:
書込みの欠落の例については、13.6項「プライマリ・データベースでの書込みの欠落エラーからのリカバリ」、書込みの欠落の検出を有効化する方法については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- Recovery Manager(RMAN)との統合の強化
カタログ使用時に、すべてのプライマリおよびフィジカル・スタンバイ・データベースでのバックアップとリカバリ操作を簡素化するために、RMANのヘルプにいくつかの拡張が行われています。また、RMANのDUPLICATEコマンドを使用することで、事前にデータベースのバックアップを行わなくても、ネットワーク経由でフィジカル・スタンバイ・データベースを作成することができます。

関連項目:

- 第11章「Recovery Managerを使用したファイルのバックアップおよびリストア」

- 付録E「Recovery Managerを使用したスタンバイ・データベースの作成」

SQL Applyに固有の11.1の新機能

- オブジェクト・データベースおよびPL/SQLパッケージの追加サポート

- CLOBとして格納されるXML

- DBMS_RLS(行レベル・セキュリティまたは仮想プライベート・データベース)

- DBMS_FGA

関連項目:
付録C「ロジカル・スタンバイ・データベースでサポートされるデータ型およびDDL」

- 透過的データ暗号化(TDE)のサポート
Data Guard SQL Applyを使用すると、透過的データ暗号化を有効に設定したプライマリ・データベースにデータ保護を提供できます。これにより、ロジカル・スタンバイ・データベースは、高度なセキュリティ要件を伴うアプリケーションにデータ保護を提供できるようになります。

関連項目:

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

- C.2項「透過的データ暗号化(TDE)のサポート」

- Data Guard SQL Applyパラメータの動的な設定
SQL Applyを再起動せずに、特定のSQL Applyパラメータを構成できるようになります。DBMS_LOGSTDBY.APPLY_SETパッケージを使用して、初期化パラメータを動的に設定し、管理性、稼働時間、ロジカル・スタンバイ構成の自動化を向上させることができます。

さらに、APPLY_SETおよびAPPLY_UNSETサブプログラムには、2つの新しいパラメータ、LOG_AUTO_DEL_RETENTION_TARGETおよびEVENT_LOG_DESTが含まれます。

関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_LOGSTDBY PL/SQLパッケージに関する項を参照してください。

- ロジカル・スタンバイ・データベースでのOracle RACスイッチオーバーのサポート強化
プライマリ・データベースまたはスタンバイ・データベースがOracle RACを使用しているロジカル・スタンバイ・データベースにスイッチオーバーする場合、どのインスタンスもシャットダウンせずに、プライマリまたはロジカル・スタンバイ・データベースでSWITCHOVERコマンドを使用できます。

- Oracle Data Guard SQL ApplyでのDDL処理の強化
SQL Applyは、パラレルDDLをパラレルに(パラレル・サーバーの可用性に基づいて)実行できます。

- スタンバイ・データベースでスケジューラのジョブを作成するためのPL/SQL DBMS_SCHEDULERパッケージの使用
必要なとき(たとえばデータベースがプライマリ、スタンバイ、またはその両方の場合)に実行できるように、スケジューラのジョブをPL/SQL DBMS_SCHEDULERパッケージを使用してスタンバイ・データベースで作成し、適切なデータベース・ロールと関連付けることができます。

第I部

概要および管理

この部は、次の章で構成されています。

- 第1章「Oracle Data Guardの概要」

- 第2章「Data Guardの概説」

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

- 第4章「ロジカル・スタンバイ・データベースの作成」

- 第5章「Data Guardの保護モード」

- 第6章「REDO転送サービス」

- 第7章「適用サービス」

- 第8章「ロールの推移」

- 第9章「フィジカルおよびスナップショット・スタンバイ・データベースの管理」

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

- 第11章「Recovery Managerを使用したファイルのバックアップおよびリストア」

- 第12章「SQL Applyを使用したOracle Databaseのアップグレード」

- 第13章「Data Guardの使用例」

1 Oracle Data Guardの概要

Oracle Data Guardでは、企業データの高可用性、データ保護および障害時リカバリを保証します。Data Guardは、1つ以上のスタンバイ・データベースの作成、メンテナンス、管理および監視など、一連の包括的なサービスを提供し、本番のOracleデータベースを障害およびデータ破損から保護します。Data Guardでは、これらのスタンバイ・データベースを本番データベースのコピーとしてメンテナンスします。したがって、本番データベースが計画的または計画外の停止によって使用不可能になった場合は、スタンバイ・データベースを本番ロールに切り替えて、停止時間を最小限にできます。Data Guardを従来のバックアップ、リストアおよびクラスタ化の技法と連携して使用すると、高いレベルのデータ保護とデータ可用性を実現できます。

Data Guardを使用すると、リソース集中型のバックアップおよびレポート生成操作をスタンバイ・システムにオフロードすることで、管理者は本番データベースのパフォーマンスをオプションで改善できます。

この章では、Oracle Data Guardの概要を説明します。次の項目で構成されています。

- Data Guard構成

- Data Guardサービス

- Data Guard Broker

- Data Guardの保護モード

- クライアント・フェイルオーバー

- Data Guardと補完テクノロジ

- Data Guardのメリットの要約

1.1 Data Guard構成

Data Guard構成には、1つの本番データベースと1つ以上のスタンバイ・データベースが含まれます。Data Guard構成のデータベースは、Oracle Netで接続され、地理的に分散している場合があります。データベースの配置場所に制限はありませんが、相互に通信できる必要があります。たとえば、1個のスタンバイ・データベースを本番データベースと同じシステム上に配置し、2個のスタンバイ・データベースをリモート位置の別のシステム上に配置できます。

プライマリ・データベースとスタンバイ・データベースは、SQLコマンドライン・インタフェースまたはData Guard Brokerインタフェースを使用して管理できます。Data Guard Brokerインタフェースには、コマンドライン・インタフェース(DGMGRL)や、Oracle Enterprise Managerに統合されたグラフィカル・ユーザー・インタフェースなどがあります。

1.1.1 プライマリ・データベース

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

プライマリ・データベースは、単一インスタンスのOracleデータベースまたはOracle Real Application Clusters(Oracle RAC)データベースのいずれかです。

1.1.2 スタンバイ・データベース

スタンバイ・データベースは、プライマリ・データベースのトランザクション一貫性のあるコピーです。プライマリ・データベースのバックアップ・コピーを使用すると、最大30個のスタンバイ・データベースを作成して、Data Guard構成に組み込むことができます。スタンバイ・データベースが作成されると、Data Guardでは、プライマリ・データベースからスタンバイ・データベースにREDOデータを転送し、スタンバイ・データベースにREDOを適用することによって、各スタンバイ・データベースを自動的にメンテナンスします。

プライマリ・データベースと同様、スタンバイ・データベースは、単一インスタンスのOracleデータベースまたはOracle RACデータベースのいずれかです。

スタンバイ・データベースのタイプは、次のとおりです。

- フィジカル・スタンバイ・データベース
プライマリ・データベースと物理的に同一のコピーを提供します。これはブロック・ベースのプライマリ・データベースと同じディスク・データベース構造です。データベース・スキーマ(インデックスを含む)は同一です。フィジカル・スタンバイ・データベースは、REDO Applyによってプライマリ・データベースとの同期が保たれます。REDO Applyでは、プライマリ・データベースから受け取ったREDOデータがリカバリされ、このREDOがフィジカル・スタンバイ・データベースに適用されます。

Oracle Database 11gリリース1(11.1)現在、フィジカル・スタンバイ・データベースは、読取り専用アクセス用にオープンしている間はREDOを受信および適用できます。そのため、フィジカル・スタンバイ・データベースは、データ保護とレポート生成に同時に使用できます。

- ロジカル・スタンバイ・データベース
本番データベースと同じ論理情報が格納されますが、データの物理的な構成と構造は異なる場合があります。ロジカル・スタンバイ・データベースでは、プライマリ・データベースから受信したREDOデータをSQL文に変換し、スタンバイ・データベースでそのSQL文を実行するSQL Applyによって、プライマリ・データベースとの同期を維持します。

ロジカル・スタンバイ・データベースは、障害時リカバリ要件に加えて、その他のビジネス用途にも使用できます。このため、ロジカル・スタンバイ・データベースには、問合せやレポート生成の目的でいつでもアクセスできます。また、ロジカル・スタンバイ・データベースを使用すると、ほとんどの場合、データベースを停止することなく、Oracle Databaseソフトウェアやパッチ・セットをアップグレードできます。つまり、ロジカル・スタンバイ・データベースは、データ保護、レポート生成およびデータベースのアップグレードに同時に使用できます。

- スナップショット・スタンバイ・データベース
スナップショット・スタンバイ・データベースは、全面的に更新可能なスタンバイ・データベースです。

フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースと同様、スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信およびアーカイブします。しかし、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースとは異なり、スナップショット・スタンバイ・データベースは、受信したREDOデータを適用しません。スナップショット・スタンバイ・データベースで受信されたREDOデータは、スナップショット・スタンバイ・データベースに対して行われたローカル更新がすべて破棄された後、スナップショット・スタンバイが変換されてフィジカル・スタンバイ・データベースに戻るまで適用されません。

スナップショット・スタンバイ・データベースは、フィジカル・スタンバイ・データベースの一時的かつ更新可能なスナップショットが必要な場合に最もよく使用されます。スナップショット・スタンバイ・データベースで受信されたREDOデータは、フィジカル・スタンバイに変換されて戻るまで適用されないため、プライマリ・データベースの障害からリカバリするのに必要な時間は、適用する必要があるREDOデータの量に正比例します。

1.1.3 構成例

図1-1は、REDOデータをスタンバイ・データベースに転送するプライマリ・データベースが含まれる一般的なData Guard構成を示しています。スタンバイ・データベースは、障害時リカバリ操作とバックアップ操作に備えて、プライマリ・データベースから離れた位置に配置されます。スタンバイ・データベースはプライマリ・データベースと同じ位置にも構成できます。ただし、障害時リカバリに使用する場合は、スタンバイ・データベースを離れた位置に構成することをお薦めします。

図1-1 一般的なData Guard構成

1.2 Data Guardサービス

次の各項では、Data GuardによるREDOデータの転送、REDOデータの適用およびデータベース・ロールの変更の管理方法について説明します。

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

- 適用サービス
スタンバイ・データベースにREDOデータを適用して、プライマリ・データベースとのトランザクションの同期を維持します。REDOデータはアーカイブ保存されたREDOログ・ファイルから適用することができます。または、リアルタイムの適用を有効にしている場合は、最初にスタンバイ・データベースにアーカイブ保存しなくても、スタンバイREDOログ・ファイルへの書込みと同時に直接適用することもできます。

- ロールの推移
データベースのロールを、スイッチオーバー操作またはフェイルオーバー操作を使用して、スタンバイ・データベースからプライマリ・データベースに、またはプライマリ・データベースからスタンバイ・データベースに変更します。

1.2.1 REDO転送サービス

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

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

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

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

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

1.2.2 適用サービス

プライマリ・データベースから送信されたREDOデータは、スタンバイ・データベース上のスタンバイREDOログ上に書き込まれます。適用サービスによって、スタンバイ・データベースにREDOデータを自動的に適用し、プライマリ・データベースとの一貫性を維持します。データへの読取り専用アクセスも許可します。

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

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

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

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

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

1.2.3 ロールの推移

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

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

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

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

1.3 Data Guard Broker

Data Guard Brokerは分散管理フレームワークで、Data Guard構成の作成、メンテナンスおよび監視を自動化します。Oracle Enterprise Managerのグラフィカル・ユーザー・インタフェース(GUI)またはData Guardコマンドライン・インタフェース(DGMGRL)を使用すると、次の操作が自動化および単純化されます。

- REDO転送サービスや適用サービスの設定など、Data Guard構成の作成と有効化

- 構成内の任意のシステムによるData Guard構成全体の管理

- Oracle RACのプライマリ・データベースまたはスタンバイ・データベースが含まれるData Guard構成の管理と監視

- Oracle Enterprise Managerでキー・クリックを1回する、あるいはDGMGRLコマンドライン・インタフェースで単一のコマンドを使用すると起動できるようにする、スイッチオーバーおよびフェイルオーバーの単純化

- プライマリ・データベースが使用できなくなった場合に、ファスト・スタート・フェイルオーバーを有効化し、すぐにフェイルオーバーを自動的に行います。ファスト・スタート・フェイルオーバーが有効化されている場合、Data Guardブローカによってフェイルオーバーの必要性が判断され、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーが自動的に開始されます。DBAによる操作は不要です。

さらに、Oracle Enterprise Managerを使用すると、次の操作が自動化および単純化されます。

- プライマリ・データベースのバックアップ・コピーからのフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースの作成

- Data Guard構成への新規または既存のスタンバイ・データベースの追加

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

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

1.3.1 Oracle Enterprise Manager Grid Controlの使用

Oracle Enterprise Manager Grid Control(以下、このマニュアルではEnterprise Managerと呼びます)は、Data Guard構成内のプライマリ・データベースおよびスタンバイ・データベースを表示、監視および管理するための、Webベースのインタフェースを提供します。Enterprise Managerの使いやすいインタフェースと、BrokerによるData Guard構成の集中化された管理および監視を組み合せることで、企業内の高可用性、サイト保護およびデータ保護を実現するためのData Guardソリューションが強化されます。

Enterprise Manager Grid Controlのセントラル・コンソールから、すべての管理操作をローカルまたはリモートで実行できます。プライマリ・データベースとスタンバイ・データベース、およびプライマリ・インスタンスとスタンバイ・インスタンスを含む、Oracleデータベースのホーム・ページの表示、既存のスタンバイ・データベースの作成または追加、インスタンスの開始および停止、インスタンスのパフォーマンスの監視、イベントの表示、ジョブのスケジュール、バックアップ操作およびリカバリ操作の実行が可能です。

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

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

1.4 Data Guardの保護モード

場合によっては、状況に関係なくデータの消失が許されないビジネスがあります。また、起こりそうにない多重障害の場合に起こりうるデータの消失よりデータベースの可用性の方が重要な場合もあります。アプリケーションの中には、常に最大のデータベース・パフォーマンスが必要であるため、コンポーネントに障害が発生した場合に少量のデータの消失ならば許容できるものがあります。データ保護には、次の3つの異なるモードが用意されています。

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

この保護モードは、特定の二重障害の場合(スタンバイ・データベースの障害が発生した後にプライマリ・データベースの障害が発生した場合など)を除いて、データ消失がないことを保証します。

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

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

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

3つの保護モードはいずれも、特定のREDO転送オプションを使用して、REDOデータが少なくとも1つのスタンバイ・データベースに送信されるようにする必要があります。

関連項目:

- 第5章「Data Guardの保護モード」にはこのモードの詳細な説明と、プライマリ・データベースの保護モードの設定に関する情報が記載されています。

1.5 クライアント・フェイルオーバー

高可用性アーキテクチャには、データベースおよびデータベース・クライアントに対する高速フェイルオーバー機能が必要です。

クライアント・フェイルオーバーには、障害の通知、失効した接続のクリーンアップおよび新しいプライマリ・データベースへの透過的な再接続が含まれます。Oracle Databaseには、データベース・フェイルオーバーとフェイルオーバー・プロシージャを統合する機能があるため、クライアントは、データベース・フェイルオーバーから数秒以内に新しいプライマリ・データベースに自動的にリダイレクトされます。

関連項目:

- Data GuardのFast Application Notification(FAN)およびFast Connection Failover(FCF)構成要件の詳細は、『Oracle Data Guard Broker』を参照してください。

- 次のURLにアクセスし、Maximum Availability Architectureのクライアント・フェイルオーバーのベスト・プラクティスに関するホワイト・ペーパーを参照してください。
http://www.oracle.com/goto/maa

1.6 Data Guardと補完テクノロジ

Oracle Databaseでは、Data Guardを補完する複数の固有のテクノロジを提供して、ビジネスに不可欠なシステムが、1つのソリューションのみを利用する場合に比べ、はるかに高い可用性とデータ保護を実現しながら稼働できるようにします。Oracleの高可用性テクノロジには、次のものがあります。

- Oracle Real Application Clusters(Oracle RAC)
Oracle RACを使用すると、インターコネクトによってリンクされた複数の独立型サーバーで、Oracleデータベースへのアクセスを共有し、障害の発生時に、高可用性、スケーラビリティおよび冗長性を実現できます。Oracle RACとData Guardを一緒に使用すると、システムレベル、サイトレベルおよびデータレベルのそれぞれの保護にメリットがあるため、データを消失することなく、高い可用性と障害時リカバリが実現します。

- Oracle RACは、ノード障害やインスタンス・クラッシュなどの障害から迅速に、自動的にリカバリすることで、システム障害に対処します。アプリケーションに対するスケーラビリティも向上します。

- Data Guardでは、トランザクション的に一貫性のある、ディスクを共有しないプライマリ・データベースとスタンバイ・データベースを介して、サイト内の問題やデータ保護に対処し、サイトの障害やデータ破損からリカバリできるようにします。

ローカル・サイトとリモート・サイトの使用、ロジカル・スタンバイ・データベースとフィジカル・スタンバイ・データベースの組合せとノードの使用によって、Oracle RACおよびData Guardを使用した様々なアーキテクチャを実現できます。Oracle RACとData Guradの統合については、付録D「Data GuardおよびOracle Real Application Clusters」、および「Oracle Database高可用性概要」を参照してください。

- フラッシュバック・データベース
フラッシュバック・データベース機能により、論理データの破損やユーザー・エラーから迅速にリカバリできます。適切なときにフラッシュバックを許可することで、誤って変更または削除された可能性のある以前のバージョンのビジネス情報に再度アクセスできるようになります。この機能により、次のことが実現します。

- バックアップをリストアして、エラーや破損が発生した時点までロールフォワード変更を行う必要がなくなります。かわりに、フラッシュバック・データベースでは、データファイルをリストアせずに、以前の時点までOracleデータベースをロールバックできます。

- REDOの適用を遅延してユーザー・エラーや論理的な破損から保護するための、代替手段を提供します。したがって、スタンバイ・データベースは、プライマリ・データベースとより密接に同期できるため、フェイルオーバーおよびスイッチオーバーの回数が少なくなります。

- フェイルオーバー後に、元のプライマリ・データベースを完全に作成しなおす必要がなくなります。障害が発生したプライマリ・データベースを、フェイルオーバー前の時点にフラッシュバックして、新しいプライマリ・データベースのスタンバイ・データベースになるように変換できます。

データベースのフラッシュバックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を、REDOデータの適用の詳細は、7.2.2項を参照してください。

- Recovery Manager(RMAN)
Recovery Managerは、データベース・ファイルのバックアップ、リストアおよびリカバリを単純化するOracleユーティリティです。Data Guardと同様に、Recovery ManagerはOracleデータベースの機能の1つであるため、個別にインストールする必要はありません。Data GuardとRecovery Managerは密接に統合されているため、次のことが実現されます。

- Recovery ManagerのDUPLICATEコマンドを使用して、プライマリ・データベースのバックアップからスタンバイ・データベースを作成できます。

- 本番データベースではなくフィジカル・スタンバイ・データベースからバックアップを取得して、本番データベースの負荷を軽減し、スタンバイ・サイトのシステム・リソースを効率的に使用できます。また、フィジカル・スタンバイ・データベースがREDOを適用しているときに、バックアップを取得することもできます。

- バックアップの実行後、入力に使用されたアーカイブREDOログ・ファイルを自動的に削除することで、アーカイブREDOログ・ファイルの管理を容易にします。

付録E「Recovery Managerを使用したスタンバイ・データベースの作成」、および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

1.7 Data Guardのメリットの要約

Data Guardには次のようなメリットがあります。

- 障害時リカバリ、データ保護および高可用性
Data Guardは、効率のよい包括的な障害時リカバリおよび高可用性ソリューションを提供します。管理が容易なスイッチオーバー機能とフェイルオーバー機能を使用すると、プライマリ・データベースとスタンバイ・データベース間でロールを可逆的に推移できるため、計画的および計画外の停止によるプライマリ・データベースの停止時間が最小限になります。

- 完全なデータ保護
Data Guardでは、予期しない障害が発生した場合でもデータ消失がないことを保証します。スタンバイ・データベースには、データの破損やユーザーのミスに対する保護対策が用意されています。プライマリ・データベースから受信したREDOデータはスタンバイ・データベースで検証されるため、プライマリ・データベースの記憶域レベルの物理破損は、スタンバイ・データベースに伝播されません。同様に、プライマリ・データベースの完全な破損の原因となった論理的な破損やユーザーのミスも解決できます。

- システム・リソースの効率的な使用
プライマリ・データベースから受信したREDOデータで更新されたスタンバイ・データベース表は、バックアップ、レポート生成、要約および問合せなどの他のタスクにも使用できます。したがって、これらのタスクの実行に必要なプライマリ・データベースのワークロードを低減し、貴重なCPUとI/Oのサイクルを節約できます。

- 可用性とパフォーマンス要件とのバランスを保つことができるデータ保護の柔軟性
Oracle Data Guardには、各企業がデータ可用性とシステム・パフォーマンス要件とのバランスを保つことができるように、最大保護、最大可用性および最大パフォーマンスの3つのモードが用意されています。

- ギャップの自動検出と自動解消
ネットワークの問題などで、プライマリ・データベースと1つ以上のスタンバイ・データベースとの間の接続が失われた場合、プライマリ・データベース上に生成されるREDOデータは、宛先のスタンバイ・データベースに送信されません。接続が再度確立された時点で、Data Guardによって、欠落しているアーカイブREDOログ・ファイル(ギャップと呼ばれます)が自動的に検出され、それらのファイルがスタンバイ・データベースに自動的に転送されます。スタンバイ・データベースはプライマリ・データベースと同期化されるため、DBAによる手動操作は不要です。

- 集中化された単純な管理
Data Guard Brokerは、グラフィカル・ユーザー・インタフェースとコマンドライン・インタフェースを提供し、Data Guard構成の複数のデータベース全体の管理タスクと操作タスクを自動化します。また、ブローカは、単一のData Guard構成内のすべてのシステムを監視します。

- Oracle Databaseとの統合
Data GuardではOracle Database Enterprise Editionの機能の1つであるため、個別にインストールする必要はありません。

- 自動ロールの推移
ファスト・スタート・フェイルオーバーが有効になると、プライマリ・サイトで障害が発生した場合、Data Guard Brokerにより、DBAによる操作の必要なしに同期化されたスタンバイ・サイトにフェイルオーバーされます。また、アプリケーションにロールの推移が自動的に通知されます。

2 Data Guardの概説

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

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

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

- Data Guardの動作要件

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

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

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

スタンバイ・データベースのタイプには、フィジカル・スタンバイ・データベース、ロジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースがあります。フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースは、必要に応じてプライマリ・データベースのロールを担い、本番処理を引き継ぐことができます。Data Guard構成には、これらのタイプのスタンバイ・データベースを任意に組み合せて含めることができます。

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

フィジカル・スタンバイ・データベースはプライマリ・データベースを正確に、ブロックごとにコピーしたものです。フィジカル・スタンバイはREDO Applyと呼ばれるプロセスによって正確なコピーとして維持されます。このプロセスではデータベース・リカバリ・メカニズムを使用して、プライマリ・データベースから受信したREDOデータを継続的にフィジカル・スタンバイ・データベースに適用します。

フィジカル・スタンバイ・データベースは、読取り専用アクセス用にオープンし、問合せをプライマリ・データベースからオフロードするために使用できます。 Oracle Active Data Guardオプションのライセンスを購入している場合は、フィジカル・スタンバイ・データベースを開いている間はRedo Applyをアクティブにすることができます。それにより、問合せによって、プライマリ・データベースからのものと同じ結果が得られます。この機能は、リアルタイム問合せ機能と呼ばれます。

関連項目:

- 「フィジカル・スタンバイ・データベースのオープン」

- Oracle Active Data Guardの詳細は、『Oracle Databaseライセンス情報』を参照してください。

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

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

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

- データ保護
フィジカル・スタンバイ・データベースは、予期しなかった障害時でもデータ損失を防止することができます。フィジカル・スタンバイ・データベースでは、すべてのデータ型、およびプライマリ・データベースがサポートしているすべてのDDLおよびDMLの操作がサポートされます。また、データの破損およびユーザー・エラーからも保護します。プライマリ・データベースに対するストレージ・レベルの物理的な破損は、スタンバイ・データベースに伝播しません。同様に、データ損失の原因となる論理的な破損ユーザー・エラーも簡単に解決できます。

- プライマリ・データベースのワークロードの低減
Oracle Recovery Manager(RMAN)は、フィジカル・スタンバイ・データベースを使用してプライマリ・データベースからバックアップをオフロードし、貴重なCPUとI/Oのサイクルを節約できます。

フィジカル・スタンバイ・データベースは、REDO Applyがアクティブであれば問い合せることもできるため、プライマリ・データベースからフィジカル・スタンバイ・データベースに問合せをオフロードでき、プライマリ・データベースのワークロードはさらに低減します。

- パフォーマンス
フィジカル・スタンバイ・データベースで使用されるREDO Applyテクノロジは、プライマリ・データベースで行われた変更でスタンバイ・データベースを常に更新することに関しては最も効率的なメカニズムです。これは、SQLレベルのコード・レイヤーをすべてバイパスする、低レベルのリカバリ・メカニズムを使用して変更を適用するためです。

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

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

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

ロジカル・スタンバイ・データベースには、データ型、表のタイプ、DDL操作およびDML操作のタイプに関していくつかの制限があります。ロジカル・スタンバイ・データベースのデータ型およびDDLのサポートの詳細は、付録Cを参照してください。

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

ロジカル・スタンバイ・データベースは、データ・リカバリ(DR)のメリットとともに高可用性(HA)を提供するには理想的です。フィジカル・スタンバイ・データベースと比較して、ロジカル・スタンバイ・データベースは、さらに次の重要なHAのメリットを提供します。

- 別の種類の障害からの保護
ロジカル・スタンバイはREDOを分析してデータベースに対する論理的な変更を再構成するため、ブロック・レベルの変更を介してレプリケートされる可能性がある、プライマリでの特定の種類のハードウェア障害を検出し、それから保護することができます。Oracleでは、同じプライマリ・サーバーに対してフィジカル・スタンバイとロジカル・スタンバイの両方を保持できます。

- リソースの効率的な使用
プライマリ上の変更をレプリケートしている間は、ロジカル・スタンバイ・データベースは読取り/書込み用にオープン状態になります。その結果、ロジカル・スタンバイ・データベースはその他のビジネス要件を満たすために、同時に使用することができます。たとえば、レポート・ワークロードを実行することができますが、プライマリのスループットが低下します。プライマリ・データの完全で正確なコピーに対して、新しいソフトウェア・リリースや特定の種類のアプリケーションをテストするために使用することができます。プライマリからレプリケートされたデータをローカルな変更から保護しながら、他のアプリケーションおよび追加のスキーマをホストすることができます。特定の物理的な再構築(たとえばパーティショニング・スキームの変更など)による影響の判定に使用することができます。ロジカル・スタンバイはユーザー・トランザクションを識別し、バックグラウンドでのシステム変更をフィルタ処理しながら該当する変更だけをレプリケートするので、対象となるトランザクションだけを効率よくレプリケートすることができます。

- ワークロードの分散
ロジカル・スタンバイは、ワークロードの分散に使用可能な、最新で一貫性のあるプライマリ・データベースのレプリカを作成することができる、シンプルなターンキー・ソリューションを提供します。レポート・ワークロードの増加に伴い、透過的ロード分散によって、プライマリ・サーバーのトランザクション・スループットには影響を及ぼすことなく、追加のロジカル・スタンバイを作成できます。

- レポート生成要件および意思決定支援要件のための最適化
ロジカル・スタンバイの主な利点は、レポート作成のワークロードを最適化する重要な補助構造(プライマリのトランザクション・レスポンス時間に対する抑制効果をもたらす構造)を作成できることです。ロジカル・スタンバイは、そのデータをパーティショニングの異なる各種ストレージに物理的に再構成し、多数の異なる索引を付けて、オンデマンド・リフレッシュ・マテリアライズド・ビューを作成および維持することができます。また、データ・キューブおよびその他のOLAPデータ・ビューの作成促進に使用することができます。

- ソフトウェア・アップグレード時の停止時間の最短化
ロジカル・スタンバイを使用すると、パッチ・セットやソフトウェアの新しいリリースの適用に関連する停止時間を大幅に短縮できます。ロジカル・スタンバイは、新しいリリースへのアップブレード後に切り替えて、アクティブなプライマリにすることができます。これにより、古いプライマリをロジカル・スタンバイに変換してパッチ・セットを適用する間、完全な可用性を可能にします。

2.1.3 スナップショット・スタンバイ・データベース

スナップショット・スタンバイ・データベースは、プライマリ・データベースに完全なデータ保護を提供するタイプの更新可能なスタンバイ・データベースです。スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信およびアーカイブしますが、適用はしません。プライマリ・データベースから受信したREDOデータは、スナップショット・スタンバイ・データベースへのローカル更新がすべて破棄された後、スナップショット・スタンバイ・データベースが変換されてフィジカル・スタンバイ・データベースに戻ると適用されます。

プライマリ・データベースのREDOデータは受信と同時には適用されないので、スナップショット・スタンバイ・データベースは通常、時間の経過とともにプライマリ・データベースとの差異が生じます。スナップショット・スタンバイ・データベースのローカルな更新によって差異が増えます。ただし、スナップショット・スタンバイはいつでもフィジカル・スタンバイ・データベースに戻すことができ、その後プライマリから受信したREDOデータを適用できるので、プライマリ・データベース内のデータは完全に保護されています。

スナップショット・スタンバイ・データベースのメリット

スナップショット・スタンバイ・データベースは、全面的に更新可能なスタンバイ・データベースで、フィジカル・スタンバイ・データベースと同様の、障害時リカバリおよびデータ保護のメリットがあります。スナップショット・スタンバイ・データベースは、プライマリ・データベースの障害からリカバリする時間が増えても、プライマリ・データベースの一時的かつ更新可能なスナップショットを保持するメリットがある場合に最もよく使用されます。

スナップショット・スタンバイ・データベースの使用には、次のメリットがあります。

- 常にデータ保護を維持しながら、開発およびテスト用に本番データベースの正確なレプリカを提供します。

- フィジカル・スタンバイに変換して再同期化することで、現行の本番データが格納されるように簡単にリフレッシュできます。

スナップショット・スタンバイの作成、テスト、本番環境との再同期化に続いて、再びスナップショット・スタンバイの作成およびテストを実行できることは、必要に応じて何度も繰り返すことができる1サイクルです。同じプロセスを使用して、データへの読取り/書込みアクセスが必要なレポート生成用にスナップショット・スタンバイを簡単に作成し、定期的に更新できます。

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

Data Guard構成の構成、実装および管理には、次のインタフェースを使用できます。

- Oracle Enterprise Manager
Enterprise Managerでは、Data Guard環境の作成、構成および監視に関係するタスクの多くを自動化する、Data Guard BrokerのGUIインタフェースが用意されています。GUIとそのウィザードの詳細は、『Oracle Data Guard Broker』およびOracle Enterprise Managerのオンライン・ヘルプを参照してください。

- SQL*Plusコマンドライン・インタフェース
いくつかのSQL*Plus文では、STANDBYキーワードを使用して、スタンバイ・データベースに対する操作を指定します。他のSQL文にはスタンバイ固有の構文はありませんが、スタンバイ・データベースで操作を実行するときに役立ちます。関連する文のリストは、第16章を参照してください。

- 初期化パラメータ
Data Guard環境の定義には、いくつかの初期化パラメータが使用されます。関連する初期化パラメータのリストは、第14章を参照してください。

- Data Guard Brokerコマンドライン・インタフェース(DGMGRL)
DGMGRLコマンドライン・インタフェースは、Enterprise Managerの代替手段です。DGMGRLコマンドライン・インタフェースは、ブローカを使用してバッチ・プログラムまたはスクリプトからData Guard構成を管理する場合に役立ちます。完全な情報は、『Oracle Data Guard Broker』を参照してください。

2.3 Data Guardの動作要件

次の各項で、Data Guard使用時の動作要件を説明します。

- ハードウェアおよびオペレーティング・システムの要件

- Oracleソフトウェア要件

2.3.1 ハードウェアおよびオペレーティング・システムの要件

Oracle Database 11gから、Data GuardではData Guard構成の柔軟性が高まり、プライマリ・システムとスタンバイ・システムで、異なるCPUアーキテクチャ、オペレーティング・システム(たとえばWindowsとLinux)、オペレーティング・システムのバイナリ(32-bit/64-bit)、またはOracleデータベースのバイナリ(32-bit/64-bit)を使用できるようになりました。

プラットフォームの混在について向上した柔軟性は、http://support.oracle.comにあるMy Oracle SupportのNote 413484.1および1085687.1で記述されている現行の制限事項の対象となります。

Note 413484.1では、フィジカル・スタンバイに対するプラットフォーム混在のサポートおよび制限事項について説明しています。

Note 1085687.1では、ロジカル・スタンバイに対するプラットフォーム混在のサポートおよび制限事項について説明しています。

同じリリースのOracle Database Enterprise Editionをプライマリ・データベースおよびすべてのスタンバイ・データベースにインストールする必要があります。ただし、ロジカル・スタンバイ・データベースを使用したローリング・データベース・アップグレード時を除きます。

関連項目:

- ローリング・データベース・アップグレードの詳細は、第12章「SQL Applyを使用したOracle Databaseのアップグレード」を参照してください。

2.3.2 Oracleソフトウェア要件

次のリストに、Data Guard使用時のOracleソフトウェア要件を示します。

- Oracle Data Guardは、Oracle Database Enterprise Editionの専用機能として提供されています。Oracle Database Standard Editionには提供されていません。

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

- Data Guard SQL Applyを使用して、Oracle Databaseソフトウェアをパッチ・セット・リリースn(10.1.0.3以上)から上位バージョンのパッチ・セットまたはメジャー・バージョン・リリースにローリング・アップグレードできます。ローリング・アップグレード時には、プライマリ・データベースおよびロジカル・スタンバイ・データベースを1つずつアップグレードする間、異なるリリースのOracle Databaseを実行できます。詳細は、第12章「SQL Applyを使用したOracle Databaseのアップグレード」および該当するOracle Database 10gパッチ・セット・リリースのREADMEファイルを参照してください。

- Data Guard構成のすべてのデータベースで、COMPATIBLE初期化パラメータを同じ値に設定する必要があります。ただし、ロジカル・スタンバイ・データベースは例外で、プライマリ・データベースよりもCOMPATIBLEの設定値を大きくできます。

- Oracle8iデータベース・ソフトウェア上でOracle Data Guardを実行している場合のOracle Data Guard 11gへのアップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

- プライマリ・データベースはARCHIVELOGモードで実行する必要があります。詳細は、『Oracle Database管理者ガイド』を参照してください。

- プライマリ・データベースは、単一インスタンス・データベースまたはOracle Real Application Clusters(Oracle RAC)データベースのいずれかです。スタンバイ・データベースは、単一インスタンス・データベースまたはOracle RACデータベースで、フィジカル・タイプ、ロジカル・タイプおよびスナップショット・タイプを組み合せることができます。Oracle Data GuardをOracle RACとともに構成および使用する方法の詳細は、『Oracle Database高可用性概要』を参照してください。

- プライマリ・データベースとスタンバイ・データベースには、それぞれ独自の制御ファイルが必要です。

- スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、スタンバイ・データベースのアーカイブ・ディレクトリは、プライマリ・データベースとは異なるディレクトリ構造を使用する必要があります。同じ構造を使用すると、スタンバイ・データベースがプライマリ・データベース・ファイルを上書きする可能性があります。

- プライマリ・データベースに対して、ログに記録されず、スタンバイ・データベースに伝播できないダイレクト書込みが行われるのを防ぐには、プライマリ・データベースでFORCE LOGGINGをオンにした後で、スタンバイ作成用にデータファイルのバックアップを実行します。スタンバイ・データベースが必要な間は、データベースをFORCE LOGGINGモードに保持してください。

- プライマリ・データベースとスタンバイ・データベースのインスタンスの管理に使用するユーザー・アカウントには、SYSDBAシステム権限が必要です。

- 動作を簡略化するために、Oracle Automatic Storage Management(Oracle ASM)およびOracle Managed Files(OMF)をData Guard構成で設定する際は、プライマリおよびスタンバイ・データベースに対称的に設定することをお薦めします。つまり、移行やメンテナンス用に意図的に混合構成を実装する場合を除き、Data Guard構成のいずれかのデータベースでOracle ASM、OMF、またはその両方を使用する場合は、構成内のすべてのデータベースでもそれぞれOracle ASM、OMFまたはその両方を使用する必要があります。詳細は、13.5項の使用例を参照してください。

注意:
更新の際に時間ベースのデータが使用される一部のアプリケーションでは、複数のタイムゾーンで入力されたデータを処理できないため、ロールの推移後もレコードの時間的順序が維持されるよう、プライマリおよびリモート・スタンバイ・システムに同じタイムゾーンを設定することをお薦めします。

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

各種スタンバイ・データベースのディレクトリ構造によってスタンバイ・データファイル、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイルのパス名が決まるため、ディレクトリ構造は重要です。可能であれば、プライマリ・システムとスタンバイ・システムでデータファイル、ログ・ファイルおよび制御ファイルの名前およびパス名を同一にし、Optimal Flexible Architecture(OFA)のネーミング規則を使用する必要があります。スタンバイ・データベースのアーカイブ・ディレクトリも、サイズおよび構造を含めてサイト間で同一であることが必要です。この方法により、バックアップ、スイッチオーバーおよびフェイルオーバーなどの他の操作を同じ手順で実行できるようになり、メンテナンスの複雑さが軽減されます。

関連項目:
Optimal Flexible Architecture(OFA)の詳細は、オペレーティング・システム固有のOracleドキュメントを参照してください。

同一にしない場合は、ファイル名変換パラメータ(表2-1を参照)を設定するか、データファイルの名前を変更する必要があります。ディレクトリ構造が異なるシステムを使用する必要がある場合や、スタンバイ・データベースとプライマリ・データベースのシステムを同じにする必要がある場合は、管理作業を最小限に抑えるようにしてください。

図2-1に、3つの基本構成オプションを示します。構成オプションは、次のとおりです。

- スタンバイ・データベースがプライマリ・データベースと同じシステムにあるが、プライマリ・システムとは異なるディレクトリ構造を使用する。これは、図2-1のStandby1です。
スタンバイ・データベースをプライマリ・データベースと同じシステムに配置する場合は、異なるディレクトリ構造を使用する必要があります。同じ構造を使用すると、スタンバイ・データベースがプライマリ・データベース・ファイルを上書きしようとします。

- スタンバイ・データベースが別個のシステム上にあり、プライマリ・システムと同じディレクトリ構造を使用する。これは、図2-1のStandby2です。このオプションをお薦めします。

- スタンバイ・データベース別個のシステム上にあり、プライマリ・システムと異なるディレクトリ構造を使用する。これは、図2-1のStandby3です。

注意:
Data Guard構成のいずれかのデータベースでOracle ASM、OMF、またはその両方を使用する場合、構成内のすべてのデータベースでもそれぞれOracle ASM、OMFまたはその両方を使用する必要があります。Data Guard構成でのOMFの設定方法を説明する使用例は、第13章を参照してください。

図2-1 可能なスタンバイ構成

図2-1では、プライマリ・データベースとスタンバイ・データベースの可能な構成およびそれぞれの結果的な注意事項について説明します。

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

スタンバイ・システム

ディレクトリ構造

結果的な注意事項

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

プライマリ・システムと異なる(必須)

- ファイル名を手動で変更するか、スタンバイ・データベースでDB_FILE_NAME_CONVERT初期化パラメータおよびLOG_FILE_NAME_CONVERT初期化パラメータを設定すると、スタンバイ・データベース制御ファイル内のプライマリ・データベースのデータファイル、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイルのパス名を自動的に更新できます。(3.1.4項を参照)。

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

離れたシステム

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

- スタンバイ・データベース制御ファイル内のプライマリ・データベースのファイル名、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイル名を変更する必要はありません。ただし、新しいネーミング計画が必要な場合(複数のディスクにファイルを分散する場合など)は、変更しても構いません。

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

離れたシステム

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

- ファイル名を手動で変更するか、またはスタンバイ・データベースでDB_FILE_NAME_CONVERT初期化パラメータおよびLOG_FILE_NAME_CONVERT初期化パラメータを設定すると、データファイル名を自動的に変更できます(3.1.4項を参照)。

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

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

この章ではフィジカル・スタンバイ・データベースの作成手順を説明します。この章の内容は次のとおりです。

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

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

- 作成後の手順

この章に記載の手順に従うと、デフォルト・データ保護モードである最大パフォーマンス・モード用のスタンバイ・データベースを構成できます。各種データ保護モードの構成の詳細は、第5章を参照してください。

関連項目:

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

- グラフィカル・ユーザー・インタフェースを使用したフィジカル・スタンバイ・データベースの自動作成の詳細は、Oracle Data Guard BrokerとEnterprise Managerのオンライン・ヘルプ・システムを参照してください。

- Recovery Manager(RMAN)を使用したスタンバイ・データベースの作成方法の詳細は、付録Eを参照してください。

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

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

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

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

参照先

タスク

3.1.1項

強制ロギングの有効化

3.1.2項

REDO転送の認証の構成

3.1.3項

REDOデータを受信するためのプライマリ・データベースの構成

3.1.4項

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

3.1.5項

アーカイブの有効化

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

3.1.1 強制ロギングの有効化

プライマリ・データベースをFORCE LOGGINGモードにします。これは、データベース作成後に、次のSQL文を使用して実行できます。

SQL> ALTER DATABASE FORCE LOGGING;

この文を発行する場合、プライマリ・データベースを少なくともマウントしておく(また、オープンもできるようにしておく)必要があります。この文は、完了までに非常に時間がかかる場合があります。これは、ログに記録されないダイレクト書込みI/Oがすべて完了するまで待機するためです。

関連項目:

- FORCE LOGGINGモード指定の影響の詳細は、『Oracle Database管理者ガイド』を参照してください。

3.1.2 REDO転送の認証の構成

Data Guardでは、Oracle Netセッションを使用してData Guard構成のメンバー間でREDOデータを転送し、メッセージを制御します。これらのREDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。

SSLは、次の場合に2つのデータベース間のREDO転送セッションの認証に使用されます。

- データベースが同じOracle Internet Directory(OID)エンタープライズ・ドメインのメンバーであり、現行ユーザーのデータベース・リンクの使用を許可する場合

- データベースに対応するLOG_ARCHIVE_DEST_nおよびFAL_SERVERの各データベース初期化パラメータで、SSL用に構成されたOracle Net接続記述子を使用する場合

- 各データベースに、データベースのOIDエントリの識別名(DN)と一致するDNが付けられたユーザー証明書を格納するOracleウォレットまたはサポートされるハードウェア・セキュリティ・モジュールがある場合

SSL認証の要件が満たされない場合は、リモート・ログイン・パスワード・ファイルを使用するようにData Guard構成の各メンバーを構成する必要があります。また、構成内のすべてのフィジカル・スタンバイ・データベースには、プライマリ・データベースのパスワード・ファイルの最新コピーが必要です。

注意:
SYSDBA権限またはSYSOPER権限を付与または取り消すか、これらの権限を持つユーザーのログイン・パスワードを変更するたびに、構成内の各フィジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースで、パスワード・ファイルをプライマリ・データベースのパスワード・ファイルの最新コピーで置き換える必要があります。

関連項目:

- リモート・ログイン・パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

- 『Oracle Database Advanced Security管理者ガイド』

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

3.1.3 REDOデータを受信するためのプライマリ・データベースの構成

このタスクはオプションですが、Data Guard構成の作成時に、REDOデータを受信するようにプライマリ・データベースを構成することをお薦めします。このベスト・プラクティスに従うことで、プライマリ・データベースは、スタンバイ・ロールに速やかに推移してREDOデータの受信を開始できるようになります。

REDOデータを受信するようにデータベースを構成する方法の詳細は、6.2.3項を参照してください。

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

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

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

データベース

DB_UNIQUE_NAME

Oracle Netサービス名

プライマリ

chicago

chicago

フィジカル・スタンバイ

boston

boston

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

DB_NAME=chicago
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=boston ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc

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

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

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

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

例3-2に示す初期化パラメータを指定すると、プライマリ・データベースがギャップを解決するよう設定され、新しいプライマリ・データベースからの新規データファイルとログ・ファイルのパス名を変換して、このデータベースがスタンバイ・ロールで動作しているときの着信REDOデータがアーカイブされます。説明に従ってプライマリおよびスタンバイ・ロールについて初期化パラメータを設定した場合、ロールの推移後に変更が必要なパラメータはありません。

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

パラメータ

推奨する設定

DB_NAME

プライマリ・データベースで、データベースが作成されたときに使用された名前を指定します。フィジカル・スタンバイ・データベースで、プライマリ・データベースのDB_NAMEを使用します。

DB_UNIQUE_NAME

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

LOG_ARCHIVE_CONFIG

Data Guard機能をすべて有効化するには、このパラメータのDG_CONFIG属性をData Guard構成で明示的に設定する必要があります。構成内の各データベース名のDB_UNIQUE_NAMEを含み、各名前がカンマで区切られたテキスト文字列にDG_CONFIGを設定します。

CONTROL_FILES

プライマリ・データベースの制御ファイルのパス名を指定します。例3-1は2つの制御ファイルに対してこれを行う方法を示しています。制御ファイルの別のコピーを用意しておき、問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後、容易にインスタンスを再開できるようにしておくことをお薦めします。

LOG_ARCHIVE_DEST_n

REDOデータがアーカイブされるプライマリ・システムおよびスタンバイ・システムの位置を指定します。例3-1では、次のようになっています。

- LOG_ARCHIVE_DEST_1と指定すると、プライマリ・データベースにより生成されたREDOデータは、ローカルのオンラインREDOログ・ファイルから/arch1/chicago/にあるローカルのアーカイブREDOログ・ファイルにアーカイブされます。

- LOG_ARCHIVE_DEST_2は、プライマリ・ロールにのみ有効です。この宛先を指定すると、REDOデータはリモート・フィジカル・スタンバイ宛先bostonに転送されます。

注意: 高速リカバリ領域を(DB_RECOVERY_FILE_DEST初期化パラメータを使用して)構成しており、LOCATION属性でローカル・アーカイブ先を明示的に構成していない場合は、デフォルトのローカル・アーカイブ先としてLOG_ARCHIVE_DEST_1初期化パラメータ(まだ設定されていない場合)が自動的に使用されます。また、LOG_ARCHIVE_DEST_nの詳細は、第15章を参照してください。

LOG_ARCHIVE_DEST_STATE_n

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

REMOTE_LOGIN_PASSWORDFILE

リモート・ログイン・パスワード・ファイルを使用して管理ユーザーまたはREDO転送セッションを認証する場合は、このパラメータをEXCLUSIVEまたはSHAREDに設定する必要があります。

LOG_ARCHIVE_FORMAT

スレッド(%t)、順序番号(%s)およびリセットログID(%r)を使用して、アーカイブREDOログ・ファイルのフォーマットを指定します。

FAL_SERVER

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

DB_FILE_NAME_CONVERT

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

LOG_FILE_NAME_CONVERT

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

STANDBY_FILE_MANAGEMENT

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

注意:
変更が必要なその他のパラメータがないか、初期化パラメータ・ファイルを確認してください。たとえばスタンバイ・データベース上のディレクトリ場所がプライマリ・データベースでの指定と異なる場合は、ダンプ先パラメータを変更する必要があります。

3.1.5 アーカイブの有効化

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

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

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

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

この項では、フィジカル・スタンバイ・データベースの作成で実行するタスクについて説明します。この章での詳細な説明内容は、『Oracle Database管理者ガイド』、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』、およびOracle Database Net Services管理者ガイド』で説明している次の内容を十分理解していることが前提になっています。

- データベース管理者の認証

- データベース初期化パラメータ

- REDOログ、データファイルおよび制御ファイルの管理

- アーカイブREDOログの管理

- 高速リカバリ領域

- Oracle Net構成

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

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

参照先

タスク

データベース

3.2.1項

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

プライマリ

3.2.2項

スタンバイ・データベース用の制御ファイルの作成

プライマリ

3.2.3項

スタンバイ・データベース用のパラメータ・ファイルの作成

プライマリ

3.2.4項

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

プライマリ

3.2.5項

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

スタンバイ

3.2.6項

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

スタンバイ

3.2.7項

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

スタンバイ

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

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

データベースのバックアップ方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

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

SQL> STARTUP MOUNT;

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

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

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

3.2.3 スタンバイ・データベース用のパラメータ・ファイルの作成

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

手順1   プライマリ・データベースで使用されるサーバー・パラメータ・ファイル(SPFILE)からパラメータ・ファイル(PFILE)を作成します。

次に例を示します。

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

3.2.5項では、このパラメータ・ファイルをフィジカル・スタンバイ・データベースでの使用に適したパラメータ値が含まれるように変更した後で、このファイルからサーバー・パラメータ・ファイルを作成します。

手順2   前の手順で作成したパラメータ・ファイルのパラメータ値を変更します。

パラメータ・ファイル内の初期化パラメータ設定の大部分はフィジカル・スタンバイ・データベースにも適していますが、一部変更が必要なものがあります。

例3-3では、例3-1および例3-2のパラメータで変更する必要のあるものが太字で示されています。

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

.
.
.
DB_NAME=chicago
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl'
DB_FILE_NAME_CONVERT='chicago','boston'
LOG_FILE_NAME_CONVERT=
'/arch1/chicago/','/arch1/boston/','/arch2/chicago/','/arch2/boston/'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/boston/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2=
'SERVICE=chicago ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
STANDBY_FILE_MANAGEMENT=AUTO
FAL_SERVER=chicago
.
.
.

プライマリ・データベースとスタンバイ・データベースでは、COMPATIBLE初期化パラメータを同じ値に設定する必要があります。値が異なる場合は、REDO転送サービスがREDOデータをプライマリ・データベースからスタンバイ・データベースに転送できない可能性があります。

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

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

パラメータ

推奨する設定

DB_UNIQUE_NAME

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

CONTROL_FILES

スタンバイ・データベースの制御ファイルのパス名を指定します。例3-3は2つの制御ファイルに対してこれを行う方法を示しています。制御ファイルの別のコピーを用意しておき、問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後、容易にインスタンスを再開できるようにしておくことをお薦めします。

DB_FILE_NAME_CONVERT

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

LOG_FILE_NAME_CONVERT

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

LOG_ARCHIVE_DEST_n

REDOデータのアーカイブ先を指定します。例3-3では、次のようになっています。

- LOG_ARCHIVE_DEST_1を指定すると、プライマリ・データから受信したREDOデータは/arch1/boston/のアーカイブREDOログ・ファイルにアーカイブされます。

- LOG_ARCHIVE_DEST_2はプライマリ・ロールのみに有効であるため、この宛先は現在は無視されます。スイッチオーバーが発生して、このインスタンスがプライマリ・データベースになる場合は、REDOデータがリモートのシカゴの宛先に転送されます。

注意: 高速リカバリ領域を(DB_RECOVERY_FILE_DEST初期化パラメータを使用して)構成しており、LOCATION属性でローカル・アーカイブ先を明示的に構成していない場合は、デフォルトのローカル・アーカイブ先としてLOG_ARCHIVE_DEST_1初期化パラメータ(まだ設定されていない場合)が自動的に使用されます。また、LOG_ARCHIVE_DEST_nの詳細は、第15章を参照してください。

FAL_SERVER

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

注意:
変更が必要なその他のパラメータがないか、初期化パラメータ・ファイルを確認してください。たとえばスタンバイ・データベース上のディレクトリ場所がプライマリ・データベースでの指定と異なる場合は、ダンプ先パラメータを変更する必要があります。

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

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

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

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

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

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

次の手順を実行して、Windowsベース・サービスの作成、パスワード・ファイルの作成、Oracle Net環境の設定およびSPFILEの作成を行います。

手順1   Windowsベース・サービスを作成する

スタンバイ・データベースのホストがWindowsシステムである場合、ORADIMユーティリティを使用してWindowsサービスを作成します。次に例を示します。

WINNT> oradim –NEW –SID boston –STARTMODE manual

ORADIMユーティリティの使用の詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。

手順2   リモート・ログイン・パスワード・ファイルをプライマリ・データベース・システムからスタンバイ・データベース・システムにコピーする

プライマリ・データベースにリモート・ログイン・パスワード・ファイルがある場合は、そのファイルをフィジカル・スタンバイ・データベース・システムの適切なディレクトリにコピーします。パスワード・ファイルは、SYSDBA権限またはSYSOPER権限が付与または取り消されるか、これらの権限を持つユーザーのログイン・パスワードが変更されるたびに再コピーする必要があります。

この手順は、オペレーティング・システムの認証を管理ユーザーに使用する場合およびSSLをREDO転送の認証に使用する場合はオプションです。

手順3   プライマリ・データベースとスタンバイ・データベースに対するリスナーを構成する

プライマリ・サイトとスタンバイ・サイトの両方で、Oracle Net Managerを使用して、各データベースに対するリスナーを構成します。

リスナーを再起動して新しい定義を読み込むには、プライマリ・システムとスタンバイ・システムの両方で次のLSNRCTLユーティリティ・コマンドを入力します。

% lsnrctl stop
% lsnrctl start

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

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

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

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

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

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

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

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

手順6   プライマリ・データベースの暗号化ウォレットをスタンバイ・データベース・システムにコピーする

プライマリ・データベースにデータベース暗号化ウォレットがある場合は、スタンバイ・データベース・システムにコピーし、そのウォレットを使用するようにスタンバイ・データベースを構成します。

注意:
データベース暗号化ウォレットは、マスター暗号化キーが更新されるたびに、プライマリ・データベース・システムから各スタンバイ・データベース・システムにコピーする必要があります。
スタンバイ・データベースの暗号化されたデータには、プライマリ・データベースの現行のマスター暗号化キーを格納するデータベース暗号化ウォレットまたはハードウェア・セキュリティ・モジュールを指すように、スタンバイ・データベースが構成されるまでアクセスできません。

関連項目:
データベース暗号化の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

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

フィジカル・スタンバイ・データベースおよびREDO Applyを起動するには、次の手順を実行します。

手順1   フィジカル・スタンバイ・データベースを起動する

スタンバイ・データベースで、次のSQL文を発行してデータベースを起動およびマウントします。

SQL> STARTUP MOUNT;

手順2   REDOデータを受信するためにスタンバイ・データベースを準備する

REDOデータをプライマリ・データベースから受信してアーカイブするように、6.2.3項で説明する手順を実行して、スタンバイ・データベースを準備します。

手順3   スタンバイ・データベースでオンラインREDOログを作成する

この手順はオプションですが、スタンバイ・データベースの作成時に、オンラインREDOログを作成することをお薦めします。このベスト・プラクティスに従うことで、スタンバイ・データベースは、プライマリ・データベース・ロールに速やかに推移できるようになります。

スタンバイ・データベースのオンラインREDOログにおけるREDOログ・グループのサイズおよび数は、スタンバイ・データベースがプライマリ・ロールに推移した場合に十分に機能するように選択する必要があります。

手順4   REDO Applyを開始します。

スタンバイ・データベースで、次のコマンドを発行してREDO Applyを開始します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE -
> DISCONNECT FROM SESSION;

この文にはDISCONNECT FROM SESSIONオプションが指定されているため、REDO Applyはバックグラウンド・セッションで実行されます。詳細は、7.3項「REDOデータのフィジカル・スタンバイ・データベースへの適用」を参照してください。

また、この文にはUSING CURRENT LOGFILE句が指定されているため、REDOを受信後すぐに適用できます。詳細は、7.3.1項「REDO Applyの開始」を参照してください。

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

フィジカル・スタンバイ・データベースを作成してREDO転送サービスを設定した後、データベースの変更がプライマリ・データベースからスタンバイ・データベースに正常に転送されているかどうかの確認が必要な場合があります。

スタンバイ・データベースでREDOデータが受信されていることを確認するには、最初に、スタンバイ・データベースの既存のアーカイブREDOログ・ファイルを識別し、ログ・スイッチを強制実行して、プライマリ・データベースのオンラインREDOログ・ファイルをいくつかアーカイブし、スタンバイ・データベースを再度チェックする必要があります。このタスクの実行手順を次に示します。

手順1   既存のアーカイブREDOログ・ファイルを識別する

スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せて、アーカイブREDOログの既存のファイルを識別します。次に例を示します。

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME -
>  FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# FIRST_TIME         NEXT_TIME
---------- ------------------ ------------------
8 11-JUL-07 17:50:45 11-JUL-07 17:50:53
9 11-JUL-07 17:50:53 11-JUL-07 17:50:58
10 11-JUL-07 17:50:58 11-JUL-07 17:51:03

3 rows selected.

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

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

SQL> ALTER SYSTEM SWITCH LOGFILE;

手順3   新しいREDOデータがスタンバイ・データベースでアーカイブされたことを確認する

スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せて、スタンバイ・データベースでREDOデータが受信およびアーカイブされたことを確認します。

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME -
> FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# FIRST_TIME         NEXT_TIME
---------- ------------------ ------------------
8 11-JUL-07 17:50:45 11-JUL-07 17:50:53
9 11-JUL-07 17:50:53 11-JUL-07 17:50:58
10 11-JUL-07 17:50:58 11-JUL-07 17:51:03
11 11-JUL-07 17:51:03 11-JUL-07 18:34:11
4 rows selected.

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

手順4   受信したREDOの適用を確認する

スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せて、受信したREDOが適用されたことを確認します。

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

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

4行を選択しました。

注意:
最後に受信したログ・ファイルのAPPLIED列の値は、そのログ・ファイルが適用されている場合、IN-MEMORYまたはYESのいずれかです。

3.3 作成後の手順

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

- データ保護モードのアップグレード
Data Guard構成は、最初は最大パフォーマンス・モード(デフォルト)で設定されます。

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

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

この章ではロジカル・スタンバイ・データベースの作成手順を説明します。この章の内容は次のとおりです。

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

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

- 作成後の手順

関連項目:

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

- グラフィカル・ユーザー・インタフェースを使用したロジカル・スタンバイ・データベースの自動作成の詳細は、Oracle Data Guard BrokerとOracle Enterprise Managerのオンライン・ヘルプ・システムを参照してください。

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

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

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

参照先

タスク

4.1.1項

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

4.1.2項

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

ロジカル・スタンバイ・データベースでは、スタンバイREDOログ(SRL)をプライマリ・データベースから受信したREDOに使用しますが、スタンバイ・データベースに変更を適用するため、オンラインREDOログ(ORL)にも書き込みます。そのため、ロジカル・スタンバイ・データベースには、SRLおよびORLを同時にアーカイブするために追加のARCnプロセスが必要になることがあります。さらに、ORLのアーカイブはSRLのアーカイブに優先するため、ワークロードが非常に高いときは、ロジカル・スタンバイにより多くのSRLが必要になる可能性があります。

4.1.1 表のデータ型および記憶域属性のサポートの確認

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

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

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

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

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

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

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

- ファンクション索引は、一意として宣言されている場合でも、変更された行を一意に識別するためには使用できません。しかし、ロジカル・スタンバイ・データベースでは、変更された行を一意に識別できるかぎり、ファンクション索引が定義された表をレプリケーションできます。

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

ロジカル・スタンバイ・データベース内のレプリケートされている各表の行をSQL Applyによって一意に識別できるかどうかを確認するには、次の手順を実行します。

手順1   プライマリ・データベース内の一意ロジカル識別子のない表を検索する

SQL Applyで一意に識別できない可能性がある表のリストを表示するには、DBA_LOGSTDBY_NOT_UNIQUEビューを問い合せます。次に例を示します。

SQL> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE
2> WHERE (OWNER, TABLE_NAME) NOT IN
3> (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED)
4> AND BAD_COLUMN = 'Y';

この問合せの実行には数分間かかる可能性があります。

手順2   無効化されたRELY主キー制約を追加する

アプリケーションで、表内の行が一意であることが保証される場合は、表に無効化されたRELY主キー制約を作成できます。これによって、プライマリ・データベースでの主キーのメンテナンスに関するオーバーヘッドを回避できます。

プライマリ・データベース表で無効化されたRELY制約を作成するには、ALTER TABLE文をRELY DISABLE句と一緒に使用します。次の例では、無効化されたRELY制約がmytabという表に作成されます。各行は、id列とname列を使用して一意に識別されます。

SQL> ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE;

RELY制約を指定すると、システムでは行が一意であると仮定されます。システムには情報に依存するように指示を出しますが、表が変更されるたびに検証は行わないため、表内の各行を一意に識別するRELY制約が無効化されている場合は、十分に注意して列を選択する必要があります。このような一意性が存在しない場合、SQL Applyによる表のメンテナンスが正しく行われません。

SQL Applyのパフォーマンスを改善するには、ロジカル・スタンバイ・データベースで行を識別するために一意制約/索引を列に追加します。追加できない場合は、SQL Applyによって表上でUPDATEまたはDELETE文を実行中に、全表スキャンが実行されます。

関連項目:

- DBA_LOGSTDBY_NOT_UNIQUEビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- ALTER TABLE文の構文とRELY制約作成の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- RELY制約およびロジカル・スタンバイ・データベース上でパフォーマンスを向上させるために行うことができる処理の詳細は、10.7.1項「主キーRELY制約の作成」を参照してください。

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

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

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

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

参照先

タスク

データベース

4.2.1項

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

プライマリ

4.2.2項

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

スタンバイ

4.2.3項

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

プライマリ

4.2.4項

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

スタンバイ

4.2.5項

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

スタンバイ

4.2.6項

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

スタンバイ

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

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

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

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

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

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

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

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

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

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

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

3.1.4項「プライマリ・データベースの初期化パラメータの設定」では、プライマリ・データベースがフィジカル・スタンバイ・ロールに推移する場合に有効になるように、複数のスタンバイ・ロールの初期化パラメータを設定しました。

注意:
この手順は、スイッチオーバーを実行する予定の場合のみ必要です。

プライマリ・データベースをロジカル・スタンバイ・ロールに推移させる場合は、ロールの推移後にパラメータを変更しなくてもよいように、例4-1に太字で示すパラメータを変更する必要もあります。

- 元のLOG_ARCHIVE_DEST_1宛先のVALID_FOR属性を、スタンバイREDOログからではなく、オンラインREDOログからのみREDOデータをアーカイブするように変更します。

- LOG_ARCHIVE_DEST_3宛先をプライマリ・データベースに含めます。このパラメータは、プライマリ・データベースがロジカル・スタンバイ・ロールに推移したときにのみ有効になります。

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

LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_3=
'LOCATION=/arch2/chicago/
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

これらの初期化パラメータを動的に設定するには、SQL ALTER SYSTEM SET文を使用し、変更が即時に有効になってデータベースを停止して再起動した後も存続するようにSCOPE=BOTH句を指定します。

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

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

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

LOG_ARCHIVE_DEST_1

/arch1/chicago/内のローカル・アーカイブREDOログ・ファイルにローカル・オンラインREDOログ・ファイルからプライマリ・データベースによって生成されたREDOデータをアーカイブするよう指示。

/arch1/chicago/内のローカル・アーカイブREDOログ・ファイルにローカル・オンラインREDOログ・ファイルからロジカル・スタンバイ・データベースによって生成されたREDOデータをアーカイブするよう指示。

LOG_ARCHIVE_DEST_3

無視。LOG_ARCHIVE_DEST_3は、chicagoがスタンバイ・ロールで稼働している場合にのみ有効。

/arch2/chicago/内のローカル・アーカイブREDOログ・ファイルにスタンバイREDOログ・ファイルからのREDOデータをアーカイブするよう指示。

4.2.3.2 REDOデータでのディクショナリの作成

LogMinerディクショナリは、SQL ApplyのLogMinerコンポーネントによってREDOでの変更が適切に解釈できるように、REDOデータに構築される必要があります。LogMinerディクショナリの構築の一部として、主キーおよび一意制約/索引列を記録するサプリメンタル・ロギングが自動的に設定されます。サプリメンタル・ロギング情報により、各更新に、文によって変更された各行を論理的に識別するための十分な情報が含まれていることが保証されます。

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

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

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

注意:
Oracle Database 11gリリース2 (11.2)以降を使用して作成されたデータベースでは、サプリメンタル・ロギング情報はすべての既存のフィジカル・スタンバイ・データベースに自動的に伝播されます。ただし、それより前のリリースのデータベースの場合や、それより前のリリースを使用してデータベースを作成してから11.2にアップグレードした場合、サプリメンタル・ロギングがプライマリ・データベースで有効化されているときは、それがフィジカル・スタンバイでも有効化されているかどうかを確認する必要があります。それがフィジカル・スタンバイで有効化されていない場合、スイッチオーバーまたはフェイルオーバーを実行する前に、すべての既存のフィジカル・スタンバイ・データベースでサプリメンタル・ロギングを有効化する必要があります。これを行うには、各フィジカル・スタンバイで次のSQLコマンドを発行します。

SQL>  ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;

これを行わないと、スイッチオーバーやフェイルオーバーがいずれかのフィジカル・スタンバイ・データベースに実行された場合に、同じData Guard構成に含まれるロジカル・スタンバイを使用できなくなります。スイッチオーバーやフェイルオーバーがすでに発生しており、サプリメンタル・ロギングが有効化されていない場合、すべてのロジカル・スタンバイ・データベースを再作成する必要があります。

関連項目:

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_LOGSTDBY.BUILD PL/SQLパッケージ

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

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

この項では、ロジカル・スタンバイ・データベースに推移するために、フィジカル・スタンバイ・データベースを準備する方法について説明します。この付録には、次の項があります。

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

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

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

REDOログには、フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換するために必要な情報が含まれています。

注意:
Oracle RACフィジカル・スタンバイ・データベースがある場合、1つのインスタンス以外はすべて停止して、CLUSTER_DATABASEをFALSEに設定し、次のようにしてスタンバイ・データベースをMOUNT EXCLUSIVEモードで単一インスタンスとして起動します。

SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE;
SQL> SHUTDOWN ABORT;
SQL> STARTUP MOUNT EXCLUSIVE;

ロジカル・スタンバイ・データベースへの変換準備が完了するまでREDOデータをフィジカル・スタンバイ・データベースに適用し続けるには、次のSQL文を発行します。

SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name;

db_nameには、新しいロジカル・スタンバイ・データベースを識別するために、プライマリ・データベースとは異なるデータベース名を指定します。この文の発行時にサーバー・パラメータ・ファイル(spfile)を使用している場合、データベースは、新しいロジカル・スタンバイ・データベースに関する適切な情報でこのファイルを更新します。spfileを使用していない場合は、データベースの停止後にDB_NAMEパラメータの名前を設定するよう求めるメッセージが発行されます。

注意:
フィジカル・スタンバイ・データベースでOracleソフトウェアのローリング・アップグレードを実行する状況で、ロジカル・スタンバイ・データベースを作成するとき、次のコマンドをかわりに発行する必要があります。

SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;

KEEP IDENTITY句で作成されたロジカル・スタンバイ・データベースには、プライマリ・データベースと同じDB_NAMEおよびDBIDが含まれています。このようなロジカル・スタンバイ・データベースは、1回のスイッチオーバー操作にしか使用できないため、フィジカル・スタンバイ・データベースでローリング・アップグレードを実行する状況でのみ作成する必要があります。

KEEP IDENTITY句は、アップグレードするデータベースでOracle Databaseリリース11.1以降が稼働している場合にのみ、使用できます。

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

注意:
Oracle Database 11g以前のリリースでは、ロジカル・スタンバイ・データベースをオープンする前に新しいパスワード・ファイルを作成する必要がありました。現在は、その必要はありません。ロジカル・スタンバイ・データベースに新しいパスワード・ファイルを作成すると、REDO転送サービスが正常に機能しなくなります。

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

注意:
Oracle RACフィジカル・スタンバイ・データベースで開始した場合、次のようにCLUSTER_DATABASEの設定をTRUEに戻します。

SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=SPFILE;

ロジカル・スタンバイ・データベース上でインスタンスをシャットダウンし、STARTUP MOUNT文を発行してデータベースの起動とマウントを行います。データベースは開かないでください。作成手順の後半まで閉じておき、ユーザー・アクセスは行わないでください。次に例を示します。

SQL> SHUTDOWN;
SQL> STARTUP MOUNT;

LOG_ARCHIVE_DEST_nパラメータを変更する必要があります。これは、フィジカル・スタンバイ・データベースとは異なり、ロジカル・スタンバイ・データベースはREDOデータを生成するオープン・データベースであり、複数のログ・ファイル(オンラインREDOログ・ファイル、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイル)があるためです。次のものに対しては、別なローカル宛先を指定することをお薦めします。

- ロジカル・スタンバイ・データベースで生成されたREDOデータを格納するアーカイブREDOログ・ファイル。例4-2では、LOG_ARCHIVE_DEST_1=LOCATION=/arch1/boston宛先として構成されています。

- プライマリ・データベースから受信したREDOデータを格納するアーカイブREDOログ・ファイル。例4-2では、LOG_ARCHIVE_DEST_3=LOCATION=/arch2/boston宛先として構成されています。

例4-2に、ロジカル・スタンバイ・データベース用に変更された初期化パラメータを示します。各パラメータは、ボストンのロジカル・スタンバイ・データベースがプライマリ・データベース・ロールまたはスタンバイ・データベース・ロールで実行されている場合に有効です。

例4-2 ロジカル・スタンバイ・データベース用の初期化パラメータの変更

LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/boston/
VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2=
'SERVICE=chicago ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_3=
'LOCATION=/arch2/boston/
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE

注意:
データベースの互換性を11.1以降に設定した場合、高速リカバリ領域を使用してリモート・アーカイブ・ログを格納することができます。そのためには、次のパラメータを設定する必要があります(すでにDB_RECOVERY_FILE_DESTおよびDB_RECOVERY_FILE_DEST_SIZEパラメータが設定されているとします)。

LOG_ARCHIVE_DEST_1=
'LOCATION=USE_DB_RECOVERY_FILE_DEST
DB_UNIQUE_NAME=boston'

高速リカバリ領域を使用しているため、VALID_FORパラメータは指定する必要はありません。デフォルト値は(ALL_LOGFILES,ALL_ROLES)で、この場合の適切な動作です。LOG_ARCHIVE_DEST_1が、オンライン(プライマリ)およびスタンバイの両方の、全ログ・ファイルに使用されます。

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

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

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

LOG_ARCHIVE_DEST_1

/arch1/boston/内のローカル・アーカイブREDOログ・ファイルにローカル・オンラインREDOログ・ファイルからプライマリ・データベースによって生成されたREDOデータをアーカイブするよう指示。

/arch1/boston/内のローカル・アーカイブREDOログ・ファイルにローカル・オンラインREDOログ・ファイルからロジカル・スタンバイ・データベースによって生成されたREDOデータをアーカイブするよう指示。

LOG_ARCHIVE_DEST_2

リモート・ロジカル・スタンバイ・データベースchicagoにREDOデータを転送するよう指示。

無視。LOG_ARCHIVE_DEST_2は、bostonがプライマリ・ロールで稼働している場合にのみ有効。

LOG_ARCHIVE_DEST_3

無視。LOG_ARCHIVE_DEST_3は、bostonがスタンバイ・ロールで稼働している場合にのみ有効。

/arch2/boston/内のローカル・アーカイブREDOログ・ファイルにプライマリ・データベースから受信したREDOデータをアーカイブするよう指示。

注意:
DB_FILE_NAME_CONVERT初期化パラメータは、フィジカル・スタンバイ・データベースがロジカル・スタンバイ・データベースに変換された後は考慮されません。必要な場合は、スキップ・ハンドラを登録し、プライマリ・データベースのデータファイルのパス名をスタンバイ・データファイルのパス名に変換することで、実行対象のかわりとなるDDL文字列をSQL Applyに提供します。SKIPプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_LOGSTDBYパッケージを参照してください。

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

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

SQL> ALTER DATABASE OPEN RESETLOGS;

注意:
Oracle RACフィジカル・スタンバイ・データベースで開始した場合、その他のすべてのスタンバイ・インスタンスをこの時点で開始できます。

注意:
ロジカル・スタンバイ・データベースをプライマリ・データベースと同じコンピュータ・システム上に配置している場合、SQL Applyを初めて開始する前に次のSQL文を発行し、SQL Applyがプライマリ・データベースで実行されるファイル操作をスキップするようにする必要があります。この文の発行が必要な理由は、SQL Applyはプライマリ・データベースと同じディレクトリ構造にアクセスできるので、特定のファイル固有の操作を再実行しようとした場合に、プライマリ・データベースに属するデータファイルが破損する可能性があるためです。

SQL> EXECUTE DBMS_LOGSTDBY.SKIP('ALTER TABLESPACE');

フィジカル・データベースをプライマリ・データベースと同じシステム上に配置する際に設定したDB_FILENAME_CONVERTパラメータは、SQL Applyでは無視されます。DBMS_LOGSTDBY.SKIPおよびロジカル・スタンバイ・データベースのコンテキストでの同等な動作の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

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

注意:
Oracle Databaseソフトウェアのローリング・アップグレードを実行するために、ロジカル・スタンバイ・データベースを作成する場合、初めてSQL Applyを開始する前に、ロジカル・スタンバイ・データベースでDBMS_LOGSTDBY PL/SQLプロシージャを使用して、プライマリ・データベースで実行されておりロジカル・スタンバイ・データベースではサポートされないトランザクションに関する情報を取得することをお薦めします。次のプロシージャを実行して情報を取得し、DBA_LOGSTDBY_EVENTS表にイベントとして記録します。

EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',
DBMS_LOGSTDBY.MAX_EVENTS);

EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');

関連項目:

- DBA_LOGSTDBY_EVENTSビューの詳細は、10.5.1項「DBA_LOGSTDBY_EVENTSビューでのイベントのロギングのカスタマイズ」を参照してください。

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

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

SQL>  ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

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

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

- 第6章「REDO転送サービス」

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

4.3 作成後の手順

注意:
フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースへの変換は、次のように2段階で行われます。

1. ALTER DATABASE RECOVER TO LOGICAL STANDBY文(KEEP IDENTITY句を指定した場合を除く)の処理の一部として、データベースのDBIDが変更されます。

2. ALTER DATABASE START LOGICAL STANDBY APPLY文が最初に正常に実行されたとき、処理の一部として制御ファイルが更新され、新たに作成されたロジカル・スタンバイ・データベースの制御ファイルと一致するようになります。
ALTER DATABASE START LOGICAL STANDBY APPLY文の起動に成功した後で、ロジカル・スタンバイ・データベースの全体バックアップを作成する必要があります。ロジカル・スタンバイ・データベースをリストアする際には、プライマリ・データベースから作成したバックアップを使用できないためです。

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

- データ保護モードのアップグレード
Data Guard構成は、最初は最大パフォーマンス・モード(デフォルト)で設定されます。

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

5 Data Guardの保護モード

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

- Data Guardの保護モード

- プライマリ・データベースのデータ保護モードの設定

5.1 Data Guardの保護モード

この項では、Data Guardの保護モードについて説明します。

ここでの説明では、同期化されたスタンバイ・データベースは、構成されたデータ保護モードの最低要件を満たし、REDOギャップがないデータベースとして作成されています。REDOギャップの詳細は、6.4.3項を参照してください。

最大可用性

この保護モードは、プライマリ・データベースの可用性を低下させない範囲で可能な最高レベルのデータ保護を提供します。トランザクションは、そのトランザクションのリカバリに必要なすべてのREDOデータが、オンラインREDOログおよび少なくとも1つの同期化されたスタンバイ・データベース上のスタンバイREDOログに書き込まれるまでコミットされません。プライマリ・データベースは、REDOストリームを少なくとも1つの同期化されたスタンバイ・データベースに書き込むことができない場合、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つのスタンバイ・データベースの障害が原因でプライマリ・データベースが停止しないようにします。

注意:
非同期でコミットされたトランザクションは、そのトランザクションで生成されたREDOが、少なくとも1つの同期スタンバイ・データベースのスタンバイREDOログに書き込まれるまで、データ消失に対してData Guardの保護を受けません。
非同期コミット機能の詳細は、次のドキュメントを参照してください。

- 『Oracle Database概要』

- 『Oracle Database SQL言語リファレンス』

- 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』

- 『Oracle Database PL/SQL言語リファレンス』

5.2 プライマリ・データベースのデータ保護モードの設定

次の手順を実行して、プライマリ・データベースのデータ保護モードを設定します。

手順1   可用性、パフォーマンスおよびデータ保護の要件を満たすデータ保護モードを選択する

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

手順2   少なくとも1つのスタンバイ・データベースが、必要なデータ保護モードの転送要件を満たしていることを検証する

少なくとも1つのスタンバイ・データベースに対応するLOG_ARCHIVE_DEST_nデータベース初期化パラメータには、表5-1にリストされている、必要なデータ保護モードに対応するREDO転送属性が含まれている必要があります。

また、スタンバイ・データベースにはスタンバイREDOログが必要です。

REDO転送およびスタンバイREODログの構成の詳細は、第6章「REDO転送サービス」を参照してください。

表5-1 データ保護モードに対するREDO転送の必須属性

最大可用性

最大パフォーマンス

最大保護

AFFIRM

NOAFFIRM

AFFIRM

SYNC

ASYNC

SYNC

DB_UNIQUE_NAME

DB_UNIQUE_NAME

DB_UNIQUE_NAME

手順3   プライマリ・データベースおよび各スタンバイ・データベースでDB_UNIQUE_NAMEデータベース初期化パラメータが一意の値に設定されていることを確認する

手順4   LOG_ARCHIVE_CONFIGデータベース初期化パラメータがプライマリ・データベースおよび各スタンバイ・データベースに定義されていて、プライマリ・データベースおよび各スタンバイ・データベースのDB_UNIQUE_NAMEを含むDG_CONFIGリストが、その値に指定されていることを確認する

たとえば、LOG_ARCHIVE_CONFIGパラメータの構成には、次のSQL文が使用されることがあります。

SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(CHICAGO,BOSTON)';

手順5   データ保護モードを設定する

次のSQL文はプライマリ・データベースで実行します。

SQL> ALTER DATABASE -
> SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY | PERFORMANCE | PROTECTION};

オープン状態のデータベースでデータ保護モードをMAXIMUM PROTECTIONに設定できるのは、現在のデータ保護モードがMAXIMUM AVAILABILITYで、同期されているスタンバイ・データベースが少なくとも1つある場合のみです。

手順6   プライマリ・データベースが新しい保護モードで動作していることを確認する

次の問合せをプライマリ・データベースで実行し、新しい保護モードで動作していることを確認します。

SQL> SELECT PROTECTION_MODE FROM V$DATABASE;

6 REDO転送サービス

この章では、Oracle REDO転送サービスを構成および監視する方法について説明します。次の項目で構成されています。

- REDO転送サービスの概要

- REDO転送サービスの構成

- カスケードされたREDO転送先

- REDO転送サービスの監視

- REDO転送のチューニング

6.1 REDO転送サービスの概要

REDO転送サービスは、Oracleデータベース間でREDOデータの自動転送を実行します。次のREDO転送先がサポートされています。

- Oracle Data Guardスタンバイ・データベース
このマニュアルでは、スタンバイ・データベースを作成および管理する方法について説明します。

- アーカイブ・ログ・リポジトリ
この宛先タイプは、アーカイブREDOログ・ファイルの一時オフサイト記憶域に使用されます。アーカイブ・ログ・リポジトリは、Oracleデータベース・インスタンスとフィジカル・スタンバイ制御ファイルで構成されます。アーカイブ・ログ・リポジトリにはデータファイルが含まれないため、ロールの推移はサポートできません。

アーカイブ・ログ・リポジトリの作成に使用される手順は、データファイルのコピーを除いて、フィジカル・スタンバイ・データベースの作成に使用される手順と同じです。

- Oracle Streamsダウンストリーム取得データベース
Oracle Streamsダウンストリーム・キャプチャ・データベースの詳細は、『Oracle Streams概要および管理』を参照してください。

- Oracle Change Data Captureステージング・データベース
Oracle Change Data Captureステージング・データベースの詳細は、Oracle Warehouse Builderソースおよびターゲット・ガイドを参照してください。

Oracleデータベースでは、REDOデータを最大30個のREDO転送先に送信できます。各REDO転送先は、次の2つのREDO転送モードのいずれかによりREDOデータを受信するように、個別に構成されます。

- 同期
同期REDO転送モードは、REDOデータをトランザクション・コミットに対して同期させて転送します。トランザクションによって生成されたすべてのREDOが、同期REDO転送モードを使用する使用可能なREDO転送先すべてに正常に送信されるまで、そのトランザクションはコミットできません。

プライマリ・データベースとSYNC REDO転送先の間の距離に制限はありませんが、プライマリ・データベースとSYNC REDO転送先の間のネットワーク待機時間が長くなるに従って、トランザクションのコミットの待機時間も長くなります。

この転送モードは、最大保護および最大可用性の各データ保護モード(第5章「Data Guardの保護モード」を参照)で使用されます。

- 非同期
非同期REDO転送モードは、REDOデータをトランザクション・コミットに対して非同期で転送します。トランザクションによって生成されたすべてのREDOが、非同期REDO転送モードを使用するREDO転送先すべてに正常に送信されるまで待機しなくても、そのトランザクションはコミットできます。

この転送モードは、最大パフォーマンス・データ保護モード(第5章「Data Guardの保護モード」を参照)で使用されます。

6.2 REDO転送サービスの構成

この項では、REDO転送サービスの構成方法について説明します。次の項目で構成されています。

- REDO転送のセキュリティ

- REDOデータを送信するためのOracleデータベースの構成

- REDOデータを受信するためのOracleデータベースの構成

この項での詳細な説明内容は、読者が『Oracle Database管理者ガイド』、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』、およびOracle Database Net Services管理者ガイド』で説明している次の内容を十分理解していることが前提になっています。

- データベース管理者の認証

- データベース初期化パラメータ

- REDOログの管理

- アーカイブREDOログの管理

- 高速リカバリ領域

- Oracle Net構成

6.2.1 REDO転送のセキュリティ

REDO転送では、Oracle Netセッションを使用してREDOデータを転送します。これらのREDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。

6.2.1.1 SSLを使用したREDO転送の認証

Secure Sockets Layer(SSL)は、ネットワーク接続を保護するための業界標準プロトコルです。SSLでは、RSA公開鍵暗号化および対称鍵暗号化を使用して、認証、暗号化およびデータ整合性を提供します。SSLは、次の場合に2つのOracleデータベース間のREDO転送の認証に自動的に使用されます。

- データベースが同じOracle Internet Directory(OID)エンタープライズ・ドメインのメンバーであり、そのドメインが現行ユーザーのデータベース・リンクの使用を許可する場合

- データベースに対応するLOG_ARCHIVE_DEST_nおよびFAL_SERVERの各データベース初期化パラメータで、SSL用に構成されたOracle Net接続記述子を使用する場合

- 各データベースに、データベースのOIDエントリの識別名(DN)と一致するDNが付けられたユーザー証明書を格納するOracleウォレットまたはサポートされるハードウェア・セキュリティ・モジュールがある場合

関連項目:

- SSL認証構成の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

- エンタープライズ・ドメイン管理の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- Oracle Internet Directoryの管理方法の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。

6.2.1.2 パスワード・ファイルを使用したREDO転送の認証

SSL認証要件を満たしていない場合、各データベースはリモート・ログイン・パスワード・ファイルを使用する必要があります。Data Guard構成では、すべてのフィジカルおよびスナップショット・スタンバイ・データベースはプライマリ・データベースからパスワード・ファイルのコピーを使用する必要があり、SYSOPERまたはSYSDBA権限を付与または解除されるたびに、あるいはこれらの権限を持つユーザーのパスワード変更後、このコピーのリフレッシュが必要です。

REDO転送の認証にパスワード・ファイルを使用する場合、REDO転送の認証に使用されるユーザー・アカウントのパスワードは、REDO転送セッションを開始したデータベースとターゲット・データベース間で比較されます。REDO転送セッションを確立するには、パスワードが両方のデータベースで一致する必要があります。

デフォルトでは、パスワード・ファイルを使用する場合、SYSユーザーのパスワードがREDO転送セッションの認証に使用されます。REDO_TRANSPORT_USERデータベース初期化パラメータを使用して、SYSOPER権限が付与されたユーザー名を設定すると、REDO転送の認証用に別のユーザー・パスワードを選択できます。管理しやすくするために、REDO_TRANSPORT_USERパラメータをREDOソース・データベースおよび各REDO転送宛先で同じ値に設定することをお薦めします。

関連項目:
リモート・ログイン・パスワード・ファイルの作成とメンテナンスの詳細は、『Oracle Database管理者ガイド』を参照してください。

6.2.2 REDOデータを送信するためのOracleデータベースの構成

この項では、REDOデータをREDO転送先に送信するようにOracleデータベースを構成する方法について説明します。

LOG_ARCHIVE_DEST_nデータベース初期化パラメータ(nは1から31の整数)を使用して、ローカルのアーカイブREDOログの位置を指定するか、REDO転送先を指定します。この項では、このパラメータの後者の使用について説明します。

各LOG_ARCHIVE_DEST_nパラメータに対応するLOG_ARCHIVE_DEST_STATE_nデータベース初期化パラメータ(nは1から31の整数)があります。このパラメータを使用すると、対応するREDO転送先を有効または無効にできます。表6-1に、このパラメータに割り当てることができる有効な値を示します。

表6-1 LOG_ARCHIVE_DEST_STATE_n初期化パラメータの値

値

説明

ENABLE

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

DEFER

REDO転送サービスはこの宛先にREDOデータを転送しない。

ALTERNATE

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

REDO転送先は、LOG_ARCHIVE_DEST_nパラメータを、1つ以上の属性を含む文字列に設定して構成します。この項では、最も一般的に使用される属性について簡単に説明します。すべてのLOG_ARCHIVE_DEST_nパラメータの属性の詳細は、第15章を参照してください。

SERVICE属性は、REDO転送先の必須属性で、属性リストの最初に指定する必要があります。SERVICE属性は、REDO転送先への接続に使用されるOracle Netサービス名の指定に使用されます。サービス名は、Oracle Netネーミング・メソッドによって、REDO転送先のOracle Netリスナーと一致するOracle Net接続記述子に解決できる必要があります。この接続記述子は、REDO転送先のデフォルト接続タイプでないかぎり、専用サーバー接続を使用するように指定する必要があります。

関連項目:
Oracle Netサービス名、接続記述子、リスナー、ネットワーク・セキュリティの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

SYNC属性は、同期REDO転送モードを使用してREDOデータをREDO転送先に送信するように指定するために使用します。

ASYNC属性は、非同期REDO転送モードを使用してREDOデータをREDO転送先に送信するように指定するために使用します。非同期REDO転送モードは、SYNC属性とASYNC属性のどちらも指定されない場合に使用されます。

NET_TIMEOUT属性は、LGWRプロセスが、同期REDO転送モードを使用する転送先でREDOデータが正常に受信されたことの確認待ちをブロックする時間を指定するために使用します。確認がNET_TIMEOUTの秒数内に受信されない場合は、REDO転送接続は終了し、エラーがログに記録されます。

同期REDO転送モードを使用する場合は常にNET_TIMEOUT属性を指定して、REDO転送障害によるREDOソース・データベースの最大停止期間を厳密に制御できるようにすることをお薦めします。同期REDO転送モードのレスポンス時間の監視の詳細は、6.4.2項を参照してください。

AFFIRM属性は、REDOソース・データベースから受信されたREDOが、スタンバイREDOログに書き込まれるまで確認されないように指定するために使用します。NOAFFIRM属性は、受信されたREDOが、スタンバイREDOログに書き込まれるのを待機せずに確認されるように指定するために使用します。

DB_UNIQUE_NAME属性は、REDO転送先のDB_UNIQUE_NAMEを指定するために使用します。DB_UNIQUE_NAME属性は、LOG_ARCHIVE_CONFIGデータベース初期化パラメータが定義されていて、その値にDG_CONFIGリストが指定されている場合に指定する必要があります。

DB_UNIQUE_NAME属性を指定する場合、その値はDG_CONFIGリスト内のDB_UNIQUE_NAME値のいずれかと一致している必要があります。また、REDO転送先のDB_UNIQUE_NAMEデータベース初期化パラメータの値とも一致している必要があります。いずれかが一致していない場合、エラーがログに記録され、その宛先にREDO転送を行うことはできません。

VALID_FOR属性は、REDO転送サービスがREDOデータをREDO転送先に転送する時期を指定するために使用します。Data Gurad構成内のすべてのサイトでREDO転送先ごとにVALID_FOR属性を指定して、どのスタンバイ・データベースがプライマリ・ロールを担うかに関係なく、ロールの推移後もREDO転送サービスがすべてのスタンバイ・データベースに引き続きREDOデータを送信するようにすることをお薦めします。

REOPEN属性は、前回のエラーにより非アクティブなREDO転送先への自動再接続試行の最低間隔(秒数)を指定するために使用します。

COMPRESSION属性は、REDOデータを圧縮した形式でREDO転送先に転送するよう指定するために使用します。REDO転送を圧縮することにより、帯域幅が小さく待機時間が長いネットワーク・リンクにおいてREDO転送のパフォーマンスを大幅に向上できます。

REDO転送の圧縮は、Oracle Advanced Compressionオプションの機能です。REDO転送の圧縮機能を使用する前に、このオプションのライセンスを購入する必要があります。

次の例では、この項で説明したLOG_ARCHIVE_DEST_nの属性をすべて使用しています。DB_UNIQUE_NAMEは、圧縮の使用と同じく、両方の宛先に指定されています。REDO転送障害がいずれかの宛先で発生した場合、REDO転送はその宛先への再接続を試行しますが、60秒に1回より長い間隔で行います。

DB_UNIQUE_NAME=BOSTON
LOG_ARCHIVE_CONFIG='DG_CONFIG=(BOSTON,CHICAGO,HARTFORD)'
LOG_ARCHIVE_DEST_2='SERVICE=CHICAGO ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILE,
PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE  DB_UNIQUE_NAME=CHICAGO'
LOG_ARCHIVE_DEST_STATE_2='ENABLE'
LOG_ARCHIVE_DEST_3='SERVICE=HARTFORD SYNC AFFIRM NET_TIMEOUT=30
VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE
DB_UNIQUE_NAME=HARTFORD'
LOG_ARCHIVE_DEST_STATE_3='ENABLE'

6.2.2.1 V$ARCHIVE_DESTビューを使用した属性の表示

V$ARCHIVE_DESTビューを問い合せると、REDO転送先ごとに現行の設定およびステータスを確認できます。

6.2.3 REDOデータを受信するためのOracleデータベースの構成

この項では、REDOソース・データベースからREDOデータを受信およびアーカイブするように、REDO転送先を構成する方法について説明します。

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

- スタンバイREDOログの作成および管理

- スタンバイREDOログ・アーカイブの構成

- REDOがアーカイブREDOログ・ファイルに直接書き込まれる場合

6.2.3.1 スタンバイREDOログの作成および管理

同期および非同期のREDO転送モードでは、REDO転送先にスタンバイREDOログが必要です。スタンバイREDOログは、別のOracleデータベースから受信されたREDOを格納するために使用します。スタンバイREDOログは、構造的にはREDOログと同じで、REDOログの作成および管理に使用するのと同じSQL文を使用して作成および管理します。

別のOracleデータベースからREDO転送を介して受信されたREDOは、RFSフォアグラウンド・プロセスにより、現行のスタンバイREDOログ・グループに書き込まれます。REDOソース・データベースでログ・スイッチが発生すると、着信REDOは次のスタンバイREDOログ・グループに書き込まれ、前に使用されたスタンバイREDOログ・グループはARCnフォアグラウンド・プロセスによってアーカイブされます。

REDOソース・データベースでREDOログ・ファイル・グループを順次いっぱいにしてアーカイブするプロセスは、スタンバイREDOログ・グループを順次いっぱいにしてアーカイブすることで、各REDO転送先でミラーリングされます。

各スタンバイREDOログ・ファイルは、少なくともREDOソース・データベースのREDOログで最も大きなREDOログ・ファイルと同じ大きさである必要があります。管理しやすくするために、REDOソース・データベースのREDOログの全REDOログ・ファイルとREDO転送先のスタンバイREDOログは同じサイズにすることをお薦めします。

スタンバイREDOログには、REDOソース・データベースのREDOスレッドごとに、REDOソース・データベースのREDOログより少なくとも1つ多いREDOログ・グループが必要です。REDOソース・データベースで、REDOソース・データベースのREDOログにいくつREDOログ・グループがあるかを確認するためにV$LOGビューに問合せを行い、REDOソース・データベースにいくつREDOスレッドが存在するかを確認するためにV$THREADビューに問合せを行います。

REDOソース・データベースで次の問合せを実行し、REDOログの各ログ・ファイルのサイズおよびログ・グループ数を確認します。

SQL> SELECT GROUP#, BYTES FROM V$LOG;

REDO転送先データベースで次の問合せを実行し、スタンバイREDOログの各ログ・ファイルのサイズおよびログ・グループ数を確認します。

SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;

スタンバイREDOログは、Data Guard構成のプライマリ・データベースに作成して、スタンバイ・ロールへのスイッチオーバー後すぐにREDOデータを受信できるようにすることをお薦めします。

ALTER DATABASE ADD STANDBY LOGFILE SQL文を使用して、スタンバイREDOログを作成し、スタンバイREDOログ・グループを既存のスタンバイREDOログに追加します。

たとえば、REDOソース・データベースのREDOログに2つのREDOログ・グループがあり、各グループには500MBのREDOログ・ファイルが1つずつ含まれているとします。この場合、REDOソース・データベースのREDOログよりREDOログ・グループが少なくとも1つ多く必要であるという要件を満たすため、スタンバイREDOログには、3つ以上のスタンバイREDOログ・グループが必要です。

次のSQL文を使用すると、この使用例に適したスタンバイREDOログを作成できます。

SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog1.rdo') SIZE 500M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog2.rdo') SIZE 500M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog3.rdo') SIZE 500M;

REDOソース・データベースがOracle Real Applications Cluster(Oracle RAC)またはOracle One Nodeデータベースの場合、REDOソース・データベースのV$LOGビューに問合せを行い、いくつREDOスレッドが存在するかを確認し、スタンバイREDOログにREDOログ・グループを追加する際に、対応するスレッド数を指定します。

たとえば、2つのREDOスレッドを持つREDOソース・データベースからREDOを受信するためのスタンバイREDOログをデータベースに作成するには、次のSQL文が使用されます。

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M;

注意:
REDOログ・グループをプライマリ・データベースに1つ追加するたびに、構成内の各スタンバイ・データベースのスタンバイREDOログにもログ・グループを1つ追加する必要があります。そうしないと、プライマリ・ログ・スイッチ後にスタンバイ・データベースが非同期化する可能性があり、その結果、一時的にデータ消失のないフェイルオーバーが機能しなくなったり、最大保護モードで稼働しているプライマリ・データベースが停止したりしかねません。

6.2.3.2 スタンバイREDOログ・アーカイブの構成

この項では、スタンバイREDOログ・アーカイブの構成方法について説明します。

関連項目:

- アーカイブ保存されたREDOログの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 高速リカバリ領域の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

6.2.3.2.1 アーカイブの有効化

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

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

スタンバイREDOログ・アーカイブを実行するには、データベースはARCHIVELOGモードである必要があります。

6.2.3.2.2高速リカバリ領域へのスタンバイREDOログ・アーカイブ

次の手順を実行して、スタンバイREDOログ・アーカイブを高速リカバリ領域に設定します。

1. LOG_ARCHIVE_DEST_nパラメータのLOCATION属性をUSE_DB_RECOVERY_FILE_DESTに設定します。

2. 同じLOG_ARCHIVE_DEST_nパラメータのVALID_FOR属性をスタンバイREDOログ・アーカイブを許可する値に設定します。

次に、スタンバイREDOログを高速リカバリ領域にアーカイブするようにフィジカル・スタンバイ・データベースを構成するために使用されるパラメータ値のサンプルをいくつか示します。

LOG_ARCHIVE_DEST_2 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

アーカイブREDOログ・ファイルの管理が簡素化されるため、高速リカバリ領域の使用をお薦めします。

6.2.3.2.3 ローカル・ファイル・システムの場所へのスタンバイREDOログ・アーカイブ

次の手順を実行して、スタンバイREDOログ・アーカイブをローカル・ファイル・システムの場所に設定します。

1. LOG_ARCHIVE_DEST_nパラメータのLOCATION属性を有効なパス名に設定します。

2. 同じLOG_ARCHIVE_DEST_nパラメータのVALID_FOR属性をスタンバイREDOログ・アーカイブを許可する値に設定します。

次に、スタンバイREDOログをローカル・ファイル・システムの場所にアーカイブするようにフィジカル・スタンバイ・データベースを構成するために使用されるパラメータ値のサンプルをいくつか示します。

LOG_ARCHIVE_DEST_2 = 'LOCATION = /disk2/archive
VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

6.2.3.3 REDOがアーカイブREDOログ・ファイルに直接書き込まれる場合

スタンバイ・データベースにより受信されたREDOは、スタンバイREDOログ・グループが使用できない場合、またはREDOギャップを解決するためにREDOが送信された場合に、アーカイブREDOログ・ファイルに直接書き込まれます。これが行われた場合、別のデータベースから受信したアーカイブREDOについて有効なREDOはLOG_ARCHIVE_DEST_nパラメータのLOCATION属性で指定された場所に書き込まれます。この目的で使用されるLOG_ARCHIVE_DEST_nパラメータは、スタンバイ・データベースのマウント時に決定され、LOG_ARCHIVE_DEST_nパラメータが修正されるたびに、再評価されます。

6.3 カスケードされたREDO転送先

注意:
この項で説明しているOracle Data GuardのカスケードREDO転送宛先機能を使用するには、Oracle Database 11gリリース2(11.2.0.2)以上を使用する必要があります。11.2.0.2以前のリリースではこの機能に対する制約がいくつかあります。11.2.0.2以上にはこの種の制約はありません。

カスケードされたREDO転送先では、プライマリ・データベースREDOを、プライマリ・データベースから直接にではなく、スタンバイ・データベースから間接的に受信します。

プライマリ・データベースREDOを1つ以上のカスケードされた転送先にカスケードするスタンバイ・データベースは、カスケード・スタンバイ・データベースとして知られています。

カスケードにより、プライマリ・データベースからカスケード・スタンバイ・データベースへのREDO転送の実行に関連したオーバーヘッドが軽減されます。

カスケード・スタンバイ・データベースは、最高30か所のカスケードされた宛先(フィジカル、ロジカル、またはスナップショット・スタンバイ・データベース)まで、プライマリ・データベースのREDOをカスケードできます。

プライマリ・データベースのREDOは、スタンバイ・データベースでの受信と同時にスタンバイREDOログに書込まれます。ただしREDOはすぐにカスケードされません。書込み先のスタンバイREDOログ・ファイルがローカルにアーカイブ保存された後でカスケードされます。したがってプライマリ・データベースについては、カスケード・スタンバイ・データベースよりもカスケード先のほうが常にREDO転送ラグが大きくなります。

カスケードには、次の制限があります。

- フィジカル・スタンバイ・データベースは、REDOをカスケードできる唯一のスタンバイ・データベースのタイプ

- Data Guard Brokerではカスケードされた宛先をサポートしない

この項の残りの部分には、次の情報が記載されています。

- カスケードされた宛先の構成

- データ保護の考慮事項

- カスケードのシナリオ

6.3.1 カスケードされた宛先の構成

カスケードされた宛先を構成するには、次の手順を実行します。

1. カスケード・スタンバイ・データベースとして構成するフィジカル・スタンバイ・データベースを選択します。

2. カスケード・スタンバイ・データベースで、FAL_SERVER属性をプライマリ・データベース、またはプライマリ・データベースからREDOを直接受信するスタンバイ・データベースのOracle Net別名を指定して構成します。

3. カスケード・スタンバイ・データベースで、カスケードされた宛先のLOG_ARCHIVE_DEST_nデータベース初期化パラメータを構成します。この宛先のSERVICE属性にカスケードされた宛先のOracle Net別名を指定し、スタンバイ・ロールである間にスタンバイREDOログのアーカイブが有効になるようにVALID属性を構成します。
SYNCまたはASYNC REDO転送属性が指定されている場合、それらは無視されます。

4. カスケードされた宛先では、FAL_SERVERデータベース初期化パラメータに、カスケード・スタンバイ・データベース、またはプライマリ・データベースに直接接続されている別のスタンバイ・データベースのOracle Net別名を指定して構成します。プライマリ・データベースを指定することも可能ですが、そうするとプライマリ・データベースでのREDO転送オーバーヘッドを減らすというカスケードの目的が果たせなくなります。

5. 例6-1は、bostonというプライマリ・データベースがREDOをboston2というローカル・フィジカル・スタンバイ・データベースに送信し、そこからプライマリ・データベースREDOがdenverというリモート・フィジカル・スタンバイ・データベースにカスケードされるというData Guard構成のメンバーによって使用されるいくつかのデータベース初期化パラメータを示しています。
LOG_ARCHIVE_DEST_nデータベース初期化パラメータは、データベースbostonがスタンバイ・ロールのときに、データベースdenverに対するスタンバイREDOログ・アーカイブとして有効なデータベースbostonでも構成できることに注意してください。これにより、データベースbostonとデータベースboston2の間でスイッチオーバーが実行された場合でも、データベースdenverへのREDOカスケードが続行可能になります。

例6-1 REDOのカスケード時に使用される初期化パラメータの一部

プライマリ・データベース

DB_UNIQUE_NAME=boston

FAL_SERVER=boston2

LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'

LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston'

LOG_ARCHIVE_DEST_2='SERVICE=boston2 SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston2'

カスケードしているフィジカル・スタンバイ・データベース

DB_UNIQUE_NAME=boston2

FAL_SERVER=boston

LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(boston,boston2,denver)'

LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston2'

LOG_ARCHIVE_DEST_2= 'SERVICE=denver
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'

カスケードされたフィジカル・スタンバイ・データベース

DB_UNIQUE_NAME=denver

FAL_SERVER=boston2

LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'

LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver'

6.3.2 データ保護の考慮事項

障害時リカバリを主目的とするスタンバイ・データベースでは、REDOデータをプライマリ・データベースから直接受信することをお薦めします。これは、最高レベルのデータ保護となります。カスケードされたスタンバイ・データベースは、第2防御ラインとして利用できますが、本質的にREDOをプライマリから直接受信するスタンバイ・データベースより、受信するプライマリ・データベースREDOの数が常に少なくなります。

6.3.3 カスケードのシナリオ

この項では、2つの典型的なカスケードのシナリオについて説明します。

- フィジカル・スタンバイへのカスケード

- 複数のフィジカル・スタンバイへのカスケード

6.3.3.1 フィジカル・スタンバイへのカスケード

このシナリオでは、きわめて重要なプライマリ・データベースがあります。このデータベースにはパフォーマンスやデータ保護に厳しい要件があるため、ローカルのフィジカル・スタンバイ・データベースをデプロイして、データ消失のない保護と、プライマリ・データベースとローカル・スタンバイ・データベースのサイトで地域災害に備えるための、カスケードされたリモート・フィジカル・スタンバイ・データベースを準備することに決定しました。

次の手順を実行することで、前述の目的を達成できます。

1. ローカル・サイトにフィジカル・スタンバイ・データベースを作成します。

2. プライマリ・データベースとローカル・スタンバイ・データベースのサイトでの地域災害に対する保護策として、十分に遠く離れたサイトでフィジカル・スタンバイ・データベースを作成します。

3. ローカル・スタンバイ・データベースを、プライマリ・データベースのSYNC REDO転送先として構成します。

4. リモート・フィジカル・スタンバイ・データベースを、ローカル・スタンバイ・データベースのカスケードされた宛先として構成します。

6.3.3.2 複数のフィジカル・スタンバイへのカスケード

このシナリオでは、北アメリカにプライマリ・データベースがあり、読取り専用のレポート生成アプリケーションをサポートするために、ヨーロッパにこのデータベースのレプリカを3つデプロイしようと考えています。コストおよびパフォーマンス上の理由から、北アメリカからヨーロッパの各サイトへのネットワーク・リンクを維持しないつもりです。

次の手順を実行することで、前述の目的を達成できます。

1. 北アメリカのサイトとヨーロッパのサイトの1つとの間にネットワーク・リンクを作成します。

2. ヨーロッパの各サイトにフィジカル・スタンバイ・データベースを作成します。

3. 9.2項で説明しているように、フィジカル・スタンバイ・データベースをリアルタイム問合せモードでオープンします。

4. 欧米間のネットワーク・リンクのヨーロッパ側の終点にあるフィジカル・スタンバイ・データベースを、他のヨーロッパのスタンバイ・データベースにREDOをカスケードするように構成します。

5. 欧米間のネットワーク・リンクのヨーロッパ側の終点にあるフィジカル・スタンバイ・データベースを、プライマリ・データベースのカスケードされた宛先として構成します。

6.4 REDO転送サービスの監視

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

- REDO転送ステータスの監視

- 同期REDO転送のレスポンス時間の監視

- REDOギャップの検出および解決

- REDO転送サービスの待機イベント

6.4.1 REDO転送ステータスの監視

この項では、REDOソース・データベースでREDO転送ステータスを監視するのに使用する手順について説明します。

手順1   最新のアーカイブREDOログ・ファイルを判定する

REDOソース・データベースで次の問合せを実行し、各スレッドの最新のアーカイブ順序番号を判定します。

SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG -
> WHERE RESETLOGS_CHANGE# = (SELECT MAX(RESETLOGS_CHANGE#) FROM V$ARCHIVED_LOG) -
> GROUP BY THREAD#;

手順2   各REDO転送先で最新のアーカイブREDOログ・ファイルを判定する

REDOソース・データベースで次の問合せを実行し、各REDO転送先の最新のアーカイブREDOログ・ファイルを判定します。

SQL> SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ# -
> FROM V$ARCHIVE_DEST_STATUS -
> WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE';

DESTINATION         STATUS  ARCHIVED_THREAD#  ARCHIVED_SEQ#
------------------  ------  ----------------  -------------
/private1/prmy/lad   VALID                 1            947
standby1             VALID                 1            947

最新のアーカイブREDOログ・ファイルは、各宛先で同じである必要があります。同じでない場合、その宛先へのアーカイブ操作の間に検出されたエラーはVALID以外のステータスで表示されます。

手順3   アーカイブREDOログ・ファイルがREDO転送先で受信されたかどうかを確認する

REDOソース・データベースで問合せを実行すると、アーカイブREDOログ・ファイルが特定のREDO転送先で受信されたかどうかを確認できます。各宛先には対応付けられたID番号があります。データベースのV$ARCHIVE_DESTビューのDEST_ID列に問合せを発行して、各宛先のID番号を特定できます。

宛先1がローカル・アーカイブREDOログを指し、宛先2がREDO転送先を指しているとします。REDOソース・データベースで次の問合せを実行し、ログ・ファイルがREDO転送先で欠落しているかどうかを確認します。

SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM -
> (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) -
> LOCAL WHERE -
> LOCAL.SEQUENCE# NOT IN -
> (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND -
> THREAD# = LOCAL.THREAD#);

THREAD#    SEQUENCE#
---------  ---------
1        12
1        13
1        14

手順4   REDO転送先に転送されたREDOの進捗状況をトレースする

REDOソース・データベースおよび各REDO転送先でLOG_ARCHIVE_TRACEデータベース初期化パラメータを設定し、REDO転送の進捗状況をトレースします。詳細と例は、付録Fを参照してください。

6.4.2 同期REDO転送のレスポンス時間の監視

V$REDO_DEST_RESP_HISTOGRAMビューには、REDO転送先ごとのレスポンス時間データが格納されます。このレスポンス時間データは、同期REDO転送モードにより送信されたREDO転送メッセージに関して保持されます。

宛先ごとのデータは一連の行で構成されており、各レスポンス時間に1行ずつ割り当てられています。レコードの保存を簡素化するために、300秒未満の場合、レスポンス時間は最も近い整数の秒数に切り上げられます。300秒超のレスポンス時間は、600、1200、2400、4800または9600秒にそれぞれ切り上げられます。

各行は、4つ列FREQUENCY、DURATION、DEST_IDおよびTIMEで構成されます。

FREQUENCY列には、特定のレスポンス時間が監視された回数が格納されます。DURATION列は、レスポンス時間に相当します。DEST_ID列は、宛先を特定します。TIME列には、その行が最後に更新されたときに取得されたタイムスタンプが格納されます。

このビューのレスポンス時間データは、REDOソース・データベースでのトランザクション・スループットに影響を与える可能性がある同期REDO転送モードのパフォーマンスの問題を特定するのに役立ちます。NET_TIMEOUT属性のチューニングにも有効です。

次の3つの例では、LOG_ARCHIVE_DEST_2パラメータに対応する宛先2への問合せのサンプルを示します。別の宛先についてレスポンス時間データを表示するには、問合せのDEST_IDを変更するだけです。

REDOソース・データベースで次の問合せを実行すると、宛先2についてレスポンス時間のヒストグラムを表示できます。

SQL> SELECT FREQUENCY, DURATION FROM -
> V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2 AND FREQUENCY>1;

REDOソース・データベースで次の問合せを実行すると、宛先2について最も遅いレスポンス時間を表示できます。

SQL> SELECT max(DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM -
> WHERE DEST_ID=2 AND FREQUENCY>1;

REDOソース・データベースで次の問合せを実行すると、宛先2について最も速いレスポンス時間を表示できます。

SQL> SELECT min( DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM -
> WHERE DEST_ID=2 AND FREQUENCY>1;

注意:
宛先について最も頻繁に監視されるレスポンス時間は、その宛先に指定されたNET_TIMEOUT値の最高値を超えることはできません。これは、REDO転送先がNET_TIMEOUTの秒数内にREDO転送メッセージに応答しない場合、同期REDO転送モードのセッションが終了するためです。

6.4.3 REDOギャップの検出および解決

REDOギャップは、REDO転送が割り込まれるたびに発生します。REDO転送が再開されると、REDO転送サービスはREDOギャップを自動的に検出し、欠落したREDOを宛先に送信して解決します。

REDOギャップの解決に必要な時間は、ギャップのサイズに正比例し、REDOソース・データベースとREDO転送先との間のネットワーク・リンクの実効スループットに反比例します。REDO転送サービスには、パフォーマンスが低いネットワーク・リンクを使用している場合にREDOギャップの解決時間を短縮するオプションが2つあります。

- REDO転送の圧縮
LOG_ARCHIVE_DEST_nパラメータのCOMPRESSION属性を使用して、宛先に送信する前にREDOデータを圧縮するように指定します。

- パラレルREDO転送ネットワーク・セッション
LOG_ARCHIVE_DEST_nパラメータのMAX_CONNECTIONS属性を使用すると、複数のネットワーク・セッションを使用して、REDOギャップを解決するために必要なREDOを送信するように指定できます。

COMPRESSION属性とMAX_CONNECTIONS属性の詳細は、第15章「LOG_ARCHIVE_DEST_nパラメータの属性」を参照してください。

6.4.3.1 手動によるギャップの解決

場合によっては、ギャップの解決を自動的に実行できず、手動による実行が必要になります。たとえば、プライマリ・データベースが使用できない場合には、ロジカル・スタンバイ・データベースでREDOギャップの解決を手動で実行する必要があります。

フィジカル・スタンバイ・データベースで次の問合せを実行し、REDOギャップがフィジカル・スタンバイ・データベースに存在するかどうかを判断します。

SQL> SELECT * FROM V$ARCHIVE_GAP;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
-----------  -------------  --------------
1              7              10

この例の出力は、フィジカル・スタンバイ・データベースでスレッド1の順序番号7から10のログ・ファイルが現在欠落していることを示しています。

プライマリ・データベースで次の問合せを実行し、プライマリ・データベースでのアーカイブREDOログ・ファイルの位置を特定します(プライマリ・データベースのローカル・アーカイブ先はLOG_ARCHIVE_DEST_1とします)。

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND -
> DEST_ID=1 AND SEQUENCE# BETWEEN 7 AND 10;

NAME
--------------------------------------------------------------------------------
/primary/thread1_dest/arcr_1_7.arc
/primary/thread1_dest/arcr_1_8.arc
/primary/thread1_dest/arcr_1_9.arc

注意:
この問合せは、特定のスレッドについて連続する順序番号を戻します。その場合、実際のギャップはありませんが、関連するスレッドは、これらの2つのアーカイブ・ログの生成期間内に無効および有効に設定されました。また、この問合せは、特定のスレッドの最後に存在するギャップを識別しません。たとえば、プライマリ・データベースでスレッド1に対して順序番号100までアーカイブ・ログが生成され、ロジカル・スタンバイ・データベースがそのスレッドについて受信した最後のアーカイブ・ログが順序番号77である場合、この問合せは、順序番号78から100のアーカイブ・ログについてギャップがあるにもかかわらず、1行も戻しません。

これらのログ・ファイルをフィジカル・スタンバイ・データベースにコピーし、コピーしたログをALTER DATABASE REGISTER LOGFILEを使用して登録します。次に例を示します。

SQL> ALTER DATABASE REGISTER LOGFILE -
> '/physical_standby1/thread1_dest/arcr_1_7.arc';

SQL> ALTER DATABASE REGISTER LOGFILE -
> '/physical_standby1/thread1_dest/arcr_1_8.arc';

SQL> ALTER DATABASE REGISTER LOGFILE -
> '/physical_standby1/thread1_dest/arcr_1_9.arc';

注意:
フィジカル・スタンバイ・データベースのV$ARCHIVE_GAPビューが戻すのは、REDO Applyの続行を現在ブロックしているギャップのみです。そのギャップを解決した後、フィジカル・スタンバイ・データベースでV$ARCHIVE_GAPビューを再度問い合せ、別のギャップ順序が存在するかどうかを判断します。この処理をギャップがなくなるまで繰り返します。

REDOギャップがロジカル・スタンバイ・データベースに存在するかどうかを判断するには、ロジカル・スタンバイ・データベースでDBA_LOGSTDBY_LOGビューを問い合せます。たとえば、次の問合せでは、ロジカル・スタンバイ・データベースのTHREAD 1に、2つのファイルが表示されているため、アーカイブREDOログ・ファイルの順序番号にギャップがあることを示しています。(ギャップがない場合、問合せで表示されるのは、スレッドごとに1つのファイルのみです。)この出力は、登録されたファイルの最大の順序番号は10ですが、順序番号6で示されるファイルにギャップがあることを示しています。

SQL> COLUMN FILE_NAME FORMAT a55
SQL> SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L -
> WHERE NEXT_CHANGE# NOT IN -
> (SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#) -
> ORDER BY THREAD#, SEQUENCE#;

THREAD#  SEQUENCE# FILE_NAME
---------- ---------- -----------------------------------------------
1          6 /disk1/oracle/dbs/log-1292880008_6.arc
1         10 /disk1/oracle/dbs/log-1292880008_10.arc

順序番号7、8および9の欠落しているログ・ファイルをロジカル・スタンバイ・システムにコピーし、コピーしたログをALTER DATABASE REGISTER LOGICAL LOGFILE文を使用して登録します。次に例を示します。

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE -
> '/disk1/oracle/dbs/log-1292880008_7.arc';

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE -
> '/disk1/oracle/dbs/log-1292880008_8.arc';

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE -
> '/disk1/oracle/dbs/log-1292880008_9.arc';

注意:
ここで指定した、ロジカル・スタンバイ・データベースのDBA_LOGSTDBY_LOGビューに基づいた問合せが戻すのは、SQL Applyの続行を現在ブロックしているギャップのみです。そのギャップを解決した後、ロジカル・スタンバイ・データベースでDBA_LOGSTDBY_LOGビューを再度問い合せ、別のギャップ順序が存在するかどうかを判断します。この処理をギャップがなくなるまで繰り返します。

6.4.4 REDO転送サービスの待機イベント

表6-2に、REDOソース・データベースでのREDO転送の待機時間を追跡管理するのに使用されるOracle待機イベントをいくつか示します。これらの待機イベントは、V$SYSTEM_EVENT動的パフォーマンス・ビューに表示されます。

REDO転送で使用されるOracle待機イベントの詳細リストは、次のURLからOracle Maximum Availability Architecture(MAA)のホームページにアクセスし、『Oracle Data Guard Redo Transport and Network Best Practices』ホワイト・ペーパーを参照してください。

http://www.oracle.com/goto/maa

表6-2 REDO転送の待機イベント

待機イベント

説明

LNS wait on ATTACH

すべてのASYNCおよびSYNCのREDO転送先に対してREDO転送セッションが確立するまでの待機に費やされた合計時間

LNS wait on SENDREQ

すべてのASYNCおよびSYNCのREDO転送先にREDOデータが書き込まれるまでの待機に費やされた合計時間

LNS wait on DETACH

すべてのASYNCおよびSYNCのREDO転送先に対してREDO転送の接続が終了されるまでの待機に費やされた合計時間

6.5 REDO転送のチューニング

最高のパフォーマンスを得るためにREDO転送を最適化する方法は、『Oracle Data Guard Redo Transport and Network Configuration Best Practices』ホワイト・ペーパーを参照してください。このホワイト・ペーパーは、次のURLからOracle Maximum Availability Architecture(MAA)のホームページにアクセスして入手することができます。

http://www.oracle.com/goto/maa

7 適用サービス

この章では、REDOデータをスタンバイ・データベースに適用する方法について説明します。次のトピックが含まれています。

- 適用サービスの概要

- 適用サービスの構成オプション

- REDOデータのフィジカル・スタンバイ・データベースへの適用

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

7.1 適用サービスの概要

適用サービスは、スタンバイ・データベースにREDOを自動的に適用して、プライマリ・データベースとの同期を維持します。また、データに対するトランザクションの一貫性のあるアクセスを可能にします。

デフォルト設定では、適用サービスはスタンバイREDOログ・ファイルのアーカイブ保存が終了するまで待って、制約のあるREDOを適用します。ただし、リアルタイムでの適用を有効化しておくと、書込みと同時に、現行のスタンバイREDOログ・ファイルにREDOを適用することができます。リアルタイムの適用については、7.2.1項で詳しく説明しています。

適用サービスは、次の方法でフィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースをメンテナンスします。

- REDO Apply(フィジカル・スタンバイ・データベースのみ)
メディア・リカバリを使用して、プライマリ・データベースとフィジカル・スタンバイ・データベースの同期を維持します。

- SQL Apply(ロジカル・スタンバイ・データベースのみ)
プライマリ・データベースから受信したREDOに基づいてSQL文を再構成し、そのSQL文をロジカル・スタンバイ・データベースに対して実行します。

この章の各項では、REDO Apply、SQL Apply、リアルタイム適用および適用の遅延について詳細に説明します。

7.2 適用サービスの構成オプション

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

- リアルタイム適用によるREDOデータの即時適用

- アーカイブREDOログ・ファイルの適用に対する遅延時間の指定

7.2.1 リアルタイム適用によるREDOデータの即時適用

リアルタイムでの適用機能を有効化すると、現行のスタンバイREDOログ・ファイルのアーカイブ保存を待たずに、適用サービスによって受信したREDOデータを適用することができます。この方法ではフェイルオーバーまたはスイッチオーバーが開始するまでに、スタンバイREDOログ・ファイルがスタンバイ・データベースに適用されているので、これによりスイッチオーバーとフェイルオーバーの速度が向上します。

次のように、ALTER DATABASE文を使用して、リアルタイム適用機能を使用可能にします。

- フィジカル・スタンバイ・データベースの場合は、ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE文を発行します。

- ロジカル・スタンバイ・データベースの場合は、ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE文を発行します。

リアルタイムの適用には、スタンバイREDOログを使用して構成された、ARCHIVELOGモードのスタンバイ・データベースが必要です。

図7-1に、ローカル宛先とスタンバイ宛先があるData Guard構成を示します。リモート・ファイル・サーバー(RFS)プロセスは、スタンバイ・データベース上のスタンバイREDOログ・ファイルにREDOデータを書き込むため、適用サービスでは、いっぱいになったときにスタンバイREDOログ・ファイルからREDOをリカバリできます。

図7-1 リアルタイム適用を使用したスタンバイ宛先へのREDOデータの適用

7.2.2 アーカイブREDOログ・ファイルの適用に対する遅延時間の指定

プライマリ・サイトからREDOデータを受信した後、そのREDOデータをスタンバイ・データベースに適用するまでの間にタイム・ラグを作成することが必要な場合があります。時間間隔(分単位)を指定すると、破損したデータや誤ったデータがスタンバイ・サイトに適用されるのを防止できます。DELAY間隔を設定すると、スタンバイ・データベースへのREDOデータの転送が遅延することはありません。かわりに、指定したタイム・ラグは、REDOデータがスタンバイ宛先で完全にアーカイブされたときに開始します。

注意:
リアルタイム適用が使用可能になっている宛先に遅延を定義すると、その遅延は無視されます。

遅延時間の指定

LOG_ARCHIVE_DEST_n初期化パラメータのDELAY=minutes属性を使用してプライマリ・データベースとスタンバイ・データベースで遅延時間を設定し、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用を遅延させることができます。デフォルトでは、遅延時間は発生しません。値を指定せずにDELAY属性を指定すると、デフォルトの遅延間隔は30分になります。

遅延時間の取消し

次のように、指定した遅延間隔を取り消すことができます。

- フィジカル・スタンバイ・データベースで、RECOVER MANAGED STANDBY DATABASE句のNODELAYキーワードを使用します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

- ロジカル・スタンバイ・データベースで、次のSQLコマンドを指定します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

これらのコマンドにより、時間間隔が経過する前に、適用サービスで、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用が即時に開始されます。

7.2.2.1 遅延時間設定の代替策としてのフラッシュバック・データベースの使用

適用遅延を設定するかわりにフラッシュバック・データベースを使用して、スタンバイ・データベースへの破損データやエラー・データの適用からリカバリできます。フラッシュバック・データベースを使用すると、スタンバイ・データベースを任意の時点まで、すばやく容易にフラッシュバックできます。

データベースのフラッシュバックでのData Guardの使用方法を示すシナリオは第13章を参照してください。フラッシュバック・データベースの有効化と使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

7.3 REDOデータのフィジカル・スタンバイ・データベースへの適用

デフォルトでは、アーカイブREDOログ・ファイルからのREDOデータが適用されます。REDO Applyを実行している場合、フィジカル・スタンバイ・データベースはリアルタイム機能を使用して、スタンバイREDOログ・ファイルがRFSプロセスによって書き込まれているときに、スタンバイREDOログ・ファイルから直接REDOを適用できます。

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

- REDO Applyの開始

- REDO Applyの停止

- フィジカル・スタンバイ・データベースでのREDO Applyの監視

7.3.1 REDO Applyの開始

フィジカル・スタンバイ・データベースで適用サービスを開始するには、フィジカル・スタンバイ・データベースが起動されマウントされていることを確認してから、SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE文を使用してREDO Applyを開始します。

REDO Applyをフォアグラウンド・セッションまたはバックグラウンド・プロセスとして動作するように指定し、リアルタイム適用で使用可能にすることができます。

- REDO Applyをフォアグラウンドで開始するには、次のSQL文を発行します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

フォアグラウンド・セッションを開始すると、別のセッションでリカバリが取り消されるまで、制御がコマンド・プロンプトに戻りません。

- REDO Applyをバックグラウンドで開始するには、このSQL文にDISCONNECTキーワードを挿入します。次に例を示します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

この文によって、分離されたサーバー・プロセスが起動し、即時に制御がユーザーに戻されます。管理リカバリ・プロセスがバックグラウンドでリカバリを実行している間、RECOVER文を発行したフォアグラウンド・プロセスは、他のタスクの実行を継続できます。これによって、カレントSQLセッションが切断されることはありません。

- リアルタイム適用を開始するには、SQL文にUSING CURRENT LOGFILE句を含めます。次に例を示します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

7.3.2 REDO Applyの停止

REDO Applyを停止するには、次のSQL文を発行します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

7.3.3 フィジカル・スタンバイ・データベースでのREDO Applyの監視

フィジカル・スタンバイ・データベースで適用サービスのステータスを監視するには、9.5.1項を参照してください。スタンバイ・データベースは、Oracle Enterprise Managerを使用して監視することもできます。ビューの参照情報の詳細は、『Oracle Databaseリファレンス』も参照してください。

7.4 REDOデータのロジカル・スタンバイ・データベースへの適用

SQL Applyは、アーカイブREDOログまたはスタンバイREDOログのデータをSQL文に変換してから、そのSQL文をロジカル・スタンバイ・データベースで実行します。ロジカル・スタンバイ・データベースはオープン状態のままであるため、メンテナンスされる表は、レポート生成、要約、問合せなどの他のタスクで同時に使用できます。

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

- SQL Applyの開始

- ロジカル・スタンバイ・データベースでのSQL Applyの停止

- ロジカル・スタンバイ・データベースでのSQL Applyの監視

7.4.1 SQL Applyの開始

SQL Applyを開始するには、ロジカル・スタンバイ・データベースを起動して次の文を発行します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

ロジカル・スタンバイ・データベースでリアルタイム適用を開始して、ロジカル・スタンバイ・データベースのスタンバイREDOログ・ファイルからREDOデータを即時に適用するには、次の文に示すように、IMMEDIATEキーワードを含めます。

SQL>  ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

7.4.2 ロジカル・スタンバイ・データベースでのSQL Applyの停止

SQL Applyを停止するには、ロジカル・スタンバイ・データベースで次の文を発行します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

この文を発行すると、SQL Applyは適用対象プロセス内の完了トランザクションがすべてコミットされるまで待機します。つまり、このコマンドを実行しても、SQL Applyプロセスが即時に停止しない場合があります。

7.4.3 ロジカル・スタンバイ・データベースでのSQL Applyの監視

SQL Applyを監視するには、10.3項を参照してください。スタンバイ・データベースは、Oracle Enterprise Managerを使用して監視することもできます。付録A「Data Guardのトラブルシューティング」と『Oracle Data Guard Broker』を参照してください。

8 ロールの推移

Data Guard構成は、プライマリ・ロールで機能する1つのデータベース、およびスタンバイ・ロールで機能する1つ以上のデータベースで構成されています。データベースの現行のロールを確認するには、V$DATABASEビューのDATABASE_ROLE列を問い合せます。

Data Guard構成内のスタンバイ・データベースの数、位置、タイプおよびプライマリ・データベースからのREDOデータを各スタンバイ・データベースに伝播する方法に応じて、プライマリ・データベースの停止に対して設定できるロール管理オプションが決定します。

この章では、Data Guard構成でロール・トランジションを管理する方法について説明します。この付録には、次の項があります。

- ロールの推移の概要

- フィジカル・スタンバイ・データベースが関与するロールの推移

- ロジカル・スタンバイ・データベースが関与するロールの推移

- ロールの推移後のフラッシュバック・データベースの使用

注意:
この章では、SQL文を使用して、手動でロールの推移を実行する方法について説明します。ブローカにより管理されるData Guard構成でロールの推移を実行する場合は、この章で説明する手順は使用しないでください。『Oracle Data Guard Broker』で提供されているトランジション・プロシージャを代わりに使用する必要があります。

関連項目:
Oracle Data Guard Brokerの使用による以下の詳細は、『Oracle Data Guard Broker』を参照してください。

- Oracle Enterprise Managerでキー・クリックを1回する、あるいはDGMGRLコマンドライン・インタフェースで単一のコマンドを使用すると起動できるようにする、スイッチオーバーおよびフェイルオーバーの単純化

- プライマリ・データベースが使用できなくなった場合に、ファスト・スタート・フェイルオーバーを有効化し、フェイルオーバーを自動的に行います。ファスト・スタート・フェイルオーバーが有効化されている場合、Data Guardブローカによってフェイルオーバーの必要性が判断され、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーが自動的に開始されます。DBAによる操作は不要です。

8.1 ロールの推移の概要

データベースは、プライマリまたはスタンバイという相互に排他的なロールのいずれかで動作します。Data Guardを使用すると、この章で説明しているSQL文を発行するか、Data Guardブローカのいずれかのインタフェースを使用して、これらのロールを動的に変更することができます。Oracle Data Guardは、次のロール・トランジションをサポートしています。

- スイッチオーバー
プライマリ・データベースが、スタンバイ・データベースの1つを使用してロールを切り替えられるようにします。スイッチオーバー時には、データは消失しません。スイッチオーバーの完了後、各データベースは、新しいロールとともにData Guard構成に継続して含まれます。

- フェイルオーバー
プライマリ・データベースの障害時に、スタンバイ・データベースをプライマリ・ロールに変更します。障害の前にプライマリ・データベースが最大保護モードまたは最大可用性モードで動作していなかった場合、データ消失が発生することがあります。フラッシュバック・データベースがプライマリ・データベースで使用可能になっている場合は、障害の原因が修正された後、元どおり新しいプライマリ・データベースのスタンバイに戻すことができます。

8.1.1項「ロールの推移の準備」では、停止時間およびデータ消失のリスクを最小限にするために、どのロールの推移を選択するかについて説明します。8.1.3項「スイッチオーバー」および8.1.4項「フェイルオーバー」では、それぞれスイッチオーバーとフェイルオーバーの詳細を説明します。

関連項目:
ブローカの管理対象のフェイルオーバーが発生した場合にデータベース・クライアントが使用可能なイベント通知、およびデータベース接続フェイルオーバー・サポートの詳細は、『Oracle Data Guard Broker』を参照してください。

8.1.1 ロールの推移の準備

ロールの推移を開始する前に、次の準備を実行します。

- 各データベースが、担う予定のロールについて正しく構成されていることを確認します。プライマリ・データベースとスタンバイ・データベースでデータベース初期化パラメータ、ARCHIVELOGモード、スタンバイREDOログ、オンラインREDOログを構成する方法の詳細は、第3章「フィジカル・スタンバイ・データベースの作成」および第4章「ロジカル・スタンバイ・データベースの作成」を参照してください。

注意:
スイッチオーバーまたはフェイルオーバーの発生時に、すべてのスタンバイ・サイトが新しいプライマリ・データベースから引き続きREDOデータを受信するように、各スタンバイ・データベース上でLOG_ARCHIVE_DEST_nおよびLOG_ARCHIVE_DEST_STATE_nパラメータを定義する必要があります。

- プライマリ・データベースでV$ARCHIVE_DEST_STATUSビューを問い合せて、スタンバイ・データベースにREDO転送エラー、またはREDOギャップがないことを確認します。
たとえば、LOG_ARCHIVE_DEST_2に関連付けられているスタンバイ・データベースのステータスをチェックするには、次の問合せを使用します。

SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;

STATUS GAP_STATUS
--------- ------------------------
VALID NO GAP

スタンバイ・データベースに対応する行のSTATUS列の値がVALID、GAP_STATUS列の値がNOGAPになるまで、次に進まないでください。

- スタンバイ・データベースに存在する一時ファイルが、プライマリ・データベースの一時ファイルと一致することを確認します。

- 新たにプライマリ・データベースになるスタンバイ・データベースで現在有効になっているREDOの適用遅延を解除します。

- Oracle RACプライマリ・データベースからフィジカル・スタンバイ・データベースにスイッチオーバーを実行するには、1つのプライマリ・データベース・インスタンス以外はすべて停止します。このとき停止したプライマリ・データベース・インスタンスは、スイッチオーバーの完了後に起動できます。

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

8.1.2 ロールの推移のターゲット・スタンバイ・データベースの選択

複数のスタンバイ・データベースがあるData Guard構成の場合、ロールの推移のターゲット・スタンバイ・データベースを選択する際には、多数の要因を考慮する必要があります。次のような要因があります。

- スタンバイ・データベースのローカリティ。

- スタンバイ・データベースの機能(CPU数、使用可能なI/O帯域幅などのハードウェア仕様)。

- ロールの推移の実行所要時間。これは、スタンバイ・データベースがREDOデータの適用に関してどの程度遅れているか、およびアプリケーションの可用性とデータ消失をどの程度柔軟にトレードオフできるかに影響を受けます。

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

ロールの推移のターゲットとして選択されたスタンバイのタイプにより、構成内の他のスタンバイ・データベースがロールの推移後にどのように動作するか決定されます。ロールの推移前、新しいプライマリがフィジカル・スタンバイだった場合、構成内の他のスタンバイ・データベースは新しいプライマリのスタンバイになります。ロールの推移前、新しいプライマリがロジカル・スタンバイだった場合、構成内の他のすべてのロジカル・スタンバイは新しいプライマリのスタンバイになりますが、構成内のフィジカル・スタンバイは、古いプライマリのスタンバイのままであるため、新しいプライマリを保護しません。後者の場合、次回のスイッチオーバーまたはフェイルオーバーで元のプライマリ・データベースに戻ると、すべてのスタンバイは現行のプライマリのスタンバイとしての元のロールに戻ります。これらの理由により、フィジカル・スタンバイとロジカル・スタンバイの両方が含まれる構成内におけるロールの推移の最適なターゲットは、通常、フィジカル・スタンバイです。

注意:
スナップショット・スタンバイは、ロールの推移のターゲットにはできません。スナップショット・スタンバイ・データベースをロールの推移のターゲットとして使用する場合、最初にこのデータベースをフィジカル・スタンバイ・データベースに変換し、プライマリ・データベースから受信したすべてのREDOを適用できるようにします。9.7.3項「フィジカル・スタンバイ・データベースへのスナップショット・スタンバイ・データベースの変換」を参照してください。

Data GuardにはV$DATAGUARD_STATSビューが用意されています。このビューを使用して、スタンバイ・データベースのデータの最新性から見た各スタンバイ・データベースと、使用可能なREDOデータがすべてスタンバイ・データベースに適用された場合の、ロール・トランジションの実行所要時間を評価することができます。次に例を示します。

SQL> COLUMN NAME FORMAT A24
SQL> COLUMN VALUE FORMAT A16
SQL> COLUMN DATUM_TIME FORMAT A24
SQL> SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS;

NAME                     VALUE            DATUM_TIME
------------------------ ---------------- ------------------------
transport lag            +00 00:00:00     06/18/2009 12:22:06
apply lag                +00 00:00:00     06/18/2009 12:22:06
apply finish time        +00 00:00:00.000
estimated startup time   9

この問合せの出力は、スタンバイ・データベースが、プライマリ・データベースにより生成されたすべてのREDOを受信し、適用したことを示しています。これらの統計は、2009年6月18日12:22.06にプライマリ・データベースから受信したデータを使用して計算されたものです。

apply lagおよびtransport lagメトリックは、プライマリ・データベースから受信されるデータに基づいて計算されます。これらのメトリックは、プライマリ・データベースとスタンバイ・データベースの間の通信が中断されると失効します。apply lagおよびtransport lagメトリックのDATUM_TIME列の値が変化していないことは、プライマリ・データベースとスタンバイ・データベース間の通信障害と考えられる原因で、これらのメトリックが更新されずに失効したことを示しています。

8.1.3 スイッチオーバー

スイッチオーバーは、通常、オペレーティング・システムやハードウェアのアップグレード、またはOracleデータベース・ソフトウェアとパッチ・セットのローリング・アップグレードなど、計画的な停止によるプライマリ・データベースの停止時間を短縮するために使用します(第12章「SQL Applyを使用したOracle Databaseのアップグレード」を参照)。

スイッチオーバーは、2つのフェーズで実行されます。最初のフェーズで、既存のプライマリ・データベースがスタンバイ・ロールに推移します。2番目のフェーズで、スタンバイ・データベースがプライマリ・ロールに推移します。

図8-1は、データベースのロールを切り替える前の2つのサイトにあるData Guard構成を示します。この構成では、プライマリ・データベースはサンフランシスコにあり、スタンバイ・データベースはボストンにあります。

図8-1 スイッチオーバー前のData Guard構成

図8-2に、元のプライマリ・データベースがスタンバイ・データベースにスイッチオーバーされた後、元のスタンバイ・データベースがまだ新しいプライマリ・データベースになっていないData Guard環境を示します。このとき、Data Guard構成には一時的に2つのスタンバイ・データベースが存在することになります。

図8-2 新しいプライマリ・データベースへのスイッチオーバー前のスタンバイ・データベース

図8-3は、スイッチオーバー実行後のData Guard環境を示します。元のスタンバイ・データベースは新しいプライマリ・データベースになります。現在、プライマリ・データベースはボストンにあり、スタンバイ・データベースはサンフランシスコにあります。

図8-3 スイッチオーバー後のData Guard環境

スイッチオーバーの準備

8.1.1項に示した前提条件が満たされていることを確認します。また、スイッチオーバーの場合は、次の前提条件が満たされている必要があります。

- フィジカル・スタンバイ・データベースが関与するスイッチオーバーの場合は、プライマリ・データベースがオープンし、REDO Applyがスタンバイ・データベースでアクティブであることを確認します。REDO Applyの詳細は、7.3項「REDOデータのフィジカル・スタンバイ・データベースへの適用」を参照してください。

- ロジカル・スタンバイ・データベースが関与するスイッチオーバーの場合は、プライマリおよびスタンバイ・データベース・インスタンスの両方がオープンし、SQL Applyがアクティブであることを確認します。REDO Applyの詳細は、7.4項「REDOデータのロジカル・スタンバイ・データベースへの適用」を参照してください。

8.1.4 フェイルオーバー

通常、フェイルオーバーは、プライマリ・データベースが使用不可能になり、適正な時間内にプライマリ・データベースをリストアしてサービスを再開できない場合にのみ使用します。フェイルオーバー時に実行するアクションは、フェイルオーバーに関与するスタンバイ・データベースがロジカルかフィジカルか、フェイルオーバー時のData Guard構成の状態、およびフェイルオーバーを開始するために使用する特定のSQL文によって異なります。

図8-4に、サンフランシスコにあるプライマリ・データベースからボストンにあるフィジカル・スタンバイ・データベースへのフェイルオーバーの結果を示します。

図8-4 スタンバイ・データベースへのフェイルオーバー

フェイルオーバーの準備

注意:
フェイルオーバーのために選択した物理スタンバイ・データベースで管理されているスタンバイ・リカバリが、ORA-752またはORA-600 [3020]のエラーで停止した場合は、このまま第13.6項「プライマリ・データベースでの書込みの欠落エラーからのリカバリ」に進んでください。
データ破損からのリカバリの詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

可能な場合は、フェイルオーバーを実行する前に、使用可能な未適用のプライマリ・データベースREDOデータを可能なかぎりスタンバイ・データベースに転送する必要があります。

8.1.1項「ロールの推移の準備」に示した前提条件が満たされていることを確認します。また、フェイルオーバーの場合は、次の前提条件が満たされている必要があります。

- 最大保護モードで実行中のスタンバイ・データベースがフェイルオーバーに関与する場合は、スタンバイ・データベースで次の文を発行して、データベースを最大パフォーマンス・モードにします。

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

適切なスタンバイ・データベースが使用できる場合は、フェイルオーバーが完了した後に、新しいプライマリ・データベースで希望の保護モードをリセットできます。

最大保護モードに設定されているスタンバイ・データベースはフェイルオーバーできないため、この作業が必要になります。さらに、最大保護モードのプライマリ・データベースがスタンバイ・データベースと通信中の場合は、スタンバイ・データベースを最大保護モードから最大パフォーマンス・モードに変更するためにALTER DATABASE文を発行しても失敗します。フェイルオーバーを実行すると元のプライマリ・データベースはData Guard構成から削除されるため、この機能によって、最大保護モードで実行されているプライマリ・データベースを計画外のフェイルオーバーの影響から保護します。

注意:
スタンバイ・データベースが正しく更新されているかどうかをテストするために、スタンバイ・データベースにフェイルオーバーしないでください。かわりに、次のようにします。

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

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

8.1.5 ロールの推移のトリガー

ロール・トランジションが発生するたびに、DB_ROLE_CHANGEシステム・イベント信号が発行されます。ロール・トランジション発生時にデータベースがオープン状態の場合は、このシステム・イベント信号が即座に発行されます。ロール・トランジション発生時にデータベースがクローズ状態の場合は、次回データベースがオープン状態になったときにシステム・イベント信号が発行されます。

DB_ROLE_CHANGEシステム・イベントを使用すると、ロールの推移が発生するたびに一連のアクションを実行するトリガーを起動できます。

8.2 フィジカル・スタンバイ・データベースが関与するロールの推移

後続のセクションでは、フィジカル・スタンバイ・データベースに対するスイッチオーバーまたはフェイルオーバーの実行方法を説明します。

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

- フィジカル・スタンバイ・データベースへのフェイルオーバーの実行

8.2.1 フィジカル・スタンバイ・データベースへのスイッチオーバーの実行

この項では、フィジカル・スタンバイ・データベースへのスイッチオーバーの実行方法を説明します。スイッチオーバーは、プライマリ・データベースで開始し、ターゲット・スタンバイ・データベースで完了します。

手順1   プライマリ・データベースがスタンバイ・ロールに切替え可能であることを確認する。

プライマリ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。次に例を示します。

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO STANDBY
1 row selected

値TO STANDBYまたはSESSIONS ACTIVEは、プライマリ・データベースをスタンバイ・ロールに切替え可能であることを示します。これらのいずれの値も戻されない場合、REDO転送が正しく構成されていないか、正しく機能していないため、スイッチオーバーは不可能です。REDO転送の構成および監視の詳細は、第6章を参照してください。

手順2   プライマリ・データベースでスイッチオーバーを開始する。

プライマリ・データベースで次のSQL文を発行してスタンバイ・ロールに切り替えます。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH -
> SESSION SHUTDOWN;

この文では、プライマリ・データベースをフィジカル・スタンバイ・データベースに変換します。現行の制御ファイルは、スイッチオーバーの前にカレントSQLセッション・トレース・ファイルにバックアップされます。これによって、必要に応じて現行の制御ファイルを再作成できるようになります。

注意:
前の手順で実行した問合せでTO STANDBYの値が戻された場合、WITH SESSION SHUTDOWN句をスイッチオーバー文から省略できます。

手順3   元のプライマリ・データベースを停止してマウントする。

SQL> SHUTDOWN ABORT;
SQL> STARTUP MOUNT;

スイッチオーバー・プロセスのこの時点では、元のプライマリ・データベースがフィジカル・スタンバイ・データベースです(図8-2を参照)。

注意:
Oracle Database 11gリリース2 (11.2.0.4)以降では、ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN文が発行されるとデータベース・インスタンスがデフォルトで停止するため、この手順でSHUTDOWN ABORT文を発行する必要はありません。

手順4   スイッチオーバー・ターゲットでプライマリ・ロールに切り替える準備が完了していることを確認する。

スタンバイ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。

次に例を示します。

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO_PRIMARY
1 row selected

値TO STANDBYまたはSESSIONS ACTIVEは、スタンバイ・データベースでプライマリ・ロールに切り替える準備が完了していることを示します。これらのいずれの値も戻されない場合、REDO applyがアクティブで、REDO転送が正しく構成されて機能していることを確認します。値TO PRIMARYまたはSESSIONS ACTIVEが戻されるまで、この列の問合せを続行します。

手順5   ターゲット・フィジカル・スタンバイ・データベース・ロールからプライマリ・ロールに切り替える。

次のSQL文をターゲット・フィジカル・スタンバイ・データベースで発行します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

注意:
前の手順で実行した問合せでTO PRIMARYの値が戻された場合、WITH SESSION SHUTDOWN句をスイッチオーバー文から省略できます。

手順6   新しいプライマリ・データベースをオープンする。

SQL> ALTER DATABASE OPEN;

手順7   新しいフィジカル・スタンバイ・データベースでREDO Applyを開始する。

次に例を示します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE -
> DISCONNECT FROM SESSION;

手順8   Data Guard構成のその他のフィジカル・スタンバイ・データベースのいずれかでREDO Applyが停止している場合は、これを再起動する。

次に例を示します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE -
> DISCONNECT FROM SESSION;

8.2.2 フィジカル・スタンバイ・データベースへのフェイルオーバーの実行

この項では、フィジカル・スタンバイ・データベースへのフェイルオーバーの実行方法を説明します。

手順1   プライマリ・データベースからターゲット・スタンバイ・データベースに未送信のREDOをフラッシュする。

プライマリ・データベースをマウントできる場合、プライマリ・データベースからスタンバイ・データベースに、未送信でアーカイブされた現行のREDOをフラッシュすることが可能です。この操作が正常に終了した場合、プライマリ・データベースがデータ消失ゼロのデータ保護モードで実行されていなくても、データの消失がないようにフェイルオーバーすることができます。

ターゲット・スタンバイ・データベースでREDO Applyがアクティブであることを確認します。

プライマリ・データベースをマウントします。オープンはしないでください。プライマリ・データベースをマウントできない場合は、手順2に進みます。

次のSQL文をプライマリ・データベースで発行します。

SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;

target_db_nameには、プライマリ・データベースからフラッシュされたREDOを受信するスタンバイ・データベースのDB_UNIQUE_NAMEを指定します。

この文は、未送信のREDOをすべて、プライマリ・データベースからスタンバイ・データベースにフラッシュし、このREDOがスタンバイ・データベースに適用されるまで待機します。

この文がエラーなしに終了した場合は、手順5に進みます。この文でエラーが出た場合、または完了するまで待てないため、この文を停止しなければならない場合は、手順2に進みます。

手順2   スタンバイ・データベースが、プライマリ・データベースREDOスレッドそれぞれについて、最新のアーカイブREDOログ・ファイルを持っていることを確認します。

ターゲット・スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せ、個々のREDOスレッドについて、最も大きなログ順序番号を取得します。

次に例を示します。

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) -
> OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;

THREAD       LAST
---------- ----------
1        100

可能であれば、各プライマリ・データベースREDOスレッドに対する最新のアーカイブREDOログ・ファイルがスタンバイ・データベースになければ、これをコピーし、登録します。これは、REDOスレッドごとに実行する必要があります。

次に例を示します。

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

手順3   アーカイブREDOログのギャップを明らかにし、解決する。

ターゲット・スタンバイ・データベースでV$ARCHIVE_GAPビューを問い合せ、ターゲット・スタンバイ・データベースにREDOギャップがあるかどうか判別します。

次に例を示します。

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

THREAD#    LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1            90             92

この例では、スレッド1の順序番号90、91および92のアーカイブREDOログ・ファイルがギャップです。

可能であれば、欠落しているすべてのアーカイブREDOログ・ファイルを、プライマリ・データベースからターゲット・スタンバイ・データベースにコピーして登録します。これは、REDOスレッドごとに実行する必要があります。

次に例を示します。

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

手順4   すべてのギャップが解決されるまで手順1を繰り返す。

手順3で実行する問合せでは、順序番号が最も大きいギャップに関する情報のみが表示されます。ギャップを解決した後、行が戻されなくなるまで問合せを繰り返します。

手順2から手順4を実行した後、アーカイブREDOログ・ファイルのすべてのギャップを解決できない場合(障害の発生したプライマリ・データベースのホスト・システムへのアクセス権がない場合など)、フェイルオーバー時にデータが消失する可能性があります。

手順5   REDO Applyを停止します。

次のSQL文をターゲット・スタンバイ・データベースで発行します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

手順6   受信したすべてのREDOデータの適用を終了する。

次のSQL文をターゲット・スタンバイ・データベースで発行します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

この文がエラーなしに終了した場合は、手順7に進みます。

エラーが発生した場合、受信されたREDOデータに適用されていないものがあります。エラーの原因を解決し、文を再発行してから次の手順に進みます。

手順3および手順4で解決されなかったREDOギャップがある場合、REDOギャップがあることを知らせるエラーが表示されることに注意してください。

エラー状態を解決できない場合でも、ターゲット・スタンバイ・データベースで次のSQL文を発行してフェイルオーバーを実行できます(一部のデータが消失する可能性があります)。

SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;

ACTIVATE文が完了した後、手順9に進みます。

手順7   ターゲット・スタンバイ・データベースがプライマリ・データベースになる準備が完了していることを確認する。

ターゲット・スタンバイ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。

次に例を示します。

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO PRIMARY
1 row selected

値TO STANDBYまたはSESSIONS ACTIVEは、スタンバイ・データベースでプライマリ・ロールに切り替える準備ができていることを示します。これらのいずれの値も戻されない場合、REDO Applyがアクティブで、TO PRIMARYまたはSESSIONS ACTIVEのいずれかが戻されるまでこのビューを問い合せ続けることを確認します。

手順8   フィジカル・スタンバイ・データベース・ロールからプライマリ・ロールに切り替える。

次のSQL文をターゲット・スタンバイ・データベースで発行します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

注意:
前の手順で実行されたSWITCHOVER_STATUS列の問合せでTO PRIMARYが戻された場合、WITH SESSION SHUTDOWN句をスイッチオーバー文から省略できます。

手順9   新しいプライマリ・データベースをオープンする。

SQL> ALTER DATABASE OPEN;

手順10   新しいプライマリ・データベースをバックアップする。

新しいプライマリ・データベースの全体バックアップを作成することをお薦めします。

手順11   Data Guard構成のその他のフィジカル・スタンバイ・データベースのいずれかでREDO Applyが停止している場合は、これを再起動する。

次に例を示します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE -
> DISCONNECT FROM SESSION;

手順12   必要に応じて、障害の発生したプライマリ・データベースをリストアする。

フェイルオーバーの完了後、元のプライマリ・データベースは13.2項または13.7項で説明する方法に従って、新しいプライマリ・データベースのフィジカル・スタンバイ・データベースに変換できます。あるいは、3.2項で説明した方法に従って、新しいプライマリ・データベースのバックアップからフィジカル・スタンバイ・データベースとして再作成できます。

元のプライマリ・データベースをスタンバイ・ロールで実行したら、スイッチオーバーを実行してプライマリ・ロールにリストアできます。

8.3 ロジカル・スタンバイ・データベースが関与するロールの推移

後続の項では、ロジカル・スタンバイ・データベースが関与するスイッチオーバーおよびフェイルオーバーの実行方法を説明します。

- ロジカル・スタンバイ・データベースへのスイッチオーバーの実行

- ロジカル・スタンバイ・データベースへのフェイルオーバーの実行

注意:
ロジカル・スタンバイでは、データベース・サービスはレプリケートしません。ロジカル・スタンバイに対するフェイルオーバーまたはスイッチオーバーのイベントでは、プライマリでのサービスに接続している中間層が接続できなくなる(サービスの作成がレプリケートされないため)か、正しくないエディションに接続するようになります(サービス属性の変更がレプリケートされないため)。
Oracle Clusterwareでは、管理するサービスをロジカル・スタンバイにレプリケートしません。それらのプライマリとスタンバイ間での同期を手動で維持する必要があります。Oracle Clusterwareの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

8.3.1 ロジカル・スタンバイ・データベースへのスイッチオーバーの実行

プライマリ・データベースとロジカル・スタンバイ・データベースとの間でスイッチオーバーを実行する場合、スイッチオーバーは、常にプライマリ・データベースで開始し、ロジカル・スタンバイ・データベースで完了してください。次の手順を記載されているとおりの順序で実行しなかった場合、スイッチオーバーは成功しません。

手順1   プライマリ・データベースでスイッチオーバーを実行できるかどうかを確認する。

スイッチオーバーを実行できるかどうかを確認するには、現行のプライマリ・データベースでV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せます。

次に例を示します。

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO STANDBY
1 row selected

SWITCHOVER_STATUS列の値TO STANDBYまたはSESSIONS ACTIVEは、プライマリ・データベースをロジカル・スタンバイ・ロールに切替え可能であることを示します。これらの値のいずれかが表示されない場合は、Data Guard構成が正常に機能していることを確認してください(たとえば、LOG_ARCHIVE_DEST_nパラメータのすべての値が正しく指定されていることを確認します)。V$DATABASEビューのSWITCHOVER_STATUS列に有効なその他の値の詳細は、『Oracle Databaseリファレンス』を参照してください。

手順2   現行のプライマリ・データベースのスイッチオーバーを準備する。

ロジカル・スタンバイ・データベース・ロール用に現行のプライマリ・データベースを準備するには、プライマリ・データベースで次のSQL文を発行します。

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;

この文は現行プライマリ・データベースに対して、間もなくロジカル・スタンバイ・ロールに切り替わり、新しいプライマリ・データベースからREDOデータを受信し始めることを通知します。LogMinerディクショナリの受信に備えてプライマリ・データベースでこの手順を実行し、手順3で説明したように、現行のロジカル・スタンバイ・データベースのREDOストリームに記録できるようにします。

この操作に成功すると、V$DATABASE.SWITCHOVER_STATUS列に値PREPARING SWITCHOVERが表示されます。

手順3   ターゲット・ロジカル・スタンバイ・データベースのスイッチオーバーを準備する。

スイッチオーバーのターゲットであるロジカル・スタンバイ・データベースでLogMinerディクショナリを作成するには、次の文を使用します。

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;

また、この文は、現行のプライマリ・データベース、およびData Guard構成内の他のスタンバイ・データベースにREDOデータの転送を開始するロジカル・スタンバイ・データベースで、REDO転送サービスを開始します。このロジカル・スタンバイ・データベースからREDOデータを受信するサイトは、REDOデータを受け入れますが、適用はしません。

ロジカル・スタンバイ・データベースのV$DATABASE.SWITCHOVER_STATUSには、LogMinerディクショナリがREDOストリームに記録されている間、最初はPREPARING DICTIONARYが表示されます。正常に完了すると、SWITCHOVER_STATUS列にPREPARING SWITCHOVERが表示されます。

手順4   現行のプライマリ・データベースで将来のプライマリ・データベースのREDOストリームに対する準備が完了していることを確認する。

プライマリ・データベースからロジカル・スタンバイ・ロールへのロール・トランジションを完了するには、プライマリ・データベースのV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せることで、プライマリ・データベースがLogMinerディクショナリを受信したことを確認する必要があります。LogMinerディクショナリを受信しなければ、現行のプライマリ・データベースが以降のプライマリ・データベースから受信するREDOレコードを解釈できないため、スイッチオーバーを続行することができません。SWITCHOVER_STATUS列にスイッチオーバーの進捗が示されています。

問合せがTO LOGICAL STANDBY値を戻した場合は、手順5に進むことができます。次に例を示します。

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO LOGICAL STANDBY
1 row selected

注意:
次の文を示された順序で発行すると、スイッチオーバー操作を取り消すことができます。

1. プライマリ・データベースでスイッチオーバーを取り消します。

SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;

2. ロジカル・スタンバイ・データベースでスイッチオーバーを取り消します。

SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;

手順5   プライマリ・データベースをロジカル・スタンバイ・データベース・ロールに切り替える。

プライマリ・データベースからロジカル・スタンバイ・データベース・ロールへのロールの推移を完了するには、次のSQL文を発行します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;

この文は、プライマリ・データベースで現在のトランザクションがすべて終了するまで待機し、新規ユーザーによる新規トランザクションの開始を防止して、スイッチオーバーがコミットされる時点を設定します。

この文を実行すると、ユーザーはロジカル・スタンバイ・データベースでメンテナンスされているデータの変更もできなくなります。スイッチオーバーを迅速に実行するには、スイッチオーバー文を発行する前に、プライマリ・データベースが静止状態で更新アクティビティが実行されていないことを確認してください(たとえば、すべてのユーザーをプライマリ・データベースから一時的にログオフします)。V$TRANSACTIONビューを問い合せると、この文の実行を遅延させる可能性のある現在進行中のトランザクションのステータス情報を取得できます。

この時点でプライマリ・データベースのロールが推移して、スタンバイ・データベース・ロールで実行されます。

プライマリ・データベースをロジカル・スタンバイ・データベース・ロールに推移した場合は、データベースを停止して再起動する必要はありません。

手順6   使用可能なすべてのREDOが、新規プライマリ・データベースになるターゲット・ロジカル・スタンバイ・データベースに適用されたことを確認する。

プライマリ・データベースからロジカル・スタンバイ・ロールへのロールの推移を完了し、構成内のスタンバイ・データベースがスイッチオーバー通知を受け取った後、ターゲット・スタンバイ・データベースでV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せ、ターゲット・スタンバイ・データベースがスイッチオーバー通知を処理したかどうかを確認する必要があります。使用可能なすべてのREDOレコードがロジカル・スタンバイ・データベースに適用されると、SQL Applyは予想されるロールの推移の準備を自動的に停止します。

スイッチオーバー中にSWITCHOVER_STATUS値が更新され、進捗を示します。ステータスがTO PRIMARYの場合は、手順7に進むことができます。

次に例を示します。

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO PRIMARY
1 row selected

V$DATABASEビューのSWITCHOVER_STATUS列に有効なその他の値の詳細は、『Oracle Databaseリファレンス』を参照してください。

手順7   ターゲット・ロジカル・スタンバイ・データベースをプライマリ・データベース・ロールに切り替える。

プライマリ・ロールに切り替えるロジカル・スタンバイ・データベースで、次のSQL文を使用し、ロジカル・スタンバイ・データベースをプライマリ・ロールに切り替えます。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

Data Guard構成内のロジカル・スタンバイ・データベースは、停止して再起動する必要はありません。8.1.2項で説明したように、構成内の他のすべてのロジカル・スタンバイは新しいプライマリのスタンバイになりますが、フィジカル・スタンバイ・データベースは、元のプライマリ・データベースのスタンバイのままです。

手順8   新規のロジカル・スタンバイ・データベースでSQL Applyを開始する。

新しいロジカル・スタンバイ・データベースでSQL Applyを開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

8.3.2 ロジカル・スタンバイ・データベースへのフェイルオーバーの実行

この項では、ロジカル・スタンバイ・データベースが関与するフェイルオーバーの実行方法を説明します。ロジカル・スタンバイ・データベースが関与するフェイルオーバーによるロールの推移では、障害の発生したプライマリ・データベースとすべてのロジカル・スタンバイ・データベースで対処措置を実行する必要があります。障害の発生したプライマリ・データベースでフラッシュバック・データベースが有効化されていない場合は、現行のプライマリ・データベースから作成したバックアップを使用してデータベースを再作成する必要があります。それ以外の場合は、13.2項で説明する手順に従って、障害の発生したプライマリ・データベースを新しいプライマリ・データベースのロジカル・スタンバイ・データベースに変換できます。

構成に対する保護モードおよびREDO転送サービスに対して選択した属性に従って、プライマリ・データベースの修正の一部またはすべてを自動的にリカバリすることも可能です。

手順1   プライマリ・データベースからターゲット・スタンバイ・データベースに未送信のREDOをフラッシュする。

プライマリ・データベースをマウントできる場合、プライマリ・データベースからスタンバイ・データベースに、未送信でアーカイブされた現行のREDOをフラッシュすることが可能です。この操作が正常に終了した場合、プライマリ・データベースがデータ消失ゼロのデータ保護モードで実行されていなくても、データの消失がないようにフェイルオーバーすることができます。

ターゲット・スタンバイ・データベースでREDO Applyがアクティブであることを確認します。

プライマリ・データベースをマウントします。オープンはしないでください。

次のSQL文をプライマリ・データベースで発行します。

SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;

target_db_nameには、プライマリ・データベースからフラッシュされたREDOを受信するスタンバイ・データベースのDB_UNIQUE_NAMEを指定します。

この文は、未送信のREDOをすべて、プライマリ・データベースからスタンバイ・データベースにフラッシュし、このREDOがスタンバイ・データベースに適用されるまで待機します。

手順2   欠落したアーカイブREDOログ・ファイルを、新しいプライマリ・データベースの候補となるターゲット・ロジカル・スタンバイ・データベースにコピーし、登録する。

構成に含まれるコンポーネントの状態によっては、プライマリ・データベースのアーカイブREDOログ・ファイルにアクセスできる場合があります。アクセスする場合の手順は、次のとおりです。

1. ロジカル・スタンバイ・データベースでアーカイブREDOログ・ファイルが欠落しているかどうかを判断します。

2. 欠落しているログ・ファイルを、プライマリ・データベースからロジカル・スタンバイ・データベースにコピーします。

3. コピーしたログ・ファイルを登録します。

次の文を発行して、アーカイブREDOログ・ファイルをロジカル・スタンバイ・データベースに登録できます。次に例を示します。

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE -
> '/disk1/oracle/dbs/log-%r_%s_%t.arc';
Database altered.

手順3   リモート宛先を使用可能にする。

ロールベースの宛先をまだ構成していない場合は、新しいプライマリ・データベースのリモート・ロジカル・スタンバイ宛先に対応する初期化パラメータを特定して、これらの宛先ごとにREDOデータのアーカイブを手動で使用可能にします。

たとえば、LOG_ARCHIVE_DEST_2パラメータで定義したリモート宛先のアーカイブを可能にするには、次の文を発行します。

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;

後で新しいプライマリ・データベースを再起動した場合にもこの変更を保持するには、適切なテキスト初期化パラメータ・ファイルまたはサーバー・パラメータ・ファイルを更新します。通常、データベースがプライマリ・ロールで動作する場合はリモート宛先へのアーカイブを可能にし、データベースがスタンバイ・ロールで動作する場合はリモート宛先へのアーカイブを不可能にする必要があります。

手順4   新しいプライマリ・データベースをアクティブにする。

ターゲット・ロジカル・スタンバイ・データベース(新規プライマリ・ロールに推移させるデータベース)で、次の文を発行します。

SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY;

この文はRFSプロセスを停止し、ロジカル・スタンバイ・データベースがプライマリ・データベースになる前にスタンバイREDOログ・ファイルに残っているREDOデータを適用し、SQL Applyを停止して、データベースをプライマリ・データベース・ロールでアクティブ化します。

FINISH APPLY句が指定されていない場合、現行のスタンバイREDOログ・ファイルの未適用のREDOは、スタンバイ・データベースがプライマリ・データベースになるまで適用されません。

手順5   フェイルオーバー後に他のスタンバイ・データベースをリカバリする。

13.1項で説明する方法に従って、既存のロジカル・スタンバイ・データベースが新しいプライマリ・データベースを引き続き保護できるようにします。

手順6   新しいプライマリ・データベースをバックアップする。

Data Guardデータベース・フェイルオーバー直後に、新しいプライマリ・データベースのバックアップを行います。データベースの完全なバックアップ・コピーがなければ、フェイルオーバー後の変更をリカバリすることができないので、バックアップをすぐに実行することは安全策として必要な作業です。

手順7   障害の発生したプライマリ・データベースをリストアする。

フェイルオーバーの完了後、元のプライマリ・データベースは13.2項で説明する方法に従って、新しいプライマリ・データベースのロジカル・スタンバイ・データベースに変換できます。あるいは、第4章で説明したように、新しいプライマリ・データベースのバックアップからロジカル・スタンバイ・データベースとして再作成できます。

元のプライマリ・データベースをスタンバイ・データベースに変換したら、スイッチオーバーを実行してプライマリ・ロールにリストアできます。

8.4 ロールの推移後のフラッシュバック・データベースの使用

ロール・トランジションの後に、オプションでFLASHBACK DATABASEコマンドを使用してデータベースをロール・トランジション前のある時点、またはシステム変更番号(SCN)に戻すことができます。プライマリ・データベースのフラッシュバックを行う場合、同じ(または以前の)SCNまたは時刻にすべてのスタンバイ・データベースをフラッシュバックする必要があります。この方法でプライマリまたはスタンバイ・データベースのフラッシュバックを行う場合は、過去のスイッチオーバーを気にする必要はありません。SCN/時刻が過去の任意の時点でのスイッチオーバーより前の場合、Oracleは自動的に過去のスイッチオーバーを越えてフラッシュバックを行うことができます。

注意:
ロールの推移が発生する前に、データベースでフラッシュバック・データベースを有効化しておく必要があります。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

8.4.1 スイッチオーバー後のフラッシュバック・データベースの使用

スイッチオーバー後にFLASHBACK DATABASEコマンドを使用して、データベースをスイッチオーバー発生前の時点またはシステム変更番号(SCN)に戻すことができます。

スイッチオーバーにフィジカル・スタンバイ・データベースが関与していた場合、フラッシュバック操作中はプライマリおよびスタンバイ・データベース・ロールが保持されます。つまり、データベースが実行中のロールは、フラッシュバックした時点またはターゲットSCNまでデータベースがフラッシュバックされても変化しません。スイッチオーバー後からフラッシュバックの前までフィジカル・スタンバイ・ロールで実行されていたデータベースは、フラッシュバック・データベース操作後もフィジカル・スタンバイ・データベースで実行されます。

スイッチオーバーにロジカル・スタンバイ・データベースが関与していた場合、フラッシュバックするとスタンバイ・データベースのロールはフラッシュバックした時点またはターゲットSCNでのロールに変更されます。

8.4.2 フェイルオーバー後のフラッシュバック・データベースの使用

フラッシュバック・データベースを使用して、障害の発生したプライマリ・データベースをフェイルオーバー発生前の時点に変換してから、スタンバイ・データベースに変換できます。詳細な手順は、13.2項「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」を参照してください。

9 フィジカルおよびスナップショット・スタンバイ・データベースの管理

この章では、フィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースの管理方法について説明します。次の項目で構成されています。

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

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

- フィジカル・スタンバイでの手動操作が必要なプライマリ・データベースの変更

- OPEN RESETLOGS文を使用したリカバリ

- プライマリ、フィジカル・スタンバイおよびスナップショット・スタンバイ・データベースの監視

- REDO Applyのチューニング

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

Data Guard Brokerによるフィジカルおよびスナップショット・スタンバイ・データベース管理の簡素化方法については、『Oracle Data Guard Broker』を参照してください。

9.1 フィジカル・スタンバイ・データベースの起動と停止

この項では、フィジカル・スタンバイ・データベースを起動および停止する方法について説明します。

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

フィジカル・スタンバイ・データベースを起動するには、SQL*Plus STARTUPコマンドを使用します。SQL*Plus STARTUPコマンドは、引数を指定せずに起動すると、フィジカル・スタンバイ・データベースを読取り専用モードで起動、マウントおよびオープンします。

フィジカル・スタンバイ・データベースは、マウントまたはオープンされると、プライマリ・データベースからREDOデータを受信できます。

REDO Applyの詳細は7.3項を、フィジカル・スタンバイ・データベースを読取り専用モードでオープンする方法の詳細は9.2項を参照してください。

注意:
プライマリ・データベースからのREDOデータをまだ受信していないフィジカル・スタンバイ・データベースでREDO Applyを開始すると、ORA-01112メッセージが戻されることがあります。このメッセージは、REDO Applyがメディア・リカバリ用の開始順序番号を判別できないことを示します。このエラーが発生した場合は、スタンバイ・データベースでアーカイブREDOログ・ファイルをプライマリ・データベースから手動で取得して登録するか、またはREDO転送が開始されるまで待機した後、REDO Applyを開始します。

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

REDO Applyを停止してフィジカル・スタンバイ・データベースを停止するには、SQL*Plus SHUTDOWNコマンドを使用します。停止処理が完了するまで、データベース停止を開始したセッションに制御が戻されません。

プライマリ・データベースが起動して稼働している場合は、フィジカル・スタンバイ・データベースを停止する前に、プライマリ・データベースでスタンバイ宛先を遅延し、ログ・スイッチを実行します。

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

フィジカル・スタンバイ・データベースは、読取り専用アクセス用にオープンし、問合せをプライマリ・データベースからオフロードするために使用できます。

注意:
読取り専用モードで開かれたフィジカル・スタンバイ・データベースは、読取り専用モードで開かれたその他のOracleデータベースと同じ制約を受けます。詳細は、『Oracle Database管理者ガイド』を参照してください。

Oracle Active Data Guardオプションのライセンスを購入している場合は、フィジカル・スタンバイ・データベースを開いている間はRedo Applyをアクティブにすることができます。それにより、問合せによって、プライマリ・データベースからのものと同じ結果が得られます。この機能は、リアルタイム問合せ機能と呼ばれます。詳細は9.2.1項を参照してください。

Oracle Active Data Guardオプションのライセンスを未購入の場合、REDO Applyがアクティブである間は、フィジカル・スタンバイ・データベースをオープンできません。そのため、フィジカル・スタンバイ・データベース・インスタンスのオープン時またはREDO Applyの開始時には、次のルールに従う必要があります。

- REDO Applyは、フィジカル・スタンバイ・データベース・インスタンスをオープンする前に停止する必要がある。

- 1つ以上のフィジカル・スタンバイ・インスタンスがオープンしている場合、REDO Applyを開始する前にこれらのインスタンスを停止する、またはMOUNT状態を再開する必要がある。

関連項目:

- Oracle Active Data Guardの詳細は、『Oracle Databaseライセンス情報』を参照してください。

9.2.1 リアルタイム問合せ

Oracle Active Data Guardオプションのリアルタイム問合せ機能を使用するためには、COMPATIBLEデータベース初期化パラメータを11.0以上に設定する必要があります。

フィジカル・スタンバイ・データベース・インスタンスは、そのデータベースのマウント済インスタンスでREDO Applyがアクティブである場合、オープンできません。次のSQL文を使用してREDO Applyを停止し、スタンバイ・インスタンスを読取り専用でオープンしてREDO Applyを再開します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE OPEN;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE -
> DISCONNECT;

注意:
REDO Applyがオープン・インスタンスでアクティブになっている場合は、REDO Applyを停止せずにその他のインスタンスをオープンすることができます。

REDO Applyは、そのデータベースのいずれかのインスタンスがオープンされている場合、マウント済フィジカル・スタンバイ・インスタンスでは開始できません。REDO Applyを開始する予定のインスタンスは、開始前にオープンしておく必要があります。

例: スタンバイのオープン・モードを調べるためのV$DATABASEの問合せ

この例は、フィジカル・スタンバイがリアルタイム問合せモードで開かれているときのV$DATABASE.OPEN_MODE列の値の変化を示します。

1. フィジカル・スタンバイ・インスタンスを起動してオープンし、次のSQL問合せを実行して、データベースが読取り専用モードでオープンしていることを確認します。

SQL> SELECT open_mode FROM V$DATABASE;

OPEN_MODE
--------------------
READ ONLY

2. 次のSQL文を発行してREDO Applyを開始します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE -
> DISCONNECT;

Database altered.

3. スタンバイがリアルタイム問合せモード(スタンバイが読取り専用モードでオープンし、REDO Applyがアクティブになっている)であるため、V$DATABASE.OPEN_MODE列は次のように変化します。

SQL> SELECT open_mode FROM V$DATABASE;

OPEN_MODE
--------------------
READ ONLY WITH APPLY

9.2.1.1 リアルタイム問合せ環境での適用ラグの監視

リアルタイム問合せを使用して、プライマリ・データベースからフィジカル・スタンバイ・データベースに問合せをオフロードしている場合、適用ラグを監視して許容範囲内かどうかを確認することが必要になる場合があります。

現行の適用ラグとは、最後に適用された変更がスタンバイで表示可能になってから、同じ変更がプライマリで最初に表示可能になるまでに経過した時間です。このメトリックは秒単位で計算されます。

適用ラグを取得するには、V$DATAGUARD_STATSビューを問い合せます。次に例を示します。

SQL> SELECT name, value, datum_time, time_computed FROM V$DATAGUARD_STATS -
> WHERE name like 'apply lag';

NAME         VALUE            DATUM_TIME              TIME_COMPUTED
---------    -------------    -------------------     -------------------
apply lag    +00 00:00:00     05/27/2009 08:54:16     05/27/2009 08:54:17

apply lagメトリックの計算には、プライマリ・データベースから定期的に受信されるデータが使用されます。DATUM_TIME列には、このデータがスタンバイ・データベースにより最後に受信されたときのタイムスタンプが格納されます。TIME_COMPUTED列には、apply lagメトリックが計算されたときに取得されたタイムスタンプが格納されます。これらの列の値の差は30秒未満である必要があります。差が30秒以上である場合、apply lagメトリックが正確ではない可能性があります。

スタンバイ・インスタンスが最後に起動されてからの適用ラグ値の履歴を示すヒストグラムを取得するには、V$STANDBY_EVENT_HISTOGRAMビューを問い合せます。次に例を示します。

SQL> SELECT * FROM V$STANDBY_EVENT_HISTOGRAM WHERE NAME = 'apply lag' -
> AND COUNT > 0;

NAME             TIME       UNIT         COUNT        LAST_TIME_UPDATED
---------     ---------   --------    -----------    ------------------------
apply lag         0        seconds        79681          06/18/2009 10:05:00
apply lag         1        seconds         1006          06/18/2009 10:03:56
apply lag         2        seconds           96          06/18/2009 09:51:06
apply lag         3        seconds            4          06/18/2009 04:12:32
apply lag         4        seconds            1          06/17/2009 11:43:51
apply lag         5        seconds            1          06/17/2009 11:43:52

6 rows selected

ある期間にわたってapply lagを評価するには、その期間の開始時のV$STANDBY_EVENT_HISTOGRAMのスナップショットを取得し、その期間の終了時に取得したスナップショットと比較します。

9.2.1.2 リアルタイム問合せ環境での適用ラグ許容差の構成

リアルタイム問合せモードのフィジカル・スタンバイ・データベースへの非管理ユーザーからの問合せで、新しいSTANDBY_MAX_DATA_DELAYセッション・パラメータを使用して特定のセッションの適用ラグの許容値を指定できます。この機能によって、スタンバイ・データベースが許容できないほど失効したかどうかを検出できるため、プライマリ・データベースからフィジカル・スタンバイ・データベースに問合せを安全に移動できます。

STANDBY_MAX_DATA_DELAYをデフォルト値のNONEに設定すると、フィジカル・スタンバイ・データベースに発行される問合せは、そのデータベースの適用ラグに関係なく実行されます。

STANDBY_MAX_DATA_DELAYを0以外の値に設定すると、フィジカル・スタンバイ・データベースに発行される問合せが実行されるのは、適用ラグがSTANDBY_MAX_DATA_DELAY以下の場合のみになります。それ以外の場合は、ORA-3172エラーが返され、適用ラグが大きすぎることがクライアントに警告されます。

STANDBY_MAX_DATA_DELAYを0に設定すると、フィジカル・スタンバイ・データベースに発行される問合せは、スタンバイ・データベースがプライマリ・データベースから遅れていないかぎり、その問合せがプライマリ・データベースに発行された場合とまったく同じ結果を返すことが保証されます。遅れている場合、ORA-3172エラーが返されます。

ALTER SESSION SQL文を使用してSTANDBY_MAX_DATA_DELAYを設定します。次に例を示します。

SQL> ALTER SESSION SET STANDBY_MAX_DATA_DELAY=2

9.2.1.3 リアルタイム問合せ環境でのREDO Applyの強制同期

フィジカル・スタンバイ・データベースで次のSQL文を発行すると、プライマリ・データベースから受け取ったすべてのREDOデータを確実にフィジカル・スタンバイ・データベースに適用できます。

SQL> ALTER SESSION SYNC WITH PRIMARY;

このコマンドが発行された時点でスタンバイ・データベースが受け取ったすべてのREDOデータが、フィジカル・スタンバイ・データベースに適用されるまで、この文によってその他の処理がブロックされます。スタンバイ・データベースのREDO転送ステータスがSYNCHRONIZEDでない場合、またはREDO Applyがアクティブでない場合は、ORA-3173エラーがすぐに返され、同期は行われません。

特定のケースでREDO Apply同期を確実に行うためには、SYS_CONTEXT('USERENV','DATABASE_ROLE')ファンクションを使用して、スタンバイ専用トリガー(プライマリで有効化されるが、スタンバイで実行される場合のみ特定の処理を実行するトリガー)を作成します。たとえば、特定のユーザー接続に対してログオン時にALTER SESSION SYNC WITH PRIMARY文を実行する次のトリガーを作成することができます。

CREATE TRIGGER adg_logon_sync_trigger
AFTER LOGON ON user.schema
begin
if (SYS_CONTEXT('USERENV', 'DATABASE_ROLE')  IN ('PHYSICAL STANDBY')) then
execute immediate 'alter session sync with primary';
end if;
end;

9.2.1.4 リアルタイム問合せの制限

これまでに説明した、適用ラグの制御およびREDO Apply同期のメカニズムでは、クライアントが接続していることと、リアルタイム問合せモードのフィジカル・スタンバイ・データベースに問合せを発行することが必要です。

STANDBY_MAX_DATA_DELAYが0に設定されている場合、またはALTER SESSION SYNC WITH PRIMARY SQL文が使用される場合には、この他に次の制限も適用されます。

- スタンバイ・データベースがSYNC転送でREDOデータを受け取ります。

- スタンバイ・データベースのREDO転送ステータスはSYNCHRONIZEDである必要があります。また、プライマリ・データベースは、最大保護モードまたは最大可用性モードのいずれかで実行されている必要があります。

- リアルタイム適用を有効化しておく必要があります。

- Active Data Guardは、キャッシュ・フュージョンの使用を通じてOracle RAC環境でパフォーマンスの高いリアルタイム問合せを実現しています。これにより、Data Guardの適用インスタンスおよび問合せは、キャッシュで動作することが可能となり、ディスクI/O制限によって低速化することがなくなります。この結果として、適用インスタンスの予期しない障害が発生すると、Oracle RACのすべてのオープン・インスタンス全体でバッファが一貫性のない状態となります。データの一貫性と整合性を確保するため、Data GuardはOracle RAC構成の他のすべてのオープン・インスタンスをクローズし、それらをマウント状態に移行します。手動でインスタンスを再オープンする必要があり、その時点でデータは自動的に一貫性を回復し、その後いずれかのインスタンスでREDO Applyが再開されます。Data Guard Broker構成では、インスタンスは自動的に再オープンされ、REDO Applyは自動的にいずれかのインスタンスで再開されることに注意してください。

関連項目:

- ブローカによる適用インスタンス障害の処理方法の詳細は、『Oracle Data Guard Broker』を参照してください。

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

9.2.1.5 破損データ・ブロックの自動修復

プライマリ・データベースのアクセス時に破損データ・ブロックが検出されると、フィジカル・スタンバイ・データベースの対応するブロックの破損していないコピーで自動的に置き換えられます。これには次の条件があります。

- フィジカル・スタンバイ・データベースがリアルタイム問合せモードで動作している必要があります(Active Data Guardライセンスが必要)。

- フィジカル・スタンバイ・データベースがリアルタイム適用を実行している必要があります。

次の点も考慮してください。

- 自動修復は、Data Guardのどの保護モードでもサポートされます。ただし、スタンバイの破損していないバージョンのブロックを使用してプライマリの破損ブロックを修復する場合の効果は、プライマリによって生成されるREDOとスタンバイ適用がどの程度密接に同期化されているかによって変化します。

- 自動ブロック修復が実行されると、データベースのアラート・ログにメッセージが書き込まれます。

- 自動ブロック修復が可能でない場合は、ORA-1578エラーが返されます。

フィジカル・スタンバイ・データベースに破損データ・ブロックが発見された場合、次のデータベース初期化パラメータがスタンバイ・データベースで構成されていれば、サーバーはプライマリ・データベースからこのブロックのコピーを取得することにより、破損を自動修復しようと試みます。

- LOG_ARCHIVE_CONFIGパラメータはDG_CONFIGリストを使用して構成され、LOG_ARCHIVE_DEST_nパラメータはプライマリ・データベース用に構成されている。
または

- FAL_SERVERパラメータが構成され、その値にプライマリ・データベース用のOracle Netサービス名が含まれている。

9.2.1.6 破損データ・ブロックの手動修復

破損データ・ブロックを手動で修復するには、RMAN RECOVER BLOCKコマンドを使用します。このコマンドは、データ・ブロックの破損していないコピーをいくつかの場所で探します。デフォルトの場所の1つは、リアルタイム問合せモードで実行しているいずれかのフィジカル・スタンバイ・データベースです。RMAN RECOVER BLOCKコマンドのEXCLUDE STANDBYオプションを使用すると、置換ブロックのコピー元からフィジカル・スタンバイ・データベースを除外することもできます。

関連項目:
Recovery ManagerのRECOVER BLOCKコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

9.2.1.7 フィジカル・スタンバイ・データベースでの問合せのチューニング

Active Data Guard 11gベスト・プラクティス・ホワイト・ペーパーの付録Dでは、フィジカル・データベースで最適パフォーマンスを実現するための問合せのチューニング方法について説明しています。このホワイト・ペーパーは、次のURLからOracle Maximum Availability Architecture(MAA)のホームページにアクセスして入手することができます。

http://www.oracle.com/goto/maa

9.2.1.8 フィジカル・スタンバイ・データベースへの一時ファイルの追加

スタンバイを使用してプライマリ・データベースから問合せをオフロードし、ワークロードの性質上、スタンバイの初回作成時に自動的に作成される一時表領域よりも多くの領域が必要になる場合、追加領域を手動で追加する必要があります。

一時ファイルをフィジカル・スタンバイ・データベースに追加するには、次のタスクを実行します。

1. 一時ファイルが格納される表領域を特定します。スタンバイ・データベースで次のコマンドを入力すると、特定できます。

SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES
2> WHERE CONTENTS = 'TEMPORARY';

TABLESPACE_NAME
--------------------------------
TEMP1
TEMP2

2. 前述の問合せで特定された表領域ごとに、新しい一時ファイルをスタンバイ・データベースに追加します。次の例では、TEMP1という新しい一時ファイルを追加します。このファイルは、プライマリ・データベースの一時ファイルと一致するサイズおよび再利用特性を持っています。

SQL> ALTER TABLESPACE TEMP1 ADD TEMPFILE
2> '/arch1/boston/temp01.dbf'
3> SIZE 40M REUSE;

9.3 フィジカル・スタンバイでの手動操作が必要なプライマリ・データベースの変更

プライマリ・データベースに対して行われる構造の変更のほとんどは、REDOデータによってフィジカル・スタンバイ・データベースに自動的に伝播します。表9-1に、フィジカル・スタンバイ・データベースで手動操作が必要なプライマリ・データベースの構造および構成の変更を示します。

表9-1 フィジカル・スタンバイでの手動操作が必要なプライマリ・データベースの変更

参照先

プライマリ・データベースの変更

フィジカル・スタンバイ・データベースで必要なアクション

9.3.1項

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

STANDBY_FILE_MANAGEMENTデータベース初期化パラメータがAUTOに設定されている場合、アクションは必要ない。このパラメータがMANUALに設定されている場合は、新しいデータファイルをフィジカル・スタンバイ・データベースにコピーする必要がある。

9.3.2項

表領域またはデータファイルの削除

DROPまたはDELETEコマンドを含むREDOデータがフィジカル・スタンバイに適用された後に、プライマリ・データベースとフィジカル・スタンバイ・データベースからデータファイルを削除する。

9.3.3項

トランスポータブル表領域の使用

プライマリ・データベースとフィジカル・スタンバイ・データベースの間で表領域を移動する。

9.3.4項

データファイルの改名

フィジカル・スタンバイ・データベースでデータファイル名を変更する。

9.3.5項

REDOログ・ファイル・グループの追加または削除

フィジカル・スタンバイ・データベースでREDOログおよびスタンバイREDOログの構成を評価し、必要に応じて調整する。

9.3.6項

NOLOGGINGまたはUNRECOVERABLE句を使用したDMLまたはDDL操作の実行

ログに記録されていない変更を含むデータファイルをフィジカル・スタンバイ・データベースにコピーする。

9.3.7項

管理権限の付与または取消し、あるいは管理権限を持つユーザーのパスワードの変更

REMOTE_LOGIN_PASSWORDFILE初期化パラメータがSHAREDまたはEXCLUSIVEに設定されている場合は、フィジカル・スタンバイ・データベースのパスワード・ファイルをプライマリ・データベースのパスワード・ファイルの最新コピーで置き換える。

9.3.8項

TDEマスター暗号化キーのリセット

フィジカル・スタンバイ・データベースのデータベース暗号化ウォレットをプライマリ・データベースのデータベース暗号化ウォレットの最新コピーで置き換える。

第14章

初期化パラメータの変更

フィジカル・スタンバイ・データベースで対応する変更を初期化パラメータに加える必要があるかどうかを評価する。

9.3.1 データファイルの追加または表領域の作成

STANDBY_FILE_MANAGEMENTデータベース初期化パラメータは、プライマリ・データベースへのデータファイルの追加を、フィジカル・スタンバイ・データベースに伝播するのかどうかを制御します。

- フィジカル・スタンバイ・データベースのSTANDBY_FILE_MANAGEMENTパラメータがAUTOに設定されている場合、プライマリ・データベースに作成された新しいデータファイルはフィジカル・スタンバイ・データベースに自動的に作成されます。

- フィジカル・スタンバイ・データベースのSTANDBY_FILE_MANAGEMENTデータベース・パラメータがMANUALに設定されている場合、新しいデータファイルがプライマリ・データベースに追加されると、そのファイルは、プライマリ・データベースからフィジカル・スタンバイ・データベースに手動でコピーする必要があります。

別のデータベースの既存のデータファイルがプライマリ・データベースにコピーされた場合、同様にそのファイルをスタンバイ・データベースにコピーする必要があり、STANDBY_FILE_MANAGEMENTパラメータの設定に関係なくスタンバイ制御ファイルを再作成する必要があります。

9.3.1.1 RAWデバイスでのSTANDBY_FILE_MANAGEMENTパラメータの使用

注意:
次の手順は、Oracle Managed Filesを使用するデータベースには使用しないでください。また、RAWデバイスのパス名がプライマリ・サーバー上とスタンバイ・サーバー上で異なる場合は、DB_FILE_NAME_CONVERTデータベース初期化パラメータを使用してパス名を変換してください。

STANDBY_FILE_MANAGEMENTパラメータをAUTOに設定し、データファイルをプライマリ・データベースに追加、またはプライマリ・データベースから削除するたびに、手動操作なしで該当する変更内容がスタンバイ・データベースにも反映されるようにします。スタンバイ・データベースがファイル・システムを使用している限り、これは適切な処理です。スタンバイ・データベースがデータファイルにRAWデバイスを使用している場合は、STANDBY_FILE_MANAGEMENTパラメータは作業を続行しますが、手動操作が必要になります。このような手動操作では、Redo Applyによって新しいデータファイルを作成するREDOデータを適用する前に、RAWデバイスの存在を確認する作業が必要です。プライマリ・データベース上で、データファイルがRAWデバイス内に存在する、新しい表領域を作成します。同時に、スタンバイ・データベース上でも同じRAWデバイスを作成します。次に例を示します。

SQL> CREATE TABLESPACE MTS2 DATAFILE '/dev/raw/raw100' size 1m;
Tablespace created.

SQL> ALTER SYSTEM SWITCH LOGFILE;
System altered.

スタンバイ・データベースでは、RAWデバイスが存在するため自動的にデータファイルが追加されます。スタンバイ・アラート・ログには次のように示されます。

Fri Apr  8 09:49:31 2005
Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1_mf_1_7_15ffgt0z_.arc
Recovery created file /dev/raw/raw100
Successfully added datafile 6 to media recovery
Datafile #6: '/dev/raw/raw100'
Media Recovery Waiting for thread 1 sequence 8 (in transit)

ただし、プライマリ・システム上でRAWデバイスが作成されてもスタンバイ上で作成されなければ、REDO Applyはファイル作成エラーにより停止します。たとえば、プライマリ・データベースで次の文を発行します。

SQL> CREATE TABLESPACE MTS3 DATAFILE '/dev/raw/raw101' size 1m;
Tablespace created.

SQL> ALTER SYSTEM SWITCH LOGFILE;
System altered.

スタンバイ・システムには、RAWデバイス/dev/raw/raw101が作成されていません。アーカイブをリカバリすると、スタンバイ・アラート・ログに次のメッセージが示されます。

Fri Apr  8 10:00:22 2005
Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1_mf_1_8_15ffjrov_.arc
File #7 added to control file as 'UNNAMED00007'.
Originally created as:
'/dev/raw/raw101'
Recovery was unable to create the file as:
'/dev/raw/raw101'
MRP0: Background Media Recovery terminated with error 1274
Fri Apr  8 10:00:22 2005
Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc:
ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created
ORA-01119: error in creating database file '/dev/raw/raw101'
ORA-27041: unable to open file
Linux Error: 13: Permission denied
Additional information: 1
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Fri Apr  8 10:00:22 2005
Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc:
ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created
ORA-01119: error in creating database file '/dev/raw/raw101'
ORA-27041: unable to open file
Linux Error: 13: Permission denied
Additional information: 1
Fri Apr  8 10:00:22 2005
MTS; MRP0: Background Media Recovery process shutdown
ARCH: Connecting to console port...

9.3.1.2 エラーのリカバリ

9.3.1.1項で説明した問題を修正する手順は、次のとおりです。

1. スタンバイ・データベースにRAWデバイスを作成し、Oracleユーザーに権限を割り当てます。

2. V$DATAFILEビューを問い合せます。次に例を示します。

SQL> SELECT NAME FROM V$DATAFILE;

NAME -------------------------------------------------------------------------------
/u01/MILLER/MTS/system01.dbf
/u01/MILLER/MTS/undotbs01.dbf
/u01/MILLER/MTS/sysaux01.dbf
/u01/MILLER/MTS/users01.dbf
/u01/MILLER/MTS/mts.dbf
/dev/raw/raw100
/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;

SQL> ALTER DATABASE CREATE DATAFILE -
> '/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007' -
>  AS -
> '/dev/raw/raw101';

3. スタンバイ・アラート・ログに、次のような情報が表示されます。

Fri Apr  8 10:09:30 2005
alter database create datafile
'/dev/raw/raw101' as '/dev/raw/raw101'

Fri Apr  8 10:09:30 2005
Completed: alter database create datafile
'/dev/raw/raw101' a

4. スタンバイ・データベースで、STANDBY_FILE_MANAGEMENTをAUTOに設定してREDO Applyを再開します。

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

この時点で、REDO Applyは新規のRAWデバイスのデータファイルを使用し、リカバリが続行されます。

9.3.2 表領域の削除とデータファイルの削除

プライマリ・データベースから表領域またはデータファイルを削除した場合、対応するデータファイルをフィジカル・スタンバイ・データベースから削除する必要があります。次の例に、表領域を削除する方法を示します。

SQL> DROP TABLESPACE tbs_4;
SQL> ALTER SYSTEM SWITCH LOGFILE;

削除されたデータファイルがデータベースに属していないことを確認するには、V$DATAFILEビューを問い合せます。

過去の変更を含むREDOデータがスタンバイ・データベースに適用された後、スタンバイ・システムで対応するデータファイルを削除します。次に例を示します。

% rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf

削除した表領域のREDO情報がスタンバイ・データベースで適用されたことを確認した後、プライマリ・データベースで表領域のデータファイルを削除できます。次に例を示します。

% rm /disk1/oracle/oradata/payroll/tbs_4.dbf

9.3.2.1 DROP TABLESPACE INCLUDING CONTENTS AND DATAFILESの使用

プライマリ・データベースでSQL DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES文を発行すると、プライマリ・データベースとスタンバイ・データベースの両方からデータファイルを削除できます。この文を使用するには、STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定する必要があります。たとえば、プライマリ・サイトで表領域を削除するには、次のように入力します。

SQL> DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES tbs_4;
SQL> ALTER SYSTEM SWITCH LOGFILE;

9.3.3 フィジカル・スタンバイ・データベースでのトランスポータブル表領域の使用

Oracleトランスポータブル表領域機能を使用すると、Oracleデータベースのサブセットを移動して、別のOracleデータベースにプラグインできます。これにより、実際には表領域がデータベース間で移動します。

フィジカル・スタンバイの使用中に表領域セットをプライマリ・データベースに移動またはコピーする手順は、次のとおりです。

1. トランスポートする表領域セットのデータファイルとその表領域セットの構造情報を含むエクスポート・ファイルで構成される、トランスポータブル表領域セットを生成します。

2. 次の手順で表領域セットをトランスポートします。

1. データファイルとエクスポート・ファイルをプライマリ・データベースにコピーします。

2. データファイルをスタンバイ・データベースにコピーします。

DB_FILE_NAME_CONVERTデータベース初期化パラメータが構成されていないかぎり、データファイルのパス名はプライマリ・データベースとスタンバイ・データベースで同じものが使用される必要があります。DB_FILE_NAME_CONVERTが構成されてなく、プライマリ・データベースとスタンバイ・データベースでデータファイルのパス名が同じではない場合、ALTER DATABASE RENAME FILE文を発行して、データファイルの名前を変更します。この操作は、REDO Applyが、表領域をプライマリ・データベースにプラグすることで生成されたREDOの適用に失敗した後で行います。データファイル名を変更する前に、STANDBY_FILE_MANAGEMENT初期化パラメータをMANUALに設定し、データファイル名を変更した後で、前の値にリセットする必要があります。

3. 表領域をプラグインします。
データ・ポンプ・ユーティリティを起動して、表領域セットをプライマリ・データベースにプラグインします。スタンバイ・サイトでREDOデータが生成されて適用され、表領域がスタンバイ・データベースにプラグインされます。

トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

9.3.4 プライマリ・データベースのデータファイルの改名

プライマリ・データベースで1つ以上のデータファイルを改名した場合、その変更はスタンバイ・データベースに伝播されません。STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定しても変更処理は自動的に実行されないため、スタンバイ・データベースにある同じデータファイルを改名する場合は、スタンバイ・データベースで同じ変更を手動で行う必要があります。

次の手順では、プライマリ・データベースでデータファイルを改名し、その変更をスタンバイ・データベースに手動で伝播する方法について説明します。

1. プライマリ・データベースでデータファイルを改名するには、表領域をオフラインにします。

SQL> ALTER TABLESPACE tbs_4 OFFLINE;

2. SQLプロンプトを終了し、UNIXのmvコマンドなどのオペレーティング・システム・コマンドを発行して、プライマリ・システム上のデータファイルを改名します。

% mv /disk1/oracle/oradata/payroll/tbs_4.dbf
/disk1/oracle/oradata/payroll/tbs_x.dbf

3. プライマリ・データベース内のデータファイルを改名し、表領域をオンラインに戻します。

SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE -
> '/disk1/oracle/oradata/payroll/tbs_4.dbf' -
>  TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';

SQL> ALTER TABLESPACE tbs_4 ONLINE;

4. スタンバイ・データベースに接続し、REDO Applyを停止します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

5. スタンバイ・データベースを停止します。

SQL> SHUTDOWN;

6. UNIXのmvコマンドなどのオペレーティング・システム・コマンドを使用して、スタンバイ・サイトでデータファイルを改名します。

% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf

7. スタンバイ・データベースを起動し、マウントします。

SQL> STARTUP MOUNT;

8. スタンバイ制御ファイルのデータファイルを改名します。データファイル名を変更するには、STANDBY_FILE_MANAGEMENTデータベース初期化パラメータをMANUALに設定する必要があります。このパラメータは、データファイル名の変更後、前の値にリセットできます。

SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf' -
> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';

9. スタンバイ・データベースで、REDO Applyを再開します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE -
> DISCONNECT FROM SESSION;

スタンバイ・システムで対応するデータファイルを改名しないでスタンバイ・データベース制御ファイルをリフレッシュしようとすると、スタンバイ・データベースは改名されたデータファイルの使用を試みますが、改名されたデータファイルは見つかりません。したがって、アラート・ログに次のようなエラー・メッセージが表示されます。

ORA-00283: recovery session canceled due to errors
ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file
ORA-01110: datafile 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf'

9.3.5 REDOログ・ファイル・グループの追加または削除

プライマリ・データベースでログ・ファイル・グループを追加または削除した後に、フィジカル・スタンバイ・データベースのREDOログおよびスタンバイREDOログの構成を再評価し、必要に応じて調整する必要があります。

次の手順を実行して、フィジカル・スタンバイ・データベースでログ・ファイル・グループまたはスタンバイ・ログ・ファイル・グループを追加または削除します。

1. REDO Applyを停止します。

2. STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定している場合は、値をMANUALに変更します。

3. REDOログ・ファイル・グループを追加または削除します。

注意:
オンライン・ログ・ファイル・グループは、フィジカル・スタンバイ・データベースから削除するには、常に手動で消去する必要があります。次に例を示します。

ALTER DATABASE CLEAR LOGFILE GROUP 3;

ステータスがCURRENTまたはCLEARING_CURRENTであるオンライン・ログ・ファイル・グループは、フィジカル・スタンバイ・データベースから削除できません。このステータスのオンライン・ログ・ファイル・グループは、ロール推移後に削除できます。

4. STANDBY_FILE_MANAGEMENT初期化パラメータおよびREDO Applyオプションを元の状態にリストアします。

5. REDO Applyを再開します。

9.3.6 ログに記録されていないまたはリカバリ不能な操作

NOLOGGINGまたはUNRECOVERABLE句を使用してDMLまたはDDL操作を実行するとスタンバイ・データベースは無効になるため、修正のために多大なDBA管理アクティビティが必要になる場合があります。SQL ALTER DATABASEまたはSQL ALTER TABLESPACE文でFORCE LOGGING句を指定すると、NOLOGGING 設定を上書きできます。ただし、この文はすでに無効になっているデータベースを修正しません。

NOLOGGING句を使用した後のリカバリの詳細は、13.4項を参照してください。

9.3.7 パスワード・ファイルのリフレッシュ

REMOTE_LOGIN_PASSWORDFILEデータベース初期化パラメータがSHAREDまたはEXCLUSIVEに設定されている場合、管理権限を付与または取り消すか、あるいは管理権限を持つユーザーのパスワードを変更した後に、フィジカル・スタンバイ・データベースのパスワード・ファイルをプライマリ・データベースの最新コピーで置き換える必要があります。

フィジカル・スタンバイ・データベースのパスワード・ファイルをリフレッシュできないと、REDO転送セッションの認証やSYSDBAまたはSYSOPERとしてのフィジカル・スタンバイ・データベースへの接続が失敗する可能性があります。

9.3.8 TDEマスター暗号化キーのリセット

フィジカル・スタンバイ・データベースのデータベース暗号化ウォレットは、プライマリ・データベースでTDEマスター暗号化キーがリセットされるたびに、プライマリ・データベースのデータベース暗号化ウォレットの最新コピーで置き換える必要があります。

フィジカル・スタンバイ・データベースのデータベース暗号化ウォレットをリフレッシュできないと、プライマリ・データベースでマスター暗号化キーがリセットされた後に変更された、フィジカル・スタンバイ・データベース上の暗号化された列にアクセスできません。

9.4 OPEN RESETLOGS文を使用したリカバリ

Data Guardでは、RESETLOGSオプションを使用してプライマリ・データベースがオープンされた後も、フィジカル・スタンバイ・データベースでリカバリを続行できます。プライマリ・データベースでALTER DATABASE OPEN RESETLOGS文を発行すると、データベースのインカネーションが変更され、REDOデータの新規ブランチが作成されます。

フィジカル・スタンバイ・データベースがREDOデータの新規ブランチを受信すると、REDO Applyではそれが自動的に使用されます。フィジカル・スタンバイ・データベースの場合、スタンバイ・データベースにより新規リセットログのSCNより後(REDOデータの新規ブランチの開始より後)のREDOデータが適用されていなければ、手動による介入は必要ありません。次の表に、スタンバイ・データベースとプライマリ・データベースのブランチを再同期化する方法を示します。

スタンバイ・データベースの状態 . .

操作 . .

実行する手順 . .

新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用されておらず、OPEN RESETLOGSの新規REDOブランチがスタンバイに登録されている場合

REDO Applyは自動的にREDOの新規ブランチを使用します。

手動による介入は必要ありません。MRPは、自動的にスタンバイ・データベースをREDOデータの新規ブランチと再同期化します。
注意: 新規REDOブランチがスタンバイに登録されたかどうかを調べるには、プライマリおよびスタンバイで次の問合せを実行して、結果が一致することを確認します。

SELECT resetlogs_id, resetlogs_change# FROM V$DATABASE_INCARNATION WHERE status='CURRENT'

新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっている場合。

スタンバイ・データベースは、REDOデータの将来の新規ブランチでリカバリされます。

1. 13.3.1項の手順に従ってフィジカル・スタンバイ・データベースをフラッシュバックします。

2. REDO Applyを再開し、新規リセットログ・ブランチへのREDOデータの適用を続行します。

MRPは、自動的にスタンバイ・データベースを新規ブランチと再同期化します。

新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっていない場合。

指定のプライマリ・データベース・ブランチで、プライマリ・データベースとスタンバイの内容にずれが生じます。

第3章の手順に従ってフィジカル・スタンバイ・データベースを再作成します。

REDOデータの新規ブランチから介入するアーカイブREDOログ・ファイルが欠落している場合。

MRPは欠落しているログ・ファイルが取得されるまで続行できません。

各ブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。

REDOデータの前のブランチの終わりからアーカイブREDOログ・ファイルが欠落している場合。

MRPは欠落しているログ・ファイルが取得されるまで続行できません。

前のブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。

データベース・インカネーション、OPEN RESETLOGSによるリカバリ、フラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

9.5 プライマリ、フィジカル・スタンバイおよびスナップショット・スタンバイ・データベースの監視

この項では、プライマリ・データベースおよびスタンバイ・データベースを監視するために役立つ情報の検索方法について説明します。

表9-2に、一般的なプライマリ・データベースの管理アクションと、そのアクションに関する情報の参照先を示します。

表9-2 一般的なプライマリ・データベースの管理アクションに関する情報ソース

プライマリ・データベースのアクション

プライマリ・サイト情報

スタンバイ・サイト情報

REDOスレッドの有効化または無効化

- アラート・ログ

- V$THREAD

アラート・ログ

データベース・ロール、保護モード、保護レベル、スイッチオーバー・ステータス、ファスト・スタート・フェイルオーバー情報などの表示

V$DATABASE

V$DATABASE

REDOログ・ファイル・グループの追加または削除

- アラート・ログ

- V$LOG

- V$LOGFILEのSTATUS列

アラート・ログ

CREATE CONTROLFILE

アラート・ログ

アラート・ログ

REDO Applyの監視

- アラート・ログ

- V$ARCHIVE_DEST_STATUS

- アラート・ログ

- V$ARCHIVED_LOG

- V$LOG_HISTORY

- V$MANAGED_STANDBY

表領域ステータスの変更

- V$RECOVER_FILE

- DBA_TABLESPACES

- アラート・ログ

- V$RECOVER_FILE

- DBA_TABLESPACES

データファイルまたは表領域の追加または削除

- DBA_DATA_FILES

- アラート・ログ

- V$DATAFILE

- アラート・ログ

データファイルの改名

- V$DATAFILE

- アラート・ログ

- V$DATAFILE

- アラート・ログ

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

- V$DATAFILE

- V$DATABASE

アラート・ログ

REDO転送の監視

- V$ARCHIVE_DEST_STATUS

- V$ARCHIVED_LOG

- V$ARCHIVE_DEST

- アラート・ログ

- V$ARCHIVED_LOG

- アラート・ログ

OPEN RESETLOGSまたはCLEAR UNARCHIVED LOGFILES文の発行

アラート・ログ

アラート・ログ

初期化パラメータの変更

アラート・ログ

アラート・ログ

9.5.1 プライマリ、フィジカルおよびスナップショット・スタンバイ・データベースを監視するためのビューの使用

この項では、動的パフォーマンス・ビューを使用してプライマリ・データベース、フィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースを監視する方法について説明します。

次の動的パフォーマンス・ビューについて説明します。

- V$DATABASE

- V$MANAGED_STANDBY

- V$ARCHIVED_LOG

- V$LOG_HISTORY

- V$DATAGUARD_STATUS

- V$ARCHIVE_DEST

関連項目:
ビューの詳細な参照情報は、『Oracle Databaseリファレンス』を参照してください。

9.5.1.1 V$DATABASE

次の問合せは、プライマリ・データベース、フィジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースのデータ保護モード、データ保護レベル、データベース・ロールおよびスイッチオーバー・ステータスを表示します。

SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL, –
> DATABASE_ROLE ROLE, SWITCHOVER_STATUS –
> FROM V$DATABASE;

次の問合せは、ファスト・スタート・フェイルオーバーのステータスを表示します。

SQL> SELECT FS_FAILOVER_STATUS "FSFO STATUS", -
> FS_FAILOVER_CURRENT_TARGET TARGET, -
> FS_FAILOVER_THRESHOLD THRESHOLD, -
> FS_FAILOVER_OBSERVER_PRESENT "OBSERVER PRESENT" –
> FROM V$DATABASE;

9.5.1.2 V$MANAGED_STANDBY

次の問合せは、フィジカル・スタンバイ・データベースでのREDO ApplyおよびREDO転送ステータスを表示します。

SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#,-
> BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;

PROCESS STATUS       THREAD#    SEQUENCE#  BLOCK#     BLOCKS
------- ------------ ---------- ---------- ---------- ----------
RFS     ATTACHED     1          947        72         72
MRP0    APPLYING_LOG 1          946        10         72

このサンプル出力は、RFSプロセスがREDOログ・ファイル順序番号947のアーカイブを完了したことを示しています。また、REDO ApplyがアーカイブREDOログ・ファイル順序番号946を適用していることも示しています。

9.5.1.3 V$ARCHIVED_LOG

次の問合せは、フィジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースでプライマリ・データベースから受信したアーカイブREDOログ・ファイルに関する情報を表示します。

SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, -
> NEXT_CHANGE# FROM V$ARCHIVED_LOG;

THREAD#    SEQUENCE#  FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1          945        74651         74739
1          946        74739         74772
1          947        74772         74795

このサンプル出力は、プライマリ・データベースから受信した3つのアーカイブREDOログ・ファイルを示しています。

9.5.1.4 V$LOG_HISTORY

次の問合せは、アーカイブ・ログの履歴情報を表示します。

SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, -
> NEXT_CHANGE# FROM V$LOG_HISTORY;

9.5.1.5 V$DATAGUARD_STATUS

次の問合せは、アラート・ログまたはサーバー・プロセス・トレース・ファイルにメッセージが書き込まれる原因となったData Guardイベントによって生成されたメッセージを表示します。

SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;

9.5.1.6 V$ARCHIVE_DEST

次の問合せは、各REDO転送先のステータスと、スタンバイ・データベースであるREDO転送先については、そのスタンバイ・データベースで適用された最後のプライマリ・データベースREDOのSCNを表示します。

SQL> SELECT DEST_ID, APPLIED_SCN FROM V$ARCHIVE_DEST WHERE TARGET='STANDBY';

DEST_ID    STATUS    APPLIED_SCN
---------- --------- -----------
2          VALID     439054
3          VALID     439054

9.6 REDO Applyのチューニング

REDO Applyおよびメディア・リカバリのパフォーマンスを最適化する方法は、『Oracle Data Guard Redo Apply and Media Recovery Best Practices』ホワイト・ペーパーを参照してください。このホワイト・ペーパーは、次のURLからOracle Maximum Availability Architecture(MAA)のホームページにアクセスして入手することができます。

http://www.oracle.com/goto/maa

関連項目:
Standby Statspackのインストールと使用の詳細は、http://support.oracle.comのMy Oracle Supportノート454848.1を参照してください。Standby Statspackはフィジカル・スタンバイ・データベースからRedo Applyパフォーマンス・データを収集するために使用することもできます。

9.7 スナップショット・スタンバイ・データベースの管理

スナップショット・スタンバイ・データベースは、全面的に更新可能なスタンバイ・データベースです。スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信およびアーカイブしますが、適用はしません。プライマリ・データベースから受信したREDOデータは、スナップショット・スタンバイ・データベースへのローカル更新がすべて破棄された後、スナップショット・スタンバイ・データベースが変換されてフィジカル・スタンバイ・データベースに戻ると適用されます。

プライマリ・データベースのREDOデータは受信と同時には適用されないので、スナップショット・スタンバイ・データベースは通常、時間の経過とともにプライマリ・データベースとの差異が生じます。スナップショット・スタンバイ・データベースのローカルな更新によって差異が増えます。ただし、スナップショット・スタンバイはいつでもフィジカル・スタンバイ・データベースに戻すことができ、その後プライマリから受信したREDOデータを適用できるので、プライマリ・データベース内のデータは完全に保護されています。

スナップショット・スタンバイ・データベースには、フィジカル・スタンバイ・データベースと同様の、障害時リカバリおよびデータ保護のメリットがあります。スナップショット・スタンバイ・データベースは、プライマリ・データベースの一時的かつ更新可能なスナップショットを保持することにメリットがあれば、プライマリ・データベースの障害からリカバリする時間が増えてもかまわない場合に最もよく使用されます。

9.7.1 スナップショット・スタンバイ・データベースへのフィジカル・スタンバイ・データベースの変換

次の手順を実行して、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換します。

1. REDO Applyがアクティブな場合は、停止します。

2. データベースがマウントされ、オープンしていないことを確認します。

3. 高速リカバリ領域が構成されていることを確認します。フラッシュバック・データベースを有効化する必要はありません。

4. 次のSQL文を発行して変換を実行します。

SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;

注意:
Data Guard Brokerで管理されるフィジカル・スタンバイ・データベースは、DGMGRLまたはOracle Enterprise Managerのいずれかを使用してスナップショット・スタンバイ・データベースに変換できます。詳細は、『Oracle Data Guard Broker』を参照してください。

9.7.2 スナップショット・スタンバイ・データベースの使用

スナップショット・スタンバイ・データベースは読取り/書込みモードでオープンされ、全体を更新できます。

スナップショット・スタンバイ・データベースには、次の特性があります。

- スナップショット・スタンバイ・データベースは、スイッチオーバーまたはフェイルオーバーのターゲットにはできません。スナップショット・スタンバイ・データベースは、ロールの推移を実行する前にフィジカル・スタンバイ・データベースに変換して戻す必要があります。

- スナップショット・スタンバイ・データベースは、最大保護のData Guard構成では唯一のスタンバイ・データベースになりません。

注意:
フラッシュバック・データベースを使用して、スナップショット・スタンバイ・データベースを変換してフィジカル・スタンバイ・データベースに戻すことができます。フラッシュバック・データベース・テクノロジを使用して元に戻すことができない操作は、スナップショット・スタンバイを変換してフィジカル・スタンバイに戻すことを妨げます。
フラッシュバック・データベースの詳細と制約は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

9.7.3 フィジカル・スタンバイ・データベースへのスナップショット・スタンバイ・データベースの変換

次の手順を実行して、スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに変換します。

1. Oracle Real Application Clusters(Oracle RAC)データベースで、1つのインスタンス以外はすべて停止します。

2. データベースがマウントされ、オープンしていないことを確認します。

3. 次のSQL文を発行して変換を実行します。

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

データベースは変換後にディスマウントされ、再起動する必要があります。

データベースがスナップショット・スタンバイ・データベースの間に受信したREDOデータは、REDO Applyが開始されると自動的に適用されます。

注意:
スナップショット・スタンバイ・データベースは、少なくとも1回は読取り/書込みモードでオープンしてから、フィジカル・スタンバイ・データベースに変換する必要があります。

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

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

- SQL Applyアーキテクチャの概要

- ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスの制御

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

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

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

- ロジカル・スタンバイ・データベースの下での特定のワークロードの管理

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

- ロジカル・スタンバイ・データベースの下でのバックアップおよびリカバリ

10.1 SQL Applyアーキテクチャの概要

SQL Applyでは、バックグラウンド・プロセスの集合を使用して、プライマリ・データベースの変更がロジカル・スタンバイ・データベースに適用されます。

図10-1に、情報のフローと各プロセスで実行されるロールを示します。

図10-1 SQL Applyの処理

ログのマイニングおよび適用処理中は、次のように、様々なプロセスとその機能が関係します。

ログのマイニング中には、次のプロセスが実行されます。

- READERプロセスでは、REDOレコードがアーカイブREDOログ・ファイルまたはスタンバイREDOログ・ファイルから読み込まれます。

- PREPARERプロセスでは、REDOレコードに含まれるブロックの変更が論理変更レコード(LCR)に変換されます。特定のREDOログ・ファイルに対して複数のPREPARERプロセスをアクティブにすることができます。LCRは、LCRキャッシュと呼ばれるシステム・グローバル領域(SGA)でステージングされます。

- BUILDERプロセスでは、LCRがトランザクション単位にグループ化されて、LCRキャッシュ内のメモリー管理、SQL Applyの再起動に関連するチェックポイント処理および重要でない変更のフィルタリングなど、その他のタスクが実行されます。

適用処理中には、次のプロセスが実行されます。

- ANALYZERプロセスでは、様々なトランザクション間の依存性が識別されます。

- COORDINATORプロセス(LSP)では、トランザクションを様々なAPPLIERに割り当て、トランザクション間の依存性が考慮されるように調整します。

- APPLIERプロセスでは、COORDINATORプロセスの管理下でロジカル・スタンバイ・データベースにトランザクションを適用します。

V$LOGSTDBY_PROCESSビューで問い合せて、SQL Applyプロセスのアクティビティを確認することができます。現在のアクティビティの情報を提供する別なビューにV$LOGSTDBY_STATSがあり、SQL Applyアクティビティ中のロジカル・スタンバイ・データベースのための統計、現在の状態、ステータス情報を表示します。このビューと関連するその他のビューの詳細は、10.3項「ロジカル・スタンバイ・データベースの管理と監視に関連するビュー」を参照してください。

注意:
SQL Applyプロセス(COORDINATORプロセスlsp0を含む)はすべてバックグラウンド・プロセスです。リソース・マネージャによる調整は行われません。そのため、ロジカル・スタンバイ・データベースでリソース・グループを作成しても、SQL Applyプロセスには影響ありません。

10.1.1 SQL Applyに関する各種の考慮事項

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

- トランザクション・サイズの考慮事項

- ページアウトの考慮事項

- 再開の考慮事項

- DML適用の考慮事項

- DDL適用の考慮事項

- パスワード検証関数

10.1.1.1 トランザクション・サイズの考慮事項

SQL Applyでは、トランザクションが大小2つのクラスに分類されます。

- 小さいトランザクション: SQL Applyは、REDOログ・ファイル内で小さいトランザクションのコミット・レコードを検出すると、そのトランザクションに属するLCRの適用を開始します。

- 大きいトランザクション: SQL Applyは、大きいトランザクションをトランザクション・チャンクと呼ばれる小さい単位に分割し、そのトランザクションのコミット・レコードをREDOログ・ファイル内で検出する前に、チャンクの適用を開始します。この処理が実行されるのは、LCRキャッシュのメモリー使用量を削減し、フェイルオーバー時間全体を短縮するためです。
たとえば、小さく分割しない場合、SQL*Loaderのロードが1000万行で、サイズがそれぞれ100バイトであれば、LCRキャッシュでは1GBを超えるメモリーが使用されます。LCRキャッシュに割り当てられているメモリーが1GB未満の場合は、LCRキャッシュからのページアウトが発生します。

メモリーの考慮事項とは別に、SQL ApplyがトランザクションのCOMMITレコードを検出するまでに1000万行のSQL*Loaderロードに関連する変更の適用を開始しない場合、ロールの推移が停止します。SQL Applyがロジカル・スタンバイ・データベース上でトランザクションを適用し終わるまで、そのトランザクションのコミット後に開始されたスイッチオーバーまたはフェイルオーバーは終了できません。

トランザクション・チャンクの使用にもかかわらず、800万行超を変更するトランザクションの処理時にSQL Applyのパフォーマンスが低下することがあります。800万行を超えるトランザクションでは、SQL Applyは一時セグメントを使用して、トランザクションの処理に必要な一部の内部メタデータを処理します。800万行を超えるトランザクションを正常に処理するには、SQL Applyで使用される一時セグメントに十分なスペースを割り当てる必要があります。

すべてのトランザクションは、最初は小さいトランザクションとして分類されます。SQL Applyでは、トランザクションが大きいトランザクションとして再分類されるタイミングは、LCRキャッシュに使用可能なメモリー量と、トランザクションに属するLCRのメモリー使用量に応じて決定します。

10.1.1.2 ページアウトの考慮事項

LCRキャッシュのメモリーがすべて使用され、SQL Applyを進行させるために領域の解放が必要になると、SQL Applyのコンテキスト内でページアウトが発生します。

たとえば、LCRキャッシュに100MBのメモリーが割り当てられている場合に、SQL Applyでサイズが300MBのLONG列を含む表に対するINSERTトランザクションが検出されるとします。この場合、ログ・マイニング・コンポーネントは、LONGデータの最初の部分をページアウトして列変更の後半部分を読み取ります。適切にチューニングされているロジカル・スタンバイ・データベースの場合、ページアウト・アクティビティはほとんど発生せず、システム全体のスループットには影響しません。

関連項目:
問題のあるページアウトを識別して修正処理を実行する方法の詳細は、10.5項「ロジカル・スタンバイ・データベースのカスタマイズ」を参照してください。

10.1.1.3 再起動の考慮事項

トランザクションのコミット・レコードがREDOログ・ファイルからマイニングされてロジカル・スタンバイ・データベースに適用されるまで、ロジカル・スタンバイ・データベースに対する変更は永続的な変更になりません。つまり、ユーザー指示の結果であるかシステム障害の結果であるかに関係なく、SQL Applyは停止されるたびに、コミットされていない最も古いトランザクションまで遡って再びマイニングする必要があります。

作業量は少ないが、長期間開いたままになるトランザクションの場合、SQL Applyを最初からやりなおすとSQL Applyはコミットされていない少量のトランザクションに対してREDOデータを再度読み込むために、アーカイブされた大量のREDOログ・ファイルを再度マイニングしなければならなくなるので非常に効率が悪くなります。これを回避するために、SQL Applyはコミットされていない古いデータに対して、定期的にチェックポイントを行っています。チェックポイントを実施するSCNは、V$LOGSTDBY_PROGRESSビューのRESTART_SCN列に反映さえます。再開後、SQL ApplyはRESTART_SCN列に表示された値よりも大きいSCNで生成されたREDOレコードのマイニングを開始します。SQL Applyは、アーカイブされたREDOログ・ファイルのうち再開が不要なものを自動的に削除します。

大量のDDLトランザクション、パラレルDML文(PDML)、および直接パス・ロードなどの特定のワークロードによっては、ワークロードが完了するまで、RESTART_SCNが中断します。

10.1.1.4 DML適用の考慮事項

SQL Applyがロジカル・スタンバイ・データベースのスループットと待機時間に影響するDMLトランザクションを適用する場合、次の特性があります。

- 1つの文で複数の行が変更されるバッチ更新または削除をプライマリ・データベースで実行した場合、ロジカル・スタンバイ・データベースでは行の個別変更として適用されます。そのため、メンテナンスされている各表に一意索引または主キーが必要になります。詳細は、4.1.2項「プライマリ・データベース内の表の行が一意に識別できることの確認」を参照してください。

- プライマリ・データベースで実行されたダイレクト・パス・インサートは、ロジカル・スタンバイ・データベースで従来型のINSERT文を使用して適用されます。

- パラレルDML(PDML)トランザクションは、ロジカル・スタンバイ・データベースではパラレルに実行されません。

10.1.1.5 DDL適用の考慮事項

SQL Applyがロジカル・スタンバイ・データベースのスループットと待機時間に影響するDDLトランザクションを適用する場合、次の特性があります。

- DDLトランザクションは、ロジカル・スタンバイ・データベースではシリアルに適用されます。そのため、プライマリ・データベースで同時に適用されたDDLトランザクションは、ロジカル・スタンバイ・データベースでは一度に1つずつ適用されます。

- ロジカル・スタンバイ・データベース上でDMLアクティビティ(CREATE TABLE AS SELECT(CTAS)文の一部)が抑制されるように、CTAS文が実行されます。CTAS文の一部として新規作成された表に挿入された行は、REDOログ・ファイルからマイニングされ、INSERT文を使用してロジカル・スタンバイ・データベースに適用されます。

- SQL Applyは、プライマリ・データベースで実行されたDDLを再発行し、DDL操作のターゲットである同じオブジェクトで、同じトランザクション内で発生するDMLがロジカル・スタンバイ・データベースでレプリケートされないようにします。そのため、次の2つの場合にプライマリ・サイトとスタンバイ・サイトは互いに異なります。

- DDLに、プライマリ・データベースの状態から導出される非リテラル値が含まれる場合。このようなDDLの例を次に示します。

ALTER TABLE hr.employees ADD (start_date date default sysdate);

SQL Applyはロジカル・スタンバイで同じDDLを再発行するため、sysdate()ファンクションはロジカル・スタンバイで再評価されます。そのため、start_date列は、プライマリ・データベースでのデフォルト値とは異なるデフォルト値で作成されます。

- DDLで、ターゲット表で定義されているDMLトリガーを起動する場合。トリガーされるDMLはDDLと同じトランザクションで発生し、DDLのターゲット表で動作するため、これらのトリガーされるDMLは、ロジカル・スタンバイでレプリケートされません。
たとえば、次のような表を作成するとします。

create table HR.TEMP_EMPLOYEES (
emp_id       number primary key,
first_name   varchar2(64),
last_name    varchar2(64),
modify_date  timestamp);

次に、表にトリガーを作成して、表が更新されるたびに、modify_dateを更新して変更時間が反映されるようにします。

CREATE OR REPLACE TRIGGER TRG_TEST_MOD_DT  BEFORE UPDATE ON HR.TEST_EMPLOYEES
REFERENCING
NEW  AS NEW_ROW  FOR EACH ROW
BEGIN
:NEW_ROW.MODIFY_DATE:= SYSTIMESTAMP;
END;
/

通常のDML/DDLワークロードではこの表は正しく維持されます。ただし、この表にデフォルト値を含む列を追加すると、ADD COLUMN DDLがこの更新トリガーを起動し、表内のすべての行のMODIFY_DATE列を新しいタイムスタンプに変更します。MODIFY_DATE列へのこの種の変更は、ロジカル・スタンバイ・データベースにはレプリケートされません。REDOストリーム内に記録されたMODIFY_DATE列データがロジカル・スタンバイ・データベース内のデータと一致しないため、この表に対してこれ以降DMLを行うと、SQL Applyが停止します。

10.1.1.6 パスワード検証関数

パスワードの複雑性をチェックするパスワード検証関数は、SYSスキーマで作成する必要があります。SQL ApplyはSYSスキーマで作成されたオブジェクトをレプリケートしないため、このような検証関数は、ロジカル・スタンバイ・データベースにレプリケートされません。ロジカル・スタンバイ・データベースでは、パスワード検証関数を手動で作成し、適切なプロファイルと関連付ける必要があります。

10.2 ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスの制御

SQLのALTER DATABASE GUARD文は、ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスを制御します。デフォルトでは、ロジカル・スタンバイ・データベースについてはデータベース・ガードがALLに設定されています。

ALTER DATABASE GUARD文では、次のキーワードを使用できます。

- ALL
ALLを指定すると、SYS以外のすべてのユーザーが、ロジカル・スタンバイ・データベース内のデータを変更できなくなります。

- STANDBY
STANDBYを指定すると、SYS以外のすべてのユーザーが、SQL Applyでメンテナンスされる表または順序に対してDMLおよびDDLを変更できなくなります。

- NONE
NONEを指定すると、データベース内の全データには通常のセキュリティが適用されます。

たとえば、SQL Applyによってメンテナンスされない表をユーザーが変更できるようにするには、次の文を使用します。

SQL> ALTER DATABASE GUARD STANDBY;

権限を持つユーザーは、ALTER SESSION DISABLE GUARDおよびALTER SESSION ENABLE GUARD文をそれぞれ使用して、現在のセッションでデータベース・ガードを一時的にオフまたはオンにできます。この文は、Oracle9iと同じ機能を実行するDBMS_LOGSTDBY.GUARD_BYPASS PL/SQLプロシージャを配置します。ALTER SESSION [ENABLE|DISABLE] GUARD文は、10.5.4項に説明されているように、データベース・ガードを一時的に無効にしてデータベースを変更するときに役立ちます。

注意:
データベース・ガードが無効のときに、プライマリおよびロジカル・スタンバイ・データベースの内容に相違を生じさせないようにしてください。

10.3 ロジカル・スタンバイ・データベースの管理および監視関連のビュー

次のパフォーマンス・ビューでは、ロジカル・スタンバイ・データベースを保守するSQL Applyの動作が監視されます。次の各項では、ロジカル・スタンバイ・データベースの監視に使用できる主なビューについて説明します。

- DBA_LOGSTDBY_EVENTSビュー

- DBA_LOGSTDBY_LOGビュー

- V$DATAGUARD_STATSビュー

- V$LOGSTDBY_PROCESSビュー

- V$LOGSTDBY_PROGRESSビュー

- V$LOGSTDBY_STATEビュー

- V$LOGSTDBY_STATSビュー

関連項目:
ビューの詳細な参照情報は、『Oracle Databaseリファレンス』を参照してください。

10.3.1 DBA_LOGSTDBY_EVENTSビュー

DBA_LOGSTDBY_EVENTSビューには、SQL Apply操作中に発生した重要なイベントが記録されます。デフォルトでは、最新の10,000のイベントが記録されます。ただし、記録されるイベントの数は、PL/SQLプロシージャDBMS_LOGSTDBY.APPLY_SET()をコールして変更できます。SQL Applyが突然停止した場合は、このビューにその原因も記録されます。

注意:
SQL Applyを停止させたエラーはイベント・テーブル内に記録されます。このイベントはALERT.LOGファイルにも記録され、テキスト内にLOGSTDBYキーワードが含まれます。ビューの問合せの際に、EVENT_TIME_STAMP、COMMIT_SCN、およびCURRENT_SCNによって列を順番に選択し、イベントの順序を正しく並べます。

このビューは、適用されたDDLトランザクションやスキップされたDDLトランザクションなどの他の情報も表示されるようにカスタマイズできます。次に例を示します。

SQL> ALTER SESSION SET NLS_DATE_FORMAT  = 'DD-MON-YY HH24:MI:SS';
Session altered.
SQL> COLUMN STATUS FORMAT A60
SQL> SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS -
> ORDER BY EVENT_TIMESTAMP, COMMIT_SCN, CURRENT_SCN;

EVENT_TIME         STATUS
------------------------------------------------------------------------------
EVENT
-------------------------------------------------------------------------------
23-JUL-02 18:20:12 ORA-16111: log mining and apply setting up
23-JUL-02 18:25:12 ORA-16128: User initiated shut down successfully completed
23-JUL-02 18:27:12 ORA-16112: log mining and apply stopping
23-JUL-02 18:55:12 ORA-16128: User initiated shut down successfully completed
23-JUL-02 18:57:09 ORA-16111: log mining and apply setting up
23-JUL-02 20:21:47 ORA-16204: DDL successfully applied
create table hr.test_emp (empno number, ename varchar2(64))
23-JUL-02 20:22:55 ORA-16205: DDL skipped due to skip setting
create database link link_to_boston connect to system identified by change_on_inst
7 rows selected.

この問合せによって、SQL Applyが数回開始および停止したことがわかります。またDDLが適用され、スキップされたこともわかります。

10.3.2 DBA_LOGSTDBY_LOGビュー

DBA_LOGSTDBY_LOGビューには、SQL Applyで処理中のアーカイブ・ログに関する動的な情報が表示されます。

次に例を示します。

SQL> COLUMN DICT_BEGIN FORMAT A10;
SQL> SET NUMF 99999999;
SQL> SELECT FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS F_SCN#, -
>  NEXT_CHANGE# AS N_SCN#, TIMESTAMP, -
>  DICT_BEGIN AS BEG, DICT_END AS END, -
>  THREAD# AS THR#, APPLIED FROM DBA_LOGSTDBY_LOG -
>  ORDER BY SEQUENCE#;

FILE_NAME                 SEQ# F_SCN    N_SCN TIMESTAM BEG END THR# APPLIED
------------------------- ---- ------- ------- -------- --- --- --- ---------
/oracle/dbs/hq_nyc_2.log  2     101579  101588 11:02:58 NO  NO  1     YES
/oracle/dbs/hq_nyc_3.log  3     101588  142065 11:02:02 NO  NO  1     YES
/oracle/dbs/hq_nyc_4.log  4     142065  142307 11:02:10 NO  NO  1     YES
/oracle/dbs/hq_nyc_5.log  5     142307  142739 11:02:48 YES YES 1     YES
/oracle/dbs/hq_nyc_6.log  6     142739  143973 12:02:10 NO  NO  1     YES
/oracle/dbs/hq_nyc_7.log  7     143973  144042 01:02:11 NO  NO  1     YES
/oracle/dbs/hq_nyc_8.log  8     144042  144051 01:02:01 NO  NO  1     YES
/oracle/dbs/hq_nyc_9.log  9     144051  144054 01:02:16 NO  NO  1     YES
/oracle/dbs/hq_nyc_10.log 10    144054  144057 01:02:21 NO  NO  1     YES
/oracle/dbs/hq_nyc_11.log 11    144057  144060 01:02:26 NO  NO  1  CURRENT
/oracle/dbs/hq_nyc_12.log 12    144060  144089 01:02:30 NO  NO  1  CURRENT
/oracle/dbs/hq_nyc_13.log 13    144089  144147 01:02:41 NO  NO  1       NO

BEGおよびEND列のYESエントリは、LogMinerディクショナリのビルドがログ・ファイル順序番号5で開始したことを示しています。最新のアーカイブREDOログ・ファイルは順序番号13で、01:02:41にロジカル・スタンバイ・データベースが受信しました。APPLIED列は、SQL ApplyがすべてのREDOをSCN 144057より前に適用したことを示しています。トランザクションが複数のアーカイブ・ログにまたがることがあるため、複数のアーカイブ・ログ・ファイルのAPPLIED列に、CURRENT値が現れることがあります。

10.3.3 V$DATAGUARD_STATSビュー

このビューには、ロジカル・スタンバイ・データベースのフェイルオーバー特性に関連する次のような情報が表示されます。

- フェイルオーバー時間(apply finish time)

- ロジカル・スタンバイ・データベース内のコミット済データの最新性(apply lag)

- 障害時の潜在的なデータ損失(transport lag)

次に例を示します。

SQL> COL NAME FORMAT A20
SQL> COL VALUE FORMAT A12
SQL> COL UNIT FORMAT A30
SQL> SELECT NAME, VALUE, UNIT FROM V$DATAGUARD_STATS;

NAME                 VALUE        UNIT
-------------------- ------------ ------------------------------
apply finish time    +00 00:00:00 day(2) to second(1) interval
apply lag            +00 00:00:00 day(2) to second(0) interval
transport lag        +00 00:00:00 day(2) to second(0) interval

この出力は、プライマリ・データベースから生成されたすべてのREDOを受信および適用したロジカル・スタンバイ・データベースからの出力です。

10.3.4 V$LOGSTDBY_PROCESSビュー

このビューには、次のように、SQL Apply関連の各種プロセスの現在の状態に関する情報が表示されます。

- 識別情報(sid | serial# | spid)

- SQL Applyプロセス: COORDINATOR、READER、BUILDER、PREPARER、ANALYZERまたはAPPLIER(type)

- プロセスの現行のアクティビティのステータス(status_code | status)

- このプロセスで処理された最上位のREDOレコード(high_scn)

次に例を示します。

SQL> COLUMN SERIAL# FORMAT 9999
SQL> COLUMN SID FORMAT 9999
SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS;

SID   SERIAL#   SPID         TYPE            HIGH_SCN
----- -------   ----------- ---------------- ----------
48        6    11074        COORDINATOR     7178242899
56       56    10858        READER          7178243497
46        1    10860        BUILDER         7178242901
45        1    10862        PREPARER        7178243295
37        1    10864        ANALYZER        7178242900
36        1    10866        APPLIER         7178239467
35        3    10868        APPLIER         7178239463
34        7    10870        APPLIER         7178239461
33        1    10872        APPLIER         7178239472

9 rows selected.

HIGH_SCN列は、READERプロセスが他のすべてのプロセスに先行することと、PREPARERおよびBUILDERプロセスが残りのプロセスに先行することを示しています。

SQL> COLUMN STATUS FORMAT A40
SQL> SELECT TYPE, STATUS_CODE, STATUS FROM V$LOGSTDBY_PROCESS;

TYPE             STATUS_CODE STATUS
---------------- ----------- -----------------------------------------
COORDINATOR            16117 ORA-16117: processing
READER                 16127 ORA-16127: stalled waiting for additional
transactions to be applied
BUILDER                16116 ORA-16116: no work available
PREPARER               16116 ORA-16117: processing
ANALYZER               16120 ORA-16120: dependencies being computed for
transaction at SCN 0x0001.abdb440a
APPLIER                16124 ORA-16124: transaction 1 13 1427 is waiting
on another transaction
APPLIER                16121 ORA-16121: applying transaction with commit
SCN 0x0001.abdb4390
APPLIER                16123 ORA-16123: transaction 1 23  1231 is waiting
for commit approval
APPLIER                16116 ORA-16116: no work available

出力は、実行中のSQL Applyのスナップショットを示しています。マイニング側では、READERプロセスはさらに読み取れるように追加のメモリーが使用可能になるまで待機中で、PREPARERプロセスはREDOレコードの処理中、BUILDERプロセスに使用可能な作業はありません。適用側では、COORDINATORはAPPLIERプロセスにさらにトランザクションを割当中で、ANALYZERはSCN 7178241034で依存性を計算中、APPLIERの1つは使用可能な作業がなく、2つにはまだ満たされていない未処理の依存性があります。

関連項目:
出力例は10.4.1項「SQL Applyの進捗の監視」を参照してください。

10.3.5 V$LOGSTDBY_PROGRESSビュー

このビューには、次のように、SQL Applyの進捗に関する詳細情報が表示されます。

- プライマリ・データベース上でコミットされた全トランザクションがロジカル・スタンバイ・データベースに適用されたSCNおよび時刻(applied_scn, applied_time)

- 再開時にSQL ApplyによるREDOレコードの読取りが開始されるSCNおよび時刻(restart_scn, restart_time)

- ロジカル・スタンバイ・データベースで受信された最新REDOレコードのSCNおよび時刻(latest_scn, latest_time)

- BUILDERプロセスにより処理された最新レコードのSCNおよび時刻(mining_scn, mining_time)

次に例を示します。

SQL> SELECT APPLIED_SCN, LATEST_SCN, MINING_SCN, RESTART_SCN -
> FROM V$LOGSTDBY_PROGRESS;

APPLIED_SCN  LATEST_SCN MINING_SCN RESTART_SCN
----------- ----------- ---------- -----------
7178240496  7178240507 7178240507  7178219805

この出力は次のことを示しています。

- SQL Applyにより、SCN 7178240496以前にコミットされた全トランザクションが適用されました。

- ロジカル・スタンバイ・データベースで受信された最新REDOレコードは、SCN 7178240507で生成されました。

- マイニング・コンポーネントにより、SCN 7178240507以前に生成された全REDOレコードが処理されました。

- SQL Applyがなんらかの理由で停止されて再開されると、SCN 7178219805以降に生成されたREDOレコードのマイニングが開始されます。

SQL> ALTER SESSION SET NLS_DATE_FORMAT='yy-mm-dd hh24:mi:ss';
Session altered

SQL> SELECT APPLIED_TIME, LATEST_TIME, MINING_TIME, RESTART_TIME -
> FROM V$LOGSTDBY_PROGRESS;

APPLIED_TIME      LATEST_TIME       MINING_TIME       RESTART_TIME
----------------- ----------------- ----------------- -----------------
05-05-12 10:38:21 05-05-12 10:41:53 05-05-12 10:41:21 05-05-12 10:09:30

この出力は次のことを示しています。

- SQL Applyにより、時刻05-05-12 10:38:21以前にコミットされた全トランザクションが適用されました(APPLIED_TIME)。

- 最後のREDOは、プライマリ・データベースで時刻05-05-12 10:41:53に生成されました(LATEST_TIME)。

- マイニング・エンジンにより、05-05-12 10:41:21以前に生成された全REDOレコードが処理されました(MINING_TIME)。

- SQL Applyの再開時には、05-05-12 10:09:30以後に生成されたREDOレコードのマイニングが開始されます。

関連項目:
出力例は10.4.1項「SQL Applyの進捗の監視」を参照してください。

10.3.6 V$LOGSTDBY_STATEビュー

このビューには、次のように、SQL Applyの現在の状態のシノプシスが表示されます。

- プライマリ・データベースのDBID(primary_dbid)

- SQL Applyに割り当てられているLogMinerセッションID(session_id)

- SQL Applyがリアルタイムで適用中かどうか(realtime_apply)

次に例を示します。

SQL> COLUMN REALTIME_APPLY FORMAT a15
SQL> COLUMN STATE FORMAT a16
SQL> SELECT * FROM V$LOGSTDBY_STATE;

PRIMARY_DBID SESSION_ID REALTIME_APPLY  STATE
------------ ---------- --------------- ----------------
1562626987          1 Y               APPLYING

この出力は、SQL Applyがリアルタイム適用モードで実行中で、現在はプライマリ・データベースから受信したREDOデータを適用中であり、プライマリ・データベースのDBIDが1562626987で、SQL Applyセッションに関連付けられているLogMinerセッションIDが1であることを示しています。

関連項目:
出力例は10.4.1項「SQL Applyの進捗の監視」を参照してください。

10.3.7 V$LOGSTDBY_STATSビュー

V$LOGSTDBY_STATSビューには、SQL Applyに関連する統計、現行の状態およびステータス情報が表示されます。SQL Applyが実行されていない場合、このビューからは1行も戻されません。このビューは、ロジカル・スタンバイ・データベースの下でのみ意味があります。

次に例を示します。

SQL> ALTER SESSION SET NLS_DATE_FORMAT='dd-mm-yyyy hh24:mi:ss';
Session altered

SQL> SELECT SUBSTR(name, 1, 40) AS NAME, SUBSTR(value,1,32) AS VALUE FROM V$LOGSTDBY_STATS;

NAME                                     VALUE
---------------------------------------- --------------------------------
logminer session id                      1
number of preparers                      1
number of appliers                       5
server processes in use                  9
maximum SGA for LCR cache (MB)           30
maximum events recorded                  10000
preserve commit order                    TRUE
transaction consistency                  FULL
record skipped errors                    Y
record skipped DDLs                      Y
record applied DDLs                      N
record unsupported operations            N
realtime apply                           Y
apply delay (minutes)                    0
coordinator state                        APPLYING
coordinator startup time                 19-06-2007 09:55:47
coordinator uptime (seconds)             3593
txns received from logminer              56
txns assigned to apply                   23
txns applied                             22
txns discarded during restart            33
large txns waiting to be assigned        2
rolled back txns mined                   4
DDL txns mined                           40
CTAS txns mined                          0
bytes of redo mined                      60164040
bytes paged out                          0
pageout time (seconds)                   0
bytes checkpointed                       4845
checkpoint time (seconds)                0
system idle time (seconds)               2921
standby redo logs mined                  0
archived logs mined                      5
gap fetched logs mined                   0
standby redo log reuse detected          1
logfile open failures                    0
current logfile wait (seconds)           0
total logfile wait (seconds)             2910
thread enable mined                      0
thread disable mined                     0
.
40 rows selected.

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

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

- SQL Applyの進捗の監視

- ログ・ファイルの自動削除

10.4.1 SQL Applyの進捗の監視

SQL Applyには、SQL Applyの初期化、ディクショナリ・ログの待機、LogMinerディクショナリのロード、(REDOデータの)適用、アーカイブのギャップ解消待ち、およびアイドルという6つの進捗状態があります。図10-2はこれらの状態のフローを示しています。

図10-2 SQL Apply処理中の進捗状態

次の各項では、それぞれの状態を詳細に説明します。

初期化中状態

ALTER DATABASE START LOGICAL STANDBY APPLY文を発行してSQL Applyを開始すると、初期化中状態になります。

SQL Applyの現在の状態を判断するには、V$LOGSTDBY_STATEビューを問い合せます。次に例を示します。

SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;

SESSION_ID    STATE
----------    -------------
1             INITIALIZING

SESSION_ID列は、SQL Applyにより作成された永続LogMinerセッションを示します。このセッションで、プライマリ・データベースで生成されたアーカイブREDOログ・ファイルがマイニングされます。

ディクショナリ・ログ待機中

SQL Applyは、初回の開始時に、REDOログ・ファイルで取得されたLogMinerディクショナリをロードする必要があります。SQL Applyは、LogMinerディクショナリのロードに必要なREDOデータをすべて受信するまで、WAITING FOR DICTIONARY LOGS状態にとどまります。

ディクショナリ・ロード中状態

ディクショナリ・ロード中状態は、しばらく継続する場合があります。大規模データベースでLogMinerディクショナリをロードするには、長時間かかることがあります。V$LOGSTDBY_STATEビューを問い合せると、ディクショナリのロード中は次の出力が戻されます。

SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;

SESSION_ID    STATE
----------    ------------------
1             LOADING DICTIONARY

LogMinerディクショナリが完全にロードされるまでに起動されるのは、COORDINATORプロセスとマイニング・プロセスのみです。したがって、この時点でV$LOGSTDBY_PROCESSを問い合せると、APPLIERプロセスは表示されません。次に例を示します。

SQL> SELECT SID, SERIAL#, SPID, TYPE FROM V$LOGSTDBY_PROCESS;

SID     SERIAL#     SPID       TYPE
------  ---------   ---------  ---------------------
47      3           11438      COORDINATOR
50      7           11334      READER
45      1           11336      BUILDER
44      2           11338      PREPARER
43      2           11340      PREPARER

V$LOGMNR_DICTIONARY_LOADビューを問い合せると、ディクショナリ・ロードの進捗に関する詳細情報を取得できます。ディクショナリ・ロードは、次の3つのフェーズで発生します。

1. LogMinerディクショナリのロードに関連するREDO変更を収集するために、関連アーカイブREDOログ・ファイルまたはスタンバイREDOログ・ファイルがマイニングされます。

2. 変更が処理され、データベース内のステージング表にロードされます。

3. 一連のDDL文が発行されて、LogMinerディクショナリ表がロードされます。

次に例を示します。

SQL> SELECT PERCENT_DONE, COMMAND -
> FROM V$LOGMNR_DICTIONARY_LOAD -
> WHERE SESSION_ID = (SELECT SESSION_ID FROM V$LOGSTDBY_STATE);

PERCENT_DONE     COMMAND
-------------    -------------------------------
40               alter table SYSTEM.LOGMNR_CCOL$ exchange partition
P101 with table SYS.LOGMNRLT_101_CCOL$ excluding
indexes without validation

PERCENT_DONEまたはCOMMAND列が長時間変化しない場合は、V$SESSION_LONGOPSビューを問い合せ、問題のDDLトランザクションの進捗を監視してください。

適用中状態

この状態では、SQL ApplyはLogMinerディクショナリの初期スナップショットを正常にロードしており、現在はロジカル・スタンバイ・データベースにREDOデータを適用中です。

SQL Applyの進捗の詳細情報を確認するには、次のようにV$LOGSTDBY_PROGRESSビューを問い合せます。

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS';
SQL> SELECT APPLIED_TIME, APPLIED_SCN, MINING_TIME, MINING_SCN -
> FROM V$LOGSTDBY_PROGRESS;

APPLIED_TIME            APPLIED_SCN   MINING_TIME           MINING_SCN
--------------------    -----------   --------------------  -----------
10-JAN-2005 12:00:05    346791023     10-JAN-2005 12:10:05  3468810134

プライマリ・データベース上でAPPLIED_SCN(またはAPPLIED_TIME)以前に表示されるコミット済トランザクションは、すべてロジカル・スタンバイ・データベースに適用されています。マイニング・エンジンは、プライマリ・データベースでMINING_SCN(およびMINING_TIME)以前に生成されたREDOレコードをすべて処理しています。安定状態では、MINING_SCN(およびMINING_TIME)は常にAPPLIED_SCN(およびAPPLIED_TIME)よりも前の値を示します。

ギャップ待機中状態

この状態が発生するのは、SQL Applyが使用可能な全REDOレコードのマイニングと適用を完了し、RFSプロセスによる新規ログ・ファイル(または欠落しているログ・ファイル)のアーカイブを待機している場合です。

SQL> SELECT STATUS FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'READER';

STATUS
------------------------------------------------------------------------
ORA-16240: waiting for log file (thread# 1, sequence# 99)

アイドル状態

SQL Applyは、プライマリ・データベースで生成されたREDOをすべて適用し終わると、この状態になります。

10.4.2 ログ・ファイルの自動削除

外部アーカイブ・ログには、プライマリ・データベースから送信されたREDOが含まれています。外部アーカイブ・ログの格納には次の2つの方法があります。

- 高速リカバリ領域に格納

- 高速リカバリ領域外のディレクトリに格納

高速リカバリ領域内に格納される外部アーカイブ・ログは、必ずSQL Applyによって管理されます。ログに含まれるすべてのREDOレコードは、ロジカル・スタンバイ・データベースでの適用後、DB_FLASHBACK_RETENTION_TARGETパラメータで指定された期間(DB_FLASHBACK_RETENTION_TARGETが指定されていない場合は1440分間)保持されます。高速リカバリ領域内に格納されている外部アーカイブ・ログの自動管理は上書きできません。

高速リカバリ領域内に格納されない外部アーカイブ・ログは、デフォルトではSQL Applyによって管理されます。自動管理下では、高速リカバリ領域内に格納されない外部アーカイブ・ログは、ログに含まれるすべてのREDOレコードがロジカル・スタンバイ・データベースで適用された後、LOG_AUTO_DEL_RETENTION_TARGETパラメータで指定された期間保持されます。高速リカバリ領域内に格納されない外部アーカイブ・ログの自動管理は、次のPL/SQLプロシージャを実行すると上書きできます。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');

注意:
DBMS_LOGTSDBY.APPLY_SETプロシージャを使用してこのパラメータを設定します。LOG_AUTO_DEL_RETENTION_TARGETを明示的に指定しなかった場合、DB_FLASHBACK_RETENTION_TARGETがロジカル・スタンバイ・データベースにデフォルト設定され、DB_FLASHBACK_RETENTION_TARGETが設定されていない場合は、デフォルトの1440分に設定されます。

デフォルトの自動ログ削除機能を上書きする場合は、定期的に次の手順を実行してSQL Applyで不要になったアーカイブREDOログ・ファイルを識別し、削除します。

1. 不要になったメタデータのロジカル・スタンバイ・セッションを消去するには、次のPL/SQL文を入力します。

SQL> EXECUTE DBMS_LOGSTDBY.PURGE_SESSION;

この文では、不要になったアーカイブREDOログ・ファイルを表示するDBA_LOGMNR_PURGED_LOGビューも更新されます。

2. DBA_LOGMNR_PURGED_LOGビューを問い合せて、削除できるアーカイブREDOログ・ファイルのリストを表示します。

SQL> SELECT * FROM DBA_LOGMNR_PURGED_LOG;

FILE_NAME
------------------------------------
/boston/arc_dest/arc_1_40_509538672.log
/boston/arc_dest/arc_1_41_509538672.log
/boston/arc_dest/arc_1_42_509538672.log
/boston/arc_dest/arc_1_43_509538672.log
/boston/arc_dest/arc_1_44_509538672.log
/boston/arc_dest/arc_1_45_509538672.log
/boston/arc_dest/arc_1_46_509538672.log
/boston/arc_dest/arc_1_47_509538672.log

3. オペレーティング・システム固有のコマンドを使用して、問合せにより表示されたアーカイブREDOログ・ファイルを削除します。

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

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

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

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

- DDL文のスキップ・ハンドラの設定

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

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

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

10.5.1 DBA_LOGSTDBY_EVENTSビューでのイベントのロギングのカスタマイズ

DBA_LOGSTDBY_EVENTSビューは、SQL Applyの下で発生する重要な最新イベントを含む循環型ログとみなすことができます。デフォルトでは、最新の10,000イベントがイベント・ビューに記録されます。ログに記録されるイベント数は、DBMS_LOGSTDBY.APPLY_SETプロシージャを起動して変更できます。たとえば、最新の100,000イベントを確実に記録するには、次の文を発行できます。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('MAX_EVENTS_RECORDED', '100000');

SQL Applyの停止原因となったエラーは、SYSTEM表領域に十分な領域があるかぎり、必ずDBA_LOGSTDBY_EVENTSビューに記録されます。これらのイベントは常にアラート・ファイルにも格納され、テキストにはLOGSTDBYというキーワードが含まれます。このビューを問い合せるときは、EVENT_TIME、COMMIT_SCN、CURRENT_SCNの順に列を選択してください。この順序によって、停止障害がビューの最後に表示されます。

次の例では、ビューに記録されるイベントを指定するDBMS_LOGSTDBYサブプログラムを示します。

例1   DDL文が適用されたかどうかを判断する

たとえば、適用済DDLトランザクションをDBA_LOGSTDBY_EVENTSビューに記録するには、次の文を発行します。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('RECORD_APPLIED_DDL', 'TRUE');

例2   サポートされない操作がないかDBA_LOGSTDBY_EVENTSビューをチェックする

プライマリ・データベースで実行されていて、ロジカル・スタンバイ・データベースでサポートされないトランザクションに関する情報を取得するには、次の文を発行します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;SQL> EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

次に、サポートされない操作がないかDBA_LOGSTDBY_EVENTSビューをチェックします。通常、サポートされない表に対する操作は、SQL Applyによって警告なしで無視されます。しかし、ローリング・アップグレード中(スタンバイ・データベースが上位バージョンであり、下位バージョンのプライマリ・データベースによって生成されたREDOをマイニングしているとき)に、サポートされない操作をプライマリ・データベースに対して実行した場合、ロジカル・スタンバイ・データベースにスイッチオーバーされない可能性があります。Data Guardは、表ごとに1つ以上のサポートされない操作をDBA_LOGSTDBY_EVENTSビューに記録します。ローリング・アップグレードに関する詳細は、第12章「SQL Applyを使用したOracle Databaseのアップグレード」を参照してください。

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

デフォルトでは、プライマリ・データベース内でサポートされる表は、すべてロジカル・スタンバイ・データベースで複製されます。このデフォルト動作は、特定の表に対する変更の適用をスキップするルールを指定することで変更できます。たとえば、HR.EMPLOYEES表に対する変更を省略するには、特定の表に対するDML変更とDDL変更の適用を防止するルールを指定できます。次に例を示します。

1. SQL Applyを停止します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

2. SKIPルールを登録します。

SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'DML', schema_name => 'HR', -
> object_name => 'EMPLOYEES');

SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'SCHEMA_DDL', schema_name => 'HR', -
> object_name => 'EMPLOYEES');

3. SQL Applyを開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

10.5.3 DDL文のスキップ・ハンドラの設定

特定のDDL文をインターセプトして元のDDL文を別のDDL文で置き換えるプロシージャを作成できます。たとえば、ロジカル・スタンバイ・データベース内のファイル・システムの編成がプライマリ・データベースとは異なる場合、DBMS_LOGSTDBY.SKIPプロシージャを作成し、ファイルを指定してDDLトランザクションを透過的に処理できます。

次のプロシージャでは、ファイル指定文字列に特定のネーミング規則を使用するかぎり、プライマリ・データベースとスタンバイ・データベース間で異なるファイル・システム編成を処理できます。

1. 次のように、表領域のDDLトランザクションを処理するスキップ・プロシージャを作成します。

CREATE OR REPLACE PROCEDURE SYS.HANDLE_TBS_DDL (
OLD_STMT  IN  VARCHAR2,
STMT_TYP  IN  VARCHAR2,
SCHEMA    IN  VARCHAR2,
NAME      IN  VARCHAR2,
XIDUSN    IN  NUMBER,
XIDSLT    IN  NUMBER,
XIDSQN    IN  NUMBER,
ACTION    OUT NUMBER,
NEW_STMT  OUT VARCHAR2
) AS
BEGIN

-- All primary file specification that contains a directory
-- /usr/orcl/primary/dbs
-- should go to /usr/orcl/stdby directory specification

NEW_STMT := REPLACE(OLD_STMT,
'/usr/orcl/primary/dbs',
'/usr/orcl/stdby');

ACTION := DBMS_LOGSTDBY.SKIP_ACTION_REPLACE;

EXCEPTION
WHEN OTHERS THEN
ACTION := DBMS_LOGSTDBY.SKIP_ACTION_ERROR;
NEW_STMT := NULL;
END HANDLE_TBS_DDL;

2. SQL Applyを停止します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

3. スキップ・プロシージャをSQL Applyに登録します。

SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'TABLESPACE', -
> proc_name => 'sys.handle_tbs_ddl');

4. SQL Applyを開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

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

ロジカル・スタンバイ・データベースは、SQL文が適用されている間でもレポート・アクティビティに使用できます。データベース・ガードはロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスを制御し、ALTER SESSION DISABLE GUARD文はデータベース・ガードをバイパスしてロジカル・スタンバイ・データベース内の表に対する変更を可能にするために使用します。

注意:
ロジカル・スタンバイ・データベースを使用して、独自に他の表を作成すると同時にプライマリ・データベースからレプリケートされるデータを処理する他のアプリケーションをホスト管理するには、データベース・ガードをSTANDBYに設定する必要があります。このようなアプリケーションがシームレスに動作するには、PRESERVE_COMMIT_ORDERをTRUE(SQL Applyのデフォルト設定)に設定して実行する必要があります。(DBMS_LOGSTDBY PL/SQLパッケージのPRESERVE_COMMIT_ORDERパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。)
次のSQL文を発行して、データベース・ガードをSTANDBYに設定します。

SQL> ALTER DATABASE GUARD STANDBY;

このガード設定では、プライマリ・データベースからレプリケートされる表は、ユーザーによる変更から保護されますが、スタンバイ・データベースに作成された表は、ロジカル・スタンバイで実行されているアプリケーションで変更できます。

デフォルトでは、ロジカル・スタンバイ・データベースはデータベース・ガードがALL(最も限定的な設定)に設定されている状態で作動し、ユーザーはデータベースに対して変更を実行できません。データベース・ガードを無視して、ロジカル・スタンバイ・データベースを変更可能にするには、ALTER SESSION DISABLE GUARD文を実行します。権限を付与されているユーザーは、この文を発行して、現行のセッションでデータベース・ガードをオフにできます。

次の各項で、例を示します。これらの例では、データベース・ガードがALLまたはSTANDBYに設定されていると仮定しています。

10.5.4.1 ロジカル・スタンバイ・データベースでのDDLの実行

この項では、SQL Applyを介してメンテナンスされている表に制約を追加する方法を説明します。

デフォルトでは、SYS権限を持つアカウントのみがデータベースを変更でき、データベース・ガードはALLまたはSTANDBYに設定されています。SYSTEMまたは権限を付与されている別のアカウントでログインした場合、最初はセッションに対するデータベース・ガードをバイパスしていないので、ロジカル・スタンバイ・データベースではDDL文を発行できません。

次の例は、SQL Applyを停止し、データベース・ガードをバイパスしてロジカル・スタンバイ・データベースでSQL文を実行した後、データベース・ガードを再び使用可能にする方法を示しています。この例では、部分一致の問合せを高速化するために、soundex索引がSCOTT.EMPのsurname列に追加されます。soundex索引をプライマリ・サーバーで保持すると、非常に高コストになる場合があります。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.

SQL> ALTER SESSION DISABLE GUARD;
PL/SQL procedure successfully completed.

SQL> CREATE INDEX EMP_SOUNDEX ON SCOTT.EMP(SOUNDEX(ENAME));
Table altered.

SQL> ALTER SESSION ENABLE GUARD;
PL/SQL procedure successfully completed.

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.

SQL> SELECT ENAME,MGR FROM SCOTT.EMP WHERE SOUNDEX(ENAME) = SOUNDEX('CLARKE');

ENAME            MGR
----------       ----------
CLARK             7839

オラクル社では、データベース・ガードのバイパスが使用可能になっている間は、SQL Applyにより保守される表に対してDML操作を実行しないことをお薦めします。DML操作を実行すると、プライマリ・データベースとスタンバイ・データベース間で違いが生じ、ロジカル・スタンバイ・データベースをメンテナンスできないようになります。

10.5.4.2 SQL Applyでメンテナンスされていない表の変更

場合によっては、レポート・アプリケーションを使用してサマリー結果を収集し、一時的に保存し、レポートの実行回数を追跡する必要があります。この種のアプリケーションの主な目的はレポート・アクティビティですが、アプリケーションはロジカル・スタンバイ・データベースに対してDML(挿入、更新、および削除)操作を実行しなければならない場合があります。表の作成または削除が必要になることもあります。

データがSQL Applyを介してメンテナンスされていない場合は、レポート生成操作でデータを変更できるように、データベース・ガードを設定できます。次の設定を行う必要があります。

- DBMS_LOGSTDBY.SKIPプロシージャを実行して、アプリケーションによるデータの書込みを可能にする、ロジカル・スタンバイ・データベース上の表のセットを指定します。スキップされた表は、SQL Applyでメンテナンスされません。

- スタンバイ表のみを保護するようにデータベース・ガードを設定します。

次の例では、レポートによって書込みが行われる表がプライマリ・データベース上にあると仮定しています。

この例では、SQL Applyを停止し、表をスキップした後、SQL Applyを再開しています。この操作によって、レポート生成アプリケーションは、HRのTESTEMP%に書込みができるようになります。スキップされた表は、SQL Applyでメンテナンスされません。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.

SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL',-
schema_name => 'HR', -
object_name => 'TESTEMP%');
PL/SQL procedure successfully completed.

SQL> EXECUTE DBMS_LOGSTDBY.SKIP('DML','HR','TESTEMP%');
PL/SQL procedure successfully completed.

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.

SQL Applyでは、開始後に、新しく指定されてスキップ・ルールに追加された表について、スタンバイ・データベースのメタデータを更新する必要があります。SQL Applyによりメタデータが更新される前に、新しくスキップされる表を変更しようとすると失敗します。追加したばかりのSKIPルールがSQL Applyで正常に考慮されたかどうかは、次の問合せを発行すると確認できます。

SQL> SELECT VALUE FROM SYSTEM.LOGSTDBY$PARAMETERS WHERE NAME = 'GUARD_STANDBY';

VALUE
---------------
Ready

VALUE列にReadyと表示される場合、SQL Applyではスキップされる表の関連メタデータがすべて正常に更新されており、その表を変更しても安全です。

関連項目:
C.12項「ロジカル・スタンバイ・データベースがサポートしているDDL文」、および『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_LOGSTDBYパッケージ

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

リカバリ不可能な操作が発生した場合は、一般にDBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャを使用して表を作成しなおします。また、このプロシージャを使用して、以前はスキップしていた表に対してSQL Applyを使用可能にすることもできます。

表を作成する前に、4.1.2項「プライマリ・データベース内の表の行が一意に識別できることの確認」に記載されている要件を満たす必要があります。その後、次の手順に従って表HR.EMPLOYEESを再作成し、SQL Applyを再開できます。この手順は、プライマリ・データベースにアクセスするデータベース・リンクBOSTONが定義済であることを前提としています。

次のリストは、表を再作成し、その表に対してSQL Applyを再開する方法を示しています。

1. SQL Applyを停止します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

2. DBA_LOGSTDBY_SKIPビューを問い合せ、問題の表で操作がスキップされていないことを確認します。

SQL> SELECT * FROM DBA_LOGSTDBY_SKIP;

ERROR  STATEMENT_OPT        OWNER          NAME                PROC
-----  -------------------  -------------  ----------------    -----
N      SCHEMA_DDL           HR             EMPLOYEES
N      DML                  HR             EMPLOYEES
N      SCHEMA_DDL           OE             TEST_ORDER
N      DML                  OE             TEST_ORDER

ロジカル・スタンバイ・データベース上で再作成する表には、すでにスキップ・ルールが関連付けられているため、最初にそのルールを削除する必要があります。そのためには、DBMS_LOGSTDBY.UNSKIPプロシージャをコールします。次に例を示します。

SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'DML', -
> schema_name => 'HR', -
> object_name => 'EMPLOYEES');

SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'SCHEMA_DDL', -
> schema_name => 'HR', -
> object_name => 'EMPLOYEES');

3. DBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャを使用し、ロジカル・スタンバイ・データベースの全データを使用して表HR.EMPLOYEESを再作成します。次に例を示します。

SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE(schema_name => 'HR', -
> table_name => 'EMPLOYEES', -
> dblink => 'BOSTON');

4. SQL Applyを開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

関連項目:
DBMS_LOGSTDBY.UNSKIPおよびDBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

新規にインスタンス化された表とデータベースの残りの部分にまたがってビューの一貫性が得られるように、SQL Applyがプライマリ・データベースと一致するまで待機してから、この表を問い合せます。手順は次のとおりです。

1. プライマリ・データベースで、V$DATABASEビューを問い合せて現在のSCNを判別します。

SQL> SELECT CURRENT_SCN FROM V$DATABASE@BOSTON;

CURRENT_SCN
---------------------
345162788

2. 前の問合せで戻されたCURRENT_SCNより前のコミット済のトランザクションがすべて、SQL Applyにより適用されていることを確認します。

SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS;

APPLIED_SCN
--------------------------
345161345

この問合せで戻されたAPPLIED_SCNが最初の問合せで戻されたCURRENT_SCNよりも大きい場合は、新規に再作成された表を問い合せても安全です。

10.6 ロジカル・スタンバイ・データベースの下での特定のワークロードの管理

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

- プライマリ・データベースへのトランスポータブル表領域のインポート

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

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

- サポートされていない表のレプリケートでのトリガーの使用

- プライマリでのPoint-in-Timeリカバリの実行によるリカバリ

- ロジカル・スタンバイ・データベースでのOracle Streams取得プロセスの実行

10.6.1 プライマリ・データベースへのトランスポータブル表領域のインポート

表領域をプライマリ・データベースにインポートする手順は、次のとおりです。

1. ロジカル・スタンバイ・データベースを変更できるように、ガード設定を無効にします。

SQL> ALTER DATABASE GUARD STANDBY;

2. ロジカル・スタンバイ・データベースで表領域をインポートします。

3. データベース・ガード設定を有効にします。

SQL> ALTER DATABASE GUARD ALL;

4. プライマリ・データベースで表領域をインポートします。

10.6.2 マテリアライズド・ビューの使用

ロジカル・スタンバイでは、マテリアライズド・ビューに関連した次のDDL文を自動的にスキップします。

- CREATE、ALTERまたはDROP MATERIALIZED VIEW

- CREATE、ALTERまたはDROP MATERIALIZED VIEW LOG

ロジカル・スタンバイ・データベースの作成後にプライマリ・データベースで作成、変更または削除された新規マテリアライズド・ビューは、ロジカル・スタンバイ・データベースには反映されません。ただし、ロジカル・スタンバイ・データベースの作成前にプライマリ・データベースで作成されたマテリアライズド・ビューは、ロジカル・スタンバイ・データベースに存在します。

ロジカル・スタンバイでは、他の種類の補助データ構造に加えて、ロジカル・スタンバイ・データベースでの新規マテリアライズド・ビューのローカルな作成およびメンテナンスをサポートしています。たとえば、オンライン・トランザクション処理(OLTP)システムでは、高度に正規化された表を更新パフォーマンスに頻繁に使用しますが、これらの表により、複雑な意思決定支援の問合せに対するレスポンス時間が長くなることがあります。ロジカル・スタンバイ・データベースでより効率的な問合せが作成できるように、次のようにして、レプリケートされたデータを非正規化するマテリアライズド・ビューを作成できます(これらの文を発行する前にユーザーSYSとして接続してください)。

SQL> ALTER SESSION DISABLE GUARD;

SQL> CREATE MATERIALIZED VIEW LOG ON SCOTT.EMP -
>  WITH ROWID (EMPNO, ENAME, MGR, DEPTNO) INCLUDING NEW VALUES;

SQL> CREATE MATERIALIZED VIEW LOG ON SCOTT.DEPT -
>  WITH ROWID (DEPTNO, DNAME) INCLUDING NEW VALUES;

SQL> CREATE MATERIALIZED VIEW SCOTT.MANAGED_BY -
>  REFRESH ON DEMAND -
>  ENABLE QUERY REWRITE -
>  AS SELECT  E.ENAME, M.ENAME AS MANAGER -
>  FROM SCOTT.EMP E, SCOTT.EMP M WHERE E.MGR=M.EMPNO;

SQL> CREATE MATERIALIZED VIEW SCOTT.IN_DEPT -
>  REFRESH FAST ON COMMIT -
>  ENABLE QUERY REWRITE -
>  AS SELECT E.ROWID AS ERID, D.ROWID AS DRID, E.ENAME, D.DNAME -
>  FROM SCOTT.EMP E, SCOTT.DEPT D WHERE E.DEPTNO=D.DEPTNO;

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

- トランザクションのコミットが発生すると、ロジカル・スタンバイ・データベースのON-COMMITマテリアライズド・ビューが自動的にリフレッシュされます。

- ON-DEMANDマテリアライズド・ビューは自動的にリフレッシュされません。リフレッシュするには、DBMS_MVIEW.REFRESHプロシージャを実行する必要があります。

たとえば、次のコマンドを発行すると、前の例で作成されたON-DEMANDマテリアライズド・ビューがリフレッシュされます。

SQL> ALTER SESSION DISABLE GUARD;

SQL> EXECUTE DBMS_MVIEW.REFRESH (LIST => 'SCOTT.MANAGED_BY', METHOD => 'C');

DBMS_SCHEDULERジョブを使用して定期的にオンデマンドでマテリアライズされたビューをリフレッシュする場合は、データベース・ガードをSTANDBYに設定しておく必要があります。(ALTER SESSION DISABLE GUARD文をPL/SQLブロック内で使用しても、効果がありません。)

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

デフォルトでは、トリガーと制約はロジカル・スタンバイ・データベースで自動的に使用可能になり、処理されます。

SQL Applyでメンテナンスされる表にトリガーおよび制約がある場合:

- 制約: CHECK制約はプライマリ・データベースで評価されます。ロジカル・スタンバイ・データベースでの再評価は不要です。

- トリガー: プライマリ・データベースで実行されたトリガーの影響は、スタンバイ・データベースでログに記録され、適用されます。

SQL Applyでメンテナンスされない表にトリガーおよび制約がある場合:

- 制約は評価されます。

- トリガーは発行されます。

10.6.4 サポートされていない表のレプリケートでのトリガーの使用

表で作成されたDMLトリガーは、DBMS_DDL.SET_TRIGGER_FIRING_PROPERTYのfire_onceパラメータをTRUEにデフォルト設定します。トリガーはユーザー・プロセスが変更された場合にのみ起動されます。SQL Applyプロセス内では自動的に無効化されるため、SQL Applyプロセスが表を変更しても起動されません。SQL Applyプロセスが保持している表に変更を加えた際に、トリガーを起動する方法が2つあります。

- トリガーのfire_onceパラメータをFALSEに設定します。ユーザー・プロセスとSQL Applyプロセスのどちらにも対応して起動できるようになります。

- apply_server_onlyパラメータをTRUEに設定します。こうすると、トリガーはSQL Applyプロセスに対応してのみ起動し、ユーザー・プロセスに対応しては起動しません。

fire_once

apply_server_only

説明

TRUE

FALSE

DMLトリガーのデフォルトのプロパティ設定です。ユーザー・プロセスによって実表が変更された場合のみトリガーが起動します。

FALSE

FALSE

トリガーは、実表を変更するユーザー・プロセスとSQL Applyプロセスの両方に対応して起動します。DBMS_LOGSTDBY.IS_APPLY_SERVERファンクションを使用して2つのケースを区別することもできます。

TRUE/FALSE

TRUE

SQL Applyプロセスによって実表が変更された場合のみトリガーが起動します。ユーザー・プロセスが実表を変更した場合には、トリガーは起動しません。したがって、apply_server_onlyプロパティがトリガーのfire_onceパラメータをオーバーライドします。

単純なオブジェクト型の列のためにサポートされていない表をレプリケートするには、SQL Applyプロセスに対応して起動するトリガーを作成します(トリガーのfire_onceパラメータをFALSEに設定するか、トリガーのapply_server_onlyパラメータをTRUEに設定します)。通常のDMLトリガーをプライマリ・データベースで使用して、オブジェクト型を、サポート可能な表にフラット化できます。ロジカル・スタンバイのSQL Applyプロセスに対応して起動するトリガーによって、オブジェクト型が再作成され、サポートされない表がトランザクション方式で更新されます。

関連項目:

- DBMS_DDL.SET_TRIGGER_FIRING_PROPERTYプロシージャとDBMS_LOGSTDBY.IS_APPLY_SERVER関数の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

次の例では、トリガーを使用して簡単なオブジェクト型の表をレプリケートする方法を示します。この例では挿入の処理方法を示しています。同じ原理で更新および削除も行えます。ネストされた表とVARRAYも、ネストされたデータの正規化を行うループを追加すれば、この方法でレプリケートすることができます。

-- simple object type
create or replace type Person as object
(
FirstName    varchar2(50),
LastName     varchar2(50),
BirthDate    Date
)

-- unsupported object table
create table employees
(
IdNumber     varchar2(10) ,
Department   varchar2(50),
Info         Person
)

-- supported table populated via trigger
create table employees_transfer
(
t_IdNumber   varchar2(10),
t_Department varchar2(50),
t_FirstName  varchar2(50),
t_LastName   varchar2(50),
t_BirthDate  Date
)
--
-- create this trigger to flatten object table on the primary
-- this trigger will not fire on the standby
--
create or replace trigger flatten_employees
after insert on employees for each row
declare
begin
insert into employees_transfer
(t_IdNumber, t_Department, t_FirstName, t_LastName, t_BirthDate)
values
(:new.IdNumber, :new.Department,
:new.Info.FirstName,:new.Info.LastName, :new.Info.BirthDate);
end

--
-- Option#1 (Better Option: Create a trigger and
-- set its apply-server-only property to TRUE)
-- create this trigger at the logical standby database
-- to populate object table on the standby
-- this trigger only fires when apply replicates rows
-- to the standby
--
create or replace trigger reconstruct_employees_aso
after insert on employees_transfer for each row
begin

insert into employees (IdNumber, Department, Info)
values (:new.t_IdNumber, :new.t_Department,
Person(:new.t_FirstName, :new.t_LastName,  :new.t_BirthDate));

end

-- set this trigger to fire from the apply server
execute dbms_ddl.set_trigger_firing_property( -
trig_owner => 'scott', -
trig_name  => 'reconstruct_employees_aso',
property => dbms_ddl.apply_server_only,
setting => TRUE);

--
-- Option#2 (Create a trigger and set
--           its fire-once property to FALSE)
-- create this trigger at the logical standby database
-- to populate object table on the standby
-- this trigger will fire when apply replicates rows to -- the standby, but we will need to make sure we are
-- are executing inside a SQL Apply process by invoking
-- dbms_logstdby.is_apply_server function
--
create or replace trigger reconstruct_employees_nfo
after insert on employees_transfer for each row
begin
if dbms_logstdby.is_apply_server() then
insert into employees (IdNumber, Department, Info)
values (:new.t_IdNumber, :new.t_Department,
Person(:new.t_FirstName, :new.t_LastName,  :new.t_BirthDate));
end if;
end

-- set this trigger to fire from the apply server
execute dbms_ddl.set_trigger_firing_property( -
trig_owner => 'scott', -
trig_name  => 'reconstruct_employees_nfo',
property => dbms_ddl.fire_once,
setting => FALSE);

10.6.5 プライマリでのPoint-in-Timeリカバリの実行によるリカバリ

ロジカル・スタンバイ・データベースがREDOデータの新規ブランチを受信すると、SQL Applyではそれが自動的に使用されます。ロジカル・スタンバイ・データベースの場合、スタンバイ・データベースにより新規リセットログのSCNより後(REDOデータの新規ブランチの開始より後)のREDOデータが適用されていなければ、手動による介入は必要ありません。

次の表に、スタンバイ・データベースとプライマリ・データベースのブランチを再同期化する方法を示します。

スタンバイ・データベースの状態 . .

操作 . .

実行する手順 . .

新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用されていない場合。

SQL Applyは、自動的にREDOデータの新規ブランチを使用します。

手動による介入は必要ありません。SQL Applyは、自動的にスタンバイ・データベースをREDOデータの新規ブランチと再同期化します。

新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっている場合。

スタンバイ・データベースは、REDOデータの将来の新規ブランチでリカバリされます。

1. 13.3.2項「特定時点へのロジカル・スタンバイ・データベースのフラッシュバック」の手順に従って、ロジカル・スタンバイ・データベースをフラッシュバックします。

2. SQL Applyを再開し、新規リセットログ・ブランチへのREDOの適用を続行します。

SQL Applyは、自動的にスタンバイ・データベースを新規ブランチと再同期化します。

新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっていない場合。

指定のプライマリ・データベース・ブランチで、プライマリ・データベースとスタンバイの内容にずれが生じます。

第4章「ロジカル・スタンバイ・データベースの作成」の手順に従ってロジカル・スタンバイ・データベースを再作成します。

REDOデータの前のブランチの終わりからアーカイブREDOログ・ファイルが欠落している場合。

SQL Applyは欠落しているログ・ファイルが取得されるまで続行できません。

前のブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。

データベース・インカネーション、OPEN RESETLOGSによるリカバリ、フラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

10.6.6 ロジカル・スタンバイ・データベースでのOracle Streams取得プロセスの実行

Oracle Streams取得プロセスをロジカル・スタンバイ・データベースで実行すると、ロジカル・スタンバイ・データベースに存在するすべての表(ローカル表またはプライマリ・データベースからレプリケートされているメンテナンス対象の表)の変更を取得できます。メンテナンス対象の表の変更を取得するときは、Oracle Streams取得プロセスをプライマリ・データベースに対して実行する場合に比べると時間がかかります。時間が長くなるのは、ロジカル・スタンバイで実行しているとき、Oracle Streams取得プロセスは変更がプライマリからロジカル・スタンバイに転送され、SQL Applyによって適用されるのを待機する必要があるためです。ほとんどの場合、リアルタイム適用を実行していれば、数秒以上かかることはありません。

Oracle Streamsの取得プロセスは作成されたデータベースに関連付けられている点に注意することが重要です。データベースのロールは関係ありません。たとえば、Bostonという名前のプライマリ・データベース、およびLondonという名前のロジカル・スタンバイがあると仮定します。ロール・トランジション時に、Oracle Streamsの取得プロセスを1つのデータベースから、別なデータベースに移動することはできません。たとえばLondonがロジカル・スタンバイのときに、Oracle Streamsの取得プロセスを作成した場合、スイッチオーバーやフェイルオーバーなどのロール・トランジションによって、Londonがプライマリになったとしても、London上に残ります。ロール・トランジション後もOracle Streamsの取得プロセスを継続するためには、次のようなロール・トランジション・トリガーを書く必要があります。

create or replace trigger streams_aq_job_role_change1
after DB_ROLE_CHANGE on database
declare
cursor capture_aq_jobs is
select job_name, database_role
from dba_scheduler_job_roles
where job_name like 'AQ_JOB%';
u capture_aq_jobs%ROWTYPE;
my_db_role  varchar2(16);
begin

if (dbms_logstdby.db_is_logstdby() = 1) then my_db_role := 'LOGICAL STANDBY';
else my_db_role := 'PRIMARY';
end if;

open capture_aq_jobs;
loop
fetch capture_aq_jobs into u;
exit when capture_aq_jobs%NOTFOUND;

if (u.database_role != my_db_role) then
dbms_scheduler.set_attribute(u.job_name,
'database_role',
my_db_role);

end if;
end loop;
close capture_aq_jobs;

exception
when others then
begin
raise;
end;
end;

10.7 ロジカル・スタンバイ・データベースのチューニング

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

- 主キーRELY制約の作成

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

- プロセス数の調整

- LCRキャッシュ用メモリーの調整

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

10.7.1 主キーRELY制約の作成

プライマリ・データベースで、表に主キーまたは一意索引がなく、実際には一意である行がわかっている場合は、主キーのRELY制約を作成します。ロジカル・スタンバイ・データベースでは、主キーを構成する列に索引を作成します。次の問合せは、ロジカル・スタンバイ・データベースで行を一意に識別するために適用できる索引情報がない表のリストを生成します。次の表に索引を作成することによって、パフォーマンスが大幅に向上する可能性があります。

SQL> SELECT OWNER, TABLE_NAME FROM DBA_TABLES -
> WHERE OWNER NOT IN (SELECT OWNER FROM DBA_LOGSTDBY_SKIP -
> WHERE STATEMENT_OPT = 'INTERNAL SCHEMA') -
> MINUS -
> SELECT DISTINCT TABLE_OWNER, TABLE_NAME FROM DBA_INDEXES -
> WHERE INDEX_TYPE NOT LIKE ('FUNCTION-BASED%') -
> MINUS -
> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED;

プライマリ・データベースの表に主キーのRELY制約を追加する手順は、次のとおりです。

1. プライマリ・データベースで主キーのRELY制約を追加します。

SQL> ALTER TABLE HR.TEST_EMPLOYEES ADD PRIMARY KEY (EMPNO) RELY DISABLE;

これにより、HR.TEST_EMPLOYEES表の各行を一意に識別するために使用可能なEMPNO列が、その表に対して実行される更新の一部としてサプリメンタル・ロギングで確実に記録されるようになります。

HR.TEST_EMPLOYEES表には、ロジカル・スタンバイ・データベースで指定された一意索引がまだないことに注意してください。このため、UPDATE文ではロジカル・スタンバイ・データベースに対して全表スキャンが実行される場合があります。ロジカル・スタンバイ・データベース上のEMPNO列に一意の索引を追加することで、これを修正できます。RELY制約の詳細は、4.1.2項「プライマリ・データベース内の表の行が一意に識別できることを確認する」、および『Oracle Database SQL言語リファレンス』を参照してください。

残りの手順をロジカル・スタンバイ・データベースで実行します。

2. SQL Applyを停止します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

3. ロジカル・スタンバイ・データベースでメンテナンスされる表を変更できるように、ガードを無効にします。

SQL> ALTER SESSION DISABLE GUARD;

4. EMPNO列に一意索引を追加します。

SQL> CREATE UNIQUE INDEX UI_TEST_EMP ON HR.TEST_EMPLOYEES (EMPNO);

5. ガードを有効にします。

SQL> ALTER SESSION ENABLE GUARD;

6. SQL Applyを開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

10.7.2 コストベース・オプティマイザの統計の収集

コストベース・オプティマイザ(CBO)で最適の問合せ実行パスを判別するために使用されるため、スタンバイ・データベースで統計を収集する必要があります。以前の統計情報が正確でなくなるような変更をスキーマ・オブジェクトのデータまたは構造に対して実行した場合は、その後に新しい統計を収集してください。たとえば、多数の行を表に挿入または削除した後は、行数に関する新しい統計を収集します。

プライマリ・データベースでのDMLおよびDDL操作はワークロードの機能として実行されるため、統計はスタンバイ・データベースで収集してください。スタンバイ・データベースがプライマリ・データベースと論理的に等しい場合、SQL Applyではワークロードを異なる方法で実行する場合があります。そのため、ロジカル・スタンバイ・データベースでSTATSパッケージおよびV$SYSSTATビューを使用すると、リソースおよび表スキャンを最も多く使用している表を判断する際に役立ちます。

関連項目:

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

- RELY制約の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

10.7.3 プロセス数の調整

次の各項で、次の内容を説明します。

- APPLIERプロセス数の調整

- PREPARERプロセス数の調整

SQL Applyに割り当てられるプロセス数を制御するために変更できるパラメータには、MAX_SERVERS、APPLY_SERVERSおよびPREPARE_SERVERSの3つがあります。常に、次の関係に該当する必要があります。

- APPLY_SERVERS + PREPARE_SERVERS = MAX_SERVERS - 3
これは、SQL Applyが常にREADER、BUILDER、ANALYZERの各ロールに対して1つずつプロセスを割り当てるためです。

- デフォルトでは、MAX_SERVERSは9に、PREPARE_SERVERSは1に、APPLY_SERVERSは5に設定されます。

- DBMS_LOGSTDBY.APPLY_SETプロシージャを使用してMAX_SERVERSパラメータのみを変更し、SQL Applyでサーバー・プロセスを準備プロセスと適用プロセスの間に適当に分散できようにすることをお薦めします。

- SQL Applyではプロセス割当てアルゴリズムを使用して、MAX_SERVERで指定されるように、SQL Applyに割り当てられる20サーバー・プロセスごとに1つのPREPARE_SERVERを割り当て、PREPARE_SERVERS の数を5に制限します。そのため、MAX_SERVERSを1から20の任意の値に設定すると、SQL ApplyはPREPARERとして機能するようにサーバー・プロセスを1つ割り当て、残りのプロセスをAPPLIERとして割り当てて前述の関係を満たします。同様に、MAX_SERVERSを21から40の値に設定すると、SQL ApplyはPREPARERとして機能するようにサーバー・プロセスを2つ割り当て、残りをAPPLIERとして割り当てて前述の関係を満たします。この内部プロセス割当てアルゴリズムは、前述の関係を満たしているならば、APPLY_SERVERSおよびPREPARE_SERVERSを直接設定することで上書きできます。

10.7.3.1 APPLIERプロセス数の調整

APPLIERプロセスの数を調整することでスループットを改善できるかどうかを判断する手順は、次のとおりです。

1. 次の問合せを発行して、APPLIERプロセスがビジーかどうかを判断します。

SQL> SELECT COUNT(*) AS IDLE_APPLIER -
> FROM V$LOGSTDBY_PROCESS -
> WHERE TYPE = 'APPLIER' and status_code = 16116;

IDLE_APPLIER
-------------------------
0

2. アイドル状態のAPPLIERプロセスがないことを確認した後、次の問合せを発行し、APPLIERの数を調整した場合に追加分のAPPLIERプロセスに十分な作業が使用可能かどうかを確認します。

SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'txns applied' OR NAME = 'distinct txns in queue';

この2つの統計では、APPLIERプロセスによる適用準備が完了しているトランザクション数とすでに適用済のトランザクション数の累計が維持されます。

この数値(distinct txns in queue - txns applied)が使用可能なAPPLIERプロセス数の2倍を超えている場合は、APPLIERプロセス数を増やすことでスループットを改善できます。

注意:
この数値は準備作業の概算です。ワークロードによっては、準備が完了したトランザクション間の依存性が、使用可能な追加のAPPLIERプロセスによる適用の妨げになる場合があります。たとえば、適用準備の完了しているトランザクションの大多数がDDLトランザクションの場合は、さらにAPPLIERプロセスを追加してもスループットは改善されません。

APPLIERプロセス数をデフォルト値の5から20に調整し、PREPARERプロセス数は1のままとします。これは、次の等式を満たす必要があるためです。

APPLY_SERVERS + PREPARE_SERVERS = MAX_SERVERS - 3

まずMAX_SERVERSを24に設定する必要があります。こうすると、APPLY_SERVERSの数を次のように20に設定できます。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS', 24);
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS', 20);

10.7.3.2 PREPARERプロセス数の調整

PREPARERプロセスの数の調整が必要になることは、ほとんどありません。PREPARERプロセスの数を増やす前に、次の条件に該当しているかどうかを確認してください。

- すべてのPREPARERプロセスがビジーである。

- 適用準備が完了しているトランザクションの数が、使用可能なAPPLIERプロセスの数よりも少ない。

- アイドル状態のAPPLIERプロセスがある。

前述の条件に該当しているかどうかを判断する手順は、次のとおりです。

1. すべてのPREPARERプロセスがビジーであることを確認します。

SQL> SELECT COUNT(*) AS IDLE_PREPARER -
> FROM V$LOGSTDBY_PROCESS -
> WHERE TYPE = 'PREPARER' and status_code = 16116;

IDLE_PREPARER
-------------
0

2. 適用準備が完了しているトランザクションの数がAPPLIERプロセスの数よりも少ないことを確認します。

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'txns applied' OR - > NAME = 'distinct txns in queue';

NAME                          VALUE
---------------------         -------
txns applied                   27892
distinct txns in queue         12896

SQL> SELECT COUNT(*) AS APPLIER_COUNT -
> FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER';

APPLIER_COUNT
-------------
20

注意: これが一時イベントでないことを確認するために、この問合せは数回発行してください。

3. アイドル状態のAPPLIERプロセスがあることを確認します。

SQL> SELECT COUNT(*) AS IDLE_APPLIER -
> FROM V$LOGSTDBY_PROCESS -
> WHERE TYPE = 'APPLIER' and status_code = 16116;

IDLE_APPLIER
-------------------------
19

この例では、PREPARERプロセス数の増加に必要な3つの条件がすべて満たされています。APPLIERプロセス数の設定を20のままにし、PREPARERプロセス数を1から3に増やすとします。これは、常に次の等式を満たす必要があるためです。

APPLY_SERVERS + PREPARE_SERVERS = MAX_SERVERS - 3

まず、増加後のPREPARERプロセス数に対応するように、MAX_SERVERSの数を24から26に増やす必要があります。次に、PREPARERプロセス数を次のようにして増やすことができます。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS', 26);
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS', 3);

10.7.4 LCRキャッシュ用メモリーの調整

ある程度のワークロードの場合、SQL Applyは多数のページアウト操作を使用することがあるため、システム全体のスループットが低下します。LCRキャッシュに割当済のメモリーを増やした場合にスループットを改善できるかどうかを判断する手順は、次のとおりです。

1. 次の問合せを発行して、ページアウト・アクティビティのスナップショットを取得します。

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE '%page%' -
> OR NAME LIKE '%uptime%' OR NAME LIKE '%idle%';

NAME                             VALUE
----------------------------     --------------
coordinator uptime (seconds)             894856
bytes paged out                           20000
pageout time (seconds)                        2
system idle time (seconds)                 1000

2. この問合せを5分以内に再発行します。

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE '%page%' -
> OR NAME LIKE '%uptime%' OR NAME LIKE '%idle%';

NAME                             VALUE
----------------------------     --------------
coordinator uptime (seconds)             895156
bytes paged out                         1020000
pageout time (seconds)                      100
system idle time (seconds)                 1000

3. 正規化されたページアウト・アクティビティを計算します。次に例を示します。

Change in coordinator uptime (C)= (895156 – 894856) = 300 secs
Amount of additional idle time (I)= (1000 – 1000) = 0
Change in time spent in pageout (P) = (100 – 2) = 98 secs
Pageout time in comparison to uptime = P/(C-I) = 98/300 ~ 32.67%

ページアウト・アクティビティによる消費量が稼働時間全体の5%以下であれば理想的です。間隔を長くして引き続きスナップショットを取得し、ページアウト・アクティビティが引き続き適用時間の大部分を占めていることがわかった場合は、メモリー・サイズを大きくするとスループットが改善される可能性があります。SQL Applyに割当済のメモリーは、LCRキャッシュに割り当てられるメモリーを設定する(この例ではSGAを1GBに設定)と増やすことができます。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 1024);
PL/SQL procedure successfully completed

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

デフォルトでは、トランザクションは、プライマリ・データベースでコミットされた順序に正確に従って、ロジカル・スタンバイ・データベースに適用されます。厳密なデフォルト順序でのトランザクションのコミットにより、アプリケーションをロジカル・スタンバイ・データベースで透過的に実行できます。

ただし、多くのアプリケーションでは、すべてのトランザクションの間でそのような厳密な順序が必要なわけではありません。そのようなアプリケーションでは、オーバーラップしない一連の行を含むトランザクションを、プライマリ・データベースでコミットしたときと同じ順序でコミットする必要がありません。一般に、厳密でない順序により、ロジカル・スタンバイ・データベースでの適用率は高くなります。次の手順で、トランザクションをコミットするデフォルトの順序を変更できます。

1. SQL Applyを停止します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered

2. 次の文を発行して、プライマリ・データベースでコミットされた順序と異なる順序でトランザクションを適用できるようにします。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER', 'FALSE');
PL/SQL procedure successfully completed

3. SQL Applyを開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered

必要であれば、次のようにして、適用モードに戻ることができます。

1. SQL Applyを停止します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered

2. PRESERVE_COMMIT_ORDERパラメータのデフォルト値をリストアします。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER');
PL/SQL procedure successfully completed

3. SQL Applyを開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered

一般的なオンライン・トランザクション処理(OLTP)のワークロードでは、デフォルト以外のモードにすると、デフォルトの適用モードに比べてスループットを50%以上改善できます。

10.8 ロジカル・スタンバイ・データベースの下でのバックアップおよびリカバリ

ロジカル・スタンバイ・データベースは、従来の方法を使用してバックアップでき、データベース・バックアップをリストアしてアーカイブ・ログに対してメディア・リカバリを実行すると、バックアップと同時にリカバリができます。次の各項目は、ロジカル・スタンバイ・データベースの場合に該当します。

Recovery Managerのローカル・リカバリ・カタログの作成および使用時の考慮事項

Recovery Managerのリカバリ・カタログを作成する、またはカタログを変更するRecovery Managerのアクティビティを実行する場合、ロジカル・スタンバイ・データベースでは、GUARDをSTANDBYに設定して実行する必要があります。

ローカル・リカバリ・カタログがロジカル・スタンバイ制御ファイルにのみ保持されている場合は、GUARDをALLに設定したままにできます。

制御ファイルのバックアップに関する考慮事項

ロジカル・スタンバイ・データベースのインスタンス化の直後に、制御ファイルのバックアップを取得することをお薦めします。

Point-in-Timeリカバリに関する考慮事項

Point-in-Timeリカバリの後に初めてSQL Applyが開始されるとき、必要なアーカイブ・ログをローカル・システムで検出するか、プライマリ・データベースからフェッチできる必要があります。V$LOGSTDBY_PROCESSビューを使用して、アーカイブ・ログをプライマリ・データベースでリストアする必要があるかどうかを判断します。

表領域のPoint-in-Timeリカバリに関する考慮事項

ロジカル・スタンバイ・データベースの表領域に対してPoint-in-Timeリカバリを実行する場合、次のいずれかを実行する必要があります。

- 表領域にSQL Applyプロセスでメンテナンスされている表またはパーティションが含まれないことを確認する。

- 表領域にSQL Applyプロセスでメンテナンスされている表またはパーティションが含まれる場合は、ロジカル・スタンバイ・データベースで、DBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャを使用して、リカバリされる表領域に含まれるメンテナンス対象の表をすべて再度インスタンス化するか、またはDBMS_LOGSTDBY.SKIPプロシージャを使用してリカバリされる表領域に含まれる表をすべて登録し、メンテナンス対象の表のリストからスキップされるようにする。

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

この章では、Data Guardおよびスタンバイ・データベースとともにOracle Recovery Manager(RMAN)を使用するバックアップ対策について説明します。Recovery Managerを使用すると、最小限の労力でプライマリ・データベースのバックアップを実行し、個々のデータファイルの消失またはデータベース全体をすばやくリカバリできます。Recovery ManagerとData Guardを併用すると、Data Guard構成の管理作業を簡素化できます。

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

- Data Guard構成におけるRecovery Managerファイル管理の概要

- Data Guard環境におけるRecovery Manager構成の概要

- 推奨されるRecovery Manager構成およびOracle Database構成

- バックアップ手順

- Data Guard環境でのデータベースの登録および登録解除

- Data Guard環境におけるレポート生成

- Data Guard環境におけるバックアップ・メンテナンスの実行

- Data Guard環境におけるリカバリ例

- その他のバックアップ状況

- Recovery Managerの増分バックアップによるフィジカル・スタンバイ・データベースのロールフォワード

注意:
ロジカル・スタンバイ・データベースはプライマリ・データベースのブロック単位のコピーではないため、ロジカル・スタンバイ・データベースを使用してプライマリ・データベースをバックアップすることはできません。

関連項目:

- RMANの概要とData Guard環境でのRMAN使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- この章で使用しているすべてのRMANコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

11.1 Data Guard構成におけるRecovery Managerファイル管理の概要

Recovery Managerでは、リカバリ・カタログを使用して、Data Guard環境のすべてのデータベース・ファイルについてファイル名を追跡管理します。リカバリ・カタログは、1つ以上のOracleデータベースに関するメタデータを格納するためにRecovery Managerで使用されるデータベース・スキーマです。また、カタログには、オンラインREDOログ、スタンバイREDOログ、テンプレート、アーカイブREDOログ、バックアップ・セットおよびイメージ・コピーが作成される場所も記録されます。

11.1.1 Data Guard環境におけるバックアップの互換性

Recovery Managerコマンドは、リカバリ・カタログのメタデータを使用して、Data Guard環境の様々なフィジカル・データベースにわたって透過的に動作します。たとえば、フィジカル・スタンバイ・データベースで表領域のバックアップを作成し、プライマリ・データベースでリストアおよびリカバリできます。同様に、プライマリ・データベースで表領域のバックアップを作成し、フィジカル・スタンバイ・データベースでリストアおよびリカバリできます。

注意:
ロジカル・スタンバイ・データベースのバックアップは、プライマリ・データベースでは使用できません。

スタンバイ制御ファイルとスタンバイ以外の制御ファイルのバックアップには互換性があります。たとえば、スタンバイ制御ファイルをプライマリ・データベースでリストアしたり、プライマリ制御ファイルをフィジカル・スタンバイ・データベースでリストアできます。この互換性は、制御ファイルのバックアップをData Guard環境の1つのデータベースにオフロードできるということです。Recovery Managerは、データベースでのリストアおよびリカバリ時に、データベース・ファイルのファイル名を自動的に更新します。

11.1.2 Data Guard環境におけるバックアップの関連付け

リカバリ・カタログでは、すべてのデータベース・ファイル(バックアップ・ファイル)をDB_UNIQUE_NAMEに関連付けて、Data Guard環境のファイルを追跡管理します。ファイルを作成するデータベースは、そのファイルに関連付けられます。たとえば、Recovery Managerで一意の名前standby1が付けられたデータベースのバックアップが作成されると、standby1はこのバックアップに関連付けられます。バックアップは、CHANGE ... RESET DB_UNIQUE_NAMEを使用して別のデータベースに関連付けないかぎり、作成元のデータベースに関連付けられたままです。

11.1.3 Data Guard環境におけるバックアップのアクセス可能性

バックアップのアクセシビリティは、その関連付けとは異なります。Data Guard環境では、関連付けられたデータベースのみがディスク・バックアップにアクセスできるとリカバリ・カタログによってみなされますが、1つのデータベースに作成されたテープ・バックアップにはすべてのデータベースがアクセスできます。バックアップ・ファイルがいずれのデータベースにも関連付けられていない場合、リカバリ・カタログ・ビュー内のバックアップ・ファイルに関する行のSITE_KEY列にnullが表示されます。デフォルト設定では、Recovery Managerはターゲット・データベースにSITE_KEYがnullのファイルを関連付けます。

BACKUP、RESTORE、CROSSCHECKなどのRecovery Managerコマンドは、アクセス可能なバックアップに対して作用します。たとえば、RECOVER COPY操作の場合、Recovery Managerはデータベースに関連付けられているイメージ・コピーのみをリカバリ対象とみなします。また、ディスクおよびテープ上の増分バックアップをイメージ・コピーのリカバリ対象とみなします。データベース・リカバリでは、Recovery Managerは、データベースに関連付けられたディスク・バックアップのみとテープ上のすべてのファイルをリストアの対象とみなします。

バックアップのアクセス可能性における差異を示すため、データベースprodおよびstandby1が異なるホスト上に存在すると仮定します。Recovery Managerは、prodのデータファイル1のバックアップを本番ホスト上にある/prmhost/disk1/df1.dbfおよびテープに作成します。また、standby1のデータファイル1のバックアップをスタンバイ・ホスト上にある/sbyhost/disk2/df1.dbfおよびテープに作成します。Recovery Managerがデータベースprodに接続されると、Recovery Managerコマンドを使用してスタンバイ・ホスト上にある/sbyhost/disk2/df1.dbfバックアップで操作を実行することはできません。しかし、Recovery Managerはstandby1で作成したテープ・バックアップをリストア対象とみなします。

注意:
スタンバイ・ホストからプライマリ・ホスト(またはその逆)にバックアップをFTP転送し、対象のホスト上のデータベースにTARGETとして接続した後、バックアップに対してCATALOGを実行することができます。ファイルは、ターゲット・データベースによってカタログに追加された後に、ターゲット・データベースに関連付けられます。

11.2 Data Guard環境におけるRecovery Manager構成の概要

Data Guard構成では、制御ファイル、データファイルおよびアーカイブ・ログのバックアップ処理をスタンバイ・システムにオフロードできるため、バックアップが本番システムに与える影響は最小限に抑えられます。これらのバックアップを使用すると、プライマリ・データベースまたはスタンバイ・データベースをリカバリできます。

Recovery Managerでは、DB_UNIQUE_NAME初期化パラメータを使用してデータベース・サイトどうしを区別します。そのため、DB_UNIQUE_NAMEの一意性がData Guard構成で維持されることは不可欠なことです。

Recovery ManagerのREGISTER DATABASEコマンドを使用して明示的に登録する必要があるのは、プライマリ・データベースのみです。この登録は、Recovery Managerをリカバリ・カタログに接続し、ターゲットとしてプライマリ・データベースに接続した後に行います。

Recovery Manager構成を設定するには、Recovery ManagerのCONFIGUREコマンドを使用します。CONFIGUREコマンドがFOR DB_UNIQUE_NAMEオプションを指定して使用されると、指定したDB_UNIQUE_NAMEのデータベースに対してRecovery Managerサイト固有の構成が設定されます。

たとえば、リカバリ・カタログへの接続後、次のコマンドをRecovery Managerプロンプトで使用して、DBIDが1625818158のBOSTONデータベースに対してデフォルト・デバイス・タイプをSBTに設定できます。Recovery ManagerのSET DBIDコマンドは、ターゲットとしてデータベースに接続していない場合にのみ必要です。

SET DBID 1625818158;
CONFIGURE DEFAULT DEVICE TYPE TO SBT FOR DB_UNIQUE_NAME BOSTON;

11.3 推奨されるRecovery Manager構成およびOracle Database構成

この項では、次のRecovery Manager構成およびOracle Database構成について説明します。各構成によってバックアップ操作およびリカバリ操作を簡略化できます。

- プライマリおよびスタンバイ・データベースでのOracle Database構成

- プライマリ・データベースでのRecovery Manager構成

- バックアップが実行されるスタンバイ・データベースでのRecovery Manager構成

- バックアップが実行されないスタンバイでのRecovery Manager構成

構成の前提

この項で説明する構成は、次の前提に基づいています。

- スタンバイ・データベースはフィジカル・スタンバイ・データベースで、バックアップはスタンバイ・データベースでのみ作成されます。プライマリ・データベースとスタンバイ・データベースの両方でバックアップを作成する場合の手順の変更は、11.9.1項を参照してください。

- 1つのデータベース・サーバーで作成されたバックアップを別なデータベース・サーバーにリストアできるようにするには、RMANリカバリ・カタログが必要です。プライマリ・データベースはスタンバイ・データベースでバックアップが作成されたことを知らないので、RMANリポジトリとして制御ファイルだけを使用するのでは不十分です。
Recovery Managerのリカバリ・カタログは、バックアップ履歴および他のリカバリ関連のメタデータを一元化された場所に編成します。リカバリ・カタログは、データベース内に構成され、バックアップ・メタデータが格納されます。リカバリ・カタログには、制御ファイルに関する領域の制限がないため、バックアップに関する履歴データをより多く格納できます。

カタログ・サーバーは、プライマリ・サイトおよびスタンバイ・サイトと物理的に切り離されていますが、Data Guard構成内に置くことをお薦めします。これは、いずれのサイトで障害が発生しても最新のバックアップをリカバリする機能に影響しないためです。

関連項目:
リカバリ・カタログの管理の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- 構成内のすべてのデータベースには、Oracle Database 11gリリース1(11.1)を使用します。

- Oracle Secure Backupソフトウェアまたはサード・パーティのメディア管理ソフトウェアは、バックアップをテープに取るようにRecovery Managerで構成します。

11.3.1 プライマリおよびスタンバイ・データベースでのOracle Database構成

次のOracle Database構成は、Data Guard環境におけるすべてのプライマリ・データベースおよびスタンバイ・データベースで推奨されます。

- データベースごとに高速リカバリ領域を構成する(リカバリ領域はデータベースに対してローカル)。
高速リカバリ領域は、ファイル・システムまたはOracle Automatic Storage Management(Oracle ASM)ディスク・グループ上にある、リカバリに必要なすべてのファイルが存在する唯一の格納場所です。これらのファイルには、制御ファイル、アーカイブ・ログ、オンラインREDOログ、フラッシュバック・ログおよびRecovery Managerバックアップがあります。新しいバックアップおよびアーカイブ・ログが高速リカバリ領域に作成されると、古いファイル(保存期間を超過しているまたは三次記憶域にバックアップされている)は自動的に削除され、新しいファイル用の領域が作成されます。さらに、高速リカバリ領域の領域使用量が事前に定義された制限に近づいている場合に、DBAにアラートを送信するように通知を設定できます。DBAは、リカバリ領域の領域制限を上げる、ディスク・ハードウェアを追加する、あるいは保存期間を短縮するなどの処置を取ることができます。

次の初期化パラメータを設定して、高速リカバリ領域を構成します。

DB_RECOVERY_FILE_DEST = <mount point or Oracle ASM Disk Group>
DB_RECOVERY_FILE_DEST_SIZE = <disk space quota>

関連項目:
高速リカバリ領域の構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- サーバー・パラメータ・ファイル(SPFILE)を使用して、インスタンス・パラメータがバックアップに保存されるようにバックアップを作成できるようにする。

- プライマリ・データベースおよびスタンバイ・データベースでフラッシュバック・データベースを有効にする。
フラッシュバック・データベースを有効に設定すると、Oracle Databaseによってフラッシュバック・ログが高速リカバリ領域に保持されます。これらのログを使用すると、完全にリストアしなくても、前の時点までデータベースをロールバックできます。

関連項目:
フラッシュバック・データベースの有効化に関する詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

11.3.2 プライマリ・データベースでのRecovery Manager構成

Recovery Managerの継続的な使用を簡略化するために、多くの永続的な構成設定をData Guard環境のデータベースごとに設定できます。これらの設定により、Recovery Managerの動作を多面的に制御します。たとえば、バックアップの保存ポリシー、デフォルトのバックアップ先(テープまたはディスク)、デフォルトのバックアップ・デバイス・タイプなどを構成できます。CONFIGUREコマンドを使用すると、Recovery Manager構成を設定および変更できます。次のRecovery Manager構成は、プライマリ・データベースにおいて推奨されます。

1. Recovery Managerをプライマリ・データベースおよびリカバリ・カタログに接続します。

2. データベースの保存ポリシーをn日間として構成します。

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF <n> DAYS;

この構成により、任意の時点までのデータベース・リカバリの実行に必要なバックアップを指定した日数の間保存できます。

DELETE OBSOLETEコマンドを使用して、特定日数の間はリカバリを実行する必要がないバックアップ(設定されている保存方針に基づき)を削除します。

3. アーカイブ・ログを削除できる時期をCONFIGURE ARCHIVELOG DELETION POLICYコマンドを使用して指定します。たとえば、すべての宛先への送信を確認した後にログを削除する場合は、次の構成を使用します。

CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;

すべてのスタンバイ宛先への適用を確認した後にログを削除する場合は、次の構成を使用します。

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

4. RESYNC CATALOG FROM DB_UNIQUE_NAMEコマンドの使用時に、RMANがリモートで接続して、再同期化を行えるように、プライマリ・データベースおよびすべてのスタンバイ・データベースの接続文字列を構成します。ターゲット・インスタンスに接続する際、ネット・サービス名を提供する必要があります。再同期化元の他のデータベースがローカル・ホストにある場合でも、この要件は適用されます。ターゲットおよびリモート・インスタンスは同じSYSDBAパスワードを使用する必要があります。したがって、両方のインスタンスにパスワード・ファイルがなければなりません。単一のパスワードでパスワード・ファイルを作成し、そのパスワード・ファイルですべてのデータベース・インスタンスを起動することができます。たとえば、ボストンにあるスタンバイへの接続用TNS別名がboston_conn_strの場合、次のコマンドを使用してBOSTONデータベース・サイトの接続識別子を構成することができます。

CONFIGURE DB_UNIQUE_NAME BOSTON CONNECT IDENTIFIER 'boston_conn_str';

'boston_conn_str'にはユーザー名とパスワードが含まれていない点に注意してください。任意のデータベース・サイトからBOSTONデータベース・サイトに接続するために使用できる、Oracle Netサービス名だけが含まれています。

すべてのスタンバイ・データベースについて接続識別子が構成されたら、LIST DB_UNIQUE_NAME OF DATABASEコマンドを使用してスタンバイのリストを確認できます。

関連項目:

- RMAN構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- RMAN CONFIGUREコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

11.3.3 バックアップが実行されるスタンバイ・データベースでのRecovery Manager構成

次のRecovery Manager構成は、バックアップが実行されるスタンバイ・データベースで推奨されます。

1. Recovery Managerをターゲットとして(バックアップが実行される)スタンバイ・データベースに接続し、リカバリ・カタログに接続します。

2. 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップを有効にします。

CONFIGURE CONTROLFILE AUTOBACKUP ON;

3. 同じチェックポイントで有効なバックアップがすでに存在するデータファイルのバックアップをスキップします。

CONFIGURE BACKUP OPTIMIZATION ON;

4. メディア管理ソフトウェアによる要求に応じて、バックアップを作成するためのテープ・チャネルを構成します。

CONFIGURE CHANNEL DEVICE TYPE SBT PARMS '<channel parameters>';

5. アーカイブ・ログを削除できる時期をCONFIGURE ARCHIVELOG DELETION POLICYコマンドを使用して指定します。
ログはスタンバイ・サイトでバックアップされるため、ログ削除ポリシーに対してBACKED UPオプションを構成することをお薦めします。

関連項目:
アーカイブREDOログの削除方針の有効化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

11.3.4 バックアップが実行されないスタンバイでのRecovery Manager構成

次のRecovery Manager構成は、バックアップが実行されないスタンバイ・データベースで推奨されます。

1. Recovery Managerをターゲットとしてスタンバイ・データベースに接続し、リカバリ・カタログに接続します。

2. スタンバイ・データベースで適用された後のアーカイブ・ログの自動削除を有効にします。

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

11.4 バックアップ手順

この項では、Data Guard構成内のOracle Databaseのバックアップに使用されるRecovery Managerスクリプトおよび手順について説明します。次の項目で構成されています。

- テープ・バックアップ用キャッシュとしてのディスクの使用

- テープへの直接バックアップの実行

注意:
OracleのMaximum Availability Architecture(MAA)ベスト・プラクティスでは、プライマリ・データベースとスタンバイ・データベースの両方が停止した場合や、スイッチオーバーおよびフェイルオーバーについてサイトのプラクティスを新たに導入しなくてもよいようにする場合に、プライマリ・データベースとスタンバイ・データベースの両方でバックアップを作成してMTTRを短縮することをお薦めしています。

サーバー・パラメータ・ファイルのバックアップ

Oracle Database 11gまでは、サーバー・パラメータ・ファイル(SPFILE)のバックアップは、他のスタンバイ・データベースで使用できると想定されていました。しかし、実際には、すべてのスタンバイ・データベースで同じSPFILEを使用することは不可能です。この問題に対応するため、Recovery Managerでは、あるデータベース・サイトで作成されたSPFILEバックアップを別のデータベース・サイトで使用できないようにしています。この制約は、COMPATIBLE初期化パラメータが11.0.0に設定されている場合にのみ実施されます。

スタンバイ・データベースでは、SPFILEのバックアップを除いたすべてのバックアップ操作をある特定のスタンバイ・データベースにオフロードできます。しかし、COMPATIBLE初期化パラメータが11.0.0に設定されている場合、SPFILEをディスクにバックアップし、バックアップがテープに書き込まれるスタンバイ・サイトでは手動でカタログに追加できます。SPFILEバックアップ・セットに格納される追加メタデータにより、どのデータベースのSPFILEがどのバックアップ・セットに含まれるかRecovery Managerで識別できます。そのため、テープからリストアする際に、適切なSPFILEバックアップが選択されます。

11.4.1 テープ・バックアップ用キャッシュとしてのディスクの使用

スタンバイ・データベースの高速リカバリ領域は、テープ・バックアップ用のディスク・キャッシュとして機能できます。ディスクはバックアップ用の一次記憶域として使用され、テープは長期間のアーカイブ記憶域となります。テープの増分バックアップは毎日、テープの全体バックアップは毎週作成されます。これらのバックアップの実行に使用されるコマンドは、次の各項を参照してください。

11.4.1.1 ディスクをキャッシュとして使用する日次テープ・バックアップ用のコマンド

バックアップ計画を決定する際に、日次増分バックアップを利用することをお薦めします。データファイル・イメージ・コピーは、最新の増分バックアップを使用してロールフォワードできるため、常に最新のデータファイル・イメージ・コピーを提供できます。Recovery Managerでは、そのシステム変更番号(SCN)で取得された全体イメージ・コピーを使用するように、結果のイメージ・コピーをメディア・リカバリに使用するため、データベースの全体イメージ・コピーを毎日実行するオーバーヘッドはありません。もう1つのメリットは、イメージ・コピーが最新のブロック変更で更新され、現在の状態にデータベースを戻すのに必要なREDOログが少なくなるため、リカバリ時間が短縮されることです。

日次増分バックアップを実施するには、1日目にデータベースの全体バックアップを作成し、2日目に増分バックアップを作成します。アーカイブREDOログを使用すると、いずれの日のどの時点についてもデータベースをリカバリできます。3日目以降は、前日の増分バックアップをデータファイル・コピーとマージし、当日の増分バックアップを作成して、最終日までのどの時点についても高速リカバリを可能にします。REDOログを使用すると、当日のどの時点についてもデータベースをリカバリできます。

日次バックアップを実行するスクリプトは次のとおりです(最終行DELETE ARCHIVELOG ALLは、高速リカバリ領域をログの格納に使用しない場合にのみ必要です)。

RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
RECOVER COPY OF DATABASE WITH TAG 'OSS';
BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE;
BACKUP DEVICE TYPE SBT ARCHIVELOG ALL;
BACKUP BACKUPSET ALL;
DELETE ARCHIVELOG ALL;

スタンバイ制御ファイルは、制御ファイルの自動バックアップが有効に設定されているため、バックアップ操作の最後に自動的にバックアップされます。

次に、スクリプトの各コマンドの動作について説明します。

- RESYNC CATALOG FROM DB_UNIQUE_NAME ALL
Data Guard設定で、リカバリ・カタログが把握しているその他すべてのデータベース・サイト(プライマリおよびその他のスタンバイ・データベース)からの情報を再同期化します。RESYNC CATALOG FROM DB_UNIQUE_NAMEが機能するためには、Oracle Netサービス名を使用してRMANをターゲットに接続し、すべてのデータベースで同じパスワード・ファイルを使用する必要があります。

- RECOVER COPY OF DATABASE WITH TAG 'OSS'
前日に取得したレベル1の増分バックアップを適用して、データベースのレベル0のコピーをロールフォワードします。この例のスクリプトでは、前日のレベル1の増分にはOSSタグが付けられています。その増分は、BACKUP DEVICE TYPE DISK ... DATABASEコマンドによって生成されます。このコマンドが実行された1日目には、レベル1の増分がまだないため、ロールフォワードはありません。レベル0の増分が、BACKUP DEVICE TYPE DISK ... DATABASEコマンドによって生成されます。2日目にも、レベル0の増分しかないため、ロールフォワードはありません。OSSタグが付けられたレベル1の増分が、BACKUP DEVICE TYPE DISK ... DATABASEコマンドによって生成されます。3日目以降には、前日に作成されたOSSタグ付きのレベル1の増分を使用して、ロールフォワードが実行されます。

- BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE
新しいレベル1の増分バックアップを作成します。このコマンドが実行された1日目は、レベル0の増分となります。2日目以降は、レベル1の増分となります。

- BACKUP DEVICE TYPE SBT ARCHIVELOG ALL
所定の削除ポリシーに従って、アーカイブ・ログをテープにバックアップします。

- BACKUP BACKUPSET ALL
増分バックアップの作成結果として作成されるバックアップ・セットをバックアップします。

- DELETE ARCHIVELOG ALL
CONFIGURE ARCHIVELOG DELETION POLICYコマンドで設定されたログ削除ポリシーに従って、アーカイブ・ログを削除します。アーカイブ・ログが高速リカバリ領域にある場合は、空きディスク領域がさらに必要になると自動的に削除されます。そのため、毎日ログを明示的に削除する場合にのみ、このコマンドを使用する必要があります。

11.4.1.2 ディスクをキャッシュとして使用する週次テープ・バックアップ用のコマンド

すべてのリカバリ関連ファイルをテープにバックアップするには、次のコマンドを週1回使用します。

BACKUP RECOVERY FILES;

これにより、ディスク上にある最新の増分バックアップ、イメージ・コピー・バックアップおよびアーカイブ・ログ・バックアップがすべてテープにバックアップされます。

11.4.2 テープへの直接バックアップの実行

OracleのMedia Management Layer(MML)APIにより、サード・パーティ・ベンダーは、メディア・マネージャ、Recovery Managerと連動して機能するソフトウェア、テープ・ドライブなどの順次メディア・デバイスへのバックアップを可能にするベンダーのハードウェアを構築できます。メディア・マネージャは、テープなどの順次メディアのロード、アンロードおよびラベル付けを処理します。Recovery Managerを順次メディア・デバイスとともに使用するには、Oracle Secure Backupまたはサード・パーティのメディア管理ソフトウェアをインストールする必要があります。

デフォルトでは、次の手順を実行してテープへの直接バックアップを実行します。

1. Recovery Managerを(ターゲット・データベースとして)スタンバイ・データベースに接続し、リカバリ・カタログに接続します。

2. 次のように、CONFIGUREコマンドを実行します。

CONFIGURE DEFAULT DEVICE TYPE TO SBT;

この例では、スタンバイ・データベースで全体バックアップが毎週、増分バックアップが毎日作成されます。

関連項目:
メディア・マネージャ用のRMANの構成方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

11.4.2.1 テープに直接実行する日次バックアップ用のコマンド

次の手順を実行して、テープに日次バックアップを直接実行します。

1. RMANをスタンバイ・データベース(ターゲット・データベースとして)、およびリカバリ・マネージャに接続します。

2. 次のRecovery Managerコマンドを実行します。

RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
BACKUP AS BACKUPSET INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
DELETE ARCHIVELOG ALL;

これらのコマンドは、Data Guard環境内のその他すべてのデータベースの情報を再同期化します。また、すべてのアーカイブ・ログを含むデータベースのレベル1の増分バックアップを作成します。このスクリプトが実行された1日目に、レベル0のバックアップが検出されなければ、レベル0のバックアップが作成されます。

DELETE ARCHIVELOG ALLコマンドは、すべてのアーカイブ・ログ・ファイルが高速リカバリ領域にない場合にのみ必要です。

11.4.2.2 テープに直接実行する週次バックアップ用のコマンド

週1日、次の手順を実行してテープに週次バックアップを直接実行します。

1. Recovery Managerを(ターゲット・データベースとして)スタンバイ・データベースに接続し、リカバリ・カタログに接続します。

2. 次のRecovery Managerコマンドを実行します。

BACKUP AS BACKUPSET INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG;
DELETE ARCHIVELOG ALL;

これらのコマンドは、Data Guard環境内のその他すべてのデータベースの情報を再同期化し、すべてのアーカイブ・ログを含むレベル0のデータベース・バックアップを作成します。

DELETE ARCHIVELOG ALLコマンドは、すべてのアーカイブ・ログ・ファイルが高速リカバリ領域にない場合にのみ必要です。

11.5 Data Guard環境でのデータベースの登録および登録解除

REGISTER DATABASEコマンドを使用して明示的に登録する必要があるのは、プライマリ・データベースのみです。この登録は、Recovery Managerをリカバリ・カタログに接続し、TARGETとしてプライマリ・データベースに接続した後に行います。

新しいスタンバイは、スタンバイ・データベースに接続するか、またはCONFIGURE DB_UNIQUE_NAMEコマンドを使用して接続識別子を構成すると、リカバリ・カタログに自動的に登録されます。

特定のスタンバイ・データベースに関する情報を登録解除するには、UNREGISTER DB_UNIQUE_NAMEコマンドを使用できます。スタンバイ・データベースをData Guard環境から完全に削除すると、同じData Guard環境内の別のデータベースに接続した後に、リカバリ・カタログのデータベース情報も削除できます。登録解除されたデータベースと関連付けられたバックアップは、そのまま他のデータベースで使用できます。これらのバックアップは、CHANGE BACKUP RESET DB_UNIQUE_NAMEコマンドを使用して既存の他のデータベースに関連付けることができます。

INCLUDING BACKUPSオプションを指定してUNREGISTER DB_UNIQUE_NAMEコマンドを使用すると、削除されるデータベースに関連付けられたすべてのバックアップ・ファイルのメタデータもリカバリ・カタログから削除されます。

11.6 Data Guard環境におけるレポート生成

FOR DB_UNIQUE_NAME句を指定してRecovery ManagerのLIST、REPORTおよびSHOWの各コマンドを使用すると、特定のデータベースに関する情報を表示できます。

たとえば、リカバリ・カタログに接続した後、次のコマンドを使用してDBIDが1625818158のデータベースに関する情報を表示し、Data Guard環境内のデータベースを出力できます。SET DBIDコマンドは、TARGETとしてデータベースに接続していない場合にのみ必要です。最後の3つのコマンドは、DB_UNIQUE_NAMEがBOSTONのデータベースについて、アーカイブ・ログ、データベース・ファイル名およびRecovery Managerの構成情報を出力します。

SET DBID 1625818158;
LIST DB_UNIQUE_NAME OF DATABASE;
LIST ARCHIVELOG ALL FOR DB_UNIQUE_NAME BOSTON;
REPORT SCHEMA FOR DB_UNIQUE_NAME BOSTON;
SHOW ALL FOR DB_UNIQUE_NAME BOSTON;

11.7 Data Guard環境におけるバックアップ・メンテナンスの実行

Data Guard環境のファイル(データファイル、アーカイブ・ログ、バックアップ・ピース、イメージ・コピー、プロキシ・コピー)は、DB_UNIQUE_NAMEパラメータを使用してデータベースに関連付けられます。そのため、Data Guard環境のデータベースごとに、DB_UNIQUE_NAMEに指定された値は一意であることが重要です。この情報は、ファイル共有属性とともに、Recovery Managerの様々な操作の際にアクセスできるファイルを判別するのに使用されます。

ファイル共有属性は、ディスク上のファイルは関連付けられたデータベースでのみアクセス可能で、テープ上のすべてのファイルはすべてのデータベースでアクセス可能に設定されています。BACKUPおよびRESTOREなどのRMANコマンド、およびその他のメンテナンス・コマンドは、この想定で機能しています。たとえば、データベースでのイメージ・コピーのロールフォワード操作中は、そのデータベースに関連付けられたイメージ・コピーだけがロールフォワードされます。同様に、ディスクとテープのすべての増分バックアップを使用して、イメージ・コピーのロールフォワードを行います。また、リカバリ操作中は、データベースに関付けられたディスク・バックアップとテープ上のファイルだけがバックアップ元と見なされます。

関連項目:
RMANコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

11.7.1 リカバリ・カタログのメタデータの変更

様々なオペランドを指定してRecovery ManagerのCHANGEコマンドを使用すると、リカバリ・カタログのメタデータを変更できます。詳細は、次の各項を参照してください。

スタンバイ・データベース間でのファイルの関連付けの変更

RESET DB_UNIQUE_NAMEオプションを指定してCHANGEコマンドを使用すると、Data Guard環境内のあるデータベースから別のデータベースにファイルの関連付けを変更できます。CHANGEコマンドは、ディスク・バックアップまたはアーカイブ・ログをあるデータベースから別のデータベースに転送し、転送先のデータベースでそれらのファイルを使用するときに役立ちます。また、CHANGEコマンドは、FOR DB_UNIQUE_NAMEオプションとRESET DB_UNIQUE_NAME TOオプションを使用すると、いずれのデータベースに直接接続しなくてもデータベース間でファイルの関連付けを変更できます。

データベースのDB_UNIQUE_NAMEの変更

データベースのDB_UNIQUE_NAME初期化パラメータの値を変更すると、Data Guard環境でも同じ変更を行う必要があります。そのデータベース・インスタンスへの接続後、Recovery Managerのリカバリ・カタログはDB_UNIQUE_NAMEの新旧両方の値を認識します。リカバリ・カタログ・スキーマ内で新旧の値に関する情報をマージするには、Recovery ManagerのCHANGE DB_UNIQUE_NAMEコマンドを使用する必要があります。Recovery Managerが変更後のDB_UNIQUE_NAMEパラメータでインスタンスに接続されない場合は、CHANGE DB_UNIQUE_NAMEコマンドを使用してリカバリ・カタログ・スキーマのDB_UNIQUE_NAMEの名前を変更することもできます。たとえば、データベースのインスタンス・パラメータ値がBOSTON_AからBOSTON_Bに変更された場合、ターゲット・データベースおよびリカバリ・カタログに接続した後に、Recovery Managerのプロンプトで次のコマンドを実行する必要があります。

CHANGE DB_UNIQUE_NAME FROM BOSTON_A TO BOSTON_B;

バックアップの使用不可化またはメタデータの削除

AVAILABLE、UNAVAILABLE、KEEP、UNCATALOGなどのオプションを指定してCHANGEコマンドを使用すると、バックアップをリストアおよびリカバリの目的で使用可能または使用不可能にしたり、そのメタデータを保存または削除することができます。

関連項目:
RMANのCHANGEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

11.7.2 アーカイブ・ログまたはバックアップの削除

DELETEコマンドを使用して、バックアップ・セット、イメージ・コピー、アーカイブ・ログ、プロキシ・コピーを削除します。特定のデータベースに関連付けられているファイルのみを削除するには、FOR DB_UNIQUE_NAMEオプションをDELETEコマンドとともに使用する必要があります。

ファイルのメタデータは、現行のターゲット・データベースに関連付けられ、正常に削除されたすべてのファイル(またはどの既知のデータベースにも関連付けられていないファイル)について削除されます。ファイルが正常に削除できなかった場合は、FORCEオプションを使用してファイルのメタデータを削除します。

別のデータベースに関連付けられているファイルが正常に削除された場合、リカバリ・カタログのそのメタデータも削除されます。他のデータベースに関連付けられているファイルおよび正常に削除できなかったファイルは、DELETEコマンドの完了時に、ファイルが関連付けられているデータベースで同じ操作を実行するように求める指示とともに出力されます(ファイルはデータベースごとにグループ化されます)。FORCEオプションを使用して、この動作を上書きすることはできません。削除不可のファイルのメタデータを削除しても問題ないことが明確である場合は、CHANGE RESET DB_UNIQUE_NAMEコマンドを使用してデータベースとのファイルの関連付けに対するメタデータを変更し、FORCEオプションを指定してDELETEコマンドを使用し、ファイルのメタデータを削除します。

関連項目:
RMANのDELETEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

11.7.3 リカバリ・カタログのメタデータの検証

CROSSCHECKコマンドを使用してリカバリ・カタログ・スキーマのファイル・ステータスを検証および更新します。特定のデータベースに関連付けられたファイルを検証するには、FOR DB_UNIQUE_NAMEオプションをCROSSCHECKコマンドとともに使用します。

現行のターゲット・データベースに関連付けられたすべてのファイル(またはどのデータベースにも関連付けられていないあらゆるファイル)のメタデータは、CROSSCHECK操作の結果に応じてAVAILABLEまたはEXPIREDのマークが付けられます。

別のデータベースに関連付けられているファイルが正常に検査された場合、リカバリ・カタログのそのメタデータもAVAILABLEに変更されます。他のデータベースに関連付けられているファイルおよび正常に検査できなかったファイルは、CROSSCHECKコマンドの完了時に、ファイルが関連付けられているデータベースで同じ操作を実行するように求める指示とともに出力されます(ファイルはサイトごとにグループ化されます)。確認し、それでも使用不可のファイルのステータス・メタデータを変更する場合は、CHANGE RESET DB_UNIQUE_NAMEコマンドを使用してデータベースとのファイルの関連付けに対するメタデータを変更し、CROSSCHECKコマンドを実行してステータス・メタデータをEXPIREDに更新します。

関連項目:
RMANのCROSSCHECKコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

11.8 Data Guard環境におけるリカバリ例

次の各項の例では、バックアップを作成したのと同じシステムにテープからファイルをリストアすると仮定しています。ファイルを異なるシステムにリストアする必要がある場合は、そのシステムに対してチャネルを構成してから、リストア・コマンドおよびリカバリ・コマンドを実行する必要があります。存在しないデータベースの構成を設定するには、SET DBIDコマンドおよびFOR DB_UNIQUE_NAMEを指定したCONFIGUREコマンドを使用します。異なるシステムからRecovery Managerバックアップにアクセスする方法の詳細は、メディア管理のドキュメントを参照してください。

この項では、次の使用例について説明します。

- プライマリ・データベースのデータファイル消失からのリカバリ

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

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

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

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

- プライマリ・データベースの不完全リカバリ

11.8.1 プライマリ・データベースのデータファイル消失からのリカバリ

プライマリ・データベースのデータファイル消失からは、バックアップを使用するか、スタンバイ・データベースのファイルを使用してリカバリできます。詳細は、次の各項を参照してください。

バックアップの使用

次のRecovery Managerコマンドを発行して、データファイルをリストアおよびリカバリします。プライマリ・データベースとリカバリ・カタログ・データベースの両方に接続する必要があります。

RESTORE DATAFILE n,m...;
RECOVER DATAFILE n,m...;

次のRecovery Managerコマンドを発行して、表領域をリストアおよびリカバリします。プライマリ・データベースとリカバリ・カタログ・データベースの両方に接続する必要があります。

RESTORE TABLESPACE tbs_name1, tbs_name2, ...
RECOVER TABLESPACE tbs_name1, tbs_name2, ...

スタンバイ・データベースのファイルの使用

Oracle 11g現在、スタンバイ・データベースのファイルを使用して消失したファイルをリカバリできます。これは、スタンバイが最新の状態で、ネットワーク接続がスタンバイとプライマリ間のファイル・コピーをサポートするのに十分足りる場合に有効に機能します。

Recovery Managerを起動し、次の手順を実行してスタンバイからプライマリにデータファイルをコピーします。

1. ターゲット・データベースとしてスタンバイ・データベースに接続します。

CONNECT TARGET sys@standby

パスワードの入力を求められます。

target database Password: password

2. 補助データベースとしてプライマリ・データベースに接続します。

CONNECT AUXILIARY sys@primary

パスワードの入力を求められます。

target database Password: password

3. ネットワークを介してスタンバイ・ホストのデータファイルをプライマリ・ホスト上の場所にバックアップします。たとえば、/disk1/df2.dbfがスタンバイ・ホストのデータファイル2の名前だとします。/disk8/datafile2.dbfがプライマリ・ホストのデータファイル2の名前だとします。次のコマンドは、ネットワークを介してデータファイル2を/disk9/df2copy.dbfにコピーします。

BACKUP AS COPY DATAFILE 2 AUXILIARY FORMAT '/disk9/df2copy.dbf';

4. 次のようにして、Recovery Managerクライアントを終了します。

EXIT;

5. Recovery Managerを起動し、ターゲットとしてプライマリ・データベースに接続し、リカバリ・カタログに接続します。

CONNECT TARGET sys@primary;
target database Password: password

CONNECT CATALOG rman@catdb;
recovery catalog database Password: password

6. CATALOG DATAFILECOPYコマンドを使用して、Recovery Managerで使用できるようにこのデータファイル・コピーをカタログに追加します。

CATALOG DATAFILECOPY '/disk9/df2copy.dbf';

次に、SWITCH DATAFILEコマンドを使用してデータファイル・コピーを切り替え、/disk9/df2copy.dbfが現行のデータファイルになるようにします。

RUN {
SET NEWNAME FOR DATAFILE 2 TO '/disk9/df2copy.dbf';
SWITCH DATAFILE 2;
}

11.8.2 スタンバイ・データベースのデータファイル消失からのリカバリ

1つ以上のデータファイルが消失した後にスタンバイ・データベースをリカバリするには、Recovery ManagerのRESTORE DATAFILEコマンドを使用して、消失したファイルをバックアップからスタンバイ・データベースにリストアする必要があります。破損ファイルのリカバリに必要なアーカイブREDOログ・ファイルすべてにスタンバイ・データベースがディスク上でアクセス可能な場合は、REDO Applyを再開します。

リカバリに必要なアーカイブREDOログ・ファイルにディスク上でアクセスできない場合は、次の手順に従ってRecovery Managerを使用し、リストアしたデータファイルをスタンバイ・データベースに最後に適用されたログよりも大きいSCN/ログ順序番号までリカバリし、REDO Applyを再開してREDOデータの適用を続行します。

1. SQL*Plusをスタンバイ・データベースに接続します。

2. SQL ALTER DATABASE ...文を使用して、REDO Applyを停止します。

3. 別の端末で、Recovery Managerを起動し、スタンバイ・データベースとリカバリ・カタログ・データベースの両方に接続します(スタンバイ・インスタンスへの接続にはTARGETキーワードを使用します)。

4. 次のRecovery Managerコマンドを発行して、スタンバイ・データベースでデータファイルをリストアおよびリカバリします。

RESTORE DATAFILE <n,m,...>;
RECOVER DATABASE;

表領域をリストアするには、Recovery Managerの'RESTORE TABLESPACE tbs_name1, tbs_name2, ...'コマンドを使用します。

5. SQL*PlusのプロンプトでSQL ALTER DATABASE ...文を使用して、REDO Applyを再開します。

関連項目:
REDO Applyの開始および停止の詳細は、7.3項および7.4項を参照してください。

11.8.3 スタンバイ制御ファイルの消失からのリカバリ

Oracleソフトウェアでは、スタンバイ制御ファイルを多重化できます。スタンバイ制御ファイルが多重化されているかどうかを確認するには、次のようにCONTROL_FILES初期化パラメータを調べます。

SQL> SHOW PARAMETER CONTROL_FILES;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      <cfilepath1>,<cfilepath2>

多重スタンバイ制御ファイルの1つが消失しているかアクセスできないと、Oracleソフトウェアはインスタンスを停止し、アラート・ログに次のメッセージを書き込みます。

ORA-00210: cannot open the specified controlfile
ORA-00202: controlfile: '/disk1/oracle/dbs/scf3_2.f'
ORA-27041: unable to open file

制御ファイルの元のコピーを消失したコピーに上書きコピーし、次のSQL文を使用してスタンバイ・インスタンスを再起動できます。

SQL> STARTUP MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

RESTORE CONTROLFILEコマンドに続いてRECOVER DATABASEコマンドを実行すると、バックアップから制御ファイルをリストアできます。RECOVER DATABASEコマンドは、制御ファイル内のファイル名をそのデータベースに存在するファイルと一致するように自動的に修正し、データベースで最後に受信したログ順序番号までデータベースをリカバリします。

他の方法として、プライマリ・データベースから新しい制御ファイルを作成し、すべての多重化位置にコピーしてデータファイル名を手動で変更し、ディスク上に存在するファイルと一致させます。

11.8.4 プライマリ制御ファイルの消失からのリカバリ

Oracleソフトウェアでは、プライマリ・データベースの制御ファイルを多重化できます。プライマリ・データベースで制御ファイルの1つを更新できない場合は、プライマリ・データベース・インスタンスが自動的に停止します。

RESTORE CONTROLFILEコマンドに続いてRECOVER DATABASEコマンドを実行すると、バックアップから制御ファイルをリストアできます。RECOVER DATABASEコマンドは、制御ファイル内のファイル名をそのデータベースに存在するファイルと一致するように自動的に修正し、データベースをリカバリします。

もう1つの方法として、CREATE CONTROLFILE SQLコマンドを使用して新しい制御ファイルを作成することができます。すべてのデータファイルとオンライン・ログが残っている場合は、制御ファイルを再作成することができます。

関連項目:
失われた制御ファイルのRMANを使用したリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

11.8.5 オンラインREDOログ・ファイルの消失からのリカバリ

オンラインREDOログ・ファイルは多重化することをお薦めします。オンラインREDOログ・グループのメンバーがすべて消失すると、Oracleソフトウェアはインスタンスを終了します。書込みできないのがログ・ファイル・グループの一部のメンバーのみの場合、そのメンバーはアクセス可能になるまで使用されません。V$LOGFILEおよびV$LOGビューには、プライマリ・データベース・インスタンスのログ・ファイル・メンバーの現行のステータスに関する詳細情報が含まれます。

OracleソフトウェアがオンラインREDOログ・ファイルのメンバーの1つに書込みできない場合は、次のアラート・メッセージが戻されます。

ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/disk1/oracle/dbs/t1_log1.f'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

アクセスの問題がハードウェア・エラーによる一時的なものの場合は、問題を解決すると処理が自動的に続行されます。消失が永続的な場合は、新規メンバーを追加して古いメンバーをグループから削除できます。

REDOログ・グループに新規メンバーを追加するには、次の文を発行します。

SQL> ALTER DATABASE ADD LOGFILE MEMBER 'log_file_name' REUSE TO GROUP n;

この文は、データベースがオープン状態の場合にも、データベースの可用性に影響を与えずに発行できます。

アーカイブ済の非アクティブ・グループのメンバーがすべて消失した場合は、そのグループを削除して再作成できます。

他のすべての場合(現行のACTIVEグループまたはアーカイブされていない非アクティブ・グループのオンライン・ログ・メンバーすべてが消失した場合)は、スタンバイ・データベースにフェイルオーバーする必要があります。フェイルオーバー手順の詳細は第8章を参照してください。

11.8.6 プライマリ・データベースの不完全リカバリ

プライマリ・データベースの不完全リカバリを実行するのは、通常、データベースが論理的に(ユーザーまたはアプリケーションが原因で)破損した場合や、表領域またはデータファイルがデータベースから意図せずに削除された場合などです。

スタンバイ・データベース・インスタンス上の現在のデータベース・チェックポイントSCNに応じて、次のいずれかの手順でプライマリ・データベースの不完全リカバリを実行できます。すべての手順は、最も所要時間が短いものから優先順位順になっています。

フラッシュバック・データベースの使用 フラッシュバック・データベースの使用は、プライマリ・データベースでフラッシュバック・データベース機能が使用可能で、データベース・ファイルが1つも消失しておらず、Point-in-Timeリカバリが最も古いフラッシュバックSCNより大きいか、最も早いフラッシュバック時間よりも後の場合の推奨手順です。フラッシュバック・データベースを使用してPoint-in-Timeリカバリを実行する手順の詳細は、13.3項を参照してください。

スタンバイ・データベース・インスタンスの使用 これは、スタンバイ・データベースが必要な不完全リカバリ時間より後のもので、プライマリまたはスタンバイ・データベースでフラッシュバック・データベースが使用可能でない場合の推奨手順です。

1. スタンバイ・データベースを必要な時点までリカバリします。

RECOVER DATABASE UNTIL TIME 'time';

あるいは、SCNまたはログ順序番号を使用して不完全リカバリ時間を指定できます。

RECOVER DATABASE UNTIL SCN incomplete recovery SCN';
RECOVER DATABASE UNTIL LOGSEQ incomplete recovery log sequence number THREAD thread number;

2. スタンバイ・データベースを読取り専用モードでオープンし、データベースの状態を確認します。
必要な状態になっていない場合は、LogMinerユーティリティを使用してアーカイブREDOログ・ファイルを調べ、不完全リカバリに適切なターゲット時刻またはSCNを確認します。または、ターゲット時刻より前の判明している時点までスタンバイ・データベースをリカバリしてから、データベースを読取り専用モードでオープンし、データの状態を検査することもできます。データベースの状態が正常であると確認されるまで、このプロセスを繰り返します。データベースのリカバリ終了時点が遅すぎると(つまり、エラーが発生したSCNより後までリカバリすると)、それより前のSCNに戻せないことに注意してください。

3. SQL ALTER DATABASE ACTIVATE STANDBY DATABASE文を使用してスタンバイ・データベースをアクティブ化します。これにより、スタンバイ・データベースがプライマリ・データベースに変換されて、新しいリセットログ・ブランチが作成され、データベースがオープンします。新規リセットログ・ブランチへのスタンバイ・データベースの対応の詳細は、9.4項を参照してください。

プライマリ・データベース・インスタンスの使用 すべてのスタンバイ・データベース・インスタンスがすでに必要な時点より後までリカバリされており、プライマリまたはスタンバイ・データベースでフラッシュバック・データベースが使用できない場合は、この方法で操作する必要があります。

次の手順に従ってプライマリ・データベースで不完全リカバリを実行します。

1. LogMinerまたは他の手段を使用して、データベースのすべてのデータが正常と判明している時点またはSCNを識別します。

2. その時点またはSCNを使用して次のRecovery Managerコマンドを発行し、不完全データベース・リカバリを実行し、RESETLOGSオプションを使用して(カタログ・データベースとMOUNT状態のプライマリ・インスタンスに接続した後で)データベースをオープンします。

RUN
{
SET UNTIL TIME 'time';
RESTORE DATABASE;
RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;

この処理の後に、Data Guard構成内ですべてのスタンバイ・データベース・インスタンスを再確立する必要があります。

11.9 その他のバックアップ状況

次の各項では、スタンバイ・データベースとプライマリ・データベースでバックアップ・ファイルを共有できない場合、REDOログ・ファイルのリモート・アーカイブにスタンバイ・インスタンスのみが使用される場合、またはスタンバイ・データベースのファイル名がプライマリ・データベースとは異なる場合など、その他の構成にあわせてバックアップ処理を変更する方法について説明します。

11.9.1 スタンバイ・データベースが地理的に離れすぎているためにバックアップを共有できない場合

スタンバイ・データベース間の距離が離れている場合、プライマリ・システムや他のスタンバイ・システムからは、これらの上で作成されたバックアップに簡単にアクセスできません。すべてのシステム上でデータベースの完全バックアップを実行して、リカバリ操作を実行します。高速リカバリ領域は、プライマリおよびスタンバイ・システム上にローカルに置くことができます(つまり、プライマリ・データベースとスタンバイ・データベースで高速リカバリ領域が同一である必要がありません)。

この使用例でも、11.8項で説明した一般的な対策を使用できますが、次の例外があります。

- Recovery Managerで作成されるバックアップ・ファイルには、タグとしてローカル・システム名を指定し、そのタグをRESTORE操作で使用して、Recovery Managerによる同じホスト上で作成されたバックアップの選択を制限する必要があります。つまり、バックアップの作成時に、BACKUPコマンドではTAG system nameオプションを、RESTOREコマンドではFROM TAG system nameオプションを、RECOVERコマンドではFROM TAG system name ARCHIVELOG TAG system nameオプションをそれぞれ使用する必要があります。

- スタンバイ・サイトの障害時リカバリを実行する手順は、次のとおりです。

1. スタンバイの操作に使用されていたのと同じパラメータ・ファイルを使用して、スタンバイ・インスタンスをNOMOUNT状態で起動します。

2. プライマリ・インスタンスで、SQL ALTER DATABASE CREATE STANDBY CONTROLFILE AS filename文を使用してスタンバイ制御ファイルを作成し、作成された制御ファイルを使用してスタンバイ・インスタンスをマウントします。

3. 次のRecovery Managerコマンドを発行し、データベース・ファイルをリストアおよびリカバリします。

RESTORE DATABASE FROM TAG 'system name';
RECOVER DATABASE FROM TAG 'system name' ARCHIVELOG TAG 'system name';

4. REDO Applyを再開します。

スタンバイ・インスタンスにより残りのアーカイブREDOログ・ファイルがフェッチされます。

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

11.4項で説明した手順を使用しますが、データベース・ファイルをバックアップするRecovery ManagerコマンドはFALサーバーに対して実行できません。FALサーバーは、すべてのアーカイブREDOログ・ファイルのバックアップ・ソースとして使用できるため、アーカイブREDOログ・ファイルのバックアップをFALサーバーにオフロードします。

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

注意:
Oracle Database 11g現在、リカバリ・カタログは各スタンバイ・データベース・サイトのファイル名を再同期化できます。しかし、スタンバイ・データベースのファイル名がなんらかの理由でまったく再同期化されていなかった場合は、この項で説明する手順に従って再同期化することが可能です。

まったく再同期化されていなかったプライマリ・データベースとスタンバイ・データベースでデータベース・ファイル名が異なる場合は、使用するRESTOREおよびRECOVERコマンドが若干異なります。スタンバイ・データベースで実際のデータファイル名を取得するには、V$DATAFILEビューを問い合せ、データベースのすべてのデータファイルに対してSET NEWNAMEオプションを指定します。

RUN
{
SET NEWNAME FOR DATAFILE 1 TO 'existing file location for file#1 from V$DATAFILE';
SET NEWNAME FOR DATAFILE 2 TO 'existing file location for file#2 from V$DATAFILE';
…
…
SET NEWNAME FOR DATAFILE n TO 'existing file location for file#n from V$DATAFILE';
RESTORE {DATAFILE <n,m,…> | TABLESPACE tbs_name_1, 2, …| DATABASE;
SWITCH DATAFILE ALL;
RECOVER DATABASE {NOREDO};
}

同様に、Recovery ManagerのDUPLICATEコマンドでもSET NEWNAMEオプションを使用し、スタンバイ・データベースの作成中に新規ファイル名を指定する必要があります。あるいは、LOG_FILE_NAME_CONVERTおよびDB_FILE_NAME_CONVERTパラメータを設定できます。

関連項目:
DB_FILE_NAME_CONVERTおよびDB_CREATE_FILE_DESTパラメータの両方がスタンバイに設定されている場合の優先ルールの詳細は、13.5項「OMFまたはOracle ASMを使用するスタンバイ・データベースの作成」を参照してください。

11.10 Recovery Managerの増分バックアップによるフィジカル・スタンバイ・データベースのロールフォワード

Recovery Managerの増分バックアップを使用して、フィジカル・スタンバイ・データベースをプライマリ・データベースと同期化できる場合があります。Recovery ManagerのBACKUP INCREMENTAL FROM SCNコマンドを使用すると、プライマリ・データベースでスタンバイの現行SCNから始まるバックアップを作成し、それを使用してスタンバイ・データベースをロールフォワードできます。

この項で説明する手順は、フィジカル・スタンバイ・データベースが次のいずれかに該当するため、Recovery Managerの増分バックアップが役立つ状況に適用します。

- プライマリ・データベースから大幅に遅れている

- 広範囲にロギングなしの変更がある

- データファイルのサブセットにロギングなしの変更がある

注意:
この操作の実行時にはリカバリ・カタログの使用をお薦めします。これらの手順は、リカバリ・カタログがなくても可能ですが、リストアされた制御ファイルのファイル名を慎重に修正する必要があります。

関連項目:
RMANの増分バックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

11.10.1 Recovery Managerの増分バックアップを使用するための手順

特に記載していないかぎり、次の手順は前述の3つの状況すべてに適用されます。

1. スタンバイ・データベースでREDO Applyを停止します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2. スタンバイ・データベースで、増分バックアップのFROM SCNを計算します。この計算は、状況によって異なります。

- プライマリ・データベースから大幅に遅れているスタンバイでは、V$DATABASEビューを問い合せてスタンバイ・データベースの現行SCNを記録します。

SQL> SELECT CURRENT_SCN FROM V$DATABASE;

CURRENT_SCN
-----------
233995

- 広範囲にロギングなしの変更があるスタンバイでは、V$DATAFILEビューを問い合せて最小のFIRST_NONLOGGED_SCNを記録します。

SQL> SELECT MIN(FIRST_NONLOGGED_SCN) FROM V$DATAFILE -
> WHERE FIRST_NONLOGGED_SCN>0;

MIN(FIRST_NONLOGGED_SCN)
------------------------
223948

- データファイルのサブセットにロギングなしの変更があるスタンバイでは、次のようにV$DATAFILEビューを問い合せます。

SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE -
> WHERE FIRST_NONLOGGED_SCN > 0;

FILE#      FIRST_NONLOGGED_SCN
---------- -------------------
4              225979
5              230184

3. RMANターゲットとしてプライマリ・データベースに接続し、手順2で記録したスタンバイ・データベースの現行SCN(プライマリから大幅に遅れているスタンバイの場合)または最小のFIRST_NONLOGGED_SCN(広範囲にロギングなしの変更があるスタンバイの場合)から増分バックアップを作成します。

RMAN> BACKUP INCREMENTAL FROM SCN 233995 DATABASE FORMAT '/tmp/ForStandby_%U' tag 'FORSTANDBY';

スタンバイのデータファイルのサブセットにログの変更がない場合、次のように、FIRST_NONLOGGED_SCN列(手順2で記録された)にリストされた各データファイル用に増分バックアップを作成します。

RMAN> BACKUP INCREMENTAL FROM SCN 225979 DATAFILE 4 FORMAT '/tmp/ForStandby_%U' TAG 'FORSTANDBY';
RMAN> BACKUP INCREMENTAL FROM SCN 230184 DATAFILE 5 FORMAT '/tmp/ForStandby_%U' TAG 'FORSTANDBY';

このBACKUPコマンドは。データファイルのバックアップ、および手順7で使用する制御ファイルのバックアップを生成します。

4. バックアップ・ピースが共有記憶域にない場合は、プライマリで作成されたすべてのバックアップ・ピースをスタンバイに転送します。

scp /tmp/ForStandby_* standby:/tmp

5. 前の手順でバックアップ・ピースをコピーする必要があった場合、またはプロセス全体のリカバリ・カタログに接続されていない場合、新しいバックアップ・ピースをスタンバイのカタログに追加する必要があります(それ以外の場合は次の手順に進みます)。

RMAN> CATALOG START WITH '/tmp/ForStandby';

6. Recovery Managerターゲットとしてスタンバイ・データベースに接続し、REPORT SCHEMA文を実行してスタンバイ・データベース・サイトが自動的に登録され、スタンバイ・サイトにファイル名が表示されることを確認します。

RMAN> REPORT SCHEMA;

7. RMANターゲットとしてスタンバイ・データベースに接続し、次のコマンドを実行して増分バックアップを適用します。RESTORE STANDBY CONTROLFILE FROM TAGコマンドは、プロセス全体のリカバリ・カタログに接続されている場合にのみ機能するという点に注意してください。それ以外の場合は、RESTORE STANDBY CONTROLFILE FROM '<control file backup filename>'コマンドを使用します。

RMAN> STARTUP FORCE NOMOUNT;
RMAN> RESTORE STANDBY CONTROLFILE FROM TAG 'FORSTANDBY';
RMAN> ALTER DATABASE MOUNT;
RMAN> RECOVER DATABASE NOREDO;

注意:
リカバリ・カタログを使用する場合、RMAN RECOVERコマンドによってスタンバイ制御ファイル内のデータファイルのパス名が修正されます。リカバリ・カタログを使用しない場合はスタンバイ制御ファイル内のファイル名を手動で編集する必要があります。またはRMAN SET NEWNAMEコマンドを使用してデータファイル名を割り当てます。RMANのRECOVERおよびSET NEWNAMEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

8. 広範囲にロギングなしの変更があるスタンバイまたはデータファイルのサブセットにロギングなしの変更があるスタンバイで、V$DATAFILEビューを問い合せ、ロギングなしの変更が含まれるデータファイルがないことを確認します。次の問合せでは0(ゼロ)行が戻されます。

SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE -
> WHERE FIRST_NONLOGGED_SCN > 0;

注意:
増分バックアップは7日で不要になります。あるいは、この時点でRecovery ManagerのDELETEコマンドを使用して削除できます。

9. フィジカル・スタンバイ・データベースでREDO Applyを開始します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE -
> USING CURRENT LOGFILE DISCONNECT FROM SESSION;

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

Oracle Database 10gリリース1(10.1.0.3)からは、ロジカル・スタンバイ・データベースを使用して、Oracle Database 10gソフトウェアのローリング・アップグレードを実行できます。ローリング・アップグレード中は、プライマリ・データベースとロジカル・スタンバイ・データベースで異なるリリースのOracleデータベースを実行しながら、プライマリ・データベースの停止時間を最短に抑えて各リリースを一度に1つずつアップグレードできます。

注意:
この章では、より停止時間が長い通常のアップグレード手順(付録B「Data Guard構成におけるデータベースのアップグレードおよびダウングレード」を参照)にかわる方法について説明します。この章で説明する方法の手順と、付録Bの手順を組み合せようとしないでください。

この章の各手順では、Oracleデータベースのアップグレード中の停止時間を最短に抑える方法について説明します。この章は、次の項目で構成されています。

- SQL Applyを使用するローリング・アップグレードのメリット

- SQL Applyを使用してローリング・アップグレードを実行するための要件

- アップグレード手順に使用する図と表記規則

- ロジカル・スタンバイ・データベースの新規作成によるローリング・アップグレードの実行

- 既存のロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行

- 既存のフィジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行

12.1 SQL Applyを使用するローリング・アップグレードのメリット

SQL Applyを使用してローリング・アップグレードを実行する方法には、次のようなメリットがあります。

- データベースの停止時間が最短で済みます。停止時間全体がスイッチオーバーの実行所要時間と同様に短時間です。

- PL/SQLの再コンパイルによるアプリケーションの停止時間は発生しません。

- プライマリ・データベースに影響を与えずに、アップグレード後のデータベース・リリースを検証できます。

12.2 SQL Applyを使用してローリング・アップグレードを実行するための要件

ローリング・アップグレード手順の要件は、次のとおりです。

- Oracle Databaseリリースxを実行中のプライマリ・データベースとOracle Databaseリリースyを実行中のロジカル・スタンバイ・データベース。

- データベースがData Guard Broker構成に含まれていないこと。ブローカ構成からのデータベースの削除の詳細は、『Oracle Data Guard Broker』を参照してください。

- Data Guardの保護モードが最大可用性モードまたは最大パフォーマンス・モードに設定されていること。現在の保護モード設定を確認するには、V$DATABASEビューのPROTECTION_LEVEL列を問い合せます。

- ロジカル・スタンバイ・データベースのアップグレード中もプライマリ・データベースで処理を進行できるようにするために、ロジカル・スタンバイ・データベースの宛先のLOG_ARCHIVE_DEST_n初期化パラメータがMANDATORYに設定されていないこと。

- COMPATIBLE初期化パラメータがアップグレード前のソフトウェア・リリースと一致していること。つまり、リリースxからリリースyへのローリング・アップグレードでは、プライマリ・データベースとスタンバイ・データベースの両方でCOMPATIBLE初期化パラメータをリリースxに設定する必要があります。

12.3 アップグレード手順に使用する図と表記規則

図12-1に、アップグレード開始前のData Guard構成を示します。この例では、プライマリ・データベースとロジカル・スタンバイ・データベースで同じリリースのOracle Databaseソフトウェアが実行されています。

図12-1 アップグレード前のData Guard構成

アップグレード処理中に、Data Guard構成は何度か混合データベース・リリースで動作します。リリース間にまたがるデータ保護は使用できません。これらの手順では、データ保護を提供するためにData Guard構成に第2のスタンバイ・データベースがある場合を考えます。

アップグレード手順と図では、データベースを「プライマリ・データベース」と「スタンバイ・データベース」ではなく「データベースA」および「データベースB」と呼びます。これは、アップグレード手順の実行中にデータベースのロールが切り替わるためです。最初は、図12-1に示すようにデータベースAがプライマリ・データベースでデータベースBがロジカル・スタンバイ・データベースです。

次の各項では、SQL Applyのローリング・アップグレード手順を使用できる例について説明します。

- 12.4項「ロジカル・スタンバイ・データベースの新規作成によるローリング・アップグレードの実行」

- 12.5項「既存のロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行」

- 12.6項「既存のフィジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行」

12.4 ロジカル・スタンバイ・データベースの新規作成によるローリング・アップグレードの実行

この使用例では、既存のData Guard構成がなく、Oracle Databaseのローリング・アップグレードを実行するためだけにロジカル・スタンバイ・データベースを作成することを前提にしています。

表12-1に、プライマリ・データベースとスタンバイ・データベースでアップグレードを準備する手順を示します。

表12-1 ロジカル・スタンバイの新規作成によってローリング・アップグレードを実行する手順

手順

説明

手順1

サポートされないデータ型および記憶域属性を識別する

手順2

ロジカル・スタンバイ・データベースを作成する

手順3

ローリング・アップグレードを実行する

手順1   サポートされていないデータ型とストレージ属性の識別

プライマリ・データベースでサポートされないデータベース・オブジェクトを識別し、その処理方法を決定する手順は、次のとおりです。

1. 表についてサポートされないデータ型および記憶域属性を識別します。

- 付録C「ロジカル・スタンバイ・データベースでサポートされるデータ型およびDDL」を参照し、サポートされるデータ型および記憶域属性のリストを確認します。

- プライマリ・データベースでDBA_LOGSTDBY_UNSUPPORTEDおよびDBA_LOGSTDBY_SKIPビューを問い合せます。プライマリ・データベースで表示された表およびスキーマに対して行われた変更は、ロジカル・スタンバイ・データベースに適用されません。次の問合せを使用して、サポートされない表のリストを確認します。

SQL> SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED;

次の問合せを使用して、サポートされない内部スキーマのリストを確認します。

SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP -
>  WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';

2. サポートされない表の処理方法を決定します。
サポートされないオブジェクトをプライマリ・データベースで変更している場合、アップグレード手順の実行所要時間中、サポートされない表に対する変更を一時的に停止することで、アップグレードを実行できるようになる可能性があります。

サポートされないデータに対する変更を防止できる場合は、SQL Applyを使用してアップグレード手順を実行できることもあります。この方法では、ロジカル・スタンバイ制御ファイルの作成時からアップグレード完了時までは、サポートされない表に対するユーザー変更を禁止する必要があります。たとえば、給与管理部門はオブジェクト表を更新しますが、この部門がデータベースを更新するのは月曜から金曜のみであるとします。一方、カスタマ・サービス部門は1日24時間、1週7日間のデータベース・アクセスを必要としますが、使用するのはサポートされるデータ型および表のみであるとします。この使用例では、週末にアップグレードを実行できます。DBA_LOGSTDBY_EVENTSビューでトランザクション・アクティビティを監視し、最初のスイッチオーバーの実行時までアップグレードを中断できます(必要な場合)。

サポートされない表に対する変更をアップグレード中に防止できない場合、発生したサポートされないトランザクションはロジカル・スタンバイ・データベースのDBA_LOGSTDBY_EVENTS表に記録されます。アップグレードの完了後に、Oracle Data Pumpまたはエクスポート/インポート・ユーティリティを使用して、変更された表をアップグレード後のデータベースにインポートできます。

関連項目:

- 10.6.4項「サポートされていない表のレプリケートでのトリガーの使用」

変更された表のサイズにより、データベース操作が使用できなくなる期間が決定するため、データをエクスポートしてスタンバイ・データベースにインポートするには表が大きすぎないかどうかを判断する必要があります。たとえば、4TBの表は、エクスポート/インポート処理に適した候補ではありません。

注意:
アプリケーション内のデータ型がサポートされていないためにロジカル・スタンバイ・データベースを使用できない場合、『Oracle Databaseアップグレード・ガイド』に記載の方法に従ってアップグレードを実行します。

手順2   ロジカル・スタンバイ・データベースを作成する

ロジカル・スタンバイ・データベースを作成するには、第4章の手順に従います。

注意:
SQL Applyを初めて実行する前に、プライマリ・データベースで実行中の、ロジカル・スタンバイ・データベースではサポートされないトランザクションに関する情報を取得します。次のプロシージャを実行して情報を取得し、DBA_LOGSTDBY_EVENTSビューにイベントとして記録します。

EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',
DBMS_LOGSTDBY.MAX_EVENTS);

EXECUTE DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS',
'TRUE');

停止時間を最短に抑えるために、ロジカル・スタンバイ・データベースでスタンバイREDOログを構成することをお薦めします。

手順3   ローリング・アップグレードを実行する

ロジカル・スタンバイ・データベースを作成したので、12.5項「既存のロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行」で説明している手順を実行できます。この手順では、ロジカル・スタンバイで同じOracleソフトウェアを実行していることを前提としています。

12.5 既存のロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行

この項では、ロジカル・スタンバイ・データベースとプライマリ・データベースをアップグレードする手順について説明します。表12-2に手順を示します。

表12-2 既存のロジカル・スタンバイを使用したローリング・アップグレードの実行手順

手順

説明

手順1

ローリング・アップグレードの準備をする

手順2

ロジカル・スタンバイ・データベースをアップグレードする

手順3

アップグレード後のロジカル・スタンバイ・データベースでSQL Applyを再開する

手順4

アップグレード後のスタンバイ・データベースでイベントを監視する

手順5

スイッチオーバーを開始する

手順6

アップグレード中に変更されたすべての表をインポートする

手順7

スイッチオーバーを完了してユーザー・アプリケーションをアクティブ化する

手順8

古いプライマリ・データベースをアップグレードする

手順9

古いプライマリ・データベースでSQL Applyを開始する

手順10

必要な場合は、両方のデータベースの互換性レベルを上げる

手順11

新規ロジカル・スタンバイ・データベースでイベントを監視する

手順12

必要な場合は、再度スイッチオーバーを実行する

手順1   ローリング・アップグレードの準備をする

次の手順に従って、Oracleソフトウェアのローリング・アップグレードの実行準備をします。

1. ロジカル・スタンバイ・データベース(データベースB)で次の文を発行し、SQL Applyを停止します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

2. 必要に応じて、互換性を最高値に設定します。
COMPATIBLE初期化パラメータに、アップグレード前のプライマリ・データベースで実行されているOracle Databaseソフトウェアのリリース番号が指定されていることを確認します。

たとえば、プライマリ・データベースでリリース10.1が実行されている場合は、COMPATIBLE初期化パラメータを両方のデータベースで10.1に設定します。COMPATIBLE初期化パラメータは、必ずスタンバイ・データベースで設定してからプライマリ・データベースで設定してください。

手順2   ロジカル・スタンバイ・データベースをアップグレードする

ロジカル・スタンバイ・データベース(データベースB)のOracle Databaseソフトウェアをリリースyにアップグレードします。ロジカル・スタンバイ・データベースでは、アップグレード中、プライマリ・データベースからのREDOデータを受け入れません。

Oracle Databaseソフトウェアをアップグレードするには、該当するOracle Databaseリリースの『Oracle Databaseアップグレード・ガイド』を参照してください。

図12-2に、リリースxを実行中のデータベースAとリリースyを実行中のデータベースBを示します。アップグレード中は、REDOデータがプライマリ・システムに蓄積されます。

図12-2 ロジカル・スタンバイ・データベースのリリースのアップグレード

手順3   アップグレード後のロジカル・スタンバイ・データベースでSQL Applyを再開する

SQL Applyを再開し、データベースAではリリースx、データベースBではリリースyで動作させます。SQL Applyを開始するには、データベースBで次の文を発行します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

プライマリ・システムに蓄積されたREDOデータは、新しくアップグレードしたロジカル・スタンバイ・データベースに自動的に転送され、適用されます。Data Guard構成では、アップグレード後のOracle Databaseソフトウェア・リリースが本番環境で正常に実行されるかどうかを確認するために、任意の期間のみ図12-3に示す混合リリースを実行できます。

図12-3 混合リリースの実行

Database BがDatabase Aにどの程度速く追いつくのかを監視するには、Database BのV$LOGSTDBY_PROGRESSビューの問合せを行います。次に例を示します。

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS';
Session altered.

SQL> SELECT SYSDATE, APPLIED_TIME FROM V$LOGSTDBY_PROGRESS;

SYSDATE            APPLIED_TIME
------------------ ------------------
27-JUN-05 17:07:06 27-JUN-05 17:06:50

手順4   アップグレード後のスタンバイ・データベースでイベントを監視する

頻繁にDBA_LOGSTDBY_EVENTSビューを問い合せ、データベースBに適用されなかったDDL文とDML文があるかどうかを確認する必要があります。例12-1に、イベントの監視により2つのデータベースにおける潜在的な差異を把握する方法を示します。

例12-1 DBA_LOGSTDBY_EVENTSを使用したイベントの監視

SQL> SET LONG 1000
SQL> SET PAGESIZE 180
SQL> SET LINESIZE 79
SQL> SELECT EVENT_TIMESTAMP, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS -
> ORDER BY EVENT_TIMESTAMP;

EVENT_TIMESTAMP
---------------------------------------------------------------------------
EVENT
--------------------------------------------------------------------------------
STATUS
--------------------------------------------------------------------------------
…
24-MAY-05 05.18.29.318912 PM
CREATE TABLE SYSTEM.TST (one number)
ORA-16226: DDL skipped due to lack of support

24-MAY-05 05.18.29.379990 PM
"SYSTEM"."TST"
ORA-16129: unsupported dml encountered

前述の例で、各エラーの意味は次のとおりです。

- ORA-16226エラーは、サポートできないDDL文を示します。この場合は、内部スキーマに属しているためにサポートできません。

- ORA-16129エラーは、適用されなかったDML文を示します。

この種のエラーは、データベースAで発生した変更の一部がデータベースBに適用されなかったことを示します。この時点で、アップグレード手順を続行するかどうかを判断する必要があります。ロジカル・スタンバイ・データベースとプライマリ・データベース間で、この差異が許容可能であることが確実な場合は、アップグレード手順を続行します。不確実な場合は、アップグレード手順を中断してデータベースBを再インスタンス化し、別の時点でアップグレード手順を実行します。

手順5   スイッチオーバーを開始する

アップグレード後のデータベース・ソフトウェアが正常に動作していることを確認した後、データベースAで次の文を発行してスイッチオーバーを実行し、データベース・ロールを元に戻します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;

この文は、既存のトランザクションが完了まで待機する必要があります。スイッチオーバーの完了所要時間を最短に抑えるには、データベースAにまだ接続されているユーザーがすぐにログオフし、データベースBに再接続する必要があります。

注意:
8.3.1項で説明した通常の2フェーズ準備済スイッチオーバーは、同じバージョンのOracleソフトウェアの実行にプライマリ・データベースとスタンバイ・データベースの両方が必要であり、この時点でプライマリ・データベースは下位バージョンのOracleソフトウェアを実行しているため、使用できません。かわりに、前述の1フェーズ準備なしスイッチオーバーの手順を使用します。準備なしスイッチオーバーは、ロジカル・スタンバイ・データベースを使用するローリング・アップグレードの場合にのみ使用してください。

注意:
データベースAがプライマリ・データベースのときに、そこでサポートされない表またはパッケージに対するアクティビティを一時停止した場合、最終的にデータベースAに切り替える計画であれば、データベースBがプライマリ・データベースになっている間にデータベースBでも引き続き同じアクティビティを一時停止する必要があります。

手順6   アップグレード中に変更されたすべての表をインポートする

手順4「アップグレード後のスタンバイ・データベースでイベントを監視する」では、変更中のサポートされない表をリストする方法について説明しました。プライマリ・データベースでサポートされないDML文が発行された場合は(例12-1を参照)、Oracle Data Pumpなどのインポート・ユーティリティを使用して、各表の最新バージョンをインポートします。

たとえば、次のインポート・コマンドはscott.emp表を切り捨て、前のプライマリ・データベース(A)と一致するデータを移入します。

IMPDP SYSTEM NETWORK_LINK=DATABASEA TABLES=SCOTT.EMP TABLE_EXIST_ACTION=TRUNCATE

このコマンドは、実行前にimpdpパスワードの入力を求めてくることに注意してください。

手順7   スイッチオーバーを完了してユーザー・アプリケーションをアクティブ化する

アップグレード後のデータベース・ソフトウェアが正常に動作していることを確認した後、スイッチオーバーを完了してデータベース・ロールを元に戻します。

1. データベースBで、次のようにV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
--------------------
TO PRIMARY

2. SWITCHOVER_STATUS列にTO PRIMARYが表示される場合は、データベースBで次の文を発行してスイッチオーバーを完了します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

注意:
8.3.1項で説明した通常の2フェーズ準備済スイッチオーバーは、同じバージョンのOracleソフトウェアの実行にプライマリ・データベースとスタンバイ・データベースの両方が必要であり、この時点でプライマリ・データベースは下位バージョンのOracleソフトウェアを実行しているため、使用できません。かわりに、前述の1フェーズ準備なしスイッチオーバーの手順を使用します。準備なしスイッチオーバーは、ロジカル・スタンバイ・データベースを使用するローリング・アップグレードの場合にのみ使用してください。

3. 現在はプライマリ・データベース・ロールで実行中のデータベースBで、ユーザー・アプリケーションとサービスをアクティブ化します。

スイッチオーバー後は、新規データベース・ソフトウェア・リリースを実行中の新規プライマリ・データベース(B)から旧ソフトウェア・リリースを実行中の新規スタンバイ・データベース(A)には、REDOデータを送信できません。これは次のことを意味します。

- REDOデータは、新規プライマリ・データベースに蓄積されます。

- 新規プライマリ・データベースは、この時点では保護されていません。

図12-4に、前はスタンバイ・データベース(リリースyを実行)で現在はプライマリ・データベースになっているデータベースBと、前はプライマリ・データベース(リリースxを実行)で現在はスタンバイ・データベースになっているデータベースAを示します。ユーザーはデータベースBに接続されます。

データベースBがプライマリ・データベースとして適切に機能でき、ビジネスにプライマリ・データベースをサポートするためのロジカル・スタンバイ・データベースが不要な場合、これでローリング・アップグレード処理は完了です。ユーザーにデータベースBへのログインとそこでの作業開始を許可し、問題のない時点でデータベースAを破棄します。それ以外の場合は、手順8に進みます。

図12-4 スイッチオーバー後

手順8   古いプライマリ・データベースをアップグレードする

データベースAでは引き続きリリースxが実行されており、アップグレードしてSQL Applyを開始するまでは、データベースBからのREDOデータを適用できません。

Oracle Databaseソフトウェアのアップグレードの詳細は、該当するOracle Databaseリリースの『Oracle Databaseアップグレード・ガイド』を参照してください。

図12-5に、両方のデータベースがアップグレードされた後のシステムを示します。

図12-5 両方のデータベースがアップグレードされた後

手順9   古いプライマリ・データベースでSQL Applyを開始する

データベースAで次の文を発行してSQL Applyを開始し、必要に応じてデータベースBへのデータベース・リンクを作成します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY db_link_to_b;

注意:
データベース・リンクを作成し(まだ設定されていない場合)、NEW PRIMARY句を使用する必要があります。これは、手順4で1フェーズ準備なしスイッチオーバーを使用してデータベースAをスタンバイ・データベースに切り替えたためです。
ユーザーSYSTEMとして接続するか、同様のレベルの権限を持つアカウントで接続する必要があります。

データベースAでSQL Applyを開始すると、プライマリ・データベース(B)に蓄積されたREDOデータがロジカル・スタンバイ・データベース(B)に送信されます。すべてのREDOデータがスタンバイ・データベースで使用可能になると、プライマリ・データベースはデータ消失から保護されます。

手順10   必要な場合は、両方のデータベースの互換性レベルを上げる

COMPATIBLE初期化パラメータを設定して、両方のデータベースの互換性レベルを上げます。互換性レベルは、ロジカル・スタンバイ・データベースで上げてから、プライマリ・データベースで上げる必要があります。COMPATIBLEパラメータは、スタンバイ・データベースで設定してからプライマリ・データベースで設定します。COMPATIBLE初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

手順11   新規ロジカル・スタンバイ・データベースでイベントを監視する

Database Bで行ったすべての変更がロジカル・スタンバイ・データベース(A)に正しく適用されていることを確認するには、手順4でDatabase Aに対して行ったように、DBA_LOGSTDBY_EVENTSビューの問合せを頻繁に行う必要があります。(例12-1を参照)。

変更が行われたためにデータベースAが既存のプライマリ・データベースのコピーとして無効になった場合は、データベースAを破棄し、かわりに新規のロジカル・スタンバイ・データベースを作成できます。詳細は、第4章「ロジカル・スタンバイ・データベースの作成」を参照してください。

手順12   必要な場合は、再度スイッチオーバーを実行する

必要な場合は、データベースAがプライマリ・データベース・ロールで再実行されるように(図12-1を参照)、データベースのスイッチオーバーを再度実行します。

注意:
この時点で、データベースAとデータベースBはいずれも同じバージョンのOracleソフトウェアを実行しているため、8.3.1項で説明した2フェーズ準備済スイッチオーバーを使用します。

12.6 既存のフィジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行

この項の手順では、Oracleソフトウェアのローリング・アップグレードを実行した後に元の構成に戻し、Aがプライマリ・データベース、Bがフィジカル・データベースで、いずれのデータベースもアップグレード後のOracleソフトウェアを実行している状態にする方法について説明します。

注意:
この項の手順では、プライマリ・データベース(A)とフィジカル・スタンバイ・データベース(B)が設定済で、Oracle Databaseリリース11.1以降を使用していることを前提にしています。

表12-3に関係する手順をまとめます。

表12-3 既存のフィジカル・スタンバイを使用したローリング・アップグレードの実行手順

手順

説明

手順1

ローリング・アップグレードのためにプライマリ・データベースを準備する(データベースAでこの手順を実行する)

手順2

フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換する(データベースBでこの手順を実行する)

手順3

ロジカル・スタンバイ・データベースをアップグレードしてプライマリ・データベースと一致させる(データベースBでこの手順を実行する)

手順4

データベースAを保証付きリストア・ポイントにフラッシュバックする(データベースAでこの手順を実行する)

手順5

新しいバージョンのOracleソフトウェアを使用して、データベースBをマウントする

手順6

データベースAをフィジカル・スタンバイに変換する

手順7

データベースAで管理リカバリを開始する

手順8

スイッチオーバーを実行してデータベースAをプライマリ・データベースにする

手順9

データベースAに作成された保証付きリストア・ポイントをクリーンアップする

手順1   ローリング・アップグレードのためにプライマリ・データベースを準備する(データベースAでこの手順を実行する)

1. まだ有効でない場合、フラッシュバック・データベースを有効にします。

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE FLASHBACK ON;
SQL> ALTER DATABASE OPEN;

2. 保証付きリストア・ポイントを作成します。

SQL> CREATE RESTORE POINT pre_upgrade GUARANTEE FLASHBACK DATABASE;

手順2   フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換する(データベースBでこの手順を実行する)

1. 次の点を除き、第4章「ロジカル・スタンバイ・データベースの作成」に記載の手順に従います。4.2.4.1項「ロジカル・スタンバイ・データベースへの変換」では、別なコマンドを使用してロジカル・スタンバイ・データベースの変換を行う必要があります。ALTER DATABASE RECOVER TO LOGICAL STANDBY db_nameのかわりに、次のコマンドを実行します。

SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;
SQL> ALTER DATABASE OPEN;

2. 初めてSQL Applyを実行する場合は、その前に次のアクションを行う必要があります。

1. 次のようにして、ロジカル・スタンバイで外部アーカイブ・ログの自動削除を無効にします。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');

注意:
ロジカル・スタンバイ・データベース(データベースB)で処理されたリモート・アーカイブ・ログは削除しないでください。これらのリモート・アーカイブ・ログは、後でローリング・アップグレード処理の際に必要になります。リカバリ領域を使用してリモート・アーカイブ・ログを格納している場合は、ロジカル・スタンバイ・データベースの通常動作を妨げることなくこれらのログを収容するのに十分な領域があることを確認してください。

2. プライマリ・データベースで実行されていて、ロジカル・スタンバイ・データベースでサポートされないトランザクションに関する情報が取得されていることを確認します。次のプロシージャを実行して情報を取得し、DBA_LOGSTDBY_EVENTS表にイベントとして記録します。

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED', -
> DBMS_LOGSTDBY.MAX_EVENTS);

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');

3. 次のようにして、初めてのSQL Applyを開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

関連項目:

- DBA_LOGSTDBY_EVENTSビューの詳細は、10.5.1項「DBA_LOGSTDBY_EVENTSビューでのイベントのロギングのカスタマイズ」を参照してください。

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

手順3   ロジカル・スタンバイ・データベースをアップグレードしてプライマリ・データベースと一致させる(データベースBでこの手順を実行する)

12.5項「既存のロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行」で説明されているとおり、手順1から8を実行できるようになりました。これらの手順が完了すると、データベースBはアップグレードされたバージョンのOracleソフトウェアを実行するプライマリ・データベースになり、データベースAはロジカル・スタンバイ・データベースになります。

次の手順に進んで、データベースAをデータベースBのフィジカル・スタンバイにします。

手順4   データベースAを保証付きリストア・ポイントにフラッシュバックする(データベースAでこの手順を実行する)

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO RESTORE POINT pre_upgrade;
SQL> SHUTDOWN IMMEDIATE;

手順5   新しいバージョンのOracleソフトウェアを使用して、データベースBをマウントする

この時点で、上位バージョンのOracleソフトウェアを使用できるように、データベースAでOracleバイナリを切り替える必要があります。データベースAはフィジカル・スタンバイに切り替えられており、データベースBによって生成されたREDOデータを適用して自動的にアップグレードされるため、アップグレード・スクリプトは実行しないでください。

次のようにして、データベースAをマウントします。

SQL> STARTUP MOUNT;

手順6   データベースAをフィジカル・スタンバイに変換する

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> SHUTDOWN IMMEDIATE;

手順7   データベースAで管理リカバリを開始する

データベースAは、データベースBにより生成されたREDOデータを適用して、自動的にアップグレードされます。管理リカバリは、プライマリからの新しいインカネーション・ブランチが登録されるまで待機した後、REDOの適用を開始します。

SQL> STARTUP MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE -
>  DISCONNECT FROM SESSION;

注意:
REDO Applyが再開するとき、現行のプライマリ・データベース(データベースB)からの新しいインカネーションが登録されるのを待機します。

手順8   スイッチオーバーを実行してデータベースAをプライマリ・データベースにする

この時点では、Database Bがプライマリ・データベースでDatabase Aがフィジカル・スタンバイで、両方ともOracleソフトウェアの上位バージョンを実行しています。Database Aをプライマリ・データベースにするには、8.2.1項「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」に記載の手順を実行します。

手順9   データベースAに作成された保証付きリストア・ポイントをクリーンアップする

ディスク領域を保持するために、既存の保証付きリストア・ポイントを削除します。

SQL> DROP RESTORE POINT PRE_UPGRADE;

関連項目:
Oracle Maximum Availability Architecture(MAA)のホームページで入手できるベスト・プラクティスに関するホワイト・ペーパー『Database Rolling Upgrade Using Transient Logical Standby: Oracle Data Guard 11g』
http://www.oracle.com/goto/maa

13 Data Guardの使用例

この章では、Data Guard構成の管理中に遭遇する可能性がある例を説明します。使用例はそれぞれ、ユーザー固有の環境に適応できます。表13-1に、この章で説明する使用例を示します。

表13-1 Data Guardの使用例

参照先

使用例

13.1項

フェイルオーバー後のロジカル・スタンバイ・データベースの構成

13.2項

フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換

13.3項

Open Resetlogs文の発行後のフラッシュバック・データベースの使用

13.4項

NOLOGGING句を指定した後のリカバリ

13.5項

OMFまたはOracle ASMを使用するスタンバイ・データベースの作成

13.6項

プライマリ・データベースでの書込みの欠落エラーからのリカバリ

13.7項

Recovery Managerバックアップを使用した障害が発生したプライマリのスタンバイ・データベースへの変換

13.8項

フィジカル・スタンバイの再作成を伴わないプライマリのキャラクタ・セットの変更

13.1 フェイルオーバー後のロジカル・スタンバイ・データベースの構成

この項では、プライマリ・データベースを別のスタンバイ・データベースにフェイルオーバーした後に、ロジカル・スタンバイ・データベースで実行する必要のある手順について説明します。フェイルオーバーの発生後、ロジカル・スタンバイ・データベースは、元のプライマリ・データベースからの最後のREDOが適用されるまで、新規プライマリ・データベースのスタンバイ・データベースとして機能できません。これは、フェイルオーバー中に新規のプライマリ・データベースで最後のREDOが適用される場合と同じです。実行する必要のある手順は、新規プライマリ・データベースがフェイルオーバー前にフィジカル・スタンバイ・データベースであったかロジカル・スタンバイ・データベースであったかに応じて異なります。

- 13.1.1項「新規プライマリ・データベースがフィジカル・スタンバイ・データベースだった場合」

- 13.1.2項「新規プライマリ・データベースがロジカル・スタンバイ・データベースだった場合」

13.1.1 新規プライマリ・データベースがフィジカル・スタンバイ・データベースだった場合

この使用例では、プライマリ・ロールを担う前はフィジカル・スタンバイ・データベースだった新規プライマリ・データベースをサポートするように、ロジカル・スタンバイ・データベースを構成する方法について説明します。この使用例では、SATはロジカル・スタンバイ・データベース、NYCはプライマリ・データベースです。

手順1   ログ・ファイルの自動リカバリを有効化するために、FAL_SERVERパラメータを構成する。

SATデータベースで、次の文を発行します。

SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>';

手順2   ロジカル・スタンバイ・データベースが新規プライマリ・データベースのスタンバイ・データベースとして機能できることを確認する。

PREPARE_FOR_NEW_PRIMARYルーチンをコールして、ローカル・ロジカル・スタンバイを確認し、新しいプライマリを使用して構成する準備をします。この手順の間、データに相違を生じさせるおそれのあるログ・ファイルのローカル・コピーは、ローカル・データベースから削除されます。その後、これらのログ・ファイルは、新しいプライマリ・データベースから直接、再アーカイブが要求されます。

SATデータベースで、次の文を発行します。

SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY( -
>  former_standby_type => 'PHYSICAL' -
>  dblink => 'nyc_link');

注意:
ORA-16109メッセージが戻され、alert.logに「LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required.」という警告が書き込まれる場合は、次の手順を実行します。

1. データベースを警告に示されたSCNまでフラッシュバックします。

2. 続行する前に、この手順を繰り返します。

ロジカル・スタンバイ・データベースをApply SCNまでフラッシュバックする方法の例は、13.2.3項を参照してください。

手順3   SQL Applyを開始する。

SATデータベースで、次の文を発行します。

SQL> START LOGICAL STANDBY APPLY IMMEDIATE;

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

この使用例では、プライマリ・ロールを担う前はロジカル・スタンバイ・データベースだった新規プライマリ・データベースをサポートするように、ロジカル・スタンバイ・データベースを構成する方法について説明します。この使用例では、SATはロジカル・スタンバイ・データベース、NYCはプライマリ・データベースです。

手順1   新規プライマリ・データベースで、ロジカル・スタンバイ・データベースのサポート準備が完了していることを確認する。

NYCデータベースで、次の問合せにより値READYが戻されることを確認します。それ以外の場合、新しいプライマリ・データベースは、ロジカル・スタンバイ・データベースに対するサポートを可能にするために必要な作業を完了していません。次に例を示します。

SQL> SELECT VALUE FROM SYSTEM.LOGSTDBY$PARAMETERS -
>   WHERE NAME = 'REINSTATEMENT_STATUS';

注意:
VALUE列にNOT POSSIBLEが含まれている場合は、新規プライマリ・データベースでロジカル・スタンバイ・データベースを構成できず、データベースを元に戻す必要があることを意味します。

手順2   ログ・ファイルの自動リカバリを有効化するために、FAL_SERVERパラメータを構成する。

SATデータベースで、次の文を発行します。

SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>';

手順3   ロジカル・スタンバイ・データベースが新規プライマリ・データベースのスタンバイ・データベースとして機能できることを確認する。

PREPARE_FOR_NEW_PRIMARYルーチンをコールして、ローカル・ロジカル・スタンバイを確認し、新しいプライマリを使用して構成する準備をします。この手順の間、データに相違を生じさせるおそれのあるログ・ファイルのローカル・コピーは、ローカル・データベースから削除されます。その後、これらのログ・ファイルは、新しいプライマリ・データベースから直接、再アーカイブが要求されます。

SATデータベースで、次の文を発行します。

SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY( -
> former_standby_type => 'LOGICAL' -
> dblink => 'nyc_link');

注意:
ORA-16109メッセージが戻され、alert.logファイルに「LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required.」という警告が書き込まれる場合は、次の手順を実行します。

1. データベースを警告に示されたSCNまでフラッシュバックします。

2. 続行する前に、この手順を繰り返します。

ロジカル・スタンバイ・データベースをApply SCNまでフラッシュバックする方法の例は、13.2.3項を参照してください。

手順4   SQL Applyを開始する。

SATデータベースで、次の文を発行します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY nyc_link;

この文は、常にリアルタイム適用オプションを有効化せずに発行する必要があることに注意してください。ロジカル・スタンバイ・データベースでリアルタイム適用を使用可能にする必要がある場合は、前述の文が正常終了するまで待機してから、次の文を発行します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

13.2 フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換

フェイルオーバーの発生後、元のプライマリ・データベースは、修正され、新しい構成のスタンバイ・データベースとして確立されるまで、Data Guard構成に含められません。これを行うには、フラッシュバック・データベース機能を使用して、障害の発生したプライマリ・データベースを障害発生前の時点にフラッシュバックし、その後新しい構成内のフィジカルまたはロジカル・スタンバイ・データベースに変換します。次の各項で、次の内容を説明します。

- 障害が発生したプライマリ・データベースのフィジカル・スタンバイ・データベースへのフラッシュバック

- 障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへのフラッシュバック

注意:
フェイルオーバー前に、元のプライマリ・データベースでフラッシュバック・データベースが使用可能になっている必要があります。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

関連項目:
失敗したプライマリ・データベースを新しいデータベースとして自動回復する(フラッシュバック・データベースを使用する代わりに)方法は、『Oracle Data Guard Broker』を参照してください。

13.2.1 障害が発生したプライマリ・データベースのフィジカル・スタンバイ・データベースへのフラッシュバック

次の手順では、フィジカル・スタンバイ・データベースに対してフェイルオーバーが実行され、ファイルオーバーの際に古いプライマリ・データベースでフラッシュバック・データベースが使用可能にされていることを前提としています。この手順では、古いプライマリ・データベースをフィジカル・スタンバイ・データベースとしてData Guard構成に戻します。

手順1   古いスタンバイ・データベースがプライマリ・データベースになったSCNを判別する。

新しいプライマリ・データベース上で次の問合せを発行し、古いスタンバイ・データベースが新しいプライマリ・データベースになったSCNを判別します。

SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;

手順2   障害の発生したプライマリ・データベースをフラッシュバックする。

必要に応じて古いプライマリ・データベースを停止し、マウントして、手順1で判別したSTANDBY_BECAME_PRIMARY_SCNの値にフラッシュバックします。

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN standby_became_primary_scn;

手順3   データベースをフィジカル・スタンバイ・データベースに変換する。

古いプライマリ・データベースで次の手順を実行します。

1. 古いプライマリ・データベースで次の文を発行します。

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

制御ファイルからスタンバイ制御ファイルへ正常に変換後、この文はデータベースをマウントしません。

2. データベースを停止して、再開します。

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;

手順4   新しいフィジカル・スタンバイ・データベースへのREDO転送を開始する。

新しいプライマリ・データベースで次の手順を実行します。

1. 次の問合せを発行し、アーカイブ宛先の現在の状態を調べます。

SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, -
> ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;

2. 必要に応じて、宛先を使用可能にします。

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;

3. スタンバイ・データベースが新しいプライマリ・データベースからのREDOデータの受信を確実に開始するよう、ログ・スイッチを実行し、これが成功したことを確認します。次のSQL文を新しいプライマリ・データベースで発行します。

SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION,-
> ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;

新しいスタンバイ・データベースで、REDO転送サービスがREDOデータを別のデータベースに転送しないよう、LOG_ARCHIVE_DEST_n初期化パラメータも変更する必要があります。

手順5   新しいフィジカル・スタンバイ・データベースでREDO Applyを開始する。

次のSQL文を新しいフィジカル・スタンバイ・データベースで発行します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE -
> USING CURRENT LOGFILE DISCONNECT;

REDO Applyは、ロールの推移により生成されるREDOレコードが検出されるたびに自動的に停止するため、新しいプライマリ・データベースがプライマリ・データベースとなったSCNを超えて適用されるまで、1回以上再起動する必要があります。障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の(障害発生前の)ロールに推移できます。詳細は、8.2.1項「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」を参照してください。

13.2.2 障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへのフラッシュバック

次の手順では、Data Guard構成ですでにロジカル・スタンバイ・データベースを使用したフェイルオーバーが実行済で、古いプライマリ・データベースでフラッシュバック・データベースが使用可能にされていることを前提としています。この手順は、新しいプライマリ・データベースから古いプライマリ・データベースを正式にインスタンス化せずに、古いプライマリ・データベースを新しいロジカル・スタンバイ・データベースとしてData Guard構成に戻します。

手順1   フラッシュバックSCNおよびリカバリSCNを判別する。

フラッシュバックSCNは、障害が発生したプライマリ・データベースのフラッシュバック先となるSCNです。リカバリSCNは、障害が発生したプライマリ・データベースのリカバリ先となるSCNです。新しいプライマリで次の問合せを発行し、これらのSCNを特定します。

SQL> SELECT merge_change# AS FLASHBACK_SCN, processed_change# AS RECOVERY_SCN -
> FROM DBA_LOGSTDBY_HISTORY -
> WHERE stream_sequence# = (SELECT MAX(stream_sequence#)-1 -
> FROM DBA_LOGSTDBY_HISTORY);

手順2   障害が発生したプライマリ・データベースを手順1で特定したフラッシュバックSCNまでフラッシュバックする。

SQL> FLASHBACK DATABASE TO SCN flashback_scn;

手順3   障害が発生したプライマリをフィジカル・スタンバイに変換し、リカバリの準備としてスタンバイ・データベースを再度マウントする。

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;

手順4   ログ・ファイルの自動リカバリを有効化するために、FAL_SERVERパラメータを構成する。

フィジカル・スタンバイ(障害の発生したプライマリ)で、次の文を発行します。

SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>';

手順5   不一致のアーカイブ・ログを障害が発生したプライマリ・データベースから削除する。

フェイルオーバー操作以後に作成されたアーカイブ・ログをすべて、障害が発生したプライマリ・データベースから削除します。障害が発生したプライマリ・データベースがスタンバイから分離されていた場合は、現行のプライマリ・データベースと一貫性がない不一致のアーカイブ・ログが存在する可能性があります。これらの不一致のアーカイブ・ログを適用しないようにするには、バックアップおよび高速リカバリ領域から削除する必要があります。次のRecovery Managerコマンドを使用すると、関連アーカイブ・ログを高速リカバリ領域から削除できます。

RMAN> DELETE FORCE ARCHIVELOG FROM SCN ARCHIVE_SCN;

削除されると、これらの不一致のログおよび後続のトランザクションはリカバリできなくなります。

手順6   手順1で特定したリカバリSCNまでリカバリする。

SQL> RECOVER MANAGED STANDBY DATABASE UNTIL CHANGE recovery_scn;

手順7   データベース・ガードを有効にする。

SQL> ALTER DATABASE GUARD ALL;

手順8   フィジカル・スタンバイをアクティブにしてプライマリ・データベースにする。

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

手順9   データベースをオープンする。

SQL> ALTER DATABASE OPEN;

手順10   新しいプライマリへのデータベース・リンクを作成してSQL Applyを開始する。

SQL> CREATE PUBLIC DATABASE LINK mylink -
> CONNECT TO system IDENTIFIED BY password -
> USING 'service_name_of_new_primary_database';

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY mylink;

これで、ロールの可逆的な推移が完了しました。

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

スタンバイ・データベースのメリットの1つは、プライマリ・データベース・サービスに影響を与えずに、スタンバイ・データベースでフラッシュバック・データベースを実行できることです。データベースを特定の時点までフラッシュバックするタスクは簡単ですが、ロジカル・スタンバイ・データベースでは、既知のトランザクションがコミットされる直前の時点までフラッシュバックする操作が必要になる場合があります。このような必要が生じるのは、フェイルオーバー後に新しいプライマリ・データベースを使用してロジカル・スタンバイ・データベースを構成する場合です。

次の手順では、フラッシュバック・データベースとSQL Applyを使用して既知の適用済SCNまでリカバリする方法について説明します。

手順1   プライマリでの既知のSCN(APPLIED_SCN)の特定後に、フラッシュバック操作に使用するためにロジカル・スタンバイ・データベースで次の問合せを発行して対応するSCNを判別する。

SQL> SELECT DBMS_LOGSTDBY.MAP_PRIMARY_SCN (PRIMARY_SCN => APPLIED_SCN) -
> AS TARGET_SCN FROM DUAL;

手順2   戻されたTARGET_SCNまでロジカル・スタンバイをフラッシュバックする。

次のSQL文を発行し、ロジカル・スタンバイ・データベースを指定したSCNまでフラッシュバックし、RESETLOGSオプションを指定してロジカル・スタンバイ・データベースをオープンします。

SQL> SHUTDOWN;
SQL> STARTUP MOUNT EXCLUSIVE;
SQL> FLASHBACK DATABASE TO SCN <TARGET_SCN>;
SQL> ALTER DATABASE OPEN RESETLOGS;

手順3   SQL ApplyがAPPLIED_SCNまで適用されたことを確認する。

次の問合せを発行します。

SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS;

13.3 Open Resetlogs文の発行後のフラッシュバック・データベースの使用

スタンバイ・データベースがリアルタイム適用を使用しているData Guard構成で、プライマリ・データベースでエラーが発生したとします。この場合、同じエラーがスタンバイ・データベースにも適用されます。

ただし、フラッシュバック・データベースが有効化されている場合は、FLASHBACK DATABASEおよびOPEN RESETLOGS文をプライマリ・データベースに対して発行し、同様のFLASHBACK STANDBY DATABASE文をスタンバイ・データベースに発行した後に、適用サービスを再起動することで、プライマリとスタンバイ・データベースをエラー前の状態に戻すことができます。(フラッシュバック・データベースが有効化されていない場合は、プライマリ・エータベースのポイント・イン・タイム・リカバリを実行後、第3章と第4章で説明しているスタンバイ・データベースの再作成が必要です。)

13.3.1 特定時点へのフィジカル・スタンバイ・データベースのフラッシュバック

次の手順では、プライマリ・データベースでOPEN RESETLOGS文を発行した後、フィジカル・スタンバイ・データベースの再作成を回避する方法を説明します。

手順1   RESETLOGS操作が発生した前のSCNを判別する。

プライマリ・データベースで、次の問合せを使用してRESETLOGS操作がプライマリ・データベースで発生したよりも2つ前のシステム変更番号(SCN)の値を取得します。

SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE;

手順2   スタンバイ・データベースの現行のSCNを取得する。

スタンバイ・データベースで、次の問合せを使用して現行のSCNを取得します。

SQL> SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE;

手順3   データベースをフラッシュバックする必要があるかどうかを判別する。

CURRENT_SCNの値がresetlogs_change# - 2の値より大きい場合、次の文を発行してスタンバイ・データベースをフラッシュバックします。

SQL> FLASHBACK STANDBY DATABASE TO SCN resetlogs_change# -2;

- CURRENT_SCNの値がresetlogs_change# - 2の値より小さい場合、手順4に進みます。

- スタンバイ・データベースのSCNがプライマリ・データベースのSCNよりも大幅に遅れており、OPEN RESETLOGS文のREDOの新規ブランチがスタンバイに登録されている場合、適用サービスは、OPEN RESETLOGS文中も停止せずに継続することができます。この場合、適用サービスはREDOデータ内のOPEN RESETLOGS文に到達しても停止しないため、データベースのフラッシュバックは不要です。

手順4   REDO Applyを再起動します。

フィジカル・スタンバイ・データベースでREDO Applyを開始するには、次の文を発行します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE -
> USING CURRENT LOGFILE DISCONNECT;

スタンバイ・データベースはプライマリ・データベースからREDOを受信し、適用できます。

13.3.2 特定時点へのロジカル・スタンバイ・データベースのフラッシュバック

次の手順では、プライマリ・データベースをフラッシュバックし、OPEN RESETLOGS文を発行してオープンした後、ロジカル・スタンバイ・データベースの再作成を回避する方法を説明します。

注意:
SQL Applyは、プライマリ・データベースでリセットログ操作の発生を検出すると、ロジカル・スタンバイ・データベースをフラッシュバックしなくてもマイニングできる場合は、REDOの正しいブランチを自動的にマイニングします。それ以外の場合、SQL Applyは「ORA-1346: 指定されたリセット・ログscnを超えてLogMinerがREDOを処理しました」エラーで停止します。この項では、SQL Applyはこのエラーですでに停止していると仮定しています。

手順1   プライマリ・データベースのSCNを判別する。

プライマリ・データベースで、次の問合せを使用してRESETLOGS操作がプライマリ・データベースで発生したよりも2つ前のシステム変更番号(SCN)の値を取得します。

SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) AS FLASHBACK_SCN FROM V$DATABASE;

手順2   ロジカル・スタンバイでのフラッシュバック操作のターゲットSCNを判別する。

この手順では、PRIMARY_SCNのFLASHBACK_SCN値は手順1から得られたものです。

SQL> SELECT DBMS_LOGSTDBY.MAP_PRIMARY_SCN (PRIMARY_SCN => FLASHBACK_SCN) -
> AS TARGET_SCN FROM DUAL;

手順3   戻されたTARGET_SCNまでロジカル・スタンバイをフラッシュバックする。

次のSQL文を発行し、ロジカル・スタンバイ・データベースを指定したSCNまでフラッシュバックし、RESETLOGSオプションを指定してロジカル・スタンバイ・データベースをオープンします。

SQL> SHUTDOWN;
SQL> STARTUP MOUNT EXCLUSIVE;
SQL> FLASHBACK DATABASE TO SCN <TARGET_SCN>;
SQL> ALTER DATABASE OPEN RESETLOGS;

手順4   SQL Applyが開始される前に、プライマリの新しいブランチからのログ・ファイルが登録されていることを確認する。

プライマリ・データベースで次の問合せを発行します。

SQL> SELECT resetlogs_id FROM V$DATABASE_INCARNATION WHERE status = 'CURRENT';

スタンバイ・データベースで次の問合せを発行します。

SQL> SELECT * FROM DBA_LOGSTDBY_LOG WHERE resetlogs_id = resetlogs_id_at_primary;

1以上の行が返された場合、これは、プライマリの新しいブランチからの登録されたログ・ファイルであることを確認します。

手順5   SQL Applyを開始する。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

13.4 NOLOGGING句を指定した後のリカバリ

いくつかのSQL文で、ユーザーはオプションとしてNOLOGGING句を指定できます。このオプションを指定すると、データベース操作がオンラインREDOログ・ファイルに記録されません。ユーザーがこの句を指定しても、REDOはオンラインREDOログ・ファイルに書き込まれます。ただし、このレコードにはデータが関連付けられていません。これによりスタンバイ・サイトでのログ・アプリケーションまたはデータ・アクセス・エラーが発生し、このログ・ファイルを適用するには手動でのリカバリが必要になることがあります。

注意:
この問題を回避するには、CREATE DATABASEまたはALTER DATABASE文にFORCE LOGGING句を常に指定することをお薦めします。『Oracle Database管理者ガイド』を参照してください。

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

ロジカル・スタンバイ・データベースの場合は、SQL ApplyでNOLOGGING句を使用して対象の表で実行された操作のREDOレコードが検出されると、「ORA-16211: サポートされていないレコードが、アーカイブREDOログで見つかりました。」エラーで停止します。

NOLOGGING句を指定した後のリカバリには、10.5.5項に説明されているように、プライマリ・データベースから1つ以上の表を再作成します。

注意:
通常、NOLOGGING句の使用はお薦めしません。また、プライマリ・データベース内の特定の表でNOLOGGING句を使用する操作が実行されることが事前にわかっている場合は、DBMS_LOGSTDBY.SKIPプロシージャを使用して、これらの表に関連付けられているSQL文をロジカル・スタンバイ・データベースに適用しないようにできます。

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

スタンバイ・サイトにコピーされたアーカイブREDOログ・ファイルがフィジカル・スタンバイ・データベースに適用されると、データファイルの一部が使用不可能となり、リカバリ不能のマークが付けられます。フィジカル・スタンバイ・データベースにフェイルオーバーするか、読取り専用アクセスでスタンバイ・データベースをオープンし、UNRECOVERABLEのマークが付けられたブロックの範囲を読み取ろうとすると、次のようなエラー・メッセージが表示されます。

ORA-01578: ORACLE data block corrupted (file # 1, block # 2521)
ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option

NOLOGGING句が指定された後でリカバリするには、欠落しているREDOデータが含まれているデータファイルをプライマリ・サイトからフィジカル・スタンバイ・サイトにコピーする必要があります。次の手順に従ってください。

手順1   コピーするデータファイルを判別する。

次の手順に従います。

1. プライマリ・データベースを問い合せます。

SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;

NAME                                                  UNRECOVERABLE
----------------------------------------------------- -------------
/oracle/dbs/tbs_1.dbf                                       5216
/oracle/dbs/tbs_2.dbf                                          0
/oracle/dbs/tbs_3.dbf                                          0
/oracle/dbs/tbs_4.dbf                                          0
4 rows selected.

2. スタンバイ・データベースを問い合せます。

SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;

NAME                                                  UNRECOVERABLE
----------------------------------------------------- -------------
/oracle/dbs/stdby/tbs_1.dbf                                 5186
/oracle/dbs/stdby/tbs_2.dbf                                    0
/oracle/dbs/stdby/tbs_3.dbf                                    0
/oracle/dbs/stdby/tbs_4.dbf                                    0
4 rows selected.

3. プライマリ・データベースの問合せ結果とスタンバイ・データベースの問合せ結果を比較します。
両方の問合せ結果のUNRECOVERABLE_CHANGE#列の値を比較します。プライマリ・データベースのUNRECOVERABLE_CHANGE#列の値の方が、スタンバイ・データベースの同じ列の値より大きい場合は、データファイルをプライマリ・サイトからスタンバイ・サイトへコピーする必要があります。

この例では、tbs_1.dbfデータファイルのプライマリ・データベースにあるUNRECOVERABLE_CHANGE#の値の方が大きいため、tbs_1.dbfデータファイルをスタンバイ・サイトへコピーする必要があります。

手順2   プライマリ・サイトで、スタンバイ・サイトにコピーする必要があるデータファイルのバックアップを作成する。

次のSQL文を発行します。

SQL> ALTER TABLESPACE system BEGIN BACKUP;
SQL> EXIT;

必要なデータファイルをローカル・ディレクトリにコピーします。

SQL> ALTER TABLESPACE system END BACKUP;

手順3   データファイルをスタンバイ・データベースにコピーする。

欠落しているREDOデータが含まれているデータファイルを、プライマリ・サイトからリカバリ関連のファイルが格納されているフィジカル・スタンバイ・サイトにコピーします。

手順4   スタンバイ・データベースで、REDO Applyを再開します。

次のSQL文を発行します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

REDO Applyを再開しようとすると、次のエラー・メッセージが(通常アラート・ログに)表示されることがあります。

ORA-00308: cannot open archived log 'standby1'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf'

ORA-00308エラーが表示され、REDO Applyが自動的に終了しない場合は、別の端末のウィンドウから次のSQL文を発行して、リカバリを取り消すことができます。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

これらのエラー・メッセージは、アーカイブ・ギャップ内にある1つ以上のログ・ファイルが正常に適用されなかった場合に戻されます。これらのエラーを受け取った場合は、ギャップを手動で解決し、手順4を繰り返します。アーカイブ・ギャップの手動による解決方法の詳細は、6.4.3.1項を参照してください。

13.4.3 リカバリ不能処理後にバックアップが必要かどうかの判断

プライマリ・データベースでリカバリ不能な操作を実行した場合は、次の手順に従って新しいバックアップ操作が必要かどうかを判断します。

1. プライマリ・データベースでV$DATAFILEビューの問合せを行い、Oracleデータベースが最新の無効なREDOデータを生成したシステム変更番号(SCN)または時刻を特定します。

2. プライマリ・データベースで次のSQL文を発行して、新たにバックアップを実行する必要があるかどうかを判断します。

SQL> SELECT UNRECOVERABLE_CHANGE#,-
> TO_CHAR(UNRECOVERABLE_TIME, 'mm-dd-yyyy hh:mi:ss') -
> FROM   V$DATAFILE;

3. 前の手順での問合せで、データファイルが最後にバックアップされた時刻より後のデータファイル・リカバリ不能時刻が報告された場合は、問題となっているデータファイルのバックアップを新たに作成します。

V$DATAFILEビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

13.5 OMFまたはOracle ASMを使用するスタンバイ・データベースの作成

第3章および第4章 では、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの作成方法を説明しました。この項では、プライマリ・データベースでOracle Managed Files(OMF)またはOracle Automatic Storage Management(Oracle ASM)を使用する場合に実行する必要のある追加手順を説明し、これらの章を補完します。

注意:
この項の説明は、読者がすでにフィジカル・スタンバイ・データベースの作成方法を理解しており、Recovery Manager、OMFおよびOracle ASM機能に習熟していることを前提としています。詳細は、次の資料を参照してください。

- フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの作成方法の詳細は、第3章、第4章および付録Eを参照してください。

- OMFおよびOracle ASMの詳細は、『Oracle Database管理者ガイド』を参照してください。

- RMANの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』および『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

スタンバイ・データベースを作成する前に、次の準備作業を実行します。

1. プライマリ・データベースで強制ロギングを使用可能にします。

2. プライマリ・データベースでアーカイブを使用可能にします。

3. プライマリ・データベースで必要な初期化パラメータをすべて設定します。

4. スタンバイ・データベース用に初期化パラメータ・ファイルを作成します。

5. プライマリ・データベースがOMFを使用するよう構成されている場合、スタンバイ・データベースもOMFを使用するよう構成することをお薦めします。これを行うには、DB_CREATE_FILE_DESTおよびDB_CREATE_ONLINE_LOG_DEST_n初期化パラメータに適切な値を設定します。プライマリおよびスタンバイ・データベースの両方で同じディスク・グループ名が使用されている場合、メンテナンスや後のロールの推移が簡易化されます。

注意:
スタンバイにOMFパラメータが設定されている場合は、そのスタンバイの新しいファイルはプライマリでの作成方法とは関係なく、常にOMFとして作成されます。したがって、DB_FILE_NAME_CONVERTおよびDB_CREATE_FILE_DESTパラメータの両方がスタンバイに設定されている場合は、DB_CREATE_FILE_DESTパラメータが優先されます。

6. STANDBY_FILE_MANAGEMENT初期化パラメータにAUTOを設定します。

7. スタンバイ・データベースに接続するために、必要に応じてOracle Netを構成します。

8. REDO転送の認証を構成します。詳細は、3.1.2項「REDO転送の認証の構成」を参照してください。

9. 制御ファイルをマウントせずにスタンバイ・データベース・インスタンスを起動します。

スタンバイ・データベースを作成するには、次の作業を実行します。

1. スタンバイ・データベースでOracle ASMを使用する場合、スタンバイ・データベース・システムにOracle ASMインスタンスが存在していなければ、インスタンスを作成します。

2. Recovery ManagerのBACKUPコマンドを使用して、プライマリ・データベースのデータファイル、アーカイブ・ログ・ファイルおよびスタンバイ制御ファイルのコピーが含まれているバックアップ・セットを作成します。

3. Recovery ManagerのDUPLICATE FOR STANDBYコマンドを使用して、バックアップ・セットのデータファイル、アーカイブREDOログ・ファイルおよびスタンバイ制御ファイルをスタンバイ・データベースの格納場所にコピーします。
DUPLICATE FOR STANDBYコマンドは、スタンバイ・インスタンスで実際のデータ移動を実行します。バックアップ・セットがテープ上にある場合、スタンバイ・インスタンスがバックアップ・セットを読み取れるように、メディア・マネージャを構成しておく必要があります。バックアップ・セットがディスク上にある場合は、NFSでプライマリ・パス名を使用できるようにするか、スタンバイ・システムにコピーしてRMANのCATALOG BACKUPPIECEコマンドを使用し、バックアップ・ピースをカタログに追加してからリストアを行うことで、スタンバイ・インスタンスがバックアップ・ピースを読み取れるようにする必要があります。

これらの手順を完了した後、3.2.7項の手順を実行してフィジカル・スタンバイ・データベースの構成を確認します。

ロジカル・スタンバイ・データベースを作成するには、第4章で説明されているスタンバイ・データベースの作成プロセスを実行しますが、次の点を変更します。

1. ロジカル・スタンバイ・データベースの場合、DB_CREATE_FILE_DESTパラメータを設定しても、OMFファイル名を強制的に作成しません。ただし、このパラメータをプライマリ・データベースで設定する場合、スタンバイ・データベースでも設定する必要があります。

2. プライマリ・システムでロジカル・スタンバイ制御ファイルを作成した後、このファイルをスタンバイ・システムにコピーするために、オペレーティング・システムのコマンドを使用しないでください。かわりにRecovery ManagerのRESTORE CONTROLFILEコマンドを使用して、ロジカル・スタンバイ制御ファイルのコピーをスタンバイ・システムにリストアします。

3. プライマリ・データベースでOMFファイルを使用する場合、スタンバイ・データベースに作成された新しいOMFファイルをスタンバイ・データベース制御ファイルが使用するよう、Recovery Managerを使用してスタンバイ・データベース制御ファイルを更新します。この操作を実行するには、次の例に示すように、スタンバイ・データベースにのみ接続します。

> RMAN TARGET sys@lstdby

target database Password: password

RMAN> CATALOG START WITH '+stby_diskgroup';
RMAN> SWITCH DATABASE TO COPY;

これらの手順を完了した後、4.2.5項の手順を実行してロジカル・スタンバイ・データベースの起動、リカバリおよび検証を行います。

13.6 プライマリ・データベースでの書込みの欠落エラーからのリカバリ

Data Guard構成でのメディア・リカバリの実行中に、フィジカル・スタンバイ・データベースを使用してプライマリ・データベースで書込みの欠落によるデータ破損エラーを検出できます。これは、プライマリ・データベースのREDOログに格納されているブロックのSCNをフィジカル・スタンバイ・データベースのブロックのSCNと比較して行います。プライマリ・データベースのブロックのSCNがスタンバイ・データベースのSCNよりも小さい場合は、プライマリ・データベースで書込みの欠落が発生しています。

そのような状況で、書込み欠落の検出(DB_LOST_WRITE_PROTECT初期化パラメータで設定)がプライマリとスタンバイ両方のレベルで有効な場合、スタンバイでリカバリを試行するとORA-752エラーになります。書込み欠落の検出が有効でない場合、リカバリを試行するとORA-600 [3020]エラーになります。ただし、ORA-600 [3020]エラーがすべて、プライマリにおける書込み欠落に起因するとはかぎりません。したがって、この項で説明するガイドラインに従う前にOracle Supportの担当者と協力し、ORA-600 [3020]エラーの根本原因が本当に、プライマリで発生した書込みの欠落なのかどうかを判断する必要があります。My Oracle Supportのノート1265884.1 (http://support.oracle.com)の『Resolving ORA-752 or ORA-600 [3020] During Standby Recovery』も参照してください。

注意:
書込み欠落のエラーはプライマリによってブロックがキャッシュに読み取られた後、対応するREDOをスタンバイのブロックと比較した場合にのみ検出されるので、プライマリおよびスタンバイの両方で読取りや検証がまだ行われていない未検出ブロックが存在している可能性があります。古いブロックを読み取るまでに問合せや更新のためにスタンバイ上で使用したブロックのうち、現在適用しているREDOのSCNまでの全ブロックはスタンバイによる検証済なので、古いブロックが現行のデータベース操作に影響を及ぼすことはありません。

プライマリの書込みの欠落エラーがスタンバイで検出されると、失効したブロックごとに次のようなブロック・エラー・メッセージが1つ以上スタンバイ・データベースのアラート・ファイルに出力されます。

Tue Dec 12 19:09:48 2006
STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASE
LOST A DISK WRITE OF BLOCK 26, FILE 7
NO REDO AT OR AFTER SCN 389667 CAN BE USED FOR RECOVERY.
.
.
.

次に、アラート・ファイルは、ORA-00752エラーがスタンバイ・データベースに発生し、管理リカバリが取り消されたことを示します。

Slave exiting with ORA-752 exception
Errors in file /oracle/log/diag/rdbms/dgstwrite2/stwrite2/trace/stwrite2_pr00_23532.trc:
ORA-00752: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 7, block# 26)
ORA-10564: tablespace TBS_2
ORA-01110: data file 7: '/oracle/dbs/btbs_21.f'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 57503
.
.
.

次に、スタンバイ・データベースは、アラート・ファイルに出力されたSCN時点で、このエラーによるデータファイルの破損がない、一貫した状態にリカバリされます。

Recovery interrupted!
Recovered data files to a consistent state at change 389569

この最後のメッセージは、アラート・ファイルのかなり後の方に表示されることがあり、ブロック・エラー・メッセージより小さいSCNの場合もあります。また、プライマリ・データベースは、すでにデータファイルに破損があってもエラーが表示されずに動作している場合があります。

このようなエラーからリカバリするための推奨手順は、次の手順に示すように、フィジカル・スタンバイにフェイルオーバーします。

プライマリで書込みの欠落が検出された後のフィジカル・スタンバイへのフェイルオーバーの手順

1. プライマリ・データベースを停止します。ブロック・エラー・メッセージに出力されたSCN以降のデータがすべて消失します。

2. スタンバイ・データベースで次のSQL文を発行してプライマリに変換します。

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

Database altered.

Tue Dec 12 19:15:23 2006
alter database activate standby database
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE (stwrite2)
RESETLOGS after incomplete recovery UNTIL CHANGE 389569
Resetting resetlogs activation ID 612657558 (0x24846996)
Online log /oracle/dbs/bt_log1.f: Thread 1 Group 1 was previously cleared
Online log /oracle/dbs/bt_log2.f: Thread 1 Group 2 was previously cleared
Standby became primary SCN: 389567
Tue Dec 12 19:15:23 2006
Setting recovery target incarnation to 3
Converting standby mount to primary mount.
ACTIVATE STANDBY: Complete - Database mounted as primary (stwrite2)
Completed: alter database activate standby database

3. 新しいプライマリのバックアップを行います。データベースの完全なバックアップ・コピーがなければ、フェイルオーバー後の変更をリカバリすることができないので、バックアップをすぐに実行することは安全策として必要な作業です。フェイルオーバーを行うと元のプライマリ・データベースはData Guard構成に含まれなくなり、その他のすべてのスタンバイ・データベースが新しいプライマリ・データベースからREDOデータの受信と適用を行うようになります。

4. 新しいプライマリ・データベースをオープンします。

5. オプションの手順として、失敗したプライマリをフィジカル・スタンバイとして再作成します。これは手順3で新しいプライマリで作成したデータベース・バックアップを使用して実行します。(この場合は、フラッシュバック・データベースまたはData Guardブローカを使用して、元のプライマリ・データベースを回復することはできません。)
新しいプライマリから作成したバックアップを使用して作成したフィジカル・スタンバイは、古いスタンバイと同じデータファイルを保持することに注意してください。そのため、新しいスタンバイでは同じブロックを比較するので、古いスタンバイがアクティブ化される前に存在していた未検出の書込みの欠落は、新しいスタンバイによって検出されません。プライマリまたはスタンバイで発生した新しい書込みの欠落はすべての検出されます。

関連項目:
書込み欠落の検出有効化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

13.7 Recovery Managerバックアップを使用した障害が発生したプライマリのスタンバイ・データベースへの変換

障害が発生したプライマリ・データベースを変換するには、プライマリでフラッシュバック・データベース機能を有効にし、13.2.1項または13.2.2項で説明した手順に従うことをお薦めします。これらの項の手順では、障害が発生したプライマリをフィジカル・スタンバイまたはロジカル・スタンバイに変換する最も速い方法を説明しています。しかし、障害が発生したプライマリでフラッシュバック・データベースが無効になっている場合でも、次の項で説明するように、障害が発生したプライマリのローカル・バックアップを使用して、障害が発生したプライマリをフィジカル・スタンバイまたはロジカル・スタンバイに変換できます。

- Recovery Managerバックアップを使用した、障害が発生したプライマリのフィジカル・スタンバイへの変換

- Recovery Managerバックアップを使用した障害が発生したプライマリのロジカル・スタンバイへの変換

13.7.1 Recovery Managerバックアップを使用した、障害が発生したプライマリのフィジカル・スタンバイへの変換

この項の手順では、Recovery Managerバックアップを使用して障害が発生したプライマリをフィジカル・スタンバイに変換する方法を説明します。この手順には、古いプライマリのCOMPATIBLE初期化パラメータが11.0.0以上に設定されている必要があります。

手順1   古いスタンバイ・データベースがプライマリ・データベースになったSCNを判別する。

新しいプライマリ・データベース上で次の問合せを発行し、古いスタンバイ・データベースが新しいプライマリ・データベースになったSCNを判別します。

SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;

手順2   データベース全体をリストアおよびリカバリする。

スタンバイが新しいプライマリになったSCN(standby_became_primary_scn)に古いプライマリが到達する前に作成したバックアップを使用して、データベースをリストアします。次に、Point-in-Timeリカバリを実行して、古いプライマリをそれと同じ時点までリカバリします。

次のRecovery Managerコマンドを発行します。

RMAN> RUN
{
SET UNTIL SCN <standby_became_primary_scn + 1>;
RESTORE DATABASE;
RECOVER DATABASE;
}

ユーザー管理リカバリでは、先にデータベースを手動でリストアできます。通常、フェイルオーバー前の、数時間を要したバックアップは古くなっています。そのため、障害が発生したプライマリは次のコマンドを使用してリカバリできます。

SQL> RECOVER DATABASE USIING BACKUP CONTROLFILE UNTIL CHANGE -
>  <standby_became_primary_scn + 1>;

フラッシュバック・データベースを使用する再インスタンス化とは異なり、この手順ではstandby_became_primary_scnに1を加算します。データファイルの場合、SCNまでフラッシュバックすることは、そのSCNに1を加算するまでリカバリすることと同義です。

手順3   データベースをフィジカル・スタンバイ・データベースに変換する。

古いプライマリ・データベースで次の手順を実行します。

1. 古いプライマリ・データベースで次の文を発行します。

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

制御ファイルからスタンバイ制御ファイルへ正常に変換後、この文はデータベースをマウントしません。

2. データベースを停止して、再開します。

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;

手順4   データベースを読取り専用でオープンする。

次のコマンドを発行します。

SQL> ALTER DATABASE OPEN READ ONLY;

この手順の目的は、ディクショナリ・チェックを使用して制御ファイルをデータベースと同期させることです。このコマンドの後に、ディクショナリ・チェックで示されたアクションがないかアラート・ログをチェックします。通常、フェイルオーバー中に古いプライマリがデータファイルを追加または削除している途中でなければ、ユーザー・アクションは必要ありません。

手順5   (オプション)必要に応じて、スタンバイを再度マウントする。

Active Data Guardオプション用にライセンスを購入しているときに、フィジカル・スタンバイ・データベースをアクティブ問合せモードで使用する場合は、この手順をスキップします。それ以外の場合は、スタンバイ・データベースをMOUNT状態にします。

次に例を示します。

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;

手順6   新しいフィジカル・スタンバイ・データベースへのREDO転送を再開する。

新しいスタンバイ・データベースの作成前に、新しいプライマリ・データベースは、リモート宛先へのREDOの転送を停止しているはずです。REDO転送サービスを再開するには、新しいプライマリ・データベースで次の手順を実行します。

1. 次の問合せを発行し、アーカイブ宛先の現在の状態を調べます。

SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, -
> ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;

2. 必要に応じて、宛先を使用可能にします。

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;

3. スタンバイ・データベースが新しいプライマリ・データベースからのREDOデータの受信を確実に開始するよう、ログ・スイッチを実行し、これが成功したことを確認します。

注意:
これは、新しいプライマリに続いて、古いプライマリが新しいスタンバイになるために重要な手順です。この手順が実行されないと、古いプライマリは誤ったデータベース・ブランチにリカバリされます。問題を修正する唯一の方法は、古いプライマリを再度変換することです。

SQLプロンプトで次の文を入力します。

SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, -
> ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;

新しいスタンバイ・データベースで、REDO転送サービスがREDOデータを別のデータベースに転送しないよう、LOG_ARCHIVE_DEST_n初期化パラメータも変更する必要があります。1つのサーバー・パラメータ・ファイル(SPFILE)でプライマリおよびスタンバイ・データベース・ロールの両方がVALID_FOR属性で設定されている場合、この手順を実行する必要はありません。これにより、Data Guard構成は、ロールの推移後も正しく動作します。

手順7   REDO Applyを開始します。

次のようにして、新しいフィジカル・スタンバイ・データベースでREDO Applyを開始します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE -
> USING CURRENT LOGFILE DISCONNECT;

障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の(障害発生前の)ロールに推移できます。詳細は、8.2.1項「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」を参照してください。

13.7.2 Recovery Managerバックアップを使用した障害が発生したプライマリのロジカル・スタンバイへの変換

この項の手順では、Recovery Managerバックアップを使用して障害が発生したプライマリをロジカル・スタンバイに変換する方法を説明します。

手順1   障害が発生したプライマリ・データベースのリカバリ先SCNを判別する。

新しいプライマリ・データベースで次の問合せを発行し、障害が発生したプライマリ・データベースをリカバリするSCNを判別します。

SQL> SELECT APPLIED_SCN RECOVERY_SCN FROM V$LOGSTDBY_PROGRESS;

また、新しいプライマリ・データベースで、次のようにして、アーカイブ・ログの処理に使用するSCNを判別します。

1. すべてのスタンバイREDOログを必ずアーカイブしておきます。次の問合せを発行し、戻されるREADYの値を検索します。データベースのサイズおよびアーカイブする必要があるログの数によって、READYのステータスが戻されるまでしばらく時間がかかることがあります。

SQL> SELECT VALUE FROM SYSTEM.LOGSTDBY$PARAMETERS -
> WHERE NAME='REINSTATEMENT_STATUS';

2. READYのステータスが戻されたら、次の問合せを実行し、このリカバリの一環としてアーカイブ・ログの処理のためのSCNを取得します。

SQL> SELECT VALUE ARCHIVE_SCN FROM SYSTEM.LOGSTDBY$PARAMETERS -
> WHERE NAME='STANDBY_BECAME_PRIMARY_SCN';

手順2   不一致のアーカイブ・ログを障害が発生したプライマリ・データベースから削除する。

フェイルオーバー操作以後に作成されたアーカイブ・ログをすべて、障害が発生したプライマリ・データベースから削除します。障害が発生したプライマリ・データベースがスタンバイから分離されていた場合は、現行のプライマリ・データベースと一貫性がない不一致のアーカイブ・ログが存在する可能性があります。これらの不一致のアーカイブ・ログを適用しないようにするには、バックアップおよび高速リカバリ領域から削除する必要があります。次のRecovery Managerコマンドを使用すると、関連アーカイブ・ログを高速リカバリ領域から削除できます。

RMAN> DELETE ARCHIVELOG FROM SCN ARCHIVE_SCN;

削除されると、これらの不一致のログおよび後続のトランザクションはリカバリできなくなります。

手順3   障害が発生したプライマリ・データベースにコピーするログ・ファイルを判別する。

新しいプライマリ・データベースで、次の問合せを発行し、バックアップからリカバリする前に、障害が発生したプライマリ・データベースにコピーする必要があるログ・ファイルの最小セットを判別します。

SQL> SELECT file_name FROM DBA_LOGSTDBY_LOG WHERE next_change# > ARCHIVE_SCN;

必要なスタンバイ・ログを取得し、バックアップ・セットを新しいスタンバイにコピーして新しい高速フラッシュ・リカバリ領域にリストアします。これらのログはスタンバイREDOログから得られるため、スタンバイの標準アーカイブの一部ではありません。Recovery Managerユーティリティでは、部分的なファイル名を使用して正しい場所からファイルを取得できます。

次に、Recovery ManagerのBACKUPコマンドの使用例を示します。

RMAN> BACKUP AS COPY DEVICE TYPE DISK FORMAT '/tmp/test/%U'
> ARCHIVELOG LIKE '<partial file names from above>%';

次に、Recovery ManagerのRESTOREコマンドの使用例を示します。

RMAN> CATALOG START WITH '/tmp/test';
RMAN> RESTORE ARCHIVELOG FROM SEQUENCE 33 UNTIL SEQUENCE 35;

手順4   バックアップをリストアしてデータベースをリカバリする。

元のプライマリの全データファイルのバックアップをリストアし、RECOVERY_SCN + 1までリカバリします。現行の制御ファイルを利用することをお薦めします。

1. データベースを制限モードで起動して、データベースのオープン後にGUARD ALLコマンドが発行されるまでローグ・トランザクションから保護します。

2. バックアップを使用して障害が発生したプライマリ・データベースのデータファイルをリストアします。

3. フラッシュバック・データベースが有効な場合は、無効にします(USING BACKUP CONTROLFILE句に必要)。

4. SQL*Plusで、RECOVERY_SCN +1までPoint-in-Timeリカバリを実行します。

現行の制御ファイルを使用してもバックアップ制御ファイルを使用しても、USING BACKUP CONTROLFILE 句を指定してリストアされるアーカイブ・ログを指すことができるようにする必要があります。指定しないと、リカバリ・プロセスでは、手順3で取得したログではなく、オンラインREDOログへのアクセスが試行されることがあります。手順3で取得した順序の入力を求められた場合は、次のようにリストアされるアーカイブ・ログのコピーのファイル名を指定します。

SQL> RECOVER DATABASE UNTIL CHANGE RECOVERY_SCN + 1 USING BACKUP CONTROLFILE;

手順5   RESETLOGSオプションでデータベースをオープンする。

SQL> ALTER DATABASE OPEN RESETLOGS;

手順6   データベース・ガードを有効にする

SQL> ALTER DATABASE GUARD ALL;

手順7   新しいプライマリ・データベースへのデータベース・リンクを作成してSQL Applyを開始する。

SQL> CREATE PUBLIC DATABASE LINK myLink -
> CONNECT TO SYSTEM IDENTIFIED BY password -
> USING 'service name of new primary database';

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY myLink;

この時点で、制限セッション(ALTER SYSTEM DISABLE RESTRICTED SESSION)を無効にできます。つまり、データベースを再起動して手順4.3のフラッシュバックを再度有効にする必要がある場合は、RESTRICTED SESSIONをオフにして再起動します。

13.8 フィジカル・スタンバイの再作成を伴わないプライマリのキャラクタ・セットの変更

Oracle Data Guardでは、構成内のフィジカル・スタンバイ・データベースを再作成することなく、プライマリ・データベースのデータベース・キャラクタ・セットと各国語キャラクタ・セットの両方を変更できます。プライマリ・データベースのキャラクタ・セット変換の実行中に、中断を最小限に抑えて、フィジカル・スタンバイ・データベースを使用し続けることができます。

実際の変換を行う前に、いくつかのプロシージャを実行する必要があります。変換には、プライマリ・データベースを停止して、制限モードでオープンし、CSALTERスクリプトを実行する必要があります。システム・データとユーザー・データはどちらも新しいキャラクタ・セットに変換されます。

このプロセスに必要な手順の詳細は、http://support.oracle.comにあるMy Oracle Support Note 1124165.1を参照してください。Note 260192.1も読む必要があります。

注意:
廃止されたALTER DATABASE CHARACTER SET SQL文と同様に、CSALTERスクリプトはシステム管理者のみが使用するものです。システム管理者は、CSALTERを実行するための適切な条件があることを確認するために、データベース・キャラクタ・セット・スキャナをまず実行する必要があります。また、CSALTERを実行する前には、データベースをバックアップする必要があります。

関連項目:
キャラクタ・セットを移行するためのCSALTERスクリプトの使用についての一般的な情報は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

第II部

参照先

この部では、Oracle Data Guardのスタンバイ・データベースの特長について参考となる資料を提供します。さらに詳しい資料は、Oracle Database 10gのドキュメント・セットを参照してください。

この部は、次の章で構成されています。

- 第14章「初期化パラメータ」

- 第15章「LOG_ARCHIVE_DEST_nパラメータの属性」

- 第16章「Data Guardに関連するSQL文」

- 第17章「Oracle Data Guardに関連するビュー」

14 初期化パラメータ

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

表14-1に初期化パラメータと、そのパラメータがプライマリ・データベース・ロール、スタンバイ・データベース・ロール、あるいはその両方のいずれに適用されるかを示します。また、これらのパラメータをData Guard環境で設定する場合の固有の注意点および推奨事項も記載します。『Oracle Databaseリファレンス』には、ALTER SYSTEM SET文の発行(たとえばALTER SYSTEM SET LOG_ARCHIVE_TRACEなど)、または初期化パラメータ・ファイルの編集による初期化パラメータの更新方法を含む、完全な初期化パラメータ情報が記載されています。初期化パラメータの設定方法の詳細は、オペレーティング・システム固有のOracleマニュアルを参照してください。

表14-1 Data Guard構成内のインスタンスの初期化パラメータ

パラメータ

適用可能先

注意点および推奨事項

COMPATIBLE = release_number

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

スイッチオーバーを実行すると思われる場合は、同じ値をプライマリ・データベースおよびスタンバイ・データベースに指定します。値が異なる場合は、REDO転送サービスがREDOデータをプライマリ・データベースからスタンバイ・データベースに転送できない可能性があります。3.2.3項の例を参照してください。

ロジカル・スタンバイ・データベースは、スイッチオーバーがないと思われる場合、プライマリ・データベースよりCOMPATIBLEの設定が大きくなる可能性があります。

SQL Applyを使用したローリング・アップグレードの場合は、このパラメータを12.4項「ロジカル・スタンバイ・データベースの新規作成によるローリング・アップグレードの実行」で説明したガイドラインに従って設定します。

CONTROL_FILE_RECORD_KEEP_TIME = number_of_days

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

オプション。このパラメータを使用して、指定された日数(0から365)内に、制御ファイル内(アーカイブREDOログ・ファイルなどの必要な情報が含まれている)の再使用可能レコードが上書きされないようにします。

CONTROL_FILES = 'control_file_name', 'control_file_name', '...'

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

必須。1つ以上の制御ファイルのパス名とファイル名を指定します。制御ファイルはすでにデータベースに存在している必要があります。2つの制御ファイルを使用することをお薦めします。現行の制御ファイルの別のコピーが存在していれば、問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後、容易にインスタンスを再開できます。3.2.3項の例を参照してください。

DB_FILE_NAME_CONVERT = 'location_of_primary_database_datafile','location_of_standby_database_datafile'

フィジカル・スタンバイ

スナップショット・スタンバイ

スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはデータファイルが格納されているスタンバイ・システムのディレクトリがプライマリ・システムと異なる場合は必須。このパラメータには、文字列をペアで指定する必要があります。最初の文字列は、プライマリ・データベース・ファイル名の中で検索される文字列です。その文字列が一致すると、スタンバイ・データベース・ファイル名を構成する2番目の文字列に置き換えられます。複数のペアのファイル名を指定できます。例3-1も参照してください。

DB_UNIQUE_NAME = データベースの一意の名前

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

LOG_ARCHIVE_CONFIGパラメータの指定時には必須のもので、それ以外の場合も推奨されます。このデータベースの一意の名前を指定します。この名前はプライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。DB_UNIQUE_NAMEパラメータは、DB_NAMEパラメータ値にデフォルト設定されます。

FAL_CLIENT = Oracle_Net_service_name

フィジカル・スタンバイ

スナップショット・スタンバイ

このパラメータは必要なくなりました。設定されていない場合、フェッチ・アーカイブ・ログ(FAL)サーバーは、クライアントのDB_UNIQUE_NAMEに対応するLOG_ARCHIVE_DEST_nパラメータからクライアントのネットワーク・アドレスを取得します。

FAL_SERVER = Oracle_Net_service_name

フィジカル・スタンバイ

スナップショット・スタンバイ

欠落しているアーカイブREDOログ・ファイルをこのスタンバイ・データベースがフェッチ(要求)できるフェッチ元データベースのOracle Netサービス名を1つ以上指定します。

INSTANCE_NAME

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

オプション。このパラメータが定義されており、プライマリ・データベースとスタンバイ・データベースが同じホストに存在する場合は、スタンバイ・データベースに対してプライマリ・データベースとは異なる名前を指定します。3.2.3項の例を参照してください。

LOG_ARCHIVE_CONFIG ='DG_CONFIG ( db_unique_name, db_unique_name, ... )'

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

強く推奨いたします。Data Guard機能をすべて有効化するには、このパラメータのDG_CONFIG属性をData Guard構成で明示的に設定する必要があります。構成内の各データベース名のDB_UNIQUE_NAMEを含み、各名前がカンマで区切られたテキスト文字列にDG_CONFIGを設定します。

LOG_ARCHIVE_DEST_n = {LOCATION=path_name | SERVICE=service_name, attribute, attribute, ...}

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

必須。最大30(ここでn = 1, 2, 3, ...31)の宛先を定義します。それぞれがLOCATIONまたはSERVICE属性を指定する必要があります。各LOG_ARCHIVE_DEST_nパラメータに対し、それぞれ対応するLOG_ARCHIVE_DEST_STATE_nパラメータを指定します。

LOG_ARCHIVE_DEST_STATE_n = {ENABLE|DEFER|ALTERNATE}

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

必須。LOG_ARCHIVE_DEST_STATE_nパラメータを指定して、指定された(または代替の)宛先へのREDO転送サービスによるREDOデータの転送を有効または無効に設定します。各LOG_ARCHIVE_DEST_nパラメータに対し、LOG_ARCHIVE_DEST_STATE_nパラメータを定義します。第15章も参照してください。

LOG_ARCHIVE_FORMAT=log%d_%t_%s_%r.arc

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

LOG_ARCHIVE_FORMATおよびLOG_ARCHIVE_DEST_nパラメータが連結され、データベースに完全修飾されたアーカイブREDOログ・ファイル名が生成されます。

LOG_ARCHIVE_LOCAL_FIRST = {TRUE | FALSE}

プライマリ

スナップショット・スタンバイ

このパラメータは非推奨であり、下位互換性のためにのみ保持されています。このパラメータを明示的に設定する場合は、TRUEにのみ設定することをお薦めします。

LOG_ARCHIVE_MAX_PROCESSES =integer

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

オプション。Oracleソフトウェアが最初に起動するアーカイバ(ARCn)プロセスの数(1から30)を指定します。デフォルト値は4です。

LOG_ARCHIVE_MIN_SUCCEED_DEST

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

オプション。このパラメータは、ログ・ファイル・グループを再使用する前にアーカイブする必要のあるローカルまたはリモートの必須の宛先、またはローカルのオプションの宛先の数を指定します。

LOG_ARCHIVE_TRACE=integer

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

オプション。スタンバイ・サイトへのREDOデータの転送をトレースするには、このパラメータを設定します。有効な整数値は、付録Fを参照してください。

LOG_FILE_NAME_CONVERT = 'location_of_primary_database_redo_logs','location_of_standby_database_redo_logs'

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはログ・ファイルが存在するスタンバイ・サイトのディレクトリ構造がプライマリ・サイトと異なる場合は必須。このパラメータは、プライマリ・データベースのオンラインREDOログ・ファイルのパス名をスタンバイ・データベースのパス名に変換します。3.2.3項の例を参照してください。

REMOTE_LOGIN_PASSWORDFILE = {EXCLUSIVE|SHARED}

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

オペレーティング・システムの認証を管理ユーザーに使用する場合およびSSLをREDO転送の認証に使用する場合はオプション。それ以外の場合は、Data Guard構成内の各データベースに対して、EXCLUSIVEまたはSHAREDに設定する必要があります。

SHARED_POOL_SIZE = bytes

プライマリ

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

オプション。オンラインREDOログ・ファイルから読み込んだ情報を処理するSystem Global Area(SGA)の指定に使用します。使用可能なSGAが大きいと、処理できる情報量も大きくなります。

STANDBY_ARCHIVE_DEST = filespec

ロジカル・スタンバイ

フィジカル・スタンバイ

スナップショット・スタンバイ

このパラメータは非推奨であり、下位互換性のためにのみ保持されています。

STANDBY_FILE_MANAGEMENT = {AUTO | MANUAL}

プライマリ

フィジカル・スタンバイ

スナップショット・スタンバイ

STANDBY_FILE_MANAGEMENTパラメータをAUTOに設定し、データファイルをプライマリ・データベースに追加、またはプライマリ・データベースから削除すると、手動操作なしで該当する変更内容がスタンバイ・データベースにも反映されるようにします。プライマリ・データベースとスタンバイ・データベースのディレクトリ構造が異なる場合は、DB_FILE_NAME_CONVERT初期化パラメータも設定して、プライマリ・データベースのデータファイルの1つ以上のセットのファイル名を(フィジカル)スタンバイ・データベースのファイル名に変換する必要があります。詳細および例は、例3-1を参照してください。

15 LOG_ARCHIVE_DEST_nパラメータの属性

この章では、LOG_ARCHIVE_DEST_n初期化パラメータ(nは1から31の整数)の属性のリファレンス情報を提供します。パラメータの属性には次のものがあります。

- AFFIRMおよびNOAFFIRM

- ALTERNATE(LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31ではサポートされない)

- COMPRESSION

- DB_UNIQUE_NAME

- DELAY

- LOCATIONおよびSERVICE(LOCATIONはLOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31ではサポートされない)

- MANDATORY(LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31ではサポートされない)

- MAX_CONNECTIONS

- MAX_FAILURE

- NET_TIMEOUT

- NOREGISTER

- REOPEN

- SYNCおよびASYNC(SYNCはLOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31ではサポートされない)

- TEMPLATE

- VALID_FOR

使用方法

- Data Guard構成の各データベースは、通常、オンラインおよびスタンバイREDOログのアーカイブ用のLOCATION属性を持つ宛先を1つと、構成にあるその他のデータベース用のREMOTE属性を持つ宛先を1つ持ちます。

- 構成されている場合、LOG_ARCHIVE_DEST_1からLOG_ARCHIVE_DEST_10の各宛先には、ローカル・ディスクのディレクトリまたはリモートからアクセスするデータベースを指定する、LOCATIONまたはSERVICE属性が含まれている必要があります。LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31の各宛先にはSERVICE属性が含まれている必要があります。
他の属性はすべてオプションです。

- LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31を、ALTERNATE REDO転送先として指定することはできません。

- LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31は、COMPATIBLE初期化パラメータが11.2.0.0以上に設定されている場合のみ使用できます。

注意:
LOG_ARCHIVE_DEST_n初期化パラメータの複数の属性が非推奨になりました。これらの属性は下位互換用にサポートされており、『Oracle Databaseリファレンス』で説明しています。

関連項目:
LOG_ARCHIVE_DEST_n宛先を定義してREDO転送サービスを設定する方法の詳細は、第6章を参照してください。

AFFIRMおよびNOAFFIRM

REDO転送先で受信したREDOデータをスタンバイREDOログに書き込む前に確認するか、後に確認するかを制御します。

- AFFIRM: REDO転送先で受信したREDOデータをスタンバイREDOログに書き込んだ後に確認するように指定します。

- NOAFFIRM: REDO転送先で受信したREDOデータをスタンバイREDOログに書き込む前に確認するように指定します。

カテゴリ

AFFIRM

NOAFFIRM

データ型

キーワード

キーワード

有効な値

該当なし

該当なし

デフォルト値

該当なし

該当なし

必須属性

SERVICE

SERVICE

属性との競合

NOAFFIRM

AFFIRM

対応先

V$ARCHIVE_DESTビューのAFFIRM列

V$ARCHIVE_DESTビューのAFFIRM列

使用方法

- AFFIRM属性およびNOAFFIRM属性が指定されていない場合、デフォルトは、SYNC属性が指定されているときはAFFIRM、ASYNC属性が指定されているときはNOAFFIRMです。

- SYNC属性を使用しないAFFIRM属性の指定は非推奨であり、今後のリリースではサポートされません。

関連項目:
SYNCおよびASYNC属性

例

次の例は、リモート宛先のAFFIRM属性を示しています。

LOG_ARCHIVE_DEST_3='SERVICE=stby1 SYNC AFFIRM'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

ALTERNATE

元のアーカイブ先で障害が発生したときに使用する代替アーカイブ先を指定します。

カテゴリ

ALTERNATE=LOG_ARCHIVE_DEST_n

データ型

文字列

有効な値

LOG_ARCHIVE_DEST_n宛先。nは1から10の値です。

デフォルト値

なし。代替宛先が指定されていない場合、REDO転送サービスでは自動的に別のアーカイブ先に変更されません。

必須属性

該当なし

属性との競合

なし脚注 1

対応先

V$ARCHIVE_DESTビューのALTERNATEおよびSTATUS列

脚注 1 REOPEN属性が0(ゼロ)ではない値で指定されている場合、ALTERNATE属性は無視されます。MAX_FAILURE属性に0(ゼロ)ではない値が指定され、障害件数が指定した障害しきい値を超過する場合は、ALTERNATE宛先が有効になります。このため、ALTERNATE属性は0(ゼロ)ではないREOPEN属性値と競合しません。

使用方法

- LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31を、代替REDO転送先として指定することはできません。

- ALTERNATE属性はオプションです。代替宛先が指定されていない場合、元のアーカイブ先に障害が発生しても、REDO転送サービスでは自動的に別のアーカイブ先に変更されません。

- 指定できる代替宛先はLOG_ARCHIVE_DEST_nパラメータごとに1つのみですが、複数の有効なアーカイブ先で同じ代替アーカイブ先を共有できます。

- 代替アーカイブ先に次のいずれかを指定することが理想的です。

- 同じローカル・スタンバイ・データベース・システム上の異なるディスクの場所(例15-1を参照)

- 同じスタンバイ・データベース・システムへの異なるネットワーク・ルート(例15-2を参照)

- 有効なアーカイブ先を厳密に反映するリモート・スタンバイ・データベース・システム

- 有効化された宛先が代替宛先を参照していない場合は、代替宛先を自動的に有効化する方法はないので、代替宛先は保留になることを意味しています。ただし、ALTER SYSTEMを使用して実行時に代替宛先を有効化することができます。

- 代替宛先に指定できる宛先には、次の制限事項があります。

- ローカルの必須の宛先を少なくとも1つは有効にする。

- 有効な宛先数は、LOG_ARCHIVE_MIN_SUCCEED_DESTパラメータでの定義と一致させる必要がある。

- 宛先をそれ自身の代替先にすることはできない。

- 有効な宛先数を増加させると、利用可能な代替アーカイブ先の数が減少します。

- 宛先に障害がある場合、次のアーカイブ操作で代替宛先が有効化されます。アーカイブ操作中に代替宛先を有効化するには処理済のブロックを再度読み取る必要があるので、これはサポートされていません。これはREOPEN属性の動作と同一です。

- REOPEN属性が0(ゼロ)ではない値で指定されている場合、MAX_FAILURE属性が0(ゼロ)ではない値で指定されていなければALTERNATE属性は無視されます。MAX_FAILURE属性とREOPEN属性の値が0(ゼロ)ではない場合は、障害件数が指定の障害しきい値を超過すると、ALTERNATE宛先が有効になります。このため、ALTERNATE属性は0(ゼロ)ではないREOPEN属性値と競合しません。

例

例15-1のサンプル初期化パラメータ・ファイルでは、エラーが発生したり、デバイスがいっぱいになった場合、LOG_ARCHIVE_DEST_1は、代替宛先であるLOG_ARCHIVE_DEST_2へのフェイルオーバーを次回のアーカイブ操作で自動的に実行します。

例15-1 代替アーカイブ先への自動フェイルオーバー

LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY MAX_FAILURE=1
ALTERNATE=LOG_ARCHIVE_DEST_2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY'
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE

この例と次の例の両方では、MAX_FAILURE属性を指定してする必要があります。この指定を行わなかった場合、問題が発生しても代替宛先へのフェイルオーバーが行われません。MAX_FAILUREにはデフォルト値はないので、値を指定する必要があります。

例15-2 同じスタンバイ・データベースに対する代替Oracle Netサービス名の定義

この例は、同じスタンバイ・データベースに代替Oracle Netサービス名を定義する方法を示しています。

LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY MAX_FAILURE=1'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='SERVICE=stby1_path1 ALTERNATE=LOG_ARCHIVE_DEST_3'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=stby1_path2'
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE

COMPRESSION

COMPRESSION属性は、REDOデータをREDO転送先に転送する前に圧縮するかどうかを指定するために使用します。

注意:
REDO転送の圧縮は、Oracle Advanced Compressionオプションの機能です。REDO転送の圧縮機能を使用する前に、このオプションのライセンスを購入する必要があります。

カテゴリ

COMPRESSION=ENABLEまたはDISABLE

データ型

ブール

有効な値

ENABLEまたはDISABLE

デフォルト値

DISABLE

必須属性

なし

属性との競合

なし

対応先

V$ARCHIVE_DESTビューのCOMPRESSION列

使用方法

- COMPRESSION属性はオプションです。指定されていない場合、デフォルトの圧縮動作はDISABLEです。

例

次の例は、COMPRESSION属性が指定されているLOG_ARCHIVE_DEST_nパラメータを示しています。

LOG_ARCHIVE_DEST_3='SERVICE=denver SYNC COMPRESSION=ENABLE'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

DB_UNIQUE_NAME

この宛先にあるデータベースの一意の名前を指定します。

カテゴリ

DB_UNIQUE_NAME=name

データ型

文字列

有効な値

nameは、DB_UNIQUE_NAMEパラメータを使用してこのデータベースに定義された値と一致している必要があります。

デフォルト値

なし

必須属性

なし

属性との競合

なし

対応先

V$ARCHIVE_DESTビューのDB_UNIQUE_NAME列

使用方法

- この属性は、次の場合にはオプションです。

- LOG_ARCHIVE_CONFIG=DG_CONFIG初期化パラメータが指定されていない場合。

- これがローカル宛先(LOCATION属性で指定)の場合。

- この属性が必須となるのは、LOG_ARCHIVE_CONFIG=DG_CONFIG初期化パラメータが指定されており、かつ、これがリモート宛先(SERVICE属性で指定)の場合です。

- プライマリ・データベースとスタンバイ・データベースの関係を明確に識別するには、DB_UNIQUE_NAME属性を使用します。この属性は、Data Guard構成に複数のスタンバイ・データベースが存在する場合に特に有用です。

- DB_UNIQUE_NAMEで指定する名前は、DG_CONFIGリストのDB_UNIQUE_NAME値の1つと一致している必要があります。REDO転送サービスにより、指定された宛先のデータベースのDB_UNIQUE_NAME属性がDB_UNIQUE_NAME属性と一致していること、またはその宛先への接続が拒否されていることが検証されます。

- DB_UNIQUE_NAME属性で指定する名前は、宛先で識別されるデータベースのDB_UNIQUE_NAME初期化パラメータで指定されている名前と一致している必要があります。

例

次の例では、DB_UNIQUE_NAMEパラメータではboston(DB_UNIQUE_NAME=boston)が指定されており、これはLOG_ARCHIVE_DEST_1パラメータのDB_UNIQUE_NAME属性にも指定されています。LOG_ARCHIVE_DEST_2パラメータのDB_UNIQUE_NAME属性は、宛先としてchicagoを指定しています。bostonとchicagoは、どちらもLOG_ARCHIVE_CONFIG=DG_CONFIGパラメータにリストされています。

DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2='SERVICE=Sales_DR
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'

DELAY

スタンバイ・サイトでプライマリ・サイトからのREDOデータがアーカイブされてから、スタンバイ・データベースまたはそこからカスケードされたスタンバイにアーカイブREDOログ・ファイルが適用されるまでの最小タイム・ラグを指定します。

カテゴリ

DELAY[=minutes]

データ型

数値

有効な値

0分以上

デフォルト値

30分

必須属性

SERVICE

属性との競合

LOCATION, VALID_FOR=(*,STANDBY_ROLE)

対応先

V$ARCHIVE_DESTビューのDELAY_MINSおよびDESTINATION列

使用方法

- DELAY属性はオプションです。デフォルトでは、遅延は発生しません。

- DELAY属性は、スタンバイ宛先のアーカイブREDOログ・ファイルが、指定した時間が経過するまでリカバリに利用されないことを示します。時間間隔は分で表され、転送されたREDOデータがスタンバイ・サイトに正常に到達した時点から計測されます。

- DELAY属性を使用すると、破損したプライマリ・データまたは誤ったプライマリ・データからスタンバイ・データベースを保護できます。ただし、フェイルオーバー中は、破損が発生した時点までのすべてのREDOを適用するための所要時間が長くなるため、トレードオフを伴います。

- DELAY属性は、REDOデータのスタンバイ宛先への転送に影響しません。

- リアルタイム適用が使用可能になっている場合、設定した遅延は無視されます。

- DELAY属性の変更は、次にREDOデータをアーカイブすると(ログ・スイッチ後に)有効になります。進行中のアーカイブ操作には、影響しません。

- 指定した遅延間隔は、スタンバイ・サイトで次のように上書きできます。

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

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

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

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

- カスケードされたスタンバイが使用するDELAY値は、カスケードしているスタンバイにREDOを送信したプライマリのLOG_ARCHIVE_DEST_nパラメータに設定された値です。

関連項目:
これらのALTER DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

例

DELAY属性を使用すれば、プライマリ・データベースと様々なレベルで同期させる複数のスタンバイ・データベースを維持する構成を設定できます。ただし、REDO Applyで破損時点までのすべてのREDOを適用するまでにかかる時間が長くなるため、フェイルオーバー中は、この保護はなんらかのオーバーヘッドを伴います。

たとえば、プライマリ・データベースAにスタンバイ・データベースBおよびCがあると仮定します。スタンバイ・データベースBは障害時リカバリ・データベースとして設定されているため、タイム・ラグはありません。スタンバイ・データベースCには2時間の遅延が設定されています。2時間あれば、スタンバイ・データベースに伝播する前に、ユーザー・エラーを検出できます。

次の例は、この構成用にDELAY属性を指定する方法を示しています。

LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='SERVICE=stbyB SYNC AFFIRM'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=stbyC DELAY=120'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

注意:
または、十分なフラッシュバック・ログ・データがあれば、フラッシュバック・データベースを使用して、データベースを障害発生時点または他のデータベース・インカネーションのSCNまで戻すこともできます。フラッシュバック・データベースの使用については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』で説明しています。

LOCATIONおよびSERVICE

各宛先にはLOCATION属性またはSERVICE属性を指定して、REDO転送サービスがローカル・ディスクのディレクトリまたはリモート・データベースの宛先のどちらにREDOデータを転送できるかを明示する必要があります。

LOG_ARCHIVE_DEST_1からLOG_ARCHIVE_DEST_10の宛先は、LOCATION属性またはSERVICE属性を含むことができます。

LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31の宛先は、SERVICE属性しか含むことができません。

カテゴリ

LOCATION=local_disk_directoryまたはUSE_DB_RECOVERY_FILE_DEST

SERVICE=net_service_name

データ型

文字列値

文字列値

有効な値

該当なし

該当なし

デフォルト値

なし

なし

必須属性

該当なし

該当なし

属性との競合

SERVICE, DELAY, NOREGISTER, SYNC, ASYNC, NET_TIMEOUT, AFFIRM,NOAFFIRM, COMPRESSION, MAX_CONNECTIONS

LOCATION

対応先

V$ARCHIVE_DESTビューのDESTINATIONおよびTARGET列

V$ARCHIVE_DESTビューのDESTINATIONおよびTARGET列

使用方法

- LOCATIONまたはSERVICE属性を指定する必要があります。デフォルトはありません。

- LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31パラメータでは、LOCATION属性はサポートされません。

- 複数の属性を指定している場合は、属性のリストの最初にLOCATION属性またはSERVICE属性を指定します。

- LOCATION属性で少なくとも1つのローカル・ディスクのディレクトリを指定する必要があります。これにより、データベースのメディア・リカバリが必要な場合は、ローカルのアーカイブREDOログ・ファイルに確実にアクセスできるようになります。ローカルまたはリモートの追加宛先は最大30個まで指定できます。

- LOCATION属性には、次のいずれかを指定できます。

- LOCATION=local_disk_directory
これは、データベースを置くシステム上のディスク・ディレクトリの一意のディレクトリ・パス名を指定します。これは、アーカイブREDOログ・ファイルのローカル宛先です。

- LOCATION=USE_DB_RECOVERY_FILE_DEST
高速リカバリ領域を構成するには、DB_RECOVERY_FILE_DEST初期化パラメータを使用して、高速リカバリ領域として機能するディレクトリまたはOracle Storage Managerのディスク・グループを指定します。高速リカバリ領域の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- SERVICE属性を指定する場合は、次のようにします。

- SERVICE属性と、REDOデータの送信先となるリモートOracleデータベース・インスタンスを識別する有効なOracle Netサービス名(SERVICE=net_service_name)を指定して、リモート宛先を識別します。
SERVICE属性で指定するOracle Netサービス名は、リモート・データベースへの接続に必要な情報を含む接続記述子に変換されます。

関連項目:
Oracle Netサービス名の設定の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- リモート宛先にREDOデータを転送するには、着信するアーカイブREDOデータを受け取るために、ネットワーク接続と、リモート宛先に対応付けられたOracleデータベース・インスタンスが必要です。

- LOCATIONおよびSERVICE属性の現行の設定を確認するには、V$ARCHIVE_DEST固定ビューを問い合せます。

- TARGET列は、宛先がプライマリ・データベースにとってローカルかリモートかを示します。

- DESTINATION列は、宛先に指定されている値を示します。たとえば、宛先パラメータ値は、アーカイブREDOログ・ファイルが配置されているリモートのOracleインスタンスを示すOracle Netサービス名を指定します。

例

例1   LOCATION属性の指定

LOG_ARCHIVE_DEST_2='LOCATION=/disk1/oracle/oradata/payroll/arch/'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

例2   SERVICE属性の指定

LOG_ARCHIVE_DEST_3='SERVICE=stby1'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

MANDATORY

いっぱいになったオンライン・ログ・ファイルが再利用可能になるには、宛先へのアーカイブが成功する必要があることを指定します。

カテゴリ

MANDATORY

データ型

キーワード

有効な値

該当なし

デフォルト値

該当なし

必須属性

該当なし

属性との競合

オプション

対応先

V$ARCHIVE_DESTビューのBINDING列

使用方法

- LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31パラメータでは、MANDATORY属性はサポートされません。

- MANDATORYが指定されていない場合、デフォルトでは、宛先はオプションとみなされます。
すべての宛先がオプションである場合にも、最低1つの宛先は成功する必要があります。オプションの宛先へのアーカイブが失敗した場合、オンラインREDOログ・ファイルは再利用可能なままで、最終的に上書きされる可能性があります。しかし、必須の宛先へのアーカイブ操作が失敗した場合、オンラインREDOログ・ファイルは上書きされません。

- LOG_ARCHIVE_MIN_SUCCEED_DEST=nパラメータ(nは1から10の整数)は、オンラインREDOログ・ファイルを上書きできるようになる前に、正常にアーカイブしておく必要がある宛先の数を指定します。
LOG_ARCHIVE_MIN_SUCCEED_DEST=nの件数は、すべてのMANDATORYの宛先とオプションのローカル宛先によって満たされます。LOG_ARCHIVE_MIN_SUCCEED_DESTパラメータに設定した値が一致すると、オンラインREDOログ・ファイルは再利用可能になります。たとえば、次のようにパラメータを設定できます。

# Database must archive to at least two locations before
# overwriting the online redo log files.
LOG_ARCHIVE_MIN_SUCCEED_DEST = 2

- 1つ以上のローカル宛先が必要であり、それらにMANDATORYを宣言するか、またはオプションのままにしておくことができます。
LOG_ARCHIVE_MIN_SUCCEED_DESTパラメータの最小値は1のため、最低1つのローカル宛先が操作上必須です。

- 必須の宛先のいずれかに障害が発生すると、LOG_ARCHIVE_MIN_SUCCEED_DESTパラメータは不適切になります。

- LOG_ARCHIVE_MIN_SUCCEED_DESTパラメータ値を、必須の宛先数にオプションのローカル宛先数を加えた数よりも大きく設定することはできません。

- V$ARCHIVE_DEST固定ビューのBINDING列は、アーカイブ操作に障害がどのように影響するのかを指定します。

例

次の例は、MANDATORY属性を示しています。

LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=denver MANDATORY'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

MAX_CONNECTIONS属性

アーカイブREDOログ・ファイルをREDO転送先に送信する際に、複数のネットワーク接続を使用できるようにします。複数のネットワーク接続を使用すると、待機時間が長いネットワーク・リンクを介したREDO転送のパフォーマンスを向上させることができます。

カテゴリ

説明

データ型

整数

有効な値

1から20

デフォルト値

1

必須属性

なし

属性との競合

なし

対応先

プライマリ・データベースのV$ARCHIVE_DESTビューのMAX_CONNECTIONS列

使用方法

- MAX_CONNECTIONS属性はオプションです。指定した場合は、REDO転送サービスでARCnプロセスをアーカイブに使用する場合にのみ使用されます。

- MAX_CONNECTIONSを1(デフォルト)に設定すると、REDO転送サービスでは、1つのARCnプロセスを使用してリモート宛先にREDOデータを転送します。

- MAX_CONNECTIONSを1より大きな値に設定すると、REDO転送サービスでは、複数のARCnプロセスを使用してリモート宛先のアーカイブREDOログ・ファイルにパラレルでREDOを転送します。各アーカイバ(ARCn)プロセスでは、個別のネットワーク接続を使用します。

- 複数のARCnプロセスを使用すると、REDO転送はパラレルで行われるため、REDOがリモート宛先に転送される速度は向上します。

- ARCnプロセスから受信するREDOは、アーカイブREDOログ・ファイルに直接書き込まれます。したがって、受信時にリアルタイムで適用できません。

- 常に使用されているアーカイバ・プロセスの実際の数は、アーカイバのワークロードおよびLOG_ARCHIVE_MAX_PROCESSES初期化パラメータの値によって異なります。たとえば、すべての宛先のMAX_CONNECTIONS属性の合計がLOG_ARCHIVE_MAX_PROCESSESの値を超えている場合、Data Guardではできるだけ多数のARCnプロセスが使用されますが、その数はMAX_CONNECTIONS属性に指定されている値より少ない場合があります。

- 複数のARCnプロセスをOracle RAC環境で使用する場合は、REDOデータをシングル・スタンバイ・データベース・インスタンスに転送するように、プライマリ・インスタンスを構成します。このようにREDO転送を構成しておかなかった場合、アーカイブ操作がリモート・アーカイブへのデフォルト動作に戻り、シングルARCnプロセスを使用してREDOデータの転送を行います。

例

次の例は、MAX_CONNECTIONS属性を示しています。

LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=denver MAX_CONNECTIONS=3'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

MAX_FAILURE

プライマリ・データベースが失敗した宛先を放棄する前に、REDO転送サービスが通信を再確立してその宛先へのREDOデータを転送する連続試行回数を制御します。

カテゴリ

MAX_FAILURE=count

データ型

数値

有効な値

>=0

デフォルト値

なし

必須属性

REOPEN

属性との競合

なし

対応先

V$ARCHIVE_DESTビューのMAX_FAILURE、FAILURE_COUNTおよびREOPEN_SECS列

使用方法

- MAX_FAILURE属性はオプションです。デフォルトでは、失敗した宛先に対するアーカイブの試行回数に制限はありません。

- この属性は、失敗後に回数制限付きでREDOデータの転送を再試行するように、宛先に対する障害の解決方法を指定するときに役立ちます。

- MAX_FAILURE属性を指定した場合は、REOPEN属性も設定する必要があります。指定した連続試行回数を超過すると、その宛先はREOPEN属性が指定されていないものとして処理されます。

- V$ARCHIVE_DEST固定ビューのFAILURE_COUNT列で障害件数を確認できます。関連するREOPEN_SECS列は、REOPEN属性値を示します。

注意:
宛先の障害件数が、指定したMAX_FAILURE属性の値に達した場合、その宛先を再利用するには、MAX_FAILURE属性値または他の属性を修正する必要があります。この結果、障害件数がゼロ(0)にリセットされます。

- ALTER SYSTEM SET文によって宛先が変更されると、障害件数は0(ゼロ)にリセットされます。このため、現在の障害件数の値よりも小さな値にMAX_FAILURE属性を設定する問題が回避されます。

- 障害件数がMAX_FAILURE属性に設定された値以上になると、REOPEN属性値は暗黙的に0(ゼロ)に設定されます。これによって、REDO転送サービスは、次のアーカイブ操作ではREDOデータを代替宛先(ALTERNATE属性で指定)に転送するようになります。

- MAX_FAILURE属性を指定せずに(またはMAX_FAILURE=0を指定し)、REOPEN属性に0(ゼロ)ではない値を指定すると、REDO転送サービスは、失敗した宛先に対して無制限にアーカイブを試行します。宛先がMANDATORY属性を持つ場合、オンラインREDOログ・ファイルはこの宛先にアーカイブされるまで再利用できません。

例

次の例は、REDO転送サービスが、宛先arc_destに対して、アーカイブ操作を連続最高3回、5秒ごとに試行できる指定を示しています。3回目の試行後、アーカイブ操作に失敗すると、その宛先はREOPEN属性が指定されていないものとして扱われます。

LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3'
LOG_ARCHIVE_DEST_STATE_1=ENABLE

NET_TIMEOUT

LGWRバックグラウンド・プロセスが、REDO転送先に送信されたREDOデータの確認待ちをブロックする時間を秒数で指定します。確認がNET_TIMEOUTの秒数内に受信されない場合は、エラーがログに記録され、その宛先へのREDO転送セッションは終了します。

カテゴリ

NET_TIMEOUT=seconds

データ型

数値

有効な値

1脚注 1 から1200

デフォルト値

30秒

必須属性

SYNC

属性との競合

ASYNC(ASYNC属性を指定しても、REDO転送サービスでは無視され、エラーは戻されません。)

対応先

プライマリ・データベースのV$ARCHIVE_DESTビューのNET_TIMEOUT列

脚注 1 最小値は1秒に設定できますが、一時的なネットワーク・エラーによるスタンバイ・データベースからの切断を回避するために、最小値は8から10秒に設定することをお薦めします。

使用方法

- NET_TIMEOUT属性はオプションです。ただし、NET_TIMEOUT属性を指定しないと30秒に設定されますが、プライマリ・データベースが停止する可能性があります。この状況を回避するには、NET_TIMEOUT属性に0(ゼロ)以外の小さい値を指定することによって、ネットワーク・サーバーからのステータスを待機する際、ユーザーが指定したタイムアウト時間の期限が切れた後に、プライマリ・データベースが操作を続行できます。

例

次の例は、NET_TIMEOUT属性を使用して、プライマリ・データベースのネットワーク・タイムアウト値を10秒に指定する方法を示しています。

LOG_ARCHIVE_DEST_2='SERVICE=stby1 SYNC NET_TIMEOUT=10'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

NOREGISTER

アーカイブREDOログ・ファイルの位置が、対応する宛先に記録されてはいけないことを示します。

カテゴリ

NOREGISTER

データ型

キーワード

有効な値

該当なし

デフォルト値

該当なし

必須属性

SERVICE

属性との競合

LOCATION

対応先

V$ARCHIVE_DESTビューのDESTINATIONおよびTARGET列

使用方法

- NOREGISTER属性は、スタンバイ・データベースの宛先がData Guard構成の一部である場合はオプションです。

- NOREGISTER属性は、宛先がData Guard構成の一部でない場合は必須です。

- これは、リモートの宛先のみの属性です。各アーカイブREDOログ・ファイルの位置は、常にプライマリ・データベースの制御ファイルに記録されます。

例

次の例は、NOREGISTER属性を示しています。

LOG_ARCHIVE_DEST_5='NOREGISTER'

REOPEN

REDO転送サービスが失敗した宛先の再オープンを試行するまでの最小秒数を指定します。

カテゴリ

REOPEN [=seconds]

データ型

数値

有効な値

0秒以上

デフォルト値

300秒

必須属性

なし

属性との競合

該当なし

対応先

V$ARCHIVE_DESTビューのREOPEN_SECSおよびMAX_FAILURE列

使用方法

- REOPEN属性はオプションです。

- REDO転送サービスは、失敗した宛先の再オープンをログ・スイッチ時に試行します。

- REDO転送サービスは、最後のエラーの時刻にREOPEN間隔を加算した時刻が現在の時刻に達していないかどうかをチェックします。達していない場合、REDO転送サービスは宛先の再オープンを試行します。

- REOPENは、接続障害のみでなく、すべてのエラーに適用されます。エラーには、ネットワーク障害、ディスク・エラー、クオータ例外などがありますが、これらに制限されません。

- オプションの宛先にREOPENを指定すると、エラーが発生した場合にOracleデータベースでオンラインREDOログ・ファイルを上書きできます。MANDATORY宛先にREOPENを指定すると、REDO転送サービスは、REDOデータを正常に転送できない場合にプライマリ・データベースを停止します。この場合には、次のオプションを考慮します。

- 宛先を遅延させる、宛先をOPTIONALとして指定する、またはSERVICE属性値を変更することで宛先を変更。

- 代替宛先の指定。

- 宛先の無効化。

例

次の例は、REOPEN属性を示しています。

LOG_ARCHIVE_DEST_3='SERVICE=stby1 MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

SYNCおよびASYNC

使用するREDO転送モードが同期(SYNC)なのか、非同期(ASYNC)なのかを指定します。

カテゴリ

SYNC

ASYNC

データ型

キーワード

キーワード

有効な値

該当なし

該当なし

デフォルト値

該当なし

なし

必須属性

なし

なし

属性との競合

ASYNC、LOCATION

SYNC、LOCATION

対応先

V$ARCHIVE_DESTビューのTRANSMIT_MODE列

V$ARCHIVE_DESTビューのTRANSMIT_MODE列

使用方法

- LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31パラメータでは、SYNC属性はサポートされません。

- トランザクションをコミットするには、SYNC属性が指定されている使用可能な各宛先で、そのトランザクションによって生成されたREDOデータを受信しておく必要があります。

- トランザクションをコミットするのに、ASYNC属性が指定されている宛先で、そのトランザクションによって生成されたREDOデータを受信しておく必要はありません。これは、SYNCおよびASYNCがいずれも指定されていない場合のデフォルトの動作です。

例

次の例は、SYNC属性が指定されているLOG_ARCHIVE_DEST_nパラメータを示しています。

LOG_ARCHIVE_DEST_3='SERVICE=stby1 SYNC'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

TEMPLATE

宛先でアーカイブされたREDOログの名前について、ディレクトリ仕様と書式テンプレートを定義します。このテンプレートは、REDO宛先のLOG_ARCHIVE_FORMAT初期化パラメータにより定義されたデフォルトのファイル名書式とは異なるファイル名を生成するために使用されます。

カテゴリ

TEMPLATE=filename_template_%t_%s_%r

データ型

文字列値

有効な値

該当なし

デフォルト値

なし

必須属性...

SERVICE

属性との競合...

LOCATION

対応先...

V$ARCHIVE_DESTビューのREMOTE_TEMPLATEおよびREGISTER列

使用方法

- TEMPLATE属性はオプションです。TEMPLATEが指定されていない場合、アーカイブされたREDOログには、LOG_ARCHIVE_FORMAT初期化パラメータの値を使用して名前が付けられます。

- TEMPLATE属性は、リモート・アーカイブ先でLOG_ARCHIVE_FORMAT初期化パラメータ設定をオーバーライドします。

- TEMPLATE属性は、リモート宛先(つまり、SERVICE属性で指定された宛先)でのみ有効です。

- 表15-1で説明されているとおり、filename_templateに指定した値には、%s、%t、および%rディレクティブが必要です。

表15-1 TEMPLATE属性のディレクティブ

ディレクティブ

説明

%t

インスタンス・スレッド番号を置換します。

%T

0(ゼロ)を埋め込んだインスタンス・スレッド番号を置換します。

%s

ログ・ファイル順序番号を置換します。

%S

0(ゼロ)を埋め込んだログ・ファイル順序番号を置換します。

%r

リセットログIDを置換します。

%R

0(ゼロ)を埋め込んだリセットログIDを置換します。

- filename_template値は宛先に送信され、そこでファイル名を作成する前に、変換および検証されます。

VALID_FOR

次の要因に基づき、REDOデータを宛先に書き込むかどうかを指定します。

- データベースがプライマリ・ロールとスタンバイ・ロールのどちらで現在実行されているか

- オンラインREDOログ・ファイルまたはスタンバイREDOログ・ファイル(あるいはその両方)が、現在この宛先のデータベースでアーカイブされているかどうか

カテゴリ

VALID_FOR=(redo_log_type, database_role)

データ型

文字列値

有効な値

該当なし

デフォルト値

VALID_FOR=(ALL_LOGFILES, ALL_ROLES)

必須属性

なし

属性との競合

なし

対応先

V$ARCHIVE_DESTビューのVALID_NOW、VALID_TYPEおよびVALID_ROLE列

使用方法

- VALID_FOR属性はオプションです。ただし、Data Guard構成内の各データベースでREDO転送先ごとにVALID_FOR属性を指定し、構成内のスタンバイ・データベースへのロール推移後もREDO転送が続行されるようにすることをお薦めします。

- LOG_ARCHIVE_DEST_n宛先ごとにこれらの要因を構成するには、キーワードのペア(VALID_FOR=(redo_log_type,database_role))を使用してこの属性を指定します。

- redo_log_typeキーワードは、次のいずれかをアーカイブする場合に有効な宛先を識別します。

- ONLINE_LOGFILE: この宛先は、オンラインREDOログ・ファイルをアーカイブする場合のみ有効です。

- STANDBY_LOGFILE: この宛先は、スタンバイREDOログ・ファイルをアーカイブする場合のみ有効です。

- ALL_LOGFILES: この宛先は、オンラインREDOログ・ファイルまたはスタンバイREDOログ・ファイルをアーカイブする場合に有効です。

- database_roleキーワードは、この宛先がアーカイブに有効なロールを識別します。

- PRIMARY_ROLE: この宛先は、データベースがプライマリ・ロールで実行されている場合のみ有効です。

- STANDBY_ROLE: この宛先は、データベースがスタンバイ・ロールで実行されている場合のみ有効です。

- ALL_ROLES: この宛先は、データベースがプライマリ・ロールまたはスタンバイ・ロールで実行されている場合に有効です。

- 宛先にVALID_FOR属性を指定しないと、データベースがプライマリ・ロールまたはスタンバイ・ロールで稼働しているかどうかに関係なく、デフォルトで、オンラインREDOログ・ファイルとスタンバイREDOログ・ファイルのアーカイブが宛先で有効になります。このデフォルトの動作は、VALID_FOR属性で(ALL_LOGFILES,ALL_ROLES)キーワード・ペアを設定した場合と同様です。

- VALID_FOR属性を使用すると、同じ初期化パラメータ・ファイルをプライマリ・ロールとスタンバイ・ロールの両方に使用できます。

例

次の例は、VALID_FORのデフォルトのキーワードのペアを示します。

LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata VALID_FOR=(ALL_LOGFILES, ALL_ROLES)'

このデータベースがプライマリ・ロールまたはスタンバイ・ロールで稼働している場合、宛先1は、すべてのログ・ファイルをローカル・ディレクトリ/disk1/oracle/oradataにアーカイブします。

16 Data Guardに関連するSQL文

この章では、Data Guard環境のスタンバイ・データベースで操作を実行するときに役立つSQLおよびSQL*Plus文の概要について説明します。この章は、次の項目で構成されています。

- ALTER DATABASE文

- ALTER SESSION文

- ALTER SYSTEM文

この章では、特定のSQL文について、その構文と簡単な概要を示します。ここに記載しているものを含むSQL文の完全な構文と説明は、『Oracle Database SQL言語リファレンス』を参照してください。

ALTER SYSTEM SET文を使用して設定および動的な更新を行うことができる初期化パラメータのリストは、第14章を参照してください。

16.1 ALTER DATABASE文

表16-1で、Data Guardに関連のあるALTER DATABASE文について説明します。

表16-1 Data Guard環境で使用されるALTER DATABASE文

ALTER DATABASE文

説明

ADD [STANDBY] LOGFILE [THREAD integer] [GROUP integer] filespec

指定したスレッドに1つ以上のオンラインREDOログ・ファイル・グループまたはスタンバイREDOログ・ファイル・グループを追加し、スレッドが割り当てられたインスタンスでログ・ファイルを使用できるようにします。

この文の例は、9.3.5項を参照してください。

ADD [STANDBY] LOGFILE MEMBER 'filename' [REUSE] TO logfile-descriptor

既存のオンラインREDOログ・ファイル・グループまたはスタンバイREDOログ・ファイル・グループに新しいメンバーを追加します。

[ADD|DROP] SUPPLEMENTAL LOG DATA {PRIMARY KEY|UNIQUE INDEX} COLUMNS

この文は、ロジカル・スタンバイ・データベース専用です。

ロジカル・スタンバイ・データベースを作成する前に、サプリメンタル・ロギングを使用可能にするために使用します。サプリメンタル・ロギングがロジカル・スタンバイ・データベースに対する変更のソースであるため、このようにする必要があります。完全なサプリメンタル・ロギングを実装するには、この文でPRIMARY KEY COLUMNSまたはUNIQUE INDEX COLUMNSキーワードを指定する必要があります。

詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

COMMIT TO SWITCHOVER

次のスイッチオーバーを実行します。

- カレント・プライマリ・データベースをスタンバイ・データベース・ロールに変更する

- 1つのスタンバイ・データベースをプライマリ・データベース・ロールに変更する

注意: ロジカル・スタンバイ・データベースでは、ALTER DATABASE COMMIT TO SWITCHOVER文を発行する前に、ALTER DATABASE PREPARE TO SWITCHOVER文を発行し、スイッチオーバーのためにデータベースを準備します。

この文の例は、8.2.1項および8.3.1項を参照してください。この文の完全な構文は、『Oracle Database SQL言語リファレンス』も参照してください。

CONVERT TO [[PHYSICAL|SNAPSHOT] STANDBY] DATABASE

フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに、またはその逆に変換します。

CREATE [PHYSICAL|LOGICAL] STANDBY CONTROLFILE AS 'filename' [REUSE]

フィジカルまたはロジカル・スタンバイ・データベースの維持に使用される制御ファイルを作成します。この文はプライマリ・データベースで発行します。

この文の例は、3.2.2項を参照してください。

DROP [STANDBY] LOGFILE logfile_descriptor

オンラインREDOログ・ファイル・グループまたはスタンバイREDOログ・ファイル・グループのすべてのメンバーを削除します。

この文の例は、9.3.5項を参照してください。

DROP [STANDBY] LOGFILE MEMBER 'filename'

オンラインREDOログ・ファイル・グループまたはスタンバイREDOログ・ファイル・グループの1つ以上のメンバーを削除します。

[NO]FORCE LOGGING

一時表領域および一時セグメントに対する変更を除くデータベースに対するすべての変更を、Oracleデータベースが記録するかどうかを制御します。[NO]FORCE LOGGING句は、スタンバイ・データベース間の一貫性の欠如を防止するために必要です。

この文を発行する場合、プライマリ・データベースを少なくともマウントしておく(また、オープンもできるようにしておく)必要があります。この文の例は、3.1.1項を参照してください。

GUARD

ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスを制御します。可能な値は、ALL、STANDBYおよびNONEです。詳細は、10.2項を参照してください。

MOUNT [STANDBY DATABASE]

スタンバイ・データベースをマウントし、スタンバイ・インスタンスがREDOデータをプライマリ・インスタンスから受信できるようにします。

OPEN

すでに起動され、マウントされたデータベースをオープンします。

- フィジカル・スタンバイ・データベースは読取り専用モードでオープンされ、ユーザーを読取り専用トランザクションに制限し、REDOデータの生成を防ぎます。

- ロジカル・スタンバイ・データベースは読取り/書込みモードでオープンされます。

PREPARE TO SWITCHOVER

この文は、ロジカル・スタンバイ・データベース専用です。

スイッチオーバーが実行される前にLogMinerディクショナリを構築することにより、プライマリ・データベースおよびロジカル・スタンバイ・データベースをスイッチオーバー用に準備します。ディクショナリ構築の完了後、ALTER DATABASE COMMIT TO SWITCHOVER文を発行し、プライマリおよびロジカル・スタンバイ・データベースのロールを切り替えます。

この文の例は、8.3.1項を参照してください。この文の完全な構文は、『Oracle Database SQL言語リファレンス』も参照してください。

RECOVER MANAGED STANDBY DATABASE [ { DISCONNECT [FROM SESSION] | USING CURRENT LOGFILE | NODELAY | UNTIL CHANGE integer }...]

この文はフィジカル・スタンバイ・データベースに対するREDO Applyを開始および制御します。RECOVER MANAGED STANDBY DATABASE句は、マウント、オープンまたはクローズされているフィジカル・スタンバイ・データベースで使用できます。例は、3.2.6項および7.3項の手順4を参照してください。

注意: 複数の句およびキーワードが非推奨となり、下位互換性のためにのみサポートされています。これらの句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

RECOVER MANAGED STANDBY DATABASE CANCEL

CANCEL句は、現行のアーカイブREOログ・ファイルの適用後、フィジカル・スタンバイ・データベースへのRedo Applyを取り消します。

注意: 複数の句およびキーワードが非推奨となり、下位互換性のためにのみサポートされています。これらの句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

RECOVER MANAGED STANDBY DATABASE FINISH

FINISH句は、ターゲット・フィジカル・スタンバイ・データベースでフェイルオーバーを開始し、現行のスタンバイREDOログ・ファイルをリカバリします。FINISH句を使用するのは、プライマリ・データベースに障害が発生した場合のみです。この句により、指定の遅延間隔がオーバーライドされます。

例は、8.2.2項の手順4を参照してください。

注意: 複数の句およびキーワードが非推奨となり、下位互換性のためにのみサポートされています。これらの句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

REGISTER [OR REPLACE] [PHYSICAL|LOGICAL] LOGFILE filespec

手動でコピーされたアーカイブREDOログ・ファイルを登録できます。

注意: このコマンドは、対応するアーカイブREDOログ・ファイルを手動でスタンバイ・データベースにコピーした後にのみ発行します。ログ・ファイルのコピー中、あるいはログ・ファイルが存在しないときにこのコマンドを発行すると、後でスタンバイ・データベースにエラーが発生する可能性があります。

RECOVER TO LOGICAL STANDBY new_database_name

適用サービスに対して、データベースをロジカル・スタンバイ・データベースに変換するコマンドを発行するまでは、引き続き変更をフィジカル・スタンバイ・データベースに適用するように指示します。詳細は、4.2.4.1項を参照してください。

RESET DATABASE TO INCARNATION integer

データベースのターゲット・リカバリ・インカネーションを、現在のインカネーションから別のインカネーションにリセットします。

SET STANDBY DATABASE TO MAXIMIZE {PROTECTION|AVAILABILITY|PERFORMANCE}

この句を使用して、Data Guard構成におけるデータの保護レベルを指定します。この句は、マウント済でオープンされていないプライマリ・データベースから指定します。

START LOGICAL STANDBY APPLY INITIAL [scn-value] ] [NEW PRIMARY dblink]

この文はロジカル・スタンバイ・データベース専用です。ロジカル・スタンバイ・データベースに対して、SQL Applyを開始します。この文の例は、7.4.1項を参照してください。

{STOP|ABORT} LOGICAL STANDBY APPLY

この文はロジカル・スタンバイ・データベース専用です。STOP句を使用して、ロジカル・スタンバイ・データベースに対するSQL Applyを整然と停止します。ABORT句を使用するとSQL Applyが突然停止します。この文の例は、8.3.2項を参照してください。

ACTIVATE [PHYSICAL|LOGICAL] STANDBY DATABASE FINISH APPLY]

フェイルオーバーを実行します。スタンバイ・データベースは、マウント後に、この文を使用してアクティブ化する必要があります。

注意: ALTER DATABASE ACTIVATE STANDBY DATABASE文でフェイルオーバーを行うと、データが失われるので使用しないでください。かわりに次のベスト・プラクティスを使用します。

- フィジカル・スタンバイ・データベースの場合、ALTER DATABASE RECOVER MANAGED STANDBY DATABASE文でFINISHキーワードを使用します。これにより、ロールの推移がすばやく実行されるため、データ消失は防止されるかまたは最小限に抑えられ、他のスタンバイ・データベースが使用できなくなることはありません。

- ロジカル・スタンバイ・データベースの場合、ALTER DATABASE PREPARE TO SWITCHOVERおよびALTER DATABASE COMMIT TO SWITCHOVER文を使用します。

16.2 ALTER SESSION文

表16-2で、Data Guardに関連のあるALTER SESSION文について説明します。

表16-2 Data Guard環境で使用されるALTER SESSION文

ALTER SESSION文

説明

ALTER SESSION [ENABLE|DISABLE] GUARD

この文は、ロジカル・スタンバイ・データベース専用です。

権限を付与されているユーザーは、この文を使用して、現在のセッションでデータベース・ガードを選択または解除できます。

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

ALTER SESSION SYNC WITH PRIMARY

この文は、フィジカル・スタンバイ・データベース専用です。

この文は、起動時にフィジカル・スタンバイにより受信されたすべてのREDOデータが適用されるまでブロックすることにより、フィジカル・スタンバイ・データベースをプライマリ・データベースと同期します。

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

16.3 ALTER SYSTEM文

表16-3で、Data Guardに関連のあるALTER SYSTEM文について説明します。

表16-3 Data Guard環境で使用されるALTER SYSTEM文

ALTER SYSTEM文

説明

ALTER SYSTEM FLUSH REDO TO target_db_name [[NO] CONFIRM APPLY]

この文は、REDOデータをすべて、プライマリ・データベースからスタンバイ・データベースにフラッシュし、必要に応じて、フラッシュされたREDOデータがフィジカルまたはロジカル・スタンバイ・データベースに適用されるまで待機します。

この文は、マウントされているが、オープンされていないプライマリ・データベースで発行する必要があります。

17 Oracle Data Guardに関連するビュー

この章では、Data Guard環境を監視するときに特に便利なビューについて説明します。この章で説明されているビューは、Oracleデータベースで使用可能なビューのサブセットです。

表17-1では、各ビューについて説明し、そのビューがフィジカル・スタンバイ・データベース、ロジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベース、プライマリ・データベースのいずれに適用されるのかを示します。ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

表17-1 Data Guard構成に関連のあるビュー

ビュー

データベース

説明

DBA_LOGSTDBY_EVENTS

ロジカルのみ

ロジカル・スタンバイ・データベースのアクティビティに関する情報を含んでいます。SQL Applyがロジカル・スタンバイ・データベースにREDOを適用中に発生した障害原因を特定するために使用します。

DBA_LOGSTDBY_HISTORY

ロジカルのみ

Data Guard構成のロジカル・スタンバイ・データベースでのスイッチオーバーおよびフェイルオーバーの履歴を表示します。すべてのロール・トランジションについて、ローカル・システムで処理または作成されたすべてのREDOログ・ストリームを示すことでこれを行います。(ロール・トランジション後は、新しいログ・ストリームが開始し、新しいプライマリ・データベースによってログ・ストリーム順序番号が増分されます。)

DBA_LOGSTDBY_LOG

ロジカルのみ

ロジカル・スタンバイ・データベースにレジストリされているログ・ファイルを表示します。

DBA_LOGSTDBY_NOT_UNIQUE

ロジカルのみ

主キー制約またはNOT NULLの一意制約がない表を識別します。

DBA_LOGSTDBY_PARAMETERS

ロジカルのみ

SQL Applyで使用されるパラメータのリストが格納されます。

DBA_LOGSTDBY_SKIP

ロジカルのみ

SQL Applyによってスキップされる表をリスト表示します。

DBA_LOGSTDBY_SKIP_TRANSACTION

ロジカルのみ

選択されているスキップ設定をリスト表示します。

DBA_LOGSTDBY_UNSUPPORTED

ロジカルのみ

サポートされないデータ型が含まれているスキーマおよび表(およびその表の列)を識別します。このビューは、ロジカル・スタンバイ・データベースの作成を準備する際に使用します。

V$ARCHIVE_DEST

プライマリ、フィジカル、スナップショットおよびロジカル

Data Guard構成内のすべての宛先の現在の値、モードおよび状況を含めた説明を表示します。

注意: このビューに表示される情報は、インスタンスの停止後には保存されません。

V$ARCHIVE_DEST_STATUS

プライマリ、フィジカル、スナップショットおよびロジカル

アーカイブREDOログ宛先の実行時および構成用の情報を表示します。

注意: このビューに表示される情報は、インスタンスの停止後には保存されません。

V$ARCHIVE_GAP

フィジカル、スナップショットおよびロジカル

アーカイブREDOログ・ファイルのギャップの識別に役立つ情報を表示します。

V$ARCHIVED_LOG

プライマリ、フィジカル、スナップショットおよびロジカル

制御ファイルのアーカイブREDOログ情報を、アーカイブREDOログ・ファイル名を含めて表示します。

V$DATABASE

プライマリ、フィジカル、スナップショットおよびロジカル

制御ファイルからのデータベース情報を表示します。ファスト・スタート・フェイルオーバー(Data Guard Brokerでのみ使用可能)に関する情報が含まれます。

V$DATABASE_INCARNATION

プライマリ、フィジカル、スナップショットおよびロジカル

すべてのデータベース・インカネーションに関する情報を表示します。Oracle Databaseでは、RESETLOGSオプションを使用してデータベースがオープンされるたびに、新しいインカネーションが作成されます。V$DATABASEビューには、現在のインカネーションのみでなく、前のインカネーションのレコードも表示されます。

V$DATAFILE

プライマリ、フィジカル、スナップショットおよびロジカル

制御ファイルからのデータファイル情報を表示します。

V$DATAGUARD_CONFIG

プライマリ、フィジカル、スナップショットおよびロジカル

初期化パラメータ、DB_UNIQUE_NAMEおよびLOG_ARCHIVE_CONFIGで定義された一意のデータベース名をリストにします。

V$DATAGUARD_STATS

プライマリ、フィジカル、スナップショットおよびロジカル

適用ラグやトランスポート・ラグを含む各種Data Guard統計を表示します。このビューは、いかなるスタンバイ・データベースのインスタンスでも問合せできます。プライマリ・データベースを問い合せた場合、1行も戻されません。例および詳細は、8.1.2項を参照してください。

V$DATAGUARD_STATUS

プライマリ、フィジカル、スナップショットおよびロジカル

通常はアラート・ログまたはサーバー・プロセスのトレース・ファイルへのメッセージによってトリガーされるイベントが表示および記録されます。

V$FS_FAILOVER_STATS

プライマリ

システムで発生したファスト・スタート・フェイルオーバーに関する統計を表示します。

V$LOG

プライマリ、フィジカル、スナップショットおよびロジカル

オンラインREDOログ・ファイルのログ・ファイル情報が格納されます。

V$LOGFILE

プライマリ、フィジカル、スナップショットおよびロジカル

オンラインREDOログ・ファイルとスタンバイREDOログ・ファイルに関する情報が格納されます。

V$LOG_HISTORY

プライマリ、フィジカル、スナップショットおよびロジカル

制御ファイルからのログ履歴情報が格納されます。

V$LOGSTDBY_PROCESS

ロジカルのみ

SQL Applyの動作を示す動的情報を提供します。このビューは、ロジカル・スタンバイ・データベースにSQL Applyを適用する際に、パフォーマンス問題を診断する場合に非常に役立ちます。

V$LOGSTDBY_PROGRESS

ロジカルのみ

ロジカル・スタンバイ・データベースでのSQL Applyの進捗状況を表示します。

V$LOGSTDBY_STATE

ロジカルのみ

SQL Applyとロジカル・スタンバイ・データベースの実行状態に関して、V$LOGSTDBY_PROCESSおよびV$LOGSTDBY_STATSビューの情報を連結します。

V$LOGSTDBY_STATS

ロジカルのみ

LogMiner統計、現行のステータスおよびSQL Apply時のロジカル・スタンバイ・データベースのステータス情報を表示します。SQL Applyが実行されていない場合、統計の値は消去されます。

V$LOGSTDBY_TRANSACTION

ロジカルのみ

ロジカル・スタンバイ・データベースでSQL Applyにより処理中のすべてのアクティブ・トランザクションに関する情報を表示します。

V$MANAGED_STANDBY

フィジカルおよびスナップショット

フィジカル・スタンバイ・データベースに関連するOracleデータベース・プロセスの現在の状態を表示します。

注意: このビューに表示される情報は、インスタンスの停止後には保存されません。

V$REDO_DEST_RESP_HISTOGRAM

プライマリ

SYNC転送用に構成された宛先に関するレスポンス時間の情報が格納されます。

注意: このビューに表示される情報は、インスタンスの停止後には保存されません。

V$STANDBY_EVENT_HISTOGRAM

フィジカル

フィジカル・スタンバイの適用ラグ値のヒストグラムが格納されます。エントリは、対応する適用ラグのバケット(REDO Applyプロセス1秒単位)に作成されます。(このビューは、リアルタイム問合せモードで開かれたフィジカル・スタンバイ・データベースでのみ行を戻します。)

注意: このビューに表示される情報は、インスタンスの停止後には保存されません。

V$STANDBY_LOG

フィジカル、スナップショットおよびロジカル

スタンバイREDOログ・ファイルのログ・ファイル情報が格納されます。

第III部

付録

この部は、次の付録で構成されています。

- 付録A「Data Guardのトラブルシューティング」

- 付録B「Data Guard構成におけるデータベースのアップグレードおよびダウングレード」

- 付録C「ロジカル・スタンバイ・データベースでサポートされるデータ型およびDDL」

- 付録D「Data GuardおよびOracle Real Application Clusters」

- 付録E「Recovery Managerを使用したスタンバイ・データベースの作成」

- 付録F「アーカイブ・トレースの設定」

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

この付録は、スタンバイ・データベースのトラブルシューティングのヘルプとしてご利用いただけます。この項は、次の項目で構成されています。

- 一般的な問題

- ログ・ファイル宛先の障害

- ロジカル・スタンバイ・データベース障害の処理

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

- ロジカル・スタンバイ・データベースへのスイッチオーバーの問題

- SQL Applyが停止した場合の処置

- REDOデータ転送のネットワーク調整

- スタンバイ・データベースのディスクのパフォーマンスが遅い

- プライマリ・データベースの停止を回避するにはログ・ファイルを一致させる必要がある

- ロジカル・スタンバイ・データベースのトラブルシューティング

A.1 一般的な問題

スタンバイ・データベースの使用時に発生する問題の原因には、次のようなものがあります。

- ALTER DATABASE文によるデータファイル名の変更

- スタンバイ・データベースがプライマリ・データベースからREDOデータを受信しない

- フィジカル・スタンバイ・データベースをマウントできない

A.1.1 ALTER DATABASE文によるデータファイル名の変更

STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定すると、スタンバイ・サイトのデータファイルを改名できません。STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定した場合、次のSQL文は使用できなくなります。

- ALTER DATABASE RENAME

- ALTER DATABASE ADD/DROP LOGFILE

- ALTER DATABASE ADD/DROP STANDBY LOGFILE MEMBER

- ALTER DATABASE CREATE DATAFILE AS

スタンバイ・データベースでこれらの文のいずれかを使用しようとすると、エラーが表示されます。次に例を示します。

SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/t_db2.log' to 'dummy';

alter database rename file '/disk1/oracle/oradata/payroll/t_db2.log' to 'dummy'
*
ERROR at line 1:
ORA-01511: error in renaming log/datafiles
ORA-01270: RENAME operation is not allowed if STANDBY_FILE_MANAGEMENT is auto

フィジカル・スタンバイ・データベースにデータファイルを追加する方法は、9.3.1項を参照してください。

A.1.2 スタンバイ・データベースがプライマリ・データベースからREDOデータを受信しない

スタンバイ・サイトがREDOデータを受信していない場合は、V$ARCHIVE_DESTビューの問合せを行い、エラー・メッセージがないか確認します。たとえば、次のような問合せを入力します。

SQL> SELECT DEST_ID "ID", -
> STATUS "DB_status", -
> DESTINATION "Archive_dest", -
> ERROR "Error" -
> FROM V$ARCHIVE_DEST WHERE DEST_ID <=5;

ID DB_status Archive_dest                   Error
-- --------- ------------------------------ ------------------------------------
1  VALID    /vobs/oracle/work/arc_dest/arc
2  ERROR    standby1                       ORA-16012: Archivelog standby database identifier mismatch
3  INACTIVE
4  INACTIVE
5  INACTIVE
5 rows selected.

問合せの出力によって解決しない場合は、次の問題リストを確認します。次のいずれかの条件に該当する場合、REDO転送サービスはスタンバイ・データベースにREDOデータを転送できません。

- プライマリ・データベースのtnsnames.oraファイル内でスタンバイ・インスタンスのサービス名が正しく構成されていない場合。

- プライマリ・データベースのLOG_ARCHIVE_DEST_nパラメータで指定されたOracle Netサービス名が不適切な場合。

- スタンバイ・データベースのLOG_ARCHIVE_DEST_STATE_nパラメータが値ENABLEに設定されていない場合。

- listener.oraファイルがスタンバイ・データベース用に正しく構成されていない場合。

- スタンバイ・サイトでリスナーが開始されていない場合。

- スタンバイ・インスタンスが起動されていない場合。

- スタンバイ・アーカイブ先をプライマリSPFILEまたはテキスト初期化パラメータ・ファイルに追加したが、その変更をまだ使用可能にしていない場合。

- REDO転送の認証が正しく構成されていない場合。REDO転送の認証の構成要件は、3.1.2項を参照してください。

- スタンバイ・データベースのベースとして無効なバックアップを使用した場合(たとえば、間違ったデータベースからのバックアップを使用、または正しい方法でスタンバイ制御ファイルを作成しなかったなど)。

A.1.3 フィジカル・スタンバイ・データベースをマウントできない

スタンバイ制御ファイルが、ALTER DATABASE CREATE [LOGICAL] STANDBY CONTROLFILE ...文またはRecovery Managerコマンドを使用して作成されていない場合、スタンバイ・データベースをマウントすることはできません。次のタイプの制御ファイル・バックアップは使用できません。

- オペレーティング・システムで作成されたバックアップ

- PHYSICAL STANDBYまたはLOGICAL STANDBYオプションのないALTER DATABASE文を使用して作成されたバックアップ

A.2 ログ・ファイル宛先の障害

MANDATORY宛先にREOPENを指定した場合、REDO転送サービスは、REDOデータを正常に転送できなかったとき、プライマリ・データベースを停止します。

MAX_FAILURE属性を使用する場合は、REOPEN属性は必須です。例A-1に、再試行時間を5秒に設定し、再試行回数を3回に制限する方法を示します。

例A-1 再試行時間と制限の設定

LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3'

LOG_ARCHIVE_DEST_nパラメータのALTERNATE属性を使用して、代替アーカイブ先を指定します。スタンバイ・データベースへのREDOデータの転送に失敗した場合は、代替アーカイブ先を使用できます。転送に失敗したときに、REOPEN属性が指定されていなかった場合、またはMAX_FAILURE属性のしきい値を超えた場合、REDO転送サービスは、次のアーカイブ操作時に代替先へのREDOデータの転送を試みます。

元のアーカイブ先で障害が発生したときに、元のアーカイブ先が自動的に代替アーカイブ先に変更されることを防ぐには、NOALTERNATE属性を使用します。

例A-2は、エラー発生時に、単一、必須のローカル宛先が異なる宛先へ自動的にフェイルオーバーするように初期化パラメータを設定する方法を示します。

例A-2 代替宛先の指定

LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY'
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE

LOG_ARCHIVE_DEST_1の宛先で障害が発生した場合、アーカイブ・プロセスは、プライマリ・データベースでの次のログ・ファイル・スイッチでLOG_ARCHIVE_DEST_2の宛先に自動的に切り替えます。

A.3 ロジカル・スタンバイ・データベース障害の処理

ロジカル・スタンバイ・データベース障害を処理するための重要なツールは、DBMS_LOGSTDBY.SKIP_ERRORプロシージャです。表の重要度に基づいて、次のいずれかを実行できます。

- 表や特定のDDLに関する障害を無視する。

- ストアド・プロシージャをフィルタに関連付ける。これによって、文のスキップ、文の実行または代用文の実行について実行時に決定できます。

これらの処理のいずれかを実行すると、SQL Applyの停止を回避できます。存在している問題は、後でDBA_LOGSTDBY_EVENTSビューを問い合せて検索し、訂正できます。PL/SQLコールアウト・プロシージャでのDBMS_LOGSTDBYパッケージ使用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

A.4 フィジカル・スタンバイ・データベースへのスイッチオーバーの問題

通常、第8章で説明した手順に従うと、スイッチオーバーは正常に行われます。ただし、スイッチオーバーが失敗した場合でも、次の項を読むと、問題の解決に役立ちます。

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

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

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

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

- 失敗したスイッチオーバーをロールバックして最初からやりなおす

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

スイッチオーバーが正常に完了しない場合は、V$ARCHIVED_LOGビューのSEQUENCE#列の問合せを行い、元のプライマリ・データベースから転送された最新のREDOデータが、スタンバイ・データベースに適用されていることを確認してください。最後のREDOデータがスタンバイ・データベースに転送されていない場合は、そのREDOデータが含まれるアーカイブREDOログ・ファイルを元のプライマリ・データベースから古いスタンバイ・データベースに手動でコピーし、SQL ALTER DATABASE REGISTER LOGFILE file_specification文を使用して登録します。次に、適用サービスを開始すると、アーカイブREDOログ・ファイルが自動的に適用されます。V$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。SWITCHOVER_STATUS列からTO PRIMARYまたはSESSIONS ACTIVEが戻されると、プライマリ・ロールへのスイッチオーバーが可能になります。

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO PRIMARY
1 row selected

V$DATABASEビューのSWITCHOVER_STATUS列に対するその他の有効な値の詳細は、第17章を参照してください。

スイッチオーバーを続行するには、8.2.1項(フィジカル・スタンバイ・データベースの場合)または8.3.1項(ロジカル・スタンバイ・データベースの場合)の説明に従って、ターゲットのスタンバイ・データベースをプライマリ・ロールに切り替える操作を再度実行します。

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

ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY文にWITH SESSION SHUTDOWN句を組み込んでいない場合、アクティブなSQLセッションがあると、スイッチオーバーを継続できません。アクティブなSQLセッションには、他のOracle Databaseプロセスが含まれていることがあります。

セッションがアクティブのときは、スイッチオーバーの試行が次のエラー・メッセージを伴って失敗します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY *
ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected

処置: V$SESSIONビューを問い合せ、エラーの原因となっているプロセスを判断します。次に例を示します。

SQL> SELECT SID, PROCESS, PROGRAM FROM V$SESSION -
> WHERE TYPE = 'USER' -
>  AND SID <> (SELECT DISTINCT SID FROM V$MYSTAT);

SID        PROCESS   PROGRAM
---------  --------  ------------------------------------------------
7      3537  oracle@nhclone2 (CJQ0)
10
14
16
19
21
6 rows selected.

この例では、JOB_QUEUE_PROCESSESパラメータがCJQ0プロセス・エントリに対応しています。ジョブ・キュー・プロセスはユーザー・プロセスなので、スイッチオーバーの発生を妨げるのはSQLセッションであると考えられます。プロセスまたはプログラム情報のないエントリは、ジョブ・キュー・コントローラによって開始されるスレッドです。

次のSQL文を使用して、JOB_QUEUE_PROCESSESパラメータが設定されていることを確認してください。

SQL> SHOW PARAMETER JOB_QUEUE_PROCESSES;

NAME                           TYPE      VALUE
------------------------------ -------   --------------------
job_queue_processes            integer   5

さらに、パラメータを0(ゼロ)に設定してください。次に例を示します。

SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
Statement processed.

JOB_QUEUE_PROCESSESは動的パラメータであるため、値を変更した際にインスタンスを再起動しなくても、変更を即時に有効にできます。これで、スイッチオーバー手順を再試行できます。

初期化パラメータ・ファイル内のパラメータは変更しないでください。インスタンスを停止し、スイッチオーバーが完了した後で再起動すると、パラメータが元の値にリセットされます。これは、プライマリ・データベースとフィジカル・スタンバイ・データベースの両方に適用されます。

表A-1に、スイッチオーバーを妨げる共通のプロセスと、実行する必要のある対処措置をまとめます。

表A-1 スイッチオーバーを妨げる共通のプロセス

プロセスのタイプ

プロセスの説明

対処措置

CJQ0

Job Queue Scheduler Process

JOB_QUEUE_PROCESSES動的パラメータを値0(ゼロ)に変更してください。変更は、インスタンスを再起動しなくても即時に有効になります。

QMN0

Advanced Queue Time Manager

AQ_TM_PROCESSES動的パラメータを値0(ゼロ)に変更してください。変更は、インスタンスを再起動しなくても即時に有効になります。

DBSNMP

Oracle Enterprise Manager Management Agent

オペレーティング・システムのプロンプトから、emctl stop agentコマンドを発行してください。

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

スタンバイ・データベースとプライマリ・データベースが同じサイトに存在するとします。ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY文およびALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY文の両方が正常に実行された後、フィジカル・スタンバイ・データベースとプライマリ・データベースを停止し、再起動します。

注意:
フィジカル・スタンバイ・データベースが起動後に読取り専用モードでオープンされていない場合、停止して再起動する必要はありません。

ただし、2番目のデータベースの起動は、「ORA-01102: データベースを排他モードでマウントすることができません。」エラーで失敗します。

スタンバイ・データベース(つまり元のプライマリ・データベース)で使用される初期化パラメータ・ファイルにDB_UNIQUE_NAMEパラメータを設定していないと、スイッチオーバー中にこの現象が発生することがあります。スタンバイ・データベースのDB_UNIQUE_NAMEパラメータが設定されていない場合、スタンバイ・データベースとプライマリ・データベースの両方が同じマウント・ロックを使用するため、2つ目のデータベースの起動時にORA-01102エラーが発生します。

処置: DB_UNIQUE_NAME=unique_database_nameをスタンバイ・データベースが使用する初期化パラメータ・ファイルに追加して、スタンバイ・データベースとプライマリ・データベースを停止し、再起動します。

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

スイッチオーバー後にアーカイブREDOログ・ファイルが新しいスタンバイ・データベースに適用されません。

これは、スイッチオーバー後、環境パラメータまたは初期化パラメータが適切に設定されていなかったことが原因と考えられます。

処置:

- 新しいプライマリ・サイトのtnsnames.oraファイルおよび新しいスタンバイ・サイトのlistener.oraファイルを調べます。スタンバイ・サイトにはリスナーのエントリ、プライマリ・サイトにはそれに対応するサービス名が必要です。

- リスナーがまだ起動されていない場合は、スタンバイ・サイトで起動します。

- プライマリ・サイトからスタンバイ・サイトにREDOデータを正しく転送するための、LOG_ARCHIVE_DEST_n初期化パラメータが設定されているかどうかを調べます。たとえば、プライマリ・サイトでV$ARCHIVE_DEST固定ビューを次のように問い合せます。

SQL> SELECT DEST_ID, STATUS, DESTINATION FROM V$ARCHIVE_DEST;

スタンバイ・サイトに対応するエントリが見つからない場合、LOG_ARCHIVE_DEST_n初期化パラメータおよびLOG_ARCHIVE_DEST_STATE_n初期化パラメータを設定する必要があります。

- スタンバイ・サイトにSTANDBY_ARCHIVE_DEST初期化パラメータおよびLOG_ARCHIVE_FORMAT初期化パラメータを正しく設定し、アーカイブREDOログ・ファイルが適切な場所に適用されるようにします。(STANDBY_ARCHIVE_DESTパラメータは非推奨であり、下位互換性のためにのみサポートされています。)

- スタンバイ・サイトで DB_FILE_NAME_CONVERT初期化パラメータおよび LOG_FILE_NAME_CONVERT初期化パラメータを設定します。プライマリ・サイトで作成された新しいデータファイルがスタンバイ・サイトに自動的に追加されるようにするには、STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定します。

A.4.5 失敗したスイッチオーバーをロールバックして最初からやりなおす

フィジカル・スタンバイ・データベースでエラーが発生し、スイッチオーバーを続行できない場合は、次の手順に従って、新しいフィジカル・スタンバイ・データベースをプライマリ・ロールに戻すことができます。(この機能は、Oracle Database 11gリリース2(11.2.0.2)以上で使用できます。)

1. 新しいスタンバイ・データベース(古いプライマリ)を停止し、マウントします。

2. 新しいスタンバイ・データベースでREDO Applyを開始します。

3. 新しいスタンバイ・データベースがいつでもプライマリ・ロールに戻せることを確認します。スタンバイ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。次に例を示します。

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO_PRIMARY
1 row selected

値TO PRIMARYまたはSESSIONS ACTIVEは、スタンバイ・データベースでプライマリ・ロールに切り替える準備が完了していることを示します。値TO PRIMARYまたはSESSIONS ACTIVEが戻されるまで、この列の問合せを続行します。

4. 次の文を発行して、新しいスタンバイ・データベースを変換してプライマリ・ロールに戻します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

この文が正常に実行されると、データベースはプライマリ・データベース・ロールで実行されるため、それ以降の手順を実行する必要はありません。

この文が正常に実行されなかった場合は、手順5に進んでください。

5. プライマリからフィジカル・スタンバイにロールを変更するスイッチオーバーを開始したときに、トレース・ファイルがログ・ディレクトリに書き込まれています。このトレース・ファイルには、元のプライマリ制御ファイルを再作成するために必要なSQL文が含まれています。トレース・ファイルの位置を特定し、SQL文を一時ファイルに抽出します。SQL*Plusから一時ファイルを実行します。これによって、新しいスタンバイ・データベースはプライマリ・ロールに戻されます。

6. 元のフィジカル・スタンバイ・データベースを停止します。

7. 新しいスタンバイ制御ファイルを作成します。このファイルは、プライマリ・データベースとフィジカル・スタンバイ・データベースの再同期化に必要です。フィジカル・スタンバイ制御ファイルを元のフィジカル・スタンバイ・システムにコピーします。フィジカル・スタンバイ制御ファイルの作成方法は、3.2.2項を参照してください。

8. 元のフィジカル・スタンバイ・インスタンスを再起動します。
この手順が正常終了し、アーカイブ・ギャップ管理が使用可能になると、FALプロセスが起動し、欠落したアーカイブREDOログ・ファイルをフィジカル・スタンバイ・データベースに再アーカイブします。プライマリ・データベース上でログ・スイッチを強制実行し、プライマリ・データベースとフィジカル・スタンバイ・データベースの両方のアラート・ログを調べて、アーカイブREDOログ・ファイルの順序番号が正しいことを確認します。

アーカイブ・ギャップ管理の詳細は6.4.3.1項を、トレース・ファイルの場所については付録Fを参照してください。

9. スイッチオーバーを再度実行します。
この時点で、Data Guard構成は初期状態にロールバックされています。最初に失敗したスイッチオーバーの問題をすべて解決した後、スイッチオーバー操作を再度実行できます。

A.5 ロジカル・スタンバイ・データベースへのスイッチオーバーの問題

ロジカル・スタンバイ・データベースに関連するスイッチオーバー操作には、通常、準備とコミットの2つのフェーズがあります。これに対する例外は、ロジカル・スタンバイ・データベースを使用したOracleソフトウェアのローリング・アップグレードの場合、またはData Guard Brokerを使用している場合です。ロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行中、またはData Guard Brokerで開始されたスイッチオーバー操作の際に障害が発生した場合は、A.5.2項に直接進んでください。

注意:
Data Guard構成のすべてのデータベースで、フラッシュバック・データベースを有効にすることをお薦めします。この項の手順では、使用するData Guard構成内のすべてのデータベースで、フラッシュバック・データベースが有効にされていると想定しています。

A.5.1 スイッチオーバー操作の準備フェーズ中の障害

スイッチオーバー操作の準備フェーズ中に障害が発生した場合、スイッチオーバーを取り消して、スイッチオーバー操作を再度初めから行います。

A.5.1.1 プライマリ・データベースの準備中の障害

ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY文の実行中に障害が発生した場合、プライマリ・データベースで次のSQL文を発行してスイッチオーバーの準備フェーズを取り消します。

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY CANCEL;

これで、スイッチオーバー操作を再度初めから行うことができます。

A.5.1.2 ロジカル・スタンバイ・データベースの準備中の障害

ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY文の実行中に障害が発生した場合、プライマリ・データベースおよびターゲット・スタンバイ・データベースで準備操作を取り消す必要があります。次の手順に従ってください。

1. プライマリ・データベースで、スイッチオーバーの準備のために発行した文を取り消します。

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY CANCEL;

2. スイッチオーバーのターゲットであるロジカル・スタンバイ・データベースで、スイッチオーバーの準備のために発行した文を取り消します。

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY CANCEL;

これで、スイッチオーバー操作を再度初めから行うことができます。

A.5.2 スイッチオーバー操作のコミット・フェーズ中の障害

スイッチオーバーのコミットでは単一のSQL文のみを使用しますが、内部的には多数の操作が実行されます。実行する必要がある修正処理は、エラー発生時のスイッチオーバー操作のコミットの状態によって異なります。

A.5.2.1 元のプライマリ・データベースの変換での障害

ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY文の実行中に障害が発生した場合、次の手順を実行します。

1. 元のプライマリ・データベースのV$DATABASE固定ビューのDATABASE_ROLE列をチェックします。

SQL> SELECT DATABASE_ROLE FROM V$DATABASE;

- 列にLOGICAL STANDBYの値が含まれる場合、スイッチオーバー操作は完了していますが、スイッチオーバー後のタスクで障害が発生しています。この場合、データベースを停止して再オープンすることをお薦めします。

- 列にPRIMARYの値が含まれる場合、手順2に進みます。

2. 元のプライマリで次の問合せを実行します。

SQL> SELECT COUNT(*) FROM SYSTEM.LOGSTDBY$PARAMETERS -
> WHERE NAME = 'END_PRIMARY';

- 問合せで0が戻される場合、プライマリの状態は、スイッチオーバーのコミット・コマンドが発行される前と同一です。修正処理を実行する必要はありません。スイッチオーバー操作のコミットに進むか、A.5.1.2項で説明するようにスイッチオーバー操作を取り消します。

- 問合せで1が戻される場合、プライマリは一貫性がない状態のため、手順3に進む必要があります。

3. インスタンス化された既存のまたは新しいロジカル・スタンバイ・データベースにより保護されるための機能が維持されるよう、元のプライマリ・データベースで対処措置を実行します。
スイッチオーバー操作のコミット中に発生したエラーの基となる原因を修正してSQL文(ALTER DTABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY)を再発行します。次の手順を実行することもできます。

1. スイッチオーバー・コマンドのコミットを開始したインスタンスのアラート・ログから、元のプライマリへのフラッシュバックに必要なSCNを判別します。この情報は、SQL文ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBYの後に表示されます。

LOGSTDBY: Preparing the COMMIT TO SWITCHOVER TO LOGICAL STANDBY DDL at scn [flashback_scn].

2. プライマリ・データベースのすべてのインスタンスを停止します。

SQL> SHUTDOWN IMMEDIATE;

3. プライマリ・データベースを排他モードでマウントします。

SQL> STARTUP MOUNT;

4. データベースをアラート・ログから取得したSCNまでフラッシュバックします。

SQL> FLASHBACK DATABASE TO BEFORE SCN <flashback_scn>;

5. プライマリ・データベースをオープンします。

SQL> STARTUP;

6. 元のプライマリ・データベースのデータベース・ガードを低くします。

SQL> ALTER DATABASE GUARD NONE;

この時点で、プライマリの状態はスイッチオーバーのコミット・コマンドが発行される前と同一です。修正処理は必要ありません。スイッチオーバー操作のコミットに進むか、A.5.1.1項で説明するようにスイッチオーバー操作を取り消します。

A.5.2.2 ターゲット・ロジカル・スタンバイ・データベースの変換での障害

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY文の実行中に障害が発生した場合、次の手順を実行します。

1. ターゲット・スタンバイ・データベースのV$DATABASE固定ビューのDATABASE_ROLE列をチェックします。

SQL> SELECT DATABASE_ROLE FROM V$DATABASE;

- 列にPRIMARYの値が含まれる場合、スイッチオーバー操作は完了していますが、スイッチオーバー後のタスクで障害が発生しています。この場合、次の手順を実行します。

1. データベースを停止して、再オープンします。

2. ALTER DATABASE GUARD NONEコマンドを発行して、データベースに対する書込み制限を削除します。

- 列にLOGICAL STANDBYの値が含まれる場合、手順2に進みます。

2. ターゲット・ロジカル・スタンバイで次の問合せを実行します。

SQL> SELECT COUNT(*) FROM SYSTEM.LOGSTDBY$PARAMETERS -
> WHERE NAME = 'BEGIN_PRIMARY';

- 問合せで0が戻される場合、ロジカル・スタンバイの状態はスイッチオーバーのコミット・コマンドが発行される前と同一です。修正処理を実行する必要はありません。スイッチオーバー操作のコミットに進むか、A.5.1.2項で説明するようにスイッチオーバー操作を取り消します。

- 問合せで1が戻される場合、ロジカル・スタンバイは一貫性がない状態のため、手順3に進む必要があります。

3. 新しいプライマリまたは別の新しいプライマリに対するバイスタンダになるための機能が維持されるよう、ロジカル・スタンバイで対処措置を実行します。
スイッチオーバー操作のコミット中に発生したエラーの基となる原因を修正してSQL文(ALTER DTABASE COMMIT TO SWITCHOVER TO PRIMARY)を再発行します。次の手順を実行して、スイッチオーバーのコミットを試行する直前の一貫性の時点までロジカル・スタンバイ・データベースをフラッシュバックすることもできます。

1. スイッチオーバーのコミット・コマンドを開始したインスタンスのアラート・ログから、ロジカル・スタンバイへのフラッシュバックに必要なSCNを判別します。この情報は、SQL文ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARYの後に表示されます。

LOGSTDBY: Preparing the COMMIT TO SWITCHOVER TO PRIMARY DDL at scn [flashback_scn].

2. ターゲット・スタンバイ・データベースのすべてのインスタンスを停止します。

SQL> SHUTDOWN IMMEDIATE;

3. ターゲット・ロジカル・スタンバイ・データベースをマウントします。

SQL> STARTUP MOUNT;

4. 必要なSCNまでターゲット・ロジカル・スタンバイをフラッシュバックします。

SQL> FLASHBACK DATABASE TO BEFORE SCN <flashback_scn>;

5. データベースをオープンします(Oracle RACの場合、すべてのインスタンスをオープンします)。

SQL> STARTUP OPEN;

この時点で、ターゲット・スタンバイの状態はスイッチオーバーのコミット・コマンドが発行される前と同一です。対処措置を実行する必要はありません。スイッチオーバー操作のコミットに進みます。

A.6 SQL Applyが停止した場合の処置

適用サービスでは、サポートされないDML文、DDL文およびオラクル社が提供するパッケージを、SQL Applyが実行されているロジカル・スタンバイ・データベースに適用できません。

サポートされない文やパッケージが検出されると、SQL Applyは停止します。表A-2で説明する処理を実行して問題を解決した後、ロジカル・スタンバイ・データベースでSQL Applyを再開してください。

表A-2 一般的なSQL Applyエラーの解決方法

エラー

解決方法

サポートされない文またはオラクル社が提供するパッケージが検出された可能性を示すエラー

DBA_LOGSTDBY_EVENTSビューで、最後の文を検索してください。この結果、SQL Applyの失敗の原因となった文とエラーが表示されます。不適切なSQL文が原因でSQL Applyに失敗した場合は、その文とエラーに関する情報とともにトランザクション情報を表示できます。このトランザクション情報は、問題の原因を正確に判断するためにLogMinerツールで使用できます。

データベース管理を要求するエラー(特定の表領域内の領域不足など)

問題を解決した後、ALTER DATABASE START LOGICAL STANDBY APPLY文を使用してSQL Applyを再開してください。

不適切なSQL文の入力によるエラー(不適切なスタンバイ・データベースのファイル名が表領域文に入力された場合など)

適切なSQL文を入力した後、DBMS_LOGSTDBY.SKIP_TRANSACTIONプロシージャを使用して、次回SQL Applyが実行されたときに不適切な文が無視されるようにしてください。その後、ALTER DATABASE START LOGICAL STANDBY APPLY文を使用してSQL Applyを再開してください。

不適切なSKIPパラメータの設定によるエラー(特定の表で全DMLがスキップされるように指定したが、CREATE、ALTERおよびDROP TABLEの各文がスキップされるように指定していないなど)

DBMS_LOGSTDBY.SKIP('TABLE','schema_name','table_name',null)プロシージャを発行した後、SQL Applyを再開してください。

障害の原因を特定するためにDBA_LOGSTDBY_EVENTSビューを問い合せる方法は、第17章を参照してください。

A.7 REDOデータ転送のネットワーク調整

最適なパフォーマンスを得るには、REDO転送サービスで使用される各Oracle Net接続記述子で、Oracle Net SDUパラメータを32KBに設定します。

次の例は、データベース初期化パラメータ・ファイル内のリモート宛先netservを定義する部分を示します。

LOG_ARCHIVE_DEST_3='SERVICE=netserv'

次の例は、tnsnames.oraファイル内の該当するサービス名の定義を示しています。

netserv=(DESCRIPTION=(SDU=32768)(ADDRESS=(PROTOCOL=tcp)(HOST=host) (PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=srvc)))

次の例は、listener.oraファイル内の定義を示します。

LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)
(HOST=host)(PORT=1521))))

SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SDU=32768)(SID_NAME=sid)
(GLOBALDBNAME=srvc)(ORACLE_HOME=/oracle)))

待機時間が長いかまたは帯域幅が大きいネットワーク・リンクを使用してリモート・サイトへのアーカイブを行う場合は、Oracle Netプロファイル・パラメータのSQLNET.SEND_BUF_SIZEおよびSQLNET.RECV_BUF_SIZEを使用して、ネットワークの送受信I/Oバッファのサイズを大きくすることでパフォーマンスを改善できます。

Oracle NET SDUパラメータのその他の変更方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

A.8 スタンバイ・データベースのディスクのパフォーマンスが遅い

ファイル・システム上の非同期I/Oがパフォーマンス上の問題を示している場合は、ダイレクトI/Oオプションを使用してファイル・システムをマウントするか、またはFILESYSTEMIO_OPTIONS=SETALL初期化パラメータを設定します。最大I/Oのサイズ設定は、1MBです。

A.9 プライマリ・データベースの停止を回避するにはログ・ファイルを一致させる必要がある

構成内の1つ以上のスタンバイ・データベースでスタンバイREDOログを構成した場合は、各スタンバイ・データベースのスタンバイREDOログ・ファイルのサイズが、プライマリ・データベースのオンラインREDOログ・ファイルのサイズと正確に一致していることを確認してください。

ログ・スイッチが発生したときに、プライマリ・データベースに新しい現行のオンラインREDOログ・ファイルのサイズと一致する使用可能なスタンバイREDOログ・ファイルがない場合、次のようになります。

- プライマリ・データベースが最大保護モードで作動しているときは停止します。
または

- スタンバイ・データベース上のRFSプロセスにより、スタンバイ・データベースにアーカイブREDOログ・ファイルが作成され、次のメッセージがアラート・ログに書き込まれます。

No standby log files of size <#> blocks available.

たとえば、プライマリ・データベースで、ログ・ファイルが100KのオンラインREDOログ・グループを2つ使用する場合、スタンバイ・データベースは、ログ・ファイル・サイズが100KのスタンバイREDOログ・グループを3つ持ちます。

また、REDOログ・グループをプライマリ・データベースに追加するたびに、対応するスタンバイREDOログ・グループをスタンバイ・データベースに追加する必要があります。これによって必要なサイズのスタンバイREDOログ・ファイルがログ・スイッチ時に使用できないことにより、プライマリ・データベースに悪影響が発生する可能性が軽減できます。

A.10 ロジカル・スタンバイ・データベースのトラブルシューティング

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

- エラーのリカバリ

- SQL*Loaderセッションのトラブルシューティング

- 長時間実行トランザクションのトラブルシューティング

- フラッシュバック・トランザクションでのORA-1403エラーのトラブルシューティング

A.10.1 エラーのリカバリ

ロジカル・スタンバイ・データベースでは、ユーザー表、順序およびジョブがメンテナンスされます。他のオブジェクトをメンテナンスするには、REDOデータ・ストリームにあるDDL文を再発行する必要があリます。

SQL Applyに障害が発生した場合、エラーはDBA_LOGSTDBY_EVENTS表に記録されます。次の各項では、このようなエラーのリカバリ方法を説明します。

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

DDL文は、プライマリ・データベースとロジカル・スタンバイ・データベースでは同じ方法で実行されます。基礎となるファイル構造が両方のデータベースで同じ場合、DDLはスタンバイ・データベース上で予想どおりに実行されます。

エラーの原因が、ロジカル・スタンバイ・データベース環境に適合しないファイル仕様を含んだDDLトランザクションにある場合は、次の手順を実行して問題を解決してください。

1. ALTER SESSION DISABLE GUARD文を使用してデータベース・ガードをバイパスし、ロジカル・スタンバイ・データベースへの変更を可能にします。

SQL> ALTER SESSION DISABLE GUARD;

2. 正しいファイル仕様を使用してDDL文を実行し、データベース・ガードを再び使用可能にします。次に例を示します。

SQL> ALTER TABLESPACE t_table ADD DATAFILE '/dbs/t_db.f' SIZE 100M REUSE;
SQL> ALTER SESSION ENABLE GUARD;

3. ロジカル・スタンバイ・データベースでSQL Applyを開始し、障害が発生したトランザクションをスキップします。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE -
> SKIP FAILED TRANSACTION;

トランザクション障害の原因となった問題を修正し、トランザクションをスキップせずにSQL Applyを再開できる場合があります。たとえば、使用可能領域がすべて使用された場合などです。(DDLトランザクションをスキップするときに、プライマリおよびロジカル・スタンバイ・データベースの内容にずれを生じさせないようにしてください。可能な場合は、スキップされたトランザクションのかわりに補足用トランザクションを手動で実行する必要があります。)

次の例に、SQL Applyの停止、エラーの修正およびSQL Applyの再開を示します。

SQL> SET LONG 1000
SQL> ALTER SESSION SET NLS_DATE_FORMAT  = 'DD-MON-YY HH24:MI:SS';

Session altered.

SQL> SELECT EVENT_TIME, COMMIT_SCN, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS;

EVENT_TIME              COMMIT_SCN
------------------ ---------------
EVENT
-------------------------------------------------------------------------------
STATUS
-------------------------------------------------------------------------------
22-OCT-03 15:47:58

ORA-16111: log mining and apply setting up

22-OCT-03 15:48:04          209627
insert into "SCOTT"."EMP"
values
"EMPNO" = 7900,
"ENAME" = 'ADAMS',
"JOB" = 'CLERK',
"MGR" IS NULL,
"HIREDATE" = TO_DATE('22-OCT-03', 'DD-MON-RR'),
"SAL" = 950,
"COMM" IS NULL,
"DEPTNO" IS NULL
ORA-01653: unable to extend table SCOTT.EMP by %200 bytes in tablespace T_TABLE

この例で、ORA-01653メッセージは、表領域がいっぱいで表を拡張できないことを示しています。問題を修正するには、新しいデータファイルを表領域に追加します。次に例を示します。

SQL> ALTER TABLESPACE t_table ADD DATAFILE '/dbs/t_db.f' SIZE 60M;
Tablespace altered.

次に、SQL Applyを再開します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.

SQL Applyを再開すると、障害が発生したトランザクションが再実行され、ロジカル・スタンバイ・データベースに適用されます。

A.10.1.2 DML障害のリカバリ

DML障害のフィルタ処理には、SKIP_TRANSACTIONプロシージャを使用しないでください。また、スキップされたイベント表にあるDMLのみでなく、トランザクションに関連しているすべてのDMLについても注意が必要です。これが複数の表の原因となります。

DML障害は通常、特定の表に関する問題を示しています。たとえば、障害が即時に解決できない記憶域の不足に関するエラーであるとします。次の手順は、この問題に応答する1つの方法を示しています。

1. 表をスキップ・リストに追加することによって、トランザクションではなく、表をバイパスします。

SQL> EXECUTE DBMS_LOGSTDBY.SKIP('DML','SCOTT','EMP');
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

以降は、SCOTT.EMP表のDMLアクティビティは適用されません。DBMS_LOGSTDBYパッケージのプロシージャを実行するための管理者権限があるプライマリ・データベースにデータベース・リンクを設定している場合は、記憶域の問題を修正後、表を修正することができます。

2. プライマリ・データベースへのデータベース・リンクを使用して、ローカルなSCOTT.EMP表を削除し、表を再作成して、データをスタンバイ・データベースに転送します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE('SCOTT','EMP','PRIMARYDB');
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

3. 新規にインスタンス化された表とデータベースの残りの部分にまたがってビューの一貫性が得られるように、SQL Applyがプライマリ・データベースと一致するまで待機してから、この表を問い合せます。詳細な例は、10.5.5項「ロジカル・スタンバイ・データベースでの表の追加または再作成」を参照してください。

A.10.2 SQL*Loaderセッションのトラブルシューティング

Oracle SQL*Loaderには、様々なソースからOracle Databaseにデータをロードする方法が用意されています。この項では、SQL*Loaderユーティリティの一部のSQL Apply関連機能について説明します。

選択したデータ・ロード方法に関係なく、SQL*Loader制御ファイルには、APPENDおよびREPLACEキーワードを介して、新規データのロード先となるOracle表の現在の内容に対して実行する作業を示す指示が含まれています。次の例に、これらのキーワードをLOAD_STOKという表に使用する方法を示します。

- APPENDキーワードを使用すると、新規にロードされるデータはLOAD_STOK表の内容に追加されます。

LOAD DATA
INTO TABLE LOAD_STOK APPEND

- REPLACEキーワードを使用すると、LOAD_STOK表の内容が削除されてから新規のデータがロードされます。SQL*Loaderでは、DELETE文を使用して表の内容が1つのトランザクションでパージされます。

LOAD DATA
INTO TABLE LOAD_STOK REPLACE

SQL*LoaderスクリプトにREPLACEキーワードを使用するかわりに、データのロード前に、プライマリ・データベースの表に対してSQL*Plus TRUNCATE TABLEコマンドを発行することをお薦めします。TRUNCATE TABLEコマンドがオンラインのREDOログ・ファイルに記録され、ロジカル・スタンバイ・データベース上のSQL Applyによって発行されるので、これによってプライマリとスタンバイの両方のデータベースの表コピーを、高速に、そして効率よくパージするのと同じ効果が得られます。

SQL*Loaderスクリプトに引き続きREPLACEキーワードを挿入することはできますが、プライマリ・データベースではオブジェクトからの0(ゼロ)行のDELETEが試行されます。プライマリ・データベースから行が削除されていないため、REDOログ・ファイルにREDOは記録されません。したがって、ロジカル・スタンバイ・データベースに対してDELETE文は発行されません。

SQL文TRUNCATE TABLEを使用せずにREPLACEキーワードを発行すると、トランザクションをロジカル・スタンバイ・データベースに適用する必要がある場合に、SQL Applyに次のような問題が発生する可能性があります。

- 現在、表に多数の行が含まれている場合は、その行をスタンバイ・データベースから削除する必要があります。SQL Applyでは文の元の構文を判別できないため、プライマリ・データベースからパージする行ごとにDELETE文を発行する必要があります。
たとえば、プライマリ・データベースの表に最初は10,000行含まれていた場合、Oracle SQL*Loaderは1つのDELETE文を発行して10,000行をパージします。スタンバイ・データベースでは、SQL Applyはすべての行がパージされることを認識しないかわりに、10,000のDELETE文を個別に発行し、それぞれの文で1行ずつパージする必要があります。

- スタンバイ・データベースの表にSQL Applyで使用可能な索引が含まれていない場合、DELETE文では情報をパージするために全表スキャンが発行されます。
前述の例では、SQL Applyは10,000のDELETE文を個別に発行しているため、スタンバイ・データベースに対して10,000の全表スキャンが発行される可能性があります。

A.10.3 長時間実行トランザクションのトラブルシューティング

SQL Apply環境における長時間実行トランザクションの主な原因の1つは、全表スキャンです。また、索引の作成時や再作成時のように、SQL文がスタンバイ・データベースに複製されるために、長時間実行トランザクションが発生することもあります。

長時間実行トランザクションの識別

SQL Applyで1つのSQL文が長時間実行されている場合は、SQL Applyインスタンスのアラート・ログに次のような警告メッセージがレポートされます。

Mon Feb 17 14:40:15 2003
WARNING: the following transaction makes no progress
WARNING: in the last 30 seconds for the given message!
WARNING: xid =
0x0016.007.000017b6 cscn = 1550349, message# = 28, slavid = 1
knacrb: no offending session found (not ITL pressure)

この警告メッセージの注意事項は次のとおりです。

- この警告は、Interested Transaction List(ITL)が不十分な場合に戻される警告メッセージに似ていますが、最終行がknacrbで始まります。この最終行は、次のことを示しています。

- 全表スキャンが発生している可能性がある

- この発行では、Interested Transaction List(ITL)が不十分な状態に対して何も実行されない

- この警告メッセージがレポートされるのは、1つの文の実行時間が30秒を超える場合のみです。

長時間実行文で実行されているSQL文を判別できない場合がありますが、次のSQL文を発行すると、SQL Applyが作業中のデータベース・オブジェクトを識別できます。

SQL> SELECT SAS.SERVER_ID -
>  , SS.OWNER -
>  , SS.OBJECT_NAME -
>  , SS.STATISTIC_NAME -
>  , SS.VALUE -
>  FROM V$SEGMENT_STATISTICS SS -
>  , V$LOCK L -
>  , V$STREAMS_APPLY_SERVER SAS -
>  WHERE SAS.SERVER_ID = &SLAVE_ID -
>  AND L.SID = SAS.SID -
>  AND L.TYPE = 'TM' -
>  AND SS.OBJ# = L.ID1;

また、次のSQL文を発行すると、実行ごとに多数のディスク読取りを発生させたSQL文を識別できます。

SQL> SELECT SUBSTR(SQL_TEXT,1,40) -
>  , DISK_READS -
>  , EXECUTIONS -
>  , DISK_READS/EXECUTIONS -
>  , HASH_VALUE -
>  , ADDRESS -
>  FROM V$SQLAREA -
>  WHERE DISK_READS/GREATEST(EXECUTIONS,1) > 1 -
>  AND ROWNUM < 10 -
>  ORDER BY DISK_READS/GREATEST(EXECUTIONS,1) DESC;

すべての表にプライマリ・キーの制約を定義すると、列が自動的にNOT NULLとして定義されるので、この方法をお薦めしています。プライマリ・キーの制約を定義できない表については、該当する列で索引をNOT NULLと定義する必要があります。該当する列が表に存在しない場合は表を確認し、可能であればSQL Applyをスキップします。次の手順では、SCOTTスキーマのFTS表に対して発行されたすべてのDML文をスキップする方法を説明します。

1. SQL Applyを停止します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered

2. SCOTT.FTS表について、すべてのDMLトランザクションのスキップ・プロシージャを構成します。

SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML' , -
>  schema_name => 'SCOTT' , -
>  object_name => 'FTS');
PL/SQL procedure successfully completed

3. SQL Applyを開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered

ITLが不十分な状態のトラブルシューティング

Interested Transaction List(ITL)が不十分な状態は、SQL Applyインスタンスのアラート・ログでレポートされます。例A-3に、警告メッセージの例を示します。

例A-3 ITLが不十分な状態に関してレポートされる警告メッセージ

Tue Apr 22 15:50:42 2003
WARNING: the following transaction makes no progress
WARNING: in the last 30 seconds for the given message!
WARNING: xid =
0x0006.005.000029fa cscn = 2152982, message# = 2, slavid = 17

リアルタイム適用の分析

例A-3のメッセージは、SQL Applyプロセス(slavid)#17が過去30秒にわたって進捗がなかったことを示しています。適用プロセスにより発行されているSQL文を判別するには、次の問合せを発行します。

SQL> SELECT SA.SQL_TEXT -
>  FROM V$SQLAREA SA -
>  , V$SESSION S -
>  , V$STREAMS_APPLY_SERVER SAS -
>  WHERE SAS.SERVER_ID = &SLAVEID -
>  AND S.SID = SAS.SID -
>  AND SA.ADDRESS = S.SQL_ADDRESS

SQL_TEXT
------------------------------------------------------------
insert into "APP"."LOAD_TAB_1" p("PK","TEXT")values(:1,:2)

ITLが不十分な状態を識別するには、次の例に示すようにV$LOCKビューを問い合せる方法もあります。TXロックのリクエスト値が4のセッションは、ITLが使用可能になるまで待機中です。

SQL> SELECT SID,TYPE,ID1,ID2,LMODE,REQUEST -
> FROM V$LOCK -
> WHERE TYPE = 'TX'

SID        TY ID1        ID2        LMODE      REQUEST
---------- -- ---------- ---------- ---------- ----------
8 TX     327688         48          6          0
10 TX     327688         48          0          4

この例では、SID 10はSID 8が保持しているTXロックを待機中です。

障害後のレビュー

セグメントのITLが不十分な状態が長時間続くことはまずありません。また、この状態の継続時間が30秒未満の場合、スタンバイ・データベースのアラート・ログではレポートされません。したがって、ITLが不十分な状態になっているオブジェクトを判別するには、次の文を発行します。

SQL> SELECT OWNER, OBJECT_NAME, OBJECT_TYPE -
>  FROM V$SEGMENT_STATISTICS -
>  WHERE STATISTIC_NAME = 'ITL waits' -
>  AND VALUE > 0 -
>  ORDER BY VALUE;

この文では、インスタンスが前回起動された後にITLが不十分な状態になったことのあるデータベース・セグメントがすべてレポートされます。

注意:
このSQL文は、Data Guard環境のロジカル・スタンバイ・データベースに限定されません。任意のOracleデータベースに適用されます。

ITLが不十分な状態の解消

特定のデータベース・オブジェクトのINITRANSの整数を増やすには、最初にSQL Applyを停止する必要があります。

関連項目:
データベース・オブジェクトに割り当てられた各データ・ブロック内に割り当てられた同時トランザクション・エントリの初期数である、INITRANS整数指定の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

次の例に、appスキーマ内の表load_tab_1のINITRANSを増やすための手順を示します。

1. SQL Applyを停止します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.

2. データベース・ガードを一時的にバイパスします。

SQL> ALTER SESSION DISABLE GUARD;
Session altered.

3. スタンバイ・データベースでINITRANSを増やします。次に例を示します。

SQL> ALTER TABLE APP.LOAD_TAB_1 INITRANS 30;
Table altered

4. データベース・ガードを再び使用可能にします。

SQL> ALTER SESSION ENABLE GUARD;
Session altered

5. SQL Applyを開始します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.

また、スイッチオーバー時に新しいスタンバイ・データベースでエラーが発生しないように、プライマリ・データベースでデータベース・オブジェクトを変更することを考慮してください。

A.10.4 フラッシュバック・トランザクションでのORA-1403エラーのトラブルシューティング

SQL Applyが「ORA-1403: データが見つかりません」 エラーを戻した場合は、失われたデータを再構築するためにフラッシュバック・トランザクションを使用することができます。これはスタンバイ・データベース・インスタンスで指定されたUNDO_RETENTION初期化パラメータに依存します。

通常は、ORA-1403エラーはロジカル・スタンバイ・データベース環境では発生しません。SQL Applyが管理している表内のデータがスタンバイ・データベースで直接変更され、同じデータがプライマリ・データベースで変更された場合にこのエラーが発生します。変更されたデータがプライマリ・データベースで更新され、その後ロジカル・スタンバイ・データベースで受信した場合、SQL Applyがレコードの更新前に、データの元のバージョンがスタンバイ・データベースに存在していることを検証します。この検証に失敗した場合は、「ORA-1403: データが見つかりません」エラーは戻されません。

初期エラー

SQL Applyが検証に失敗すると、ロジカル・スタンバイ・データベースのアラート・ログでエラー・メッセージがレポートされ、DBA_LOGSTDBY_EVENTSビューにレコードが挿入されます。アラート・ログ内の情報は切り捨てられますが、エラー全体がデータベース・ビューでレポートされます。次に例を示します。

LOGSTDBY stmt: UPDATE "SCOTT"."MASTER"
SET
"NAME" = 'john'
WHERE
"PK" = 1 and
"NAME" = 'andrew' and
ROWID = 'AAAAAAAAEAAAAAPAAA'
LOGSTDBY status: ORA-01403: no data found
LOGSTDBY PID 1006, oracle@staco03 (P004)
LOGSTDBY XID 0x0006.00e.00000417, Thread 1, RBA 0x02dd.00002221.10

調査

最初のステップは、エラーの原因となった表の履歴データを分析することです。そのためには、SELECT文のVERSIONS句を使用します。たとえば、プライマリ・データベースで次の問合せを発行できます。

SELECT VERSIONS_XID
, VERSIONS_STARTSCN
, VERSIONS_ENDSCN
, VERSIONS_OPERATION
, PK
, NAME
FROM SCOTT.MASTER
VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE
WHERE PK = 1
ORDER BY NVL(VERSIONS_STARTSCN,0);

VERSIONS_XID     VERSIONS_STARTSCN VERSIONS_ENDSCN V  PK NAME
---------------- ----------------- --------------- - --- -------
03001900EE070000           3492279         3492290 I   1 andrew
02000D00E4070000           3492290                 D   1 andrew

データベースに設定されたUNDO保存量(UNDO_RETENTION)と表のアクティビティによっては、戻される情報量が膨大になり、構文ごとにバージョンを変更して戻される情報量を制限する必要が生じることがあります。戻された情報から、最初にSCN 3492279でレコードが挿入され、トランザクションID 02000D00E4070000の一環として、SCN 3492290で削除されことがわかります。このトランザクションIDを使用してデータベースの問合せを行い、トランザクション・スコープを検出する必要があります。これはFLASHBACK_TRANSACTION_QUERYビューの問合せによって行うことができます。

SELECT OPERATION
, UNDO_SQL
FROM FLASHBACK_TRANSACTION_QUERY
WHERE XID = HEXTORAW('02000D00E4070000');

OPERATION  UNDO_SQL
---------- ------------------------------------------------
DELETE     insert into "SCOTT"."MASTER"("PK","NAME") values
('1','andrew');
BEGIN

トランザクションの開始を表す1行が必ず戻されることに注意してください。このトランザクションでは、マスター表から削除されたのは1行のみです。実行時のUNDO_SQL列では、元のデータが表にリストアされます。

SQL> INSERT INTO "SCOTT"."MASTER"("PK","NAME") VALUES ('1','ANDREW');SQL> COMMIT;

SQL Applyを再開すると、トランザクションがスタンバイ・データベースに適用されます。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

B Data Guard構成におけるデータベースのアップグレードおよびダウングレード

この付録の手順では、Data Guard構成にフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースが存在する場合に、Oracleデータベースをアップグレードおよびダウングレードする方法を説明します。

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

- Oracle Databaseソフトウェアをアップグレードする前の注意事項

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

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

- アップグレード後のCOMPATIBLE初期化パラメータの変更

- ロジカル・スタンバイが存在しない場合のOracle Databaseのダウングレード

- ロジカル・スタンバイが存在する場合のOracle Databaseのダウングレード

B.1 Oracle Databaseソフトウェアをアップグレードする前の注意事項

Oracle Databaseソフトウェアのアップグレードを開始する前に、次のことに注意してください。

- Data Guardブローカを使用して構成を管理している場合は、ブローカ構成の削除や無効化の詳細は、『Oracle Data Guard Broker』マニュアルの指示を参照してください。

- この付録で説明する手順は、『Oracle Databaseアップグレード・ガイド』に記載されている手順とともに使用します。

- NOLOGGING操作をチェックします。NOLOGGING操作が実行されていた場合は、スタンバイ・データベースを更新する必要があります。詳細は、13.4項「NOLOGGING句を指定した後のリカバリ」を参照してください。

- OFFLINE IMMEDIATEが原因でリカバリを必要とする表領域またはデータファイルを書き留めておきます。アップグレード前に表領域またはデータファイルをリカバリし、オンラインまたはオフラインにする必要があります。

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

構成にフィジカル・スタンバイ・データベースが存在する場合に、Oracle Database 11gリリース2(11.2)にアップグレードする手順は、次のとおりです。

1. 『Oracle Databaseアップグレード・ガイド』のアップグレードの準備に関する項に記載されている手順を確認して実行します。

2. 『Oracle Databaseアップグレード・ガイド』に従って、Oracleソフトウェアの新しいリリースを、フィジカル・スタンバイ・データベースとプライマリ・データベース・システムの新しいOracleホームにインストールします。

3. プライマリ・データベースを停止します。

4. フィジカル・スタンバイ・データベースを停止します。

5. アップグレード対象のOracleホームで実行しているすべてのリスナー、エージェントおよびその他のプロセスを停止します。この手順は、Oracle Real Application Cluster(Oracle RAC)環境のすべてのノードで実行します。

6. Oracle Automatic Storage Management(Oracle ASM)が使用中の場合は、Oracle ASMを使用するすべてのデータベースを停止してから、すべてのOracle ASMインスタンスを停止します。

7. 新しいOracleホームで、手順5で停止したすべてのリスナー、エージェントおよびその他のプロセスを再起動します。

8. フィジカル・スタンバイ・データベースを、新しいOracleホーム(アップグレード済バージョン)にマウントします。フィジカル・スタンバイ・データベースの起動方法の詳細は、3.2.6項を参照してください。

注意:
プライマリ・データベースのアップグレードが完了してから、スタンバイ・データベースをオープンします。

9. フィジカル・スタンバイ・データベースでREDO Applyを開始します。REDO Applyの起動方法の詳細は、3.2.6項を参照してください。

10. 『Oracle Databaseアップグレード・ガイド』に従ってプライマリ・データベースをアップグレードします。フィジカル・スタンバイ・データベースは、プライマリ・データベースでアップグレード時に生成されたREDOを適用するとアップグレードされます。

11. アップグレード後のプライマリ・データベースをオープンします。

12. アップグレードの前にActive Data Guardが使用されている場合、これをアップグレード後に再び有効にする方法は9.2.1項を参照してください。

13. オプションで、B.4項で説明されている手順に従い、COMPATIBLE初期化パラメータを変更します。

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

注意:
この付録では、ロジカル・スタンバイ・データベースが存在する場合にOracle Databaseソフトウェアをアップグレードする従来の方法を説明します。第12章「SQL Applyを使用したOracle Databaseのアップグレード」にある2つ目の方法では、ロジカル・スタンバイ・データベースが存在する場合にローリング・アップグレードを行って停止時間を最短に抑える方法を説明します。完全なアップグレードを実行するには、どちらか一方の方法の手順のみを使用してください。アップグレードの実行に両方の方法を使用したり、2つの方法の手順を組み合せようとしないでください。
この項で説明する手順では、プライマリ・データベースがMAXIMUM PERFORMANCEデータ保護モードで稼働していると仮定しています。

構成にロジカル・スタンバイ・データベースが存在する場合に、Oracle Database 11gリリース2(11.2)にアップグレードする手順は、次のとおりです。

1. 『Oracle Databaseアップグレード・ガイド』のアップグレードの準備に関する項に記載されている手順を確認して実行します。

2. 必要に応じて、プライマリ・データベースでデータ保護モードをMAXIMUM PERFORMANCEに設定します。

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

3. プライマリ・データベースで、すべてのユーザー・アクティビティを停止し、ロジカル・スタンバイ・データベースに関連付けられているリモート・アーカイブ先を遅延させます(この手順では、LOG_ARCHIVE_DEST_2がロジカル・スタンバイ・データベースに関連付けられていると仮定しています)。

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=BOTH;
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

4. ロジカル・スタンバイ・データベースでSQL Applyを停止します。

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

5. 『Oracle Databaseアップグレード・ガイド』に従って、プライマリ・データベースにOracleソフトウェアの新しいリリースをインストールします。

6. 『Oracle Databaseアップグレード・ガイド』に従って、ロジカル・スタンバイ・データベースにOracleソフトウェアの新しいリリースをインストールします。

注意:
手順5および手順6は、アップグレード手順中の停止時間を短縮するために、同時に実行できます(つまり、プライマリ・データベースとスタンバイ・データベースは同時にアップグレードできます)。

7. アップグレード後のロジカル・スタンバイ・データベースでSQL Applyを開始します。Oracle RACを使用している場合は、他のスタンバイ・データベース・インスタンスを起動します。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

8. アップグレード後のプライマリ・データベースをオープンし、ユーザーが接続できるようにします。Oracle RACを使用している場合は、他のプライマリ・データベース・インスタンスを起動します。
また、次のようにして、アップグレード後のロジカル・スタンバイ・データベースへのアーカイブを有効にします。

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

9. 必要に応じて、手順2で元のデータ保護モードを変更した場合は、そのモードをリセットします。

10. オプションで、B.4項で説明されている手順に従い、COMPATIBLE初期化パラメータを変更します。

B.4 アップグレード後のCOMPATIBLE初期化パラメータの変更

Oracle Databaseの新リリースにアップグレードする際、一部の新機能のためにデータベースが前のリリースと互換性がなくなる場合があります。Oracle Databaseでは、COMPATIBLE初期化パラメータにより、データベースの互換性を制御できます。

アップグレードが完了したら、COMPATIBLE初期化パラメータの設定をOracle Databaseの新リリース用に最大レベルに増やすことができます。データベースを元のリリースにダウングレードする機能がもう必要ないことが確実な場合は、COMPATIBLE初期化パラメータを新しいデータベースで必要な互換性レベルに基づいて設定します。

Data Guard構成で、アップグレード後にCOMPATIBLE初期化パラメータの設定を増やすことにした場合、次の手順を示した順序どおりに実行することが重要です(スタンバイ・データベースのCOMPATIBLE設定が、プライマリと同じか、あるいはそれ以上であることが必要です)。

1. まず、構成内のすべてのスタンバイ・データベースのCOMPATIBLE初期化パラメータの値を、次のように増やします。

1. 適用がスタンバイ・データベースで最新であることを確認します。

2. 各スタンバイ・データベースの1つのインスタンスで、次のSQL文を実行します。

ALTER SYSTEM SET COMPATIBLE=<value> SCOPE=SPFILE;

3. REDO ApplyまたはSQL Applyが実行中の場合は、停止します。

4. スタンバイ・データベースのすべてのインスタンスを再起動します。

5. 前にREDO ApplyまたはSQL Applyを停止した場合は、再起動します。

2. プライマリ・データベースでCOMPATIBLE初期化パラメータの値を、+次のように増やします。

1. プライマリ・データベースの1つのインスタンスで、次のSQL文を実行します。

ALTER SYSTEM SET COMPATIBLE=<value> SCOPE=SPFILE;

2. プライマリ・データベースのすべてのインスタンスを再起動します。

関連項目:

- 互換性の設定の詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

B.5 ロジカル・スタンバイが存在しない場合のOracle Databaseのダウングレード

ロジカル・スタンバイ・データベースが存在しないData Guard構成でOracle Databaseをダウングレードするには、次の手順を実行します。

1. すべてのフィジカル・スタンバイ・データベースがマウント済で、オープンされていないことを確認します。

注意:
スタンバイ・データベースは、プライマリ・データベースのダウングレードによって生成されたすべてのREDOが適用されるまでオープンしないでください。

2. フィジカル・スタンバイ・データベースでREDO Applyをリアルタイム適用モードで開始します。

3. 『Oracle Databaseアップグレード・ガイド』で説明されている手順を使用し、次のことを念頭に置いて、プライマリ・データベースをダウングレードします。

- ダウングレード手順においてスクリプトを実行する各手順では、プライマリ・データベースでのみスクリプトを実行します。プライマリ・データベースでのスクリプトの実行により生成されたすべてのREDOが、各フィジカル・スタンバイ・データベースに適用されるまで、次のダウングレード手順を実行しないでください。

- ダウングレード手順においてスクリプトの実行以外のアクションが実行される各手順では、まずその手順をプライマリ・データベースで実行してから、各フィジカル・スタンバイ・データベースで実行します。そのアクションが各フィジカル・スタンバイ・データベースで実行されるまで、プライマリ・データベースで次のダウングレード手順を実行しないでください。

4. ダウングレード中にフェイルオーバーの実行が必要になった場合、フェイルオーバーを実行してから、新しいプライマリ・データベースでダウングレード手順を続行します。

B.6 ロジカル・スタンバイが存在する場合のOracle Databaseのダウングレード

ロジカル・スタンバイが存在するか、ロジカルとフィジカルのスタンバイ・データベースが混在するData Guard構成でOracle Databaseをダウングレードするには、次の手順を実行します。

1. プライマリ・データベース(ここではデータベースP)で、ダウングレードする前に、次のコマンドを発行します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;

データベースPは、プライマリ・データベース・ロールではなくなります。

2. 構成内のすべてのスタンバイ・データベースで、使用可能なすべてのREDOの適用が終了するまで待ちます。各スタンバイ・データベースで使用可能なすべてのREDOの適用が終了したかどうかを確認するために、各スタンバイ・データベースで次の問合せを実行します。

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO PRIMARY

問合せにより構成内のすべてのスタンバイ・データベースについてTO PRIMARYの値が戻されるまで、手順3に進まないでください。

3. 『Oracle Databaseアップグレード・ガイド』で説明されている手順を使用し、次のことを念頭に置いて、ロジカル・スタンバイ・データベースをダウングレードします。

- ダウングレード手順においてスクリプトを実行する各手順では、ロジカル・スタンバイ・データベースでのみスクリプトを実行します。直前までプライマリ・ロール(データベースP)であったロジカル・スタンバイ・データベースでスクリプトを実行することにより生成されたすべてのREDOが、各フィジカル・スタンバイ・データベースに適用されるまで、次のダウングレード手順を実行しないでください。

- ダウングレード手順においてスクリプトの実行以外のアクションが実行される各手順では、まずその手順を直前までプライマリ・ロール(データベースP)であったロジカル・スタンバイ・データベースで実行してから、各フィジカル・スタンバイ・データベースで実行します。そのアクションが各フィジカル・スタンバイ・データベースで実行されるまで、直前までプライマリ・ロール(データベースP)であったロジカル・スタンバイ・データベースで次のダウングレード手順を実行しないでください。

4. 直前までプライマリ・ロール(データベースP)であったロジカル・スタンバイが正常にダウングレードされたら、それをオープンし、次のコマンドを発行します。

SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE;

これでデータベースPは、プライマリ・ロールに戻りました。

5. 構成内の各ロジカル・スタンバイ・データベースで、次のコマンドを発行します(このコマンドでは、プライマリに戻るデータベース・リンクがすべてのロジカル・スタンバイ・データベースに存在することが必要です)。

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY
prim_db_link;

関連項目:
『Oracle Databaseアップグレード・ガイド』

C ロジカル・スタンバイ・データベースでサポートされるデータ型およびDDL

ロジカル・スタンバイ・データベースの設定では、ロジカル・スタンバイ・データベースがプライマリ・データベースのデータ型と表を維持していることを確認する必要があります。この付録では、ロジカル・スタンバイ・データベースのサポート対象および対象外の各種データベース・オブジェクト、ストレージ・タイプ、PL/SQL供給パッケージをリストにまとめています。この付録には、次の項があります。

- データ型に関する考慮事項

- 透過的データ暗号化(TDE)のサポート

- 表領域の暗号化のサポート

- 行レベル・セキュリティおよびファイングレイン監査のサポート

- Oracle Label Security

- Oracle E-Business Suite

- サポートされる表記憶域タイプ

- サポートされない表記憶域タイプ

- PL/SQLパッケージに関する考慮事項

- サポートされない表

- ロジカル・スタンバイ・データベースでスキップされるSQL文

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

- 分散トランザクションおよびXAのサポート

- SecureFile LOBのサポート

- キャラクタ・セットに関する考慮事項

C.1 データ型に関する考慮事項

次の各項では、データベース・オブジェクトについて、サポートされるものとサポートされないものを示します。

- ロジカル・スタンバイ・データベースでサポートされるデータ型

- ロジカル・スタンバイ・データベースでサポートされないデータ型

C.1.1 ロジカル・スタンバイ・データベースでサポートされるデータ型

ロジカル・スタンバイ・データベースでは、次のデータ型がサポートされます。

- BINARY_DOUBLE

- BINARY_FLOAT

- BLOB

- CHAR

- CLOBおよびNCLOB

- DATE

- INTERVAL YEAR TO MONTH

- INTERVAL DAY TO SECOND

- LONG

- LONG RAW

- NCHAR

- NUMBER

- NVARCHAR2

- RAW

- TIMESTAMP

- TIMESTAMP WITH TIMEZONE

- TIMESTAMP WITH LOCAL TIMEZONE

- VARCHARおよびVARCHAR2

- SecureFileとして格納されるLOBには、11.2以上の互換性で動作するプライマリ・データベースが必要です。C.14項「SecureFile LOBのサポート」を参照してください。

- 次のプライマリ・データベース互換性要件を仮定した場合は、すべてのストレージ・モデルのXMLTypeデータ。

- CLOB形式で格納されるXMLTypeには、11.1以上の互換性で動作するプライマリ・データベースが必要です。

- オブジェクト・リレーショナル形式またはバイナリXMLで格納されるXMLTypeには、11.2.0.3以上のREDO互換性が設定されたOracle Database 11gリリース2(11.2.0.3)以上でプライマリ・データベースを実行している必要があります。

C.1.1.1 互換性要件

次に対するSQL Applyサポートでは、プライマリ・データベースに対する互換性要件があります。

- マルチバイトのCLOBサポートには、10.1以上の互換性で動作するプライマリ・データベースが必要です。

- LOBおよびオーバーフローなしのIOTサポートには、10.1以上の互換性で動作するプライマリ・データベースが必要です。

- LOBおよびオーバーフローありのIOTサポートには、10.2以上の互換性で動作するプライマリ・データベースが必要です。

- TDEサポートには、11.1以上の互換性で動作するプライマリ・データベースが必要です。

- セグメント圧縮には、11.1以上の互換性で動作するプライマリ・データベースが必要です。

- ハイブリッド列圧縮サポートは、基礎となるストレージ・システムに依存します。

関連項目:

- ハイブリッド列圧縮の詳細は、『Oracle Database概要』を参照してください。

C.1.2 ロジカル・スタンバイ・データベースでサポートされないデータ型

次のデータ型はロジカル・スタンバイ・データベースではサポートされていません。表にサポートされていないこれらのデータ型が含まれている場合、SQL Applyを実行しても表全体が無視されます。

BFILE
コレクション(VARRAYSおよびネストされた表を含む)
マルチメディア・データ型(Spatial、ImageおよびOracle Textを含む)
ROWID、UROWID
ユーザー定義型

C.2 透過的データ暗号化(TDE)のサポート

Data Guard SQL Applyを使用すると、透過的データ暗号化(TDE)を有効に設定したプライマリ・データベースにデータ保護を提供できます。ロジカル・スタンバイ・データベースを使用し、高度なセキュリティ要件を伴うアプリケーションにデータ保護を提供する場合は、次のことを考慮してください。

- サーバーが保持する鍵を使用する透過的データ暗号化が指定された表は、プライマリ・データベースとスタンバイ・データベースの両方が11.1以上の互換性レベルで稼働している場合のロジカル・スタンバイ・データベースで複製されます。

- ハードウェア・セキュリティ・モジュールの下での透過的データ暗号化は、11gリリース1のロジカル・スタンバイ・データベースではサポートされません。

ロジカル・スタンバイ・データベースの下では、暗号化された列が含まれる表をレプリケートするときに、次の制限事項を考慮する必要があります。

1. 暗号化されたREDOレコードを変換するには、透過的データ暗号化鍵を含むオープン・ウォレットへのアクセス権がSQL Applyに必要です。そのため、鍵を含むウォレットの作成後に、そのウォレットをプライマリ・データベースからスタンバイ・データベースにコピーする必要があります。

2. ウォレットは、マスター鍵が変更されるたびに、プライマリ・データベースからロジカル・スタンバイ・データベースにコピーする必要があります。

3. ロジカル・スタンバイ・データベースでは、プライマリ・データベースから暗号化された表をレプリケートしている間、マスター鍵をREKEY(鍵の変更)しないことをお薦めします。これは、暗号化されたREDOレコードの検出時にSQL Applyが停止する原因になります。

4. ロジカル・スタンバイ・データベースでは、レプリケートされた表の暗号化鍵をREKEYできます。このためには、REKEYコマンドを発行する前にガード設定をNONEにして低くする必要があります。

5. レプリケートされた暗号化された表では、プライマリ・データベースで使用された暗号化方式とは異なる方式を列に対して使用できます。たとえば、HR.EMPLOYEES表のSALARY列がプライマリ・データベースでAES102暗号化アルゴリズムを使用して暗号化される場合、ロジカル・スタンバイではAES256暗号化アルゴリズムを使用して暗号化することができます。あるいは、ロジカル・スタンバイ・データベースでは、SALARY列を暗号化しないままにしておくことも可能です。

C.3 表領域の暗号化のサポート

Data Guard SQL Applyを使用すると、表領域の暗号化を有効に設定したプライマリ・データベースにデータ保護を提供できます。その場合、C.2項「透過的データ暗号化(TDE)のサポート」に示した制限事項1、2および3が適用されます。

注意:
暗号化された表領域の表に対する変更に、SQL ApplyがREDOレコードをマイニングおよび適用した際、暗号化されていない形式のユーザー・データのレコードが長時間維持される場合があります。これを許容できない場合、次のコマンドを発行して、暗号化された表領域へのSQL Applyのコンポーネントのマイニングに関係するすべてのメタデータ表を移動します。

SQL> DBMS_LOGMNR_D.SET_TABLESPACE(NEW_TABLESPACE => 'ENCRYPTED_LOGMNR_TS');

C.4 行レベル・セキュリティおよびファイングレイン監査のサポート

Oracle Database 11gでは、ロジカル・スタンバイによってDBMS_RLSおよびDBMS_FGA PL/SQLパッケージで提供されているセキュリティ環境を自動的にレプリケートすることができます。このサポートによりセキュリティ環境が透過的に維持されるので、サーバーをスタンバイにフェイルオーバーする際に、セキュリティに配慮した管理の手間が軽減されます。また、プライマリ・データに適用されたアクセス・コントロール・ポリシーを自動的にスタンバイに必ず転送し、スタンバイ・データに同等な保護レベルを付与することができます。スタンバイ・サーバーを11gで新しく作成すると、このレプリケーションはデフォルト設定で有効化されますが、それ以外の場合はDBAが適宜有効化する必要があります。

これらのPL/SQLパッケージのレプリケーションをサポートするには、プライマリとスタンバイの両方が11.1以上の互換性設定で稼働している必要があります。

また、参照される表は、ロジカル・スタンバイよって保持されるオブジェクトである必要があります。たとえば、ROWID列を含む表のデータがロジカル・スタンバイによって保持されない場合、その表を参照するDBMS_RLSおよびDBMS_FGAコールも保持されません。

C.4.1 行レベルのセキュリティ

行レベルのセキュリティは、仮想プライベート・データベース(VPD)とも呼ばれる機能で、表、ビューまたはシノニムにアクセスするときに、セキュリティの粒度をFINEレベルにまで強化します。VPDポリシーで保護された表、ビューまたはシノニムに直接または間接的にユーザーがアクセスすると、サーバーはそのユーザーのSQL文を動的に変更します。この変更では、セキュリティ・ポリシーを実装するファクンションによって戻されるWHERE条件(述語)が作成されます。文は、ファンクションで表される条件あるいはファンクションによって戻される条件を使用して、ユーザーに対して透過的に、動的に変更されます。VPDポリシーは、SELECT、INSERT、UPDATE、INDEXおよびDELETE文に適用されます。VPDは、DBMS_RLSパッケージを使用してセキュリティ・ポリシーを適用すると実装されます。

DBMS_RLSプロシージャをプライマリで実行すると、追加情報がREDOに取得されるため、スタンバイでプロシージャ・コールを論理的に再構築して実行することができます。ロジカル・スタンバイでは、VPDの補助オブジェクト(コンテキスト、データベース・ログオン、トリガー、サポート対象パッケージなど)をレプリケートできます。これらのオブジェクトが保持されるスキーマに存在し、レプリケーションを停止させるDDLスキップが構成されていないことを確認する必要があります。

C.4.2 ファイングレイン監査

きめ細かい監査により、select文を監査することができます。DBMS_FGAパッケージでは、表にアクセスするすべてのselect文を、アクセスしたデータとともに取得することができます。FGAポリシーは特定の列、または指定された述語戻り値がTRUEの行を戻す、select文にも適用することができます。

DBMS_FGAプロシージャをプライマリで実行すると、追加情報がREDOに取得されるため、スタンバイでプロシージャ・コールを論理的に再構築して実行することができます。

C.4.3 PL/SQLレプリケーションのスキップおよび有効化

パッケージとプロシージャでのワイルドカードの指定がサポートされていない点を除き、PL/SQLにはDDL文とまったく同様なskipとskip_errorルールを設定することができます。たとえばVPDのすべての点をスキップするには、次を実行します。

DBMS_LOGSTDBY.Skip (
stmt => 'PL/SQL',
schema_name => 'SYS',
object_name =>'DBMS_RLS',
use_like => FALSE);

指定されたスキーマが、パッケージが定義されているスキーマであることに注意してください。パッケージの個々のプロシージャをスキップする場合の構文は、次のようになります。

DBMS_LOGSTDBY.Skip (
stmt => 'PL/SQL',
schema_name => 'SYS',
object_name =>'DBMS_RLS.Add_Policy',
use_like => FALSE);

特定のスキーマや表でVPDをスキップするには、スキップ・プロシージャを使用する必要があります。スキップ・プロシージャには、たとえば次のような実行予定の完全修飾PL/SQL文が渡されます。

DBMS_RLS.Drop_Policy(
object_schema => 'SCOTT,
object_name  => 'EMP',
policy_name => 'MYPOLICY');

すると、プロシージャは、文を解析してスキップするか、適用するか、適用を中止してDBAに補正アクションを実行させるかを決定します。

DDLとは異なり、PL/SQLに対するスキップ・プロシージャは代用文を戻しません。

C.5 Oracle Label Security

ロジカル・スタンバイ・データベースでは、Oracle Label Securityをサポートしません。Oracle Label Securityをプライマリ・データベースにインストールすると、開始時に内部エラーが発生してSQL Applyはロジカル・スタンバイ・データベースで失敗します。

C.6 Oracle E-Business Suite

ロジカル・スタンバイ・データベースは、サポートされていないデータ型を含む表があるため、Oracle E-Business Suite実装を完全にはサポートしていません。しかし、SKIPルールを使用して、E-Business Suiteスキーマと表のサブセットを複製し、アプリケーションをロジカル・スタンバイにオフロードすることは可能です。

関連項目:
Oracle E-Business Suiteでのロジカル・スタンバイ使用の詳細は、http://support.oracle.comのMy Oracle Supportノート851603.1を参照してください。

C.7 サポートされる表記憶域タイプ

ロジカル・スタンバイ・データベースでは、次の表記憶域タイプがサポートされます。

- クラスタ表(索引クラスタおよびヒープ・クラスタを含む)

- 索引構成表(オーバーフロー・セグメントを含むパーティション化および非パーティション化)

- ヒープ構成表(パーティション化および非パーティション化)

- OLTP表圧縮(COMPRESS FOR OLTP)および基本表圧縮(COMPRESS BASIC)OLTP表圧縮および基本表圧縮では、プライマリ・データベースの互換性設定が11.1.0以上に設定されている必要があります。

- 仮想列を含む表(表にロジカル・スタンバイでサポートされていない他の列またはプロパティがない場合)。これは、Oracle Database 11g リリース2(11.2.0.3)以上でのみサポートされます。

- ハイブリッド列圧縮を使用する表

関連項目:

- ハイブリッド列圧縮の詳細は、『Oracle Database概要』を参照してください。

C.8 サポートされない表記憶域タイプ

ロジカル・スタンバイでは、次のデータ型のみを含む表はサポートされません。

- LOB (CLOB、NCLOB、BLOB)

- LONG

- LONG RAW

- OBJECT TYPE

- COLLECTIONS

- XML

関連項目:
SecureFile LOBのサポート

C.9 PL/SQLパッケージに関する考慮事項

この項では、PL/SQLパッケージに関する次の考慮事項について説明します。

- サポートされるPL/SQLパッケージ

- サポートされないPL/SQLパッケージ

- ロジカル・スタンバイでのXMLおよびXDB PL/SQLパッケージの処理

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

C.9.1 サポートされているPL/SQLパッケージ

システムのメタデータやユーザー・データを変更しない、オラクル社が提供するPL/SQLパッケージは、アーカイブREDOログ・ファイルにフットプリントを残さないため、プライマリ・データベースで安全に使用できます。この種のパッケージの例には、DBMS_OUTPUT、DBMS_RANDOM、DBMS_PIPE、DBMS_DESCRIBE、DBMS_OBFUSCATION_TOOLKIT、DBMS_TRACE、DBMS_METADATA、DBMS_CRYPTOがあります。

システムのメタデータは変更せず、ユーザー・データを変更することがある、オラクル社が提供するPL/SQLパッケージは、変更されるデータがC.1.1項に示すサポートされるデータ型に属するかぎり、SQL Applyでサポートされます。この種のパッケージの例には、DBMS_LOB、DBMS_SQL、DBMS_TRANSACTIONがあります。

Data Guardのロジカル・スタンバイでは、DBMS_RLS、DBMS_FGA、およびDBMS_REDEFINITIONの3つのパッケージを使用して実行されるアクションのレプリケーションがサポートされます。

C.9.2 サポートされていないPL/SQLパッケージ

システムのメタデータを変更する、オラクル社が提供するPL/SQLパッケージは、通常、SQL Applyではサポートされないため、その影響はロジカル・スタンバイ・データベースでは参照できません。この種のパッケージの例には、DBMS_JAVA、DBMS_REGISTRY、DBMS_ALERT、DBMS_SPACE_ADMIN、DBMS_REFRESHおよびDBMS_AQがあります。

DBMS_JOBに固有のサポートが用意されています。プライマリ・データベースで作成されたジョブはスタンバイ・データベースで複製されますが、このスタンバイがスタンバイ・ロールを維持しているかぎり、実行されません。スイッチオーバーまたはフェイルオーバーが発生すると、元のプライマリ・データベースでスケジュールされていたジョブの実行は、新規のプライマリ・データベースで自動的に開始されます。

ロジカル・スタンバイでジョブを作成することもできます。これらのジョブは、ロジカル・スタンバイがスタンバイ・ロールを維持している間のみ実行されます。

スタンバイ・データベースでジョブを実行できるように、DBMS_SCHEDULERに固有のサポートが用意されています。database_roleと呼ばれるスケジューラ・ジョブの新しい属性が11gで作成されました。この内容はV$DATABASEのdatabase_role属性と一致しています。スケジューラ・ジョブを作成すると、ローカル・ロールにデフォルト設定されます(したがって、スタンバイで作成されたジョブは、LOGICAL STANDBYのdatabase_roleにデフォルト設定されます)。ジョブ・スケジューラは、現行のロールに固有のジョブだけを実行します。スイッチオーバーまたはフェイルオーバーの際は、スケジューラが新しいロールに固有のジョブ実行に切り替わります。

スケジューラ・ジョブはスタンバイにレプリケートされません。しかし、既存のジョブはDBMS_SCHEDULER.Set_Attributeプロシージャを使用して、新しいロールの下でアクティブ化できます。あるいは、両方のロールで実行する必要があるジョブをクローニングし、コピーを他のロールに固有のものにすることが可能です。DBA_SCHEDULER_JOB_ROLESビューには、どのジョブがどのロールに固有かが表示されます。

スケジューラのジョブをロジカル・スタンバイ・データベースで実行する際は、データベース・ガードに従います。したがって、維持されていない表の変更が必要なジョブを実行するには、データベース・ガードをSTANDBYに設定する必要があります。(ALTER SESSION DISABLE GUARD文をPL/SQLブロック内で使用しても、効果がありません。)

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

C.9.3 ロジカル・スタンバイでのXMLおよびXDB PL/SQLパッケージの処理

Oracle Database 11gリリース1(11.1)では、XMLがCLOB形式で格納される場合は、ロジカル・スタンバイでXMLをサポートします。しかし、完全にはサポートされないXMLとともに使用されるPL/SQLパッケージがいくつかあります。

ロジカル・スタンバイがサポートしているPL/SQLパッケージとプロシージャは、インメモリー構造だけで変更を行い、データベースに格納されたデータは変更しません。これらのパッケージはREDOを生成しないため、ロジカル・スタンバイにはレプリケートされません。

ロジカル・スタンバイでサポートされなくても、レプリケーション・アクティビティの続行にロジカル・スタンバイ・データベースで対応する起動が必要なXMLおよびXDBに関連する特定のPL/SQLパッケージおよびプロシージャは、プライマリ・データベースでこれらのプロシージャが起動することにより、プロシージャの起動を示す追加のREDOレコードが生成されるように装備されています。SQL ApplyでこのようなREDOレコードが検出されると、SQL Applyは停止し、プロシージャ名を示すエラー・メッセージがDBA_LOGSTDBY_EVENTS表に書き込まれます。これにより、DBAは対応するプロシージャを適切な時期にロジカル・スタンバイ・データベースで起動し、プライマリ・データベースで生成された後続のREDOレコードをロジカル・スタンバイ・データベースに正常に適用することができます。これらのサポートされないプロシージャの処理の詳細は、C.9.3.1項からC.9.3.6項を参照してください。

次のパッケージには、サポートされないプロシージャが含まれます。

- DBMS_XMLSCHEMA

- DBMS_XMLINDEX

これらのパッケージに加えて、ロジカル・スタンバイではXDBスキーマへの変更もサポートしません。XDBスキーマ内のオブジェクトは、システム・メタデータとみなされ、直接の変更はレプリケートされません。

Oracle XML DBリポジトリで管理される表は、階層対応表とも呼ばれますが、ロジカル・スタンバイではサポートされません。これらの表は、XMLデータの格納に使用され、通常のSQLアクセスに加えてFTPおよびHTTPプロトコルを使用してアクセスできます。これらの表の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

C.9.3.1 DBMS_XMLSCHEMAスキーマ

DBMS_XMLSCHEMAパッケージ内の次のプロシージャは、ロジカル・スタンバイではサポートされず、レプリケートできません。ロジカル・スタンバイは、これらのプロシージャへのコールを検出すると、これらのコールに対してユーザーが補正アクションを実行できるように停止します。これらのサポートされないプロシージャの処理に使用できる代替方法の詳細は、C.9.3.3項からC.9.3.6項を参照してください。

- REGISTERSCHEMA

- REGISTERURI

- DELETESCHEMA

- PURGESCHEMA

- COPYEVOLVE

- INPLACEEVOLVE

- COMPILESCHEMA

XDBスキーマは、Oracle管理スキーマです。このスキーマに対する変更は、ロジカル・スタンバイによって自動的にスキップされます。次のプロシージャは、XDBスキーマを変更しますが、レプリケートされません。

- GENERATEBEAN

次のプロシージャおよびファンクションは、REDOを生成しないため、ロジカル・スタンバイは停止しません。

- GENERATESCHEMAS

- GENERATESCHEMA

C.9.3.2 DBMS_XMLINDEXパッケージ

DBMS_XMLINDEXパッケージ内のSYNCINDEXプロシージャは、ロジカル・スタンバイではサポートされず、レプリケートできません。ロジカル・スタンバイは、このプロシージャへのコールを検出すると停止します。

次のファンクションおよびプロシージャは、REDOを生成しないため、ロジカル・スタンバイは停止しません。

- NODEREFGETREF

- NODEREFGETVALUE

- NODEREFGETPARENTREF

- NODEREFGETNAME

- NODEREFGETNAMESPACE

C.9.3.3 サポートされないPL/SQLプロシージャの処理

サポートされないPL/SQLプロシージャの処理には、2つのオプションがあります。1つ目のオプションは、ロジカル・スタンバイの適用プロセスが停止してなんらかの補正アクションを手動で実行できるようにする方法です。2つ目のオプションは、事前対応アクションを実行し、さらにロジカル・スタンバイのスキップ・プロシージャを使用してサポートされないPL/SQLをスキップする方法です。次の各項で、これらのオプションについてそれぞれ説明します。

C.9.3.4 サポートされないPL/SQLの手動による補正

ロジカル・スタンバイでサポートされないものが検出されると、適用プロセスは停止し、エラーがDBA_LOGSTDBY_EVENTS表に記録されます。この表を問い合せると、スタンバイが停止した原因となるアクションと、該当する場合は補正のために必要なアクションを確認できます。

次の例に、問合せ内容のサンプルとその出力を示します。

select status, event from dba_logstdby_events
where commit_scn >= (select applied_scn from dba_logstdby_progress) and
status_code = 16265
order by commit_scn desc;

STATUS
--------------------------------------------------------------------------------
EVENT
--------------------------------------------------------------------------------
ORA-16265: Unsupported PL/SQL procedure encountered
begin
"XDB"."DBMS_XMLSCHEMA"."REGISTERSCHEMA" (
"SCHEMAURL" => 'xmlplsqlsch2

ORA-16265: Unsupported PL/SQL procedure encountered
begin
"XDB"."DBMS_XMLSCHEMA"."REGISTERSCHEMA" (
"SCHEMAURL" => 'xmlplsqlsch2

2 rows selected.

ロジカル・スタンバイは失敗したトランザクションを自動的に再試行するので、同じ情報が含まれた2行が戻されます。結果は、xmlplsqlsch2スキーマでDBMS_XMLSCHEMA.REGISTERSCHEMAの呼出しに遭遇したため、スタンバイが停止したことを示しています。この情報を使用してプライマリから必要なファイルを転送し、スタンバイにスキーマを登録することができます。

スキーマをスタンバイに正しく登録したら、ロジカル・スタンバイへの適用プロセスを再開できます。これはたとえば次のように、SKIP FAILED TRANSACTIONオプションを使用して実行する必要があります。

alter database start logical standby apply skip failed transaction'

ロジカル・スタンバイは、問題となるトランザクションをスキップし、プライマリからのREDOの適用を続行します。

サポートされないPL/SQLを手動でレプリケートするための一般的な手順は、次のとおりです。

1. サポートされないPL/SQLをプライマリ・データベースで実行します。

2. スタンバイ・データベースでサポートされないPL/SQLが検出され、適用が停止します。

3. DBA_LOGSTDBY_EVENTS表を調べ、適用が停止した原因を確認します。

4. スタンバイで、サポートされないPL/SQLについてなんらかの補正アクションを実行します。

5. スタンバイで適用を再開します。

C.9.3.5 サポートされないPL/SQLの事前対応的な補正

プライマリ・データベースで実行する予定のアクションが、スタンバイの停止原因となることがわかっている場合があります。その場合、事前にアクションを実行してスタンバイがREDOを適用していない時間を最小限に抑えるか、なくなるようにすることが可能です。

たとえば、新しいアプリケーションのインストール予定があることを知っていると仮定します。インストレーションでは大量のXMLスキーマの登録が必要になります。これらのスキーマをプライマリに登録する前に、スタンバイに登録しておくことができます。DBMS_XMLSCHEMA.REGISTERSCHEMAプロシージャについても、スタンバイでスキップ・プロシージャをインストールすることができます。このプロシージャはXMLスキーマが登録済かどうかを確認し、登録済であればロジカル・スタンバイにそのPL/SQLコールをスキップするように伝えます。

この方法は、他のサポートされていないPL/SQLプロシージャの一部にも使用できます。たとえば、DBMS_XMLSCHEMA.DELETESCHEMAは、同様の方法で処理できます。スタンバイにスキーマがインストールされているかどうかを確認し、インストールされていない場合は、スタンバイには大きな影響がまったくないので、そのPL/SQLが安全にスキップされるように、スキップ・プロシージャを作成できます。

C.9.3.6 順序に依存するサポートされないPL/SQLの補正

前述のアプローチは有効ですが、すべての場合に使用できるわけではありません。他のトランザクションとの相対的なPL/SQL実行時間が重要ではない場合にかぎり、安全に使用することができます。使用すべきではない場合の例として、DBMS_XMLSCHEMA.copyEvolveがあげられます。

このプロシージャはスキーマを進化、または変化させ、列の追加または削除によって表を変更することがあり、XMLドキュメントの有効性/無効性も変更します。ロジカル・スタンバイでのこのプロシージャの実行タイミングは非常に重要です。このプロシージャがプライマリ・データベースで実行されたことがわかった場合、ロジカル・スタンバイ上で適用を停止したタイミングが唯一安全です。

スキーマを発展させる前に、プライマリでそのスキーマを使用するトラフィックをすべてQUIESCE(静止)させることも重要です。そうしないと、2つのトランザクション間の依存性がロジカル・スタンバイには識別できないため、プライマリではevolveSchemaに間に合うようにクローズされるトランザクションが、ロジカル・スタンバイでは異なる順序で実行される可能性があります。そのため、順序に依存するPL/SQLが含まれる場合は、次の手順に従う必要があります。

1. プライマリで依存表への変更をQUIESCEさせます。

2. プライマリでCopyEvolveを実行します。

3. スタンバイでのCopyEvolve PL/SQLの停止を待機します。

4. スタンバイで補正CopyEvolveを適用します。

5. スタンバイで適用を再開します。

例C-1に、RegisterSchemaコールの処理方法を決定するために使用されるプロシージャのサンプルを示します。

例C-1 RegisterSchema用のPL/SQLスキップ・プロシージャ

-- Procedures to determine how to handle registerSchema calls

-- This procedure extracts the schema URL, or name, from the statement
-- string that is passed into the skip procedure.

Create or replace procedure sec_mgr.parse_schema_str(
statement             in varchar2,
schema_name      out varchar2)
Is
pos1 number;
pos2 number;
workingstr   varchar2(32767);
Begin

-- Find the correct argument
pos1 := instr(statement, '"SCHEMAURL" => ''');
workingstr := substr(statement, pos1 + 16);

-- Find the end of the schema name
pos1 := instr(workingstr, '''');

-- Get just the schema name
workingstr := substr(workingstr, 1, pos1 - 1);

schema_name := workingstr;

End parse_schema_str;
/
show errors

-- This procedure checks if a schema is already registered. If so,
-- it returns the value DBMS_LOGSTDBY.SKIP_ACTION_SKIP to indicate that
-- the PL/SQL should be skipped. Otherwise, the value
-- DBMS_LOGSTDBY.SKIP_ACTION_SKIP is returned and Logical Standby apply
-- will halt to allow the DBA to deal with the registerSchema call.

Create or replace procedure sec_mgr.skip_registerschema(
statement             in varchar2,
package_owner            in varchar2,
package_name             in varchar2,
procedure_name                 in varchar2,
current_user                   in varchar2,
xidusn                in number,
xidslt                in number,
xidsqn                in number,
exit_status            in number,
skip_action            out number)
Is
schema_exists number;
schemastr varchar2(2000);
Begin

skip_action := DBMS_LOGSTDBY.SKIP_ACTION_SKIP;

-- get the schame name from statement
parse_schema_str(statement, schemastr);

-- see if the schema is already registered
select count(*) into schema_exists from sys.all_xml_schemas s
where s.schema_url = schemastr and
s.owner = current_user;

IF schema_exists = 0 THEN
-- if the schema is not  registered, then we must stop apply
skip_action := DBMS_LOGSTDBY.SKIP_ACTION_APPLY;
ELSE
-- if the schema is already registered, then we can skip this statement
skip_action := DBMS_LOGSTDBY.SKIP_ACTION_SKIP;
END IF;

End skip_registerschema;
/
show errors

-- Register the skip procedure to deal with the unsupported registerSchema
-- PL/SQL.
Begin
sys.dbms_logstdby.skip(stmt => 'PL/SQL',
schema_name => 'XDB',
object_name   => 'DBMS_XMLSCHEMA.REGISTERSCHEMA',
proc_name     => 'SEC_MGR.SKIP_REGISTERSCHEMA',
use_like         => FALSE );
End;
/
show errors

C.10 サポートされない表

ロジカル・スタンバイ・データベースを作成する前にプライマリ・データベース・オブジェクトでサポートされていないデータベース・オブジェクトを識別しておくことが重要です。プライマリ・データベース上でサポートされていないデータ型や表に対して行った変更は、ロジカル・スタンバイ・データベース上ではSQL Applyが自動的にスキップするからです。また、エラー・メッセージも戻されません。

ロジカル・スタンバイのサポートの観点から、データベースには次の3種類のオブジェクトがあります。

- SQL Applyによって明示的にメンテナンスされるオブジェクト

- SQL Applyによって暗黙的にメンテナンスされるオブジェクト

- SQL Applyによってメンテナンスされないオブジェクト

Oracleデータベースに同梱される一部のスキーマ(SYSTEMなど)には、SQL Applyによって暗黙的にメンテナンスされるオブジェクトが含まれます。しかし、ユーザー定義の表をSYSTEMに入れると、サポートされるデータ型の列が含まれている場合でもその表はメンテナンスされません。SQL Applyによってメンテナンスされないオブジェクトを検出するには、次の2つの問合せを実行する必要があります。1つ目の問合せは次のとおりです。

SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';

この問合せは、内部スキーマとみなされるスキーマをすべて戻します。これらのスキーマにあるユーザー表は、ロジカル・スタンバイ・データベースでレプリケートされず、DBA_LOGSTDBY_UNSUPPORTEDビューにも表示されません。スキーマに実装された機能がロジカル・スタンバイの下でサポートされる場合、オラクル社で作成されたこれらのスキーマ内の表は、ロジカル・スタンバイで保持されます。

実行が必要な2つ目の問合せは次のとおりです。この問合せは、内部スキーマに属さず、サポートされないデータ型が含まれるためにSQL Applyによってメンテナンスされない表を戻します。

SQL> SELECT DISTINCT OWNER,TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED -
> ORDER BY OWNER,TABLE_NAME;

OWNER        TABLE_NAME
-----------  --------------------------
HR           COUNTRIES
OE           ORDERS
OE           CUSTOMERS
OE           WAREHOUSES

前述の問合せでリストされたいずれかの表の列名とデータ型を表示するには、次のようなSELECT文を使用します。

SQL> SELECT COLUMN_NAME,DATA_TYPE FROM DBA_LOGSTDBY_UNSUPPORTED -
> WHERE OWNER='OE' AND TABLE_NAME = 'CUSTOMERS';

COLUMN_NAME                      DATA_TYPE
-------------------------------  -------------------
CUST_ADDRESS                     CUST_ADDRESS_TYP
PHONE_NUMBERS                    PHONE_LIST_TYP
CUST_GEO_LOCATION                SDO_GEOMETRY

プライマリ・データベースにサポートされない表が含まれている場合、REDOデータをロジカル・スタンバイ・データベースに適用すると、SQL Applyサービスによって、その表が自動的に除外されます。

注意:
プライマリ・データベースの重要な表がロジカル・スタンバイ・データベースでサポートされない場合は、フィジカル・スタンバイ・データベースの使用を考慮することもできます。フィジカル・スタンバイ・データベースには、このようなデータ型の制約はありません。

C.11 ロジカル・スタンバイ・データベースでスキップされるSQL文

デフォルトでは、次のSQL文がSQL Applyにより自動的にスキップされます。

ALTER DATABASE
ALTER MATERIALIZED VIEW
ALTER MATERIALIZED VIEW LOG
ALTER SESSION
ALTER SYSTEM
CREATE CONTROL FILE
CREATE DATABASE
CREATE DATABASE LINK
CREATE PFILE FROM SPFILE
CREATE MATERIALIZED VIEW
CREATE MATERIALIZED VIEW LOG
CREATE SCHEMA AUTHORIZATION
CREATE SPFILE FROM PFILE
DROP DATABASE LINK
DROP MATERIALIZED VIEW
DROP MATERIALIZED VIEW LOG
EXPLAIN
LOCK TABLE
SET CONSTRAINTS
SET ROLE
SET TRANSACTION

プライマリ・データベースで実行されるこの他のSQL文はすべて、ロジカル・スタンバイ・データベースに適用されます。

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

表C-1に、DBMS_LOGSTDBY.SKIPプロシージャのstmtパラメータについて、サポートされる値を示します。表の左側の列には、キーワードの右側にあるSQL文セットの識別に使用される可能性のあるキーワードを示します。また、sys.audit_actions表に示されたSQL文(表1-13の右列を参照)はすべて、有効な値でもあります。キーワードは、通常、データベース・オブジェクトによって定義されます。

関連項目:
DBMS_LOGSTDBYパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』および10.5.3項「DDL文のスキップ・ハンドラの設定」を参照してください。

表C-1 DBMS_LOGSTDBY.SKIPプロシージャのstmtパラメータの値

キーワード

関連するSQL文

このグループのSQL文に対するキーワードはない。

GRANT
REVOKE
ANALYZE TABLE
ANALYZE INDEX
ANALYZE CLUSTER

CLUSTER

AUDIT CLUSTER
CREATE CLUSTER
DROP CLUSTER
TRUNCATE CLUSTER

CONTEXT

CREATE CONTEXT
DROP CONTEXT

DATABASE LINK

CREATE DATABASE LINK
CREATE PUBLIC DATABASE LINK
DROP DATABASE LINK
DROP PUBLIC DATABASE LINK

DIMENSION

ALTER DIMENSION
CREATE DIMENSION
DROP DIMENSION

DIRECTORY

CREATE DIRECTORY
DROP DIRECTORY

DML

表内のDML文を含む(例: INSERT、UPDATE、DELETE)

INDEX

ALTER INDEX
CREATE INDEX
DROP INDEX

NON_SCHEMA_DDL

特定のスキーマに関連付けられていないすべてのDDL

注意: SCHEMA_NAMEおよびOBJECT_NAMEはNULLである必要があります。

PROCEDURE脚注 1

ALTER FUNCTION
ALTER PACKAGE
ALTER PACKAGE BODY
ALTER PROCEDURE
CREATE FUNCTION
CREATE LIBRARY
CREATE PACKAGE
CREATE PACKAGE BODY
CREATE PROCEDURE
DROP FUNCTION
DROP LIBRARY
DROP PACKAGE
DROP PACKAGE BODY
DROP PROCEDURE

PROFILE

ALTER PROFILE
CREATE PROFILE
DROP PROFILE

PUBLIC DATABASE LINK

CREATE PUBLIC DATABASE LINK
DROP PUBLIC DATABASE LINK

PUBLIC SYNONYM

CREATE PUBLIC SYNONYM
DROP PUBLIC SYNONYM

ROLE

ALTER ROLE
CREATE ROLE
DROP ROLE
SET ROLE

ROLLBACK SEGMENT

ALTER ROLLBACK SEGMENT
CREATE ROLLBACK SEGMENT
DROP ROLLBACK SEGMENT

SCHEMA_DDL

スキーマ・オブジェクト(例: 表、索引、列)の作成、変更または削除を行うすべてのDDL文

注意: SCHEMA_NAMEおよびOBJECT_NAMEはNULL以外である必要があります。

SEQUENCE

ALTER SEQUENCE
CREATE SEQUENCE
DROP SEQUENCE

SYNONYM

CREATE PUBLIC SYNONYM
CREATE SYNONYM
DROP PUBLIC SYNONYM
DROP SYNONYM

SYSTEM AUDIT

AUDIT SQL_statements
NOAUDIT SQL_statements

TABLE

CREATE TABLE
ALTER TABLE
DROP TABLE
TRUNCATE TABLE

TABLESPACE

CREATE TABLESPACE
DROP TABLESPACE
ALTER TABLESPACE

TRIGGER

ALTER TRIGGER
CREATE TRIGGER
DISABLE ALL TRIGGERS
DISABLE TRIGGER
DROP TRIGGER
ENABLE ALL TRIGGERS
ENABLE TRIGGER

TYPE

ALTER TYPE
ALTER TYPE BODY
CREATE TYPE
CREATE TYPE BODY
DROP TYPE
DROP TYPE BODY

USER

ALTER USER
CREATE USER
DROP USER

VIEW

CREATE VIEW
DROP VIEW

脚注 1 Javaスキーマ・オブジェクト(ソース、クラス、リソース)は、SQL文をスキップ(無視)するためのプロシージャと同等とみなされます。

関連項目:
SKIPおよびUNSKIPオプションの使用例を示した次の各項

- 10.5.2項「DBMS_LOGSTDBY.SKIPによる特定のスキーマ・オブジェクトに対する変更の防止」

- 10.5.3項「DDL文のスキップ・ハンドラの設定」

- 10.5.4項「ロジカル・スタンバイ・データベースの変更」

- 10.5.5項「ロジカル・スタンバイ・データベースでの表の追加または再作成」

C.12.1 DBLINKSを使用するDDL文

SQL Applyは、データベース・リンクを参照する次のようなDDL文を正しく適用できない場合があります。

CREATE TABLE tablename AS SELECT * FROM bar@dblink

これは、ロジカル・スタンバイ・データベースでdblinkがプライマリ・データベースと同じデータベースを指さないことがあるためです。このようなDDL文の実行中にSQL Applyに障害が発生した場合は、表の作成にDBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャを使用して、SQL APPLYの操作を再開する必要があります。

C.12.2 ロジカル・スタンバイ・プロセス上のAUD$およびFGA_LOG$のレプリケーション

ロジカル・スタンバイでは、監査およびファイングレイン監査がサポートされています。プライマリ・データベースでAUD$およびFGA_AUD$表に対して行われた変更は、ロジカル・スタンバイにレプリケートされます。

AUD$表およびFGA_AUD$表の両方に、DBID列があります。DBID値がプライマリ・データベースの値の場合、その行は、プライマリでのアクティビティに基づいてロジカル・スタンバイにレプリケートされています。DBID値がロジカル・スタンバイ・データベースの値の場合、その行は、ロジカル・スタンバイのローカル・アクティビティの結果として挿入されています。

ロジカル・スタンバイ・データベースで、プライマリ・ロールをロールの推移(スイッチオーバーまたはフェイルオーバー)の結果とみなした後、新しいプライマリ(元のロジカル・スタンバイ)および新しいロジカル・スタンバイ(元のプライマリ)のAUD$表およびFGA_AUD$表は、必ず同期されるとはかぎりません。このため、新しいプライマリ・データベースのAUD$表またはFGA_AUD$表のすべての行が、新しいロジカル・スタンバイ・データベースに存在するとはかぎりません。ただし、データベースがプライマリ・ロールの際に挿入されたAUD$およびFGA_LOG$のすべての行はレプリケートされ、ロジカル・スタンバイ・データベースに存在します。

C.13 分散トランザクションおよびXAのサポート

次のいずれかの方法を使用して分散トランザクションを実行できます。

- データベース・リンクを使用した調整方法により複数のデータベース内の表を変更します。

- 提供PL/SQLパッケージ内でDBMS_XAパッケージによって公開されたXAインタフェース、あるいはOCIまたはJDBCライブラリを介してXAインタフェースを使用します。XAインタフェースによって、X/Open分散トランザクション処理(DTP)アーキテクチャが実装されます。

これら2つの方法のいずれかを使用した分散トランザクション中に、プライマリ・データベースに対して変更が行われると、ロジカル・スタンバイ・データベースにレプリケートされます。

ただし、分散トランザクションの状態はレプリケートされません。ロジカル・スタンバイ・データベースは、その種のトランザクションの未決定、または準備状態は継承しません。またXAトランザクション用にプライマリ・データベースで使用されたものと同じグローバル・トランザクション識別子はレプリケートしません。その結果、分散トランザクションにコミットする前にロジカル・スタンバイ・データベースにフェイルオーバーすると、変更がロジカル・スタンバイにロールバックされます。プライマリ・データベース上の分散トランザクションが準備状態で、2段階から成るコミット・プロトコルのうち最初の段階を正常に終了した場合でも、ロールバックが発生します。スイッチオーバー操作はすべてのアクティブ分散トランザクションの完了を待機するので、この制約には影響されません。

XAトランザクションは次の2つの方法で実行できます。

- 密結合(異なるXAブランチがロックを共有する)

- 疎結合(異なるXAブランチがロックを共有しない)

疎結合のXAブランチによって行われる変更のレプリケーションは、COMPATIBLEパラメータの値に関係なくサポートされます。Oracle RACプライマリ上で緊密に連結されたブランチ(11gリリース1で新たに提供)への変更のレプリケーションは、COMPATIBLE=11.2以上でのみサポートされています。

C.14 SecureFile LOBのサポート

SecureFile LOBは、データベースの互換性レベルが11.2以降に設定されている場合にサポートされます。

プライマリ・データベースでは、SecureFile LOB列で透過的なデータ暗号化およびデータ圧縮を使用できます。SecureFile LOB列の重複除外はサポートされていません。また、DBMS_LOB PL/SQLパッケージに含まれる次の操作は、SecureFile LOB列ではサポートされていません。

FRAGMENT_DELETE、FRAGMENT_INSERT、FRAGMENT_MOVE、FRAGMENT_REPLACE、COPY_FROM_DBFS_LINK、MOVE_TO_DBFS_LINK、SET_DBFS_LINK、COPY_DBFS_LINK、SETCONTENTTYPE

SQL Applyがこれらの操作によって生成されたREDOを検出すると、「ORA-16211: サポートされていないレコードが、アーカイブREDOログで見つかりました。」エラーとともに停止します。続行するには、DBMS_LOGSTDBY.SKIPを使用した該当する表にスキップ・ルールを追加し、SQL Applyを再開します。

C.15 キャラクタ・セットに関する考慮事項

プライマリ・データベースとスタンバイ・データベースでの使用キャラクタ・セットが異なる構成はサポートされていません。

D Data GuardおよびOracle Real Application Clusters

Oracle Data Guardは、シングル・インスタンスとOracle Real Application Clusters(Oracle RAC)の複数インスタンス・データベースを自由に組み合せて構成することができます。この章ではOracle Data GuardをOracle RACデータベースと一緒に使用する場合の構成要件と考慮事項をまとめます。この章の内容は、次のとおりです。

- Oracle RAC環境でのスタンバイ・データベースの構成

- Oracle RAC環境での構成に関する考慮事項

- トラブルシューティング

D.1 Oracle RAC環境でのスタンバイ・データベースの構成

スタンバイ・データベースを構成すると、Oracle RACを使用しているプライマリ・データベースを保護できます。次の表では、プライマリ・データベースとスタンバイ・データベースのインスタンスの可能な組合せについて説明します。

インスタンスの組合せ

単一インスタンス・スタンバイ・データベース

複数インスタンス・スタンバイ・データベース

単一インスタンス・プライマリ・データベース

可

可

複数インスタンス・プライマリ・データベース

可

可

それぞれの組合せでは、プライマリ・データベースの各インスタンスが、REDOデータをスタンバイ・データベースのインスタンスへ転送します。

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

図D-1 では、プライマリ・データベース・インスタンスが2つあるOracle RACデータベース(複数インスタンス・プライマリ・データベース)が、単一インスタンス・スタンバイ・データベースへREDOデータを転送しています。

図D-1 複数インスタンス・プライマリ・データベースからのREDOデータの転送

この場合は、プライマリ・データベースのインスタンス1がローカル・アーカイブREDOログ・ファイル1、2、3、4、5にREDOデータをアーカイブし、スタンバイ・データベース宛先にREDOデータを転送するのに対し、インスタンス2がローカル・アーカイブREDOログ・ファイル32、33、34、35、36にREDOデータをアーカイブし、同じスタンバイ・データベース宛先にREDOデータを転送します。スタンバイ・データベースでは、アーカイブREDOログ・ファイルを適用する正しい順序が自動的に判断されます。

Oracle RAC環境でプライマリ・データベースを設定する手順

各プライマリ・インスタンスを構成するには、第3章(フィジカル・スタンバイ・データベース作成の場合)、または第4章(ロジカル・スタンバイ・データベース作成の場合)の説明に従ってください。

単一インスタンス・スタンバイ・データベースを設定する手順

LOG_ARCHIVE_DEST_nパラメータおよびLOG_ARCHIVE_FORMATパラメータを定義して、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイルの場所を指定するには、第3章(フィジカル・スタンバイ・データベース作成の場合)、または第4章(ロジカル・スタンバイ・データベース作成の場合)の説明に従ってください。

D.1.2 Oracle RACプライマリおよびスタンバイ・データベースの設定

この項では、Oracle RACスタンバイ・データベースにREDOデータを送信するようにOracle RACプライマリ・データベースを構成する方法について説明します。

D.1.2.1 REDOデータを受信するためのOracle RACスタンバイ・データベースの構成

次の手順を実行して、プライマリ・データベースからREDOデータを受信するようにOracle RACスタンバイ・データベースを構成します。

1. スタンバイ・データベースで、スタンバイREDOログを作成します。スタンバイREDOログのREDOログ・ファイルは、すべてのスタンバイ・データベース・インスタンスがアクセスできる場所(クラスタ・ファイル・システムやOracle ASMインスタンスなど)に存在する必要があります。スタンバイREDOログの作成の詳細は、6.2.3.1項を参照してください。

2. スタンバイREDOログ・アーカイブを、各スタンバイ・インスタンス上に構成します。スタンバイREDOログはすべてのスタンバイ・インスタンスがアクセス可能な場所にアーカイブする必要があります。また、各スタンバイ・データベース・インスタンスは、同じ場所にスタンバイREDOログをアーカイブするように構成しておく必要があります。スタンバイREDOログ・アーカイブ構成の詳細は、6.2.3.2項を参照してください。

D.1.2.2 REDOデータを送信するためのOracle RACプライマリ・データベースの構成

REDOデータをOracle RACスタンバイ・データベースに送信するように、Oracle RACプライマリ・データベースの各インスタンスを構成します。REDOデータを別のデータベースに送信するようにOracleデータベース・インスタンスを構成する方法は、6.2.2項を参照してください。

REDOデータをOracle RACスタンバイ・データベースに送信するようにOracle RACプライマリ・データベースを構成する際には、次のベスト・プラクティスをお薦めします。

1. 各プライマリ・データベース・インスタンスで同じLOG_ARCHIVE_DEST_nパラメータを使用して、REDOデータを特定のスタンバイ・データベースに送信する。

2. 特定のスタンバイ・データベースに対応する各LOG_ARCHIVE_DEST_nパラメータのSERVICE属性を同じネット・サービス名に設定する。

3. ネット・サービス名は、アドレス・リストを含むOracle Net接続記述子に解決する必要があり、そのアドレス・リストには、各スタンバイ・データベース・インスタンスの接続データが含まれる必要がある。

D.2 Oracle RAC環境での構成に関する考慮事項

この項では、Oracle RAC環境に固有のData Guard構成情報を示します。この付録には、次の項があります。

- アーカイブREDOログ・ファイル名の形式

- データ保護モード

- ロールの推移

D.2.1 アーカイブREDOログ・ファイル名の形式

アーカイブREDOログ・ファイル名は、log_%parameterの形式になります。%parameterには、表D-1のパラメータを1つ以上含めることができます。

表D-1 LOG_ARCHIVE_FORMAT初期化パラメータのディレクティブ

ディレクティブ

説明

%a

データベース・アクティブID

%A

0(ゼロ)を埋め込んだデータベース・アクティブID

%d

データベースID

%D

0(ゼロ)を埋め込んだデータベースID

%t

インスタンス・スレッド番号

%T

0(ゼロ)を埋め込んだインスタンス・スレッド番号

%s

ログ・ファイル順序番号

%S

0(ゼロ)を埋め込んだログ・ファイル順序番号

%r

リセットログID

%R

0(ゼロ)を埋め込んだリセットログID

次に例を示します。

LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc

Oracle RACが、LOG_ARCHIVE_FORMATパラメータでアーカイブREDOログ・ファイルを一意に識別するためには、スレッド・パラメータ%tまたは%Tが必須です。

D.2.2 データ保護モード

Oracle RACプライマリ・データベースのいずれかのインスタンスでスタンバイ・データベースとの接続性が失われた場合、他のすべてのプライマリ・データベース・インスタンスでは、LOG_ARCHIVE_DEST_n REOPEN属性で指定された秒数の間、スタンバイ・データベースへのREDO送信を停止し、その後すべてのプライマリ・データベース・インスタンスでスタンバイ・データベースへの再接続が試みられます。

次に、Oracle RAC環境における保護モードの動作を説明します。

- 最大保護の構成
接続を失った宛先が最後のSYNC宛先の場合、インスタンスは接続を失い、停止します。Oracle RAC構成内でスタンバイ宛先への接続を維持しているインスタンスは、接続を失ったインスタンスをリカバリし、スタンバイ宛先への送信を継続します。Oracle RAC構成内のすべてのインスタンスが最後のスタンバイ宛先への接続を失った場合にのみ、プライマリ・データベースが停止します。

D.2.3 ロールの推移

この項では、スイッチオーバーについて説明します。

D.2.3.1 スイッチオーバー

Oracle RACデータベースの場合は、ターゲット・データベースがフィジカル・スタンバイであるスイッチオーバー時にアクティブにできるのは、1つのプライマリ・インスタンスのみです。したがって、フィジカル・スタンバイ・データベースへのスイッチオーバーの前に、1つのプライマリ・インスタンス以外はすべて停止します。スイッチオーバーの完了後、スイッチオーバーの実行時に停止したインスタンスを再起動します。ロジカル・スタンバイ・データベースへのスイッチオーバーを実行する場合には、この制限は適用されません。

注意:
SQL ALTER DATABASE文を使用してスイッチオーバーを実行すると、REDOログ・ファイルが存在していない場合は自動的に作成されます。これによって、COMMIT操作の完了に必要な時間が大幅に長くなる場合があるため、フィジカル・スタンバイ・データベースを作成するときは、REDOログ・ファイルを手動で追加することをお薦めします。

D.3 トラブルシューティング

この項は、Oracle RACで発生する問題のトラブルシューティングのヘルプとして利用できます。

D.3.1 Oracle RAC構成でスイッチオーバーできない

データベースでOracle RACを使用すると、アクティブ・インスタンスによってスイッチオーバーの実行が妨げられます。他のインスタンスがアクティブの場合は、スイッチオーバーの試行が次のエラー・メッセージを伴って失敗します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;

ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY *
ORA-01105: mount is incompatible with mounts by other instances

処置: 次のようにGV$INSTANCEビューを問い合せ、問題の原因となっているインスタンスを判断します。

SQL> SELECT INSTANCE_NAME, HOST_NAME FROM GV$INSTANCE -
> WHERE INST_ID <> (SELECT INSTANCE_NUMBER FROM V$INSTANCE);

INSTANCE_NAME HOST_NAME
------------- ---------
INST2         standby2

上記の例では、識別したインスタンスを手動でシャットダウンしなければ、スイッチオーバーに進むことができません。自身のインスタンスから識別したインスタンスに接続し、たとえば次のようにSHUTDOWN文を発行することができます。

SQL> CONNECT SYS@standby2 AS SYSDBA
Enter Password:
SQL> SHUTDOWN;
SQL> EXIT

E Recovery Managerを使用したスタンバイ・データベースの作成

この付録では、Oracle Recovery Managerを使用してスタンバイ・データベースを作成する方法を説明します。この付録は、次の項目で構成されています。

- 前提条件

- Recovery Managerを使用したスタンバイ・データベースの作成の概要

- DUPLICATEコマンドを使用したスタンバイ・データベースの作成

E.1 前提条件

この付録は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のデータベース・レプリケーションに関する章を読んでいることが前提になっています。DUPLICATEコマンドを使用してRMANでスタンバイ・データベースを作成するので、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のDUPLICATEコマンド・エントリについて理解している必要があります。

この章で説明するRecovery Managerでの作成手順を実行する前に、第3章「フィジカル・スタンバイ・データベースの作成」および第4章「ロジカル・スタンバイ・データベースの作成」のスタンバイ・データベースの作成方法を理解しておいてください。

E.2 Recovery Managerを使用したスタンバイ・データベースの作成の概要

この項では、Recovery Managerを使用してスタンバイ・データベースを作成する目的および基本概念について説明します。

E.2.1 Recovery Managerを使用したスタンバイ・データベースの作成の目的

プライマリ・データベースのバックアップからスタンバイ・データベースを作成するには、手動で行うか、Recovery ManagerのDUPLICATEコマンドを使用します。Recovery Managerを使用してスタンバイ・データベースを作成すると、手動による作成と比べて次のメリットがあります。

- プライマリ・データベースで現在使用しているファイルをコピーしてスタンバイ・データベースを作成できます。バックアップは必要ありません。

- プライマリ・データベースのバックアップをスタンバイ・サイトにリストアしてスタンバイ・データベースを作成できます。したがって、スタンバイ・データベースの作成中にプライマリ・データベースが影響を受けることはありません。

- Oracle Managed Files(OMF)などのファイルやディレクトリ構造の名前の変更が自動化されます。

- アーカイブREDOログ・ファイルをバックアップからリストアされ、スタンバイ・データベースとプライマリ・データベースが同期化されるようにメディア・リカバリが実行されます。

E.2.2 Recovery Managerを使用したスタンバイ・データベースの作成の基本概念

Recovery Managerを使用してスタンバイ・データベースを作成する手順は、複製データベースの作成とほぼ同じです。スタンバイ・データベース固有の問題に対処するために、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』で説明されている複製手順を変更する必要があります。

DUPLICATEコマンドを使用してスタンバイ・データベースを作成するには、ターゲットとしてプライマリ・データベースに接続し、FOR STANDBYオプションを指定する必要があります。スタンバイ・データベースに接続してスタンバイ・データベースを追加作成することはできません。Recovery Managerは、制御ファイルをリストアおよびマウントして、スタンバイ・データベースを作成します。Recovery Managerではプライマリ・データベースの制御ファイルの既存のバックアップを使用できるので、スタンバイ・データベース専用に制御ファイルのバックアップを作成する必要はありません。

FOR STANDBY OPTIONを指定せずにDUPLICATEで作成した複製データベースと異なり、スタンバイ・データベースには新しいDBIDが設定されません。そのため、スタンバイ・データベースをリカバリ・カタログに登録しないでください。

E.2.2.1 アクティブ・データベース複製とバックアップベース複製

アクティブ複製とバックアップベース複製のいずれかを選択する必要があります。FROM ACTIVE DATABASEを指定すると、Recovery Managerはデータファイルをプライマリ・データベースからスタンバイ・データベースに直接コピーします。プライマリ・データベースをマウントまたはオープンする必要があります。

FROM ACTIVE DATABASEを指定しないと、Recovery Managerはバックアップベース複製を実行します。プライマリ・データファイルのバックアップがスタンバイ・データベースにリストアされます。スタンバイ・データベースの作成およびリカバリに必要なバックアップおよびアーカイブREDOログ・ファイルはすべて、スタンバイ・ホストのサーバー・セッションでアクセスできる必要があります。SET UNTILコマンドを実行しないかぎり、最新のデータファイルがリストアされます。

E.2.2.2 Recovery Manager環境におけるDB_UNIQUE_NAMEの値

FOR STANDBYオプションを指定せずにDUPLICATEコマンドを使用して作成された複製データベースと異なり、スタンバイ・データベースには新しいDBIDが設定されません。Data Guard環境でRecovery Managerを使用する場合、常にリカバリ・カタログに接続する必要があります。リカバリ・カタログには、環境内のすべてのプライマリ・データベースとスタンバイ・データベースに関するメタデータを格納できます。スタンバイ・データベースは、リカバリ・カタログに明示的に登録しないでください。

Data Guard環境内のデータベースは、初期化パラメータ・ファイルのDB_UNIQUE_NAMEパラメータによって一意に識別する必要があります。DB_UNIQUE_NAMEは、Recovery ManagerがData Guard環境で正しく機能するために、同じDBIDを持つすべてのデータベース間で一意である必要があります。

関連項目:
Data Guard環境でのRMAN操作の概要は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

E.2.2.3 スタンバイ・データベースのリカバリ

デフォルトで、Recovery Managerはスタンバイ・データベースの作成後、リカバリを実行しません。Recovery Managerはスタンバイ・データベースをマウントしたままにしますが、スタンバイ・データベースを手動または管理リカバリ・モードには設定しません。Recovery Managerは接続を切断し、スタンバイ・データベースのメディア・リカバリを実行しません。

Recovery Managerでスタンバイ・データベースの作成後にリカバリを行う場合、リカバリに対してスタンバイ制御ファイルが使用可能である必要があります。次の条件を満たしている必要があります。

- スタンバイ・データベースのリカバリ終了時刻は、スタンバイ制御ファイルのチェックポイントSCN以上である必要があります。

- スタンバイ制御ファイルのチェックポイントSCNが含まれているアーカイブREDOログ・ファイルは、リカバリ用にスタンバイ・サイトから使用可能である必要があります。

これらの条件を満たしていることを確認する方法として、プライマリ・データベースに制御ファイルをバックアップ後、ALTER SYSTEM ARCHIVE LOG CURRENT文を実行します。この文は、プライマリ・データベースのオンラインREDOログ・ファイルをアーカイブします。その後、最新のアーカイブREDO・ログ・ファイルをRecovery Managerでバックアップするか、またはアーカイブREDOログ・ファイルをスタンバイ・サイトに移動します。

DUPLICATEコマンドのDORECOVERオプションを使用して、Recovery Managerでスタンバイ・データベースをリカバリするように指定します。Recovery Managerは、スタンバイ・データベース・ファイルの作成後に次の手順を実行します。

1. Recovery Managerはメディア・リカバリを開始します。アーカイブREDOログ・ファイルを必要とするリカバリで、そのログ・ファイルがディスクにない場合、Recovery Managerはバックアップのリストアを試みます。

2. Recovery Managerは、指定された時間、システム変更番号(SCN)またはログ・ファイル順序番号にスタンバイ・データベースをリカバリします。そのいずれも指定されていない場合は、最新の生成済アーカイブREDOログ・ファイルにリカバリします。

3. Recovery Managerは、メディア・リカバリの完了後、スタンバイ・データベースをマウントしたままにしますが、スタンバイ・データベースを手動または管理リカバリ・モードには設定しません。

E.2.2.4 スタンバイ・データベースREDOログ・ファイル

Recovery Managerは、スタンバイ・データベースでスタンバイREDOログ・ファイルを自動的に作成します。ログ・ファイルは作成後、スタンバイ・データベースによってログ・ファイルの通常のルールに従って管理およびアーカイブされます。

バックアップベース複製を使用した場合、スタンバイ・データベースでスタンバイREDOログ・ファイルに名前を付けるときの唯一のオプションは、スタンバイ制御ファイルで指定されるログ・ファイルのファイル名です。スタンバイでのログ・ファイル名をプライマリのファイル名と異なる名前にする必要がある場合は、スタンバイ初期化パラメータ・ファイルでLOG_FILE_NAME_CONVERTを設定して、スタンバイREDOログのファイル名を指定する方法を選択できます。

スタンバイ・データベースでスタンバイREDOログ・ファイルのファイル名を指定する際、次の制限事項に注意してください。

- プライマリ・データベースおよびスタンバイ・データベースでログ・ファイルに異なるネーミング規則を使用する場合、スタンバイREDOログ・ファイルにはLOG_FILE_NAME_CONVERTパラメータを使用して名前を付ける必要があります。

- スタンバイREDOログ・ファイルの名前の変更には、SET NEWNAMEまたはCONFIGURE AUXNAMEコマンドを使用できません。

- スタンバイREDOログ・ファイルのファイル名の指定には、DUPLICATEコマンドのLOGFILE句を使用できません。

- スタンバイ・データベースでのスタンバイREDOログ・ファイル名をプライマリREDOログ・ファイル名と同じ名前にする場合、DUPLICATEコマンドのNOFILENAMECHECK句を指定する必要があります。指定しない場合、スタンバイ・データベースが異なるホスト上で作成されていても、Recovery Managerによりエラーが発生します。

E.2.2.5 スタンバイ・データベースのパスワード・ファイル

アクティブ・データベース複製を使用すると、スタンバイ・データベースのパスワード・ファイルはターゲット・データベースのパスワード・ファイルの完全コピーである必要があるため、Recovery Managerは常にパスワード・ファイルをスタンバイ・ホストにコピーします。その場合、PASSWORD FILE句は必要ありません。補助インスタンスの既存のパスワード・ファイルはすべて上書きされます。バックアップベース複製では、Data Guardによるログの送信のために、プライマリで使用されているパスワード・ファイルをスタンバイにコピーする必要があります。

E.3 DUPLICATEコマンドを使用したスタンバイ・データベースの作成

スタンバイ・データベースの作成手順は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』で説明している複製手順と基本的に同じです。

E.3.1 アクティブ・データベース複製によるスタンバイ・データベースの作成

プライマリ・データベースのアクティブなファイルからスタンバイ・データベースを作成するには、FOR STANDBYとFROM ACTIVE DATABASEの両方を指定します。必要に応じて、DORECOVERオプションを指定し、スタンバイの作成後にデータベースをリカバリします。

この使用例では、スタンバイ・ホストおよびプライマリ・データベース・ホストのディレクトリ構造は同じであることを前提にしています。

スタンバイ・データベースをアクティブなデータベース・ファイルから作成するには、次のようにします。

1. 補助データベース・インスタンスを準備します。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
アクティブ・データベース複製を使用するため、補助インスタンス用にパスワード・ファイルを作成し、Oracle Net接続を確立する必要があります。これは、複製操作中に上書きされるので、一時的なパスワード・ファイルです。

2. スタンバイ制御ファイル、データファイル、オンラインREDOログおよび一時ファイルの名前の指定方法を決定します。この手順の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
この使用例では、スタンバイ・データベース・ファイルには、プライマリ・データベース・ファイルと同じ名前を付けます。

3. Recovery Managerを起動して構成します。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

4. DUPLICATEコマンドを実行します。
次の例に、アクティブ複製でのDUPLICATEの使用方法を示します。この例では、プライマリ・データベース・ファイルがスタンバイ・データベース・ファイルと同じ名前であるため、NOFILENAMECHECKオプションが必要です。SPFILEのSET句は、ログの送信が正常に行われるために必要です。db_unique_nameを設定して、カタログおよびData Guardでこのデータベースがプライマリとは異なるものであると識別できるようにする必要があります。

DUPLICATE TARGET DATABASE
FOR STANDBY
FROM ACTIVE DATABASE
DORECOVER
SPFILE
SET "db_unique_name"="foou" COMMENT ''Is a duplicate''
SET LOG_ARCHIVE_DEST_2="service=inst3 ASYNC REGISTER
VALID_FOR=(online_logfile,primary_role)"
SET FAL_SERVER="inst1" COMMENT "Is primary"
NOFILENAMECHECK;

Recovery Managerは、サーバー・パラメータ・ファイルをスタンバイ・ホストに自動的にコピーし、そのサーバー・パラメータ・ファイルを使用して補助インスタンスを起動してバックアップ制御ファイルをリストアし、必要なデータベース・ファイルおよびアーカイブREDOログをすべてスタンバイ・ホストにネットワークを介してコピーします。Recovery Managerはスタンバイ・データベースをリカバリしますが、スタンバイ・データベースを手動または管理リカバリ・モードには設定しません。

E.3.2 バックアップベース複製によるスタンバイ・データベースの作成

スタンバイ・データベースをバックアップから作成するには、FOR STANDBYを指定しますが、FROM ACTIVE DATABASEは指定しません。必要に応じて、DORECOVERオプションを指定し、スタンバイの作成後にデータベースをリカバリします。

この使用例では、スタンバイ・ホストおよびプライマリ・データベース・ホストのディレクトリ構造は同じであることを前提にしています。

スタンバイ・データベースをバックアップから作成するには、次のようにします。

1. 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』に記載されているように、データベース・バックアップおよびアーカイブREDOログを複製ホスト上の補助インスタンス用に提供します。

2. 補助データベース・インスタンスを準備します。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

3. スタンバイ制御ファイル、データファイル、オンラインREDOログおよび一時ファイルの名前の指定方法を決定します。この手順の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
この使用例では、スタンバイ・データベース・ファイルには、プライマリ・データベース・ファイルと同じ名前を付けます。

4. Recovery Managerを起動して構成します。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

5. DUPLICATEコマンドを実行します。
次の例に、バックアップベース複製でのDUPLICATEの使用方法を示します。この例では、プライマリ・データベース・ファイルがスタンバイ・データベース・ファイルと同じ名前であるため、NOFILENAMECHECKオプションが必要です。

DUPLICATE TARGET DATABASE
FOR STANDBY
DORECOVER
SPFILE
SET "db_unique_name"="foou" COMMENT ''Is a duplicate''
SET LOG_ARCHIVE_DEST_2="service=inst3 ASYNC REGISTER
VALID_FOR=(online_logfile,primary_role)"
SET FAL_SERVER="inst1" COMMENT "Is primary"
NOFILENAMECHECK;

Recovery Managerは、サーバー・パラメータ・ファイルをスタンバイ・ホストに自動的にコピーし、そのサーバー・パラメータ・ファイルを使用して補助インスタンスを起動し、必要なデータベース・ファイルおよびアーカイブREDOログをすべてスタンバイ・ホストにリストアします。Recovery Managerはスタンバイ・データベースをリカバリしますが、スタンバイ・データベースを手動または管理リカバリ・モードには設定しません。

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

Oracleデータベースは、LOG_ARCHIVE_TRACEパラメータを使用して、ログ・アーカイブおよびREDO転送アクティビティに関する包括的なトレース情報の生成を可能にし、制御します。このトレース情報は、Automatic Diagnostic Repositoryに書き込まれます。

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

- LOG_ARCHIVE_TRACE初期化パラメータの設定

- 整数値の選択

関連項目:
Automatic Diagnostic Repositoryの詳細は、『Oracle Database管理者ガイド』を参照してください。

F.1 LOG_ARCHIVE_TRACE初期化パラメータの設定

アーカイブ・トレース・パラメータの書式は次のとおりです。trace_levelは整数です。

LOG_ARCHIVE_TRACE=trace_level

LOG_ARCHIVE_TRACEパラメータの有効化、無効化または変更を行うには、次のようなSQL文を発行します。

SQL> ALTER SYSTEM SET LOG_ARCHIVE_TRACE=15;

この例では、LOG_ARCHIVE_TRACEパラメータを15に設定したため、F.2項で説明するように、トレース・レベルが1、2、4および8に設定されます。

F.2 整数値の選択

LOG_ARCHIVE_TRACEパラメータの整数値は、データのトレース・レベルを表します。一般的には、レベルが高いほど、情報が詳細になります。次の整数値を使用できます。

レベル

意味

0

アーカイブREDOログのトレースを使用不可能にします(デフォルト設定)。

1

ログ・ファイルのアーカイブを追跡します。

2

アーカイブ・ログ・ファイルの宛先ごとにアーカイブ状況を追跡します。

4

アーカイブ操作のフェーズを追跡します。

8

アーカイブ・ログの宛先のアクティビティを追跡します。

16

アーカイブ・ログの宛先の詳細なアクティビティを追跡します。

32

アーカイブ・ログの宛先のパラメータ修正を追跡します。

64

ARCnプロセスの状態のアクティビティを追跡します。

128

FALサーバー・プロセスのアクティビティを追跡します。

256

RFSの論理的なクライアントを追跡します。

512

LGWRのREDO転送ネットワーク・アクティビティを追跡します。

1024

RFSの物理的なクライアントを追跡します。

2048

RFS/ARCnのpingのハートビートを追跡します。

4096

リアルタイム適用アクティビティを追跡します。

8192

REDO Applyアクティビティ(メディア・リカバリまたはフィジカル・スタンバイ)を追跡します。

16384

アーカイブI/Oバッファを追跡します。

32768

LogMinerディクショナリのアーカイブを追跡します。

LOG_ARCHIVE_TRACEパラメータの値をいくつかのトレース・レベルを合計した値に設定すると、トレース・レベルを組み合せることができます。たとえば、パラメータを6に設定すると、レベル2とレベル4のトレース出力が生成されます。

次に、ログ・ファイル387を2つの異なる宛先(サービスstandby1およびローカル・ディレクトリ/oracle/dbs)にアーカイブすることによってプライマリ・サイトに生成されるARC0トレース・データの例を示します。

注意:
レベルの数値は実際のトレース出力には表示されません。ここでは説明の目的で示してあります。

Level   Corresponding entry content (sample)
-----   --------------------------------
( 1)    ARC0: Begin archiving log# 1 seq# 387 thrd# 1
( 4)    ARC0: VALIDATE
( 4)    ARC0: PREPARE
( 4)    ARC0: INITIALIZE
( 4)    ARC0: SPOOL
( 8)    ARC0: Creating archive destination 2 : 'standby1'
(16)    ARC0:  Issuing standby Create archive destination at 'standby1'
( 8)    ARC0: Creating archive destination 1 : '/oracle/dbs/d1arc1_387.log'
(16)    ARC0:  Archiving block 1 count 1 to : 'standby1'
(16)    ARC0:  Issuing standby Archive of block 1 count 1 to 'standby1'
(16)    ARC0:  Archiving block 1 count 1 to :  '/oracle/dbs/d1arc1_387.log'
( 8)    ARC0: Closing archive destination 2  : standby1
(16)    ARC0:  Issuing standby Close archive destination at 'standby1'
( 8)    ARC0: Closing archive destination 1  :  /oracle/dbs/d1arc1_387.log
( 4)    ARC0: FINISH
( 2)    ARC0: Archival success destination 2 : 'standby1'
( 2)    ARC0: Archival success destination 1 : '/oracle/dbs/d1arc1_387.log'
( 4)    ARC0: COMPLETE, all destinations archived
(16)    ARC0: ArchivedLog entry added: /oracle/dbs/d1arc1_387.log
(16)    ARC0: ArchivedLog entry added: standby1
( 4)    ARC0: ARCHIVED
( 1)    ARC0: Completed archiving log# 1 seq# 387 thrd# 1

(32)  Propagating archive 0 destination version 0 to version 2
Propagating archive 0 state version 0 to version 2
Propagating archive 1 destination version 0 to version 2
Propagating archive 1 state version 0 to version 2
Propagating archive 2 destination version 0 to version 1
Propagating archive 2 state version 0 to version 1
Propagating archive 3 destination version 0 to version 1
Propagating archive 3 state version 0 to version 1
Propagating archive 4 destination version 0 to version 1
Propagating archive 4 state version 0 to version 1

(64) ARCH: changing ARC0 KCRRNOARCH->KCRRSCHED
ARCH: STARTING ARCH PROCESSES
ARCH: changing ARC0 KCRRSCHED->KCRRSTART
ARCH: invoking ARC0
ARC0: changing ARC0 KCRRSTART->KCRRACTIVE
ARCH: Initializing ARC0
ARCH: ARC0 invoked
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0 started with pid=8
ARC0: Archival started

次に示すトレース・データは、スタンバイ・サイトで、ディレクトリ/stbyにアーカイブREDOログ・ファイル387を受信し、それをスタンバイ・データベースに適用するRFSプロセスによって生成されたものです。

level    trace output (sample)
----    ------------------
( 4)      RFS: Startup received from ARCH pid 9272
( 4)      RFS: Notifier
( 4)      RFS: Attaching to standby instance
( 1)      RFS: Begin archive log# 2 seq# 387 thrd# 1
(32)      Propagating archive 5 destination version 0 to version 2
(32)      Propagating archive 5 state version 0 to version 1
( 8)      RFS: Creating archive destination file: /stby/parc1_387.log
(16)      RFS:  Archiving block 1 count 11
( 1)      RFS: Completed archive log# 2 seq# 387 thrd# 1
( 8)      RFS: Closing archive destination file: /stby/parc1_387.log
(16)      RFS: ArchivedLog entry added: /stby/parc1_387.log
( 1)      RFS: Archivelog seq# 387 thrd# 1 available 04/02/99 09:40:53
( 4)      RFS: Detaching from standby instance
( 4)      RFS: Shutdown received from ARCH pid 9272

索引
A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  Z

A

アクティブ化

ロジカル・スタンバイ・データベース, 8.3.2, 16.1

フィジカル・スタンバイ・データベース, 11.8.6, 16.1

Active Data Guard

およびフィジカル・スタンバイ・データベース, 2.1.1, 9.2

およびリアルタイム問合せ機能, 9.2.1

追加

データファイル, 9.3.1, A.10.1.1, A.10.1.1

ロジカル・スタンバイ・データベースでの索引, 2.1.2, 10.5.4.1

新規または既存のスタンバイ・データベース, 1.3

オンラインREDOログ・ファイル, 9.3.5

表領域, 9.3.1

調整

初期化パラメータ・ファイル

ロジカル・スタンバイ・データベース用, 4.2.4.2

AFFIRM属性, 15 ALTER DATABASE文

ABORT LOGICAL STANDBY句, 16.1

ACTIVATE STANDBY DATABASE句, 8.3.2, 11.8.6, 16.1, 16.1

ADD STANDBY LOGFILE句, 16.1, A.1.1

ADD STANDBY LOGFILE MEMBER句, 16.1, A.1.1, A.1.1

ADD SUPPLEMENTAL LOG DATA句, 16.1

CLEAR UNARCHIVED LOGFILES句, 9.5

COMMIT TO SWITCHOVER句, 8.3.1, 8.3.1, 8.3.1, 16.1

Oracle Real Application Cluster, D.3.1

トラブルシューティング, A.4.2, A.4.2, A.4.3

CREATE CONTROLFILE句, 9.5 CREATE DATAFILE AS句, A.1.1 CREATE STANDBY CONTROLFILE句, 3.2.2, A.1.3

REUSE句, 16.1

DROP LOGFILE句, A.1.1 DROP STANDBY LOGFILE MEMBER句, 16.1, 16.1, 16.1, A.1.1 FORCE LOGGING句, 2.3.2, 3.1.1, 13.4, 13.4, 16.1 GUARD句, 10.2 MOUNT STANDBY DATABASE句, 16.1 OPEN READ ONLY句, 16.1 OPEN RESETLOGS句, 3.2.2, 9.5 PREPARE TO SWITCHOVER句, 8.3.1, 8.3.1, 16.1 RECOVER MANAGED STANDBY DATABASE句, 3.2.6, 4.2.5, 16.1, 16.1, 16.1

バックグラウンド・プロセス, 7.3.1

取消し, 7.3.2

REDO Applyの制御, 7.3.1, 11.8.2

フェイルオーバー, 16.1

フォアグラウンド・セッション, 7.3.1

遅延間隔の上書き, 7.2.2

リアルタイム適用の開始, 7.3.1

REGISTER LOGFILE句, 16.1, A.4.1 RENAME FILE句, A.1.1, A.1.1 SET STANDBY DATABASE句

TO MAXIMIZE AVAILABILITY句, 16.1

TO MAXIMIZE PERFORMANCE句, 8.1.4

TO MAXIMIZE PROTECTION句, 16.1

START LOGICAL STANDBY APPLY句, 7.4.1, 12.5, A.6

IMMEDIATEキーワード, 7.4.1

SQL Applyの開始, 4.2.5

STOP LOGICAL STANDBY APPLY句, 7.4.2, 8.3.2, 16.1 ALTER SESSION DISABLE GUARD文

データベース・ガードのオーバーライド, 10.5.4

ALTER SESSION文

ENABLE GUARD句, 16.2

ALTER SYSTEM文

SWITCH LOGFILE句, 3.2.7

ALTER TABLESPACE文, 9.3.4, 13.4.2, A.10.1.1

FORCE LOGGING句, 9.3.6

代替アーカイブ先

初期化パラメータの設定, A.2

ALTERNATE属性, 15, 15

LOG_ARCHIVE_DEST_n初期化パラメータ, A.2

LOG_ARCHIVE_DEST_STATE_n初期化パラメータ, 6.2.2

ANALYZERプロセス, 10.1 APPLIERプロセス, 10.1 適用ラグ

リアルタイム問合せ環境での監視, 9.2.1.1

適用ラグ許容差

リアルタイム問合せ環境での構成, 9.2.1.2

適用サービス

定義, 1.2.2, 7.1

REDOデータの適用遅延, 7.2.2, 15

リアルタイム適用

定義, 7.2.1, 7.2.1

LOG_ARCHIVE_TRACEによる監視, F.2

REDO Apply

定義, 7.1, 7.3

監視, 7.3.3

開始 7.3.1

停止, 7.3.2

SQL Apply

定義, 1.2.2, 7.1, 7.1

監視, 7.4.3

開始, 7.4.1

停止, 7.4.2

適用

REDOデータの即時, 7.2.1

スタンバイ・データベースのREDOデータ, 1.2, 1.2.2, 7

SQL文をロジカル・スタンバイ・データベースに, 7.4

適用中状態, 10.4.1 AQ_TM_PROCESSES動的パラメータ, A.4.2 アーカイブ先

代替, A.2

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

情報へのアクセス, 9.5.1.3

適用

REDO Applyテクノロジ, 1.2.2

SQL Applyテクノロジ, 1.2.2

適用の遅延, 15

スタンバイ・データベース, 7.2.2

不要なファイルの削除, 10.4.2 宛先

無効化, 6.2.2

有効化, 6.2.2

ギャップ管理, 1.7

「ギャップ管理」を参照

手動による転送, 2.3.2 転送されたREDOデータ, 1.2.2, 7.1 登録

フェイルオーバー時, 8.3.2

スタンバイ・データベース, 7.3.3, 7.4.3, 9.5.1 スイッチオーバーの問題のトラブルシューティング, A.4.1 ARCHIVELOGモード

ソフトウェア要件, 2.3.2

アーカイバ・プロセス(ARCn)

MAX_CONNECTIONS属性による影響, 15

アーカイブ

リアルタイム適用, 7.2.1

指定

障害解決ポリシー, 15

スタンバイREDOログ, 6.2.3.2

高速リカバリ領域, 6.2.3.2.2

ローカル・ファイル・システム, 6.2.3.2.3

失敗した宛先へ, 15 ASM

「自動ストレージ管理(ASM)」を参照

ASYNC属性, 15 属性

LOG_ARCHIVE_DEST_n初期化パラメータについて非推奨, 15

AUD$表

ロジカル・スタンバイでのレプリケーション, C.12.2

自動ブロック修復, 9.2.1.5 欠落しているログ・ファイルの自動検出, 1.2.1, 1.7 自動フェイルオーバー, 1.2.3 自動ストレージ管理(ASM)

使用するスタンバイ・データベースの作成, 13.5

自動スイッチオーバー, 1.2.3

「スイッチオーバー」を参照

B

BACKUP INCREMENTAL FROM SCNコマンド

使用例, 11.10

バックアップ操作

フェイルオーバー後, 8.3.2

リカバリ不能な操作の後, 13.4.3, 13.4.3

フィジカル・スタンバイ・データベースの構成, 1.1.3

データファイル, 13.4.2

スタンバイ・データベースでのオフロード, 1.7

プライマリ・データベース, 1.1.2

ブローカによる使用, 1.3

RMANの使用, 11

読取り可能な基本スタンバイ・データベース 「スタンバイ・データベース環境のシミュレーション」を参照 バッチ処理

ロジカル・スタンバイ・データベースで, 10.1.1.4

メリット

Data Guard, 1.7

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

ローリング・アップグレード, 12.1

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

BFILEデータ型

ロジカル・スタンバイ・データベース, C.1.2

ブロック修復, 自動, 9.2.1.5 ブローカ

コマンドライン・インタフェース, 1.7

定義, 1.3

グラフィカル・ユーザー・インタフェース, 1.7

BUILDERプロセス, 10.1

C

REDOデータのカスケード, 6.3

要件の構成, 6.3

データ保護の考慮事項, 6.3.2

制限, 6.3

キャラクタ・セット

プライマリ・データベースでの変更, 13.8

異なるものを使用して構成, C.15

チェックリスト

フィジカル・スタンバイ・データベース作成に関するタスク, 3.2, 3.2

スタンバイ・データベース作成に関するタスク, 4.2, 4.2

チェックポイント

V$LOGSTDBY_PROGRESSビュー, 10.1.1.3

チャンク

トランザクション, 10.1.1.1

CJQ0プロセス, A.4.2 CLEAR UNARCHIVED LOGFILES句

ALTER DATABASE, 9.5

コレクション・データ型

ロジカル・スタンバイ・データベース, C.1.2

コマンドライン・インタフェース

ブローカ, 1.7

コマンド, Recovery Manager

DUPLICATE, E.2.1

COMMIT TO SWITCHOVER句

ALTER DATABASE, 8.3.1, 8.3.1, 16.1

Oracle Real Application Cluster, D.3.1

トラブルシューティング, A.4.2, A.4.2, A.4.3

COMMIT TO SWITCHOVER TO PRIMARY句

ALTER DATABASE, 8.3.1

通信

Data Guard構成のデータベース間, 1.1

COMPATIBLE初期化パラメータ

Oracle Databaseソフトウェアのアップグレード後の設定, B.4

ローリング・アップグレードの設定, 12.2, 12.5, 12.5

補完テクノロジ, 1.6 COMPRESSION属性, 15 構成オプション

Data Guard Brokerでの作成, 1.3

概要, 1.1

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

位置とディレクトリ構造, 2.4

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

遅延スタンバイ, 7.2.2

構成

スタンバイ・データベースでのバックアップ, 1.1.3

障害時リカバリ, 1.1.3

初期化パラメータ

代替アーカイブ先, A.2

フィジカル・スタンバイ・データベースのリスナー, 3.2.5 データ消失はない, 1.2.3 フィジカル・スタンバイ・データベース, 2.4 ロジカル・スタンバイ・データベースでのレポート生成操作, 1.1.3 リモート位置のスタンバイ・データベース, 1.1.3 制約

ロジカル・スタンバイ・データベースでの処理, 10.6.3

Context

サポートされていないデータ型, C.1.2

Contextデータ型

ロジカル・スタンバイ・データベース, C.1.2

制御ファイル

コピー, 3.2.4

スタンバイ・データベース用に作成, 3.2.2

ALTER DATABASE文のCONVERT TO SNAPSHOT STANDBY句, 16.1 変換

ロジカル・スタンバイ・データベースからフィジカル・スタンバイ・データベースへ

中止, 4.2.4.1

フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースへ, 4.2.4.1 COORDINATORプロセス, 10.1

LSPバックグラウンド・プロセス, 10.1

コピー

制御ファイル, 3.2.4

CREATE CONTROLFILE句

ALTER DATABASE, 9.5

CREATE DATABASE文

FORCE LOGGING句, 13.4

CREATE DATAFILE AS句

ALTER DATABASE, A.1.1

CREATE STANDBY CONTROLFILE句

ALTER DATABASE, 3.2.2, 16.1, A.1.3

CREATE TABLE AS SELECT(CTAS)文

ロジカル・スタンバイ・データベースで適用, 10.1.1.5

作成

ロジカル・スタンバイ・データベースでの索引, 10.5.4.1

D

データ可用性

システム・パフォーマンス要件とのバランス, 1.7

Data Guard Broker

定義, 1.3

分散管理フレームワーク, 8

フェイルオーバー, 1.3

ファスト・スタート, 8

手動, 1.3, 8

ファスト・スタート・フェイルオーバー, 1.3 スイッチオーバー, 8 Data Guard構成

ログ・ライター・プロセスを使用したスタンバイ宛先へのアーカイブ, 7.2.1

定義, 1.1

保護モード, 1.4

Oracle Databaseソフトウェアのアップグレード, B

データ消失

フェイルオーバーによる, 1.2.3

スイッチオーバー, 8.1

データ保護

パフォーマンスとのバランス, 1.7

メリット, 1.7

柔軟性, 1.7

Data Guardによる実現, 1

データ保護モード

REDO転送サービスによる実行, 1.2.1

概要, 1.4, 1.4

データ・ポンプ・ユーティリティ

フィジカル・スタンバイ・データベースでのトランスポータブル表領域の使用, 9.3.3

データ型

BFILE, C.1.2

ロジカル・スタンバイ・データベースでのコレクション, C.1.2

ROWID, C.1.2

Spatial、ImageおよびContext, C.1.2

UROWID, C.1.2

ユーザー定義, C.1.2

データベース・ガード, 10.5.4

オーバーライド, 10.5.4

データベース・インカネーション

OPEN RESETLOGS, 9.4, 9.4

データベースのロール

プライマリ, 1.1.1, 8.1

スタンバイ, 1.1.2, 8.1

推移, 1.2.3

データベース・スキーマ

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

データベース

フェイルオーバー, 8.1.4

ロールの推移, 8.1

障害とデータ破損からの保護, 1

ソフトウェア・バージョンのアップグレード, 12.1

データファイル

プライマリ・データベースへの追加, 9.3.1

監視, 9.5, 13.4.2

プライマリ・データベースでの改名, 9.3.4

DB_FILE_NAME_CONVERT初期化パラメータ

スイッチオーバー後スタンバイサイトで設定, A.4.4

フィジカル・スタンバイ・データベースで設定, 3.2.3

位置とディレクトリ構造の計画時, 2.4

DB_NAME初期化パラメータ, 3.1.4 DB_ROLE_CHANGEシステムイベント, 8.1.5 DB_UNIQUE_NAME属性, 15 DB_UNIQUE_NAME初期化パラメータ, A.4.3

LOG_ARCHIVE_CONFIGパラメータとともに必須, 14

データベース初期化パラメータの設定, 3.1.4

DBA_DATA_FILESビュー, 9.5 DBA_LOGMNR_PURGED_LOGビュー

削除できるアーカイブREDOログ・ファイルのリスト, 10.4.2

DBA_LOGSTDBY_EVENTSビュー, 10.3.1, 17, A.6

サポートされない操作の記録, 10.5.1

DBA_LOGSTDBY_HISTORYビュー, 17 DBA_LOGSTDBY_LOGビュー, 10.3.2, 17 DBA_LOGSTDBY_NOT_UNIQUEビュー, 17 DBA_LOGSTDBY_PARAMETERSビュー, 17 DBA_LOGSTDBY_SKIPビュー, 17 DBA_LOGSTDBY_SKIP_TRANSACTIONビュー, 17 DBA_LOGSTDBY_UNSUPPORTEDビュー, 17 DBA_TABLESPACESビュー, 9.5 DBMS_ALERT, C.9.2 DBMS_AQ, C.9.2 DBMS_DESCRIBE, C.9.1 DBMS_JAVA, C.9.2 DBMS_LOB, C.9.1 DBMS_LOGSTDBYパッケージ

INSTANTIATE_TABLEプロシージャ, 10.5.5

SKIPプロシージャ, A.6

SKIP_ERRORプロシージャ, A.3

SKIP_TRANSACTIONプロシージャ, A.6

DBMS_LOGSTDBY.BUILDプロシージャ

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

DBMS_METADATA, C.9.1 DBMS_OBFUSCATION_TOOLKIT, C.9.1 DBMS_OUTPUT, C.9.1 DBMS_PIPE, C.9.1 DBMS_RANDOM, C.9.1 DBMS_REDEFINITION, C.9.2 DBMS_REFRESH, C.9.2 DBMS_REGISTRY, C.9.2 DBMS_SCHEDULER, C.9.1 DBMS_SPACE_ADMIN, C.9.2 DBMS_SQL, C.9.1 DBMS_TRACE, C.9.1 DBMS_TRANSACTION, C.9.1 DBSNMPプロセス, A.4.2 DDL文

SQL Applyでサポート, C

DDL文

DBLINKSを使用, C.12.1

DDLトランザクション

ロジカル・スタンバイ・データベースで適用, 10.1.1.5

ロジカル・スタンバイ・データベースに適用, 10.1.1.5

DEFER属性

LOG_ARCHIVE_DEST_STATE_n初期化パラメータ, 6.2.2

DELAY属性, 15

LOG_ARCHIVE_DEST_n初期化パラメータ, 7.2.2

DELAYオプション

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

取消し, 7.2.2

遅延

アーカイブREDOログ・ファイルの適用, 15

REDOログ・ファイルの適用, 7.2.2

削除

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

DBA_LOGMNR_PURGED_LOGビューに表示, 10.4.2

SQL Applyで不要, 10.4.2

非推奨になった属性

LOG_ARCHIVE_DEST_n初期化パラメータ, 15

宛先

V$ARCHIVE_DESTに表示, 17

ロールベースの定義, 15

検出

欠落しているアーカイブREDOログ・ファイル, 1.2.1, 1.7

DG_CONFIG属性, 15 DGMGRLコマンドライン・インタフェース

フェイルオーバーの起動, 1.3, 8

スイッチオーバーの単純化, 1.3, 8

ディクショナリ

LogMinerの構築, 4.2.3.2

ダイレクト・パス・インサート

SQL Apply DMLの考慮事項, 10.1.1.4

ディレクトリ位置

Optimal Flexible Architecture(OFA), 2.4, 2.4

ASMによる設定, 2.4

OMFによる設定, 2.4

スタンバイ・データベースの構造, 2.4

無効化

アーカイブREDOログ・ファイルの宛先, 6.2.2

障害時リカバリ

メリット, 1.7

構成, 1.1.3

Data Guardによる実現, 1

スタンバイ・データベースによる実現, 1.1.3

ディスクI/O

AFFIRMおよびNOAFFIRM属性で制御, 15

分散トランザクション, C.13 DML

ロジカル・スタンバイ・データベースでのバッチ更新, 10.1.1.4

DMLトランザクション

ロジカル・スタンバイ・データベースに適用, 10.1.1.4

ダウングレード

Oracle Databaseソフトウェア, B.6

DROP STANDBY LOGFILE句

ALTER DATABASE, A.1.1

DROP STANDBY LOGFILE MEMBER句

ALTER DATABASE, 16.1, 16.1, 16.1, A.1.1

削除

オンラインREDOログ・ファイル, 9.3.5

動的パラメータ

AQ_TM_PROCESSES, A.4.2

JOB_QUEUE_PROCESSES, A.4.2

E

ENABLE属性

LOG_ARCHIVE_DEST_STATE_n初期化パラメータ, 6.2.2

ENABLE GUARD句

ALTER SESSION, 16.2

使用可能

ロジカル・スタンバイ・データベースにおけるデータベース・ガード, 16.2

アーカイブREDOログ・ファイルの宛先, 6.2.2

リアルタイム適用

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

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

拡張可能索引

ロジカル・スタンバイ・データベースによるサポート, C.1.2

F

フェイルオーバー, 1.2.3

Data Guard Broker, 1.3, 8

定義, 1.2.3, 8.1

DBA_LOGSTDBY_HISTORYに履歴を表示, 17

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

後のデータベースのフラッシュバック, 8.4

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

手動と自動, 1.2.3

後のバックアップの実行, 8.3.2

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

準備, 8.1.4

Data Guard Brokerでの単純化, 8

REDOデータの事前転送, 8.1.4

ロジカル・スタンバイ・データベースの特性の表示, 10.3.3

最大パフォーマンス・モード, 8.1.4

最大保護モード, 8.1.4

障害解決ポリシー

REDO転送サービスに関する指定, 15

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

自動フェイルオーバー, 1.3, 8

監視, 9.5

FGA_LOG$表

ロジカル・スタンバイでのレプリケーション, C.12.2

ファイル指定

ロジカル・スタンバイ・データベースでの改名, 10.5.3

フラッシュバック・データベース

ロールの推移後, 8.4

OPEN RESETLOGS後, 13.3

ロールの推移後, 8.4

Data Guardを補完する特性, 1.6

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

FORCE LOGGING句

ALTER DATABASE, 2.3.2, 3.1.1, 13.4, 13.4, 16.1

ALTER TABLESPACE, 9.3.6

CREATE DATABASE, 13.4

G

ギャップ管理

自動検出と自動解消, 1.2.1, 1.7

欠落しているログ・ファイルの検出, 1.7

アーカイブREDOログ・ファイルの登録

フェイルオーバー時, 8.3.2

GV$INSTANCEビュー, D.3.1

H

高可用性

メリット, 1.7

Data Guardによる実現, 1

Oracle RACおよびData Guardによる実現, 1.6

I

アイドル状態, 10.4.1

Imageデータ型

ロジカル・スタンバイ・データベース, C.1.2

データベースのインカネーション

変更, 9.4, 9.4

初期化パラメータ

DB_UNIQUE_NAME, 3.1.4, A.4.3

LOG_ARCHIVE_MIN_SUCCEED_DEST, 15

LOG_ARCHIVE_TRACE, F.2

LOG_FILE_NAME_CONVERT, E.2.2.4

フィジカル・スタンバイ・データベースの変更, 3.2.3

プライマリ・ロールおよびスタンバイ・ロールの設定, 15

INITIALIZING状態, 10.4.1 INSTANTIATE_TABLEプロシージャ

DBMS_LOGSTDBY, 10.5.5

J

JOB_QUEUE_PROCESSES動的パラメータ, A.4.2

K

KEEP IDENTITY句, 4.2.4.1

L

待機時間

ロジカル・スタンバイ・データベース, 10.1.1.4, 10.1.1.5

listener.oraファイル

構成, 3.2.5

REDO転送サービス調整, A.7

トラブルシューティング, A.1.2, A.7

ディクショナリ・ロード中状態, 10.4.1 LOCATION属性, 15

設定

LOG_ARCHIVE_DEST_n初期化パラメータ, A.2

ログ適用サービス

REDO Apply

監視, 9.5.1

開始 9.1.1

停止, 9.1.2

REDO Applyに関するチューニング, 9.6 ログ・ライター・プロセス(LGWR)

ASYNCネットワーク転送, 15

NET_TIMEOUT属性, 15

SYNCネットワーク転送, 15

LOG_ARCHIVE_CONFIG初期化パラメータ, 3.1.4, 3.1.4, 3.2.3

例, 15

定義済の一意のデータベース名のリスト表示, 17

DB_UNIQUE_NAMEパラメータとの関係, 14

DG_CONFIG属性との関係, 15

LOG_ARCHIVE_DEST_n初期化パラメータ

AFFIRM属性, 15

ALTERNATE属性, 15, 15, A.2

ASYNC属性, 15

COMPRESSION属性, 15

DB_UNIQUE_NAME属性, 15

DELAY属性, 7.2.2, 15

非推奨になった属性, 15

LOCATION属性, 15, A.2

MANDATORY属性, 15

MAX_CONNECTIONS属性, 15

MAX_FAILURE属性, 15

NET_TIMEOUT属性, 15

NOAFFIRM属性, 15

NOALTERNATE属性, A.2

NODELAY属性, 7.2.2

NOREGISTER属性, 15

REOPEN属性, 15, 15

SERVICE属性, 15

SYNC属性, 15

VALID_FOR属性, 15

LOG_ARCHIVE_DEST_STATE_n初期化パラメータ

ALTERNATE属性, 6.2.2

DEFER属性, 6.2.2

ENABLE属性, 6.2.2

LOG_ARCHIVE_MAX_PROCESSES初期化パラメータ

MAX_CONNECTIONSとの関係, 15

LOG_ARCHIVE_MIN_SUCCEED_DEST初期化パラメータ, 15 LOG_ARCHIVE_TRACE初期化パラメータ, F.2 LOG_FILE_NAME_CONVERT初期化パラメータ

スイッチオーバー後スタンバイサイトで設定, A.4.4

フィジカル・スタンバイ・データベースで設定, 3.2.3

位置とディレクトリ構造の計画時, 2.4

論理変更レコード(LCR)

PREPARERプロセスによる変換, 10.1

全体が使用済のキャッシュ・メモリー, 10.1.1.2

ステージング, 10.1

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

追加

データファイル, A.10.1.1

索引, 2.1.2, 10.5.4.1

表, 10.5.5

バックグラウンド・プロセス, 10.1 メリット, 2.1.2 表に対するユーザー・アクセスの制御, 10.2 作成, 4

フィジカル・スタンバイ・データベースからの変換, 4.2.4.1

Data Guard Broker, 1.3

データ型

サポートされる, C, C.1.1

サポートされない, C.1.2

データベース・ガード

オーバーライド, 10.5.4

SQL文の実行, 1.1.2 フェイルオーバー, 8.3.2

履歴の表示, 17, 17

障害の処理, A.3

V$LOGSTDBY_STATSに特性を表示, 10.3.3

ロジカル・スタンバイ・プロセス(LSP), 10.1 マテリアライズド・ビュー

作成, 2.1.2

サポート, C.11

監視, 7.4.3, 17 ファイル指定の改名, 10.5.3 スキップ・ハンドラの設定, 10.5.3 SQL Apply, 1.2.2

REDOのプライマリ・データベース・ブランチとの再同期化, 10.6.5

DDL文のスキップ, C.11

SQL文のスキップ, C.11

リアルタイム適用の開始, 7.4.1

停止, 7.4.2

テクノロジ, 7.1

トランザクション・サイズの考慮事項, 10.1.1.1

開始

リアルタイム適用, 7.4.1, 7.4.1

状態

適用, 10.4.1

アイドル, 10.4.1

初期化, 10.4.1

ディクショナリ・ロード中, 10.4.1

ギャップ待機中, 10.4.1

透過的データ暗号化を指定したプライマリ・データベースのサポート, C.2 スイッチオーバー, 8.3.1, 8.3.1 スループットと待機時間, 10.1.1.4, 10.1.1.5 アップグレード, B.3

ローリング・アップグレード, 2.3.2

ロジカル・スタンバイ・プロセス(LSP)

COORDINATORプロセス, 10.1

LogMinerディクショナリ

DBMS_LOGSTDBY.BUILDプロシージャを使用した構築, 4.2.3.2

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

M

管理リカバリ操作

「Redo Apply」を参照

MANDATORY属性, 15 マテリアライズド・ビュー

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

MAX_CONNECTIONS属性

パラレル・アーカイブ用のOracle RACの構成, 15

参照, 15

MAX_FAILURE属性, 15 最大可用性モード

概要, 1.4

最大パフォーマンス・モード, 8.1.4

概要, 1.4

最大パフォーマンス保護モード, 5.1 最大保護モード

Oracle Real Application Cluster, D.2.2

概要, 1.4

スタンバイ・データベース, 8.1.4

メモリー

全体が使用済のLCRキャッシュ, 10.1.1.2

欠落しているログ順序番号

「ギャップ管理」を参照

検出, 1.7, 1.7

変更

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

フィジカル・スタンバイ・データベース用の初期化パラメータ, 3.2.3

監視

プライマリ・データベース・イベント, 9.5

表領域の状態, 9.5

MOUNT STANDBY DATABASE句

ALTER DATABASE, 16.1

マルチメディア・データ型

ロジカル・スタンバイ・データベース, C.1.2

ロジカル・スタンバイ・データベースでサポートされない, C.1.2

N

NET_TIMEOUT属性, 15

ネットワーク接続

複数の構成, 15

Oracle RAC環境, 15

ネットワークI/O操作

ネットワーク・タイマー

NET_TIMEOUT属性, 15

調整

REDO転送サービス, A.7

ネットワーク・タイムアウト

応答, 15

データ消失はない

データ保護モードの概要, 1.4

保証, 1.2.3

保証, 1.2.3

最大可用性モードによる実現, 1.4

最大保護モードによる実現, 1.4

NOAFFIRM属性, 15 NOALTERNATE属性

LOG_ARCHIVE_DEST_n初期化パラメータ, A.2

NODELAY属性

LOG_ARCHIVE_DEST_n初期化パラメータ, 7.2.2

NOREGISTER属性, 15

O

OMF

「Oracle Managed Files(OMF)」を参照

ディスク上のデータベース構造

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

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

追加, 9.3.5

削除, 9.3.5

OPEN READ ONLY句

ALTER DATABASE, 16.1

OPEN RESETLOGS

後のフラッシュバック, 13.3

OPEN RESETLOGS句

データベース・インカーネーションの変更, 9.4, 9.4

ALTER DATABASE, 3.2.2, 9.5

リカバリ, 9.4, 9.4

動作要件, 2.3, 2.3.2 Optimal Flexible Architecture(OFA)

ディレクトリ構造, 2.4, 2.4

ORA-01102メッセージ

スイッチオーバー障害の原因となる, A.4.3

Oracle Automatic Storage Management(ASM), 2.4 Oracle Databaseソフトウェア

SQL Applyを使用したアップグレードの要件, 12.2

アップグレード, 2.3.2, B.1

SQL Applyを使用したアップグレード, 12.1

Oracle Enterprise Manager

フェイルオーバーの起動, 1.3, 8

スイッチオーバーの起動, 1.3, 8

Oracle Managed Files(OMF), 2.4

使用するスタンバイ・データベースの作成, 13.5

Oracle Net

Data Guard構成のデータベース間の通信, 1.1

Real Application Clusters

Data Guardを補完する特性, 1.6

複数のネットワーク接続に対する構成, 15

プライマリ・データベース, 1.1.1, D.1.1

設定

最大データ保護, D.2.2

スタンバイ・データベース, 1.1.2, D.1 Oracle Recovery Managerユーティリティ(RMAN)

フィジカル・スタンバイ・データベースのバックアップ・ファイルの作成, 11

Oracle Standard Edition

スタンバイ・データベース環境の再現, 2.3.2

P

ページアウトの考慮事項, 10.1.1.2

ページアウト

SQL Apply, 10.1.1.2

パラレルDML(PDML)トランザクション

SQL Apply, 10.1.1.3, 10.1.1.4

パッチ・セット・リリース

アップグレード, 2.3.2

パフォーマンス

データ可用性とのバランス, 1.7

データ保護とのバランス, 1.7

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

およびOracle Active Data Guard, 2.1.1

REDOデータの適用, 7.1, 7.3

REDO Applyテクノロジ, 7.3

REDOログ・ファイルの適用

開始 7.3.1

メリット, 2.1.1 構成オプション, 2.4 データファイルのパス名の変換, 3.2.3 ログ・ファイルのパス名の変換, 3.2.3 ロジカル・スタンバイ・データベースへの変換, 4.2.4.1 作成

タスクのチェックリスト, 3.2

リスナーの構成, 3.2.5

ディレクトリ構造, 2.4

初期化パラメータ, 3.2.3

Data Guard Broker, 1.3

定義, 1.1.2 フェイルオーバー

更新をチェック, 8.1.4

フェイルオーバー後のフラッシュバック, 13.2.1 監視, 7.3.3, 9.5.1, 17 読取り専用または読取り/書込みアクセス用にオープン, 9.2 読取り専用, 9.2 OPEN RESETLOGS操作によるリカバリ, 9.4 REDO Apply, 1.2.2 REDOのプライマリ・データベース・ブランチとの再同期化, 9.4, 9.4 ロールの推移, 8.2 BACKUP INCREMENTAL FROM SCNコマンドによるロール・フォワード, 11.10 停止, 9.1.2 開始

適用サービス, 7.3.1

リアルタイム適用, 7.3.1

プライマリ・データベースとの同期化, 11.10 ログ適用レートのチューニング, 9.6 アップグレード, B.2 トランスポータブル表領域の使用, 9.3.3 PL/SQLパッケージ

サポートされる, C.9.1

サポートされない, C.9.2

PREPARE TO SWITCHOVER句

ALTER DATABASE, 8.3.1, 8.3.1, 16.1

PREPARERプロセス, 10.1

SGA内でのLCRのステージング, 10.1

プライマリ・データベース

バックアップ, 8.3.2

構成

Oracle Real Application Cluster, 1.1.1

単一インスタンス, 1.1.1

データファイル

追加, 9.3.1

定義, 1.1.1 フェイルオーバー, 8.1 ギャップの解決, 1.7 初期化パラメータ

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

イベントの監視, 9.5 ネットワーク接続

ネットワーク停止の回避, 15

ネットワーク・タイムアウトの処理, 15

Oracle Real Application Clusters

設定, D.1.1

準備

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

要件

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

REDO転送サービス, 1.2.1 ワークロードの低減, 1.7 スイッチオーバー, 8.1.3 表領域

追加, 9.3.1

プライマリ・データベース

ARCHIVELOGモード, 2.3.2

ソフトウェア要件, 2.3.2

主キー列

サプリメンタル・ロギングを使用したログ, 4.2.3.2, 10.1.1.4

プライマリ・ロール, 1.1.1 プロセス

CJQ0, A.4.2

DBSNMP, A.4.2

スイッチオーバーの防止, A.4.2

QMN0, A.4.2

SQL Applyアーキテクチャ, 10.1, 10.4.1

保護モード

最大可用性モード, 1.4

最大パフォーマンス, 5.1

最大パフォーマンス・モード, 1.4

最大保護モード, 1.4

監視, 9.5

プライマリ・データベースでの設定, 5.2

Q

QMN0プロセス, A.4.2

問合せ

スタンバイ・データベースでのオフロード, 1.7

R

READERプロセス, 10.1

読取り専用操作, 1.2.2

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

リアルタイム適用

定義, 7.2.1

ログ適用サービスの概要, 1.2

開始 7.3.1

ロジカル・スタンバイ, 7.4.1

ロジカル・スタンバイ・データベースでの開始, 7.4.1 フィジカル・スタンバイ・データベースでの開始, 7.3.1 停止

ロジカル・スタンバイ, 7.4.2

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

LOG_ARCHIVE_TRACE初期化パラメータによるデータの追跡, F.2 リアルタイム問合せ機能, 9.2

およびOracle Active Data Guard, 9.2, 9.2.1

適用ラグ許容差の構成, 9.2.1.2

REDO Applyの強制同期, 9.2.1.3

適用ラグの監視, 9.2.1.1

制限, 9.2.1.4

使用, 9.2.1

RECORD_UNSUPPORTED_OPERATIONS

例, 10.5.1

RECOVER MANAGED STANDBY DATABASE CANCEL句

中止, 4.2.4.1

RECOVER MANAGED STANDBY DATABASE句

DELAY制御オプションの取消し, 7.2.2

ALTER DATABASE, 3.2.6, 4.2.5, 7.3.1, 16.1, 16.1, 16.1, 16.1

バックグラウンド・プロセス, 7.3.1

REDO Applyの制御, 7.3.1, 11.8.2

フォアグラウンド・セッション, 7.3.1

遅延間隔の上書き, 7.2.2

リアルタイム適用の開始, 7.3.1

RECOVER TO LOGICAL STANDBY句

フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースへの変換, 4.2.4.1

リカバリ

エラー, A.10.1

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

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

OPEN RESETLOGS後, 9.4, 9.4

リセットログの使用, 9.4, 10.6.5 Recovery Manager

Data Guardを補完する特性, 1.6

コマンド

DUPLICATE, E.2.1

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

作成, E.2.1

LOG_FILE_NAME_CONVERT初期化パラメータ, E.2.2.4

Recovery Managerの準備, E.2.2

再作成

ロジカル・スタンバイ・データベース上の表, 10.5.5

REDO Apply

定義, 1.2.2, 7.1

フェイルオーバー後のフラッシュバック, 13.2.1

開始 3.2.6, 7.3.1

停止, 9.1.2

テクノロジ, 1.2.2

ログ適用レートのチューニング, 9.6

REDOデータ

適用

REDO Applyテクノロジの使用, 1.2.2

SQL Applyテクノロジの使用, 1.2.2

スタンバイ・データベースへ, 7.1

スタンバイ・データベースへ, 1.1.2

フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースヘの変換中の適用, 4.2.4.1 スタンバイ・システムでのアーカイブ, 1.2.2, 7.1 ディクショナリの構築, 4.2.3.2 カスケード, 6.3 手動による転送, 2.3.2 転送, 1.1.2, 1.2.1 REDOギャップ, 6.4.3

手動による解決, 6.4.3.1

解決時間の短縮, 6.4.3

REDOログ・ファイル

適用の遅延, 7.2.2

REDOログ

フィジカル・スタンバイ・データベースでの自動適用, 7.3.1

スタンバイ・データベース表の更新, 1.7

REDO転送サービス, 6

アーカイブ先

代替, A.2

失敗した宛先への再アーカイブ, 15

セッションの認証

パスワード・ファイルの使用, 6.2.1.2

SSLの使用, 6.2.1.1

構成, 6.2 セキュリティの構成, 6.2.1 定義, 1.2.1 ギャップの検出, 6.4.3 アーカイブ障害の処理, 15 ステータスの監視, 6.4.1 ネットワーク

調整, A.7

保護モード

最大可用性モード, 1.4

最大パフォーマンス・モード, 1.4

最大保護モード, 1.4

REDOデータの受信, 6.2.3 REDOデータの送信, 6.2.2 同期および非同期ディスクI/O, 15 待機イベント, 6.4.4 REGISTER LOGFILE句

ALTER DATABASE, 16.1, A.4.1

REGISTER LOGICAL LOGFILE句

ALTER DATABASE, 8.3.2

登録

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

フェイルオーバー時, 8.3.2

RELY制約

作成, 4.1.2

リモート・ファイル・サーバー・プロセス(RFS)

ログ・ライター・プロセス, 7.2.1

RENAME FILE句

ALTER DATABASE, A.1.1, A.1.1

改名

データファイル

プライマリ・データベース上, 9.3.4

STANDBY_FILE_MANAGEMENTパラメータの設定, 9.3.4

REOPEN属性, 15, 15 レポート生成操作

構成, 1.1.3

スタンバイ・データベースでのオフロード, 1.7

ロジカル・スタンバイ・データベースでの実行, 1.1.2

要件

ローリング・アップグレード, 12.2

再開の考慮事項

SQL Apply, 10.1.1.3

再同期化

ロジカル・スタンバイ・データベースとREDOの新規ブランチ, 10.6.5

フィジカル・スタンバイ・データベースとREDOの新規ブランチ, 9.4, 9.4

取得

欠落しているアーカイブREDOログ・ファイル, 1.2.1, 1.7

Recovery Manager

増分バックアップ, 11.10

フィジカル・スタンバイ・データベースのロール・フォワード, 11.10

RMAN BACKUP INCREMENTAL FROM SCNコマンド, 11.10 Recovery Managerバックアップ

Data Guard環境におけるアクセス可能性, 11.1.3

Data Guard環境における関連付け, 11.1.2

Data Guard環境における互換性, 11.1.1

ロール管理サービス

定義, 8

ロールの推移のトリガー, 8.1.5

DB_ROLE_CHANGEシステムイベント, 8.1.5

ロールの推移, 1.2.3, 8.1

タイプの選択, 8.1.1

定義, 1.2.3

後のデータベースのフラッシュバック, 8.4

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

監視, 9.5

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

可逆的な推移, 1.2.3, 8.1

ロールベースの宛先

設定, 15

ロールバック

スイッチオーバー障害後, A.4.5

ローリング・アップグレード

ソフトウェア要件, 2.3.2

ローリング・アップグレード

メリット, 12.1

パッチ・セット・リリース, 2.3.2

要件, 12.2

COMPATIBLE初期化パラメータの設定, 12.2, 12.5, 12.5

サポートされないデータ型および記憶域属性, 12.4

KEEP IDENTITY句の使用, 4.2.4.1

ROWIDデータ型

ロジカル・スタンバイ・データベース, C.1.2

S

使用例

リカバリ

NOLOGGING指定後, 13.4

スキーマ

プライマリ・データベースと同一, 1.1.2

SCN

増分バックアップに使用, 11.10

順序

ロジカル・スタンバイ・データベースでサポートされない, C.10

SERVICE属性, 15 SET STANDBY DATABASE句

ALTER DATA, 16.1

ALTER DATABASE, 8.1.4, 16.1

停止

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

再現

スタンバイ・データベース環境, 2.3.2

スキップ・ハンドラ

ロジカル・スタンバイ・データベースでの設定, 10.5.3

SKIPプロシージャ

DBMS_LOGSTDBY, A.6

SKIP_ERRORプロシージャ

DBMS_LOGSTDBYパッケージ, A.3

SKIP_TRANSACTIONプロシージャ

DBMS_LOGSTDBY, A.6

スナップショット・スタンバイ・データベース, 1.1.2

管理, 9.7

ソフトウェア要件, 2.3.2

ローリング・アップグレード, 2.3.2, 2.3.2

Spatialデータ型

ロジカル・スタンバイ・データベース, C.1.2

SQL Apply, 7.4.2, 10.1.1.2

OPEN RESETLOGS後, 10.6.5

ANALYZERプロセス, 10.1

APPLIERプロセス, 10.1

CREATE TABLE AS SELECT(CTAS)文の適用, 10.1.1.5

DDLトランザクションの適用, 10.1.1.5, 10.1.1.5

DMLトランザクションの適用, 10.1.1.4

アーキテクチャ, 10.1, 10.4.1

BUILDERプロセス, 10.1

COORDINATORプロセス, 10.1

定義, 1.2.2, 7.1

アーカイブREDOログ・ファイルの削除, 10.4.2

パラレルDML(PDML)トランザクション, 10.1.1.3, 10.1.1.4

ローリング・アップグレードの実行, 12.1

PREPARERプロセス, 10.1

READERプロセス, 10.1

ローリング・アップグレードの要件, 12.2

再開の考慮事項, 10.1.1.3

ローリング・アップグレード, 2.3.2

開始

リアルタイム適用, 7.4.1

停止

リアルタイム適用, 7.4.2

DDL文のサポート, C PL/SQLパッケージのサポート, C.9.1 サポートされてるデータ型, C.1.1 トランザクション・サイズの考慮事項, 10.1.1.1 サポートされていないデータ型, C.1.2 サポートされないPL/SQLパッケージ, C.9.2 現行のアクティビティの表示, 10.1

プロセス, 10.1

停止した場合の処置, A.6 SQLセッション

スイッチオーバー障害の原因となる,A.4.2

SQL文

ロジカル・スタンバイ・データベースでの実行, 1.1.2, 1.2.2

ロジカル・スタンバイ・データベースでのスキップ, C.11

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

ロジカルの作成, 4

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

RMANを使用した作成, E.2.1

適用サービス, 7.1

REDOデータの適用, 7

REDOログ・ファイルの適用, 1.2.2, 1.7

複数のネットワーク接続を使用するARCnプロセス, 15

構成, 1.1

最大数, 2

Oracle Real Application Cluster, 1.1.2, D.1

リモート位置, 1.1.3

単一インスタンス, 1.1.2

作成, 1.1.2, 3

タスクのチェックリスト, 4.2

ディレクトリ構造の考慮事項, 2.4

プライマリがASMまたはOMFを使用している場合, 13.5

リモート・ホスト上で同一のディレクトリ構造, E.3

タイム・ラグのある, 7.2.2

定義, 2.1 フェイルオーバー

準備, 8.1.4

フェイルオーバー, 8.1.4 LOG_FILE_NAME_CONVERT初期化パラメータ, E.2.2.4 動作要件, 2.3, 2.3.2 Recovery Managerの準備, E.2.2 OPEN RESETLOGS操作によるリカバリ, 9.4 プライマリ・データベースとの再同期化, 1.7 Recovery Managerの増分バックアップによるロールフォワード, 11.10 SET AUXNAMEコマンド, E.2.2.4 SET NEWNAMEコマンド, E.2.2.4 ソフトウェア要件, 2.3.2 フィジカル・スタンバイ・データベースでの適用サービスの開始, 7.3.1 「フィジカル・スタンバイ・データベース」を参照 スタンバイREDOログ・ファイル

リアルタイム適用, 7.2.1

スタンバイREDOログ

高速リカバリ領域へのアーカイブ, 6.2.3.2.2

ローカル・ファイル・システムへのアーカイブ, 6.2.3.2.3

アーカイブの構成, 6.2.3.2

作成および管理, 6.2.3.1

スタンバイ・ロール, 1.1.2 STANDBY_FILE_MANAGEMENT初期化パラメータ

データファイルの改名時, 9.3.4

START LOGICAL STANDBY APPLY句

IMMEDIATEキーワード, 7.4.1

ALTER DATABASE, 4.2.5, 7.4.1, 12.5, A.6

開始

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

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

リアルタイム適用, 7.4.1, 7.4.1

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

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

REDO Apply, 3.2.6, 7.3.1, 9.1.1 SQL Apply, 4.2.5, 7.4.1 STOP LOGICAL STANDBY APPLY句

ALTER DATABASE, 7.4.2, 8.3.2, 16.1

停止

リアルタイム適用

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

フィジカル・スタンバイ・データベースでのリアルタイム適用, 7.3.2 REDO Apply, 7.3.2 SQL Apply, 7.4.2 記憶域属性

ローリング・アップグレード中にサポートされない, 12.4

Streams取得

ロジカル・スタンバイでの実行, 10.6.6

サプリメンタル・ロギング

主キー列と一意索引列を記録するための設定, 4.2.3.2, 10.1.1.4

サポートされるデータ型

ロジカル・スタンバイ・データベース, C, C.12

サポートされるPL/SQLパッケージ, C.9.1 SWITCH LOGFILE句

ALTER SYSTEM, 3.2.7

SWITCHOVER_STATUS列

V$DATABASEビュー, A.4.1

スイッチオーバー, 1.2.3

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

定義, 1.2.3, 8.1

DBA_LOGSTDBY_HISTORYに履歴を表示, 17

ORA-01102による失敗, A.4.3

後のデータベースのフラッシュバック, 8.4

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

手動と自動, 1.2.3

監視, 9.5

データ消失はない, 8.1

準備, 8.1.3

回避方法

アクティブなSQLセッション, A.4.2

CJQ0プロセス, A.4.2

DBSNMPプロセス, A.4.2

プロセス, A.4.2

QMN0プロセス, A.4.2

最後のアーカイブREDOログ・ファイルが転送されたかどうかの確認, A.4.1 DB_FILE_NAME_CONVERTの設定, A.4.4 LOG_FILE_NAME_CONVERTの設定, A.4.4 Data Guard Brokerでの単純化, 1.3, 8 最初からやりなおし, A.4.5 代表的な使用例, 8.1.3 SYNC属性, 15 システム・イベント

ロールの推移, 8.1.5

システム・グローバル領域(SGA)

論理変更レコードのステージング, 10.1

システム・リソース

効率的な使用, 1.7

T

表

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

追加, 10.5.5

表の再作成, 10.5.5

サポートされない, C.10

表領域

追加

新規データファイル, A.10.1.1

プライマリ・データベースへの, 9.3.1

状態の変更の監視, 9.5 データベース間の移動, 9.3.3 ターゲット・スタンバイ・データベース

スイッチオーバー, 8.1.2

終了

ネットワーク接続, 15

テキスト索引

ロジカル・スタンバイ・データベースによるサポート, C.1.2

スループット

ロジカル・スタンバイ・データベース, 10.1.1.4, 10.1.1.5

タイム・ラグ

アーカイブREDOログ・ファイルの適用の遅延, 7.2.2, 15

スタンバイ・データベース, 7.2.2

TIME_COMPUTED列, 8.1.2 V$DATAGUARD_STATSビューのTIME_COMPUTED列, 8.1.2 tnsnames.oraファイル

REDO転送サービス調整, A.7

トラブルシューティング, A.1.2, A.4.4, A.7

トレース・ファイル

データのトレース・レベル, F.2

設定, F.1

リアルタイム適用の追跡, F.2

トランザクション・サイズの考慮事項

SQL Apply, 10.1.1.1

透過的データ暗号化

SQL Applyでサポート, C.2

トランスポータブル表領域

フィジカル・スタンバイ・データベースでの使用, 9.3.3

トリガー

ロジカル・スタンバイ・データベースでの処理, 10.6.3

ロールの推移, 8.1.5

トラブルシューティング

SQL Applyが停止した場合, A.6

最後のREDOデータが転送されていない, A.4.1

listener.oraファイル, A.1.2, A.7

ロジカル・スタンバイ・データベース障害, A.3

スイッチオーバーを妨げるプロセス, A.4.2

SQL Apply, A.6

スイッチオーバー, A.4

アクティブなSQLセッション, A.4.2

ORA-01102メッセージ, A.4.3

ロールバックおよび最初からやりなおし, A.4.5

tnsnames.oraファイル, A.1.2, A.4.4, A.7 調整

REDO Applyのログ適用レート, 9.6

U

一意索引列

サプリメンタル・ロギングを使用したログ, 4.2.3.2, 10.1.1.4

リカバリ不能処理, 13.4.2

直後のバックアップ, 13.4.3

サポートされないデータ型

ローリング・アップグレード中, 12.4

サポートされない操作

DBA_LOGSTDBY_EVENTSビューでの取得, 10.5.1

サポートされないPL/SQLパッケージ, C.9.2 アップグレード

Oracle Databaseソフトウェア, 2.3.2, 12.1, B, B.1

COMPATIBLE初期化パラメータの設定, B.4

UROWIDデータ型

ロジカル・スタンバイ・データベース, C.1.2

ユーザー定義データ型

ロジカル・スタンバイ・データベース, C.1.2

USING CURRENT LOGFILE句

リアルタイム適用の開始, 7.3.1

V

V$ARCHIVE_DESTビュー, 17, A.1.2

すべての宛先の情報の表示, 17

V$ARCHIVE_DEST_STATUSビュー, 17 V$ARCHIVE_GAPビュー, 17 V$ARCHIVED_LOGビュー, 9.5.1.3, 17, A.4.1 V$DATABASEビュー, 17

ファスト・スタート・フェイルオーバーの監視, 9.5

SWITCHOVER_STATUS列, A.4.1

V$DATABASE_INCARNATIONビュー, 17 V$DATAFILEビュー, 13.4.2, 13.4.3, 17 V$DATAGUARD_CONFIGビュー, 17

LOG_ARCHIVE_CONFIGで定義済のデータベース名のリスト表示, 17

V$DATAGUARD_STATSビュー, 8.1.2, 17 V$DATAGUARD_STATUSビュー, 9.5.1.5, 17 V$FS_FAILOVER_STATSビュー, 17 V$LOGビュー, 17 V$LOG_HISTORYビュー, 9.5.1.4, 17 V$LOGFILEビュー, 17 V$LOGSTDBY_PROCESSビュー, 10.1, 10.3.4, 10.3.4, 10.4.1, 10.7.3.1, 10.7.3.2, 17 V$LOGSTDBY_PROGRESSビュー, 10.3.5, 17

RESTART_SCN列, 10.1.1.3

V$LOGSTDBY_STATEビュー, 8.1.2, 10.3.6, 10.4.1, 17 V$LOGSTDBY_STATSビュー, 10.1, 10.3.7, 17

フェイルオーバー特性, 10.3.3

V$LOGSTDBY_TRANSACTIONビュー, 17 V$MANAGED_STANDBYビュー, 9.5.1.2, 9.5.1.2, 17 V$REDO_DEST_RESP_HISTOGRAM

同期REDO転送のレスポンス時間の監視に使用, 6.4.2

V$REDO_DEST_RESP_HISTOGRAMビュー, 17 V$SESSIONビュー, A.4.2 V$STANDBY_EVENT_HISTOGRAMビュー, 17 V$STANDBY_LOGビュー, 17 V$THREADビュー, 9.5 VALID_FOR属性, 15 確認

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

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

バージョン

Oracle Databaseソフトウェアのアップグレード, 12.1

ビュー

DBA_LOGSTDBY_EVENTS, 10.3.1, 17, A.6

DBA_LOGSTDBY_HISTORY, 17

DBA_LOGSTDBY_LOG, 10.3.2, 17

DBA_LOGSTDBY_NOT_UNIQUE, 17

DBA_LOGSTDBY_PARAMETERSY, 17

DBA_LOGSTDBY_SKIP, 17

DBA_LOGSTDBY_SKIP_TRANSACTION, 17

DBA_LOGSTDBY_UNSUPPORTED, 17

GV$INSTANCE, D.3.1

V$ARCHIVE_DEST, 17, A.1.2

V$ARCHIVE_DEST_STATUS, 17

V$ARCHIVED_GAP, 17

V$ARCHIVED_LOG, 9.5.1.3, 17

V$DATABASE, 17

V$DATABASE_INCARNATION, 17

V$DATAFILE, 13.4.2, 13.4.3, 17

V$DATAGUARD_CONFIG, 17

V$DATAGUARD_STATS, 17

V$DATAGUARD_STATUS, 9.5.1.5, 17

V$FS_FAILOVER_STATS, 17

V$LOG, 17

V$LOG_HISTORY, 9.5.1.4, 17

V$LOGFILE, 17

V$LOGSTDBY_PROCESS, 10.1, 10.3.4, 17

V$LOGSTDBY_PROGRESS, 10.3.5, 17

V$LOGSTDBY_STATE, 10.3.6, 17

V$LOGSTDBY_STATS, 10.1, 10.3.7, 17

V$LOGSTDBY_TRANSACTION, 17

V$MANAGED_STANDBY, 9.5.1.2, 9.5.1.2, 17

V$REDO_DEST_RESP_HISTOGRAM, 17

V$SESSION, A.4.2

V$STANDBY_EVENT_HISTOGRAM, 17

V$STANDBY_LOG, 17

V$THREAD, 9.5

W

待機イベント

REDO転送サービス, 6.4.4

WAITING FOR DICTIONARY LOGS状態, 10.4.1 ギャップ待機中状態, 10.4.1

Z

停止時間ゼロのインスタンス化

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

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

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の登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。