| Oracle® Fail Safe概要および管理ガイド リリース4.1 for Microsoft Windows B72446-01 |
|
 前 |
 次 |
Oracle Fail Safeにより、Microsoft Windowsフェイルオーバー・クラスタを使用して構成されたWindowsクラスタで稼働しているシングルインスタンスOracle Database(Oracle Database Standard EditionとOracle Database Enterprise Editionの両方)の可用性が向上します。
シングルインスタンスOracle Databaseの可用性を高めると、1つのクラスタ・ノードが停止または故障した場合でも、別のクラスタ・ノードでデータベースが再起動され、そのデータベースにアクセスするアプリケーションとデータベースとの接続が失われるのはほんの一瞬にすぎません。こうしたフェイルオーバー・イベントの発生後、アプリケーションはTAFによって自動的にデータベースに再接続できるため、フェイルオーバーがユーザーの作業に悪影響を与えることはありません。
この章では、次の項目について説明します。
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リソースを選択します。
次の項では、スタンドアロン・シングルインスタンス・データベースのためのOracle Netの構成について簡単に説明します。
Oracle Database Configuration Assistant(DBCA)を使用してスタンドアロン・シングルインスタンス・データベースを作成すると、新規データベースの情報が次のようにOracle Net構成に追加されます。
DBCAにより、データベースのSID_DESCパラメータがデフォルトのlistener.oraファイル内のデフォルト・リスナーに追加されます。このSID_DESCパラメータは、データベースSID名で構成されます。
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ホームのデフォルト・ドメイン名をネット・サービス名エントリに追加します。
リスナーの定義でシステムのホスト名が使用されている場合、このリスナーはホスト名に関連付けられている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)
)
Oracle Databaseソフトウェアをアップグレードする場合、リスナーもアップグレードする必要があります。旧バージョンのリスナーSIDリストのエントリをメンテナンスするには、次のように、アップグレード先のバージョンのリスナーにエントリを移します。
アップグレード元のデータベース・ソフトウェア・リリースに対応するlistener.oraファイルを見つけます。
アップグレード元のリスナーの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)
)
)
アップグレード元のデータベースのリスナーを停止し、リスナーの起動状態を手動に変更します。
アップグレード先のデータベースのリスナーを起動します。
使用中のデータベース・ソフトウェアのリリースに対応するリスナーを使用しない場合、Oracle Fail Safeで次の操作を実行するときに問題が発生します。
データベース・リソースのグループへの追加
グループの検証
データベース・リソースのグループからの削除
Oracle Fail Safeでは、スタンドアロン・データベースのリスナーの検索時に、すべてのOracleホームで定義されたリスナーが検索されます。複数のOracleサーバーが(1つ以上のOracleホームに)インストールされている場合は、複数のリスナーが存在する可能性があります。複数のリスナーがある場合でも、Oracle Fail Safeではスタンドアロン・データベースのリスナーを検索することが可能です。
システムに追加のOracleホームをインストールした後、使用するリスナーの数およびそのシステムで使用するリスナーを決定する必要があります。その後で、次のことを行います。
使用しないリスナーの定義をlistener.oraファイルから削除します。これにより、Oracle Fail Safeで不要なリスナーが検出されなくなります。
SIDの同じアドレスで複数のリスナーを実行していないことを確認します。(同じアドレスまたはSIDで別のアクティブ・リスナーが動作中の場合は、Oracleリスナーを起動できません。)
使用するリスナーを起動します。Windowsの「サービス」の「スタートアップ」リストで、これらのリスナーが自動的に起動するように設定されていることを確認します。
スタンドアロン・データベースのリスナーを検索する際、listener.oraファイルに定義されたリスナーの状態によって検索結果が左右されます。Oracle Fail Safeでリスナーを検索する順序は、次のとおりです。
起動しているリスナー。
停止しているリスナー。
Windowsサービス定義のないリスナー。
たとえば、データベースの2つのリスナーが、それぞれ別のOracleホームにあるとします。このとき、ホーム1のリスナーは停止しており、ホーム2のリスナーは起動しているとします。Oracle Fail Safeでは、起動しているリスナーを最初に検索するため、システム上の2つのホームを検索するとホーム2のリスナーが検出されます。起動しているリスナーが見つかると、検索を中止します。起動しているリスナーが見つからない場合は、停止しているリスナーを検索し、それでも見つからない場合は、次のリスナー・グループを検索します。
|
注意: Oracle Fail Safeのどの操作においても、実行前にスタンドアロン・シングルインスタンス・データベースのリスナーが予定どおりの状態(停止または起動)であることを確認してください。 |
可用性が高まるようにデータベースが構成されている場合、Oracle Fail Safeではデフォルト・リスナーの調整を行います。この調整は、スタンドアロン・データベースを含むすべてのデータベースのOracle Net構成に影響を与えます。このため、クラスタ内のデータベースが可用性が高まるように構成されている場合、Oracle Fail Safe環境のすべてのスタンドアロン・データベースのOracle Net構成を調整する必要があります。
スタンドアロン・シングルインスタンス・データベースの共有サーバーの構成がデフォルト・リスナーに依存している場合、データベース・パラメータ・ファイル内にリスナー・パラメータが指定されていません。(デフォルト・リスナーとは、ノードのホスト名、デフォルト・ポート番号およびTCPプロトコルをリスニングするリスナーです。)この場合、Oracle Fail Safeでホスト名ではなくIPアドレスを使用するようにデフォルトのリスナーが変更されると、その構成が機能しなくなります。
LOCAL_LISTENERパラメータをデータベース初期化パラメータ・ファイルに追加します。このLOCAL_LISTENERパラメータはOracle Netデフォルト・リスナーのアドレスになるネットワーク名を示します。
データベースのデータベース初期化パラメータ・ファイルを見つけて、そのファイルにLOCAL_LISTENERパラメータを追加します。
LOCAL_LISTENER = network-name
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)
tnsnames.oraファイルにnetwork-nameエントリを作成します。
手順2で調べたアドレスを使用して、tnsnames.oraファイルにnetwork-nameのエントリを作成します。
この例では、次のようにエントリを作成します。
network-name= (ADDRESS=
(PROTOCOL=TCP)
(HOST=192.0.2.1)
(PORT=1521)
)
この変更は、データベースが再起動された時点で有効になります。
可用性が高まるようにシングルインスタンス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.3.3項を参照してください。
リソースが属するグループは1つのみです。このため、2つのシングルインスタンス・データベースが同じディスク・ドライブを共有する場合は、この2つのデータベースを同一グループ内に指定する必要があります。
フェイルオーバーの際、一時表内のデータはフェイルオーバーされません。(ソートやハッシュ結合など)一時表や一時表領域を使用する操作では、フェイルオーバー・ノードで再起動されるときに必要な一時オブジェクトが再作成されます。ただし、一時表内の特定のデータに依存するアプリケーションが正常に機能することを確認する必要があります。
一時表の詳細は、『Oracle Database概要』の一時表に関する説明を参照してください。
グループには、少なくとも1つの仮想アドレスが含まれている必要があります。
データベース・サービス名がクラスタ全体で一意になるようにする必要があります。
スタンドアロン・リソースおよびクラスタ・リソースのプロパティがOracle Fail Safe ManagerとOracle Enterprise Managerによって正しく検出され、表示されるようにするには、各リソースにクラスタ内で一意の名前を付ける必要があります。デフォルト値とは異なる名前を指定したり、リソースのデフォルト名を変更したりすることが必要な場合もあります。
表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 |
仮想サーバーを認識するようにクライアントを構成します(ネットワーク構成ツールを使用して各クライアント・システム上の |
Oracle Fail Safe Managerには、可用性が向上するようにシングルインスタンスOracle Databaseを構成する際に役立つリソースをグループに追加ウィザードがあります。ウィザードで表示されるページは、現在グループに含まれている仮想アドレスの数と、クラスタ内のノード数によって異なります。
各グループに1つの仮想アドレスが含まれる構成が典型的ですが、複雑な構成では複数の仮想アドレスが含まれる場合もあります。リソースをグループに追加ウィザードを使用して典型的な構成を実行するには、次のデータが必要です。
サービス名、インスタンス名、データベース名およびデータベース初期化パラメータ・ファイルのファイル指定などのシングルインスタンスOracle Databaseの識別情報
データベースSYSパスワード
複数の仮想アドレスが含まれているグループにデータベースを追加する場合は、クライアントがデータベースへのアクセスに使用する仮想アドレスを指定するように要求されます。
次の項では、シングルインスタンス・データベースの構成要件について詳細に説明します。
データベースをグループに追加する際に、クラスタが3つ以上のノードから構成されている場合は、図8-1に示すように、選択済ノードのリストを指定して、データベースの可能所有者となるノードを指定するように求められます。特定のノードをデータベースの可能所有者として指定しない場合は、そのノードを「選択済ノード」リストから選択して、左矢印をクリックします。
2.6.7項では、「可能所有者ノード」リストの概念の詳細を説明しています。
シングルインスタンス・データベースをグループに追加する際に、クラスタが2つ以上のノードで構成されており、そのうちの1つ以上のノードが使用できない場合、どのノードをデータベースの可能所有者とするのかを指定するように求められます。このような場合、図8-2に示すように、ウィザード・ページには使用できないノードが表示されます。
図8-3に示すように、シングルインスタンス・データベースを追加する対象のグループに複数の仮想アドレスが含まれている場合、クライアントがグループ内のデータベースにアクセスするときにグループ内のどの仮想アドレスを使用するかを尋ねるリソースをグループに追加ウィザードが表示されます。仮想アドレスが1つしか含まれていないデータベースを追加する場合には、このページは表示されません。
Oracle Fail Safeでは、1つのグループに複数の仮想アドレスがサポートされます。グループ内のすべてのデータベースは同じ仮想アドレスを使用する必要があり、グループにデータベースを追加する前に仮想アドレスがグループに追加される必要があります。グループの作成順序は、次のとおりです。
グループを作成します。
グループに1つ以上の仮想アドレスを追加します。
グループに1つ以上のシングルインスタンス・データベースを追加します。
たとえば、グループに2つの仮想アドレスを持つデータベースが含まれ、2番目のデータベースをそのグループに追加する場合、2番目のデータベースは、グループに構成されていた最初のデータベースと同じ仮想アドレスを使用する必要があります。Oracle Fail Safe Managerは、グループに追加したすべてのシングルインスタンス・データベースで同じ仮想アドレスが使用されていることを確認します。
複数の仮想アドレスを持つグループ内にリソースを構成する方法の詳細は、4.7項を参照してください。
リソースをグループに追加ウィザードでは、図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のヘルプを参照してください。 |
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管理者ガイド』を参照してください。)
Oracle Database Configuration Assistantを使用してデータベースを作成すると、テキスト初期化パラメータ・ファイル(init.ora)がORACLE_HOME\databaseディレクトリに作成されます。このファイルには、IFILEパラメータが含まれます。IFILEパラメータ値は、データベースの初期化パラメータが含まれる別のテキスト初期化パラメータ・ファイルのファイル指定です。
初期化パラメータ・ファイルのIFILEパラメータのファイル指定は、Windowsレジストリ内に格納されます。Oracle Fail Safeでは、デフォルトで、IFILEパラメータを含む初期化パラメータ・ファイルのファイル指定が「パラメータ・ファイル」フィールドに表示されます(「サンプル・データベースの作成」コマンドにより作成したデータベースを除く)。「サンプル・データベースの作成」コマンドにより作成したデータベースの場合、IFILEパラメータで指定する初期化パラメータ・ファイルが「パラメータ・ファイル」フィールドに表示されます。
クラスタ環境では、IFILEパラメータで指定するファイルを「パラメータ・ファイル」フィールドに入力することをお薦めします。これにより、データベース初期化パラメータへの最短アクセスが可能になります。また、この方法を選択せずにパラメータ・ファイルをプライベート・ディスクに置く場合は、必ずIFILEパラメータを含む初期化パラメータ・ファイルとIFILEパラメータで指定するファイルを両方とも各クラスタ・ノードのプライベート・ディスクにコピーしてください。
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のインストールに使用されたアカウントが、オペレーティング・システム認証を使用してデータベースにアクセスできるグループのメンバーになっている場合は表示されません。 |
シングルインスタンス・データベースをグループに追加すると、Oracle Fail Safeでは、Oracle Netリスナー・リソースおよびデータベース・リソースがグループに作成および構成されます。データベースがオンライン化すると、Oracle Fail Safeは最初に、リスナー・リソースがオンラインであることを確認します。データベース・リソースのIs Aliveポーリング中に、リスナーを介してデータベースに接続できない場合には、Bequeathプロトコル・アダプタを使用してデータベースに接続します。この障害をユーザーに通知するイベントも記録されます。このイベントが表示される場合、リスナー・リソースをチェックしてください。リスナー・リソースの障害が、データベースへの既存の接続に影響することはありません。ただし、新規のユーザーがデータベースに接続できなくなります。リスナー・リソースは独自の再起動ポリシーを持つため、障害発生時にはクラスタによって自動的に再起動されます。
Oracle Fail Safeでは、データベースと、リスナーに関連付けられたIPアドレス(リスナーそのものではない)との間に依存性を作成します。この依存性は、データベースに接続する前にIPアドレスがオフライン化された場合に、クライアントの応答が停止するという状況を避けるために作成されます。
USE_SHARED_SOCKETパラメータをTRUEに設定すると、共有ソケットが使用できるようになります。このパラメータをTRUEに設定すると、ネットワーク・リスナーからデータベース・スレッドにクライアント接続用のソケット記述子が渡されます。その結果、クライアントはデータベース・スレッドへの新しい接続を確立する必要がなくなるため、データベース接続時間が改善されます。また、データベースの接続はすべてネットワーク・リスナーで使用するポート番号を共有するため、サード・パーティ製のプロキシ・サーバーの設定が簡単に行えます。
(データベースを含む)ネットワーク・オブジェクトは、ネットワーク・アドレスによって識別されます。クライアントとデータベース間を接続するには、クライアントの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によりtnsnames.oraファイル、listener.oraファイルおよびsqlnet.oraファイル内のデータベースのOracle Net構成が変更されます。
シングルインスタンス・データベースをグループに追加すると、そのデータベースの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ではlistener.oraファイルを次のように変更します。
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アドレスが追加されます。
次の各項では、共有サーバー構成を使用するシングルインスタンス・データベースがOracle Fail Safeでどのようにサポートされるかを説明します。
共有サーバー構成を使用するには、データベース・パラメータ・ファイルを変更する必要があることがあります。
リスナー情報は、共有サーバー構成の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項の指示に従って、このパラメータをデータベース初期化ファイルに戻す必要があります。
シングルインスタンスOracle Databaseを管理するには、SYSDBA権限を付与されたデータベース管理者アカウントを使用します。これにより、リモート・クライアントからOracle Databaseを管理できます。
シングルインスタンスのサンプル・データベースを作成する場合や、グループにシングルインスタンス・データベースを追加する場合、Oracle Fail Safeではオペレーティング・システム認証またはSYSユーザー・アカウントを使用してデータベースにアクセスする必要があります。ユーザーがSYSアカウントを使用してデータベースにアクセスする場合は、認証パスワード・ファイルを使用してデータベース初期化パラメータ・ファイル(initdatabase-name.ora)内の初期化パラメータREMOTE_LOGIN_PASSWORDFILEをSHAREDまたはEXCLUSIVEに設定します。ユーザーがオペレーティング・システム認証のみを使用してデータベースにアクセスする場合は、REMOTE_LOGIN_PASSWORDFILEをNONEに設定します。
データベース管理者認証およびREMOTE_LOGIN_PASSWORDFILEパラメータの詳細は、『Oracle Database管理者ガイド』を参照してください。
データベースのパスワード・ファイルはプライベート・ディスクに格納されます。一方のクラスタ・ノードでパスワード・ファイルに対して行った変更内容は、他方のクラスタ・ノード上の対応するファイルに自動的には適用されません。
このため、1つのクラスタ・ノード上のパスワード・ファイルにアカウントを追加した場合は、データベース・インスタンスを実行するよう構成されている他のクラスタ・ノード上のパスワード・ファイルにもそのアカウントを追加する必要があります。パスワード・ファイルにSYSアカウント以外のアカウントが格納されている場合は、シングルインスタンス・フェイルセーフ・データベース用に、他のクラスタ・ノードで追加アカウントのSYSOPERおよびSYSDBA 権限を付与する必要があります。
Oracle Fail Safe Managerのリソースをグループに追加ウィザードを使用してシングルインスタンス・データベースをグループに追加する場合、Oracle Fail Safeはデータベースを実行するために構成される他のノード上にデータベース・インスタンスを作成し、パスワード・ファイルのユーザーの最大数にデフォルト値を使用します。インスタンスが作成されたノード上のパスワード・ファイルには、リソースをグループに追加ウィザードで指定したSYSアカウントのパスワードのみが含まれます。
データベース・インスタンスが稼働するように構成された他のノードで、次の手順を実行して、他のクラスタ・ノード上のパスワード・ファイルを同期化します。
パスワード・ファイル内のアカウント数がデフォルトの最大値を超える場合は、新しいパスワード・ファイルを作成します。それ以外の場合は、手順2に進みます。
新しいパスワード・ファイルを作成するには、Oracle Databaseの該当するリリースの管理者ガイドで、パスワード・ファイルの作成方法の手順を参照してください。
シングルインスタンス・データベースを含むグループを、そのデータベース・インスタンスが稼働するように構成された他のノードに移します。
データベースを移した先のノードで、SYS以外のアカウントに権限を付与します。
データベースが稼働するように構成された各クラスタ・ノードに対して、手順2と3を繰り返します。
これで、データベース・インスタンスが稼働するように構成されたすべてのノードで、パスワード・ファイルのローカル・コピーが同一のものになります。
SYSアカウントのパスワードは、データベースに関連付けられているOracleホームにあるパスワード・ファイルに通常格納されます。各クラスタ・ノードにデータベースに使用するOracleホームがあるため、データベースがクラスタ・リソースである場合に保持する必要がある複数のパスワード・ファイルが存在します。SYSアカウントのパスワードを変更するには、変更をデータベースに関連付けられているクラスタの各Oracleホームに伝播できるように、Oracle Fail Safe Managerユーティリティを使用します。Oracle Fail Safeで使用するパスワード・メンテナンス戦略を妨げる可能性があるため、SQL*Plusまたは他のユーティリティを使用してSYSアカウント・パスワードを手動で変更しないでください。
データベースのパスワードをデータベース・リソースの「プロパティ」ページで変更できます。Oracle Fail Safe Managerで、クラスタ・リソース・リストからデータベースを選択して、「アクション」メニューの「プロパティ」アクションをクリックします。リソース・プロパティ・ページが表示されます。オペレーティング・システムが使用されない場合、パスワード・フィールドが表示されます。
一般的なデータベースでは、パスワードの変更がただちに適用されます。ただし、データベース・パスワード・ファイルが共有されている場合、つまり初期化パラメータREMOTE_LOGIN_PASSWORDFILEがSHAREDに設定されている場合、パスワードの変更が適用される前にデータベースを再度開く必要があります。つまり、データベース・クラスタ・リソースをオフライン化して再度オンライン化するか、パスワードを変更する前にデータベースを所有するクラスタ・グループをクラスタの別のノードに移動する必要があります。Oracle Fail Safeは、データベースがオフライン化された場合でもパスワード・ファイルを更新します。
この項では、Oracle Database Upgrade Assistantを使用して異なるリリース間でシングルインスタンス・フェイルセーフ・データベースをアップグレードする方法、あるいは異なるOracleホーム間でシングルインスタンスOracle Databaseを移動する方法について説明します。
アップグレードまたは新規Oracleホームに移動するシングルインスタンス・データベースのそれぞれに対して、次の手順を実行します。
シングルインスタンス・データベースをグループから削除します。「使用可能なOracleリソース」リストから削除するサンプル・データベースを選択し、「Oracleリソース」ビューの「アクション」メニューから「サンプル・データベースの削除」を選択します。
「サンプル・データベースの削除の確認」ダイアログ・ボックスが開きます。「はい」をクリックします。
シングルインスタンス・データベースの移動先またはアップグレード先となるOracleホームから、Oracle Database Upgrade Assistantを実行します。
アップグレードするシングルインスタンス・データベースのデータベース・パラメータ・ファイルの場所を把握しておきます。データベースをアップグレードする際に、データベース・パラメータ・ファイルが変換されます。データベース・パラメータ・ファイルがクラスタ・ディスク上にある場合、パラメータ・ファイルはOracle Fail Safeによる変換に適した場所に置かれます。データベース・パラメータ・ファイルがプライベート・ディスク上にある場合、Oracle Database Upgrade Assistantはそのローカル・コピーのみを変換します。この場合、他のクラスタ・ノード上のコピーも編集し、適切な変更を加える必要があります。
Oracle Database Upgrade Assistantで求められる変換済データベース・ファイルの場所を指定します。データファイルを現在の場所のままにしておくか、またはローカル・ノードから現在アクセス可能なクラスタ・ディスクを指定します。後者を選択する場合、そのクラスタ・ディスクが他のグループによって使用されていないことを確認してください。
Oracle Database Upgrade Assistantによって、グループ内のすべてのデータベースがアップグレードまたは新規Oracleホームに移動されてから、Oracle Fail Safe Managerを使用して、次のようにデータベースをグループに戻し、データベースをオンライン化します。
使用可能なリソースをグループに追加するには、グループに追加するリソースを選択し、「Oracleリソース」ビューの「アクション」メニューから「このリソースをグループに追加」アクションを選択します。
リソースの構成を示す「リソースをグループに追加」ガイド付きプロセス・ウィザードが開きます。
移動するグループのデータベースは、すべて同じOracleホームに属している必要があります。Oracle Database Upgrade Assistantを使用して、あるグループ内の1つのデータベースを新規のOracleホームに移動する場合、そのグループ内のすべてのデータベースを新規Oracleホームに移動してください。
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のマニュアルを参照してください。
可用性が向上するように構成されたデータベースに対する管理作業も、他のデータベースと同様にして実行します。ただし、データベースへのアクセスを制限する操作、またはフェイルオーバー機能を一時的に使用不可にする操作の途中でデータベースをオフラインにする(およびクラスタでのデータベースの監視を停止する)場合は例外で、Oracle Fail Safe ManagerまたはPowerShellコマンドレット・コマンドライン・インタフェース(第5章を参照)を使用します。これには、コールド・バックアップ操作のみではなく、ユーザーがデータベースにアクセス中に実行する必要のある管理操作や、Microsoft Windowsフェイルオーバー・クラスタによるデータベースの定期的なIs Aliveポーリング中の応答時間に影響する操作が含まれます。
Oracle Fail Safe Managerを使用してグループ内に構成されているデータベースに対して管理作業を実行するには、次の手順に従います。
Oracle Fail Safe ManagerまたはFail Safe PowerShellコマンドレットを使用して、データベースをオフライン化して停止し、クラスタによるデータベースの監視を中止します。データベースに接続されているユーザーはすべて切断されます。
SQL*Plusなどのツールを使用し、データベースを起動して管理作業を実行します。データベースが起動されている間、ユーザーはデータベースにアクセスできます。
管理作業を完了した後、SQL*Plusなどのツールを使用してデータベースを停止します。
Oracle Fail Safe ManagerまたはFail Safe PowerShellコマンドレットを使用し、データベースを再度オンライン化します。クラスタによるデータベースの監視が再開されます。
第5章には、Fail Safe PowerShellコマンドレットを使用してバックアップ操作を実行するスクリプトの例が示されています。
管理作業の途中で、(新しい表領域や関連データファイルの追加など)データベースの構成を変更する操作を行った場合は、「検証」グループ操作を実行します。新規データファイルを追加すると、グループが新しいディスクに依存する可能性があります。「検証」グループ操作を実行すると、ディスクがクラスタ・ディスクであり、別のグループには属していないことが確認されます。新規データファイルの追加によりグループが新しいディスクに依存する場合、ディスクはデータベースと同じグループに追加され、新規ディスクが正常にデータベースとともにフェイルオーバーするよう、クラスタ・レジストリ内の情報が更新されます。
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種類です。
Oracle Fail Safeサーバー(OracleMSCSServices)
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項を参照してください。
スタンドアロン・シングルインスタンス・データベースの場合、透過的アプリケーション・フェイルオーバー(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管理者ガイド』を参照してください。
次の各項では、Oracle Fail Safeが可用性の高いシングルインスタンス・データベースのオンライン化を試行した際にエラーが発生した場合に、そのエラーを処理するスクリプトの指定方法と、可用性が高まるよう構成されたシングルインスタンスOracle Databaseで発生する特定の問題のトラブルシューティングの方法を説明します。Oracle Databaseのトラブルシューティングに関する一般的な情報は、Oracle Databaseのマニュアルを参照してください。
Oracle Fail Safeがシングルインスタンス・データベースのオンライン化を試行した際に発生するエラーを処理するスクリプトを指定します。Oracle Fail Safeでは、クラスタ上のすべてのシングルインスタンス・フェイルセーフ・データベースに同じスクリプトを使用します。
エラー処理スクリプトを指定するには、次のようにします。
エラーを処理するスクリプトを作成します。
スクリプトが成功した場合は0を返し、失敗した場合は0以外の整数を返すことを確認します。
データベース・リソースの可能所有者である各クラスタ・ノードの次のディレクトリにスクリプトを置き、ファイル所有者がそのクラスタ・ノードに対するローカル管理者権限を持っていることを確認します。
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では、データベースの再起動ポリシーおよびフェイルオーバー・ポリシーの定義に従ってシングルインスタンス・データベースのオンライン化の試行が継続されます。
多くの場合、問題のトラブルシューティングでは、まず「検証」クラスタ、「検証」グループ、または「検証」スタンドアロン・データベース・アクションを選択します。これらのツールの概要は、第7章に記載されています。検証アクションを実行しても問題の原因を特定できない場合は、Windowsアプリケーション・イベント・ログを確認して、エラー・メッセージがポストされていないかを調べます。操作が失敗した場合、Oracleサポートによりトレースを有効にするように求められることがあります。Oracle Fail Safeトレースの有効化の詳細は、付録Aを参照してください。
シングルインスタンス・データベースを含むグループに対して「検証」アクションを選択すると、Oracle Fail Safeでは次のことを行います。
グループ内の各データベースに問い合せて、使用されているディスクを特定します。その後、そのディスクがクラスタ・ディスクであるか、すでにグループに追加されているかをチェックします。(たとえば、可用性が高まるように構成された後にデータベースにディスクが追加されたために)ディスクの有効性検査が失敗した場合、「検証」グループ・アクションでは、問題を修正する前に確認を求められます。
ネットワーク名が正しいIPアドレスにpingするかどうかを検証します。
いつでも「検証」グループ・アクションを選択できます。ただし、次の状況が発生した場合は、必ず実行してください。
グループまたはグループ内のリソースがオンライン化されない場合。
クラスタに新しいノードが追加された場合。
たとえば、Oracle Fail Safe Managerを使用してクラスタ構成を更新せずに、シングルインスタンス・データベースに新しいディスクを追加した場合を考えてみます。その後サーバー・ノードが停止しても、フェイルオーバーは適切に実行されません。これは、クラスタ・ソフトウェアに構成の変更を通知していないことによるものです。この問題を回避するため、シングルインスタンス・データベースの構造を変更したときは、必ずそのデータベースを含むグループを検証してください。グループを検証すると、Oracle Fail Safeでは自動的に変更を検出し、クラスタ構成を更新します。前述の例では、Oracle Fail Safeは、ユーザーにかわって新しいディスクをグループに追加します。
グループの検証で問題が検出された場合、Oracle Fail Safeは問題を修正するための応答を求めるか、または問題を詳しく説明したエラー・メッセージを返します。
シングルインスタンス・データベースをグループへ追加する際に問題が発生した場合は、次の操作を実行します。
「使用可能なOracleリソース」リストからデータベースを選択して、「検証」スタンドアロン・データベース・アクションを実行します(7.1.3項を参照)。
「検証」スタンドアロン・データベース操作を実行することにより、データベースが有効に機能するスタンドアロン・データベースであることが検証されます。
たとえば、スタンドアロン・データベースのグループへの追加を試行しOracle Netを構成する際にエラーが発生したとします。この場合は、Oracle Fail Safeによってクラスタワイド操作がロールバックされ、データベースはスタンドアロン・データベースのままになります。この問題を解決するには、次の手順を実行します。
「検証」スタンドアロン・データベース操作を実行して、ネットワーク(Oracle Net)が機能していることを確認します。
スタンドアロン・データベースをグループに追加してみます。
データベースをグループに追加する操作に失敗した場合は、8.10.7.4項に記載されている方法に従って、Oracle Netのロールバック・ファイルを調べてください。
次の条件が満たされていることを確認してください。
シングルインスタンス・データベースが含まれるグループをオンライン化する際に問題が発生した場合は、次の操作を実行します。
(Oracle Fail Safe Managerグループの「アクション」メニューから)「検証」を選択すると、Oracle Fail Safeではグループの構成をチェックし、問題が見つかると修正を行います。
「検証」グループ・アクションで問題が見つかった場合は、その問題を手動で解決するヒントとなるエラー・メッセージが返されます。
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ファイルには、クラスタ内のグループに対する有効な仮想サーバー・アドレスが含まれている必要があります。
グループ内の各リソースを個別にオンライン化します。
グループ内に複数のシングルインスタンス・データベースが存在する場合、この方法で問題の原因となっているデータベースを識別できます。
「拡張ポリシー」プロパティ・ページで指定されたシングルインスタンス・データベースの「保留タイムアウト」値が十分であることを確認します。
データベースが含まれるグループがオンライン化に失敗する場合、または頻繁にフェイルオーバーする場合は、「保留タイムアウト」値が正しく設定されているか確認してください。データベースの「保留タイムアウト」値の設定が低すぎると、オンライン化に失敗したり、フェイルオーバーが頻繁に発生します。
「保留タイムアウト」の値を設定して、クラスタ・ソフトウェアでデータベースがオンライン(またはオフライン)になってから操作が失敗したと判断されるまでの時間を指定します。値は、遅いレスポンス時間がクラスタ・システムにより使用不可状態と判断されることがない程度に大きく、かつ障害発生時のフェイルオーバー・レスポンス時間を最小限に抑えられる程度に小さく設定してください。
「保留タイムアウト」値を設定するには、次のようにデータベース・プロパティを変更します。
Oracle Fail Safe Managerのツリー・ビューで、データベース名を選択します。
「ポリシー」タブをクリックします。
「保留タイムアウト」ボックスで「保留タイムアウト」値を変更します。
ユーザーが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項を参照してください。
プロセスが集中している操作(インポート操作など)では、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章を参照してください。
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項に、データベース・パスワードの正しい更新方法が記載されています。
スタンドアロン・データベースまたはグループに構成されているデータベースに接続しようとして問題が検出された場合は、データベースのOracle Net構成を調べる必要があります。
Oracle Fail Safeは、「検証」グループおよび「検証」スタンドアロン・データベース操作を提供して、Oracle Net構成を検証および修正できます。詳細は、7.1.2項および7.1.3項を参照してください。
Oracle Fail Safeは仮想アドレス情報を構成するとき、listener.oraファイルおよびtnsnames.oraファイルを変更し、リスナーを停止してから再起動します。発生する可能性のある問題と問題を解決するための処置を、次のリストに示します。
このメッセージ・コードは、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のマニュアル(ログ・ディレクトリの情報を含む)を参照してください。
Oracle Fail Safe Managerでは、リスナー制御ユーティリティ(LSNRCTL)を使用して新規リスナーを作成し、Oracleホームにあるファイルに出力します。
たとえば、Oracleホームとネットワーク・ディレクトリのパスがC:\ORANT\NETWORK\ADMINで、リスナーが動作する仮想アドレスがntclu-155の場合、リスナー出力ファイルは、次のディレクトリおよびファイルに書き込まれます。
C:\ORANT\NETWORK\LOG\fslntclu-155.out
各リスナーには、リスナー名に.out拡張子が付いた名前の出力ファイルがあります。(この例では、リスナー名はfslntclu-155です。)新規リスナーの作成が困難な場合は、出力ファイルを使用して問題を診断できます。
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が最新のファイルです。
アクセスおよび認証の問題は、Oracle Enterprise Managerを介して操作を実行する場合に最も多く発生します。
次に、典型的な認証の問題をいくつか示します。
Oracle Fail Safeへの接続時に、Oracle Enterprise Managerから次のようなエラーが発生。
FS-10101: クラスタ上のユーザーusernameの認証に失敗しました。
Oracle Enterprise Managerで、クラスタのユーザー資格証明がすべてのクラスタ・ノーでWindows管理者の資格証明と同じであり、ユーザー名とドメインが正しく指定されていることを確認します。
Oracle Enterprise ManagerからOracle Fail Safeに発行したジョブが、エラー「ユーザーの認証に失敗しました。」で失敗します。
グループ内に構成されているデータベースで操作を実行したり、データベースにアクセスしようとすると、「ORA-01031: 権限が不足しています」エラーが返されます。
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の使用に関する情報を検索できます。
