我們有一個體面大小，寫入重量大約爲426 GB（包括索引）和大約3億行的數據庫。我們目前每隔幾分鐘就會收集一次設備報告給我們的服務器的位置數據，而我們則爲大約10,000臺設備提供服務 - 每秒鐘都會有大量的寫入。存儲每個設備位置的位置表大約有2.23億行。數據目前按年存檔。用於寫入重磅中型數據庫的事務複製
當用戶在這個數據庫上運行大型報告時，會發生問題，整個數據庫幾乎停滯不前。
我知道我需要一個報告數據庫，但我的問題是，如果任何人都有使用SQL Server事務複製對同等大小的數據庫的經驗，以及他們使用這種技術的經驗？
我的粗略計劃是將我們應用程序中的所有報告指向報告數據庫，使用事務複製將數據從主數據複製到從數據庫（報告數據庫）。
任何人對此策略有任何想法和我可能遇到的問題？
非常感謝！
在這種情況下事務複製應該可以正常工作（數據庫的大小的唯一影響是生成初始快照所需的時間）。但是，它可能無法解決您的問題。
我認爲如果您選擇事務複製，您將遇到的問題是，應用更改時，從服務器將與主機承擔相同的負載 - 當用戶運行大型報告時（假設它有相似的規格）。
根據報告數據到實時數據的可接受延遲，這可能會或可能不會爲您的用戶。
如果某些延遲時間是可以接受的，您可能會從日誌傳送中獲得更好的性能，因爲批量應用了更改。
在獲取報告服務器之前，另一種方法是調查用戶正在運行的查詢，並查看修改其代碼或索引策略以更好地匹配他們嘗試執行的操作。
事務複製可能適合您。需要考慮的事項：
通過從OLTP數據庫的備份中初始化報告數據庫，可以跳過對快照的折磨。請參閱https://msdn.microsoft.com/en-us/library/ms151705.aspx
將從複製到INSERT/UPDATE/DELETE通信到分發和訂閱者數據庫。這需要考慮，但鎖定/阻止問題應該不會比從OLTP運行這些報告更糟（也可能更好）。
我在2.6TB數據庫上以2.5GB /天的增長運行多個發佈，使用純粹的事務驅動報告（對兩個報告服務器）和對等事務處理來在擴展中複製數據爲SaaS產品提供服務（再增加三臺服務器）。正因爲如此，我們有一個單獨的分銷商。
希望這會有所幫助。
謝謝 約翰。