SQL Server Replication İlgili Notlar

Bu yazıda SQL Server Replication ile ilgili forumlarda veya site üzerinden gelmiş olan sorulara verdiğim yanıtları ve deneyimlerimi paylaşıyor olacağım.
1 – “Error 14114: (NULL) is not configured as a distributor” hatası

Bu hatanın alınmasının nedeni local sunucunun remote server olarak tanımlanmamış olmasıdır. Nitekim select @@servername ifadesi null döndürecektir. Eğer sysservers tablosunda kayıt var ise sp_dropserver ‘SunucuAdi’,’droplogins’ ifadesi çalıştırılıp ilgili sunucu kaydı silinir. Ardından aşağıdaki gibi yerel sunucu eklenir;

sp_addserver ‘YerelSunucuAdi’, ‘local’

Daha sonra servis yeniden başlatılır.

2 – Replike edilen bir tabloya yeni bir kolon eklemek veya var olan bir kolonu çıkarmak veya kolonun tipini değiştirdiğimizde o tablonun replike ediliği otomatik abonelerin yeniden initialize edilmesi gerekir. Bu durumda abonedeki tablo drop edilir yeniden create edilip ardından bulk insert yapılır.

3 – Bazı durumlarda distributor tarafındaki UPDATE işlemi Subscriber tarafında DELETE / INSERT olarak uygulanabilir. Bunun nedeni değişen alanın üzerinde unique constraint olmasıdır. Konuyla ilgili olarak aşağıdaki sayfa incelenebilir.
http://support.microsoft.com/kb/238254

4 – Snapshot folder olarak share edilmiş bir alanın verilmemesi veya Subscriber’ların erişmeyeceği bir alanın verilmesi ancak push subscription’a destek verir. Network path vermek daha mantıklı olacaktır.Network pathin verilmesi durumunda bu share folderin pull subscription gibi diğer makinelerde çalışan agentler tarafından erişilebiliyor olması gerekir.

5 – Bir aboneyi yaratırken manual mi yoksa otomatik mi Initialize edileceği belirtilir. Eğer manual olarak set edilmiş bir abone ise o anda veya daha sonra kaynak sunucunun o sunucuyu ilklendirilmesi sağlanamaz. Reinitialize etmek için o aboneyi drop edip yeniden create etmek lazım. Eğer otomatik olarak set edilmişse Replication » Publications bölümü altındaki aboneyi sağ tıklayıp Reinitialize menüsünü seçtiğimizde yeniden ilklendirilmiş olur. Eğer manual yöntemini tercih etmişsek replike edilecek tabloları ve replikasyon prosedürelerini aboneler üzerinde oluşturmak lazım. Örneğin üzerinde replikasyon prosedürlerinin yaratılmadığı aboneyi senkronize etmek istediğimizde Could not find stored procedure ‘sp_MSins. gibi bir hata alırız. Replikasyon prosedürlerine ait scripti oluşturmak için publish edilmiş olan database üzerinde
sp_scriptpublicationcustomprocs [ @publication = ] ‘publication_name’
prosedürü kullanılır. Bu prosedür her tablolar için çalışacak olan INSERT, UPDATE ve DELETE prosedürlerinin içeriğini oluşturur. Üretilen SQL scripti abone üzerinde çalıştırmak yeterli olacaktır.

6 – Manual initialization işleminde dikkat edilmesi gereken en önemli konu kaynak veritabanı üzerinde önceki kayıtlarda yani abonede olmayan kayıtlarda bir değişiklik olursa abonede o kayıt olmadığı için UPDATE / DELETE işlemi hata verecektir. “‘The row was not found at the Subscriber when applying the replicated command.'” hata mesajıyla karşılaşılır. Bu kayıt abonede oluşturulmadığı sürece yani bu hata giderilmediği sürece replikasyon o noktada takılıp devam etmeyecektir.

Eğer replikasyonun yapıldığı sistemler SQL Server ise aboneler üzerinde her tablo için “sp_MS.” ile başlayan INSERT/DELETE/UPDATE procedure’leri oluşturulur. Bu prosedürlerin aldığı parametreler o tablonun o anda replikasyona dahil edilmiş olan kolonlarına göre oluşturulur. Eğer daha sonradan tabloların şemaları değişirse veya replikasyonda kolon ekleme/çıkarma olursa bu prosedürleri yeniden abonelerde oluşturmak gerekir. Eğer replikasyon heterojen sistemler arasında yapılırsa yani SQL Server – Oracle arasında yapılırsa o zaman subscriber olan Oracle üzerinde bu prosedürler oluşturulmaz (“Heterogeneous Database Replication“). Normal UPDATE, DELETE, INSERT SQL cümleleri gönderilir. Abonelere gönderilecek komutlar MSrepl_commands ve MSrepl_transactions tablolarında binary formatında tutulur.

