3

SSRS レポートを実行しようとしています。これは単純なレポートで、約 80K のレコードを持つテーブルからデータをレンダリングするだけです。

レポートでは集計やデータ処理は行われません。19 のレポート パラメータとともに約 50 の列があります。これらの 50 列をレポートに表示するだけです (ピボットなし)。

通常、開発サーバーでこのレポートをレンダリングするのに約 5 分かかります (オフピーク時)。私たちの実稼働サーバーでも同じことが言えますが、ユーザーは「メモリ不足」の例外を頻繁に取得しており、レポート パラメーターの条件も使用されていません (これがユーザーからの苦情です)。

レンダリングに時間がかかりますが、問題なく基準をローカルでフィルタリングできます。

  1. レポートが単純であるにもかかわらず、レポートの表示に時間がかかるのはなぜですか?

  2. VS 2008 で F5 キーを押すとレポートは正常に実行されますが、[プレビュー] タブをクリックするとメモリ不足の例外が発生することがあります。

  3. 一部の列の名前には「#」文字が含まれています。レポートにそのような列を含めると、「メモリ不足の例外」がスローされます (特にプレビュー モードで)。これには真実があります: SSRS は「#」を含む列名が好きではありませんか? たとえば、私の列名は「KLN#」でした。

  4. テーブルに非クラスター化インデックスを作成しましたが、あまり役に立ちませんでした。

  5. レポートをプレビュー モードで実行する場合と、VS 2008 で F5 キーを押す場合の違いは何ですか? F5連打時は5分かかっても平気なのですが、プレビューモードが問題。

(単純なレポートであるため) 再設計の余地はあまりなく、おそらくレポート パラメータを削除するしかありません。

任意の提案をいただければ幸いです。

4

4 に答える 4

3

既に投稿された回答に加えて、レポート デザイナーまたはレポート マネージャーでのプレビューの問題に関して、別の解決策があります。最初のレポート ページでデータが多すぎないようにしてください。

これは、少量のレコードに改ページすることによって、つまり改ページを含むカスタム グループによって、または場合によっては自動的に (done_merson の回答を参照)、または単純なカバー ページを追加することによって行うことができます。これらのソリューションは、開発段階で、レポート結果をとにかく Excel または PDF にレンダリングする予定がある場合に特に役立ちます。

メモリ不足の例外を伴う同様のケースがあり、単純なレポートと約 70k レコードを含むデータセットを含むレポートが返されませんでした。クエリは約 1 ~ 2 分で実行されましたが、レポート デザイナーも開発 SSRS 2008R2 サーバー (レポート マネージャー) も結果のレポート プレビューを表示できませんでした。最後に、HTML プレビューがボトルネックになっているのではないかと疑い、シンプルなテキスト ボックスを含むカバー ページを追加して回避しました。次のレポートの実行には約 2 分かかり、表紙付きの HTML プレビューが正常に表示されました。完全な結果を Excel にレンダリングするのに、さらに 30 秒しかかかりませんでした。

SSRS のメモリ不足の例外を検索すると、このページは依然として上位の投稿の 1 つであるため、これが他の人の役に立てば幸いです。

于 2016-05-10T14:58:25.610 に答える
1

レンダリングに時間がかかるのはなぜですか...
テーブルに非クラスター化インデックスを作成しましたが、あまり役に立ちませんでした。

(AFAIK)SSRSはレンダリング前にレポートのメモリ内モデルを構築するためです。SSRS は、レポートを作成する際に次の 3 つの手順を実行することに注意してください。

  1. データを取得します。
  2. レポートとデータを組み合わせて内部モデルを作成します。
  3. レポートを適切な形式 (プレビュー、html、xls など) にレンダリングします。

ExecutionLog2 ビューをチェックして、各ステップにかかる時間を確認できます。ステップ 1 はおそらくすでにかなり高速 (秒単位) であるため、追加されたインデックスはボトルネックに取り組んでいません。おそらく、ステップ 2 と 3 に多くの時間がかかり、多くの RAM が必要です。

SSRS は #?? を含む列名を好まない 私の列名はKLN#でした。

私の知る限り、これは問題にならないはずです。その列を削除するだけで、レポートが再び実行可能になる可能性が高くなります。

レポート パラメーターを削除できることを除けば、(単純なレポートであるため) 再設計する必要はあまりありません。

SSRS は、これに適したツールではありません。そのため、問題の本当の「解決策」はなく、代替手段と回避策しかありません。

回避策:

  • @glhが彼の回答で述べたように、SSRSで使用できるRAMを増やすと「役立つ」場合があります。
  • パラメータを使用してデータをフィルタリングするようにユーザーに要求します (つまり、ユーザーが必要な行だけを選択できるようにしないでください)
  • 静かな時間 (十分な RAM が利用できるとき) にレポートをスケジュールし、レポートをキャッシュします。

代替案:

  • データベースから読み取り、Excel を出力する小さなカスタム アプリを作成します。
  • SSISを使用してください。これは、この種のタスク (データの変換と移行) により適していると思います。
  • セットアップを再考してください。レポートのコンテキストについて言及していませんが、おそらくXY 問題があります。おそらく、ユーザーはレポート全体を必要としているが、いくつかのキー行だけが必要な場合や、バックアップ メカニズムとしてのみ使用する場合 (より適切な代替手段がある場合)、または...
于 2013-01-27T15:14:29.213 に答える
0

RAM を増やしてみてください。同様のエラーについては、この投稿を参照してください。

400k を超えるレコードを表示するには SSRS マトリックスが必要です

于 2013-01-27T12:01:07.983 に答える