8 Exadataプラグインのトラブルシューティング

この章では、Exadataプラグインのインストール、検出および構成に関するトラブルシューティングのヒントおよび方法について説明します。内容は次のとおりです。

• SSH接続の確立

• 検出のトラブルシューティング

• Exadata Database Machineスキーマ・ファイルのトラブルシューティング

• Exadata Database Machineの管理のトラブルシューティング

• Exadata導出のアソシエーション・ルール

• インフィニバンド・パッチの詳細の欠落

• Oracle Auto Service Request (ASR)の問題

• メトリック収集の問題

• ステータス: 保留中の問題

• 高度なMIBの非互換性

• IPv6環境にデプロイされないモニタリング・エージェント

SSH接続の確立

リリース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接続を設定するには、エージェント・ユーザーとして次の手順を実行します。

1. 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は、エージェント・ユーザーのホーム・ディレクトリです。

2. パブリック・キー(id_dsa.pub)をストレージ・セルの/tmpディレクトリにコピーします。

   $ scp id_dsa.pub root@<cell_ipaddress>:/tmp
   

3. 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"

4. .sshディレクトリとauthorized_keysに正しいファイル権限があることを確認します。

   # chmod 700 ~cellmonitor/.ssh
   # chmod 600 ~cellmonitor/.ssh/authorized_keys

検出のトラブルシューティング

多くの場合、エラー・メッセージそのものにエラーの原因が示されています。OMSおよびエージェントのログでエラー・メッセージを探す(dbmdiscoveryを大/小文字区別なしで検索する)か、「検出」ウィンドウ内でエラー・メッセージを探します。

内容は次のとおりです。

• ハードウェアの可用性

• 検出失敗の診断

• セルが検出されない

• コンピュート・ノードのエラー・メッセージ

• コンピュート・ノードまたはインフィニバンド・スイッチが検出されない

• コンピュート・ノードがEnterprise Managerで管理されない

• 新たに検出されたExadataデータベース・マシンの余分なまたは欠落しているコンポーネント

• インフィニバンド・ネットワーク・パフォーマンス・ページにデータが表示されない

• ILOM、PDU、KVMまたはCiscoスイッチが検出されない

• 選択したターゲット・ページにターゲットが表示されない

• 検出後にターゲットが停止したり、メトリック収集エラーが発生する

• 検出プロセスのハング

ハードウェアの可用性

すべてのハードウェア・コンポーネントが認識されていて、接続可能である必要があります。それ以外の場合は通信障害が発生します。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で管理されない

Enterprise Managerで管理されていないコンピュート・ノードのインスタンスが発生する場合は、次のトラブルシューティング・ステップを確認します。

• エージェントのホスト名がコンピュート・ノードのホスト名と異なる場合は、次のコマンドをrootとして実行して、エージェントのホスト名に一致させます。

  # ibnetdiscover
  

• 検出用に不適切なエージェントが使用されている場合は、検出用のコンピュート・ノード・エージェントを選択します。

• クライアントから管理に(その逆も同じ)コンピュート・ノード名をリセットした場合は、次のコマンドを実行します。

  # /usr/sbin/set_nodedesc.sh
  

• エージェントに短いホスト名が使用されている場合は、完全修飾ホスト名の<hostname.domain>を使用してエージェントを再インストールします。

新たに検出されたExadataデータベース・マシンの余分なまたは欠落しているコンポーネント

余分なコンポーネントが表示される場合、または欠落しているコンポーネントがある場合は、次のトラブルシューティング・ステップを確認します。

• 余分なコンポーネントの場合、Exadata Database Machineメンバーシップでそれを探します。検出されたリストから、余分なコンポーネントを手動で選択解除します。

• 検出に使用した構成図ファイルを確認します。Enterprise Managerで、コンピュート・ノードの最新のxmlファイル(たとえば、databasemachine.xml)を読み取れることを確認します。

• 欠落しているコンポーネントの場合は、構成図ファイルの内容を確認します。

