Oracle® Fail Safe 概要および管理ガイド

リリース4.1 for Microsoft Windows

B72446-01(原本部品番号:E24699-01)

目次

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

1 Oracle Fail Safeの基礎知識

- 1.1 Oracle Fail Safeの概要

- 1.2 Oracle Fail Safeの利点

- 1.2.1 高い可用性を備えたリソースおよびアプリケーション

- 1.2.2 使いやすさ

- 1.2.3 製品の利用しやすさ

- 1.2.4 アプリケーションとの統合のしやすさ

- 1.3 典型的なOracle Fail Safe構成の概要

- 1.4 Oracle Fail Safeソリューションのデプロイ

2 クラスタの概念

- 2.1 クラスタ・テクノロジ

- 2.1.1 高可用性を提供するクラスタについて

- 2.1.2 システムレベル構成について

- 2.1.3 ディスクレベル構成について

- 2.2 リソース、グループおよび高可用性

- 2.2.1 リソースについて

- 2.2.2 グループについて

- 2.2.3 リソースの依存性について

- 2.2.4 リソース・タイプの概要

- 2.3 グループ、仮想アドレスおよび仮想サーバー

- 2.4 仮想アドレスへのIPアドレス割当て

- 2.5 クラスタ・グループとクラスタ別名

- 2.6 フェイルオーバーについて

- 2.6.1 計画外フェイルオーバー

- 2.6.1.1 リソース障害による計画外フェイルオーバー

- 2.6.1.2 ノードの障害または使用不可状態による計画外フェイルオーバー

- 2.6.2 グループの計画的フェイルオーバー

- 2.6.3 フェイルオーバーに影響するグループおよびリソースのポリシー

- 2.6.4 リソース障害の検出

- 2.6.5 リソース再起動ポリシーについて

- 2.6.6 リソースのフェイルオーバー・ポリシーについて

- 2.6.7 リソースの「可能所有者ノード」リストについて

- 2.6.8 グループのフェイルオーバー・ポリシーについて

- 2.6.9 リソース再起動ポリシーおよびグループ・フェイルオーバー・ポリシーによるフェイルオーバーへの影響

- 2.6.10 グループ・フェイルオーバーと「優先所有者ノード」リストについて

- 2.6.11 グループのフェイルオーバー・ノードの決定

- 2.7 フェイルバックについて

- 2.7.1 グループ・フェイルバックと「優先所有者ノード」リスト

- 2.7.2 フェイルオーバー後のクライアントの再接続

3 Oracle Fail Safeソリューションの設計

- 3.1 構成のカスタマイズ

- 3.1.1 アクティブ/パッシブ構成

- 3.1.2 アクティブ/アクティブ構成

- 3.2 クライアントとアプリケーションの統合

4 高い可用性を実現するための管理

- 4.1 フェイルオーバーのリソースの構成

- 4.2 ウィザード入力項目のOracle Fail Safeでの処理

- 4.3 クラスタ・セキュリティの管理

- 4.3.1 Oracle Fail Safe

- 4.3.1.1 Oracle Fail Safe Serverアカウントの変更

- 4.3.2 Oracle Fail Safe Manager

- 4.4 スタンドアロン・リソースの検出

- 4.5 リソース名の変更

- 4.6 複数Oracleホーム環境でのOracle Fail Safeの使用方法

- 4.7 複数仮想アドレスを使用する構成

- 4.8 既存クラスタへのノードの追加

5 FSCMDコマンドライン・インタフェース

- FSCMD

6 PowerShellコマンド

- 6.1 開始

- 6.2 共通パラメータについて

- 6.3 スクリプトのOracle Fail Safeコマンドレットの使用

- 6.4 FSCMD等価コマンドレット

- 6.5 例

7 アクションの検証

- 7.1 操作の検証

- 7.1.1 クラスタの検証

- 7.1.2 Oracleリソースの構成の検証

- 7.1.3 スタンドアロン・データベースの検証

- 7.2 クラスタのダンプ

- 7.3 その他のトラブルシューティング情報の入手

8 可用性および障害耐久力を高めるためのシングルインスタンス・データベースの構成

- 8.1 スタンドアロン・シングルインスタンス・データベースの検出

- 8.2 スタンドアロン・シングルインスタンス・データベースのためのOracle Net構成

- 8.2.1 DBCAにより作成したデータベースのためのOracle Net構成の更新

- 8.2.2 リスナーの定義

- 8.2.3 SIDリスト・エントリおよびOracle Databaseソフトウェアへのアップグレード

- 8.2.4 複数のリスナーを伴うノードでのOracle Netの構成

- 8.2.5 共有サーバーの構成とスタンドアロン・データベース

- 8.3 シングルインスタンスOracle Databaseのグループへの追加

- 8.3.1 構成前に

- 8.3.2 構成手順

- 8.3.3 Oracle Databaseの構成データ

- 8.3.3.1 ノードの選択

- 8.3.3.2 仮想アドレスの選択

- 8.3.3.3 データベース・パラメータの識別

- 8.3.3.4 データベースの検証

- 8.4 Oracle Netリスナー・リソースの作成および構成について

- 8.4.1 専用サーバー・モードでの共有ソケットの使用方法

- 8.4.2 可用性の高いシングルインスタンス・データベースへのクライアント接続

- 8.4.3 データベースをグループに追加した後のOracle Net構成の更新

- 8.4.3.1 Oracle Fail Safeにより行われるtnsnames.oraファイルの更新内容

- 8.4.3.2 Oracle Fail Safeにより行われるlistener.oraファイルの更新内容

- 8.4.3.3 Oracle Fail Safeにより行われるsqlnet.oraファイルの更新内容

- 8.4.4 可用性が高まるように構成されたデータベースでの外部プロシージャの使用方法

- 8.4.5 共有サーバーを使用するデータベースのサポート

- 8.4.5.1 データベース用の共有サーバー

- 8.5 シングルインスタンス・データベースのセキュリティ要件

- 8.5.1 クラスタ・ノード上のパスワード・ファイルの同期化

- 8.5.2 SYSアカウントのパスワードの変更

- 8.5.3 Oracle Database Upgrade Assistantを使用したフェイルセーフ・データベースのアップグレード

- 8.6 シングルインスタンス・データベース・リカバリの最適化

- 8.7 シングルインスタンス・フェイルセーフ・データベースに対する管理作業の実行

- 8.8 データベース・ホーム

- 8.9 透過的アプリケーション・フェイルオーバー(TAF)の構成

- 8.10 データベースに関連するエラー処理と問題のトラブルシューティング

- 8.10.1 データベースをオンライン化する際に発生するエラーの処理

- 8.10.2 問題のトラブルシューティング

- 8.10.3 データベースをグループに追加する際の問題

- 8.10.4 グループのオンライン化の問題

- 8.10.5 プロセスが集中している操作の際のグループ・フェイルオーバー

- 8.10.6 データベース認証の概要

- 8.10.7 仮想サーバーの構成で検出される問題

- 8.10.7.1 仮想アドレスの構成で発生する問題

- 8.10.7.2 リスナー作成時の問題

- 8.10.7.3 アーカイブされたlistener.oraまたはtnsnames.oraファイル

- 8.10.7.4 ロールバック・ファイル

- 8.10.8 セキュリティ・アクセスおよび認証の問題

- 8.10.9 クライアントがデータベースにアクセスできない

- 8.11 Oracle Data Guardによる可用性の高いデータベースの使用

9 可用性を高めるためのOracle Management Agentの構成

- 9.1 可用性を高めるための前提条件

- 9.2 可用性を高めるためのOracle Management Agentの構成手順

- 9.3 Oracle Management Agentのグループからの削除

A Oracleサポート・サービスへの連絡

- A.1 問題の報告

- A.2 Oracleソフトウェアのバージョンの確認

- A.3 エラー情報の表示

- A.4 Oracle Fail Safeの問題のトレース

- A.5 トレース・ファイルとアラート・ファイルの保管

用語集

索引

図一覧

- 1-1 MicrosoftクラスタでのOracle Fail Safeによるフェイルオーバー

- 1-2 Oracle Fail Safe Manager

- 1-3 Oracle Fail Safe Managerのメニューと内容

- 1-4 Oracle Fail Safeによって構成されるハードウェアおよびソフトウェア・コンポーネント

- 2-1 Microsoftクラスタ・システム

- 2-2 シェアード・ナッシング構成

- 2-3 グループの設計

- 2-4 仮想サーバーを介したクラスタ・リソースへのアクセス

- 2-5 ツリーにクラスタを追加」ダイアログ・ボックスの「クラスタ別名

- 2-6 リソースのフェイルオーバー

- 2-7 ノードのフェイルオーバー

- 2-8 グループの「フェイルバック」ポリシー・プロパティ・ページ

- 2-9 リソースの「ポリシー」プロパティ・ページ

- 2-10 「優先所有者ノード」プロパティ・ページ

- 2-11 「優先所有者ノード」プロパティ・ページ

- 2-12 「可能所有者ノード」プロパティ・ページ

- 2-13 フェイルオーバーしきい値とフェイルオーバー期間の関係を示す時間軸

- 2-14 グループの「フェイルバック」ポリシー・プロパティ・ページ

- 3-1 2ノードのアクティブ/パッシブ(スタンバイ)構成

- 3-2 4ノードのアクティブ/パッシブ(スタンバイ)構成

- 3-3 アクティブ/アクティブ構成

- 4-1 Oracle Fail Safe環境内の仮想サーバーとアドレッシング

- 4-2 Oracle Fail Safe Server資格証明

- 4-3 Oracle Fail Safe ServerのWindowsセキュリティ設定

- 7-1 クラスタを検証中の進行状況ウィンドウ

- 7-2 グループを検証中の進行状況ウィンドウ

- 7-3 スタンドアロン・データベースを検証中の進行状況ウィンドウ

- 7-4 クラスタ情報をダンプ中の進行状況ウィンドウ

- 8-1 全ノードが使用可能な場合のリソースをグループに追加ウィザード・ページ

- 8-2 使用できないノードがある場合のリソースをグループに追加ウィザード・ページ

- 8-3 「リソースをグループに追加」の仮想ホスト・ウィザード・ページ

- 8-4 データベース・パラメータ・ウィザード・ページ

- 8-5 データベースの認証ウィザード・ページ

- 9-1 リソースをグループに追加ウィザード - 「グループ」ページ

- 9-2 リソースをグループに追加ウィザード - 「Management Agent」の「ディスク」ページ

- 9-3 リソースをグループに追加ウィザード - 「Management Agent」の「ホスト」ページ

- 9-4 リソースをグループに追加ウィザード - 「Management Agent」の「パスワード」ページ

- 9-5 リソースをグループに追加ウィザード - 「Management Agent」の「確認」ページ

表一覧

- 2-1 Test_Groupグループ内のリソースの可能所有者の例

- 4-1 許可と権限

- 8-1 データベースを構成する手順

- A-1  クラスタのサーバー・ノードが使用するトレース・フラグ

Oracle® Fail Safe

概要および管理ガイド

リリース4.1 for Microsoft Windows

B72446-01(原本部品番号:E24699-01)

2012年12月

Oracle Fail Safe概要および管理ガイド リリース4.1 for Microsoft Windows

B72446-01

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

原本著者: Ashmita Bose

原本協力者: Janelle Simmons

協力者: Paul Mead

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

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

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

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

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

はじめに

このマニュアルでは、Microsoftクラスタ・システム上で稼働しているOracle Fail Safeを使用して、次のものの可用性が高まるように構成する方法を説明します。

- Oracleシングルインスタンス・データベース

- Windows汎用サービスとしてインストールされたアプリケーション

- Oracle Management Agent

- Oracle Application Serverコンポーネント

対象読者

このマニュアルは、Oracle Fail Safeによって、Microsoftクラスタ・システム上で稼働するソフトウェア・コンポーネントの停止時間を最短にする方法に関心がある方を対象としています。

読者は、フェイルオーバー・クラスタ、Oracle Netネットワーキング、および高い可用性を実現する他のアプリケーションに精通していることが必要です。

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

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

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

Oracle Fail Safeの詳細は、次の資料を参照してください。

- ソフトウェアの更新、オンライン・ドキュメントへのアクセス、およびその他のリリース固有の情報の詳細は、『Oracle Fail Safeリリース・ノートfor Microsoft Windows』を参照してください。

- インストール、削除およびアップグレードの手順については、『Oracle Fail Safeインストレーション・ガイドfor Microsoft Windows』を参照してください。

- オンライン・ヘルプは、Oracle Fail Safe Managerで提供されているオンライン・ヘルプの項目を参照してください。オンライン・ヘルプのトピックにアクセスするには、Oracle Fail Safe Managerの「ヘルプ」メニュー・バーにある「ヘルプ・トピック」を選択してください。

- Oracle Call Interfaceの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

- ODBCの詳細は、Microsoft ODBCのマニュアルを参照してください。

その他の関連製品の詳細は、各製品のマニュアルを参照してください。

表記規則

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

規則

意味

太字

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

イタリック

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

固定幅フォント

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

1 Oracle Fail Safeの基礎知識

ビジネスにおいて、24時間365日利用できる製品やサービスがますます求められるようになっています。100%の可用性を保証できるソリューションはありませんが、Oracle Fail Safeを使用すると、Microsoftクラスタ上で稼働してWindowsフェイルオーバー・クラスタで構成されているOracle Databaseやその他のアプリケーションの停止時間を、最小限に抑えることが可能になります。

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

- Oracle Fail Safeの概要

- Oracle Fail Safeの利点

- 典型的なOracle Fail Safe構成の概要

- Oracle Fail Safeソリューションのデプロイ

1.1 Oracle Fail Safeの概要

Oracle Fail Safeはユーザーフレンドリなソフトウェアで、Windowsフェイルオーバー・クラスタとともに、Microsoftクラスタ上で高い可用性を実現するビジネス・ソリューションです。クラスタは、ネットワーク・ユーザーからは可用性の高い単一システムのように見える2つ以上のMicrosoft Windowsシステムで構成されます。クラスタ内の各システムをクラスタ・ノードと呼びます。

Oracle Fail SafeはMicrosoft Windowsフェイルオーバー・クラスタ・ソフトウェアとともに、クラスタ上で実行されるアプリケーションおよびシングルインスタンス・データベースの高い可用性を実現します。あるクラスタ・ノードに障害が発生した場合、Microsoft Windowsフェイルオーバー・クラスタ・マネージャを使用して構成したパラメータに基づき、クラスタ・ソフトウェアがその作業負荷を正常に機能しているノードに移します。この操作をフェイルオーバーと呼びます。

Oracle Fail Safeによって、シングルインスタンスOracle Database、およびMicrosoft Windowsサービスとして構成可能なほとんどすべてのアプリケーションの停止時間を短縮できます。

Oracle Fail SafeはOracle Fail Safe ServerとOracle Fail Safe Managerから構成されます。

- Oracle Fail Safe ServerはMicrosoft Windowsフェイルオーバー・クラスタとともに、可用性を高めるように構成されたリソースが計画的に、また予想外に停止したときの高速自動フェイルオーバーを構成します。これらのリソースには、Oracle Databaseまたはその他のMicrosoft Windowsサービス(これらが依存するソフトウェアおよびハードウェアを含む)があります。また、Oracle Fail Safeは障害が発生したソフトウェア・リソースの再起動を試行できるため、あるクラスタ・ノードから別のノードへのフェイルオーバーが不要になることもあります。

注意:
以前のリリースでは、Oracle Fail Safe ServerはOracle Services for MSCSと呼ばれていました。

- Oracle Fail Safe Managerには、クラスタ・リソースを構成し管理するためのユーザーフレンドリなインタフェースとウィザード、さらに問題を診断するためのトラブルシューティング・ツールが用意されています。

これらのコンポーネントをともに使用することで、高い可用性を備えたデータベース、アプリケーションおよびインターネット・ビジネス・ソリューションを速やかにデプロイできます。

1.2 Oracle Fail Safeの利点

Oracle Fail Safeには、次の項で説明する主な利点があります。

- 高い可用性を備えたリソースおよびアプリケーション

- 使いやすさ

- 製品のアクセシビリティ

- アプリケーションとの統合のしやすさ

1.2.1 高い可用性を備えたリソースおよびアプリケーション

Oracle Fail SafeはMicrosoft Windowsフェイルオーバー・クラスタとともに、ハードウェア・リソースとソフトウェア・リソースを両方の可用性が高くなるように構成します。構成した後、クラスタの複数のノードが単一の仮想サーバーとしてエンド・ユーザーおよびクライアントに表示されます。エンド・ユーザーおよびクライアント・アプリケーションは、基礎となるクラスタの知識を必要とせずにく仮想アドレスと呼ばれる単一の固定ネットワーク・アドレスに接続します。クラスタ内のあるノードが使用不可になった場合、Microsoft Windowsフェイルオーバー・クラスタは障害が発生したノードの作業負荷(およびクライアントの要求)を他のノードに移します。

例として、図1-1の左側に、2つのノードからなるクラスタ構成を示します。ここでは両方のノードが使用可能であり、トランザクションが能動的に処理されています。表面的には、この構成は2つの独立したサーバーの設定と同じように見えますが、共有ストレージ・インターコネクトによってディスクが両方のノードに物理的に接続されるようにストレージ・サブシステムが構成されている点が異なります。同じディスクに物理的に2つのノードが接続されますが、Microsoft Windowsフェイルオーバー・クラスタにより、各ディスクをある時点で所有しアクセスできるノードは必ずどちらか1つのノードとなります。

図1-1の右半分に、1つのノードでハードウェアまたはソフトウェアが使用不可能になったときに、その作業負荷が管理者の介入なしで正常に機能しているノードに自動的に移動(フェイルオーバー)され、再起動される仕組みを示しています。フェイルオーバー中、クラスタ・ディスクの所有権は障害が発生したサーバー(ノードA)から解放され、正常に機能しているサーバー(ノードB)がこの所有権を獲得します。シングルインスタンスOracle DatabaseがノードAで稼働していた場合、Oracle Fail SafeによってノードBのデータベース・インスタンスが再起動されます。クライアントは、ノードAがホスト・サーバーであったときにデータベースへのアクセスに使用したのと同じ仮想アドレスを使用し、ノードBを介してデータベースにアクセスします。

図1-1 MicrosoftクラスタでのOracle Fail Safeによるフェイルオーバー

「図1-1 MicrosoftクラスタでのOracle Fail Safeによるフェイルオーバー」の説明

1.2.2 使いやすさ

クラスタ内で動作するソフトウェアおよびその依存コンポーネント(たとえば、ディスク、IPアドレス、ネットワーク)の構成作業には、数多くのハードウェア・コンポーネントおよびソフトウェア・コンポーネントが関係しているため、複雑なプロセスになることがあります。対照的に、Oracle Fail Safeはインストール、管理および使用が簡単にできるように設計されており、クラスタ内のソフトウェアの構成が簡素化されています。

インストール: Oracle Universal Installerを使用して、Oracle Fail Safeを対話モードまたはサイレント・モードでインストールします。サイレント・モードでのインストールの場合、レスポンス・ファイルを使用してOracle Universal Installerへの入力を行い、ソフトウェアをインストールできます。また、オペレーティング・システムおよびアプリケーション・ソフトウェアのローリング・アップグレードを実行します。1つのシステムがローリング・アップグレードによってアップグレードされている間、もう1つのクラスタ・ノードが継続してクラスタの作業負荷のホストとなることが可能になり、停止時間が最短になります。詳細は、『Oracle Fail Safeインストレーション・ガイドfor Microsoft Windows』を参照してください。

管理および使用: Oracle Fail Safe Managerには、クラスタ上のアプリケーションとデータベースを設定、構成および管理するためのユーザーフレンドリなインタフェースが用意されています。Oracle Fail Safe Managerには、構成手順を自動化し、その構成をクラスタ・ノード間で矛盾なくレプリケートするウィザードもあります。

Oracle Fail Safe Managerには、次のものが含まれます。

- 情報を効率的に検索できるように同じデータの複数のビューが表示された、オブジェクトのツリー・ビュー

- ノード間のリソースを移動した作業負荷のバランス調整など、リソース構成を自動化および簡略化するウィザード

- 構成の前後に一般的な構成の問題を自動的に診断して修正する、統合検証ツール・ファミリ

- HTML形式やPDF形式で使用可能なチュートリアル、ヘルプおよびマニュアルなどのオンライン・マニュアル

- バッチ・プログラムやスクリプトからのクラスタ管理に使用するコマンドライン・インタフェース(PowerShell)

図1-2に、Oracle Fail Safe Managerのウィンドウを示します。左側のペインに、Microsoft Windowsフェイルオーバー・クラスタ・マネージャおよびOracle Fail Safe Managerを示すツリー・ビューが表示されます。Oracle Fail Safe Managerには、Oracleリソースおよびグループ(グループは、サービスまたはアプリケーション、あるいはクラスタ化されたロールと呼ばれることもあります)を含むクラスタがあります。右側のペインに、Oracleリソースおよび使用可能なOracleリソースと関連付けられたアクションが表示されます。「アクション」メニューの上部に表示されているアクションは、左側のツリー・ビュー・ペインで現在選択されている項目と関連しています。一方、「アクション」メニューの下部に表示されているアクションは、中央のペインで選択したリスト・アイテム(存在する場合)に関連しています。

図1-2 Oracle Fail Safe Manager

「図1-2 Oracle Fail Safe Manager」の説明

図1-3に、Oracle Fail Safeのメニューおよび各メニュー内のアイテムを示します。

図1-3 Oracle Fail Safe Managerのメニューと内容

「図1-3 Oracle Fail Safe Managerのメニューと内容」の説明

1.2.3 製品の利用しやすさ

Oracle Fail Safeには、PowerShellコマンドレット・コマンドライン・インタフェースとOracle Fail Safe Manager GUIの2つのユーザー・インタフェースが備わっています。ただし、Oracle Fail Safe Manager GUIのほうが広範に使用されます。Oracle Fail Safe Manager GUIは、次の3つのパネルを表示します。

- 左側パネルのナビゲーション・ツリー

- 選択したツリー・ビュー・アイテムを表す中央のパネル

- 「アクション」メニュー・リストの上部にある選択したツリー・ビューのアクションおよび「アクション」メニュー・リストの下部にある中央のパネルから選択される選択したリスト・アイテム(存在する場合)のアクションを示す右側のパネル。

複数の手順が必要な操作(グループへのリソースの追加など)をユーザーが選択すると、ウィザード・ページが表示されます。

MMCのアクセシビリティ機能の詳細は、MMC 3.0のアクセシビリティに関するMicrosoft管理コンソール(MMC)・ヘルプ・トピックを参照してください。

1.2.4 アプリケーションとの統合のしやすさ

Oracle Fail Safeによって構成されたデータベースまたはその他のアプリケーションにアクセスするよう既存のアプリケーションを構成するには、変更はほとんど必要ありません。アプリケーションは常に同じ仮想アドレスにあるクラスタ・リソースにアクセスするため、フェイルオーバーを短時間のノードの再起動として扱います。

フェイルオーバーの発生後、データベース・クライアントまたはユーザーは再接続して、まだ実行されていないトランザクション(インスタンスのリカバリ中にロールバックされたデータベース・トランザクションなど)があればそれを再実行する必要があります。OCI(Oracle ODBCドライバを使用するODBCクライアントを含む)によって開発されたアプリケーションでは、フェイルオーバー後の自動再接続を利用できます。詳細は、8.9項を参照してください。

1.3 典型的なOracle Fail Safe構成の概要

Oracle Fail Safeのソリューションは、Microsoft社によって認定されたすべてのWindowsクラスタにデプロイされ、Microsoft Windowsフェイルオーバー・クラスタを使用して構成できます。

多くのクラスタの構成はほとんど同じで、ストレージ・インターコネクトの選択(SCSI、ファイバ・チャネルまたはSAN)と、クラスタ・ノード間のアプリケーションのデプロイ方式のみが異なります。

典型的なクラスタ構成には、次のハードウェアおよびソフトウェアが含まれます。

- ハードウェア

- 実行可能アプリケーション・ファイルがインストールされているローカル(プライベート)・ディスクをそれぞれ1つ以上持っているMicrosoftクラスタ・ノード。

- クラスタ内通信のためのノード間のプライベート(ハートビート)・インターコネクト。

- Local Area Network(LAN)またはWide Area Network(WAN)に接続するパブリック・インターコネクト(インターネットまたはイントラネット、あるいはその両方)。

- 共有ストレージ・インターコネクト(ファイバ・チャネルまたはSAN)上のNTFS形式のディスク。あるノードから別のノードにフェイルオーバーする必要があるすべてのデータファイル、ログ・ファイルおよびその他のファイルは、これらのクラスタ・ディスク上に置かれます。

注意:
さらに高い可用性を与えるために冗長性の高いハードウェア(RAIDなど)を使用する場合の情報は、クラスタ・ハードウェアのマニュアルを参照してください。

- その他の冗長コンポーネント(UPS、ネットワーク・カード、ディスク・コントローラなど)。

- ソフトウェア(各ノードにインストール)

- Microsoft Windows

- Oracle Fail Safe

- Oracle Fail Safe Manager(1つ以上のクラスタ・ノードまたは1台以上のクライアント・ワークステーション、あるいはその両方にインストール)

- 次のリソースのうち、可用性を高める1つ以上のリソース:

- Oracleシングルインスタンス・データベース

- Oracle Management Agent

- Windows汎用サービスとして構成可能なOracleまたはサード・パーティ製のアプリケーション

これらのコンポーネントのサポートされているリリースの詳細は、『Oracle Fail Safeリリース・ノート』を参照してください。

図1-4に、2つのノードからなるクラスタをOracle Fail Safeで構成した場合のハードウェアおよびソフトウェア・コンポーネントを示します。実行可能アプリケーション・ファイルは各クラスタ・ノードのプライベート・ディスク上にインストールされ、アプリケーション・データおよびログ・ファイルは共有クラスタ・ディスクに常駐することに注意してください。

図1-4 Oracle Fail Safeによって構成されるハードウェアおよびソフトウェア・コンポーネント

「図1-4 Oracle Fail Safeによって構成されるハードウェアおよびソフトウェア・コンポーネント」の説明

1.4 Oracle Fail Safeソリューションのデプロイ

Oracle Fail SafeはMicrosoft Windowsフェイルオーバー・クラスタとともに、クラスタ上で稼働するリソースを構成し、高速フェイルオーバーを実現して、計画的な停止(システム・アップグレード)および計画外の停止(ハードウェアまたはソフトウェアの障害)による停止時間を最小限に抑えます。

クラスタは、次のものを管理することにより、高い可用性を提供します。

- 計画外グループ・フェイルオーバー
クラスタにより、計画外グループ・フェイルオーバー(ハードウェアまたはソフトウェア・コンポーネントの障害)がユーザーに対して透過的な方法で管理されます。クラスタ上の1つのノードが使用不可になった場合、一時的に別のノードがそれ自体の作業負荷と、障害のあったノードの作業負荷の両方を処理します。リソースに障害が発生し、現在のノード上で再起動できなくなった場合、別のノードがそのリソース(およびそれが依存しているすべてのリソース)の所有権を受け取り、その再起動を試みます。

- 計画的フェイルオーバー

クラスタにより、グループの計画的フェイルオーバー(クラスタ上のソフトウェアをアップグレードする場合などに意図的に発生させるフェイルオーバー)が管理されます。別のノードにリソースをフェイルオーバーするには、ソフトウェアまたはハードウェアのアップグレードを実行した後、そのリソースを元のノードに戻すことができます。(これをリソースのフェイルバックと呼びます。)その後、クラスタの他のノードでも同じアップグレード手順を実行します。

また、Oracle Fail Safeでは次のものを管理することにより、クラスタ環境のリソースを効率的に使用できます。

- 独立した作業負荷
クラスタ・ノードは個別の作業負荷を処理できます。たとえば、1つのノードがOracle Databaseのホストとなり、残りのノードがアプリケーションのホストとなることが可能です。

- ロード・バランス

クラスタ・ノード間でリソースのバランスをとることができます。たとえば、負荷の大きいノードから容量に余裕があるノードにデータベースを移すことが可能です。

Oracle Fail Safeには多様なデプロイメント・オプションがあり、幅広いフェイルオーバー要件を満たします。第3章では、アクティブ/パッシブ・ソリューションやアクティブ/アクティブ・ソリューションなど、業務要件に合せてOracle Fail Safeソリューションを構成する方法を説明します。

2 クラスタの概念

Oracle Fail Safeの高可用性ソリューションでは、Microsoft Windowsクラスタ・ハードウェアとMicrosoft Windowsフェイルオーバー・クラスタ・ソフトウェアを使用しています。

- Microsoftクラスタは、2つ以上の独立したコンピューティング・システム(ノードと呼ばれる)が同じディスク・サブシステムに接続された構成になっています。

- Microsoft Windowsソフトウェアに組み込まれているMicrosoft Windowsフェイルオーバー・クラスタ・ソフトウェアにより、Windowsクラスタにデプロイされたアプリケーションおよびハードウェア・コンポーネント(リソースと呼ばれる)を構成、監視および制御できます。

Oracle Fail Safeが提供する高可用性機能を利用するためには、Microsoft Windowsフェイルオーバー・クラスタの概念を理解することが重要になります。

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

- クラスタ・テクノロジ

- リソース、グループおよび高可用性

- グループ、仮想アドレスおよび仮想サーバー

- 仮想アドレスへのIPアドレス割当て

- クラスタ・グループとクラスタ別名

- フェイルオーバーについて

- フェイルバックについて

2.1 クラスタ・テクノロジ

クラスタのメンバーであるWindowsシステムをクラスタ・ノードと呼びます。クラスタ・ノードは、パブリックな共有ストレージ・インターコネクトおよびプライベート・ノード間ネットワーク接続によって結合されます。

ノード間ネットワーク接続(ハートビート接続とも呼ばれる)では、あるノードが使用可能かどうかを別のノードから検出できます。この通信には、(ユーザーおよびクライアント・アプリケーションのアクセスに使用されるパブリック・ネットワーク接続と区別される)プライベート・インターコネクトを使用することが一般的です。あるノードに障害が発生した場合、クラスタ・ソフトウェアは使用不可になったノードの作業負荷をただちに使用可能なノードにフェイルオーバーし、障害発生ノードが所有していたあらゆるクラスタ・リソースを使用可能なノードに再マウントします。クライアントは、何も変更することなく、クラスタ・リソースに継続してアクセスします。

図2-1に、2つのノードからなるMicrosoftクラスタ構成でのネットワーク接続を示します。

図2-1 Microsoftクラスタ・システム

「図2-1 Microsoftクラスタ・システム」の説明

2.1.1 高可用性を提供するクラスタについて

クラスタ・テクノロジが利用できるようになるまでは、PCシステムの信頼性はRAIDやミラー化ドライブ、および電源の二重化といったハードウェアの冗長性によって達成されていました。可用性の高いシステムを作成する上でディスク冗長性は重要ですが、この方法のみではシステムとアプリケーションの可用性を保証できません。

Microsoft Windowsフェイルオーバー・クラスタ・ソフトウェアを使用してWindowsクラスタ内のサーバーに接続すると、通常の操作中は各サーバー(ノード)がクラスタ・ディスクのサブセットに排他的アクセスすることになり、サーバーの冗長化を実現します。クラスタは、互いに依存しないスタンドアロン・システムよりはるかに効率的です。なぜなら、各ノードはそれぞれ有効な作業を実行できる上に、障害が発生したクラスタ・ノードのディスク・リソースおよび作業負荷を引き継ぐことができるためです。

クラスタは、その設計によって、コンポーネントの障害を管理し、コンポーネントの追加と削減をユーザーに認識させず、高い可用性を実現します。障害の検出、リカバリ、およびクラスタ・ノードを単一のシステムとして管理する能力などのサービスの提供を含む、付加的な利点があります。

注意:
可用性が高まるように冗長性の高いハードウェア( RAIDテクノロジなど)を使用する場合の情報は、ハードウェアのマニュアルを参照してください。

2.1.2 システムレベル構成について

クラスタ構成の設定と使用には、様々な方法があります。Oracle Fail Safeでは、次の構成がサポートされています。

- アクティブ/パッシブ構成

- アクティブ/アクティブ構成

これらの構成の詳細は、第3章を参照してください。

2.1.3 ディスクレベル構成について

Windowsフェイルオーバー・クラスタが障害からリカバリする際には、正常に機能しているノードが、シェアード・ナッシング構成を介して障害発生ノードのディスク・データへのアクセスを獲得します。

シェアード・ナッシング構成では、すべてのノードが物理的に同一ディスクにケーブル接続されていますが、特定のディスクにアクセスできるのは一度につき1つのノードのみです。すべてのノードが物理的にディスクに接続されていても、そのディスクを所有しているノードしか、それらにアクセスできません。

図2-2は、2つのノードからなるクラスタで1つのノードが使用不可になった場合に、障害発生ノードが所有していたディスクおよびアプリケーション作業負荷の所有権を、もう一方のクラスタ・ノードが引き受け、両方のノードに対する操作の処理を続行することを示しています。

図2-2 シェアード・ナッシング構成

「図2-2 シェアード・ナッシング構成」の説明

2.2 リソース、グループおよび高可用性

あるサーバー・ノードが使用不可になった場合、可用性が高まるように構成されたクラスタ・リソース(ディスク、Oracle Databaseとアプリケーション、IPアドレスなど)は、グループと呼ばれる単位で使用可能なノードに移されます。グループは、サービスまたはアプリケーション、あるいはクラスタ化されたロールと呼ばれることもあります。次の各項でリソースおよびグループについて説明し、可用性が高まるようにそれらを構成する方法を説明します。

2.2.1 リソースについて

クラスタ・リソースとは、コンピューティング・システムで使用可能で、次のような特性を備えた物理的または論理的なコンポーネントです。

- オンライン化とオフライン化が可能です。

- クラスタ内で管理できます。

- ある時点でホストになるノードはクラスタ内で1つのみですが、潜在的には他のクラスタ・ノードによっても所有されます。(たとえば、あるリソースが特定のノードによって所有されている場合です。フェイルオーバーの後、そのリソースは別のクラスタ・ノードによって所有されます。ただし、特定の時点においてリソースにアクセスできるクラスタ・ノードはいずれか1つのみです。)

2.2.2 グループについて

グループは、フェイルオーバーの最小単位を形成するクラスタ・リソースの論理的な集合です。グループは、サービスまたはアプリケーション、あるいはクラスタ化されたロールと呼ばれることもあります。フェイルオーバーの際には、グループ単位のリソースが別のノードに移されます。グループは、同時に1つのクラスタ・ノードにのみ所有されます。特定の作業負荷のために必要なリソース(データベース、ディスクおよび他のアプリケーション)はすべて、同じグループに常駐している必要があります。

たとえば、Oracle Fail Safeを使用して可用性の高いOracle Databaseを構成するために作成されたサービスまたはアプリケーションには、次のようなリソースが含まれる可能性があります。

- Oracle Databaseで使用する全ディスク

- Oracle Databaseのインスタンス

- 次の項目で構成されている1つ以上の仮想アドレス

- IPアドレス

- ネットワーク名

- グループ内のデータベースへの接続要求をリスニングするOracle Netネットワーク・リスナー

- Oracle Enterprise Managerとサービスまたはアプリケーション内のデータベースの間の通信を管理するOracle Management Agent

リソースをグループに追加する場合、そこで使用されるディスクも同じグループに含まれる点に注意してください。そのため、同一のディスクを使用する2つのリソースを異なるグループに含めることはできません。両方のリソースをフェイルセーフにするには、同じグループに含めてください。

Microsoft Windowsフェイルオーバー・クラスタ・マネージャを使用して、グループを作成し、アプリケーションを実行するために必要なリソースを追加できます。

2.2.3 リソースの依存性について

