2

ストアド プロシージャは、Management Studio では 10 秒で実行できますが、TableAdapter では同じ入力に対して 15 分かかりますか? つまり、各環境で少なくとも 3 回実行しましたが、Management Studio は一貫して約 100 倍高速です。

.net 2.0 と SQL Server 2000 を使用しています

SQL Server Management では、次のように実行しています。

EXEC    [dbo].[uspMovesReportByRouteStep]
    @RouteStep = 12000,
    @RangeBegin = N'12/28/08',
    @RangeEnd = N'1/18/9'

TableAdapter では、 にStoredProcedure CommandTypeanddbo.uspMovesReportByRouteStepを使用していCommandTextます。ASP.NET ページからテーブル アダプターを呼び出していますが、ローカルでも "データをプレビュー" しようとすると 30 秒でタイムアウトします。

ストアド プロシージャを提供するのは現実的ではありません。これは、100 行を超える長さであり、同じデータベースや他のデータベース上の多数の他の UDF やビューに依存しているからです。

他のすべてのストアド プロシージャは、どちらの方法を使用してもほぼ同時に実行されるように見えます。これはどのように可能ですか？

4

1 に答える 1

5

これは、「パラメーターのスニッフィング」と、呼び出しているパラメーターの特定の値に適していないキャッシュされたクエリ プランが原因である可能性が非常に高いです。それはどのように起こりますか？1 セットの値で SP を初めて呼び出すと、クエリ プランが生成され、パラメータ化され、キャッシュされます。SP が別のパラメーター値のセットを使用して再度呼び出されると、別のクエリ プランが生成されますが、キャッシュされたクエリ プランが使用されると、パフォーマンスが低下する可能性があります。

多くの場合、統計が古くなっていることが原因です。推定実行計画と実際の実行計画を比較することで、それが当てはまるかどうかを判断できます。異なる場合は、統計が古くなっている可能性が最も高くなります。

最初に、データベースのインデックスを再構築するか、少なくとも統計を更新してみます (DBA に問い合わせてください)。インデックスを再構築する 1 つの方法 (SQL Server のすべてのバージョンで機能するはずです):

exec sp_msforeachtable "dbcc dbreindex ('?')"

それでも問題が解決しない場合は、ステートメントWITH RECOMPILEをストアド プロシージャの定義に一時的に追加してみてください。問題が解決した場合は、このブログ投稿OPTIMIZE FORで説明されている の使用を検討してください。

于 2009-01-17T00:04:38.150 に答える