イベント 31551 Operations Manager が、データ ウェアハウス データベースに接続しようとしています。

現象

System Center Operations Manager 管理サーバーは、接続またはデータ ウェアハウス データベースをホストする SQL クラスターと通信できません。このような状況では、さまざまなワークフローの名前は、次のような説明と、Operations Manager ログにイベント ID 31551 が記録されます。

Operations Manager のログ名:
ソース: 正常性サービス モジュール
日付:
イベント ID: 31551
データ ウェアハウスのタスクのカテゴリ:
レベル: エラー
キーワード: クラシック
ユーザー: N/A
コンピューター: サーバーです。Contoso.com
説明:
データ ウェアハウスにデータを保存できませんでした。操作は再試行されます。
例外 'SqlException': SQL Server への接続を確立中にネットワーク関連またはインスタンス固有のエラーが発生しました。サーバーが見つからないか、アクセスできませんでした。インスタンス名が正しいことと、SQL Server がリモート接続を許可するように構成されていることを確認します。(プロバイダー: SQL ネットワーク インターフェイス、エラー: 26 - エラーを検索するサーバー/インスタンスの指定)

1 つまたは複数のワークフローは、これによって影響を受けた。

ワークフロー名: Microsoft.SystemCenter.DataWarehouse.CollectEventData
インスタンス名: サーバーです。Contoso.com
インスタンス ID: {8A13A832-776E-096E-32E7-DC479FCD6DBC}
管理グループ: SupportGroup

原因

ここは、次の文字列にする必要があります。

エラー: 26 - エラーを検索するサーバー/インスタンスの指定

このエラーは多くの場合、サーバー上のリモート接続が有効になっていないために発生すると考えます。ただし、クライアントが SQL ブラウザーから SSRP 応答の UDP パケットを受信できない場合、このエラーは生成実際にします。この現象は、管理サーバーとオペレーション マネージャーのデータ ウェアハウスをホストする SQL のクラスターの間で UDP ポートの通信がブロックされているために通常発生します。

名前付きインスタンスの SQL Server に接続しようとするとにのみこのエラーが発生することに注意します。既定のインスタンスに接続するときは発生する必要があります。(たとえば、エラーのため、指定したサーバーまたはインスタンスを検索する)、この段階では、接続の試行が失敗した場合でも、これは (例では、既定の TCP ポート 1433 を使用して、名前付きパイプというようにデフォルトのパイプ名) の既定値を使用して接続しようとして続行します。以降の障害ですが、このエラー メッセージではないため他のエラー メッセージが生成されます。

解決策

この問題を解決するには、UDP ポートの通信が管理サーバーと SQL のクラスターの間での失敗の原因となって何らかの問題を解決する必要があります。ほとんどの場合は比較的簡単に次の手順で問題を特定するのには。
  1. サーバー名が正しいことを確認 (たとえば、確認名にエラーがない)。
  2. インスタンス名が正しいことと、インスタンスが実際には、ターゲット コンピューター上に存在することを確認してください。一部のアプリケーションが変換することに注意してください。 に \ です。明確でないアプリケーションは場合、は、接続文字列に"server\\instance"と"server\instance"の両方をしてみてください。
  3. サーバーが到達可能であることを確認します。DNS が正しく解決され、サーバーを ping できることを確認ください。
  4. SQL ブラウザー サービスがサーバー上で実行されていることを確認します。
  5. サーバーでファイアウォールが有効の場合 sqlbrowser.exe または UDP ポート 1434 の例外があることを確認します。

PortQry ユーティリティは、手順 4 と 5 をテストするのには次のサポート技術情報資料からダウンロードできます。

832919の新機能と PortQry version 2.0 の機能

PortQry を作成したら、次のコマンドを実行します。

portqry.exe-n serverName -p UDP-e 1434

このコマンドに情報を返す、ターゲット インスタンスを含んでいる場合は、手順 4 と 5 のシナリオは除外できます。SQL ブラウザーが実行して、ファイアウォールは、SQL ブラウザーの UDP パケットをブロックしていないことがあることを意味します。

後、次の手順を完了したら、エラーは発生しません。管理サーバーを SQL サーバーに接続できないことがありますが、別のエラー メッセージがトリガーされた t をこの時点でする必要がある場合は。管理サーバーが接続にも失敗した場合は、"tcp:server\instance"または"np:server\instance、"と"server\instance"を置き換えるし、し、[TCP] または [NP プロトコルで成功するかどうかを参照してください。

詳細

次の組み合わせによっては、この問題が発生します。
  • Windows クラスターの詳細について
  • SQL Server が名前付きインスタンスを検出する方法
名前付きインスタンスの SQL Server に接続する場合、クライアント コンポーネントは、サーバーとそのパラメーターを検出するには SQL ブラウザーに依存します。検出プロセスは、次のように実行されます。

  • クライアントは、SQL ブラウザーをターゲット コンピューターの UDP パケットを送信します。名前付きインスタンスは、Windows クラスターでは、クラスター ip アドレス、または SQL Server を実行している仮想マシンに対応する IP アドレスをより具体的には、パケットが送信されます。ただし、SQL ブラウザーがクラスター対応ではないし、任意の IP 上でリッスンします。
  • SQL ブラウザーでは、UDP 応答パケットを受信すると、応答 UDP パケットをクライアントに送信します。宛先 IP アドレスには、クライアントの IP アドレスが、送信元 IP アドレスが変更されます。仮想 SQL Server の IP アドレスの代わりに物理コンピューターのネットワーク アダプターの IP アドレスになっています。
  • 応答の UDP パケットの発信元 IP アドレスは、ルーティング テーブルに基づいた、Windows オペレーティング システムによって決定されます。仮想 SQL Server の IP アドレスと物理ネットワーク アダプターに関連付けられている IP アドレスの両方は、同じサブネットでは、通常と同じルートに属しているためため、物理的な IP アドレスが選択されます。セキュリティの設定によって、クライアントとサーバー コンピューターでこの応答の UDP パケット可能性があります削除するか、サードパーティ製のファイアウォールまたは IPsec でピアの IP アドレスが変更されたため。Windows ファイアウォールがパケットを破棄しないことに注意してください。
  • クライアントが Windows Vista ベースのコンピューターの場合は、IPsec がパケットを破棄とクライアントの IPsec ポリシーが有効になっている場合、クライアントとサーバー間の信頼関係接続を確立できない場合に注意します。この問題を回避するのには手動で接続文字列で TCP ポートまたはパイプ名を指定します。
プロパティ

文書番号:3084547 - 最終更新日: 2017/02/01 - リビジョン: 1

Microsoft System Center 2012 R2 Operations Manager, Microsoft System Center 2012 Operations Manager Service Pack 1, Microsoft System Center 2012 Operations Manager, Microsoft System Center Operations Manager 2007 R2

フィードバック