Oracle高可用性アーキテクチャおよびベスト・プラクティス, 10...

Oracle®高可用性アーキテクチャおよびベスト・プラクティス

10g リリース 1（10.1）

部品番号部品番号部品番号部品番号 : B12464-02

2004 年７月

Oracle 高可用性アーキテクチャおよびベスト・プラクティス , 10g リリース 1（10.1）

部品番号 : B12464-02

原本名 : Oracle Database High Availability Architecture and Best Practices, 10g Release 1 (10.1)

原本部品番号 : B10726-02

原本著者 : Cathy Baird

原本協力者 : David Austin, Andrew Babb, Mark Bauer, Ruth Baylis, Tammy Bednar, Pradeep Bhat, Donna Cooksey, Ray Dutcher, Jackie Gosselin, Mike Hallas, Daniela Hansell, Wei Hu, Susan Kornberg, Jeff Levinger, Diana Lorentz, Roderick Manalac, Ashish Ray, Antonio Romero, Vivian Schupmann, Deborah Steiner, Ingrid Stuart, Bob Thome, Lawrence To, Paul Tsien, Douglas Utzig, Jim Viscusi, Shari Yamaguchi, Valarie Moore

Copyright © 2003, 2004 Oracle Corporation. All rights reserved.

制限付権利の説明

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

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

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

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

U.S. GOVERNMENT RIGHTS

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

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

Oracle は Oracle Corporation およびその関連会社の登録商標です。その他の名称は、Oracle Corporation または各社が所有する商標または登録商標です。

目次目次目次目次

はじめにはじめにはじめにはじめに ......................................................................................................................................................................... xiii

対象読者 ................................................................................................................................................................... xivこのドキュメントの構成 ....................................................................................................................................... xiv関連ドキュメント ................................................................................................................................................... xvi

表記規則 .................................................................................................................................................................. xvii

第第第第 I 部部部部スタート・ガイドスタート・ガイドスタート・ガイドスタート・ガイド

1 高可用性の概要高可用性の概要高可用性の概要高可用性の概要

高可用性の概要高可用性の概要高可用性の概要高可用性の概要 ....................................................................................................................................................... 1-2可用性の概要可用性の概要可用性の概要可用性の概要 ........................................................................................................................................................... 1-2

可用性の重要性可用性の重要性可用性の重要性可用性の重要性 ....................................................................................................................................................... 1-3停止時間の原因停止時間の原因停止時間の原因停止時間の原因 ....................................................................................................................................................... 1-4このマニュアルの内容このマニュアルの内容このマニュアルの内容このマニュアルの内容 ........................................................................................................................................... 1-4

対象読者対象読者対象読者対象読者 ................................................................................................................................................................... 1-5

2 高可用性要件の決定高可用性要件の決定高可用性要件の決定高可用性要件の決定

高可用性要件の決定の重要性高可用性要件の決定の重要性高可用性要件の決定の重要性高可用性要件の決定の重要性 ............................................................................................................................... 2-2

高可用性要件を決定するための分析フレームワーク高可用性要件を決定するための分析フレームワーク高可用性要件を決定するための分析フレームワーク高可用性要件を決定するための分析フレームワーク ....................................................................................... 2-3ビジネスへの影響の分析 ............................................................................................................................... 2-3

停止時間のコスト ........................................................................................................................................... 2-4

リカバリ時間目標 ........................................................................................................................................... 2-4

リカバリ・ポイント目標 ............................................................................................................................... 2-5

i

高可用性アーキテクチャの選択高可用性アーキテクチャの選択高可用性アーキテクチャの選択高可用性アーキテクチャの選択 ........................................................................................................................... 2-5

HA システムの機能 ....................................................................................................................................... 2-7

ビジネス・パフォーマンス、予算および成長の計画 ............................................................................... 2-8

高可用性のベスト・プラクティス ............................................................................................................... 2-9

第第第第 II 部　部　部　部　Oracle Database の高可用性機能、アーキテクチャおよびポリシーの高可用性機能、アーキテクチャおよびポリシーの高可用性機能、アーキテクチャおよびポリシーの高可用性機能、アーキテクチャおよびポリシー

3 Oracle Database の高可用性機能の高可用性機能の高可用性機能の高可用性機能

Oracle Real Application Clusters ....................................................................................................................... 3-2Oracle Data Guard ................................................................................................................................................ 3-2Oracle Streams ....................................................................................................................................................... 3-4

オンライン再編成オンライン再編成オンライン再編成オンライン再編成 ................................................................................................................................................... 3-5トランスポータブル表領域トランスポータブル表領域トランスポータブル表領域トランスポータブル表領域 ................................................................................................................................... 3-6Automatic Storage Management ........................................................................................................................ 3-7

フラッシュバック・テクノロジフラッシュバック・テクノロジフラッシュバック・テクノロジフラッシュバック・テクノロジ ........................................................................................................................... 3-8Oracle Flashback Query ................................................................................................................................ 3-8Oracle Flashback Version Query .................................................................................................................. 3-8

Oracle Flashback Transaction Query .......................................................................................................... 3-9Oracle Flashback Table .................................................................................................................................. 3-9Oracle Flashback Drop .................................................................................................................................. 3-9

Oracle Flashback Database ........................................................................................................................... 3-9

動的再構成動的再構成動的再構成動的再構成 ............................................................................................................................................................. 3-10Oracle Fail Safe .................................................................................................................................................... 3-10

Recovery Manager ............................................................................................................................................... 3-11フラッシュ・リカバリ領域フラッシュ・リカバリ領域フラッシュ・リカバリ領域フラッシュ・リカバリ領域 ................................................................................................................................. 3-12Hardware Assisted Resilient Data（（（（HARD））））Initiative ............................................................................. 3-13

4 高可用性アーキテクチャ高可用性アーキテクチャ高可用性アーキテクチャ高可用性アーキテクチャ

Oracle Database の高可用性アーキテクチャの高可用性アーキテクチャの高可用性アーキテクチャの高可用性アーキテクチャ .................................................................................................... 4-2データベースのみのアーキテクチャ ........................................................................................................... 4-4

RAC のみのアーキテクチャ ......................................................................................................................... 4-6

Data Guard のみのアーキテクチャ ............................................................................................................. 4-8Maximum Availability Architecture ......................................................................................................... 4-10

Streams アーキテクチャ .............................................................................................................................. 4-12

適切な適切な適切な適切な HA アーキテクチャの選択アーキテクチャの選択アーキテクチャの選択アーキテクチャの選択 .................................................................................................................... 4-14その他のアーキテクチャの評価その他のアーキテクチャの評価その他のアーキテクチャの評価その他のアーキテクチャの評価 ......................................................................................................................... 4-17

ii

5 高可用性の操作ポリシー高可用性の操作ポリシー高可用性の操作ポリシー高可用性の操作ポリシー

高可用性の操作ポリシーの概要高可用性の操作ポリシーの概要高可用性の操作ポリシーの概要高可用性の操作ポリシーの概要 ........................................................................................................................... 5-2高可用性のサービス・レベル管理高可用性のサービス・レベル管理高可用性のサービス・レベル管理高可用性のサービス・レベル管理 ....................................................................................................................... 5-3

高可用性を促進する容量計画高可用性を促進する容量計画高可用性を促進する容量計画高可用性を促進する容量計画 ............................................................................................................................... 5-4高可用性の変更管理高可用性の変更管理高可用性の変更管理高可用性の変更管理 ............................................................................................................................................... 5-5高可用性のバックアップおよびリカバリ計画高可用性のバックアップおよびリカバリ計画高可用性のバックアップおよびリカバリ計画高可用性のバックアップおよびリカバリ計画 ................................................................................................... 5-8障害時リカバリ計画障害時リカバリ計画障害時リカバリ計画障害時リカバリ計画 ............................................................................................................................................... 5-9

計画的停止の計画計画的停止の計画計画的停止の計画計画的停止の計画 ................................................................................................................................................. 5-11高可用性のスタッフ研修高可用性のスタッフ研修高可用性のスタッフ研修高可用性のスタッフ研修 ..................................................................................................................................... 5-12高可用性保持の手段としてのドキュメント高可用性保持の手段としてのドキュメント高可用性保持の手段としてのドキュメント高可用性保持の手段としてのドキュメント ..................................................................................................... 5-13

高可用性のための物理的なセキュリティ・ポリシーおよび手順高可用性のための物理的なセキュリティ・ポリシーおよび手順高可用性のための物理的なセキュリティ・ポリシーおよび手順高可用性のための物理的なセキュリティ・ポリシーおよび手順 ................................................................. 5-14

第第第第 III 部部部部高可用性を備えた高可用性を備えた高可用性を備えた高可用性を備えた Oracle 環境の構成環境の構成環境の構成環境の構成

6 システム構成およびネットワーク構成システム構成およびネットワーク構成システム構成およびネットワーク構成システム構成およびネットワーク構成

システム構成に関する推奨事項の概要システム構成に関する推奨事項の概要システム構成に関する推奨事項の概要システム構成に関する推奨事項の概要 ............................................................................................................... 6-2

ストレージの構成に関する推奨事項ストレージの構成に関する推奨事項ストレージの構成に関する推奨事項ストレージの構成に関する推奨事項 ................................................................................................................... 6-2全ハードウェア・コンポーネントにおける完全な冗長性およびフォルト・トレラントの確認 ....... 6-3

オンラインでサービス可能なアレイの使用 ............................................................................................... 6-3

保護とパフォーマンスのためのミラー化とストライプ化 ....................................................................... 6-4

すべての物理インタフェース間でのロード・バランス ........................................................................... 6-4

独立したストレージ領域の作成 ................................................................................................................... 6-5

特定 HA アーキテクチャに関するストレージの推奨事項 .............................................................. 6-6

ASM ディスクと障害グループの適切な定義 ............................................................................................. 6-7

データ破損に対する大保護のための HARD 準拠のストレージの使用 ............................................ 6-8

RAC に関するストレージの推奨事項 ......................................................................................................... 6-9

Oracle Cluster Registry および投票ディスク（ボーティング・ディスク）のメディア障害からの保護 ....................................................................................................................... 6-9

サーバー・ハードウェアの構成に関する推奨事項サーバー・ハードウェアの構成に関する推奨事項サーバー・ハードウェアの構成に関する推奨事項サーバー・ハードウェアの構成に関する推奨事項 ......................................................................................... 6-10

すべてのアーキテクチャに関するサーバー・ハードウェアの推奨事項 ............................................. 6-10

より少数、高速、稠密なコンポーネントの使用 ............................................................................. 6-10冗長ハードウェア・コンポーネントの使用 ..................................................................................... 6-10

障害を検出して分離するシステムの使用 ......................................................................................... 6-10バックアップ・コピーによるブート・ディスクの保護 ................................................................. 6-11

iii

RAC に関するサーバー・ハードウェアの推奨事項 ............................................................................... 6-11

サポートされているクラスタ・システムを使用した RAC の実行 .............................................. 6-11適切なクラスタ・インターコネクトの選択 ..................................................................................... 6-11

Data Guard に関するサーバー・ハードウェアの推奨事項 ................................................................... 6-12

両サイトでの全マシンに対する同一ハードウェアの使用 ............................................................. 6-12サーバー・ソフトウェアの構成に関する推奨事項サーバー・ソフトウェアの構成に関する推奨事項サーバー・ソフトウェアの構成に関する推奨事項サーバー・ソフトウェアの構成に関する推奨事項 ......................................................................................... 6-12

すべてのアーキテクチャに関するサーバー・ソフトウェアの推奨事項 ............................................. 6-12

同じ OS のバージョン、パッチ・レベル、単一パッチおよびドライバのバージョンの使用 ... 6-13

ハードウェア障害に対してフォルト・トレラントなオペレーティング・システムの使用 ..... 6-13適切なスワップ・パーティションの構成 ......................................................................................... 6-13今後の拡張を可能にするオペレーティング・システム・パラメータの設定 ............................. 6-13

ロギングまたはジャーナル・ファイル・システムの使用 ............................................................. 6-14Oracle ソフトウェアとアプリケーション・ソフトウェアを含むミラー・ディスク ................ 6-14

RAC に関するサーバー・ソフトウェアの推奨事項 ............................................................................... 6-14

サポートされているクラスタ化ソフトウェアの使用 ..................................................................... 6-14すべてのクラスタ・ノード上での Network Time Protocol（NTP）の使用 .............................. 6-14

ネットワークの構成に関する推奨事項ネットワークの構成に関する推奨事項ネットワークの構成に関する推奨事項ネットワークの構成に関する推奨事項 ............................................................................................................. 6-15すべてのアーキテクチャのネットワーク構成のベスト・プラクティス ............................................. 6-15

すべてのネットワーク・コンポーネントが冗長であることの確認 ............................................. 6-15ロード・バランサを使用した受信した要求の配信 ......................................................................... 6-17

RAC のネットワーク構成のベスト・プラクティス ............................................................................... 6-17

Oracle インタフェース構成ツールを使用したネットワーク・インタフェースの分類 ............ 6-17Data Guard のネットワーク構成のベスト・プラクティス ................................................................... 6-18

システム TCP パラメータの適切な構成 ........................................................................................... 6-18

サイト・フェイルオーバー機能を提供する WAN トラフィック・マネージャの使用 ............ 6-18

7 Oracle 構成のベスト・プラクティス構成のベスト・プラクティス構成のベスト・プラクティス構成のベスト・プラクティス

データベースに関する構成上のベスト・プラクティスデータベースに関する構成上のベスト・プラクティスデータベースに関する構成上のベスト・プラクティスデータベースに関する構成上のベスト・プラクティス ................................................................................... 7-22 つの制御ファイルの使用 ............................................................................................................................ 7-3

CONTROL_FILE_RECORD_KEEP_TIME の十分な日数の設定 ............................................................ 7-3

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

多重オンライン REDO ログ・ファイル ..................................................................................................... 7-4

ARCHIVELOG モードの有効化 .................................................................................................................. 7-4

ブロックのチェックサムの有効化 ............................................................................................................... 7-4

データベース・ブロックのチェックの有効化 ........................................................................................... 7-5

チェックポイントのアラート・ログへの記録 ........................................................................................... 7-5

iv

ファスト・スタート・チェックポイントを使用したインスタンス・リカバリ時間の制御 ............... 7-6

タイミングに関するパフォーマンス統計の取得 ....................................................................................... 7-7

自動 UNDO 管理の使用 ................................................................................................................................ 7-8

ローカル管理表領域の使用 ........................................................................................................................... 7-9

自動セグメント領域管理の使用 ................................................................................................................... 7-9

一時表領域の使用およびデフォルト一時表領域の指定 ........................................................................... 7-9

再開可能領域割当ての使用 ......................................................................................................................... 7-10

フラッシュ・リカバリ領域の使用 ............................................................................................................. 7-10

フラッシュバック・データベースの有効化 ............................................................................................. 7-11

セキュリティに関するベスト・プラクティスの設定 ............................................................................. 7-11

Database Resource Manager の使用 .......................................................................................................... 7-12

サーバー・パラメータ・ファイルの使用 ................................................................................................. 7-12

Real Application Clusters に関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティス ......................................................... 7-13リモート・リスナーを使用した全インスタンスの登録 ......................................................................... 7-13

スケーラビリティに必要ないかぎり CLUSTER_INTERCONNECTS を設定しない ........................ 7-13

Data Guard に関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティス .................................................................................. 7-14単純で堅牢なアーカイブ計画と構成の使用 ............................................................................................. 7-16

多重スタンバイ REDO ログの使用およびサイズの適切な構成 ........................................................... 7-19

FORCE LOGGING モードの有効化 .......................................................................................................... 7-20

リアルタイム適用の使用 ............................................................................................................................. 7-20

動的サービス登録用のデータベースおよびリスナーの構成 ................................................................. 7-21

WAN 環境でのネットワークのチューニング ......................................................................................... 7-22

データ保護モードの決定 ............................................................................................................................. 7-23

保護モードの決定 ................................................................................................................................. 7-24

データ保護モードの変更 ..................................................................................................................... 7-25ネットワーク構成案によるパフォーマンス評価の実施 ......................................................................... 7-26

大可用性モードまたは大保護モードでの LAN または MAN の使用 .......................................... 7-27

大のパフォーマンス・スループットを得るための ARCH の使用 ................................................... 7-28

データ消失を制御するための ASYNC 属性の使用 ................................................................................. 7-28

圧縮を使用した SSH ポート転送の評価 ................................................................................................... 7-30

LOG_ARCHIVE_LOCAL_FIRST を TRUE に設定 ................................................................................. 7-30

REDO データの安全な転送 ........................................................................................................................ 7-30

DB_UNIQUE_NAME の設定 ..................................................................................................................... 7-31

LOG_ARCHIVE_CONFIG の適切な設定 ................................................................................................. 7-31

v

フィジカル・スタンバイ・データベースのみに関する推奨事項 ......................................................... 7-31

メディア・リカバリのパフォーマンスのチューニング ................................................................. 7-31ロジカル・スタンバイ・データベースのみに関する推奨事項 ............................................................. 7-32

補助ロギングおよび主キー制約の使用 ............................................................................................. 7-32

MAX_SERVERS 初期化パラメータの設定 ....................................................................................... 7-32PARALLEL_MAX_SERVERS 初期化パラメータ値の増加 ............................................................ 7-33TRANSACTION_CONSISTENCY 初期化パラメータの設定 ....................................................... 7-33不要なオブジェクトに対する SQL Apply のスキップ ................................................................... 7-33

MAA に関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティス ............................................................................................. 7-34複数のスタンバイ・インスタンスの構成 ................................................................................................. 7-34

ネットワーク・サービスの記述子に対する接続時フェイルオーバーの構成 ..................................... 7-35

バックアップおよびリカバリに関する推奨事項バックアップおよびリカバリに関する推奨事項バックアップおよびリカバリに関する推奨事項バックアップおよびリカバリに関する推奨事項 ............................................................................................. 7-36Recovery Manager を使用したデータベース・ファイルのバックアップ .......................................... 7-37

バックアップの使用時期の識別 ................................................................................................................. 7-37

定期的なバックアップの実行 ............................................................................................................. 7-37Data Guard 環境の初期設定 ............................................................................................................... 7-37ファイルまたはブロック・メディア・リカバリを使用したデータ障害からのリカバリ ......... 7-38二重障害の解決 ..................................................................................................................................... 7-38

長期バックアップ ................................................................................................................................. 7-38RMAN Recovery Catalog の使用 ............................................................................................................... 7-38

制御ファイルおよび SPFILE の自動バックアップ機能の使用 .............................................................. 7-39

段階的に更新されたバックアップの使用によるリストア時間の短縮 ................................................. 7-39

変更トラッキングの有効化によるバックアップ時間の短縮 ................................................................. 7-39

フラッシュ・リカバリ領域にディスク上のデータベース・バックアップを作成 ............................. 7-39

フラッシュ・リカバリ領域からテープ・バックアップを作成 ............................................................. 7-40

保存方針およびバックアップ頻度の決定 ................................................................................................. 7-40

フラッシュ・リカバリ領域の適切なサイズの構成 ................................................................................. 7-41

Data Guard 環境における全サイトでのフラッシュ・リカバリ領域へのバックアップ ................... 7-41

バックアップ時にターゲット・データベースの制御ファイルを Recovery Manager リポジトリ

として使用 ..................................................................................................................................................... 7-42

ブロック破損検出のためのデータベース・ファイルの定期チェック ................................................. 7-42

リカバリ手順の定期的なテスト ................................................................................................................. 7-43

テープまたはオフサイトへの OCR のバックアップ .............................................................................. 7-43

高速アプリケーション・フェイルオーバーに関する推奨事項高速アプリケーション・フェイルオーバーに関する推奨事項高速アプリケーション・フェイルオーバーに関する推奨事項高速アプリケーション・フェイルオーバーに関する推奨事項 ..................................................................... 7-44すべての本番インスタンスの接続記述子の構成 ..................................................................................... 7-45

RAC の可用性通知およびイベントの使用 ............................................................................................... 7-47

vi

RAC の通知を使用できない場合の透過的アプリケーション・フェイルオーバーの使用 ............... 7-47

新規の接続 ............................................................................................................................................. 7-48既存の接続 ............................................................................................................................................. 7-48接続記述子内の LOAD_BALANCE パラメータ ............................................................................. 7-49

接続記述子内の FAILOVER パラメータ .......................................................................................... 7-49接続記述子内の SERVICE_NAME パラメータ ............................................................................... 7-49接続記述子内の RETRIES パラメータ ............................................................................................... 7-49接続記述子内の DELAY パラメータ ................................................................................................. 7-49

サービスの構成 ............................................................................................................................................. 7-50

高可用性を維持するための CRS の構成 ................................................................................................... 7-50

中間層アプリケーションとクライアントに通知するためのサービス・コールアウトの構成 ......... 7-51

スタンバイまたは本番以外のサービスの公開 ......................................................................................... 7-51

本番サービスの公開 ..................................................................................................................................... 7-51

第第第第 IV 部部部部高い可用性を備えた高い可用性を備えた高い可用性を備えた高い可用性を備えた Oracle 環境の管理環境の管理環境の管理環境の管理

8 Oracle Enterprise Manager を使用した監視と検出を使用した監視と検出を使用した監視と検出を使用した監視と検出

高可用性の監視と検出の概要高可用性の監視と検出の概要高可用性の監視と検出の概要高可用性の監視と検出の概要 ............................................................................................................................... 8-2Enterprise Manager を使用したシステムの監視を使用したシステムの監視を使用したシステムの監視を使用したシステムの監視 .............................................................................................. 8-2

各システムに対するデフォルトの通知ルールの設定 ............................................................................... 8-5

「Database Target」ビューを使用した状態、可用性およびパフォーマンスの監視 ............................ 8-9

イベント通知を使用したメトリック変更への対応 ................................................................................. 8-11

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

Enterprise Manager によるによるによるによる HA 環境の管理環境の管理環境の管理環境の管理 ................................................................................................... 8-12

Enterprise Manager ポリシー違反のチェック ......................................................................................... 8-12

Enterprise Manager を使用した Oracle Patches の管理とシステム・ベースラインのメンテナンス ... 8-12

Enterprise Manager を使用した Data Guard ターゲットの管理 ............................................................ 8-13

Enterprise Manager の高可用性アーキテクチャの高可用性アーキテクチャの高可用性アーキテクチャの高可用性アーキテクチャ ............................................................................................ 8-14Enterprise Manager の HA アーキテクチャに対する推奨事項 ............................................................ 8-16

リポジトリとプロセスの保護および監視対象の構成 ..................................................................... 8-16Management Repository の RAC インスタンスへの配置および Data Guard の使用 .............. 8-17

低 2 つの Management Service プロセスの構成とそのロード・バランシング ...................... 8-17HA システムと同じハードウェアでの Enterprise Manager のホスティング ............................ 8-17プロセスとエージェント間のネットワーク帯域幅の監視 ............................................................. 8-18

Enterprise Manager の計画外停止 ............................................................................................................. 8-18

vii

Enterprise Manager の追加構成の追加構成の追加構成の追加構成 ........................................................................................................................ 8-20

Enterprise Manager に対する個別リスナーの構成 ................................................................................. 8-20

既存のデータベースへの Management Repository のインストール ................................................... 8-21

9 停止からのリカバリ停止からのリカバリ停止からのリカバリ停止からのリカバリ

計画外停止のリカバリ手順計画外停止のリカバリ手順計画外停止のリカバリ手順計画外停止のリカバリ手順 ................................................................................................................................... 9-2プライマリ・サイトでの計画外停止に対するリカバリ手順 ................................................................... 9-4

セカンダリ・サイトでの計画外停止に対するリカバリ手順 ................................................................... 9-7

計画的停止のリカバリ手順計画的停止のリカバリ手順計画的停止のリカバリ手順計画的停止のリカバリ手順 ................................................................................................................................... 9-8

プライマリ・サイトでの計画的停止に対するリカバリ手順 ................................................................. 9-10

セカンダリ・サイトでの計画的停止に対するリカバリ手順 ................................................................. 9-11

セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備 ..................................... 9-13

10 リカバリ手順の詳細リカバリ手順の詳細リカバリ手順の詳細リカバリ手順の詳細

リカバリ操作の概略リカバリ操作の概略リカバリ操作の概略リカバリ操作の概略 ............................................................................................................................................. 10-2全体または部分的なサイト・フェイルオーバー全体または部分的なサイト・フェイルオーバー全体または部分的なサイト・フェイルオーバー全体または部分的なサイト・フェイルオーバー ............................................................................................. 10-3

全体のサイト・フェイルオーバー ............................................................................................................. 10-4

部分的なサイト・フェイルオーバー : リモート・データベース・サーバーへの

中間層アプリケーションの接続 ................................................................................................................. 10-8

データベース・フェイルオーバーデータベース・フェイルオーバーデータベース・フェイルオーバーデータベース・フェイルオーバー ................................................................................................................... 10-10Data Guard フェイルオーバーを使用する場合 ..................................................................................... 10-11

Data Guard フェイルオーバーを使用しない場合 ................................................................................. 10-11

SQL*Plus を使用した Data Guard フェイルオーバー .......................................................................... 10-11

SQL*Plus を使用したフィジカル・スタンバイ・フェイルオーバー ......................................... 10-11SQL*Plus を使用したロジカル・スタンバイ・フェイルオーバー ............................................. 10-12

データベース・スイッチオーバーデータベース・スイッチオーバーデータベース・スイッチオーバーデータベース・スイッチオーバー ................................................................................................................... 10-13

Data Guard スイッチオーバーを使用する場合 ..................................................................................... 10-13

Data Guard スイッチオーバーを使用しない場合 ................................................................................. 10-14

SQL*Plus を使用した Data Guard スイッチオーバー .......................................................................... 10-14

SQL*Plus を使用したフィジカル・スタンバイ・スイッチオーバー ......................................... 10-14SQL*Plus を使用したロジカル・スタンバイ・スイッチオーバー ............................................. 10-15

RAC リカバリリカバリリカバリリカバリ ..................................................................................................................................................... 10-16

計画外停止の RAC リカバリ .................................................................................................................... 10-16

障害のあるインスタンスの自動インスタンス・リカバリ ........................................................... 10-16Real Application Clusters での単一ノード障害 .................................................................... 10-16Real Application Clusters での複数ノード障害 .................................................................... 10-16

viii

サービスの自動再配置 ....................................................................................................................... 10-17

計画的停止の RAC リカバリ .................................................................................................................... 10-17

CRS 管理リソースの無効化 .............................................................................................................. 10-17計画的なサービスの再配置 ............................................................................................................... 10-18

適用インスタンス・フェイルオーバー適用インスタンス・フェイルオーバー適用インスタンス・フェイルオーバー適用インスタンス・フェイルオーバー ........................................................................................................... 10-19SQL*Plus を使用した適用インスタンス・フェイルオーバーの実行 ................................................. 10-20

手順 1: 選択されたスタンバイ・インスタンスのマウントの確認 .............................................. 10-20手順 2: 選択されたスタンバイ・ホストへの Oracle Net 接続の検証 ......................................... 10-20

手順 3: 選択されたスタンバイ・インスタンスでのリカバリの開始 .......................................... 10-21手順 4: 新しい適用ホストへのアーカイブ REDO ログのコピー ................................................ 10-21手順 5: 新しい構成の検証 .................................................................................................................. 10-21

データ障害に対するリカバリ・ソリューションデータ障害に対するリカバリ・ソリューションデータ障害に対するリカバリ・ソリューションデータ障害に対するリカバリ・ソリューション ........................................................................................... 10-22データファイル・ブロックの破損の検出とリカバリ ........................................................................... 10-23

データファイル・ブロックの破損の検出 ....................................................................................... 10-24

データファイル・ブロックの破損からのリカバリ ....................................................................... 10-24破損範囲の判断 ........................................................................................................................... 10-24障害のあるハードウェアの置換または移動 ........................................................................... 10-26影響を受けるオブジェクトの判断 ........................................................................................... 10-26

使用するリカバリ方法の決定 ................................................................................................... 10-27メディア障害からのリカバリ ................................................................................................................... 10-30

メディア障害の範囲の判断 ............................................................................................................... 10-30

障害のあるハードウェアの置換または移動 ................................................................................... 10-30実行するリカバリ処置の決定 ........................................................................................................... 10-31

データ障害に対するリカバリ方法 ........................................................................................................... 10-34

Recovery Manager のデータファイル・メディア・リカバリの使用 ........................................ 10-34Recovery Manager のブロック・メディア・リカバリの使用 .................................................... 10-34手動によるオブジェクトの再作成 ................................................................................................... 10-36Data Guard を使用したデータ障害からのリカバリ ..................................................................... 10-36

フラッシュバック・テクノロジによるユーザー・エラーからのリカバリフラッシュバック・テクノロジによるユーザー・エラーからのリカバリフラッシュバック・テクノロジによるユーザー・エラーからのリカバリフラッシュバック・テクノロジによるユーザー・エラーからのリカバリ ............................................... 10-37行とトランザクションの非一貫性の解決 ............................................................................................... 10-39

フラッシュバック問合せ ................................................................................................................... 10-39

フラッシュバック・バージョン問合せ ........................................................................................... 10-40フラッシュバック・トランザクション問合せ ............................................................................... 10-40例 : フラッシュバック・テクノロジを使用した給与相違の調査 ................................................ 10-41

表の非一貫性の解決 ................................................................................................................................... 10-43

フラッシュバック・テーブル ........................................................................................................... 10-43フラッシュバック・ドロップ ........................................................................................................... 10-43

ix

データベース全体の非一貫性の解決 ....................................................................................................... 10-44

フラッシュバック・データベース ................................................................................................... 10-44フラッシュバック・データベースを使用した削除済表領域の修復 ........................................... 10-46

RAC ローリング・アップグレードローリング・アップグレードローリング・アップグレードローリング・アップグレード ................................................................................................................. 10-47

opatch によるパッチの適用 ...................................................................................................................... 10-48

opatch によるパッチのロールバック ...................................................................................................... 10-49

opatch を使用したインストール済ソフトウェア・コンポーネントとパッチのリスト .................. 10-49

RAC ローリング・アップグレードの推奨プラクティス ..................................................................... 10-49

ロジカル・スタンバイ・データベースによるアップグレードロジカル・スタンバイ・データベースによるアップグレードロジカル・スタンバイ・データベースによるアップグレードロジカル・スタンバイ・データベースによるアップグレード ................................................................... 10-51オンラインでのオブジェクトの再編成オンラインでのオブジェクトの再編成オンラインでのオブジェクトの再編成オンラインでのオブジェクトの再編成 ........................................................................................................... 10-55

オンラインでの表の再編成 ....................................................................................................................... 10-55

オンラインでの索引の再編成 ................................................................................................................... 10-56

オンラインでの表領域の再編成 ............................................................................................................... 10-56

11 フォルト・トレランスのリストアフォルト・トレランスのリストアフォルト・トレランスのリストアフォルト・トレランスのリストア

トレランスの完全なリストアトレランスの完全なリストアトレランスの完全なリストアトレランスの完全なリストア ............................................................................................................................. 11-2RAC クラスタ内の障害のあるノードやインスタンスのリストアクラスタ内の障害のあるノードやインスタンスのリストアクラスタ内の障害のあるノードやインスタンスのリストアクラスタ内の障害のあるノードやインスタンスのリストア ............................................................... 11-3

サービス可用性のリカバリ ......................................................................................................................... 11-4

RAC インスタンスをリストアした後のクライアント接続の考慮点 ................................................... 11-5

フェイルオーバー後のスタンバイ・データベースのリストアフェイルオーバー後のスタンバイ・データベースのリストアフェイルオーバー後のスタンバイ・データベースのリストアフェイルオーバー後のスタンバイ・データベースのリストア ................................................................... 11-10フェイルオーバー後のフィジカル・スタンバイ・データベースのリストア ................................... 11-11

手順 1P: STANDBY_BECAME_PRIMARY_SCN の取得 ............................................................. 11-11

手順 2P: 以前の本番データベースのフラッシュバック ............................................................... 11-11手順 3P: 以前の本番データベースからの新規スタンバイ・データベースのマウント ........... 11-11手順 4P: 新規本番データベースから新規スタンバイ・データベースへのアーカイブ ........... 11-12

手順 5P: 管理リカバリの起動 ........................................................................................................... 11-12手順 6P: End-of-Redo マーカー発生後の MRP の再起動 ............................................................. 11-13

フェイルオーバー後のロジカル・スタンバイ・データベースのリストア ....................................... 11-13

手順 1L: END_PRIMARY_SCN の取得 ........................................................................................... 11-13

手順 2L: 以前の本番データベースのフラッシュバック ............................................................... 11-13手順 3L: 新規ロジカル・スタンバイ・データベースのオープンと SQL Apply の起動 ......... 11-13

セカンダリ・サイトまたはクラスタ全体の計画的停止の後で行うフォルト・トレランスのリストアセカンダリ・サイトまたはクラスタ全体の計画的停止の後で行うフォルト・トレランスのリストアセカンダリ・サイトまたはクラスタ全体の計画的停止の後で行うフォルト・トレランスのリストアセカンダリ・サイトまたはクラスタ全体の計画的停止の後で行うフォルト・トレランスのリストア ... 11-14

手順 1: スタンバイ・データベースの起動 .............................................................................................. 11-14

手順 2: リカバリの起動 .............................................................................................................................. 11-14

手順 3: 本番データベースでのログ転送サービスの検証 ...................................................................... 11-15

x

手順 4: スタンバイ・データベースでのリカバリ進行の検証 .............................................................. 11-15

手順 5: 本番データベースの保護モードのリストア .............................................................................. 11-15

スタンバイ・データベースでのデータ障害後に行うフォルト・トレランスのリストアスタンバイ・データベースでのデータ障害後に行うフォルト・トレランスのリストアスタンバイ・データベースでのデータ障害後に行うフォルト・トレランスのリストアスタンバイ・データベースでのデータ障害後に行うフォルト・トレランスのリストア ....................... 11-16手順 1: 停止原因の修正 .............................................................................................................................. 11-16

手順 2: 影響を受けたデータファイルのバックアップのリストア ...................................................... 11-16

手順 3: 必要なアーカイブ REDO ログ・ファイルのリストア ............................................................ 11-17

手順 4: スタンバイ・データベースの起動 .............................................................................................. 11-17

手順 5: リカバリまたは適用の開始 .......................................................................................................... 11-17

手順 6: 本番データベースでのログ転送サービスの検証 ...................................................................... 11-18

手順 7: スタンバイ・データベースでのリカバリ進行または適用進行の検証 .................................. 11-18

手順 8: 本番データベースの保護モードのリストア .............................................................................. 11-18

本番データベースがリセットログをオープンした後のフォルト・トレランスのリストア本番データベースがリセットログをオープンした後のフォルト・トレランスのリストア本番データベースがリセットログをオープンした後のフォルト・トレランスのリストア本番データベースがリセットログをオープンした後のフォルト・トレランスのリストア ................... 11-19使用例 1: スタンバイの SCN が本番のリセットログ SCN より遅い ................................................. 11-19

使用例 2: スタンバイの SCN が本番のリセットログ SCN より早い ................................................. 11-20

二重障害後のフォルト・トレランスのリストア二重障害後のフォルト・トレランスのリストア二重障害後のフォルト・トレランスのリストア二重障害後のフォルト・トレランスのリストア ........................................................................................... 11-21

A Hardware Assisted Resilient Data（（（（HARD））））InitiativeHARD 準拠のストレージによるデータ破損の防止準拠のストレージによるデータ破損の防止準拠のストレージによるデータ破損の防止準拠のストレージによるデータ破損の防止 ......................................................................................... A-2

データ破損データ破損データ破損データ破損 ............................................................................................................................................................... A-3HARD による対処の対象となるデータ破損のタイプによる対処の対象となるデータ破損のタイプによる対処の対象となるデータ破損のタイプによる対処の対象となるデータ破損のタイプ ..................................................................................... A-3HARD で実行可能なチェック項目で実行可能なチェック項目で実行可能なチェック項目で実行可能なチェック項目 ..................................................................................................................... A-4

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

SPFILE のサンプルのサンプルのサンプルのサンプル ................................................................................................................................................ B-3Oracle Net 構成ファイル構成ファイル構成ファイル構成ファイル ...................................................................................................................................... B-9

動的インスタンス登録を使用する全ホストの SQLNET.ORA ファイルのサンプル ........................... B-9

動的インスタンス登録を使用する全ホストの LISTENER.ORA ファイルのサンプル ....................... B-9

動的インスタンス登録を使用する全ホストの TNSNAMES.ORA ファイルのサンプル ................. B-10

索引索引索引索引

xi

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

このマニュアルはデータベースの高可用性に関するリファレンスです。Oracle データベースのアーキテクチャと機能に加え、ビジネスで高可用性を実現するために役立つ推奨プラクティスについて説明します。適切な高可用性ソリューションを選択するためのガイドラインも示します。

ここでは、次の項目について説明します。

� 対象読者

� このドキュメントの構成

� 関連ドキュメント

� 表記規則

xiii

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

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

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

� 高可用性システムのメンテナンス

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

このドキュメントの構成このドキュメントの構成このドキュメントの構成このドキュメントの構成このドキュメントの構成は次のとおりです。

第第第第 I 部「スタート・ガイド」部「スタート・ガイド」部「スタート・ガイド」部「スタート・ガイド」高可用性（HA）の概要および高可用性を実現するために使用できる Oracle 機能について説明します。

第第第第 1 章「高可用性の概要」章「高可用性の概要」章「高可用性の概要」章「高可用性の概要」

高可用性の定義および HA アーキテクチャとプラクティスの必要性について説明します。高可用性を実現するために必要な事項を一般的な用語で記述しています。停止の例を挙げ、停止がビジネスに与える影響を示します。このマニュアルの有効範囲と使用方法についても説明します。

第第第第 2 章「高可用性要件の決定」章「高可用性要件の決定」章「高可用性要件の決定」章「高可用性要件の決定」

品質保証契約とビジネス要件について説明します。データの消失が許容可能かどうかを判断するガイドラインを示し、HA プラクティスがパフォーマンスと管理性に与える影響について説明します。

第第第第 II 部「部「部「部「Oracle Database の高可用性機能、アーキテクチャおよびポリシー」の高可用性機能、アーキテクチャおよびポリシー」の高可用性機能、アーキテクチャおよびポリシー」の高可用性機能、アーキテクチャおよびポリシー」高可用性ソリューションを実装するための決定に影響を与えるビジネス要件について説明します。基本的な要因を識別、定義および説明した後、それらの要因を使用して、高可用性アーキテクチャを選択するためのガイダンスを示します。

第第第第 3 章「章「章「章「Oracle Database の高可用性機能」の高可用性機能」の高可用性機能」の高可用性機能」

Oracle HA 機能について詳細に説明します。

第第第第 4 章「高可用性アーキテクチャ」章「高可用性アーキテクチャ」章「高可用性アーキテクチャ」章「高可用性アーキテクチャ」

検証済の HA アーキテクチャについて説明します。

xiv

第第第第 5 章「高可用性の操作ポリシー」章「高可用性の操作ポリシー」章「高可用性の操作ポリシー」章「高可用性の操作ポリシー」

HA の操作上のベスト・プラクティスについて説明します。

第第第第 III 部「高可用性を備えた部「高可用性を備えた部「高可用性を備えた部「高可用性を備えた Oracle 環境の構成」環境の構成」環境の構成」環境の構成」高可用性アーキテクチャの構築方法について説明します。

第第第第 6 章「システム構成およびネットワーク構成」章「システム構成およびネットワーク構成」章「システム構成およびネットワーク構成」章「システム構成およびネットワーク構成」

この章では、データベース・サーバー層とネットワークを構成するサブコンポーネントの構成に関する推奨事項を説明します。

第第第第 7 章「章「章「章「Oracle 構成のベスト・プラクティス」構成のベスト・プラクティス」構成のベスト・プラクティス」構成のベスト・プラクティス」

データベース、Oracle Real Application Clusters、Oracle Data Guard、Maximum Availability Architecture、バックアップとリカバリおよび高速アプリケーション・フェイルオーバーについて、推奨する Oracle 構成とベスト・プラクティスを示します。

第第第第 IV 部「高い可用性を備えた部「高い可用性を備えた部「高い可用性を備えた部「高い可用性を備えた Oracle 環境の管理」環境の管理」環境の管理」環境の管理」HA Oracle 環境の管理方法について説明します。

第第第第 8 章「章「章「章「Oracle Enterprise Manager を使用した監視と検出」を使用した監視と検出」を使用した監視と検出」を使用した監視と検出」

システム可用性の監視および検出方法について説明します。Oracle Enterprise Manager に重点を置いています。

第第第第 9 章「停止からのリカバリ」章「停止からのリカバリ」章「停止からのリカバリ」章「停止からのリカバリ」

特定の停止に対して講じる処置を決定する際の意思決定マトリックスを示します。

第第第第 10 章「リカバリ手順の詳細」章「リカバリ手順の詳細」章「リカバリ手順の詳細」章「リカバリ手順の詳細」

第 9 章「停止からのリカバリ」で説明した停止からリカバリするための詳細な手順を示します。

第第第第 11 章「フォルト・トレランスのリストア」章「フォルト・トレランスのリストア」章「フォルト・トレランスのリストア」章「フォルト・トレランスのリストア」

様々なタイプの修復について説明します。これらの修復には、Real Application Cluster における障害ノードのリストア、フェイルオーバー後のスタンバイ・データベースのリストア、およびセカンダリ・サイトやクラスタ全体での計画的な停止の後、スタンバイ・データベースでのデータ障害後、本番データベースのアクティブ化後、二重障害後のフォルト・トレランスの各リストアが含まれます。

付録付録付録付録 A「「「「Hardware Assisted Resilient Data（（（（HARD））））Initiative」」」」Hardware Assisted Resilient Data（HARD）Initiative に関する情報を記載します。

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

データベースの SPFILEおよび Oracle Net 構成ファイルのサンプルを掲載します。

xv

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

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

� 『Oracle Real Application Clusters 配置およびパフォーマンス』

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

� 『Oracle Database 管理者ガイド』

� 『Oracle Application Server 10g 高可用性ガイド』

ドキュメント・セットに含まれるドキュメントの多くでは、Oracle のインストール時にデフォルトでインストールされるシード・データベースのサンプル・スキーマを使用しています。これらのスキーマの作成方法およびその使用方法については、『Oracle Database サンプル・スキーマ』を参照してください。

リリース・ノート、インストール関連ドキュメント、ホワイト・ペーパーまたはその他の関連ドキュメントは、OTN-J（Oracle Technology Network Japan）から、無償でダウンロードできます。OTN-J を使用するには、オンラインでの登録が必要です。登録は、次の Web サイトから無償で行えます。

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

すでに OTN-J のユーザー名およびパスワードを取得している場合は、次の URL で OTN-J Web サイトのドキュメントのセクションに直接接続できます。

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

xvi

表記規則表記規則表記規則表記規則この項では、このマニュアルの本文およびコード例で使用される表記規則について説明します。この項の内容は次のとおりです。

� 本文の表記規則

� コード例の表記規則

� Microsoft Windows オペレーティング・システム環境での表記規則

本文の表記規則本文の表記規則本文の表記規則本文の表記規則本文では、特定の項目が一目でわかるように、次の表記規則を使用します。次の表に、その規則と使用例を示します。

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

太字太字太字太字太字は、本文中で定義されている用語および用語集に記載されている用語を示します。

この句を指定すると、索引構成表索引構成表索引構成表索引構成表が作成されます。

固定幅フォントの大文字

固定幅フォントの大文字は、システム指定の要素を示します。このような要素には、パラメータ、権限、データ型、Recovery Manager キーワード、SQL キーワード、

SQL*Plus またはユーティリティ・コマン

ド、パッケージおよびメソッドがあります。また、システム指定の列名、データベース・オブジェクト、データベース構造、ユーザー名およびロールも含まれます。

NUMBER列に対してのみ、この句を指定できます。

BACKUPコマンドを使用して、データベースの

バックアップを作成できます。

USER_TABLESデータ・ディクショナリ・ビュー

内の TABLE_NAME列を問い合せます。

DBMS_STATS.GENERATE_STATSプロシージャを

使用します。

固定幅フォントの小文字

固定幅フォントの小文字は、実行可能ファイル、ファイル名、ディレクトリ名およびユーザーが指定する要素のサンプルを示します。このような要素には、コンピュータ名

およびデータベース名、ネット・サービス名および接続識別子があります。また、ユーザーが指定するデータベース・オブジェクトとデータベース構造、列名、パッケージとクラス、ユーザー名とロール、プログラム・ユニットおよびパラメータ値も含まれます。

sqlplusと入力して、SQL*Plus をオープンしま

す。

パスワードは、orapwdファイルで指定します。

/disk1/oracle/dbsディレクトリ内のデータ

ファイルおよび制御ファイルのバックアップを作成します。

hr.departments表には、department_id、department_nameおよび location_id列があ

ります。

QUERY_REWRITE_ENABLED初期化パラメータを

trueに設定します。

oeユーザーとして接続します。

注意注意注意注意 : プログラム要素には、大文字と小文

字を組み合せて使用するものもあります。これらの要素は、記載されているとおりに入力してください。

JRepUtilクラスが次のメソッドを実装します。

xvii

コード例の表記規則コード例の表記規則コード例の表記規則コード例の表記規則コード例は、SQL、PL/SQL、SQL*Plus または他のコマンドライン文の例です。次のように、固定幅フォントで表示され、通常のテキストと区別されます。

SELECT username FROM dba_users WHERE username = 'MIGRATE';

次の表に、コード例で使用される表記規則とその使用例を示します。

固定幅フォントの小文字のイタリック

固定幅フォントの小文字のイタリックは、プレースホルダまたは変数を示します。

parallel_clauseを指定できます。

old_release.SQLを実行します。ここで、

old_releaseとはアップグレード前にインス

トールしたリリースを示します。


[ ] 大カッコは、カッコ内の項目を任意に選択することを表します。

DECIMAL (digits [ , precision ])

{ } 中カッコは、項目をグループ化するために使用します。

{ENABLE | DISABLE}

| 縦線は、2 つの選択項目の区切りに使用しま

す。

{ENABLE | DISABLE}[COMPRESS | NOCOMPRESS]

... 水平の省略記号は、構文の説明での反復を意味します。

さらに、コード例またはテキストで省略部分があることを意味することもあります。

CREATE TABLE ... AS subquery;

SELECT col1, col2, ... , coln FROM employees;

その他の記号大カッコ（[ ]）、中カッコ（{ }）、縦線（|）および省略記号（...）以外の記号は、記載

されているとおり入力する必要があります。

acctbal NUMBER(11,2);acct CONSTANT NUMBER(4) := 3;

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

CONNECT SYSTEM/system_passwordDB_NAME = database_name

大文字大文字は、システム指定の要素を示します。これらの要素は、ユーザー定義の要素と区別するために大文字で示されます。大カッコにないかぎり、表示されているとおりの順序および綴りで入力します。ただし、大 /小文字が区別されないため、小文字でも使用できます。

SELECT last_name, employee_id FROM employees;SELECT * FROM USER_TABLES;DROP TABLE hr.employees;


xviii

Microsoft Windows オペレーティング・システム環境での表記規則オペレーティング・システム環境での表記規則オペレーティング・システム環境での表記規則オペレーティング・システム環境での表記規則次の表に、Microsoft Windows オペレーティング・システム環境での表記規則とその使用例を示します。

小文字小文字は、ユーザー指定のプログラム要素を示します。たとえば、表名、列名またはファイル名などです。

注意注意注意注意 : プログラム要素には、大文字と小文

字を組み合せて使用するものもあります。これらの要素は、記載されているとおりに入力してください。

SELECT last_name, employee_id FROM employees;sqlplus hr/hrCREATE USER mjones IDENTIFIED BY ty3MU9;


ファイル名およびディレクトリ名

ファイル名およびディレクトリ名は大 / 小

文字が区別されません。特殊文字の左山カッコ（<）、右山カッコ（>）、コロン（:）、二重引用符（"）、スラッシュ（/）、縦線

（|）およびハイフン（-）は使用できませ

ん。円記号（¥）は、引用符で囲まれている

場合でも、要素のセパレータとして処理されます。Windows では、ファイル名が ¥¥ で

始まる場合、汎用命名規則が使用されていると解釈されます。

c:¥winnt"¥"system32は

C:¥WINNT¥SYSTEM32と同じです。

Windows コマン

ド・プロンプト

Windows コマンド・プロンプトには、カレ

ント・ディレクトリが表示されます。コマンド・プロンプトのエスケープ文字はカレット（^）です。プロンプトは、現在作業

中のサブディレクトリを示します。このマニュアルでは、コマンド・プロンプトと呼びます。

C:¥oracle¥oradata>

特殊文字 Windows コマンド・プロンプトで二重引用

符（"）のエスケープ文字として円記号（¥）が必要な場合があります。丸カッコおよび一重引用符（'）にはエスケープ文字は必要

ありません。エスケープ文字および特殊文字の詳細は、Windows オペレーティング・

システムのドキュメントを参照してください。

C:¥>exp HR/HR TABLES=employees QUERY=¥"WHERE job_id='SA_REP' and salary<8000¥"


xix

HOME_NAME Oracle ホームの名前を表します。ホーム名

には、英数字で 16 文字まで使用できます。ホーム名で使用できる特殊文字は、アンダースコアのみです。

C:¥> net start OracleHOME_NAMETNSListener

ORACLE_HOMEおよびORACLE_BASE

Oracle8i より前のリリースでは、Oracle コ

ンポーネントをインストールすると、すべてのサブディレクトリが上位のORACLE_HOMEの直下に置かれました。

Windows NT のデフォルトは、C:¥orantでした。

このリリースは、Optimal Flexible Architecture（OFA）のガイドラインに準拠

しています。ORACLE_HOMEディレクトリ

下に配置されないサブディレクトリもあります。上位のディレクトリはORACLE_BASEと呼ばれ、デフォルトでは

C:¥oracle¥product¥10.1.0です。他の

Oracle ソフトウェアがインストールされて

いないコンピュータに新リリースのOracle をインストールした場合、Oracleホーム・ディレクトリは、デフォルトでC:¥oracle¥product¥10.1.0¥db_nに設

定されます。nは新の Oracle ホーム番号

です。Oracle ホーム・ディレクトリは、

ORACLE_BASEの直下に配置されます。

このマニュアルに示すディレクトリ・パスの例は、すべて OFA の表記規則に準拠して

います。

ORACLE_BASE¥ORACLE_HOME¥rdbms¥adminディレクトリへ移動します。


xx

第第第第 I 部部部部
スタート・ガイドスタート・ガイドスタート・ガイドスタート・ガイド
第Ⅰ部では、高可用性の概要および高可用性要件の決定について説明します。

内容は次のとおりです。

� 第 1 章「高可用性の概要」

� 第 2 章「高可用性要件の決定」

高可用性の

1
高可用性の概要高可用性の概要高可用性の概要高可用性の概要
この章の内容は、次のとおりです。

� 高可用性の概要

� 可用性の概要

� 可用性の重要性

� 停止時間の原因

� このマニュアルの内容

� 対象読者

概要 1-1

高可用性の概要

高可用性の概要高可用性の概要高可用性の概要高可用性の概要データベースおよびインターネットは、データベース・アプリケーションの領域を組織や地域社会まで拡張することによって、世界的なコラボレーションおよび情報の共有を可能にしました。このような領域では、データ管理ソリューションにおける高可用性（HA）の重要性が強調されます。中小企業およびグローバル企業の両方には、ユーザーが世界中におり、1 日 24 時間データへのアクセスを必要とします。このデータ・アクセスが行われないと、業務が停止し、収益が失われます。独自のソリューションへの依存度が高まっているユーザーは現在、情報技術（IT）部門およびソリューション・プロバイダからの品質保証契約を要求します。可用性は、時間や利便性のみではなく、ドル、ユーロおよび円でますます評価されるようになってきています。

企業は、独自の IT インフラストラクチャを使用して、競合相手に対する優位性を確立し、生産性を高め、ユーザーが情報に基づいてさらに迅速で的確な決定を下せるようにします。ただし、これらの利点に伴い、そのインフラストラクチャへの依存度は高まっています。重要なアプリケーションが使用できなくなると、ビジネス全体が危険にさらされます。収益および顧客を失い、ペナルティを与えられ、悪い評判によって顧客や自社の株価が長期間にわたって影響を受ける可能性があります。データの保護方法を決定する要因を調査し、ユーザーに対する可用性を大にすることが重要です。

可用性の概要可用性の概要可用性の概要可用性の概要可用性とは、ユーザーが要求したときに、アプリケーションまたはサービスが機能する状態で使用できる度合いを示します。可用性は、アプリケーションのエンド・ユーザーの認識によって評価されます。エンド・ユーザーは、データが使用できないと不満を感じ、ソリューション全体の複雑なコンポーネントについては理解しないか、またはその違いを気にしません。予測した使用量を超えたことによるパフォーマンスの障害は、ソリューションの重要なコンポーネントの障害と同様の混乱をもたらします。

信頼性、リカバリ可能性および継続的な稼働が高可用性ソリューションの 3 つの特性です。

� 信頼性信頼性信頼性信頼性 : 信頼性のあるハードウェアは、HA ソリューションの構成要素の 1 つです。データベース、Web サーバーおよびアプリケーションを含め、信頼性のあるソフトウェアも高可用性ソリューションの実装と同じく重要です。

� リカバリ可能性リカバリ可能性リカバリ可能性リカバリ可能性 : 障害が発生した場合のリカバリ方法には、多数の選択肢があります。現在の高可用性環境で発生する可能性がある障害の種類、およびビジネス要件を満たす時間内にこれらの障害からリカバリする方法を判別することが重要です。たとえば、重要な表が誤ってデータベースから削除された場合、リカバリするにはどのような処理を実行するかを考えてみます。現在のアーキテクチャで、品質保証契約（SLA）で指定された時間内にリカバリが可能かどうかを確認してください。

� エラーの検出エラーの検出エラーの検出エラーの検出 : アーキテクチャ内のコンポーネントで障害が発生した場合、迅速な検出は、起こり得る予想外の障害からリカバリするときのもう 1 つの必須構成要素です。停止からすぐにリカバリできる可能性があるのに対して、問題の検出に 90 分かかる場合は、SLA を満たさない恐れがあります。環境の状態の監視には、状態を迅速に表示し、問題を DBA に通知できる信頼性のあるソフトウェアが必要です。

1-2　Oracle 高可用性アーキテクチャおよびベスト・プラクティス

可用性の重要性

� 継続的な稼働継続的な稼働継続的な稼働継続的な稼働 : メンテナンス・アクティビティを実行するための停止時間がほとんどないか、またはまったくないことが許容される場合は、データへの継続的なアクセスが非常に重要です。表をデータベース内の別の位置に移動したり、またはハードウェアにCPU を追加するなどのアクティビティは、HA アーキテクチャ内のエンド・ユーザーに対して透過的であることが必要です。

HA アーキテクチャには、次のような特性があります。

� ほとんどの障害に対して透過的

� 組込みの予防策の提供

� 障害の事前的監視および迅速な検出機能の提供

� 迅速なリカバリ機能の提供

� リカバリ操作の自動化

� データの消失をなくすまたは小限に抑えるためのデータ保護

� 環境を管理するための操作上のベスト・プラクティスの実装

� SLA を満たす HA ソリューションの提供

可用性の重要性可用性の重要性可用性の重要性可用性の重要性高可用性の重要性はアプリケーションによって様々です。ただし、企業が競合相手に対する優位性の獲得を目指してソリューションを設計しなおすにつれて、可用性のレベルを高める必要性は絶え間なく加速しています。通常これらの新しいソリューションは、重要なビジネス・データへの即時アクセスに依存しています。データが使用できない場合、操作が機能しなくなる場合があります。停止時間は、生産性の損失、収益の損失、顧客関係の損傷、悪い評判および訴訟などにつながる恐れがあります。

不可欠なアプリケーションが使用できなくなると、企業は危険にさらされます。停止時間に直接費を割り当てることは必ずしも容易ではありません。顧客の不満、従業員の怠慢および悪い評判は、すべてコストがかかりますが、通貨で直接評価されることはありません。一方、SLA の目標が満たされないために発生する収益損失および法的なペナルティは容易に定量化できます。停止時間のコストは、サービスを提供するために独自のソリューションに依存する産業で急速に増大します。

停止時間のコストについて考慮するその他の要因は、1 回の計画外停止の大許容時間および許容可能な事象の大頻度です。そのイベントの継続時間が 30 秒未満である場合、影響は非常に小さく、エンド・ユーザーはほとんど認知できません。停止時間が長くなるにしたがって、ささいな問題の不快感が大きな問題になり、法的措置に発展する可能性もあります。ソリューションを設計するときは、これらの問題を考慮して、停止時間の実際のコストを判断することが重要です。この結果、組織は可用性の高いソリューションの構築に相応する額を費やす必要がありますが、そのコストは容認されます。高可用性ソリューションは、有効な保護ポリシーです。

高可用性の概要 1-3

停止時間の原因

Oracle では、規模に関係なくすべての顧客が高可用性ソリューションを利用できます。小規模なワークグループもグローバル企業も同様に、それぞれの重要なビジネス・アプリケーションの範囲を拡張できます。Oracle およびインターネットによって、アプリケーションおよびそのデータに、いつでもどこでも確実にアクセスできます。

停止時間の原因停止時間の原因停止時間の原因停止時間の原因HA ソリューションの設計時の難題の 1 つは、停止時間について考えられるすべての原因を調査し、対処することです。計画外停止時間および計画的停止時間の両方の原因を考慮することが重要です。計画外停止時間には、コンピュータ障害やデータ障害があります。データ障害は、ストレージ障害、人為的なエラー、破損およびサイト障害などが原因で発生します。計画的停止時間には、システム変更やデータ変更があります。計画的停止時間は、特に複数のタイム・ゾーンでユーザーをサポートしているグローバル企業では、操作を中断される場合があります。

このマニュアルの内容このマニュアルの内容このマニュアルの内容このマニュアルの内容可用性要件にも適したアーキテクチャを選択および実装することは、わずらわしい作業です。このアーキテクチャは、全コンポーネントにわたる冗長性を包含し、あらゆる種類の停止時間に対して迅速なクライアント・フェイルオーバーを実現し、一貫した高パフォーマンスを提供し、ユーザー・エラー、破損およびサイト障害からの保護を提供する一方で、簡単に配置、管理および拡張できる必要があります。

このマニュアルでは、いくつかの HA アーキテクチャについて説明し、要件にも適したアーキテクチャを選択するガイドラインを示します。選択したアーキテクチャに関係なく、HA 環境をメンテナンスするために必要なプラクティスについても説明します。また、停止の種類を示し、停止を検出および解決するための青写真を提供します。

関連項目関連項目関連項目関連項目 : 計画外停止および計画的停止の詳細は、第 9 章「停止からのリカバリ」を参照してください。


対象読者

対象読者対象読者対象読者対象読者構成および実装の詳細を理解するには、Oracle Database サーバー、Real Application Clusters および Oracle Data Guard の用語の知識が必要です。

次の章には、高技術責任者および IT 技術者に役立つ情報が記載されています。

� 第 2 章「高可用性要件の決定」

� 第 4 章「高可用性アーキテクチャ」

IT 技術者に必要な情報は、次の章にも記載されています。

� 第 3 章「Oracle Database の高可用性機能」

� 第 5 章「高可用性の操作ポリシー」

次の章には、データベース管理者に役立つ情報が記載されています。



� 第 6 章「システム構成およびネットワーク構成」

� 第 7 章「Oracle 構成のベスト・プラクティス」

� 第 8 章「Oracle Enterprise Manager を使用した監視と検出」

� 第 9 章「停止からのリカバリ」

� 第 11 章「フォルト・トレランスのリストア」

次の章には、ネットワーク管理者およびアプリケーション管理者に役立つ情報が記載されています。






関連項目関連項目関連項目関連項目 :

� 『Oracle Database 概要』

� Oracle Data Guard のドキュメント・セット

� Real Application Clusters のドキュメント・セット

高可用性の概要 1-5

対象読者


高可用性要件の

2
高可用性要件の決定高可用性要件の決定高可用性要件の決定高可用性要件の決定
この章の内容は次のとおりです。

� 高可用性要件の決定の重要性

� 高可用性要件を決定するための分析フレームワーク

� 高可用性アーキテクチャの選択

決定 2-1

高可用性要件の決定の重要性

高可用性要件の決定の重要性高可用性要件の決定の重要性高可用性要件の決定の重要性高可用性要件の決定の重要性今日のグローバル・ビジネスの相互接続された性質によって、より多くのビジネス・コンポーネントの継続的な可用性が必要とされています。しかし、高可用性の実装には高い費用がかかるため、HA 計画を設計および実装するビジネスでは、徹底的な分析を実行し、高可用性を要求するビジネス運営者の完全な理解を得る必要があります。次のような重要な作業が含まれます。

� 既存システムの廃止

� より高度で堅牢なシステムおよび設備への投資

� 高可用性モデルに適応させるための IT アーキテクチャ全体の再設計

� ビジネス・プロセスの再設計

� 人員の雇用および研修

次の表に示すように、可用性が高くなると停止時間が大幅に短縮されます。

高可用性要件を持つビジネスは、ビジネス・コンポーネントに対してより優れたフォルト・トレラントな冗長システムを配置して、ビジネス停止時間のリスクを小限に抑えるために、IT スタッフ、プロセスおよびサービスにさらに多くの投資をする必要があります。

高可用性のビジネス要件の分析およびそれに付随するコストに合意すると、ビジネス管理者のニーズを満たす適なソリューションを、ビジネスの財務的および資源的な制限内で可能なかぎり使用可能にできます。この章では、ビジネスの高可用性要件を評価するために有効に使用できる簡単なフレームワークを提供します。

可用性パーセント可用性パーセント可用性パーセント可用性パーセント年間停止時間（概算）年間停止時間（概算）年間停止時間（概算）年間停止時間（概算）

95% 18 日

99% 4 日

99.9% 9 時間

99.99% 1 時間

99.999% 5 分


高可用性要件を決定するための分析フレームワーク

高可用性要件を決定するための分析フレームワーク高可用性要件を決定するための分析フレームワーク高可用性要件を決定するための分析フレームワーク高可用性要件を決定するための分析フレームワークこの分析フレームワークの要素は、次のとおりです。

� ビジネスへの影響の分析

� 停止時間のコスト

� リカバリ時間目標

� リカバリ・ポイント目標

ビジネスへの影響の分析ビジネスへの影響の分析ビジネスへの影響の分析ビジネスへの影響の分析ビジネスへの影響を的確に分析すると、組織内の重要なビジネス・プロセスが識別され、この各ビジネス・プロセスに影響を与える IT の計画外停止および計画的停止の定量化可能な消失リスクが算出され、これらの停止についてあまり具体的ではない影響の概要が示されます。重要なビジネス機能、人員とシステム・リソース、政府規制および内部的と外部的なビジネス依存関係が考慮されます。この分析は、知識と経験のある人員と会談し、商慣習、財務報告書、IT システム・ログなどを検討して収集した客観的および主観的なデータを使用して行われます。

ビジネスへの影響の分析では、IT 関連の停止による影響の重要度に基づいてビジネス・プロセスが分類されます。たとえば、チップ設計センターが世界中にある半導体製造業者について考えてみます。人事管理、営業費および内部調達へのアクセスを提供する社内システムは、社内電子メール・システムほど重要であるとは考えられていません。電子メール・システムの停止時間は、グローバルな R&D センター間のコラボレーションおよび通信機能に大きく影響し、チップ製造の予期しない遅延の原因となるため、企業の財務に実質的に影響を与えると考えられます。

同様に、社内の知識管理システムは、管理コンサルティング会社にとっては重要であると考えられます。これは、クライアント中心の企業のビジネスは、そのコンサルタントや専門知識のある就業者に対する内部的な調査が使用可能であることを基盤としているためです。このようなシステムの停止時間のコストは、このビジネスに対して非常に高額です。これらのことを踏まえて、高可用性要件フレームワークの次の要素である停止時間のコストの説明に進みます。

高可用性要件の決定 2-3

高可用性要件を決定するための分析フレームワーク

停止時間のコスト停止時間のコスト停止時間のコスト停止時間のコスト適切に実施されたビジネスへの影響の分析では、様々なビジネス・プロセスをサポートするIT システムの計画外および計画的な停止時間によって発生するコストの見通しが示されます。このコストは、停止時間のリスクを低限に抑えるために選択する高可用性テクノロジに直接影響を与えるため、よく理解する必要があります。

業種階層全体の停止時間のコストをドキュメント化した様々な報告書が公開されています。これらのコスト範囲は、証券会社の操作やクレジット・カード販売の時間当たり何百万ドルというコストから、荷物出荷サービスの時間当たり数万ドルのコストまで様々です。

これらの数値が膨大である反面、理由は非常に明白です。インターネットは、ビジネスの電子店舗に何百万もの顧客を直接呼び込みました。顧客関係、競合相手に対する優位性、法的義務、業界の評判および株主の信用など、重要な相互依存のビジネスに関する問題は、ビジネスの中断に対する脆弱さが増しているためさらに重要です。

リカバリ時間目標リカバリ時間目標リカバリ時間目標リカバリ時間目標ビジネスへの影響の分析は、停止時間のコストの計算と同じく、ビジネス継続計画における重要な統計であるリカバリ時間目標（RTO）の見通しを提供します。これは、組織が深刻な物質的損失を受け始める前に、IT ベースのビジネス・プロセスが停止できる大時間として定義されます。RTO は、一般にビジネス・プロセスまたは組織の停止時間許容範囲を示します。

RTO 要件は、重要な性質に比例します。したがって、株式取引を実行するシステムの場合、RTO は 0（ゼロ）または非常に 0（ゼロ）に近くなります。

組織は、様々なビジネス・プロセスに多種多様な RTO 要件を設定する場合があります。したがって、E-Commerce の大容量 Web サイトで、迅速な応答時間が期待され顧客の切替えコストが非常に安価である場合、E-Commerce 販売を処理する Web ベースの顧客対話システムは、RTO が 0（ゼロ）に近くなる可能性があります。ただし、出荷や請求などのバックエンド操作をサポートするシステムの RTO は高くなります。これらのバックエンド・システムが停止した場合は、一時的に手動操作を使用でき、影響がはっきりと認識されることはありません。

RTO に関連するシステム統計にネットワーク・リカバリ目標（NRO）があります。これは、ビジネスに対するネットワーク操作の停止可能な大時間を示します。ネットワーク操作のコンポーネントには、通信リンク、ルーター、ネーム・サーバー、ロード・バランサおよびトラフィック・マネージャが含まれます。NRO は組織全体の RTO に影響を与えます。これは、ネットワーク停止時に各サーバーにアクセスできないと、サーバーを使用できないためです。


高可用性アーキテクチャの選択

リカバリ・ポイント目標リカバリ・ポイント目標リカバリ・ポイント目標リカバリ・ポイント目標リカバリ・ポイント目標（RPO）は、ビジネス継続計画に対するもう 1 つの重要な統計で、有効なビジネスへの影響の分析から算出されます。これは、組織に不利益をもたらす前に、IT ベースのビジネス・プロセスで消失が許容されるデータの大量として定義されます。RPO は、一般にビジネス・プロセスまたは組織のデータ消失許容範囲を示します。このデータ消失は通常、5 時間分または 2 日分に相当するデータ消失など、時間に換算して測定されます。

毎分何百万ドルにも値する取引が発生する株式取引では、データの消失は許されません。したがって、RPO は 0（ゼロ）である必要があります。E-Commerce の例について考えると、Web ベースの販売システムでは、RPO が 0（ゼロ）であることは厳密に求められてはいませんが、顧客満足の点では RPO を低く抑えることが重要です。しかし、そのバックエンドの商品計画および在庫更新システムでは、RPO がこれより高い可能性があります。これは、消失したデータを再入力できるためです。

高可用性アーキテクチャの選択高可用性アーキテクチャの選択高可用性アーキテクチャの選択高可用性アーキテクチャの選択高可用性分析フレームワークを使用すると、ビジネスにおいて、ビジネスへの影響の分析を完了し、高可用性要件を持つ重要なビジネス・プロセスを識別して分類し、停止時間のコストを編成し、これらの様々なビジネス・プロセスに対する RTO 目標と RPO 目標を確立できます。

この結果ビジネスでは、ビジネスの重要な側面に対する高可用性に関して、品質保証契約（SLA）を定義できます。たとえば、そのビジネスを複数の HA 層に分類できます。

� 第 1 層のビジネス・プロセスは、ビジネスに大の影響を与えます。HA 要件はも厳しく、RTO および RPO は 0（ゼロ）に近く、サポートするシステムは継続的に使用できる必要があります。大容量の E-Commerce が存在するビジネスの場合、これは Webベースの顧客対話システムに該当する可能性があります。

� 第 2 層のビジネス・プロセスの HA および RTO/RPO 要件はそれほど厳しくありません。E-Commerce ビジネスの第 2 層は、サプライ・チェーン / 商品計画システムなどです。たとえば、これらのシステムでは、99.999% の可用性を保持する必要はなく、RTO/RPO の値は 0（ゼロ）以外でかまいません。したがって、ビジネスのこれらの 2つの層をサポートするために選択される HA システムおよびテクノロジは異なる可能性があります。

� 第 3 層のビジネス・プロセスは、社内の開発および品質保証プロセスに関連する場合があります。これらのプロセスをサポートするシステムは、他の層のような厳しい HA 要件は必要ありません。

ビジネスの次のステップは、様々な HA システムおよびテクノロジの機能を評価し、ビジネス・パフォーマンスの問題、予算的な制約および予測されるビジネスの成長によって指示されるガイドライン内で、その SLA 要件を満たす組合せを選択することです。

図 2-1 に、このプロセスを示します。



図図図図 2-1 可用性の高い企業の計画および実装可用性の高い企業の計画および実装可用性の高い企業の計画および実装可用性の高い企業の計画および実装

次の各項では、この方法について詳しく説明します。

� HA システムの機能

� ビジネス・パフォーマンス、予算および成長の計画

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


� 4-16 ページの表 4-3「品質保証契約と推奨 HA アーキテクチャ」

� 4-14 ページ「適切な HA アーキテクチャの選択」



HA システムの機能システムの機能システムの機能システムの機能現在は、広範囲にわたる高可用性およびビジネス継続ソリューションが存在します。これらのシステムの性質の高度化が進み、その範囲が拡大するとともに、データ記憶域、サーバー、ネットワーク、アプリケーションおよび設備など、さらに多くの IT インフラストラクチャで高可用性が実現しています。また、RTO および RPO は、日単位から時間単位、さらに分単位にまで短縮されています。しかし、可用性が高まるとともにコストが増加し、場合によっては、システム・パフォーマンスへの影響が大きくなります。

組織は、これらの HA システムの機能を慎重に分析し、その機能をビジネス要件に割り当てることで、ビジネスを継続できるように HA ソリューションの適な組合せを確保する必要があります。例として、重要な E-Commerce が存在するビジネスについて考えてみます。

このビジネスの場合、顧客が使用するシステムをサポートする IT インフラストラクチャである E-Commerce のコア・エンジンは、可用性が高く、障害を防止できる必要があります。このビジネスでは、E-Commerce エンジンを処理する Web サーバー、アプリケーション・サーバーおよびデータベース・サーバーのクラスタ化を考慮できます。組込みの冗長性を使用することで、クラスタ化ソリューションではシングル・ポイント障害がなくなります。また、近のクラスタ化ソリューションは、アプリケーションに対して透過的で、今後のビジネス成長に適応させるためのスケーラビリティを提供し、大量の通信量を処理するロード・バランシングを提供します。したがって、このようなクラスタ化ソリューションは、重要でトランザクションの多いアプリケーションに適です。

E-Commerce の大量のトランザクションをサポートするデータは、適切に保護され、計画外停止および計画的停止が発生した場合に、短の停止時間で使用できる必要があります。このデータは、ローカル・データ・センターで定期的にバックアップされるのみでなく、高速で冗長的なネットワークで接続されているリモート・データ・センターでデータベースにレプリケートされる必要があります。このリモート・データ・センターでは、セカンダリ・サーバーとデータベースが使用可能な状態であり、プライマリ・サーバーとデータベースが同期化されている必要があります。この結果、停止が発生した場合は、サーバーの再構築およびバックアップ・テープからのデータのリカバリを何時間も何日間も待機せずに、短の停止時間で即時にこれらのサーバーに切り替えることができます。

同期化されたリモート・データ・センターの保持は、システムのインフラストラクチャ全体に冗長性が構築される 1 つの例です。この例はコストがかかる場合があります。ただし、保護するシステムおよびデータが重要であることが、このコストを認める理由になります。ビジネスの別の側面について考えてみます。たとえば、クリックストリーム・データを収集し、データ・マイニングを実行するシステムの高可用性要件はあまり厳しくありません。停止時間のコストは低く、このシステムの RTO 要件および RPO 要件は数日でもかまいません。これは、このシステムが停止して一部のデータが消失した場合でも、ビジネスに悪影響を与えないためです。ビジネスではデータ・マイニングの実行に高性能のマシンを必要とする場合がありますが、このデータをリアルタイムにミラー化する必要はありません。データ保護は、定期的にバックアップを実行し、オフサイトでの保管用にテープをアーカイブすることで達成できます。

この E-Commerce ビジネスの場合、バックエンドの商品計画および在庫システムは、データ・マイニング・システムより高い HA 要件を設定することが期待されているため、定期的



なバックアップとオフサイトのアーカイブに加えて、ローカルのミラー化またはローカル・スナップショットなどのテクノロジを使用できます。

ビジネスでは、システム全体の管理、運営および監視を実行し、エグゼクティブ・ダッシュボードを提供する管理インフラストラクチャを使用する必要があります。この管理インフラストラクチャは可用性が高くフォルト・トレラントであることが必要です。

後に、外部および内部の不正な電子的攻撃から保護するには、この E-Commerce ビジネスの IT インフラストラクチャ全体が非常に安全であることが必要です。

ビジネス・パフォーマンス、予算および成長の計画ビジネス・パフォーマンス、予算および成長の計画ビジネス・パフォーマンス、予算および成長の計画ビジネス・パフォーマンス、予算および成長の計画高可用性ソリューションは、ビジネス・パフォーマンスの問題も考慮しながら選択する必要があります。たとえば、プライマリ・データベースのすべてのトランザクションをリモート・データベースに同期でミラー化する非データ消失ソリューションを使用できます。ただし、光速度の制限およびネットワークに関連する物理的な制限を考慮すると、ネットワーク転送にはラウンドトリップによる遅延があります。この遅延は距離に従って大きくなり、ネットワーク帯域幅、通信量の混雑、ルーターの待機時間などで変化します。したがって、大規模な WAN の範囲で実行された場合、この同期ミラー化はプライマリ・サイトのパフォーマンスに影響を与える可能性があります。オンライン購入者がこれらのシステム待機時間に気づき、長いシステム応答時間に不満を感じると、他の場所で購入する可能性があります。これは、非データ消失ソリューションの実現とシステム・パフォーマンスの大化の間にトレードオフが生じる例です。

高可用性ソリューションは、財務的な考慮事項および今後の成長見積りも考慮しながら選択する必要があります。IT インフラストラクチャ全体で冗長性を構築し、障害から完全に保護されていると宣言することは非常に魅力的です。しかし、このようなソリューションにこだわりすぎると、予算の超過のみでなく、統合やメンテナンスが非常に複雑で費用がかかり、管理が難しく拡張不可能なソリューションの組合せになる恐れがあります。

パフォーマンス・ベンチマーク結果が見事な HA ソリューションは、理論上は正しいように思われます。ただし、テクノロジの機能がビジネス運営者に見合っているどうかを慎重に分析せずにこのようなソリューションに投資すると、残りのシステム・インフラストラクチャとうまく統合されず、年 1 回の統合とメンテナンスのコストが先行投資のライセンス・コストを容易に上回り、ベンダーに拘束されるようなソリューションになる可能性があります。コストを意識したベテランの CIO は、適切に統合され、標準ベースであり、実装、メンテナンスおよび管理が容易で、今後のビジネス成長に対応するためのスケーラブルなアーキテクチャを持つソリューションにのみ投資します。



高可用性のベスト・プラクティス高可用性のベスト・プラクティス高可用性のベスト・プラクティス高可用性のベスト・プラクティスビジネスの可用性要件にも適したアーキテクチャを選択および実装することはわずらわしい作業です。このアーキテクチャは、適切な冗長性を包含し、あらゆる種類の停止からの十分な保護を提供し、一貫した高パフォーマンスと強固なセキュリティを保証する一方で、配置、管理および拡張が容易である必要があります。もちろん、このアーキテクチャは正しく理解されたビジネス要件によって処理される必要があります。

このようなアーキテクチャを作成、実装およびメンテナンスするには、IT システムとビジネス・プロセスの技術的および操作的の両方の側面を含んだ高可用性のベスト・プラクティスが必要です。このような一連のベスト・プラクティスでは、HA アーキテクチャの設計の複雑さが取り除かれ、低限のシステム・リソースで可用性が大化され、HA システムの実装およびメンテナンス・コストを削減し、ビジネスの他の領域で高可用性アーキテクチャを容易に複製できるようにします。

HA 分析フレームワーク、ビジネス運営者およびシステム機能を包含する、よく整理統合された一連の高可用性のベスト・プラクティスを持つ企業は、操作的なリジリエンスが向上し、ビジネスの敏捷性が強化されます。このマニュアルの残りの章では、Oracle によって提供される様々な高可用性テクノロジに関する技術的な詳細について、このようなテクノロジの構成および使用に関するベスト・プラクティスの推奨事項とともに説明します。

関連項目関連項目関連項目関連項目 : 第 5 章「高可用性の操作ポリシー」


第第第第 II 部部部部
Oracle Database の高可用性機能、の高可用性機能、の高可用性機能、の高可用性機能、
アーキテクチャおよびポリシーアーキテクチャおよびポリシーアーキテクチャおよびポリシーアーキテクチャおよびポリシー

第Ⅱ部では、主に Oracle Database の高可用性機能について説明し、Oracle の高可用性機能および製品を使用するアーキテクチャを示します。また、高可用性維持の重要な部分である操作ポリシーについても説明します。


� 第 3 章「Oracle Database の高可用性機能」



Oracle Database の高可用

3
Oracle Database の高可用性機能の高可用性機能の高可用性機能の高可用性機能
この章では、Oracle Database の高可用性機能について説明します。内容は次のとおりです。

� Oracle Real Application Clusters

� Oracle Data Guard

� Oracle Streams

� オンライン再編成

� トランスポータブル表領域

� Automatic Storage Management

� フラッシュバック・テクノロジ

� 動的再構成

� Oracle Fail Safe

� Recovery Manager

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

� Hardware Assisted Resilient Data（HARD）Initiative

性機能 3-1

Oracle Real Application Clusters

Oracle Real Application ClustersOracle Real Application Clusters（RAC）を使用すると、インターコネクトによってリンクされた複数のインスタンスで Oracle データベースへのアクセスを共有できます。この機能によって、障害の発生時に、高可用性、スケーラビリティおよび冗長性が RAC に提供されます。RAC では、スケーラビリティがアプリケーション・コードの変更なしに提供されます。

RAC は、読取り専用のデータ・ウェアハウス（DSS）システムから更新を主目的とするオンライン・トランザクション処理（OLTP）システム、また DSS と OLTP を組み合せたシステムまで、すべてのタイプのシステムに対応します。一般的な RAC 環境は、対称型マルチプロセッサで構成されます。

RAC には、次の利点があります。

� ノードおよびインスタンスの秒単位のフェイルオーバー

� 様々なインスタンス間で統合されたインテリジェントな接続およびサービスのフェイルオーバー

� ノード、インスタンスおよびサービスの計画的なスイッチオーバーおよびスイッチバック

� パッチのローリング・アップグレード

� 複数ノード間における複数アクティブ・インスタンスの可用性およびスケーラビリティ

� データベースおよびクラスタ機能を統合する包括的な管理

Oracle Data GuardOracle Data Guard は、Oracle の本番データベースで失敗、障害、エラーおよびデータ破損が発生した場合に処理を継続できるように、1 つ以上のスタンバイ・データベースを作成、メンテナンス、管理および監視する包括的な一連のサービスを提供します。これらのスタンバイ・データベースは、本番データベースのトランザクション一貫性のあるコピーとしてメンテナンスされます。本番データベースが計画的停止および計画外停止によって使用不可能になった場合、Data Guard はスタンバイ・データベースを本番のロールに切り替えることができるため、停止に伴う停止時間が小限になります。Data Guard を従来のバックアップ、リストアおよびクラスタ・テクノロジとともに使用すると、高いレベルのデータ保護およびデータ可用性を提供できます。

Data Guard 構成は、1 つの本番データベースと 1 つ以上のフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースで構成されます。Data Guard 構成のデータベースは、Oracle Net で接続され、地理的に分散している場合があります。互いに通信できる場所であれば、データベースの配置場所に制限はありません。たとえば、計画停止時間の管理を容易にするためにプライマリ・データベースと同じビル内に 1 つのスタンバイ・データベースを配置し、障害時リカバリで使用するために他の場所に 2 つ以上のスタンバイ・データベースを配置できます。


Oracle Data Guard

Data Guard には、次の利点があります。

� 障害時リカバリ、データ保護および高可用性

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

� 完全なデータ保護

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

� システム・リソースの効率的な使用方法

プライマリ・データベースから受信した REDO データで更新されたスタンバイ・データベース表は、バックアップ操作、レポート作成、要約および問合せなどの他のタスクにも使用できます。したがって、これらのタスクの実行に必要なプライマリ・データベースのワークロードを低減し、貴重な CPU と I/O のサイクルを節約できます。ロジカル・スタンバイ・データベースを使用すると、プライマリ・データベースから更新されていないスキーマ内の各表で通常のデータ操作を実行できます。ロジカル・スタンバイ・データベースは、表がプライマリ・データベースから更新されている間、オープン状態のままにしておくことができるため、表は読取り専用アクセスに同時に使用できます。後に、メンテナンスされている表に追加の索引やマテリアライズド・ビューを作成することによって、問合せパフォーマンスを改善し、特定のビジネス要件を満たすことができます。

� 可用性とパフォーマンス要件とのバランスを保つことができるデータ保護の柔軟性

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

� ギャップの自動検出と自動解消

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

Oracle Database の高可用性機能 3-3

Oracle Streams

� 集中化された単純な管理

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

� Oracle データベースとの統合

Oracle StreamsOracle Streams では、データベース内またはあるデータベースから別のデータベースへ、データ・ストリーム内のデータ、トランザクションおよびイベントの伝播と管理ができます。Oracle Streams では、一連の要素が提供されます。ユーザーは、これらの要素を使用して、ストリームに入れる情報、ストリームのノード間でのルーティング、各ノードに送られるストリーム内のイベントに発生する処理、およびストリームの終了方法を制御できます。

Oracle Streams を使用すると、データベースまたはデータベースのサブセットをレプリケートできます。この結果、複数のユーザーおよびアプリケーションが複数の場所でデータを同時に更新できます。ある場所で障害が発生した場合、障害のないサイトのユーザーおよびアプリケーションは、データへのアクセスおよび更新を継続できます。

Oracle Streams では、メッセージ・キューイングを使用して、アプリケーション・レベルで変更をレプリケートする分散アプリケーションを構築できます。アプリケーションで障害が発生した場合、障害のないアプリケーションは継続して動作し、ローカルに保持されているコピーを使用してデータへのアクセスを提供できます。

Oracle Streams では細分化が提供され、レプリケート対象およびレプリケート方法が制御されます。双方向レプリケーション、データ変換、サブセット化、カスタムの適用機能および異機種間プラットフォームがサポートされます。また、プライマリ・データベースからレプリカ・データベースへの変更レコードのルーティングはユーザーが完全に制御できます。

関連項目関連項目関連項目関連項目 : 『Oracle Data Guard 概要および管理』

関連項目関連項目関連項目関連項目 : 『Oracle Streams 概要および管理』


オンライン再編成

オンライン再編成オンライン再編成オンライン再編成オンライン再編成データベース管理者は、ヒープ構成表のオンライン再編成など、表定義に対する様々なオンライン操作を実行できます。ユーザーが表にフル・アクセスしている間でも表を再編成できます。

このオンライン・アーキテクチャには、次の利点があります。

� 表のあらゆる物理属性をオンラインで変更できます。表は新しい場所に移動できます。また、パーティション化できます。さらに、あるタイプの編成（ヒープ構成など）から別のタイプの編成（索引構成など）に変換できます。

� 多数の論理属性も変更できます。列名、列型および列サイズを変更できます。また、列の追加、削除またはマージが可能です。制限事項として、表の主キーは変更できません。

� 索引構成表の 2 次索引をオンラインで作成および再作成できます。2 次索引により、ブロック・ヒント（物理推測）の効果的な使用がサポートされます。無効な物理推測はオンラインで修復できます。

� 索引のオンライン作成および分析を同時に実行できます。（索引構成表の 2 次索引およびマッピング表で使用される）論理 ROWID の物理推測コンポーネントをオンラインで修正することもできます。

� 索引構成表の 2 次索引に格納された論理 ROWID の物理推測コンポーネントを修正できます。これにより、無効な物理推測のオンラインでの修復が可能になります。

� 索引構成表または索引構成表のパーティションを、その 2 次索引を再作成せずに再編成できます。この結果、再編成のメンテナンス期間が短くなります。

� 索引構成表をオンラインで再編成できます。2 次索引のオンライン再編成とともに、この機能によって再編成メンテナンス期間が不要になります。

関連項目関連項目関連項目関連項目 : 『Oracle Database 管理者ガイド』


トランスポータブル表領域

トランスポータブル表領域トランスポータブル表領域トランスポータブル表領域トランスポータブル表領域トランスポータブル表領域機能を使用すると、Oracle データベース間で表領域を迅速に移動できます。これは、データベース間でバルク・データを移動するも効率的な方法です。

同じデータのエクスポート / インポートやアンロード / ロードを使用するよりも、トランスポータブル表領域を使用してデータを移動するほうが高速です。これは、表領域のトランスポートでは、データファイルをコピーして表領域の構造情報を統合するのみで済むためです。また、トランスポータブル表領域を使用して索引データを移動することで、表データのインポート時やロード時に必要となる索引の再作成を回避することもできます。

プラットフォーム間で表領域をトランスポートできます。この機能を使用すると、次のことが可能になります。

� コンテンツ・プロバイダは、容易にかつ効率的に構造化データを公開し、別のプラットフォームで Oracle を実行している顧客に配布できます。

� データ・ウェアハウス環境からデータ・マート（多くの場合、様々なプラットフォームの小規模システムで実行されている）へのデータの配布を簡素化できます。

� 異機種のクラスタ間で読取り専用表領域を共有できます。

� データベースをプラットフォーム間で移行できます。

大抵のプラットフォームでは、クロス・プラットフォームでの表領域のトランスポートがサポートされます。V$TRANSPORTABLE_PLATFORMビューを問い合せると、サポートされているプラットフォームを参照して、そのプラットフォーム ID と endian 形式（バイト順序）を確認できます。



Automatic Storage Management

Automatic Storage ManagementAutomatic Storage Management（ASM）は、データファイル、制御ファイル、REDO ログ・ファイル、およびシングル・インスタンス・データベースと RAC データベースの両方に対するフラッシュ・リカバリ領域ファイルの適なレイアウトを自動化および簡素化します。ASM は、非管理ディスクから SAN ベースのインテリジェントなストレージ・アレイまで、あらゆるタイプのストレージで動作するように設計されています。

ASM は、使用可能なすべてのディスク全体にデータベース・ファイルを自動的に分散することによってパフォーマンスを大にします。データベース記憶域は、記憶域構成が変更されるたびに、データベースはオンラインのままで自動的に再調整されます。この機能によって記憶域の断片化が解消されるため、データを手動で再割当てして領域を再生する必要はありません。

ASM は、データの冗長コピー（ミラー）をメンテナンスすることによってデータを保護します。保護およびストライプ化の方針をファイルごとに定義すると、同じディスク・セット内でストライプ化される様々なレベルの保護が可能です。

ASM のディスク・グループ（ディスクとそのディスク上のファイルで構成）によって、ディスクの集合を 1 つの単位として管理できるため、記憶域管理が簡素化されます。ASMの障害グループを使用すると、ディスク・グループ内のディスクを、障害により許容される必要がある共通リソースを共有するディスク・セットに細分化できます。障害グループの例に、共通の SCSI コントローラに接続されている一連の SCSI ディスクがあります。



フラッシュバック・テクノロジ

フラッシュバック・テクノロジフラッシュバック・テクノロジフラッシュバック・テクノロジフラッシュバック・テクノロジ人為的なエラーは、回避することが難しく、計画性や正しいテクノロジがない状態では特にリカバリが困難な場合があります。このようなエラーは、論理データの破損につながり、ITインフラストラクチャの 1 つ以上のコンポーネントが停止する原因となります。個々のコンポーネントの障害を修復するのは比較的容易であるのに対して、重要なデータを誤って削除した場合など、論理的なデータの破損の検出と修復は、ビジネスの生産性に多大な損失を与える時間のかかる作業です。

フラッシュバック・テクノロジでは、時間でデータの表示および巻戻しと先送りをする一連の機能が提供されています。フラッシュバック機能には、スキーマ・オブジェクトの過去のバージョンの問合せ、履歴データの問合せ、変更分析の実行およびデータベースがオンライン中に論理破損からリカバリするセルフサービス修復の実行などの機能があります。

フラッシュバック・テクノロジには、人為的なエラーを迅速に分析および修復するためのSQL インタフェースが用意されています。顧客からの誤った注文を削除するなど、範囲が限定されているダメージに対して詳細な分析および修復が提供されます。フラッシュバック・テクノロジでは、より広範囲にわたるダメージの修復も可能ですが、この修復は停止時間が長くならないように迅速に行われます。また、フラッシュバックは Oracle Database に固有のテクノロジであり、行、トランザクション、表、表領域およびデータベースなど、すべてのレベルでリカバリがサポートされています。

Oracle Flashback QueryOracle Flashback Query を使用すると、ターゲット時間を指定してデータベースに対する問合せを実行し、その時点で表示されていたとおりの結果を表示できます。表を誤って更新するなどの意図していない変更からリカバリするために、エラー前のターゲット時間を選択し、問合せを実行して、失われた行の内容を取り出すことができます。

Oracle Flashback Version QueryOracle Flashback Version Query では、特定の時間間隔のメタデータおよび履歴データが取得されます。特定の時間間隔の間に存在していた表のすべての行を参照できます。行の様々なバージョンに関するメタデータには、開始時間と終了時間、変更操作のタイプおよび行バージョンを作成したトランザクションの識別情報が含まれます。


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

� 『Oracle Database SQL リファレンス』


フラッシュバック・テクノロジ

Oracle Flashback Transaction QueryOracle Flashback Transaction Query では、特定のトランザクション、または特定の時間間隔内のすべてのトランザクションに関するメタデータおよび履歴データが取得されます。SQLコードを取得すると、トランザクションによって処理された特定の行の変更を元に戻すこともできます。フラッシュバック・トランザクション問合せは通常、目的の行のトランザクション ID を提供するフラッシュバック・バージョン問合せとともに使用します。

Oracle Flashback TableOracle Flashback Table は、表を以前のある時点の状態にリカバリします。データベースをオンラインにしたままで、指定した表に対する変更のみを元に戻し、表のデータをリストアできます。

Oracle Flashback DropOracle Flashback Drop は、削除された表をリカバリします。DROP TABLE文の効果を元に戻します。

Oracle Flashback DatabaseOracle Flashback Database は、データベースの Point-in-Time リカバリに対するさらに効率的な代替機能を提供します。Flashback Database を使用すると、現在のデータファイルの内容が過去のある時点の内容に戻ります。結果はデータファイルのバックアップと REDO ログを使用した Point-in-Time リカバリとほぼ同様ですが、データファイルをバックアップからリストアする必要はなく、また従来のメディア・リカバリで再適用する必要があったREDO ログ内の多数の個別変更を再適用する必要はありません。


動的再構成

動的再構成動的再構成動的再構成動的再構成Oracle データベースには、インスタンス構成を動的に変更できる機能がいくつか用意されています。たとえば、動的な SGA インフラストラクチャを使用すると、インスタンスのメモリー使用量を変更できます。インスタンスを停止することなく、バッファ・キャッシュ、共有プール、ラージ・プールおよびプロセス・プライベート・メモリーのサイズ変更が可能です。Oracle では、プライベート・メモリーの割当てを制御する初期化ランタイム・パラメータの自己チューニングによって、SQL 実行に必要な作業メモリーの透過的な管理も提供します。

Oracle がオペレーティング・システムをポーリングして使用できる CPU 数の変化を検出し、内部リソースを再割当てする場合は、別のタイプの動的再構成が発生します。

また、一部の初期化パラメータは、インスタンスを停止せずに変更できます。ALTER SESSION文を使用すると、セッションの存続中にパラメータの値を変更できます。ALTER SYSTEM文を使用すると、インスタンスのすべてのセッションに対するパラメータの値を、インスタンスの存続中にかぎり変更できます。

Oracle Fail SafeOracle Fail Safe は、Microsoft Cluster Server（MSCS）とともに動作するソフトウェア・オプションで、Microsoft クラスタ上で高い可用性を実現するビジネス・ソリューションです。Microsoft クラスタは、ネットワーク・ユーザーからは可用性の高い単一システムのように見える 2 つ以上の Windows システムで構成されています。

Oracle Fail Safe は MSCS クラスタ・ソフトウェアとともに、クラスタ上で実行されるアプリケーションおよびシングル・インスタンス・データベースの高い可用性を実現します。あるノードに障害が発生した場合は、Oracle Fail Safe を使用して構成したパラメータに基づき、クラスタ・ソフトウェアによって、障害のないノードにフェイルオーバーされます。

Oracle Fail Safe によって、シングル・インスタンスの Oracle データベース、Oracle HTTP Server および Microsoft Windows サービスとして構成可能な大抵のアプリケーションの停止時間を短縮できます。


� 動的な SGA インフラストラクチャの詳細は、『Oracle Database 概要』を参照してください。

� 動的初期化パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : Oracle Fail Safe に関するドキュメントは、http://otn.oracle.co.jp/document/index.htmlを参照してください。


Recovery Manager

Recovery Managerデータベースのバックアップ、リストアおよびリカバリは、高可用性システムの基礎となる必須プロセスです。たとえば、ディスク障害または人為的エラーによって、収益が得られなくなる、顧客が満足しない、情報がリカバリできなくなる可能性があることを想像してくだい。正しく設計され、正しく実施されたバックアップおよびリカバリ計画はすべてのデータベース配置の基礎であり、データを消失せずにデータベース全体または一部のリストアおよびリカバリを可能にします。

Recovery Manager（RMAN）は、データベースのバックアップ、およびさらに重要なリカバリを管理する Oracle のユーティリティです。操作の複雑性を解消するとともに、データベースの優れたパフォーマンスと可用性を実現します。

Recovery Manager は、要求されたバックアップ、リストアまたはリカバリ操作を実行するも効率的な方法を判断して、Oracle データベース・サーバーを使用してこれらの操作を実

行します。Recovery Manager とサーバーは、データベースの構造に対する変更を自動的に識別し、必要な操作を動的に調整してその変更に適応させます。

Recovery Manager には、次の利点があります。

� ブロック・メディア・リカバリを使用すると、データファイルをオンラインにしたままでブロック破損を修復できます。

� 永続的 Recovery Manager 構成によって、バックアップおよびリカバリ操作が簡素化されます。

� 保存方針によって、関連バックアップが保存されることが保証されます。

� 再開可能バックアップでは、以前の失敗したバックアップ操作でバックアップされなかったファイルがバックアップされます。

� 再開可能リストアでは、リカバリが必要なファイルのみをリストアすることによってリカバリ時間が短縮されます。

� バックアップの適化では、バックアップが必要なファイルでまだ 1 度もバックアップされていないファイルのみがバックアップされます。

� リストアの適化によって、データファイルおよびアーカイブ・ログのリストアで推測作業が排除されます。Recovery Manager は必要な場合のみリストアを実行します。

� 制御ファイルおよびサーバー・パラメータ・ファイルを自動バックアップすると、バックアップ・メタデータを、メディア障害やその他の障害時のみでなく、データベース構造の変更時にも使用できます。

� 「データベースがリカバリ可能であるか」という問に対する回答を示すレポート作成機能があります。

� マルチ・ブロック・サイズ・バックアップがサポートされます。

� オンライン・バックアップで、データベースをホット・バックアップ・モードにする必要はありません。


フラッシュ・リカバリ領域

� 迅速な増分バックアップを実行できます。

� バックアップ、アーカイブ REDO ログおよびフラッシュバック・ログなど、すべてのリカバリ関連ファイルを再編成および管理できます。

� Recovery Manager の増分バックアップとバックアップ内のイメージ・コピーをマージすると、新のリカバリ能力を提供できます。

フラッシュ・リカバリ領域フラッシュ・リカバリ領域フラッシュ・リカバリ領域フラッシュ・リカバリ領域フラッシュ・リカバリ領域は、Oracle データベースにおけるリカバリ関連ファイルとアクティビティ用の統合された格納場所です。1 つの初期化パラメータを定義することで、Recovery Manager のすべてのバックアップ、アーカイブ・ログ、制御ファイルの自動バックアップおよびデータファイルのコピーが、指定したファイル・システムまたは Automatic Storage Management のディスク・グループに自動的に書き込まれます。

ディスクへのバックアップの作成は、フラッシュ・リカバリ領域を使用することでテープへの書込みのボトルネックがなくなるため時間が短縮されます。さらに重要なことは、データベースのメディア・リカバリが必要な場合に、データファイルのバックアップを容易に使用できることです。必要なデータファイルおよびアーカイブ・ログをリストアするために、テープや空きテープ・デバイスを探す必要がないため、リストアおよびリカバリ時間が短縮されます。

フラッシュ・リカバリ領域によって次の機能が提供されます。

� 関連リカバリ・ファイルの統合された格納場所

� リカバリ・ファイル用に割り当てられたディスク領域の管理

� データベース管理タスクの簡素化

� 高速バックアップ

� 高速リストア

� ディスク本来の信頼による信頼性

関連項目関連項目関連項目関連項目 : 『Oracle Database バックアップおよびリカバリ基礎』


Hardware Assisted Resilient Data（HARD）Initiative

Hardware Assisted Resilient Data（（（（HARD））））Initiativeオラクル社は、Hardware Assisted Resilient Data（HARD）Initiative を導入しています。このプログラムは、データ破損を未然に防止するために設計されています。データ破損が発生することはほとんどありませんが、発生した場合は、データベースおよびビジネスに致命的な影響を与える可能性があります。

HARD Initiative のもとで、オラクル社は、選ばれたシステム・ベンダーとストレージ・ベンダーと協力して、早期に破損を検出し、破損したデータのディスクへの書込みを防止するオペレーティング・システムとストレージ・コンポーネントの構築に取り組み続けています。主な方法はブロック・チェックで、ストレージ・サブシステムによって Oracle ブロックの内容を検証します。この機能の実装は、ハードウェア・ベンダーにかかわらず、エンド・ユーザーや DBA に対して透過的です。

関連項目関連項目関連項目関連項目 : 付録 A「Hardware Assisted Resilient Data（HARD）Initiative」


Hardware Assisted Resilient Data（HARD）Initiative


高可用性アーキテク

4
高可用性アーキテクチャ高可用性アーキテクチャ高可用性アーキテクチャ高可用性アーキテクチャ
この章では、Oracle 環境の高可用性アーキテクチャについて説明します。内容は次のとおりです。

� Oracle Database の高可用性アーキテクチャ

� 適切な HA アーキテクチャの選択

� その他のアーキテクチャの評価

チャ 4-1

Oracle Database の高可用性アーキテクチャ

Oracle Database の高可用性アーキテクチャの高可用性アーキテクチャの高可用性アーキテクチャの高可用性アーキテクチャこの項では、高可用性に関する様々なビジネス・ニーズに対応する 5 つの主要なデータベース・アーキテクチャを定義します。説明するアーキテクチャは次のとおりです。

� データベースのみデータベースのみデータベースのみデータベースのみ : スタンドアロン・マシン上に単一インスタンスの本番データベースがあり、Oracle データベースに備わっている HA 機能をすべて使用します。フラッシュバック・テクノロジによって、ユーザー・エラーおよび論理的なエラーから迅速にリカバリできます。オンライン再定義および再編成によって、ほとんどの計画的なメンテナンス・アクティビティの停止時間を短縮できます。Recovery Manager を使用したOracle の高度なバックアップおよびリカバリ・フレームワークは、各顧客のリカバリ要件にあわせてカスタマイズできます。

� RAC のみのみのみのみ : RAC データベースを使用するアーキテクチャです。RAC 環境では、クラスタ内の計画的停止および計画外停止の両方に対してサービスが継続的に提供されます。ノードまたはインスタンスで障害が発生すると、アプリケーション・サービスによって、既存の RAC インスタンスに迅速かつ透過的にフェイルオーバーされます。

� Data Guard のみのみのみのみ : プライマリ・サイトに本番データベースがあります。セカンダリ・サイトには 1 つ以上のスタンバイ・データベースがあります。プライマリ・サイトの障害またはデータベースの障害あるいはローカル・サイトですぐには解決できないその他の障害が発生した場合は、Data Guard を使用するとスタンバイ・データベースにフェイルオーバーまたはスイッチオーバーできます。

� Maximum Availability Architecture（（（（MAA））））: プライマリ・サイトには RAC 本番データベースがあります。セカンダリ・サイトには、ロジカル・スタンバイ・データベースとフィジカル・スタンバイ・データベースの両方をホスティングするクラスタがあります。このアーキテクチャでは、RAC アーキテクチャと Data Guard アーキテクチャの両方の機能および利点が継承されるため、計画外停止および計画的停止の両方に対して、も包括的な一連のソリューションが提供されます。

� Streams: プライマリ・サイトには本番データベースがあります。セカンダリ・サイトには、Streams テクノロジを使用したレプリケート・データベースがあります。両方のサイトをアクティブにでき、トランザクションを双方向で同期化できます。プラットフォームは異機種でもかまいません。

Oracle は広範囲にわたる多数の HA アーキテクチャ・ソリューションを提供しています。データベースのみのアーキテクチャの可用性は高くありませんが、他のすべてのアーキテクチャで使用される多数の可用性機能および利点が含まれています。データベースのみのアーキテクチャは、ほとんどの顧客にとって開始点となるアーキテクチャです。RAC のみ、Data Guard のみおよび Streams のアーキテクチャでは、データベースのみの機能に加えて、その他の HA 機能が提供されます。MAA では RAC と Data Guard の両方の利点が取り込まれ、可用性が大のアーキテクチャが提示されます。図 4-1 に、様々な HA アーキテクチャの階層を示します。



図図図図 4-1 HA アーキテクチャの階層アーキテクチャの階層アーキテクチャの階層アーキテクチャの階層

次の各項では、それぞれのアーキテクチャとその利点を詳しく説明します。

� データベースのみのアーキテクチャ

� RAC のみのアーキテクチャ

� Data Guard のみのアーキテクチャ

� Maximum Availability Architecture

� Streams アーキテクチャ

高可用性アーキテクチャ 4-3


データベースのみのアーキテクチャデータベースのみのアーキテクチャデータベースのみのアーキテクチャデータベースのみのアーキテクチャOracle には、どのデータベース・アーキテクチャでも使用できる HA 機能が備わっています。これらの機能によって、単一マシン上のスタンドアロン・データベースが使用しやすく便利になります。これらの機能については表 4-1 で説明します。第 9 章「停止からのリカバリ」では、様々な停止を解決するためにこれらの機能をどのような場合に使用するかを説明し、第 10 章「リカバリ手順の詳細」では、これらの機能を使用したリカバリ方法を詳しく説明します。

表表表表 4-1 Oracle Database の高可用性機能の高可用性機能の高可用性機能の高可用性機能

機能機能機能機能説明説明説明説明

アプリケーションおよび Oracle アップグレードの

ための停止時間の短縮

� アップグレード時にオンライン再定義を迅速に実行するために、データベース・オブジェクトのクローンを 1 ステッ

プで作成します。

� 基礎となるオブジェクトの変更後も PL/SQL パッケージは

無効になりません。

� ビジー表のデータ定義言語（DDL）ロックを処理します。

ユーザー・エラーおよび論理的な破損から保護するフラッシュバック機能

� フラッシュバック・バージョン問合せでは、特定の時間間隔のメタデータおよび履歴データが取得されます。

� フラッシュバック・トランザクション問合せでは、特定のトランザクション、または特定の時間間隔内のすべてのトランザクションに関するメタデータおよび履歴データが取得されます。

� フラッシュバック・テーブルは、表を以前のある時点の状態にリカバリします。

� フラッシュバック・ドロップは、削除された表をリカバリします。

� フラッシュバック・データベースは、データベースのPoint-in-Time リカバリに対するさらに効率的な代替機能

を提供します。



オブジェクト構造またはアプリケーションの変更に伴う計画的な停止時間をなくすまたは小限にするためのオンライン再定義および再構成

� 表のあらゆる物理属性をオンラインで変更できます。表は新しい場所に移動できます。また、パーティション化できます。さらに、あるタイプの編成（ヒープ構成など）から別のタイプの編成（索引構成など）に変換できます。

� 多数の論理属性も変更できます。列名、列型および列サイズを変更できます。また、列の追加、削除またはマージが

可能です（表の主キーは変更できません）。

� 索引構成表（IOT）の 2 次索引を作成および再作成できま

す。2 次索引により、ブロック・ヒント（物理推測）の効

果的な使用がサポートされます。無効な物理推測はオンラインで修復できます。

� 索引のオンライン作成および分析を同時に実行できます。

� CLOBおよび BLOBデータ型のサポートが拡張されていま

す。

バックアップおよびリカバリ操作の自動管理 � ディスクベースの自動バックアップおよびリカバリ。バックアップ、アーカイブ REDO ログ、フラッシュバック・

ログ、およびリカバリに必要なその他のファイルに対して、単純化および統合された格納場所が提供されます。

� Recovery Manager のバックアップ機能。バックアップ・

スタンバイ制御ファイルのサポート、バックアップ・ファイルのカタログ化の簡素化、ディスクへのバックアップの簡素化、増分バックアップの改善によるデータファイルの全体スキャンの回避などがあります。

� Recovery Manager のリカバリ機能。リカバリ時の自動

ファイル作成、リセットログを使用したリカバリの簡素化、および様々な時点にフラッシュバックしてリカバリする機能などがあります。

高速および効率的なオブジェクト再作成機能 Data Pump

起動時のファスト・スタート・リカバリファスト・スタート・チェックポイントを使用すると、インスタンスのリカバリ時間を短縮できます。

Oracle Enterprise Manager を使用した簡潔で統合

された管理フレームワーク

� インストール、設定および構成用の簡単な GUI。

� 監視および管理方法の統合。

表表表表 4-1 Oracle Database の高可用性機能の高可用性機能の高可用性機能の高可用性機能（続き）（続き）（続き）（続き）

機能機能機能機能説明説明説明説明



RAC のみのアーキテクチャのみのアーキテクチャのみのアーキテクチャのみのアーキテクチャRAC のみのアーキテクチャは、Real Application Clusters を使用する本質的に可用性の高いシステムです。RAC 環境における一般的なクラスタでは、計画的停止および計画外停止の両方に対してサービスが継続的に提供されます。RAC は、Oracle の標準機能の上に高いレベルの可用性を構築します。フラッシュバック・テクノロジやオンライン再編成など、シングル・インスタンスのすべての HA 機能は RAC にも適用されます。

標準の Oracle 機能に加えて、RAC は、クラスタ化によって提供される冗長性を利用して、n ノードのクラスタ内で n - 1 ノードに障害が発生した場合でも可用性を提供します。つまり、すべてのユーザーは、クラスタ内に 1 つでも使用可能なノードがあれば、すべてのデータにアクセスできます。

このアーキテクチャには次の利点があります。

� ノードおよびインスタンスの高速フェイルオーバー（秒単位）

� 様々なインスタンス間で統合されたインテリジェントな接続およびサービスのフェイルオーバー

� ノード、インスタンスおよびサービスの計画的なスイッチオーバーおよびスイッチバック

� パッチのローリング・アップグレード

� 複数ノード間における複数アクティブ・インスタンスの可用性およびスケーラビリティ

� データベースおよびクラスタ機能を統合する包括的な管理

図 4-2 に、RAC のみのアーキテクチャを示します。



図図図図 4-2 RAC のみのアーキテクチャのみのアーキテクチャのみのアーキテクチャのみのアーキテクチャ



Data Guard のみのアーキテクチャのみのアーキテクチャのみのアーキテクチャのみのアーキテクチャData Guard では、豊富な一連の HA ソリューションが提供され、障害時リカバリ・ソリューションに対するビジネス・コミュニティの要件が処理されます。Data Guard（REDO Apply）テクノロジおよび Data Guard（SQL Apply）テクノロジがサポートされており、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースという異なる 2 種類のスタンバイ・データベースを使用できます。

フィジカル・スタンバイ・データベースによって、Oracle バージョン 6 以降、多数のアプリケーションに HA ソリューションが提供されています。Oracle8i では Oracle Data Guard が導入され、Oracle9i と Oracle Database 10g のリリースでさらに拡張機能が加わり、単純で高度な HA セットが提供されるようになりました。Data Guard のフィジカル・スタンバイ・アーキテクチャは、も効率的で単純なスタンバイ・データベース環境です。Oracle9i で導入されたロジカル・スタンバイ・データベースでは、トランザクションのリカバリ中に、同じデータベースで読取り / 書込み操作を同時に実行できます。ロジカル・スタンバイ・データベースでは追加の処理が必要ですが、一部のアプリケーションでは適な HA ソリューションであり、他のソリューションを捕捉することもできます。顧客によっては、HA ソリューションの一部としてフィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方を使用できる場合があります。これは MAA の推奨構成です。フィジカル・スタンバイ・データベースはスイッチオーバーおよびフェイルオーバーの初のターゲットになり、ロジカル・スタンバイ・データベースは、レポート作成、問合せ、および本番データベースの負荷を軽減するためのその他の処理に使用されます。ロジカル・スタンバイ・データベースは、スイッチオーバー、フェイルオーバーおよびデータベースのローリング・アップグレードのターゲットにもなります。

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

� ユーザー・エラーおよび論理的な破損からの保護

� リモートに配置されている場合のサイト障害およびその他の障害からの保護

� サイトおよびデータベースの高速フェイルオーバー（分単位）

� メンテナンスのためのサイトおよびデータベースの計画的な高速スイッチオーバー

� バックアップを本番データベースのかわりにフィジカル・スタンバイ・データベースから取得することによる、本番データベースの負荷の軽減

� システム・リソースの有効利用につながる読取り専用機能

障害時リカバリおよびデータ保護に加えて、ロジカル・スタンバイ・データベースには次の利点があります。

� 通常の操作に対してスタンバイ・データベースをオープンしたままで、読取り専用と読取り / 書込みの両方が可能です。

� 追加オブジェクトを作成およびメンテナンスできます。

� 本番データベースでデータベースのローリング・アップグレードが可能です。



多くの場合、推奨構成には、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方が含まれます。これらは、同じデータベース・マシンまたはクラスタ上に常駐できますが、本番データベースからは離れた位置にある必要があります。フィジカル・スタンバイ・データベースは障害時のフェイルオーバー用に確保し、ロジカル・スタンバイ・データベースはレポート作成用に継続して使用できます。フィジカル・スタンバイ・データベースでは、REDO ログを SQL に変換する必要がないため、より速い適用テクノロジが提供されます。

図 4-3 は、プライマリ・サイトの本番データベースとセカンダリ・サイトのスタンバイ・データベースを示しています。

図図図図 4-3 プライマリ・サイトとセカンダリ・サイトのプライマリ・サイトとセカンダリ・サイトのプライマリ・サイトとセカンダリ・サイトのプライマリ・サイトとセカンダリ・サイトの Data Guard のみのアーキテクチャのみのアーキテクチャのみのアーキテクチャのみのアーキテクチャ



Maximum Availability ArchitectureRAC と Data Guard によって、データベースの MAA ソリューションの基礎が提供されます。MAA では、計画的停止時間の短縮、および計画外停止の防止、検出、リカバリを実現するためのも包括的なアーキテクチャが提供されます。推奨 MAA には、2 つの同一サイトがあります。プライマリ・サイトには RAC データベースが含まれ、セカンダリ・サイトには、RAC のフィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方が含まれます。

フェイルオーバーまたはスイッチオーバー後にパフォーマンスが低下しないようにするには、同一のサイト構成をお薦めします。対称型サイトでは、サイト間で処理や手順も同一にできるため、操作タスクの維持および実行が容易になります。

図 4-4 に、アーキテクチャの概要を示します。


� ロジカル・スタンバイ・データベースでサポートされるデータ型の詳細は、『Oracle Data Guard 概要および管理』を参照してください。

� スタンバイ・データベースに関するドキュメントは、http://otn.oracle.co.jp/document/index.htmlを参照してください。



図図図図 4-4 Maximum Availability Architecture



Streams アーキテクチャアーキテクチャアーキテクチャアーキテクチャStreams は、情報の共有および分散を目的としています。また、効率的で可用性の高いアーキテクチャを提供できます。

Oracle Streams では細分化が提供され、レプリケート対象およびレプリケート方法が制御されます。双方向レプリケーション、データ変換、サブセット化、カスタムの適用機能および異機種間プラットフォームがサポートされます。また、プライマリ・データベースからレプリカ・データベースへの変更レコードのルーティングはユーザーが完全に制御できます。この結果、ユーザーは多数のレプリカ・データベースをサポートできるハブ・アンド・スポーク・ネットワーク構成を構築できます。

次の条件の 1 つ以上に該当する場合は、Streams を評価する必要があります。

� 双方向の変更も含めて、完全なアクティブ / アクティブ・サイト構成が必要な場合

� サイト構成が異機種間プラットフォーム上にある場合

� 情報およびデータの共有を細かく制御する必要がある場合

� 統合 HA ソリューションの構築にさらに投資が可能な場合

障害時リカバリについては、Data Guard が推奨する障害時リカバリ・ソリューションです。

図 4-5 に、Streams のアーキテクチャを示します。



図図図図 4-5 HA 環境での環境での環境での環境での Streams の使用の使用の使用の使用


適切な HA アーキテクチャの選択

適切な適切な適切な適切な HA アーキテクチャの選択アーキテクチャの選択アーキテクチャの選択アーキテクチャの選択この項では、この章で説明した HA アーキテクチャの利点を要約し、ビジネスに適した HAアーキテクチャを選択するためのガイドラインを示します。

表 4-2 に、この章で説明した 5 つの基本 HA アーキテクチャの利点を要約します。

表表表表 4-2 HA アーキテクチャの利点アーキテクチャの利点アーキテクチャの利点アーキテクチャの利点

データベースのデータベースのデータベースのデータベースの HA アーキテクチャアーキテクチャアーキテクチャアーキテクチャ利点利点利点利点

データベースのみデータベースのみデータベースのみデータベースのみ

スタンドアロン・マシン上の本番データベース

アプリケーションおよび Oracle アップグレードのための停止時間の短縮

フラッシュバック機能によるユーザー・エラーおよび論理的な破損からの保護

オンライン再定義および再構成による計画的停止時間の短縮

バックアップおよびリカバリ機能

高速および効率的なオブジェクト再作成機能

Oracle Enterprise Manager を使用した簡潔で統合された管理フレームワーク

注意注意注意注意 : これらの利点はすべて、この表内の他のアーキテクチャでも使用可能

ですが、繰り返し記述されません。

RAC のみのみのみのみ

RAC 本番データベース

RAC の HA の利点

アプリケーションに対して透過的

関連項目関連項目関連項目関連項目 : 4-6 ページの「RAC のみのアーキテクチャ」を参照してください。

Data Guard のみのみのみのみ

プライマリ・サイト上の（RAC 以外

の）本番データベース

セカンダリ・サイトまたは障害時リカバリ・サイト上のスタンバイ・データベース

Data Guard の HA の利点


関連項目関連項目関連項目関連項目 : 4-8 ページの「Data Guard のみのアーキテクチャ」を参照してく

ださい。



RAC のみおよび Data Guard のみは、も一般的な Oracle HA アーキテクチャで、それぞれに重要な HA の利点があります。MAA は、も冗長で堅牢な HA アーキテクチャを提供します。このアーキテクチャは、メンテナンスのための停止時間をなくすまたは小限にするのみでなく、様々な停止を防止、検出し、短い平均リカバリ時間（MTTR）内でリカバリします。Streams アーキテクチャは、もう 1 つの高可用性ソリューションですが、さらにカスタマイズが必要であり、アプリケーションに対して透過的でない場合があります。

どの HA アーキテクチャを実装するかを決定するときに、品質保証契約を考慮する必要があります。RAC または Data Guard が含まれる Oracle HA アーキテクチャを実装するかどうかを決定するには、品質保証契約に関する次の質問事項を考慮してください。

1. 本番システムが 1 日 24 時間、毎週 7 日間、毎年 365 日稼働している必要があるかどうか。

2. 計画的なメンテナンスが現在、サービス・レベルを超えていないかどうか。

3. 障害時リカバリが必要かどうか。

表 4-3 に、これらの質問に対する各回答のセットについて、推奨アーキテクチャを示します。

MAA

プライマリ・サイト上の RAC 本番

データベース

セカンダリ・サイトまたは障害時リカバリ・サイト上のスタンバイ・データベース

RAC の HA の利点

Data Guard の HA の利点


関連項目関連項目関連項目関連項目 : 4-6 ページの「RAC のみのアーキテクチャ」および 4-8 ページの

「Data Guard のみのアーキテクチャ」を参照してください。

Streams

プライマリ・サイト : 本番データ

ベース

セカンダリ・サイトまたは追加サイト : Streams を使用してレプリケート

されたデータベース

完全なアクティブ / アクティブ構成

データベース構成が異機種間プラットフォームでも可

関連項目関連項目関連項目関連項目 : 4-12 ページの「Streams アーキテクチャ」を参照してください。

表表表表 4-2 HA アーキテクチャの利点（続き）アーキテクチャの利点（続き）アーキテクチャの利点（続き）アーキテクチャの利点（続き）

データベースのデータベースのデータベースのデータベースの HA アーキテクチャアーキテクチャアーキテクチャアーキテクチャ利点利点利点利点



ビジネスで次の機能を必要とする場合は、Oracle Streams をさらに詳細に評価する必要があります。

� 双方向レプリケーションによる完全なアクティブ / アクティブ・サイト構成

� サイト間の異機種間プラットフォーム

� 情報およびデータの共有の詳細な制御

表表表表 4-3 品質保証契約と推奨品質保証契約と推奨品質保証契約と推奨品質保証契約と推奨 HA アーキテクチャアーキテクチャアーキテクチャアーキテクチャ

回答回答回答回答 1（ローカル・サイト（ローカル・サイト（ローカル・サイト（ローカル・サイト HA））））

回答回答回答回答 2（ローリング・メンテナンス）（ローリング・メンテナンス）（ローリング・メンテナンス）（ローリング・メンテナンス）

回答回答回答回答 3（障害時リカバリ）（障害時リカバリ）（障害時リカバリ）（障害時リカバリ）推奨アーキテクチャ推奨アーキテクチャ推奨アーキテクチャ推奨アーキテクチャ

No No No データベースのみ

Yes No No RAC のみ

No Yes No Data Guard のみ

No No Yes Data Guard のみ

Yes Yes No MAA

Yes No Yes MAA

No Yes Yes Data Guard のみ

Yes Yes Yes MAA


その他のアーキテクチャの評価

その他のアーキテクチャの評価その他のアーキテクチャの評価その他のアーキテクチャの評価その他のアーキテクチャの評価この他にも Oracle HA ソリューションおよび Oracle 以外の HA ソリューションがあります。この項では、も一般的な変形アーキテクチャについて説明します。表 4-4 に、代替の各HA 案、その不利な点と推奨 Oracle HA アーキテクチャを示します。

表表表表 4-4 HA アーキテクチャの比較アーキテクチャの比較アーキテクチャの比較アーキテクチャの比較

代替アーキテクチャ代替アーキテクチャ代替アーキテクチャ代替アーキテクチャ不利な点不利な点不利な点不利な点推奨ソリューション推奨ソリューション推奨ソリューション推奨ソリューション

プライマリ・サイト : ハードウェア・

クラスタ上の Oracle データベース

注意注意注意注意 : これはコールド・フェイルコールド・フェイルコールド・フェイルコールド・フェイル

オーバーオーバーオーバーオーバーと呼ばれます。

RAC の HA 機能なし

Data Guard 機能なし

1. RAC

2. MAA


ベース

セカンダリ・サイト : リモートの

ミラー化データベース

RAC の HA 機能なし

Data Guard 機能なし

高いネットワーク使用率

Oracle のスイッチオーバーとフェイ

ルオーバーの統合なし

カスタマイズが必要

リモートのミラー化ソリューションが Oracle Storage Compatibility Program（OSCP）の一部であること

が必要

1. Data Guard

2. MAA

プライマリ・サイト : RAC 本番

データベース（RAC GeoCluster）

セカンダリ・サイト : RAC GeoCluster の低 1 つのノード

ノード間の待機時間によるパフォーマンスへの影響

データまたはメディア障害、あるいはデータベース破損に対する障害時リカバリ保護なし（スタンバイ・データベースが離れた場所にないため）

1. Data Guard または Streams

2. MAA

プライマリ・サイト : RAC 本番データ

ベースおよびローカル Data Guardサイト障害およびサイト・エラーからの保護なし

MAA


ベースおよびローカル Data GuardRAC の HA 機能なし

障害およびサイト・エラーからの保護なし

MAA


その他のアーキテクチャの評価


高可用性の操作ポリ

5
高可用性の操作ポリシー高可用性の操作ポリシー高可用性の操作ポリシー高可用性の操作ポリシー
この章では、高可用性のメンテナンスに必要なポリシーおよび手順について説明します。

� 高可用性の操作ポリシーの概要

� 高可用性のサービス・レベル管理

� 高可用性を促進する容量計画

� 高可用性の変更管理

� 高可用性のバックアップおよびリカバリ計画

� 障害時リカバリ計画

� 計画的停止の計画

� 高可用性のスタッフ研修

� 高可用性保持の手段としてのドキュメント

� 高可用性のための物理的なセキュリティ・ポリシーおよび手順

シー 5-1

高可用性の操作ポリシーの概要

高可用性の操作ポリシーの概要高可用性の操作ポリシーの概要高可用性の操作ポリシーの概要高可用性の操作ポリシーの概要操作ポリシーはサービス管理とともに、停止からのリカバリ時間を短縮するのみでなく、停止を防止および小限にするための基本事項です。操作ポリシーは、情報テクノロジのインフラストラクチャを管理するための基礎です。処理、ポリシーおよび管理に重点が置かれます。

高可用性の操作ポリシーでは、処理、ポリシーおよび管理の設定および確立が重点項目です。次のカテゴリに分類されます。

� 高可用性のサービス・レベル管理

� 高可用性を促進する容量計画

� 高可用性の変更管理

� 高可用性のバックアップおよびリカバリ計画

� 障害時リカバリ計画

� 計画的停止の計画

� 高可用性のスタッフ研修

� 高可用性保持の手段としてのドキュメント

� 高可用性のための物理的なセキュリティ・ポリシーおよび手順

関連項目関連項目関連項目関連項目 : 技術的なベスト・プラクティスの詳細は、第 6 章「システム構成およびネットワーク構成」を参照してください。


高可用性のサービス・レベル管理

高可用性のサービス・レベル管理高可用性のサービス・レベル管理高可用性のサービス・レベル管理高可用性のサービス・レベル管理情報技術（IT）部門は、サービスおよび可用性のレベルを向上させる一方で、コストの削減も求められます。サービス・レベル管理は、IT サービスがビジネス要件を満たしていることを保証するための容認された方法です。サービス・レベル管理には、IT マネージャと企業の取扱商品との掛け合いが必要です。まず、ビジネス要件を IT 投資に割り当てることから始めます。

サービス・レベル管理には、サービス・インフラストラクチャの完全なエンド・トゥ・エンドの管理が網羅されています。サービス・レベル管理の基礎は、品質保証契約（SLA）です。SLA は、プロバイダとクライアントの関係にアカウンタビリティを構築し、プロバイダのパフォーマンスを評価するために不可欠です。SLA は、顧客と IT サプライヤ（外部または内部）の関係に関する監視および制御文書として、より一般に認められるようになっています。SLA は、注文処理など、重要なビジネス・プロセスやアプリケーション・システム用に開発されています。システムの機能を特定する業務担当者は、これらのシステムに対するSLA を開発する必要があります。SLA は、サプライヤが提供する義務があるサービスおよびそのサービスを受けるユーザーの責務を詳細かつ完全に示します。SLA の開発では、クライアントに要件をランク付けするように依頼し、も重要な要件にリソースを重点的に割り当てます。SLA は、ビジネス要件から導き出す必要があります。

すべての企業のニーズを満たす標準化された SLA はありませんが、一般的な SLA には次のような項目が含まれます。

� 提供されるサービス、関係者および契約の有効日の定義。

� 計画的なテスト、メンテナンスおよびアップグレードに要する時間を除いたサービスまたはアプリケーションを利用できる日時の指定。

� サービスやアプリケーションが提供されるユーザーおよびハードウェアの数と場所の指定。

� 問題に対する予測応答時間など、問題に関するレポート作成およびエスカレーション手順。

� 日常的な要求の予測完了時間など、変更の要求手順。

� 品質目標の指定、およびその評価方法とレポート頻度の説明。

� サービスの費用および手数料の指定。手数料は、定額料金の場合またはサービス品質の様々なレベルに結び付けられる場合があります。

� ユーザー研修、正しいデスクトップ構成の維持、外部ソフトウェアの非導入または変更管理手順を回避しないことなど、ユーザーの責務の指定。

� サービス関連の相違点を解決する手順の記述。

高可用性の操作ポリシー 5-3

高可用性を促進する容量計画

SLA およびサービス・レベル評価方法の開発には、すべての関係者による参加と多大な労力を必要とします。サービス・レベルは、各注文ごとの処理費用など、ビジネス要件別に評価される必要があります。共有サービスまたはコンポーネントは、も厳しいレベルの SLAで実行する必要があります。さらに、SLA は、相互依存の IT グループ間で外部サプライヤとともに開発される必要があります。多くの技術者は、インフラストラクチャ・コンポーネントに対する個別の SLA より、統合された包括的な SLA を支持しています。

SLA の開発には、次の利点があります。

� ドキュメント化された責務によるサプライヤと顧客との職務上の関係。

� ビジネス要件の理解と一致の相互目標。

� サービス提供に対する評価方法のシステム。IT は、その機能と結果を定量化し、継続的に改善できます。

� 可用性を低下させるイベントの IT による防止または迅速な対応。

� 連絡手順およびエスカレーション手順のドキュメント・セット。

高可用性を促進する容量計画高可用性を促進する容量計画高可用性を促進する容量計画高可用性を促進する容量計画容量の計画およびしきい値の監視は、停止時間または許容範囲を超えるトランザクション遅延を防止するために必要です。時間経過とともにその負荷をメンテナンスするために平均使用量と大使用量および要件を理解すると、許容可能なパフォーマンスの確保に役立ちます。

容量計画には、表領域が完全に満杯になるまでの残り時間、およびディスク領域の追加を前もって計画する時間を見積る機能が含まれます。容量計画では、データベース内の大セッション数を増やすために、計画的停止を遅延または防止することもできます。


高可用性の変更管理

高可用性の変更管理高可用性の変更管理高可用性の変更管理高可用性の変更管理変更管理は、システムのハードウェア、ソフトウェア、アプリケーションおよびデータに対する変更が許可、計画およびテストされることを保証する一連の手順または規則です。予測外、未テストおよび未承認の変更が許可されない安定したシステムは、ユーザーに整合性を保証するシステムです。ユーザーは、ハードウェア、ソフトウェアおよびデータが予測どおりに実行されることを信頼できます。システムに適用される変更の時期および内容の適確な把握は、問題の修正に欠かせません。顧客はそれぞれ、システム、データベースおよびアプリケーション・コードの変更管理を様々な方法で処理しますが、不要なシステムの停止を回避して、システムの整合性の保護に役立つ一般的なガイドラインがあります。適切な変更管理によって、アプリケーションおよびハードウェア・システムの安定性が向上し、新しい問題の修正が容易になります。

図 5-1 に、一般的な変更制御フローを示します。障害の発生などの緊急時には、この変更制御プロセスの短縮が必要になる場合があります。

図図図図 5-1 変更制御変更制御変更制御変更制御



優れた変更管理の基礎となる推奨事項を次に示します。

� 変更制御プロセスの開発

エスカレートなしおよびエスカレートありの両方の場合に対応する変更制御プロセスを作成、ドキュメント化および実施する必要があります。システム内のハードウェア、データベース、ソフトウェアの臨時および緊急の変更は回避できませんが、変更制御プロセスは、それらの変更が後で変更管理システムに取り込まれ、その影響や問題が検証および記録されることを保証する必要があります。

� 変更制御グループの形成

アプリケーション、データベース、システムおよび管理の代表者が変更制御チームのメンバーであることが必要です。ハードウェアおよびソフトウェアの両方の代表者が参加する必要があります。

ミーティング頻度および低評価時間を決定します。変更制御プロセスは、重要な変更が適切な時間内に実施できるようにする必要があります。変更制御ミーティングは、も重要な問題に取り組み、議論するために十分な頻度で開催する必要があります。変更が提示されてから、検討するための時間がスケジュールされるまでの猶予期間を低限に抑え、十分な評価時間を確保する必要があります。この評価時間は、上層管理者の承認がある場合のみ省略してください。

� 提案された変更の評価

変更は、短期間または長期間にわたる利点をもたらす必要があります。変更制御チームは、変更の利点がリスクを上回るかどうか、変更がビジネス、アプリケーションおよびその規則の全体像で一貫しているかどうかを評価する必要があります。提案された変更は、次の項目をドキュメント化する必要があります。

– 変更の目的

– リスクの評価

– フォールバック計画

– テスト計画およびテスト結果

– 停止時間を含めた変更の実施および取消しの見積時間

� 基準との比較用統計の収集

システム、ハードウェア、データベースおよびアプリケーションの構成およびパフォーマンス統計のスナップショットを収集します。これらの基準値は、変更の実施時に比較用として使用できます。データベース・パラメータの変更後、新規統計を収集し、これらを基準統計と比較すると、変更の影響を確認できます。



� データベース変更の追跡

データベース構造の変更は必要に応じて容易に行われ、変更管理プロセスを簡単に通過します。したがって、これらの変更に適した特別な手順が必要になる場合があります。傾向分析用にこれらの変更を追跡することも有効です。また、ファイルがデータベースに追加されたときは、そのファイルをバックアップおよび監視計画に組み込む必要があります。この種の変更を正しく追跡すると、覚書きとして機能します。

� アプリケーション・コードに対するバージョン制御システムの使用

アプリケーション・コードには、変更の追跡に役立ち、以前のコード・ベースへのフォールバックを可能にするバージョン制御システムが存在する必要があります。内部的に開発されたアプリケーションは頻繁に変更および拡張され、新しいバージョンに入れ替わります。新しいバージョンで問題が検出された場合は、旧バージョンでテストすることで、貴重なデバッグ情報が提供されます。アプリケーションのタイプ、および前のバージョンへの復帰をユーザーが必要とする可能性によって、企業は保持するバージョン数を決定する必要があります。少なくとも 1 つは必須です。

� 品質保証およびテスト手順の開発

品質保証では、テスト・シミュレーションでアプリケーションが疑似実行されるか、または少なくともテストするアプリケーションの重要なポイントがすべて考慮されるように、テスト仕様、テスト計画およびテスト結果を検証する必要があります。テストおよびテスト環境は、アプリケーションの必須機能およびスケーラビリティの両方をテストするように設計する必要があります。

� 内部監査の実行

内部監査は、ハードウェア、ソフトウェア、データベースおよびアプリケーションが、ベンダーによって保証され、サービス・レベル内で実行され、高可用性を実現していることを検証するために使用されます。


高可用性のバックアップおよびリカバリ計画

高可用性のバックアップおよびリカバリ計画高可用性のバックアップおよびリカバリ計画高可用性のバックアップおよびリカバリ計画高可用性のバックアップおよびリカバリ計画適切なバックアップおよびリカバリ計画は非常に重要で、特定のサービス・レベルを満たすように作成する必要があります。ディスクとテープの両方によるデータベース・バックアップをお薦めします。ディスクとテープによるバックアップは、障害時リカバリおよび非常に古いバックアップからリストアする必要がある場合に必要です。

強固なバックアップおよびリカバリ計画を作成するには、ファイルの物理的な位置、バックアップ・プロセス時のイベント順序およびエラーの処理方法によって、計画がどのように強化または妥協されるかを理解する必要があります。強固な計画によって、メディア障害、プログラム・エラーおよびオペレータ障害が発生した場合の回復が容易になります。完全で正常なテスト済のプロセスは、障害が発生した環境を正常にリカバリするための基本です。

有効なバックアップおよびリカバリ計画を作成するには、次の手順を実行します。

� リカバリ計画の作成

様々なタイプの停止に対するリカバリ計画を作成します。もよく発生する停止のタイプから開始し、あまり発生しない停止へと進みます。停止と推奨リカバリ処理のマトリックス、および検証済 MTTR の見積りを使用すると、様々なタイプの停止に対してSLA が満たされるかどうかを評価できます。

� バックアップの定期的なテスト

リカバリ手順を定期的にテストして、バックアップ・タスクに誤りがないか調査し、バックアップを検証します。

� バックアップおよびリカバリの手順の自動化

� 適切なバックアップ頻度の選択

新のバックアップがあると、リカバリ時間が短縮されます。

� オフサイトのテープ・バックアップの保持

サイト障害から保護するには、データベースのオフサイトのバックアップが必要です。

� バックアップおよびリカバリ計画の更新済ドキュメントの保持

ドキュメントは、失敗、知識のある人員の損失、および誤った解釈に対する保護対策であることは明らかです。バックアップおよびリカバリ手順に関する正確なドキュメントを保持することは、手順の実施と同じく重要です。

関連項目関連項目関連項目関連項目 : 第 9 章「停止からのリカバリ」


障害時リカバリ計画

障害時リカバリ計画障害時リカバリ計画障害時リカバリ計画障害時リカバリ計画障害時リカバリ（DR）計画は、サービスの致命的で大規模な停止を処理して操作を適時に再開できるように、特別に設計および開発されたプロセスです。これらの停止の原因には、火災、洪水、地震または不当な攻撃などによる障害があります。基本的な前提事項は、データ・センターおよびコンピュータが常駐しているビルに到達できない可能性があること、および操作を他の場所で再開する必要があることです。悪の事態を想定し、悪の状況に対処することを目的とします。コンピュータ・システムやデータに対する企業の依存度は増大しているため、これらのシステムおよびデータへのアクセスは、成功の基本構成要素になります。このため、障害時リカバリ計画の重要性も高まります。適切な障害時計画では、致命的な状況での MTTR が短縮され、重要なアプリケーションは継続的に使用できるため、顧客および収益の保持に有効です。

障害からのリカバリを計画するには、次の手順を実行します。

� 正しい障害時リカバリ計画（DRP）の選択

DRP では、予期された MTTR サービス・レベルを提供する必要があります。実施コストも、サービス・レベルで容認される必要があります。1 つの DRP では、すべての障害、またはよくある障害にも対応できない場合があります。

� 障害時リカバリ計画の適用範囲の決定

障害時リカバリ計画にアプリケーションを組み込むかどうかを決定しようとする場合の初の質問は、そのアプリケーションで、障害の数時間または数日以内にオンラインに

戻る必要のある主要なビジネス操作がサポートされているかどうかです。これは、アプリケーションの可用性要件と密接に関連していますが、同じではない場合があります。システムが使用できない日時でも、企業ではコストを伴う遂行事項が他にもあります。障害時リカバリ計画では、暫定基準の許容可能なレベルで機能できるオフサイトの機器類、人員、および電話回線やネットワークなどのサポート・コンポーネントを保護する必要があります。これにはコストがかかるため、企業の存続に不可欠なアプリケーションのみを考慮するように注意する必要があります。

� 影響を受ける領域およびシステムの図を含めた DRP のドキュメント化

DRP では、保護の対象とする停止、およびその停止が発生した場合に実施する手順を明確に示す必要があります。それには、システムの全体図が必要です。コントローラ、ミラー化されたディスク、障害時バックアップ・サイト、プロセッサ、通信回線および電源など、ハードウェアのフォルト・トレランスを判別できるように詳細に描かれる必要があります。現在のリソースおよび必要となる場合がある追加のリソースの識別にも役立ちます。システム内をデータがいつどのように流れているかを理解することは、特別に注意するシステム部分の識別に重要です。特別な注意とは、追加の監視要件、またはバックアップの頻度や種類などで表されます。逆に、監視および管理に低限の注意と少しのシステム・リソースしか必要としない領域を示す場合もあります。


障害時リカバリ計画

� 障害時リカバリ・プロセスの設定

重要なアプリケーション、データベース・インスタンス、システムまたはビジネス・プロセスが障害時リカバリ計画に含まれていることを確認します。アプリケーション、システムおよびネットワークの図を使用して、障害時のフォルト・トレランスおよび代替経路を評価します。

� 重要なすべてのビジネス・コンポーネントの評価

ビジネスの実行を可能にするすべてのコンポーネントについて考えます。DRP に、すべてのシステム、ハードウェア、アプリケーションおよび人員が含まれていることを確認します。ネットワーク、電話サービスおよびセキュリティ保護装置が使用可能であることを検証します。

� DR コーディネータの割当て

DR コーディネータおよびバックアップ・コーディネータを事前に割り当て、すべての運用および通信手段が伝達されることを確認する必要があります。

� DRP のテストおよび検証

DRP は定期的に繰り返し検討する必要があります。これは、DRP をテストする機能が使用可能である必要があることを意味します。


計画的停止の計画

計画的停止の計画計画的停止の計画計画的停止の計画計画的停止の計画計画的停止は、アプリケーション・サーバー層、データベース層またはサイト全体に影響を与える可能性があります。これらの停止には、ノード・ハードウェアのメンテナンス、ノード・ソフトウェアのメンテナンス、Oracle ソフトウェアのメンテナンス、冗長コンポーネントのメンテナンス、サイト全体のメンテナンスのうちの 1 つ以上が含まれる場合があります。計画的停止を正しく計画すると、MTTR が短縮され、変更が計画どおりに進まなかった場合のリスクが低くなります。

計画的停止を計画するには、次の手順を実行します。

� 計画的停止のリストの作成

想定できる計画的停止、その予測頻度および推定継続時間のリストを作成すると、可用性要件の詳細な計画およびより優れた評価が可能になります。計画外停止を防止するために、重要なコンポーネントの平均障害間隔（MTBF）を理解するための信頼性の評価を使用して、特定の計画的停止を計画できます。多くの場合、大規模な計画的停止は毎年 1 回のみであるため、メンテナンスに優先順位を付け、容認する必要があります。

� 想定できる各計画的停止に関する影響のドキュメント化およびリスクの評価

ソフトウェアまたはアプリケーションの変更を必要としない計画的停止は、停止後のシステムで新規トランザクションを引き継ぐことができる場合、通常は低限の停止時間で終了できます。Real Application Clusters と Data Guard のスイッチオーバーを使用すると、ハードウェアのアップグレード、およびある程度の標準システム・メンテナンスを、低限の業務停止時間で実行できます。Oracle のアップグレードなどのほとんどのソフトウェア・アップグレードについては、正しく準備されている場合、実際の停止時間は 1 時間未満です。スキーマの変更またはデータベース・オブジェクトの再編成を必要とする複雑なアプリケーションの変更については、顧客は、Oracle のオンライン再編成機能で十分かどうかを評価するか、Oracle のローリング・アップグレード機能の一部を使用する必要があります。

� 計画的停止の容認

各変更は、アプリケーションおよびビジネスの全体像と一貫性があり、互換性および変更制御ルールに準拠している必要があります。

� 変更、テストおよびフォールバック手順の作成および自動化

Oracle のアップグレードなどの計画的な各変更は、パフォーマンスおよび可用性の影響を評価するために、シミュレートされた実社会の環境でテストする必要があります。パフォーマンスおよび負荷の影響を正確に評価するために、シミュレートされた完全なストレス・テストおよび負荷の使用をお薦めします。フォールバック計画を作成し、計画的停止に組み込む必要があります。変更を実施し、必要な場合は正しくフォールバックするためには、自動化プロセスが使用可能であることが必要です。

関連項目関連項目関連項目関連項目 : 9-8 ページ「計画的停止のリカバリ手順」


高可用性のスタッフ研修

高可用性のスタッフ研修高可用性のスタッフ研修高可用性のスタッフ研修高可用性のスタッフ研修高度な技術を身に付けた人員は、情報に基づいてより優れた決定を下すことができ、失敗する可能性が低くなります。システム管理、データベース管理、開発およびユーザー・グループの継続的な技術教育に対する包括的な計画は、システムおよびデータベースの高い可用性を確保するために役立ちます。さらに、システム・コンポーネントの冗長性によってシングル・ポイント障害がなくなるのと同様に、知識管理および相互研修によって、ある従業員がいなくなった場合に操作に影響することがないようにする必要があります。

� ビジネス・クリティカルな職務に対する相互研修

ビジネス・クリティカルなシステムでは、ある従業員が不在の場合または退職した場合の操作への影響を低減するために、技術スタッフの相互研修が必要です。たとえば、システム管理グループは、Oracle RDBMS とツール類をよく理解している必要があります。異なるサポート・グループ間で定例の正式な伝達手段（週 1 回のミーティングなど）を設けてください。

� 継続的な技術教育を保証するガイドラインの開発

企業で使用しているハードウェアおよびソフトウェアに関連する新機能または手順に関して、スタッフに通知および研修を実施するプロセスが使用可能であることを確認してください。また、サービス・レベルの向上する、またはコストを削減できる新しいテクノロジに対する調査時間を確保してください。

� 知識管理プロセスの導入

企業の知的財産を効果的に管理すると、これらの財産を失うリスクが低くなります。ITグループ内の習得済の課題に関する情報への中央アクセスを促進するプロセスを作成してください。たとえば、グループ会議、内部ホワイト・ペーパー、アップグレード関連の新機能、問題の分析と解決のためのリポジトリなどが情報を入手可能にする手段です。

� アプリケーションまたはシステム変更時の研修資料の更新

研修資料は、アプリケーションおよびシステムの変更にあわせて新の状態にしておく必要があります。研修資料を変更管理およびドキュメントの手順に組み込んでください。


高可用性保持の手段としてのドキュメント

高可用性保持の手段としてのドキュメント高可用性保持の手段としてのドキュメント高可用性保持の手段としてのドキュメント高可用性保持の手段としてのドキュメントわかりやすい完全なドキュメントが、一連の各 HA 操作ポリシーの一部であることが必要です。プロセスの実施または実行の手順をドキュメント化しないと、その知識を失うリスクがあり、そのプロセス実行時の人為的なエラーやプロセス内の手順を抜かすリスクが増大します。これらのリスクすべてが可用性に影響を与えます。

わかりやすく定義された操作手順は、組織に新しく加わった従業員の習得時間の短縮に役立ちます。正しくドキュメント化された操作手順は、サポート担当者への質問数を大幅に削減し、手順を整えた人員がそのグループで作業しなくなった場合は特に役立ちます。また、組織内の役割や責務を明確に定義することによって混乱をなくすこともできます。

アプリケーションのわかりやすいドキュメントは、新規従業員にとって非常に重要です。内部的に開発されたアプリケーションをメンテナンスおよび拡張する必要がある場合、ドキュメントは、開発者がプログラムの内部的な詳細に関する知識を新たにするのに役立ちます。元の開発者がグループを離れている場合、このドキュメントは新しい開発者にとって特に有益です。ドキュメントがない場合は、コード自体の解読に労力を費やす必要があります。容易に使用できるアプリケーション・ドキュメントは、サポート組織への質問数を大幅に減少することにもなります。

� ドキュメントが常に新であることの確認

アプリケーションまたはシステムの変更時に操作手順を更新します。ドキュメントの更新が常にユーザーに伝わるようにしてください。

� 変更管理プロセスを使用したドキュメントの変更の承認

変更管理チームは、ドキュメントが正確であることを保証するために、変更内容を確認し、承認する必要があります。

� 習得済の課題および問題の解決方法のドキュメント化

問題の解決方法および習得済の課題をドキュメント化すると、繰返し発生する問題のリカバリ時間を改善できます。このドキュメントは、システム拡張の優先順位を設定するための定期的な検討プロセスの一部とするのが理想的です。

� ドキュメントの保護

ドキュメントに安全にアクセスできるようにし、操作手順のドキュメントおよびその他の重要なドキュメントのオフサイト・コピーを保持してください。重要なドキュメントはすべて、リモート・サイト実装の一部にもする必要があります。リモート・サイトが、障害発生後のシステムの再起動または障害時リカバリを目的としているかどうかに関係なく、サイトには、そのサイトにフェイルオーバーするためのドキュメント化された手順のコピーも含まれている必要があります。


高可用性のための物理的なセキュリティ・ポリシーおよび手順

高可用性のための物理的なセキュリティ・ポリシーおよび手順高可用性のための物理的なセキュリティ・ポリシーおよび手順高可用性のための物理的なセキュリティ・ポリシーおよび手順高可用性のための物理的なセキュリティ・ポリシーおよび手順セキュリティ・ポリシーでは、ハードウェアおよびデータ・センターの物理的なセキュリティおよび運用について考慮します。物理的なセキュリティには、火災、熱および電気的なサージなどの物理的な損傷からの保護のみでなく、不当なアクセスからの保護も含まれます。物理的なセキュリティは、も基本的なセキュリティ予防措置であり、システムで顧客の可用性要件を満たすための必須事項です。外部および内部からのセキュリティの侵害に対して保護します。『CSI/FBI Computer Crime and Security Survey』には、外部からの侵入が増加傾向にあることが記載され、内部のセキュリティ違反もまた多大な脅威であることが示されています。データ・センターの運用および組織のセキュリティに関する詳細な検出プロセスはこのドキュメントには記載されていません。ただし、適切に保護されたインフラストラクチャは、破損、停止時間および財務的な損害のリスクを削減します。

ハードウェアおよびデータ・センターの物理的なセキュリティを保持するには、次の手順を実行します。

� コンピュータ装置に適した物理環境の準備

コンピュータ装置の設置場所として、オフィス環境内のすべての部屋または小室を使用できるわけではありません。データ・センターの場合は、適切な温度、湿度およびシステムのセキュリティを考慮する必要があるのみでなく、電気的なサージ、火災、洪水などの潜在的な危険の防止も計画する必要があります。

� 認可された人員に対する運用領域へのアクセスの制限

セキュリティを考慮したすべての運用センターでは、バイオメトリック認証装置またはスマートカード・リーダーなど、なんらかのセキュアなアクセスが必要です。

� 内部的なセキュリティ監視の使用

運用センターを保護するには、カメラや閉回路テレビジョンなどの装置によって設備内の人間による違反行為や損害を防ぐことが必要です。

� DBA、システム管理者および運用スタッフの経歴確認の実施

DBA、システム管理者および運用スタッフは、本質的に権限が与えられているユーザーであり、責任のある地位にいます。組織では、適切な経歴の確認を実行して、これらの権限が与えられている個人がその地位の信頼に値するかどうかを確認します。確固とした悪意を持つ不適格な人間が権限のある地位にいるかぎり、完全に保護できる技術的なソリューションはありません。

関連項目関連項目関連項目関連項目 : データ・セキュリティの詳細は、第 6 章「システム構成およびネットワーク構成」を参照してください。


第第第第 III 部部部部
高可用性を備えた高可用性を備えた高可用性を備えた高可用性を備えた Oracle 環境の構成環境の構成環境の構成環境の構成
第Ⅲ部では、高可用性アーキテクチャの構築方法について説明します。




システム構成およびネットワーク

6
システム構成およびネットワーク構成システム構成およびネットワーク構成システム構成およびネットワーク構成システム構成およびネットワーク構成
この章では、データベース・サーバー層とネットワークを構成するサブコンポーネントの構成に関する推奨事項を説明します。内容は次のとおりです。

� システム構成に関する推奨事項の概要

� ストレージの構成に関する推奨事項

� サーバー・ハードウェアの構成に関する推奨事項

� サーバー・ソフトウェアの構成に関する推奨事項

� ネットワークの構成に関する推奨事項

構成 6-1

システム構成に関する推奨事項の概要

システム構成に関する推奨事項の概要システム構成に関する推奨事項の概要システム構成に関する推奨事項の概要システム構成に関する推奨事項の概要高い可用性を備えた環境を構成する目的は、平易性とパフォーマンスを犠牲にすることなく、冗長性と信頼性の高いシステムおよびデータベースを作成することにあります。この章では、データベース・サーバー層のサブコンポーネントの構成に関する推奨事項について説明します。

次の原則は、サブコンポーネントの推奨事項のすべてに適用されます。

� 冗長性冗長性冗長性冗長性 : 障害によるリスクを軽減するために、冗長性のあるコンポーネントおよび機能を選択します。

� 統合統合統合統合 : 障害の可能性があるコンポーネントの数を減らすために、適切なコンポーネントを統合します。

� 拡張拡張拡張拡張 : 今後の拡張に備えて計画します。

� 管理性管理性管理性管理性 : 信頼性があり、オンラインでサービスできるコンポーネントを選択します。

ストレージの構成に関する推奨事項ストレージの構成に関する推奨事項ストレージの構成に関する推奨事項ストレージの構成に関する推奨事項電子データは、すべてのビジネスにとっても重要な資産の 1 つです。企業の成功を確かなものにするため、ストレージ・アレイは格納したデータを保護し、そのデータにアクセス可能な状態を保持する必要があります。この項では、管理性およびパフォーマンスの提供と同時にデータを保護するフォルト・トレラントのストレージ・サブシステムの特性について説明します。この項で説明する、すべてのアーキテクチャに関するストレージの推奨事項は、次のとおりです。

� 全ハードウェア・コンポーネントにおける完全な冗長性およびフォルト・トレラントの確認

� オンラインでサービス可能なアレイの使用

� 保護とパフォーマンスのためのミラー化とストライプ化

� すべての物理インタフェース間でのロード・バランス

� 独立したストレージ領域の作成

� ASM ディスクと障害グループの適切な定義

� データ破損に対する大保護のための HARD 準拠のストレージの使用

次の項は、特に RAC 環境に関係しています。

� RAC に関するストレージの推奨事項

関連項目関連項目関連項目関連項目 : 各ベンダーの HA アーキテクチャ、およびハードウェア、オペレーティング・システム、クラスタ構成に関するベスト・プラクティスのドキュメントと推奨事項


ストレージの構成に関する推奨事項

全ハードウェア・コンポーネントにおける完全な冗長性およびフォルト・全ハードウェア・コンポーネントにおける完全な冗長性およびフォルト・全ハードウェア・コンポーネントにおける完全な冗長性およびフォルト・全ハードウェア・コンポーネントにおける完全な冗長性およびフォルト・トレラントの確認トレラントの確認トレラントの確認トレラントの確認

ストレージ・アレイのすべてのハードウェア・コンポーネントは、冗長電源装置およびアレイ自体への接続性も含め、物理インタフェースから物理ディスクまで、完全に冗長である必要があります。

ストレージ・アレイには、1 つ以上のスペア・ディスク（ホット・スペアとも呼ばれる）を含める必要があります。物理ディスクが、監視インフラストラクチャにエラーのレポートを開始した場合、または障害が突然発生した場合、ファームウェアは、障害が発生したディスクの内容をスペア・ディスクにミラー化して、フォルト・トレランスを迅速にリストアする必要があります。

ストレージ・アレイへの接続性は、完全に冗長（マルチパスと呼ばれる）である必要があります。これによって、各ノードから共有ディスク・アレイ（コントローラ、インタフェース・カード、ケーブル、スイッチなど）までのデータ・パス内で発生した単一コンポーネントの障害が透過的となり、アレイを完全にアクセス可能な状態に保持できます。また、複数の物理パスを経由して同じ論理デバイスをアドレッシングできます。ホストベースのデバイス・ドライバは、障害のない物理インタフェースの 1 つに I/O を再発行します。

ストレージ・アレイに書込みキャッシュが含まれている場合は、メモリー・ボードの障害を防ぐために保護する必要があります。書込みキャッシュは、複数のバッテリ・バックアップで保護し、すべての外部電源装置の障害を防ぐ必要があります。キャッシュは、バッテリ・バックアップを使用して外部電源が復帰するまで、またはキャッシュ内のすべての破損したブロックが物理ディスクに完全にフラッシュされたことが保証されるまで存続可能にする必要があります。

オンラインでサービス可能なアレイの使用オンラインでサービス可能なアレイの使用オンラインでサービス可能なアレイの使用オンラインでサービス可能なアレイの使用物理コンポーネントで障害が発生した場合、アレイをシャット・ダウンまたはオフライン化せずに、アレーは障害のあるデバイスを修復するか、または置換する必要があります。また、ストレージ・アレイでは、そのストレージ・アレイをシャット・ダウンせずに、ファームウェアのアップグレードとパッチの適用が実行できる必要があります。

システム構成およびネットワーク構成 6-3


保護とパフォーマンスのためのミラー化とストライプ化保護とパフォーマンスのためのミラー化とストライプ化保護とパフォーマンスのためのミラー化とストライプ化保護とパフォーマンスのためのミラー化とストライプ化ディスクと他のコンポーネントの障害からデータを保護するため、データをミラー化する必要があります。また、適なパフォーマンスを実現するために、データを多数のディスクにわたってストライプ化する必要があります。このストレージ構成の手法は、Stripe and Mirror Everything（SAME）と呼ばれています。この SAME 手法によって、簡単で効率的な高い可用性を備えたストレージ構成が提供されます。

Oracle の Automatic Storage Management（ASM）の機能によって、データは、1 つのディスク・グループ内の全ドライブ間で常に均等にストライプ化されます。さらに、この機能には、ディスクが追加された場合は新しいディスク間で、ディスクが削除された場合は既存のディスク間で、複数のファイルを自動的に再バランスする利点があります。さらに、ASMには、コンポーネント障害に対する保護や基礎となるストレージ・アレイによるミラー化を可能にするために、冗長性保護が提供されています。

すべての物理インタフェース間でのロード・バランスすべての物理インタフェース間でのロード・バランスすべての物理インタフェース間でのロード・バランスすべての物理インタフェース間でのロード・バランス物理インタフェース間の I/O 操作のロード・バランシングは、通常、ホストにインストールされているソフトウェア・パッケージによって提供されます。このロード・バランシング・ソフトウェアの目的は、単一のホスト・バス・アダプタ（HBA）が現在のワークロードでオーバーロードになった場合に、I/O 操作を負荷の軽い物理インタフェースにリダイレクトすることです。


� http://otn.oracle.com/deploy/availability/pdf/oow2000_same.pdfの『Optimal Storage Configuration Made Easy』を参照してください。

� 『Optimal Storage Configuration Made Easy』での主張を実証したOracle 内部の研究論文。この研究論文は、http://otn.oracle.com/deploy/availability/pdf/SAME_HP_WP_112002.pdfから入手できます。

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



独立したストレージ領域の作成独立したストレージ領域の作成独立したストレージ領域の作成独立したストレージ領域の作成ソフトウェア、アクティブ・データベース・ファイルおよびリカバリ関連ファイル用に個別の独立したストレージ領域を作成します。

次のストレージ領域が必要です。

� ソフトウェア領域 : ソフトウェアがインストールされ、ログ・ファイルおよびトレース・ファイルが作成される場所

� データベース領域 : データファイル、制御ファイル、オンライン REDO ログ、および増分バックアップで使用される変更トラッキング・ファイルなどのアクティブ・データベース・ファイルが格納される場所

� フラッシュ・リカバリ領域 : 現在の制御ファイルとオンライン REDO ログの多重コピー、アーカイブ REDO ログ、バックアップ・セット、フラッシュバック・ログ・ファイルなどのリカバリ関連ファイルが作成される場所

データベース領域を含むストレージは、できるかぎりフラッシュ・リカバリ領域と物理的に区別する必要があります。低限、データベース領域とフラッシュ・リカバリ領域が、同じ物理ディスク・ドライブまたはディスク・コントローラを共有しないようにする必要があります。この方法によって、データベース領域でデータファイルへのアクセスを提供するコンポーネントの障害が、そのデータファイルのリカバリに必要なフラッシュ・リカバリ領域にあるバックアップや REDO ログの消失の原因にならないことが確実になります。

ストレージ・オプションの定義は、次のとおりです。

� 通常ファイル・システム : 他のシステムと共有されないローカル・ファイル・システム

� クラスタ・ファイル・システム（CFS）: 1 つのクラスタ内のすべてのノードによる均等なアドレス指定とアクセスが可能なファイル・システム（アクセスがマスター・ノードを介して送信される共有ファイル・システムとは異なります）

� Automatic Storage Management（ASM）: ファイル・システムとボリューム・マネージャの機能を統合する、Oracle データベース・ファイル用に特別に設計されたツール

� RAW デバイスまたは論理ボリューム : 一般的に、ファイル・システムを含まない論理ボリューム・マネージャによって管理されるストレージ

この項の後半では、次の内容を説明します。

� 特定 HA アーキテクチャに関するストレージの推奨事項

� ASM ディスクと障害グループの適切な定義



特定特定特定特定 HA アーキテクチャに関するストレージの推奨事項アーキテクチャに関するストレージの推奨事項アーキテクチャに関するストレージの推奨事項アーキテクチャに関するストレージの推奨事項Data Guard のみのアーキテクチャと MAA の場合、プライマリ・サイトとセカンダリ・サイトには、それぞれ同じ構成のストレージ領域を含める必要があります。

RAC のみのアーキテクチャと MAA の場合は、次の推奨事項に従います。

� ソフトウェア領域は、RAC クラスタ内の各ノードに対してローカルな通常ファイル・システムにインストールする必要があります。この構成では、Oracle のパッチ・アップグレードが可能なため、シングル・ポイント障害としてのソフトウェアは除去されます。

� データベース領域とフラッシュ・リカバリ領域は、いずれも RAC クラスタ内のすべてのノードからアクセスできる必要があります。

– クラスタ・ファイル・システム（CFS）がターゲット・プラットフォーム上で使用可能な場合は、データベース領域とフラッシュ・リカバリ領域の両方を CFS またはASM 上に作成できます。

– クラスタ・ファイル・システム（CFS）がターゲット・プラットフォーム上で使用できない場合、データベース領域は ASM または RAW デバイス上に（必要なボリューム・マネージャとともに）作成でき、フラッシュ・リカバリ領域は ASM 上に作成する必要があります。

表 6-1 には、独立したストレージの推奨事項の要約をアーキテクチャ別に示しています。

表表表表 6-1 HA アーキテクチャに関する独立したストレージの推奨事項アーキテクチャに関する独立したストレージの推奨事項アーキテクチャに関する独立したストレージの推奨事項アーキテクチャに関する独立したストレージの推奨事項

ストレージ領域ストレージ領域ストレージ領域ストレージ領域非非非非 RAC データベースデータベースデータベースデータベースRAC データベースデータベースデータベースデータベース（（（（CFS 使用可能）使用可能）使用可能）使用可能）

RAC データベースデータベースデータベースデータベース（（（（CFS 使用不可）使用不可）使用不可）使用不可）

ソフトウェア領域通常ファイル・システム通常ファイル・システム通常ファイル・システム

データベース領域通常ファイル・システムまたはASM

CFS または ASM RAW または ASM

フラッシュ・リカバリ領域通常ファイル・システムまたはASM

CFS または ASM ASM


� 既存データベースの ASM への移動に関する詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

� ASM で使用するディスクの設定に関する詳細は、使用しているプラットフォーム固有のインストール・ガイドおよび『Oracle Real Application Clusters インストレーションおよび構成』を参照してください。



ASM ディスクと障害グループの適切な定義ディスクと障害グループの適切な定義ディスクと障害グループの適切な定義ディスクと障害グループの適切な定義ASM は、障害グループと呼ばれる概念を使用して、ディスクまたはコンポーネントの障害からデータを保護します。障害グループを使用する場合、ASM はファイル・レイアウトを適化して共有リソースの障害による使用制限を軽減します。障害グループはコンポーネン

トを共有するディスクを定義するため、1 つのディスクで障害が発生すると、コンポーネントを共有している他のディスクでも障害が発生する可能性があります。障害グループとして定義できる例には、同じ SCSI コントローラ上にある一連の SCSI ディスクがあります。障害グループは、冗長データの格納に使用する ASM ディスクを決定するために使用します。たとえば、ファイルに対して双方向ミラー化が指定された場合、ファイル・エクステントの冗長コピーは障害グループに個別に格納されます。

障害グループは、RAID に従って構成されていないディスクなど、それ自体の冗長機能がないストレージで使用します。ASM ディスク・グループに障害グループを定義する方法は、サイトによって異なります。これは、ストレージの構成、およびストレージのデータベース・システムへの接続方法によって障害グループの定義が異なるためです。ASM は、それ自体のメタデータのコピーを 3 つメンテナンスしようとするため、適切に保護するには低3 つの障害グループが必要です。

インテリジェント・ストレージ・アレイで ASM を使用する場合は、ASM の冗長機能ではなく、ストレージ・アレイの保護機能（ハードウェアの RAID-1 ミラー化など）を一般的に使用します。この保護機能は、CREATE DISKGROUP文の EXTERNAL REDUNDANCY句を使用して実装します。外部の冗長性を使用する場合、外部の冗長性ディスク・グループのディスクには高い可用性があると想定されるため、ASM 障害グループは使用しません。

ストレージ・アレイによってオペレーティング・システムに与えられるディスクは、アレイで集計または細分化されないようにする必要があります。これは、適切なデータ配置とデータ保護に必要な物理ディスクの境界がアレイによって隠される可能性があるためです。ただし、物理ディスクの境界が常にアレイによって隠されている場合、およびオペレーティング・システムに与えられる各論理デバイスが同じサイズおよび同じパフォーマンス特性を持つ場合は、単純に同じ（EXTERNAL REDUNDANCYとして定義される冗長性のある）ASMディスク・グループに各論理デバイスを配置し、データベース領域とフラッシュ・リカバリ領域をその 1 つの ASM ディスク・グループに配置します。代替方法の 1 つとしては、それぞれが単一の論理デバイスで構成される 2 つのディスク・グループを作成し、一方のディスク・グループにデータベース領域を配置し、もう一方のディスク・グループにフラッシュ・リカバリ領域を配置します。この方法によって、ディスク・グループのメタデータの障害と破損に対する追加の保護が提供されます。

たとえば、1 つのストレージ・アレイが 36GB の物理ディスクを 8 個使用して、パフォーマンスと保護のためにそれらを RAID0+1 の方法で構成し、ミラー化ストレージに合計 144GBを与えるとします。さらに、144GB のストレージは、72GB の論理デバイス 2 個としてオペレーティング・システムに与えられ、各論理デバイスは全 8 個のデバイス間でストライプ化およびミラー化されます。ASM を構成する場合は、72GB の各論理デバイスを同じ ASMディスク・グループに配置し、そのディスク・グループにデータベース領域およびフラッシュ・リカバリ領域を配置します。



この 2 つの論理デバイスが異なるパフォーマンス特性を持つ場合は（たとえば、一方が基礎となる物理ドライブの内側半分に対応し、もう一方が外側半分に対応する場合）、それぞれ個別のディスク・グループに配置する必要があります。これは、ディスクの外側部分は転送レートが高いことから、外側半分のディスク・グループはデータベース領域に使用する必要があり、内側半分のディスク・グループはリカバリ領域に使用する必要があるためです。

ASM 制御のもとで 1 つのデータベースで複数の異なるストレージ・アレイを使用する場合は、複数の選択肢があります。選択肢の 1 つは、複数のアレイ間でストレージを共有しない複数の ASM ディスク・グループを作成し、データベース領域とフラッシュ・リカバリ領域を別々のディスク・グループに配置することです。このようにして、データベース領域とフラッシュ・リカバリ領域を物理的に分離します。もう 1 つの選択肢は、各障害グループがただ 1 つのアレイからのディスクを含む障害グループを構成するアレイ間に、単一のディスク・グループを作成することです。これらの選択肢によって、1 つのストレージ・アレイ全体の障害に対する保護が提供されます。

データ破損に対する大保護のためのデータ破損に対する大保護のためのデータ破損に対する大保護のためのデータ破損に対する大保護のための HARD 準拠のストレージの使用準拠のストレージの使用準拠のストレージの使用準拠のストレージの使用Hardware Assisted Resilient Data（HARD）Initiative は、データ破損を未然に防止するために設計されたプログラムです。データ破損は非常に稀ですが、発生すると、ビジネスに致命的な影響を与えます。HARD Initiative のもとで、Oracle のストレージ・パートナは、記憶デバイス内に Oracle のデータ検証アルゴリズムを実装します。これによって、破損データの永続ストレージへの書込みを防止できます。HARD の目標は、これまでコンピュータ業界では防止できなかった種類の障害の排除です。RAID はデータの物理的な保護を確実にすることによって、ストレージ業界で幅広い支持を得ていますが、HARD は物理的なデータの保護を超えてビジネス・データを保護することによって、データ保護を次の段階に進めます。

破損を未然に防ぐために、Oracle は高度な記憶デバイスを緊密に統合して、破損を未然に検出し排除するシステムを作成します。オラクル社は主要なストレージ・ベンダーと協力して、Oracle のデータ検証アルゴリズムの記憶デバイス自体への実装に取り組んできました。Oracle が HARD で取り組むデータ破損には、次の種類があります。

� 物理的および論理的に破損したデータファイル、制御ファイルおよびログ・ファイルの各ブロックの書込み

� Oracle ブロックの不適切な位置への書込み

� Oracle 以外のプログラムによる Oracle データへの誤った書込み

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

エンド・トゥ・エンドのブロック検証は、オペレーティング・システムまたはストレージ・サブシステムによる Oracle データ・ブロックの内容の検証に使用するテクノロジです。記憶デバイス内での Oracle データの検証によって破損が検出され、永続ストレージへの書込み前に排除されます。この機能は、逸脱、消失または破損した書込みを次の物理的な読込みまで検出しない現在の Oracle のデータ検証機能を超えるものです。




Oracle のベンダーには、仕様に基づいた妥当性チェックを実装する機会が与えられています。ベンダーの実装では、各社のストレージ・テクノロジに固有の機能を提供できます。オラクル社は、各ベンダーのソリューションを製品と Oracle のバージョンで比較する Web サイトを整備しています。新の情報については、http://otn.oracle.com/deploy/availability/htdocs/HARD.htmlを参照してください。

RAC に関するストレージの推奨事項に関するストレージの推奨事項に関するストレージの推奨事項に関するストレージの推奨事項次の推奨事項は、RAC のみのアーキテクチャと MAA に適用されます。

� Oracle Cluster Registry および投票ディスク（ボーティング・ディスク）のメディア障害からの保護

Oracle Cluster Registry および投票ディスク（ボーティング・ディスク）および投票ディスク（ボーティング・ディスク）および投票ディスク（ボーティング・ディスク）および投票ディスク（ボーティング・ディスク）のメディア障害からの保護のメディア障害からの保護のメディア障害からの保護のメディア障害からの保護OCR と投票ディスク用に作成された共有ボリュームは、メディア障害から保護するためにRAID を使用して構成する必要があります。このためには、RAID による保護を提供する外部クラスタ・ボリューム・マネージャ、クラスタ・ファイル・システムまたはストレージ・ハードウェアを使用する必要があります。


関連項目関連項目関連項目関連項目 : 『Oracle Real Application Clusters インストレーションおよび構成』


サーバー・ハードウェアの構成に関する推奨事項

サーバー・ハードウェアの構成に関する推奨事項サーバー・ハードウェアの構成に関する推奨事項サーバー・ハードウェアの構成に関する推奨事項サーバー・ハードウェアの構成に関する推奨事項メイン・サーバーのハードウェア・コンポーネントは、データベースとアプリケーション・サーバー・ファーム用のノード、および各ノード内のコンポーネントです。このコンポーネントには、CPU、メモリー、インタフェース・ボード（I/O やネットワークなど）、ストレージ、RAC 環境のクラスタ・インターコネクトなどがあります。

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

� すべてのアーキテクチャに関するサーバー・ハードウェアの推奨事項

� RAC に関するサーバー・ハードウェアの推奨事項

� Data Guard に関するサーバー・ハードウェアの推奨事項

すべてのアーキテクチャに関するサーバー・ハードウェアの推奨事項すべてのアーキテクチャに関するサーバー・ハードウェアの推奨事項すべてのアーキテクチャに関するサーバー・ハードウェアの推奨事項すべてのアーキテクチャに関するサーバー・ハードウェアの推奨事項次の推奨事項は、すべてのアーキテクチャに適用されます。

� より少数、高速、稠密なコンポーネントの使用

� 冗長ハードウェア・コンポーネントの使用

� 障害を検出して分離するシステムの使用

� バックアップ・コピーによるブート・ディスクの保護

より少数、高速、稠密なコンポーネントの使用より少数、高速、稠密なコンポーネントの使用より少数、高速、稠密なコンポーネントの使用より少数、高速、稠密なコンポーネントの使用多数の低速な CPU のかわりに、少数の高速な CPU を使用します。多数の低稠密度のメモリー・モジュールのかわりに、少数の高稠密度のメモリー・モジュールを使用します。これによって、同じサービス・レベルの提供中に障害を起こす可能性のあるコンポーネントの数を減らします。これにはコストと冗長性のバランスをとる必要があります。

冗長ハードウェア・コンポーネントの使用冗長ハードウェア・コンポーネントの使用冗長ハードウェア・コンポーネントの使用冗長ハードウェア・コンポーネントの使用冗長ハードウェア・コンポーネントの使用によって、障害のあるコンポーネントをオフラインにすると稼動中のコンポーネントに対するシステムのフェイルオーバーが可能になります。ハードウェア障害の修復によって発生した計画外停止を防ぐために、システムが稼動している間に、修復または再配置が可能なコンポーネント（電源装置、冷却ファン、インタフェース・ボードなど）を選択します。

障害を検出して分離するシステムの使用障害を検出して分離するシステムの使用障害を検出して分離するシステムの使用障害を検出して分離するシステムの使用自動的に障害を検出した後、障害のあるサブシステムの周辺に代替パスを提供したり、障害のあるサブシステムを分離できるシステムを使用します。コンポーネント障害にかかわらず稼動を継続し、全体停止を発生させずに障害のあるコンポーネントを自動的に回避するシステムを選択します。たとえば、アダプタに障害が発生した場合は I/O 要求の代替パスを使用でき、メモリー・ボードで障害が発生した場合は破損した物理メモリーを避けられるシステムを検出します。


サーバー・ハードウェアの構成に関する推奨事項

バックアップ・コピーによるブート・ディスクの保護バックアップ・コピーによるブート・ディスクの保護バックアップ・コピーによるブート・ディスクの保護バックアップ・コピーによるブート・ディスクの保護ミラー化では、偶発的なファイルの削除または大部分のブート・ディスクの破損からは保護されないため、ブート・ディスクのオンライン・コピーを維持する必要があります。これによって、重大なファイルが削除された場合、またはプライマリ・ブート・イメージに破損が発生した場合に、同じオペレーティング・システム・イメージを使用して高速にシステムをリブートできます。オペレーティング・システムのベンダーは、多くの場合、複数のブート・イメージを容易に維持するメカニズムを提供しています。

RAC に関するサーバー・ハードウェアの推奨事項に関するサーバー・ハードウェアの推奨事項に関するサーバー・ハードウェアの推奨事項に関するサーバー・ハードウェアの推奨事項次の推奨事項は、RAC のみの環境と MAA 環境に適用されます。

� サポートされているクラスタ・システムを使用した RAC の実行

� 適切なクラスタ・インターコネクトの選択

サポートされているクラスタ・システムを使用したサポートされているクラスタ・システムを使用したサポートされているクラスタ・システムを使用したサポートされているクラスタ・システムを使用した RAC の実行の実行の実行の実行RAC は、ノード障害とインスタンス障害からの高速で自動的なリカバリを提供します。RAC の実装に成功するためには、適切にサポートされている構成を使用する必要があります。サポートされているハードウェア構成には、サーバー・ハードウェア、ストレージ・アレイ、インターコネクト・テクノロジおよび他のハードウェア・コンポーネントが含まれる場合があります。

適切なクラスタ・インターコネクトの選択適切なクラスタ・インターコネクトの選択適切なクラスタ・インターコネクトの選択適切なクラスタ・インターコネクトの選択冗長性があり、高速で、待機時間が短く、ホスト・リソースの消費が少なく、さらに複数の使用可能なパス間のロード・バランシングが可能なインターコネクトを選択します。2 つのノード構成内で、その 2 つのノード間でのダイレクト接続インターコネクトを使用することは可能ですが、そのかわりに、クラスタ内で 2 つのノードのネットワーク・インタフェース・カード間にある程度の分離を提供するには、スイッチを使用する必要があります。今後、3 つ以上のノードを設置する予定の場合は、ノード追加の複雑さを軽減するために、ダイレクト接続のかわりにスイッチ・ベースのインターコネクト・ソリューションを選択します。3 つ以上のノードが存在する場合は、スイッチ・ベースのインターコネクトをお薦めします。また、大抵使用されているクラスタ・ソリューションの要件は、スイッチ・ベースのインターコネクトです。


サーバー・ソフトウェアの構成に関する推奨事項

Data Guard に関するサーバー・ハードウェアの推奨事項に関するサーバー・ハードウェアの推奨事項に関するサーバー・ハードウェアの推奨事項に関するサーバー・ハードウェアの推奨事項次の推奨事項は、Data Guard のみの環境と MAA 環境におけるプライマリ・サイトとセカンダリ・サイトの両方に適用されます。

両サイトでの全マシンに対する同一ハードウェアの使用両サイトでの全マシンに対する同一ハードウェアの使用両サイトでの全マシンに対する同一ハードウェアの使用両サイトでの全マシンに対する同一ハードウェアの使用両サイトでマシンに対して同一ハードウェアを使用することによって対称的な環境が提供され、管理および維持が容易になります。このような対称的な環境は、スイッチオーバーやフェイルオーバー後の異なるハードウェアによって発生する障害またはパフォーマンスの非一貫性を軽減します。

サーバー・ソフトウェアの構成に関する推奨事項サーバー・ソフトウェアの構成に関する推奨事項サーバー・ソフトウェアの構成に関する推奨事項サーバー・ソフトウェアの構成に関する推奨事項サーバー・ソフトウェアに関する推奨事項は、RAC 環境のすべてのノード、および Data Guard 環境と MAA 環境のプライマリ・サイトとセカンダリ・サイトの両方に適用されます。これは、それらのノードやサイトに同じ構成が含まれているためです。


� すべてのアーキテクチャに関するサーバー・ソフトウェアの推奨事項

� RAC に関するサーバー・ソフトウェアの推奨事項

すべてのアーキテクチャに関するサーバー・ソフトウェアの推奨事項すべてのアーキテクチャに関するサーバー・ソフトウェアの推奨事項すべてのアーキテクチャに関するサーバー・ソフトウェアの推奨事項すべてのアーキテクチャに関するサーバー・ソフトウェアの推奨事項次の推奨事項は、すべてのアーキテクチャに適用されます。

� 同じ OS のバージョン、パッチ・レベル、単一パッチおよびドライバのバージョンの使用

� ハードウェア障害に対してフォルト・トレラントなオペレーティング・システムの使用

� 適切なスワップ・パーティションの構成

� 今後の拡張を可能にするオペレーティング・システム・パラメータの設定

� ロギングまたはジャーナル・ファイル・システムの使用

� Oracle ソフトウェアとアプリケーション・ソフトウェアを含むミラー・ディスク



同じ同じ同じ同じ OS のバージョン、パッチ・レベル、単一パッチおよびドライバののバージョン、パッチ・レベル、単一パッチおよびドライバののバージョン、パッチ・レベル、単一パッチおよびドライバののバージョン、パッチ・レベル、単一パッチおよびドライバのバージョンの使用バージョンの使用バージョンの使用バージョンの使用すべてのマシンに同じオペレーティング・システムのバージョン、パッチ・レベル、単一パッチおよびドライバのバージョンを使用します。オペレーティング・システムのバージョンおよびパッチ・レベルの一貫性は、すべてのマシンのソフトウェア間での非互換性または小規模な非一貫性が発生する可能性を軽減します。オープン・スタンダードの環境では、すべてのベンダーがすべての新規ソフトウェアを、リリース済のソフトウェアおよびハードウェアのすべての組合せでテストすることは実用的ではありません。目的が、すべてのマシンを同じバージョンまたはパッチ・レベルにアップグレードすることにある場合、個別のシステムまたはシステムのグループとして使用する RAC または Data Guard を計画的停止を小限にするために 1 度に 1 つずつアップグレードまたはパッチするときに一時的な相違は

許容できます。

ハードウェア障害に対してフォルト・トレラントなオペレーティング・ハードウェア障害に対してフォルト・トレラントなオペレーティング・ハードウェア障害に対してフォルト・トレラントなオペレーティング・ハードウェア障害に対してフォルト・トレラントなオペレーティング・システムの使用システムの使用システムの使用システムの使用オペレーティング・システムについては、自動的に障害を検出した後、障害のあるサブシステムの周辺に代替パスを提供できるか、または障害のあるサブシステムを分離できる（適切なハードウェアと連結した場合に）ものを使用します。システムについては、CPU やメモリー・ボードなどの 1 つのコンポーネントで障害が発生し、そのコンポーネントが障害のあるコンポーネントの周辺にアダプタ障害のイベント内の I/O 要求の代替パスのようなパスを自動的に提供する場合に、稼動を継続できるものを選択します。

適切なスワップ・パーティションの構成適切なスワップ・パーティションの構成適切なスワップ・パーティションの構成適切なスワップ・パーティションの構成複数のスワップ・パーティションを含む複数のミラー・ディスクの場合、1 つのスワップ・パーティションを含む 1 つのディスクで障害が発生しても、アプリケーション障害またはシステム障害にはなりません。

RAM ベースのスワップのかわりにディスク・ベースのスワップを使用します。すべてのシステム・メモリーをデータベースおよびアプリケーションに対して使用可能にすることは、使用可能な容量がスワップの対応に大きすぎないかぎり、常に適した業務です。

TMPFS（ディスクよりも仮想メモリーにファイルを格納する Solaris 実装の 1 つ）、または/tmpファイル・システムや他のスクラッチ・ファイル・システムに対して、ストレージのディスクのかわりに仮想メモリーを排他的に使用する他のファイル・システムを使用しないでください。これによって、/tmpに書き込む停止プログラムが、すべての仮想メモリーを使い果たしてシステムを停止させる可能性を防ぎます。

今後の拡張を可能にするオペレーティング・システム・パラメータの設定今後の拡張を可能にするオペレーティング・システム・パラメータの設定今後の拡張を可能にするオペレーティング・システム・パラメータの設定今後の拡張を可能にするオペレーティング・システム・パラメータの設定UNIX の例では、今後の拡張に備えて共有メモリー・パラメータとセマフォ・カーネル・パラメータを十分に高く設定しています。これによって、カーネルの再設定とシステムのリブートによる停止を防ぎます。必要以上に高い設定によってオーバーヘッドが発生していないこと、大規模なシステムの場合は、発生したオーバーヘッドの影響が無視できる程度に小さいことを検証します。



ロギングまたはジャーナル・ファイル・システムの使用ロギングまたはジャーナル・ファイル・システムの使用ロギングまたはジャーナル・ファイル・システムの使用ロギングまたはジャーナル・ファイル・システムの使用ジャーナル・ファイル・システムおよびロギングは、システム・リブートの後に必要なファイル・システム・チェックの数を減少またはなくします。これによって、システムの高速な再起動が容易になります。

Oracle ソフトウェアとアプリケーション・ソフトウェアを含むミラー・ソフトウェアとアプリケーション・ソフトウェアを含むミラー・ソフトウェアとアプリケーション・ソフトウェアを含むミラー・ソフトウェアとアプリケーション・ソフトウェアを含むミラー・ディスクディスクディスクディスクOracle ソフトウェアに関する推奨事項は、プライマリ・サイトとセカンダリ・サイトの両方に適用されます。これは、それらのサイトに同じ構成が含まれているためです。Oracle ソフトウェアとアプリケーション・ソフトウェアを含むミラー・ディスクは、ディスク障害による計画外停止を防ぎます。

RAC に関するサーバー・ソフトウェアの推奨事項に関するサーバー・ソフトウェアの推奨事項に関するサーバー・ソフトウェアの推奨事項に関するサーバー・ソフトウェアの推奨事項次の推奨事項は、RAC のみの環境に適用されます。

� サポートされているクラスタ化ソフトウェアの使用

� すべてのクラスタ・ノード上での Network Time Protocol（NTP）の使用

サポートされているクラスタ化ソフトウェアの使用サポートされているクラスタ化ソフトウェアの使用サポートされているクラスタ化ソフトウェアの使用サポートされているクラスタ化ソフトウェアの使用RAC は、ノード障害とインスタンス障害からの高速で自動的なリカバリを提供します。適切にサポートされている構成の使用は、成功への重要な構成要素です。サポートされているソフトウェア構成には、オペレーティング・システムのバージョンおよびパッチ・レベル、オラクル社が提供するクラスタ・ソフトウェアを含む場合があるクラスタ化ソフトウェアのバージョンが含まれます。一部のプラットフォーム（Solaris、Linux、Windows など）で、オラクル社は RAC での使用に必要なクラスタ・ソフトウェアを提供しています。

すべてのクラスタ・ノード上でのすべてのクラスタ・ノード上でのすべてのクラスタ・ノード上でのすべてのクラスタ・ノード上での Network Time Protocol（（（（NTP）の使用）の使用）の使用）の使用NTP を使用して、クラスタ内のすべてのノード上のクロックを同期化し、タイムスタンプに基づいたトレース情報の分析を容易にします。

関連項目関連項目関連項目関連項目 : 『Oracle Real Application Clusters インストレーションおよび構成』


ネットワークの構成に関する推奨事項

ネットワークの構成に関する推奨事項ネットワークの構成に関する推奨事項ネットワークの構成に関する推奨事項ネットワークの構成に関する推奨事項この項の内容は、次のとおりです。

� すべてのアーキテクチャのネットワーク構成のベスト・プラクティス

� RAC のネットワーク構成のベスト・プラクティス

� Data Guard のネットワーク構成のベスト・プラクティス

すべてのアーキテクチャのネットワーク構成のベスト・プラクティスすべてのアーキテクチャのネットワーク構成のベスト・プラクティスすべてのアーキテクチャのネットワーク構成のベスト・プラクティスすべてのアーキテクチャのネットワーク構成のベスト・プラクティス次の推奨事項は、すべてのアーキテクチャに適用されます。

� すべてのネットワーク・コンポーネントが冗長であることの確認

� ロード・バランサを使用した受信した要求の配信

すべてのネットワーク・コンポーネントが冗長であることの確認すべてのネットワーク・コンポーネントが冗長であることの確認すべてのネットワーク・コンポーネントが冗長であることの確認すべてのネットワーク・コンポーネントが冗長であることの確認表 6-2 では、図 6-1 の図に示されている必要な冗長ネットワーク・コンポーネントを示しています。

表表表表 6-2 冗長ネットワーク・コンポーネント冗長ネットワーク・コンポーネント冗長ネットワーク・コンポーネント冗長ネットワーク・コンポーネント

コンポーネントコンポーネントコンポーネントコンポーネントフォルト・トレランスフォルト・トレランスフォルト・トレランスフォルト・トレランス

外部接続性（遠隔地のIT スタッフを含む）

複数のインターネット・サービス・プロバイダ（ISP）によって、1 つの ISP の障害が

サイトを使用不可能にしないようにします。

注意注意注意注意 : ケーブルは、設備への同じトランク内に格納しないでください。のこぎりやス

コップによって、複数の ISP への接続が同時に切断される危険があります。

WAN トラフィック・

マネージャ

プライマリ WAN トラフィック・マネージャおよびバックアップ WAN トラフィック・

マネージャを使用します。（データベースのみの環境または RAC のみの環境で使用さ

れない）Data Guard を使用する環境では、プライマリ WAN トラフィック・マネー

ジャおよびバックアップ WAN トラフィック・マネージャが各サイトに含まれます。

アプリケーション・ロード・バランサ

クライアント要求をアプリケーション・サーバー層に送るために、冗長アプリケーション・ロード・バランサを実装します。セカンダリ・ロード・バランサは、プライマリ・ロード・バランサへのハートビートとまったく同じに構成する必要があります。プライマリ・ロード・バランサで障害が発生した場合は、セカンダリ・ロード・バランサがテイクオーバー機能を起動します。

ファイアウォール冗長ファイアウォール、およびペア間のロード・バランスを実装します。ファイアウォールを通過する接続は、長くなる傾向があるため（ソケット接続対 HTTP）、ロー

ド・バランシングの決定は、セッションが初期化されるとき、およびセッションが維持されているセッション中に行われる必要があります。使用可能な機能性について、ファイアウォールのベンダーをチェックします。

中間層アプリケーション・サーバー

アプリケーション・サーバー・ファームを実装します。これによって、フォルト・トレランスおよびスケーラビリティが提供されます。



図 6-1 では、冗長ネットワーク・コンポーネントを強調した MAA 環境の単一サイトを示しています。

図図図図 6-1 ネットワーク構成ネットワーク構成ネットワーク構成ネットワーク構成



ロード・バランサを使用した受信した要求の配信ロード・バランサを使用した受信した要求の配信ロード・バランサを使用した受信した要求の配信ロード・バランサを使用した受信した要求の配信アプリケーション・レイヤーのロード・バランサは、論理的にアプリケーション・サーバー・ファームの正面に位置し、アプリケーション・サーバーの 1 つのグループ上で稼動しているサービスに対する単一の IP アドレスを外部に公開しています。すべての要求は、初にロード・バランサによって処理されてから、アプリケーション・サーバー・ファーム内のサーバーの 1 つに配信されます。エンド・ユーザーは、公開された IP アドレスに各自の要求のみをアドレス指定し、どのサーバーがその要求を処理するかはロード・バランサが決定します。

中間層アプリケーション・サーバーの 1 つが要求を処理できない場合、ロード・バランサは後続のすべての要求をファンクション・サーバーにルーティングします。すべてのクライアント要求は単一のハードウェアベースのロード・バランサを通過するため、ロード・バランサはシングル・ポイント障害にならないように冗長にする必要があります。ハードウェアのロード・バランサ部分の障害がサイト全体に有害なため、バックアップ・ロード・バランサはプライマリ・ロード・バランサとのハートビートを持つ構成にします。2 つのロード・バランサのうち 1 つはスタンバイとして構成し、プライマリ・ロード・バランサが使用不可能になった場合のみアクティブになります。

RAC のネットワーク構成のベスト・プラクティスのネットワーク構成のベスト・プラクティスのネットワーク構成のベスト・プラクティスのネットワーク構成のベスト・プラクティスこの推奨事項は、RAC 環境に適用されます。

Oracle インタフェース構成ツールを使用したネットワーク・インタインタフェース構成ツールを使用したネットワーク・インタインタフェース構成ツールを使用したネットワーク・インタインタフェース構成ツールを使用したネットワーク・インタフェースの分類フェースの分類フェースの分類フェースの分類Oracle インタフェース構成（OIFCFG）ツールを使用して、ネットワーク・インタフェースをパブリック、クラスタ・インターコネクトまたはストレージに分類すると、ノード間ネットワーク通信量のために RAC がネットワーク・インタフェースを適切に選択できます。

関連項目関連項目関連項目関連項目 : 『Oracle Real Application Clusters 管理者ガイド』



Data Guard のネットワーク構成のベスト・プラクティスのネットワーク構成のベスト・プラクティスのネットワーク構成のベスト・プラクティスのネットワーク構成のベスト・プラクティス次の推奨事項は、Data Guard に適用されます。

� システム TCP パラメータの適切な構成

� サイト・フェイルオーバー機能を提供する WAN トラフィック・マネージャの使用

システムシステムシステムシステム TCP パラメータの適切な構成パラメータの適切な構成パラメータの適切な構成パラメータの適切な構成送信バッファ・サイズおよび受信バッファ・サイズを制御するシステム TCP パラメータを構成し、ログ転送サービスに対してサイト間の帯域幅を十分に利用できるようにします。多くの場合、特に高速で長い待機時間のネットワークを使用する場合、適切なバッファ・サイズは帯域遅延積（BDP）計算式によって決定されます。

サイト・フェイルオーバー機能を提供するサイト・フェイルオーバー機能を提供するサイト・フェイルオーバー機能を提供するサイト・フェイルオーバー機能を提供する WAN トラフィック・マネートラフィック・マネートラフィック・マネートラフィック・マネージャの使用ジャの使用ジャの使用ジャの使用WAN トラフィック・マネージャは、プライマリ・サイトにあるサービスに初期アクセスを提供します。このマネージャは、プライマリ・サイトが完全に使用不可能になった場合、サイト・フェイルオーバー機能を提供するためにプライマリ・サイトおよびセカンダリ・サイトに実装されます。WAN トラフィック・マネージャを地理的に分離して個別のネットワーク上に配置することによって、ネットワーク障害、またはプライマリ・サイトを使用不可能にする自然災害の影響が軽減されます。


� 7-14 ページ「Data Guard に関する構成上のベスト・プラクティス」

� 送信バッファ・サイズおよび受信バッファ・サイズを制御する TCP パラメータの変更に関する詳細は、使用しているオペレーティング・システムのドキュメントを参照してください。

関連項目関連項目関連項目関連項目 : 10-3 ページ「全体または部分的なサイト・フェイルオーバー」


Oracle 構成のベスト・プラクテ

7
Oracle 構成のベスト・プラクティス構成のベスト・プラクティス構成のベスト・プラクティス構成のベスト・プラクティス
この章では、Oracle 構成のベスト・プラクティスについて説明します。内容は次のとおりです。

� データベースに関する構成上のベスト・プラクティス

� Real Application Clusters に関する構成上のベスト・プラクティス

� Data Guard に関する構成上のベスト・プラクティス

� MAA に関する構成上のベスト・プラクティス

� バックアップおよびリカバリに関する推奨事項

� 高速アプリケーション・フェイルオーバーに関する推奨事項

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

ィス 7-1

データベースに関する構成上のベスト・プラクティス

データベースに関する構成上のベスト・プラクティスデータベースに関する構成上のベスト・プラクティスデータベースに関する構成上のベスト・プラクティスデータベースに関する構成上のベスト・プラクティスこの項で推奨するプラクティスは、システムのパフォーマンス、可用性および MTTR に影響を与えます。これらのプラクティスは、第 4 章「高可用性アーキテクチャ」で説明したシングル・インスタンス・データベース、RAC のみ、Data Guard のみおよび大可用性の各アーキテクチャに適用されます。Oracle Data Guard を使用している場合、この項で説明する推奨事項は、プライマリ・データベースおよびスタンバイ・データベースに対する推奨事項と同じです。プラクティスによってはパフォーマンスが低下する場合がありますが、それらはシステムの停止を減らしたり回避するために必要なプラクティスです。パフォーマンスへの影響を小限にするよりも、システム破損のリスクの低減、またはリカバリのパフォーマンスの向上が優先されます。

この項では、次の推奨事項について説明します。

2 つの制御ファイルの使用CONTROL_FILE_RECORD_KEEP_TIME の十分な日数の設定REDO ログ・ファイルのサイズおよびグループの適切な構成多重オンライン REDO ログ・ファイルARCHIVELOG モードの有効化ブロックのチェックサムの有効化データベース・ブロックのチェックの有効化チェックポイントのアラート・ログへの記録ファスト・スタート・チェックポイントを使用したインスタンス・リカバリ時間の制御タイミングに関するパフォーマンス統計の取得自動 UNDO 管理の使用ローカル管理表領域の使用自動セグメント領域管理の使用一時表領域の使用およびデフォルト一時表領域の指定再開可能領域割当ての使用フラッシュ・リカバリ領域の使用フラッシュバック・データベースの有効化セキュリティに関するベスト・プラクティスの設定Database Resource Manager の使用サーバー・パラメータ・ファイルの使用



2 つの制御ファイルの使用つの制御ファイルの使用つの制御ファイルの使用つの制御ファイルの使用制御ファイルの 2 つのコピーを保持します。1 つの制御ファイルが破損した場合、Oracle インスタンスは破損または欠落した制御ファイルにアクセスすると失敗します。現行制御ファイルのもう 1 つのコピーが使用可能な場合、破損した制御ファイルの位置に正常な制御ファイルをコピーすると、インスタンスを容易に再起動できます。データベースのリカバリは不要です。

CONTROL_FILE_RECORD_KEEP_TIME の十分な日数の設定の十分な日数の設定の十分な日数の設定の十分な日数の設定CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータは、ディスク上のすべてのバックアップ情報を制御ファイルに保存できる値に設定します。各制御ファイルには、200MB を割り当てます。CONTROL_FILE_RECORD_KEEP_TIMEには、制御ファイル内にレコードを保持する日数を指定します。この日数を超えると、そのレコードは再利用の候補になります。CONTROL_FILE_RECORD_KEEP_TIMEの値は、ディスク上にバックアップ・ファイルを保存する長期間（フラッシュ・リカバリ領域のサイズで指定）よりも幾分長い期間を指定します。たとえば、7 日ごとに作成する全体バックアップを 2 つ保持し、毎日作成する増分バックアップとアーカイブ REDO ログ・ファイルを保持できるサイズにフラッシュ・リカバリ領域を設定する場合は、CONTROL_FILE_RECORD_KEEP_TIMEの値を 21 または 30 などに設定します。この日数を超えたレコードは再利用されます。ただし、バックアップ・メタデータは、RMAN Recovery Catalog で使用可能です。

REDO ログ・ファイルのサイズおよびグループの適切な構成ログ・ファイルのサイズおよびグループの適切な構成ログ・ファイルのサイズおよびグループの適切な構成ログ・ファイルのサイズおよびグループの適切な構成オンライン REDO ログ・ファイルは、すべて同じサイズで、通常のアクティビティ時は約 1時間に 1 回切り替えられるように構成する必要があります。また、ピーク・アクティビティ時でも、20 分以上間隔を置いて切り替えられる必要があります。

ログ・スイッチの後に、オンライン・ログ・グループが使用可能になるまで LGWRが待機するのを防ぐには、オンライン・ログ・グループが少なくとも 4 つ必要です。グループは、チェックポイントが未完了のため、またはグループがまだアーカイブされていないために使用不可になる可能性があります。


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





Oracle 構成のベスト・プラクティス 7-3


多重オンライン多重オンライン多重オンライン多重オンライン REDO ログ・ファイルログ・ファイルログ・ファイルログ・ファイルOracle のログ多重化機能を使用して、各 REDO グループに複数の REDO ログ・メンバーを作成します。これによって、いずれかのメンバーのディスク・ミラーの両側に存在するディスクが破損したり、ユーザーがメンバーを誤って削除した場合など、REDO ログに関連する障害からデータベースを保護できます。少なくとも 1 つの REDO ログ・メンバーが使用可能であれば、インスタンスは継続して機能します。

ARCHIVELOG モードの有効化モードの有効化モードの有効化モードの有効化データベースがオンラインで、リストアされた後の時点にデータベースをリカバリする必要がある場合は、ARCHIVELOGモードを使用するとデータベースをバックアップできます。

Oracle Data Guard を含むアーキテクチャでは、スタンバイ・データベースがインスタンス化される前に本番データベースを ARCHIVELOGモードで実行する必要があります。スタンバイ・データベースをメンテナンスするには、ARCHIVELOGモードであることが必要です。

ブロックのチェックサムの有効化ブロックのチェックサムの有効化ブロックのチェックサムの有効化ブロックのチェックサムの有効化デフォルトでは、ディスクから読み込まれるデータ・ブロックは常にテストされます。DB_BLOCK_CHECKSUMを TRUEに設定してデータ・ブロックおよびログ・ブロックのチェックサムを有効にすると、基礎となるディスク、ストレージ・システムまたは I/O システムで発生した他のタイプの破損も検出されます。データ・ブロックがディスクに書き込まれる前に、チェックサムが計算されてブロック内に格納されます。後でそのブロックがディスクから読み込まれると、チェックサムが再度計算され、格納されているチェックサムと比較されます。チェックサムが異なる場合は、メディア・エラーとして処理され、ORA-01578 エラーが表示されます。ブロックのチェックサムは、常に SYSTEM表領域でメンテナンスされます。

データ・ブロックのチェックサムの計算の他に、すべての REDO ログ・ブロックについても現行ログに書き込まれる前にそのチェックサムが計算されます。REDO レコードの破損は、ログがアーカイブされるとただちに検出されます。このオプションを使用しないと、REDO ログの破損は、ログがスタンバイ・データベースに適用されるまで、またはバックアップがリストアされて破損したログ・ブロックを含むログにロールフォワードされるまで、検出されない可能性があります。

Recovery Manager でもバックアップを作成するときにチェックサムを計算して、バックアップするすべてのブロックの妥当性をチェックします。


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



この機能をオンにしても、通常、オーバーヘッドは小限で済みます。アクティブ・データベースでこの機能をオンにする前に、テスト・システムでワークロードを使用してパフォーマンスへの影響を測定し、パフォーマンスへの影響が許容範囲内であることを確認してください。

データベース・ブロックのチェックの有効化データベース・ブロックのチェックの有効化データベース・ブロックのチェックの有効化データベース・ブロックのチェックの有効化DB_BLOCK_CHECKINGを TRUEに設定して、データベース・ブロックのチェックを有効にします。ブロックのチェックを有効にすると、ブロックが変更されるたびに、そのブロックの首尾一貫性が検証されます。一貫性がない場合、そのブロックは破損とマークされ、ORA-01578 エラーが返されます。さらに、問題の詳細が含まれたトレース・ファイルが作成されます。ブロックのチェックを有効にしないと、ブロックが再度アクセスされるまで破損が検出されない可能性があります。SYSTEM表領域では、常にブロックのチェックが有効になります。

多くの場合、ブロックをチェックすることで、メモリーやデータの破損を防止できます。この機能をオンにすると、通常は、ワークロードに応じて 1 ～ 10 パーセントのオーバーヘッドが発生します。アクティブ・データベースでこの機能をオンにする前に、テスト・システムでワークロードを使用してパフォーマンスへの影響を測定し、パフォーマンスへの影響が許容範囲内であることを確認してください。

Oracle 外部のブロックが破損していないことを確認するには、次のいずれかを使用します。

� VALIDATEオプションを指定した Recovery Manager の BACKUPコマンド

� DBVERIFYユーティリティ

� ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE SQL 文

チェックポイントのアラート・ログへの記録チェックポイントのアラート・ログへの記録チェックポイントのアラート・ログへの記録チェックポイントのアラート・ログへの記録LOG_CHECKPOINT_TO_ALERTを TRUEに設定して、チェックポイント・アクティビティをアラート・ログに記録する必要があります。チェックポイント・アクティビティを監視して、現行のチェックポイントの完了後に次のチェックポイントが開始されることを確認します。



関連項目関連項目関連項目関連項目 : 『Oracle Database リファレンス』



ファスト・スタート・チェックポイントを使用したインスタンス・リカバリファスト・スタート・チェックポイントを使用したインスタンス・リカバリファスト・スタート・チェックポイントを使用したインスタンス・リカバリファスト・スタート・チェックポイントを使用したインスタンス・リカバリ時間の制御時間の制御時間の制御時間の制御

ファスト・スタート・チェックポイントとは、データベース・ライター（DBWn）・プロセスによる定期的な書込みを意味します。DBWnプロセスでは、変更されたデータ・ブロックをOracle バッファ・キャッシュからディスクに書き込み、スレッドのチェックポイントを前進させます。ファスト・スタート・チェックポイントを使用すると、チェックポイントが継続して前進するため、インスタンス障害またはノード障害からのリカバリ時間を予測できます。

Oracle Database 10g は、自動チェックポイント・チューニングをサポートしています。この機能は、I/O 使用率が低い期間を利用してチェックポイントを前進させるため、可用性が向上します。自動チェックポイント・チューニングは、FAST_START_MTTR_TARGETデータベース初期化パラメータが設定されていない場合に有効になります。次の推奨事項を検討して自動チェックポイント・チューニングを使用してください。

� インスタンス障害またはノード障害からのリカバリ時間を制御する必要がある場合は、FAST_START_MTTR_TARGETに適切な MTTR（秒単位）を設定します。

� MTTR を指定する必要がない場合は、FAST_START_MTTR_TARGETを未設定のままにすると自動チェックポイント・チューニングが有効になります。

� ファスト・スタート・チェックポイントを無効にするには、FAST_START_MTTR_TARGET=0を設定します。システムの I/O 容量が不十分でファスト・スタート・チェックポイントを有効にできず、MTTR を指定する必要がない場合のみ、ファスト・スタート・チェックポイントを無効にしてください。

ファスト・スタート・チェックポイントを有効にすると、DBWnで指定のワークロードに対して発行するトランザクション当たりの平均書込み数が、ファスト・スタート・チェックポイントを無効にした場合に比べて増加します。ただし、システムの I/O 容量が大または大近くになっている場合は、ファスト・スタート・チェックポイントによってパフォーマンスがわずかに低下します。アグレッシブなファスト・スタート・チェックポイントによってDBWnの書込みがどの程度増加するかは、ワークロード、I/O の速度と容量、CPU の速度と容量、以前のリカバリのパフォーマンスなど、多くの要因によって決まります。

V$MTTR_TARGET_ADVICEビューを監視して、FAST_START_MTTR_TARGETに異なる値を設定した場合の I/O 操作の増加数の見積りや推奨情報を取得してください。また、ロード時に FAST_START_MTTR_TARGETの様々な設定値（たとえば、0、1、90、180、270、3600、未設定など）をテストして、特定のシステムへの実行時の影響（たとえば、DBWn書込みアクティビティの増加数）、およびその設定でのインスタンス・リカバリ時間を調べてください。

FAST_START_MTTR_TARGETを低い値に設定すると、ファスト・スタート・チェックポイントはアグレッシブになり、指定された MTTR でスレッドのチェックポイントを十分に前進させるために、DBWnが発行するトランザクション当たりの平均書込み数が増加します。逆に、FAST_START_MTTR_TARGETを高い値に設定した場合、または自動チェックポイント・チューニングが有効な場合（つまり、FAST_START_MTTR_TARGETが未設定の場合）、



ファスト・スタート・チェックポイントはアグレッシブにならず、DBWnが発行するトランザクション当たりの平均書込み数は減少します。

ファスト・スタート・チェックポイントを明示的に無効にするには、FAST_START_MTTR_TARGET=0を設定します。ファスト・スタート・チェックポイントを無効にすると、特定のワークロードと構成に対して DBWnが発行するトランザクション当たりの平均書込み数は小になりますが、MTTR は大になります。

ファスト・スタート・チェックポイントを有効にする場合は、LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUTおよび FAST_START_IO_TARGETの各初期化パラメータを削除または無効（0に設定）にしてください。

タイミングに関するパフォーマンス統計の取得タイミングに関するパフォーマンス統計の取得タイミングに関するパフォーマンス統計の取得タイミングに関するパフォーマンス統計の取得Oracle イベントのタイミングに関するデータを取得するには、TIMED_STATISTICS初期化パラメータを TRUEに設定します。このパラメータは、STATISTICS_LEVELデータベース・パラメータがデフォルト値の TYPICALに設定されている場合、デフォルトで TRUEに設定されます。システムのパフォーマンス問題を識別して修正するには、有効なデータを収集して分析することが不可欠です。Oracle には、パフォーマンス担当の技術者がインスタンスやデータベースのパフォーマンスに関する情報を収集できる、いくつかのツールが用意されています。これらの Oracle Tools を有効に使用するには、TIMED_STATISTICSを TRUEに設定する必要があります。

関連項目関連項目関連項目関連項目 : 『Oracle Database パフォーマンス・チューニング・ガイド』


� Oracle のパフォーマンス方法および新しいパフォーマンス・チューニング機能については、『Oracle Database パフォーマンス・チューニング・ガイド』を参照してください。

� Oracle Enterprise Manager で使用可能な監視ツールおよび診断ツールについては、『Oracle Enterprise Manager 概要』を参照してください。

� DBMS_ADVISOR、DBMS_SQLTUNEおよび DBMS_WORKLOAD_REPOSITORY PL/SQL パッケージについては、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。



自動自動自動自動 UNDO 管理の使用管理の使用管理の使用管理の使用自動 UNDO 管理を使用すると、Oracle サーバーは UNDO 領域を効率的に管理できるため、管理業務の複雑さが軽減され、管理コストも削減できます。UNDO セグメントを内部的に管理すると、現行のワークロード要件に応じて UNDO セグメントのサイズと数が自動的に調整されるため、UNDO ブロックと読取り一貫性の競合が解消されます。

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

� UNDO_MANAGEMENT = AUTO

� UNDO_RETENTIONには、UNDO データを保存する期間を秒単位で指定します。すべてのインスタンスで同じ値を指定する必要があります。

� UNDO_TABLESPACEには、各インスタンスに一意の UNDO 表領域を指定します。

フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション問合せ、フラッシュバック・テーブルなどオブジェクト・リカバリの拡張機能では、自動 UNDO 管理を使用する必要があります。これらの機能は、UNDO_RETENTIONの設定値に依存します。保存期間は、秒単位で指定します。Oracle はデフォルトで、データベース使用統計を収集して UNDO に必要な領域の量を見積り、UNDO の保存期間を自動的にチューニングします。この自動チューニングに影響を与えるには、UNDO_RETENTION初期化パラメータを設定します。UNDO_RETENTIONのデフォルト値は 900です。Oracle でUNDO の保存期間をチューニングする場合、このパラメータの設定は必要ありません。UNDO_RETENTIONの値は、ALTER SYSTEM文を使用していつでも動的に変更できます。

UNDO_RETENTIONを設定しても、指定した期間、UNDO データが保存されるとはかぎりません。トランザクションで UNDO データが必要な場合は UNDO_RETENTIONの期間が短縮されるため、トランザクションで必要な UNDO データを取得できるようになります。

UNDO データの生成が必要となるその後の操作の失敗によって、期限切れでない UNDOデータが上書きされないように保証できます。そのためには、CREATE DATABASE文またはCREATE UNDO TABLESPACE文を使用して UNDO 表領域を作成するときに、その UNDO表領域に対して RETENTION GUARANTEE句を指定します。または、後でこの句を ALTER TABLESPACE文で指定することもできます。

RETENTION GUARANTEE オプションを指定すると、UNDO が DML アクティビティで必要な場合でも、UNDO の保存が保証されます（DDL 文の実行は許可されます）。トランザクションのスループットで必要な領域よりも少ない領域で表領域が構成されている場合は、次の 4 つの現象が順番に発生します。

1. 自動拡張可能ファイルを使用している場合、そのファイルは、保存対象の UNDO データに対応して自動的に拡張されます。

2. 85 パーセントまで満杯になると、警告のアラートが発行されます。

3. 97 パーセントまで満杯になると、重大なアラートが発行されます。

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



ローカル管理表領域の使用ローカル管理表領域の使用ローカル管理表領域の使用ローカル管理表領域の使用ローカル管理表領域を使用すると、ディクショナリ管理表領域に比べてパフォーマンスが向上し、管理が容易になり、領域の断片化の問題がなくなります。ローカル管理表領域では、データファイル・ヘッダーに格納されているビットマップを使用し、ディクショナリ管理表領域とは異なり、領域の割当てと割当て解除の際に一元管理されるリソースを求めて競合することはありません。

自動セグメント領域管理の使用自動セグメント領域管理の使用自動セグメント領域管理の使用自動セグメント領域管理の使用自動セグメント領域管理を使用すると、領域管理タスクが簡素化されるため、人為的なエラーの発生が減少します。もう 1 つの利点は、領域管理に関連したパフォーマンス・チューニングが不要になることです。オブジェクト（表や索引など）内の空き領域の管理が容易になり、領域の使用効率が向上します。さらに、管理が簡素化されることによって、パフォーマンスとスケーラビリティが大幅に向上します。自動セグメント領域管理機能は、永続的なローカル管理表領域でのみ使用可能です。

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

一時表領域句を誤って指定しないように、デフォルト一時表領域はデータベース全体に対して指定する必要があります。そのためには、データベース作成時に CREATE DATABASE文の DEFAULT TEMPORARY TABLESPACE句を使用するか、またはデータベース作成後にALTER DATABASE文を使用します。デフォルト一時表領域を使用すると、すべてのディスク・ソートは一時表領域内で実行されるため、他の表領域をソート用に誤って使用することはありません。

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






再開可能領域割当ての使用再開可能領域割当ての使用再開可能領域割当ての使用再開可能領域割当ての使用再開可能領域割当てによって、領域割当てが失敗した場合にデータベース操作を一時停止し、後で再開するための方法が提供されます。影響を受ける操作は一時停止し、データベースはエラーを返しません。プロセスの再起動は不要です。領域の問題が解決すると、一時停止した操作は自動的に再開します。

RESUMABLE_TIMEOUT初期化パラメータに、再試行時間を秒数で設定します。

フラッシュ・リカバリ領域の使用フラッシュ・リカバリ領域の使用フラッシュ・リカバリ領域の使用フラッシュ・リカバリ領域の使用フラッシュ・リカバリ領域は、Oracle が管理するディレクトリ、ファイル・システムまたはAutomatic Storage Management のディスク・グループで、バックアップおよびリカバリのファイルを集中管理するためのディスク位置です。フラッシュ・リカバリ領域は、次のデータベース初期化パラメータを設定して定義します。

� DB_RECOVERY_FILE_DEST: フラッシュ・リカバリ領域のデフォルト位置

� DB_RECOVERY_FILE_DEST_SIZE: リカバリ領域の位置で作成されたターゲット・データベース・リカバリ・ファイルで使用される合計領域に関して、ハード上の制限をバイト単位で指定します。

フラッシュ・リカバリ領域が大きいほど、その利点も多くなります。推奨するディスク小限度は、データベース・サイズ、増分バックアップのサイズ、テープにコピーしていないすべてのアーカイブ REDO ログのサイズ、およびフラッシュバック・ログのサイズの合計です。


関連項目関連項目関連項目関連項目 : フラッシュ・リカバリ領域のサイズおよび保存期間の設定の詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』および『Oracle Database バックアップおよびリカバリ基礎』を参照してください。



フラッシュバック・データベースの有効化フラッシュバック・データベースの有効化フラッシュバック・データベースの有効化フラッシュバック・データベースの有効化フラッシュバック・データベースは画期的なリカバリ機能で、変更されたデータに対してのみ使用します。この機能によって、エラーの発生時点までデータベースを戻してエラーを修正でき、データベースのサイズによって決まるリカバリ時間は必要ありません。データベースは 1 つのコマンドを使用して Recovery Manager および SQL*Plus からフラッシュバックでき、複雑なプロシージャは必要ありません。フラッシュバック・データベースは従来のPoint-in-Time リカバリと効果は同じで、データベースを過去のある時点の状態に戻すことができます。ただし、フラッシュバック・データベースは、バックアップまたは広範囲なアプリケーションの REDO データからデータファイルをリストアする必要がないため、Point-in-Time リカバリよりもはるかに高速です。

フラッシュバック・データベースを有効にするには、フラッシュ・リカバリ領域を設定し、フラッシュバック保存期間のターゲット（DB_FLASHBACK_RETENTION_TARGET初期化パラメータ）を設定します。これによって、フラッシュバック・データベースを使用して、データベースをリストアする過去の時点を分単位で指定できます。ALTER DATABASE FLASHBACK ON文を実行すると、フラッシュバック・データベースが有効になります。フラッシュバック保存期間のターゲットは目安であり、フラッシュバック・データベースが使用可能であることを完全に保証するものではありません。フラッシュ・リカバリ領域に十分な領域がないため、アーカイブ REDO ログや他のバックアップなどの必要なファイルを保持できない場合は、必要なファイルを保持するための領域をフラッシュ・リカバリ領域に確保するために、フラッシュバック・ログが削除される場合があります。過去のどの時点までさかのぼってフラッシュバックできるかを判断するには、V$FLASHBACK_DATABASE_LOGビューを問い合せます。スタンバイ・データベースを使用している場合は、プライマリ・データベースとスタンバイ・データベースの両方について FLASHBACK_RETENTION_TIMEを同じ値に設定します。

セキュリティに関するベスト・プラクティスの設定セキュリティに関するベスト・プラクティスの設定セキュリティに関するベスト・プラクティスの設定セキュリティに関するベスト・プラクティスの設定企業データは、従業員や契約者によるネットワークや設備への内部アクセスによっても脅威にさらされます。企業データはその企業のも貴重な財産の 1 つであるため、適切なセキュリティ保護手段のないシステムまたはデータベース上に配置すると、企業データは非常に危険な状態に置かれることになります。セキュリティ・ポリシーを明確に定義することは、システムへの不正なアクセスを防止し、機密性の高い企業情報を不正行為から保護するために役立ちます。適切なデータ保護によって、セキュリティ違反によるシステム停止を減少できます。

高水準のガイドである『Oracle セキュリティ概要』では、第 9 章「Oracle のセキュリティ製品および機能」の「高可用性」の項以外にも、データ・セキュリティ要求に対する技術的ソリューションについて説明しています。セキュリティに関するベスト・プラクティスを実装するための手法の概要は、『Oracle セキュリティ概要』の第 II 部「セキュリティ・リスクに対する技術的ソリューション」を参照してください。セキュリティに関するポリシー、




チェックリスト、ガイドラインおよび機能の詳細は、『Oracle Database セキュリティ・ガイド』を参照してください。

Database Resource Manager の使用の使用の使用の使用データベース管理者は、Database Resource Manager を使用してリソース管理に関する決定を厳密に制御できるため、企業のビジネス目標に基づいてリソース割当てを調整できます。また、Database Resource Manager を使用して、Oracle システム内の作業に優先順位を設定できます。データベースの可用性には、その機能とパフォーマンスが含まれます。データベースが使用可能でも、ユーザーの求めるレベルのパフォーマンスが得られない場合、データベースの可用性とサービスのレベルは目標に達していません。ほとんどの場合、アプリケーションのパフォーマンスは、データベースにアクセスするアプリケーション間でのリソースの分散方法に影響されます。Database Resource Manager の主な目的は、Oracle データベース・サーバーがリソース管理に関する決定を厳密に制御することによって、非効率的なオペレーティング・システム管理やオペレーティング・システム・リソース・マネージャから生じる問題を回避することです。

サーバー・パラメータ・ファイルの使用サーバー・パラメータ・ファイルの使用サーバー・パラメータ・ファイルの使用サーバー・パラメータ・ファイルの使用サーバー・パラメータ・ファイル（SPFILE）を使用すると、中核となる単一のパラメータ・ファイルに、データベースに関連付けられた全インスタンスに関するデータベース初期化パラメータをすべて保持できます。これによって、単純で永続的かつ堅牢な環境でデータベース・パラメータを管理できます。

SPFILEは、Data Guard Broker を使用する際に必要です。

関連項目関連項目関連項目関連項目 : 『Oracle セキュリティ概要』および『Oracle Database セキュリティ・ガイド』




� 『Oracle Real Application Clusters 管理者ガイド』

� 『Oracle Data Guard Broker』

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


Real Application Clusters に関する構成上のベスト・プラクティス

Real Application Clusters に関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスこの項で推奨するプラクティスは、システムのパフォーマンス、可用性および MTTR に影響を与えます。これらのプラクティスは、シングル・インスタンス・データベースの構成上のベスト・プラクティスに基づいています。プライマリ・データベースとスタンバイ・データベースを MAA アーキテクチャで Data Guard とともに使用している場合、プライマリ・データベースとスタンバイ・データベースに関するプラクティスは同じです。プラクティスによってはパフォーマンス・レベルが低下する場合がありますが、それらはシステムの停止を減らしたり回避するために必要なプラクティスです。パフォーマンスへの影響を小限にするよりも、システム破損のリスクの低減、またはリカバリのパフォーマンスの向上が優先されます。


� リモート・リスナーを使用した全インスタンスの登録

� スケーラビリティに必要ないかぎり CLUSTER_INTERCONNECTS を設定しない

リモート・リスナーを使用した全インスタンスの登録リモート・リスナーを使用した全インスタンスの登録リモート・リスナーを使用した全インスタンスの登録リモート・リスナーを使用した全インスタンスの登録すべてのリスナーがサービスおよびサービスが実行されているインスタンスをすべて認識できるように、REMOTE_LISTENERパラメータを使用してリスナーを相互に登録する必要があります。また、リスナーは、接続のセッション・カウントに基づくサーバー側ロード・バランシングを使用する必要があります。リスナーは、仮想 IP アドレスおよびクラスタの別名

（使用可能な場合）でリスニングする必要があります。ホスト名でリスニングする必要はありません。ホスト名でリスニングすると、仮想 IP が所有ノードに自動的に再配置されたときにセッションが切断されます。

スケーラビリティに必要ないかぎりスケーラビリティに必要ないかぎりスケーラビリティに必要ないかぎりスケーラビリティに必要ないかぎり CLUSTER_INTERCONNECTS を設定しないを設定しないを設定しないを設定しないCLUSTER_INTERCONNECTS初期化パラメータは、複数のクラスタ・インターコネクトがあり、デフォルトのクラスタ・インターコネクトが RAC データベースのスループット要件を満たしていない場合にのみ設定する必要があります。CLUSTER_INTERCONECTSに複数のネットワーク・アドレスを設定すると、Oracle ではインタフェース間でロード・バランスを実行します。ただし、Oracle で利用できる自動フェイルオーバー機能がないため、適切に機能しているデータベース環境ですべてのインタフェースが使用可能であることが必要です。




� 『Oracle Net Services 管理者ガイド』



Data Guard に関する構成上のベスト・プラクティス

Data Guard に関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスこの項で説明するプラクティスは、シングル・インスタンス・データベースの構成に関する推奨事項に基づいています。すべてのスタンバイ・データベースが適切に稼働し、スイッチオーバーやフェイルオーバーの後にサービス・レベル内でそのロールを実行するためには、Oracle Data Guard の REDO Apply および SQL Apply を適切に構成することが重要です。ほとんどの場合、Data Guard の構成は Oracle Enterprise Manager を使用して設定できます。頻繁に使用しない高度な Data Guard 構成パラメータは、Data Guard Broker のコマンドライン・インタフェースまたは SQL*Plus を使用して設定できます。

Data Guard を使用すると、ビジネス要件に応じて、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースのいずれか、あるいは両方を使用できます。フィジカル・スタンバイ・データベースでは、プライマリ・データベースとブロック単位で同一のディスク上データベース構造を持ち、プライマリ・データベースと物理的に同一のコピーを使用できます。索引などのデータベース・スキーマも同一です。フィジカル・スタンバイ・データベースは、プライマリ・データベースから受信した REDO データを適用することによって、プライマリ・データベースとの同期を維持します。

ロジカル・スタンバイ・データベースには、本番データベースと同一の論理情報が格納されますが、データの物理的な構成や構造は異なる場合があります。ロジカル・スタンバイ・データベースは、プライマリ・データベースから受信した REDO ログ・ファイルのデータを SQL 文に変換し、その SQL 文をスタンバイ・データベースで実行することによって、プライマリ・データベースとの同期を維持します。ロジカル・スタンバイ・データベースは、障害時にリカバリで必要になるばかりでなく、他のビジネス目的にも使用できます。

表 7-1 を参照して、使用するスタンバイ・データベースの種類を決定してください。

表表表表 7-1 スタンバイ・データベースの種類の決定スタンバイ・データベースの種類の決定スタンバイ・データベースの種類の決定スタンバイ・データベースの種類の決定

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

1. ロジカル・スタンバイ・データベースでサポートしていないデータ型を使用しますか。

次の問合せを実行します。

SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED ORDER BY OWNER, TABLE_NAME;

行が返される場合 : フィジカル・スタンバイ・データ

ベースを使用するか、サポートされているデータ型への変更を検討してください。

行が返されない場合 : 次の質問に進んでください。

2. スタンバイ・データベースを読取り専用または読取り/ 書込みアクセスでオープンする必要がありますか。

関連項目関連項目関連項目関連項目 : Oracle Technology Network Japan にある

『Oracle Data Guard SQL Apply Best Practices』を参照して

ください。

はい : ロジカル・スタンバイ・データベースを評価し

てください。

いいえ : フィジカル・スタンバイ・データベースを使

用してください。



表 7-2 に、構成に関する推奨事項を示します。ここでは、ロジカル・スタンバイ・データベースとフィジカル・スタンバイ・データベースの両方に適用できる推奨事項、およびロジカルのみまたはフィジカルのみに適用できる推奨事項を示します。

表表表表 7-2 スタンバイ・データベースの構成に関する推奨事項スタンバイ・データベースの構成に関する推奨事項スタンバイ・データベースの構成に関する推奨事項スタンバイ・データベースの構成に関する推奨事項

フィジカルおよびロジカル・フィジカルおよびロジカル・フィジカルおよびロジカル・フィジカルおよびロジカル・スタンバイ・データベースの両方にスタンバイ・データベースの両方にスタンバイ・データベースの両方にスタンバイ・データベースの両方に関する推奨事項関する推奨事項関する推奨事項関する推奨事項

フィジカル・スタンバイ・フィジカル・スタンバイ・フィジカル・スタンバイ・フィジカル・スタンバイ・データベースのみに関する推奨事項データベースのみに関する推奨事項データベースのみに関する推奨事項データベースのみに関する推奨事項

ロジカル・スタンバイ・ロジカル・スタンバイ・ロジカル・スタンバイ・ロジカル・スタンバイ・データベースのみに関する推奨事項データベースのみに関する推奨事項データベースのみに関する推奨事項データベースのみに関する推奨事項

単純で堅牢なアーカイブ計画と構成の使用

メディア・リカバリのパフォーマンスのチューニング

補助ロギングおよび主キー制約の使用

多重スタンバイ REDO ログの使用

およびサイズの適切な構成 - MAX_SERVERS 初期化パラメータの

設定

FORCE LOGGING モードの有効化 - PARALLEL_MAX_SERVERS 初期化

パラメータ値の増加

リアルタイム適用の使用 - TRANSACTION_CONSISTENCY初期化パラメータの設定

動的サービス登録用のデータベースおよびリスナーの構成

- 不要なオブジェクトに対する SQL Apply のスキップ

WAN 環境でのネットワークのチュー

ニング

- -

データ保護モードの決定 - -

ネットワーク構成案によるパフォーマンス評価の実施

- -

大可用性モードまたは大保護モードでの LAN または MAN の使用

- -

大のパフォーマンス・スループットを得るための ARCH の使用

- -

データ消失を制御するための ASYNC属性の使用

- -

圧縮を使用した SSH ポート転送の

評価

- -

LOG_ARCHIVE_LOCAL_FIRST を

TRUE に設定

- -

REDO データの安全な転送 - -



単純で堅牢なアーカイブ計画と構成の使用単純で堅牢なアーカイブ計画と構成の使用単純で堅牢なアーカイブ計画と構成の使用単純で堅牢なアーカイブ計画と構成の使用ここで説明するアーカイブ計画は、次の想定に基づいています。

� すべてのインスタンスでフラッシュ・リカバリ領域を使用します。

� 本番インスタンスでは、1 つの適用インスタンスにのみリモートでアーカイブします。

表 7-3 に、堅牢なアーカイブ計画に関する推奨事項を示します。

DB_UNIQUE_NAME の設定 - -

LOG_ARCHIVE_CONFIG の適切な

設定

- -



� 『Oracle Database リファレンス』

表表表表 7-3 アーカイブに関する推奨事項アーカイブに関する推奨事項アーカイブに関する推奨事項アーカイブに関する推奨事項

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

アーカイブは、プライマリ・データベースで開始する必要があります。

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

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のように

指定します。

表表表表 7-2 スタンバイ・データベースの構成に関する推奨事項（続き）スタンバイ・データベースの構成に関する推奨事項（続き）スタンバイ・データベースの構成に関する推奨事項（続き）スタンバイ・データベースの構成に関する推奨事項（続き）

フィジカルおよびロジカル・フィジカルおよびロジカル・フィジカルおよびロジカル・フィジカルおよびロジカル・スタンバイ・データベースの両方にスタンバイ・データベースの両方にスタンバイ・データベースの両方にスタンバイ・データベースの両方に関する推奨事項関する推奨事項関する推奨事項関する推奨事項

フィジカル・スタンバイ・フィジカル・スタンバイ・フィジカル・スタンバイ・フィジカル・スタンバイ・データベースのみに関する推奨事項データベースのみに関する推奨事項データベースのみに関する推奨事項データベースのみに関する推奨事項

ロジカル・スタンバイ・ロジカル・スタンバイ・ロジカル・スタンバイ・ロジカル・スタンバイ・データベースのみに関する推奨事項データベースのみに関する推奨事項データベースのみに関する推奨事項データベースのみに関する推奨事項



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

*.DB_RECOVERY_FILE_DEST=/recoveryarea*LOG_ARCHIVE_DEST_1='SERVICE=SALES LGWR AFFIRM REOPEN=15 MAX_FAILURE=10 VALID_FOR=(ONLINE+LOGFILES, ALL ROLES)'*.LOG_ARCHIVE_DEST_STATE_1='ENABLE'*.STANDBY_ARCHIVE_DEST='USE_DB_RECOVERY_FILE_DEST'

アーカイバ・プロセス（ARCH）で初に

ローカル・アーカイブを実行します。

ARCHを使用すると、LGWRでの作業が軽減されます。LOG_ARCHIVE_LOCAL_FIRSTはデフォルトで TRUEに設定されます。この場合、

REDO ログは少なくとも 1 つのローカル・アーカイブ先に正常にアー

カイブされた後、リモート・アーカイブ先に転送されます。フラッシュ・リカバリ領域を使用する場合は、LOG_ARCHIVE_DEST_10を使

用してローカル・アーカイブが実行されます。

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

ンスタンスとノードに対してのみ実行する必要があります。

すべての本番インスタンスは、同じネット・サービス名を使用して、1つのスタンバイ・アーカイブ先にアーカイブします。プライマリ・スタンバイ・インスタンスが停止したとき、セカンダリ・スタンバイ・ホストに自動的に切り替える場合は、Oracle Net Services の接続時

フェイルオーバーが使用されます。

スタンバイ・アーカイブ先でフラッシュ・リカバリ領域を使用する必要があります。

処理を簡略にするため、スタンバイ・アーカイブ先（STANDBY_ARCHIVE_DEST）では、フラッシュ・リカバリ領域としてローカル・

アーカイブ用と同じディレクトリを使用する必要があります。SRL が

存在するため、スタンバイ ARCHプロセスではローカル・アーカイブ

先に書き込みます。

ロジカル・スタンバイ・アーカイブ先ではフラッシュ・リカバリ領域を使用できません。

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

ください。

VALID_FOR属性を使用して、ロールベース

の接続先を指定します。

VALID_FOR属性を使用すると、プライマリおよびスタンバイ・データ

ベース・ロールの接続先属性を 1 つのサーバー・パラメータ・ファイ

ル（SPFILE）に構成できるため、ロールの推移後も Data Guard 構成

は適切に機能します。これによって、ロールの推移後にロール固有のパラメータ・ファイルを有効または無効にする必要がなくなるため、スイッチオーバーおよびフェイルオーバーが簡素化されます。

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

イルのサンプル」

表表表表 7-3 アーカイブに関する推奨事項（続き）アーカイブに関する推奨事項（続き）アーカイブに関する推奨事項（続き）アーカイブに関する推奨事項（続き）

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



この例では、次の点に注意してください。

� Oracle Data Guard の大可用性モードまたは大保護モードでは、LOG_ARCHIVE_DEST_n初期化パラメータの LGWR SYNC=NOPARALLELオプションは決して使用しないことをお薦めします。常にデフォルトの SYNC=PARALLELを使用してください。スタンバイ・インスタンスが失敗した後の障害検出は、LOG_ARCHIVE_DEST_n初期化パラメータの NET_TIMEOUTオプションで指定された時間内に発生します。さらに、ほとんどの構成では NET_ TIMEOUTを 30 秒に設定することをお薦めします。

� REOPEN=15 MAX_FAILURE=10設定は、接続が失敗した場合に、15 秒後に接続を再オープンし、大 10 回まで再試行することを意味します。

� VALID_FOR句は、アーカイブ先のロールを指定するために使用します。データベースがフィジカル・スタンバイ・ロールの場合、フィジカル・スタンバイ・データベースではオンライン・ログ・ファイルを使用しないため、リモート・アーカイブ先LOG_ARCHIVE_DEST_1は使用されません。

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

スタンバイ・データベース・ノードでは、ノード 1 が失敗して再起動できない場合は、別のノードからリカバリする必要があります。この場合、別のノードにすでに存在するいずれかのスタンバイ・インスタンスが管理リカバリを開始できます。スタンバイ・アーカイブREDO ログ・ファイルがアクセス不可能なとき、悪の場合、別のノード上の新しい管理リカバリ・プロセス（MRP）またはロジカル・スタンバイ・プロセス（LSP）では、FAL サーバーを使用してアーカイブ REDO ログ・ファイルをフェッチし、本番ノードからアーカイブ REDO ログ・ファイルを直接取得します。

ハードウェア・ベンダーの共有ファイル・システム・テクノロジを構成するときは、パフォーマンスおよび可用性への影響を検証してください。また、この方法を採用する前に、次の問題について調査してください。

� ノード障害の数に関係なく、任意のノードから共有ファイル・システムにアクセス可能か。

� 共有ファイル・システムを実装した場合、パフォーマンスへの影響があるか。

� インターコネクト通信量への影響があるか。



多重スタンバイ多重スタンバイ多重スタンバイ多重スタンバイ REDO ログの使用およびサイズの適切な構成ログの使用およびサイズの適切な構成ログの使用およびサイズの適切な構成ログの使用およびサイズの適切な構成スタンバイ REDO ログ（SRL）は、両方のサイトで使用する必要があります。Oracle のログ多重化機能を使用して、各スタンバイ REDO グループに複数のスタンバイ REDO ログ・メンバーを作成します。これによって、いずれかのメンバーのディスク・ミラーの両側に存在するディスクが破損したり、ユーザーがメンバーを誤って削除した場合など、REDO ログに関連する障害からデータベースを保護できます。

SRL の数は、次の式を使用して決定します。

# of SRLs = sum of all production online log groups per thread + number of threads

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

次に、SRL を作成する際の追加のガイドラインを示します。

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

� 本番データベースとスタンバイ・データベースの両方で、オンライン REDO ログと SRLはすべて同じサイズにする必要があります。

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

� RAC 環境では、SRL は共有ディスク上に存在する必要があります。

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

ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 10 '/dev/vx/rdsk/ha10-dg/DGFUN stbyredo10 01.log' SIZE 50M REUSE;

スタンバイ・データベースのリモート・ファイル・サーバー（RFS）プロセスは、本番データベースのオンライン REDO ログと同じサイズの SRL にのみ書き込みます。適切なサイズの SRL を検出できない場合、RFS は直接アーカイブ REDO ログ・ファイルを作成し、次のメッセージをアラート・ログに記録します。

No standby redo log files of size <#> blocks available.



FORCE LOGGING モードの有効化モードの有効化モードの有効化モードの有効化本番データベースが FORCE LOGGINGモードの場合は、一時表領域および一時セグメントの変更を除くすべてのデータベース変更が記録されます。FORCE LOGGINGモードに設定すると、スタンバイ・データベースは本番データベースとの一貫性を維持できます。ロード・パフォーマンスを得るために、このモードではなく NOLOGGING操作を指定する場合は、対応するスタンバイ・データファイルを後で同期化する必要があります。NOLOGGING 操作の完了後、変更されたデータファイルの本番バックアップで、対応するスタンバイ・データファイルを置き換える必要があります。ファイル転送の前に、フィジカル・スタンバイ・データベースではリカバリを停止し、ロジカル・スタンバイ・データベースでは影響を受ける表領域を一時的にオフラインにする必要があります。

FORCE LOGGING は、ALTER DATABASE FORCE LOGGING文を発行してすぐに有効にできます。FORCE LOGGINGを指定すると、Oracle は記録されていない実行中の操作がすべて完了するまで待機します。

リアルタイム適用の使用リアルタイム適用の使用リアルタイム適用の使用リアルタイム適用の使用リアルタイム適用を使用すると、ログ適用サービスでは、現行のスタンバイ REDO ログ・ファイルがアーカイブされるのを待たずに、REDO データ（フィジカル・スタンバイ・データベース）または SQL（ロジカル・スタンバイ・データベース）を受信すると同時に適用できます。この結果、スイッチオーバーまたはフェイルオーバーの開始前にスタンバイ REDOログ・ファイルがスタンバイ・データベースに適用されるため、スイッチオーバーおよびフェイルオーバーの時間が短縮されます。

フィジカル・スタンバイ・データベースの場合は、次の SQL 文を使用します。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

ロジカル・スタンバイ・データベースの場合は、次の SQL 文を使用します。

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;







動的サービス登録用のデータベースおよびリスナーの構成動的サービス登録用のデータベースおよびリスナーの構成動的サービス登録用のデータベースおよびリスナーの構成動的サービス登録用のデータベースおよびリスナーの構成LOG_ARCHIVE_DEST_2初期化パラメータの SERVICE属性の設定値および FAL_SERVERとFAL_CLIENT初期化パラメータの設定値は、適切な Oracle Net 構成によって決まります。Oracle Data Guard の転送サービスおよびギャップの解決が機能するには、SPFILE、listener.ora、tnsnames.oraおよび sqlnet.oraファイルに一貫性があることが必要です。

リモート・アーカイブ先の FAL_CLIENTおよび FAL_SERVERパラメータには、Oracle Netサービスが必要です。このサービスは、tnsnames.oraファイルのネット・サービス名エントリとして表されます。FAL_SERVERと FAL_CLIENTは、同じ Oracle ネットワーク・サービス名を参照することに注意してください。これは、FAL_SERVERサービスはスタンバイの tnsnames.oraファイルで定義され、FAL_CLIENTサービスはプライマリのtnsnames.oraファイルで定義されるため可能となります。これが機能するのは、Oracleネットワーク・サービスのローカル・ネーミング・メソッドを使用する場合のみです。ローカル・ネーミング・メソッドを使用しない場合は、別のサービス名を使用する必要があります。したがって、リスナー構成では、静的な SID リストではなく、動的なサービス登録の使用をお薦めします。サービス登録を正しく機能させるには、サーバー・パラメータ・ファイルに次のパラメータが含まれている必要があります。

� データベース・サービス名の SERVICE_NAMES

� インスタンス名の INSTANCE_NAME

� デフォルト以外のリスナー・アドレスを指定するための LOCAL_LISTENER

PMONは、データベース・サービスをリスナーに動的に登録します。PMONは、ネーミング・メソッドを使用して LOCAL_LISTENERを解決しようとします。ここで説明する例では、PMONは対応する名前をローカルの tnsnames.oraファイルで検索します。

次に例を示します。

SALES1.INSTANCE_NAME='SALES1'SALES2.INSTANCE_NAME='SALES2'*.LOG_ARCHIVE_DEST_2='SERVICE=SALES LGWR AFFIRM REOPEN=15 MAX_FAILURE=10'*.LOCAL_LISTENER='SALES_lsnr'*.SERVICE_NAMES='SALES' # required for service registration*.FAL_SERVER='SALES'*.FAL_CLIENT='SALES'


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



各プライマリ・ホストおよびセカンダリ・ホストの listener.oraファイルは、HOST設定を除いて同一であることが必要です。サービス登録を使用するため、静的に構成された情報は必要ありません。

ローカルの tnsnames.oraファイルには、ネット・サービス名およびローカル・リスナー名の変換が含まれる必要があります。また、各ノードで同じサービス名を使用するには、本番データベースおよびスタンバイ・データベースでローカル管理の tnsnames.oraファイルを使用する必要があります。プライマリ・クラスタ上では、tnsnames.oraのエントリである SERVICE_NAMEは、SERVICE_NAMES SPFILEパラメータの設定と同じであることが必要です。インスタンスの後にリスナーを起動すると、サービス登録が即時には発生しません。この場合は、データベースで ALTER SYSTEM REGISTER文を発行して、PMONバックグラウンド・プロセスに対して即時にインスタンスをリスナーに登録するように指示してください。

WAN 環境でのネットワークのチューニング環境でのネットワークのチューニング環境でのネットワークのチューニング環境でのネットワークのチューニングREDO ログ・データのスタンバイ・サイトへの転送を適化するには、ネットワーク間のラウンドトリップ回数を減らすことが不可欠です。Oracle Net Services を使用すると、セッション・データ・ユニット（SDU）のサイズを Oracle Net 設定で調整することによってデータ転送を制御できます。WAN 環境では、SDU を 32KB に設定するとパフォーマンスが向上する場合があります。各バッファを TCP/IP ネットワーク・レイヤーに配信してネットワーク間で転送する前に、SDU パラメータで Oracle Net バッファのサイズを指定します。Oracle Net は、データ送信が要求されたとき、またはバッファがデータで満杯になったときにバッファ内のデータを送信します。WAN 環境での Oracle Data Guard を Oracle 内部でテストした結果、大値を 32KB（32768）に設定すると、WAN 環境でパフォーマンスが大になりました。SDU を設定することで、データをパケット化するためのコール回数が減少すると、パフォーマンスが向上します。

SDUパラメータの設定に加えて、Oracle Net パラメータの SQLNET.SEND_BUF_SIZEとSQLNET.RECV_BUF_SIZEを使用してネットワーク TCP の送受信 I/O バッファのサイズを増やすと、多くの場合、ネットワーク・スループットが大幅に改善されます。

関連項目関連項目関連項目関連項目 : 『Oracle Net Services 管理者ガイド』




データ保護モードの決定データ保護モードの決定データ保護モードの決定データ保護モードの決定ビジネスによっては、どのような状況でもデータの消失は許されない場合があります。また、データの保護よりデータベースの可用性のほうが重要な場合もあります。アプリケーションの中には、データベース・パフォーマンスを大にすることが必要で、障害発生時にデータが消失する可能性を許容できるものがあります。

次のいずれかの保護モードを選択してください。

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

� 大可用性モード大可用性モード大可用性モード大可用性モード : プライマリ・データベースの可用性に影響しない範囲で可能な高レベルのデータ保護を提供します。

� 大パフォーマンス・モード大パフォーマンス・モード大パフォーマンス・モード大パフォーマンス・モード（デフォルト・モード） : プライマリ・データベースのパフォーマンスに影響しない範囲で可能な高レベルのデータ保護を提供します。このモードでは、トランザクションは、そのトランザクションのリカバリに必要な REDOデータがローカル・オンライン REDO ログに書き込まれると同時にコミットされます。プライマリ・データベースの REDO データ・ストリームも少なくとも 1 つのスタンバイ・データベースに書き込まれます。ただし、REDO データ・ストリームは、そのREDO データを作成するトランザクションのコミットメントとは非同期で書き込まれます。十分な帯域幅のネットワーク・リンクを使用する場合、このモードは、プライマリ・データベースのパフォーマンスへの影響が小限で、大可用性モードと同じレベルのデータ保護を提供します。


� 保護モードの決定

� データ保護モードの変更

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



保護モードの決定保護モードの決定保護モードの決定保護モードの決定アプリケーションに対して適切なデータ保護モードは、表 7-4 の質問に従って決定します。

表表表表 7-4 適切な保護モードの決定適切な保護モードの決定適切な保護モードの決定適切な保護モードの決定

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

プライマリ・サイトで障害が発生した場合に、データ消失を許容できますか。

はい : すべての保護モードを使用できます。

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

サイトで障害が発生した場合に、どの程度のデータ消失量を許容できますか。

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

いくらか : ASYNC=blocksを指定して大パフォーマンス・モードを使用します。こ

こで指定するブロック数によって、サイトで障害が発生した場合に消失する可能性がある REDO データの大量が決まります。

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

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

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

障害時リカバリ・サイトとプライマリ・サイトの距離はどの程度ですか。

サイト間の距離およびサイト間のネットワーク・インフラストラクチャによって、ネットワーク待機時間が決まります。通常、待機時間は距離に従って長くなります。停止の際の独立性を確保したりネットワーク待機時間を小限に抑えるために、サイト間の距離は小になるようにしてください。企業にデータ・センターを設けたり、Oracle のアウトソーシング・サービスの利用を検討してください。

サイト間の現行または提案されたネットワーク帯域幅および待機時間はどの位ですか。

帯域幅は、REDO の大生成率より大きい必要があります。双方向通信の場合、帯域

幅の目安は記述されているライン容量の 50 パーセントですが、他のアプリケーション

によるネットワーク使用も考慮する必要があります。

非同期のログ転送またはアーカイバを指定して大パフォーマンス・モードを使用すると、パフォーマンスへの影響を軽減できます。



データ保護モードの変更データ保護モードの変更データ保護モードの変更データ保護モードの変更デフォルトのデータ保護モードは大パフォーマンス・モードです。スタンバイ・データベースへのフェイルオーバーが発生すると、保護モードは自動的に大パフォーマンス・モードに変更されます。スイッチオーバー操作では、保護モードは変更されません。

データ保護モードを大パフォーマンス・モードから大可用性モードまたは大保護モードに変更するには、次の手順を実行します。

1. 適切な初期化パラメータを変更します。大保護モードまたは大可用性モードの場合は、起動時に LGWR SYNCオプションと有効なネット・サービス名を使用する有効なリモートまたはスタンバイ・アーカイブ先が 1 つ必要です。大パフォーマンス・モードの場合は、LGWR ASYNCオプションおよび有効なネット・サービス名を使用します。

2. プライマリ・データベースを停止し、マウント・モードで再起動します。

3. すべてのインスタンスを停止し、排他モードで 1 つのインスタンスを起動します。

SHUTDOWN IMMEDIATE;STARTUP MOUNT EXCLUSIVE;

4. データ保護モードを目的のモードに明示的に変更します。

ALTER DATABASE SET STANDBY TO MAXIMIZE [AVAILABILITY | PROTECTION];

5. すべてのインスタンスを再起動します。

保護モードを大保護モードから大パフォーマンス・モードまたは大可用性モードに変更するには、次に類似した文を使用します。

ALTER DATABASE SET STANDBY TO MAXIMIZE [PERFORMANCE | AVAILABILITY];


� Data Guard 構成のデータ保護モードの設定については、『Oracle Data Guard 概要および管理』を参照してください。

� Data Guard 構成および RAC 構成での保護モードの変更については、『Oracle Data Guard 概要および管理』を参照してください。



ネットワーク構成案によるパフォーマンス評価の実施ネットワーク構成案によるパフォーマンス評価の実施ネットワーク構成案によるパフォーマンス評価の実施ネットワーク構成案によるパフォーマンス評価の実施ネットワーク構成案および現行（または予想される）のピーク時の REDO 率を使用して、パフォーマンス評価の実施をお薦めします。本番データベースとスタンバイ・データベース間のネットワークの影響およびプライマリ・データベースのスループットへの影響を理解する必要があります。本番データベースとスタンバイ・データベース間のネットワークは、2つのデータベースの同期化を維持するために重要であるため、インフラストラクチャには次の特性が必要です。

� 帯域幅は REDO の大生成率より十分に大きいこと

� 本番データベースでのパフォーマンスへの影響を軽減するために、待機時間が小であること

� ネットワークの冗長性を確保するために、複数のネットワーク・パスが存在すること

専用ネットワーク接続に必要な帯域幅は、本番データベースの大 REDO 率によって決定します。また、実際のネットワーク効率も考慮する必要があります。データ保護モードに応じて、追加の推奨プラクティスおよびパフォーマンスに関する考慮事項があります。大保護モードおよび大可用性モードでは、LGWR SYNC転送が必要です。大パフォーマンス保護モードでは、LGWRではなく、ASYNC転送オプションまたはアーカイバ（ARCHn）を使用して、REDO を転送します。これらの推奨事項は、Oracle Data Guard の ARCH、LGWR ASYNCおよび LGWR SYNCの各転送オプションについて、ネットワーク待機時間がプライマリ・データベースのスループットに与える影響を測定した Oracle 内部のパフォーマンス調査に基づいています。

本番データベースの REDO データによってフィジカル・スタンバイ・データベースが更新されるため、プライマリ・サイトとセカンダリ・サイト間のネットワーク・インフラストラクチャでは REDO 通信量を処理できることが必要です。ピーク・ロード時の大 REDO 通信量が毎秒 8MB の場合、ネットワーク・インフラストラクチャにはこのロードを処理できる十分な帯域幅が必要です。さらに、ネットワーク待機時間は、スループット全体およびOLTP 操作とバッチ操作の応答時間に影響を与えます。

LGWR SYNC操作を指定した大保護モードまたは大可用性モードと、LGWR ASYNC操作を指定した大パフォーマンス・モードを比較する場合は、発生する待機時間によってパフォーマンスまたはスループットが低下するかどうかを測定する必要があります。また、モード変更後のスループットおよび応答時間がアプリケーションのパフォーマンス要件を満たしているかどうかもチェックする必要があります。距離およびネットワーク構成は待機時間に直接影響を与えます。また、待機時間が長くなると、トランザクションのスループットが低下し、応答時間が長くなる場合があります。ネットワーク構成、リピータの数、プロトコル変換のオーバーヘッドおよびルーターの数も、全体のネットワーク待機時間やトランザクションの応答時間に影響を与えます。

関連項目関連項目関連項目関連項目 : この調査の詳細は、http://otn.oracle.co.jp/document/index.htmlを参照してください。



大可用性モードまたは大保護モードでの大可用性モードまたは大保護モードでの大可用性モードまたは大保護モードでの大可用性モードまたは大保護モードでの LAN またはまたはまたはまたは MAN の使用の使用の使用の使用大可用性モードまたは大保護モードの場合は、Oracle Data Guard の転送サービスで

LGWR SYNC転送オプションを使用する必要があります。ネットワーク待機時間は、LGWR SYNC I/O 操作ごとに追加のオーバーヘッドになります。図 7-1 は、LGWR SYNC操作によって、ローカルにオンライン REDO ログに書き込むとともに、RFSプロセスへのネットワークを介してリモートにスタンバイ REDO ログに書き込む様子を示しています。

図図図図 7-1 LGWR SYNC 操作操作操作操作

次の式から、リモート書込みはローカル書込みより常に速度が遅く、LGWR同期書込みが発生したときの制限要因になることがわかります。

Local write = local write I/O timeRemote write = network round trip time (RTT) + local write I/O time (on standby machine)

たとえば、ネットワークのラウンドトリップ時間（RTT）が 20 ミリ秒で、LGWR同期書込みが構成されている場合、すべてのトランザクションのコミット時間は 20 ミリ秒ずつ増加します。このオーバーヘッドは応答時間に影響を与え、プライマリ・データベースのスループットにも影響する場合があります。RTT によって追加のオーバーヘッドが発生するため、パフォーマンスや応答時間の変化を許容できないアプリケーションの場合は、RTT が 10 ミリ秒以下の Local Area Network（LAN）または Metropolitan Area Network（MAN）を使用する必要があります。LAN または MAN のどちらを使用するかは、パフォーマンス評価の結果によって決定します。



大のパフォーマンス・スループットを得るための大のパフォーマンス・スループットを得るための大のパフォーマンス・スループットを得るための大のパフォーマンス・スループットを得るための ARCH の使用の使用の使用の使用LOG_ARCHIVE_DEST_n初期化パラメータの ARCH属性を使用すると、パフォーマンスのスループットは大になりますが、データ消失のリスクも大になります。 REDO ログが 7-3ページの「REDO ログ・ファイルのサイズおよびグループの適切な構成」で説明されているように正しく構成されているかぎり、待機時間が長くなっても ARCH属性はプライマリのパフォーマンスに影響を与えません。データ保護モードが大パフォーマンス・モードの場合は、この属性（デフォルト）の使用をお薦めします。

プライマリのスループットへの待機時間の影響については、次のホワイト・ペーパーを参照してください。

データ消失を制御するためのデータ消失を制御するためのデータ消失を制御するためのデータ消失を制御するための ASYNC 属性の使用属性の使用属性の使用属性の使用大パフォーマンス・モードでアーカイバのかわりに LGWR ASYNCを使用すると、データ

消失量が減ります。ただし、ASYNCネットワーク・バッファが適宜空にならないと、ARCHが LGWR ASYNCに優先します。結果を善にするには、ASYNCバッファの小サイズを少なくとも 10MB にします。

より大きいサイズのバッファを使用すると、WAN でバッファが満杯になったことを示すORA-16198タイムアウト・メッセージの発生を低減できます。ただし、LGWR wait on full LNS bufferデータベース待機イベントがデータベース待機イベントの上位 3 つに入っている場合は、ARCHを使用します。

ネットワーク・バッファが満杯になり、その状態が 1 秒間続くと、転送がタイムアウトになり、ARCH転送に変更されます。この状態は、スタンバイ・アーカイブ先へのネットワークが、プライマリ・データベースでの REDO 生成率より遅れていることを示します。これは、アラート・ログに次のメッセージで示されます。

ORA-16198: リモート・アーカイブ中に、内部チャネルでタイムアウトが発生しました

このメッセージは、LGWR ASYNC属性を使用して構成したスタンバイ・アーカイブ先で、非同期バッファが満杯の状態になったことを示します。この状態が発生すると、ログ転送サービスは、ネットワーク・サーバー・プロセス LNSn を使用した REDO データの転送を停止し、ログ・スイッチが発生するまでアーカイバ・プロセス（ARCn）を使用するように変更します。次回のログ・スイッチで、REDO 転送は LGWR ASYNC転送に戻ります。この変更は自動的に行われます。大サイズ（50MB）の非同期ネットワーク・バッファを使用すると、転送が ARCHに変更される可能性が低くなります。すべてのログまたはほとんどのログでこのエラーが発生する場合は、永続的にアーカイバ・プロセスを使用するように転送を変更する必要があります。

図 7-2 は、LGWR ASYNC構成でスタンバイ保護モードを大パフォーマンス・モードに設定した場合のアーキテクチャを示しています。

関連項目関連項目関連項目関連項目 : ARCHによるパフォーマンスと待機時間の詳細は、Oracle Technology Network Japan の『Oracle Data Guard: プライマリ・サイトおよびネットワーク構成 Best Practices』を参照してください。



図図図図 7-2 LGWR ASYNC 転送サービス転送サービス転送サービス転送サービス



圧縮を使用した圧縮を使用した圧縮を使用した圧縮を使用した SSH ポート転送の評価ポート転送の評価ポート転送の評価ポート転送の評価待機時間が長い WAN（RTT が 100 ミリ秒以上）で、大パフォーマンス・モードで圧縮を使用した SSH ポート転送を評価します。LGWR ASYNCを使用してバッファ・サイズを大にすると、圧縮を使用した SSH では、非同期バッファが満杯になったためにタイムアウトになる可能性が低くなります。また、ネットワーク通信量も削減されます。

LOG_ARCHIVE_LOCAL_FIRST をををを TRUE に設定に設定に設定に設定LOG_ARCHIVE_LOCAL_FIRSTを TRUEに設定すると、REDO ログをリモート・スタンバイ・アーカイブ先に転送する前に、アーカイバ・プロセスでプライマリ・データベースのローカルのオンライン REDO ログ・ファイルをアーカイブできます。この設定は、スタンバイ・データベースへのネットワーク速度が遅い場合に特に役立ちます。

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

REDO データの安全な転送データの安全な転送データの安全な転送データの安全な転送セキュリティが不十分な場合は可用性に直接影響を与えるため、Data Guard は、REDOデータをスタンバイ・データベースに転送する際の安全な環境を提供し、REDO データの改ざんを防ぎます。REDO データを安全に転送するには、Data Guard 構成内のすべてのデータベースでパスワード・ファイルを使用するように設定し、SYSユーザーのパスワードをすべてのシステムで同一に設定します。Data Guard 構成内の各データベースで必要な手順は、次のとおりです。

1. Data Guard 構成内の各データベースで、パスワード・ファイルを作成します。

2. 各インスタンスで REMOTE_LOGIN_PASSWORDFILE=[EXCLUSIVE | SHARED]初期化パラメータを設定します。

Data Guard 構成内のすべてのデータベースでこれらの手順を実行してセキュリティを設定すると、Data Guard は、SYS資格証明を使用した適切な認証チェックが正常に終了した後、REDO データを転送します。この認証は Oracle Advanced Security をインストールしていない場合でも実行でき、REDO データの転送時にある程度のレベルのセキュリティが提供されます。さらに REDO データを保護するには（たとえば、REDO データを暗号化したり、整合性のチェックサム値を計算して、ネットワーク上の REDO 通信で REDO が改ざんされるのを防止します）、Oracle Advanced Security をインストールして使用することをお薦めします。


� Oracle Technology Network Japan の『Oracle Data Guard: プライマリ・サイトおよびネットワーク構成 Best Practices』を参照してください。



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

LOG_ARCHIVE_CONFIG の適切な設定の適切な設定の適切な設定の適切な設定Data Guard 構成内のプライマリ・データベースおよび各スタンバイ・データベースのDB_UNIQUE_NAMEをリスト表示するには、LOG_ARCHIVE_CONFIG初期化パラメータのDG_CONFIG属性を指定します。デフォルトでは、このパラメータによって、プライマリ・データベースは REDO データをリモート・アーカイブ先に送信でき、スタンバイ・データベースは REDO データを受信できるようになります。大保護モードまたは大可用性モードのいずれかで稼働している RAC プライマリ・データベースがある Data Guard 構成にスタンバイ・データベースを動的に追加できるようにするには、DG_CONFIG属性を設定する必要があります。

フィジカル・スタンバイ・データベースのみに関する推奨事項フィジカル・スタンバイ・データベースのみに関する推奨事項フィジカル・スタンバイ・データベースのみに関する推奨事項フィジカル・スタンバイ・データベースのみに関する推奨事項次の推奨事項は、フィジカル・スタンバイ・データベースのみに適用されます。

� メディア・リカバリのパフォーマンスのチューニング

メディア・リカバリのパフォーマンスのチューニングメディア・リカバリのパフォーマンスのチューニングメディア・リカバリのパフォーマンスのチューニングメディア・リカバリのパフォーマンスのチューニングOracle Data Guard をフィジカル・スタンバイ・データベースとともに使用したり、メディア・リカバリ操作を効率的に使用するには、データベース・リカバリをチューニングする必要があります。


� REDO データの安全な転送を実現するための詳細な手順は、『Oracle Data Guard 概要および管理』を参照してください。

� 『Oracle Advanced Security 管理者ガイド』



関連項目関連項目関連項目関連項目 : Oracle Technology Network Japan の『Oracle Database メディア・リカバリ Best Practices』を参照してください。



ロジカル・スタンバイ・データベースのみに関する推奨事項ロジカル・スタンバイ・データベースのみに関する推奨事項ロジカル・スタンバイ・データベースのみに関する推奨事項ロジカル・スタンバイ・データベースのみに関する推奨事項次の推奨事項は、ロジカル・スタンバイ・データベースのみに適用されます。

� 補助ロギングおよび主キー制約の使用

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

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

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

� 不要なオブジェクトに対する SQL Apply のスキップ

補助ロギングおよび主キー制約の使用補助ロギングおよび主キー制約の使用補助ロギングおよび主キー制約の使用補助ロギングおよび主キー制約の使用本番で使用されるすべての表で、補助ロギングおよび主キー制約を使用します。

アプリケーションで表内の行が一意であることが確実な場合は、無効な主キーの RELY制約を表に作成できます。これによって、プライマリ・データベースで主キーをメンテナンスするオーバーヘッドを回避できます。プライマリ・データベース表に無効な主キーの RELY制約を作成するには、RELY DISABLE句を指定した ALTER TABLE文を使用します。

SQL Apply のパフォーマンスを改善するには、ロジカル・スタンバイ・データベースの行を一意に識別する索引を列に追加します。索引を追加しない場合は、全表スキャンが発生します。

MAX_SERVERS 初期化パラメータの設定初期化パラメータの設定初期化パラメータの設定初期化パラメータの設定プライマリ・データベースでのレポート作成操作や意思決定支援操作を回避するためにロジカル・スタンバイ・データベースを使用する場合は、このような操作用のパラレル問合せスレーブをいくつか確保する必要があります。SQL Apply プロセスではデフォルトですべてのパラレル問合せスレーブを使用するため、MAX_SERVERS初期化パラメータを設定すると、指定した数のパラレル問合せスレーブが確保されます。

表 7-5 に、MAX_SERVERSの値の例を示します。

MAX_SERVERSは初に、9 または 3 ＋（3 × CPU）より大きい値に設定することをお薦めします。

表表表表 7-5 MAX_SERVERS の値の例の値の例の値の例の値の例

PARALLEL_MAX_SERVERS初期化パラメータ初期化パラメータ初期化パラメータ初期化パラメータ

MAX_SERVERS初期化パラメータ初期化パラメータ初期化パラメータ初期化パラメータ

パラレル問合せ操作用にパラレル問合せ操作用にパラレル問合せ操作用にパラレル問合せ操作用に確保されたサーバー数確保されたサーバー数確保されたサーバー数確保されたサーバー数

SQL Apply 操作用に操作用に操作用に操作用に確保されたサーバー数確保されたサーバー数確保されたサーバー数確保されたサーバー数

24 未設定 0 24

24 24 0 24

48 24 24 24



PARALLEL_MAX_SERVERS 初期化パラメータ値の増加初期化パラメータ値の増加初期化パラメータ値の増加初期化パラメータ値の増加プライマリ・インスタンスおよびスタンバイ・インスタンスの両方で、PARALLEL_MAX_SERVERS初期化パラメータを 9 または 3 × CPU より大きい値に設定します。

PARALLEL_MAX_SERVERS=current value + max(9, 3 +(3 x CPU))

PARALLEL_MAX_SERVERS初期化パラメータには、データベース・インスタンスで作成できるパラレル問合せプロセスの大数を指定します。コーディネータ・プロセスを除き、SQL Apply エンジンを構成するすべてのプロセスはパラレル問合せプロセスのプールから作成されます。SQL Apply エンジンは、デフォルトで、データベース・インスタンスで使用可能なすべてのパラレル問合せプロセスを使用します。この動作は、ロジカル・スタンバイ・パラメータを使用して変更できます。

PARALLEL_MAX_SERVERSを MAX_SERVERSの値のみ増やすことをお薦めします。

TRANSACTION_CONSISTENCY 初期化パラメータの設定初期化パラメータの設定初期化パラメータの設定初期化パラメータの設定ロジカル・スタンバイ・データベースでは、次のデータ適用方法をサポートします。

� レポート作成システムまたは意思決定支援システムの場合は、FULLまたは READ_ONLYのトランザクション一貫性を使用します。

� 障害時リカバリ・ソリューションの場合、または SQL Apply エンジンが遅れないようにする必要がある場合は、TRANSACTION_CONSISTENCYを NONEに設定します。

レポート作成操作または意思決定支援操作でロジカル・スタンバイ・データベースを使用する場合は、次のように設定します。

� スタンバイ・データベースに複数のインスタンス（RAC）が存在する場合は、FULLを選択します。

� スタンバイ・データベースに 1 つのインスタンスのみ（RAC なし）が存在する場合は、READ_ONLYを選択します。

不要なオブジェクトに対する不要なオブジェクトに対する不要なオブジェクトに対する不要なオブジェクトに対する SQL Apply のスキップのスキップのスキップのスキップスタンバイ・データベースにレプリケートする必要がないデータベース・オブジェクトは、DBMS_LOGSTDBY.SKIPプロシージャを使用してスキップする必要があります。このようなオブジェクトをスキップすると、SQL Apply エンジンの処理が軽減されます。この推奨事項は、意思決定支援環境の場合に考慮してください。


MAA に関する構成上のベスト・プラクティス

MAA に関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスに関する構成上のベスト・プラクティスこの項では、シングル・インスタンス・データベース、RAC および Data Guard について説明したプラクティス以外の構成に関する推奨プラクティスについて説明します。ここでは、MAA を使用する（RAC と Data Guard を両方のサイトで使用する）場合の推奨プラクティスについて説明します。


� 複数のスタンバイ・インスタンスの構成

� ネットワーク・サービスの記述子に対する接続時フェイルオーバーの構成

複数のスタンバイ・インスタンスの構成複数のスタンバイ・インスタンスの構成複数のスタンバイ・インスタンスの構成複数のスタンバイ・インスタンスの構成MAA 環境では、スタンバイ・データベースは RAC を使用し、複数のスタンバイ・インスタンスが同じスタンバイ・データベースに関連付けられています。複数のスタンバイ・インスタンスが存在することは、複数のスタンバイ・データベースが存在することと同じではありません。1 つのインスタンスのみが管理リカバリ・プロセス（MRP）またはロジカル・スタンバイ適用プロセス（LSP）を指定できます。MRP または LSP を実行するスタンバイ・インスタンスは、プライマリ・スタンバイ・インスタンスと呼ばれます。これ以外のすべてのスタンバイ・インスタンスは、セカンダリ・スタンバイ・インスタンスと呼ばれます。

クラスタ上に同一データベースのスタンバイ・インスタンスが複数存在すると、次の利点があります。

� プライマリ・スタンバイ・インスタンスとの接続が失敗した場合、セカンダリ・スタンバイ・インスタンスへの透過的な接続フェイルオーバーが可能です。この場合、MRPまたは LSP セッションは、Data Guard Broker によって自動的に再起動します。Brokerを使用していない場合、これらのプロセスは、新しいプライマリ・スタンバイ・インスタンスで手動で再起動する必要があります。

� メンテナンスのためにプライマリ・スタンバイ・インスタンスおよびホストを停止する必要がある場合は、スケジュールされたメンテナンス・ソリューションを提供します。接続時フェイルオーバーが発生すると、セカンダリ・スタンバイ・インスタンスはプライマリ・スタンバイ・インスタンスを引き継ぎ、Oracle Net のサービスを介してログを受信します。


MAA に関する構成上のベスト・プラクティス

ネットワーク・サービスの記述子に対する接続時フェイルオーバーの構成ネットワーク・サービスの記述子に対する接続時フェイルオーバーの構成ネットワーク・サービスの記述子に対する接続時フェイルオーバーの構成ネットワーク・サービスの記述子に対する接続時フェイルオーバーの構成接続が失敗して接続要求が別のリスナーに転送されると、Data Guard の接続時フェイルオーバーが発生します。リスナーは要求されたサービスを提供する有効な Oracle インスタンスを識別するため、接続時フェイルオーバーはサービス登録によって有効になります。

次に、tnsnames.oraファイル内の Oracle Net 接続記述子を示します。

sales.us.acme.com= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521))) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)))

ネット・サービス名 SALESには、本番クラスタとスタンバイ・クラスタ用にアドレス・リストが 2 つ（2 ノード・クラスタであるため）含まれています。1 番目の接続が失敗すると、2 番目のアドレス・リストによって接続時フェイルオーバーが有効になります。すべての保護モードでこのように動作します。

ネットワーク・プロトコル・アドレスを既存のネット・サービス名またはデータベース・サービスに追加するには、Oracle Enterprise Manager または Oracle Net Manager のいずれかを使用します。



バックアップおよびリカバリに関する推奨事項

バックアップおよびリカバリに関する推奨事項バックアップおよびリカバリに関する推奨事項バックアップおよびリカバリに関する推奨事項バックアップおよびリカバリに関する推奨事項すべてのデータベースで適切なバックアップを作成することも賢明な方法ですが、バックアップを使用したリカバリは必ずしも速のソリューションではありません。多くの場合、バックアップからリストアするよりも、RAC、Data Guard、フラッシュバック・テクノロジなどの Oracle テクノロジを使用したほうが迅速に停止からリカバリできます。

ただし、適切なバックアップ計画およびリカバリ計画は、全体的な高可用性を維持するために重要で、特定の停止は許容可能な時間内で確実にリカバリされます。この項の内容は次のとおりです。

Recovery Manager を使用したデータベース・ファイルのバックアップバックアップの使用時期の識別RMAN Recovery Catalog の使用制御ファイルおよび SPFILE の自動バックアップ機能の使用段階的に更新されたバックアップの使用によるリストア時間の短縮変更トラッキングの有効化によるバックアップ時間の短縮フラッシュ・リカバリ領域にディスク上のデータベース・バックアップを作成フラッシュ・リカバリ領域からテープ・バックアップを作成保存方針およびバックアップ頻度の決定フラッシュ・リカバリ領域の適切なサイズの構成Data Guard 環境における全サイトでのフラッシュ・リカバリ領域へのバックアップバックアップ時にターゲット・データベースの制御ファイルを Recovery Manager リポジトリとして使用ブロック破損検出のためのデータベース・ファイルの定期チェックリカバリ手順の定期的なテストテープまたはオフサイトへの OCR のバックアップ


� 『Oracle Database バックアップおよびリカバリ基礎』

� Recovery Manager も含めたバックアップおよびリカバリの詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。



Recovery Manager を使用したデータベース・ファイルのバックアップを使用したデータベース・ファイルのバックアップを使用したデータベース・ファイルのバックアップを使用したデータベース・ファイルのバックアップRecovery Manager（RMAN）は、サーバー・セッションを使用してバックアップおよびリカバリ操作を実行し、バックアップに関するメタデータをリポジトリに格納します。Recovery Manager は、表領域をバックアップ・モードに設定せずにオンラインでデータベースをバックアップする機能、増分バックアップのサポート、バックアップおよびリストア操作中のデータ・ブロックの整合性チェック、実際にバックアップおよびリストア操作を実行せずにこれらの操作をテストする機能など、典型的なユーザー管理バックアップ方法より多くの利点があります。Recovery Manager を使用するとバックアップおよびリカバリは自動化されますが、ユーザー管理の方法ではすべてのデータベース・ファイルとバックアップを追跡管理する必要があります。たとえば、ユーザー管理の方法では、各データファイルのバックアップの位置を特定し、オペレーティング・システム・コマンドを使用してバックアップを正しい位置にコピーして、適用するログを選択する必要があります。これに対して、Recovery Manager では、これらのタスクを自動的に管理します。また、ブロック・メディア・リカバリなど、Recovery Manager を使用する場合のみ利用できる Oracle のリカバリ機能もいくつかあります。

バックアップの使用時期の識別バックアップの使用時期の識別バックアップの使用時期の識別バックアップの使用時期の識別本番データベースで発生する計画外停止は、多くの場合、様々なデータベース・コンポーネントによって自動的に処理されるか、またはバックアップをリストアする別のテクノロジを使用して解決されます。たとえば、停止が発生したとき、フラッシュバック・データベースまたはスタンバイ・データベースを使用して処理するのが善である場合があります。ただし、次の場合は、データベース・バックアップを使用する必要があります。

� 定期的なバックアップの実行

� Data Guard 環境の初期設定

� ファイルまたはブロック・メディア・リカバリを使用したデータ障害からのリカバリ

� 二重障害の解決

� 長期バックアップ

定期的なバックアップの実行定期的なバックアップの実行定期的なバックアップの実行定期的なバックアップの実行定期的にバックアップを実行する際に、データベース・バックアップが必要です。

Data Guard 環境の初期設定環境の初期設定環境の初期設定環境の初期設定スタンバイ・データベースを初期設定するとき、初のスタンバイ・データベースを作成するために、セカンダリ・サイトで本番データベースのバックアップが必要です。

関連項目関連項目関連項目関連項目 : 7-40 ページ「保存方針およびバックアップ頻度の決定」




ファイルまたはブロック・メディア・リカバリを使用したデータ障害ファイルまたはブロック・メディア・リカバリを使用したデータ障害ファイルまたはブロック・メディア・リカバリを使用したデータ障害ファイルまたはブロック・メディア・リカバリを使用したデータ障害からのリカバリからのリカバリからのリカバリからのリカバリData Guard が含まれない環境でブロック破損やメディア障害を含むデータ障害が発生した場合、唯一のリカバリ方法は既存のバックアップを使用することです。Data Guard を使用する場合でも、既存のバックアップを使用して影響を受けたオブジェクトをリストアしてリカバリする方法が、データ障害からリカバリするも効率的な方法である場合があります。

二重障害の解決二重障害の解決二重障害の解決二重障害の解決二重障害が発生すると、本番データベースおよびスタンバイ・データベースの両方の可用性に影響が及びます。このような状況の唯一の解決方法は、使用可能なバックアップから本番データベースを再作成し、次にスタンバイ・データベースを再作成することです。二重障害の例として、セカンダリ・サイトでサイトの停止が発生してフォルト・トレランスが失われ、次に本番データベースでメディア障害が発生する場合があります。複数の障害（正確には、プライマリ・サイトの停止に続いてセカンダリ・サイトが停止するような大規模な障害）が発生した場合は、オフサイトに存在するバックアップを使用する必要があります。したがって、悪の状況でサービスをリストアできるように、バックアップ・テープを配布してオフサイトでメンテナンスするプロセスを開発して実行することが必要です。

長期バックアップ長期バックアップ長期バックアップ長期バックアップビジネスによっては、数年にわたる長期バックアップをメンテナンスする機能が必要です。Recovery Manager で KEEPオプションを指定すると、保存方針から除外され期限切れのないバックアップを保持できるため、データベースを任意の時点にリストアしてリカバリできます。領域不足によってバックアップ・メタデータが消失しないように、Recovery Managerリポジトリでリカバリ・カタログを使用することが重要です。領域不足は、Recovery Manager リポジトリでターゲット・データベースの制御ファイルを使用するときに発生する可能性があります。

RMAN Recovery Catalog の使用の使用の使用の使用Recovery Manager は、バックアップするデータベースの制御ファイル内にあるバックアップ・メタデータを自動的に管理します。また、バックアップ・メタデータを長期間保護して格納するために、Recovery Manager リポジトリ（通常はリカバリ・カタログと呼ばれます）が別のデータベースに作成されます。リカバリ・カタログを使用すると、バックアップ情報を長期間格納する機能、複数のデータベースのメタデータを格納する機能、別のシステム上にある使用可能なバックアップをリストアする機能など、多くの利点があります。さらに、ターゲット・データベースの制御ファイルのみを使用してリポジトリを格納している場合、大サイズが制限される制御ファイルでは、必要なバックアップ・メタデータをすべて保持

するだけの十分な領域を確保できない場合があります。制御ファイルが小さすぎて追加のバックアップ・メタデータを保持できない場合は既存のバックアップ情報が上書きされるため、このバックアップを使用したリストアおよびリカバリが困難になります。

関連項目関連項目関連項目関連項目 : 10-34 ページ「データ障害に対するリカバリ方法」



制御ファイルおよび制御ファイルおよび制御ファイルおよび制御ファイルおよび SPFILE の自動バックアップ機能の使用の自動バックアップ機能の使用の自動バックアップ機能の使用の自動バックアップ機能の使用Recovery Manager は、制御ファイル内のデータベース構造メタデータが変更されたり、バックアップ・レコードが追加されるたびに、自動的に制御ファイルとサーバー・パラメータ・ファイル（SPFILE）をバックアップするように構成できます。自動バックアップ機能によって、現行の制御ファイル、カタログおよび SPFILEが失われた場合でも、Recovery Manager はデータベースをリカバリできます。Recovery Manager の自動バックアップ機能を有効にするには、CONFIGURE CONTROLFILE AUTOBACKUP ON文を使用します。

段階的に更新されたバックアップの使用によるリストア時間の短縮段階的に更新されたバックアップの使用によるリストア時間の短縮段階的に更新されたバックアップの使用によるリストア時間の短縮段階的に更新されたバックアップの使用によるリストア時間の短縮Oracle の段階的にバックアップを更新する機能を使用すると、データファイルのイメージ・コピーを作成し、データベースの増分バックアップを定期的に作成してイメージ・コピーに適用できます。イメージ・コピーは、増分バックアップが作成された時点の SCN を使用してすべての変更に対して更新されます。Recovery Manager は、その SCN で作成された全体イメージ・コピーを使用するのと同様に、更新されたデータファイルをメディア・リカバリで使用できるため、毎日、データベースの全体イメージ・コピーを実行する際のオーバーヘッドが発生しません。段階的に更新されたバックアップに基づくバックアップ計画は、メディア・リカバリの MTTR を小限に抑えるために役立ちます。

変更トラッキングの有効化によるバックアップ時間の短縮変更トラッキングの有効化によるバックアップ時間の短縮変更トラッキングの有効化によるバックアップ時間の短縮変更トラッキングの有効化によるバックアップ時間の短縮増分バックアップに対する Oracle の変更トラッキング機能によって、各データファイル内の変更されたブロックが変更トラッキング・ファイルに記録されるため、増分バックアップのパフォーマンスが向上します。変更トラッキングが有効な場合、Recovery Manager は変更トラッキング・ファイルを使用して、増分バックアップ内の変更されたブロックを識別するため、データファイル内のすべてのブロックをスキャンする必要がありません。

フラッシュ・リカバリ領域にディスク上のデータベース・バックアップをフラッシュ・リカバリ領域にディスク上のデータベース・バックアップをフラッシュ・リカバリ領域にディスク上のデータベース・バックアップをフラッシュ・リカバリ領域にディスク上のデータベース・バックアップを作成作成作成作成

ディスク・ベースの自動バックアップと自動リカバリを使用してフラッシュ・リカバリ領域を作成すると、バックアップ関連のファイルを自動的に管理できます。ディスク上の位置および記憶域の上限を選択し、バックアップ・ファイルがリカバリのために必要となる期間を管理する保存方針を設定します。この領域内で、データベースのバックアップ、アーカイブREDO ログなどのリカバリ関連のファイルで使用する記憶域が管理されます。Recovery Manager で新しいファイル用に領域を再生する必要がある場合は、不要になったファイルが削除対象になります。






フラッシュ・リカバリ領域からテープ・バックアップを作成フラッシュ・リカバリ領域からテープ・バックアップを作成フラッシュ・リカバリ領域からテープ・バックアップを作成フラッシュ・リカバリ領域からテープ・バックアップを作成Recovery Manager コマンドの BACKUP RECOVERY FILE DESTINATIONを使用して、フラッシュ・リカバリ領域で作成されたディスク・バックアップをテープに移動します。テープ・バックアップはオフサイトおよび長期保存のために使用し、特定の停止が発生した場合に使用します。

保存方針およびバックアップ頻度の決定保存方針およびバックアップ頻度の決定保存方針およびバックアップ頻度の決定保存方針およびバックアップ頻度の決定バックアップ保存方針は、リカバリなどの要件に応じて（ディスク上または他のバックアップ・メディア上に）保存する必要があるバックアップに関するルール・セットです。バックアップが古すぎるために新しいバックアップで上書きできる場合、またはテープにバックアップが格納されている場合、そのバックアップは削除しても安全です。また、アーカイブ要件などの理由で、ディスク上にバックアップを保持する必要が生じる場合もあります。バックアップ保存方針を満たして不要になったバックアップは、不要不要不要不要なバックアップと呼ばれます。

バックアップ保存方針は、冗長性冗長性冗長性冗長性またはリカバリ期間リカバリ期間リカバリ期間リカバリ期間に基づいて決定できます。冗長性に基づく保存方針では、バックアップの数 n を指定します。これによって、データベース内の各ファイルについて少なくとも n 個のバックアップが常に保持されます。リカバリ期間に基づく保存方針では、過去の時間間隔（1 週間、1 か月など）を指定します。これによって、その期間内の任意の時点に Point-in-Time リカバリを実行するために必要なすべてのバックアップが保持されます。

バックアップは、リカバリ計画用に頻繁に作成することが不可欠です。バックアップの頻度は、次のようなデータベース変更の率または頻度によって決定します。

� 表の追加および削除

� 既存の表への行の挿入および削除

� 表内のデータの更新

データベースが更新される頻度が高いほど、データベースのバックアップを頻繁に実行する必要があります。データベースの更新が比較的少ない場合、データベース全体のバックアップを頻繁に実行する必要はありませんが、これを補完するために、変更されるブロック数が少なく比較的小規模な増分バックアップを実行できます。





フラッシュ・リカバリ領域の適切なサイズの構成フラッシュ・リカバリ領域の適切なサイズの構成フラッシュ・リカバリ領域の適切なサイズの構成フラッシュ・リカバリ領域の適切なサイズの構成フラッシュ・リカバリ領域のサイズを適切に構成すると、ユーザー・エラーの場合はフラッシュバック・データベースを使用して高速にリカバリでき、データ障害の場合はディスクからのファイルまたはブロック・メディア・リカバリを使用して高速にリカバリできます。フラッシュ・リカバリ領域の適切なサイズは、保存方針、バックアップ頻度、データベースのサイズ、データベースに対する変更の率および数に応じて決定します。『Oracle Database バックアップおよびリカバリ基礎』に、様々なバックアップ使用例について、フラッシュ・リカバリ領域の適切なサイズを決定するための式が記載されています。

Data Guard 環境における全サイトでのフラッシュ・リカバリ領域への環境における全サイトでのフラッシュ・リカバリ領域への環境における全サイトでのフラッシュ・リカバリ領域への環境における全サイトでのフラッシュ・リカバリ領域へのバックアップバックアップバックアップバックアップ

バックアップは、プライマリ・サイトおよびセカンダリ・サイトで作成します。このプラクティスの利点は次のとおりです。

� 二重に停止が発生した場合の MTTR が大幅に削減されます。

� スイッチオーバーまたはフェイルオーバー時に、他のバックアップ手順の実行を防ぎます。

� Recovery Manager のファイルおよびブロック・メディア・リカバリは、プライマリ・サイトとセカンダリ・サイトの両方でデータ障害による停止が発生した場合のリカバリ・オプションです。

セカンダリ・サイトのみでバックアップが実行された場合を考えてみます。セカンダリ・サイトでサイトの停止が発生し、リカバリ期間の見積りは 3 日間とします。プライマリ・サイトは、一般的にフェイルオーバーによって解決される停止、またはローカル・バックアップを使用して解決できる停止（ブロック・メディア・リカバリによって解決されるデータ障害による停止など）に対して、完全に無防備です。この場合、本番データベースの停止は、スタンバイ・サイトで作成されたオフサイトのテープ・バックアップの物理的な移送によってのみ解決できます。プライマリ・サイトのバックアップが使用可能な場合は、実行不可能なフェイルオーバーのかわりに、ローカルにリストアすることが可能です。プライマリ・サイトのバックアップを使用すると、データが消失する場合がありますが、MTTR は大幅に短縮されます。

セカンダリ・サイトで停止が発生したときに、プライマリ・サイトでバックアップの作成を開始する方法はお薦めできません。環境が異常な状態にあるときに他のプロセスや手順が実行され、スタッフの操作ミスによる影響も拡大されるため、この方法は実行しないでください。また、プライマリ・サイトでバックアップを作成できないことを確認しないでください。

さらに、Recovery Manager のファイルおよびブロック・メディア・リカバリが妥当なMTTR で実行されるために、プライマリ・サイトでのディスク・バックアップが必要です。ローカルなディスク上バックアップがない場合は、スタンバイ・サイトで作成したバックアップをプライマリ・サイトにリストアする必要があるため、このような停止での MTTRはかなり長くかかります。



バックアップ時にターゲット・データベースの制御ファイルをバックアップ時にターゲット・データベースの制御ファイルをバックアップ時にターゲット・データベースの制御ファイルをバックアップ時にターゲット・データベースの制御ファイルを Recovery Manager リポジトリとして使用リポジトリとして使用リポジトリとして使用リポジトリとして使用

バックアップ時に、ターゲット・データベースの制御ファイルを Recovery Manager リポジトリとして使用し、後で Recovery Manager の RESYNC CATALOGコマンドを使用して再同期化します。

バックアップをディスクまたはテープに作成するとき、ターゲット・データベースの制御ファイルを Recovery Manager リポジトリとして使用してください。これによって、バックアップが可能かどうか、またはバックアップの成否は、管理データベースでの Recovery Manager カタログの可用性に影響されません。これを実現するには、NOCATALOGオプションを指定して Recovery Manager を実行してください。バックアップの完了後、ターゲット・データベースの制御ファイルに格納された新しいバックアップ情報は、RESYNC CATALOGコマンドを使用してリカバリ・カタログと再同期化できます。

ブロック破損検出のためのデータベース・ファイルの定期チェックブロック破損検出のためのデータベース・ファイルの定期チェックブロック破損検出のためのデータベース・ファイルの定期チェックブロック破損検出のためのデータベース・ファイルの定期チェックユーザー・セッションまたは通常のバックアップ操作でレポートされていないブロック破損を検出するために、Recovery Manager コマンドの BACKUP VALIDATEを使用して、データベース・ファイルを定期的にチェックする必要があります。Recovery Manager は、指定されたファイルをスキャンし、内容を検証して物理的および論理的なエラーが発生していないかをチェックします。ただし、バックアップ操作やリカバリ操作は実行しません。Oracleは、破損ブロックのアドレスと破損のタイプを制御ファイルに記録します。記録されたレコードには V$DATABASE_BLOCK_CORRUPTIONビューからアクセスします。このレコードは Recovery Manager のブロック・メディア・リカバリで使用できます。

BLOCK CHANGE TRACKINGが有効な場合は、すべてのデータ・ブロックが読み込まれて検証されるように、BACKUP VALIDATEで INCREMENTAL LEVELオプションを使用しないでください。

検出可能な破損をすべて検出するには、次の点に注意してください。

� MAXCORRUPTオプションを指定しないこと

� NOCHECKSUMオプションを指定しないこと

� CHECK LOGICALオプションを指定しないこと



リカバリ手順の定期的なテストリカバリ手順の定期的なテストリカバリ手順の定期的なテストリカバリ手順の定期的なテスト完全で正常なテスト済のバックアップは、リカバリを成功させるための基本です。様々なタイプの停止について、テスト計画を作成します。もよく発生する停止のタイプから開始し、あまり発生しない停止へと進みます。バックアップを成功させるには、バックアップ手順を発行するのみでなく、テストを繰り返すことが必要です。リカバリ手順を定期的にテストして、バックアップ手順に誤りがないかを調べ、バックアップを検証します。また、Recovery Manager コマンドの BACKUP VALIDATEおよび RESTORE... VALIDATEコマンドを使用してバックアップおよびリストアが実行できることも検証してください。

テープまたはオフサイトへのテープまたはオフサイトへのテープまたはオフサイトへのテープまたはオフサイトへの OCR のバックアップのバックアップのバックアップのバックアップOracle Cluster Registry（OCR）には、RAC および Cluster Ready Services（CRS）に関するクラスタとデータベースの構成情報が含まれています。これらの構成情報には、クラスタ・データベース・ノード・リスト、CRS アプリケーション・リソース・プロファイル、イベント・マネージャ（EVM）の認可などがあります。ocrconfigツールを使用して、OCR の内容をコピーする方法と、その内容をリカバリで使用する方法があります。初の方法では、自動的に生成される物理的な OCR ファイル・コピーを使用します。2 番目の方法では、手動で作成される論理的な OCR エクスポート・ファイルを使用します。ocrconfigを使用して作成されるバックアップ・ファイルは、標準のオペレーティング・システムまたはサード・パーティ製ツールを使用して、オペレーティング・システムのバックアップの一部としてバックアップされます。




高速アプリケーション・フェイルオーバーに関する推奨事項

高速アプリケーション・フェイルオーバーに関する推奨事項高速アプリケーション・フェイルオーバーに関する推奨事項高速アプリケーション・フェイルオーバーに関する推奨事項高速アプリケーション・フェイルオーバーに関する推奨事項高可用性アーキテクチャでは、クライアントおよび中間層アプリケーションは Real Application Cluster 内で使用可能なサービスにリダイレクトでき、Data Guard またはレプリケートされたデータベースをカスタマイズできます。通常、このリダイレクトは透過的で、クライアントまたは中間層アプリケーションの計画停止時間および計画外停止時間の削減に使用できます。

サービスは、透過的な高速アプリケーション・フェイルオーバーの前提条件です。RAC でサービスを作成するとき、デフォルト（通常）で使用可能な（リカバリ）処理に対してサービスをインスタンスに割り当てることができます。サービスを割り当てたインスタンスが使用不可能になると、RAC では、サービスを停止せずに、ユーザーを使用可能なインスタンスに再接続できます。クライアントおよび中間層アプリケーションは、グローバル名を使用してサービスを指定し、接続を要求します。接続情報は、そのサービスを公開できるすべての本番インスタンスまたはデータベースで認識される必要があります。サービスを使用すると、あらゆるタイプの高可用性または障害時リカバリについて、計画的および計画外の操作の両方をモデル化して配置できます。

クラスタ・データベースでの変更に対処するには、RAC の Cluster Ready Services（CRS）、イベント・システムおよびサービス・コールアウトを使用して、クライアントおよび中間層アプリケーションに自動的に通知できます。イベント通知は、ネットワーク・タイムアウトをなくし、重要なリソースに対するエンド・トゥ・エンドの制御を行うために、障害発生後にリカバリ処理を開始するように構成できます。RAC から JDBC クライアントへは、高速JDBC 接続フェイルオーバーを介して高速かつ自動的に通知されます。ただし、RAC は、ユーザーが特別なコールアウトをカスタマイズしてデータベースの UPイベントと DOWNイベントに応答できるように、強力なコールアウトとイベント・システムを提供します。これらのコールアウトを使用して中間層アプリケーションに通知し、問題が発生している既存の接続を中断して、別の接続を使用可能なリソースにリダイレクトします。

また、障害時リカバリの場合は、新しい本番データベースは、本番サービスを公開して古い本番データベース上のサービスを停止するように構成できます。この場合も、中間層アプリケーションへの通知にコールアウトが必要です。

高速アプリケーション・フェイルオーバーを構成する場合は、中間層アプリケーションおよびクライアントに関する次の推奨事項に従ってください。

� すべての本番インスタンスの接続記述子の構成

� RAC の可用性通知およびイベントの使用

� RAC の通知を使用できない場合の透過的アプリケーション・フェイルオーバーの使用

– 適切な再試行および遅延を使用して、障害時リカバリ・サイトに接続します。

– TCP システム・パラメータを調整して、TCP/IP タイムアウトを削減します。

すべてのデータベースに関する次の推奨事項に従ってください。

� サービスの構成



RAC に関する次の推奨事項に従ってください。

� 高可用性を維持するための CRS の構成

� 中間層アプリケーションとクライアントに通知するためのサービス・コールアウトの構成

Data Guard、レプリケート環境または分散環境の場合は、次の推奨事項に従ってください。

� スタンバイまたは本番以外のサービスの公開

� 本番サービスの公開

すべての本番インスタンスの接続記述子の構成すべての本番インスタンスの接続記述子の構成すべての本番インスタンスの接続記述子の構成すべての本番インスタンスの接続記述子の構成クライアントおよび中間層アプリケーションは、グローバル名を使用してサービスを指定し、接続を要求します。接続情報は、そのサービスを公開できるすべての本番インスタンスまたはデータベースで認識される必要があります。さらに、接続記述子は、LDAP またはOracle Names Server に格納するとメンテナンスや管理が容易になります。

この項では、Oracle Net の接続記述子の 3 つの例について説明します。使用可能なスタンバイ・データベースがない場合、または DNS サイトのフェイルオーバーが配置されている場合は、例 7-1 の PROD_RAC接続記述子を使用してください。

例 7-2 の PROD_RAC_DG接続記述子には、RAC の本番インスタンスおよび Data Guard のスタンバイ・インスタンスが含まれたアドレス・リストがあります。この例は、本番データベースの停止時に、ハードウェア・クラスタが使用可能な場合に使用できます。この例は、TCP/IP タイムアウトの回避に役立ちます。

ハードウェア・クラスタ全体に障害が発生した場合は、例 7-3 の接続記述子を使用して、スタンバイ・データベースを指すように接続を手動で調整する必要があります。

障害時リカバリについては、本番インスタンスおよびスタンバイ・データベース・インスタンスの両方をリストするより、クライアント側の DNS フェイルオーバーまたはサイト・フェイルオーバーをお薦めします。

関連項目関連項目関連項目関連項目 : 10-3 ページ「全体または部分的なサイト・フェイルオーバー」



例例例例 7-1 接続記述子接続記述子接続記述子接続記述子 : 使用可能なスタンバイ・データベースがない場合、または使用可能なスタンバイ・データベースがない場合、または使用可能なスタンバイ・データベースがない場合、または使用可能なスタンバイ・データベースがない場合、または DNS サイトのサイトのサイトのサイトの

フェイルオーバーが配置されている場合フェイルオーバーが配置されている場合フェイルオーバーが配置されている場合フェイルオーバーが配置されている場合

PROD_RAC= (DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE=on) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE1)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE2)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE3)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE4)(PORT = 1520)) (CONNECT_DATA = (SERVICE_NAME = MAA_PROD)))

例例例例 7-2 接続記述子接続記述子接続記述子接続記述子 : 本番データベースが停止してハードウェア・クラスタが使用可能な場合本番データベースが停止してハードウェア・クラスタが使用可能な場合本番データベースが停止してハードウェア・クラスタが使用可能な場合本番データベースが停止してハードウェア・クラスタが使用可能な場合

PROD_RAC_DG= (DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE=on) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE1)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE2)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE3)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE4)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = DG_INSTANCE1)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = DG_INSTANCE2)(PORT = 1520))) (CONNECT_DATA = (SERVICE_NAME = MAA_PROD)))

例例例例 7-3 接続記述子接続記述子接続記述子接続記述子 : ハードウェア・クラスタに障害が発生した場合ハードウェア・クラスタに障害が発生した場合ハードウェア・クラスタに障害が発生した場合ハードウェア・クラスタに障害が発生した場合

PROD_DR= (DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE=on) (ADDRESS = (PROTOCOL = TCP)(HOST = DG_INSTANCE1)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = DG_INSTANCE2)(PORT = 1520))) (CONNECT_DATA = (SERVICE_NAME = MAA_PROD)))



RAC の可用性通知およびイベントの使用の可用性通知およびイベントの使用の可用性通知およびイベントの使用の可用性通知およびイベントの使用中間層アプリケーションおよびクライアントで、RAC の自動可用性通知およびイベントを使用するのが理想的です。Oracle Database 10g の高速 JDBC 接続フェイルオーバーを使用するアプリケーションは、これらのイベントを自動的にサブスクライブします。これ以外のアプリケーションは、サービス・コールアウトを構成し、それに対してアプリケーションが動作するように変更することが必要になる場合があります。

RAC の通知を使用できない場合の透過的アプリケーション・フェイルオーの通知を使用できない場合の透過的アプリケーション・フェイルオーの通知を使用できない場合の透過的アプリケーション・フェイルオーの通知を使用できない場合の透過的アプリケーション・フェイルオーバーの使用バーの使用バーの使用バーの使用

RAC の通知を使用できない場合、または RAC が配置されていない場合は、透過的アプリケーション・フェイルオーバー（TAF）を使用します。Oracle Call Interface（OCI）クライアント・アプリケーションを使用すると、アプリケーション・サーバーとデータベース・サーバー間で接続を透過的にフェイルオーバーするように、透過的アプリケーション・フェイルオーバー（TAF）を構成できます。

OCI クライアント・アプリケーションは、フェイルオーバーおよび状態の自動的なリカバリに役立つコールバック関数の後に、自動再接続を利用できます。また、中断された SELECT文および状態の自動的なリカバリに役立つコールバック関数を再実行できます。Oracle JDBC および ODBC ドライバでも、データベースの自動再接続および中断された SELECT文の再実行をサポートしているため、追加のアプリケーション・コードを記述する必要はありません。

TAF の構成は、クライアントがデータベースへの接続で使用する接続文字列で指定します。

次の TAF の接続記述子例を使用して、TAF の影響および各構成要素の使用方法について説明します。

PROD= (DESCRIPTION = (FAILOVER=on) (ADDRESS_LIST = (LOAD_BALANCE=on) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE1)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE2)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE3)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE4)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = DG_INSTANCE1)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = DG_INSTANCE2)(PORT = 1520))) (CONNECT_DATA =


� 7-51 ページ「中間層アプリケーションとクライアントに通知するためのサービス・コールアウトの構成」

� 『Oracle Database JDBC 開発者ガイドおよびリファレンス』



(SERVICE_NAME = MAA_PROD) (FAILOVER_MODE = (BACKUP=PROD_BACKUP)(TYPE=SESSION)(METHOD=BASIC)(RETRIES=12)(DELAY=5))))

PROD_BACKUP= (DESCRIPTION = (FAILOVER=on) (ADDRESS_LIST = (LOAD_BALANCE=on) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE1)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE2)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE3)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = RAC_INSTANCE4)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = DG_INSTANCE1)(PORT = 1520)) (ADDRESS = (PROTOCOL = TCP)(HOST = DG_INSTANCE2)(PORT = 1520))) (CONNECT_DATA = (SERVICE_NAME = MAA_PROD) (FAILOVER_MODE = (BACKUP=PROD)(TYPE=SESSION)(METHOD=BASIC)(RETRIES=12)(DELAY=5))))

新規の接続新規の接続新規の接続新規の接続新規の接続では、アドレス・リストを使用して、サービス（MAA_PROD）が登録済で初に使用可能なリスナーに接続します。これは、インスタンス障害とリスナー障害の両方で同様です。障害が発生したノードに接続しようとすると、TCP/IP タイムアウトが発生します。新規の接続ではアドレス・リストを 1 回のみ試行するため、再試行や遅延による影響は受けません。

既存の接続既存の接続既存の接続既存の接続既存の接続では、バックアップの接続記述子を使用し、反復するたびに DELAYに指定された秒数のみ待機します。バックアップの接続記述子内にあるすべてのアドレスを試行した後、クライアントは DELAYに指定された秒数だけ待機してからアドレス・リストを再試行します。クライアントは、RETRIESに指定された回数までアドレス・リストを再試行します。RETRIESに DELAYを乗算した秒数が経過した後にサービスが使用不可能な場合、クライアントは ORA-03113 エラーを受け取ります。障害時リカバリ・サイトへのクライアントの自動フェイルオーバーを実行する場合、スイッチオーバーまたはフェイルオーバーの大回数は RETRIES× DELAY未満にする必要があります。



接続記述子内の接続記述子内の接続記述子内の接続記述子内の LOAD_BALANCE パラメータパラメータパラメータパラメータLOAD_BALANCEは、クライアント側のロード・バランシングを設定します。このパラメータを ONに設定すると、クライアントはアドレス・リストからランダムにアドレスを選択します。リスナーに同じサービスを提供するインスタンスが複数登録されている場合、リスナーは、その時点のインスタンスの負荷に応じて、クライアント要求のバランスをインスタンス間で調整できます。

接続記述子内の接続記述子内の接続記述子内の接続記述子内の FAILOVER パラメータパラメータパラメータパラメータFAILOVERパラメータは ONに設定します。アドレス・リストにあるサービス、インスタンス、リスナーまたはノードが 1 つ以上停止または使用不可能になるとクライアントはアドレス・リストで失敗します。

接続記述子内の接続記述子内の接続記述子内の接続記述子内の SERVICE_NAME パラメータパラメータパラメータパラメータサービス名は、データベースによってリスナーに公開されます。

接続記述子内の接続記述子内の接続記述子内の接続記述子内の RETRIES パラメータパラメータパラメータパラメータこのパラメータは、既存の接続が、フェイルオーバー後に BACKUPリスト内のアドレスを再試行する回数を指定します。このパラメータは、新規の接続には影響を与えません。新規のクライアントは、アドレス・リストを 1 回のみ試行します。

接続記述子内の接続記述子内の接続記述子内の接続記述子内の DELAY パラメータパラメータパラメータパラメータこのパラメータは、クライアントが再試行ごとに待機する秒数を指定します。クライアントは、アドレス・リストを試行した後、DELAYに指定された秒数だけ待機してから再試行します。アドレス・リスト内のアドレス間での遅延はありません。この遅延は、リスト全体を試行した後にのみ適用されます。

RAC を使用すると、RAC は仮想インターネット・プロトコル（VIP）およびクラスタ別名を管理するため、クラスタ内のノードの使用不可が原因による TCP/IP タイムアウトの発生を回避できます。ただし、クラスタ全体または RAC 以外のホストが使用不可能になると、TCP/IP タイムアウトは回避できません。この TCP/IP タイムアウトを回避するには、次のいずれかを実行する必要があります。

� このようなイベントを検出して対処するための特別なイベントとコールアウトを作成します。

� TCP/IP パラメータを調整して、タイムアウト全体の影響を軽減します。

コールアウトをカスタマイズして、既存の接続を中断し、使用不可能なノードやクラスタを含まない新規の接続記述子を使用して新規の接続にリダイレクトする必要があります。



TCP/IP パラメータを調整すると、他のアプリケーションやシステムに影響を与える場合があるため、常に注意する必要があります。ただし、次の TCP/IP パラメータは、Oracle のテストによって、Solaris プラットフォームで TCP/IP タイムアウト全体の間隔が短縮されるように変更されています。

� tcp_ip_abort_cinterval

� tcp_ip_abort_interval

� tcp_keepalive_interval

使用しているオペレーティング・システム・プラットフォームのドキュメントで、これらのパラメータを確認してください。

サービスの構成サービスの構成サービスの構成サービスの構成RAC 内では、Database Configuration Assistant（DBCA）、Server Control（SRVCTL）または DBMS_SERVICE PL/SQL パッケージを使用して、サービスを作成します。作成したサービスは、DBCA または Enterprise Manager を使用して管理します。RAC 以外の環境の場合は、SERVICE_NAMEデータベース初期化パラメータを設定してください。

高可用性を維持するための高可用性を維持するための高可用性を維持するための高可用性を維持するための CRS の構成の構成の構成の構成CRS は、サービスの可用性を継続して維持するためのサービスおよびワークロード管理フレームワークをサポートします。CRS は、データベース、データベース・クラスタ別名、RAC をサポートするすべてのノードに対してローカルなリソースなど、RAC の他のリソースもサポートします。

ノード・リソースには、ノード用の仮想インターネット・プロトコル（VIP）アドレス、グローバル・サービス・デーモン、Enterprise Manager エージェントおよび Oracle Net リスナーが含まれます。これらのリソースは CRS がノードとともに開始すると自動的に開始され、リソースが失敗すると CRS は自動的にそのリソースを再起動します。






中間層アプリケーションとクライアントに通知するためのサービス・コー中間層アプリケーションとクライアントに通知するためのサービス・コー中間層アプリケーションとクライアントに通知するためのサービス・コー中間層アプリケーションとクライアントに通知するためのサービス・コールアウトの構成ルアウトの構成ルアウトの構成ルアウトの構成

UP、DOWNおよび NOT_RESTARTINGの各イベントについて中間層アプリケーションおよびクライアントに通知するために、サービス・コールアウトを構成します。RAC は高速 JDBC接続フェイルオーバーを介して自動的に JDBC クライアントに通知するため、調整は必要ありません。まれなケースですが、RAC クラスタ全体に障害が発生した場合は、障害時リカバリまたはセカンダリ・データベースに接続するために、別の通知とコールアウトを使用して中間層アプリケーションに通知する必要があります。

中間層アプリケーションまたはクライアントが JDBC クライアントでない場合は、RAC のイベント管理機能およびサービス・コールアウト機能を使用して、カスタマイズされたコールアウトを構成する必要があります。コールアウトでは、中間層アプリケーションに次の処理の実行を通知する必要があります。

� 問題が発生しているか、使用不可能なノードまたはインスタンスへの既存の接続を中断すること

� 使用可能な本番インスタンスまたはノードに新規接続をリダイレクトすること

既存の接続を中断すると、TCP/IP タイムアウトによる長時間の遅延を回避できます。使用可能な本番インスタンスまたはノードに新規接続をリダイレクトするとき、TCP/IP タイムアウトを回避するために、アクセス不可能なホストが含まれていない新規接続記述子を渡す必要があります。

スタンバイまたは本番以外のサービスの公開スタンバイまたは本番以外のサービスの公開スタンバイまたは本番以外のサービスの公開スタンバイまたは本番以外のサービスの公開RAC と Enterprise Manager が統合されている場合は、スタンバイまたは本番以外のサービスを自動的に公開できます。スタンバイ・データベースが Enterprise Manager で管理されていない場合、または RAC 環境内に存在しない場合は、SERVICE_NAMEデータベース初期化パラメータを本番以外のサービスに手動で変更できます。次に例を示します。

SQL> ALTER SYSTEM SET SERVICE_NAME='STANDBY';

本番サービスの公開本番サービスの公開本番サービスの公開本番サービスの公開RAC と Enterprise Manager が統合されている場合は、本番サービスを自動的に公開できます。新規の本番データベースが Enterprise Manager で管理されていない場合または RAC 環境内に存在しない場合は、SERVICE_NAMEデータベース初期化パラメータを手動で変更して、別の本番サービスに設定できます。次に例を示します。

SQL> ALTER SYSTEM SET SERVICE_NAME='PROD_SVC1, PROD_SVC2, PROD_SVC3';

PROD_SVC1には、たとえば SALESや HRなどを指定できます。



第第第第 IV 部部部部
高い可用性を備えた高い可用性を備えた高い可用性を備えた高い可用性を備えた Oracle 環境の管理環境の管理環境の管理環境の管理
第Ⅳ部では、高い可用性を備えた Oracle 環境の管理方法について説明します。


� 第 8 章「Oracle Enterprise Manager を使用した監視と検出」


� 第 10 章「リカバリ手順の詳細」

� 第 11 章「フォルト・トレランスのリストア」

Oracle Enterprise Manager を使用

8
Oracle Enterprise Manager を使用したを使用したを使用したを使用した
監視と検出監視と検出監視と検出監視と検出

この章では、アプリケーション・スタックのすべての層にわたって高可用性の環境を、Oracle Enterprise Manager を使用して監視および保持するための推奨事項を説明します。さらに、高可用性な Enterprise Manager の構成方法も説明します。

� 高可用性の監視と検出の概要

� Enterprise Manager を使用したシステムの監視

� Enterprise Manager による HA 環境の管理

� Enterprise Manager の高可用性アーキテクチャ

� Enterprise Manager の追加構成

した監視と検出 8-1

高可用性の監視と検出の概要

高可用性の監視と検出の概要高可用性の監視と検出の概要高可用性の監視と検出の概要高可用性の監視と検出の概要問題の早期検出は、システム、ネットワーク、データベース操作、アプリケーションおよびその他のシステム・コンポーネントに対する継続的な監視によって確実なものとなります。早期検出によって問題が迅速に解決されるため、ユーザーのシステム経験が向上します。さらに、監視によって、システム・パフォーマンスの向上および再発する問題の傾向を示すシステム・メトリックが取得されます。この情報は、問題の予防、セキュリティ・ポリシーの実施およびジョブ処理の管理に役立てることができます。データベース・サーバーの場合の安定した監視システムでは、可用性を測定し、データベース・サーバーが使用不可となる原因のイベントを検出し、重要な障害に関与している部門に迅速に通知する必要があります。

監視システムは、それ自体が高い可用性を備えている必要があり、監視対象のリソースと同じ操作上のベスト・プラクティスと可用性プラクティスを装備している必要があります。監視システムの障害は、監視対象のすべてのシステムでの診断データの取得や管理者への問題の警告が不可能になることを意味します。

Oracle Enterprise Manager には、多様な通知オプションを備えた管理機能と監視機能が用意されています。この章では、アプリケーション・スタックのすべての層にわたって高い可用性を備えた環境を、Enterprise Manager を使用して監視および保持するための推奨事項を説明します。これらの推奨事項は、環境の可用性とパフォーマンスの監視方法、およびこのツールを環境の変化に対応して使用する場合に利用できます。さらに、高い可用性を備えたEnterprise Manager の構成方法および構成に関する追加のヒントも説明します。

Enterprise Manager を使用したシステムの監視を使用したシステムの監視を使用したシステムの監視を使用したシステムの監視この項では、Enterprise Manager の概念と機能についてその概要を説明します。

Enterprise Manager の大きな利点は、ホストのオペレーティング・システムからユーザーまたはパッケージ・アプリケーションに至るアプリケーション・スタック全体にわたってコンポーネントを管理できる点にあります。Enterprise Manager は、アプリケーションの各レイヤーをターゲットターゲットターゲットターゲットとして処理します。このため、データベース、アプリケーション・サーバー、ハードウェアなどのターゲットは、同じタイプの他のターゲットとともに表示したり、アプリケーション・タイプ別にグループ化できます。すべてのターゲットを単一のビューでレビューすることもできます。各ターゲット・タイプにはデフォルトで生成されたホーム・ページがあり、特定ターゲットに関する詳細のサマリーが表示されます。異なるタイプの複数のターゲットはファンクション別にグループ化できます。つまり、同じアプリケーションをサポートするリソースとしてグループ化できます。

すべてのターゲットは、Oracle Management Agent によって監視されます。マシン上で実行される Management Agent によって、一連のターゲットが監視されます。ターゲットは、Management Agent が実行されているマシンとは異なるマシン上に存在している場合があります。たとえば、Management Agent は、エージェントをネイティブにホスティングできないストレージ・アレイを監視できます。ホストに Management Agent がインストールされている場合、そのホストは、マシン上の他のターゲットとともに自動的に検出されます。

図 8-1 の「Grid Control」ホーム・ページには、検出されたすべてのターゲットの可用性が図で示されています。


Enterprise Manager を使用したシステムの監視

図図図図 8-1「「「「Grid Control」ホーム・ページ」ホーム・ページ」ホーム・ページ」ホーム・ページ

「Grid Control」ホーム・ページには、次の重要な情報が表示されます。

� すべてのターゲットに関する現在の可用性のスナップショット。可用性に関する円グラフは、使用できない（停止）ターゲットやコンソールとの接続を失った（不明）ターゲットを管理者に対して迅速に示します。

� 監視システム全体で認識されているアラート件数（イベントの場合）と問題件数（ジョブの場合）の概要。詳細な情報を表示するには、リンクをクリックするか、「Enterprise Manager」ページの右上から「「「「Alerts」」」」にナビゲートします。

� ターゲットへのショートカット。このショートカットは、特定ターゲットに対してタスクを実行する必要がある管理者が使用します。

� システムで実際に検出された内容に関する概要。このリストは、ハードウェア・レベルと Oracle レベルで表示できます。

� 他の Oracle オンライン・リソースへの有用な一連のリンク。

アラートは複数要素の組合せによって生成され、特定のメトリックメトリックメトリックメトリック上に定義されます。メトリックは Management Agent によってサンプリングされたデータ・ポイントで、Oracle Management Repository に送信されます。このメトリックは、簡単なハートビート・テス

Oracle Enterprise Manager を使用した監視と検出 8-3


ト、「ディスク・ビジー」などの特定パフォーマンス測定の評価、または特定の待機イベントを待機しているプロセスの比率を使用したコンポーネントの可用性です。

メトリックについては、エラー、警告、クリティカルおよびクリアの 4 つの状態をチェックできます。管理者は、次の内容について方針を決定する必要があります。

� 監視対象のオブジェクト（データベース、ノード、リスナーまたは他のサービス）

� サンプリングの手段（可用性や CPU のビジー比率など）

� イベントのサンプリング頻度

� メトリックが事前定義のしきい値を超えた時の処理

これらすべては、システムのビジネス・ニーズを基礎にして決定されますたとえば、可用性についてすべてのコンポーネントを監視しますが、一部のシステムはビジネス時間のみ監視する場合があります。特定のパフォーマンスに関して問題があるシステムには、問題のデバッグに対応した追加のパフォーマンス追跡を指定できます


� 各システムに対するデフォルトの通知ルールの設定

� 「Database Target」ビューを使用した状態、可用性およびパフォーマンスの監視

� イベント通知を使用したメトリック変更への対応

� イベントを使用した Data Guard システム可用性の監視


� 『Oracle Enterprise Manager 概要』

� Oracle Enterprise Manager にメトリックを設定する方法の詳細は、『Oracle Database 2 日でデータベース管理者』を参照してください。



各システムに対するデフォルトの通知ルールの設定各システムに対するデフォルトの通知ルールの設定各システムに対するデフォルトの通知ルールの設定各システムに対するデフォルトの通知ルールの設定通知ルール通知ルール通知ルール通知ルールはメトリックに関する一連の定義済アラートで、Enterprise Manager で検出されたターゲットに対して自動的に適用されます。たとえば、管理者はデータベース・ターゲットの可用性を監視するルールを作成して、データベースの障害時に電子メール・メッセージを生成できます。生成したルールは、既存のすべてのデータベースおよび今後作成されるデータベースにも適用されます。これらのルールにアクセスするには、「「「「Preferences」」」」にナビゲートしてから、「「「「Rules」」」」を選択します。

このルールは、迅速な対処が必要な問題を監視します。これらの問題には、サービスの可用性に影響を与える問題および Oracle エラーやアプリケーション・エラーなどがあります。サービスの可用性は、アプリケーション・スタックのレイヤー（ノード、データベース、リスナーおよび重要なアプリケーション・データ）での停止によって影響を受ける可能性があります。データベースへの接続不可やアプリケーションの機能にとって重要なデータへのアクセス不可など、サービスの可用性に関する障害は、迅速に識別してレポートし、対応する必要があります。満杯状態のアーカイブ・ログ・ディレクトリなどの潜在的なサービス可用性の停止に対しても、システムの停止を回避するために適切な対処が必要です。

Enterprise Manager には、可用性を監視するための強力なフレームワークを備えた一連のデフォルト・ルールが用意されています。デフォルト・ルールは、Enterprise Manager に伴う事前インストール済のターゲット・タイプにそれぞれ設定されています。これらのルールは、各個別サイトの方針に準拠するように変更できます。また、サイト固有のターゲットやアプリケーション用に新しいルールを作成できます。ルールを設定して、特定期間については自動化された適用方針を作成することを、ユーザーに通知することもできます

次の推奨事項を考慮してください。

� ルール変更ウィザードを使用して、ターゲット・アーキテクチャ内の高い値のコンポーネントに対する各ルールを変更し、必要な可用性の要件に適合させます。データベース・ルールの場合は、表 8-1、表 8-2 および表 8-3 のイベントを各ターゲットに設定します。監視する頻度は、各コンポーネントの品質保証契約（SLA）で決められています。

� 通知方法を追加し、各通知ルールで使用します。デフォルトでは、管理者に潜在的な問題を警告するも容易な方法は電子メールの送信です。この通知方法を、SNMP トラップへのコールアウトまたはアラートを電子メール以外の方法で送信するオペレーティング・システムのスクリプトを追加することで補足します。これによって、電子メール・システムのコンポーネントに支障が生じた場合の問題を回避します。「Enterprise Manager」ページの上部にある「「「「Set-up」」」」リンクを使用して、通知方法を追加設定します。

� ターゲットの可用性の計算でエラーが発生したことを管理者に通知するように通知ルールを変更します。この変更によって、コンポーネントの可用性について不正確な読取値が生成される場合がありますが、システム管理者には高レベルの通知を送信できます。

図 8-2 に、可用性の状態を選択するための「Notification Rule property」ページを示します。「Down」、「Agent Unreachable」、「Agent Unreachable Resolved」および「Metric Error

Detected」が選択されています。



図図図図 8-2 可用性に対する通知ルールの設定可用性に対する通知ルールの設定可用性に対する通知ルールの設定可用性に対する通知ルールの設定

さらに、表 8-1、表 8-2 および表 8-3 に示したメトリックをレポートするために、データベース・ルールで監視するメトリックを変更します。この変更によって、これらのメトリックがすべてのデータベース・ターゲットについて取得され、傾向データが今後の分析で使用できるようになります。表 8-1、表 8-2 および表 8-3 で説明されているすべてのイベントは、「「「「Database Homepage」」」」からアクセスできます。「「「「All Metrics」」」」→「「「「Expand All」」」」を選択してください。

サービス停止の原因となる可能性がある領域管理の状態は、表 8-1 に示したイベントを使用して監視する必要があります。



アラート・ログのメトリック・グループから、Enterprise Manager を設定して、表 8-2 に示すようなエラーのアラート・ログを監視します。

表表表表 8-1 領域の監視に対する推奨事項領域の監視に対する推奨事項領域の監視に対する推奨事項領域の監視に対する推奨事項

メトリックメトリックメトリックメトリック推奨事項推奨事項推奨事項推奨事項

表領域使用率（%）このメトリックは、重要なハードウェア・サーバーのルート・ファイル・システムを監視するために設定します。このメトリックによって、管理者は、Enterprise Managerによるテストで照合するしきい値の比率、および管理者へのメッセージ生成に必要なエラーのサンプル件数を選択できます。推奨するデフォルト設定は、警告で 70 パーセ

ント、エラーで 90 パーセントですが、システムの使用状況に従って調整する必要があ

ります。このメトリックは、特定の表領域のみを監視するようにカスタマイズできます。

このメトリックおよび類似のイベントは、表領域フルのメトリック・グループ内に設定できます。

アーカイバ・ハングのアラート・ログ・エラー

このメトリックは、ORA-00257 エラーのアラート・ログを監視するために設定します。

このエラーは、満杯状態のアーカイブ・ログ・ディレクトリを示します。

このメトリックは、アラート・ログ・エラー・ステータスのメトリック・グループ内に設定できます。

アーカイブ領域使用率（%）このメトリックは、複数のしきい値と適切なサンプリング時間とともに設定します。このメトリックによって、システム停止の原因となる満杯状態のアーカイブ・ディレクトリを管理者にアラートできます。推奨するデフォルト設定は、警告で 70 パーセン

ト、エラーで 90 パーセントですが、システムの使用状況に従って調整する必要があり

ます。

このメトリックは、アーカイブ領域のメトリック・グループ内に設定できます。

ダンプ領域使用率（%）このメトリックは、ダンプ・ディレクトリの宛先を監視するために設定します。ダンプ領域は、初のエラー発生時に診断情報を大限格納できるように確保する必要があります。推奨するデフォルト設定は、警告で 70 パーセント、エラーで 90 パーセン

トですが、システムの使用状況に従って調整する必要があります。

このメトリックは、ダンプ領域のメトリック・グループ内に設定できます。

表表表表 8-2 アラート・ログの監視に対する推奨事項アラート・ログの監視に対する推奨事項アラート・ログの監視に対する推奨事項アラート・ログの監視に対する推奨事項


アラートこのメトリックは、ORA-6XX エラー、ORA-01578 エラー（データベース破損）また

は ORA-00060 エラー（デッドロック検出）の発生時に、アラートを送信するために設

定します。他のエラーが発生した場合は、警告メッセージが生成されます。

データ・ブロック破損このメトリックは、ORA-01157 エラーと ORA-27048 エラーのアラート・ログを監視

するために設定します。これらのエラーは、Oracle Database のデータファイルの破損

を示します。

Data Guard のログ転送このメトリックを設定します。



システムを監視して、処理容量を超えていないことを確認します。これらのイベントの警告レベルと重要レベルは、システムの使用パターンに基づいて変更する必要があります。データベース制限のメトリック・グループからイベントを設定します。表 8-3 に推奨事項を示します。

図 8-3 に、メトリックを選択および設定するための「Notification Rule」プロパティ・ページを示します。「Critical」と「Warning」が、通知に対する重大度の状態としてすでに選択されています。左側のリスト・ボックスに、「Available Metrics」のリストが表示されています。通知用に選択されたメトリックは、右側のリスト・ボックスに表示されています。

図図図図 8-3 メトリックに対する通知ルールの設定メトリックに対する通知ルールの設定メトリックに対する通知ルールの設定メトリックに対する通知ルールの設定

表表表表 8-3 処理容量の監視に対する推奨事項処理容量の監視に対する推奨事項処理容量の監視に対する推奨事項処理容量の監視に対する推奨事項


プロセス制限このメトリックにしきい値を設定して、現在のプロセス数が PROCESSES初期化パラ

メータの値に達した場合に警告します。

セッション制限このメトリックにしきい値を設定して、インスタンスが、データベースで許容されている大同時接続数に達した場合に警告します。

関連項目関連項目関連項目関連項目 : 通知ルールとメトリックしきい値の設定方法の詳細は、『Oracle Database 2 日でデータベース管理者』を参照してください。



「「「「Database Target」ビューを使用した状態、可用性およびパフォーマンスの」ビューを使用した状態、可用性およびパフォーマンスの」ビューを使用した状態、可用性およびパフォーマンスの」ビューを使用した状態、可用性およびパフォーマンスの監視監視監視監視

図 8-4 の「Database Targets」ページには、システムのパフォーマンス、領域の使用率および重要な可用性コンポーネントの構成が表示されます。この可用性コンポーネントには、アーカイブ REDO ログ・ステータス、フラッシュバック・ログ・ステータス、インスタンスのリカバリ見積り時間などが含まれます。アラートは迅速に表示されます。各アラートの値は、このページのリンクから構成できます。

図図図図 8-4 システム・パフォーマンスの概要システム・パフォーマンスの概要システム・パフォーマンスの概要システム・パフォーマンスの概要

Enterprise Manager のメトリックの多くはパフォーマンスに関連しています。適切なパフォーマンスを伴わないシステムは、個々のコンポーネントのステータスにかかわらず、HA システムではありません。パフォーマンスの問題は重要なシステ停止の原因となり、一部の顧客にとっても停止の原因になります。このような停止は、一般的にアプリケーショアプリケーショアプリケーショアプリケーション・サービスのブラウンアウトン・サービスのブラウンアウトン・サービスのブラウンアウトン・サービスのブラウンアウトと呼ばれています。この停止の主な原因は、1 つ以上のインフラストラクチャ・コンポーネントの断続的または一時的な障害にあります。IT マネージャは、インフラストラクチャ・コンポーネントがどのように実行されているのか（応答時間、待機時間および可用性）、およびエンド・ユーザーに配置されたアプリケーション・サービスにどのような影響を与えているのかを認識している必要があります。

SLA を満たす通常の操作から導出されるパフォーマンス・ベースラインでは、パフォーマンス・メトリック・アラートの構成内容を決定する必要があります。ベースライン・データはアプリケーションが本番となる初の日から収集し、次の統計情報を含める必要があります。

� アプリケーション統計情報（トランザクション量、応答時間、Web サービス時間）

� データベース統計情報（トランザクション・レート、REDO レート、ヒット率、上位 5つの待機イベント、上位 5 つの SQL トランザクション）

� オペレーティング・システム統計情報（CPU、メモリー、I/O、ネットワーク）



Enterprise Manager では、データベース・パフォーマンスのスナップショットをベースラインとして取得できます。Enterprise Manager では、これらの値をシステム・パフォーマンスと照合して比較し、その結果をデータベースの「Target」ページに表示できます。また、この値が設定したベースラインから大きく逸脱している場合は、アラートを送信することもできます。

データベースの通知ルールを設定し、すべてのデータベース・ターゲットについて、表 8-4にリストされているメトリックを取得します。これらのパラメータの分析は、1 つのツールで実行でき、履歴データが使用できるようになります。

表表表表 8-4 メトリックに対する推奨通知ルールメトリックに対する推奨通知ルールメトリックに対する推奨通知ルールメトリックに対する推奨通知ルール


ディスク I/O（毎秒）このメトリックはデータベース・レベルのメトリックで、データベースによる I/O の

操作件数を監視します。操作件数がユーザー定義のしきい値を超えると、アラートを送信します。このメトリックは、Enterprise Manager でも使用できるオペレーティン

グ・システム・レベルのイベントと併用します。

このメトリックは、システムで使用可能な合計 I/O スループット、使用可能な I/Oチャネル数、ネットワーク帯域幅（SAN 環境の場合）、ストレージ・アレイ・デバイ

スを使用している場合のディスク・キャッシュの効果、大 I/O レートおよびデータ

ベースで使用可能なスピンドル数に基づいて設定します。

% CPU ビジーこのメトリックは、75 パーセントで警告を、85 ～ 90 パーセントで重要なアラートを

送信するために設定します。この使用率はピーク時には通常ですが、応答を停止したプロセスや潜在的なリソース不足を示している場合もあります。

待機時間 % 過剰なアイドル時間は、1 つ以上のリソースが発生しているためのボトルネックを示し

ます。このメトリックは、アプリケーションが予測したパフォーマンスで実行されているときのシステム待機時間に基づいて設定します。

ネットワーク・バイト数（毎秒）

このメトリックは、Oracle が生成するネットワーク通信量をレポートします。潜在的

なネットワークのボトルネックを示すことができます。このメトリックは、ピーク時の実際の使用率に基づいて設定します。

合計解析（毎秒）このメトリックは、SQL のパフォーマンスを測定します。リソース不足の原因となっ

たアプリケーション変更や使用率の変更を示すことができます。ピーク時に基づいて設定します。

関連項目関連項目関連項目関連項目 : パフォーマンス監視の詳細は、『Oracle Database パフォーマンス・チューニング・ガイド』を参照してください。



イベント通知を使用したメトリック変更への対応イベント通知を使用したメトリック変更への対応イベント通知を使用したメトリック変更への対応イベント通知を使用したメトリック変更への対応提示メトリックの補足に使用できるオペレーティング・システム・イベントは多数あります。各ホストおよびインスタンスには、このようなオペレーティング・システム・イベントは必要ありません。ここで定義されているすべてのメトリックは、インスタンスまたはデータベースごとに個別に設定できます。設定するには、該当するオブジェクト・ターゲット・ページのナビゲーション・バーの下部にある「「「「Manage Metrics」」」」リンクを使用します。警告や重要なアラートのトリガーとなる値はここで変更できます。また、オペレーティング・システムのスクリプトをアクティブにして、Oracle Enterprise Manager 10g Grid Control に対して生成される標準のアラートの他に、メトリックのしきい値にも応答できます。

イベントを使用したイベントを使用したイベントを使用したイベントを使用した Data Guard システム可用性の監視システム可用性の監視システム可用性の監視システム可用性の監視ロジカルおよびフィジカルな Data Guard 構成の可用性を監視するには、Enterprise Manager のメトリックを設定します。Data Guard 環境が Enterprise Manager の Data Guard Manager 拡張子で登録されている場合は、次の表に示すイベントを設定します。

表表表表 8-5 Data Guard イベントの設定に対する推奨事項イベントの設定に対する推奨事項イベントの設定に対する推奨事項イベントの設定に対する推奨事項


Data Guard ステータスこのメトリックは、Data Guard 構成内のシステムに関する問題を通知するために設定

します。

未適用のデータこのメトリックは、後の受信したアーカイブ REDO ログとスタンバイ・データベー

スに後に適用されたログとの間のギャップ（分数で測定）がユーザー定義のしきい値を超えた場合を通知するために設定します。この情報を使用すると、スタンバイ・インスタンスのリカバリ時間が、定義されている停止リカバリのサービス・レベルを超えた場合、管理者に対して警告を送信できます。このメトリックは、スタンバイ・データベースに対するログ適用の指定に基づいて設定します。

未受信のデータこのメトリックは、本番データベースからスタンバイ・データベースへのアーカイブREDO ログの移動に大幅な遅延があった場合を通知するために設定します。このメト

リックは、本番データベース上のアーカイブ REDO ログの数とスタンバイ・サイトに

移動したアーカイブ REDO ログの数の差異が、ユーザー定義のしきい値を超えた場合

に発生します。このしきい値は、ネットワークを介してアーカイブ REDO ログを転送

する時間に基づいている必要があります。

このメトリックには、サンプル時間を概算のログ転送時間で設定し、2 以上の発生件数

を設定して不正確な要素を回避します。警告およびクリティカルなしきい値に対する推奨開始値は、それぞれ 1および 2です。


Enterprise Manager による HA 環境の管理

Enterprise Manager によるによるによるによる HA 環境の管理環境の管理環境の管理環境の管理Enterprise Manager は、システム管理の事前的な部分として使用し、問題の通知と分析のためにも使用します。この項では、次の推奨事項について説明します。

� Enterprise Manager ポリシー違反のチェック

� Enterprise Manager を使用した Oracle Patches の管理とシステム・ベースラインのメンテナンス

� Enterprise Manager を使用した Data Guard ターゲットの管理

Enterprise Manager ポリシー違反のチェックポリシー違反のチェックポリシー違反のチェックポリシー違反のチェックEnterprise Manager には、一連の事前インストールのポリシーとすべてのデータベースに対するベスト・プラクティスの推奨事項が伴います。これらのポリシーはデフォルトでチェックされ、違反件数が図 8-4 に示す「Targets」ページに表示されます。「Targets」ページで「「「「Policy Violations」」」」を選択し、リストされているすべての違反を参照してください。

Enterprise Manager を使用したを使用したを使用したを使用した Oracle Patches の管理とシステム・ベースラインの管理とシステム・ベースラインの管理とシステム・ベースラインの管理とシステム・ベースラインのメンテナンスのメンテナンスのメンテナンスのメンテナンス

Enterprise Manager を使用すると、アプリケーション環境における監視システムに対するパッチを http://metalink.oracle.comからダウンロードして管理できます。ユーザー環境に関連するパッチを定期的にチェックするようにジョブを設定できます。これらのパッチは、ダウンロードして Management Repository に直接格納できます。パッチはManagement Repository から複数のシステムにステージングし、メンテナンス・ウィンドウの間に適用できます。

パッチ・レベルは 1 つのマシンについて検討し、複数のマシン間では 1 対 1 または 1 対多の関係で比較できます。この場合は、1 つのマシンをベースラインとして識別し、他の複数のマシンにおけるメンテナンス要件を示すために使用できます。この方法は、オペレーティング・システムのパッチの他に、データベースのパッチでも実行できます。

関連項目関連項目関連項目関連項目 : 『Oracle Enterprise Manager 管理者ガイド』


Enterprise Manager による HA 環境の管理

Enterprise Manager を使用したを使用したを使用したを使用した Data Guard ターゲットの管理ターゲットの管理ターゲットの管理ターゲットの管理Enterprise Manager を使用すると、データベース・ターゲットに対してロジカル・スタンバイ・データベースとフィジカル・スタンバイ・データベースを設定できます。また、管理リポジトリが含まれているデータベース以外のデータベース・ターゲットのスイッチオーバーとフェイルオーバーも管理できます。

Enterprise Manager は、Data Guard 構成の状態を一覧で監視するためにも使用できます。データベース・ターゲットのページから Data Guard ステータスのセクションにナビゲートするには、「High Availability」セクションのリンクを使用します。このページには、プライマリ・ターゲットに対してアクティブなスタンバイ・データベース、送信待機中のログ・データの量とスタンバイ・データベースで受信したログ・データの量、およびそのデータの保護モードが表示されています。このページでは、データの保護モードも変更できます。

このページには、検証検証検証検証ファンクションへのリンクが含まれています。このファンクションは、Data Guard 環境およびログ転送サービスをチェックし、警告とエラーを表示します。この検証ファンクションは手動で実行する必要があります。自動化されていません。


Enterprise Manager の高可用性アーキテクチャ

Enterprise Manager の高可用性アーキテクチャの高可用性アーキテクチャの高可用性アーキテクチャの高可用性アーキテクチャEnterprise Manager のアーキテクチャは、図 8-5 に示すように、3 層のフレームワークで構成されています。

図図図図 8-5 Enterprise Manager のアーキテクチャのアーキテクチャのアーキテクチャのアーキテクチャ



アーキテクチャの構成要素は、次のとおりです。

� Web ベースのグリッド制御 : Enterprise Manager のユーザー・インタフェースで、コンピューティング環境全体を 1 箇所から集中管理します。ホスト、データベース、リスナー、アプリケーション・サーバー、HTTP サーバーおよび Web アプリケーションも含めて、企業内のすべてのサービスを 1 つの単位として容易に管理できます。

� Oracle Management Service および Oracle Management Repository: Management Service は、グリッド制御にユーザー・インタフェースをレンダリングする J2EE Web アプリケーションです。このアプリケーションは、監視情報とジョブ情報の処理ですべての Management Agent とともに動作し、そのデータ・ストアとして Management Repository を使用します。Management Repository は、Oracle データベース内の複数の表領域で構成されています。これらの表領域には、Enterprise Manager 内で管理されている管理者、ターゲットおよびアプリケーションに関する情報が含まれています。

� Oracle Management Agents: Management Agent は、監視対象の各ホストに配置されているプロセスです。Management Agent は、ホスト上のすべてのターゲットの監視、監視情報の Management Service への通信、そのホストにインストールされているホストと製品を管理およびメンテナンスします。この図の中で管理の対象となるターゲットは、データベース、サード・パーティのアプリケーションおよびアプリケーション・サーバーです。

� Database Control を使用すると、単一の Oracle データベース・インスタンスまたはクラスタ・データベースを監視および管理できます。

� Application Server Control を使用すると、単一の Oracle Application Server インスタンス、Oracle Application Server インスタンスのファームまたは Oracle Application Server クラスタを監視および管理できます。

Enterprise Manager には、それ自体を監視する一連の詳細なツールが用意されています。

「Management System」ページは、Enterprise Manager の事前定義のコンポーネントです。このページは、管理者に対して、Enterprise Manager コンポーネント、エージェント・データ処理での未処理およびコンポーネントの可用性の概要を示します。

「Management System」ページには、基本的なメトリックが表示されます。これには、リポジトリ内の領域の量およびリポジトリへのロードを待機しているデータの量も含まれます。このページには、管理システムに対するアラートと警告も表示されます。「Repository Operations」ページには、管理システムを構成している個別のコンポーネント・タスクの概要が表示されます。また、「Repository Operations」ページには、個別のコンポーネントの早見表が表示されます。これには、CPU リソースの使用量と処理エラーが含まれます。製品のインストール時に作成されたデフォルトの通知ルールは、Enterprise Manager コンポーネントに関する問題をシステム管理者に通知するように構成する必要があります。



Enterprise Manager 環境を監視するには、次のオプションを設定します。

� リポジトリ操作の通知ルールを変更して、Management Service のステータス、データを提供しないターゲットおよびローダーの合計実行時間を更新します。このルールには、「Notifications Rules」からアクセスします。8-5 ページの「各システムに対するデフォルトの通知ルールの設定」を参照してください。

� emd.propertiesを、Management Service または Management Repository のノードを監視するエージェントの有効な電子メール・アドレスとメール・サーバーを使用して更新します。この更新によって、リポジトリに障害が発生した場合、Enterprise Managerには追加の通知方法が用意されます。 emd.propertiesの設定方法については、「Grid Control」ホーム・ページの「Tip」セクションを参照してください。


� Enterprise Manager の HA アーキテクチャに対する推奨事項

� Enterprise Manager の計画外停止

Enterprise Manager のののの HA アーキテクチャに対する推奨事項アーキテクチャに対する推奨事項アーキテクチャに対する推奨事項アーキテクチャに対する推奨事項ここでは、次の推奨事項を説明します。

� リポジトリとプロセスの保護および監視対象の構成

� Management Repository の RAC インスタンスへの配置および Data Guard の使用

� 低 2 つの Management Service プロセスの構成とそのロード・バランシング

� HA システムと同じハードウェアでの Enterprise Manager のホスティング

� プロセスとエージェント間のネットワーク帯域幅の監視

リポジトリとプロセスの保護および監視対象の構成リポジトリとプロセスの保護および監視対象の構成リポジトリとプロセスの保護および監視対象の構成リポジトリとプロセスの保護および監視対象の構成可用性の要件は、Enterprise Manager スタックの各レイヤーで対処する必要があります。Enterprise Manager のリポジトリとプロセスに対する低の推奨事項は、Enterprise Manager による上レベルの可用性監視を備えたシステムと同じ保護レベルの構成内で、そのリポジトリとプロセスをホスティングすることです。Enterprise Manager アーキテクチャには、アプリケーション・アーキテクチャと同等の高い信頼性が必要です。監視フレームワークによる、できるかぎり効率的な問題の検出と修復の管理が重要です。Enterprise Manager の実装は、監視対象となるほとんどのアプリケーションの使用可能性と同程度に使用可能となるように設計する必要があります。これは、監視対象のアプリケーションで障害が発生した場合のアラートの生成には、この Enterprise Manager フレームワークが使用されるためです。



Management Repository のののの RAC インスタンスへの配置およびインスタンスへの配置およびインスタンスへの配置およびインスタンスへの配置および Data Guardの使用の使用の使用の使用Management Repository は、すべての Enterprise Manager 操作の基礎です。RAC と Data Guard 構成を使用しているシステムの監視とアラートでは Enterprise Manager システムが使用されていますが、Management Repository がシングル・インスタンスでのみホスティングされている場合は、その Enterprise Manager システムが停止すると、本番システムでの問題が管理者に適時に通知されない恐れがあります。個別のインスタンスの障害から保護するために Management Repository を RAC インスタンスに配置することを考慮し、サイトの障害から保護するために Data Guard を使用することを考慮してください。

低低低低 2 つのつのつのつの Management Service プロセスの構成とそのロード・バランシプロセスの構成とそのロード・バランシプロセスの構成とそのロード・バランシプロセスの構成とそのロード・バランシングングングング中間層の場合のベースライン推奨事項は、低 2 つの Management Service プロセスを指定することです。この指定には、個別の Management Service プロセスの位置と個別のコンポーネントの障害をマスキングするために、ハードウェアのサーバー・ロード・バランサを使用します。これによって、Enterprise Manager アーキテクチャのも重要なコンポーネントでの単一障害を迅速にカバーできます。Enterprise Manager を使用して監視しているすべてのシステムに対するサービスの中断はほとんどありません。ハードウェアのサーバー・ロード・バランサは、Enterprise Manager を使用して監視および構成することもでき、オペレーティング・システム・スタック全体をカバーします。Management Service は、Oracle Net を使用してリポジトリ・インスタンスへの接続を処理します。

HA システムと同じハードウェアでのシステムと同じハードウェアでのシステムと同じハードウェアでのシステムと同じハードウェアでの Enterprise Manager のホスティングのホスティングのホスティングのホスティングハードウェアのオーバーロードを削減して現在のリソースを利用するために、リポジトリとManagement Service のプロセスは、高い可用性を備えた他の本番システムと同じハードウェアでホスティングできます。これには、セカンダリ・サイトに、本番でのロードの他に、Enterprise Manager リポジトリと Management Service プロセスを処理するための容量と帯域幅があるという前提が必要です。ハードウェアのサービス・ロード・バランサは、個別の Management Service の障害を管理し、中間層全体にわたってワークロードのバランスをとるために、複数の Management Service プロセスに対するフロント・エンドとして使用する必要があります。

エージェントは、環境内にある監視対象ノードから任意の Management Service プロセスに接続できます。Management Service プロセスに接続しているエージェント・プロセスのロード・バランシングは、Enterprise Manager によって内部的に処理されます。



プロセスとエージェント間のネットワーク帯域幅の監視プロセスとエージェント間のネットワーク帯域幅の監視プロセスとエージェント間のネットワーク帯域幅の監視プロセスとエージェント間のネットワーク帯域幅の監視Management Service プロセスと Management Agent 間の通信をサポートするには十分なネットワーク帯域幅が必要です。大規模な企業の管理にリポジトリを使用する場合、複数のエージェントと複数の Management Service プロセス間の通信は、スケジュールされているイベントとジョブによっては、膨大になる可能性があります。Enterprise Manager フレームワークが複数のアプリケーションの監視に使用され、専用のシステム・リソースがさらに必要な場合は、追加のノードを使用して、Management Repository と Management Service のプロセスをスケール変更することを考慮してください。Management Repository とManagement Service のプロセスは、個別にスケール変更できます。必要な場合は、Management Service のプロセス数をスケール変更するために、ハードウェアをクラスタ外に追加できます。

Enterprise Manager の計画外停止の計画外停止の計画外停止の計画外停止Enterprise Manager は、使用しているデータ・センターを管理するための主要な制御インタフェースです。Enterprise Manager の停止は、DBA による包括的なシステム・パフォーマンスの管理を可能にするパフォーマンス・メトリックと可用性メトリックの重大な欠落の原因となります。表 8-6 を使用して、Enterprise Manager に関連する層で発生する可能性がある停止とその停止のリカバリ方法を説明します。

表表表表 8-6 Enterprise Manager の計画外停止の計画外停止の計画外停止の計画外停止

停止のタイプ停止のタイプ停止のタイプ停止のタイプ停止の原因停止の原因停止の原因停止の原因解決策または代替案解決策または代替案解決策または代替案解決策または代替案

Management Repositoryインスタンス障害

ハードウェア障害、Oracleデータベース障害、プライマリ・サイトにある RACインスタンスの単一ノードへのネットワーク障害、リスナー障害

この停止は、Management Repository の RAC 環境を使用す

ることでも効率よく管理されます。

RAC 環境では、接続は Oracle Net フェイルオーバーを使用

して 2 番目のノードに再接続されます。障害のあるノード

がリストアされると、ロードは自動的に再バランシングされます。

プライマリ・サイトの障害双方のノードへのネットワーク停止、クラスタ障害、インターコネクト障害、ハードウェア障害

セカンダリ・サイトへの Data Guard フェイルオーバーが必

要です。

� プライマリ・サイト・ノードでの Enterprise Manager通信量に対して構成したリスナーを停止します。

� Management Repository に対して Data Guard フェイル

オーバーを実行します。

� Enterprise Manager リスナーと Management Service プ

ロセスを新しい本番サイトで開始します。

注意注意注意注意 : この停止は、Enterprise Manager では直接管理でき

ません。10-11 ページの「SQL*Plus を使用した Data Guardフェイルオーバー」を参照してください。



Management Agent の障害

プロセス障害、ユーザーによる偶発的な停止

Management Agent の状態チェック・プロセスによって、

Management Agent が再起動されます。再起動の回数は、

監視対象のノードでの不要な処理を避けるために、ユーザーが構成できるパラメータによって制限されています。

状態チェックの障害プロセス障害、ユーザーによる偶発的な停止

データはレポートされません。Management Agent のロギ

ングは停止します。処理中のプロセスをすべて手動で停止し、Management Agent を再起動する必要があります。

注意注意注意注意 : 状態チェックの障害は、Enterprise Manager GUI にレポートされません。

システム状態データの削除または破損

エージェント障害、ユーザーによる状態ファイルの削除

実行中の Management Agent プロセス（EMAGENT とEMWD）を停止します。

そのプロセスを再起動（emctl start agent）します。

Management Service プロ

セスの障害


Oracle Process Manager and Notification Server（OPMN）

によって、Management Service が再起動されます。

複数の Management Service プロセスには、サーバー・ロー

ド・バランサ（SLB）を使用できます。これによって、プロ

セス障害がマスキングされ、ワークロードが中間層全体に分散されます。

Management Service に障害があると、その Management Service に接続している GUI セッションは失敗します。その

GUI セッションは、障害のない Management Service で再

開する必要があります。

Oracle Process Manager and Notification Server（OPMN）の障害


データはレポートされず、Management Service プロセスの

ロギングは停止します。処理中のプロセスを手動で停止し（UNIX プラットフォームの場合）、エージェントを再起動

する必要があります。

注意注意注意注意 : 状態チェックの停止は、Enterprise Manager GUI にレポートされません。

Grid Control 接続の切断ネットワークの問題が原因で Grid Control がManagement Service への

接続を失うと、Management Service また

はノードで障害が発生します。

Grid Control はステートレスであるため、データは

Management Service プロセスから受信します。この障害

は、障害のない Management Service に接続するか、Grid Control 自体を起動することで解決されます。

表表表表 8-6 Enterprise Manager の計画外停止（続き）の計画外停止（続き）の計画外停止（続き）の計画外停止（続き）

停止のタイプ停止のタイプ停止のタイプ停止のタイプ停止の原因停止の原因停止の原因停止の原因解決策または代替案解決策または代替案解決策または代替案解決策または代替案


Enterprise Manager の追加構成

Enterprise Manager の追加構成の追加構成の追加構成の追加構成この項では、MAA 環境で Enterprise Manager を構築する場合に役立つ追加の構成情報を説明します。内容は次のとおりです。

� Enterprise Manager に対する個別リスナーの構成

� 既存のデータベースへの Management Repository のインストール

Enterprise Manager に対する個別リスナーの構成に対する個別リスナーの構成に対する個別リスナーの構成に対する個別リスナーの構成Management Agent からの通信量は Management Service プロセスにルーティングされてから、Oracle Net によって Management Repository にルーティングされます。この通信量を他のアプリケーション通信量と区別し、必要に応じてサイト・フェイルオーバーで Data Guard をサポートするには、別のリスナーを使用して Enterprise Manager の通信量を構成する必要があります。このリスナーは、アクティブな Enterprise Manager インスタンスが実行されているノード上でのみアクティブです。GLOBAL_DBNAMEパラメータをlistener.oraファイルに設定しないでください。設定すると、透過的アプリケーション・フェイルオーバー（TAF）と接続時フェイルオーバーが使用できなくなります。LOCAL_LISTENER初期化パラメータと REMOTE_LISTENER初期化パラメータを構成して、動的なサービス登録と相互登録を有効にしてください。次に、リスナー構成の例を示します。

LISTENER_N1= (description_list= (description= (address_list= (address=(protocol=tcp)(port=1521)(host=EMPRIM1.us.oracle.com)) ) ) )SID_LIST_LISTENER_N1 = (SID_LIST = (SID_DESC = (ORACLE_HOME = /mnt/app/oracle/product/10g) (SID_NAME = EM1) ) )

LISTENER_DG= (description_list= (description= (address_list= (address=(protocol=tcp)(port=1529)(host=EMPRIM1.us.oracle.com)) ) ) )



既存のデータベースへの既存のデータベースへの既存のデータベースへの既存のデータベースへの Management Repository のインストールのインストールのインストールのインストールRAC ベースのリポジトリを構築する際にインストールの問題を回避する簡単な方法は、Enterprise Manager を既存のデータベースにインストールして、事前に表領域を構築しておくことです。Oracle Universal Installer の特定のバージョンでは、リポジトリの RAC データベースへのインストールを処理していません。初にデータベースを構築してから、インストール・オプションを使用して、既存のデータベースにインストールしてください。


停止からのリカ

9
停止からのリカバリ停止からのリカバリ停止からのリカバリ停止からのリカバリ
この章では、計画的停止と計画外停止、および各停止を管理して停止時間を小限に短縮できる Oracle のリカバリ処理とアーキテクチャ・フレームワークについて説明します。この章の内容は、次のとおりです。

� 計画外停止のリカバリ手順

� 計画的停止のリカバリ手順

バリ 9-1

計画外停止のリカバリ手順

計画外停止のリカバリ手順計画外停止のリカバリ手順計画外停止のリカバリ手順計画外停止のリカバリ手順計画外停止は、次のコンポーネントを含め、アプリケーションをサポートするテクノロジ・インフラストラクチャの一部に生じる思いがけない障害です。

� ホスト・マシン、ストレージ、スイッチ、ケーブルおよびカードなどのハードウェア

� オペレーティング・システム、Oracle データベースとアプリケーション・サーバーおよびアプリケーション・コードなどのソフトウェア

� ネットワーク・インフラストラクチャ

� ネーミング・サービス・インフラストラクチャ

� フロントエンド・ロード・バランサ

� 現行の本番サイト

監視および HA インフラストラクチャによって、障害からの迅速な検出およびリカバリを提供する必要があります。検出方法については、第 8 章「Oracle Enterprise Manager を使用した監視と検出」を参照してください。この章では、各停止に対するリカバリ操作に注目します。

表 9-1 は、プライマリまたはセカンダリ・サイトのコンポーネントに影響を与える計画外停止を示しています。

表表表表 9-1 計画外停止計画外停止計画外停止計画外停止

停止停止停止停止説明説明説明説明例例例例

サイト障害現行の本番データベースがあるサイト全体を使用できない状態です。ここにはアプリケーションのすべての層が含まれています。

� 火災、洪水または地震など、本番サイトの災害

� 停電（重要なシステムに対して複数の電力供給網とバックアップ用発電機を備えている場合は、一部のデータ・センターへの影響のみになります。）

ノード障害 RAC クラスタのノードを使用できない状

態、またはノードに障害が発生しています。

� メモリー不良または CPU 不良による

データベース層のノード障害または停止

� データベース層のノードに到達できない場合

� 双方の冗長クラスタ間接続に障害が発生した結果、別のノードが所有権を取得した場合

インスタンス障害データベース・インスタンスを使用できない状態、またはインスタンスに障害が発生しています。

ソフトウェアの不具合またはオペレーティング・システムやハードウェアの問題によってデータベース・サーバー上の RACデータベース・インスタンスに障害が発生した場合



クラスタ全体の障害 RAC データベースをホスティングするクラ

スタ全体を使用できない状態、またはクラスタ全体に障害が発生しています。これには、クラスタ内のノード障害のみでなく、結果的にクラスタを使用できなくなったり、サイト上の Oracle データベースおよびイン

スタンスを使用できなくなる他のコンポーネントの障害も含まれます。

� RAC クラスタ上で後まで正常に稼動

しているノードで障害が発生し、再起動できない場合

� 双方の冗長クラスタ間接続に障害が発生した場合

� 現行のデータ・サーバー上で連続的に拒否されるほど深刻なデータベースの破損

� ディスク・ストレージの障害

データ障害この障害は、メディアの破損、アクセス不可または非一貫性に起因してデータベースの一部が使用できなくなります。

� データファイルの偶発的な削除、またはデータファイルを使用できない場合

� データベースのブロックに影響を与えるメディア破損

� オペレーティング・システムまたはノードに関連する他の問題によるOracle ブロックの破損

ユーザー・エラーこの障害が発生すると、データベースの一部が使用できなくなり、トランザクションまたは論理データの非一貫性を引き起こします。通常は、オペレータまたはアプリケーション・コードの不具合に起因して発生します。

これは、停止時間のも大きな原因の 1 つ

と推測されます。

限定的な破損（正確な修復が必要）

� 表が削除された状態または表から行が削除された状態となるユーザー・エラー

広範囲な破損（停止時間を回避する抜本的な処置が必要）

� データベースが論理的に破損するアプリケーション・エラー

� バッチ・ジョブが指定回数を超えて実行される結果となるオペレータ・エラー

注意注意注意注意 : このカテゴリは、データベースの可

用性に影響を与え、特にトランザクションまたは論理データの非一貫性を引き起こすユーザー・エラーに注目しています。

表表表表 9-1 計画外停止計画外停止計画外停止計画外停止（続き）（続き）（続き）（続き）

停止停止停止停止説明説明説明説明例例例例

停止からのリカバリ 9-3


これ以降の項では、プライマリ・サイトおよびセカンダリ・サイトでの計画外停止について、停止判断表を提供します。判断表は、次の各項に記載されています。

� プライマリ・サイトでの計画外停止に対するリカバリ手順

� セカンダリ・サイトでの計画外停止に対するリカバリ手順

各停止に関する高水準のリカバリ手順が、各リカバリ手順の詳細な説明へのリンクとともにリストされています。これらの説明については、第 10 章「リカバリ手順の詳細」を参照してください。

一部の停止では、複数のリカバリ手順が必要です。たとえば、サイト障害が発生した場合は、停止判断マトリックスによるとサイト障害以前に必ず Data Guard 障害が発生することがわかります。一部の停止は、可用性を消失せずに自動的に処理されます。たとえば、インスタンス障害は RAC で自動的に管理されます。各停止について適切な場合は複数のリカバリ・オプションがリストされています。

プライマリ・サイトでの計画外停止に対するリカバリ手順プライマリ・サイトでの計画外停止に対するリカバリ手順プライマリ・サイトでの計画外停止に対するリカバリ手順プライマリ・サイトでの計画外停止に対するリカバリ手順プライマリ・サイトに本番データベースがあり、セカンダリ・サイトにスタンバイ・データベースがある場合、プライマリ・サイトでの停止はも重大な停止です。これらの停止に対するソリューションは、システムの大可用性のために不可欠です。サイト障害から保護するためにセカンダリ・サイトがあるのは、「Data Guard のみ」アーキテクチャと MAA アーキテクチャのみです。予測リカバリ時間（ERT）は顧客およびテストによる実際の経験値から導出された厳密な例であり、保証されているリカバリ時間には影響を与えません。

表 9-2 に、プライマリ・サイトでの計画外停止に対するリカバリ手順の概略を示します

表表表表 9-2 プライマリ・サイトでの計画外停止に対するリカバリ手順プライマリ・サイトでの計画外停止に対するリカバリ手順プライマリ・サイトでの計画外停止に対するリカバリ手順プライマリ・サイトでの計画外停止に対するリカバリ手順

停止の理由停止の理由停止の理由停止の理由

「データベースのみ」「データベースのみ」「データベースのみ」「データベースのみ」アーキテクチャのアーキテクチャのアーキテクチャのアーキテクチャのリカバリ手順リカバリ手順リカバリ手順リカバリ手順

「「「「RAC のみ」のみ」のみ」のみ」アーキテクチャのアーキテクチャのアーキテクチャのアーキテクチャのリカバリ手順リカバリ手順リカバリ手順リカバリ手順

「「「「Data Guard のみ」のみ」のみ」のみ」アーキテクチャのアーキテクチャのアーキテクチャのアーキテクチャのリカバリ手順リカバリ手順リカバリ手順リカバリ手順 MAA のリカバリ手順のリカバリ手順のリカバリ手順のリカバリ手順

サイト障害 ERT: 数時間から数日

1. サイトのリストア

2. テープ・バックアップからのリストア

3. データベースのリカバリ

ERT: 数時間から数日

1. サイトのリストア



ERT: 数分から 1 時間

1. データベース・フェイルオーバー

2. 全体または部分的なサイト・フェイルオーバー






ノード障害 ERT: 数分から 1 時間

1. ノードのリセットおよびデータベースの再起動

2. ユーザーの再接続

ERT: 数秒から数分

RAC リカバリによる

自動管理


1. ノードのリセットおよびデータベースの再起動


または






自動管理

インスタンス障害

ERT: 数分

1. インスタンスの再起動




自動管理

ERT: 数分

1. インスタンスの再起動




自動管理

クラスタ全体の障害

N/A ERT: 数時間から数日

1. クラスタのリストアまたは低 1 つ

のノードのリストア



N/A ERT: 数分から 1 時間



表表表表 9-2 プライマリ・サイトでの計画外停止に対するリカバリ手順（続き）プライマリ・サイトでの計画外停止に対するリカバリ手順（続き）プライマリ・サイトでの計画外停止に対するリカバリ手順（続き）プライマリ・サイトでの計画外停止に対するリカバリ手順（続き）







データ障害 ERT: 数分から 1 時間

データ障害に対するリカバリ・ソリューション





または




注意注意注意注意 : プライマリ・

データベースのメディア障害またはメディア破損については、データベース・フェイルオーバーによって、データの消失を小限に抑制できます。



または




注意注意注意注意 : プライマリ・

データベースのメディア障害またはメディア破損については、データベース・フェイルオーバーによって、データの消失を小限に抑制できます。

ユーザー・エラー

ERT: 数分

フラッシュバック・テクノロジによるユーザー・エラーからのリカバリ

ERT: 数分


ERT: 数分


ERT: 数分


表表表表 9-2 プライマリ・サイトでの計画外停止に対するリカバリ手順（続き）プライマリ・サイトでの計画外停止に対するリカバリ手順（続き）プライマリ・サイトでの計画外停止に対するリカバリ手順（続き）プライマリ・サイトでの計画外停止に対するリカバリ手順（続き）







セカンダリ・サイトでの計画外停止に対するリカバリ手順セカンダリ・サイトでの計画外停止に対するリカバリ手順セカンダリ・サイトでの計画外停止に対するリカバリ手順セカンダリ・サイトでの計画外停止に対するリカバリ手順スイッチオーバーまたはフェイルオーバーがないかぎり、クライアントは常にプライマリ・サイトにアクセスするため、セカンダリ・サイトでの停止は可用性に直接影響を与えません。プライマリ・サイトでも同時に障害が発生した場合は、セカンダリ・サイトの停止がMTTR に影響を与える可能性があります。ほとんどの場合は、可用性にまったく影響せずにセカンダリ・サイトでの停止を管理できます。ただし、大保護モードが構成の一部である場合は、正常に稼動している後のスタンバイ・データベースに計画外停止が発生すると、本番データベースに停止時間が生じます。この場合は、データ保護モードをダウングレード後、本番データベースを再起動できます。

表 9-3 に、セカンダリ・サイトでのスタンバイ・データベースの計画外停止に対するリカバリ手順の概略を示します。

表表表表 9-3 セカンダリ・サイトでのスタンバイ・データベースの計画外停止に対するリカバリ手順セカンダリ・サイトでのスタンバイ・データベースの計画外停止に対するリカバリ手順セカンダリ・サイトでのスタンバイ・データベースの計画外停止に対するリカバリ手順セカンダリ・サイトでのスタンバイ・データベースの計画外停止に対するリカバリ手順

停止の理由停止の理由停止の理由停止の理由「「「「Data Guard のみ」アーキテクチャのみ」アーキテクチャのみ」アーキテクチャのみ」アーキテクチャのリカバリ手順のリカバリ手順のリカバリ手順のリカバリ手順 MAA のリカバリ手順のリカバリ手順のリカバリ手順のリカバリ手順

スタンバイ適用のインスタンス障害 1. ノードおよびスタンバイ・インスタンスの再起動

2. リカバリの再起動

スタンバイ・データベースが 1 台の

みで、大データベース保護が構成されている場合は、スタンバイ・データベースとデータが乖離しないように本番データベースが停止します。

ERT: 数秒

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

本番データベースの Oracle Net 記述

子が、使用可能なスタンバイ・インスタンスへの接続時フェイルオーバーを使用するように構成されている場合は、本番データベースの可用性には影響ありません。

ノードおよびインスタンスの再起動（使用可能な場合）

スタンバイ非適用のインスタンス障害

N/A プライマリ・ノードまたはインスタンスが REDO ログを受け取ってリカ

バリ処理に適用するため、可用性には影響ありません。本番データベースは引き続きこのスタンバイ・データベースと通信します。

ノードおよびインスタンスの再起動（使用可能な場合）

メディア障害またはディスク破損などのデータ障害

手順 2: リカバリの起動手順 2: リカバリの起動

フラッシュバック操作またはメディア・リカバリのためのプライマリ・データベースによるログのリセット

本番データベースがリセットログをオープンした後のフォルト・トレランスのリストア



計画的停止のリカバリ手順

計画的停止のリカバリ手順計画的停止のリカバリ手順計画的停止のリカバリ手順計画的停止のリカバリ手順計画的停止は計画された停止です。計画的停止は、アプリケーションをサポートするテクノロジ・インフラストラクチャを定期的にメンテナンスするために必要です。これには、ハードウェアに対するメンテナンスや修復、アップグレード、ソフトウェアに対するアップグレードやパッチ、アプリケーションに対する変更やパッチ、およびシステムのパフォーマンスや管理性の改善などのタスクが含まれます。計画的停止は、継続的なアプリケーションの可用性にも適した時期にあわせて計画してください。

表 9-4 は、プライマリまたはセカンダリ・サイトのコンポーネントに影響を与える計画的停止を示しています。

表表表表 9-4 計画的停止計画的停止計画的停止計画的停止

停止の種類停止の種類停止の種類停止の種類説明説明説明説明例例例例

サイト全体現行の本番データベースがあるサイト全体を使用できない状態です。通常は、あらかじめ知られていて予定できます。

� 予定されている停電

� サイト・メンテナンス

� インフラストラクチャをテストするために定期的に計画されるスイッチオーバー

ハードウェア・メンテナンス（ノードに影響）

ハードウェア・メンテナンスのためのデータベース・サーバー・ノードに対する計画的停止時間です。この停止時間の範囲は、データベース・クラスタの単一のノードに制限されます。

� メモリー・カードまたは CPUボードなどの障害のあるコンポーネントの修復

� データベース層の既存のノードへのメモリーまたは CPU の追加

ハードウェア・メンテナンス（クラスタ全体に影響）

ハードウェア・メンテナンスのためのデータベース・サーバー・クラスタに対する計画的停止時間です。

� クラスタにノードを追加する場合

� クラスタ間接続のアップグレードまたは修復

� データベース層に対して停止時間が必要なストレージ層へのアップグレード

システム・ソフトウェア・メンテナンス（ノードに影響）

システム・ソフトウェア・メンテナンスのためのデータベース・サーバー・ノードに対する計画的停止時間です。停止時間の範囲は単一のノードに制限されます。

� オペレーティング・システムなどのソフトウェア・コンポーネントのアップグレード

� オペレーティング・システムの構成パラメータへの変更

システム・ソフトウェア・メンテナンス（クラスタ全体に影響）

システム・ソフトウェア・メンテナンスのためのデータベース・サーバー・クラスタに対する計画的停止時間です。

� クラスタ・ソフトウェアのアップグレードまたはパッチ

� ボリューム管理ソフトウェアのアップグレード



これ以降の項では、計画的停止について、停止判断表を提供します。判断表は、次の各項に記載されています。

� プライマリ・サイトでの計画的停止に対するリカバリ手順

� セカンダリ・サイトでの計画的停止に対するリカバリ手順

各停止に関する高水準のリカバリ手順が、各リカバリ手順の詳細な説明へのリンクとともにリストされています。リカバリ操作の詳細は、第 10 章「リカバリ手順の詳細」を参照してください。


� セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備

データベースに対するOracle パッチ・アップグレード

Oracle のパッチのための計画的停止

時間です。

顧客に固有の問題を修正するためのOracle ソフトウェアのパッチ

データベースに対するOracle パッチ・セットまたは

ソフトウェア・アップグレード

Oracle パッチ・セットまたはソフト

ウェア・アップグレードに対する計画的停止時間です。

� パッチ・セットによる Oracle ソ

フトウェアのパッチ

� Oracle ソフトウェアのアップグ

レード

データベース・オブジェクトの再編成

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

の論理構造または物理編成に対する変更です。これらの変更の主な理由は、パフォーマンスまたは管理性の改善です。したがって、常に計画されたアクティビティとなります。再編成を行うために選択する方法と時間は、計画的で適切であることが必要です。

Oracle のオンライン再編成機能を使

用すると、再編成中もオブジェクトを使用できます。

� 別の表領域へのオブジェクトの移動

� パーティション表への表の変換

� 表の列名の変更または列の削除

表表表表 9-4 計画的停止（続き）計画的停止（続き）計画的停止（続き）計画的停止（続き）

停止の種類停止の種類停止の種類停止の種類説明説明説明説明例例例例



プライマリ・サイトでの計画的停止に対するリカバリ手順プライマリ・サイトでの計画的停止に対するリカバリ手順プライマリ・サイトでの計画的停止に対するリカバリ手順プライマリ・サイトでの計画的停止に対するリカバリ手順プライマリ・サイトに本番データベースがあり、セカンダリ・サイトにスタンバイ・データベースがある場合、プライマリ・サイトでの停止はも重大な停止です。これらの停止に対するソリューションは、システムの継続的な可用性のために不可欠です。

表 9-5 に、プライマリ・サイトでの計画的停止に対するリカバリ手順を示します。

表表表表 9-5 プライマリ・サイトでの計画的停止に対するリカバリ手順プライマリ・サイトでの計画的停止に対するリカバリ手順プライマリ・サイトでの計画的停止に対するリカバリ手順プライマリ・サイトでの計画的停止に対するリカバリ手順

停止の範囲停止の範囲停止の範囲停止の範囲停止の理由停止の理由停止の理由停止の理由



「「「「Data Guard のみ」のみ」のみ」のみ」アーキテクチャのアーキテクチャのアーキテクチャのアーキテクチャのリカバリ手順リカバリ手順リカバリ手順リカバリ手順

MAA ののののリカバリ手順リカバリ手順リカバリ手順リカバリ手順

サイトサイトの停止全期間に対する停止時間

全期間に対する停止時間

1. データベース・スイッチオーバー




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

ハードウェア・メンテナンス（ノードに影響）


RAC リカバリに

よる自動管理



RAC リカバリに

よる自動管理


ハードウェア・メンテナンス（クラスタ全体に影響）








システム・ソフトウェア・メンテナンス（ノードに影響）


RAC リカバリに

よる自動管理



RAC リカバリに

よる自動管理



セカンダリ・サイトでの計画的停止に対するリカバリ手順セカンダリ・サイトでの計画的停止に対するリカバリ手順セカンダリ・サイトでの計画的停止に対するリカバリ手順セカンダリ・サイトでの計画的停止に対するリカバリ手順スイッチオーバーまたはフェイルオーバーがないかぎり、クライアントは常にプライマリ・サイトにアクセスするため、セカンダリ・サイトでの停止は可用性に影響を与えません。プライマリ・サイトでも同時に障害が発生した場合は、セカンダリ・サイトの停止が MTTRに影響を与える可能性があります。可用性にまったく影響せずにセカンダリ・サイトでの停止を管理できます。大保護のデータベース・モードが構成されている場合は、本番データベース上で停止時間が生じないように、スタンバイ・インスタンスまたはデータベースに対して計画的停止を開始する前に、保護モードをダウングレードしてください。

表 9-6 に、セカンダリ・サイトでの計画的停止に対するリカバリ手順を示します。


システム・ソフトウェア・メンテナンス（クラスタ全体に影響）








データベースに対する Oracleパッチ・アップグレード


RAC ローリング・

アップグレード


RAC ローリング・



データベースに対する Oracleパッチ・セットまたはソフトウェア・アップグレード



ロジカル・スタンバイ・データベースによるアップグレード



データベース・オブジェクトの再編成

オンラインでのオブジェクトの再編成




表表表表 9-5 プライマリ・サイトでの計画的停止に対するリカバリ手順（続き）プライマリ・サイトでの計画的停止に対するリカバリ手順（続き）プライマリ・サイトでの計画的停止に対するリカバリ手順（続き）プライマリ・サイトでの計画的停止に対するリカバリ手順（続き）




「「「「Data Guard のみ」のみ」のみ」のみ」アーキテクチャのアーキテクチャのアーキテクチャのアーキテクチャのリカバリ手順リカバリ手順リカバリ手順リカバリ手順

MAA ののののリカバリ手順リカバリ手順リカバリ手順リカバリ手順



表表表表 9-6 セカンダリ・サイトでの計画的停止に対するリカバリ手順セカンダリ・サイトでの計画的停止に対するリカバリ手順セカンダリ・サイトでの計画的停止に対するリカバリ手順セカンダリ・サイトでの計画的停止に対するリカバリ手順



サイトサイトの停止停止前 : 9-13 ページの「セ

カンダリ・サイトでのスケジューリングしたメンテナンスに対する準備」

停止後 : 11-14 ページの「セ

カンダリ・サイトまたはクラスタ全体の計画的停止の後で行うフォルト・トレランスのリストア」

停止前 : 9-13 ページの「セ




スタンバイ・データベース管理リカバリ・プロセス（MRP）を実行している

ノードでのハードウェアまたはソフトウェア・メンテナンス





スタンバイ・データベース MRP を実行していない

ノードでのハードウェアまたはソフトウェア・メンテナンス

N/A プライマリ・スタンバイ・ノードまたはインスタンスが管理リカバリ・プロセスで適用される REDO ログを

受け取るので影響はありません。

停止後 : ノードおよびイン

スタンスの再起動（使用可能な場合）

スタンバイ・データベースハードウェアまたはソフトウェア・メンテナンス（クラスタ全体に影響）

N/A 停止前 : 9-13 ページの「セ




スタンバイ・データベース Oracle パッチおよびソフト

ウェア・アップグレード

アップグレードには停止時間が必要ですが、大保護のデータベース・モードで構成されていないかぎり、プライマリ・ノードに対する影響はありません。

アップグレードには停止時間が必要ですが、大保護のデータベース・モードで構成されていないかぎり、プライマリ・ノードに対する影響はありません。



セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備セカンダリ・サイトでの計画的停止の間に継続してサービスを遂行するには、大保護モードを大可用性または大パフォーマンスにダウングレードします。セカンダリ・サイトのメンテナンスをスケジューリングする場合、サイト全体またはクラスタ全体の停止期間には、スタンバイ・データベースが本番データベースよりも遅れる時間、つまり、フォルト・トレランスをリストアするための時間を考慮してください。

表 9-7 に、セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備方法を示します。

表表表表 9-7 セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備

本番データベースの保護モード本番データベースの保護モード本番データベースの保護モード本番データベースの保護モード停止の理由停止の理由停止の理由停止の理由「「「「Data Guard のみ」アーキテクチャのみ」アーキテクチャのみ」アーキテクチャのみ」アーキテクチャおよびおよびおよびおよび MAA の準備手順の準備手順の準備手順の準備手順

大保護サイトの停止本番データの保護モードの大可用性または大パフォーマンスへの切替え

関連項目関連項目関連項目関連項目 : 7-25 ページの「データ保護

モードの変更」

大保護ハードウェア・メンテナンス（クラスタ全体に影響）

本番データの保護モードの大可用性または大パフォーマンスへの切替え



大保護ソフトウェア・メンテナンス（クラスタ全体に影響）




大保護プライマリ・ノード（リカバリ処理を実行しているノード）でのハードウェア・メンテナンス

適用インスタンス・フェイルオーバー（MAA のみ）

または


大保護プライマリ・ノード（リカバリ処理を実行しているノード）でのソフトウェア・メンテナンス


または




大可用性または大パフォーマンスサイトの停止なし（本番データベースへの影響なし）

大可用性または大パフォーマンスハードウェア・メンテナンス（クラスタ全体に影響）

なし（本番データベースへの影響なし）

大可用性または大パフォーマンスソフトウェア・メンテナンス（クラスタ全体に影響）


大可用性または大パフォーマンスプライマリ・ノード（リカバリ処理を実行しているノード）でのハードウェア・メンテナンス


または


大可用性または大パフォーマンスプライマリ・ノード（リカバリ処理を実行しているノード）でのソフトウェア・メンテナンス


または


表表表表 9-7 セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備（続き）セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備（続き）セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備（続き）セカンダリ・サイトでのスケジューリングしたメンテナンスに対する準備（続き）

本番データベースの保護モード本番データベースの保護モード本番データベースの保護モード本番データベースの保護モード停止の理由停止の理由停止の理由停止の理由「「「「Data Guard のみ」アーキテクチャのみ」アーキテクチャのみ」アーキテクチャのみ」アーキテクチャおよびおよびおよびおよび MAA の準備手順の準備手順の準備手順の準備手順


リカバリ手順

10
リカバリ手順の詳細リカバリ手順の詳細リカバリ手順の詳細リカバリ手順の詳細
この章では、第 9 章「停止からのリカバリ」に記載されている停止とそのソリューションの表で言及しているリカバリ操作の詳細について説明します。内容は次のとおりです。

� リカバリ操作の概略

� 全体または部分的なサイト・フェイルオーバー

� データベース・フェイルオーバー

� データベース・スイッチオーバー

� RAC リカバリ

� 適用インスタンス・フェイルオーバー

� データ障害に対するリカバリ・ソリューション

� フラッシュバック・テクノロジによるユーザー・エラーからのリカバリ

� RAC ローリング・アップグレード

� ロジカル・スタンバイ・データベースによるアップグレード

� オンラインでのオブジェクトの再編成

の詳細 10-1

リカバリ操作の概略

リカバリ操作の概略リカバリ操作の概略リカバリ操作の概略リカバリ操作の概略この章では、第 9 章「停止からのリカバリ」に記載されている停止とそのソリューションの表で言及しているリカバリ操作の詳細について説明します。表 10-1 に、この章で説明するリカバリ操作の概略を示します。

表表表表 10-1 リカバリ操作リカバリ操作リカバリ操作リカバリ操作

リカバリ操作リカバリ操作リカバリ操作リカバリ操作説明説明説明説明

全体または部分的なサイト・フェイルオーバー

全体のサイト・フェイルオーバーでは、既存の接続は失敗となり、新しい接続はセカンダリまたはフェイルオーバー・サイトにルーティングされます。この状態は、実際の災害時およびアプリケーション・スタックがレプリケートされる場合に発生します。

部分的なサイト・フェイルオーバーでは、プライマリ・サイトはそのままで、データベースがセカンダリ・サイトのスタンバイ・データベースにフェイルオーバーまたはスイッチオーバーした後に、中間層アプリケーションをリダイレクトする必要があります。この構成は、アプリケーション・サーバーとデータベース間の待ち時間が長いためにパフォーマンスが大幅に低下する場合は、お薦めできません。

データベース・フェイルオーバー

Data Guard フェイルオーバーは、計画外停止が発生したときにデータベース層で起動

されます。完全リカバリが試行された場合、データの消失は小限に抑制されるか、またはデータの消失はありません。その後は、全体または部分的なサイト・フェイルオーバーが発生します。データベースをフラッシュバックすることで、以前の本番データベースをスタンバイ・データベースに変換できます。

データベース・スイッチオーバー

Data Guard スイッチオーバーは、データベース層で発生します。以前の本番データ

ベースが新しいスタンバイ・データベースになり、以前のスタンバイ・データベースが新しい本番データベースになります。その後は、全体または部分的なサイト・フェイルオーバーが発生します。これはスケジューリングした停止または計画的停止です。

RAC リカバリ RAC は、バックエンド・データベースへの継続的なアクセスを提供するために、指定

されたサイトのインスタンス障害とノード障害を自動的に処理します。使用可能なインスタンスへの再接続はアプリケーションからは透過的で、プライマリ・サイトでのみ発生します。アプリケーション・サービスは、使用可能なインスタンスまたは指定のインスタンスに移行します。


スタンバイ・ノードでメンテナンスが必要な場合は、本番データベースへの影響を回避し、スタンバイ・リカバリが遅延しないようにするために、別のスタンバイ・インスタンスに切り替えることができます。スタンバイ・クラスタでのメンテナンスが必要な場合、またはスタンバイ・クラスタに障害が発生した場合は、大保護モードが有効なときは、本番データベースを大可用性モードまたは大パフォーマンス・モードにダウングレードする必要があります。

アプリケーション・フェイルオーバー

プライマリ・サイトでインスタンス障害またはノード障害が発生すると、クライアントまたはアプリケーション層は、障害のない 1 つ以上の RAC インスタンスに自動的に

フェイルオーバーします。

関連項目関連項目関連項目関連項目 : 7-44 ページの「高速アプリケーション・フェイルオーバーに関する推奨事

項」を参照してください。



全体または部分的なサイト・フェイルオーバー全体または部分的なサイト・フェイルオーバー全体または部分的なサイト・フェイルオーバー全体または部分的なサイト・フェイルオーバーこの項では、クライアント・フェイルオーバーに関する次の使用例について説明します。

� 全体のサイト・フェイルオーバー

� 部分的なサイト・フェイルオーバー : リモート・データベース・サーバーへの中間層アプリケーションの接続

全体のサイト・フェイルオーバーでは、既存の接続は失敗となり、新しい接続はセカンダリまたはフェイルオーバー・サイトにルーティングされます。この状態は、実際の災害時およびアプリケーション・スタックがレプリケートされる場合に発生します。

部分的なサイト・フェイルオーバーでは、プライマリ・サイトはそのままで、データベースがセカンダリ・サイトのスタンバイ・データベースにフェイルオーバーまたはスイッチオーバーした後に、中間層アプリケーションをリダイレクトする必要があります。この構成は、アプリケーション・サーバーとデータベース間の待ち時間が長いためにパフォーマンスが大幅に低下する場合は、お薦めできません。


メディアの劣化または破損が原因でデータ障害が発生した場合は、フラッシュ・リカバリ領域を使用するか、またはスタンバイ・データベースにスイッチオーバーする別のリカバリ・オプションを使用できます。あるいは、高速インポートまたはパラレルで索引を再作成することで、表を再作成できます。


ユーザー・エラーのためにトランザクション・データや論理データに矛盾が生じた場合は、エラー修正のフラッシュバック・テクノロジを行、トランザクション、表またはデータベースのレベルで使用して、問題を解決できます。

RAC ローリング・アップグ

レード

RAC では、1 度に 1 つのノードまたはインスタンスに、顧客固有の問題に対するパッ

チを段階的に適用できます。これによって、アプリケーションおよびデータベースの継続的な可用性が可能になります。


Data Guard では、スタンバイ・データベース上のデータベースをアップグレードし、

スイッチオーバーを実行でき、データベースに対するパッチ・セットの適用またはソフトウェア・アップグレードに要する計画停止時間全体が小限に短縮されます。


データ・サーバーに関連する計画的停止の多くは、データベース・オブジェクトの再編成に関係しています。オブジェクトの再編成は、データベースの継続的な可用性を維持しながら遂行する必要があります。Oracle オンラインでのオブジェクトの再編成

は、計画的停止の管理に使用されます。

表表表表 10-1 リカバリ操作リカバリ操作リカバリ操作リカバリ操作（続き）（続き）（続き）（続き）

リカバリ操作リカバリ操作リカバリ操作リカバリ操作説明説明説明説明

リカバリ手順の詳細 10-3


全体のサイト・フェイルオーバー全体のサイト・フェイルオーバー全体のサイト・フェイルオーバー全体のサイト・フェイルオーバープライマリとセカンダリのサイトには、サイト・フェイルオーバー機能を提供するために、広域トラフィック・マネージャが実装されています。この広域トラフィック・マネージャは、プライマリ・サイトまたはプライマリ・サイト上の特定のアプリケーションがアクセス可能でない場合、通信量を自動的にリダイレクトします。スイッチオーバーするためにセカンダリ・サイトへの切替えを手動でトリガーすることもできます。通信量がセカンダリ・サイトに送られるのは、停止のため、またはスイッチオーバー後であるために、プライマリ・サイトでサービスを提供できない場合のみです。プライマリ・サイトで障害が発生した場合、ユーザー通信量はセカンダリ・サイトに送られます。

図 10-1 に、サイト・フェイルオーバー前のネットワーク・ルーティングを示します。クライアント要求は、プライマリ・サイトのクライアント層に入り、WAN トラフィック・マネージャによって移動します。アプリケーション・サーバー層に対するクライアント要求は、ファイアウォールを介して非武装地帯（DMZ）に送信されます。次に、要求はアクティブなロード・バランサを介してアプリケーション・サーバーに転送されます。要求はその後、別のファイアウォールを介して、データベース・サーバー層に送信されます。アプリケーション要求は、必要に応じて RAC インスタンスにルーティングされます。応答は、同様の経路でアプリケーションおよびクライアントに返信されます。



図図図図 10-1 サイト・フェイルオーバー前のネットワーク・ルーティングサイト・フェイルオーバー前のネットワーク・ルーティングサイト・フェイルオーバー前のネットワーク・ルーティングサイト・フェイルオーバー前のネットワーク・ルーティング



図 10-2 に、サイト・フェイルオーバー後のネットワーク・ルーティングを示します。クライアント要求またはアプリケーション要求は、セカンダリ・サイトのクライアント層に入り、プライマリ・サイトの場合と同一の経路でセカンダリ・サイトを移動します。

図図図図 10-2 サイト・フェイルオーバー後のネットワーク・ルーティングサイト・フェイルオーバー後のネットワーク・ルーティングサイト・フェイルオーバー後のネットワーク・ルーティングサイト・フェイルオーバー後のネットワーク・ルーティング



次の手順は、フェイルオーバーまたはスイッチオーバー時のネットワーク通信量の処理を示しています。

1. 管理者が、本番データベースをセカンダリ・サイトにフェイルオーバーまたはスイッチオーバーしました。

2. 管理者は、セカンダリ・サイトの中間層アプリケーション・サーバーを起動します。

3. 通常、ドメイン・ネーム・サービス（DNS）管理者は、セカンダリ・サイトの広域トラフィック・マネージャの選択を変更します。この選択は、サイト全体の障害に対して自動的に行うこともできます。セカンダリ・サイトの広域トラフィック・マネージャは、セカンダリ・サイトにあるロード・バランサの仮想 IP アドレスを返します。この場合、サイト・フェイルオーバーは DNS フェイルオーバーによって遂行されます。次に、手動による DNS フェイルオーバーの例を示します。

a. セカンダリ・サイトのロード・バランサを指すように DNS を変更します。

b. DNS 伝播の TTL（Time to Live）を短い間隔に設定します。

c. プライマリ・サイトの DNS を無効にします。

d. セカンダリ・サイトを指すように DNS プッシュを実行します。

e. すべてのフェイルオーバー操作が完了するまで待機します。

f. DNS サーバーの TTL を通常の設定に戻します。

g. セカンダリ・サイトのロード・バランサが、セカンダリ・サイトの中間層アプリケーション・サーバーに通信量を送ります。

h. セカンダリ・サイトでは、クライアント要求を取得する準備が整いました。

フェイルオーバーは、クライアントの Web ブラウザにも依存します。ほとんどのブラウザ・アプリケーションは、DNS エントリを一定の期間キャッシュします。したがって、停止時に進行しているセッションは、キャッシュのタイムアウトが失効するまでフェイルオーバーしません。このようなクライアントに対してサービスを再開する唯一の方法は、ブラウザを閉じてから再起動することです。



部分的なサイト・フェイルオーバー部分的なサイト・フェイルオーバー部分的なサイト・フェイルオーバー部分的なサイト・フェイルオーバー : リモート・データベース・サーバーリモート・データベース・サーバーリモート・データベース・サーバーリモート・データベース・サーバーへの中間層アプリケーションの接続への中間層アプリケーションの接続への中間層アプリケーションの接続への中間層アプリケーションの接続

通常、このフェイルオーバーはデータベースがセカンダリ・サイトにフェイルオーバーまたはスイッチオーバーした後、中間層アプリケーションがプライマリ・サイト上に残っている場合に発生します。次の手順は、部分的なサイト・フェイルオーバー時のネットワーク通信量の処理を示しています。

1. 本番データベースは、セカンダリ・サイトにフェイルオーバーまたはスイッチオーバーされます。

2. 7-44 ページの「高速アプリケーション・フェイルオーバーに関する推奨事項」で説明されている構成上のベスト・プラクティスを使用して、中間層アプリケーション・サーバーがセカンダリ・サイトのデータベースに再接続します。

図 10-3 に、部分的なサイト・フェイルオーバー後のネットワーク・ルーティングを示します。クライアント要求とアプリケーション要求は、クライアント層のプライマリ・サイトに入り、図 10-1 と同じようにデータベース・サーバー層への経路をたどります。データベース・サーバー層に入った要求は、追加のスイッチ、ルーターおよび可能なファイアウォールを介して、セカンダリ・サイトのデータベース層にルーティングされます。



図図図図 10-3 部分的なサイト・フェイルオーバー後のネットワーク・ルーティング部分的なサイト・フェイルオーバー後のネットワーク・ルーティング部分的なサイト・フェイルオーバー後のネットワーク・ルーティング部分的なサイト・フェイルオーバー後のネットワーク・ルーティング



データベース・フェイルオーバーデータベース・フェイルオーバーデータベース・フェイルオーバーデータベース・フェイルオーバーフェイルオーバーとは、あるサイトの本番データベースをオフラインにして、スタンバイ・データベースの 1 つを新しい本番データベースとしてオンラインにする操作です。フェイルオーバー操作は、本番データベースで計画外の致命的な障害が発生し、その本番データベースをタイムリな方法でリカバリできない場合に起動できます。

Data Guard では、次の各項で説明する SQL 文を発行し、Oracle Enterprise Manager またはOracle Data Guard Broker コマンドライン・インタフェースを使用して、フェイルオーバーできます。

Data Guard フェイルオーバーは、スタンバイ・データベースを本番データベースに変換するための一連の手順です。スタンバイ・データベースは、基本的に本番のロールを引き受けます。Data Guard フェイルオーバーには、ユーザーを新しいサイトとデータベースにフェイルオーバーするためのサイト・フェイルオーバーが付随しています。フェイルオーバーした後は、セカンダリ・サイトに本番データベースが含まれます。以前の本番データベースは、レジリエンスをリストアするために新しいスタンバイ・データベースとして再作成する必要があります。フラッシュバック・データベースを使用すると、スタンバイ・データベースを迅速に再作成できます。11-10 ページの「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。

フェイルオーバー操作時のデータ消失はほとんど、またはまったくありません。フェイルオーバーの詳細は、『Oracle Data Guard 概要および管理』を参照してください。


� Data Guard フェイルオーバーを使用する場合

� Data Guard フェイルオーバーを使用しない場合

� SQL*Plus を使用した Data Guard フェイルオーバー

関連項目関連項目関連項目関連項目 : データベースのフェイルオーバーに対して Enterprise Manager または Data Guard Broker コマンドラインを使用する方法は、

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



Data Guard フェイルオーバーを使用する場合フェイルオーバーを使用する場合フェイルオーバーを使用する場合フェイルオーバーを使用する場合Data Guard フェイルオーバーが使用されるのは緊急時のみで、次のような計画外停止によって開始されます。

� サイト障害

� ユーザー・エラー

� データ障害

フェイルオーバーでは、使用している環境にフォルト・トレランスをリストアするために、当初の本番データベースをスタンバイ・データベースとして再作成する必要があります。フラッシュバック・データベースを使用すると、スタンバイ・データベースを迅速に再作成できます。11-10 ページページページページの「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。

Data Guard フェイルオーバーを使用しない場合フェイルオーバーを使用しない場合フェイルオーバーを使用しない場合フェイルオーバーを使用しない場合タイムリな方法で問題をローカルで解決できる場合、または Data Guard スイッチオーバーを使用できる場合は、Data Guard フェイルオーバーを使用しないでください。完全リカバリでフェイルオーバーすると、本番データベースはアクセス不可または再開できなくなります。オブジェクト・リカバリまたはフラッシュバック・テクノロジのソリューションによって迅速で効率的な代替が提供される場合は、Data Guard フェイルオーバーを使用しないでください。

SQL*Plus を使用したを使用したを使用したを使用した Data Guard フェイルオーバーフェイルオーバーフェイルオーバーフェイルオーバーこの項の内容は、次のとおりです。

� SQL*Plus を使用したフィジカル・スタンバイ・フェイルオーバー

� SQL*Plus を使用したロジカル・スタンバイ・フェイルオーバー

SQL*Plus を使用したフィジカル・スタンバイ・フェイルオーバーを使用したフィジカル・スタンバイ・フェイルオーバーを使用したフィジカル・スタンバイ・フェイルオーバーを使用したフィジカル・スタンバイ・フェイルオーバー1. アーカイブ・ギャップをチェックします。

SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

2. 他のスタンバイ・インスタンスを停止します。

3. リカバリを終了します。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

関連項目関連項目関連項目関連項目 : ギャップが存在する場合の処理方法については、『Oracle Data Guard 概要および管理』を参照してください。



4. データベースの状態をチェックします。次の文を実行して、スイッチオーバー・ステータスを問い合せます。

SELECT SWITCHOVER_STATUS FROM V$DATABASE;

5. フィジカル・スタンバイ・データベースを本番ロールに変換します。

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

6. インスタンスを再起動します。

SQL*Plus を使用したロジカル・スタンバイ・フェイルオーバーを使用したロジカル・スタンバイ・フェイルオーバーを使用したロジカル・スタンバイ・フェイルオーバーを使用したロジカル・スタンバイ・フェイルオーバー1. 現行の SQL Apply セッションを停止します。

ALTER DATABASE STOP LOGICAL STANDBY APPLY;

2. 登録する追加ログがある場合（たとえば、プライマリ・データベースにアクセスできる場合、またはスタンバイ先に LGWR を使用している場合）は、そのログ・ファイルを登録します。

ALTER DATABASE REGISTER LOGICAL LOGFILE 'file_name';

3. NODELAY句と FINISH句を使用して、SQL Apply セッションを開始します。

ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY FINISH;

4. ロジカル・スタンバイ・データベースをアクティブにします。

ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE;

フェイルオーバーが完了し、新しい本番データベースでトランザクションを処理できるようになります。



データベース・スイッチオーバーデータベース・スイッチオーバーデータベース・スイッチオーバーデータベース・スイッチオーバーOracle Data Guard で実行されるデータベース・スイッチオーバーは計画的なトランジションで、スタンバイ・データベースと本番データベース間でロールを切り替える一連の手順が含まれています。したがって、スイッチオーバー操作が正常に完了すると、スタンバイ・データベースが本番ロールを引き受け、本番データベースがスタンバイ・データベースになります。RAC 環境でのスイッチオーバーでは、本番とスタンバイの各データベースに対して、アクティブなインスタンスが 1 つのみ必要です。スイッチバックという用語は、データベース・ロール管理の分野でもしばしば使用されます。スイッチバック操作とは、ロールをオリジナルの状態に戻すために続いて行うスイッチオーバー操作です。

Data Guard では、次の各項で説明する SQL 文を発行するか、Oracle Enterprise Manager または Oracle Data Guard Broker コマンドライン・インタフェースを使用して、これらのロールを動的に変更できます。 Oracle Enterprise Manager または Oracle Data Guard Broker コマンドライン・インタフェースの使用方法は、『Oracle Data Guard Broker』を参照してください。


� Data Guard スイッチオーバーを使用する場合

� Data Guard スイッチオーバーを使用しない場合

� SQL*Plus を使用した Data Guard スイッチオーバー

Data Guard スイッチオーバーを使用する場合スイッチオーバーを使用する場合スイッチオーバーを使用する場合スイッチオーバーを使用する場合スイッチオーバーは計画的な操作です。スイッチオーバーとは、データベースをインスタンス化しないで、本番データベースとスタンバイ・データベース間のデータベース・ロールを切り替える機能です。スイッチオーバーは、本番データベースが起動していて、ターゲットのスタンバイ・データベースとすべてのアーカイブ REDO ログが使用可能な場合はいつでも実行できます。スイッチオーバーは次の場合に有用です。

� 本番ホストでのハードウェア・メンテナンス（たとえば、ハードウェアやファームウェアのパッチ）など、計画的なメンテナンス

� 本番データベースがオープン状態でのデータ障害の解決

� 障害リカバリ準備状況をテストする手段としてのセカンダリ・リソースのテストと検証

� データベース・ソフトウェアとパッチ・セットのアップグレード。10-51 ページの「ロジカル・スタンバイ・データベースによるアップグレード」を参照してください。



Data Guard スイッチオーバーを使用しない場合スイッチオーバーを使用しない場合スイッチオーバーを使用しない場合スイッチオーバーを使用しない場合スイッチオーバーは、次の状況では使用できないか、効果的ではありません。

� アーカイブ REDO ログがない場合

� Point-in-Time リカバリが必要な場合

� 本番データベースがオープン状態ではなく、またオープンできない場合

Data Guard スイッチオーバーは、ローカルのリカバリ・ソリューションに迅速で効率的な代替がある場合は使用しないでください。スイッチオーバーの詳細は、『Oracle Data Guard概要および管理』を参照してください。

SQL*Plus を使用したを使用したを使用したを使用した Data Guard スイッチオーバースイッチオーバースイッチオーバースイッチオーバーOracle Enterprise Manager を使用していない場合、この項に記載されている高水準の手順は、SQL*Plus を使用して実行できます。これらの手順の詳細は、『Oracle Data Guard 概要および管理』を参照してください。


� SQL*Plus を使用したフィジカル・スタンバイ・スイッチオーバー

� SQL*Plus を使用したロジカル・スタンバイ・スイッチオーバー

SQL*Plus を使用したフィジカル・スタンバイ・スイッチオーバーを使用したフィジカル・スタンバイ・スイッチオーバーを使用したフィジカル・スタンバイ・スイッチオーバーを使用したフィジカル・スタンバイ・スイッチオーバー1. 各サイトの 1 つを除いて、本番インスタンスとスタンバイ・インスタンスのすべてを停

止します。

2. 残りのアクティブな本番インスタンスにあるアクティブ・セッションを停止します。

アクティブ・セッションを識別するには、次の問合せを実行します。

SELECT SID, PROCESS, PROGRAM FROM V$SESSION WHERE TYPE = 'USER' AND SID <> (SELECT DISTINCT SID FROM V$MYSTAT);

3. 本番データベースのスイッチオーバー・ステータスが 'TO STANDBY'であることをチェックします。

SELECT SWITCHOVER_STATUS FROM V$DATABASE;

4. 現行の本番データベースをスタンバイ・データベースにスイッチオーバーします。

ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY [WITH SESSION SHUTDOWN];



5. 新しいスタンバイ・データベースを起動します。

STARTUP MOUNT;RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

6. 以前のスタンバイ・データベースを本番データベースに変換します。

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY [WITH SESSION SHUTDOWN];

7. すべてのインスタンスを再起動します。

SQL*Plus を使用したロジカル・スタンバイ・スイッチオーバーを使用したロジカル・スタンバイ・スイッチオーバーを使用したロジカル・スタンバイ・スイッチオーバーを使用したロジカル・スタンバイ・スイッチオーバー1. ロジカル・スタンバイ・データベースになるように本番データベースを準備します。

ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;

2. 本番データベースになるようにロジカル・スタンバイ・データベースを準備します。

現行の本番データベースは現行のロジカル・スタンバイ・データベースからのログを処理しませんが、この手順以降は、ログが両方に送信されるようになります。

ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;

3. ロジカル・スタンバイ・データベースになるように本番データベースをコミットします。

このフェーズで、本番データベース上の現行のトランザクションが取り消されます。DML に関連するすべてのカーソルは、新しいレコードが適用されないように無効になります。REDO の終了（EOR）マーカーがオンライン REDO ログに記録され、その後

（リアルタイム適用を使用している場合はただちに）、ロジカル・スタンバイ・データベースに送信され、登録されます。

ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;

4. 本番データベースになるようにロジカル・スタンバイ・データベースをコミットします。

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

5. 新しいロジカル・スタンバイ・データベース上のロジカル・スタンバイ適用エンジンを起動します。

リアルタイム適用が必要な場合は、次の文を実行します。


それ以外の場合は、次の文を実行します。

ALTER DATABASE START LOGICAL STANDBY APPLY;


RAC リカバリ

RAC リカバリリカバリリカバリリカバリこの項の内容は、次のとおりです。

� 計画外停止の RAC リカバリ

� 計画的停止の RAC リカバリ

計画外停止の計画外停止の計画外停止の計画外停止の RAC リカバリリカバリリカバリリカバリこの項の内容は、次のとおりです。

� 障害のあるインスタンスの自動インスタンス・リカバリ

� サービスの自動再配置

障害のあるインスタンスの自動インスタンス・リカバリ障害のあるインスタンスの自動インスタンス・リカバリ障害のあるインスタンスの自動インスタンス・リカバリ障害のあるインスタンスの自動インスタンス・リカバリインスタンス障害は、ソフトウェアやハードウェアの問題でインスタンスを使用できない場合に発生します。インスタンス障害が発生すると、Oracle は自動的にオンライン REDO ログを使用して、この項の説明のようにデータベース・リカバリを実行します。

Real Application Clusters での単一ノード障害での単一ノード障害での単一ノード障害での単一ノード障害 RAC のインスタンス・リカバリでは、障害のあるインスタンスの再起動や障害のあるインスタンスで実行されていたアプリケーションのリカバリは行われません。実行していたアプリケーションを障害認識とリカバリを使用して続行する方法は、『Oracle Real Application Clusters インストレーションおよび構成』を参照してください。これによって、ハードウェアやソフトウェア障害の場合にも一貫性のある連続したサービスが提供されます。あるインスタンスが別のインスタンスのリカバリを実行する場合、正常に機能しているインスタンスは、障害のあるインスタンスで生成された REDOログ・エントリを読み取り、その情報を使用してコミットされたトランザクションがデータベースに確実に記録されるようにします。したがって、コミットされたトランザクションのデータ消失はありません。リカバリを実行しているインスタンスは、障害時にアクティブであったコミットされていないトランザクションをロールバックして、そのトランザクションが使用していたリソースを解放します。

Real Application Clusters での複数ノード障害での複数ノード障害での複数ノード障害での複数ノード障害複数ノード障害が発生した場合、RAC では、1つのインスタンスが正常に稼働しているかぎり、障害のある他のインスタンスに対してインスタンス・リカバリが実行されます。RAC データベースのすべてのインスタンスに障害が発生した場合、Oracle では、次回、あるインスタンスがデータベースをオープンするときに、それらのインスタンスが自動的にリカバリされます。リカバリを実行しているインスタンスは、RAC データベースのノードから共有モードまたは排他モードでデータベースをマウントできます。このリカバリ手続きは、1 つのインスタンスが、排他的なノードで障害が発生したすべてのインスタンスに対してインスタンス・リカバリを実行すること以外は、排他モードで実行している Oracle の場合と、共有モードで実行している Oracle の場合で同じです。


RAC リカバリ

サービスの自動再配置サービスの自動再配置サービスの自動再配置サービスの自動再配置サービスの信頼性は、冗長性のある複数インスタンスの構成とそのインスタンスへのフェイルオーバーによって達成されます。必要と思われる数より多いインスタンスが、サービスを提供するために使用されます。ハードウェア障害が発生し、RAC データベース・インスタンスに悪影響を与える場合、RAC は、そのインスタンスのすべてのサービスを、使用可能な別のインスタンスに自動的に移動します。次に、Cluster Ready Services（CRS）が障害のあるノードとインスタンスの再起動を試みます。

各サービスに対する優先的な構成および使用可能な構成は、インストール時に指定できます。この構成は、システムの優先的な実行方法を示し、サービスの初の起動時に使用されます。たとえば、システムの初の起動時点で、ERPサービスは instance1とinstance2で実行され、HRサービスは instance3で実行されます。障害による停止または計画的停止の場合、instance2は HRの実行に使用でき、instance3と instance4はERPの実行に使用できます。サービスの構成を設計するには、いくつかの方法があります。

RAC は、障害がサービスに影響を与えている状況を認識し、そのサービスを自動的にフェイルオーバーして、サービスをサポートしているインスタンスの中で正常に機能しているインスタンスにクライアントを再配置します。これと並行して、CRS は、障害のあるインスタンスの再起動、およびシステムへの依存リソースの統合を試みます。障害の通知は、Enterprise Manager とコールアウトを使用した外部パーティの通知、追跡、イベント・ログおよびアプリケーションの中断に関する障害の記録など、様々なレベルで発生します。障害のあるドメインが休止している場合、通知は正常に機能しているデフォルト・ドメインから発行されます。サービスを処理しているデフォルト・ドメインの位置と数は、アプリケーションに対しては透過的です。自動再起動とリカバリは、データベースのみではなく、すべてのサブシステムを含めて自動的に実行されます。

計画的停止の計画的停止の計画的停止の計画的停止の RAC リカバリリカバリリカバリリカバリこの項の内容は、次のとおりです。

� CRS 管理リソースの無効化

� 計画的なサービスの再配置

CRS 管理リソースの無効化管理リソースの無効化管理リソースの無効化管理リソースの無効化停止が発生すると、RAC は基本的なコンポーネントを自動的に再起動します。自動再起動に適格なコンポーネントには、いくつかのサブコンポーネントに加え、インスタンス、リスナー、およびデータベースが含まれます。スケジュールされた一部の管理タスクでは、コンポーネントが自動的に再起動されないようにする必要があります。操作中に CRS 管理コンポーネントの停止が必要な計画的なメンテナンスを実行するには、CRS がコンポーネントを自動的に再起動しないように、リソースを無効にする必要があります。たとえば、メンテナンスのために、ノードおよびそのインスタンスとサービスすべてをオフラインで取得するには、Enterprise Manager または SRVCTLを使用して、インスタンスとそのサービスを無効にしてから、必要なメンテナンスを実行します。無効にしないと、ノード障害が発生して再起動された場合、管理操作中に CRS によってインスタンスの再起動が試行されます。


RAC リカバリ

計画的なサービスの再配置計画的なサービスの再配置計画的なサービスの再配置計画的なサービスの再配置インスタンス、ノードまたは他のコンポーネントを分離する必要がある計画的停止に対して、RAC には、サービスを再配置、無効および有効にする機能が用意されています。再配置によって、サービスは別のインスタンスに移行されます。セッションも再配置可能です。これらのインタフェースを使用すると、修復、変更またはアップグレード中は、サービス、インスタンスおよびデータベースを選択的に無効にし、変更後に再度有効にもできます。これによって、依存性またはサービスの起動操作のために、修復中のインスタンスでサービスが起動されることはなくなります。サービスは、計画的停止が開始されると、そのインスタンスで無効になります。サービスは、メンテナンスによる停止の終了時に有効になります。

たとえば、node1で計画的なメンテナンスを実行するために SALESサービスをinstance1から instance3に再配置するには、Enterprise Manager または SRVCTLコマンドを使用してそのタスクを実行できます。次に、SRVCTLコマンドの使用方法を示します。

1. SALESサービスを instance3に再配置します。

srvctl relocate service -d PROD -s SALES -i instance1 -t instance3

2. instance1での SALESサービスを無効にして、メンテナンスの実行中にサービスがinstance1に再配置されないようにします。

srvctl disable service -d PROD -s SALES -i instance1

3. instance1を停止します。

srvctl stop instance -d PROD -i instance1

4. 計画的なメンテナンスを実行します。

5. instance1を起動します。

srvctl start instance -D PROD -i instance1

6. instance1で SALESサービスを再度有効にします。

srvctl enable service -d PROD -s SALES -i instance1

7. 必要な場合は、instance3で実行している SALESサービスを instance1に戻します。

srvctl relocate service -d PROD -s SALES -i instance3 -t instance1




適用インスタンス・フェイルオーバー適用インスタンス・フェイルオーバー適用インスタンス・フェイルオーバー適用インスタンス・フェイルオーバーこの項の内容は、各サイトで RAC および Data Guard を使用している MAA に適用されます。

1 つのスタンバイ・データベースに、複数のスタンバイ・インスタンスを指定できます。1つのインスタンスのみが管理リカバリ・プロセス（MRP）またはロジカル・スタンバイ適用プロセス（LSP）を指定できます。MRP または LSP を持つインスタンスは適用インスタンスと呼ばれます。

RAC 対応のスタンバイ・データベースがある場合は、スタンバイ RAC 環境の適用インスタンスをフェイルオーバーできます。適用インスタンスまたはノードに影響を与える計画的停止または計画外停止が発生している場合は、別の適用インスタンスへのフェイルオーバーが必要です。セカンダリ・サイトにあるスタンバイ・データベースの複数のインスタンスを利用する適用インスタンス・フェイルオーバーと、スタンバイ・データベースを本番データベースに変換する Data Guard フェイルオーバーまたは Data Guard スイッチオーバーとの相違に注意してください。適用インスタンス・フェイルオーバーの結果は、次のようになります。

� 適用ホストがメンテナンス中または障害に直面している場合でもスタンバイ・リカバリを続行できます。スタンバイ・リカバリを中断しないことで、許容 MTTR 内で Data Guard フェイルオーバーまたはスイッチオーバーを完了できます。

� 後続のネットワーク接続は別の適用インスタンスに切り替わるため、本番データベースは中断せず、大保護モードを使用している場合でも本番データベースの停止時間を回避できます。

適用フェイルオーバーが正しく機能するには、7-34 ページの「MAA に関する構成上のベスト・プラクティス」に従う必要があります。

� 複数のスタンバイ・インスタンスの構成

� ネットワーク・サービスの記述子に対する接続時フェイルオーバーの構成

これらの構成推奨事項に従うと、プライマリ・インスタンスでの計画的停止または計画外停止では適用インスタンス・フェイルオーバーが自動的に実行され、アーカイブ REDO ログへのアクセス権がすべてのスタンバイ・インスタンスに付与されます。定義によって、すべての RAC スタンバイ・インスタンスは共有ストレージに常駐している必要があるため、これらのインスタンスにはあらかじめスタンバイ REDO ログへのアクセス権があります。

フィジカル・スタンバイの管理リカバリ・プロセス（MRP）またはロジカル・スタンバイ適用プロセス（LSP）を再起動する方法は、Data Guard Broker を使用しているかどうかで異なります。Data Guard Broker が使用されている場合は、プライマリ・スタンバイ・インスタンスに障害が発生すると、初に使用可能なスタンバイ・インスタンスで、MRP またはLSP が自動的に再起動されます。Data Guard Broker が使用されていない場合は、新しいスタンバイ・インスタンスで、MRP または LSP を手動で再起動する必要があります。アーカイブ REDO ログについては、クラスタ・ファイル・システムやグローバル・ファイル・システムなどの共有ファイル・システムの使用を考慮します。共有ファイル・システムでは、



スタンバイにすでに送信されて適用されていないアーカイブ REDO ログの再送信を回避できます。

SQL*Plus を使用した適用インスタンス・フェイルオーバーの実行を使用した適用インスタンス・フェイルオーバーの実行を使用した適用インスタンス・フェイルオーバーの実行を使用した適用インスタンス・フェイルオーバーの実行適用インスタンス・フェイルオーバーが自動的に発生しない場合は、次の手順に従って本番データベースを再起動し、必要な場合は、計画外の適用インスタンスまたはノード停止の後に MRP または LSP を再起動します。

� 手順 1: 選択されたスタンバイ・インスタンスのマウントの確認

� 手順 2: 選択されたスタンバイ・ホストへの Oracle Net 接続の検証

� 手順 3: 選択されたスタンバイ・インスタンスでのリカバリの開始

� 手順 4: 新しい適用ホストへのアーカイブ REDO ログのコピー

� 手順 5: 新しい構成の検証

手順手順手順手順 1: 選択されたスタンバイ・インスタンスのマウントの確認選択されたスタンバイ・インスタンスのマウントの確認選択されたスタンバイ・インスタンスのマウントの確認選択されたスタンバイ・インスタンスのマウントの確認ターゲット・スタンバイ・インスタンスから次の問合せを実行します。

SELECT OPEN_MODE, DATABASE_ROLE FROM V$DATABASE;

手順手順手順手順 2: 選択されたスタンバイ・ホストへの選択されたスタンバイ・ホストへの選択されたスタンバイ・ホストへの選択されたスタンバイ・ホストへの Oracle Net 接続の検証接続の検証接続の検証接続の検証1. スタンバイ・リスナーが起動していることを確認します。

% lsnrctl status listener_name

2. クラスタ内のすべての本番ホストから Oracle Net 別名を確認します。

% tnsping standby_database_connection_service_name

接続できない場合のトラブルシューティングの詳細は、『Oracle Net Services 管理者ガイド』を参照してください。

関連項目関連項目関連項目関連項目 : インスタンス間アーカイブの設定方法は、『Oracle Data Guard 概要および管理』を参照してください。

スタンバイ・データベースのタイプスタンバイ・データベースのタイプスタンバイ・データベースのタイプスタンバイ・データベースのタイプスタンバイ・データベースのスタンバイ・データベースのスタンバイ・データベースのスタンバイ・データベースのマウントを示す出力マウントを示す出力マウントを示す出力マウントを示す出力

マウントしていない場合のマウントしていない場合のマウントしていない場合のマウントしていない場合の異なるターゲットの選択または異なるターゲットの選択または異なるターゲットの選択または異なるターゲットの選択または手動によるオープン手動によるオープン手動によるオープン手動によるオープン

フィジカル MOUNTED, PHYSICAL STANDBY STARTUP NOMOUNT

ロジカル READ WRITE, LOGICAL STANDBY STARTUP



手順手順手順手順 3: 選択されたスタンバイ・インスタンスでのリカバリの開始選択されたスタンバイ・インスタンスでのリカバリの開始選択されたスタンバイ・インスタンスでのリカバリの開始選択されたスタンバイ・インスタンスでのリカバリの開始フィジカル・スタンバイ・データベースには、次の文を使用します。

RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

ロジカル・スタンバイ・データベースには、次の文を使用します。


手順手順手順手順 4: 新しい適用ホストへのアーカイブ新しい適用ホストへのアーカイブ新しい適用ホストへのアーカイブ新しい適用ホストへのアーカイブ REDO ログのコピーログのコピーログのコピーログのコピー必要に応じて、アーカイブ REDO ログを新しい適用ホストにコピーします。

フィジカル・スタンバイ・データベースの場合、コピーは必要ありません。フィジカル・スタンバイ・データベースの場合は、管理リカバリ・プロセスでアーカイブ・ギャップが検出されると、本番アーカイブ REDO ログを自動的に再送信する要求が発行されます。

ロジカル・スタンバイ・データベースの場合、すでに登録されている未適用のアーカイブ・ファイル名は、ロジカル・スタンバイ・データベースには自動的に再送信されません。アーカイブ REDO ログは、新しい適用ホストの同じディレクトリ構造に手動で送信する必要があります。次のような文を実行することで、すでに登録されている未適用のアーカイブREDO ログを識別できます。

SELECT LL.FILE_NAME, LL.THREAD#, LL.SEQUENCE#, LL.FIRST_CHANGE#, LL.NEXT_CHANGE#, LP.APPLIED_SCN, LP.READ_SCN FROM DBA_LOGSTDBY_LOG LL, DBA_LOGSTDBY_PROGRESS LP WHERE LEAST(LP.APPLIED_SCN, LP.READ_SCN) <= LL.NEXT_CHANGE#;

文の結果を STANDBY_ARCHIVE_DESTディレクトリの内容と比較します。

手順手順手順手順 5: 新しい構成の検証新しい構成の検証新しい構成の検証新しい構成の検証1. アーカイブ REDO ログが新しい適用ホストに送信されていることを検証します。

V$ARCHIVE_STATUSおよび V$ARCHIVED_DEST_STATUSを問い合せます。

SELECT NAME_SPACE, STATUS, TARGET, LOG_SEQUENCE ,TYPE,PROCESS, REGISTER , ERROR FROM V$ARCHIVE_DESTWHERE STATUS!='INACTIVE';

SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE STATUS!='INACTIVE';

関連項目関連項目関連項目関連項目 : Oracle Technology Network Japan にある『Oracle Data Guard SQL Apply Best Practices』を参照してください。



2. 新しい適用ホストで管理リカバリまたは論理適用が進行していることを検証します。

次の問合せを発行し、時間の経過とともに順序番号が進んでいることを確認します。

フィジカル・スタンバイ・データベースには、次の文を使用します。

SELECT MAX(SEQUENCE#), THREAD# FROM V$LOG_HISTORY GROUP BY THREAD#;SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, CLIENT_PROCESS FROM V$MANAGED_ STANDBY;

ロジカル・スタンバイ・データベースには、次の文を使用します。

SELECT MAX(SEQUENCE#), THREAD# FROM DBA_LOGSTDBY_LOG GROUP BY THREAD#;SELECT APPLIED_SCN FROM DBA_LOGSTDBY_PROGRESS;

データ障害に対するリカバリ・ソリューションデータ障害に対するリカバリ・ソリューションデータ障害に対するリカバリ・ソリューションデータ障害に対するリカバリ・ソリューションデータ障害からのリカバリは計画外停止に対する処置です。データ障害は、それが明らかにデータベース内の問題であっても、多くの場合データベース外で発生した一部のアクティビティまたは障害がその原因です。

データ障害は、次のタイプのデータベース・オブジェクトに影響を与える可能性があります。

� アプリケーション表領域、データ・ディクショナリ、UNDO表領域、一時表領域などのデータファイル

� 制御ファイル

� スタンバイ制御ファイル

� オンライン REDO ログ

� スタンバイ REDO ログ

� アーカイブ REDO ログ

� サーバー・パラメータ・ファイル（SPFILE）

データ障害は、データファイル・ブロックの破損またはメディア障害として分類できます。

� データファイル・ブロックの破損 : 破損したデータファイル・ブロックにはアクセスできますが、ブロック内の内容は無効かまたは一貫性がありません。

� メディア障害 : メディア障害はハードウェアの物理的な問題またはユーザー・エラーが原因です。システムでは、データベースの操作に必要なファイルを正しく読取りまたは書込みできません。



すべての環境で、次の方法の 1 つを使用してデータ障害による停止を解決できます。

� Recovery Manager のデータファイル・メディアのリストアとリカバリ

� Recovery Manager のブロック・メディアのリストアとリカバリ

� 手動によるオブジェクトの再作成

Data Guard 環境では、スタンバイ・データベースへの Data Guard スイッチオーバーまたはフェイルオーバーを使用しても、データ障害からリカバリできます。

データベース・オブジェクトが使用できなくなったり、一貫性を失うことに関連した停止の原因には、表の削除や表データの誤った更新などのユーザー・エラーがあります。ユーザー・エラーからのリカバリの詳細は、10-37 ページの「フラッシュバック・テクノロジによるユーザー・エラーからのリカバリ」を参照してください。


� データファイル・ブロックの破損の検出とリカバリ

� メディア障害からのリカバリ

� データ障害に対するリカバリ方法

データファイル・ブロックの破損の検出とリカバリデータファイル・ブロックの破損の検出とリカバリデータファイル・ブロックの破損の検出とリカバリデータファイル・ブロックの破損の検出とリカバリ破損したデータファイル・ブロックにはアクセスできますが、ブロック内の内容は無効かまたは一貫性がありません。データファイルが破損する典型的な原因は、ファイル・システム、ボリューム・マネージャ、デバイス・ドライバ、ホスト・バス・アダプタ、ストレージ・コントローラ、ディスク・ドライブなど、I/O スタック内の障害を持つハードウェアまたはソフトウェア・コンポーネントにあります。

通常、データベースは破損したブロックが検出されても使用できますが、ファイル・ヘッダーの破損やデータ・ディクショナリ・オブジェクトの破損、アプリケーションが使用できなくなる重要な表の破損など、一部の破損ブロックによって問題が広範囲に及ぶ可能性があります。


� データファイル・ブロックの破損の検出

� データファイル・ブロックの破損からのリカバリ


� 高度なユーザー管理の詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。




データファイル・ブロックの破損の検出データファイル・ブロックの破損の検出データファイル・ブロックの破損の検出データファイル・ブロックの破損の検出データ障害は、アプリケーションの可用性に影響するため、ユーザー、管理者、Recovery Manager バックアップまたはアプリケーションによって認識された場合に検出されます。次に例を示します。

� 物理ディスクの不良部分が原因で、アプリケーションで読み取れないユーザー表の単一の破損データ・ブロック

� ディスク・コントローラの障害が原因で SYSTEM表領域内のデータファイルのブロックが無効なために自動的に停止したデータベース

アプリケーション・ログ（データ・サーバー、中間層およびクライアント・マシンに分散可能）、アラート・ログ、および ORA-01578 や ORA-01110 などのエラーに関する Oracle のトレース・ファイルは定期的に監視してください。

ORA-01578: Oracleデータ・ブロックに障害が発生しました（ファイル番号 4、ブロック番号 26）ORA-01110: データファイル 4: '/u01/oradata/objrs/obj_corr.dbf'

データファイル・ブロックの破損からのリカバリデータファイル・ブロックの破損からのリカバリデータファイル・ブロックの破損からのリカバリデータファイル・ブロックの破損からのリカバリデータファイル・ブロックの破損を識別した後は、次の手順を実行します。

1. 破損範囲の判断

2. 障害のあるハードウェアの置換または移動

3. 影響を受けるオブジェクトの判断

4. 使用するリカバリ方法の決定

破損範囲の判断破損範囲の判断破損範囲の判断破損範囲の判断次の方法を使用して破損の範囲を判断します。

� エラー・メッセージによる詳細の収集

エラー・メッセージからファイル番号、ファイル名およびブロック番号を収集します。次に例を示します。

ORA-01578: Oracleデータ・ブロックに障害が発生しました（ファイル番号 22、ブロック番号 12698）ORA-01110: データファイル 22: '/oradata/SALES/users01.dbf'

ファイル番号は 22、ブロック番号は 12698、ファイル名は/oradata/SALES/users01.dbfです。

� ログ・ファイルでの追加エラー・メッセージのチェック

アラート・ログ、Oracle のトレース・ファイルまたはアプリケーション・ログに表示される追加エラー・メッセージを記録します。ログ・ファイルはデータ・サーバー、中間層およびクライアント・マシンに分散している可能性があります。



� Oracle Utilities によるその他の破損のチェック

Oracle の検出ツールを使用して、同じディスクまたはレポートされていない一連のディスクに存在している可能性がある他のデータ障害の問題を検出します。たとえば、ファイル番号 22 に破損ブロックがある場合は、Recovery Manager の BACKUP VALIDATE DATAFILE 22コマンドを実行して、他の破損を検出することが賢明な処理となります。表 10-2 に、データファイル・ブロックの破損を検出するために使用できる Oracle Tools の概略を示します。

表表表表 10-2 データファイル・ブロックの破損を検出するためのデータファイル・ブロックの破損を検出するためのデータファイル・ブロックの破損を検出するためのデータファイル・ブロックの破損を検出するための Oracle Tools

Oracle Tools 説明説明説明説明追加情報の場所追加情報の場所追加情報の場所追加情報の場所

VALIDATEオプションを使用し

た Recovery Manager の BACKUPまたは RESTOREコマンド

Recovery Manager は、指定されたファイルをス

キャンし、内容を検証して物理的および論理的なエラーが発生していないかをチェックします。ただし、バックアップ操作やリカバリ操作は実行しません。Oracle は、破損ブロックのアドレスと破

損のタイプを制御ファイルに記録します。記録されたレコードには V$DATABASE_BLOCK_CORRUPTIONビューからアクセスします。このレ

コードは Recovery Manager のブロック・メディ

ア・リカバリで使用できます。

BLOCK CHANGE TRACKINGが有効な場合は、す

べてのデータ・ブロックの確実な読取りと検証のために、BACKUP VALIDATEでは INCREMENTAL LEVELオプションを使用しないでください。

検出可能な破損をすべて検出するには、次の点に注意してください。

� MAXCORRUPTオプションを指定しないでくだ

さい。

� NOCHECKSUMオプションを指定しないでくだ

さい。

� CHECK LOGICALオプションを指定してくだ

さい。

『Oracle Database バックアッ

プおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

DBVERIFYユーティリティデータファイルまたはデータファイル内の特定のセグメントに対して物理構造のデータ整合性チェックを実行する外部コマンドライン・ユーティリティです。DBVERIFYの出力は、画面に表

示されるかまたは指定された LOGFILEに格納さ

れます。

『Oracle Database ユーティリ

ティ』



障害のあるハードウェアの置換または移動障害のあるハードウェアの置換または移動障害のあるハードウェアの置換または移動障害のあるハードウェアの置換または移動破損の問題の一部は、障害のあるハードウェアが原因です。ハードウェア障害または障害の疑いがあるコンポーネントがある場合は、先に進む前に、リカバリ・オプションを使用して問題を修復するか、または個別のディスク・サブシステムのディスク領域を使用できるようにすることが賢明な処理です。

複数のエラーがある場合、影響を受けるファイルに対してオペレーティング・システム・レベルのエラーがある場合、またはエラーが一時的で発生箇所が一定していない場合は、根本的な問題が処置されるまで、または代替ディスクの領域が使用可能になるまで、継続操作はほとんどできません。ハードウェア・ベンターに連絡してシステムの整合性を検証してください。

Data Guard 環境では、破損の問題がオフラインで処理されている間に、スイッチオーバーを実行してアプリケーションを起動し、サービスを迅速にリストアできます。

影響を受けるオブジェクトの判断影響を受けるオブジェクトの判断影響を受けるオブジェクトの判断影響を受けるオブジェクトの判断エラー・メッセージから収集したファイル ID（fid）とブロック ID（bid）および Oracle ブロック・チェック・ユーティリティの出力を使用し、次のような問合せを発行することで、破損によって影響を受けるデータベース・オブジェクトを判断します。

SELECT tablespace_name, partition_name, segment_type, owner, segment_nameFROM dba_extents WHERE file_id = fid AND bid BETWEEN block_id AND block_id + blocks - 1;

VALIDATE STRUCTUREオプ

ションを使用した ANALYZE SQL 文

索引、表またはクラスタの構造の整合性を検証し、破損を識別して、使用している表と索引の一貫性をチェックまたは検証します。問題点は、USER_DUMP_DESTのユーザー・セッションのトレース・

ファイルに記録されます。

『Oracle Database 管理者ガイ

ド』

DBMS_REPAIR PL/SQLパッケージ

指定された表、パーティションまたは索引のブロック・チェックを実行します。DBMS_REPAIRは、オラクル社カスタマ・サポート・センターの説明に従って注意して使用してください。

『Oracle Database 管理者ガイ

ド』

表表表表 10-2 データファイル・ブロックの破損を検出するためのデータファイル・ブロックの破損を検出するためのデータファイル・ブロックの破損を検出するためのデータファイル・ブロックの破損を検出するための Oracle Tools（続き）（続き）（続き）（続き）

Oracle Tools 説明説明説明説明追加情報の場所追加情報の場所追加情報の場所追加情報の場所



次に、問合せとその結果の出力例を示します。

SQL> select tablespace_name, partition_name, segment_type, 2 owner, segment_name from dba_extents 3 where file_id=4 and 11 between block_id and block_id + blocks -1;

TABLESPACE_NAME PARTITION_NAME SEGMENT_TYPE OWNER SEGMENT_NAME--------------- -------------- ------------ ----- ------------USERS TABLE SCOTT EMP

ANALYZE文を使用すると、表または索引の整合性を判断できます。

使用するリカバリ方法の決定使用するリカバリ方法の決定使用するリカバリ方法の決定使用するリカバリ方法の決定表 10-3 および表 10-4 に、推奨するリカバリ方法の概略を示します。リカバリ方法は、Data Guard を使用しているかどうかで異なります。

表 10-3 に、Data Guard を使用していない場合のデータ障害に対するリカバリ方法の概略を示します。

表表表表 10-3 Data Guard を使用しないデータ障害からのリカバリを使用しないデータ障害からのリカバリを使用しないデータ障害からのリカバリを使用しないデータ障害からのリカバリ

影響を受けるオブジェクト影響を受けるオブジェクト影響を受けるオブジェクト影響を受けるオブジェクト問題の範囲問題の範囲問題の範囲問題の範囲処置処置処置処置

データ・ディクショナリまたは UNDOセグメント

N/A Recovery Manager のデータファイ

ル・メディア・リカバリの使用

アプリケーション・セグメント（ユーザー表、索引、クラスタ）

広範囲または不明 Recovery Manager のデータファイ

ル・メディア・リカバリの使用

または

手動によるオブジェクトの再作成


限定的 Recovery Manager のブロック・メ

ディア・リカバリの使用

または


TEMPORARYセグメントまたは一時表 N/A 永続オブジェクトには影響ありません。必要に応じて一時表領域を再作成してください。



表 10-4 に、Data Guard がある場合のデータ障害に対するリカバリ方法の概略を示します。

表 10-3 および表 10-4 に示されているように、使用する適切なリカバリ方法は、次の基準により決定します。

� 影響を受けるオブジェクト : 使用可能なリカバリ処置は、破損の影響を受けるオブジェクトによって異なります。可能な値は次のとおりです。

– データ・ディクショナリまたは UNDOセグメント : 影響を受けるオブジェクトは、SYSの所有オブジェクトまたは UNDO表領域の一部です。

– 一時セグメント : 破損は一時表領域内の一時セグメントまたはオブジェクトで、永続オブジェクトには影響を与えません。

– アプリケーション・セグメント : アプリケーションが使用する表、索引またはクラスタです。

表表表表 10-4 Data Guard を使用したデータ障害からのリカバリを使用したデータ障害からのリカバリを使用したデータ障害からのリカバリを使用したデータ障害からのリカバリ

影響を受ける影響を受ける影響を受ける影響を受けるオブジェクトオブジェクトオブジェクトオブジェクト問題の範囲問題の範囲問題の範囲問題の範囲

アプリケーションアプリケーションアプリケーションアプリケーションへの影響への影響への影響への影響

ローカル・リカバリローカル・リカバリローカル・リカバリローカル・リカバリのコストのコストのコストのコスト処置処置処置処置

データ・ディクショナリまたは UNDOセグメント

N/A N/A N/A Data Guard を使用した

データ障害からのリカバリ


広範囲または不明低低 Recovery Manager のデー

タファイル・メディア・リカバリの使用

または



N/A 高 N/A Data Guard を使用した



N/A N/A 高 Data Guard を使用した



限定的低低 Recovery Manager のブ

ロック・メディア・リカバリの使用

または


TEMPORARYセグメント

または一時表

N/A N/A N/A 永続オブジェクトには影響ありません。必要に応じて一時表領域を再作成してください。



� アプリケーションへの影響

オブジェクトによっては、アプリケーションが機能するために不可欠なものもあります。この中には、アプリケーションのパフォーマンスと有用性にとって重要なオブジェクトも含まれます。また、履歴、レポート、ログ表など、それほど重要ではないオブジェクトの可能性もあります。すでに使用されていないオブジェクトや一時セグメントの場合もあります。

この基準は、Data Guard 環境のみに適用され、影響を受けたオブジェクトをローカルでリカバリするか、または Data Guard フェイルオーバーを使用するかを決定するために使用します。可能な値は次のとおりです。

– 高 : 可用性やパフォーマンスに大きな影響を与えるなど、オブジェクトはアプリケーションにとって重要です。

– 低 : オブジェクトはアプリケーションにとって重要でなく、影響はほとんど、またはまったくありません。

� ローカル・リカバリのコスト

この基準は、Data Guard 環境のみに適用され、影響を受けたオブジェクトをローカルでリカバリするか、または Data Guard フェイルオーバーを使用するかを決定するために使用します。このコストは、アプリケーションに対するオブジェクトの重要性を判断する際に考慮されるビジネス上のコストではなく、リカバリの実行可能性、必要なリソース、それらがパフォーマンスと合計所要時間に与える影響の観点におけるコストです。

ローカル・リカバリのコストには、1）有効なソースからオブジェクトをリストアおよびリカバリする時間、2）索引、制約、関連する表およびその索引と制約などの他の依存オブジェクトをリカバリする時間、3）ディスク領域、データまたは索引表領域、一時表領域などのリソースの可用性、および 4）破損によるオブジェクトの欠落に起因する現行の正常なアプリケーション機能のパフォーマンスと機能性への影響が含まれます。

� 破損の範囲

破損は、限定的で 1 つまたは少数のオブジェクト内の既知のブロック数に影響する場合と、広範囲でオブジェクトの大部分に影響する場合があります。



メディア障害からのリカバリメディア障害からのリカバリメディア障害からのリカバリメディア障害からのリカバリメディア障害が発生した場合は、次の手順に従います。

1. メディア障害の範囲の判断

2. 障害のあるハードウェアの置換または移動

3. 実行するリカバリ処置の決定

メディア障害の範囲の判断メディア障害の範囲の判断メディア障害の範囲の判断メディア障害の範囲の判断次の方法を使用してメディア障害の範囲を判断します。

� エラー・メッセージによる詳細の収集

報告されたエラー・メッセージからファイル番号とファイル名を収集します。典型的なエラー・メッセージは、ORA-01157 と ORA-01110 および ORA-01115 と ORA-01110 です。

たとえば、次のエラー・メッセージから情報を収集します。

ORA-01115: ファイル 22（ブロック番号 12698）からの読取り I/Oエラーが発生しました。 ORA-01110: データファイル 22: '/oradata/SALES/users01.dbf'

� ログ・ファイルでの追加エラー・メッセージのチェック

システム・ログ、ボリューム・マネージャ・ログ、アラート・ログ、Oracle のトレース・ファイルまたはアプリケーション・ログに表示される追加エラー・メッセージを記録します。ログ・ファイルはデータ・サーバー、中間層およびクライアント・マシンに分散している可能性があります。

障害のあるハードウェアの置換または移動障害のあるハードウェアの置換または移動障害のあるハードウェアの置換または移動障害のあるハードウェアの置換または移動ハードウェア障害または障害の疑いがあるコンポーネントがある場合は、先に進む前に、リカバリ・オプションを使用して問題を修復するか、または個別のディスク・サブシステムのディスク領域を使用できるようにすることが賢明な処理です。

複数のエラーがある場合、影響を受けるファイルに対してオペレーティング・システム・レベルのエラーがある場合、またはエラーが一時的で発生箇所が一定していない場合は、根本的な問題が処置されるまで、または代替ディスクの領域が使用可能になるまで、継続操作はほとんどできません。ハードウェア・ベンターに連絡してシステムの整合性を検証してください。



実行するリカバリ処置の決定実行するリカバリ処置の決定実行するリカバリ処置の決定実行するリカバリ処置の決定適切なリカバリ処置は、メディア障害で影響を受けるファイルのタイプによって異なります。表 10-5 に、ファイルのタイプと適切なリカバリを示します。

表表表表 10-5 タイプが異なるファイルの障害に対するリカバリ処置タイプが異なるファイルの障害に対するリカバリ処置タイプが異なるファイルの障害に対するリカバリ処置タイプが異なるファイルの障害に対するリカバリ処置

ファイルのタイプファイルのタイプファイルのタイプファイルのタイプリカバリ処置リカバリ処置リカバリ処置リカバリ処置

データファイルデータファイルのメディア障害は、広範囲なデータファイル・ブロックの破損への対応と同じ方法で解決されます。

関連項目関連項目関連項目関連項目 : 10-24 ページの「データファイル・ブロックの破損からのリカバリ」を参照

してください。

制御ファイル制御ファイルを消失すると、プライマリ・データベースが停止します。制御ファイルの障害をリカバリする手順には、正しい制御ファイルのコピーの作成、制御ファイルのバックアップ・コピーのリストア、または CREATE CONTROLFILE文を使用した手

動による制御ファイルの作成があります。適切なリカバリ方法は、次の条件によって異なります。

� 現在の制御ファイルすべてを消失したか、多重制御ファイルのメンバーの消失のみか

� バックアップ制御ファイルが使用可能かどうか

関連項目関連項目関連項目関連項目 : 『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザー

ズ・ガイド』のユーザー管理のフラッシュバックとリカバリに関する項を参照してください。

スタンバイ制御ファイルスタンバイ制御ファイルを消失すると、スタンバイ・データベースが停止します。また、プライマリ・データベースの保護モードによっては、プライマリ・データベースも停止する可能性があります。スタンバイ制御ファイルの障害をリカバリするには、新しいスタンバイ制御ファイルをプライマリ・データベースから作成してスタンバイ・システムに転送する必要があります。

関連項目関連項目関連項目関連項目 : 『Oracle Data Guard 概要および管理』の「フィジカル・スタンバイ・デー

タベースの作成」を参照してください。



オンライン REDO ログ・

ファイル

データベースのオンライン REDO ログがメディア障害の影響を受けた場合の適切なリ

カバリ手続きは、次の条件によって異なります。

� オンライン REDO ログの構成 : ミラー化されているかどうか

� メディア障害のタイプ : 一時的か永続的か

� メディア障害で影響を受けるオンライン REDO ログ・ファイルのステータス : 現行、アクティブ、非アーカイブまたは非アクティブ


ズ・ガイド』のユーザー管理のアドバンスト・リカバリ使用例に関する項を参照してください。

オンライン REDO ログの障害によってプライマリ・データベースが停止したため、不

完全リカバリを使用してデータベースを再稼働する必要がある場合は、すべてのデータファイルをリストアするかわりに、フラッシュバック・データベースを使用できます。フラッシュバック・データベースを使用して、消失したオンライン REDO ログ・

グループの SCN よりも前の SCN までデータベースを戻します。フラッシュバック・

データベース手続きの一部として実行するリセットログ操作によって、すべてのオンライン REDO ログ・ファイルが再初期化されます。フラッシュバック・データベース

を使用するほうが、すべてのデータファイルをリストアするよりも高速です。

オンライン REDO ログの障害のために Data Guard 環境でプライマリ・データベース

が停止した場合は、Data Guard フェイルオーバーを実行して、ユーザーに対するサー

ビスのリストアに要する時間を短縮し、データの消失被害を軽減することが賢明な処理です（ただし、適切なデータベース保護モードを使用している場合）。（たとえば、フラッシュバック・データベースを使用してプライマリ・サイトでローカルにリカバリするかわりに）フェイルオーバーを実行する判断は、プライマリ・サイトでの停止からリカバリするまでの予測時間、データの消失予想量、およびプライマリ・サイトでのリカバリ手続きがスタンバイ・データベースに与える影響によって異なります。

たとえば、プライマリ・サイトでのリカバリを決定した場合、そのリカバリ手順には、フラッシュバック・データベース、および消失したデータの完全な REDO ログ・ファ

イルとなるオープン・リセットログが必要です。すべての REDO データはスタンバ

イ・データベースで使用できるため、ほとんどの場合、スタンバイ・データベースでのデータ消失は、プライマリ・サイトでのリカバリよりも少なくなります。プライマリ・サイトでリカバリを実行したときに、スタンバイ・データベースがプライマリ・データベースのリカバリ時点より進んでいる場合は、そのスタンバイ・データベースをプライマリ・データベースのリセットログの SCN よりも前の時点に再作成またはフ

ラッシュバックする必要があります。

関連項目関連項目関連項目関連項目 : 『Oracle Data Guard 概要および管理』の「フィジカル・スタンバイ・デー

タベースの作成」を参照してください。

表表表表 10-5 タイプが異なるファイルの障害に対するリカバリ処置（続き）タイプが異なるファイルの障害に対するリカバリ処置（続き）タイプが異なるファイルの障害に対するリカバリ処置（続き）タイプが異なるファイルの障害に対するリカバリ処置（続き）




スタンバイ REDO ログ・

ファイル

Data Guard 環境では、スタンバイ REDO ログの障害はスタンバイ・データベースのみ

に影響を与えます。スタンバイ REDO ログのほとんどの障害は、プライマリ・データ

ベースに影響を与えないまま、スタンバイ・データベースによって自動的に処理されます。ただし、スタンバイ REDO ログ・ファイルへのアーカイブ中に障害が発生した

場合、その障害は、ログ・アーカイブ先の障害としてプライマリ・データベースが処理します。

関連項目関連項目関連項目関連項目 : 7-23 ページの「データ保護モードの決定」を参照してください。

アーカイブ REDO ログ・

ファイル

アーカイブ REDO ログの消失は、プライマリ・データベースの可用性に直接影響を与

えませんが、別のメディア障害がスケジュールした次回のバックアップ以前に発生した場合、または Data Guard を使用している環境で、スタンバイ・システムでのアーカ

イブ REDO ログの受信が完了していなかったために、ファイルの消失前にそのログが

スタンバイ・データベースに適用されていなかった場合は、可用性に重大な影響を与える可能性があります。


ズ・ガイド』のユーザー管理のアドバンスト・リカバリ使用例に関する項を参照してください。

Data Guard 環境でアーカイブ REDO ログを消失しても、そのログがスタンバイ・デー

タベースにすでに適用されていた場合、影響はありません。消失したファイルの有効なバックアップ・コピーがない場合は、他の停止が発生した場合に必要となる可能性があるメディア・リカバリでログが使用できるように、ただちにプライマリまたはスタンバイ・データベースのいずれかのバックアップを取る必要があります。

消失したアーカイブ REDO ログがスタンバイ・データベースに適用されていない場合

は、ファイルのバックアップ・コピーをリストアし、スタンバイ・データベースで使用できるようにする必要があります。消失したアーカイブ REDO ログの有効なバック

アップ・コピーがない場合は、消失したログの NEXT_CHANGE#（V$ARCHIVED_LOGを参照してください）以降に行われたプライマリ・データベースのバックアップから、スタンバイ・データベースを再インスタンス化する必要があります。

サーバー・パラメータ・ファイル（SPFILE）

サーバー・パラメータ・ファイルの消失は、データベースの可用性には影響を与えません。データベースの起動には SPFILEが必要です。フラッシュ・リカバリおよび

Recovery Manager の CONTROLFILE AUTOBACKUP機能を有効にして、バックアップ

からサーバー・パラメータ・ファイルをリストアする方法が高速です。

関連項目関連項目関連項目関連項目 : 『Oracle Database バックアップおよびリカバリ基礎』のリカバリの実行に

関する項を参照してください。

Oracle Cluster Registry（OCR）

Oracle Cluster Registry ファイルの消失は、RAC および Cluster Ready Services の可用

性に影響を与えます。OCR ファイルは、自動的に作成された物理バックアップ、また

は ocrconfigツールを使用して手動で作成されたエクスポート・ファイルからリス

トアできます。

関連項目関連項目関連項目関連項目 : 『Oracle Real Application Clusters 管理者ガイド』の Real Application Clustersの記憶域管理に関する項を参照してください。

表表表表 10-5 タイプが異なるファイルの障害に対するリカバリ処置（続き）タイプが異なるファイルの障害に対するリカバリ処置（続き）タイプが異なるファイルの障害に対するリカバリ処置（続き）タイプが異なるファイルの障害に対するリカバリ処置（続き）




データ障害に対するリカバリ方法データ障害に対するリカバリ方法データ障害に対するリカバリ方法データ障害に対するリカバリ方法次のリカバリ方法はすべての環境で使用できます。

� Recovery Manager のデータファイル・メディア・リカバリの使用

� Recovery Manager のブロック・メディア・リカバリの使用

� 手動によるオブジェクトの再作成

Data Guard を使用していない場合は、常にローカルのリカバリ方法を使用します。ローカルのリカバリ方法は、Data Guard 環境にも適しています。この項の内容は、次のとおりです。

� Data Guard を使用したデータ障害からのリカバリ

Recovery Manager のデータファイル・メディア・リカバリの使用のデータファイル・メディア・リカバリの使用のデータファイル・メディア・リカバリの使用のデータファイル・メディア・リカバリの使用データファイル・メディア・リカバリは、Recovery Manager の RECOVERコマンドを使用して、データベースのデータファイル全体または一連のデータファイルをリカバリします。多数または未知数のデータ・ブロックにメディア障害のマークが付けられ、メディア・リカバリが必要な場合、またはファイル全体を消失した場合は、影響を受けたデータファイルをリストアおよびリカバリする必要があります。

次の条件に当てはまる場合は Recovery Manager のファイル・メディア・リカバリを使用します。

� リカバリを必要とするブロックが多数または未知数の場合

� ブロック・メディア・リカバリを使用できない場合（たとえば、不完全リカバリが必要な場合、またはリカバリが必要なデータファイルに対して増分バックアップのみが使用可能な場合）

Recovery Manager のブロック・メディア・リカバリの使用のブロック・メディア・リカバリの使用のブロック・メディア・リカバリの使用のブロック・メディア・リカバリの使用ブロック・メディア・リカバリ（BMR）は、Recovery Manager の BLOCKRECOVERコマンドを使用して、データファイル内でメディア障害とマークされた単一または一連のデータ・ブロックをリカバリします。少数のデータ・ブロックがメディア障害とマークされ、メディア・リカバリが必要な場合は、データファイル全体ではなく、破損したブロックを選択してリストアおよびリカバリできます。この方法を使用すると、リカバリが必要なブロックのみがリストアされ、必要な破損ブロックのみがリカバリの対象となるため、平均リカバリ時間

（MTTR）が短縮されます。ブロック・メディア・リカバリによって、REDO 適用時間が小限に短縮され、リカバリ時の I/O オーバーヘッドが回避されます。また、破損ブロックのリカバリ中は、影響を受けたデータファイルをオンラインのままにできます。ただし、その破損ブロックは、完全にリカバリされるまで使用できません。

関連項目関連項目関連項目関連項目 : 『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』のユーザー管理のアドバンスト・リカバリ使用例に関する項を参照してください。



次の場合は、ブロック・メディア・リカバリを使用します。

� メディア・リカバリの必要なブロックは少数で、リカバリの必要なブロック数がわかっている場合。データファイルの大部分が破損している場合、または破損している量が不明な場合は、別のリカバリ方法を使用する必要があります。

� ブロックに破損のマークが付けられ（Recovery Manager の BACKUP VALIDATEコマンドで確認）、完全リカバリが必要な場合のみ。

ブロック・メディア・リカバリは、次の場合のリカバリには使用できません。

� データ・ブロックに損傷はなく、論理的な破損の原因がユーザー・エラーまたはソフトウェアにある場合。このタイプのリカバリの詳細は、10-37 ページの「フラッシュバック・テクノロジによるユーザー・エラーからのリカバリ」を参照してください。

� 破損した REDO データが原因の変更の場合。ブロック・メディア・リカバリでは、使用可能なすべての REDO データをリカバリするブロックに適用する必要があります。

ブロック・メディア・リカバリを使用する場合は、次のプラクティスが役立ちます。

� フラッシュ・リカバリ領域には、ブロックの破損を検出する Oracle Tools の使用頻度よりも長くディスクに保存されているすべてのデータファイルをバックアップするような保存方針を指定する必要があります。たとえば、Recovery Manager の BACKUP VALIDATEを週に 1 度実行する場合、フラッシュ・リカバリ領域には、1 週間より長い保存方針を指定する必要があります。これによって、ディスク・ベースのバックアップのブロック・メディア・リカバリを使用して、破損ブロックを迅速にリカバリできます。

� アーカイブ REDO ログに REDO データが欠落していても、ブロックのリストアにデータファイルのバックアップが使用されたときからブロックが更新されている場合、または欠落している REDO データの特定ブロックに変更がない場合は、ブロック・メディア・リカバリをそのまま実行できます。

� Recovery Manager ブロックの検証を事前に実行している場合は、Recovery Manager によって破損が確認されたブロックのリストが V$DATABASE_BLOCK_CORRUPTIONビューに表示されます。Recovery Manager に指示を与え、V$DATABASE_BLOCK_CORRUPTIONにリストされているすべての破損ブロックを、ブロック・メディア・リカバリを使用してリカバリできます。




手動によるオブジェクトの再作成手動によるオブジェクトの再作成手動によるオブジェクトの再作成手動によるオブジェクトの再作成小規模な参照表や索引など、一部のデータベース・オブジェクトは、メディア・リカバリを実行するかわりに、オブジェクトを手動で再作成することで迅速にリカバリできます。

次の場合は、手動によるオブジェクトの再作成を使用します。

� メディアが破損したために小規模な索引を再作成する必要がある場合。索引をオンラインで作成することで、基礎となるオブジェクトを同時に使用できるようになります。

� 参照表を再作成する必要がある場合、または表を再作成するスクリプトが使用できる場合。表を削除して再作成することがも速い可能性があります。

Data Guard を使用したデータ障害からのリカバリを使用したデータ障害からのリカバリを使用したデータ障害からのリカバリを使用したデータ障害からのリカバリフェイルオーバーとは、あるサイトの本番データベースをオフラインにして、スタンバイ・データベースの 1 つを新しい本番データベースとしてオンラインにする操作です。データベース・スイッチオーバーとは、スタンバイ・データベースと本番データベースでロールを切り替える計画的なトランジションです。

次の場合は、Data Guard のスイッチオーバーまたはフェイルオーバーを使用します。

� データベースが停止している場合、またはデータベースは起動しているが、データ障害のためにアプリケーションを使用できず、ローカルでのリストアとリカバリに時間かかるか、または時間が不明な場合。

� スイッチオーバーまたはフェイルオーバーおよびスタンバイ・データベースの再作成に関わるビジネス・コストが、ローカルでのリカバリ手順の実行で予想される停止時間や能力低下に関わるコストより低い場合。

� ローカルでのリカバリに対する適切な判断が不明瞭または複雑すぎるため、データ障害がアプリケーションの可用性に影響を与えている場合。

関連項目関連項目関連項目関連項目 : 10-10 ページの「データベース・フェイルオーバー」および10-13 ページの「データベース・スイッチオーバー」



フラッシュバック・テクノロジによるユーザー・エラーからのフラッシュバック・テクノロジによるユーザー・エラーからのフラッシュバック・テクノロジによるユーザー・エラーからのフラッシュバック・テクノロジによるユーザー・エラーからのリカバリリカバリリカバリリカバリ

Oracle のフラッシュバック・テクノロジは、データ・リカバリを刷新します。従来は、データベースの破損には数秒、そのリカバリには数時間から数日かかりました。フラッシュバック・テクノロジによって、エラーの修正にかかる時間を、そのエラーが作成された時間と同程度まで短縮できます。データベース、表、トランザクションまたは行レベルの変更を以前の状態に戻す必要があるユーザー・エラーの修正は容易で、データベースまたはオブジェクトをリストアする必要もありません。フラッシュバック・テクノロジは、行の誤った削除など、限定的な破損に対してきめ細かい分析と修復を提供します。フラッシュバック・テクノロジによって、誤ったアプリケーション・バッチ・ジョブの偶発的な実行など、広範囲に及ぶ破損の修正が可能になります。フラッシュバック・テクノロジは、データベース・リストアよりも飛躍的に高速です。

フラッシュバック・テクノロジは、次のユーザー・エラーの修復にのみ適用できます。

� トランザクションの誤りまたは故意による更新、削除または挿入

� 誤りまたは故意による DROP TABLE文

� 誤りまたは故意によるバッチ・ジョブまたは広範囲なアプリケーション・エラー

フラッシュバック・テクノロジは、ブロック破損、不良ディスク、ファイル削除など、メディアやデータの破損には使用できません。これらの停止の修復方法は、10-22 ページの

「データ障害に対するリカバリ・ソリューション」および 10-10 ページの「データベース・フェイルオーバー」を参照してください。

表 10-6 に、各停止タイプに対するフラッシュバック・ソリューションの概略を示します。

表表表表 10-6 異なる停止に対するフラッシュバック・ソリューション異なる停止に対するフラッシュバック・ソリューション異なる停止に対するフラッシュバック・ソリューション異なる停止に対するフラッシュバック・ソリューション

停止の影響停止の影響停止の影響停止の影響ユーザー・エラーの例ユーザー・エラーの例ユーザー・エラーの例ユーザー・エラーの例フラッシュバック・ソリューションフラッシュバック・ソリューションフラッシュバック・ソリューションフラッシュバック・ソリューション

行またはトランザクション

関連項目関連項目関連項目関連項目 : 10-39 ページの「行とトラ

ンザクションの非一貫性の解決」を参照してください。

� 行の偶発的な削除

� 誤ったトランザクション

次のソリューションを組み合せて使用します。

� フラッシュバック問合せ

� フラッシュバック・バージョン問合せ

� フラッシュバック・トランザクション問合せ

関連項目関連項目関連項目関連項目 : 10-39 ページの「フラッ

シュバック問合せ」を参照してください。

表

関連項目関連項目関連項目関連項目 : 10-43 ページの「表の非一

貫性の解決」を参照してください。

� 削除された表

� 1 つの表または一連の表に影響を

与える誤ったトランザクション

� フラッシュバック・ドロップ

� フラッシュバック・テーブル



表 10-7 に、各フラッシュバックの機能の概略を示します。

表領域またはデータベース

関連項目関連項目関連項目関連項目 : 10-44 ページの「データ

ベース全体の非一貫性の解決」を参照してください。

� 多数の表または未知の一連の表に影響を与える誤ったバッチ・ジョブ

� データベース全体に及ぶ一連の故意によるトランザクション

� 物理データファイルを削除しない表領域の削除

� フラッシュバック・データベース

� フラッシュバック・データベースおよび削除されたデータファイルのみのリストア

表表表表 10-7 フラッシュバック機能の概要フラッシュバック機能の概要フラッシュバック機能の概要フラッシュバック機能の概要

フラッシュバック機能フラッシュバック機能フラッシュバック機能フラッシュバック機能説明説明説明説明

フラッシュバック問合せフラッシュバック問合せでは、過去の特定時点でのデータを表示できます。この機能を使用すると、事故によって削除または変更された消失データを表示して再構築できます。開発者は、この機能を使用してセルフサービスのエラー修正をアプリケーションに組み込み、エンド・ユーザーによる UNDO とエラーの解決を支援できます。

注意注意注意注意 : 変更は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・

データベースに伝播されます。

フラッシュバック・バージョン問合せ

フラッシュバック・バージョン問合せでは、データベースに格納されている UNDOデータを使用して、1 つ以上の行に対する変更とそのすべてのメタデータが表示されま

す。

注意 : 変更は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・デー

タベースに伝播されます。

フラッシュバック・トランザクション問合せ

フラッシュバック・トランザクション問合せでは、トランザクション・レベルでデータベースに対して行われた変更を検査できます。これによって、問題を診断し、分析を実行してトランザクションを監査できます。



フラッシュバック・ドロップ

フラッシュバック・ドロップによって、偶発的に削除された表をリストアできます。

注意注意注意注意 : 変更は、フィジカル・スタンバイ・データベースに伝播されます。

フラッシュバック・テーブル

フラッシュバック・テーブルによって、バックアップをリストアせずに、表を過去の特定時点まですばやくリカバリできます。



フラッシュバック・データベース

フラッシュバック・データベースによって、以前の特定時点以降に発生した変更をすべて取り消して、データベースをその時点まですばやく戻すことができます。この操作は、バックアップをリストアする必要がないため高速です。

表表表表 10-6 異なる停止に対するフラッシュバック・ソリューション（続き）異なる停止に対するフラッシュバック・ソリューション（続き）異なる停止に対するフラッシュバック・ソリューション（続き）異なる停止に対するフラッシュバック・ソリューション（続き）

停止の影響停止の影響停止の影響停止の影響ユーザー・エラーの例ユーザー・エラーの例ユーザー・エラーの例ユーザー・エラーの例フラッシュバック・ソリューションフラッシュバック・ソリューションフラッシュバック・ソリューションフラッシュバック・ソリューション



フラッシュバック・データベースは Oracle Database のフラッシュバック・ログを使用します。一方、フラッシュバック・テクノロジの他のすべての機能では Oracle Database 固有のUNDO およびマルチバージョンの読取り一貫性機能を使用します。これらのソリューションのためのリソースを障害時に使用できるようにフラッシュバック・テクノロジを構成する方法は、10-2 ページの「データベースに関する構成上のベスト・プラクティス」を参照してください。


� 行とトランザクションの非一貫性の解決

� 表の非一貫性の解決

� データベース全体の非一貫性の解決

行とトランザクションの非一貫性の解決行とトランザクションの非一貫性の解決行とトランザクションの非一貫性の解決行とトランザクションの非一貫性の解決行とトランザクションの非一貫性の解決には、フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション問合せ、および問題を修正するために提示された UNDO 文を組み合せる必要があります。次の各項では、人事管理の例を使用して、誤りまたは故意によるユーザー・エラーが原因で発生する行とトランザクションの非一貫性を解決する一般的なアプローチを説明します。


� フラッシュバック問合せ

� フラッシュバック・バージョン問合せ

� フラッシュバック・トランザクション問合せ

� 例 : フラッシュバック・テクノロジを使用した給与相違の調査

フラッシュバック問合せフラッシュバック問合せフラッシュバック問合せフラッシュバック問合せフラッシュバック問合せは、Oracle9i Database で導入された機能で、管理者やユーザーは過去のある時点でのデータを問い合せることができます。この強力な機能を使用すると、事故によって削除または変更された可能性があるデータを表示して再構築できます。次に例を示します。

SELECT * FROM EMPLOYEES AS OF TIMESTAMP TO_DATE('28-Aug-03 14:00','DD-Mon-YY HH24:MI') WHERE ...

関連項目関連項目関連項目関連項目 : フラッシュバック・テクノロジと自動 UNDO 管理の詳細は、『Oracle Database 管理者ガイド』、『Oracle Database バックアップおよびリカバリ基礎』および『Oracle Database 概要』を参照してください。



この部分的な文によって、EMPLOYEES表から 2003 年 8 月 28 日午後 2 時以降の列が表示されます。開発者は、この機能を使用してセルフサービスのエラー修正をアプリケーションに組み込み、このタスクの実行を管理者に負担させずに、エンド・ユーザーによる UNDO とエラーの解決を遅延なく支援できます。構成可能な過去のある時点にデータを再構成するための情報は、データベース内に自動的に保持されています。したがって、フラッシュバック問合せの管理は非常に容易です。

フラッシュバック・バージョン問合せフラッシュバック・バージョン問合せフラッシュバック・バージョン問合せフラッシュバック・バージョン問合せフラッシュバック・バージョン問合せは、データベースに対する変更を行レベルで表示する方法を提供します。フラッシュバック・バージョン問合せは SQL に対する拡張であり、行の異なるバージョンすべてを指定された時間間隔で取得できます。次に例を示します。

SELECT * FROM EMPLOYEES VERSIONS BETWEEN TIMESTAMP TO_DATE('28-Aug-03 14:00','dd-Mon-YY hh24:mi') AND TO_DATE('28-Aug-03 15:00','dd-Mon-YY hh24:mi')WHERE ...

この文によって、本日の午後 2 時から 3 時までの行の各バージョン、つまり、異なるトランザクションによって変更された各エントリが表示されます。DBA は、この情報を使用して、データがいつ、どのように変更されたかを正確に特定し、変更を加えたユーザー、アプリケーションまたはトランザクションにさかのぼることができます。これによって、DBA は、データベース内の論理的な破損の原因を突き止めて修正できます。これを使用することで、アプリケーション開発者はコードをデバッグすることもできます。

フラッシュバック・トランザクション問合せフラッシュバック・トランザクション問合せフラッシュバック・トランザクション問合せフラッシュバック・トランザクション問合せフラッシュバック・トランザクション問合せは、データベースに対する変更をトランザクション・レベルで表示する方法を提供します。フラッシュバック・トランザクション問合せは SQL に対する拡張であり、トランザクションによるすべての変更を確認できます。次に例を示します。

SELECT UNDO_SQLFOMR DBA_TRANSACTION_QUERY WHERE XID = '000200030000002D';

この文は、このトランザクションに起因するすべての変更を表示します。また、補正するSQL 文が返されるため、この文を使用して、このトランザクションによって行われたすべての行に対する変更を取り消すことができます。このような精密なツールを使用することで、DBA とアプリケーション開発者は、データベースやアプリケーションの論理的な問題点を正確に診断し、修正できます。



例例例例 : フラッシュバック・テクノロジを使用した給与相違の調査フラッシュバック・テクノロジを使用した給与相違の調査フラッシュバック・テクノロジを使用した給与相違の調査フラッシュバック・テクノロジを使用した給与相違の調査SCOTTスキーマに関係する人事管理（HR）の例を考えます。HR マネージャは、Ward の給与が正しくない可能性があることを DBA にレポートしています。午前 9 時より前のある時点で、Ward の給与が 1875 ドルに増加されました。HR マネージャには、この変更がどのように生じたのか不明であり、給与が増加した時点の確認を希望しています。また、このマネージャは、給与を以前のレベルである 1250 ドルに再設定するようにスタッフに指示しています。この指示は午前 9 時 15 分頃に完了しています。

この問題に対するアプローチ方法は、次のとおりです。

1. 問題を検討評価します。

幸いなことに、この HR マネージャは、変更が生じた時間に関する情報を提供しています。フラッシュバック問合せを使用して、午前 9 時時点の情報を問合せできます。

SELECT EMPNO, ENAME, SALFROM EMPAS OF TIMESTAMP TO_DATE('03-SEP-03 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_ENDTIMEFROM EMPVERSIONS BETWEEN TIMESTAMP MINVALUE AND MAXVALUEWHERE EMPNO = 7521ORDER BY NVL(VERSIONS_STARTSCN,1);

EMPNO ENAME SAL VERSIONS_STARTTIME VERSIONS_ENDTIME-------- ---------- ---------- ---------------------- ---------------------- 7521 WARD 1250 03-SEP-03 08.48.43 AM 03-SEP-03 08.54.49 AM 7521 WARD 1875 03-SEP-03 08.54.49 AM 03-SEP-03 09.10.09 AM 7521 WARD 1250 03-SEP-03 09.10.09 AM

WARD の給与が午前 8 時 54 分 49 秒に 1250 ドルから 1875 ドルに増加し、続いて同じ日の午前 9 時 10 分 9 秒頃に 1250 ドルに再設定されたことを確認できました。



さらに、同様のフラッシュバック・バージョン問合せを使用して、WARD に影響を与える各変更のトランザクション情報を確認するように問合せを変更できます。ここではVERSIONS_XID疑似列を使用します。

SELECT EMPNO, ENAME, SAL, VERSIONS_XIDFROM EMPVERSIONS BETWEEN TIMESTAMP MINVALUE AND MAXVALUEWHERE EMPNO = 7521ORDER BY NVL(VERSIONS_STARTSCN,1);

EMPNO ENAME SAL VERSIONS_XID---------- ---------- ---------- ---------------- 7521 WARD 1250 0006000800000086 7521 WARD 1875 0009000500000089 7521 WARD 1250 000800050000008B

3. 誤ったトランザクションとその影響範囲を問い合せます。

トランザクション情報（VERSIONS_XID疑似列）を使用し、フラッシュバック・トランザクション問合せを使用してデータベースを問い合せ、このトランザクションの範囲を確認できます。

SELECT UNDO_SQLFROM FLASHBACK_TRANSACTION_QUERYWHERE 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. 修正文を実行するかどうかを判断します。

HR マネージャによって、UNDO_SQL列に提示されている修正変更が正しいと判断された場合、DBA はこれらの文を個別に実行できます。



表の非一貫性の解決表の非一貫性の解決表の非一貫性の解決表の非一貫性の解決Oracle には、偶発的な DROP TABLE文からリカバリするための FLASHBACK DROP文、およびデータベース内の表を過去の時点にリストアするための FLASHBACK TABLE文が用意されています。


� フラッシュバック・テーブル

� フラッシュバック・ドロップ

フラッシュバック・テーブルフラッシュバック・テーブルフラッシュバック・テーブルフラッシュバック・テーブルフラッシュバック・テーブルを使用すると、DBA は 1 つの表または一連の表を指定された時点まですばやく簡単にリカバリできます。多くの場合、フラッシュバック・テーブルによって、複雑な Point-in-Time リカバリ操作を実行する必要性が緩和されます。次に例を示します。

FLASHBACK TABLE orders, order_items TO TIMESTAMP TO_DATE('29-AUG-03 14.00.00','dd-Mon-yy hh24:mi:ss');

この文は、ORDERS表と ORDER_ITEMS表に対して、指定された過去のタイムスタンプから現在の時刻までに実行された更新を以前の状態に戻します。フラッシュバック・テーブルは、この操作をオンラインで適切に実行し、複数の表間の参照整合性制約を保持します。

フラッシュバック・ドロップフラッシュバック・ドロップフラッシュバック・ドロップフラッシュバック・ドロップ偶発的なデータベース・オブジェクトの削除は、よくある間違いです。ユーザーはすぐにその誤りに気付きますが、すでにその時点では手遅れであり、削除した表とその索引、制約、トリガーを簡単にリカバリする方法はありませんでした。一度削除したオブジェクトは永久に削除されていました。消失した表や他のオブジェクト（索引、パーティション、クラスタなど）が非常に重要である場合は、DBA による Point-in-Time リカバリの実行が必要ですが、時間がかかり、近のトランザクションを消失する可能性があります。

Oracle Database 10g では、フラッシュバック・ドロップによって、オブジェクトを削除した場合のセーフティ・ネットが提供されます。ユーザーが表を削除すると、Oracle ではその表がリサイクル・ビンに配置されます。リサイクル・ビンのオブジェクトは、ユーザーがそのオブジェクトを永久に削除すると決定するまで、または表を格納する表領域に領域制限が生じるまで保存されます。このリサイクル・ビンは、削除したすべてのオブジェクトを格納する仮想コンテナです。ユーザーは、リサイクル・ビンを確認し、削除した表とその依存オブジェクトの削除を取り消すことができます。たとえば、employees表とその依存オブジェクトすべての削除を取り消すには、次の文を発行します。

FLASHBACK TABLE employees TO BEFORE DROP;



データベース全体の非一貫性の解決データベース全体の非一貫性の解決データベース全体の非一貫性の解決データベース全体の非一貫性の解決Oracle には、データベース全体を過去の時点まで戻すためのフラッシュバック・データベースが用意されています。この項の内容は、次のとおりです。

� フラッシュバック・データベース

� フラッシュバック・データベースを使用した削除済表領域の修復

フラッシュバック・データベースフラッシュバック・データベースフラッシュバック・データベースフラッシュバック・データベースOracle データベースを以前の時点まで戻す従来の方法は、Point-in-Time リカバリです。ただし、Point-in-Time リカバリでは、データベース全体をバックアップからリストアし、エラーがデータベースに組み込まれる直前の時点にリカバリする必要があるため、数時間、場合によっては数日かかることがあります。データベースのサイズは絶えず拡大する傾向にあるため、データベース全体の単なるリストアにも数時間または数日かかるようになります。

フラッシュバック・データベースは、Point-in-Time リカバリを実行するための新しい方法です。フラッシュバック・データベースを使用すると、Oracle データベースを以前の時点まで迅速にリカバリし、論理データの破損やユーザー・エラーによる問題を解決できます。変更されたブロックの古いバージョンを取得するには、フラッシュバック・ログを使用します。フラッシュバック・ログに対する考え方の 1 つは、それを連続的なバックアップまたはストレージのスナップショットと考えることです。リカバリの実行が必要な場合は、エラーの前の時点にデータベースをリストアするようにフラッシュバック・ログが迅速に再生され、変更されたブロックのみがリストアされます。この処理は非常に高速で、数時間を要したリカバリ時間が数分に短縮されます。また、使用方法が簡単です。1 つの文を発行するだけで、データベースを午後 2 時 5 分までリカバリできます。データベースをリカバリする前に、そのデータベースのすべてのインスタンスを停止し、その後、インスタンスの 1 つをマウントする必要があります。次に、FLASHBACK DATABASE文の例を示します。

FLASHBACK DATABASE TO TIMESTAMP TIMESTAMP'2002-11-05 14:00:00';

フラッシュバック・データベースを使用する上で、テープからのリストア、長い停止時間、および複雑なリカバリ手続きは必要ありません。フラッシュバック・データベースを使用して、データベースを読取り専用モードでオープンし、その内容を調査することもできます。フラッシュバックした時点が離れすぎているか、または十分に離れていないと判断した場合は、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;

5. データベースをオープンします。

ALTER DATABASE OPEN RESETLOGS;

注意注意注意注意 :

データベースをオープンした後は、リセットログの SCN より前の SCN にフラッシュバックすることはできません。したがって、ALTER DATABASE OPEN RESETLOGS文を発行する前に、データベースが正しい状態であることを確認してください。



フラッシュバック・データベースを使用する際の他の考慮事項は、次のとおりです。

� 十分なフラッシュバック・ログがない場合は、Data Guard（使用可能な場合）またはバックアップからのリストアを使用します。

� データベースをフラッシュバックした後は、スタンバイ・データベースなどの依存しているフラッシュバック・データベースも必要です。第 11 章「フォルト・トレランスのリストア」を参照してください。

フラッシュバック・データベースを使用した削除済表領域の修復フラッシュバック・データベースを使用した削除済表領域の修復フラッシュバック・データベースを使用した削除済表領域の修復フラッシュバック・データベースを使用した削除済表領域の修復フラッシュバック・データベースは、この問題を自動的には解決しませんが、停止時間の大幅な短縮には使用できます。表領域が削除される前の時点に本番データベースをフラッシュバックして、対応するデータファイルのバックアップを影響を受けた表領域からリストアし、表領域が削除される前の時点にリカバリできます。

フラッシュバック・データベースを使用して、削除された表領域を修復するには、次の推奨手順に従います。

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#;

6. データベースをオープンします。

ALTER DATABASE OPEN RESETLOGS;


RAC ローリング・アップグレード

RAC ローリング・アップグレードローリング・アップグレードローリング・アップグレードローリング・アップグレード通常、データベース・ソフトウェアへの 1 回かぎりのパッチまたは暫定的なパッチは、インストール時のソフトウェアの問題に対して既知の修正内容を実装するため、または診断パッチを適用して問題に関する情報を収集するために適用されます。このようなパッチの適用は、多くの場合、計画的なメンテナンス停止の際に実行されます。

Oracle では、Real Application Clusters を使用して、データベース停止時間がほとんど、またはまったくないパッチのローリング・アップグレードを実行する機能が提供されています。ローリング・アップグレードの実行には、opatchコマンドライン・ユーティリティを使用します。

RAC ローリング・アップグレードの利点は、パッチのアップグレードに必要な計画的な停止中でも、RAC インストールの少なくともいくつかのインスタンスを使用できることです。停止する必要があるインスタンスは、その時点でパッチが適用されている RAC インスタンスのみです。他のインスタンスは引き続き使用できます。これは、計画的停止に必要なアプリケーションの停止時間による影響が小限に抑制されることを意味します。Oracle のopatchユーティリティを使用すると、RAC インストールの異なるインスタンスに連続してパッチを適用できます。

ローリング・アップグレードは、Oracle によってローリング・アップグレードへの適格性が証明されたパッチのみ使用できます。通常は、ローリング・アップグレードでインストールできるパッチは、次のとおりです。

� データ・ディクショナリなど、データベースの内容に影響を与えないパッチ

� RAC インターノード通信に関連のないパッチ

� SQL*PLUS、Oracle Utilities、開発ライブラリ、Oracle Net など、クライアント側のツールに関連するパッチ

� カーネル・モジュールのデータファイル・ヘッダー、制御ファイル、共通ヘッダー定義など、共有データベースのリソースを変更しないパッチ

現在、パッチのローリング・アップグレードは 1 回かぎりのパッチにのみ使用できます。パッチ・セットには使用できません。

パッチのローリング・アップグレードは、Oracle Database ソフトウェアが異なるノード間で共有されている配置では使用できません。たとえば、Oracle ホームがクラスタ・ファイル・システム（CFS）上にある場合、またはファイル・サーバーまたは NFS でマウントされたドライブで提供される共有ボリューム上にある場合は使用できません。この機能は、各ノードに Oracle Database ソフトウェアのそれぞれのコピーがある場所にのみ使用できます。


� opatch によるパッチの適用

� opatch によるパッチのロールバック

� opatch を使用したインストール済ソフトウェア・コンポーネントとパッチのリスト

� RAC ローリング・アップグレードの推奨プラクティス



opatch によるパッチの適用によるパッチの適用によるパッチの適用によるパッチの適用opatchユーティリィティは、RAC クラスタのノードにパッチを連続的に適用します。パッチの性質によって、RAC インストールは複合環境で実行できます。データベースの異なるインスタンスを同時に操作したり、一部のインスタンスにはパッチを適用して他のインスタンスには適用しないこともできます。opatchユーティリティは、特定の RAC 配置が実装されているクラスタのノードを自動的に検出します。パッチは、1 度に 1 つずつ各ノードに適用されます。各ノードでは、インスタンスを停止するプロンプトが DBA に表示されます。パッチは、そのノードにインストールされているデータベース・ソフトウェアに適用されます。現行のノードに対するパッチ適用が完了すると、インスタンスを再起動できます。現行のノードにパッチが適用された後、DBA は、パッチを適用する次の RAC ノードを選択できます。インスタンスの停止、パッチの適用、およびインスタンスの起動のサイクルが繰り返されます。したがって、パッチ適用中に停止している必要があるノードは 1 つのみです。

パッチがローリング・パッチかどうかをチェックするには、UNIX プラットフォームで次のコマンドを実行します。

opatch query -is_rolling

（Windows では、opatch.batを実行します。）

プロンプトに従ってパッチの位置を入力します。

RAC クラスタのすべてのノードにパッチを適用するには、次のコマンドを実行します。

opatch apply patch_location

opatchは、パッチがローリング・パッチであることを自動的に認識し、必要な動作を提供します。

ローカル・ノードのみにパッチを適用するには、次のコマンドを入力します。

opatch apply -local patch_location

パッチの適用結果を確認するには、次の位置でログをチェックします。

$ORACLE_HOME/.patch_storage/patch_id/patch_id_Apply_timestamp.log



opatch によるパッチのロールバックによるパッチのロールバックによるパッチのロールバックによるパッチのロールバックopatchユーティリティを使用して、パッチをロールバックできます。DBA は、このユーティリティを使用して、面倒なパッチや不要になったパッチを削除できます。ローリングと同じ手続きで実行できます。

RAC クラスタのすべてのノードのパッチをロールバックするには、次のコマンドを実行します。

opatch rollback -id patch_id -ph patch_location

ローカル・ノードのパッチのみをロールバックするには、次のコマンドを入力します。

opatch rollback -local -id patch_id -ph patch_location

パッチのロールバック結果を確認するには、次の位置でログをチェックします。

$ORACLE_HOME/.patch_storage/patch_id/patch_id_RollBack_timestamp.log

opatch を使用したインストール済ソフトウェア・コンポーネントとパッチを使用したインストール済ソフトウェア・コンポーネントとパッチを使用したインストール済ソフトウェア・コンポーネントとパッチを使用したインストール済ソフトウェア・コンポーネントとパッチのリストのリストのリストのリスト

opatchユーティリィティは、インストールされているソフトウェア・コンポーネントとインストールしたパッチのリストもオプションで提供します。次のコマンドを入力します。

opatch lsinventory

RAC ローリング・アップグレードの推奨プラクティスローリング・アップグレードの推奨プラクティスローリング・アップグレードの推奨プラクティスローリング・アップグレードの推奨プラクティスすべてのデータベース・パッチ・アップグレードについて次のプラクティスをお薦めします。

� パッチが自社の問題点と配置環境に有効であることを必ずオラクル社カスタマ・サポート・センターに確認してください。

� パッチを適用する計画とともに、パッチをバック・アウトする計画も作成してください。

� 初はテスト環境にパッチを適用して、問題が解決されることを検証してください。

� パッチの適用に必要な所要時間を計画する場合は、他のテクノロジ・スタックの層を起動および停止する時間も必要に応じて含めてください。

RAC ローリング・アップグレードの場合には、次のその他のプラクティスをお薦めします。

� 複数のインスタンスが Oracle ホームを共有している場合、パッチの適用はそれらのすべてのインスタンスに影響を与えます。DBA は意図しない副作用が生じないことを検証する必要があります。また、パッチ適用時は、ノードにあるこのようなインスタンスをすべて停止する必要があります。計画的停止の計画には、このことを考慮してください。ベスト・プラクティスとしては、類似したアプリケーションのみがノード上の Oracleホームを共有するようにします。これによって、パッチの柔軟性が高くなります。



� 各ノード上の Oracle インベントリは、ノードにインストールされている Oracle Database ソフトウェアのリポジトリです。インベントリはノードに固有です。ノードにインストールされているすべての Oracle ソフトウェアがそのインベントリを共有します。配置されている Oracle Database ソフトウェア、配置構成およびパッチ・レベルの点で、すべてのノードがまったく同じ場合のみ、インベントリが複数のノードにわたって同じとなります。Oracle インベントリは、パッチの適用とパッチ管理プロセスに非常に役立つため、その整合性を保持することをお薦めします。特定のノード上の Oracleソフトウェアに各パッチをインストールした後は、Oracle インベントリをバックアップする必要があります。この場合、クラスタの各ノードの Oracle インベントリがバックアップ対象となります。

� すべての Oracle データベース・ソフトウェアのインストールには、Oracle Universal Installer を使用します。これによって、関連するリポジトリ・エントリがクラスタの各ノードの Oracle インベントリに作成されます。また、Oracle Universal Installer を使用すると、既存の RAC クラスタにノードを追加することもできます。

ただし、追加しなかった場合またはなんらかの理由で追加できない場合は、attachオプションを指定して opatchユーティリティを実行することで、既存の Oracle Database ソフトウェアのインストールに関する情報を Oracle インベントリに追加できます。ノード情報もこのオプションで追加できます。

� パッチのローリング・アップグレードの性質によって、RAC クラスタの一部のノードのみにパッチを適用できます。したがって、あるインスタンスはパッチを適用した状態で、別のインスタンスはパッチを適用しない状態で動作できます。これは、パッチの非ローリング・アップグレードでは実現できません。RAC 配置がアクティブ化される前に、すべてのインスタンスにパッチの非ローリング・アップグレードを適用します。パッチをすべてのインスタンスに配置する前にパッチのテストが必要な場合は、複合環境が有用です。これを実行するには、-localオプションを指定してパッチを適用する方法をお薦めします。

RAC クラスタのすべてのインスタンスを同じパッチ・レベルで維持するために、パッチが有効になった時点で RAC インストールのすべてのノードにパッチの適用をお薦めします。RAC クラスタのインスタンスに同様のパッチ・ソフトウェアがある場合は、パッチで解決した問題に直面せずにインスタンス間でサービスを移行できます。

� （ローリング・アップグレードで適用されたパッチも含めて）すべてのパッチは、オンラインでメンテナンスし、1 度適用したパッチは削除しないでください。これは、パッチのロールバックが必要な場合、またはパッチを再度適用する必要がある場合に役立ちます。

パッチは、クラスタのすべてのノードがアクセスできる位置に格納する必要があります。したがって、パッチを適用またはロールバックする機能は、クラスタのすべてのノードで同じです。

� 他のパッチ・アップグレードと同様に、パッチのローリング・アップグレードは、ノード上で他のパッチ・アップグレードまたは Oracle インストールが実行されていないときに実行する必要があります。複数のパッチの適用は順次処理です。計画的停止はこれに従って計画する必要があります。



� 複数のパッチを同時に適用する必要があるときに、これらのパッチの一部のみがローリング・アップグレードに適している場合は、すべてのパッチをローリングでない方法で適用してください。これによって、パッチ処理の終了に必要な時間が全体的に短縮されます。

� ローリング・アップグレードに適格でないパッチの場合、RAC 配置のための次善のオプションは applyコマンドの minimize_downtimeオプションです。

� ローリング・アップグレードは、システム使用率が低いときに実行します。これによって、エンド・ユーザーに対するサービスの混乱が小限に抑制されます。

ロジカル・スタンバイ・データベースによるアップグレードロジカル・スタンバイ・データベースによるアップグレードロジカル・スタンバイ・データベースによるアップグレードロジカル・スタンバイ・データベースによるアップグレードロジカル・スタンバイ・データベースを使用すると、わずかな停止時間でデータベース・ソフトウェアおよびパッチ・セットをアップグレードできます。

現在、ロジカル・スタンバイ・データベースが存在していない場合は、使用しているアプリケーションのすべての基本的なデータ型をロジカル・スタンバイ・データベースがサポートしていることを検証します。

初に、ロジカル・スタンバイ・データベースを作成または設置します。図 10-4 に、本番データベースとロジカル・スタンバイ・データベースを示します。これらは両方ともバージョン X のデータベースです。

注意注意注意注意 : この機能は、Oracle9i から Oracle Database 10g へのアップグレードには使用できません。

関連項目関連項目関連項目関連項目 : ロジカル・スタンバイ・データベースによってサポートされるデータ型のリストは、『Oracle Data Guard 概要および管理』を参照してください。

アプリケーションのデータ型のためにロジカル・スタンバイ・データベースを使用できない場合は、『Oracle Database アップグレード・ガイド』に従ってアップグレードを実行してください。



図図図図 10-4 ロジカル・スタンバイ・データベースの設置ロジカル・スタンバイ・データベースの設置ロジカル・スタンバイ・データベースの設置ロジカル・スタンバイ・データベースの設置

次に、SQL Apply プロセスを停止し、ロジカル・スタンバイ・データベースのデータベース・ソフトウェアをバージョン X+1 にアップグレードします。図 10-5 に、バージョン X の本番データベースおよびバージョン X+1 のロジカル・スタンバイ・データベースを示します。

図図図図 10-5 ロジカル・スタンバイ・データベースのバージョンのアップグレードロジカル・スタンバイ・データベースのバージョンのアップグレードロジカル・スタンバイ・データベースのバージョンのアップグレードロジカル・スタンバイ・データベースのバージョンのアップグレード



さらに、SQL Apply を再起動し、本番データベースのバージョン X およびスタンバイ・データベースのバージョン X+1 を稼働させます。図 10-6 のように、構成を混合モードで任意の期間実行して、本番環境でアップグレードを確認できます。

図図図図 10-6 混合モードでの実行混合モードでの実行混合モードでの実行混合モードでの実行

アップグレードされたソフトウェアが適切に動作している場合は、スイッチオーバーを実行してデータベース・ロールを逆にできます。これは数分で切り替わります。アプリケーションがアクティブになるように、データベース・クライアントを新しい本番データベースに切り替えます。なんらかの理由でアプリケーションのサービス・レベルが低下する場合は、以前の本番データベースを再度オープンし、ユーザーを元に切り替えて前述の手順を終了できます。

図 10-7 に示すように、以前のスタンバイ・データベース（バージョン X+1）が本番データベースになり、以前の本番データベース（バージョン X）がスタンバイ・データベースになりました。クライアントは、新しい本番データベースに接続されます。



図図図図 10-7 スイッチオーバーの完了後スイッチオーバーの完了後スイッチオーバーの完了後スイッチオーバーの完了後

新しいスタンバイ・データベースをアップグレードします。図 10-8 に、両方のデータベースがバージョン X+1 にアップグレードされたシステムを示します。

図図図図 10-8 両方のデータベースのアップグレード完了両方のデータベースのアップグレード完了両方のデータベースのアップグレード完了両方のデータベースのアップグレード完了



前述のロール・リバーサルには、次の手順が含まれます。

1. Data Guard スイッチオーバーを開始し、元のスタンバイ・データベースを本番データベースにします。数秒で切り替わります。

2. アプリケーションとサービスがアクティブになるように、データベース・クライアントを新しい本番データベースに切り替えます。なんらかの理由でアプリケーションのサービス・レベルが低下する場合は、以前の本番データベースを再度オープンし、ユーザーを元に切り替えて前述の手順を終了できます。

3. 現行の動作に問題がない場合は、スタンバイ・データベース上のデータベース・ソフトウェアをアップグレードします。

4. 両方のデータベースの互換性レベルを上げます。

オンラインでのオブジェクトの再編成オンラインでのオブジェクトの再編成オンラインでのオブジェクトの再編成オンラインでのオブジェクトの再編成Oracle のオンラインでのオブジェクトの再編成機能は、Oracle8i から採用されました。これらの機能によって、基礎となるデータが変更されている間にもオブジェクトの再編成を実行できます。

表 10-8 に、Oracle Database 10g で使用できるオブジェクトの再編成機能の一部を示します。

オンラインでの表の再編成オンラインでの表の再編成オンラインでの表の再編成オンラインでの表の再編成高い可用性を備えたシステムでは、問合せまたは DML の実行パフォーマンスを改善するために、絶えずアクセスされる大規模な表を絶えず再定義する必要があります。Oracle には、表をオンラインで再定義するための DBMS_REDEFINITION PL/SQL パッケージが用意されています。このパッケージは、表をオフラインにすることが必要な従来の表の再定義方法と比較して、可用性が大幅に向上しています。

表表表表 10-8 オブジェクトの再編成機能の一部オブジェクトの再編成機能の一部オブジェクトの再編成機能の一部オブジェクトの再編成機能の一部

オブジェクトのタイプオブジェクトのタイプオブジェクトのタイプオブジェクトのタイプオブジェクトの再編成によるオブジェクトの再編成によるオブジェクトの再編成によるオブジェクトの再編成によるソリューションの例ソリューションの例ソリューションの例ソリューションの例ソリューションの説明ソリューションの説明ソリューションの説明ソリューションの説明

表 DBMS_REDEFINITIONPL/SQL パッケージ

表をオンラインで再定義するメカニズムを提供する PL/SQL パッケージ

です。

索引索引の再作成以前に使用不可としてマークされた索引を再作成します。

表領域表領域名の変更表領域とその内容を再作成せずに、既存の表領域名を変更可能にします。




オンラインでの索引の再編成オンラインでの索引の再編成オンラインでの索引の再編成オンラインでの索引の再編成索引は、以前の索引定義を使用して、必要に応じて索引を新しい表領域に移動し、オンラインで再作成できます。

オンラインでの表領域の再編成オンラインでの表領域の再編成オンラインでの表領域の再編成オンラインでの表領域の再編成Oracle Database 10g では、列名、表名およびデータファイル名を変更する機能と同様に、表領域名を変更する機能が導入されました。これまで、表領域名を変更する唯一の方法は、表領域を削除してから再作成する方法でした。しかし、この方法は、表領域の内容を削除してから後で再作成する必要があります。オンラインによる表領域名の変更機能を使用することで、ユーザーに対する中断はなくなりました。

ALTER TABLESPACE USERS RENAME TO new_tablespace_name;

Tablespace altered.




フォルト・トレランスのリ

11
フォルト・トレランスのリストアフォルト・トレランスのリストアフォルト・トレランスのリストアフォルト・トレランスのリストア
この章では、障害発生後に、使用している環境に冗長性をリストアする方法を説明します。内容は次のとおりです。

� トレランスの完全なリストア

� RAC クラスタ内の障害のあるノードやインスタンスのリストア

� フェイルオーバー後のスタンバイ・データベースのリストア

� セカンダリ・サイトまたはクラスタ全体の計画的停止の後で行うフォルト・トレランスのリストア

� スタンバイ・データベースでのデータ障害後に行うフォルト・トレランスのリストア

� 本番データベースがリセットログをオープンした後のフォルト・トレランスのリストア

� 二重障害後のフォルト・トレランスのリストア

ストア 11-1

トレランスの完全なリストア

トレランスの完全なリストアトレランスの完全なリストアトレランスの完全なリストアトレランスの完全なリストアHA アーキテクチャ内のコンポーネントに障害が発生すると、アーキテクチャの完全な保護またはフォルト・トレランスが危険にさらされ、そのコンポーネントが修復されるまで、シングル・ポイント障害の可能性が残ります。HA アーキテクチャをフォルト・トレランスに完全にリストアして、RAC、Data Guard または MAA の保護を完全に再構築するには、障害のあるコンポーネントを修復する必要があります。完全なフォルト・トレランスは、計画的停止の間には実行されませんが、修復方法は容易に理解できます。これは、この停止が計画されたもので、リスクが少なく、アプリケーションの可用性の継続に適なときに都合よく発生するためです。ただし、計画外停止の場合は、シングル・ポイント障害にさらされるリスクを十分に理解する必要があります。

この章では、データベースのフォルト・トレランスをリストアするために必要な手順について説明します。内容は次のとおりです。

RAC 環境の場合 :

� RAC クラスタ内の障害のあるノードやインスタンスのリストア

Data Guard 環境および MAA 環境の場合 :

� フェイルオーバー後のスタンバイ・データベースのリストア

� セカンダリ・サイトまたはクラスタ全体の計画的停止の後で行うフォルト・トレランスのリストア

� スタンバイ・データベースでのデータ障害後に行うフォルト・トレランスのリストア

� 二重障害後のフォルト・トレランスのリストア

注意注意注意注意 : 障害発生前に Data Guard Broker を使用していた場合は、Data Guard に関する初期化パラメータの変更前に、Enterprise Manager またはData Guard コマンドライン・インタフェースを使用して構成を削除する必要があります。Data Guard Broker の構成は、フォルト・トレランスのリストア後に再作成します。


RAC クラスタ内の障害のあるノードやインスタンスのリストア

RAC クラスタ内の障害のあるノードやインスタンスのリストアクラスタ内の障害のあるノードやインスタンスのリストアクラスタ内の障害のあるノードやインスタンスのリストアクラスタ内の障害のあるノードやインスタンスのリストア計画的停止および計画外停止のいずれの計画時にも重要なことは、アプリケーション・サービスの迅速かつ自動的なフェイルオーバーが、RAC クラスタ内またはプライマリ・サイトとセカンダリ・サイト間で行われることです。また、エラーや問題の訂正後に、その環境をフォルト・トレランスに完全にリストアするには、RAC クラスタ内またはサイト間のデータベース内の障害のあるインスタンスやノードをリストアするための手順とプロセスを理解することも重要です。

特定コンポーネントの初の障害の原因であった中核の問題を訂正すると、障害のあるノードのクラスタへの追加や障害のある RAC インスタンスの再起動が容易に行えます。ただし、次の点を考慮してください。

� 現在実行中の環境への影響をなくすか、小限に抑えるために、これらのタスクを実行する時期

� フェイルオーバーのために変更され、現在はリセットが必要なネットワーク・コンポーネント（ロード・バランサなど）のリセット

� 既存接続のフェイルバックまたは再バランシング

RAC 環境におけるアプリケーションの実行方法（初のフェイルオーバーに類似）は、ノードやインスタンスのリストア方法の他に、他のプロセスや手順を実行するかどうかも規定します。

初期に発生したノード障害またはインスタンス障害の原因となった問題を訂正した後は、ノードまたはインスタンスの再起動と RAC 環境への追加が常に可能となります。ただし、ノードまたはインスタンスの再結合時に、現在のワークロードにパフォーマンス上の影響を与える場合があります。表 11-1 に、ノードまたはインスタンスの再起動または再結合によるパフォーマンスへの影響の要約を示します。

表表表表 11-1 ノードまたはインスタンスの再起動または再結合によるパフォーマンスへの影響ノードまたはインスタンスの再起動または再結合によるパフォーマンスへの影響ノードまたはインスタンスの再起動または再結合によるパフォーマンスへの影響ノードまたはインスタンスの再起動または再結合によるパフォーマンスへの影響

処置処置処置処置ランタイム・アプリケーションへの影響ランタイム・アプリケーションへの影響ランタイム・アプリケーションへの影響ランタイム・アプリケーションへの影響

ノードの再起動またはクラスタへのノードの再結合

このノードをクラスタに追加しなおすための再構成が発生している間は、パフォーマンスに影響を与える可能性があります。実行中のアプリケーションのパフォーマンスに影響を与える場合と与えない場合がありますが、この影響は評価する必要があります。

RAC インスタンスの再起動

または再結合

RAC インスタンスを再起動する場合は、ロックの再構成が発生している間、パフォー

マンスに影響を与える可能性があります。評価テストでは、現在のアプリケーションへの影響は小限と示されますが、影響は適切なテスト・ワークロードを使用して評価する必要があります。

フォルト・トレランスのリストア 11-3


したがって、ノードまたは RAC インスタンスをリストアする場合には、次の点を検討することが重要です。

� クラスタへのノードの再結合、または Oracle RAC インスタンスの再起動の場合は、ストレスをかけたワークロード下でパフォーマンスへの影響をテストおよび評価します。

� サービス・レベルが許容範囲内で、クラスタ内に 2 つ以上の RAC インスタンスがある場合、障害のあるインスタンスの再結合は、ピーク以外の稼働期間に行うことを検討します。


� サービス可用性のリカバリ

� RAC インスタンスをリストアした後のクライアント接続の考慮点

サービス可用性のリカバリサービス可用性のリカバリサービス可用性のリカバリサービス可用性のリカバリ障害のあるノードをクラスタに戻し、そのインスタンスを起動すると、RAC の Cluster Ready Services（CRS）は、そのノードで使用する仮想 IP アドレスおよびそのノードが自動的にサポートするサービスを自動的に管理します。ある特定のサービスが、リストアされたインスタンスに対して起動できる場合と起動できない場合があります。リストアされたインスタンスに関して CRS がサービスの起動を決定する要因は、そのサービスの構成方法と、そのサービスに対して適切な数のインスタンスがアクセスを現在提供しているかどうかです。初の障害発生時に CRS がサービスを移動した先のインスタンスによってサービスが指定されている場合、そのサービスは優先インスタンスに再配置されません。クラスタ間でサービスへのアクセスを提供するインスタンスの数が、そのサービスに定義されている優先インスタンスの数よりも少ない場合、CRS はリストアされたインスタンスでサービスを再起動します。サービスを再起動した後、CRS は登録されたアプリケーションにサービスの変更を通知します。

たとえば、HR サービスは、優先インスタンスとして A と B を、障害時に使用するインスタンスとして C と D を使用して定義されているとします。インスタンス B に障害が発生し、CRS が HR サービスをインスタンス C で自動的に起動した場合、インスタンス B が再起動されても、HR サービスはインスタンス C に残ります。CRS は優先インスタンスへのサービスの自動再配置は行いません。

別の例を想定します。HR サービスは、優先インスタンス A、B、C および D を使用して定義され、使用可能と定義されたインスタンスはなく、サービスはクラスタ内のすべてのノードに配分されているとします。インスタンス B に障害が発生した場合、HR サービスは残り


� ノードを起動してクラスタに結合しなおす方法の詳細な手順は、ベンダー指定のクラスタ管理ドキュメントを参照してください。

� RAC インスタンスの再起動に関する詳細は、『Oracle Real Application Clusters 管理者ガイド』を参照してください。



の 3 つのノード上で使用可能な状態のままです。この状態の HR サービスは、定義された数よりも少ない数のインスタンスで実行されているため、クラスタが再結合されると、CRS はインスタンス B で HR サービスを自動的に起動します。CRS はアプリケーションに対して、HR サービスがインスタンス B で再び使用可能であることを通知します。

RAC インスタンスをリストアした後のクライアント接続の考慮点インスタンスをリストアした後のクライアント接続の考慮点インスタンスをリストアした後のクライアント接続の考慮点インスタンスをリストアした後のクライアント接続の考慮点RAC インスタンスがリストアされた後は、現行のリソース使用率とシステムのパフォーマンス、アプリケーション構成、および実装されているネットワークのロード・バランシングに応じて、手順の追加が必要になる場合があります。

障害のない RAC インスタンス上の既存の接続（フェイルオーバーまたは新規セッションとして起動）は、再起動されたインスタンスに対して、自動的に再分散またはフェイルバックされません。ユーザーのフェイルバックまたは再分散は、現行のリソース使用率および障害のないインスタンスの機能に応じて、必要がある場合とない場合があります。この機能は、ワークロードに対する許容範囲内の応答時間を適切に処理して提供する機能です。障害のない RAC インスタンスに、全ワークロードの実行または許容範囲内の応答時間を提供するための適切なリソースがない場合は、既存のユーザー接続の一部を再起動したインスタンスに移動（切断および再接続）する必要がある場合があります。

接続時ロード・バランシングが構成されている場合は、必要に応じて、新規接続がも使用頻度の低いノードで起動されます。したがって、新規接続では時間の経過とともに自動的にロード・バランスが実行されます。

アプリケーション・サービスでは、次のことが可能です。

� RAC インスタンスのサブセットで稼働しているサービスでのパーティション化

� すべてのサービスをすべてのノード間で均等に実行するための非パーティション化

これらは、統合されたデータセットを保持しながら、アプリケーションとデータベースの形式および機能をモジュール化する場合に役立ちます。パーティション化されたアプリケーションまたはパーティション化と非パーティション化を組み合せたアプリケーションの場合は、各サービスの応答時間および可用性を検討する必要があります。特定のサービスに対して接続の再分散またはフェイルバックが必要な場合は、DBMS_SERVICE.disconnect_session PL/SQL プロシージャを使用して手動でワークロードを再バランシングできます。このプロシージャを使用すると、サービスの実行中にそのサービスと関連するセッションを切断できます。

複数の RAC インスタンスにわたるアプリケーション・サービスのロード・バランシングには、Oracle Net の接続時フェイルオーバーと接続ロード・バランシングをお薦めします。この機能では、フェイルオーバーまたはリストアに対する変更は必要ありません。また、ハードウェアベースのロード・バランサも使用できます。ただし、個別のアプリケーション・






サービス（Oracle Net Services で理解される）の区別と、インスタンスまたはノードのリストアには制約がある場合があります。たとえば、ノードまたはインスタンスがリストアされ、新規接続の受信を開始できる場合は、リストアされたノードまたはインスタンスをハードウェアベースのロード・バランサの論理に含めるために、手動による手順が必要な場合がありますが、Oracle Net Services では手動による再構成は必要ありません。

表 11-2 に、インスタンスをリストアした後の新規または既存接続に関する考慮点の要約を示します。この考慮点は、アプリケーション・サービスがパーティション化されているかされていないか、またはその組合せであるかによって異なります。リソース使用率および応答時間に応じて、既存の接続の実際の再分散が必要な場合と必要でない場合があります。

図 11-1 に、2 つのノードを持つパーティション化された RAC データベースを示します。各インスタンスは、アプリケーションの異なる部分（HR および営業）を処理します。クライアントは、必要なサービスに基づいて適切なインスタンスへの接続を処理します。

表表表表 11-2 リストアおよび接続フェイルバックリストアおよび接続フェイルバックリストアおよび接続フェイルバックリストアおよび接続フェイルバック

アプリケーション・アプリケーション・アプリケーション・アプリケーション・サービスサービスサービスサービス既存接続のフェイルバックまたはリストア既存接続のフェイルバックまたはリストア既存接続のフェイルバックまたはリストア既存接続のフェイルバックまたはリストア新規接続のフェイルバックまたはリストア新規接続のフェイルバックまたはリストア新規接続のフェイルバックまたはリストア新規接続のフェイルバックまたはリストア

パーティション化既存のセッションはリストアされたインスタンスに自動的に再配置されません。DBMS_SERVICE.disconnect_sessionを使用して手

動でセッションを切断すると、サービスを提供している残りのインスタンスのひとつにそのセッションを再構築できます。

Oracle Net Services の構成を使用すること

で、リストアされたインスタンスに自動的にルーティングされます。

非パーティション化インスタンスをリストアすることはそのロードが低いことを示すため、ロードの再バランシングが必要でないかぎり、処理は必要ありません。ロードの再バランシングが必要な場合は、アプリケーション・サービスがパーティション化された場合と同じ問題が発生します。

Oracle Net Services の構成を使用すること

で、リストアされたインスタンスに（そのインスタンスのロードがも低いため）自動的にルーティングされます。



図図図図 11-1 2 つのノードを持つパーティション化されたつのノードを持つパーティション化されたつのノードを持つパーティション化されたつのノードを持つパーティション化された RAC データベースデータベースデータベースデータベース

図 11-2 に、1 つの RAC インスタンスに障害が発生した場合を示します。



図図図図 11-2 パーティション化されたデータベース内でのパーティション化されたデータベース内でのパーティション化されたデータベース内でのパーティション化されたデータベース内での RAC インスタンスのフェイルオーバーインスタンスのフェイルオーバーインスタンスのフェイルオーバーインスタンスのフェイルオーバー

1 つの RAC インスタンスに障害が発生した場合、そのインスタンスのサービスと既存のクライアント接続は、自動的に別の RAC インスタンスにフェイルオーバーされます。この例では、HR サービスと営業サービスの両方が、残りの RAC インスタンスでサポートされます。また、営業サービスへの新規クライアント接続は、このサービスを現在サポートしているインスタンスにルーティングされます。

障害のあるインスタンスが修復され、図 11-1 に示す状態にリストアされると、営業サービスは、リストアされたインスタンスのフェイルオーバー・クライアントに再配置されます。また、フェイルオーバー・インスタンス上で営業サービスに接続していた新規クライアントは、識別してからフェイルバックする必要がある場合があります。インスタンスがリストアされた後に起動した新規クライアント接続は、自動的に元のインスタンスに接続されます。したがって、時間の経過とともに古い接続が切断され、新規セッションが営業サービスに接



続されて、クライアントのロードがリストアされたインスタンスに移行します。リストア直後のロードの再バランシングは、リソース使用率とアプリケーションの応答時間に応じて異なります。

図 11-3 に、パーティション化されていないアプリケーションを示します。サービスは、両方のアクティブ・インスタンス間で均等に分散されています。各インスタンスには、HR および営業の両方のクライアント接続が混在しています。

図図図図 11-3 パーティション化されていないパーティション化されていないパーティション化されていないパーティション化されていない RAC インスタンスインスタンスインスタンスインスタンス


フェイルオーバー後のスタンバイ・データベースのリストア

1 つの RAC インスタンスで障害が発生すると、CRS は、そのインスタンス上で実行されていたサービスを移動します。また、新規クライアント接続は、その接続に必要なサービスを提供する RAC インスタンスにのみルーティングされます。

障害のあるインスタンスが修復されて、図 11-3 に示す状態にリストアされた後は、一部のクライアントをリストアされたインスタンスに移動する必要がある場合があります。パーティション化されていないアプリケーションの場合は、すべての使用可能なインスタンス間でクライアントのロードを再バランシングするために、適切なサービスを識別する必要はありません。適切なサービスの識別が必要なのは、シングル・インスタンスで要求を適切に処理できない場合のみです。

インスタンスがリストアされた後に起動した新規クライアント接続は、ロードが低いため、リストアされたインスタンスに自動的に接続されます。したがって、時間の経過とともに古い接続が切断され、新規セッションがリストアされたインスタンスに接続されて、クライアントのロードはすべての使用可能な RAC インスタンス間で再び均等にバランス化されます。リストア直後のロードの再バランシングは、リソース使用率とアプリケーションの応答時間に応じて異なります。

フェイルオーバー後のスタンバイ・データベースのリストアフェイルオーバー後のスタンバイ・データベースのリストアフェイルオーバー後のスタンバイ・データベースのリストアフェイルオーバー後のスタンバイ・データベースのリストアフェイルオーバーが必要な本番データベースでの計画外停止の後は、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースが再構築されるまで、フォルト・トレランス全体が危険にさらされます。ただちにデータベース保護を完全にリストアする必要があります。フォルト・トレランスを完全にリストアする手順は、フィジカル・スタンバイ・データベースの場合とロジカル・スタンバイ・データベースの場合でわずかに異なります。

スタンバイ・データベースの再インスタンス化は、Oracle のフラッシュバック・データベース機能があるため必要ありません。フラッシュバック・データベースには、次の機能があります。

� データベースのリストア時間を短縮します。

� フォルト・トレランスのリストアの全般的な複雑さを軽減します。

� 迅速にスタンバイ・データベースが再作成されるため、システムが危険にさらされる時間を短縮します。


� フェイルオーバー後のフィジカル・スタンバイ・データベースのリストア

� フェイルオーバー後のロジカル・スタンバイ・データベースのリストア



フェイルオーバー後のフィジカル・スタンバイ・データベースのリストアフェイルオーバー後のフィジカル・スタンバイ・データベースのリストアフェイルオーバー後のフィジカル・スタンバイ・データベースのリストアフェイルオーバー後のフィジカル・スタンバイ・データベースのリストアフェイルオーバー後にフィジカル・スタンバイ・データベースをリストアするには、次の手順が必要です。この手順では、アーカイブ REDO ログと十分なフラッシュバック・ログ・データがあることを想定しています。

� 手順 1P: STANDBY_BECAME_PRIMARY_SCN の取得

� 手順 2P: 以前の本番データベースのフラッシュバック

� 手順 3P: 以前の本番データベースからの新規スタンバイ・データベースのマウント

� 手順 4P: 新規本番データベースから新規スタンバイ・データベースへのアーカイブ

� 手順 5P: 管理リカバリの起動

手順手順手順手順 1P: STANDBY_BECAME_PRIMARY_SCN の取得の取得の取得の取得新規本番データベースから、次の問合せを実行します。

SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;

この SCN を使用して、以前の本番データベースをスタンバイ・データベースに変換します。

手順手順手順手順 2P: 以前の本番データベースのフラッシュバック以前の本番データベースのフラッシュバック以前の本番データベースのフラッシュバック以前の本番データベースのフラッシュバック以前の本番データベースにログインし、次の文を実行します。

SHUTDOWN IMMEDIATE; /*if necessary */STARTUP MOUNT;FLASHBACK DATABASE TO SCN standby_became_primary_scn;

フラッシュバック・データが不十分な場合は、新規スタンバイ・データベースの作成について『Oracle Data Guard 概要および管理』を参照してください。

手順手順手順手順 3P: 以前の本番データベースからの新規スタンバイ・データベース以前の本番データベースからの新規スタンバイ・データベース以前の本番データベースからの新規スタンバイ・データベース以前の本番データベースからの新規スタンバイ・データベースのマウントのマウントのマウントのマウント新規スタンバイ・データベースのマウントには、次の手順が必要です。

1. フラッシュバック・モードをオフにします。これによって、スタンバイ制御ファイルのリストア後に不要になったフラッシュバック・ログが削除されます。

ALTER DATABASE FLASHBACK OFF;

2. スタンバイ制御ファイルを作成します。

ALTER DATABASE CREATE STANDBY CONTROLFILE AS controlfile_name; SHUTDOWN IMMEDIATE;



3. オペレーティング・システムのコピー・コマンドを発行して、現在の制御ファイルを新規スタンバイ制御ファイルに置換します。

4. 新規スタンバイ・データベースを対応するスタンバイ制御ファイルにマウントします。

STARTUP MOUNT; 5. スタンバイ・リスナーが稼働していることを確認します。

LSNRCTL STAT list_name;

手順手順手順手順 4P: 新規本番データベースから新規スタンバイ・データベースへの新規本番データベースから新規スタンバイ・データベースへの新規本番データベースから新規スタンバイ・データベースへの新規本番データベースから新規スタンバイ・データベースへのアーカイブアーカイブアーカイブアーカイブ新規スタンバイ・データベースの作成前は、現在の本番リモート・スタンバイ・アーカイブ先がエラーで停止しており、リモート宛先へのファイル送信も停止している可能性があります。リモート・アーカイブを再起動するには、スタンバイ・アーカイブ先を再び有効にする必要があります。

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;

REDO ログ・ファイルを切り替えて、正常に送信されたことを検証します。

ALTER SYSTEM SWITCH LOGFILE;SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR, SRL FROM V$ARCHIVE_DEST_STATUS;

新規本番データベースからのアーカイブ REDO ログの送信によって、スタンバイ・データベースには、新規本番データベースのインカネーション番号が通知されます。

手順手順手順手順 5P: 管理リカバリの起動管理リカバリの起動管理リカバリの起動管理リカバリの起動次の文のいずれかを使用して、管理リカバリを起動するか、またはリアルタイムで適用します。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

または

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

リカバリでアーカイブ REDO ログが適用されていることを確認します。

SELECT * FROM V$MANAGED_STANDBY;



手順手順手順手順 6P: End-of-Redo マーカー発生後のマーカー発生後のマーカー発生後のマーカー発生後の MRP の再起動の再起動の再起動の再起動管理リカバリ・プロセス（MRP）は End-of-Redo マーカーが発生すると停止します。このマーカーには、REDO ストリームで Data Guard のフェイルオーバーが完了した時間が記録されます。この停止はエラーではありません。再起動した MRP は問題なく継続されます。

フェイルオーバー後のロジカル・スタンバイ・データベースのリストアフェイルオーバー後のロジカル・スタンバイ・データベースのリストアフェイルオーバー後のロジカル・スタンバイ・データベースのリストアフェイルオーバー後のロジカル・スタンバイ・データベースのリストアフェイルオーバー後にロジカル・スタンバイ・データベースをリストアするには、次の手順が必要です。

� 手順 1L: END_PRIMARY_SCN の取得

� 手順 2L: 以前の本番データベースのフラッシュバック

� 手順 3L: 新規ロジカル・スタンバイ・データベースのオープンと SQL Apply の起動

手順手順手順手順 1L: END_PRIMARY_SCN の取得の取得の取得の取得新規本番データベース上で、以前のスタンバイ・データベースが新規本番データベースになったときの SCN を問い合せます。

SELECT VALUE AS TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM DBA_LOGSTDBY_PARAMETERSWHERE NAME = 'END_PRIMARY_SCN';

手順手順手順手順 2L: 以前の本番データベースのフラッシュバック以前の本番データベースのフラッシュバック以前の本番データベースのフラッシュバック以前の本番データベースのフラッシュバック新規ロジカル・スタンバイ・データベースは、以前の本番データベースをマウントし、それを STANDBY_BECAME_PRIMARY_SCNにフラッシュバックした後、以前のガード・レベルの設定を有効にすることで作成できます。

SHUTDOWN IMMEDIATE;STARTUP MOUNT;FLASHBACK DATABASE TO SCN standby_became_primary_scn;ALTER DATABASE GUARD [ALL | STANDBY | NONE];

手順手順手順手順 3L: 新規ロジカル・スタンバイ・データベースのオープンと新規ロジカル・スタンバイ・データベースのオープンと新規ロジカル・スタンバイ・データベースのオープンと新規ロジカル・スタンバイ・データベースのオープンと SQL Apply の起動の起動の起動の起動ALTER DATABASE OPEN RESETLOGS;ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY dblink;

新規ロジカル・スタンバイ・データベースから新規本番データベースへのデータベース・リンクが存在しない場合は、そのデータベース・リンクを作成する必要があります。次の構文を使用します。

CREATE PUBLIC DATABASE LINK dblink CONNECT TO system IDENTIFIED BY password USING 'service_name_of_new_primary_database';


セカンダリ・サイトまたはクラスタ全体の計画的停止の後で行うフォルト・トレランスのリストア

セカンダリ・サイトまたはクラスタ全体の計画的停止の後でセカンダリ・サイトまたはクラスタ全体の計画的停止の後でセカンダリ・サイトまたはクラスタ全体の計画的停止の後でセカンダリ・サイトまたはクラスタ全体の計画的停止の後で行うフォルト・トレランスのリストア行うフォルト・トレランスのリストア行うフォルト・トレランスのリストア行うフォルト・トレランスのリストア

セカンダリ・サイトの計画的停止またはクラスタ全体の計画的停止の後でフォルト・トレランスを完全にリストアするには、次の手順が必要です。

� 手順 1: スタンバイ・データベースの起動

� 手順 2: リカバリの起動

� 手順 3: 本番データベースでのログ転送サービスの検証

� 手順 4: スタンバイ・データベースでのリカバリ進行の検証

� 手順 5: 本番データベースの保護モードのリストア

手順手順手順手順 1: スタンバイ・データベースの起動スタンバイ・データベースの起動スタンバイ・データベースの起動スタンバイ・データベースの起動セカンダリ・サイトのデータが破損している場合は、ローカル・バックアップ、ローカル・テープ・バックアップ、またはプライマリ・サイトのバックアップからスタンバイ・データベースをリストアする必要がある場合があります。新規本番データベースからスタンバイ・データベースを再作成するには、『Oracle Data Guard 概要および管理』にあるスタンバイ・データベースの作成手順に従います。

スタンバイ・データベースが再構築された後に、スタンバイ・データベースを起動します。

手順手順手順手順 2: リカバリの起動リカバリの起動リカバリの起動リカバリの起動

スタンバイ・データベースのスタンバイ・データベースのスタンバイ・データベースのスタンバイ・データベースのタイプタイプタイプタイプ SQL 文文文文

フィジカル STARTUP MOUNT;

ロジカル STARTUP;


フィジカル RECOVER MANAGED STANDBY DATABASE DISCONNECT;

ロジカル ALTER DATABASE START LOGICAL STANDBY APPLY;


セカンダリ・サイトまたはクラスタ全体の計画的停止の後で行うフォルト・トレランスのリストア

手順手順手順手順 3: 本番データベースでのログ転送サービスの検証本番データベースでのログ転送サービスの検証本番データベースでのログ転送サービスの検証本番データベースでのログ転送サービスの検証本番データベースのリモート・アーカイブ先を再び有効にする必要がある場合があります。初に 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 SWITCH LOGFILE;

本番データベースとスタンバイ・データベースの間のログ転送サービスを、エラーをチェックすることで検証します。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';

手順手順手順手順 4: スタンバイ・データベースでのリカバリ進行の検証スタンバイ・データベースでのリカバリ進行の検証スタンバイ・データベースでのリカバリ進行の検証スタンバイ・データベースでのリカバリ進行の検証フィジカル・スタンバイ・データベースの場合は、管理リカバリ・プロセスでエラーがないこと、およびリカバリでアーカイブ REDO ログが適用されていることを検証します。

SELECT MAX(SEQUENCE#), THREAD# FROM V$LOG_HISTORY GROUP BY THREAD;SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, CLIENT_PROCESS FROM V$MANAGED_STANDBY;

ロジカル・スタンバイ・データベースの場合は、ロジカル・スタンバイ・プロセスでエラーがないこと、およびリカバリでアーカイブ 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];

関連項目関連項目関連項目関連項目 : 7-25 ページ「データ保護モードの変更」


スタンバイ・データベースでのデータ障害後に行うフォルト・トレランスのリストア

スタンバイ・データベースでのデータ障害後に行うフォルト・スタンバイ・データベースでのデータ障害後に行うフォルト・スタンバイ・データベースでのデータ障害後に行うフォルト・スタンバイ・データベースでのデータ障害後に行うフォルト・トレランスのリストアトレランスのリストアトレランスのリストアトレランスのリストア

全体または部分的なリストアが必要なスタンバイ・データベースでの計画外停止（データやメディアの障害など）の後は、そのスタンバイ・データベースが処理に戻るまで、フォルト・トレランス全体が危険にさらされます。ただちにデータベース保護を完全にリストアする必要があります。Hardware Assisted Resilient Database の構成を使用すると、このタイプの問題を防ぐことができます。

スタンバイ・データベースのデータ障害後にフォルト・トレランスを完全にリストアするには、次の手順が必要です。

� 手順 1: 停止原因の修正

� 手順 2: 影響を受けたデータファイルのバックアップのリストア

� 手順 3: 必要なアーカイブ REDO ログ・ファイルのリストア

� 手順 5: リカバリまたは適用の開始

� 手順 6: 本番データベースでのログ転送サービスの検証

� 手順 7: スタンバイ・データベースでのリカバリ進行または適用進行の検証

� 手順 8: 本番データベースの保護モードのリストア

手順手順手順手順 1: 停止原因の修正停止原因の修正停止原因の修正停止原因の修正停止の根本原因を調査し、問題の再発を防ぐための対策をたてる必要があります。

手順手順手順手順 2: 影響を受けたデータファイルのバックアップのリストア影響を受けたデータファイルのバックアップのリストア影響を受けたデータファイルのバックアップのリストア影響を受けたデータファイルのバックアップのリストア影響を受けたデータファイルのみをスタンバイ・サイトにリストアする必要があります。




手順手順手順手順 3: 必要なアーカイブ必要なアーカイブ必要なアーカイブ必要なアーカイブ REDO ログ・ファイルのリストアログ・ファイルのリストアログ・ファイルのリストアログ・ファイルのリストアリストアされたデータファイルを構成されたタイムラグまでリカバリするには、アーカイブREDO ログをリストアする必要があります。

フィジカル・スタンバイ・データベースについては、次の事項を考慮してください。

� リカバリに必要なアーカイブ REDO ログが、構成されたアーカイブ先のスタンバイ・システムにある場合は、管理リカバリ・プロセスがそれらを自動的に検出し、必要に応じて適用します。リストアは必要ありません。

� 必要なアーカイブ REDO ログがスタンバイ・システムからは削除されていますが、本番システムでは使用可能な場合は、フェッチ・アーカイブ・ログ（FAL）プロセスが自動的に起動し、必要なアーカイブ REDO ログをスタンバイ・システムに送信します。リストアは必要ありません。

ロジカル・スタンバイ・データベースについては、影響を受けたファイルに対して完全なメディア・リカバリを開始します。次の事項を考慮してください。

� リカバリに必要なアーカイブ REDO ログが、構成されたアーカイブ先のスタンバイ・システムにある場合は、リカバリ・プロセスがそれらを自動的に検出し、必要に応じて適用します。リストアは必要ありません。

� 必要なアーカイブ REDO ログがスタンバイ・システムから削除されている場合は、その内容をスタンバイ・システムにリストアする必要があります。必要なアーカイブ REDOログを使用可能にした後、影響を受けたファイルに対するメディア・リカバリを完了させます。

手順手順手順手順 4: スタンバイ・データベースの起動スタンバイ・データベースの起動スタンバイ・データベースの起動スタンバイ・データベースの起動スタンバイ・データベースが再構築された後に、スタンバイ・データベースを起動します。

手順手順手順手順 5: リカバリまたは適用の開始リカバリまたは適用の開始リカバリまたは適用の開始リカバリまたは適用の開始


フィジカル STARTUP MOUNT;

ロジカル STARTUP;


フィジカル RECOVER MANAGED STANDBY DATABASE DISCONNECT;

ロジカル ALTER DATABASE START LOGICAL STANDBY APPLY;



手順手順手順手順 6: 本番データベースでのログ転送サービスの検証本番データベースでのログ転送サービスの検証本番データベースでのログ転送サービスの検証本番データベースでのログ転送サービスの検証新規本番データベースでのログ転送サービスは、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';

手順手順手順手順 7: スタンバイ・データベースでのリカバリ進行または適用進行の検証スタンバイ・データベースでのリカバリ進行または適用進行の検証スタンバイ・データベースでのリカバリ進行または適用進行の検証スタンバイ・データベースでのリカバリ進行または適用進行の検証フィジカル・スタンバイ・データベースの場合は、管理リカバリ・プロセスでエラーがないこと、およびリカバリでアーカイブ REDO ログが適用されていることを検証します。

SELECT MAX(SEQUENCE#), THREAD# FROM V$LOG_HISTORY GROUP BY THREAD;SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, CLIENT_PROCESS FROM V$MANAGED_STANDBY;

ロジカル・スタンバイ・データベースの場合は、ロジカル・スタンバイ・プロセスでエラーがないこと、およびリカバリでアーカイブ REDO ログが適用されていることを検証します。

SELECT THREAD#, SEQUENCE# SEQ# FROM DBA_LOGSTDBY_LOG LOG, DBALOGSTDBY_PROGRESS PROG WHERE PROG.APPLIED_SCN BETWEEN LOG.FIRST_CHANGE# AND LOG.NEXT_CHANGE# ORDER BY NEXT_CHANGE#;

手順手順手順手順 8: 本番データベースの保護モードのリストア本番データベースの保護モードのリストア本番データベースの保護モードのリストア本番データベースの保護モードのリストアスタンバイ・データベースの停止のために、本番データベースの保護モードを大保護から、大可用性または大パフォーマンスのいずれかに変更する必要があった場合は、ビジネス要件に応じて本番データベースの保護モードを大保護に戻します。

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE [PROTECTION | AVAILABILITY];



本番データベースがリセットログをオープンした後のフォル本番データベースがリセットログをオープンした後のフォル本番データベースがリセットログをオープンした後のフォル本番データベースがリセットログをオープンした後のフォルト・トレランスのリストアト・トレランスのリストアト・トレランスのリストアト・トレランスのリストア

論理エラーを訂正するためにフラッシュバックされたか、またはリストアされ、ある時点までリカバリされたことが原因で、本番データベースがアクティブ化されている場合は、対応するスタンバイ・データベースにメンテナンスの追加が必要な場合があります。本番データベースでのリカバリがリセットログなしで完了した場合、追加の作業は必要ありません。

本番データベースをアクティブにした後で、次の表に示す問合せを実行します。

使用例使用例使用例使用例 1: スタンバイのスタンバイのスタンバイのスタンバイの SCN が本番のリセットログが本番のリセットログが本番のリセットログが本番のリセットログ SCN より遅いより遅いより遅いより遅い

データベースデータベースデータベースデータベース問合せ問合せ問合せ問合せ

本番データベース SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE;

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

SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE;

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

SELECT APPLIED_SCN FROM DBA_LOGSTDBY_PROGRESS;

データベースデータベースデータベースデータベース処置処置処置処置


1. スタンバイ・データベースが新しいアーカイブ REDO ログ・

ファイルを本番データベースから受信したことを確認します。

2. リカバリを再開します。


スタンバイ・データベースが新しいアーカイブ REDO ログ・ファイ

ルを本番データベースから受信したことを確認します。11-15 ペー

ジの「手順 3: 本番データベースでのログ転送サービスの検証」を参

照してください。



使用例使用例使用例使用例 2: スタンバイのスタンバイのスタンバイのスタンバイの SCN が本番のリセットログが本番のリセットログが本番のリセットログが本番のリセットログ SCN より早いより早いより早いより早い

データベースデータベースデータベースデータベース処置処置処置処置


1. スタンバイ・データベースが新しいアーカイブ REDO ログ・

ファイルを本番データベースから受信したことを確認します。

2. リセットログの発生より 2SCN 前の SCN にデータベースをフ

ラッシュバックします。

SHUTDOWN IMMEDIATE; /* if necessary */STARTUP MOUNT;FLASHBACK DATABASE TO SCN resetlogs_change#_minus_2;

3. リカバリを再起動します。11-12 ページの「手順 5P: 管理リカ

バリの起動」を参照してください。


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;

4. リセットログを使用して、ロジカル・スタンバイ・データベースをオープンします。

SHUTDOWN;STARTUP MOUNT EXCLUSIVE;ALTER DATABASE OPEN RESETLOGS;

5. プライマリ・データベースの現行ログをアーカイブします。

ALTER SYSTEM ARCHIVE LOG CURRENT;

6. SQL Apply を起動します。

ALTER DATABASE START LOGICAL STANDBY APPLY;


二重障害後のフォルト・トレランスのリストア

二重障害後のフォルト・トレランスのリストア二重障害後のフォルト・トレランスのリストア二重障害後のフォルト・トレランスのリストア二重障害後のフォルト・トレランスのリストアスタンバイ・データベースと本番データベースの両方に影響を与える二重障害が発生した場合は、初に本番データベースを再作成する必要があります。これらのサイトは同一なため、新のバックアップがある場所に本番データベースを作成できます。

表 11-3 に、使用可能なバックアップのタイプに応じたリカバリ計画を示します。

本番データベースを再作成した後は、『Oracle Data Guard 概要および管理』にある新規スタンバイ・データベースの作成手順に従います。

表表表表 11-3 本番データベースとスタンバイ・データベースの再作成本番データベースとスタンバイ・データベースの再作成本番データベースとスタンバイ・データベースの再作成本番データベースとスタンバイ・データベースの再作成

使用可能なバックアップ使用可能なバックアップ使用可能なバックアップ使用可能なバックアップ本番データベースの再作成本番データベースの再作成本番データベースの再作成本番データベースの再作成

本番データベースとスタンバイ・データベースのローカル・バックアップ

本番データベースからバックアップをリストアします。このデータベースを新しい本番データベースとしてリカバリおよびアクティブにします。

スタンバイ・データベースのローカル・バックアップのみ。スタンバイ・データベースのテープ・バックアップ

ローカル・スタンバイ・バックアップをスタンバイ・データベースにリストアします。このデータベースを新しい本番データベースとしてリカバリおよびアクティブにします。

テープ・バックアップのみテープ・バックアップをローカルでリストアします。このデータベースを新しい本番データベースとしてリカバリおよびアクティブにします。


二重障害後のフォルト・トレランスのリストア


Hardware Assisted Resilient Data（HARD）Ini

A
Hardware Assisted Resilient Data（（（（HARD））））
Initiative

tiative A-1

HARD 準拠のストレージによるデータ破損の防止

HARD 準拠のストレージによるデータ破損の防止準拠のストレージによるデータ破損の防止準拠のストレージによるデータ破損の防止準拠のストレージによるデータ破損の防止オラクル社は、Hardware Assisted Resilient Data（HARD）Initiative を導入しています。このプログラムは、データ破損を未然に防止するために設計されています。データ破損が発生することはほとんどありませんが、発生した場合は、データベースおよびビジネスに致命的な影響を与える可能性があります。

HARD Initiative のもとで、オラクル社は、選ばれたシステム・ベンダーとストレージ・ベンダーと協力して、早期に破損を検出し、破損したデータのディスクへの書込みを防止するオペレーティング・システムとストレージ・コンポーネントの構築に取り組み続けています。主な方法はブロック・チェックで、ストレージ・サブシステムによって Oracle ブロックの内容を検証します。この機能の実装は、ハードウェア・ベンダーにかかわらず、エンド・ユーザーや DBA に対して透過的です。

HARD の検証機能を使用するには、すべてのデータファイルとログ・ファイルを HARD 準拠のストレージに配置します。また、ベンダー提供のインタフェースを使用して、ストレージ上で HARD の検証機能を有効にする必要があります。Oracle 製品でデータをストレージに書き込むと、ストレージ・システムによってデータが検証されます。データが破損しているような場合は、エラーとなり書込みが拒否されます。

図図図図 A-1 Oracle データの検証データの検証データの検証データの検証

A-2　Oracle 高可用性アーキテクチャおよびベスト・プラクティス

HARD による対処の対象となるデータ破損のタイプ

データ破損データ破損データ破損データ破損データの破損には、多くの原因が考えられます。ディスク上のビットフリップは、データベース、オペレーティング・システム、ストレージ・エリア・ネットワーク（SAN）またはストレージ・システムのソフトウェアの不具合によるものです。データ破損の防止や修復がない場合は、データベースの停止や重要なビジネス・データの消失となります。

Oracle には、データ破損の検出とそのリカバリに関する高度な技術が用意されています。この技術には、ブロックレベル・リカバリ、自動バックアップと自動リストア、表領域のPoint-in-Time リカバリ、リモート・スタンバイ・データベース、およびトランザクション・リカバリが含まれます。ただし、破損のリカバリには長時間がかかります。さらに、重要なデータの破損は、データベース全体の障害の原因となる可能性があります。初に考慮することは、データ破損を防ぐことです。HARD には、ビジネス・データの破損を防ぐためのメカニズムが用意されています。

Oracle の Maximum Availability Architecture（MAA）には、Oracle RAC、Oracle Data Guard および HARD を使用して、停止の影響を軽減するインフラストラクチャが示されています。

HARD による対処の対象となるデータ破損のタイプによる対処の対象となるデータ破損のタイプによる対処の対象となるデータ破損のタイプによる対処の対象となるデータ破損のタイプHARD プログラムでは、保護を複数のレベルで定義しています。Oracle ストレージ・パートナは、ファームウェアまたはハードウェアのチェック項目を実装できます。これらのチェックによって、次のタイプの破損を防止できます。

� 破損したブロックの書込み

Oracle で書き込まれたデータが、ディスクに到達する前に、付随的な一部のオペレーティング・システムやハードウェア・コンポーネントによって破損する場合です。これらのコンポーネントには、オペレーティング・システム、ファイル・システム、ボリューム・マネージャ、デバイス・ドライバ、ホスト・バス・アダプタ、SAN ファブリック・スイッチなどがあります。Oracle ではデータの読取り時に破損を検出できますが、Oracle がそのデータを読み込むのは数日後または数か月後の場合があります。それまでには、データのリカバリに適したバックアップが使用できなくなる可能性があります。

� 不適切な位置へのブロックの書込み

Oracle では、ディスク上の指定位置への書込みを発行します。なんらかの原因で、オペレーティング・システムまたはストレージ・システムによって、そのブロックが誤った位置に書き込まれます。この書込みは、2 つの破損の原因となります。つまり、ディスク上の有効なデータの破損およびコミットしたトランザクションからのデータの消失です。

Hardware Assisted Resilient Data（HARD）Initiative A-3

HARD で実行可能なチェック項目

� Oracle 以外のプログラムによる Oracle データへの誤った書込み

Oracle データファイルは、Oracle 以外のアプリケーションによって上書きされる可能性があります。Oracle 以外のプロセスやプログラムによって、Oracle データファイルの内容が偶発的に上書きされます。この原因は、アプリケーション・ソフトウェアやオペレーティング・システムの不具合か、または人的ミス（たとえば、通常のオペレーティング・システムのファイルを Oracle データファイルに偶発的にコピーした場合）にあります。

� 破損したサード・パーティのバックアップ

バックアップをテープにコピーするときに、データ破損が発生する場合があります。このバックアップがデータ破損の修復に使用されるため、このタイプの破損は特に致命的です。そのため、このバックアップも破損した場合、消失したデータをリカバリする方法はありません。この状態は、特にサード・パーティのバックアップの場合（データが、ディスク・ストレージ・ユニットからバックアップ・デバイスに、Oracle を経由せず直接コピーされる）に当てはまります。

HARD で実行可能なチェック項目で実行可能なチェック項目で実行可能なチェック項目で実行可能なチェック項目Oracle HARD の機能を実装したストレージ・システムでは、Oracle サーバーによる、多数のチェック項目を使用した Oracle のブロック構造、ブロック整合性およびブロック位置の検証が可能です。書込み時にブロックが検証に失敗した場合は、ストレージによって書込みが拒否され、データの整合性が保護されます。また、一時的にデータを一貫性のない状態にする可能性があるシステム管理の操作中には、HARD の妥当性チェックを選択的に使用禁止にできます。

次の Oracle オブジェクトは、I/O 書込み中に検証できます。

� データファイル

� 制御ファイル

� REDO ログ

� アーカイブ REDO ログ

� Recovery Manager バックアップ・ピース

� フラッシュバック・ログ

� 変更トラッキング・ファイル

� ASM メタデータ

� Oracle Cluster Registry ファイル

� Data Guard Broker 構成ファイル



HARD を使用する DBA およびシステム管理者は、HARD のエラーが I/O エラーとしてORACLE インスタンスにレポートされることに注意する必要があります。システム管理者は、リカバリ処理を開始する前に、HARD 対応のストレージをチェックするためのシステム・ログを慎重にチェックする必要があります。

Automatic Storage Management（ASM）再バランシングは、HARD 実装で現在サポートされていません。ASM 再バランシングは、データ・ブロックより大きく、HARD チェックの対象とならない擬似文字が含まれる可能性があるディスク・ブロック全体を移動します。これによって、誤った HARD 検証エラーが発生する場合があります。

ストレージ・ベンダーは、自社製品に一部またはすべてのチェック項目を実装できます。また、各ベンダーの実装は独自のもので、それぞれの制御インタフェースには異なる機能を指定できます。新のベンダー情報および実装情報は、HARD Initiative のページを参照してください。

http://otn.oracle.com/deploy/availability/index.html

Hardware Assisted Resilient Data（HARD）Initiative A-5

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

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

この付録に含まれる表とファイルのサンプルは、様々な HA アーキテクチャに関係するため、ベスト・プラクティスを示しています。また、これらのサンプルは、動的なサービス登録について、データベースのサーバー・パラメータ・ファイル（SPFILE）と Oracle Net 構成の関係も明確にします。

この付録には、次の表とサンプル・ファイルが含まれています。

� SPFILE のサンプル

– 表 B-1「プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースに関する一般的な SPFILE パラメータ」

– 表 B-2「プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースに関する RAC の SPFILE パラメータ」

– 表 B-3「プライマリ・データベースおよびフィジカル・スタンバイ・データベースのみに関する Data Guard の SPFILE パラメータ」

– 表 B-4「プライマリ・データベースおよびロジカル・スタンバイ・データベースのみに関する Data Guard の SPFILE パラメータ」

– 表 B-5「プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースに関する Data Guard の SPFILE パラメータ」

– 表 B-6「大パフォーマンス・モードに関する Data Guard の SPFILE パラメータ」

のサンプル B-1

� Oracle Net 構成ファイル

– 動的インスタンス登録を使用する全ホストの SQLNET.ORA ファイルのサンプル

– 動的インスタンス登録を使用する全ホストの LISTENER.ORA ファイルのサンプル

– 動的インスタンス登録を使用する全ホストの TNSNAMES.ORA ファイルのサンプル

これらの表とファイルは、次の構成で示されます。

� ORACLE_BASE=/mnt/app/oracle

� データベースのフラッシュ・リカバリ領域は、/flash_recoveryです。

B-2　Oracle 高可用性アーキテクチャおよびベスト・プラクティス

SPFILE のサンプル

SPFILE のサンプルのサンプルのサンプルのサンプルこの項の表は、データベース、RAC、および Data Guard のパラメータ・ファイルの値を表します。一部のパラメータは、一般的なデータベースのパラメータ表と RAC のパラメータ表の両方に示されています。RAC を使用している場合は、一般的なデータベースのパラメータ表にある値ではなく、RAC パラメータ表の値を使用する必要があります。

これらのパラメータは、シカゴにあるデータベースの構成、およびボストンにあるフィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースのオプションを示します。プライマリ・データベースは、SALESデータベースです。シングル・インスタンスのデータベースの場合、ORACLE_SIDパラメータの値は、SALES、SALES_PHYSおよびSALES_LOGです。RAC の構成では、対応するインスタンス番号が、ORACLE_SIDパラメータの値ごとに追加されます。

注意注意注意注意 : Oracle Data Guard の大可用性モードまたは大保護モードでは、LOG_ARCHIVE_DEST_n初期化パラメータのLGWR SYNC=NOPARALLELオプションは決して使用しないことをお薦めします。常にデフォルトの SYNC=PARALLELを使用してください。スタンバイ・インスタンスが失敗した後の障害検出は、LOG_ARCHIVE_DEST_n初期化パラメータの NET_TIMEOUTオプションで指定された時間内に発生します。さらに、ほとんどの構成では NET_ TIMEOUTを 30 秒に設定することをお薦めします。

表表表表 B-1 プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データプライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データプライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データプライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データ

ベースに関する一般的なベースに関する一般的なベースに関する一般的なベースに関する一般的な SPFILE パラメータパラメータパラメータパラメータ

シカゴ（プライマリ・データベース）シカゴ（プライマリ・データベース）シカゴ（プライマリ・データベース）シカゴ（プライマリ・データベース）ボストン（フィジカル・スタンバイ・ボストン（フィジカル・スタンバイ・ボストン（フィジカル・スタンバイ・ボストン（フィジカル・スタンバイ・データベース）データベース）データベース）データベース）

ボストン（ロジカル・スタンバイ・ボストン（ロジカル・スタンバイ・ボストン（ロジカル・スタンバイ・ボストン（ロジカル・スタンバイ・データベース）データベース）データベース）データベース）

*.COMPATIBLE='10.1.0' シカゴと同様シカゴと同様

*.LOG_ARCHIVE_FORMAT='arch_%t_%S_%r.log'

シカゴと同様シカゴと同様

*.LOG_ARCHIVE_TRACE=0 シカゴと同様シカゴと同様

*.REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE


*.LOG_CHECKPOINT_INTERVAL=0 シカゴと同様シカゴと同様

*.LOG_CHECKPOINT_TIMEOUT=0 シカゴと同様シカゴと同様

*.LOG_CHECKPOINTS_TO_ALERT=TRUE


*.DB_BLOCK_CHECKING=TRUE シカゴと同様シカゴと同様

*.DB_BLOCK_CHECKSUM=TRUE シカゴと同様シカゴと同様

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


*.TIMED_STATISTICS=TRUE シカゴと同様シカゴと同様

*.LOCAL_LISTENER='SALES_lsnr'


*.REMOTE_LISTENER='SALES_remotelsnr_CHICAGO'

*.REMOTE_LISTENER='SALES_remotelsnr_BOSTON'

*.REMOTE_LISTENER='SALES_remotelsnr_BOSTON'

*.DB_RECOVERY_FILE_DEST=/flash_recovery


*.DB_RECOVERY_FILE_DEST_SIZE=100G


*.DB_FLASHBACK_RETENTION_TARGET=240


*.UNDO_MANAGEMENT=AUTO シカゴと同様シカゴと同様

*.UNDO_RETENTION=900 シカゴと同様シカゴと同様

*.UNDO_TABLESPACE='rbs01' シカゴと同様シカゴと同様

*.DB_NAME='SALES' シカゴと同様 *.DB_NAME='SALES_LOG'

*.SERVICE_NAME='SALES_CHICAGO'

*.SERVICE_NAME='SALES_BOSTON'

*.SERVICE_NAME='SALES_BOSTON'

*.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'

*.CLUSTER_DATABASE=FALSE シカゴと同様シカゴと同様

*.CONTROL_FILES='/oradata/SALES/SALES_cntr01','/oradata/SALES/SALES_cntr02'

*.CONTROL_FILES='/oradata/SALES/SALES_cntr01','/oradata/SALES/SALES_cntr02'

*.CONTROL_FILES='/oradata/SALES_LOG/SALES_cntr01','/oradata/SALES_LOG/SALES_cntr02'

*.DB_FILE_NAME_CONVERT='/SALES_LOG/','/SALES/'

シカゴと同様 *.DB_FILE_NAME_CONVERT='/SALES/','/SALES_LOG/'


ベースに関する一般的なベースに関する一般的なベースに関する一般的なベースに関する一般的な SPFILE パラメータパラメータパラメータパラメータ（続き）（続き）（続き）（続き）





*.LOG_FILE_NAME_CONVERT='/SALES_LOG/','/SALES/'

シカゴと同様 *.LOG_FILE_NAME_CONVERT='/SALES/','/SALES_LOG/'

*.STANDBY_FILE_MANAGEMENT=AUTO


*.CONTROL_FILE_RECORD_KEEP_TIME=30


*.RESUMABLE_TIMEOUT=900 シカゴと同様シカゴと同様

SALES_CHICAGO SALES_BOSTON SALES_BOSTON_LOG


ベースに関するベースに関するベースに関するベースに関する RAC のののの SPFILE パラメータパラメータパラメータパラメータ



*.CLUSTER_DATABASE=TRUE シカゴと同様シカゴと同様

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_BOSTON1

SALES2.INSTANCE_NAME=SALES_CHICAGO2

SALES_PHYS2.INSTANCE_NAME=SALES_BOSTON2

SALES_LOG2.INSTANCE_NAME=SALES_BOSTON2

SALES1.UNDO_TABLESPACE='rbs01'

SALES_PHYS1.UNDO_TABLESPACE='rbs01'

SALES_LOG1.UNDO_TABLESPACE='rbs01'

SALES2.UNDO_TABLESPACE='rbs02'

SALES_PHYS2.UNDO_TABLESPACE='rbs02'

SALES_LOG2.UNDO_TABLESPACE='rbs02'

*.STANDBY_FILE_MANAGEMENT=MANUAL


表表表表 B-1 プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データプライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データプライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データプライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースに関する一般的なベースに関する一般的なベースに関する一般的なベースに関する一般的な SPFILE パラメータパラメータパラメータパラメータ（続き）（続き）（続き）（続き）





表表表表 B-3 プライマリ・データベースおよびフィジカル・スタンバイ・データベースのみに関するプライマリ・データベースおよびフィジカル・スタンバイ・データベースのみに関するプライマリ・データベースおよびフィジカル・スタンバイ・データベースのみに関するプライマリ・データベースおよびフィジカル・スタンバイ・データベースのみに関する Data Guard のののの

SPFILE パラメータパラメータパラメータパラメータ

シカゴ（プライマリ・データベース）シカゴ（プライマリ・データベース）シカゴ（プライマリ・データベース）シカゴ（プライマリ・データベース）ボストン（フィジカル・スタンバイ・データベース）ボストン（フィジカル・スタンバイ・データベース）ボストン（フィジカル・スタンバイ・データベース）ボストン（フィジカル・スタンバイ・データベース）

*.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)'

シカゴと同様

*STANDBY_ARCHIVE_DEST=USE_DB_RECOVERY_FILE_DEST_SIZE

シカゴと同様

*.LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST arch noreopen max_failure=0 mandatory valid_for=(ALL_LOGFILES,ALL_ROLES) db_unique_name=SALES_CHICAGO'

*.LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST arch noreopen max_failure=0 mandatory valid_for=(ALL_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON'

*.LOG_ARCHIVE_DEST_2='service=SALES_BOSTON reopen=15 max_failure=10 lgwr affirm valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_BOSTON'

*.LOG_ARCHIVE_DEST_2='service=SALES_CHICAGO reopen=15 max_failure=10 lgwr affirm valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_CHICAGO'

表表表表 B-4 プライマリ・データベースおよびロジカル・スタンバイ・データベースのみに関するプライマリ・データベースおよびロジカル・スタンバイ・データベースのみに関するプライマリ・データベースおよびロジカル・スタンバイ・データベースのみに関するプライマリ・データベースおよびロジカル・スタンバイ・データベースのみに関する Data Guard のののの SPFILEパラメータパラメータパラメータパラメータ

シカゴ（プライマリ・データベース）シカゴ（プライマリ・データベース）シカゴ（プライマリ・データベース）シカゴ（プライマリ・データベース）ボストン（ロジカル・スタンバイ・データベース）ボストン（ロジカル・スタンバイ・データベース）ボストン（ロジカル・スタンバイ・データベース）ボストン（ロジカル・スタンバイ・データベース）

*.FAL_CLIENT='SALES_CHICAGO' *.FAL_CLIENT='SALES_BOSTON_LOG'

*.FAL_SERVER='SALES_BOSTON_LOG' *.FAL_SERVER='SALES_CHICAGO'

*.DB_UNIQUE_NAME=SALES_CHICAGO' *.DB_UNIQUE_NAME='SALES_BOSTON_LOG'

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(SALES_CHICAGO,SALES_BOSTON_LOG)'

シカゴと同様

*.STANDBY_ARCHIVE_DEST='/arch/SALES/archivelog'

*.STANDBY_ARCHIVE_DEST='/arch/SALES_LOG/archivelog'

*.LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST arch noreopen 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 noreopen max_failure=0 mandatory valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON_LOG'



次の表 B-5 は、大可用性モードまたは大保護モードのいずれかで稼働している Data Guard 環境に適用されます。

*.LOG_ARCHIVE_DEST_3='service=SALES_BOSTON_LOG reopen=15 max_failure=10 lgwr affirm valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_BOSTON_LOG'


*.LOG_ARCHIVE_DEST_4='location=/arch/SALES/archivelog arch noreopen max_failure=0 mandatory valid_for=(STANDBY_LOGFILES,ALL_ROLES) db_unique_name=SALES_CHICAGO'

*.LOG_ARCHIVE_DEST_4='location=/arch/SALES_LOG/archivelog arch noreopen max_failure=0 mandatory valid_for=(STANDBY_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON_LOG'

*.PARALLEL_MAX_SERVERS=9 シカゴと同様

表表表表 B-5 プライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データプライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データプライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データプライマリ・データベース、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースに関するベースに関するベースに関するベースに関する 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_BOSTON','SALES_BOSTON_LOG'

*.FAL_SERVER='SALES_BOSTON','SALES_BOSTON'

*.DB_UNIQUE_NAME='SALES_CHICAGO'

*.DB_UNIQUE_NAME='SALES_BOSTON'

*.DB_UNIQUE_NAME='SALES_BOSTON_LOG'

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(SALES_CHICAGO,SALES_BOSTON,SALES_BOSTON_LOG)'


*.STANDBY_ARCHIVE_DEST='/arch/SALES/archivelog'

シカゴと同様 *.STANDBY_ARCHIVE_DEST='/arch/SALES_LOG/archivelog

*.LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST arch noreopen 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 noreopen max_failure=0 mandatory valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON'

*.LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST arch noreopen max_failure=0 mandatory valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON_LOG'

表表表表 B-4 プライマリ・データベースおよびロジカル・スタンバイ・データベースのみに関するプライマリ・データベースおよびロジカル・スタンバイ・データベースのみに関するプライマリ・データベースおよびロジカル・スタンバイ・データベースのみに関するプライマリ・データベースおよびロジカル・スタンバイ・データベースのみに関する Data Guard のののの SPFILEパラメータ（続き）パラメータ（続き）パラメータ（続き）パラメータ（続き）

シカゴ（プライマリ・データベース）シカゴ（プライマリ・データベース）シカゴ（プライマリ・データベース）シカゴ（プライマリ・データベース）ボストン（ロジカル・スタンバイ・データベース）ボストン（ロジカル・スタンバイ・データベース）ボストン（ロジカル・スタンバイ・データベース）ボストン（ロジカル・スタンバイ・データベース）



表 B-6 に、大パフォーマンス・モードで稼働中の Data Guard 環境に対するパラメータの変更方法を示します。

*.LOG_ARCHIVE_DEST_2='service=SALES_BOSTON reopen=15 max_failure=10 lgwr affirm valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON'

*.LOG_ARCHIVE_DEST_2='service=SALES_CHICAGO reopen=15 max_failure=10 lgwr affirm valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_CHICAGO'

N/A




*.LOG_ARCHIVE_DEST_4='location=/arch/SALES/archivelog arch noreopen max_failure=0 mandatory valid_for=(STANDBY_LOGFILES,ALL_ROLES) db_unique_name=SALES_CHICAGO'

*.LOG_ARCHIVE_DEST_4='location=/arch/SALES/archivelog arch noreopen max_failure=0 mandatory valid_for=(STANDBY_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON'

*.LOG_ARCHIVE_DEST_4='location=/arch/SALES_LOG/archivelog arch noreopen max_failure=0 mandatory valid_for=(STANDBY_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON_LOG'

*.PARALLEL_MAX_SERVERS=9 シカゴと同様シカゴと同様

表表表表 B-6 大パフォーマンス・モードに関する大パフォーマンス・モードに関する大パフォーマンス・モードに関する大パフォーマンス・モードに関する Data Guard のののの SPFILE パラメータパラメータパラメータパラメータ



*.LOG_ARCHIVE_DEST_2='service=SALES_BOSTON reopen=15 max_failure=10 lgwr async=102400 net_timeout=30 valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON'

*.LOG_ARCHIVE_DEST_2='service=SALES_CHICAGO reopen=15 max_failure=10 lgwr async=102400 net_timeout=30 valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_CHICAGO'

N/A


ベースに関するベースに関するベースに関するベースに関する Data Guard のののの SPFILE パラメータ（続き）パラメータ（続き）パラメータ（続き）パラメータ（続き）




Oracle Net 構成ファイル

Oracle Net 構成ファイル構成ファイル構成ファイル構成ファイル

動的インスタンス登録を使用する全ホストの動的インスタンス登録を使用する全ホストの動的インスタンス登録を使用する全ホストの動的インスタンス登録を使用する全ホストの SQLNET.ORA ファイルのファイルのファイルのファイルのサンプルサンプルサンプルサンプル

# Set dead connection timeSQLNET.EXPIRE_TIME = 1# Set default SDU for all connectionsDEFAULT_SDU_SIZE=32767

動的インスタンス登録を使用する全ホストの動的インスタンス登録を使用する全ホストの動的インスタンス登録を使用する全ホストの動的インスタンス登録を使用する全ホストの LISTENER.ORA ファイルのファイルのファイルのファイルのサンプルサンプルサンプルサンプル

RAC 環境の場合、リスナーは、ローカル・ホスト名ではなく仮想 IP アドレス（VIP）でリスニングする必要があります。

lsnr_SALES = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=<local_host_name>)(PORT=1513) (QUEUESIZE=1024)))))# Password Protect listener; See "Oracle Net Services Administration Guide"PASSWORDS_lsnr_SALES = 876EAE4513718ED9 # Prevent listener administration ADMIN_RESTRICTIONS_lsnr_SALES=ON

*.LOG_ARCHIVE_DEST_3='service=SALES_BOSTON_LOG reopen=15 max_failure=10 lgwr async=102400 net_timeout=30 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_BOSTON_LOG'

*.LOG_ARCHIVE_DEST_3='service=SALES_BOSTON_LOG reopen=15 max_failure=10 lgwr async=102400 net_timeout=30 valid_for=(ONLINE_LOGFILES,ALL_ROLES) db_unique_name=SALES_BOSTON_LOG'

*.LOG_ARCHIVE_DEST_3='service=SALES_CHICAGO reopen=15 max_failure=10 lgwr async=102400 net_timeout=30 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=SALES_CHICAGO'

表表表表 B-6 大パフォーマンス・モードに関する大パフォーマンス・モードに関する大パフォーマンス・モードに関する大パフォーマンス・モードに関する Data Guard のののの SPFILE パラメータ（続き）パラメータ（続き）パラメータ（続き）パラメータ（続き）




Oracle Net 構成ファイル

動的インスタンス登録を使用する全ホストの動的インスタンス登録を使用する全ホストの動的インスタンス登録を使用する全ホストの動的インスタンス登録を使用する全ホストの TNSNAMES.ORA ファイルのファイルのファイルのファイルのサンプルサンプルサンプルサンプル

# Used for database parameter local_listenerSALES_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 ChicagoSALES_CHICAGO = (DESCRIPTION= (ADDRESS_LIST= (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 BostonSALES_BOSTON = (DESCRIPTION= (ADDRESS_LIST= (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 BostonSALES_BOSTON_LOG = (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=<boston_host1>)) (ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=<boston_host2>))) (CONNECT_DATA=(SERVICE_NAME=SALES_BOSTON_LOG)))


索引索引索引索引
AARCHIVELOG モード，7-4ASM，6-5
ストライプ化，6-4ASM 障害グループ，6-7ASM ディスク・グループ，6-7ASYNC 属性，7-28Automatic Storage Management，6-5

ストライプ化，6-4説明，3-7

BBACKUP VALIDATE RMAN コマンド，7-42BLOCK CHANGE TRACKING，7-42

CCFS（クラスタ・ファイル・システム），6-5Cluster Ready Services，7-44

構成に関する推奨事項，7-50CLUSTER_INTERCONNECTS 初期化パラメータ，

7-13CONTROL_FILE_RECORD_KEEP_TIME 初期化パラ

メータ，7-3CPU

推奨数，6-10CREATE DISKGROUP 文，6-7CRS

構成に関する推奨事項，7-50

DData Guard

Enterprise Manager による監視，8-11Enterprise Manager を使用したターゲットの管理，

8-13構成に関する推奨事項，7-14スイッチオーバー，10-13接続時フェイルオーバー，7-35データ障害からのリカバリ，10-36フェイルオーバー，10-10フェイルオーバーの選択，10-11利点，3-2

Data Guard スイッチオーバーSQL*Plus を使用，10-14選択，10-13

Data Guard のみのアーキテクチャ，4-2利点，4-8

Data Guard フェイルオーバー

SQL*Plus を使用，10-11Database Resource Manager，7-12DB_FLASHBACK_RETENTION_TARGET 初期化パラ

メータ，7-11DB_RECOVERY_FILE_DEST_SIZE 初期化パラメータ，

7-10DB_RECOVERY_FILE_DEST 初期化パラメータ，7-10DB_UNIQUE_NAME 初期化パラメータ，7-31DBMS_LOGSTDBY.SKIP プロシージャ，7-33DBMS_REDEFINITION PL/SQL パッケージ，10-55DELAY パラメータ，7-49DNS フェイルオーバー，10-7

索引索引索引索引 -1

EEnterprise Manager

Data Guard ターゲットの管理，8-13Data Guard の監視，8-11「Database Targets」ページ，8-9

Enterprise Manager の計画外停止，8-18HA アーキテクチャ，8-14HA アーキテクチャ推奨事項，8-16Management Repository の位置，8-21アラート，8-3可用性，8-14推奨通知ルール，8-10通知ルール，8-5パッチの管理，8-12パフォーマンス，8-9ポリシー違反，8-12メトリック，8-4メトリックの管理，8-11リスナーの構成，8-20

EXTERNAL REDUNDANCY 句，6-7

FFAILOVER パラメータ，7-49FAL_SERVER および FAL_CLIENT 初期化パラメータ，

7-21FAST_START_MTTR_TARGET 初期化パラメータ，7-6FORCE LOGGING モード，7-20

G「Grid Control」ホーム・ページ，8-2

HHARD Initiative，3-13，6-8，A-2Hardware Assisted Resilient Data Initiative，6-8Hardware Assisted Resilient Data（HARD）Initiative，

3-13，A-2HA アーキテクチャ

比較，4-14

II/O 操作

ロード・バランシング，6-4

Llistener.ora ファイル，7-22listener.ora ファイルのサンプル，B-9LOAD_BALANCE パラメータ，7-49LOG_ARCHIVE_DEST_2 初期化パラメータ，7-21LOG_ARCHIVE_DEST_n 初期化パラメータの ARCH

属性，7-28LOG_ARCHIVE_FORMAT 初期化パラメータ，7-16LOG_ARCHIVE_LOCAL_FIRST 初期化パラメータ，

7-17，7-30

MMAA，4-2

構成に関する推奨事項，7-34利点，4-10

Management Agent，8-2MAX_SERVERS 初期化パラメータ，7-32Maximum Availability Architecture，4-2

利点，4-10

NNetwork Time Protocol，6-14NRO，2-4NTP，6-14

OOCR

バックアップ，7-43リカバリ，10-33

ocrconfig ツール

Oracle Cluster Registry のバックアップ，7-43OCR の保護，6-9OIFCFG，6-17opatch

インストール済ソフトウェアとパッチのリスト，10-49

パッチの適用，10-48パッチのロールバック，10-49

opatch コマンドライン・ユーティリティ，10-47Oracle Advanced Security，7-30Oracle Cluster Registry

バックアップ，7-43リカバリ，10-33


Oracle Cluster Registry の保護，6-9Oracle Fail Safe

説明，3-10Oracle Net 構成ファイル

サンプル，B-9Oracle Net パラメータの SQLNET.SEND_BUF_SIZE

および SQLNET.RECV_BUF_SIZE，7-22Oracle インタフェース構成，6-17

PPARALLEL_MAX_SERVERS 初期化パラメータ，7-33

RRAC

構成に関する推奨事項，7-13サポートされているクラスタ・システム，6-11利点，3-2ローリング・アップグレード，10-3

RAC インスタンス

リモート・リスナーを使用した登録，7-13RAC インスタンスのリストア

クライアント接続，11-5RAC の可用性通知，7-47RAC のみのアーキテクチャ，4-2

利点，4-6RAC リカバリ，10-2，10-17

計画外停止，10-16RAC ローリング・アップグレード，10-47

推奨事項，10-49RAW デバイス，6-5Real Application Clusters

利点，3-2Recovery Manager

使用，7-37説明，3-11

Recovery Manager の自動バックアップ，7-39Recovery Manager のデータファイル・メディア・リカ

バリ，10-34Recovery Manager リポジトリ

制御ファイル，7-42REDO データ

安全な転送，7-30REDO データの安全な転送，7-30

REDO ログ・ファイルおよびグループ

サイズ，7-3RELY 制約，7-32REMOTE_ARCHIVE_ENABLE 初期化パラメータ，

7-16RESUMABLE_TIMEOUT 初期化パラメータ，7-10RETENTION GUARANTEE 句，7-8RETRIES パラメータ，7-49RMAN

使用，7-37説明，3-11

RMAN Recovery Catalog，7-38RPO，2-5RTO，2-4

SSAME 手法，6-4SERVICE_NAME パラメータ，7-49SLA，2-5

構成要素，5-3SPFILE，7-12

リカバリ，10-33SPFILE のサンプル，B-1SQL Apply

オブジェクトをスキップ，7-33sqlnet.ora ファイルのサンプル，B-9SRL，7-19SSH ポート転送，7-30STANDBY_ARCHIVE_DEST 初期化パラメータ，7-17Streams

説明，3-4Streams アーキテクチャ，4-2

利点，4-12

TTAF，7-47TCP パラメータ，6-18TIMED_STATISTICS 初期化パラメータ，7-7tnsnames.ora ファイル，7-22tnsnames.ora ファイルのサンプル，B-10TRANSACTION_CONSISTENCY 初期化パラメータ，

7-33


UUNDO_MANAGEMENT 初期化パラメータ，7-8UNDO_RETENTION 初期化パラメータ，7-8UNDO_TABLESPACE 初期化パラメータ，7-8

VV$MTTR_TARGET_ADVICE ビュー，7-6VALID_FOR 属性，7-17

WWAN 環境

ネットワークのチューニング，7-22WAN トラフィック・マネージャ，6-18

ああああアーカイブ REDO ログ

リカバリ，10-33アーカイブ計画，7-16アーキテクチャ

Data Guard のみ，4-2MAA，4-2Maximum Availability Architecture，4-2RAC のみ，4-2Streams，4-2データベースのみ，4-2

アクティブ化された本番データベースリストア，11-19


パッチのローリング，10-47ロジカル・スタンバイ・データベースの使用，

10-3，10-51アプリケーション・サービスのブラウンアウト，8-9アプリケーション・フェイルオーバー，10-2

RAC が配置されていない，7-47構成に関する推奨事項，7-44

アラート

Enterprise Manager，8-3

いいいい一時表領域，7-9インテリジェント・ストレージ・アレイ，6-7

おおおおオブジェクトの再編成，10-3オペレーティング・システムのバージョン，6-13オペレーティング・システムのパラメータ，6-13オンライン REDO ログ・ファイル

多重化，7-4リカバリ，10-32

オンライン・サービス，6-3オンライン再編成

説明，3-5オンラインでのオブジェクトの再編成，10-3，10-55オンラインでの索引の再編成，10-56オンラインでの表の再編成，10-55オンラインでの表領域の再編成，10-56

かかかか可用性

定義，1-2監視

Enterprise Manager，8-2

きききき記憶デバイス

データの検証，A-2行とトランザクションの非一貫性，10-39

くくくくクラスタ・インターコネクト，6-11クラスタ化ソフトウェア，6-14クラスタ全体の停止

リストア，11-14クラスタ・ファイル・システム，6-5

けけけけ計画外停止

Enterprise Manager，8-18RAC リカバリ，10-16セカンダリ・サイトのリカバリ手順，9-7タイプ，9-2プライマリ・サイトのリカバリ手順，9-4


計画的停止

RAC リカバリ，10-17準備，9-13セカンダリ・サイトのリカバリ手順，9-11タイプ，9-8プライマリ・サイトのリカバリ手順，9-10

計画的停止の計画，5-11

ここここ高可用性

重要性，1-3人員の研修，5-12操作ポリシー，5-2ドキュメントの重要性，5-12ビジネスへの影響の分析，2-3

高可用性アーキテクチャ特性，1-3

高可用性ソリューション

特性，1-2高速 JDBC 接続フェイルオーバー，7-44，7-47コールド・フェイルオーバー，4-17

ささささサーバー・ソフトウェア

すべてのアーキテクチャに関する推奨事項，6-12サーバー・ハードウェアの推奨事項

Data Guard のみと MAA，6-12RAC のみと MAA，6-11すべてのアーキテクチャ，6-10

サーバー・パラメータ・ファイル，7-12リカバリ，10-33

サーバー・パラメータ・ファイルのサンプル，B-1サービス

作成，7-50スタンバイの公開，7-51本番の公開，7-51

サービスのリストア，11-4サービス・レベル管理，5-3再開可能領域割当て，7-10

初にローカル・アーカイブを実行，7-17大可用性モード，7-23大パフォーマンス・モード，7-23大保護モード，7-23

サイト・フェイルオーバー，10-4WAN トラフィック・マネージャ，6-18ネットワーク・ルーティング，10-6部分的，10-8リカバリ，10-2

索引の再作成，10-55削除された表領域

フラッシュバック・データベースの使用，10-46暫定的なパッチ・アップグレード，10-47

しししし自動 UNDO 管理，7-8自動セグメント領域管理，7-9自動チェックポイント・チューニング，7-6ジャーナル・ファイル・システム，6-14主キー制約，7-32障害グループ，6-7障害検出

オペレーティング・システム，6-13障害時リカバリ計画，5-9障害のあるインスタンスのリストア

RAC，11-3障害のあるノードのリストア

RAC，11-3冗長ハードウェア，6-10初期化パラメータ

プライマリおよびフィジカル・スタンバイの例，7-17

すすすす推奨事項

コンポーネント特性，6-2冗長ハードウェア・コンポーネント，6-3ストレージの構成，6-2データベース構成，7-2

スイッチオーバーの手順，10-13スタンバイ REDO ログ，7-19

リカバリ，10-33スタンバイ・アーカイブ先，7-17スタンバイ・インスタンス

複数，7-34スタンバイ制御ファイル

消失のリカバリ，10-31


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

リストア，11-10ロジカルとフィジカルの比較，7-14

スタンバイ・データベースの一意の名前，7-31スタンバイ・データベースのデータ障害

リストア，11-16ストレージ・アレイ

オンライン・サービス，6-3ストレージの推奨事項

Data Guard のみと MAA，6-6RAC のみと MAA，6-6，6-9

ストレージ領域

ソフトウェア領域，6-5データベース領域，6-5フラッシュ・リカバリ領域，6-5

スワップ・パーティションミラー化，6-13

せせせせ制御ファイル

Recovery Manager リポジトリ，7-42消失のリカバリ，10-31

制御ファイルのコピー，7-3セカンダリ・サイトの停止

リストア，11-14セキュリティに関する推奨事項，7-11セキュリティ・ポリシー，5-14接続記述子

パラメータ，7-49本番インスタンス，7-45

接続時フェイルオーバー，7-35

そそそそソフトウェア領域，6-5

たたたた帯域幅，7-26待機時間

プライマリのスループットへの影響，7-28単一ノード障害，10-16

ちちちちチェックポイント，7-5中間層アプリケーション

通知用のサービス・コールアウト，7-51

つつつつ通知

RAC が配置されていない，7-47中間層アプリケーション，7-51

通知ルール

推奨，8-10

てててて停止，8-9

計画的，9-8スケジューリング外，9-2

停止時間原因，1-4コスト，2-4

データ障害

Data Guard を使用したリカバリ，10-28，10-36Data Guard を使用しないリカバリ，10-27Recovery Manager のデータファイル・メディア・

リカバリ，10-34Recovery Manager のブロック・メディア・リカ

バリ，10-34手動による再作成，10-36ファイルまたはブロック・メディア・リカバリ，

7-38リカバリ，10-3，10-22

データのミラー化とストライプ化，6-4データ破損

防止，A-2データファイル

リカバリ，10-31データファイル・ブロックの破損

ANALYZE 文，10-25DBMS_REPAIR パッケージ，10-25DBVERIFY ユーティリティ，10-25RMAN，10-25検出，10-24リカバリ，10-23

データベース・オブジェクトの削除，10-43


データベース構成

推奨事項，7-2データベース・スイッチオーバー，10-2，10-13データベースのみのアーキテクチャ，4-2

HA 機能と説明，4-4データベース・パッチ・アップグレード

推奨事項，10-49データベース・フェイルオーバー，10-10

リカバリ，10-2データベース領域，6-5データ保護モード，7-23

ネットワーク構成，7-27変更，7-25

適用インスタンス・フェイルオーバー，10-2，10-19SQL*Plus を使用，10-20

テンポラリ・ファイル・システム，6-13

とととと同一ハードウェア，6-12透過的アプリケーション・フェイルオーバー，7-47動的サービス登録，7-21動的再構成

説明，3-10ドライバのバージョン，6-13トランスポータブル表領域機能，3-6

にににに二重障害

リストア，11-21認証チェック，7-30

ねねねねネットワーク構成

パフォーマンス評価，7-26ネットワーク・コンポーネント

冗長，6-15ネットワークの推奨事項

RAC，6-17すべてのアーキテクチャ，6-15

ネットワーク・リカバリ目標，2-4

ののののノード障害

単一，10-16複数，10-16

ははははバージョン

オペレーティング・システム、パス、ドライバ，

6-13ハードウェア

フェンシング，6-11ハードウェア・コンポーネント

冗長，6-3破損

BACKUP VALIDATE RMAN コマンド，7-42リカバリ，10-22

バックアップ

増分，7-39長期，7-38

バックアップおよびリカバリOracle Cluster Registry，7-43推奨事項，7-36スケジュール，7-37ディスク・ベースの自動，7-39二重障害，7-38フラッシュ・リカバリ領域，7-41

バックアップおよびリカバリ計画，5-8バックアップ保存方針，7-40パッチ

Enterprise Manager による管理，8-12opatch による適用，10-48ロールバック，10-49

パッチ・アップグレード，10-3，10-47ローリング，10-47

パッチのローリング・アップグレード，10-47パッチのロールバック，10-49パッチ・レベル，6-13

ひひひひ非同期バッファ・サイズ，7-28表の非一貫性，10-43表領域名の変更，10-55品質保証契約，2-5

構成要素，5-3


ふふふふファスト・スタート・チェックポイント，7-6フィジカル・スタンバイ・スイッチオーバー

SQL*Plus を使用，10-14フィジカル・スタンバイ・データベース

構成に関する推奨事項，7-15，7-31リストア，11-11

フィジカル・スタンバイ・フェイルオーバーSQL*Plus を使用，10-11

ブート・ディスク，6-11フェイルオーバー

Data Guard，10-10RAC と Data Guard，10-19SQL*Plus を使用した適用インスタンス，10-20データベース，10-10適用インスタンス，10-19

フェンシング操作システム，6-13

複数ノード障害，10-16複数のスタンバイ・インスタンス，7-34部分的なサイト・フェイルオーバー

ネットワーク・ルーティング，10-8フラッシュバック・データベース，10-38，10-44

説明，3-9有効化，7-11

フラッシュバック・テーブル，10-38，10-43説明，3-9

フラッシュバック・テクノロジユーザー・エラーからのリカバリ，10-37例，10-41

フラッシュバック問合せ，10-38，10-39説明，3-8

フラッシュバック・トランザクション問合せ，10-38，10-40

説明，3-9フラッシュバック・ドロップ，10-38，10-43

説明，3-9フラッシュバック・バージョン問合せ，10-38，10-40

説明，3-8フラッシュ・リカバリ領域，6-5

構成に関する推奨事項，7-10サイズ，7-41説明，3-12テープ・バックアップ，7-40バックアップ，7-41

ブロックの検証，6-8

ブロックのチェック，7-5ブロックのチェックサム，7-4ブロック・メディア・リカバリ，10-34

へへへへ変更管理，5-5変更制御，5-6変更トラッキング，7-39

ほほほほ補助ロギング，7-32本番データベースのリセットログ

スタンバイ・データベースのリストア，11-19

みみみみミラー化ディスク，6-14

めめめめメディア障害

データファイルのリカバリ，10-31リカバリ，10-22，10-30

メディア・リカバリパフォーマンス，7-31

メトリックEnterprise Manager，8-4

ゆゆゆゆユーザー・エラー

フラッシュバック・テクノロジ，10-37リカバリ，10-3

よよよよ容量計画，5-4

りりりりリアルタイム適用，7-20リカバリ・カタログ，7-38リカバリ時間目標，2-4リカバリ・ポイント目標，2-5


リモート・アーカイブ，7-17リモート・リスナー

インスタンスの登録，7-13

ろろろろローカル管理表領域，7-9ロード・バランサ

アプリケーション・サーバー，6-17ネットワーク，6-17

ロード・バランシングI/O 操作，6-4

ローリング・アップグレード，10-3ロールベースの接続先，7-17ロギング，6-14ロジカル・スタンバイ・アーカイブ先，7-17ロジカル・スタンバイ・スイッチオーバー

SQL*Plus を使用，10-15ロジカル・スタンバイ・データベース

アップグレード，10-3，10-51構成に関する推奨事項，7-15，7-32リストア，11-13

ロジカル・スタンバイ・フェイルオーバー

SQL*Plus を使用，10-12論理ボリューム，6-5


Oracle高可用性アーキテクチャおよびベスト・プラクティス, 10...

Documents

Transcript of Oracle高可用性アーキテクチャおよびベスト・プラクティス, 10...