| Oracle® Grid Infrastructureインストレーション・ガイド 11gリリース2 (11.2) for IBM AIX on POWER Systems (64-Bit) B57777-08 |
|
 前 |
 次 |
| Oracle® Grid Infrastructureインストレーション・ガイド 11gリリース2 (11.2) for IBM AIX on POWER Systems (64-Bit) B57777-08 |
|
前 |
次 |
この付録では、Oracle Grid Infrastructureのインストールに関するトラブルシューティング情報について説明します。
|
関連項目: ドキュメント・ディレクトリにインストール・メディアとともに含まれるOracle Database 11g Oracle RACのドキュメントを参照してください。
|
この付録の内容は次のとおりです。
次に、インストール中に発生する可能性のある様々なエラーの例を示します。内容は次のとおりです。
suコマンドを使用して変更している場合(rootユーザーのコンソール・ディスプレイで低い権限のユーザーがウィンドウを開いている場合など)に起こります。echo $DISPLAYコマンドを使用して、環境変数に正しいディスプレイ、つまり正しいホストが設定されていることを確認してください。DISPLAY変数が正しく設定されていたら、X Windowを開く権限のあるユーザーでログインしていることを確認するか、またはxhost +コマンドを実行してすべてのユーザーにX Windowを開く許可を与えてください。
サーバー・コンソール上でrootとしてローカルでログインし、su -コマンドを使用してOracle Grid Infrastructureのインストール所有者に変更した場合は、サーバーからログアウトし、Gridのインストール所有者としてログインしなおしてください。
root.shを実行したとき、Oracle Grid Infrastructureのインストールが失敗しました。ローカル・ホスト・エントリがhostsファイルから欠落しているため、Oracle Grid Infrastructureは起動に失敗しました。
Oracle Grid Infrastructureのalert.logファイルには、次のように示されます。
[/oracle/app/grid/bin/orarootagent.bin(11392)]CRS-5823:Could not initialize agent framework. Details at (:CRSAGF00120:) in /oracle/app/grid/log/node01/agent/crsd/orarootagent_root/orarootagent_root.log 2010-10-04 12:46:25.857 [ohasd(2401)]CRS-2765:Resource 'ora.crsd' has failed on server 'node01'.
crsdOUT.logファイルを確認し、次を見つけることで、これが原因であることを検証できます。
Unable to resolve address for localhost:2016 ONS runtime exiting Fatal error: eONS: eonsapi.c: Aug 6 2009 02:53:02
$ xhost fully_qualified_remote_host_name
次に例を示します。
$ xhost somehost.example.com
その後、次のコマンドを入力してください。workstation_nameはワークステーションのホスト名またはIPアドレスです。
Bourne、BashまたはKornシェル:
$ DISPLAY=workstation_name:0.0
$ export DISPLAY
X Windowアプリケーションがローカル・システムで適切に表示されるかどうかを確認するには、次のコマンドを入力します。
$ xclock
モニターにXクロックが表示されます。Xクロックが表示されたら、Xクロックを閉じてOracle Universal Installerを再度起動します。
rootupgrade.shの実行中に移行障害が発生します。確認するには、ログ・ファイルGrid_home /log/hostname/client/ocrconfig_pid.logでエラー「utopen:12:Not enough space in the backing store」を検索してください。/var/opt/oracle/srvConfig.locで既存のRAWデバイス名を確認し、コマンドddを使用して、このRAWデバイスの内容を新しいデバイスにコピーしてください。-verbose引数を使用してクラスタ検証ユーティリティを実行し、特定のノードに対するクラスタ検証ユーティリティ・コマンドの結果がUNKNOWNになる場合、その原因は、検証時に問題が検出されたかどうかをクラスタ検証ユーティリティで判断できないことにあります。結果が「不明」になる場合の、考えられる原因を次に示します。
ノードが停止している。
クラスタ検証ユーティリティで必要な、オペレーティング・システムの共通コマンド・バイナリが、Oracle Grid Infrastructureホームの/binディレクトリまたはOracleホーム・ディレクトリで不足している。
クラスタ検証ユーティリティを起動したユーザー・アカウントには、ノードでオペレーティング・システムの共通コマンドを実行する権限がない。
ノードで、オペレーティング・システム・パッチ、または必須パッケージが不足している。
ノードの最大プロセス数または最大オープン・ファイル数を超えているか、共有メモリー、セマフォなど、IPCセグメントに問題が発生している。
Oracle Grid Infrastructureをインストールするための要件をシステムが満たしていないことがクラスタ検証ユーティリティのレポートに示された場合は、この項の説明に従ってレポートに示されている問題を解決し、クラスタ検証ユーティリティを再実行します。
失敗したノードと示されている各ノードに対して、ユーザー構成およびSSH構成が正常に完了していることをインストール所有者のユーザー構成で確認してください。Oracle Grid Infrastructureのインストールを実行するユーザーには、SSH接続を作成する権限が必要です。
SSHの構成は、OUIのSSH構成オプションで行うことをお薦めします。手動でSSHの構成を行う場合はインストール前に、インストールのためにSSHが構成済の場合はインストール後に、クラスタ検証ユーティリティを使用できます。
たとえば、ユーザー・アカウントoracleのユーザー等価関係を確認するには、su - oracleコマンドを使用し、dateコマンド引数を指定したsshコマンドを次の構文を使用してローカル・ノードで実行し、ユーザー等価関係を手動で確認します。
$ ssh nodename date
このコマンドによって、nodenameに指定した値で指定されたリモート・ノードのタイムスタンプが出力されます。パスワードを求められた場合、SSHの構成を行う必要があります。デフォルトの場所(/usr/binディレクトリ)にsshがある場合は、sshを使用してユーザー等価関係を構成します。ユーザー等価関係は、rshを使用しても確認できます。
SSHを使用してdateコマンドを入力した際に次のメッセージが表示された場合、この問題はユーザー等価関係エラーが原因である可能性があります。
The authenticity of host 'node1 (140.87.152.153)' can't be established. RSA key fingerprint is 7z:ez:e7:f6:f4:f2:4f:8f:9z:79:85:62:20:90:92:z9. Are you sure you want to continue connecting (yes/no)?
「yes」と入力してクラスタ検証ユーティリティを実行し、ユーザー等価関係エラーが解決されたかどうか確認します。
sshがデフォルト(/usr/bin)以外の場所にある場合は、クラスタ検証ユーティリティによって、ユーザー等価関係の検証に失敗したことがレポートされます。このエラーを回避するには、Grid_home/cv/adminディレクトリに移動し、テキスト・エディタでcvu_configファイルを開き、ORACLE_SRVM_REMOTESHELLキーを追加または更新してシステム上のsshパスの位置を指定します。次に例を示します。
# Locations for ssh and scp commands ORACLE_SRVM_REMOTESHELL=/usr/local/bin/ssh ORACLE_SRVM_REMOTECOPY=/usr/local/bin/scp
cvu_configファイルを変更する場合は、次の規則に注意します。
キー・エントリはname=value構文で指定する。
キーに割り当てる各キー・エントリおよび値は適切なものを1のみ定義する。
シャープ記号(#)で始まる行はコメント行であり無視される。
name=value構文が前にない行は無視される。
パス設定の変更後、再度クラスタ検証ユーティリティを実行します。また、sshがデフォルト以外の場所にある場合は、リモート・シェルおよびリモート・コピー・コマンドに別の場所を指定するために引数を追加してOUIを起動する必要があります。これらの引数の使用方法の詳細を表示するには、runInstaller -helpを入力してください。
|
注意: ユーザーまたはOUIがsshまたはrshコマンド(ログインや起動するその他のシェル・スクリプトを含む)を実行し、それらのスクリプトによって出力が行われると、無効な引数または標準の入力に関するエラーが表示されます。これらのエラーの原因を解決する必要があります。
エラーを回避するには、 X11転送についてのメッセージが表示されたら、第2.14.4項「表示およびX11転送構成の設定」のタスクを完了し、この問題を解決します。 次のようなエラーが出力される場合もあります。 stty: standard input: Invalid argument stty: standard input: Invalid argument これらのエラーは、システム上の隠しファイル( |
/bin/ping addressコマンドを使用して、各ノードのアドレスを確認してください。到達できないアドレスを発見した場合は、パブリックおよびプライベート・アドレスのリストを確認して、それらを正しく構成してください。他社ベンダーのクラスタウェアを使用する場合に役立つ情報については、そのベンダーのドキュメントを参照してください。パブリック・ネットワーク・インタフェースおよびプライベート・ネットワーク・インタフェースのインタフェース名は、クラスタ内の各ノードで同じである必要があります。idコマンドを使用して、インストール所有者ユーザー(gridやoracleなど)が正しいグループ・メンバーシップで作成されていることを確認してください。必要なグループを作成していることを確認し、影響のあるノードでユーザー・アカウントを作成または変更して、必要なグループ・メンバーシップを設定してください。
|
関連項目: 必要なグループの作成方法およびインストール所有者ユーザーの構成方法については、2.4項「Oracle Grid Infrastructureのグループ、ユーザーおよびパスの作成」を参照してください。 |
深刻なエラーを見つけるには、まずOracle Grid Infrastructureのアラート・ログを見ます。エラーが発生すると、エラーの原因に関する具体的な情報がある診断ログのパス情報が含まれていることがあります。
重要なイベントが発生した場合には、インストール後に、Oracle Grid Infrastructureがアラート・メッセージを書き込みます。たとえば、Cluster Ready Services(CRS)デーモン・プロセスからのアラート・メッセージは、起動時、中断した場合、フェイルオーバー・プロセスが失敗した場合、CRSリソースの自動再起動が失敗した場合に出力されます。
Oracle Enterprise ManagerはClusterwareのログ・ファイルを監視し、エラーが検出されると「クラスタ・ホーム」ページにアラートを書き込みます。たとえば、投票ディスクが利用できない場合はCRS-1604エラーが発生し、「クラスタ・ホーム」ページにクリティカル・アラートが書き込まれます。「メトリックとポリシー設定」ページで、エラー検出とアラートの設定をカスタマイズできます。
Oracle Grid Infrastructureのログ・ファイルの場所は、CRS_home/log/hostname/alerthostname.logです。CRS_homeはOracle Grid Infrastructureがインストールされたディレクトリ、hostnameはローカル・ノードのホスト名です。
|
関連項目: 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』 |
IBM AIXリリース6.1では、次の問題が発生する可能性があります。
/bin/oslevel 6.1.4.0 /bin/oslevel -s 6100-04-01-0944
この問題は、誤ったオペレーティング・システム・レベルをレポートしているAIXによって発生します。この例では、/bin/oslevelによって戻される値は6.1.0.0です。
Oracle Universal Installer (OUI)のノードの選択ページが表示されない場合、Oracle Grid Infrastructureホーム(LinuxおよびUNIXベース・システムの場合はGrid_home/bin、Windowsベース・システムの場合はGrid_home\BIN)のバイナリ・ディレクトリからolsnodes -vコマンドを実行してクラスタウェア診断を実行し、その出力を分析します。クラスタウェアが動作していないことが出力に示された場合は、クラスタウェアのドキュメントを参照してください。
また、次のコマンド構文を使用してクラスタ・マネージャの整合性を検証します。
cluvfy comp clumgr -n node_list -verbose
前述の構文例で、node_list変数は、クラスタ内のノードのカンマ区切りリストです。
Oracle Grid Infrastructure 11gリリース2 (11.2.0.3)以上では、CVUのhealthcheckコマンド・オプションを使用してOracle Grid InfrastructureおよびOracle Databaseインストールをチェックし、必須要件およびベスト・プラクティス・ガイドラインへの適合性を調べたり、正しく動作していることを確認できます。
次の構文を使用してhealthcheckコマンド・オプションを実行します。
cluvfy comp healthcheck [-collect {cluster|database}] [-db db_unique_name] [-bestpractice|-mandatory] [-deviations] [-html] [-save [-savedir directory_path]
次に例を示します。
$ cd /home/grid/cvu_home/bin $ ./cluvfy comp healthcheck -collect cluster -bestpractice -deviations -html
オプションは次のとおりです。
-collect [cluster|database]
このフラグは、Oracle Grid Infrastructure (クラスタ)またはOracle Database (データベース)のチェックの実行を指定する場合に使用します。healthcheckオプションでcollectフラグを使用しない場合、cluvfy comp healthcheckではOracle Grid InfrastructureとOracle Databaseの両方のチェックが実行されます。
-db db_unique_name
このフラグを使用して、dbフラグの後に入力した一意のデータベース名に対するチェックを指定します。
CVUでは、JDBCを使用してcvusysユーザーとしてデータベースに接続し、様々なデータベース・パラメータが検証されます。このため、-dbフラグで指定したデータベースに対してチェックを実行する場合は、最初にそのデータベースでcvusysユーザーを作成し、このユーザーにCVU固有の役割であるcvusappを付与する必要があります。cvusappの役割のメンバーに、システム表に対するselect権限を付与する必要もあります。
SQLスクリプトがCVU_home/cv/admin/cvusys.sqlに含まれており、このユーザーの作成を容易にします。このSQLスクリプトを使用して、CVUにより検証するすべてのデータベースでcvusysユーザーを作成します。
dbフラグを使用し、一意のデータベース名を指定しない場合、CVUではクラスタのすべてのOracle Databaseが検出されます。これらのデータベースでベスト・プラクティス・チェックを実行する場合は、各データベースでcvusysユーザーを作成し、ベスト・プラクティス・チェックを実行するのに必要なcvusappの役割とselect権限をこのユーザーに付与する必要があります。
[-bestpractice | -mandatory] [-deviations]
ベスト・プラクティス・チェックを指定するにはbestpracticeフラグを使用し、必須チェックを指定するにはmandatoryフラグを使用します。ベスト・プラクティスの推奨事項または必須要件からの差異のみを確認することを指定するには、deviationsフラグを追加します。-bestpracticeまたは-mandatoryのいずれかのフラグを指定できますが、両方のフラグを指定することはできません。-bestpracticeまたは-mandatoryのいずれも指定しない場合は、ベスト・プラクティスと必須要件の両方が表示されます。
-html
htmlフラグを使用すると、詳細レポートがHTML形式で生成されます。
htmlフラグを指定し、CVUで認識されるブラウザがシステムで使用可能な場合は、チェックの完了時にブラウザが起動されてレポートがブラウザに表示されます。
htmlフラグを指定しない場合、詳細レポートはテキスト・ファイルで生成されます。
-save [-savedir dir_path]
検証レポート(cvuchecdkreport_timestamp.txtおよびcvucheckreport_timestamp.htm)を保存するには、saveフラグまたは-save -savedirフラグを使用します(timestampは検証レポートの日時)。
saveフラグを単独で使用すると、レポートはパスCVU_home/cv/reportに保存されます(CVU_homeはCVUバイナリの場所)。
-save -savedirフラグを使用し、CVUレポートを保存するパスを入力すると、指定したパスにCVUレポートが保存されます。
インターコネクトに複数のネットワーク・インタフェース・カード(NIC)を使用する場合で、それらを冗長インターコネクトを使用してインストール時またはインストール後に構成していない場合は、サード・パーティのソリューションを使用して、オペレーティング・システム・レベルでインタフェースを集約する必要があります。そうしない場合、1つのNICの障害が、クラスタ・ノードの可用性に影響します。
集約されたNICカードを使用し、Oracle Clusterware冗長インターコネクト機能を使用する場合、それらのカードは異なるサブネット上に存在する必要があります。サード・パーティ・ベンダーの集約方法を使用する場合は、そのベンダーの製品に対する指示に従います。
エラーが発生したら、次のシステム検証を実行してください。
スイッチに適切なケーブル(長さやタイプ)やソフトウェアが使用されていることを、ネットワーク・プロバイダに確認してください。場合によっては、負荷によって切断を起こす不具合を回避するため、またはジャンボ・フレームなどの追加機能をサポートするために、インターコネクト・スイッチのファームウェアのアップグレードや、新しいNICドライバ、オペレーティング・システム・レベルの新しいファームウェアが必要になることがあります。こうした修正を行わずに実行すると、初めのインストールは正常に見えても、後でOracle RACデータベースが不安定になることがあります。
ベンダーおよびOracleの推奨事項に従って、VLAN構成、二重化設定、自動ネゴシエーションを確認してください。
インストールによりSCAN VIPアドレスまたはリスナーに関連するエラーが報告される場合は、次の項目をチェックし、ネットワークが正常に構成されていることを確認します。
ファイル/etc/resolv.confをチェックし、それぞれのノード上で内容が同じであることを確認します。
SCANのDNSエントリが存在すること、およびそれが3つの有効なIPアドレスに解決されることを確認します。nslookup scan-nameコマンドを使用します。このコマンドを実行すると、SCANに構成されているDNSサーバー名および3つのIPアドレスが返されます。
pingコマンドを使用して、SCANに割り当てられているIPアドレスをテストします。各IPアドレスのレスポンスを受信します。
|
注意: クラスタ環境用にDNSが構成されていない場合は、各ノードの/etc/hostsファイルでSCANのエントリを作成できます。ただし、/etc/hostsファイルを使用してSCANを解決すると、クラスタ全体に使用可能なSCANは3つではなく1つのみになります。hostsファイル内のSCANの最初のエントリのみが使用されます。 |
パブリック・インタフェースと同じサブネットがSCAN VIPで使用されていることを確認してください。
SCAN、SCAN VIPまたはリスナーに関連するエラーのトラブルシューティングについてさらに支援が必要な場合は、My Oracle Supportを参照してください。たとえば、Doc ID 1373350.1のNoteにはSCAN VIPおよびリスナーの最も一般的ないくつかの問題が含まれます。
次にストレージ構成の問題を示します。
Oracle Grid Infrastructureリリース11.2以上では、ファイル・システムを誤って削除した場合、または記憶域の構成に関する別の問題が発生してOracle Local Registryを失うか、あるいはノードを破損した場合、次の2通りの方法のいずれかでノードをリカバリできます。
オペレーティング・システム・レベルのバックアップからノードをリストアする(推奨)。
ノードを削除した後、ノードを追加する。11.2以上のクラスタでは、プロファイル情報はノードにコピーされ、ノードがリストアされます。
クラスタ内の残りのノードからリストアできるように、クラスタ・ノードを削除して再度追加することを可能にする機能をグリッドのプラグ・アンド・プレイ(GPnP)と呼びます。グリッドのプラグ・アンド・プレイによって、ノードごとの構成データが削減され、明示的にノードを追加したり削除する必要性がなくなります。この機能によって、システム管理者は、テンプレートのシステム・イメージを取得するだけで、それ以上の構成を行わなくても、新しいノードでそのイメージを実行できます。そのため多くの手動操作が不要になり、エラーの発生する可能性が減るだけでなく、構成の変更をより簡単に行えるようになります。ノード単位の構成が排除されると、個々の状態をノードで保持して管理する必要がなくなるため、ノードの交換が容易になります。
グリッドのプラグ・アンド・プレイ機能により、ノード単位の状態が使い捨て可能になることで、データベース・ノードのインストール、構成および管理のコストが削減されます。これによって、再生成された状態でノードを簡単に交換できるようになります。
次のようなaddnode構文を使用してノードのリカバリを開始します。lostnodeは、クラスタに再度追加しているノードです。
グリッド・ネーミング・サービス(GNS)を使用している場合:
$ ./addNode.sh -silent "CLUSTER_NEW_NODES=lostnode"
GNSを使用していない場合:
$ ./addNode.sh -silent "CLUSTER_NEW_NODES={lostnode}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={lostnode-vip}"
リストアするノードでroot.shスクリプトを実行できるようにし、OCRキーを再作成し、他の構成タスクを実行するには、ルートにアクセスする必要があることに注意してください。/usr/local/binの既存の情報を上書きするプロンプトが表示された場合は、デフォルトを受け入れます。
The file "dbhome" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: The file "oraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: The file "coraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]:
