SQLSERVER復制
服務器角色：發布服務器、分發服務器、訂閱服務器
復制代理程序：快照代理程序、分發代理程序、日志讀取器代理程序、合並代理程序、隊列讀取器代理程序
復制的類型：快照復制、事務復制、合並復制
訂閱類型：推送、請求
事務復制：通過激發觸發器把數據的更改發送到訂閱服務器
默認情況下，事務發布的訂閱服務器應視為只讀，因為更改將不會傳播回發到發布服務器
在一般情況下，當使用事務發布時，如果發布服務器和訂閱服務器都對數據進行了更新，那么將以發布服務器的事務為准，覆蓋訂閱服務器對數據的更改
-------------------------------------------------------------------------------------------------------------------------
合並復制：與事務復制相同，合並復制通常也是從發布數據庫對象和數據的快照開始，並且用觸發器跟蹤在發布服務器和訂閱服務器上所做的后續
數據更改和架構修改。訂閱服務器在連接到網絡時將與發布服務器進行同步，並交換自上次同步以來發布服務器和訂閱服務器之間發生更改
的所有行
合並復制通常用於服務器到客戶端的環境中，合並復制適用於下列各種情況：
（1）多個訂閱服務器可能會在不同時間更新同一數據，並將其更改傳播到發布服務器和其他訂閱服務器
（2）訂閱服務器需要接收數據，脫機更改數據，並在以后與發布服務器和其他訂閱服務器同步更改
（3）每個訂閱服務器都需要不同的數據分區
（4）可能會發生沖突，並且在沖突發生時，需要具有檢測和解決沖突的能力
（5）應用程序需要最終的數據更改結果，而不是訪問中間數據狀態。例如，如果在訂閱服務器與發布服務器進行同步之前，訂閱服務器
上的行更改了5次，則該行在發布服務器上僅更改一次來反映最終數據更改，即第五次更改的值。
簡單來講，就是訂閱服務器不是只讀的，用戶既可以修改發布服務器上的數據，也可以修改訂閱服務器上的數據，然后兩者
的修改都會進行合並
-------------------------------------------------------------------------------------------------------------------
訂閱
推送：發布服務器將更改傳播到訂閱服務器，而無需訂閱服務器發出請求。數據更新可以按需、連續地或按照計划推送到訂閱服務器。分發代理或合並
代理在分發服務器上運行
使用場合：
數據將連續同步或按照經常重復執行的計划同步
發布要求數據近似實時地移動
分發服務器上較高的處理器開銷不會影響性能，換言之分發服務器的CPU處理能力一定要高，分發服務器配置一定要高
通常與快照和事務性復制一起使用，換言之快照和事務復制一般使用推送
請求：訂閱服務器請求在發布服務器上所做的更改。請求訂閱允許訂閱服務器上的用戶確定同步數據更改的時間。分發代理或合並代理在訂閱服務器上運行
使用場合：
數據通常根據需要進行同步，而非連續同步
訂閱數量多，或在分發服務器上運行所有代理會消耗大量資源
訂閱服務器是自主的、非實時連接的或移動的。訂閱服務器將確定連接和同步更改的時間
通常與合並復制一起使用
----------------------------------------------------------------------------------------------------------------------------
配置復制的步驟：
（1）標識分發服務器，在分發服務器上創建分發數據庫
（2）配置發布服務器，准備發布的數據
（3）創建訂閱，啟用接收發布數據的訂閱服務器
---------------------------------------------------------------------------------------------------------------------------
復制前的考慮：
（1）為了提高執行效率，可以限制訂閱服務器獲得的所有數據，或僅發布訂閱者真正需要的數據或訂閱者有權得到的數據
（2）在實現快照復制之前，為快照復制留出充足的磁盤空間
（3）在實現事務復制之前，分配足夠的日志空間，為分發數據庫留有足夠的磁盤空間
（4）為每一個表創建主鍵
（5）實現合並復制前移去timestamp列，由於訂閱服務器的數據也會傳遞到發布服務器，應確保數據的完整性在各個訂閱服務器上
都能得到保證，維護表之間的關聯參照
（6）在所有IDENTITY屬性字段上加上NOT FOR REPLICATION設置，以保證SQLSERVER在復制代理程序所添加的行上保留起始標識值，
但是繼續在其他用戶所添加的行上增加標識值。當用戶將某個新行添加到表時，標志值以通常的方式增加。當復制代理程序將該新行復制到
訂閱服務器時，再將該行插入到訂閱服務器表中時不更改標識值
-----------------------------------------------------------------------------------------------------------
“Not for Replication”屬性也適用於發布方和訂閱方的Check約束、外鍵約束和標識列-Identity Column上
我的理解：比如有一張表orders表,orders表有一列recordno 自增，發布方有這張表，訂閱方也有這張表，當前有兩個訂閱，一個發布
只需要在發布方的orders表里的recordno列設置NOT FOR REPLICATION就可以了
1 USE [tempdb] 2 GO 3 CREATE TABLE ttt(id INT IDENTITY NOT FOR REPLICATION NOT null ,NAME nvarchar(200)) 4 GO 5 INSERT INTO [dbo].[ttt] ( id,[NAME] ) 6 VALUES (6, N'sdf') 7 --DROP TABLE ttt
不過只能夠在合並復制里面用
1 消息 544，級別 16，狀態 1，第 1 行 2 當 IDENTITY_INSERT 設置為 OFF 時，不能為表 'ttt' 中的標識列插入顯式值。
然后你做一次快照復制，訂閱里的orders表里的recordno列自動會有NOT FOR REPLICATION屬性
當訂閱#1插入了一條記錄，recordno為2，訂閱#2插入兩條記錄，recordno為2和recordno為3，那么同步的時候，就會把recordno1
和recordno2和recordno3的記錄插入到發布方里的orders表
recordno
2
2
3
而不是
1
2
3
不過這樣做的話就會造成recordno有重復值，所以這時候不能將recordno設置為主鍵
當然了，當把recordno設置為NOT FOR REPLICATION之后就能手工插入自增值
參考文章：《解析“Not for Replication”》http://blogs.msdn.com/b/apgcdsd/archive/2012/04/25/not-for-replication.aspx
---------------------------------------------------------------------------------------
一般來說，復制包括以下幾個階段：配置發布，生成和應用初始快照，修改復制數據，以及同步和傳播數據
分發服務器是快照復制和事務復制的首要組件，用於代理程序歷史記錄和監視。分發服務器可以是與發布服務器不同的獨立服務器
也可以是同一台服務器
----------------------------------------------------------------------------------------
關於SQL AGENT服務
復制過程中，各代理程序的調度由SQL SERVER AGENT服務管理，應配置SQL SERVER AGENT服務能夠在系統
啟動的時候自動啟動，並且在意外停止時能夠自動重新啟動，由於復制操作跨越多個服務器傳輸數據，所以
SQLSERVER AGENT服務的啟動帳號應使用域用戶賬號
-----------------------------------------------------------------------------------------
只發布必要的表或字段
發布項目可以是表中的全部數據或者部分數據，也可以是數據庫對象，如存儲過程、視圖
在事務發布中，只允許發布有主鍵的表，用戶還可以選擇發布這張表中指定的字段
----------------------------------------------------------------------------------------
定制性能標准
配置復制后，建議定制一個性能標准，以便確定復制在通常用於應用程序和拓撲的常見工作負荷中的行為方式。
例如：
（1）滯后時間：在復制拓撲中的節點之間傳播數據更改所用的時間
（2）吞吐量：在某段時間內系統可以維持的復制活動量（用在某個時間段內傳遞的命令來度量）
（3）並發：可以在系統上同時運行的復制進程數
（4）同步持續時間：完成給定同步所用的時間
（5）資源消耗：用於復制處理的硬件和網絡資源
復制監視器提供了設置復制事件警報的一種方法，當事件發生時，復制監視器可以自動響應，觸發警報，執行管理員定義的任務或向某人發送電子郵件或傳呼信息
----------------------------------------------------------------------------------------------------
提高常規復制的性能
復制經常用於在遠程SQLSERVER之間進行數據分發，用戶應當考慮SQLSERVER服務器和網絡硬件、數據庫設計、分發服務器配置
發布設計和選項、快照選項、訂閱選項等對性能的影響。為了最大限度地提高復制的性能，請從下面着手提高復制的性能：
1、服務器和網絡
（1）使用多處理器系統
復制代理可以利用服務器上的附加處理器。如果執行復制時CPU占用率高，則需要安裝更快的CPU或多個CPU
（2）設置SQLSERVER的最小內存使用內存
默認情況下，SQLSERVER根據可用系統資源動態地改變其內存需求。為避免服務器內存競爭使用，
對服務器設置“最小服務器內存”選項設置最小可用內存。如果服務器的角色是遠程分發服務器或是發布服務器和分發服務器的組合，則必須
分配至少16MB的內存
（3）使用單獨的磁盤放置復制中涉及的所有數據庫
將數據文件與事務日志存儲在不同的磁盤驅動器上，可減少寫日志所需的時間。如果
需要容錯，可以使用RAID1鏡像該驅動器。其他數據庫文件用RAID0或RAID0+1存儲
（4）使用速度快的網絡
網絡可能是一個重要的性能瓶頸，尤其是對於事務復制而言。通過使用每秒100兆位（Mbps）或更快的網絡，可以
顯著提高將更改傳播到訂閱服務器的速度
2、數據庫的設計
（1）訂閱服務器上的索引的設計
在使用事務復制、合並復制時，訂閱服務器上使用索引時應謹慎。應為訂閱服務器上的主鍵列建立索引，但附加的索引
可能影響插入、更新和刪除操作的性能
（2）訂閱服務器中的觸發器
在使用事務復制、合並復制時，在訂閱服務器上的用戶定義觸發器中使用業務邏輯可能會降低將更改復制到訂閱服務器的速度
（3）限制使用大型對象（LOB）數據類型
LOB（數據類型為text、ntext、image）比其他列數據類型需要更多的存儲空間和處理。除非
應用程序需要，否則不要在發布項目中包括這些列
（4）訂閱服務器數據庫使用簡單恢復模式
簡單恢復模式允許在訂閱服務器上應用快照時執行最少的大容量插入日志記錄
3、發布和訂閱設計
（1）只發布需要的數據
發布超出實際需要的數據會使分發數據庫和快照文件中耗費額外資源，
應該避免發布不必要的數據表並考慮不要過於頻繁地更改發布
（2）僅在必要時和非高峰時段運行快照代理
快照代理將發布服務器上的數據復制到分發服務器的“快照”文件夾中，生成快照依然
是消耗大量資源的進程，所以最好在非高峰時間調度
（3）將快照文件夾放在分發服務器上不用於存儲數據庫或日志文件的本地驅動器中
快照代理將按順序將數據寫入快照文件夾。將快照文件夾放在與數據庫
或日志文件分開的驅動器上可以減少磁盤間的爭用，並有助於快照進程更快地完成
（4）連續運行代理程序代替過於頻繁地調度
設置“連續運行代理”程序而不是創建“頻繁調度”（如每隔一分鍾）將提高復制性能。
當設置分發代理程序或合並代理程序連續運行時，無論更改何時發生，都能立即傳播到訂閱服務器上
（5）考慮使用請求訂閱
當存在大量訂閱服務器時，應使用請求訂閱。分發代理和合並代理在分發服務器上運行以實現推送訂閱，在訂閱服務器上
運行以為實現請求訂閱。使用請求訂閱可以提高性能，因為他將代理從分發服務器移到了訂閱服務器上。