レポートのトラブルシューティング : レポートのパフォーマンス
レポートを表示する際に、最初のページが表示されるまでに長い時間がかかることがあります。レポートの処理時間がどこに費やされているのかを特定するための情報については、「レポートに関する問題のトラブルシューティングの手法」を参照してください。遅延が発生しているのがデータの取得なのか、レポートの処理なのか、またはレポートの表示なのかを特定できたら、このトピックを使用して問題のトラブルシューティングを開始できます。
データの取得に時間がかかる
レポートの処理に時間がかかる
レポートの表示に時間がかかる
レポート処理の最適化のためのデザインのヒント
データの取得に時間がかかる
レポートのデータが増えると、使用されるリソース、ネットワーク トラフィック、処理時間、およびストレージがすべて増加します。レポートに表示する問題を分析して必要なデータの量を特定し、必要なデータのみをレポート データ ソースから取得するようにします。
必要以上のデータがレポートに取得されている
フィルタ、並べ替え、および集計は、レポートの処理時に行うよりもデータ ソースで行う方が有効です。レポートに表示する詳細レベルのデータのみを返すクエリを作成します。レポート内の各レポート クエリを評価するためのヒントを以下に示します。
レポートに表示する必要があるもののみにデータを制限する WHERE 句または HAVING 句を含むクエリを作成します。クエリ パラメータを使用して、実行時に取得されるデータを制限します。クエリ パラメータは、対応するレポート パラメータに自動的にバインドされます。クエリ パラメータを使用すると、関心のあるデータをユーザーが決定できます。詳細については、「WHERE と HAVING を使ったフィルタによる行選択」を参照してください。
データをフィルタ選択するレポート パラメータを持つスナップショット レポートを作成すると、レポートに表示される可能性があるすべてのデータをスナップショットに保存しなければならなくなります。この場合は、データセット クエリでクエリ パラメータを使用する代わりに、フィルタ式で使用できるレポート パラメータを手動で作成して、必要なレポート データをユーザーが指定できるようにします。
ORDER BY 句を含むクエリを作成して、レポートに取得されるデータを事前に並べ替えます。レポートに表示する順序でデータを並べ替えます。データを事前に並べ替えると、レポートの処理時間が向上するような方法でデータがメモリに格納されます。多くのレポート処理タスクでは、データを処理前に並べ替える必要はありません。たとえば、SUM は順序に依存しません。また、グループ インスタンス内のデータは自動的に並べ替えられません。レポートのデータを並べ替える必要がない場合は、データセットやデータ領域で並べ替え式を設定しないでください。詳細については、「ORDER BY 句 (Transact-SQL)」および「レポートのデータの並べ替え」を参照してください。
グループの並べ替えや集計値による並べ替えは、クエリで行うよりレポートで行う方がはるかに簡単であり、多くの場合、より効率的です。
GROUP BY を含むクエリを作成して、データ ソースで値を集計します。
多くの場合、値を集計して概要を表示することで情報を最も効果的に伝えることができます。ある程度の集計をデータ ソースで計算して、それをデータセットに取得することができます。この場合、データセットの "詳細" データは、データ ソースで計算された集計を表します。詳細については、「クエリ結果の集計 (Visual Database Tools)」を参照してください。
このように事前に集計された値をレポートに取得した後も、数学的推移性のある集計関数 (SUM など) を使用している限り、集計を続けることが可能です。たとえば、1、2、3、4、5、6 という、6 つの値の集合があるとします。ここで、値を 2 つずつ 1 組としてグループ化すると、3、7、11 という、3 つの値の集合が得られます。1 つ目の集合の合計は 21 で、2 つ目の集合の合計も 21 です。つまり、どのようにグループ化しても、結果は同じであることがわかります。ここで、AVG 関数を使用し、集合に含まれる値の平均を求めた場合はどうでしょうか。その場合、それぞれの集合で結果が異なります。6 つの値の集合の平均は 21/6 (3.5) です。3 つの値の集合の平均は 21/3 (7) です。AVG は推移的関数とは言えません。
グラフやゲージに必要なデータの量について検討します。数ピクセルの画面に何百もの点を描画しても、パフォーマンスが低下するだけで、グラフィックの表示は向上しません。円グラフを 7 ～ 8 より多くに分割するのも疑問です。詳細については、「グラフ データ領域で表示するデータの準備」を参照してください。
条件に応じて表示/非表示を切り替えるレポート アイテムでは、最初に表示されるのはトップレベルのデータだけであっても、レポート プロセッサでグループ化、並べ替え、およびフィルタ式の適用が必要になります。SQL Server 2008 Reporting Services の要求時の処理では、表示されるデータのみを処理することによってデータの評価が最適化されていますが、表示される可能性があるデータはすべてレポートに含まれます。ユーザーが常に詳細データを表示するわけではない場合は、ドリルスルー レポートを使用することをお勧めします。詳細については、「レポートの種類」を参照してください。
レポートの実行スナップショットを作成することを検討します。レポート スナップショットには、レポート定義のデータセットに取得されたすべてのレポート データが含まれます。詳細については、「レポート履歴でのスナップショットの作成、変更、および削除」を参照してください。
クエリがタイムアウトになる
クエリ タイムアウト値は、レポートの作成中にデータセットを定義するときに指定します。タイムアウト値は、クエリの Timeout 要素の中にレポートと一緒に格納されます。既定では、この値は 30 秒に設定されます。詳細については、「レポート処理タイムアウト値の設定」を参照してください。
データセット クエリのタイムアウト値を設定する方法については、「データセットを作成する方法 (Reporting Services)」を参照してください。
大量のネットワーク トラフィックによってユーザーの待ち時間が発生する
大量のデータをネットワーク トラフィックとして渡すと、ユーザーの待ち時間が発生する可能性があります。ユーザー ベースやレポート表示のボリュームの予測に応じて、レポート サーバー コンポーネントの配置方法を選択できます。詳細については、「配置トポロジの計画」を参照してください。
ユーザーの待ち時間の短縮に役立つ方法の例を以下に示します。
レポート サーバー カタログをレポート サーバーと同じコンピュータに配置します。
レポート サーバー データベース tempdb は、レポート定義の各データセット クエリで取得されるレポート データを管理します。レポート データをレポート プロセッサと一緒に配置すると、レポートの実行速度を低下させる原因になるネットワーク トラフィックが減少します。
データ ウェアハウス データ ソースの場合は、データ ウェアハウスをレポート サーバーとは別のサーバーに配置します。
データをネットワーク経由で取得すると確かに余分なレポート実行タスクが増えますが、互いにメモリを取り合うデータ ウェアハウスと Reporting Services を同じサーバーに配置すると、パフォーマンスが低下する可能性があります。
レポートの処理に時間がかかる
レポートの処理は、データがレポート データセットに取得された後、レポート プロセッサがレポート レイアウトとデータを結合して中間レポート形式を作成するときに発生します。作成された中間レポート形式はレポート レンダラに渡されます。一般に、このデータとレイアウトの結合の処理は、ユーザーによって表示されている現在のページに対してのみ行われます。多数のインスタンスを含むレポートの領域では、レポート レイアウト、ページング、および複合式がレポートの処理時間に影響を与える可能性があります。
ここでは、レポート処理のパフォーマンスの向上に役立つ情報を紹介します。
ページ ヘッダーやページ フッターで式を使用するとすべてのページが処理される
組み込みフィールド [&TotalPages] への参照が含まれていると、レポート プロセッサがレポート全体をページ分割するまで最初のページを表示できません。[&TotalPages] への参照が存在しない場合は、レポートの残りの部分を処理する必要はなく、すぐに最初のページを処理してユーザーに返すことができます。また、レポート プロセッサでは、ページ ヘッダーやページ フッターの複合式には [&TotalPages] への直接参照または間接参照が含まれている可能性があると見なされます。
レポート プロセッサによって長大なレポートのページ分割が行われないようにするため、[&TotalPages] への参照を含めたり、ページ ヘッダーやページ フッターに複合式を含めたりしないようにしてください。
レポートに改ページが含まれていない
レポート プロセッサは、ユーザーがレポートのページ間を移動するたびに、各レポート ページのデータとレポート レイアウト情報を結合して、ページをレポート レンダラに渡します。改ページが含まれていないレポートでは、レポート全体が処理されるまで最初のページが表示されません。
HTML ビューアなどのソフト改ページ レンダラでは、ページングが自動的に処理されます。レポート プロパティの InteractiveHeight を 0 に設定すると、この自動的な動作を無効にしてレポートを 1 ページとして設定できます。ハード改ページ レンダラでは、改ページを手動で追加する必要があります。レンダラの種類の詳細については、「レンダリングの動作について」を参照してください。
InteractiveHeight が 0 ではなく妥当なページ サイズ (8.5 in など) に設定されていることを確認し、レポートをページ分割しやすくするためにレポート アイテムや Tablix グループに改ページを追加します。これにより、各ページで処理しなければならないデータの量が減ります。詳細については、「改ページを追加する方法 (Reporting Services)」を参照してください。
Tablix データ領域の複雑なグループ化関数と集計関数
何重にも入れ子になったグループや隣接するグループが Tablix データ領域に含まれていると、レポート処理のパフォーマンスに影響する可能性があります。グループ化のレベルやグループ インスタンスの数のほか、グループ式、フィルタ式、および並べ替え式が適用された後に評価する必要がある集計関数の使用についても考慮する必要があります。たとえば Previous は、値がデータ領域の並べ替え済みの要素に依存するため、"コストの高い" 集計関数です。Sum は順序に依存しないため、必要とされるリソースが少なくなります。並べ替え後に行われる集計には、その他に First や Last などがあります。詳細については、「式での組み込みのレポート関数と集計関数の使用 (Reporting Services)」を参照してください。
レポートのデザインを評価して、データ集計の一部をデータ ソースで実行できないかどうかを検討します。集計関数の呼び出しを変更しなくても、レポートのデータの量を減らすだけで十分なパフォーマンスが得られる場合もあります。
Tablix データ領域に多数のサブレポート インスタンスがあるとレポートのパフォーマンスが低下する
サブレポートを使用することの長所と短所を把握しておく必要があります。サブレポートのインスタンスはそれぞれ個別のクエリとして実行され、個別のレポート処理タスクとして処理されます。
サブレポート インスタンスが少ししかない場合は、サブレポートを使用します。
多数のグループ インスタンスがある場合は、グループ内でサブレポートを使用しないようにします。たとえば、各顧客の売り上げと返品の両方の一覧を表示する場合は、ドリルスルー レポートを使用できないかどうかや、顧客を売り上げおよび返品と結合してから顧客 ID でグループ化するクエリを作成できないかどうかを検討します。
サブレポートがメイン レポートとは別のデータ ソースを使用する場合は、サブレポートを使用します。パフォーマンスが問題になる場合は、次のいずれかの緩和方法を使用してメイン レポートのデータセット クエリを変更することを検討してください。
データをデータ ウェアハウスに収集し、そのデータ ウェアハウスを 1 つのデータセットのデータ ソースとして使用する。
SQL Server リンク サーバーを使用して、複数のデータベースからデータを取得するクエリを作成する。
OPEN ROWSET 機能を使用して別のデータベースを指定する。
複数のプロセスがレポート サーバーの同じメモリを取り合う
複数のアプリケーションがレポート サーバーの同じメモリ リソースを取り合うと、レポートの処理に影響する可能性があります。
システム管理者と連携し、メモリ管理構成がレポート サーバーに適したモデルになっていることを確認してください。詳細については、「レポート サーバー アプリケーションで利用可能なメモリの構成」を参照してください。
レポートの実行がタイムアウトになる
大きなレポートを実行するには、レポート実行タイムアウトと ASP.NET タイムアウトの 2 つのタイムアウト値を調整する必要があります。
レポート実行タイムアウト値は、レポート サーバーで指定します。詳細については、「レポート処理タイムアウト値の設定」を参照してください。
ASP.NET のタイムアウト ポリシーは、レポート サーバー構成ファイルによって制御されます。このファイルの既定の場所は、<ドライブ>:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\web.config です。要求を実行できる最大秒数を設定するには、このファイルに httpRuntime 要素を追加します。
<configuration>
. . .
<system.web.
. . .
<httpRuntime executionTimeout="90"/>
. . .
</system.web.
. . .
</configuration>
レポートのサイズによっては、数時間に及ぶ値を指定する必要がある場合もあります。
レポートの表示に時間がかかる
レポートの表示は、データとレイアウトが中間形式に結合され、表示拡張機能に渡された後に行われます。表示時間は、データの量、レポート アイテムのインスタンスの数、およびページングの影響を受ける可能性があります。レポートをエクスポートする際には、中間形式を特定のレンダラに渡します。ユーザーがレポートを特定の形式で表示することがわかっている場合は、そのレンダラに合わせてレポートを最適化する必要があります。詳細については、「レポートのエクスポート」および「レンダリングの動作について」を参照してください。
ここでは、レポート表示のパフォーマンスの向上に役立つ情報を紹介します。
選択された表示形式にレポートが最適化されていない
すべてのレンダラですべての機能がサポートされているわけではありません。レポートを主に特定のファイル形式で表示する場合は、ユーザーがレポートを最適な形で表示できるようにレポートのデザインを変更する必要があります。
適切な場所に改ページを追加します。たとえば、各改ページは Excel の新しいシートを定義します。各シートでは最大 65,000 行を処理できます。レポートで改ページを設定する際には、これらの制限を考慮に入れてください。
Excel にエクスポートする場合は、Tablix データ領域のセルを結合しないようにします。自由形式のレポートではレポート アイテムを垂直方向に揃えます。結合されたセルや整列されていないレポート アイテムがあると、エクスポートされたレポートで Excel の機能の妨げになります。
表示する HTML ページが大きい場合、HTML パーサーの処理効率は低下します。レポートの表示に時間がかかる場合は、生成されるファイルのサイズを小さくできる形式 (CSV など) を選択します。レポート ツール バーを利用できないために別の形式を選択できない場合は、表示形式を設定して、レポートを静的ドキュメントとしてファイル共有に配信するサブスクリプションを定義できます。詳細については、「Reporting Services でのファイル共有の配信」を参照してください。
レポート処理の最適化のためのデザインのヒント
レポートのパフォーマンスが最優先される場合に、レポートの処理に必要な時間をできるだけ短くするために役立つ情報を以下に示します。
レポートにテキスト ボックスのインスタンスが数多く含まれている場合は、テキスト ボックスの CanGrow と CanShrink を FALSE に設定します。Tablix データ領域の各セルには既定でテキスト ボックスが含まれるため、表示する必要があるテキスト ボックスの総数はすぐに増えてしまいます。
レポートに多数の画像が含まれている場合は、画像の AutoSize を別の値 (Fit など) に設定します。
テキスト ボックスでは TextAlign プロパティを General に設定しないようにします。この値では、テキスト ボックスの内容に応じた条件処理が必要になります。
不要な場所で水平方向の改ページを使用しないようにします。また、レポートの余白、列幅、および空白を確認します。たとえば、レポートを .TIFF ファイルに変換して Microsoft Windows 画像と FAX ビューアで表示すると、余分なページが表示されないかどうかを確認できます。
Tablix メンバの KeepTogether プロパティは、Tablix データ領域の特定の表示動作を制御する必要がある場合にのみ設定します。KeepTogether 機能を使用すると、改ページの計算時に追加の処理が必要になります。