7 – Replikasyon işleminde Distribution hataları atlamak.

Replikasyon, Publisher’da meydana gelen her transaction Distributor’a gönderilir. O da ilgili Subscriber’a gönderir. Bu süreçte INSERT / UPDATE / DELETE işlemlerinde birinde hata meydana gelirse o işlem rollback edilir veya sonraki transactionlar işlenmez. Bu şekilde herhangi bir hatanın meydana gelmesi durumunda o hatayı görmemezden gelip sonraki transactionların abonelerde uygulaması için “Distribution Agent” için -SkipErrors parametresi kullanılabilir. Bu parametreye o hata veya hataların numaraları girilerek o hataların görmemezlikten gelinmesi sağlanabilir. Bunun için “Publisher and Distributor Properties” penceresindeki Distributor sekmesinde Agent Profiles tıklanarak yeni bir profil tanımlanır. Replikasyon agent’lerin çalıştığı default profile göre hatanın olması durumunda sistem devam etmez. SkipErrors değerinin karşısında mevcut hata numaralarının yazıldığı bir profil yaratılır ve servis yeniden başlatılarak bu profilin devreye girmesi sağlanır. Hata giderildikten sonra yeniden default profile kullanılabilir.

8 – Replikasyonda sadece replikasyona dahil edilmiş kolonlarla ilgili transactionlar abonelere gönderilir. Örneğin AdSoyad ve Sehir kolonlarının bulunduğu kaynak tablosunda sadece AdSoyad kolonu replike ediliyorsa sadece Sehir kolonu update edildiği zaman aboneye herhangi bir update cümlesi gönderilmez aynı şekilde AdSoyad ve Sehir aynı anda update edilirse sadece AdSoyad kolonun update bilgisi aboneye ulaşır. Replikasyonun güzel yanı replikasyona dahil edilmiş kolonlar içerisinden gerçekten update edilmiş olanları abonelere gönderir. Örneğin tabloda Sehir=’Ankara’ ve AdSoyad=’Ahmet’ olan kayıt için
UPDATE Musteri SET Sehir=’İstanbul’,AdSoyad=’Ahmet’ WHERE MusteriId=1
sorgusunu çalıştırdığımızda abonelere sadece
UPDATE Musteri SET Sehir=’İstanbul’ WHERE MusteriId=1
sorgusu gönderilecektir. Aynı update cümlesini çalıştırdığımızda abonelere herhangi bir güncelleme emri gönderilmeyecektir.

9 – Article’larda bir değişiklik yapıldığı zaman yani replikasyona yeni bir kolon eklendiği veya var olan bir kolon çıkarıldığı zaman tüm subscription’lar reinitialize olacak şekilde işaretlenir. Onları yeniden ilklendirmek gerekir. Bu durum automatic initialization destekli subscription’lar için geçerli. Bu durumda reinitialization işlemi bir sonraki Snapshot Agent ve Distribution Agent’lerin çalışmasıyla gerçekleşir. Manual initialization destekli olan aboneleri manual olarak ilklendirmek gerekir.

10- Snapshot dosyaları nelerdir
İlklendirme işlemi için gerekli olan Snapshot dosyaları şunlardır; schema (.sch); data (.bcp); constraint ve index’ler (.dri); constraint’ler (.idx); trigger’ler (.trg):sıkıştırılmış snapshot dosyaları (.cab). Bu ilklendirme dosyaları transactional publication için sp_browsesnapshotfolder prosedürü, merge publication için sp_browsemergesnapshotfolder prosedürü kullanılarak görülebilir. Bu prosedürler publisher üzerinde çalıştırılır.

11 – Replikasyona dahil edilmiş olan bir kolonu kaldırmak istediğimizde “ALTER TABLE DROP COLUMN failed because is currently replicated.” gibi bir hatayla karşılaşırız. Bunu çözmenin en doğru yolu replikasyonu durdurmak, sözkonusu kolonu replikasyonda çıkarıp ardından DROP etmektir.

12 – SQL Server Enterprise Manager could not configure ‘TESTSERVER’ as the Distributor for ‘TESTSERVER’. Error 21112: ‘-PollingInterval’ is not a valid parameter for the Log Reader Agent” hatası sunucunun Turkish collation kullanıyor olmasından kaynaklanmaktadır. Bu hatayı gidermek için en az SQL Server 2000 Service Pack 1 kurmak lazım. Daha fazla bilgi için aşağıdaki adres incelenebilir.
http://support.microsoft.com/kb/295325

13 – Message 20554 Severity 10 “The agent is suspect. No activity reported within the last 10 minutes.” hatası replication agent’in SQL Server Enterprise Manager’e uzun süre durumunu haberdar edemeyişinden kaynaklanır. Bu hata sistem için sıkıntı yaratmaz. Bu hatayla karşılaşıldığı zaman sözkonusu agenti stop etmeyip servisin o anki işini bitirmesini beklemeliyiz. Agent stop edilirse o andaki işlemler rollback edilerek yeniden başlatılır.