図2-3に、販売データベースの可用性が高まるように作成されたグループを示します。リソースをグループに追加すると、追加したリソースが依存しているリソースがOracle Fail Safe Managerによって自動的に追加されます。この関係はリソースの依存性と呼ばれます。たとえば、シングルインスタンス・データベースをグループに追加すると、Oracle Fail Safeにより、データベース・インスタンスで使用されるシェアード・ナッシング・ディスクが追加され、Oracle Netファイルがそれぞれのグループと連携するように構成されます。また、Oracle Fail Safeでは、各グループがそれぞれのノードにフェイルオーバーできるかどうかがテストされます。

図2-3 グループの設計

「図2-3 グループの設計」の説明

クラスタ内のノードはそれぞれ1つ以上のグループを所有できます。各グループは、関連付けられたリソースの独立したセットで構成されます。グループ内のリソースの依存関係によって、クラスタ・ソフトウェアがリソースをオンライン化またはオフライン化する順序が定義されます。たとえば、障害が発生するとまずOracleアプリケーションまたはデータベース(およびOracle Netリスナー)がオフライン化され、続いて物理ディスク、ネットワーク名、IPアドレスがオフライン化されます。フェイルオーバー・ノードでは、順序が逆になり、Windowsフェイルオーバー・クラスタによって最初にIPアドレスがオンライン化され、次にネットワーク名、物理ディスク、最後にOracle DatabaseとOracle Netリスナー、またはアプリケーションがオンライン化されます。

2.2.4 リソース・タイプの概要

各リソース・タイプ(汎用サービス、物理ディスク、Oracle Databaseなど)は、リソースのDynamic Link Library(DLL)と関連付けられており、クラスタ環境ではそのリソースDLLを使用して管理されます。標準のMicrosoft Windowsフェイルオーバー・クラスタのリソースDLLおよびカスタムOracleリソースDLLがあります。同じリソースDLLで異なるリソース・タイプをサポートできます。

Microsoft Windowsフェイルオーバー・クラスタは、IPアドレス、物理ディスク、汎用サービスなどのサポートされるリソース・タイプのリソースDLLを提供します。(汎用サービス・リソースは、Microsoft Windowsフェイルオーバー・クラスタが提供するリソースDLLによってサポートされるWindowsサービスです。)

Oracle Fail Safeでは、カスタム・サポートが提供されているリソース・タイプ(汎用サービスなど)を監視する際に、多数のWindowsフェイルオーバー・クラスタ・リソースDLLを使用します。

オラクル社では、Oracle Databaseリソース・タイプに対するカスタムDLLを提供しています。Windowsフェイルオーバー・クラスタは、OracleリソースDLLを使用してOracle Databaseリソースを管理(オンライン化およびオフライン化)し、リソースの可用性を監視します。

Oracle Fail SafeはDLLファイルを提供し、Microsoft Windowsフェイルオーバー・クラスタによるOracle Databaseリソースの通信および監視を有効化できます。FsResOdbs.dllが提供する機能によって、Microsoft Windowsフェイルオーバー・クラスタはOracle Databaseおよびそのリスナーをオンライン化またはオフライン化し、Is Aliveポーリングを介してデータベースの状態をチェックできます。

Oracle Fail Safe Managerを使用してOracle Databaseをグループに追加すると、Oracle Fail Safeによってデータベース・リソースとOracleリスナー・リソースが作成されます。

Oracle Fail Safeには、Oracleクラスタ・リソースに関する情報がMicrosoft Windowsフェイルオーバー・クラスタよりも多く含まれています。このため、Oracle Databaseおよびアプリケーションを構成し管理する場合はOracle Fail Safe Manager(またはOracle Fail Safe PowerShellコマンドレット)を使用することをお薦めします。

関連項目:
Oracle Fail Safeによって提供されるカスタム・リソースDLLの詳細は『Oracle Fail Safeインストレーション・ガイドfor Microsoft Windows』を参照し、標準リソース・タイプおよびリソースDLLの詳細はMicrosoft Windowsフェイルオーバー・クラスタのドキュメント・セットを参照してください。

2.3 グループ、仮想アドレスおよび仮想サーバー

仮想アドレスは、グループ内のリソースのホストになっているクラスタ・ノードとは無関係に、リソースにアクセスできるネットワーク・アドレスです。仮想アドレスによって、ノードに依存しない一定したネットワークの場所が提供されます。これにより、クライアントはリソースのホストになっている物理的クラスタ・ノードを認識することなく、容易にリソースにアクセスできます。

障害が起きている間にグループが使用不可ノードから使用可能ノードに移されるため、クライアントは、1つのノードによってしか識別されないアドレスを使用しているアプリケーションには接続できません。Oracle Fail Safe Manager内のグループの仮想アドレスを識別するには、グループに一意のネットワーク名とIPアドレスを付加します。

仮想アドレス・リソースをグループに追加するには、Microsoft Windowsフェイルオーバー・クラスタ・マネージャを使用します。

あるグループに仮想アドレスを追加すると、そのグループは仮想サーバーになります。クライアント・アクセスのために各グループには少なくとも1つの仮想アドレスが必要ですが、グループに複数の仮想アドレスを割り当てることができます。帯域幅を増やしたり、グループ内のリソースのセキュリティを区分化するために、複数の仮想アドレスを割り当てることもできます。

ユーザーやクライアント・アプリケーションからは、各グループは特定のノードの物理的識別情報に依存しない、可用性の高い仮想サーバーのように見えます。グループ内のリソースにアクセスする場合、クライアントは常にグループの仮想アドレスに接続します。クライアントにとって、仮想サーバーはクラスタ・リソースへのインタフェースであり、物理ノードのように見えます。

図2-4に、各ノードに1つのグループを構成した2ノード・クラスタを示します。クライアントは仮想サーバーAおよびBを通じてこれらのグループにアクセスします。各ノードの物理アドレスではなく、グループの仮想アドレスを介してクラスタ・リソースにアクセスすることで、どのクラスタ・ノードがグループのホストになっているかにかかわらず、確実にリモート接続ができます。

図2-4 仮想サーバーを介したクラスタ・リソースへのアクセス

「図2-4 仮想サーバーを介したクラスタ・リソースへのアクセス」の説明

2.4 仮想アドレスへのIPアドレス割当て

クラスタをセットアップする際に、少なくとも次の数のIPアドレスを割り当てます。

- 各クラスタ・ノードに対して1つのIPアドレス

- 各クラスタ別名(2.5項を参照)に対して1つのIPアドレス

- 各グループに対して1つのIPアドレス

たとえば、図2-4の構成では、2つのクラスタ・ノードに1つずつ、クラスタ別名に1つ、そして2つのグループに1つずつで合計5つのIPアドレスが必要です。

注意:
1つのグループに対して複数の仮想アドレスを指定できます。詳細は、4.7項を参照してください。

関連項目:
Oracle Fail Safe環境でのIPアドレス割当ての詳細は、『Oracle Fail Safeインストレーション・ガイドfor Microsoft Windows』を参照してください。

2.5 クラスタ・グループとクラスタ別名

クラスタ別名とは、クラスタを特定し、クラスタ関連のシステム管理に使用される、ノードに依存しないネットワーク名です。Microsoft Windowsフェイルオーバー・クラスタはクラスタ・グループと呼ばれるグループを作成し、クラスタ別名はこのグループの仮想アドレスです。Oracle Fail Safeはクラスタ・グループ内にあるリソースです。このためクラスタ・グループの可用性が高められると同時に、すべてのクラスタ・ノードのOracle Fail Safeの処理が常にOracle Fail Safeにより調整されます。

Oracle Fail Safe環境では、クラスタ別名はシステム管理の目的でしか使用されません。Oracle Fail Safe Managerは、クラスタ別名を使用してクラスタ・コンポーネントおよびMicrosoft Windowsフェイルオーバー・クラスタと対話します。

特定のクラスタでOracle Fail Safe Managerを使用するには、まずそのクラスタをOracle Fail Safe Managerクラスタ・リストに追加します。これを実行するには、「Oracle Fail Safe Manager」ページの右側のペインで「アクション」メニューから「クラスタの追加」を選択します。次に、図2-5に示すように、「クラスタ別名」フィールドにクラスタのネットワーク名を入力します。オプションで、「別の資格証明を使用して接続」を選択できます。

デフォルトでは、Oracle Fail Safe Managerは現在のWindowsログイン・セッションの資格証明を使用してクラスタに接続します。別のユーザーの資格証明を使用するには、「別の資格証明を使用して接続」オプションを選択します。Windowsセキュリティの「クラスタ資格証明」ダイアログ・ボックスが開き、クラスタを管理するための新たな資格証明を入力できるようになります。表示されたフィールドに、ユーザー名とパスワードを入力して続行します。資格証明を保存するには、資格証明を記憶するオプションを選択して、「OK」をクリックします。クラスタに接続する場合にOracle Fail Safe Managerでクラスタ用の保存された資格証明があるかどうかを確認してクラスタの接続に使用するために、資格証明がWindows資格証明キャッシュに保存されます。

関連項目:
Oracle Fail Safe Managerクラスタ・リストへのクラスタの追加およびクラスタの接続の手順ごとの指示は、Oracle Fail Safeのチュートリアルを参照してください。

図2-5 ツリーにクラスタを追加」ダイアログ・ボックスの「クラスタ別名

「図2-5 「ツリーにクラスタを追加」ダイアログ・ボックスの「クラスタ別名」」の説明

クライアント・アプリケーションは、クラスタ・リソースとの通信の際にクラスタ別名を使用しません。かわりに、そのリソースを含むグループの仮想アドレスを使用します。

2.6 フェイルオーバーについて

あるノード上のグループをオフライン化し、それを別のノード上でオンライン化するプロセスをフェイルオーバーと呼びます。フェイルオーバーの発生後、このグループ内のリソースを実行するように構成されたクラスタ・ノードのいずれかが使用可能であれば、そのリソースにアクセスできます。Windowsフェイルオーバー・クラスタは、クラスタ内のクラスタ・ノードおよびリソースの状態を継続的に監視します。

フェイルオーバーには、計画的なものと計画外のものがあります。

- 計画外フェイルオーバーは、クラスタ・ソフトウェアがノードまたはリソースの障害を検出した場合に、自動的に行われます。

- 計画的フェイルオーバーは、ロード・バランスやソフトウェアのアップグレードなどの機能を実行する場合に行う手動の操作です。

次の各項で、これら2タイプのフェイルオーバーについて詳細に説明します。

2.6.1 計画外フェイルオーバー

計画外グループ・フェイルオーバーには2つのタイプがあり、それぞれ次のいずれかの原因によって実行されます。

- 可用性が高まるように構成されたリソースの障害

- クラスタ・ノードの障害または使用不可状態

2.6.1.1 リソース障害による計画外フェイルオーバー

リソース障害による計画外フェイルオーバーは、次のように検出および実行されます。

1. クラスタ・ソフトウェアが、リソースに障害が発生したことを検出します。
リソース障害を検出するために、クラスタ・ソフトウェアはリソースが稼働状態であるかどうかを(リソースDLL経由で)定期的に問い合せます。詳細は、2.6.4項を参照してください。

2. クラスタ・ソフトウェアが、リソース再起動ポリシーを実装します。リソース再起動ポリシーでは、クラスタ・ソフトウェアが現在のノード上でリソース再起動を試行するかどうか、そして再起動を試行する場合には一定時間内に何回それを試行するかを指定します。たとえばOracle Fail Safeがリソースの再起動を900秒間に3回試行するなどと指定します。
リソースが再起動された場合、クラスタ・ソフトウェアがソフトウェアの監視を再開し(手順1)、フェイルオーバーは回避されます。

3. リソースが現在のノード上で再起動されない、またはできない場合、クラスタ・ソフトウェアはリソース・フェイルオーバー・ポリシーを適用します。
リソース・フェイルオーバー・ポリシーでは、リソース障害が起きた場合にグループをフェイルオーバーするかどうかを指定します。グループがフェイルオーバーしないというリソース・フェイルオーバー・ポリシーを指定した場合、リソースは障害発生の状態のままとなり、フェイルオーバーは発生しません。

図2-9に示すプロパティ・ページで、リソースの再起動ポリシーおよびフェイルオーバー・ポリシーを表示または変更できます。

リソースが再起動しない(またはできない)場合には、グループがフェイルオーバーするというリソース・フェイルオーバー・ポリシーを指定すると、そのグループは別のノードにフェイルオーバーされます。グループのフェイルオーバー先となるノードは、稼働しているノード、そのリソースの「可能所有者ノード」リスト、およびグループの「優先所有者ノード」リストによって決定されます。リソースの「可能所有者ノード」リストの詳細は2.6.7項を、グループの「優先所有者ノード」リストの詳細は2.6.10項を、それぞれ参照してください。

4. グループがフェイルオーバーすると、そのグループのフェイルオーバー・ポリシーが適用されます。グループ・フェイルオーバー・ポリシーでは、そのグループがオフライン化されるまでに、クラスタ・ソフトウェアが一定時間内に何回のフェイルオーバーを許容するかを指定します。グループ・フェイルオーバー・ポリシーを使用すると、グループが何度もフェイルオーバーすることを防ぐことができます。グループ・フェイルオーバー・ポリシーの詳細は、2.6.8項を参照してください。

5. (障害または意図的な再起動のために)所定のノードがオフライン化され、その後再度オンライン化される場合に、リソースとそれが属するグループがそのノードに戻されるかどうかは、フェイルバック・ポリシーによって決定されます。フェイルバックの詳細は、2.7項を参照してください。
図2-6では、グループ1のリソースの1つに障害が発生したために、仮想サーバーAがノードBにフェイルオーバーしています。

図2-6 リソースのフェイルオーバー

「図2-6 リソースのフェイルオーバー」の説明

2.6.1.2 ノードの障害または使用不可状態による計画外フェイルオーバー

クラスタ・ノードが使用不可になったことによる計画外フェイルオーバーは、次に説明する手順で検出および実行されます。

1. クラスタ・ソフトウェアによって、クラスタ・ノードが使用不可になったことが検出されます。
ノードの障害または使用不可状態を検出するために、クラスタ・ソフトウェアは(プライベート・インターコネクトを使用して)定期的にクラスタ内のノードに問合せを行います。

2. 障害の発生した、または使用不可になったノード上のグループが、1つ以上の他のノードにフェイルオーバーされます。フェイルオーバー先のノードは、クラスタ内で使用可能なノード、各グループの「優先所有者ノード」リスト、および各グループ内のリソースの「可能所有者ノード」リストによって決定されます。リソースの「可能所有者ノード」リストの詳細は2.6.7項を、グループの「優先所有者ノード」リストの詳細は2.6.10項を、それぞれ参照してください。

3. グループがフェイルオーバーすると、そのグループのフェイルオーバー・ポリシーが適用されます。グループ・フェイルオーバー・ポリシーでは、そのグループがオフライン化されるまでに、クラスタ・ソフトウェアが一定時間内に何回のフェイルオーバーを許容するかを指定します。グループ・フェイルオーバー・ポリシーの詳細は、2.6.8項を参照してください。

4. リソースとそれが属するグループが、再度使用可能になったノードに移されるかどうかは、フェイルバック・ポリシーによって決定されます。フェイルバックの詳細は、2.7項を参照してください。
図2-7では、ノードAでの障害発生時にグループ1がフェイルオーバーされることを示しています。クライアント・アプリケーション(障害が発生したサーバーに接続されていたもの)は、フェイルオーバー後、再びサーバーに接続する必要があります。アプリケーションがOracle Databaseに対する更新処理を実行中で、障害発生時に未コミットのデータベース・トランザクションが進行している場合、そのトランザクションはロールバックされます。

注意:
この項の手順3および4は、2.6.1.1項の手順4および5と同じです。フェイルオーバーの開始後は、フェイルオーバーの原因がリソース障害かノード障害かにかかわらず、手順は同じになります。

図2-7 ノードのフェイルオーバー

「図2-7 ノードのフェイルオーバー」の説明

2.6.2 グループの計画的フェイルオーバー

グループの計画的フェイルオーバーは、あるノードのクライアント・アプリケーションおよびクラスタ・リソースをオフライン化し、別のノードでオンライン化する意図的なプロセスです。これによって、あるクラスタ・ノードで管理者が定期的なメンテナンス作業(ハードウェアおよびソフトウェアのアップグレードなど)を実行している間も、ユーザーは別のノードで作業を継続できます。メンテナンス作業以外にも、計画的フェイルオーバーによってクラスタ内のノード間でロード・バランスを行うことができます。つまり計画的フェイルオーバーは、ノード間でのグループの移動に使用します。実際、計画的フェイルオーバーを実装する際には、Oracle Fail Safe Manager内でグループ移動操作を実行します(説明はOracle Fail Safe Managerのオンライン・ヘルプを参照してください)。

計画的フェイルオーバーの際、Oracle Fail SafeはMicrosoft Windowsフェイルオーバー・クラスタとともに、グループをあるノードから別のノードに効率よく移します。クライアント接続は失われるので、透過的アプリケーション・フェイルオーバーを構成していない場合、クライアントはアプリケーションの仮想サーバー・アドレスに手動で再接続する必要があります(透過的アプリケーション・フェイルオーバーの詳細は、8.9項を参照してください)。また、元のノードがオフライン化された場合でも、Oracle Fail Safeによりクライアントは別のクラスタ・ノードで作業を続行できるため、ゆっくりアップグレードを実行します。(グループにOracle Databaseが含まれている場合、どの計画的フェイルオーバーよりも先にデータベースのチェックポイント取得が実行され、新しいノードでの高速データベース・リカバリが確実に行われます。)

2.6.3 フェイルオーバーに影響するグループおよびリソースのポリシー

リソースおよびグループの各フェイルオーバー・ポリシーの値は、Oracle Fail Safe ManagerおよびMicrosoft Windowsフェイルオーバー・クラスタ・マネージャを使用してグループを作成するか、グループにOracleリソースを追加すると、デフォルトに戻されます。ただし、Oracle Fail Safe ManagerのOracleリソース「プロパティ」ページおよびMicrosoft Windowsフェイルオーバー・クラスタ・マネージャのグループ・フェイルオーバーの「Properties」ページでこれらのポリシーの値をリセットできます。グループ・フェイルオーバーの「Properties」ページを使用して「Allow failback」オプションを選択し、グループ作成時またはそれ以降に、グループ・フェイルバック・ポリシーの値を設定できます。

図2-8に、グループ・フェイルオーバー・ポリシーを設定するページを示します。このページにアクセスするには、Microsoft Windowsフェイルオーバー・クラスタ・マネージャのツリー・ビューで該当するグループを選択し、画面右側のペインの「Actions」メニューから「Properties」アクションを選択します。次に、「Properties」ページの「Failover」タブを選択します。

図2-9に、Oracleリソース・ポリシーを設定するページを示します。このページにアクセスするには、画面右側のペインの「プロパティ」アクション・メニューを選択するか、メニュー・バーの「操作」アイテムから「プロパティ」を選択します。次に、Oracleリソース「プロパティ」ページの「ポリシー」タブを選択します。

図2-8 グループ・フェイルオーバー・プロパティ・ページ

「図2-8 グループ・フェイルオーバーのプロパティ・ページ」の説明

図2-9 リソース・ポリシーのプロパティ・ページ

「図2-9 リソース・ポリシーのプロパティ・ページ」の説明

2.6.4 リソース障害の検出

可用性が高まるように構成されたリソースは、すべてクラスタ・ソフトウェアによってその状態が監視されます。リソース障害は次の3つの値に基づいて検出されます。

- 保留タイムアウト値
保留タイムアウト値は、障害が発生したと判断する前に保留状態のリソースがオンライン化(またはオフライン化)されるまで、クラスタ・ソフトウェアが待機する時間の長さを指定します。デフォルト値は180秒です。

- Is Aliveポーリング間隔
Is Aliveポーリング間隔は、クライアント・ソフトウェアがリソースの状態をチェックする頻度を指定します。リソース・タイプのデフォルト値を使用するか、数値(秒単位)を指定します。このチェックは、Looks Aliveポーリング間隔で行われるチェックよりも完全ですが、消費するシステム・リソースも多くなります。

- Looks Aliveポーリング間隔
Looks Aliveポーリング間隔は、クライアント・ソフトウェアがリソースの登録済の状態をチェックし、リソースがアクティブかどうかを判断する頻度を指定します。リソース・タイプのデフォルト値を使用するか、数値(秒単位)を指定します。このチェックは、Is Aliveポーリング間隔で行われるチェックよりも不完全ですが、消費するシステム・リソースは少なくなります。

2.6.5 リソース再起動ポリシーについて

リソースで障害が発生したことが確定すると、クラスタ・ソフトウェアによってそのリソースの再起動ポリシーが適用されます。リソース再起動ポリシーには、図2-9で示すように2つのオプションがあります。

- クラスタ・ソフトウェアが、現在のノードでリソースの再起動を試みない。そのかわりに、リソース・フェイルオーバー・ポリシーをただちに適用します。

- クラスタ・ソフトウェアが、現在のノードでリソースの再起動を、一定時間内に指定した回数試みる。リソースが再起動できない場合、クラスタ・ソフトウェアはリソース・フェイルオーバー・ポリシーを適用します。

2.6.6 リソースのフェイルオーバー・ポリシーについて

リソース・フェイルオーバー・ポリシーは、現在のノードでリソースが再起動されない(または再起動できない)場合に、そのリソースを含むグループがフェイルオーバーするかどうかを決定します。障害リソースを含むグループがフェイルオーバーしないというポリシーが指定されている場合、リソースは現在のノードで障害発生状態のままとなります。(このグループが、最終的にはフェイルオーバーする可能性はあります。このグループ内の別のリソースが、障害リソースを含むグループはフェイルオーバーするというポリシーを指定されていれば、そこでフェイルオーバーするためです。)障害リソースを含むグループがフェイルオーバーするというポリシーが指定されている場合、障害リソースを含むグループは、「優先所有者ノード」リストによる指定に応じて別のクラスタ・ノードにフェイルオーバーします。「優先所有者ノード」リストについては、2.6.10項および2.7.1項を参照してください。

2.6.7 リソースの「可能所有者ノード」リストについて

「可能所有者ノード」リストは、指定されたリソースの実行が許可されているすべてのノードで構成されています。

Oracle Fail Safe Managerは、リソースの「拡張ポリシー」の「プロパティ」タブの下に可能所有者ノードを表示します。ユーザーがノードを変更する場合、Microsoft Windowsフェイルオーバー・クラスタ・マネージャを使用する必要があります。可能所有者ノードを変更した後、「検証」グループ・アクションを実行する必要があります。

- 図2-10、図2-11および図2-12は、Microsoft Windowsフェイルオーバー・クラスタ・マネージャのグループのプロパティ・ページの例です。

注意:
「検証」グループ・アクションを選択すると、指定されたグループ内のリソースが、そのグループの可能所有者となっている各ノードで実行するよう構成されているかどうかが、Oracle Fail Safeによってチェックされます。グループ内のリソースが実行するように構成されていない可能所有者ノードが検出されると、Oracle Fail Safeがそれを構成します。
このため、新規のノードが可能所有者としてリストされた各グループについては、「検証」グループ・コマンドを選択することを強くお薦めします。7.1.2項に、「検証」グループ・アクションを示します。

図2-10 優先所有者ノードのプロパティ・ページ

「図2-10 優先所有者ノードのプロパティ・ページ」の説明

図2-11 優先所有者ノードのプロパティ・ページ

「図2-11 優先所有者ノードのプロパティ・ページ」の説明

図2-12可能所有者ノードのプロパティ・ページ

「図2-12 「可能所有者ノードのプロパティ・ページ」の説明

2.6.8 グループのフェイルオーバー・ポリシーについて

リソースが現在のノード上で再起動できない場合には、そのリソースを含むグループがフェイルオーバーするというリソース・フェイルオーバー・ポリシーを指定すると、そのグループはフェイルオーバーし、グループ・フェイルオーバー・ポリシーが適用されます。同様に、ノードが使用不可になった場合にも、そのノード上のグループがフェイルオーバーし、グループ・フェイルオーバー・ポリシーが適用されます。

グループ・フェイルオーバー・ポリシーでは、そのグループがオフライン化されるまでに、クラスタ・ソフトウェアが一定時間内に何回のフェイルオーバーを許容するかを指定します。グループ・フェイルオーバー・ポリシーを使用すると、グループが何度もフェイルオーバーするのを防ぐことができます。

グループ・フェイルオーバー・ポリシーは、フェイルオーバーしきい値とフェイルオーバー期間とで構成されます。

- フェイルオーバーしきい値
フェイルオーバーしきい値では、クラスタ・ソフトウェアがグループ・フェイルオーバーの試行を停止するまでに(フェイルオーバー期間内で)発生するフェイルオーバーの最大回数を指定します。

- フェイルオーバー期間
フェイルオーバー期間は、クラスタ・ソフトウェアがフェイルオーバー発生回数をカウントする時間です。フェイルオーバーの頻度が、フェイルオーバー期間に指定した時間内に、フェイルオーバーしきい値に指定した回数を超えると、クラスタ・ソフトウェアはグループ・フェイルオーバーの試行を停止します。

たとえば、フェイルオーバーしきい値が3でフェイルオーバー期間が5の場合、クライアント・ソフトウェアがそのグループのフェイルオーバーを中止するまでに、5時間以内で3回のフェイルオーバーが許容されます。

最初のフェイルオーバーが発生すると、フェイルオーバー期間を測定するタイマーは0にリセットされ、フェイルオーバー回数を測定するカウンタは1に設定されます。フェイルオーバー期間を超過した時点では、タイマーは0にリセットされません。そのかわりに、フェイルオーバー期間を超過してから最初のフェイルオーバーが発生した時点で、タイマーは0にリセットされます。

たとえば、前述の例と同様にフェイルオーバー期間が5時間で、フェイルオーバーしきい値が3であるとします。図2-13に示すように、Aの時点で最初のグループ・フェイルオーバーが発生すると、タイマーが0に設定されます。2度目のグループ・フェイルオーバーが4.5時間後のBの時点で発生し、3度目のグループ・フェイルオーバーはCの時点で発生すると仮定します。3度目のグループ・フェイルオーバー発生時点(Cの時点)ではフェイルオーバー期間を超過しているため、グループ・フェイルオーバーは続行可能で、タイマーは0にリセットされ、フェイルオーバーのカウンタは1にリセットされます。

Dの時点(Aの時点から7時間が経過し、Bの時点から2.5時間が経過した時点)でフェイルオーバーがもう1回発生すると仮定します。フェイルオーバーは停止するでしょうか。B、CおよびDの時点でのフェイルオーバーは、5時間以内に発生しています。しかし、フェイルオーバー期間を測定するタイマーはCの時点で0にリセットされており、フェイルオーバーしきい値は超えていないため、このグループのフェイルオーバーはクラスタ・ソフトウェアによって許可されます。

次のフェイルオーバーがEの時点で発生するとします。通常はフェイルオーバーになるような問題がFの時点で発生しても、クラスタ・ソフトウェアはこのグループをフェイルオーバーしません。これは、Cの時点でタイマーが0にリセットされて以降5時間以内に、3回のフェイルオーバーが発生したためです。このグループは、クラスタ・ソフトウェアによって障害発生状態のまま現在のノード上に残されます。

図2-13 フェイルオーバーしきい値とフェイルオーバー期間の関係を示す時間軸

「図2-13 フェイルオーバーしきい値とフェイルオーバー期間の関係を示す時間軸」の説明

2.6.9 リソース再起動ポリシーおよびグループ・フェイルオーバー・ポリシーによるフェイルオーバーへの影響

リソース再起動ポリシーと、リソースを含むグループのフェイルオーバー・ポリシーは、どちらもグループのフェイルオーバー機能に影響します。

たとえば、CustomersというグループにNortheastデータベースがあり、次のように指定するとします。

- Northeastデータベースの「ポリシー」プロパティ・ページで次のように指定します。

- 現在のノードで、600秒(10分)以内に3回データベースの再起動を試行

- リソースに障害が発生し再起動が不可能な場合には、グループをフェイルオーバー

- Customersグループの「フェイルオーバー」プロパティ・ページで次のように指定します。

- リソースを含むグループのフェイルオーバーしきい値は20

- リソースを含むグループのフェイルオーバー期間は1時間

データベース障害が発生したと仮定します。Oracle Fail Safeでは、現在のノードでデータベース・インスタンスの再起動が試行されます。データベース・インスタンス再起動の試行が、10分間で3回失敗したとします。この場合、Customersグループは別のノードにフェイルオーバーします。

そのノードで、Oracle Fail Safeはデータベース・インスタンスの再起動を試行しますが、10分間に3回失敗したため、Customersグループは再度フェイルオーバーします。Oracle Fail Safeによるデータベース・インスタンス再起動の試行とCustomersグループのフェイルオーバーは、データベース・インスタンスが再起動するか、あるいはグループのフェイルオーバーが1時間以内に20回を超えるまで続行されます。データベース・インスタンスが再起動できず、グループのフェイルオーバーが1時間以内に20回より少ない場合、Customersグループは何度もフェイルオーバーを続けます。このような場合には、フェイルオーバーが何度も続かないようにフェイルオーバーしきい値を低くすることを検討してください。

2.6.10 グループ・フェイルオーバーと「優先所有者ノード」リストについて

グループを作成する際に、グループ・フェイルオーバーおよびフェイルバック両方の「優先所有者ノード」リストを作成できます。(クラスタ内のノードが2つのみの場合、このリストをフェイルバックのみに指定します。)リスト中の各ノードがグループを所有する優先順位を示すために、順序付けられたノードのリストを作成します。

たとえば4つのノードからなるクラスタで、あるデータベースを含むグループについて次のような「優先所有者ノード」リストを指定するとします。

- ノード1

- ノード4

- ノード3

このように指定すると、4つのノードすべてが稼働している場合にはグループが優先的にノード1で実行されます。ノード1が使用不可になると、グループは2番目に指定されているノード4で実行されます。ノード1もノード4も使用不可の場合、次に指定されているノード3でグループが実行されます。ノード2が優先所有者ノード・リストから省略されます。ただし、クラスタ・ソフトウェアで使用可能なノードが他にない(ノード1、ノード4およびノード3のすべてで障害が発生したため)場合、グループはノード2にフェイルオーバーします。(ノード2が、グループ内のすべてのリソースの可能所有者とはかぎらない場合でも同様です。このような場合、グループはフェイルオーバーしますが、障害発生状態のままになります。)

フェイルオーバーが発生すると、クラスタ・ソフトウェアは「優先所有者ノード」リストを使用して、グループのフェイルオーバー先となるノードを決定します。グループのフェイルオーバー先となるのは、リスト内のノードのうち、稼働しており、かつそのグループの可能所有者ノードである最上位のノードです。クラスタ・ソフトウェアがグループのフェイルオーバー先ノードを決定する方法の詳細は、2.6.11項で説明します。

グループの「優先所有者ノード」リストによるフェイルバックへの影響の詳細は、2.7.1項を参照してください。

2.6.11 グループのフェイルオーバー・ノードの決定

グループのフェイルオーバー先となるノードは、次の3つのリストに基づいて決定されます。

- 使用可能なクラスタ・ノードのリスト
使用可能なクラスタ・ノードのリストは、グループ障害の発生時に稼働している全ノードで構成されます。たとえば、4つのノードからなるクラスタがあります。グループのフェイルオーバー時に1つのノードが停止している場合、使用可能なクラスタ・ノードのリスト内は3つになります。

- グループ内の各リソースの「可能所有者ノード」リスト(2.6.7項を参照。)

- リソースを含むグループの「優先所有者ノード」リスト(2.6.10項を参照。)

クラスタ・ソフトウェアでは、使用可能なクラスタ・ノードと、グループ内の全リソースに共通の可能所有者セットとの共通点を検出して、グループのフェイルオーバー先となる可能性があるノードを決定します。たとえば、4つのノードからなるクラスタで、ノード3にTest_Groupというグループがあるとします。Test_Group内のリソースには、表2-1に示すような可能所有者を指定してあります。

表2-1 Test_Groupグループ内のリソースの可能所有者の例

リソース1の可能所有者

リソース2の可能所有者

リソース3の可能所有者

ノード1 - はい

ノード1 - はい

ノード1 - はい

ノード2 - はい

ノード2 - いいえ

ノード2 - はい

ノード3 - はい

ノード3 - はい

ノード3 - はい

ノード4 - はい

ノード4 - はい

ノード4 - はい

表2-1を見ると、3つのリソースすべてに共通な可能所有者は次のノードであることがわかります。

- ノード1

- ノード3

- ノード4

ノード3(現在Test_Groupが常駐している)で障害が発生したと仮定します。使用可能なノードは次のようになります。

- ノード1

- ノード4

Test_Groupのフェイルオーバー先となるノードを決定するために、クラスタ・ソフトウェアはグループ内の全リソースに共通する可能所有者ノードのリストと、使用可能なノードのリストとの共通点を検出します。この例では、これら2つのリストで共通するのはノード1およびノード4です。

Test_Groupのフェイルオーバー先となるノードの決定には、そのグループの「優先所有者ノード」リストがクラスタ・ソフトウェアで使用されます。Test_Groupの「優先所有者ノード」リストを次のように設定してあるとします。

- ノード3

- ノード4

- ノード1

ノード3は障害が発生しているため、クラスタ・ソフトウェアはTest_Groupをノード4にフェイルオーバーします。ノード3およびノード4がいずれも使用不可の場合、Test_Groupはノード1にフェイルオーバーされます。もしノード1、3および4がすべて使用不可であれば、Test_Groupはノード2にフェイルオーバーされます。ただし、ノード2はTest_Group内のすべてのリソースの可能所有者ではないので、Test_Groupはノード2で障害発生状態のままになります。

2.7 フェイルバックについて

フェイルバックは、優先所有者ノードが動作可能状態に復帰した後で、クラスタ・リソースのグループがフェイルオーバー・ノードから優先所有者ノードに自動的に戻るプロセスです。優先所有者ノードは、可能な場合(そのノードが使用可能である場合)にグループを常駐させるノードです。

グループをフェイルオーバー・ノードから優先所有者ノードへフェイルバックする必要があるか、およびいつフェイルバックするかを決定するフェイルバック・ポリシーを設定できます。たとえば、あるグループがただちにフェイルバックする、または選択した特定の時間内にフェイルバックするように設定が可能です。あるいは、グループがフェイルバックせずに現在常駐しているノードで稼働し続けるようなフェイルバック・ポリシーも設定できます。図2-14に、グループのフェイルバック・ポリシーを設定するプロパティ・ページを示します。

図2-14 グループの「フェイルバック」ポリシー・プロパティ・ページ

「図2-14 グループの「フェイルバック」ポリシー・プロパティ・ページ」の説明

2.7.1 グループ・フェイルバックと「優先所有者ノード」リスト

クラスタ上にグループを作成する際に、グループ・フェイルオーバーおよびフェイルバックの「優先所有者ノード」リストを作成します。クラスタ内のノードが2つの場合、このリストをフェイルバックのみに指定します。順序付けられたノードのリストを作成して、グループを優先的に実行するノードを指定します。以前に使用不可だったノードが再度オンライン化されると、クラスタ・ソフトウェアはクラスタ上の各グループの「優先所有者ノード」リストを読み込み、オンライン化されたこのノードがいずれかのグループの優先所有者ノードであるかどうかを判断します。「優先所有者ノード」リスト中で、再オンライン化されたノードの順位が、現在グループが常駐しているノードよりも上位である場合、グループは再オンライン化されたこのノードにフェイルバックされます。

たとえば4つのノードからなるクラスタで、My_Groupというグループについて次のような「優先所有者ノード」リストを指定するとします。

- ノード1

- ノード4

- ノード3

