レポート目的でのテーブルの複製
レポート目的でサーバーBに複製するサーバーAのデータベースに5つのテーブルがあります。レポートのパフォーマンスを向上させるために、コピー先に異なるインデックスを作成したいと考えています。次のオプションを検討しました。
Always On可用性グループ（SQL Server 2012の機能）：ソースデータベースの読み取り専用コピーの作成のみを許可するため、これを使用できません。つまり、サーバーごとに異なるインデックスのセットを作成することはできません。
トランザクションレプリケーション：これは、実行しようとしていることを実装するのに適していますが、テーブルは非常に頻繁に更新されるため、サーバーのパフォーマンスへの影響は高くなると予想され、パフォーマンスの低下を回避することを目指しています。
毎晩のスナップショット：2つのデータベースを常に同期させる必要がないため、これも問題ない可能性があります。しかし、これにより、毎晩テーブルが再作成されます。つまり、毎晩インデックスも再作成する必要があります。すべてが1晩で完了する保証はありません。
私たちが思いついた他のカスタマイズされたソリューションは、2ステップのプロセスでした。最初に、Always ONメソッドを使用してサーバーBにデータベース全体を複製します。次に、サーバーBに別のデータベースを作成し、トランザクションレプリケーション方式で最初の宛先データベースを使用して複製します。これは同じ宛先に到達するためのより長い方法であることを理解していますが、これによりサーバーAのパフォーマンスへの影響を回避できます。サーバーBのパフォーマンスにはそれほど関心がありません。このソリューションは適切に聞こえますか？このソリューション？
過去にソリューション2を複数回実装したことがあり、非常に効果的であることが証明されています。
ただし、テーブルをレプリケートすることによるパフォーマンスへの影響を心配するのは正しいことです。レプリケーションが問題を引き起こしていないことを確認するために時間を費やす必要があります。考慮すべきことは次のとおりです。
ディストリビューターをホストする場所-レプリケートされたテーブルで実行されるDMLおよびDDLは、パブリッシャー（元のテーブルがある場所）からディストリビューターに渡されます。実際のコマンドは、別個の「配布」データベース内の一連の特別なテーブルに効果的にコピーされます。ディストリビューターは、この負荷に対処するのに十分強力でなければなりません。これはパブリッシングデータベースと同じインスタンスである可能性がありますが、OLTPまたはOLAPの場合は、別のマシンにスケールアウトする必要があります。
レプリケートするテーブルにスキーマを変更する頻度はどれくらいですか。スキーマの変更は可能ですが、レプリケーショントポロジでは悪夢になる可能性があります。これにより、スキーマの変更が必要になりますmuch今後はさらに注意が必要です。
レプリケートされたテーブルにどのくらいのデータが挿入/更新/削除されますか？レプリケーションは非常に高い負荷に対応できますが、基盤となるシステムはこれに対処できる必要があります（システムアーキテクチャの問題です）。レプリケーションはDMLとDDLを2番目のデータベースに効果的にコピーしているので、基本的に、レプリケーションなしの同じDBと比較して2倍のデータ（およびI/Oなど）を作成しているように見えます。
考慮すべきことは他にもたくさんありますが、これにより、ソリューション2を使用した場合に検討する必要があることを簡単に紹介できます。
現在、トランザクションレプリケーションを使用してデータの同期を維持しています。両方のサーバーに異なるインデックスがあります。レポートサーバーには、データファイルを格納するFusion ioドライブがあります。それはうまくいきます。
ミラーリングとスナップショットを組み合わせることもできます。
ミラーリングはデータベースの同期を維持し、その後、セカンダリデータベースからスナップショットを作成します。