2

ストアド プロシージャから返されたデータをレンダリングするレポートがあります。プロファイラーを使用すると、レポート サービスからストアド プロシージャへの呼び出しをキャッチできます。

レポートがタイムアウトしたことを示すレポートは失敗しますが、SSMS からストアド プロシージャを実行でき、5 ～ 6 秒でデータが返されます。

テスト実行の例では、レンダリングのために 2 行のみがレポートに返されますが、ストアド プロシージャ内では、レポート サービスに返された結果を照合するために、数千または数百万のレコードが処理されている可能性があります。

ストアド プロシージャをさらに最適化できることはわかっていますが、SSMS からの実行に数秒しかかからないように見えるのに、SSRS がタイムアウトする理由がわかりません。

また、別の問題が浮上しました。ストアド プロシージャを再作成すると、レポートは再び完全に正常に表示されるようになります。それは問題ありませんが、しばらくすると、レポートが再びタイムアウトし始めます。

タイムアウトの戻りは、レポートが実行されているメイン テーブルに追加される新しいデータに関連しているようです。私がテストした例では、100 の新しいレコードが挿入されるだけで、レポートが台無しになりました。

より正確には、根本原因であるレポートではないと思います。SSRS から実行したときにタイムアウトを引き起こしているのはストアド プロシージャです。

再びタイムアウトになったら、これまでに行った最善の修正は、ストアド プロシージャを再作成することです。これは理想的な解決策ではないようです。

また、問題は本番環境でのみ発生しているようです。私たちのテストおよび開発プラットフォームでは、同じ問題が発生していないようです。ただし、開発とテストには、本番と同じ量のレコードはありません。

4

4 に答える 4

2

あなたが説明したように、この問題は、ストアド プロシージャの一部の実行計画のバリエーションに起因しているようです。使用されているテーブルで保持されている統計と、新しい行の追加がそれらにどのように影響するかを調べます。

列の範囲の最後に多くの行を追加している場合 (autonumbers またはタイムスタンプを追加することを考えてください)、その列のヒストグラムは急速に古くなります。UPDATE STATISTICS ステートメントを実行することにより、T-SQL から即時更新を強制できます。

于 2008-10-25T22:10:37.877 に答える
2

また、SPROC の実行に数秒かかるにもかかわらず、SSRS が単にタイムアウトするというこの問題も発生しました。

私自身の経験から、この問題を克服するにはいくつかの方法があることがわかりました。

  1. パラメータ盗聴です！ストアド プロシージャが SSRS から実行されると、パラメーターを「盗聴」して、SPROC がそれらをどのように使用しているかを確認します。その後、SQL Server はその調査結果に基づいて実行計画を作成します。SPROC を初めて実行するときはこれで問題ありませんが、レポートを実行するたびにこれを行うのは望ましくありません。そのため、SPROC の先頭で新しい変数セットを宣言します。これは、クエリで渡されたパラメーターを格納し、クエリ全体でこれらの新しいパラメーターを使用するだけです。

例：

CREATE PROCEDURE [dbo].[usp_REPORT_ITD001]
@StartDate DATETIME,
@EndDate DATETIME,
@ReportTab INT
AS

-- Deter parameter sniffing
DECLARE @snf_StartDate DATETIME = @StartDate
DECLARE @snf_EndDate DATETIME = @EndDate
DECLARE @snf_ReportTab INT = @ReportTab

...これは、SPORC が SSRS によって実行されるときに、クエリ全体ではなく、渡されたパラメーターのクエリの最初の数行のみを調べていることを意味します。これにより、SSRS での実行時間が大幅に短縮されます。

  1. SPROC に変数として宣言された一時テーブルが多数ある場合 ( DECLARE @MyTable AS TABLE)、レポートを生成するときに、これらはサーバーで (メモリに関して) 非常に集中的です。代わりにハッシュ一時テーブル ( SELECT MyCol1, MyCol2 INTO #MyTable) を使用することで、SQL Server は一時テーブルをシステム メモリではなくサーバー上の TempDB に保存し、レポート生成の負荷を軽減します。
于 2011-01-13T11:05:47.340 に答える
1

ストアド プロシージャの CREATE ステートメントに WITH RECOMPILE オプションを追加すると役立つ場合があります。これは、元の実行計画が最適ではない方法でプロシージャによって調査されるレコードの数が変化する状況で効果的です。

于 2008-10-28T13:06:14.027 に答える
0

基本的に、これまでに行ったことは、sproc をもう少し最適化することだけで、少なくとも一時的に問題を解決しているようです。

SSMS と SSRS から sproc を呼び出すことの違いを知りたいです。

于 2008-10-28T19:24:29.210 に答える