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-*.xmlexaman-*.htmltargets-*.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/.sshauthorized_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構成が見つからない

Exadata Storage ServerのSNMPサブスクリプションの設定

Exadata Storage Serverは、サブスクライバへのSNMP v1/v2およびv3バージョン・ベースのアラート通知をサポートしています。SNMP V3バージョンのアラートを受信するには、snmpuserを使用して、snmpsubscriberリストにモニタリング・エージェントを追加しておく必要があります。snmpSubscribernotificationMethodおよびnotificationPolicyの値を設定するには、次の手順を実行します。

  1. snmpSubscriberの値を設定します。
    • SNMP V1

      # cellcli -e "alter cell snmpSubscriber=((host='[host name]',port=[port]),(host='[host name]',port=[port]))"
      

      [host name]および[port]の値は、Exadata Storage Serverターゲットをモニタリングするエージェントです。

    • SNMP V3

      手順は前と同じですが、ホストとポート、SNMP V3ユーザーとタイプを指定する必要があります。

      ALTER CELL snmpSubscriber=((host='host1.example.com',port=[port], snmpUser='[v3user]', type=V3))
      

      このコマンドの実行前に、v3userがExadata Storage Serverの有効なSNMPユーザーであることを確認します。次のコマンドを実行して確認できます。

      cellcli -e "list cell attributes snmpUser"
      

      Exadata Storage Serverの有効なSNMPユーザーが存在していない場合は、SNMP v 3ユーザーを追加します。「コンピュート・ノードおよびStorage ServerのSNMPv3ユーザーの作成」を参照してください。

    ノート:

    snmpSubsriberの既存の設定を上書きしないように十分に注意してください。既存のサブスクライバが存在する場合は、エージェント・サブスクリプションを追加します。既存のSNMPサブスクライバのリストは、次のようにcellcli -e list cell attributes snmpSubscriberコマンドを使用して取得します。

    # cellcli -e list cell attributes snmpSubscriber
     ((host=ilm-asr.example.com,port=162,community=public,type=asr))
    

    その後、新しいエージェント・サブスクリプションを既存のサブスクリプションに追加して、次のようにalter cell snmpsubscriberコマンドを実行します。

    #cellcli -e "alter cell snmpSubscriber=((host='ilm-asr.example.com',port=162,
    community=public,type=asr),(host='[host name]',port=[port]),(host='[host name]',port=[port]))"
  2. SNMP V3では、Enterprise Managerで次を更新します。
    • Enterprise Managerで、Exadata Storage Serverターゲットに設定したSNMP V3モニタリング資格証明が、Exadata Storage ServerのSNMP V3ユーザーと一致していることを確認します。

      • Enterprise Managerにログインします。

      • 「設定」メニューから「セキュリティ」を選択し、「モニタリング資格証明」を選択します。

      • 「Exadata Storage Server」タイプを選択して、「モニタリング資格証明の管理」をクリックします。

      • Exadata Storage Serverを選択して、SNMP V3資格証明を設定します。

    • Enterprise Managerで、Exadata Storage Serverターゲットに対して「モニタリング構成」プロパティの「SNMPエンジンID」が設定されていることを確認します。

      • Enterprise Managerにログインします。

      • Exadata Storage Serverのホームページに移動します。

      • 「Exadata Storage Server」メニューから、「モニタリング構成」を選択します。

      • エンジンIDプロパティが設定されていない場合は、Enterprise Managerで手動で設定します。これは、次のコマンドでExadata Storage Serverから取得します

        CellCLI> list cell attributes snmpengineidhex ;

        前述のすべてのステップは、Exadata Database Machine検出ウィザードの一環として表示される「Exadata Storage Server資格証明」リージョンでSNMP V3サブスクリプションが選択されていると、自動的に処理されます。

  3. notificationMethodの値を設定します。
    # cellcli -e "alter cell notificationMethod='snmp,mail'"
    
  4. notificationPolicyの値を設定します。
    # cellcli -e "alter cell notificationPolicy='Critical,Warning,Clear'"
Ciscoイーサネット・スイッチ・ターゲットのSNMPサブスクリプションの設定

Ciscoイーサネット・スイッチをモニターするエージェントがスイッチをポーリングしてスイッチからSNMPアラートを受信できるように、Ciscoイーサネット・スイッチを構成する必要があります。このためには、次のステップを実行します(例のスイッチ名dm01sw-ipを、構成するCiscoイーサネット・スイッチ・ターゲットの名前で置き換えます)。

ノート:

