8

私はSSMSの多くの2つのコアを使用して10秒で約50000レコードを返すストアドプロシージャを持っています。ストアドプロシージャを使用したSSRSレポートは20分掛かり、8コアサーバーのプロセッサー全体を最大限に活用しました。レポートは比較的単純であった(すなわち、グラフ、計算なし)。私はテンポラリテーブルに50Kの行を書き、レポートは数秒でデータを表示することができたため、レポートは問題には見えませんでした。私は毎回ストアドプロシージャを変更してテストするために多くの異なるアイデアを試しましたが、元のコードを別のウィンドウに保持して元に戻しました。ストアドプロシージャの1つの変更後、元のコードに戻って、レポートとサーバーの使用率は、ストアドプロシージャ単独のパフォーマンスに匹敵する速さで実行を開始しました。今はすべてうまいですが、もう一度起こった場合に起こった原因の最下部に行きたいと思います。何か案は?SSRSパフォーマンスミステリー

+0

インデックス:

は、ここでは、ほぼ同一の質問を参照してください?古い実行計画ですか?統計は更新されましたか?あなたはSqlProfilerログを持っていましたか?それは将来的に役立ちます。 – rene

+0

PDFとしてレンダリングまたはレンダリングするだけですか? – SQLMason

+0

Dan - ウェブに標準レポートをレンダリングするだけです。 Rene - トラブルシューティング中にSqlProfilerを実行しませんでした。ローカルクエリで実行しましたが、SSRS DB呼び出しを記録するために必要なことは何ですか?私はSSRS実行ログも掘り下げませんでしたが、他のトラブルシューティングがうまくいかなかった場合は考慮していました。どのように古い実行計画を検出できますか? – user101654

答えて

0

私は通常、SSRSで呼び出されたときに同じSPを実行するときに、ストアドプロシージャのSQLプロファイラトレースから始めます。 SQL Serverは、クエリのソースに関係なく、最適または少なくとも一貫性のあるプランを実行する必要があるとは思われますが、実行プランを含めてください。

私は、SSRSの同じ動作を見たことはありませんでしたが、ビジネスオブジェクトがストアドプロシージャを何度も実行して、何らかの理由で恐ろしいパフォーマンスになるケースがありました。しかし、どこかで始まるかもしれません。ハングアップしているデータベースレイヤーか、SQL Serverが10秒後にデータを戻して、どこかで窒息するSSRSサービスである場合は、実行開始/終了時刻も表示されます。

0

高速SSRSレポートの主な解決策は、キャッシュレポートです。 1人がこれを実行すると(例えば、私が午前7時30分にキャッシュをプリロードする)、またはヒットしたレポートをキャッシュすると、はロード速度が大幅に向上します。

また、問題を解決するためにSSRSアプリケーションドメインを毎月再起動することがあります。

は、私が毎日かつ専門的これを行うと、あなたが行う場合は、単にSSRS

SSRS でキャッシュhttp://msdn.microsoft.com/en-us/library/ms155927.aspx

キャッシュを事前ロード http://msdn.microsoft.com/en-us/library/ms155876.aspx

に詩的なワックスがけておりませんのでご注意ください最初のレポートが長時間かかるのではなく、データが静的なもの、つまり日常の総勘定元帳などで、データが比較的静的であることを意味します。キャッシュ寿命を延ばす

最後に、あなたはまた、代わりに彼らがより簡単に、より体系的かもしれ時間Excelレポートのポイントを送信します電子メールサブスクリプションを介してこれらのレポートを受信するビジネスマネージャを選択することができます。

また、SSRSのパラメータを使用すると、ユーザーによる解析や高速なクエリが可能になります。パラメータ化するフィルタ列のIN(@SSN)型のクエリビルダでは、BIDS GUIの左上のデータソースのすぐ上のパラメータフォルダに作成されます。 [SSRSでデータソースセクションが表示されない場合は、Ctrl + Alt + Dを押します。テーブル上のPerformance Issuses with SSRS