標籤彙整: Replication

[MS SQL Server]如何在Replication中新增Article時只建立新增的Article的Snapshot

發佈日期: 作者:
回覆

在 MS SQL Server 中, 已建立好的 Replication , 若是要新增 article 時, 可以參考這篇: http://tim.diary.tw/2009/02/27/adding-articles-to-existing-publications/ , 比較討厭的地方就是若是原來的 publication 內容多或是資料量大時, 在重做一個新的可用的 snapshot 會很久, 而且佔用很大的空間, (雖然只會將新增的 article 同步到 subscriber).

其實有個參數可以讓新增 article 到 publication 時, 只建立新增 article 的 snapshot, 這樣就會省時又省空間多了, 參數就是在 publication 中的 @allow_anonymous 及 @immediate_sync, 預設在建立 publication 時, 這兩個參數是 true, 我們可以利用 sp_changepublication 這個 stored procedure 來調整已建立的 publication 將參數改為 false 即可, 如下:


EXEC sp_changepublication
@publication = 'your publication name',
@property = 'allow_anonymous' ,
@value = 'false'
GO

EXEC sp_changepublication
@publication = 'your publication name',
@property = 'immediate_sync' ,
@value = 'false'
GO

如此一來, 在新增 article 到publication時, 就可以大幅減少建立整個 snapshot 的時間與空間了.

參考資料: http://www.mssqltips.com/sqlservertip/2502/limit-snapshot-size-when-adding-new-article-to-sql-server-replication/

[MS SQL]Replication架構下的資料庫變大問題

發佈日期: 作者:
回覆

前一篇提到: 如何在沒有distributor及subscriber的狀況下, 移除publication (MS SQL Server)  http://tim.diary.tw/2012/07/16/remove-publication-without-distributor-and-subscriber/

在 replication 的架構下, 若是 publication database 在 distributor 及 subscriber 不存在的狀況下, 該 publication database 在 backup 出來時的檔案, 將會愈來愈來大, 主要是因為讓 distributor 及 subscriber 回復時, 能再將未同步的資料寫回.

不過若是在 distributor 及 subscriber 下架, 又無法以正常的方式將 replication 架構移除時, 將會導致原來的 publication database 的備份愈來愈大, 解決之道當然是將該 replication 移除, 方式可以參考前面文章連結的內容.

若是資料庫備份有快速異常變大時, 可以參考看看!

如何在沒有distributor及subscriber的狀況下, 移除publication (MS SQL Server)

發佈日期: 作者:
1

有時候, 在測試環境下(當然生產環境下也有可能發生), 會因為某些原因, 在一組架構好的 replication 下, 沒有了 distributor 及 subscriber 的狀況下, 但 publication 還在時, 如何能移除該 publication.

使用 UI 操作的狀況下, 會回應沒有 distributor, 所以移除失敗等狀況, 所以得使用指令的方式來進行, 使用方式如下:


sp_replicationdboption @dbname= 'dbname',
@optname=  'Publish',
@value= 'false',
@ignore_distributor=  1

