特殊な要件

この節では、Sun Cluster Support for Oracle Parallel Server/Real Application Clusters 固有の要件を示します。

32 ビットモードまたは 64 ビットモード

Oracle UDLM および Oracle リレーショナルデータベースにどのアーキテクチャを使用するかを決める前に、以下の点に注意してください。

• 両方の Oracle コンポーネントのアーキテクチャが一致する必要があります。 たとえばOracle UDLM に 64 ビットアーキテクチャを使用する場合は、RDBMS にも 64 ビットアーキテクチャを使用する必要があります。

• Oracle コンポーネントに 32 ビットアーキテクチャを使用する場合は、それらのコンポーネントが配置されたノードを 32 ビットモードまたは 64 ビットモードのどちらででもブートできます。 しかし、Oracle コンポーネントに 64 ビットアーキテクチャを使用する場合は、それらのコンポーネントが配置されたノードを 64 ビットモードでブートする必要があります。

• すべてのノードをブートするときは、同じアーキテクチャを使用する必要があります。 たとえば、32 ビットアーキテクチャを使用するように 1 つのノードをブートする場合は、全ノードとも 32 ビットを使用するようにブートする必要があります。

ログファイルの場所

次に、データサービスログファイルの場所を示します。

• 現在のログ: /var/cluster/ucmm/ucmm_reconf.log

• 以前のログ: /var/cluster/ucmm/ucmm_reconf.log.0 (0, 1,...) – この場所は、Oracle UDLM パッケージによって異なります。

• Oracle UDLMログ: /var/cluster/ucmm/dlm_ nodename/logs – この場所に Oracle のログファイルを見つけることができない場合は、Oracle のサポートにお問い合わせください。

• Oracle UDLM コアファイル: /var/cluster/ucmm/dlm_ nodename/cores – この場所に Oracle のログファイルを見つけることができない場合は、Oracle のサポートにお問い合わせください。

ノード障害と回復の手順

Oracle Parallel Server/Real Application Clusters 環境では、複数の Oracle インスタンスが協力して同じ共有データベースへのアクセスを提供します。 Oracle クライアントは、任意のインスタンスを使用してデータベースにアクセスできます。 したがって、1 つまたは複数のインスタンスで障害が発生しても、クライアントは残りのインスタンスに接続することによって、引き続きデータベースにアクセスできます。

1 つのノードで障害が発生する場合は、ノードをメンテナンスモードでブートし、問題を解決してください。 問題を修正した後、ノードをリブートします。 詳細については、『Sun Cluster のシステム管理 (Solaris OS 版)』を参照してください。

このデータサービスをインストールする場合、ノードをリブートする前に、Oracle RDBMS ソフトウェアのインストールと Oracle データベースの作成の前のすべての手順を完了してください。 これらをすべて実行しないと、ノードはパニックを引き起こします。 ノードがパニックを起こした場合は、メンテナンスモードでブートして問題を解決する必要があります。 問題を修正した後、ノードをリブートする必要があります。 完了しなければならない手順は、表 2–1 にリストされています。

Oracle Parallel Server/Real Application Clusters での Sun Cluster LogicalHostname リソースの使用

Oracle Parallel Server/Real Application Clusters のインスタンスを実行しているクラスタノードで障害が生じた場合、クライアントアプリケーションが実行しようとしていた操作が別のインスタンスで再び実行される前にタイムアウトにする必要があります。 TCP/IP ネットワークのタイムアウトが頻繁に起きる場合、クライアントアプリケーションで障害を検出するのに長時間かかることがあります。 通常、クライアントアプリケーションでこの種の障害を検出するのに必要な時間は、3 分から 9 分です。

このような場合、クライアントアプリケーションは、Sun Cluster LogicalHostname リソースを使って、Sun Cluster 上で動作する Oracle Parallel Server/Real Application Clusters データベースに接続できます。 LogicalHostname リソースを Oracle Parallel Server/Real Application Clusters が動作するノード上でマスターされた別のリソースグループで設定できます。 ノードが失敗した場合、LogicalHostname リソースが Oracle Parallel Server/Real Application Clusters を実行する別の動作中のノードで処理を継続します。 LogicalHostname リソースのフェイルオーバーにより、新しい接続を Oracle Parallel Server/Real Application Clusters の他のインスタンスにつなげることができます。

LogicalHostname リソースをこの目的で使用する前に、既存のユーザー接続への LogicalHostname リソースのフェイルオーバーまたはフェイルバックの影響を考慮してください。

Sun Cluster 3.1 での Oracle Parallel Fail Safe/Real Application Clusters Guard オプションの使用

Oracle Parallel Fail Safe/Real Application Clusters Guard オプションのインストール、管理および操作については、Oracle のドキュメントを参照してください。 この製品オプションを Sun Cluster 3.1 で使用する場合は、 Sun Cluster 3.1 をインストールする前に、以下で説明する点に注意してください。

ホスト名の制限

Oracle Parallel Fail Safe/Real Application Clusters Guard オプションを Sun Cluster 3.1 で使用する場合、クラスタで使用するホスト名に以下の制限が適用されます。

• ホスト名に特殊文字を含めることはできません。

• Sun Cluster 3.1 をインストールしたあとでは、ホスト名を変更することはできません。

これらの制限およびその他の要件について詳しくは、Oracle のドキュメントを参照してください。

Sun Cluster コマンド使用の制限

Sun Cluster 3.1 で Oracle Parallel Fail Safe/Real Application Clusters Guard オプションを使用する場合、以下の操作の実行に Sun Cluster コマンドを使用しないでください。

• Oracle Parallel Fail Safe/Real Application Clusters Guard がインストールするリソースの状態の操作。 Sun Cluster コマンドをこの目的で使用すると、障害が起きる可能性があります。

• Oracle Parallel Fail Safe/Real Application Clusters Guard がインストールするリソースの状態のクエリ。 出力される状態は実際の状態を示さない可能性があります。 Oracle Parallel Fail Safe/Real Application Clusters Guard の状態を確認するには、Oracle が提供するコマンドを使用してください。