老皮的程式筆記

發布者(負責把資料丟給另一台的)

訂閱者(負責接受複寫資料的DB，可能可以視為讀寫分離中 讀的那一台)

 

錯誤訊息: 项目的初始快照尚不可用。 (the initial snapshot for publication is not yet available)

- 解法1: 如果是新開的機器。可能要安裝SP4補丁檔。或某些更新(這方法對我沒用)

- 解法2:重建publisher & subscriber (我之前只是一直砍掉subscriber、一直沒效果。但是重建publisher就正常了)

 

如果有發生一些權限問題或訂閱端的錯誤訊息是無法遠程連結..

 

其他心得 (2023/1)

不確定是否有這樣的設計。partition的配置都沒同步過去 & index的同步似乎是寫完資料才處理?(如果是1000萬+筆)會很慘。

因此建議採去。先建好table & index。然後同步端設定>資料表已存在>則保留(?)還是blabla的那個設定。

但是還遇到了replication的資料表。有使用到truncate table來清資料。但是replication的資料表不支持此語法 (直到新版SQL似乎還是不能)

所以…最後暫時放棄了Replication的方案了。

 

發布端 (Publication)

要確保 [發布端] 複寫資料夾D:/SQL_Server/RepliData…. 類似這樣的路徑

• 網路資料夾分享
• everyone權限開啟(或更謹慎一點的控管)

如果索引(非叢集)也要同步。建置的時候。Article property 要設置 true
並且建議設定訂閱端(Subcribe)之前 

要先確定發布者(Publisher)這邊的SQL排程歷史紀錄，沒有出現錯誤

當針對大型table (千萬筆)的資料表設置Publication後。會開始產生sanpshot。CPU有明顯上升大概多了30%(因此建議還是在停機時段處理會比較安全)

 

 

查看發布者那邊的配置(更進階的砍掉重練是對著SSMS複寫分類按右鍵禁用全部)

select * from msdb..MSdistpublishers
select * from distribution..MSpublisher_databases
select * from distribution..MSpublications
select * from distribution..MSarticles
select * from distribution..MSsubscriptions

 

發布端的路徑要用UNI路徑

\\WIN-XXX-ServerName\repldata\

 

如果在訂閱端執行代理複寫行為一直行不通

可以改成在發布端執行代理複寫，或許就可以了(但我猜這種方式對主DB負擔較大?)