• 新しい構成図ファイルを生成する必要がある場合は、Oracleサポートでサービス・リクエスト(SR)を記入し、詳細を提供します。

インフィニバンド・ネットワーク・パフォーマンス・ページにデータが表示されない

インフィニバンド・ネットワーク・パフォーマンス・ページにデータが表示されない場合は、コンピュート・ノードの/opt/oracle.SupportTools/em/ディレクトリ内のファイルがパブリックから読取り可能になっていることを再度確認します。詳細は、Oracle Bug#13255511を参照してください。

ILOM、PDU、KVMまたはCiscoスイッチが検出されない

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」ターゲット・タイプをクリックします。次に、モニタリング資格証明を設定します。

12c検出時のILOM資格証明検証の失敗

ILOM資格証明の検証の失敗エラー

注意:

次に示す内容は、Enterprise Manager Cloud Controlリリース2プラグイン・アップデート1以降に適用されます。

12cの検出を実行中に、ILOM資格証明の検証が失敗することがあります。次のエラーが発生する可能性があります。

• 認証に失敗しました

  問題: 指定された資格証明が無効です。

  解決策: 有効な資格証明を使用します。

• IPMI V2 / RMCP+セッションを確立できません。

  問題: ILOMサーバーでIPMI V2が有効ではありません。

  解決策: IPMI V2を意図的に無効化し、より安全なTLS1.2プロトコルを使用するようにILOMサーバーが構成されている場合、ILOMサーバーとのセッションを確立するには、IPMIクライアントをアップグレードしてTLS1.2を使用する必要があります。

• LANセッションを確立できません。

  問題: ILOMサーバーでIPMI V1.5が有効でない場合に発生します。

  解決策: ILOMサーバーでIPMI V1.5を有効にします。IPMI V1.5は、TLS1.2とIPMI V2が失敗した後に、3番目の選択肢として通信に使用されます。

検出プロセスのハング

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スキーマ・ファイルのトラブルシューティング

ガイドされた検出の前提条件として、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 Database Machineの管理のトラブルシューティング

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

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

• クラスタ、データベースおよびASMがEnterprise Managerターゲットとして追加されていません。

• データベースまたはセル・ターゲットが停止しているか、メトリック収集エラーを戻します。

• メトリックは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+で問合せを実行して、問合せ内のすべてのデータおよび条件が満たされていることを確認します。

• タイミングの問題がないか調べるデバッグ・ロギングを有効にして、トリガーを確認します。

インフィニバンド・パッチの詳細の欠落

問題: Exadata Database Machineで2つのInfiniBandスイッチを選択した場合、パッチの詳細セクションは空です。1つのパッチの2つのインフィニバンド・スイッチへのインストールは作用しません - インストール済パッチの詳細のみです。

回避策: インフィニバンド・スイッチごとに選択して、パッチの詳細を確認します。

Oracle Auto Service Request (ASR)の問題

• Oracle ASRがExadata Storage Serverで動作しない

• 使用可能なスロットがないというエラー

Oracle ASRがExadata Storage Serverで動作しない

問題: 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のサブスクリプションを再試行します。

