Maximum Availability Architecture
オラクル・ホワイト・ペーパー
2005 年 2 月
Maximum Availability Architecture
表の一覧 .......................................................................................................................................................................... iii
図の一覧 .......................................................................................................................................................................... iv
謝辞 ....................................................................................................................................................................................v
要約 .................................................................................................................................................................................. vi
Maximum Availability Architectureの新機能 ............................................................................................................... viii
第1部: MAAの概要
1.
はじめに................................................................................................................................................................ 1-1
2.
アーキテクチャの概要 ........................................................................................................................................ 2-1
第2部: MAA構成のベスト・プラクティス
3.
システム構成 ........................................................................................................................................................ 3-1
3.1
ストレージ..................................................................................................................................................... 3-1
3.2
サーバー・ハードウェア ............................................................................................................................. 3-6
3.3
サーバー・ソフトウェア ............................................................................................................................. 3-8
4.
ネットワーク構成 ................................................................................................................................................ 4-1
5.
データベース構成 ................................................................................................................................................ 5-1
6.
5.1
Real Application Clusters................................................................................................................................ 5-1
5.2
5.3
Oracle Data Guard........................................................................................................................................... 5-8
バックアップとRecovery Manager............................................................................................................. 5-35
Data CenterのMAA................................................................................................................................................ 6-1
第3部: 可用性の高い環境を監視および管理する
7.
Enterprise Managerでの監視と管理..................................................................................................................... 7-1
7.1
監視................................................................................................................................................................. 7-1
7.2
管理................................................................................................................................................................. 7-8
7.3
可用性の高いEnterprise Managerアーキテクチャ...................................................................................... 7-9
7.4
EM構成......................................................................................................................................................... 7-13
第4部: 停止、停止からのリカバリ、フォルト・トレランスのリストア
8.
9.
停止........................................................................................................................................................................ 8-1
8.1
計画外停止..................................................................................................................................................... 8-1
8.2
計画停止......................................................................................................................................................... 8-4
停止からのリカバリ ............................................................................................................................................ 9-1
9.1
リカバリ処理の概要 ..................................................................................................................................... 9-1
9.2
クライアント層 － サイト・フェイルオーバー（すべての層を含む） .............................................. 9-4
9.3
アプリケーション・サーバー層 - アプリケーション・サーバー・フェイルオーバー .................... 9-7
Maximum Availability Architecture
i
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
9.4
データベース・サーバー層 － オブジェクトの再編成.......................................................................... 9-8
9.5
データベース・サーバー層 － オブジェクトのリカバリ.................................................................... 9-13
9.6
データベース・サーバー層 － RACフェイルオーバーおよび
透過的アプリケーション・フェイルオーバー........................................................................................ 9-23
9.7
データベース・サーバー層 － Data Guardスイッチオーバー ............................................................. 9-24
9.8
データベース・サーバー層 － Data Guardフェイルオーバー ............................................................. 9-37
9.9
データベース・サーバー層 － スタンバイ・インスタンス・フェイルオーバー ............................ 9-49
10. データベースのフォルト・トレランスをリストアする............................................................................... 10-1
10.1 Real Applications Clusters内で障害が発生したノードまたはインスタンスをリストアする.............. 10-1
10.2 フェイルオーバー後にスタンバイ・データベースをリストアする .................................................... 10-7
10.3 セカンダリ・サイトまたはクラスタ全体の計画停止の後で
フォルト・トレランスをリストアする ................................................................................................. 10-11
10.4 スタンバイ・データベースのデータ障害後にフォルト・トレランスをリストアする .................. 10-13
10.5 スタンバイ・データベースのインスタンス化...................................................................................... 10-16
10.6 ロジカル・スタンバイ・データベースの作成に必要な手順は、『Oracle9i Data Guard概要と管理』
の第4章「Creating a logical standby database」を参照してください。 ............................................... 10-18
10.7 二重障害後にフォルト・トレランスをリストアする.......................................................................... 10-18
11. まとめ.................................................................................................................................................................. 11-1
第5部: 付録
12. 付録A − 主なアーキテクチャ変更におけるリスク評価............................................................................... 12-1
13. 付録B − 運用上のベスト・プラクティス....................................................................................................... 13-1
13.1 実務的ベスト・プラクティス ................................................................................................................... 13-1
13.2 技術的なベスト・プラクティス ............................................................................................................. 13-13
14. 付録C − データベースSPFILEおよびOracle Net構成 ファイルの例........................................................... 14-1
14.1 データベース・システムのパラメータ・ファイル（SPFILE）の例 ................................................... 14-2
14.2 Oracle Netの構成ファイルの例.................................................................................................................. 14-8
15. 付録D − テスト構成 .......................................................................................................................................... 15-1
15.1 RACのアクティブ/アクティブ・テスト構成 .......................................................................................... 15-1
15.2 Data Guardプライマリ・サイト/セカンダリ・サイトのテスト構成 .................................................... 15-2
15.3 SAMEテスト構成........................................................................................................................................ 15-3
16. 付録E − オブジェクトの再編成とリカバリの例 ........................................................................................... 16-1
16.1 オブジェクトの再編成例 ........................................................................................................................... 16-1
16.2 オブジェクトのリカバリ例 ....................................................................................................................... 16-5
17. 付録F − サーバー・パラメータ・ファイル（SPFILE） .............................................................................. 17-1
17.1 SPFILEの作成 .............................................................................................................................................. 17-1
17.2 SPFILEの管理 .............................................................................................................................................. 17-3
Maximum Availability Architecture
ii
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
表の一覧
表3-1:
サイトごとの各SAMEセットの内容 ......................................................................................................... 3-3
表4-1:
アプリケーション・フェイルオーバーの方法 ........................................................................................ 4-3
表4-2:
冗長なネットワーク・コンポーネント .................................................................................................... 4-4
表5-1:
RACの初期化パラメータのベスト・プラクティス ................................................................................ 5-2
表5-2:
スタンバイ・データベースのタイプ ........................................................................................................ 5-8
表5-3:
スタンバイ・データベースのタイプを決定する方法 ............................................................................ 5-8
表5-4:
Oracle Data Guardの初期化パラメータの設定 ........................................................................................ 5-11
表5-5:
アーカイブのルール.................................................................................................................................. 5-13
表5-6:
保護モード.................................................................................................................................................. 5-19
表5-7:
保護モードの選定...................................................................................................................................... 5-20
表5-8:
プライマリにおけるユーザー200人のテスト結果 ................................................................................ 5-22
表5-9:
ロジカル・スタンバイのMAX_SERVERSの例 ..................................................................................... 5-31
表7-1:
EMの計画外停止........................................................................................................................................ 7-11
表8-1:
計画外停止.................................................................................................................................................... 8-1
表8-2:
プライマリ・サイトにおける計画外停止 ................................................................................................ 8-3
表8-3:
セカンダリ・サイトにおける計画外停止 ................................................................................................ 8-4
表8-4:
計画停止........................................................................................................................................................ 8-4
表8-5:
プライマリ・サイトにおける計画停止 .................................................................................................... 8-6
表8-6:
セカンダリ・サイトにおける計画停止 .................................................................................................... 8-7
表8-7:
計画されているセカンダリ・サイトのメンテナンス対して準備する................................................. 8-8
表9-1:
リカバリ処理................................................................................................................................................ 9-1
表9-2:
オブジェクト再編成のソリューション（概要） .................................................................................... 9-8
表9-3:
表または索引のオブジェクト・リカバリに対する決定マトリックス............................................... 9-16
表9-4:
オブジェクト・リカバリの決定基準の説明 .......................................................................................... 9-17
表9-5:
ローカル・オブジェクト・リカバリのソリューション ...................................................................... 9-18
表9-6:
Data Guardスイッチオーバーの決定マトリックス................................................................................ 9-24
表9-7:
Data Guardフェイルオーバーの決定マトリックス................................................................................ 9-37
表9-8:
様々なタイプの停止に対してフェイルオーバーを使用する............................................................... 9-39
表9-9:
様々なタイプの停止に対してフェイルオーバーを使用する............................................................... 9-45
表10-1:
ノードまたはインスタンスの再開または再結合におけるパフォーマンスへの影響 ....................... 10-2
表10-2:
リストアおよび接続のフェイルバック .................................................................................................. 10-3
表10-3:
本番およびスタンバイ・データベースを再作成する ........................................................................ 10-18
表12-1:
MAAと代替のアーキテクチャ................................................................................................................. 12-1
表13-1:
完全に使用できないオブジェクトの検出、修復および防止............................................................. 13-16
表13-2:
部分的に使用できないオブジェクトまたは破損したオブジェクトの検出、修復および防止 ..... 13-18
表13-3:
計画外停止の防止および検出 ................................................................................................................ 13-20
表17-1:
SCOPEオプションの機能 ......................................................................................................................... 17-3
Maximum Availability Architecture
iii
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
図の一覧
図1-1:
HAパズル...................................................................................................................................................... 1-1
図1-2:
OracleのHAソリューション ....................................................................................................................... 1-2
図2-1:
Maximum Availability Architecture............................................................................................................... 2-1
図2-2:
Maximum Availability Architectureのネットワーク構成 ........................................................................... 2-4
図3-1:
ストレージ・アレイの詳細図 .................................................................................................................... 3-4
図3-2:
サーバー・ハードウェアの構成 ................................................................................................................ 3-6
図4-1:
ネットワーク構成（hb=ハートビート）.................................................................................................. 4-5
図5-1:
プライマリおよびセカンダリのアーカイブ宛先 .................................................................................. 5-15
図5-2:
200人のユーザー・テスト........................................................................................................................ 5-23
図5-3:
LGWR SYNC .............................................................................................................................................. 5-26
図5-4:
LGWR ASYNCの転送サービス................................................................................................................ 5-29
図6-1:
各データ・センターに1つのアプリケーション・サーバーを持つ1つのクラスタ ............................. 6-2
図6-2:
アプリケーション・サーバーを共有する別々のデータ・センター内の2つのクラスタ ................... 6-2
図7-1:
EM MAAのアーキテクチャ...................................................................................................................... 7-10
図9-1:
3層のMaximum Availability Architecture..................................................................................................... 9-2
図9-2:
サイト・フェイルオーバーの前のネットワーク・ルート..................................................................... 9-4
図9-3:
サイト・フェイルオーバーの後のネットワーク・ルート..................................................................... 9-5
図9-4:
アプリケーション・サーバー・ファームにおけるアプリケーション・サーバーの障害 ................. 9-7
図9-5:
スタンバイ・インスタンスへのフェイルオーバー ............................................................................ 10-53
図10-1:
パーティション化された2ノードのRACデータベース ........................................................................ 10-4
図10-2:
パーティション化されたデータベースにおけるRACインスタンスの障害....................................... 10-4
図10-3:
パーティション化されていないRACインスタンス .............................................................................. 10-5
図10-4:
アプリケーションがパーティション化されていない場合の1つの
RACインスタンスにおける障害.............................................................................................................. 10-5
図10-5:
フェイルオーバーのタイムライン .......................................................................................................... 10-9
図12-1:
RAC本番およびData Guardのシングル・インスタンス........................................................................ 12-2
図12-2:
シングル・インスタンスの本番およびData Guardのシングル・インスタンス ................................ 12-3
図12-3:
RACの本番、およびプライマリ・サイトでRACを使用するData Guard ............................................ 12-4
図12-4:
RACの本番、およびプライマリ・サイトでシングル・インスタンスを使用するData Guard ........ 12-5
図12-5:
シングル・インスタンスおよびプライマリ・サイトでのData Guard ................................................ 12-6
図12-6:
プライマリ・サイトのRAC本番のみ ...................................................................................................... 12-7
図13-1:
変更管理の流れ.......................................................................................................................................... 13-4
図15-1:
RACのアクティブ/アクティブ・テスト構成 ......................................................................................... 15-1
図15-2:
Data Guardのテスト構成 ........................................................................................................................... 15-2
図15-3:
SAMEのテスト構成................................................................................................................................... 15-3
Maximum Availability Architecture
iv
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
謝
辞
Maximum Availability Architecture に対して貴重な貢献をいただいた、次の Oracle パートナに深く感謝いたします。
•
Sun Microsystems
•
Hewlett-Packard
•
EMC
•
F5
•
Shunra
Maximum Availability Architecture
v
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
要
約
ユーザーの可用性要件に最適なアーキテクチャを選択し実装するのは、困難な作業になる場合があります。このアーキテ
クチャは、すべてのコンポーネントにわたって冗長性を備えており、配置、管理および拡張が簡単であるうえに、すべて
のタイプの停止に対処できる高速なクライアント・フェイルオーバーおよび一貫したハイ・パフォーマンスを提供し、ユ
ーザー・エラー、破損およびサイト障害からの保護を実現する必要があります。
このドキュメントでは、ビジネスで使用する高可用性（HA）を持つアーキテクチャを設計ための、複雑さを排除した技
術的なアーキテクチャについて説明します。Maximum Availability Architecture（MAA: 究極の可用性）は、単純かつ冗
長的で堅牢なアーキテクチャを提供し、様々なシステム停止を回避、検出およびリカバリして、システムを停止から平均
リカバリ時間（MTTR）内に復旧させるだけでなく、メンテナンスによる停止時間を最小限（またはゼロ）にします。こ
のアーキテクチャは、実証済の Oracle HA テクノロジで構成される完全なソリューションで、Oracle の Unbreakable なア
ーキテクチャを例証するものです。
より多くのシステム機能が提供されるにつれて、適切な機能のセットを統合して、すべての事業要件に適合する統一され
た高可用性を持つソリューションの構築や、既存のアーキテクチャに新しい HA 機能を組み込んだ活用が IT 管理者、設
計者、システム管理者、データベース管理者にとって困難になります。MAA の目的は、可用性の高い正しいアーキテク
チャを設計する際の複雑さを排除することです。MAA は、機能やポイント・ソリューションに焦点をあてるのではなく、
システム全体の可用性を最大にするように Oracle の実証済 HA テクノロジやベスト・プラクティス推奨事項をすべて統合
し、設定や構成を容易にする一方、次に示す利点を提供します。
•
MAA では、障害発生時の停止からのリカバリ時間の長さや受容可能なデータ消失量を制御できるため、事業要
件に合わせて MTTR を調整できます。
•
MAA は、詳細な構成ガイドラインを提供することにより、Oracle システムの可用性を高める実装コストを削減
します。異なる構成でのパフォーマンスへの影響の調査結果により、ニーズに合わせた高可用性アーキテクチャ
を継続的に利用し拡張が可能です。
•
MAA は、人的エラー、システム障害、クラッシュ、保守、データ障害、破損、災害などによる計画停止および
計画外停止を、ゼロまたは最小限に抑えるベスト・プラクティスとリカバリ手順を提供します。
このドキュメントの構成
このドキュメントでは、MAA の構築を中心に取り上げていますが、難しい HA の質問や、Data Guard、Real Application
Clusters（RAC）などの MAA のコンポーネントを構成するリファレンス・ガイドとしても利用できます。MAA は、オラ
クル社の簡単に管理できるベストな HA アーキテクチャを示しています。また、構成のベスト・プラクティスおよび停止
と修復の項は、DBA やシステム管理者が、Data Guard や RAC などの MAA を部分的または全体的にテストし構築する際
に役に立ちます。このドキュメントは IT マネージャ、データベース管理者、システム管理者、コンサルタント、および
設計者を対象としています。
第 1 部: MAA の概要:
の概要 「はじめに」および「アーキテクチャの概要」では、MAA の目標、MAA のアーキテクチャとコ
ンポーネントの概要を説明します。
第 2 部: MAA 構成のベスト・プラクティス:
構成のベスト・プラクティス Maximum Availability Architecture（MAA）を作成する構成のベスト・プラク
ティスについて説明します。ここでは、必要な実装内容と、実装理由を中心に説明します。「MAA 構成のベスト・プラ
クティス」の項では、必要な実装内容と、実装理由について説明します。この項は、MAA 構成のベスト・プラクティス
全体または一部の実装を行うデータベース管理者、システム管理者、コンサルタントを対象にしています。
Maximum Availability Architecture
vi
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
第 3 部: 可用性の高い環境を監視および管理する:
可用性の高い環境を監視および管理する 「Enterprise Manager での監視と管理」の項では、MAA を含むすべて
の高可用性を持つアーキテクチャに対して、Enterprise Manager が提供する高度な監視および管理フレームワークを説明
します。
第 4 部: 停止、停止からのリカバリ、フォルト・トレランスのリストア:
停止、停止からのリカバリ、フォルト・トレランスのリストア 「停止」、「停止からのリカバリ」、および
「フォルト・トレランスのリストア」の項では、様々な計画外停止および計画停止に対する最適なソリューションを提供
して、このアーキテクチャの有用性を示し、停止後に高可用性をリストアする方法を詳しく説明します。この項はすべて
のユーザーを対象としていますが、特に、MAA の様々な HA ソリューションおよびリカバリ手順を実装またはテストの
必要があるユーザーに対し、詳細な説明を提供しています。
第 5 部: 付録:
付録 この項は、ベスト・プラクティス、リスク評価、およびテスト構成の詳細について説明します。
構成および実装の詳細を理解するには、Oracle Server、Real Application Clusters、および Data Guard の用語に関する知識が
必要です。関連情報は、『Oracle9i Database 概要』、Oracle Data Guard のドキュメント・セット、Oracle Real Application
Clusters のドキュメント・セットを参照してください。
MAA は、Oracle 社 Server Technologies 部門の High Availability Systems Group によって設計、テスト、および検証されてお
り、世界中の多数のカスタマ・サイトで検証および配置されています。
Maximum Availability Architecture
vii
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Maximum Availability Architecture の新機能
2003 年 7 月
この項では、
2003 年の 7 月のリビジョンで Maximum Availability Architecture に加えられた変更について主に説明します。
•
Enterprise Manager
「Enterprise Manager での監視と管理」の章が追加されました。Enterprise Manager のリポジトリのための高可用性
を持つアーキテクチャを作成する場合の詳細な説明が追加されました。Enterprise Manager に関連するトピックは、
すべてこの章に移動しました。
•
ロジカル・スタンバイ・データベース
ロジカル・スタンバイ・データベースを検証およびテストすることによって、ロジカル・スタンバイが MAA の
Data Guard オプションとして組み込まれました。ロジカル・スタンバイの内容を含めるために、「Data Guard の
構成」、「停止」、「停止からのリカバリ」、「フォルト・トレランスのリストア」の項が拡張されました。
•
Oracle Data Guard
Data Guard（フィジカルおよびロジカル・スタンバイ）のパフォーマンス・テストおよびカスタマ・ケースから
導出されるベスト・プラクティスが追加されました。最適なスタンバイ構成の選択をサポートするための決定マ
トリックスが追加され、保護モードの項が修正されました。
2003 年 2 月
この項では、2003 年の 2 月のリビジョンで Maximum Availability Architecture に関し追加された変更について主に説明し
ます。
•
「新機能」の項が追加されました。
•
Enterprise Manager
Oracle Enterprise Manager（OEM）のリポジトリに対して可用性の高いアーキテクチャが追加され、障害ケースお
よび OEM の 3 層（エージェント、Oracle Management Server（OMS）、リポジトリ）のソリューションを説明す
るための停止マトリックスが更新されました。
•
Real Application Clusters
「Real Application Clusters 構成のベスト・プラクティス」の項が更新され、制御ファイルのサイズおよび
CONTROL_FILE_RECORD_KEEP_TIME の推奨値が追加されました。
•
Oracle Data Guard
Data Guard のパフォーマンスのベスト・プラクティスが追加されました。
フェイルオーバーまたは強制フェイルオーバー後にスタンバイ・データベースのリストアに関連する手順が明確
にするために、「データベースの完全なフォルト・トレランスをリストアする」の項が更新されました。
•
バックアップおよびリカバリ
「バックアップおよびリカバリ構成のベスト・プラクティス」の項が更新されました。
•
「付録 E − Fast-Start Checkpointing Overview and Recommendation」が削除されました。この付録の情報は、Oracle
Technology Network（OTN）（http://otn.oracle.com）の『Oracle9i Fast-Start Checkpointing Best Practices』という別
のドキュメントとして提供されています。
Maximum Availability Architecture
viii
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
•
「付録 I − Oracle Recovery Tuning Best Practices」が削除されました。この付録の情報は、Oracle Technology Network
（OTN）（http://otn.oracle.com）の『Oracle9i Media Recovery Best Practices』という別のドキュメントとして提供さ
れています。
•
「付録 H − RMAN Considerations for Backups」が削除されました。この内容は、「バックアップおよびリカバリ
構成のベスト・プラクティス」の項に含まれています。
Maximum Availability Architecture
ix
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
第 1 部: MAA の概要
第 1 部では、MAA の目標、MAA のアーキテクチャとコンポーネントについて概要を説明します。
次の項で構成されています。
•
第 1 項「はじめに」
•
第 2 項「アーキテクチャの概要」
Maximum Availability Architecture
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
はじめに
1.
MAA の目的は次のとおりです。
•
高可用性（HA）のソリューションと HA 体験をすぐに提供
•
Unbreakable なアーキテクチャ
•
すべての停止を回避、検出および修復するための統合的ベスト・プラクティス
このドキュメントの提供および MAA プロジェクトは、すべてのお客様の HA においてこれらの基準が満たされるまで継
続します。このドキュメントでは、最初に RAC および Data Guard をベースとして使用したデータベースおよびシステム
の構成について説明します。将来のリリースと改訂では、Oracle Application Server、Oracle Collaboration Suite および
E-Business Suite を統合する予定です。また、新しく有効性が確認された機能、様々なパフォーマンス調査結果、管理性
についての詳細なデータなどにあわせてこのドキュメントの内容も更新されます。
このドキュメントは、多くのお客様にとって HA ソリューションを構成するリファレンスとなるよう、Maximum
Availability Architecture およびそのすべてのコンポーネントに対するロードマップを提供します。図 1-1 に示すとおり、
MAA は、HA では何が必要か、HA アーキテクチャとコンポーネントをどのように構成するか、停止からどのように修復
するかという問題を解決します。
図1-1: HAパズル
パズル
MAA によって、制御困難な停止がすべて解決されます。図 1-2 は、オラクル社提供する様々な停止に対するソリューシ
ョンを示しています。MAA では、様々な停止からリカバリする詳細な手順の提供により、様々な Oracle の機能の組合せ
以上の環境を提供します。これらの手順は、社内およびコラボレーションによるお客様のテスト、妥当性チェックおよび
ディスカッションによって作成されます。これについては停止とソリューションの項で、さらに詳しく説明します。
Maximum Availability Architecture
1-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
はじめに
図1-2: Oracleの
のHAソリューション
ソリューション
このドキュメントは、次の章および項で構成されています。
•
MAA の概要
はじめに
アーキテクチャの概要
•
MAA 構成のベスト・プラクティス
システム構成
ネットワーク構成
データベース構成
Data Center の MAA
•
Enterprise Manager での監視と管理
•
停止、停止からのリカバリ、フォルト・トレランスのリストア
停止
停止からのリカバリ
フォルト・トレランスのリストア
Maximum Availability Architecture
1-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
はじめに
「アーキテクチャの概要」では、MAA のアーキテクチャおよびそのコンポーネントの概要について説明します。「MAA
構成のベスト・プラクティス」は構成のガイドラインで、システム、ネットワーク、ネットワークの構成について、およ
び既存の Data Center で MAA を使用する場合について説明します。「Enterprise Manager での監視と管理」では、HA 環境
で監視する必要がある重要なイベントは何か、Oracle Enterprise Manager を使用して何を管理できるのかを説明します。
「停止」および「停止からのリカバリ」では、計画的および計画外停止に対する最適なソリューションを提供し、MAA
アーキテクチャが適切であることを示します。フェイルオーバーの操作またはデータベース停止を解決した後で、「フォ
ルト・トレランスをリストアする」の項を参照して、データベースの高可用性を回復させます。
このドキュメントでは、構成のベスト・プラクティスおよびソリューションについて詳しく説明し、アーキテクチャ全体
の広範囲におよぶ様々な停止を回避および修復するサポートを提供します。3 層のアーキテクチャにおける高可用性デー
タベースの構成および管理を中心に説明します。
Maximum Availability Architecture
1-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
アーキテクチャの概要
2.
MAA は、シンプルで冗長性の高い堅牢なアーキテクチャの提供により、様々な停止を防止し、または短い平均リカバリ
時間（MTTR）内での停止からのリカバリを実現します。その目標は、大部分の停止で可用性への影響をゼロまたは最小
限に抑え、致命的停止の場合には 30 分以内に復旧することです。MAA の主なコンポーネントは次のとおりです。
•
冗長な中間層およびアプリケーション層
•
冗長なネットワーク・インフラストラクチャ
•
冗長なストレージ・インフラストラクチャ
•
ホストとインスタンスの障害から保護する Real Application Clusters（RAC）
•
人的エラーとデータ障害から保護し、サイト障害からリカバリするための Oracle Data Guard（DG）
•
堅実な運用プラクティス
図 2-1 は、アーキテクチャの概要を示しています。
図2-1: Maximum Availability Architecture
図 2-1 は、同様に構成された 2 つのサイトを表しています。各サイトは、障害発生時にも要求を常に処理できるように、
冗長なコンポーネントと冗長なルーティング・メカニズムで構成されています。大部分の停止はローカルに解決されます。
クライアント要求は、常に本番ロールとして機能しているサイトに送信されます。
Maximum Availability Architecture
2-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
アーキテクチャの概要
重大な停止が原因でフェイルオーバーまたはスイッチオーバーの操作が行われると、クライアントのリクエストは、本番
ロールが割り当てられている別のサイトに送信されます。各サイトには、アプリケーション・サーバーまたは中間層サー
バーのセットが含まれています。本番ロールのサイトには、ホストやインスタンスの障害から保護するために、RAC を
使用する本番データベースがあります。スタンバイ・ロールのサイトには、Data Guard により管理される 1 つ以上のスタ
ンバイ・データベースがあります。Data Guard スイッチオーバーとフェイルオーバーにより、サイト間でロールを交換で
きます。
図 2-1 で、最初は、プライマリ・サイトに本番データベースがあり、本番ロールとして機能しています。セカンダリ・サ
イトには、フィジカルまたはロジカルまたは両方のスタンバイ・データベースがあり、スタンバイ・ロールとして機能し
ています。計画的なスイッチオーバー操作または計画外のフェイルオーバー操作が行われると、このロールは切り替わり
ます。これらの操作の詳しい説明、および発生するタイミングについては、「停止からのリカバリ」を参照してください。
ロールが変更された場合でも、プライマリ・サイトおよびセカンダリ・サイトという呼び方は変わりません。
RAC および Data Guard は、MAA ソリューションのベースを提供します。RAC では、複数データベースのインスタンス
で同じデータベースを共有し、最適なパフォーマンス、スケーラビリティおよび可用性を実現できます。Data Guard は、
スタンバイ・データベースに対して、障害時リカバリ、ユーザー・エラーとデータ破損の回避、読込み専用（および可能
な場合は読込み/書込み）アクセスを提供します。Data Guard には管理インフラストラクチャが含まれており、具体的に
はログ転送サービス、管理されたリカバリ、フィジカル・スタンバイ・データベース、ロジカル・スタンバイ・データベ
ース、Data Guard Broker、コマンドライン・インタフェースなどが用意されています。MAA では、Data Guard が自動的
なログ転送サービス、管理されたリカバリ、本番データベースとフィジカル・スタンバイ・データベースとロジカル・ス
タンバイ・データベース間のロール管理を提供します。スタンバイ・データベースは本番データベースのコピーであり、
本番データベースの REDO データを適用することで更新されます。フィジカル・スタンバイ・データベースは、マウン
トされリカバリ・モードに設定された複製データベースです。ロジカル・スタンバイ・データベースは、フィジカル・ス
タンバイ・データベースとは異なり、読込み/書込み操作で使用できます。スタンバイ・データベースは、アプリケーシ
ョンでユーザー・エラーまたはスタンバイ・データベースに対する本番データベースの破損を回避するため、REDO の適
用遅延で構成されています。プライマリ・データベースが停止した場合でも、プライマリ・データベースの REDO デー
タは生成後すぐにスタンバイ・データベースへ送信されるため、データの損失はゼロまたは最少に抑えられます。
フェイルオーバーやスイッチオーバーの後でもパフォーマンスが低下しないよう、プライマリ・サイトとセカンダリ・サ
イトを同じ構成にすることをお薦めします。ただし、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・
データベースの両方を配置する計画の場合は、特別な注意が必要になります。対称型のサイトにするとサイト間で処理と
手順がサイト間で同じに保持されるため、保守と実行の運用は非常に簡単になります。さらに、アップグレードやソフト
ウェア変更は、プライマリ・サイトとセカンダリ・サイトのどちらでも、互いに複製されます。どのような場合でも、リ
モート・ソフトウェアの同期の維持は手動で、またはソフトウェアの同期を維持するサード・パーティ・ソリューション
を使用する必要があります。
次の項で、MAA の各コンポーネントの概要について説明します。
•
アプリケーション層
•
ネットワーク・インフラストラクチャ
•
ストレージ・インフラストラクチャ
•
Real Application Clusters
•
Data Guard とセカンダリ・サイト
•
運用上のベスト・プラクティス
2.1.1
アプリケーション層
アプリケーション層は、Customer Relationship Management や Self Service Applications などのアプリケーション・サービス
にホストされている 1 つ以上のコンピュータ・セットで構成されています。これらのサービスの機能は、複数のマシンに
分散されます。たとえばアプリケーション層の機能は、Web サーバーにホスティングしているマシンの実装だけでなく、
Maximum Availability Architecture
2-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
アーキテクチャの概要
アプリケーション特有の処理（サーブレットや Enterprise JavaBeans（EJBs）の処理）にホスティングしているサーバーに
実装もできます。このサーバーのセットは、ともにクライアントに対してアプリケーション・サービスを提供し、アプリ
ケーション層のビルディング・ブロックとなります。
各サービスの冗長なホスト・セットはアプリケーション層の中に存在し、レジリエンスの高いスケーラブルなロード・バ
ランシングを実現しています。これらのホスト・セットはまとめてサーバー・ファームと呼ばれます。サーバー・ファー
ムは通常、受信するクライアント要求をサーバー・ファーム内の複数のホストに分散させる、ハードウェア・ベースまた
はソフトウェア・ベースのロード・バランサを持っています。
MAA は、各サイトに個別のアプリケーション層サーバーを備えています。プライマリ・サイトのサーバー・ファームは、
ハードウェア、OS、アプリケーション・サーバー・ソフトウェア、アプリケーション固有のソフトウェアについてセカ
ンダリ・サイトと同様です。プライマリ・サイトとセカンダリ・サイトは、すべての面で同様に構成されます。ネットワ
ーク・インフラストラクチャは、本番ロールのプライマリ・サイトにあるアプリケーション・サーバーに、すべてのクラ
イアント要求を送信します。アプリケーション層は、Oracle Net Services を使用して（オプションで、データベース・サ
ービスをルックアップする Oracle Internet Directory も使用）、データベース層にあるプライマリ・サイトの RAC データ
ベースにアクセスします。
図 1 では、プライマリ・サイトで障害が発生した場合、セカンダリ・サイトのサーバー・ファームをアクティブにする必
要があります。そして、ネットワークは以降のすべてのクライアント要求をセカンダリ・サイトのアプリケーション層に
送信します。クライアントのリダクションについては、「ネットワークのインフラストラクチャ」および「アプリケーシ
ョン・フェイルオーバー構成のベスト・プラクティス」で説明しています。スタンバイ・ロールであったセカンダリ・サ
イトのデータベースは、本番ロールを引き継ぎ、新しい構成のもとでアクティブな本番データ・サーバーになります。
それぞれのサーバー・ファームはマシンの複数セットにおいて冗長であるため、個々のアプリケーション層ホストのサイ
ト内での問題および停止はクライアント間で透過になります。インフラストラクチャの監視による自動検出、（および該
当する場合は）アプリケーション層で障害が発生したコンポーネントの再起動によって、アプリケーション・サービスを
ほとんど停止なしに使用が可能です。
2.1.2
ネットワークのインフラストラクチャ
ネットワークのインフラストラクチャ
すべてのネットワークのコンポーネント（ルーター、ファイアウォールおよびロード・バランサ）は、単一の障害箇所が
発生しないようフォルト・トレラント形式で実装する必要があります。ネットワークには、冗長性のあるリンクとデバイ
ス間でトラフィックを自動的に再ルートする機能を備えて、障害が発生したコンポーネントについて、1 つ以上の代替の
ルートを提供する必要があります。これにより、アプリケーションは常にアクセス可能です。この方法では、ユーザーが
ネットワーク・コンポーネントを 1 つずつオフラインにして、予定されている停止時間の最少も可能です。図 2-2: ネッ
トワークのフェイルオーバー・ルートでは、それぞれのネットワーク・データベースが冗長ペアの一部になっており、単
一箇所で停止した場合には複数のフェイルオーバー・ルートが有効であることがわかります。
MAA では、可用性の高い環境を提供するために、2 つのサイト（プライマリ・サイトとセカンダリ・サイト）を同様に
構成します。プライマリ・サイトでの重大な停止のためサービスを提供できなくなると、トラフィックはセカンダリ・サ
イトに転送されます。プライマリ・サイトの障害に対し、広域のトラフィック・マネージャを使用してセカンダリ・サイ
トへトラフィックが転送されます（図 2-2 Tier 1 参照）。
ロード・バランサは、アプリケーション・サーバー・ファームを隠蔽し、エンド・ユーザーのクライアントに対して単一
の IP アドレスを提供します。ロード・バランサはすべてのクライアント要求を受け取り、それを中間層のアプリケーシ
ョン・サーバー間で均等に負荷を分配します。いずれかのアプリケーション・サーバーに障害が発生すると、ロード・バ
ランサは後続のすべてのクライアント要求を有効な（使用できる）アプリケーション・サーバーに対して再分配します。
冗長性のためには、バックアップ・ロード・バランサも必要です。2 つのロード・バランサを使用して、1 つはスタンバ
イ・ロード・バランサとして設定しておき、プライマリ・ロード・バランサが使用不可になった場合のみ有効にします（図
2-2 Tier 2 参照）。
Maximum Availability Architecture
2-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
アーキテクチャの概要
アプリケーション・サーバーは Oracle Net Services の構成情報を使用してデータベースに接続します。この情報は、一元
管理されている LDAP 準拠のディレクトリ・サーバー（Oracle Internet Directory など、冗長性も実現されている必要があ
るもの）に格納できます。これは、各ホストのローカル tnsnames.ora ファイルよりも管理が簡単です。
図2-2: Maximum Availability Architectureのネットワーク構成
のネットワーク構成
2.1.3
ストレージ・インフラストラクチャ
現在は、いくつかのストレージ・オプションが存在し、様々な機能とオプションが用意されています。高可用性には、次
の機能が必要です。
•
すべてのハードウェア・コンポーネントに対する完全な冗長性
•
オンライン・パーツ交換（ホスト・スワップ可能なパーツ）
•
オンライン・パッチ・アプリケーション
Maximum Availability Architecture
2-4
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
アーキテクチャの概要
•
ハードウェアのミラーリングとストライピング機能
•
バッテリー・バックアップを備え、ミラー化された書込みキャッシュ
•
すべてのホスト・バス・アダプタ間でのロード・バランシングとフェイルオーバー機能
2.1.4
Real Application Clusters
RAC は複数のノードまたはマシンを使用します。それぞれのノードやマシンは共有ディスク・ストレージ上の単一のデ
ータベースにアクセスする Oracle インスタンスを実行します。RAC 環境では、アクティブなインスタンスのどれもが共
有データベースに対し、トランザクションを同時に実行できます。RAC は、各インスタンスによる共有データへのアク
セスを自動的に調整し、データの一貫性と整合性を提供します。
RAC には、次のような大きな特長があります。
•
可用性 − ハードウェアとソフトウェアのコンポーネント障害からの中断を最小限にして、データに対してほと
んど継続的なアクセスを提供します。
•
スケーラビリティ − データの再配置やユーザー・アプリケーションの変更を行わずにクラスタにノードを追加
して、処理機能を高めることができます。
•
管理性 − 単一システム・イメージで管理できます。
RAC により、コンポーネント、インスタンスまたはノードに障害が発生した場合でも、連続データ可用性
可用性を維持できま
可用性
す。インスタンスまたはノードで障害が発生した場合、障害のあるインスタンスに有効なインスタンスが自動的にリカバ
リを実行し、データベース・サービスの提供を継続します。クラスタで稼働している有効なインスタンスが少なくとも 1
つあれば、常にユーザー・データにアクセス可能です。RAC では、計画外停止（インスタンスやノードの障害など）を
効率的な処理だけでなく、管理者は、クラスタのノードまたはコンポーネントのサブセットで計画的保守を実行している
間も、ユーザーにサービスを継続して提供できます。
RAC は、クラスタに追加されたノードの処理能力を自動的に活用して、実際には停止を必要としないスケーラビリティ
スケーラビリティ
を提供します。RAC のキャッシュ・フュージョン・アーキテクチャの採用により、クラスタでノードが追加または削除
された際、追加された CPU 能力や I/O とネットワーク帯域幅の活用にデータの再パーティションやアプリケーションの
変更が必要ありません。
RAC は、処理負荷が最も低く、接続数が最小となるように、使用可能なインスタンス間で自動的に新しいデータベース
接続要求のバランスを取ることもできます。インスタンスは、リスナー、およびリモート・リスナーを持つクロスレジス
タに対して負荷データを提供できるため、各リスナーは、どの位置からでもすべてのサービス、インスタンス、ディスパ
ッチャ、およびそれらの現在の負荷を認識できます。したがって、リスナーは、特定のサービスを求めて到着したクライ
アント要求を、負荷の最も少ないノード、インスタンスまたはディスパッチャに送信できます。
RAC 可用性とスケーラビリティに対する重要なコンポーネントに、プライベート・インターコネクトがあります。イン
ターコネクトは、クラスタのノードをリンクし、メッセージ、データなどのクラスタ通信トラフィックをルーティングす
ることにより、共有リソースに対する各ノードのアクセスを調整する通信機能です。高可用性のためには、インターコネ
クトは、障害の発生したアダプタ、ケーブルまたはスイッチによる単一リンク障害が 1 つのノードをクラスタの残りの部
分から孤立させない冗長性を必要とします。特にキャッシュ・フュージョン・アーキテクチャでのスケーラビリティを保
証するため、インターコネクトは、帯域幅の広い低遅延リンクが必要です。理想は、クラスタが冗長リンクを完全に利用
でき、複数のインターコネクト・パス間で負荷のバランスを取れることです。
RAC 環境の保守の面では、RAC は複数のインスタンスからアクセスされる単一のデータベースであるため、すべてのデ
ータベース操作についてクラスタ全体を単一システムとするイメージが保持されます。これが管理性
管理性を簡素化します。
管理性
DBA は、構成、HA 操作、リカバリ、監視などの機能は 1 回の実行だけで、あとは Oracle が適切なノードに管理機能を
自動的に分散します。これは、DBA が 1 台の仮想サーバーを管理していることを意味します。
Maximum Availability Architecture
2-5
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
アーキテクチャの概要
2.1.5
Oracle Data Guard とセカンダリ・サイト
Oracle Data Guard は、Oracle データベースと統合されたソフトウェアで、スタンバイ・データベースと呼ばれる本番デー
タベースのリアルタイム・コピーを管理します。MAA では、スタンバイ・データベースはサイトでスタンバイ・ロール
を割り当てられ、障害時リカバリに使用されます。サイトが同一で、本番データベースの物理的位置がユーザーに対して
透過的である場合、様々なタイプの計画外停止や計画停止の際に、本番ロールとスタンバイ・ロールをサイト間で簡単に
切替えができ、より高度な障害時リカバリを提供できます。
Oracle Data Guard は、ログ転送サービス、管理されたリカバリ、スイッチオーバーおよびフェイルオーバーの各機能を提
供することにより、本番データベースとのスタンバイ・リレーションシップを管理します。MAA では、本番データベー
スは Real Application Cluster 内に置かれ、フィジカル、ロジカルまたは両方のスタンバイ・データベースは、セカンダリ・
サイトの同一のクラスタ上に置かれます。最初は、スタンバイ・データベースはセカンダリ・サイトにあります。ただし、
プライマリ・サイトとセカンダリ・サイトは、Data Guard のスイッチオーバー機能とフェイルオーバー機能により、簡単
にロールの切替えができます。セカンダリ・サイトをプライマリ・サイトと同一に設定しておくと、プライマリ・サイト
からのフェイルオーバーまたはスイッチオーバー後のパフォーマンスとレスポンス時間は、予測可能になります。また、
同一のセカンダリ・サイトでは、手順、処理、全体的管理も、同一に設定されたサイト間で同様に可能です。セカンダリ・
サイトは、プライマリ・サイトで自動的または迅速に解決されないすべての計画外停止、およびプライマリ・サイトで保
守が必要な場合の多くの計画停止に利用されます。セカンダリ・サイトは、サイト障害からの保護の提供し、次の点でプ
ライマリ・サイトと同等です。
•
冗長な中間層およびアプリケーション層
•
冗長なネットワーク・インフラストラクチャ
•
冗長なストレージ・インフラストラクチャ
•
本番ロールの場合に、ホストおよびインスタンスの障害から保護するための同一の Real Application Clusters 環境
•
堅実な運用プラクティス
フィジカル・スタンバイ・データベースを使用する Data Guard には、次の特長があります。
•
可用性 − 人的エラー、データ障害、プライマリ・サイト障害および災害からの保護を提供し、プライマリ・サ
イト保守のためのスイッチオーバー操作と、データ消失のない環境を実現する様々なデータベース保護モードを
提供します。
•
管理性 − ログ転送サービス、管理されたスタンバイ・リカバリ、スイッチオーバーやフェイルオーバーのよう
なロール管理サービス、および本番データベースからバックアップや読取り専用アクティビティをオフロードす
る機能のための、管理および監視のフレームワークを提供します。
また、ロジカル・スタンバイ・データベースを使用する Data Guard には、次の特長があります。
•
レポート作成および読込み/書込みのアクセス可能性
レポート作成および読込み 書込みのアクセス可能性 − ロジカル・データベースはレポート作成、意思決定サポ
ートおよび障害時リカバリに利用できます。ロジカル・スタンバイの SQL 適用エンジンは、本番の REDO を SQL
に変換し、それをオープン中のデータベースに適用できます。また、ロジカル・スタンバイ・データベースは、
索引やマテリアライズド・ビューのような他のオブジェクトもサポートします。
Maximum Availability Architecture
2-6
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
アーキテクチャの概要
2.1.6
運用上のベスト・プラクティス
スタンバイ・データベースでのREDO適用の遅延を指定することにより、変更がスタンバイ・データベースに適用前に、
表の消去のような論理的破壊やエラーが検出されるように構成する必要があります。さらに、エラーが指定された遅延間
隔以内に検出されるように適切な監視と検出の必要もあります。スタンバイ・データベースは、フィジカル・スタンバイ・
データベースの場合のみ、データまたはトランザクションの消失ゼロで構成できます。ただし、アーキテクチャ上の設計
決定は、パフォーマンスへの影響を最小限にするように考慮が必要です。スタンバイ・データベースを使用する場合、デ
ータベース・リカバリ時間が大幅に短縮されるため、大部分のデータベース障害は、オンディスク・バックアップより迅
速に解決されます。フィジカル、ロジカルまたは両方のスタンバイ・データベースが現在の要件に合うかの判断、すべて
の保護モードでパフォーマンスへの影響を最小限するベスト・プラクティスおよび推奨事項については、「Data Guard
の構成」の項を参照してください。
必要なすべてのハードウェアとソフトウェア機能を備えているにもかかわらず、堅実な運用プラクティスを持たないアー
キテクチャは、最終的には可用性サービス・レベルを満足できません。運用上のベスト・プラクティスにより次のことが
可能になり、可用性が最大限維持されます。
•
停止の防止
•
潜在的な問題の検出
•
許容できる MTTR 内での停止からのリカバリ
運用上のベスト・プラクティスは、実務的コンポーネントと技術的コンポーネントに分類されます。実務的コンポーネン
トは、IT インフラストラクチャ管理の基礎となるプラクティス、および処理およびポリシーの管理の対象となるプラク
ティスを含みます。実務的ベスト・プラクティスには、堅実な変更管理ポリシー、バックアップおよびリカバリ計画、停
止からのリカバリ計画、スケジュールされた停止計画、適切なスタッフ研修、完全なドキュメント・プラクティス、堅実
なセキュリティ・ポリシーの手順などがあります。これらの処理とポリシーにより、IT での問題の発生をほとんど防止
し、問題発生時にはリカバリ計画を提供できます。
技術的コンポーネントは、問題の防止、検出、解決のために使用される具体的な技術詳細やインフラストラクチャを提供
します。技術的ベスト・プラクティスには、次のものが含まれます。
•
配置前に完全なテストを行うための QA およびテスト・システム
•
単一の障害箇所、および停止の原因となる不正な行動に対処する冗長でセキュアなシステム・スタック
•
問題を迅速に検出、防止、通知し、可能であれば問題を解決する監視インフラストラクチャ
•
ほとんどの一般的な停止を解決する自動リカバリ・インフラストラクチャ
実務的ベスト・プラクティスと技術的ベスト・プラクティスのコンポーネントの詳細は、付録「運用上のベスト・プラク
ティス」を参照してください。
オープンなインターネット標準の上に構築された Oracle Enterprise Manager（OEM）スィート製品群は、複数の異なる環
境をサポートする設計がされた初めての包括的な管理フレームワークです。OEM コンソールが、すべての管理タスクを
実行するプライマリ・インタフェースとなります。複数の管理者を配置できる信頼性の高いスケーラブルなリポジトリに
より、共同管理が可能になります。標準 Web ブラウザを使用して、様々な場所から OEM のすべての管理領域にアクセ
スできます。OEM 製品ファミリーを使用すると、データベース管理者と IT 責任者は、生産性を向上させ、より優れたサ
ービスを提供し、情報システムのトータル・コストを削減できます。
Maximum Availability Architecture
2-7
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
アーキテクチャの概要
OEM の機能:
•
完全な Oracle 環境を管理する統一アーキテクチャ
•
管理ポイントを単一化する集中コンソール
•
リアルタイムによる監視
•
分散データベース管理
Oracle Enterprise Manager は、グローバル企業の管理と監視にオラクル社が提供する単一の統合されたソリューションで
す。高可用性の実現には、連続的なサービス可用性、スケーラビリティ、シンプルな管理、サービス・パフォーマンス最
適化およびレポート作成が必要です。これらの要件を満たすため、Oracle Enterprise Manager には、イベントのリアルタ
イム監視、分散データベース管理、パフォーマンスおよび可用性データの収集と分析、Oracle 環境の自動チューニング、
および適切に統合されたレポート作成機能が用意されています。OEM は、管理者が一元的にシステムを把握し、データ
ベースやアプリケーションなどのリンクされた個別のサービスの関連付けと構成を行い、24 時間年中無休でシステムの
健全性を効率的に監視し、対応できる効率的なシステム管理を提供します。
Oracle Enterprise Manager の詳細は、「Enterprise Manager での監視と管理」の項を参照してください。
Maximum Availability Architecture
2-8
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
第 2 部: MAA 構成のベスト・プラクティス
第 2 部では、Maximum Availability Architecture（MAA）を作成する構成のベスト・プラクティスについて説明します。こ
こでは、実装が必要なものと、その理由を中心に説明します。次の構成のベスト・プラクティスの項に分かれています。
•
3 項「システム構成」
•
4 項「ネットワーク構成」
•
5 項「データベース構成」
•
6 項「Data Center の MAA」
Maximum Availability Architecture
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
システム構成
3.
MAA 環境を構成する総合的な目標は、簡潔さとパフォーマンスを低下させずに冗長で信頼性の高いシステムとデータベ
ースの作成です。この項では、MAA データベース・サーバー層を構成するサブコンポーネントを作成する推奨事項につ
いて説明します。次の項目を説明します。
•
ストレージ
•
サーバー・ハードウェア
•
サーバー・ソフトウェア（Oracle ソフトウェアを含む）
注意: 以降の項では、サーバーのハードウェアとソフトウェアにおいて高可用性を保持するいくつかの重要事項について
重点的に説明します。ただし、利用しているベンダーの可用性の高いアーキテクチャ、ベスト・プラクティス、およびハ
ードウェア、オペレーティング・システム、クラスタ構成の推奨事項を参照することも重要です。
3.1
ストレージ
電子的なデータは、すべてのビジネスの最も重要な財産の 1 つです。このようなデータをデータを保護し、アクセス可能
にするストレージ・アレイは、企業の成功に不可欠です。この項では、管理性とパフォーマンスを維持したうえで、デー
タを保護するフォルト・トレランスのストレージ・サブシステムの特性について説明します。ここでは、ストレージに関
する次の推奨事項について詳しく説明します。
•
すべてのハードウェア・コンポーネントを完全に冗長でフォルト・トレラントにする
•
サービス可能なアレイをオンラインで使用する
•
ハードウェア・レベルの RAID 機能を使用する
•
物理的なインタフェース全体で I/O の負荷を均衡化する
•
Stripe and Mirror Everything（SAME）を使用して新しい構成のディスクを構成する
•
Hardware Assisted Resilient Data（HARD）を実装する必要性を検討する
注意: 以降の項では、高可用性のストレージ・サブシステムのいくつかの主要な要件について重点的に説明します。ただ
し、ストレージ・ベンダーの可用性の高いアーキテクチャ、ベスト・プラクティス、およびストレージ・アレイのハード
ウェア、オペレーティング・システム、クラスタ構成の推奨事項を参照することも重要です。
3.1.1
すべてのハードウェア・コンポーネントを完全に冗長でフォルト・トレラントに
する
ストレージ・アレイのすべてのハードウェア・コンポーネントについては、物理的なインタフェースから物理的なディス
クにいたるまで、電源供給やアレイ自身への接続の冗長も含めて、十分に冗長性を持たせる必要があります。
ストレージ・アレイは、（ホット・スペアとも呼ばれる）1 つまたは複数の予備のディスクが必須になります。物理ディ
スクがインフラストラクチャの監視に対するエラーを記録し始めた場合や、突然障害が発生した場合には、障害が発生し
たディスクの内容を予備のディスクにミラーリングして、ファームウェアはすぐにフォルト・トレランスをリストアする
必要があります。
Maximum Availability Architecture
3-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
システム構成
ストレージ・アレイへの接続は、十分に冗長性を持たせ（マルチパスともいう）、いずれかのノードから共有ディスク・
アレイへのデータ・パス（コントローラ、インタフェース・カード、ケーブル、スイッチなど）の単一のコンポーネント
における障害が透過になり、アレイを常にアクセス可能にする必要があります。これにより、複数の物理的なパスを介し
て同じ論理デバイスに対してアドレッシングできます。ホストベースの論理ボリューム・マネージャは、有効な（障害が
発生していない）物理インタフェースのいずれかに対して I/O を再発行します。
ストレージ・アレイに書込みキャッシュが含まれている場合は、メモリー・ボードの障害から保護するため、書込みキャ
ッシュのミラー化が必要です。複数のバッテリーをバックアップすることによって、外部のすべての電源供給の障害に対
して書込みキャッシュを保護する必要があります。キャッシュは、外部の電源が元に戻るまでバッテリーを長時間バック
アップするか、またはキャッシュ内の使用済ブロックがすべて、物理ディスクに完全にフラッシュされるように、継続し
て使用します。
3.1.2
サービス可能なアレイをオンラインで使用する
物理コンポーネントで障害が発生した場合は、アレイを停止またはオフラインにせずに、サービスを継続して提供したり、
障害が発生したデバイスを置き換える必要があります。また、ストレージ・アレイでは、ストレージ・アレイの停止なく
ファームウェアのアップグレードやパッチも必要になります。
3.1.3
ハードウェア・レベルの
機能を使用する
ハードウェア・レベルのRAID機能を使用す
機能を使用する
パフォーマンスの理由から、ストレージ・アレイは、ハードウェア・レベルで RAID 機能を実装する必要があります。ス
トレージ・アレイには、少なくともハードウェア RAID-1（ミラーリング）の構成が必要です。ストレージ・アレイがハ
ードウェアの他に RAID-1 ハードウェア RAID 1+0（ミラーリングとストライピング）を提供している場合は、より大き
なストレージ・アレイでの使用が必要です。ハードウェア RAID 1+0 の構成では、アレイは物理ディスクのサイズよりも
大きなホスト論理デバイスを提示できます。これは、データのホストに必要な物理デバイスの数が、オペレーティング・
システムの制限を超える VLDB 環境では特に有効です。
3.1.4
物理的なインタフェース全体でI/Oの負荷を均衡化する
物理的なインタフェース全体で の負荷を均衡化する
物理インタフェース間での I/O 処理の負荷の均衡化（ロード・バランシング）は、通常、ホストにインストールされてい
るソフトウェアのパッケージによって行われます。このロード・バランシング・ソフトウェアの目的は、いずれかのホス
ト・バス・アダプタ（HBA）が現在のワークロードによってオーバーロード（過負荷）になった場合に、I/O の処理をあ
まりビジーではない物理インタフェースにリダイレクトすることです。
3.1.5
Stripe and Mirror Everything（
（SAME）を使用してディスクを構成する
）を使用してディスクを構成する
SAME 構成は、簡単で効率がよく、可用性の高いストレージ構成を提供します。この構成の基本的な概念は、大規模なデ
ィスク・セットにおいて広範囲にストライピングを使用するものです。
1
http://otn.oracle.com/deploy/availability/pdf/oow2000_same.pdf の『Optimal Storage Configuration Made Easy』 では、SAME
構成、および簡単で効率がよく可用性の高いストレージ構成をどのように提供するかを説明します。
この SAME に関するドキュメントに記載されている内容の検証に、オラクル社の内部で調査しました。SAME の方法論
を検証するための詳しいテストについては、OTN の http://otn.oracle.com/deploy/availability/pdf/SAME_HP_WP_112002.pdf
を参照してください。
MAA における SAME の検討には、次の内容の評価が必要です。
1
『Optimal Storage Configuration Made Easy』Juan Loaiza、オラクル社
Maximum Availability Architecture
3-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
システム構成
•
SAME セットの数を決定する
•
構成済システムの非 SAME 構成
SAMEセットの数を決定する
シングル・インスタンス環境では、データベース・ファイル・システムに対するすべての論理ボリュームを 1 つの SAME
セット上に作成できます。ただし、RAC に対しては、Oracle データ・ファイルが共有 RAW デバイス上に常駐している、
2 つ以上の SAME セットがオペレーティング・システム上に必要です。論理ボリューム・マネージャでは現在、ファイル・
システムを共有 RAW デバイスと同じディスク・グループ上に常駐できません。したがって、Oracle ソフトウェアで使用
されるシステム、構成ファイル、およびアーカイブ REDO ログ・ファイルは、共有 RAW デバイスで使用される SAME
セットとは別の SAME セットに常駐が必要です。
このため、2（N）ノードの RAC では、（2+N）個の SAME セットが 4 個必要になります。これには、次の意図がありま
す。
•
Oracle データ・ファイル、コントロール・ファイル、およびオンラインとスタンバイの REDO ログ・ファイルの
共有 RAW ボリュームに対して 1 つの共有データ・エリア
共有データ・エリア SAME セットを使用します。
セット
•
バックアップ・エリア SAME セットとして
1 つ使用します。このエリアには、リカバリおよびテストのリカバ
セット
リ・プロシージャで使用するファイルが含まれます。バックアップ・エリアは、データベースのバックアップが
含まれる UNIX ファイル・システムで構成します。バックアップ・エリアは 1 つのノードに対してのみローカル
です。ただし、そのノードで障害が発生した場合には、クラスタ内の他のすべてのノードが、バックアップ・エ
リアにアクセスおよびマウントできる必要があります。
•
クラスタ内の各ノード上にマウントされているファイル・システム（Oracle ソフトウェア、構成ファイル、アー
カイブ REDO ログ・ファイルなど）に対して、ノードごとに
ノードごとに 1 つのローカルデータ・エリア
つのローカルデータ・エリア SAME セットを使
セット
用します。このファイル・システムはファイル・システムのキャパシティ要件をサポートするために必要な数の
ディスク上でストライプ化が必要です。
オラクル社では、SAME セットを割り当てる場合に次のアプローチを推奨しています。
•
各ローカル・データのエリア・ファイル・システムに対して 1 つの SAME セットを割り当てる
•
すべてのデータベース・バックアップを格納するためのバックアップ・エリアに対して 1 つの SAME セットを割
り当てる
•
ストレージ・アレイ内の残りのディスクを、共有データ・エリア用の 1 つの SAME セットに割り当てる
次の表は、各 SAME セットの内容について説明しています。
表3-1: サイトごとの各SAMEセットの内容
セットの内容
サイトごとの各
内容
数
コメント
共有データ・エリア:
1 つを各ノードが
コントロール・ファイル、データ・ファ 共有
イル、オンラインおよびスタンバイ
REDO ログ・ファイル
クラスタ内のすべてのホストでアドレッシング可能な
共有ディスク・グループ上に格納される
バックアップ・エリア:
1 つを各ノードが
RMAN バックアップ・セットまたはデー 共有
タベース・バックアップ
バックアップ・エリアは 1 つのノードに対してのみロー
カル。ただし、そのノードで障害が発生した場合には、
クラスタ内の他のすべてのノードが、バックアップ・エ
リアにアクセスおよびマウントできる必要がある
ローカルデータ・エリア:
クラスタ内のノー
アーカイブ REDO ログ・ファイルと構成 ドごとに 1 つ
ファイル
排他的なディスク・グループ上に格納され、1 つのホス
トによってマウントされる
次の図は、ストレージ・アレイ内の各ディスクの内容を分析した例です。
Maximum Availability Architecture
3-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
システム構成
図3-1: ストレージ・アレイの詳細図
構成済システムの非SAME構成
新しいデータベース・アプリケーション、または既存のアプリケーションに追加される新しいストレージでは、SAME
を使用します。現在のストレージ構成を適切に機能させるために、既存のアプリケーションをチューニング済のお客様は、
MAA のサポートに特にストレージを再編成する必要はありません。MAA の実装は、全体的には、ベースとなるデータ
構成に依存しません。他のストレージ構成のベスト・プラクティスをすべて適用できます。
3.1.6
Hardware Assisted Resilient Data（
（HARD）を実装する必要性を検討する
）を実装する必要性を検討する
2
HARD イニシアティブ は、データの破損を未然に防ぐことを目的としたプログラムです。データの破損はごくまれです
が、実際にデータが破損するとビジネスは致命的な影響を受けます。HARD イニシアティブをベースとして、Oracle のス
トレージ・パートナーは、ストレージ・デバイス内に Oracle のデータ検証アルゴリズムを実装しています。これによっ
て、破損したデータが永続的なストレージに書き込まれません。HARD の目標は、コンピュータ産業では防ぎようがな
い障害を排除することです。RAID はデータを物理的に確実に保護することで、ストレージ業界から幅広く支持を得てい
ますが、HARD は物理ビットの保護からビジネス・データの保護へと進化することで、データ保護を 1 つ上のレベルに高
めています。
データの破損前に破損を未然に防ぐため、Oracle は、破損を検出および排除するシステムを作成する高度なストレージ・
デバイスを密接に統合しています。オラクル社は業界をリードするストレージ・ベンダーとして機能し、ストレージ・デ
バイス内でオラクル社のデータ検証およびチェック・アルゴリズムを実装してきました。Oracle が HARD で対処するデ
ータの破損には、次のものがあります。
2
『End-to-End Validation of Oracle Database Blocks』Wei Hu, J. Bill Lee、Juan Loaiza、Oracle社、2001年11月
Maximum Availability Architecture
3-4
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
システム構成
•
物理的および論理的に破損したデータ・ファイル、コントロール・ファイル、ログ・ファイル・ブロックを書き
込む
•
不正な場所に対して Oracle ブロックを書き込む
•
Oracle 以外のプログラムにより Oracle データへ不正な書込みをする
•
部分的または不完全なブロックを書き込む
オラクル社で使用する主なアプローチは、エンド・トゥ・エンドのブロック検証で、それによってオペレーティング・シ
ステムまたはストレージ・サブシステムは Oracle のデータ・ブロックのコンテンツを検証します。ストレージ・デバイ
ス内の Oracle データを検証することによって、データが永続的なストレージに書き込まれる前に、破損が検出および排
除されます。これは、次の物理的な読込みまで、不正な、または消失または破損した書込みを検出できない現在の Oracle
の検証機能よりも優れています。
Oracle のストレージ・パートナーは、仕様に基づいて検証チェックを実装することがあります。ベンダーの実装は、自身
のストレージ・テクノロジに特有な独自の機能を提供する場合があります。オラクル社は、製品および Oracle のバージ
ョンによって分類した各ベンダーのソリューションの比較を Web サイトで管理しています。最新情報は、
http://otn.oracle.com/deploy/availability/htdocs/HARD.html を参照してください。
現在の HARD の実装では、オンライン REDO ログ・ファイルを Oracle データ・ファイルおよびコントロール・ファイル
とは別の SAME セットに格納しなければならないという制約があります。これは、Oracle データ・ファイル、REDO ロ
グ・ファイル、およびコントロール・ファイルをすべて同じ SAME セットに格納すると、それぞれの推奨事項で矛盾が
発生するためです。したがって、ストレージでこのような HARD の実装を使用している場合は、オンライン REDO ログ・
ファイル用に別の SAME セットが必要になります。オンライン REDO ログ・ファイルに対して、SAME セットのディス
ク数を構成する場合には、この SAME セットが、ピーク時のスループットにおいても REDO ログの生成率をサポートで
きるかをテストします。
Maximum Availability Architecture
3-5
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
システム構成
3.2
サーバー・ハードウェア
サーバー・ハードウェアに関する推奨事項は、プライマリ・サイトとセカンダリ・サイトの両方に適用されます。これは、
これらの両方のサイトで同じ構成が必要なためです。メインのハードウェア・コンポーネントは、データベースとアプリ
ケーション・サーバー・ファーム・ノード、各ノード内のコンポーネント（CPU、メモリー、I/O やネットワークなどの
インタフェース・ボード）、クラスタ・インターコネクト、および共有ストレージです。ストレージの構成のベスト・プ
ラクティスについては、「ストレージ構成のベスト・プラクティス」を参照してください。
図3-2: サーバー・ハードウェアの構成
サーバー・ハードウェアの推奨事項は次のとおりです。
•
サポートされているクラスタ化システムを使用して RAC を実行する
•
クラスタ内のすべてのノードに対して類似のハードウェアを使用する
•
適切なクラスタ・インターコネクトを選択する
•
コンポーネントの数を少なくし、高速で稠密なコンポーネントを使用する
•
ホットスワップが可能な冗長性のあるハードウェア・コンポーネントを使用する
•
自動的に障害を検出し、代替えパスの提供や、障害が発生したサブシステムの分離が可能なシステムを
使用する
•
3.2.1
ブート・ディスクおよびバックアップ・コピーを保護する
サポートされているクラスタ化システムを使用してRACを実行する
を実行する
サポートされているクラスタ化システムを使用して
RAC は、ノードおよびインスタンスの障害から、高速かつ自動でリカバリをする MAA の主要なコンポーネントです。
RAC の実装を成功させるためには、適切にサポートされている構成が必要です。サポートされているハードウェア構成
には、サーバー・ハードウェア、ストレージ・アレイ、インターコネクト・テクノロジ、および他のハードウェア・コン
ポーネントが含まれます。
Maximum Availability Architecture
3-6
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
システム構成
3.2.2
クラスタ内のすべてのノードに対して類似のハードウェアを使用する
クラスタ内のすべてのノードに類似のハードウェアを使用すると、シンメトリックな環境が実現され、管理と保守が容易
になります。このようなシンメトリックな構成では、障害時のリカバリ中、ハードウェアが異種であることによる障害ま
たはパフォーマンスの矛盾が緩和されます。
3.2.3
適切なクラスタ・インターコネクトを選択する
インターコネクトを選択する場合、冗長性を備えており、高速で待機時間が少なく、複数の有効なパスにおいて負荷の均
衡化を考慮します。スイッチベースのインターコネクト・ソリューションを、直接接続の代わりに選択してください。
3.2.4
コンポーネントの数を少なくし、高速で稠密なコンポーネントを使用する
低速な CPU を多数使用する代わりに高速な CPU を少数使用し、密度の低いメモリー・モジュールを多数使用する代わり
に密度の高いメモリー・モジュールを少数使用します。これによって、同じサービス・レベルを保持したまま、障害が発
生する可能性のあるコンポーネントの数を削減できます。これについては、コストと冗長性の点でバランスをとる必要が
あります。
3.2.5
ホットスワップが可能な冗長性のあるハードウェア・コンポーネントを
使用する
冗長なハードウェア・コンポーネントを使用すると、障害が発生したコンポーネントをオフラインのまま、動作中のコン
ポーネントにフェイルオーバーが可能になります。ハードウェア障害の修復によって発生する計画外停止の回避には、電
源装置、冷却ファン、インタフェース・ボードなどのホットスワップ可能なコンポーネントが必要です。冗長なコンポー
ネントで障害が発生しても、それがホットスワップ可能であれば、障害が発生したコンポーネントの処理の停止は起こり
ません。
3.2.6
自動的に障害を検出し、代替えパスの提供や、障害が発生したサブシステムの分
離が可能なシステムを使用する
コンポーネントで障害が発生しても継続して稼働し、システムを完全に停止することなく、障害が発生したコンポーネン
トに対して自動的に対処できるシステムを選択します。たとえば、アダプタの障害が発生した場合に I/O 要求に対する代
替えパスを使用できる、またはメモリー・ボードの障害時に物理的に不正なメモリーの場所を回避できるシステムを使用
します。
3.2.7
バックアップ・コピーでブート・ディスクを保護する
予想外にファイルが削除された、またはブート・ディスクが破損した場合はミラーリングでは保護できないため、ブート・
ディスクのコピーを作成しておく必要があります。多くの OS ベンダーは、複数のブート・イメージを簡単に管理できる
メカニズムを提供しています。
Maximum Availability Architecture
3-7
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
システム構成
3.3
サーバー・ソフトウェア
プライマリ・サイトとセカンダリ・サイトには同じ構成が含まれているため、サーバー・ハードウェアについては、サー
バー・ソフトウェアの推奨事項がこれらの 2 つのサイトにも適用されます。サーバー・ソフトウェアの推奨事項は次のと
おりです。
•
サポートされているクラスタリング・ソフトウェアを使用して RAC を実行する
•
すべてのノードで同じオペレーティング・システムのバージョン、パッチ・レベル、ワンオフ・パッチ、およ
びドライバのバージョンを使用する
•
ハードウェアの障害に対してフォルト・トレラントなオペレーティング・システムを使用する
•
スワップを適切に構成する
•
将来的な拡張に対処できるようにオペレーティング・システムのパラメータを設定する
•
ロギングまたはジャーナル・ファイル・システムを使用する
•
Oracle およびアプリケーション・ソフトウェアが含まれているディスクをミラー化する
3.3.1
サポートされているクラスタリング・ソフトウェアを使用してRACを実行する
を実行する
サポートされているクラスタリング・ソフトウェアを使用して
RAC は、ノードおよびインスタンスの障害から、高速かつ自動でリカバリをする MAA の主要なコンポーネントです。
正規にサポートされている構成の使用がポイントです。サポートされているソフトウェア構成には、オペレーティング・
システムのバージョンとパッチ・レベル、クラスタリング・ソフトウェアのバージョン、または Oracle が提供するシス
テム・ソフトウェアが含まれています。Oracle9i Database では Linux、Windows などいくつかのプラットフォーム、Oracle
Database 10g ではすべてのプラットフォームで、RAC の使用に必要なシステム・ソフトウェアをオラクル社で提供してい
ます。
3.3.2
すべてのノードで同じオペレーティング・システムのバージョン、
すべてのノードで同じオペレーティング・システムのバージョン、
パッチ・レベル、ワンオフ・パッチ、およびドライバのバージョンを使用する
OS のバージョンとパッチ・レベルで一貫性を持たせることで、すべてのノード間のソフトウェアの非互換性や小さな矛
盾の可能性を低くできます。あらゆるベンダーが、それぞれ新しいソフトウェアを、すでにリリースされているソフトウ
ェアと組み合せたテストはできません。
3.3.3
ハードウェアの障害に対してフォルト・トレラントなオペレーティング・
システムを使用する
適切なハードウェアとの組合せに、自動的な障害検出をサポートし、代替えパスの提供、および障害が発生したサブシス
テムの分離が可能なオペレーティング・システムを使用します。CPU やメモリー・ボードなどのコンポーネントに障害
が発生しても実行を継続し、（アダプタの障害時に I/O 要求に対して代替えパスを提供するなど）、障害が発生したコン
ポーネントへの代替えパスを自動的に提供できるシステムを選択します。
3.3.4
スワップを適切に構成する
スワップ・パーティションが含まれているディスク・クラッシュがクラッシュした場合に、アプリケーションまたはシス
テムで障害が発生しないよう、スワップ・パーティションが含まれているディスクをミラー化します。
Maximum Availability Architecture
3-8
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
システム構成
ここでは、RAM ベースのスワップではなく、ディスクベースのスワップを使用します。スワップを保存する有効なメモ
リー量が十分でない場合は、すべてのシステム・メモリーをデータベースおよびアプリケーションで使用することをお薦
めします。
TMPFS（ファイルをディスクではなく仮想メモリーに格納する、Solaris の実装）、または/tmp ファイル・システムの格
納にディスクではなく仮想メモリーのみを使用する他のファイル・システム、または他のスクラッチ・ファイル・システ
ムは使用しないでください。これにより、/tmp へ書込みを行うリソース集中型のプログラムが、すべての仮想メモリー
を消費したシステムの停止がありません。
3.3.5
将来的な拡張に対処できるようにオペレーティング・システムのパラメータを設
定する
UNIX の例では、将来的な拡張に対処し、カーネルの再構成やシステムの再起動で処理が停止しないため、共有メモリー
およびセマフォ・カーネル・パラメータを高い数値に設定しています。必要な値よりも大きい値に設定することにより、
オーバーヘッドの発生を回避できるか、または大規模なシステムでは無視できる程度のわずかなオーバーヘッドのみにと
どまることを確認してください。
3.3.6
ロギングまたはジャーナル・ファイル・システムを使用する
ジャーナル・ファイル・システムのロギングによって、システムの再起動の次に必要なファイル・システム・チェックの
数を減らし（またはこのような確認を不要にして）、より高速なシステムの再起動を可能にします。
3.3.7
Oracleおよびアプリケーション・ソフトウェアが含まれているディスクを
およびアプリケーション・ソフトウェアが含まれているディスクを
ミラー化する
プライマリ・サイトとセカンダリ・サイトには同じ構成が含まれているため、サーバーのハードウェアとソフトウェアに
ついては、Oracle ソフトウェアの推奨事項がこれらの 2 つのサイトにも適用されます。ディスク・クラッシュで計画外停
止が発生しないよう、Oracle およびアプリケーション・ソフトウェアが含まれているディスクをミラー化します。
Maximum Availability Architecture
3-9
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
ネットワーク構成
4.
MAA では、フォルト・トレラントな環境を提供できる、プライマリ・サイトとセカンダリ・サイトの 2 つのサイトを作
成します。プライマリ・サイトとセカンダリ・サイトは同一で、冗長なルーティング・システム、インターネットへの複
数の接続、および冗長なロード・バランサ、アプリケーション・サーバー・ファーム、および RAC データベースで構成
されています。通常の処理の間、およびクライアントからのリクエストを受け取らない間は、セカンダリ・サイトはアイ
ドル状態です。プライマリ・サイトでの停止によりサービスを提供できなくなると、通信はセカンダリ・サイトに転送さ
れます。
•
WAN トラフィック・マネージャを使用して、サイトのフェイルオーバー機能を提供する
•
ロード・バランサを使用して、受信した要求を分散する
•
適切なアプリケーション・フェイルオーバーを選択し、実装する
•
すべてのネットワーク・コンポーネントで冗長性を実現する
4.1.1
WANトラフィック・マネージャを使用して、サイトのフェイルオーバー機能を
トラフィック・マネージャを使用して、サイトのフェイルオーバー機能を
提供する
WAN トラフィック・マネージャは、プライマリ・サイトに定義されているサービスに対して最初のアクセスを提供しま
す。これらのマネージャは、プライマリ・サイトが完全に使用できない場合に、サイト・アクセスに対するフェイルオー
バー機能を実現できる、プライマリ・サイトとセカンダリ・サイトに実装されています。異なるネットワーク上で、複数
の WAN トラフィック・マネージャを地理的に分散させて使用すると、プライマリ・サイトが使用できないネットワーク
障害または自然災害の影響を低減できます。
4.1.2
ロード・バランサを使用して、受信した要求を分散する
アプリケーション層のロード・バランサは、論理的にはアプリケーション・サーバー・ファームの前面に定義されており、
アプリケーション・サーバーのグループ上で稼働しているサービスの単一の IP アドレスを外部へ公開します。すべての
リクエストは最初にロード・バランサで処理され、次にアプリケーション・サーバー・ファーム内のいずれかのサーバー
に配置されます。エンド・ユーザーは、自身のリクエストを公開されている IP アドレスへの指定だけで、ロード・バラ
ンサがどのサーバーがリクエストを処理するかを決定します。
中間層でいずれかのアプリケーション・サーバーが要求を処理できない場合は、ロード・バランサは後続のリクエストを
すべて有効なサーバーにルーティングします。ロード・バランサは、すべてのクライアントのリクエストがハードウェア・
ベースの 1 つのロード・バランサを通過した後で、単一の障害箇所が発生しないために、冗長性を備える必要があります。
ハードウェアのいずれかの部分で障害が発生すると、サイト全体が影響を受けます。MAA は、プライマリ・サイトのハ
ートビートを提供するバックアップ・ロード・バランサを備えています。1 つのサイトに 2 つのロード・バランサを用意
し、1 つはスタンバイとして構成して、プライマリのロード・バランサが使用できなくなった場合に有効にします。
4.1.3
適切なアプリケーション・フェイルオーバー
適切なアプリケーション・フェイルオーバーを選択し、実装する
アプリケーション・フェイルオーバーを選択し、実装する
アプリケーションのフェイルオーバーおよびリカバリのポリシーでは、ミッションクリティカルなアプリケーションの耐
障害性を保証する必要があります。システムの停止（計画的または計画外停止）は、いつでも発生する可能性があります。
ただし、障害の後でアプリケーションを自動的に再接続できるよう設計することにより、停止による影響を最小限に抑え
ることができます。ほとんどの場合、停止はエンド・ユーザーにとってシームレスな体験となります。
Maximum Availability Architecture
4-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
ネットワーク構成
クラスタ・ノードまたは RAC インスタンスで障害が発生した場合には、クライアント・アプリケーションは再接続して
処理を再開しておく必要があります。また、クライアント・アプリケーションは、接続を再試行できるなど、成功まで自
動的に接続を再試行する、またはバックアップを取得不可にするアプリケーションで決定できる、のいずれかの機能をユ
ーザーに提供する必要があります。一部のシステムでは、デフォルトの TCP/IP ネットワークのタイムアウトが 10～15
分になります。これは再接続の時間に影響を与えることもあり、場合によってはネットワーク管理者と検討が必要です。
RAC のインスタンスまたはノードの障害は、次のいずれかの方法で処理できます。
•
Transparent Application Failover（TAF）
•
仮想 IP アドレスのフェイルオーバー
•
アプリケーション固有の例外処理
それぞれの方法については、次に詳しく説明します。適切な RAC フェイルオーバーの方法、またはそれぞれの方法の組
合せの選択に役に立つよう、説明の後で、「適切なアプリケーション・フェイルオーバーの選択」の表 4-1 で対比しなが
ら各方法の欠点と利点について説明します。MAA では主に TAF を使用しています。
透過的アプリケーション・フェイルオーバー
透過的アプリケーション・フェイルオーバー
MAA の 3 層の環境では、Oracle Call Interface（OCI）クライアント・アプリケーションがデータベース・サーバーとクラ
イアントの間に存在しており、TAF はアプリケーション・サーバーとデータベース・サーバーの間で接続を透過的にフ
ェイルオーバーします。クライアントは、有効なインスタンスに対して自動的にフェイルオーバーされますが、TAF の
構成では、透過的なフェイルオーバーが実現できるよう事前の設定が必要です。
Oracle8 およびそれ以降の OCI クライアント・アプリケーションは、障害後の自動的な再接続およびコールバック機能に
よってサポートされる自動のステート・リカバリを使用します。これらのクライアント・アプリケーションでは、中断さ
れた SELECT 文およびコールバック機能を再実行し、自動的なステート・リカバリをサポートしています。また Oracle
JDBC と ODBC ドライバは、自動的なデータベースの再接続、および中断された SELECT 文の再実行を、アプリケーシ
ョンの追加コーディングなしでサポートしています。
TAF の構成は、クライアントでデータベースに接続するため接続字列の中で指定します。接続文字列の中では、セッシ
ョンの再確立に管理者が指定します。また、OID LDAP サーバーを使用した接続文字列の別名を使用して、DBA がネッ
トワーク上のすべてのクライアントに TAF をすぐに設定できます。
TAF を使用して、RAC インスタンスまたはセカンダリ・サイト上のデータベースにフェイルオーバーもできます。
仮想IPアドレスのフェイルオーバー
ほとんどのクラスタ・ソフトウェアには、クラスタ内の IP アドレス・リソースを定義し、クラスタ内のノード間でその
リソースをフェイルオーバーする機能が用意されています。仮想 IP アドレスは、障害の発生時には別の物理ホストに再
定義ができるため、クラスタ・システムに対するホスト名のイーサネット・インタフェースに関連付けられている IP ア
ドレスとは異なります。
仮想 IP アドレスは、クライアントの通信で使用されます。クライアントは、各ノードが 1 つの IP アドレスを使用してい
るような、複数のクラスタ・ノード上で稼働している RAC データベースに接続します。ノードで障害が発生すると、ク
ラスタ・マネージャはそのノードの仮想 IP アドレスをその他の（有効な）ノードの 1 つに再ルーティングします。この
仮想 IP アドレスでは、クライアントの接続要求は受け取りません。クライアントは自身のアプリケーション・セッショ
ン内の障害を検出し、元の接続と同様の方法で再接続します。クライアントは Oracle Net の接続時フェイルオーバー機能
を使用し、その他の有効なノード上で仮想 IP アドレスのいずれかを使用しているデータベースに対して接続を再確立し
ます。これによって、障害が発生したノードで、クライアントが TCP/IP のタイムアウトを待機する必要がありません。
このようにしてアプリケーションの高可用性は実現されますが、アプリケーションのリカバリの際には、回復に関するク
ライアント・セッション・データを保存するアプリケーションで指定しておかないと、障害が発生したクライアント・セ
ッションに関連するステート情報が失われます。
Maximum Availability Architecture
4-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
ネットワーク構成
アプリケーション固有の例外処理
次のリカバリ手順をサポートできるよう、カスタム機能についてクライアント・アプリケーションを特別にプログラムお
よびテストが必要です。
1.
フェイルオーバーに関するデータベース・エラーをトラップおよび処理し、Real Application Clusters 内の残りの
インスタンスに再接続する
2.
中断されたいずれかの SQL 問合せ、またはリカバリの際にロールバックされた（まだコミットされていない）
トランザクションを再発行する
適切なアプリケーション・フェイルオーバー
適切なアプリケーション・フェイルオーバーの選択
アプリケーション・フェイルオーバーの選択
MAA では、RAC のインスタンスまたはノードの障害を処理するシナリオにおいて、透過的なアプリケーション・フェイ
ルオーバーを重視します。次の表 4-1 で、前述のフェイルオーバーの方法に関する利点と欠点について説明します。
表4-1: アプリケーション・フェイルオーバーの方法
アプリケーション・フェイルオーバーの方法
方法
利点
仮想 IP アドレス
•
TAF
•
•
アプリケーション
固有の例外処理
欠点
TCP/IP を介してデータベースに接続できる
クライアントは、すべて仮想 IP アドレスで
も機能する
•
障害が発生したクライアント・セッションは
アプリケーションでリカバリする必要があ
り、アプリケーション固有の例外処理が必要
になる
•
クラスタ内にアプリケーションを配置する
ことが必要
•
アプリケーションのフェイルオーバーおよ
びリカバリのポリシーを事前に定義する必
要がある
自動的なフェイルオーバー（クライアントは •
クラスタ内の別のノードに自動的に再接続
される）
•
アプリケーションに対する多少カスタム・コ
ーディングのみを必要とする（またはカスタ
ム・コーディングを必要としない）フェイル
オーバーを実現できる
•
OCI により TAF 関連のコールバックが提供
される（これによりアプリケーションがフェ
イルオーバーを認識できる）
•
Oracle Net の接続時フェイルオーバーおよび
ロード・バランシングとあわせて使用する
と、総合的なフェイルオーバーおよびフェイ
ルバックのソリューションを実現できる
•
アプリケーションに対するより高度な制御
Maximum Availability Architecture
OCI に組み込まれているフェイルオーバー対
応の API コールを使用する必要がある
1 つのノードが停止した場合に、アプリケー
ションが別の SQL 文を実行するまで、停止
したことがアプリケーションで認識されな
い。TAF がトリガーされないこともある
•
アプリケーション内にフェイルオーバーの
ロジックを組み込み、テストする必要がある
•
アプリケーションのフェイルオーバーおよ
びリカバリのポリシーを事前に定義する必
要がある
4-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
ネットワーク構成
4.1.4
すべてのネットワーク・コンポーネントで冗長性を実現する
次の表は、後続の図に示されている必要な冗長ネットワーク・コンポーネントについて説明しています。
表4-2: 冗長なネットワーク・コンポーネント
コンポーネント
外部接続
（リモート IT スタッフなど）
フォルト・トレランス
複数のインターネット・サービス・プロバイダ（ISP）を使用することにより、ISP 障害
発生時にもサイトの可用性を保持できる。
[注意: 道路から施設内に設置するケーブルは異なる幹線に設置し、のこぎりやシャベル
の誤用よって 2 本同時に切断されることを回避する。]
WAN トラフィック・
マネージャ
各サイトでプライマリおよびバックアップの WAN トラフィック・マネージャを使用す
る。
アプリケーション・ロード・
バランサ
各サイトで冗長なロード・バランサを実装する。セカンダリ・ロード・バランサのペア
は、プライマリ・サイトのハートビートと同一に構成する必要がある。プライマリ・ロ
ード・バランサのペアで障害が発生した場合は、セカンダリ・ロード・バランサが処理
を引き継ぐ。
ファイアウォール
プライマリとセカンダリのペアで冗長なファイアウォールとロード・バランシングを実
装する。ファイアウォールを介した接続は長くなる傾向にあるため（ソケット接続
vs.HTTP）、セッションを開始するタイミング、およびセッション全体のどのタイミン
グで保持するかをロード・バランシングで決定する必要がある。使用できる機能につい
ては、ファイアウォールのベンダーに確認してください。
中間層のアプリケーション・
サーバー
フォルト・トレランスおよびスケーラビリティを実現する、アプリケーション・サーバ
ー・ファームを実装する。
次の図は、冗長なネットワーク・コンポーネントを中心とした、MAA 環境の単一サイトを示しています。
Maximum Availability Architecture
4-4
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
ネットワーク構成
図4-1: ネットワーク構成（hb=ハートビート）
ハートビート）
ネットワーク構成（
Maximum Availability Architecture
4-5
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
5.
この項では、次の Oracle 製品および機能に対する構成のベスト・プラクティスについて説明します。
•
Real Application Clusters
•
Oracle Data Guard
•
バックアップと Recovery Manager
5.1
Real Application Clusters
この項では、システムのパフォーマンス、可用性および MTTR に影響するデータベース構成のベスト・プラクティスを
中心に説明します。これらのプラクティスは、プライマリ
プライマリ・データベースでもスタンバイ
スタンバイ・データベースでも同じです。
プライマリ
スタンバイ
オプションによっては、パフォーマンス・レベルの低下がありますが、停止時間の削減や停止回避に不可欠です。パフォ
ーマンスへの多少の影響があっても、破損のリスクを軽減し、リカバリのパフォーマンスを向上させることがより重要で
す。
•
初期化パラメータ用のサーバー・パラメータ・ファイル（SPFILE）を使用する
•
2 つの制御ファイルを使用する
•
プライマリとスタンバイの両方の制御ファイルが含まれているボリュームのサイズを調整し、拡張に対処
できるようにする
•
CONTROL_FILE_RECORD_KEEP_TIME を、すべてのオンディスク・バックアップ情報を制御ファイルに
格納できる値に設定する
•
本番およびスタンバイの REDO ログとグループのサイズを適切に調整する
•
本番およびスタンバイの REDO ログを多重化する
•
ARCHIVELOG モードを有効化し、自動アーカイブを使用する
•
ブロック・チェックサムを有効化する
•
データベース・ブロック・チェックを有効化する
•
アラート・ログにチェックポイントを記録する
•
ファスト・スタート・チェックポインティングを有効化する
•
タイミングに関するパフォーマンス統計を収集する
•
自動 UNDO 管理を使用する
•
ローカル管理表領域を使用する
•
自動セグメント領域管理を使用する
•
一時表領域を使用し、デフォルト一時表領域を指定する
•
再開可能領域割当てを使用する
•
THREAD、INSTANCE_NUMBER、INSTANCE_NAME の各データベース・パラメータを設定する場合の
一貫性を確保する
Data Guard に特有な構成のベスト・プラクティスについては、次の「Oracle Data Guard」の項を参照してください。
Maximum Availability Architecture
5-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
この項に記載および説明されているいくつかの推奨事項は、次の表に示す 1 つまたは複数のパラメータ設定に対応してい
ます。データベース・レベルのパラメータには先頭に*が付加され、インスタンス固有のパラメータには、（SPFILE で指
定されているように）先頭に ORACLE_SID という値が付加されています。これらのサンプル設定は、ORACLE_SID の値
が SALES1 と SALES2 である 2 つのインスタンスを持つ、SALES というデータベースを対象としています。表内のパラ
メータに関連する推奨事項、および対応するデータベース・パラメータを持たない推奨事項については、後で詳しく説明
します。
表5-1: RACの初期化パラメータのベスト・プラクティス
の初期化パラメータのベスト・プラクティス
パラメータ名（SPFILE
に指定されている）
パラメータ名（
推奨されるパラメータ値またはサンプル設定
*.CONTROL_FILES
/dev/vx/rdsk/oradg/control01, /dev/vx/rdsk/oradg/control02
*.CONTROL_FILE_RECORD_KEEP_TIME
30
*.LOG_ARCHIVE_START
TRUE
*.DB_BLOCK_CHECKSUM
TRUE
*.DB_BLOCK_CHECKING
TRUE
*.LOG_CHECKPOINTS_TO_ALERT
TRUE
*.FAST_START_MTTR_TARGET
300
*.LOG_CHECKPOINT_INTERVAL
0
*.LOG_CHECKPOINT_TIMEOUT
0
*.FAST_START_IO_TARGET
0
*.TIMED_STATISTICS
TRUE
*.UNDO_MANAGEMENT
AUTO
SALES1.UNDO_TABLESPACE
undo01
SALES2.UNDO_TABLESPACE
undo02
*.DB_NAME
論理スタンバイの場合は SALESSALES_LOG
1
SALES1.THREAD
2
SALES2.THREAD
1
SALES1.INSTANCE_NUMBER
2
SALES2.INSTANCE_NUMBER
SALES1
SALES1.INSTANCE_NAME
SALES2
SALES2.INSTANCE_NAME
5.1.1
初期化パラメータ用のサーバー・パラメータ・ファイル（SPFILE）を使用する
）を使用する
初期化パラメータ用のサーバー・パラメータ・ファイル（
RAC 環境では、SPFILE を使用して、一括管理された単一パラメータ・ファイルで、RAC データベースに含まれているす
べてのインスタンスに関連するデータベースの初期化パラメータをすべて保持できます。これによって、データベース・
パラメータを管理するうえで、シンプルで一貫性のある堅牢な環境が実現します。付録の「SPFILE のセットアップと管
理」の詳細、および「MAA SPFILE」のテキストを参照してください。
参照: 『Oracle9i データベース管理者ガイド』および『Oracle9i Real Application Clusters セットアップおよび構成』
5.1.2
2つの制御ファイルを使用する
つの制御ファイルを使用する
冗長性の実現に、制御ファイルの 2 つのコピーを保持します。1 つのデータベースに対して複数の制御ファイルを管理す
ると、制御ファイルに関する単一の障害箇所について安全性が確保されます。1 つの制御ファイルが破損すると、いずれ
かの Oracle インスタンスによる破損した（または不明な）制御ファイルへのアクセスは失敗します。ただし、対象の制
Maximum Availability Architecture
5-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
御ファイルにもう 1 つのコピーが使用できる状態であれば、有効な制御ファイルをエラーの発生した制御ファイルの場所
にコピー後、データベースをリカバリせずにインスタンスを簡単に再起動できます。
また、制御ファイルの停止を短時間で完全に解決するためには、制御ファイルのバックアップを頻繁に保存すること、お
よびバックアップのたびに制御ファイルのスクリプトを更新しておく必要があります。
参照: 『Oracle9i データベース管理者ガイド』
5.1.3
プライマリとスタンバイの両方の制御ファイルが含まれているボリュームの
サイズを調整し、拡張に対処できるようにする
アーカイブ・ログが生成され、RMAN バックアップが作成される場合には、Oracle によって、制御ファイルの再利用可
能なセクションに対して新しいレコードが追加されます。再利用できるレコードがない場合（すべてのレコードが、
CONTROL_FILE_RECORD_KEEP_TIME で指定されている有効期限内にあるなど）は、制御ファイルが拡張されて新し
いレコードが追加されます。制御ファイルの最大サイズは、20000 データベース・ブロックです。db_block_size=8192 の
場合は、制御ファイルの最大サイズは 156MB になります。クラスタ・ファイルシステムではなく、制御ファイルが事前
に作成されたボリュームに格納している場合は、制御ファイルの最大サイズを調整して、本番用およびスタンバイの制御
ファイルが含まれているボリュームのサイズに対応が必要です。制御ファイルのボリュームが小さすぎて拡張できない場
合は、再利用前に、制御ファイルの現在のレコードを上書きします。この動作は、アラート・ログの次のメッセージによ
って示されます。
「krcpwnc: following controlfile record written over:」
アラート・ログでは、制御ファイルのボリューム・サイズが適切に設定されていないことを表すこれらのメッセージに注
意してください。
参照: 『Oracle9i Recovery Manager ユーザーズ・ガイド』
5.1.4
CONTROL_FILE_RECORD_KEEP_TIMEを、すべてのオンディスク・
を、すべてのオンディスク・
バックアップ情報を制御ファイルに格納できる値に設定する
バックアップ情報を制御ファイルに格納できる値に設定する
CONTROL_FILE_RECORD_KEEP_TIME は、制御ファイル内のレコードを保存する日数を表します。ここで指定された
日数が経過すると、レコードは再利用可能になります。CONTROL_FILE_RECORD_KEEP_TIME の値は、バックアップ・
エリアのサイズによって決められるため、ディスク上に保存する最も古いバックアップ・ファイルよりも少し長い期間に
設定します。この値よりも古いレコードは再利用されます。ただし、バックアップ・メタデータは RMAN のリカバリ・
カタログでは使用可能です。
参照: 「Backup Recovery Best Practices」の項および『Oracle9i Recovery Manager ユーザーズ・ガイド』
5.1.5
本番およびスタンバイのREDOログとグループのサイズを適切に調整する
ログとグループのサイズを適切に調整する
本番およびスタンバイの
本番用およびスタンバイのすべての REDO ログはすべて同じサイズに設定し、
通常のアクティビティでは約 1 時間ごと、
ピーク時のアクティビティでは 20 分ごとにダイアログをスイッチできるサイズを調整する必要があります。ただし、セ
カンダリ・サイトへのフェイルオーバーが必要な停止に対する MTTR は、スタンバイ・データベースのリカバリ時間に
直接影響されるため、REDO ログ・ファイルのサイズによって決定されます。REDO ログのサイズを大きくすると、リカ
バリ時間が長くなります。これは、REDO ログのサイズを決定するうえでの重要な要因となります。詳細は、「Oracle Data
Guard」を参照してください。
ログ・スイッチの後で、チェックポイントが完全ではない、またはグループがまだアーカイブされいない理由でグループ
が使用可能になるのを LGWR が待つことがないよう、最低 4 つの本番用ログ・グループを用意します。
参照: 『Oracle9i データベース管理者ガイド』および『Oracle9i Data Guard 概要および管理』
Maximum Availability Architecture
5-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
5.1.6
本番およびスタンバイのREDOログを多重化する
ログを多重化する
本番およびスタンバイの
Oracle ログの多重化を使用して、1 つの REDO グループについて複数の本番およびスタンバイ REDO ログ・メンバーを作
成します。これによって、いずれかのメンバーに対するディスク・ミラーの双方でディスクが破損する、ユーザー・エラ
ーによってメンバーを不注意で削除してしまうなどの REDO ログに関する障害を回避できます。
少なくとも 1 つの REDO
ログ・メンバーが有効であれば、インスタンスは継続して作用できます。
参照: 『Oracle9i データベース管理者ガイド』
5.1.7
ARCHIVELOGモードを有効化し、自動アーカイブを使用する
モードを有効化し、自動アーカイブを使用する
本番用のデータベースは、スタンバイ・データベースのインスタンス化前に ARCHIVELOG モードで実行させておき、ス
タンバイ・データベースを管理できるようにします。ARCHIVELOG モードにすると、データベースはオンラインのまま
バックアップされます。データベースは、リストアされた後の特定のポイントにリカバリする必要があります。
LOG_ARCHIVE_START=TRUE と設定すると、自動的にアーカイブされます。
参照: 『Oracle9i データベース管理者ガイド』
5.1.8
ブロック・チェックサムを有効化する
デフォルトでは、Oracle は常にディスクから読み込むブロックをテストしています。DB_BLOCK_CHECKSUM=TRUE に
設定してログ・ブロックのチェックサムを有効化すると、ベースとなるディスク、ストレージ・システム、または I/O シ
ステムによって発生する異なるタイプの破損を検出できます。データ・ブロックがディスクに書き込まれる前に、チェッ
クサムが計算されてブロックに格納されます。その後でブロックがディスクから読み込まれる際に、チェックサムが再計
算され、格納されているチェックサムと比較されます。なんらかの違いが認められると、媒体のエラーとして処理され、
ORA-1578 のエラーが示されます。ブロック・チェックサムは、常に SYSTEM 表領域で管理されています。
データ・ブロックのチェックサムを有効するほか、Oracle は、現行のログに対して REDO ログ・ブロックが書き込まれ
る前に、すべての REDO ログ・ブロックのチェックサムも計算しています。REDO レコードの破損は、ログがアーカイ
ブされる際に検出されます。このオプションを使用しない場合は、ログがスタンバイ・データベースに適用されるまで、
またはバックアップがリストアされ、破損したログ・ブロックが含まれているログ全体がロールフォワードされるまで、
REDO ログの破損は検出されません。
バックアップを取得する場合には、RMAN でもチェックサムを計算し、バックアップするすべてのブロックが正しいこ
とを確認します。この場合、チェックサム・エラーのディスクへの書出しを検出するための、アプリケーションによる次
の特定のブロックの読込みは使用されません。
通常はこの機能を有効にして、オーバーヘッドを最少にします。ワークロードを使用している場合のパフォーマンスの影
響はテスト・システムで測定し、このオプションを本番用のデータベースで使用する前に、影響度が許容できる範囲か判
断してください。
参照: 『Oracle9i データベース管理者ガイド』
5.1.9
データベース・ブロック・チェックを有効化する
DB_BLOCK_CHECKING=TRUE を設定して、データベース・ブロックのチェックを有効にします。ブロック・チェック
を有効にすると、ブロックが修正されるたびに、ブロックの一貫性が検証されます。一貫性が失われた場合は、軽度の破
損としてブロックにマークされ、ORA-1578 が発行されます。また、このエラーの詳細が記載されているトレース・ファ
イルが作成されます。ブロック・チェックを有効にしない場合は、ブロックに再度アクセスするまで破損は認識されませ
ん。SYSTEM 表領域のブロック・チェックは常に有効に設定されています。
Maximum Availability Architecture
5-4
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
ブロック・チェックによって、データの破損を回避できることがあります。通常、この機能を有効にしておくと、ワーク
ロードによっては 1～10%のオーバーヘッドが付加されます。実際のパフォーマンスの影響は、ワークロードを使用して
テスト・システムで測定し、このオプションを本番用のデータベースで使用前に、影響度が許容できる範囲か判断してく
ださい。
スタンバイ・データベースでは、
「Oracle9i メディア・リカバリに関するベスト・プラクティス」
（Oracle Technology Network
Japan のhttp://otn.oracle.co.jp/products/oracle9i/index.html#ha参照）のベスト・プラクティスを使用してチューニングしても
REDO の適用レートが十分でない場合は、DB_BLOCK_CHECKING=FALSE を設定すると、スタンバイ REDO 適用に対し
て優れたパフォーマンスが得られます。追加のブロック・チェックは、スタンバイ・データベースに対する REDO 適用
でのみ切り捨てられます。本番データベースでブロック・チェックが常に有効になっており、本番用およびスタンバイの
データベースの両方で DB_BLOCK_CHECKSUM が有効になっている場合は、スタンバイでブロック・チェックを無効に
しても影響はありません。独立したテストでは、REDO 適用レートは 2 倍になりました。
次の検出ツールのいずれかを使用して、オフピークのブロック・チェックも実行の必要があります。
•
RMAN VALIDATE
•
DBMS_REPAIR
•
DBVERIFY
•
ANALYZE TABLE <tablename> VALIDATE STRUCTURE CASCADE
参照: 『Oracle9i データベース管理者ガイド』
5.1.10
アラート・ログにチェックポイントを記録する
LOG_CHECKPOINT_TO_ALERT=TRUE に設定して、チェックポイントのアクティビティをアラート・ログに記録してお
く必要があります。チェックポイントのアクティビティを監視して、次のチェックポイントが始まる前に、現在のチェッ
クポイントが完全であることを確認します。
参照: 『Oracle9i データベース・リファレンス』
5.1.11
ファスト・スタート・チェックポインティングを有効化する
ファスト・スタートのチェックポインティングは、データベース・ライター（DBW）の処理による定期的な書込みを参
照します。これは、変更されたデータ・ブロックを Oracle バッファ・キャッシュからディスクに書き込み、スレッドチ
ェックポイントを進める目的です。間隔値に対して、データベース・パラメータ FAST_START_MTTR_TARGET を 0（秒）
より大きい値に設定すると、ファスト・スタート・チェックポインティングの機能が有効になります。必要なサービス・
レベルを満たすため、RAC 環境でインスタンスまたはノードの障害からリカバリする時間が重要でない場合は、
FAST_START_MTTR_TARGET=3600 に設定します。必要なサービス・レベルを満たすため、インスタンス障害からリカ
バリする時間を制御することが必要な場合は、FAST_START_MTTR_TARGET を、適切な MTTR（秒）に設定します
（FAST_START_MTTR_TARGET=300 など）。
ファスト・スタート・チェックポインティングは、次の理由で常に有効にしておきます。
•
キャッシュ・リカバリに必要な時間が短縮され、インスタンス・リカバリの時間が制限され予想可能になる
•
システムが I/O の最大キャパシティに達していない（または近くない）場合には、ファスト・スタート・チェッ
クポインティングを有効にしても、パフォーマンスにはほとんど影響がない
•
ファスト・スタート・チェックポインティングを使用すると、大量の書込みおよび対応する I/O スパイクが行わ
れない（従来は、これによってインターバルベースのチェックポイントが発生した）
ファスト・スタート・チェックポインティングを有効にする場合には、次の初期化パラメータを削除するか、または無効
（0 に設定）
します。
LOG_CHECKPOINT_INTERVAL、
LOG_CHECKPOINT_TIMEOUT、
および FAST_START_IO_TARGET。
Maximum Availability Architecture
5-5
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
参照: 『Oracle9i データベース・パフォーマンス・チューニング・ガイドおよびリファレンス』および「Oracle9i ファス
ト・スタート・チェックポイントの最良実施例」（http://otn.oracle.co.jp/products/oracle9i/index.html#ha参照）
5.1.12
タイミングに関するパフォーマンス統計を収集する
TIMED_STATISTICS=TRUE に設定して、Oracle イベントのタイミング・データを取得し、パフォーマンスの監視および
パフォーマンスの問題点を適切に診断します。データベース・パラメータ STATISTICS_LEVEL がデフォルトの TYPICAL
に設定されている場合は、このパラメータもデフォルトで TRUE に設定されています。システム・パフォーマンスの問
題点の特定および修正には、データを効果的に収集および分析する必要があります。オラクル社では、パフォーマンス・
エンジニアが、インスタンスおよびデータベースのパフォーマンスに関する情報を収集できる、様々なツールを用意して
います。Oracle ツールを効果的に使用するには、TIMED_STATISTICS=TRUE の設定が必要です。詳細は、『Oracle Tools
to Gather Database Statistics』の「パフォーマンス・チューニング・ガイドおよびリファレンス」のドキュメントを参照し
てください。
参照: 『Oracle9i データベース・パフォーマンス・チューニング・ガイドおよびリファレンス』
5.1.13
自動UNDO管理を使用する
管理を使用する
自動
自動 UNDO 管理を使用すると、Oracle サーバーで効率よく効果的に UNDO 領域を管理して、管理の複雑さとコストを削
減できます。Oracle が UNDO セグメントを内部で管理すると、現行のワークロード要件にあわせて UNDO セグメントの
サイズと数が自動的に調整されるため、UNDO ブロックおよび読込みの一貫性に関する競合が排除されます。
自動の UNDO 管理を使用するには、次のパラメータを設定します。
UNDO_MANAGEMENT = AUTO
UNDO_RETENTION = <the desired time to retain undo data>
UNDO_TABLESPACE = <a unique undo tablespace for each instance>
オブジェクト・レベルのリカバリに対するフラッシュバック問合せなど、いくつかの高度なオブジェクト・リカバリ機能
では、自動 UNDO 管理が必要です。詳細は、付録「停止からのリカバリ」の「フラッシュバック問合せ」を参照してく
ださい。
参照: 『Oracle9i データベース管理者ガイド』
5.1.14
ローカル管理表領域を使用する
ローカルに管理されている表領域は、ディクショナリに管理されている表領域よりもパフォーマンスに優れている、管理
がしやすい、領域の断片化に関する問題が排除されるなどの特長があります。ローカルに管理されている表領域は、ディ
クショナリに管理されている表領域とは異なり、データ・ファイル・ヘッダーに格納されているビットマップを使用して
いて、領域の割当ておよび割当て解除において、集中管理されているリソースを求めた競合はありません。
参照: 『Oracle9i データベース管理者ガイド』
5.1.15
自動セグメント領域管理を使用する
自動セグメント領域管理を使用すると、領域管理が簡単になり、人的エラーの発生を低減できます。その他にも、領域管
理に関するパフォーマンスのチューニングが不要になるという利点があります。また、自動セグメント領域管理によって、
表や索引内などのオブジェクト内の空き領域の管理が簡単になる、領域の使用率が向上する、そのままの状態で優れたパ
フォーマンスとスケーラビリティが実現されるなどの利点もあります。自動セグメント領域管理の機能は、永続的にロー
カル管理される表領域でのみ使用できます。
参照: 『Oracle9i データベース概要』
Maximum Availability Architecture
5-6
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
5.1.16
一時表領域を使用し、デフォルト一時表領域を指定する
一時表領域を使用すると、複数のソート操作の同時性が向上し、ソート操作のオーバーヘッドが減少し、データ・ディク
ショナリの領域管理が不要になります。一時セグメントの処理で一時表領域を使用すると、システム・リソースの使用率
およびデータベース・パフォーマンスの両方の観点から、効率がよくなります。
デフォルトの一時表領域は、一時表領域の句が不用意に排除されないよう、データベース全体に対して指定します。これ
は、CREATE DATABASE 文で DEFAULT TEMPORARY TABLESPACE 句を使用して、データベースの作成時に設定する
こと、ALTER DATABASE 文で後に指定もできます。デフォルトの一時表領域を使用すると、すべてのディスク・ソート
が一時表領域内で発生し、他の表領域が誤ってソート用に使用されなくなるため、非常に有効です。
参照: 『Oracle9i データベース管理者ガイド』
5.1.17
再開可能領域割当てを使用する
再開可能領域割当てを使用すると、領域割当てに失敗した場合、データベース処理を停止し、その後再開できます。領域
割当てに失敗した場合、データベースがエラーの状態まで戻るのではなく、影響があった処理が停止します。領域の問題
がクリアになった後、停止していた処理が自動的に再開されます。すべてのセッションに対して再開可能モードを自動的
に有効にするために、データベース・レベルで LOGON トリガーを登録できます。
参照: 『Oracle9i データベース管理者ガイド』
5.1.18
THREAD、
、INSTANCE_NUMBER、
、INSTANCE_NAMEの各データベース・
の各データベース・
パラメータを設定する場合の一貫性を確保する
THREAD および INSTANCE_NUMBER のパラメータについて、一貫性のあるネーミング規則を使用します。
INSTANCE_NAME は、データベース名（DB_NAME パラメータ）の後に INSTANCE_NUMBER を付加して指定します。
これは、ORACLE_SID の環境変数と一致させる必要があります。付録のサーバー・パラメータ・ファイルの例を参照し
てください。
参照: 『Oracle9i Real Application Clusters 管理』
Maximum Availability Architecture
5-7
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
5.2
Oracle Data Guard
はじめに
この項では、Data Guard スタンバイ・データベースを使用するベスト・プラクティスと推奨事項について詳しく説明しま
す。スタンバイ・データベースは、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベース
のいずれかができます。フィジカル・スタンバイ・データベースは、ブロック単位でプライマリ・データベースと同一な
オンディスク・データベース構造を持つ、プライマリ・データベースと物理的に同一なコピーを提供します。索引も含め
て、データベース・スキーマも同一です。フィジカル・スタンバイ・データベースとプライマリ・データベースとの同期
は、プライマリから受信した REDO データのリカバリにより維持されます。
ロジカル・スタンバイ・データベースには、本番データベースと同じ論理情報が含まれますが、データの物理的編成と構
造は異なっていてもかまいません。プライマリ・データベースから受信した REDO ログのデータを SQL 文に変換し、そ
の SQL 文をスタンバイ・データベースで実行することにより、プライマリ・データベースとの同期が維持されます。ロ
ジカル・スタンバイ・データベースは、障害時リカバリ用としてだけでなく、他の事業目的にも利用できます。したがっ
て、ユーザーもロジカル・スタンバイ・データベースにアクセスできます。
MAA 内では、事業要件に応じて、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベース
のいずれかまたは両方を使用できます。どのタイプのスタンバイ・データベースを使用するかの決定には、次の表を参照
してください。
表5-2: スタンバイ・データベースのタイプ
スタンバイ・タイプ
フィジカル・スタンバイ
（REDO Apply）
利点
考慮点
プライマリ・データベースおよびスタ
ンバイ・データベースでの最小限のリ
ソース・オーバーヘッド
REDO Apply が最も高速で、スタンバ
イ・データベースに対して変更を適用
する場合に最も効率的なアプローチ
プライマリ・データベースと物理的に
同じコピー
READ ONLY でオープンした場合、
REDO は適用されない
プライマリ・データベースをリカバリ
するために使用できるバックアップ
をオフロードするために使用可能
ロジカル・スタンバイ
（SQL Apply）
スタンバイ・データベースを通常の操
作のためにオープン可能
データの物理編成と構造が異なって
いてもかまわない
追加オブジェクトの作成と保守が可
能
フィジカル・スタンバイとともに使用
した場合は、フィジカル・スタンバイ
に対してフェイルオーバーが実行さ
れた際に、ロジカル・スタンバイを再
度インスタンス化することが必要
すべての操作をスタンバイ・ノードで
実行し、プライマリ・ノードには最小
限の補足処理のみを要求
フィジカル・スタンバイに比べ、より
多くのシステム・リソースを使用
表5-3: スタンバイ・データベースのタイプを決定する方法
質問
推奨事項
1. データ分岐のない厳密なデータ消失ゼロを
必要としますか?
Yes − フィジカル・スタンバイ・データベースを使用してください。
No − 次の質問に進んでください。
詳細は、「適切なデータベース保護モードを選
定する」を参照してください。
Maximum Availability Architecture
5-8
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
質問
推奨事項
2. サポートされないロジカル・スタンバイ・デ 次の問合せを実行してください。
ータ型がありますか?
SELECT DISTINCT OWNER,TABLE_NAME FROM
DBA_LOGSTDBY_UNSUPPORTED
ORDER BY OWNER,TABLE_NAME;
行が返された場合: フィジカル・スタンバイを使用するか、サポート
されているデータ型への切替えを検討してください。
行が返されない場合: 次の質問に進んでください。
3. 読込み/書込みアクセスのためにスタンバ
Yes − 次の質問に進んでください。
イ・データベースをオープンする必要があり No − フィジカル・スタンバイを使用してください。
ますか?
4. ロジカル・スタンバイでプライマリ REDO の Yes − ロジカル・スタンバイまたはフィジカル・スタンバイまたは両
方を使用してください。
レートを確保できますか?
詳細は、テクニカル・ペーパー『Oracle9i Data
Guard: SQL Apply のベスト・プラクティス』
（http://otn.oracle.co.jp/products/oracle9i/index.html
#ha）を参照してください。
No − フィジカル・スタンバイを使用するか、ロジカル・スタンバイ
で使用できるシステム・リソースを増やしてください。
Data Guard の設定は、スイッチオーバーまたはフェイルオーバー操作に、両方のデータベースが正しく機能し、サービス・
レベルの範囲内でロールの実行を保証するために必要です。次に、一般的推奨事項（いずれのタイプのスタンバイにも適
用）、フィジカル・スタンバイ・データベースのみに対する推奨事項、およびロジカル・スタンバイのみに対する推奨事
項に分けて、構成の推奨事項のリストを示します。フィジカル・スタンバイとロジカル・スタンバイの両方を使用する場
合、適用プロセス（フィジカル・スタンバイに対しては Managed Recovery（MRP）、ロジカル・スタンバイに対しては
ロジカル・スタンバイ適用プロセス（LSP））は、RAC の別のノードで実行する必要があります。両方を使用する場合は、
次に示す推奨事項がすべて適用されます。
一般
•
シンプルで堅牢なアーカイブ方針と構成を使用する
•
FORCE LOGGING モードを有効化する
•
リカバリ遅延を設定する
•
複数のスタンバイ・インスタンスを構成する
•
LGWR に対する時間ベースのスレッド拡張機能（ARCHIVE_LAG_TARGET=0）を無効化する
•
DB_CREATE_ONLINE_LOG_DEST を設定しない
•
リモート・ミラーリング・テクノロジのかわりに Data Guard を使用する
•
適切なデータベース保護モードを選定する
•
提案されたネットワーク構成でパフォーマンス評価を実施する
•
動的サービス登録のためのデータベースとリスナーを構成する
•
Data Guard ネットワーク・サービス・ディスクリプタに対する接続時間フェイルオーバーを構成する
•
代替スタンバイ接続を設定する
•
WAN 環境でネットワークのチューニングを評価する
•
データ消失ゼロの保護モードの場合、LAN または MAN ネットワーク環境を使用する
•
データ消失ゼロの保護モードの場合、SYNC=NOPARALLEL 属性を設定する
•
スループットのパフォーマンスを最大にするためにアーカイブ転送を使用する
Maximum Availability Architecture
5-9
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
•
WAN 上の最大パフォーマンス・モードで、圧縮付き SSH ポート転送の実装を評価する
•
OS ネットワーク TCP の送信および受信のバッファ・サイズを、帯域遅延積に設定する
フィジカル・スタンバイ・データベースのみ
•
スタンバイ REDO ログを使用する
•
最大パフォーマンス・モードで、10MB のバッファ・サイズを持つ ASYNC 属性を使用する
•
最適なリカバリ・パフォーマンスを得られるようにスタンバイ・データベースとホストをチューニングする
•
1 つのスタンバイ・ホストで CPU の 2 倍の数のパラレル・リカバリを設定する
•
パラレル・リカバリのバッファ・サイズを 4K に設定する
•
スタンバイ上のオンライン REDO ログ・グループを消去する
ロジカル・スタンバイのみ
•
すべての本番表でサプリメンタル・ロギングとプライマリ・キー制約を使用する
•
ロジカル・スタンバイ MAX_SERVERS SQL Apply パラメータを設定する
•
初期化パラメータ PARALLEL_MAX_SERVERS の値を増やす
•
MAX_SGA SQL Apply パラメータに対してデフォルトを使用する
•
_EAGER_SIZE SQL Apply パラメータを 1000 に設定する
•
APPLY_DELAY SQL Apply パラメータを設定する
•
TRANSACTION_CONSISTENCY SQL Apply パラメータを設定する
•
不要なオブジェクトについて SQL Apply をスキップする
•
両方向のデータベース・リンクを作成する
表 5-4 は、Data Guard およびそのオプションについて推奨されるそれぞれの初期化パラメータを示しています。データベ
ース・レベルのパラメータは、SPFILE で指定されているように、先頭に*.が付加されています。これらのサンプル設定
は、ORACLE_SID の値が SALES1 と SALES2 であるような 2 つのインスタンスを持つ、SALES というデータベースを対
象としています。表内のパラメータに関連する推奨事項、および対応するデータベース・パラメータを持たない推奨事項
については、後で詳しく説明します。したがって、詳細は、完全な推奨リストを確認してください。推奨事項の設定に対
応する説明は、表のリンクを参照してください。リンクを使用すると、詳細な設定の推奨事項が記載されている項を参照
できます。以降の設定は、特に指定されていないかぎり、プライマリおよびセカンダリ・サイトの両方に共通のものです。
これらの設定は、ログ・アーカイブの宛先について次の前提も使用します。
•
宛先 1 は、常にローカル・アーカイブの宛先を指している
•
宛先 2 は、使用されている場合は常にフィジカル・スタンバイの宛先を指していて、プライマリ・ロールの場合
にのみ適用される
•
宛先 3 は、常にローカルな代替え宛先を指している
•
宛先 4 は、使用されている場合は常にロジカル・スタンバイの宛先を指していて、プライマリ・ロールの場合に
のみ適用される
Maximum Availability Architecture
5-10
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
「付録 C」には、SPFILE の完全な例、および RAC 用のパラメータ設定が記載されています。また、「付録 C」には、Oracle
Net Services ファイルの例も含まれています。この推奨事項の設定の概要では、次のネットワーク・サービスが定義され
ています。
SALES_PRIM
-
SALES_SEC
-
プライマリ・サイトのデータベースを指す
セカンダリ・サイトのデータベースを指す
（使用されている場合は最初にフィジカル・スタンバイ）
SALES_LOG_SEC
-
セカンダリ・サイトの論理データベースを指す
その他のデータベース・パラメータの詳細は、『Oracle9i Data Guard 概要および管理』および『Oracle9i データベース・
リファレンス』を参照してください。
表5-4: Oracle Data Guardの初期化パラメータの設定
の初期化パラメータの設定
パラメータ名
（SPFILE に指定されているとおり）
推奨されるパラメータ値とオプション
*.LOG_ARCHIVE_DEST_1
プライマリ・サイトまたはセカンダリ・サイト
location=/arch1/SALES arch noreopen max_failure=0
mandatory alternate=LOG_ARCHIVE_DEST_3
ロジカル・スタンバイ・データベース
location=/arch1/SALES_LOG arch noreopen max_failure=0
mandatory alternate=LOG_ARCHIVE_DEST_3
*.LOG_ARCHIVE_DEST _STATE_1
enable
プライマリ・サイト
service=SALES_SEC LGWR sync=noparallel affirm reopen=15 max_failure=10
（最大保護または最大可用性モード）
フィジカル・スタンバイが使用される場 delay=30
合のみ使用
セカンダリ・サイト
service=SALES_PRIM LGWR sync=noparallel affirm reopen=15 max_failure=10
delay=30
*.LOG_ARCHIVE_DEST_2
プライマリ・サイト
*.LOG_ARCHIVE_DEST_2
service= SALES_SEC LGWR ASYNC=20480 reopen=15 max_failure=10
（最大パフォーマンス・モードのみ）
フィジカル・スタンバイが使用される場 delay=30
合のみ使用
net_timeout=30
セカンダリ・サイト
service= SALES_PRIM LGWR ASYNC=20480 reopen=15 max_failure=10
delay=30 net_timeout=30
*.LOG_ARCHIVE_DEST _STATE_2
enable（ロールが本番の場合）
defer（ロールがスタンバイの場合）
*.LOG_ARCHIVE_DEST_3
プライマリ・サイトまたはセカンダリ・サイト
location=/arch2/SALES arch
ロジカル・スタンバイ・データベース
location=/arch2/SALES_LOG arch
*.LOG_ARCHIVE_DEST _STATE_3
alternate
Maximum Availability Architecture
5-11
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
パラメータ名
（SPFILE に指定されているとおり）
推奨されるパラメータ値とオプション
フィジカルおよびロジカルの両方を使用している場合はプライマリ・サイト
service=SALES_LOG_SEC dependency=log_archive_dest_2 reopen=15
（最大可用性モード）
ロジカル・スタンバイが使用される場合 max_failure=10 optional delay=30
ロジカルのみを使用している場合はプライマリ・サイト
のみ使用
service=SALES_LOG_SEC LGWR sync=noparallel affirm reopen=15
max_failure=10 delay=30 optional
ロジカルのみを使用している場合はセカンダリ・サイト
service=SALES_PRIM LGWR sync=noparallel affirm reopen=15 max_failure=10
delay=30 optional
フィジカルとロジカルの両方を使用している場合はセカンダリ・サイト、そ
の場合 dest_4 on physical を設定
service=SALES_LOG_SEC dependency=log_archive_dest_1 reopen=15
max_failure=10 optional delay=30
*.LOG_ARCHIVE_DEST_4
フィジカルおよびロジカルの両方を使用している場合はプライマリ・サイト
service=SALES_LOG_SEC dependency=log_archive_dest_2 reopen=15
（最大パフォーマンス・モードのみ）
ロジカル・スタンバイが使用される場合 max_failure=10 optional delay=30
のみ使用
ロジカルのみを使用している場合はプライマリ・サイト
service=SALES_LOG_SEC LGWR async=20480 reopen=15 max_failure=10
delay=30 net_timeout=30 optional
ロジカルのみを使用している場合はセカンダリ・サイト
service=SALES_PRIM LGWR async=20480 reopen=15 max_failure=10 delay=30
net_timeout=30 optional
フィジカルとロジカルの両方を使用している場合はセカンダリ・サイト、
dest_4 on physical を設定
service=SALES_LOG_SEC dependency=log_archive_dest_1 reopen=15
max_failure=10 optional delay=30
*.LOG_ARCHIVE_DEST_4
*.LOG_ARCHIVE_DEST _STATE_4
enable（ロールが本番の場合）
defer（ロールがスタンバイの場合）
*.LOG_ARCHIVE_START
TRUE
*.LOG_ARCHIVE_FORMAT
arch_%t_%S.log
*.STANDBY_ARCHIVE_DEST
= /arch1/SALES
*.FAL_SERVER
プライマリ・サイト
SALES_SEC
セカンダリ・サイト
SALES_PRIM
*.FAL_CLIENT
プライマリ・サイト
SALES_PRIM
セカンダリ・サイト
SALES_SEC
*.REMOTE_ARCHIVE_ENABLE
TRUE
*.ARCHIVE_LAG_TARGET
0
*.DB_CREATE_ONLINE_LOG_DEST
“”
*.LOCAL_LISTENER
SALES_lsnr
*.SERVICE_NAMES
SALES
ロジカルの場合
SALES_LOG
Maximum Availability Architecture
5-12
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
一般
5.2.1
シンプルで堅牢なアーカイブ方針と構成を使用する
このアーカイブ方針は、次の 2 つの前提をベースとしています。
•
すべてのインスタンスは/arch1 に対してローカルにアーカイブし、別のアーカイブの宛先として/arch2 が定義さ
れている。
•
本番用のインスタンスは、Oracle スタンバイ・インスタンスのみを指している同じネット・サービス名にリモー
トにアーカイブする。ネット・サービス名は、プライマリ・スタンバイ・インスタンスに接続するもので、通常
は管理されたリカバリまたは論理適用を実行している。
次の表は、アーカイブの方針の主なルール、および各ルールの背景にある原理について説明しています。
表5-5: アーカイブのルール
アーカイブのルール
説明と原理
アーカイブを開始し、リモート・ フィジカル・スタンバイの保持するには、アーカイブを有効にし、プライマリ・デ
アーカイブを有効にする
ータベースで開始する必要がある。LOG_ARCHIVE_START=true、またリモート・
アーカイブを有効にする。
REMOTE_ARCHIVE_ENABLE=true
一貫性のあるログ形式
LOG_ARCHIVE_FORMAT はスレッドとシーケンス属性を持ち、すべてのインスタ
LOG_ARCHIVE_FORMAT を使用 ンスで一貫している必要がある。“%S”は、フォーマットのログ・アーカイブ・ファ
する
イル名の順序番号部をゼロで埋めることを意味する。
ローカル・アーカイブ
LGWR の作業を軽減する。ローカル・アーカイブおよび代替えアーカイブの宛先が
LOG_ARCHIVE_DEST_1 はアーカ 一杯の場合は、停止の状態が延長される。領域の問題を検出および解決するために、
イブ・プロセス（ARCH）によっ 時間が延長される。
ステート LOG_ARCHIVE_DEST _STATE_1 は必ず enable にする。
て行う
ローカルな代替えアーカイブの宛 ARCH で書込みエラーが発生した場合、または宛先で領域が一杯だった場合に切り
先 LOG_ARCHIVE_DEST_3 を作 替えるため、ARCH に対するローカルな代替えアーカイブの宛先を作成する。宛先
成する
のステート LOG_ARCHIVE_DEST _STATE_3 は alternate にしておく。
アーカイブ・ディレクトリの構造 推奨しているのは次の 2 つのアーカイブ宛先のみ
は、本番およびスタンバイのすべ
/arch1/<DB_NAME>（プライマリ・アーカイブの宛先）
てのノードで同じにする
/arch2/<DB_NAME>（代替えアーカイブの宛先）
これらの宛先がノード間で同じ場合は、スイッチオーバーまたはフェイルオーバー
の処理後でも予測ができて、管理が簡単になる。
LGWR またはアーカイブは、スタ
ンバイ RAC ごとに 1 つのスタンバ
イ・インスタンスおよびノードに
リモートにアーカイブする
すべての本番インスタンスは、同じネット・サービス名を使用している 1 つのスタ
ンバイ宛先にアーカイブする。セカンダリ・スタンバイ・ホストに切り替える場合
は、バックアップ・ネット・サービス名を使用する。
フィジカル・スタンバイ・データベースまたはロジカル・スタンバイのみ
「最大限の保護」と「最大限のパフォーマンス」の構成の主な違いは、LGWR の書込
みが同期か非同期かである。ほとんどの場合は、LGWR のオプションを使用し、ス
タンバイ REDO ログ（SRL）でスタンバイ・データベースを構成する。WAN 上の
Data Guard 構成で、プライマリ・データベースに対するパフォーマンスの影響が最
少になるようにするには、REDO をスタンバイ・インスタンスへ送信するアーカイ
バを使用する。
フィジカル・スタンバイおよびロジカル・スタンバイ
フィジカル・スタンバイおよびロジカル・スタンバイ
ロジカル・スタンバイの宛先に対してプライマリ上に DEPENDENCY の宛先を定義
する。
Maximum Availability Architecture
5-13
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
アーカイブのルール
説明と原理
スタンバイ・アーカイブの宛先
は、必ず/arch1 ディレクトリを使
用する
わかりやすくするため、スタンバイ・アーカイブの宛先 STANDBY_ARCHIVE_DEST
では必ず/arch1 ディレクトリ（ローカル・アーカイブの宛先 LOG_ARCHIVE_DEST_1
ディレクトリと同じ名前）を使用する。スタンバイ REDO ログ（SRL）が存在する
場合は、スタンバイの ARCH プロセスが、ローカル・アーカイブの宛先に書込みを
行う。ギャップがある場合は、アーカイブ・ログ（FAL）プロセスをフェッチして、
スタンバイ・アーカイブの宛先に書き込む。STANDBY_ARCHIVE_DEST は、フィ
ジカル・スタンバイの LOG_ARCHIVE_DEST_1（ローカル・アーカイブ・ディレク
トリ）と同じにする。
フィジカルおよびロジカルを使用する場合は、ロジカルの設定をフィジカルの
log_archive_dest_1 と同じにする。
ロジカル・スタンバイのみを使用している場合は、ファイル名が競合しないよう、
この設定はロジカル・スタンバイの log_archive_dest_1 の設定と異なるようにする。
最後にディスク上でバックアップ
を行ってからのアーカイブ REDO
ログ・ファイルをすべて保持でき
るよう、アーカイブの宛先のサイ
ズを調整する必要がある
スタンバイ・データベースのインスタンス化では、ディスク上のバックアップおよ
び付随しているローカル・アーカイブ REDO ログ・ファイルを使用して、新しいス
タンバイ・データベースを再作成できる。スイッチオーバーまたはノードの障害が
発生する可能性があるため、すべてのノードは、プライマリ・スタンバイ・ノード
のロールを実行できる。
次の例は、フィジカル・スタンバイのみを持つ構成について、推奨される初期化パラメータを表しています。
ここでは、最大保護モードで稼働している 2 つのインスタンス、SALES1 と SALES2 があります。
*.LOG_ARCHIVE_DEST_1='location=/arch1/SALES arch noreopen max_failure=0
mandatory alternate=LOG_ARCHIVE_DEST_3'
*.LOG_ARCHIVE_DEST_2='service=SALES_SEC lgwr sync=noparallel affirm reopen=15
max_failure=10 delay=30'
*.LOG_ARCHIVE_DEST_3='location=/arch2/SALES arch'
*.LOG_ARCHIVE_DEST_STATE_1='enable'
*.LOG_ARCHIVE_DEST_STATE_2='enable'
# defer for the standby instances
*.LOG_ARCHIVE_DEST_STATE_3='alternate'
*.standby_archive_dest='/arch1/SALES'
この例では、次のことに注意してください。
•
複数のスタンバイ宛先がある場合は、PARALLEL 属性を利用します。SYNC が PARALLEL に設定されていると、
LGWR プロセスは、各スタンバイ宛先に対して同時に I/O 処理を開始します。ここでは 1 つのスタンバイ宛先を
定義しているため、NOPARALLEL オプションはオーバーヘッドを少なくする設定です。
•
REOPEN=15 MAX_FAILURE=10 の設定は、接続が失敗した場合に、ネットワーク・サーバーが 15 秒後に接続の
再開を試行し、最大 10 回の試行を表します。
•
リカバリの適用遅延 DELAY=30 は、リカバリの適用が、フィジカル・スタンバイ上でアーカイブされているロ
グの時刻から 30 分の遅延を意味します。ただし、スタンバイに対する REDO の転送は遅れません。DELAY の
設定の詳細は、「リカバリ遅延を設定する」の推奨事項で説明しています。
•
NET_TIMEOUT=30 の設定は、ネットワークの操作に対して 30 秒以内に応答がない場合は、デフォルトのネット
ワーク・タイムアウト期間（TCP のタイムアウト値）の時間が延長されず、ネットワークのタイムアウトによっ
てネットワーク・サーバー・エラーのアウトを意味しています。
•
ネットワーク操作がサービスされている場合は、失敗したすべての処理に対する最大の再試行回数が、REOPEN
と MAX_FAILURE の積として計算されます。この場合には、再開するまで 15 秒です。15 秒を 10 回再試行する
と、150 秒（2.5 分）になります。
•
LOG_ARCHIVE_DEST _STATE_2（LOG_ARCHIVE_DEST_2 のステート）の設定は、データベース・ロールによ
って異なります。本番ロールの場合は、ステートは有効（ENABLE）になります。データベースがフィジカル・
スタンバイ・ロールの場合は、ステートは遅延（DEFER）になります。
Maximum Availability Architecture
5-14
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
表 5-1 は、前述の設定をベースとしたアーカイブ・インフラストラクチャを表しています。プライマリ環境とセカンダリ
環境には、同じアーカイブ宛先の構造が定義されています。ただし、セカンダリ・サイト、またはスタンバイ・ロールを
持つサイトの最初のノードにのみ、アーカイブ REDO ログ・ファイルがすべて含まれています。LOG_ARCHIVE_DEST_1
が一杯の場合は、ARCH が、LOG_ARCHIVE_DEST_3 で定義されている代替えのアーカイブ宛先に対してアーカイブし
ます。
図5-1: プライマリおよびセカンダリのアーカイブ宛先
アーカイブ宛先は、クラスタ内のすべてのノードに対してアクセスして、共有ファイル・システム・テクノロジ（クラス
タ・ファイルシステム、グローバル・ファイル・システム、可用性の高いネットワーク・ファイル・システム（HA NFS）
など）を利用するか、またはクラスタ内のすべてのノードごとにファイル・システムを手動ですぐにマウントするアプロ
ーチを使用します。これは、メディア・リカバリまたはスタンバイ・リカバリが必要で、本番データベース・ノード上で
すべてのアーカイブ REDO ログ・ファイルをアクセス可能な場合に必要です。ただし、通常はスタンバイにフェイルオ
ーバーする方が高速で効率的なため、最初はプライマリ・サイトのメディア・リカバリは使用しません。
スタンバイ・データベース・ノードでは、node1 がクラッシュして再起動できない場合は、メディア・リカバリまたは別
のノードからのスタンバイ・リカバリが必要になります。このような場合には、別の 1 つのノードに定義されている既存
のすべてのインスタンスによって、管理されたリカバリを開始できます。スタンバイ・アーカイブ REDO ログ・ファイ
ルにアクセスできない最悪の場合には、別のノード上の新しい Managed Recovery Process（MRP）が FAL サーバーを使用
してアーカイブ REDO ログ・ファイルをフェッチし、本番ノードから直接取得します。
ハードウェア・ベンダーの共有ファイル・システム・テクノロジを構成する場合は、パフォーマンスと可用性の関係をよ
く確認してください。この方針の適用前に、次の問題について調べる必要があります。
•
ノードの障害数に関係なく、すべてのノードが共有ファイル・システムにアクセできるか
•
共有ファイル・システムを実装した場合のパフォーマンスへの影響
•
インターコネクト・トラフィックへの影響
Maximum Availability Architecture
5-15
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
5.2.2
FORCE LOGGINGモードを有効化する
モードを有効化する
FORCE LOGGING モードの本番データベースでは、データベースのすべての変更（ただし一時表領域および一時セグメ
ントの変更は除く）が記録されます。FORCE LOGGING モードは、スタンバイ・データベースと本番データベースの整
合性の保持を保証します。NOLOGGING 操作でのロード・パフォーマンスが必要なために、このモードを有効にできな
い場合は、対応するスタンバイ・データ・ファイルの同期を確認する必要があります。
ALTER DATABASE FORCE LOGGING コマンドを発行すると、ロギングをすぐに有効にできます。FORCE LOGGING を
指定すると、Oracle は、処理中の NOLOGGING の終了まで待ちます。
参照: 『Oracle9i データベース管理者ガイド』、『Oracle9i Data Guard 概要および管理』（10.1.4 項）
5.2.3
リカバリ遅延を設定する
ユーザー・エラーまたは破損がスタンバイ・データベースへ伝播されないようにし、障害時リカバリ・ソリューションを
保護するうえで、リカバリ遅延の設定は重要です。リカバリ遅延の設定は、主に次の 2 つの要因に基づいて決定されます。
•
サイト障害に対する MTTR のサービス・レベル
•
ユーザー・エラーおよび破損に対する検出および対応の時間
スタンバイ・データベースが管理されたリカバリ・モードで、SRL を使用している場合は、ログの切換えが行われた際
に、アーカイブされている REDO が自動的に適用されます。ただし、本番データベースからスタンバイ・データベース
に破損している変更または誤った変更が渡されないように、本番用のホストにおける REDO ログのアーカイブおよびス
タンバイ・データベースで、そのアーカイブ・ログ・ファイルを適用する際にタイムラグを設定する場合があります。こ
の遅延メカニズムは、本番用のデータベースが REDO ログをアーカイブしてからではなく、実際は、スタンバイ・デー
タベースがログをローカルにアーカイブしてから開始されます。オラクル社では、この遅延を 30 分以内に設定するよう
推奨しています。ただし、問題の検出、およびデータベースで管理されたリカバリ・プロセスを停止する監視インフラス
トラクチャがある場合は、この遅延を有効にすることが可能です。リカバリ遅延の設定は、保護モードに関係なく、スタ
ンバイの構成にとって重要です。
LOG_ARCHIVE_DEST_N パラメータを修正して、遅延を設定できます。MAA では、LOG_ARCHIVE_DEST_2 パラメー
タは、リモート・スタンバイの宛先を表します。30 分のタイムラグを設定するには、*.LOG_ARCHIVE_DEST_2 を次の
ように設定します。
*.LOG_ARCHIVE_DEST_2='service=SALES_SEC lgwr sync=noparallel affirm reopen=15
max_failure=10 delay=30'
実際の遅延オプションの設定は、次の要因に基づいて決定します。
•
本番データベース上でユーザー・エラーまたは破損を検出するために、最大どの程度の時間がかかるか
•
検出がアーカイブされた後、どのようにスタンバイ・データベース上のリカバリを迅速に取り消すことが
できるか
•
ユーザー・エラーによる停止に対してどの程度の MTTR が適切か
MTTR は次のようにして推定されます。
適切な MTTR ⇐ 検出時間の合計 + 修復時間
検出時間の合計 = エラーの検出時間 + リカバリの取消し時間
修復時間 = スタンバイのリカバリ時間 + 活性化に要する時間
Maximum Availability Architecture
5-16
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
「検出時間の合計」と「修復時間」を加算した時間よりも、適切な MTTR 時間の値が大きい場合は、検出時間を最適化す
るか、または修復時間を短くする必要があります。遅延を少なくすると、スタンバイ・リカバリに必要なアーカイブ・ロ
グ・ファイルの数が減少するため、修復時間が短縮されます。オンラインおよびスタンバイの REDO ログのサイズを小
さくした場合も、修復時間が短縮されます（「REDO ログのサイズを適切に調整する」参照）。最も一般的な検出のメカ
ニズムは、アラート・ログで ORA-600 や ORA-1578 などの重要なエラーを監視し、アプリケーションで、表が存在しな
いなどの論理的な破損が検出された場合に警告および対処するものです。
テスト環境では、本番データベースとスタンバイ・データベース間で 30 分の遅延を設定しました。
5.2.4
複数のスタンバイ・インスタンスを構成する
クラスタ上の同じデータベースに対して複数のスタンバイ・インスタンスを実行すると、次の効果があります。
•
プライマリ・スタンバイ・インスタンスに対する接続が失敗した場合に、セカンダリ・スタンバイ・インスタン
スに透過的にフェイルオーバーできます。これは、最大可用性モード、または最大パフォーマンス・データベー
ス・モードでのみ可能です。このシナリオでは、MRP セッションがプライマリ・スタンバイ・インスタンス上
で稼働していた場合に、MRP セッションを再起動する必要があります。「リスナーおよび Oracle Net の構成」を
参照してください。
•
メンテナンスのためにプライマリ・スタンバイ・インスタンスとホストを停止する必要がある場合、必ず計画さ
れたメンテナンス・ソリューションを提供します。セカンダリ・スタンバイは、プライマリの処理を引き継ぎ、
セカンダリ・スタンバイ・インスタンスを指している新しい Oracle Net サービスを利用できます。本番データベ
ースで次のコマンドを発行し、サービスを変更できます。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2= “service=SALES_SEC_ALT lgwr
sync=noparallel affirm reopen=15 max_failure=10 delay=30 ”;
SALES_SEC_ALT は、セカンダリ・スタンバイ・インスタンスを指す代替えの Oracle Net エイリアスです。この
ALTER SYSTEM 文は、本番データベースが停止しないよう最大保護モードを使用する場合のみ必要になります。
注意: 複数のスタンバイ・インスタンスを持つことは、複数のスタンバイ・データベースを持つこととは異なります。複
数のスタンバイ・インスタンスは同じデータベースを共有しています。管理リカバリ・プロセス（MRP）を持つのは、1
つのインスタンスのみです。
5.2.5
LGWRに対する時間ベースのスレッド拡張機能（
に対する時間ベースのスレッド拡張機能（ARCHIVE_LAG_TARGET=0）
）
に対する時間ベースのスレッド拡張機能（
を無効化する
タイムベースのスレッドの高度な機能を無効にすることで、アーカイブのログの切換えを最小限にします。これは、デー
タベース・パラメータ ARCHIVE_LAG_TARGET=0 を設定します。このパラメータはデフォルトではゼロですが、明示的
に設定すると、リカバリ遅延設定で競合を回避できます。このパラメータは、プライマリ・サイトの障害時のデータ損失
を抑える目的で、Oracle8i で導入されました。ただし、Oracle9i でデータ損失を抑えるには、LGWR を使用した REDO の
転送が最適な方法です。ログ・ライターのかわりに、アーカイバが REDO をスタンバイへ送信する最大パフォーマンス・
モードでは、損失する可能性のあるデータ量を減らすために、このパラメータを設定します。このパラメータは、指定し
た時間（秒数）が経過した後でログを強制的に切り替えることによって、スタンバイ・データベースの可用性を効果的に
向上させます。
5.2.6
DB_CREATE_ONLINE_LOG_DESTを設定しない
を設定しない
DB_CREATE_ONLINE_LOG_DEST パラメータは設定しません。SRL 名は再利用できないため、このパラメータを設定す
ると、スタンバイ・データベースのインスタンス化で問題が発生します。このパラメータを設定すると、Oracle は、オン
ライン・ログに対して名前を動的に作成します。これは、スタンバイ・データベース上で手動での作成はできません。
Maximum Availability Architecture
5-17
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
5.2.7
リモート・ミラーリング・テクノロジのかわりにData
Guardを使用する
を使用する
リモート・ミラーリング・テクノロジのかわりに
Data Guard のリモート・ログ転送を使用すると、カスタマイズやスクリプトの作成を行わず、またはリモート・ミラーリ
ングのテクノロジを使用せず、より統合されたスイッチオーバーおよびフェイルオーバー・ソリューションを使用するこ
とで、「非データ消失」のソリューションが実現します。
本番データベースでは、データベース保護モードおよびリモート・ログ転送機能を使用して、記録されているすべての変
更がローカルおよびリモートの両方でスタンバイ・データベースに必ず伝播されます。
ただし、次の場合にはリモート・ミラー・テクノロジが有効です。
•
プライマリ・サイトとセカンダリ・サイトの間で、非データベース・ファイル（Oracle バイナリや他のソフトウ
ェアなど）の同期をとる。このソリューションを使用すると、不注意なソフトウェアの削除などのユーザーによ
るエラーやソフトウェアのアップグレードなどに対し特別な注意が必要になる場合がある。
•
プライマリ・サイトとセカンダリ・サイト間で、重要なフラット・ファイルまたはバイナリ・ファイル（SPFILE
や init.ora ファイルなど）の同期をとる。
次の効果を理由に、サードパーティのテクノロジからリモート・ミラーリング・ソリューションよりも、Data Guard およ
びフィジカル・スタンバイ・データベースを選択します。
•
ユーザー・エラーやデータの破損から保護する
•
REDO トラフィックのみが転送されるため、ネットワークの使用率が低下する
•
ロール管理機能によって、シンプルで統合されたスイッチオーバーおよびフェイルオーバーの手順が提供される
•
Oracle ベースのソリューションを使用することによって、サポートおよび証明が簡素化される
5.2.8
適切なデータベース保護モードを選定する
ユーザーは、3 つの保護モード（およびそれぞれ異なるロギング・オプション）を設定できます。環境に対してそれぞれ
のデータベース保護モードを使用すると、可用性、コスト、データ損失、パフォーマンス、およびスケーラビリティにそ
れぞれ異なる影響を与えます。
品質保証契約に応じて、次のいずれかを選択してください。
•
データの損失をゼロにすることが必要な環境では、最大保護モード（および LGWR SYNC AFFIRM オプション）
を使用します。パフォーマンスのオーバーヘッドが発生する可能性があります。この保護モードは、フィジカル・
スタンバイ・データベースでのみ使用できます。
•
データの損失をゼロにする必要がある一方、サイトが一時的に使用不可になった場合にはデータ分岐が可能な環
境では、最大可用性モード（および LGWR SYNC AFFIRM オプション）を使用します。パフォーマンスのオー
バーヘッドが発生する可能性があります。この保護モードは、フィジカルまたはロジカル・スタンバイで使用で
きます。
•
データの損失を最小限にして、サイトが一時的に使用不可になった場合にはデータ分岐が可能な環境では、最大
パフォーマンス・モード（および LGWR ASYNC オプション）を使用します。パフォーマンスのオーバーヘッド
は最少になります。LGWR ASYNC のかわりに ARCH を使用すると、本番データベースでパフォーマンスのオー
バーヘッドが最少になります。ただし、ARCH ではデータが損失する可能性が高くなります。この保護モードは、
フィジカルまたはロジカル・スタンバイで使用できます。
Maximum Availability Architecture
5-18
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
この項では、次の内容について説明します。
•
データベースの保護モード
•
適切な保護モードを選定するための要因
•
データベースの保護モードを設定する
詳細な注意事項およびこのトピックの詳細は、『Oracle9i Data Guard: プライマリ・サイトおよびネットワーク構成に関
するベスト・プラクティス』（http://otn.oracle.co.jp/products/oracle9i/index.html#ha）を参照してください。
データベースの保護モード
次の表は、各モードおよびモードの利点と考慮点について説明しています。
表5-6: 保護モード
保護モード
利点
考慮点
最大保護
記録されているすべてのトランザクション スタンバイ・データベースにアクセスできな
（ログ・ライター同期 I/O） が、スタンバイ・データベースで随時に使用 い場合は、本番データベースは強制終了しま
できることが保証されます。
す。
それぞれのログ・ライターの I/O は、トラン
ザクションのコミットが正常終了したとみ
なされる前に、オンライン・ログに対してロ
ーカルおよびリモートの両方で完了する必
要があります。
ネットワークが適切に構成されていない場
合は、パフォーマンスに影響を与えます。
この保護モードはロジカル・スタンバイでは
使用できません。
最大可用性
接続が確立されている間は、記録されている データベース間でデータの分岐が発生する
（ログ・ライター同期 I/O） すべてのトランザクションがスタンバイ・デ 可能性があり、その場合はネットワークまた
ータベースで使用できることが保証されま はスタンバイ・データベースはのアクセスが
す。
不可能になります。
スタンバイ・データベースにアクセスできな
い場合でも本番データベースは強制終了し
ません。ただし、RAC 製品を起動する際に
は、スタンバイ・データベースにアクセスで
きる必要があります。
各ログ・ライターの I/O は、オンライン REDO
ログに対してローカルとリモートの両方で
完全にする必要があるため、パフォーマンス
が低下する可能性があります。
ネットワークが適切に構成されていない場
合は、パフォーマンスに影響を与えます。
接続を再確立した後、Oracle が自動的なギャ
ップ解決を完全にするまで、スタンバイは最
初にデータを分岐します。
RAC 製品では、起動時にスタンバイにアクセ
ス可能であることが必要になります。
最大パフォーマンス
（ログ・ライター非同期
I/O またはアーカイバの
使用）
ネットワークの書込みを非同期にすること プライマリ・サイトで障害が発生した場合に
によって、パフォーマンスの低下を最小限に は、データが損失する可能性があります。
抑えます。
ネットワークが適切に構成されていない場
ASYNC のバッファ・サイズを制御すること 合は、パフォーマンスに影響を与えます。
によって、プライマリ・サイトで障害が発生
した場合に、記録されているトランザクショ
ンの損失が制限されます。
スタンバイ・データベースにアクセスできな
い場合でも、本番データベースは強制終了し
ません。
Maximum Availability Architecture
5-19
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
保護モードを選定するための要因
アプリケーションの適切なデータベース保護モードを選定するには、最初に次の質問に答えて実装の可能性を判断できま
す。ロジカル・スタンバイ・データベースを使用している場合は、最大可用性またはまたは最大パフォーマンス保護モー
ドのみ使用可能です。最大保護モードが推奨される場合は、フィジカル・スタンバイ・データベースの使用が必要です。
表5-7: 保護モードの選定
質問
推奨事項
プライマリ・サイトで障害が発生 Yes − すべての保護モードを使用できます。
した場合にデータが損失しても許 No − 最大保護モードまたは最大可用性モードを使用してください。
容できますか?
サイトが消失した場合に、どの程 None（許容できない） − 最大保護または最大可用性モードを使用してください。
度のデータ損失を許容できます
Some（少し） − ASYNC=<blocks>として最大パフォーマンス・モードを使用してく
か?
ださい。ブロック数の値によって、サイトの障害時に失われる可能性のある REDO
データ量が事前に決定されます。現在の最大値は 10MB です。パフォーマンスを最
適にするには、ASYNC=20480 に設定することをお薦めします。製品のスループッ
トが高く、ネットワークのラウンド・トリップが低い場合は、パフォーマンスの影
響が最少になるよう、Oracle でアーカイバを元の状態に戻すことができます。
スタンバイ・ホストまたはネット
ワーク接続が一時的に使用不可に
なった場合は、本番データベース
とスタンバイ・データベース間に
おいてデータ損失の可能性を許容
できますか?
Yes − 最大パフォーマンスまたは最大可用性モードを使用してください。
例外: 最大可用性モードを使用すると、RAC 製品では起動時にスタンバイ・データ
ベースへアクセスできる必要があります。
No − 最大保護モードのみ使用できます。
二重サイトの障害を排除するため サイト間の距離、およびサイト間のネットワーク・インフラストラクチャによって、
の最低必要距離はどの程度です
ネットワークの待機時間が決まります。通常は、距離が長くなるほど待機時間が長
か?
くなります。
障害停止を分離させて、ネットワークの待機時間によるプライマリ・サイトへのパ
フォーマンスの影響を最小限にするための、サイト間の最少必要距離を決定しま
す。『Oracle9i Data Guard: プライマリ・サイトおよびネットワーク構成に関するベ
スト・プラクティス』（http://otn.oracle.co.jp/products/oracle9i/index.html#ha）を参照
してください。
現在の、または提案されたサイト Data Guard 構成のパフォーマンスを最適にするためには、ネットワークのスループ
間のネットワーク帯域幅および待 ットを REDO 生成の最大レートよりも大きくします。設定が不適切な場合は、設定
機時間はどの程度ですか?
ネットワークの帯域幅が不足してパフォーマンスが低下します。
プライマリ・サイトとセカンダリ・サイト間のネットワーク・ラウンドトリップ時
間（RTT）の値を大きくすると、最大保護および最大可用性の保護モードへの影響
が大きくなります。最大パフォーマンス・モードで ASYNC ログ転送を設定してい
るか、またはアーカイバを使用している場合には、スループットが高い環境におい
ても、パフォーマンスへの影響が緩和されるか、または影響がなくなります。
距離と帯域幅だけでなく、ネットワークのスループットは他の様々な要因（プロセ
ッサの制約、ネットワークの輻輳、バッファリングの不足、転送エラー、トラフィ
ック・ロード、ネットワーク・ホップの数、輻輳、ハードウェアの不十分な設計な
ど）によっても影響を受けます。帯域幅を決定する場合には、プライマリとセカン
ダリのホスト間の最低限のすべてのルーター・ホップについて、最大の帯域幅を使
用します。
REDO レートおよびネットワークのオーバーヘッドが 30%の場合に、必要な帯域幅
を推定する計算式は、次のようになります。
必要な帯域幅 = ((REDO レート・バイト /秒 / .7) * 8) / 1,000,000 = 帯域幅（Mbps）
データの損失をゼロにするために Yes − 最大保護または最大可用性モードを使用してください。
は、パフォーマンスの低下を許容 どの程度のパフォーマンスの低下を許容できるかを決定する、および環境がこの要
できますか?
件に適合できるかどうかを検証するためにテストを実施してください。
No - 1）パフォーマンスへの影響があるか、2）異なる保護モードを使用した場合
に待機時間が少なくするなど、影響を緩和する方法があるかを調べるためにはパフ
ォーマンス・テストが必要です。
Maximum Availability Architecture
5-20
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
データベースの保護モードを設定する
データベースの保護モードは、次の手順で設定または変更します。
1.
対象の初期化パラメータを変更します。最大保護モードおよび最大可用性モードの場合は、LGWR SYNC オプシ
ョンを使用している有効なリモートまたはスタンバイのアーカイブ宛先、および起動時における適切なネット・
サービス名の設定が必要になります。最大パフォーマンス・モードでは、LGWR ASYNC または ARCH オプショ
ンおよび有効なネット・サービス名を使用します。
2.
初期化パラメータを構成した後、SPFILE で CLUSTER_DATABASE=FALSE のように設定して、インスタンスを
排他モードで再起動する準備を行います。
ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE;
3.
すべてのインスタンスを停止し、排他モードで 1 つのインスタンスを開始します。
SHUTDOWN IMMEDIATE;
STARTUP MOUNT EXCLUSIVE;
4.
次のコマンドを実行し、データベースの保護モードを明示的に変更します。
ALTER DATABASE SET STANDBY TO MAXIMIZE [PERFORMANCE | AVAILABILITY | ROTECTION];
注意: このコマンドは、本番データベースが排他モードにマウントされている場合のみ実行できます。これは、
すべてのデータベース保護モードの変更では、本番データベースが停止し、それを再起動させる必要があ
ることを意味しています。
5.
保護モードを排他モードで設定した後、SPFILE パラメータを RAC モード用にリセットします。
CLUSTER_DATABASE=TRUE（インスタンスを再起動する前）
ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=SPFILE;
6.
すべてのインスタンスを再起動します。
本番データベースが停止しないよう、最初に適切な保護モードを選択します。
スタンバイ・データベースにフェイルオーバー後は、保護モードは自動的に最大パフォーマンス・モードへダウングレー
ドします。スイッチオーバー処理が行われても、保護モードの設定は変わりません。
5.2.9
提案されたネットワーク構成でパフォーマンス評価を実施する
提案されたネットワーク構成および現在の（または予想される）ピーク REDO レートで、パフォーマンス評価の実施を
お薦めします。本番データベースおよびスタンバイ・データベース間のネットワークへの影響、およびプライマリ・デー
タベースのスループットに対する影響を十分に理解しておく必要があります。本番およびスタンバイのデータベース間の
ネットワークはライフラインとなっており、これによって 2 つのデータベースが同期をとるため、インフラストラクチャ
では次の要件が必要です。
•
REDO の最大生成レートに対応できるだけの十分な帯域幅を定義する
•
本番データベースにおけるパフォーマンスの影響を減らすために、待機時間を最少にする
•
ネットワークの冗長性を実現するために複数のネットワーク・パスを定義する
•
最も効率のよいネットワークの応答時間を実現するための構成およびチューニングを行う
3
専用ネットワーク接続に必要な帯域幅は、本番データベースの最大 REDO レート によって決まります。また、実際の
ネットワーク効率についても明確にする必要があります。データベースの保護モードの選択によっては、他のベスト・プ
ラクティスや、パフォーマンス上の留意点の考慮が適切な場合もあります。「データベースの保護モード」の項で説明し
3
データベースの最大REDOレートは、Oracleのstatspackレポートによって入手できます。ピーク時のREDO生成間隔における、
スナップショットを取得します。REDOレート = 生成されたREDO（またはREDOサイズ）/ 時間
Maximum Availability Architecture
5-21
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
たように、最大保護および最大可用性の保護モードでは、LGWR SYNC 転送が必要で、最大パフォーマンス保護モード
では、（ログ・ライターではなく）ASYNC 転送オプションまたはアーカイバを使用して REDO を転送します。
その他のベスト・プラクティス、および保護モードの選択に関するパフォーマンス上の留意点を次に示します。これらの
ベスト・プラクティスは、Oracle のインターネット・パフォーマンスの検証で Data Guard の各転送オプション（ARCH、
LGWR ASYNC、LGWR SYNC）に対するプライマリ・データベースのスループットでネットワーク待機時間の影響を測
定し、そこから得たものです。この研究の詳細は、Oracle Technology Network のドキュメント(英語)
（http://otn.oracle.com/deploy/availability/htdocs/maa.htm）を参照してください。
本番データベースの REDO データはフィジカル・スタンバイ・データベースを更新するため、プライマリ・サイトとセ
カンダリ・サイト間のネットワーク・インフラストラクチャは、REDO トラフィックに対応する必要があります。ピーク
時のロードにおける最大 REDO トラフィックが 8 MB/秒の場合は、ネットワーク・インフラストラクチャはこのロードを
処理する十分な帯域幅を持つと判断できます。また、ネットワーク待機時間は、全体のスループットおよび OLTP とバッ
チ処理の応答時間にも影響を与えます。
LGWR SYNC を指定して最大保護または最大可用性モードを設定するか、または LGWR ASYNC を指定して最大パフォ
ーマンス保護モードを使用するかを判断には、待機時間によってパフォーマンスまたはスループットが低下するかのを測
定が必要です。また、新しいスループットおよび応答時間がアプリケーションのパフォーマンス要件の範囲内であるかも
確認します。距離およびネットワークの構成は、待機時間に直接影響を与えます。待機時間が長くなるとトランザクショ
ンのスループットが低下し、応答時間が長くなる可能性があります。ネットワークの構成、繰返しの数、プロトコル変換
のオーバーヘッド、およびルーターの数によっても、全体のネットワーク待機時間およびトランザクションの応答時間に
影響を与えます。また、TCP の受信/送信用バッファ・サイズ、および Oracle の Session Data Used（SDU）設定は、全体
のパケット応答時間に多大な影響を与えます。
次の表と図は、Oracle Technology Network のの『Oracle9i Data Guard: プライマリ・サイトおよびネットワーク構成のベス
ト・プラクティス』から抜粋したものです。これらの結果は、パフォーマンス評価の一部を表しています。このテストは、
様々な転送オプション、およびプライマリ・データベースのスループットにおけるネットワークの RTT の影響を評価す
るために、ネットワークのラウンド・トリップ時間（RTT）をエミュレートし、LAN 上で実施されました。プライマリ・
データベースのスループットの数量化に、REDO レート（KB/秒）がメトリックとして使用されました。REDO レートは、
各プライマリ・インスタンスにおける STATSPACK（1 秒あたりの REDO サイズ統計）のスナップショットから取得され
ました。他の転送オプションと影響を比較する基準として、ARCH 転送オプションが使用されました。これらの統計の他
に、オペレーティング・システムのリソース（CPU、メモリー、I/O）およびネットワーク・ボリュームも監視しました。
これらのテストでは、OS リソースに関するボトルネックは検出されませんでした。
表5-8: プライマリにおけるユーザー200人のテスト結果
人のテスト結果
プライマリにおけるユーザー
RTT
転送
0.2 ms
2 ms
10 ms
50 ms
100 ms
ARCH
REDO
レート
746
744
742
751
741
ASYNC
REDO
レート
752
744
745
745
732
拡張
101
100
100
99
99
SYNC
REDO
レート
739
732
722
拡張
99
98
97
Maximum Availability Architecture
5-22
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
図5-2: 200人のユーザー・テスト
人のユーザー・テスト
5.2.10
動的サービス登録のためのデータベースとリスナーを構成する
LOG_ARCHIVE_DEST_2 SERVICE、FAL_SERVER および FAL_CLIENT の初期化パラメータの設定は、固有の Oracle Net
構成によって異なります。Data Guard の転送サービスおよびギャップ解決の適切な機能には、SPFILE、listener.ora、
tnsnames.ora、および sqlnet.ora ファイルで整合性を保持する必要があります。これらのファイルの完全な例は、「付録 C」
に記載されています。これらの設定は、プライマリおよびセカンダリ・サイト間の Oracle Net サービスでのみ使用できま
す。
リモートのアーカイブ宛先、FAL_CLIENT、および FAL_SERVER パラメータでは、Oracle Net サービスが必要です。
FAL_CLIENT および FAL_SERVER は、フィジカル・スタンバイでのみ使用されます。このサービスは、ローカルな
tnsnames.ora ファイル内で、ネット・サービス名のエントリとして示されます。また、オラクル社は、リスナー構成で静
的な 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_SEC lgwr sync=noparallel affirm reopen=15
max_failure=10 delay=30'
*.local_listener='SALES_lsnr'
*.service_names='SALES'
# required for service registration
*.FAL_SERVER='SALES_PRIM'
*.FAL_CLIENT='SALES_SEC'
Maximum Availability Architecture
5-23
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
listener.ora ファイルは、それぞれのプライマリ・ホストとセカンダリ・ホストに対して、（HOST 設定以外は）同様に定
義します。サービスの登録が使用されているため、静的に設定された情報は必要ありません。
ローカルな tnsnames.ora ファイルには、ネット・サービス名およびローカル・リスナーの名前変換を定義します。各ノー
ドで同じサービス名の使用には、本番およびスタンバイ・データベースに対して、ローカルに管理されている tnsnames.ora
ファイルの使用が必要です。プライマリ・クラスタでは、tnsnames.ora のエントリ SERVICE_NAME が、SPFILE の
SERVICE_NAMES パラメータの設定と同じになるようにします。インスタンスの後でリスナーが開始されても、すぐに
サービスは登録されません。この場合には、データベースで ALTER SYSTEM REGISTER 文を発行し、リスナーを使用し
てインスタンスをすぐに登録する PMON バックグラウンド・プロセスに指示します。
5.2.11
Data Guardネットワーク・サービス・ディスクリプタに対する接続時間
ネットワーク・サービス・ディスクリプタに対する接続時間
フェイルオーバーを構成する
フェイルオーバーを構成する
あるリスナーが応答しない場合、別のリスナーに対して接続要求が転送されると、接続時フェイルオーバーが発生します。
接続時フェイルオーバーは、サービス登録によって有効になります。これは、接続の際に、特定のインスタンスが実行中
であるかをリスナーが認識しているためです。サンプルの tnsnames.ora ファイルでは、SALES というネット・サービス名
に、本番およびスタンバイのクラスタに対する複数の（このサービス名は 2 ノード・クラスタを参照しているため、2 つ
の）アドレス・リストが含まれていることがわかります。2 番目のアドレス・リストによって、最初の接続が失敗した場
合に、接続時フェイルオーバーが有効になります。これは、最大パフォーマンスおよび最大可用性モードで作用しますが、
最大保護モードでは作用しません。
5.2.12
代替スタンバイ接続を設定する
ノード 1 のスタンバイ・ホストをメンテナンスのために停止が必要な場合は、代替えのサービス名を指すよう本番データ
ベースの LOG_ARCHIVE_DEST_2 の設定を変更できます。サンプルの tnsnames.ora ファイルでは、これは
SALES_SEC_ALT ネット・サービス名になります。これにより、いずれの保護モードにおいても、本番データベースがオ
ープンした状態です。このアプローチについては、スタンバイのメンテナンスの説明で詳しく説明します。
5.2.13
WAN環境でネットワークのチューニングを評価する
環境でネットワークのチューニングを評価する
TCP ソケットの送信および受信バッファ・サイズを、帯域遅延積と同じになるように設定します。
tcp_xmit_hiwat = tcp_recv_hiwat = bandwidth*RTT（Solaris の例）
4
REDO ログ・データをスタンバイ・サイトに転送するパフォーマンスの最適化には、ネットワークにおけるラウンド・ト
リップ数の軽減が重要なポイントです。Oracle Net Services では、セッション・データ・ユニット（SDU）に対して Oracle
Net 設定のサイズを調整することによって、データ転送を制御できます。WAN 環境では、SDU を 32KB に設定すると、
パフォーマンスが改善されます。SDU パラメータは、各バッファを TCP/IP 層へ渡してネットワークに転送前に、データ
の格納で使用される Oracle Net のバッファ・サイズを表します。Oracle Net は、要求された場合、またはバッファが一杯
になった場合に、バッファのデータを送信します。WAN におけるオラクル社内部の Data Guard テストでは、WAN 環境
において、最大 32KB（32768）の設定でパフォーマンスが最適になることが実証されました。SDU を設定した場合には、
データをパケットするコール数が減ることによってメリットが得られます。
SDU パラメータは、リスナーおよび接続のレベル（tnsnames.ora および listener.ora）で設定が必要です。SDU 設定を使用
している場合は、Oracle9i
Database Release 2 ( 9.2.0.4)以前は動的インスタンス登録を使用できません。
以前は動的インスタンス登録を使用できません。Oracle9i
Database
している場合は、
以前は動的インスタンス登録を使用できません。
4
これらのパラメータ名はプラットフォームによって異なる場合があります。可能な場合は、これらのパラメータをプライマリおよ
びスタンバイ・マシンの両方に設定し、ソケット接続を再起動する必要があります。ただし、メモリー、ネットワークおよびパフ
ォーマンスの影響を再評価する必要があります。
Maximum Availability Architecture
5-24
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
Release 2 ( 9.2.0.4)以前は、SDU を使用して動的インスタンス登録を使用すると、すべての SDU 設定がデフォルトの 2048
（2KB）に上書きされます。
同様に、デフォルトのポート 1521 を使用すると、自動的に動的な登録が試みられます。SDU の適切な構成については、
「付録 C」の最後の例の下に示されています。
SDU パラメータを設定する他に、TCP の送信および受信ウィンドウ・サイズを増やしてもパフォーマンスが改善されま
す。ただし、これにより、アーカイブと同じ特性を公開しない、ネットワーク化されたアプリケーションに悪影響をおよ
ぼす可能性があります。この方法は、接続のたびに追加でメモリーを消費します。TCP のウィンドウ・サイズは 32KB を
超える大きさには設定しないでください。TCP ウィンドウ・サイズの詳しい設定については、ネットワーク管理者に問
合せるか、またはオペレーティング・システムのドキュメントを参照してください。
5.2.14
データ消失ゼロの保護モードの場合、
またはMANネットワーク環境を
ネットワーク環境を
データ消失ゼロの保護モードの場合、LANまたは
ードの場合、
または
使用する
前述のように、最大保護および最大可用性保護モードでは、Data Guard の転送サービスで LGWR SYNC 転送オプション
が必要です。ネットワーク待機時間は、それぞれの LGWR SYNC I/O 処理に対して追加のオーバーヘッドになります。図
5-3 の LGWR SYNC は、LGWR SYNC がオンライン REDO ログに対してローカルに書き込む仕組みと、RFS プロセスへ
のネットワークを介してスタンバイ REDO ログに対してリモートに書き込む仕組みを表しています。次の簡単な計算式
では、リモート書込みが常にローカル書込みよりも低速で、LGWR の同期書込みが発生した場合には制限要因になるこ
とが強調されます。
ローカル書込み =
リモート書込み =
ローカル書込みの I/O 時間
ネットワークのラウンド・トリップ時間（RTT） +
（スタンバイ・マシンにおける）ローカル書込みの I/O 時間
ネットワークのラウンド・トリップ時間（RTT）が 20ms である例を使用すると、LGWR のすべての同期書込みおよびす
べてのトランザクションの時間は 20ms 増えます。このオーバーヘッドは応答時間に影響し、プライマリ・データベース
のスループットに影響を及ぼす場合もあります。したがって、RTT による追加のオーバーヘッドを考慮して、Local Area
Network（LAN）またはメトロポリタン・エリア・ネットワーク（MAN）では、RTT が 10ms 以下にします。LAN と WAN
のどちらを使用するかの判断は、パフォーマンス評価の結果によって決まります。『Oracle9i Data Guard: プライマリ・
サイトおよびネットワーク構成に関するベスト・プラクティス』（http://otn.oracle.co.jp/products/oracle9i/index.html#ha）を
参照してください。
Maximum Availability Architecture
5-25
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
図5-3: LGWR SYNC
5.2.15
データ消失ゼロの保護モードの場合、SYNC=NOPARALLELを設定する
を設定する
データ消失ゼロの保護モードの場合、
LAN でリモートのスタンバイ宛先が 1 つで、十分な帯域幅を備えており、待機時間が短い場合は、最大データ保護機能
で最適なパフォーマンスの実現に、LGWR SYNC=NOPARALLEL AFFIRM の設定をお薦めします。データ消失をゼロに
する必要があり、リモートのアーカイブ宛先が 1 つしかない場合、1 つのスタンバイ宛先で同期パラレル（デフォルト）
よりも、SYNC=NOPARALLEL に設定した方がパフォーマンスが向上します。
SYNC=PARALLEL に設定すると、ネットワーク I/O が動機的に開始され、複数の宛先に対する I/O をパラレルに開始で
きます。ただし、一度 I/O が開始されると、ログ・ライター・プロセスは各 I/O 処理が完了するのを待ってから処理を続
行します。実際には、複数の同期的な I/O 処理が同時に行われることと同じです。
SYNC=PARALLEL は、複数のスタンバイ宛先がある場合のみ使用します。
スタンバイの保護モードが最大パフォーマンス・モードに設定され、LGWR ASYNC 構成を使用している場合は、ネット
ワーク・バッファ内で十分な領域が使用できれば、LGWR 要求がバッファされます。このようなケースでは、ネットワ
ークの帯域幅が十分ではない場合、またはネットワーク I/O の処理よりもネットワーク・バッファが早く一杯になった場
合のみ、パフォーマンスが低下します。本番データベースがクラッシュして使用できない場合は、ネットワーク・バッフ
ァ内のデータが失われます。
5.2.16
スループットのパフォーマンスを最大にするアーカイブ転送を使用する
アーカイブ転送では、最大のパフォーマンス・スループットが得られますが、データを損失する可能性も最大になります。
「本番およびスタンバイの REDO ログとグループのサイズを適切に調整する」に記載されているとおりに REDO ログが正
しく設定されている場合は、待機時間が増えた場合でも ARCH 転送はプライマリ・パフォーマンスには影響を与えませ
ん。プライマリ・スループットの待機時間の影響は、このホワイト・ペーパーでも説明しています。
Maximum Availability Architecture
5-26
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
5.2.17
WAN上の最大パフォーマンス・モードで、圧縮付き
上の最大パフォーマンス・モードで、圧縮付きSSHポート転送の
ポート転送の
上の最大パフォーマンス・モードで、圧縮付き
実装を評価する
「タイミング・アウト－ASYNC バッファがフル」のエラーの発生率を低くするには、最大非同期バッファ・サイズの他
に、圧縮付きで SSH を使用する方法があります。これにより、ネットワークのトラフィックも軽減します。圧縮付きの
SSH ポート転送では、暗号化も行われます。SSH は、ラウンド・トリップ時間が 50ms 以上の WAN 上で、最大のパフォ
ーマンスのメリットを得られます。
5.2.18
OSネットワーク
ネットワークTCPの送信および受信のバッファ・サイズを、帯域遅延積に
の送信および受信のバッファ・サイズを、帯域遅延積に
ネットワーク
設定する
TCP はスライディング・ウィンドウのアルゴリズムを使用して、データが送信および受信されたときにデータを処理し
ます。このアルゴリズムの詳細は、Request for Comments（RFC）793 および 1323 に記載されています。このスライディ
ング・ウィンドウの方法では、帯域遅延積（BDP: 推測される最少帯域幅と、2 つのマシン間のラウンド・トリップ時間
の積）の値が大きい場合に、効率が悪いことを表します。この効率の悪さは、デフォルトの TCP バッファ・サイズの設
定の変更によって改善します。デフォルトのバッファ・サイズは、送信側および受信側の両方で変更が必要です。TCP
のバッファ・サイズは、最大のスループットが得られる BDP の値に設定します。TCP の送信および受信バッファ・サイ
ズを増やすことは、ホスト・レベルまたはシステム全体（すべての接続）で行うことができます。また、バッファ用にメ
モリーを使用して、このことの考慮も可能です。次に、Solaris 2.8 のシステム全体の設定の例を示します。
1.
環境: プライマリとセカンダリが T3（44.736 Mbps）によって RTT が 50ms のネットワークにリンクしている
2.
BDP=44.376 * 50=2236.8 Mb=279,600 バイト
3.
ndd コマンドを使用し、両方のホストで TCP の設定を確認します。
echo tcp_xmit_hiwat = `/usr/sbin/ndd /dev/tcp tcp_xmit_hiwat `
echo tcp_recv_hiwat = `/usr/sbin/ndd /dev/tcp tcp_recv_hiwat `
4.
両方のホストで次の設定が定義されています。
tcp_xmit_hiwat = 16384
tcp_recv_hiwat = 24576
5.
両方のホストの設定を、BDP の 279,600 に変更します。このためにはルート権限が必要です。
/usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 279600
/usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 279600
Solaris 上の 1 つのホストに対してバッファ設定の変更には、次のように設定します。
プライマリ・ホスト = PRIM、スタンバイ・ホスト名 = STBY
1.
PRIM の場合
ndd -set /dev/tcp tcp_host_param ‘STBY sendspace 279600 recvspace 279600’
2.
STBY の場合
ndd -set /dev/tcp tcp_host_param ‘PRIM sendspace 279600 recvspace 279600’
これらの新しい設定は新しい接続に対してすぐに有効になり、再起動は必要ありません。ただし、現在の接続に対しては
新しい設定は反映されません。したがって、これらの変更後、新しい TCP バッファの設定を取得するには、データベー
スおよびリスナーの再起動が必要になります。システムの再起動でこれらの設定が反映されたことを確認するには、
Solaris で/etc/rc2.d/S69inet のように指定して、システム起動のスクリプトにこれらのコマンドを挿入します。
Maximum Availability Architecture
5-27
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
フィジカル・スタンバイ・データベースのみ
5.2.19
スタンバイREDOログを使用する
ログを使用する
スタンバイ
両方のサイトでスタンバイ REDO ログ（SRL）を使用します。次の計算式に従って、SRL の数を算出してください。
SRL の数 = スレッド当たりのオンライン・ログ・グループのすべての合計 + 1
本番データベースのオンライン REDO ログ・グループよりも、1 つ多い数のログ・グループを定義しておくと、SRL をス
タンバイに割当てができなくなるため、本番インスタンスの LGWR がブロックされる可能性が少なくなります。たとえ
ばプライマリ・データベースに 2 つのインスタンス（スレッド）があり、各スレッドに 4 つのオンライン・ログ・グルー
プがある場合には、9 個の SRL グループになります。
•
本番データベースとスタンバイ・データベースの両方に、同じ数の SRL を作成します。
•
本番データベースのオンライン REDO ログと SRL はすべて同じサイズにします。
•
SRL は、本番データベースとスタンバイ・データベースの両方に、同じサイズと名前で定義します。
スタンバイ・データベースのリモート・ファイル・サーバー（RFS）プロセスは、本番データベースのオンライン REDO
ログと同じサイズの SRL に対してのみ書込みを行います。適切なサイズの SRL が見つからない場合は、RFS は、かわり
にアーカイブ REDO ファイルを直接作成し、アラート・ログに「No standby redo log files of size <#> blocks available」とい
うメッセージを記録します
LGWR 転送オプションが指定されている SRL は、ARCH 転送よりも高度なデータ保護が実現できます。これは ARCH の
ようにログの切換えを待つのではなく、変更がスタンバイに保持されるためです。また、SRL を使用すると、スイッチ
オーバーが始まったときに完全にアーカイブされたログを転送する必要がないため、スイッチオーバーにかかる時間が速
くなります。ローカル SRL のみスタンバイにアーカイブが必要ですが、これによって ARCH のようなネットワーク転送
のオーバーヘッドがなくなります。
5.2.20
最大パフォーマンス・モードで、10MBのバッファ・サイズを持つ
のバッファ・サイズを持つ
最大パフォーマンス・モードで、
ASYNC属性を使用する
属性を使用する
最大サイズの LGWR ASYNC バッファを 10MB（ASYNC=20480）に設定すると、WAN 上で最大のパフォーマンスが得ら
れます。LAN では、別の非同期バッファ・サイズはプライマリ・データベースのスループットに影響を及ぼしません。
これは前述の表 5-8 で示しています。また、最大バッファ・サイズを使用すると、WAN 上で非同期バッファが一杯にな
るために、「タイムアウト」のメッセージの発行が少なくなります（バッファを小さくするほど待機時間が増えるため、
バッファが一杯になる可能性が高くなります）。
Oracle9i Database Release 2 (9.2.0.3)は、非同期転送サービスについてパフォーマンスが改善されています。また、Oracle9i
Database Release 2 (9.2.0.3)からは、ネットワーク・バッファが一杯になり、5 秒間一杯のままになっていると、転送がタ
イムアウトになり ARCH 転送に変換されます。この状況は、スタンバイ宛先に対するネットワークが、プライマリ・デ
ータベースにおける REDO の生成レートよりも遅延することを表しています。これは、次のメッセージによって alert.log
に示されます。
'Timing out on NetServer %d prod=%d,cons=%d,threshold=%d"
このメッセージは、LGWR ASYNC 属性で設定されているスタンバイ宛先で、「ASYNC バッファが一杯」というエラー
の発生を意味しています。このようなエラーが発生すると、ログ転送サービスは、REDO データの転送を行うためのネッ
トワーク・サーバー・プロセスの使用を自動的に停止し、ログの切換えまでアーカイバ・プロセス（ARC）を使用します。
次のログ転送は、ASYNC 転送に戻ります。この変更は自動的に行われ、ユーザーが行う処理は特にありません。最大非
同期ネットワーク・バッファを 10MB にすると、
転送が ARCH に切り替わらないことが多くなりました。
バッファが 10MB
の場合に、100ms の RTT テストで ARCH に切り替わりました。10MB の非同期バッファ・テストの場合は、10ms および
50ms の RTT テストのみが 1 つのノードで ARCH に切り替わりました。これに対して、2MB バッファの・テストでは、
Maximum Availability Architecture
5-28
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
すべての RTT テスト（10、50、および 100ms）で ARCH に切り替わりました。圧縮付き SSH を使用している場合は、100ms
の RTT テストで 10MB の非同期バッファを使用している場合は ARCH に切り替わりません。
Error! Reference source not found.は、スタンバイ保護モードが最大パフォーマンスで、LGWR ASYNC に設定されている
場合のアーキテクチャを表しています。ネットワーク・バッファで十分な領域が使用できる場合は、LGWR 要求はバッ
ファされます。このようなケースでは、ネットワークの帯域幅が十分ではない場合、またはネットワーク I/O が処理され
るよりもネットワーク・バッファが早く一杯になった場合に、パフォーマンスが低下します。したがって、ネットワーク
の帯域幅が十分でなく、待機時間が長くなると、アプリケーションのスループットおよびアプリケーションの応答時間が
低下します。本番データベースがクラッシュして使用できなくなった場合は、ネットワーク・バッファ内のデータが失わ
れます。
図5-4: LGWR ASYNCの転送サービス
の転送サービス
5.2.21
最適なリカバリ・パフォーマンスを得られるようにスタンバイ・データベースと
ホストをチューニングする
フィジカル・スタンバイで Data Guard を利用する、またはなんらかのメディア・リカバリ操作を効率よく利用するには、
データベース・リカバリのチューニングが必要です。Oracle のメディア・リカバリ・チューニングのベスト・プラクティ
スと特定するために実施された、オラクル社内部の研究で示されているベスト・プラクティスに従ってください。
『Oracle9i メディア・リカバリに関するベスト・プラクティス』は、Oracle Technology Network Japan の
http://otn.oracle.co.jp/products/oracle9i/index.html#haで入手できます。
Maximum Availability Architecture
5-29
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
5.2.22
1つのスタンバイ・ホストで
つのスタンバイ・ホストでCPUの
の2倍の数のパラレル・リカバリを設定する
倍の数のパラレル・リカバリを設定する
つのスタンバイ・ホストで
この方法は、オラクル社内部のテスト研究に示されています。詳細は、『Oracle9i メディア・リカバリに関するベスト・
プラクティス』（Oracle Technology Network Japan のhttp://otn.oracle.co.jp/products/oracle9i/index.html#ha）を参照してくだ
さい。
パラレルのメディア・リカバリまたはパラレルのスタンバイ・リカバリを使用すると、OLTP の実行に対するシリアル・
リカバリで 3 倍のパフォーマンスを得ることができます。オラクル社のテストでは、大量のバッチ実行においてパフォー
マンスが最小になりました。推奨される並列度は、「ホスト上の CPU 数」に 2 を掛けた値です。データベース・パラメ
ータ PARALLEL_MAX_SERVERS は並列度の値以上に設定する必要があります。これは RECOVERY コマンドで指定し
た内容に関係なく、PARALLEL_MAX_SERVERS の値は可能なパラレル・リカバリ・プロセスの最大数になるためです。
最適なリカバリ・パフォーマンスを判断するには、いくつかのシリアル・リカバリおよびパラレル・リカバリの実行を比
較する必要があります。次に、リカバリの並列性を設定する場合の例を示します。
RECOVER MANAGED STANDBY DATABASE PARALLEL <#CPUS * 2>; # for standby managed recovery
RECOVER STANDBY DATABASE PARALLEL <#CPUS * 2>;
# for manual standby recovery
RECOVER DATABASE PARALLEL <#CPUS * 2>;
# for manual media recovery
Oracle9i リリース 2 のパッチセット 3 に含まれているバグ、
2555509 に対して修正を行っていることを確認してください。
5.2.23
パラレル・リカバリのバッファ・サイズを4Kに設定する
パラレル・リカバリのバッファ・サイズを に設定する
この方法は、オラクル社内部のテスト検証で示されました。詳細は、『Oracle9i メディア・リカバリに関するベスト・
プラクティス』（Oracle Technology Network Japan のhttp://otn.oracle.co.jp/products/oracle9i/index.html#ha）を参照してくだ
さい。
パラレル・メディア・リカバリまたはパラレル・スタンバイ・リカバリを使用している場合に、
PARALLEL_EXECUTION_MESSAGE_SIZE データベース・パラメータの値を 4K（4096）に増やすと、パラレル・リカバ
リが 20%改善されます。これは、スイッチオーバーの処理に備えて、プライマリおよびスタンバイの両方で設定する必
要があります。このパラメータの値を増やすと、各パラレル実行のスレーブ・プロセスによって、共有プールのメモリー
が追加で必要になります。
このパラメータはパラレル問合せの処理でも使用されるため、すべてのパラレル問合せ処理でテストを行い、システムに
十分なメモリーがあることを確認してください。32 ビット・インストレーションでパラレル問合せのスレーブが増加す
ると、メモリーの限界に達し、PARALLEL_EXECUTION_MESSAGE_SIZE の値をデフォルトの 2K（2048）から 4K に増や
せません。
5.2.24
スタンバイ上のオンラインREDOログ・グループを消去する
ログ・グループを消去する
スタンバイ上のオンライン
スタンバイの作成後、またはスイッチオーバーの後でスタンバイ上のいずれかのオンライン REDO ログ・グループを消
去すると、以降のスイッチオーバーまたはフェイルオーバーで、ログを消去する必要がありません。内部テストではこれ
によって、スイッチオーバーまたはフェイルオーバー時間が 15 秒短縮されました。
スタンバイ上のオンライン REDO ログ・グループの消去を確認するには、アラート・ログで該当するメッセージを探す
他には方法がありません。最善の方法は、スイッチオーバーまたはスタンバイのインスタンス化の最後の手順でこの検索
を行うことです。具体的には ALTER DATABASE CLEAR LOGFILE GROUP <GROUP# FROM v$log>;というコマンドを使
用します。V$LOG ビューに示されている各オンライン REDO ログ・グループに対して、このコマンドを実行します。
Maximum Availability Architecture
5-30
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
ロジカル・スタンバイのみ
詳細は、テクニカル・ペーパー『Oracle9i Data Guard: SQL Apply のベスト・プラクティス』
（http://otn.oracle.co.jp/products/oracle9i/index.html#ha）を参照してください。
SQL Apply エンジンには、独自の専用パラメータ・セットがあります。これは、DBMS_LOGSTDBY パッケージ・プロシ
ージャによって設定されます。
次のような APPLY_SET プロシージャの呼出しで、パラメータを設定します。
execute dbms_logstdby.apply_set(‘<parameter name>’,value);
特定のパラメータをキャンセルする、または設定しない場合は、APPLY_UNSET プロシージャを次のように使用します。
execute dbms_logstdby.apply_unset(‘<parameter name>’)
APPLY_SET および APPLY_UNSET プロシージャは、SQL Apply エンジンが停止している場合のみ実行できることに注意
してください。コマンドを実行した際に、SQL Apply エンジンが実行中の場合は、ORA-16103 のエラーが生成されます。
5.2.25
すべての本番表でサプリメンタル・ロギングとプライマリ・キー制約を
使用する
すべての表で主キー制約を定義することをお薦めします。これは、列が NOT NULL として定義されることを意味します。
主キー制約を定義できない表では、NOT NULL として定義される列に索引を定義する必要があります。表に適切な列が
存在しない場合は、表を調べて、SQL Apply エンジンによってスキップが可能かの確認が必要です。
5.2.26
ロジカル・スタンバイ
SQL Applyパラメータを設定する
パラメータを設定する
ロジカル・スタンバイMAX_SERVERS
ンバイ
プライマリ・データベースで、レポート作成または意思決定支援の処理の負荷を軽減するために SQL Apply データベー
スを使用している場合は、このような処理に対するパラレル問合せのいくつかのスレーブを保持しておくことがあります。
デフォルトでは、SQL Apply エンジンはパラレル問合せのすべてのスレーブを使用するため、ロジカル・スタンバイの
MAX_SERVERS パラメータを設定すると、この処理に対してパラレル問合せのいくつかのスレーブが保持されます。
このパラメータは、開始時に SQL Apply エンジンが保持しておくパラレル問合せのスレーブ数を指定します。
表5-9: ロジカル・スタンバイのMAX_SERVERSの例
の例
ロジカル・スタンバイの
スタンバイ上のデータベース初期
スタンバイ上の
化パラメータ
SQL Apply パラメータ
MAX_SERVERS
PARALLEL_MAX_SERVERS
パラレル問合せの
処理に対して
保持されるサーバー数
SQL Apply の
処理に対して
保持されるサーバー数
24
設定しない
0
24
24
24
0
24
48
24
24
24
このパラメータは最初に 9、または（3 × 最初の CPU − MAX_SERVERS）の大きい方、つまり max (9, 3 × CPU)に設
定することをお薦めします。
Maximum Availability Architecture
5-31
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
5.2.27
初期化パラメータPARALLEL_MAX_SERVERSの値を増やす
の値を増やす
初期化パラメータ
初期化パラメータ PARALLEL_MAX_SERVERS の値を、プライマリおよびスタンバイの両方のインスタンスで 9、また
は（3 × CPU）の大きい方の値に増やします。つまり、PARALLEL_MAX_SERVERS=現在の値 + max (9, 3 × CPU)としま
す。
PARALLEL_MAX_SERVERS パラメータは、データベース・インスタンス上に作成できるパラレル問合せの最大数を表し
ます。コーディネータ・プロセスは除いて、SQL Apply エンジンを構成しているすべての処理は、パラレル問合せ処理の
プールにあります。デフォルトでは、SQL Apply エンジンはデータベース・インスタンス上で有効なすべてのパラレル問
合せ処理を使用します。この動作は、ロジカル・スタンバイ・パラメータを使用して上書きできます。
このパラメータは、SQL Apply パラメータ MAX_SERVERS の値まで増やすことをお薦めします。
5.2.28
MAX_SGA SQL Applyパラメータに対してデフォルトを使用する
パラメータに対してデフォルトを使用する
MAX_SGA パラメータでは、共有プールの 1/4 の「T-LCR Struct」に対するデフォルトの割当てを変更できます。このパラ
メータは、メガバイトで指定され、共有プールの 1/4 の制限を超えてはいけません。
このパラメータは設定しないで、共有プールの 1/4 をデフォルトの状態をお薦めします。
5.2.29
_EAGER_SIZE SQL Applyパラメータを
パラメータを1000に設定する
に設定する
パラメータを
※本パラメータは隠しパラメータであり、マニュアルには使用方法が記載されていません。また、使用する場合はオラク
ル社サポートサービスの指示に従ってください。
_EAGER_SIZE パラメータは、1 つのトランザクションで修正可能な最少行数を表します。この前に、トランザクション
は eager トランザクションであると判断されます。通常の環境では、SQL Apply エンジンは、コミットされたトランザク
ションをコーディネータに渡し、最終的には適用スレーブに渡します。eager トランザクションは、SQL Apply エンジン
によってこのように処理される通常のトランザクションとは異なります。eager トランザクションが特定されると、コー
ディネータは Apply スレーブに関連付けてトランザクションに対してサービスを行い、準備ができたときに SQL 文が適
用スレーブに渡されます。このため、完全なトランザクションを作成する必要がありません。
次の 2 つの理由により、eager トランザクションの識別が必要です。
1.
1 つのトランザクションで、プライマリ・データベース上の 100 万行を更新すると、T-LCR Struct のサイズが不
足して、トランザクションをスタンバイ・データベースに適用させるため必要な 100 万個の SQL 文をサポート
できません。
2.
SQL 文をスタンバイ・データベースに適用すると、準備が完了していることになり、完全なトランザクションが
作成後で Apply スレーブのみに割り当てた場合よりも、トランザクションがコミットされる時間が非常に短くな
ります。これは、整合性が完全であることを仮定して、SQL Apply エンジンが新しいトランザクションをスタン
バイ・データベースへ継続して適用できることを意味しています。
_EAGER_SIZE は、修正される行について指定します。
Oracle9i Database Release 2 では、このパラメータのデフォルト値は、MAX_SGA のロジカル・スタンバイ・パラメータに
1000 を掛けた値をベースとしています。したがって、MAX_SGA パラメータが 500MB に指定されている場合は、
_EAGER_SIZE パラメータのデフォルト値は 500,000 行となります。この値は通常では大きすぎます。
Maximum Availability Architecture
5-32
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
APPLY_DELAY SQL Applyパラメータを設定する
パラメータを設定する
5.2.30
APPLY_DELAY パラメータは、SQL Apply エンジンで、ログ・ファイルがロジカル・スタンバイ・データベースに登録さ
れた時間と比べて、アーカイブ REDO ログの適用をどの程度遅らせるかを表します。この遅延時間は、管理者が識別、
レポート作成、および最終的には SQL Apply エンジンの停止に十分な値を設定します。これにより、データベース管理
者が SQL Apply エンジンを停止させて、エラーがロジカル・スタンバイ・データベースにレプリケートされないように
できます。
このパラメータは、分単位で指定します。
TRANSACTION_CONSISTENCY SQL Applyパラメータを設定する
パラメータを設定する
5.2.31
Oracle Data Guard SQL Apply は、データ・アプリケーションの次のメソッドをサポートしています。
•
レポート作成または意思決定支援システムに対しては、FULL または READ_ONLY トランザクションの整合性が
実現されます。
•
障害時リカバリのソリューションに対して、または SQL Apply エンジンでキャッチアップ（巻返し）が必要な場
合、またはトランザクションの順序付けが必須でない場合は、TRANSACTION_CONSISTENCY を NONE に設定し
ます。
レポート作成または意思決定支援の処理でロジカル・スタンバイ・データベースが使用される場合は、次のようになりま
す。
•
スタンバイ・データベースに複数インスタンスがある（Real Application Clusters）場合は、FULL を選択します。
•
スタンバイ・データベースにインスタンスが 1 つのみ存在する場合は（非 Real Application Clusters）、READ_ONLY
を選択します。
5.2.32
不要なオブジェクトについて
Applyをスキップする
をスキップする
不要なオブジェクトについてSQL
なオブジェクトについて
スタンバイ・データベースにレプリケートする必要がないデータベース・オブジェクトでは、DBMS_LOGSTDBY.SKIP
プロシージャを使用してこれらのオブジェクトのスキップをお薦めします。
このようなオブジェクトをスキップすると、SQL Apply エンジンは、必要ない表を管理するための不要な処理から解放さ
れます。
このような状況は、意思決定支援の環境で頻繁に発生します。
5.2.33
データベース・リンクを作成する
スイッチオーバー処理の間、プライマリおよびロジカル・スタンバイ・データベースは詳細はデータベース情報を通信す
る必要があります。Oracle のデータベース・リンクは、SQL Apply データベースのインスタンス化にプライマリおよびロ
ジカル・スタンバイ・データベースにおける作成をお薦めします。Oracle データベース・リンクの名前は、プライマリお
よびスタンバイ・データベースで同じになるように、ターゲット・データベースが実行するロールに反映します。
プライマリおよびロジカル・スタンバイ・データベースの両方で、次の手順を完全にしておきます。
ロジカル・スタンバイ・データベース
SQL> connect sys/<password>
SQL> create database link prim_db
2
connect to system
3
identified by manager
4
using ‘SALES_PRIM’;
Maximum Availability Architecture
5-33
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
プライマリ・サイト・データベース
SQL> connect sys/<password>
SQL> create database link log_db
2
connect to system
3
identified by manager
4
using ‘SALES_LOG_SEC’;
次の例は、Logical Standby 環境の 2 つの異なるノードで実行される、同じ問合せの結果を表しています。
SQL> select local.host_name local_host
2
,.remote.host_name remote_host
3
from v$instance@prim_db remote
4
, v$instance local;
LOCAL_HOST
REMOTE_HOST
----------------------- ----------------------primary1
secondary2
SQL> select local.host_name local_host
2
,.remote.host_name remote_host
3
from v$instance@log_db remote
4
, v$instance local;
LOCAL_HOST
REMOTE_HOST
----------------------- ----------------------secondary2
primary1
Maximum Availability Architecture
5-34
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
5.3
バックアップとRecovery
Manager
バックアップと
すべてのデータベースを適切にバックアップしておくことは重要ですが、MAA 環境では、バックアップを使用したリカ
バリが最も迅速なソリューションであるとはかぎりません。
冗長性を備え、対照型のハードウェアとソフトウェアで MAA
を構成することにより、ほとんどの問題の解決が可能です。障害時のリカバリで Oracle RAC および Data Guard のテクノ
ロジを使用すると、バックアップからリストアするよりも高速です。
RAC は、標準の Oracle 機能上に、より高いレベルの可用性を追加します。RAC は、n ノード・クラスタの n-1 のノード
障害において可用性を実現するために、クラスタリングで提供される冗長性を利用します。つまり、すべてのユーザーは、
クラスタ内で使用できるノードが少なくとも 1 つあれば、すべてのデータにアクセスできます。RAC 環境では、クラス
タ・コンポーネントの障害およびソフトウェア障害に対して保護されます。ただし、メディア障害および人的エラーによ
っては、システムが停止する場合があります。
計画されているメンテナンス、メディア障害、ユーザー・エラー、またはその他の障害の際には、Data Guard のスイッチ
オーバーおよびフェイルオーバー機能によって、スタンバイ・データベースへの切換えまたはフェイルオーバーのメカニ
ズムが提供されます。バックアップからリストアするには、データベースのサイズ、バックアップの頻度、バックアップ
の特定に必要な時間、バックアップ・メディアのスピードなどの要因によって、数時間または数日かかります。したがっ
て、MAA でのデータベース・バックアップは、主に Data Guard のフェイルオーバーまたは二重のデータベース障害の後
のフォルト・トレランスのリストアに使用されます。
システム全体の項可用性を実現するソリューションにおいて、およびフォルト・トレランスが許容できる時間内で確実に
リストアするには、適切なバックアップとリカバリの方針が非常に重要です。この項では、MAA におけるバックアップ
とリカバリのベスト・プラクティスについて説明します。バックアップおよびリカバリ構成のベスト・プラクティスは次
のとおりです。
•
バックアップを使用するタイミングを理解する
•
データベース・ファイルのバックアップで Recovery Manager（RMAN）を使用する
•
Recovery Catalog を使用する
•
適切なバックアップ頻度を選択する
•
バックアップ領域に、オンディスク・バックアップを保持するための十分な領域を確保する
•
プライマリおよびセカンダリ・サイトの両方でディスクをバックアップする
•
RMAN コマンドの CATALOG を使用したディスク・バックアップのかわりに使用した場合に、ミラーの分割
によるバックアップをカタログする
•
RMAN コマンドの BACKUP BACKUPSET を使用して、プライマリ・およびセカンダリ・サイトのディスク・
バックアップからテープ・バックアップを作成する
•
バックアップ中に RMAN リポジトリとしてターゲット・データベースの制御ファイルを使用し、RMAN コマ
ンドの RESYNC CATALOG を使用して再同期化する
•
制御ファイルおよびサーバー・パラメータ・ファイルに対して RMAN の自動バックアップ機能を使用する
•
定期的にリカバリ手順をテストする
•
制御ファイルのバックアップを頻繁に作成し、最新の制御ファイル作成スクリプトを保持する
Maximum Availability Architecture
5-35
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
5.3.1
バックアップを使用するタイミングを理解する
ほとんどの本番データベースの計画外停止（「停止」を参照）は、MAA の様々なコンポーネントによって自動的に処理
される（インスタンスの停止は RAC で自動的に処理されるなど）か、または（表が突然削除された場合など）、スタン
バイ・データベースによって解決されます。ただし、次のように、データベースのバックアップが必要になります。
•
スタンバイ・データベースのインスタンス化
フェイルオーバー後フォルト・トレランスをリストアする場合
MAA 環境の初期設定
スタンバイ・データベースで破損またはメディア障害が発生した後
•
ブロック・メディア・リカバリを使用したオブジェクト・レベルのリカバリ
•
二重障害の解決
•
アーカイブ目的での長期間のテープ保存
スタンバイ・データベースのインスタンス化
本番データベースで、スタンバイ・データベースへのフェイルオーバーが必要な問題（破損、メディア障害、ユーザー・
エラーなど）の発生後は、本番データベースが定義されていたサイトに、新しいスタンバイ・データベースの作成が必要
です。スタンバイは、オンディスクのローカル・バックアップ、リモート・バックアップ、またはテープ・バックアップ
から再作成できます。ローカルのオンディスク・バックアップは、最も迅速で適切な方法です。MAA データベースはリ
ジリエンスがなく、新しいスタンバイが設定されて、指定時期の状態にリカバリされるまで脆弱になります。詳細は、「デ
ータベースの完全なフォルト・トレランスをリストアする」を参照してください。
MAA 環境の最初の設定には、セカンダリ・サイトで最初にスタンバイ・データベースを作成する際に、リストア用に本
番データベースのバックアップが必要です。最初にスタンバイ・データベースを作成する場合の詳細は、「データベース
の完全なフォルト・トレランスをリストアする」を参照してください。
3 番目のシナリオでは、スタンバイ・データベースの作成にバックアップの使用が必要で、これは既存のスタンバイ・デ
ータベースで、1 つまたは複数のデータ・ファイルに影響を与えるディスクの破損や、メディア障害が発生した場合に使
用します。リカバリでは、影響を受けるデータ・ファイル全体のバックアップをセカンダリ・サイトのみでバックアップ
し、MRP をリストアして、スタンバイ・データベースが指定時期の状態に戻す方法が推奨されます。HARD を使用する
と、このような問題を回避できます。詳細は、「ストレージ」を参照してください。
ブロック・メディア・リカバリを使用したオブジェクト・レベル
オブジェクト・レベルのリカバリ
ブロック・メディア・リカバリを使用した
オブジェクト・レベル
のリカバリ
本番環境におけるほとんどの停止は、Data Guard のフェイルオーバー手順、または様々なオブジェクト・リカバリ・ソリ
ューションを使用して、スタンバイ・データベースにフェイルオーバーできます。ただし、本番データベースのある部分
のみ、または比較的重要ではないコンポーネントで問題が発生した場合には、ローカルの RMAN バックアップから本番
データベースの特定の部分をリストアし、RMAN のブロック・メディア・リカバリを使用してその部分をリカバリでき
ます。このソリューションでは、部分的な可用性が実現され、現在のスタンバイ・データベースはそのままの状態で保持
されます。詳細は、「停止と解決」の章の「オブジェクト・リカバリ・ソリューション」を参照してください。
Maximum Availability Architecture
5-36
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
二重障害の解決
二重の障害は、本番およびスタンバイの両方のデータベースの可用性に影響を与えます。このような状況を解決する唯一
の手段は、有効なバックアップから本番データベースを再作成し、その後でスタンバイ・データベースを再作成する方法
です。二重の障害の例として、セカンダリ・サイトにおいてサイトが停止し、それによってフォルト・トレランスが排除
され、その後で本番データベースにおいて不用意に表を削除するなどのユーザー・エラーが発生した場合が考えられます。
複数の障害すなわち災害（プライマリ・サイトでの停止に続いて、セカンダリ・サイトも停止するなど）では、オフサイ
トのロケーションにあるバックアップを使用します。したがって、最も被害の大きい環境でサービスを回復させるために、
オフサイトにあるバックアップ・テープの提供および保守のための処理を作成してそれに従う必要があります。詳細は、
「データベースの完全なフォルト・トレランスをリストアする」の章の「二重障害の後でデータベースの完全なフォルト・
トレランスをリストアする」を参照してください。
アーカイブ目的での長期バックアップ
ビジネス環境では、数年間にわたって長期のバックアップを管理できる必要があります。RMAN で KEEP オプションを
使用すると、保存方針から除外され、有効期限を持たないバックアップを保持して、データベースを特定の時期にリスト
アおよびリカバリが可能です。RMAN リポジトリに対してリカバリ・カタログを使用して、領域不足によってバックア
ップ・メタデータが失われないことが重要です。領域不足は、RMAN リポジトリでターゲット・データベースの制御フ
ァイルを使用している場合によく発生します。
参照: 『Oracle9i Recovery Manager ユーザーズ・ガイド』の第 5 章「RMAN 概要 I: チャネル、バックアップおよびコピ
ー」の「Backups Exempt from the Retention Policy」の項を参照してください。
5.3.2
データベース・ファイルのバックアップでRecovery
データベース・ファイルのバックアップで
Manager（
（RMAN）を
）を
使用する
Recovery Manager（RMAN）は、サーバー・セッションを使用して、バックアップとリカバリの処理を実行し、バックア
ップに関するメタデータをリポジトリに保存します。RMAN を使用すると、通常のユーザー管理によるバックアップ方
法に比べて様々なメリットがあります。表領域をバックアップ・モードにすることなくオンラインでデータベース・バッ
クアップする機能、増分バックアップのサポート、バックアップおよびリストアの際のデータ・ブロックの整合性チェッ
ク、実際に処理を実行せずにバックアップをテストしリストアする機能が提供されます。ユーザー管理の方法では、すべ
てのデータベース・ファイルとバックアップの内容を追跡する必要がありますが、RMAN ではバックアップとリカバリ
が自動化されます。たとえば、ユーザーが各データ・ファイルに対するバックアップの場所を特定し、オペレーティング・
システムのコマンドを使用して適切な場所にコピーして、適用するログを選択するかわりに、RMAN ではこれらのタス
クを自動的に管理します。また、ブロック・リカバリなど、RMAN を使用した場合のみ有効になる Oracle リカバリの機
能もあります。
参照: 『Oracle9i Recovery Manager ユーザーズ・ガイド』の第 1 章「I 概要」の「Recovery Manager を使用する理由」の
項を参照してください。
5.3.3
Recovery Catalogを使用する
を使用する
RMAN は、バックアップ中のデータベースの制御ファイルのバックアップ・メタデータを自動的に管理します。バック
アップ・メタデータの長期にわたる保護および保持には、最も一般的なリカバリ・カタログである RMAN リポジトリを
データベースのデータベースに作成します。リカバリ・カタログを使用すると、バックアップ情報の長期保存、メタデー
タの複数のデータベースへの保持、別のシステムで使用するバックアップのリストアなど、様々なメリットがあります。
また、ターゲット・データベースの制御ファイルのみを使用してリポジトリを保持している場合、対象のバックアップ・
メタデータをすべて保持すると、その最大サイズの制限によって制御ファイルの領域が不足する場合があります。制御フ
ァイルが小さすぎて追加のバックアップ・メタデータを保持できない場合は、既存のバックアップ情報が上書きされるた
め、これらのバックアップを使用たリストアおよびリカバリが困難になります。
Maximum Availability Architecture
5-37
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
リカバリ・カタログは、Oracle Enterprise Manager のリポジトリと同じデータベース内に作成します。詳細は、「Enterprise
Manager」の項を参照してください。
参照: 『Oracle9i Recovery Manager ユーザーズ・ガイド』の第 8 章「Recovery Manager 環境の構成」の「リカバリ・カタ
ログの設定」の項を参照してください。
5.3.4
適切なバックアップ頻度を選択する
MAA 環境では、データベースがフォルト・トレランス機能を持たない場合にはバックアップの使用が必要なため、バッ
クアップを作成する頻度は重要な考慮事項です。この頻度を決める場合には、フェイルオーバーの後でフォルト・トレラ
ンスのリストアに必要な時間を基準に判断します。この設定により、次の時間が決定されます。
•
バックアップが完了する時間
•
新しいスタンバイ・データベースをインスタンス化する時間。これは主に次の 2 つの要因によって決まります。
既存のオンディスク・バックアップからデータ・ファイルをリストアする時間
データベースを、指定時期の状態までリカバリする時間
次に推奨する、データベースのバックアップをディスク上に作成してください。テープのバックアップは、RMAN コマ
ンドの BACKUP BACKUPSET を使用して、オンディスクのバックアップから作成します。
ローカルのオンディスク・バックアップを使用している場合は、新しいスタンバイ・サイトに新しいスタンバイ・データ
ベースを作成する時間、および指定時期の状態まで戻す時間は、次の関数を使用します。
•
バックアップからデータ・ファイルをリストアする時間
•
データベースを、指定時期の状態にリカバリする時間
リストアで使用されるバックアップの年齢 − より古いバックアップからリカバリする場合には、新しいバ
ックアップからのリカバリよりも多くのリカバリが必要になります。
スタンバイ・データベースの時期指定 − 時間差が大きな値に設定されているスタンバイ・データベースを
リカバリする場合は、時間差が小さい値に設定されている場合よりも時間が短くてすみます。
5
本番の REDO 生成レート − バックアップがリストアされ、スタンバイ・データベースがリカバリされて
いる間も、本番データベースはユーザーにサービスを提供し、REDO の生成を続行します。生成された追加
の REDO は、リカバリ・プロセスの一部として、指定時期の状態に戻す場合にスタンバイ・データベースに
適用が必要です。
6
スタンバイの最大 REDO 適用レート − スタンバイの最大 REDO 適用レートは、本番 REDO の生成レート
よりも大きくして、本番 REDO によって新しい REDO の生成に、スタンバイ・データベースがキャッチア
ップします。スタンバイの最大 REDO 適用レートを、本番データベースで REDO を生成するレートよりも
小さい値に設定すると、スタンバイ・データベースはその後も遅延し、本番データベースによる REDO の生
成が減少するまで、指定時期の状態に戻すことはできません。
リストア時間、本番の REDO 生成レート、スタンバイ・データベースの指定時期の状態、およびスタンバイの最大 REDO
適用レートが一定であると仮定すると、新しいスタンバイ・データベースを作成し、完全にリカバリする時間は、主にバ
ックアップが作成された日付によって決定されます。リストア時間の短縮（『Oracle9i Recovery Manager ユーザーズ・ガ
イド』の第 14 章「Recovery Manager のチューニング」参照）、およびスタンバイの REDO 適用レートの増加（これはメ
ディア・リカバリのチューニングと同等）によって、リカバリの時間を短縮できます。メディア・リカバリのチューニン
5
本番のREDO生成レートは、平均およびピーク時のトランザクション処理のいくつかの間隔でstatspackを実行することによって取得
することができます。statspackには、「ロード・プロファイル」セクションがあり、ここでは1秒間に生成される平均の「REDOサ
イズ」が含まれています。Oracleの『パフォーマンス・チューニング・ガイドおよびリファレンス』を参照してください。
6
スタンバイのREDO適用レート、またはメディア・リカバリのレートは、いくつかのアーカイブ・ログを適用し、平均の適用レー
トを決定することによって取得できます。http://otn.oracle.co.jp/の「Oracle9i メディア・リカバリに関するベスト・プラクティス」
を参照してください。
Maximum Availability Architecture
5-38
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
グについて、詳細は、OTN（http://otn.oracle.co.jp）の「Oracle9i メディア・リカバリに関するベスト・プラクティス」を
参照してください。
バックアップ領域に、オンディスク・バックアップを保持するための十分な
領域を確保する
5.3.5
オンディスク・バックアップは、バックアップ領域として指定された領域に確保する必要があります。このバックアップ
領域は、ミラー化およびストライプされている必要があります。バックアップ領域の詳細は、「ストレージ構成のベスト・
プラクティス」を参照してください。この領域の大きさを正確に算出する計算式はありません。ただし、バックアップ領
域は、2 つ以上の完全なデータベースのバックアップ、およびアーカイブ REDO ログ・ファイルを保持できるサイズが必
要です。データベースのバックアップは少なくとも 2 つ必要です。これは、1 つめのバックアップが削除される前に、も
う 1 のバックアップが正常に終了する必要があるためです。データ・ファイルの追加や削除など、データベースの物理的
な変更によって、バックアップ領域の要件も変わるため、これらの変更は考慮されます。
RMAN のデータベース全体のバックアップでは、使用されたデータベースのすべてのブロックをすべてバックアップし
ます。このため、Oracle でファイルの使用されたブロックによってサイズが決定されます。以前はあるオブジェクトによ
ってブロックが使用されていて、現在はそのオブジェクトが削除されたためにブロックが使用されていない場合でも、
RMAN はそれらのブロックをバックアップします。増分バックアップを実行しても、すべてのブロックは、バックアッ
プ時に読み込まれるため、バックアップ時間の短縮には効果がありません。ただし、変更されたブロックのみがバックア
ップされるため、必要なバックアップ領域が少なくて済むという重要なメリットがあります。
プライマリおよびセカンダリ・サイトの両方でディスクをバックアップする
5.3.6
以前は、MAA では、プライマリ・サイトのオンディスク・バックアップとセカンダリ・サイトのテープ・バックアップ、
またはセカンダリ・サイトのオンディスクおよびテープのバックアップを推奨していました。どちらの方法を使用するか
は、フェイルオーバーの後でスタンバイを再度インスタンス化する場合にどの方法を使用するか（ローカル・バックアッ
プを使用する、またはネットワーク介して本番データベースから直接行うか）によって判断されていました。
この推奨事項は、プライマリおよびセカンダリ・サイトの両方でバックアップをとるよう変更されました。スタンバイ・
サイトのみでのバックアップは、次のようなリスクがあります。
•
大規模データベースでは、フェイルオーバーの後にフォルト・トレランスをリストアする時間が非常に長くかか
る
•
セカンダリ・サイトが使用できない期間が長くなると、プライマリ・サイトで新しいバックアップ手順を導入す
る
•
プライマリ・サイトの RMAN ブロック・メディア・リカバリは、オブジェクト・レベルの停止に対するリカバ
リ・オプションでは使用できない
ここで、セカンダリ・サイトのみでバックアップが行われており、セカンダリ・サイトが停止していると仮定します（予
測ではリカバリに 3 日かかります）。プライマリ・サイトは、通常はフェイルオーバーによって解消できる停止の影響（ユ
ーザー・エラーなどの）を受けやすくなっており、さらに、ローカル・バックアップによって解消できる停止（ブロック・
メディア・リカバリによって解決できるオブジェクト・レベルの停止など）に対しても脆弱になっています。このような
状況では、スタンバイ・サイトで用意されていたオフサイトのテープ・バックアップを物理的に提供して、本番データベ
ースの停止を解消するのみです。プライマリ・サイトのバックアップが使用できない場合は、元に戻すことが可能なフェ
イルオーバーのかわりに、ローカル・リストアを使用できます。データは損失する可能性がありますが、プライマリ・サ
イトのバックアップを用意しておくと、このシナリオの MTTR を非常に短縮することができます。
Maximum Availability Architecture
5-39
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
可能な方法としては、セカンダリ・サイトが停止した場合に、プライマリ・サイトのバックアップの開始方法があります。
ただし、すでに逼迫した環境になっている場合には、新しい処理と手順の導入と、管理者の誤操作による影響を避けるた
め、この方法は使用しないでください。
使用しないでください。また、プライマリ・サイトでバックアップが取れないことが判明した場合は、
使用しないでください。
状況はさらに複雑になります。
さらに、RMAN のブロック・メディア・リカバリを使用している場合には、適切な MTTR を保証するにはプライマリ・
サイトのディスク・バックアップが必要です。ローカルのオンディスク・バックアップがない場合は、スタンバイで作成
されたバックアップをプライマリでリストアが必要ですが、このような停止では MTTR が非常に長くなります。
5.3.7
RMANコマンドの
コマンドのCATALOGを使用したディスク・バックアップのかわりに
を使用したディスク・バックアップのかわりに
コマンドの
使用した場合に、ミラーの分割によるバックアップをカタログする
ミラーの分割によるバックアップでは、オペレーティング・システムまたはストレージ・ソフトウェアが、ミラー化され
たデータ・ファイルの 3 つのコピーを保持しています。このバックアップは、RMAN が作成したオンディスク・バック
アップのかわりに使用できます。RMAN は、ミラーの分割によるバックアップを自動的に作成しませんが、RMAN
CATALOG コマンドを使用して RMAN リポジトリにカタログされる場合は、リストアおよびリカバリ手順に対してミラ
ーの分割によるバックアップを使用できます。
参照: 『Oracle9i Recovery Manager ユーザーズ・ガイド』の第 9 章「Recovery Manager でのバックアップおよびコピーの
作成」の「Recovery Manager を使用したミラー分割によるバックアップの作成」の項を参照してください。
5.3.8
RMANコマンドの
コマンドのBACKUP
BACKUPSETを使用して、プライマリおよび
を使用して、プライマリおよび
コマンドの
セカンダリ・サイトのディスク・バックアップからテープ・バックアップを
作成する
MAA 環境では、テープ・バックアップも必要です。テープ・バックアップは、セカンダリ・サイト全体の停止に続くプ
ライマリ・サイト全体の停止などの特定の二重停止に対する障害保護を提供します。非常に条件の悪い環境でも、オフサ
イトで管理されているテープ・バックアップからのリストアは、有効なリカバリ手段です。
テープ・バックアップは、RMAN コマンドの BACKUP BACKUPSET を使用して、ローカルなオンディスク・バックアッ
プから直接作成できます。テープ・バックアップに対して既存のオンディスク・バックアップを使用すると、データベー
スとバックアップ間の I/O の競合が最少になるため、製品サービス・レベルに対する影響が減少または排除されます。
参照: 『Oracle9i Recovery Manager ユーザーズ・ガイド』の第 9 章「Recovery Manager でのバックアップおよびコピーの
作成」の「Recovery Manager を使用したバックアップ・セットのバックアップ」の項を参照してください。
5.3.9
バックアップ中にRMANリポジトリとしてターゲット・データベースの
リポジトリとしてターゲット・データベースの
バックアップ中に
制御ファイルを使用し、RMANコマンドの
コマンドのRESYNC
CATALOGを使用して
を使用して
制御ファイルを使用し、
コマンドの
再同期化する
（ディスクまたはテープに対して）バックアップの作成には、RMAN リポジトリとしてターゲット・データベースの制御
ファイルを使用します。このため、バックアップが可能か、またはバックアップが成功するかは、管理が容易なデータベ
ースにおける RMAN カタログの可用性には依存しません。これには、RMAN を NOCATALOG オプションで実行します。
バックアップが完了すると、ターゲット・データベースの制御ファイルに保存されている新しいバックアップ情報は、
RESYNC CATALOG コマンドを使用してリカバリ・カタログと再同期化できます。
参照: 『Oracle9i Recovery Manager ユーザーズ・ガイド』の第 16 章「Recovery Manager のリポジトリ」の「リカバリ・
カタログの再同期化」の項を参照してください。
Maximum Availability Architecture
5-40
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベース構成
5.3.10
制御ファイルおよびサーバー・パラメータ・ファイルに対してRMANの
の
制御ファイルおよびサーバー・パラメータ・ファイルに対して
自動バックアップ機能を使用する
RMAN の自動バックアップ機能は、制御ファイルが消失して、リカバリ・カタログが消失したり、使用できなくなった
場合に、制御ファイルに含まれているバックアップ・リポジトリのリストア方法を提供します。制御ファイルの自動バッ
クアップをリストアするには、リカバリ・カタログまたはターゲットの制御ファイルは必要ありません。RMAN の自動
バックアップ機能は、CONFIGURE CONTROLFILE AUTOBACKUP ON コマンドで使用できます。
参照: 『Oracle9i Recovery Manager ユーザーズ・ガイド』の第 5 章「概念 I: チャネル、バックアップおよびコピー」の
「制御ファイルとサーバー・パラメータ・ファイルの自動バックアップ」の項を参照してください。
5.3.11
定期的にリカバリ手順をテストする
リカバリの成功には、テストされた完全なバックアップが存在することが重要です。最も一般的なタイプの停止や発生す
る可能性の低い停止など、様々なタイプの停止に対するテスト計画を作成します。バックアップ手順を作成しても、それ
でバックアップが成功するわけではなく、その手順を試行する必要があります。リカバリ手順の定期的なテストによって、
バックアップ手順でエラーを監視し、バックアップの妥当性をチェックします。また、RMAN コマンドの BACKUP
VALIDATE および RESTORE...VALIDATE を使用して、バックアップおよびリストアの機能を検証します。
参照: 『Oracle9i Recovery Manager ユーザーズ・ガイド』の第 10 章「Recovery Manager によるリストアとリカバリ」の
「バックアップとコピーのリストアの妥当性チェック」の項を参照してください。
Maximum Availability Architecture
5-41
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Data Centerの
のMAA
6.
•
このドキュメントではこれまで、1 つのデータベースまたは 1 つのアプリケーションに対する MAA を中心に説
明してきました。ただし、データ・センターは、複数の本番アプリケーションおよびデータベースをサポートし
ています。この項では、複数のアプリケーションをサポートしている、分散した 2 つのデータ・センターにおけ
る MAA について説明します。データ・センターは、アクティブ/非アクティブで構成できます。
•
アクティブ/非アクティブの構成
アクティブ/非アクティブのデータ・センター構成には、本番およびセカンダリ・データ・センターで使用されている 1
つのプライマリ・データ・センターがあり、これは最初は非アクティブになっています。リモート・データ・センターは、
アプリケーションが故障またはスイッチオーバーした後で使用されます。MAA では、2 つのサイトは対称型になってい
るため、アプリケーションが故障またはスイッチオーバーした後でもスイッチ・バックの必要はありません。コストを削
減するために、多くの顧客は非対称型の環境を構築し、プライマリ・サイトと比べると、セカンダリ・サイトにはハード
ウェアおよびネットワーク・リソースのサブセットのみが含まれるように設定しています。ただし、特に複数の障害が発
生した場合は、パフォーマンスのサービス・レベルを保持すること、およびフェイルオーバーとスイッチオーバーに対す
る手順を処理することは困難です。
より効果的な構成としては、アクティブ/アクティブ構成があります。この構成の 2 つのデータ・センターは、アクティ
ブおよび非アクティブのアプリケーションの組合せをサポートしています。ただし、1 つのサイト内の各データベースは、
本番ロールまたはスタンバイ・ロールのいずれかを保有しています。このため、あるアプリケーションに対しては、デー
タ・センターのいずれかに存在する 1 つの本番データベース、および対応するデータ・センター内のスタンバイ・データ
ベースが存在します。したがって、それぞれのデータベースについては、このドキュメントを通じて説明している可用性
と同じレベルのものが提供されます。各データベースは本番用のクラスタに定義できます。また、対応するスタンバイ・
データベースも他のクラスタにも定義できます。使用率を上げるために、様々なアプリケーションに対する複数の本番デ
ータベースおよび複数のスタンバイ・データベースで、（容量が十分な場合は）同じハードウェア・リソースを共有でき
ます。
次の図は、（リソースが十分で全体の負荷を処理できると仮定した場合に）、クラスタが複数の本番およびスタンバイ・
データベース・アプリケーションをどのように共有しているかを示しています。データ・センターには、いくつかのデー
タベース・アプリケーションがあり、この中には同じクラスタ内に存在するものも、独自の（専用の）クラスタ内に存在
するものもあります。図 6-1 と図 6-2 では、別々のクラスタ内に 4 つの RAC データベース（CRM、ERP、Mail、HR）が
存在します。図 6-1 は、各データ・センター内の 1 つのクラスタを表していて、それぞれのクラスタには、クラスタの本
番データベース、およびリモート・クラスタの対応するスタンバイが定義されています。図 6-2 は、各サイトにおけるク
ラスタのペアを表しています。このサイトでは、アプリケーション・サーバーの共通セットを共有しています。ここで、
データベースに対するクラスタは 1 つのサイトでアクティブですが、他方のサイトでは対応するスタンバイ・クラスタは
非アクティブです。ここでは、Data Guard がフェイルオーバーまたはスイッチオーバーした場合に、調整および計画を行
う別のデータベース・アプリケーションがないことが利点です。
図 6-1 では、CRM 本番データベースのクラスタも、サイト A の ERP に対してスタンバイ RAC データベースをサポート
しています。サイト B には、同様に構成された同じサイズのクラスタがあり、ERP 本番データベースを実行し、CRM ス
タンバイ・データベースを保有しています。このシナリオでは、各クラスタで使用できるリソースと容量を十分に用意し
て、シングル・クラスタの本番モードで 2 つのデータベースを実行し、理想的にはパフォーマンスの低下が最少（または
ゼロ）にする必要があります。たとえば、サイト A が停止した場合は、本番の CRM データベースが Data Guard を使用し
てサイト B のスタンバイ CRM データベースにフェイルオーバーします。ここでは、CRM と ERP の両方がシングル・ク
ラスタの本番のロードで実行されます。リソースが適切に計画されているかぎり、これによって問題が発生したりパフォ
ーマンスの低下はありません。
Maximum Availability Architecture
6-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Data Centerの
のMAA
図6-1: 各データ・センターに1つのアプ
各データ・センターに つのアプリケーション・サーバーを持つ
つのアプリケーション・サーバーを持つ1つのクラスタ
リケーション・サーバーを持つ つのクラスタ
図 6-2 では、同じ中間層セット（アプリケーション、Web サーバー、IMAP、LDAP など）のアプリケーション・サーバ
ーを共有する、2 つの別々のクラスタが定義されています。次の例では、本番の RAC Mail データベースはサイト A の自
身のクラスタに定義されており、サイト B に、RAC Mail のスタンバイ・データベース用として対応するクラスタを持っ
ています。また、サイト B には、本番の RAC HR データベースを実行するもう 1 つのクラスタがあります。さらにサイ
ト A には、RAC HR のスタンバイ・データベース用として、対応する 1 つのクラスタがあります。各サイトでは、中間
層のアプリケーション・サーバーが Mail および HR のアプリケーションで共有されます。したがって、1 つのデータベー
ス・アプリケーションに対してフェイルオーバーが行われた場合、中間層のアプリケーション・サーバーには、同じサイ
トの 2 つの本番アプリケーションのロードを処理する十分なリソース容量が必要で、さらに理想的には、パフォーマンス
の低下を最少（またはゼロ）にする必要があります。
図6-2: アプリケーション・サーバーを共有する別々のデータ・センター内の2つのクラスタ
アプリケーション・サーバーを共有する別々のデータ・センター内の つのクラスタ
Maximum Availability Architecture
6-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Data Centerの
のMAA
注意: これらの図は、すべてのハードウェア・コンポーネントの完全な冗長性を示しているわけではありません。MAA
構成で期待されるネットワークまたはハードウェアの冗長性の詳細は、「クライアント層 − サイト・フェイルオーバー」
を参照してください。
データ・センターには、サポートしているそれぞれのデータベース・アプリケーションのサービス・レベル要件によって
異なる組合せが定義されています。MAA の構成は、高可用性を必要とするサービスをサポートしているすべてのアプリ
ケーションに対して配置する必要があります。シングル・クラスタにおける複数データベースの所有、または中間層サー
バーの共有は完全にサポートされており、可能なかぎり利用できますが、追加のリソースおよび容量の計画が必要になり
ます。アクティブ/アクティブなデータ・センター環境の主なメリットは、すべてのリソースが利用できる点です。
Maximum Availability Architecture
6-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
第 3 部: 可用性の高い環境を監視および管理する
可用性の高い環境を監視および管理する
第 3 部では、可用性の高い環境におけるシステムの可用性とパフォーマンスの監視について詳しい情報を提供します。こ
れは、このドキュメントのすべての指針に対して必ずしも適用されるものではありません。また、ここでは、Enterprise
Manager の使用に関する提案、およびイベントが発生した場合の対応についても説明します。
次の項で構成されています。
•
第 7 項「Enterprise Manager での監視と管理」
Maximum Availability Architecture
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
7.
システム、ネットワーク、データベース処理、アプリケーション、およびシステムの他のコンポーネントを継続的に監視
すると、問題が早期に検出され、結果的には問題の回避や迅速な解決につながります。また監視では、システム・メトリ
ックを取得して、システムの成長率および再発性のある問題の両方の傾向の提示、問題の予防、セキュリティ・ポリシー
の施行、ジョブ処理の管理なども行います。さらにデータベース・サーバーについては、可用性の測定、データベース・
サーバーを停止させる原因にもなるイベントも検出、および重要な障害を関係者にすぐに通知するため必要な安定したシ
ステム監視が必要です。
システムの監視機能も高可用性を持つこと、および監視対象のリソースと同じ運用のベスト・プラクティスおよび可用性
のプラクティスに準拠していることが必要です。システム監視で障害が発生すると、監視されているすべてのシステムが
公開されたままの状態になります。Oracle Enterprise Manager（OEM）は、電子メールやポケベル通知のオプションを使
用した、イベント管理および監視の機能を提供します。
この項では、Oracle Enterprise Manager R9.2 を使用して既存の MAA 環境を管理する推奨事項について説明します。
これらの推奨事項は、環境を監視する方法だけでなく、環境の変化に対応する場合にも適用されます。また、RAC、Data
Guard テクノロジ、およびその他構成上のヒントの組合せを使用して、可用性の高い Oracle Enterprise Manager 構成を作成
する方法も説明します。これらの推奨事項は、次の項で説明しています。
•
監視
•
管理
•
可用性の高い Enterprise Manager アーキテクチャ
•
EM 構成
7.1
監視
•
EM イベントを設定して、サービスの割込みを検出可能にする
•
EM イベントを使用してシステムの可用性を監視する（データ・ガード・イベント）
•
EM イベントおよび EM パフォーマンス・パックを使用してデータベース全体の健全性を確認し、パフォーマ
ンスの問題点を分離させる
Oracle Enterprise Manager の使用に関する多くの推奨事項では、「Event」と呼ばれる製品の機能を使用します。Event は、
対象の条件が満たされた状況になったかどうかを監視し、そのような状況にはなんらかの処置を実行します。Event を設
定して、オペレーティング・システム、アプリケーション・サーバー、リスナー、データベースなどを含むアプリケーシ
ョン・スタックの様々な層を監視できます。イベントの定義に必要なポイントは次のとおりです。
•
どのオブジェクトを監視するか（データベース、ノード、リスナー、または他のサービス）
•
どの計測をサンプリングするか（可用性、CPU ビジーの割合）
•
イベントはど程度の頻度でサンプリングするか
•
イベントが定義済のしきい値を超えた場合にはどのように対応するか
Maximum Availability Architecture
7-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
すべてのイベントに対して、2 つのしきい値「警告」レベルと「重大」レベルを設定できます。Enterprise Manager GUI
においてイベントの定義で使用される完全な処理については、『Oracle Enterprise Manager 管理者ガイド』の第 6 章で説
明しています。製品で提供される Event の完全なリストは、『Oracle Enterprise Manager イベント・テスト・リファレン
ス』に記載されており、ここでは Oracle Enterprise Manager で使用できる定義済の多くの計測ポイント、および SQL また
はシェル・スクリプトを使用して追加できるイベントの新しい監視条件について記載されています。項 7.1.1 には、重要
なシステムに対して設定する、最低限のイベント・セットが含まれています。項 7.1.2 では、Data Guard インスタンスを
監視するために設定するイベントについて詳しく説明します。項 7.1.3 では、パフォーマンスの監視を設定する必要があ
るイベントについて詳しく説明します。
イベント画面には、Oracle Enterprise Manager の左側にあるメインのナビゲーション・ツリーでアクセスできます。この
画面には有効なアラートとそのステータス（警告または重大）が表示されます。登録されているタブには、現在監視され
ているアクティブなイベントがすべて一覧で表示されます。次の例では、Disk Monitoring イベントが重大レベルのしきい
値に達し、Crisis Alerts というイベントが警告レベルのしきい値に達しています。Oracle Enterprise Manager は、イベント
がしきい値を超えた場合に、そのイベントに対しても機能します。たとえば、特定のしきい値に達した場合にポケットベ
ルや電子メールをトリガーするようイベントを設定できます。また、イベントを「Fixit」ジョブに関連付けることが可能
です。Fixit ジョブの概念は、「EM の Fixit ジョブを使用してイベント・アラートに応答する」で説明します。
Maximum Availability Architecture
7-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
7.1.1
EMイベントを設定して、サービスの割込みを検出可
イベントを設定して、サービスの割込みを検出可能にする
イベントを設定して、サービスの割込みを検出可能にする
これらのイベントは、サービスの可用性、Oracle やアプリケーションのエラーに影響を与える可能性がある、早急な注意
を必要とする問題を監視します。サービスの可用性は、（ノード、データベース、リスナー、重要なアプリケーション・
データなど）任意のアプリケーション・スタックのレイヤーにおける停止によって影響を受けることがあります。データ
ベースに接続できない、アプリケーションの機能にとって重要なデータにアクセスできないなどのサービス可用性の障害
は、早急に特定し、レポートを作成して対処する必要があります。アーカイブ・ログのディレクトリをファイリングする
場合などの潜在的なサービスの停止も適切に対処して、システムが停止しないことが必要です。
前述の手順を使用して可用性を監視する必要があるターゲット・アーキテクチャのそれぞれのコンポーネントに対して、
1 つのイベントを作成します。監視される各ターゲットについて、必要に応じて次の 12 個のイベントを設定します。監
視の頻度は、各コンポーネントの品質保証契約（SLA）によって決定します。
監視されるすべてのターゲットに対して、UpDown イベントを設定します。これらのイベントは、停止しているかを示す
メインのイベントです。現在サポートされているコンポーネントは次のとおりです。
•
データベース
•
ハードウェア・ノード
•
リスナー
•
アプリケーション・サーバー
•
HTTP Server
•
Web Cache
サービス停止の原因となる可能性がある重要な領域管理の条件は、次のイベントを使用して監視します。
•
Disk Full イベントを設定して、重要なすべてのハードウェア・サーバーに対してルート・ファイル・システムを
監視します。このイベントを使用して、管理者は、EM がテストで使用するしきい値のパーセンテージおよびサ
ンプル数を取得します。これがエラーで特定の数値を超えると、管理者にメッセージが発行されます。デフォル
トの推奨値は、警告については 70%、エラーについては 90%ですが、これらの値はシステムの使用度によって調
整する必要があります。この推奨値は、次に示す Swap Full、Archive Full、および Dump Full のイベントにも適用
されます。
•
Swap Full イベントを設定して、重要なハードウェア・サーバーのすべてに対してスワップ領域の使用を監視し
ます。
•
Archiver Hung イベントを設定し、完全なアーカイブ・ログ・ディレクトリを表す ORA-00257 のメッセージにつ
いて、アラート・ログを監視します。
•
アーカイブ・ログ領域の追加確認として、Archive Full (%)イベント、および環境にあったしきい値とサンプリン
グのイベント時間を設定します。このイベントは、管理者に対して、完全なアーカイブ・ディレクトリ（アーカ
イブ・ディレクトリが一杯であることによる）潜在的なシステムの停止を発行できます。
•
Dump Full (%)を設定して、ダンプのディレクトリ宛先を監視します。発生するすべての情報に対する診断情報の
最大量を最初に取得できる、ダンプ領域を有効にしておくことが重要です。
領域管理などの潜在的な問題を監視する必要があります。これらのイベントは、システムで予想される増加量に基づいて
設定します。本番システムは比較的安定しているため、データ・ファイルの量は急激には増加しない傾向にありますが、
これらのイベントを設定すると、予想外に増加した場合に管理者に警告を発行できます。
•
Maximum extents イベントを設定して、重要なリソースが一杯に近くなった場合に警告を発行します。セグメン
トでエクステントの最大量に達すると、行が挿入できなくなり、ORA-1631 のエラー・メッセージが発行されま
す。このイベントのデフォルトでは、任意のデータベース・ターゲットのすべての表領域を監視しますが、これ
Maximum Availability Architecture
7-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
はイベントの Parameters タブで修正できます。警告および重大レベルのしきい値は、環境に応じてデフォルトの
1 および 2 から、それぞれ修正できます。
•
Datafile limit を設定して、データ・ファイル・リソースの使用率を確認します。DB_FILES 初期化パラメータの
制限セットに対して使用されているデータ・ファイルのパーセンテージが、しきい値引数に指定されている値を
超えた場合は、80%の使用で警告が生成され、90%の使用で重要なアラートが発行されます。
アラート・ログでエラーを監視します。
•
Enterprise Manager にはアラート・イベントが用意されています。これは、ORA-6XX、ORA-1578（データベース
の破損）、および ORA_0060（デッドロックの検出）イベントが記録された場合に、アラートを発行します。そ
の他のアラートが記録された場合には、警告のメッセージが生成されます。
•
Data Block Corruption イベントを設定して、（Oracle データ・ファイルの破損を表す）ORA-01157、ORA-27048
のエントリに対してアラート・ログを監視します。
システムを監視して、処理容量を超えていないことを保証します。この警告、およびこれらのイベントに対する重要なパ
ラメータは、システムの使用パターンに基づいて修正する必要があります。
•
現行の処理数が PROCESSES データベース・パラメータで設定した値に達した場合は、Process limit を使用して
警告を発行します。
•
Session limit イベントを設定して、インスタンスが、データベースで許容できる最大同時接続数に近いことを警
告します。
EMイベントを使用して
イベントを使用してData
Guardシステムの可用性を監視する
システムの可用性を監視する
イベントを使用して
7.1.2
Oracle9i の Data Guard マネージャは、このリリースでは RAC ターゲットを監視しませんが、イベントを設定して任意の
シングル・インスタンスの Data Guard 構成の可用性を監視できます。Data Guard Manager の拡張によって Data Guard 環境
が登録されている場合は、次のイベントを設定します。
•
Data Guard Status イベントを設定して、停止したシステムの問題を管理者にアラートを発行します。これは、7.1.1
の項で説明した Data Guard に対する NodeUpDown テストと同様です。
•
Data Guard Data Not Applied イベントを設定して、最新のアーカイブ・ログで分単位の差異が計測された場合、お
よびスタンバイで適用されている最新のログが、ユーザー定義のしきい値を超えた場合に、管理者に対してアラ
ートを発行します。このイベントを使用すると、スタンバイ・インスタンスに対するリカバリ時間が、停止から
のリカバリで定義されているサービス・レベルを超えた場合に、管理者に対して警告を発行できます。このイベ
ントは、スタンバイ・データベースで定義されているログ適用を考慮して、設定する必要があります。
Data Guard Logs Not Shipped イベントを設定して、プライマリからスタンバイ・サイトへアーカイブ・ログを移動する際
に過度の遅延が発生した場合、管理者に対してアラートを発行します。このイベントでは、プライマリのアーカイブ・ロ
グにおける差異が、スタンバイ・サイトに提供されるアーカイブ・ログの数を超えた場合にフラグが設定されます。これ
はユーザー定義のしきい値で、ネットワーク上でアーカイブ・ログの移送にかかる時間に基づいて設定します。イベント
のサンプル時間が、ログの移送時間と同様になるよう設定し、また出現数が 2 回以上になるように設定して、このアラー
トに対する不適切な反応を排除します。警告および重大レベルのしきい値に対して推奨される開始の値は、それぞれ 1
と 2 です。
Maximum Availability Architecture
7-4
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
7.1.3
EMイベントおよび
イベントおよびEMパフォーマンス・パックを使用してデータベース全体の健
パフォーマンス・パックを使用してデータベース全体の健
イベントおよび
全性を確認し、パフォーマンスの問題点を分離させる
前述のように、十分なパフォーマンスが実現されていないシステムは、個々のコンポーネントのステータスに関係なく、
可用性の高いシステムとは言えません。『Oracle Enterprise Manager イベント・テスト・リファレンス』に記載されてい
る多くのイベントは、パフォーマンスに関連するものです。パフォーマンスの問題によって、大規模なシステムの停止や
ブラックアウト（処理不能）が発生することはありませんが、顧客によってはパフォーマンスの問題が停止の原因になる
場合もあります。このような停止は通常、アプリケーション・サービスの低下とみなされます。このような低下は、1 つ
または複数のインフラストラクチャ・コンポーネント（クライアント、ネットワーク、データベース、アプリケーション
のいずれか）において連続した、または部分的な障害が発生したことが主な原因です。アプリケーションで低下が発生す
るタイミングおよびその理由を理解するために、IT マネージャは様々なインフラストラクチャ・コンポーネントがどの
ように実行されているか（具体的には応答時間、待機時間、可用性など）を認識し、エンド・ユーザーに提示されるアプ
リケーション・サービスの品質にどのような影響を与えているか認識が必要です。パフォーマンスのチューニング、およ
びパフォーマンスのイベント・アラートの構成要素を決定する基盤は、エンド・トゥ・エンドのパフォーマンス基準です。
理想的には、収集される基準データには、次のものが含まれるようにします。
•
アプリケーションの統計（トランザクションのボリューム、応答時間、Web サービス時間）
•
データベースの統計（トランザクション・レート、REDO レート、ヒット率、上位 5 つの待機イベント、
上位 5 つの SQL）
•
OS の統計（CPU、メモリー、I/O、ネットワーク）
基準とは、SLA を満たす通常の処理に対するパフォーマンス・メトリックが何であるかを示すものです。したがって、
この基準から許容範囲を超えて逸脱しているものに対してパフォーマンスの警告またはアラート・イベントを設定するこ
とがベースとなります。また、パフォーマンスの履歴データは、傾向をつかんだり、容量計画における使用を特定したり
するうえで重要です。これは、アプリケーションが本番環境にロールアウトされた初日から、オペレーティング・システ
ム、データベース、およびアプリケーションの統計を収集する必要があることを意味します。パフォーマンス監視のプラ
クティスおよびメトリックに関する詳細は、この設計の範囲を超えていますが、サービスおよび可用性の監視する重要な
事前コンポーネントです。
ただし、すべてのシステムは、Enterprise Manager Events を使用して監視できる、基本的な特性を共有します。これらの
各イベントに対するしきい値およびサンプリング・レートの設定は、システムによって異なります。推奨されるアプロー
チでは、次の推奨値を監視して傾向を認識し、負荷をかけた場合に安定したシステム・パフォーマンスが得られる場合の
値を取得します。これは、Enterprise Manager Capacity Planner を使用して行えます。このようにサンプリングされた値を
イベントを設定ためのベースとして使用し、これらの値がユーザー定義の制限を超えた場合に、システム管理者にアラー
トを発行できます。
Oracle Enterprise Manager を使用して、次のデータベース・イベントを監視し、システム・パフォーマンスの状態を表し
ます。
これらのテストを補足するために、多数のオペレーティング・システムのイベントを使用できますが、使用できるイベン
トはプラットフォームによって異なります。
•
Disk I/O per Second を設定します。これはデータベース・レベルのイベントで、データベースによって行われる
I/O 処理を監視し、アクティビティがユーザー定義のしきい値を超えた場合にアラートを発行します。監視対象
のハードウェアで実行される他の I/O 処理はカウントされませんが、これはデータベースによってレポートされ
るため、重要です。このイベントは、オペレーティング・システム・レベルのイベントと組み合せて使用します。
これらのイベントは Enterprise Manager で使用することも可能で、プラットフォームに依存します。ただし、デ
ータベースがこのハードウェア上で稼働しているプライマリ・アプリケーションの場合は、このイベントを設定
すると、実行された作業量全般の状態を表します。システムで有効な I/O スループット全体に基づいてこのイベ
ントを設定し、有効な I/O チャネル数、SAN 環境で稼働している場合のネットワーク帯域幅、ストレージ・アレ
イ・デバイスを使用している場合の影響、および I/O の最大レートとデータベースで使用できる物理的なスピン
ドルの数を考慮します。
Maximum Availability Architecture
7-5
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
•
監視される各データベースに対して Physical Reads (Writes) per Second イベントを設定します。前述のように、こ
れらのイベントはデータベースで測定されるアクティビティの全般的な量について監視し、アラートを発行しま
す。潜在的な I/O 問題の詳細な警告を得るためには、これらのイベントを設定します。
•
% CPU Busy イベントを設定します。このイベントは、データベースで測定される CPU の使用率を監視します。
使用率が 75%で警告を発行し、85%から 90%でクリティカル・アラートを表示して、ピークの使用が連続してい
ることを管理者に警アラートを発行します。これはピーク時における通常の使用率の値ですが、さらに使用率の
増加が見込まれる場合には、潜在的なリソース不足による異常な処理を表している場合もあります。
•
% Wait Time イベントを設定して、システム・レベルのアイドル時間を監視します。アイドル時間は、ある程度
は CPU などのリソースが共有されている、または I/O 要求が満たされているとみなされます。過度のアイドル時
間は、1 つ以上のリソースに対するボトルネックとして、共有の問題が悪化した可能性があることを示していま
す。アプリケーションが通常の負荷で実行されている場合にシステムの待機時間を測定し、その値を使用してこ
のイベントを設定します。
•
Network bytes per Second イベントを設定して、SQL*Net で測定されるネットワーク全体のトラフィックを監視し
ます。このイベントは前述の I/O イベント類似していて、ハードウェア全体の使用率ではなく、Oracle が生成し
たトラフィックのみをレポートします。ただし、このイベントを使用して潜在的なネットワークのボトルネック
の状態を示すことも可能です。このイベントの最初の警告値は、% Wait Time イベントで説明したピーク時の実
際の使用率をベースにします。
•
Total (hard) Parses per Second を設定して、SQL パフォーマンスの状態を表します。ピーク時の通常の負荷では、
パフォーマンスの状態を取得するための基準として別のイベントを使用しますが、この基準からの偏差によって、
アプリケーションの変更または使用率の変更にリソースが不足したか、またシステムの潜在的なボトルネックが
発生したかが判断されます。
Oracle Enterprise Manager では、これらのイベントの他にも、V$SYSSTAT の統計を監視するイベント、および特別な待機
イベントを用意しています。
アラートが発行されると、Enterprise Manager Performance Pack は詳細なビューを提供します。これによって、システム全
体のパフォーマンス、SQL のパフォーマンス、またはセッション・パフォーマンスとトレースを迅速に参照できます。
Enterprise Manager Database Health Overview Chart は、パフォーマンス設定のいずれかのイベントで発行されるアラートに
対して、システム全体のパフォーマンスの詳細なビューを提供します。それぞれの図は、個別の SQL 使用率やセッショ
ン・リソースの使用率など、それぞれの問題のタイプについてより詳細なメトリックにドリル・ダウンできます。アドバ
イスが提示されるウィザードを使用し、現在のシステム・ステートに基づいたヒントの参照も可能です。この図の詳細は、
『Oracle Enterprise Manager 概要』および『Oracle Enterprise Manager 管理者ガイド』に記載されています。
Maximum Availability Architecture
7-6
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
パフォーマンス監視の詳細は、Oracle Enterprise Manager のマニュアル、『Oracle9i Database パフォーマンス・プランニ
ング』および『Oracle9i Database パフォーマンス・ガイドおよびリファレンス』を参照してください。
Maximum Availability Architecture
7-7
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
管理
7.2
Oracle Enterprise Manager は、非アクティブな問題通知やパフォーマンスの問題分析への対処を行うだけでなく、システ
ム管理の事前対策としても使用されます。次の提案では、発生したイベントに処理し、日常的な管理タスクの処理に
Enterprise Manager Job システムの使用方法を説明します。この機能の使用については、『Oracle Enterprise Manager 管理
者ガイド』の第 5 章に詳しく記載されています。また Data Guard を使用してスタンバイ・データベース環境も管理でき
ます。
•
EM Fixit ジョブを使用してイベントのアラートに応答する
•
EM ジョブのスケジューリングを使用して、ルーチン・イベントを管理する
•
EM Data Guard マネージャを使用して、非 MAA 構成を管理する
7.2.1
EM Fixitジョブを使用してイベントのアラートに応答する
ジョブを使用してイベントのアラートに応答する
Oracle Enterprise Manager のジョブは、複数の処理を 1 つにまとめたもので、集合演算条件付き演算子で順次に組み合せ
ることができます。この製品には、事前定義された多数の処理、および新しい処理とジョブを作成する機能が最初から用
意されています。処理は SQL*Plus スクリプト、シェル・スクリプト、または TCL スクリプトを使用して拡張できます。
保存されているジョブはジョブ・ライブラリに格納されており、定期的に実行するスケジュールと、保存における随時使
用もできます。ジョブの作成で使用する処理の詳しい説明は、『Oracle Enterprise Manager 管理者ガイド』の第 5 章に記
載されています。
ジョブの 1 つのサブカテゴリに Fixit ジョブがあります。Fixit ジョブは他のジョブと同様に作成および保存されますが、
任意の間隔ではスケジュールされず、前述のようになんらかのイベントのトリガーの結果として実行されます。
Fixit ジョブを設定して、問題が発生したときに管理者にアラートも発行できます。Fixit ジョブはイベントに基づいて、
追加のトレース情報を収集するスクリプトを実行したり、失敗したアプリケーション・コンポーネントの再起動を試行す
る処理も実行します。
7.2.2
EMジョブのスケジューリングを使用して、ルーチン・イベントを管理する
ジョブのスケジューリングを使用して、ルーチン・イベントを管理する
ルーチンのデータベース管理タスクの管理には、Oracle Enterprise Manager のジョブ・スケジューリング・システムを使
用します。システムのバックアップ、エクスポート、統計収集、索引の再編成などのタスクは、EM のジョブ・システム
を使用してスケジュールできます。ジョブ・システムを使用すると、すべてのシステム管理者がジョブの共有ライブラリ
にアクセスしてルーチン管理タスクを実行したり、ジョブのスケジューリング・システムにアクセスしてこれらのタスク
の実行を管理したり、また中枢にアクセスして実行ステータスを確認し、問題が発生した場合に管理者に簡単に通知でき
ます。ジョブの作成で使用する処理の詳しい説明は、『Oracle Enterprise Manager 管理者ガイド』の第 5 章に記載されて
います。
7.2.3
EM Data Guardマネージャを使用して、非
マネージャを使用して、非MAA構成を管理する
構成を管理する
マネージャを使用して、非
前述のように、Data Guard Manager を使用して、シングル・インスタンスの Data Guard 環境を監視できます。
これらの環境は、ロジカルまたはフィジカル・スタンバイ・インスタンスのいずれが可能です。Data Guard Manager を使
用して、Enterprise Manager に認識されている既存のリソースから新しいスタンバイも作成できます。いったんインスタ
ンス化されると、GUI を使用して環境を監視したり、スイッチオーバーやフェイルオーバーの操作を実行できます。
Maximum Availability Architecture
7-8
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
7.3
可用性の高いEnterprise
Managerアーキテクチャ
アーキテクチャ
可用性の高い
EM アーキテクチャは、3 層のフレームワークで構成されています。（情報のプレゼンテーションを行うクライアント層
が、サーバーのデータにアクセスするような）2 層のクライアント/サーバー構造とは異なり、EM では 3 層のアーキテク
チャを使用します。このアーキテクチャには次のものが含まれています。
•
コンソール － コンソール・クライアントおよび統合ツールによって、管理者にグラフィカルなインタフェース
を提供します。
これは、EM のフロントエンド GUI インタフェースです。管理者は、特定のハードウェアの OMS 処理に直接接
続することによって、Oracle Enterprise Manager コンソールを使用します。
•
OMS /リポジトリ
リポジトリ － 管理サーバーおよびデータベース・リポジトリによって、システム管理タスクを行うため
の拡張性のある中間層を提供します。
管理サーバー・プロセスは、コンソールからエージェントへ、およびエージェントからリポジトリとコンソール
への作業のブローカとして機能します。管理サーバーは、システム・データ、アプリケーション・データ、管理
ノードのステート情報、およびシステム管理パックの情報をすべて格納するために 1 つのリポジトリを使用しま
す。このリポジトリはデータベース表のセットで、Oracle Management Server（OMS）にアクセス可能な、サポー
トされている Oracle データベースに定義する必要があります。
•
エージェント － 各ノードにインストールされている Intelligent Agent はノード・サービスを監視し、Management
Server からタスクを実行します。
エージェントは繰返し作業を起動する際に有用です。ユーザーによってコンソールを介して（OMS を介して）
プログラムされたエージェントは、スケジュールされた間隔で起動され、統計および起動ジョブの確認と記録を
行います。スケジュールされた作業の起動側として、エージェントは OMS にコールを行います。エージェント
は、（プライマリおよびスタンバイの EM リポジトリおよび OMS 処理が定義されているノードも含めて）アー
キテクチャで監視されているすべてのノード上で実行する必要があります。
EM アーキテクチャは、アプリケーション・アーキテクチャと同様の信頼性が必要です。これは、できるだけ効率よく修
復を管理、検出および開始するフレームワーク監視にとっては重要です。オラクル社では、MAA EM アーキテクチャの
構成および設定について、次のことを推奨しています。
•
MAA アーキテクチャを使用して EM の可用性を保証する
•
Enterprise Manager に対する計画外停止
7.3.1
MAAアーキテクチャを使用して
アーキテクチャを使用してEMの可用性を保証す
の可用性を保証する
アーキテクチャを使用して
の可用性を保証する
EM リポジトリおよび処理に対する最小限の推奨事項は、Enterprise Manager で監視される最高レベルの可用性を備えたシ
ステムと同じレベルの保護を実現している構成内で、リポジトリと処理のホストです。RAC/Data Guard 構成を使用して
いるシステム上での監視およびアラートを目的に EM システムを使用していて、EM リポジトリがシングル・インスタン
ス上でのみホストされている場合は、EM システムの停止が発生すると、本番システムの問題がタイムリーに管理者に通
知されないことがあります。ただし、オラクル社は、プライマリおよびスタンバイの両方のサイトで物理的な Data Guard
インスタンスおよび RAC を使用している完全な MAA 構成で EM リポジトリのホストを推奨しています。
この基本的な推奨事項では、本番およびスタンバイ・ハードウェアの各ノード、および各ノードのエージェント処理で 1
つの OMS 処理も要求しています。これによって、EM アーキテクチャの重要なほとんどのコンポーネントで発生する単
一の障害に対して、EM を使用して監視されているすべてのシステムのサービスをほとんど中断させずに、即時的にカバ
ーできます。次の図は、推奨されるこのアーキテクチャを示しています。項 7.3.2 では、Oracle Enterprise Manager の各コ
ンポーネントに対する障害について説明しています。
Maximum Availability Architecture
7-9
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
環境内で監視されているすべてのノードのエージェントは、稼働しているすべての OMS 処理に接続します。OMS 処理
に接続しているエージェント処理のロード・バランシングは、Oracle Enterprise Manager によって内部で処理されます。
OMS 処理は、RAC ノード、または SQL*Net のフェイルオーバーを使用したフェイルオーバー上で実行中のリポジトリ/
インスタンスに接続します。これについては、7.4.2 の項で説明しています。
このアーキテクチャを成功させるためのポイントは、OMS 処理とエージェント間の通信をサポートするためのネットワ
ーク帯域幅の量です。このリポジトリを使用してより大きな企業を管理する場合は、スケジュールされるイベントおよび
ジョブの数によっては、OMS に対するエージェントのトラフィックが膨大な量になることがあります。EM フレームワ
ークを利用して複数のアプリケーションを監視する場合は、さらに専用のシステム・リソースが必要になり、EM リポジ
トリと管理処理にノードを追加し拡張を検討します。
リポジトリおよび OMS 処理は、
必要に応じて個別に拡張できます。
必要な場合は、クラスタ外部のハードウェアを追加して、OMS 処理の数を増やすことができます。
図7-1: EM MAAのアーキテクチャ
のアーキテクチャ
すべてのシステム・アーキテクチャで、完全な MAA 構成における可用性が必要なわけではありません。このような環境
については、このドキュメントの付録 A「主なアーキテクチャ変更におけるリスク評価」で、アーキテクチャ間のいくつ
かの違いについて説明し、EM リポジトリを使用した場合のコスト上の影響について、基本的な事項を説明しています。
またハードウェアのオーバーロードを減らし、現行のリソースを利用するために、EM リポジトリと管理サーバー・プロ
セスを、同じハードウェア上の別の MAA 構成アプリケーションにホストできます。ここでは、セカンダリ・サイト上の
アクティブな EM インスタンスと管理サーバー・プロセスを使用します。これは、セカンダリ・サイトが、本番のロード、
およびアクティブな Enterprise Manager Repository と OMS 処理を処理するだけの容量と帯域幅を備えていることを前提と
しています。
Maximum Availability Architecture
7-10
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
7.3.2
Enterprise Managerに対する計画外停止
に対する計画外停止
Oracle Enterprise Manager は、データ・センターを管理する主要な制御インタフェースとなります。停止が発生すると、
DBA がシステム全体のパフォーマンスの管理するに必要な、パフォーマンスの確認ができなくなり、可用性のメトリッ
クがなくなります。次の表は、EM 内の任意の層で発生する可能性のある停止、およびそのそれぞれのリカバリ方法につ
いて説明しています。
表7-1: EMの計画外停止
の計画外停止
停止の範囲
停止の理由
リカバリ手順（処理で解決される問題）
リポジトリ・ノード ハードウェア障害、Oracle RAC により自動的に管理される
またはインスタン データベースのクラッシ
RAC 環境では、Oracle Net フェイルオーバーを使用して、2 番目のノ
スの障害
ュ、プライマリの RAC イ ードに対して再接続を行います。障害が発生したノードがリストアさ
ンスタンスのシングル・ノ れると、Oracle Net のロード・バランシングと管理サーバー・プロセ
ードに対するネットワー
スのロード・バランシングを使用した場合に、この組合せによって自
ク障害、リスナー障害
動的に負荷が再調整されます。
プライマリ・サイト （2 つのノードに対する） セカンダリ・サイトにフェイルオーバーするために、Data Guard が必
の障害
ネットワーク障害、クラス 要
タ障害、インターコネクト - プライマリ・サイト・ノード上の EM トラフィックに対して構成
障害、ハードウェア障害
されたリスナーを停止する
エージェントの
障害
-
EM リポジトリに対する DG のフェイルオーバー
-
新しい本番サイトで EM リスナーおよび管理サーバー・プロセス
を開始する
処理クラッシュ、ユーザー エージェントのウォッチドッグ・プロセス（DBSNMPWD）によって
による不用意な強制終了
エージェントを再起動します。再起動の量は、ユーザーが設定可能な
パラメータによって調整し、監視対象のノードがスラッシングしない
ようにします。
エージェント開始の失敗数が設定されている回数を超えた場合は、手
動で再起動する必要があります（agentctl start）。
ウォッチドッグ・
クラッシュ
処理クラッシュ、ユーザー データはレポートされず、エージェントに対してロギングが停止しま
による不用意な強制終了
す。停止中の処理は、（UNIX の場合は）手動で削除してエージェン
トを再起動する必要があります。
ウォッチドッグの停止は EM GUI には通知されません。
システム・ステー エージェント・クラッシ
ト・データが削除さ ュ、ユーザーによるステー
れた、または破損し ト・ファイルの削除
た
管理サーバー・
プロセスのクラッ
シュ
まだ実行されているエージェント処理（DBSNMP および
DBSNMPWD）を停止します。
$ORACLE_HOME/network/agent ディレクトリの*.q、および services.ora
ファイルをすべて削除します。
-
エージェントを再起動します（agentctl start）
-
OEM コンソールから、そのノードに対してスケジュール・イベン
トまたはジョブを再起動します。
処理クラッシュ、ユーザー ウォッチドッグ・プロセスによって管理サーバーを再起動します。
による不用意な強制終了
- これに対するフラグは、$ORACLE_HOME/OMSconfig.properities
ファイルに設定されています。
管理サーバー開始の失敗数が設定されている回数を超えた場合は、手
動で再起動する必要があります（oemctl start management server
user/password）
管理サーバーが再起動に失敗した場合は、残りの（有効な）サーバー
が処理を引き継ぎます。処理を行うことが可能な管理サーバーの処理
がない場合は、すべての EM プロセッシングが消滅します。
管理サーバーの障害によって、接続されている GUI セッションも失敗
し、残りの管理サーバーを再起動することが必要になります。
Maximum Availability Architecture
7-11
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
停止の範囲
停止の理由
リカバリ手順（処理で解決される問題）
ウォッチドッグ
障害
処理クラッシュ、ユーザー データはレポートされず、管理サーバー・プロセスに対してロギング
による不用意な強制終了
が停止します。停止中の処理は、（UNIX の場合は）手動で削除して
エージェントを再起動する必要があります。
コンソールの切断
ネットワークの問題、
管理サーバーの障害、
ノードの障害などによっ
て、コンソールが管理サー
バーへの接続を失った
ウォッチドッグの停止は EM GUI には通知されません。
Maximum Availability Architecture
コンソールはステートレスになっているため、管理サーバー・プロセ
スからすべてのデータを取得します。この障害を解決するには、残り
の有効な管理サーバーへ再接続し、コンソールをスタンドアロンで開
始します。
GUI 処理をうまく再起動できない場合は時間がかかります。これを解
決するには、EM コンソールを完全に停止（および Windows で実行し
ている場合はノードを再起動）して再起動します。
7-12
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
7.4
EM構成
構成
次の項には、Oracle Enterprise Manager を作成に役に立つ、その他の構成情報が含まれています。
•
EM トラフィック用に別のリスナーを設定する
•
Oracle Net 接続のロード・バランシングおよび接続のフェイルオーバーを設定する
•
既存のデータベースに Enterprise Manager Repository をインストールする
7.4.1
EMトラフィック用に別のリスナーを設定する
トラフィック用に別のリスナーを設定する
Oracle Agents のトラフィックは、管理処理へルーティング後、Oracle Net を介して EM リポジトリにルーティングされま
す。このトラフィックを、他のアプリケーションのトラフィックと分離させてサイトのフェイルオーバーに必要な Data
Guard をサポートするには、別のリスナーを介した EM トラフィックの設定が必要です。リスナーは、アクティブな EM
インスタンスが実行されているノードでのみ有効になります。TAF および接続時フェイルオーバーが無効になるため、
listener.ora に GLOBAL_DBNAME パラメータは設定しないでください。動的なサービス登録およびクロス登録を可能にす
る、local_listener、remote_listener init.ora パラメータを設定してください。次に、リスナー設定の例を示します。
LISTENER_N1=
(description_list=
(description=
(address_list=
(address=(protocol=tcp)(port=1521)(host=EMPRIM1.us.acme.com))
)
)
)
SID_LIST_LISTENER_N1 =
(SID_LIST =
(SID_DESC =
(ORACLE_HOME = /mnt/app/oracle/product/9.2)
(SID_NAME = EM1)
)
)
LISTENER_DG=
(description_list=
(description=
(address_list=
(address=(protocol=tcp)(port=1529)(host=EMPRIM1.us.acme.com))
)
)
)
7.4.2
Oracle Net接続のロード・バランシングおよび接続のフェイルオーバーを
接続のロード・バランシングおよび接続のフェイルオーバーを
設定する
OMS がロード・バランシングおよびフェイルオーバーで使用する Oracle Net の接続記述子または TNS エイリアスを設定
します。次の例は、最初に接続がどのようにして第 1 の RAC データベースへルーティングされ、2 つの間で均衡される
かを示しています。1 つのサイトが停止すると、トラフィックは他方のサイトへルーティングされ、これらのノード間で
均衡されます。
Maximum Availability Architecture
7-13
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Enterprise Managerでの監視と管理
での監視と管理
EM=
(description=
(failover=on)
(address_list=
(load_balance=on)
(failover=on)
(address=(protocol=tcp)(port=1522)(host=EMPRIM1.us.acme.com))
(address=(protocol=tcp)(port=1522)(host=EMPRIM2.us.acme.com)))
(address_list=
(load_balance=on)
(failover=on)
(address=(protocol=tcp)(port=1522)(host=EMSEC1.us.acme.com))
(address=(protocol=tcp)(port=1522)(host=EMSEC2.us.acme.com)))
(connect_data=(service_name=EMrep.us.acme.com)))
これは、ホスト名、リスナー名、およびネットのエイリアスが異なることを除けば、データベースに対する Oracle Net
構成の設定と同様です。「付録 C」を参照してください。
7.4.3
既存のデータベースにEnterprise
Manager Repositoryを
をインストールする
既存のデータベースに
インストールする
RAC ベースのリポジトリの作成にインストールの問題を回避するため、既存のデータベースに Oracle Enterprise Manager
をインストールし、表領域を事前に作成しておく方が簡単です。インストーラのバージョンによっては、RAC データベ
ースへリポジトリをインストールできないものもあります。最初にデータベースを作成し、次に Install オプションを使用
して既存のデータベースへインストールします。
Maximum Availability Architecture
7-14
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
第 4 部: 停止、停止からのリカバリ、
フォルト・トレランスのリストア
第 4 部では、MAA 環境で発生する可能性のある停止、これらの停止を解決するソリューション、および完全な保護を実
現するフォルト・トレランスをリストアする手順について詳しく説明します。
次の項で構成されています。
•
第 8 項「停止」
•
第 9 項「停止からのリカバリ」
•
第 10 項「データベースのフォルト・トレランスをリストアする」
Maximum Availability Architecture
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止
8.
連続可用性は、今日、多くのアプリケーションの基本的要件です。ビジネスは連続運用の時代になり、実際、多くの事業
は、アプリケーションの 24 時間 365 日の可用性を前提として存在します。停止は、意図したものかどうかにかかわらず、
収益とサービスの質において大きなオポチュニティ・コストを伴います。MAA は、それぞれの停止を管理し、停止に関
連する停止時間を最少にするリカバリ処理とアーキテクチャ上のフレームワークを提供します。
この項では、MAA で扱うすべての停止について説明します。停止は、次の 2 つに分類できます。
•
計画外停止
•
計画停止
8.1
計画外停止
計画外停止とは、アプリケーションをサポートするテクノロジー・インフラストラクチャのいずれかの部分における不測
の障害です。このインフラストラクチャには、ホスト・マシン、ストレージ、スイッチ、ケーブル、カードのようなハー
ドウェア、ソフトウェア（オペレーティング・システム、Oracle データベースとアプリケーション・サーバー、アプリケ
ーション、コード）、ネットワーク・インフラストラクチャ、ネーミング・サービス・インフラストラクチャ、フロント
エンド・ロード・バランサ、現在の本番サイトが含まれます。監視と HA のためのインフラストラクチャは、そのような
障害を迅速に検出し、リカバリを提供する必要があります。この章では、それぞれの停止からのリカバリ処理を中心に説
明しますが、停止の検出については、付録「運用上のベスト・プラクティス」で説明しています。
次の表は、プライマリまたはセカンダリ・サイトのコンポーネントに影響を及ぼす計画外停止について説明します。
表8-1: 計画外停止
停止
説明
サイト全体
現在の本番システムが定義されて •
いるサイト全体が使用できなくな •
ります。アプリケーションのすべ
ての層が含まれます。
火事、洪水、地震などによる本番サイトの障害。
アプリケーション層のノードが使 •
用できなくなるノード自身または
いずれかのコンポーネントの障害
によって、ノードが使用できなく •
なります。このノードは通常、サ
ーバー・ファームの冗長セットの
•
一部です。
アプリケーション層のノードがクラッシュした、またはメ
モリーや CPU の不具合によって停止しなければならなく
なった。
アプリケーション
層ノードの障害
アプリケーション
層全体の障害
データベース層の
ノードの障害
例
停電（重要なシステムに対して複数の電力供給網およびバ
ックアップ・ジェネレータが用意されている場合は、影響
はデータ・センターの一部のみで済む）。
冗長性ネットワークの両方のカードで障害が発生したた
め、アプリケーション層のノードが使用できなくなった。
バグまたは不正な設定によって、アプリケーション層のソ
フトウェアがクラッシュした。
アプリケーション層全体が使用で •
きなくなります。
すべてのノードが停止する、また •
はすべてのノードのアプリケーシ
ョン・サーバーが停止します。
トラフィックをアプリケーション層へダイレクトしてい
た、冗長なハードウェア・ベースの両方のロード・バラン
サがクラッシュした。
•
ネットワークの接続がアプリケーション層へ送出された。
データベース・インスタンスにホ •
スティングしているデータ・サー
バーのクラスタ・ノードが使用で
きなくなっているか、またはクラ •
ッシュしています。
•
データベース層のノードがクラッシュした、またはメモリ
ーや CPU の不具合によって停止しなければならなくなっ
た。
Maximum Availability Architecture
アプリケーション・サーバー・ファームで最後に使用して
いたノードでサービスを提供できなくなった。
データベース層のノードが使用できなくなった。
冗長なクラスタ・インターコネクトの切換えに失敗して、1
つのノードが処理を行う。
8-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止
停止
説明
データベース層の
インスタンスの
障害
データベース・インスタンスが使 ソフトウェアの障害またはオペレーティング・システムやハー
用できない、またはクラッシュし ドウェアの問題によって、データ・サーバー上の RAC データ
ています。
ベースのインスタンスがクラッシュしています。
データベース層の
クラスタ全体の
障害
Oracle RAC データベースにホステ
ィングしているクラスタ全体が使
用できないか、またはクラッシュ
しています。この障害には、クラ
スタ内のノードの障害だけでな
く、クラスタの機能停止およびこ
のサイトの Oracle データベースと
インスタンスの機能停止の原因と
なる、他のすべてのコンポーネン
トの障害が含まれます。
データの障害
ユーザー・エラー
例
•
RAC クラスタで最後に使用していたノードの再起動に失敗
した。
•
冗長クラスタ・インターコネクトの切換えに失敗した。
•
データベースの破損（現行のデータ・サーバーで処理を継
続できないくらい深刻）。
•
ディスク・ストレージの障害
この障害によって、データベース •
の一部が使用できなくなります。
データ・ファイルが不用意に削除された、または無効にな
った。
•
メディア破損によってデータベース・ブロックが影響を受
けた。
•
オペレーティング・システム、または関連ノードの問題か
障害によって Oracle ブロックが破損した。
この障害によって、データベース •
の一部が使用できなくなります。
主な原因は、オペレータによるユ •
ーザー・エラーか、またはアプリ
ケーション・コードのバグです。
•
ユーザー・エラーによって表が削除された、または表内の
行が削除された。
アプリケーション・エラーによって、データベースが論理
的に破損した。
オペレータのエラーによって、指定した回数以上にバッ
チ・ジョブが実行された。
注意: 計画外停止では、データベースの可用性に影響を与える
ユーザー・エラーについてのみ説明します。
冗長なコンポーネ
ントの障害
MAA では、すべてのハードウェア ネットワーク・カード、ネットワーク、クラスタのインターコ
およびソフトウェア・コンポーネ ネクト、ディスク・コントローラとアダプタ、Oracle ディレク
ントの冗長性を既定しています。 トリ・サービス、またはホスト名の解決サービス。
この障害には、（冗長ペアに対し
て処理を自動的に引き継ぐ）冗長
なコンポーネントの障害が含まれ
ます。
この項では、計画外停止に対する停止のデシジョン・ツリーについて説明します。デシジョン・ツリーのそれぞれの停止
に対して、高度なリカバリ手順、およびその詳細な説明へのリンクが記載されています。停止のデシジョン・ツリーは、
本番サイトとスタンバイ・サイトに対して次のように分類されます。
•
プライマリ・サイト
•
セカンダリ・サイト
•
Enterprise Manager
リカバリ処理の説明は、「リカバリ処理の説明」の表に記載されています。
停止によっては、複数のリカバリ手順が必要になります。たとえば、あるサイトで障害が発生した場合、停止決定マトリ
ックスは、Data Guard フェイルオーバー、およびサイトのフェイルオーバーの必要があると示します。手順について、お
よびそれぞれのリカバリ処理のベスト・プラクティスについては、「リカバリ処理の説明」を参照してください。停止の
いくつかは、可用性を失うことなく自動的に処理されます。たとえば、インスタンス障害は RAC により自動的に管理さ
れます。該当する場合には、各停止について複数のリカバリ・オプションが説明されています。
Maximum Availability Architecture
8-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止
付録「運用上のベスト・プラクティス」では、すべての停止を回避および検出する様々なガイドラインについて説明して
います。停止の回避は、停止が発生したときに修復の処理を必要としないため、長期で考えれば最もコストのかからない
ソリューションになります。
8.1.1
プライマリ・サイトにおける計画外停止
プライマリ・サイトに本番データベースが含まれており、セカンダリ・サイトにスタンバイ・データベースが含まれてい
ると仮定すると、プライマリ・サイトの停止は最も重要なポイントになります。このような停止のソリューションは、シ
ステムの可用性を維持するうえで非常に重要です。
表8-2: プライマリ・サイトにおける計画外停止
停止の範囲
停止の理由
リカバリ手順
サイト
サイト障害
1. データベース・フェイルオーバー
2. サイト・フェイルオーバー
いずれかのアプリケーシ
ョン・サーバー
ノード障害
アプリケーション・サーバー・ファームの冗長ノードに
より自動的に管理される
すべてのアプリケーショ
ン・サーバー
全面的な障害
1. データベース・スイッチオーバー
本番データベース
2. サイト・フェイルオーバー
ノード障害
RAC により自動的に管理される
インスタンス障害
RAC により自動的に管理される
クラスタ全体の障害
1. データベース・フェイルオーバー
2. サイト・フェイルオーバー
ユーザー・エラー
1. 強制データベース・フェイルオーバー
2. サイト・フェイルオーバー
または
ローカル・オブジェクト・リカバリ
いずれかの層
8.1.2
コンポーネント障害
冗長コンポーネントにより自動的に管理される
セカンダリ・サイトにおける計画外停止
セカンダリ・サイトにおける計画外停止
セカンダリ・サイトにおいて前述の停止と同様の停止が発生しても、可用性には影響を与えません。これはスイッチオー
バーまたはフェイルオーバーがない場合は、クライアントが常にプライマリ・サイトにアクセスするためです。セカンダ
リ・サイトが停止すると、プライマリ・サイトで同時に障害が発生した場合に全体の MTTR が影響を受ける可能性があ
ります。ほとんどの場合には、セカンダリ・サイトの停止は可用性に影響を与えずに管理できます。
ただし、構成が最大保護のデータベース・モードで構成されている場合は、スタンバイ・インスタンスまたはデータベー
スにおける計画外停止によって、本番データベースが停止します。別のスタンバイ・インスタンスにフェイルオーバーし
た後、またはデータベース保護モードをダウングレードした後で、本番データベースを再起動できます。
Maximum Availability Architecture
8-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止
表8-3: セカンダリ・サイトにおける計画外停止
停止の範囲
停止の理由
リカバリ手順
スタンバイ・データベース プライマリ・ノードまたはインス スタンバイ・インスタンスのフェイルオーバー
タンスの障害（MRP で実行されて
いるもの）
セカンダリ・ノードまたはインス プライマリ・ノードまたはインスタンスが REDO を受
タンスの障害（MRP で実行されて け取り、REDO が MRP に適用されるため、影響はあり
いるもの）
ません。使用できるときにノードとインスタンスを再起
動します。
データ障害（メディア障害、ディ スタンバイ・データベースのデータ障害後にフォルト・
スクの破損など）
トレランスをリストアする
8.2
計画停止
計画停止とは、予定された停止です。この停止は、アプリケーションをサポートするテクノロジー・インフラストラクチ
ャの定期保守に必要なものであり、ハードウェアの保守、修理およびアップグレード、ソフトウェアのアップグレードと
パッチ適用、アプリケーションの変更とパッチ適用、システムのパフォーマンスと管理性改善の変更などの作業が含まれ
ます。計画停止は、連続アプリケーション可用性に対して最も都合のよい時間に行われるように、スケジュールが必要で
す。
次の表は、プライマリまたはセカンダリ・サイトのコンポーネントに影響を及ぼす、様々な計画停止について説明します。
表8-4: 計画停止
停止のクラス
説明
例
サイト全体
現在の本番システムが定義されているサイト全
体が使用できなくなります。これは通常、事前
にわかっておりスケジューリングすることがで
きます。
•
予定されている停電
•
サイトのメンテナンス
•
テスト・インフラストラクチャに対す
る定期的なスイッチオーバー
アプリケーション層の
これは、ハードウェア・メンテナンスに対する •
ハードウェア・メンテナン アプリケーション・サーバー・ノードの計画停
ス
止です。この停止には、修復やアップグレード
も含まれます。ノードは通常冗長なアプリケー •
ション・サーバー・ファームの一部であるため、
メンテナンスはノード間で交互に行うことが可
能で、アプリケーション・サーバー・ファーム
はアプリケーション・サービスの継続を管理し
ます。
メモリー・カードや CPU ボードなど、
障害が発生したコンポーネントの修
復
アプリケーション層の
これは、アプリケーション・サーバー・ノード •
ソフトウェア・メンテナン をアップグレードする、ソフトウェア・コンポ
ス
ーネントにパッチを適用する、または設定を変
更するための計画停止です。関連するソフトウ
ェア・コンポーネントとして、オペレーティン •
グ・システム、Oracle Application Server 10g、ア
プリケーション層に定義されているアプリケー
•
ションなどが考えられます。
オペレーティング・システムやアプリ
ケーション・サーバー・ソフトウェア
などのソフトウェア・コンポーネント
のアップグレード
データベース層の
ハードウェア・メンテナン
ス（ノードに影響を与え
る）
Maximum Availability Architecture
これは、ハードウェア・メンテナンスに対する
データベース・サーバー・ノードの計画停止で
す。この停止の範囲は、データベース・クラス
タのノードに限られます。
アプリケーション層の既存のノード
に対するメモリーや CPU の追加
オペレーティング・システムの構成パ
ラメータに対する変更
アプリケーション・サーバーの構成に
対する変更
•
メモリー・カードや CPU ボードなど、
障害が発生したコンポーネントの修
復
•
データベース層の既存のノードに対
するメモリーや CPU の追加
•
ストレージ層へのアップグレードに
よって、データベース層が停止する
8-4
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止
停止のクラス
説明
例
データベース層のハード
ウェア・メンテナンス（ク
ラスタ全体に影響を与え
る）
これは、ハードウェア・メンテナンスに対する
データベース・サーバー・ノードの計画停止で
す。この停止の範囲は、データベース・クラス
タ全体に及びます。
•
クラスタに対するノードの追加
•
クラスタ・インターコネクトのアップ
グレードまたは修復
データベース層のソフト
これは、ソフトウェア・メンテナンスに対する
ウェア・メンテナンス（ノ データベース・サーバー・ノードの計画停止で
ードに影響を与える）
す。この停止の範囲は、データベース・クラス
タのノードに限られます。
•
オペレーティング・システムなどのソ
フトウェア・コンポーネントのアップ
グレード
•
オペレーティング・システムの構成パ
ラメータに対する変更
データベース層の
ソフトウェア・メンテナン
ス（クラスタ全体に影響を
与える）
•
クラスタ・ソフトウェアのアップグレ
ードまたはパッチ適用
•
ボリューム管理ソフトウェアのアッ
プグレード
•
Oracle ソフトウェアに対する個別パ
ッチ
これは、ソフトウェア・メンテナンスに対する
データベース・サーバー・クラスタの計画停止
です。この停止の範囲は、データベース・クラ
スタ全体に及びます。
データベース層における
Oracle ソフトウェア・パッチに対する計画停止
Oracle ソフトウェアのパッ
チ適用
データベース層における
Oracle ソフトウェアのアップグレード（パッチ適 •
Oracle ソフトウェアのアッ 用も含む）に対する計画停止
プグレード
Oracle システム・ソフトウェアのアッ
プグレードまたはパッチ適用
データベース層の
アプリケーション変更 −
オブジェクトの再編成
別の表領域に対するオブジェクトの
移動
データベース層の
アプリケーション変更 −
アプリケーション・コード
のアップグレード
これは Oracle データベース・オブジェクトの論 •
理的な構造または物理的な編成に対する変更で
す。変更を行う主な要因としては、パフォーマ •
ンスの改善、オブジェクトの管理性の改善など
が挙げられます。これは必ず計画されたアクテ
ィビティになります。再編成を行うための方法 •
とタイミングは、十分に計画され、適切なもの
であるとします。
Oracle のオンライン再編成機能を使用して、再編
集中でもオブジェクトを使用できる必要があり
ます。
アプリケーション・コードのアップグレードま
たはデータベース層におけるパッチの適用。こ
れには、データベース・オブジェクトに対する
変更が含まれる場合もあります。
アプリケーションによって、データベース層の
停止が必要な場合と、必要でない場合がありま
す。
パーティション化された表に対する
表の変換
表内の列の名前変換/削除
•
アプリケーション・ソフトウェアのア
ップグレードまたはパッチ適用
•
オブジェクト構造または物理的な編
成に対する（アプリケーション・パッ
チの一部としての）変更
アプリケーションのアップグレードによって、
アップグレード中でもアプリケーション・オブ
ジェクトの一部を使用できる場合も、まったく
使用できなくなる場合もあります。
冗長なコンポーネントの
メンテナンス
MAA では、すべてのハードウェアおよびソフト
ウェア・コンポーネントの冗長性を既定してい
ます。これらのコンポーネントはときどきメン
テナンスして、再起動する必要があります。
障害が発生したコンポーネント（ネット
ワーク・カード、クラスタ・インターコ
ネクト、またはリジリエンスをリストア
するためのミラー化ディスク）の修復
この項では、計画停止に対する停止のデシジョン・ツリーについて説明します。デシジョン・ツリーのそれぞれの停止に
対して、高度なリカバリ手順、およびその詳細な説明へのリンクが記載されています。停止のデシジョン・ツリーは、本
場サイトとスタンバイ・サイトに対して次のように分類されます。
•
プライマリ・サイト
•
セカンダリ・サイト
リカバリ処理の説明は、「リカバリ処理の説明」の表に記載されています。
Maximum Availability Architecture
8-5
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止
8.2.1
プライマリ・サイトにおける計画停止
プライマリ・サイトに本番データベースが含まれており、セカンダリ・サイトにスタンバイ・データベースが含まれてい
ると仮定すると、プライマリ・サイトの停止は最も重要なポイントになります。このような停止のソリューションは、シ
ステムの可用性を維持するうえで非常に重要です。
表8-5: プライマリ・サイトにおける計画停止
プライマリ・サイトにおける計画停止
停止の範囲
停止の理由
リカバリ手順
サイト
サイトのシャットダウン
1. データベース・スイッチオーバー
2. サイト・フェイルオーバー
ノード・ハードウェア・メンテナ アプリケーション・サーバー・ファームの冗長ノードに
より自動的に管理される
ンス
いずれかのアプリケーシ
ョン・サーバー
プライマリ・データベース
ノード・ソフトウェアのメンテナ アプリケーション・サーバー・ファームの冗長ノードに
ンス（オペレーティング・システ より自動的に管理される
ム、アプリケーション・サーバー・
ソフトウェア、アプリケーショ
ン・ソフトウェアを含む）
ハードウェアのメンテナンス
（ノードに影響を与える）
RAC により自動的に管理される
ハードウェア・メンテナンス
（クラスタ全体に影響を与える）
1. データベース・スイッチオーバー
ソフトウェア・メンテナンス
（ノードに影響を与える）
RAC により自動的に管理される
ソフトウェア・メンテナンス
（クラスタ全体に影響を与える）
1. データベース・スイッチオーバー
2. サイト・フェイルオーバー
2. サイト・フェイルオーバー
個別パッチに対する Oracle ソフト パッチによっては、RAC のローリング・パッチ・アッ
ウェア・パッチのアップグレード プグレードが可能です。
Oracle ソフトウェア・アップグレ ローリング・アップグレードではない
ード（パッチ適用を含む）
データベース・オブジェクトの再 オンライン・オブジェクト再構成
構成
アプリケーション・コードの変更 範囲外
およびアップグレード
いずれかの層
8.2.2
コンポーネント変更
冗長コンポーネントにより自動的に管理される
セカンダリ・サイトにおける計画停止
セカンダリ・サイトにおいて前述の停止と同様の停止が発生しても、可用性には影響を与えません。これはスイッチオー
バーまたはフェイルオーバーがない場合は、クライアントが常にプライマリ・サイトにアクセスするためです。セカンダ
リ・サイトが停止すると、プライマリ・サイトでも同時に障害が発生した場合には MTTR 全体が影響を受ける可能性が
あります。ほとんどの場合には、セカンダリ・サイトの停止は可用性に影響を与えずに管理できます。
ただし、構成が最大保護のデータベース・モードで構成されている場合は、スタンバイ・インスタンスまたはデータベー
スにおける停止によって、本番データベースが停止します。別のスタンバイ・インスタンスにフェイルオーバーした後、
またはデータベース保護モードをダウングレードした後で、本番データベースを再起動できます。
Maximum Availability Architecture
8-6
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止
表8-6: セカンダリ・サイトにおける計画停止
停止の範囲
停止の理由
リカバリ手順
サイト
サイト・シャットダウン
停止前: 計画されているセカンダリ・サイトのメンテナ
ンス対して準備する
停止後: セカンダリ・サイトまたはクラスタ全体の計画
停止の後でフォルト・トレランスをリストアす
る
プライマリ・ノードのハードウェ 停止前: 計画されているセカンダリ・サイトのメンテナ
ンス対して準備する
アまたはソフトウェアのメンテナ
ンス（MRP で実行されているも
の）
セカンダリ・ノードのハードウェ
アまたはソフトウェアのメンテナ
ンス（MRP で実行されていないも
の）
スタンバイ・データベース
プライマリのスタンバイ・ノードまたはインスタンスが
REDO を受け取り、それが MRP に適用されるため、影
響はありません。
停止後: 使用できるときにノードとインスタンスを再
起動します。
ハードウェアまたはソフトウェア 停止前: 計画されているセカンダリ・サイトのメンテナ
のメンテナンス（クラスタ全体に
ンス対して準備する
影響を与える）
停止後: セカンダリ・サイトまたはクラスタ全体の計画
停止の後でフォルト・トレランスをリストアす
る
Oracle ソフトウェアのアップグレ ローリング・アップグレードではない
ード
計画されているセカンダリ・サイトのメンテナンスに対して準備する
セカンダリ・サイトにおいてサイト全体またはクラスタ全体の計画停止が必要な場合、および最大保護モードが有効にな
っている場合には、本番データベースを停止させる必要があります。セカンダリ・サイトにおける計画停止中にサービス
を継続させるには、最大保護モードを最大可用性モード、または最大パフォーマンス・モードにダウングレードが必要で
す。最大保護モードからのダウングレードには、本番データベースをリストアする必要があります。5.2.8「データベース
の保護モードを設定する」を参照してください。また本番データベースでは、サイト全体またはクラスタ全体の停止され
る期間がスタンバイのラグに追加される、つまりフォルト・トレランスをリストアする時間が長くなることを考慮してく
ださい。
Maximum Availability Architecture
8-7
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止
表8-7: 計画されているセカンダリ・サイトのメンテナンス対して準備する
本番データベースの
保護モード
停止の理由
準備手順
サイト・シャットダウン
ハードウェア・メンテナンス
（クラスタ全体に影響を与える）
ソフトウェア・メンテナンス
（クラスタ全体に影響を与える）
最大保護
プライマリ・ノードのハードウェ
ア・メンテナンス（MRP または
LSP で実行されているもの）
プライマリ・ノードのソフトウェ
ア・メンテナンス（MRP または
LSP で実行されているもの）
「Oracle Data Guard」の項でハイライトされている「デー
タベースの保護モードを設定する」の手順を使用して、
本番データベースの保護モードを、最大可用性または最
大パフォーマンスのモードに変更します。
スタンバイ・インスタンスのフェイルオーバー
サイト・シャットダウン
ハードウェア・メンテナンス
（クラスタ全体に影響を与える）
最大可用性または最大パ
フォーマンス
ソフトウェア・メンテナンス
（クラスタ全体に影響を与える）
プライマリ・ノードのハードウェ
ア・メンテナンス（MRP または
LSP で実行されているもの）
プライマリ・ノードのソフトウェ
ア・メンテナンス（MRP または
LSP で実行されているもの）
Maximum Availability Architecture
なし
スタンバイ・インスタンスのフェイルオーバー
8-8
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
9.
停止からのリカバリ
MAA は、様々なリカバリ・オプションを使用します。これらのリカバリ・オプションでは、停止とデータ消失を防止し、
最小限にするために、Oracle 製品機能およびインフラストラクチャが組み合せて使用されます。次の表で、様々なリカバ
リ処理について説明します。
9.1
リカバリ処理の概要
リカバリ処理の概要
表9-1: リカバリ処理
リカバリ処理
説明
サイト・フェイルオーバー サイトのフェイルオーバーでは、セカンダリ・サイトによる処理の引継ぎが行われます。
フェイルオーバーが行われると、セカンダリ・サイトが新しい本番サイトになります。新
しいクライアント要求はすべて新しいサイトに転送されます。アプリケーション・サービ
スを提供するために、このサイトのアプリケーション層が有効になります。このサイトの
データ・サーバーは新しい本番データベースになります。この推移は、データベース層か
らアプリケーション層へと外側へ行われます。WAN トラフィック・マネージャは、新しい
サイト上のロード・バランサへトラフィックを転送します。新しいサイトのロード・バラ
ンサは、クライアント・トラフィックを新しく有効化されたアプリケーション・サーバー
に転送するよう、事前に設定されています。
完全なリカバリを行うデ
ここでは、データベース層の Data Guard のフェイルオーバーが行われ、完全なリカバリが
ータベース・フェイルオー 試行されます。データの消失は最少またはゼロになります。前の本番データベースは、バ
バー
ックアップまたは現在の本番データベースから再インスタンス化が必要です。計画外停止
のため、以降のサイト・フェイルオーバーを行う必要があります。
強制データベース・フェイ ここでは、データベース層の Data Guard のフェイルオーバーが行われます。不完全なリカ
ルオーバー
バリ、または Point-in-Time リカバリが発生します。論理的な破損の前、整合性のとれてい
る期間にスタンバイ・データベースが有効になっている場合は、データが損失します。以
前の本番サイトのデータベースは、バックアップまたは現在の本番データベースから再度
インスタンス化が必要です。計画外停止のため、以降のサイト・フェイルオーバーを行う
必要があります。
データベース・スイッチオ ここでは、データベース層の Data Guard のスイッチオーバーが行われます。以前のスタン
ーバー
バイ・データベースは新しい本番データベースになり、以前の本番データベースは新しい
スタンバイ・データベースになりますが、再度インスタンス化は必要ありません。以降の
サイト・フェイルオーバーを行う必要があります。これは計画停止になります。
RAC のフェイルオーバー
または RAC のリカバリ
RAC は、特定サイトにおけるインスタンスおよびノードの障害を自動的に処理し、バック
エンドのデータ・サーバーへ継続してアクセスできるようにします。停電のわずかな期間
を除いては、アプリケーションの観点からすると全体の処理が透過で、プライマリ・サイ
トでのみ発生します。
スタンバイ・インスタンス
のフェイルオーバー、また
はスタンバイ・クラスタの
メンテナンスや障害
スタンバイ・ノードでメンテナンスが必要な場合は、別のスタンバイ・インスタンスに切
り替えて、本番データベースへの影響を回避し、スタンバイでラグが増加しないようにし
ます。
スタンバイ・クラスタでメンテナンスが必要な場合、またはスタンバイ・クラスタで障害
が発生した場合は、本番データベースを最大可用性モードまたは最大パフォーマンス・モ
ードにダウングレードする必要があります。ただし、この保護モードでは、サイト間でデ
ータ分岐できます。
アプリケーションのフェ
イルオーバー
アプリケーション層は、プライマリ・サイトでインスタンスまたはノードの障害が発生し
たときに、1 つ以上の有効な RAC インスタンスに対して自動的にフェイルオーバーを行い
ます。Oracle Net は新しいインスタンスに対するフェイルオーバーを管理します。
Maximum Availability Architecture
9-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
リカバリ処理
説明
オブジェクトのリカバリ
状況によっては、現在の本番サイトを継続し、消失したオブジェクトをリカバリして特定
の部分だけ可用性を犠牲にする方法がコスト効率が良い場合があります。Oracle のオブジ
ェクト・リカバリ機能は、このような要件に対処できます。
オンライン・オブジェクト データ・サーバーに関する多くの計画停止では、基本的になんらかのデータベース・オブ
再構成
ジェクトの再編成が必要です。この再編成は、データベースの可用性を保持しながら行う
必要があります。Oracle のオンライン・オブジェクトの再構成を使用して、計画停止を管
理します。
この項は、停止のソリューションを実現する手順について詳しく説明します。次の層は、クライアント層、アプリケーシ
ョン・サーバー層、データベース・サーバー層のリカバリ処理を系統立てて示しています。次の図は、これらの層を表し
ています。
図9-1: 3層の
層のMaximum
Availability Architecture
層の
Maximum Availability Architecture
9-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
この項では、次のリカバリ手順について説明します。
•
クライアント層 − サイト・フェイルオーバー（すべての層を含む）
•
アプリケーション・サーバー層 − アプリケーション・サーバー・フェイルオーバー
•
データベース・サーバー層 − オブジェクトの再編成
•
データベース・サーバー層 − オブジェクトのリカバリ
•
データベース・サーバー層 − RAC フェイルオーバーおよび透過的アプリケーション・フェイルオーバー
•
データベース・サーバー層 − Data Guard スイッチオーバー
•
データベース・サーバー層 − Data Guard フェイルオーバー
•
データベース・サーバー層 − スタンバイ・インスタンス・フェイルオーバー
•
データベース・サーバー層 − スタンバイ・クラスタ・メンテナンス
Maximum Availability Architecture
9-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
9.2
クライアント層 - サイト・フェイルオーバー（すべての層を含む）
サイトのフェイルオーバー機能を実現するために、プライマリおよびセカンダリ・サイトの両方に WAN トラフィック・
マネージャを実装します。WAN トラフィック・マネージャは、プライマリ・サイトにアクセスできない場合にトラフィ
ックを自動的にリダイレクトできます。また、手動でトリガーし、スイッチオーバーを行うためにセカンダリ・サイトへ
切替えも可能です。通常の処理の間、セカンダリ・サイトはアイドル状態で、ユーザー要求を受け取りません。停止また
はスイッチオーバーのためにプライマリ・サイトで障害が発生してサービスを提供できない場合にのみ、トラフィックが
セカンダリ・サイトに転送されます。プライマリ・サイトで障害が発生した場合は、ユーザー・トラフィックがセカンダ
リ・サイトに転送されます。次の図は、サイト・フェイルオーバー（赤い太線の矢印部分）の前のネットワーク・ルート
を示しています。
図9-2: サイト・フェイルオーバーの前のネットワーク・ルート
次の図は、サイト・フェイルオーバー（青い点線の矢印部分）後のネットワーク・ルートを示しています。
Maximum Availability Architecture
9-4
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
図9-3: サイト・フェイルオーバーの後のネットワーク・ルート
次の手順は、フェイルオーバーまたはスイッチオーバーにおけるネットワーク・トラフィックの状態を説明しています。
1.
本番データベースがフェイルオーバーした、またはセカンダリ・サイトへスイッチオーバーした。
2.
セカンダリ・サイトで中間層のアプリケーション・サーバーが起動された。
3.
クライアントの DNS 要求および解決の動作によって、セカンダリ・サイトの WAN トラフィック・マネージャ
の選択が行われる。セカンダリ・サイトの WAN トラフィック・マネージャが、セカンダリ・サイトのロード・
バランサの仮想 IP アドレスを返す。
Maximum Availability Architecture
9-5
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
4.
セカンダリ・サイトのロード・バランサが、セカンダリ・サイトの中間層アプリケーション・サーバーへトラフ
ィックを転送する。
5.
セカンダリ・サイトで、クライアント要求を受け取る準備が完了する。
フェイルオーバーは、クライアントの Web ブラウザにも依存しています。ほとんどのブラウザ・アプリケーションは、
一定期間のドメイン・ネーム・サービス（DNS）エントリをキャッシュしています。このため、停止中のセッションは、
キャッシュの有効期間までフェイルオーバーできない場合があります。このようなクライアントに対してサービスを再開
するには、ブラウザを閉じた再起動しかありません。
Maximum Availability Architecture
9-6
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
9.3
アプリケーション・サーバー層 - アプリケーション・サーバー・
フェイルオーバー
クライアントは、ハードウェア・ベースのロード・バランサを介してアプリケーション・サーバー・ファームへアクセス
します。このロード・バランサは、アプリケーション・サーバー・ファーム内のいずれかのアプリケーション・サーバー
へリクエストを送信します。アプリケーション・サーバー・ファーム内のアプリケーション・サーバーはクライアント・
リクエストのサービスが可能で、インスタンス・アプリケーション・サーバーまたはホストの障害は、アプリケーション
には提示されません。アプリケーション・サーバーが使用できなくなると、ロード・バランサは新しいリクエストを残り
のアプリケーションに継続して転送します。
障害が発生したアプリケーション・サーバーに対するリクエストが存在するとエラーになり、新しいアプリケーション・
サーバーに対してリクエストがリダイレクトされたときに、問題のあるサーバーのセッション情報は失われます。Oracle
Application Server では、セッション・ステートのレプリケーションを使用して、複数のアプリケーション・サーバーのセ
ッション情報を保持できます。
図 9-4 は、冗長性とバックアップを提供し、単一の障害箇所の排除によって、アプリケーション・サーバー・ファームが
高可用性を実現するしくみを表しています。クライアントは、ロード・バランサを介してアプリケーション・サーバー・
ファームへアクセスします。ロード・バランサは、アプリケーション・サーバー・ファーム内のいずれかのアプリケーシ
ョン・サーバーへリクエストを送信できます。アプリケーション・サーバーが使用できなくなると、ロード・バランサは
新しいリクエストを残りのアプリケーション・サーバーへ継続して転送します。
図9-4: アプリケーション・サーバー・ファームにおけるアプリケーション・サーバーの障害
アプリケーション・サーバー・ファームにおけるアプリケーション・サーバーの障害
Maximum Availability Architecture
9-7
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
9.4
データベース・サーバー層 - オブジェクトの再編成
データベースでは、データベース・オブジェクトの再編成が一般的なタスクです。これには、次の理由があります。
•
オブジェクトの再配置によってパフォーマンスを改善する
•
アプリケーションの変更またはアップグレードによる構造の変更に対応する
•
大容量の表をより小さいパーティションにパーティション化する
データベース・オブジェクトの再編成は、アプリケーションの可用性の中断を最少にする必要があります。Oracle9i
Database に-は、表および索引の再編成を実現する様々な機能があります。これらの機能は通常のアプリケーション機能
に対してオンラインで行い、オブジェクトの可用性の中断を最小限にできます。オブジェクトの再編成は計画されたアク
ティビティであり、システムの使用率が低いときに行う必要があります。同じ再編成に対して複数の方法があり、オブジ
ェクトの可用性に対する影響もそれぞれ異なるため、次の要因に基づいて適切な方針を選択します。
•
オブジェクトのサイズ
•
オブジェクトにおける読込みと書込みの量と割合
•
再編成の種類と範囲
•
再編成に必要な使用できるリソース
再編成によっては、オブジェクトのデータ・コンテンツの変更が必要な場合もあります。これらの再編成は通常アプリケ
ーションに特有のもので、アプリケーション・レベルで最適に処理されるため、ここでは取り上げません。
次の表に、オブジェクトの再編成のソリューションについてまとめています。
表9-2: オブジェクト再編成のソリューション（概要）
要件
使用できる方法
列名の変更
ALTER TABLE … RENAME.
表の移動
Alter table … move.
例:
オンラインで表を再定義する
• ブロック・サイズまたは記憶特性が異なる別の表領域
CREATE TABLE AS SELECT (CTAS)
へ表を移動する
• パフォーマンスを改善するために表の物理的なレイア
ウトを再編成する
表領域の編成を変更する
オンラインで表を再定義する
例: 通常の表（ヒープ構成表）を索引構成表へ変更する
水平パーティション化
オンラインで表を再定義する
例: 大容量の表を複数のパーティションへパーティション
化する
垂直パーティション化
例: 1 つの表を列ごとに複数の表へ垂直に分割する
表の非索引列を削除する
オンラインで表を再定義する
アプリケーション固有のカスタマイズされた手順
複数の CTAS
ALTER TABLE … SET UNUSED
ALTER TABLE … DROP UNUSED COLUMN
オンラインで表を再定義する
ALTER TABLE … DROP COLUMN
Maximum Availability Architecture
9-8
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
要件
使用できる方法
ALTER TABLE … SET UNUSED
以降のオンライン索引の再作成
表の索引列を削除する
新しい索引/制約を定義してオンラインで表を再定義する
ALTER TABLE … DROP
以降のオンライン索引の再作成
索引作成
CREATE INDEX … ONLINE
索引の再作成
ALTER INDEX … REBUILD ONLINE
オンライン索引結合
ALTER INDEX … COALESCE ONLINE
カスタム・アプリケーション特有の再編成
例: BLOB の内容を再編成する
オブジェクト再編成には、オブジェクトおよび表の内容に
非常に特有で、アプリケーションの変更に影響されるもの
があります。これらの再編成は、アプリケーション特有の
カスタマイズされた手順を使用して行ってください。
9.4.1
オブジェクト再編成のソリューション
常に可用性があることが必要な大規模なオブジェクトでは、オンラインで表を再定義することが適切なソリューションで
す。それ以外のオブジェクトでは、ALTER TABLE 文などの他の機能も使用できます。カスタマイズされた手順を使用し
てアプリケーション特有の再編成を行う場合は、アプリケーションの可用性が保証されるように、このような手順を設計
する必要があります。表の構造定義に対する変更では、通常アプリケーション・コードの変更も必要になります。このよ
うな場合には、アプリケーション・コードのアップグレードは構造の変更と同期的に行われます。
この項では、表を再編成するための次の方法について説明します。
•
オンラインで表を再定義する
•
ALTER TABLE 文
•
オンラインで索引を再編成する
これらの例については付録で説明しています。これらの機能の詳細、および制約の例については、次のマニュアルを参照
してください。
•
『Oracle9i データベース管理者ガイド リリース 2（9.2）』
•
『Oracle9i SQL リファレンス リリース 2（9.2）』
•
『Oracle9i PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス リリース 2（9.2）』
オンラインで表を再定義する
オンラインで表を再定義することによって、表を使用したまま表の定義および物理的な設計を変更できます。このため、
表の再編成中でもアプリケーション・サービスの継続が可能です。
オンラインで表を再定義している間にも、アップグレードができます。この場合には、以前の定義から新しい定義へ最後
の切替えに、わずかな間のみ表が排他的にロックされます。
オンラインの表再定義を使用する場合
オンラインの表再定義によって、アプリケーションは表の構造定義を変更だけでなく、表にアクセス可能な状態のまま記
憶特性も変更できます。これは、表の再定義に時間がかかり、全体の処理でアプリケーションを使用可能にする必要があ
る大規模なオブジェクトでは特に便利です。
オンラインで表の再定義によって、次のメリットが得られます。
Maximum Availability Architecture
9-9
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
•
表の記憶域パラメータを修正できる
•
同じスキーマの別の表領域へ表を移動できる
•
パラレル問合せに対してサポートを追加できる
•
パーティション化のサポートを追加または削除できる
•
表を再作成して断片化を軽減できる
•
通常の表（ヒープ構成表）の編成と索引構成表の間で相互に変更できる
•
列を追加または削除できる
以前の表および新しい表の制約については、『Oracle9i データベース管理者ガイド リリース 2（9.2）』の第 15 章「表の
管理」に記載されています。
オンライン表再定義を使用するための前提条件
•
オンライン表の再定義に必要な領域を慎重に見積もります。必要な領域の決定には、「有効なプラクティス」を
参照してください。必要な領域は、表のサイズ、表に対する書込みの量、および再編成の範囲によって非常に異
なります。
•
オンラインのオブジェクト再編成では、追加のシステム・リソースを消費するため、パフォーマンスに多少の影
響があります。
•
オンライン再編成を行って仮のトランザクションを取得するために、追加の UNDO セグメントも必要になりま
す。
UNDO セグメントの領域要件は最初、同期化および最後の手順でピークになり、これらの手順が実行されるイン
スタンスで高くなります。特定の表をアップグレードするトランザクションの処理に、追加の UNDO セグメン
ト領域が消費されます。
•
再編成は、本番環境の実行前にテスト環境でのテストをお薦めします。領域（データ、索引、UNDO）およびパ
フォーマンスに対する再編成の影響を評価する必要があります。この場合には、オブジェクト・サイズ、トラン
ザクション・ミックス、トランザクション・レート、および再編成の範囲が本番システムと類似するように、テ
スト・システムを設定してください。データ、索引、および UNDO セグメントに対する追加の領域は、テスト
環境で測定し、本番環境に拡張できます。パフォーマンスの影響も測定し、本番環境に拡張することが可能です。
最も厳しい条件のシナリオに対する影響の測定をお薦めします。これにより、再編成を完全にする十分なシステ
ム・リソースの使用を保証します。
•
オンラインで表を再定義している間も更新は可能ですが、これは対象の表のシステム・アクティビティが低いと
きにスケジュールする必要があります。これにより、再編成に必要な UNDO 領域の量も減り、オンラインの再
定義がスムーズになります。
有効なプラクティス
•
表の構造定義が変更された場合は、表の新しい定義の使用にアプリケーション・コードの同期化を外部で調整す
る必要があります。この作業の複雑さは、変更およびアプリケーション・コードの性質によって決まります。
•
オンラインの表再定義の開始および終了（start_redef_table ()および finish_redef_table ()）は、表に関して、実行時
間の長いトランザクションの再定義が行われないときに実行が必要です。redef_table のコールは、保留中のすべ
てのトランザクションがコミットかロールバックまで待機します。
•
仮表のすべての索引および制約の定義は、再定義の開始後に行います。これにより、再定義の開始が高速になり
ます。
Maximum Availability Architecture
9-10
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
•
仮表に作成される参照整合性制約およびトリガーは無効にします。
•
同期コール（sync_interim_table ()）は、表および仮表を同期化します。再定義中に通常のベースでこの同期化を
コールすると、finish_redef_table ()にかかる絶対時間が短くなります。必要な領域が縮小される場合もあります。
•
再定義中の表にマテリアライズド・ビューが存在する場合は、処理中にそのビューの削除が必要です。
•
1 つの表に対しては、一度に実行できるオンライン表の再定義は 1 つのみです。
•
処理全体の領域要件は、事前に十分な領域を持つ計画が必要です。オンライン表の再定義に対する追加の領域要
件には、次のものが含まれます。
新しい定義において、現行表のすべての行に対する領域
再定義処理で作成される、すべての追加行および更新に対する領域
新しい定義の索引に対する領域
再定義処理中の変更に対するマテリアライズド・ビュー・ログの領域
•
DML ロックを有効にし、オンラインの表再定義に対して十分にしておきます。
ALTER TABLE文
文
表の定義および表の記憶特性を変更するために、いくつかの ALTER TABLE 文が用意されています。
これらの文は、比較的小さい表、および再編成中にアプリケーションを可用にする必要がない表に対して使用できます。
これらの処理では、表が長時間ロックされ、表に対して DML アクセスがブロックされる場合もあります。ALTER TABLE
文を使用するには、DML ブロックの有効が必要です。これらの文の制約および使用方法については、これらの文を使用
した再編成の計画前に、『Oracle9i データベース管理者ガイド』リリース 2（9.2）を参照してください。これらの文の使
用例については、付録「オブジェクトの再編成とリカバリの例」を参照してください。
この場合には、次の ALTER TABLE 文が重要になります。
•
ALTER TABLE ... DROP COLUMN
この文で、表の 1 つ以上の列を削除します。表が大きい場合は処理時間が長くなるため、この文は使用しないで
ください。このような場合は、ALTER TABLE … SET UNUSED を使用する方が適切です。unused とマークされ
ている列は、この処理ですべて削除されます。索引列の 1 つとして削除された列を持つ索引も削除されます。使
用されていない列を参照しているアプリケーションに対して、Oracle エラー（ORA-00904: "col": invalid identifier）
が提示されます。
•
ALTER TABLE … SET UNUSED
これは、遅延される ALTER TABLE ... DROP COLUMN 文に似ています。この文では、使用されていない列を削
除するようマークします。実際は、その列が以前と物理的に同じ領域に定義されていても、列はその表の一部に
はなりません。これは、停止時間が最少で非常に高速な処理になります。実際の列の削除は、ALTER TABLE …
DROP COLUMN へのコールが実行されたときに行われます。
•
ALTER TABLE … RENAME
この文は、既存の列の名前を変更します。列の名前を変更しても、名前変更された列に関するファンクション・
ベースのすべての索引および CHECK 制約はまだ有効になりますが、これらの列に従属している他のビュー、ト
リガー、ドメイン索引、関数、手順、およびパッケージは INVALID とマークされます。これらのものが以前の
名前を参照している場合は、それ以降の再検証でも失敗します。結合索引の定義に使用される列は、名前を変更
できません。かわりに索引を削除し、列名を変更してから索引を再作成する必要があります。
•
ALTER TABLE … MOVE
この文では、パーティション化されていない表を再配置して記憶域パラメータを変更できます。索引編成、非パ
ーティション化表に対しては、この移動はオンラインでは実行できません。ヒープ構成のパーティション化され
ていない表では、このコマンドを使用して移動を行うと、移動際に表がロックされます。表が大きい場合は、オ
ンラインの再定義を行う方が適しています。
Maximum Availability Architecture
9-11
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
オンラインで索引を再編成する
ほとんどの環境では、索引の再編成だけでなく、新しい索引の作成が必要なことがあります。その目的は次のとおりです。
•
パフォーマンスを改善する
•
既存の索引を削除し、再作成する
•
新しい制約、または別の制約を作成する
•
アプリケーションに対するデータ・アクセス・パターンを変更する
すべての索引の作成は、アプリケーションの可用性に影響を与えずにオンラインで実行できます。索引の再編成の例につ
いては、付録を参照してください。
オンラインで索引の再編成を使用する場合
索引の構築（ビルド）によって、通常の索引を作成できます。既存の索引も、オンラインで再構築できます。索引の構築
と再構築だけでなく、索引の結合もオンラインで可能です。
オンラインで索引再編成を使用するための前提条件
•
オンラインの索引構築中には、パラレル DML はサポートされません。
•
オンラインの索引作成中には、他の DDL を使用できません。
•
これは、通常の索引でのみ使用できます。ビットマップ索引またはクラスタ索引に使用できません。これらの再
作成が必要です。
•
通常の索引では、ROWID 列に ONLINE を指定できません。
•
索引の再構築では追加のディスク領域が必要になります。
有効なプラクティス
•
索引はオンラインで構築できますが、この処理はシステムの使用率が低いときにスケジュールする必要がありま
す。
•
実行中のオンライン索引構築の処理は、実表でコミットされていないトランザクションがあると待機するため、
このような DML は最少にして長い間実行しないようにします。
•
索引の再構築を使用して、表領域間で索引を移動だけでなく、これらの記憶特性も変更できます。
•
オンライン索引結合は、ツリーの同じ分岐内のリーフ・ブロックを結合し、索引のリーフ・ブロックを使用でき
るように解放します。結合により、新しいエントリに対して割り当てられている索引セグメントの領域が解放さ
れ、断片化が減少します。このことによって、パフォーマンス上のメリットが得られます。索引の再構築におい
て十分なディスク領域が使用できない場合は、結合の使用をお薦めします。索引の結合はオンラインで可能です。
•
索引の構築および索引の再構築のシナリオに対して、十分なソート領域を確認してください。
•
索引の再構築では、索引をオンラインで削除してから再作成する方が早い場合もあります。通常これらのケース
は、実表におけるシステム・アクティビティが重い場合に索引の再構築を行い、再構築する表の中に列の更新が
多数含まれている場合に相当します。
Maximum Availability Architecture
9-12
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
9.5
データベース・サーバー層 - オブジェクトのリカバリ
Oracle オブジェクトは、表、クラスタ、または索引のいずれかです。オブジェクトのリカバリは、特定の計画外停止の状
況で開始されます。オブジェクトが完全に、または部分的に使用できない場合には、セカンダリ・サイトにフェイルオー
バーするよりもオブジェクトをローカルにリカバリする方が適切です。このような場合は、ローカルなリカバリに比べて、
セカンダリにフェイルオーバーし新しいスタンバイを再インストールするコストが非常に高くなります。
オブジェクトの停止において、考えられる処置の順序は次のとおりです。特定の停止を解決する処置の手順は、様々な要
因によって異なります。この項では、これらの要因について詳しく説明します。
•
ローカルなオブジェクト・リカバリ − 詳細は「ローカルなオブジェクト・リカバリのソリューション」を参照
してください。
すぐにローカルなリカバリを行う − できるだけ迅速にリカバリをローカルに開始します。
後でローカルなリカバリを行う − ローカルなリカバリを行いますが、リカバリ・プロセスは後で実行しま
す。
•
ロールの推移
スイッチオーバー − Data Guard のスイッチオーバー
完全なリカバリを実現するフェイルオーバー − Data Guard の完全な（またはできるだけ完全な）フェイルオ
ーバー
ある時点のフェイルオーバー − エラー発生前の特定のタイミングに対する Data Guard のフェイルオーバー
顧客は、次の項で説明している処理を使用して、カスタマイズされたオブジェクト破損の決定マトリックスを作成し、オ
ブジェクトが破損した際にロール・リバーサル・プロセスとローカルなオブジェクト・リカバリのどちらを選択を早急に
決定する必要があります。
決定がはっきりしない、または複雑すぎてオブジェクトがアプリケーションの可用性に影響を与える場合は、顧客はデー
タベースのフェイルオーバーを開始し、サイト・フェイルオーバーを起動してアプリケーションの可用性を回復させる必
要があります。
この項では、ローカルなリカバリを選択するか、またスタンバイへのフェイルオーバーを選択するかの判断を支援する、
意思決定のプロセスを説明します。
最後に、MAA で使用されるオブジェクト・リカバリのソリューションについて説明し、その後で、問題を回避するため
の通常の方針について説明します。
この項には次のトピックが含まれています。
•
ローカルなオブジェクト・リカバリとロールの推移のいずれかの選択
•
ローカルなオブジェクト・リカバリのソリューション
9.5.1
ローカルなオブジェクト・リカバリとロールの推移のいずれかの選択
障害が発生すると、処理の監視、またはエラーを受け取ったアプリケーションによって障害が検出されます。原因は、オ
ブジェクトが完全（または部分的に）使用できなくなったことが考えられます。簡単な解決方法として（変更がスタンバ
イ・データベースへ適用されていない場合の論理的な問題については、データベースのフェイルオーバー、およびセカン
ダリ・サイトへのフェイルオーバーがあります。メディアが破損している場合は、データベースのスイッチオーバー、お
よびサイトのフェイルオーバーがあります。ただし、すぐに修正を行う場合、または一部的な可用性のみで十分な場合は、
データベースのフェイルオーバーのかわりにローカル・リカバリも可能です。多くのケースでは、ローカルなリカバリを
行うと、オブジェクトのリカバリが完了するまで現行インスタンスのサービスを部分的に継続して行うことができます。
これによって、スタンバイ・データベースを再度インスタンス化する実質的な時間と労力が節約されます。
Maximum Availability Architecture
9-13
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
次の表および手順で、オブジェクトの破損を処理する方法について、およびこの停止を解決するための有効な解決方法に
ついて説明します。
オブジェクトの停止を解決するための手順
1.
スタンバイでリカバリをキャンセルする
2.
影響を受けているオブジェクトを特定する
3.
オブジェクトが適用されている範囲を特定する
4.
オブジェクトの重要度を判断する
5
問題の性質を特定する
6.
オブジェクトのタイプを特定する
7.
必要なリカバリの処置を決定する
1. スタンバイでリカバリをキャンセルする
これにより、本番アプリケーションがスタンバイへこれ以上記録されず、本番データベースにおける分析と問題解決がで
きます。検出されてからすぐに、変更が適用される前にリカバリをキャンセルすると、オブジェクトの破損がスタンバイ・
データベースに影響はありません。
(physical standby database)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL IMMEDIATE;
(logical standby database)
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
2. 影響を受けているオブジ
影響を受けているオブジェクトを特定する
ェクトを特定する
ソースの確認（定期的な監視）
a)
アラート・ログで次のエラー（ORA-1578、ORA-1110/ORA-600 [3339]）を確認します。
ORA-01578:ORACLE data block corrupted (file # 4, block # 26)
ORA-01110:data file 4:'/u01/oradata/objrs/obj_corr.dbf'
ORA-600 errors should always be reported.
b)
アプリケーション・ログで、このエラーおよび論理データ・エラーを確認します。ログは、データ・サーバー、
中間層およびクライアント・マシンに記述されている可能性があります。たとえば、不明なオブジェクトがある
場合はアプリケーションは ORA-00942: table or view does not exist というメッセージを受け取りま
す。
ソースの確認（事前監視）
DBVERIFY、DBMS_REPAIR、RMAN などの Oracle ツール、または VALIDATE STRUCTURE オプションを指定した
ANALYZE 文を実行中にエラーが検出された場合は、該当するログ・ファイルで結果を確認します。
オブジェクトの詳細を取得する
SELECT OWNER,
SEGMENT_NAME, PARTITION_NAME, SEGMENT_TYPE,
TABLESPACE_NAME FROM DBA_EXTENTS
WHERE FILE_ID = fid AND bid BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS;
fid ⇒ file id
bid ⇒ block id
Maximum Availability Architecture
9-14
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
不明なオブジェクトについては、オブジェクトが存在しているかどうか検証します。オブジェクトを検証するには、
外部の変更管理ツールを確認します。
アクション
•
OWNER が SYS の場合はフェイルオーバーします。
•
SEGMENT_TYPE が ROLLBACK/”TYPE2 UNDO”の場合はフェイルオーバーします。
•
SEGMENT_TYPE が TEMPORARY の場合はフェイルオーバーせず、一時表領域の一時的なオブジェクトを
ローカルに再作成することを検討します。
•
他のオブジェクトに対しては、オブジェクトの決定マトリックスに従います。
3. オブジェクトが適用されている範囲を特定する
問題が広範に及んでおり、複数のオブジェクトが影響を受けている場合は、Data Guard のフェイルオーバーを実行し
ます。
4. オブジェクトの重要度を判断する
オブジェクトには、アプリケーションが機能するうえで重要なポイントになっているものがあります。このようなオ
ブジェクトとしては、パフォーマンスおよびアプリケーションの有用性において重要なオブジェクトがあります。履
歴、レポート作成、またはロギングの表もオブジェクトに含まれますが、これらは重要であるとはかぎりません。ま
た、現在は使用されていないオブジェクトや一時セグメントもあります。オブジェクトが重要でない場合は、通常は
ローカルにリカバリする方が適切です。
5. 問題の性質を特定する
オブジェクトが使用できない
オブジェクトが使用できない場合は、手順 1 の問合せで行が返されません。これはユーザー・エラーによってデータ
ベース内に既にオブジェクトが存在していないためです。データの整合性に影響を及ぼすアプリケーション・エラー
またはユーザー・エラーによって、オブジェクトが無効になっている可能性もあります。
メディアの破損
メディアの破損:
アの破損 物理的なメディアが不正
オペレーティング・システムからブロックを読み込めない場合は、メディアが破損している場合がほとんどです。
OS のシステム・ログで、関連メッセージを確認してください。dd UNIX コマンドなどのオペレーティング・システ
ム・ユーティリティを使用して、ブロックにアクセスしてみてください。これらの破損は、スタンバイには伝播され
ません。
ソフト破損:
ソフト破損 物理的なメディアを読み込めないが Oracle ブロックが不正である
ブロックは、インスタンスによって有効な Oracle ブロックとして認識されませんが、それ以外は正常です。これらの
内容はアラート・ログ、あるいはブロックにアクセスするアプリケーションに対して ORA-1578、ORA-1110、ORA-7445、
または ORA-600 [12700]として記録されます。
論理的な破損:
論理的な破損 従属オブジェクトが内部で矛盾している
索引エントリが表のエントリと一致しない、または主キーが外部キーと一致しない場合があります。
Maximum Availability Architecture
9-15
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
6. オブジェクトのタイプを特定する
ディクショナリ・オブジェクト
オブジェクトがデータまたは索引セグメント・オブジェクトではない場合は、オブジェクトをローカルに再作成しま
す。
データ・オブジェクトまたは索引セグメント
オブジェクト・タイプに従って、表 9-3 の決定マトリックスを見当してください。
7. 必要なリカバリの処置を決定する
この時点では、ローカルなリカバリが可能であるか、または強制データベース・フェイルオーバーまたはサイト・フ
ェイルオーバーが唯一使用可能な解決方法であるかが決定されています。ローカルなオブジェクト・リカバリを使用
できる場合は、決定マトリックス表を使用して、オブジェクト・リカバリに対して行う最終的な処置を決定してくだ
さい。
たとえば重要なアプリケーション表が誤って（ユーザー・エラーによって）削除され、できるだけ迅速にリカバリす
る必要があるとします。
このような場合には、表をローカルに再作成する方法はありませんが、設定されているラグのためにスタンバイ・デ
ータベースに対して誤りは適用されません。次の決定マトリックスに従うと、ユーザー・エラーの後では、データベ
ース強制フェイルオーバーを実行し、仮トランザクションを手動で再実行するのが適切な処置になります。
表9-3: 表または索引のオブジェクト・リカバリに対する決定マトリックス
表または索引のオブジェクト・リカバリに対する決定マトリックス
問題
ソフト破損
または
論理的な破損
ユーザー・
エラー
メディアの
破損
アクセスの
緊急性
イベントから
の時間
スタンバイの
問題
ローカル・
リカバリの
コスト
アクション
緊急ではない
−
−
−
後でローカルにリカバリする
緊急
ラグの範囲外
あり
高い
すぐローカルにリカバリする
ラグの範囲内
あり
−
すぐローカルにリカバリする
−
−
低い
すぐローカルにリカバリする
ラグの範囲外
なし
高い
データベース・フェイルオーバ
ー
ラグの範囲内
なし
高い
強制データベース・フェイルオ
ーバー
緊急ではない
−
−
後でローカルにリカバリする
緊急
ラグの範囲外
−
すぐローカルにリカバリする
−
低い
すぐローカルにリカバリする
ラグの範囲内
高い
強制データベース・フェイルオ
ーバー
緊急ではない
−
後でローカルにリカバリする
緊急
高い
データベース・フェイルオーバ
ー（場合によってはデータベー
ス・スイッチオーバーが可能）
低い
すぐローカルにリカバリする
この決定マトリックスでは、適切なリカバリ・プロセスを決定するために、4 つの基準（アクセスの緊急性、イベントか
らの時間、スタンバイの問題、ローカル・リカバリのコスト）を評価する必要があります。基準については、表 9-4 で説
明しています。
Maximum Availability Architecture
9-16
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
表9-4: オブジェクト・リカバリの決定基準の説明
基準
説明
有効な値
値の説明
アクセスの
緊急性
アプリケーションが、どの程度早急にオブジェ
クトにアクセスする必要があるか
緊急（すぐ）
リストアに必要な時間内にオブジ
ェクトにアクセスする
緊急ではない
（後で）
リストアに必要な時間内には、オ
ブジェクトにアクセスされない
イベントからの 問題の発生および手順 0 から何時間が経過して
時間
いるか。この時間は、問題が発生してからの時
間であり、問題が検出されてからの時間ではあ
りません。
ラグの範囲外
イベントが発生してからの時間
が、スタンバイ・ラグ、および本
番の UNDO 保存期間を超えている
ラグの範囲内
イベントが発生してからの時間
が、スタンバイ・ラグ、または本
番の UNDO 保存期間の範囲内であ
る
スタンバイ・デ スタンバイに対して問題がすでに伝播している
ータベースの問 か。この場合には、問題が発生した時間を簡単
題
に判断することは不可能で、問題がすでにスタ
ンバイへ伝播しているかどうかを確認すること
が重要になります。
あり
スタンバイでも問題が確認できる
×
問題はスタンバイでは確認されて
いない。
スタンバイ・データベースを読込
み専用モードでオープンするか、
または関連するデータ・ファイル
で DBVERIFY プロセスを実行し
て検証します。
ローカルなリカ スタンバイ・データベースにフェイルオーバー 高い
バリまたは再作 し、新しいスタンバイを再作成する場合のコス
成のコスト
トに比べて、ローカル・リカバリのコストはど
うか。これは「オブジェクトの可用性の重大さ」
基準において暗黙的に仮定されているビジネ
低い
ス・コストではなく、リカバリの実現可能性、
必要なリソース、およびパフォーマンスと処理
の合計時間に対する影響におけるコストです。
ローカル・リカバリのコストには次のものが含
同じ
まれます。
•
•
有効なソースのオブジェクトをリストアお
よびリカバリするための時間
次のような、他の従属オブジェクトをリカバ
リするための時間
索引
制約
（主キー、外部キー、および他の制約）
関連表と索引、およびその制約
オブジェクトをローカルに再作成
するコストは、フェイルオーバー
および再度インスタンス化した場
合に比べて非常に高くなります。
ローカルな再作成を行うためのコ
ストは、フェイルオーバーおよび
再度インスタンス化した場合に比
べて低くなります。
コストの要因が違っても、コスト
はほとんど変わりません。
ローカル・リカバリのコストが「低
い」および「同じ」場合は、同様
の処置を採用します。これは、こ
のケースでは現行のデータベース
上に保持しておいて、クライアン
ト・フェイルオーバーに伴うリス
クを回避する方が安全性が高くな
るためです。
このオブジェクトに基づいているディク
ショナリ・オブジェクト（再作成および
再検証）
•
リソース（ディスク領域、データ/索引の表領
域、一時表領域など）の可用性
•
オブジェクトが欠落することによる、現行の
通常のアプリケーションにおけるパフォー
マンスと機能への影響
•
オブジェクトを再作成することによる、現行
の通常のアプリケーションにおけるパフォ
ーマンスと機能への影響
Maximum Availability Architecture
9-17
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
9.5.2
ローカルなオブジェクト・リカバリのソリューション
前の項の決定マトリックスで強調表示されている有効なソリューションには、ロールの推移とローカル・オブジェクト・
リカバリが含まれています。ロールの推移については、この章の以降の項で詳しく説明します。この項では、索引および
表のオブジェクトに対するローカル・オブジェクト・リカバリのソリューションについて説明します。
表9-5: ローカル・オブジェクト・リカバリのソリューション
オブジェクト・
タイプ
リカバリの方法
コメント
索引
索引を削除する
メディア破損によって再作成が必要な小さい索引に対して
は、有効です。索引をオンラインで作成すると、ベース・オブ
ジェクトを組み合せて使用できます。
索引をオンラインで作成する
RMAN のブロック・メディア・リ RMAN のバックアップが有効で、ブロック・メディア・リカバ
カバリ
リが使用できる場合には有効。これは、バックアップをオンラ
インで使用可能で、破損したブロックが特定されており、あま
り広範囲に及んでいない場合には、最も簡単ですぐに使用でき
るソリューションです。
表
フラッシュバック問合せ
ユーザー/アプリケーション・エラーによる問題が、本番で指
定されている UNDO_RETENTION 時間内に検出された場合は
有効。このソリューションを適切に使用するには、すべての従
属オブジェクトの影響を理解する必要があります。
スタンバイから再作成する
表の再作成、または特定行の更新が必要な場合は、スタンバイ
からデータを取得する方法が考えられます。スタンバイは読込
み専用モードでオープンしておく必要があります。データを転
送するための実際のメカニズムには、スタンバイからのエクス
ポートおよび本番へのインポート、ファイルへのダンプと本番
での再起動が含まれます。また他の方法として、データベー
ス・リンクを挿入する、SQL*Loader を使用するなどの方法も
あります。
ローカルに再作成する
表が主にルックアップ表であるか、または表を再作成しデータ
を挿入するためのスクリプトの準備ができている場合は、表を
単純に削除して再作成するのが最も高速な方法です。
RMAN のブロック・メディア・
リカバリ
RMAN のバックアップが有効で、ブロック・メディア・リカバ
リが使用できる場合には有効。これは、バックアップをオンラ
インで使用可能で、破損したブロックが特定されており、あま
り広範囲に及んでいない場合には、すぐに使用できる最も簡単
なソリューションです。メディアが物理的に破損していない場
合、または問題がユーザーまたはアプリケーション・エラーに
よるものではない場合は適していません。
DBMS_REPAIR
オブジェクト・レベルで使用する場合は有効。ブロックが不正
であることをマークし、オブジェクト・レベルで破損ブロック
をスキップするようにできます。破損したブロックを将来的に
リカバリするときに、ブロック・メディア・リカバリを使用で
きます。
この項では、次のオブジェクト・リカバリのソリューションについて説明します。
•
フラッシュバック問合せ
•
RMAN のブロック・メディア・リカバリ
•
DBMS_REPAIR パッケージ
これらの使用の詳細および例については、付録に記載されています。
Maximum Availability Architecture
9-18
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
フラッシュバック問合せ
フラッシュバック問合せは、必要なときに UNDO の適用によってデータをリストアする、Oracle のマルチバージョンの
読取り一貫性機能です。
管理者は、データベース内で UNDO をどの程度の期間保持するかの指定だけで、UNDO の保存を設定できます。フラッ
シュバック問合せを使用すると、ユーザーは様々なタイミング（今朝、昨日、先週など）で存在していたデータベースに
対して問合せできます。フラッシュバック問合せを使用すると、不要なまたは不正な DML が生成される原因となるユー
ザーまたはアプリケーションのエラーから、オブジェクトをリカバリできます。
フラッシュバック問合せを使用する場合
MAA では、（表において誤った DML 文が生成される原因となる）ユーザー・エラーまたはアプリケーション・エラー
からリカバリするときにフラッシュバック問合せを使用します。対象エラーのユーザーまたはアプリケーションが、これ
らの DML 文を発行した可能性があります。
フラッシュバック問合せを使用するための前提条件
フラッシュバック問
合せを使用するための前提条件
•
表に対する構造上の変更、または表の再配置を必要とする DDL は、ユーザーまたはアプリケーションのエラー
が発生した後は、オブジェクトで発行しないようにします。MODIFY COLUMN、DROP TABLE、または
TRUNCATE TABLE オプションを使用して ALTER TABLE 文を発行した場合は、リカバリのメカニズムとしてフ
ラッシュバック問合せを使用できます。
•
ユーザー・エラーの後で生成された UNDO の量は、
使用できる UNDO 領域よりも少なくなり、
上書きされる UNDO
はありません。UNDO_RETENTION の時間は、UNDO 情報がデータベース内で保持される最大の期間を表しま
す。指定されている UNDO_RETENTION 時間に関係なく、生成された UNDO の量が使用できる UNDO 領域を超
えた場合は、UNDO が上書きされ、元に戻れる時間の量が少なくなる場合があります。
•
データベースでデータの整合性を保持するには、エラーの原因となる処理について知っておくことが有効な前提
条件となります。具体的には次のものがあります。
適切な時間またはエラーの SCN
ユーザー・エラーの原因
特定のオブジェクトにおいてユーザー・エラーの原因となるすべての変更
DML によって生成される二次的な影響（特定のオブジェクトに基づいたトリガーによるもの）。他のオブ
ジェクトが影響されている場合もあるため、データの整合性を保持するためにも、このことについて認識し
ておく必要があります。
オブジェクトがフラッシュバックされた場合の、依存関係をすべて理解する
オブジェクトがフラッシュバックされた場合に、現行のデータで使用されるトランザクションおよびそれら
の影響についてすべて理解する
•
アプリケーションが、特定のオブジェクトに関する問題によって影響を受けるすべてのオブジェクトについて、
影響を分析を行うための、正確なデータ・モデルとトランザクション・モデルを定義することが重要です。
•
影響を受けるオブジェクトのサイズ、および変更の量を少量にして、オブジェクトまたは影響を受けた行を再作
成およびリカバリします。
Maximum Availability Architecture
9-19
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
有効なプラクティス
• UNDO_RETENTION 時間は、過去へフラッシュバックするために割り当てられている時間に基づいて設定します。
ユーザー・エラーからのローカル・リカバリが適しているインストレーションもありますが、これはスタンバイ・
ラグよりも時間が長くなります。スタンバイへのフェイルオーバーの方が適している場合は、
UNDO_RETENTION 時間をスタンバイ・ラグよりも短くします。
UNDO_RETENTION 時間を調整する方法は、「データベース構成」を参照してください。
•
UNDO 表領域のサイズ調整は、UNDO_RETENTION 時間の設定、および（平均の UNDO 生成レートではなく）
ピーク間隔で生成された UNDO の量に基づいて行ってください。UNDO 表領域のサイズ調整、および UNDO 領
域の使用率の監視についての詳細は、『Oracle9i データベース管理者ガイド』を参照してください。
•
大容量のオブジェクトで、変更の範囲がわかっている場合は、影響を受けた行についてのみ、フラッシュバック
問合せでアクセスおよび修正できるよう設定することをお薦めします。小容量のオブジェクトでは、表全体、お
よびその索引と従属オブジェクトを作成し、元の表を新しい表で置き換える方が適切です。
•
影響を受けたオブジェクトを新しいオブジェクトとして再作成する場合は、すべての制約、トリガー、ビュー、
シノニム、および権限付与を新しいオブジェクト上で再作成する必要があります。特定のオブジェクトについて、
すべての DDL 関連のものを使用できるようにします。オブジェクト・リポジトリを使用すると、これらの管理
が簡単になります。
•
トランザクションの一部として表の更新を行う場合は、タイム・スタンプではなく SCN に基づいてフラッシュ
バック問合せを行うことをお薦めします。これは、トランザクションに関連するすべての表に対して行います。
•
次のようにすると、UNDO_RETENTION 時間の制限を超えたり、調整することが可能です。
新しい UNDO 表領域を作成する。
次のコマンドを発行して、インスタンスに対する UNDO 表領域を変更する。
ALTER SYSTEM SET UNDO_TABLESPACE=<new_tablespace>;
インスタンスは、新しいすべてのトランザクションに対してこの新しい UNDO 表領域を使用します。フラッ
シュバック問合せで必要な UNDO 情報は、元の UNDO 表領域に保持されます。これは新しいトランザクシ
ョンでは使用されません。古い UNDO 表領域の情報は、表領域の削除まで、または古い表領域の切替えまで
上書きされません。
RMANのブロック・メディア・リカバリ
のブロック・メディア・リカバリ
ブロック・メディア・リカバリ（BMR）は、破損した 1 つのデータ・ブロック、またはデータ・ファイル内のデータ・
ブロック・セットをリカバリします。少数のブロックでメディア・リカバリが必要な場合は、データ・ファイル全体では
なく、影響を受けた特定のブロックのみをリストアおよびリカバリできます。これにより、リカバリが必要なブロックの
みがリストアされ、破損したブロックのみがリカバリされるため、平均リカバリ時間（MTTR）が短くなります。ブロッ
ク・メディア・リカバリは、REDO アプリケーションの時間を最少にし、リカバリの際の I/O オーバーヘッドを回避しま
す。また、ブロックのリカバリ中も、影響を受けたデータ・ファイルをオンラインで保持できるようにします。
詳細は、『Oracle9i Recovery Manager ユーザーズ ガイド』の第 6 章を参照してください。
ブロック・メディア・リカバリを使用する場合
MAA では、無効とみなされ、Oracle によって破損のマークが付けられているブロックを持つオブジェクトをリカバリす
る場合に、ブロック・メディア・リカバリを使用します。ブロック・メディア・リカバリを使用すると、処理を停止させ
ずにすべてのデータを保存したまま、このようなブロックをオンラインでリカバリできます。これは、少量のブロックで
メディア・リカバリを必要とする場合には、適切な方法です。データ・ファイルの大部分が破損している場合は、フェイ
ルオーバーするか、またはデータ・ファイルを完全にリカバリする方が適切です。ブロック・リカバリは、破損のマーク
が付けられたブロックで、完全なリカバリが試行される場合のみ実行できます。論理的な破損の原因となるユーザー・エ
Maximum Availability Architecture
9-20
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
ラーやソフトウェア・バグからリカバリする場合、または破損 REDO の原因となる変更からリカバリする場合には、ブ
ロック・メディア・リカバリは使用できません。これは、ブロック・メディア・リカバリでは、有効なすべての REDO
をリカバリ中のブロックに適用しなければならないためです。
ブロック・メディア・リカバリを使用するための前提条件
•
ブロック・メディア・リカバリは、RMAN でのみ使用できます。ただし、ユーザー管理のデータ・ファイルおよ
びアーカイブ REDO ログのバックアップがカタログされている場合は、ブロック・メディア・リカバリのメリッ
トを使用するために RMAN 特有のバックアップは必要ありません。
•
RMAN をバックアップ・メカニズムとして使用している場合は、完全な RMAN バックアップが存在するように
します。増分バックアップは使用できません。
•
ブロック・メディア・リカバリでは、ブロックがリカバリされるデータ・ファイルの適切なバージョン、および
バックアップ以降のすべてのアーカイブ REDO ログが必要になります。ブロック・メディア・リカバリは、ブロ
ック上で完全なリカバリを行います。
有効なプラクティス
•
ブロック・メディア・リカバリを使用する場合は、使用する RMAN バックアップおよびアーカイブ・ログをロ
ーカルに使用します。
•
アーカイブ REDO ログに不明な REDO があっても、ブロックが当座の間更新され、不明な REDO で特定のブロ
ックに対して変更されていない場合は、ブロック・メディア・リカバリは継続して機能します。
•
RMAN ブロックの検証が事前に行われた場合は、RMAN によって破損とみなされたブロックのリストが
V$DATABASE_BLOCK_CORRUPTION ビューに定義されます。これは、ブロック・メディア・リカバリによっ
て事前にリカバリできます。
DBMS_REPAIRパッケージ
パッケージ
DBMS_REPAIR は、表および索引で破損しているブロックを検出し、修復するためのパッケージ化された手順です。こ
のアプローチを使用して、可能な場合は破損に対処し、再作成または修復を試行しながらオブジェクトを継続して使用で
きるようにします。
詳細、および制限事項については、『Oracle9i データベース管理者ガイド』の第 22 章「データ・ブロック破損の検出と
修復」を参照してください。
DBMS_REPAIRを使用する場合
DBMS_REPAIR パッケージを使用して、破損したブロックをオブジェクト・レベルで検出および修復できます。
DBMS_REPAIR パッケージはブロックを修正しようとします。ブロックが修復不可能な場合は、ソフト破損としてマー
クされます。
もう 1 つの手順では、表に対してこれ以降にアクセスすると、これらのソフト破損ブロックがスキップされるようにでき
ます。これらのブロックは、BMR の使用後にリカバリできることに注意してください。
表および索引データが含まれているブロックでは、DBMS_REPAIR パッケージしか使用できません。DBMS_REPAIR パ
ッケージは、他のデータベース・ブロックでは使用できません。
破損が広範囲に及んでいる場合は、データベースのフェイルオーバーを発行するか、またはファイルをリストアして、メ
ディア・リカバリを発行します。
修復はオブジェクト・レベルで行うため、特定のオブジェクトが他のオブジェクトに対して論理的に従属していることも
考慮する必要があります。また、修復によってデータが損失する場合もあります。
Maximum Availability Architecture
9-21
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
有効なプラクティス
•
REPAIR_TABLE および ORPHAN_KEYS_TABLE の表は、事前の作成が可能です。これにより、必要になった際
に作成することはありません。
•
SKIP_TABLE オプションは、明示的に解除されるまで設定されません。SKIP_TABLE オプションが
（DBMS_REPAIR.SKIP_TABLE プロシージャによって）オンに設定されていると、表および索引のスキャンで、
検出された破損ブロックは（最初の停止後に破損したブロックも含めて）すべて継続してスキップされます。こ
のオプションはできるかぎり早急に解除してください。これらの表は、なるべく早期の再作成をお薦めします。
ある表に対して SKIP_TABLE オプションが設定されていることを検証するには、次の SQL コマンドを使用しま
す。
SELECT SKIP_CORRUPT FROM DBA_TABLES WHERE TABLE_NAME = table_name,
Maximum Availability Architecture
9-22
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
9.6
データベース・サーバー層 - RACフェイルオーバーおよび透過的
フェイルオーバーおよび透過的アプ
フェイルオーバーおよび透過的アプ
リケーション・フェイルオーバー
リケーション・フェイルオーバー
RAC および透過的アプリケーション・フェイルオーバー（TAF）は、本番のホストまたはインスタンスにおける停止の
影響をゼロにするか、または軽減します。
自動のインスタンス・リカバリおよび事前に設定したクライアント・フェイルオーバーによって、クライアントはサービ
スが中断したことに気が付きません。
RAC インスタンス 1 でハードウェアまたはソフトウェアの障害が発生すると、クライアントは、接続時フェイルオーバ
ー（新しい接続）、または Oracle Net の透過的アプリケーション・フェイルオーバー（既存の接続）を使用して RAC イ
ンスタンス 2 へ再接続します。
TAF などのアプリケーション・フェイルオーバー機能とともに RAC を使用している場合は、エンド・ユーザーまたはア
プリケーション・サーバーに対してインスタンスまたはノードの障害は提示されません。自動のアプリケーション・フェ
イルオーバー機能は、残りの有効なインスタンスに対して接続を透過的に再度ルーティングし、障害時に実行中だった問
合せを再実行します。このリジリエンスのレベルは、アプリケーションで OCI ライブラリのリリース 8 以降を使用して
いる場合は、特別なアプリケーションをコーディングせずに実現されます。
複数のアドレスに対して接続時フェイルオーバーおよびクライアント・ロード・バランシングを使用して TAF を実装し
ます。次の例では、Oracle Net が sales1-server または sales2-server のプロトコル・アドレスのいずれかにランダムにアクセ
スします。接続後にインスタンスが失敗すると、TAF アプリケーションは他のノードのリスナーにフェイルオーバーし
ます。
sales.us. acme.com=
(DESCRIPTION=
(LOAD_BALANCE=on)
(FAILOVER=on)
(ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=sales.us.acme.com)
(FAILOVER_MODE=
(TYPE=session)
(METHOD=basic)
(RETRIES=20)
(DELAY=15))))
新しいデータベースへの接続
新しいクライアントは、
sales1-server と sales2-server 上でリスニングしているリスナー間で接続をランダムに要求します。
リスナーに対する最初の接続が失敗すると、接続時フェイルオーバーによって、クライアントが各プロトコル・アドレス
の成功する、ランダムに接続を試行します。
既存のデータベースへの接続
TAF は同じ接続文字列を使用して、自動的に接続を再確立します。
TAF には、RETRIES および DELAY パラメータで最初の再接続の試行が失敗した場合に、自動的に接続を再試行する機
能があります。この例では、Oracle Net が sales1-server または sales2-server のリスナーに再接続しようとします。フェイル
オーバー接続が失敗した場合は、Oracle Net は 15 秒待機してから再度接続を試行します。Oracle Net は最大 20 回まで再
接続を試行します。
Maximum Availability Architecture
9-23
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
9.7
データベース・サーバー層 - Data Guardス
スイッチオーバー
Oracle Data Guard では、
保護サイトの計画停止と計画外停止を処理するために、
使いやすい方法を 2 通り用意しています。
これらの方法はスイッチオーバーとフェイルオーバーと呼ばれるもので、SQL を使用して簡単に開始できます。
スイッチオーバーは、プライマリ・データベースで計画的なメンテナンスに、プライマリ・データベースとスタンバイ・
データベースのロールを計画的に反転させます。スイッチオーバーの操作では、データベースを再度インスタンス化する
必要はありません。そのため、プライマリ・データベースをほとんど瞬時にスタンバイ・データベースのロールに移行さ
せることができます。したがって、計画的保守をこれまで以上に容易にかつ頻繁に行うことが可能になります。たとえば、
プライマリ・サイトでハードウェアをアップグレードする際、スイッチオーバーを利用して、すべてのデータベース・ク
ライアントをスタンバイ・サイトに切り替えることにより、プライマリ・サイトでアップグレードを実行できます。
表9-6: Oracle Data Guardスイッチオーバーの決定マトリックス
スイッチオーバーの決定マトリックス
Data Guard の可用性
スイッチオーバー
フィジカル・スタンバイ・データベースのみ
フィジカル・スタンバイ・データベースのスイッチオーバー
ロジカル・スタンバイ・データベースのみ
ロジカル・スタンバイ・データベースのスイッチオーバー
フィジカルおよびロジカルのスタンバイ・
データベース
フィジカル・スタンバイ・データベースのスイッチオーバー
•
Data Guard のスイッチオーバーの概要
•
フィジカル・スタンバイ・データベースのスイッチオーバー
•
ロジカル・スタンバイ・データベースのスイッチオーバー
9.7.1
Data Guardのスイッチオーバーの概要
のスイッチオーバーの概要
Oracle Data Guard のスイッチオーバーは計画されたトランザクションで、スタンバイ・データベースと本番データベース
間でロールを切り替えるための一連の手順が含まれています。このため、スイッチオーバーの処理が成功した後では、ス
タンバイ・データベースは、本番のロールおよび本番データベースがスタンバイ・データベースであるとみなします。
RAC 環境では、スイッチオーバーは、本番とスタンバイの各データベースに対して 1 つのインスタンスのみをアクティ
ブにしておく必要があります。データベースのロール管理の範囲では、「スイッチ・バック」という語が使用されること
もあります。スイッチ・バックの処理は、単にロールを元のステートに戻すためのスイッチオーバーということになりま
す。
Data Guardのスイッチオーバーを使用する場合
のスイッチオーバーを使用する場合
スイッチオーバーは計画された操作で、本番およびスタンバイのデータベース間で、データベースをインスタンス化せず
にデータベース・ロールを切り替えることができます。本番データベースが開始されたとき、ターゲットのスタンバイ・
データベースが使用できるとき、アーカイブ REDO ログが使用できるときには、常にスイッチオーバーを行うことが可
能です。これは次の状況で、非常に有効です。
•
本番ホストにおいて、ハードウェアのメンテナンス（ハードウェアまたはファームウェアのパッチ）などのスケ
ジュールされたメンテナンスを行う場合
•
本番データベースがオープンしているときに、データの障害を解決する場合
•
障害時リカバリの準備ができているかのテストに、セカンダリ・リソースのテストおよび検証を行う場合
Maximum Availability Architecture
9-24
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
Data Guardのスイッチオーバーを使用しない場合
のスイッチオーバーを使用しない場合
元の本番データベースにまだアクセスできる場合は、最初に Oracle Data Guard のスイッチオーバーを検討します。フェイ
ルオーバーでは、最初の本番データベースを新しいスタンバイ・データベースとして再度インスタンス化の必要がありま
すが、これは非常にコストが高くなります。ただし、スイッチオーバーが使用できない、または実用的ではない場合とし
て次のケースが考えられます。
•
アーカイブ REDO ログが不明
•
Point-in-Time リカバリが必要
•
本番データベースがオープンしていなくて、オープンできない
オブジェクト・リカバリ・ソリューションにより、迅速で効率のよい方法が提供される場合は、Data Guard のスイッチオ
ーバーを使用しないでください。
9.7.2
フィジカル・スタンバイ・データベースのスイッチオーバー
•
フィジカル・スタンバイ・スイッチオーバーの準備
•
フィジカル・スタンバイ・データベースのスイッチオーバー手順とベスト・プラクティス
•
フィジカル・スタンバイ・データベース: スイッチオーバー後の手順
フィジカル・スタンバイ・スイッチオーバーの準備
フィジカル・スタンバイ・スイッチオーバーの開始前に、現在の状況を評価し、スイッチオーバーが可能かどうか判断す
る必要があります。次の項で、スイッチオーバーを確実にするため、事前に必要な手順を説明します。
•
スイッチオーバーの準備手順 1: ログ転送サービスのステータスを確認する
•
スイッチオーバーの準備手順 2: 本番とスタンバイのデータベース間のアーカイブ・ギャップを調べる
•
スイッチオーバーの準備手順 3: 現行のオンライン REDO ログの順序番号およびスタンバイ・リカバリの
順序番号を記録する
•
スイッチオーバーの準備手順 4: （1 つを除いて）本番およびスタンバイのすべてのインスタンスを
シャットダウンする
•
スイッチオーバーの準備手順 5: 残りのアクティブな本番インスタンスでアクティブなセッションを停止する
•
スイッチオーバーの準備手順 6: 本番データベースでスイッチオーバー・ステータスを確認する
スイッチオーバーの準備手順1: ログ転送サービスのステータスを確認する
1.
本番データベースで次の問合せを実行します。
SELECT INST_ID, DEST_ID, DEST_NAME, NAME_SPACE, STATUS,
LOG_SEQUENCE, TYPE, PROCESS, REGISTER, ERROR
FROM GV$ARCHIVE_DEST
WHERE STATUS != ‘INACTIVE’ AND TARGET=’STANDBY’
ORDER BY INST_ID, DEST_ID;
2.
VALID ステータスを調べ、エラーがないことを確認します。ログ転送サービスが機能していない場合は、Oracle
Net のエイリアス（tnsping エイリアス）を確認し、SQL*Plus を使用して手動で接続することによってトラブルシ
ューティングします（sqlplus username/password@alias）。
3.
スイッチオーバーの前に、ログ転送サービスが機能していることを確認します。
Maximum Availability Architecture
9-25
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
4.
スタンバイ・アラート・ログにも、スタンバイ・オンライン REDO ログのオープンおよびシーケンスの書込みに
関するメッセージがあります。たとえば次のようになります。
RFS: Successfully opened standby logfile
スイッチオーバーの準備手順2: 本番とスタンバイのデータベース間のアーカイブ・ギャップを
調べる
本番の V$ARCHIVE_DEST_STATUS で保護モードを確認すると、保護モード、または RESYNCHRONIZATION が示
されます。これにはアーカイブ・ギャップも含まれています。次のようにして、スタンバイ宛先（この場合は
log_archive_dest_2）の保護モードを確認します。
SELECT PROTECTION_MODE
FROM V$ARCHIVE_DEST_STATUS
WHERE DEST_ID=2;
本番データベースで次の問合せを実行し、どのアーカイブ REDO ログがスタンバイ・データベースへ届いていない
かを判断します。
SELECT LOCAL.THREAD#, LOCAL.SEQUENCE#
FROM (SELECT THREAD#, SEQUENCE#
FROM V$ARCHIVED_LOG
WHERE DEST_ID=1) LOCAL
WHERE LOCAL.SEQUENCE# NOT IN
(SELECT SEQUENCE# FROM V$ARCHIVED_LOG
WHERE DEST_ID=2 AND THREAD# = LOCAL.THREAD#);
アーカイブ・ギャップがある場合は、アーカイブ REDO ログを直接コピーし、それをスタンバイ・データベースへ
登録します。『Oracle9i Data Guard 概要および管理』の付録 B.3「Resolving Archive Gaps Manually」を参照してくだ
さい。
通常、これは自動ギャップ検出によって自動的に行われます。
スイッチオーバーの準備手順3: 現行のオンラインREDOログの順序番号およびスタンバイ・リカ
バリの順序番号を記録する
デバッグを行う場合に備え、現行のオンライン REDO ログの順序番号およびスタンバイ・リカバリの順序番号を記
録します。
本番データベースでは次の文を実行します。
SELECT THREAD#, SEQUENCE#
FROM V$LOG
WHERE STATUS='CURRENT';
スタンバイ・データベースでは次の文を実行します。
SELECT THREAD#, MAX(SEQUENCE#)
FROM V$LOG_HISTORY
GROUP BY THREAD#;
Maximum Availability Architecture
9-26
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
スイッチオーバーの準備手順4: （1つを除いて）本番およびスタンバイのすべてのインスタンス
をシャットダウンする
をシャッ
トダウンする
1 つを除いてすべてのインスタンスをシャットダウンした後、本番およびスタンバイで次の問合せを実行して、他の
インスタンスがアクティブになっていないことを確認します。
SELECT INSTANCE_NAME, HOST_NAME
FROM GV$INSTANCE
WHERE INST_ID <>
(SELECT INSTANCE_NUMBER FROM V$INSTANCE);
通常は行は返されませんが、なんらかの行が返された場合は、それらのインスタンスをシャットダウンしてください。
SWITCHOVER TO STANDBY および SWITCHOVER TO PRIMARY で他のインスタンスをアクティブにしようとする
と、次のエラーが発生します。
ORA_01105: mount is incompatible with mounts by other instances
スイッチオーバーの準備手順5: 残りのアクティブな本番インスタンスでアクティブなセッショ
ンを停止する
次の問合せを実行して、アクティブなセッションを特定します。
SELECT SID, PROCESS, PROGRAM
FROM V$SESSION
WHERE TYPE = 'USER'
AND SID <> (SELECT DISTINCT SID FROM V$MYSTAT);
スイッチオーバーを回避する一般的な処理は次のとおりです。
•
CJQ0（ジョブの Queue Scheduler Process）
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;で CJQ0 を停止する
•
QMN0（Advanced Queue Time Manager）
ALTER SYSTEM SET AQ_TM_PROCESSES=0;で QMN0 を停止する
•
DBSNMP（Oracle Enterprise Manager の Intelligent Agent）
OS レベルで AGENTCTL STOP コマンドを発行する
処理を手動で停止するかわりに、「Switchover_Step_2」のスイッチオーバー・コマンドの WITH SESSION SHUTDOWN
オプションを使用できます。
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN;
スイッチオーバーの準備手順6: 本番データベースでスイッチオーバー・ステータスを確認する
次の文を入力します。
SELECT SWITCHOVER_STATUS FROM V$DATABASE;
Maximum Availability Architecture
9-27
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
フィジカル・スタンバイ・データベースのスイッチオーバー手順と
ベスト・プラクティス
Oracle9i Database Release 2 の Data Guard Broker は RAC をサポートしないため、現行の Data Guard GUI のかわりに簡単な
一連の手順が必要です。Oracle Database 10g では Data Guard Broker で RAC をサポートするため、これらの手動の手順で
スイッチオーバーを実行するのではなく、Data Guard Manager（OEM GUI）の使用をお薦めします。この項では、スイッ
チオーバーを実装する詳細手順、および各手順を確認するカラム監視において、予想されるデータベースのアラート・ロ
グの出力について重点的に説明します。具体的には、次の項があります。
•
スイッチオーバーの手順 1: スイッチオーバーの準備手順が完了していることを確認する
•
スイッチオーバーの手順 2: 現在の本番データベースをスタンバイ・データベースへスイッチオーバーする
•
スイッチオーバーの手順 3: 新しいスタンバイ・データベースを開始する
•
スイッチオーバーの手順 4: スイッチオーバーのステータスを確認し、必要な場合はリカバリを終了する
•
スイッチオーバーの手順 5: 以前のスタンバイ・データベースから本番データベースに変換する
•
スイッチオーバーの手順 6: すべてのインスタンスを再開する
スイッチオーバーの準備手順が完了していることを確認する
スイッチオーバーの手順1: スイッチオーバーの準備手順が完了
していることを確認する
「Data Guard のスイッチオーバーを準備する」を参照してください。スイッチオーバーの正常な完了には、必ず準備
を行います。
スイッチオーバーの手順2: 現在の本番データベースをスタンバイ・データベースへ
スイッチオーバーする
現在の本番インスタンスで、次の文を実行します。
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY [WITH SESSION SHUTDOWN];
この文によって、次の処理が行われます。
•
プライマリ・データベースがクローズし、アクティブなセッションがすべて終了する
•
アーカイブされていない REDO ログがすべてアーカイブされ、スタンバイ・データベースへ適用される
•
アーカイブ中の最後のログ・ファイルのヘッダーに、end-of-redo のマーカーが追加される
•
現行の制御ファイルのバックアップが作成される
•
現行の制御ファイルがスタンバイ制御ファイルに変換される
本番のアラート・ログに次のメッセージが表示されます。
Media Recovery End-Of-Redo indicator encountered
Media Recovery Applied until change <SCN>
MRP0: Media Recovery Complete: End-Of-REDO
Resetting standby activation ID <activation-id>
MRP0: Background Media Recovery process shutdown
…
Switchover: Complete - Database shutdown required
Completed: alter database commit to switchover to standby
Maximum Availability Architecture
9-28
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
スタンバイのアラート・ログに次のメッセージが表示されます。
Identified end-of-REDO for thread 1 sequence <sequence#>
Media Recovery Log <archive log file name>
Identified end-of-REDO for thread 2 sequence <sequence#>
Media Recovery End-Of-Redo indicator encountered
Media Recovery Applied until change <SCN>
MRP0: Media Recovery Complete: End-Of-REDO
Resetting standby activation ID <activation-id>
MRP0: Background Media Recovery process shutdown
スイッチオーバーの手順3: 新しいスタンバイ・データベースを開始する
新しい本番インスタンスを開始し、新しいスタンバイに対してログ転送サービスを無効にして、インスタンスを手動
でリスナーに登録します。
SHUTDOWN IMMEDIATE
STARTUP NOMOUNT
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=MEMORY;
RECOVER MANAGED STANDBY DATABASE DISCONNECT;
ALTER SYSTEM REGISTER;
スイッチオーバーの手順
スイ
ッチオーバーの手順4: スイッチオーバーのステータスを確認し、必要な場合は
リカバリを終了する
現在のスタンバイ・インスタンスで、次の文を実行します。
SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS=’TO PRIMARY’の場合は、「スイッチオーバーの手順 5」へ進みます。
SWITCHOVER_STATUS=’SWITCHOVER PENDING で、必要な次の順序番号がスタンバイのオンライン REDO ログ
にある場合は、これでも適切ですが、次の処理を行った方がより安全です。
RECOVER MANAGED STANDBY DATABASE CANCEL;
RECOVER MANAGED STANDBY DATABASE NODELAY DISCONNECT;
アラート・ログの例
Media Recovery Log <archive log file name>
Media Recovery Log <archive log file name>
Identified end-of-REDO for thread 1 sequence <sequence#>
Media Recovery Log <archive log file name>
Identified end-of-REDO for thread 2 sequence <sequence#>
Media Recovery End-Of-Redo indicator encountered
Media Recovery Applied until change <SCN>
MRP0: Media Recovery Complete: End-Of-REDO
Resetting standby activation ID <activation-id>
MRP0: Background Media Recovery process shutdown
アラート・ログを調べ、リカバリが処理中かどうか確認します。TO PRIMARY になるまで、スイッチオーバーのス
テータスを問い合せます。
Maximum Availability Architecture
9-29
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
スイッチオーバーの手順5: 以前のスタンバイ・データベースから本番データベースに変換する
現在のスタンバイ・インスタンスで、次の文を実行します。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
この文によって、次の処理が行われます。
•
最後のアーカイブ REDO ログ・ファイルが受信され、スイッチオーバー（end-of-redo）マーカーを介して確
実に適用される。これらの処理が行われない場合は、Data Guard によってエラーが返される。
•
読込み専用トランザクションに対してオープンしていない場合は、データベースをクローズする。
•
スタンバイ制御ファイルが現行の制御ファイルに変換される。
文がエラーなしで終了した場合は、「スイッチオーバーの手順 6」へ進みます。この手順が正常に終了したことは、
次のアラート・ログのメッセージによって示されます。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
RESETLOGS after incomplete recovery UNTIL CHANGE SCN 239480106
…
Switchover: Complete - Database shutdown required
Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
次のエラー
ORA-01105: mount is incompatible with mounts by other instances
が表示された場合は、他のスタンバイ・インスタンスがまだアクティブになっていることを示します。これらのスタ
ンバイ・インスタンスをシャットダウンし、ALTER DATABASE 文を再発行します。
スイッチオーバーの手順6: すべてのインスタンスを再開する
新しいインスタンスをシャットダウンし、そのインスタンスおよびその他のすべてのインスタンスを再開します。
SHUTDOWN IMMEDIATE
STARTUP
ここでは、データベース・ロールはスイッチされていません。残りのサイト・フェイルオーバーを実行する前に、「ス
イッチオーバー後の手順」に記載されている環境を確認してください。
フィジカル・スタンバイ・データベース:
フィジカル・スタンバイ・データベース スイッチオーバー後の手順
スイッチオーバーの後では、データベースの保護モードが同じになっています。スイッチオーバーの後で、リカバリおよ
びアーカイブがエラーなしで行われていることを確認してください。
次の項では、スイッチオーバー後の手順について説明します。
•
スイッチオーバー後の手順 1: スタンバイ・データベースのオンライン REDO ログ・グループをクリアする
•
スイッチオーバー後の手順 2: 本番データベースでローカルおよびリモートのアーカイブ宛先を確認する
•
スイッチオーバー後の手順 3: ラグが適切に設定されていることを確認する
•
スイッチオーバー後の手順 4: リカバリで新しいアーカイブ REDO ログが適用されるようにする
Maximum Availability Architecture
9-30
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
スイッチオーバー後の手順1: スタンバイ・データベースのオンラインREDOログ・グループをク
リアする
スタンバイ・データベースで次の文を入力し、オンライン REDO ログ・グループをクリアします。記載されている
とおりのオンライン REDO ログをそれぞれ、問合せからクリアします。
SELECT GROUP# FROM V$LOG;
RECOVER MANAGED STANDBY DATABASE CANCEL
ALTER DATABASE CLEAR LOGFILE GROUP 1;
ALTER DATABASE CLEAR LOGFILE GROUP 2;
ALTER DATABASE CLEAR LOGFILE GROUP 3;
ALTER DATABASE CLEAR LOGFILE GROUP 4;
RECOVER MANAGED STANDBY DATABASE DISCONNECT
スイッチオーバー後の手順2: 本番データベースでローカルおよびリモートのアーカイブ宛先を
確認する
本番データベースで、次の文を入力します。
SELECT NAME_SPACE, STATUS, TARGET, LOG_SEQUENCE, TYPE, PROCESS,
REGISTER, ERROR FROM V$ARCHIVE_DEST WHERE STATUS!='INACTIVE';
ローカルおよびリモートのアーカイブ宛先が返されます。予想される宛先が返されない場合は、アラート・ログ、お
よび V$ARCHIVE_DEST と V$ARCHIVE_DEST_STATUS のビューを調べ、エラーを確認します。
SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE STATUS!=’INACTIVE’;
スイッチオーバー後の手順3: ラグが適切に設定されていることを確認する
SELECT DELAY_MINS FROM V$ARCHIVE_DEST WHERE DEST_ID=2;
スイッチオーバー後の手順4: リカバリで新しいアーカイブREDOログが適用されるようにする
本番データベースおよびスタンバイ・データベースで次の問合せを実行します。
SELECT 'ARCHIVED LOG MAX ' || THREAD#, MAX(SEQUENCE#) FROM
V$ARCHIVED_LOG GROUP BY THREAD#;
「スイッチオーバー後の手順 1」でエラーがなかった場合は、次の問合せは、本番データベースで REDO ログがアー
カイブおよび送信されていることを示します。スタンバイおよび本番データベースの出力は、通常は一致します。
スタンバイ・データベースで次の問合せを実行します。
SELECT 'LOG HISTORY MAX ' || THREAD#, MAX(SEQUENCE#) FROM V$LOG_HISTORY
GROUP BY THREAD#;
スタンバイ・データベースで次の問合せを実行します。
SELECT 'LOG HISTORY MAX ' || THREAD#, MAX(SEQUENCE#) FROM V$LOG_HISTORY
GROUP BY THREAD#;
これは、スタンバイ・データベースで、各スレッドに対してリカバリされた最大順序番号を表します。これは、（本
番の LOG_ARCHIVE_DEST_2 DELAY 設定に基づいて遅延しているログを除いては）前の問合せの出力と一致します。
遅延しているすべてのログは、次のメッセージ形式でアラート・ログ内に示されます。
Media Recovery Delayed for thread <thread#> seq# <sequence#> until <timestamp>
『Oracle9i Data Guard 概要および管理』の項 6.4「ログ適用サービスの監視」も参照してください。
Maximum Availability Architecture
9-31
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
9.7.3
ロジカル・スタンバイ・データベースのスイッチオーバー
•
ロジカル・スタンバイ・データベースのスイッチオーバーの準備
•
ロジカル・スタンバイ・データベースのスイッチオーバー手順とベスト・プラクティス
•
ロジカル・スタンバイ・データベース: スイッチオーバー後の手順
ロジカル・スタンバイ・データベースのスイッチオーバーの準備
ロジカル・スタンバイ・スイッチオーバーを開始する前に、現在の状況を評価し、スイッチオーバーが可能かどうか判断
する必要があります。
次の項で、スイッチオーバーを確実に実行するために、事前に必要な手順について説明します。
•
スイッチオーバーの準備手順 1: ログ転送サービスのステータスを確認する
•
スイッチオーバーの準備手順 2: 本番とスタンバイのデータベース間のアーカイブ・ギャップを調べる
•
スイッチオーバーの準備手順 3: 現行のオンライン REDO ログの順序番号およびスタンバイ・リカバリの順序番
号を記録する
•
スイッチオーバーの準備手順 4: 残りのアクティブな本番インスタンスでアクティブなセッションを停止する
スイッチオーバーの準備手順1: ログ転送サービスのステータスを確認する
1.
本番データベースで次の問合せを実行します。
SELECT INST_ID, DEST_ID, DEST_NAME, NAME_SPACE, STATUS,
LOG_SEQUENCE, TYPE, PROCESS, REGISTER, ERROR
FROM GV$ARCHIVE_DEST
WHERE STATUS != ‘INACTIVE’ AND TARGET=’STANDBY’
ORDER BY INST_ID, DEST_ID;
2.
VALID ステータスを調べ、エラーがないことを確認します。ログ転送サービスが機能していない場合は、Oracle
Net のエイリアス（tnsping エイリアス）を確認し、SQL*Plus を使用して手動で接続することによってトラブルシ
ューティングします（sqlplus username/password@alias）。
3.
スイッチオーバーの前に、ログ転送サービスが機能していることを確認します。
スイッチオーバーの準備手順2: 本番とスタンバイのデータベース間のアーカイブ・ギャップを
調べる
本番の V$ARCHIVE_DEST_STATUS で保護モードを確認すると、保護モード、または RESYNCHRONIZATION が示
されます。これにはアーカイブ・ギャップも含まれています。次のようにして、スタンバイ宛先（この場合は
log_archive_dest_2）の保護モードを確認します。
SELECT PROTECTION_MODE
FROM V$ARCHIVE_DEST_STATUS
WHERE DEST_ID=2;
本番データベースで次の問合せを実行し、どのアーカイブ REDO ログがスタンバイ・データベースへ届いていない
かを判断します。
Maximum Availability Architecture
9-32
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
SELECT LOCAL.THREAD#, LOCAL.SEQUENCE#
FROM (SELECT THREAD#, SEQUENCE#
FROM V$ARCHIVED_LOG
WHERE DEST_ID=1) LOCAL
WHERE LOCAL.SEQUENCE# NOT IN
(SELECT SEQUENCE# FROM V$ARCHIVED_LOG
WHERE DEST_ID=2 AND THREAD# = LOCAL.THREAD#);
アーカイブ・ギャップがある場合は、アーカイブ REDO ログを直接コピーし、それをスタンバイ・データベースへ
登録します。『Oracle9i Data Guard 概要および管理』の付録 B.3「手動によるアーカイブ・ギャップの解決」を参照
してください。
通常、これは自動ギャップ検出によって自動的に行われます。
スイッチオーバーの準備手順3: 現行のオンラインREDOログの順序番号および
スタンバイ・リカバリの順序番号を記録する
デバッグを行う場合に備え、現行のオンライン REDO ログの順序番号およびスタンバイ・リカバリの順序番号を記
録します。
本番データベースでは次の文を実行します。
SELECT THREAD#, SEQUENCE#
FROM V$LOG
WHERE STATUS='CURRENT';
スタンバイ・データベースでは次の文を実行します。
SELECT THREAD# , SEQUENCE#
FROM DBA_LOGSTDBY_LOG LOG
, DBA_LOGSTDBY_PROGRESS PROG
WHERE PROG.APPLIED_SCN BETWEEN LOG.FIRST_CHANGE# AND LOG.NEXT_CHANGE#;
スイッチオーバーの準備手順4: 残りのアクティブな本番インスタンスでアクティブな
セッションを停止する
次の問合せを実行して、アクティブなセッションを特定します。
SELECT SID, PROCESS, PROGRAM
FROM V$SESSION
WHERE TYPE = 'USER'
AND SID <> (SELECT DISTINCT SID FROM V$MYSTAT);
スイッチオーバーを回避する一般的な処理は次のとおりです。
•
CJQ0（ジョブの Queue Scheduler Process）
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;で CJQ0 を停止する
•
QMN0（Advanced Queue Time Manager）
ALTER SYSTEM SET AQ_TM_PROCESSES=0;で QMN0 を停止する
•
DBSNMP（Oracle Enterprise Manager の Intelligent Agent）
OS レベルで AGENTCTL STOP コマンドを発行する
Maximum Availability Architecture
9-33
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
ロジカル・スタンバイ・データベースのスイッチオーバー手順とベスト・プラクティス
この項では、スイッチオーバーを実装するための詳細手順、および各手順を確認するためのカラム監視において、予想さ
れるデータベースのアラート・ログの出力について重点的に説明します。具体的には、次の項があります。
•
スイッチオーバーの手順 1: スイッチオーバーの準備手順が完了していることを確認する
•
スイッチオーバーの手順 2: 現在の本番データベースをスタンバイ・データベースへスイッチオーバーする
•
スイッチオーバーの手順 3: ログ転送サービスを無効にする
•
スイッチオーバーの手順 4: スイッチオーバーのステータスを確認し、必要な場合はリカバリを終了する
•
スイッチオーバーの手順 5: 以前のスタンバイ・データベースから本番データベースに変換する
•
スイッチオーバーの手順 6: ロジカル・スタンバイ適用を開始する
スイッチオーバーの手順1: スイッチオーバーの準備手順が完了していることを確認する
「ロジカル・スタンバイ・データベースのスイッチオーバーの準備」を参照してください。スイッチオーバーを正常
に完了させるためには、準備が必要です。
スイッチオーバーの手順2: 現在の本番データベースをスタンバイ・データベースへ
スイッチオーバーする
現在の本番インスタンスで、次の文を実行します。
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
この文によって、次の処理が行われます。
•
アクティブなセッションがすべて終了する
•
アーカイブされていない REDO ログがすべてアーカイブされ、スタンバイ・データベースへ適用される
•
アーカイブ中の最後のログ・ファイルのヘッダーに、end-of-redo のマーカーが追加される
本番のアラート・ログに次のメッセージが表示されます。
alter database commit to switchover to logical standby
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY
Checking for active hot backups
Disabling job queue processes
Waiting for transactions to complete
...
Switchover complete
Completed: alter database commit to switchover to logical sta
スイッチオーバーの手順3: ログ転送サービスを無効にする
新しいスタンバイからログ転送サービスを無効にします。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=DEFER SCOPE=MEMORY;
Maximum Availability Architecture
9-34
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
スイッチオーバーの手順4: スイッチオーバーのステータスを確認し、必要な場合はリカバリを終
了する
現在のスタンバイ・インスタンスで、次の文を実行します。
SELECT ‘FOUND’
FROM DBA_LOGSTDBY_EVENTS
WHERE EVENT_TIME = ( SELECT MAX(EVENT_TIME) FROM DBA_LOGSTDBY_EVENTS)
AND STATUS_CODE = 16128;
問合せが「FOUND」というメッセージを返した場合は、「スイッチオーバーの手順 5」へ進みます。
問合せで何も返されない場合は、REDO の最後に Apply Engine が適用されています。Apply Engine に対して設定され
ている遅延がある場合は、これを削除します。
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
EXECUTE DBMS_LOGSTDBY.APPLY_UNSET(‘APPLY_DELAY’);
ALTER DATABASE START LOGICAL STANDBY APPLY;
アラート・ログの例
LOGSTDBY event: ORA-16128: User initiated shut down successfully completed
スイッチオーバーの手順5: 以前のスタンバイ・データベースから本番データベースに変換する
現在のスタンバイ・インスタンスで、次の文を実行します。
ALTER SYSTEM SET log_archive_dest_state_4='ENABLE' SCOPE=MEMORY;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
この文によって、次の処理が行われます。
•
•
新しいスタンバイに対してログ転送サービスを有効にする。
最後のアーカイブ REDO ログ・ファイルが受信され、スイッチオーバー（end-of-redo）マーカーを介して確
実に適用される。これらの処理が行われない場合は、Data Guard によってエラーが返される。
文がエラーなしで終了した場合は、「スイッチオーバーの手順 6」へ進みます。この手順が正常に終了したことは、
次のアラート・ログのメッセージによって示されます。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
LSP1 started with pid=38
...
Completed: alter database commit to switchover to primary
スイッチオーバーの手順6: ロジカル・スタンバイ適用を開始する
新しいスタンバイ・データベースで、NEW PRIMARY キーワードを使用して、SQL Apply エンジンを開始します。
ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY <db_link>;
ここでは、データベース・ロールはスイッチされていません。「ロジカル・スタンバイ・データベース: スイッチオ
ーバー後の手順」で説明されている環境であることを確認してください。
Maximum Availability Architecture
9-35
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
ロジカル・スタンバイ・データベース:
ロジカル・スタンバイ・データベース スイッチオーバー後の手順
スイッチオーバーの後では、データベースの保護モードが同じになっています。スイッチオーバーの後で、リカバリおよ
びアーカイブがエラーなしで行われていることを確認してください。
次の項では、スイッチオーバー後の手順について説明します。
•
スイッチオーバー後の手順 1: 本番データベースでローカルおよびリモートのアーカイブ宛先を確認する
•
スイッチオーバー後の手順 2: 遅延が適切に設定されていることを確認する
•
スイッチオーバー後の手順 3: リカバリで新しいアーカイブ REDO ログが適用されるようにする
スイッチオーバー後の手順1: 本番データベースでローカルおよびリモートのアーカイブ宛先を
確認する
本番データベースで、次の文を入力します。
SELECT NAME_SPACE, STATUS, TARGET, LOG_SEQUENCE, TYPE, PROCESS,
REGISTER, ERROR FROM V$ARCHIVE_DEST WHERE STATUS!='INACTIVE';
ローカルおよびリモートのアーカイブ宛先が返されます。予想される宛先が返されない場合は、アラート・ログ、お
よび V$ARCHIVE_DEST と V$ARCHIVE_DEST_STATUS のビューを調べ、エラーを確認します。
SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE STATUS!=’INACTIVE’;
スイッチオーバー後の手順2: 遅延が適切に設定されていることを確認する
SELECT DELAY_MINS FROM V$ARCHIVE_DEST WHERE DEST_ID=2;
スイッチオーバー後の手順3: リカバリで新しいアーカイブREDOログが適用されるようにする
本番データベースで次の問合せを実行します。
SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG GROUP BY THREAD#;
スタンバイ・データベースで次の問合せを実行します。
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#
「スイッチオーバー後の手順 1」でエラーがなかった場合は、次の問合せは、本番データベースで REDO ログがアー
カイブおよび送信されていることを示します。スタンバイおよび本番データベースの出力は、通常は一致します。
『Oracle9i Data Guard 概要および管理』の項 6.4「ログ適用サービスの監視」も参照してください。
Maximum Availability Architecture
9-36
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
9.8
データベース・サーバー層 - Data Guardフェイルオーバー
フェイルオーバー
フェイルオーバーとは、あるサイトのプライマリ・データベースをオフラインにして、スタンバイ・データベースの 1
つを新しいプライマリ・データベースとしてオンラインにする操作です。フェイルオーバー操作は、プライマリ・データ
ベースに予定外の壊滅的障害が発生し、プライマリ・データベースを迅速にリカバリできる可能性がない場合に実行しま
す。
表9-7: Data Guardフェイルオーバーの決定マトリックス
フェイルオーバーの決定マトリックス
Data Guard の可用性
使用するフェイルオーバー
フィジカル・スタンバイ・データベースのみ
フィジカル・スタンバイ・フェイルオーバー
Error!
Reference source no found.
ロジカル・スタンバイ・データベースのみ
ロジカル・スタンバイ・データベースのフェイルオーバー
フィジカルおよびロジカルのスタンバイ・
データベース
フィジカルおよびロジカルの両方のスタンバイを使用できる場合
は、フィジカル・スタンバイ環境にフェイルオーバーする方が適切で
す。これは、通常はフィジカル・スタンバイ環境の方がプライマリ・
データベースを正確に複製しているためです。
すべての MAA では、残りのスタンバイ・データベースの再度インス
タンス化が必要です。
フィジカル・スタンバイ・フェイルオーバーまたはロジカル・スタン
バイ・データベースのフェイルオーバーを使用してください。
9.8.1
Data Guardのフェイルオーバーの概要
のフェイルオーバーの概要
Data Guard のフェイルオーバーは、スタンバイ・データベースを本番データベースに変換する一連の手順です。スタンバ
イ・データベースは基本的に、本番のロールを前提としています。Data Guard のフェイルオーバーは、ユーザーを新しい
サイトおよびデータベースにフェイルオーバーするために、サイト・フェイルオーバーによって行われます。フェイルオ
ーバーの後は、セカンダリ・サイトには本番データベースが含まれます。以前の本番データベースは、新しいデータベー
スとして再作成し、MAA のリジリエンスをリストアする必要があります。
フェイルオーバーの処理中には、データの損失がほとんどない（またはゼロである）です。フェイルオーバーの詳しい説
明は、『Oracle9i Data Guard 概要と管理』に記載されています。
Data Guardのフェイルオーバーを使用する場合
のフェイルオーバーを使用する場合
Data Guard のフェイルオーバーは、次のような計画外停止によって、早急に処理を開始する場合にのみ使用します。
•
サイトの障害
•
ユーザー・エラー
•
データ障害
元の本番データベースにまだアクセスできる場合は、最初に Data Guard のスイッチオーバーを検討します。フェイルオ
ーバーでは、最初の本番データベースを新しいスタンバイ・データベースとして再度インスタンス化が必要ですが、これ
は非常にコストが高くなります。これに対してスイッチオーバーは、計画された処理で、本番とスタンバイのデータベー
ス間でデータベースを再度インスタンス化せずにロールを切替えできます。
Maximum Availability Architecture
9-37
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
Data Guardのフェイルオーバーを使用する場合
のフェイルオーバーを使用する場合
Data Guard のフェイルオーバーは、計画外停止に対して緊急処理が必要な場合のみ使用します。Data Guard のスイッチオ
ーバーを使用できる場合には、本番データベースがまだ使用できて完全なリカバリが意図されているため、Data Guard の
フェイルオーバーを使用してはいけません
いけません。完全なリカバリを行うフェイルオーバーのシナリオでは、本番データベー
いけません
スにアクセスできないように、または再起動できないようにします。強制フェイルオーバーのシナリオでは、本番データ
ベースは使用できますが、スタンバイ・データベースにおける poin-in-time のリカバリでデータが失われる可能性があり
ます。
オブジェクト・リカバリ・ソリューションにより、迅速で効率のよい方法が提供される場合は、Data Guard のフェイルオ
ーバーを使用しないでください。
オブジェクトのリカバリでは、データベースを再度インスタンス化が必要ですが、フェイルオーバーでは、前の本番デー
タベースを新しいスタンバイ・データベースとして再度インスタンス化が必要です。
9.8.2
フィジカル・スタンバイ・データベースのフェイルオーバー
フィジカル・スタンバイ・データベースのフェイルオーバー
•
フィジカル・スタンバイ・フェイルオーバーの準備
•
フィジカル・スタンバイ・データベースのフェイルオーバー手順とベスト・プラクティス
フィジカル・スタンバイ・データベース: 完全なリカバリを行うフェイルオーバーの手順
手順7: インスタンスを再開する
新しい本番データベースとして起動し、以前の本番データベースに対するログ転送を遅延設定して、インスタンスを
Oracle Net Services リスナーに手動で登録します。すべての本番インスタンスは、このタイミングで開始できます。
SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;
ALTER DATABASE OPEN;
ALTER SYSTEM REGISTER;
フィジカル・スタンバイ・データベース: 強制フェイルオーバーの手順
•
フィジカル・スタンバイ・データベースのフェイルオーバー後
フィジカル・スタンバイ・フェイルオーバーの準備
フィジカル・スタンバイのフェイルオーバーの開始前に、現在の状況を評価し、データ損失のリスク、および停止時間を
最少にしてロールを推移するために必要な時間を判断します。次の表は、考えられる停止、およびそれをリカバリする手
順について説明しています。強制フェイルオーバーにすべての REDO を適用するメリットは、後続のスタンバイ・デー
タベースを再度インスタンス化する必要がないことです。
Maximum Availability Architecture
9-38
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
表9-8: 様々なタイプの停止に対してフェイルオーバーを使用する
停止のタイプ
準備手順
サイト障害
本番データベースにアクセスできない、または再起動できない場合に検討します。本番
データベースにアクセスできて、起動できる場合は、Data Guard のスイッチオーバーを
使用します。
本番データベースが含まれて
いるクラスタがすべて使用で
きない
本番データベースにアクセスできない、または再起動できない場合に検討します。本番
データベースにアクセスできて、起動できる場合は、Data Guard のスイッチオーバーを
使用します。
データ障害
本番データベースにアクセスできない、または再起動できない場合に検討します。本番
（データまたはメディア破損） データベースにアクセスできて、起動できる場合は、Data Guard のスイッチオーバーを
使用します。
ユーザー・エラーまたは
不正な処理
（表の削除、バッチ実行の重
複）
1. スタンバイ・データベースで、管理されたリカバリをキャンセルする
RECOVER MANAGED STANDBY DATABASE CANCEL;
これによって、破損が適用されなくなります。
2. イベントまたはエラーの前の、（低く見積もった）時間または SCN を記録します。
3. 本番データベースがまだオープンしている場合は、現在の本番データベースにおけ
るログ転送サービスを遅延させて、スタンバイ・データベースに対するトランスポ
ートを停止します。スタンバイ・データベースでは、ユーザー・エラー前の特定の
ポイントにリカバリする必要があるため、新しい本番アーカイブ REDO ログは送信
する必要はありません。
ALTER SYSTEM SET
LOG_ARCHIVE_DEST_STATE_2=DEFER;
4. 現在の本番データベースをシャットダウンするか、またはこれ以上データが損失し
ないようにユーザー・コミュニティに対するアクセスを拒否します。
フィジカル・スタンバイ・データベースのフェイルオーバー手順と
フィジカル・スタンバイ・データベースのフェイルオーバー手順と
ベスト・プラクティス
Oracle9i Database Release 2 (9.2.0)の Data Guard GUI マネージャは RAC をサポートしていないため、現行の Data Guard GUI
インタフェースを使用するかわりに簡単な一連の手順を手動で実行する必要があります。Oracle Database 10g の Grid
Control では RAC および Data Guard の環境をサポートしています。それ以外の手段としては、手動でフェイルオーバーを
実行する手順のかわりに、Data Guard Manager の使用をお薦めします。フェイルオーバーの手順は、フェイルオーバーが
すべてのデータをリカバリするか、または強制フェイルオーバーかによって異なります。この項では、フェイルオーバー
の 2 つのシナリオを実施する詳細な手順、および各手順の進行を監視する方法を中心として説明します。
この項には次のトピックが含まれています。
•
フィジカル・スタンバイ・データベース: 完全なリカバリを行うフェイルオーバーの手順（有効なすべてのデー
タをリカバリする）
インスタンスを再開する
手順7: インスタンスを再
開する
新しい本番データベースとして起動し、以前の本番データベースに対するログ転送を遅延設定して、インスタンスを
Oracle Net Services リスナーに手動で登録します。すべての本番インスタンスは、このタイミングで開始できます。
SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;
ALTER DATABASE OPEN;
ALTER SYSTEM REGISTER;
•
フィジカル・スタンバイ・データベース: 強制フェイルオーバーの手順（データ損失）
Maximum Availability Architecture
9-39
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
フィジカル・スタンバイ・データベース:
フィジカル・スタンバイ・データベース 完全なリカバリを行うフェイルオーバーの手順
この手順の目的は、スタンバイで使用できるすべての REDO をリカバリし、スタンバイを本番データベースに変換する
ことです。各手順について、および各手順を監視する方法については、次の項で説明しています。
•
手順 1: アーカイブ・ギャップを確認する
•
手順 2: 他のスタンバイ・インスタンスをシャットダウンする
•
手順 3: プライマリがアクセス不可能で RFS 接続が停止していることを確認する
•
手順 4: リカバリを終了する
•
手順 5: データベースのステートを確認する
•
手順 6: スイッチオーバーへコミットする
•
手順 7: インスタンスを再開する
手順1: アーカイブ・ギャップを確認する
アーカイブ・ギャップに対して V$ARCHIVE_GAP、V$LOG_HISTORY、および V$MANAGED_STANDBY の問合せ
を実行します。アーカイブ宛先に、必要なアーカイブ REDO ログがすべて定義されていることを確認します。
V$ARCHIVE_GAP ビューには、スタンバイ・データベースが認識しているアーカイブ・ギャップの thread#、low
sequence#、および high sequence#が表示されます。
新規のアーカイブが送信されて、以前のアーカイブが送信されなかった場合にかぎり、ギャップが認識されます。
1.
次のいずれかの問合せを実行して、リカバリに必要な次のアーカイブ・ログを特定します。
SELECT MAX(SEQUENCE#) +1, THREAD# FROM V$LOG_HISTORY GROUP BY THREAD#;
SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS=’MRP0’;
2.
スタンバイ・データベースにアーカイブされている最大順序番号を特定します。
SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#;
3.
ギャップ内のすべてのアーカイブ REDO ログが、スタンバイ・データベースに対して有効であることを確認しま
す。スタンバイ・データベースでプライマリ・アーカイブの宛先、LOG_ARCHIVE_DEST_1（/arch1 など、
STANDBY_ARCHIVE_DEST の設定と同じ）、および別の宛先のディレクトリ、LOG_ARCHIVE_DEST_3（/arch2
など）を確認します。
本番ホストが使用できる場合は、アーカイブ・ギャップ・クエリーを介してさらに実行できます。ギャップが検出さ
れた場合は、本番のアーカイブ REDO ログを手動でコピーし、それをスタンバイ・データベースへ手動で登録でき
ます。
アーカイブ・ギャップ・クエリーは次のようになります。
SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM
(SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) LOCAL
WHERE LOCAL.SEQUENCE# NOT IN (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE
DEST_ID=2 AND THREAD# = LOCAL.THREAD#);
アーカイブ REDO ログをスタンバイにコピーした後で、次の文を使用してアーカイブ REDO ログを登録します。
ALTER DATABASE REGISTER LOGFILE ‘/ARCH1/SALES/archname’;
Maximum Availability Architecture
9-40
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
手順2: 他のスタンバイ・インスタンスをシャットダウンする
プライマリ・スタンバイ・インスタンスを除いたすべてのノードにログオンします。プライマリ・スタンバイ・イン
スタンスはリモート・ファイル・サービス（RFS）および MRP が使用されているため、SHUTDOWN IMMEDIATE 文
を発行します。
手順3: プライマリがアクセス不可能でRFS接続が停止していることを確認する
スタンバイ REDO ログ（SRL）で LGWR トランスポートを使用している場合には、プライマリ・データベースに接
続されているスタンバイ・リモート・ファイル・サーバー（RFS）プロセスが、スタンバイで書込みを行っている SRL
で処理をロックします。このロックは、プライマリ・データベースのログがスイッチされるまで、または REF プロ
セスが終了するまで解放されません。（V$MANAGED_STANDBY ビューに表示される）WRITING、RECEIVING、
または ATTACHED のステータスを持った 1 つのプライマリ・インスタンスおよびスレッドについて、最大で 3 つの
RFS プロセスがあります。これらの RFS プロセスがアクティブな状態でフェイルオーバーを試行すると、アラート・
ログに次のメッセージが示されます。
ORA-00283: recovery session canceled due to errors
ORA-00261: log 4 of thread 1 is being archived or modified
ORA-00312: online log 4 thread 1: '/database/oracle/920DG/srl1.dbf'
プライマリ・データベースとネットワークにアクセスできない場合は、これらの RFS プロセスは、TCP のタイムア
ウト、または Oracle Net Services の使用不能接続検出（DCD）（sqlnet.ora SQLNET.EXPIRE_TIME）が設定されてい
る場合は、これによって最終的に停止します。この設定が適切な最小値であっても（これは、システム全体に影響を
与えるため推奨されません）、RFS を終了するには 9 分以上かかります。したがって、フェイルオーバー・プロセス
をスムーズに行うには、RFS プロセスの終了を待つよりも、手動で RFS プロセスを終了させる必要があります。処
理を特定し、それらを終了させる手順は次のとおりです。
1.
スタンバイで次の問合せを実行し、アクティブな RFS プロセスを特定します。
SELECT PID
FROM V$MANAGED_STANDBY
WHERE PROCESS=’RFS’;
PID
---------14914
14928
2.
特定された処理を停止します。UNIX 以外のシステムの場合は、システムのドキュメントおよび MetaLink を参照
してください。たとえば、UNIX では次のとおりです。
kill −9 14914 14928
手順4: リカバリを終了する
現在のスタンバイ・インスタンスで、次の文を実行します。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
この文は、有効なすべてのアーカイブ REDO ログおよびスタンバイ REDO ログに適用されます。本番およびスタン
バイのデータベースが同期化されており、最大保護モードまたは最大可用性モードで実行されている場合は、トラン
ザクション・データは失われません。ただし、最大パフォーマンス保護モードで LGWR ASYNC オプションを使用し
ている場合は、データが失われる可能性があります。
スタンバイのアラート・ログで、エラーおよびメッセージを監視します。次のメッセージは、完全なリカバリが終了
したことを表しています。
Maximum Availability Architecture
9-41
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
Incomplete recovery applied all redo ever generated.
Recovery completed through change 56985.
Media Recovery Completed
次のメッセージは、データが失われた可能性があることを表しています。
Incomplete recovery applied all redo ever generated.
Recovery completed through change 77637.
Terminal recovery recovered to last consistent point in redo stream But
it did not apply all redo; some data maybe lost
次の 2 つのメッセージを受け取った場合は、リカバリの終了コマンドが正常終了したことを表します。
Terminal Recovery: successful completion
Completed: ALTER DATABASE RECOVER managed standby database finish
このコマンドの実行中にエラーを受け取った場合、またはスタンバイのアラート・ログで、このコマンドが失敗した
ことを示すエラーを検出した場合は、RECOVER STANDBY DATABASE コマンドを使用して手動でアーカイブ・ログ
を適用できます。FINISH コマンドが停止した場合は、インスタンスを強制終了し、手動で再試行する必要がありま
す。
一般的な問題は、強制フェイルオーバーを必要とする解決不可能なアーカイブ・ギャップで、この場合には次のコマ
ンドを発行する必要があります。
ALTER DATABASE ACTIVATE STANDBY DATABASE SKIP STANDBY LOGFILE
手順5: データベースのステートを確認する
次の文を実行して、スイッチオーバーのステータスが準備完了になっているか問い合せます。
SELECT SWITCHOVER_STATUS FROM V$DATABASE;
•
SWITCHOVER_STATUS=’TO PRIMARY’の場合は、「手順 5」へ進みます。
•
SWITCHOVER_STATUS != 'TO PRIMARY'の場合は、前のコマンドでエラーがあります。手順 2 を再度実行する
か、または次のコマンドを実行して、スタンバイ REDO ログの適用を省略します。
RECOVER MANAGED STANDBY DATABASE FINISH SKIP
•
RECOVER MANAGED STANDBY DATABASE FINISH SKIP コマンドの発行後も、SWITCHOVER_STATUS がま
だ TO PRIMARY になっている場合は、V$DATABASE を再度実行します。その後で次のコマンドを実行して、
強制フェイルオーバーを行う必要があります。
ALTER DATABASE ACTIVATE STANDBY DATABASE SKIP STANDBY LOGFILE;
スイッチオーバーへコミットする
手順6: スイッチオーバーへ
コミットする
現在のスタンバイ・インスタンスで、次の文を実行します。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
スタンバイ・アラート・ログで、このコマンドが完了したかを監視します。次のアラート・ログ・メッセージに注意
します。
Switchover: Complete - Database shutdown required
Completed: alter database commit to switchover to primary
エラーがある場合は、エラー・メッセージを参照して再度実行します。
Maximum Availability Architecture
9-42
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
手順7: インスタンスを再開する
新しい本番データベースとして起動し、以前の本番データベースに対するログ転送を遅延設定して、インスタンスを
Oracle Net Services リスナーに手動で登録します。すべての本番インスタンスは、このタイミングで開始できます。
SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;
ALTER DATABASE OPEN;
ALTER SYSTEM REGISTER;
フィジカル・スタンバイ・データベース:
フィジカル・スタンバイ・データベース 強制フェイルオーバーの手順
強制フェイルオーバーの目的は、スタンバイ・データベースを、論理的な破損、またはユーザー・エラーの前の特定のタ
イミングにリカバリし、新しい本番データベースとしてスタンバイ・データベースを有効にすることです。各手順につい
て、および各手順を監視する方法については、次の項で説明しています。
•
手順 1: アーカイブ REDO ログを確認する
•
手順 2: Point-in-Time リカバリ
•
手順 3: 排他モードでスタンバイ・インスタンスをマウントする
•
手順 4: スタンバイ・データベースを有効化する
•
手順 5: 新しい本番データベースを再起動する
•
手順 6: Resetlogs SCN を記録する
強制フェイルオーバーの手順1: アーカイブREDOログを確認する
次の内容を調べ、リカバリ対象のスタンバイ・ノードで、必要なアーカイブ REDO ログがすべて存在していることを確
認します。
•
V$ARCHIVED_LOG
•
スタンバイ・アーカイブの宛先
必要なアーカイブ REDO ログがすべて有効ではない場合は、本番データベースで同じ V$ARCHIVED_LOG ビューに対し
て問合せを実行し、対応する本番アーカイブ REDO ログをセカンダリ・ホストの STANDBY_ARCHIVE_DEST 宛先にコ
ピーします。
強制フェイルオーバーの手順2: Point-in-Timeリカバリ
論理的な破損またはユーザー・エラー前の特定のポイントにリカバリします。プライマリ・サイトとセカンダリ・サ
イト間でタイムゾーンが同じにしてください。タイムゾーンが異なる場合は、ローカル・スタンバイのロケーション
で時間を調整してください。リカバリ・セッションはすでにキャンセルされています。管理されたリカバリのかわり
に、手動のリカバリが必要になります。
RECOVER STANDBY DATABASE UNTIL [TIME time_format | CHANGE | CANCEL];
注意: TIME は、YYYY-MON-DD: 24HH:MI:SS という形式にする必要があります。
次の問合せを発行して、リカバリ・プロセスを監視します。
SELECT THREAD#, MAX(SEQUENCE#) FROM V$LOG_HISTORY GROUP BY THREAD#;
Maximum Availability Architecture
9-43
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
次のメッセージを受け取るまで、スタンバイ・データベースにアーカイブ REDO ログを適用します。
Log applied.
Media recovery complete
処理全体を通じて、スタンバイ・アラート・ログでエラーを確認します。
強制フェイルオーバーの手順3: 排他モードでスタンバイ・インスタンスをマウントする
クラスタ・データベース・モードを無効にして、1 つのスタンバイ・インスタンスをマウントし、クラスタ・データ
ベース・モードを再度有効化します。
ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE
SHUTDOWN IMMEDIATE # on all standby instances
STARTUP NOMOUNT
# on one of the standby instances
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER SYSTEM SET CLUSTER_DATABASE = TRUE SCOPE=SPFILE
強制フェイルオーバーの手順
順4: スタンバイ・データベースを有効化する
強制フェイルオーバーの手
これによって、すべてのスタンバイ REDO ログをスキップします。リカバリはすでに終了しています。データが失
われる可能性があります。
ALTER DATABASE ACTIVATE STANDBY DATABASE SKIP;
スタンバイ・アラート・ログの進行を確認します。新しい本番のアラート・ログに次のメッセージが表示されます。
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE RESETLOGS after
incomplete recovery UNTIL CHANGE 143080
Resetting resetlogs activation ID 2547644951 (0x97d9fa17) Activation
complete
Completed: alter database activate standby database skip
強制フェイルオーバーの手順5: 新しい本番データベースを再起動する
新しい本番データベースは、CLUSTER_DATABASE=TRUE で提示されます。
SHUTDOW IMMEDIATE;
STARTUP
# on all new production instances
ALTER SYSTEM REGISTER;
強制フェイルオーバーの手順6: Resetlogs SCNを記録する
これは、元の本番バックアップを使用して以前の resetlogs SCN にリカバリする場合に必要になります。以前のリリ
ースでは、古いバックアップはすべて無効になっていました。以前の resetlogs SCN にリカバリすることによって、
ローカル・バックアップを使用してスタンバイ・データベースを再作成できます。
スタンバイ・アラート・ログからこの SCN を記録します。
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE RESETLOGS after
incomplete recovery UNTIL CHANGE 143080
Maximum Availability Architecture
9-44
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
フィジカル・スタンバイ・データベースのフェイルオーバー後
フェイルオーバーの後は、データベースの保護モードが自動的に最大パフォーマンス・モードにダウングレードします。
最終的に、新しいスタンバイ・データベースを作成してリジリエンスを回復する場合を検討します。「データベースのフ
ォルト・トレランスをリストアする」では、リジリエンスがある MAA ステートに戻すための詳しい手順について説明し
ています。いずれのタイプのフェイルオーバーの後でも、次の説明するいくつかの重要な手順があります。
•
ローカル・アーカイブが機能しており、ログ転送が一時的に DEFER ステートになるよう確認します。
V$ARCHIVE_DEST および V$ARCHIVE_DEST_STATUS に問い合せ、ローカル・アーカイブが機能しているか
を検証します。
•
フェイルオーバーから、現在のアーカイブ REDO ログまでのすべての本番アーカイブ REDO ログをバックアッ
プします。強制フェイルオーバーの最中は、アーカイブの順序番号はリセットされます。スタンバイ・データベ
ースを有効化した後は、resetlogs SCN も記録する必要があります。
•
以前の本番ホストおよび現在のスタンバイ・ホストのリストアには、過去のアーカイブ REDO ログをすべてバッ
クアップおよび移動してください。新しいスタンバイ・データベースの再作成には、同じ名前で内容が異なるア
ーカイブ REDO ログを混同しないことが重要です。
•
データが損失した場合は、ユーザー・コミュニティおよびアプリケーション・コミュニティへ通知します。強制
フェイルオーバーが行われた場合は、以前のデータを再度設定する必要があります。有効な REDO をすべてリカ
バリするには、スタンバイ・アラート・ログを確認して、次のメッセージがあるかを確認できます。
「Terminal recovery recovered to last consistent point in redo stream But it did not apply
all redo; some data maybe lost.」
ロジカル・スタンバイ・データベースのフェイルオーバー
9.8.3
•
ロジカル・スタンバイ・フェイルオーバーの準備
•
ロジカル・スタンバイ・フェイルオーバーおよびベスト・プラクティス
•
ロジカル・スタンバイのフェイルオーバー後の手順
ロジカル・スタンバイ・フェイルオーバーの準備
次の表は、考えられる停止、およびそれをリカバリする手順について説明しています。フィジカル・スタンバイ・データ
ベースのフェイルオーバーとは異なり、ロジカル・スタンバイ・データベースへのフェイルオーバーが成功した後は、新
しいプライマリからカスケードされない後続のすべてのスタンバイ・データベースの再度インスタンス化が必要です。
表9-9: 様々なタイプの停止に対してフェイルオーバーを使用する
停止のタイプ
準備手順
サイト障害
本番データベースにアクセスできない、または再起動できない場合に検討します。本番
データベースにアクセスできて、起動できる場合は、Data Guard のスイッチオーバーを
使用します。
本番データベースが含まれて
いるクラスタがすべて使用で
きない
本番データベースにアクセスできない、または再起動できない場合に検討します。本番
データベースにアクセスできて、起動できる場合は、Data Guard のスイッチオーバーを
使用します。
データ障害
本番データベースにアクセスできない、または再起動できない場合に検討します。本番
（データまたはメディア破損） データベースにアクセスできて、起動できる場合は、Data Guard のスイッチオーバーを
使用します。
Maximum Availability Architecture
9-45
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
停止のタイプ
準備手順
ユーザー・エラーまたは
1. スタンバイ・データベースで、管理されたリカバリをキャンセルする
不正な処理（表の削除、バッチ
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
実行の重複）
これによって破損が適用されなくなります。
2. イベントまたはエラーの前の、（低く見積もった）時間または SCN を記録します。
3. 本番データベースがまだオープンしている場合は、現在の本番データベースにおけ
るログ転送サービスを遅延させて、スタンバイ・データベースに対するトランスポ
ートを停止します。スタンバイ・データベースでは、ユーザー・エラー前の特定の
ポイントにリカバリする必要があるため、新しい本番アーカイブ REDO ログは送信
する必要はありません。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;
4. 現在の本番データベースをシャットダウンするか、またはこれ以上データが損失し
ないようにユーザー・コミュニティに対するアクセスを拒否します。
ロジカル・スタンバイ・フェイルオーバーおよびベスト・プラクティス
Oracle9i Database Release 2 (9.2.0)の Data Guard GUI マネージャは RAC をサポートしていないため、現行の Data Guard GUI
インタフェースを使用するかわりに簡単な一連の手順を手動で実行する必要があります。Oracle Database 10g の Grid
Control では RAC および Data Guard の環境をサポートしています。それ以外の手段としては、手動でフェイルオーバーを
実行するかわりに、Data Guard Manager の使用をお薦めします。この項では、ロジカル・スタンバイ・フェイルオーバー
を実施する詳細な手順、および各手順の進行を監視する方法を中心として説明します。
この手順の目的は、スタンバイで使用できるすべての REDO をリカバリし、ロジカル・スタンバイを本番データベース
に変換することです。各手順について、および各手順を監視する方法については、次の項で説明しています。
手順1: アーカイブ・ギャップを確認する
データの損失を最少に抑える場合は、アーカイブ・ギャップに対して DBA_LOGSTDBY_LOG の問合せを行います。
アーカイブ宛先に、必要なアーカイブ REDO ログがすべて定義されていることを確認します。
ロジカル・スタンバイのフェイルオーバーでは、REDO ログ・ファイル全体を適用する場合に、ロジカル・スタンバ
イ・エンジンのみ使用できます。ロジカル・スタンバイ・データベースで、特定のタイミングまたは SCN へのリカ
バリを実行する場合にはオプションはありません。したがって、データの損失または不正な処理によるフェイルオー
バーの場合は、すべてのアーカイブ・ギャップが解決されない可能性があります。
1.
スタンバイ・データベースで使用できる、部分的なログ・ファイルがあるかどうか判断します。
プライマリ・データベースがシャットダウンされると、LGWR プロセスによってオープンされていたすべてのロ
グ・ファイルはクローズし、ログ転送サービスでは、部分的なログ・ファイルが使用できることを通知します。
RFS: Possible network disconnect with primary database
Closing latent archivelog for thread 2 sequence 111
EOF located at block 918 low SCN 0:1536302 next SCN 0:1541253
Latent archivelog '/arch1/SALES/arch_2_0000000111.log'
If you wish to failover to this standby database, you should use the
following command to manually register the archivelog for recovery:
アラート・ログのメッセージは、ログ・ファイルを登録するために、「ALTER DATABASE REGISTER
LOGFILE ...」コマンドを使用することを推奨しています。この構文は、フィジカル・スタンバイ・データベー
スで有効です。ロジカル・ログ・ファイルを登録するためのコマンドは、「ALTER DATABASE REGISTER
LOGICAL LOGFILE ...」です。
Maximum Availability Architecture
9-46
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
2.
スタンバイ・データベースにギャップがあるかどうか判断します。
SELECT THREAD#, SEQUENCE# FROM DBA_LOGSTDBY_LOG L
WHERE NEXT_CHANGE# NOT IN
(SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#)
AND NEXT_CHANGE# > ( SELECT APPLIED_SCN FROM DBA_LOGSTDBY_PROGRESS )
ORDER BY THREAD#,SEQUENCE#;
THREAD# SEQUENCE#
---------- ---------1
350
1
357
2
126
この問合せでは REDO の各スレッドに対して登録された最後のロジカル・ログ・ファイル、および特定のスレッ
ド内で不明になっているログ・ファイルがレポートされます。この結果は、thread# 1 と sequence# 357、および
thread# 2 と sequence# 126 が、登録された最後の 2 つのロジカル・ログ・ファイルで、最初の thread# 1 と sequence#
350 とギャップがあることを示しています。これは、少なくとも thread#1、sequence# 351 が不明であり、さらに
いくつかの sequence# が不明である可能性があることを意味しています。
本番ホストがまだ使用できる場合は、アーカイブ・ギャップ・クエリーを介してさらに実行できます。ギャップが検
出された場合は、本番のアーカイブ REDO ログを手動でコピーし、それをスタンバイ・データベースへ登録できま
す。
アーカイブ・ギャップ・クエリーは次のようになります。
本番ホスト環境のみのロジカル・スタンバイの場合
SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM
(SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) LOCAL
WHERE LOCAL.SEQUENCE# NOT IN
(SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=4 AND THREAD# =
LOCAL.THREAD#);
スタンバイ・ホストでロジカルおよびフィジカルのスタンバイを実行している環境の場合
SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM
(SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) LOCAL
WHERE LOCAL.SEQUENCE# NOT IN
(SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=4 AND THREAD# =
LOCAL.THREAD#);
アーカイブ REDO ログ・ファイルをスタンバイにコピーした後で、次の文を使用してアーカイブ REDO ログを登録
します。
ALTER DATABASE REGISTER LOGICAL LOGFILE ‘/arch1/SALES/archname’;
手順2: リカバリを終了する
プライマリ・スタンバイ・インスタンスで、有効なデータがすべて適用されていることを確認します。
SELECT APPLIED_SCN, NEXT_SCN FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN および NEXT_SCN によって同じ数値がレポートされる場合は、登録されているすべてのデータに対
してリカバリが提供されており、次の文を使用してリカバリを停止できます。
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Maximum Availability Architecture
9-47
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
手順3: スタンバイ・データベースを有効化する
リカバリは終了していますが、データの損失が予想されます。
ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE;
スタンバイ・アラート・ログの進行を確認します。新しい本番のアラート・ログに次のメッセージが表示されます。
ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE
LSP1 started with pid=18
Completed: alter database activate logical standby database
ロジカル・スタンバイのフェイルオーバー後の手順
フェイルオーバーの後、最終的に新しいスタンバイ・データベースを作成してリジリエンスを回復する場合を検討します。
「データベースのフォルト・トレランスをリストアする」では、リジリエンスがある MAA ステートに戻すための詳しい
手順について説明しています。いずれのタイプのフェイルオーバーの後でも、次の説明するようないくつかの重要な手順
があります。
•
ローカル・アーカイブが機能し、
ログ転送が一時的に DEFER ステートになるよう確認します。V$ARCHIVE_DEST
および V$ARCHIVE_DEST_STATUS に対して問合せを行い、ローカル・アーカイブが機能しているかどうか検
証します。
•
フェイルオーバーから、現在のアーカイブ REDO ログまでのすべての本番アーカイブ REDO ログをバックアッ
プします。
•
以前の本番ホストおよび現在のスタンバイ・ホストをリストアする場合には、過去のアーカイブ REDO ログをす
べてバックアップおよび移動してください。新しいスタンバイ・データベースを再度作成する場合には、同じ名
前で内容が異なるアーカイブ REDO ログを混同しないことが必要です。
•
データが損失した場合は、ユーザー・コミュニティおよびアプリケーション・コミュニティへ通知します。
Maximum Availability Architecture
9-48
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
9.9
データベース・サーバー層 - スタンバイ・インスタンス・
フェイルオーバー
この項では、スタンバイ RAC 環境のプライマリ・スタンバイ・インスタンスから、セカンダリ・スタンバイ・インスタ
ンスにフェイルオーバーする際の影響を最小限にする方法について説明します。（ノードまたはインスタンスの計画外の
障害、または計画的なメンテナンスによって）、プライマリ・スタンバイ・インスタンスまたはノードに影響を与える停
止が発生する場合には、セカンダリ・スタンバイ・インスタンスへのフェイルオーバーが必要になることがあります。ス
タンバイ・インスタンス
インスタンスのフェイルオーバーは、セカンダリ・サイトにおいてスタンバイ・データベースの複数のイン
インスタンス
スタンスを利用し、Data Guard のフェイルオーバーまたは Data Guard のスイッチオーバーは、スタンバイ・データベース
を本番データベースにします。これらの違いについて注意してください。スタンバイ・インスタンスのフェイルオーバー
での状態は、次のとおりです。
•
プライマリのスタンバイ・ホストのメンテナンス中、または障害発生時でも、スタンバイ・リカバリを続行させ
ることができます。
スタンバイ・リカバリを中断せず、適切なリカバリ・ラグを保持することによって、妥当な MTTR 内で Data Guard
のフェイルオーバーまたはスイッチオーバーを完了させることが可能です。
•
以降のネットワーク接続はセカンダリ・スタンバイ・インスタンスへ切り替えられるため、本番データベースは
中断されないか、または本番の停止時間は最少になります。
プライマリ・スタンバイ・インスタンスにおいて計画停止または計画外停止があるかどうかによって、スタンバイ・イン
スタンスのフェイルオーバー手順は異なります。
•
複数のスタンバイ・データベース環境に関する留意点
•
計画外のスタンバイ・インスタンスのフェイルオーバー
•
スタンバイ・インスタンスの計画的なフェイルオーバー
9.9.1
複数のスタンバイ・データベース環境に関する留意点
この項では、複数のスタンバイ・データベースを配置した場合に、考慮の必要がある事項について説明します。顧客がフ
ィジカル・スタンバイとロジカル・スタンバイの両方を配置した場合は、ログ転送サービスは次のように設定されます。
•
プライマリ・サイトのプライマリ・データベースは、ログ転送サービス#2（log_archive_dest_2）を使用して、REDO
ログをフィジカル・スタンバイ・データベースに転送します。
•
セカンダリ・サイトのフィジカル・スタンバイ・データベースは、ログ転送サービス#4（log_archive_dest_4）を
使用して、REDO ログをロジカル・スタンバイ・データベースにアナウンスします。
フィジカル・スタンバイ・データベースへ影響を与える停止が発生した場合は、次の 2 つの選択肢があります。
•
フィジカル・スタンバイ・データベースのリストアを保留にして、ロジカル・スタンバイ・データベースを効率
よく停止させることができます。
この場合には、顧客による処理は必要ありません。
•
プライマリ・データベースのログ転送サービス#4（log_archive_dest_4）を有効化し、プライマリ・データベース
からロジカル・スタンバイ・データベースへログを直接送信することによって、ロジカル・スタンバイ・データ
ベースを続行ができます。
REDO ログをロジカル・スタンバイ・データベースに転送するプライマリ・データベースの再設定には、次の手順に従い
ます。
•
手順 1: プライマリ・データベースでフィジカル・スタンバイのログ転送サービスを再設定する
•
手順 2: プライマリ・データベースでロジカル・スタンバイのログ転送サービスを再設定する
Maximum Availability Architecture
9-49
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
手順1: プライマリ・データベースでフィジカル・スタンバイのログ転送サービスを再設定する
本番インスタンスから、リモート・アーカイブ先のステータス（LOG_ARCHIVE_DEST_STATE_2）を変更して、フ
ィジカル・スタンバイ・データベースへの REDO ログの転送を無効にします。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;
手順2: プライマリ・データベースでロジカル・スタンバイのログ転送サービスを再設定する
本番インスタンスから、リモート・アーカイブ先のステータス（LOG_ARCHIVE_DEST_STATE_4）を変更して、ロ
ジカル・スタンバイ・データベースへの REDO ログの転送を有効にします。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=DEFER;
9.9.2
計画外のスタンバイ・インスタンスのフェイルオーバー
本番データベースを再起動するには次の手順に従います。必要な場合は、プライマリ・スタンバイ・インスタンスまたは
ノードの計画外停止に続いて、管理リカバリを再起動します。
•
手順 1: セカンダリ・スタンバイ・インスタンスがマウントされていることを確認する
•
手順 2: セカンダリ・スタンバイ・ホストへの Oracle Net 接続を検証する
•
手順 3: 必要な場合は本番データベースを開始する
•
手順 4: セカンダリ・スタンバイ・インスタンスでリカバリを開始する
•
手順 5: アーカイブ REDO ログをセカンダリ・スタンバイ・ホストにコピーする
•
手順 6: セカンダリ・スタンバイ・ホストへのリモート・アーカイブを検証する
•
手順 7: セカンダリ・スタンバイ・ホストの管理されたリカバリを検証する
•
手順 8: プライマリ・スタンバイ・インスタンスおよびリスナーを再開する
手順1: セカンダリ・スタンバイ・インスタンスがマウントされていることを確認する
ターゲットのスタンバイ・インスタンスから次の問合せを実行します。
SELECT OPEN_MODE, DATABASE_ROLE FROM V$DATABASE;
フィジカル・スタンバイで必要な出力は次の文を実行します。
MOUNTED PHYSICAL STANDBY
マウントされていない場合は、別のターゲット・スタンバイ・インスタンスを選択するか、またはこのスタンバイ・
インスタンスを手動でマウントします。
STARTUP NOMOUNT
ALTER DATABASE MOUNT STANDBY DATABASE;
ロジカル・スタンバイで必要な出力は次の文を実行します。
READ WRITE LOGICAL STANDBY
読込み/書込みに対してオープンされていない場合は、別のターゲット・スタンバイ・インスタンスを選択するか、
またはこのスタンバイ・インスタンスを手動でオープンします。
STARTUP
Maximum Availability Architecture
9-50
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
手順2: セカンダリ・スタンバイ・ホストへのOracle Net接続を検証する
1.
スタンバイ・リスナーが開始されるようにします。
% lsnrctl status listener_name
2.
クラスタ内のすべての本番ホストから、Oracle Net のエイリアスの妥当性チェックを行います。
% tnsping SALES_ALT
手順3: 必要な場合は本番データベースを開始する
最大保護モードで実行中の場合は、スタンバイ・データベースに対する接続の再試行（LOG_ARCHIVE_DEST_n パ
ラメータの REOPEN 属性）が適切ではないため、プライマリ・スタンバイ・インスタンスが失敗すると本番データ
ベースが失敗します。本番データベース、およびそのすべてのインスタンスを再開します。本番データベースの開始
時に、ログ・ライターは、Oracle Net のフェイルオーバー・ポリシーを使用して、セカンダリ・スタンバイ・インス
タンスへ自動的に再接続します。
最大可用性モードおよび最大パフォーマンス保護モードでは、
自動の Oracle Net フェイルオーバー・ポリシーにより、
LOG_ARCHIVE_DEST_n パラメータの REOPNE 属性に基づいてスタンバイ・データベースへの接続が自動的に再確
立され、本番データベースでは停止時間が発生しません。Oracle Net の自動フェイルオーバーの詳細は、「Oracle Data
Guard」を参照してください。
手順4: セカンダリ・スタンバイ・インスタンスでリカバリを開始する
なんらかの理由でプライマリ・スタンバイ・インスタンスがまだ実行中の場合は、リカバリ・プロセスを停止します。
フィジカル・スタンバイ・データベースでは次の文を実行します。
RECOVER MANAGED STANDBY DATABASE CANCEL IMMEDIATE;
ロジカル・スタンバイ・データベースでは次の文を実行します。
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
プライマリ・スタンバイ・インスタンスで実行中だったリカバリ・プロセスは、セカンダリ・スタンバイ・インスタ
ンスで開始する必要があります。
フィジカル・スタンバイ・データベースでは次の文を実行します。
RECOVER MANAGED STANDBY DATABASE DISCONNECT;
ロジカル・スタンバイ・データベースでは次の文を実行します。
ALTER DATABASE START LOGICAL STANDBY APPLY;
手順5: アーカイブREDOログをセカンダリ・スタンバイ・ホストにコピーする
オプションで、プライマリ・スタンバイ・ホストからセカンダリ・スタンバイ・ホストにアーカイブ REDO ログを
コピーします。
この処理は必須ではありませんが、有用です。管理されたリカバリ・プロセスでアーカイブ・ギャップを検出した場
合は、リカバリ・プロセスでは、本番のアーカイブ REDO ログを再度セカンダリ・スタンバイ・ホストに送信する
よう要求します。ただし、スタンバイ・ホスト間で共有ファイル・システムを使用している場合は、アーカイブ REDO
ログを再送信が必要ありません。また、アーカイブ・ログを手動でコピーして、アーカイブ・ログを登録することも
可能です。
Maximum Availability Architecture
9-51
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
手順6: セカンダリ・スタンバイ・ホストへのリモート・アーカイブを検証する
アーカイブ REDO ログがセカンダリ・スタンバイ・ホストに送信されていることを確認します。V$ARCHIVE_STATUS
および V$ARCHIVED_DEST_STATUS で問い合せます。
SELECT NAME_SPACE, STATUS, TARGET, LOG_SEQUENCE ,
TYPE, PROCESS, REGISTER, ERROR FROM V$ARCHIVE_DEST
WHERE STATUS!='INACTIVE';
SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE STATUS!='INACTIVE';
手順7: セカンダリ・スタンバイ・ホストの管理されたリカバリを検証する
次の問合せを発行し、時間の経過につれて順序番号が増加していることを確認します。
フィジカル・スタンバイ・データベースでは次の文を実行します。
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;
プライマリ・スタンバイ・インスタンスおよびリスナーを再開する
手順8: プライマリ・スタンバ
イ・インスタンスおよびリスナーを再開する
停止が解決した後、プライマリ・スタンバイ・インスタンスおよびリスナーを再開します。
フィジカル・スタンバイ・データベースでは次の文を実行します。
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ロジカル・スタンバイ・データベースでは次の文を実行します。
STARTUP;
% lsnrctl start listener_name
9.9.3
スタンバイ・インスタンスの計画的なフェイルオーバー
次の手順に従って、プライマリ・スタンバイ・インスタンスのメンテナンス前にセカンダリ・スタンバイ・インスタンス
へネットワーク接続を意図的に切り替えることによって、本番データベースの破損を回避できます。
次の図は、スタンバイ・インスタンスのフェイルオーバー手順の目的について表しています。ここでは Oracle Net のエイ
リアス SALES_SEC を使用してスタンバイ・ホスト 1 をポイントし、Oracle Net のエイリアス SALES_SEC_ALT を使用し
てスタンバイ・ホスト 2 をポイントしています。SALES_SEC および SALES_SEC_ALT を定義する例については、付録の
「Oracle Net の構成ファイルの例」を参照してください。
Maximum Availability Architecture
9-52
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
図9-5: スタンバイ・インスタンスへのフェイルオーバー
ここでは、クラスタ内のプライマリ・スタンバイ・インスタンスが使用できなくなった後で、フェイルオーバーに使用で
きる有効なスタンバイ・インスタンスを少なくとも 1 つ持つことが前提条件になります。スタンバイ・インスタンスのフ
ェイルオーバーに対して次の手順を完了します。
•
手順 1: セカンダリ・スタンバイ・インスタンスを使用できるようにする
•
手順 2: セカンダリ・スタンバイ・ホストへの Oracle Net 接続を検証する
•
手順 3: セカンダリ・スタンバイ・ホストへのリモート・アーカイブ宛先を変更する
•
手順 4: セカンダリ・スタンバイ・インスタンスでリカバリを開始する
•
手順 5: アーカイブ REDO ログをセカンダリ・スタンバイ・ホストにコピーする
•
手順 6: セカンダリ・スタンバイ・ホストへのリモート・アーカイブを検証する
•
手順 7: セカンダリ・スタンバイ・ホストの管理されたリカバリを検証する
•
手順 8: プライマリ・スタンバイ・インスタンスおよびリスナーをシャットダウンする
•
手順 9: スタンバイ・ホストでメンテナンスを実行する
Maximum Availability Architecture
9-53
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
手順1: セカンダリ・スタンバイ・インスタンスを使用できるようにする
ターゲットのスタンバイ・インスタンスから次の問合せを実行します。
SELECT OPEN_MODE, DATABASE_ROLE FROM V$DATABASE;
フィジカル・スタンバイで必要な出力は次の文を実行します。
MOUNTED PHYSICAL STANDBY
マウントされていない場合は、別のターゲット・スタンバイ・インスタンスを選択するか、またはこのスタンバイ・
インスタンスを手動でマウントします。
STARTUP NOMOUNT
ALTER DATABASE MOUNT STANDBY DATABASE;
ロジカル・スタンバイで必要な出力は次の文を実行します。
READ WRITE LOGICAL STANDBY
読込み/書込みに対してオープンされていない場合は、別のターゲット・スタンバイ・インスタンスを選択するか、
またはこのスタンバイ・インスタンスを手動でオープンします。
STARTUP
手順2: セカンダリ・スタンバイ・ホストへのOracle Net接続を検証する
1.
スタンバイ・リスナーが開始されるようにします。
% lsnrctl status listener_name
2.
クラスタ内のすべての本番ホストから、Oracle Net のエイリアスの妥当性チェックを行います。
% tnsping SALES_ALT
セカンダリ・スタンバイ・ホストへのリモート・アーカイブ宛先を変更する
手順3: セカンダ
リ・スタンバイ・ホストへのリモート・アーカイブ宛先を変更する
本番インスタンスから、リモート・アーカイブ宛先（LOG_ARCHIVE_DEST_2）を変更して、セカンダリ・フィジカ
ル・スタンバイ・インスタンスを指すようにします。たとえば次の文を実行します。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=” service=SALES_SEC_ALT …”
本番インスタンスから、リモート・アーカイブ宛先（LOG_ARCHIVE_DEST_4）を変更して、セカンダリ・フィジカ
ル・ロジカル・インスタンスを指すようにします。たとえば次の文を実行します。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_4=” service=SALES_LOG_SEC_ALT …”
手順4: セカンダリ・スタンバイ・インスタンスでリカバリを開始する
プライマリ・スタンバイ・インスタンスでリカバリ・プロセスを停止します。
フィジカル・スタンバイ・データベースでは次の文を実行します。
RECOVER MANAGED STANDBY DATABASE CANCEL;
ロジカル・スタンバイ・データベースでは次の文を実行します。
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
プライマリ・スタンバイ・インスタンスで実行中だったリカバリ・プロセスは、セカンダリ・スタンバイ・インスタ
ンスで開始する必要があります。
Maximum Availability Architecture
9-54
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
停止からのリカバリ
フィジカル・スタンバイ・データベースでは次の文を実行します。
RECOVER MANAGED STANDBY DATABASE DISCONNECT;
ロジカル・スタンバイ・データベースでは次の文を実行します。
ALTER DATABASE START LOGICAL STANDBY APPLY;
手順5: アーカイブREDOログをセカンダリ・スタンバイ・ホストにコピーする
オプションで、プライマリ・スタンバイ・ホストからセカンダリ・スタンバイ・ホストにアーカイブ REDO ログを
コピーします。
この処理は必須ではありませんが、有用です。管理されたリカバリ・プロセスでアーカイブ・ギャップを検出した場
合は、リカバリ・プロセスでは、本番のアーカイブ REDO ログを再度セカンダリ・スタンバイ・ホストに送信する
よう要求します。ただし、スタンバイ・ホスト間で共有ファイル・システムを使用している場合は、アーカイブ REDO
ログを再送信する必要はありません。また、アーカイブ REDO ログを手動でのコピーも可能です。
手順6: セカンダリ・スタンバイ・ホストへのリモート・アーカイブを検証する
アーカイブ REDO ログがセカンダリ・スタンバイ・ホストに送信されていることを確認します。V$ARCHIVE_STATUS
および V$ARCHIVED_DEST_STATUS で問い合せます。
SELECT NAME_SPACE, STATUS, TARGET, LOG_SEQUENCE ,
TYPE,PROCESS, REGISTER , ERROR FROM V$ARCHIVE_DEST
WHERE STATUS!='INACTIVE';
SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE STATUS!='INACTIVE';
手順7: セカンダリ・スタンバイ・ホストの管理されたリカバリを検証する
次の問合せを発行し、時間の経過につれて順序番号が増加していることを確認します。
フィジカル・スタンバイ・データベースでは次の文を実行します。
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;
手順8: プライマリ・スタンバイ・インスタンスおよびリスナーをシャットダウンする
プライマリ・スタンバイ・インスタンスをシャットダウンし、リスナーを停止します。
SHUTDOWN IMMEDIATE;
% lsnrctl stop listener_name
手順9: スタンバイ・ホストでメンテナンスを実行する
スタンバイ・ホストでメンテナンスを実行します。
Maximum Availability Architecture
9-55
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
10. データベースのフォルト・トレランスをリストアする
MAA のコンポーネントで障害が発生すると、MAA の完全な保護（フォルト・トレランス）が脆弱になり、コンポーネ
ントが修復されるまで、単一の障害箇所が発生する可能性があります。MAA を完全なフォルト・トレランス状態に戻し
て、完全な MAA の保護を回復させるには、障害が発生したコンポーネントを修復する必要があります。計画停止の際に
は完全なフォルト・トレランスが実現できない場合もありますが、停止が計画的で、修復方法がわかっているためリスク
を制御することが可能で、アプリケーションの継続使用の妨げにならない時期に障害が発生します。ただし、計画外停止
では、単一の障害箇所が発生するリスクを明確に理解しておく必要があります。
この項では、データベースのフォルト・トレランスをリストアする手順を中心に説明します。データベース層のフォルト・
トレランスのリストア処理は、次の項で詳しく説明しています。
•
Real Applications Clusters 内で障害が発生したノードまたはインスタンスをリストアする
•
フェイルオーバー後にスタンバイ・データベースをリストアする
•
セカンダリ・サイトまたはクラスタ全体の計画停止の後でフォルト・トレランスをリストアする
•
スタンバイ・データベースのデータのフェイルオーバー後にフォルト・トレランスをリストアする
•
スタンバイ・データベースのインスタンス化
•
二重障害後にフォルト・トレランスをリストアする
10.1
Real Applications Clusters内で障害が発生したノードまたは
内で障害が発生したノードまたは
インスタンスをリストアする
RAC クラスタ内、またはプライマリおよびセカンダリ・サイトの間でアプリケーション・サービスのフェイルオーバー
を迅速かつ自動的に行うことは、計画停止および計画外停止の両方を計画するうえで非常に重要です。また、RAC 内ま
たはサイト間のデータベースで障害が発生したインスタンスまたはノードをリストアする手順と処理を理解して、エラー
または問題を解決した後でこの環境が完全なフォルト・トレランスにリストアすることも重要です。
特定のコンポーネントで障害が発生下場合、原因となった中枢の問題を解決することにより、障害が発生したノードをク
ラスタに戻して追加したり、障害が発生したインスタンスを再開することは簡単です。ただし、ここでは次のことにも注
意する必要があります。
•
稼働中の環境に対して影響を最少（またはゼロ）にするために、これらのタスクをどのタイミングで実行するか
•
ネットワーク・コンポーネント（ロード・バランサまたは Oracle Net）のリセット（フェイルオーバーのために
修正されたものを、リセットする必要がある）
•
既存の接続のフェイルバックまたは再調整
（最初のフェイルオーバーに類似した）RAC 環境でアプリケーションがどのように稼働しているかによって、ノードまた
はインスタンスをどのようにリストアするか、および他の処理や手順を実行するかが決定されます。
最初にノードまたはインスタンスの障害の原因となった問題を修正した後は、ノードまたはインスタンスをリストアし、
随時に RAC 環境に戻すことができます。RAC インスタンスをリストアする場合には、Oracle インスタンスの STARTUP
コマンドのみ必要となります。変更または修正は必要ありません。ただし、ノードまたはインスタンスを再結合すると、
現行のワークロードでパフォーマンスが影響を受ける場合があります。
Maximum Availability Architecture
10-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
表10-1: ノードまたはインスタンスの再開または再結合におけるパフォーマンスへの影響
処理
ランタイム・アプリケーションの影響
ランタイム・アプリケーションの影響
ノードをリストアする、または
ノードをクラスタへ再結合する
このノードをクラスタに戻すために再構成を行う際に、パフォーマンスが影響を受
ける可能性があります。実行中のアプリケーションが影響を受けるかどうかは明確
ではありませんが、この影響は評価する必要があります。ノードをクラスタに再結
合する際の詳細な手順は、ベンダーが提供しているクラスタのドキュメントを参照
してください。
RAC デバイスを再開/再結合する
RAC インスタンスを再開する場合には、ロックの再構成中にパフォーマンスが影響
を受ける可能性があります。評価テストで、現行のアプリケーションに関する影響
が最少であることが示されても、適切なテスト・ワークロードで影響を評価する必
要があります。
したがって、ノードまたは RAC インスタンスをリストアする場合には次の内容の考慮が重要です。
•
ノードをクラスタへ再結合する場合、または Oracle RAC インスタンスを再開する場合には、負荷が高い状態で
パフォーマンスの影響をテストおよび評価する。
•
サービス・レベルが妥当で、クラスタ内でまだ複数の RAC インスタンスが有効な場合は、障害が発生したイン
スタンスをピーク時以外の作業期間に再結合するよう検討する。
ノードを開始し、クラスタへ結合させるための詳細な手順は、ベンダー固有のクラスタ管理ドキュメントを参照してくだ
さい。RAC インスタンスのリストアの詳細は、『Oracle9i Real Application Clusters 管理および配置ガイド』を参照してく
ださい。
10.1.1
RACインスタンスのリストア後のクライアント接続に関する留意点
インスタンスのリストア後のクライアント接続に関する留意点
RAC インスタンスをリストアした後で、アプリケーション構成、および実装されているネットワークのロード・バラン
シングにおける現行のリソースの使用率、またシステムのパフォーマンスによって、追加の手順が必要になることもあり
ます。
稼働中の RAC インスタンス上に、（フェイルオーバーした、または新しいセッションとして開始した）接続が存在して
いる場合は、自動的に再確立されたり、再開されたインスタンスへフェイルバックされたりすることはありません。現行
のリソース使用率、および残りのインスタンスの能力（特定のワークロードを妥当な応答時間内で適切に処理する能力）
によって、ユーザーのフェイルバックまたは再配置が必要かどうかが決まります。残りの RAC インスタンスで、過度の
ワークロードに対処できるリソースがなく、妥当な応答時間で処理できない場合は、事前にいくつかのユーザー接続を、
再開したインスタンスへ移動（切断および再接続）が必要となります。
新しい接続は、接続のロード・バランシングが設定されていることを前提として、必要な場合に、最小限使用されるノー
ド（この場合は、ほとんど接続されないリストアされたノード）で開始されます。したがって、新しい接続では、時間が
経過すると自動的にロード・バランシングが実現されます。
アプリケーションは次に示す場合が考えられます。
•
パーティション化されている（サービスが RAC インスタンスのサブセットで稼働している）
•
パーティション化されていない（すべてのサービスがすべてのノード間で同様に稼働している）
•
いくつかのサービスの組合せで構成されている（すべてのインスタンスで均等にロード・バランシングされてお
り、いくつかのサービスはインスタンスの特定のサブセットで稼働している）
これは、統合化されたデータ・セットを保持していくうえで、アプリケーションのモジュール化、およびデータベースの
フォーム/機能にとって非常に重要です。アプリケーションがパーティション化されている場合、またはパーティション
化と非パーティション化の組合せを持つ場合には、各サービスの応答時間および可用性を考慮する必要があります。特定
のサービスに対して接続の再配置またはフェイルバックが必要な場合は、これらの接続を正しく特定し（他のサービスの
接続と区別し）、移動する必要があります。
Maximum Availability Architecture
10-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
複数の RAC インスタンス間におけるロード・バランシングのアプリケーション・サービスに対しては、Oracle Net の接
続時フェイルオーバー、および（前述の項で説明した）接続のロード・バランシングの使用をお薦めします。この機能を
使用すると、フェイルオーバーまたはリストアの際に変更または修正が必要ありません。また、ハードウェア・ベースの
ロード・バランサも使用できます。ただし、（Oracle Net Services で認識されている）他のアプリケーション・サービス
と区別すること、およびインスタンスまたはノードをリストアすることにおいては制約を受ける場合もあります。たとえ
ば、ノードまたはインスタンスをリストアし、新しい接続の受信を開始できるようにする場合には、リストアされたノー
ドまたはインスタンスをハードウェア・ベースのロード・バランサ・ロジックに組み込むための、手動の手順が必要です。
次の表は、インスタンスをリストアした後の新しい接続と既存の接続に関する留意点についてまとめています。これらの
留意点は、アプリケーション・サービスがパーティション化されているか、非パーティション化されているか、または各
タイプの組合せで構成されているかによって異なります。前述のように、既存の接続を実際に再配置する必要があるかど
うかは、リソースの使用率および応答時間によって決まります。
表10-2: リストアおよび接続のフェイルバック
リストアおよび接続のフェイルバック
アプリケーション・
サービス
パーティション化
されている
パーティション化
されていない
組合せ:
非パーティション化
されている OLTP と
パーティション化
されているバッチ
既存の接続のフェイルバック
既存の接続のフェイルバック/リストア
フェイルバック リストア
新しい接続のフェイルバック
新しい接続のフェイルバック/リストア
フェイルバック リストア
既存の接続を特定することが必要。この接続
は、インスタンスをリストアした後でフェイル
バックする必要があります。その他の場合は、
新しいユーザーが元のインスタンスへ、既存の
ユーザーがフェイルオーバーされたインスタン
スに定義されます。
フェイルバックは、フェイルオーバーしたイン
スタンスからユーザーを切断し、元のインスタ
ンスへ再接続することを意味します。
•
Oracle Net Services の設定またはハードウ
ェア・ベースのロード・バランサを介し
て、リストアしたインスタンスへ自動的
にルーティングします。
•
ハードウェア・ベースのロード・バラン
シングがフェイルオーバーに対して修正
されている場合は、リストアに対して再
度修正する必要があります。
インスタンスをリストアするということは負荷
が低いことを意味するため、負荷を再調整する
必要がないかぎり、これは問題にはなりませ
ん。負荷の再調整が必要な場合は、アプリケー
ション・サービスがパーティション化されてい
る場合と同じ問題が発生します。
•
Oracle Net Services の設定またはハードウ
ェア・ベースのロード・バランサを介し
て、リストアしたインスタンスへ自動的
にルーティングします（負荷が低いた
め）。
•
ハードウェア・ベースのロード・バラン
シングがフェイルオーバーに対して修正
されている場合は、リストアに対して再
度修正する必要があります。
バッチ・ジョブのフェイルバック。既存の接 •
続を特定することが必要。この接続は、イン
スタンスをリストアした後でフェイルバッ
クする必要があります。その他の場合は、新
しいユーザーが元のインスタンスに、既存の
ユーザーがフェイルオーバーされたインス •
タンスに定義されます。フェイルバックは、
ユーザーを切断し、元のインスタンスに再接
続することを意味します。
Oracle Net Services の設定またはハードウ
ェア・ベースのロード・バランサを介し
て、リストアしたインスタンスに自動的
にルーティングします（負荷が低いた
め）。
•
•
ハードウェア・ベースのロード・バラン
シングがフェイルオーバーに対して修正
されている場合は、リストアに対して再
度修正する必要があります。
インスタンスをリストアするということは
負荷が低いことを意味するため、負荷を再調
整する必要がないかぎり、非パーティション
化されている OLTP は問題にはなりません。
負荷の再調整が必要な場合は、アプリケーシ
ョン・サービスがパーティション化されてい
る場合と同様の問題が発生します。
図 10-1 は、2 ノードの RAC データベースを表しています。ここでは、アプリケーションがパーティション化されていま
す。したがって、各インスタンスはアプリケーションの異なる部分（この例では HR（人事管理）や Sales（販売）など）
に対してサービスを提供します。クライアント処理は、必要なサービスに基づいて、適切なインスタンスに接続します。
Maximum Availability Architecture
10-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
図10-1: パーティション化された2ノードの
データベース
パーティション化された ノードのRACデータベース
ノードの
図 10-2 は、RAC インスタンスが失敗した場合の状態を表しています。1 つの RAC インスタンスが失敗すると、サービス
および既存のクライアント接続は、他の RAC インスタンスへ自動的にフェイルオーバーが可能です。この例では、残り
の有効な RAC インスタンスによって、人事管理と販売の両方のサービスがサポートされています。また、人事サービス
に対する新しいクライアント接続を、このサービスを現在サポートしているインスタンスにルーティングできます。
図10-2: パーティション化されたデータベースにおけるRACインスタンスの障害
インスタンスの障害
パーティション化されたデータベースにおける
図 10-1 のように、障害が発生したインスタンスを修復およびリストアした後では、フェイルオーバーされたクライアン
トと、フェイルオーバーされたインスタンスの人事管理サービスに接続されていた新しいクライアントは同一のものとみ
なされ、フェイルバックする必要があります（インスタンスのリストア後に開始された新しいクライアント接続は、元の
インスタンスへ自動的に接続されます。したがって、時間が経過して、古い接続が切断されて新しいセッションが人事管
Maximum Availability Architecture
10-4
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
理サービスに接続されると同時に、クライアントの負荷が、リストアされたインスタンスへ移行されます。リストアの後
ですぐに負荷を再調整するかは、リソースの使用率およびアプリケーションの応答時間によって決まります）。
図 10-3 は、パーティション化されていないアプリケーションを表しています（ただし、サービスが有効なすべてのイン
スタンスで均等に配置されていません）。各インスタンスには、人事管理と販売の両方に対するクライアント接続が混在
しています。
図10-3: パーティション化されていないRACインス
インスタンス
パーティション化されていない
インスタンス
図 10-4 は、RAC インスタンスが失敗した場合の状態を表しています。1 つの RAC インスタンスが失敗すると、既存のク
ライアント接続は、他の RAC インスタンスへ自動的にフェイルオーバーが可能です。また、新しいクライアント接続は、
有効な RAC インスタンスにのみルーティングされます。
図10-4: アプリケーションがパーティション化されていない場合の1つの
インスタンスにおける障害
アプリケーションがパーティション化されていない場合の つのRACインスタンスにおける障害
つの
Maximum Availability Architecture
10-5
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
図 10-3 のように、障害が発生したインスタンスを修復およびリストアした後で、いくつかのクライアントを、リストア
したインスタンスに戻す必要がある場合があります。パーティション化されていないアプリケーションでは、有効なすべ
のインスタンス間でクライアントの負荷を再調整するために、該当するサービスの特定が必要ありません。また、これは、
シングル・インスタンスで要求に対して十分なサービスを提供できない場合にのみ必要です。（注意: インスタンスのリ
ストア後に開始された新しいクライアント接続は、リストアされたインスタンスへ自動的に接続されます。これは、この
インスタンスが最も負荷が少ないためです。したがって、時間が経過して古い接続が切断され、新しいセッションが、リ
ストアされたインスタンスに接続と同時に、クライアントの負荷は、有効なすべての RAC インスタンスで再調整されま
す。リストア後すぐに負荷を再調整するかは、リソースの使用率およびアプリケーションの応答時間によって決まります）。
10.1.2
RACインスタンスのリストア後のロジカル・スタンバイのクライアント接続に関
インスタンスのリストア後のロジカル・スタンバイのクライアント接続に関
する留意点
RAC インスタンスをリストアした後のクライアント接続に関する説明は、ロジカル・スタンバイ・データベースに接続
されるクライアント接続と同様に適用されます。障害が発生した RAC インスタンスに接続されていたクライアントは、
別の RAC インスタンスへ自動的にフェイルオーバーできます。障害が発生したインスタンスを修復およびリストアした
後で、いくつかのクライアントを、リストアしたインスタンスに戻す必要がある場合があります。「データベース・サー
バー層－スタンバイ・インスタンス・フェイルオーバー」によって移動された場合は、ロジカル・スタンバイ・プロセス
にスイッチ・バックが可能な場合もあります。
Maximum Availability Architecture
10-6
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
10.2
フェイルオーバー後にスタンバイ・データベースをリストアする
本番データベースが計画外に停止して、完全なリカバリまたは強制フェイルオーバーによるフェイルオーバーが必要にな
った場合は、フィジカル・スタンバイ・データベースが再度インスタンス化まで完全なフォルト・トレランスは実現され
ません。すべてのデータベースの保護は、できるかぎり迅速にリストアが必要です。
•
フェイルオーバー後にフィジカル・スタンバイ・データベースをリストアする
•
フェイルオーバー後にロジカル・スタンバイ・データベースをリストアする
10.2.1
フェイルオーバー後にフィジカル・スタンバイ・データベースをリストアする
再インスタンス化処理のいくつかの手順は、実行するフェイルオーバーのタイプ（完全なリカバリが必要なフェイルオー
バー、強制フェイルオーバーなど）によって多少異なります。これらの違いは、以降の手順で詳しく説明します。
フェイルオーバー後に完全なフォルト・トレランスのリストアには、次の手順が必要です。
•
手順 1: フェイルオーバーSCN を取得する
•
手順 2: 新しいスタンバイ・データベースへホスティングされているサイトへバックアップをリストアする
•
手順 3: フェイルオーバーSCN の後でアーカイブをリストアする
•
手順 4: 新しいスタンバイ制御ファイルを作成する
•
手順 5: 新しいスタンバイ・データベースを開始およびマウントする
•
手順 6: スタンバイでログ転送サービスを遅延させる
•
手順 7: 管理されたリカバリを開始する
•
手順 8: 本番でログ転送サービスを検証する
•
手順 9: 管理されたリカバリがスタンバイで処理中であることを検証する
手順1:
を取得する
手順 フェイルオーバーSCNを取得する
フェイルオーバー
このフェイルオーバーSCN は、フェイルオーバーの後で、新しい本番データベース・バックアップのかわりに本番デー
タベースの古いバックアップを使用して、新しいスタンバイ・データベースを再作成する場合に重要です。フェイルオー
バー・コマンドのアラート・ログの出力は、実行するフェイルオーバーのタイプによって異なります。
完全なリカバリを行うフェイルオーバーの後
完全なリカバリを行うフェイルオーバーを実行した後では、アラート・ログに次のメッセージが示されます。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIAMRY NORESETLOGS after
complete recovery through change 56985
Switchover: Complete - Database shutdown required
Completed: alter database commit to switchover to primary
この例では、フェイルオーバーSCN は 56985 です。
Maximum Availability Architecture
10-7
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
強制フェイルオーバーの後
強制フェイルオーバーの実行後では、アラート・ログに次のメッセージが示されます。
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE
RESETLOGS after incomplete recovery UNTIL CHANGE 77637
Resetting resetlogs activation ID 2547644951 (0x97d9fa17)
この例では、フェイルオーバーSCN は 77637 です。
手順2:
手順 新しいスタンバイ・データベースへホスティングされているサイトへ
新しいスタンバイ・データベースへホスティングされているサイトへ
バックアップをリストアする
完全なリカバリを行うフェイルオーバーの後
新しい本番データベースと同じインカネーションを持つ、データ・ファイルのバックアップのみリストアします（制
御ファイルはリストアしません）。この手順で使用する有効なバックアップは、次のとおりです。
御ファイルはリストアしません）
•
フェイルオーバー後に新しい本番データベースで取得されたバックアップ。
•
フェイルオーバー前にいずれかのサイトで取得されたデータ・ファイルのバックアップ。具体的には、フェ
イルオーバー前の古い本番データベースのデータ・ファイルのバックアップ、または新しい本番データベー
スとして使用される前の、以前のスタンバイ・データベースのデータ・ファイルのバックアップが存在しま
す。
強制フェイルオーバーの後
（データ・ファイルのみ、またはデータ・ファイルと制御ファイルなど）、リストアするファイルは使用するバック
アップが取得されたタイミングによって異なります。この手順で使用する有効なバックアップは、次のとおりです。
•
フェイルオーバー後に新しい本番データベースで取得されたバックアップ。新しい本番のバックアップを使
用する場合は、データ・ファイルのみリストアします。
用する場合は、データ・ファイルのみリストアします。
•
フェイルオーバー前にいずれかのサイトで取得されたデータ・ファイルのバックアップ。具体的には、フェ
イルオーバー前の古い本番データベースのデータ・ファイルのバックアップ、または新しい本番データベー
スとして使用される前の、以前のスタンバイ・データベースのデータ・ファイルのバックアップが存在しま
す。フェイルオーバー前のバックアップを使用する場合は、制御ファイルとデータ・ファイルをリストア
フェイルオーバー前のバックアップを使用する場合は、制御ファイルとデータ・ファイルをリストア
します。
強制フェイルオーバー前のデータ・ファイルは、継続する前に、（手順 1 で取得した）フェイルオーバーSCN
までリカバリする必要があります。
手順 2.1: バックアップ制御ファイルを使用して、スタンバイ・データベースを開始およびマウントする
STARTUP NOMOUNT;
ALTER DATABASE MOUNT;
手順 2.2: ログ転送サービスを遅延させる
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=MEMORY;
手順 2.3: 強制フェイルオーバーSCN
までリカバリする
強制フェイルオーバー
RECOVER DATABASE UNTIL CHANGE <forced failover SCN> USING BACKUP
CONTROLFILE;
手順 2.4: シャットダウン
SHUTDOWN IMMEDIATE;
Maximum Availability Architecture
10-8
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
手順3:
の後でアーカイブをリストアする
手順 フェイルオーバーSCNの後でアーカイブをリストアする
フェイルオーバー
完全なリカバリを行うフェイルオーバーの後
フェイルオーバー（次の図 10-5 の Time B）以降に生成された必要なアーカイブ・ログを、新しい本番データベース・
ホストから新しいスタンバイ・ホストにすべてコピーします。Time B 以降に元の本番データベースで生成されたア
ーカイブ・ログを適用すると、このデータベースを破損することがあるため、これは非常に重要な手順です。図 10-5
では、Time B 以降のアーカイブは、2 つのデータベースにおいて異なります。新しいスタンバイ・データベースを作
成する場合には、新しい本番データベースのアーカイブを適用する必要があります。2 つのホスト間でアーカイブに
同じ名前を定義しているにもかかわらず、Time B 以降は内容が異なるという状態は避けてください。不正なアーカ
イブを適用すると、スタンバイ・データベースが正しいリカバリ・パスから外れることになり、バックアップからの
スタンバイ・データベースの再作成が必要になります。
図10-5: フェイルオーバーのタイムライン
新しい本番データベースから次の問合せを発行して、スタンバイ・ホストにコピーされたアーカイブを特定します。
SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG
WHERE NEXT_CHANGE# >= (SCN from alert.log);
Time B 以前の前のアーカイブ・ログは、2 つのデータベース間で同一です。
強制フェイルオーバーの後
新しいスタンバイ・データベースに対応していない現行のスタンバイ・ホストから、すべてのアーカイブをバックア
ップします。すべてのスレッドに対してシーケンス 1 から始まる、必要なアーカイブ・ログを新しい本番データベー
ス・ホストから新しいスタンバイ・ホストにすべてコピーします。
手順4:
手順 新しいスタンバイ制御ファイルを作成する
新しい本番データベースで新しいスタンバイ制御ファイルを作成し、それを古い本番データベースの制御ファイルに
コピーしてかわりに使用します。
ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘name’;
Maximum Availability Architecture
10-9
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
手順5:
手順 新しいスタンバイ・データベースを開始およびマウントする
SPFILE がすでに準備されている場合は、新しいスタンバイ・データベースを開始し、マウントします。
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
手順6:
手順 スタンバイでログ転送サービスを遅延させる
スタンバイでログ転送サービスを遅延させる
スタンバイに対してリモート・アーカイブを無効にします。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=MEMORY;
手順7:
手順 管理されたリカバリを開始する
RECOVER MANAGED STANDBY DATABASE
手順8:
手順 本番でログ転送サービスを検証する
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’;
手順9:
手順 管理されたリカバリがスタンバイで処理中であることを検証する
MRP でエラーがなく、ログにリカバリが適用されていることを確認し、リカバリが新しいスタンバイ・データベー
ス上で処理中であることを検証します。
SELECT MAX (SEQUENCE#), THREAD# FROM V$LOG_HISTORY GROUP BY THREAD;
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, CLIENT_PROCESS FROM
V$MANAGED_STANDBY;
10.2.2
フェイルオーバー後にロジカル・スタンバイ・データベースをリストアする
ロジカル・スタンバイ・データベースにフェイルオーバーした後は、フィジカル・スタンバイ・データベースへのフェイ
ルオーバーが行われるため、元のプライマリ・データベースにリストアできません。したがって、ロジカル・スタンバイ・
データベースへのフェイルオーバーの後に完全なフォルト・トレランスをリストアするには、新しいスタンバイ・データ
ベースのインスタンス化が必要です。詳細は、「スタンバイ・データベースのインスタンス化」を参照してください。
Maximum Availability Architecture
10-10
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
10.3
セカンダリ・サイトまたはクラスタ全体の計画停止の後で
フォルト・トレランスをリストアする
セカンダリ・サイトまたはクラスタ全体で計画停止の発生後で、完全なフォルト・トレランスのリストアには、次の手順
が必要です。
•
手順 1: スタンバイ・データベースを開始およびマウントする
•
手順 2: スタンバイでログ転送サービスを遅延させる
•
手順 3: 管理されたリカバリを開始する
•
手順 4: 本番でログ転送サービスを検証する
•
手順 5: 管理されたリカバリがスタンバイで処理中であることを検証する
•
手順 6: 本番データベースの保護モードをリストアする
手順1:
手順 スタンバイ・データベースを開始する
スタンバイ・データベースを開始します。
フィジカル・スタンバイ・データベースでは次のコマンドを実行します。
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ロジカル・スタンバイ・データベースでは次のコマンドを実行します。
STARTUP;
手順2:
手順 スタンバイでログ転送サービスを遅延させる
スタンバイに対してリモート・アーカイブを無効にします。
フィジカル・スタンバイ・データベースでは次のコマンドを実行します。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=MEMORY;
ロジカル・スタンバイ・データベースでは次のコマンドを実行します。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=MEMORY;
フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方を備えた MAA 環境では、次
のコマンドを実行します。
フィジカル・スタンバイ・データベース
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=MEMORY;
ロジカル・スタンバイ・データベース
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=MEMORY;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=DEFER SCOPE=MEMORY;
Maximum Availability Architecture
10-11
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
手順3:
手順 リカバリを開始する
フィジカル・スタンバイ・データベースでは次のコマンドを実行します。
RECOVER MANAGED STANDBY DATABASE
ロジカル・スタンバイ・データベースでは次のコマンドを実行します。
ALTER DATABASE START LOGICAL STANDBY APPLY
手順4:
手順 本番でログ転送サービスを検証する
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’;
手順5:
手順 スタンバイでリカバリが処理中であることを検証する
新しいスタンバイ・データベースでリカバリが処理中であることを検証します。
フィジカル・スタンバイ・データベースで、MRP のエラーがないこと、およびログにリカバリが適用されているこ
とを確認します。
SELECT MAX(SEQUENCE#), THREAD# FROM V$LOG_HISTORY GROUP BY THREAD;
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, CLIENT_PROCESS FROM
V$MANAGED_STANDBY;
ロジカル・スタンバイ・データベースで、LSP のエラーがないこと、およびログにリカバリが適用されていることを
確認します。
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#
手順6:
手順 本番データベースの保護モードをリストアする
スタンバイ・データベースの停止によって、本番データベースの保護モードを、最大保護モードから、最大可用性モ
ードまたは最大パフォーマンス・モードへ変更する必要がある場合は、本番データベースの保護モードを最大保護モ
ードに戻します。「データベースの保護モードを設定する」の「Oracle Data Guard」に記載されている手順に従って
ください。
Maximum Availability Architecture
10-12
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
スタンバイ・データベースのデータ障害後にフォルト・トレランスを
リストアする
10.4
完全または部分的なデータ・ファイルのリストアを必要とする、スタンバイ・データベースの計画外停止（データまたは
メディアの障害など）の後では、フィジカル・スタンバイ・データベースでサービスが回復するまで完全なフォルト・ト
レランスは実現できなくなります。すべてのデータベースの保護は、できるかぎり迅速なリストアが必要です。HARD
を使用すると、このような問題を回避できます。詳細は、「ストレージ」を参照してください。
スタンバイ・データベースのデータ障害後に完全なフォルト・トレランスのリストアには、次の手順が必要です。
•
手順 1: 停止の原因を特定する
•
手順 2: 影響を受けたデータ・ファイルのバックアップをリストアする
•
手順 3: 必要なアーカイブ・ログ・ファイルをリストアする
•
手順 4: スタンバイ・データベースを開始およびマウントする
•
手順 5: スタンバイでログ転送サービスを遅延させる
•
手順 6: 管理されたリカバリを開始する
•
手順 7: 本番でログ転送サービスを検証する
•
手順 8: 管理されたリカバリがスタンバイで処理中であることを検証する
•
手順 9: 本番データベースの保護モードをリストアする
手順1:
手順 停止の原因を特定する
停止の根本的な原因を調べて、将来的に同様の停止が発生しないように対処する必要があります。
手順2:
手順 影響を受けたデータ・ファイルのバックアップをリストアする
スタンバイ・サイトで、影響を受けたデータ・ファイルのみをリストアする必要があります。
手順3:
手順 必要なアーカイブ・ログ・ファイルをリストアする
次のように、リストアされたデータ・ファイルを、設定された遅延までリカバリするためにアーカイブ・ログ・ファ
イルのリストアが必要な場合があります。
•
リカバリに必要なアーカイブが、設定されているログ・アーカイブ宛先のスタンバイ・システムで使用でき
る状態になっている場合は、MRP が必要な場合にアーカイブを自動的に検出および適用します。リストアは
必要ありません。
•
必要なアーカイブがスタンバイ・システムから削除されており、本番システムではまだ有効になっている場
合は、必要なアーカイブをスタンバイ・システムに転送するために、FAL が自動的に起動されます。リスト
アは必要ありません。
•
リストアされたデータ・ファイルを、設定されている遅延までリカバリするために必要なアーカイブが、本
番システムとスタンバイ・システムの両方で削除されている場合は、スタンバイ・システムでこれらのアー
カイブをリストアする必要があります。
Maximum Availability Architecture
10-13
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
手順4:
手順 スタンバイ・データベースを開始する
ターゲットのスタンバイ・インスタンスから次の問合せを実行します。
SELECT OPEN_MODE, DATABASE_ROLE FROM V$DATABASE;
フィジカル・スタンバイで必要な出力は次のとおりです。
MOUNTED PHYSICAL STANDBY
マウントされていない場合は、他のターゲット・スタンバイ・インスタンスを選択するか、またはこのスタンバイ・
インスタンスを手動でマウントします。
STARTUP NOMOUNT
ALTER DATABASE MOUNT STANDBY DATABASE;
ロジカル・スタンバイで必要な出力は次のとおりです。
READ WRITE LOGICAL STANDBY
読込み/書込みに対してオープンされていない場合は、他のターゲット・スタンバイ・インスタンスを選択するか、
またはこのスタンバイ・インスタンスを手動でオープンします。
STARTUP
手順5:
手順 スタンバイでログ転送サービスを遅延させる
スタンバイに対してリモート・アーカイブを無効にします。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=MEMORY;
手順6:
手順 リカバリを開始する
フィジカル・スタンバイ・データベースでは次のコマンドを実行します。
RECOVER MANAGED STANDBY DATABASE
ロジカル・スタンバイ・データベースでは次のコマンドを実行します。
ALTER DATABASE START LOGICAL STANDBY APPLY
手順7:
手順 本番でログ転送サービスを検証する
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’;
Maximum Availability Architecture
10-14
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
手順8:
手順 スタンバイでリカバリが処理中であることを検証する
新しいスタンバイ・データベースでリカバリが処理中であることを検証します。
フィジカル・スタンバイ・データベースで、MRP のエラーがないこと、およびログにリカバリが適用されているこ
とを確認します。
SELECT MAX (SEQUENCE#), THREAD# FROM V$LOG_HISTORY GROUP BY THREAD;
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, CLIENT_PROCESS FROM
V$MANAGED_STANDBY;
ロジカル・スタンバイ・データベースで、LSP のエラーがないこと、およびログにリカバリが適用されていることを
確認します。
SELECT THREAD#, SEQUENCE# SEQ#
FROM DBA_LOGSTDBY_LOG LOG, DBA_LOGSTDBY_PROGRES PROG
WHERE PROG.APPLIED_SCN BETWEEN LOG.FIRST_CHANGE# AND LOG.NEXT_CHANGE#
ORDER BY NEXT_CHANGE#
手順9:
手順 本番データベースの保護モードをリストアする
スタンバイ・データベースの停止によって、本番データベースの保護モードを、最大保護モードから、最大可用性モ
ードまたは最大パフォーマンス・モードへ変更する必要がある場合は、本番データベースの保護モードを最大保護モ
ードに戻します。「データベースの保護モードを設定する」の「Oracle Data Guard」に記載されている手順に従って
ください。
Maximum Availability Architecture
10-15
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
スタンバイ・データベースのインスタンス化
10.5
次の手順を使用して、スタンバイ・データベースを作成できます。本番システムとスタンバイ・システムは、前述の「シ
ステム構成」の項で推奨したように、同様に構成する必要があります。
最初のフィジカル・スタンバイ・データベースのインスタンス化
10.5.1
最初のフィジカル・スタンバイ・データベースを作成するには、次の手順が必要です。詳細は、『Oracle9i Data Guard 概
要および管理』を参照してください。
•
手順 1:
本番データベースのバックアップをスタンバイ・クラスタにリストアする
•
手順 2:
スタンバイの初期化パラメータ・ファイル（SPFILE）および Oracle Net ファイルを設定する
•
手順 3:
本番でスタンバイ REDO ログが作成されていることを確認する
•
手順 4:
スタンバイ制御ファイルを作成する
•
手順 5:
アーカイブをスタンバイにコピーまたはリストアする
•
手順 6:
スタンバイ・データベースを開始およびマウントする
•
手順 7:
スタンバイ・データベースのログ転送サービスを遅延させる
•
手順 8:
管理されたリカバリを開始する
•
手順 9:
本番でログ転送サービスを検証する
•
手順 10: 管理されたリカバリがスタンバイで処理中であることを検証する
手順1:
手順
本番データベースのバックアップをスタンバイ・クラスタにリストアする
手順2:
手順
スタンバイの初期化パラメータ・ファイル（SPFILE）および
スタンバイの初期化パラメータ・ファイル（
）およびOracle
Netファイル
ファイル
）および
を設定する
詳細は、「Oracle Data Guard」の構成の項および「付録 C」を参照してください。
手順3:
手順
本番でスタンバイREDOログが作成
ログが作成されていることを確認する
本番でスタンバイ
ログが作成されていることを確認する
スタンバイ REDO ログの定義は、本番とスタンバイで同じです。「Oracle Data Guard」の項に記載されているガイド
ラインを使用してください。
手順4:
手順
スタンバイ制御ファイルを作成する
本番データベースから新しいスタンバイ制御ファイルを作成し、それをスタンバイ・クラスタにコピーします。
ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘name’;
手順5:
手順
アーカイブをスタンバイにコピーまたはリストアする
バックアップが作成された以降に生成されたアーカイブ REDO ログをすべて、スタンバイ・クラスタにコピーしま
す。バックアップの年齢、およびディスク上でアーカイブが保持される長さによって、テープ・バックアップからの
ファイルのリストアが必要になる場合があります。
Maximum Availability Architecture
10-16
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
手順6:
手順
スタンバイ・データベースを開始およびマウントする
STARTUP NOMOUNT
ALTER DATABASE MOUNT STANDBY DATABASE;
手順7:
手順
スタンバイ・データベースのログ転送サービスを遅延させる
スタンバイに対してリモート・アーカイブを無効にします。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=MEMORY;
手順8:
手順
管理されたリカバリを開始する
RECOVER MANAGED STANDBY DATABASE DISCONNECT;
手順9:
手順
本番でログ転送サービスを検証する
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’;
手順10:
管理されたリカバリがスタンバイで処理中であることを検証する
手順
MRP でエラーがなく、ログにリカバリが適用されていることを確認し、リカバリが新しいスタンバイ・データベー
ス上で処理中であることを検証します。
SELECT MAX(SEQUENCE#), THREAD# FROM V$LOG_HISTORY GROUP BY THREAD;
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, CLIENT_PROCESS FROM
V$MANAGED_STANDBY;
10.5.2
ロジカル・スタンバイ・データベースのインスタンス化
ロジカル・スタンバイ・データベースへのフェイルオーバーの後で、新しいプライマリ・データベースから新しいロジカ
ル・スタンバイ・データベースをインスタンス化し、完全なフォルト・トレランスを実現する必要があります。
Maximum Availability Architecture
10-17
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
データベースのフォルト・トレランスをリストアする
10.6
ロジカル・スタンバイ・データベースの作成
必要な手順は、『Oracle9i Data Guard 概要と管理』の第 4 章「ロジカル・スタンバイ・データベースの作成」を参照して
ください。
10.7
二重障害後にフォルト・トレランスをリストアする
スタンバイ・データベースと本番データベースの両方に影響を及ぼす二重障害が発生した場合は、最初に本番データベー
スを再作成する必要があります。これらの 2 つのサイトは同じになっているため、最も新しいバックアップが存在するタ
イミングで、いつでも本番データベースを作成できます。
次の表は、使用できるバックアップのタイプによるリカバリ方針について詳しく説明しています。
表10-3: 本番およびスタンバイ・データベースを再作成する
使用できるバックアップ
本番データベースの再作成
スタンバイ・データベースの再作成
本番およびスタンバイ・データ 本番データベースからバックアッ ローカル・バックアップからフィジカル・スタンバ
ベースにおけるローカル・バッ プをリストアします。不完全リカ イ・データベースをリストアする場合は、「フェイ
クアップ
バリを行い、新しい本番データベ ルオーバー後にスタンバイ・データベースをリスト
ースとしてデータベースを有効化 アする」の手順に従ってください。
します。
ローカル・バックアップからロジカル・スタンバイ・
データベースをリストアする場合は、「スタンバ
イ・データベースのインスタンス化」の手順に従っ
て、新しい本番データベースからスタンバイ・デー
タベースを再作成します。
スタンバイのみのローカル・バ
ックアップ
スタンバイのテープ・バックア
ップ
ローカルのスタンバイ・バックア
ップをスタンバイ・データベース
にリストアします。不完全リカバ
リを行い、新しい本番データベー
スとして有効化します。
フィジカル・スタンバイ・データベースをリストア
する場合は、「フェイルオーバー後にスタンバイ・
データベースをリストアする」の手順に従って、新
しい本番データベースからスタンバイ・データベー
スを再作成します。
ローカル・バックアップからロジカル・スタンバイ
をリストアする場合は、「スタンバイ・データベー
スのインスタンス化」の手順に従って、新しい本番
データベースからスタンバイ・データベースを再作
成します。
テープ・バックアップのみ
テープ・バックアップをローカル
にリストアします。本番データベ
ースをリカバリし、新しい本番デ
ータベースとして有効化します。
フィジカル・スタンバイ・データベースをリストア
する場合は、「フェイルオーバー後にスタンバイ・
データベースをリストアする」の手順に従って、新
しい本番データベースからスタンバイ・データベー
スを再作成します。
ローカル・バックアップからロジカル・スタンバイ
をリストアする場合は、「スタンバイ・データベー
スのインスタンス化」の手順に従って、新しい本番
データベースからスタンバイ・データベースを再作
成します。
Maximum Availability Architecture
10-18
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
11. まとめ
Maximum Availability Architecture は、Oracle の最高の高可用性ソリューションであり、次の特長があります。
•
データとアーカイブの高可用性を保護するためのアーキテクチャ・コンポーネント
•
Real Application Clusters や Data Guard などの主要な Oracle 機能
•
運用上のベスト・プラクティス
•
構成ベスト・プラクティス
•
高可用性ソリューションとなる停止決定マトリックス
•
高可用性ソリューションを実装するための手順とベスト・プラクティス
MAA は HA を採用し、どのような障害も透過的に処理されるように、または優れた MTTR を達成する完全に自動化され
たリカバリ手順で処理を実行します。運用および構成のベスト・プラクティスで MAA を設定した後は、停止決定マトリ
ックスと詳細ソリューションを使用して、すべての潜在的停止に対処できる完全な高可用性ソリューションを構築するこ
とをお薦めします。必要な MTTR を実現できるよう、配置全体をリハーサルしておく必要があります。
自動化といくつかのテストの後、次のような MAA プラクティスを活用することによって、高い可用性要件を満たせるよ
うにします。
•
クライアントをセカンダリ・サイトにルーティング変更するための、ワイド・エリア・トラフィック・マネージ
ャを使用した高速サイト・フェイルオーバー
•
ハードウェアまたはソフトウェア・ベースのロード・バランサと中間層アプリケーション・サーバー・ファーム
による透過的なアプリケーション層フェイルオーバー
•
透過的アプリケーション・フェイルオーバーおよび Real Application Clusters によるホストおよびインスタンスの
フェイルオーバー
•
Data Guard スイッチオーバーを使用した計画保守のための、プライマリ・サイトとセカンダリ・サイト間のデー
タベース・ロール反転
•
ユーザー・エラー、データ・エラー、サイト障害から保護するための、Data Guard フェイルオーバーを使用した
スタンバイ・データベースへのデータベース・フェイルオーバー
MAA は、
顧客の実装経験による情報と内部テストの結果を取り入れ日々強化されています。将来的なプロジェクトには、
ロジカル・スタンバイ・データベースのような Oracle 機能と、まだリリースされていない機能も対象とする予定です。
MAA の拡張機能は、オラクル社のメール・サーバー・アプリケーション、カスタマ・リレーションシップ・マネジメン
ト（CRM）アプリケーション、Enterprise Resource Planning（ERP）アプリケーションのような様々なアプリケーション・
インフラストラクチャを使用して妥当性が検証されます。
高可用性ソリューションの作成、テスト、妥当性チェックおよび設計のために、Server Technologies’ High Availability
Systems Group が設立されています。このグループの目標の 1 つは、顧客が簡単に HA を配置できるようにすること、お
よび完全性を保証することです。それには、配置が容易で管理しやすく、顧客のサービス・レベルを満たすことができる
統合された Oracle HA ソリューションが必要です。このホワイト・ペーパーで説明した機能と手動手順の多くは、最終的
には自動化され、将来の Oracle リリースに組み込まれる予定です。Oracle HA ソリューションをより透過的で管理しやす
くするための改善が続けられます。
最新の更新情報を取得するには、http://otn.oracle.com/deploy/availability/htdocs/maa.htm を参照してください。
Maximum Availability Architecture
11-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
第 5 部: 付録
第 5 部は、次の項で構成されています。
•
付録A「主なアーキテクチャ変更におけるリスク評価」
•
付録B「運用上のベスト・プラクティス」
•
付録C「データベースSPFILEおよびOracle Net構成ファイルの例」
•
付録D「テスト構成」
•
付録E「オブジェクトの再編成とリカバリの例」
•
付録F「サーバー・パラメータ・ファイル（SPFILE）」
Maximum Availability Architecture
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
12. 付録A
付録 - 主なアーキテクチャ変更におけるリスク評価
Maximum Availability Architecture は、最高の Oracle HA アーキテクチャを提供します。ただし、システム・アーキテクチ
ャを設計する場合、可用性のニーズ、アプリケーション・パフォーマンスの要件、および IT に関するコストの制約のバ
ランスを考慮する必要があります。この項では、様々なアーキテクチャ・ソリューション、およびそのデメリットと関連
するリスクを詳しく説明し、代替のアーキテクチャに焦点をあてて説明します。
そのようなアーキテクチャでは、MAA のメインのアーキテクチャ・コンポーネント（RAC、Data Guard、セカンダリ・
サイトなど）を削除することに焦点をあてています。ただし、このコンポーネントを削除すると、そのメリットも得られ
なくなります。たとえば、環境から RAC を削除するには様々な方法がありますが、どの場合でも、高速フェイルオーバ
ーの機能が失われたり、システムを停止することなく業務に影響を与えずに計画的なメンテナンスを行えないなど、重要
な機能が失われ、またリジリエンスが排除されるとリスクが高まります。
次の表は、MAA および代替のアーキテクチャの違いを比較したもので、代替のアーキテクチャに伴うリスクの分野をそ
れぞれ特定しています。各アーキテクチャの詳細な説明と図は、その後に記載しています。
表12-1: MAAと代替のアーキテクチャ
と代替のアーキテクチャ
代替のアーキテクチャ
アーキテクチャにおける MAA との違い
失われる機能またはデメリット
（詳細は次参照）
プライマリ・サイト: RAC 本番
セカンダリ・サイトの RAC がシングル・ 計画的なメンテナンス
セカンダリ・サイト: Data Guard のシ インスタンスを実行するシングル・シス 高速なフェイルオーバー機能
ングル・インスタンス・スタンバイ テムで置き換えられる。
処理能力
運用上の複雑さ
プライマリ・サイト: シングル・イン プライマリおよびセカンダリ・サイトの 計画的なメンテナンス
スタンスの本番
RAC が、両方のサイトのシングル・イン 高速なフェイルオーバー機能
セカンダリ・サイト: Data Guard のシ スタンスで置き換えられる。
スケーラビリティ
ングル・インスタンス・スタンバイ
プライマリ・サイト: RAC の本番、お セカンダリ・サイトが削除されるが、同 サイトの障害の保護
よび RAC スタンバイを使用する Data じ LAN 上の別の RAC クラスタにフィジ
Guard
カル・スタンバイ・データベースが追加
される。
セカンダリ・サイト: なし
プライマリ・サイト: RAC の本番およ セカンダリ・サイトが削除され、同じ LAN サイトの障害の保護
びシングル・インスタンス・スタンバ 上の別のホストにフィジカル・スタンバ 計画的なメンテナンス
イを持つ Data Guard
イ・データベースが追加される。
高速なフェイルオーバー機能
セカンダリ・サイト: なし
処理能力
運用上の複雑さ
プライマリ・サイト: シングル・イン プライマリ・サイトからセカンダリ・サ サイトの障害の保護
スタンスの本番および Data Guard の イトおよび RAC が削除され、同じ LAN 計画的なメンテナンス
シングル・インスタンス・スタンバイ 上の別のホストにフィジカル・スタンバ 高速なフェイルオーバー機能
イ・データベースが追加される。
セカンダリ・サイト: なし
スケーラビリティ
運用上の複雑さ
プライマリ・サイト: RAC 本番
セカンダリ・サイト: なし
Maximum Availability Architecture
セカンダリ・サイトが削除される。
ユーザー・エラーまたは破損の
リカバリ
サイトの障害の保護
計画的なメンテナンス
追加のレポート機能またはオープン
されているデータベース・リソース
12-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録A
付録 - 主なアーキテクチャ変更におけるリスク評価
プライマリ・サイト:
プライマリ・サイト
RAC本番
本番
セカンダリ・サイト:
セカンダリ・サイト
シングル・インスタンス・スタンバイを使用するData
Guard
シングル・インスタンス・スタンバイを使用する
代替のアーキテクチャは、コストを削減するためにセカンダリ・サイトでシングル・インスタンスになっている（RAC
またはクラスタがない）点を除けば、MAA と非常に似ています。セカンダリ・サイトの RAC が削除されると、次のデ
メリットによってリスクが高まると予想されます。
•
セカンダリ・サイトで、リジリエンスを保持したまま計画的なメンテナンスを行うことができなくなります。最
大保護モードで実行している場合は、本番データベースの保護モードをダウングレードする必要があります。
•
セカンダリ・サイトのインスタンスおよびノードの障害から保護できなくなります。
•
セカンダリ・サイトへのスイッチオーバーまたはフェイルオーバーを行うと、ノードが 1 つになるため、パフォ
ーマンスが低下する可能性があります。セカンダリ・サイトは、プライマリ・サイトよりも処理能力が劣るため、
セカンダリ・サイトではプライマリ・サイトよりもサービスされるユーザー数が少なくなる場合もあります。プ
ライマリ・サイトがリストアされるまで、少ない容量で稼働する場合もあります。
•
構成が対称型ではないため、それぞれのサイトで別の処理と手順が必要になり、環境における操作と管理がさら
に複雑になります。
次の図に示す構成は、発生する可能性のある様々な停止のすべてに対して、近似のまたは等しい MTTR を提供しますが、
これはプライマリ・サイトで発生する停止のみが対象になります。また、本番ロールをセカンダリ・サイトへ移動した場
合は、パフォーマンスおよびリジリエンスのレベルは低下します。
図12-1: RAC本番および
本番およびData
Guardのシングル・インスタンス
のシングル・インスタンス
本番および
Maximum Availability Architecture
12-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録A
付録 - 主なアーキテクチャ変更におけるリスク評価
プライマリ・サイト:
プライマリ・サイト
シングル・インスタンスの本番
セカンダリ・サイト:
セカンダリ・サイト
シングル・インスタンス・スタンバイを使用するData
Guard
シングル・インスタンス・スタンバイを使用する
代替のアーキテクチャは、コストを削減するためにプライマリ・サイトとセカンダリ・サイトの両方でシングル・インス
タンスになっている（RAC またはクラスタがない）点を除けば、MAA と非常に似ています。この場合のデメリットは次
のとおりです。
•
いずれかのサイトで、リジリエンスを保持したまま計画的なメンテナンスを行うことができなくなります。
最大保護モードで実行している場合は、本番データベースの保護モードをダウングレードする必要があります。
•
インスタンスおよびノードの障害から高速フェイルオーバー保護を行うことができません。
•
スケールの機能は、単一のマシンの機能に制限されます。
RAC を削除すると、RAC による主要な効果も得られなくなります。RAC および RAC の高速フェイルオーバー機能なし
では、計画的、または計画外のホストおよびインスタンスの停止によって MTTR が延長され、Data Guard のスイッチオ
ーバーまたはフェイルオーバーによって処理される可能性もあります。ただし、停止したサイトには 1 つのノードしかな
いため、停止が解決するまでリジリエンスは実現されません。また、単一のマシンの機能以上に環境を拡張できません。
図12-2: シングル・インスタンスの本番およびData
Guardのシングル・インスタンス
のシングル・インスタンス
シングル・インスタンスの本番および
Maximum Availability Architecture
12-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録A
付録 - 主なアーキテクチャ変更におけるリスク評価
プライマリ・サイト:
プライマリ・サイト
RACの本番、および
の本番、およびRACスタンバイを使用する
スタンバイを使用するData
Guard
の本番、および
スタンバイを使用する
セカンダリ・サイト:
セカンダリ・サイト
なし
多くのケースでは、セカンダリ・サイトまたは障害のサイトは最後に実装されます。これは、コストによる制限のため、
または現行の SLA が是認していないためです。セカンダリ・サイト、およびその運用上のインフラストラクチャをすべ
て削除することによってコストを大幅に減少させることができます。ただし、障害をリカバリするために数時間または数
日かかるかもしれないというリスクが発生します。セカンダリ・サイトのかわりに、プライマリ・サイトで Data Guard
を使用して、人的エラーおよびデータ障害から保護し、解決を行います。フィジカル・スタンバイ・データベースは、本
番ホストと同じ LAN 上でかつ、本番データベースとは別のクラスタに定義します。この場合のデメリットは次のとおり
です。
•
サイト障害から保護されない
•
サイト全体の計画的なメンテナンスでは、システムを停止させる必要がある
図12-3: RACの本番、およびプライマリ・サイトで
の本番、およびプライマリ・サイトでRACを使用する
を使用するData
Guard
の本番、およびプライマリ・サイトで
を使用する
Maximum Availability Architecture
12-4
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録A
付録 - 主なアーキテクチャ変更におけるリスク評価
プライマリ・サイト:
プライマリ・サイト
RACの本番、およびシングル・インスタンスを使用する
の本番、およびシングル・インスタンスを使用する
Data Guard
スタンバイ・セカンダリ・サイト:
スタンバイ・セカンダリ・サイト
なし
このアーキテクチャは、前述の 2 つのアーキテクチャを組み合せたものです。このアーキテクチャでは、セカンダリ・サ
イトが削除され、Data Guard のフィジカル・スタンバイから RAC が削除されています。シングル・インスタンスのフィ
ジカル・スタンバイ・データベースは、本番データベースと同じ LAN 上で、本番データベースとは異なるホストに定義
します。この場合には、前述のアーキテクチャを組み合ることによる、次のようなリスクがあります。
•
プライマリ・サイトの障害からは保護されません。プライマリ・サイトの停止から完全にリカバリするには、（適
切な計画が提示された場合に）数時間、数日または数週間かかります。
•
サイト全体の計画的なメンテナンスでは、システムを停止させる必要があります。
•
スタンバイへのスイッチオーバーまたはフェイルオーバーを行うと、ノードが 1 つになるため、パフォーマンス
が低下する可能性があります。シングル・インスタンス・データベースでは、RAC の本番データベースよりも
処理能力が劣るため、シングル・インスタンス・データベースでサービスされるユーザー数が、RAC の本番デ
ータベースよりも少なくなる場合もあります。RAC データベースがリストアされるまで、少ない容量で業務を
行います。
•
（RAC の本番とシングル・インスタンスのスタンバイでは）構成が対称型ではないため、それぞれのデータベ
ースで別の処理と手順が必要になり、環境における操作と管理がさらに複雑になります。
図12-4: RACの本番、およびプライマリ・サイトでシングル・インスタンスを使用する
の本番、およびプライマリ・サイトでシングル・インスタンスを使用するData
Guard
の本番、およびプライマリ・サイトでシングル・インスタンスを使用する
Maximum Availability Architecture
12-5
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録A
付録 - 主なアーキテクチャ変更におけるリスク評価
プライマリ・サイト:
プライマリ・サイト
シングル・インスタンスの本番および
シングル・インスタンス・スタンバイを使用した
Guard
シングル・インスタンス・スタンバイを使用したData
使用した
セカンダリ・サイト:
セカンダリ・サイト
なし
このアーキテクチャは、前述の 2 つのアーキテクチャの別の組合せを使用したものです。ここではセカンダリ・サイトを
削除し、本番およびスタンバイの両方のデータベースから RAC を削除しています。シングル・インスタンスのフィジカ
ル・スタンバイ・データベースは、本番データベースと同じ LAN 上で、本番データベースとは別のホストに定義します。
この場合には、前述のアーキテクチャを組み合ることによる、次のようなリスクがあります。
•
プライマリ・サイトの障害からは保護されません。プライマリ・サイトの停止から完全にリカバリするには、（適
切な計画が提示された場合に）数時間、数日または数週間かかります。
•
サイト全体の計画的なメンテナンスでは、システムを停止させる必要があります。
•
本番データベースまたはスタンバイ・データベースで、リジリエンスを保持したまま計画的なメンテナンスを行
うことができなくなります。最大保護モードで実行している場合は、本番データベースの保護モードをダウング
レードする必要があります。
•
インスタンスおよびノードの障害から高速フェイルオーバー保護を行うことができません。
•
スケールの機能は、単一のマシンの機能に制限されます。
RAC を削除すると、RAC の主要なメリットも得られなくなります。RAC が削除されると、計画的または計画外のホスト
やインスタンスの停止時に、停止を解決するまでの MTTR が長くなる、またはスタンバイ・ホストやインスタンスの停
止を解決するまでリジリエンスが実現されないなどのデメリットが生じます。また、単一のマシンの機能以上に環境を拡
張できません。
図12-5: シングル・インスタンスおよびプライマリ・サイトでのData
Guard
シングル・インスタンスおよびプライマリ・サイトでの
Maximum Availability Architecture
12-6
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録A
付録 - 主なアーキテクチャ変更におけるリスク評価
プライマリ・サイト:
プライマリ・サイト
RAC本番
本番
セカンダリ・サイト:
セカンダリ・サイト
なし
このアーキテクチャでは、環境からセカンダリ・サイトと Data Guard の両方を削除しています。この構成では、高速フ
ェイルオーバーの実現、本番ノードおよびインスタンスでの計画的メンテナンスの実行などの RAC の機能は保持されま
すが、次のリスクも発生します。
•
ユーザー・エラーまたは破損からリカバリするには、データベースを部分的または完全にリストアおよびリカバ
リすることのみが使用可能な方法です。この場合には、広い範囲での停止が必要になる場合があります。
•
プライマリ・サイトの障害からは保護されません。プライマリ・サイトの停止から完全にリカバリするには、（適
切な計画が提示された場合に）数時間、数日または数週間かかります。
•
サイト全体またはデータベース全体の計画的なメンテナンスでは、システムを停止させる必要があります。
•
ロジカル・スタンバイで、オープンした状態の追加のデータベース・リソースが失われます。
図12-6: プライマリ・サイトのRAC本番のみ
本番のみ
プライマリ・サイトの
まとめ
ビジネス要件において、実現可能な最高の MTTR サービス・レベルを必要としない場合、または前述のコスト削減の方
法によっても、十分なコスト削減が実現できない場合にのみ、代替のアーキテクチャを検討してください。ただし、MAA
は、他のアーキテクチャでは実現できない可用性とパフォーマンスのメリットを提供しています。
Maximum Availability Architecture
12-7
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
13. 付録B
付録 - 運用上のベスト・プラクティス
サービス管理を念頭に置いた運用上のベスト・プラクティスは、停止からの復旧時間、つまり MTTR を短縮するだけで
なく、運用停止を回避（または最小）にして、これに対処するための基礎になります。この項では、これらのプラクティ
スについて説明します。各プラクティスの後には、推奨事項を含むチェックリストが記載されているため、これを使用し
て、対象のインフラストラクチャがこれらのプラクティスに準拠しているか確認してください。
ベスト・プラクティスは、実務面と技術面の項に分かれます。実務的ベスト・プラクティスの項では、IT インフラスト
ラクチャを管理する際の基礎について説明します。ここでは、処理
処理、ポリシー
管理について詳しく説明します。
処理 ポリシーおよび管理
ポリシー
管理
技術的ベスト・プラクティスでは、高可用性の環境に必要な技術の詳細を説明します。実務的ベスト・プラクティスと技
術的ベスト・プラクティスの両方が実現されると、堅牢で可用性の高いインフラストラクチャを構築するための基礎が成
立します。
13.1
実務的ベスト・プラクティス
実務的ベスト・プラクティスの項では、処理、ポリシー、管理の設定および構築について重点的に説明します。
実務的ベスト・プラクティスは、次のカテゴリに分類できます。
•
サービス・レベルの管理
•
変更管理
•
バックアップ、リストアおよびリカバリ・プラン
•
障害時リカバリのプラン作成
•
計画停止のプラン作成
•
従業員の教育
•
ドキュメント
•
セキュリティ・ポリシーおよび手順
技術的な運用上のベスト・プラクティスは、「技術的ベスト・プラクティス」の項を参照してください。
13.1.1
サービス・レベルの管理
企業がビジネスを運営する方法は常に変化しているため、企業の IT 部署には、ビジネスにとってより直接的な価値を提
供する必要性が強いられます。IT 部署は、コスト削減を求められる一方で、より高いレベルのサービスと可用性の提供
を求められています。サービス・レベルの管理は、IT サービスがビジネス要件に対処するための、実績ある方法として
認められています。サービス・レベルの管理では、IT マネージャと企業の事業部門との間に対話が必要です。サービス
の管理は、ビジネスの要件を IT 投資にマッピングすることから始まります。
サービス・レベルの管理は、サービス・インフラストラクチャ全体の管理が対象です。サービス・レベルの管理の基盤は、
品質保証契約（SLA）です。SLA は、プロバイダとクライアント間の責任分担を確立し、プロバイダのパフォーマンスを
評価するために重要な項目です。SLA は、顧客と IT サプライヤ（外部または内部）との関係を監視および管理するため
の道具として認められてきており、ますます重要になってきています。まず、SLA は注文処理などのミッション・クリ
ティカルなビジネス・プロセスや、アプリケーション・システムを扱います。SLA は、これらのシステムの機能、サプ
ライヤが提供するサービスの完全で詳細な説明、およびそのサービスに対するユーザーの責任を特定できる人物と共同で
作成する必要があります。SLA を作成するためには、ビジネス・マネージャ（顧客）は要件に順位を付け、優先度に従
ってリソースを考慮します。また、SLA は、ビジネスの要件とともに進化する柔軟なドキュメントである必要がありま
す。
Maximum Availability Architecture
13-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
すべての企業の要件に合うような標準化された SLA は存在しませんが、一般的な SLA には次の項目が含まれます。
•
•
基本の定義 − 提供されるサービスの定義、関係する組織、契約の発効日。
可用性の仕様 − サービスまたはアプリケーションが使用可能な日時に関する仕様（スケジュールされたテスト、
メンテナンス、アップグレードを除く）。
•
サービス範囲の仕様 − サービスまたはアプリケーションが提供されるユーザーや、ハードウェアの人数および
場所に関する仕様。
•
問題の報告およびエスカレーションの手順 − より高いレベルのサポートを要請するためのエスカレーション・
コールの条件など、問題を報告するための方法。これには、問題に対する予定応答時間が設定されます。
•
変更手順 − 変更を要請するための手順の説明。場合によっては、日常的な変更要請を終了するまでの予定時間
が含まれます。
•
•
サービス測定項目の仕様
サービス測定項目の仕様 − 品質目標の仕様と、これらの測定項目の測定方法および測定頻度が示されます。
サービス・コストと料金の定義 − サービスに関する料金の仕様。フラット・レートか、サービスの品質レベル
によって異なる料金が課されます。
•
ユーザーの責任に関する仕様 − SLA におけるユーザーの責任の仕様（ユーザーの訓練、適切なデスクトップ構
成の維持、外部ソフトウェアを導入しないこと、変更管理手順を略さないこと）。
•
サービスに関連する意見の不一致の解決方法
たとえば WAN、デスクトップ、データ・センターなど、SLA は伝統的にサービスごとに作成されます。SLA および測定
項目の編集では、関係するすべての組織が、重要な作業を責任を持って行う必要があります。測定項目は、応答時間など、
従来の技術的な測定以上のものが望まれ、注文処理ごとのコストなど、よりビジネスの要件に近いものである必要があり
ます。共有されるサービスまたはコンポーネントは、最も厳しい SLA のレベルに従う必要があります。さらに、全体的
なサービス管理の一部として、相互依存する IT グループ間や、外部サプライヤとの SLA を作成する必要もあります。実
際、技術者は、インフラストラクチャ・コンポーネントに対する個別の SLA よりも、統合された包括的な SLA を支持し
ています。SLA 作成に関する主な効果は、次のとおりです。
•
文書化された責任分担によるサプライヤと顧客間のプロフェッショナルな関係
•
ビジネス要件の理解および適合性の相互的な目標
•
IT がビジネスの条件においてその能力と結果を定量化し、継続的に改善していくために、サービスの提供を測定
するためのシステム
•
可用性に負の影響を与える不要なイベントの発生を回避し、より迅速な方法で対処できるように、事前に処理で
きる IT
•
伝達およびエスカレーションの方法を記した文書
Maximum Availability Architecture
13-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
変更管理
13.1.2
変更管理とは、ハードウェア、ソフトウェア、アプリケーションおよびデータに対するすべての変更が承認され、スケジ
ュールされ、テストされるようにするためのルールまたは手順です。予想外、未テスト、または未承認の変更がない安定
したシステムでは、ユーザーに対して整合性が保証されます。エンド・ユーザーは、期待どおりに実行されるハードウェ
ア、ソフトウェアおよびデータを信頼することができます。システムに対して、いつ、どのような変更が行われたかを正
確に把握することは、問題をデバッグする際にきわめて重要です。それぞれの顧客は、システム、データベース、アプリ
ケーション・コードの変更管理をそれぞれ別に取り扱いますが、不必要なシステム停止を防ぎ、システムの整合性を保護
7
するための一般的なガイドラインは存在します。 適切な変更管理が実行されれば、アプリケーションおよびハードウェ
ア・システムの安定性が大きく向上し、新しい問題も簡単にデバッグできます。
•
変更管理プロセスの作成
•
変更管理グループの形成
•
変更案の評価
•
基本的な比較のための統計データの収集
•
データベースの変更の追跡
•
アプリケーション・コードに対するバージョン管理システムの使用
•
品質管理およびテスト方法の作成
•
内部監査の実行
次の図 13-1 は、典型的な変更管理フローを示しています。障害など、緊急時用の変更管理プロセスは短くすることもで
きます。
7
『Expert Review Server Handbook』および顧客の運用上のレビューからの情報
Maximum Availability Architecture
13-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
図13-1: 変更管理の流れ
変更管理プロセスの作成
エスカレーションの場合とエスカレーションではない場合の変更管理プロセスを作成し、文書化し、実行する必要があり
ます。特別な場合および緊急時のシステムのハードウェア、データベースおよびソフトウェアに対する変更は避けられま
せんが、変更管理プロセスでは、これらの変更が、その後で、確実に変更の管理システムに組み込まれ、主な影響と副次
的な影響の両方が試験および記録されるようにします。
変更管理グループの形成
変更管理委員会には、アプリケーション、データベース、システムおよび管理の代表が参加する必要があります。
また、ハードウェアとソフトウェアの両方の代表も参加する必要があります。
会議の頻度と最小評価時間を決めます。変更管理のための会議の頻度および処理は、妥当な時間で主要な変更が実行され
ること、および重要課題を特定し話し合うために十分な頻度であることを考慮する必要があります。変更が発行される時
から、適切な評価時間を提供するためのレビューをスケジュールするときまでの最小据置期間が必要です。この評価時間
は、より高いレベルの管理の承認によってのみ省略できます。
変更案の評価
変更は、短期および長期の効果を提供する必要があります。変更管理チームは、変更による利点が危険性よりも価値が高
いかどうかを評価し、ビジネス、アプリケーションおよびそのルールの全体的な観点から変更を評価する必要があります。
すべての変更案には、次の内容が示されていなければなりません。
Maximum Availability Architecture
13-4
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
•
変更の目的
•
リスク評価
•
フォールバック・プラン
•
詳細のテストおよびテスト結果
•
変更を実行および取り消すための推定時間（停止時間を含む）
基本的な比較のための統計データの収集
システム、ハードウェア、データベース、アプリケーションの構成のスナップショットおよびパフォーマンスの統計を収
集します。これらの基本的な数値は、変更を実行した場合との差を検索するために利用します。たとえば、Oracle の
Statspack は、データベースのパフォーマンスについて履歴情報を収集し、保存できます。データベースのパラメータを
変更した場合は、新しい統計を収集し、基本的な統計と比較して変更の影響を評価できます。
8
データベースの変更の追跡
データベース構造の変更は、必要に応じて簡単に行うことができますが、変更管理プロセスで処理されない場合もありま
す。そのため、これらの変更のための特別な手順を作成する必要があります。また、これらの変更の追跡は、傾向分析の
際にも有効です。さらに、ファイルをデータベースに追加する場合には、そのファイルをバックアップおよびモニタリン
グ・スキームに組み込む必要があります。このような変更の適切な追跡は、リマインダとして機能することが可能です。
アプリケーション・コードに対するバージョン管理システムの使用
変更を追跡し、以前のコード・ベースに戻す場合に備えて、アプリケーション・コード用のバージョン管理システムが必
要です。社内アプリケーションは頻繁に変更および拡張され、新しいバージョンに変わります。新しいバージョンで問題
が発見された場合には、古いバーションでその事象をテストすると、有益なデバッグ情報を得ることができます。アプリ
ケーションの種類および以前のバージョンに戻さなければならないユーザーの必要性に応じて、企業は以前のバージョン
をどの程度まで保管しておくかを決めます。少なくとも、1 つは必須です。
品質管理およびテスト方法の作成
品質管理は、テストの仕様、テスト・プランおよびテスト結果を評価して、テスト・シミュレーションがアプリケーショ
ンを再現していること、または少なくともアプリケーションの重要なポイントがすべてテストされていることを確認しま
す。
内部監査の実行
内部監査は、ハードウェア、ソフトウェア、データベースおよびアプリケーションが、ベンダーによって保証されている
か、サービス・レベル内で実行されているか、高可用性を得ているかを評価するために行われます。
8
Enterprise Managerの変更管理パックには、Oracleデータベース変更管理および変更実装機能もあります。
Maximum Availability Architecture
13-5
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
13.1.3
バックアップ、リストアおよびリカバリ・プラン
適切なバックアップ、リストアおよびリカバリ・プランは重要な項目であり、これらのプランはそれぞれのサービス・レ
ベルに合わせて作成する必要があります。MAA では、ディスクとテープのデータベース・バックアップが利用できます。
ただし、ほとんどの環境では、セカンダリ・サイトにおけるスタンバイ・データベースが、論理的および物理的障害から
のリカバリを行うために利用されます。かわりに、ディスクまたはテープによるバックアップを使用した場合には、デー
タベースをリストアおよびリカバリするための時間は、目標の MTTR を超える傾向があり、特に大きなデータベースの
場合はこの傾向が顕著です。
それにもかかわらず、ディスクおよびテープによるバックアップは、障害時リカバリや、非常に古いバックアップからリ
ストアを行う場合の重要な手段です。採用するリカバリ計画は、データベースのサイズ、トランザクション・レート、ネ
ットワークの帯域幅およびプライマリ・サイトとセカンダリ・サイト間の待機時間など、多くの要因に依存します。詳細
は、「バックアップおよびリカバリ構成のベスト・プラクティス」の項を参照してください。
堅牢なバックアップ、リストアおよびリカバリでは、ファイルの物理的な場所、バックアップ・プロセス時のイベントの
順序、およびエラー処理によって、それらの処理がどこまで強化または脆弱化されるかを理解することが基本的に必要で
す。堅牢な方式は、メディア障害や、プログラムによる障害、場合によってはオペレータ障害に対してもリジリエンスを
持ちます。どのような障害においてもリカバリを正常に完了させるためには、テストされた完全な処理があることが基礎
となります。
•
リカバリ・プランの作成
•
定期的なバックアップの評価
•
バックアップ、リストアおよびリカバリ手順の自動化
•
適切なバックアップ頻度の選択
•
テープ・バックアップのオフサイトでの維持
•
交換部品のストック
•
バックアプおよびリカバリ・プランに関して更新されたドキュメントの維持
リカバリ・プランの作成
様々なタイプの停止に対してリカバリ・プランを作成します。最も一般的な停止のタイプから始めて、あまり発生しない
タイプの停止について作成します。推奨されるリカバリ方法が示された停止のマトリックスおよび評価された MTTR の
予測によって、様々な停止のタイプに対して SLA が適合しているかを評価できます。詳細は、「停止と解決」の項を参
照してください。
定期的なバックアップの評価
バックアップ処理を実行しただけでは、バックアップが成功するとはかぎりません。エラーに対するバックアップ手順を
監視し、リカバリ手順を定期的にテストすることによってバックアップの妥当性をチェックします。
バックアップ、リストアおよびリカバリ手順の自動化
バックアップ、リストアおよびリカバリ手順の自動化
より迅速で信頼性のあるリカバリのためには、処理方法をスクリプト化し、適切にテストする必要があります。
スクリプトには、適切なエラー・チェック機能と障害が発生した場合にアラートを送信する機能が必要です。これによっ
て、障害時の対応を行う担当者の負担を軽減できます。
Maximum Availability Architecture
13-6
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
適切なバックアップ頻度の選択
バックアップの頻度が、期待されるサービス・レベルに適したものであるかどうかを確認します。ほとんどの停止は、オ
ンライン・バックアップからリストアするかわりに、セカンダリ・サイトのスタンバイ・データベースまたは別の RAC
インスタンスを用いて解決されます。ただし、テープによるバックアップは必要です。
テープ・バックアップのオフサイトでの維持
データベースのオフサイト・バックアップは、サイト障害に対する重要な手段です。
交換部品のストック
MTTR の設定によっては、顧客は、ハードウェア・ベンダーが部品を持って来るのを待っている時間がない場合がありま
す。ディスク・ドライブなどの特定の交換部品をオンサイトで保管するか、ハードウェア・ベンダーとこれらの部品の配
達を迅速に行うサポート契約を結ぶ必要があります。
バックアプおよびリカバリ・プランに関して更新されたドキュメントの維持
ドキュメントが、誤り、専門知識を持つ人材の流出、および誤解に対する防御措置であることは明白です。バックアップ、
リストアおよびリカバリ手順に関する最新のドキュメントを維持することは、手順を正しく実行することと同様に重要で
す。
13.1.4
障害時リカバリ計画（DRP）
）
障害時リカバリ計画（
障害時リカバリ計画は、通常のバックアップおよびリカバリの概念よりもさらに大きな視点から作成されます。
この計画は、サービスの大規模で破壊的な中断に対処し、迅速に再開するために設計および作成される処理です。これら
の中断は、火災、洪水、地震または悪意のある行為によって起こる可能性があります。基本的な仮定として、データ・セ
ンターおよびコンピュータが存在する建物にアクセスすることができず、どこか別の場所から運用を再開することを想定
しています。最悪の事態を想定し、これに対処します。電子システムとデータへの組織の依存度が増すにつれ、これらの
システムとデータへのアクセスがビジネスの成功の鍵となってきています。これは、障害時リカバリ計画の重要性を示し
ています。適切な障害時の計画は、大災害時の MTTR を短縮し、重要なアプリケーションを継続的に提供して顧客や収
益を維持するために有効です。
•
適切な障害時リカバリ計画の選択
•
障害時リカバリ計画の内容の決定
•
影響を受ける領域およびシステムの図を含む障害時リカバリ計画（DRP）の文書化
•
すべてのアプリケーション・メカニズムの設定
•
全体像からの重要項目の評価
•
DR コーディネータの割り当て
•
DRP のテストおよび評価
Maximum Availability Architecture
13-7
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
適切な障害時リカバリ計画の選択
DRP は、期待される MTTR のサービス・レベルを満たすものである必要があります。また、実装コストもサービス・レ
ベルによって検討される必要があります。1 つの DRP では、すべての障害に対応できないだけでなく、一般的な障害に
も対応できない可能性があります。たとえば、30 マイル離れた場所に DR サイトを構築しても、ブリザードには対処で
きないが、地震には対処できる可能性はあります。
障害時リカバリ計画の内容の決定
障害時リカバリ方式に、どのアプリケーションを含めるかを判断するには、そのアプリケーションがどの程度重要な業務
作業をサポートしているか（つまり数時間または数日以内にオンラインに復旧しなければならないか）を検討することが
最初の課題です。これは、アプリケーションの可用性の要件と密接に関係しますが、同じである必要はありません。ただ
し、システムが使用できない時間または日数に対する企業のコストについては、さらに考慮する必要があります。障害時
リカバリ計画には、オフサイトの機器、人員およびサポート対象の様々な要素（仮の状態で許容レベルで動作する電話線
や、ネットワークなど）が含まれます。これは、コストのかかるものであり、企業の存続に必要なアプリケーションのみ
を考慮する必要があります。
影響を受ける領域およびシステムの図を含む
の文書化
影響を受ける領域およびシステムの図を含むDRPの文書化
の図を含む
DRP は、回避努力が必要な停止と、停止した場合に実行する手順を明確に示す必要があります。システムの一般的な図
は、影響を受ける領域を明確にするために重要です。ハードウェアのフォルト・トレランス（コントローラ、ミラー化デ
ィスク、障害時バックアップ・サイト、通信ライン、電源などを含む）を判断できるよう、詳細な情報を提供する必要が
あります。また、現在のリソースと必要な追加リソースも明らかにします。システムのデータ・フローの入出力がいつ、
どのようになされているかを理解することは、システムで特別な注意を必要とする部分を明らかにするうえで重要です。
監視条件を追加したり、実行するバックアップの頻度および種類を検討したりすることによって特別な注意を払います。
逆に言えば、最低限の注意のみを必要とし、監視と管理のためのシステム・リソースもほとんど必要ない領域が示されま
す。
すべてのアプリケーション・メカニズムの設定
重要なアプリケーション、データベース・インスタンス、システムまたはビジネス・プロセスが、障害時リカバリ計画に
含まれていることを確認します。アプリケーション、システムおよびネットワークの図を使用して、フォルト・トレラン
スおよび障害時の代替ルーターを検討します。
全体像からの重要項目の評価
業務を実行していくうえで必要なすべてのコンポーネントを検討します。DRP に、すべてのシステム、ハードウェア、
アプリケーションおよび人員が含まれていることを確認します。また、ネットワーク、電話サービスおよびセキュリティ
保護装置が設定されているかを確認します。
DRコーディネータの割当て
コーディネータの割当て
すべての操作および伝達事項が回覧されるように、コーディネータおよびバックアップは事前に割り当てておきます。
DRPのテスト
のテストおよび評価
のテストおよび評価
DRP は、定期的に練習をする必要があります。つまり、DRP をテストする設備を準備する必要があります。
Maximum Availability Architecture
13-8
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
計画停止のプラン作成
13.1.5
計画停止は、アプリケーション・サーバー層、データベース層またはサイト全体に影響を与える場合があります。
これらの停止には、ノードのハードウェアのメンテナンス、ノードのソフトウェアのメンテナンス、Oracle ソフトウェア
のメンテナンス、冗長なコンポーネントのメンテナンスおよびサイト全体のメンテナンスなどがあります。適切な計画停
止を計画することは、計画された変更を行う際の MTTR を削減したり、変更が計画どおり実行されなかった場合のリス
クを削減します。
•
計画停止のリストの作成
•
実行する可能性のある計画停止について、影響の文書化とリスクの評価
•
停止の妥当性
•
変更、テストおよびフォールバック手順の作成および自動化
計画停止のリストの作成
実行する可能性のある計画停止や、予定する停止の頻度および推定される間隔のリストを作成することによって、可用性
の要件をより適切に評価し、計画できます。計画外停止を防ぐため、重要なコンポーネントの平均障害間隔時間（MTBF）
を知るための信頼性評価を使用して、特定の停止をスケジューリングできます。通常、大規模な計画停止は年に 1 回予定
されるため、メンテナンスを優先し、適切に行う必要があります。
実行する可能性のある計画停止について、影響の文書化とリスクの評価
ソフトウェアまたはアプリケーションの変更を必要としない計画停止の場合、次のシステムが新しいトランザクションを
引き継ぐことができれば、一般的に、これらの停止は最小の停止時間内に解消できます。Real Application Clusters および
Data Guard スイッチオーバーを使用することにより、ハードウェアのアップグレードや、標準的なシステムのメンテナン
スを最小の停止時間で実行できます。Oracle のアップグレードなどのほとんどのソフトウェアのアップグレードでは、準
備が適切に行われているかぎり、実際の停止時間は 1 時間以内です。方式の変更またはデータベース・オブジェクトの再
編成を必要とするさらに複雑なアプリケーションの変更の場合は、顧客は Oracle のオンライン再編成および再構築機能
が十分であるかを評価する必要があります。詳細は、「Outages and Solution Roadmap」を参照してください。
停止の妥当性
各変更は、アプリケーションとビジネスの全体的な視点から行う必要があり、なんらかの互換性または変更管理ルールに
従う必要があります。
変更、テストおよびフォールバック手順の作成および自動化
Oracle のアップグレードなど、計画されたそれぞれの変更は、シミュレーションされた実際の環境でテストし、パフォー
マンスと可用性の影響を検討する必要があります。全負荷のハーネス、またはパフォーマンスおよびロードの影響を正確
に評価するためにシミュレーションされたロードを使用することをお薦めします。フォールバック・プランを作成して、
計画停止に組み込みます。変更を実装し、必要に応じてフォールバックも実装するための自動化処理を設定する必要があ
ります。
Maximum Availability Architecture
13-9
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
13.1.6
従業員の教育
十分なトレーニングを受けた人材は、知識に基づいた適切な判断を下すことができ、ミスも少なくなります。システム管
理者、データベース管理者、開発およびユーザー・グループに対する継続的な技術教育についての総合的な計画は、シス
テムおよびデータベースの高可用性を保証するために有効です。さらに、システム・コンポーネントの冗長性によって単
一箇所での障害を排除できるのと同様に、ナレッジ・マネジメントとクロス・トレーニングによって、従業員の退職によ
る業務への影響を排除できます。
•
ビジネスに重要な人員ポストのクロス・トレーニング
•
継続的な技術教育を確実にするためのガイドラインの作成
•
ナレッジ・マネジメント・プロセスの実装
•
アプリケーションまたはシステムの改訂に応じた研修資料の維持
ビジネスで重要な位置に対するクロス・トレーニング
ビジネスにとって重要などのようなシステムでも、従業員が作業できない場合や、退職した場合に備えて、業務への影響
を減らすために技術者のクロス・トレーニングが必要です。たとえば、システム管理者のグループは、Oracle RDBMS と
Tools に熟知している必要があります。異なるサポート・グループ間で、意思疎通のための正式な定型フォームを維持す
る必要があります。
継続的な技術教育を確実にするためのガイドラインの作成
企業で使用しているハードウェアおよびソフトウェアの新しい機能または手順についてスタッフに知らせたり、訓練する
処理があることを確認してください。さらに、サービス・レベルを向上させたり、コストを削減する可能性のある新しい
技術に対する調査も考慮してください。
ナレッジ・マネジメント・プロセスの実装
企業の知的資産を効果的に管理することによって、これらの資産の損失リスクを軽減できます。IT グループ内に、得ら
れた教訓への集中方式のアクセスを推進するための処理を作成します（グループ円卓会議、内部白書、アップグレードに
関する新機能、問題の分析/解決に対するリポジトリなど）。
アプリケーションまたはシステムの改訂に応じた研修資料の維持
アプリケーションおよびシステムの変更に応じて、最新の研修資料を維持する必要があります。これは、変更管理および
文書化の手順に組み込まれる必要があります。
Maximum Availability Architecture
13-10
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
13.1.7
ドキュメント
ドキュメントのベスト・プラクティスは、運用上の全ベスト・プラクティスの一部である必要があります。処理を実装ま
たは実行するための手順を文書化しないと、知識が失われる、その処理の実行時に発生する人的エラーが増加する、処理
の手順を抜かしてしまう、といった危険性もあります。これらはすべて可用性に影響を与えます。
明確に定義された運用手順によって、組織に新しい従業員が加わったときの学習曲線を短くできます。
また、適切に文書化された運用手順によって、サポート担当者への質問数を大幅に軽減できます。特に、これらの手順を
決めた担当者がグループに残っていない場合は、この効果がより大きくなります。適切なドキュメントは、組織内での役
割と責任が明確に定義されるため、運用上の混乱を防ぐこともできます。
明確に文書化されたアプリケーションは、組織に新しく参加した従業員の学習曲線を短くするための基礎です。
メンテナンスおよび拡張が自作のアプリケーションに対して必要な場合に、ドキュメントにより、開発者はプログラムに
ついての知識を再確認できます。元の開発者がグループにいない場合、このようなドキュメントによりコード自体を解読
する作業が不要になるため、新しい開発者にとっては特に重要です。すぐに使用できるドキュメントも、サポート組織へ
の質問数を大幅に削減する効果的な手段です。
•
最新のドキュメントの維持
•
変更管理プロセスに基づくドキュメントの変更承認
•
学習内容および問題解決策の文書化
•
ドキュメントの保護
最新のドキュメントの維持
アプリケーションまたはシステムの変更に応じて運用手順を維持してください。また、ドキュメントの更新がユーザーに
通知されるようにしてください。
変更管理プロセスに基づくドキュメントの変更承認
変更管理チームは、正確さが保たれるようにドキュメントに対するすべての変更を確認し、承認します。
学習内容および問題解決策の文書化
これは、ナレッジ・マネジメントのさらに大きな処理に提供される必要があります（「従業員の教育」の項参照）。問題
の解決方法と得られた教訓を文書化することによって、問題が繰り返された場合のリカバリ時間の短縮につながります。
理想的には、この文書化が、将来的なシステム拡張の順位付けのため、定期的なレビュー・プロセスの一部として実行さ
れることが望ましいといえます。
ドキュメントの保護
ドキュメントへのアクセスを保護し、運用手順を記したドキュメントおよびその他の重要なドキュメントのオフサイト・
コピーを保管します。すべての重要なドキュメントも、リモート・サイトの実装の一部とする必要があります。障害時の
再起動のためのリモート・サイト、および障害時リカバリのためのリモート・サイトに対するフェイルオーバー用の文書
化された手順のコピーも維持する必要があります。
Maximum Availability Architecture
13-11
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
セキュリティ・ポリシーおよび方法
13.1.8
実務的な観点から行われるセキュリティは、ハードウェアおよびデータ・センターの物理的なセキュリティと運用を対象
にします。物理的なセキュリティとは、火事、熱、電気サージ、偶然の蹴りなど、物理的な損傷に加え、不当なアクセス
からの保護も意味します。データ・セキュリティについては、「技術的ベスト・プラクティス」の項を参照してください。
物理的なセキュリティは、最も基本的なセキュリティ上の予防措置で、顧客の可用性の要件に合わせてシステムの能力を
決定するための主要要素です。物理的なセキュリティは、外部および内部のセキュリティ侵害を防ぎます。CSI/FBI
Computer Crime & Security Survey は、外部からの侵入の増加傾向を記していますが
9
、内部的なセキュリティ違反も大き
な脅威として存在します。データ・センターおよび組織のセキュリティに関する詳細な発見プロセスは、この手段の範囲
外になります。ただし、適切に保護されたインフラストラクチャは、損害の危険性や、停止時間および財務上の損失を軽
減します。
•
コンピュータ機器のための適切な物理的環境の設定
•
運用に関係する領域への許可された人員のみのアクセス制限
•
内部セキュリティ監視の使用
•
DBA、システム管理書および運用スタッフのバックグラウンドの確認
コンピュータ機器のための適切な物理的環境の設定
オフィス環境にあるすべての部屋またはクロゼットが、コンピュータ機器の収容に適しているわけではありません。デー
タ・センターは、適切な温度、湿度およびシステムのセキュリティを考慮するだけではなく、電気サージ、火災、洪水な
ど、潜在的な危険の防止も考慮する必要があります。
運用に関係する領域への許可された人員のみのアクセス制限
セキュリティを重視する必要があるすべてのオペレーション・センターには、バイオメトリック認証機器や、スマートカ
ード・リーダーなどのアクセス保護が必要です。
内部セキュリティ監視の使用
施設内部の人員による犯罪および損傷を防ぐために、カメラやクローズドサーキット・テレビなどの機器を、セキュリテ
ィ目的でオペレーション・センターに設置します。
DBA、システム管理者および運用スタッフのバックグラウンドの確認
、システム管理者および運用スタッフのバックグラウンドの確認
DBA、システム管理者および操作スタッフは、本質的に権限を持つユーザーであり、責任ある地位にいます。組織は、
これらの責任ある人材がその地位に適した人物であるかを調べるためには、適切なバックグラウンドの確認を行う必要が
あります。適切な身元調査が行われなかった人物が権限を持ち、悪意のある行為を行った場合には、これを防御するため
の技術的な解決策はありません。
9
CSI/FBI Computer Crime & Security Survey、http://www.gocsi.com/prelea/000321.html
Maximum Availability Architecture
13-12
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
13.2
技術的なベスト・プラクティス
技術的ベスト・プラクティスの項では、防止および検出に関する提案など、MAA の構成および停止に対する解決策の範
囲外にある技術的な推奨事項に関して説明します。技術的ベスト・プラクティスは、次のカテゴリに分類されます。
•
データベース・オブジェクトの設計に関するベスト・プラクティス
•
オブジェクトの可用性に関連する防止、検出および修復
•
計画外停止の防止および検出
•
セキュリティ・ポリシーおよび方法
13.2.1
データベース・オブジェクトの設計に関するベスト・プラクティス
多くの設計方針および運用プラクティスによって、オブジェクトの可用性問題が表面化したときに、それが問題化するこ
とが少なくなります。また、MAA は、問題を早期に予防的に検出することも推奨します。オブジェクト・レベルの破損
は、予防的に検出され、実行時に発見されます。オブジェクト・レベルの破損を事前に検出することは特に重要で、これ
によって、DBA は、システムの起動および実行時に最も適切な方法を用いて問題を解決することが可能になります。次
の事項は、ブロックの破損を事前に検出するために使用できます。これらは、定期的に実行するようにしてください。こ
れらのツールによって報告されたエラーは、必ず調査してください。メディア・リカバリまたは適切なレベルでのオブジ
ェクトの再作成によって問題を解決できます。
•
使用していない索引の削除
•
索引の定期的な結合または再構築
•
オブジェクト定義の詳細の維持
•
小さい単位のデータに合わせた設計
•
SYS ユーザー以外のデフォルトの表領域の設定
•
アプリケーションに独立性を持たせた管理しやすい表領域の使用
•
パーティション化された表および索引の使用
•
異なる表領域へのパーティションの保存
使用していない索引の削除
使用していない索引を削除することによって、パフォーマンスが向上し、ディスクの破損が軽減されるため停止時間が短
縮されます。使用していない索引は削除してください。索引の使用状況の監視は、次の問合せを実行します（DML の索
引へのロックが必要です）。
SQL> ALTER INDEX <INDEX NAME> MONITORING USAGE;
SQL> SELECT * FROM V$OBJECT_USAGE WHERE INDEX_NAME=<INDEX_NAME>;
SQL> ALTER INDEX <INDEX NAME> NOMONITORING USAGE;
索引の定期的な結合または再構築
索引レンジ・スキャンで使用されるブロックを減らすため、希薄なリーフ・キーの索引を結合または再構築します。オン
ライン再構築の方が結合よりも速く処理できるのですが、新しい索引を構築するまで古い索引が残るため、より多くの領
域を必要とします。これによって、同じ量のデータに対して、索引で使用されるブロック数を軽減でき、パフォーマンス
を向上させ、メディア障害になる可能性を軽減できます。
Maximum Availability Architecture
13-13
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
オブジェクト定義の詳細の維持
オブジェクトをリカバリするための適切な方法を決めてオブジェクト損失時の MTTR を最小にするためには、オブジェ
クトに関連するすべての情報を簡単に入手し、迅速に影響を分析できる必要があります。関連情報とは、次の情報を意味
します。
•
オブジェクトの構造
•
索引および制約
•
そのオブジェクトに依存するオブジェクト
•
オブジェクトの依存関係
このようなすべての関連情報のリポジトリおよびオブジェクトを再作成するためのスクリプトは、リカバリ時間を短縮す
るために有効です。パッケージ、手順、関数、ビュー、シノニムなど、辞書オブジェクトについては、オブジェクト定義
スクリプトへの迅速なアクセスが、失われたオブジェクトを検出して短時間で修復することにつながります。インストー
ルの際しては、オブジェクト定義スクリプトを使用できるようにするための様々の方法を選択できます。Enterprise
Manager（EM）に付属する Oracle Change Management Pack は、このようなツールの 1 つです。
小さい単位のデータに合わせた設計
データベースは、小さな単位のオブジェクトをリカバリできるように、小さな単位のデータを念頭に置いて設計する必要
があります。問題が発生した場合は、単位が小さいほど、より柔軟に対処できます。たとえば、大きな表の場合は次のよ
うに対処します。
•
可能な場合はパーティションを使用
•
可能な場合は、パーティションにローカル索引を使用
•
可能な場合は、パーティションごとに異なる表領域を使用
エンティティを一緒に使用される列または類似した頻度によってグループ化された表に分割します。1 つの表のオブジェ
クトのリカバリにより、他の表の可用性が影響を受けることはありません。
SYSユーザー以外のデフォルトの表領域の設定
ユーザー以外のデフォルトの表領域の設定
SYS オブジェクト以外のオブジェクトを、SYSTEM 表領域に置かないでください。SYS オブジェクト以外のオブジェク
トを SYSTEM 表領域に置くと、データベースが完全に停止する可能性があります。これは、オブジェクトを別の表領域
に設定することで、回避できます。
アプリケーションに独立性を持たせた管理しやすい表領域の使用
表領域を扱いやすい大きさに維持します。オブジェクトが大きくなりすぎた場合は、パーティションを考慮してください。
複数のアプリケーションで 1 つのインスタンスを共有している場合は、共有していないすべてのデータを独立した異なる
表領域に分離します。これによって、それぞれの表領域がオフラインになった場合でも、影響を 1 つのアプリケーション
のみに抑えることができ、全体的な可用性を適切に維持できます。
パーティション化された表および索引の使用
それぞれのパーティションは個別に管理でき、他のパーティションに依存しないで機能します。それにより、可用性およ
びパフォーマンスを適切に維持できます。
Maximum Availability Architecture
13-14
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
異なる表領域へのパーティションの保存
パーティションを異なる表領域に保存することによって、次のメリットがあります。
•
パーティションごとの非依存のバックアップとリカバリ
•
複数パーティションでのデータ破損の可能性の減少
•
扱いやすさ、可用性、パフォーマンスの向上
13.2.2
オブジェクトの可用性に関連する防止、検出および修復
データベース・オブジェクトが完全に使用できなかったり、部分的に使用できない場合があります。完全に使用できない
場合には、オブジェクトが切り捨てられていたり、削除されている場合があります。部分的に使用できる場合には、オブ
ジェクトに部分的にはアクセスできても、すべてにアクセスできない場合があります。部分的に使用できる場合というの
は、一般的には、オブジェクトに直接的に影響する破損や、アプリケーションの観点からそのオブジェクトが使用できな
くなるような依存オブジェクトに影響する破損によって引き起こされます。
この項では、次の項目について説明します。
•
完全に使用できないオブジェクトの検出、リペアおよび防止
•
部分的に使用できないオブジェクトまたは破損したオブジェクトの検出、修復および防止
•
Oracle 検出ツール
完全に使用できないオブジェクトの検出、修復および防止
次の表は、オブジェクトが完全に使用できない場合の検出、修復および防止方法について示しています。防止メカニズム
は、基本的にはデータベース構成レベルに依存し、オブジェクトの削除および切り捨て防止に主眼を置いています。検出
メカニズムは、Oracle Enterprise Manager など、監視ツールを使用します。基本的には、アプリケーション・ログの他に
も、Oracle アラート・ログおよび監査ログを監視します。検出には、常に、迅速で信頼性のある通知処理が必要です。適
切な検出および修復メカニズムが設定されていない場合は、本番データベースの問題はスタンバイ・データベースに伝播
します。監視設備は、エラーの発生を、スタンバイ・データベースの時間の遅れ、および（存在する場合は）本番データ
ベースのアンドゥ保存時間よりも短い時間で検出および通知する必要があります。
Maximum Availability Architecture
13-15
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
表13-1: 完全に使用できないオブジェクトの検出、修復および防止
オブジェクトの種類
データ・セグメントの
削除または切り捨て
（表/パーティション/ク
ラスタ）
索引
防止
検出
修復
オブジェクトにアクセスするアプリ 「オブジェクト・リカバ
ケーションが ORA-00942: 表または リの決定プロセス」
参照。
ビューが存在しませんを受信。
10
アプリケーションがすべてのエラー
パラメータ DML_LOCKS
=0 をすべてのインスタンスに を一元的に記録している場合には、そ
の記録を監視する。
設定。
AUDIT NOT EXISTS および/または
アクセスを権限によって制
AUDIT
DROP TABLE を有効にするこ
御。許可するアクセス権限はア
プリケーションに必要な最小 とによって、監視可能な（手動または
自動）監査証跡が残る。
限にとどめる。
ALTER TABLE <tablename>
DISABLE TABLE LOCK;
− 通常の方法
ALTER TABLE <tablename>
DISABLE TABLE LOCK;
DML_LOCKS=0 に設定
パフォーマンスの低下。
「オブジェクト・リカバ
リの決定プロセス」
AUDIT NOT EXISTS および/または
参照。
AUDIT DROP INDEX を有効にするこ
とによって、監視可能な監査証跡が残
る。
シノニム
ビュー
制約
トリガーの削除/
トリガーの無効化
アクセスを権限によって
制御。PUBLIC シノニムを削除
するためには、DROP PUBLIC
SYNONYM システム権限が必
要。
オブジェクトにアクセスするアプリ
ケーションが ORA- 00942: 表または
ビューは存在しませんを受信。
シノニムをローカルで
11
再作成する。
権限を用いてオブジェクトへ
のアクセスおよび依存関係を
制御する。
オブジェクトにアクセスするアプリ
ケーションは ORA-00942 を取得: 表
またはビューは存在しない。
ビューをローカルで再
作成する。自動的にビ
ューを無効にする。
DBA_OBJECTS の INVALID ビューを
確認する。AUDIT NOT EXISTS また
は AUDIT DROP INDEX（あるいはそ
の両方）を有効にすることによって、
監視可能な監査証跡に対してこれを
監査する。
次の使用時に Oracle に
よって再コンパイル。
ALTER TABLE <tablename>
DISABLE TABLE LOCK;
データ整合性損失の可能性の
増加。
制約をローカルで再作
成する。
DML_LOCKS=0 に設定
ALTER TABLE 文に対する監査。監査
証跡の監視。
アクセスを権限によって
制御。
アプリケーションの機能低下と、不適 トリガーをローカルで
切な可能性。
再作成する。
AUDIT NOT EXISTS を有効にするこ
とによって監視可能な監査証跡が残
る。
依存オブジェクトのエ
ラーを解決し、ALTER
VIEW COMPILE 文を用
いて、手動で無効なビ
ューを再コンパイルす
る。
ALTER TRIGGER/DROP TRIGGER に
対する監査と監査証跡の監視。
10
インスタンス・レベルまたはオブジェクトに対してDMLロックが無効な場合は、LOCK TABLE IN EXCLUSIVE MODEまたはオブジ
ェクトのDDLなど、明示的なロック文は許可されません。
11
前述のすべての辞書オブジェクトの場合、オブジェクトの状態および定義を記録するための変更管理ツールの使用は、オブジェク
トの損失時に非常に有効です。オブジェクトの再作成を、最小の時間で行うことができます。
Maximum Availability Architecture
13-16
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
オブジェクトの種類
防止
検出
修復
PL/SQL プロシージャ/
関数/パッケージ
権限を用いてオブジェクトへ
のアクセスおよび依存関係を
制御する。
アプリケーションが ORA エラーを受 プロシージャ、関数、
信（通常 ORA-6550）。
パッケージをローカル
で再作成する。
INVALID プロシージャと
DBA_OBJECTS のパッケージを確認
する。
無効なプロシージャ、
関数、パッケージ・オ
プロシージャ/パッケージ/関数の作成 ブジェクトを、次の使
と削除を監査し、監査証跡の監視す 用時の Oracle によって
自動的に再コンパイル
る。
する。
依存オブジェクトのエ
ラーを解決し、ALTER
PROCEDURE
COMPILE 文を用い
て、手動で無効なプロ
シージャを再コンパイ
ルする。
依存オブジェクトのエ
ラーを解決し、ALTER
PACKAGE COMPILE
文を用いて、手動で無
効なパッケージを再コ
ンパイルする。
シーケンス
アクセスを権限によって
制御。
オブジェクトにアクセスするアプリ シーケンスをローカル
ケーションが ORA-2289 を受信し、障 で再作成する。
害が発生。
使用するシーケンスの
削除または存在しない（あるいはその マップおよび表/列を維
両方）シーケンスの監査および監査証 持する。これは、次の
跡の監視。
順序番号を決める際に
有効。
SELECT MAX
(table.column)
FROM TABLE; シーケ
ンスの新しい値を決め
るため。
分析統計
アクセスを権限によって
制御。
アプリケーションは、パフォーマンス ローカルで統計を再分
に関して異常な動作を示す。
析する。
データベース・リンク
アクセスを権限によって
制御。
リンクにアクセスするアプリケーシ データベース・リンク
ョンが ORA エラー（ORA-2019）を受 を
信。
ローカルで再作成す
削除されたか、存在しない dblink また る。
はパブリック dblink の監査と監査証
跡の監視。
適切なオブジェクト・セキュリティおよび制限された権限によって、オブジェクトに損傷を与える可能性のあるこれらの
ユーザー・エラーまたは悪意ある行動はほとんど防止できますが、オブジェクトの DDL 操作に関しては別の方法が必要
です。DDL 操作は、ALTER TABLE | INDEX … DISABLE TABLE LOCK 文によって、それぞれの表に対して無効にでき
ます。また、DDL 操作は、データベース・パラメータ DML_LOCKS=0 をデータベースに設定することによって、データ
ベース全体に対して無効にすることもできます。ただし、データベースの構造的な変更または追加がないと思われるとき
にのみ、データベース全体に対して DDL 操作を無効にしてください。
細かい制御が可能になるため、表レベルで DDL 操作を制限することを推奨します。
Maximum Availability Architecture
13-17
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
表レベルで、表に対する DML ロックが無効になっているかを確認するためには、次の SQL 文を使用します。
SQL> SELECT TABLE_LOCKED FROM DBA_TABLES WHERE TABLE_NAME = ‘table_name’;
TABLE_LOCKED
------ --- --DISABLED
部分的に使用できないオブジェクトまたは破損したオブジェクトの検出、
修復および防止
多くの場合、オブジェクトは部分的に使用できます。一般的な原因は、オブジェクトの破損です。破損には、メディアの
破損、オペレーティング・システムのバグまたはソフトウェアのバグがあります。破損によって、制約、索引および表間
の依存性に関する問題が生じる場合があります。次の表は、様々な停止状況についての検出、修復および防止メカニズム
を示します。
表13-2: 部分的に使用できないオブジェクトまたは破損したオブジェクトの検出、修復および防止
部分的に使用できないオブジェクトまたは破損したオブジェクトの検出、修復および防止
オブジェクトの種類
防止
検出
データまたは索引セグ
メントのメディアの破
損
DB_BLOCK_CHECKING =
TRUE に設定。
OS ファイルに OS レベル I/O エラー。「オブジェクト・リカバ
アラート・ログに ORA-600 エラー。 リの決定プロセス」
参照。
アラート・ログに一時エラー。
データまたは索引セグ
メントのメディア以外
の破損
使用可能な場合は、特定の破損 アラート・ログに ORA-1578、
防止用に HARD を使用。
ORA-1110/ORA-600 [3339]。
DB_BLOCK_CHECKSUM =
TRUE に設定。
DB_BLOCK_CHECKING =
TRUE に設定。
修復
「オブジェクト・リカバ
リの決定プロセス」
メモリーの破損、OS の破損について 参照。
OS ログを確認。
DB_BLOCK_CHECKSUM =
TRUE に設定。
DBVERIFY、DBMS_REPAIR、RMAN
または VALIDATE STRUCTURE オプ
ションのある
ANALYZE 文など、
OS、Oracle ソフトウェア、デ
バイス・ドライバおよびファー Oracle Tools。詳細は次を参照。
ムウェアに対して適切なパッ
チ・レベルでデータ・サーバー
を維持。
索引セグメントの論理
的な破損
使用可能な場合は、特定の
アプリケーションが
破損防止用に HARD を使用。 ORA エラーを受信。
DB_BLOCK_CHECKING =
TRUE に設定。
「オブジェクト・リカバ
リの決定プロセス」
参照。
事前に、VALIDATE STRUCTURE オ
プションのある ANALYZE 文による。
DB_BLOCK_CHECKSUM =
TRUE に設定。
OS、Oracle ソフトウェア、
デバイス・ドライバおよび
ファームウェアに対して適切
なパッチ・レベルでデータ・サ
ーバーを維持。
Maximum Availability Architecture
13-18
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
Oracle検出ツール
検出ツール
Oracle は、事前にオブジェクトの整合性を検証したり、非一貫性および破損を検出するためのツールを準備しています。
これらのツールは、定期的に実行されるようにスケジューリングされているか（推奨事項）、状況に応じて必要な場合に
実行できます。
DBVERIFY
DBVERIFY は、オフラインおよびオンラインのデータベースで、物理的なデータ構造整合性チェックの検証に使用でき
ます。DEVERIFY は、データベース・ファイルを読込み専用モードで開き、データ・ファイル・レベルまたはセグメン
ト・レベルでブロックの検証を行います。セグメント・レベルの検証では、検証するオブジェクトがロックされるため、
MAA では使用しないでください。ファイル・レベルの検証は、データベースを開いて行います。DBVERIFY は、ファイ
ルのすべてのブロックを検証し、データベースのセグメントによって現在使用されていないデータ・ファイルの部分にあ
る問題を検出できます。DBVERIFY の使用例については、付録を参照してください。DBVERIFY が報告したエラーは、
さらに診断に使用され、メディア・リカバリを用いて修正されます。
Recovery Manager（RMAN）検証
RMAN ブロック検証は、データベース・ブロックの構造的な整合性を検証するために使用できます。検証は、現在使用
されているブロックに対して実行されます。検証によってエラーが検出された場合は、
V$DATABASE_BLOCK_CORRUPTION ビューに記録されます。これは、メディア・リカバリまたはブロック・メディア・
リカバリに使用できます。
例については付録を参照してください。
VALIDATE STRUCTUREオプションのあるANALYZE文
これは、データベースがオンラインの場合に、データおよび索引セグメントの両方の物理的な構造を検証するために使用
できます。索引の場合、索引の内部的な一貫性の他にも、このコマンドは、表と索引が同期しているかも検証できます。
メディア・リカバリおよびオブジェクトの再作成は、その後の診断および修正のため、実行による結果を使用できます。
例については付録を参照してください。
DBMS_REPAIRパッケージ
DBMS_REPAIR パッケージを使用すると、特定のデータまたは索引セグメントの構造を検証できます。これは、ブロッ
クの内部構造を検証し、検索した問題の結果とともに修復した表を移入します。また、これを、データ・セグメントに見
つかった破損によって影響を受ける索引を決定するためにも使用できます。例については付録を参照してください。
13.2.3
計画外停止の防止および検出
一般的には、まず、様々な停止を処理するための解決方法を考えます。ただし、これらの停止の防止や検出も同様に重要
です。計画停止は予測でき、停止時間も最小にできるため、計画外停止について考えます。
防止メカニズムには、適切な技術の導入および運用プラクティスの実装があります。運用上のベスト・プラクティスによ
って停止を防止することができ、フェイルオーバーの手順を自動化することによって停止時間を最小にできます。停止を
防ぐための共通のテーマは、運用上のベスト・プラクティスの実装とその励行です。
検出メカニズムは信頼性があり、問題の検出および通知に関して、時間に正確に機能する必要があります。監視インフラ
ストラクチャには、Oracle Enterprise Manager のようなツールも含まれます。アーキテクチャの複数層にわたる障害の検
出を設定し、適切なテストを実行してください。これらのツールはサイトの障害を検出し、セカンダリ・サイトに加えて
ローカルでも通知する必要があります。監視インフラストラクチャは、停止を迅速に確実に検出し、適切なエージェント
Maximum Availability Architecture
13-19
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
に通知し（人または自動化）、該当する場合は、その問題を解決する必要があります（中間層処理のための自動再起動、
Oracle Net Services のための自動フェイルオーバーなど）。
停止の種類については、「停止」の項を参照してください。ここでは、防止および検出に関する様々な方法について示し
ます。これらの停止の修復については、「停止からのリカバリ」の項を参照してください。これらの停止は、プライマリ・
サイトまたはセカンダリ・サイトのコンポーネントに影響を与える可能性があります。
表13-3: 計画外停止の防止および検出
計画外停止
防止
サイト全体の障害
•
データ・センターは、重要なリソースへの制限
されたアクセスによって保護。
•
冗長なインフラストラクチャは、様々な種類の
サイト全体の障害を引き起こす。
•
電源や、プライマリ・サイトとセカンダリ・サ
イト間のネットワーク・パスなどの外部リソー
スの代替ソースを計画する。
•
MAA で推奨されるアプリケーション・サーバ
ー・ノードの冗長なセットによって、1 つのノー
ド・セットでの障害はアプリケーションの可用
性に影響しない。
本番サイトで、各コンポーネントを検出
したり、アプリケーション・サービスを
隈なく監視するなど、中間層の障害を監
視する。
•
障害を検出するための監視インフラストラクチ
ャおよび必要に応じて中間層サーバー・ソフト
ウェア。
監視されるコンポーネントは、次のとお
りです。
•
製品に配置する前に、様々な負荷パターに対し
てアプリケーション層を適切にテストする。
•
アプリケーションに対するすべての変更は、変
更管理プロセスを通し、適切にテストされたソ
フトウェアのみを配置する。
すべてのノードをその構成に関して正確に複製
する。
アプリケーション層の
ノード障害
データベース層の
ノード障害
サイト障害を検出するためのプライマ
リ・サイトのハートビート。このハート
ビート・メカニズムはサイトの可用性と
アプリケーションの可用性を確認する。
•
ノード障害
•
ノード・コンポーネント障害
•
アプリケーション・サーバーのソフト
ウェアのクラッシュ
•
アプリケーション・ソフトウェアのク
ラッシュ
•
中間層の誤った構成
•
プライマリ・サイトで、各コンポーネ
ントを検出したり、アプリケーショ
ン・サービスを隈なく監視するなど、
中間層の障害を監視する。
•
セカンダリ・サイトで、プライマリ・
サイトのアプリケーションの可用性
を適切に監視し、必要に応じて引継ぎ
を行う。
•
WAN マネージャ、DNS サービスなどをローカル
で含むネットワーク・インフラストラクチャ
に、クライアントをセカンダリ・サイトのアプ
リケーション層にリダイレクトできるようなフ
ェイルオーバー機能を持たせる。また、このテ
ストを適切に行う。
•
データ・サーバー層に RAC を設置し、1 つのノ •
ード障害の場合に継続してデータ・サーバーを
提供する。
RAC は停止を隠し、ユーザーは使用可能なイン
スタンスに再接続される。
インスタンスの障害の検出および
データ・サーバーの再構成を、RAC
によって自動的に行う。このような障
害を監視し、関係する人員に自動的に
通知することが推奨される。
•
セカンダリ・サイトに、複数のスタンバイ・イ •
ンスタンスを準備する。
1 つに障害が発生した場合に、次のスタンバイ・
インスタンスが管理リカバリ・プロセス（MRP）
を再起動できる。
スタンバイ・インスタンスの障害検出
は自動化すること。提供するスタンバ
イ・インスタンスの 1 つが MRP を再
起動させること。
•
アプリケーション層の
全面的障害
検出
•
アプリケーション層のノード障害用防止メカニ
ズムを適用する。
•
セカンダリ・サイトに、プライマリ・サイトで
問題が発生した場合に引き継ぎを行う冗長なア
プリケーション層のセットを設け、停止から迅
速にリカバリする。セカンダリ・サイトのアプ
リケーション・サーバーをプライマリ・サイト
と同様に構成する。
Maximum Availability Architecture
13-20
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
計画外停止
防止
データベース層の
インスタンス障害
•
データ・サーバー層に RAC を設置し、1 つのノ •
ード障害の場合に継続してデータ・サーバーを
提供する。
RAC は停止を隠し、ユーザーは使用可能なイン
スタンスに再接続される。
インスタンスの障害の検出および
データ・サーバーの再構成を、RAC
によって自動的に行う。このような障
害を監視し、関係する人員に自動的に
通知することが推奨される。
•
セカンダリ・サイトに、複数のスタンバイ・イ •
ンスタンスを準備する。1 つに障害が発生した場
合に、次のスタンバイ・インスタンスが MRP を
再起動できる。
スタンバイ・インスタンスの障害検出
は自動化すること。提供するスタンバ
イ・インスタンスの 1 つが MRP を再
起動させること。
•
Oracle Net、アプリケーション層、ネットワーク・
インフラストラクチャのフェイルオーバーと共
に Data Guard を配置することによって、セカン
ダリ・サイトに対するデータ損失をゼロから最
小に止める。
•
スタンバイ・クラスタ全体の障害の場合、最大
保護モードでデータベースが構成されていない
かぎり、本番データベースへの影響はない。
この場合、本番データベースを再起動する前
に、保護モードを下げる必要がある。
•
データベースの物理的オブジェクトと論理的オ
ブジェクトへのアクセスを保護し、ユーザー・
レベルの厳しいデータベース・サーバー・セキ
ュリティを実装する。
•
データベース構造に対する変更を管理する変更
管理プロセスを実装する。
•
「運用上のベスト・プラクティス」に示される
プラクティスを実行する。
•
堅実なアプリケーションの設計および本番に配
置する前のテスト作業
•
例外が発生した場合にすべての Oracle および OS
エラー・メッセージを捉え、アプリケーション・
ログに記録するための堅実なアプリケーション
設計の手段。
•
堅実なセキュリティの実施が、ここで、おそら
く最も有効な保護コンポーネント。
データベース層の
クラスタ全体の障害
データ障害
ユーザー・エラー
冗長なコンポーネント
の障害
検出
プライマリ・サイトで、データベース・
サービスの可用性を監視する。データベ
ース・サービスが使用できない場合は、
通知を行い、アプリケーション層レベル
とネットワーク・インフラストラクチャ
でフェイルオーバーを開始する（ネーミ
ング・サービス、アプリケーション層の
ロード・バランサ）。
Oracle アラート・ログ、Oracle 監査ログ、
アプリケーション・サーバー・ログ、ア
プリケーション固有のログ、データベー
ス層の OS ログを監視するための監視イ
ンフラストラクチャ。必要に応じて、
通知および自動修復ジョブを実装する。
•
Oracle アラート・ログ、Oracle 監査ロ
グ、アプリケーション・サーバー・ロ
グ、アプリケーション固有のログ、デ
ータベース層の OS ログを監視するた
めの監視インフラストラクチャ。必要
に応じて、通知および自動修正ジョブ
を実装する。
•
論理エラーを検出し、スタンバイ・デ
ータベースを止めるような対処を行
うためのアプリケーション・ロジッ
ク。
MAA には、技術全体にわたってすべてのリソース
に関する冗長なコンポーネントが存在し、これに障
害が起こる可能性がある。単一箇所での障害はな
い。アクティブなコンポーネントの障害時には、冗
長なコンポーネントによる自動引継ぎが前提となっ
ている。これは事前にテストされ、不要な停止を防
ぐため定期的にテストされる必要がある。
Maximum Availability Architecture
13-21
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
13.2.4
セキュリティ・ポリシーおよび手順
ネットワークおよび施設に内部的にアクセスできる従業員および契約者は、企業データにとって最大の脅威となる場合が
あります。企業データは、企業が所有する最も価値ある資産の 1 つであり、適切なセキュリティ対策を施していないシス
テムまたはデータベースに保管した場合には深刻なリスクが生じます。正しく定義されたセキュリティ・ポリシーは、不
要なアクセスからシステムを守り、妨害行為からデリケートな企業情報を保護するために有効です。適切なデータ保護は、
セキュリティ違反による停止の可能性を減少させます。
•
適切なデータベース制御の実行
デフォルト・ユーザー・アカウントのロックおよび期限終了
パスワード管理の実行
デフォルト・ユーザー・パスワードの変更
データ辞書の保護の実行
必要な権限のみの許可（PUBLIC からの不必要な権限の削除を含む）
ランタイム・ファシリティの権限の制限
リモート・クライアントの適切な認証
データベース起動およびシャットダウン時のユーザー固有の SYSOPER 型の接続の使用
データベース管理用の厳密認証の一般的なユーザー・アカウントの使用
監査および DBA サブロールの作成
Oracle Advanced Security の使用の検討
退職した従業員のログインを削除するメカニズムの作成
テスト、開発および本番データベースに対する異なるパスワードの使用
•
ネットワーク・アクセスの制限
ファイアウォールの利用
ネットワーク IP アドレスの確認
Oracle リスナーの不当な管理の防止
ネットワーク・トラフィックの暗号化
•
オペレーティング・システムの強化
•
すべてのセキュリティ・パッチおよび次善策の適用
•
ウィルス保護の更新の維持
•
オペレーティング・システムのユーザー数の制限
•
セキュリティ監査の実行
•
セキュリティ・アドバイス通知の監視
注意: 次の項では、セキュリティ・ポリシーおよび対策において重要な項目について説明します。ただし、利用している
ベンダーのベスト・プラクティス、およびハードウェア、ネットワーク、オペレーティング・システム、クラスタ構成の
保護についての推奨事項を参照することも重要です。
Maximum Availability Architecture
13-22
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
適切なデータベース制御の実行
デフォルト・ユーザー・アカウントのロックおよび期限終了
Oracle9i は、多くのデフォルト（プリセット）のデータベース・サーバー・ユーザー・アカウントをインストールします。
Database Client Administration ツール（DBCA）は、データベース・サーバーのインストールが成功すると、SYS、SYSTEM、
SCOTT、DBSNMP、OUTLN および 3 つの JSERV ユーザーを除いて、自動的のすべてのデフォルトのデータベース・ユ
ーザー・アカウントをロックし、期限切れにします。手動で（DBCA を使用しないで）Oracle9i をインストールした場合
は、データベース・サーバーの作成が成功した際も、デフォルトのデータベース・ユーザーはロックされません。これら
のユーザー・アカウントをデフォルトの状態で残したままにすると、データへの不正アクセスまたはデータベース・プロ
セスの混乱を招く恐れがあります。DBCA を使用しないでなんらかの初期インストールを行った場合には、すべてのデフ
ォルト・データベース・ユーザー・アカウントをロックし、期限切れにしてください。
たとえば、次のコマンドを実行します。
SQL> alter user outln lock;
パスワード管理の実行
定期的なスケジュールを設定するか、OS レベルのソフトウェアを使用して、自動的にユーザー・アカウント・パスワー
ドを期限切れにして変更します。データベースによって提供されるような基本的なパスワード管理規則（パスワードの長
さ、履歴、複雑さ）を、すべてのユーザー・パスワードに適用し、すべてのユーザーに定期的にパスワードを変更するよ
う指示します。
デフォルト・ユーザー・パスワードの変更
組織は、すぐに SYS および SYSTEM アカウントのデフォルトのパスワードをそれぞれ CHANGE_ON_INSTALL と
MANAGER から他の適度に複雑なパスワードに変更します。これらの特権アカウントに対してデフォルトのパスワード
が変更されない場合は、デフォルト・パスワードの知識を持つユーザーが SYS または SYSTEM として接続できます。ま
た、
これらのアカウントは、
ユーザーが SYS または SYSTEM として接続するのを防ぐためロックされる場合もあります。
SYSTEM アカウントは、すべて一緒に削除される場合があります。
データ辞書の保護の実行
データベース・パラメータ O7_DICTIONARY_ACCESSIBILITY がデフォルトの設定 FALSE であることを確認します。こ
のパラメータが TRUE に設定されていると、ANY 権限がデータ辞書に適用され、ANY 権限を持つ悪意あるユーザーがデ
ータ・ディクショナリ表にアクセス、または変更できます。
必要な権限のみの許可（PUBLICからの不必要な権限の削除を含む）
必要な権限以上の権限をデータベース・ユーザーに与えないようにします。つまり、効果的かつ簡潔に作業を行うために
実際に必要な権限のみをユーザーに与えるという最小限の権限の原則を維持します。最小限の権限を実行するためには、
次の制限を行います。
•
•
データベース・ユーザーに許可する SYSTEM および OBJECT 権限数を制限する。
可能なかぎりデータベースに接続する SYS 権限の数を制限する。たとえば、一般的に、DBA 権限を持たないユ
ーザーに CREATE ANY TABLE を許可する必要はありません。
Maximum Availability Architecture
13-23
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
不必要なすべての権限およびロールをデータベース・サーバー・ユーザー・グループ PUBLIC から削除します。PUBLIC
は、Oracle データベースのすべてのユーザーに許可されるデフォルトのロールとして動作します。すべてのデータベー
ス・ユーザーは、PUBLIC に許可された権限を実行できます。このような権限には、最小権限のユーザーが、本来は直接
アクセスできないパッケージにアクセスし、実行することを許可できる各種 PL/SQL パッケージの EXECUTE が含まれま
す。
ランタイム・ファシリティの権限の制限
Oracle Java Virtual Machine（Oracle JVM）のようなデータベース・サーバーのランタイム・ファシリティに対してすべて
の権限を割り当てないようにしてください。データベース・サーバー外でファイルおよびパッケージを実行できるこのよ
うな機能の場合は、明示的なドキュメント・ルート・ファイル・パスに特定の権限を許可します。攻撃されやすいランタ
イム・コールの例:
call dbms_java.grant_permission(‘SCOTT’,
‘SYS:java.io.FilePermission’,’<<ALL FILES>>’,’read’);
より効果的（より安全）なランタイム・コールの例:
Calldbms_java.grant_permission(‘SCOTT’,
‘SYS:java.io.FilePermission’,’<<actual directory path>>’,’read’);
リモート・クライアントの適切な認証
Oracle データベースに接続するクライアントに、サーバーベースの適切な認証を設定します。リモート認証を制限し、こ
のためデータベースに対するクライアントの信頼を延期させるためには、データベース・パラメータ
REMOTE_OS_AUTHENT を FALSE に設定します。
データベース起動およびシャットダウン時のユーザー固有のSYSOPER型の接続の使用
データベースの起動とシャットダウンの場合のみ、AS SYSOPER で接続します。接続が必要なユーザーごとに異なるユ
ーザー・アカウント（オペレーティング・システムの異なるアカウント、またはパスワード・ファイルの異なるエントリ）
を作成します。SYSOPER としての接続は、SYSOPER として接続しているユーザーの名前を用いて、オペレーティング・
システム・ファイルに対して監査されます。
データベース管理用の厳密認証の一般的なユーザー・アカウントの使用
データベースの管理を行うユーザーには、AS SYSDBA で接続するよりも、一般的なデータベース・ユーザーを作成し、
DBA ロール（または適切なサブロール）を許可します。また、これらのユーザーが、RSA Security の SecurID カードなど、
Oracle Advanced Security によってサポートされる厳密認証のフォームを使用することをお薦めします。
監査およびDBAサブロールの作成
機能と責任分担をより適切に分離するためには、監査機能から純粋なデータベース管理機能を分離した小さなロールを作
成します。これにより、ユーザーが、データベース管理者ロールに含まれるシステム権限の使用を監査できます。
Maximum Availability Architecture
13-24
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
監査記録の保護
監査証跡を保存する場合には、記録を堅固に保護するとことを推奨します。DBA から監査証跡のコンテントを保存する
という観点から最も安全な場所は、オペレーティング・システム自体の監査証跡またはオペレーティング・システム・フ
ァイルです。データベース・サーバーが、すべての監査記録を SYS.AUD$に書き込むかわりに、OS に書き込むことを推
奨します（OS に組込み監査証跡がない場合は、Oracle が監査記録を書き込む OS ファイルに適切な OS ファイル保護を設
ける）。これは、AUDIT_ TRAIL init.ora パラメータを DB から OS に変更するだけの簡単な操作です。
（注意: AUDIT_TRAIL のデフォルトの値は NONE、つまり監査なしです。）
Oracle Advanced Securityの使用の検討
可能な場合は、ネットワーク認証サービス（Kerberos など）、トークン・カード、スマート・カードまたは X.509 証明書
のある Oracle Advanced Security（Oracle9i Database Enterprise Edition のオプション）を使用します。これらのサービスは、
ユーザーの厳密認証を可能にし、Oracle9i への不当なアクセスに対してより有効な保護を提供します。
退職した従業員のログインを削除するメカニズムの作成
従業員の退職と同時に、その従業員の企業の全アカウントを削除するか、恒久的に無効に設定します。
テスト、開発および本番データベースに対する異なるパスワードの使用
本番データベースをテストおよび開発作業用に複製するときには、機密データを削除、変更または制限するように注意し
てください。
ネットワーク・アクセスの制限
ファイアウォールの利用
ファイアウォールの背後にデータベース・サーバーを維持します。データベース・サーバーがファイアウォールの背後に
ある場合に、ファイアウォールに穴を開けないようにします。たとえば、インターネット接続のために Oracle Listener の
1521 ポートをオープンな状態で残さないでください。
ネットワークIPアドレスの確認
Oracle Net の妥当なノード・チェック・セキュリティ機能を使用して、指定した IP アドレスで、ネットワーク・クライア
ントから Oracle サーバー・プロセスへのアクセスを許可または拒否することを考慮してください。この機能を使用する
ためには、次の sqlnet.ora（Oracle Net パ構成ファイル）パラメータを設定します。
tcp.validnode_checking = YES
tcp.excluded_nodes = {list of IP addresses}
tcp.invited_nodes = {list of IP addresses}
最初のパラメータは機能を有効にし、後の 2 つのパラメータは、それぞれ指定されたクライアント IP アドレスが Oracle
リスナーに接続するのを拒否または許可します（これによって潜在的な DoS 攻撃を防止します）。この機能は、サーバ
ーIP アドレスの割当てに DHCP を使用する環境では正常に動作しない場合があります。
Oracleリスナーの不当な管理の防止
常に、Oracle リスナーには意味のある適格なパスワードを構築して、Oracle リスナーのリモート構築を防止します。
また、listener.ora（Oracle Listener 制御ファイル）セキュリティ構成パラメータを次のように設定します。
ADMIN_RESTRICTIONS_listener_name=ON
Maximum Availability Architecture
13-25
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録B
付録 - 運用上のベスト・プラクティス
ネットワーク・トラフィックの暗号化
可能な場合は、Oracle Advanced Security を使用して、クライアント、データベースおよびアプリケーション・サーバー間
のネットワーク・トラフィックを暗号化します。
オペレーティング・システムの強化
不必要なすべてのオペレーティング・システム・サービスを無効にして、ホスト・オペレーティング・システムを強化し
ます。UNIX も、Windows プラットフォームも、多くのオペレーティング・システム・サービスを提供していますが、配
置においてはほとんど必要ありません。このようなサービスには、FTP、TFTP、TELNET などがあります。
無効にする各サービスの UDP と TCP ポートの両方をクローズしてください。1 つのポートを無効にして、他のポートを
無効にしないと、オペレーティング・システムの保護が弱くなります。
すべてのセキュリティ・パッチおよび次善策の適用
常に、Oracle データベースが常駐するオペレーティング・システムと Oracle データベース自身の両方、およびインストー
ルした Oracle データベースオプションとコンポーネントに、関連する最新のすべてのセキュリティ・パッチを適用しま
す。定期的に、Oracle Corporation が発表するセキュリティ・アラートの詳細について、Oracle Technology Network のセキ
ュリティ・サイトを確認します（http://otn.oracle.co.jp/security/index.html）。
ウィルス保護の更新の維持
最新のウィルス保護ソフトウェアを使用してください。CSI/FBI Computer Crime & Security Survey は、ウィルスによる被
害が最も多く、最も損失が大きいことを指摘しています。
オペレーティング・システムのユーザー数の制限
データベース・ホストのオペレーティング・システムのアカウント、特に、ルートまたはハイレベル権限を取得するユー
ザー数を可能なかぎり制限します。また、Oracle Corporation によって特別に指示されないかぎりは、Oracle9i ホーム（イ
ンストール）ディレクトリ内で、オペレーティング・システム特権ユーザーまたは Oracle 所有者が、デフォルト・ファ
イルおよびディレクトリ権限を変更する権限を持たないことも推奨します。
セキュリティ監査の実行
システム全体のセキュリティを調査するため、定期的に、内部または外部監査の実行をお薦めします。
企業への侵入を試みることによってセキュリティ・レベルの調査を目的とするサード・パーティ・ベンダーがあります。
セキュリティ・アドバイス通知の監視
コンピュータ緊急対応チーム（CERT）からのセキュリティ・アドバイスに常に注意を払います。
http://www.cert.org/
Maximum Availability Architecture
13-26
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
14. 付録C
データベースSPFILEおよび
およびOracle
Net構成
構成
付録 - データベース
および
ファイルの例
この付録のファイル・サンプルは、MAA データベース層の Oracle 構成ファイルに関連するベスト・プラクティスを示す
ものです。また、これらのサンプルによって、データベース・システムのパラメータ・ファイル（SPFILE）が Oracle Net
の構成に対して、動的サービス登録の目的のためにどのように関連しているかについて、明確に示されています。
この付録には、次のサンプル・ファイルが含まれています。
•
SPFILE
•
Oracle Net の構成ファイル
各ホストの listener.ora
各ホストの tnsnames.ora
これらのファイルは、ORACLE_BASE=/mnt/app/oracle において次の設定を使用して参照できます。
プライマリ・サイト
ホスト名
ORACLE_SID
primary_host1
SALES1
primary_host2
SALES2
セカンダリ・サイト
Maximum Availability Architecture
ホスト名
ORACLE_SID
secondary_host1
SALES1
secondary_host2
SALES2
14-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録C
）の例
付録 - データベース・システムのパラメータ・ファイル（SPFILE）の例
データベース・システムのパラメータ・ファイル（
14.1
14.1.1
データベース・システムのパラメータ・ファイル（
）の例
データベース・システムのパラメータ・ファイル（SPFILE）の例
ァイル（
すべての構成に共通
次のデータベース・システム・パラメータ・ファイルの例は、プライマリ・データベース・インスタンス、およびフィジ
カルまたはロジカル・スタンバイ・データベース（あるいはその両方）に対して共通です。データベース・インスタンス
に特有のパラメータについては、この項の後で説明します。
################################################################
#
see “Database Configuration Best Practices”
#
compatible >= 9.0.0
################################################################
*.COMPATIBLE='9.2.0'
*.CLUSTER_DATABASE=true
# RAC naming
SALES1.THREAD=1
SALES2.THREAD=2
SALES1.INSTANCE_NUMBER=1
SALES2.INSTANCE_NUMBER=2
################################################################
#
# Data Guard Configuration parameters
#
see “Data Guard Configuration Best Practices”
################################################################
*.STANDBY_ARCHIVE_DEST='/arch1/SALES'
*.STANDBY_FILE_MANAGEMENT='auto'
*.LOG_ARCHIVE_DEST_STATE_1='enable'
*.LOG_ARCHIVE_DEST_STATE_2=’defer’
*.LOG_ARCHIVE_DEST_STATE_3='alternate'
*.LOG_ARCHIVE_DEST_STATE_4=’defer’
*.LOG_ARCHIVE_FORMAT='arch_%t_%S.log'
*.LOG_ARCHIVE_START=true
# This can be used for debugging purposes
*.LOG_ARCHIVE_TRACE=0
*.REMOTE_ARCHIVE_ENABLE=true
*.ARCHIVE_LAG_TARGET=0
*.DB_CREATE_FILE_DEST=’’
################################################################
#
# Fast Start Checkpointing Parameters
#
see “Database Configuration Best Practices”
#
for determining the proper setting
################################################################
*.FAST_START_MTTR_TARGET=300
*.LOG_CHECKPOINT_INTERVAL=0
*.LOG_CHECKPOINT_TIMEOUT=0
################################################################
#
# Oracle Net Services Related Parameters
#
see “Database Configuration Best Practices”
#
subheading “Ensuring Registration with Initialization Parameters”
#
###################################### ##########################
*.LOCAL_LISTENER='SALES_lsnr'
#################################################################
#
# Other Best Practices Related Parameters
#
see “Database Configuration Best Practices”
#################################################################
Maximum Availability Architecture
14-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録C
）の例
付録 - データベース・システムのパラメータ・ファイル（SPFILE）の例
データベース・システムのパラメータ・ファイル（
*.DB_BLOCK_CHECKING=true
*.DB_BLOCK_CHECKSUM=true
*.LOG_CHECKPOINTS_TO_ALERT=true
*.TIMED_STATISTICS=true
#################################################################
#
# Automatic undo management, 1 tablespace per instance
#
see “Database Configuration Best Practices”
#
and “Integrating automatic undo”
#################################################################
*.UNDO_MANAGEMENT='auto'
SALES1.UNDO_TABLESPACE='rbs01'
SALES2.UNDO_TABLESPACE='rbs02'
*.UNDO_RETENTION=900
14.1.2
プライマリおよびフィジカル・スタンバイに特有のパラメータ
次のパラメータは、プライマリおよびフィジカル・スタンバイ・データベースの両方に適用されます。
*.DB_NAME=SALES
*.SERVICE_NAMES='SALES'
*.CONTROL_FILES='/dev/vx/rdsk/ha-dg/SALES_cntr01',
'/dev/vx/rdsk/ha-dg/SALES_cntr02'
# OFA Compliant directory structure
*.BACKGROUND_DUMP_DEST='/mnt/app/oracle/admin/SALES/bdump'
*.CORE_DUMP_DEST='/mnt/app/oracle/admin/SALES/cdump'
*.USER_DUMP_DEST='/mnt/app/oracle/admin/SALES/udump'
14.1.3
ロジカル・スタンバイに特有のパラメータ
次のパラメータは、ロジカル・スタンバイ・データベースに適用されます。フィジカル・スタンバイ・データベースおよ
びロジカル・スタンバイ・データベースが同じホストに定義されている場合は、これらのパラメータの変更が必要になり
ます。
*.DB_NAME=SALES_LOG
*.SERVICE_NAMES='SALES_LOG'
*.CONTROL_FILES='/dev/vx/rdsk/ha-dg/SALES_LOG_cntr01',
'/dev/vx/rdsk/ha-dg/SALES_LOG_cntr02'
# OFA Compliant directory structure
*.BACKGROUND_DUMP_DEST='/mnt/app/oracle/admin/SALES/bdump'
*.CORE_DUMP_DEST='/mnt/app/oracle/admin/SALES/cdump'
*.USER_DUMP_DEST='/mnt/app/oracle/admin/SALES/udump'
14.1.4
プライマリ・インスタンス特有のパラメータ － プライマリ・サイト
選択したスタンバイの構成によって、3 つのパラメータ・セットのいずれかを、プライマリ・サイトで実行しているデー
タベースのシステム・パラメータ・ファイルに指定する必要があります。
Maximum Availability Architecture
14-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録C
）の例
付録 - データベース・システムのパラメータ・ファイル（SPFILE）の例
データベース・システムのパラメータ・ファイル（
フィジカル・スタンバイ・データベースのみ
################################################################
# Assuming that only a Physical standby database has been
#
deployed, then set the six parameters as follows.
#
# FAL_CLIENT / FAL_SERVER will only be used when this database
# is a Physical Standby database.
#
# LOG_ARCHIVE_DEST_2 is specified assuming the Physical Standby
# database is configured for MAXIMUM PROTECTION mode.
#
# LOG_ARCHIVE_DEST_4 is not set as there is no Logical Standby
# database in this configuration.
################################################################
*.FAL_CLIENT='SALES_PRIM'
*.FAL_SERVER='SALES_SEC'
*.LOG_ARCHIVE_DEST_1='location=/arch1/SALES arch noreopen max_failure=0
mandatory alternate=log_archive_dest_3'
*.LOG_ARCHIVE_DEST_2='service=SALES_SEC reopen=15 max_failure=10 lgwr
sync=noparallel affirm delay=30'
*.LOG_ARCHIVE_DEST_3='location=/arch2/SALES arch'
*.LOG_ARCHIVE_DEST_4=’’
ロジカル・スタンバイのみ
################################################################
# Assuming that only a Logical standby database has been
#
deployed, then set the six parameters as follows.
#
# FAL_CLIENT / FAL_SERVER are not set as there is no Physical
# Standby database in this configuration.
#
# LOG_ARCHIVE_DEST_2 is not set as there is no Physical Standby
# database in this configuration.
#
# LOG_ARCHIVE_DEST_4 is specified assuming the Logical Standby
# database is configured for MAXIMUM AVAILABILITY mode.
################################################################
*.FAL_CLIENT=''
*.FAL_SERVER=''
*.LOG_ARCHIVE_DEST_1='location=/arch1/SALES arch noreopen max_failure=0
mandatory alternate=log_archive_dest_3'
*.LOG_ARCHIVE_DEST_2=’’
*.LOG_ARCHIVE_DEST_3='location=/arch2/SALES arch'
*.LOG_ARCHIVE_DEST_4='service=SALES_LOG_SEC reopen=15 max_failure=10
lgwr sync=noparallel affirm delay=30
Maximum Availability Architecture
14-4
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録C
）の例
付録 - データベース・システムのパラメータ・ファイル（SPFILE）の例
データベース・システムのパラメータ・ファイル（
フィジカルおよびロジカルのスタンバイ
################################################################
# Assuming that both a Physical and Logical standby database has
#
been deployed, then set the six parameters as follows.
#
# FAL_CLIENT / FAL_SERVER will only be used when this database
# becomes a Physical Standby, following a scheduled switchover.
#
# LOG_ARCHIVE_DEST_2 is specified assuming the Physical Standby
# database is configured for MAXIMUM PROTECTION mode.
#
# LOG_ARCHIVE_DEST_4 is specified with the DEPENDENCY option.
################################################################
*.FAL_CLIENT='SALES_PRIM'
*.FAL_SERVER='SALES_SEC'
*.LOG_ARCHIVE_DEST_1='location=/arch1/SALES arch noreopen max_failure=0
mandatory alternate=log_archive_dest_3'
*.LOG_ARCHIVE_DEST_2='service=SALES_SEC reopen=15 max_failure=10 lgwr
sync=noparallel affirm delay=30'
*.LOG_ARCHIVE_DEST_3='location=/arch2/SALES arch'
*.LOG_ARCHIVE_DEST_4='service=SALES_LOG_SEC reopen=15 max_failure=10
delay=30 dependency=LOG_ARCHIVE_DEST_2'
14.1.5
フィジカル・スタンバイ・インスタンス特有のパラメータ －
セカンダリ・サイト
セカンダリ・サイトにフィジカル・スタンバイ・データベースが配置されている場合は、次の 3 つのパラメータ・セット
のいずれかを、セカンダリ・サイトで実行しているフィジカル・スタンバイ・データベースのシステム・パラメータ・フ
ァイルに指定する必要があります。
フィジカル・スタンバイ・データベースのみ
################################################################
# Assuming that only a Physical standby database has been
#
deployed, then set the six parameters as follows.
#
# FAL_CLIENT / FALL_SERVER will only be used when this databasse
# is a Physical Standby database.
#
# LOG_ARCHIVE_DEST_2 is specified assuming the Physical Standby
# database is configured for MAXIMUM PROTECTION mode.
#
# LOG_ARCHIVE_DEST_4 is not set as there is no Logical Standby
# database is this configuration.
################################################################
*.FAL_CLIENT='SALES_SEC'
*.FAL_SERVER='SALES_PRIM'
*.LOG_ARCHIVE_DEST_1='location=/arch1/SALES arch noreopen max_failure=0
mandatory alternate=log_archive_dest_3'
*.LOG_ARCHIVE_DEST_2=service=SALES_PRIM reopen=15 max_failure=10 lgwr
sync=noparallel affirm delay=30'
*.LOG_ARCHIVE_DEST_3='location=/arch2/SALES arch'
*.LOG_ARCHIVE_DEST_4=’’
Maximum Availability Architecture
14-5
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録C
）の例
付録 - データベース・システムのパラメータ・ファイル（SPFILE）の例
データベース・システムのパラメータ・ファイル（
ロジカル・スタンバイのみ － 適用不可
これらのパラメータはフィジカル・スタンバイ・インスタンスに特有なため、ロジカル・スタンバイのみのパラメータ・
セットには適用できません。
フィジカルおよびロジカルのスタンバイ
################################################################
# Assuming that both a Physical and Logical standby database has
#
been deployed, then set the six parameters as follows.
#
# FAL_CLIENT / FAL_SERVER will only be used when this database
# is a Physical Standby database.
#
# LOG_ARCHIVE_DEST_2 is specified assuming the Physical Standby
# database is configured for MAXIMUM PROTECTION mode.
#
# LOG_ARCHIVE_DEST_4 is specified with the DEPENDENCY option.
# This parameter is only applicable when the primary database is
# running locally at the Secondary Site, following a switchover
# or failover of the Physical Standby databases.
################################################################
*.FAL_CLIENT='SALES_SEC'
*.FAL_SERVER='SALES_PRIM'
*.LOG_ARCHIVE_DEST_1='location=/arch1/SALES arch noreopen max_failure=0
mandatory alternate=log_archive_dest_3'
*.LOG_ARCHIVE_DEST_2='service=SALES_PRIM reopen=15 max_failure=10 lgwr
sync=noparallel affirm delay=30'
*.LOG_ARCHIVE_DEST_3='location=/arch2/SALES arch'
# LOG_ARCHIVE_DEST_4='service=SALES_LOG_SEC reopen=15 max_failure=10
delay=30 dependency=LOG_ARCHIVE_DEST_1'
14.1.6
ロジカル・スタンバイ・インスタンス特有のパラメータ －
セカンダリ・サイト
セカンダリ・サイトにロジカル・スタンバイ・データベースが配置されている場合は、次の 3 つのパラメータ・セットの
いずれかを、セカンダリ・サイトで実行しているロジカル・スタンバイ・データベースのシステム・パラメータ・ファイ
ルに指定する必要があります。
フィジカル・スタンバイ・データベースのみ － 適用不可
これらのパラメータはロジカル・スタンバイ・インスタンスに特有なため、フィジカル・スタンバイのみのパラメータ・
セットには適用できません。
Maximum Availability Architecture
14-6
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録C
）の例
付録 - データベース・システムのパラメータ・ファイル（SPFILE）の例
データベース・システムのパラメータ・ファイル（
ロジカル・スタンバイのみ
################################################################
# Assuming that only a Logical standby database has been
#
deployed, then set the six parameters as follows.
#
# FAL_CLIENT / FAL_SERVER are not set as there is no Physical
# Standby database in this configuration.
#
# LOG_ARCHIVE_DEST_2 is not set as there is no Physical Standby
# database in this configuration.
#
#
# LOG_ARCHIVE_DEST_4 is specified assuming the Logical Standby
# database in configured for MAXIMUM AVAILABILITY mode.
################################################################
*.FAL_CLIENT=''
*.FAL_SERVER=''
*.LOG_ARCHIVE_DEST_1='location=/arch1/SALES arch noreopen max_failure=0
mandatory alternate=log_archive_dest_3'
*.LOG_ARCHIVE_DEST_2=’’
*.LOG_ARCHIVE_DEST_3='location=/arch2/SALES arch'
*.LOG_ARCHIVE_DEST_4='service=SALES_PRIM reopen=15 max_failure=10
lgwr async=20480 delay=30 net_timeout=30'
フィジカルおよびロジカルのスタンバイ
################################################################
# Assuming that both a Physical and Logical standby database has
#
been deployed, then set the six parameters as follows.
#
# FAL_CLIENT / FAL_SERVER are not used by a Logical Standby
# database. Therefore they are not set.
#
# LOG_ARCHIVE_DEST_2 is not set as there is no Physical Standby
# database that is a dependent of this Logical Standby database.
#
# LOG_ARCHIVE_DEST_4 is not set as there is a Physical Standby
# database and for MAA we always recommend switching over to
# the Physical Standby database.
################################################################
*.FAL_CLIENT=''
*.FAL_SERVER=''
*.LOG_ARCHIVE_DEST_1='location=/arch1/SALES_LOG arch noreopen max_failure=0
mandatory alternate=log_archive_dest_3'
*.LOG_ARCHIVE_DEST_2=''
*.LOG_ARCHIVE_DEST_3='location=/arch2/SALES_LOG arch'
*.LOG_ARCHIVE_DEST_4=''
Maximum Availability Architecture
14-7
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録C
の構成ファイルの例
付録 - Oracle Netの構成ファイルの例
14.2
14.2.1
Oracle Netの構成ファイルの例
の構成ファイルの例
動的インスタンス登録を使用したprimary_host1に対する
に対するlistener.ora
動的インスタンス登録を使用した
に対する
lsnr_SALES =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST=
(ADDRESS= (PROTOCOL=tcp)(HOST=primary_host1)(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
14.2.2
動的インスタンス登録を使用したprimary_host2に対する
に対するlistener.ora
動的インスタンス登録を使用した
に対する
lsnr_SALES =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST=
(ADDRESS= (PROTOCOL=tcp)(HOST=primary_host2)(PORT=1513)
(QUEUESIZE=1024)))))
# Password Protect listener; See "Oracle Net Services Administration Guide"
PASSWORDS_lsnr_SALESS = 876EAE4513718ED9
# Prevent listener administration
ADMIN_RESTRICTIONS_lsnr_SALES=ON
14.2.3
動的インスタンス登録を使用したprimary_host
1および
および2に対する
動的インスタンス登録を使用した
および に対する
tnsnames.ora
# Used for detabase parameter local_listener
SALES_lsnr=
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(PORT=1513)))
# Net service used for log_archive_dest_2
SALES_SEC =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=secondary_host1))
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=secondary_host2)))
(CONNECT_DATA=(SERVICE_NAME=SALES)))
# Alternate for log_archive_dest_2 when in maximum protection mode
SALES_SEC_ALT=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=secondary_host2)))
(CONNECT_DATA=(SERVICE_NAME=SALES)))
SALES_SEC_ALT2=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=secondary_host1)))
(CONNECT_DATA=(SERVICE_NAME=SALES)))
# Net service used for log_archive_dest_4
SALES_LOG_SEG =
Maximum Availability Architecture
14-8
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録C
の構成ファイルの例
付録 - Oracle Netの構成ファイルの例
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=secondary_host1))
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=secondary_host2)))
(CONNECT_DATA=(SERVICE_NAME=SALES_LOG)))
14.2.4
動的インスタンス登録を使用したsecondary_host1に対する
に対するlistener.ora
動的インスタンス登録を使用した
に対する
lsnr_SALES =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST=
(ADDRESS= (PROTOCOL=tcp))(HOST=secondary_hostl)(PORT=1513)
(QUEUESIZE=1024)))))
# Password Protect the listener; See "Oracle Net Services Administration
Guide"
PASSWORDS_lsnr_SALES = 876EAE4513718ED9
# Prevent listener administration
ADMIN_RESTRICTIONS_lsnr_SALES=ON
14.2.5
動的インスタンス登録を使用したsecondary_host2に対する
に対するlistener.ora
動的インスタンス登録を使用した
に対する
lsnr_SALES =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST=
(ADDRESS= (PROTOCOL=tcp))(HOST=secondary_host2)(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
Maximum Availability Architecture
14-9
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録C
の構成ファイルの例
付録 - Oracle Netの構成ファイルの例
14.2.6
動的インスタンス登録を使用した
1および
および2に対する
動的インスタンス登録を使用したsecondary_host
を使用した
および に対する
tnsnames.ora
# Used for database parameter local_listener
SALES_lsnr=
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(PORT=1513)))
# Net service used for log_archive_dest_2
SALES_PRIM =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=primary_host1))
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=primary_host2)))
(CONNECT_DATA=(SERVICE_NAME=SALES)))
# Alternate for log_archive_dest_2 when in maximum protection mode
SALES_PRIM_ALT=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=primary_host2)))
(CONNECT_DATA=(SERVICE_NAME=SALES)))
SALES_PRIM_ALT2=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=primary_host1)))
(CONNECT_DATA=(SERVICE_NAME=SALES)))
# Net service used for log_archive_dest_4
SALES_LOG_SEC =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=primary_host1))
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=primary_host2)))
(CONNECT_DATA=(SERVICE_NAME=SALES)))
14.2.7
SDU=32Kの静的登録用のネット・サービス・ファイルの例
の静的登録用のネット・サービス・ファイルの例
SDU の設定では静的登録が必要です。
listener.ora（本番およびスタンバイ）
（本番およびスタンバイ）
# If using a physical and logical a standby then there will be multiple SID’s
lsnr_SALES =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST=
(ADDRESS= (PROTOCOL=tcp))(HOST=<local hostname>)(PORT=1513)
(QUEUESIZE=1024)(SDU=32768))))))
SID_LIST_LSNR_SALES =
(SID_LIST =
(SID_DESC =
(SDU=32768)
(ORACLE_HOME = <local ORACLE_HOME path>)
(SID_NAME = <local ORACLE_SID>)))
Maximum Availability Architecture
14-10
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録C
の構成ファイルの例
付録 - Oracle Netの構成ファイルの例
tnsnames.ora（本番クラスタ）
（本番クラスタ）
# log_archive_dest_2 service under normal operations
# set to standby MRP node
SALES_SEC =
(DESCRIPTION=
(SDU=32768)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=secondary_host1)))
(CONNECT_DATA=(SID=SALES1)))
# log_archive_dest_2 service when standby maintenance is being done on
# initial Managed Recovery Process (MRP) node
SALES_SEC_ALT=
(DESCRIPTION=
(SDU=32768)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=secondary_host2)))
(CONNECT_DATA=(SID=SALES2)))
# Net service used for log_archive_dest_4
SALES_LOG_SEC =
(DESCRIPTION=
(SDU=32768)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=secondary_host2)))
(CONNECT_DATA=(SID=SALES_LOG1)))
tnsnames.ora（スタンバイ・クラスタ）
（スタンバイ・クラスタ）
# log_archive_dest_2 service under normal operations
SALES_PRIM =
(DESCRIPTION=
(SDU=32768)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=primary_host1)))
(CONNECT_DATA=(SID=SALES1)))
# log_archive_dest_2 service when standby maintenance is being done on
# initial MNP node
SALES_PRIM_ALT=
(DESCRIPTION=
(SDU=32768)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=secondary_host2)))
(CONNECT_DATA=(SID=SALES2)))
# Net service used for log_archive_dest_4
SALES_LOG_SEC =
(DESCRIPTION=
(SDU=32768)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(PORT=1513)(HOST=secondary_host2)))
(CONNECT_DATA=(SID=SALES_LOG1)))
詳細は、Oracle Net Services のドキュメントを参照してください。
Maximum Availability Architecture
14-11
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
15. 付録D
付録 - テスト構成
RAC および Data Guard は、MAA における 2 つの重要なコンポーネントです。MAA でこれらのコンポーネントの使用を
検証には、次のテスト環境を使用します。
15.1
RACのアクティブ
のアクティブ/アクティブ・テ
のアクティブ アクティブ・テスト構成
アクティブ・テスト構成
次の図は、アクティブ/アクティブ構成における RAC の使用、および MAA の重要なコンポーネントとしてファスト・ス
タート・チェックポインティングを検証する環境を示しています。
図15-1: RACのアクティブ
のアクティブ/アクティブ・テスト構成
のアクティブ アクティブ・テスト構成
100BaseT のネットワーク・スイッチを介して 2 ノードの Sun E4000 クラスタ上で稼働している Oracle データベースにロ
ードをスイッチするためには、2 つの SUN Ultra 60 ワークステーションを使用していました。これらのデータベース・ノ
ードは Sun Photon ディスク・アレイに直接割り当てられており、これらのディスク・アレイは、Veritas CVM 3.0.4 を使
用して 18.9GB のディスクにストライプおよびミラー化されているデータベース・ファイル用の SAME セットで構成され
ていました。
Maximum Availability Architecture
15-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録D
付録 - テスト構成
15.2
Data Guardプライマリ・サイト
プライマリ・サイト/セカンダリ・サイトのテスト構成
プライマリ・サイト セカンダリ・サイトのテスト構成
次の図は、プライマリおよびセカンダリ・サイトの両方に対して対称型の構成を推奨する理由、および MAA の重要なコ
ンポーネントとして Data Guard の使用を検証する設定を示しています。
図15-2: Data Guardのテスト構成
のテスト構成
本番およびスタンバイ・サイトは、同じ 2 ノード・クラスタです。これはすべて、100BaseT ネットワークのスイッチを
介してパブリック・ネットワークに接続されています。このデータベース・ノードは Sun Photon ディスク・アレイに直
接割り当てられていて、これらのディスク・アレイは、Veritas CVM 3.0.4 を使用して 4.18GB のディスクにストライプデ
ータベース・ファイル用の SAME セットで構成されていました。
Maximum Availability Architecture
15-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録D
付録 - テスト構成
15.3
SAMEテスト構成
テスト構成
次の図は、SAME の検証で使用する設定を示しています。SAME 構成は、ストレージ構成でディスク・ドライブの最適な
使用率を実現するために設計されています。この構成は、ランダム・アクセスとシーケンシャル・スループットの両方に
対して最適化を行います。SAME では、アクセス率とスループットのいずれも維持したまま、接続性によって、実際にデ
ィスク・ドライバが実現し得る最大スループットよりも少ないスループットに制限された場合でも、適切に機能します。
SAME 検証のテスト結果と構成の詳細を確認するには、
http://otn.oracle.com/deploy/availability/pdf/SAME_HP_WP_112002.pdf の「SAME and the HP XP512」のホワイト・ペーパー
を参照してください。SAME の概念と一般的なガイドラインの詳細は、
http://otn.oracle.com/deploy/availability/pdf/oow2000_same.pdf を参照してください。
図15-3: SAMEのテスト構成
のテスト構成
Maximum Availability Architecture
15-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
16. 付録E
付録 - オブジェクトの再編成とリカバリの例
この項には、オブジェクト停止の処理で使用できる機能が記載されています。ここでの内容とあわせて、「停止」および
「停止からのリカバリ」の項を参照してください。この項は、次の 2 つの内容に分かれています。
.オブジェクトの再編成例
•
オンラインで表を再編成する
ALTER TABLE 文
.オブジェクトのリカバリ例
•
フラッシュバック問合せ
RMAN のブロック・メディア・リカバリ
DBMS_REPAIR パッケージ
DBVERIFY
RMAN のブロック検証
16.1
オブジェクトの再編成例
この項では、オブジェクト・リカバリ機能の使用例を示します。各機能のさらに詳しい例については、関連する Oracle
ドキュメントを参照してください。
16.1.1
オンラインで表を再編成する
ここでは、オンライン再定義の例を示しています。この例では、オンライン再定義を使用して、dist 表の street address（住
所）を削除します。再編成する表は、次のとおりです。
SQL> DESC SALES.DIST
NAME
NULL?
----------------------------------------- -------D_ID
D_W_ID
D_YTD
D_TAX
D_NEXT_O_ID
D_NAME
D_STREET_1
D_STREET_2
D_CITY
D_STATE
D_ZIP
TYPE
---------------------NUMBER(2)
NUMBER(5)
NUMBER
NUMBER
NUMBER
VARCHAR2(10)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
CHAR(2)
CHAR(9)
A) 表を再編成できることを確認します。
SQL> EXECUTE DBMS_REDEFINITION.CAN_REDEF_TABLLE('SALES','DIST',2);
PL/SQL procedure successfully completed.
Maximum Availability Architecture
16-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録E
付録 - オブジェクトの再編成とリカバリの例
B) 仮表を作成します。
SQL> CREATE TABLE DIST_INTERIM (
D_ID
NUMBER(2),
D_W_ID
NUMBER(5),
D_YTD
NUMBER,
D_TAX
NUMBER,
D_NEXT_O_ID NUMBER,
D_NAME
VARCHAR2(10),
D_CITY
VARCHAR2(20),
D_STATE
CHAR(2),
D_ZIP
CHAR(9));
Table created.
C) 再定義を開始します。
SQL> EXECUTE
DBMS_REDEFINITION.START_REDEF_TABLE('SALES', 'DIST', 'DIST_INTERIM',NULL,2);
PL/SQL procedure successfully completed.
D) 仮表と実表を同期化します。同期化は、複数回行うことが可能です。
SQL> EXECUTE
DBMS_REDEFINITION.SYNC_INTERIM_TABLE('SALES', 'DIST', 'DIST_INTERIM');
PL/SQL procedure successfully completed.
SQL> EXECUTE
DBMS_REDEFINITION.SYNC_INTERIM_TABLE('SALES', 'DIST', 'DIST_INTERIM');
PL/SQL procedure successfully completed.
E) 再定義を終了します。
SQL> EXECUTE
DBMS_REDEFINITION.FINISH_REDER_TABLE('SALES', 'DIST', 'DIST_REDEF');
PL/SQL procedure successfully completed.
F)
dist 表の構造は次のとおりです。
SQL> DESC SALES.DIST
NAME
NULL?
----------------------------------------- -------D_ID
D_W_ID
D_YTD
D_TAX
D_NEXT_O_ID
D_NAME
D_CITY
D_STATE
D_ZIP
Maximum Availability Architecture
TYPE
---------------------NUMBER(2)
NUMBER(5)
NUMBER
NUMBER
NUMBER
VARCHAR2(10)
VARCHAR2(20)
CHAR(2)
CHAR(9)
16-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録E
付録 - オブジェクトの再編成とリカバリの例
16.1.2
ALTER TABLE文
文
ALTER TABLE … SET UNUSED/ ALTER TABLE ... DROP
ALTER TABLE… SET UNUSED 文を使用して、使用されていない列をレンダリングする例を示します。このような列は、
ALTER TABLE … DROP UNUSED コマンドを使用して後で表から物理的に削除できます。
A) 表を説明します。
SQL> desc dist
Name
NULL?
----------------------------------------- -------D_ID
D_W_ID
D_YTD
D_TAX
D_NEXT_O_ID
D_NAME
D_STREET_1
D_STREET_2
D_CITY
D_STATE
D_ZIP
TYPE
---------------------NUMBER(2)
NUMBER(5)
NUMBER
NUMBER
NUMBER
VARCHAR2(10)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
CHAR(2)
CHAR(9)
B) 表を変更し、使用していない列を設定します。
SQL> ALTER TABLE DIST SET UNUSED (D_STREET_1);
Table altered.
C) ‘alter table … set unused’後の表について説明します。
SQL> DESC DIST
Name
NULL?
----------------------------------------- -------D_ID
D_W_ID
D_YTD
D_TAX
D_NEXT_O_ID
D_NAME
D_STREET_2
D_CITY
D_STATE
D_ZIP
TYPE
---------------------NUMBER(2)
NUMBER(5)
NUMBER
NUMBER
NUMBER
VARCHAR2(10)
VARCHAR2(20)
VARCHAR2(20)
CHAR(2)
CHAR(9)
D) 表名、および使用していない列の数に対して USER_UNUSED_COL_TABS を確認できます。
SQL> SELECT * FROM USER_UNUSED_COL_TABS;
TABLE_NAME
COUNT
------------------------------ ---------DIST
1
Maximum Availability Architecture
16-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録E
付録 - オブジェクトの再編成とリカバリの例
E) 列を削除します。
SQL> ALTER TABLE DIST DROP UNUSED COLUMNS;
Table altered.
F)
列が削除されたことを確認します。
SQL> SELECT * FROM USER_UNUSED_COL_TABS;
no rows selected
ALTER TABLE ...DROP
表から列を削除する例を示します。
SQL> ALTER TABLE DIST DROP COLUMN D_STREET_2;
Table altered.
ALTER TABLE ...RENAME
表の列名を変更する例を示します。
SQL> ALTER TABLE DIST RENAME COLUMN D_STREET TO D_ST;
Table altered.
ALTER TABLE ...MOVE
表領域間で表を移動する例を示します。
A) 移動前の表の場所を特定します。
SQL> SELECT TABLESPACE_NAME FROM USER_TABLES WHERE TABLE_NAME = 'DIST';
TABLESPACE_NAME
-----------------------------DIST_TBS
B) DIST_TBS から DIST_TBS2 へ表を移動します。
SQL> ALTER TABLE DIST MOVE TABLESPACE DISP_TBS2
Table altered.
C) 移動後の表の場所を特定します。
SQL> SELECT TABLESPACE_NAME FROM USER_TABLES WHERR TABLE_NAME = 'DIST';
TABLESPACE_NAME
-----------------------------DIST_TBS2
Maximum Availability Architecture
16-4
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録E
付録 - オブジェクトの再編成とリカバリの例
16.2
オブジェクトのリカバリ例
この項では、オブジェクトの再編成およびリカバリ機能の使用例を示します。各機能のさらに詳しい例については、関連
する Oracle ドキュメントを参照してください。
16.2.1
フラッシュバック問合せ
この例では、ユーザー・エラーまたはアプリケーション・エラーの結果として、トランザクションで発生したロジカル・
エラーからリカバリする際のフラッシュバック問合せの使用例について示します。
INIT.ORAの設定
の設定
UNDO_MANAGEMENT=AUTO
UNDO_TABLESPACE=’UNDOTBS1’
UNDO_RETENTION=10800 # time in seconds
使用方法
SCNが既知の場合
問題の原因となるトランザクションの SCN が既知の場合は、SCN でフラッシュバック問合せを使用する方法が最も適し
ています。手順は次のとおりです。
I.
トランザクションによって直接変更された表の一覧を作成します。
II. これらの表におけるトリガーによって変更された表の一覧を作成します。
III. これらの表についてそれぞれ、次の問合せを実行します。
SQL>
CREATE TABLE T1_DIFF AS
SELECT * FROM T1
MINUS
SELECT * FROM T1 AS OF SCN 556565;
T1_DIFF の表には、SCN 556565 以降に表 T1 に対して行われた変更がすべて含まれています。これらの変更の多
くは、変更せずにそのままにしておく場合があります。この結果に基づいて、関連データをメインの表にリカバ
リおよびロールバックできます。
時間が既知の場合
問題の原因となったトランザクションのタイム・スタンプがわかっていて、SCM がわからない場合は、次のとおり実行
します。タイム・スタンプベースのフラッシュバック問合せでは、最大 5 分まで切り捨てられた時間で結果が返されます。
ここでの手順は、AS OF 句の変更を除けば、前述の手順と同様です。
I.
トランザクションによって直接変更された表の一覧を作成します。
II. これらの表におけるトリガーによって変更された表の一覧を作成します。
III. これらの表についてそれぞれ、次の問合せを実行します。
SQL>
CREATE TABLE T1_DIFF AS
SELECT * FROM T1
MINUS
SELECT * FROM T1 AS OF TIMESTAMP (TO_TIMESTAMP
('24-MAY-02 10:17:00','DD-MON-YY HH:MI:SS'));
Maximum Availability Architecture
16-5
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録E
付録 - オブジェクトの再編成とリカバリの例
T1_DIFF の表には、指定された時間（最大 5 分の間隔で切捨て）以降に T1 表に対して行われた変更がすべて含
まれています。これらの変更の多くは、変更せずにそのままにしておく場合があります。返された結果で変更が
示されていない場合は、タイム・スタンプを調整するか、またはそのときの SCN を使用して問合せを再実行で
きます。この結果に基づいて、関連データをメインの表にリカバリおよびロールバックします。
16.2.2
RMANのブロック・メディア・リカバリ
のブロック・メディア・リカバリ
この例は、RMAN のブロック・メディア・リカバリの機能を使用した、破損ブロックのリカバリについて示しています。
エラーのレポート
エラーは、アプリケーションで検出、およびアラート・ログ・ファイルで検索も可能です。通常のエントリは、次のとお
りです。
ORA-01578: ORACLE data block corrupted (file # 4, block #26)
ORA-01110: data file 4: '/dev/vx/rdsk/ha-dg/SALES_dtf04'
使用方法
次の RMAN コマンドを使用して、このブロックを修正します。
RMAN> blockrecover data file 4 block 26 from backupset;
Starting blockrecover at 07-APR-02
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=12 devtype=DISK
channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of data file 00004
channel ORA_DISK_1: restored block(s) from backup piece 1
piece handle=/rmanbackup/01dlart2_1_1 tag=TAG20020407T162610 params=NULL
channel ORA_DISK_1: block restore complete
starting media recovery
media recovery complete
Finished blockrecover at 07-APR-02
複数のブロックをリカバリする場合には、前述のコマンドに複数のデータ・ファイルおよびブロックの組合せを指定でき
ます。他の使用例は、『Oracle9i Recovery Manager リファレンス リリース 2（9.2）』を参照してください。
Maximum Availability Architecture
16-6
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録E
付録 - オブジェクトの再編成とリカバリの例
16.2.3
DBMS_REPAIRパッケージ
パッケージ
この例は、DBMS_REPAIR を使用して、オブジェクトに対して破損ブロックをスキップする方法を示しています。
他の使用例は、『Oracle9i データベース管理者ガイド、リリース 2（9.2）』の第 22 章「Detecting and Repairing Data Block
Corruption」を参照してください。次の例では、sqlplus を使用してコマンドを発行します。
A) repair table および orphan key table を作成します。これらの表は、事前の作成をお薦めします。
SQL> BEGIN
2
DBMS_REPAIR.ADMIN_TABLES
3
('REPAIR_TABLE',DBMS_REPAIR.REPAIR_TABLE,DBMS_REPAIR.CREATE_ACTION);
4
END;
5
/
PL/SQL procedure successfully completed.
SQL> BEGIN
2
DBMS_REPAIR.ADMIN_TABLES (
3
'ORPHAN_KEY_TABLE', DBMS_REPAIR.ORPHAN_TABLE,
DBMS_REPAIR.CREATE_ACTION);
4
END;
5
/
PL/SQL procedure successfully completed.
B) オブジェクト内の破損を確認するために、次の問合せを実行します。
SQL> VARIABLE NUM_CORRUPT NUMBER;
SQL> BEGIN
2
DBMS_REPAIR.CHECK_OBJECT(SCHEMA_NAME => 'SALES',
3
OBJECT_NAME => 'ORDR', CORRUPT_COUNT => :NUM_CORRUPT);
4
END;
5
/
PL/SQL procedure successfully completed.
SQL> PRINT
NUM_CORRUPT
----------1
C) 破損の詳細を確認するには、次の問合せを実行します。
SQL> SELECT
2
OBJECT_NAME, BLOCK_ID, MARKED_CORRUPT, CORRUPT_DESCRIPTION,
3
REPAIR_DESCRIPTION, CHECK_TIMESTAMP
4
FROM REPAIR_TABLE
5
ORDER BY CHECK_TIMESTAMP
6
/
D) 前述のオブジェクトを修復するには、次の問合せを実行します。
SQL> VARIABLE FIX_COUNT NUMBER;
SQL> BEGIN
2
DBMS_REPAIR.FIX_CORRUPT_BLOCKS
3
(SCHEMA_NAME => 'SALES',OBJECT_NAME => 'ORDR',
4
FIX_COUNT => :FIX_COUNT);
5
END;
6
/
PL/SQL procedure successfully completed.
SQL> PRINT
FIX_CORRUPT
----------1
Maximum Availability Architecture
16-7
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録E
付録 - オブジェクトの再編成とリカバリの例
E) この表に対して破損ブロックをスキップするには、次の問合せを実行します。
SQL> BEGIN
2
DBMS_REPAIR.SKIP_CORRUPT_BLOCKS(SCHEMA_NAME => 'SALES',
3
OBJECT_NAME => 'ORDR', OBJECT_TYPE => DBMS_REPAIR.TABLE_OBJECT,
4
FLAGS => DBMS_REPAIR.SKIP_FLAG );
5
END;
6
/
PL/SQL procedure successfully completed.
前述の内容を確認するには、次の問合せを実行します。
SQL> SELECT SKIP_CORRUPT FROM DBA_TABLES WHERE TABLE_NAME = ‘SALES’ ;
SKIP_COR
-------ENABLED
16.2.4
DBVERIFYユーティリティ
ユーティリティ
この例は、DBVERIFY ユーティリティを使用して、データ・ファイル・レベルで破損ブロックを検出する方法について
示しています。セグメントに対してほとんど読込みモードでアクセスする場合を除いては、MAA でセグメント・レベル
の検証を行うことは推奨していません。
$ dbv FILE=/dev/vx/rdsk/ha-dg/SALES_dtf01 BLOCKSIZE=8192
DBVERIFY: Release 9.2.0.1.0 - Production on Fri May 24 14:14:53 2002
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
DEVERIFY – Verification starting : FILE = /dev/vx/rdsk/ha-dg/SALES_dtf01
DBVERIFY - Verification complete
Total Pages Examined
: 262016
Total Pages Processed (Data) : 120682
Total Pages Failing
(Data) : 0
Total Pages Processed (Index) : 3884
Total Pages Failing
(Index) : 0
Total Pages Processed (Other) : 54
Total Pages Processed (Seg)
: 0
Total Pages Failing
(Seg)
: 0
Total Pages Empty
: 137396
Total Pages Marked Corrupt
: 0
Total Pages Influx
: 0
dbv で検出される破損ブロックの例は、次のようになります。
$ dbv FILE=/dev/vx/rdsk/ha-dg/SALES_dtf02 BLOCKSIZE=8192
DBVERIFY: Release 9.2.0.1.0 - Production on Fri May 24 14:34:53 2002
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
DEVERIFY – Verification starting : FILE = /dev/vx/rdsk/ha-dg/SALES_dtf02
Page 8 is marked corrupt
***
Corrupt block relative dba: 0x01000008 (file 4, block 8)
Bad header found during dbv:
Data in bad block –
type: 48 format: 0 rdba: 0x30303030
last change scn: 0x3030.30303030 seq: 0x30 flg: 0x30
consistency value in tail: 0x30303030
check value in block header: 0x3030, block checksum disabled
sparel: 0x30, spare2: 0x30, spare3: 0x3030
***
Maximum Availability Architecture
16-8
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録E
付録 - オブジェクトの再編成とリカバリの例
DBVERIFY - Verification complete
Total Pages Examined
: 12800
Total Pages Processed (Data) : 279
Total Pages Failing
(Data) : 0
Total Pages Processed (Index) : 0
Total Pages Failing
(Index) : 0
Total Pages Processed (Other) : 8
Total Pages Processed (Seg)
: 0
Total Pages Failing
(Seg)
: 0
Total Pages Empty
: 12511
Total Pages Marked Corrupt
: 1
Total Pages Influx
: 0
ブロックとファイルの番号を使用して、問題点をさらに詳しく調べて、修正することができます。
16.2.5
RMANのブロック検証
のブロック検証
RMAN を使用して、データベースで使用されているブロックを検証できます。次のコマンドはバックアップの検証を実
行して、V$DATABASE_BLOCK_CORRUPTION にデータを移入します。
RMAN> BACKUP VALIDATE DATABASE;
問題が検出された場合は、次の問合せで次のような行が示されます。
SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
FILE#
BLOCK#
BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ --------4
25
1
0 FRACTURED
4
27
1
0 FRACTURED
次のコマンドを使用して、これらのブロックをリカバリできます。
RMAN> BLOCKRECOVER CORRUPTION LIST;
Starting blockrecover at 07-APR-02
using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=12 devtype=DISK
channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of data file 00004
channel ORA_DISK_1: restored block(s) from backup piece 1
piece handle=/rmanbackup/04dlaulu_1_1 tag=TAG20020407T170254 params=NULL
channel ORA_DISK_1: block restore complete
channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of data file 00004
channel ORA_DISK_1: restored block(s) from backup piece 1
piece handle=/rmanbackup/01dlart2_1_1 tag=TAG20020407T162610 params=NULL
channel ORA_DISK_1: block restore complete
starting media recovery
media recovery complete
Finished blockrecover at 07-APR-02
Maximum Availability Architecture
16-9
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
17. 付録F
）
付録 - サーバー・パラメータ・ファイル（SPFILE）
サーバー・パラメータ・ファイル（
RAC 環境では、サーバー・パラメータ・ファイル（SPFILE）を使用して、1 つの一括管理されたパラメータ・ファイル
で、RAC データベースに含まれているすべてのインスタンスに関連するデータベースの初期化パラメータを、すべての
保持できます。これによって、データベース・パラメータを管理するうえで、シンプルで一貫性のある堅牢な環境が実現
されます。
17.1
SPFILEの作成
の作成
MAA では、SPFILE を共有ロジカル・ボリュームに定義する必要があります。これは制御ファイルおよびデータ・ファイ
ルと類似していますが、SPFILE のサイズは数メガバイト程度です。RAC データベースのパラメータ・ファイルは、オプ
ションのインスタンス・フィールドを必要とします。これは、インスタンス特有のパラメータに対するパラメータに関連
付けができます。Sun Solaris UNIX プラットフォームに対して Veritas Volume Manager を使用した手順の例を次に示しま
す。
•
共有ボリュームを作成する（RAW デバイス）
•
テキスト初期化ファイルを作成する
•
テキスト初期化ファイルから SPFILE を作成する
•
SPFILE に対するシンボリック・リンクを作成する
17.1.1
共有ボリュームを作成する（RAWデバイス）
デバイス）
共有ボリュームを作成する（
このボリュームは、クラスタ内のすべてのインスタンスに対してアクセス可能で、データベース所有者のアクセス権を持
つ必要があります。
次に例を示します。
/usr/sbin/vxassist -g ha-dg -U gen make SALES_spfile 2m layout=mirrored
stripeunit=256k nstripe=4 user=oracle group=dba mode=660
この例では、RAW デバイスの/dev/vx/rdsk/ha-dg/SALES_spfile が作成されます。
17.1.2
テキスト初期化ファイルを作成する
SPFILE では、初期化パラメータ・ファイル IFILE オプションを使用できません。IFILE オプションは、SPFILE に必須で
はありません。グローバルな（すべてのインスタンスで同じ）パラメータに対して、以前に IFLE オプションを使用して
いた場合は、ファイルを統合することができます。テキスト・ファイルを作成する場合は、いずれのグローバル・パラメ
ータでもライン・プリフィックスは必要ありませんが、*.log_archive_start=TRUE のように "*."のライン・プリフィック
スを定義できます。thread などのインスタンス特有のパラメータでは、ORACLE_SID のライン・プリフィックスが必要で
す。たとえば、SALES1.thread=1 のように指定し、ここで ORACLE_SID=SID1 となります。次に、
/mnt/app/oracle/SALES/pfile/initSALES.ora という名前のテキスト初期化パラメータ・ファイルの例を示します。
Maximum Availability Architecture
17-1
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録F - サーバー・パラメータ・ファイル（SPFILE）
）
サーバー・パラメータ・ファイル（
*.fal_server='SALES_SEC'
*.fal_client='SALES_PRIM'
SALES1.thread=1
SALES2.thread=2
SALES1.undo_tablespace='rbs01' <can you use more than 1 tbs>
SALES2.undo_tablespace='rbs02'
SALES1.instance_name='SALES1'
SALES2.instance_name='SALES2'
SALES1.instance_number=1
SALES2.instance_number=2
log_archive_start=TURE
"fal_"の行には"*."は必要ありません。"log_archive_start"の行には、ライン・プリフィックス"*"も定義できます。
17.1.3
テキスト初期化ファイルからSPFILEを作成する
を作成する
テキスト初期化ファイルから
事前に作成した共有ボリュームとテキスト初期化ファイルを使用して、データベースの稼働中または停止中のいずれの場
合でも、SQL*Plus の環境からバイナリ SPFILE を作成できます。
次に例を示します。
SQL> create spfile='/dev/vx/rdsk/ha-dg/SALES_spfile’ from
2 pfile='/mnt/app/oracle/admin/SALES/pfile/initSALES.ora';
File created.
17.1.4
SPFILEに対するシンボリック・リンクを作成する
に対するシンボリック・リンクを作成する
共有ボリュームにはすでに SPFILE が作成されているため、データベースの起動は、シンボリック・リンクの作成によっ
て簡潔に行うことができます。このリンクの作成では、デフォルトのサーバー・パラメータ・ファイル
spfile$ORACLE_SID.ora を使用します。UNIX の場合は、サーバー・パラメータ・ファイルの場所（ディレクトリ）は、
$ORACLE_HOME/dbs になります。Windows 環境では、ディレクトリは$ORACLE_HOME＼database になります。それぞ
れのデータベース・インスタンスに対してデフォルト場所のディレクトリで次のコマンドを実行します。
ln –s <shared volume file spec> spfile$ORACLE_SID.ora
SALES1 と SALES2 の 2 つのインスタンスを持つデータベースに対しては、$ORACLE_HOME/dbs ディレクトリで次のコ
マンドを実行します。
SALES1 のインスタンスでは、次のコマンドを実行します。
ln –s /dev/vx/rdsk/ha-dg/SALES_spfile spfileSALES1.ora
SALES2 のインスタンスでは、次のコマンドを実行します。
ln –s /dev/vx/rdsk/ha-dg/SALES_spfile spfileSALES2.ora
プラットフォームでシンボリック・リンクまたはショートカットをサポートしていない場合は、かわりに、次の行が含ま
れている PFILE（デフォルトまたは非デフォルト）を使用できます。
SPFILE=/dev/vx/rdsk/ha-dg/SALES_spfile
セカンダリ・サイトのデータベースで SPFILE を作成するには、同じ手順を続行します。
Maximum Availability Architecture
17-2
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
付録F - サーバー・パラメータ・ファイル（SPFILE）
）
サーバー・パラメータ・ファイル（
17.2
SPFILEの管理
の管理
SPFILE は"ALTER SYSTEM …"コマンドで管理できます（詳細は、『Oracle9i データベース管理者ガイド』を参照してく
ださい）。"ALTER SYSTEM"コマンドを介してデータベース・パラメータが正常に変更された場合は、データベース・
アラート・ログへ記録されます。ALTER SYSTEM コマンドを使用したデータベース・パラメータの変更では、表 17-1
のような SCOPE オプションを使用できます。
表17-1: SCOPEオプションの機能
オプションの機能
SCOPE オプション
機能
SPFILE
変更はサーバー・パラメータ・ファイルのみに適用されます。これは、静的パラメータが
許可された唯一の SCOPE 仕様です。
Memory
変更は、メモリーのみに適用されますが、サーバー・パラメータ・ファイルが更新されな
いため、永続的ではありません。静的パラメータは許可されません。
SPFILE とメモリー
変更はサーバー・パラメータ・ファイルとメモリーに適用されます。
初期化パラメータには、Oracle インスタンスの停止および開始のみに変更できるものがあります。これらのパラメータは
静的パラメータと呼ばれます。静的パラメータの変更は、"SCOPE=SPFILE"オプションを使用して SPFILE に記録されま
す。SPFILE でデータベースが再起動されるまで、SPFILE のみの変更は変更に反映されません。
インスタンス特有のパラメータでは、SID の指名子を使用します。
ALTER SYSTEM SET undo_retention=600 scope=memory SID=’SALES1’;
SPFILE の設定は、V$SPPARAMETER ビューで確認できます。SCOPE=SPFILE または SCOPE=MEMORY によってパラメ
ータの変更が行われた場合は、V$SPPARAMETER ビューの値が V$PARAMETER ビューの値と異なっている可能性があ
ります。また、インスタンス特有の SPFILE の設定は次の問合せで参照できます。
SELECT SID,NAME,VALUE
FROM V$SPPARAMETER
WHERE SID <>’*’
ORDER BY SID;
"ALTER SYSTEM SET"コマンドでデフォルトを使用するのではなく、コマンド・オプション指定してください。
つまり、"ALTER SYSTEM SET"コマンドでは、常に SCOPE および SID を指定することを推奨します。
Maximum Availability Architecture
17-3
Oracle Corporation発行「Maximum Availability Architecture」の翻訳版です｡
Maximum Availability Architecture
2005 年 2 月
著書: High Availability systems Group
寄稿者: Andrew Babb, Pradeep Bhat, Ray Dutcher, Susan Kornberg, Ashish Prabhu, Lawrence To, Doug Utzig, Jim Viscusi, Shari Yamaguchi
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
海外からのお問合せ窓口:
電話: +1.650.506.7000
ファックス: +1.650.506.7200
www.oracle.com
オラクル社は、インターネット上での活動を強化するソフトウェアを提供します。
Oracle はオラクル社の登録商標です。
このガイドで使用されているさまざまな製品名およびサービス名には、オラクル社の商標が含まれています。
その他のすべての製品名およびサービス名は、各社の商標です。
Copyright © 2002, 2003,2004, 2005 Oracle Corporation
All rights reserved.

Slide 1

新生銀行グループ7社の財務会計・管理会計

MIMIX® AvailabilityTM

スライド タイトルなし

www.tintri.co.jp

Oracle Database Appliance トータルサービス

Arcserve Replication / High Availability のライセンスキー登録方法

四日市港管理組合 財務会計システム サーバ機器等リース（保守込み