ノード1がオフライン化されたため、My_Groupはノード4にフェイルオーバーし、現在そこで稼働中であると仮定します。ここでノード1が再オンライン化されます。クラスタ・ソフトウェアがMy_Group(およびクラスタ上の他の全グループ)の「優先所有者ノード」リストを読み込み、My_Groupの優先所有者ノードがノード1であることが検出されます。フェイルバックが有効であれば、My_Groupはノード1にフェイルバックされます。

My_Groupが現在ノード3で稼働中(ノード1もノード4も使用不可なため)であり、ノード4が再オンライン化された場合、フェイルバックが有効であればMy_Groupはノード4にフェイルバックします。この後でノード1が使用可能になった場合、My_Groupは再び、今度はノード1にフェイルバックします。「優先所有者ノード」リストを指定する際には、フェイルバックが不必要に何度も発生しないように注意してください。ほとんどのアプリケーションで、「優先所有者ノード」リストのノードは2つあれば十分です。

グループが、あるノードに手動で移動された場合、予期しない結果になります。すべてのノードが使用可能で、My_Groupは現在ノード3で稼働しているとします(これは、グループの移動操作でMy_Groupをノード3に移動したためです)。ノード4が再起動されると、ノード1(My_Groupの「優先所有者ノード」リストで最上位のノード)が稼働中であっても、My_Groupはノード4にフェイルバックします。

ノードが再オンライン化されると、オンライン化されたそのノードが、「優先所有者ノード」リストの中で、現在各グループが常駐しているノードよりも上位であるかどうかがクラスタ・ソフトウェアによってチェックされます。上位である場合、そのようなグループはすべて、再オンライン化されたノードに移動されます。

グループの「優先所有者ノード」リストによるフェイルオーバーへの影響の詳細は、2.6.10項を参照してください。

2.7.2 フェイルオーバー後のクライアントの再接続

ノードの障害は、次のユーザーおよびアプリケーションにのみ影響します。

- 障害発生ノードがホストになっているアプリケーションに、直接接続しているもの

- ノードの障害発生時にトランザクション処理中であったもの

多くの場合、障害発生ノードに接続していたユーザーおよびアプリケーションは接続を失うことになり、処理を継続するためにはフェイルオーバー・ノードに(ノードに依存しない仮想アドレスを通じて)再接続する必要があります。データベースの場合、障害発生時に処理中だった未コミット・トランザクションは、ロールバックされます。透過的アプリケーション・フェイルオーバーが構成されているクライアント・アプリケーションではサービスが短時間中断され、クライアント・アプリケーションからはノードが即時に再起動されたように見えます。サービスはフェイルオーバー・ノードで自動的に再起動されます。オペレータの介入は必要ありません。

透過的アプリケーション・フェイルオーバーの詳細は、8.9項を参照してください。

3 Oracle Fail Safeソリューションの設計

Oracle Fail Safeには多数の構成オプションがあり、各自のアーキテクチャ要件またはフェイルオーバー要件に対応します。

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

- 構成のカスタマイズ

- クライアントとアプリケーションの統合

3.1 構成のカスタマイズ

可用性の高いソリューションは、次の構成を使用してデプロイできます。

- アクティブ/パッシブ構成

- アクティブ/アクティブ構成

作業をクラスタ・ノード間で割り当てる方法はそれぞれの構成で異なりますが、次に示すことは両方の構成に共通しています。

- 1つ以上のOracleホームが、各ノードのプライベート・ディスク(通常はシステム・ディスク)に作成されます。

- Oracle製品の実行可能ファイルがすべて、各ノードのOracleホームにインストールされます。

- 可用性を高めようとするアプリケーションで必要なすべてのデータファイル、構成ファイル、ログ・ファイル、HTMLファイルなどはクラスタ・ディスク上に置かれるため、各クラスタ・ノードからアクセスが可能です。

Oracle Fail Safeソフトウェアは、適切な構成とフェイルオーバーを保証するために、必要に応じて1つ以上のクラスタ・ノードで自動的に実行されます。

図1-4に、クラスタをOracle Fail Safeで構成した場合のソフトウェアおよびハードウェア・コンポーネントを示しています。

3.1.1 アクティブ/パッシブ構成

アクティブ/パッシブ構成では、1つ以上のノードがクラスタ全体の作業負荷のホストになりますが、1つのノードが(スタンバイ・サーバーとして)アイドル状態を維持し、アプリケーションを実行しているノードで障害が発生した場合に処理を引き継ぐために待機します。このソリューションでは、フェイルセーフな作業負荷のパフォーマンスがフェイルオーバーの前後で同じになります。

図3-1は、ノード1にOracle Databaseを置き、ノード2をスタンバイ・サーバーとした2ノードの構成です。現在、ノード2では何も実行されていません。フェイルオーバーの際、ノード2はノード1の作業負荷を引き継ぎます。

図3-1 2ノードのアクティブ/パッシブ(スタンバイ)構成

「図3-1 2ノードのアクティブ/パッシブ(スタンバイ)構成」の説明

図3-2は、ノード1、ノード2およびノード3にOracle Databaseを置く4ノードの構成です。ノード4はスタンバイ・ノードです。現在、ノード4では何も実行されていません。フェイルオーバーの際、ノード4はフェイルオーバーの作業負荷を引き継ぎます。

図3-2 4ノードのアクティブ/パッシブ(スタンバイ)構成

「図3-2 4ノードのアクティブ/パッシブ(スタンバイ)構成」の説明

パッシブのスタンバイ・ノードにはそれ自体の作業負荷がないため、アクティブ/パッシブ構成は最高速のフェイルオーバー構成です。

3.1.2 アクティブ/アクティブ構成

アクティブ/アクティブ構成では、各ノードがアプリケーション処理作業を共有し、障害発生時には他のノードのバックアップも行います。1つのノードに障害が発生した場合、別のノードが障害ノードからフェイルオーバーされたアプリケーションやサービスのみでなく、それ自体のアプリケーションおよびサービスも実行します。アクティブ/アクティブ構成は、アクティブ/パッシブ構成よりもコスト効率に優れています。この構成では、柔軟なアーキテクチャによって業務上の要求に最も合うように作業負荷を分割できます。

図3-3は、両方のクラスタ・ノードでOracle Databaseが稼働する、2ノードのアクティブ/アクティブ構成を示しています。また、汎用サービスがノード1で実行されています。図3-3では、ノード1でマーケティング用にOracle Databaseが1つ使用され、ノード2でも販売用にOracle Databaseが1つ使用されます。ノード1が所有するクラスタ・ディスクにはマーケティング・ファイルが格納され、ノード2が所有するクラスタ・ディスクには販売ファイルが格納されています。

図3-3 アクティブ/アクティブ構成

「図3-3 アクティブ/アクティブ構成」の説明

アクティブ/アクティブ構成では、通常操作中、すべてのノードがアクティブにアプリケーションを処理します。この構成では、すべてのノードが動作している場合に優れたパフォーマンス(より効果的なスループット)を実現しますが、フェイルオーバーは低速で、ノードに障害が発生するとパフォーマンスが低下する可能性があります。また、クライアント接続がすべてのノードに分配されます。

作業負荷のバランス調整とは、各システムの通常の作業負荷の大きさを調整することです。すべてのシステムがほぼ上限の能力で稼働している場合、停止した他のシステムの作業負荷を処理するためのリソースはほとんど使用できず、クライアント・システムではフェイルオーバー中およびフェイルオーバー後の応答時間が大幅に遅くなります。速やかに修復できるリソースや、障害システムに置き換えられるリソースがある場合は、片方のクラスタ・ノードが両方の作業負荷を担当する時間は短くなります。実際、停止時間があるよりもアプリケーションの実行速度が遅くなる方がよいという業務もあります。

また、すべてのシステムが(クラスタ中のノード数に応じて)75%から50%より低い能力で稼働する場合、フェイルオーバー後のクライアントへの応答時間は長くなりませんが、通常の状態では1システム全体に相当する分がアイドル状態であり、アクティブ/パッシブ構成とほとんど同じになってしまいます。

Oracle Fail Safeでは、このタイプの構成に伴うパフォーマンス上の問題を回避するような構成が可能です。たとえば、次のようなことが可能です。

- ミッション・クリティカル・アプリケーションに関してのみ、フェイルオーバーを可能にします。

- 各ノードごとに異なるデータベース・パラメータ・ファイルを使用して、フェイルオーバーの後はより少ないシステム・リソースを使用するように設定します。

- 各コンポーネント(Oracle Databaseなど)を、独自のフェイルオーバー・ポリシーおよびフェイルバック・ポリシーを持つ個別のグループに構成します。
Oracle Fail Safeでは各クラスタ・ノードがいくつかの仮想サーバーのホストになるように構成できるため、このことが可能になります。

- Oracle Fail Safeのスクリプト作成サポート(第6章で説明しているPowerShellコマンドレットを使用)と、システム・モニタリング・ツール(Oracle Enterprise Managerなど)を併用して、ロード・バランスのためのグループ移行を自動化します。

すべてのノードが物理的に同等である必要はありませんが、十分な能力とメモリー、ディスク・ホスト・アダプタおよびディスク・ドライブを持つサーバーを選択し、忙しい時間帯にフェイルオーバーが発生した場合でも十分なレベルのサービスをサポートする必要があります。

3.2 クライアントとアプリケーションの統合

クライアント・アプリケーションをOracle Fail Safe環境で動作させる場合、特別なプログラミングや変更は必要ありません。シングル・ノードのOracleリソースで動作するクライアント・アプリケーションであれば、再コーディングまたは再コンパイル、再リンクをすることなくOracle Fail Safe環境で正常に機能し続けます。これは、クライアントが仮想サーバーを利用してアプリケーションにアクセスできるためです。

第8章に、クライアントとアプリケーションの統合に関連する項があります。第8章では、データベースがクラスタ内の別のノードにフェイルオーバーする場合のクライアントとアプリケーションの透過的なフェイルオーバーの方法について説明します。

4 高い可用性を実現するための管理

Oracle Fail Safeには、Windowsクラスタ環境内でリソースを容易に構成できるという利点があります。この章では、次の項目について説明します。

- フェイルオーバーのリソースの構成

- ウィザード入力項目のOracle Fail Safeでの処理

- クラスタ・セキュリティの管理

- スタンドアロン・リソースの検出

- リソース名の変更

- 複数Oracleホーム環境でのOracle Fail Safeの使用方法

- 複数仮想アドレスを使用する構成

- 既存クラスタへのノードの追加

スタンドアロン・リソースをグループに構成する手順、およびグループに属しているこれらのリソースの管理の詳細は、このマニュアルの第8章、第9章、Oracle Fail Safeのチュートリアルおよびオンライン・ヘルプを参照してください。

4.1 フェイルオーバーのリソースの構成

Oracle Fail Safe Managerのウィザードを使用すると、システム管理者は、最小限の作業で簡単かつ自動的にフェイルオーバーを構成できます。Oracle Fail Safe Managerを使用すると、クラスタ内の1つのノードに障害が起きた場合でも別のクラスタ・ノードが障害ノードのグループ内のリソースを即時に引き継ぐように、リソースをグループごとに構成できます。

ウィザードにより、実装中の構成問題が発生するリスクが最小限に抑えられ、高度なレベルの専門知識がなくても、可用性が高まるようにリソースを構成できます。ウィザードで設定したポリシーの大部分は、Oracle Fail Safe Managerを使用して後から変更できます。

次のリストに、リソースにフェイルオーバーを実装するための、基本的な作業を要約します。最初のタスクを除き、Oracle Fail Safe Managerを使用してこれらのすべてのタスクを実行する必要があります。

1. Oracle Fail Safeとともに構成する製品が適切にインストールされていることを確認します。(これは、『Oracle Fail Safeインストレーション・ガイドfor Microsoft Windows』に記載されています。)

2. Oracle Fail Safe Managerを起動します。

3. クラスタを検証します。

4. 「検証」アクションを使用して、追加するスタンドアロンのOracle Databaseを検証します。

5. グループにリソースを追加します。

6. グループを検証します。

7. クライアント・システムにOracle Netファイル(tnsnames.oraファイルなど)がある場合は、これらのファイルを更新します。

注意:
構成するリソースのタイプによっては、これ以外に手順や注意事項を追加する場合もあります。

Oracle Fail Safe Managerのウィザードを使用するための段階的なガイダンスは、Oracle Fail Safe Managerのチュートリアルおよびオンライン・ヘルプを参照してください。

4.2 ウィザード入力項目のOracle Fail Safeでの処理

ウィザードで必要な情報がすべて収集されると、Oracle Fail Safe ManagerがOracle Fail Safeと対話し(次にそれがMicrosoft Windowsフェイルオーバー・クラスタと対話して)、可用性の高い環境が実現されます。

Oracle Fail Safeでは、ユーザーがウィザードで入力した情報に基づいて、環境の構成に必要な追加情報がすべて導出されます。

同様の手順により、多くのリソースがOracle Fail Safeによって構成されます。Oracle Fail Safeでは、可用性の高いOracle Databaseを構成するために、次の特定の手順を実行します。

1. 仮想アドレスを使用したデータベースへのアクセスを構成します。

1. Oracle Netを、データベースの「可能所有者ノード」リストにあるすべてのノードで仮想アドレスまたは関連付けられたアドレスを使用できるように構成します。(2つのノードからなるクラスタでは、両方のクラスタ・ノードが可能所有者ノードになります。3つ以上のノードからなるクラスタでは、リソースをグループに追加ウィザードのステップとして、リソースの可能所有者ノードを指定します。)

2. ネットワーク構成情報を、「可能所有者ノード」リストのすべてのノードにレプリケートします。

2. 次のようにデータベースを構成します。

1. データベース・リソースが使用するすべてのデータファイルがクラスタ・ディスクに置かれ、他のグループのアプリケーションによって現在使用されていないことを確認します。クラスタ・ディスクが別のグループ内に存在していても、そのグループ内のアプリケーションによって使用されていない場合、Oracle Fail Safeがそのディスクをデータベース・リソースと同じグループに移動します。

2. ウィザードで選択した内容に基づいて、データベース・リソースのフェイルバック・ポリシーを作成します。

3. 次のリソースをグループに移入します。

- クラスタ・グループに使用される各ディスク・リソース

- Oracle Database

- Oracle Netリスナー

3. データベースを追加するグループの可能所有者ノードのそれぞれについて次の処理を、1回に1つずつ行います。

1. 同じ名前のOracleインスタンスをノード上に作成します。

2. データベースをノードにフェイルオーバーして、ノードがデータベースをオンライン化またはオフライン化できることを検証し、フェイルオーバー・ポリシーが機能することを確認します。

4. 「可能所有者ノード」リストのすべてのノードについてフェイルオーバーをテストした後、Oracle Databaseを停止します。「優先所有者ノード」リストでノードが選択されていない場合、グループは構成プロセスの過程で最後に指定したフェイルオーバー先のノードに残ります。

これらの手順を実行することで、Oracle Fail Safeでは、リソースが正しく構成され、またリソース追加先のグループのすべての可能所有者ノードにフェイルオーバーおよびフェイルバックできるようになります。

図4-1に、各ノードがデータベースを伴うグループのホストになる、2ノードのアクティブ/アクティブ・クラスタ構成を示します。

図4-1 Oracle Fail Safe環境内の仮想サーバーとアドレッシング

「図4-1 Oracle Fail Safe環境内の仮想サーバーとアドレッシング」の説明

仮想サーバー(AおよびB)とネットワーク・アドレスは、すべてのクライアントおよびクラスタ・ノードには既知のものです。各クラスタ・ノードのlistener.oraファイルと各クライアント・ワークステーションのtnsnames.oraファイルには、各仮想サーバーの名前とアドレス情報があります。

フェイルオーバーが適切に動作するためには、tnsnames.oraファイルおよびlistener.oraファイル内のホスト名(仮想アドレス)、データベース・インスタンス、SIDエントリおよびプロトコル情報が、グループ内のリソースの可能所有者となる各サーバー・ノードと、クライアント・システムとで一致する必要があります。

たとえば、通常の動作中には、ノードAで仮想サーバーAがアクティブになります。ノードBは仮想サーバーAのフェイルオーバー・ノードです。クラスタ・ディスクは両方のノードと接続しているため、リソースはクラスタのどちらのノードでも稼働しますが、各グループのリソースに対するサービスは、一度に1つのクラスタ・ノードによって提供されます。

ノードAでシステム障害が発生すると、グループ1はノードA上にあったときと同じ仮想アドレスおよびポート番号を使用してノードBでアクティブになります。ノードBはクライアントに対し透過的に、ノードAから作業負荷を引き継ぎ、クライアントは仮想サーバーAを使用してグループ1に、仮想サーバーBを使用してグループ2にアクセスを続けます。クライアントは、グループを処理している物理ノードを考慮せずに、同じ仮想サーバー名およびアドレスを使用してそのグループ内のリソースに対してアクセスを続けます。

4.3 クラスタ・セキュリティの管理

Oracle Fail Safeに関連した管理作業を実行するには、Oracleリソースおよびアプリケーションを管理し、Oracle Fail Safe Managerによる操作を実行する特別な権限が必要です。

表4-1に、Oracle Fail Safe環境で使用するサービスに必要な権限の一覧を示します。詳細は、右端の列に示した項を参照してください。

表4-1 許可と権限

サービス

必要な権限

参照

Oracle Fail Safe

すべてのクラスタ・ノードで管理者権限を持つドメイン・ユーザー・アカウント

4.3.1項

Oracle Fail Safe Manager

すべてのクラスタ・ノードで管理者権限を持つドメイン・ユーザー・アカウント

4.3.2項

Oracle Database

SYSDBA権限を伴うデータベース管理者アカウント

第8.5項

4.3.1 Oracle Fail Safe

Oracle Fail Safeは、2種類のWindowsサービス(Cluster ServiceサービスおよびOracle Fail Safeサービス)からデータベース・リソースにアクセスします。Cluster Serviceサービスは、データベース・リソースDLL関数(データベース・リソースを起動および停止する共通のリソース関数)を実装し、データベースに対して単純なデータベース問合せ(Is Aliveポーリング)を発行することにより、データベース・リソースが適切に機能しているかどうかを判別します。Oracle Fail Safeサービスは、Oracleクラスタ・リソースに関連するOracle Fail Safe ManagerやPowerShellコマンドレットなどのOracle Fail Safeクライアントからのリクエストを処理します。

これらの各サービスは、特定のサービスに対して指定されている「ログオン」ユーザーのコンテキストで実行されます。Oracle Fail Safeサービスは、Oracle Fail Safeのインストール中にOracle Fail Safeのセキュリティ設定ツールに指定されたアカウントで実行されます。Windows Server 2008より前は、Cluster Serviceサービスは、クラスタの構成時に指定されたクラスタ・アカウントで実行されていました。Windows Server 2008以降では、Cluster ServiceサービスはユーザーLocal Systemとして実行されます。

すべてのデータベース接続を適切に認証する必要があるため、Oracle Fail Safeは、データベースへの接続権限を持つコンテキストから実行する必要があります。データベースへのアクセスにオペレーティング・システム認証を使用する場合(データベース・パラメータREMOTE_LOGIN_PASSWORDFILEがNONEに設定されている場合)、Oracle Databaseは、そのサービスのアカウント名を使用してWindowsサービスからアクセスを認証します。Oracle Fail Safeサービスでは、Oracle Fail Safeサービスに指定された「ログオン」アカウントを使用して認証が実行されることを意味します。Cluster Serviceサービスの場合、2008より前のWindows Serverバージョンを使用するインストールでは、クラスタ・アカウントが使用されます。Windows Server 2008以降では、Oracle Fail Safeデータベース・リソースDLLによって、データベースへの接続時にOracle Fail Safeアカウントが暗号化されます。このため、Windows Server 2008以降では、Cluster ServiceサービスがLocal Systemとして実行されている場合でも、データベース・アクセス認証はOracle Fail Safeアカウントを使用して行われます。

Windows Server 2008より前は、Oracle Fail Safeは2種類のユーザー・アカウント(Cluster Serviceサービスに指定されたアカウントと、Oracle Fail Safeサービスに指定されたアカウント)からデータベースにアクセスすることが可能でした。Windows Server 2008以降を使用するシステムでは、オペレーティング・システム認証を使用する場合、Oracle Fail Safeは、Oracle Fail Safeサービスに指定されたアカウントを使用してデータベース・アクセスの認証を試行します。データベース認証の詳細は、8.3.3.4項「データベースの検証」を参照してください。

4.3.1.1 Oracle Fail Safe Serverアカウントの変更

Oracle Fail Safe Serverサービスは、管理者グループのメンバーであるドメイン・ユーザー・アカウントで実行する必要があり、クラスタのすべてのノードにアクセスできます。このアカウントは、クラスタのOracleリソースの構成を変更するためにOracle Fail Safeで使用され、Oracle Fail Safeで管理されるOracle Databaseのアクセスにも使用されます。Oracle Fail Safeのインストール中に、インストール・プロセスによってOracle Fail Safeサーバーで使用されるアカウントおよびパスワードの入力が求められます。Oracle Fail Safeで使用されるアカウントを変更するには、「資格証明の設定」ツールを実行して、Oracle Fail Safeで使用する新しいアカウントを指定します。

Oracle Fail Safeアカウントを変更するには、Windowsの「スタート」メニューから「すべてのプログラム」、Oracle Fail Safeホーム、「資格証明の設定」の順に選択します。導入画面が表示されます。

図4-2に、ユーティリティを説明するOracle Fail Safe Server資格証明のダイアログ・ボックスを示します。

図4-2 Oracle Fail Safe Server資格証明

「図4-2 Oracle Fail Safe Server資格証明」の説明

「継続」をクリックして、新しい資格証明を入力します。

図4-3 Oracle Fail Safe ServerのWindowsセキュリティ設定

「図4-3 Oracle Fail Safe ServerのWindowsセキュリティ設定」の説明

4.3.2 Oracle Fail Safe Manager

Oracle Fail Safe Managerへのログインに使用するアカウントは、(ローカル・アカウントではなく)すべてのクラスタ・ノードに対する管理者権限を持ったドメイン・ユーザー・アカウントである必要があります。

4.4 スタンドアロン・リソースの検出

Oracle Fail Safe Managerのツリー・ビューから「スタンドアロン・リソース」フォルダを選択すると、Oracle Fail Safeによってスタンドアロン・リソースが自動的に検出(特定)され、ツリー・ビューに表示されます。第8章および第9章に、Oracle Fail Safeで可用性を高めるように構成することが可能な各タイプのコンポーネントの検出方法に関する情報が記載されています。

4.5 リソース名の変更

リソースをグループに追加した後、リソース名は変更しないでください。リソース名を変更する必要がある場合は、Oracle Fail Safe Managerを使用してリソースをグループから削除してから、新しい名前でそのリソースをグループに再度追加します。

4.6 複数Oracleホーム環境でのOracle Fail Safeの使用方法

Oracle Fail Safeでは、複数のOracleホームの機能がサポートされています。次のリストに、複数Oracleホーム環境でOracle Fail Safeを使用するための要件を示します。

- Oracle Fail Safeは、すべてのクラスタ・ノード上のいずれか1つのOracleホームにインストールします。ノードにインストールして実行できるのは、Oracle Fail Safeの1つのバージョンにかぎられます。

- 最新リリースのOracle Fail Safe Managerを使用して、複数のクラスタを管理します。各種バージョンのOracle Fail Safe ManagerおよびOracle Fail Safeサーバー・コンポーネントの互換性の詳細は、『Oracle Fail Safeリリース・ノートfor Microsoft Windows』を参照してください。

注意:
複数のリリースのOracle Fail Safe Managerをシステムにインストールできますが、各リリースを異なるOracleホームにインストールする必要があります。

- 可用性が高まるように構成する各リソースは、可能所有者であるすべてのクラスタ・ノード上の同じOracleホームにインストールします。クラスタの「検証」アクションは、この対称性を検証します。クラスタの「検証」アクションの詳細は、7.1.1項を参照してください。

- グループ内のすべてのデータベースおよびリスナーは、同じOracleホームに属している必要があります。
データベースをグループに追加すると、Oracle Netのリスナー・リソースもグループに追加されます。オプションで、Oracle Management Agentリソースをグループに追加できます。詳細は、9.2項を参照してください。

リスナーは、データベースが存在しているのと同じOracleホームに作成されます。

4.7 複数仮想アドレスを使用する構成

Oracle Fail Safe Managerを使用してグループにリソース(汎用サービス以外)を追加するには、あらかじめそのグループに1つ以上の仮想アドレスを追加しておく必要があります。クライアント・アプリケーションは、グループの仮想アドレスの1つによって、そのグループ内のリソースに接続します。

リソースをグループに追加ウィザードを起動して、リソースを追加する前に、グループには最大で32個までの仮想アドレスを追加できます。Microsoft Windowsフェイルオーバー・クラスタ・マネージャで、グループを選択し、画面右側のペインの「Actions」メニューから「Add a Resource」アクションを選択して、仮想アドレス(クライアント・アクセス・ポイントとも呼ばれます)をグループに追加します。

次の制限事項に注意してください。

- グループに少なくとも1つの仮想アドレスを追加していないと、そのグループに別のリソースは追加できません。仮想アドレスが含まれていないグループには、汎用サービス以外は追加できません。

- グループに1つ以上のOracle Databaseが含まれる場合は、次のようにします。

- グループにデータベースを追加する前に、そのグループの1つ以上のデータベースとともに構成するすべての仮想アドレスをグループに追加します。

- グループ内のすべてのデータベースで、グループに追加する最初のデータベースに対して指定する一連の仮想アドレスを使用します。(一連の仮想アドレスには、最低1つのアドレスを含めることができます。)

Oracle Databaseに対する複数仮想アドレスの構成の詳細は、8.3.3.2項を参照してください。

グループに仮想アドレスを追加すると、どのクラスタ・ノードがそのクラスタのホストになっているかにかかわらず、同じネットワーク・アドレスを持つクライアントはそのグループにアクセスできます。

グループ内の複数仮想アドレスによって、柔軟な構成オプションが得られます。たとえば、プライベート・ネットワークを介してデータベースのバックアップ処理を実行している間に、ユーザーがパブリック・ネットワークを介してデータベースにアクセスすることが可能になります。あるいは、異なるネットワーク・セグメント上の異なる仮想アドレスをセキュリティ管理に割り当て、管理者があるセグメント上のデータベースにアクセスする一方で、ユーザーが別のセグメント上のデータベースにアクセスすることも可能です。

グループに複数の仮想アドレスを追加する場合、Oracle Fail Safe Managerにより、そのグループのリソースにアクセスするためにクライアントが使用するアドレスを指定するように要求されます。グループに複数のリソース(たとえば、データベースとカスタム・アプリケーションなど)を追加すると、ユーザーからデータベースに直接アクセスする場合はデータベースへのアクセス専用の仮想アドレスを使用し、ユーザーからカスタム・アプリケーションにアクセスする場合は別の仮想アドレスを使用することができます。また、データベース・ユーザーが多数の場合、一部のユーザーにはある仮想アドレスを使用してデータベースにアクセスさせ、その他のユーザーにはもう1つ別の仮想アドレスを使用させることで、ネットワークのトラフィックを均衡化することが可能になります。

グループへの仮想アドレスの追加の詳細は、Oracle Fail Safe Managerオンライン・ヘルプを参照してください。

4.8 既存クラスタへのノードの追加

ソフトウェアをインストールして新しいノードを既存のクラスタに追加する手順は、『Oracle Fail Safeインストレーション・ガイドfor Microsoft Windows』に記載されています。その作業の完了後に、最終的な手順があります。新しいノードが可能所有者であるクラスタの各グループの「検証」アクションを選択します。

クラスタに新規ノードを追加し、Oracle Fail Safeと、そのノードで実行を予定しているリソースのDLLを、そのノードにインストールするとします。新規のノードは、これらのリソースの可能所有者になります。これらのリソースが新規ノード上で実行するように構成されていない場合、そのリソースを含むグループが新規のノードにフェイルオーバーしても、そのノードではこれらのリソースは再起動しません。

しかし「検証」アクションを実行すると、検証されたグループ内のリソースが、そのグループの可能所有者となっている各ノードで実行するよう構成されているかどうかが、Oracle Fail Safeによってチェックされます。グループ内のリソースが実行するように構成されていない可能所有者ノードが検出されると、Oracle Fail Safeがそれを構成します。

このため、新規のノードが可能所有者としてリストされた各グループについては、「検証」操作を実行することを強くお薦めします。7.1.2項に、「検証」操作を示します。第6章の説明に従って、Oracle Fail Safe PowerShellコマンドレットTest-OracleClusterGroupを使用してグループを検証することもできます。

5 FSCMDコマンドライン・インタフェース

Oracle Fail Safeでは、クラスタ内のリソースを管理する手段として、Oracle Fail Safe Managerに加えて、コマンドライン・インタフェースが提供されます。たとえば、「コマンド プロンプト」でFSCMDコマンドを使用して、Oracleリソースをオフライン化、またはオンライン化できます。FSCMDコマンドは、バッチ・プログラムやスクリプトからOracleリソースを管理する場合に便利です。

注意:
FSCMDインタフェースは、将来のリリースでは廃止になる予定です。第6章で説明しているPowerShellコマンドレットに現在置き換えられています。

FSCMD

Oracle Fail Safe Managerを使用して実行する操作のうちの多くは、FSCMDコマンドによって実行できます。FSCMDコマンドを実行するには、Oracle_Home\Failsafe\Client\fscmd.exeのように、Oracle Fail Safe Managerがインストールされている場所から始まるフルパスを指定してください。

このパスを使用しない場合、Windowsオペレーティング・システムではFSCMDコマンドを検出できません。

書式

FSCMDコマンドを使用するときは、「コマンド プロンプト」ウィンドウを開いて、次の構文を使用したFSCMDコマンドラインを入力します。

FSCMD action name /CLUSTER=cluster-name [qualifier]

注意:
わかりやすくするために、この章では構文および例からFSCMDへのフルパス表記を省略します。

説明

Oracle Fail Safeには、Oracle Fail Safe Managerで実行可能な機能の多くをスクリプトで使用できるFSCMDコマンドがあります。たとえば、FSCMDコマンドを使用して、夜間バックアップを実行する前にクラスタ・リソースをオフライン化し、バックアップの完了後にリソースを再びオンライン化できます。

FSCMDコマンドは、Oracle Fail Safe Managerがインストールされているシステムで実行できます。(FSCMDソフトウェアはOracle Fail Safe Managerのコンポーネントです。)

FSCMDコマンドを実行する場合、長時間実行する操作の結果を取得するログ・ファイルの名前を指定できます。

コマンド・パラメータ

次に、コマンド・パラメータの一部を示します。

action

グループ、リソースまたはクラスタに適用できるアクションを指定します。次の表で説明するアクションのいずれかを使用します。

アクション

説明

DISABLEISALIVE

次のいずれかの操作を行うまで、指定したデータベース・インスタンスのIs AliveポーリングおよびLooks Aliveポーリングを使用不可にします。

- FSCMD ENABLEISALIVEコマンドを使用してIs Aliveポーリングを明示的に使用可能にすること。

- インスタンスをオンライン化すること。

「グループの検証」コマンドでは、あるインスタンスに対してIs Aliveポーリングが使用不可にされていると警告が発行されますが、Is Aliveポーリングを再度使用可能にはできません。

Is Aliveポーリングが使用不可の場合、データベース・ポーリングが使用不可であることを示す警告イベントが、リソースDLLによってWindowsイベント ログに書き込まれます。

DUMPCLUSTER

クラスタ構成情報の出力。この操作による出力は、/LOGFILE修飾子によって指定したファイル名のファイルに書き込まれます。

ENABLEISALIVE

指定したデータベース・インスタンスのIs AliveポーリングおよびLooks AliveポーリングがFSCMD DISABLEISALIVEコマンドにより使用不可にされている場合、それらを使用可能にします。

MOVEGROUP

リソースのグループを/NODEコマンド修飾子によって指定したノードに移動。この操作による出力は、/LOGFILE修飾子によって指定したファイル名のファイルに書き込まれます。

ONLINEGROUP

グループのオンライン化。

ONLINERESOURCE

リソースのオンライン化。

OFFLINEGROUP

グループのオフライン化。

OFFLINERESOURCE

リソースのオフライン化。Oracle Databaseリソースでは、この操作には/OFFLINEコマンド修飾子が必要です。

VERIFYGROUP

Oracle Fail Safeによって構成された単一グループの検証。この操作による出力は、/LOGFILE修飾子によって指定されるファイル名のファイルに書き込まれます。

VERIFYALLGROUPS

Oracle Fail Safeによって構成されたすべてのグループの検証。この操作による出力は、/LOGFILE修飾子によって指定されるファイル名のファイルに書き込まれます。

VERIFYCLUSTER

クラスタ構成の検証。この操作による出力は、/LOGFILE修飾子によって指定されるファイル名のファイルに書き込まれます。

actionパラメータは、FSCMDコマンドに対する第1引数としてください。

name

FSCMDコマンドで処理するリソースまたはグループの名前です。たとえば、PERSONNEL.worldは、シングルインスタンス・データベースのリソースとして有効な名前です。

このパラメータは、actionパラメータの次に指定します。nameパラメータは、DUMPCLUSTER、VERIFYALLGROUPSおよびVERIFYCLUSTERを除くすべてのFSCMDコマンド・アクションに必要です。

コマンド修飾子

次に、コマンド修飾子の一部を示します。

/CLUSTER=cluster-name

FSCMDコマンドを実行するクラスタの名前を指定します。

この修飾子は必須です。

/LOGFILE=file-name

DUMPCLUSTER、MOVEGROUP、VERIFYCLUSTER、VERIFYGROUPまたはVERIFYALLGROUPSアクションの実行時に、長時間実行する操作によって作成されるログ・ファイルの場所を指定します。LOGFILE修飾子を指定しない場合、ログ・ファイルは現行の出力デバイス(一般的にはシステム・コンソール)に書き込まれます。

この修飾子はオプションです。

/NODE=node-name

この修飾子は、MOVEGROUPアクションでのグループの移動先ノード名を指定するときにかぎり使用します。

この修飾子は、MOVEGROUPアクションを指定する場合に必要となります。

/OFFLINE=offline-option

この修飾子は、OFFLINERESOURCEアクションを指定して、Oracleリソースをオフラインにする場合にかぎり使用します。Oracle Databaseでは、次の表にあげたオフライン・オプション・モードの1つを指定しないと、そのリソースはimmediateモード(デフォルト)でオフライン化されます。

モード

説明

abort

データベース・インスタンスを強制終了することにより、データベースを即時に停止します。abortモードによる停止は、次の場合を除いてできるだけ使用を避けてください。

- データベース、もしくはそのアプリケーションの1つが不適切に機能していて、かつimmediate、normalのいずれの停止ノードも作動しない場合。

- データベースをただちに停止する必要がある(たとえば、電源遮断が1分以内に発生することがわかっている)場合。

データベースの再起動時に、データベース・リカバリ・プロシージャが実行されます。

immediate

処理中のSQL文を終了し、コミットされていないトランザクションをロールバックし、ユーザーとのデータベース接続を切断して、データベースを即時に停止します。immediateモードは、リソースをオフライン化するときのデフォルトのモードです。immediateモードの選択は、次の場合を除いてできるだけ避けてください。

- 電源遮断がまもなく発生する場合。

- データベースまたはアプリケーションの1つが不適切に機能している場合。

- データベースのバックアップ処理を実行する場合。

normal

次のようにしてデータベースを停止します。

- データベースの停止コマンド入力後に新規に接続できないようにします。

- データベースを実際に停止する前に、接続中のすべてのユーザーが切断するまで待機します。

transactional

現行のトランザクションがすべて完了した後で、データベースを停止します。

/DOMAIN=domain-name

(/USER修飾子で指定した)ユーザー・アカウントが存在するドメインを指定します。

