レポート用のSQL Serverデータベースの読み取り専用レプリカの作成
すべてのクエリを最適化しても、.Net Webアプリケーションの動作が遅いと問題が発生しました。レポートを作成している別の開発者が判明したように、最適化されていない一連のクエリが常に実行されています。そこで、私は彼のために別のサーバーを作成することにしました。現在、バックアップを作成し、それを別のサーバーにコピーして復元するジョブを作成しました。しかし、これは一時的な解決策であるため、2番目のサーバーが最新のデータを取得するため、または少なくとも遅延を最小限に抑えるために、読み取り専用のレプリカを作成する機会を調査しています。
私はDBAではないので、SQL Serverのレプリケーションメカニズムに関する記事をたくさん読んだことがあります。私にとって最良のオプションは、自分のPROD Webアプリケーションがレプリケーションの影響をまったく受けない場合です。つまり、同期テーブルに多くのロックがかかることになります。ミラーリングのようにリアルタイムの同期は必要ありません。また、キングのクラスターソリューションも必要ありません。ただPRODデータベースの同期コピーを読み取るだけです。したがって、非同期配布ポリシー（スケジュールどおり）を使用したTransactionalレプリケーションメカニズム（更新不可）を選択しました。
だから私はいくつかの質問があります：
トランザクションレプリケーションは、SQL Serverレプリケーションメカニズムの中で最も問題に適していますか？
SQL Server 2008からSQL Server 2012に移行するopportunitがある場合、トランザクションレプリケーションに重大な変更がありますか？エラーが発生する可能性があるという technet の記事を読みましたか？
SQL Server 2012ではない
Always On問題を解決するためのより良いメカニズム（2008 R2をまだ使用していて、まだ2012年への移行が計画されていないため、このオプションを最後のオプションとして検討しています）？
トランザクションレプリケーションは、SQL Serverレプリケーションメカニズムの中で最も私の問題に適していますか？
すべてのレプリケーションオプションのうち-トランザクションは、ここで最も役立ちます。レイテンシが最小限に抑えられ、双方向である必要はありません（ただし双方向である必要はありません）。変更をマージするのではなく、ピアツーピアは必要ありません。
とはいえ、レプリケーションは「無料」ではありません。レプリケーションを管理および監視する必要があり、不適切な設定はパフォーマンスの問題を悪化させる可能性があります。パフォーマンスの最適なオプションとパフォーマンスの最適な設定について学び、それを念頭に置いて、レプリケーション環境を監視し続ける必要があります。
トランザクションレプリケーションは、マージレプリケーションよりも「簡単」です。しかし、それはあなたがいつもスムーズな航海をするという意味ではなく、複製の経験を持つ誰かが助けなくても常に逃げることができるということです。
SQL Server 2008からSQL Server 2012に移行する機会がある場合、トランザクションレプリケーションに重大な変更がありますか？エラーが発生する可能性があるというtechnetの記事を読みましたか？
残念ながら、これは「依存する」タイプの質問です。理論的には私たち自身の経験から答えを出すことができますが、テストする必要があります。問題にぶつかった場合、それらは必ずしも修正できない不可能な問題ではなく、テストと調整が必要になります。
SQL Server 2012 Always Onメカニズムは私の問題を解決するのに優れていますか？
SQL Server 2012では、AlwaysOnが潜在的に機能する機能を備えています。可用性グループは、読み取りのためのアクティブセカンダリの概念を備えた回答です。ただし、ライセンスに関する懸念事項があります。プライマリと読み取り専用/アクティブなセカンダリの両方でエンタープライズにいる必要があります。レプリケーションアプローチでは、両端でライセンスを取得する必要がありますが、これは確かに良いオプションです。また、それに関連するオーバーヘッドと、いくつかの管理上の懸念事項について学ぶ必要がありますが、優れた選択肢となります。
ミラーリングのようにリアルタイムの同期は必要ありません。また、キングのクラスターソリューションも必要ありません。ただPRODデータベースの同期コピーを読み取るだけです。
マイクが述べたように、T-Repは無料ではありません。ディストリビュータデータベースを維持する必要があり、ログリーダーエージェントに依存している。パブリケーションで発生する変更の量が大きく、ネットワーク遅延に依存する場合、ログリーダーエージェントがスキャンしてサブスクライバーに送信するのを待機するコマンドがディストリビューションデータベースに蓄積されます。スキーマの変更には新しいスナップショットが必要です-これにより、スナップショットが完了するまでパブリケーションデータベースがロックされます。また、データのサブセット（選択したテーブル、SPなど）とは対照的に、データベース全体のレプリケーションでは、そのメンテナンスに関連する問題が発生することがよくあります。
あなたの状況に基づいて、logshippingをお勧めします。セットアップが簡単で、依存関係は最小限です（ネットワーク共有-適切な権限が必要です）。
ログシッピングの良い点は、STANDBYモードでセカンダリデータベースを読み取り専用にできることです。
注：STANDBYオプションを使用してログ配布を使用する場合、セカンダリデータベースをプライマリよりも新しいバージョンのSQLサーバーに配置することはできません。
トランザクションレプリケーションの良い点としてマイク。同様の状況があり、現時点でトランザクションレプリケーションを機能させようとしていますが、機能していますが、削除と挿入が大量に発生していることがわかっている記事を追加すると、ディストリビューションDBがパブリッシャー側で停止します（これはトランザクションレプリケーションの注意点の1つです）。これは私の質問です：
SQL Serverトランザクションレプリケーションディストリビューションデータベースが追いついていない
私はまだディストリビューションDBがパブリッシャーで追いついていない理由を理解しようとしています。うまくいけば、環境がこれらの多くの変更を生成せず、トランザクションレプリケーションで大丈夫なはずです。それが、あなたのアプローチに最適であると思われるからです。