7 トラブルシューティング
この章では、Exadataプラグインのインストール、検出および構成に関するトラブルシューティングのヒントおよび方法について説明します。内容は次のとおりです。
検出のトラブルシューティング
多くの場合、エラー・メッセージそのものにエラーの原因が示されています。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/exadata
ディレクトリにあるexaman-*.xml
、examan-*.html
、targets-*.xml
およびexaman*.log
ファイルのすべて。 -
エージェント・ログ:
emagent_perl.trc
およびgcagent.log
-
OMSログ:
emoms.trc
およびemoms.log
-
ターゲットのサマリー・ページに表示されるエラーのスナップショット(スクリーン・キャプチャ)。
-
「前提条件チェック」ページにクリティカル・エラーが表示された場合は、「再試行」メニューをクリックして、「再試行、静的のみ」オプションを選択すると、検出を再試行できます。
Exadata Storage Serverが検出されない
Exadata Storage Server自体が検出されない場合は、次の原因が考えられます。
-
コンピュート・ノードの
/etc/oracle/cell/network-config/cellip.ora
ファイルが存在しないか、そのファイルをエージェント・ユーザーが読取りできません。または、そのファイル内にExadata Storage Serverがリストされていません。 -
Exadata Storage Serverが、
/etc/oracle/cell/network-config/cellip.ora
ファイルにリストされていません。 -
Management Server (MS)またはcellsrvが停止しています。
-
Exadata Storage Server管理IPが不適切に変更されています。cellsrvとMSの両方を停止すると、解決することがあります。
-
Exadata Storage Serverが有効な管理IPで検出されていることを確認するには、検出に使用したコンピュート・ノードのグリッド・インフラストラクチャ・ホームまたはデータベース・ホームから次のコマンドを実行します。
$ORACLE_HOME/bin/kfod op=cellconfig
コンピュート・ノードまたはインフィニバンド・スイッチが検出されない
コンピュート・ノードまたはインフィニバンド・スイッチの検出に関する問題がある場合、次の原因が考えられます。
-
インフィニバンド・スイッチのホスト名または
ilom-admin
パスワードが間違っています。 -
コンピュート・ノードからインフィニバンド・スイッチへのSSH接続が、ファイアウォールによってブロックされています。
-
インフィニバンド・スイッチが停止しているか、SSHへのレスポンスに時間がかかりすぎています。
コンピュート・ノードまたはインフィニバンド・スイッチの検出に関連する問題を解決するには、次の操作を試行してください。
-
インフィニバンド・スイッチ・ノードが検出されない場合、EM Exadataでインフィニバンド・スイッチ・モデルまたはスイッチ・ファームウェアがサポートされていない可能性があります。
ibnetdiscover
コマンドを実行します。出力は次のようになります。Switch 36 "S-002128469f47a0a0" # "Sun DCS 36 QDR switch switch1.example.com" enhanced port 0 lid 1 lmc 0
-
コンピュート・ノードが検出されていない場合は、コンピュート・ノードで
ibnetdiscover
コマンドを実行してください。その出力は、次に示すようなものになります。出力に欠落している値や無効な値がある場合は、問題についてネットワーク管理者に問い合せてください。Ca 2 "H-00212800013e8f4a" # " xdb1db02 S 192.168.229.85 HCA-1“
新たに検出されたExadataデータベース・マシンの余分なまたは欠落しているコンポーネント
検出ウィザードの「コンポーネント」ページにあるコンポーネントのリストに、余分なコンポーネントが含まれている場合やコンポーネントが欠落している場合は、次のトラブルシューティング・ステップを確認してください。
-
余分なコンポーネントの場合、Exadata Database Machineメンバーシップでそれを探します。「コンポーネント」ページで、すでに選択されている不要なコンポーネントの選択を解除します。
-
検出に使用した構成図ファイルを確認します。Enterprise Managerで、コンピュート・ノードの最新の
xml
ファイル(たとえば、databasemachine.xml
)を読み取れることを確認します。 -
欠落しているコンポーネントの場合は、構成図ファイルの内容を確認します。
-
新しい構成図ファイルを生成する場合は、Oracle SupportドキュメントID 1684431.1を参照してください。
ILOM、PDUまたはCiscoスイッチが検出されない
ILOM、PDUまたはCiscoスイッチが検出されない場合、最も可能性の高い原因は、Exadata Database Machine構成図ファイルが読み取れないか、そのファイルに不適切なデータが含まれていることです。「Exadata Database Machineスキーマ・ファイルのトラブルシューティング」を参照してください。
PDUのテスト接続の失敗
テスト接続で、"資格証明が間違っています。正しいPDUユーザー名とパスワード…"のようなエラー・メッセージが表示された場合は、そのメッセージを無視して検出を続行してください。PDUターゲットは、最初に停止ステータスになります。この障害を修正するために、次のいずれかの方法を試してみてください。
-
「PDUのSNMPv3の有効化」のステップを実行して、PDUに手動でSNMPサブスクリプションを追加します。ターゲットは、SNMPが可用性メトリックの収集を開始するとバックアップになります。
-
ターゲットをモニターしているエージェントから、次のコマンドを実行します。
emctl control agent runCollection <pdu-target-name>:oracle_si_pdu oracle_si_pdu_snmp_config emctl upload agent
ガイドされた検出の「コンポーネント」ステップでターゲットが表示されない
Exadata Database Machineのガイドされた検出プロセスで、「前提条件チェック」ページにエラーが表示されていないのに、「コンポーネント」ページにターゲットが表示されません。考えられる原因と解決策は次のとおりです。
-
「すべてのターゲット」ページを確認して、ターゲットがEnterprise Managerターゲットとして追加されていないことを確認します。
-
Enterprise Managerにログインします。
-
「ターゲット」、「すべてのターゲット」の順に選択します。
-
「すべてのターゲット」ページで、「コンポーネント」選択ページに表示されていなかったターゲットがリストに表示されているかどうかを確認します。
-
-
手動で追加したターゲットは、アソシエーションを介してExadata Database Machineシステム・ターゲットに接続されないことがあります。この問題を修正するには、次の手順を行います。
-
Exadata Database Machineのガイドされた検出を開始する前に、これらのターゲットを削除します。
-
あるいは、
emcli
コマンドを使用して、これらのターゲットをメンバーとして適切なシステム・ターゲットに追加します。
-
検出後にターゲット・ステータスが「停止中」または「メトリック収集エラー」になっている
Exadata Database Machineのガイドされた検出の後、ターゲットが停止している、またはメトリック収集に関連する問題があるというエラーが表示されることがあります。考えられる原因および推奨される解決策は、次のとおりです。
-
Exadata Storage Serverまたはインフィニバンド・スイッチの場合は、SSHの設定が適切に構成されていない可能性があります。この問題のトラブルシューティングを行い、解決するには、次の手順を実行します。
-
<AGENT_INST>/.ssh/id_dsa.pub
ファイル内のエージェントのSSH公開キーが、ilom-adminの$HOME/.ssh
のauthorized_keys
ファイル内にありません。CellCLIを使用してモニターされているExadata Storage Serverの場合:
<AGENT_INST>/.ssh/id_dsa.pub
ファイル内のエージェントのSSH公開キーが、Exadata Storage Serverのcellmonitorユーザーに対応する$HOME/.ssh.authorized_keys
に存在していません。ExaCLI/RESTAPIを使用してモニターされているExadata Storage Serverの場合: Exadata Storage Server資格証明が、Exadata Storage Serverターゲットのモニタリング資格証明として設定されません。
インフィニバンド・スイッチの場合:
<AGENT_INST>/.ssh/id_dsa.pub
ファイル内のエージェントのSSH公開キーが、インフィニバンド・スイッチのilom-adminユーザーに対応する$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設定が適切に設定されているのに、ターゲットのステータスが停止している場合、ターゲットをモニターするように割り当てられた有効なモニタリング・エージェントおよびバックアップ・エージェントが存在していることを確認します。確認するには、「データベース・マシン」メニューをクリックして、「モニタリング・エージェント」を選択します。
-
ILOM、PDUまたはCiscoスイッチの場合、次の原因が考えられます。
-
Exadata Database Machineスキーマ・ダイアグラム・ファイルで、間違ったIPアドレスが指定されています。
-
モニタリング資格証明が設定されていないか、間違っています。
-
-
モニタリング資格証明を確認または設定するには:
-
Enterprise Managerにログインします。
-
「設定」→「セキュリティ」→「モニタリング資格証明」をクリックします。
-
「監視資格証明」ページで、「Exadataデータベース・マシン」ターゲット・タイプをクリックします。モニタリング資格証明が設定されていることを確認します。設定されていない場合は、モニタリング資格証明を設定します。
-
検出時のILOM資格証明の検証の失敗
ILOM資格証明の検証の失敗エラー
13cの検出を実行中に、ILOM資格証明の検証が失敗することがあります。次のエラーが発生する可能性があります。
認証に失敗しました
このエラーに考えられる原因は、無効な資格証明が指定されていることです。
この問題を解決するには、有効な資格証明を使用します。
検出プロセスのハング
Exadata Database Machineの検出プロセスがハングする場合は、次のトラブルシューティング・ステップを確認します。
-
ネットワークを調査して、次の点を確認します。
-
ホスト名が解決できること。
-
エージェントからOMSにアクセスできること。
-
コンソールから簡単なジョブを実行できること。
-
-
OMSからエラーが報告される場合は、次のログ・ファイルをチェックします。
$MW_HOME/gc_inst/sysman/log/emoms.log
-
リポジトリの問題の場合は、リポジトリ・データベースの
alert.log
ファイルを確認します。 -
エージェントの問題の場合は、モニタリング・エージェントの次のログ・ファイルを確認します。
$AGENT/agent_inst/sysman/log/gcagent.log
SNMP構成が見つからない
Ciscoイーサネット・スイッチ・ターゲットのSNMPサブスクリプションの設定
Ciscoイーサネット・スイッチをモニターするエージェントがスイッチをポーリングしてスイッチからSNMPアラートを受信できるように、Ciscoイーサネット・スイッチを構成する必要があります。このためには、次のステップを実行します(例のスイッチ名dm01sw-ip
を、構成するCiscoイーサネット・スイッチ・ターゲットの名前で置き換えます)。
ノート:
この手順は、スイッチのモニタリングが管理者以外のユーザーで実行されている場合、SIターゲットに対して有効です。Enterprise Managerが管理者ユーザーでスイッチをモニターしている場合、次の手順は検出プロセスの一環として自動的に実行されます。
電力配分装置(PDU)ターゲットのSNMPの設定
Enterprise ManagerでPDUターゲットのメトリック・データが収集され、イベントが発生するように、PDUターゲットを監視するエージェントからのSNMP問合せを受け入れるようにPDUを構成する必要があります。また、PDUでは様々なフェーズ値に対する適切なしきい値を設定する必要があります。
PDUでSNMPv3を有効にするためのステップは、「PDUのSNMPv3の有効化」を参照してください。
SNMPサブスクリプション中のタイムアウト・エラー
Exadata Database Machineの検出中に、Exadata Storage ServerにILOM 5.0またはそれ以降があり、SNMPサブスクリプション・ステップでタイムアウト・エラーがスローされる場合は、次の2つの修正をお薦めします。
-
Enterprise Manager Exadataプラグインを13.4 RU12、13.5 RU01またはそれ以降にアップグレードします。
-
Exadata Storage Serverソフトウェアを21.2.0.0.0またはそれ以降のバージョンにアップグレードします。
ログの確認
ログを確認することで、検出、機能性およびトラブルシューティングを適切に検証できます。次に、一部の有用なログとログの場所を示します。
-
OMSのログ
場所: $INSTANCE_HOME/sysman/log
-
emoms.log: OMSコンソール・アプリケーションのメイン・ログ・ファイル
-
emoms.trc: OMSコンソール・アプリケーションのメイン・トレース・ファイル
-
emoms_pbs.log: OMSプラットフォーム・アプリケーションのメイン・ログ・ファイル
-
-
EM管理対象サーバーのログ
場所: EMインスタンス・ベースuser_projects/domains/GCDomain/servers/EMGC_OMS1からの相対パス
-
EMGC_OMS1.log: EMGC_OMSnインスタンスは、このログ・ファイルにサブシステムおよびアプリケーションからのすべてのメッセージを書き込みます。
-
EMGC_OMS1-diagnostic.log: このログ・ファイルには、アプリケーション関連のセキュリティ・エラーが含まれています。
-
-
モニタリング・エージェントのログ
場所: AGENT INSTANCE HOME sysman/logからの相対パス
-
gcagent.log: このログ・ファイルには、エージェントからの追跡、デバッグ、情報、エラーまたは警告メッセージが含まれています。エージェント・フレームワークの問題をデバッグする際に使用できます。
-
gcagent_errors.log: gcagent.logに似ていますが、ERRORレベルおよびFATALレベルのログ・メッセージのみが含まれています。このログには、サイズ制限がありません。
-
emagent_perl.trc: PERLスクリプトのトレース・ファイル。EMでは、一部のメトリックの収集とターゲット検出にPerlスクリプトを使用します。ログ・レベルの変更は、
sysman/config/emd.properties
ファイルのEMAGENT_PERL_TRACE_LEVEL
変数を変更することで可能です。
-
EMCLI検出の問題
デプロイメント・プロシージャの出力には、昇格されていないターゲット、実行されていないタスク(SNMPサブスクリプションやアクセスポイントの作成など)に関するエラー・メッセージと、そうしたエラーを解決するための情報が表示されます。エラーの根本的な原因を解決してから、デプロイメント・プロシージャを再発行します。
問題を選別するために、OMSとエージェントでデバッグ・モードを有効化し、検出を再発行して詳細情報を取得します。
-
OMSの場合:
emctl set property -name log4j.rootCategory -value "DEBUG, emlogAppender, emtrcAppender" -sysman_pwd sysman
-
エージェントの場合:
emcli set_agent_property -agent_name="<agent_target_name>" -value=DEBUG -name="Logger.sdklog.level"
次に、発生および解決の可能性のあるエラーの一部を示します。
保留中ステータスのシステム・インフラストラクチャ・ターゲット
システム・インフラストラクチャ・ターゲットは、最初の構成メトリックが収集されるまで保留中ステータスになっています。
検出後15分経過したターゲットに対して「保留中」ステータスが表示される場合は、そのターゲットのホームページに移動し、原因を調べて手動で修正します。たとえば、メトリック収集のエラーなどが挙げられます。
ほとんどの場合は、ターゲット・メトリックの収集に十分な時間待機することで、再検出することなく問題が解決されます。
検出ステータスのサマリーに「エラー付きで完了」と表示される
EMCLIデプロイメント・プロシージャのステップ「システム作成」が、「エラー付きで完了」のステータスで完了した場合は、発生したエラーに関するサマリー情報がプロシージャの出力に表示されます。次に例を示します。
Number of targets that have been created successfully:8
Number of targets that have errors during discovery:1
List of targets with errors during discovery:
Exatarget_1.example.com
ExpressionEvaluationException: Below error message was returned while executing this Computational step.
----------------------------------------------------------
Some targets are not successfully discovered. Please refer the above target creation details for the detailed errors.
----------------------------------------------------------
ターゲットが検出されてもアソシエーションが作成されない
ターゲットは作成されたが、そのターゲットのアソシエーションは作成されていないことが検出ステータスで報告された場合、次のステップを実行して手動でアソシエーションを作成します。
-
データベース・マシンのホームページから、Exadata Database Machine構成図に手動でターゲットを追加します。これにより、ターゲットはデータベース・マシン・ラックに関連付けられます。
-
次の例に示すように、EMCLIコマンドを使用して、Exadata Database Machineにターゲットを関連付けます。
emcli create_assoc -assoc_type='app_composite_contains' -source='DB_Machine1.example.com:oracle_dbmachine' -dest='DB_Machine1.example.com:host'
検出前のコンポーネントが使用不可またはアクセス不可になっている
Exadata Database Machineメンバー・ターゲットが使用可能またはアクセス可能になっていない場合は、次のいずれかのオプションを使用して問題を解決してください。
-
データベース・マシン検出の実行前に、コンポーネントを使用可能にします。
-
コンポーネントの可用性がいつまでも解決されない場合は、そのコンポーネントをExadata Database Machine検出から除外します。入力ファイルのパラメータcomponent.skipComponentListを使用して、検出を続行してください。コンポーネントが使用可能になったら、そのコンポーネントをcomponent.skipComponentListパラメータから削除し、検出を再発行して既存のExadata Database Machineにターゲットを追加します。
検出時のExaCLIの使用に関する問題
Exadata Storage Serverのモニタリング・メカニズムとしてExaCLIを選択していて、コンピュート・ノードにモニタリング・エージェントがインストールされている場合は、ExaCLIがすでにインストールされています。インストールされていない場合は、選択したエージェントにExaCLIをインストールしてください。
エージェントにExaCLIが正しくインストールされているかどうかを確認するには、次のコマンドを実行します。
[oracle@myagent ~]$ which exacli
/usr/local/bin/exacli
[oracle@myagent ~]$ exacli -c mycell.example.com -l exacli_user --xml -e 'list cell attributes name'
Password: *************
<?xml version="1.0" encoding="utf-8" ?>
<cli-output>
<context cell="mycell"/>
<cell> <name>mycell</name>
</cell>
</cli-output>
入力ファイルのエラー
-
入力ファイルで必須のプロパティ名または値が指定されていない
入力ファイルの一部として欠落しているプロパティを示すエラーが表示されます。たとえば、
プロパティoutputFileLocは定義されていません
。 -
指定した値がプロパティに適用できません
エラー・メッセージに、プロパティに指定可能なすべての値がリストされます。たとえば、
セル・メトリック・ソース入力を確認してください。これはCellCLIまたはExaCLIである必要があります
。 -
指定された名前付き資格証明が入力ファイルに存在しません
Enterprise Managerでは使用できない名前付き資格証明を示すエラーが表示されます。たとえば、
所有者SYSMAN名前BLR_BOX_CREDS_1の資格証明が見つかりません
。 -
指定した名前付き資格証明が無効
資格証明の検証に失敗したことを示すエラーが表示されます。たとえば、
セル・ターゲットExa_Storage_Server_1の資格証明テストに失敗しました。
。
エラーに付随する使用可能な追加情報に基づいて問題を解決し、ターゲットを再検出します。
デプロイメント・プロシージャの出力で提案される解決ステップを使用して、入力ファイル内の情報を更新し、前述のエラーを解決します。デプロイメント・プロシージャを再発行して、ターゲットを検出します。
デプロイメント・プロシージャの出力に表示される不明確なメッセージ
通常、特定のユース・ケースについては、エラーと解決策の詳細な情報が表示されます。不明確なメッセージが表示された場合は、次のようにしてエラーの原因を調べます。
-
情報が記録されているOracle Management Serviceログ(インスタンス・ログ)を確認してくださいこの。ログの場所は、$INSTANCE_HOME/sysman/logです。
-
詳細は、Enterprise Managerサーバー・ログを確認してください。このログは、Enterprise Managerインスタンス・ベースuser_projects /domains/GCDomain/servers/EMGC_OMS1からの相対パスに格納されています。
Exadata Database Machineスキーマ・ファイルのトラブルシューティング
-
コンピュート・ノードのスキーマ・ファイルが存在しないか、エージェント・ユーザーが読み取ることができません。
Exadata Release 11.2.3.2以上の場合、スキーマ・ファイルは次のとおりです。
/opt/oracle.SupportTools/onecommand/databasemachine.xml
指定の場所に構成図ファイルが存在していて、そのファイルとディレクトリにエージェント・インストール・ユーザー・アカウントでアクセスできることを確認します。
-
PerformOperationException
エラーが表示された場合、エージェントNMOがsetuid-root
に対して構成されていません。-
次のOMSログに移動します。
2019-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
問題を解決するには、コンピュート・ノードの
/etc/pam.d
ファイルでpam_unix.so
を使用します。 -
-
構成図ファイルが空白の場合は、次を実行します。
-
ブラウザがEnterprise Manager Cloud Control 13cをサポートしているかチェックします。
-
検出を再度実行し、メッセージを確認します。
-
それと同時に、例外の
emoms.log
ファイルを確認します。
-
-
コンポーネントが見つからない場合は、次を実行します。
-
構成図のページに手動で追加します(「編集」をクリック)。
-
Enterprise Manager内にコンポーネントが存在することをチェックします。それがモニターされているか確認します。
-
Exadata Database Machineの管理のトラブルシューティング
-
スキーマ・ファイルが正しくロードされていません。
-
クラスタ、データベースおよびASMがEnterprise Managerターゲットとして追加されていません。
-
データベース・ターゲットまたはExadata Storage Serverターゲットが停止しているか、メトリック収集エラーを戻します。
-
メトリックはEnterprise Managerリポジトリ内に収集されるが、
IS_CURRENT != Y
という設定になっています。
Exadata導出のアソシエーション・ルール
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+で問合せを実行して、問合せ内のすべてのデータおよび条件が満たされていることを確認します。
-
タイミングの問題がないか調べるデバッグ・ロギングを有効にして、トリガーを確認します。
ターゲット・ステータスの問題
ターゲットのステータスが誤って「DOWN」と表示される場合は、次を実行します。
-
Exadata Storage Serverのモニタリングに
cellCLI
を使用している場合は、次のコマンドで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_Host_Name>/emd/browser/main
「ターゲット >>」をクリックし、「レスポンス」をクリックしてその結果を評価します。Oracleサポートでサービス・リクエスト(SR)の記入が必要になる場合もあります。
ステータス: 保留中の問題
コンポーネントのステータスが「保留中」という問題の場合は、次のトラブルシューティング・ステップを参照してください。
Cellsysターゲット
Cellsysターゲットのステータスがあまりにも長い間「保留中」であると思われる場合は、次を実行します。
-
クラスタASM、データベースおよびExadata Storage Serverの関連付けがあることを確認します。
-
関連付けられているターゲット・データベースのステータスをチェックして修正します。
-
関連付けられているターゲット・ASMクラスタのステータスをチェックして修正します。
-
すべてのExadata Storage Serverターゲットの稼働中ステータスを確認してください。
-
関連付けられていないすべてのcellsysターゲットを削除します。
データベース・マシン・ターゲットまたは関連コンポーネント
Exadata Database Machineターゲットまたは関連コンポーネントのステータスがあまりにも長い間「保留中」である場合は、次を実行します。
-
重複する、または保留中の削除ターゲットを確認します。「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。
-
ターゲットの構成を確認します。ターゲットのホームページのメニューから、「ターゲット設定」、「モニタリング構成」の順に選択します。
-
エージェントまたはOMSログ内のターゲット名を検索します。
$ grep <target name> gcagent.log or emoms.log
IPv6環境にデプロイされないモニタリング・エージェント
問題: IPv6環境で、モニタリング・エージェントがデプロイされません。
原因: IPv6アドレスが/etc/hosts
ファイルに含まれていない場合、エージェントはデプロイされません。
解決策: コンピュート・ノード(または、仮想Exadataの場合はVM)の/etc/hosts
を編集して、OMSホスト名をIPv6アドレスにマップします。
IPv6を使用してExadata Storage ServerのSNMPトラップを受信できない
IPv6環境の場合、完全なモニタリングのために、Enterprise Managerエージェントは、Exadata Storage ServerへのSNMP v 3サブスクリプションを必要とします。
-
Exadata Storage Serverで作成されたSNMP V3ユーザー。方法については、ステップ1を参照してください。
-
Exadata Storage Serverのバージョンは、SNMP V3サブスクリプションをサポートする12.1.2.2以降にする必要があります。
Exadataの検出時にSNMPサブスクリプションが見つからない場合は、次のステップを実行します。
Exadata Storage ServerのSNMP v3サブスクリプションを構成するには: