2

月に12,000回実行されるSQL2008R2レポートがあります。実行ごとに平均60〜90秒です。

私はSQLを12年間使用していますが、2〜3週間前にこの仕事を始めたばかりで、これらのSSRSパフォーマンスの問題のいくつかに頭を悩ませようとしています。言うまでもなく、このレポートを支援するために、すべてのインデックスを再作成しています。

これが私の実行ログの写真/ダンプです：

SELECT ReportPath, TimeDataRetrieval, TimeProcessing, TimeRendering, Source, [RowCount] 
FROM ReportServer.dbo.ExecutionLog2
WHERE UserName = '_________' AND ReportAction = 'Render'
ORDER BY timeStart desc

http://accessadp.com/?attachment_id=562

ReportPath  TimeDataRetrieval   TimeProcessing  TimeRendering   Source  RowCount

/CubeReports/Freight Allocation 2954    4402    2039    Live    2348
/RS Reports/Freight Allocation  39954   4087    2380    Live    2348
/RS Reports/Freight Allocation  37718   3948    1888    Live    2348
/RS Reports/Freight Allocation  39534   4317    1937    Live    2348
/CubeReports/Freight Allocation 3257    4206    2422    Live    2348
/RS Reports/Freight Allocation            37517 4164    2402    Live    2348
/RS Reports/Freight Allocation  36127   4151    1986    Live    2348
/RS Reports/Freight Allocation  36415   39888   2569    Live    19048
/RS Reports/Freight Allocation  37544   41644   2071    Live    19048
/RS Reports/Freight Allocation  37970   41003   2187    Live    19048
/RS Reports/Freight Allocation  38057   48085   1885    Live    19048
/CubeReports/Freight Allocation 3030    4558    2056    Live    2348
/CubeReports/Freight Allocation 3534    5232    2422    Live    2348

'RowCount'の違いが何であるかを私は知っていると私は信じていることに注意してください。データセットを実行しているサブレポートがあり（これは重要ではありませんでした）、それを削除しました。

これがパフォーマンスの向上の理由だと思いました。しかし、サブレポートに他のデータセットがないことをダブルチェックおよびトリプルチェックしました（これは行数の減少で参照されます）。残念ながら、それは処理時間の短縮にはつながりませんでした。

「RSReports」からレポートをダウンロードし、「CubeReports」に展開しました。このバージョンのレポートでは、他に何も変更していません。

同じパラメータで実行します。レポート「CubeReports」のコピーは文字通り10倍高速に実行されます。

なぜこれが起こっているのか理解できませんか？私は本当に解決策を見つけて、それを本番環境に移行する必要があります。

スナップショット、履歴、実行キャッシュを確認しました。いずれもオンになっておらず、両方のレポートのデフォルト設定のように見えます。他のすべてのオプションを確認しましたが、そうなるものが見つかりません。これを説明してください。

私が見る唯一の3つのオプション：

  1. Report Builder 3.0は、BIDのように、「レポートのコンパイル」ではありません。
  2. テストを実行しているときに3〜4人がプライマリレポートを同時に実行していると、この問題が発生します。（300人の従業員がいます。人々は毎日これを実行しているため、他の場所でテストすることはできません）。
  3. レポートを削除して再デプロイし、これによりレポートの実行速度が10倍になることを確認しました。

残念ながら、私は一貫して10倍の速度向上を再現することができました。同じパラメーターを使用して、それぞれ約10回実行し、同じ結果を得ました。SSRSサーバーは1つだけであり、データベースサーバーは1つであることに注意してください。同じsproc、同じパラメータ。

このレポートの本番コピーでは、パフォーマンスが10倍低下します。新しいフォルダにコピーすると、パフォーマンスが10倍向上します。

プライマリERPデータベースは最大100GB、4コア、16GBのRAMのみです。SSRSサーバーはVM上にあり、2コア、8GBのRAMのみです。

SSRSサーバー上に存在する追加のデータベースが1つあります。これは実際にはかなり大きなデータベースですが、大量のアクティビティではありません。もう1つのデータベース（Bartender）は、9GBのデータ/3GBのログのみです。

4

3 に答える 3

0

最近、同様のパフォーマンスの問題が発生しました。SQL Server Profilerを使用して、実行中のまったく同じクエリまで追跡しました。他のクエリの約1000倍の読み取りが発生する場合があります。違いは、クエリがSQLとして呼び出されたか、RPCを介して呼び出されたかにあるように見えました。

これをさらに掘り下げて、いくつかの試行錯誤によって、私の場合の主な違いは、のオプションがARITHABORT接続またはユーザーごとに異なるように設定されていることであることがわかりました。

残念ながら、私の場合、どちらの設定が速いかは覚えていません。失敗したクエリは取得されませんでしたが、このオプションの状態により、さまざまな実行プランが使用されました。ステートメントを配置するSET ARITHABORT ONかSET ARITHABORT OFF、クエリの先頭に配置すると、すべてが一致します。ARITHIGNOREとANSI_WARNINGSは似たような設定なので、それらも見ることができます。

于 2012-10-17T18:47:59.817 に答える
0

Credentials used to run this report are not stored実行速度が速いレポートはと表示され、実行速度が遅いレポートは と表示されることを発見しましたDefault report parameter values are missing。戻って、パラメーターのデフォルトを再確認します。

デフォルトのパラメータに矛盾があります。おそらく、レポートを破棄して再展開することになるでしょう。

于 2012-10-10T21:15:23.087 に答える
0

2 つの単語のフォルダー名に問題がある可能性があります。名前にスペースが含まれる別のフォルダーで試して、そこで確認してください。

ちょうど私の 2 セント...しかし、私は神聖な「i」がグローバルに宣言されるのを見るために生きました。

于 2012-10-16T19:45:08.793 に答える