14 – The process is running and is waiting for a response from one of the backend connections” hatası nedir ?
Bazı durumlarda Log Reader bu veya buna benzer bir mesaj verebilir. Bu bir hata olmayıp sistemin o an için meşgul olduğu karşı abonelerin tam olarak COMMIT edilmeyi beklediğini anlatır. Örneğin msrepl_transaction tablosunda işlenecek veya işlemin transcationlar fazla olduğu zaman böyle bir uyarı verilir. Veya snapshot data aboneye yansıtıldıktan sonra tablolara ait indexler çalıştırıldığı zaman da bu uyarı verilir. Bunun için sunucunun işlemini beklemekte fayda vardır. Bir süre sonra normale geçecektir. Bu hata mesajını kısa sürede elde etmemek için Agent için daha yüksek timeout değerine sahip bir profil oluşturulabilir.

15 – The system cannot find the file specified..” hatası
Bu hatayı genellikle snapshot agent çalışmaya başlarken hata verir. Bunun sebebi “C:\Program Files\Microsoft SQL Server\80\COM\” klasörünün altında replikasyon ile ilgili exe dosyalarının eksik olması olabilir.SP3 yeniden kurulabileceği gibi başka bir makineden ilgili exe ve dll dosyaları da kopyalanabilir.

SQL Server Replication İlgili Notlar” üzerine 6 düşünce

  1. Ismail

    Merhabalar,
    Yazınızda okudum da 7. maddenin sonunda servisin restrat edilmesi demişsiniz.Ben yeni bir aget profile tanımladıktan sonra sadece SQL server servicesini restart edersem replikasyoın kaldıgı yerden devam eder mi?

    Cevapla
  2. Ahmet Kaymaz Yazar

    Merhaba İsmail,aslında sadece Distributor Agent’i yeniden başlatmak yeterli olacaktır ama benim tavsiyem SQL Server Agent’i yeniden başlatmak olacaktır.

    Cevapla
  3. Ismail

    cevabınız için cok tskr ederim o zaman relikasyonun durdugu anlarda hatayı bulup eklemek sorunu çözer tekrar tskr ederim

    Cevapla
  4. Abdullah Esenkaya

    Merhaba;

    geçen hafta içerisinde tablolardaki kayıtlarımda 300bin kayda yakın bir değişikliğe gittim ve bu işlemi Distributor tarafında gerçekleştirdim veriler üzerinde değişiklik yaptıktan sonra Subscriber databaselerinde inceleme yaptığımda bazı verilerin yaklaşık olarak 1.500 kayıt değişmediğini gördüm. Problemi Subscriber tarafında veriler üzerinde aynı işlemi yaptığımda Distributor tarafına yansıyacağını düşünerek Subscriber tarafında kayıtlar üzerinde değişikliği yaptım tüm problemler bu esnada başladı.Kayıtlar Conflicts düşmeye başladı fakat 1500 kayıt için dakikada sadece 1 kayıt düşüyordu. Ve sonrasında Log reader agent kayıt numarası problemi vermeye başladı ve Puplicasyon işlemi tamamen durdu Distributor ne Subscriber lara kayıt gönderiyor nede dinliyordu. Sonucunda problemi köklü çözebilmek adına yeni daabase yeni publication diyerek yola çıktım ve publication tanımlarımı tekrar yaptım şu anda veri çoğaltma ve dinleme aşamasında herhangi bir problem görmüyorum Fakat MSrepl_transactions (480 kayıt) tablomda yeni puplication kurulduktan bu tarafa olan bütün transactions kayıtları duruyor. aynı problem MSrepl_commands (65.000 kayıt ) tablosu içinde geçerli ve bu kayıtlar gitgide artıyor daha önceki puplication işlemimde bu kayıtlar çoğaltma yapıldıktan sonra otomatik olarak siliniyordu. Bu kayıtların çoğalmasının bir zararı varmı ? Bu kayıtları silmemim bir sakıncası varmı?

    Bu konuda sizlerden yardım bekliyorum.

    Cevapla
  5. şükrü

    The replication agent has not logged a progress message in 10 minutes. This might indicate an unresponsive agent or high system activity. Verify that records are being replicated to the destination and that connections to the Subscriber, Publisher, and Distributor are still active.

    bu hatayı neden aldığım hakkıında bir fikriniz var mı

    Cevapla
  6. şükrü

    The replication agent has not logged a progress message in 10 minutes. This might indicate an unresponsive agent or high system activity. Verify that records are being replicated to the destination and that connections to the Subscriber, Publisher, and Distributor are still active.

    Bu hatayı neden alıyor olabilirim ?

    Cevapla

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Time limit is exhausted. Please reload CAPTCHA.