この手順は、スイッチのモニタリングが管理者以外のユーザーで実行されている場合、SIターゲットに対して有効です。Enterprise Managerが管理者ユーザーでスイッチをモニターしている場合、次の手順は検出プロセスの一環として自動的に実行されます。

  1. Ciscoスイッチにログインし、構成モードを開始します。
    # ssh cisco-switch-host -l <admin user>
    User Access Verification Password: 
    dm01sw-ip> enable
    Password:
    dm01sw-ip# configure terminal
    Enter configuration commands, one per line. End with CNTL/Z.
    dm01sw-ip(config)#
    
  2. Ciscoスイッチ・ターゲットをモニタリングするエージェントがスイッチをポーリングできるように、アクセスを有効にします。

    このコマンドの[EMagentIPaddr]は、Enterprise Managerエージェントが実行されているサーバーのIPアドレスです。「Ciscoイーサネット・スイッチのSNMPv3ユーザーの作成」および「Ciscoイーサネット・スイッチのSNMPコミュニティの作成」を参照してください。

  3. モニタリング・エージェントを、SNMPアラートが配信される場所として設定します。Ciscoスイッチのモニタリング・エージェントに指定されているSNMPコミュニティは、Enterprise ManagerのCiscoスイッチ管理の設定で指定した値と一致する必要があります。
    snmp-server host <EM_Agent_IP_Address> version { 1 | 2c | 3 { auth | noauth | priv }} community-string [ udp-port <EMagentRecvltListenPort> ]

    前述のコマンドでは、次のとおりです。

    • EM_Agent_IP_Address: モニタリング・エージェントのIPアドレス
    • version { 1 | 2c | 3 { auth | noauth | priv }}: SNMPバージョンは、SNMPv1、SNMPv2cまたはSNMPv3のいずれかになります。オプションのキーワード{auth | noauth | priv}}は、認証レベルを指定するために使用します。
    • udp-port <EMagentRecvltListenPort>: [EMagentRecvltListenPort]は、emagentまたはSnmpRecvletListenNICプロパティ値のEMD_URLポートです(有効になっている場合)。udp-portの指定はオプションです。
    • community-string: SNMPv1およびSNMPv2cの場合は、パスワードのようなコミュニティ文字列を入力します。SNMPv3の場合は、SNMPv3ユーザー名を入力します。たとえば、SNMPv3の場合は前述のコマンドを次のように変更します。
      snmp-server host <EM_Agent_IP_Address> version {3 { auth | noauth | priv }} SNMPv3-user-name [ udp-port <EMagentRecvltListenPort> ]
  4. 設定を確認し、構成を保存します。
    dm01sw-ip(config)# end
    dm01sw-ip# show running-config
    dm01sw-ip# copy running-config startup-config
電力配分装置(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つの修正をお薦めします。

  1. Enterprise Manager Exadataプラグインを13.4 RU1213.5 RU01またはそれ以降にアップグレードします。

  2. 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. 
----------------------------------------------------------

ターゲットが検出されてもアソシエーションが作成されない

ターゲットは作成されたが、そのターゲットのアソシエーションは作成されていないことが検出ステータスで報告された場合、次のステップを実行して手動でアソシエーションを作成します。

  1. データベース・マシンのホームページから、Exadata Database Machine構成図に手動でターゲットを追加します。これにより、ターゲットはデータベース・マシン・ラックに関連付けられます。

  2. 次の例に示すように、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の管理のトラブルシューティング

「リソース使用率」グラフにデータが表示されない場合は、SQL問合せ「view object」を実行して、どのデータが欠落しているかを調べます。一般的な問題には、次のものがあります。

  • スキーマ・ファイルが正しくロードされていません。

  • クラスタ、データベースおよび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サブスクリプションを構成するには:

  1. Exadata Storage ServerターゲットでSNMP V3ユーザーを作成します。
    • "v3user"というユーザーが必要であると仮定します。このコマンドを使用すると、このユーザーがすでにExadata Storage Serverに存在しているかどうかを確認できます。

      cellcli -e "list cell attributes snmpUser"
    • このユーザーがExadata Storage Serverに存在しない場合は、新しいユーザーを作成します。「コンピュート・ノードおよびStorage ServerのSNMPv3ユーザーの作成」を参照してください。

    ノート:

    Enterprise Managerエージェントは、SHA認証プロトコルに加えて、DESおよびAESプライバシ・プロトコルをサポートしています。
  2. 検出後にExadata Storage ServerのSNMP V3モニタリング資格証明を編集する必要がある場合は、Enterprise Managerにログインして次のようにします。
    • 「設定」「セキュリティ」「モニタリング資格証明」の順に選択します。

    • 「Oracle Exadata Storage Server」タイプを選択し、「モニタリング資格証明の管理」ボタンをクリックします。

    • 「Exadata Storage Server」ターゲットと「SNMP V3モニタリング資格証明」資格証明セットに対応する行を選択して、「資格証明の設定」ボタンをクリックします。

    • 「モニタリング資格証明の入力」フォームに適切な情報を入力して、「保存」をクリックします。

    ノート:

    Enterprise Managerで、Exadata Storage Serverターゲットに、Exadata Storage ServerのSNMP V3ユーザーと一致しているSNMP V3モニタリング資格証明が設定されていることを確認します。