(參考 sp_replicationdboption 指令用法: http://msdn.microsoft.com/zh-tw/library/ms188769.aspx )

該資料庫(db)在沒有其他發行集(publication)的狀況下, 直接使用這個指令即可, 可以快速地將 publication 移除, 方便又好用!

使用備份來做起始化Replication-MS SQL

發佈日期: 作者:
回覆

交易式複寫從備份初始化，而非快照集 – http://byronhu.wordpress.com/2009/09/01/%E4%BA%A4%E6%98%93%E5%BC%8F%E8%A4%87%E5%AF%AB%E5%BE%9E%E5%82%99%E4%BB%BD%E5%88%9D%E5%A7%8B%E5%8C%96%EF%BC%8C%E8%80%8C%E9%9D%9E%E5%BF%AB%E7%85%A7%E9%9B%86/

How to: Initialize a Transactional Subscriber from a Backup (Replication Transact-SQL Programming) – http://msdn.microsoft.com/en-us/library/ms147834%28v=SQL.90%29.aspx

SQL Server的Replication中的Article必須要有Primary Key

發佈日期: 作者:
回覆

這個是朋友請我查的資料, 其實邏輯上還蠻容易的, 因為 SQL Server的Transactional Replication是參考table的primary key來進行新增刪除修改的, 若是該table沒有primary key的話, 是沒有辦法加入到publication的article裡的.

資料可以參考這裡:

http://msdn.microsoft.com/en-US/library/ms152559%28v=SQL.90%29.aspx

其中的:

Limitations on Publishing Objects

  • The maximum number of articles and columns that can be published differs by publication type. For more information, see the “Replication Objects” section of Maximum Capacity Specifications for SQL Server 2005.
  • Stored procedures, views, triggers, and user-defined functions that are defined as WITH ENCRYPTION cannot be published as part of SQL Server replication.
  • XML schema collections can be replicated but changes are not replicated after the initial snapshot.
  • Tables published for transactional replication must have a primary key. If a table is in a transactional replication publication, you cannot disable any indexes that are associated with primary key columns. These indexes are required by replication. To disable an index, you must first drop the table from the publication.
  • Bound defaults created with sp_bindefault (Transact-SQL) are not replicated (bound defaults are deprecated in favor of defaults created with the DEFAULT keyword of ALTER TABLE or CREATE TABLE).

 

上面紅字部分就是說明這個限制.

 

SQL Server如何新增article到publication

發佈日期: 作者:
回覆

在使用 Replication 時, 若是使用 Transaction 的方式, 若有要新增 article 到 publication 時, 其實很容易.

基本上就只要在原來的 publication 的 property 裡的 articles, 多加上需要 replication 出來的article, 完成後, 他不會自動進行後續, 接下來的動作就是做 snapshot 就行了, 這裡比較討厭的是若是原來的publication資料多, 而加入的 article資料少, 其實很不划算, 不過做完 snapshot 後, replication 機制會開始將該新發行的article schema傳給 subscriber, 讓 subscriber 將沒有的資料寫入, 這樣就完成了.

其實只會做新的部分, 不過因為還是要一個 schema及起始資料, 所以還是得做一個 snapshot 是比較吃資源的地方, 和 alter table的狀況又不太一樣了. 不過操作上還是很直覺也很方便!

參考SQL Server 2005 help 資料: http://msdn.microsoft.com/en-us/library/ms152493(SQL.90).aspx

其中比較重要的是這段:

After adding an article to a publication, you must create a new snapshot for the publication (and all partitions if it is a merge publication with parameterized filters). The Distribution Agent or Merge Agent then copies the schema and data for the new article to the Subscriber (it does not reinitialize the entire publication).

也就是說, 新增完了之後, 要做一次 snapshopt, 不過 agent 會將新的 article 送到 subscriber, 而不會整個 reinitialize!

SQL Server Replication下的異動資料表

發佈日期: 作者:
回覆

若是SQL Server已設定完成Replication的Article時, 進行資料表異動, 其實會透過 DDL 傳送的方式, 將異動的指令也透過複寫的方式送出, 並進行同步. 可以參考相關文章: http://www.replicationanswers.com/AlterSchema2005.asp

不過若是異動的欄位是 Primary Key時, 將會觸發 exception, 發出如下的訊息:

Msg 4929, Level 16, State 1, Line 2
Cannot alter the table ‘tbltest’ because it is being published for replication.

如此一來便無法使用這種 ddl 傳遞的方式將 Replicated Table 的異動送出. 若是要執行這樣的異動需求, 得先解除掉發行及訂閱此 table, 才能進行調整, 調整完成後才能再重新設定回發行及訂閱, 接下來再做 snap shot 進行遞送出去.

SQL Server Transactional Replication注意參數(max text repl size)

發佈日期: 作者:
回覆

在使用 SQL Server Replication 發行資料時, 有個重要的參數必須要特別注意的地方, 就是 max text repl size, (在 SQL 2005也會影響 varchar(MAX) 這種型態的欄位).

參考這篇 最大文字覆寫大小選項 的設定方法來進行調整(利用 sp_configure).

另外在這篇 交易式複寫考量 也有說明在使用 Replication 時, 要注意覆寫資料的 size 上限, 若是在寫入資料大於該設定的 size 時, 將會發生 error, 內容如下:

Length of LOB data (??????) to be replicated exceeds configured maximum 65536

如此一來便會造成寫入失敗而無法成功寫入資料, 這在沒有使用 交易式複寫 時不會發生的問題. 這在使用交易式複寫時要特別注意的地方!

SQL Server Replication預設不會複製nonclustered index

發佈日期: 作者:
回覆

在使用 SQL Server Replication 機制時, 要特別注意有關複寫參數的部分, 由於預設是不會複製 noclustered indexes的, 所以在使用上要特別注意這點. 這樣的預設有好有壞, 好處是複寫出來到訂閱者資料庫的彈性相當大, 可以依需要再進行 index 設計及應用, 壞處是若管理人員或使用人員沒有發現, 在使用上將會有某種影響訂閱者資料庫的效能!

閱讀全文 →