Veri Taşıma

A veri tabanından B veri tabanına bilgileri aktarmanın değişik amaçları olabilir. Bu amaçlardan bir tanesi canlıda çalışan uygulamaların kullandığı verinin sağlanması veya var olan verilerin güncellenmesi ise; zaman ayırıp uygun yapının bulunması, kurgulanması ve geliştirilip çalışır hale getirilmesi ciddi zaman demektir. Bu zamanı azaltmak için kullandığınız veri tabanlarının neler desteklediğini bilmek ve bunlara göre uygun senaryolar oluşturmak işinize yarayabilir.

Giriş kısmı biraz benim üslubumdan uzak olduğunun farkındayım, ancak geçtiğimiz haftalarda yaptığım bir geliştirme tam da yukarıda anlattığım gibi ciddi zaman harcamama sebep oldu. Bu geliştirme sırasında başıma gelenleri düşününce güzel bir yazı çıkabileceğini düşündüm ve yazmaya başladım.

Service Broker Yapıları

Konumuz, A veri tabanından B veri tabanına verilerin belirli koşullarla güncellendiğinde transfer edilmesi, daha önceden çalışan yapının özelliklerini kullanarak ufak tefek güncellemeler yapmamız  ve eksik olan yeni alanların senkronizasyon sistemine eklenmesi.

Kullanacağımız yapı, SQL Server 2005 ile hayatımıza giren, lokal veya uzak veri tabanları arasında asenkron mesaj iletilmesini sağlayan Service Broker.

Service Broker’ ın basit olarak ne olduğunu söyledim ancak aslında detaylı incelendiğinde TCP üzerinden veri tabanı seviyesinden mesaj iletilmesi ve bunun asenkron olarak sağlanması bu yapı kullanılarak yapılacak alt yapısal çözümlerin çeşitliliğini bana göre arttırıyor. Ancak belirttiğim gibi yazının konusu Service Broker ile Data Audit yapısı kurmak.

Service Broker yapısının detaylarına bu yazı da girmeyeceğim sadece verilerin transfer edilmesi için gerekli olan yapıyı nasıl kurulduğunu ve karşılaştığım sorunlarla nasıl başa çıktığımla devam etmeye çalışacağım. Bu rağmen Service Broker‘ ın kullandığı basit yapılardan bahsetmem gerekiyor.

Queues ( Kuyruklar ) – Dialogs ( İletişim Kutuları )

Service Broker mesaj gönderen ve alan servislerin arasındaki bağlantının esnekliğini sağlamak için kuyruk yapısını kullanmaktadır. Bu kuyruklar normal kuyruklar gibi mesajları geliş sırasına göre saklar ve istenildiğinde uygun sırada iletilmesini iletişim kutuları kullanarak sağlar.

İletişim kutuları çift yönlü ve tekil olarak sağladığı iletişim kanalıyla mesajın karışmadan ve takılmadan gönderen servisten alan servise taşınmasına olanak sağlar.

İletişim kutuları ve kuyruklar en temel bileşenlerini oluşturmakta olmasına rağmen mesaj ve sözleşmeler de Service Broker yapısının detayına girildiği zaman işe yarayan özelliklerle karşılaşabileceğiniz diğer bileşenleri.

Mesaj ve sözleşme olmadan yapı tamamlanmıyor, ancak en basit kullanımlarıyla tam olarak ihtiyacımızı karşılıyor ve kullanım da bir sıkıntı yaratmıyor.

Hadi o zaman basit bir Service Broker yapısı hazırlayalım. Öncelikle Service Broker özelliğinin veri tabanı üzerinden aktifleştirilmesi gerekmekte, bunun için;

kullanılabileceği gibi. Veri tabanı özelliklerinden de açılabilir.Service Broker Database Properties
Bu noktada karşılaştığım sorun canlı sistem üzerinde bu çalışmayı yapmak istediğim de bağlı olan oturumların açık kalması. Bunu önleyebilmek için biraz tehlikeli bir sorgu ile çözüme ulaşabiliyoruz.

Service Broker özelliği aktifleştirildikten sonra kullanacağımız diğer bileşenleri oluşturmak için aşağıdaki sorguyu çalıştırabiliriz.

Sırasıyla sorguları çalıştırıldığında bileşenlerin hepsi tamamlanmış olacak ve bu sayede artık örneklerimize geçebileceğiz.

Service Broker‘ ı tanıtırken tekil bir iletişim kanalı açtığını söylemiştim. Göndereceğimiz mesajı hazırladıktan sonra bir id tanımlaması yapıyoruz. Bu id’ yi kullanarak iletişim kanalını açıyoruz ve kanalın tanımlamalarını yapıyoruz. Bizim örneğimiz de CatalogSendService üzerinden CatalogRecieveService üzerine mesaj aktarımı CatalogContract kullanılacak yapılacak ve şifreleme kullanılmayacak. Mesaj gönderimi yapılırken kullanılacak iletişim kanalınının id bilgisi kullanılıyor ve istediğimiz mesaj tipinde gönderimi yapıyoruz. Son olarak ta tanımlamasını yaptığımız iletişim kanalını kapatıyoruz. Sorguyu çalıştırdıktan sonra aşağıdaki gibi mesajları sorgulayabiliyoruz.

Service Broker Result
Yukarıdaki görsel açıklayıcı ya da anlamlı gelmemiş olabilir o yüzden;

Service Broker Result Readable
sorgusu size daha mantıklı gelebilir. Bu sorguyu istediğiniz gibi çalıştırabilirsiniz, mesaj kuyruktan çıkartılmayacaktır. Kuyruktan mesajı çıkartmak için;

sorgusunu kullanmak gerekiyor. Bu sorgu çalıştıktan sonra mesaj kuyruktan çıkartılıyor. Denemeleri yaparken göreceksiniz, bir mesajı kuyruğa eklediğiniz zaman peşine message_body alanı NULL olan bir kayıt gelecek. Bu kayıt aradaki iletişim kanalının kapatıldığına dair bir bilgi eklemiş oluyor. Bu mesajları uygulama tarafından nasıl elde edeceğiz kısmına geldiğimiz de ise;

şeklinde bir kod karşımıza çıkıyor. Kod üzerinde işaretli olan satır ile ilgili aklınıza neden while kullanmadık düşüncesi gelebilir diye açıklamasını yapayım hemen. Eğer while kullanırsam daha önceki görsellerde gördüğümüz o NULL satır biriz uygulama tarafımıza da gelmiş oluyor. Recieve komutu sadece tek bir mesaj grubu alıp bunu kuyruktan çıkarttığı için if ile devam ettiğimiz zaman NULL olan satır bilgisinden kurtulmuş oluyoruz.

Select ile bütün kuyruk mesajlarını listelediğimiz de bu mesajların kuyruktan çıkmadığını söylemiştim,  bu yüzden Select ile ilerlemek yerine Recieve ile ilerliyoruz.

Uygulama ile Service Broker yapımızı bağlamış olduk. A veri tabanı ile B veri tabanı arasındaki bilgi alış verişini bu şekilde sağlamak önerilen bir yöntem olarak düşünülmemeli. Zaten Service Broker yapısının amacı lokal ve uzak veri tabanları arasında TCP üzerinden asenkron iletişimin sağlanması.

Verilerin senkronize edilmesi için SQL Server tarafında 2008 versiyonu ile gelen yeni yapılar ile çok daha basit geliştirmelerle verinin versiyonlanması ve takibi kolaylaştırılıp, Service Broker‘ ın kendi tanımına uygun çalışması sağlanabilir.

Yorumlayın