SQL Server-レポート用の別のデータベース？

SQL Serverには、各Webアプリ用のデータベースがあります。レポートには、Reporting Servicesを使用し、すべてのレポートデータ（レポートパラメーターを含む）はストアドプロシージャから取得します。

ストアドプロシージャは、レポート内のデータと同じデータベースにあります。したがって、たとえば、Stockレポートを提供するprocはStockデータベースにあります。一部のレポートには、複数のデータベースからの情報が表示され、procはそれらのソースデータベースのいずれかになります。レポートパラメータは、店舗、従業員などのデータを持つエンタープライズデータベースのプロシージャからデータを取得します。

つまり、すべてのレポートには、少なくともエンタープライズデータベースへの接続と別のデータベースへの別の接続があり、場合によってはそれ以上の接続があります。

私の質問は、レポートプロシージャを別の「レポート」データベースに移動することの利点があります。レポートを別のサーバーに移動することの利点を知っていますが、それについては話していません。これは同じサーバー上にあります。

これに影響する可能性のあるものは次のとおりです。

• レポートに複数のデータベース接続があると、レポートの速度に影響しますか？
• レポートプロシージャをデータとは別のデータベースに配置すると、インデックス付きビューを使用できなくなりますか？
• 別のデータベースでレポートを管理する方が簡単/難しいと感じましたか？

ご意見をお聞かせください。

答えは、はい、そうすることには利点があります。運用データベースに関するレポートは、多くのリソースを使用し、運用システムのパフォーマンスに干渉します。データベースのパフォーマンスは、機械的な制約（ディスクヘッドが前後に移動し、適切なセクターがヘッドの下に現れるまで待機する際の回転待ち時間）の影響を受けることに注意してください。レポート戦略には、2つの幅広いオプションがあります。

1. データベースを別のサーバーに複製し、レポートsprocをそのサーバーに移動します。レポートは複製されたサーバーから実行されます。これは最小の労力であり、既存のレポートとストアドプロシージャを再利用できます。
2. 実稼働システムからのデータを統合し、レポート作成に非常に使いやすい形式に変換するデータウェアハウスを構築します。「昨日の営業終了」時点のスナップショットから容認できるほどのアドホックな統計レポートが多数ある場合は、データウェアハウスがより良いアプローチかもしれません。

実行しているSPの種類に大きく依存すると思います。それらが重く、データベースサーバーで実行されている他のものに影響を与える可能性がある場合は、それらを移動します。そうでなければ、保守と追跡がはるかに簡単であることがわかった場合は、実際に報告しているデータベースにできるだけ近づけるようにします。レポートを実際のデータベースの近くに置くだけでもパフォーマンスに影響を与える可能性がありますが、標準設定で大量のデータを移動しないと、わずかな違いになります。

私も見つけたこの記事が役に立ちます。

いくつかの理由で、ストアドプロシージャを別のデータベースに移動しないことをお勧めします。開発の観点からは、変更を行うたびに2つのデータベースを再現する必要があります。その結果、「データ」データベースのスキーマと2番目のストアドプロシージャのプロダクションバージョンとの同期方法について説明します。災害復旧とバックアップ/復元に関しては、システムを稼働させるために、2つのデータベースの復元に注意する必要があります。

テスト時には、複雑さも追加されます。権限、バージョンなどに関して、より多くの障害点があります。データベースのさまざまなイニシアチブで複数の人が作業している場合、作業の調整により多くの時間を費やすことになります。今、午前3時を想像してください。システムがダウンし、すべてのデータベースの権限を探し回って、開発中に間違ったデータベースに関数やプロシージャを残さないようにする必要があります。

2つのデータベースを使用することをお勧めします。

「ライブ」データベースからレポートを取得すると、パフォーマンスの問題が発生します。

また、レポートデータベースは主に検索用であるため、パフォーマンスを向上させるためにここでインデックスをカスタマイズできます。（ライブデータベースには、特定のインデックスによって悪影響を受ける挿入があります）

別のアプローチは、レポートテーブルを別のスキームと別のファイルグループに移動することです。レポートファイルグループのファイルは、データハードディスクから移動できます。これにより、管理、将来の開発、およびアクセス管理が容易になります。