Oracle Fail Safeにより、Microsoft Windowsフェイルオーバー・クラスタを使用して構成されたWindowsクラスタで稼働しているシングルインスタンスOracle Database(Oracle Database Personal Editionを除く)の可用性が向上します。
シングルインスタンスOracle Databaseの可用性を高めると、1つのクラスタ・ノードが停止または故障した場合でも、別のクラスタ・ノードでデータベースが再起動され、そのデータベースにアクセスするアプリケーションとデータベースとの接続が失われるのはほんの一瞬にすぎません。こうしたフェイルオーバー・イベントの発生後、アプリケーションはTAFによって自動的にデータベースに再接続できるため、フェイルオーバーがユーザーの作業に悪影響を与えることはありません。
関連項目: 『Oracle Fail Safeリリース・ノートfor Microsoft Windows』のマルチテナント・コンテナ・データベース(CDB)のサポートに関する項 |
この章では、次の項目について説明します。
Oracle Fail Safe Serverは、Oracle DatabaseインスタンスのWindowsサービスを検索してスタンドアロン・シングルインスタンス・データベース(クラスタ・グループに含まれないもの)を検出します。その時点でクラスタ・グループに含まれていないクラスタ・ノードで検出されたすべてのサービスが、Oracle Fail Safe Managerの「使用可能なOracleリソース」リストに表示されます。
次の項では、スタンドアロン・シングルインスタンス・データベースのためのOracle Netの構成について簡単に説明します。
リスナーの定義でシステムのホスト名が使用されている場合、このリスナーはホスト名に関連付けられているIPアドレスのみではなく、ノード上のすべてのIPアドレスでリスニングを行います。ローカル・リスナーは、グループに割り当てられているIPアドレスをリスニングする際にクラスタ・グループ・リスナーの障害の原因となるクラスタIPアドレスも開きます。
この問題を回避するために、リスナーにはホスト名ではなくホスト・エントリのノードIPアドレスを使用する必要があります。Oracle Fail Safeがクラスタ・グループを検証するかデータベースをグループに追加する場合、HOSTがローカル・ノードのホスト名に設定されているADDRESSエントリを検索します。ローカル・ノード名を使用するすべてのHOSTエントリは、ノードの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 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 Fail Safeは、リスナーSIDリストを維持しません。クラスタ・データベースがリスナーのSIDリストに含まれている必要のあるアプリケーションを使用する場合、クラスタの各ノードで該当するlistener.ora
ファイルを手動で編集してください。
Oracle Fail Safeはスタンドアロン・データベース・リスナーを検索する際、リスナーのWindowsサービスをスキャンして、データベースによって使用されているネットワーク・アドレスでリスニングしているものを探します。ネットワーク・アドレスでリスニングしているリスナーが複数存在する場合、Oracle Fail Safeは実行中のリスナー・サービスを選択します。どのリスナーも起動されていない場合、ネットワーク・アドレスでリスニングしているリスナーで最初に検出されたものがOracle Fail Safeによって選択されます。
注意: ネットワーク構成エラーを回避するために、Oracle Fail Safeのどの操作においても、実行前にスタンドアロン・シングルインスタンス・データベースのリスナーが予定どおりの状態(停止または起動)であることを確認してください。 |
可用性が高まるようにシングルインスタンスOracle Databaseを構成するには、少なくとも1つのネットワーク名が含まれているグループにデータベースを追加します。Oracle Fail Safeにより、シングルインスタンスOracle Databaseで必要なすべてのリソースが追加されます。通常、このグループには次のリソースが含まれます。
それぞれが1つのIPアドレスおよびネットワーク名から構成される1つ以上のネットワーク名
Oracle Databaseインスタンス
Oracle Databaseで使用する全ディスク
グループのネットワーク名上でグループ内のデータベースへの接続要求をリスニングするOracle Netネットワーク・リスナー
シングルインスタンス・データベースをグループに追加する前に、次のことに注意してください。
データベース初期化パラメータ・ファイルを除き、シングルインスタンス・データベースにより使用されるファイルはすべて共有クラスタ・ディスク上に置く必要があります。データベース初期化パラメータ・ファイルは、プライベート・ディスクにも共有クラスタ・ディスクにも配置できます。初期化パラメータ・ファイルの配置場所の詳細は、7.3.3.4項を参照してください。
リソースが属するグループは1つのみです。このため、2つのシングルインスタンス・データベースが同じディスク・ドライブを共有する場合は、この2つのデータベースを同一グループ内に指定する必要があります。
フェイルオーバーの際、一時表内のデータはフェイルオーバーされません。(ソートやハッシュ結合など)一時表や一時表領域を使用する操作では、フェイルオーバー・ノードで再起動されるときに必要な一時オブジェクトが再作成されます。ただし、一時表内の特定のデータに依存するアプリケーションが正常に機能することを確認する必要があります。
一時表の詳細は、『Oracle Database概要』の一時表に関する説明を参照してください。
グループには、少なくとも1つのネットワーク名が含まれている必要があります。
データベース・サービス名がクラスタ全体で一意になるようにする必要があります。
グループ内のすべてのリスナーおよびデータベースは同じOracleホームを使用している必要があります。
表7-1に、可用性が高まるようにシングルインスタンスOracle Databaseを構成する際に必要な作業の一覧を示します。各作業の詳細は、オンライン・ヘルプとチュートリアルを参照してください。オンライン・ヘルプにアクセスするには、Oracle Fail Safe Managerウィンドウの右側のペインの「アクション」メニューから「ヘルプ」を選択します。または、Oracle Fail Safe Managerの中央のペインの「Fail Safeドキュメント」を選択し、順を追った詳細な説明は「チュートリアル」の「HTML」または「PDF」バージョンを選択します。
表7-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の識別情報
OS認証が使用されていない場合はデータベースのSYS
パスワード
現在複数のネットワーク名が含まれているグループにデータベースを追加する場合、リスナーのネットワーク名も指定するよう求められます。
次の項では、シングルインスタンス・データベースの構成要件について詳細に説明します。
Microsoftフェイルオーバー・クラスタでは、リソース名に任意のテキスト文字列を使用できます。デフォルトで、Oracle Fail SafeではデータベースのインスタンスIDを使用します。必要に応じて、この名前をもっとわかりやすい名前に変更できます。たとえば、ここではクラスタ・リソース名がTest Databaseに変更されています。
データベースをグループに追加する際に、クラスタが3つ以上のノードから構成されている場合は、図7-2に示すように、選択済ノードのリストを指定して、データベースの可能所有者となるノードを指定するように求められます。特定のノードをデータベースの可能所有者として指定しない場合は、そのノードを「選択済ノード」リストから選択して、左矢印をクリックします。
2.6.7項では、「可能所有者ノード」リストの概念の詳細を説明しています。
シングルインスタンス・データベースをグループに追加する際に、クラスタが2つ以上のノードで構成されており、そのうちの1つ以上のノードが使用できない場合、どのノードをデータベースの可能所有者とするのかを指定するように求められます。このような場合、図7-3に示すように、ウィザード・ページには使用できないノードが表示されます。
シングルインスタンス・データベースを追加するグループに複数のネットワーク名が含まれている場合、図7-4に示すように、「リソースをグループに追加」ウィザードによってリスナーのネットワーク名を指定するよう求められます。ネットワーク名が1つしか含まれていないデータベースを追加する場合には、このページは表示されません。
Oracle Fail Safeでは、1つのグループに複数のネットワーク名がサポートされます。グループ内のすべてのデータベースは同じネットワーク名を使用する必要があり、グループにデータベースを追加する前にネットワーク名がグループに追加される必要があります。グループの作成順序は、次のとおりです。
グループを作成します。
グループに1つ以上のネットワーク名を追加します。
グループに1つ以上のシングルインスタンス・データベースを追加します。
たとえば、グループに2つのネットワーク名を持つデータベースが含まれ、2番目のデータベースをそのグループに追加する場合、2番目のデータベースは、グループに構成されていた最初のデータベースと同じネットワーク名を使用する必要があります。Oracle Fail Safe Managerは、グループに追加したすべてのシングルインスタンス・データベースで同じネットワーク名が使用されていることを確認します。
複数のネットワーク名を持つグループ内にリソースを構成する方法の詳細は、4.7項を参照してください。
リソースをグループに追加ウィザードでは、図7-5に示すように、可用性が高まるように構成されるシングルインスタンス・データベースを一意に識別する、データベース・パラメータ情報を入力する必要があります。
Oracle Fail Safeでは、(たとえば、tnsnames.ora
ファイルを更新する場合)このデータを使用してデータベースがクラスタ内に構成されます。また、ユーザーが入力したデータがMicrosoft Windowsフェイルオーバー・クラスタに渡され、データはMicrosoft Windowsフェイルオーバー・クラスタに登録されて、データベースがオンラインまたはオフラインになるとき、あるいはIs Aliveポーリングが実行されるときに使用されます。Oracle Fail Safeは、初期化パラメータ・ファイルの名前と場所を要求します。
Oracle Databaseの起動時には、初期化パラメータ・ファイルを使用してデータベース名、メモリーの割当て量、制御ファイル名、各種の制限事項、およびその他のシステム・パラメータが指定されます。
通常は、どのクラスタ・ノードがデータベースのホストであるかにかかわらずパラメータ・ファイルにアクセスできるように、パラメータ・ファイルはクラスタ・ディスク上に配置します。ただし、データベースが稼働するように構成されたすべてのクラスタ・ノードの同じ場所に初期化パラメータ・ファイルを置くことが確実な場合は、各ノードのプライベート・ディスクにファイルのコピーを配置することも可能です。また、ホストになっているノードに応じてデータベースに異なるパラメータを設定するために、各ノードのプライベート・ディスクにパラメータ・ファイルを配置することもできます。ノード間でメモリー量または処理能力に差がある場合は、このような方法が有効です。
注意: 可用性が高まるようにデータベースを構成した後、必要に応じて初期化パラメータ・ファイルを移動できます。この操作の実行方法の詳細は、Oracle Fail Safe Managerのヘルプを参照してください。 |
Oracle Fail Safeでは、「パラメータ・ファイル」フィールドでテキスト初期化パラメータ・ファイル(PFILE
)を指定する必要があります。バイナリ・サーバー・パラメータ・ファイル(SPFILE
)を、可用性が高まるように構成されたデータベースとともに使用する場合は、SPFILE=
SPFILE-location
パラメータを使用して、
PFILE内でSPFILE
の位置を指定します。SPFILE
は、データベースが常駐するクラスタ・グループのメンバーである共有ディスクに常駐する必要があります。たとえば、PFILE
に次のようなパラメータを含めることが可能です。
SPFILE=F:\OFSDB\oradata\OFS1\spfileTestDboradb.ora
(Oracle Fail Safeで使用するPFILE
内にSPFILE
を指定する場合、そのSPFILE
をエクスポートする際には次の事項に注意する必要があります。ファイル指定なしでCREATE PFILE FROM SPFILE
コマンドを使用すると、Oracle Fail Safeで使用するPFILE
が上書きされます。このため、SPFILE
をエクスポートするPFILE
には必ず一意のファイル名を指定してください。サーバー・パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。)
クラスタの各ノードのすべてのOracleデータベース・インスタンスは同じSPFILE
を使用する必要があり、ファイルは共有記憶域に存在する必要があります。SPFILE
が共有記憶域に保存されていない場合、次のようにして、SQL*PLUS
を使用してコピーを作成します。
CREATE SPFILE=shared disk path\spfiledb_unique_name.ora
SPFILE=
shared disk path
\spfile
db_unique_name
.ora
という名前が含まれるPFILE
、ORACLE_HOME
\dbs\initsid.ora
を作成します。
Oracle Fail Safeのインストールに使用されたアカウントが、データベースに関連付けられたORA_DBA
グループ、ORA_
SID
_DBA
グループまたはORA_
home
_DBA
グループのいずれかのWindowsオペレーティング・システム・グループにない場合、「認証」ページが表示されます。Oracle Fail SafeがインストールされたアカウントがORA_DBA
、ORA_
SID
_DBA
グループまたはORA_
home
_DBA
グループに含まれている場合、データベースへのアクセスにオペレーティング・システムの認証を使用できます。アカウントがORA_DBA
グループ、ORA_
SID
_DBA
グループまたはORA_
home
_DBA
グループのメンバーではない場合、データベースへのアクセスにSYS
アカウントを使用する必要があります。
図7-6
に示すように、Oracle Fail Safeでデータベースおよびデータベース・インスタンスにアクセスする際に、オペレーティング・システム認証とSYSアカウントのどちらを使用するかを、このページから指定できます。
注意: 「データベースの認証」ページは、Oracle Fail Safeのインストールに使用されたアカウントが、オペレーティング・システム認証を使用してデータベースにアクセスできるグループのメンバーになっている場合は表示されません。 |
構成済のOracleホーム・ユーザーが存在する場合、Oracle Fail SafeによってOracleホーム・ユーザー用にパスワード・フィールドが追加で表示されます。Oracleホーム・ユーザーのパスワードも必ず入力してください。
シングルインスタンス・データベースをグループに追加すると、Oracle Fail Safeでは、Oracle Netリスナー・リソースおよびデータベース・リソースがグループに作成および構成されます。スタンドアロン・データベースがグループに追加されたときに使用しているリスナーに基づいて、新規グループのリスナーが構成されます。新規リスナーには、元のリスナーと同じパラメータが設定され、元のリスナーのアドレス・リストと同じポート番号を使用します。
通常の操作中、クラスタは定期的にリスナーをポーリングし、Windowsサービスが起動されており、リスナーがステータス・コマンドに応答するかどうか検証されます。それらのチェックが失敗すると、リスナーが停止され、クラスタはフェイルオーバー・ポリシーを開始して、リスナー・リソースを再起動する必要があるか、またはグループを別のノードにフェイル・オーバーする必要があるかが決定されます。Oracleクラスタ・リソースのコントロール・マネージャが検出したリソースの障害はすべてWindowsアプリケーションのイベント・ログに記録されます。
Oracle Fail Safeでは、データベースと、リスナーに関連付けられたIPアドレス(リスナーそのものではない)との間に依存性を作成します。この依存性は、データベースに接続する前にIPアドレスがオフライン化された場合に、クライアントの応答が停止するという状況を避けるために作成されます。
(データベースを含む)ネットワーク・オブジェクトは、ネットワーク・アドレスによって識別されます。クライアントとデータベース間を接続するには、クライアントのtnsnames.ora
ファイル内のネットワーク・アドレスと、サーバーのlistener.ora
ファイル内のネットワーク・アドレスが一致している必要があります。つまり、クライアントがネットワーク・アドレスを使用してネットワーク・オブジェクトの特定の場所に接続要求を送ると、受け側は、このアドレス上で要求をリスニングし、クライアント情報と一致するアドレス情報に基づいて接続を許可します。
シングルインスタンス・データベースをグループに追加すると、Oracle Fail Safeでは、データベースが常駐するOracleホーム内にグループのリスナーを作成します。Oracle Fail Safeがネットワーク名情報を構成する際、データベースの所有者の可能性のあるクラスタ・ノードのすべてのOracleホームでtnsnames.ora
ファイルを更新します。これによって、Oracle Fail Safeで常に最新の構成でデータベース・インスタンスにアクセスできるようになります。
7.4.2項では、データベースをグループに追加した後で、Oracle Fail Safeでlistener.ora
ファイルにエントリが作成され、tnsnames.ora
ファイルが更新されて、どのクラスタ・ノードがデータベースのホストであるかに関係なく、クライアントがデータベースに接続できるようにする方法について説明します。
次の項で説明するように、シングルインスタンス・データベースをグループに追加すると、Oracle Fail Safeによりtnsnames.oraファイル、listener.ora
ファイルおよびsqlnet.ora
ファイル内のデータベースのOracle Net構成が変更されます。
シングルインスタンス・データベースをグループに追加すると、Oracle Fail Safeはtnsnames.oraファイルのすべてのネット・サービス記述子を、クラスタ・グループによって使用されるネットワーク名を使用するよう更新します。まず、Oracle Fail Safeによってtnsnames.oraファイルがスキャンされ、データベースを参照するネット・サービス記述子が存在するか確認されます。既存の記述子は、グループのTNSリスナーのアドレス・リストを使用するよう変更されます。次に、データベースのservice_namesパラメータで検出された各サービス名について、Oracle Fail Safeはtnsnames.oraファイルにネット・サービス記述子が存在するか確認します。ネット・サービス記述子が検出されなかった場合、Oracle Fail Safeにより、グループのリスナー・アドレス・リストに一致するアドレス・リストが含まれる新しいネット・サービス記述子が作成されます。ノードに複数のOracleホームが存在する場合、データベースのすべてのネット・サービス記述子が、他のOracleホームのtnsnames.oraファイルに複製されます。同様に、新しいネット・サービス記述子も、クラスタに含まれる他のすべてのノードのtnsnames.oraファイルに複製されます。
グループにシングルインスタンス・データベースを追加する際に、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
となります。
次の例に示すように、アーカイブ・ログの宛先をサービス名として定義した場合、どのクラスタ・ノードでもtnsnames.ora
ファイルが自動的に更新されなくなります。各クラスタ・ノードで、サービス名エントリを手動で編集するか、tnsnames.ora
ファイルに追加します。
log_archive_dest_2='SERVICE=standby OPTIONAL REOPEN=120'
データベースに接続するすべてのクライアント・システムにおいて、データベースを参照する各ネットワーク・サービス記述子のアドレス・リストのHOST
パラメータに、クラスタ・グループのネットワーク名を使用するよう、tnsnames.oraファイルが更新されている必要があります。各クライアントのローカルtnsnames.oraファイルを手動で編集するか、ネットワーク構成ツールを使用します。
シングルインスタンス・データベースをグループに追加すると、Oracle Fail Safeではlistener.ora
ファイルを次のように変更します。
シングルインスタンス・データベースに関連付けられたネットワーク名でリスニングするように構成されたOracle Fail Safeリスナーを新規作成します。
スタンドアロン・データベース・リスナーを停止後、再起動して変更内容を有効にします。
新規のOracle Fail Safeリスナーを起動します。
新規クラスタ・グループ・リスナーが作成されると、Oracle Fail Safeによって元のリスナーから新規リスナーにポート番号が複製されます。たとえば、元のリスナーのADDRESS
エントリでポート1521
および1522
がADDRESS_LIST
に含まれている場合、新規リスナーは同じポート番号が含まれるADDRESS_LIST
を作成します。
新規グループ・リスナーが作成されると、Oracle Fail Safeにより、クラスタ・グループ内のすべてのデータベースがIPCプロトコルを介してセキュアな登録を使用するよう強制されます。したがって、Oracle Fail SafeによってパラメータSECURE_REGISTER_group_listener_name
が値IPC
で作成されます。
データベースがクラスタ・グループに追加され、グループに対して構成されているリスナーが存在しない場合、Oracle Fail Safeによってデータベースの現在のリスナーから新規グループ・リスナーにパラメータがコピーされます。たとえば、データベースが現在「listener」という名前のデフォルト・リスナーを使用しており、リスナーにはパラメータINBOUND_CONNECT_TIMEOUT_LISTENER
がlistener.ora
ファイルに含まれている場合、Oracle Fail Safeによって新規リスナー用にパラメータINBOUND_CONNECT_TIMEOUT_group_listener_name
が作成され、INBOUND_CONNECT_TIMEOUT_LISTENER
パラメータに使用される値が割り当てられます。
Oracle Fail Safeでは、新規グループ・リスナー用に外部プロシージャ・パラメータは作成されません。ご使用のアプリケーションで外部プロシージャが使用されている場合、クラスタ内の各ノードのlistener.ora
およびtnsname.ora
ファイルを手動で編集し、アプリケーションが使用する外部プロシージャに必要なパラメータを追加する必要があります。
次の各項では、共有サーバー構成を使用するシングルインスタンス・データベースがOracle Fail Safeでどのようにサポートされるかを説明します。
注意: データベースを共有サーバー構成用に設定する場合、Oracle Fail Safeで内部操作専用のサーバー接続を引き続き使用できることを確認します。そのためには、各クラスタ・サーバー・ノード上のtnsnames.oraファイルのデータベースに対する、ネット・サービス名エントリの接続データ部分に(S ERVER=DEDICATED )パラメータを指定します。(共有サーバーが使用されている状態でSERVER パラメータが指定されていない場合、デフォルトではリスナーが共有サーバーを使用して接続を確立します。) |
共有サーバー構成を使用するには、データベース・パラメータ・ファイルを変更する必要があることがあります。
リスナー情報は、共有サーバー構成の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パラメータが削除されます。7.2.2項の指示に従って、このパラメータをデータベース初期化ファイルに戻す必要があります。
シングルインスタンス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 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 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コマンドレットを使用し、データベースを再度オンライン化します。クラスタによるデータベースの監視が再開されます。
管理作業の途中で、(新しい表領域や関連データファイルの追加など)データベースの構成を変更する操作を行った場合は、「検証」グループ操作を実行します。新規データファイルを追加すると、グループが新しいディスクに依存する可能性があります。「検証」グループ操作を実行すると、ディスクがクラスタ・ディスクであり、別のグループには属していないことが確認されます。新規データファイルの追加によりグループが新しいディスクに依存する場合、ディスクはデータベースと同じグループに追加され、新規ディスクが正常にデータベースとともにフェイルオーバーするよう、クラスタ・レジストリ内の情報が更新されます。
Oracle Database 12cリリース1 (12.1)以降、Oracle Databaseでは、インストール時に指定されるOracleホーム・ユーザーの使用がサポートされます。Oracleホーム・ユーザーは、ドメイン・ユーザー・アカウントである必要があります。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では、データベースの再起動ポリシーおよびフェイルオーバー・ポリシーの定義に従ってシングルインスタンス・データベースのオンライン化の試行が継続されます。
多くの場合、問題のトラブルシューティングでは、まず「検証」クラスタ、「検証」グループ、または「検証」スタンドアロン・データベース・アクションを選択します。これらのツールの概要は、第6章に記載されています。「検証」アクションを実行しても問題の原因を特定できない場合は、Windowsアプリケーション・イベント・ログを確認して、エラー・メッセージがポストされていないかを調べます。操作が失敗した場合、Oracleサポートによりトレースを有効にするように求められることがあります。Oracle Fail Safeトレースの有効化の詳細は、付録Aを参照してください。
シングルインスタンス・データベースを含むグループに対して「検証」アクションを選択すると、Oracle Fail Safeでは次のことを行います。
グループ内の各データベースに問い合せて、使用されているディスクを特定します。その後、そのディスクがクラスタ・ディスクであるか、すでにグループに追加されているかをチェックします。(たとえば、可用性が高まるように構成された後にデータベースにディスクが追加されたために)ディスクの有効性検査が失敗した場合、「検証」グループ・アクションでは、問題を修正する前に確認を求められます。
いつでも「検証」グループ・アクションを選択できます。ただし、次の状況が発生した場合は、必ず実行してください。
グループまたはグループ内のリソースがオンライン化されない場合。
クラスタに新しいノードが追加された場合。
たとえば、Oracle Fail Safe Managerを使用してクラスタ構成を更新せずに、シングルインスタンス・データベースに新しいディスクを追加した場合を考えてみます。その後サーバー・ノードが停止しても、フェイルオーバーは適切に実行されません。これは、クラスタ・ソフトウェアに構成の変更を通知していないことによるものです。この問題を回避するため、シングルインスタンス・データベースの構造を変更したときは、必ずそのデータベースを含むグループを検証してください。グループを検証すると、Oracle Fail Safeでは自動的に変更を検出し、クラスタ構成を更新します。前述の例では、Oracle Fail Safeは、ユーザーにかわって新しいディスクをグループに追加します。
グループの検証で問題が検出された場合、Oracle Fail Safeは問題を修正するための応答を求めるか、または問題を詳しく説明したエラー・メッセージを返します。
データベースをグループに追加する際、リスナーまたはデータベース・リソースがオンライン化に失敗すると、Oracle Fail Safe Managerによって詳細なエラー情報が表示されない可能性があります。Oracle Fail Safeのリソース・コントロール・マネージャにより、エラー情報はWindowsアプリケーションのイベント・ログにロギングされます。詳細なエラー情報は、付録Aを参照してください。
シングルインスタンス・データベースが含まれるグループをオンライン化する際に問題が発生した場合は、次の操作を実行します。
(Oracle Fail Safe Managerグループの「アクション」メニューから)「検証」を選択すると、Oracle Fail Safeではグループの構成をチェックし、問題が見つかると修正を行います。
「検証」グループ・アクションで問題が見つかった場合は、その問題を手動で解決するヒントとなるエラー・メッセージが返されます。
Oracle Netでは、エラーの検出や、リスナーを介したデータベースへのアクセスのたびに、リスナー・ログ・ファイルにエントリを作成します。このログ・ファイルの中に、問題の識別に役立つエラーがないかどうかを調べます。
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のデータベース・パスワードの変更を更新する方法の詳細は、7.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コマンドレットの詳細は、第5章を参照してください。
Oracle Fail Safeでシングルインスタンス・データベースをオンライン化またはオフライン化しようとして問題が発生することがあります。この問題の原因として、データベース認証の設定方法に問題があることが考えられます。この問題を解決するには、次の操作を実行します。
Oracle Databaseの「通常」プロパティ・ページでデータベースを認証する「SYSアカウントを使用」を選択した場合は、データベース初期化パラメータ・ファイル(initdatabase-name.ora
)でREMOTE_LOGIN_PASSWORDFILE
初期化パラメータがSHARED
またはEXCLUSIVE
に設定されていることを確認します。
7.5項に、データベース認証に対してこのパラメータを適切に設定する方法が記載されています。
Oracle Fail Safeでグループ内のデータベースにアクセスできることを確認します。
グループの検証や、データベースがオンライン状態であることを確認するためのポーリングなど、Oracle Fail Safeにより実行される一部の操作では、Oracle Fail Safeでグループ内にあるデータベースにアクセスできる必要があります。データベース・アカウントのパスワードが変更されている場合は、Oracle Fail Safe Managerでその変更を更新します。更新しないと、Oracle Fail SafeでIs Aliveポーリングを使用するデータベースの監視ができなくなります。この状態は、Windowsアプリケーション・イベント・ログにより記録されます。
7.5.2項に、データベース・パスワードの正しい更新方法が記載されています。
スタンドアロン・データベースまたはグループに構成されているデータベースに接続しようとして問題が検出された場合は、データベースのOracle Net構成を調べる必要があります。
Oracle Fail Safeは、「検証」グループおよび「検証」スタンドアロン・データベース操作を提供して、Oracle Net構成を検証および修正できます。詳細は、6.1.2項および6.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) ) )
他のリスナーでLISTENER_A
と同じアドレスまたはデータベースSIDを使用しようとすると、起動に失敗します。
リスナーを起動できない一般的な原因のもう1つは、ネットワーク名です。リスナーが使用するネットワーク名は、Oracle Fail Safeがリスナーを起動しようとしているノード上でアクティブである必要があります。
ネットワーク構成の問題のトラブルシューティングに関する詳細は、Oracle Netのマニュアル(ログ・ディレクトリの情報を含む)を参照してください。
Oracle Fail Safe Managerでは、リスナー制御ユーティリティ(LSNRCTL
)を使用して新規リスナーを作成し、Oracleホームにあるファイルに出力します。
たとえば、Oracleホームとネットワーク・ディレクトリのパスがC:\Oracle\product\12.1.0\dbhome_1\NETWORK\ADMIN
で、リスナーが動作するネットワーク名がntclu-155
の場合、リスナー出力ファイルは、次のディレクトリおよびファイルに書き込まれます。
C:\Oracle\product\12.1.0\dbhome_1\NETWORK\LOG\Create_fslntclu-155.log
各リスナーについて、Create_
listenername
および.log
拡張子を使用して名付けられたそれぞれの出力ファイルが存在します。(この例では、リスナー名はfslntclu_155
です。)新規リスナーの作成が困難な場合は、出力ファイルを使用して問題を診断できます。
Oracle Fail Safeがlistener.ora
またはtnsnames.ora
ファイルを変更すると、そのファイルの元のバージョンが毎回アーカイブされます。Oracle Fail Safeによって変更される前のOracle Netのサービス名定義やリスナー定義を参照する必要がある場合は、構成ファイルのアーカイブ・バージョンを調べます。
Oracle Fail Safeでは、構成ファイルの以前のバージョンが保存されます。ファイルが更新されると、ファイルの以前のバージョンの名前がfilenametimestamp
.ora
に変更されます。filename
.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の使用に関する情報を検索できます。
Oracle Fail Safeでは、プラガブル・データベースのオープンまたはクローズにトリガーの使用をサポートしていません。たとえば、次のようなトリガーは、フェイルオーバー・クラスタ内のデータベースに使用しないでください。
CREATE OR REPLACE TRIGGER sys.after_startup AFTER STARTUP ON DATABASE BEGIN EXECUTE IMMEDIATE 'ALTER PLUGGABLE DATABASE ALL OPEN'; END after_startup;