/PWD=password

/USER修飾子で指定したアカウントのパスワードを指定します。

/USER=username

すべてのクラスタ・ノードで管理者権限を持つドメイン・アカウントのユーザー名を指定します。

使用上の注意

次に、FSCMDコマンドの使用上の注意の一部を示します。

- actionパラメータは、FSCMDコマンドに対する第1引数としてください。

- パーサーでは、コマンド修飾子間のデリミタとしてスラッシュ(/)またはハイフン(-)が認められます。

- コマンド・パラメータおよび修飾子では大文字と小文字が区別されないため、大文字か小文字のいずれか、または両方を組み合せて使用できます。

- グループ名またはリソース名に1つ以上の空白が含まれる場合は、引用符で囲み、たとえば、"Sales Group"のようにします。

- FSCMDユーティリティの認証情報(ドメイン、ユーザー名またはパスワード)はオプションです。認証情報を指定しない場合、そのデフォルトのローカル認証情報を使用してFSCMDによってサーバーへの接続が試行されます。認証をコマンド行に指定しても(ドメイン、ユーザー名またはパスワード)、項目のいずれかがない場合、FSCMDによって存在しない情報の入力が求められます。たとえば、FSCMDコマンドの入力時に/domainと/usernameのスイッチが存在しても、/passwordスイッチが指定されていない場合には、FSCMDによってパスワードの入力が要求されるため、パスワードがコンソールにエコーされません。

- コマンドラインでは、修飾子の間に空白を入力する必要があります。次に、コマンドラインにおける空白の正しい使用例と誤った使用例を示します。
正しい使用例:

FSCMD onlineresource salesdb.world /CLUSTER=ntclu-160 /USER=smith /PASSWORD=smithpwd  /DOMAIN=newengland

誤用例:

FSCMD onlineresource salesdb.world/CLUSTER=ntclu-160/USER=smith/PWD=smithpwd/DOMAIN=newengland
Invalid number of parameters.

- Windowsイベント ビューアを使用して、FSCMDコマンドの処理中に報告されていたイベントを表示します。

コマンドの例

次に、コマンド例の一部を示します。

例1

次のコマンドでは、salesdb.worldというOracle Databaseをオンライン化します。

FSCMD onlineresource salesdb.world /CLUSTER=ntclu-160 /USER=smith /PWD=smithpwd /DOMAIN=newengland

例2

次のコマンドでは、クラスタNTCLU-160上のすべてのグループが検証され、検証操作の出力がログ・ファイルC:\temp\fsverify.logに書き込まれます。

FSCMD verifyallgroups /LOGFILE=c:\temp\fsverify.log /CLUSTER=ntclu-160
/USER=smith /PWD=smithpwd /DOMAIN=ORANT

例3

次のコマンドでは、Oracle Databaseを即時にオフライン化します。

FSCMD offlineresource salesdb.world /CLUSTER=NTCLU-160 /USER=smith
/PWD=smithpwd /DOMAIN=ORANT /OFFLINE=immediate

例4

次のコマンドでは、Disk Group 1というグループをオフライン化します。

FSCMD offlinegroup "Disk Group 1" /CLUSTER=ntclu-160 /USER=smith /PWD=smithpwd /DOMAIN=ORANT

スクリプトの例

次のスクリプトでは、db.worldというデータベースのオンライン・バックアップを実行します。この例では、db.worldデータベースがFS Group1というグループに含まれ、NTCLU-141ノード上のNTCLU-140というクラスタで稼働しているものとします。(データベースのクローズ状態のバックアップを実行する場合、Is Aliveポーリングを使用不可にしてから使用可能にするのではなく、FSCMD offlineresourceコマンドを使用して手順2でデータベース・リソースをオフライン化し、FSCMD onlineresourceコマンドを使用して手順6でオンライン化します。)

REM   This script shows an example of performing an online backup operation
REM   on an Oracle Fail Safe database.
REM
REM   1. Move the group FS Group1 that contains the database to the node on
REM   which the backup operation will run. Alternatively, you can create file
REM   share resources for each cluster disk to let the backup software
REM   access the drives through a virtual server address regardless of which
REM   cluster node currently owns them.

fscmd movegroup "FS Group1" /node=NTCLU-141 /cluster=NTCLU-140 /USER=smith
/PWD=smithpwd /DOMAIN=ORANT

REM   2. Disable Is Alive polling for the database resource. This step allows
REM      you to keep the database online during the backup operation, but
REM      prevents Oracle Fail Safe from attempting to fail over the database
REM      during the online backup operation.

fscmd disableisalive db.world /cluster=NTCLU-140 /USER=smith /PWD=smithpwd /DOMAIN=ORANT

REM   3. Mark the beginning of the online tablespace backup operation for each
REM      database tablespace. In this example there are two tablespaces, users
REM      and indx. The database must be in ARCHIVELOG mode to back up the
REM      tablespaces. (If you use Recovery Manager (RMAN) for the online
REM      backup operation, you are not required to mark the beginning
REM      and end of the tablespace backup operations, nor would you copy the
REM      database files, as described in steps 3, 4, and 5.)

SQL> ALTER TABLESPACE users BEGIN BACKUP;
SQL> ALTER TABLESPACE indx BEGIN BACKUP;

REM   4. When you are certain the previous operations have completed, begin the
REM      backup operation. As an example, the following lines
REM      copy files using the copy function of the operating system.

copy e:\ofsdb\ofs1\data\*.ora e:\backup\data
copy e:\ofsdb\ofs1\log\*.ora e:\backup\log
copy e:\ofsdb\ofs1\param\*.ora e:\backup\param

REM   5. Indicate the end of the online backup operation of each tablespace.

SQL> ALTER TABLESPACE users END BACKUP;
SQL> ALTER TABLESPACE indx END BACKUP;

REM   6. Reenable Is Alive polling for the database resource.

fscmd enableisalive db.world /cluster=ntclu-140 /USER=smith /PWD=smithpwd /DOMAIN=ORANT

REM   The backup operation is complete.

6 PowerShellコマンド

Windows Server 2008 R2で、Microsoft社は、フェイルオーバー・クラスタを管理する優先スクリプト・ツールとして一連のフェイルオーバー・クラスタのPowerShellコマンド(コマンドレット)を導入しました。PowerShellは、Microsoft社が提供する新しいコマンドおよびスクリプト言語であり、過去に使用された古いコマンド(CMD)環境と置き換わります。新しいフェイルーバー・クラスタ・コマンドレットは、将来のリリースのWindows Serverで使用できなくなる可能性がある古いコマンドライン・ユーティリティCLUSTER.EXEと置き換わります。オラクル社では、古いFSCMD.EXEユーティリティも置き換える新しい一連のPowerShellコマンドレットを提供しています。

PowerShellコマンドレットは、Windows Server 2008 R2などのサーバー・システムまたはWindows 7などのクライアント・システムで使用される可能性があります。フェイルオーバー・クラスタ機能がシステムに追加されると、Microsoftフェイルオーバー・クラスタ・コマンドレットがサーバーに追加されます。Microsoft社の使用可能なリモート・サーバー管理ツール・パッケージをインストールして、フェイルオーバー・クラスタ・コマンドレットをクライアント・システムに追加できます。Oracle Fail Safeコマンドレットは、Oracle Fail Safe Managerインストール・コンポーネントの一部としてインストールされます。

6.1 開始

注意:
Windows Server 2008 R2から、Windows PowerShellがすべてのWindows Serverシステムにデフォルトでインストールされます。Windows Server 2008 R2より前のシステムには、PowerShellを手動でインストールする必要があります。

すでにPowerShellがインストールされているシステムで基本PowerShellセッションを開始するには、「スタート」、「すべてのプログラム」、「アクセサリ」、「Windows PowerShell」の順にクリックして、最後に「Windows PowerShell」をダブルクリックします。これにより、標準コマンドレットがロードされた基本PowerShellセッションが開始されます。

関連するコマンドレットのグループは、モジュールと呼ばれるコンテナにパッケージ化されています。フェイルオーバー・クラスタに固有のコマンドレットを使用する前に、Import-Moduleコマンドレットを使用してPowerShellセッションにロードします。次のコマンドを使用して、フェイルオーバー・クラスタ・モジュールをロードします。

PS C:\Users\admin> Import-Module FailoverClusters

PowerShellモジュールには、含まれるコマンドの説明へのリンクも含まれます。モジュールをロードした後、モジュールに含まれるコマンドレットを確認して、各コマンドレットを説明するヘルプ・テキストを表示します。

たとえば、FailSafeモジュールで提供されるコマンドレットを確認するには、次のコマンドを入力します。

PS C:\Users\Admin> Get-Command -Module FailSafe

