多くのデータベース管理者は、SQL Server Reporting Services（SSRS）のインスタンス、または少なくともSSRSに必要なバックエンドデータベースをサポートする必要があることに気付きます。何年もの間、SSRSはSQL Serverのインストールにバンドルされていたため、製品のライセンスとサポートに関する混乱が生じたため、SSRS 2017以降、ReportingServicesのインストールパッケージは個別にダウンロードされます。

この記事では、Reporting Servicesのインストールを適切にライセンス、リカバリ、および調整するためにデータベース管理者が知っておく必要のある多くの領域について説明します。これらのトピックは、SQL ServerReportingServicesとPowerBIReportServerの両方に適用されます。

ライセンス

SSRSのインストールとサポートは混乱を招く可能性があります。レポートサービスは、専用サーバー上のスタンドアロンインスタンス、SQL Serverと同じインスタンス、またはスケールアウト展開（Enterprise Editionのみ）としてインストールできます。 SSRSが本番環境にインストールされている各インスタンスには、SQL Serverライセンスと、ReportServerおよびReportServerTempDBデータベースが存在するSQLServerのインスタンスのライセンスが必要です。

Reporting Servicesのライセンスを取得する方法を説明する方法は、レポートサービスをバックエンドでSQLServerを使用するアプリケーションと考えることです。 SSRSの初期には、インターネットインフォメーションサービス（IIS）もインストールして構成する必要がありました。 SSRS 2008は、そのコンポーネントをレポートサービスモジュールに導入しました。ライセンスのためにSSRSとMSSQLが同じインスタンスにインストールされているのを見るのは非常に一般的であり、これは小規模な実装でうまく機能する可能性があります。大規模な展開の場合、統合されたSQLServer上にReportServerとReportServerTempDBを備えた専用のレポートサービスサーバーが表示されるのが一般的です。非常に大規模なインストールの場合、スケールアウト展開を使用して、レポートサーバーサービスの負荷分散を提供します。スケールアウト展開では、ファーム内の各インスタンスにライセンスが必要です。

回復

各展開モデルで、データベース管理者の役割は、SSRSが安定していて、信頼でき、回復可能であることを確認することです。回復可能な部分は、いくつかのDBAの問題を引き起こすものです。 ReportServerデータベースは暗号化されており、特定の操作では対称鍵を復元する必要があります。障害が発生し、データベースを別のサーバーに復元する必要がある場合は、レポートサーバーのWindowsサービスアカウント名またはパスワードを変更するか、コンピューター名を変更するか、別のサーバーに移行するか、新しいサーバーをスケールに追加します-構成を解除するには、暗号化キーを復元する必要があります。キーがバックアップされていない限り、接続文字列やパスワードなどの保護されたデータを復号化することはできません。手遅れになるまで、多くのDBAがこれに気づいていないことがわかりました。キーは、Reporting Services Configuration Manager、rskeymgmt.exeユーティリティ、またはPowerShellを使用して手動でバックアップおよび復元できます。技術的には、対称鍵のコピーを1つだけバックアップする必要があります。

ReportServerおよびReportServerTempDBデータベースはSQLServerデータベースであり、他のユーザーデータベースと同様に、通常のバックアッププロセスの一部である必要があります。 ReportServerは完全復旧モデルを使用する必要がありますが、ReportServerTempDBは単純復旧モデルを使用できます。技術的には、災害時にReportServerTempDBをスクリプトで再作成できますが、ReportingServicesはReportServerTempDBなしでは起動できません。 DBAは、データベースを再作成するためのスクリプトを探すのではなく、データベースの復元に精通しています。システムデータベースtempdbとは異なり、ReportServerTempDBは起動時に再作成されません。 DBAのベストプラクティスは、実際にはReportServerとReportServerTempDBを他のユーザーデータベースと同じように扱うことです。

また、バックアップする必要があるアプリケーション設定を格納する構成ファイルがあります。これらは、OSレベルのバックアップでカバーされる場合があります。ただし、DBAは、初期構成後やカスタム拡張機能の適用後に、これらのファイルがバックアップされていることを確認する必要があります。これらのファイルは次のもので構成されています：

• Rsreportserver.config
• Rssvrpolicy.config
• Rsmgrpolicy.config
• Reportingservciesservice.exe.config
• Web.config
• Machine.config

次のようなレポートデザイナファイルのバックアップに関する考慮事項。 .rdl、.rds、.dv、.ds、rptproj、および.slnファイルを指定する必要があります。

チューニングオプション

SSRSの調整は、他のアプリケーションとほとんど同じです。ユーザーは、データベースと通信しているアプリケーションサーバーからレポートを実行しています。大きな違いは、独自のデータベースを備えたアプリケーションサーバー（Reporting Services）がありますが、レポートには他のユーザーデータベースに接続するデータソースがあることです。 DBAは、実際のレポートを調整するだけでなく、ReportingServicesインフラストラクチャの全体的な状態を調整する必要があります。