1. ILOMコンソールにログインします(例: https://XXXCELL-c.example.com)。
2. 「ILOM管理」をクリックして、「通知」をクリックします。
3. スロットを選択して、サブスクライバを0.0.0.0に設定してクリアします。

ターゲット・ステータスの問題

ターゲットのステータスが誤って「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ターゲット

• データベース・マシン・ターゲットまたは関連コンポーネント

Cellsysターゲット

Cellsysターゲットのステータスがあまりにも長い間「保留中」であると思われる場合は、次を実行します。

• クラスタASM、データベースおよびストレージ・セルの関連付けがあることを確認します。

• 関連付けられているターゲット・データベースのステータスをチェックして修正します。

• 関連付けられているターゲット・ASMクラスタのステータスをチェックして修正します。

• すべてのセル・サーバー・ターゲットの「稼働中」ステータスを確認します。

• 関連付けられていないすべてのcellsysターゲットを削除します。

データベース・マシン・ターゲットまたは関連コンポーネント

Exadata Database Machineターゲットまたは関連コンポーネントのステータスがあまりにも長い間「保留中」である場合は、次を実行します。

• 重複する、または保留中の削除ターゲットを確認します。「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。

• ターゲットの構成を確認します。ターゲットのホームページのメニューから、「ターゲット設定」、「モニタリング構成」の順に選択します。

• エージェントまたはOMSログ内のターゲット名を検索します。

  $ grep <target name> gcagent.log or emoms.log

高度なMIBの非互換性

ExadataのいくつかのX4シリーズの出荷物およびそれ以降のすべてのハードウェア・バージョンでは、Exadata Database Machineには新しいバージョンのファームウェアを実行するアップグレード済のPDUが含まれています。このファームウェアは、高度なManagement Information Base (MIB)と出荷され、Exadata 12.1.xプラグインと互換性がありません。このような場合、元のMIBを使用し、図8-2の説明に従い、PDU設定を変更してください。

1. Enterprise ManagerでILOMを「Oracle Engineered System PDU」としてモニタリングしている場合は、元のMIBを選択します。
2. かわりに高度なMIBを使用する場合は、Oracle System Infrastructure PDUを使用し、Oracle Enterprise Manager Cloud Control 13cを使用するようにExadata Database Machineコンポーネントを変換できます。このバージョンへの変換の詳細は、変換ウィザードを使用した12cターゲットから13cターゲットへの変換を参照してください。

図8-2 元のMIBの選択

IPv6環境にデプロイされないモニタリング・エージェント

問題: IPv6環境で、モニタリング・エージェントがデプロイされません。

原因: IPv6アドレスが/etc/hostsファイルに含まれていない場合、エージェントはデプロイされません。

解決策: コンピュート・ノード(または、仮想Exadataの場合はVM)の/etc/hostsを編集して、OMSホスト名をIPv6アドレスにマップします。

IPv6–SNMPv3サブスクリプションの構成

SNMPv3サブスクリプションを行えるのは「Oracle Exadata Storage Server」ページのみです。

前提条件:

• セルでSNMPv3ユーザーを作成する必要があります。方法については、ステップ1を参照してください。

• Exadata Storage Serverのバージョンは、SNMPv3サブスクリプションをサポートする12.1.2.2以降にする必要があります。

IPv6–SNMPv3サブスクリプションを構成する手順:

1. Exadata Storage ServerターゲットでSNMPv3ユーザーを作成します。

   • "v3user"というユーザーが必要であると仮定します。このコマンドを使用して、このユーザーがすでにセルに存在しているかどうかを確認できます。

     cellcli -e "list cell attributes snmpUser"

   • このユーザーがExadata Storage Serverに存在しない場合:

     ALTER CELL snmpUser=((name='[v3user]', authProtocol='MD5', authPassword='[passwd]', privProtocol='DES', privPassword='[passwd]'))

   注意:

   Enterprise Managerエージェントでは、DESおよびMD5/SHAの組合せがサポートされています。
2. 12cおよび13cで検出プロセスを実行する場合、EMのセル・ターゲットのvモニタリング資格証明が、そのセルのvユーザーと一致していることを確認します。

   注意:

   検出プロセスが開始される前に、SNMP v3ユーザーが作成済であることを確認してください(方法は、ステップ1を参照してください)。
3. 検出後にExadata Storage ServerのSNMP v3モニタリング資格証明を編集する必要がある場合は、EMにログインして次のようにします。

   • 「構成」、「セキュリティ」、「モニタリング資格証明」の順に選択します。

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

   • 「Exadata Storage Server」を選択し、v3資格証明を設定します。

   注意:

   EMのセル・ターゲット上で、そのセルのv3ユーザーと一致するV3モニタリング資格証明が設定されていることを確認します。