SQL Serverレプリケーションを実装する時が来たことを示す客観的要因は何ですか？

データベースの高いパフォーマンスとメンテナンスの容易さのバランスをとろうとしています。レプリケーションを使用してパフォーマンスを向上させることを検討しています。SSRSレポートをトランザクションデータベースとは物理的に別のデータベースにレプリケートすることです。ただし、レプリケーションを有効にすることには、開発者の観点から多くの欠点があります。

• スキーマの変更が困難になります
• 自動統合/ビルドサーバーを妨害する
• SQLソース管理の実装が難しくなっているようです

私の質問は次のとおりです。これらの欠点を考慮して、レプリケーションに移行する時期がいつになると思いますか 追加の複雑さが利益を正当化するかどうかをどのように決定しますか？

以前に使用したことがあるので、設定は問題ありません。これは、それを有効にするかどうかを決定することに関するものです。他の人がレプリケーションで観察したいくつかのオブジェクトパフォーマンスメトリックを探しています。

もちろん、最善のことは、私たち自身のサーバーでいくつかのシミュレートされた負荷テストを行い、それを自分で理解することですが、私はそこにいくつかの一般的なガイドラインがあることを望んでいます。

レプリケーションは、アプリケーションの設計段階で検討する必要があります。地理的に分散した労働力/ユーザーベースがある場合は、地域データベースと中央データベースを持つことは理にかなっています。ラップトップ上の切断されたデータベースは、最終的にネットワークに再接続したときに「同期」できます（出張中の販売スタッフを考えてください）。

レポートの目的に関しては、レプリケーションは答えではありません。レポート環境におけるパフォーマンスの問題のほとんどは、レポートがオンライントランザクション処理（OLTP）用に構成されたシステムに対して書き込まれているという事実に起因しています。

レポート目的のレプリケーションは、OLTPデータを別のサーバーに移動するだけですが、同じレポートに適さない構造を維持します。本質的には、問題に対してより多くのハードウェアを投入し、メンテナンスコストを増加させますが、わずかな利益のためです。

注目すべきは、レポートに必要な特定のデータを取得し、それらをより有用な形式に変換する方法です。本番データベースから新しいトランザクションを取得し、レポートデータベース（できれば別のサーバー）に保存するフィードを作成します。フィードを実行するたびに、前回実行したときよりも新しいすべてのデータを取得し、そのデータを変換して保存する必要があります。現在実行しているレポートは、必要な変換のタイプについての良い考えを提供します。

このアプローチに従うことで、パフォーマンスの大きなメリットを享受できます。

レポートの作成者はレプリケートされたデータベースのインデックスを "所有"できるため、同じような状況でレプリケーションが役立つことがわかりました。これにより、INSERTSおよびUPDATESに悪影響を与えるためにアプリケーション開発者が本番環境で承認することのないインデックスを追加することで、クエリのパフォーマンスを向上させることができました。

多分あなたのユースケースの一部は、いくつかのトランザクションテーブルをコピーし、いくつかのインデックスを変更し、それが価値があるかどうかを確認することですか？

お役に立てれば！