| Oracle® Enterprise Manager Exadata管理スタート・ガイド リリース12.1.0.6.0 B69691-09 |
|
 前 |
 次 |
この章では、Exadata Database Machineプラグインをインストールおよび構成するトラブルシューティングのヒントおよび技術について説明します。
トラブルシューティングの内容は次のとおりです。
リリース12.1.0.1.0では、SSHキーは<ORACLE_HOME>/.sshにあります(ORACLE_HOMEはEnterprise Managerエージェントのインストール・ディレクトリです)。次に例を示します。
/u01/app/oracle/product/gc12/agent/core/12.1.0.1.0
|
注意: 一部のメトリック収集は、~/.ssh/known_hostsに依存しています。 |
リリース12.1.0.2.0以降では、SSHキーの場所はエージェント・ユーザーの$HOME/.sshにあります。
エージェントが実行されているコンピュータとOracle Exadata Storage Serverの間にSSH接続を設定するには、エージェント・ユーザーとして次の手順を実行します。
Enterprise Managerエージェントが実行されているコンピュータにログインし、端末を開き、エージェント・ユーザーとして次のコマンドを実行してSSHのプライベート・キーとパブリック・キーの組を生成します(存在しない場合)。
リリース12.1.0.1.0の場合:
$ cd <ORACLE_HOME>/.ssh $ ssh-keygen -t dsa -f id_dsa
<ORACLE_HOME>は、Enterprise Managerエージェントのインストール・ディレクトリです。
リリース12.1.0.2.0の場合:
$ cd $HOME/.ssh $ ssh-keygen -t dsa -f id_dsa
$HOMEは、エージェント・ユーザーのホーム・ディレクトリです。
パブリック・キー(id_dsa.pub)をストレージ・セルの/tmpディレクトリにコピーします。
$ scp id_dsa.pub root@<cell_ipaddress>:/tmp
id_dsa.pubファイルのコンテンツを、cellmonitorユーザーのホーム・ディレクトリにある.sshディレクトリ内のauthorized_keysファイルに追加します。
$ ssh -l root <cell_ipaddress> "cat /tmp/id_dsa.pub >> ~cellmonitor/.ssh/authorized_keys"
|
注意: authorized_keysファイルが存在しない場合は、ユーザーcellmonitorのホーム・ディレクトリ内の.sshディレクトリにid_dsa.pubファイルをコピーして作成します。
$ ssh -l root <cell_ipaddress> "cp /tmp/id_dsa.pub ~cellmonitor/.ssh/authorized_keys; chown cellmonitor:cellmonitor ~cellmonitor/.ssh/authorized_keys" |
.sshディレクトリとauthorized_keysに正しいファイル権限があることを確認します。
# chmod 700 ~cellmonitor/.ssh # chmod 600 ~cellmonitor/.ssh/authorized_keys
多くの場合、エラー・メッセージそのものにエラーの原因が示されています。OMSおよびエージェントのログでエラー・メッセージを探す(dbmdiscoveryを大/小文字区別なしで検索する)か、「検出」ウィンドウ内でエラー・メッセージを探します。共通のエラーには、次が含まれます。
すべてのハードウェア・コンポーネントが認識されていて、接続可能である必要があります。それ以外の場合は通信障害が発生します。Exadataラックの各ハードウェア・コンポーネントに対してpingコマンドを実行して、すべての名前が解決されることを確認します。
計算ノードに関する問題があると、次のエラーが生成されることがあります。
The selected compute node is not an existing host target managed by Enterprise Manager. Please add the compute node as managed target before you continue.
このエラーの原因として、次のことが考えられます。
Exadata Database Machine検出の前に計算ノードがEnterprise Managerホスト・ターゲットとして追加されていませんでした。
計算ノードのホスト・ターゲット名がIPアドレスになっています。この場合、/etc/hostsまたはDNSに問題がある可能性があります。
ホスト・ターゲット名がドメイン名で完全修飾されていません(例: hostname.mycompany.com)
セルそのものが検出されない場合は、次の原因が考えられます。
RDBMS Oracle Homeリリース11.2が正しくインストールされていません。
計算ノードの/etc/oracle/cell/network-config/cellip.oraファイルが存在しないか、エージェント・ユーザーから読取り可能でない、またはセルがそのファイル内にリストされていません。
セルが/etc/oracle/cell/network-config/cellip.oraファイル内にリストされていません。
Management Server (MS)またはcellsrvが停止しています。
セル管理IPが間違って変更されています。cellsrvとMSの両方を停止すると、解決することがあります。
有効な管理IPでセルが検出されていることを確認するには、検出に使用した計算ノードで次のコマンドを実行します。
$ORACLE_HOME/bin/kfod op=cellconfig
計算ノードまたはインフィニバンド・スイッチの検出に関する問題がある場合、次の原因が考えられます。
インフィニバンド・スイッチのホスト名またはnm2userパスワードが間違っています。
計算ノードからインフィニバンド・スイッチへのSSH接続が、ファイアウォールによってブロックされています。
インフィニバンド・スイッチが停止しているか、SSHへのレスポンスに時間がかかりすぎています。
計算ノードまたはインフィニバンド・スイッチの検出に関連する問題を解決するには、次の操作を試行してください。
インフィニバンド・スイッチ・ノードが検出されない場合、EM Exadataでインフィニバンド・スイッチ・モデルまたはスイッチ・ファームウェアがサポートされていない可能性があります。ibnetdiscoverコマンドを実行します。出力は次のようになります。
Switch 36 "S-002128469f47a0a0" # "Sun DCS 36 QDR switch myhost1.example.com" enhanced port 0 lid 1 lmc 0
計算ノードの検出を確認するには、検出に使用した計算ノードで次のコマンドを実行します。
# ssh <IB switch> -l nm2user ibnetdiscover
計算ノードが検出されない場合、ibnetdiscoverコマンドを実行します。出力は次のようになります。
Ca 2 "H-00212800013e8f4a" # " myhost1 S 192.168.229.85 HCA-1”
11.2.2.2.2では不具合により、計算ノード・イメージにSが表示され、インフィニバンドIPが存在しないと示されます。出力は次のようになります。
Ca 2 " H-00212800013e8f4a " # "xdb1db02 HCA-1”
この問題を回避するには、rootとして計算ノードで次のコマンドを実行します。
# /opt/oracle.cellos/ib_set_node_desc.sh
インフィニバンド・ネットワーク・パフォーマンス・ページにデータが表示されない場合は、計算ノードの/opt/oracle.SupportTools/em/ディレクトリ内のファイルがパブリックから読取り可能になっていることを再度確認します。詳細は、Oracle Bug#13255511を参照してください。
ILOM、PDU、KVMまたはCiscoスイッチが検出されない場合、最も可能性の高い原因はExadata Database Machineスキーマ・ファイルが読み取れないか、不適切なデータが含まれていることです。「Exadata Database Machineスキーマ・ファイルのトラブルシューティング」を参照してください。
Exadata Database Machineのガイドされた検出中にエラーが表示されないのに、「コンポーネントの選択」ページにターゲットが表示されません。考えられる原因と解決策は次のとおりです。
「すべてのターゲット」ページを確認して、ターゲットがEnterprise Managerターゲットとして追加されていないことを確認します。
Enterprise Managerにログインします。
「ターゲット」、「すべてのターゲット」の順に選択します。
「すべてのターゲット」ページで、Oracle Exadataターゲットがリストに表示されているかどうかを確認します。
手動で追加したターゲットは、アソシエーションを介してExadata Database Machineシステム・ターゲットに接続されないことがあります。この問題を修正するには、次の手順を行います。
Exadata Database Machineのガイドされた検出を開始する前に、これらのターゲットを削除します。
あるいは、emcliコマンドを使用して、これらのターゲットをメンバーとして適切なシステム・ターゲットに追加します。
Exadata Database Machineのガイドされた検出の後、ターゲットが停止している、またはメトリック収集に関連する問題があるというエラーが表示されることがあります。考えられる原因および推奨される解決策は、次のとおりです。
セルまたはインフィニバンド・スイッチの場合、SSHの設定が適切に構成されていない可能性があります。この問題のトラブルシューティングを行い、解決するには、次の手順を実行します。
<AGENT_INST>/.ssh/id_dsa.pubファイル内のエージェントのSSH公開鍵が、cellmonitorまたはnm2userの$HOME/.sshのauthorized_keysファイル内にありません。
権限を確認します。.sshおよびauthorized_keysの権限設定は、次のようになっている必要があります。
drwx------ 2 cellmonitor cellmonitor 4096 Oct 13 07:06 .ssh -rw-r--r-- 1 cellmonitor cellmonitor 441842 Nov 10 20:03 authorized_keys
PerformOperationExceptionエラーを解決します。詳細は、「Exadata Database Machineスキーマ・ファイルのトラブルシューティング」を参照してください。
SSH設定が適切に設定されているのに、ターゲットのステータスが停止している場合、ターゲットを監視するように割り当てられた有効な監視エージェントおよびバックアップ・エージェントが存在していることを確認します。確認するには、「データベース・マシン」メニューをクリックし、「監視エージェント」を選択します。図8-1は、モニタリング・エージェントの例を示しています。
ILOM、PDU、KVMまたはCiscoスイッチの場合、次の原因が考えられます。
Exadata Database Machineスキーマ・ダイアグラム・ファイルで、間違ったIPアドレスが指定されています。
監視資格証明が設定されていないか、間違っています。検証する手順は次のとおりです。
Enterprise Managerにログインします。
「設定」→「セキュリティ」→「監視資格証明」をクリックします。
「監視資格証明」ページで、「Oracle Exadata」ターゲット・タイプをクリックします。次に、監視資格証明を設定します。
ガイドされた検出の前提条件として、Exadata Database Machineスキーマ・ファイルのバージョン503が必要です。検出のトラブルシューティングの一部として、スキーマ・ファイルに関連して考えられる原因および推奨される解決策は次のとおりです。
計算ノードのスキーマ・ファイルが存在しないか、エージェント・ユーザーが読み取ることができません。
Exadata Release 11.2.3.2以上の場合、スキーマ・ファイルは次のとおりです。
/opt/oracle.SupportTools/onecommand/catalog.xml
Exadataリリース11.2.3.1以前の場合、スキーマ・ファイルは次のとおりです。
/opt/oracle.SupportTools/onecommand/databasemachine.xml
PerformOperationExceptionエラーが表示された場合、エージェントNMOがsetuid-rootに対して構成されていません。
次のOMSログに移動します。
2011-11-08 12:28:12,910 [[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] ERROR model.DiscoveredTarget logp.251 - ERROR: NMO not setuid-root (Unix only) oracle.sysman.emSDK.agent.client.exception.PerformOperationException:
rootとして、次のコマンドを実行します。
# <AGENT_INST>/root.sh
計算ノードで、/etc/pam.dファイル内にpam_unix.soではなくpam_ldap.soが使用されています。
エージェント・ユーザーとパスワードは正しいのに、エージェント・ログに次のエラーが表示されます。
oracle.sysman.emSDK.agent.client.exception.PerformOperationException: ERROR: Invalid username and/or password
Exadata Database Machine Configuratorに既知の不具合があるため、スキーマ・ファイルにエラーが含まれます。
Exadata Database Machine Configuratorがバージョン12.0であることを確認します。
スキーマ・ファイルがバージョン503であることを確認します。
それ以前のバージョンでは、Exadata Database Machineのラック・タイプやパーティション化に応じて不具合がある場合とない場合があります。
「リソース使用率」グラフにデータが表示されない場合は、SQL問合せ「view object」を実行して、どのデータが欠落しているかを調べます。一般的な問題には、次のものがあります。
スキーマ・ファイルが正しくロードされていません。
クラスタ、データベースおよびASMがEnterprise Managerターゲットとして追加されていません。
データベースまたはセル・ターゲットが停止しているか、メトリック収集エラーを戻します。
メトリックはEnterprise Managerリポジトリ内に収集されるが、IS_CURRENT != Yという設定になっています。
Exadata導出のアソシエーション・ルールは、ExadataおよびDB/ASM ECMデータに依存します。メトリック収集スケジュールによっては、このデータが表示されるまでに最大30分かかります。データの可用性を確認するには、次の手順を実行します。
Enterprise Manager Cloud Controlコンソールから、次のようにします。
「ターゲット」→「すべてのターゲット」をクリックします。
「すべてのターゲット」ページで、リストから「Oracle Exadata」ターゲットをクリックします。
「データベース・システム」→「構成」→「最新収集」をクリックします。
「最新の構成」ページで、「アクション」→「リフレッシュ」をクリックします。
コマンド・ラインから:
# emctl control agent runCollection # target_name:target_type <collectionName>
他にも、次のようなトラブルシューティング・ヒントがあります。
Enterprise Managerリポジトリ内にECMデータが収集されて存在していることを確認します。
SQL+で問合せを実行して、問合せ内のすべてのデータおよび条件が満たされていることを確認します。
タイミングの問題がないか調べるデバッグ・ロギングを有効にして、トリガーを確認します。
ExadataのいくつかのX4シリーズの出荷物およびそれ以降のすべてのハードウェア・バージョンでは、Exadata Database Machineには新しいバージョンのファームウェアを実行するアップグレード済のPDUが含まれています。このファームウェアは、高度なManagement Information Base (MIB)と出荷され、Exadata 12.1.xプラグインと互換性がありません。このような場合、元のMIBを使用し、図8-2の説明に従い、PDU設定を変更してください。
