単一の SQL テーブルに約 10 個の lac レコードがあります。これだけのレコードを自分のレコードにロードする必要があります。これが読み込まれるかどうかを知る必要があります。メモリ不足の例外を表示することを報告するためにロードしようとしたとき。
3 に答える
Reporting Services (および Cognos、Business Objects、およびその他の BI レポート スイート) では、通常、OUTPUT に数十万または数百万のレコードが含まれるレポートのレンダリングに問題があります。これらのシステムのほとんどは、データを数万のレコードに集約することには大きな問題はありませんが、数十万または数百万に達すると、メモリ エラーが発生します。
何十万行ものレポートには Reporting Services を使用しないことをお勧めします。レポートのすべての行を読む人はいません。65,556 行の制限があるため、ほとんどの BI スイートは、Excel にレンダリングしようとしてもレポートを出力しません。大規模な生データ ダンプには SSIS を使用することをお勧めします。ユーザーが Excel で探索的なアドホック スライス アンド ダイス分析を実行できるようにする場合、またはそれをより小さく関連性の高いデータに分割して消費できるようにする方法を見つけたい場合は、Analysis Services キューブを使用することをお勧めします。人間 -- 数百行または数千行に集約またはフィルタリングされることを意味します。
レポート サービスを使用する必要があり、それをツールとして使用してデータを Excel に取り込みたい場合は、サブスクリプションを介して CSV へのレンダリングを試すことができます。繰り返しになりますが、数百万行の CSV ファイルを出力するメモリの問題が発生しないため、代わりにこれを行う SSIS パッケージをビルドすることをお勧めします。ただし、レポート サービスを出力ツールとして使用する必要がある場合は、メモリ負荷が最も少ないレンダリング方法を使用して、メモリ コストを最小限に抑えてください。
何万ものレコードを表示しようとしていますか?どのユーザーがそれを読むだろうか?レポートをスケジュールして電子メールで送信してみましたか?
質問を拡大しない限り、これは答えられません。どの言語を使用していますか? どのレポート生成フレームワーク? SQLクエリはどのように見えますか?
編集:ああ、わかりました、Microsoft SQL Reporting Services。何百万ものタプルを含むテーブルに対するクエリを簡単に処理できるはずです。それはすべて、クエリをどのように構成したかによって異なります。