CommandType      Name                            Definition
-----------      ----                            ----------
Cmdlet           Add-OracleClusterResource       Add-OracleClusterResource [[...
Cmdlet           Get-OracleClusterResource       Get-OracleClusterResource [[...
Cmdlet           Remove-OracleClusterResource    Remove-OracleClusterResource...
Cmdlet           Stop-OracleClusterDatabase      Stop-OracleClusterDatabase [...
Cmdlet           Test-OracleCluster              Test-OracleCluster [[-Name] ...
Cmdlet           Test-OracleClusterAvailableD... Test-OracleClusterAvailableD...
Cmdlet           Test-OracleClusterGroup         Test-OracleClusterGroup [[-N...

文字列「cluster」を含むすべてのコマンドレットの基本情報を取得するには、次のコマンドを使用します。

PS C:\Users\Admin> Get-Help cluster

Name                              Category  Synopsis
----                              --------  --------
Add-OracleClusterResource         Cmdlet    Adds an Oracle resource to a fai...
Get-OracleClusterResource         Cmdlet    Gets an Oracle resource object
Remove-OracleClusterResource      Cmdlet    Removes an Oracle cluster resour...
Stop-OracleClusterDatabase        Cmdlet    Stops an Oracle database
Test-OracleCluster                Cmdlet    Verifies the installation and co...
Test-OracleClusterAvailableDat... Cmdlet    Verifies the configuration of an...
Test-OracleClusterGroup           Cmdlet    Verifies the configuration of Or...
Add-ClusterDisk                   Cmdlet    Make a new disk available for us...
Add-ClusterFileServerRole         Cmdlet    Create a clustered file server (...
.
.
.

特定のコマンドレットに固有の情報を取得するには、コマンドレット名にGet-Helpを指定します。

例6-1 Get-OracleClusterResource

PS C:\Users\Admin> Get-Help Get-OracleClusterResource

NAME
Get-OracleClusterResource

SYNOPSIS
Gets an Oracle resource object.

SYNTAX
Get-OracleClusterResource [[-Name] <String>] [-Available] [-InputObject <PS
Object>] [-Cluster <String>] [-Credential <PSCredential>] [<CommonParameter
s>]

DESCRIPTION
This cmdlet will return an Oracle cluster resource object or objects based
on the input provided.

RELATED LINKS
Add-OracleClusterResource
Remove-OracleClusterResource
Test-OracleClusterAvailableDatabase
Stop-OracleClusterDatabase

REMARKS
To see the examples, type: "get-help Get-OracleClusterResource -examples".
For more information, type: "get-help Get-OracleClusterResource -detailed".
For technical information, type: "get-help Get-OracleClusterResource -full".

6.2 共通パラメータについて

Oracle Fail Safeコマンドレットは、同じ操作のOracle Fail Safe Manager進行状況ダイアログ出力ボックスに示される同じ進行状況情報を表示します。ただし、出力を表示するには、-Verboseスイッチを指定する必要があります。

PS C:\Users\Admin > Test-OracleClusterGroup “Test Group” -Verbose
VERBOSE: FS-10371: FSWIN3 : Performing initialization processing
VERBOSE: FS-10371: FSWIN4 : Performing initialization processing
VERBOSE: FS-10373: FSWIN3 : Determining owner node of resource
.
.
.

別のクラスタでコマンドレットを実行するには、-Clusterパラメータをコマンドに追加する必要があります。Oracle Fail Safe ManagerコンポーネントのみインストールしているWindowsクライアント・システムでコマンドレットを実行するには、これは必須です。たとえば、「FinanceCluster」というクラスタのOracleクラスタ・リソースを表示するには、次のコマンドを使用します。

PS C:\Users\Admin > Get-OracleClusterResource -Cluster FinanceCluster

Name                          State                         Group
----                          -----                         -----
OracleOraDb11g_home1TNSLis... Online                        Receivables
OracleOraDb12c_home1TNSLis... Online                        Payables
ReceivablesDb                 Online                        Receivables
PayablesDb                    Online                        Payables

一部のコマンドは、パイプライン入力として使用されません。このため、これらのコマンドの実行は、オブジェクトをパイプラインに送信しません。ターゲット・オブジェクトを出力パイプライン・ストリームに強制的に書き込むコマンドには、-PassThruスイッチを使用します。たとえば、次のコマンドはオブジェクトをパイプラインに送信しません。

PS C:\Users\Admin> Get-ClusterGroup | Test-OracleClusterGroup

-PassThruスイッチを追加すると、クラスタ・グループ・オブジェクトがパイプラインに強制的に送信されます。

PS C:\Users\Admin> Get-ClusterGroup | Test-OracleClusterGroup -PassThru

Name                                    OwnerNode
----                                    ---------
Test Group                              Node1
Cluster Group                           Node2
Available Storage                       Node2

6.3 スクリプトのOracle Fail Safeコマンドレットの使用

一部のOracle Fail Safeコマンドレットでは、続行する前にユーザーに確認を求めます。たとえば、Test-OracleClusterAvailableDatabaseコマンドレットは、指定されたデータベース・インスタンスが実行されていないことを検出し、インスタンスを起動できるかどうかを尋ねます。これは対話セッションで問題ありませんが、スクリプトを実行する際に確認プロンプトがスクリプトの次のコマンドラインを受け取り、スクリプトでエラーが生じることがあります。PowerShellは、この状況に対応する別の方法を提供します。プロンプトを回避する1つの方法は、コマンドで-Confirm:$falseパラメータを指定します。この修飾子が存在する場合、確認プロンプトは表示されず、コマンドレットが中断せずに続行します。次の例では、最初のコマンドは確認プロンプトを表示し、-Confirm:$falseを含む2番目のコマンドはデータベースが起動しているかどうかユーザーに尋ねずに続行します。

PS C:\Users\Admin> Test-OracleClusterAvailableDatabase TestDb
WARNING: FS-10349: Database instance OFS3 is not alive. Do you want to stop and
restart the database instance?

Confirm
Are you sure you want to perform this action?
Performing operation "Test-OracleClusterAvailableDatabase" on Target "TestDb".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is
"Y"): N
WARNING: FS-10340: Database instance OFS3 is not started and therefore cannot be
fully verified.
PS C:\Users\Admin> Test-OracleClusterAvailableDatabase TestDb –Confirm:$false

確認プロンプトを回避する別の方法は、デフォルトのレスポンス変数$ConfirmPreferenceを設定します。この変数を確認が必要な最下位レベルに設定できます(「high」、「medium」、「low」または「none」)。たとえば、ほとんどのOracle Fail Safeコマンドレットは、システム操作に大きな影響を与えます。そのため、Oracle Fail Safeコマンドレットを自動的に確認するには、次に示すように$ConfirmPreference変数を「none」に設定する必要があります。

PS C:\Users\Admin> $ConfirmPreference=”none”
PS C:\Users\Admin> Test-OracleClusterAvailableDatabase TestDb

Stop-OracleClusterDatabaseコマンドなどの一部のコマンドでは、続行する前に常に確認を求められます。このコマンドレットは、確認プロンプトを回避するために使用できる-Forceスイッチを提供します。

PS C:\Users\Admin> Stop-OracleClusterDatabase TestDb -Force

6.4 FSCMD等価コマンドレット

次の表は、同じタスクを実行するために使用できるFSCMD.EXEコマンドおよびOracle Fail Safe PowerShellコマンドレットを示しています。

FSCMD.EXEコマンド

PowerShellコマンド

DISABLEISALIVE

(Get-OracleClusterResource <db name>).IsAliveEnabled=$false

ENABLEISALIVE

(Get-OracleClusterResource <db name>).IsAliveEnabled=$true

MOVEGROUP

Move-ClusterGroup

OFFLINEGROUP

Stop-ClusterGroup

OFFLINERESOURCE

Stop-ClusterResource or Stop-OracleClusterDatabase

ONLINEGROUP

Start-ClusterGroup

ONLINERESOURCE

Start-ClusterResource

VERIFYALLGROUPS

Get-ClusterGroup|Test-OracleClusterGroup

VERIFYCLUSTER

Test-OracleCluster

VERIFYGROUP

Test-OracleGroup

6.5 例

オペレーティング・システム(OS)認証がクラスタまたはデータベースに対して有効になっていない場合、データベースのユーザー名およびパスワードを提供する必要があります。Test-OracleClusterAvailableDatabaseコマンドレットは、データベースSYSアカウントのパスワードを指定する-SysPwdパラメータを提供します。Read-Hostコマンドレットを実行してパスワードがユーザーから取得されることに注意してください。

PS C:\Users\Admin> Test-OracleClusterAvailableDatabase TestDb -SysPwd (Read-Host
-AsSecureString -Prompt ”SYS Password”)
SYS password: ****

Oracleリソースを追加する場合、リソース・タイプによっては、ユーザー名およびパスワード・プロパティがない場合があります。データベース・リソースでは、OS認証を使用していない場合、クラスタ・グループに追加する前にユーザー名およびパスワードをリソースに設定する必要があります。

PS C:\Users\Admin> $testdb = Get-OracleClusterResource TestDb -Available
PS C:\Users\Admin> $testdb.UserName="SYS"
PS C:\Users\Admin> $testdb.Password=Read-Host -AsSecureString -Prompt "SYS
Password"
SYS Password: ****
PS C:\Users\Admin> $testdb | Add-OracleClusterResource -Group FsTutorial

PowerShellのパイプライン機能を使用して、各種コマンドを結合できます。

次の例では、すべてのOracleリソースが最初にフェッチされ、次にデータベースがリストから選択され、最後にimmediateモードを使用してデータベースが停止されます。

PS C:\Users\Admin> Get-OracleClusterResource |
>> where {($_.Type -ieq "Oracle Database")} |
>> Stop-OracleClusterDatabase -Mode Immediate –Force

7 アクションの検証

この章では、Oracle Fail Safe Managerの検証プロセスの一般的な情報を説明します。この章では、次の項目について説明します。

- 操作の検証

- クラスタのダンプ

- その他のトラブルシューティング情報の入手

Oracle Fail Safeには一元化されたメッセージ機能が備わっています。ある操作を実行した結果、エラーが発生すると、システムはエラーに対応するメッセージを検索し、そのメッセージを表示します。『Oracle Fail Safeエラー・メッセージfor Microsoft Windows』マニュアルでこれらのメッセージの詳細を確認してください。

7.1 操作の検証

Oracle Fail Safeには、ノード、グループおよびリソース状況の有効性を検証して、クラスタのコンポーネントおよび環境の有効性を検証する便利なツール・ファミリがあります。不一致や問題が検出されると、検証操作により適切な処置がとられ、実際に発生した問題や潜在的な問題をすべて修正します。

検証コマンドを使用して、いつでも、クラスタ、グループまたはスタンドアロン・データベースの有効性を検査します。検証中に問題が検出された場合、Oracle Fail Safeによって、問題を修正するようにプロンプトが出されるか、または問題を詳しく説明したエラー・メッセージが返されます。

いずれかの検証コマンドを実行したときにエラーが返された場合は、エラーを修正し、検証コマンドを再実行します。検証操作がエラーなしで実行されるまで、このプロセスを繰り返します。

7.1.1 クラスタの検証

「検証」クラスタ・アクションにより、クラスタのインストールおよびネットワーク構成の有効性が検査されます。クラスタの検証はいつでも実行できます。リストから検証するクラスタを選択し、「クラスタ」ビューの「アクション」メニューから「検証」を選択します。

Oracle Fail Safeソフトウェアのインストールまたはアップグレード後、初めてクラスタに接続する際に、「検証」を実行するように求められます。「検証」アクションはいつでも実行できますが、クラスタ構成を変更したときは必ず実行する必要があります。「検証」アクションでは、次のことを検証します。

- OracleソフトウェアがインストールされているOracleホームの名前が、すべてのクラスタ・ノードに共通であること
たとえば、あるクラスタ・ノードのOracle Fail SafeソフトウェアのOracleホームの名前がOFSである場合、Oracle Fail Safeがインストールされているクラスタ内のすべてのノードでOFSというOracleホーム名が使用されている必要があります。同じように、あるクラスタ・ノードのOracle DatabaseソフトウェアのOracleホームの名前がOfsDbである場合、Oracle Databaseソフトウェアがインストールされているクラスタ内のすべてのノードでOfsDbというOracleホーム名が使用されている必要があります。

- Oracle Fail Safeのリリースが、すべてのノードで同じであること

- リソース・プロバイダ(コンポーネント)が各リソースの少なくとも2つの可能所有者であるノードでまったく同じに構成されていること

また、「検証」は、OracleリソースDLLをMicrosoft Windowsフェイルオーバー・クラスタに登録します。また、クラスタ構成変更のいずれかが変更される場合、Microsoft Windowsフェイルオーバー・クラスタ・マネージャのValidate Clusterウィザードを実行して、クラスタ構成がまだ有効であることを確認することをお薦めします。

図7-1に、典型的な「検証」アクションの出力を示します。

図7-1 クラスタを検証中の進行状況ウィンドウ

「図7-1 クラスタを検証中の進行状況ウィンドウ」の説明

「検証」操作を実行しても正常に終了しない場合、次に示すいずれか1つまたは複数の問題があると考えられます。

- 問題は、ハードウェア、ネットワークまたはMicrosoft Windowsフェイルオーバー・クラスタの構成にあります。

- Oracleホームおよびバージョンの対称性の問題。

- Oracle Fail Safeのインストール(たとえば、リソース・プロバイダの対称性)の問題。

操作が正常に終了していながらOracle Fail Safeで問題が発生する場合、Oracle Fail Safeの構成に問題があります。

7.1.2 Oracleリソースの構成の検証

「検証」アクションによって、グループが正常に動作することを確認するために次のことが行われます。

- グループ内のすべてのリソースをチェックし、グループの可能所有者であるすべてのノードで正しく構成されていることを確認します。

- グループ内のリソース間の依存性を更新します。

- プロンプトを表示した後で、構成の誤りのあるグループを修正します。

いつでも「検証」操作を実行できます。ただし、次の状況が発生した場合は、必ず実行してください。

- グループまたはグループ内のリソースがオンライン化されない場合。

- フェイルオーバーまたはフェイルバックが予定どおりに実行されない場合。

- クラスタにノードを追加する場合。

グループを選択して、「クラスタ」ビューの「アクション」メニューから「検証」を選択します。

または、PowerShellコマンドレットのTest-OracleClusterGroupコマンドを使用して、「検証」アクションを実行できます(第6章を参照してください)。Test-OracleClusterGroupコマンドは、スクリプト内でバッチ・ジョブとして実行できます。

Oracle Fail Safeのグループ検証の際、「検証」アクションの進捗状況、グループ内の各リソースの状態を表示できます。

図7-2に、「検証」アクションの出力を示します。

図7-2 グループを検証中の進行状況ウィンドウ

「図7-2 グループを検証中の進行状況ウィンドウ」の説明

7.1.3 スタンドアロン・データベースの検証

「検証」アクションを選択して、いつでもスタンドアロン・データベースを検証できます。「使用可能なOracleリソース」リストからデータベースを選択して、「検証」アクションを実行します。

「検証」操作では、有効性検査を実行し、スタンドアロン・データベースが常駐するノード上に正しく構成されているかどうかを確認して、もう一方のクラスタ・ノードに存在するデータベースへの参照を削除します。(データベースが、一度グループに追加された後で削除されたものである場合、別のクラスタ・ノードにデータベースへの参照が残っている可能性があります。)これによって、Oracle Fail Safeを使用した可用性の高いデータベースが実現されます。

グループにスタンドアロン・データベースを追加する前に、そのデータベースに対して「検証」コマンドを実行してください。また、スタンドアロン・データベースへのアクセスに問題が生じた場合に、いつでもコマンドを使用できます。ただし、検証操作中、データベースはOracle Fail Safeにより停止および再起動されます。

たとえば、次のような場合に検証を実行します。

- グループにデータベースを追加しようとしたときに障害が発生する場合。

- Oracle Fail Safe Manager以外の管理者ツールを使用してデータベースを処理し、そのデータベースにアクセスできなくなってしまった場合。

- Oracle Fail Safeソフトウェアを削除しないまま、(たとえば、ソフトウェアのアップグレード中に)クラスタ・ノードからMicrosoft Windowsフェイルオーバー・クラスタを削除した場合。この詳細は、『Oracle Fail Safeインストレーション・ガイドfor Microsoft Windows』を参照してください。

図7-3に、クラスタワイド操作ウィンドウに表示される一般的な「検証」操作の出力を示します。

図7-3 スタンドアロン・データベースを検証中の進行状況ウィンドウ

「図7-3 スタンドアロン・データベースを検証中の進行状況ウィンドウ」の説明

スタンドアロン・データベースを検証するには、次の手順を実行します。

- ウィンドウの左側パネルのツリー・ビューから「Oracleリソース」を選択します。

- 「使用可能なOracleリソース」リストからリソースを選択します。

- ウィンドウの右側パネルの「アクション」メニュー・リストから「検証」アクションを選択します。

- スタンドアロン・データベースを検証中の進行状況ウィンドウが開きます。このウィンドウは、スタンドアロン・データベースに対して実行される様々なテストを示し、エラーが発生した場合にメッセージを表示します。データベースをクラスタ・グループに追加する前に、これらのエラーを解決する必要があります。Oracle Fail Safe Serverで問題を解決できる場合がありますが、変更を行う前に確認が求められます。

この情報をOracle Fail Safeでは次の場合に使用します。

- Oracle Netによるクラスタワイドの問題の修正

- スタンドアロン・データベースがクラスタ・ディスク上に存在するかどうかの確認

- Oracle Fail Safeでデータベースにアクセス可能かどうかの確認

スタンドアロン・データベースがオープンされていると、「検証」アクションを選択してもデータベースは再起動されません。

スタンドアロン・データベースがオープンされていないか、データベースが停止されている場合、Oracle Fail Safeでは、データベース・インスタンスの停止および再起動を行ってよいかどうかをユーザーに確認します。次に、アクセスするためにデータベースがオープンされます。

検証で問題が検出された場合、「検証」アクションでは、問題を修正する前にユーザーに確認します。たとえば、Oracle Netの問題が原因で、グループへのデータベースの追加に失敗した場合を考えます。「検証」アクションを実行してネットワークの問題を修正した後に、データベースをグループに追加します。

7.2 クラスタのダンプ

「ダンプ」クラスタ・アクションでは、クラスタ・データ(クラスタ・ノード数、リソース・タイプ、ネットワーク情報、Oracleホームおよび再起動アクションなど)をウィンドウに表示するようOracle Fail Safeに指示することができます。その後、このデータをファイルに保存できます。このコマンドは、一定期間内にクラスタに対して行われた変更の記録を保持するために定期的に入力(同時に出力を保存)でき、Oracleサポート・サービスの要請に従って、クラスタ環境のスナップショットを作成するために入力する場合があります。

「ダンプ」クラスタ・アクションを選択した際に提示されるデータには、次のものがあります。

- オペレーティング・システムに関連する情報(クォーラム・ディスクの場所など)

- パブリック・ネットワーク情報およびプライベート・ネットワーク情報

- クラスタとともに登録されたリソース

- グループのフェイルオーバー・ポリシーおよびフェイルバック・ポリシー

オプションで、「クラスタのダンプ」のデータをファイルに保存できます。「別名保存」をクリックしてください。

「ダンプ」クラスタ・アクションを実行するには、リストからダンプするクラスタを選択して、リストからダンプするクラスタを選択し、「クラスタ」ビューの「アクション」メニューから「ダンプ」を選択します。

図7-4に、「ダンプ」クラスタ・コマンドの出力のうち、cluster-2クラスタとそのリソースの一部に関する情報部分を示します。

図7-4 クラスタ情報をダンプ中の進行状況ウィンドウ

「図7-4 クラスタ情報をダンプ中の進行状況ウィンドウ」の説明

7.3 その他のトラブルシューティング情報の入手

この章では、Oracle Fail Safe Managerの様々なグループ、クラスタおよびリソースの検証方法について説明します。その他の情報は、次の方法で入手できます。

- 特定のコンポーネントのトラブルシューティングに関する情報は、可用性を高めるためのコンポーネントの構成方法について説明する、第7章から第9章の各章に記載しています。

- Oracle Fail SafeはMicrosoft Windowsフェイルオーバー・クラスタ・ソフトウェアと重なっているため、クラスタ・サービス、インターコネクトおよびハードウェア構成の問題のトラブルシューティングにMicrosoft Windowsフェイルオーバー・クラスタ・ドキュメントを参照する必要がある場合があります。

- Oracle Fail Safeを起動できないときは、Windowsイベント ビューアを起動してアプリケーション・ログを表示します。通常、Oracle Fail Safeにより、問題を識別するイベントのログが取られます。

8 可用性および障害耐久力を高めるためのシングルインスタンス・データベースの構成

Oracle Fail Safeにより、Microsoft Windowsフェイルオーバー・クラスタを使用して構成されたWindowsクラスタで稼働しているシングルインスタンスOracle Database(Oracle Database Standard EditionとOracle Database Enterprise Editionの両方)の可用性が向上します。

シングルインスタンスOracle Databaseの可用性を高めると、1つのクラスタ・ノードが停止または故障した場合でも、別のクラスタ・ノードでデータベースが再起動され、そのデータベースにアクセスするアプリケーションとデータベースとの接続が失われるのはほんの一瞬にすぎません。こうしたフェイルオーバー・イベントの発生後、アプリケーションはTAFによって自動的にデータベースに再接続できるため、フェイルオーバーがユーザーの作業に悪影響を与えることはありません。

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

- スタンドアロン・シングルインスタンス・データベースの検出

- スタンドアロン・シングルインスタンス・データベースのためのOracle Net構成

- シングルインスタンスOracle Databaseのグループへの追加

- Oracle Netリスナー・リソースの作成および構成について

- シングルインスタンス・データベースのセキュリティ要件

- シングルインスタンス・データベース・リカバリの最適化

- シングルインスタンス・フェイルセーフ・データベースに対する管理作業の実行

- データベース・ホーム

- 透過的アプリケーション・フェイルオーバー(TAF)の構成

- データベースに関連するエラー処理と問題のトラブルシューティング

8.1 スタンドアロン・シングルインスタンス・データベースの検出

Oracle Fail Safe Serverでは、スタンドアロン・シングルインスタンス・データベース(グループの一部ではないデータベース)が検出されてOracle Fail Safe Managerの「使用可能なOracleリソース」リスト内に表示されます。「サンプル・データベースの作成」コマンドを使用して作成したスタンドアロン・シングルインスタンス・データベース(サンプル・データベース)と、他の方法で作成したスタンドアロン・シングルインスタンス・データベースでは、次のように検出の方法が異なります。

- サンプルのスタンドアロン・データベース
サンプルのスタンドアロン・シングルインスタンス・データベースは、Windowsレジストリ内の次のキーを検索することにより検出されます。

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\FailSafe\SampleDB

- その他のスタンドアロン・シングルインスタンス・データベース
その他のスタンドアロン・シングルインスタンス・データベース(「サンプル・データベースの作成」コマンドで作成されていないスタンドアロン・データベース)は、各クラスタ・ノードでtnsnames.oraファイルを解析し、有効なネット・サービス名エントリを検索することにより検出されます。スタンドアロン・シングルインスタンス・データベースは、次の条件が満たされると検出されます。

- クラスタ・ノード上にスタンドアロン・シングルインスタンス・データベースのインスタンスが存在。

- tnsnames.oraファイル内にスタンドアロン・シングルインスタンス・データベースの次のような有効エントリが存在。

- ノード上のデータベース・インスタンスに一致するSID、またはデータベース・パラメータ・ファイル中のサービス名に一致するSERVICE_NAME。

- ホスト名またはIPアドレス(Oracle Fail Safeでは、ネットワーク別名の使用をサポートしていません。)

あるインスタンスに対して有効なネット・サービス名エントリがない場合、インスタンス名はOracle Fail Safe Manager内のデータベース・インスタンスを表す名前になります。

Oracle Fail Safe Managerツリー・ビューのスタンドアロン・シングルインスタンス・データベース(および他のスタンドアロン・リソース)を表示するには、ウィンドウの左側のペインのOracleリソースを選択します。

8.2 スタンドアロン・シングルインスタンス・データベースのためのOracle Net構成

次の項では、スタンドアロン・シングルインスタンス・データベースのためのOracle Netの構成について簡単に説明します。

8.2.1 DBCAにより作成したデータベースのためのOracle Net構成の更新

Oracle Database Configuration Assistant(DBCA)を使用してスタンドアロン・シングルインスタンス・データベースを作成すると、新規データベースの情報が次のようにOracle Net構成に追加されます。

1. DBCAにより、データベースのSID_DESCパラメータがデフォルトのlistener.oraファイル内のデフォルト・リスナーに追加されます。このSID_DESCパラメータは、データベースSID名で構成されます。

2. DBCAにより、データベースのネット・サービス名エントリがデータベースのOracleホームのみのtnsnames.oraファイルに追加されます。このエントリは、SERVICE_NAMEパラメータで構成されます。

DBCAによりOracle Net情報が構成された後、Oracle Fail Safeでは、Oracle Fail Safe Managerの「使用可能なOracleリソース」リストに新規シングルインスタンス・データベースが表示されます。

データベースを作成したクラスタ・ノードに複数のOracleホームがある場合は、新規データベースに対してOracle Fail Safe Managerの「検証」アクションを選択してください。Oracle Fail Safeにより、すべてのOracleホーム内のtnsnames.oraファイルがチェックされます。tnsnames.oraファイルにデータベースのネット・サービス名エントリが含まれていないことが検出されると、そのファイルを更新してよいかどうかを尋ねられます。「はい」を選択すると、Oracle Fail Safeでは新規データベースのネット・サービス名エントリを追加します。

デフォルトのドメイン名の値(たとえば、sqlnet.oraファイルのnames.default_domainパラメータの値)がOracleホーム間で異なる場合は、ネット・サービス名エントリはいくつかのOracleホームからアクセスできなくなります。この問題を解決するには、各Oracleホーム内のtnsnames.oraファイルを編集し、それぞれのOracleホームのデフォルト・ドメイン名をネット・サービス名エントリに追加します。

8.2.2 リスナーの定義

リスナーの定義でシステムのホスト名が使用されている場合、このリスナーはホスト名に関連付けられているIPアドレスのみではなく、ノード上のすべてのIPアドレスでリスニングを行います。これは、後でグループにデータベースを追加する際にリスナーが競合する原因となり、Oracle Fail Safeとともに構成されたリスナーは仮想アドレスでリスニングするよう定義されます。

この問題を回避するために、リスナーにはホスト名ではなくホスト・エントリのノードIPアドレスを使用する必要があります。シングルインスタンス・データベースをグループに追加する際、ホスト・エントリを使用しているリスナーが検出された場合、このエントリを修正してIPアドレスを使用するかどうかが確認されます。修正しないと、「リソースをグループに追加」操作は続行できません。

Oracle Fail Safe環境での無効なエントリの例を次に示します。

LISTENER =
....
(ADDRESS=
(PROTOCOL=TCP)
(HOST=NTCLU-152)
(PORT=1521)
)

Oracle Fail Safe環境での有効なエントリの例を次に示します。

LISTENER =
....
(ADDRESS=
(PROTOCOL=TCP)
(HOST=192.0.2.254)
(PORT=1521)
)

8.2.3 SIDリスト・エントリおよびOracle Databaseソフトウェアへのアップグレード

Oracle Databaseソフトウェアをアップグレードする場合、リスナーもアップグレードする必要があります。旧バージョンのリスナーSIDリストのエントリをメンテナンスするには、次のように、アップグレード先のバージョンのリスナーにエントリを移します。

1. アップグレード元のデータベース・ソフトウェア・リリースに対応するlistener.oraファイルを見つけます。

2. アップグレード元のリスナーのSIDリストにあるSID_DESCエントリをコピーし、アップグレード先のOracle Databaseソフトウェア・リリースに対応するリスナーのSIDリストに追加します。たとえば、更新後のSIDリストは次のようになります。

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME= c:\oracle)
(PROGRAM = extproc)
)
(SID_DESC=
(SID_NAME=ORCL)
)
(SID_DESC=
(SID_NAME=OFS2)
)
)

3. アップグレード元のデータベースのリスナーを停止し、リスナーの起動状態を手動に変更します。

4. アップグレード先のデータベースのリスナーを起動します。
使用中のデータベース・ソフトウェアのリリースに対応するリスナーを使用しない場合、Oracle Fail Safeで次の操作を実行するときに問題が発生します。

- データベース・リソースのグループへの追加

- グループの検証

- データベース・リソースのグループからの削除

8.2.4 複数のリスナーを伴うノードでのOracle Netの構成

Oracle Fail Safeでは、スタンドアロン・データベースのリスナーの検索時に、すべてのOracleホームで定義されたリスナーが検索されます。複数のOracleサーバーが(1つ以上のOracleホームに)インストールされている場合は、複数のリスナーが存在する可能性があります。複数のリスナーがある場合でも、Oracle Fail Safeではスタンドアロン・データベースのリスナーを検索することが可能です。

システムに追加のOracleホームをインストールした後、使用するリスナーの数およびそのシステムで使用するリスナーを決定する必要があります。その後で、次のことを行います。

1. 使用しないリスナーの定義をlistener.oraファイルから削除します。これにより、Oracle Fail Safeで不要なリスナーが検出されなくなります。

2. SIDの同じアドレスで複数のリスナーを実行していないことを確認します。(同じアドレスまたはSIDで別のアクティブ・リスナーが動作中の場合は、Oracleリスナーを起動できません。)

3. 使用するリスナーを起動します。Windowsの「サービス」の「スタートアップ」リストで、これらのリスナーが自動的に起動するように設定されていることを確認します。

スタンドアロン・データベースのリスナーを検索する際、listener.oraファイルに定義されたリスナーの状態によって検索結果が左右されます。Oracle Fail Safeでリスナーを検索する順序は、次のとおりです。

1. 起動しているリスナー。

2. 停止しているリスナー。

3. Windowsサービス定義のないリスナー。

たとえば、データベースの2つのリスナーが、それぞれ別のOracleホームにあるとします。このとき、ホーム1のリスナーは停止しており、ホーム2のリスナーは起動しているとします。Oracle Fail Safeでは、起動しているリスナーを最初に検索するため、システム上の2つのホームを検索するとホーム2のリスナーが検出されます。起動しているリスナーが見つかると、検索を中止します。起動しているリスナーが見つからない場合は、停止しているリスナーを検索し、それでも見つからない場合は、次のリスナー・グループを検索します。

注意:
Oracle Fail Safeのどの操作においても、実行前にスタンドアロン・シングルインスタンス・データベースのリスナーが予定どおりの状態(停止または起動)であることを確認してください。

8.2.5 共有サーバーの構成とスタンドアロン・データベース

可用性が高まるようにデータベースが構成されている場合、Oracle Fail Safeではデフォルト・リスナーの調整を行います。この調整は、スタンドアロン・データベースを含むすべてのデータベースのOracle Net構成に影響を与えます。このため、クラスタ内のデータベースが可用性が高まるように構成されている場合、Oracle Fail Safe環境のすべてのスタンドアロン・データベースのOracle Net構成を調整する必要があります。

スタンドアロン・シングルインスタンス・データベースの共有サーバーの構成がデフォルト・リスナーに依存している場合、データベース・パラメータ・ファイル内にリスナー・パラメータが指定されていません。(デフォルト・リスナーとは、ノードのホスト名、デフォルト・ポート番号およびTCPプロトコルをリスニングするリスナーです。)この場合、Oracle Fail Safeでホスト名ではなくIPアドレスを使用するようにデフォルトのリスナーが変更されると、その構成が機能しなくなります。

次の手順を実行してこの問題を解決します。

1. LOCAL_LISTENERパラメータをデータベース初期化パラメータ・ファイルに追加します。このLOCAL_LISTENERパラメータはOracle Netデフォルト・リスナーのアドレスになるネットワーク名を示します。
データベースのデータベース初期化パラメータ・ファイルを見つけて、そのファイルにLOCAL_LISTENERパラメータを追加します。

LOCAL_LISTENER = network-name

2. Oracle Netデフォルト・リスナーのアドレスを特定します。
データベースのホームのlistener.oraファイルで、デフォルト・リスナーの定義を探します。この定義内で、TCPプロトコルが使用されている最初のアドレスを調べます。

たとえば、デフォルト・リスナーが次のように定義されているとします。

LISTENER =
(DESCRIPTION_LIST=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=192.0.2.1)
(PORT=1521)
)
)
)
)

最初のアドレスは次のとおりです。

(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=192.0.2.1)
(PORT=1521)

3. tnsnames.oraファイルにnetwork-nameエントリを作成します。
手順2で調べたアドレスを使用して、tnsnames.oraファイルにnetwork-nameのエントリを作成します。

この例では、次のようにエントリを作成します。

network-name= (ADDRESS=
(PROTOCOL=TCP)
(HOST=192.0.2.1)
(PORT=1521)
)

この変更は、データベースが再起動された時点で有効になります。

8.3 シングルインスタンスOracle Databaseのグループへの追加

可用性が高まるようにシングルインスタンスOracle Databaseを構成するには、少なくとも1つの仮想アドレスが含まれているグループにデータベースを追加します。Oracle Fail Safeにより、シングルインスタンスOracle Databaseで必要なすべてのリソースが追加されます。通常、このグループには次のリソースが含まれます。

- それぞれが1つのIPアドレスおよびネットワーク名から構成される1つ以上の仮想アドレス

- Oracle Databaseインスタンス

- Oracle Databaseで使用する全ディスク

- グループの仮想アドレス上でグループ内のデータベースへの接続要求をリスニングするOracle Netネットワーク・リスナー

- グループの仮想アドレスを使用するように構成されているOracle Management Agent(データベースの管理にOracle Enterprise Managerが使用される場合)

8.3.1 構成前に

シングルインスタンス・データベースをグループに追加する前に、次のことに注意してください。

- データベース初期化パラメータ・ファイルを除き、シングルインスタンス・データベースにより使用されるファイルはすべて共有クラスタ・ディスク上に置く必要があります。データベース初期化パラメータ・ファイルは、プライベート・ディスクにも共有クラスタ・ディスクにも配置できます。初期化パラメータ・ファイルの配置場所の詳細は、8.3.3.3項を参照してください。

- リソースが属するグループは1つのみです。このため、2つのシングルインスタンス・データベースが同じディスク・ドライブを共有する場合は、この2つのデータベースを同一グループ内に指定する必要があります。

- フェイルオーバーの際、一時表内のデータはフェイルオーバーされません。(ソートやハッシュ結合など)一時表や一時表領域を使用する操作では、フェイルオーバー・ノードで再起動されるときに必要な一時オブジェクトが再作成されます。ただし、一時表内の特定のデータに依存するアプリケーションが正常に機能することを確認する必要があります。
一時表の詳細は、『Oracle Database概要』の一時表に関する説明を参照してください。

- グループには、少なくとも1つの仮想アドレスが含まれている必要があります。

- データベース・サービス名がクラスタ全体で一意になるようにする必要があります。
スタンドアロン・リソースおよびクラスタ・リソースのプロパティがOracle Fail Safe ManagerとOracle Enterprise Managerによって正しく検出され、表示されるようにするには、各リソースにクラスタ内で一意の名前を付ける必要があります。デフォルト値とは異なる名前を指定したり、リソースのデフォルト名を変更したりすることが必要な場合もあります。

8.3.2 構成手順

表8-1に、可用性が高まるようにシングルインスタンスOracle Databaseを構成する際に必要な作業の一覧を示します。各作業の詳細は、オンライン・ヘルプとチュートリアルを参照してください。オンライン・ヘルプにアクセスするには、Oracle Fail Safe Managerウィンドウの右側のペインの「アクション」メニューから「ヘルプ」を選択します。または、Oracle Fail Safe Managerの中央のペインの「Fail Safeドキュメント」を選択し、順を追った詳細な説明は「チュートリアル」の「HTML」または「PDF」バージョンを選択します。

表8-1 データベースを構成する手順

手順

処置

Oracle Fail Safe Managerでの手順

1

Oracle Databaseの可能所有者となるクラスタの各ノードのプライベート・ディスク上に、Oracle Databaseソフトウェアがインストールされていることを確認します。

インストールの情報は、Oracle Databaseのマニュアルを参照してください。

2

グループの作成および1つ以上の仮想アドレスを追加します。

Microsoft Windowsフェイルオーバー・クラスタ・マネージャ・ウィンドウの右側のペインの「Actions」メニューで「Configure a Service or Application」を選択すると、High Availabilityウィザードが開きます。「Select Service or Application」ページから「Other Server」を選択して、「Next」をクリックします。次に、「Client Access Point」ページで、ネットワーク・アドレスを設定して、「Next」をクリックします。この後、「Select Storage」ページのリストからクラスタ・ディスクを選択して、「Next」をクリックします。最後にリソース・タイプを選択し、「Next」を選択して選択内容を確認します。

3

サンプル・データベースを作成(必要な場合)します。

「Oracleリソース」ビューで、画面右側のペインの「アクション」メニューから「サンプル・データベースの作成」アクションを選択します。このサンプル・データベースを使用して、Oracle Fail Safeの機能を本番データベースで使用する前に試すことができます。サンプルは、本番作業用には使用しないでください。

4

スタンドアロン・データベースを検証します。

「使用可能なOracleリソース」リストから検証するリソースを選択し、「Oracleリソース」ビューの「アクション」メニューから「検証」を選択します。この操作では、有効性検査を実行し、スタンドアロン・データベースが常駐するノード上に正しく構成されているかどうかを確認して、もう一方のクラスタ・ノードに存在するデータベースへの参照を削除します。

5

Oracle Databaseをグループに追加します。

「使用可能なOracleリソース」リストから追加するリソースを選択し、「Oracleリソース」ビューの「アクション」メニューから「このリソースをグループに追加」アクションを選択します。これにより、可用性が向上するようにシングルインスタンスOracle Databaseを構成できます。

6

各クライアント・システム上のtnsnames.oraファイルを変更します。

仮想サーバーを認識するようにクライアントを構成します(ネットワーク構成ツールを使用して各クライアント・システム上のtnsnames.oraファイルを変更します)。詳細は、8.4項を参照してください。

8.3.3 Oracle Databaseの構成データ

Oracle Fail Safe Managerには、可用性が向上するようにシングルインスタンスOracle Databaseを構成する際に役立つリソースをグループに追加ウィザードがあります。ウィザードで表示されるページは、現在グループに含まれている仮想アドレスの数と、クラスタ内のノード数によって異なります。

各グループに1つの仮想アドレスが含まれる構成が典型的ですが、複雑な構成では複数の仮想アドレスが含まれる場合もあります。リソースをグループに追加ウィザードを使用して典型的な構成を実行するには、次のデータが必要です。

- サービス名、インスタンス名、データベース名およびデータベース初期化パラメータ・ファイルのファイル指定などのシングルインスタンスOracle Databaseの識別情報

- データベースSYSパスワード

複数の仮想アドレスが含まれているグループにデータベースを追加する場合は、クライアントがデータベースへのアクセスに使用する仮想アドレスを指定するように要求されます。

次の項では、シングルインスタンス・データベースの構成要件について詳細に説明します。

8.3.3.1 ノードの選択

データベースをグループに追加する際に、クラスタが3つ以上のノードから構成されている場合は、図8-1に示すように、選択済ノードのリストを指定して、データベースの可能所有者となるノードを指定するように求められます。特定のノードをデータベースの可能所有者として指定しない場合は、そのノードを「選択済ノード」リストから選択して、左矢印をクリックします。

2.6.7項では、「可能所有者ノード」リストの概念の詳細を説明しています。

図8-1 全ノードが使用可能な場合のリソースをグループに追加ウィザード・ページ

「図8-1 全ノードが使用可能な場合のリソースをグループに追加ウィザード・ページ」の説明

シングルインスタンス・データベースをグループに追加する際に、クラスタが2つ以上のノードで構成されており、そのうちの1つ以上のノードが使用できない場合、どのノードをデータベースの可能所有者とするのかを指定するように求められます。このような場合、図8-2に示すように、ウィザード・ページには使用できないノードが表示されます。

図8-2 使用できないノードがある場合のリソースをグループに追加ウィザード・ページ

「図8-2 使用できないノードがある場合のリソースをグループに追加ウィザード・ページ」の説明

8.3.3.2 仮想アドレスの選択

図8-3に示すように、シングルインスタンス・データベースを追加する対象のグループに複数の仮想アドレスが含まれている場合、クライアントがグループ内のデータベースにアクセスするときにグループ内のどの仮想アドレスを使用するかを尋ねるリソースをグループに追加ウィザードが表示されます。仮想アドレスが1つしか含まれていないデータベースを追加する場合には、このページは表示されません。

図8-3 「リソースをグループに追加」の仮想ホスト・ウィザード・ページ

「図8-3 「リソースをグループに追加」の仮想ホスト・ウィザード・ページ」の説明

Oracle Fail Safeでは、1つのグループに複数の仮想アドレスがサポートされます。グループ内のすべてのデータベースは同じ仮想アドレスを使用する必要があり、グループにデータベースを追加する前に仮想アドレスがグループに追加される必要があります。グループの作成順序は、次のとおりです。

1. グループを作成します。

2. グループに1つ以上の仮想アドレスを追加します。

3. グループに1つ以上のシングルインスタンス・データベースを追加します。

たとえば、グループに2つの仮想アドレスを持つデータベースが含まれ、2番目のデータベースをそのグループに追加する場合、2番目のデータベースは、グループに構成されていた最初のデータベースと同じ仮想アドレスを使用する必要があります。Oracle Fail Safe Managerは、グループに追加したすべてのシングルインスタンス・データベースで同じ仮想アドレスが使用されていることを確認します。

複数の仮想アドレスを持つグループ内にリソースを構成する方法の詳細は、4.7項を参照してください。

8.3.3.3 データベース・パラメータの識別

リソースをグループに追加ウィザードでは、図8-4に示すように、可用性が高まるように構成されるシングルインスタンス・データベースを一意に識別する、データベース・パラメータ情報を入力する必要があります。

図8-4 データベース・パラメータ・ウィザード・ページ

「図8-4 データベース・パラメータ・ウィザード・ページ」の説明

Oracle Fail Safeでは、(たとえば、tnsnames.oraファイルを更新する場合)このデータを使用してデータベースがクラスタ内に構成されます。また、ユーザーが入力したデータがMicrosoft Windowsフェイルオーバー・クラスタに渡され、データはMicrosoft Windowsフェイルオーバー・クラスタに登録されて、データベースがオンラインまたはオフラインになるとき、あるいはIs Aliveポーリングが実行されるときに使用されます。Oracle Fail Safeでは、次の情報が要求されます。

- サービス名
これはネット・サービス名です。この名前は、Oracle Fail Safe Managerのツリー・ビューとMicrosoft Windowsフェイルオーバー・クラスタ・マネージャのツリー・ビューに表示されます。クライアント・アプリケーションでは、この名前を接続リクエストに指定します。

Oracle Netサービス名にドメイン名を指定しない場合、8.4.3.1項で説明するようにOracle Fail Safeによってドメイン名が選択され、ネット・サービス名に追加されます。

- インスタンス名
これはデータベース・インスタンスの名前であり、SIDとも呼ばれます。

- データベース名
これは、初期化パラメータ・ファイル内でデータベースの識別に使用されるdb_nameパラメータです。データベース名は、データベースの作成時に(たとえばSQL CREATE DATABASE文内で)使用された名前です。

- 初期化パラメータ・ファイルの名前と場所
Oracle Databaseの起動時には、初期化パラメータ・ファイルを使用してデータベース名、メモリーの割当て量、制御ファイル名、各種の制限事項、およびその他のシステム・パラメータが指定されます。

通常は、どのクラスタ・ノードがデータベースのホストであるかにかかわらずパラメータ・ファイルにアクセスできるように、パラメータ・ファイルはクラスタ・ディスク上に配置します。ただし、データベースが稼働するように構成されたすべてのクラスタ・ノードの同じ場所に初期化パラメータ・ファイルを置くことが確実な場合は、各ノードのプライベート・ディスクにファイルのコピーを配置することも可能です。また、ホストになっているノードに応じてデータベースに異なるパラメータを設定するために、各ノードのプライベート・ディスクにパラメータ・ファイルを配置することもできます。ノード間でメモリー量または処理能力に差がある場合は、このような方法が有効です。Oracle Database Configuration Assistantを使用して作成したデータベースに対してこの方法を使用する場合は、8.3.3.3.2項に示す注意事項を参照してください。

注意:
可用性が高まるようにデータベースを構成した後、必要に応じて初期化パラメータ・ファイルを移動できます。この操作の実行方法の詳細は、Oracle Fail Safe Managerのヘルプを参照してください。

8.3.3.3.1 パラメータ・ファイルと、SPFILEを使用するデータベース

Oracle Fail Safeでは、「パラメータ・ファイル」フィールドでテキスト初期化パラメータ・ファイル(PFILE)を指定する必要があります。バイナリ・サーバー・パラメータ・ファイル(SPFILE)を、可用性が高まるように構成されたデータベースとともに使用する場合は、SPFILE=SPFILE-locationパラメータを使用して、PFILE内でSPFILEの位置を指定します。たとえば、PFILEに次のようなパラメータを含めることが可能です。

SPFILE=I:\Oracle_Home\admin\oradb\pfile\spfileoradb.ora
REMOTE_LOGIN_PASSWORDFILE=none

(Oracle Fail Safeで使用するPFILE内にSPFILEを指定する場合、そのSPFILEをエクスポートする際には次の事項に注意する必要があります。ファイル指定なしでCREATE PFILE FROM SPFILEコマンドを使用すると、Oracle Fail Safeで使用するPFILEが上書きされます。このため、SPFILEをエクスポートするPFILEには必ず一意のファイル名を指定してください。サーバー・パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。)

8.3.3.3.2 パラメータ・ファイルと、DBCAにより作成したデータベース

Oracle Database Configuration Assistantを使用してデータベースを作成すると、テキスト初期化パラメータ・ファイル(init.ora)がORACLE_HOME\databaseディレクトリに作成されます。このファイルには、IFILEパラメータが含まれます。IFILEパラメータ値は、データベースの初期化パラメータが含まれる別のテキスト初期化パラメータ・ファイルのファイル指定です。

初期化パラメータ・ファイルのIFILEパラメータのファイル指定は、Windowsレジストリ内に格納されます。Oracle Fail Safeでは、デフォルトで、IFILEパラメータを含む初期化パラメータ・ファイルのファイル指定が「パラメータ・ファイル」フィールドに表示されます(「サンプル・データベースの作成」コマンドにより作成したデータベースを除く)。「サンプル・データベースの作成」コマンドにより作成したデータベースの場合、IFILEパラメータで指定する初期化パラメータ・ファイルが「パラメータ・ファイル」フィールドに表示されます。

クラスタ環境では、IFILEパラメータで指定するファイルを「パラメータ・ファイル」フィールドに入力することをお薦めします。これにより、データベース初期化パラメータへの最短アクセスが可能になります。また、この方法を選択せずにパラメータ・ファイルをプライベート・ディスクに置く場合は、必ずIFILEパラメータを含む初期化パラメータ・ファイルとIFILEパラメータで指定するファイルを両方とも各クラスタ・ノードのプライベート・ディスクにコピーしてください。

8.3.3.4 データベースの検証

Oracle Fail Safeのインストールに使用されたアカウントが、データベースに関連付けられたORA_DBAグループまたはORA_SID_DBAグループのいずれかのWindowsオペレーティング・システム・グループにない場合、「認証」ページが表示されます。Oracle Fail Safeのインストールに使用されたアカウントがORA_DBAグループまたはORA_SID_DBAグループにある場合は、オペレーティング・システム認証を使用してデータベースにアクセスできます。アカウントがORA_DBAグループまたはORA_SID_DBAグループのメンバーでない場合は、SYSアカウントを使用してデータベースにアクセスする必要があります。

図8-5に示すように、Oracle Fail Safeでデータベースおよびデータベース・インスタンスにアクセスする際に、オペレーティング・システム認証とSYSアカウントのどちらを使用するかを、このページから指定できます。

注意:
「データベースの認証」ページは、Oracle Fail Safeのインストールに使用されたアカウントが、オペレーティング・システム認証を使用してデータベースにアクセスできるグループのメンバーになっている場合は表示されません。

図8-5 「データベースの認証」ページ

「図8-5 「データベースの認証」ページ」の説明

8.4 Oracle Netリスナー・リソースの作成および構成について

シングルインスタンス・データベースをグループに追加すると、Oracle Fail Safeでは、Oracle Netリスナー・リソースおよびデータベース・リソースがグループに作成および構成されます。データベースがオンライン化すると、Oracle Fail Safeは最初に、リスナー・リソースがオンラインであることを確認します。データベース・リソースのIs Aliveポーリング中に、リスナーを介してデータベースに接続できない場合には、Bequeathプロトコル・アダプタを使用してデータベースに接続します。この障害をユーザーに通知するイベントも記録されます。このイベントが表示される場合、リスナー・リソースをチェックしてください。リスナー・リソースの障害が、データベースへの既存の接続に影響することはありません。ただし、新規のユーザーがデータベースに接続できなくなります。リスナー・リソースは独自の再起動ポリシーを持つため、障害発生時にはクラスタによって自動的に再起動されます。

Oracle Fail Safeでは、データベースと、リスナーに関連付けられたIPアドレス(リスナーそのものではない)との間に依存性を作成します。この依存性は、データベースに接続する前にIPアドレスがオフライン化された場合に、クライアントの応答が停止するという状況を避けるために作成されます。

8.4.1 専用サーバー・モードでの共有ソケットの使用方法

USE_SHARED_SOCKETパラメータをTRUEに設定すると、共有ソケットが使用できるようになります。このパラメータをTRUEに設定すると、ネットワーク・リスナーからデータベース・スレッドにクライアント接続用のソケット記述子が渡されます。その結果、クライアントはデータベース・スレッドへの新しい接続を確立する必要がなくなるため、データベース接続時間が改善されます。また、データベースの接続はすべてネットワーク・リスナーで使用するポート番号を共有するため、サード・パーティ製のプロキシ・サーバーの設定が簡単に行えます。

このパラメータは、TCP/IP環境で専用サーバー・モードを使用する場合にかぎり有効です。

8.4.2 可用性の高いシングルインスタンス・データベースへのクライアント接続

(データベースを含む)ネットワーク・オブジェクトは、ネットワーク・アドレスによって識別されます。クライアントとデータベース間を接続するには、クライアントのtnsnames.oraファイル内のネットワーク・アドレスと、サーバーのlistener.oraファイル内のネットワーク・アドレスが一致している必要があります。つまり、クライアントがネットワーク・アドレスを使用してネットワーク・オブジェクトの特定の場所に接続要求を送ると、受け側は、このアドレス上で要求をリスニングし、クライアント情報と一致するアドレス情報に基づいて接続を許可します。

シングルインスタンス・データベースをグループに追加すると、Oracle Fail Safeでは、データベースが常駐するOracleホーム内にグループのリスナーを作成します。仮想アドレス情報を構成する際、Oracle Fail Safeではデータベースの可能所有者であるクラスタ・ノード上、およびOracle Fail Safe Managerを実行しているクライアント・システム上のすべてのOracleホーム内のtnsnames.oraファイルが更新されます。これによって、Oracle Fail Safeで常に最新の構成でデータベース・インスタンスにアクセスできるようになります。

8.4.3項では、データベースをグループに追加した後で、Oracle Fail Safeでlistener.oraファイルにエントリが作成され、tnsnames.oraファイルが更新されて、どのクラスタ・ノードがデータベースのホストであるかに関係なく、クライアントがデータベースに接続できるようにする方法について説明します。

注意:
Oracle Fail Safeでは、TNS_ADMIN Windows環境変数またはレジストリ・パラメータの使用をサポートしていません。Oracle Fail Safeでは、Oracle_Home\network\adminディレクトリにあるOracle Netファイルの検索および更新は可能ですが、TNS_ADMIN Windows環境変数やレジストリ・パラメータを指定してもこれらは無視されます。

8.4.3 データベースをグループに追加した後のOracle Net構成の更新

次の項で説明するように、シングルインスタンス・データベースをグループに追加すると、Oracle Fail Safeによりtnsnames.oraファイル、listener.oraファイルおよびsqlnet.oraファイル内のデータベースのOracle Net構成が変更されます。

8.4.3.1 Oracle Fail Safeにより行われるtnsnames.oraファイルの更新内容

シングルインスタンス・データベースをグループに追加すると、そのデータベースのtnsnames.oraファイル内のネット・サービス名エントリは、グループの仮想アドレスを使用するように更新されます。ノード上にOracleホームが複数ある場合は、すべてのtnsnames.oraファイルが更新されます。さらに、次のことが行われます。

- Oracle Fail Safeによりネット・サービス名と、SERVICE_NAMEパラメータまたはSIDパラメータが調整されます。
サンプルのシングルインスタンス・データベースを作成、またはグループにシングルインスタンス・データベースを追加する際に、Oracle Netサービス名にドメイン名を指定しない場合、次のようにOracle Fail Safeによってドメイン名が選択され、ネット・サービス名に追加されます。

- Oracle Fail Safeにより、ノード上でバージョンが最も新しいデータベースのOracleホーム内で、デフォルトのドメイン名が検索されます。これが見つかった場合、デフォルトのドメイン名がネット・サービス名に追加されます。たとえば、ノード上で最もバージョンが新しいデータベースはOracle Database 12cであると仮定します。Oracleネット・サービス名にMyDBと指定した場合に、Oracle Database 12cホームでのデフォルトのドメイン名がexample.comであれば、ネット・サービス名はMyDB.example.comとなります。

- ノード上で最もバージョンが新しいデータベースのOracleホームに、デフォルトのドメイン名がない場合、ネット・サービス名には何も追加されません。たとえば、MyDBと指定した場合、ネット・サービス名もMyDBとなります。

どちらの場合もネット・サービス名が決定されると、Oracle Fail Safeによりtnsnames.oraファイルに同じ名前のエントリがすでに存在するかどうかチェックされ、次のようにtnsnames.oraファイルが更新されます。

- ネット・サービス名のエントリがすでに存在する場合、Oracle Fail Safeにより、仮想ホストに接続できるようにそのエントリが更新されます。SERVICE_NAMEなどのCONNECT_DATAパラメータは変更されません。

- エントリが存在しない場合、tnsnames.oraファイルに新しいエントリが書き込まれます。この場合、SIDはCONNECT_DATAパラメータで使用されます。(ユーザーは、サービス名ではなくSIDを参照するネット・サービス名を使用して、データベースに接続できます。)

- 次の例に示すように、アーカイブ・ログの宛先をサービス名として定義した場合、どのクラスタ・ノードでもtnsnames.oraファイルが自動的に更新されなくなります。各クラスタ・ノードで、サービス名エントリを手動で編集するか、tnsnames.oraファイルに追加します。

log_archive_dest_2='SERVICE=standby OPTIONAL REOPEN=120'

- サーバー・ノードでは、内部クラスタ通信専用に構成された仮想ホスト名を使用するアドレスが、アドレス・リストの最上位に置かれます。そのため、サーバー・ノードで実行されるアプリケーション(データベース・リソース・モニターを含む)は、データベース・リソースへの接続にパブリック・インターコネクトを利用するアドレスを使用する前に、クラスタ・ノード間のプライベート・ネットワーク・インターコネクトを利用するアドレスの使用を試みます。
クライアント・ノードでは、内部クラスタ通信専用に構成された仮想ホスト名を使用するアドレスは、アドレス・リストに含まれません。

注意:
Oracle Fail Safeにより、(そのシングルインスタンス・データベースの可能所有者である)すべてのクラスタ・ノード上で、tnsnames.oraファイルが更新されます。リモート・クライアントで、クラスタ・ノードを介してシングルインスタンスOracle Databaseに対する作業を処理できるようにする必要がある場合は、tnsnames.oraファイルを編集し、仮想アドレス情報でホスト名を更新する必要があります。ネットワーク構成ツールを使用して各クライアントのローカルtnsnames.oraファイルを編集してください。

8.4.3.2 Oracle Fail Safeにより行われるlistener.oraファイルの更新内容

シングルインスタンス・データベースをグループに追加すると、Oracle Fail Safeではlistener.oraファイルを次のように変更します。

1. スタンドアロン・データベース・リスナーからSID_DESCパラメータを削除します。

2. シングルインスタンス・データベースに関連付けられた仮想アドレスでリスニングするように構成されたOracle Fail Safeリスナーを新規作成します。

3. SID_DESCパラメータを新規のOracle Fail Safeリスナーに追加します。

4. スタンドアロン・データベース・リスナーを停止後、再起動して変更内容を有効にします。

5. 新規のOracle Fail Safeリスナーを起動します。

8.4.3.3 Oracle Fail Safeにより行われるsqlnet.oraファイルの更新内容

シングルインスタンス・データベースに対するオペレーティング・システム認証を選択済の状態で、そのデータベースをグループに追加すると、(パラメータを設定済でない場合は、)Oracle Fail Safeによって、sqlnet.oraファイルにSQLNET.AUTHENTICATION_SERVICES=(NTS)パラメータが追加されます。

8.4.4 可用性が高まるように構成されたデータベースでの外部プロシージャの使用方法

Oracle Fail Safeでは、グループのOracle Netリスナー定義(listener.oraファイル)内に外部プロシージャのアドレスが構成されます。最初のデータベースがグループに追加される時点で、データベースにサービスを提供する元のOracle Netリスナーに外部プロシージャが構成されているかどうかが判断されます。構成されている場合、グループのlistener.oraファイル内に、IPCリスナー・アドレスおよびSID記述子(SID_DESC)の両方が作成されます。

Oracle Fail Safeでは、グループ内の最初の仮想アドレスのネットワーク名に接頭辞EXTPROCを連結して、IPCアドレスのキーを作成します。グループ内の最初の仮想アドレスは、アルファベット順の仮想アドレス・ネットワーク名を使用して決定されます。したがって、最初の仮想アドレスのネットワーク名がntclu45の場合は、キー値はEXTPROCntclu45で、IPCアドレス・エントリは次のようになります。

(ADDRESS=
(PROTOCOL=IPC)
(KEY=EXTPROCntclu45)
)

Oracle Fail Safeでは、データベースの元のOracle NetリスナーからSID記述子情報をグループのOracle Netリスナーにコピーします。たとえば、データベースの元のOracle Netリスナーに次のSID記述子がある場合、グループのOracle Netリスナーの記述子もこれと同じになります。

(SID_DESC=
(SID_NAME=PLSExtProc)
(ORACLE_HOME=C:\app\oracle\product\11.2.0\db_1)
(PROGRAM=extproc)
)

PL/SQLまたはSQLのアプリケーションで外部プロシージャをコールする場合、アプリケーションではtnsnames.oraファイル内にEXTPROC_CONNECTION_DATAネット・サービス名エントリを指定します。このエントリには、リスナーが外部プロシージャのプロセスを起動するために必要な情報が含まれています。クラスタ内のすべてのtnsnames.oraファイルで、EXTPROC_CONNECTION_DATAネット・サービス名エントリに、グループ内のOracle NetリスナーのIPCアドレスが追加されます。

8.4.5 共有サーバーを使用するデータベースのサポート

次の各項では、共有サーバー構成を使用するシングルインスタンス・データベースがOracle Fail Safeでどのようにサポートされるかを説明します。

注意:
データベースを共有サーバー構成用に設定する場合、Oracle Fail Safeで内部操作専用のサーバー接続を引き続き使用できることを確認します。そのためには、各クラスタ・サーバー・ノード上のtnsnames.oraファイルのデータベースに対する、ネット・サービス名エントリの接続データ部分に(SERVER=DEDICATED)パラメータを指定します。(共有サーバーが使用されている状態でSERVERパラメータが指定されていない場合、デフォルトではリスナーが共有サーバーを使用して接続を確立します。)

8.4.5.1 データベース用の共有サーバー

共有サーバー構成を使用するには、データベース・パラメータ・ファイルを変更する必要があることがあります。

リスナー情報は、共有サーバー構成のLOCAL_LISTENERパラメータまたはDISPATCHERSパラメータのいずれかに指定できます。

共有サーバー構成で、LOCAL_LISTENERパラメータを使用して完全なリスナー情報を指定する場合(完全なリスナー情報にはホストとポートの両方の値が含まれる)は、Oracle Fail Safeにより、「リソースをグループに追加」操作中に共有サーバー構成用のデータベース・パラメータ・ファイルが自動的に更新されます。

グループに追加されたシングルインスタンス・データベースは、共有サーバー・モードで稼働します。データベース・パラメータ・ファイルはそれ以上変更しないでください。

次の例は、Oracle Fail Safeにより自動的に更新される共有サーバー構成を示します。

dispatchers = "(PROTOCOL=TCP)(DISPATCHERS=1)"
local_listener = "(ADDRESS=(PROTOCOL=TCP)(HOST=124.7.56.1)(PORT=1521))"

データベースをグループに追加すると、Oracle Fail SafeではLOCAL_LISTENERパラメータを更新し、そのグループのリスナー情報を使用します。

ただし、共有サーバー構成でDISPATCHERSパラメータを使用して完全なリスナー情報を指定する場合は、DISPATCHERSパラメータからホストとポートの値を削除します。Oracle Fail Safeでは、常にLOCAL_LISTENERパラメータをデータベース・パラメータ・ファイルに書き込みます。

Oracle Fail Safe Managerを使用してデータベースをグループから削除すると、データベース初期化ファイルからLOCAL_LISTENERパラメータが削除されます。8.2.5項の指示に従って、このパラメータをデータベース初期化ファイルに戻す必要があります。

8.5 シングルインスタンス・データベースのセキュリティ要件

シングルインスタンスOracle Databaseを管理するには、SYSDBA権限を付与されたデータベース管理者アカウントを使用します。これにより、リモート・クライアントからOracle Databaseを管理できます。

シングルインスタンスのサンプル・データベースを作成する場合や、グループにシングルインスタンス・データベースを追加する場合、Oracle Fail Safeではオペレーティング・システム認証またはSYSユーザー・アカウントを使用してデータベースにアクセスする必要があります。ユーザーがSYSアカウントを使用してデータベースにアクセスする場合は、認証パスワード・ファイルを使用してデータベース初期化パラメータ・ファイル(initdatabase-name.ora)内の初期化パラメータREMOTE_LOGIN_PASSWORDFILEをSHAREDまたはEXCLUSIVEに設定します。ユーザーがオペレーティング・システム認証のみを使用してデータベースにアクセスする場合は、REMOTE_LOGIN_PASSWORDFILEをNONEに設定します。

注意:
Oracle Fail Safeでは、WindowsレジストリのDBA_AUTHORIZATIONパラメータをBYPASSの値に設定できません。

データベース管理者認証およびREMOTE_LOGIN_PASSWORDFILEパラメータの詳細は、『Oracle Database管理者ガイド』を参照してください。

8.5.1 クラスタ・ノード上のパスワード・ファイルの同期化

データベースのパスワード・ファイルはプライベート・ディスクに格納されます。一方のクラスタ・ノードでパスワード・ファイルに対して行った変更内容は、他方のクラスタ・ノード上の対応するファイルに自動的には適用されません。

このため、1つのクラスタ・ノード上のパスワード・ファイルにアカウントを追加した場合は、データベース・インスタンスを実行するよう構成されている他のクラスタ・ノード上のパスワード・ファイルにもそのアカウントを追加する必要があります。パスワード・ファイルにSYSアカウント以外のアカウントが格納されている場合は、シングルインスタンス・フェイルセーフ・データベース用に、他のクラスタ・ノードで追加アカウントのSYSOPERおよびSYSDBA 権限を付与する必要があります。

Oracle Fail Safe Managerのリソースをグループに追加ウィザードを使用してシングルインスタンス・データベースをグループに追加する場合、Oracle Fail Safeはデータベースを実行するために構成される他のノード上にデータベース・インスタンスを作成し、パスワード・ファイルのユーザーの最大数にデフォルト値を使用します。インスタンスが作成されたノード上のパスワード・ファイルには、リソースをグループに追加ウィザードで指定したSYSアカウントのパスワードのみが含まれます。

データベース・インスタンスが稼働するように構成された他のノードで、次の手順を実行して、他のクラスタ・ノード上のパスワード・ファイルを同期化します。

1. パスワード・ファイル内のアカウント数がデフォルトの最大値を超える場合は、新しいパスワード・ファイルを作成します。それ以外の場合は、手順2に進みます。
新しいパスワード・ファイルを作成するには、Oracle Databaseの該当するリリースの管理者ガイドで、パスワード・ファイルの作成方法の手順を参照してください。

2. シングルインスタンス・データベースを含むグループを、そのデータベース・インスタンスが稼働するように構成された他のノードに移します。

3. データベースを移した先のノードで、SYS以外のアカウントに権限を付与します。

4. データベースが稼働するように構成された各クラスタ・ノードに対して、手順2と3を繰り返します。
これで、データベース・インスタンスが稼働するように構成されたすべてのノードで、パスワード・ファイルのローカル・コピーが同一のものになります。

8.5.2 SYSアカウントのパスワードの変更

SYSアカウントのパスワードは、データベースに関連付けられているOracleホームにあるパスワード・ファイルに通常格納されます。各クラスタ・ノードにデータベースに使用するOracleホームがあるため、データベースがクラスタ・リソースである場合に保持する必要がある複数のパスワード・ファイルが存在します。SYSアカウントのパスワードを変更するには、変更をデータベースに関連付けられているクラスタの各Oracleホームに伝播できるように、Oracle Fail Safe Managerユーティリティを使用します。Oracle Fail Safeで使用するパスワード・メンテナンス戦略を妨げる可能性があるため、SQL*Plusまたは他のユーティリティを使用してSYSアカウント・パスワードを手動で変更しないでください。

データベースのパスワードをデータベース・リソースの「プロパティ」ページで変更できます。Oracle Fail Safe Managerで、クラスタ・リソース・リストからデータベースを選択して、「アクション」メニューの「プロパティ」アクションをクリックします。リソース・プロパティ・ページが表示されます。オペレーティング・システムが使用されない場合、パスワード・フィールドが表示されます。

図版db_gen_prop.gifの説明

一般的なデータベースでは、パスワードの変更がただちに適用されます。ただし、データベース・パスワード・ファイルが共有されている場合、つまり初期化パラメータREMOTE_LOGIN_PASSWORDFILEがSHAREDに設定されている場合、パスワードの変更が適用される前にデータベースを再度開く必要があります。つまり、データベース・クラスタ・リソースをオフライン化して再度オンライン化するか、パスワードを変更する前にデータベースを所有するクラスタ・グループをクラスタの別のノードに移動する必要があります。Oracle Fail Safeは、データベースがオフライン化された場合でもパスワード・ファイルを更新します。

8.5.3 Oracle Database Upgrade Assistantを使用したフェイルセーフ・データベースのアップグレード

この項では、Oracle Database Upgrade Assistantを使用して異なるリリース間でシングルインスタンス・フェイルセーフ・データベースをアップグレードする方法、あるいは異なるOracleホーム間でシングルインスタンスOracle Databaseを移動する方法について説明します。

アップグレードまたは新規Oracleホームに移動するシングルインスタンス・データベースのそれぞれに対して、次の手順を実行します。

1. シングルインスタンス・データベースをグループから削除します。「使用可能なOracleリソース」リストから削除するサンプル・データベースを選択し、「Oracleリソース」ビューの「アクション」メニューから「サンプル・データベースの削除」を選択します。
「サンプル・データベースの削除の確認」ダイアログ・ボックスが開きます。「はい」をクリックします。

2. シングルインスタンス・データベースの移動先またはアップグレード先となるOracleホームから、Oracle Database Upgrade Assistantを実行します。

3. アップグレードするシングルインスタンス・データベースのデータベース・パラメータ・ファイルの場所を把握しておきます。データベースをアップグレードする際に、データベース・パラメータ・ファイルが変換されます。データベース・パラメータ・ファイルがクラスタ・ディスク上にある場合、パラメータ・ファイルはOracle Fail Safeによる変換に適した場所に置かれます。データベース・パラメータ・ファイルがプライベート・ディスク上にある場合、Oracle Database Upgrade Assistantはそのローカル・コピーのみを変換します。この場合、他のクラスタ・ノード上のコピーも編集し、適切な変更を加える必要があります。

4. Oracle Database Upgrade Assistantで求められる変換済データベース・ファイルの場所を指定します。データファイルを現在の場所のままにしておくか、またはローカル・ノードから現在アクセス可能なクラスタ・ディスクを指定します。後者を選択する場合、そのクラスタ・ディスクが他のグループによって使用されていないことを確認してください。

5. Oracle Database Upgrade Assistantによって、グループ内のすべてのデータベースがアップグレードまたは新規Oracleホームに移動されてから、Oracle Fail Safe Managerを使用して、次のようにデータベースをグループに戻し、データベースをオンライン化します。

1. 使用可能なリソースをグループに追加するには、グループに追加するリソースを選択し、「Oracleリソース」ビューの「アクション」メニューから「このリソースをグループに追加」アクションを選択します。

2. リソースの構成を示す「リソースをグループに追加」ガイド付きプロセス・ウィザードが開きます。

移動するグループのデータベースは、すべて同じOracleホームに属している必要があります。Oracle Database Upgrade Assistantを使用して、あるグループ内の1つのデータベースを新規のOracleホームに移動する場合、そのグループ内のすべてのデータベースを新規Oracleホームに移動してください。

8.6 シングルインスタンス・データベース・リカバリの最適化

Oracle Fail Safeによって可用性が高まるように構成されたOracle Databaseでは、予定外に発生したシステム・ダウンおよび(ソフトウェア・アップグレードや定期メンテナンスなどの)計画的システム・ダウンの際に、高速フェイルオーバーと高速リカバリを実現できます。Oracleのファスト・スタートおよび障害時リカバリ機能を利用して、データベース・リカバリに費やされる時間を制御し、Oracle Fail Safeにより可用性が高くなるように構成されたデータベースを連続的に監視することができます。

Oracle Fail SafeとOracle Databaseテクノロジにより、計画的/計画外いずれのフェイルオーバーの場合も、あるノードでデータベースを停止して別のノードでインスタンスを完全にリカバリするまでの所要時間が最適化されます。Oracle Databaseのチェックポイント・アルゴリズムにより、計画的および計画外フェイルオーバーでのインスタンスのリカバリ時間が最適化されます。

計画的フェイルオーバーの実行にOracle Fail Safe Manager(またはPowerShellコマンドレット)を使用すると、Oracle Fail Safeでは、シングルインスタンスOracle Databaseを停止する前にそのチェックポイントを取得します。インスタンス・リカバリを即時に完了し、データベース・クライアントでデータベースをすぐに利用できるように、別のノードのシングルインスタンス・データベースは制限付きモードで起動されます。(計画的フェイルオーバーの実行にMicrosoft Windowsフェイルオーバー・クラスタを使用した場合、データベースが停止される前のチェックポイントの取得は行われません。)

注意:
Oracle Fail Safe Manager、Oracle Fail Safe PowerShellコマンドレットまたはMicrosoft Windowsフェイルオーバー・クラスタ以外のツールを使用してデータベースをオフライン化すると、Oracle Fail Safeではそれを障害の発生したリソースとしてみなし、再度オンライン化を試行します。

計画外フェイルオーバーの場合、インスタンス・リカバリの時間はデータベース・リカバリ処理によって制御されます。ファスト・スタート・リカバリ操作の詳細は、Oracle Databaseのマニュアルを参照してください。

8.7 シングルインスタンス・フェイルセーフ・データベースに対する管理作業の実行

可用性が向上するように構成されたデータベースに対する管理作業も、他のデータベースと同様にして実行します。ただし、データベースへのアクセスを制限する操作、またはフェイルオーバー機能を一時的に使用不可にする操作の途中でデータベースをオフラインにする(およびクラスタでのデータベースの監視を停止する)場合は例外で、Oracle Fail Safe ManagerまたはPowerShellコマンドレット・コマンドライン・インタフェース(第5章を参照)を使用します。これには、コールド・バックアップ操作のみではなく、ユーザーがデータベースにアクセス中に実行する必要のある管理操作や、Microsoft Windowsフェイルオーバー・クラスタによるデータベースの定期的なIs Aliveポーリング中の応答時間に影響する操作が含まれます。

Oracle Fail Safe Managerを使用してグループ内に構成されているデータベースに対して管理作業を実行するには、次の手順に従います。

1. Oracle Fail Safe ManagerまたはFail Safe PowerShellコマンドレットを使用して、データベースをオフライン化して停止し、クラスタによるデータベースの監視を中止します。データベースに接続されているユーザーはすべて切断されます。

2. SQL*Plusなどのツールを使用し、データベースを起動して管理作業を実行します。データベースが起動されている間、ユーザーはデータベースにアクセスできます。

3. 管理作業を完了した後、SQL*Plusなどのツールを使用してデータベースを停止します。

4. Oracle Fail Safe ManagerまたはFail Safe PowerShellコマンドレットを使用し、データベースを再度オンライン化します。クラスタによるデータベースの監視が再開されます。

第5章には、Fail Safe PowerShellコマンドレットを使用してバックアップ操作を実行するスクリプトの例が示されています。

管理作業の途中で、(新しい表領域や関連データファイルの追加など)データベースの構成を変更する操作を行った場合は、「検証」グループ操作を実行します。新規データファイルを追加すると、グループが新しいディスクに依存する可能性があります。「検証」グループ操作を実行すると、ディスクがクラスタ・ディスクであり、別のグループには属していないことが確認されます。新規データファイルの追加によりグループが新しいディスクに依存する場合、ディスクはデータベースと同じグループに追加され、新規ディスクが正常にデータベースとともにフェイルオーバーするよう、クラスタ・レジストリ内の情報が更新されます。

8.8 データベース・ホーム

Oracle Database 12cリリース1 (12.1)以降、Oracle Databaseでは、インストール時に指定されるOracleホーム・ユーザーの使用がサポートされます。Oracleホーム・ユーザーには、組込みアカウントまたはWindowsユーザー・アカウントを指定できます。ただし、Windowsユーザー・アカウントを使用することをお薦めします。Windowsユーザー・アカウントを使用する場合、権限の弱い非管理アカウントである必要があります。Oracleホーム・ユーザーは、Oracleホームに関連付けられます。同じOracleホームを使用するクラスタのすべてのノードで同じOracleホーム・ユーザーを使用していることを確認してください。

Oracle Fail Safeでは、データベースにアクセスする際、通常は同じOracle Databaseホームを使用してシステムのデータベースにアクセスします。Oracle Fail Safeが使用するデータベース・ホームは、サーバーの起動時に選択されます。Oracle Fail Safeはすべてのデータベース・ホームをスキャンして、最上位のソフトウェア・バージョンが含まれるホームを検索します。最初は、システムのPATH環境変数に\binパスが含まれるホームのみを検索します。Oracle Fail SafeはシステムのPATHにデータベース・ホームが見つからない場合、すべてのデータベース・ホームをスキャンして、最上位のバージョンが含まれるホームを検索します。

Oracle Fail Safeでは、最初の起動時にデータベース・ホームが選択されるため、Oracle Fail Safe起動後にインストールされたデータベース・ホームは認識されないことに注意してください。Oracle Fail Safeのサーバーおよびリソース・モニターを再起動しないと、Oracle Fail Safeは新しいデータベース・ホームを使用できるとはみなしません。新しいバージョンのOracle Databaseをインストールした後は、Oracle Fail Safeが新しいデータベース・ホームを使用できるように、すべてのノードでCluster Serviceサービスを再起動する必要があります。

クラスタにより管理されているデータベースがある場合は、データベース・ホームがクラスタ内の各ノードのローカル・ディスクにインストールされている必要があります。データベース・ホームが共有クラスタ・ディスクにインストールされている場合、システムのPATH環境変数にその\binディレクトリを含めないでください。

データベースにアクセスできるOracle Fail Safeコンポーネントは、次の2種類です。

1. Oracle Fail Safeサーバー(OracleMSCSServices)

2. Oracle Fail Safeデータベース・リソースDLL(FsResOdbs.dll)

通常、サーバーがデータベースにアクセスするのは、データベース・リソースを構成(リソースを追加または削除)するときか、操作を検証するときのみです。通常のシステム操作中にOracle Fail Safeサーバーがデータベースにアクセスすることはありません。

データベース・リソースまたはリスナー・リソースがクラスタによって参照されると、Windows Cluster ServiceサービスによってリソースDLLが呼び出されます。たとえば、データベースがオンライン化されるとき、IsAliveポーリング中、リソースが別の仮想ノードにフェイルオーバーされるときなどです。複数のデータベース・ホームが存在するシステムでは、そのデータベースのインスタンスで使用されるデータベース・ホーム・ソフトウェアと同じデータベース・ホーム・ソフトウェアを使用して、各データベースをアクセス先のシステムに置く必要があることがあります。Oracle Fail Safe Managerで表示されるリソース・プロパティ・ページの「このリソースを別のリソース・モニターで実行」チェック・ボックスを選択すると、リソースが個別のリソース・モニター・プロセスで実行されるよう構成することが可能です。このオプションが有効になっている場合、データベースのリソース・モニター・プロセスでは、データベース・アクセスの際に、システムの最上位バージョンのデータベース・ホームが常に使用されるのではなく、データベース・インスタンスの実行に使用されるデータベース・ホームが使用されます。データベース・リスナー・リソースを参照する際には、リソースDLLでは、「このリソースを別のリソース・モニターで実行」オプションの設定に関係なく、リスナー・サービスの起動に使用される\binパスからのソフトウェアが常に使用されます。

データベースにアクセスする際にOracle Fail Safeコンポーネントにより使用されるユーザー・アカウントの詳細は、4.3.1項を参照してください。

8.9 透過的アプリケーション・フェイルオーバー(TAF)の構成

スタンドアロン・シングルインスタンス・データベースの場合、透過的アプリケーション・フェイルオーバー(TAF)が発生すると、Oracle Netは別のリスナーに接続して障害の発生したデータベースへの再接続を確立します。このため、ユーザーは元の接続が維持されている場合と同じように、新しい接続を使用して作業を続行できます。スタンドアロン・シングルインスタンス・データベースの場合とシングルインスタンスOracle Fail Safeデータベースの場合では、TAF機能による実際の処理は異なります。Oracle Fail Safeデータベースの場合、透過的アプリケーション・フェイルオーバーにより、(グループのフェイルオーバーによって別のクラスタ・ノードに移動した)同じリスナーに再接続するようにOracle Netに指示されます。

スタンドアロン・データベースの場合、TAFのフェイルオーバーという語句は、Oracle Netによってあるリスナーから別のリスナーに接続がフェイルオーバーされることを指します。Oracle Fail Safeデータベースの場合、TAFのフェイルオーバーという語句の使用方法に多少誤りがあります。この場合、アプリケーションではなく、アプリケーションに接続されているリスナーのフェイルオーバーによって再接続が確立されます。

実装にはこのような違いがありますが、TAFを管理する方法は同じです。

Oracle Fail Safeで構成されるデータベースに接続する場合に透過的アプリケーション・フェイルオーバーを利用するには、クライアント・アプリケーションはOracle Netを介してOracle Databaseに接続する必要があります。

TAFでは、グループ・フェイルオーバーの後、クライアントは明示的に再接続を行いません。OCI接続がクライアント・アプリケーションの再接続と状態のリカバリを自動的に処理します。実際、障害の発生時にデータベースを頻繁に更新していた場合を除き、アプリケーション側ではフェイルオーバーの発生に気付かない場合があります。

透過的アプリケーション・フェイルオーバーの詳細は、『Oracle Net Services管理者ガイド』を参照してください。

8.10 データベースに関連するエラー処理と問題のトラブルシューティング

次の各項では、Oracle Fail Safeが可用性の高いシングルインスタンス・データベースのオンライン化を試行した際にエラーが発生した場合に、そのエラーを処理するスクリプトの指定方法と、可用性が高まるよう構成されたシングルインスタンスOracle Databaseで発生する特定の問題のトラブルシューティングの方法を説明します。Oracle Databaseのトラブルシューティングに関する一般的な情報は、Oracle Databaseのマニュアルを参照してください。

8.10.1 データベースをオンライン化する際に発生するエラーの処理

Oracle Fail Safeがシングルインスタンス・データベースのオンライン化を試行した際に発生するエラーを処理するスクリプトを指定します。Oracle Fail Safeでは、クラスタ上のすべてのシングルインスタンス・フェイルセーフ・データベースに同じスクリプトを使用します。

エラー処理スクリプトを指定するには、次のようにします。

1. エラーを処理するスクリプトを作成します。

2. スクリプトにFsDbError.batという名前を付けます。

3. スクリプトが成功した場合は0を返し、失敗した場合は0以外の整数を返すことを確認します。

4. データベース・リソースの可能所有者である各クラスタ・ノードの次のディレクトリにスクリプトを置き、ファイル所有者がそのクラスタ・ノードに対するローカル管理者権限を持っていることを確認します。

Oracle_Home\FailSafe\Server\scripts

シングルインスタンス・データベースをオンライン化できない場合、Oracle Fail Safeは次のように、スクリプトを実行するプロセスを生成し、エラー・コード、データベース名、データベースSID、TNSサービス名およびデータベース・パラメータ・ファイル指定などをスクリプトに渡してスクリプトを実行します。

FsDbError.bat error-code database-name SID TNS service name parameter-file-spec

次に例を示します。

FsDbError.bat ORA-01113 OracleDB OracleDB OracleDB.WORLD D:\Ora\admin\OracleDB\pfile\initOracleDB.ora

スクリプトが実行されているプロセスは、データベース・リソースの保留タイムアウト値で指定された期間、スクリプトの終了を待機します。スクリプトが保留タイムアウト期間内に終了しない場合、スクリプトは終了させられます。

Oracle Fail Safeは、Windowsイベント ログにイベントを記録し、スクリプトが成功したか、失敗したか、Oracle Fail Safeによって終了させられたかを示します。スクリプトが失敗した場合は、エラー・コードもイベント ログに書き込まれます。

スクリプトの成否にかかわらず、Oracle Fail Safeでは、データベースの再起動ポリシーおよびフェイルオーバー・ポリシーの定義に従ってシングルインスタンス・データベースのオンライン化の試行が継続されます。

8.10.2 問題のトラブルシューティング

多くの場合、問題のトラブルシューティングでは、まず「検証」クラスタ、「検証」グループ、または「検証」スタンドアロン・データベース・アクションを選択します。これらのツールの概要は、第7章に記載されています。検証アクションを実行しても問題の原因を特定できない場合は、Windowsアプリケーション・イベント・ログを確認して、エラー・メッセージがポストされていないかを調べます。操作が失敗した場合、Oracleサポートによりトレースを有効にするように求められることがあります。Oracle Fail Safeトレースの有効化の詳細は、付録Aを参照してください。

シングルインスタンス・データベースを含むグループに対して「検証」アクションを選択すると、Oracle Fail Safeでは次のことを行います。

- グループ内の各データベースに問い合せて、使用されているディスクを特定します。その後、そのディスクがクラスタ・ディスクであるか、すでにグループに追加されているかをチェックします。(たとえば、可用性が高まるように構成された後にデータベースにディスクが追加されたために)ディスクの有効性検査が失敗した場合、「検証」グループ・アクションでは、問題を修正する前に確認を求められます。

- ディスク・ドライブの変更を検出し、必要に応じてリソースの依存性を更新します。

- ネットワーク名が正しいIPアドレスにpingするかどうかを検証します。

- Oracle Net構成が正しいかどうかを確認します。

- グループ内のリソースの構成に誤りがあれば修正します。

いつでも「検証」グループ・アクションを選択できます。ただし、次の状況が発生した場合は、必ず実行してください。

- グループまたはグループ内のリソースがオンライン化されない場合。

- フェイルオーバーまたはフェイルバックが予定どおりに実行されない場合。

- グループに構成されているシングルインスタンス・データベースにディスクを追加する場合。

- クラスタに新しいノードが追加された場合。

たとえば、Oracle Fail Safe Managerを使用してクラスタ構成を更新せずに、シングルインスタンス・データベースに新しいディスクを追加した場合を考えてみます。その後サーバー・ノードが停止しても、フェイルオーバーは適切に実行されません。これは、クラスタ・ソフトウェアに構成の変更を通知していないことによるものです。この問題を回避するため、シングルインスタンス・データベースの構造を変更したときは、必ずそのデータベースを含むグループを検証してください。グループを検証すると、Oracle Fail Safeでは自動的に変更を検出し、クラスタ構成を更新します。前述の例では、Oracle Fail Safeは、ユーザーにかわって新しいディスクをグループに追加します。

グループの検証で問題が検出された場合、Oracle Fail Safeは問題を修正するための応答を求めるか、または問題を詳しく説明したエラー・メッセージを返します。

8.10.3 データベースをグループに追加する際の問題

シングルインスタンス・データベースをグループへ追加する際に問題が発生した場合は、次の操作を実行します。

- 「使用可能なOracleリソース」リストからデータベースを選択して、「検証」スタンドアロン・データベース・アクションを実行します(7.1.3項を参照)。
「検証」スタンドアロン・データベース操作を実行することにより、データベースが有効に機能するスタンドアロン・データベースであることが検証されます。

たとえば、スタンドアロン・データベースのグループへの追加を試行しOracle Netを構成する際にエラーが発生したとします。この場合は、Oracle Fail Safeによってクラスタワイド操作がロールバックされ、データベースはスタンドアロン・データベースのままになります。この問題を解決するには、次の手順を実行します。

1. 「検証」スタンドアロン・データベース操作を実行して、ネットワーク(Oracle Net)が機能していることを確認します。

2. スタンドアロン・データベースをグループに追加してみます。

3. データベースをグループに追加する操作に失敗した場合は、8.10.7.4項に記載されている方法に従って、Oracle Netのロールバック・ファイルを調べてください。

- 次の条件が満たされていることを確認してください。

- シングルインスタンス・データベース・ファイルが共有クラスタ・ディスク上にあること
Oracle Fail Safeでは、構成内の各ディスクについて、ディスクが共有ストレージ・インターコネクト上にあるかどうかを判断します。データベース・ファイルがクラスタ化されていないディスク上にある場合は、そのデータベース・ファイルを移動して共有クラスタ・ディスク上に置く必要があります。

- リソースをグループに追加ウィザードで次の情報を正しく指定してあること

- データベースのアクセスに使用するユーザー名とパスワード

- データベースのパラメータ・ファイル

8.10.4 グループのオンライン化の問題

シングルインスタンス・データベースが含まれるグループをオンライン化する際に問題が発生した場合は、次の操作を実行します。

- グループを検証します。
(Oracle Fail Safe Managerグループの「アクション」メニューから)「検証」を選択すると、Oracle Fail Safeではグループの構成をチェックし、問題が見つかると修正を行います。

「検証」グループ・アクションで問題が見つかった場合は、その問題を手動で解決するヒントとなるエラー・メッセージが返されます。

- Oracle Netのリスナー・ログを確認します。
Oracle Netでは、エラーの検出や、リスナーを介したデータベースへのアクセスのたびに、リスナー・ログ・ファイルにエントリを作成します。このログ・ファイルの中に、問題の識別に役立つエラーがないかどうかを調べます。

- シングルインスタンス・データベースのネット・サービス名を調査します。
Oracle Fail Safeデータベース・リソースDLLでは、Is Aliveポーリング間隔でグループ内の各データベースにアクセスします。(Is Aliveポーリング間隔は、Oracle Fail Safe Manager内のOracleリソースの「ポリシー」プロパティ・ページに表示されます。)DLLでは、データベース接続情報を使用してデータベースにアクセスします。データベース・アクセス情報が変更されると、Oracle Fail Safeはデータベースへのアクセスに失敗します。このため、Microsoft Windowsフェイルオーバー・クラスタはデータベース・リソースが稼働中であるとはみなしません。

- Oracle Net構成データを確認します。
サーバー・システム上のlistener.oraファイル、およびサーバーとクライアントの両方のシステム上の tnsnames.oraファイルには、クラスタ内のグループに対する有効な仮想サーバー・アドレスが含まれている必要があります。

- グループ内の各リソースを個別にオンライン化します。
グループ内に複数のシングルインスタンス・データベースが存在する場合、この方法で問題の原因となっているデータベースを識別できます。

- 「拡張ポリシー」プロパティ・ページで指定されたシングルインスタンス・データベースの「保留タイムアウト」値が十分であることを確認します。
データベースが含まれるグループがオンライン化に失敗する場合、または頻繁にフェイルオーバーする場合は、「保留タイムアウト」値が正しく設定されているか確認してください。データベースの「保留タイムアウト」値の設定が低すぎると、オンライン化に失敗したり、フェイルオーバーが頻繁に発生します。

「保留タイムアウト」の値を設定して、クラスタ・ソフトウェアでデータベースがオンライン(またはオフライン)になってから操作が失敗したと判断されるまでの時間を指定します。値は、遅いレスポンス時間がクラスタ・システムにより使用不可状態と判断されることがない程度に大きく、かつ障害発生時のフェイルオーバー・レスポンス時間を最小限に抑えられる程度に小さく設定してください。

「保留タイムアウト」値を設定するには、次のようにデータベース・プロパティを変更します。

1. Oracle Fail Safe Managerのツリー・ビューで、データベース名を選択します。

2. 「ポリシー」タブをクリックします。

3. 「保留タイムアウト」ボックスで「保留タイムアウト」値を変更します。

- ユーザーがSYSアカウントを使用してデータベースにアクセスする場合は、データベース初期化パラメータ・ファイル(initdatabase-name.ora)内の初期化パラメータREMOTE_LOGIN_PASSWORDFILEがSHAREDまたはEXCLUSIVEに設定されていることを確認します。

- ユーザーがオペレーティング・システム認証のみを使用してデータベースにアクセスする場合は、データベース初期化パラメータ・ファイル内の初期化パラメータREMOTE_LOGIN_PASSWORDFILEがNONEに設定されていることを確認します。

- Oracle Fail Safeでデータベースへのアクセスに使用するアカウントのパスワードが変更されている場合は、Oracle Fail Safe Managerでその変更を更新します。
Oracle Fail Safeでデータベースへのアクセスに使用するアカウントのパスワードを変更後、Oracle Fail Safe Managerでその情報を更新しない場合、データベースに対するポーリングは失敗します。Oracle Fail Safeのデータベース・パスワードの変更を更新する方法の詳細は、8.5.2項を参照してください。

8.10.5 プロセスが集中している操作の際のグループ・フェイルオーバー

プロセスが集中している操作(インポート操作など)では、Is Aliveポーリングが正常に実行されずに、予期しないグループ・フェイルオーバーが発生する場合があります。このような場合には、(Get-OracleClusterResource dbname).IsAliveEnabled=$falseコマンドを発行して、データベースに対するIs Aliveポーリングを使用不可にできます。Is Aliveポーリングを使用不可にする場合は、再度使用可能にするまで、Oracle Fail Safeによりインスタンスの監視が中止されるので注意してください。Is Aliveポーリングを再度使用可能にするには、(Get-OracleClusterResource dbname).IsAliveEnabled=$trueコマンドを使用します。

これらのPowerShellコマンドレットは、プロセスが集中している操作の完了時にIs Aliveポーリングを再度使用可能にできるようにスクリプト内から実行することをお薦めします。

PowerShellコマンドレットの詳細は、第6章を参照してください。

8.10.6 データベース認証の概要

Oracle Fail Safeでシングルインスタンス・データベースをオンライン化またはオフライン化しようとして問題が発生することがあります。この問題の原因として、データベース認証の設定方法に問題があることが考えられます。この問題を解決するには、次の操作を実行します。

- Oracle Databaseの「通常」プロパティ・ページでデータベースを認証する「SYSアカウントを使用」を選択した場合は、データベース初期化パラメータ・ファイル(initdatabase-name.ora)でREMOTE_LOGIN_PASSWORDFILE初期化パラメータがSHAREDまたはEXCLUSIVEに設定されていることを確認します。
8.5項に、データベース認証に対してこのパラメータを適切に設定する方法が記載されています。

- Oracle Fail Safeでグループ内のデータベースにアクセスできることを確認します。
グループの検証や、データベースがオンライン状態であることを確認するためのポーリングなど、Oracle Fail Safeにより実行される一部の操作では、Oracle Fail Safeでグループ内にあるデータベースにアクセスできる必要があります。データベース・アカウントのパスワードが変更されている場合は、Oracle Fail Safe Managerでその変更を更新します。更新しないと、Oracle Fail SafeでIs Aliveポーリングを使用するデータベースの監視ができなくなります。この状態は、Windowsアプリケーション・イベント・ログにより記録されます。

8.5.2項に、データベース・パスワードの正しい更新方法が記載されています。

8.10.7 仮想サーバーの構成で検出される問題

スタンドアロン・データベースまたはグループに構成されているデータベースに接続しようとして問題が検出された場合は、データベースのOracle Net構成を調べる必要があります。

Oracle Fail Safeは、「検証」グループおよび「検証」スタンドアロン・データベース操作を提供して、Oracle Net構成を検証および修正できます。詳細は、7.1.2項および7.1.3項を参照してください。

8.10.7.1 仮想アドレスの構成で発生する問題

Oracle Fail Safeは仮想アドレス情報を構成するとき、listener.oraファイルおよびtnsnames.oraファイルを変更し、リスナーを停止してから再起動します。発生する可能性のある問題と問題を解決するための処置を、次のリストに示します。

- FS-10070 Oracle Net: name
このメッセージ・コードは、Oracle Netのlistener.oraおよびtnsnames.oraファイルの解析(読込みまたは更新)に問題があることを報告するものです。

- 不適切な更新やファイルの破損によりファイルが無効となった場合、Oracle Fail Safeではこれらのファイルを使用して仮想サーバー情報を構成できません。有効なバージョンのファイルを取得するか、Oracle Net Assistantを使用してファイルを作成しなおします。

- これらのファイルが有効な場合は、操作で使用されているグループのネット・サービス名、データベースSIDおよびネットワーク名が正しいかどうかをチェックします。情報が不適切であると、仮想サーバーの構成でエラーが生じることがあります。同じデータベースSIDが、複数のリスナーに含まれていないことを確認してください。複数のOracleホームを伴ったシステムでは、すべてのlistener.oraファイルをチェックします。

- FS-10066: Oracle NetリスナーのWindowsサービスname が開始できませんでした。
リスナーの定義変更や新規リスナーの定義作成後、Oracle Fail Safeではリスナーが起動されます。

多くの場合、このエラーは、別のリスナーがすでにデータベースをリスニングしていることが原因で発生します。システム上で1つのリスナーにかぎり、特定のアドレスまたはデータベースSIDのリスニングが可能です。たとえば、LISTENER_Aが次のような定義の場合、システム上のその他のリスナーでは、IPCプロトコルを使用したキーORCLのリスニング、TCPプロトコルを使用したホストserver_Aでのポート1521のリスニング、またはORCL SID名のリスニングができません。

LISTENER =
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=IPC)
(KEY=ORCL)
)
(ADDRESS=
(PROTOCOL=TCP)
(Host=server_A)
(Port=1521)
)
)

