0

Sql Server 2008 R2 の SSIS パッケージで非常に奇妙なパフォーマンスの問題が発生しました。事実: 最近、Sql Server 2005 (Windows Server 2003 R2 32 ビット) から Sql Server 2008 R2 (Windows Server 2008 R2 64 ビット) に移行しました。

1 つの SSIS パッケージのパフォーマンスの問題を除いて、すべて問題ないようです。PC から実行すると、数分 (4/5 前後) で正常に実行され、SqlServer Management Studio を介して Integrations Services に接続し、そこからパッケージを開始すると、同じことが起こるようです。

ただし、Sql Server Agent から実行すると、実行時間が 5 分から 1 時間以上になります... 古いサーバーではそのような問題はありませんでした! また、パッケージを 32 ビット モードで実行しようとしましたが、一部の実行では高速に見えますが、かなりランダムです... ただし、Sql Server 2005 での優れたパフォーマンスには決して達しません。

手がかりがありません...最初は、Sql Serverに最大メモリ制限を与えておらず、他のパッケージを同時に実行するのに問題があったため、メモリの問題だと思いました。そのため、サーバーが使用するRAMを拡張しました（は VMWare 上で実行されます)、マシンには 8 GB の RAM があり、Sql Server の最大サーバー メモリは 4 GB です。他のパッケージは現在クラッシュしていませんが、これはまだランダムな実行時間を与えています...

推測はありますか？

日ごとの実行時間の表に従う

Start Time          Execution Time
12/17/2010 06:15 00:49:43
12/16/2010 17:54 01:12:26
12/16/2010 17:18 00:06:29
12/16/2010 16:53 00:05:23
12/16/2010 16:10 00:24:23
12/16/2010 06:15 00:19:26
12/15/2010 06:15 00:07:19
12/14/2010 06:15 00:11:26
12/13/2010 06:15 00:17:30
12/12/2010 06:15 00:44:59
12/11/2010 06:15 00:11:59
12/10/2010 06:15 00:34:19
4

2 に答える 2

1

これに対する解決策を見つけました。

この問題は、サーバーでのバッファ作成に関するメモリの問題でした。

デフォルトのバッファサイズ（MBと行数の両方）を増やして部分的に解決し、使用したすべてのソートおよびマージコンポーネントを削除して、Transform Cacheコンポーネントで構築されたカスタムキャッシュのルックアップに置き換えて完全に解決しました。

Windows Server 2003 を使用した Sql Server 2005 および開発中の割り当てが正常に機能する理由はまだわかりませんが、パッケージは修正されました!

于 2011-02-17T16:04:36.923 に答える
1

他に何が実行されていますか？このパッケージの実行がスケジュールされているときに、クエリを実行しているユーザー (テーブルをロックする可能性があるユーザー) や、関連するテーブルにアクセスする他のパッケージはありますか? 実行すると、ブロッキングロックやそのようなものが表示されますか?

本番環境のバッチ実行環境は、開発環境ほど良くなく、静かで、制御されていない可能性が高いと思います。

データ ロックを保持しているユーザーまたは関連するパッケージによって、実行時間のランダムな分布が説明される場合があります。

于 2010-12-17T09:42:25.500 に答える