2009-03-11 19 views
0

非常に多数のSSISジョブが毎晩/翌朝に連続して実行されるようスケジュールされています。これらのジョブは、本番システムの大量のデータを読み込んで更新します。最近、さまざまな時代に異なるジョブでエラーメッセージが受信され始めています。SSIS SQLネイティブクライアントエラー - 原因を診断できません。

 
    Code: 0xC0202009  
    Source: [Job Name] Connection manager "[Connection.Manager.Name]" 
    Description: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005. 
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure". 
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Named Pipes Provider: No process is on the other end of the pipe. ". 
End Error 
Error: 2009-03-10 05:19:51.09 
    Code: 0xC00291EC  Source: Update record status Execute SQL Task 
    Description: Failed to acquire connection "[Connection.Manager.Name]". Connection may not be configured correctly or you may not have the right permissions on this connect... The package execution fa... The step failed. 

接続が確実に適切に構成されており、我々は適切な権限を持つユーザーとして、それを実行している:これまでのところ、一貫して再現することは不可能でした。 1年以上にわたって、これらの仕事は完璧に実行されていました。 Googleの検索では、可能性のある接続の問題からデータの完全性の問題に至るまでのあらゆる結果に見える結果が得られます。これをデータソース側から接続問題として、SQL Serverデータベースとサーバーボックスからイベントログを調べて試してみました。何も整列していないようです。ここに私たちのセットアップは次のとおりです。

  • 私たちは、私たちはを収容し、その上にちょうどSQL Serverデータベースと専用Server 2003のボックスを持っているだけで住宅や実行中のSSISジョブ
  • に専用のSQL Server 2005で1つのServer 2003のボックスを持っていますまた、データとは、サービスのレポートのレポートアップ機能
  • 私たちの仕事のほとんどは、レコードの我々のシステムからデータを取得し、

が持つレポーティングやデータ操作のためのSQL ServerにそれをダウンさせるためにSybaseのDBにODBC経由で接続似たような人でこの例外を越えて走る者ネー?ここでも、SQL Serverデータベースのトラブルシューティングを試みましたが、Sybaseとの接続は問題ありませんでした。

答えて

1

OLE DBがあなたに横たわっている場合は、これはまったく問題になる可能性があります。そうでなければ、パイプのもう一方の端にプロセスがないかもしれません。多分他のプロセスが亡くなったかどうかを調べるには、イベントログなどを調べる必要があります。

何年も前から本番環境で稼動していたプロセスでも、何か他のものが変更された場合、その動作が変更される可能性があります。たとえば、バックアップやその他の自動化されたジョブが長くなり、SSISパッケージの既存のスケジュールと衝突する可能性があります。このようなことは、開いている接続を強制的に閉じて、「パイプのもう一方の端にプロセスがない」原因となる可能性があります。

+0

両方のボックスのローカルイベントログと、両方のボックスのSQL Serverイベントログを確認しました。 SSISログにはどこにでも目立つものはありませんが、上記のエラーメッセージが表示されます。だから私たちはこの問題にとても戸惑っているのです。 –

+0

エラーがタイムスロットやジョブ間でスキップしても、それは役に立ちません。ある夜、私たちは何の誤りもありません。それ以外の夜は何度も繰り返されます。 –

+0

一方、死に至るプロセス以外の何かがそのエラーの原因になるかどうかを知るためには、MSのサポートインシデントに値するかもしれません。次に、プロセス終了の監査をオンにし、相関があるかどうかを確認します。最後の手段:テクネット上のsysinternalsからprocmon。大きな出力、素晴らしいディテール。 –

2

私たちの場合は、リソースの競合でした。デッドロックは、他のジョブからのテーブルレベルのロックのために発生していました。ネイティブクライアントのエラーでは、最初に何が間違っていたかをわかりやすく説明できませんでした。 SQL Server ProfilerをDB上で実行し、デッドロックエラーをフィルタリングする必要がありました。 Thisの記事は、私たちを正しい方向に向けるために多くの助けとなりました。

希望に役立ちます!