レポートのパフォーマンスのトラブルシューティング
新規 : 2008 年 11 月 17 日
このトピックでは、レポートのパフォーマンスを向上する方法について説明します。
レポートのパフォーマンスに関するトラブルシューティングを行うには、Reporting Services ログ ファイルを使用して、データの取得、レポート レイアウトの処理、またはレポートの表示のどこに最も時間がかかっているかを判断します。詳細については、「レポートに関する問題のトラブルシューティング」を参照してください。
どこに最も時間がかかっているかがわかったら、次のセクションを使用して特定の問題のトラブルシューティングを行います。
データ取得のパフォーマンスの向上
レポート処理のパフォーマンスの向上
レポート表示のパフォーマンスの向上
データ取得のパフォーマンスの向上
レポートのデータ量が多くなるほど、使用されるリソースおよびストレージも生成されるネットワーク トラフィックも増え、長い処理時間が必要になります。レポートのパフォーマンスを制御するには、データ量も複雑さも妥当なレポートをデザインします。たとえば、ほとんどのユーザーは 1,000 ページものレポートの表示を望みません。また、テーブルの入れ子レベルが多すぎるとドリルダウン レポートのコンテキストがわかりづらく、列が多すぎるとテーブルが見づらくなります。円グラフに何百ものスライスがあると、煩雑でわかりづらくなります。レポートの必要条件を慎重に検討して必要なデータ量を判断し、その後でレポートのデータ ソースからそのデータのみを取得してください。
次のセクションの情報を使用すると、レポートのためのデータ取得にかかる時間を短縮できます。
必要以上のデータの取得
大量のデータをフィルタ処理、並べ替え、および集計する場合は、レポートの処理中に行うよりデータ ソースに対して行う方が効率的です。レポートに表示するデータのみを取得するクエリを作成するようにしてください。要約データのみを表示する場合は、集計の計算はデータ ソースに対して行い、詳細データは取得しないようにします。レポートの各レポート クエリを評価するためのアイディアを以下に示します。
- レポートに表示するもののみにデータを制限する 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 つずつグループ化すると、3、7、11 の 3 つの値になります。最初の 6 つの値の合計 (21) を計算する場合も、2 番目の 3 つの値の合計 (21) を計算する場合も、グループ化に関係なく合計値は同じになります。しかし、AVG 関数を使用して、6 つの値と 3 つの値の平均を求めると、それぞれに対して異なる結果が得られます。6 つの値の平均は、21/6 で 3.5 です。3 つの値の平均は、21/3 で 7 です。AVG は推移関数ではありません。 - データ ソースのクエリ パフォーマンスの分析および最適化を検討します。たとえば、SQL Server 2005 のクエリ オプティマイザの詳細については、「クエリ パフォーマンス」および「単一 SQL ステートメントの処理」を参照してください。
- グラフに必要なデータ量を検討します。折れ線グラフでは、モニタ上に数ピクセルの点を数百個描いても、パフォーマンスを低下させるだけで、グラフィックの見やすさが向上するわけではありません。円グラフでは、スライスが 7 つか 8 つ以上になると、必ずしも有用であるとは言えなくなる場合があります。
- 条件付きで表示するレポート アイテムについては、最初に最上位のデータしか表示されない場合でも、レポート プロセッサでグループ化式、並べ替え式、およびフィルタ式を適用する必要があります。ユーザーがときどきしか詳細データを表示しない場合には、ドリルスルー レポートの方が適しています。ドリルスルー レポートは、ユーザーがメイン レポートのドリルスルー リンクをクリックするまで実行されません。ドリルダウン レポートまたはサブレポートでは、データが当初表示されない場合でも、すべてのデータが処理されます。詳細については、「レポートへのリンクの追加」を参照してください。
- レポートの実行スナップショットの作成を検討します。レポート スナップショットには、レポート定義のデータセットのために取得されたすべてのレポート データが含まれます。詳細については、「レポート スナップショット」を参照してください。
大量のネットワーク トラフィックによる待機時間の長期化
ネットワーク トラフィックとして大量のデータが送受信されると、ユーザーに待機時間が発生します。予想されるユーザー ベースとレポート表示の予想量がわかれば、レポート サーバー コンポーネントの配置に関して適切なアプローチを選択できます。
ユーザーの待機時間を短縮するには、次の方法を検討します。
- レポート サーバーと同じコンピュータにレポート サーバー データベースを配置します。
レポート サーバー データベースの tempdb は、各データセット クエリに対して取得されるレポート データを管理します。レポート サーバーに tempdb を配置することで、レポートの実行を遅らせるネットワーク トラフィックを低減できます。 - データ ウェアハウスのデータ ソースの場合、レポート サーバーとは異なるサーバーにデータ ウェアハウスを配置します。
ネットワーク経由でデータを取得するとレポート実行時のタスクは増えますが、データ ウェアハウスと Reporting Services を同じサーバーに配置すると、両者によるメモリ消費が競合するために、パフォーマンスが低下する場合があります。
詳細については、「Reporting Services の配置の計画」を参照してください。
クエリのタイムアウト
データの取得前にデータセット クエリがタイムアウトする場合は、レポートのタイムアウト値を指定できます。既定では、この値は 30 秒に設定されます。データセット クエリのタイムアウト値を設定するには、「データセットを作成する方法 (レポート デザイナ)」を参照してください。詳細については、「レポート実行タイムアウト値の設定」を参照してください。
レポート処理のパフォーマンスの向上
レポート処理は、レポート データセットおよびレポート パラメータのデータの取得後に行われます。レポート プロセッサは、レポート レイアウトとデータを結合して中間レポート形式を作成し、その後、この中間レポート形式がレポート レンダラに渡されます。レポート処理時間は、レポート レイアウト、ページング、および多くのインスタンスを持つレポート アイテムの複合式によって影響を受ける可能性があります。このセクションを使用して、レポート処理パフォーマンスを向上できます。
正しいデータ領域の選択
可能な場合は、テーブルおよび一覧のデータ領域を使用します。テーブルまたは一覧の処理は、マトリックスの処理よりも効率的です。テーブルおよび一覧のデータ領域では、行のみについて動的要素がサポートされます。マトリックス レイアウトでは、行および列について動的要素がサポートされるため、レイアウト構造がより複雑になります。
物理ページ レンダラのページ ヘッダーまたはページ フッターに合計ページ値の使用を避ける
PDF または画像など、物理ページの改ページを行うレイアウト表示拡張機能によってレポートが表示される場合は、グローバル フィールド TotalPages の参照により、レポート処理パフォーマンスが影響を受ける場合があります。レンダラの詳細については、「レポートの表示に関するデザイン上の注意事項」を参照してください。
複雑なデータ領域のグループ化関数および集計関数の使用
テーブルまたはマトリックスのデータ領域に多くのレベルの入れ子構造のグループが存在すると、レポート処理パフォーマンスが影響を受ける場合があります。グループ化のレベルとグループ インスタンスの数を検討すると共に、グループ化式、フィルタ式、および並べ替え式の適用後に評価する必要がある集計関数の使用についても考慮します。
並べ替え後の集計を避けます。並べ替え後の集計は並べ替え順に依存しており、これには Previous、First、Last、および RunningValue の各関数が含まれます。式にこれらの関数を含めると、レポート プロセッサは関数を適用する前にターゲット データを並べ替える必要があります。複数レベルの入れ子のグループや隣接するグループなど、グループ定義が複雑なマトリックス レイアウトに含まれる式に、並べ替え後の集計を含めることは可能な限り避けてください。
レポート デザインを評価し、一部のデータ集計をデータ ソースに対して行うことが可能かどうかを検討します。レポートのデータ量を削減するだけで、集計関数の呼び出しを変更しなくても、妥当なパフォーマンスが得られる可能性があります。
集計関数の詳細については、「式でのレポート関数の使用 (Reporting Services)」を参照してください。
式における不要な再帰の指定
マネージャおよび従業員を表示する組織レポートなど、再帰型階層を定義する場合にのみ、グループの親の式を指定します。Parent プロパティは、再帰型データのみに適用されます。Parent プロパティは、入れ子構造のグループの親子関係には適用されません。
多くの行を持つデータ領域におけるサブレポートの使用
サブレポート使用の利点と欠点を理解します。各サブレポート インスタンスは、個別のクエリ実行タスクおよび個別のレポート処理タスクになります。
- データ領域でサブレポートを使用するのは、サブレポート インスタンスの数がごく少ない場合にします。
- 多くのグループ インスタンスが存在する場合は、データ領域グループでのサブレポートの使用を避けます。たとえば、各顧客の売り上げおよび返品の一覧を表示するには、ドリルスルー レポートの使用を検討します。顧客データを売り上げおよび返品データと結合し、その後で顧客 ID によりグループ化するクエリを作成できるかどうかを検討します。
- メイン レポートとは異なるデータ ソースを使用する場合はサブレポートを使用します。パフォーマンスが問題になる場合は、次のいずれかの方法を使用してメイン レポートのデータセット クエリの変更を検討します。
- データ ウェアハウスでデータを収集し、1 つのデータセットのデータ ソースとしてデータ ウェアハウスを使用します。
- SQL Server リンク サーバーを使用し、複数のデータベースからデータを取得するクエリを作成します。
- OPEN ROWSET 機能を使用して異なるデータベースを指定します。
対話的な並べ替えの使用
ユーザーがレポートのデータの並べ替え順を変更する機能を必要とする場合を除いて、対話型の並べ替えボタンの使用を避けます。
画像の使用
画像のリソース要件を理解します。
- 背景画像など、大きな画像の使用を避けます。大きな画像は、特に PDF、印刷画像、ドキュメント画像などのハードコピー形式のレンダラに渡されたときに、メモリ リソース、処理リソース、および表示リソースを必要とします。
- 主要業績評価指標 (KPI) などで、データベースやサーバーにある小さな画像のインスタンスを多数使用することを避けます。これらの画像は、埋め込み画像としてレポートに含めます。
- 多くの画像を含むレポートの場合は、画像の AutoSize を Fit などの別の値に設定します。
プロセスによるレポート サーバーのメモリの競合
複数のアプリケーションがレポート サーバーの同じメモリ リソースを求めて競合すると、レポート処理に影響する場合があります。
システム管理者と協力して、メモリ管理の構成モデルがレポート サーバーの用途に適していることを確認します。詳細については、「Reporting Services で利用可能なメモリの構成」を参照してください。
レポート実行タイムアウト
大きなレポートを実行するには、レポート実行タイムアウトおよび ASP.NET タイムアウトの 2 つのタイムアウトを調整する必要があります。
レポート実行タイムアウト値は、レポート サーバーで指定します。詳細については、「レポート実行タイムアウト値の設定」を参照してください。
ASP.NET タイムアウト ポリシーは、レポート サーバー構成ファイルによって制御されます。このファイルの既定の場所は、<drive>:\Program Files\Microsoft SQL Server\MSSQL.n\Reporting Services\ReportServer\web.config です。要求を実行する最大秒数を設定するには、httpRuntime 要素に秒単位のタイムアウト値を設定します。次の XML フラグメントは、この要素を追加する構成ファイルの場所を示します。
<configuration>
. . .
<system.web>
. . .
<httpRuntime executionTimeout="90"/>
. . .
</system.web>
. . .
</configuration>
実行時間の長いクエリまたは複雑なレポートの場合は、数時間にわたる値を指定することが必要になる可能性があります。
レポート表示のパフォーマンスの向上
レポートの表示は、データとレイアウトが結合され、表示拡張機能に渡された後に行われます。表示時間は、データ量、レポート アイテムのインスタンス数、およびページ サイズに依存します。レポート レンダラによって、ページに配置できるデータ量が決まります。ページの定義はレンダラによって異なります。Excel レンダラのページはワークシートです。レポートを印刷できる PDF レンダラのページは、物理ページです。HTML ビューアのページは、レポート全体となる場合があります。印刷ページのレポート デザインは、オンライン表示のレポート デザインと異なる場合があります。ユーザーが特定の形式でレポートを表示することが予想される場合は、その形式のレポートをデザインします。詳細については、「レポートの表示に関するデザイン上の注意事項」を参照してください。
次の表は、レポート表示パフォーマンスを向上する方法を示します。
| 表示形式 | 説明 |
|---|---|
すべて |
|
Excel |
|
HTML |
|
画像 TIFF 印刷 |
|
.gif "Dd353300.note(ja-jp,SQL.90).gif")
メモ :
1 つの形式のレポートの表示に問題がある場合は、CSV など、生成されるファイルのサイズを小さくできる形式を選択します。パブリッシュされたレポートの場合、URL の表示形式を指定できます。詳細については、「URL での表示形式の指定」を参照してください。
レポート ツール バーを利用できないために別の形式を選択できない場合は、表示形式を設定してレポートを静的ドキュメントとしてファイル共有に配信するサブスクリプションを定義できます。詳細については、「Reporting Services でのファイル共有の配信」を参照してください。
参照
概念
Reporting Services のログ ファイル
サイズの大きなレポートの処理
その他の技術情報
Reporting Services のトラブルシューティング
Reporting Services のエラーおよびイベント
レポートに関する問題のトラブルシューティング