SID_LIST_LISTENER =
(SID_LIST=
(SID_DESC=
(SID_NAME=ORCL)
)
)

他のリスナーでLISTENER_Aと同じアドレスまたはデータベースSIDを使用しようとすると、起動に失敗します。

この問題が発生すると、Oracle Fail Safeでは、更新されたリスナーおよびネット・サービス名の定義が含まれたlistener.oraファイルおよび tnsnames.oraファイルをロールバック・ファイルとして保存します。ロールバック・ファイルのファイル名は、filename_rlb.oraです。

ロールバック・ファイルを読み込んでリスナー定義を探し、システム上で稼働している他のすべてのリスナー定義と照合する必要があります。リスナー間でアドレスまたはデータベースSID名が重複しないようにしてください。ここでも、複数のOracleホームを使用するシステムでは、すべてのlistener.oraファイルをチェックしてください。

- リスナーを起動できない一般的な原因のもう1つは、仮想アドレスです。リスナーが使用する仮想アドレスは、Oracle Fail Safeがリスナーを起動しようとしているノード上でアクティブである必要があります。

ネットワーク構成の問題のトラブルシューティングに関する詳細は、Oracle Netのマニュアル(ログ・ディレクトリの情報を含む)を参照してください。

8.10.7.2 リスナー作成時の問題

Oracle Fail Safe Managerでは、リスナー制御ユーティリティ(LSNRCTL)を使用して新規リスナーを作成し、Oracleホームにあるファイルに出力します。

たとえば、Oracleホームとネットワーク・ディレクトリのパスがC:\ORANT\NETWORK\ADMINで、リスナーが動作する仮想アドレスがntclu-155の場合、リスナー出力ファイルは、次のディレクトリおよびファイルに書き込まれます。

C:\ORANT\NETWORK\LOG\fslntclu-155.out

各リスナーには、リスナー名に.out拡張子が付いた名前の出力ファイルがあります。(この例では、リスナー名はfslntclu-155です。)新規リスナーの作成が困難な場合は、出力ファイルを使用して問題を診断できます。

8.10.7.3 アーカイブされたlistener.oraまたはtnsnames.oraファイル

Oracle Fail Safeがlistener.oraまたはtnsnames.oraファイルを変更すると、そのファイルの元のバージョンが毎回アーカイブされます。Oracle Fail Safeによって変更される前のOracle Netのネット・サービス名定義やリスナー定義を参照する必要がある場合は、構成ファイルのアーカイブ・バージョンを調べます。

Oracle Fail Safeは、アーカイブされたバージョンの構成ファイルを2つ前の分まで保持します。アーカイブされたバージョンのファイル名の形式は、filename_000.oraおよびfilename_001.oraとなります。filename_000.oraが最新のファイルです。

8.10.7.4 ロールバック・ファイル

Oracle Net構成ファイルの変更後、Oracle Fail Safeで操作の実行中にエラーを検出すると、そのファイルの更新済バージョンがfilename_rlb.oraとして保存されます。その後、ファイルの元のバージョンがリストアされます。

このロールバック・バージョンのファイルは、問題の診断に役立つことがあります。

8.10.8 セキュリティ・アクセスおよび認証の問題

アクセスおよび認証の問題は、Oracle Enterprise Managerを介して操作を実行する場合に最も多く発生します。

次に、典型的な認証の問題をいくつか示します。

