原文: Replication的犄角旮旯（七）-- 一個DDL引發的血案(下)（聊聊logreader的延遲）

?

?

《Replication的犄角旮旯》系列導讀

Replication的犄角旮旯（一）--變更訂閱端表名的應用場景

Replication的犄角旮旯（二）--尋找訂閱端丟失的記錄

Replication的犄角旮旯（三）--聊聊@bitmap

Replication的犄角旮旯（四）--關于事務復制的監控

Replication的犄角旮旯（五）--關于復制identity列

Replication的犄角旮旯（六）-- 一個DDL引發的血案(上)（如何近似估算DDL操作進度）

Replication的犄角旮旯（七）-- 一個DDL引發的血案(下)（聊聊logreader的延遲）

Replication的犄角旮旯（八）-- 訂閱與發布異構的問題

Replication的犄角旮旯（九）-- sp_setsubscriptionxactseqno，賦予訂閱活力的工具

---------------------------------------華麗麗的分割線--------------------------------------------

?

前言：這是昨天剛剛發生的案例，盡管事件的起因只是一個簡單的DDL操作，但影響面和影響時間可以說是大大超出了預期；我們將在描述本案例的前因后果之后，聊聊如何近似估算DDL的操作進度，以及關于logreader延遲的問題；

前一篇文章《Replication的犄角旮旯（六）-- 一個DDL引發的血案(上)（如何近似估算DDL操作進度）》

http://www.cnblogs.com/diabloxl/p/3844205.html

前因簡述：

一個復制節點（即使上級的訂閱，又是下級的分發）需要對一個表進行DDL操作，由于需要修改主鍵，因此將這個表從publication中刪除，然后就開始了漫長的DDL操作……

本來需要進行DDL操作的表已經從replication中摘除了，以為不會影響到其他article的復制，結果慘劇還是發生了，原因依舊是VLF對logreader的影響，但這次的問題和以往又有些不同……

?

=====================華麗麗的分割線=====================

先說說之前遇到的logreader延遲的情況：

1、發布表的寫操作

　　這里又分為兩種情況

　　a)大量并發寫操作：指大量的小DML操作，特點是事務小、并發多

　　b)大事務寫操作：指有單個大事務操作，特點是事務大、并發少

2、非發布表的寫操作

　　指有寫操作的表并不是需要復制的表，這里將上述a\b兩種情況合并在一起說，這次遇到的是b這個類型；

?

檢查logreader的延遲的利器——sp_replcounters

MSDN上關于這個存儲過程的解釋：

http://msdn.microsoft.com/zh-cn/LIBRARY/ms190486

無論對于上述哪種情況，如果 Replicated transactions 持續增加，那就是logreader延遲了，初步的現象就是這個發布下所有的訂閱都在延遲；

那上述3種情況的差異呢?

　　對于1a)?

Replicated transactions 快速增加，replbiginlsn和replnextlsn都會較慢速度的變化；（這里的慢速是相對與正常速度而言，受實際業務環境影響，下同）

　　這是由于大量的小DML操作都會快速的提交，但由于大量的日志寫入，導致存在大量的活動VLF，因而日志不能被截斷；同時，盡管logreader根據replnextlsn去定位下一個要復制的lsn，但由于效率下降，且后面涌入的新事務也在增長，導致惡性循環，從而引起logreader的延遲；

　　對于1b)

Replicated transactions 慢速 增加，replbiginlsn不變、replnextlsn不變；

　　雖然事務并發量很小，但由于單個提交的事務很大，仍然導致大量的活動VLF，從而引起logreader效率下降；

　　對于2

Replicated transactions 快速增加，replbiginlsn不變、replnextlsn慢速變化；

　　由于非復制的表也需要寫日志，且占用了大量VLF，因此logreader需要從大量的VLF中獲取需要復制的日志信息，這也同樣影響到它的執行效率；

?

那我們該如何應對呢？

　　硬件當然是最有效的手段之一，升級內存、磁盤換成IO卡等可以解決根本問題，但這又不是絕對，一個SQL跑死服務器的情況也絕非不可能；

　　1、對于1a的情況，建議有頻繁寫操作的表，還是能分就分，或者分到多個庫中，或者分到多個實例下，原則就是不要讓logreader干太多活，畢竟的是個單線程的任務，穿少了也cool，喝多了也吐。

　　2、對于1b的情況，本身單個大事務就不是OLTP環境中提倡的，不光是復制延遲，光一堆鎖估計機器也受不了；建議拆成多個事務來跑；

　　3、對于2來說，盡管要搞的表和復制沒有任何關系，但不能忽略VLF對logreader的影響，既然在一個庫中，公用日志序列，還是小心為妙；如果是大表的DDL的操作，還是通過停寫、建新表、導數據的方法實現，bulk insert的方式或許是對日志影響最小的；

　　但bulk insert的方式一般要求停寫，而受業務的制約，可能不允許長時間的停寫，這該怎么破？

　　可以看看我之前的文章《 Replication的犄角旮旯（一）--變更訂閱端表名的應用場景 》，復制回路可以說是為這種需求量身定做的~

?

Replication的犄角旮旯（七）-- 一個DDL引發的血案(下)（聊聊logreader的延遲）