SQL Server 複製方法
我在 SQL Server 中有一個相對較大的生產環境（150GB），我需要在其他地方複製它以進行查詢（特別是：我需要創建一個與生產相同的環境，以便查詢不會觸及實時生產環境 - 我使用“重複”一詞，因為我不想建議特定的方法）。
要求： 1- 伺服器只有 2 個核心和 32GB 記憶體，所以在硬體方面不是很先進。生產環境為 Standard SQL 2014，接收環境為 Enterprise SQL Server 2017。
2- 我需要良好的延遲（1 分鐘）：這意味著延遲不能超過一分鐘。
3-這只是單向複製。我不會在副本中進行更改，並希望它最終在生產中結束。這只是單向複製。
4-“實時”連接（意味著對產品所做的更改必須在 1 分鐘左右內發送回副本）
我做了什麼： 我想過做複製。但這是一個糟糕的主意，原因如下：a) 大多數表（有數百個）沒有 PK。我知道要進行複制，您需要 PK。b）有這麼多的表，所以很難將它們全部挑選出來進行複制。c) 我知道複製會給生產伺服器帶來很多負載。所以更輕的版本更好。
然後我看了看快照。我想知道是否可以同時使用兩者，如果不能，單獨使用快照是否足以滿足上述情況？任何幫助/方向將不勝感激。
**注意：**感謝您建議表需要 PK。我們都知道這一點，但是，這是一個供應商環境。添加 PK 是沒有問題的，請考慮作為上述要求。
事務複製最適合這種情況。
您的表應該有主鍵，這是事務複製的先決條件。發布者的負擔是最小的。大部分工作由分發者完成，分發者可以與發布者或訂閱者在同一個實例上，也可以是完全獨立的 SQL 實例。
如果您願意將生產數據庫升級到 SQL Server 2017 企業版，您可以使用 AlwaysOn 可用性組在輔助節點上創建可讀副本，無論是否加入 Windows Server 故障轉移群集中的伺服器。
正如@DavidBrowne 提到的，事務複製通常是最好的方法，您應該努力設計您的表以具有主鍵（這通常只是出於多種原因的最佳實踐）。
但當然，我們不能總是控制給定的數據，並且正如您所研究的那樣，對於缺少主鍵的表來說，快照複製是一個不錯的選擇。
您實際上可以實現一個使用事務複製和快照複製的混合解決方案。您的事務複製解決方案將接近實時（通常在一切正常工作的幾秒鐘內）。快照複製將生成一個 SQL 代理作業，該作業可以安排為每 1 分鐘執行一次（實際上您可以將時間腳本化為每秒一次 - 儘管取決於您的表有多大以及您的來源和分發伺服器的能力伺服器，您可能不希望它經常執行）。
混合解決方案將導致您創建兩個複制發布，一個用於源數據庫的事務複製發佈器，另一個用於同一數據庫的快照發佈器。在添加發布者嚮導的 UI 中，您將能夠為每個發布選擇適當的表。（事務發布將禁用缺少主鍵的表，因此不可能意外選擇錯誤的表。）
正如 David Browne 指出的那樣，發布伺服器（源伺服器）本身的負載相當輕。大多數工作發生在分發伺服器（以及分發伺服器數據庫所在的伺服器）上。因此，您可以選擇在您的源伺服器、目標伺服器或完全在它自己的伺服器上實現 Distributor 以分離性能問題。