- Oracle Fail Safeへの接続時に、Oracle Enterprise Managerから次のようなエラーが発生。
FS-10101: クラスタ上のユーザーusernameの認証に失敗しました。

Oracle Enterprise Managerで、クラスタのユーザー資格証明がすべてのクラスタ・ノーでWindows管理者の資格証明と同じであり、ユーザー名とドメインが正しく指定されていることを確認します。

- Oracle Enterprise ManagerからOracle Fail Safeに発行したジョブが、エラー「ユーザーの認証に失敗しました。」で失敗します。

- クラスタ内のそれぞれのノード上で、「バッチ ジョブでログオン」のアクセス権限を使用して設定されたWindowsアカウントを持っていることを確認します。

- Oracle Enterprise Managerで、クラスタ内の各ノードに対するユーザー設定項目が、クラスタ内の各ノードのローカル・アカウントのユーザー名およびパスワードと一致していることを確認します。

- グループ内に構成されているデータベースで操作を実行したり、データベースにアクセスしようとすると、「ORA-01031: 権限が不足しています」エラーが返されます。

- サンプル・データベースの作成、グループへのデータベースの追加を実行する場合は、データベースの認可情報にパスワードとSYSアカウントが使用されていることを確認します。

- Oracle Enterprise Managerからデータベースにアクセスする場合、各データベースのユーザー設定項目がデータベースのSYSアカウントと一致していることを確認します。

8.10.9 クライアントがデータベースにアクセスできない

ユーザーおよびクライアント・アプリケーションがグループ内に構成されているデータベースにアクセスできない場合は、次の手順を実行して問題を修正します。

1. グループに対して仮想サーバーを使用するように、tnsnames.oraファイルを更新します。

2. 「検証」グループ・アクションを選択して、ネットワーク(Oracle Net)構成の有効性を検査します。

8.11 Oracle Data Guardによる可用性の高いデータベースの使用

Oracle Fail SafeによってシングルインスタンスOracle Databaseの可用性が高くなり、Oracle Data Guardによって障害耐久力がもたらされます。たとえば、Oracle Fail Safeでは、特定のシステムに対してほぼ連続した高い可用性が実現されますが、そのシステムが常駐するサイトが正常に機能できなくなるような障害に対する保護は行われません。同様に、Oracle Data Guardでは、高度な障害時リカバリ機能が提供されますが、プライマリ・サイトから物理的に離れたサイトに操作を切り替えるには、数分から数時間を要する場合があります。Oracle Fail SafeとOracle Data Guardを組み合せて使用することで、データベースの可用性と障害耐久力が高まります。

Oracleサポートと契約している場合は、次の場所にあるMy Oracle Supportにログインしてノート259902.1を検索することにより、Oracle Fail SafeでのOracle Data Guardの使用に関する情報を検索できます。

https://support.oracle.com

9 可用性を高めるためのOracle Management Agentの構成

次の手順を使用することにより、可用性が高まるように構成されたデータベースを監視するOracle Enterprise Manager 11g Grid Controlを構成します。

注意:
Oracle Fail Safeは、Oracle Enterprise Manager Grid Control 11gリリース以前にのみ互換性があります。

1. Oracle Management Agentをインストールします。

2. 仮想アドレスでリスニングするOracle Management Agentを作成します。

3. 手順2でインストールしたOracle Management Agentを、可用性が高まるように構成されたOracle Databaseと同じグループに追加します。

4. データベースを監視するようにOracle Management Agentを構成します。

関連項目:

マニュアルは、次に示すOracle Technology NetworkのWebサイトから入手できます。

http://www.oracle.com/technetwork/indexes/documentation/index.html#em

- Enterprise Manager Grid Controlの詳細は、『Oracle Enterprise Manager Grid Control基本インストレーション・ガイド』を参照してください。

- Oracle Management Agentのインストールの詳細は、『Oracle Enterprise Manager Grid Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

- Oracle Enterprise Manager管理者ガイドのManagement Agentの構成に関する項を参照してください。

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

- 可用性を高めるための前提条件

- 可用性を高めるためのOracle Management Agentの構成手順

- Oracle Management Agentのグループからの削除

9.1 可用性を高めるための前提条件

可用性を高めるためにOracle Management Agentを構成するには、あらかじめ次のソフトウェアをクラスタ・システムにインストールしておく必要があります。

- Oracle Database(Oracle Enterprise Manager Grid Controlでサポートされているリリース)

- Oracle Management Agent
各クラスタ・ノードにManagement Agentをインストールします。各ノードで同じOracleホームを使用します。

- Oracle Fail Safe

さらに、次のコンポーネントを構成する必要があります。

- Oracle Databaseインスタンスを、可用性を高めるために構成する必要があります。

- Oracle Enterprise Manager Management Serverを構成して、設定の際に使用できるようにしておく必要があります。管理サーバーは、クラスタ・システム上になくても構いません。

9.2 可用性を高めるためのOracle Management Agentの構成手順

次の手順を実行して、可用性を高めるためのOracle Management Agentを構成します。

- 手順1「Management Agentの可用性の向上」

- 手順2「Oracle Enterprise Managerで可用性の高いデータベースをターゲットとして追加」

- 手順3「可用性の高いManagement Agentのテスト」

- 手順4「Oracle Enterprise Manager環境からの不要なターゲットの削除」

手順1 Management Agentの可用性の向上

Oracle Fail Safe Managerを使用して、Oracle Management Agentが監視するデータベースが含まれるFail Safeグループに新しいOracle Management Agentを追加します。次の手順を実行します。

1. Oracleリソース・ページへ移動して、「使用可能なOracleリソース」リストから「Oracle Management Agent」リソース・タイプを選択します。

2. ウィンドウの右側のパネルの「アクション」メニュー・リストから「このリソースをグループに追加」を選択します。リソースをグループに追加ウィザードが開きます。

図9-1 リソースをグループに追加ウィザード - 「グループ」ページ

「図9-1 リソースをグループに追加ウィザード - 「グループ」ページ」の説明

3. 「グループ」ガイド付きプロセス・ウィンドウで、Oracle Management Agentを追加するグループを選択します。これは、Oracle Management Agentによって監視するデータベースが含まれるグループにする必要があります。

4. 「次へ」をクリックします。「Management Agent」の「ディスク」のページが開きます。

図9-2 リソースをグループに追加ウィザード - 「Management Agent」の「ディスク」ページ

「図9-2 リソースをグループに追加ウィザード - 「Management Agent」の「ディスク」ページ」の説明

5. 「エージェント・ディスク」ガイド付きプロセス・ウィンドウで、Management Agentコンテキスト情報を格納するために使用されるクラスタ・ディスクを選択します。

6. 「次へ」をクリックします。「Management Agent」の「ホスト」のページが開きます。

図9-3 リソースをグループに追加ウィザード - 「Management Agent」の「ホスト」ページ

「図9-3 リソースをグループに追加ウィザード - 「Management Agent」の「ホスト」ページ」の説明

7. 「エージェント・ホスト」ガイド付きプロセス・ウィンドウで、新しいOracle Management Agentの「仮想アドレス」を選択します。

8. 他のボックスで、開いているポート番号を入力します。

9. 「次へ」をクリックします。「Management Agent」の「パスワード」のページが開きます。

図9-4 リソースをグループに追加ウィザード - 「Management Agent」の「パスワード」ページ

「図9-4 リソースをグループに追加ウィザード - 「Management Agent」の「パスワード」ページ」の説明

10. Oracle Management Serverに対して使用するパスワードを入力します。

11. 「次へ」をクリックします。「Management Agent」の「確認」のページが開きます。

図9-5 リソースをグループに追加ウィザード - 「Management Agent」の「確認」ページ

「図9-5 リソースをグループに追加ウィザード - 「Management Agent」の「確認」ページ」の説明

12. 「終了」をクリックします。リソースをグループに追加中の進行状況ウィンドウが開きます。このウィンドウは、操作が完了しているタスクを表示します。ファイルへの出力ウィンドウの内容の保存または出力の印刷を選択できます。

13. タスクが正常に完了した後、「クラスタワイド操作の状態」ダイアログ・ボックスが開きます。「OK」をクリックします。次に、リソースをグループに追加中の進行状況ウィンドウの「閉じる」をクリックして、操作を閉じます。

手順2 Oracle Enterprise Managerで可用性の高いデータベースをターゲットとして追加

可用性の高いManagement Agentによって可用性の高いデータベースを監視するように構成するには、次の手順に従います。

1. Oracle Enterprise Manager Grid Controlコンソールにログインします。

2. 「ターゲット」タブをクリックします。「ホスト」ページが開きます。

3. 「データベース」セカンダリ・タブをクリックします。「データベース」ページが開きます。

4. 「追加」をクリックします(ページの右上部分)。「データベース・ターゲットの追加: ホストの指定」ページが開きます。

5. 懐中電灯アイコンをクリックします。検索と選択: ホスト・ウィンドウが開きます。

6. 仮想ホストを選択し、「選択」をクリックします。検索と選択: ホスト・ウィンドウが閉じ、データベースへのターゲットの追加: ホストの指定ページの「ホスト」フィールドに選択した仮想ホストが含まれています。

7. 「続行」をクリックします。「ホスト上で検出されたターゲット」ページが開きます。

8. 監視する可用性の高いデータベースを選択し、「OK」をクリックします。「データベース構成結果」ページが開きます。

9. 「OK」をクリックします。

手順3 可用性の高いManagement Agentのテスト

Management Agentの可用性が高いことをテストするには、監視している可用性の高いデータベースに対してジョブを実行し、次の手順に従います。

1. Oracle Enterprise Manager Grid Controlコンソールにログインします。

2. 次のように、SQLジョブを作成し、可用性の高いデータベースに対してこのジョブを発行します。

1. 「ジョブ」タブをクリックします。「ジョブ・アクティビティ」ページが開きます。

2. 「ジョブの作成」ボックスで、「SQLスクリプト」を選択し、「実行」をクリックします。「'SQL Script'ジョブの作成」ページが開きます。

3. 「ジョブ名」ボックスにTEST JOBと入力し、「SQLスクリプト」フィールドにSELECT * FROM ts$と入力します。

4. このページの「データベース」領域で「追加」をクリックします。「ターゲットの追加」ページが開きます。

5. 可用性の高いデータベースのホスト名(仮想ホスト名と一致)を選択し、「追加」をクリックします。「'SQL Script'ジョブの作成」ページが開きます。

6. このページの「ホスト資格証明およびデータベース資格証明」部分で、データベース資格証明を指定し、「発行」をクリックします。

3. 発行したジョブが正常に完了することを確認します。

4. (このリストの手順1および手順2に従って)同じデータベースに対して別のジョブを作成します。ただし、現在の時刻から10分間行われるようにスケジュールを設定します。

5. Oracle Fail Safe Managerを使用して、グループをフェイルオーバーします。

6. 10分後に、スケジュールを設定した2番目のジョブが正常に実行されたことを確認します。

手順4 Oracle Enterprise Manager環境からの不要なターゲットの削除

この手順に到達すると、Oracle Enterprise Manager Grid Controlコンソールには、同じデータベースに対して3つのターゲットが表示されます。Management Agentのインストール時に、可用性の高いデータベースを含むOracleコンポーネントが自動的に検出され、検出されたコンポーネントはターゲットとして追加されます。

可用性の高いデータベース・インスタンスが各クラスタ・ノードに存在するため、データベースには2つのターゲットがあります。各ターゲットは異なるManagement Agentで監視されます。さらに、仮想サーバー上でリスニングする可用性の高いManagement Agentのターゲットとしてデータベースを追加したときに、3つ目のターゲットを作成しています。

次の手順を実行して、Management Agentのインストール時に検出されたデータベース・ターゲットを安全に削除します。

1. Oracle Enterprise Manager Grid Controlコンソールにログインします。

2. 「ターゲット」タブをクリックします。「ホスト」ページが開きます。

3. いずれかのクラスタ・ノードの(仮想ではなく)物理ホスト名をクリックします。その物理ホストの「ホスト」ページが開きます。

4. 「ターゲット」ロケータ・リンクをクリックします。

5. このホストでデータベースを選択し、「削除」をクリックします。

6. クラスタ・ノードごとに、手順2から5を繰り返します。

9.3 Oracle Management Agentのグループからの削除

可用性を高めるように構成されたOracle Management Agentが不要になった場合は、該当グループからそのOracle Management Agentを削除します。削除を実行すると、Oracle Management Agentはクラスタから削除されます。

グループからOracle Management Agentを削除するには、次の手順を実行します。

1. Oracleリソース・ページを開きます。

2. 削除するOracle Management Agentを選択して、画面右側のペインの「アクション」メニュー・リストから「削除」を選択します。

3. 「リソースのグループからの削除の確認」ダイアログ・ボックスが開きます。「はい」をクリックし、リソースを削除します。

A Oracleサポート・サービスへの連絡

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

- 問題の報告

- Oracleソフトウェアのバージョンの確認

- エラー情報の表示

- Oracle Fail Safeの問題のトレース

- トレース・ファイルとアラート・ファイルの保管

A.1 問題の報告

メッセージの中には、オラクル社に連絡して問題を報告するようにお薦めしているものがあります。Oracleサポート・サービスにご連絡いただく場合は、あらかじめ次の情報をご用意ください。

- Oracleソフトウェアが動作しているハードウェア、ならびにオペレーティング・システムとそのリリース番号

- Oracleおよびその他のソフトウェア製品の完全なリリース番号

- エラーが発生したときに使用していたすべてのOracleプログラム(リリース番号を含む)

- エラー・コードやエラー・メッセージが1つまたは複数表示された場合は、それらの正確なコード番号とメッセージ・テキスト(表示順に)

- Windowsアプリケーション・イベント・ログに書き込まれたOracle Fail Safeメッセージがある場合は、それらの正確なテキスト

- 問題の重大度。次のコードに従って判断してください。

1 = プログラムは使用不可。操作に致命的な影響があります。

2 = プログラムは使用可能。操作は非常に制限されています。

3 = 機能はかぎられているが、プログラムは使用可能。操作全体にそれほど重大な影響はありません。

4 = ユーザーにより、プログラムで問題を回避。操作への影響はきわめて微小です。

- ユーザーの個人の情報と会社の情報

- 名前

- 会社名

- 会社のOracle Support ID番号

- 電話番号

- 場合によっては、オラクル社カスタマ・サポート・センターよりトレース・ファイルの提供をお願いすることがあります。
エラー出力のログをファイルに記録するトレース機能の使用方法は、A.4項を参照してください。

A.2 Oracleソフトウェアのバージョンの確認

Oracle Fail Safe Managerヘルプ・メニューで実行するソフトウェアのバージョンを確認するには、メニュー・バーの「ヘルプ」を選択し、「Oracle Fail Safe Managerのバージョン情報」を選択します。「検証」クラスタ・コマンドの出力ウィンドウに、Oracle Fail Safeと統合されているOracle製品のバージョン情報が表示されます。

A.3 エラー情報の表示

Oracle Fail Safe Managerエラー・メッセージは3つの方法で保存されます。パラメータは次のとおりです。

- 進行状況ウィンドウ: このウィンドウはユーザーに対してエラー・メッセージを表示します。「別名で保存」ボタンを選択して、エラー番号、タイムスタンプ、バージョン情報などの詳細を含む出力ウィンドウの内容をファイルに保存します。

- Windowsアプリケーション・イベント・ログ: Oracle Fail Safeリソース・モニター -- Oracleクラスタ・リソースを開始、停止および監視するクラスタ・コンポーネント -- は、Windowsアプリケーション・イベント・ログにエラー情報をポストします。Oracleクラスタ・リソースの開始、停止またはIs Aliveポーリングに関連するエラーが発生しているかどうか、このログを確認します。

- Oracle Fail Safeトレース・ファイル: Oracle Fail Safeは、エラーの原因を特定できるヒントが提供される可能性があるこれらのファイルに詳細を記録します。

A.4 Oracle Fail Safeの問題のトレース

トレース機能を使用すると、エラー情報がログ・ファイルにダンプされます。この機能はOracle Fail Safeで受け取るエラーの追跡、報告、検査に役立ちます。

トレース機能はノード単位で有効にします。

次の手順に従い、クラスタのサーバー・ノード上でトレース機能を有効にし、トレース・フラグを設定してください。

1. Windowsのレジストリ・エディタを起動します。

2. レジストリのツリー表示から、次の順序で選択します。
「HKEY_LOCAL_MACHINE」→「SOFTWARE」→「ORACLE」→「FailSafe」→「Tracing」

3. レジストリ・エディタのメニュー・バーから「編集」を選択し、「値の追加」を選択して「文字列の追加」ダイアログ・ボックスを開きます。

4. 「値の名前」フィールドに、表A-1に示されたOracle Fail Safe値を入力します。

5. 「データタイプ」フィールドにREG_SZと入力します。

6. 「OK」をクリックして「文字列エディタ」ダイアログ・ボックスを開きます。

7. 「文字列」フィールドで、表A-1に示されているOracle Fail Safe文字列を1つ以上入力します。複数の項目がある場合は、カンマで区切ってください。

8. 複数のOracle Fail Safeトレース・フラグを設定する場合は、手順3から7を繰り返します。

9. トレースが有効な各ノードでCluster Serviceサービスを再起動します。Cluster Serviceサービスを停止すると、すべてのクラスタ・リソースがクラスタの別のノードにフェイルオーバーすることに注意してください。

表A-1 クラスタのサーバー・ノードが使用するトレース・フラグ

値

文字列

説明

FSR_TRACE_OUTPUT

パスおよびファイル名

Oracle Fail SafeリソースDLLに関するトレース情報を書き込むファイルのパスおよびファイル名を指定します。Oracle Fail SafeリソースDLLは、クラスタのOracleリソースを開始、停止および監視します。次に例を示します。

C:\fsr_tracelog

FSS_TRACE_OUTPUT

パスおよびファイル名

Oracle Fail Safeサーバーに関するトレース情報のファイルのパスおよびファイル名を指定します。Oracle Fail Safe Managerクライアントによって送信されるコマンドを実行する場合に発生するサーバー・エラーは、このファイルに書き込まれます。次に例を示します。

C:\fss_tracelog

FSS_TRACE_FLAGS

AGENT

Oracle Management Agentアクティビティに関連する情報を記録します。

ALL

すべてのOracle Fail Safeトレース・メッセージのロギングを有効にします。通常、これは最も便利に使用できるフラグです。このフラグが有効になっている場合、トレース・ファイルのサイズが大きくなる可能性があります。

COM

Microsoft DCOMインタフェースに関連するアクティビティを記録します。

COMMAND_RESULT

生成されたコマンドに関連する情報を記録します。

COMMON

すべてのOracle Fail Safeコンポーネントに共通の情報(エラー・ロギングや作業アイテム処理など)を記録します。

CREATE_SA

スタンドアロン・リソース(サンプル・データベースなど)の作成に関連する情報を記録します。

CR_RES

クラスタ・リソースの作成に関連する情報を記録します。

CLUSTER_MGR

Microsoft Windowsフェイルオーバー・クラスタのクラスタ・インタフェースに関連する情報を記録します。

DB_RES

サーバーまたはリソースのモニターDLLによるデータベース・アクセスに関連する情報を記録します。

DEL_RES

クラスタ・リソースの削除に関連する情報を記録します。

DELETE_SA

スタンドアロン・リソース(サンプル・データベースなど)の削除に関連する情報を記録します。

HOME

Oracleホームの処理に関連する情報を記録します。

LOCAL_TRACE

ローカル・トレースを使用可能にして、あるクラスタ・ノードのトレース出力を、そのノードのFSS_TRACE_OUTPUTファイルに書き込むように指定します。このフラグを指定しない場合、すべてのクラスタ・ノードのトレース出力はOracle Fail Safeを実行するノード(クラスタ・グループが常駐するノード)のFSS_TRACE_OUTPUTファイルに書き込まれます。

トレースする情報のタイプを指定するために、1つ以上の追加のFSS_TRACE_FLAG文字列を指定します。LOCAL_TRACE文字列のみを指定した場合、トレース出力は作成されません。

SQLNET

Oracle Fail Safeが実行したOracle Net構成に関連する詳しい内部情報を生成します。Oracle Net構成の変更が必要な操作が実行されるたびに、情報が記録されます。これには、サンプル・データベースの作成や削除、あるいはグループに対するデータベースの追加や削除が含まれます。

VERIFY_CLUSTER

VERIFY CLUSTER操作に関する情報を記録します。

VERIFY_GR

「グループの検証」操作に関する情報を記録します。

VERIFY_SA

スタンドアロン・リソースの検証に関連する情報を記録します。

VERIFY_DB

「検証」操作に関する情報を記録します。

XML

Oracle Fail Safeコンポーネント間のXMLメッセージの交換に関連するアクティビティを記録します。

FSU_TRACE_OUTPUT

パスおよびファイル名

Oracle Fail Safeに関するトレース情報を書き込むファイルのパスおよびファイル名を指定します。Oracle Fail Safe Managerクライアントによって送信されるコマンドを実行する場合に発生するサーバー・エラーは、このファイルに書き込まれます。このファイルは、クラスタ・グループを所有しないノードで使用されます。次に例を示します。

C:\fsu_tracelog.log

注意: FSU_TRACE_OUTPUTファイルは、常に追加され、上書きされることはありません。つまり、ファイルが削除されるまで、あるいはFSU_TRACE_OUPUTレジストリ・エントリが削除または再定義されるまで、ファイルのサイズは大きくなり続けます。ファイルのサイズが大きくなりすぎないように監視し、トレース機能は短期間でのみ使用可能にすることをお薦めします。

注意:
FSS_TRACE_FLAGSにALLを使用することをお薦めします。

A.5 トレース・ファイルとアラート・ファイルの保管

Oracle Fail Safeトレース・ファイルは、プライベート・ディスクに保存する必要があります。

データベース・トレースとアラート・ファイルは、クラスタ・ディスクまたはプライベート・ディスクのいずれかに保管できます。

- クラスタ・ディスクを使用する場合は、トレース・ファイルおよびアラート・ファイルには、操作に関する完全な情報が含まれます。ただし、データベースをホストするノードに関する情報は記録されません。これらのファイルで使用されるクラスタ・ディスクは、アーカイブ・ログ・ファイルまたはデータベース・データファイルで使用されるディスク(たとえば、「サンプル・データベースの作成」操作によりファイルが配置されるディスク)である必要があります。そうでない場合、これらはグループに追加されません。

- プライベート・ディスクを使用する場合は、トレース・ファイルおよびアラート・ファイルには、操作に関するノード固有の情報がそれぞれ含まれます。ただし、データベースがフェイルオーバーまたは移動された場合、完全な履歴情報を得るには各クラスタ・ノードのファイルを同時に表示することが必要です。データがこれらのファイルに正しく書き込まれるように、それぞれのノードで有効なパス名を使用します。プライベート・ディスク上のファイルは、グループに追加されることはありません。

用語集

24×365

1日24時間、1年365日のビジネス体制。

アクティブ/アクティブ構成

すべてのクラスタ・ノードが処理を実行するクラスタ構成。片方のノードが使用できなくなった場合、使用できないノードの作業負荷を、1つ以上の他のノードが引き継ぎます。

アクティブ/パッシブ構成

1つのノードが、他のノードからのフェイルオーバーに備えて、通常はアイドル状態で待機するクラスタ構成。

可用性

システムまたはリソースが、必要なときに必要なサービスを提供する能力の程度。可用性は、装置が必要とされる合計時間のうち、アクセス可能である時間の割合として測定されます。連続したコンピューティング・サービスを必要とするビジネスでは、可用性の目標は24×365です。

Bequeathプロトコル

クライアントがネットワーク・リスナーを使用せずにOracle Databaseから情報を取り出すことのできるプロトコル。Bequeathプロトコルによって、各クライアント・アプリケーション用のサーバー・スレッドが内部的に生成されます。ある意味では、データベース接続に対してリモート・ネットワーク・リスナーが行っているのと同じ操作を、ローカルに実行するものです。

クライアント・アプリケーション

すべてのユーザー指向のアクティビティを提供するアプリケーション。アクティビティの中には、文字またはグラフィカル・ユーザー表示、画面制御、データの提示、アプリケーションの流れ、およびその他のアプリケーション固有のタスクが含まれます。

クラスタ

単一の仮想システムとして動作する、2つ以上の独立したコンピューティング・システムのグループ。

クラスタ別名

クラスタを識別し、クラスタ関連のシステム管理に使用される、ノードから独立したネットワーク名。

クラスタ・ノード

クラスタのメンバーであるWindowsシステム。

クラスタ・リソース

クラスタ・ノード上で構成および管理されるリソース。「リソース」および「スタンドアロン・リソース」も参照してください。

データファイル

表や索引などの論理データベース構造のコンテンツを含むファイル。1つ以上のデータファイルは、表領域と呼ばれる論理記憶域を形成します。あるデータファイルは1つの表領域および1つのデータベースのみに関連付けられます。

停止時間

システムまたはリソースで、必要時に必要なサービスの提供が不可能な時間の割合。停止時間は、装置が必要とされる合計時間のうち、アクセス不可である時間の割合として測定されます。

フェイルバック

優先所有者ノードが動作可能状態にリカバリした後、クラスタ・リソースのグループをフェイルオーバー・ノードから優先所有者ノードへ意図的に戻す処理。

フェイルバック・ポリシー

「グループ・フェイルオーバー・ポリシー」を参照してください。

フェイルオーバー

クラスタ・リソースを片方のノードでオフライン化し、そのリソースをもう一方のノードでオンライン化するプロセス。このプロセスは、計画的(アップグレードおよびメンテナンスの際など)または計画外(システム障害やリソース障害の場合など)のいずれかとなります。

フェイルオーバー・ノード

使用不可ノードの作業負荷を引き継ぐサーバー・ノード。

フェイルオーバー期間

クラスタ・ソフトウェアがフェイルオーバー・プロセスを停止してクラスタ・リソースをオフラインにする前に、クラスタ・リソースをあるノードから別のノードに移動し続けるユーザー指定の期間。「グループ・フェイルオーバー・ポリシー」も参照してください。

フェイルオーバー・ポリシー

「グループ・フェイルオーバー・ポリシー」または「リソース・フェイルオーバー・ポリシー」を参照してください。

フェイルオーバーしきい値

クラスタ・ソフトウェアが、指定される期間(フェイルオーバー期間)内にリソースを片方のノードからもう一方のノードに移動しようとする、試行回数の最大値。クラスタ・ソフトウェアは、指定されたフェイルオーバーしきい値に達すると、フェイルオーバー・プロセスを停止し、リソースをオフライン化します。「グループ・フェイルオーバー・ポリシー」も参照してください。

フェイルセーフ・リソース

可用性が高まるように構成されたリソース。

障害

コンピューティング・コンポーネントがその機能を正しく実行できなくなること。

汎用サービス

Microsoft Windowsフェイルオーバー・クラスタで提供される汎用サービス・リソースDLLによりサポートされるWindowsサービス。汎用サービス・リソースDLLは、標準のWindowsサービス(IPアドレス、物理ディスクおよび一部のアプリケーションなど)をクラスタ内のリソースとして構成するために使用されます。

グループ

フェイルオーバーの最小単位を形成するクラスタ・リソースの論理的な集まり。フェイルオーバーの際、リソースのグループはまとめてフェイルオーバー・ノードに移されます。グループがある特定の時点で常駐するクラスタ・ノードは1つです。サービスまたはアプリケーション、あるいはクラスタ化されたロールとも呼ばれます。

グループ・フェイルバック・ポリシー

クラスタ・リソースをフェイルオーバー・ノードから優先所有者ノードへフェイルバックする必要があるか、およびいつフェイルバックするかを決定するユーザー指定の計画。

グループ・フェイルオーバー

クラスタ・リソースのグループをあるノードでオフライン化し、そのリソースを別のノードでオンライン化するプロセス。このプロセスは、計画的(アップグレードおよびメンテナンスの際など)または計画外(システム障害やリソース障害の場合など)のいずれかとなります。

グループ・フェイルオーバー・ポリシー

クラスタ・ソフトウェアがリソースを片方のノードからもう一方のノードに移動し続ける期間(フェイルオーバー期間)と、フェイルオーバー期間中に発生するフェイルオーバー回数の最大値(フェイルオーバーしきい値)の2つのパラメータを決定するユーザー指定の計画。「フェイルオーバー期間」および「フェイルオーバーしきい値」も参照してください。

ハートビート接続

「プライベート・インターコネクト」を参照してください。

ホスト名

ネットワーク上の特定のIPアドレスを表す名前。Microsoft Windowsフェイルオーバー・クラスタでは、ホスト名はネットワーク名リソースにマップされます。「ネットワーク名」も参照してください。

インスタンス

システム・グローバル領域(SGA)と1つ以上のOracle Databaseプロセスの組合せ。データベースが起動すると、OracleはSGAを割り当て、1つ以上のOracleプロセスを開始します。インスタンスのメモリーおよびプロセスは、関連付けられたデータベースのデータを効率よく管理し、データベース・ユーザーに提供します。各インスタンスには一意のOracleシステム識別子(SID)、インスタンス名、インスタンス番号、ロールバック・セグメントおよびスレッドIDがあります。

ノード間ネットワーク接続

「プライベート・インターコネクト」を参照してください。

IPアドレス

インターネット・プロトコル(IP)・アドレス。IPアドレスは、n.n.n.nという形式になります。たとえば、138.2.134.113。

リスナー

クライアントからの要求を受け取り、その要求を適切なサーバーにリダイレクトするサービス。

Microsoft Windowsフェイルオーバー・クラスタ

Microsoft Windowsフェイルオーバー・クラスタは、サポートされているWindowsオペレーティング・システムが稼働している個々のクラスタ・ノードに機能を提供します。サポートされているオペレーティング・システム・リリースのリストは、『Oracle Fail Safeリリース・ノートfor Microsoft Windows』を参照してください。「Microsoft Windowsフェイルオーバー・クラスタ」および「Microsoft Windowsフェイルオーバー・クラスタ」も参照してください。

Microsoft Windowsフェイルオーバー・クラスタ

Windows Server 2003では、Microsoft Cluster Services(MSCS)はMicrosoft Windowsフェイルオーバー・クラスタと呼ばれます。「Microsoft Windowsフェイルオーバー・クラスタ」および「Microsoft Windowsフェイルオーバー・クラスタ」も参照してください。

Microsoft Windowsフェイルオーバー・クラスタ

Windows Server 2008では、Microsoft Cluster Services(MSCS)はMicrosoft Windowsフェイルオーバー・クラスタと呼ばれます。「Microsoft Windowsフェイルオーバー・クラスタ」および「Microsoft Windowsフェイルオーバー・クラスタ」も参照してください。

ミッション・クリティカル・アプリケーション

企業にとってきわめて重要であり、高い可用性を必要とする種類の業務機能。

ネット・サービス名

ネットワークとOracle Databaseの接続データを記述するネットワーク情報。1つのOracle Databaseに対して複数のネット・サービス名を定義できます。

ネットワーク名

Microsoft Cluster Server(MSCS)でNetBIOS名(ネットワーク上の特定のIPアドレスに変換される名前)を指す用語。「ホスト名」も参照してください。

ノード

クラスタのメンバーであるコンピューティング・システム。

グループの計画的フェイルオーバー

クライアント・アプリケーションおよびクラスタ・リソースを片方のノードでオフライン化し、もう一方のノードでオンライン化する意図的なプロセス。たとえば、『Oracle Fail Safeインストレーション・ガイドfor Microsoft Windows』には、計画的フェイルオーバーを実行してローリング・アップグレード(あるクラスタ・ノード上でハードウェアまたはソフトウェアを順番にアップグレードする際に、全リソースを別のノードにフェイルオーバーすること)を実行する方法が説明されています。「計画外グループ・フェイルオーバー」も参照してください。

可能所有者ノード

次の性質に基づいて、指定されたリソースを実行できるノード。

- 指定したリソースのリソースDLLがノードにインストールされていること。

- そのリソースがノード上で実行するよう構成されていること。

- そのリソースまたはリソースを含むグループの「可能所有者ノード」リストから、手動でノードを削除していないこと。

2つのノードからなるクラスタで、グループがフェイルオーバーできるようにする場合には、そのグループ内のすべてのリソースに対して両方のノードが可能所有者ノードである必要があります。

「可能所有者ノード」リスト

指定したリソースのリソースDLLがインストールされ、実行するよう構成されているノードのうち、明示的にセットから削除したノードを除いたすべてのノードのセット。

優先所有者ノード

可能所有者であるすべてのクラスタ・ノードが稼働している場合に、グループを常駐させるノード。「フェイルオーバー・ノード」も参照してください。

プライマリ・ノード

アクティブ/パッシブ構成において作業を実行するノード。「アクティブ/パッシブ構成」も参照してください。

プライベート・インターコネクト

クラスタ内通信専用のネットワーク接続。プライベート・インターコネクトは、あるノードの使用可否を別のノードで検出できるため、ハートビート接続とも呼ばれます。プライベート・インターコネクトは、パブリック・インターコネクトとは異なるものです。「パブリック・インターコネクト」も参照してください。

パブリック・インターコネクト

クライアントをクラスタに接続するネットワーク接続(LANやWANなど)。「プライベート・インターコネクト」も参照してください。

冗長コンポーネント

コンピューティング・システムの整合性を保護する、重複または余分なコンピューティング・コンポーネント。

信頼性

コンピューティング・システムが障害を起こさずに動作する能力。

リソース

コンピューティング・システムが使用できる物理的または論理的コンポーネント。たとえば、ディスク、ネットワークIPアドレス、Oracle Database、リスナーなどがリソースです。「クラスタ・リソース」および「スタンドアロン・リソース」も参照してください。

リソースの依存性

1グループ内のリソース間の関係。クラスタ・ソフトウェアがそれらのリソースをオンライン化およびオフライン化する順番を定義します。

リソース・フェイルオーバー・ポリシー

リソース障害によってグループのフェイルオーバーを発生させるかどうかを指定するポリシー。

リソース再起動ポリシー

リソース障害があった場合に、クラスタ・ソフトウェアが現在のノード上でそのリソースの再起動を試行するかどうかを指定し、試行する場合には一定時間内に試行する再起動の回数を指定するポリシー。

ローリング・アップグレード

ソフトウェアを次のリリースにアップグレードしている間に、クラスタ・システムがサービスを提供し続けることを可能にしたソフトウェア・インストール手法。すべてのクラスタ・システムおよびクライアント・ノードのアップグレードが完了するまで、各ノードが順々にアップグレードされて再起動されるため、このプロセスはローリング・アップグレードと呼ばれます。片方のノードが一時的にオフライン化している間、アップグレード中のノードの作業負荷は他のノードに引き継がれます。

サンプル・データベース

Oracle Fail Safeの機能を本番データベースで使用する前に試せるように、Oracle Fail Safeで提供されている、事前に構成されたオプションの初期データベース。

セカンダリ・ノード

アクティブ/パッシブ構成において、フェイルオーバーの際にプライマリ・ノードの作業を受け継ぐためにスタンバイしているノード。「アクティブ/パッシブ構成」および「プライマリ・ノード」も参照してください。

サービス名エントリ

「ネット・サービス名」を参照してください。

シェアード・ナッシング構成

すべてのクラスタ・ノードが物理的に同一ディスクにケーブル接続されていますが、ある時点で特定のディスクにアクセスできるのは、読込みおよび書込みのいずれの場合も1つのノードのみであるクラスタ構成です。

共有ストレージ・インターコネクト

クラスタ・ディスクがクラスタ内のすべてのノードからアクセス可能なI/O接続。

サイレント・モード

ソフトウェアをインストールする際に、レスポンス・ファイルを使用してOracle Universal Installerへの入力を指定できるインストール方法。

スタンドアロン・リソース

グループに含まれていないリソース。スタンドアロン・リソースは、特定のクラスタ・ノードによりホストされます。「クラスタ・リソース」および「グループ」も参照してください。

