Oracle Database高可用性ベスト・プラクティス, 10g」 …otndnld.oracle.co.jp/document/products/oracle10g/102/… · · 2009-07-02Nowak, Viv Schupmann, Michael Todd

Oracle® Database高可用性ベスト・プラクティス

10g リリース 2（10.2）

部品番号部品番号部品番号部品番号 : B31489-01

2006 年 10 月

Oracle Database 高可用性ベスト・プラクティス , 10g リリース 2（10.2）

部品番号 : B31489-01

原本名 : Oracle Database High Availability Best Practices, 10g Release 2 (10.2)

原本部品番号 : B25159-01

原本協力者 : Andrew Babb, Tammy Bednar, Immanuel Chan, Timothy Chien, Craig B. Foch, Michael Nowak, Viv Schupmann, Michael Todd Smith, Vinay Srihari, Lawrence To, Randy Urbano, Douglas Utzig, James Viscusi, Larry Carpenter, Joseph Meeks, Ashish Ray (coauthors of MAA white papers), Valarie Moore (graphic artist)

Copyright © 2006 Oracle. All rights reserved.

制限付権利の説明

このプログラム（ソフトウェアおよびドキュメントを含む）には、オラクル社およびその関連会社に所有権のある情報が含まれています。このプログラムの使用または開示は、オラクル社およびその関連会社との契約に記された制約条件に従うものとします。著作権、特許権およびその他の知的財産権と工業所有権に関する法律により保護されています。

独立して作成された他のソフトウェアとの互換性を得るために必要な場合、もしくは法律によって規定される場合を除き、このプログラムのリバース・エンジニアリング、逆アセンブル、逆コンパイル等は禁止されています。

このドキュメントの情報は、予告なしに変更される場合があります。オラクル社およびその関連会社は、このドキュメントに誤りが無いことの保証は致し兼ねます。これらのプログラムのライセンス契約で許諾されている場合を除き、プログラムを形式、手段（電子的または機械的）、目的に関係なく、複製または転用することはできません。

このプログラムが米国政府機関、もしくは米国政府機関に代わってこのプログラムをライセンスまたは使用する者に提供される場合は、次の注意が適用されます。

U.S. GOVERNMENT RIGHTS

Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

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

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

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

目次目次目次目次

はじめにはじめにはじめにはじめに ........................................................................................................................................................................... ix

対象読者 ...................................................................................................................................................................... xドキュメントのアクセシビリティについて .......................................................................................................... x関連ドキュメント ...................................................................................................................................................... x表記規則 ..................................................................................................................................................................... xiサポートおよびサービス ......................................................................................................................................... xi

1 高可用性ベスト・プラクティスの概要高可用性ベスト・プラクティスの概要高可用性ベスト・プラクティスの概要高可用性ベスト・プラクティスの概要 1.1 Oracle データベースの高可用性アーキテクチャ .............................................................................. 1-21.2 Oracle データベースの高可用性ベスト・プラクティス .................................................................. 1-21.3 Oracle Maximum Availability Architecture ....................................................................................... 1-3

1.4 運用ベスト・プラクティス ................................................................................................................... 1-3

2 高可用性の構成高可用性の構成高可用性の構成高可用性の構成

2.1 ストレージの構成 ................................................................................................................................... 2-2

2.1.1 データベース・パフォーマンス要件とストレージ・パフォーマンス性能の評価 ............... 2-2

2.1.2 自動ストレージ管理（ASM）を使用したデータベース・ファイルの管理 .......................... 2-3

2.1.3 ディスクおよびディスク・グループの簡易構成の使用 ........................................................... 2-3

2.1.4 ディスクのマルチパス・ソフトウェアを使用したパス障害からの保護 ............................... 2-6

2.1.5 冗長性を使用したディスク障害からの保護 ............................................................................... 2-6

2.1.6 HARD 準拠ストレージの検討 ..................................................................................................... 2-7

2.2 Oracle Database 10g の構成 .................................................................................................................. 2-8

2.2.1 高可用性の要件 ............................................................................................................................... 2-9

2.2.2 高可用性および高速リカバリのための推奨事項 ..................................................................... 2-10

2.2.3 管理性向上のための推奨事項 ..................................................................................................... 2-14

2.3 RAC を使用した Oracle Database 10g の構成 ................................................................................. 2-172.3.1 サービスおよび仮想インターネット・プロトコル（VIP）・アドレスを使用した

データベースへの接続 ................................................................................................................. 2-18

2.3.2 Oracle クラスタウェアを使用したクラスタおよびアプリケーションの可用性の管理 .... 2-18

2.3.3 クライアント側およびサーバー側でのロード・バランシングの使用 ................................. 2-19

2.3.4 Oracle Cluster Registry（OCR）のミラー化と複数の投票ディスクの構成 ....................... 2-19

2.3.5 テープまたはオフサイトへの OCR の定期的なバックアップ .............................................. 2-20

2.3.6 CRS と RAC で同じインターコネクト・ネットワークを使用していることの確認 ......... 2-20

2.3.7 クラスタの大インスタンスに応じたすべてのデータベースの構成 ................................. 2-21

2.4 Data Guard を使用した Oracle Database 10g の構成 ..................................................................... 2-212.4.1 フィジカル・スタンバイまたはロジカル・スタンバイ ......................................................... 2-22

i

2.4.2 データ保護モード ........................................................................................................................ 2-25

2.4.3 スタンバイ・データベースの数 ................................................................................................ 2-26

2.4.4 Data Guard の一般構成のベスト・プラクティス .................................................................. 2-27

2.4.5 REDO 転送サービスのベスト・プラクティス ........................................................................ 2-31

2.4.6 ログ適用サービスのベスト・プラクティス ............................................................................ 2-35

2.4.7 ロール移行のベスト・プラクティス ........................................................................................ 2-39

2.4.8 クローンとしてのフィジカル・スタンバイ・データベースの管理 .................................... 2-44

2.4.9 データベース以外のデータを保護するための推奨事項 ........................................................ 2-45

2.4.10 Data Guard のパフォーマンスの評価 ...................................................................................... 2-46

2.5 バックアップとリカバリの構成 ........................................................................................................ 2-482.5.1 Oracle のデータベース機能および製品の使用 ....................................................................... 2-49

2.5.2 構成と管理 .................................................................................................................................... 2-50

2.5.3 ディスクへのバックアップ ........................................................................................................ 2-53

2.5.4 テープへのバックアップ ............................................................................................................ 2-56

2.5.5 バックアップとリカバリのメンテナンス ................................................................................ 2-56

2.6 高速アプリケーション・フェイルオーバーの構成 ........................................................................ 2-57

2.6.1 クライアントのフェイルオーバーの構成 ................................................................................ 2-58

2.6.2 RAC データベースでのクライアント・フェイルオーバー .................................................. 2-58

2.6.3 RAC プライマリ・データベースからスタンバイ・データベースへの

フェイルオーバー ........................................................................................................................ 2-58

3 Oracle Grid Control を使用した監視を使用した監視を使用した監視を使用した監視 3.1 高可用性の監視と検出の概要 ............................................................................................................... 3-23.2 Oracle Grid Control を使用したシステムの監視 ............................................................................... 3-23.2.1 各システムに対するデフォルト通知ルールの設定 ................................................................... 3-4

3.2.2 データベース・ターゲット・ビューを使用したシステム状態、可用性および

パフォーマンスの監視 ................................................................................................................... 3-8

3.2.3 イベント通知を使用したメトリック変更への応答 ................................................................... 3-9

3.2.4 イベントを使用した Data Guard システムの可用性の監視 ................................................. 3-10

3.3 Oracle Grid Control を使用した高可用性環境の管理 .................................................................... 3-103.3.1 Oracle Grid Control を使用したポリシー違反のチェック .................................................... 3-10

3.3.2 Oracle Grid Control を使用した Oracle パッチの管理とシステム・ベースラインの

維持 ................................................................................................................................................ 3-11

3.3.3 Oracle Grid Control を使用した Data Guard ターゲットの管理 ......................................... 3-11

4 停止の管理停止の管理停止の管理停止の管理

4.1 停止の概要 ............................................................................................................................................... 4-24.1.1 計画外の停止 ................................................................................................................................... 4-2

4.1.2 計画済の停止 ................................................................................................................................... 4-7

4.2 計画外の停止からのリカバリ ............................................................................................................ 4-114.2.1 完全サイト・フェイルオーバー ................................................................................................ 4-12

4.2.2 スタンバイ・データベースでのデータベース・フェイルオーバー .................................... 4-16

4.2.3 スタンバイ・データベースでのデータベース・スイッチオーバー .................................... 4-22

4.2.4 計画外の停止からの RAC リカバリ ......................................................................................... 4-26

4.2.5 アプリケーション・フェイルオーバー .................................................................................... 4-27

4.2.6 ディスクおよびストレージ障害後の ASM リカバリ ............................................................. 4-28

4.2.7 データ破損（データ障害）からのリカバリ ............................................................................ 4-36

ii

4.2.8 人為的エラーからのリカバリ ..................................................................................................... 4-39

4.3 フォルト・トレランスのリストア ..................................................................................................... 4-464.3.1 RAC クラスタの障害ノードまたは障害インスタンスのリストア ....................................... 4-47

4.3.2 フェイルオーバー後のスタンバイ・データベースのリストア ............................................. 4-53

4.3.3 障害後の ASM ディスク・グループのリストア ...................................................................... 4-55

4.3.4 セカンダリ・サイトでの計画済の停止後またはクラスタ全体の停止後の

フォルト・トレランスのリストア ............................................................................................. 4-56

4.3.5 スタンバイ・データベースのデータ障害後のフォルト・トレランスのリストア ............. 4-57

4.3.6 RESETLOGS による本番データベースのオープン後のフォルト・トレランスの

リストア ......................................................................................................................................... 4-58

4.3.7 二重障害後のフォルト・トレランスのリストア ..................................................................... 4-61

4.4 計画済の停止による停止時間の回避または短縮 ............................................................................. 4-614.4.1 ストレージ・メンテナンス ......................................................................................................... 4-62

4.4.2 RAC データベース・パッチ ....................................................................................................... 4-63

4.4.3 データベース・アップグレード ................................................................................................. 4-65

4.4.4 データベースのプラットフォームまたはロケーションの移行 ............................................. 4-67

4.4.5 データベースおよびアプリケーションのオンライン・アップグレード ............................. 4-71

4.4.6 データベース・オブジェクトの再編成 ..................................................................................... 4-73

4.4.7 システム・メンテナンス ............................................................................................................. 4-76

5 MAA 環境への移行環境への移行環境への移行環境への移行

5.1 MAA への移行の概要 ............................................................................................................................ 5-25.2 単一インスタンスから RAC への移行 ................................................................................................ 5-25.3 RAC プライマリへの Data Guard 構成の追加 .................................................................................. 5-3

A データベースデータベースデータベースデータベース SPFILE およびおよびおよびおよび Oracle Net 構成ファイルのサンプル構成ファイルのサンプル構成ファイルのサンプル構成ファイルのサンプル

A.1 SPFILE サンプル ..................................................................................................................................... A-2A.2 Oracle Net 構成ファイル ....................................................................................................................... A-7A.2.1 動的インスタンス登録を使用するすべてのホストに対応する SQLNET.ORA の例 ........... A-7

A.2.2 動的インスタンス登録を使用するすべてのホストに対応する LISTENER.ORA の例 ....... A-7

A.2.3 動的インスタンス登録を使用するすべてのホストに対応する TNSNAMES.ORA の例 .... A-8

用語集用語集用語集用語集

索引索引索引索引

iii

iv

図一覧図一覧図一覧図一覧

2-1 ディスク全体の割当て ........................................................................................................................... 2-42-2 各ディスクのパーティション化 ........................................................................................................... 2-52-3 ネットワーク・サーバー（LNSn）・プロセスによる LGWR ASYNC アーカイブ ................... 2-333-1 Oracle Grid Control のホームページ .................................................................................................. 3-33-2 可用性の通知ルールの設定 ................................................................................................................... 3-53-3 メトリックの通知ルールの設定 ........................................................................................................... 3-73-4 システム・パフォーマンスの概要 ....................................................................................................... 3-84-1 サイト・フェイルオーバー前のネットワーク・ルート ................................................................. 4-134-2 サイト・フェイルオーバー後のネットワーク・ルート ................................................................. 4-144-3 ORA-16625 エラーを示す Data Guard の「概要」ページ ............................................................. 4-184-4 フェイルオーバーの「確認」ページ ................................................................................................. 4-194-5 フェイルオーバーの進行状況のページ ............................................................................................. 4-204-6 フェイルオーバー完了後の Data Guard の「概要」ページ .......................................................... 4-204-7 スイッチオーバー操作の確認 ............................................................................................................. 4-234-8 スイッチオーバー時の「処理中」ページ ......................................................................................... 4-244-9 スイッチオーバー後の新規プライマリ・データベース ................................................................. 4-244-10 Enterprise Manager によるディスク障害のレポート .................................................................... 4-304-11 Enterprise Manager による ASM ディスク・グループ・ステータスのレポート ..................... 4-314-12 Enterprise Manager による保留中の REBAL 操作のレポート ..................................................... 4-314-13 パーティション化された 2 ノードの RAC データベース .............................................................. 4-504-14 パーティション化されたデータベースでの RAC インスタンスのフェイルオーバー .............. 4-514-15 パーティション化されていない RAC インスタンス ...................................................................... 4-524-16 有効化に成功したファスト・スタート・フェイルオーバーとオブザーバ ................................. 4-544-17 ファスト・スタート・フェイルオーバー後の以前のプライマリ・データベースの復元 ......... 4-554-18 Oracle Streams によるデータベースのオンライン・アップグレード ......................................... 4-724-19 Oracle Enterprise Manager を使用したデータベース・オブジェクトの再編成 ........................ 4-74

v

vi

表一覧表一覧表一覧表一覧

2-1 適切な保護モードの決定 ................................................................................................................... 2-252-2 アーカイブの推奨事項 ......................................................................................................................... 2-292-3 FastStartFailoverThreshold の小値の推奨設定 ............................................................................ 2-432-4 バックアップ・オプションの比較 ..................................................................................................... 2-532-5 クライアント・フェイルオーバーの一般的な待機時間 ................................................................. 2-573-1 領域を監視するための推奨事項 ........................................................................................................... 3-63-2 アラート・ログを監視するための推奨事項 ....................................................................................... 3-63-3 処理容量を監視するための推奨事項 ................................................................................................... 3-63-4 メトリックの推奨通知ルール ............................................................................................................... 3-93-5 Data Guard イベントを設定するための推奨事項 ........................................................................... 3-104-1 計画外の停止 ........................................................................................................................................... 4-24-2 プライマリ・サイトでの計画外の停止のリカバリ時間および手順 ............................................... 4-34-3 セカンダリ・サイトでの計画外の停止のリカバリ手順 ................................................................... 4-64-4 計画済の停止 ........................................................................................................................................... 4-74-5 プライマリ・サイトでの計画済の停止のリカバリ手順 ................................................................... 4-84-6 セカンダリ・サイトでの計画済の停止の管理 ................................................................................. 4-104-7 ASM 障害タイプと推奨される修復方法 ........................................................................................... 4-284-8 データ領域ディスク・グループ障害のリカバリ・オプション ................................................... 4-324-9 フラッシュ・リカバリ領域ディスク・グループ障害のリカバリ・オプション ......................... 4-344-10 データベース以外のオブジェクトの破損と推奨される修復方法 ............................................... 4-374-11 様々な障害のフラッシュバック・ソリューション ......................................................................... 4-404-12 フラッシュバック機能のまとめ ......................................................................................................... 4-404-13 ノードまたはインスタンスの再起動または再結合時の追加処理 ................................................. 4-474-14 リストアおよび接続フェイルバック ................................................................................................. 4-494-15 フィジカルおよびロジカル・スタンバイ・データベースを起動するための SQL 文 ............... 4-564-16 REDO Apply および SQL Apply を開始するための SQL 文 ........................................................ 4-564-17 RESETLOGS SCN と現在の SCN OPEN RESETLOGS を確認するための問合せ ..................... 4-584-18 スタンバイ・データベースの SCN が本番データベースのリセットログ SCN より

遅れている場合のアクション ............................................................................................................. 4-584-19 スタンバイ・データベースの SCN が本番データベースのリセットログ SCN より

進んでいる場合のアクション ............................................................................................................. 4-594-20 本番データベースとスタンバイ・データベースの再作成 ............................................................. 4-614-21 プラットフォーム移行およびデータベース・アップグレードのオプション ............................. 4-654-22 プラットフォームおよびロケーション移行のオプション ............................................................. 4-684-23 オブジェクトの再編成機能の一部 ..................................................................................................... 4-735-1 MAA 環境に移行する前の開始構成 .................................................................................................... 5-2A-1 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの

一般的な SPFILE パラメータ ................................................................................................................ A-2A-2 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの

RAC 用 SPFILE パラメータ .................................................................................................................. A-3A-3 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの

Data Guard 用 SPFILE パラメータ ...................................................................................................... A-3A-4 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの

Data Guard Broker 用 SPFILE パラメータ ......................................................................................... A-4A-5 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの

Data Guard 用 SPFILE パラメータ（Broker 不使用時） ................................................................... A-4A-6 プライマリおよびフィジカル・スタンバイ・データベースのみの構成の Data Guard 用

SPFILE パラメータ ................................................................................................................................. A-4A-7 プライマリおよびロジカル・スタンバイ・データベースのみの構成の Data Guard 用

SPFILE パラメータ ................................................................................................................................. A-5A-8 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの

Data Guard 用 SPFILE パラメータ : 大可用性モードまたは大保護モード ........................... A-5A-9 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの

Data Guard 用 SPFILE パラメータ : 大パフォーマンス・モード ............................................... A-6

vii

viii

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

このマニュアルでは、高可用性対応の Oracle データベース・システムとネットワーク・コンポーネントを構成および管理するためのベスト・プラクティスについて説明します。

ix

対象読者対象読者対象読者対象読者このマニュアルは、次の作業を実行する高技術責任者（CTO）、情報技術アーキテクト、データベース管理者、システム管理者、ネットワーク管理者およびアプリケーション管理者を対象としています。

� データ・センターの計画

� データ・センター・ポリシーの実施

� 高可用性システムの管理

� 高可用性ソリューションの計画と構築

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

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

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

外部外部外部外部 Web サイトのドキュメントのアクセシビリティについてサイトのドキュメントのアクセシビリティについてサイトのドキュメントのアクセシビリティについてサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しない Web サイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらの Web サイトのアクセシビリティに関しての評価や言及は行っておりません。

Oracle サポート・サービスへのサポート・サービスへのサポート・サービスへのサポート・サービスへの TTY アクセスアクセスアクセスアクセス

アメリカ国内では、Oracle サポート・サービスへ 24 時間年中無休でテキスト電話（TTY）アクセスが提供されています。TTY サポートについては、 (800)446-2398 にお電話ください。

関連ドキュメント関連ドキュメント関連ドキュメント関連ドキュメント詳細は、Oracle データベースのドキュメント・セットを参照してください。特に、次のマニュアルが役立ちます。

� 『Oracle Database 高可用性概要』

� 『Oracle Data Guard 概要および管理』および『Oracle Data Guard Broker』

� Oracle Database Oracle Clusterware および Oracle Real Application Clusters のインストレーション・ガイド（プラットフォーム別）

� 『Oracle Database Oracle Clusterware および Oracle Real Application Clusters 管理およびデプロイメント・ガイド』

� 『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

� 『Oracle Database 管理者ガイド』

Oracle 高可用性ベスト・プラクティスに関するホワイト・ペーパーは、http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmからダウンロードできます。

x

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

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

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

http://www.oracle.co.jp/support/

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

http://otn.oracle.co.jp/document/

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

http://www.oracle.co.jp/education/

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

http://www.oracle.co.jp http://otn.oracle.co.jp

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

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

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

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

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

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

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

xi

xii

高可用性ベスト・プラクティスの概要

1
高可用性ベスト・プラクティスの概要高可用性ベスト・プラクティスの概要高可用性ベスト・プラクティスの概要高可用性ベスト・プラクティスの概要
この章では、Oracle 高可用性ベスト・プラクティスを使用して、Oracle データベースとテクノロジ・スタック全体の可用性を向上する方法について説明します。この章には、次の各項が含まれます。

� Oracle データベースの高可用性アーキテクチャ

� Oracle データベースの高可用性ベスト・プラクティス

� Oracle Maximum Availability Architecture

� 運用ベスト・プラクティス

1-1

Oracle データベースの高可用性アーキテクチャ

1.1 Oracle データベースの高可用性アーキテクチャデータベースの高可用性アーキテクチャデータベースの高可用性アーキテクチャデータベースの高可用性アーキテクチャビジネスの可用性要件に適なアーキテクチャを選択して実装するのは、困難な作業です。このアーキテクチャでは、適切な冗長性を保持し、あらゆるタイプの停止に対して十分な保護を提供しながら、高パフォーマンスと堅牢なセキュリティを維持する必要があります。その一方で、このアーキテクチャは、配置、管理およびスケール変更が容易である必要があります。言うまでもなく、このアーキテクチャは、既知のビジネス要件に応じて決定されます。高可用性アーキテクチャの選択および実装の詳細は、『Oracle Database 高可用性概要』を参照してください。

このマニュアルに記載されているベスト・プラクティスを使用する前に、『Oracle Database 高可用性概要』に説明されているとおりに現在の組織でデータベースの高可用性アーキテクチャを選択している必要があります。まだこの選択作業を行っていない場合、前述のマニュアルを参照して Oracle データベースの高可用性ソリューションについて理解してから、このマニュアルの内容に進んでください。

1.2 Oracle データベースの高可用性ベスト・プラクティスデータベースの高可用性ベスト・プラクティスデータベースの高可用性ベスト・プラクティスデータベースの高可用性ベスト・プラクティス高可用性アーキテクチャを構築、実装および管理する場合、IT システムおよびビジネス・プロセスの技術面と運用面を対象とする高可用性ベスト・プラクティスが必要です。このようなベスト・プラクティスのセットにより、高可用性アーキテクチャの設計の簡略化、小限のシステム・リソースを使用した可用性の大化、適切な高可用性システムの実装コストとメンテナンス・コストの削減、および他のビジネス領域における高可用性アーキテクチャの複製の容易化が可能になります。エンタープライズでは、高可用性分析フレームワーク、ビジネス・ドライバおよびシステム機能を含む有機的に統合された高可用性ベスト・プラクティスのセットを保持することで、弾力性に優れた運用と高度なビジネス・アジリティを実現できます。

このマニュアルの目的は、高可用性ベスト・プラクティスを使用して Oracle データベースの高可用性アーキテクチャを構築、実装および管理することです。このマニュアルに記載されている Oracle データベースの高可用性ベスト・プラクティスを使用することで、次のことが可能になります。

� データベース、ストレージ、アプリケーション・フェイルオーバー、バックアップおよびリカバリを構成するための詳細なガイドラインに従うことで、Oracle データベースの高可用性システムの実装コストを削減できます。詳細は、第 2 章「高可用性の構成」を参照してください。

� Oracle Grid Control を使用してデータベースを監視および管理することで、システム停止の可能性を排除できます。詳細は、第 3 章「Oracle Grid Control を使用した監視」を参照してください。

� コンピュータ障害、ストレージ障害、人為的エラーまたはデータ破損を原因とする計画外の停止から迅速にリカバリできます。詳細は、第 4 章「停止の管理」を参照してください。

� データベースへのパッチ適用やアプリケーション・アップグレードなどの計画済のメンテナンスにより発生する停止時間を回避または削減できます。詳細は、第 4 章「停止の管理」を参照してください。

1-2　Oracle Database 高可用性ベスト・プラクティス

運用ベスト・プラクティス

1.3 Oracle Maximum Availability ArchitectureOracle Maximum Availability Architecture（MAA）は、Oracle における実証済の高可用性テクノロジおよび推奨事項に基づくベスト・プラクティスのブループリントです。このマニュアルに記載されている高可用性ベスト・プラクティスは、MAA の複数の構成要素の 1 つに相当します。 MAA には、テクノロジ・スタック全体にわたるすべての Oracle 製品（Oracle Database、Oracle Application Server、Oracle Applications、Oracle Collaboration Suite および Oracle Grid Control）の高可用性ベスト・プラクティスが含まれます。

MAA の主要機能は、次のとおりです。

� 様々なビジネスの品質保証契約（SLA）を考慮しながら高可用性ベスト・プラクティスを可能なかぎり広範囲に適用できます。

� データベース・グリッド・サーバーと、低コスト・ストレージに基づくストレージ・グリッドを活用して、高度な弾力性を備えた低コスト・インフラストラクチャを実現します。

� ビジネス・ニーズに合せて実行およびスケール変更できるよう適に構成された高可用性アーキテクチャを確保する目的で、各種構成を対象とする広範なパフォーマンス影響調査の結果を利用できます。

� 停止状態からのリカバリ時間の長さと、自然災害時に許容可能なデータ損失の量を制御できます。

� 各 Oracle リリースに伴って内容が拡張され、ハードウェアとオペレーティング・システムからは完全に独立しています。

MAA の詳細と、MAA のすべての構成要素のベスト・プラクティスに関するドキュメントは、次の場所にある MAA の Web サイトを参照してください。

http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm

1.4 運用ベスト・プラクティス運用ベスト・プラクティス運用ベスト・プラクティス運用ベスト・プラクティス停止時間を短縮する善の方法の 1 つは、運用ベスト・プラクティスを取り入れることです。テスト環境での詳細な変更テストの実行、プライマリ・データベースを障害から保護するための厳密な変更制御ポリシーへの準拠、および十分に検証された修復計画の各停止タイプへの適用を通じて、問題や停止時間の発生を高い頻度で防ぐことができます。

Grid Control などの監視インフラストラクチャは、迅速な問題検出に不可欠です。停止および修復用のディシジョン・ツリーと自動修復機能を確保することで、意思決定や修復のための時間を回避または削減して停止時間を短縮できます。

次に、主要な運用プラクティスのリストを示します。

� 品質保証契約（SLA）を文書化して通達します。

� テスト環境を構築します。

適切なテスト環境は本番システムを正確に反映するため、変更をテストすることで問題がビジネスに影響を与える前に防ぐことができます。

� 変更制御およびセキュリティ手順を確立します。

変更制御およびセキュリティ手順によって、システムの安定性が維持され、テスト・システムで厳密に評価されるまで変更がプライマリ・データベースに適用されないことが保証されます。

� セキュリティ・ベスト・プラクティスを設定して準拠します。

企業データに対する大の脅威は、ネットワークや企業設備に内部アクセスできる従業員と契約社員によってもたらされます。適切なセキュリティ基準のないシステムまたはデータベースに配置された企業データは、深刻なリスクに直面している可能性があります。明確に定義されたセキュリティ・ポリシーは、システムに対する不正アクセスを遮断し、企業の機密情報を破壊行為から保護するのに役立ちます。適切なデータ保護により、セキュリティの侵害によるシステム停止の可能性を抑制できます。

高可用性ベスト・プラクティスの概要 1-3

運用ベスト・プラクティス

� Grid Control などの監視インフラストラクチャを活用して、潜在的な障害や問題を発生前に検出して対応します。

– システム、ネットワークおよびデータベース統計を監視します。

– パフォーマンス統計を監視します。

– システムやアプリケーションの障害またはパフォーマンス低下を示す早期警告インジケータとしてパフォーマンスしきい値を作成します。

� MAA 推奨の修復計画を活用し、適切な MAA マトリックスを使用して深刻な状況に対応するための停止および修復用ディシジョン・ツリーを作成します。

� MAA ベスト・プラクティスに準拠して修復プラクティスを自動化および適化し、停止時間を小化します。

関連資料関連資料関連資料関連資料 :

� データベース・セキュリティの概要は、『Oracle Database 概要』を参照してください。

� セキュリティ・チェックリストと推奨事項の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

関連項目関連項目関連項目関連項目 : 修復計画および修復プラクティスの詳細は、第 4 章「停止の管理」を参照してください。


高可用性の構

2
高可用性の構成高可用性の構成高可用性の構成高可用性の構成
この章では、Oracle データベースと関連コンポーネントのための Oracle 構成ベスト・プラクティスについて説明します。

この章には、次の各項が含まれます。

� ストレージの構成

� Oracle Database 10g の構成

� RAC を使用した Oracle Database 10g の構成

� Data Guard を使用した Oracle Database 10g の構成

� バックアップとリカバリの構成

� 高速アプリケーション・フェイルオーバーの構成

関連項目関連項目関連項目関連項目 : データベース・パラメータ設定の詳細な例は、付録 A「データベース SPFILE および Oracle Net 構成ファイルのサンプル」を参照してください。

成 2-1

ストレージの構成

2.1 ストレージの構成ストレージの構成ストレージの構成ストレージの構成この項では、管理性とパフォーマンスを維持しながらデータを保護するフォルト・トレラントなストレージ・サブシステムを構成するためのベスト・プラクティスについて説明します。これらのプラクティスは、『Oracle Database 高可用性概要』に記載されている Oracle データベースのすべての高可用性アーキテクチャに適用されます。

この項には、次の各項目が含まれます。

� データベース・パフォーマンス要件とストレージ・パフォーマンス性能の評価

� 自動ストレージ管理（ASM）を使用したデータベース・ファイルの管理

� ディスクおよびディスク・グループの簡易構成の使用

� ディスクのマルチパス・ソフトウェアを使用したパス障害からの保護

� 冗長性を使用したディスク障害からの保護

� HARD 準拠ストレージの検討

2.1.1 データベース・パフォーマンス要件とストレージ・パフォーマンス性能データベース・パフォーマンス要件とストレージ・パフォーマンス性能データベース・パフォーマンス要件とストレージ・パフォーマンス性能データベース・パフォーマンス要件とストレージ・パフォーマンス性能の評価の評価の評価の評価

様々なアプリケーション・ワークロードを使用して、現在のデータベースのパフォーマンス要件を分類します。ターゲット・ワークロードの処理中に統計を抽出するため、開始時と終了時の統計スナップショットを取得します。ターゲット・ワークロードの例は、次のとおりです。

� 平均負荷

� ピーク負荷

� バッチ処理

必要な統計は、自動ワークロード・リポジトリ（AWR）・レポートから導出するか、GV$SYSSTATビューから収集することが可能です。データベースのパフォーマンス要件を理解すると同時に、ストレージ・アレイのパフォーマンス性能を評価する必要があります。

低コストのストレージ・アレイ、低コストのストレージ・ネットワーク、および Oracle Database 10g を組み合せて使用すると、パフォーマンスと可用性に優れた低コストのストレージ・グリッドを作成できます。低コストのストレージは、特定のタイプのパフォーマンス要件と可用性要件を保持するデータベース用として配置するのに適です。低コストのストレージ・アレイは、従来のハイエンドなストレージ・アレイと比較して、データ・スループットに優れており、GB 当たりの価格を抑えることができます。ただし、OLTP タイプのアプリケーションの場合、低コストのストレージ・アレイの I/O レートは、従来のストレージに及びません

（1 秒当たりの I/O ごとのコストはほぼ同じです）。 Oracle Resilient Low-Cost Storage Initiativeは、各部門と企業全体の両環境で、顧客による IT 費用の削減と、低コストのストレージ・アレイの使用を促進する目的で設計されています。

Oracle データベースのフラッシュ・リカバリ領域は、低コストのストレージを使用するのに適です。フラッシュ・リカバリ領域には、一般的に 1MB の順次ストリームを使用してアクセスされるリカバリ関連ファイルが含まれるため、低コストのストレージのパフォーマンス特性に適しています。フラッシュ・リカバリ領域では低コストのストレージを使用し、データベース領域では引き続き従来のストレージを使用するよう構成できます。


� 『Best Practices for Creating a Low-Cost Storage Grid for Oracle Databases』（http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm）

� Oracle Resilient Low-Cost Storage Initiative の Web サイト（http://www.oracle.com/technology/deploy/availability/htdocs/lowcoststorage.html）



2.1.2 自動ストレージ管理（自動ストレージ管理（自動ストレージ管理（自動ストレージ管理（ASM）を使用したデータベース・ファイルの管理）を使用したデータベース・ファイルの管理）を使用したデータベース・ファイルの管理）を使用したデータベース・ファイルの管理ASM は、特に Oracle データベース・ファイル用に構築されたファイル・システムとボリューム・マネージャの両方を垂直統合したものです。 ASM により、パフォーマンスの適化のためにすべてのディスクをストライプ化してミラー化する（SAME）という概念が拡張される一方で、手動による I/O チューニングを行う必要がなくなります（データファイルのレイアウトはホット・スポットを避けるように分散されます）。 ASM では、ストレージ割当てを調整するためにデータベースを停止することなくデータベース・サイズを拡張することで、動的にデータベース環境を管理できます。また、ASM によるミラー化とストライプ化のサポートにより、低コストのモジュール型ストレージで優れたパフォーマンスと高度な可用性を実現できます。

ASM は、すべてのデータベース・ファイルを管理するために使用します。ただし、初はフラッシュ・リカバリ領域のみをサポートして現在の環境に ASM を段階的に導入できます。この方法は、従来のストレージ構成が現在も残っている既存の環境に低コストのストレージを導入する場合に特に効果的です。

管理性を向上するため、プラットフォーム上で使用可能な場合には ASMLib を使用する必要があります。 ASMLib は、ASM のサポート・ライブラリです。 ASMLib により、システムの再起動時にディスク・デバイス名のマッピングが変化する場合にその影響を回避できます。 ASM の実行に ASMLib は必要ありませんが、ASMLib を使用することでディスク・デバイス名の管理が容易になり、検出プロセスが簡単になると同時に、あるノードに追加されたディスクがクラスタ内の他のノードに認識されないといった問題を回避できます。

2.1.3 ディスクおよびディスク・グループの簡易構成の使用ディスクおよびディスク・グループの簡易構成の使用ディスクおよびディスク・グループの簡易構成の使用ディスクおよびディスク・グループの簡易構成の使用データベース記憶域に ASM を使用する場合、2 つのディスク・グループ（データベース領域用のディスク・グループとフラッシュ・リカバリ領域用のディスク・グループ）を作成する必要があります。

� データベース領域には、データファイル、制御ファイル、オンライン REDO ログ・ファイル、Data Guard Broker メタデータ・ファイル、RMAN の増分バックアップに使用される変更トラッキング・ファイルなどのアクティブなデータベース・ファイルが含まれます。たとえば、次のようになります。

CREATE DISKGROUP DATA DISK '/devices/lun01','/devices/lun02','/devices/lun03','/devices/lun04';

� フラッシュ・リカバリ領域には、現在の制御ファイルのコピー、各オンライン REDO ログ・ファイル・グループのメンバー、アーカイブ REDO ログ・ファイル、RMAN のバックアップ・セット、フラッシュバック・ログ・ファイルなどのリカバリ関連ファイルが含まれます。たとえば、次のようになります。

CREATE DISKGROUP RECO DISK '/devices/lun05','/devices/lun06','/devices/lun07','/devices/lun08','/devices/lun09','/devices/lun10','/devices/lun11','/devices/lun12';


� 『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』の第 16 章「Recovery Manager を使用した ASM 環境とデータベース間の移行」

� 『Oracle Database 10g Release 2 Automatic Storage Management Overview and Technical Best Practices』

（http://www.oracle.com/technology/products/database/asm/pdf/asm_10gr2_bptwp_sept05.pdf）

� Oracle ASMLib の Web サイト（http://www.oracle.com/technology/tech/linux/asmlib/index.html）

� 自動ストレージ管理の構成方法の詳細は、『Oracle Database 管理者ガイド』を参照してください。

高可用性の構成 2-3


ファイル管理を簡略化するには、Oracle Managed Files を使用してファイルの命名作業を制御します。 Oracle Managed Files を有効化するには、初期化パラメータのDB_CREATE_FILE_DEST、DB_RECOVERY_FILE_DESTおよびDB_RECOVERY_FILE_DEST_SIZEを次のように設定します。

DB_CREATE_FILE_DEST=+DATADB_RECOVERY_FILE_DEST=+RECODB_RECOVERY_FILE_DEST_SIZE=500G

ASM で使用するためにディスクをパーティション化する場合、次の 2 つのオプションがあります。

� 複数のディスク全体をデータベース領域のディスク・グループとフラッシュ・リカバリ領域のディスク・グループに割り当てます。

� 各ディスクを 2 つのパーティションに分割し、1 つをデータベース領域に、もう 1 つをフラッシュ・リカバリ領域に割り当てます。

図図図図 2-1 ディスク全体の割当てディスク全体の割当てディスク全体の割当てディスク全体の割当て

図 2-1 は、ディスク全体を割り当てる方法を示しています。このオプションのメリットは、次のとおりです。

� 各ディスクを 1 つの大きなパーティションとして分割しているため、オペレーティング・システム・レベルでディスク・パーティションを管理することが容易です。

� ディスク障害後の ASM によるリバランス操作は、1 つのディスク・グループのみをリバランスすればよいため、迅速に完了します。

このオプションのデメリットは、次のとおりです。

� 各ディスク・グループが使用可能なディスクのサブセットに単純に分散されるため、I/O帯域幅が小さくなります。

注意注意注意注意 : DB_RECOVERY_FILE_DESTを設定してフラッシュ・リカバリ領域を使用する場合、DB_RECOVERY_FILE_DEST_SIZEも設定してフラッシュ・リカバリ領域に使用するディスク領域の容量を制限する必要があります。 DB_RECOVERY_FILE_DESTと DB_RECOVERY_FILE_DEST_SIZEは、フラッシュ・リカバリ領域の場所とサイズを変更できる動的パラメータです。



図図図図 2-2 各ディスクのパーティション化各ディスクのパーティション化各ディスクのパーティション化各ディスクのパーティション化

図 2-2 は、2 番目のオプションを示しています。この場合、各ディスクを 2 つのパーティションに分割する必要があります。各ドライブの高速な外側部分にある小さいパーティションをデータベース領域用とし、各ドライブの低速な内側部分にある大きいパーティションをフラッシュ・リカバリ領域用とします。内側のパーティション・サイズと外側のパーティション・サイズの割合は、データベース領域とフラッシュ・リカバリ領域の推定サイズに応じて変化します。

このオプションのメリットは、次のとおりです。

� 使用可能なすべてのスピンドルに両方のディスク・グループが分散されるため、使用できる I/O 帯域幅が大きくなります。このメリットは、I/O 集中型のアプリケーションで使用されるデータベース領域用のディスク・グループでは重要です。

このオプションのデメリットは、次のとおりです。

� 二重ディスク障害が発生すると、両方のディスク・グループが失われる可能性があります。この場合、リカバリのためにスタンバイ・データベースまたはテープ・バックアップを使用する必要があります。

� ディスク障害後の ASM によるリバランス操作は、両方のディスク・グループが対象となるため、時間がかかります。

� 各ディスクを適切にパーティション化するために、より多くの初期管理作業を必要とします。


� フラッシュ・リカバリ領域の設定とサイズ指定の詳細は、『Oracle Database バックアップおよびリカバリ基礎』を参照してください。

� 自動ストレージ管理の詳細は、『Oracle Database 管理者ガイド』を参照してください。



2.1.4 ディスクのマルチパス・ソフトウェアを使用したパス障害からの保護ディスクのマルチパス・ソフトウェアを使用したパス障害からの保護ディスクのマルチパス・ソフトウェアを使用したパス障害からの保護ディスクのマルチパス・ソフトウェアを使用したパス障害からの保護ディスクのマルチパス・ソフトウェアでは、複数の独立した I/O パスを単一の論理パスに集約します。パスの抽象化により、ホスト・バス・アダプタ（HBA）全体にわたる I/O のロード・バランシングが実現し、I/O パスの障害時には無停止のままフェイルオーバーが実行されます。ディスクのマルチパス・ソフトウェアは、ASM と組み合せて使用する必要があります。

ASM でのディスク・グループ作成時にディスク名を指定するときに、単一の論理パスを表す論理デバイスを使用します。たとえば、Linux 2.6 でデバイス・マッパーを使用する場合、/dev/dm-0の論理デバイス・パスで物理ディスク /dev/sdcおよび /dev/sdhを集約できます。 ASM 内では、論理デバイス /dev/dm-0を検出するために asm_diskstringパラメータに /dev/dm-*を含め、ディスク・グループ作成時にその論理デバイスを使用する必要があります。

asm_diskstring='/dev/dm-*'

CREATE DISKGROUP DATA DISK'/dev/dm-0','/dev/dm-1','/dev/dm-2','/dev/dm-3';

2.1.5 冗長性を使用したディスク障害からの保護冗長性を使用したディスク障害からの保護冗長性を使用したディスク障害からの保護冗長性を使用したディスク障害からの保護冗長性を設定してハードウェア障害から保護する場合、検討する必要のあるオプションは次の2 つです。

� RAID に基づくストレージ・アレイ

� ASM による冗長性

ストレージ・アレイでは、RAID1（ミラー化）や RAID5（ストライプ化とパリティ）などのRAID 保護を有効化して冗長性を構成することをお薦めします。たとえば、ストレージ・アレイにより冗長性が提供される ASM ディスク・グループを作成するには、まずストレージ・アレイに RAID で保護された論理ユニット番号論理ユニット番号論理ユニット番号論理ユニット番号を作成してから、EXTERNAL REDUNDANCY句を使用して次のように ASM ディスク・グループを作成します。

CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK '/devices/lun1','/devices/lun2','/devices/lun3','/devices/lun4';

ストレージ・アレイで希望するレベルの冗長性を使用できない場合、または複数のストレージ・アレイ全体で冗長性を構成する必要がある場合、ASM による冗長性を使用します。 ASMでは、障害グループを使用した冗長性が提供されます（障害グループはディスク・グループ作成時に定義します）。 ASM による冗長性では、ファイルを二重にミラー化する標準冗長性か、またはファイルを三重にミラー化する高冗長性を指定できます。ディスク・グループが一度作成されると、冗長性レベルは変更できません。

障害グループの定義は、各ストレージ設定に固有ですが、次のガイドラインに従う必要があります。

� ディスクのマルチパス・ソフトウェアを使用している場合のように、すべての I/O パスを通じてすべてのディスクを使用できる場合、各ディスクはそれぞれ独自の障害グループに残します。これは、障害グループを明示的に定義せずにディスク・グループを作成する場合の ASM のデフォルト動作です。

CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK '/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4', '/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4';

� すべての I/O パスを通じてすべてのディスクを使用できない場合、障害が懸念されるハードウェアの構成部分から保護するために障害グループを定義します。次の 3 つの使用例があります。

– 2 つのコントローラでそれぞれドライブ全体の半分のみを認識しているアレイの場合、コントローラ障害から保護するため、各コントローラに対応する 2 つの障害グループを持つディスク・グループを作成します。

CREATE DISKGROUP DATA NORMAL REDUNDANCY FAILGROUP controller1 DISK '/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4'



FAILGROUP controller2 DISK '/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4';

– 2 つのコントローラの両方ですべてのディスクを認識しているアレイの場合、各ディスクがそれぞれ独自の障害グループに含まれるディスク・グループを作成します。

CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK '/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4', '/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4';

– 複数のストレージ・アレイを備えたストレージ・ネットワークでストレージ・アレイ全体にわたりミラー化を行う場合、アレイ障害から保護するため、各アレイに対応する 2 つの障害グループを持つディスク・グループを作成します。

CREATE DISKGROUP DATA NORMAL REDUNDANCY FAILGROUP array1 DISK '/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4' FAILGROUP array2 DISK '/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4';

ASM による冗長性で保護されるディスク・グループの適切なサイズを決定する場合、ディスク・グループには十分な空き領域が存在する必要があります。これは、ディスク障害が発生した場合に、データベースをオンラインに維持したまま、障害ドライブの内容をディスク・グループ内の別のドライブに自動的に再構築できるようにするためです。ディスク障害後に ASMで冗長性を回復するのに必要な領域の容量は、V$ASM_DISKGROUPビューのREQUIRED_MIRROR_FREE_MB列で確認できます。ミラー化を考慮しながらディスク・グループで安全に使用できるとともに、ディスク障害後に冗長性を回復できる空き領域の容量は、V$ASM_DISKGROUPビューの USABLE_FILE_MB列で確認できます。 USABLE_FILE_MBは、常に 0（ゼロ）を超えている必要があります。 USABLE_FILE_MBが 0（ゼロ）未満の場合、ディスク・グループに別のディスクを追加する必要があります。

2.1.6 HARD 準拠ストレージの検討準拠ストレージの検討準拠ストレージの検討準拠ストレージの検討データ破損に対する高度の保護が提供される HARD 準拠ストレージの導入を検討してください。データ破損が発生することは非常にまれですが、発生した場合にはビジネスに壊滅的な影響を及ぼす可能性があります。

Hardware Assisted Resilient Data（HARD）イニシアチブの目的は、コンピュータ業界がこれまで防ぐことのできなかったクラスの障害を排除することです。 RAID は、データの物理的な保護を保証することでストレージ業界の広範な支持を得てきました。 HARD は、物理データの保護を超える形でビジネス・データを保護することにより、次世代レベルのデータ保護を提供します。

HARD イニシアチブは、発生前にデータ破損を防ぐよう設計されています。オラクル社では、HARD イニシアチブに基づいてストレージ・ベンダーと協力し、ストレージ・デバイス内部にOracle データを検証およびチェックするアルゴリズムを実装しています。これにより、破損データが永続ストレージに書き込まれることを防止できます。

HARD で対処できるデータ破損のクラスは、次のとおりです。

� Oracle ブロックを物理的および論理的に破損する書込み

� 間違った場所へのデータベース・ブロックの書込み

� 部分的または不完全なブロックの書込み

� 他のアプリケーションによる Oracle データ・ブロックへの書込み

エンドツーエンドのブロック検証は、Oracle データベースのデータ・ブロックの内容を検証するためにオペレーティング・システムまたはストレージ・サブシステムによって使用されるテクノロジです。ストレージ・デバイスに含まれる Oracle データベースのデータを検証することで、永続ストレージに書き込まれる前にデータ破損を検出および削除できます。この機能は、次の物理読取りまで書込みの逸脱、欠落または破損を検出できない現在の Oracle データベースのブロック検証機能より優れています。


Oracle Database 10g の構成

オラクル社のパートナであるストレージ・ベンダーは、仕様に基づいて検証チェック機能を実装することが可能です。特定のベンダーの実装では、そのストレージ・テクノロジに固有の機能が提供されることもあります。オラクル社では、製品および Oracle リリース別に各ベンダーのソリューションを比較した Web サイトを公開しています。

2.2 Oracle Database 10g の構成の構成の構成の構成この項に記載されているベスト・プラクティスは、Oracle Database 10g の次の一般的なデータベース・アーキテクチャに適用されます（『Oracle Database 高可用性概要』で説明されているすべてのアーキテクチャを含みます）。

� Oracle Database 10g

� RAC を使用した Oracle Database 10g

� Data Guard を使用した Oracle Database 10g

� RAC および Data Guard を使用した Oracle Database 10g（MAA）

Oracle Data Guard を使用する場合、これらの推奨事項は、プライマリ・データベースとスタンバイ・データベースの両方で同じです。停止時間の削減または回避、破損リスクの低減、およびリカバリ・パフォーマンスの向上を図るには、これらのプラクティスを採用する必要があります。

この項には、一般的なデータベースを構成するための次のタイプのベスト・プラクティスが含まれます。

� 高可用性の要件

– ARCHIVELOG モードの有効化

– ブロック・チェックサムの有効化

� 高可用性および高速リカバリのための推奨事項

– REDO ログ・ファイルおよびグループの適切なサイズ構成

– フラッシュ・リカバリ領域の使用

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

– ファスト・スタート・リカバリを使用したインスタンス・リカバリ時間の制御

– データベース・ブロック・チェックの有効化

– DISK_ASYNCH_IO の設定

– 8MB 以上の LOG_BUFFER の設定

– 自動共有メモリー管理の使用

– PARALLEL_EXECUTION_MESSAGE_SIZE の増加

– PARALLEL_MIN_SERVERS のチューニング

– パラレル・リカバリの無効化

注意注意注意注意 : ASM を使用してデータベース記憶域を管理する場合、ASM は常に外部冗長性として構成する必要があります。また、新規ディスクの追加などによりリバランス操作が発生する場合、データの移動が誤って HARD により不正な書込みと認識されないように、HARD 保護を無効化する必要があります。

関連資料関連資料関連資料関連資料 : HARD イニシアチブの新情報は、http://www.oracle.com/technology/deploy/availability/htdocs/HARD.htmlを参照してください。



� 管理性向上のための推奨事項

– 自動パフォーマンス・チューニング機能の使用

– サーバー・パラメータ・ファイルの使用

– 自動 UNDO 管理の使用

– ローカル管理表領域の使用

– 自動セグメント領域管理の使用

– 一時表領域の使用とデフォルト一時表領域の指定

– 再開可能領域割当ての使用

– データベース・リソース・マネージャの使用

2.2.1 高可用性の要件高可用性の要件高可用性の要件高可用性の要件この項では、高可用性対応の Oracle データベースを構成するための次の低要件について説明します。

� ARCHIVELOG モードの有効化

� ブロック・チェックサムの有効化

2.2.1.1 ARCHIVELOG モードの有効化モードの有効化モードの有効化モードの有効化ARCHIVELOGモードでは、オンラインでのデータベース・バックアップが可能です。すでにリストアされている時点より後の時点にデータベースをリカバリするには、このモードで運用する必要があります。 Oracle Data Guard やフラッシュバック・データベースなどのアーキテクチャの場合、本番データベースは ARCHIVELOGモードで実行する必要があります。

2.2.1.2 ブロック・チェックサムの有効化ブロック・チェックサムの有効化ブロック・チェックサムの有効化ブロック・チェックサムの有効化Oracle のデフォルトでは、ディスクから読み取られたデータ・ブロックが常に検証されます。 DB_BLOCK_CHECKSUMを TYPICALに設定してデータおよびログのブロック・チェックサムを有効化すると、基礎となるディスク、ストレージ・システムまたは I/O システムで発生した他のタイプの破損を検出できます。データ・ブロックがディスクに書き込まれる前に、チェックサムが計算されてブロックに格納されます。その後、ブロックがディスクから読み取られる際に、チェックサムが再計算されて保存済のチェックサムと比較されます。なんらかの差異は、メディア・エラーとして扱われ、ORA-1578エラーが発生します。 SYSTEM表領域では、ブロック・チェックサムが常に維持されます。 DB_BLOCK_CHECKSUMを FULLに設定すると、ディスクへの書込み前にメモリー内破損も検出できます。

データ・ブロックのチェックサムの有効化に加え、Oracle では、現在のログへの書込み前にすべての REDO ログ・ブロックのチェックサムも計算されます。 REDO レコードの破損は、ログがアーカイブされると即座に検出されます。このオプションを使用しない場合、REDO ログの破損は、ログがスタンバイ・データベースに適用されるか、破損ログ・ブロックを含むログに基づいてバックアップのリストアとロールフォワードが実行されるまで見つからない可能性があります。

RMAN でも、バックアップ対象のすべてのブロックが有効であることを確認するため、バックアップ時にチェックサムが計算されます。

一般的に、TYPICALのオーバーヘッドは 1 ～ 2%、FULLのオーバーヘッドは 4 ～ 5% です。デフォルト設定の TYPICALでは、非常に低コストで重大な破損を検出できると同時に、高可用性の要件にも対応します。アクティブなデータベースで設定を TYPICALから FULLに変更する前に、テスト・システムで現在のワークロードを使用してパフォーマンスへの影響を測定し、その影響が許容範囲内であることを確認してください。

関連資料関連資料関連資料関連資料 : 自動アーカイブの使用方法の詳細は、『Oracle Database 管理者ガイド』を参照してください。



2.2.2 高可用性および高速リカバリのための推奨事項高可用性および高速リカバリのための推奨事項高可用性および高速リカバリのための推奨事項高可用性および高速リカバリのための推奨事項この項では、リカバリ時間を短縮するための、または可用性と冗長性を向上するための Oracleデータベースのベスト・プラクティスについて説明します。

� REDO ログ・ファイルおよびグループの適切なサイズ構成

� フラッシュ・リカバリ領域の使用

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

� ファスト・スタート・リカバリを使用したインスタンス・リカバリ時間の制御

� データベース・ブロック・チェックの有効化

� DISK_ASYNCH_IO の設定

� 8MB 以上の LOG_BUFFER の設定

� 自動共有メモリー管理の使用

� PARALLEL_EXECUTION_MESSAGE_SIZE の増加

� PARALLEL_MIN_SERVERS のチューニング

� パラレル・リカバリの無効化

2.2.2.1 REDO ログ・ファイルおよびグループの適切なサイズ構成ログ・ファイルおよびグループの適切なサイズ構成ログ・ファイルおよびグループの適切なサイズ構成ログ・ファイルおよびグループの適切なサイズ構成Oracle ログの多重化を使用して、データ領域およびフラッシュ・リカバリ領域の各 REDO グループに複数の REDO ログ・メンバーを作成します。これにより、REDO ログに関連する障害

（いずれかのメンバーのディスク障害や I/O 障害、またはオペレーティング・システム・コマンドにより間違ってメンバーを削除するといったユーザー・エラー）からデータを保護できます。少なくとも 1 つの REDO ログ・メンバーが使用できれば、インスタンスは継続して動作できます。

すべてのオンライン REDO ログ・ファイルは、同じサイズとし、通常のアクティビティでほぼ1 時間に 1 回切り替わるように構成します。アクティビティのピーク時でも、20 分に 1 回より高い頻度で切り替わらないようにします。

ログ・スイッチ後にグループが使用可能になるのを LGWRが待機することのないように、少なくとも 4 つのオンライン・ログ・グループを用意する必要があります。グループが使用できなくなる可能性があるのは、チェックポイント処理が完了していない場合や、グループがアーカイブされていない場合です。


� REDO ログの管理方法の詳細は、『Oracle Database 管理者ガイド』を参照してください。

� オンライン、アーカイブおよびスタンバイ REDO ログ・ファイルの詳細は、『Oracle Data Guard 概要および管理』を参照してください。

� 2-21 ページの 2.4 項「Data Guard を使用した Oracle Database 10g の構成」。



2.2.2.2 フラッシュ・リカバリ領域の使用フラッシュ・リカバリ領域の使用フラッシュ・リカバリ領域の使用フラッシュ・リカバリ領域の使用フラッシュ・リカバリ領域は、Oracle が管理するディスク領域であり、バックアップ・ファイルとリカバリ・ファイルを集中管理するためのディスク上の場所です。フラッシュ・リカバリ領域は、次のデータベース初期化パラメータを設定することで定義します。

� DB_RECOVERY_FILE_DEST

このパラメータでは、フラッシュ・リカバリ領域のデフォルトの場所を指定します。

� DB_RECOVERY_FILE_DEST_SIZE

このパラメータでは、リカバリ領域の場所に作成されるターゲット・データベースのリカバリ・ファイルで使用される合計領域について、強い制限の値をバイト単位で指定します。

フラッシュ・リカバリ領域は、リカバリのための主要な場所となります。フラッシュ・リカバリ領域のサイズが適切であれば、修復に必要なファイルをすぐに使用できます。推奨される低限のディスク制限値は、データベース、増分バックアップ、テープにコピーされていないすべてのアーカイブ REDO ログ、およびフラッシュバック・ログの合計サイズです。

2.2.2.3 フラッシュバック・データベースの有効化フラッシュバック・データベースの有効化フラッシュバック・データベースの有効化フラッシュバック・データベースの有効化フラッシュバック・データベースでは、データファイルのバックアップ・コピーをリストアすることなく、データベースを過去のある時点に戻すことができます。フラッシュバック・データベースは、変更されたデータのみが操作対象となる画期的なリカバリ機能です。フラッシュバック・データベースにより、エラーの修正時間は、エラーの発生時間と検出時間に比例することになり、データベース・サイズに依存するリカバリ時間は除外されます。複雑な手順を使用することなく、1 つのコマンドで RMAN と SQL*Plus の両方からデータベースをフラッシュバックできます。

フラッシュバック・データベースでは、通常の実行時に、フラッシュバック・リカバリ領域に存在するフラッシュバック・ログにデータ・ブロックの変更前のイメージがバッファされて書き込まれます。フラッシュバックの書込みスループットを維持するため、十分な I/O 帯域幅がフラッシュ・リカバリ領域で使用できることを確認してください。フラッシュバックの書込みが遅い場合（flashback free buffer waits待機イベントで判別できます）、データベース・スループットが影響を受けます。フラッシュバック・データベースによるディスク書込みの容量は、ワークロードとアプリケーション・プロファイルに応じて異なります。十分なディスク・スピンドルおよび I/O スループットとともにフラッシュバック・リカバリ領域を使用する一般的な OLTP ワークロードの場合、フラッシュバック・データベースにより発生するオーバーヘッドは、2% 未満です。

フラッシュバック・データベースでは、プライマリまたはスタンバイ・データベースをロール移行より前の時点までフラッシュバックできます。また、フラッシュバック・データベースは、リセットログ操作より前の時点を対象に実行できるため、管理者はより柔軟に人為的エラーを検出および修正できます。自動フェイルオーバー後に Data Guard Broker でプライマリ・データベースを自動的に復元するためにファスト・スタート・フェイルオーバーを使用する場合、フラッシュバック・データベースは必須です。

スタンバイ・データベースを使用する場合、プライマリ・データベースとスタンバイ・データベースの両方で DB_FLASHBACK_RETENTION_TARGETに同じ値を設定します。

関連資料関連資料関連資料関連資料 : フラッシュ・リカバリ領域のサイズ指定と保存期間の設定の詳細は、『Oracle Database バックアップおよびリカバリ基礎』を参照してください。

関連資料関連資料関連資料関連資料 : リストア・ポイントとフラッシュバック・データベースの詳細は、『Oracle Database バックアップおよびリカバリ基礎』を参照してください。



2.2.2.4 ファスト・スタート・リカバリを使用したインスタンス・リカバリファスト・スタート・リカバリを使用したインスタンス・リカバリファスト・スタート・リカバリを使用したインスタンス・リカバリファスト・スタート・リカバリを使用したインスタンス・リカバリ時間の制御時間の制御時間の制御時間の制御ファスト・スタート・リカバリ機能では、クラッシュからのリカバリに必要な時間を短縮できます。また、使用済バッファの数と、新の REDO レコードと後のチェックポイントの間に生成される REDO レコードの数を制限することで、リカバリに境界を設定して予測可能とします。この機能では、FAST_START_MTTR_TARGET初期化パラメータにより、インスタンスまたはシステム障害からのリカバリ時間を簡単に構成できます。このパラメータでは、予定する目標リカバリ時間（RTO）の目標値を指定します。RTO は、インスタンスを起動してキャッシュ・リカバリを実行するための時間（秒単位）です。このパラメータを設定すると、データベースでは、設定された目標値に適合するよう増分チェックポイントの書込みが管理されます。このパラメータに特定の値を選択した場合、現在のデータベースは、平均でほぼ選択した秒数以内にリカバリされると期待できます。

2.2.2.5 データベース・ブロック・チェックの有効化データベース・ブロック・チェックの有効化データベース・ブロック・チェックの有効化データベース・ブロック・チェックの有効化DB_BLOCK_CHECKINGを LOW、MEDIUMまたは FULLに設定してデータベース・ブロック・チェックを有効化します。各値で実行されるブロック・チェックは、次のとおりです。

� LOW

メモリー内ブロック変更の後にブロック・チェックが実行されます。

� MEDIUM

すべてのメモリー内ブロック変更のチェックが実行されると同時に、すべての非索引構成表ブロックに対してセマンティクス・ブロック・チェックが実行されます。

� FULL

すべてのメモリー内ブロック変更のブロック・チェックが実行されると同時に、すべての非索引構成表ブロックと索引ブロックに対してセマンティクス・ブロック・チェックが実行されます。

これら 3 つの形式のブロック・チェックのいずれかを有効化すると、Oracle データベースにより、対応するタイプのブロック変更が発生したときにそのブロックの一貫性が検証されます。一貫性が失われているブロックは、破損ブロックとしてマークされ、ORA-1578 エラーが戻されます。また、問題の詳細を含むトレース・ファイルが作成されます。ブロック・チェックを有効化しないと、ブロックが再度アクセスされるまで破損が検出されない可能性があります。 DB_BLOCK_CHECKINGの設定内容にかかわらず、SYSTEM表領域のブロック・チェックは常に有効です。

ブロック・チェックにより、メモリーおよびデータの破損を高い頻度で防ぐことができます。通常、この機能を有効化すると、設定とワークロードに応じて 1 ～ 10% の追加オーバーヘッドが発生します。アクティブなデータベースにこの機能を導入する前に、テスト・システムで現在のワークロードを使用してパフォーマンスへの影響を測定し、その影響が許容範囲内であることを確認してください。

DB_BLOCK_CHECKINGで保護できなかったディスク上のブロック破損をチェックするには、次のいずれかを使用します。

� RMAN BACKUPコマンド（VALIDATEオプション付き）

� DBVERIFYユーティリティ

� ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE SQL 文

関連資料関連資料関連資料関連資料 : ファスト・スタート・リカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。



2.2.2.6 DISK_ASYNCH_IO の設定の設定の設定の設定適な I/O パフォーマンスを得るため、DISK_ASYNCH_IO=TRUEに設定して非同期ディスク

I/O を有効化します。

2.2.2.7 8MB 以上の以上の以上の以上の LOG_BUFFER の設定の設定の設定の設定大規模な本番データベースでは、LOG_BUFFER初期化パラメータを 8MB 以上に設定します。この設定により、データベースでは、フラッシュバック・データベース・ログの書込み用に大メモリー（通常は 16MB）を割り当てることができます。

2.2.2.8 自動共有メモリー管理の使用自動共有メモリー管理の使用自動共有メモリー管理の使用自動共有メモリー管理の使用自動共有メモリー管理（ASM）の導入により、メモリー管理機能は大幅に向上しました。 SGA_TARGETパラメータに 0（ゼロ）以外の値を設定することで、共有プール、ラージ・プール、Java プール、Streams プールおよびバッファ・キャッシュのサイズを必要に応じて自動的かつ動的に変更できます。詳細は、『Oracle Database 管理者ガイド』を参照してください。

2.2.2.9 PARALLEL_EXECUTION_MESSAGE_SIZE の増加の増加の増加の増加PARALLEL_EXECUTION_MESSAGE_SIZE初期化パラメータの値をデフォルト値の 2048から4096に増やします。この構成手順により、インスタンス・リカバリなどのパラレル実行が高速化します。

2.2.2.10 PARALLEL_MIN_SERVERS のチューニングのチューニングのチューニングのチューニングインスタンスまたはノード・クラッシュから迅速にリカバリするため、必要な数のパラレル・リカバリ・プロセスを事前生成するように PARALLEL_MIN_SERVERSを設定します。このパラメータは、FAST_START_MTTR_TARGETと連携してリカバリ時間を制限します。

PARALLEL_MIN_SERVERS = CPU_COUNT + GV$ 問合せとパラレル実行に使用されるパラレル問合せプロセスの平均数

2.2.2.11 パラレル・リカバリの無効化パラレル・リカバリの無効化パラレル・リカバリの無効化パラレル・リカバリの無効化V$INSTANCE_RECOVERYビューの RECOVERY_ESTIMATED_IOSの値が小さい場合（5000 未満など）、パラレル・リカバリのオーバーヘッドがそのメリットを上回っている可能性があります。この状況は、FAST_START_MTTR_TARGETの設定が極端な場合によく発生します。この場合、RECOVERY_PARALLELISMを 1 に設定してパラレル・リカバリを無効化してください。


� RMAN BACKUP VALIDATEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

� SQL ANALYZE TABLE文の詳細は、『Oracle Database SQL リファレンス』を参照してください。

� DBVERIFYの詳細は、『Oracle Database ユーティリティ』を参照してください。



2.2.3 管理性向上のための推奨事項管理性向上のための推奨事項管理性向上のための推奨事項管理性向上のための推奨事項この項では、Oracle データベースの管理性を向上するためのベスト・プラクティスについて説明します。

� 自動パフォーマンス・チューニング機能の使用

� サーバー・パラメータ・ファイルの使用

� 自動 UNDO 管理の使用

� ローカル管理表領域の使用

� 自動セグメント領域管理の使用

� 一時表領域の使用とデフォルト一時表領域の指定

� 再開可能領域割当ての使用

� データベース・リソース・マネージャの使用

2.2.3.1 自動パフォーマンス・チューニング機能の使用自動パフォーマンス・チューニング機能の使用自動パフォーマンス・チューニング機能の使用自動パフォーマンス・チューニング機能の使用パフォーマンス問題を特定および修正するためには、効果的なデータの収集と分析が不可欠です。 Oracle には、パフォーマンス・エンジニアがデータベース・パフォーマンスに関する情報を収集できる複数のツールが付属しています。

Oracle データベースの自動パフォーマンス・チューニング機能は、次のもので構成されます。

� 自動ワークロード・リポジトリ（AWR）

� 自動データベース診断モニター（ADDM）

� SQL チューニング・アドバイザ

� SQL アクセス・アドバイザ

AWR を使用する場合、次のベスト・プラクティスを検討してください。

� ストレス・テスト中にパフォーマンスのピークを取得する場合や、パフォーマンス問題を診断する場合、AWR 自動スナップショットの間隔を 10 ～ 20 分に設定します。

� 通常のワークロードの場合、60 分間隔で十分です。

2.2.3.2 サーバー・パラメータ・ファイルの使用サーバー・パラメータ・ファイルの使用サーバー・パラメータ・ファイルの使用サーバー・パラメータ・ファイルの使用サーバー・パラメータ・ファイル（SPFILE）は、データベースのすべてのインスタンスに関連付けられたすべてのデータベース初期化パラメータを保持する単一の集中管理パラメータ・ファイルです。このファイルにより、データベース・パラメータを管理するための簡単で確実な永続的環境が提供されます。 Data Guard Broker を使用する場合、SPFILE は必須です。


� SPFILE で初期化パラメータを管理する方法の詳細は、『Oracle Database 管理者ガイド』を参照してください。

� Real Application Clusters 環境での初期化パラメータの詳細は、『Oracle Database Oracle Clusterware および Oracle Real Application

Clusters 管理およびデプロイメント・ガイド』を参照してください。

� Oracle Data Guard Broker を使用する際の他の要件の詳細は、『Oracle Data Guard Broker』を参照してください。

� 付録 A「データベース SPFILE および Oracle Net 構成ファイルのサンプル」



2.2.3.3 自動自動自動自動 UNDO 管理の使用管理の使用管理の使用管理の使用自動 UNDO 管理を使用すると、Oracle データベース・サーバーで効果的かつ効率的に UNDO領域を管理できるため、管理作業の複雑さとコストが削減されます。 Oracle データベースで内部的に UNDO セグメントを管理する場合、現在のワークロード要件に合せて UNDO セグメントのサイズと数が自動的に調整されるため、UNDO ブロックと読取り一貫性の競合は発生しません。

自動 UNDO 管理を使用するには、次の初期化パラメータを設定します。

� UNDO_MANAGEMENT

このパラメータは、AUTOに設定します。

� UNDO_RETENTION

このパラメータでは、UNDO データを保存する希望時間を秒単位で指定します。すべてのインスタンスで同じにする必要があります。

� UNDO_TABLESPACE

このパラメータでは、インスタンスごとに一意の UNDO 表領域を指定します。

フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション問合せ、フラッシュバック表などの高度なオブジェクト・リカバリ機能では、自動UNDO 管理が必要です。 Oracle データベースのデフォルトでは、データベース使用統計の収集と UNDO 容量要件の評価により、自動的に UNDO 保存期間が調整されます。この自動チューニングを変更するには、UNDO_RETENTION初期化パラメータを設定します。この初期化パラメータは、次の場合にのみ設定する必要があります。

� UNDO 表領域で AUTOEXTENDオプションを有効化する場合

� LOB の UNDO 保存期間を設定する場合

� 保存保証を必要とする場合

保存保証オプションでは、DML アクティビティの必要があっても、UNDO 保証が維持されます（DDL 文は引き続き許可されます）。表領域に構成されている領域がトランザクション・スループットの必要量より少ない場合、次の 4 つの処理が順番に発生します。

1. 自動拡張可能なファイルがある場合、保存された UNDO データを格納できるようそのファイルが自動拡張されます。

2. 85% フルの時点で警告アラートが発行されます。

3. 97% フルの時点でクリティカル・アラートが発行されます。

4. トランザクションに領域不足エラーが戻されます。

注意注意注意注意 : デフォルトでは、UNDO データは、UNDO_RETENTION設定を使用して維持するよう指定していても、実行中のトランザクションによって上書きされる可能性があります。期限切れ前の UNDO データが上書きされないよう保証するには、UNDO 表領域で保存保証を有効化する必要があります。

関連資料関連資料関連資料関連資料 : UNDO_RETENTIONの設定と UNDO 表領域のサイズの詳細は、『Oracle Database 管理者ガイド』を参照してください。



2.2.3.4 ローカル管理表領域の使用ローカル管理表領域の使用ローカル管理表領域の使用ローカル管理表領域の使用ローカル管理表領域は、ディクショナリ管理表領域よりパフォーマンスに優れており、管理が容易で領域が断片化する心配もありません。ローカル管理表領域では、データファイルのヘッダーに格納されたビットマップを使用します。ディクショナリ管理表領域とは異なり、領域の割当てと割当て解除において集中管理されたリソースに対する競合は発生しません。

2.2.3.5 自動セグメント領域管理の使用自動セグメント領域管理の使用自動セグメント領域管理の使用自動セグメント領域管理の使用自動セグメント領域管理により、領域管理タスクを簡略化することで、人為的エラーの発生を抑制できます。別のメリットとして、領域管理関連のパフォーマンス・チューニングが不要になります。この機能により、表や索引などのオブジェクト内の空き領域の管理が容易になり、領域使用率が向上し、簡単な管理操作でパフォーマンスとスケーラビリティが大幅に改善します。自動セグメント領域管理機能は、デフォルトの属性を使用して作成されたすべての新規表領域でデフォルトで有効化されます。

2.2.3.6 一時表領域の使用とデフォルト一時表領域の指定一時表領域の使用とデフォルト一時表領域の指定一時表領域の使用とデフォルト一時表領域の指定一時表領域の使用とデフォルト一時表領域の指定一時表領域により、複数のソート操作の同時実行性の向上、ソート操作のオーバーヘッドの削減、およびデータ・ディクショナリによる領域管理操作の完全な回避が可能になります。これは、システム・リソースの使用とデータベース・パフォーマンスの両方の観点からして、一時セグメントを処理するためのより効率的な方法です。

デフォルト一時表領域は、TEMPORARY TABLESPACE 句が不注意で指定されない場合に備え、データベース全体に対して指定します。これを行うには、CREATE DATABASE文（データベース作成時）または ALTER DATABASE文（データベース作成後）で DEFAULT TEMPORARY TABLESPACE句を使用します。デフォルト一時表領域を使用すると、すべてのディスク・ソート処理は一時表領域で発生し、他の表領域が誤ってソートに使用されることはなくなります。

2.2.3.7 再開可能領域割当ての使用再開可能領域割当ての使用再開可能領域割当ての使用再開可能領域割当ての使用再開可能領域割当ては、領域割当て障害が発生した場合にデータベース操作を一時停止して後から再開する方法です。データベースはエラーを戻さず、関連する操作を一時停止します。プロセスを再起動する必要はありません。領域問題が解決すると、一時停止されていた操作は自動的に再開されます。

再開可能領域割当てを使用するには、RESUMABLE_TIMEOUT初期化パラメータに再試行時間の秒数を設定します。同時に、セッション・レベルで ALTER SESSION ENABLE RESUMABLE文を発行する必要があります。

関連資料関連資料関連資料関連資料 : ローカル管理表領域の詳細は、『Oracle Database 管理者ガイド』を参照してください。

関連資料関連資料関連資料関連資料 : セグメント領域管理の詳細は、『Oracle Database 管理者ガイド』を参照してください。

関連資料関連資料関連資料関連資料 : 表領域管理の詳細は、『Oracle Database 管理者ガイド』を参照してください。

関連資料関連資料関連資料関連資料 : 再開可能領域割当ての管理方法の詳細は、『Oracle Database 管理者ガイド』を参照してください。


RAC を使用した Oracle Database 10g の構成

2.2.3.8 データベース・リソース・マネージャの使用データベース・リソース・マネージャの使用データベース・リソース・マネージャの使用データベース・リソース・マネージャの使用データベース・リソース・マネージャを使用すると、データベース管理者は、リソース割当てがエンタープライズのビジネス目標に合うようにリソース管理の設定を詳細に制御できます。データベース・リソース・マネージャでは、Oracle データベース・サーバー内の作業に優先順位を設定できます。データベースの可用性には、その機能性とパフォーマンスの両方が含まれます。データベースが使用可能であっても、ユーザーの必要とするパフォーマンス・レベルに到達しなければ、可用性とサービス・レベルの目標は満たされません。アプリケーション・パフォーマンスは、データベースにアクセスする各アプリケーションにリソースがどのように配置されるかによって大きく変化します。データベース・リソース・マネージャの主な目的は、Oracle データベース・サーバーでリソース管理の設定をより詳細に制御して、オペレーティング・システムの不十分な管理やオペレーティング・システムのリソース・マネージャを原因として発生する問題を回避することです。データベース・リソース・マネージャは、デフォルトで有効化されます。

2.3 RAC を使用したを使用したを使用したを使用した Oracle Database 10g の構成の構成の構成の構成この項に記載されているベスト・プラクティスは、RAC を使用した Oracle Database 10g に適用されます。これらのベスト・プラクティスは、2-8 ページの 2.2 項「Oracle Database 10g の構成」に説明されている Oracle Database 10g 構成のベスト・プラクティスを基盤としています。各ベスト・プラクティスは、RAC と Data Guard を使用した Oracle Database 10g（MAA）環境の Data Guard で使用される場合、プライマリ・データベースとスタンバイ・データベースで同一です。一部のベスト・プラクティスは、パフォーマンス・レベルを低下させることもありますが、システム停止を抑制または回避するために必要です。パフォーマンスに対するわずかな影響より、破損リスクの軽減またはリカバリ時のパフォーマンス向上の方が重要です。


� サービスおよび仮想インターネット・プロトコル（VIP）・アドレスを使用したデータベースへの接続

� Oracle クラスタウェアを使用したクラスタおよびアプリケーションの可用性の管理

� クライアント側およびサーバー側でのロード・バランシングの使用

� Oracle Cluster Registry（OCR）のミラー化と複数の投票ディスクの構成

� テープまたはオフサイトへの OCR の定期的なバックアップ

� CRS と RAC で同じインターコネクト・ネットワークを使用していることの確認

� クラスタの大インスタンスに応じたすべてのデータベースの構成

関連資料関連資料関連資料関連資料 : データベース・リソース・マネージャの詳細は、『Oracle Database 管理者ガイド』を参照してください。



2.3.1 サービスおよび仮想インターネット・プロトコル（サービスおよび仮想インターネット・プロトコル（サービスおよび仮想インターネット・プロトコル（サービスおよび仮想インターネット・プロトコル（VIP）・アドレスを）・アドレスを）・アドレスを）・アドレスを使用したデータベースへの接続使用したデータベースへの接続使用したデータベースへの接続使用したデータベースへの接続

Oracle Database 10g では、アプリケーション・ワークロードを個別に管理および制御できるように、それらのワークロードをサービスとして定義できます。 DBA は、通常運用時と障害対応時において各サービスにどの処理リソースを割り当てるかを制御します。サービスによりパフォーマンス・メトリックが追跡され、一定の値を超えたときにアラートを自動生成するためのしきい値が設定されます。サービスでの CPU リソース割当てとリソース使用量制御は、リソース・マネージャを通じて管理されます。ジョブ・スケジューラ、パラレル問合せ、Oracle Streams アドバンスト・キューイングなどの Oracle ツールおよび機能でも、サービスの使用によりそのワークロードが管理されます。

Oracle Database 10g では、処理リソースをサービスに自動で割り当てるためのルールを定義できます。 Oracle RAC 10g インスタンスは、個々のサービスまたは複数のサービスを処理するために必要に応じて割り当てることが可能です。これらの割当てルールは、変化するビジネス要件に合せて動的に変更できます。たとえば、重要な財務処理を予定どおり完了するのに十分な処理リソースを確保するため、四半期末の時点でこれらのルールを変更できます。ルールを定義して、重要度の高いサービスを実行するインスタンスに障害が発生したときに、そのワークロードを重要度の低いワークロードを実行するインスタンスに自動で移行することも可能です。サービスは、Enterprise Manager、データベース・コンフィギュレーション・アシスタント

（DBCA）および DBMS_SERVICE PL/SQL パッケージで作成および管理できます。

データベースへのアプリケーション接続は、サービスに対する仮想インターネット・プロトコル（VIP）・アドレスを通じて行う必要があります（VIP アドレスは、高度の可用性と管理性を備えたワークロード管理機能の一部として定義されます）。

VIP アドレスは、クライアント接続で標準のパブリック IP アドレスのかわりに使用される代替パブリック・アドレスです。あるノードに障害が発生すると、そのノードの VIP アドレスは、同じ VIP アドレスで接続を受け入れることのできる別のノードにフェイルオーバーされます。 VIP アドレスに接続を試みるクライアントでは、TCP 接続のタイムアウト・メッセージを待機することなく迅速に接続拒否エラーを受信できるため、障害ノードに対して初期接続を試行する無駄な時間を削減できます。 VIP アドレスは、仮想インターネット・プロトコル・コンフィギュレーション・アシスタント（VIPCA）を使用して構成します。

2.3.2 Oracle クラスタウェアを使用したクラスタおよびアプリケーションのクラスタウェアを使用したクラスタおよびアプリケーションのクラスタウェアを使用したクラスタおよびアプリケーションのクラスタウェアを使用したクラスタおよびアプリケーションの可用性の管理可用性の管理可用性の管理可用性の管理

RAC の稼働するほとんどのプラットフォームで必要なクラスタウェアは、Oracle クラスタウェアのみです。他のベンダーのクラスタウェアでも、RAC 用に認定されていれば使用できます。ただし、Oracle クラスタウェアによりすでに提供されている機能に対して不要なソフトウェア・レイヤーを追加すると、複雑さとコストが増大し、特に計画済のメンテナンスなどでシステムの可用性が低下する可能性があります。

Oracle クラスタウェアには、任意のアプリケーションを管理するためのインフラストラクチャを提供する高可用性フレームワークが含まれます。 Oracle クラスタウェアにより、システムの起動時に管理対象アプリケーションが開始されることが保証されます。 Oracle クラスタウェアは、アプリケーションが常に使用できるよう監視も行います。たとえば、プロセスに障害が発生した場合、Oracle クラスタウェアは、ユーザーがカスタマイズしたスクリプトに基づいてそのプロセスを再起動します。クラスタ内のノードに障害が発生した場合、通常は障害の発生したノードで稼働するプロセスをプログラムして別のノードで再起動できます。アプリケーションの監視の頻度、アプリケーションの開始と停止、およびアプリケーションの依存性は、構成可能です。

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

関連資料関連資料関連資料関連資料 : Oracle クラスタウェアでアプリケーションの可用性を管理する方法の詳細は、『Oracle Database Oracle Clusterware および Oracle Real Application Clusters 管理およびデプロイメント・ガイド』を参照してください。



2.3.3 クライアント側およびサーバー側でのロード・バランシングの使用クライアント側およびサーバー側でのロード・バランシングの使用クライアント側およびサーバー側でのロード・バランシングの使用クライアント側およびサーバー側でのロード・バランシングの使用クライアント側のロード・バランシングにより、新規接続リクエストがすべてのリスナーに均等に分散されます。クライアント接続の定義でこれを指定するには、LOAD_BALANCEパラメータを ONに設定します。（記述リストのデフォルトは、ONです。）このパラメータが ONに設定されている場合、Oracle データベースは、アドレス・リスト内のアドレスをランダムに選択してそのノードのリスナーに接続します。これにより、クライアント接続は、クラスタ内の使用可能なリスナー全体に分散されます。リスナーは、接続リクエストを受信すると、認識しているサービスのうちで要求されたサービスを提供しているインスタンスにユーザーを接続します。リスナーによりサポートされるサービスを確認するには、LSNRCTLサービス・コマンドを実行します。

サーバー側のロード・バランシングでは、接続リクエストでデータベース・サービスを要求されると、使用可能なインスタンスで実行されている現在のワークロードを使用して、その接続リクエストを負荷のも低いインスタンスに割り当てます。サーバー側の接続ロード・バランシングでは、各インスタンスを使用可能なすべてのリスナーに登録する必要があります。これを行うには、各インスタンスで LOCAL_LISTENERおよび REMOTE_LISTENERパラメータを設定します。これは、DBCA でデータベースを作成するとデフォルトで実行されます。接続ロード・バランシングの機能を拡張するには、ロード・バランシング・アドバイザを使用し、DBMS_SERVICE PL/SQL パッケージで GOALおよび CLB_GOAL属性を設定して各サービスの接続ロード・バランシングの目標を定義します。

2.3.4 Oracle Cluster Registry（（（（OCR）のミラー化と複数の投票ディスクの構成）のミラー化と複数の投票ディスクの構成）のミラー化と複数の投票ディスクの構成）のミラー化と複数の投票ディスクの構成OCR には、クラスタの構成情報と、クラスタ内のクラスタ・データベースに関する構成情報が保持されます。 OCR では、Oracle クラスタウェアが制御するプロセスに関する情報も管理されます。 OCR をディスク障害から保護するため、Oracle クラスタウェアの機能を使用して OCRをミラー化します。外部冗長性を使用している場合、外部冗長ストレージに OCR を作成します。外部冗長性を使用していない場合、2 つの異なるコントローラに対して低 2 つの OCR を作成します。

RAC では、クラスタのメンバーであるインスタンスを決定するのに投票ディスクを使用します。投票ディスクは、共有ディスクに存在する必要があります。高可用性を確保するため、複数の投票ディスクを保持することをお薦めします。 Oracle クラスタウェアでは、複数の投票ディスクを使用できますが、投票ディスクの数は 3、5 などの奇数である必要があります。単一の投票ディスクを定義する場合は、外部ミラー化を使用して冗長性を確保します。


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

� リスナー構成の詳細は、『Oracle Database Net Services 管理者ガイド』を参照してください。

� LOCAL_LISTENERおよび REMOTE_LISTENERパラメータの詳細は、『Oracle Database リファレンス』を参照してください。

関連資料関連資料関連資料関連資料 : OCR および投票ディスクの管理方法の詳細は、『Oracle Database Oracle Clusterware および Oracle Real Application Clusters 管理およびデプロイメント・ガイド』を参照してください。



2.3.5 テープまたはオフサイトへのテープまたはオフサイトへのテープまたはオフサイトへのテープまたはオフサイトへの OCR の定期的なバックアップの定期的なバックアップの定期的なバックアップの定期的なバックアップOCR には、RAC と Cluster Ready Services（CRS）に関するクラスタおよびデータベースの構成情報（クラスタ・データベースのノード・リスト、CRS アプリケーションのリソース・プロファイル、イベント・マネージャ（EVM）の認可など）が含まれます。 Oracle クラスタウェアでは、4 時間ごとに自動的に OCR のバックアップが作成されます。 Oracle では、OCR の新の 3 つのバックアップ・コピーが常に保持されます。バックアップを作成する CRSDプロセスにより、1 日ごと、および各週の終わりにも OCR のバックアップが作成されて保持されます。 Oracle クラスタウェアによって作成されたバックアップ・ファイルは、Oracle Secure Backup、標準のオペレーティング・システム・ツールまたはサード・パーティ・ツールを使用して、オペレーティング・システム・バックアップの一環としてバックアップする必要があります。

自動作成される OCR バックアップ・ファイルを使用する以外に、重要な構成変更（現在の環境でのノードの追加または削除、Oracle クラスタウェア・リソースの変更、データベースの作成など）の前後には OCR の内容をエクスポートする必要があります。これを行うには、ocrconfig -exportコマンドを使用します。これにより、OCR の内容がファイル形式でエクスポートされます。 ocrconfigによって作成したエクスポート・ファイルは、Oracle Secure Backup、標準のオペレーティング・システム・ツールまたはサード・パーティ・ツールを使用して、オペレーティング・システム・バックアップの一環としてバックアップする必要があります。

2.3.6 CRS とととと RAC で同じインターコネクト・ネットワークを使用していることで同じインターコネクト・ネットワークを使用していることで同じインターコネクト・ネットワークを使用していることで同じインターコネクト・ネットワークを使用していることの確認の確認の確認の確認

も効率的なネットワーク検出およびフェイルオーバーを実現するため、CRS と RAC では、接続とアクセス可能性について同じ認識を共有するように同じインターコネクト・サブネットを使用する必要があります。 RAC で使用されているインターコネクト・サブネットを確認するには、いずれかのインスタンスで次のように Oracle ORADEBUGユーティリティを実行します。

SQL> ORADEBUG SETMYPIDStatement processed.SQL> ORADEBUG IPCInformation written to trace file.SQL> ORADEBUG tracefile_name/u01/app/oracle/admin/prod/udump/prod1_ora_24409.trc

トレース・ファイルの SSKGXPT セクションを調べ、RAC で使用されているサブネットを確認します。この例では、次のように使用サブネットは 192.168.0.3 で、使用プロトコルは UDP です。

SSKGXPT 0xd7be26c flags info for network 0 socket no 7 IP 192.168.0.3 UDP 14727

CRS で使用されているインターコネクト・サブネットを確認するには、次のように OCR のキー名 SYSTEM.css.node_numbers.node<n>.privatenameの値を調べます。

prompt> ocrdump -stdout -keyname SYSTEM.css.node_numbers [SYSTEM.css.node_numbers.node1.privatename]ORATEXT : halinux03ic0 …

注意注意注意注意 : UNIX ベースのシステムでバックアップが生成されるデフォルトの場所は、CRS_HOME/cdata/cluster_name（cluster_nameはクラスタ名）です。 Windows ベースのシステムでバックアップが生成されるデフォルトの場所は、これと同じパス構成の場所です。

関連資料関連資料関連資料関連資料 : OCR のバックアップ方法の詳細は、『Oracle Database Oracle Clusterware および Oracle Real Application Clusters 管理およびデプロイメント・ガイド』を参照してください。


Data Guard を使用した Oracle Database 10g の構成

[SYSTEM.css.node_numbers.node2.privatename]ORATEXT : halinux04ic0

ここでのホスト名（この例では halinux03ic0および halinux04ic0）が、ORADEBUGで生成されたトレース・ファイルのサブネット（サブネット 192.168.0.3）と一致する必要があります。オペレーティング・システムのツールを使用して確認します。 Linux では、次のようになります。

prompt> getent hosts halinux03ic0192.168.0.3 halinux03ic0.us.oracle.com halinux03ic0

2.3.7 クラスタの最大インスタンスに応じたすべてのデータベースの構成クラスタの最大インスタンスに応じたすべてのデータベースの構成クラスタの最大インスタンスに応じたすべてのデータベースの構成クラスタの最大インスタンスに応じたすべてのデータベースの構成RAC データベースの初期設定時に、クラスタに含まれるすべての追加インスタンスのオンライン REDO ログ・スレッドと UNDO 表領域を作成しておく必要があります。データベースが任意の時点で Oracle Data Guard のスタンバイ・データベースになる可能性がある場合は、この段階で各スレッドのスタンバイ REDO ログも作成します。

2.4 Data Guard を使用したを使用したを使用したを使用した Oracle Database 10g の構成の構成の構成の構成この項に記載されているベスト・プラクティスは、Data Guard を使用した Oracle Database 10gに適用されます。これらのベスト・プラクティスは、2-8 ページの 2.2 項「Oracle Database 10gの構成」に説明されているベスト・プラクティスを基盤としています。スイッチオーバーやフェイルオーバー後にすべてのスタンバイ・データベースが適切に動作し、サービス・レベルの範囲内でそのロールを実行するには、Oracle Data Guard の REDO Apply および SQL Applyの適切な構成が不可欠です。 Data Guard のほとんどの構成設定は、Oracle Enterprise Managerで操作できます。使用頻度の低い高度な Data Guard 構成パラメータを設定する場合は、Data Guard Broker のコマンドライン・インタフェースまたは SQL*Plus を使用できます。

Data Guard では、ビジネス要件に応じて、フィジカル・スタンバイ・データベース（REDO Apply）とロジカル・スタンバイ・データベース（SQL Apply）の一方または両方を使用できます。フィジカル・スタンバイ・データベースでは、プライマリ・データベースと物理的に同一のコピーが提供されます。フィジカル・スタンバイ・データベースのディスク上のデータベース構造は、ブロック単位でプライマリ・データベースと同じです。索引などのデータベース・スキーマも同じです。フィジカル・スタンバイ・データベースとプライマリ・データベースとの同期は、メディア・リカバリを通じてプライマリ・データベースから取得された REDOデータを適用することで維持されます。

ロジカル・スタンバイ・データベースには、本番データベースと同じ論理情報が含まれますが、データの物理的な編成と構造は異なる場合があります。ロジカル・スタンバイ・データベースとプライマリ・データベースとの同期は、プライマリ・データベースから取得された REDO ログ・ファイルのデータを SQL 文に変換し、その SQL 文をスタンバイ・データベースで実行することで維持されます。ロジカル・スタンバイ・データベースは、障害時のリカバリ要件を満たす以外に、他のビジネス目的にも使用できます。

この項には、Data Guard の次の内容に関する構成上のベスト・プラクティスが含まれます。

� フィジカル・スタンバイまたはロジカル・スタンバイ

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

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

– 現在のアプリケーションに適なスタンバイ・タイプの決定

� データ保護モード

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

関連資料関連資料関連資料関連資料 : Oracle Real Application Clusters のストレージの概要は、『Oracle Database Oracle Clusterware および Oracle Real Application Clusters 管理およびデプロイメント・ガイド』を参照してください。



� Data Guard の一般構成のベスト・プラクティス

– フェイルオーバー後の迅速な再インスタンス化のためのフラッシュバック・データベースの有効化

– FORCE LOGGING モードの使用

– Data Guard Broker の使用

– 単純で堅牢なアーカイブ計画および構成の使用

– スタンバイ REDO ログの使用と適切なサイズ構成

– パラメータ構成の例

� REDO 転送サービスのベスト・プラクティス

– ネットワーク構成案に関するパフォーマンス評価の実行

– プライマリ・データベース・スループットのベスト・プラクティス

– ネットワーク構成と大ネットワーク REDO 速度のベスト・プラクティス

� ログ適用サービスのベスト・プラクティス

– フィジカル・スタンバイ・データベースにおける REDO Apply のベスト・プラクティス

– ロジカル・スタンバイ・データベースにおける SQL Apply のベスト・プラクティス

� ロール移行のベスト・プラクティス

– フェイルオーバー時のロール移行

– スイッチオーバー時のロール移行

� クローンとしてのフィジカル・スタンバイ・データベースの管理

� データベース以外のデータを保護するための推奨事項

� Data Guard のパフォーマンスの評価

2.4.1 フィジカル・スタンバイまたはロジカル・スタンバイフィジカル・スタンバイまたはロジカル・スタンバイフィジカル・スタンバイまたはロジカル・スタンバイフィジカル・スタンバイまたはロジカル・スタンバイこの項には、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースのいずれかを選択する際に役立つ情報が含まれます。


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

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

� 現在のアプリケーションに適なスタンバイ・タイプの決定

2.4.1.1 フィジカル・スタンバイ・データベースのメリットフィジカル・スタンバイ・データベースのメリットフィジカル・スタンバイ・データベースのメリットフィジカル・スタンバイ・データベースのメリットフィジカル・スタンバイ・データベースのメリットは、次のとおりです。

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

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

� データ保護

フィジカル・スタンバイ・データベースを使用すると、予測不可能な災害に直面した場合でも、Data Guard の一定の構成によりデータ損失を防ぐことができます。フィジカル・スタンバイ・データベースでは、プライマリ・データベースで使用できるすべてのデータ型とすべての DDL および DML 操作がサポートされます。また、データ破損やユーザー・エ



ラーに対する保護機能も提供されます。プライマリ・データベースにおけるストレージ・レベルの物理破損は、スタンバイ・データベースに伝播されません。同様に、プライマリ・データベースを永久的に破壊する論理破損またはユーザー・エラーは、解決することが可能です。 REDO データは、スタンバイ・データベースへの適用時に検証されます。

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

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

� パフォーマンス

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

� テストとレポート用の読取りおよび書込みデータベース

フラッシュバック・データベースとフィジカル・スタンバイ・データベースを使用すると、テストおよびレポート用の一時クローン・データベースを構成できます。この一時クローン・データベースは、後でプライマリ・データベースと再同期できます。

2.4.1.2 ロジカル・スタンバイ・データベースのメリットロジカル・スタンバイ・データベースのメリットロジカル・スタンバイ・データベースのメリットロジカル・スタンバイ・データベースのメリットロジカル・スタンバイ・データベースでは、フィジカル・スタンバイ・データベースと同様の障害時リカバリ、高可用性およびデータ保護機能が提供されます。同時に、次の特別なメリットも得ることができます。

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

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

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

ロジカル・スタンバイ・データベースは、プライマリ・データベースによる表の更新時にオープンしたままにできます。これらの表は、同時に読取りアクセスにも使用できます。これにより、ロジカル・スタンバイ・データベースを問合せ、サマリー作成およびレポート・アクティビティの対象として優先的に選択することで、これらのタスクによるプライマリ・データベースの負荷を軽減し、貴重な CPU および I/O サイクルを節約できます。

� データベースのローリング・アップグレード

ロジカル・スタンバイ・データベースは、新しいリリースにアップグレードした後、Data Guard によるスイッチオーバーを通じて新規プライマリ・データベースとして運用できます。このローリング・アップグレードの手順により、データベース・アップグレードの計画済の停止時間を大幅に削減できます。



2.4.1.3 現在のアプリケーションに最適なスタンバイ・タイプの決定現在のアプリケーションに最適なスタンバイ・タイプの決定現在のアプリケーションに最適なスタンバイ・タイプの決定現在のアプリケーションに最適なスタンバイ・タイプの決定実装するスタンバイ・タイプは、いくつかの主要領域を検討することで決定します。ロジカル・スタンバイにはサポートされないデータ型があるため、まず現在のアプリケーションでサポート外のデータ型を使用していないかどうかを確認します。アプリケーションでサポート外のデータ型を使用していないかどうかを確認するには、プライマリ・データベースで次の問合せを実行します。

� サポート外の表をリストするには、次の問合せを発行します。

SET PAGES 200 LINES 132 COL OWNER FORMAT A8 COL DATA_TYPE FORMAT A15COL TABLE_NAME FORMAT A32COL COLUMN_NAME FORMAT A25COL ATTRIBUTES FORMAT A15SELECT OWNER, TABLE_NAME, REASONFROM DBA_STREAMS_UNSUPPORTEDWHERE OWNER NOT IN (SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT='INTERNAL SCHEMA')ORDER BY OWNER

� 列およびデータ型情報付きでサポート外の表をリストするには、次の問合せを発行します。

COL OWNER FORMAT A9COL DATA_TYPE FORMAT A35COL TABLE_NAME FORMAT A35SELECT OWNER, TABLE_NAME, COLUMN_NAME, DATA_TYPEFROM DBA_TAB_COLSWHERE OWNER NOT IN (SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT='INTERNAL SCHEMA') AND DATA_TYPE NOT IN ('BINARY_DOUBLE', 'BINARY_FLOAT', 'INTERVAL YEAR TO MONTH', 'INTERVAL DAY TO SECOND', 'BLOB', 'CLOB','CHAR', 'DATE','LONG', 'LONG RAW', 'NCHAR', 'NCLOB','NUMBER', 'NVARCHAR2','RAW','TIMESTAMP', 'TIMESTAMP(6)','TIMESTAMP(6) WITH TIME ZONE','TIMESTAMP(9)', 'TIMESTAMP WITH LOCAL TIMEZONE', 'TIMESTAMP WITH TIMEZONE', 'VARCHAR','VARCHAR2')ORDER BY 1,2

いずれかの問合せで重要なアプリケーション表を含む行が戻された場合、フィジカル・スタンバイ・データベースを使用するか、またはサポートされるデータ型のみを使用するようプライマリ・データベースを変更できないかどうかを調査します。問合せで重要なアプリケーション表を含む行が戻されなかった場合、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースのどちらでも使用できます。

次に、変更の適用時にスタンバイ・データベースにアクセスする必要があるかどうかを検討します。保持されているデータに対する読取り専用アクセス付きでスタンバイ・データベースを読取り / 書込みモードでオープンする必要があり、現在のアプリケーションでサポート外のデータ型を使用していない場合、ロジカル・スタンバイを選択するのが適です。変更の適用時にスタンバイ・データベースにアクセスする必要がないか、ロジカル・スタンバイでサポートされないデータ型を使用している場合は、フィジカル・スタンバイを実装する必要があります。

ここまでの検討でロジカル・スタンバイ・データベースが選択肢として残っている場合、次にピーク・ワークロードを処理できるかどうかを評価します。ロジカル・スタンバイ・データベースでは、低レベルのリカバリ・メカニズムのかわりに SQL を使用して変更が適用されるため、データベース・パフォーマンスを慎重に評価する必要があります。詳細は、http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmの

『Oracle Database 10g Release 2 Best Practices: Data Guard SQL Apply』を参照してください。



2.4.2 データ保護モードデータ保護モードデータ保護モードデータ保護モードビジネスには、絶対にデータを失うことのできない状況があります。別の状況では、データの保護よりデータベースの可用性の方が重要になります。一部のアプリケーションでは、大限のデータベース・パフォーマンスが必要とされ、障害が発生した場合のデータ損失の可能性は許容されます。

現状のビジネス要件に基づいて、次の保護モードのいずれかを選択します。

� 大保護モード大保護モード大保護モード大保護モード : このモードでは、プライマリ・データベースに障害が発生しても、データ損失は起こらないことが保証されます。データ損失を確実に防ぐため、障害により 1 つ以上のリモート・スタンバイ REDO ログに REDO ストリームを書き込むことができない場合、プライマリ・データベースは停止されます。

� 大可用性モード大可用性モード大可用性モード大可用性モード : このモードでは、プライマリ・データベースの可用性に影響を与えない範囲で高レベルのデータ保護が提供されます。

� 大パフォーマンス・モード（デフォルト・モード）大パフォーマンス・モード（デフォルト・モード）大パフォーマンス・モード（デフォルト・モード）大パフォーマンス・モード（デフォルト・モード）: このモードでは、プライマリ・データベースのパフォーマンスに影響を与えない範囲で高レベルのデータ保護が提供されます。このモードでは、トランザクションのリカバリに必要な REDO データがローカルのオンライン REDO ログに書き込まれると、即座にそのトランザクションのコミットが許可されます。

プライマリ・データベースの REDO データ・ストリームは、1 つ以上のスタンバイ・データベースにも書き込まれますが、REDO データを生成するトランザクションのコミットとは同期せずに書き込まれます。十分な帯域幅のあるネットワーク・リンクを使用している場合、このモードでは、プライマリ・データベースのパフォーマンスに対する影響を小限に抑えながら、大可用性モードに匹敵するデータ保護レベルを得ることができます。

現在のアプリケーションに適したデータ保護モードを決定するには、表 2-1 の各質問に回答してください。

関連資料関連資料関連資料関連資料 : データ保護モードとその設定方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。

表表表表 2-1 適切な保護モードの決定適切な保護モードの決定適切な保護モードの決定適切な保護モードの決定

質問質問質問質問推奨事項推奨事項推奨事項推奨事項

プライマリ・サイトの障害時にデータ損失を許容できますか。

はいはいはいはい : 任意の保護モードを使用します。

いいえいいえいいえいいえ : 大保護モードまたは大可用性モードを使用します。

サイトが失われた場合に許容できるデータ損失量はどの程度ですか。

なし（ゼロ損失）なし（ゼロ損失）なし（ゼロ損失）なし（ゼロ損失）: 大保護モードまたは大可用性モードを使用します。

一部許容可一部許容可一部許容可一部許容可 : LGWR ASYNC で大パフォーマンス・モードを使用します。

スタンバイ・ホストまたはネットワーク接続が一時的に使用不可能になった場合、本番データベースとスタンバイ・データベース間のデータ損失の可能性を許容できますか。

はいはいはいはい : 大パフォーマンス・モードまたは大可用性モードを使用します。

いいえいいえいいえいいえ : 大保護モードを使用します。または、複数のスタンバイ・デー

タベースで大可用性モードを使用します。



2.4.3 スタンバイ・データベースの数スタンバイ・データベースの数スタンバイ・データベースの数スタンバイ・データベースの数大保護モードで運用する場合、複数のスタンバイ・データベースの使用を検討してください。大保護モードでは、スタンバイ・ホストまたはネットワーク接続が一時的に使用不可能にな

ると、プライマリ・データベースは、LOG_ARCHIVE_DEST_n初期化パラメータのNET_TIMEOUTパラメータに指定された秒数の間スタンバイ・データベースに接続の再試行を繰り返します。プライマリ・データベースでは、この期間中はゼロ・データ損失が維持されます。この処理が終了すると、プライマリ・データベースは後続のトランザクションに進みます。複数のスタンバイ・データベースを構成することにより、プライマリ・データベースが保護モードの要件を満たす 1 つ以上のスタンバイ・データベースと通信できるようになれば、プライマリ・データベースのトランザクションは中断されることがなくなります。

多くの場合、ロジカル・スタンバイ・データベースは、レポート処理、データ保護およびデータ・リカバリに使用できます。ただし、ロジカル・スタンバイ・データベースのスキーマで、レポート機能を適化するために追加の索引や変更が必要となる場合は、別個のフィジカル・スタンバイ・データベースも用意して、プライマリ・データベースの一貫性のあるコピーを維持することをお薦めします。

複数のスタンバイ・データベースを使用する場合、ネットワーク停止や自然災害によってそれらのスタンバイ・データベースが影響を受けないように、各データベースを地理的に異なる場所でホストすることを検討してください。たとえば、1 つのスタンバイ・データベースはプライマリ・データベースに近い場所でホストし、別のスタンバイ・データベースは遠隔地でホストします。

障害時リカバリ・サイトはプライマリ・サイトからどの程度離れていますか。

サイト間の距離およびネットワーク・インフラストラクチャによってネットワークの待機時間と帯域幅が確定するため、使用可能な保護モードも決定します。一般的に、距離とともに待機時間は増加し、帯域幅は低下しま

す。

待機時間が短く、帯域幅が大きいネットワークでは、大保護モードまたは大可用性モードを使用します。この場合、パフォーマンスへの影響は

小限で、ゼロ・データ損失を実現できます。

待機時間が長いネットワークでは、ASYNC転送で大パフォーマンス・

モードを使用します。この場合、プライマリ・データベースのパフォーマ

ンスへの影響は小限で、ほとんどの状況においてデータ損失を秒単位に制限できます。 SYNC転送で大可用性モードや大保護モードを使用する

ことも可能ですが、COMMITによる追加の待機時間が現在のアプリケー

ション・パフォーマンス要件を超えることがないかどうかを評価する必要があります。状況によっては、レスポンス時間またはスループットのオー

バーヘッドがまったくないか、許容範囲内に収まります。待機時間が長い

ネットワークでも SYNCによる大可用性モードを使用できる例として、

大規模なバッチ・アプリケーションやメッセージ・キューイング・アプリケーションなどがあげられます。

サイト間の現在または将来のネットワーク帯域幅および待機時間はどの程度ですか。

帯域幅は、大の REDO 生成速度を超えている必要があります。双方向通

信のガイドラインは、帯域幅の場合規定のネットワーク容量の 50% です

が、他のアプリケーションによるネットワークの使用も考慮する必要があります。

非同期 REDO 転送またはアーカイバを使用した大パフォーマンス・モー

ドにより、パフォーマンスへの影響を緩和できます。

表表表表 2-1 適切な保護モードの決定（続き）適切な保護モードの決定（続き）適切な保護モードの決定（続き）適切な保護モードの決定（続き）

質問質問質問質問推奨事項推奨事項推奨事項推奨事項



2.4.4 Data Guard の一般構成のベスト・プラクティスの一般構成のベスト・プラクティスの一般構成のベスト・プラクティスの一般構成のベスト・プラクティスこの項では、次のような Data Guard の構成上のベスト・プラクティスについて説明します。

� フェイルオーバー後の迅速な再インスタンス化のためのフラッシュバック・データベースの有効化

� FORCE LOGGING モードの使用

� Data Guard Broker の使用

� 単純で堅牢なアーカイブ計画および構成の使用

� スタンバイ REDO ログの使用と適切なサイズ構成

� パラメータ構成の例

2.4.4.1 フェイルオーバー後の迅速な再インスタンス化のためのフェイルオーバー後の迅速な再インスタンス化のためのフェイルオーバー後の迅速な再インスタンス化のためのフェイルオーバー後の迅速な再インスタンス化のためのフラッシュバック・データベースの有効化フラッシュバック・データベースの有効化フラッシュバック・データベースの有効化フラッシュバック・データベースの有効化フェイルオーバー後に以前のプライマリ・データベースを新しいスタンバイ・データベースとして簡単に復元できるように、プライマリ・データベースとスタンバイ・データベースの両方でフラッシュバック・データベースを有効化します。フラッシュバック・データベースが有効であれば、スイッチオーバー・プロセスで障害が発生した場合でも、そのプロセスを簡単に元に戻すことができます。

2.4.4.2 FORCE LOGGING モードの使用モードの使用モードの使用モードの使用本番データベースを FORCE LOGGINGモードで運用すると、データベースのすべてのデータ変更がログに記録されます。 FORCE LOGGINGモードにより、スタンバイ・データベースと本番データベースとの一貫性が維持されます。 NOLOGGING操作によるロード・パフォーマンスが必要なためにこの設定を使用できない場合は、対応するフィジカル・スタンバイ・データファイルを後で確実に同期する必要があります。フィジカル・スタンバイ・データファイルを同期するには、プライマリ・データベースから作成された増分バックアップを適用するか、NOLOGGING 操作後に取得されたプライマリ・データファイルのバックアップを使用して関連するスタンバイ・データファイルを置き換えます。ファイル転送の前に、フィジカル・スタンバイ・データベースでリカバリを停止する必要があります。

ロジカル・スタンバイ・データベースでは、SQL Apply の処理中に NOLOGGING句付きで実行された操作の REDO レコードが出現すると、そのレコードはスキップされて、それ以降のレコードから変更が適用されます。後で、NOLOGGINGが有効な状態で更新されたいずれかのレコードに対するアクセスが発生すると、「ORA-01403: データが見つかりません。」というエラーが戻されます。 NOLOGGING句の指定後にロジカル・スタンバイ・データベースでリカバリを行うには、『Oracle Data Guard 概要および管理』のロジカル・スタンバイ・データベースでの表の追加または再作成に関する項の説明に従って、プライマリ・データベースから 1 つ以上の表を再作成します。

ALTER DATABASE FORCE LOGGING文を発行すると、強制ロギングを即座に有効化できます。 FORCE LOGGINGを指定した場合、Oracle は、ログに記録されていない進行中のすべての操作が終了するまで待機します。

関連項目関連項目関連項目関連項目 : フラッシュバック・データベース機能の詳細とフラッシュバック・データベースを有効化する方法は、2-11 ページの 2.2.2.3 項「フラッシュバック・データベースの有効化」を参照してください。


� 『Oracle Database 管理者ガイド』

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



2.4.4.3 Data Guard Broker の使用の使用の使用の使用Data Guard 構成の作成、管理および監視には、Data Guard Broker を使用します。 Data Guard Broker を使用することのメリットは、次のとおりです。

� RAC との統合

Data Guard Broker は、データベースのロール変更がスムーズかつシームレスに発生するように CRS と統合されています。このことは、計画的なロール・スイッチオーバーを実行する際に特に有利です（たとえば、フィジカル・スタンバイ・データベースにプライマリ・ロールを引き継がせ、前のプライマリ・データベースにスタンバイ・ロールを割り当てる場合です）。 Data Guard Broker と CRS は、連携してプライマリ・データベースのサービス可用性を一時的に停止し、両方のデータベースの実際のロールを変更します。その間に、CRS は Data Guard Broker とともに必要に応じて適切なインスタンスを再起動し、新しいプライマリ・データベースでサービス可用性を再開します。 Data Guard Broker は基礎となる Data Guard 構成とそのデータベース・ロールを管理し、CRS はそれらのロールに依存するサービス可用性を管理します。サービス可用性の管理を CRS に依存するアプリケーションでは、Data Guard 構成でロール変更が発生したときに一時的にサービスの停止を認識するだけです。

� Data Guard 構成の自動作成

Oracle Enterprise Manager には、次のような Data Guard Broker 構成の作成に伴う複雑なタスクを自動化するウィザードが付属しています。

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

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

– スタンバイ・データベースとの通信の初期化

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

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

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

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

Data Guard Broker では、Oracle Enterprise Manager のボタン・クリック 1 つ、またはDGMGRL コマンドライン・インタフェースの単一のコマンドを使用して、簡単にスイッチオーバーまたはフェイルオーバーを起動できます（このマニュアルでは、これらの操作を手動フェイルオーバーと呼びます）。完全自動管理の場合、ファスト・スタート・フェイルオーバーを有効化して Data Guard Broker にフェイルオーバーが必要であるかどうかの判断を任せ、事前に指定したターゲット・スタンバイ・データベースに対するフェイルオーバーを自動的に起動できます。この場合、DBA による手動操作は必要なく、データ損失も発生しません。

ファスト・スタート・フェイルオーバーを使用すると、手動操作を極力使用せずに可用性を向上し、管理コストを削減できます。手動フェイルオーバーでは、フェイルオーバーの発生時期とターゲット・スタンバイ・データベースを正確に制御できます。どちらの方法を選択しても、Data Guard Broker により、構成内のすべてのデータベースのロール移行が調整されます。



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

Data Guard Broker には、構成内のすべてのデータベース状態を監視する組込みの検証機能があります。任意のデータベースに接続された構成内のシステムから診断情報を取得し、監視、テストおよびパフォーマンス用の一元管理されたツールで大小様々な問題を迅速に検出できます。 Enterprise Manager と DGMGRL の両方で、プライマリ・データベースにおける REDO 転送サービスの進行状況と、スタンバイ・データベースにおける REDO Apply または SQL Apply の進行状況の詳細な構成ビューを取得できます。

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

2.4.4.4 単純で堅牢なアーカイブ計画および構成の使用単純で堅牢なアーカイブ計画および構成の使用単純で堅牢なアーカイブ計画および構成の使用単純で堅牢なアーカイブ計画および構成の使用ここでのアーカイブ計画は、次の前提に基づきます。

� 各データベースでは、フラッシュ・リカバリ領域を使用していること

� 本番インスタンスは、リモートのただ 1 つの適用インスタンスにアーカイブされること

表 2-2 に、SQL*Plus を通じて Data Guard 構成を管理する際の堅牢なアーカイブ計画の推奨事項を示します。 Data Guard Broker で構成を管理する場合、次のすべての項目は自動的に処理されます。

表表表表 2-2 アーカイブの推奨事項アーカイブの推奨事項アーカイブの推奨事項アーカイブの推奨事項

推奨事項推奨事項推奨事項推奨事項説明説明説明説明

プライマリ・データベースでアーカイブを開始する。

スタンバイ・データベースを維持するには、プライマリ・データベースでアーカイブを有効化して開始する必要があります。

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

リモート・アーカイブを有効化する。 REMOTE_ARCHIVE_ENABLE=TRUE

一貫性のあるログ形式（LOG_ARCHIVE_FORMAT）を使用する。

LOG_ARCHIVE_FORMATには、スレッド、順序およびリセットログ ID の

各属性を割り当て、すべてのインスタンスで一貫性のある形式を使用する必要があります。 %Sを指定すると、先行する 0（ゼロ）で順序番号の接頭

辞が埋められます。

フラッシュ・リカバリを使用している場合、この形式は無視されます。

例 : LOG_ARCHIVE_FORMAT=arch_%t_%S_%r.arc

アーカイバ・プロセス（ARCH）により

ローカル・アーカイブを初に実行する。

LOG_ARCHIVE_LOCAL_FIRSTのデフォルト設定は、TRUEです。これに

より、REDO データをローカルの宛先にアーカイブする専用アーカイバ・

プロセスが用意されます。フラッシュ・リカバリ領域を使用している場合

は、ローカル・アーカイブ用として LOG_ARCHIVE_DEST_10が暗黙的に

使用されます。

リモート・アーカイブは、スタンバイRAC データベースごとにただ 1 つのスタ

ンバイ・インスタンスおよびノードに対して実行する。

すべての本番インスタンスは、同じネット・サービス名を使用して 1 つの

スタンバイ宛先にアーカイブします。プライマリ・スタンバイ・インスタ

ンスが停止したときに自動的にセカンダリ・スタンバイ・ホストに切り替える場合、Oracle Net Services の接続時フェイルオーバーを使用します。

フラッシュ・リカバリ領域で ASM またはその他の共有ファイル・システ

ムを使用しているためにすべてのノードからアーカイブにアクセスできる場合、スタンバイ RAC データベースの異なるノード全体にリモート・

アーカイブを分散できます。



次に、フィジカル・スタンバイ・データベースと通信するプライマリ・データベースに推奨される初期化パラメータを示します。大保護モードで稼働する SALES1および SALES2という2 つのインスタンスがあります。

*.DB_RECOVERY_FILE_DEST=+RECO*.LOG_ARCHIVE_DEST_1='SERVICE=SALES stby LGWR SYNC AFFIRM NET_TIMEOUT=30 REOPEN=300 VALID_FOR=(ONLINE_LOGFILES, ALL_ROLES)) DB_UNIQUE_NAME=SALES_stby'*.LOG_ARCHIVE_DEST_STATE_1='ENABLE'

フラッシュ・リカバリ領域は、クラスタ内の任意のノードからアクセス可能である必要があります。また、フラッシュ・リカバリ領域では、自動ストレージ管理（ASM）、クラスタ・ファイル・システム、グローバル・ファイル・システム、高可用性ネットワーク・ファイル・システム（HA NFS）などの共有ファイル・システム・テクノロジを使用する必要があります。クラスタ内の任意のノードに手動でファイル・システムをマウントすることも簡単にできます。すべてのアーカイブ REDO ログ・ファイルにすべてのノードからアクセスできる必要があるため、これはリカバリにとって必須の設定です。

スタンバイ・データベース・ノードでは、スタンバイ適用を現在実行しているノードに障害が発生して再起動できない場合、異なるノードからリカバリする必要があります。この場合、異なるノードに存在する既存のスタンバイ・インスタンスのいずれかを使用して、管理リカバリを開始できます。スタンバイ・アーカイブ REDO ログ・ファイルにアクセスできない場合は、異なるノードの新規管理リカバリ・プロセス（MRP）またはロジカル・スタンバイ・プロセス

（LSP）により、本番ノードからの直接取得を行う FAL サーバーを通じてアーカイブ REDO ログ・ファイルがフェッチされます。

ハードウェア・ベンダーの共有ファイル・システム・テクノロジを構成する場合は、パフォーマンスと可用性に対する影響を確認してください。この計画を採用する前に、次の項目を調査します。

� ノード障害の数にかかわらず、任意のノードから共有ファイル・システムにアクセスできますか。

� 共有ファイル・システムを実装することによるパフォーマンスへの影響はどの程度ですか。

� インターコネクト・トラフィックに対する影響はありませんか。

スタンバイ・アーカイブの宛先にはフラッシュ・リカバリ領域を使用する。

簡略化のため、スタンバイ・アーカイブの宛先（STANDBY_ARCHIVE_DEST）には、ローカル・アーカイブのディレクトリ

と同じフラッシュ・リカバリ領域を使用します。 SRL が存在するため、ス

タンバイ ARCHプロセスによりローカル・アーカイブの宛先に対する書込

みが行われます。

ロジカル・スタンバイ・データベースの場合、フラッシュ・リカバリ領域は STANDBY_ARCHIVE_DESTに使用できません。 STANDBY_ARCHIVE_DESTには、明示的なアーカイブ・ディレクトリを設

定してください。

VALID_FOR属性でロール・ベースの宛先

を指定する。

VALID_FOR属性を使用すると、ロール移行後も Data Guard 構成が適切に

動作するように、1 つのサーバー・パラメータ・ファイル（SPFILE）でプ

ライマリ・データベースとスタンバイ・データベースの両方のロールの宛先属性を構成できます。これにより、ロール移行後にロール固有のパラ

メータ・ファイルの有効化と無効化を切り替える必要がなくなるため、スイッチオーバーやフェイルオーバーの処理が簡単になります。

関連項目関連項目関連項目関連項目 : 付録 A「データベース SPFILE および Oracle Net 構成ファイル

のサンプル」

表表表表 2-2 アーカイブの推奨事項（続き）アーカイブの推奨事項（続き）アーカイブの推奨事項（続き）アーカイブの推奨事項（続き）

推奨事項推奨事項推奨事項推奨事項説明説明説明説明



2.4.4.5 スタンバイスタンバイスタンバイスタンバイ REDO ログの使用と適切なサイズ構成ログの使用と適切なサイズ構成ログの使用と適切なサイズ構成ログの使用と適切なサイズ構成スタンバイ REDO ログ（SRL）は、可用性とパフォーマンスを向上するために両方のサイトで使用する必要があります。 SRL の数を決定するには、次の式を使用します。

SRL の数 = スレッドごとのすべての本番オンライン・ログ・グループの合計数 + スレッド数

たとえば、プライマリ・データベースに 2 つのインスタンス（スレッド）があり、スレッドごとに 4 つのオンライン・ログ・グループがある場合、必要な SRL の数は 10 になります。スレッドごとのスタンバイ・ログ・グループの数を本番データベースのオンライン REDO ログ・グループの数より 1 つ増やすと、スタンバイで SRL を割り当てられないために本番インスタンスの LGWR がブロックされる可能性を減らすことができます。

SRL を作成する際の追加のガイドラインは、次のとおりです。

� 本番データベースとスタンバイ・データベースの両方で、同じ数の SRL を作成します。

� 本番データベースとスタンバイ・データベースの両方で、すべてのオンライン REDO ログと SRL のサイズを同じにします。

� SRL は、本番データベースとスタンバイ・データベースの両方に存在している必要があります。

� SRL は、ASM または外部冗長性を通じて保護されたデータ領域に作成される必要があります。

� RAC 環境では、SRL は共有ディスクに配置される必要があります。

� RAC 環境では、SRL の作成時にその SRL をスレッドに割り当てます。

2.4.4.6 パラメータ構成の例パラメータ構成の例パラメータ構成の例パラメータ構成の例SPFILE のサンプルや Oracle Net 構成ファイルを含むパラメータ設定の詳細な例は、付録 A「データベース SPFILE および Oracle Net 構成ファイルのサンプル」を参照してください。

2.4.5 REDO 転送サービスのベスト・プラクティス転送サービスのベスト・プラクティス転送サービスのベスト・プラクティス転送サービスのベスト・プラクティスこの項では、Data Guard の REDO 転送サービスを計画および実装するためのベスト・プラクティスについて説明します。


� ネットワーク構成案に関するパフォーマンス評価の実行

� プライマリ・データベース・スループットのベスト・プラクティス

� ネットワーク構成と大ネットワーク REDO 速度のベスト・プラクティス

2.4.5.1 ネットワーク構成案に関するパフォーマンス評価の実行ネットワーク構成案に関するパフォーマンス評価の実行ネットワーク構成案に関するパフォーマンス評価の実行ネットワーク構成案に関するパフォーマンス評価の実行ネットワーク構成案と現在（または将来）のピーク REDO 速度に関するパフォーマンス評価を実行することをお薦めします。本番データベースとスタンバイ・データベース間のネットワークに対する影響と、プライマリ・データベースのスループットに対する影響を把握する必要があります。本番データベースとスタンバイ・データベース間のネットワークは 2 つのデータベースの同期を維持するのに不可欠の要素であるため、そのインフラストラクチャは次の特徴を有している必要があります。

� 大の REDO 生成速度に対応できる十分な帯域幅

� 本番データベースへのパフォーマンス上の影響を抑える小限の待機時間

� ネットワーク冗長性のための複数のネットワーク・パス

専用ネットワーク接続に必要な帯域幅は、本番データベースの大 REDO 速度と実際のネットワーク効率により決定されます。データ保護モードによっては、他の推奨プラクティスとパフォーマンス上の考慮事項があります。大保護モードと大可用性モードでは、LGWR SYNC転送を使用する必要があります。大パフォーマンス保護モードでは、ASYNC転送オプションまたはアーカイバ（ARCHn）を使用します。



大保護モードまたは大可用性モード（LGWR SYNCによる運用）と、大パフォーマンス・モード（LGWR ASYNCによる運用）を比較する場合、発生する待機時間を原因としてパフォーマンスまたはスループットが低下するかどうかを測定します。また、新規のスループットまたはレスポンス時間が、アプリケーションのパフォーマンス要件の範囲内であるかどうかをチェックします。距離とネットワーク構成は、待機時間に直接影響します。待機時間が長いと、潜在的なトランザクション・スループットが低下し、レスポンス時間が増大する可能性があります。ネットワーク構成、リピータの数、プロトコル変換のオーバーヘッド、およびルーターの数も、ネットワーク待機時間とトランザクション・レスポンス時間に全体的な影響を与えます。

2.4.5.2 プライマリ・データベース・スループットのベスト・プラクティスプライマリ・データベース・スループットのベスト・プラクティスプライマリ・データベース・スループットのベスト・プラクティスプライマリ・データベース・スループットのベスト・プラクティスLGWR SYNC属性を使用してスタンバイ・データベースに REDO を送信する場合、プライマリ・データベースのトランザクションは、そのトランザクションに関連する REDO がローカルとリモートの両方に書き込まれるまでフォアグラウンド・プロセスにコミット完了を戻しません。 LGWR SYNC使用時のコミット時間は、スタンバイ・データベースの I/O 容量以外に、ネットワークの待機時間と帯域幅に直接的な影響を受けます。合計コミット時間は、プライマリ・データベースのローカル書込み（ログ・ファイル・パラレル書込み）時間と、SENDREQでのLNS 待機イベントによる所要時間（ネットワーク時間 + スタンバイ書込み（スタンバイ・データベースの V$SYSTEM_EVENTビューから取得される RFS 書込み） + ネットワーク確認応答）で構成されます。ただし、プライマリ・データベースに対する影響の程度は、アプリケーション・プロファイルに応じて変化します。一般的に、不定期のコミットを伴うバッチ更新と、メッセージ・キューイング・アプリケーションでは、目立った違いはありません。

LGWR ASYNC属性を使用してスタンバイ・データベースに REDO を送信する場合、ASYNCによる REDO 転送の実際の非同期的な動作により、プライマリ・データベースのスループットに対する影響は小限に抑えられます。さらに、ネットワーク待機時間が増加しても、プライマリ・データベースのスループット（1 秒当たりの REDO バイト）にはほとんど影響がありません。 ASYNC属性付きの場合、ログ・ライター・プロセスがローカルのオンライン REDO ログ・ファイルに書込みを行う一方で、（宛先ごとに 1 つ存在する）LGWRネットワーク・サーバー

（LNSn）・プロセスがオンライン REDO ログから REDO を読み取り、それをリモート宛先に非同期的に転送します。 LGWRプロセスは、LNS のネットワーク I/O が完了するのを待機せずにリクエストの処理を続けます。 REDO 転送サービスが複数のリモート宛先に REDO データを送信する場合、LNSnプロセスは、すべての宛先に対するネットワーク I/O をパラレルに開始します。

関連項目関連項目関連項目関連項目 : 2-25 ページの 2.4.2 項「データ保護モード」



図 2-3 は、オンライン REDO ログ・ファイルから REDO データを収集し、そのデータを Oracle Net を介してスタンバイ・データベースの RFS プロセスに転送する LNSnプロセスを示しています。

図図図図 2-3 ネットワーク・サーバー（ネットワーク・サーバー（ネットワーク・サーバー（ネットワーク・サーバー（LNSn）・プロセスによる）・プロセスによる）・プロセスによる）・プロセスによる LGWR ASYNC アーカイブアーカイブアーカイブアーカイブ

ARCHプロセスによって処理されるリモート宛先については、ネットワーク・リソースをより効率的に使用する目的で、複数のストリームを使用するようリモート転送を構成できます。複数のストリームを構成するには、LOG_ARCHIVE_DEST_n初期化パラメータのMAX_CONNECTIONS属性に 1より大きい値を設定します。この値により、リモート・アーカイブの実行に使用されるネットワーク接続の大数が決定されます。大値は、リモート宛先ごとに 5 つのストリームです。

複数のストリームで使用されるネットワーク接続は、ARCHプロセスによって実行されるため、LOG_ARCHIVE_MAX_PROCESSES初期化パラメータを設定する場合は注意してください。 LOG_ARCHIVE_MAX_PROCESSESおよび PARALLEL_MAX_SERVERS初期化パラメータの値は、すべてのリモート宛先に MAX_CONNECTIONSで指定した合計数より少なくとも 1 大きくする必要があります。

関連資料関連資料関連資料関連資料 :『Oracle Data Guard 概要および管理』

OracleNet

LGWRLGWR

ARCnARCn

RFS



2.4.5.3 ネットワーク構成と最大ネットワークネットワーク構成と最大ネットワークネットワーク構成と最大ネットワークネットワーク構成と最大ネットワークREDO 速度のベスト・プラクティス速度のベスト・プラクティス速度のベスト・プラクティス速度のベスト・プラクティス次の各項には、ネットワーク構成と大ネットワーク REDO 速度のベスト・プラクティスが含まれます。

� TCP 送信 / 受信バッファ・サイズの適切な構成

� SDU サイズの増加

� TCP.NODELAY が YES であることの確認

� PARALLEL_MAX_SERVERS の増加

� LGWR ASYNC による追加のディスク I/O の考慮

2.4.5.3.1 TCP 送信送信送信送信 / 受信バッファ・サイズの適切な構成受信バッファ・サイズの適切な構成受信バッファ・サイズの適切な構成受信バッファ・サイズの適切な構成 TCP の送信および受信ソケット・バッファ・サイズを、プライマリ・システムとスタンバイ・システム間のネットワーク・リンクの帯域幅遅延積（BDP）の 2 倍に設定します。 BDP は、ネットワーク帯域幅と待機時間の積です。ソケット・バッファ・サイズは、Oracle Net パラメータの RECV_BUF_SIZEとSEND_BUF_SIZEを使用して設定するため、ソケット・バッファ・サイズの設定は Oracle TCP接続にのみ有効です。ソケット・バッファ・サイズがオペレーティング・システムにより制限されている場合、Oracle でより大きい値を使用できるよう調整する必要があります。たとえば、Linux では、net.core.rmem_maxおよび net.core.wmem_maxパラメータでソケット・バッファ・サイズを制限しているため、これらのパラメータに RECV_BUF_SIZEとSEND_BUF_SIZEより大きい値を設定する必要があります。

たとえば、帯域幅が 622M ビットで待機時間が 30 ミリ秒の場合、RECV_BUF_SIZEとSEND_BUF_SIZEを次のように設定します。

RECV_BUF_SIZE= SEND_BUF_SIZE= 2 x 622,000,000 / 8 x 0.030 = 4,665,000 バイト

2.4.5.3.2 SDU サイズの増加サイズの増加サイズの増加サイズの増加 Oracle Net Services では、セッション・データ・ユニット（SDU）に関する Oracle Net 設定を調整することでデータ転送を制御できます。 SDU を大値の 32767に設定すると、パフォーマンスが向上する可能性があります。 SDU では、Oracle Net バッファのサイズを指定します。このバッファは、ネットワーク転送のためにデータを TCP ネットワーク・レイヤーに配信する前に、それらのデータを収集するために使用されます。オラクル社による Oracle Data Guard の内部テストでは、大設定の 32767 で高のパフォーマンスを発揮しました。パフォーマンス向上の理由は、Oracle Net バッファからオペレーティング・システムの TCP ネットワーク・レイヤーにデータを渡す際に要求されるシステム・コールの数が減少するためです。 SDU は、ローカル・ネーミング構成ファイル（tnsnames.ora）およびリスナー構成ファイル（listener.ora）の SDUパラメータで接続単位ごとに設定するか、sqlnet.oraファイルの DEFAULT_SDU_SIZEプロファイル・パラメータですべての Oracle Net 接続を対象に設定します。

関連資料関連資料関連資料関連資料 :『Primary Site and Network Configuration Best Practices』（http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm）


� SDUおよび DEFAULT_SDU_SIZEパラメータの詳細は、『Oracle Database Net Services リファレンス』を参照してください。

� 『Primary Site and Network Configuration Best Practices』（http://otn.oracle.com/deploy/availability/htdocs/maa.htm）



2.4.5.3.3 TCP.NODELAY がががが YES であることの確認であることの確認であることの確認であることの確認 TCP プロトコル・スタックでのバッファ・フラッシングによる遅延を回避するため、プライマリ・システムとスタンバイ・システムの両方で SQLNET.ORAファイルの TCP.NODELAYを YESに設定して TCP Nagle アルゴリズムを無効化します。

2.4.5.3.4 PARALLEL_MAX_SERVERS の増加の増加の増加の増加 LOG_ARCHIVE_DEST_n初期化パラメータのMAX_CONNECTIONS属性設定に対応するため、PARALLEL_MAX_SERVERS初期化パラメータを増やします。 LOG_ARCHIVE_MAX_PROCESSESおよび PARALLEL_MAX_SERVERS初期化パラメータは、MAX_CONNECTIONS属性に関連しており、インスタンスで使用される ARCnプロセスの実際の数に影響を与えます。たとえば、すべての宛先の MAX_CONNECTIONS属性で指定された合計接続数が LOG_ARCHIVE_MAX_PROCESSESの値を超えている場合、Data Guard では可能なかぎり多くの ARCnプロセスが使用されますが、その接続数は MAX_CONNECTIONSで指定された数より少なくなる可能性があります。

2.4.5.3.5 LGWR ASYNC による追加のディスクによる追加のディスクによる追加のディスクによる追加のディスク I/O の考慮の考慮の考慮の考慮 LGWR ASYNCでの REDO 転送の有効化による追加の読取り I/O 操作を考慮して、十分な I/O 帯域幅を確保します。 LOG_ARCHIVE_DEST_n初期化パラメータで LGWRおよび ASYNC属性を指定すると、ログ・ライター・プロセスは、ローカルのオンライン REDO ログ・ファイルに書込みを行いますが、Oracle Database 10g リリース 1（10.1）のように ASYNCバッファに追加書込みを行うことはありません。 Oracle Database 10g リリース 2（10.2）では、LGWRがオンライン・ログへの書込みを完了すると、LNSnプロセスがオンライン REDO ログから変更ベクトルを読み取って REDOをスタンバイ・データベースに転送します。この新しい方法では、LGWRプロセスの書込みが、LNSnのネットワーク書込みから完全に分離しています。以前のリリースとは異なり、LNS プロセスはオンライン REDO ログに対してディスク読取りを実行するため、十分なディスク I/O 帯域幅があることを確認する必要があります。

2.4.6 ログ適用サービスのベスト・プラクティスログ適用サービスのベスト・プラクティスログ適用サービスのベスト・プラクティスログ適用サービスのベスト・プラクティスこの項では、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースにおける Data Guard ログ適用サービスのベスト・プラクティスについて説明します。


� フィジカル・スタンバイ・データベースにおける REDO Apply のベスト・プラクティス

� ロジカル・スタンバイ・データベースにおける SQL Apply のベスト・プラクティス

2.4.6.1 フィジカル・スタンバイ・データベースにおけるフィジカル・スタンバイ・データベースにおけるフィジカル・スタンバイ・データベースにおけるフィジカル・スタンバイ・データベースにおける REDO Apply ののののベスト・プラクティスベスト・プラクティスベスト・プラクティスベスト・プラクティスフィジカル・スタンバイ・データベースに Oracle Data Guard の REDO Apply を使用するか、任意のメディア・リカバリ操作を効率的に実行するには、次のベスト・プラクティスに従ってデータベース・リカバリをチューニングする必要があります。

1. スタンバイ REDO ログとアーカイブ REDO ログの I/O レートを大化します。

スタンバイ REDO ログ・ディレクトリとアーカイブ REDO ログ・ディレクトリの I/Oレートを測定します。転送された REDO がスタンバイ・データベースに同時に書き込まれると、I/O が飽和状態となって REDO 読取り速度が低下する可能性があります。リカバリ速度全体は REDO を読み取ることのできる速度によって常に制限されるため、REDO 読取り速度が必要とされるリカバリ速度を超えていることを確認します。

2. リカバリ速度を評価します。

リカバリ速度の履歴を取得するには、次の問合せを使用してリカバリ進行状況の履歴を表示します。

SELECT * FROM V$RECOVERY_PROGRESS;

ACTIVE APPLY RATEがプライマリ・データベースでの大 REDO 生成速度を超えているか、プライマリ・データベースでの平均生成速度の 2 倍を超えている場合、チューニング

関連資料関連資料関連資料関連資料 : TCP.NODELAYパラメータの詳細は、『Oracle Database Net Services リファレンス』を参照してください。



は必要ありません。それ以外の場合は、次のチューニング・ヒントに従ってください。プライマリ・データベースの REDO 生成速度は、Grid Control で監視するか、REDO SIZE統計の AWR レポートから抽出することが可能です。 CHECKPOINT TIME PER LOGが 10 秒を超えている場合は、I/O とチェックポイントのチューニングを調査します。

3. DB_BLOCK_CHECKINGおよび DB_BLOCK_CHECKSUMのデフォルトを使用します。

DB_BLOCK_CHECKINGのデフォルト設定は、OFFです。 DB_BLOCK_CHECKINGを FULLに設定すると、リカバリ速度が低下する可能性があります。ブロック・チェックは、プライマリ・データベースでは常に推奨されます。スタンバイ・データベースでは、リカバリ速度が期待どおりであれば有効化できます。

DB_BLOCK_CHECKSUMのデフォルト設定は、TYPICALです。ブロック・チェックサムは、プライマリ・データベースとスタンバイ・データベースの両方で常に有効化する必要があります。これにより、ごくわずかなオーバーヘッドが発生しますが、ほとんどのブロック破損を検出できます。

4. PARALLEL_EXECUTION_MESSAGE_SIZE = 4096 と設定します。

このパラメータを 4096 に増加すると、デフォルト設定の 2152 より 20% ほどリカバリ速度が向上する可能性があります。メッセージ・サイズ・パラメータは、パラレル問合せ操作で使用されるため、この増加をサポートするのに十分な共有プールが存在する必要があります。

5. DB_CACHE_SIZEを、プライマリ・データベースの同じパラメータより大きい値に設定します。 DB_KEEP_CACHE_SIZEと DB_RECYCLE_CACHE_SIZEを 0に設定します。

データベース・キャッシュ・サイズを大きくすると、物理データ・ブロックの読取り量が減少するため、メディア・リカバリのパフォーマンスが向上する可能性があります。メディア・リカバリでは、DB_KEEP_CACHE_SIZEや DB_RECYCLE_CACHE_SIZEを必要としないか、または大きいサイズの SHARED_POOL_SIZEを必要としないため、DB_CACHE_SIZEにメモリーを再度割り当てることができます。

これらのパラメータは、スタンバイ・データベースをプライマリ・データベースに変換する前に、プライマリ・データベースの設定にリセットしてください。

6. データベース待機を評価します。

スタンバイ・データベースの V$SYSTEM_EVENTS、V$SESSION_WAITSおよびV$EVENT_HISTOGRAMを問い合せて、大の TIME_WAITED値を調べることで、上位のシステムおよびセッション待機イベントを特定できます。場合によっては、ある一定期間を正確に評価するため、問合せ結果の複数のスナップショットを取得して手動で差異を抽出する必要があります。ただし、フィジカル・スタンバイ・データベースには、AWR レポートに相当する機能はありません。

リカバリで多くの REDO を効率的に適用する場合、システムは I/O バウンドとなるため、I/O 待機が発生することはシステムにとって妥当な動作です。次の表に、監視対象となる上位のリカバリ関連の待機と、各待機タイプに適したチューニング・ヒントを示します。チューニング・ヒントは、リカバリ・イベントが上位 10 番目以内の待機に含まれる場合にのみ適用してください。

待機名待機名待機名待機名説明説明説明説明チューニング・ヒントチューニング・ヒントチューニング・ヒントチューニング・ヒント

log file sequential read

コーディネータ（リカバリ・セッションまたは MRP プロセス）によ

るログ・ファイル読取り I/O の待

機

ログ読取り I/O をチューニングし

ます。

px deq: par recov reply

コーディネータによるスレーブの同期待機（チェックポイントの待機）

データファイル書込み I/O の

チューニング、DBWR プロセスの

増加、プライマリおよびスタンバイ REDO ログ・サイズの増加を行

います。

px deq credit: send blkd

コーディネータによるスレーブのストリーム待機（適用の待機）

PARALLEL_EXECUTION_MESSAGE_SIZEを 8192 に増加します。



7. I/O 操作をチューニングします。

DBWR では、変更されたブロックをバッファ・キャッシュからデータファイルに書き出す必要があります。 DISK_ASYNCH_IOを TRUEに設定して（デフォルト）、ネイティブの非同期 I/O を常に使用します。めったにないことですが、非同期 I/O が使用できない場合は、DBWR_IO_SLAVESを使用すると同期 I/O で有効なデータ・ブロック書込み速度を向上できます。

基本的な I/O テストの実行、プライマリ・データベースとの I/O 統計の比較、またはいくつかの I/O 履歴メトリックの調査により、十分な I/O 帯域幅が確保されており、I/O レスポンス時間が現在のシステムにとって適切であることを確認します。 Storage Area Network

（SAN）や Network Attached Storage（NAS）などの同じストレージ・インフラストラクチャを多くのアプリケーションで共有している場合、I/O レスポンス時間は変化する可能性があることに注意してください。

8. システム・リソースを評価します。

UNIX の sarや vmstatなどのシステム・コマンド、またはシステム・モニタリング・ツールを使用してシステム・リソースを評価します。あるいは、Enterprise Manager、AWR レポート、または V$SYSTEM_EVENT、V$ASM_DISK、V$OSSTATなどのパフォーマンス・ビューを参照します。

a. I/O ボトルネックや過剰な待機 I/O 操作が存在する場合、I/O 容量を増加させている操作またはアプリケーションの変更を調査します。長い待機時間の原因が不十分なI/O 帯域幅にある場合、関連する ASM ディスク・グループに別のディスクを追加します。この原因がバスやコントローラのボトルネック、またはその他の I/O ボトルネックではないことを確認します。スタンバイ REDO ログからの読取り I/O は、期待されるリカバリ速度を超えている必要があります。

b. 過剰なスワッピングまたはメモリー・ページングが発生していないかどうかをチェックします。

c. リカバリ中にリカバリ・コーディネータまたは MRP が CPU バウンド状態にならないことを確認します。

free buffer waits

フォアグラウンド・プロセスによるバッファ・キャッシュ内の使用可能な空きバッファの待機

DB_CACHE_SIZEを増加し、KEEPまたは RECYCLE POOL設定を削除

します。

recovery read データ・ブロック読取りの待機データファイル読取り I/O を

チューニングします。

direct path read

コーディネータによるログ境界チェックポイントでのファイル・ヘッダー読取りの待機

データファイル読取り I/O を


direct path write

コーディネータによるログ境界チェックポイントでのファイル・ヘッダー書込みの待機

データファイル書込み I/O を


checkpoint completed（シリ

アル・リカバリのみ）

チェックポイント完了の待機データファイル書込み I/O を


DBWR プロセスの数を増加します。

db file parallel read（シリアル・リカバリのみ）

データ・ブロック読取りの待機ファイル読取り I/O をチューニン

グします。

待機名待機名待機名待機名説明説明説明説明チューニング・ヒントチューニング・ヒントチューニング・ヒントチューニング・ヒント



9. プライマリ・データベースとスタンバイ・データベースのログ・グループ・サイズを増加します。

プライマリ・データベースのオンライン REDO ログ・サイズとスタンバイ・データベースのスタンバイ REDO ログ・サイズを低 1GB に増加します。 Oracle データベースは、メディア・リカバリ中にログ・ファイル境界ごとに（適化された方法で）完全チェックポイント処理を実行し、すべてのファイル・ヘッダーを更新します。データベースの完全チェックポイント処理とすべてのファイル・ヘッダー更新の頻度を抑制するには、ログ・スイッチが低 15 分間隔で発生するようログ・グループ・サイズを増加します。

リアルタイム適用を使用しており、LGWR プロセスを通じて同期的または非同期的にREDO が送信される場合、この変更によりデータ損失リスクが増大することはありません。アーカイバで REDO を送信している場合、または負荷が高いためにプライマリ・データベースを ARCH モードに変更している場合、リカバリ速度の向上によるデータ損失リスクの増大に適切に対処する必要があります。

REDO グループ・サイズを非常に大きくした場合でも、プライマリ・データベースのクラッシュ・リカバリ時間を小限に抑えるために、FAST_START_MTTR_TARGETに 0（ゼロ）以外の値を設定してファスト・スタート・リカバリを有効化します。現在設定されていない場合は、3600 に設定します。この初期化パラメータは、プライマリ・データベースにのみ有効です。

10. 異なるリカバリ並列度を評価します。

パラレル・リカバリは、使用可能な CPU の数に設定されたデフォルトの並列度に基づいて、メディア・リカバリとクラッシュ・リカバリに対してデフォルトで有効化されています。ほとんどの場合、これが適な設定となります。ただし、一部の環境では、デフォルトとは異なる（多いかまたは少ない）並列度を使用した方がリカバリ速度が向上します。デフォルト設定を上書きするには、次のように明示的に並列度を指定します。

RECOVER MANAGED STANDBY DATABASE PARALLEL <#>;

2.4.6.2 ロジカル・スタンバイ・データベースにおけるロジカル・スタンバイ・データベースにおけるロジカル・スタンバイ・データベースにおけるロジカル・スタンバイ・データベースにおける SQL Apply ののののベスト・プラクティスベスト・プラクティスベスト・プラクティスベスト・プラクティスこの項では、Data Guard SQL Apply とロジカル・スタンバイ・データベースの推奨事項について説明します。


� MAX_SERVERS 初期化パラメータの設定

� PARALLEL_MAX_SERVERS 初期化パラメータの増加

� PRESERVE_COMMIT_ORDER 初期化パラメータの設定

� 不必要なオブジェクトでの SQL Apply のスキップ

� LOG_AUTO_DELETE SQL Apply パラメータの設定

2.4.6.2.1 MAX_SERVERS 初期化パラメータの設定初期化パラメータの設定初期化パラメータの設定初期化パラメータの設定ロジカル・スタンバイ・データベースをレポート・システムまたは意思決定支援システムとして使用する場合、その操作用のパラレル問合せスレーブを確保するために MAX_SERVERS初期化パラメータの値を増加します。 SQL Apply プロセスは、デフォルトですべてのパラレル問合せスレーブを使用するため、次の等式のように MAX_SERVERSパラメータを設定し、特定の数のパラレル問合せスレーブを確保します。

MAX_SERVERS = <current MAX_SERVERS setting> + <PQ Slaves needed for reporting and decision-support operations>

初期設定では、MAX_SERVERSパラメータを 9 または 3 + (3 x CPU) のいずれか大きい方の値に設定することをお薦めします。

関連資料関連資料関連資料関連資料 :『Oracle Database 10g Release 2 Best Practices: Data Guard Redo Apply and Media Recovery』

（http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm）



2.4.6.2.2 PARALLEL_MAX_SERVERS 初期化パラメータの増加初期化パラメータの増加初期化パラメータの増加初期化パラメータの増加現在の設定を MAX_SERVERプロセスに合せて調整していない場合、次のようにプライマリ・データベース・インスタンスとスタンバイ・データベース・インスタンスの MAX_SERVERS初期化パラメータの値に基づいて、PARALLEL_MAX_SERVERS初期化パラメータの値を増加します。

PARALLEL_MAX_SERVERS = 現在の値 + MAX_SERVERS の値

2.4.6.2.3 PRESERVE_COMMIT_ORDER 初期化パラメータの設定初期化パラメータの設定初期化パラメータの設定初期化パラメータの設定レポート・システムまたは意思決定支援システムでは、スタンバイ・データベースがプライマリ・データベースより遅れている場合を除き、PRESERVE_COMMIT_ORDERを TRUEに設定する必要があります。 SQL Apply でスタンバイ・データベースがプライマリ・データベースに追い付くまでは、一時的にPRESERVE_COMMIT_ORDERを FALSEに設定しますが、ギャップの解消後はこのパラメータをTRUEに再設定します。

2.4.6.2.4 不必要なオブジェクトでの不必要なオブジェクトでの不必要なオブジェクトでの不必要なオブジェクトでの SQL Apply のスキップのスキップのスキップのスキップスタンバイ・データベースにレプリケートする必要のないデータベース・オブジェクトは、DBMS_LOGSTDBY.SKIPプロシージャを使用してスキップする必要があります。このようなオブジェクトをスキップすることで、SQL Apply の処理を軽減できます。

2.4.6.2.5 LOG_AUTO_DELETE SQL Apply パラメータの設定パラメータの設定パラメータの設定パラメータの設定 DBMS_LOGSTDBY.APPLY_SETプロシージャを実行して、LOG_AUTO_DELETE SQL Apply パラメータを設定します。 LOG_AUTO_DELETEパラメータにより、プライマリ・データベースから送信されたアーカイブREDO ログ・ファイルを SQL Apply でロジカル・スタンバイ・データベースに適用した後に、それらのアーカイブ REDO ログ・ファイルを自動的に削除するかどうかを制御できます。アーカイブ REDO ログ・ファイルの自動削除を有効化するには、このパラメータを TRUEに設定します。自動削除を無効化するには、FALSEに設定します。デフォルト値は、TRUEです。

LOG_AUTO_DELETEパラメータを FALSEに設定している場合、DBMS_LOGSTDBY.PURGE_SESSIONプロシージャを使用して手動でアーカイブ REDO ログ・ファイルを削除できます。

2.4.7 ロール移行のベスト・プラクティスロール移行のベスト・プラクティスロール移行のベスト・プラクティスロール移行のベスト・プラクティス適切な計画と実行に基づいた Data Guard のロール移行により、効果的に停止時間を小化し、ビジネスへの影響を小限に抑えながらデータベース環境をリストアすることが可能になります。フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースのどちらを使用するかにかかわらず、MAA のテスト結果では、Oracle Data Guard 10g リリース 2によるスイッチオーバーとフェイルオーバーの時間は数秒間に短縮されました。この項では、スイッチオーバーとフェイルオーバーのベスト・プラクティスについて説明します。


� スイッチオーバー時のロール移行

� フェイルオーバー時のロール移行

関連資料関連資料関連資料関連資料 : DBMS_LOGSTDBY PL/SQL パッケージの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』および『Oracle Data Guard 概要および管理』を参照してください。



2.4.7.1 スイッチオーバー時のロール移行スイッチオーバー時のロール移行スイッチオーバー時のロール移行スイッチオーバー時のロール移行Oracle Data Guard により実行されるデータベース・スイッチオーバーは、スタンバイ・データベースと本番データベースの間でロールを切り替えるための一連の手順を含む計画された移行操作です。スイッチオーバー操作に成功すると、スタンバイ・データベースが本番ロールを引き継ぎ、本番データベースがスタンバイ・データベースとなります。 RAC 環境のスイッチオーバーでは、本番用とスタンバイ用のデータベースごとにただ 1 つのインスタンスがアクティブである必要があります。

データベースのロール管理の分野では、スイッチバックという用語も使用されることがあります。スイッチバックは、スイッチオーバー操作の後にデータベースのロールを元の状態に戻す操作です。

Data Guard では、次の方法により動的にロールを変更できます。

� Oracle Enterprise Manager の使用（4-23 ページの 4.2.3.2.1 項「Enterprise Manager を使用した Data Guard スイッチオーバーの実行」を参照）

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

� SQL 文の発行（4-25 ページから始まる 4.2.3.2.2 項「SQL を使用したフィジカル・スタンバイ・データベースへの Data Guard スイッチオーバー」および 4.2.3.2.3 項「SQL を使用したロジカル・スタンバイ・データベースへの Data Guard スイッチオーバー」を参照）

2.4.7.1.1 スイッチオーバーのベスト・プラクティススイッチオーバーのベスト・プラクティススイッチオーバーのベスト・プラクティススイッチオーバーのベスト・プラクティススイッチオーバー処理を適化するには、次のベスト・プラクティスを使用してください。また、次の場所から入手できるホワイト・ペーパー『Oracle Database 10g Release 2 Best Practices: Data Guard Switchover and Failover』を参照してください。

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_SwitchoverFailoverBestPractices.pdf

� ロジカル・スタンバイ・データベースの場合 :

– 適な SQL Apply 速度を確認する方法の詳細は、http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmの『Oracle Database 10g Release 2 Best Practices: Data Guard SQL Apply』を参照してください。

– プライマリ・データベースの V$DATABASE固定ビューの SWITCHOVER_STATUS列を問い合せて、LogMiner のマルチバージョン・データ・ディクショナリがプライマリ・データベースに受信されたことを確認します。問合せにより TO LOGICAL STANDBYという値が戻された場合、スイッチオーバー操作を継続できます。詳細は、『Oracle Data Guard 概要および管理』のロジカル・スタンバイ・データベースが関与するスイッチオーバーに関する項を参照してください。

� フィジカル・スタンバイ・データベースの場合 :

– 適な REDO Apply 速度を確認する方法の詳細は、http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmの『Oracle Database 10g Release 1 Best Practices: Data Guard Redo Apply and Media Recovery』を参照してください。

– 読取り専用モードから REDO Apply（リカバリ）モードに移行する場合、データベースを再起動します。

� 受信と同時に REDO データがスタンバイ・データベースに適用されるようリアルタイム適用を使用します。

フィジカル・スタンバイ・データベースでリアルタイム適用を有効化するには、次の SQL文を使用します。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT USING CURRENT LOGFILE;

関連資料関連資料関連資料関連資料 : Enterprise Manager または Data Guard Broker コマンドラインを使用してデータベース・スイッチオーバーを実行する方法の詳細は、

『Oracle Data Guard Broker』を参照してください。



ロジカル・スタンバイ・データベースでリアルタイム適用を有効化するには、次の SQL 文を使用します。

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

� スイッチオーバー中に障害が発生してもプロセスを簡単に元に戻せるように、フラッシュバック・データベースを有効化します。

2.4.7.2 フェイルオーバー時のロール移行フェイルオーバー時のロール移行フェイルオーバー時のロール移行フェイルオーバー時のロール移行フェイルオーバーは、あるサイトの本番データベースをオフラインにし、スタンバイ・データベースの 1 つを新規本番データベースとしてオンラインにする操作です。フェイルオーバー操作は、本番データベースに壊滅的な障害が発生し、一定の時間内にそのデータベースをリカバリできない場合に起動します。

Data Guard のフェイルオーバー・プロセスは、ファスト・スタート・フェイルオーバー機能を使用して完全自動で実行するか、ユーザーが手動で起動します。ファスト・スタート・フェイルオーバーでは、手動操作を必要とするプロセスに固有の不確実性を排除できます。この機能を使用すると、システム停止が検出されてから数秒以内にゼロ・データ損失のフェイルオーバーを自動的に実行できます。

通常は、ファスト・スタート・フェイルオーバーを使用することをお薦めします。 Oracle Database 10g リリース 2（10.2）の稼働する環境で行った初期の MAA テストでは、Data Guard Broker とファスト・スタート・フェイルオーバーを使用したフェイルオーバーの実行により、可用性が大幅に向上しました。

手動フェイルオーバーでは、ユーザーの決定に基づくフェイルオーバー・プロセスが可能になります。手動フェイルオーバーは、次の方法で実行できます。

� SQL 文の発行（4-21 ページの 4.2.2.2.2 項「SQL を使用したフィジカル・スタンバイ・データベースへのフェイルオーバー」を参照）

� Oracle Enterprise Manager の使用（4-18 ページの 4.2.2.2.1 項「Enterprise Manager を使用した Data Guard フェイルオーバーの実行」を参照）

� Oracle Data Guard Broker コマンドライン・インタフェース（DGMGRL）の使用


� ファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較

� ファスト・スタート・フェイルオーバーのベスト・プラクティス

� 手動フェイルオーバーのベスト・プラクティス

関連資料関連資料関連資料関連資料 : Oracle フェイルオーバーのベスト・プラクティスの総合レビューは、http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmの『Oracle Database 10g Release 2 Best Practices: Data Guard Fast-Start Failover』を参照してください。

関連資料関連資料関連資料関連資料 : Enterprise Manager または Data Guard Broker コマンドラインを使用してデータベース・フェイルオーバーを実行する方法の詳細は、




2.4.7.2.1 ファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較ファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較ファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較ファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較ファスト・スタート・フェイルオーバーは、Data Guard Broker 構成でのみ使用できます。この機能は、DGMGRL か、または Oracle Enterprise Manager の Data Guard 管理ページを通じてのみ構成できます。ファスト・スタート・フェイルオーバーでは、REDO 転送サービスを LGWR SYNCで構成する必要があります。また、正式に保証されたゼロ・データ損失のフェイルオーバーを実現するには、Data Guard 構成を大可用性モードに設定する必要があります。さらに、プライマリ・データベースとスタンバイ・データベースでは、フラッシュバック・データベースを有効化する必要があります。有効化されたファスト・スタート・フェイルオーバー機能により、Data Guard 構成が監視され、指定のターゲット・スタンバイ・データベースに自動的にフェイルオーバーが開始されます。このとき、DBA による手動操作は必要なく、データ損失も発生しません。

ファスト・スタート・フェイルオーバーが起動されるのは、次の場合です。

� データベース・インスタンス（または RAC 構成の後のインスタンス）に障害が発生した場合

� 異常終了した場合（または RAC 構成の後のインスタンスが異常終了した場合）

� I/O エラーのためにデータファイルがオフラインになった場合

� オブザーバ（ファスト・スタート・フェイルオーバーの監視プロセス）とスタンバイ・データベースの両方がプライマリ・データベースに対するネットワーク接続を失い、同期状態にあることをスタンバイ・データベースが確認した場合

ファスト・スタート・フェイルオーバーの後、構成に対する再接続時に、以前のプライマリ・データベースは自動的に新しいスタンバイ・データベースとして再構成されます。これにより、Data Guard では、障害保護の構成を迅速かつ容易にリストアし、データベースを可能なかぎり早く保護状態に戻すことができます。

Data Guard の手動フェイルオーバーは、スタンバイ・データベースを本番データベースに変換するための一連の手順です。スタンバイ・データベースは、原則として本番データベースのロールを引き継ぎます。 Data Guard フェイルオーバーは、ユーザーを新規プライマリ・データベースにフェイルオーバーするアプリケーション・フェイルオーバーにより実行されます。フェイルオーバー後、以前の本番データベースは、弾力性を回復するために新規スタンバイ・データベースとして再作成する必要があります。スタンバイ・データベースは、フラッシュバック・データベースを使用して迅速に再作成できます。 4-53 ページの 4.3.2 項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。

2.4.7.2.2 ファスト・スタート・フェイルオーバーのベスト・プラクティスファスト・スタート・フェイルオーバーのベスト・プラクティスファスト・スタート・フェイルオーバーのベスト・プラクティスファスト・スタート・フェイルオーバーのベスト・プラクティスファスト・スタート・フェイルオーバーのベスト・プラクティスは、次のとおりです。

� 受信と同時に REDO データがスタンバイ・データベースに適用されるようリアルタイム適用を使用します。

� 論理障害から保護するためにフラッシュバック・データベースを有効化します。

� ファスト・スタート・フェイルオーバーのオブザーバ・プロセスは、プライマリ・データベースまたはスタンバイ・データベースとは別の場所にあるデータ・センターのホストで実行します。

オブザーバは、プライマリ・データベースおよびスタンバイ・データベースから等距離の場所にあるシステムで実行するのが理想的です。オブザーバは、任意のエンド・ユーザー・クライアントと同じネットワークを使用してこれら 2 つのデータベースに接続する必要があります。指定したオブザーバに障害が発生した場合、Enterprise Manager で検出して自動的にオブザーバを再起動するよう構成できます。第 3 のサイトで実行できない場合は、オブザーバをアプリケーションと同じネットワークにインストールする必要があります。

� スタンバイ・データベースが読取り専用モードでオープンされている場合、REDO Applyを開始する前にデータベースを再起動します。

� フェイルオーバー後もデータ保護を維持するために、複数のスタンバイ・データベースを構成することを検討します。

関連資料関連資料関連資料関連資料 : フェイルオーバー操作の詳細は、『Oracle Data Guard Broker』を参照してください。



� 現在の構成上の特性に従って、FastStartFailoverThresholdプロパティの値を表 2-3のとおりに設定します。

表 2-3 のどの設定を使用する場合でもテストを実行して、ファスト・スタート・フェイルオーバーのしきい値が、間違ってフェイルオーバーが起動されるほど極端に小さくないか、またはフェイルオーバー要件を満たさないほど大きくないかどうかを確認してください。

2.4.7.2.3 手動フェイルオーバーのベスト・プラクティス手動フェイルオーバーのベスト・プラクティス手動フェイルオーバーのベスト・プラクティス手動フェイルオーバーのベスト・プラクティスユーザーが起動する手動フェイルオーバーは、緊急時にのみ使用し、次のような計画外の停止が発生した場合に開始する必要があります。

� プライマリ・データベースが使用不可能となるサイト障害

� 一定の時間内に修復できないユーザー・エラー

� 広範囲の破損を含む、本番アプリケーションに影響を及ぼすデータ障害

フェイルオーバーでは、以前の本番データベースをスタンバイ・データベースとして復元し、現在の環境にフォルト・トレランスを回復する必要があります。スタンバイ・データベースは、フラッシュバック・データベースを使用して迅速に復元できます。 4-53 ページの 4.3.2 項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。

フェイルオーバー処理を適化して高可用性を維持するには、次のベスト・プラクティスを使用します。

� フェイルオーバー操作の完了後にデータベースを復元するため、フラッシュバック・データベースを有効化します。

� ユーザー・エラーや論理破損が検出されたときに、受信と同時に REDO データをスタンバイ・データベースに適用してデータベースを迅速に復元するため、フラッシュバック・データベースと組み合せてリアルタイム適用を使用します。

� ロジカル・スタンバイ・データベースに適な SQL Apply 速度を確認する方法の詳細は、http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmの『Oracle Database 10g Release 2 Best Practices: Data Guard SQL Apply』を参照してください。

表表表表 2-3 FastStartFailoverThreshold の最小値の推奨設定の最小値の推奨設定の最小値の推奨設定の最小値の推奨設定

構成構成構成構成最小値の推奨設定最小値の推奨設定最小値の推奨設定最小値の推奨設定

単一インスタンスのプライマリ、短い待機時間、信頼性の高いネットワーク

15 秒

単一インスタンスのプライマリ、WAN を介した待機時間の長いネット

ワーク

30 秒

RAC のプライマリ再構成時間 + 30 秒 1

1 リリース 10.2.0.3 より前の Oracle データベース・ソフトウェアを実行する構成では、RAC ミスカウント + 再構成時間 + 30 秒を小値として使用します。


� FastStartFailoverThreshold プロパティの詳細は、『Oracle Data Guard Broker』を参照してください。

� 『Oracle Database 10g Release 2 Best Practices: Data Guard Switchover and Failover』（http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm）



� フィジカル・スタンバイ・データベースの場合 :

– http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmの『Oracle Database 10g Release 1 Best Practices: Data Guard Redo Apply and Media Recovery』を参照してください。

– （以前のリリースで要求されたように）スタンバイ・データベースを再起動するのではなく、MOUNTED状態から OPEN状態に直接移行します。

� 読取り専用モードから REDO Apply（リカバリ）モードに移行する場合、データベースを再起動します。

2.4.8 クローンとしてのフィジカル・スタンバイ・データベースの管理クローンとしてのフィジカル・スタンバイ・データベースの管理クローンとしてのフィジカル・スタンバイ・データベースの管理クローンとしてのフィジカル・スタンバイ・データベースの管理Data Guard、リストア・ポイントおよび Recovery Manager を組み合せることで、REDO Apply（フィジカル）スタンバイ・データベースを読取り / 書込みクローン・データベースとして、テスト、レポート、開発向けに、またはクローン・テクノロジにより現在の組織内で実現できるその他の用途向けに一時的に使用できます。

スタンバイ・データベースをクローンとして使用する際に検討に値する推奨事項は、次のとおりです。

� この方法のパフォーマンスを評価します。

この方法を使用したクローン・データベースの管理を評価する場合、クローン・データベースがどの程度プライマリ・データベースとは異なって変化するかを考慮したうえで、クローン・データベースをリフレッシュするのに必要な時間を測定します。頻繁に使用され、プライマリ・データベースとは大幅に異なる（各データベース間のデータ・ブロック変更の合計が 15% を超える）クローン・データベースは、RMAN DUPLICATEを実行してディスク・バックアップからデータベース全体をコピーした方が迅速に同期できます。

また、十分な I/O リソースが使用可能であることを確認してください。クローン・データベースに加えられた変更をフラッシュバックし、増分バックアップを適用してプライマリ・データベースと同期するプロセスは、I/O 集中型の操作です。

� 障害保護のために別個のスタンバイ・データベースを使用します。

スタンバイ・データベースがクローンとしてアクティブになると、プライマリ・データベースからの REDO データの受信が停止し、障害保護を提供できなくなります。フィジカル・スタンバイ・データベースのアクティブ化中も障害保護を提供するため、Data Guard構成で稼働するスタンバイ・データベースを複数用意して、スタンバイ・データベースの1 つがアクティブになってもプライマリ・データベースの保護を継続する必要があります。 2 番目のスタンバイ・データベースを使用することで、クローン・データベースのアクティブ化中も、引き続き Data Guard 構成を大保護モードまたは大可用性モードで運用できます。

� プライマリ・データベースでブロック変更トラッキングを有効化します。

ブロック変更トラッキングを有効化すると、プライマリ・データベースの INCREMENTAL FROM SCNバックアップをより迅速に作成できます。このバックアップは、プライマリ・データベースで発生したすべての変更を、内容の異なるクローン・データベースに適用する場合に使用します。ブロック変更トラッキングを有効化する方法の詳細は、『Oracle Database バックアップおよびリカバリ基礎』を参照してください。

� 増分バックアップの作成と適用に RMAN のパラレル化を使用します。

プライマリ・データベースの INCREMENTAL FROM SCNバックアップを作成および適用する場合、作成時間と適用時間を節約するために RMAN のパラレル化を使用します。 RMAN のパラレル化の詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

� プライマリの増分バックアップとフラッシュバック・クローンを同時に作成します。

同期時間全体を節約するため、クローン・データベースを初期リストア・ポイントにフラッシュバックするときに、同時にプライマリ・データベースから増分バックアップを作成します。



スタンバイ・データベースをクローンとして使用するには、障害保護に使用されていないフィジカル・スタンバイ・データベースを特定します。次の項では、各フェーズの概要についてリストします。スタンバイ・データベースをクローンとして使用する方法の詳細は、『Oracle Data Guard 概要および管理』を参照してください。

フェーズフェーズフェーズフェーズ 1: フィジカル・スタンバイ・データベースのクローンとしてのアクティブ化フィジカル・スタンバイ・データベースのクローンとしてのアクティブ化フィジカル・スタンバイ・データベースのクローンとしてのアクティブ化フィジカル・スタンバイ・データベースのクローンとしてのアクティブ化

1. アクティブ化するフィジカル・スタンバイ・データベースを準備します。

2. フィジカル・スタンバイ・データベースを分離するプライマリ・データベースを準備します。

3. フィジカル・スタンバイ・データベースをアクティブ化します（プライマリ・データベースから分離します）。

4. アクティブ化したクローン・データベースをテストに使用します。

フェーズフェーズフェーズフェーズ 2: フィジカル・スタンバイ・データベースに戻すためのクローンの再同期フィジカル・スタンバイ・データベースに戻すためのクローンの再同期フィジカル・スタンバイ・データベースに戻すためのクローンの再同期フィジカル・スタンバイ・データベースに戻すためのクローンの再同期

1. アクティブ化したデータベースをフラッシュバックしてフィジカル・スタンバイ・データベースに戻します。

2. スタンバイ・データベースを現在のプライマリ・データベースと同期します。

2.4.9 データベース以外のデータを保護するための推奨事項データベース以外のデータを保護するための推奨事項データベース以外のデータを保護するための推奨事項データベース以外のデータを保護するための推奨事項高可用性環境では、データベース以外のファイルもデータベース・ファイルとともに保護する必要があります。 Oracle Secure Backup は、UNIX、Linux、Windows、Network Attached Storage などの異機種環境にデータ保護を提供します。また、障害時リカバリ目的では、複数のサード・パーティ・ツールを使用してローカル・ファイルとリモート・ファイルのセット間でリモート同期を実行できます。たとえば、リモート同期用として rsync、csync2、DRDBなどのツールを使用できます。これらのツールは、インターネットからダウンロードできます。これらのツールに関する推奨事項は、次のとおりです。

� ソフトウェアの更新用としては、プライマリ・システムのソフトウェアの変更とスタンバイ・システムを同期するために rsyncを使用します。

� 構成ファイル用としては、rsyncを毎日または更新後に使用するか、csync2を使用します。

� 重要なログ・ファイル、トレース・ファイルまたはデバッグ・ファイル用としては、rsyncを毎日または 1 時間ごとに使用するか、ファイル・システム全体を同期するためにDRDBを使用します。

� データベースと同期する必要のあるトランザクション・ログまたはメタデータ・ファイル用としては、rsyncまたは csync2を頻繁に使用するか、DRDB、サード・パーティ製のミラー化ユーティリティ、リモート同期ツールなどのブロック同期ツールを使用します。

関連資料関連資料関連資料関連資料 :『Oracle Secure Backup 管理者ガイド』



2.4.10 Data Guard のパフォーマンスの評価のパフォーマンスの評価のパフォーマンスの評価のパフォーマンスの評価Data Guard スタンバイ・データベースの追加後におけるプライマリ・データベースのパフォーマンスを正確に評価するには、同じアプリケーション・プロファイルおよび負荷を伴う Data Guard の配置前後に、V$SYSMETRIC_SUMMARYビューまたは自動ワークロード・リポジトリ

（AWR）のスナップショットから統計履歴を取得します。

アプリケーション・プロファイルは、次の統計を比較することで迅速に評価できます。

� 1 トランザクション当たりの物理読取り

� 1 トランザクション当たりの物理書込み

� 1 トランザクション当たりの CPU 使用率

� 1 トランザクション当たりの REDO 生成

アプリケーション・パフォーマンスは、次の統計を比較することで迅速に評価できます。

� 1 秒当たりの REDO 生成（または REDO 速度）

� 1 秒当たりのユーザー・コミット（または 1 秒当たりのトランザクション）

� 1 秒当たりのデータベース処理時間

� 1 トランザクション当たりのレスポンス時間

� SQL サービス・レスポンス時間

アプリケーション・プロファイルが 2 つの使用例で変化していると、正確に比較できません。『Oracle Database パフォーマンス・チューニング・ガイド』に記載された一般的な原則に従って、データベースまたはシステムでテストとチューニングを繰り返してください。

アプリケーション・プロファイルがほぼ同じ状態で、プライマリ・データベースのアプリケーション・パフォーマンスにスループットの低下やレスポンス時間の増大が認められる場合、次の一般的な問題領域を確認します。

� CPU 使用率

システム負荷が高い場合（90% を超える過剰な CPU 使用率、ページングおよびスワッピング）、Data Guard での操作を続ける前にシステムをチューニングする必要があります。オペレーティング・システムの使用統計を監視するには、V$OSSTATまたはV$SYSMETRIC_HISTORYビューを使用します。

� I/O 待機の増加

LGWRおよび DBWRの I/O 待機が増加すると、I/O の低下によりスループットとレスポンス時間が影響を受けます。これは、次の待機イベントの履歴データを参照することで確認できます。

– ログ・ファイル・パラレル書込み

– ログ・ファイル順次読取り

– ログ・ファイル・パラレル読取り

– データファイル・パラレル書込み

– データファイル順次読取り

LGWR SYNC転送では、より多くのコミット時間を必要とします。これは、フォアグラウンド・プロセスが LGWRからコミット完了の確認応答を受信する前に、スタンバイ・データベースでREDO が使用可能であることを保証する必要があるためです。 LGWRのコミットには、次の待機イベントが含まれます。

� ログ・ファイル・パラレル書込み（LGWRのローカル書込み）



� SENDREQでの LGWRの待機

この待機イベントには、次の時間が含まれます。

– パケットをネットワークに送信する時間

– パケットをスタンバイ・データベースに送信する時間

– スタンバイ REDO ログに RFS 書込みまたはスタンバイ書込みを行う時間（RFS の I/O待機イベントとチェックサムのための追加オーバーヘッドを含む）

– プライマリ・データベースにネットワーク確認応答を送信する時間（シングル・トリップの待機時間など）

LGWR（ログ・ライター）によるコミット時間の増加は、特に小規模な時間依存型のトランザクションにおいて、レスポンス時間の増加とスループット低下の原因となる場合があります。ただし、LGWRのローカル書込み（ログ・ファイル・パラレル書込み待機イベント）、またはSENDREQでの LGWR待機の異なる構成要素をチューニングすることで、これらの問題を十分に改善できる可能性があります。

ディスク書込み I/O（ログ・ファイル・パラレル書込みまたは RFS I/O）は、より多くのスピンドルを追加するか、I/O 帯域幅を増加することでチューニングできます。ネットワーク時間は、Oracle Net の送信および受信バッファ・サイズのチューニング、SDU=32Kの設定、および飽和状態にあるネットワーク帯域幅の増加を通じて削減できます。また、より近い場所にサイトを設定することで、ネットワーク待機時間を削減できる可能性があります。

LNSn ASYNC転送や ARCH転送の場合、LGWRは、LNSn または ARCHが現在のログ・ファイルにコミット・レコードを書き込むまで待機することはありません。ただし、LNSn とアーカイバ・プロセスは両方ともオンライン REDO ログを読み取るため、より多くの I/O 競合が発生し、状況によっては LGWR書込み（ログ・ファイル・パラレル書込み）の待機時間が増加します。 I/O 帯域幅と十分なスピンドルが割り当てられていない場合、ログ・ファイル・パラレル書込みおよびログ・ファイル順次読取りによる待機が増加し、スループットやレスポンス時間に影響を与える可能性があります。通常は、十分なスピンドルを追加することで I/O 待機時間を削減できます。

注意注意注意注意 : 新しい統計収集機能とアドバイザの大部分を有効化するには、STATISTICS_LEVEL初期化パラメータを TYPICAL（推奨）または ALLに設定します。


� 一般的なパフォーマンス・チューニングおよびトラブルシューティングのベスト・プラクティスは、『Oracle Database パフォーマンス・チューニング・ガイド』を参照してください。

� LGWR SYNCおよび LGWR ASYNC転送コンポーネントのチューニングの詳細は、『Oracle 10g Data Guard: Primary Site and Network Configuration Best Practices』を参照してください。このホワイト・ペーパーは、http://www.oracle.com/technology/deploy/availability/htdocs/maa.htmからダウンロードできます。


バックアップとリカバリの構成

2.5 バックアップとリカバリの構成バックアップとリカバリの構成バックアップとリカバリの構成バックアップとリカバリの構成すべてのデータベースに適切なバックアップを用意する一方で、バックアップおよびリカバリ計画の設計時に目標リカバリ時間（RTO）と目標リカバリ時点（RPO）を検討してください。リカバリの多くにはバックアップのリストア操作が含まれますが、Oracle では、データベース停止からのリカバリ時間を小限に抑えるための他のデータベース機能も提供されます（Data Guard やフラッシュバック・テクノロジなど）。

この項では、データベース・バックアップを適切に管理するためのベスト・プラクティスと、利用可能な Oracle データベース機能を通じて使用できるその他のバックアップ・オプションとバックアップ計画について説明します。


� Oracle のデータベース機能および製品の使用

– Recovery Manager を使用したデータベース・ファイルのバックアップ

– Oracle Secure Backup の使用

– リストア・ポイントの使用

� 構成と管理

– バックアップを使用する状況の理解

– バックアップ頻度の決定

– RMAN リカバリ・カタログの使用

– 増分バックアップ用のブロック変更トラッキングの有効化

– 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップの有効化

� ディスクへのバックアップ

– ディスク・バックアップ方法の決定

– NOCATALOG モードとその後の RESYNC CATALOG によるバックアップの作成

– ディスク上のフラッシュ・リカバリ領域へのデータベース・バックアップの作成

– すべてのサイトでのフラッシュ・リカバリ領域へのバックアップ（Data Guard 環境の場合）

� テープへのバックアップ

– フラッシュ・リカバリ領域からのテープ・バックアップの作成

– オフサイト・バックアップの管理

� バックアップとリカバリのメンテナンス

– データベース・ファイルの破損の定期的なチェック

– リカバリ手順の定期的なテスト

– リカバリ・カタログ・データベースの定期的なバックアップ



2.5.1 Oracle のデータベース機能および製品の使用のデータベース機能および製品の使用のデータベース機能および製品の使用のデータベース機能および製品の使用Oracle には、バックアップとリカバリの操作を容易にする複数のデータベース機能および製品が含まれます（Recovery Manager（RMAN）、Oracle Secure Backup、フラッシュ・リカバリ領域、フラッシュバック・データベース、リストア・ポイントなど）。


� Recovery Manager を使用したデータベース・ファイルのバックアップ

� Oracle Secure Backup の使用

� リストア・ポイントの使用

2.5.1.1 Recovery Manager を使用したデータベース・ファイルのバックアップを使用したデータベース・ファイルのバックアップを使用したデータベース・ファイルのバックアップを使用したデータベース・ファイルのバックアップRecovery Manager（RMAN）は、Oracle データベースのバックアップとリカバリに使用できる Oracle のユーティリティです。 RMAN は、データベースと緊密に統合されているため、バックアップに必要なファイルを自動的に判別できます。また、より重要な機能として、RMAN では、メディア・リカバリ操作でリストアする必要のあるファイルを認識できます。 RMAN では、サーバー・セッションを使用してバックアップおよびリカバリ操作を実行し、バックアップに関するメタデータをリポジトリに格納します。 RMAN には、一般的なユーザー管理バックアップの方法と比べて有利な点が多くあります。たとえば、次のようなメリットがあります。

� 表領域をバックアップ・モードにする必要のないオンライン・データベース・バックアップ

� 増分バックアップ

� バックアップおよびリストア操作中のデータ・ブロック整合性チェック

� 操作を実際に実行しないテスト・バックアップおよびリストア

RMAN により、バックアップとリカバリは自動化されます。ユーザー管理バックアップでは、各データファイルのバックアップ場所を探し、それらをオペレーティング・システムのコマンドを使用して正しい場所にコピーしてから、適用するログを選択する必要があります。 RMANでは、これらのタスクを自動で管理できます。

RMAN を使用している場合にのみ利用可能な Oracle バックアップおよびリカバリの機能（表領域の自動ポイント・イン・タイム・リカバリやブロック・メディア・リカバリなど）もあります。

2.5.1.2 Oracle Secure Backup の使用の使用の使用の使用Oracle Secure Backup は、UNIX、Linux、Windows、Network Attached Storage（NAS）などの異機種環境にデータ保護を提供します。 Oracle Secure Backup により、次のような Oracle 環境全体でテープ・データ保護機能を使用できます。

� Oracle データベース（RMAN との統合を通じて）

� Oracle Real Application Clusters（RAC）のシームレスなサポート

� 次のような分散サーバーのファイル・システム・データ保護

– Oracle Application Server

– Oracle Collaboration Suite

– Oracle ホームおよびバイナリ

RMAN と Oracle Secure Backup の組合せにより、エンドツーエンドのテープ・バックアップ・ソリューションが提供されるため、サード・パーティ製のバックアップ・ソフトウェアを使用する必要がなくなります。

関連資料関連資料関連資料関連資料 : Oracle Secure Backup の Web サイト（http://www.oracle.com/database/secure-backup.html）



2.5.1.3 リストア・ポイントの使用リストア・ポイントの使用リストア・ポイントの使用リストア・ポイントの使用Oracle リストア・ポイントは、データベース・メンテナンス時のリスクの高い結合操作における論理障害を防ぐために使用できます。通常のリストア・ポイントを作成すると、特定の時点または SCN にリストア・ポイント名が割り当てられます。リストア・ポイント名は、フラッシュバック表操作とフラッシュバック・データベース操作で使用できます。フラッシュバック・データベース操作でデータベースを確実にリストア・ポイントに戻す場合は、リストア・ポイントを保証することが可能です。

保証付きリストア・ポイントは、データベース全体を対象とするメンテナンス（データベースまたはアプリケーションのアップグレードや、バッチ・プロセスの実行など）に推奨されます。保証付きリストア・ポイントにより、フラッシュバック・データベースが有効化され、データベースをそのリストア・ポイントにフラッシュバックするのに必要なすべてのフラッシュバック・ログが保持されます。メンテナンス・アクティビティの完了後に結果を検証したら、不要な保証付きリストア・ポイントは削除する必要があります。

2.5.2 構成と管理構成と管理構成と管理構成と管理この項には、次の各項目が含まれます。

� バックアップを使用する状況の理解

� バックアップ頻度の決定

� RMAN リカバリ・カタログの使用

� 増分バックアップ用のブロック変更トラッキングの有効化

� 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップの有効化

2.5.2.1 バックアップを使用する状況の理解バックアップを使用する状況の理解バックアップを使用する状況の理解バックアップを使用する状況の理解本番データベースの計画外の停止を解決するためにバックアップを使用すると、目標リカバリ時間（RTO）または SLA の要件を満たすことができない場合があります。たとえば、一部の停止は、フラッシュバック・データベースまたはスタンバイ・データベースを使用することでも効果的に対処できます。ただし、次のようにデータベース・バックアップを使用することが必要な状況もあります。

� Data Guard 環境の初期設定

� ファイルまたはブロック・メディア・リカバリを使用したデータ障害からのリカバリ

� 二重障害の解決

Data Guard 環境の初期設定環境の初期設定環境の初期設定環境の初期設定スタンバイ・データベースの初期設定時には、セカンダリ・サイトで初期スタンバイ・データベースを作成するために本番データベースのバックアップが必要です。

ファイルまたはブロック・メディア・リカバリを使用したデータ障害からのリカバリファイルまたはブロック・メディア・リカバリを使用したデータ障害からのリカバリファイルまたはブロック・メディア・リカバリを使用したデータ障害からのリカバリファイルまたはブロック・メディア・リカバリを使用したデータ障害からのリカバリ Data Guard のない環境でブロック破損、メディア障害、またはその他のデータ障害が発生した場合、唯一のリカバリ方法は、既存のバックアップを使用することです。

関連資料関連資料関連資料関連資料 : フラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。


� Data Guard 設定の詳細は、『Oracle Data Guard 概要および管理』を参照してください。

� バックアップ計画の詳細は、『Oracle Database バックアップおよびリカバリ基礎』を参照してください。



二重障害の解決二重障害の解決二重障害の解決二重障害の解決二重障害の状況では、本番データベースとスタンバイ・データベースの両方の可用性が影響を受けます。二重障害の例は、セカンダリ・サイトが停止してフォルト・トレランスが失われ、それに続いて本番データベースでメディア障害が発生した場合です。この状況を解決する唯一の方法は、使用可能なバックアップから本番データベースを再作成し、次にスタンバイ・データベースを再作成することです。

プライマリ・サイトの停止に続いてセカンダリ・サイトが停止するなど、複数の障害（より適切に言えば、災害）が発生した場合、オフサイトにのみ存在するバックアップを使用する必要があります。したがって、壊滅的な状況下でサービスを再開するには、オフサイトにバックアップ・テープを配布して管理するためのプロセスを開発し、そのプロセスに準拠する必要があります。

2.5.2.2 バックアップ頻度の決定バックアップ頻度の決定バックアップ頻度の決定バックアップ頻度の決定バックアップ頻度ポリシーを決定して、定期的にバックアップを実行することは重要です。バックアップ保存ポリシーは、必要なデータがすぐに破棄されないことを保証するのに役立ちます。

バックアップ頻度を決定する要因バックアップ頻度を決定する要因バックアップ頻度を決定する要因バックアップ頻度を決定する要因頻繁なバックアップは、すべてのリカバリ・スキームにとって不可欠です。バックアップ頻度は、Data Guard またはフラッシュバック・テクノロジで解決できない停止に対処する際の目標リカバリ時間の見積りに基づいて決定します。修復時間は、リストア時間とリカバリ時間の合計に基づきます。バックアップの頻度と場所は、これら 2 つの要因に影響を与えます。データファイルのバックアップ頻度に影響する他の要因は、次のようなデータベース変更の割合または頻度です。

� 表の追加と削除

� 既存の表を対象とする行の挿入と削除

� 表のデータの更新

データベースのバックアップとリカバリを簡略化するため、推奨バックアップ計画では、フラッシュ・リカバリ領域を導入し、増分バックアップ機能と更新増分バックアップ機能を使用します。推奨計画の詳細は、『Oracle Database 2 日でデータベース管理者』の推奨バックアップ計画の使用に関する項を参照してください。

バックアップ保存ポリシーの確定バックアップ保存ポリシーの確定バックアップ保存ポリシーの確定バックアップ保存ポリシーの確定バックアップ保存ポリシーは、リカバリなどの要件を満たすために（ディスクまたは他のバックアップ・メディアに）保存する必要のあるバックアップに関するルール・セットです。特定のバックアップは、より新しいバックアップで置換できるほど古いか、テープに保存済であるという理由から、安全に削除することが可能です。また、特定のバックアップは、アーカイブ要件などの他の理由により、ディスクに保存する必要があります。バックアップ保存ポリシーを満たすために必要でなくなったバックアップは、不要なバックアップとなります。

バックアップ保存ポリシーは、冗長性またはリカバリ・ウィンドウを基準とします。冗長性ベースの保存ポリシーでは、データベース内の各ファイルの個別バックアップを少なくともn 個常に保持するように、n という数を指定します。リカバリ・ウィンドウ・ベースの保存ポリシーでは、過去の時間間隔（1 週間や 1 か月など）を指定して、その期間内の任意の時点に対してポイント・イン・タイム・リカバリを実行するのに必要なすべてのバックアップを保持します。

長期バックアップの保持長期バックアップの保持長期バックアップの保持長期バックアップの保持一部のビジネスでは、将来の数年間にわたり必要とされる長期バックアップを保持する機能が要求されます。 RMAN で KEEPオプションを使用すると、保存ポリシーとは関係なく無期限にバックアップを保存して、希望する時点を対象にデータベースをリストアおよびリカバリできます。領域不足のためにバックアップ・メタデータが失われることのないように、RMAN リポジトリにリカバリ・カタログを使用することは重要です（RMANリポジトリにターゲット・データベースの制御ファイルを使用すると、領域不足が発生する可能性があります）。



2.5.2.3 RMAN リカバリ・カタログの使用リカバリ・カタログの使用リカバリ・カタログの使用リカバリ・カタログの使用RMAN では、バックアップ対象のデータベースの制御ファイルでバックアップ・メタデータが自動的に管理されます。バックアップ・メタデータを長期にわたり保護および維持する場合、別個のデータベースに RMAN リポジトリを作成できます。このリポジトリは、通常、リカバリ・カタログと呼ばれます。リカバリ・カタログを使用することによるメリットは、次のとおりです。

� バックアップ情報の長期保存

� 複数のデータベースのメタデータの保存

� 別のシステムへの使用可能バックアップのリストア

リカバリ・カタログを使用するもう 1 つの理由は、ターゲット・データベースの制御ファイルに大サイズの制限があるためです。制御ファイルのサイズが小さすぎて追加のバックアップ・メタデータを保持できなくなると、既存のバックアップ情報は上書きされるため、それらのバックアップを使用してリストアとリカバリを行うことは困難になります。

2.5.2.4 増分バックアップ用のブロック変更トラッキングの有効化増分バックアップ用のブロック変更トラッキングの有効化増分バックアップ用のブロック変更トラッキングの有効化増分バックアップ用のブロック変更トラッキングの有効化Oracle Database 10g には、増分バックアップ用の変更トラッキング機能があります。この機能により、各データファイルの変更済ブロックを変更トラッキング・ファイルに記録することで、増分バックアップのパフォーマンスを向上できます。変更トラッキングが有効化されると、RMAN では、変更トラッキング・ファイルを使用して増分バックアップの変更済ブロックを特定します。これにより、データファイルのすべてのブロックをスキャンする必要がなくなるため、バックアップ中のディスク読取り数が減少します。

2.5.2.5 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップの有効化の有効化の有効化の有効化RMAN を構成して、制御ファイルのデータベース構造メタデータが変更された場合、またはバックアップ・レコードが追加された場合に制御ファイルとサーバー・パラメータ・ファイル

（SPFILE）を自動的にバックアップできます。自動バックアップにより、RMAN では、現在の制御ファイル、カタログおよび SPFILE が失われた場合でもデータベースをリカバリできます。 RMAN の自動バックアップ機能は、CONFIGURE CONTROLFILE AUTOBACKUP ON文を使用して有効化します。

関連資料関連資料関連資料関連資料 : RMAN リポジトリの詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

関連資料関連資料関連資料関連資料 : ブロック変更トラッキングの詳細は、『Oracle Database バックアップおよびリカバリ基礎』を参照してください。

関連資料関連資料関連資料関連資料 : 自動バックアップの詳細は、『Oracle Database バックアップおよびリカバリ基礎』を参照してください。



2.5.3 ディスクへのバックアップディスクへのバックアップディスクへのバックアップディスクへのバックアップこの項には、次の各項目が含まれます。

� ディスク・バックアップ方法の決定

� NOCATALOG モードとその後の RESYNC CATALOG によるバックアップの作成

� ディスク上のフラッシュ・リカバリ領域へのデータベース・バックアップの作成

� すべてのサイトでのフラッシュ・リカバリ領域へのバックアップ（Data Guard 環境の場合）

2.5.3.1 ディスク・バックアップ方法の決定ディスク・バックアップ方法の決定ディスク・バックアップ方法の決定ディスク・バックアップ方法の決定バックアップ・メカニズムを選択する場合、次の優先項目を参考にバックアップ計画を決定してください。

� バックアップ時間全体

� プライマリへの影響

� バックアップによる使用領域

� リカバリ時間

表 2-4 では、環境ごとに異なる優先項目に対応する様々なバックアップの選択肢を比較しています。この表を参考に、現在の特定のビジネス要件に適なバックアップ方法を選択してください。リカバリ時間を犠牲にする一方で、バックアップ領域を小化することが可能です。または、領域を考慮せずに、リカバリ時間とバックアップ時間を優先することも可能です。

リカバリ時間を最適化するためのベスト・プラクティスリカバリ時間を最適化するためのベスト・プラクティスリカバリ時間を最適化するためのベスト・プラクティスリカバリ時間を最適化するためのベスト・プラクティスリストア時間が主な検討課題の場合、データベース・コピーか、または即時ロールフォワードを実行する増分バックアップを実行します。即座に使用できるデータベースのバックアップを提供するのはこれら 2 つのオプションのみであり、後のバックアップ以降に作成されたアーカイブ・ログを使用することで、障害発生時点までリカバリできます。

領域使用量を最小化するためのベスト・プラクティス領域使用量を最小化するためのベスト・プラクティス領域使用量を最小化するためのベスト・プラクティス領域使用量を最小化するためのベスト・プラクティス領域使用量が主な検討課題の場合、遅延ロールフォワードを実行する増分バックアップを実行します。累積レベル 1 の増分バックアップを実行すると、後のレベル 0 のバックアップ以降に変更されたブロックのみが保存されます。累積増分バックアップでは、後のレベル 1 のバックアップのみをレベル 0 のバックアップに適用する必要があります。差分増分バックアップでは、レベル 1 のすべてのバックアップをレベル 0 のバックアップに適用する必要があります。初めのうち、累積増分バックアップは、差分増分バックアップより多くの領域をフラッシュ・リカバリ領域で使用します。ただし、時間の経過につれて、累積増分バックアップによる使用領域は減少します。

表表表表 2-4 バックアップ・オプションの比較バックアップ・オプションの比較バックアップ・オプションの比較バックアップ・オプションの比較

バックアップ・オプションバックアップ・オプションバックアップ・オプションバックアップ・オプションバックアップバックアップバックアップバックアップ時間全体時間全体時間全体時間全体

プライマリプライマリプライマリプライマリへの影響への影響への影響への影響

バックアップにバックアップにバックアップにバックアップによる使用領域よる使用領域よる使用領域よる使用領域リカバリ時間リカバリ時間リカバリ時間リカバリ時間

全体データファイル・コピー速い大きい多いも速い

全体バックアップ・セットより速い大きいより少ないも遅い

増分バックアップ（即時ロール

フォワード）

より速い小さい多いも速い

増分バックアップ（リカバリまで

ロールフォワードを遅延）

も速い小さいも少ない速い



システム・リソース消費（システム・リソース消費（システム・リソース消費（システム・リソース消費（I/O およびおよびおよびおよび CPU）を最小化するためのベスト・プラクティス）を最小化するためのベスト・プラクティス）を最小化するためのベスト・プラクティス）を最小化するためのベスト・プラクティスシステム・リソース消費が主な検討課題の場合、データベースでのリソース消費量が小となるのは、ブロック変更トラッキング・ファイルを使用する増分バックアップです。これが当てはまるのは、各バックアップ・ウィンドウで変更されるデータ量が合計データベース・サイズの20% 未満の場合です。各バックアップ・ウィンドウで変更されるデータ量が 20% を超えると、バックアップを格納するのに必要なディスク領域量は増分バックアップの実行により減少しますが、バックアップ時間は減少しない可能性があります。

例例例例

ほとんどのアプリケーションで、トランザクション頻度が非常に高いかどうかにかかわらず、データベース全体で毎日変更される部分の割合は多くありません。アプリケーションは、同じブロック・セットを頻繁に更新するため、ダーティ・ブロック・セットの合計サイズは小さくなります。

たとえば、約 600GB のユーザー・データを含むデータベースがあるとします（一時ファイルとREDO ログは除外します）。 24 時間ごとに、データベースの約 2.5%（約 15GB のデータ）が変更されます。初のレベル 0 のバックアップにはおよそ 180 分を要し、後続のレベル 1 のバックアップには 20 分を要します。一方で、各バックアップのマージには 45 分を要します。この例のまとめは、次のとおりです。

� レベル 0 のバックアップには、180 分を要します（データ領域からの READ操作とフラッシュ・リカバリ領域への WRITE操作を含む）。

� レベル 1 のバックアップには、20 分を要します（データ領域からの READ操作とフラッシュ・リカバリ領域への WRITE操作を含む）。

� 各バックアップのロールフォワードとマージには、45 分を要します（フラッシュ・リカバリ領域を対象とする READ操作と WRITE操作を含む）。個別ストレージを使用している場合は、通常、データ領域に対する競合が減少します。

� 終的な削減内容は次のとおりです。

– 115 分または 64% の時間を節約して完全なバックアップを作成できます。

– バックアップ中のデータベースの I/O を削減できます。

より大規模なデータベースであれば、削減量はさらに増加します。

2.5.3.2 NOCATALOG モードとその後のモードとその後のモードとその後のモードとその後の RESYNC CATALOG によるバックアップによるバックアップによるバックアップによるバックアップの作成の作成の作成の作成バックアップをディスクまたはテープに作成する場合、ターゲット・データベースの制御ファイルを RMAN リポジトリとして使用します。これにより、バックアップの成功が、RMAN リポジトリを保持するデータベースの可用性に左右されなくなります。これを行うには、RMANを NOCATALOGオプション付きで実行します。バックアップの完了後に、RESYNC CATALOGコマンドを使用することで、ターゲット・データベースの制御ファイルに格納された新規バックアップ情報をリカバリ・カタログと再同期できます。

関連資料関連資料関連資料関連資料 : RESYNC CATALOGの詳細は、『Oracle Database バックアップおよびリカバリ・リファレンス』を参照してください。



2.5.3.3 ディスク上のフラッシュ・リカバリ領域へのデータベース・バックアップディスク上のフラッシュ・リカバリ領域へのデータベース・バックアップディスク上のフラッシュ・リカバリ領域へのデータベース・バックアップディスク上のフラッシュ・リカバリ領域へのデータベース・バックアップの作成の作成の作成の作成ディスク・ベースの自動バックアップおよびリカバリ機能を使用して、次のようにバックアップ関連ファイルを自動管理するフラッシュ・リカバリ領域を作成できます。

1. ディスク上の場所を選択します。

この場所は、DB_RECOVERY_FILE_DESTで指定します。

2. 記憶領域の上限を選択します。

この上限は、DB_RECOVERY_FILE_DEST_SIZEで指定します。

3. リカバリ用にバックアップ・ファイルを必要とする期間を制御する保存ポリシーを設定します。

これで、Oracle Database 10g により、データベースのバックアップやアーカイブ REDO ログなどのリカバリ関連ファイルに使用される記憶域がこの領域内で管理されます。不要になったファイルは、RMAN が新規ファイル用として領域を再利用する場合の削除候補となります。

2.5.3.4 すべてのサイトでのフラッシュ・リカバリ領域へのバックアップすべてのサイトでのフラッシュ・リカバリ領域へのバックアップすべてのサイトでのフラッシュ・リカバリ領域へのバックアップすべてのサイトでのフラッシュ・リカバリ領域へのバックアップ（（（（Data Guard 環境の場合）環境の場合）環境の場合）環境の場合）バックアップは、プライマリ・サイトとセカンダリ・サイトの両方で実行します。このプラクティスのメリットは、次のとおりです。

� 特定の二重停止状況で RTO が大幅に短縮されます。

� スイッチオーバーまたはフェイルオーバーの際に新しいバックアップ手順を導入する必要がなくなります。

� RMAN のファイルおよびブロック・メディア・リカバリは、プライマリ・サイトとセカンダリ・サイトの両方のデータ障害停止に対応するリカバリ・オプションです。

バックアップがセカンダリ・サイトでのみ実行される環境について検討します。推定リカバリ時間が 3 日であるセカンダリ・サイトでサイト停止が発生したとします。プライマリ・サイトは、通常のフェイルオーバーで解決される停止、またはローカル・バックアップを保持していれば解決できる停止（ブロック・メディア・リカバリにより解決されるデータ障害停止など）に対して完全に無防備となります。

この状況の場合、本番データベースの停止は、スタンバイ・サイトで取得されたオフサイトのテープ・バックアップを物理的に移送するだけで解決できます。プライマリ・サイトのバックアップが使用可能であれば、実行できないフェイルオーバーのかわりにローカルでリストアを実行するというオプションを使用できます。データが失われる可能性もありますが、プライマリ・サイトのバックアップを保持することで RTO が大幅に短縮されます。

RMAN のファイルまたはブロック・メディア・リカバリを使用する場合、適切な RTO を確保するには、プライマリ・サイトのディスク・バックアップも必要です。ローカルのディスク・バックアップが存在しないと、スタンバイ・サイトで取得されたバックアップをプライマリ・サイトに対してリストアすることになるため、このタイプの停止では RTO が大幅に増加します。



2.5.4 テープへのバックアップテープへのバックアップテープへのバックアップテープへのバックアップこの項には、次の各項目が含まれます。

� フラッシュ・リカバリ領域からのテープ・バックアップの作成

� オフサイト・バックアップの管理

2.5.4.1 フラッシュ・リカバリ領域からのテープ・バックアップの作成フラッシュ・リカバリ領域からのテープ・バックアップの作成フラッシュ・リカバリ領域からのテープ・バックアップの作成フラッシュ・リカバリ領域からのテープ・バックアップの作成RMAN コマンドの BACKUP RECOVERY FILE DESTINATIONを使用すると、フラッシュ・リカバリ領域に作成されているディスク・バックアップをテープに移行できます。 1 つのコマンドを使用して、まだテープにバックアップされていないすべてのファイルをバックアップできます。これにより、2 回以上ファイルをバックアップしてテープを無駄にせずにすむ他、以前にバックアップされていないファイルを追跡する必要もなくなります。テープ・バックアップは、オフサイトおよび長期保管用で、特定の停止状況に対処する際に使用します。

2.5.4.2 オフサイト・バックアップの管理オフサイト・バックアップの管理オフサイト・バックアップの管理オフサイト・バックアップの管理スタンバイ・データベースが存在するかどうかなど、配置されているアーキテクチャにかかわらず、障害からの保護を実現するため、および証券取引委員会（SEC）や医療保険の携行性と責任に関する法律（HIPPA）などの法的規制要件に準拠するため、ビジネス要件としてオフサイトにバックアップを保持することは重要です。

2.5.5 バックアップとリカバリのメンテナンスバックアップとリカバリのメンテナンスバックアップとリカバリのメンテナンスバックアップとリカバリのメンテナンスこの項には、次の各項目が含まれます。

� データベース・ファイルの破損の定期的なチェック

� リカバリ手順の定期的なテスト

� リカバリ・カタログ・データベースの定期的なバックアップ

2.5.5.1 データベース・ファイルの破損の定期的なチェックデータベース・ファイルの破損の定期的なチェックデータベース・ファイルの破損の定期的なチェックデータベース・ファイルの破損の定期的なチェックRMAN コマンドの BACKUP VALIDATE RMANを使用して、ユーザー・セッションや通常のバックアップ操作によりまだレポートされていないブロック破損が存在しないかどうか、データベース・ファイルを定期的にチェックします。 RMAN は、指定されたファイルをスキャンして、物理エラーと論理エラーに関して内容のチェックを実行しますが、実際のバックアップまたはリカバリ操作は実行しません。 Oracle により、破損ブロックのアドレスと破損タイプが制御ファイルに記録されます。これらのレコードには、V$DATABASE_BLOCK_CORRUPTIONビューを通じてアクセスします（このビューは、RMAN のブロック・メディア・リカバリで使用できます）。

BLOCK CHANGE TRACKINGが有効の場合、すべてのデータ・ブロックを確実に読み取って検証するため、BACKUP VALIDATEで INCREMENTAL LEVELオプションを使用しないでください。

検出可能なすべての破損タイプを検出するには、CHECK LOGICALオプションを指定します。 BACKUP VALIDATEコマンドの MAXCORRUPTまたは NOCHECKSUMオプションは指定しないでください。


高速アプリケーション・フェイルオーバーの構成

2.5.5.2 リカバリ手順の定期的なテストリカバリ手順の定期的なテストリカバリ手順の定期的なテストリカバリ手順の定期的なテスト完全で正常なテスト済のバックアップは、リカバリが成功するための基盤となります。異なる停止タイプに対応するテスト計画を作成してください。も一般的な停止タイプから始め、も可能性の低いタイプへと作業を進めます。

バックアップ手順のエラーを監視し、定期的にリカバリ手順をテストしてバックアップを検証します。また、RMAN コマンドの BACKUP VALIDATEおよび RESTORE...VALIDATEを使用してバックアップとリストアの実行可能性を検証します。

2.5.5.3 リカバリ・カタログ・データベースの定期的なバックアップリカバリ・カタログ・データベースの定期的なバックアップリカバリ・カタログ・データベースの定期的なバックアップリカバリ・カタログ・データベースの定期的なバックアップリカバリ・カタログ・データベースは、バックアップおよびリカバリ計画に含めます。リカバリ・カタログのバックアップがない状態でリカバリ・カタログ・データベースを破壊するディスク障害が発生すると、カタログ内のメタデータが失われる可能性があります。リカバリ・カタログの内容なしで他のデータベースをリカバリするのは、一般的にかなり困難です。

2.6 高速アプリケーション・フェイルオーバーの構成高速アプリケーション・フェイルオーバーの構成高速アプリケーション・フェイルオーバーの構成高速アプリケーション・フェイルオーバーの構成Real Application Clusters（RAC）および Data Guard 環境でインスタンスとデータベースの高速フェイルオーバーおよびスイッチオーバーの効果を大化するには、高速アプリケーション・フェイルオーバーを構成する必要があります。高速アプリケーション・フェイルオーバーを使用すると、データベース・サービスが使用不可能になった場合に、クライアント（中間層アプリケーションまたはデータベースに直接接続する任意のプログラム）を迅速かつシームレスに使用可能なデータベース・サービスにフェイルオーバーできます。

クライアント・フェイルオーバー機能は、Oracle データベースの各リリースに合せて拡張されているため、クライアントが様々な停止状態に対応するのに必要な時間は、リリースごとに変化します。特定の状況では、フェイルオーバーに必要とされる時間は、TCP/IP のネットワーク・タイムアウト時間に直接依存します。

表 2-5 に、クライアント・フェイルオーバー機能の使用時の一般的な待機時間を示します。

Oracle Database 10g リリース 2（10.2）では、TCP/IP のネットワーク・タイムアウトを原因とする遅延は、高速アプリケーション・フェイルオーバーを使用することで JDBC クライアントと OCI クライアントの両方で抑止できます。サイト・フェイルオーバーで高速アプリケーション・フェイルオーバーを使用するには、DB_ROLE_CHANGEシステム・イベントによって起動されるトリガーを記述します。このトリガーでは、フェイルオーバー後のタスクも管理できます。

シームレスなクライアント・フェイルオーバーの実行方法の詳細は、http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_ClientFailoverBestPractices.pdfの『Oracle Database 10g Release 2 Best Practices: Client Failover for Highly Available Oracle Databases』を参照してください。

表表表表 2-5 クライアント・フェイルオーバーの一般的な待機時間クライアント・フェイルオーバーの一般的な待機時間クライアント・フェイルオーバーの一般的な待機時間クライアント・フェイルオーバーの一般的な待機時間

Oracle データベースデータベースデータベースデータベースのリリースのリリースのリリースのリリース

クライアント・クライアント・クライアント・クライアント・タイプタイプタイプタイプサイト障害サイト障害サイト障害サイト障害 RAC ノード障害ノード障害ノード障害ノード障害

非非非非 RAC インスタンスインスタンスインスタンスインスタンス障害障害障害障害

RAC インスタンスインスタンスインスタンスインスタンス障害障害障害障害

8.0、8i、9i すべて TCP タイムア

ウト

TCP タイムアウト数秒～数分1

1 非 RAC インスタンス障害に必要とされる待機時間は、スタンバイ・データベースを新規プライマリ・データベースとしてアクティブ化する時間と、クライアントが新規接続を確立する時間によって決定されます。

数秒

10g リリース 1（10.1） JDBC TCP タイムア

ウト

数秒数秒～数分 1 数秒

10g リリース 1（10.1） OCI TCP タイムア

ウト

TCP タイムアウト数秒～数分 1 数秒

10g リリース 2（10.2） JDBC 数秒数秒数秒数秒

10g リリース 2（10.2） OCI 数秒2

2 TCP タイムアウトに等しい停止が発生する ODP.NET クライアントを除きます。

数秒数秒数秒


高速アプリケーション・フェイルオーバーの構成


� クライアントのフェイルオーバーの構成

� RAC データベースでのクライアント・フェイルオーバー

� RAC プライマリ・データベースからスタンバイ・データベースへのフェイルオーバー

2.6.1 クライアントのフェイルオーバーの構成クライアントのフェイルオーバーの構成クライアントのフェイルオーバーの構成クライアントのフェイルオーバーの構成JDBC クライアントの場合、フェイルオーバーのベスト・プラクティスとして次の手順を実行します。

1. JDBC クライアントで高速接続フェイルオーバーを有効化するため、DataSourceプロパティの FastConnectionFailoverEnabledを TRUEに設定します。

2. JDBC クライアントを構成して、クラスタ内の各ノードの VIP アドレスが記載された、既存のサービスに接続するためのアドレス・リストを含む接続記述子を使用します。

3. Oracle Notification Service（ONS）デーモンがクライアントで必要とされることのないように、JDBC クライアントでリモート ONS サブスクリプションを構成します。

OCI クライアントの場合、フェイルオーバーのベスト・プラクティスとして次の手順を実行します。

1. OCI クライアントで高速アプリケーション通知（FAN）を有効化するため、OCI_EVENTSパラメータで環境を初期化します。

2. OCI クライアント・アプリケーションをスレッド・ライブラリにリンクします。

3. AQ_HA_NOTIFICATIONSパラメータを TRUEに設定し、サービスで透過的アプリケーション・フェイルオーバー（TAF）属性を構成します。

2.6.2 RAC データベースでのクライアント・フェイルオーバーデータベースでのクライアント・フェイルオーバーデータベースでのクライアント・フェイルオーバーデータベースでのクライアント・フェイルオーバーRAC データベースの場合、クライアント・フェイルオーバーのベスト・プラクティスとして次の手順を実行します。

1. Oracle Enterprise Manager を使用して新規サービスを作成します。

2. RAC ONS 構成にクラスタ内のすべてのホストを追加します。

2.6.3 RAC プライマリ・データベースからスタンバイ・データベースへのプライマリ・データベースからスタンバイ・データベースへのプライマリ・データベースからスタンバイ・データベースへのプライマリ・データベースからスタンバイ・データベースへのフェイルオーバーフェイルオーバーフェイルオーバーフェイルオーバー

RAC プライマリ・データベースからスタンバイ・データベースにフェイルオーバーする場合、クライアント・フェイルオーバーのベスト・プラクティスとして次の手順を実行します。

1. Oracle Net 別名の変更用に必要なサポート・ファイルを作成します。

2. JDBC クライアントにプライマリ・サイトの障害を通知し、新規プライマリ・データベースへの再接続を指示するため、FAN ONS パブリッシャ・プログラムを構成します。

3. Data Guard のフェイルオーバーまたはスイッチオーバーによるロール変更後に、JDBC および OCI クライアントが新規プライマリ・データベースに接続できるように、適切な手順を実行するトリガーを DB_ROLE_CHANGEシステム・イベントに作成します。


Oracle Grid Control を使用した

3
Oracle Grid Control を使用した監視を使用した監視を使用した監視を使用した監視
この章では、Oracle Grid Control を使用してアプリケーション・スタックのすべての層で高可用性環境を監視および管理するためのベスト・プラクティスについて説明します。

� 高可用性の監視と検出の概要

� Oracle Grid Control を使用したシステムの監視

� Oracle Grid Control を使用した高可用性環境の管理

監視 3-1

高可用性の監視と検出の概要

3.1 高可用性の監視と検出の概要高可用性の監視と検出の概要高可用性の監視と検出の概要高可用性の監視と検出の概要システム、ネットワーク、データベース操作、アプリケーション、およびその他のシステム・コンポーネントを継続的に監視することで、問題を早期に検出できます。早期の検出により、問題を迅速に解決できるため、ユーザーのシステム使用感が向上します。また、監視では、増加するシステム・パフォーマンスの傾向や再発する問題の傾向を示すシステム・メトリックを取得できます。この情報を使用して、予防対策の促進、セキュリティ・ポリシーの適用、およびジョブ処理の管理を行うことができます。データベース・サーバーでは、堅牢な監視システムで可用性を測定し、データベース・サーバーを使用不可能にする危険性のあるイベントを検出すると同時に、重大な障害については担当各所に即座に通知する必要があります。

監視システムは、それ自体が高可用性を保持し、監視対象のリソースと同じ運用ベスト・プラクティスと可用性プラクティスに準拠している必要があります。監視システムに障害が発生すると、すべての監視対象システムで診断データを取得することや管理者に問題を通知することができなくなります。

Oracle Grid Control には、様々な通知オプションを備えた管理および監視機能が付属しています。この章では、Oracle Grid Control を使用してアプリケーション・スタックのすべての層で高可用性環境を監視および管理するためのベスト・プラクティスについて説明します。環境の可用性およびパフォーマンスを監視する方法と、環境内の変化に対応してツールを使用する方法の推奨事項が含まれます。

3.2 Oracle Grid Control を使用したシステムの監視を使用したシステムの監視を使用したシステムの監視を使用したシステムの監視この項では、Oracle Grid Control で使用可能な概念および機能の概要について説明します。

Oracle Grid Control の主なメリットは、ホスト・オペレーティング・システムからユーザー・アプリケーション（またはパッケージ・アプリケーション）までのアプリケーション・スタック全体で複数のコンポーネントを管理できることです。 Oracle Grid Control では、アプリケーションの各レイヤーをターゲットとして扱います。ターゲット（データベース、アプリケーション・サーバー、ハードウェアなど）は、同じタイプの他のターゲットとともに表示するか、アプリケーション・タイプごとにグループ化することができます。また、すべてのターゲットを単一のビューで確認することも可能です。各ターゲット・タイプには、特定のターゲットに関連する詳細情報のサマリーを含む、デフォルトで生成されるホームページがあります。異なるタイプのターゲットは、機能ごとに（つまり、同じアプリケーションをサポートするリソースとして）グループ化できます。

すべてのターゲットは、Oracle 管理エージェントによって監視されます。すべての管理エージェントは、任意のマシン上で稼働し、ターゲットのセットを監視対象とします。ターゲットは、管理エージェントが稼働するマシンとは別のマシン上にあってもかまいません。たとえば、管理エージェントでは、エージェントをネイティブにホストしないストレージ・アレイを監視できます。管理エージェントをホストにインストールすると、そのホストはマシン上の他のターゲットとともに自動的に検出されます。


Oracle Grid Control を使用したシステムの監視

図 3-1 に示すとおり、Oracle Grid Control のホームページには、検出されたすべてのターゲットの可用性に関するグラフが表示されます。

図図図図 3-1 Oracle Grid Control のホームページのホームページのホームページのホームページ

Oracle Grid Control のホームページには、主に次の種類の情報が表示されます。

� すべてのターゲットを対象とする現在の可用性のスナップショット。可用性に関連付けられた円グラフにより、管理者は、使用不可能なターゲット（「停止中」）、またはコンソールとの通信が途絶えているターゲット（「不明」）を即座に判別できます。

� 監視対象システム全体で認識されているイベントのアラート数とジョブの問題数の概要。詳細情報を表示するには、対応するリンクをクリックするか、任意の Oracle Grid Controlページの右上部分から「アラート」「アラート」「アラート」「アラート」に移動します。

� 特定のターゲットでタスクを実行する必要のある管理者用のターゲット・ショートカット。

� システム内で実際に何が検出されたかを示す概要情報。このリストは、ハードウェア・レベルと Oracle レベルで表示できます。

� 他の Oracle オンライン・リソースに対する便利なリンクのセット。

アラートは、複数の要因の組合せにより生成されるもので、特定のメトリックメトリックメトリックメトリックに対して定義されます。メトリックは、管理エージェントにより調査されて Oracle 管理リポジトリに送信されるデータ・ポイントです。メトリックは、単純なハートビート・テストに基づくコンポーネントの可用性である場合や、特定のパフォーマンス測定（ディスク・ビジーまたは特定の待機イベントを待機するプロセスの割合など）の評価である場合があります。

どのメトリックでも、エラー、警告、クリティカルおよびクリアという 4 つの状態をチェックできます。管理者は、次のようなポリシーを決定する必要があります。

� どのオブジェクトを監視するか（データベース、ノード、リスナー、またはその他のサービス）。

� 何を計測対象として調査するか（可用性、CPU ビジー割合など）。

� どの程度の頻度でイベントを調査するか。

� 事前定義されたしきい値をメトリックが超えたときに何を実行するか。

Oracle Grid Control を使用した監視 3-3


これらすべての項目は、システムのビジネス要件に基づいて決定します。たとえば、すべてのコンポーネントで可用性を監視する場合でも、一部のシステムは業務時間中にのみ監視することが可能です。特定のパフォーマンス問題のあるシステムでは、問題をデバッグするために、追加のパフォーマンス・トレース機能を有効化できます。

この項には、他に次の各項目が含まれます。

� 各システムに対するデフォルト通知ルールの設定

� データベース・ターゲット・ビューを使用したシステム状態、可用性およびパフォーマンスの監視

� イベント通知を使用したメトリック変更への応答

� イベントを使用した Data Guard システムの可用性の監視

3.2.1 各システムに対するデフォルト通知ルールの設定各システムに対するデフォルト通知ルールの設定各システムに対するデフォルト通知ルールの設定各システムに対するデフォルト通知ルールの設定通知ルール通知ルール通知ルール通知ルールは、Oracle Grid Control に検出されたターゲットに自動的に適用される、メトリックに対する定義済のアラートのセットです。たとえば、管理者は、データベース・ターゲットの可用性を監視して、データベースに障害が発生した場合は電子メール・メッセージを生成するルールを作成できます。作成したルールは、既存のすべてのデータベースと、将来作成される任意のデータベースに適用できます。これらのルールにアクセスするには、「プリファレン「プリファレン「プリファレン「プリファレンス」ス」ス」ス」に移動し、「ルール」「ルール」「ルール」「ルール」を選択します。

ルールでは、サービス可用性に影響する可能性のある問題など、即座に対処する必要のある問題や、Oracle エラーまたはアプリケーション・エラーを監視します。サービス可用性は、アプリケーション・スタックの任意のレイヤー（ノード、データベース、リスナー、重大なアプリケーション・データなど）の停止によって影響を受けます。データベースに接続できない、またはアプリケーション機能に不可欠なデータにアクセスできないなどのサービス可用性の障害については、迅速に特定してレポートを確認し、問題に対処する必要があります。アーカイブ・ログ・ディレクトリが一杯であるなど、サービス停止につながる可能性のある問題も、システム停止を避けるために適切に対処する必要があります。

Oracle Grid Control には、可用性を監視するための強力なフレームワークとなる一連のデフォルト・ルールが含まれます。デフォルト・ルールは、Oracle Grid Control に付属する事前インストール済のターゲット・タイプごとに用意されています。これらのルールは、個々のサイトのポリシーに合せて変更できます。また、サイト固有のターゲットまたはアプリケーション用に新規ルールを作成することも可能です。特定期間中にユーザーに通知するようルールを設定して、自動カバレッジ・ポリシーを作成することもできます。

次の推奨事項を検討してください。

� ターゲット・アーキテクチャの重要なコンポーネントの各ルールは、ルール変更ウィザードを使用して必要な可用性要件を満たすように変更します。データベース・ルールの場合、ターゲットごとに表 3-1、表 3-2 および表 3-3 のイベントを設定します。監視頻度は、各コンポーネントの品質保証契約（SLA）に基づいて決定します。

� ビーコン機能を使用して、個々のアプリケーションのパフォーマンスを追跡します。ビーコンを設定すると、通常のアプリケーション作業のかわりとなるユーザー・トランザクションを実行できます。 Enterprise Manager では、このトランザクションのレスポンス時間を分析用のコンポーネントに分割します。また、このトランザクションの実行時間が事前定義済の制限値を超えた場合、アラートを起動できます。

関連資料関連資料関連資料関連資料 : Oracle Grid Control でメトリックを監視および使用する方法の詳細は、『Oracle Enterprise Manager 概要』を参照してください。


� ビーコンの概念的な情報は、『Oracle Enterprise Manager 概要』を参照してください。

� サービス・テストとビーコンの構成方法の詳細は、『Oracle Enterprise Manager アドバンスト構成』を参照してください。



� 通知メソッドを追加して各通知ルールで使用します。デフォルトでは、潜在的な問題を管理者に通知するも簡単な方法は、電子メールの送信です。この通知メソッドを拡張するため、電子メール以外の方法でアラートを送信する SNMP トラップまたはオペレーティング・システム・スクリプトへのコールアウトを追加できます。これにより、電子メール・システムのコンポーネントが停止した場合に問題が発生することを回避できます。追加の通知メソッドを設定するには、任意の Oracle Grid Control ページの上部にある「設定」「設定」「設定」「設定」リンクを使用します。

� ターゲットの可用性の計算でエラーが発生した場合に管理者に通知するよう通知ルールを変更します。これにより、コンポーネントの可用性の誤った読取りが発生することもありますが、システム管理者にとって高度の通知レベルが保証されます。

図 3-2 は、可用性状態を選択するための通知ルールのプロパティ・ページを示しており、「停止中」、「エージェント使用不可」、「エージェント使用不可解決」および「メトリック・エラー検出」が選択されています。

図図図図 3-2 可用性の通知ルールの設定可用性の通知ルールの設定可用性の通知ルールの設定可用性の通知ルールの設定

また、データベース・ルールにより監視されるメトリックを変更して、表 3-1、表 3-2 および表 3-3 に記載されているメトリックをレポートします。すべてのデータベース・ターゲットを対象にこれらのメトリックを収集することで、将来の分析において傾向データを使用できます。表 3-1、表 3-2 および表 3-3 に記載されているすべてのイベントにアクセスするには、データベースのホームページで「すべてのメトリック」「すべてのメトリック」「すべてのメトリック」「すべてのメトリック」→「すべてを開く」「すべてを開く」「すべてを開く」「すべてを開く」を選択します。



サービス停止の原因となる可能性のある領域管理の条件は、表 3-1 のイベントを使用して監視する必要があります。

「アラート・ログ」メトリック・グループで、表 3-2 のエラーについてアラート・ログを監視するよう Oracle Grid Control を設定します。

処理容量を超えることがないようシステムを監視します。これらのイベントの警告レベルとクリティカル・レベルは、システムの使用パターンに基づいて変更してください。表 3-3 の推奨事項を使用して、「データベース制限」メトリック・グループでイベントを設定します。

表表表表 3-1 領域を監視するための推奨事項領域を監視するための推奨事項領域を監視するための推奨事項領域を監視するための推奨事項

メトリックメトリックメトリックメトリック推奨事項推奨事項推奨事項推奨事項

表領域使用率（%）このメトリックを設定すると、重要なハードウェア・サーバーのルート・ファイル・システムを監視できます。このメトリックを使用する場合、管理者は、Oracle Grid Control がテスト対象とするしきい値の割合と、メッセージを管理者に生成する前に検出を必要とするエラーの発生数を選択できます。デフォルト設定は、70% で警告、90% でエラーとする

ことをお薦めしますが、これらの値はシステムの使用状況に応じて調整してください。このメトリックは、特定の表領域のみを監視するようカスタマイズできます。

このメトリックと類似イベントは、表領域フル・メトリック・グループで設定できます。

アーカイバ・ハングのアラート・ログ・エラー

このメトリックを設定すると、アーカイブ・ログ・ディレクトリが一杯であることを示すORA-00257 エラーのアラート・ログを監視できます。

このメトリックは、「アラート・ログ・エラー・ステータス」メトリック・グループで設定できます。

ダンプ領域使用率（%）このメトリックを設定すると、ダンプ出力先ディレクトリを監視できます。初にエラー

が発生したときに大量の診断情報を保存するためには、ダンプ領域が使用可能である必要があります。デフォルト設定は、70% で警告、90% でエラーとすることをお薦めします

が、これらの値はシステムの使用状況に応じて調整してください。

このメトリックは、「ダンプ領域」メトリック・グループで設定できます。

表表表表 3-2 アラート・ログを監視するための推奨事項アラート・ログを監視するための推奨事項アラート・ログを監視するための推奨事項アラート・ログを監視するための推奨事項


アラートこのメトリックを設定すると、ORA-6XX、ORA-1578（データベース破損）または

ORA-0060（デッドロック検出）の各エラーが発生したときにアラートを送信できます。他のエラーが記録された場合は、警告メッセージが生成されます。

データ・ブロック破損このメトリックを設定すると、ORA-01157 および ORA-27048 エラーのアラート・ログを

監視できます。これらのエラーは、Oracle データベースのデータファイルが破損したこと

を示します。

表表表表 3-3 処理容量を監視するための推奨事項処理容量を監視するための推奨事項処理容量を監視するための推奨事項処理容量を監視するための推奨事項


プロセス制限このメトリックのしきい値を設定すると、現在のプロセス数が PROCESSES初期化パラ

メータの値に接近したときに警告を生成できます。

セッション制限このメトリックのしきい値を設定すると、インスタンスがデータベースに許可されている同時接続の大数に接近したときに警告を生成できます。



図 3-3 は、メトリックを選択するための通知ルールのプロパティ・ページを示しています。ユーザーにより、通知の重大度の状態として「クリティカル」と「警告」が選択されています。左側のリスト・ボックスは、「使用可能なメトリック」のリストです。通知用に選択済のメトリックは、右側のリスト・ボックスに示されています。

図図図図 3-3 メトリックの通知ルールの設定メトリックの通知ルールの設定メトリックの通知ルールの設定メトリックの通知ルールの設定


� 通知ルールおよびメトリックしきい値の設定方法の詳細は、『Oracle Database 2 日でデータベース管理者』を参照してください。

� 使用可能なメトリックの詳細は、『Oracle Enterprise Manager フレームワーク、ホストおよびサードパーティ・メトリック・リファレンス・マニュアル』を参照してください。



3.2.2 データベース・ターゲット・ビューを使用したシステム状態、可用性データベース・ターゲット・ビューを使用したシステム状態、可用性データベース・ターゲット・ビューを使用したシステム状態、可用性データベース・ターゲット・ビューを使用したシステム状態、可用性およびパフォーマンスの監視およびパフォーマンスの監視およびパフォーマンスの監視およびパフォーマンスの監視

図 3-4 のデータベース・ターゲットのページには、システム・パフォーマンス、領域使用量、および重要な可用性コンポーネントの構成（アーカイブ REDO ログ・ステータス、フラッシュバック・ログ・ステータス、推定インスタンス・リカバリ時間など）の概要が表示されます。また、アラートも即座に表示されます。各アラート値は、このページのリンクを使用して構成できます。

図図図図 3-4 システム・パフォーマンスの概要システム・パフォーマンスの概要システム・パフォーマンスの概要システム・パフォーマンスの概要

Oracle Grid Control のメトリックの多くは、パフォーマンスに関連します。十分なパフォーマンスを維持できないシステムは、個々のコンポーネントのステータスにかかわらず、高可用性システムとは言えません。パフォーマンスの問題が大規模なシステム停止の原因となることはまれですが、それでも顧客の一部に対するサービスを停止させる可能性があります。このタイプの停止は、一般的にアプリケーション・サービス低下アプリケーション・サービス低下アプリケーション・サービス低下アプリケーション・サービス低下と呼ばれます。サービス低下の主な原因は、1 つ以上のインフラストラクチャ・コンポーネントの断続的または部分的障害です。 ITマネージャは、インフラストラクチャ・コンポーネントの稼働状況（レスポンス時間、待機時間および可用性）と、エンド・ユーザーに提供されるアプリケーション・サービスの品質に対するこれらのコンポーネントの影響を把握しておく必要があります。

パフォーマンス・ベースラインは、SLA を満たす通常の操作から導出されるもので、パフォーマンス・メトリック・アラートの構成項目を決定する際の基準となります。ベースライン・データは、アプリケーションが本番環境に導入された初日から収集します。ベースライン・データには、次の統計が含まれる必要があります。

� アプリケーション統計（トランザクション量、レスポンス時間、Web サービス時間）

� データベース統計（トランザクション率、REDO 速度、ヒット率、上位 5 位の待機イベント、上位 5 位の SQL トランザクション）

� オペレーティング・システム統計（CPU、メモリー、I/O、ネットワーク）

Oracle Grid Control を使用すると、ベースラインとしてデータベース・パフォーマンスのスナップショットを取得できます。 Oracle Grid Control では、これれらの値をシステム・パフォーマンスと比較して、その結果をデータベース・ターゲットのページに表示します。基準のベースラインから値が大きく逸脱した場合に、アラートを送信することも可能です。



すべてのデータベース・ターゲットに対して、表 3-4 のメトリックを取得するようデータベース通知ルールを設定します。これらのパラメータは、単一のツールを使用して分析できます。また、履歴データも使用できます。

3.2.3 イベント通知を使用したメトリック変更への応答イベント通知を使用したメトリック変更への応答イベント通知を使用したメトリック変更への応答イベント通知を使用したメトリック変更への応答推奨メトリックの補足に使用できる多くのオペレーティング・システム・イベントがあります。このようなオペレーティング・システム・イベントは、ホストやインスタンスごとに設定する必要はありません。定義済のすべてのメトリックは、オブジェクト・ターゲット・ページのナビゲーション・バーの下部にある「メトリックの管理」「メトリックの管理」「メトリックの管理」「メトリックの管理」リンクを使用して、インスタンスまたはデータベースごとに個別に設定できます。警告アラートまたはクリティカル・アラートを起動する値は、この場所で変更できます。また、Oracle Grid Control で生成される標準のアラート以外に、オペレーティング・システム・スクリプトをアクティブ化してメトリックしきい値に応答することも可能です。

表表表表 3-4 メトリックの推奨通知ルールメトリックの推奨通知ルールメトリックの推奨通知ルールメトリックの推奨通知ルール


1 秒当たりのディスク I/O これは、データベースにより実行される I/O 操作を監視するデータベース・レベルのメト

リックです。このメトリックは、操作の数がユーザー定義のしきい値を超えたときにア

ラートを送信します。このメトリックは、Oracle Grid Control で同様に使用できるオペ

レーティング・システム・レベルのイベントと組み合せて使用します。

このメトリックは、システムで使用可能な合計 I/O スループット、使用可能な I/O チャ

ネルの数、ネットワーク帯域幅（SAN 環境の場合）、ディスク・キャッシュの効果（スト

レージ・アレイ・デバイスを使用している場合）、大 I/O レート、およびデータベース

で使用可能なスピンドルの数に基づいて設定します。

% CPU ビジーこのメトリックを設定すると、75% で警告が表示され、85 ～ 90% でクリティカル・ア

ラートが表示されます。この使用率は、ピーク期間では一般的ですが、リソース集中型の

プロセスや潜在的なリソース不足を表すインジケータにもなります。

% 待機時間過剰なアイドル時間は、1 つ以上のリソースにボトルネックが発生していることを示しま

す。このメトリックは、アプリケーションが問題なく動作しているときのシステム待機時

間に基づいて設定します。

1 秒当たりのネットワーク・

バイト

このメトリックは、Oracle によって生成されるネットワーク・トラフィックをレポートし

ます。その内容は、潜在的なネットワーク・ボトルネックを示します。このメトリックは、

ピーク期間中の実際の使用状況に基づいて設定します。

1 秒当たりの合計解析このメトリックは、SQL パフォーマンスを測定します。その内容は、リソース不足の原因

であるアプリケーション変更または使用状況の変更を示します。このメトリックは、ピー

ク期間に基づいて設定します。


� パフォーマンス監視の詳細は、『Oracle Database パフォーマンス・チューニング・ガイド』を参照してください。

� Enterprise Manager を使用した監視方法とチューニング方法の詳細は、『Oracle Database 2 日でデータベース管理者』を参照してください。


Oracle Grid Control を使用した高可用性環境の管理

3.2.4 イベントを使用したイベントを使用したイベントを使用したイベントを使用した Data Guard システムの可用性の監視システムの可用性の監視システムの可用性の監視システムの可用性の監視Oracle Grid Control のメトリックを設定すると、Data Guard の論理構成および物理構成の可用性を監視できます。 Oracle Grid Control の拡張機能である Data Guard Manager に Data Guard環境が登録されている場合、表 3-5 のイベントを設定します。

3.3 Oracle Grid Control を使用した高可用性環境の管理を使用した高可用性環境の管理を使用した高可用性環境の管理を使用した高可用性環境の管理Oracle Grid Control は、問題の通知と分析以外に、任意のシステムのプロアクティブな管理に使用できます。この項には、次の推奨事項が含まれます。

� Oracle Grid Control を使用したポリシー違反のチェック

� Oracle Grid Control を使用した Oracle パッチの管理とシステム・ベースラインの維持

� Oracle Grid Control を使用した Data Guard ターゲットの管理

3.3.1 Oracle Grid Control を使用したポリシー違反のチェックを使用したポリシー違反のチェックを使用したポリシー違反のチェックを使用したポリシー違反のチェックOracle Grid Control には、すべてのデータベースのベスト・プラクティスとして、ポリシーと推奨事項の事前インストール済のセットが付属しています。これらのポリシーはデフォルトでチェックされ、違反の数は図 3-4 のように「ターゲット」ページに表示されます。すべての違反のリストを参照するには、「ターゲット」ページで「ポリシー違反」「ポリシー違反」「ポリシー違反」「ポリシー違反」を選択します。

表表表表 3-5 Data Guard イベントを設定するための推奨事項イベントを設定するための推奨事項イベントを設定するための推奨事項イベントを設定するための推奨事項


Data Guard ステータスこのメトリックを設定すると、Data Guard 構成のシステム問題を通知できます。

未適用のデータこのメトリックを設定すると、受信された後のアーカイブ REDO ログとスタンバイ・

データベースに適用された後のログの間のギャップ（分単位で測定）がユーザー定義のしきい値を超えた場合に、通知を実行できます。この情報は、スタンバイ・インスタンス

のリカバリ時間が定義済の停止リカバリ・サービス・レベルを超えた場合に管理者に警告するために使用できます。このメトリックは、スタンバイ・データベースのログ適用の指

定に基づいて設定します。

未受信のデータこのメトリックを設定すると、本番データベースからスタンバイ・データベースにアーカイブ REDO ログを移動する際の遅延が拡大した場合に通知を実行できます。このメトリッ

クが起動するのは、本番データベースのアーカイブ REDO ログの数とスタンバイ・サイ

トに転送されたアーカイブ REDO ログの数の差異がユーザー定義のしきい値を超えた場

合です。しきい値は、ネットワークを通じてアーカイブ REDO ログを転送する際の時間に

基づいて設定する必要があります。

このメトリックのサンプル時間は、REDO 転送時間とほぼ同じ値に設定し、誤検出を防ぐ

ために発生数は 2 以上に設定します。警告のしきい値とクリティカルのしきい値に推奨さ

れる初期値は、それぞれ 1および 2です。

関連資料関連資料関連資料関連資料 :『Oracle Enterprise Manager 管理者ガイド』

関連資料関連資料関連資料関連資料 : 既存のポリシー定義の詳細は、『Oracle Enterprise Manager ポリシー・リファレンス・マニュアル』を参照してください。



3.3.2 Oracle Grid Control を使用したを使用したを使用したを使用したOracle パッチの管理とシステム・ベースラインパッチの管理とシステム・ベースラインパッチの管理とシステム・ベースラインパッチの管理とシステム・ベースラインの維持の維持の維持の維持

Oracle Grid Control を使用して、アプリケーション環境の監視対象システムに適用するパッチを https://metalink.oracle.comからダウンロードして管理できます。ジョブを設定して、ユーザー環境に関連するパッチを定期的にチェックできます。これらのパッチは、ダウンロードして管理リポジトリに直接保存できます。パッチは、管理リポジトリから複数のシステムにステージングして、メンテナンス・ウィンドウ中に適用できます。

あるマシンのパッチ・レベルを調査して、それらを 1 対 1 または 1 対多の関係において複数のマシン間で比較できます。この場合、1 台のマシンをベースラインとして区別し、他の複数のマシンにおけるメンテナンス要件の実証に使用できます。この機能は、データベース・パッチと同様に、オペレーティング・システム・パッチにも使用可能です。

3.3.3 Oracle Grid Control を使用したを使用したを使用したを使用した Data Guard ターゲットの管理ターゲットの管理ターゲットの管理ターゲットの管理Oracle Grid Control を使用して、任意のデータベース・ターゲットのロジカル・スタンバイ・データベースとフィジカル・スタンバイ・データベースを設定できます。また、管理リポジトリが含まれるデータベース以外のデータベース・ターゲットのスイッチオーバーとフェイルオーバーを管理できます。

Oracle Grid Control では、Data Guard 構成の状態を一覧して管理することも可能です。任意のデータベース・ターゲットのページで、「高可用性」セクションのリンクを使用して「Data Guard ステータス」セクションに移動します。このページには、プライマリ・ターゲットのアクティブなスタンバイ・データベース、スタンバイ・データベースによる受信を待機している転送ログ・データの量、およびデータ保護モードが表示されます。このページでは、データ保護モードを変更することもできます。

このページには、検証検証検証検証機能へのリンクが含まれます。この機能により、Data Guard 環境とREDO 転送サービスをチェックして、警告とエラーを表示できます。検証機能は、自動では実行されないため、手動で実行する必要があります。

関連資料関連資料関連資料関連資料 : 実際の使用例は、『Oracle Data Guard Broker』を参照してください。




停止の管

4
停止の管理停止の管理停止の管理停止の管理
この章では、計画外および計画済の停止について説明します。また、各停止タイプを許容するか管理することで停止時間を小化できる Oracle 運用ベスト・プラクティスについて説明します。


� 停止の概要

� 計画外の停止からのリカバリ

� フォルト・トレランスのリストア

� 計画済の停止による停止時間の回避または短縮

理 4-1

停止の概要

4.1 停止の概要停止の概要停止の概要停止の概要この項では、発生する可能性のある停止タイプと、それぞれの停止に関連する停止時間を回避または小化するために推奨される方法について説明します。


� 計画外の停止

� 計画済の停止

4.1.1 計画外の停止計画外の停止計画外の停止計画外の停止計画外の停止は、アプリケーションをサポートするテクノロジ・インフラストラクチャのいずれかの部分に予期しない障害が発生することを示します。これには、次のコンポーネントが含まれます。

� ハードウェア

� ソフトウェア

� ネットワーク・インフラストラクチャ

� ネーミング・サービス・インフラストラクチャ

� データベース

監視および高可用性インフラストラクチャでは、迅速な検出作業を行って停止時間からの回復を図る必要があります。第 3 章「Oracle Grid Control を使用した監視」では問題の検出について説明しましたが、この章では停止時間の短縮に重点を置きます。

表 4-1 に、プライマリ・サイトまたはセカンダリ・サイトのコンポーネントに影響を与える計画外の停止を示します。

表表表表 4-1 計画外の停止計画外の停止計画外の停止計画外の停止

停止タイプ停止タイプ停止タイプ停止タイプ説明説明説明説明例例例例

サイト障害現行の本番データベースが存在するサイト全体が使用不可能になります。これには、アプリケーションのすべての層が含まれます。

本番サイトでの火災、洪水、地震などの災害。

サイトへの悪意のある攻撃。

停電。重要なシステム用に複数の電力網とバックアップ

発電機がある場合、この障害はデータ・センターの一部にのみ影響します。

クラスタ全体障害 RAC データベースをホストするクラス

タ全体が使用不可能になるか、機能停止します。これには、クラスタ内の複

数のノードの障害と、クラスタを停止してサイトの Oracle データベースおよ

びインスタンスを使用不可能にする他のすべてのコンポーネントの障害が含まれます。

RAC クラスタに残っていた後のノードが停止し、再起

動できない場合。

冗長クラスタ・インターコネクトの両方が停止したか、クラスタウェアに障害または問題が発生した場合。

現在のデータ・サーバーの継続操作が不可能になるほど深刻なデータベース破損が発生した場合。

ディスク・ストレージに障害が発生した場合。

コンピュータ障害（ノード）

RAC クラスタのノードの 1 つが使用不

可能になるか、機能停止します。

データベース層のノードが停止したか、メモリーまたはCPU の不具合により停止する必要がある場合。

データベース層のノードに接続できない場合。

冗長クラスタ・インターコネクトの両方が停止して、別のノードが所有権を取得した場合。

コンピュータ障害（インスタンス）

データベース・インスタンスが使用不可能になるか、機能停止します。

ソフトウェアの不具合、オペレーティング・システムの問題、またはハードウェアの問題により、データ・サーバーの RAC データベースのインスタンスが停止した場

合。


停止の概要

プライマリ・サイトとセカンダリ・サイトにおける計画外の停止の削減、推定リカバリ時間、およびリカバリ手順に関する推奨ベスト・プラクティスは、次の各項を参照してください。

� プライマリ・サイトでの計画外の停止の管理

� セカンダリ・サイトでの計画外の停止の管理

4.1.1.1 プライマリ・サイトでの計画外の停止の管理プライマリ・サイトでの計画外の停止の管理プライマリ・サイトでの計画外の停止の管理プライマリ・サイトでの計画外の停止の管理プライマリ・サイトに本番データベースが含まれ、セカンダリ・サイトにスタンバイ・データベースが含まれる場合、プライマリ・サイトで発生する停止がも致命的です。これらの停止を解決することが、システムの大可用性にとって不可欠です。セカンダリ・サイトをサイト障害から保護できるのは、Data Guard を使用した Oracle Database 10g アーキテクチャと、RAC および Data Guard を使用した Oracle Database 10g（MAA）アーキテクチャのみです。

表 4-2 に、プライマリ・サイトでの計画外の停止に対応するためのリカバリ手順をまとめます。複数のリカバリ手順を必要とする停止については、この表に、4-11 ページから始まる 4.2 項

「計画外の停止からのリカバリ」の詳細な説明へのリンクが含まれます。

ストレージ障害データベースの内容の一部または全部を格納するストレージが、停止またはアクセス中断を理由として使用不可能になります。

ディスク・ドライブの障害。

ディスク・コントローラの障害。

ストレージ・アレイの障害。

データ破損データベースの一部が、メディア破損、アクセス中断または非一貫性を理由として使用不可能になります。

データファイルが間違って削除されるか、使用不可能になった場合。

メディア破損がデータベースのブロックに影響を与える場合。

オペレーティング・システムまたは他のノード関連の問題により Oracle ブロックが破損した場合。

人為的エラーデータベースの一部が使用不可能になり、トランザクション的または論理的な意味でデータの一貫性が失われます。この障害は、通常、ユーザーまたはアプリケーション・コードの不具合を原因として発生します。

局所的損害（集中的な修復作業が必要）: 表の削除また

は表からの行の削除の原因となる人為的エラー。

全体的損害（停止時間を回避するために根本的な処置が必要）: データベースの論理破損の原因となるアプリ

ケーション・エラー、または指定回数を超えるバッチ・ジョブ実行の原因となるユーザー・エラー。

注意注意注意注意 : このカテゴリは、データベースの可用性に影響を

及ぼす人為的エラー、特にデータのトランザクション的または論理的な非一貫性の原因となるエラーに重点を置いています。

表表表表 4-2 プライマリ・サイトでの計画外の停止のリカバリ時間および手順プライマリ・サイトでの計画外の停止のリカバリ時間および手順プライマリ・サイトでの計画外の停止のリカバリ時間および手順プライマリ・サイトでの計画外の停止のリカバリ時間および手順

停止タイプ停止タイプ停止タイプ停止タイプ Oracle Database 10gRAC を使用したを使用したを使用したを使用したOracle Database 10g

Data Guard を使用したを使用したを使用したを使用したOracle Database 10g

Oracle Database 10g（（（（MAA））））

サイト障害数時間～数日

1. サイトをリストアします。

2. テープ・バックアップからリストアします。

3. データベースをリカバリします。

数時間～数日

1. サイトをリストアします。

2. テープ・バックアップからリストアします。


数秒～ 5 分1

1. スタンバイ・データベースでのデータベース・フェイルオーバー（4-16 ペー

ジ）

2. 完全サイト・フェイルオーバー（4-12ページ）

3. アプリケーション・フェイルオーバー

（4-27 ページ）

数秒～ 5 分 1

1. スタンバイ・データベースでのデータベース・フェイルオーバー（4-16ページ）

2. 完全サイト・フェイルオーバー

（4-12 ページ）

3. アプリケーション・フェイルオーバー（4-27 ペー

ジ）

表表表表 4-1 計画外の停止（続き）計画外の停止（続き）計画外の停止（続き）計画外の停止（続き）

停止タイプ停止タイプ停止タイプ停止タイプ説明説明説明説明例例例例

停止の管理 4-3

停止の概要

クラスタ全体障害

適用なし数時間～数日

1. クラスタをリストアするか、低 1 つの

ノードをリストアします。

2. テープ・バックアップからリストアします（データの損失または破損が発生した場合のオプション）。


適用なし数秒～ 5 分



ジ）

コンピュータ障害（ノード）

数分～数時間2

1. ノードを再起動し、データベースを再起動します。

2. ユーザーを再接続します。

停止時間なし3

計画外の停止からのRAC リカバリによる自

動管理

数秒～ 5 分 2


ジ）


（4-27 ページ）

または

数分～数時間 2

1. ノードを再起動し、データベースを再起動します。


停止時間なし 3

計画外の停止からのRAC リカバリ（4-26ページ）による自動管理


数分 2

1. インスタンスを再起動します。



計画外の停止からのRAC リカバリによる自

動管理

数分 2

1. インスタンスを再起動します。


または

数秒～ 5 分 1


ジ）


（4-27 ページ）


計画外の停止からのRAC リカバリ（4-26ページ）による自動管理

ストレージ障害停止時間なし4

ディスクおよびストレージ障害後の ASMリカバリ（4-28 ペー

ジ）


ディスクおよびストレージ障害後の ASM リカバ

リ（4-28 ページ）


ディスクおよびストレージ障害後の ASM リカバ

リ（4-28 ページ）


ディスクおよびストレージ障害後の ASMリカバリ（4-28 ページ）

表表表表 4-2 プライマリ・サイトでの計画外の停止のリカバリ時間および手順（続き）プライマリ・サイトでの計画外の停止のリカバリ時間および手順（続き）プライマリ・サイトでの計画外の停止のリカバリ時間および手順（続き）プライマリ・サイトでの計画外の停止のリカバリ時間および手順（続き）





停止の概要

データ破損 HARD によるデータ破

損の回避5

状況により数時間

データ破損（データ障害）からのリカバリ

HARD によるデータ破

損の回避 5

状況により数時間

データ破損（データ障害）からのリカバリ


損の回避 5

または

数秒～ 5 分 1


ジ）


（4-27 ページ）


損の回避 5

または

数秒～ 5 分 1



ジ）

人為的エラー 30 分未満6

人為的エラーからのリカバリ

30 分未満 6

人為的エラーからのリカバリ

30 分未満 6

人為的エラーからのリカバリ（4-39 ページ）

30 分未満 6

人為的エラーからのリカバリ（4-39 ページ）

1 ここでのリカバリ時間は、データベースおよび既存の接続のフェイルオーバーに適用されます。ネットワーク接続の変更やサイト固有の他のフェイルオーバー・アクティビティによっては、リカバリ時間全体が増加する可能性があります。

2 リカバリ時間の多くは、障害の発生したシステムのリストアに要する時間です。3 データベースは継続して使用できますが、障害の発生したシステムに接続するアプリケーションの一部は一時的に影響を受け

ます。4 ストレージ障害は、ミラー化と組み合せた自動ストレージ管理（ASM）と、その自動リバランス機能の使用により回避されま

す。5 データ破損のすべてのタイプが回避されるわけではありません。 HARD イニシアチブの新情報は、2-7 ページの 2.1.6 項「HARD 準拠ストレージの検討」を参照してください。

6 人為的エラーからのリカバリ時間は、主に検出時間に依存します。不適切な DML または DLL トランザクションの検出に数秒を要する場合、一般的に適切なトランザクションをフラッシュバックするのに必要な時間は数秒間のみです。

表表表表 4-2 プライマリ・サイトでの計画外の停止のリカバリ時間および手順（続き）プライマリ・サイトでの計画外の停止のリカバリ時間および手順（続き）プライマリ・サイトでの計画外の停止のリカバリ時間および手順（続き）プライマリ・サイトでの計画外の停止のリカバリ時間および手順（続き）




停止の管理 4-5

停止の概要

4.1.1.2 セカンダリ・サイトでの計画外の停止の管理セカンダリ・サイトでの計画外の停止の管理セカンダリ・サイトでの計画外の停止の管理セカンダリ・サイトでの計画外の停止の管理ほとんどの場合、セカンダリ・サイトで発生する停止は、プライマリ・サイトに存在するプライマリ・データベースの可用性に影響を与えることなく管理できます。ただし、構成が大保護モードの場合、稼働を続ける後のスタンバイ・データベースで計画外の停止が発生すると、スタンバイ・データベースへのフェイルオーバー時にデータが失われることを防ぐため、本番データベースが停止します。データ保護モードのダウングレード後は、スタンバイ・データベースにアクセスできない場合でも本番データベースを再起動できます。セカンダリ・サイトで停止が発生したときにプライマリ・サイトで同時障害が発生すると、大リカバリ時間

（MTTR）に影響する可能性があります。

表 4-3 に、セカンダリ・サイトでのスタンバイ・データベースの計画外の停止に対応するためのリカバリ手順をまとめます。複数のリカバリ手順を必要とする停止については、この表に、4-11 ページから始まる 4.2 項「計画外の停止からのリカバリ」の詳細な説明へのリンクが含まれます。

表表表表 4-3 セカンダリ・サイトでの計画外の停止のリカバリ手順セカンダリ・サイトでの計画外の停止のリカバリ手順セカンダリ・サイトでの計画外の停止のリカバリ手順セカンダリ・サイトでの計画外の停止のリカバリ手順

停止タイプ停止タイプ停止タイプ停止タイプ Data Guard を使用したを使用したを使用したを使用した Oracle Database 10g Oracle Database 10g（（（（MAA））））


1. ノードとスタンバイ・インスタンスを再起動します。

2. リカバリを再開します。

スタンバイ・データベースが 1 つのみ存在し、

大データベース保護で構成されている場合、スタンバイ・データベースでデータの相違が発生しないよう本番データベースが停止します。

使用可能なスタンバイ・インスタンスへの接続時フェイルオーバーを実行するよう本番データベースの Oracle Net 記述子が構成され

ている場合、本番データベースの可用性に対する影響はありません。

ブローカにより、適用プロセスが自動的に再起動されます。

使用可能になったら、ノードとインスタンスを再起動します。

データ破損スタンバイ・データベースのデータ障害後のフォルト・トレランスのリストア（4-57 ペー

ジ）

スタンバイ・データベースのデータ障害後のフォルト・トレランスのリストア（4-57 ペー

ジ）

RESETLOGSによるプラ

イマリ・データベースのオープン（フラッシュバック・データベース操作またはポイント・イン・タイム・メディア・リカバリのため）

RESETLOGS による本番データベースのオー

プン後のフォルト・トレランスのリストア（4-58 ページ）

RESETLOGS による本番データベースのオー

プン後のフォルト・トレランスのリストア（4-58 ページ）


停止の概要

4.1.2 計画済の停止計画済の停止計画済の停止計画済の停止計画済の停止は、アプリケーションをサポートするテクノロジ・インフラストラクチャの定期メンテナンスのために必要です。これには、次のタスクが含まれます。

� ハードウェアのメンテナンス、修復およびアップグレード

� ソフトウェアのアップグレードとパッチ適用

� アプリケーションの変更とパッチ適用

� システムのパフォーマンスと管理性を向上するための変更

これらのタスクは、アプリケーションの可用性を継続するのにも適したときにスケジュールする必要があります。

表 4-4 に、プライマリ・サイトまたはセカンダリ・サイトのいずれかに影響を与える計画済の停止を示します。

表表表表 4-4 計画済の停止計画済の停止計画済の停止計画済の停止

停止範囲停止範囲停止範囲停止範囲説明説明説明説明例例例例

サイト全体現行の本番データベースが存在するサイト全体が使用不可能になります。通常は、事前に広く通知されます。

計画済の停電

サイト・メンテナンス

テスト・インフラストラクチャへの定期的な計画済のスイッチオーバー

ハードウェア・メンテナンス（ノードに影響）

データベース・サーバーでのハードウェア・メンテナンスです。データ

ベース・クラスタの 1 つのノードに制

限されます。

メモリー・カードや CPU ボードなどの障害コン

ポーネントの修復

データベース層の既存のノードへのメモリーまたは CPU の追加

ハードウェア・メンテナンス（クラスタ全体に影響）

データベース・サーバー・クラスタでのハードウェア・メンテナンスです。

クラスタにノードを追加する一部の場合

クラスタ・インターコネクトのアップグレードまたは修復

データベース層の停止を必要とするストレージ層のアップグレード

システム・ソフトウェア・メンテナンス（ノードに影響）

データベース・サーバーでのシステム・ソフトウェア・メンテナンスです。停止の範囲は、1 つのノードに制限さ

れます。

オペレーティング・システムなどのソフトウェア・コンポーネントのアップグレード

オペレーティング・システムの構成パラメータの変更

システム・ソフトウェア・メンテナンス（クラスタ全体に影響）

データベース・サーバー・クラスタでのシステム・ソフトウェア・メンテナンスです。

クラスタ・ソフトウェアのアップグレードまたはパッチ適用

ボリューム管理ソフトウェアのアップグレード

データベースの Oracle パッ

チのアップグレード

Oracle パッチのインストールによる計

画済の停止です。

特定の顧客問題を修正するための Oracle ソフト

ウェアへのパッチ適用

データベースの Oracle パッ

チ・セットまたはソフトウェアのアップグレード

Oracle パッチ・セットまたはソフト

ウェアのアップグレードによる計画済の停止です。

パッチ・セットを使用した Oracle ソフトウェア

へのパッチ適用

Oracle ソフトウェアのアップグレード

データベース・オブジェクトの再編成

主にパフォーマンスや管理性を向上する目的で、Oracle データベース・オブ

ジェクトの論理構造または物理編成を変更します。

Oracle データベースのオンライン再編

成機能を使用すると、再編成中にオブジェクトを使用できます。

異なる表領域へのオブジェクトの移動

パーティション表への表の変換

表の列の名前変更または削除

ストレージ・メンテナンスデータベース・ファイルが存在するストレージのメンテナンスです。

ASM への変換

ストレージの追加または削除

停止の管理 4-7

停止の概要

次の各項では、プライマリ・サイトとセカンダリ・サイトでの計画済の停止を削減するための推奨ベスト・プラクティスおよび準備事項について説明します。

� プライマリ・サイトでの計画済の停止の管理

� セカンダリ・サイトでの計画済の停止の管理

� セカンダリ・サイトでの計画済の停止の準備

4.1.2.1 プライマリ・サイトでの計画済の停止の管理プライマリ・サイトでの計画済の停止の管理プライマリ・サイトでの計画済の停止の管理プライマリ・サイトでの計画済の停止の管理プライマリ・サイトに本番データベースが含まれ、セカンダリ・サイトにスタンバイ・データベースが含まれる場合、プライマリ・サイトで発生する停止がも致命的です。これらの停止を解決することが、システムの可用性継続にとって不可欠です。

表 4-5 に、プライマリ・サイトでの計画済の停止に対応するためのリカバリ手順の概要を示します。複数のリカバリ手順を必要とする停止については、この表に、4-61 ページから始まる4.4 項「計画済の停止による停止時間の回避または短縮」の詳細な説明へのリンクが含まれます。

プラットフォーム移行プライマリ・データベースとスタンバイ・データベースのオペレーティング・システム・プラットフォームを変更します。

Linux オペレーティング・システムへの移行

ロケーション移行プライマリ・データベースの物理的な場所を変更します。

あるデータ・センターから別のデータ・センターへのプライマリ・データベースの移行

表表表表 4-5 プライマリ・サイトでの計画済の停止のリカバリ手順プライマリ・サイトでの計画済の停止のリカバリ手順プライマリ・サイトでの計画済の停止のリカバリ手順プライマリ・サイトでの計画済の停止のリカバリ手順

停止範囲停止範囲停止範囲停止範囲原因原因原因原因Oracle Database 10g

RAC を使用したを使用したを使用したを使用したOracle Database 10g



サイトサイト停止停止後のデータベースの再起動

停止後のデータベースの再起動

1. スタンバイ・データベースでのデータベース・スイッチオーバー（4-22 ペー

ジ）

2. 完全サイト・フェイルオーバー（4-12 ペー

ジ）

3. アプリケーション・フェイルオーバー（4-27ページ）


ジ）

2. 完全サイト・フェイルオーバー（4-12 ペー

ジ）


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

ハードウェア・メンテナンス（ノードに影響）


自動管理（4-76 ペー

ジの「システム・メンテナンス」を参照）


ジ）


自動管理（4-76 ペー

ジの「システム・メンテナンス」を参照）

表表表表 4-4 計画済の停止（続き）計画済の停止（続き）計画済の停止（続き）計画済の停止（続き）

停止範囲停止範囲停止範囲停止範囲説明説明説明説明例例例例


停止の概要


ハードウェア・メンテナンス（クラスタ全体に影響）

システム・ソフトウェア・メンテナンス（クラスタ全体に影響）

適用なし停止後のデータベースの再起動

適用なし 1. スタンバイ・データベースでのデータベース・スイッチオーバー（4-22 ペー

ジ）



システム・ソフトウェア・メンテナンス（ノードに影響）


システム・メンテナンス（4-76 ページ）

による自動管理


ジ）


システム・メンテナンス（4-76 ページ）

による自動管理


Real Application Clusters のCluster Ready Service（CRS）の

アップグレード

適用なし一般的に CRS アップ

グレードはオンラインで実行できるため停止は不要

適用なし一般的に CRS アップ

グレードはオンラインで実行できるため停止は不要


データベースの Oracleパッチのアップグレード


RAC データベース・

パッチ（4-63 ページ）


ジ）


RAC データベース・

パッチ（4-63 ページ）


データベースの Oracleパッチ・セットまたはソフトウェアのアップグレード（自動ストレージ管理（ASM）およ

び CRS の一

部のアップグレードを含む）



データベース・アップグレード（4-65ページ）

データベース・アップグレード（4-65ページ）

表表表表 4-5 プライマリ・サイトでの計画済の停止のリカバリ手順（続き）プライマリ・サイトでの計画済の停止のリカバリ手順（続き）プライマリ・サイトでの計画済の停止のリカバリ手順（続き）プライマリ・サイトでの計画済の停止のリカバリ手順（続き）





停止の管理 4-9

停止の概要

4.1.2.2 セカンダリ・サイトでの計画済の停止の管理セカンダリ・サイトでの計画済の停止の管理セカンダリ・サイトでの計画済の停止の管理セカンダリ・サイトでの計画済の停止の管理クライアントは常にプライマリ・サイトにアクセスするため、セカンダリ・サイトでの停止は可用性に影響しません。セカンダリ・サイトで停止が発生したときにプライマリ・サイトで同時障害が発生すると、RTO に影響する可能性があります。セカンダリ・サイトで発生する停止は、可用性に影響を与えることなく管理できます。大保護データベース・モードで構成している場合は、本番データベースで停止時間が発生しないように、スタンバイ・インスタンスまたはデータベースで計画済の停止を実行する前に保護モードをダウングレードします。

表 4-6 に、セカンダリ・サイトでの計画済の停止に対応するためのリカバリ手順をまとめます。



データベース・オブジェクトの再編成（4-73 ページ）


（4-73 ページ）


（4-73 ページ）


（4-73 ページ）


ストレージ・メンテナンス

ストレージ・メンテナンス（4-62ページ）

ストレージ・メンテナンス（4-62 ページ）




プラットフォーム・メンテナンス

データベースのプラットフォームまたはロケーションの移行（4-67 ペー

ジ）

データベースのプラットフォームまたはロケーションの移行（4-67 ページ）




ロケーション・メンテナンス

データベースのプラットフォームまたはロケーションの移行（4-67 ペー

ジ）




表表表表 4-6 セカンダリ・サイトでの計画済の停止の管理セカンダリ・サイトでの計画済の停止の管理セカンダリ・サイトでの計画済の停止の管理セカンダリ・サイトでの計画済の停止の管理

停止タイプ停止タイプ停止タイプ停止タイプ原因原因原因原因Data Guard を使用したを使用したを使用したを使用したOracle Database 10g Oracle Database 10g（（（（MAA））））

サイトサイト停止停止前 :

セカンダリ・サイトでの計画済の停止の準備（4-11 ページ）

停止後 :

セカンダリ・サイトでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア（4-56 ページ）

停止前 :


停止後 :


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

管理リカバリ・プロセス（MRP）を実行している

ノードでのハードウェアまたはソフトウェア・メンテナンス

停止前 :


停止前 :



MRP を実行していないノー

ドでのハードウェアまたはソフトウェア・メンテナンス

適用なしプライマリ・スタンバイ・ノードまたはインスタンスは、管理リカバリ・プロセスで適用されるREDO ログを受信するため、影響

はありません。

停止後 : 使用可能になったら、ノー

ドとインスタンスを再起動します。

表表表表 4-5 プライマリ・サイトでの計画済の停止のリカバリ手順（続き）プライマリ・サイトでの計画済の停止のリカバリ手順（続き）プライマリ・サイトでの計画済の停止のリカバリ手順（続き）プライマリ・サイトでの計画済の停止のリカバリ手順（続き）






計画外の停止からのリカバリ

4.1.2.3 セカンダリ・サイトでの計画済の停止の準備セカンダリ・サイトでの計画済の停止の準備セカンダリ・サイトでの計画済の停止の準備セカンダリ・サイトでの計画済の停止の準備大保護モードを使用するセカンダリ・サイトで計画済の停止を実行する際にサービスの提供

を継続するには、大保護モードを一時的に大可用性モードまたは大パフォーマンス・モードにダウングレードします。セカンダリ・サイトのメンテナンスをスケジュールする場合、サイト全体またはクラスタ全体の停止期間が増加するほどスタンバイ・データベースと本番データベースの差異が拡大し、それによりフォルト・トレランスを回復するための時間も増加することに注意してください。 Data Guard の保護モードの概要は、2-25 ページの 2.4.2 項

「データ保護モード」を参照してください。

4.2 計画外の停止からのリカバリ計画外の停止からのリカバリ計画外の停止からのリカバリ計画外の停止からのリカバリこの項では、様々なタイプの計画外の停止からリカバリするためのベスト・プラクティスについて説明します。


� 完全サイト・フェイルオーバー

� スタンバイ・データベースでのデータベース・フェイルオーバー

� スタンバイ・データベースでのデータベース・スイッチオーバー

� 計画外の停止からの RAC リカバリ

� アプリケーション・フェイルオーバー

� ディスクおよびストレージ障害後の ASM リカバリ

� データ破損（データ障害）からのリカバリ

� 人為的エラーからのリカバリ


ハードウェアまたはソフトウェア・メンテナンス（クラスタ全体に影響）

適用なし停止前 :


停止後 :



Oracle パッチとソフトウェ

アのアップグレード

アップグレードのために停止時間が必要ですが、構成が大保護データベース・モードでないかぎり、プライマリ・ノードに影響はありません。

アップグレードのために停止時間が必要ですが、構成が大保護データベース・モードでないかぎり、プライマリ・ノードに影響はありません。

表表表表 4-6 セカンダリ・サイトでの計画済の停止の管理（続き）セカンダリ・サイトでの計画済の停止の管理（続き）セカンダリ・サイトでの計画済の停止の管理（続き）セカンダリ・サイトでの計画済の停止の管理（続き）

停止タイプ停止タイプ停止タイプ停止タイプ原因原因原因原因Data Guard を使用したを使用したを使用したを使用したOracle Database 10g Oracle Database 10g（（（（MAA））））

停止の管理 4-11


4.2.1 完全サイト・フェイルオーバー完全サイト・フェイルオーバー完全サイト・フェイルオーバー完全サイト・フェイルオーバー完全サイト・フェイルオーバーでは、本番環境の負荷に対応するよう準備されたセカンダリ・サイトにデータベース、中間層アプリケーション・サーバーおよびすべてのユーザー接続をフェイルオーバーします。

4.2.1.1 完全サイト・フェイルオーバーを使用する時期完全サイト・フェイルオーバーを使用する時期完全サイト・フェイルオーバーを使用する時期完全サイト・フェイルオーバーを使用する時期スタンバイ・サイトが前提条件を満たしている場合、次の状況では完全サイト・フェイルオーバーをお薦めします。

� プライマリ・サイトの障害（自然災害や悪意のある攻撃など）

� プライマリ・ネットワークの接続障害

� プライマリ・サイトの電源障害

4.2.1.2 完全サイト・フェイルオーバーのベスト・プラクティス完全サイト・フェイルオーバーのベスト・プラクティス完全サイト・フェイルオーバーのベスト・プラクティス完全サイト・フェイルオーバーのベスト・プラクティス次のプラクティスを使用することで、サイト・フェイルオーバーを数分以内に迅速に完了できます。

� Data Guard 構成のベスト・プラクティスを使用します。

� 目標リカバリ時間（RTO）が 30 秒未満の環境では、Data Guard ファスト・スタート・フェイルオーバーを使用してスタンバイ・データベースに自動的にフェイルオーバーします。

� 起動時間を節約するため、セカンダリ・サイトで中間層アプリケーション・サーバーの実行を維持します。

� DNS フェイルオーバー手順を自動化します。

データ損失があるかどうかは、Data Guard 構成と、同期または非同期 REDO 転送の使用状況に応じて変化します。

4.2.1.3 修復ソリューション修復ソリューション修復ソリューション修復ソリューションプライマリ・サイトとセカンダリ・サイトの WAN トラフィック・マネージャにより、サイト・フェイルオーバー機能が提供されます。 WAN トラフィック・マネージャは、プライマリ・サイト（またはプライマリ・サイトの特定のアプリケーション）がアクセス不可能になった場合に、自動的にトラフィックをリダイレクトします。スイッチオーバーの際には、この操作を手動で起動してセカンダリ・サイトに切り替えることも可能です。トラフィックは、停止またはスイッチオーバーによりプライマリ・サイトでサービスを提供できなくなった場合にのみ、セカンダリ・サイトに転送されます。プライマリ・サイトが停止すると、ユーザー・トラフィックはセカンダリ・サイトに自動的に転送されます。

図 4-1 は、サイト・フェイルオーバー前の可能なネットワーク・ルートを示しています。

1. クライアント・リクエストは、プライマリ・サイトのクライアント層に入り、WAN トラフィック・マネージャによって転送されます。

2. クライアント・リクエストは、ファイアウォールを介して非武装地帯（DMZ）からアプリケーション・サーバー層に送信されます。

3. リクエストは、アクティブなロード・バランサを介してアプリケーション・サーバーに転送されます。

4. リクエストは、別のファイアウォールを介してデータベース・サーバー層に送信されます。

5. アプリケーション・リクエストは、必要に応じて RAC インスタンスにルーティングされます。

6. レスポンスは、同様の経路でアプリケーションとクライアントに戻されます。



図図図図 4-1 サイト・フェイルオーバー前のネットワーク・ルートサイト・フェイルオーバー前のネットワーク・ルートサイト・フェイルオーバー前のネットワーク・ルートサイト・フェイルオーバー前のネットワーク・ルート

hb hb

hb

hb hb

hb

hbhb

hbhb



図 4-2 は、サイト・フェイルオーバー後のネットワーク・ルートを示しています。クライアントまたはアプリケーション・リクエストは、セカンダリ・サイトのクライアント層に入り、プライマリ・サイトとまったく同じ経路をたどります。

図図図図 4-2 サイト・フェイルオーバー後のネットワーク・ルートサイト・フェイルオーバー後のネットワーク・ルートサイト・フェイルオーバー後のネットワーク・ルートサイト・フェイルオーバー後のネットワーク・ルート

次の手順では、フェイルオーバーまたはスイッチオーバーのネットワーク・トラフィックに対する影響について説明します。

1. 管理者は、本番データベースをセカンダリ・サイトにフェイルオーバーまたはスイッチオーバーします。この操作は、Data Guard ファスト・スタート・フェイルオーバーを使用している場合は自動的に処理されます。

2. 管理者は、セカンダリ・サイトの中間層アプリケーション・サーバーを起動します（まだ実行されていない場合）。

3. WAN トラフィック・マネージャによるセカンダリ・サイトの選択は、サイト全体障害の場合は自動化できます。セカンダリ・サイトの WAN トラフィック・マネージャは、セカンダリ・サイトのロード・バランサの仮想 IP アドレスを戻します。クライアントは、その後の再接続で自動的に転送されます。この場合のサイト・フェイルオーバーは、自動ドメイン・ネーム・システム（DNS）・フェイルオーバーにより実行されます。

hb

hb hb

hb

hb hb

hb

hbhb

hbhb



別の方法として、DNS 管理者は、WAN トラフィック・マネージャの選択をサイト全体または特定のアプリケーションに対応するセカンダリ・サイトに手動で変更できます。次に、手動 DNS フェイルオーバーの例を示します。

a. セカンダリ・サイトのロード・バランサを参照するよう DNS を変更します。

マスター（プライマリ）DNS サーバーは、新規ゾーン情報で更新され、この変更はDNS NOTIFY で広く通知されます。

スレーブ DNS サーバーは、DNS NOTIFY 通知によりゾーンの更新を認識し、新規ゾーン情報を取得します。

b. キャッシュ DNS サーバーから関連するレコードを消去します。

キャッシュ DNS サーバーは、主にパフォーマンスとレスポンス速度を向上するために使用します。キャッシュ・サーバーは、ホスト問合せに応答して権威 DNS サーバーから情報を取得し、そのデータをローカルに保存（キャッシュ）します。同じデータに対する 2 回目のリクエストや後続のリクエストがあると、キャッシュ DNS サーバーは、レスポンスの TTL 値が期限切れになるまでローカルに保存したデータ（キャッシュ）を使用して応答します。期限切れになると、ゾーン・マスターからのデータはリフレッシュされます。 DNS レコードがプライマリ DNS サーバーで変更される場合、キャッシュ DNS サーバーは、TTL が期限切れになるまでキャッシュされたレコードの変更を取得しません。キャッシュをフラッシュすることでキャッシュ DNS サーバーを強制的に権威 DNS サーバーに再接続し、更新された DNS 情報を取得します。

キャッシュのフラッシュは、使用中の DNS サーバーがフラッシュ機能をサポートしている場合に実行します。一般的な DNS BIND バージョンのフラッシュ機能は、次のとおりです。

BIND 9.3.0: コマンド rndc flushname nameにより、キャッシュから個々のエントリをフラッシュします。

BIND 9.2.0 およびおよびおよびおよび 9.2.1: コマンド rndc flushにより、キャッシュ全体をフラッシュできます。

BIND 8 およびおよびおよびおよび BIND 9（（（（9.1.3 以下）以下）以下）以下）: ネーム・サーバーを再起動してキャッシュを消去します。

c. ローカル DNS サービス・キャッシュをリフレッシュします。

一部のオペレーティング・システムでは、DNS 情報がローカル・ネーム・サービス・キャッシュにローカルにキャッシュされることがあります。その場合、DNS の更新が迅速に認識されるように、このキャッシュも消去する必要があります。

Solaris: nscd

Linux: /etc/init.d/nscd restart

Microsoft Windows: ipconfig /flushdns

Apple Mac OS X: lookupd -flushcache

d. セカンダリ・サイトのロード・バランサで、セカンダリ・サイトの中間層アプリケーション・サーバーにトラフィックを転送します。

e. セカンダリ・サイトでクライアント・リクエストを処理する準備が整いました。

フェイルオーバーは、クライアントの Web ブラウザにも依存します。ほとんどのブラウザ・アプリケーションでは、一定期間 DNS エントリがキャッシュされます。したがって、停止の発生時に進行中だったセッションは、キャッシュ・タイムアウトの期限切れまでフェイルオーバーされない可能性があります。このようなクライアントでサービスを再開するには、ブラウザを一度終了して再起動します。

注意注意注意注意 : マスター・サーバーとスレーブ・サーバーは、権威ネーム・サーバーです。したがって、これらのサーバーには信頼できる DNS 情報が含まれます。



4.2.2 スタンバイ・データベースでのデータベース・フェイルオーバースタンバイ・データベースでのデータベース・フェイルオーバースタンバイ・データベースでのデータベース・フェイルオーバースタンバイ・データベースでのデータベース・フェイルオーバーフェイルオーバーは、スタンバイ・データベースの 1 つを本番データベースのロールに移行する操作です。フェイルオーバー操作は、本番データベースに計画外の障害が発生し、一定の時間内にそのデータベースをリカバリできない場合に起動します。

Data Guard では、次の方法によりフェイルオーバーを実行できます。

� Oracle Enterprise Manager の使用（4-18 ページの 4.2.2.2.1 項「Enterprise Manager を使用した Data Guard フェイルオーバーの実行」を参照）


� SQL 文の発行（4-21 ページの 4.2.2.2.2 項「SQL を使用したフィジカル・スタンバイ・データベースへのフェイルオーバー」を参照）

Data Guard フェイルオーバーは、スタンバイ・データベースを本番データベースに移行するための一連の手順です。スタンバイ・データベースは、原則として本番データベースのロールを引き継ぎます。 Data Guard フェイルオーバーは、アプリケーション・フェイルオーバーにより実行されますが、先にサイト・フェイルオーバーが実行される場合もあります。 Data Guardフェイルオーバー後のセカンダリ・サイトには、本番データベースが含まれます。以前の本番データベースは、弾力性を回復するために新規スタンバイ・データベースとして復元する必要があります。スタンバイ・データベースは、フラッシュバック・データベースを使用して迅速に再作成できます。 4-53 ページの 4.3.2 項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。

Data Guard のフェイルオーバー・プロセスは、ファスト・スタート・フェイルオーバー機能を使用して完全自動で実行するか、ユーザーが手動で起動します（手動フェイルオーバー）。ファスト・スタート・フェイルオーバーでは、手動操作を必要とするプロセスの不確実性を排除できます。また、この機能を使用すると、システム停止が検出されてから数秒以内にゼロ・データ損失のフェイルオーバーを自動的に実行できます。手動フェイルオーバーは、ユーザーの決定に基づくフェイルオーバー・プロセスに対応しています。手動フェイルオーバーは、Oracle Enterprise Manager の使用、Oracle Data Guard Broker コマンドライン・インタフェースでのコマンドの発行、または SQL 文の発行により実行できます（後続の項を参照してください）。

通常、フェイルオーバー操作は、データをほとんど失わないか、まったく失うことなく 1 分未満で完了します。フェイルオーバーの詳細は、『Oracle Data Guard 概要および管理』を参照してください。

関連資料関連資料関連資料関連資料 : Enterprise Manager または Data Guard Broker コマンドラインを使用してデータベース・フェイルオーバーを実行する方法の詳細は、


関連資料関連資料関連資料関連資料 : フェイルオーバー操作の適化の詳細は、次のホワイト・ペーパーを参照してください。

� 『Oracle Database 10g Release 2 Best Practices: Data Guard Fast-Start Failover』（http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_FastStartFailoverBestPractices.pdf）

� 『Oracle Database 10g Release 2 Best Practices: Data Guard Switchover and Failover』

（http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_SwitchoverFailoverBestPractices.pdf）



4.2.2.1 Data Guard フェイルオーバーを実行する時期フェイルオーバーを実行する時期フェイルオーバーを実行する時期フェイルオーバーを実行する時期プライマリ・データベースの障害を、ローカル・バックアップやフラッシュバック・テクノロジを使用して目標リカバリ時間（RTO）内に修復できない場合、Data Guard を使用する必要があります。

ユーザーが開始する手動フェイルオーバーは、次のような計画外の停止が発生した場合に実行します。

� プライマリ・データベースが使用不可能となるサイト障害

� 一定の時間内に修復できないユーザー・エラー

� 本番アプリケーションに影響を及ぼすデータ障害

フェイルオーバーでは、以前の本番データベースをスタンバイ・データベースとして復元し、現在の環境にフォルト・トレランスを回復する必要があります。スタンバイ・データベースは、フラッシュバック・データベースを使用して迅速に復元できます。 4-53 ページの 4.3.2 項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。

4.2.2.2 Data Guard フェイルオーバーを実装するためのベスト・プラクティスフェイルオーバーを実装するためのベスト・プラクティスフェイルオーバーを実装するためのベスト・プラクティスフェイルオーバーを実装するためのベスト・プラクティスファスト・スタート・フェイルオーバーは、完全自動のため、ユーザーの操作を必要としません。ユーザーが起動する手動フェイルオーバーは、Enterprise Manager、Data Guard Broker コマンドライン・インタフェースまたは SQL*Plus コマンドを使用して実行できます。

� ファスト・スタート・フェイルオーバーファスト・スタート・フェイルオーバーファスト・スタート・フェイルオーバーファスト・スタート・フェイルオーバー : ファスト・スタート・フェイルオーバーの実行時に考慮する必要のある操作上のベスト・プラクティスはありません。ただし、2-42 ページの 2.4.7.2.2 項「ファスト・スタート・フェイルオーバーのベスト・プラクティス」に記載されているすべての構成上のベスト・プラクティスを検討することは非常に重要です。

� 手動フェイルオーバー手動フェイルオーバー手動フェイルオーバー手動フェイルオーバー : 手動フェイルオーバーを実行する場合は、4-21 ページの 4.2.2.2.2 項「SQL を使用したフィジカル・スタンバイ・データベースへのフェイルオーバー」に記載されているベスト・プラクティスと、2-43 ページの 2.4.7.2.3 項「手動フェイルオーバーのベスト・プラクティス」に記載されている構成上のベスト・プラクティスに従います。

Real Application Clusters に関連する手動フェイルオーバーでは、フェイルオーバーを実行する前にスタンバイ・データベースのすべてのセカンダリ RAC インスタンスにSHUTDOWN ABORT文を発行します。


� Enterprise Manager を使用した Data Guard フェイルオーバーの実行

� SQL を使用したフィジカル・スタンバイ・データベースへのフェイルオーバー

� SQL を使用したロジカル・スタンバイ・データベースへのフェイルオーバー

関連資料関連資料関連資料関連資料 :『Oracle Database 10g Release 2 Best Practices: Data Guard Switchover and Failover』




4.2.2.2.1 Enterprise Manager を使用したを使用したを使用したを使用した Data Guard フェイルオーバーの実行フェイルオーバーの実行フェイルオーバーの実行フェイルオーバーの実行 Data Guard フェイルオーバーの手順は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方で同じです。次のスクリーン・ショットは、Oracle Enterprise Manager を使用してフェイルオーバーを実行する方法を示しています。

図 4-3 では、Data Guard の「概要」ページに、プライマリ・データベースへのアクセスに関する問題が発生したことを示す ORA-16625 エラー・ステータスが表示されています。

図図図図 4-3 ORA-16625 エラーを示すエラーを示すエラーを示すエラーを示す Data Guard の「概要」ページの「概要」ページの「概要」ページの「概要」ページ

DR_Sales をプライマリ・ロールに移行するには、「スタンバイ・データベース」表で DR_Salesを選択し、「フェイルオーバー」「フェイルオーバー」「フェイルオーバー」「フェイルオーバー」をクリックします。



図 4-4 は、フェイルオーバーの「確認」ページを示しています。

図図図図 4-4 フェイルオーバーの「確認」ページフェイルオーバーの「確認」ページフェイルオーバーの「確認」ページフェイルオーバーの「確認」ページ

プライマリ・データベースで障害が発生し、一定の時間内にそのデータベースをリカバリできないと判断した場合、フェイルオーバー操作を起動します。フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方が存在する構成では、フィジカル・スタンバイ・データベースをフェイルオーバー・ターゲットとして使用することをお薦めします。これにより、ロジカル・スタンバイ・データベースを新規プライマリ・データベースのロジカル・スタンバイとして引き続き使用できます。ロジカル・スタンバイを対象にフェイルオーバーを実行する場合、新規プライマリ・データベースのバックアップを使用して構成内のフィジカル・スタンバイを再作成する必要があります。

フェイルオーバー操作では、次のいずれかのタイプを選択できます。

� 完全

この操作では、使用可能なすべての REDO をスタンバイ・データベースに適用して、データ損失を小化するよう試みます。

� 即時

スタンバイ・データベースに追加データは適用されません。データは失われる可能性があります。これは、も高速なタイプのフェイルオーバーです。



図 4-5 は、フェイルオーバー操作の進行状況を示しています。

図図図図 4-5 フェイルオーバーの進行状況のページフェイルオーバーの進行状況のページフェイルオーバーの進行状況のページフェイルオーバーの進行状況のページ

フェイルオーバー中に、選択されたスタンバイ・データベース（ターゲット・スタンバイ・データベース）はプライマリ・ロールに移行します。フェイルオーバー・ターゲットがフィジカル・スタンバイ・データベースの場合、データベースは再起動されます。完了すると、図 4-6のように、Data Guard の「概要」ページに更新された構成が反映されます。

図図図図 4-6 フェイルオーバー完了後のフェイルオーバー完了後のフェイルオーバー完了後のフェイルオーバー完了後の Data Guard の「概要」ページの「概要」ページの「概要」ページの「概要」ページ

この図の「Data Guard ステータス」列には、元のプライマリ・データベース（North_Sales）が無効化されたため、フィジカル・スタンバイ・データベースとして再有効化されるまでEnterprise Manager で管理できなくなったことが示されています。



4.2.2.2.2 SQL を使用したフィジカル・スタンバイ・データベースへのフェイルオーバーを使用したフィジカル・スタンバイ・データベースへのフェイルオーバーを使用したフィジカル・スタンバイ・データベースへのフェイルオーバーを使用したフィジカル・スタンバイ・データベースへのフェイルオーバーフィジカル・スタンバイ・データベースにフェイルオーバーするには、次の手順を実行します。

1. スタンバイ・データベースが Real Application Clusters データベースの場合、すべての追加スタンバイ・インスタンスに SHUTDOWN ABORTを発行します。

2. ターゲット・スタンバイ・データベースに次の SQL コマンドを発行してフェイルオーバーを開始します。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

プライマリ・サイトとスタンバイ・サイト間のネットワークが使用できない場合、スタンバイ RFS プロセスは、停止する前に通常の TCP タイムアウト処理を通じてネットワーク接続がタイムアウトするのを待機します。 RFS プロセスが TCP タイムアウト処理中の場合、スタンバイ・データベースは、RECOVER MANAGED STANDBY DATABASE FINISH文にFORCEキーワードを含めないかぎりフェイルオーバーできません。

3. フィジカル・スタンバイ・データベースをプライマリ・ロールに変換します。

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

4. スタンバイ・データベースを後に起動してから読取り専用で一度もオープンしていない場合、次の SQL 文を発行して新規プライマリ・データベースをオープンします。

ALTER DATABASE OPEN;

5. スタンバイ・データベースを読取り専用でオープンしている場合、REDO Apply を開始する前に新規プライマリ・データベースを再起動します。

4.2.2.2.3 SQL を使用したロジカル・スタンバイ・データベースへのフェイルオーバーを使用したロジカル・スタンバイ・データベースへのフェイルオーバーを使用したロジカル・スタンバイ・データベースへのフェイルオーバーを使用したロジカル・スタンバイ・データベースへのフェイルオーバーロジカル・スタンバイ・データベースにフェイルオーバーするには、次の手順を実行します。

1. スタンバイ・データベースが Real Application Clusters データベースの場合、すべての追加スタンバイ・インスタンスに SHUTDOWN ABORTを発行します。

2. ターゲット・スタンバイ・データベースに次の SQL コマンドを発行してフェイルオーバーを開始します。

ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY;

この文により、RFS プロセスの停止、残っている REDO データの適用、SQL Apply の停止、およびプライマリ・ロールでのロジカル・スタンバイ・データベースのアクティブ化が実行されます。フェイルオーバーの実行前にスタンバイ REDO ログ・ファイルの REDO適用を待機しない場合は、この文の FINISH APPLY句を省略します。

FINISH APPLY句を省略するとフェイルオーバーが高速化しますが、スタンバイ REDO ログの未適用の REDO データはすべて失われます。失われる REDO の量を評価するには、V$LOGSTDBY_PROGRESSビューを問い合せます。 LATEST_SCN列の値はプライマリ・データベースから受信された後の SCN を示し、APPLIED_SCN列の値はスタンバイ・データベースに適用された後の SCN を示します。これら 2 つの値の間の SCN は、すべて失われます。



4.2.3 スタンバイ・データベースでのデータベース・スイッチオーバースタンバイ・データベースでのデータベース・スイッチオーバースタンバイ・データベースでのデータベース・スイッチオーバースタンバイ・データベースでのデータベース・スイッチオーバーOracle Data Guard により実行されるデータベース・スイッチオーバーは、スタンバイ・データベースと本番データベースの間でロールを切り替えるための一連の手順を含む計画された移行操作です。スイッチオーバー操作に成功すると、スタンバイ・データベースが本番ロールを引き継ぎ、本番データベースがスタンバイ・データベースとなります。 RAC 環境のスイッチオーバーでは、本番用とスタンバイ用のデータベースごとにただ 1 つのインスタンスがアクティブである必要があります。データベースのロール管理の分野では、スイッチバックという用語も使用されることがあります。スイッチバックは、スイッチオーバー操作の後にデータベースのロールを元の状態に戻す操作です。

Data Guard では、次の方法により動的にロールを変更できます。

� Enterprise Manager の使用（4-23 ページの 4.2.3.2.1 項「Enterprise Manager を使用したData Guard スイッチオーバーの実行」を参照）


� SQL コマンドの発行（4-25 ページの 4.2.3.2.2 項「SQL を使用したフィジカル・スタンバイ・データベースへの Data Guard スイッチオーバー」および 4-25 ページの 4.2.3.2.3 項「SQLを使用したロジカル・スタンバイ・データベースへの Data Guard スイッチオーバー」を参照）

4.2.3.1 Data Guard スイッチオーバーを実行する時期スイッチオーバーを実行する時期スイッチオーバーを実行する時期スイッチオーバーを実行する時期スイッチオーバーは、計画された操作です。スイッチオーバーは、本番データベースとスタンバイ・データベースの間でデータベース・ロールを切り替える機能です。本番データベースが起動しており、ターゲット・スタンバイ・データベースが使用可能で、すべてのアーカイブREDO ログが使用できる場合、いつでもスイッチオーバーを実行できます。通常、スイッチオーバーは 5 分未満で完了しますが、状況によっては 1 分未満にまで適化されます。スイッチオーバーは、次のような状況で役立ちます。

� 計画されたメンテナンス（本番ホストでのハードウェア・メンテナンスやファームウェア・パッチ適用など）

� 本番データベースをオープンしたままでのデータ障害の解決

� セカンダリ・リソースのテストと検証（障害時リカバリの準備状況をテストする手段として）

スイッチオーバーは、次の場合には使用できないか、または効果がありません。

� アーカイブ REDO ログが失われている場合

� ポイント・イン・タイム・リカバリが必要な場合

� 本番データベースがオープンしておらず、オープンできない場合

関連資料関連資料関連資料関連資料 : Enterprise Manager または Data Guard Broker コマンドラインを使用してデータベース・スイッチオーバーを実行する方法の詳細は、




4.2.3.2 Data Guard スイッチオーバーを実装するためのベスト・プラクティススイッチオーバーを実装するためのベスト・プラクティススイッチオーバーを実装するためのベスト・プラクティススイッチオーバーを実装するためのベスト・プラクティススイッチオーバーを実行する前に、2-40 ページの 2.4.7.1.1 項「スイッチオーバーのベスト・プラクティス」に記載されている構成上のベスト・プラクティスに従うと同時に、次の操作上のベスト・プラクティスに従います。

1. SQL コマンドの ALTER SYSTEM KILL SESSIONを発行して、すべてのセッションを切断します（存在する場合）。

2. AQ_TM_PROCESSESを 0に設定してジョブ処理を停止します。

3. NODELAYキーワードを使用してスタンバイ・データベースのログ適用サービスを停止および再起動し、指定されている適用遅延をすべて取り消します。

� フィジカル・スタンバイ・データベースの場合、次のように実行します。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE NODELAY;

� ロジカル・スタンバイ・データベースの場合、次のように実行します。

ALTER DATABASE STOP LOGICAL STANDBY APPLY;ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NODELAY;

次の各項で、スイッチオーバーの実行方法について説明します。

� Enterprise Manager を使用した Data Guard スイッチオーバーの実行

� SQL を使用したフィジカル・スタンバイ・データベースへの Data Guard スイッチオーバー

� SQL を使用したロジカル・スタンバイ・データベースへの Data Guard スイッチオーバー

4.2.3.2.1 Enterprise Manager を使用したを使用したを使用したを使用した Data Guard スイッチオーバーの実行スイッチオーバーの実行スイッチオーバーの実行スイッチオーバーの実行 Enterprise Managerを使用した Data Guard スイッチオーバーの手順は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方で同じです。

1. プライマリ・データベースに移行するスタンバイ・データベースを選択します。

2. 「スイッチオーバー」「スイッチオーバー」「スイッチオーバー」「スイッチオーバー」をクリックします。

3. スイッチオーバー操作を続ける場合は、「はい」「はい」「はい」「はい」をクリックします。取り消す場合は、「い「い「い「いいえ」いえ」いえ」いえ」をクリックします。

図 4-7 は、スイッチオーバーの「確認」ページを示しています。

図図図図 4-7 スイッチオーバー操作の確認スイッチオーバー操作の確認スイッチオーバー操作の確認スイッチオーバー操作の確認

関連資料関連資料関連資料関連資料 :『Oracle Database 10g Release 2 Best Practices: Data Guard Switchover and Failover』




図 4-8 は、スイッチオーバー中に表示される「処理中」ページを示しています。

図図図図 4-8 スイッチオーバー時の「処理中」ページスイッチオーバー時の「処理中」ページスイッチオーバー時の「処理中」ページスイッチオーバー時の「処理中」ページ

図 4-9 は、スイッチオーバー成功後の Data Guard の「概要」ページを示しています。

図図図図 4-9 スイッチオーバー後の新規プライマリ・データベーススイッチオーバー後の新規プライマリ・データベーススイッチオーバー後の新規プライマリ・データベーススイッチオーバー後の新規プライマリ・データベース



4.2.3.2.2 SQL を使用したフィジカル・スタンバイ・データベースへのを使用したフィジカル・スタンバイ・データベースへのを使用したフィジカル・スタンバイ・データベースへのを使用したフィジカル・スタンバイ・データベースへの Data Guard スイッチオースイッチオースイッチオースイッチオーバーバーバーバー Oracle Enterprise Manager を使用していない場合、SQL*Plus を使用してこの項の手順

（概要）を実行できます。これらの手順の詳細は、『Oracle Data Guard 概要および管理』を参照してください。

フィジカル・スタンバイ・データベースにスイッチオーバーするには、次の手順を実行します。

1. ユーザー・セッションを切断し（存在する場合）、アプリケーション処理を無効化または停止します。

2. プライマリ・データベースとスタンバイ・データベースが RAC の場合、1 つを除き、すべてのインスタンスを正しく停止します。この操作を迅速化するには、SHUTDOWN ABORTを発行します。

3. プライマリ・データベースに次の SQL 文を発行してスタンバイ・データベースに変換します。

ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN;

4. 前の手順の文が完了した後、次の操作を実行します。

a. 以前のスタンバイ・データベースに次の SQL 文を発行します。


b. COMMIT TO SWITCHOVER TO PRIMARY文の発行直後に、以前のプライマリ・データベースを新規スタンバイ・データベースとして再起動し、マウント状態に移行します。

5. スイッチオーバー・コマンドが完了したら、新規プライマリ・データベースに ALTER DATABASE OPEN文を発行し、オープン状態に移行します。

マウント状態からの新規プライマリ・データベースのオープンは、スタンバイ・データベースを後に起動してから読取り専用で一度もオープンしていない場合にのみ可能です。データベースを読取り専用でオープンしている場合、再起動する必要があります。

6. プライマリ・データベースとスタンバイ・データベースが RAC の場合、すべてのインスタンスを起動します。

7. ユーザー・セッションとアプリケーション処理を再開します。

4.2.3.2.3 SQL を使用したロジカル・スタンバイ・データベースへのを使用したロジカル・スタンバイ・データベースへのを使用したロジカル・スタンバイ・データベースへのを使用したロジカル・スタンバイ・データベースへの Data Guard スイッチオーバースイッチオーバースイッチオーバースイッチオーバー Oracle Enterprise Manager を使用していない場合、SQL*Plus を使用してこの項の手順（概要）を実行できます。これらの手順の詳細は、『Oracle Data Guard 概要および管理』を参照してください。

SQL*Plus コマンドを使用してスイッチオーバーを実行する場合、新規プライマリ・データベースに移行する予定のスタンバイ・データベースで、実際のスイッチオーバー前に LogMinerディクショナリを構築して現在のプライマリ・データベース（新規スタンバイ・データベース）に転送できます。これにより、スイッチオーバーの実行に要する合計時間を短縮できます。次の手順では、この適化された操作の実行方法について説明します。

1. プライマリ・データベースに次の SQL 文を発行して、現在のスタンバイ・データベースからの REDO 受信を有効化します。

ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;

2. 現在のロジカル・スタンバイ・データベースで、LogMiner ディクショナリを構築して現在のプライマリ・データベースに転送します。

ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;

3. ユーザー・セッションを切断し（存在する場合）、アプリケーション処理を無効化または停止します。

4. プライマリ・データベースとスタンバイ・データベースが RAC の場合、1 つを除き、すべてのインスタンスを正しく停止します。停止操作を適化するには、SHUTDOWN ABORTを使用します。



5. V$DATABASEビューの SWITCHOVER_STATUS列の問合せにより TO LOGICAL STANDBYが戻された場合、次の文を発行してプライマリ・データベースをスタンバイ・データベースに変換します。

ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY WITH SESSION SHUTDOWN;

6. 以前のスタンバイ・データベースに次の文を発行します。


7. プライマリ・データベースとスタンバイ・データベースが RAC 構成の場合、すべてのインスタンスを起動します。

8. ユーザー・セッションとアプリケーション処理を再開します。

4.2.4 計画外の停止からの計画外の停止からの計画外の停止からの計画外の停止からの RAC リカバリリカバリリカバリリカバリこのソリューションは、ノードまたはインスタンスで障害が発生したときに自動的に使用されます。稼働を続けるインスタンスは、障害インスタンスを自動的にリカバリし、自動クライアント・フェイルオーバーを潜在的に支援します。リカバリ時間は、データベースおよび RAC 構成上のベスト・プラクティスを導入することで制限できます。これにより、通常は、大規模なビジー・システムでデータ損失を発生させることなくインスタンス・リカバリ時間を数秒～数分に抑えることが可能です。

次のリカバリ方法を使用できます。

� 障害インスタンスの自動インスタンス・リカバリ

� 自動サービス再配置

� Oracle Cluster Registry

4.2.4.1 障害インスタンスの自動インスタンス・リカバリ障害インスタンスの自動インスタンス・リカバリ障害インスタンスの自動インスタンス・リカバリ障害インスタンスの自動インスタンス・リカバリソフトウェアまたはハードウェアの問題によりインスタンスが無効化されると、インスタンス障害が発生します。インスタンス障害の発生後、Oracle では、オンライン REDO ログ・ファイルを使用して、この項に記載されているように自動的にデータベース・リカバリを実行します。

RAC 環境のインスタンス・リカバリでは、障害インスタンスの再起動や、障害インスタンスで稼働していたアプリケーションのリカバリは行われません。サービス再配置と高速アプリケーション通知を使用すると、稼働していたアプリケーションを継続して実行できます（4-27 ページの 4.2.4.2 項「自動サービス再配置」を参照してください）。

いずれかのインスタンスが別のインスタンスに対してリカバリを実行する場合、リカバリする側のインスタンスは次の操作を実行します。

� 障害インスタンスによって生成された REDO ログ・エントリを読み取り、その情報を使用してコミット済トランザクションがデータベースに記録されていることを確認します。したがって、コミット済トランザクションのデータは失われません。

� 障害発生時にアクティブであったコミットされていないトランザクションをロールバックし、それらのトランザクションに使用されていたリソースを解放します。

複数のノード障害が発生しても、1 つのインスタンスが稼働しているかぎり、RAC では停止した他のインスタンスに対するインスタンス・リカバリが実行されます。 RAC データベースのすべてのインスタンスに障害が発生した場合、いずれか 1 つのインスタンスを再起動した時点でクラッシュ・リカバリが開始され、コミット済トランザクションはすべてリカバリされます。 Data Guard が使用可能であれば、すべてのインスタンスが停止したときに、Data Guard ファスト・スタート・フェイルオーバーを使用して自動的にフェイルオーバーを実行できます。



4.2.4.2 自動サービス再配置自動サービス再配置自動サービス再配置自動サービス再配置サービスの信頼性を確保するには、冗長インスタンスを構成してその中でフェイルオーバーを実行します。通常必要とするより多くのインスタンスを有効化して、サービスを提供します。ハードウェア障害が発生し、RAC データベース・インスタンスに悪影響を及ぼす場合、そのインスタンス上のサービスは、Cluster Ready Services（CRS）によって（DBCA またはEnterprise Manager での構成どおりに）別の使用可能なインスタンスに自動的に移動されます。その後、CRS は、障害の発生したノードとインスタンスを再起動するよう試みます。

CRS は、障害がサービスに影響を与えるタイミングを認識して自動的にサービスをフェイルオーバーし、サービスをサポートする稼働中のインスタンス全体にクライアントを再配置します。同時に、CRS は、障害インスタンスを再起動して依存リソースをシステムに再統合するよう試みます。高速アプリケーション通知（FAN）イベントを使用した障害の通知は、Oracleサーバー・アーキテクチャ内の様々なレベルで起動できます。レスポンスには、Oracle Notification Service（ONS）、アドバンスト・キューイングまたは FAN コールアウトを通じた外部パーティへの通知に加え、追跡用の障害記録、イベント・ロギング、およびアプリケーションへの割込みを含めることが可能です。障害ノードのサービスが停止すると、稼働を続けるノードから通知が発生します。サービスを提供するノードの場所と数は、アプリケーションに対して透過的です。自動再起動およびリカバリは、データベースのみでなくリスナーや ASMインスタンスなどのすべてのサブシステムで自動化されています。

4.2.4.3 Oracle Cluster RegistryOracle Cluster Registry ファイルが失われると、RAC および Cluster Ready Services の可用性が影響を受けます。 OCR ファイルは、自動で作成される物理バックアップからリストアするか、ocrconfigツールを使用して手動で作成されるエクスポート・ファイルからリストアすることが可能です。また、Oracle Database 10g リリース 2（10.2）以上では、単一の OCR デバイス障害に対応できるようオプションで OCR をミラー化できます。

4.2.5 アプリケーション・フェイルオーバーアプリケーション・フェイルオーバーアプリケーション・フェイルオーバーアプリケーション・フェイルオーバーアプリケーションは、アプリケーション・サービスが使用不可能になったときに効率的な通知を迅速に受信するよう適切に構成できます。通知が発生すると、アプリケーションは、稼働を続けているリソース（RAC データベースのノードや、フェイルオーバー後にプライマリ・ロールを継承したリモート・データ・センターのスタンバイ・データベースなど）に透過的に接続します。

RAC 構成では、迅速で透過的なアプリケーション・フェイルオーバーを実現するためにサービスは不可欠です。サービスが特定のインスタンスで使用不可能になると、そのサービスはクラスタ内の使用可能なインスタンスにフェイルオーバーされるため、アプリケーションでは処理を継続できます。クライアントは、高速アプリケーション通知（FAN）を介してサービス再配置を通知されます。

サービスは、Data Guard 構成のサイト間でのクライアント・フェイルオーバーにとっても不可欠です。 Data Guard 構成では、サイト障害の発生後、新規本番データベースが構成されて自動的に本番サービスが公開されるとともに、障害の発生した本番データベースでサービスが中断したことが FAN イベントを通じて関連するクライアントに通知されます。

FAN 通知とサービス再配置により、RAC 環境と Data Guard 環境で障害が発生したときにクライアントを自動的に素早くリダイレクトできます。

関連資料関連資料関連資料関連資料 :『Oracle Database Oracle Clusterware および Oracle Real Application Clusters 管理およびデプロイメント・ガイド』の Real Application Clusters でのストレージ管理に関する項


� 2-41 ページの 2.4.7.2 項「フェイルオーバー時のロール移行」

� 『Oracle Database 10g Release 2 Best Practices: Client Failover for Highly Available Oracle Databases』（http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm）



4.2.6 ディスクおよびストレージ障害後のディスクおよびストレージ障害後のディスクおよびストレージ障害後のディスクおよびストレージ障害後の ASM リカバリリカバリリカバリリカバリ表 4-7 に、様々な ASM 障害タイプの影響と推奨される修復方法をまとめます。

表表表表 4-7 ASM 障害タイプと推奨される修復方法障害タイプと推奨される修復方法障害タイプと推奨される修復方法障害タイプと推奨される修復方法

障害障害障害障害説明説明説明説明影響影響影響影響推奨される修復方法推奨される修復方法推奨される修復方法推奨される修復方法

ASM インスタ

ンス障害

ASM インスタ

ンスに障害が発生します。

同じノードから ASMストレージにアクセスするすべてのデータベース・インスタンスが停止します。

4-26 ページの計画外の停止からの

RAC リカバリを自動実行します。

RAC を使用していない場合、Data Guard フェイルオーバーを使用します

（4-17 ページの 4.2.2.2 項「Data Guardフェイルオーバーを実装するためのベスト・プラクティス」を参照）。

RAC と Data Guard を使用していない

場合、基礎となる問題を修正してからASM とデータベース・インスタンス

を再起動します。

ASM ディスク

障害

1 つ以上の

ASM ディスク

に障害が発生しますが、すべてのディスク・グループはオンラインのままです。

引き続きすべてのデータにアクセスできます。この状況は、標準

冗長性または高冗長性のディスク・グループでのみ発生します。

ASM は、残っているディスク・ドラ

イブを対象にリバランス操作を自動的に実行し、冗長性を再確立します。冗長性を回復するには、残っているディスク・ドライブに十分な空き領域が存在する必要があります。領域が不足している場合、リバランス操作はORA-15041 により失敗する可能性があ

ります。

注意注意注意注意 : 外部冗長性ディスク・グループ

では、ディスク障害から保護するためにストレージ・アレイでミラー化を使用する必要があります。ディスク障害

は ASM から隔離する必要があります。

データ領域ディスク・グループ障害

1 つ以上の

ASM ディスク

に障害が発生し、データ領域ディスク・グループがオフラインになります。

データ領域ディスク・グループにアクセスするデータベースが停止します。

Data Guard フェイルオーバーまたは

ローカル・リカバリを実行します（4-32 ページの 4.2.6.3 項「データ領域

ディスク・グループ障害」を参照）。

フラッシュ・リカバリ領域ディスク・グループ障害

1 つ以上の

ASM ディスク

に障害が発生し、フラッシュ・リカバリ領域ディスク・グループがオフラインになります。

フラッシュ・リカバリ領域ディスク・グループにアクセスするデータベースが停止します。

ローカル・リカバリまたは Data Guardフェイルオーバーを実行します（4-34ページの 4.2.6.4 項「フラッシュ・リカ

バリ領域ディスク・グループ障害」を参照）。



4.2.6.1 ASM インスタンス障害インスタンス障害インスタンス障害インスタンス障害ASM インスタンスに障害が発生すると、同じノードから ASM ストレージにアクセスするデータベース・インスタンスが停止します。

プライマリ・データベースで RAC を使用している場合、アプリケーション・フェイルオーバーが自動的に発生し、データベース・インスタンスに接続していたクライアントは、必要なサービスをクラスタ内で提供している残りのインスタンスに再接続されて処理を継続します。通常、リカバリ時間は数秒以内です。

プライマリ・データベースで RAC を使用していない場合、ASM インスタンス障害が発生するとデータベース全体が停止します。 Data Guard を使用しており、Data Guard ファスト・スタート・フェイルオーバーを構成している場合、データベース・フェイルオーバーが自動的に起動され、クライアントはフェイルオーバー後に新規プライマリ・データベースに自動的に再接続されます。リカバリ時間は、自動 Data Guard ファスト・スタート・フェイルオーバー操作が完了するまでの時間と同じです。ファスト・スタート・フェイルオーバーを構成していない場合、この停止状態からのリカバリは手動プロセスになります。手動プロセスを実行するには、ASMインスタンスとデータベース・インスタンスを手動で再起動するか、Data Guard フェイルオーバーを実行します。

RAC も Data Guard も使用していない場合、ASM インスタンスとデータベース・インスタンスを手動で再起動します。リカバリ時間は、ASM インスタンスを起動するのに要する時間と、データベース・インスタンスを起動してクラッシュ・リカバリを実行するのに要する時間に応じて変化します。

4.2.6.2 ASM ディスク障害ディスク障害ディスク障害ディスク障害ASM ディスク・グループが外部冗長性タイプとして構成されている場合、単一のディスク障害は、ストレージ・アレイにより処理されるため ASM インスタンスからは認識されないのが普通です。ASM のすべての操作と、ディスク・グループを使用するデータベースは、通常どおり機能し続けます。ただし、外部冗長性ディスク・グループの障害が ASM インスタンスで認識された場合、ASM インスタンスはディスク・グループを即座にオフラインにするため、そのディスク・グループにアクセスしている Oracle インスタンスはクラッシュします。ディスク障害が一時的な場合は、ASM インスタンスとデータベース・インスタンスを再起動できます。ディスク・グループがオンラインに戻ると、クラッシュ・リカバリが起動します。

ASM ディスク・グループが標準または高冗長性タイプとして構成されている場合、ディスク障害は ASM により透過的に処理され、ディスク・グループにアクセスしているデータベースは影響を受けません。 ASM インスタンスは、自動的に ASM リバランス操作を開始し、1 つ以上の障害ディスクのデータを ASM ディスク・グループの代替ディスクに分散します。リバランス操作の進行中に、まだ再ミラー化されていないデータを含むディスクに別のディスク障害が発生すると、ディスク・グループの可用性に影響を与える可能性があります。リバランス操作が正常に完了すると、後続の障害が発生しても ASM ディスク・グループは影響を受けません。複数のディスク障害も、それらの障害が ASM ディスク・グループのただ 1 つの障害グループに影響を与えるかぎり、同じように処理されます。

複数の障害グループの複数のディスクで、プライマリ・エクステントとそのすべてのミラー・エクステントが失われる障害が発生した場合、ディスク・グループはオフラインになります。


� Enterprise Manager を使用した ASM ディスク障害の修復

� SQL を使用したディスク・グループへの置換ディスクの追加

関連項目関連項目関連項目関連項目 : 詳細は、4-32 ページの 4.2.6.3 項「データ領域ディスク・グループ障害」および 4-34 ページの 4.2.6.4 項「フラッシュ・リカバリ領域ディスク・グループ障害」を参照してください。



4.2.6.2.1 Enterprise Manager を使用したを使用したを使用したを使用した ASM ディスク障害の修復ディスク障害の修復ディスク障害の修復ディスク障害の修復

図 4-10 は、ディスク障害をレポートする Enterprise Manager を示しています。 3 つのアラートが 11:19:29 に記録されています。初のアラートは、「オフライン・ディスク数」です。 2 番目と 3 番目のアラートは、データ領域ディスク DATA.XBBT1D06_DATAおよびリカバリ領域ディスク RECO.XBBT1D06_RECOに関する「ディスク・ステータス」メッセージです。

2 disks are offlineDisk DATA.XBBT1D06_DATA is offline.Disk RECO.XBBT1D06_RECO is offline.

図図図図 4-10 Enterprise Manager によるディスク障害のレポートによるディスク障害のレポートによるディスク障害のレポートによるディスク障害のレポート



図 4-11 は、データ領域ディスク・グループ DATAおよびリカバリ領域ディスク・グループRECOのステータスをレポートする Enterprise Manager を示しています。「メンバー・ディス「メンバー・ディス「メンバー・ディス「メンバー・ディスク」ク」ク」ク」の下の赤い矢印は、各ディスク・グループ内の 1 つのディスクに障害が発生していることを示しています。「保留中の操作」「保留中の操作」「保留中の操作」「保留中の操作」の下の数字は、各ディスク・グループで 1 つの操作が保留中であることを示しています。

図図図図 4-11 Enterprise Manager によるによるによるによる ASM ディスク・グループ・ステータスのレポートディスク・グループ・ステータスのレポートディスク・グループ・ステータスのレポートディスク・グループ・ステータスのレポート

図 4-12 は、DATAディスク・グループに対する保留中の REBAL操作をレポートする Enterprise Manager を示しています。この操作は、「「「「% 完了」完了」完了」完了」に示されているとおり約 3 分の 1 が完了しており、「残り時間」「残り時間」「残り時間」「残り時間」は 16 分と推定されています。

図図図図 4-12 Enterprise Manager による保留中のによる保留中のによる保留中のによる保留中の REBAL 操作のレポート操作のレポート操作のレポート操作のレポート

4.2.6.2.2 SQL を使用したディスク・グループへの置換ディスクの追加を使用したディスク・グループへの置換ディスクの追加を使用したディスク・グループへの置換ディスクの追加を使用したディスク・グループへの置換ディスクの追加 1 つ以上の障害ディスクを置換し、ストレージへのアクセスが回復したら、次の手順を実行します。

1. 次の SQL コマンドを使用して、障害ディスク・グループに 1 つ以上の置換ディスクを追加します。

ALTER DISKGROUP disk_group ADD FAILGROUP failure_group DISK 'disk1','disk2',...;

2. 次のコマンドで操作の進行状況をチェックします。

SELECT * FROM V$ASM_OPERATION;



4.2.6.3 データ領域ディスク・グループ障害データ領域ディスク・グループ障害データ領域ディスク・グループ障害データ領域ディスク・グループ障害データ領域ディスク・グループ障害は、複数の障害が存在する場合にのみ発生するのが普通です。たとえば、データ領域ディスク・グループが外部冗長性として定義されている場合、単一のディスク障害は ASM から隔離されている必要があります。ただし、ストレージ・アレイの複数のディスク障害は、ASM で認識される可能性があり、その場合ディスク・グループはオフラインになります。同様に、標準または高冗長性ディスク・グループの異なる障害グループに複数のディスク障害が発生した場合も、ディスク・グループはオフラインになる可能性があります。

標準または高冗長性ディスク・グループで 1 つ以上のディスク障害が発生したが、ASM ディスク・グループにアクセス可能な場合、データは失われず、即座にアクセスできなくなることもありません。 ASM インスタンスは、自動的に ASM リバランス操作を開始し、1 つ以上の障害ディスクのデータを ASM ディスク・グループの代替ディスクに分散します。リバランス操作が正常に完了すると、2 番目の障害が発生しても ASM ディスク・グループは影響を受けません。リバランス操作を正常に完了するには、ディスク・グループ内の残りのディスクに十分なディスク領域が存在する必要があります。

表 4-8 に、データ領域ディスク・グループ障害が発生した場合に使用可能な 2 つの解決方法をまとめます。

Data Guard を使用しており、ファスト・スタート・フェイルオーバーを構成している場合、データ領域ディスク・グループがオフラインとなってデータベースが停止した時点で自動フェイルオーバーが起動されます。ファスト・スタート・フェイルオーバーを構成していない場合は、手動フェイルオーバーを実行します。

Data Guard フェイルオーバーを実行する場合、目標リカバリ時間目標リカバリ時間目標リカバリ時間目標リカバリ時間は、Data Guard オブザーバ・プロセスとファスト・スタート・フェイルオーバーの稼働状況に応じて数分～数秒となります。ただし、手動フェイルオーバーを実行する場合は、スタンバイ・サイトにすべてのデータが存在しないとデータ損失が発生する可能性があります。

Data Guard フェイルオーバーが完了し、アプリケーションが使用可能になったら、データ領域ディスク・グループ障害を解決する必要があります。引き続き、後続の「ローカル・リカバリの手順」を参照して ASM ディスク・グループ障害を解決します。

ローカル・リカバリのみの RTO は、主に次の操作時間に基づきます。

1. 障害ストレージ・コンポーネントを修復および置換する時間

2. データベースをリストアおよびリカバリする時間

損失の影響はデータ領域ディスク・グループに限定されるため、データ損失は発生しません。すべてのトランザクションはフラッシュ・リカバリ領域に存在する Oracle REDO ログ・メンバーに記録されるため、完全なメディア・リカバリが可能です。

Data Guard を使用していない場合、次のローカル・リカバリの手順を実行します。ローカル・リカバリの実行に要する時間は、データベースをリストアおよびリカバリする時間に応じて変化します。ローカル・リカバリの実行によるデータ損失はありません。

表表表表 4-8 データ領域ディスク・グループ障害のリカバリ・オプションデータ領域ディスク・グループ障害のリカバリ・オプションデータ領域ディスク・グループ障害のリカバリ・オプションデータ領域ディスク・グループ障害のリカバリ・オプション

リカバリ・オプションリカバリ・オプションリカバリ・オプションリカバリ・オプション目標リカバリ時間（目標リカバリ時間（目標リカバリ時間（目標リカバリ時間（RTO））））目標リカバリ時点（目標リカバリ時点（目標リカバリ時点（目標リカバリ時点（RPO））））

Data Guard フェイル

オーバー

5 分以下選択されているデータ保護レベルに応じて変動

ローカル・リカバリデータベースのリストア時間とリカバリ時間

0（ゼロ）



ローカル・リカバリの手順ローカル・リカバリの手順ローカル・リカバリの手順ローカル・リカバリの手順

1 つ以上の障害ディスクを置換し、ストレージへのアクセスが回復したら、次の手順を実行します。

1. 新しいストレージの場所を使用して ASM ディスク・グループを再構築します。

SQL> CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK 'path1','path2',...;

2. NOMOUNTでインスタンスを起動します。

RMAN> STARTUP FORCE NOMOUNT;

3. リカバリ領域に残っているコピーから制御ファイルをリストアします。

RMAN> RESTORE CONTROLFILE FROM 'recovery_area_controlfile';

4. MOUNTでインスタンスを起動します。

RMAN> STARTUP FORCE MOUNT;

5. データベースをリストアします。

RMAN> RESTORE DATABASE


RMAN> RECOVER DATABASE;

7. ブロック変更トラッキングを使用している場合、ブロック変更トラッキング・ファイルを一度無効化してから再有効化します。

SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

8. データベースをオープンします。

SQL> ALTER DATABASE OPEN;

9. 障害 ASM ディスク・グループにログ・ファイル・メンバーを再作成します。

SQL> ALTER DATABASE DROP LOGFILE MEMBER 'filename';SQL> ALTER DATABASE ADD LOGFILE MEMBER 'disk_group' TO GROUP group_no;

10. 増分レベル 0 の新規バックアップを実行します。

RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;

注意注意注意注意 : 新規プライマリ・データベースに対して Oracle Data Guard フェイルオーバーを実行した場合、次の手順を使用してそのデータベースを Data Guard 環境に再統合できます。 4-53 ページの 4.3.2 項「フェイルオーバー後のスタンバイ・データベースのリストア」も参照してください。



4.2.6.4 フラッシュ・リカバリ領域ディスク・グループ障害フラッシュ・リカバリ領域ディスク・グループ障害フラッシュ・リカバリ領域ディスク・グループ障害フラッシュ・リカバリ領域ディスク・グループ障害通常、制御ファイル・メンバーはフラッシュ・リカバリ領域に存在し、Oracle ではすべての制御ファイル・メンバーにアクセスできる必要があるため、フラッシュ・リカバリ領域ディスク・グループに障害が発生すると、データベースはクラッシュします。フラッシュ・リカバリ領域には、フラッシュバック・ログ、REDO ログ・メンバーおよびすべてのバックアップも含まれます。

フラッシュ・リカバリ領域ディスク・グループ障害は、複数の障害が存在する場合にのみ発生するのが普通です。たとえば、フラッシュ・リカバリ領域ディスク・グループが外部冗長性として定義されている場合、単一のディスク障害は ASM から隔離されている必要があります。ただし、ストレージ・アレイの複数のディスク障害は、ASM で認識される可能性があり、その場合ディスク・グループはオフラインになります。同様に、標準または高冗長性ディスク・グループの異なる障害グループに複数のディスク障害が発生した場合も、ディスク・グループはオフラインになる可能性があります。

表 4-9 に、フラッシュ・リカバリ領域ディスク・グループ障害が発生した場合に使用可能な 2 つの解決方法をまとめます。

損失の影響はフラッシュ・リカバリ領域ディスク・グループに限定されるため、データ損失は発生しません。データファイルとオンライン REDO ログ・ファイルは引き続き存在し、データ領域で使用できるため、データベースのメディア・リカバリは必要ありません。高速ローカル再起動を実行するには、障害フラッシュ・リカバリ領域に存在する制御ファイル・メンバーの削除後にプライマリ・データベースを起動し、ローカル・アーカイブの新規フラッシュ・リカバリ領域を参照するよう設定します（手順の詳細は、この項の「ローカル再起動の手順」を参照してください）。ただし、この方法は、新規フラッシュ・リカバリ領域を作成して障害ストレージ・コンポーネントを置換するまでの一時的な修復手段です。この項の「ローカル・リカバリの手順」を使用することをお薦めします。

Data Guard フェイルオーバーを実行する場合、RTO は、Data Guard オブザーバ・プロセスとファスト・スタート・フェイルオーバーの稼働状況に応じて数分～数秒となります。 Data Guard フェイルオーバーが完了し、アプリケーションが使用可能になったら、フラッシュ・リカバリ領域ディスク・グループ障害を解決する必要があります。引き続き、後続の「ローカル・リカバリの手順」を参照して ASM ディスク・グループ障害を解決します。

保護レベルが大パフォーマンス・モードの場合、またはスタンバイ・データベースがプライマリ・データベースと同期していない場合、制御ファイル・メンバーを削除して SPFILE で一時フラッシュ・リカバリ領域（ファイル・システム）を参照するよう設定し、プライマリ・データベースを一時的に起動します。 Data Guard スイッチオーバーを実行してデータ損失を防ぎます。 Data Guard スイッチオーバーが完了し、アプリケーションが使用可能になったら、フラッシュ・リカバリ領域ディスク・グループ障害を解決する必要があります。関連するデータベースを停止し、後続の「ローカル・リカバリの手順」を参照して ASM ディスク・グループ障害を解決します。

ローカル・リカバリのみの RTO は、主に障害ストレージ・コンポーネントを修復および置換する時間と、制御ファイルのコピーをリストアする時間に基づきます。損失の影響はフラッシュ・リカバリ領域ディスク・グループに限定されるため、データ損失は発生しません。データファイルとオンライン REDO ログ・ファイルは引き続き存在し、データ領域で使用できるため、データベースのメディア・リカバリは必要ありません。前述のとおり、制御ファイル・メンバーを削除して新規フラッシュ・リカバリ領域を参照することでプライマリ・データベースを起動できます。ただし、この方法は、フラッシュ・リカバリ領域が適切に構成されていないかぎり、可用性とパフォーマンスを損う可能性のある一時的な修復手段です。そのため、後続の

「ローカル・リカバリの手順」を使用することをお薦めします。

表表表表 4-9 フラッシュ・リカバリ領域ディスク・グループ障害のリカバリ・オプションフラッシュ・リカバリ領域ディスク・グループ障害のリカバリ・オプションフラッシュ・リカバリ領域ディスク・グループ障害のリカバリ・オプションフラッシュ・リカバリ領域ディスク・グループ障害のリカバリ・オプション

リカバリ・オプションリカバリ・オプションリカバリ・オプションリカバリ・オプション目標リカバリ時間（目標リカバリ時間（目標リカバリ時間（目標リカバリ時間（RTO））））目標リカバリ時点（目標リカバリ時点（目標リカバリ時点（目標リカバリ時点（RPO））））

ローカル・リカバリ 5 分以下 0（ゼロ）

Data Guard フェイル

オーバーまたはスイッチオーバー

5 分以下 0（ゼロ）



ローカル再起動の手順ローカル再起動の手順ローカル再起動の手順ローカル再起動の手順

高速ローカル再起動を行うには、プライマリ・データベースで次の手順を実行します。

1. データ領域のメンバーのみを参照するよう CONTROL_FILES初期化パラメータを変更します。たとえば、次のようになります。

ALTER SYSTEM SET CONTROL_FILES='+DATA/sales/control1.dbf' SCOPE=spfile;

2. ローカル・アーカイブの宛先またはフラッシュ・リカバリ領域（あるいはその両方）を、冗長性を備えたスケーラブルなローカルの宛先に変更します。たとえば、次のようになります。

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+DATA' SCOPE=spfile;

3. 新規設定で起動します。

STARTUP MOUNT:

フラッシュバック・ログの破損や損失が発生した場合、状況によってはフラッシュバック・データベースを一度無効化してから再有効化する必要があります。

ALTER DATABASE FLASHBACK OFF;ALTER DATABASE FLASHBACK ON;ALTER DATABASE OPEN;

ローカル・リカバリの手順ローカル・リカバリの手順ローカル・リカバリの手順ローカル・リカバリの手順

1. フラッシュ・リカバリ領域として使用する新規ストレージに置換するか、ストレージへのアクセスを確立します。

2. 新しいストレージの場所を使用して ASM ディスク・グループを再構築します。

SQL> CREATE DISKGROUP RECO NORMAL REDUNDANCY DISK 'path1','path2',...;

3. NOMOUNTでインスタンスを起動します。

RMAN> STARTUP FORCE NOMOUNT;

4. データ領域に残っているコピーから制御ファイルをリストアします。

RMAN> RESTORE CONTROLFILE FROM 'data_area_controlfile';

5. MOUNTでインスタンスを起動します。

RMAN> STARTUP FORCE MOUNT;

6. フラッシュバック・データベースを使用している場合、その機能を無効化します。

SQL> ALTER DATABASE FLASHBACK OFF;

7. データベースをオープンし、インスタンス・リカバリを完了します。

SQL> ALTER DATABASE OPEN;

8. フラッシュバック・データベースが必要な場合にのみ、次の文を発行します。

SQL> SHUTDOWN IMMEDIATE;SQL> STARTUP MOUNT;SQL> ALTER DATABASE FLASHBACK ON;SQL> ALTER DATABASE OPEN;

注意注意注意注意 : 新規プライマリ・データベースに対して Oracle Data Guard フェイルオーバーを実行した場合、この手順を使用して以前のプライマリ・データベースをスタンバイ・データベースとして再導入することはできません。その理由は、データベースの再導入作業に必要なフラッシュバック・データベースのログ・ファイルが失われているためです。スタンバイ・データベースについては、完全な再インスタンス化を実行する必要があります。



9. 障害 ASM ディスク・グループにログ・ファイル・メンバーを再作成します。

SQL> ALTER DATABASE DROP LOGFILE MEMBER 'filename';SQL> ALTER DATABASE ADD LOGFILE MEMBER 'disk_group' TO GROUP group_no;

10. 制御ファイルおよびフラッシュ・リカバリ領域を同期します。

RMAN> CATALOG RECOVERY AREA;RMAN> CROSSCHECK ARCHIVELOG ALL;RMAN> CROSSCHECK BACKUPSET;RMAN> CROSSCHECK DATAFILECOPY ALL;RMAN> LIST EXPIRED type;RMAN> DELETE EXPIRED type;

11. なんらかの形でデータが失われたと仮定し、新規バックアップを実行します。

RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;

4.2.7 データ破損（データ障害）からのリカバリデータ破損（データ障害）からのリカバリデータ破損（データ障害）からのリカバリデータ破損（データ障害）からのリカバリデータ破損からのリカバリは、計画外の停止に関連する状況です。データ破損は、たとえ問題がデータベース内で明らかとなっても、データベース外で発生したなんらかのアクティビティまたは障害を原因とするのが普通です（常にではありません）。

データファイルのデータ破損は、次の 2 つのカテゴリに分類されます。

� データファイル・ブロック破損

破損したデータファイル・ブロックにはアクセスできますが、ブロックの内容は無効であるか、一貫性が失われています。データファイル破損の一般的な原因は、I/O スタックのハードウェアまたはソフトウェア・コンポーネントの障害です。I/O スタックには、ファイル・システム、ボリューム・マネージャ、デバイス・ドライバ、ホスト・バス・アダプタ、ストレージ・コントローラおよびディスク・ドライブが含まれます（これらに限定されるわけではありません）。

通常、破損ブロックが検出された時点でデータベースは依然として使用できますが、一部の破損ブロックは広範囲に及ぶ問題（ファイル・ヘッダーまたはデータ・ディクショナリ・オブジェクトの破損や、アプリケーションを使用不可能にする重要な表の破損）を引き起こす可能性があります。

データ障害は、アプリケーションの可用性に影響を与えるため、ユーザー、管理者、RMAN バックアップまたはアプリケーションによって認識された時点で明らかとなります。データ障害の例は、次のとおりです。

– 物理ディスクに問題箇所が存在するためにアプリケーションで読み取ることができないユーザー表の単一の破損データ・ブロック。

– ブロックの一貫性が失われているために Oracle によって検出された単一の破損データ・ブロック。このブロックは破損ブロックとしてマークされ、このブロックにアクセスするアプリケーションは ORA-1578エラーを受信します。

– ディスク・コントローラ障害による SYSTEM表領域のデータファイルの無効ブロックを原因として自動停止するデータベース。

� メディア障害

このカテゴリのデータ破損の原因は、ハードウェアの物理的問題またはユーザー・エラーです。システムでは、データベースの運用に必要なファイルを正常に読み取ることができないか、ファイルに正常に書き込むことができません。

すべての環境において、データ破損による停止は次のいずれかの方法を使用して解決できます。

� RMAN ブロック・メディア・リストアおよびリカバリ

� スタンバイ・データベースへの Data Guard スイッチオーバーまたはフェイルオーバー

� RMAN データファイル・メディア・リストアおよびリカバリ

� オブジェクトの手動再作成



RMAN ブロック・メディア・リストアおよびリカバリでは、ターゲット・ブロックがアプリケーション機能にとって重要でないかぎり、高度のアプリケーション可用性を得ることができます。スタンバイ・データベースへの Data Guard スイッチオーバーまたはフェイルオーバーでは、予測される RTO をも短縮できます。

データベース・オブジェクトの可用性や一貫性を損うその他の停止は、表の削除または表データの不適切な更新などの人為的エラーにより引き起こされます。人為的エラーからのリカバリ方法の詳細は、4-39 ページの 4.2.8 項「人為的エラーからのリカバリ」を参照してください。

データ破損がデータファイル以外のオブジェクトに影響を及ぼす場合、修復方法は多少異なることがあります。表 4-10 に、データベース以外の主要オブジェクトの破損と推奨される修復方法をマトリックス形式で示します。


� Data Guard を使用したデータ破損およびデータ障害からのリカバリ

� RMAN ブロック・メディア・リカバリの使用

� RMAN データファイル・メディア・リカバリの使用

� 手動によるオブジェクトの再作成

表表表表 4-10 データベース以外のオブジェクトの破損と推奨される修復方法データベース以外のオブジェクトの破損と推奨される修復方法データベース以外のオブジェクトの破損と推奨される修復方法データベース以外のオブジェクトの破損と推奨される修復方法

関連するオブジェクト関連するオブジェクト関連するオブジェクト関連するオブジェクトまたはコンポーネントまたはコンポーネントまたはコンポーネントまたはコンポーネント影響影響影響影響修復方法修復方法修復方法修復方法

任意の制御ファイルデータベース停止 Data Guard ファスト・スタート・フェイルオー

バーにより、スタンバイ・データベースに自動的にフェイルオーバーされます。

REDO ログ・メンバーなし 1. 障害を調査してシステムをチェックします。

2. REDO ログ・メンバーを削除して再作成しま

す。

アーカイブされており、クラッシュ・リカバリに必要のないアクティブなログ・グループ

データベース停止関連する REDO ログ・グループの削除後にデータ

ベースを再起動します。

アーカイブされておらず、クラッシュ・リカバリに必要のないアクティブな REDO ログ・

グループ

データベース停止 1. 関連するログ・グループの削除後にデータベースを再起動します。

2. 新規バックアップを作成します。

3. スタンバイ・データベースをリフレッシュするため、増分バックアップを適用するか、プライマリ・データベース（またはプライマリ・データベースのバックアップ）からスタンバイ・データベースを再作成します。

クラッシュ・リカバリに必要とされるアクティブな（または現行の）REDO ログ・グ

ループ

データベース停止次のいずれかの解決方法を使用します。

� Data Guard フェイルオーバー

� フラッシュバック・データベース : データ

ベースを一貫性のある時点にフラッシュバックし、OPEN RESETLOGSを発行します。

アーカイブ REDO ロ

グ・ファイル

なし 1. データベース・バックアップを作成します。

2. スタンバイ・データベースをリフレッシュするため、増分バックアップを適用するか、プライマリ・データベース（またはプライマリ・データベースのバックアップ）からスタンバイ・データベースを再作成します。

SPFILE なしバックアップから SPFILE をリストアして修正し

ます。



4.2.7.1 Data Guard を使用したデータ破損およびデータ障害からのリカバリを使用したデータ破損およびデータ障害からのリカバリを使用したデータ破損およびデータ障害からのリカバリを使用したデータ破損およびデータ障害からのリカバリフェイルオーバーは、スタンバイ・データベースを新規本番データベースに移行する操作です。データベース・スイッチオーバーは、スタンバイ・データベースと本番データベースのロールを切り替える計画された移行操作です。どちらの操作も、データを失うことなく 5 分未満で完了します。

データ破損やデータ障害に Data Guard スイッチオーバーまたはフェイルオーバーを使用するのは、次の場合です。

� データベースが停止している状況で（またはデータベースは稼働しているがデータ破損またはデータ障害のためにアプリケーションを使用できない状況で）、ローカルでのリストアおよびリカバリ時間が長くなるか、その時間が予測できない場合。

� ローカルでのリカバリ時間が、ビジネス上の SLA または RTO より長くなる場合。

4.2.7.2 RMAN ブロック・メディア・リカバリの使用ブロック・メディア・リカバリの使用ブロック・メディア・リカバリの使用ブロック・メディア・リカバリの使用ブロック・メディア・リカバリ（BMR）では、RMAN BLOCKRECOVERコマンドを使用して、データファイルでメディア破損としてマークされた 1 つのブロックまたはデータ・ブロックのセットをリカバリします。メディア破損としてマークされた、メディア・リカバリを必要とするデータ・ブロックの数が少ない場合、データファイル全体ではなく、破損したブロックを選択的にリストアおよびリカバリできます。この場合、リカバリを必要とするブロックのみがリストアされ、必要な破損ブロックのみがリカバリされるため、RTO が短縮されます。ブロック・メディア・リカバリにより、REDO 適用時間が小化され、リカバリ時の I/O オーバーヘッドが回避されます。また、破損ブロックのリカバリ中も、関連するデータファイルはオンラインのまま使用できます。ただし、破損ブロックは、完全にリカバリされるまで使用できない状態が続きます。

ブロック・メディア・リカバリを使用するのは、次の場合です。

� メディア・リカバリを必要とするブロックの数が少なく、リカバリの必要なブロックが判明している場合。データファイルの重要な部分が破損しているか、破損量が不明の場合は、別のリカバリ方法を使用する必要があります。

� ブロックが破損としてマークされており（RMAN BACKUP VALIDATEコマンドで検証）、特に完全リカバリが必要とされる場合。

� 破損ブロックを含むデータファイルのバックアップがローカルで使用可能であるか、そのバックアップをリモートの場所（フィジカル・スタンバイ・データベースなど）から取得できる場合。

ブロック・メディア・リカバリは、次の障害からリカバリする場合には使用できません。

� データ・ブロックを損わない論理破損の原因となるユーザー・エラーまたはソフトウェアの不具合。このタイプのリカバリの詳細は、4-39 ページの 4.2.8 項「人為的エラーからのリカバリ」を参照してください。

� 破損した REDO データを原因とする変更。ブロック・メディア・リカバリでは、使用可能なすべての REDO データをリカバリ対象のブロックに適用する必要があります。

たとえば、RMAN ブロック・メディア・リカバリを使用して特定の破損ブロックをリカバリするには、次のようにします。

RMAN> BLOCKRECOVER DATAFILE 7 BLOCK 3;

破損が検出された場合、Grid Control を使用すると簡単にブロックをリカバリできます。

関連項目関連項目関連項目関連項目 : 4-22 ページの「スタンバイ・データベースでのデータベース・スイッチオーバー」および 4-16 ページの「スタンバイ・データベースでのデータベース・フェイルオーバー」

関連資料関連資料関連資料関連資料 :『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』およびホワイト・ペーパー『Using Recovery Manager with Oracle Data Guard in Oracle Database 10g』

（http://www.oracle.com/technology/deploy/availability/pdf/RMAN_DataGuard_10g_wp.pdf）



4.2.7.3 RMAN データファイル・メディア・リカバリの使用データファイル・メディア・リカバリの使用データファイル・メディア・リカバリの使用データファイル・メディア・リカバリの使用データファイル・メディア・リカバリでは、RMAN RECOVERコマンドを使用して、データベースのデータファイル全体またはデータファイルのセットをリカバリします。メディア破損としてマークされた、メディア・リカバリを必要とするデータ・ブロックの数が多いか不明の場合、またはファイル全体が失われた場合、関連するデータファイルをリストアおよびリカバリする必要があります。

RMAN データファイル・メディア・リカバリを使用するのは、次の場合です。

� リカバリを必要とするブロックの数が多いか不明の場合

� ブロック・メディア・リカバリを使用できない場合（不完全リカバリが必要な場合や、リカバリを必要とするデータファイルに使用できるのが増分バックアップのみの場合など）

4.2.7.4 手動によるオブジェクトの再作成手動によるオブジェクトの再作成手動によるオブジェクトの再作成手動によるオブジェクトの再作成一部のデータベース・オブジェクト（サイズの小さい参照表または索引）は、メディア・リカバリを実行するかわりに手動で再作成することで迅速にリカバリできます。

手動でオブジェクトを再作成するのは、次の場合です。

� メディア破損のためにサイズの小さい索引を再作成する必要がある場合。オンラインで索引を作成すると、ベース・オブジェクトを同時に使用できます。

� 参照表を再作成する必要がある場合、または表を再作成するスクリプトをすぐに使用できる場合。表を削除して再作成することがも迅速なオプションである可能性があります。

4.2.8 人為的エラーからのリカバリ人為的エラーからのリカバリ人為的エラーからのリカバリ人為的エラーからのリカバリOracle フラッシュバック・テクノロジは、データ・リカバリの概念を大きく変えるものです。これまで、データベースを破損するのは数秒で、それをリカバリするのに数時間から数日を要していました。フラッシュバック・テクノロジを使用すると、エラーを修正する時間が、エラーを起こしたときの時間と同じ程度にまで短縮されます。人為的エラーが発生し、データベース、表、トランザクションまたは行レベルの変更を過去の任意の時点に戻す必要がある場合でも、データベースやオブジェクトをリストアすることなくそれらのエラーを簡単に修復できます。フラッシュバック・テクノロジでは、間違った行削除などの局所的な障害を詳細に分析して修復できます。また、フラッシュバック・テクノロジでは、不適切なアプリケーション・バッチ・ジョブを誤って実行した場合など、広範囲に影響が及ぶ障害を修復することも可能です。さらに、フラッシュバック・テクノロジは、データベース・リストアと比較して非常に高速です。

フラッシュバック・テクノロジは、次のような人為的エラーを修復する場合にのみ使用できます。

� 間違いによる（または悪意のある）更新、削除または挿入トランザクション

� 間違いによる（または悪意のある）DROP TABLE文

� 間違いによる（または悪意のある）バッチ・ジョブまたは広範囲に影響が及ぶアプリケーション・エラー

フラッシュバック・テクノロジは、ブロック破損、ディスク障害、ファイル削除などのメディア破損やデータ破損には使用できません。これらの障害を修復する方法の詳細は、4-36 ページの 4.2.7 項「データ破損（データ障害）からのリカバリ」および 4-16 ページの 4.2.2 項「スタンバイ・データベースでのデータベース・フェイルオーバー」を参照してください。

関連資料関連資料関連資料関連資料 :『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』の高度なユーザー管理のリカバリの例に関する項、およびホワイト・ペーパー『Using Recovery Manager with Oracle Data Guard in Oracle Database 10g』

（http://www.oracle.com/technology/deploy/availability/pdf/RMAN_DataGuard_10g_wp.pdf）



表 4-23 に、各障害タイプのフラッシュバック・ソリューションをまとめます。

表 4-12 に、各フラッシュバック機能をまとめます。

フラッシュバック・データベースでは、Oracle データベースのフラッシュバック・ログを使用し、他のすべてのフラッシュバック・テクノロジ機能では、Oracle データベース独自の UNDO機能とマルチバージョン読取り一貫性機能を使用します。障害時にこれらのソリューションで各リソースを使用できるようフラッシュバック・テクノロジを構成する方法の詳細は、2-8 ページの 2.2 項「Oracle Database 10g の構成」に記載されているデータベース構成上のベスト・プラクティスを参照してください。

表表表表 4-11 様々な障害のフラッシュバック・ソリューション様々な障害のフラッシュバック・ソリューション様々な障害のフラッシュバック・ソリューション様々な障害のフラッシュバック・ソリューション

障害の影響障害の影響障害の影響障害の影響人為的エラーの例人為的エラーの例人為的エラーの例人為的エラーの例フラッシュバック・ソリューションフラッシュバック・ソリューションフラッシュバック・ソリューションフラッシュバック・ソリューション

行またはトランザクション

関連項目関連項目関連項目関連項目 : 4-42 ページの「行およびト

ランザクションの非一貫性の解決」

意図しない行の削除

間違ったトランザクション

フラッシュバック問合せ

フラッシュバック・バージョン問合せ

フラッシュバック・トランザクション問合せ

表

関連項目関連項目関連項目関連項目 : 4-41 ページの「表の非一貫

性の解決」

表の削除

1 つの表または表のセットに影響を与

える間違ったトランザクション

フラッシュバック・ドロップ

フラッシュバック表

表領域またはデータベース

関連項目関連項目関連項目関連項目 : 4-44 ページの「データベー

ス全体の非一貫性の解決」

多くの表または不明な表のセットに影響を与える間違ったバッチ・ジョブ

データベース全体を対象とする悪意のある一連のトランザクション

フラッシュバック・データベース

表表表表 4-12 フラッシュバック機能のまとめフラッシュバック機能のまとめフラッシュバック機能のまとめフラッシュバック機能のまとめ

フラッシュバック機能フラッシュバック機能フラッシュバック機能フラッシュバック機能説明説明説明説明

フラッシュバック問合せ

フラッシュバック問合せでは、過去のある時点でのデータを参照できます。この機能は、間

違って削除または変更された損失データを参照および再構築する際に使用します。開発者は、

この機能を使用して、アプリケーションにセルフサービスのエラー修正機能を組み込み、エンド・ユーザーにエラーを元に戻して修正する機能を提供できます。

注意注意注意注意 : 変更は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベー

スに伝播されます。

フラッシュバック・バージョン問合せ

フラッシュバック・バージョン問合せでは、データベースに格納された UNDO データを使用

して、1 つ以上の行に対する変更と、その変更のすべてのメタデータを参照できます。



フラッシュバック・トランザクション問合せ

フラッシュバック・トランザクション問合せでは、トランザクション・レベルでデータベースに対する変更を調査できます。その結果、問題の診断、分析の実行、およびトランザクション

の監査を行うことができます。



フラッシュバック・ドロップ

フラッシュバック・ドロップでは、間違って削除した表をリストアできます。

注意注意注意注意 : 変更は、フィジカル・スタンバイ・データベースに伝播されます。

フラッシュバック表フラッシュバック表では、バックアップをリストアせずに過去のある時点まで表を迅速にリカバリできます。



フラッシュバック・データベース

フラッシュバック・データベースでは、過去のある時点以降に発生したすべての変更を取り消すことで、データベースをその時点まで迅速に戻すことができます。バックアップをリストア

する必要がないため、この操作は高速です。



一般的に、フラッシュバック・テクノロジを使用した場合のリカバリ時間は、人為的エラーの発生に要した時間と人為的エラーの検出に要した時間の合計に等しくなります。

フラッシュバック・テクノロジでは、人為的エラーが発生した時点までリカバリすることが可能です。


� 表の非一貫性の解決

� 行およびトランザクションの非一貫性の解決

� データベース全体の非一貫性の解決

4.2.8.1 表の非一貫性の解決表の非一貫性の解決表の非一貫性の解決表の非一貫性の解決 Oracle では、偶発的な DROP TABLE文からリカバリするための FLASHBACK DROP文と、データベースの表を過去の時点にリストアするための FLASHBACK TABLE文を使用できます。

フラッシュバック表により、DBA は、1 つの表または表のセットを特定の時点に迅速かつ簡単にリカバリできます。多くの場合、フラッシュバック表を使用することで、ポイント・イン・タイム・リカバリ操作の複雑さが軽減されます。たとえば、次のようになります。

FLASHBACK TABLE orders, order_items TO TIMESTAMP TO_DATE('28-Jun-06 14.00.00','dd-Mon-yy hh24:mi:ss');

この文により、タイムスタンプで指定した過去の時点から現在までの間に発生した ORDERS表と ORDER_ITEMS表に対するすべての更新が元に戻されます。フラッシュバック表では、この操作がオンラインでインプレース実行されると同時に、表間の参照整合性制約も維持されます。

誤ってデータベース・オブジェクトを削除することは、よくあります。ユーザーはすぐこの間違いに気付きますが、その時点ではすでに遅く、削除した表とその索引、制約、トリガーを簡単に元に戻す方法はなくなっています。以前は、一度削除したオブジェクトは永久的に失われていました。非常に重要な表やその他のオブジェクト（索引、パーティションまたはクラスタ）が失われた場合、DBA はポイント・イン・タイム・リカバリを実行する必要がありましたが、これは時間のかかる操作であり、新のトランザクションは失われる可能性がありました。

フラッシュバック・ドロップは、Oracle Database 10g でオブジェクトを削除する際のセーフティ・ネットとなります。ユーザーが表を削除すると、その表はごみ箱に配置されます。ごみ箱のオブジェクトは、ユーザーがそれらを永久的に削除することを決定するまで、またはその表を含む表領域の領域制限に到達するまでそのまま格納されます。ごみ箱は、すべての削除済オブジェクトが存在する仮想的なコンテナです。ユーザーは、ごみ箱を参照して、削除済の表とその依存オブジェクトを元に戻すことができます。たとえば、employees表とそのすべての依存オブジェクトを元に戻すには、次の文を使用します。

FLASHBACK TABLE employees TO BEFORE DROP;

関連資料関連資料関連資料関連資料 : フラッシュバック・テクノロジと自動 UNDO 管理の詳細は、『Oracle Database 管理者ガイド』、『Oracle Database バックアップおよびリカバリ基礎』および『Oracle Database 概要』を参照してください。



4.2.8.2 行およびトランザクションの非一貫性の解決行およびトランザクションの非一貫性の解決行およびトランザクションの非一貫性の解決行およびトランザクションの非一貫性の解決行およびトランザクションの非一貫性を解決するには、フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション問合せ、および問題を修正するための UNDO 文で構成された補正 SQL 文を組み合せて使用する必要があります。この項では、人事管理の例を使用して、間違いによる（または悪意のある）ユーザー・エラーによって引き起こされた行およびトランザクションの非一貫性を解決するための一般的な方法について説明します。

Oracle9i Database で導入された機能であるフラッシュバック問合せを使用すると、管理者またはユーザーは、過去のある時点でのデータを問い合せることができます。この便利な機能は、間違って削除または変更されたデータを参照および再構築する際に使用します。たとえば、次のようになります。

SELECT * FROM EMPLOYEES AS OF TIMESTAMP TO_DATE('28-Jun-06 14:00','DD-Mon-YY HH24:MI')WHERE ...

この部分的な文により、2006 年 6 月 28 日午後 2 時の EMPLOYEES表から行が選択されて表示されます。開発者は、この機能を使用して、アプリケーションにセルフサービスのエラー修正機能を組み込むことで、管理者に作業を任せるかわりにエンド・ユーザーにエラーをその場で元に戻して修正する機能を提供できます。過去に設定された時間に合せてデータを再構築するのに必要な情報は、データベースで自動的に維持されるため、フラッシュバック問合せの管理は非常に簡単です。

フラッシュバック・バージョン問合せでは、データベースの変更を行レベルで参照できます。これは、SQL の拡張機能であり、指定した時間間隔で異なるバージョンの行をすべて取得できます。たとえば、次のようになります。

SELECT * FROM EMPLOYEES VERSIONS BETWEEN TIMESTAMP TO_DATE('28-Jun-06 14:00','dd-Mon-YY hh24:mi') AND TO_DATE('28-Jun-06 15:00','dd-Mon-YY hh24:mi')WHERE ...

この文により、今日の午後 2 時から 3 時の間における各バージョンの行（異なるトランザクションによって変更された各エントリ）が表示されます。DBA は、この機能を使用して、データがいつどのように変更されたかを特定し、関連するユーザー、アプリケーションまたはトランザクションを追跡することが可能です。これにより、DBA は、データベースの論理破損の原因を追跡して修正できます。また、アプリケーション開発者は、自分のコードをデバッグできます。

フラッシュバック・トランザクション問合せでは、データベースの変更をトランザクション・レベルで参照できます。これは、SQL の拡張機能であり、トランザクションによるすべての変更を参照できます。たとえば、次のようになります。

SELECT UNDO_SQLFROM FLASHBACK_TRANSACTION_QUERY WHERE XID = '000200030000002D';

この文により、このトランザクションに基づくすべての変更が表示されます。また、補正 SQL文が戻されるため、その文を使用してこのトランザクションで変更されたすべての行を元に戻すことができます。このような精度の高いツールを使用することで、DBA とアプリケーション開発者は、データベースやアプリケーションの論理問題を正確に診断および修正できます。

ここでは、SCOTTスキーマに関連する人事管理（HR）の例について検討します。 HR マネージャから、Ward の給与に食い違いがあるようだという報告が DBA に入ります。 Ward の給与は、午前 9 時前のどこかの時点で 1875 ドルに上昇しました。HR マネージャは、この変更がどうして起こったのかわからないため、いつこの従業員の給与が上がったのかを把握するつもりです。また、HR マネージャは、スタッフに指示して Ward の給与を以前のレベルの 1250 ドルに再設定しました。この作業は、午前 9 時 15 分ごろには完了しました。



この問題に対処するには、次の手順を実行します。

1. 問題を評価します。

変更の発生した時刻に関する情報は、HR マネージャから提供されています。フラッシュバック問合せを使用して、午前 9 時の時点での情報を問い合せます。

SELECT EMPNO, ENAME, SAL FROM EMP AS OF TIMESTAMP TO_DATE('28-JUN-06 09:00','dd-Mon-yy hh24:mi') WHERE ENAME = 'WARD';

EMPNO ENAME SAL ---------- ---------- ---------- 7521 WARD 1875

Ward の給与が午前 9 時の時点で 1875 ドルであったという事実から、正しい従業員を選択したことを確認できます。後続の調査では、Ward の名前ではなく従業員番号を使用できます。

2. トランザクション情報を取得するため、データの過去の行またはバージョンを問い合せます。

行バージョン情報を特定の日付または SCN の範囲に制限することも可能ですが、フラッシュバック・バージョン問合せを使用すると、従業員 WARD について使用可能なすべての行情報を問い合せることができます。

SELECT EMPNO, ENAME, SAL, VERSIONS_STARTTIME, VERSIONS_ENDTIME FROM EMP VERSIONS BETWEEN TIMESTAMP MINVALUE AND MAXVALUE WHERE EMPNO = 7521 ORDER BY NVL(VERSIONS_STARTSCN,1);

EMPNO ENAME SAL VERSIONS_STARTTIME VERSIONS_ENDTIME----- ---------- ------- ---------------------- ---------------------- 7521 WARD 1250 28-JUN-06 08.48.43 AM 28-JUN-06 08.54.49 AM 7521 WARD 1875 28-JUN-06 08.54.49 AM 28-JUN-06 09.10.09 AM 7521 WARD 1250 28-JUN-06 09.10.09 AM

WARD の給与は、今朝の 08:54:49 に 1250 ドルから 1875 ドルに上がり、その後 09:10:09 ごろに 1250 ドルに戻されたことがわかります。

同様のフラッシュバック・バージョン問合せで問合せを変更し、WARD に影響を与えた各変更のトランザクション情報を確認することもできます。この場合、VERSIONS_XID擬似列を使用します。

SELECT EMPNO, ENAME, SAL, VERSIONS_XID FROM EMP VERSIONS BETWEEN TIMESTAMP MINVALUE AND MAXVALUE WHERE EMPNO = 7521 ORDER BY NVL(VERSIONS_STARTSCN,1);

EMPNO ENAME SAL VERSIONS_XID ---------- ---------- ---------- ---------------- 7521 WARD 1250 0006000800000086 7521 WARD 1875 0009000500000089 7521 WARD 1250 000800050000008B

WARD の給与を 1875 ドルに上げた不適切なトランザクションの ID は、0009000500000089です。



3. 不適切なトランザクションとその影響範囲を問い合せます。

フラッシュバック・トランザクション問合せにトランザクション情報（VERSIONS_XID擬似列）を指定してデータベースに問い合せ、トランザクションの範囲を確認します。

SELECT UNDO_SQL FROM FLASHBACK_TRANSACTION_QUERY WHERE XID = HEXTORAW('0009000500000089');

UNDO_SQL ---------------------------------------------------------------------------- update "SCOTT"."EMP" set "SAL" = '950' where ROWID = 'AAACV4AAFAAAAKtAAL'; update "SCOTT"."EMP" set "SAL" = '1500' where ROWID = 'AAACV4AAFAAAAKtAAJ'; update "SCOTT"."EMP" set "SAL" = '2850' where ROWID = 'AAACV4AAFAAAAKtAAF'; update "SCOTT"."EMP" set "SAL" = '1250' where ROWID = 'AAACV4AAFAAAAKtAAE'; update "SCOTT"."EMP" set "SAL" = '1600' where ROWID = 'AAACV4AAFAAAAKtAAB'; 6 rows selected.

このトランザクションでは、WARD の給与以外にも変更が発生していたことがわかります。 WARD と同様に変更されていた他の 4 人の従業員情報を、確認のため HR マネージャに戻します。

4. 修正用の文を実行するかどうかを確認します。

UNDO_SQL列に示された修正用の変更文が HR マネージャによって正しいと判断されたら、DBA はそれらの文を個別に実行できます。

5. FLASHBACK_TRANSACTION_QUERYビューを問い合せて追加のトランザクション情報を取得します。たとえば、間違った更新を実行したユーザーを確認するには、次の問合せを発行します。

SELECT LOGON_USER FROM FLASHBACK_TRANSACTION_QUERYWHERE XID = HEXTORAW('0009000500000089');

LOGON_USER----------------------------MSMITH

この例の場合、ユーザー MSMITH が間違ったトランザクションを実行していたことがわかります。

4.2.8.3 データベース全体の非一貫性の解決データベース全体の非一貫性の解決データベース全体の非一貫性の解決データベース全体の非一貫性の解決Oracle データベースを以前の時点に戻すための従来の方法は、ポイント・イン・タイム・リカバリです。ただし、ポイント・イン・タイム・リカバリには、数時間または数日かかる可能性があります。この理由は、データベース全体をバックアップからリストアし、エラーがデータベースで発生する直前の時点までリカバリする必要があるためです。データベース・サイズが一定の割合で増加している場合、データベース全体をリストアするだけで数時間または数日かかります。

フラッシュバック・データベースは、ポイント・イン・タイム・リカバリを実行するための新しい手段です。この機能を使用すると、論理的データ破損またはユーザー・エラーを原因とする問題を修正するために、Oracle データベースを過去の時点に迅速に戻すことができます。フラッシュバック・ログは、以前のバージョンの変更済ブロックを取得するのに使用されます。フラッシュバック・ログは、継続的なバックアップまたは記憶域のスナップショットと考えることができます。リカバリを実行する必要がある場合、データベースをエラー前の時点にリストアするためにフラッシュバック・ログが迅速に適用され、変更済ブロックがリストアされます。この処理は非常に高速であり、リカバリ時間は数時間から数分に短縮されます。また、この機能は簡単に使用できます。 1 つの文を発行することで、データベースを午後 2 時 5 分の時点にリカバリできます。データベースをリカバリするには、データベースのすべてのインスタンスを停止して、その後、インスタンスの 1 つをマウントする必要があります。次に、FLASHBACK DATABASE文の例を示します。

FLASHBACK DATABASE TO TIMESTAMP SYSDATE-1;



フラッシュバック・データベースを使用する場合、テープからのリストア、長い停止時間、および複雑なリカバリ手順は必要とされません。フラッシュバック・データベースを使用して、データベースを読取り専用モードでオープンし、その内容を調査することも可能です。フラッシュバックした時点が希望の位置と比べて前後した場合は、FLASHBACK DATABASE文を再発行するか、データベースが破損する前の適切な時点を見つけるために、より新しい時点にまでリカバリを続けることができます。フラッシュバック・データベースは、本番データベース、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースで動作します。

フラッシュバック・データベースを使用する際に推奨される手順は、次のとおりです。

1. データベースをフラッシュバックする日時または SCN を決定します。

2. 十分なフラッシュバック・ログ情報が存在することを確認します。

SELECT OLDEST_FLASHBACK_SCN, TO_CHAR(OLDEST_FLASHBACK_TIME, 'mon-dd-yyyy HH:MI:SS') FROM V$FLASHBACK_DATABASE_LOG;

3. データベースを特定の日時または SCN にフラッシュバックします。（フラッシュバック・データベースを実行するにはデータベースをマウントする必要があります。）

FLASHBACK DATABASE TO SCN scn;

または

FLASHBACK DATABASE TO TIMESTAMP TO_DATE date;

4. データベースを読取り専用モードでオープンして、正しい状態になっていることを確認します。

ALTER DATABASE OPEN READ ONLY;

追加のフラッシュバック・データが必要な場合は、もう一度 FLASHBACK DATABASE文を発行します。（フラッシュバック・データベースを実行するにはデータベースをマウントする必要があります。）

時間的に前に進めるには、次のような文を発行します。

RECOVER DATABASE UNTIL [TIME | CHANGE] date | scn;


ALTER DATABASE OPEN RESETLOGS;

フラッシュバック・データベースを使用する際のその他の考慮事項は、次のとおりです。

� 目的の時点にフラッシュバックするのに十分なフラッシュバック・ログが存在しない場合、次のいずれかの方法をかわりに使用します。

– Data Guard を使用して、目的の時点にリカバリするか（スタンバイ・データベースがプライマリ・データベースより遅れている場合）、目的の時点にフラッシュバックします（スタンバイ・データベースに十分なフラッシュバック・ログが存在する場合）。

– バックアップからリストアします。

� データベースのフラッシュバック後は、スタンバイ・データベースなどの依存データベースもすべてフラッシュバックする必要があります。 4-46 ページの 4.3 項「フォルト・トレランスのリストア」を参照してください。

フラッシュバック・データベースでは、削除した表領域は自動的に修復されませんが、その機能を使用して停止時間を大幅に短縮できます。表領域が削除される前の時点に本番データベースをフラッシュバックして、関連する表領域から対応するデータファイルのバックアップをリストアし、表領域が削除される前の時点にリカバリできます。


フォルト・トレランスのリストア

削除された表領域をフラッシュバック・データベースを使用して修復するには、次の推奨手順を実行します。

1. 表領域を削除したときの SCN または日時を特定します。

2. 表領域が削除される前の時点にデータベースをフラッシュバックします。次のような文を使用できます。

FLASHBACK DATABASE TO BEFORE SCN drop_scn;

3. データファイルのリストア、名前変更、およびオンラインへの移行を行います。

a. 関連する表領域のデータファイルのみをバックアップからリストアします。

b. 無名ファイルの名前を変更してバックアップ・ファイルにします。

ALTER DATABASE RENAME FILE '.../UNNAMED00005' to 'restored_file';

4. データファイルをオンラインに移行します。

ALTER DATABASE DATAFILE 'name' ONLINE;

5. データベースを問い合せてリカバリします。

SELECT CHECKPOINT_CHANGE# FROM V$DATAFILE_HEADER WHERE FILE#=1;RECOVER DATABASE UNTIL CHANGE checkpoint_change#;


ALTER DATABASE OPEN RESETLOGS;

4.3 フォルト・トレランスのリストアフォルト・トレランスのリストアフォルト・トレランスのリストアフォルト・トレランスのリストア高可用性アーキテクチャのコンポーネントに障害が発生すると、アーキテクチャの完全保護

（フォルト・トレランス）は損われ、そのコンポーネントが修復されるまでシングル・ポイント障害の可能性が存在することになります。高可用性アーキテクチャに完全なフォルト・トレランスを回復し、RAC、Data Guard または MAA による完全保護を再確立するには、障害コンポーネントを修復する必要があります。計画済の停止時間中には、完全なフォルト・トレランスは損われる可能性がありますが、その修復方法はよく理解されています。この停止は計画されたもので、リスクは制御されており、通常はアプリケーションの可用性を継続するのにも適した時間に実行されるためです。ただし、計画外の停止時間においては、シングル・ポイント障害が発生する可能性を明確に理解する必要があります。

この項には、データベースのフォルト・トレランスを回復するのに必要な手順を記載した次の項目が含まれます。

� RAC を使用した Oracle Database 10g の場合

– RAC クラスタの障害ノードまたは障害インスタンスのリストア

� Data Guard を使用した Oracle Database 10g と、RAC および Data Guard を使用した Oracle Database 10g（MAA）の場合

– フェイルオーバー後のスタンバイ・データベースのリストア

– 障害後の ASM ディスク・グループのリストア

– セカンダリ・サイトでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア

– スタンバイ・データベースのデータ障害後のフォルト・トレランスのリストア

– RESETLOGS による本番データベースのオープン後のフォルト・トレランスのリストア

– 二重障害後のフォルト・トレランスのリストア



4.3.1 RAC クラスタの障害ノードまたは障害インスタンスのリストアクラスタの障害ノードまたは障害インスタンスのリストアクラスタの障害ノードまたは障害インスタンスのリストアクラスタの障害ノードまたは障害インスタンスのリストアアプリケーション・サービスを RAC クラスタ内（またはプライマリ・サイトとセカンダリ・サイト間）で自動的にすばやくフェイルオーバーすることは、計画済の停止と計画外の停止の両方に備えるうえで重要です。また、エラーまたは問題の修正後に、環境で完全なフォルト・トレランスを回復するためには、RAC クラスタ内または各サイトのデータベースで障害インスタンスや障害ノードをリストアするための手順およびプロセスを理解しておくことも重要です。

特定のコンポーネントに初に障害を発生させる原因となった主要な問題を修正したら、クラスタに障害ノードを戻すことや、RAC の障害インスタンスを再起動することは簡単です。ただし、次のことを検討する必要があります。

� 現在稼働中の環境に影響をまったく与えないか、小限の影響で抑えるためにこれらのタスクを実行するのに適な時期

� フェイルオーバー用に変更したため、再設定する必要のあるネットワーク・コンポーネント（ロード・バランサなど）の再構成

� 既存の接続のフェイルバックまたは再調整

ノードまたはインスタンスの初の障害を引き起こした問題を修正したら、ノードまたはインスタンスを再起動していつでも RAC 環境に戻すことができます。ノードの再構成を完了するための処理では、追加のシステム・リソースを必要とする場合があります。

表 4-13 に、ノードの追加時に必要とされる可能性のある追加処理をまとめます。


� サービス可用性のリカバリ

� RAC インスタンスのリストア後のクライアント接続に関する考慮事項

表表表表 4-13 ノードまたはインスタンスの再起動または再結合時の追加処理ノードまたはインスタンスの再起動または再結合時の追加処理ノードまたはインスタンスの再起動または再結合時の追加処理ノードまたはインスタンスの再起動または再結合時の追加処理

アクションアクションアクションアクション追加リソース追加リソース追加リソース追加リソース

ノードの再起動またはクラスタへのノードの再結合

Oracle クラスタウェアのみを使用している場合、新規ノードをクラスタに結合するこ

とによる影響はありません。

ベンダーのクラスタウェアを使用している場合、ノードをクラスタに戻すための再構成中にパフォーマンスが低下する可能性があります。現在のアプリケーションに対す

る影響は、フル・ワークロードのテストで評価しておく必要があります。

RAC インスタンスの再起動ま

たは再結合

RAC インスタンスを再起動する場合、ロックの再構成中はパフォーマンスに多少影響

する可能性があります。現在のアプリケーションに対する影響は、通常はほとんどあ

りませんが、フル・ワークロードのテストで評価しておく必要があります。


� ノードを起動してクラスタに結合する方法の詳細な手順は、ベンダーが指定するクラスタ管理ドキュメントを参照してください。

� RAC インスタンスを再起動する方法の詳細は、『Oracle Database Oracle Clusterware および Oracle Real Application Clusters 管理およびデプロイメント・ガイド』を参照してください。



4.3.1.1 サービス可用性のリカバリサービス可用性のリカバリサービス可用性のリカバリサービス可用性のリカバリ障害ノードがクラスタに戻され、そのインスタンスが起動されると、Cluster Ready Services

（CRS）によってノードで使用される仮想 IP アドレスと、インスタンスでサポートされるサービスが自動的に管理されます。リストアされたインスタンスでは、特定のサービスが起動される場合と起動されない場合があります。 CRS がリストアされたインスタンスでサービスを起動するかどうかは、サービスがどのように構成されているかと、その時点で適切な数のインスタンスがサービスへのアクセスを提供しているかどうかによって決定されます。初の障害が発生したときに CRS によって移動された稼働中のインスタンスで、サービスが現在も適切に提供されている場合、そのサービスは優先インスタンスに再配置されません。 CRS がリストアされたインスタンスでサービスを再起動するのは、クラスタ全体でサービスへのアクセスを提供しているインスタンスの数が、そのサービスに定義されている優先インスタンスの数より少ない場合です。 CRS は、リストアされたインスタンスでサービスを再起動すると、登録アプリケーションにサービスの変更を通知します。

たとえば、優先インスタンス A および B と、障害時用の使用可能インスタンス C および D で定義されている HR サービスがあるとします。インスタンス B に障害が発生すると、CRS はインスタンス C で自動的に HR サービスを起動します。その後インスタンス B が再起動しても、HR サービスはインスタンス C で稼働を続けます。CRS は、サービスを自動的に優先インスタンスに再配置しません。

次に、別の使用例を検討します。HR サービスが優先インスタンス A、B、C および D で定義されており、使用可能インスタンスは存在せず、サービスはクラスタ内のすべてのノードに分散されているとします。インスタンス B に障害が発生すると、HR サービスは残りの 3 つのノードで稼働を続けます。 CRS は、インスタンス B がクラスタに再結合されると、インスタンス B でHR サービスを自動的に起動します。これは、サービスの稼働しているインスタンスの数が、構成されているインスタンスの数より少ないためです。 CRS は、アプリケーションに対して、HR サービスがインスタンス B で再び使用可能になったことを通知します。

4.3.1.2 RAC インスタンスのリストア後のクライアント接続に関する考慮事項インスタンスのリストア後のクライアント接続に関する考慮事項インスタンスのリストア後のクライアント接続に関する考慮事項インスタンスのリストア後のクライアント接続に関する考慮事項RAC インスタンスのリストア後、システムの現在のリソース使用状況とパフォーマンス、アプリケーション構成、および実装されているネットワーク・ロード・バランシング機能によっては、追加の手順を実行する必要があります。

稼働を続ける RAC インスタンスに移行された（フェイルオーバーされたか、新規セッションとして開始された）既存の接続は、再起動されたインスタンスに自動的に再分散またはフェイルバックされません。ユーザーのフェイルバックまたは再分散は、必要な場合と必要でない場合があります。この決定は、現在のリソース使用状況と、ワークロードを適切に処理して許容可能なレスポンス時間内に応答できる稼働中のインスタンスの能力に応じて変化します。稼働を続ける RAC インスタンスがフル・ワークロードを実行するのに十分なリソースを保持していないか、許容可能なレスポンス時間内に応答できない場合は、再起動されたインスタンスに既存のユーザー接続の一部を移行（切断および再接続）する必要があります。

接続ロード・バランシングが構成されている場合は、使用頻度のも低いノードで必要に応じて新規接続が開始されます。したがって、新規接続は、時間の経過とともに自動的に分散されます。

アプリケーション・サービスでは、次の構成を使用できます。

� パーティション化する構成 : サービスは RAC インスタンスのサブセットで稼働します。

� パーティション化しない構成 : すべてのサービスがすべてのノードで均等に稼働します。

これは、データセットの結合を維持したままアプリケーションおよびデータベースの形式と機能をモジュール化する際に役立ちます。アプリケーションをパーティション化する場合、またはパーティション化と非パーティション化の組合せを使用する場合、各サービスのレスポンス時間と可用性を考慮する必要があります。特定のサービスの接続を再分散またはフェイルバックする必要がある場合、DBMS_SERVICE.DISCONNECT_SESSION PL/SQL プロシージャを使用して手動でワークロードを再調整できます。このプロシージャを使用すると、サービスの実行を続けながらそのサービスに関連付けられたセッションを切断できます。

関連資料関連資料関連資料関連資料 :『Oracle Database Oracle Clusterware および Oracle Real Application Clusters 管理およびデプロイメント・ガイド』



複数の RAC インスタンス全体でアプリケーション・サービスの負荷分散を行う場合、Oracle Net の接続時フェイルオーバーと接続ロード・バランシングを使用することをお薦めします。この機能では、フェイルオーバーやリストアに応じた変更作業が必要ありません。ハードウェア・ベース・ロード・バランサを使用することも可能です。ただし、（Oracle Net Services では認識される）個別のアプリケーション・サービスの区別と、インスタンスまたはノードのリストアに対して制限が加えられる可能性があります。たとえば、ノードまたはインスタンスがリストアされて新規接続の受信が開始される場合、リストアされたノードまたはインスタンスをハードウェア・ベース・ロード・バランサのロジックに含めるための手動による手順が必要になる可能性があります。これに対し、Oracle Net Services では手動による再構成は必要ありません。

表 4-14 に、インスタンス・リストア後の新規および既存の接続に関する考慮事項をまとめます。これらの考慮事項は、パーティション化、非パーティション化、またはその両方の組合せというアプリケーション・サービスの構成に応じて変化します。既存の接続の再分散が実際に必要であるかどうかは、リソース使用状況とレスポンス時間に応じて決定されます。

表表表表 4-14 リストアおよび接続フェイルバックリストアおよび接続フェイルバックリストアおよび接続フェイルバックリストアおよび接続フェイルバック

アプリケーション・アプリケーション・アプリケーション・アプリケーション・サービスサービスサービスサービス既存の接続のフェイルバックまたはリストア既存の接続のフェイルバックまたはリストア既存の接続のフェイルバックまたはリストア既存の接続のフェイルバックまたはリストア新規接続のフェイルバックまたはリストア新規接続のフェイルバックまたはリストア新規接続のフェイルバックまたはリストア新規接続のフェイルバックまたはリストア

パーティション化既存のセッションは、リストアされたインスタンスに自動的に再配置されません。 DBMS_SERVICE.DISCONNECT_SESSIONを使用する

と、手動でセッションを切断し、サービスを提供する稼働中のインスタンスの 1 つでセッションを再確

立できます。

Oracle Net Services 構成の使用により、リ

ストアされたインスタンスに自動的にルーティングされます。

非パーティション化インスタンスがリストアされた時点でそのインスタンスの負荷は低いため、負荷を再調整する必要がなければ特に何もする必要はありません。負荷を再調整

する必要がある場合は、アプリケーション・サービスをパーティション化している場合と同様の問題が発生します。

Oracle Net Services 構成の使用により、リ

ストアされたインスタンスに自動的にルーティングされます（そのインスタンスの負荷がも低いため）。



図 4-13 は、2 つのノードでパーティション化された RAC データベースを示しています。各インスタンスでは、異なるアプリケーション機能（HR および Sales）が提供されます。クライアント・プロセスは、必要とするサービスに基づいて適切なインスタンスに接続します。

図図図図 4-13 パーティション化されたパーティション化されたパーティション化されたパーティション化された 2 ノードのノードのノードのノードの RAC データベースデータベースデータベースデータベース

hb

hbhb

HR

Sales

HR

Sales



図 4-14 は、1 つの RAC インスタンスに障害が発生した場合を示しています。

図図図図 4-14 パーティション化されたデータベースでのパーティション化されたデータベースでのパーティション化されたデータベースでのパーティション化されたデータベースでの RAC インスタンスのフェイルオーバーインスタンスのフェイルオーバーインスタンスのフェイルオーバーインスタンスのフェイルオーバー

1 つの RAC インスタンスに障害が発生すると、サービスと既存のクライアント接続は、別のRAC インスタンスに自動的にフェイルオーバーされます。この例の場合、HR サービスと Salesサービスは、両方とも稼働を続ける RAC インスタンスによってサポートされます。また、Salesサービスに対する新規クライアント接続は、Sales サービスのサポートを開始したインスタンスにルーティングされます。

障害インスタンスが修復およびリストアされて図 4-13 の状態に戻り、Sales サービスがリストアされたインスタンスに再配置されると、フェイルオーバーされたクライアントと、フェイルオーバー先のインスタンスの Sales サービスに接続されていた新規クライアントは、それぞれ識別されてフェイルバックされる可能性があります。インスタンスのリストア後に開始される新規クライアント接続は、自動的に元のインスタンスに接続されます。したがって、時間の経過とともに古い接続は切断され、新規セッションは Sales サービスに接続されるため、クライアント負荷はリストアされたインスタンスに戻ります。リストアの直後に負荷の再調整が発生するかどうかは、リソース使用状況とアプリケーションのレスポンス時間に応じて決定されます。

hb

hbhb

HR

Sales

HR

Sales



図 4-15 は、パーティション化されていないアプリケーションを示しています。サービスは、アクティブな 2 つのインスタンス間で均等に分散されます。各インスタンスには、HR と Sales に対するクライアント接続が混在しています。

図図図図 4-15 パーティション化されていないパーティション化されていないパーティション化されていないパーティション化されていない RAC インスタンスインスタンスインスタンスインスタンス

1 つの RAC インスタンスに障害が発生すると、障害インスタンスで稼働していたサービスはCRS により移動されます。また、新規クライアント接続は、同じサービスを提供する使用可能な RAC インスタンスにのみルーティングされます。

障害インスタンスが修復およびリストアされて図 4-15 の状態に戻ると、一部のクライアントはリストアされたインスタンスに戻される可能性があります。パーティション化されていないアプリケーションでは、すべての使用可能なインスタンス間でクライアント負荷を再調整するために適切なサービスを識別する必要はありません。この処理は、単一のインスタンスでリクエストを十分に処理できない場合にのみ必要です。

インスタンスのリストア後に開始される新規クライアント接続は、自動的にリストアされたインスタンスに接続されます（そのインスタンスの負荷が他と比べて低いためです）。したがって、時間の経過とともに古い接続は切断され、新規セッションはリストアされたインスタンスに接続されるため、クライアント負荷は再び使用可能なすべての RAC インスタンス間で均等に分散されます。リストアの直後に負荷の再調整が発生するかどうかは、リソース使用状況とアプリケーションのレスポンス時間に応じて決定されます。

hb

hbhb

HR

Sales

HR

Sales



4.3.2 フェイルオーバー後のスタンバイ・データベースのリストアフェイルオーバー後のスタンバイ・データベースのリストアフェイルオーバー後のスタンバイ・データベースのリストアフェイルオーバー後のスタンバイ・データベースのリストアフェイルオーバーを必要とする本番データベースの計画外の停止後、スタンバイ・データベースが再確立されるまで完全なフォルト・トレランスは損われます。データベースの完全保護は、可能なかぎり迅速に回復する必要があります。フォルト・トレランスを回復する手順は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースで多少異なります。

Data Guard ファスト・スタート・フェイルオーバーを使用している場合、データベースは自動的に復元されます。ファスト・スタート・フェイルオーバーが完了すると、オブザーバは、自動的に以前のプライマリ・データベースをスタンバイ・データベースとして復元するよう試みます。復元復元復元復元により、ブローカ構成に高可用性が回復され、新規プライマリ・データベースに障害が発生した際に再度ファスト・スタート・フェイルオーバーを起動できます。復元されたデータベースは、新規プライマリ・データベース用としてファスト・スタート・フェイルオーバーのターゲットとなるため、再度のファスト・スタート・フェイルオーバーが可能になります。新規スタンバイ・データベースは、新規プライマリ・データベースから受信された REDOデータの適用を開始することで、フェイルオーバーの実行可能なターゲットとなります。

ブローカにより、以前のプライマリ・データベースがスタンバイ・データベースとして復元されるため、プライマリ・データベースを再有効化する必要や、フラッシュバック・データベース操作を手動で実行する必要はありません。以前のプライマリ・データベースを復元する場合、データベースを起動してマウントする必要がありますが、オープンすることはできません。ブローカは、以前のスタンバイ・データベースと同じタイプ（フィジカルまたはロジカル）のスタンバイ・データベースとしてデータベースを復元します。

以前のプライマリ・データベースが自動的に復元されない場合、DGMGRL REINSTATEコマンドまたは Enterprise Manager を使用して手動で復元できます。手動復元の詳細な手順は、


Oracle のフラッシュバック・データベース機能を使用する場合、スタンバイ・データベースを再インスタンス化する必要はありません。フラッシュバック・データベースには、次のメリットがあります。

� 数時間に及ぶデータベースのリストア時間を節約できます。

� フォルト・トレランスを回復する際の全体的な複雑さを軽減できます。

� スタンバイ・データベースが迅速に再作成されるため、システムが脆弱である時間が短縮されます。


� ファスト・スタート・フェイルオーバー後のスタンバイ・データベースのリストア

� Enterprise Manager を使用したフェイルオーバー後のスタンバイ・データベースの復元

関連資料関連資料関連資料関連資料 :『Oracle Data Guard 概要および管理』の次の項を参照してください。

� 障害が発生したプライマリ・データベースのフィジカル・スタンバイ・データベースへのフラッシュバックに関する項

� 障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへのフラッシュバックに関する項



4.3.2.1 ファスト・スタート・フェイルオーバー後のスタンバイ・データベースファスト・スタート・フェイルオーバー後のスタンバイ・データベースファスト・スタート・フェイルオーバー後のスタンバイ・データベースファスト・スタート・フェイルオーバー後のスタンバイ・データベースのリストアのリストアのリストアのリストアファスト・スタート・フェイルオーバーの後、オブザーバは、定期的に以前のプライマリ・データベースに再接続するよう試みます。以前のプライマリ・データベースへのネットワーク・アクセスを再確立すると、オブザーバは、Data Guard Broker に対するリクエストを起動して、そのデータベースを新規プライマリ・データベース用のスタンバイ・データベースとして自動的に復元します。これにより、新規プライマリ・データベースにおける障害保護と高可用性が迅速に回復されます。

ファスト・スタート・フェイルオーバーは、ブローカ構成内のデータベースに接続しながら、Enterprise Manager でオブザーバ・サイトを含む任意のサイトから有効化できます。ブローカでは、図 4-16 に示されている Oracle Enterprise Manager のページでボタンを 1 回クリックするだけで簡単にスイッチオーバーやフェイルオーバーを起動できます。

図図図図 4-16 有効化に成功したファスト・スタート・フェイルオーバーとオブザーバ有効化に成功したファスト・スタート・フェイルオーバーとオブザーバ有効化に成功したファスト・スタート・フェイルオーバーとオブザーバ有効化に成功したファスト・スタート・フェイルオーバーとオブザーバ



4.3.2.2 Enterprise Manager を使用したフェイルオーバー後のスタンバイ・を使用したフェイルオーバー後のスタンバイ・を使用したフェイルオーバー後のスタンバイ・を使用したフェイルオーバー後のスタンバイ・データベースの復元データベースの復元データベースの復元データベースの復元Enterprise Manager を使用して、以前のプライマリ・データベースを新規スタンバイ・データベースとして復元することも可能です。図 4-17 は、復元が必要な場合に Enterprise Manager に表示される警告メッセージの例を示しています。

図図図図 4-17 ファスト・スタート・フェイルオーバー後の以前のプライマリ・データベースの復元ファスト・スタート・フェイルオーバー後の以前のプライマリ・データベースの復元ファスト・スタート・フェイルオーバー後の以前のプライマリ・データベースの復元ファスト・スタート・フェイルオーバー後の以前のプライマリ・データベースの復元

4.3.3 障害後の障害後の障害後の障害後の ASM ディスク・グループのリストアディスク・グループのリストアディスク・グループのリストアディスク・グループのリストア4-32 ページの 4.2.6.3 項「データ領域ディスク・グループ障害」または 4-34 ページの 4.2.6.4 項

「フラッシュ・リカバリ領域ディスク・グループ障害」の手順に従ってください。



4.3.4 セカンダリ・サイトでの計画済の停止後またはクラスタ全体の停止後セカンダリ・サイトでの計画済の停止後またはクラスタ全体の停止後セカンダリ・サイトでの計画済の停止後またはクラスタ全体の停止後セカンダリ・サイトでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストアのフォルト・トレランスのリストアのフォルト・トレランスのリストアのフォルト・トレランスのリストア

セカンダリ・サイトで計画済のメンテナンスを実行したら、スタンバイ・データベースとログ適用サービスを再起動する必要があります。その後、Data Guard によって自動的に同期が実行されます。 Enterprise Manager と Data Guard Broker を使用して、Data Guard の状態を監視できます。

セカンダリ・サイトでの計画済の停止後、またはクラスタ全体の停止後に、次の手順を実行して完全なフォルト・トレランスを回復する必要があります。

1. スタンバイ・データベースを起動します。

スタンバイ・データベースは、ローカル・バックアップ、ローカル・テープ・バックアップまたはプライマリ・サイト・バックアップ（セカンダリ・サイトのデータが破損している場合）からリストアする必要があります。『Oracle Data Guard 概要および管理』のスタンバイ・データベースを作成する手順に従って、新規本番データベースからスタンバイ・データベースを再作成します。

スタンバイ・データベースを再確立したら、スタンバイ・データベースを起動します。

2. REDO Apply（フィジカル・スタンバイ）または SQL Apply（ロジカル・スタンバイ）を開始します。

3. 本番データベースで REDO 転送サービスを検証します。

状況により、本番データベースのリモート・アーカイブの宛先を再有効化する必要があります。初に V$ARCHIVE_DEST_STATUSビューを問い合せて、アーカイブの宛先の現在の状態を確認します。

SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR, SRL FROM V$ARCHIVE_DEST_STATUS;ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE; ALTER SYSTEM ARCHIVE LOG CURRENT;

エラーをチェックして本番データベースとスタンバイ・データベース間の REDO 転送サービスを検証します。 V$ARCHIVE_DESTビューと V$ARCHIVE_DEST_STATUSビューを問い合せます。

SELECT STATUS, TARGET, LOG_SEQUENCE, TYPE, PROCESS, REGISTER, ERROR FROM V$ARCHIVE_DEST; SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE STATUS!='INACTIVE';

注意注意注意注意 : 次の手順は、（後述の説明のとおり）手動で実行するか、Enterprise Manager を使用して自動で実行することができます。

表表表表 4-15 フィジカルおよびロジカル・スタンバイ・データベースを起動するためのフィジカルおよびロジカル・スタンバイ・データベースを起動するためのフィジカルおよびロジカル・スタンバイ・データベースを起動するためのフィジカルおよびロジカル・スタンバイ・データベースを起動するための SQL 文文文文

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

フィジカル STARTUP MOUNT;

ロジカル STARTUP;

表表表表 4-16 REDO Apply およびおよびおよびおよび SQL Apply を開始するためのを開始するためのを開始するためのを開始するための SQL 文文文文

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

フィジカル RECOVER MANAGED STANDBY DATABASE DISCONNECT;

ロジカル ALTER DATABASE START LOGICAL STANDBY APPLY;



4. リカバリがスタンバイ・データベースで進行中であることを確認します。

� フィジカル・スタンバイ・データベースの場合、管理リカバリ・プロセスからのエラーがないことと、アーカイブ REDO ログ・ファイルから REDO が適用されていることを次のように確認します。

SELECT MAX(SEQUENCE#), THREAD# FROM V$LOG_HISTORY GROUP BY THREAD;SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, CLIENT_PROCESS FROM V$MANAGED_STANDBY;

� ロジカル・スタンバイ・データベースの場合、ロジカル・スタンバイ・プロセスからのエラーがないことと、アーカイブ REDO ログから REDO が適用されていることを次のように確認します。

SELECT THREAD#, SEQUENCE# SEQ# FROM DBA_LOGSTDBY_LOG LOG, DBA_LOGSTDBY_PROGRESS PROG WHERE PROG.APPLIED_SCN BETWEEN LOG.FIRST_CHANGE# AND LOG.NEXT_CHANGE# ORDER BY NEXT_CHANGE#;

5. 本番データベースの保護モードを回復します。

スタンバイ・データベースの停止のために、本番データベースの保護モードを大保護モードから大可用性モードまたは大パフォーマンス・モードに変更する必要があった場合、ビジネス要件に応じて大保護モードに戻します。

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE [PROTECTION | AVAILABILITY];

4.3.5 スタンバイ・データベースのデータ障害後のフォルト・トレランスのスタンバイ・データベースのデータ障害後のフォルト・トレランスのスタンバイ・データベースのデータ障害後のフォルト・トレランスのスタンバイ・データベースのデータ障害後のフォルト・トレランスのリストアリストアリストアリストア

データ障害やメディア障害など、データファイルの完全リストアまたは部分リストアを必要とするスタンバイ・データベースでの計画外の停止後、スタンバイ・データベースが稼働を再開するまで完全なフォルト・トレランスは損われます。データベースの完全保護は、可能なかぎり迅速に回復する必要があります。

ロジカル・スタンバイ・データベースのデータ破損およびデータ障害を修復するには、プライプライプライプライマリ・データベースのバックアップではなく、ロジカル・スタンバイ・ファイルのバックアッマリ・データベースのバックアップではなく、ロジカル・スタンバイ・ファイルのバックアッマリ・データベースのバックアップではなく、ロジカル・スタンバイ・ファイルのバックアッマリ・データベースのバックアップではなく、ロジカル・スタンバイ・ファイルのバックアップが必要ですプが必要ですプが必要ですプが必要です。それ以外の方法では、破損によって影響を受けた関連オブジェクトを再インスタンス化するか、再作成する必要があります。

スタンバイ・データベースのデータ破損またはデータ障害を修復する場合、次の修復ソリューションを使用できます。

� RMAN ブロック・メディア・リカバリの使用（4-38 ページの 4.2.7.2 項を参照）

� RMAN データファイル・メディア・リカバリの使用（4-39 ページの 4.2.7.3 項を参照）

� ロジカル・スタンバイ・データベース専用の手動によるオブジェクトの再作成（4-39 ページの 4.2.7.4 項を参照）

スタンバイ・データベースの停止のために、本番データベースの保護モードを大保護モードから大可用性モードまたは大パフォーマンス・モードに変更する必要があった場合、ビジネス要件に応じて大保護モードに戻します。

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE [PROTECTION | AVAILABILITY];

関連資料関連資料関連資料関連資料 :『Oracle Data Guard 概要および管理』



4.3.6 RESETLOGS による本番データベースのオープン後のフォルト・トレランスによる本番データベースのオープン後のフォルト・トレランスによる本番データベースのオープン後のフォルト・トレランスによる本番データベースのオープン後のフォルト・トレランスのリストアのリストアのリストアのリストア

本番データベースが、論理エラーの修正のためにフラッシュバックされたか、任意の時点にリストアおよびリカバリされてアクティブ化された場合、状況によっては対応するスタンバイ・データベースで追加メンテナンスを実行する必要があります。本番データベースのリカバリがリセットログ操作なしで完了した場合、追加の作業は必要ありません。

RESETLOGSオプション付きで本番データベースをオープンした後に、表 4-17 の問合せを実行します。

表 4-18 に、スタンバイ・データベースがプライマリ・データベースのリセットログ SCN より遅れている場合に、フォルト・トレランスを回復するために実行できるアクションを示します。

表表表表 4-17 RESETLOGS SCN と現在のと現在のと現在のと現在の SCN OPEN RESETLOGS を確認するための問合せを確認するための問合せを確認するための問合せを確認するための問合せ

データベースデータベースデータベースデータベース問合せ問合せ問合せ問合せ

本番データベース SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE;

フィジカル・スタンバイ

SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE;

ロジカル・スタンバイ

SELECT APPLIED_SCN FROM DBA_LOGSTDBY_PROGRESS;

表表表表 4-18 スタンバイ・データベースのスタンバイ・データベースのスタンバイ・データベースのスタンバイ・データベースの SCN が本番データベースのリセットログが本番データベースのリセットログが本番データベースのリセットログが本番データベースのリセットログ SCN より遅れているより遅れているより遅れているより遅れている

場合のアクション場合のアクション場合のアクション場合のアクション

データベースデータベースデータベースデータベースアクションアクションアクションアクション


1. スタンバイ・データベースが本番データベースから新規アーカイブREDO ログ・ファイルを受信していることを確認します。

関連項目関連項目関連項目関連項目 : 4-56 ページの「本番データベースで REDO 転送サービスを検

証します。」

2. REDO Apply を再開します。


スタンバイ・データベースが本番データベースから新規アーカイブ REDO ロ

グ・ファイルを受信していることを確認します。

関連項目関連項目関連項目関連項目 : 4-56 ページの「本番データベースで REDO 転送サービスを検証し

ます。」



表 4-19 に、スタンバイ・データベースがプライマリ・データベースのリセットログ SCN より進んでいる場合に、フォルト・トレランスを回復するために実行できるアクションを示します。

表表表表 4-19 スタンバイ・データベースのスタンバイ・データベースのスタンバイ・データベースのスタンバイ・データベースの SCN が本番データベースのリセットログが本番データベースのリセットログが本番データベースのリセットログが本番データベースのリセットログ SCN より進んでいるより進んでいるより進んでいるより進んでいる場合のアクション場合のアクション場合のアクション場合のアクション



1. スタンバイ・データベースが本番データベースから新規アーカイブREDO ログ・ファイルを受信していることを確認します。

関連項目関連項目関連項目関連項目 : 4-56 ページの「本番データベースで REDO 転送サービスを検

証します。」

2. 必要に応じて SHUTDOWN IMMEDIATE文を発行します。

3. STARTUP MOUNT文を発行します。

4. FLASHBACK DATABASE TO SCN flashback_scn文を発行します。こ

こで、flashback_scnは、表 4-17 の本番データベースの問合せで戻さ

れる SCN です。本番データベースの問合せで戻される SCN は、

RESETLOGS_CHANGE#より 2 少ない数です。

FLASHBACK DATABASE TO SCN resetlogs_change#_minus_2文

を発行します。

5. リアルタイム適用を指定するか、または指定せずに REDO Apply を再開

します。

リアルタイム適用を指定する場合 :

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

リアルタイム適用を指定しない場合 :

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;




1. 本番データベースのフラッシュバック時間または SCN を取得します。フラッシュバック時間または SCN は、本番データベースのアラート・ロ

グから抽出する必要があります。この操作では、データベースの存在す

るマシン間で時刻が一致していることを前提としています。一致していない場合は、フラッシュバック時間を調整する必要があります。

2. SQL Apply を停止します。

ALTER DATABASE STOP LOGICAL STANDBY APPLY;SELECT APPLIED_SCN FROM DBA_LOGSTDBY_PROGRESS;

3. 次の SQL 文を発行して、プライマリ・データベースをフラッシュバック

したのと同じ時点にロジカル・スタンバイ・データベースをフラッシュバックします。

SHUTDOWN;STARTUP MOUNT EXCLUSIVE;FLASHBACK DATABASE TO TIMESTAMP

time_of_primary_database_flashback;ALTER DATABASE OPEN READ ONLY;SELECT APPLIED_SCN FROM DBA_LOGSTDBY_PROGRESS;

後の SQL 文では、DBA_LOGSTDBY_PROGRESSビューの

APPLIED_SCN列を問い合せています。この問合せの結果で、SQL Apply による適用が手順 2 で取得された APPLIED_SCN以下であること

を確認します。この SCN を超えている場合は、データベースをさらに

フラッシュバックする必要があります。

4. リセットログ操作付きでロジカル・スタンバイ・データベースをオープンします。

SHUTDOWN;STARTUP MOUNT EXCLUSIVE;ALTER DATABASE OPEN RESETLOGS;

5. プライマリ・データベースの現在のログをアーカイブします。

ALTER SYSTEM ARCHIVE LOG CURRENT;

6. SQL Apply を開始します。

ALTER DATABASE START LOGICAL STANDBY APPLY;

表表表表 4-19 スタンバイ・データベースのスタンバイ・データベースのスタンバイ・データベースのスタンバイ・データベースの SCN が本番データベースのリセットログが本番データベースのリセットログが本番データベースのリセットログが本番データベースのリセットログ SCN より進んでいるより進んでいるより進んでいるより進んでいる場合のアクション（続き）場合のアクション（続き）場合のアクション（続き）場合のアクション（続き）



計画済の停止による停止時間の回避または短縮

4.3.7 二重障害後のフォルト・トレランスのリストア二重障害後のフォルト・トレランスのリストア二重障害後のフォルト・トレランスのリストア二重障害後のフォルト・トレランスのリストアスタンバイ・データベースと本番データベースの両方に影響する二重障害が発生した場合、先に本番データベースを再作成する必要があります。各サイトは同一であるため、新のバックアップが存在する場所であればどこでも本番データベースを作成できます。

表 4-20 に、使用可能なバックアップのタイプに応じたリカバリ計画をまとめます。

4.4 計画済の停止による停止時間の回避または短縮計画済の停止による停止時間の回避または短縮計画済の停止による停止時間の回避または短縮計画済の停止による停止時間の回避または短縮この項では、計画済の停止による停止時間を回避または短縮するためのベスト・プラクティスについて説明します。この項には、次の各項目が含まれます。

� ストレージ・メンテナンス

� RAC データベース・パッチ

� データベース・アップグレード

� データベースのプラットフォームまたはロケーションの移行

� データベースおよびアプリケーションのオンライン・アップグレード

� データベース・オブジェクトの再編成

� システム・メンテナンス

表表表表 4-20 本番データベースとスタンバイ・データベースの再作成本番データベースとスタンバイ・データベースの再作成本番データベースとスタンバイ・データベースの再作成本番データベースとスタンバイ・データベースの再作成

使用可能なバックアップ使用可能なバックアップ使用可能なバックアップ使用可能なバックアップ本番データベースの再作成本番データベースの再作成本番データベースの再作成本番データベースの再作成

本番データベースとスタンバイ・データベースのローカル・バックアップ

本番データベースのバックアップをリストアします。データベースをリカ

バリして新規本番データベースとしてアクティブ化します。

スタンバイ・データベースにのみ存在するローカル・バックアップスタンバイ・データベースのテープ・バックアップ

スタンバイ・データベースのローカル・バックアップをスタンバイ・データベースにリストアします。データベースをリカバリして新規本番データ

ベースとしてアクティブ化します。

テープ・バックアップのみテープ・バックアップをローカルでリストアします。データベースをリカ

バリして新規本番データベースとしてアクティブ化します。

関連資料関連資料関連資料関連資料 : 本番データベースの再作成後、新規スタンバイ・データベースを作成する手順の詳細は、『Oracle Data Guard 概要および管理』を参照してください。



4.4.1 ストレージ・メンテナンスストレージ・メンテナンスストレージ・メンテナンスストレージ・メンテナンスシステムにストレージを追加する場合、次の手順を使用する必要があります。次の各項の手順では、ストレージを ASM ディスク・グループに追加すると仮定します。

� ASM ストレージへの移行

� ストレージの追加と削除

4.4.1.1 ASM ストレージへの移行ストレージへの移行ストレージへの移行ストレージへの移行ファイル・システムまたは RAW デバイスにデータベース・ファイルを格納する既存の Oracleデータベースがある場合、それらのデータベース・ファイルの一部または全部を ASM に移行できます。これを行うには、DBMS_FILE_TRANSFERパッケージを使用します。

4.4.1.2 ストレージの追加と削除ストレージの追加と削除ストレージの追加と削除ストレージの追加と削除ディスクは、停止時間なしで ASM を対象に追加または削除できます。ディスクを追加または削除すると、ASM によって自動的にリバランス操作が開始され、ディスク・グループの内容がディスク・グループ内のすべてのドライブに均等に分散されます。

ストレージを追加または削除するためのベスト・プラクティスは、次のとおりです。

� 停止時間なしでホスト・オペレーティング・システムを対象にストレージを追加または削除するための方法を調査します。

� 複数のディスク・ドライブを追加または削除する場合、単一の ALTER DISKGROUPコマンドを使用します。

たとえば、ストレージ・メンテナンスで新規ドライブを追加し、既存のドライブを削除する場合、新規ドライブを追加するための ADD DISK句と、既存のドライブを削除するための DROP DISK句を指定した単一の ALTER DISKGROUPコマンドを使用します。たとえば、次のようになります。

ALTER DISKGROUP data DROP DISK diska5 ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9;

� ディスク・グループからディスクを削除する場合、削除対象のドライブの内容が他のドライブに移行されるまで ALTER DISKGROUP文が戻されないように、REBALANCE句にWAITオプションを指定します。文が完了したら、システムから安全にドライブを削除できます。たとえば、次のようになります。

ALTER DISKGROUP dataDROP DISK diska5ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9REBALANCE WAIT;

� 標準または高冗長性ディスク・グループのディスクを削除する場合、完全な冗長性を再構築するのに十分な空き領域がディスク・グループに存在することを確認します。

� Enterprise Manager を使用するか、V$ASM_OPERATIONを問い合せることでリバランス操作の進行状況を監視します。

� データベース・アクティビティの頻度が低い期間に長く実行されるリバランス操作では、リバランスの大能力が向上するため、リバランス時間を短縮できます。


� RMAN を使用してデータベースを ASM に移行する手順の詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

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



4.4.2 RAC データベース・パッチデータベース・パッチデータベース・パッチデータベース・パッチRAC では、特定のデータベース・パッチをノードまたはインスタンスごとに適用できるため、アプリケーションとデータベースを継続的に使用できます。データベース・ソフトウェア用の個別パッチを適用するのは、通常、インストール環境で発生したソフトウェア問題の既知の修正策を実装する場合か、問題に関する情報を収集するための診断パッチを適用する場合です。このようなパッチ適用は、一般的に、計画された停止期間中のメンテナンスで実行されます。

Oracle では、データベースをまったく停止しないか、小限の停止時間で Real Application Clusters のローリング・パッチ・アップグレードを実行できます。この操作を行うためのツールは、opatchコマンドライン・ユーティリティです。

RAC ローリング・アップグレードのメリットは、パッチ・アップグレードに必要とされる計画済の停止期間中でも、RAC インストール環境の一部のインスタンスを使用できることです。停止する必要があるのは、現在パッチを適用中の RAC インスタンスのみです。その他のインスタンスは、引き続き使用できます。これにより、このような計画済の停止に必要とされるアプリケーションの停止時間に対する影響を小限に抑えることができます。 Oracle の opatchユーティリティでは、RAC インストール環境の異なるインスタンスに対して連続的にパッチを適用できます。

ローリング・アップグレード機能は、オラクル社がローリング・アップグレードに適切であると認定したパッチでのみ使用できます。一般的に、ローリング・アップグレードでは次のパッチをインストールできます。

� データベースの内容（データ・ディクショナリなど）に影響を与えないパッチ

� RAC のノード間通信に関連しないパッチ

� SQL*Plus、Oracle ユーティリティ、開発ライブラリ、Oracle Net などのクライアント側のツールに関連するパッチ

� データファイル・ヘッダー、制御ファイル、カーネル・モジュールの共通ヘッダー定義などの共有データベース・リソースを変更しないパッチ

パッチのローリング・アップグレードは、現在個別パッチでのみ使用可能です。パッチ・セットでは使用できません。

ローリング・パッチ・アップグレードは、Oracle データベース・ソフトウェアが異なるノード間で共有される配置環境では使用できません。これに該当するのは、クラスタ・ファイル・システム（CFS）上、またはファイル・サーバーや NFS マウント・ドライブにより提供される共有ボリューム上に Oracle ホームが存在する場合です。この機能を使用できるのは、各ノードがOracle データベース・ソフトウェアの独自のコピーを所有している場合のみです。

4.4.2.1 停止時間を最小化するためのベスト・プラクティス停止時間を最小化するためのベスト・プラクティス停止時間を最小化するためのベスト・プラクティス停止時間を最小化するためのベスト・プラクティスすべてのデータベース・パッチ・アップグレードで、次の推奨プラクティスを使用します。

� オラクル社カスタマ・サポート・センターに連絡して、パッチが現在の問題と配置環境に有効であることを必ず確認します。

� パッチを適用する計画とともに、パッチをバック・アウトする計画を作成します。

� パッチは先にテスト環境に適用し、問題が修正されることを確認します。

� パッチを適用する際の所要時間を見積もる場合、必要に応じてテクノロジ・スタックの他の層を起動および停止する時間も含めます。

� パッチが RAC ローリング・アップグレードに適しておらず、パッチの適用時に停止時間が発生する可能性がある場合、4-65 ページの 4.4.3 項「データベース・アップグレード」を参照して他の解決方法を実行できないかどうかを検討します。

関連資料関連資料関連資料関連資料 :『Oracle Database 管理者ガイド』の「自動ストレージ管理（ASM）の使用」



次に、RAC ローリング・アップグレードの追加の推奨プラクティスを示します。

� 複数のインスタンスで Oracle ホームを共有している場合、それらすべてのインスタンスがパッチの適用により影響を受けます。 DBA は、これにより意図しない別の問題が発生しないことを確認する必要があります。また、パッチの適用中は、ノード上のこのようなインスタンスをすべて停止する必要があります。計画済の停止では、このことを考慮してください。ベスト・プラクティスとしては、類似するアプリケーションのみでノード上のOracle ホームを共有します。これにより、パッチ適用の柔軟性が向上します。

� 各ノードの Oracle インベントリは、そのノードにインストールされている Oracle データベース・ソフトウェアのリポジトリです。インベントリは、各ノードに固有です。インベントリは、ノードにインストールされているすべての Oracle ソフトウェアにより共有されます。このインベントリがノード間で類似するのは、配置されている Oracle データベース・ソフトウェア、配置構成およびパッチ・レベルに関してすべてのノードがまったく同じである場合のみです。 Oracle インベントリは、パッチ適用およびパッチ管理プロセスに非常に役立つため、その整合性を維持することをお薦めします。 Oracle インベントリは、特定のノードの Oracle ソフトウェアにパッチをインストールするたびにバックアップする必要があります。この原則は、クラスタの各ノードの Oracle インベントリに適用されます。

� Oracle Universal Installer を使用してすべての Oracle データベース・ソフトウェアをインストールします。これにより、関連するリポジトリ・エントリがクラスタの各ノードのOracle インベントリに作成されます。また、既存の RAC クラスタにノードを追加する場合も Oracle Universal Installer を使用します。

ただし、この操作を実行していない場合や、なんらかの理由で実行できない場合、opatchユーティリティの attachオプションを使用して、既存の Oracle データベース・ソフトウェア・インストールに関する情報を Oracle インベントリに追加できます。ノード情報もこのオプションで追加できます。

� ローリング・パッチ・アップグレードでは、その性質上、パッチを RAC クラスタの一部のノードにのみ適用できます。そのため、パッチの適用されているインスタンスと、パッチの適用されていないインスタンスが同時に稼働することになります。この状態は、ローリング・パッチ・アップグレード以外の方法では発生しません。 RAC 配置をアクティブ化する前であれば、ローリング・パッチ・アップグレード以外の方法ですべてのインスタンスにパッチを適用します。パッチをすべてのインスタンスに導入する前にテストする必要がある場合、混在環境は役立ちます。これを実現するのに推奨される方法は、-localオプション付きでパッチを適用することです。

RAC クラスタのすべてのインスタンスを同じパッチ・レベルで維持するため、検証の完了したパッチは、RAC インストール環境のすべてのノードに適用することを強くお薦めします。 RAC クラスタの各インスタンスが同じパッチ・ソフトウェアを維持している場合、パッチの修正対象である問題を発生させることなくインスタンス間でサービスを移行できます。

� すべてのパッチ（ローリング・アップグレードにより適用されるパッチを含む）は、オンラインで管理し、適用後も削除しないようにします。これは、パッチをロールバックまたは再適用する場合に役立ちます。

パッチは、クラスタのすべてのノードからアクセスできる場所に保存します。これにより、クラスタのすべてのノードで、同じようにパッチを適用またはロールバックできます。

� ローリング・パッチ・アップグレードは、他の任意のパッチ・アップグレードと同様に、ノードで別のパッチ・アップグレードまたは Oracle インストールが行われていない場合に実行します。複数のパッチの適用は、順次的に処理します。停止の計画も、各作業に応じて作成する必要があります。

� 複数のパッチを同時に適用する必要があり、かつそれらのパッチの一部のみがローリング・アップグレードに対応している場合、すべてのパッチをローリング・アップグレード以外の方法で適用します。これにより、パッチ適用プロセスに必要とされる合計時間を短縮できます。

� ローリング・アップグレードに適さないパッチの場合、RAC 配置用として次に適切なオプションは、applyコマンドの minimize_downtimeオプションです。

� ローリング・アップグレードは、システム使用率が低い場合に実行します。これにより、エンド・ユーザーのサービス中断を小限に抑えることができます。



4.4.3 データベース・アップグレードデータベース・アップグレードデータベース・アップグレードデータベース・アップグレードデータベース・アップグレードを実行する場合、次の Oracle 機能を使用できます。

� データベース・アップグレード・アシスタント（DBUA）

� Data Guard SQL Apply（ロジカル・スタンバイ・データベース）

� Oracle Streams

� トランスポータブル表領域

データベース・アップグレードの実行方法は、次のことを考慮したうえで選択します。

� アップグレードを完了するのに必要な停止時間

� 停止時間の前に必要な設定時間および作業

� 一時的に必要となる追加リソース（ディスク領域や CPU など）

� アップグレードを完了するのに必要な手順の複雑さ

表 4-21 に、プラットフォーム移行およびデータベース・アップグレードに使用できる方法と、その方法の使用が推奨される場合についてリストします。

4.4.3.1 データベース・アップグレード・アシスタントデータベース・アップグレード・アシスタントデータベース・アップグレード・アシスタントデータベース・アップグレード・アシスタントデータベース・アップグレード・アシスタント（DBUA）は、データベースを以前のソフトウェア・リリースからインプレースでアップグレードする際に使用します。

小限の停止時間でデータベース・アップグレードを実行する際に、DBUA を適切なツールとして使用するかどうかを決定する場合、次の点を考慮してください。

� DBUA により、データベース・ディクショナリとインストール済のすべてのコンポーネント（Java、XDB、Streams など）がアップグレードされますが、アップグレード中は通常のユーザー・アクティビティでデータベースを使用できなくなります。

� DBUA を使用したデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。

– すべてのデータベース・ディクショナリ・オブジェクトを新規バージョンにアップグレードする時間

– すべての PL/SQL を再コンパイルする時間

– アップグレードしたデータベースにクライアントを再接続する時間

DBUA によるアップグレードの実行時間がメンテナンス・ウィンドウ内に収まる場合は、データベース・アップグレードに DBUA を使用してください。

関連資料関連資料関連資料関連資料 : opatch ユーティリティの詳細は、『Oracle Universal Installer および Opatch ユーザーズ・ガイド』を参照してください。

表表表表 4-21 プラットフォーム移行およびデータベース・アップグレードのオプションプラットフォーム移行およびデータベース・アップグレードのオプションプラットフォーム移行およびデータベース・アップグレードのオプションプラットフォーム移行およびデータベース・アップグレードのオプション

アップグレード方法アップグレード方法アップグレード方法アップグレード方法この方法を使用する場合この方法を使用する場合この方法を使用する場合この方法を使用する場合

データベース・アップグレード・アシスタント

メンテナンス・ウィンドウが十分な場合に推奨される方法

Data Guard SQL Apply（ロ

ジカル・スタンバイ）

DBUA がメンテナンス・ウィンドウ内に終了せず、データベースが

RAC ローリング・パッチ・アップグレードに適していない場合

Oracle Streams すでに Streams が実装されている場合、または使用中のデータベー

ス・リリースが Data Guard SQL Apply のローリング・アップグ

レードでサポートされない場合

トランスポータブル表領域 Data Guard SQL Apply または Streams でサポートされないデータ

型をデータベースで使用している場合



4.4.3.2 Data Guard SQL Apply（ロジカル・スタンバイ）（ロジカル・スタンバイ）（ロジカル・スタンバイ）（ロジカル・スタンバイ）Data Guard SQL Apply を使用すると、ローリング・アップグレードというプロセスを使用して小限の停止時間でデータベースをアップグレードできます。現在のところ、Data Guard では、プライマリ・データベースとスタンバイ・データベースが同じプラットフォームで稼働する同機種環境をサポートしています。

データベース・アップグレード時の停止時間を小化するために Data Guard SQL Apply が適切な方法であるかどうかを決定する場合、次の点を考慮してください。

� Data Guard SQL Apply インフラストラクチャでは Oracle Streams を使用するため、ユーザー定義型に関する Oracle Streams データ型の制限も継承されます（オブジェクト型、REF 値、VARRAY、ネストした表など）。

� ローリング・アップグレードがサポートされるのは、Oracle Database 10g リリース 1（10.1.0.3）以上です。ソース・データベースとターゲット・データベースに関して、サポートされるリリースの制限は、Oracle Streams の制限より強い拘束性があります。

� Data Guard SQL Apply を使用したデータベース・アップグレード（ローリング・アップグレード）に必要な停止時間は、次の操作に要する時間によって決定されます。

– Data Guard スイッチオーバーを実行する時間

– 新規データベースにクライアントを再接続する時間

DBUA によるアップグレードがメンテナンス・ウィンドウ内に完了せず、アプリケーションでユーザー定義型を使用していない場合は、Data Guard SQL Apply のローリング・データベース・アップグレードを使用してください。

4.4.3.3 Oracle StreamsOracle Streams を使用すると、小限の停止時間でデータベース・ソフトウェアをあるリリースから別のリリースにアップグレードできます。その理由は、Oracle Streams では、異なるデータベース・リリースに基づいてプライマリ・データベースとそのレプリカが稼働する構成がサポートされるためです。

データベース・アップグレードに Oracle Streams が適切な方法であるかどうかを決定する場合、次の点を考慮してください。

� Oracle Streams では、ユーザー定義型がサポートされません（オブジェクト型、REF 値、VARRAY、ネストした表など）。ただし、サポート外のデータ型を含まないプライマリ・データベースでシャドウ表を作成し、そのシャドウ表をレプリケートすることが可能です。

� ソース・データベースでは、Oracle9i リリース 2 以上が稼働している必要があります。

� Oracle Streams 環境を設定および維持するための管理作業は、Data Guard SQL Apply のデータベース・アップグレードを使用する場合よりも多くなります。

� ソース・データベースとターゲット・データベースをパラレルに実行してターゲット・データベースに変更を伝播する場合、ソース・データベースにパフォーマンス上の影響が発生する可能性があります。

� Oracle Streams を使用したデータベース・アップグレードに必要な停止時間は、キュー内の残りのトランザクションを適用する時間と、新規データベースにクライアントを再接続する時間によって決定されます。

アプリケーションですでに Oracle Streams を使用している場合、またはクライアントでユーザー定義型を使用しておらず、追加の管理作業が発生しても停止時間を小限に抑えたい場合は、Oracle Streams の使用を検討してください。

関連資料関連資料関連資料関連資料 : DBUA および Oracle データベース・ソフトウェアのアップグレードの詳細は、『Oracle Database アップグレード・ガイド』を参照してください。

関連資料関連資料関連資料関連資料 : SQL Apply の詳細は、『Oracle Data Guard 概要および管理』を参照してください。



4.4.3.4 トランスポータブル表領域トランスポータブル表領域トランスポータブル表領域トランスポータブル表領域トランスポータブル表領域を使用すると、すべてのユーザー・データファイルを事前に作成および準備されたターゲット・データベースにトランスポートすることで、データベース・アップグレードを実行できます。

データベース・アップグレードの実行にトランスポータブル表領域が適切な方法であるかどうかを決定する場合、次の点を考慮してください。

� SYSTEM表領域は、トランスポータブル表領域で移動できません。ユーザー定義やアプリケーションに必要なオブジェクトを含むターゲット・データベースの SYSTEM表領域の内容は、手動で構築する必要があります。 SYSTEM表領域の内容を移動する場合、Data Pumpを使用します。

� トランスポータブル表領域を使用したデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。

– ソース・データベースの表領域を読取り専用モードにする時間

– トランスポータブル・メタデータのネットワーク・インポートを実行する時間

– ターゲット・データベースがリモート・システムに存在する場合、ソース・システムからターゲット・システムにすべてのデータファイルを転送する時間

データファイルの転送時間を大幅に短縮するには、ファイルを物理的に移動することなくターゲット・システムでデータファイルを利用可能にするストレージ・インフラストラクチャを使用するか、フィジカル・スタンバイ・データベースを使用します。

DBUA がメンテナンス・ウィンドウ内に完了せず、データ型の制限から Oracle Streams またはData Guard SQL Apply を使用できない場合は、データベース・アップグレードを実行するのにトランスポータブル表領域を使用してください。

4.4.4 データベースのプラットフォームまたはロケーションの移行データベースのプラットフォームまたはロケーションの移行データベースのプラットフォームまたはロケーションの移行データベースのプラットフォームまたはロケーションの移行プラットフォーム移行を実行する場合、次の Oracle 機能を使用できます。

� トランスポータブル・データベース

� Oracle Streams

� Oracle Data Pump

� トランスポータブル表領域

� Data Guard REDO Apply（フィジカル・スタンバイ・データベース）

これらのデータベース・メンテナンス・タスクの実行方法は、次のことを考慮したうえで選択します。

� メンテナンス操作を完了するのに必要な停止時間

� 停止時間の前に必要な設定時間および作業

� 一時的に必要となる追加リソースの量（ディスク領域や CPU など）

� メンテナンス操作を完了するのに必要な手順の複雑さ

関連資料関連資料関連資料関連資料 : Oracle Streams を使用したデータベース・アップグレードの詳細は、『Oracle Streams 概要および管理』を参照してください。

関連資料関連資料関連資料関連資料 : トランスポータブル表領域の詳細は、『Oracle Database 管理者ガイド』を参照してください。



次の表に、プラットフォーム移行およびデータベース・アップグレードに使用できる方法と、操作ごとにその方法の使用が推奨される場合についてまとめます。

4.4.4.1 トランスポータブル・データベーストランスポータブル・データベーストランスポータブル・データベーストランスポータブル・データベーストランスポータブル・データベースは、Oracle Database 10g リリース 2（10.2）の新機能であり、データベース全体を同じエンディアン形式の別のプラットフォームに移行する際に推奨される方法です。

データベースを別のプラットフォームに移行する際にトランスポータブル・データベースが適切な方法であるかどうかを決定する場合、次の点を考慮してください。

� トランスポータブル・データベースでは、同じエンディアン形式のプラットフォーム間でのデータベースの移行がサポートされます。

� トランスポータブル・データベースを使用したプラットフォーム移行に必要な停止時間は、次の操作に要する時間によって決定されます。

– ソース・データベースを読取り専用モードにする時間

– すべてのデータファイルを新規プラットフォームの形式に変換する時間

– すべてのデータファイルをソース・システムからターゲット・システムに転送する時間

この時間を大幅に短縮するには、ファイルを物理的に移動することなくターゲット・システムでデータファイルを利用可能にするストレージ・インフラストラクチャを使用します。

トランスポータブル・データベースは、も簡単な方法であるため、同じエンディアン形式の別のプラットフォームにデータベース全体を移行する場合に推奨される方法です。

表表表表 4-22 プラットフォームおよびロケーション移行のオプションプラットフォームおよびロケーション移行のオプションプラットフォームおよびロケーション移行のオプションプラットフォームおよびロケーション移行のオプション

操作操作操作操作方法方法方法方法使用する場合使用する場合使用する場合使用する場合

同じエンディアン・プラットフォームへのプラットフォーム移行

トランスポータブル・データベース

推奨される方法

Oracle Streams トランスポータブル・データベースがメンテナンス・ウィンドウ内に終了しない場合

異なるエンディアン・プラットフォームへのプラットフォーム移行

Oracle Data Pump 推奨される方法

Oracle Streams Data Pump がメンテナンス・ウィンドウ内

に終了しない場合

トランスポータブル表領域 Oracle Streams でサポートされないデータ

型をデータベースで使用している場合

ロケーション移行 Data Guard REDO Apply（フィジカル・スタンバイ・データベース）

推奨される方法

注意注意注意注意 : すべてのプラットフォームのエンディアン形式を確認するには、V$TRANSPORTABLE_PLATFORMビューを問い合せます。現在のシステムのプラットフォーム ID とプラットフォーム名を確認するには、V$DATABASEビューを問い合せます。

関連資料関連資料関連資料関連資料 : プラットフォーム間でトランスポータブル・データベースを使用する方法の詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。



4.4.4.2 Oracle StreamsOracle Streams を使用すると、小限の停止時間でデータベースをあるプラットフォームから別のプラットフォームに移行できます。その理由は、Oracle Streams では、異なるプラットフォームに基づいてプライマリ・データベースとそのレプリカが稼働する構成がサポートされるためです。

プラットフォーム移行に Oracle Streams が適切な方法であるかどうかを決定する場合、次の点を考慮してください。

� Oracle Streams では、ユーザー定義型がサポートされません（オブジェクト型、REF 値、VARRAY、ネストした表など）。

� Oracle Streams を使用してアップグレードを実行するには、ソース・データベースでOracle9i リリース 2 以上が稼働している必要があります。

� Oracle Streams 環境を設定および維持するための管理作業は、Data Guard SQL Apply のデータベース・アップグレードを使用する場合よりも多くなります。

� ソース・データベースとターゲット・データベースをパラレルに実行してターゲット・データベースに変更を伝播する場合、ソース・データベースにパフォーマンス上の影響が発生する可能性があります。

� Oracle Streams を使用したプラットフォーム移行に必要な停止時間は、キュー内の残りのトランザクションを適用する時間と、新規データベースにクライアントを再接続する時間によって決定されます。

アプリケーションでユーザー定義型を使用しておらず、追加の管理作業が発生しても停止時間を小限に抑えたい場合は、Oracle Streams の使用を検討してください。

4.4.4.3 Oracle Data PumpOracle Data Pump テクノロジを使用すると、異なるプラットフォーム間や異なるデータベース・リリース間でデータおよびメタデータをあるデータベースから別のデータベースに高速に移動できます。

プラットフォーム移行に Data Pump が適切な方法であるかどうかを決定する場合、次の点を考慮してください。

� Oracle Data Pump は、Oracle Database 10g リリース 1（10.1）以上でのみ使用できます。

� Data Pump を使用したプラットフォーム移行に必要な停止時間は、データベース全体のネットワーク・インポートを実行する時間によって決定されます。ネットワーク・インポートでは、ターゲット・システムとリモート・ソース・システム間のデータベース・リンクを使用してデータを取得し、そのデータをターゲット・システムに直接書き込みます

（ダンプ・ファイルは使用しません）。

異なるエンディアン形式のプラットフォームにデータベースを移行する場合、ネットワーク・インポート時間が許容範囲内であれば、Data Pump を使用してください。

関連資料関連資料関連資料関連資料 : Oracle Streams を使用したデータベース・アップグレードの詳細は、『Oracle Streams 概要および管理』を参照してください。


� Oracle Data Pump とエクスポートおよびインポート・ユーティリティの詳細は、『Oracle Database ユーティリティ』を参照してください。

� Oracle データベース・ソフトウェアのアップグレードの詳細は、『Oracle Database アップグレード・ガイド』を参照してください。



4.4.4.4 トランスポータブル表領域トランスポータブル表領域トランスポータブル表領域トランスポータブル表領域トランスポータブル表領域を使用すると、すべてのユーザー・データファイルを事前に作成および準備されたターゲット・データベースにトランスポートすることで、プラットフォーム移行を実行できます。

プラットフォーム移行の実行にトランスポータブル表領域が適切な方法であるかどうかを決定する場合、次の点を考慮してください。

� SYSTEM表領域は、トランスポータブル表領域で移動できません。ユーザー定義やクライアントに必要なオブジェクトを含むターゲット・データベースの SYSTEM表領域の内容は、手動で構築する必要があります。 SYSTEM表領域の必要な内容を移動する場合、Data Pumpを使用します。

� トランスポータブル表領域を使用したプラットフォーム移行またはデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。

– ソース・データベースの表領域を読取り専用モードにする時間

– トランスポータブル・メタデータのネットワーク・インポートを実行する時間

– すべてのデータファイルをソース・システムからターゲット・システムに転送する時間

この時間を大幅に短縮するには、ファイルを物理的に移動することなくターゲット・システムでデータファイルを利用可能にするストレージ・インフラストラクチャを使用します。

– RMAN を使用してすべてのデータファイルを新規プラットフォームの形式に変換する時間

Oracle Data Pump がメンテナンス・ウィンドウ内に完了せず、データ型の制限から Oracle Streams または Data Guard SQL Apply を使用できない場合は、新規プラットフォームへの移行にトランスポータブル表領域を使用してください。

4.4.4.5 Data Guard REDO Apply（フィジカル・スタンバイ・データベース）（フィジカル・スタンバイ・データベース）（フィジカル・スタンバイ・データベース）（フィジカル・スタンバイ・データベース）Data Guard REDO Apply を使用すると、一時スタンバイ・データベースをリモートの場所に設定してスイッチオーバー操作を実行することで、小限の停止時間でデータベースの場所をリモート・サイトに変更できます。

Data Guard REDO Apply を使用したロケーション移行に必要な停止時間は、スイッチオーバー操作を実行する時間によって決定されます。

関連資料関連資料関連資料関連資料 : トランスポータブル表領域の詳細は、『Oracle Database 管理者ガイド』を参照してください。

関連資料関連資料関連資料関連資料 : REDO Apply とフィジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard 概要および管理』を参照してください。



4.4.5 データベースおよびアプリケーションのオンライン・アップグレードデータベースおよびアプリケーションのオンライン・アップグレードデータベースおよびアプリケーションのオンライン・アップグレードデータベースおよびアプリケーションのオンライン・アップグレードOracle データベース・アップグレードは、すでに存在する以前のリリースの Oracle データベース・システムを現在のリリースの Oracle データベース・システムに変換するプロセスであり、場合によっては非常に長くかかります。アプリケーション・アップグレードには、データベース・アップグレードと、必要なアプリケーション・コードおよびスキーマの変更が含まれることがあります。 Data Guard によるデータベース・アップグレードを使用できず、データベースまたはアプリケーション・アップグレードの際の停止時間を 0（ゼロ）にするか小限に抑える必要がある場合、Oracle Streams を構成してデータベース・アップグレードを実行することで、停止時間を 0（ゼロ）または小限に抑えることができます。これを行うには、Oracle Streams を使用して次のデータベースで単一ソース・レプリケーション環境を構成します。

� ソース・データベース : アップグレード対象である元のデータベース。

� 取得データベース : アップグレード中に発生したソース・データベースに対する変更を取得プロセスで取得する場所となるデータベース。

� 宛先データベース : アップグレード・プロセス中に発生したソース・データベースに対する変更を適用プロセスで適用する場所となるソース・データベースのコピー。適用プロセスは、同じスキーマまたは異なるスキーマと、使用中のオブジェクト構造に適用できます。

具体的には、次の一般的な手順を使用して、データベースをオンラインにしたままデータベース・アップグレードを実行します。

1. 空の宛先データベースを作成します。

2. 元のデータベースがソース・データベースとなり、データベースのコピーがソースの変更を適用するための宛先データベースとなる Oracle Streams の単一ソース・レプリケーション環境を構成します。

3. 宛先データベースでデータベース・アップグレードを実行します。この間、元のソース・データベースはオンラインで使用可能です。

4. Oracle Streams を使用して、ソース・データベースで発生した変更を宛先データベースに適用します。

5. 宛先データベースにソース・データベースの変更がすべて適用されたら、ソース・データベースをオフラインにし、宛先データベースをアプリケーションおよびユーザーから使用可能にします。

スキーマまたはオブジェクト構造が宛先データベースで異なる場合、Streams 変換を組み入れて新規構造の変更を操作する必要があります。



図 4-18 は、このプロセスの概要を示しています。

図図図図 4-18 Oracle Streams によるデータベースのオンライン・アップグレードによるデータベースのオンライン・アップグレードによるデータベースのオンライン・アップグレードによるデータベースのオンライン・アップグレード

関連資料関連資料関連資料関連資料 :『Oracle Streams 概要および管理』の付録 C「Streams を使用したオンラインでのデータベースのメンテナンス」



4.4.6 データベース・オブジェクトの再編成データベース・オブジェクトの再編成データベース・オブジェクトの再編成データベース・オブジェクトの再編成データ・サーバーに関連する多くの計画済の停止には、データベース・オブジェクトの再編成が伴います。データベース・オブジェクトの再編成は、データベースの継続的な可用性を確保しながら実行する必要があります。 Oracle では、Oracle8i 以上でオブジェクトのオンライン再編成機能を使用できます。これらの機能により、基礎となるデータの変更中でもオブジェクトの再編成を実行できます。

表 4-23 に、Oracle Database 10g で使用可能なオブジェクトの再編成機能の一部を示します。

高可用性システムでは、問合せや DML のパフォーマンスを向上するために、頻繁にアクセスされる大規模な表を定期的に再定義する必要があります。 Oracle Database 10g のオンライン再編成および再定義機能により、管理者は、ユーザーによるデータベースへの完全なアクセスを維持しながら、これまでにない柔軟性に基づいて表の物理属性を変更し、データと表構造の両方を変換できます。この機能により、ミッション・クリティカルな環境で重要となるデータ可用性、問合せパフォーマンス、レスポンス時間およびディスク領域使用率が向上し、アプリケーション・アップグレード・プロセスをより簡単に、安全かつ迅速に行うことができます。

Oracle での推奨プラクティスは、DBMS_REDEFINITION PL/SQL パッケージを使用した表の再編成です。この方法を使用すると、表をオフラインにする必要のある従来の表の再定義方法と比較して可用性が大幅に向上するためです。 DBMS_REDEFINITIONをコマンドラインから手動でコールするか、Oracle Enterprise Manager から自動でコールするかにかかわらず、再編成プロセス全体がユーザーによる表への完全なアクセスを維持したまま実行されるため、システムの可用性が確保されます。

表表表表 4-23 オブジェクトの再編成機能の一部オブジェクトの再編成機能の一部オブジェクトの再編成機能の一部オブジェクトの再編成機能の一部

オブジェクト・オブジェクト・オブジェクト・オブジェクト・タイプタイプタイプタイプオブジェクトの再編成ソリューションの例オブジェクトの再編成ソリューションの例オブジェクトの再編成ソリューションの例オブジェクトの再編成ソリューションの例ソリューションの説明ソリューションの説明ソリューションの説明ソリューションの説明

表 DBMS_REDEFINITION PL/SQL パッケージ表をオンラインで再定義するメカニズムを提供するPL/SQL パッケージ。これは、Oracle での推奨ベスト・

プラクティスです。

索引索引の再構築以前に使用不可能としてマークされた索引を再構築します。

表領域表領域の名前変更表領域とその内容を再構築せずに既存の表領域名を変更することが可能です。



図 4-19 は、Oracle Enterprise Manager のオブジェクトの再編成ウィザードを示しています。このウィザードは、SQL*Plus のコマンドラインで DBMS_REDEFINITIONパッケージをコールする方法のかわりとして使用できます。ウィザードでいくつかの質問に答えると、スクリプトが自動生成されて再編成が実行されます。

図図図図 4-19 Oracle Enterprise Manager を使用したデータベース・オブジェクトの再編成を使用したデータベース・オブジェクトの再編成を使用したデータベース・オブジェクトの再編成を使用したデータベース・オブジェクトの再編成

DBMS_REDEFINITIONパッケージによる方法では、適切なすべての属性を含む仮表が作成されます。再編成プロセスは、表の現行バージョンと新規バージョンの間の列マッピングを記述するための START_REDEF_TABLEプロシージャをコールすることにより開始されます。トリガー、制約、索引などのすべての依存オブジェクトが、COPY_TABLE_DEPENDENTSプロシージャの使用によって仮表に自動的にコピーされます。再編成中に元表に発生した変更は、SYNC_INTERIM_TABLEプロシージャがコールされて仮表に追加されます。 FINISH_REDEF_TABLEプロシージャのコールにより再編成が完了すると、仮表の名前が変更されて主表になります。

Oracle Database 10g では、列、表およびデータファイルの名前と同様に、表領域の名前を変更できます。これまでは、表領域名を変更する唯一の方法は、その表領域を削除して再作成することでしたが、この方法では表領域の内容を削除して後で再構築する必要がありました。表領域名のオンライン変更機能では、ユーザー操作への割込みは発生しません。

ALTER TABLESPACE USERS RENAME TO new_tablespace_name;

Tablespace altered.

データの再編成を実行する場合は、次のことも考慮してください。

� オンライン操作中の表における同時アクティビティ。

オンライン操作中は、実表でのユーザー・アクティビティを小化することをお薦めします。オンライン操作中のデータベース・アクティビティによる影響は、表の 10% 未満とする必要があります。データベース管理者は、データベース・リソース・マネージャを使用してユーザーに十分なリソースを割り当てることで、データ再編成の影響を小限に抑えることができます。

� ピーク期間中にオンライン操作を実行することや、データのオンライン再編成中に大容量のデータ変更を伴うバッチ・ジョブを実行することは避けてください。

実際、オンライン操作中は、パラレル DML、ダイレクト・ロードおよびインポート / エクスポート機能は実行できません。



� オンラインで索引を再構築する方法と、索引を削除してからオンラインで新規索引を再作成する方法の比較。

オンラインで索引を再構築する場合、操作中に新規索引用の追加ディスク領域が必要です。一方、索引を削除して再作成する場合、追加ディスク領域は必要ありません。

� オンライン索引結合とオンライン索引再構築の比較。

オンライン索引結合は、インプレースのデータ再編成操作であるため、索引を再構築する場合のような追加ディスク領域は必要ありません。索引の再構築では、索引とソート領域の合計サイズに等しい一時ディスク領域が操作中に必要です。オンライン索引結合では、B ツリーの高さは減少しません。この場合、リーフ・ブロック数の削減が試行されるのみです。結合操作では、ユーザー用の領域は解放されませんが、索引スキャンのパフォーマンスは向上します。

索引を新規表領域に移動する必要がある場合は、オンライン索引再構築を使用してください。

� ローカル索引とグローバル索引。

Oracle Database 10g では、オンライン操作でローカル・パーティション索引とグローバル・パーティション索引の両方がサポートされます。表および索引がパーティション化されている場合、管理者は、一度に 1 つのパーティションを対象にこれらのオブジェクトのメンテナンスを実行することで、他のパーティションをオンラインのまま維持できます。


� 表のオンライン再定義の詳細は、『Oracle Database 管理者ガイド』を参照してください。

� オンライン・データ再編成および再定義に関する OTN の Web サイト（http://www.oracle.com/technology/deploy/availability/htdocs/online_ops.html）

� 追加のオンライン再定義ソリューションを説明したホワイト・ペーパー『Online Reorganization using Oracle Database 10g』（http://www.oracle.com/technology/deploy/availability/pdf/ha_10gR2_online_reorg_twp.pdf）



4.4.7 システム・メンテナンスシステム・メンテナンスシステム・メンテナンスシステム・メンテナンスインスタンス、ノード、またはその他のコンポーネントを分離する必要のある計画済の停止では、サービスを再配置、無効化および有効化する RAC の機能を使用できます。再配置機能では、サービスを別のインスタンスに移行できます。サービスとインスタンスは、ハードウェアまたはシステム・ソフトウェアでの修復、変更、アップグレードの実行中に選択的に無効化し、メンテナンスの完了後に再有効化することが可能です。これにより、メンテナンスによる停止中はサービスまたはインスタンスが起動しないことが保証されます。サービスとインスタンスは、計画済の停止の開始時に無効化します。その後、メンテナンスによる停止の終了時に有効化します。

RAC を使用している場合、ノードの開始時に Oracle クラスタウェア・デーモンが自動的に起動します。 1 回以上のシステム再起動を必要とするメンテナンス、またはオペレーティング・システム以外のすべてのプロセスを停止する必要のあるメンテナンスを実行する場合、crsctlコマンドの使用により Oracle クラスタウェア・デーモンの起動を停止して無効化します。メンテナンスが完了したら、crsctlコマンドで Oracle クラスタウェア・デーモンを有効化して起動します。

関連資料関連資料関連資料関連資料 : Enterprise Manager、DBCA、PL/SQL および SRVCTL を使用してサービスを管理する方法の詳細は、『Oracle Database Oracle Clusterwareおよび Oracle Real Application Clusters 管理およびデプロイメント・ガイド』を参照してください。

関連資料関連資料関連資料関連資料 : crsctlコマンドの使用方法の詳細は、『Oracle Database Oracle Clusterware および Oracle Real Application Clusters 管理およびデプロイメント・ガイド』を参照してください。


MAA 環境への

5
MAA 環境への移行環境への移行環境への移行環境への移行
この章では、簡易性やパフォーマンスを損うことなく現在の構成を Maximum Availability Architecture（MAA）環境に移行して、冗長性と信頼性を備えたシステムおよびデータベースを作成するための推奨ベスト・プラクティスについて説明します。


� MAA への移行の概要

� 単一インスタンスから RAC への移行

� RAC プライマリへの Data Guard 構成の追加

移行 5-1

MAA への移行の概要

5.1 MAA への移行の概要への移行の概要への移行の概要への移行の概要MAA では、Oracle Real Application Clusters（RAC）のスケーラビリティおよび可用性のメリットが、Oracle Data Guard のサイト保護機能と組み合されます。

MAA 環境環境環境環境は、RAC 本番データベースの存在する 1 つのサイトと、低 1 つのフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースをホストするクラスタの存在するもう 1 つのサイトで構成されます（可能であれば、ロジカル・スタンバイ・データベースとフィジカル・スタンバイ・データベースを組み合せてホストするのが理想的です）。この環境では、RAC を使用した Oracle Database 10g と Data Guard を使用した Oracle Database 10g の両方の機能とメリットが継承されるため、計画外および計画済の停止に対しても包括的なソリューションが提供されます。

MAA 構成には、RAC プライマリ・データベースと RAC スタンバイ・データベースの両方が含まれることが理想ですが、ビジネス要件やその他の考慮事項によっては異なる終了構成を選択することや、段階的移行を進めることも可能です。実際、一部の終了構成は、RAC プライマリと RAC スタンバイの組合せ構成を段階的に実装する場合の中間形態と考えることができます。

現在の構成設定に応じて、この章の関連する項を参照してください。表 5-1 に、例としていくつかの可能な開始構成に対応する移行手順を示します。

5.2 単一インスタンスから単一インスタンスから単一インスタンスから単一インスタンスから RAC への移行への移行への移行への移行RAC データベースを構成するためにノードを追加する手順では、まず Oracle クラスタウェアと RAC ソフトウェアを新規ノードにクローニングし、次に新規 RAC インスタンスを追加します。この手順には、次の基本タスクが含まれます。

1. クラスタに新規ノードを接続します。

2. クラスタウェアと Oracle ソフトウェアを新規ノードに拡張します。

3. 新規ノードに RAC 用の記憶域を準備します。

4. Oracle RAC データベース・レイヤーにノードを追加します。

5. 新規ノードにデータベース・インスタンスを追加します。

表表表表 5-1 MAA 環境に移行する前の開始構成環境に移行する前の開始構成環境に移行する前の開始構成環境に移行する前の開始構成

開始構成開始構成開始構成開始構成対応する移行手順対応する移行手順対応する移行手順対応する移行手順

単一インスタンスのプライマリ・データベース

プライマリ・データベースを RAC に移行します（5-2 ページの

「単一インスタンスから RAC への移行」の手順を参照）。

単一インスタンスのスタンバイ・データベース

スタンバイ・データベースを RAC に移行します（5-2 ページの

「単一インスタンスから RAC への移行」の手順を参照）。

単一インスタンスの Data Guard 構成

プライマリ・データベースまたはスタンバイ・データベース（あるいはその両方）を RAC に移行します（5-2 ページの「単一イン

スタンスから RAC への移行」の手順を参照）。

RAC プライマリ・データベー

ス（ただし非 Data Guard 構成）

単一インスタンスのスタンバイ・データベースまたは RAC スタ

ンバイ・データベースを構成に追加します（5-3 ページの「RACプライマリへの Data Guard 構成の追加」の手順を参照）。

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


RAC プライマリへの Data Guard 構成の追加

5.3 RAC プライマリへのプライマリへのプライマリへのプライマリへの Data Guard 構成の追加構成の追加構成の追加構成の追加RAC プライマリ・データベースに Data Guard 構成を追加する手順には、次の基本タスクが含まれます。

1. スタンバイ・データベースで Oracle Net Services を構成します。

2. スタンバイ・インスタンスおよびデータベースを作成します。

3. Data Guard のプライマリ・データベースを構成します。

4. Data Guard 構成を検証します。

これらのタスクを実行する方法の詳細な手順は、現在までに公開されている一連の MAA ホワイト・ペーパーを参照してください。次のホワイト・ペーパーでは、単一インスタンスの Data Guard スタンバイ・データベースまたは RAC スタンバイ・データベースを作成する方法について説明しています。

� 『MAA / Data Guard 10g Setup Guide - Creating a RAC Standby for a RAC Primary』

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10g_RACPrimaryRACStandby.pdf

� 『MAA / Data Guard 10g Setup Guide - Creating a Single Instance Standby for a RAC Primary』

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10g_RACPrimarySingleInstanceStandby.pdf

� 『MAA/ Data Guard 10g Setup Guide - Creating a RAC Logical Standby for a RAC Primary Database』

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_RACPrimaryRACLogicalStandby.pdf

このホワイト・ペーパーでは、既存の RAC フィジカル・スタンバイ・データベースからRAC ロジカル・スタンバイ・データベースを作成する方法と、次の基本手順について説明しています。

1. フィジカル・スタンバイ・データベース環境を準備します。

2. フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換します。

3. Data Guard 構成を検証します。

関連資料関連資料関連資料関連資料 : 単一インスタンスのフィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換する方法の詳細は、『Oracle Data Guard 概要および管理』の第 3 章および 4 章を参照してください。

MAA 環境への移行 5-3

RAC プライマリへの Data Guard 構成の追加


データベース SPFILE および Orac

A
データベースデータベースデータベースデータベース SPFILE およびおよびおよびおよび
Oracle Net 構成ファイルのサンプル構成ファイルのサンプル構成ファイルのサンプル構成ファイルのサンプル

この付録には、異なる高可用性アーキテクチャに関連するベスト・プラクティスを説明するための表およびファイル・サンプルが含まれます。これらのサンプルにより、データベース・サーバー・パラメータ・ファイル（SPFILE）が動的サービス登録でどのように Oracle Net 構成と関連しているかも理解できます。

この付録には、次の表およびサンプル・ファイルが含まれます。

� SPFILE サンプル

– 表 A-1「プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの一般的な SPFILE パラメータ」

– 表 A-2「プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの RAC 用 SPFILE パラメータ」

– 表 A-6「プライマリおよびフィジカル・スタンバイ・データベースのみの構成の Data Guard 用 SPFILE パラメータ」

– 表 A-7「プライマリおよびロジカル・スタンバイ・データベースのみの構成の Data Guard 用 SPFILE パラメータ」

– 表 A-8「プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの Data Guard 用 SPFILE パラメータ : 大可用性モードまたは大保護モード」

– 表 A-9「プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの Data Guard 用 SPFILE パラメータ : 大パフォーマンス・モード」

� Oracle Net 構成ファイル

– 動的インスタンス登録を使用するすべてのホストに対応する SQLNET.ORA の例

– 動的インスタンス登録を使用するすべてのホストに対応する LISTENER.ORA の例

– 動的インスタンス登録を使用するすべてのホストに対応する TNSNAMES.ORA の例

各表およびファイルは、次の構成に基づきます。

� ORACLE_BASE=/mnt/app/oracle

� /flash_recovery（データベース・フラッシュ・リカバリ領域）

le Net 構成ファイルのサンプル A-1

SPFILE サンプル

A.1 SPFILE サンプルサンプルサンプルサンプルこの項の表には、データベース、RAC および Data Guard のパラメータ・ファイルの値が含まれます。一部のパラメータは、一般的なデータベース・パラメータ表と RAC パラメータ表の両方に出現します。 RAC を使用している場合は、一般的なデータベース・パラメータ表の値のかわりに RAC パラメータ表の値を使用する必要があります。

これらのパラメータでは、Chicago にあるデータベース用の構成と、Boston にあるフィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベース用のオプション構成を示します。プライマリ・データベースは、SALESデータベースです。単一インスタンスのデータベースの場合、ORACLE_SIDのパラメータ値は、SALES、SALES_PHYSおよびSALES_LOGです。 RAC 構成の場合、対応するインスタンス番号が ORACLE_SIDの各パラメータ値に追加されます。

表 A-1 に、プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの構成に対応する一般的な SPFILE パラメータのベスト・プラクティスを示します。

表表表表 A-1 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの一般的なプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの一般的なプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの一般的なプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの一般的なSPFILE パラメータパラメータパラメータパラメータ

Chicago（プライマリ・データベース）（プライマリ・データベース）（プライマリ・データベース）（プライマリ・データベース） Boston（フィジカル・スタンバイ）（フィジカル・スタンバイ）（フィジカル・スタンバイ）（フィジカル・スタンバイ） Boston（ロジカル・スタンバイ）（ロジカル・スタンバイ）（ロジカル・スタンバイ）（ロジカル・スタンバイ）

*.COMPATIBLE='10.2.0' Chicago と同じ Chicago と同じ

*.CONTROL_FILES='_+DATA/SALES/controlfiles/control.265.263563526', '+RECO/SALES/controlfiles/control.276.263563526'

*.CONTROL_FILES='+DATA/SALES/controlfiles/backup.474.3736463483', '+RECO/SALES/cnortolfiles/backup.363.3736463483'

*.CONTROL_FILES='+DATA/SALES_LOG/controlfiles/backup.354.25365373', '+RECO/SALES_LOG/controlfiles/backup.352.25365373'

*.CONTROL_FILE_RECORD_KEEP_TIME=30 Chicago と同じ Chicago と同じ

*.DB_NAME='SALES' Chicago と同じ *.DB_NAME='SALES_LOG'

*.DB_CREATE_FILE_DEST=+DATA Chicago と同じ Chicago と同じ

*.DB_RECOVERY_FILE_DEST=+RECO Chicago と同じ Chicago と同じ

*.DB_RECOVERY_FILE_DEST_SIZE=100G Chicago と同じ Chicago と同じ

*.DB_FLASHBACK_RETENTION_TARGET=240 Chicago と同じ Chicago と同じ

*.BACKGROUND_CORE_DUMP=FULL Chicago と同じ Chicago と同じ

*.BACKGROUND_DUMP_DEST='mnt/app/oracle/admin/SALES/bdump'

*.BACKGROUND_DUMP_DEST='mnt/app/oracle/admin/SALES/bdump'

*.BACKGROUND_DUMP_DEST='mnt/app/oracle/admin/SALES_LOG/bdump'

*.CORE_DUMP_DEST='/mnt/app/oracle/admin/SALES/cdump'

*.CORE_DUMP_DEST='/mnt/app/oracle/admin/SALES/cdump'

*.CORE_DUMP_DEST='/mnt/app/oracle/admin/SALES_LOG/cdump'

*.USER_DUMP_DEST='/mnt/app/oracle/admin/SALES/udump'

*.USER_DUMP_DEST='/mnt/app/oracle/admin/SALES/udump'

*.USER_DUMP_DEST='/mnt/app/oracle/admin/SALES_LOG/udump'

*.DB_BLOCK_CHECKING=MEDIUM Chicago と同じ1 Chicago と同じ

*.DB_BLOCK_CHECKSUM=FULL Chicago と同じ Chicago と同じ

*.LOG_ARCHIVE_FORMAT='arch_%t_%S_%r.log'

Chicago と同じ Chicago と同じ

*.LOG_ARCHIVE_TRACE=0 Chicago と同じ Chicago と同じ

*.FAST_START_MTTR_TARGET=300 Chicago と同じ Chicago と同じ

*.STATISTICS_LEVEL=TYPICAL Chicago と同じ Chicago と同じ

A-2　Oracle Database 高可用性ベスト・プラクティス

SPFILE サンプル

表 A-2 に、プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの構成に対応する RAC 用 SPFILE パラメータのベスト・プラクティスを示します。

表 A-3 に、プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの構成に対応する Data Guard 用 SPFILE パラメータのベスト・プラクティスを示します。これらのパラメータは、Data Guard Broker を使用しているかどうかにかかわらず設定する必要があります。

*.LOCAL_LISTENER='SALES_lsnr' Chicago と同じ Chicago と同じ

*.REMOTE_LISTENER='SALES_remotelsnr_CHICAGO'

*.REMOTE_LISTENER='SALES_remotelsnr_BOSTON'

*.REMOTE_LISTENER='SALES_remotelsnr_BOSTON'

*.UNDO_MANAGEMENT=AUTO Chicago と同じ Chicago と同じ

*.UNDO_RETENTION=900 Chicago と同じ Chicago と同じ

*.UNDO_TABLESPACE='UNDOTBS' Chicago と同じ Chicago と同じ

*.RESUMABLE_TIMEOUT=900 Chicago と同じ Chicago と同じ

1 リカバリ・パフォーマンスに悪影響を与える場合は、DB_BLOCK_CHECKING=FALSEと設定することで無効化できます。

表表表表 A-2 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの RAC 用用用用 SPFILE パラメータパラメータパラメータパラメータ


*.CLUSTER_DATABASE=TRUE Chicago と同じ Chicago と同じ

SALES1.THREAD=1 SALES_PHYS1.THREAD=1 SALES_LOG1.THREAD=1

SALES2.THREAD=2 SALES_PHYS2.THREAD=2 SALES_LOG2.THREAD=2

SALES1.INSTANCE_NUMBER=1 SALES_PHYS1.INSTANCE_NUMBER=1 SALES_LOG1.INSTANCE_NUMBER=1

SALES2.INSTANCE_NUMBER=2 SALES_PHYS2.INSTANCE_NUMBER=2 SALES_LOG2.INSTANCE_NUMBER=2

SALES1.INSTANCE_NAME=SALES_CHICAGO1

SALES_PHYS1.INSTANCE_NAME=SALES_BOSTON1

SALES_LOG1.INSTANCE_NAME=SALES_BOSTON_LOG1

SALES2.INSTANCE_NAME=SALES_CHICAGO2

SALES_PHYS2.INSTANCE_NAME=SALES_BOSTON2

SALES_LOG2.INSTANCE_NAME=SALES_BOSTON_LOG2

SALES1.UNDO_TABLESPACE='UNDOTBS1'

SALES_PHYS1.UNDO_TABLESPACE='UNDOTBS1'

SALES_LOG1.UNDO_TABLESPACE='UNDOTBS1'

SALES2.UNDO_TABLESPACE='UNDOTBS2'

SALES_PHYS2.UNDO_TABLESPACE='UNDOTBS2'

SALES_LOG2.UNDO_TABLESPACE='UNDOTBS2'

表表表表 A-3 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの Data Guard 用用用用 SPFILE パラパラパラパラメータメータメータメータ


*.DB_UNIQUE_NAME='SALES_CHICAGO' *.DB_UNIQUE_NAME='SALES_BOSTON' *.DB_UNIQUE_NAME='SALES_BOSTON_LOG'

表表表表 A-1 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの一般的なプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの一般的なプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの一般的なプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの一般的なSPFILE パラメータ（続き）パラメータ（続き）パラメータ（続き）パラメータ（続き）


データベース SPFILE および Oracle Net 構成ファイルのサンプル A-3

SPFILE サンプル

表 A-4 に、プライマリ・データベースおよびフィジカル・スタンバイ・データベースのみの構成に対応する Data Guard 用 SPFILE パラメータのベスト・プラクティスを示します。 Data Guard Broker を使用してデータベース環境を管理している場合、表 A-3 と表 A-4 の値のみを設定する必要があります。

表 A-5 に、Data Guard Broker を使用してデータベース環境を管理していない場合の、プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの構成に対応する Data Guard 用 SPFILE パラメータのベスト・プラクティスを示します。 Data Guard Broker を使用していない場合、表 A-6 から表 A-9 のパラメータも設定する必要があります。

表 A-6 に、プライマリ・データベースおよびフィジカル・スタンバイ・データベースのみの構成に対応する Data Guard 用 SPFILE パラメータのベスト・プラクティスを示します。これらのパラメータは、Data Guard Broker を使用してデータベース環境を管理していない場合に設定する必要があります。

表表表表 A-4 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの Data Guard Broker 用用用用SPFILE パラメータパラメータパラメータパラメータ


*.DB_BROKER_CONFIG_FILE_1='+DATA/SALES_CHICAGO/dr1SALES_CHICAGO.dat'

*.DB_BROKER_CONFIG_FILE_1='+DATA/SALES_BOSTON/dr1SALES_BOSTON.dat'

*.DB_BROKER_CONFIG_FILE_1='+DATA/SALES_BOSTON_LOG/dr1SALES_BOSTON_LOG.dat'

*.DB_BROKER_CONFIG_FILE_2='+DATA/SALES_CHICAGO/dr2SALES_CHICAGO.dat'

*.DB_BROKER_CONFIG_FILE_2='+DATA/SALES_BOSTON/dr2SALES_BOSTON.dat'

*.DB_BROKER_CONFIG_FILE_2='+DATA/SALES_BOSTON_LOG/dr2SALES_BOSTON_LOG.dat'

*.DG_BROKER_START=TRUE Chicago と同じ Chicago と同じ

表表表表 A-5 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの Data Guard 用用用用 SPFILEパラメータ（パラメータ（パラメータ（パラメータ（Broker 不使用時）不使用時）不使用時）不使用時）


*.LOG_FILE_NAME_CONVERT=' ',' ' Chicago と同じ Chicago と同じ

*.STANDBY_FILE_MANAGEMENT=AUTO Chicago と同じ Chicago と同じ

*.REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE


表表表表 A-6 プライマリおよびフィジカル・スタンバイ・データベースのみの構成のプライマリおよびフィジカル・スタンバイ・データベースのみの構成のプライマリおよびフィジカル・スタンバイ・データベースのみの構成のプライマリおよびフィジカル・スタンバイ・データベースのみの構成の Data Guard 用用用用 SPFILE パラメータパラメータパラメータパラメータ

Chicago（プライマリ・データベース）（プライマリ・データベース）（プライマリ・データベース）（プライマリ・データベース） Boston（フィジカル・スタンバイ・データベース）（フィジカル・スタンバイ・データベース）（フィジカル・スタンバイ・データベース）（フィジカル・スタンバイ・データベース）

*.FAL_CLIENT='SALES_CHICAGO' *.FAL_CLIENT='SALES_BOSTON'

*.FAL_SERVER='SALES_BOSTON' *.FAL_SERVER='SALES_CHICAGO'

*.DB_UNIQUE_NAME='SALES_CHICAGO' *.DB_UNIQUE_NAME='SALES_BOSTON'

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(SALES_CHICAGO,SALES_BOSTON)'

Chicago と同じ

*.LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST arch mandatory valid_for=(ALL_LOGFILES,ALL_ROLES) db_unique_name=SALES_CHICAGO'

*.LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST arch mandatory valid_for=(ALL_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON'

*.LOG_ARCHIVE_DEST_2='service=SALES_BOSTON lgwr sync affirm net_timeout=30 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_BOSTON'

*.LOG_ARCHIVE_DEST_2='service=SALES_CHICAGO lgwr sync affirm net_timeout=30 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_CHICAGO'


SPFILE サンプル

表 A-7 に、プライマリ・データベースおよびロジカル・スタンバイ・データベースのみの構成に対応する Data Guard 用 SPFILE パラメータのベスト・プラクティスを示します。これらのパラメータは、Data Guard Broker を使用してデータベース環境を管理していない場合に設定する必要があります。

表 A-8 は、大可用性モードまたは大保護モードで稼働する Data Guard 環境に適用されます。

表表表表 A-7 プライマリおよびロジカル・スタンバイ・データベースのみの構成のプライマリおよびロジカル・スタンバイ・データベースのみの構成のプライマリおよびロジカル・スタンバイ・データベースのみの構成のプライマリおよびロジカル・スタンバイ・データベースのみの構成の Data Guard 用用用用 SPFILE パラメータパラメータパラメータパラメータ

Chicago（プライマリ・データベース）（プライマリ・データベース）（プライマリ・データベース）（プライマリ・データベース） Boston（ロジカル・スタンバイ・データベース）（ロジカル・スタンバイ・データベース）（ロジカル・スタンバイ・データベース）（ロジカル・スタンバイ・データベース）

*.FAL_CLIENT='SALES_CHICAGO' *.FAL_CLIENT='SALES_BOSTON_LOG'

*.FAL_SERVER='SALES_BOSTON_LOG' *.FAL_SERVER='SALES_CHICAGO'

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(SALES_CHICAGO,SALES_BOSTON_LOG)'

Chicago と同じ

*.STANDBY_ARCHIVE_DEST=+RECO/SALES_CHICAGO/archivelog/FAL/

*.STANDBY_ARCHIVE_DEST=+RECO/SALES_BOSTON/archivelog/FAL/

*.LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST arch max_failure=0 mandatory valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_CHICAGO'

*.LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST arch max_failure=0 mandatory valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON_LOG'

*.LOG_ARCHIVE_DEST_2='service=SALES_BOSTON_LOG reopen=15 max_failure=10 lgwr sync affirm net_timeout=30 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_BOSTON_LOG'

*.LOG_ARCHIVE_DEST_2='service=SALES_CHICAGO lgwr sync affirm net_timeout=30 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_CHICAGO'

*.LOG_ARCHIVE_DEST_3 = 'location=+RECO/SALES_CHICAGO/archivelog/SRL/ arch max_failure=0 mandatory valid_for=(STANDBY_LOGFILES,STANDBY_ROLE) db_unique_name=SALES_CHICAGO'

*.LOG_ARCHIVE_DEST_3= 'location=+RECO/SALES_BOSTON/archivelog/SRL/ arch max_failure=0 mandatory valid_for=(STANDBY_LOGFILES,STANDBY_ROLE) db_unique_name=SALES_BOSTON_LOG'

表表表表 A-8 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの Data Guard 用用用用 SPFILEパラメータパラメータパラメータパラメータ : 最大可用性モードまたは最大保護モード最大可用性モードまたは最大保護モード最大可用性モードまたは最大保護モード最大可用性モードまたは最大保護モード


*.FAL_CLIENT='SALES_CHICAGO' *.FAL_CLIENT='SALES_BOSTON' *.FAL_CLIENT='SALES_BOSTON_LOG'

*.FAL_SERVER='SALES_BOSTON','SALES_BOSTON_LOG'

*.FAL_SERVER='SALES_CHICAGO','SALES_BOSTON_LOG'

*.FAL_SERVER='SALES_CHICAGO','SALES_BOSTON'

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(SALES_CHICAGO,SALES_BOSTON,SALES_BOSTON_LOG)'


*.STANDBY_ARCHIVE_DEST='+RECO/SALES_CHICAGO/archivelog/FAL/'

*.STANDBY_ARCHIVE_DEST='+RECO/SALES_BOSTON/archivelog/FAL/'

*.STANDBY_ARCHIVE_DEST='+RECO/SALES_BOSTON_LOG/archivelog/FAL/

*.LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST arch mandatory valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_CHICAGO'

*.LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST arch mandatory valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON'

*.LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST arch max_failure=0 mandatory valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON_LOG'


SPFILE サンプル

表 A-9 に、大パフォーマンス・モードで稼働する Data Guard 環境に応じたパラメータの変更方法を示します。

*.LOG_ARCHIVE_DEST_2='service=SALES_BOSTON lgwr syncaffirm net_timeout=30 valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON'

*.LOG_ARCHIVE_DEST_2='service=SALES_CHICAGO lgwr sync affirm net_timeout=30 valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_CHICAGO'

適用なし

*.LOG_ARCHIVE_DEST_3='service=SALES_BOSTON_LOG lgwr sync affirm net_timeout=30 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_BOSTON_LOG'

*.LOG_ARCHIVE_DEST_3='service=SALES_BOSTON_LOG lgwr sync affirm net_timeout=30 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_BOSTON_LOG'

*.LOG_ARCHIVE_DEST_3 ='service=SALES_CHICAGO lgwr sync affirm net_timeout=30 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_CHICAGO'

*.LOG_ARCHIVE_DEST_4='location=+RECO/SALES_CHICAGO/archivelog/SRL/ arch mandatory valid_for=(STANDBY_LOGFILES,STAMDBY_ROLE) db_unique_name=SALES_CHICAGO'

*.LOG_ARCHIVE_DEST_4='location=+RECO/SALES_BOSTON/archivelog/SRL/ arch mandatory valid_for=(STANDBY_LOGFILES,STANDBY_ROLE) db_unique_name=SALES_BOSTON'

*.LOG_ARCHIVE_DEST_4='location=+RECO/SALES_BOSTON_LOG/archivelog/SRL/ arch mandatory valid_for=(STANDBY_LOGFILES,STANDBY_ROLES) db_unique_name=SALES_BOSTON_LOG'

*.PARALLEL_MAX_SERVERS=9 Chicago と同じ Chicago と同じ

表表表表 A-9 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの Data Guard 用用用用 SPFILE パラパラパラパラメータメータメータメータ : 最大パフォーマンス・モード最大パフォーマンス・モード最大パフォーマンス・モード最大パフォーマンス・モード


*.LOG_ARCHIVE_DEST_2='service=SALES_BOSTON lgwr async net_timeout=30 valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON'

*.LOG_ARCHIVE_DEST_2='service=SALES_CHICAGO lgwr async net_timeout=30 valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_CHICAGO'

適用なし

*.LOG_ARCHIVE_DEST_3='service=SALES_BOSTON_LOG lgwr async net_timeout=30 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_BOSTON_LOG'

*.LOG_ARCHIVE_DEST_3='service=SALES_BOSTON_LOG lgwr async net_timeout=30 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_BOSTON_LOG'

*.LOG_ARCHIVE_DEST_3='service=SALES_CHICAGO lgwr async net_timeout=30 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_CHICAGO'

表表表表 A-8 プライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースのプライマリ、フィジカル・スタンバイおよびロジカル・スタンバイ・データベースの Data Guard 用用用用 SPFILEパラメータパラメータパラメータパラメータ : 最大可用性モードまたは最大保護モード（続き）最大可用性モードまたは最大保護モード（続き）最大可用性モードまたは最大保護モード（続き）最大可用性モードまたは最大保護モード（続き）



Oracle Net 構成ファイル

A.2 Oracle Net 構成ファイル構成ファイル構成ファイル構成ファイルこの項には、次の Oracle Net 構成ファイルの設定例が含まれます。

� 動的インスタンス登録を使用するすべてのホストに対応する SQLNET.ORA の例

� 動的インスタンス登録を使用するすべてのホストに対応する LISTENER.ORA の例

� 動的インスタンス登録を使用するすべてのホストに対応する TNSNAMES.ORA の例

A.2.1 動的インスタンス登録を使用するすべてのホストに対応する動的インスタンス登録を使用するすべてのホストに対応する動的インスタンス登録を使用するすべてのホストに対応する動的インスタンス登録を使用するすべてのホストに対応するSQLNET.ORA の例の例の例の例

# Set dead connection time SQLNET.EXPIRE_TIME = 1 # Disable Nagle's algorithmTCP.NODELAY=yes# Set default SDU for all connections DEFAULT_SDU_SIZE=32767

A.2.2 動的インスタンス登録を使用するすべてのホストに対応する動的インスタンス登録を使用するすべてのホストに対応する動的インスタンス登録を使用するすべてのホストに対応する動的インスタンス登録を使用するすべてのホストに対応するLISTENER.ORA の例の例の例の例

RAC 環境の場合、リスナーは、ローカル・ホスト名ではなく仮想 IP アドレス（VIP）でリスニングする必要があります。

lsnr_SALES = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=<local_host_name>)(PORT=1513) (QUEUESIZE=1024)))))PASSWORDS_lsnr_SALES = 876EAE4513718ED9 # Prevent listener administration ADMIN_RESTRICTIONS_lsnr_SALES=ON

関連資料関連資料関連資料関連資料 : OTN Web サイトの『Oracle Database 10g Release 2 Best Practices: Data Guard Redo Apply and Media Recovery』


このホワイト・ペーパーには、帯域幅遅延積を計算する手順が含まれます。

関連資料関連資料関連資料関連資料 : リスナー・パスワード保護の詳細は、『Oracle Database Net Services 管理者ガイド』を参照してください。


Oracle Net 構成ファイル

A.2.3 動的インスタンス登録を使用するすべてのホストに対応する動的インスタンス登録を使用するすべてのホストに対応する動的インスタンス登録を使用するすべてのホストに対応する動的インスタンス登録を使用するすべてのホストに対応するTNSNAMES.ORA の例の例の例の例

# Used for database parameter local_listener SALES_lsnr = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(PORT=1513))) SALES_remotelsnr_CHICAGO = (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=<chicago_host1>)) (ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=<chicago_host2>))) SALES_remotelsnr_BOSTON = (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=<boston_host1>)) (ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=<boston_host2>))) # Net service used for communication with SALES database in Chicago SALES_CHICAGO = (DESCRIPTION= (ADDRESS_LIST= (SEND_BUF_SIZE=4665000)(RECV_BUF_SIZE=4665000) (ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=<chicago_host1>)) (ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=<chicago_host2>))) (CONNECT_DATA=(SERVICE_NAME=SALES_CHICAGO))) # Net service used for communication with SALES database in Boston SALES_BOSTON = (DESCRIPTION= (ADDRESS_LIST= (SEND_BUF_SIZE=4665000)(RECV_BUF_SIZE=4665000) (ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=<boston_host1>)) (ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=<boston_host2>))) (CONNECT_DATA=(SERVICE_NAME=SALES_BOSTON))) # Net service used for communication with Logical Standby SALES database in Boston SALES_BOSTON_LOG = (DESCRIPTION= (ADDRESS_LIST= (SEND_BUF_SIZE=4665000)(RECV_BUF_SIZE=4665000) (ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=<boston_host1>)) (ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=<boston_host2>))) (CONNECT_DATA=(SERVICE_NAME=SALES_BOSTON_LOG)))


用語集用語集用語集用語集

MAA 環境環境環境環境（（（（MAA environment））））

RAC を使用した Oracle Database 10g と Data Guard を使用した Oracle Database 10g の両方の機能とメリットが継承されるため、計画外および計画済の停止に対しても包括的なソリューション・セットが提供されるアーキテクチャ。

MAA 環境は、RAC 本番データベースの存在する 1 つのサイトと、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの両方（または少なくともその一方）をホストするクラスタの存在するもう 1 つのサイトで構成される。

目標リカバリ時間目標リカバリ時間目標リカバリ時間目標リカバリ時間（（（（recovery time objective: RTO））））

組織に重大な物理的損失を発生させずに IT ベースのビジネス・プロセスを停止できる大時間。 RTO は、一般的に、ビジネス・プロセスまたは組織の許容停止時間に相当する。

目標リカバリ時点目標リカバリ時点目標リカバリ時点目標リカバリ時点（（（（recovery point objective: RPO））））

組織に問題を発生させずに IT ベースのビジネス・プロセスで失うことのできる大データ量。 RPO は、一般的に、ビジネス・プロセスまたは組織の許容データ損失量に相当する。このデータ損失は、通常、時間を基準として測定される（5 時間または 2 日分のデータ損失など）。

論理ユニット番号論理ユニット番号論理ユニット番号論理ユニット番号（（（（logical unit numbers: LUN））））

同じ SCSI ID で大 8 つのデバイス（論理ユニット）を区別するために SCSI バスで使用される3 ビットの識別子。

用語集用語集用語集用語集 -1

用語集用語集用語集用語集 -2

索引索引索引索引

AALTER SESSION ENABLE RESUMABLE 文，2-16ANALYZE TABLE tablename VALIDATE STRUCTURE

CASCADE，2-12ARCHIVELOG モード，2-9ASM「自動ストレージ管理（ASM）」を参照

asm_diskstring パラメータ，2-6ASMLib，2-3AWR「自動ワークロード・リポジトリ（AWR）」を参照

CCluster Ready Services（CRS）

サービス可用性のリカバリ，4-48説明，4-48

CREATE DISKGROUP 文

例，2-3，2-6CRS「Cluster Ready Services（CRS）」を参照

CRSD プロセス

OCR のバックアップ，2-20

DData Guard

RAC プライマリへの追加，5-3REDO 転送サービス，2-31，2-35アーカイブ計画，2-29監視，3-10スイッチオーバー

Enterprise Manager の使用，4-23SQL*Plus の使用，4-25 ～ 4-26ベスト・プラクティス，2-40

スタンバイ・タイプの選択，2-23スタンバイ・データベースのリストア，4-53ターゲットの管理，3-11データ破損およびデータ障害からのリカバリ，4-38パフォーマンス，2-46フィジカル・スタンバイ・データベースのクローン，

2-44フェイルオーバー

Enterprise Manager の使用，4-18SQL*Plus の使用，4-21実行する場合，4-17

データ領域ディスク・グループ障害のリカバリ，4-32

ベスト・プラクティス（手動），2-43ベスト・プラクティス（ファスト・スタート），

2-42ブローカ，2-28ロール移行，2-39，2-44ログ適用サービス，2-35，2-39

Data PumpSYSTEM 表領域の内容の移動，4-70

DB_BLOCK_CHECKING 初期化パラメータ，2-12DB_BLOCK_CHECKSUM 初期化パラメータ，2-9DB_CACHE_SIZE 初期化パラメータ，2-36DB_CREATE_FILE_DEST 初期化パラメータ

Oracle Managed Files（OMF）の有効化，2-4DB_FLASHBACK_RETENTION_TARGET 初期化パラ

メータ，2-11DB_KEEP_CACHE_SIZE 初期化パラメータ，2-36DB_RECOVERY_FILE_DEST_SIZE 初期化パラメータ

Oracle Managed Files（OMF）の有効化，2-4フラッシュ・リカバリ領域の制限，2-11

DB_RECOVERY_FILE_DEST 初期化パラメータOracle Managed Files（OMF）の有効化，2-4フラッシュ・リカバリ領域，2-11

DB_RECYCLE_CACHE_SIZE 初期化パラメータ，2-36DBCA

クライアント接続の分散，2-19DBMS_FILE_TRANSFER パッケージ，4-62DBMS_REDEFINITION PL/SQL パッケージ，4-73DBVERIFY ユーティリティ，2-12DEFAULT TEMPORARY TABLESPACE 句

CREATE DATABASE 文，2-16DISK_ASYNCH_IO 初期化パラメータ，2-13，2-37DNS フェイルオーバー，4-15

EEnterprise Manager

Data Guard スイッチオーバー，4-23Data Guard フェイルオーバー，4-18アラート，3-3通知ルール，3-4，3-9データベース・ターゲットのページ，3-8パッチの管理，3-11パフォーマンス，3-8メトリック，3-3，3-9

EXTERNAL REDUNDANCY 句

CREATE DISKGROUP 文，2-6

索引索引索引索引 -1

FFAST_START_MTTR_TARGET 初期化パラメータ，

2-13，2-38インスタンス・リカバリ時間の制御，2-12

flashback free buffer waits 待機イベント，2-11FORCE LOGGING モード，2-27

GGrid Control「Oracle Grid Control」および「Enterprise Manager」

を参照GV$SYSSTAT ビュー

ワークロード統計の収集，2-2

HHARD「Hardware Assisted Resilient Data（HARD）」を参

照Hardware Assisted Resilient Data（HARD）

ASM の使用時，2-8データ破損 , 防止，2-7，4-5

HR サービス使用例，4-48

II/O 操作

チューニング，2-37ロード・バランシング，2-6

I/O 帯域幅

フラッシュ・リカバリ領域，2-11

LLISTENER.ORA ファイルのサンプル，A-7LOAD_BALANCE パラメータ

クライアント接続の分散，2-19LOG_ARCHIVE_FORMAT 初期化パラメータ，2-29LOG_ARCHIVE_LOCAL_FIRST 初期化パラメータ，

2-29LOG_BUFFER 初期化パラメータ，2-13LUN「論理ユニット番号（LUN）」も参照「論理ユニット番号（LUN）」を参照，2-6

MMAA「Oracle Maximum Availability Architecture

（MAA）」を参照

NNetwork Attached Storage（NAS），2-37NORMAL REDUNDANCY 句

CREATE DISKGROUP 文，2-6

OOCR

説明，2-19バックアップ，2-20リカバリ，4-27

ocrconfig -export コマンド，2-20OMF「Oracle Managed Files（OMF）」を参照

opatch コマンドライン・ユーティリティ，4-63ORA-1578 エラー，2-9ORA-16625 エラー，4-18Oracle Cluster Registry（OCR）「OCR」を参照

Oracle Data Pumpプラットフォーム移行，4-69

Oracle Database 10gRAC 構成の推奨事項，2-17構成の推奨事項，2-8

Data Guard，2-21Oracle Grid Control

Data Guard ターゲットの管理，3-11ホームページ，3-3ポリシー違反，3-10メリット，1-3

Oracle Managed Files（OMF）ディスクおよびディスク・グループの構成，2-4データベース・ファイルの管理，2-4フラッシュ・リカバリ領域，2-11

Oracle Maximum Availability Architecture（MAA）Web サイト，1-3環境，5-2説明，1-3定義，用語集- 1

Oracle Net構成ファイルの例，A-7 ～ A-8

Oracle ORADEBUG ユーティリティ

インターコネクト・サブネットの確認，2-20Oracle Resilient Low-Cost Storage Initiative，2-2Oracle Secure Backup

OCR のバックアップ，2-20Oracle Streams

アップグレード，4-66オンライン・データベース・アップグレード，4-72データベース移行，4-69

Oracle Universal Installer，4-64Oracle 管理エージェント，3-2Oracle クラスタウェア

OCR のミラー化，2-19システム・メンテナンス，4-76説明，2-18

PPARALLEL_EXECUTION_MESSAGE_SIZE 初期化パラ

メータ，2-36設定，2-13

PARALLEL_MIN_SERVERS 初期化パラメータチューニング，2-13


RRAC

Data Guard の追加，5-3アプリケーション・フェイルオーバー，4-27クライアント・フェイルオーバー，2-58計画外の停止からのリカバリ，4-26構成，2-17システム・メンテナンス，4-76障害ノードまたはインスタンスのリストア，4-47単一インスタンスからの移行，5-2投票ディスク，2-19ネットワーク検出およびフェイルオーバー，2-20ローリング・アップグレード，4-63ローリング・パッチ・アップグレード，4-64

RAC 環境

LISTENER.ORA ファイルのサンプル，A-7SQLNET.ORA ファイルのサンプル，A-7TNSNAMES.ORA ファイルのサンプル，A-8ノードへのディスクの追加，2-3

RAID，2-6論理ユニット番号（LUN），2-6

RAID に基づくストレージ・アレイ，2-6RAID 保護，2-6RECOVERY_ESTIMATED_IOS 初期化パラメータ

パラレル・リカバリ，2-13RECOVERY_PARALLELISM 初期化パラメータ，2-13REDO 転送サービス

ベスト・プラクティス，2-31 ～ 2-35REDO ログ・ファイルおよびグループ

サイズ，2-10チェックサム，2-9

REMOTE_ARCHIVE_ENABLE 初期化パラメータ，2-29RESUMABLE_TIMEOUT 初期化パラメータ，2-16RMAN

チェックサムの計算，2-9RMAN BACKUP VALIDATE コマンド，4-38RMAN BACKUP コマンド

VALIDATE オプション，2-12RMAN BLOCKRECOVER コマンド，4-38RMAN データファイル・メディア・リカバリ，4-39RMAN ブロック・メディア・リカバリ，4-38RPO「目標リカバリ時点（RPO）」を参照

RTO「目標リカバリ時間（RTO）」を参照

SSALES の使用例

初期化パラメータの設定，2-30SAME「全ディスクのストライプ化とミラー化（SAME）」を

参照

SGA_TARGET 初期化パラメータ，2-13SLA「品質保証契約（SLA）」を参照

SPFILEサンプル，A-2 ～ A-6

SQLNET.ORA ファイルのサンプル，A-7SQL アクセス・アドバイザ，2-14SQL チューニング・アドバイザ，2-14STANDBY_ARCHIVE_DEST 初期化パラメータ，2-30

Storage Area Network（SAN），2-37SYSTEM 表領域

内容の移動，4-70

TTCP Nagle アルゴリズム

無効化，2-35TNSNAMES.ORA ファイルのサンプル，A-8

UUNDO_MANAGEMENT 初期化パラメータ

自動 UNDO 管理，2-15UNDO_RETENTION 初期化パラメータ

自動 UNDO 管理，2-15UNDO_TABLESPACE 初期化パラメータ

自動 UNDO 管理，2-15UNDO 保存期間

チューニング，2-15UNDO 領域

管理，2-15USABLE_FILE_MB 列

V$ASM_DISKGROUP ビュー，2-7

VV$ASM_DISKGROUP

REQUIRED_MIRROR_FREE_MB 列，2-7V$ASM_DISKGROUP ビュー

REQUIRED_MIRROR_FREE_MB 列，2-7USABLE_FILE_MB 列，2-7

V$ASM_DISK ビュー，2-37V$ASM_OPERATION ビュー

リバランス操作の監視，4-62V$EVENT_HISTOGRAM ビュー，2-36V$INSTANCE_RECOVERY ビュー

リカバリ・プロセスのチューニング，2-13V$OSSTAT ビュー，2-37V$SESSION_WAITS ビュー，2-36V$SYSTEM_EVENTS ビュー，2-36V$SYSTEM_EVENT ビュー，2-37VALID_FOR 属性，2-30VALIDATE オプション

RMAN BACKUP コマンド，2-12VIP アドレス

アプリケーションへの接続，2-18説明，2-18リカバリ時，4-48ワークロード管理，2-18

WWeb サイト

ASMLib，2-3MAA，1-3

ああああアーカイブ計画，2-29アーキテクチャ

高可用性，1-2


アップグレードアプリケーション，4-71データベース・アップグレード・アシスタント

（DBUA），4-65ベスト・プラクティス，4-63

アプリケーションOracle クラスタウェアでの管理，2-18アップグレード，4-71高速フェイルオーバー，2-57，2-58サービス低下，3-8サービスとして定義，2-18データ型のサポート，2-24ビーコンでのパフォーマンスの追跡，3-4フェイルオーバー，4-27

アプリケーション・サービスの負荷分散，4-49アラート

Enterprise Manager，3-3

いいいい移行

ASM 環境とデータベース，2-3MAA，5-1RAC プライマリへの Data Guard 構成の追加，5-3単一インスタンスから RAC へ，5-2トランスポータブル・データベース，4-68

一時表領域，2-16インスタンス障害

単一，4-26リカバリ，2-12

インスタンス・リカバリ制限，2-13パラレル実行，2-13ファスト・スタート・リカバリを使用した制御，2-12

インターコネクト・サブネット

Oracle ORADEBUG ユーティリティでの確認，2-20

うううう運用ベスト・プラクティス，1-3 ～ 1-4

ええええエンディアン形式

確認，4-68エンドツーエンドのブロック検証，2-7

おおおおオブジェクトのオンライン再編成，4-73オンライン REDO ログ・ファイル

多重化，2-10オンライン再編成および再定義，4-73オンライン・ログ・グループ

小数，2-10

かかかか仮想インターネット・プロトコル（VIP）・アドレス「VIP アドレス」も参照

仮想インターネット・プロトコル・コンフィギュレーション・アシスタント（VIPCA）

VIP アドレスの構成，2-18

監視Oracle Grid Control，1-3リバランス操作，4-62

完全サイト・フェイルオーバー目標リカバリ時間（RTO），4-12

管理性向上，2-14 ～ 2-17

きききき行およびトランザクションの非一貫性，4-42距離

障害時リカバリ・サイトとプライマリ・サイトの間，

2-26

くくくくクライアント

アプリケーション・フェイルオーバー，4-27フェイルオーバーの構成，2-58ロード・バランシング，2-19

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

ベスト・プラクティス，2-58クラスタ

管理，2-18クラスタ全体の停止

スタンバイ・データベースのリストア，4-56クラッシュ・リカバリ

制限，2-13

けけけけ計画外の停止

RAC リカバリ，4-26説明，4-2 ～ 4-6タイプ，4-2リカバリ，4-3，4-11 ～ 4-46

「計画済の停止」も参照計画外の停止のリカバリ手順，4-3計画済の停止

説明，4-7 ～ 4-11タイプ，4-7停止時間の短縮，4-61 ～ 4-76リカバリ，4-8，4-11

「計画外の停止」も参照

計画済の停止のリカバリ手順，4-8 ～ 4-11検証

RMAN バックアップ時のチェックサム，2-9エンドツーエンドのブロック検証テクノロジ，2-7

ここここ高可用性

説明，1-2ファスト・スタート・フェイルオーバー後のリスト

ア，4-53要件，2-9 ～ 2-13

構成

RAC，2-17高速アプリケーション通知（FAN），4-27高速アプリケーション・フェイルオーバー，2-57 ～ 2-58個別パッチ・アップグレード，4-63


ささささサーバー・パラメータ・ファイル

「SPFILE」を参照サービス

RAC アプリケーション・フェイルオーバー，4-27RAC アプリケーション・ワークロード，2-18管理用ツール，2-18

サービス可用性

リカバリ，4-48サービス・テストとビーコン

構成，3-4再開可能領域割当て，2-16

領域割当て

障害，2-16大可用性モード

REDO 転送の要件，2-31使用する場合，2-25説明，2-25大パフォーマンス・モード

REDO 転送の要件，2-31使用する場合，2-25説明，2-25大保護モード

使用する場合，2-25初期化パラメータの例，2-30説明，2-25

サイト・フェイルオーバーネットワーク・ルート，4-14

索引の再構築，4-73索引ブロック，2-12削除された表領域

フラッシュバック・データベースの使用，4-45

ししししシステム障害

リカバリ，2-12システム・メンテナンス，4-76システム・リソース

評価，2-37自動 UNDO 管理

説明，2-15自動共有メモリー管理，2-13自動ストレージ管理（ASM）

asm_diskstring パラメータ，2-6ASMLib，2-3HARD 準拠ストレージ，2-8冗長性，2-6ディスク・グループのサイズ，2-7ディスク・デバイス割当て，2-4ディスクのマルチパス・ソフトウェア，2-6データベースの移行，2-3，4-62データベース・ファイルの管理，2-3リカバリ，4-28

自動セグメント領域管理，2-16使用，2-16

自動データベース診断モニター（ADDM），2-14自動パフォーマンス・チューニング，2-14自動ワークロード・リポジトリ（AWR），2-14

パフォーマンス要件の評価，2-2ベスト・プラクティス，2-14

手動フェイルオーバー実行する場合，4-17ベスト・プラクティス，2-43，4-21

障害領域割当て，2-16

障害グループ定義，2-6

障害時リカバリ・サイトプライマリ・サイトからの距離，2-26

冗長性CREATE DISKGROUP DATA 文，2-6ディスク障害後の回復，2-7ディスク・デバイス，2-6

使用例ASM ディスク障害と修復，4-30Data Guard スイッチオーバー，4-23Data Guard フェイルオーバー，4-18HR サービス，4-48SALES，2-30インターコネクト・サブネットの確認，2-20オブジェクトの再編成，4-74人為的エラーからのリカバリ，4-42ファスト・スタート・フェイルオーバー，4-54

初期化パラメータ

プライマリとフィジカル・スタンバイの例，2-30人為的エラー

フラッシュバック・データベースでの修正，2-11リカバリ，4-39

すすすす推奨事項

データベース構成，2-8スイッチオーバー「Data Guard」も参照

Enterprise Manager，4-23説明，4-22フィジカル・スタンバイ・データベース，4-25ロジカル・スタンバイ・データベース，4-25

スタンバイ REDO ログ・ファイル（SRL）数の決定，2-31

スタンバイ・データベースデータ型のサポート，2-24フィジカルまたはロジカルの選択，2-24プライマリ・サイトからの距離，2-26リストア，4-53ロジカルとフィジカルの比較，2-22

ストレージ・アレイ

ミラー化，2-7ストレージ・サブシステム，2-2 ～ 2-8

ASM の構成，2-3冗長性の構成，2-6パフォーマンス要件，2-2

せせせせセカンダリ・サイトの停止

スタンバイ・データベースのリストア，4-56セキュリティ

推奨事項，1-3接続時フェイルオーバー，4-49セマンティクス・ブロック・チェック，2-12全ディスクのストライプ化とミラー化（SAME），2-3


そそそそソート操作

向上，2-16

たたたた待機イベント

flashback free buffer waits，2-11

ちちちちチェックサム，2-9

つつつつ通知ルール

監視に対する SLA の影響，3-4推奨，3-9

てててて低下，3-8低コストのストレージ・サブシステム，2-2停止

計画外，4-2計画外および計画済の停止の管理，4-1計画済，4-7タイプ，4-2

停止時間

短縮，1-3ディスク・グループ

サイズの決定，2-7適切なサイズの決定，2-7

ディスク・グループの構成，2-3ディスク障害

冗長性の回復，2-7保護，2-6

ディスク・デバイス

ASM でのパーティション化，2-4構成，2-3，2-6障害からの保護，2-6名前

asm_diskstring パラメータ，2-6ASMLib，2-3

マルチパス，2-6ディスクのマルチパス，2-6データ

データベース以外の保護，2-45破損からの保護，2-7

データ型スタンバイ・データベースによるサポート，2-24

データ障害RMAN データファイル・メディア・リカバリ，4-39RMAN ブロック・メディア・リカバリ，4-38手動による再作成，4-39スタンバイ・データベースのフォルト・トレランスの

リストア，4-57リカバリ，4-36，4-38

データ破損Data Guard でのリカバリ，4-38HARD 保護，2-7，4-5

データファイル・ブロック破損リカバリ，4-36

データベース

アップグレード方法，4-65

移行，4-68オブジェクトの再編成，4-73

大 RAC インスタンスの構成，2-21パフォーマンス要件の評価，2-2非一貫性の解決，4-44プライマリ・ロールとスタンバイ・ロールの切替え，

4-22データベース・アップグレード・アシスタント

（DBUA），4-65データベース以外のオブジェクトの破損と推奨される修

復方法，4-37データベース・オブジェクトの削除，4-41データベース構成

推奨事項，2-8データベース・パッチ・アップグレード

推奨事項，4-63データベース・ファイル

ASM 統合，2-3管理の適化，2-3リカバリ関連，2-3

データベース・ブロック・チェック，2-12データベース・リソース・マネージャ，2-17データベース領域

ディスクのパーティション化，2-4内容，2-3

データ保護モード，2-25 ～ 2-26データ領域ディスク・グループ障害「Data Guard フェイルオーバー」、「ファスト・スター

ト・フェイルオーバー」、「ローカル・リカバリ」も参照

リカバリ・オプション，4-32テスト環境

運用ベスト・プラクティス，1-3デバイス・マッパー

ディスクのマルチパス，2-6

とととと等式

PARALLEL_MIN_SERVERS の設定，2-13スタンバイ REDO ログ・ファイル，2-31

動的インスタンス登録LISTENER.ORA ファイルの例，A-7SQLNET.ORA ファイルの例，A-7TNSNAMES.ORA ファイルの例，A-8

投票ディスク（RAC）ベスト・プラクティス，2-19

トランスポータブル・データベース，4-68トランスポータブル表領域

データベース・アップグレード，4-67プラットフォーム移行，4-70

にににに二重障害

リストア，4-61


ねねねねネットワーク検出およびフェイルオーバー

CRS と RAC，2-20ネットワーク・ルート

サイト・フェイルオーバー後，4-14サイト・フェイルオーバー前，4-12

ののののノード障害

複数，4-26ノード・リカバリ

制限，2-13

ははははパーティション

ASM で使用するためのディスクの割当て，2-4パス障害

保護，2-6破損

REDO レコードの検出，2-9検出，2-9メモリーおよびデータの保護，2-12メモリー内での検出，2-9リカバリ，4-36

バックアップ

OCR，2-20構成，2-48 ～ 2-56

バックアップとリカバリ

ARCHIVELOG モードでの有効化，2-9推奨事項，2-48チェックサムの計算，2-9ベスト・プラクティス，2-48，2-56

パッチEnterprise Manager での管理，3-11

パッチ・セットローリング・アップグレード，4-63

パフォーマンスData Guard，2-46アプリケーション , ビーコンでの追跡，3-4自動チューニング，2-14チェックサム有効時のオーバーヘッド，2-9データベース , 要件の収集，2-2非同期ディスク I/O，2-13

パラレル実行 , 高速化，2-13パラレル・リカバリ

無効化，2-13パラレル・リカバリの無効化，2-13

ひひひひビーコン，3-4

構成，3-4非索引構成表ブロック，2-12

チェック，2-12非同期ディスク I/O，2-13表の非一貫性，4-41表領域

一時，2-16名前変更，4-73，4-74ローカル管理，2-16

品質保証契約（SLA），1-3運用ベスト・プラクティス，1-3監視と通知に対する影響，3-4

ふふふふファスト・スタート・リカバリ

インスタンス・リカバリ，2-12フィジカル・スタンバイ・データベース

クローンとしての使用，2-44スイッチオーバー，4-25フェイルオーバー，4-21メリット，2-22ロケーション移行，4-70

プール

サイズ変更，2-13フェイルオーバー

Enterprise Manager，4-18アプリケーション，4-27完全サイト，4-12高速アプリケーション，2-57，2-58スタンバイ・データベースのリストア，4-53説明，4-17定義，4-16ネットワーク・ルートへの影響，4-12無停止，2-6

フェイルオーバー（手動）実行する場合，4-17ベスト・プラクティス，2-43

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

以前のプライマリ・データベースの復元，4-53ベスト・プラクティス，2-42

フォルト・トレランス

OPEN RESETLOGS 後のリストア，4-58ストレージ・サブシステムの構成，2-2リストア，4-46 ～ 4-61

復元，4-53プライマリ・データベース

障害時リカバリ・サイトからの距離，2-26ファスト・スタート・フェイルオーバー後の復元，

4-53フォルト・トレランスのリストア，4-58

フラッシュバック・データベース，4-40，4-44Data Guard 構成，2-27

大メモリーの設定，2-13人為的エラーの修正，2-11有効化，2-11

フラッシュバック・テクノロジ

ソリューション，4-40データベース全体の非一貫性の解決，4-44ユーザー・エラーからのリカバリ，4-39例，4-42

フラッシュバック問合せ，4-40，4-42フラッシュバック・トランザクション問合せ，4-40，

4-42フラッシュバック・ドロップ，4-40，4-41フラッシュバック・バージョン問合せ，4-40，4-42フラッシュバック表，4-40，4-41フラッシュ・リカバリ領域

使用，2-11低コストのストレージ・グリッド，2-2ディスク・グループ障害，4-34ディスクのパーティション化，2-4


内容，2-3ローカル再起動の手順，4-35ローカル・リカバリの手順，4-35

プラットフォーム移行，4-65，4-67エンディアン形式，4-68

ブローカメリット，2-28

ブロック検証エンドツーエンド，2-7

ブロック・チェック破損の防止，2-12

ブロック・チェックサム，2-9ブロック・メディア・リカバリ，4-38

へへへへベスト・プラクティス，1-2

AWR，2-14Data Guard 構成，2-21 ～ 2-47RAC 構成，2-17，2-17 ～ 2-21アップグレード，4-63運用，1-3，1-4スイッチオーバー，2-40，4-23ストレージ・サブシステム，2-2セキュリティ・ポリシー，1-3バックアップとリカバリ，2-48，2-56フェイルオーバー（手動），2-43，4-17，4-21フェイルオーバー（ファスト・スタート），2-42，

4-17

ほほほほ保護モード

説明，2-25「データ保護モード」、「大保護モード」、「大可用

性モード」、「大パフォーマンス・モード」も参照

適切なモードの決定，2-25ホスト

動的インスタンス登録の使用LISTENER.ORA ファイルの例，A-7SQLNET.ORA ファイルの例，A-7TNSNAMES.ORA ファイルの例，A-8

ホスト・バス・アダプタ（HBA）ロード・バランシング，2-6

本番データベースでのリセットログ操作スタンバイ・データベースのリストア，4-58

ままままマルチパス（ディスク）

パスの抽象化，2-6

みみみみミラー化

ストレージ・アレイ，2-7

むむむむ無停止のフェイルオーバー，2-6

めめめめメディア障害

リカバリ，4-36メトリック

Enterprise Manager，3-3メモリー管理，2-13メモリー内破損

検出，2-9メモリー内ブロック変更のチェック，2-12メリット

Grid Control，1-3高可用性ベスト・プラクティス，1-2フィジカル・スタンバイ・データベース，2-22ロジカル・スタンバイ・データベース，2-23

もももも目標リカバリ時間（RTO）

説明，4-12定義，用語集- 1データ領域ディスク・グループ障害，4-32

目標リカバリ時点（RPO）定義，用語集- 1データ領域ディスク・グループ障害，4-32

ゆゆゆゆ有効化，2-12ユーザー・エラー

フラッシュバック・テクノロジ，4-39

ららららライブラリ

ASM での ASMLib サポート，2-3

りりりりリカバリ

制限，2-13リカバリ・ファイル

リカバリ領域の場所に作成されるファイル，2-11リストア

クライアント接続，4-48サービス，4-48障害インスタンス，4-47障害ノード，4-47

リスナーLISTENER.ORA ファイルの例，A-7SQLNET.ORA ファイルの例，A-7TNSNAMES.ORA ファイルの例，A-8クライアントの分散，2-19

リソース管理

データベース・リソース・マネージャの使用，2-17リバランス操作

ASM ディスク・パーティション，2-4，2-5監視，4-62

リモート・アーカイブ，2-29領域管理，2-16


ろろろろローカル・アーカイブの先行，2-29ローカル管理表領域，2-16

説明，2-16ローカル再起動の手順

フラッシュ・リカバリ領域の高速リカバリ，4-35ローカル・リカバリ

データ領域ディスク・グループ障害，4-33フラッシュ・リカバリ領域ディスク・グループ障害，

4-35ロード・バランシング

I/O 操作，2-6クライアント接続，2-19ディスクのマルチパスの使用，2-6

ローリング・アップグレード

パッチ・セット，4-63ロール移行

ベスト・プラクティス，2-39 ～ 2-44ロール・ベースの宛先，2-30ログ適用サービス

ベスト・プラクティス，2-35 ～ 2-39ロケーション移行，4-67ロジカル・スタンバイ・データベース

アップグレード，4-66スイッチオーバー，4-25フェイルオーバー，4-21メリット，2-23

論理ユニット番号（LUN），2-6定義，用語集- 1

わわわわワークロード

統計の収集，2-2例，2-2

ワークロード管理

VIP アドレスを通じた接続，2-18



Documents

Oracle Database高可用性ベスト・プラクティス, 10g」 …otndnld.oracle.co.jp/document/products/oracle10g/102/… · · 2009-07-02Nowak, Viv Schupmann, Michael Todd