レポートサービスインフラストラクチャ

ReportServerとReportServerTempDBのディスク遅延は非常に重要です。ワークロードによっては、これらのデータベースをより高速なディスクに配置する必要がある場合があります。レポート結果のキャッシュはReportServerTempDBデータベースに保存され、I/Oパフォーマンスがここで問題になる可能性があります。

Reporting Servicesのワークロードにより、そのワークロードを処理するために追加のReportingServicesインスタンスが必要になる場合があります。スケールアウト展開には、EnterpriseEditionライセンスが必要です。スケールアウト展開の利点には、より高いスループット、高可用性、およびレポートサーバー処理をセグメント化する機能のための負荷分散を顧客に提供することが含まれます。

意味のある場所でスナップショットを利用します。 1日前のデータを使用しているレポートがある場合は、スナップショットの使用を検討してください。これにより、レポート全体を再度生成するのではなく、そのレポートの後続のビューでスナップショットが使用されます。

データドリブンサブスクリプションを使用して、レポートを実行し、サブスクライバーベースおよびスケジュールに基づいてコンテンツを配信できます。スケジュールに基づいて、これらのレポートの多くは、データ処理が完了した後、ユーザーが職場に到着するかなり前に、環境にとって忙しくない時間に実行できます。

DBAは、実行ログに精通している必要があります。これは、キャッシュの候補となる可能性のあるレポートや、実行処理に基づいてパフォーマンスを向上させるために調べる必要のあるレポートを特定するのに役立ちます。実行ログは、レポートが実行される頻度、最も要求された形式、レポートプロセスのフェーズに関連付けられた処理の割合などの洞察を提供します。このデータには、ExecutionLog、ExecutionLog2、ExecutionLog3の組み込みビューを使用してアクセスできます。

一般的なチューニング

レポートで使用されているユーザーデータベースと、ReportServerおよびReportServerTempDBを保持しているインスタンスの場合、パフォーマンスを追跡およびベースライン化する必要があります。これらのシステムの全体的なワークロードの正常な状態を知るには、メモリ/ディスク/ CPU使用率、ネットワークI / O、tempdb使用率、待機、およびその他のカウンターを監視する必要があります。ユーザーが問題の報告を開始した場合は、現在の使用率が正常かどうかを知る必要があります。監視していない場合、どのように測定できますか？

監視とベースライン化に加えて、業界で受け入れられているベストプラクティスをインスタンスに適用する必要があります。前回の記事「CommonSQLServerMishaps」で、メモリ設定、インデックスメンテナンス、統計、MAXDOP、並列処理のコストしきい値について説明しました。

レポートの実行を高速化するための本当の魔法は、そのレポートを最適化することです。レポートは本質的に単なる別のクエリです。遅いレポートを調整するには、通常、その特定のレポートのインデックスを作成するか、レポート内のコードを調整する必要があります。これらがOLTPデータベースにアクセスしているレポートである場合、レポートのインデックスを作成すると、より多くのスペースを使用し、更新、挿入、および削除のための追加のI / Oを生成し、それらのインデックスを維持するための追加のオーバーヘッドが発生するため、OLTPシステムに影響を与える可能性があります。リスクと報酬のバランスをとる必要があります。一部のお客様は、トランザクションレプリケーションを使用してレポートデータベースをOLTPから分離できます。これにより、OTLPデータベースに影響を与えることなくレポートデータベースにインデックスを付けることができます。

ExecutionLogを使用してレポートの使用状況を追跡できますが、機会を調整するために、ユーザーデータベースインスタンスを調査して、コストが高く、実行時間の長いクエリを探す必要があります。 DMVとクエリストアも大きな助けになりますが、SQLSentryのような監視ツールははるかに強力で柔軟性があります。 SQL Sentry自体には「レポートサービスダッシュボード」はありませんが、SSRSイベントのカレンダービューを作成し、組み込みのメトリックとレポートを簡単にフィルタリングしてSSRSアクティビティに焦点を合わせ、堅牢なアドバイザリ条件を作成しての正確な側面を監視できます。あなたが気にかけているレポーティングサービス（そしてあなたが気にしないノイズはありません）。 SQL ServerマシンでSSRSを実行していない場合でも、Win Sentryを使用して、現在および過去のプロセスレベルおよびサービスレベルのアクティビティに関する豊富なパフォーマンスの洞察を得ることができます。

結論

SQL Server Reporting Servicesのチューニングにはいくつかの固有の特性がありますが、レポートの最適化とReportServerおよびReportServerTempDBデータベースの監視には標準のパフォーマンスチューニングを引き続き適用できます。暗号化キーのバックアップは、ディザスタリカバリまたは移行作業に必要です。レポートの使用法をよりよく理解するために、DBAはExcecutionLogの使用を開始する必要があります。