スタンバイ・ノード

優先所有者ノードに障害が発生した場合にアプリケーション処理をいつでも継続できるように準備された、アクティブ/パッシブ・アーキテクチャ内のノード。「アクティブ/パッシブ構成」および「優先所有者ノード」も参照してください。

サブネット・マスク

ネットワークID用としてアドレス内のビットがいくつ使用されるかを示す32ビット値。

透過的アプリケーション・フェイルオーバー

フェイルオーバーの発生後、クライアント・アプリケーションが自動的にデータベースに再接続し操作を再開する能力。

計画外グループ・フェイルオーバー

ソフトウェアまたはハードウェア障害に対応して自動的にトリガーされる、ソフトウェアから起動されるフェイルオーバー・プロセス。「計画外グループ・フェイルオーバー」も参照してください。

仮想アドレス

グループ内のリソースのホストになっているクラスタ・ノードとは無関係に、そのリソースにアクセスできるネットワーク・アドレス。Windowsフェイルオーバー・クラスタ上の仮想アドレスは、ネットワーク名とそれに関連付けられたIPアドレスで構成されます。仮想アドレスは、クライアント・アクセス・ポイントと呼ばれることもあります。

仮想ディレクトリ

物理ディレクトリ指定にマップされる名前。仮想ディレクトリは、ファイル構造をユーザーから隠すために指定します。物理ディレクトリが変更された場合でも、ユーザーが指定するURLは変更されません。たとえば、仮想アドレスがCompanyで、仮想ディレクトリSalesをU:\SalesInfo\Webfilesにマップしてある場合、ユーザーはhttp://Company/SalesというURLを入力して販売情報にアクセスします。

仮想サーバー

1つ以上の仮想アドレスを持つグループ。

索引

A  B  C  D  E  F  G  H  I  J  L  M  N  O  P  Q  R  S  T  U  V  W

A

abortモード

シングルインスタンス・データベースのオフライン化, 5

リソースへのアクセス, 2.2.1 アカウント

データベース・パスワード・ファイルへの追加, 8.5.1

権限と許可, 4.3

シングルインスタンスOracle Databaseの管理, 8.5

アクティブ/アクティブ構成, 3.1.2 アクティブ/パッシブ構成, 3.1.1 「リソースをグループに追加」操作

トラブルシューティング, 8.2.2

リソースをグループに追加ウィザード

Oracleシングルインスタンス・データベース, 8.3.3

シングルインスタンスOracle Databaseのグループへの追加, 8.3

認証情報, 8.3.3.4

データベース名, 8.3.3.3

インスタンス名, 8.3.3.3

Oracle Netリスナー, 8.4.2

可能所有者ノード, 8.3.3.1

前提条件, 8.3.1

サービス名, 8.3.3.3

手順, 8.3.2

tnsnames.oraファイル, 8.3.2

仮想アドレス, 8.3.3.2

管理者権限

クラスタへのログイン, 4.3.2

FSCMDコマンドによる指定, 5

アラート・ファイル, A.5 クラスタへのIPアドレス割当て, 2.4 アプリケーション・ログ

起動問題のトラブルシューティング, 7.3

アプリケーション・ソフトウェア

ローリング・アップグレード, 1.2.2

アプリケーション

フェイルオーバー後の自動再接続, 1.2.4

フェイルオーバー, 1.2.4, 2.7.2

ミッション・クリティカル, 3.1.2

アーカイブされたファイル, 8.10.7.3 認証

Oracle Enterprise Managerのプリファレンスのチェック, 8.10.8

「バッチ ジョブでログオン」アクセス権限, 8.10.8

必要な許可および権限, 4.3

REMOTE_LOGIN_PASSWORDFILE初期化パラメータ, 8.5

SYSDBAロール, 8.5.1

SYSOPER権限, 8.5.1

DBA認証のトラブルシューティング, 8.10.6

データベースでのSYSの使用, 8.5.1

可用性

RAIDテクノロジ, 2.1.1

B

バックアップ操作

スクリプトでのFSCMDコマンドの例, 5

帯域幅

複数仮想アドレスによる向上, 2.3

利点

Oracle Fail Safe, 1.2

Bequeathプロトコル・アダプタ

Oracle Fail Safeのシングルインスタンス・データベースへの接続, 8.4

C

チェックポイント

データベース・フェイルオーバーの前, 2.6.2

クライアント接続

シングルインスタンスOracle Database, 8.4.2

クライアント

リソースへのアクセス, 2.3

複数仮想アドレスによるグループのアクセス, 4.7

クラスタの接続, 2.7.2

複数仮想アドレスによるリソースへの接続, 4.7

フェイルオーバー後のシングルインスタンス・データベースへの再接続, 8.9

クラスタ別名

定義, 2.5

Oracle Fail Safe Manager, 2.5

使用, 2.5

クラスタ・ディスク

Oracleシングルインスタンス・データベース, 8.3.1

RAIDハードウェア, 1.3

冗長性, 2.1.1

「ディスク」を参照

クラスタ・グループ, 2.5

クラスタ別名ネットワーク名, 2.5

リソース, 2.5

クラスタ・ノード, 2.1

既存クラスタへの追加, 4.8

定義, 1.1

共有サーバー構成, 8.4.5

CLUSTER修飾子

FSCMDコマンド, 5

クラスタ・レジストリ

修正のための「検証」グループの実行, 8.7

クラスタ・リソース

定義, 2.2.1

クラスタ, 1.1

新規ノードの追加, 4.8

クラスタ別名, 2.5

構成, 2.1

接続, 2.5

定義, 2

各種の構成, 2.1.2

ディスク構成, 2.1.3

ディスク

「クラスタ・ディスク」を参照

概要, 2.1 メンバー, 2.1 ノード, 1.2.1, 2.1 パスワード・ファイルの同期化, 8.5.1 典型的な構成, 1.3 構成の検証, 5, 7.1.1 クラスタワイド操作

ロールバック, 8.10.3

「グループの検証」操作, 7.1.2

通信

システムの障害発生時の損失, 8.10.9

Oracle Intellignet Agentによる管理, 2.2.2

構成, 3.1

アクティブ/アクティブ, 3.1.2

アクティブ/パッシブ, 3.1.1

カスタマイズ, 3.1, 3.1

ディスク・レベル, 2.1.3

複数仮想アドレス, 4.7

シェアード・ナッシング, 2.1.3

システム・レベル, 2.1.2

典型, 1.3

ウィザード入力項目の使用, 4.2, 4.2

検証, 7.1.2, 7.1.3

クラスタへの接続

ドメイン・ユーザー・アカウント, 4.3.2

接続時間

改善, 8.4.1

破損

tnsnames.oraおよびlistener.oraファイル, 8.10.7.1

カスタム・リソース・タイプ, 2.2.4 カスタマ・サポート

連絡, A.1

構成のカスタマイズ, 3.1

D

データファイル

新規の追加, 8.7

データベース・アカウント

SYS, 8.5, 8.10.8

データベース管理者

パスワードの変更, 8.10.6

Internalとしての接続, 8.10.6

DBA_AUTHORIZATIONパラメータ, 8.5

データベース・パスワード・ファイル

データベースへのアカウントの追加, 8.5.1

データベース・リカバリ

シングルインスタンス・データベースの最適化, 8.6

データベース

新規データファイルの追加, 8.7

バックアップ操作, 8.7

FSCMDコマンドの使用, 5

DBAパスワードの変更, 8.10.6 チェックポイント取得, 2.6.2 クライアントによるシングルインスタンス・データベース接続の損失, 8.10.9 構成データ, 8.3.3 共有サーバーを使用するためのデータベース・リソースの構成, 8.4.5 ウィザード入力項目の使用による構成, 4.2 EXCLUSIVEアクセス, 8.5 グループ・リソース, 2.2.2 識別情報, 8.3.3.3 接続時間の改善, 8.4.1 Is Aliveポーリング, 8.10.6 スタンドアロン用のリスナー, 8.2.4 初期化ファイル内のLOCAL_LISTENERパラメータ, 8.4.5.1 name, 8.3.3.3 ネット・サービス名エントリ, 8.2.1 共有サーバーを使用するOracle8i以上, 8.4.5.1 不安定な状態の解決, 8.10.4 セキュリティ, 8.5 SHAREDアクセス, 8.5 共有サーバーおよびWindowsフェイルオーバー・クラスタ・ノード, 8.4.5 構成の手順, 8.3.2, 8.3.2 パスワード・ファイルの同期化, 8.5.1 オフライン化, 5, 5, 8.7

パスワードの変更に起因, 8.10.6

コールド・バックアップ操作, 8.7

保留タイムアウト, 8.10.4

問題, 8.10.6

セカンダリ・ノード上の停止テスト, 4.2 リモート・クライアント・アクセスのためのtnsnames.oraファイルの更新, 8.4.3.1 アップグレード, 8.2.3 Oracle Database Upgrade Assistantを使用したアップグレード, 8.5.3 共有サーバーの使用, 8.4.5 コールド・バックアップ操作のためのSQL*Plusの使用, 8.7 検証, 7.1.2, 7.1.3 仮想アドレス, 8.3.3.2 「リソース」を参照 DBA_AUTHORIZATIONパラメータ, 8.5 DBCA

「Oracle Database Configuration Assistant」を参照

DBNameパラメータ, 8.3.3.3 専用サーバー・モード

USE_SHARED_SOCKETSリスナー・パラメータ, 8.4.1

依存性

リソース, 2.2.3, 2.2.3

DISABLEISALIVEパラメータ, 5, 8.10.5 検出

リソース, 4.4

スタンドアロン・シングルインスタンス・データベース, 8.1

サンプルのスタンドアロン・シングルインスタンス・データベース, 8.1

ディスク装置

「グループの検証」による変更の検出, 8.10.2

グループ内のリソース, 2.2.2

追加後の検証, 8.10.2

ディスク

構成, 2.1.3

リソース・タイプ, 2.2.4

「クラスタ・ディスク」を参照

DISPATCHERSパラメータ

完全なリスナー情報の指定, 8.4.5.1

情報の指定, 8.4.5.1

ドメイン・アカウント

Oracle Fail Safe, 4.3

Oracle Fail Safe Manager, 4.3

デフォルト値の更新, 8.2.1

DOMAIN修飾子

FSCMDコマンド, 5

DUMPCLUSTERパラメータ, 5 Dynamic Link Library(DLL)

カスタム, 2.2.4

FsResOdbs.dll, 2.2.4

汎用サービス, 2.2.4, 2.2.4

IPアドレス, 2.2.4

リソースの管理, 2.2.4

物理ディスク, 2.2.4

Is Aliveポーリング間隔でのシングルインスタンス・データベース・アクセス, 8.10.4

E

ENABLEISALIVEパラメータ, 5, 8.10.5

エラー処理

スクリプト, 8.10.1

エラー

FS-10066, 8.10.7.1

FS-10070, 8.10.7.1

FS-10101, 8.10.8

ORA-01031, 8.10.8

報告, A.1

不十分な権限に対する戻り, 8.10.8

トレース・ファイル内の情報の追跡, A.4

ユーザー認証, 8.10.8

Oracle Netのリスナー・ログへの書込み, 8.10.4

外部プロシージャ

構成, 8.4.4

F

フェイルバック

「優先所有者ノード」リストによる影響, 2.7.1, 2.7.1

グループの移動操作による影響, 2.7.1

フェイルバック・ポリシー

情報のダンプ, 7.2

指定, 2.7

「検証」グループ・アクションによる検証, 7.1.2

「グループの検証」操作による検証, 8.10.2

フェイルオーバー期間, 2.6.8 フェイルオーバー・ポリシー

グループ, 2.6.8

フェイルオーバーしきい値, 2.6.8 フェイルオーバー, 2.6

アプリケーション, 1.2.4

アプリケーションの自動再接続, 1.2.4

「検証」コマンドによるチェック, 4.2

クライアント・アプリケーション, 2.7.2

データベースのチェックポイント取得, 2.6.2

定義, 2.1

バックアップ操作中の使用不可, 8.7

リソース障害に起因, 2.6.1.1

ポリシーに関する情報のダンプ, 7.2

「可能所有者ノード」リストによる影響, 2.6.11

「優先所有者ノード」リストによる影響, 2.6.11

リソース再起動ポリシーによる影響, 2.6.9

最高速, 3.1.1

ロード・バランス, 2.6

グループ, 2.2.2

アクティブ/アクティブ構成, 3.1.2

反復を制限する, 2.6.8

ノード障害, 2.6.1.2

グループの移動先のノード, 2.6.11

計画的, 2.6, 2.6.2

トランザクションの再実行, 1.2.4

トラブルシューティング, 8.10.5

単位, 2.2.2

計画外, 2.6

「検証」グループ・アクションによる検証, 7.1.2

「グループの検証」操作による検証, 8.10.2

障害

計画外, 2.6.1

防止のためのリソースの検証, 7.1.2, 7.1.3

ファイバ・チャネル

共有ストレージ・インターコネクト, 1.3

ファイルの破損

tnsnames.oraおよびlistener.oraファイル, 8.10.7.1

ファイル

アラート, A.5

アーカイブ, 8.10.7.3

ロールバック, 8.10.7.4, 8.10.7.4

トレース, A.5

フラグ

Oracle Fail Safeエラーのトレース, A.4

FSCMDコマンド, 1.2.2

DISABLEISALIVEパラメータ, 5, 8.10.5

DUMPCLUSTERパラメータ, 5

ENABLEISALIVEパラメータ, 5, 8.10.5

スクリプトでの使用例, 5

例, 5

MOVEGROUPパラメータ, 5

OFFLINEGROUPパラメータ, 5

OFFLINERESOURCEパラメータ, 5

ONLINEGROUPパラメータ, 5

ONLINERESOURCEパラメータ, 5

パラメータと修飾子, 5

構文, 5

使用上の注意, 5

VERIFYALLGROUPSパラメータ, 5

VERIFYCLUSTERパラメータ, 5

VERIFYGROUPパラメータ, 5

FsDbError.batスクリプト, 8.10.1 FSR_TRACE_OUTPUT値, A.4 FsResOdbs.dllファイル

機能, 2.2.4

FSS_TRACE_OUTPUT値, A.4

G

汎用サービス

定義済, 2.2.4

Windowsサービス, 2.2.4

リソース・タイプ, 2.2.4

GR_VERIFY文字列, A.4 グループ

帯域幅追加, 2.3

シングルインスタンス・データベースの追加, 8.3.2

仮想アドレスの追加, 2.3

ネットワーク名の修正, 8.10.7.1

DBAパスワードの不一致, 8.10.6

定義, 2.2.2

情報のダンプ, 7.2

リソースの例, 2.2.2

フェイルオーバー, 2.2.2

フェイルオーバー期間, 2.6.8

フェイルオーバー・ポリシー, 2.6.8

フェイルオーバーしきい値, 2.6.8

移動, 5

複数仮想アドレス, 4.7

Oracleホーム, 4.6

所有権, 2.2.2

オンライン化, 5

移入, 4.2

「優先所有者ノード」リスト, 2.6.10

シングルインスタンス・データベースを追加するための権限, 8.10.8

リソースの依存性, 2.2.3

オフライン化, 5

クラスタ内のすべてのグループの検証, 5

リソースの検証, 7.1.2

仮想アドレス, 8.3.3

複数仮想アドレスの使用, 4.7

H

ハードウェア

構成, 1.3

RAID, 1.3

ハートビート接続, 2.1

定義, 1.3

I

immediateモード

シングルインスタンス・データベースのオフライン化, 5

初期化パラメータ・ファイル

LOCAL_LISTENERパラメータの削除, 8.4.5.1

SPFILEのエクスポート, 8.3.3.3.1

可用性の高いシングルインスタンス・データベース, 8.3.3.3, 8.3.3.3

場所, 8.3.3.3

PFILE, 8.3.3.3.1

配置, 8.3.3.3

REMOTE_LOGIN_PASSWORDFILE初期化パラメータ, 8.5, 8.10.6

SPFILEを指定する際の制限事項, 8.3.3.3.1

インストール

対話式, 1.2.2

Oracle Fail Safe, 1.2.2

サイレント・モード, 1.2.2

レスポンス・ファイルを使用, 1.2.2

インスタンス名

可用性の高いシングルインスタンス・データベース, 8.3.3.3

「SID」を参照

不十分な権限, 8.10.8, 8.10.8 インターコネクト

プライベート・ノード間接続, 2.1

共有ストレージ, 2.1, 8.10.3

内部クラスタ通信

仮想アドレスの構成, 8.4.3.1

クラスタ内通信, 1.3 IPアドレス

クラスタへの割当て, 2.4

必要数の決定, 2.4

リスナー間での重複, 8.10.7.1

リソース・タイプ, 2.2.4

Is Aliveポーリング

無効化, 5, 8.10.5

DLLファイルの機能, 2.2.4

バックアップ操作中の影響, 8.7

有効化, 8.10.5

再度の使用可能設定, 5

J

ジョブ

アクセス問題のトラブルシューティング, 8.10.8

L

リスナー制御ユーティリティ(LSNRCTL)

リスナーの作成, 8.10.7.2

listener.oraファイル, 4.2

アーカイブ, 8.10.7.3

構成データの確認, 8.10.4

複数の構成, 8.2.4

例, 8.10.7.1

EXTPROC接頭辞, 8.4.4

変更, 8.10.7.1

仮想サーバーの構成で発生する問題, 8.10.7.1

ロールバック・ファイル, 8.10.7.1

サンプル定義, 8.10.7.1

Oracle Database Configuration Assistantによる更新, 8.2.1

リスナー

共有サーバーのための変更, 8.2.5

構成, 4.2

複数のリスナーを伴うノードでのOracle Netの構成, 8.2.4

グループに追加するシングルインスタンス・データベース用に作成, 8.4.2

新規作成, 8.10.7.2

リスナー制御ユーティリティ(LSNRCTL)を使用した作成, 8.10.7.2

ロールバック・ファイル内の定義, 8.10.7.1

共有ソケットを使用可能にする, 8.4.1

ログ・ファイル, 8.10.4

ネットワーク・リソース, 2.2.2

出力ファイル, 8.10.7.2

定義の変更または作成後の問題, 8.10.7.1

作成時の問題, 8.10.7.2

LOCAL_LISTENERパラメータへの指定, 8.4.5.1

DISPATCHERSパラメータへの情報指定, 8.4.5.1

起動, 8.2.4

トラブルシューティング, 8.10.4

ロード・バランス, 2.6

アクティブ/アクティブ構成, 3.1.2

静的, 2.6.2

Local Area Network, 1.3 LOCAL_LISTENERパラメータ

シングルインスタンス・データベース・パラメータ・ファイルへの追加, 8.2.5

シングルインスタンス・データベースをグループから削除した後の削除, 8.4.5.1

リスナーの指定, 8.4.5.1

グループの情報の更新, 8.4.5.1

シングルインスタンス・データベース・パラメータ・ファイルへの書込み, 8.4.5.1

LOGFILE修飾子

FSCMDコマンド, 5

LSNRCTLユーティリティ

リスナーの問題のトラブルシューティング, 8.10.7.2

M

管理操作

シングルインスタンス・データベース, 8.7

管理

クラスタ・セキュリティ, 4.3

クライアント・システム上のtnsnames.oraファイル, 8.3.2, 8.4.3.1

クラスタ別名の使用, 2.5

Microsoft Windowsフェイルオーバー・クラスタ・マネージャ

トレース中の使用, A.4

Microsoft Windowsフェイルオーバー・クラスタ

リソース・タイプ, 2.2.4

ミッション・クリティカル・アプリケーション

アクティブ/アクティブ構成, 3.1.2

グループの移動操作

フェイルバックへの影響, 2.7.1

MOVEGROUPパラメータ, 5 複数Oracleホーム, 4.6

アドレスおよびシングルインスタンス・データベースSID名の重複のチェック, 8.10.7.1

複数のリスナーの構成, 8.2.4

複数のリスナー, 8.2.4

listener.oraファイルのシングルインスタンス・データベースSID, 8.10.7.1

検証コマンドによるtnsnames.oraの更新, 8.2.1

N

ネット・サービス名, 8.3.3.3

シングルインスタンス・データベース用の追加, 8.2.1

デフォルト・ドメイン名による追加, 8.4.3.1

デフォルトのドメイン名, 8.4.3.1

定義

アーカイブされた構成ファイルでの参照, 8.10.7.3

シングルインスタンス・データベースをグループに追加した後のエントリ, 8.4.3.1 新規シングルインスタンス・データベースのエントリ, 8.2.1 可用性の高いシングルインスタンス・データベース, 8.3.3.3 仮想サーバーの構成時, 8.10.7.1 ネットワーク構成

sqlnet.oraファイル内のドメイン名の値の更新, 8.2.1

ネットワーク名

クラスタ別名, 2.5

グループ用の修正, 8.10.7.1

ネットワーク

構成

可用性の高いシングルインスタンス・データベース, 8.4.2

複数のリスナーを伴うノードでのOracle Net, 8.2.4

更新, 8.2.1

「グループの検証」による検証, 8.10.2

パブリック情報およびプライベート情報のダンプ, 7.2 仮想サーバーの構成時に検出される問題, 8.10.7.1 tnsnames.oraファイルのプロトコル情報, 4.2 構成情報のトレース, A.4 ノード

グループのフェイルオーバー先, 2.6.11

ノード障害

影響, 2.7.2

フェイルオーバー, 2.6.1.2

NODE修飾子

FSCMDコマンド, 5

ノード

既存クラスタへの追加, 4.8

クラスタ, 1.2.1

定義, 2.1

可能所有者, 2.6.7

優先, 2.7

グループを所有する優先順位, 2.6.10

normalモード

シングルインスタンス・データベースのオフライン化, 5

O

OFFLINE修飾子

FSCMDコマンド, 5

OFFLINEGROUPパラメータ, 5 オフライン・オプション・モード, 5 OFFLINERESOURCEパラメータ, 5 ONLINEGROUPパラメータ, 5 ONLINERESOURCEパラメータ, 5 オペレーティング・システム認証, 8.3.3.4 ORA_DBA

Windowsオペレーティング・システム・グループ, 8.3.3.4

ORA_sid_DBA

Windowsオペレーティング・システム・グループ, 8.3.3.4

Oracle Database Configuration Assistant(DBCA), 8.2.1

Oracle Net構成の作成, 8.2.1

ネット・サービス名エントリ, 8.2.1

Database Upgrade Assistant

シングルインスタンス・データベースのアップグレード, 8.5.3

Oracle Enterprise Manager

認証の問題, 8.10.8

ユーザー資格証明の設定, 8.10.8

認証の問題のトラブルシューティング, 8.10.8

クライアント接続の問題のトラブルシューティング, 8.10.8

アクティブ/アクティブ構成での使用, 3.1.2

Oracle Fail Safe

インストール, 1.2.2

Oracle Fail Safe Manager, 1.1

クラスタ別名, 2.5

Oracle Fail Safe Serverの前のリリースとの互換性, 4.6

概要, 1.2.2

ツリー・ビュー, 1.2.2

検証ツール, 1.2.2

ウィザード, 1.2.2

Oracle Fail Safe Server

説明, 1.1

Oracle Fail Safe Managerのリリース, 4.6

「Oracle Fail Safe」も参照してください。

Oracleホーム

グループ, 4.6

複数, 4.6

名前, 7.1.1

Oracle Intelligent Agent

通信の管理, 2.2.2

Oracle Net Assistant

ネットワーク・ファイルの再作成のための使用, 8.10.7.1

Oracle Netリスナー

動作, 8.2.2

構成, 8.4

作成, 8.4

Oracle Netネットワーク

アーカイブされた構成ファイル, 8.10.7.3

tnsnames.oraファイルの変更, 8.4.3.1

グループ内のリソース, 2.2.2

ロールバック・ファイル, 8.10.7.4

シングルインスタンス・データベースの構成, 8.4.3

構成情報のトレース, A.4

構成の検証, 8.10.4

Oracleサポート

連絡, A.1

Oracle7データベース

「データベース」を参照

Oracle8iデータベース

「データベース」を参照

出力ファイル

リスナー, 8.10.7.2

所有者ノード

「「可能所有者ノード」リスト」を参照

所有権

グループ, 2.2.2

P

パラメータ・ファイル

「初期化パラメータ・ファイル」を参照

パラメータ

tnsnames.oraファイルのSERVER=DEDICATED, 8.4.5

USE_SHARED_SOCKETSリスナー・パラメータ, 8.4.1

パスワード・ファイル

同期, 8.5.1

パスワード

変更によるグループの問題, 8.10.4

DBAアカウントのための変更, 8.10.6

REMOTE_LOGIN_PASSWORDFILEパラメータでの問題, 8.10.6

保留タイムアウト値

設定, 8.10.4

トラブルシューティング, 8.10.4

パフォーマンス

アクティブ/アクティブ構成, 3.1.2

許可

不十分なため返されるエラーORA-01031, 8.10.8

PFILE

「初期化パラメータ・ファイル」を参照

計画的フェイルオーバー

静的ロード・バランス, 2.6.2

グループの計画的フェイルオーバー, 2.6.2 計画的メンテナンス, 2.6.2 ポリシー

フェイルオーバー情報およびフェイルバック情報のダンプ, 7.2

ポーリング

障害, 8.10.4, 8.10.6

「可能所有者ノード」リスト

フェイルオーバーへの影響, 2.6.11

リソースへの影響, 2.6.7

シングルインスタンスOracle Database用, 8.3.3.1

フェイルオーバー・ノードの決定, 2.6.11

リソース, 2.6.7

「検証」グループ, 2.6.7

「グループの検証」コマンド, 4.8

PowerShellコマンドレット

アクティブ/アクティブ構成での使用, 3.1.2

プリファレンス

アクセス問題を回避するための設定, 8.10.8

「優先所有者ノード」リスト

フェイルバックへの影響, 2.7.1, 2.7.1

フェイルオーバーへの影響, 2.6.10, 2.6.11

グループの移動操作, 2.7.1

プライベート・インターコネクト, 1.3, 2.1 権限

各クラスタ・ノードでの付与, 8.5.1

必須, 4.3

プロトコル・アドレス, 8.4.2 パブリック・インターコネクト, 1.3 PWD修飾子

FSCMDコマンド, 5, 5

Q

クォーラム・ディスク

情報のダンプ, 7.2

R

RAID

ハードウェア, 1.3

テクノロジ, 2.1.1

冗長性

サーバー, 2.1.1

登録

リソースの情報のダンプ, 7.2

REMOTE_LOGIN_PASSWORDFILE初期化パラメータ, 8.10.6

設定, 8.10.4

リソース・タイプ

カスタム, 2.2.4

汎用サービス, 2.2.4

IPアドレス, 2.2.4

Microsoft Windowsフェイルオーバー・クラスタ, 2.2.4

Oracle MTS Service, 2.2.4

物理ディスク, 2.2.4

リソース, 1.1

アクセス, 2.2.1

仮想サーバーを介したアクセス, 2.3

クライアントのアクセス, 2.1

定義, 2.2.1

依存性, 2.2.3, 2.2.3

検出, 4.4

データベース構成に使用するディスク, 4.2

DLL, 2.2.4

グループの「ノード」プロパティ・ページでの変更による影響, 2.6.7

例, 2.2.2

フェイルオーバー・ポリシーによるグループへの影響, 2.6.8

障害, 2.6.1.1

オンライン化, 5

FSCMDの使用, 5

「可能所有者ノード」リスト, 2.6.7 名前の変更, 4.5 構成の誤りの修正, 8.10.2 再起動ポリシー, 2.6.9 優先所有者ノードへの戻り, 2.7 オフライン化, 5, 5

FSCMDの使用, 5

構成の検証, 7.1.2, 7.1.2, 7.1.3 ロールバック

クラスタワイド操作, 8.10.3

ファイル, 8.10.7.1, 8.10.7.4

ローリング・アップグレード

アプリケーション・ソフトウェア, 1.2.2

S

サンプル・データベース

必要な権限, 8.10.8

スクリプト

FsDbError.batスクリプト, 8.10.1

アクティブ/アクティブ構成のPowerShellコマンドレット, 3.1.2

シングルインスタンス・データベースをオンライン化できない場合のエラー処理, 8.10.1

FSCMDコマンドの使用, 5, 5

セカンダリ・ノード

データベース・インスタンスの作成, 4.2

データベース停止のテスト, 4.2

セキュリティ

複数仮想アドレスによる向上, 2.3

要件

シングルインスタンス・データベース, 8.5

ノード上のパスワード・ファイルの同期化, 8.5.1 サーバー・ノード

再起動の試行, 2.7.2

クラスタ・ポーリングの障害, 8.10.6

クライアント接続の損失, 8.10.9

トレース・フラグ, A.4

サーバーの冗長性, 2.1.1 SERVER=DEDICATEDパラメータ, 8.4.5 サービス名

「ネット・サービス名」を参照

SERVICE_NAMEパラメータ

Oracle Database Configuration Assistantによる追加, 8.2.1

シェアード・ナッシング構成, 2.1.3 共有サーバー

Oracle8i以上のデータベースのための構成, 8.4.5.1

SERVER=DEDICATEDパラメータ, 8.4.5

共有ソケット

サード・パーティ製のプロキシ・サーバー, 8.4.1

使用, 8.4.1

共有ストレージ・インターコネクト, 1.2.1, 2.1

ファイバ・チャネル, 1.3

停止

データベースのモード, 5

SID

シングルインスタンス・データベースのための入力, 8.10.7.1

tnsnames.oraファイルのエントリ, 4.2

複数のリスナー, 8.2.4

Oracle Database Configuration Assistantによって追加された名前, 8.2.1

リスナー間で重複した名前, 8.10.7.1

SID_DESCパラメータ, 8.2.1

新規シングルインスタンス・データベース用の追加, 8.2.1

シングルインスタンス・データベースをグループに追加した後の更新, 8.4.3.2

サイレント・モードのインストール, 1.2.2 シングルインスタンス・データベース

クライアントによる接続の損失, 8.10.9

共有サーバーを使用するためのデータベース・リソースの構成, 8.4.5

オンライン化の障害のエラー処理, 8.10.1

初期化パラメータ・ファイル, 8.3.3.3

インスタンス名, 8.3.3.3

管理操作, 8.7

「可能所有者ノード」リスト, 8.3.3.1

グループへの追加に対する前提条件, 8.3.1

サービス名, 8.3.3.3

アップグレード, 8.5.3

ソフトウェア構成, 1.3 SPFILE

「初期化パラメータ・ファイル」を参照

SQL*Plus

管理作業の実行, 8.7

SQLNET文字列, A.4 SQLNET.AUTHENTICATION_SERVICESパラメータ

シングルインスタンス・データベースをグループに追加した後の更新, 8.4.3.3

sqlnet.oraファイル

シングルインスタンス・データベースをグループに追加した際に行われる更新, 8.4.3.3

デフォルト・ドメイン値の更新, 8.2.1

スタンドアロン・データベース

検出, 8.1

リスナーの検索, 8.2.4

共有サーバー, 8.2.5

検証, 4.1, 7.1.3

検証, 4.1, 7.1.3

表示, 8.1

スタンドアロン・リソース

検出, 4.4

各リソースの索引エントリを参照

スタンバイ構成, 3.1.1 静的ロード・バランス, 2.6.2 文字列

Oracle Fail Safeのトレース, A.4

SYSアカウント, 8.5, 8.10.8, 8.10.8 SYSDBA権限, 8.5.1 SYSOPER権限, 8.5.1

T

一時表

フェイルオーバー, 8.3.1

サード・パーティ製のプロキシ・サーバー

共有ソケットの使用, 8.4.1

TNSリスナー

ネット・サービス名の更新, 8.2.4

TNS_ADMIN Windows環境変数, 8.4.2 TNS_ADMIN Windowsレジストリ・パラメータ, 8.4.2 tnsnames.oraファイル, 4.2

アーカイブ, 8.10.7.3

Oracle Net構成データのチェック, 8.10.4

EXTPROC_CONNECTION_DATAネット・サービス名エントリ, 8.4.4

可用性の高いシングルインスタンス・データベースのための変更, 8.4.2

シングルインスタンス・データベース検出のための分析, 8.1

仮想サーバーの構成で発生する問題, 8.10.7.1

ロールバック・ファイル, 8.10.7.1

SERVER=DEDICATEDパラメータ, 8.4.5

シングルインスタンスOracle Database, 8.3.2

Oracle Database Configuration Assistantによる更新, 8.2.1

更新, 8.4.2

デフォルト・ドメイン名の値での更新, 8.2.1

トレース・ファイル, A.5 トレース

有効化, A.4

フラグ, A.4

transactionalモード

データベースのオフライン化, 5

トランザクション

フェイルオーバー, 1.2.4

透過的アプリケーション・フェイルオーバー, 8.9 ツリー・ビュー, 1.2.2

クラスタの移入, 2.5

トラブルシューティング

クラスタへのアクセス, 8.10.8

仮想アドレスの構成, 8.10.7.1

データベース, 8.10

Oracle Enterprise Managerを使用したセキュリティ・アクセス, 8.10.8

起動問題, 7.3

グループをオンライン化できない, 8.10.4

シングルインスタンス・データベースに接続できないユーザー, 8.4

検証ツール, 7.1

U

計画外フェイルオーバー, 2.6.1

シングルインスタンス・データベースのアップグレード, 8.5.3

USE_SHARED_SOCKETSパラメータ, 8.4.1

ユーザー

Oracle Fail Safe Managerのドメイン・アカウント, 4.3.2

ユーザー資格証明

設定, 8.10.8

USER修飾子

FSCMDコマンド, 5

V

「検証」グループ・アイコン

目的, 7.1.2

「検証」グループ操作

概要, 7.1.2

「可能所有者ノード」リスト, 2.6.7

クラスタ・レジストリ内の情報の更新, 8.7

「検証」操作, 7.1.3, 7.1.3

新規データベースに対する実行, 8.2.1

トレース, A.4

「クラスタの検証」操作

目的, 7.1.1

「グループの検証」操作

FSCMDコマンド, 5

ロギング情報, A.4

「可能所有者ノード」リスト, 4.8

リソース依存性の更新, 8.10.2

検証ツール, 1.2.2 VERIFY_DB文字列, A.4 VERIFYALLGROUPSパラメータ, 5 VERIFYCLUSTERパラメータ, 5 VERIFYGROUPパラメータ, 5 確認

グループの使用, 8.10.4

仮想アドレス, 1.2.1

クラスタ別名, 2.5

定義, 2.3

シングルインスタンスOracle Database, 8.3.3.2

グループ, 8.3.3

識別, 2.3

内部クラスタ通信, 8.4.3.1

複数, 2.3, 4.7

グループ内の複数の仮想アドレスの理由, 4.7

構成の問題のトラブルシューティング, 8.10.7.1

仮想サーバー, 1.2.1

構成, 2.3

構成の問題, 8.10.7.1

定義, 2.3

リスナー障害, 8.10.7.1

複数, 4.7

複数仮想アドレス, 2.3

ネットワーク構成, 8.4.2

構成時のtnsnames.oraファイルに対する更新, 8.4.2

W

Wide Area Network, 1.3

Windowsクラスタ

「クラスタ」を参照

Windows環境変数

TNS_ADMIN, 8.4.2

Windowsフェイルオーバー・クラスタ

クラスタ・ソフトウェア, 1.1

Is Aliveポーリング, 2.2.4

保留タイムアウト値, 8.10.4

Windowsオペレーティング・システム・グループ

ORA_DBA, 8.3.3.4

ORA_sid_DBA, 8.3.3.4

Windowsレジストリ・パラメータ

TNS_ADMIN, 8.4.2

ウィザード, 1.2.2

入力項目, 4.2

作業負荷

多大な負荷に耐えうる保留タイムアウトの設定, 8.10.4

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