Replication Debugging

Published on 29 October 2013 by in Replikasyon / Okunma: 1,447

0

Replikasyon çözümlerinde bazı zamanlarda hiç beklenmedik hatalar ile karşılaşılabilinir. Bunun için hata mesajlarından yola çıkarak iz sürmeye başlarız ve hata hiyerarşisinin en üstünden (Distribution) en alt seviyesine kadar (Veri) debug yapmamız gerekir. Örneğin eğer Transactional Replication ile replike edilen database’de ki tabloda bir value silinirse ve daha sonradan production’dan aynı value için bir update/delete isteği replike edilen database’e gelirse replication agent hata verip transaction’ları transfer etmeyecektir. Bu durumda aşağıdaki hata mesajı ile karşılaşabilirsiniz.

The row was not found at the Subscriber when applying the replicated command.

 

 

 

 

 

 

 

 

 

 

 

 

Debug yöntemi için yukarıdaki hata mesajı üzerinden devam edeceğz. Hata mesajından da anlaşılacağı gibi process’e alınacak kayıt replike olan database’den ya silinmiş veya değişikliğe uğramıştır. Bunun için Replication Debeugging yapmak gerekecektir. Çünkü Replication Monitor ile sadece replike olan database’lerden hangisinde bu hatanın alındığı bilgisine ulaşılabilinir. Yukarıda paylaştığım ekran görüntüsündeki Distributor To Subscriber History tab’ında gönderilen transaction’ın sequence number’ı belirtilmiştir. Debug işlemimizde bu sequence number’ı kullanmamız gerekiyor. Publish edilen her database’in, article’ın ve command’in distribution’da tutlan birer ID’si vardır. Önce bu tanımlamalara ulaşalım.

Bunun için Msrepl_commands‘ı kullanarak article_id‘mizi öğreniyoruz. Sorgu içerisinde almış olduğumuz hata mesajındaki command_id ve xact_seqno‘yu kullanarak filtreleyip execute ediyoruz.

SELECT b.[publisher_db], a.[article_id], a.[command_id] 
  FROM [MSrepl_commands] a
    INNER JOIN [MSpublisher_databases] b
            ON a.[publisher_database_id] = b.[id]
 WHERE a.[command_id] = 1 
   AND a.[xact_seqno] = 0x00065B7C000050B4000800000000

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Artık article_id’mizi yani modifikasyona uğrayan verinin hangi ID’li tabloda tutulduğunu bulduk.

 

 

Sıra geldi hata mesajını oluşturan veriyi bulmaya. Bunun için sp_browsereplcmds stored procedure’ünü kullanacağız. Bu SP yardımıyla replike edilecek database’e gönderilen veriyi okuyabileceğiz. sp_browsereplcmds içerisindeki parametreleri yukarıda elde ettiğimiz bilgiler ile doldurup execute ediyoruz.

USE [distribution]
GO

EXEC sp_browsereplcmds 
 @publisher_database_id = 1,
 @article_id = 31,
 @xact_seqno_start ='0x00065B7C000050B4000800000000',
 @xact_seqno_end ='0x00065B7C000050B4000800000000'

 

SP’yi execute ettiğimizde detaylı olarak transaction bilgilerine ulaşıyoruz. Burada dikkat etmemiz gereken command kolonudur. Bu kolon içerisinde production’dan replike olan tabloya gönderilen veri ve replike olan tablodaki şuanki veriyi görebiliyoruz.

 

 

command kolonunu genişlettiğimizde aşağıdaki gibi transaction bilgisine ulaşıyoruz.

CALL [sp_MSupd_dboUserObject] (,N’i.son‘,,,,,,,N’İ.son‘,0×0200000000000000000000)

UserObject iki taraftaki tablo ismimiz oluyor. Production’dan replike olacak database’e gönderilen veri “İ.son“. Fakat replike edilen database’de ki hali “i.son“. Zaman içerisinde replike olan database’de “İ.son” verisi için bir update uygulanıp “i.son” ‘a çevrilmiş.

Problemi yaratıp replication’ı durduran veriyi bulduk. Replikasyonu tekrardan başlatabilmek için verinin orjinal halini production’dan çekip modifiye etmeli veya replike olan database’de veriyi drop etmeliyiz. Gerekli güncellemeyi gerçekleştirdikten sonra son olarak UserObject article’ımızı re-initialize ederek replikasyonumuzu tekrardan başlatıyoruz.

 

 

Leave a Reply