| Oracle® Enterprise Manager Oracle Exadata Database Machineスタート・ガイド 13c リリース2 E78873-01 |
|
 前へ |
 次へ |
この章では、Exadataプラグインのインストール、検出および構成に関するトラブルシューティングのヒントおよび方法について説明します。内容は次のとおりです。
リリース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接続を設定するには、エージェント・ユーザーとして次の手順を実行します。
多くの場合、エラー・メッセージそのものにエラーの原因が示されています。OMSおよびエージェントのログでエラー・メッセージを探す(dbmdiscoveryを大/小文字区別なしで検索する)か、「検出」ウィンドウ内でエラー・メッセージを探します。
内容は次のとおりです。
すべてのハードウェア・コンポーネントが認識されていて、接続可能である必要があります。それ以外の場合は通信障害が発生します。Exadataラックの各ハードウェア・コンポーネントに対してpingコマンドを実行して、すべての名前が解決されることを確認します。
相関識別子の収集中、Enterprise Manager Cloud Control 13c内のマップ・ターゲットが失敗することがあります。この失敗は、資格証明が正しくない場合、またはターゲット(たとえば、ILOM)のレスポンスが遅すぎる場合に発生することがあります。
ILOM上でオープンしているセッション数が制限を超えていると、ILOMの処理が遅くなります。一時的にILOM上のセッションをクローズすることで、この問題を解決できます。
ターゲットのラック配置は、次の場合に失敗することがあります。
examanがターゲットの有効なラック位置を返さない場合。
同じ場所に既存のターゲットがある場合。
Oracle Exadata Database Machineの検出が失敗する場合は、診断のため、次の情報を収集してください。
AGENT_ROOT/agent_inst/sysman/emd/stateディレクトリにあるexaman-*.xml、examan-*.html、targets-*.xmlおよびexaman*.logファイルのすべて。
エージェント・ログ: emagent_perl.trcおよびgcagent.log
OMSログ: emoms.trcおよびemoms.log
ターゲットのサマリー・ページに表示されるエラーのスナップショット(スクリーン・キャプチャ)。
セルそのものが検出されない場合は、次の原因が考えられます。
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
コンピュート・ノードに関する問題があると、次のエラーが生成されることがあります。
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)
コンピュート・ノードまたはインフィニバンド・スイッチの検出に関する問題がある場合、次の原因が考えられます。
インフィニバンド・スイッチのホスト名またはnm2userパスワードが間違っています。
コンピュート・ノードからインフィニバンド・スイッチへのSSH接続が、ファイアウォールによってブロックされています。
インフィニバンド・スイッチが停止しているか、SSHへのレスポンスに時間がかかりすぎています。
コンピュート・ノードまたはインフィニバンド・スイッチの検出に関連する問題を解決するには、次の操作を試行してください。
インフィニバンド・スイッチ・ノードが検出されない場合、EM Exadataでインフィニバンド・スイッチ・モデルまたはスイッチ・ファームウェアがサポートされていない可能性があります。ibnetdiscoverコマンドを実行します。出力は次のようになります。
Switch 36 "S-002128469f47a0a0" # "Sun DCS 36 QDR switch switch1.example.com" enhanced port 0 lid 1 lmc 0
コンピュート・ノードの検出を確認するには、検出に使用したコンピュート・ノードで次のコマンドを実行します。
# ssh <IB switch> -l nm2user ibnetdiscover
コンピュート・ノードが検出されない場合、ibnetdiscoverコマンドを実行します。出力は次のようになります。
Ca 2 "H-00212800013e8f4a" # " xdb1db02 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
Enterprise Managerで管理されていないコンピュート・ノードのインスタンスが発生する場合は、次のトラブルシューティング手順を確認します。
エージェントのホスト名がコンピュート・ノードのホスト名と異なる場合は、次のコマンドをrootとして実行して、エージェントのホスト名に一致させます。
# ibnetdiscover
検出用に不適切なエージェントが使用されている場合は、検出用のコンピュート・ノード・エージェントを選択します。
クライアントから管理に(その逆も同じ)コンピュート・ノード名をリセットした場合は、次のコマンドを実行します。
# /usr/sbin/set_nodedesc.sh
エージェントに短いホスト名が使用されている場合は、完全修飾ホスト名の<hostname.domain>を使用してエージェントを再インストールします。
余分なコンポーネントが表示される場合、または欠落しているコンポーネントがある場合は、次のトラブルシューティング手順を確認します。
余分なコンポーネントの場合、Exadata Database Machineメンバーシップでそれを探します。検出されたリストから、余分なコンポーネントを手動で選択解除します。
検出に使用した構成図ファイルを確認します。Enterprise Managerで、コンピュート・ノードの最新のxmlファイル(たとえば、databasemachine.xml)を読み取れることを確認します。
欠落しているコンポーネントの場合は、構成図ファイルの内容を確認します。
新しい構成図ファイルを生成する必要がある場合は、Oracleサポートでサービス・リクエスト(SR)を記入し、詳細を提供します。
インフィニバンド・ネットワーク・パフォーマンス・ページにデータが表示されない場合は、コンピュート・ノードの/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は、モニタリング・エージェントの例を示しています。
図8-1 モニタリング・エージェントの例
ILOM、PDU、KVMまたはCiscoスイッチの場合、次の原因が考えられます。
Exadata Database Machineスキーマ・ダイアグラム・ファイルで、間違ったIPアドレスが指定されています。
モニタリング資格証明が設定されていないか、間違っています。検証する手順は次のとおりです。
Enterprise Managerにログインします。
「設定」→「セキュリティ」→「モニタリング資格証明」をクリックします。
「モニタリング資格証明」ページで、「Oracle Exadata」ターゲット・タイプをクリックします。次に、モニタリング資格証明を設定します。
Exadata Database Machineの検出プロセスがハングする場合は、次のトラブルシューティング手順を確認します。
ネットワークを調査して、次の点を確認します。
ホスト名が解決できること。
エージェントからOMSにアクセスできること。
コンソールから簡単なジョブを実行できること。
OMSからエラーが報告される場合は、次のログ・ファイルをチェックします。
MW_HOME/gc_inst/sysman/log/emoms.log
リポジトリの問題の場合は、リポジトリ・データベースのalert.logファイルを確認します。
エージェントの問題の場合は、次のログ・ファイルを確認します。
$AGENT/agent_inst/sysman/log/gcagent.log
ガイドされた検出の前提条件として、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のラック・タイプやパーティション化に応じて不具合がある場合とない場合があります。
構成図ファイルが空白の場合は、次を実行します。
ブラウザがEnterprise Manager Cloud Control 12cをサポートしているかチェックします。
検出を再度実行し、メッセージを確認します。
それと同時に、例外のemoms.logファイルを確認します。
コンポーネントが見つからない場合は、次を実行します。
構成図のページに手動で追加します(「編集」をクリック)。
Enterprise Manager内にコンポーネントが存在することをチェックします。それがモニターされているか確認します。
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 Database Machineで2つのInfiniBandスイッチを選択した場合、パッチの詳細セクションは空です。1つのパッチの2つのインフィニバンド・スイッチへのインストールは作用しません - インストール済パッチの詳細のみです。
回避策: インフィニバンド・スイッチごとに選択して、パッチの詳細を確認します。
問題: Oracle ASRがExadata Storage Serverで動作しないという問題が発生することがあります。
解決策: Exadata Storage Serverに、次の2つのサブスクリプションがあることを確認します。
セルのILOMトラップを受信するには、タイプがASRまたはV3ASRである必要があります。
セルからMS MIBトラップを受信するには、タイプがdefault (タイプなし)またはv3である必要があります。
MS MIBのasrタイプのエントリでは、自動的にセルのILOMへのサブスクリプションが追加されます。ILOM SNMPスロットがフルの場合、そのセルに関するサブスクリプション・コマンドが次のエラーで失敗します。
CELL-02669: No slots are available for ILOM SNMP subscribers
ILOMに関して15サブスクライバの制限がある場合、この失敗が発生する可能性があります。次のように、ILOMのいくつかのスロットを解放して、ASRのサブスクリプションを再試行します。
https://XXXCELL-c.example.com)。ターゲットのステータスが誤って「DOWN」と表示される場合は、次を実行します。
セルの場合: 次のコマンドでsshの等価(cellmonitorユーザー)をチェックします。
ssh –i /home/oracle/.ssh/id_dsa –l cellmonitor <cell name> -e cellcli list cell
<cell name>と出力される必要があります
PDUの場合: ブラウザでPDUにアクセスできるかチェックして、それがLANに接続されていることを確認します。
http://<pdu name>
Ciscoスイッチの場合: SNMPのサブスクリプションが正しいかチェックします。詳細は、「Ciscoイーサネット・スイッチ・ターゲットのSNMPの設定」を参照してください。
ターゲットのステータスが「メトリック収集エラー」と表示される場合は、次を実行します。
アイコンにカーソルを置くか、インシデント・マネージャに移動します。
エラーの全文を読みます。
「モニタリング構成」ページにアクセスして、設定を確認します。「設定」メニューから「モニタリング構成」を選択します。
新規コレクションのトリガー: 「ターゲット」メニューから、「構成」、「最新収集」、「アクション」の順に選択し、最後に「リフレッシュ」を選択します。
モニタリングしているエージェント・メトリックにブラウザでアクセスします。
https://<agent URL>/emd/browser/main
「ターゲット >>」をクリックし、「レスポンス」をクリックしてその結果を評価します。Oracleサポートでサービス・リクエスト(SR)の記入が必要になる場合もあります。
コンポーネントのステータスが「保留中」という問題の場合は、次のトラブルシューティング手順を参照してください。
Cellsysターゲットのステータスがあまりにも長い間「保留中」であると思われる場合は、次を実行します。
クラスタASM、データベースおよびストレージ・セルの関連付けがあることを確認します。
関連付けられているターゲット・データベースのステータスをチェックして修正します。
関連付けられているターゲット・ASMクラスタのステータスをチェックして修正します。
すべてのセル・サーバー・ターゲットの「稼働中」ステータスを確認します。
関連付けられていないすべてのcellsysターゲットを削除します。
Exadata Database Machineターゲットまたは関連コンポーネントのステータスがあまりにも長い間「保留中」である場合は、次を実行します。
重複する、または保留中の削除ターゲットを確認します。「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。
ターゲットの構成を確認します。ターゲットのホームページのメニューから、「ターゲット設定」、「モニタリング構成」の順に選択します。
エージェントまたはOMSログ内のターゲット名を検索します。
$ grep <target name> gcagent.log or emoms.log
ExadataのいくつかのX4シリーズの出荷物およびそれ以降のすべてのハードウェア・バージョンでは、Exadata Database Machineには新しいバージョンのファームウェアを実行するアップグレード済のPDUが含まれています。このファームウェアは、高度なManagement Information Base (MIB)と出荷され、Exadata 12.1.xプラグインと互換性がありません。このような場合、元のMIBを使用し、図8-2の説明に従い、PDU設定を変更してください。
図8-2 元のMIBの選択
