SSRSで高速クエリの実行が遅い
ストアドプロシージャを呼び出すSSRSレポートがあります。クエリウィンドウからストアドプロシージャを直接実行すると、2秒以内に戻ります。ただし、2005 SSRSレポートから同じクエリを実行すると、完了するまでに最大5分かかります。これは最初の実行時に発生するだけでなく、毎回発生します。また、他の環境でもこの同じ問題は発生しません。
この特定の環境でSSRSレポートが非常に遅くなる理由についてのアイデアはありますか？
ここに提示された提案をありがとう。解決策を見つけましたが、パラメーターに関連していることが判明しました。 SQL Serverは、「パラメータースニッフィング」が原因でSSRSレポートから実行されると、複雑な実行計画を作成していました。回避策は、ストアドプロシージャ内で変数を宣言し、受信パラメーターを変数に割り当てることでした。次に、クエリはパラメータではなく変数を使用しました。これにより、SQL Server Managerから呼び出された場合でもSSRSレポートから呼び出された場合でも、クエリは一貫して実行されました。
これをprocの最後に追加します：option(recompile)
これにより、レポートはストアドプロシージャとほぼ同じ速度で実行されます。
非ストアドプロシージャクエリでも同じ問題が発生したことを追加します。単なる選択ステートメントです。それを修正するために、データセットSQLステートメント内で変数を宣言し、SSRSパラメーターと同じ値に設定しました。
なんて面倒な回避策でしょう！それでも、答えに私を近づけてくれてありがとう！
私は同じ問題を抱えていました、ここに問題の私の説明があります
「2200行を生成し、ほぼ2秒で実行されるストアプロシージャを作成しましたが、SSRS 2008からストアプロシージャを呼び出してレポートを実行した後、実際には実行されず、最終的にBIDS（Business Intelligence Development Studio）を強制終了する必要がありますタスクマネージャから」。
試したこと：reportuserログインからSPを実行しようとしましたが、SPはそのユーザーに対しても正常に実行されていました。プロファイラーをチェックしましたが、何もうまくいきませんでした。
解決：
実際には、問題は、SPが結果を生成しているが、SSRSエンジンがこれらの多くの行を読み取って戻すのに時間がかかっていることです。したがって、SPそしてレポートを実行しました..これは奇跡が起こり、私の問題が解決したときです。
ストアドプロシージャがリンクサーバーまたはopenqueryを使用する場合、それらは単独で迅速に実行できますが、SSRSでのレンダリングに時間がかかります。一般的な提案：
- リンクサーバーを使用してデータを取得する代わりに、別のデータソースを使用して、データが格納されているサーバーから直接データを取得します。
- レポートクエリをシンプルに保ちながら、レポートを実行する前に、リモートサーバーからローカルテーブルにデータをロードします。
- テーブル変数を使用して、最初にリモートサーバーからデータを取得してから、リンクサーバーとの結合を直接返すのではなく、ローカルテーブルと結合します。
質問に回答したことがわかりました。誰かが同じ問題を抱えている場合に備えて、これを追加しています。
Tablixのプロパティで[各ページのヘッダー列を繰り返す]の選択を解除しました。
同じシナリオが発生していました。非常に基本的なレポート、SP（これは1つのパラメーターのみを取ります）は、10,000個のレコードを戻すのに5秒かかりましたが、レポートの実行には6分かかりましたプロファイラとRS ExecutionLogStorageテーブルによると、レポートはクエリにすべての時間を費やしていました。ブライアンS.のコメントが私をソリューションに導きました。SPのASステートメントの前に単にWITH RECOMPILEを追加しました。レポート時間は、SP実行時間とほぼ一致します。
ストアドプロシージャがManagement Studioから迅速に実行されるが、SSRSから非常に低速で実行されるという同様の問題に遭遇しました。長い闘争の後、ストアドプロシージャを物理的に削除して再作成することでこの問題を解決しました。その背後にあるロジックは定かではありませんが、ストアドプロシージャで使用されるテーブル構造の変更が原因であると思われます。
32000行を取得するレポートで、レポートhtml出力のトラブルが発生しました。クエリは高速で実行されましたが、Webブラウザーへの出力は非常に低速でした。私の場合、ユーザーが最初のページを表示してExcelファイルを生成できるようにするには、「インタラクティブページング」をアクティブにする必要がありました。このソリューションの長所は、最初のページが高速で表示され、ユーザーがExcelまたはPDFへのエクスポートを生成できることです。欠点は、ユーザーが現在のページのみをスクロールできることです。ユーザーがより多くのコンテンツを表示する場合、グリッドの上にあるナビゲーションボタンを使用する必要があります。私の場合、Excelへのエクスポートがより重要だったため、ユーザーはこの動作を受け入れました。
「インタラクティブページング」を有効にするには、レポートペインの空き領域をクリックし、プロパティペインのレポートレベルでプロパティ「InteractiveSize」\「Height」を変更する必要があります。このプロパティを0以外に設定します。私の場合は8.5インチに設定します。また、Tablixレベルで[可能な場合は1ページにまとめる]プロパティのチェックを外してください（Tablixを右クリックし、[Tablixプロパティ]、[一般]\[改ページオプション]）。
同じ問題に直面しました。私にとっては、オプションを解くだけでした：
Tablixのプロパティ=>改ページオプション=>可能な場合は1ページにまとめる
SSRSレポートの。多くのページを作成するのではなく、すべてのレコードを同じページに配置しようとしていました。
私の場合、SSMSを切断して接続するだけでした。クエリのプロファイルを作成したところ、クエリ自体が2秒未満で実行されていても、実行時間は1分でした。接続を再起動して再度実行しましたが、今回は継続時間が正しい実行時間を示しました。
パラメータスニッフィングの問題は別として、SSRSは一般にクライアント側の処理で（私の場合は）Crystalレポートよりも遅いことがわかりました。 SSRSエンジンは、ローカルでフィルター処理または集計する行が多数ある場合、機能しているようには見えません。確かに、これらは頻繁に対処できる結果セットの設計上の問題ですが（詳細がドリルダウンに必要な場合は常にではありません）、より多くの...成熟した...レポートエンジンがより寛容です。
これを解決するには、下から[＆TotalPages]組み込みフィールドを削除しました。数分から1秒未満に減少する時間。
私が判断できなかった奇妙なことは、合計ページの計算に影響を与えていたことです。
SSRS 2012を使用していました。
SSRSテーブルで「グループ化」を使用していますか？
フィールドでグループ化された3つのレポートがあり、クエリが軽いにもかかわらずレポートの実行が非常に遅く、検索フィールドで値をダイヤルすることさえできないことがわかりました。
グループを削除してから、レポートが数秒で表示され、すべてが瞬時に機能するようになりました。
同じ問題があり、共有データセットにデフォルトのパラメーターを指定し、レポートサーバーでそのデータセットを更新することで修正しました。
実際のレポートを実行せずにできることはいくつかあります。レポートサービスの[データ]タブからsprocを実行するだけです。まだ時間がかかりますか？別のオプションは、SQLプロファイラを使用して、データベースシステムに出入りするものを判別することです。
それをテストするためにできるもう1つのことは、パラメーターなしで単純なレポートを再作成することです。レポートを実行して、違いが生じるかどうかを確認します。 RSレポートが壊れているか、形式が正しくないためにレンダリングが非常に遅くなる可能性があります。
私たちの場合、コードは必要ありませんでした。
ヘルプデスクからのメモ：「インターネット設定をクリアすると、この問題は解決します。」
たぶんそれは「キャッシュのクリア」を意味します。