DBA'ler Nelerden Sorumludur ?

Yükleme, Konfigrasyon, Geliştirme, Migration: Sistem yöneticileri belirli bir sunucudaki donanımdan, işletim sisteminden database yazılımlarının sunucular üzerinde kurulumundan sorumludurlar. Aynı zamanda dba’lerin database’in kurulu olduğu sunucunun donanımsal olarakta bilgi sahibi olması beklenmektedir. DBA yazılımı yüklendikten sonra yazılımların çeşitli sunmuş olduğu seçenekleri belirlemek ve bu ayarları verim açısından en üst düzeyde konfigre etmek diğer amaçlarındandır. DBA, iş tanımı içerisinde en uygun yükleme koşullarını belirlemek durumundadır. Eğer mevcut olan sunucu bir diğer yeni olan ile değiştirilecekse buradaki veri aktarımı ve yeni olan server’ın tam effective çalışabilmesi için gerekli düzenlemeleri sağlar.

BackUp ve Recovery İşlemleri: DBA’ ler geliştirme, implemente etme(uygulamaya koyma), belli periyotlarla test işlemleri, backup ve recovery ile ilgili süreç ve prosedürleri yönetir. Alınan backup’ların sistemde oluşan herhangi beklenmedik problem sonrasında sağlıklı bir recovery işlemi sağlayabilmek için çalışabilir olup olmadığını denetlemektedir. Ortaya çıkan bir problem karşısında backup’ların nasıl kullanılacağını ve hiçbir transaction ve data kaybı olmadan ilgili backup’ın sisteme nasıl restore edilmesi gerektiğini en iyi şekilde bilmesi beklenmektedir. Sunucuların çalışmasına zarar verecek birçok farklı durum vardır ve bir veritabanı yöneticisinin kafasına bu senaryoları oluşturup, her bir farklı felaket senaryosu durumunda her biri için ayrı çözümleri daha önceden tanımlanmış olması gerekmektedir. İş açısından backup almanın çeşitli maliyetleri vardır. DBA’nin farklı backup çeşitleri için risk/maliyet analizini yapıp sisteme uygun doğru bir backup stratejisi belirlemesi gerekir.

Veritabanı Güvenliği: Veritabanının amacı verileri sistematik bir düzen içerisinde verileri depolamaktır. Böle bir şey söz konusu olduğu zaman bu verilere ulaşım dış çevrenin ilgisini çekmektedir. Saklanan verileri bu meraklı kişilerden(Hacker,çalışanlar, rakip firmalar)  koruyabilmek için dba bazı güvenlik modellerini bilmesi gerekmektedir. Üç temel güvenlik prosedürü vardır. Bunlardan ilki dba kullanıcılara hesap tanımlar ve kullanıcılar bu hesap ile birlikte veritabanına login olarak bağlanırlar. Böylece sistem dışarıya karşı izole edilmiş olur. Bir diğeri ise kullanıcı hesapları düzenlenerek, kullanıcı databse login olurken kullanıcının iş ihtiyacına göre erişim yetkisi tanımlar. Her kullanıcı için farklı yetkiler tanımlanabilir. Bir diğer güvenlik prosedürü ise login olan kullanıcının veritabanı içersinde ne iş yaptığını dba'ye izleme yetisi kazandıran auditing(denetleme) prosedürüdür.

Depolama ve Kapasite Planlaması: Database deki temel amaçlardan bir tanesi de depolama ve veri düzenlemesidir. Bu planlama ile dba ne kadar disk alanının gerekli olduğunu ve boşta kalan disk alanının takip etmek dba’nin temel sorumluluklarındandır. Verilerin büyüme eğilimlerini izlemek geleceğe yönelik yapılacak olan kapasite planlaması açısında dba nin vereceği kararlar için oldukça önem arz etmektedir.

Performansın İzlenimi ve Düzenlenmesi:  Dba'nin bir diğer sorumluluk alanı düzenli bir şekilde sunucuyu izlemesi gerekir ki herhangi bir olumsuz değişiklik söz konusu olduğu zaman bunu tanımlayabilecek bilgi birikimine sahip olsun. Eğer olması gerektiği çalışma performansını DBA tanımlayamıyorsa sıra dışı bir performans düşüşü söz konusu olduğu zaman DBA erken teşhis olarak bu durumu tanımlayamayacaktır. Sunucuların donanımsal kapasitesi ve işletim sisteminden dolayı birçok sınırlayıcı faktör söz konusu olabilir. Sunucuların disk sürücüleri ve indexleme yöntemleri ile bu sınırları bir nebze olsun zorlayabiliriz. Dba hangi izleme tools(araçları)'ları ile sistemi takip etmesi gerektiğini bilmeli ki sistemin normal çalışma prensiplerini anlayabilsin.

Troubleshooting (Problem Giderme): Server'larda yolunda gitmeyen bazı şeyler yüz göstermeye başladığı zaman dba'nın bunu en erken şekilde fark edebilmesi ortaya çıkan problem için teşhis koyabilmesi ve hiç bir veri kaybı yaşanmayacak şekilde ya da bunu minimum düzeyde tutacak şekilde sistemi çalışabilir halde tutması gerekir.

Bilişim Sektöründe DBA

     Merhabalar, bu yazımda sizlerle biraz teknik konulardan ziyade yapmış olduğum bir araştırmayı paylaşmak istiyorum. Dba'lerin bilişim sektöründeki yerini size anlatmaya çalışacağım. Sizlere aşağıda sunmuş olduğum grafikler, oranlar ve istatistiki veriler tamamen Amerika'ya aittir. Ayrıca bütün bu araştırmaların Mayıs 2015 tarihinde gerçekleştirildiğine de değinmek isterim.
   

Yukarıda gördüğünüz resimde dba olan bir kişinin hangi alanlara yönelebileceğini temsil eder. Aslında yukarıda da görüldüğü gibi sanılandan ziyada bir dba'in hiç de kısıtlı dar bir çalışma alanı olmadığını bize kanıtlar niteliktedir. 

Yukarıda ki sayısal veriler ise bize bir dba'nin maaşını olumlu yönde etkileyen yetenekler gösterilmektedir. Yani yapılan istatistiklere göre Unix bilen bir veritabanı yöneticisi diğerlerine göre %13 daha fazla maaş almaktadır.

Bu görselde ise veritabanı yöneticileri için popüler olan yeteneklerin şematik bir görseli sunulmuştur. Yalnız bu yukarıda ki görsel senior dba'ler arasında yapılan araştırma sonucu oluşturulmuştur. 

Bu görsel ise sektör içindeki dba'lerin cinsiyet oranlarını temsil etmektedir.

923 dba arasında yapılan oylamalar sonucunda iş memnuniyeti açısından dba'lik 5 üzerinden 5 puan alıp çalışanların işlerinden aşırı derecede memnun oldukları görülmektedir.

Bu görselde yıl bazında iş tecrübesine sahip çalışanlar sektördeki toplam dba'lere olan oranı gösterilmektedir. Yukarıdaki görselde gördüğünüz gibi 1-4 yıllık tecrübeye sahip çalışanlar %34'ünü oluşturarak en kalabalık gruptur.

Burada ise sektördeki maaş ortalamasının  $69,564 olduğunu görmekteyiz. Maaş aralığı ise $40,318 ile $102,713 arasında farklılık göstermektedir. Eğer senior seviyesine çıkılırsa maaş ortalamasıda $99,416 olmakta ve maaş aralığı ise $74,501 ile $135,327 olmaktadır.

Amerikadaki bazı şirketlerin dba maaşları gösterilmektedir.

Tecrübe ile maaş arasındaki ilişki.

Yukarıdaki 3 görselde MySql, Oracle ve Ms Sql Server'ın diğer branşlara göre yıllık bazlı maaş bilgileri verilmiştir.

Yukarıda ki 3 görselde ise şirket maaşları gösterilmektedir.

DBA'lerin görev tanımları hakkında yazılan makale için tıklayınız. 

Kaynakça:

www.payscale.com

Key Terminolojisi İle Birlikte Surrogate Key ve Natural Key Karşılaştırılması

Merhabalar; bu yazımda sizlere öncelikle genel olarak key (anahtar) terminolojisinden biraz bahsettikten sonra esas üzerinde durmak istediğim nokta Surrogate Key ile Natural Key'in karşılaştırılması ve bunların kullanım şekilleri olacak.

Key: Anahtar bir ya da birden fazla verinin benzersiz olarak kimliğinin tanımlanmasıdır. Fiziksel veri tabanlarında key'ler bir ya da birden fazla tablo kolonlarının biçimlendirilmesi ve onların ilişkisel tablolardaki satırların birbirinden benzersiz olarak tanımlanmasına olanak verir.

Composite Key: İki ya da daha fazla özelliklerin key ile birleştirilmesine verilen isimdir.

Natural Key: Gerçek yaşamda var olan bir özelliğin anahtar özellik olarak kullanılması denilebilir. Biraz daha açıklayıcı olması açısından tam da natural key'e örnek olarak Türkiye Cumhuriyetin'de yaşayan her Türk vatandaşının sahip olduğu ve benzersiz olan TC Kimlik numarası buna örnek verilebilir.

Surrogate Key: Bu key natural key gibi herhangi bir anlamı yoktur ve sistem tarafında otomatik olarak tanımlanabilirler.

Candidate Key: Logical Data modelinde hiç anahtar bulunmadığı gibi aynı zamanda birden fazla candidate anahtar bulunabilir. Ayrıca temel olarak benzersiz tanımlayıcı da olabilir. Daha açıklayıcı olması açısından örnek vermek gerekirse bir banka veritabanı düşünelim. Bankada her bir müşterinin benzersiz hesap ID'sinin yanı sıra aynı zamanda müşterilerinin TC Kimlik Numaraları da kullanılır. Şimdi küçük bir senaryo oluşturalım. Farz edelim ki devlet TC Kimlik Numarasını bireylere atarken yanlışlıkla iki kişiye aynı numarayı atadığını varsayalım. Eğer ki banka benzersiz numara olarak bir tek TC Kimlik numarasını kullanmış olsaydı bu iki TC No su aynı olan kişiyi veri tabanına kayıt ederken problem yaşanacaktı. Oysaki bu durumda en azından primary key alanı olan HesapID üzerinden işlemler sorunsuz bir şekilde devam edecektir.

Primary Key: Primary key etkili ve önemli bir ilişkisel veri tabanı konseptidir diyebiliriz. Benzersizliği sağlar ve primary-froign key ilişkisi sağlanmadan ilişkisel veritabanı düzgün şekilde çalışmayacaktır.

Alternate Key: İkincil anahtar da denilebilir, tablodaki bir satırın ikinci benzersiz tanımlayıcı alanıdır.

Foreign Key: Birincil ya da ikincil anahtarın başka bir tabloda temsil edilmesi denilebilir.

               

İlişkisel veri tabanlarını teorilerine göre, tabloların tam olarak normalize edilmesi için primary key'in tanımlı olması gerekmektedir. Fakat DB developer'ların üzerinde tartıştığı önemli bir konu ise surrogate mı yoksa natural primary key'in en iyi olduğu konusudur.

İlişkisel veri tabanı teorilerine göre, tabloların tam anlamıyla normalize olması için primary key olmak durumundadır. Fakat database developer'ların üzerinde tam olarak uzlaşamadığı bir nokta var ki surrogate kullanımı mı? Yoksa natural primary key kullanımı mı aralarında en iyisidir. Datalar aslında naturel key içerirler. Surrogate key’ler ise gerçek bir anlam içermezler. Hatta genellikle bu değerleri sistem tarafında üretilirler. Bazı DB developer'lar bunlardan ikisini de tercih edebilirler.

               

Primary Key Benzersiz Olmalı: Tablolarda saklanan veriler diğer alakalı tablolarda saklanan veriler ile bağlı olabilir ve her bir data, primary key vasıtasıyla benzersiz olarak tanımlanırlar. Naturel Key’e çeşitli alanlarda ihtiyaç duyulabilir ve naturel key her bir kayıt için benzersiz kimlik özelliğini sağlar. Surrogate key de kendi içerisinde de bu benzersizliği sağlamaktadır.

Primary Key Mümkün Olduğunca Kompakt Olmalı: Peki bu ifadenin bize anlatmak istediği şey nedir? Başlıktaki kompakt ifadesi bize tablolardaki benzersiz kimliğe sahip olması gereken alanların sayısını ifade etmektedir. DB developer'lardan bazıları naturel keys için çoklu alanlarda primary key kullanımı daha performanslı olduğu üzerinde dururlar. Primary key kompakt olmalı ve olabildiğince az field içinde kullanılmalıdır. Naturel key kullanımında birden fazla alan gerekmektedir. Surrogate key ise sadece bir alan gerektirir. 

Primary Key Değeleri Stabil Olmalı: Primary Key alanlarına gelecek olan data'lar stabil yani değişmez olmasına dikkat edilmelidir. Fakat bunu engellemenin bir yolu da yok, daima istisnai durumlar bu konu ile ilgili yaşanmaktadır. Ayrıca Naturel data'lar öznel olma özelliğine sahiptir ve bu veriler dış dünyadaki durumlardan etkilenirler ve bunları kontrol edemeyiz. Db developer'lar bu durumu göz önünde bulundurup kabullenmekten başka seçenekleri de bulunmamaktadır.

Surrogate key'de kullanılan değerler dış dünyadan değer almazlar yani anlamsız değerlerdir diyebiliriz. Bu durumda herhangi bir data’nın değişikliğe uğramak durumunda kalacağı istisnai bir durumda yaşanmaz. Eğer surrogate key değerlerinde bir data’da değişiklik yapmak zorunda kaldıysanız başlarda yapmış olduğunuz bir hata var demektir.

Primary Key Değerleri, Kayıt Oluşturmaktadır: Şunu unutmamak gererkir ki, primary key'in kullanıldığı alanlar null geçilemez. Başka bir deyişle primary key'ler aslında kayıt oluştururlar. Peki, bu durumda siz primary key değerini herhangi bir kayıt oluşturmadan önce bilmeli misiniz? Teorik olarak buna cevabımız hayır, ama gerçekte bazen bilmek zorunda kalabilirsiniz? Siz yeni bir kayıt oluşturduğunuzda surrogate key de değerler sistem tarafından atanır. Bundan dolayı primary key değerleri kayıt oluşturlduğu anda otomatik olarak yaratılırlar.

Kopya Verilere İzin Verilmez: Normalize edilmiş bir tabloda verilerin kopyalanmasına izin verilmez. İşlevsel olarak, evet doğru. İlişkisel teori açısından, hayır diyebiliriz. Unique index'lerde ve primary key'lerde verilerin tekrar edilmesi engellenir. Bu iki durumda da biri bir diğerini tamamlıyor ve sıklıkla bu görüş naturel key içindir. Naturel key'i savunanlar bu noktada surrogate key için veri tekrarına sebep olabileceğini idda ederler. Eğer surrogate primary key kullanmak istiyorsanız, uygun alanları index'lemeniz veri tekrarını önleyip bu problemi de çözecektir.

Kullanıcılar Primary Key Görmek İster: Genelde böyle yanlış bir anlayış vardır. Primary key değerleri olmadan genelde kullanıcılarda bir eksiklik varmış gibi bir algı oluşur. Bunun için geçerli bir sebep yok oysaki. Gerçekte kullanıcıların böle bir değeri bilmesine de ihtiyaç yoktur. Arka planda tutulması yeterlidir. Primary key kullanıcı tarafında bir anlam ifade de etmemelidir zaten. Kullanıcı veri girer, mevcut veriyi günceller, rapor alır ya da bunun gibi şeyler. Kullanıcı işlem yaptığı tarafta primary key kullanımına ihtiyaç duyma düşüncesi terk edilmelidir. Bunu da surrogate key ile arka planda çalıştırarak da daha kolay sağlayabiliriz.

Gereksiz Alana Surrogate Ekleme: Surrogate kullanımı bize extra bir alan gerektirmektedir ki bu da boş alanların israf edilmesine sebep olacaktır. Sonuçta gereken her şey kayıt için benzersiz bir kimlik tanımlamak ki bu işlemde aslında diğer tablolardaki verilerle ilgilidir. Otomatik değer üreten bir alan hem disk maliyetini düşürecektir hem de bu konu ile alakalı bakım durumunu minimal düzeyde tutacaktır. Bu, natural key kadar önerilmemektedir. Fakat geçerli bir yöntem de denilebilir.

Sistem Hata Yapmaz: Herkes sistem tarafından üretilen değerlere yeteri kadar güvenmeyebilir. Sistem tarafında bir hata oluşabilir. Fakat diğer taraftan, Naturel value kullanımında da problem çıkması muhtemeldir. Veri tabanını korumanın en iyi yolu düzenli olarak uygulanan bir back up stratejinizdir. Naturel veriler sistem tarafından oluşturulanlardan daha fazla güvenilir değildir.

Koşullar Natural Key Kullnımını Gerektirir: Entegre olmuş sistemlerde natural key kullanımı gerekebilir. Bazen benzer tablolar paylaşan uygulamaların birbirinden bağımsız yeni kayıtlar oluşturur. İki farklı veritabanı muhtemelen birbirine benzer değerler üretecektir. Bu koşullar altında primary key'in tekrarlanmaması için bütün olasılıklar elimine edilmelidir.

Surrogate key kullanımı bu durumda bize çözüm sunar. Her bir sisteme faklı bir seed değeri tanımlanabilir ama bu hala tam net çözümü sunmayabilir. GUID kullanımı ise sizin performansınızı etkileyecektir. Bu durumda en mantıklı seçenek naturel key kullanımı olacaktır.

               

Data Replication Nedir ?

       SQL Server replication teknolojisi sayesinde bu noktada bize kullanılabilirlik, sürdürülebilirlik sunuyor. Şimdi konuyu detaylandırmadan önce değinmek istediğim bir diğer nokta ise data replication'u SQL Server'in tüm sürümlerinden kullanmak mümkün. Fakat Express sürümü üzerinde küçük bir kısıtlama uygulanmış; bu sürüme sahipseniz birazdan detaylandıracağımız SnapShot modelini kullanamıyorsunuz ve sunucunun publisher olarak kullanıma izin verilmiyor. Bu noktada sadece sunucunun Subscriber olmasına izin verilmekte.
Şimdi kısaca data replication modelindeki sunucu tiplerinden bahsedelim:
1- Publisher: Publisher'ın Türkçe karşılığıda yayıncıdır. Yani bizim kaynak verilerimizin alınıp diğer sunuculara kopyalandığı merkezi sunucumuz diyebiliriz.
2-Subscriber: Subscriber'in Türkçe karşılığı ise üyedir. Aslında isimden de anlaşılacağı üzere Subscriber sunucular publisher'lardan gelen kaynak veriyi alırlar.
3-Distributor: Publisher ile Subscriber arasında veri alış verişini sağlayan ve bu akışı yöneten sunucudur. Değişikliğe uğramış veriler subscriber sunucuya ulaşana kadar bu sunucu üzerinde saklanır.  Distributor ayrı bir sunucu olabildiği gibi aynı zamanda da publisher'ın içerisinde tanımlanabilir. Aslında buna karar verirken tamamen sizin sunucu trafiğiniz yada publisher üzerinde gerçekleşen replikasyon işlem yoğunlu ile alakalıdır. İlerleyen aşamalarda bu konuyu detaylandıracağım.
Artcile: Publisher tarafından subsciriber' a yayınlanan her türlü yayın içeriği denilebilir. Bunlar table, view, stored procedure olabilirler.
Bir replication modeli oluştururken modellememiz gereken publisher, subscriber ve distributor sunucularmız, ayrıca agentların hangi tarafta çalışması gerektiği gibi sormamız gereken sorular olacaktır. İşte bu noktada sistemimizi iyi bilmemiz, oluşacak network trafiği ve replikasyon işlem yoğunluna uygun strateji geliştirip, bu doğrultuda aşağıda bahsedilenlerden hangi yapıyı kullanmak bizim için daha uygun olacağına karar vermek gerekir.
Toplam 5 adet replikasyon modeli bulunmaktadır, bunlardan ilki:
Central Publisher Modeli: Bu modelde adından da anlaşılacağı üzere tek bir publisher sunucu vardır ve birden fazla subsriber server' a yayın yapar. Aynı zamanda bu model de unutulmaması gereken bir diğer önemli ayrıntı distributor sunucu, burada ayrı bir sunucuda değil publsiher sunucu içerisinde bulunur. Bu noktada eğer ki yoğun replikasyon işlemleri olacaksa bu model tavsiye edilmemektedir. Eğer sunucu tarafında distributor'u ayrıma imkânınız yoksa en azından Pull Subscription yönetimi kullanarak iş yükünü birazcık daha Subscriber sunucuya yükleyerek Publisher sunucu tarafın işini hafifletmeye çalışabiliriz.
Central Subscriber modeli: Bu model de ise yukarıda bahsettiğmiz central publisher modelin tam tersi bir yapı söz konusu. burada bir adet subscriber sunucu varken birden fazla publisher sunucu bu tek subscriber sunucuya yayın yapar. Genel de bu yapının kullanım alanı Data Warehouse sistemlerinde görülmektedir. Bu yapıda birden fazla publisher olduğu için veri iletiminde distributor'lar yaptığı için iki farklı distributor subscriber ile publisher arasındaki veri iletişimini sağlar ama bunlar ayrı bir sunucu içerisinde değil publisher içerisinde çalışırlar.
Central Publisher with Remote Distributor Modeli: Bu model yoğun işlem ve replikasyonların çalıştığı sistemlerde  tercih edilir. Bu tarafta bir adet publisher sunucu, birden fazla subscriber sunucu ve bir adette ayrı bir sunucuda da Distributor vardır. Burada amaç Distributor'u Publisher'dan ayırarak zaten publisher üzerinde yoğun olan işlemler yüzünden bir de veri transferi ile publisher sunucuyu boğmamak amaçlanır.
Publishing Subscriber Modeli: Bu modelde publisher bir sunucu aynı zamanda başka bir sunucunun subscriber görevini üstlenir. Bu modelde iki sunucada aynı veriyi yayınlar. Burada bir adet publisher sunucu bir adet subscriber/publisher sunucu birden fazla da subscriber sunucu bulunur. Distributorlar publisher sunucuların içerisinde yer alırlar.
Central Distributor Modeli: Birden fazla publisher sunucu ve birden fazla da subscriber sunucu vardır. Bu sunucların arasında iletişimi sağlayan publisherdan bağımsız olarak bulunan distributor sunucu vardır.
Şu ana kadar modellerden bahsettik fakat bu verilerin gönderilmesinin iki farklı türü vardır. Bunlardan bir tanesi Push Subscriptiondur.  Burada distributor verileri subscriber' a kendisi kopyalar yani agent aslında distributor tarafında çalışır.Bir diğre ise pull subscriptiondur. Burada ise bizim subscriber sunucumuz verileri distributor tarafından kendine çeker. Yani bu işlemde agent subscriber tarafında çalışır. Yukarıda da biraz değinmiştim eğer ki Distributor, publisher sunucu üzerinde çalışıyorsa ve işlem yoğunluğu fazla ise push subscription distributor tarafında çalışacağından sunucumuzu ekstra yoracaktır. Bu noktada pull subscription yönetimi kullanarak agent'ı subscriber tarafında çalıştırırarak publish sunucuyu bir miktar rahatlatmış olacağız.
Tüm bunlar ayarlandıktan sonra sırada karar verilmesi gereken bir diğer nokta ise bizim replication türümüzün ne olacağıdır. Burada tamamen aslında bizim nasıl bir replication stratejesine ihtiyaç duyduğumuz önemlidir. Bu noktada SQL Server bize 3 farklı seçenek sunmaktadır. Bunlar: Snapshot replication, transactional replication ve merge replicationur. Snapshot  replication static bir yapıdır. Çalışma şekli, kaynak veritabanındaki tüm verileri alarak subscriber sunucumaza kopyalar ve bunu her defasında yapar.  Bu model az transaciton işlemlerin olduğu sistemlerde kullanılabilir.
Transactional replication snapshota göre dinamik bir yapıya sahiptir. İncremental bir yapıdadır. Son yapılan replication işlemlerinden sonraki değişiklikleri subscriber sunucuya gönderir. Bunu yaparken de publisher tarafındaki log dosyasını dinleyerek gerçekleştirir. Burda opsiyonel olarak gerçek zamanlı  yada periyodik aralıklarla da replicaiton işleminin uygulanma şeklini ayarlayabiliriz. Bu yönetem yoğun replication işlemlerin olduğu sistemlerde tercih edilmektedir. Çünkü bu yapıda sadece transaction'lar subscriber'a gönderilir.
Merge replication transactional replication gibi incremental bir yapıya sahip olup aynı zamanda çift yönlü replication işlemi sunar. Yani Publisher sunucuda subscriber tarafındaki değişiklikleri dinler. Bu yapı birden fazla subscriber'ın bulunduğu ve yapılan değişiklerin publisher sunucuyla birlikte aynı zamanda diğer üyelerede uygulanması gerektiği durumlarda tercih edilmelidir. Merge Replicationdaki bir diğer ayrıntı, bir data üzerinde birden fazla yapılan değişiklik adım adım subscriber'a yansıtılmaz bunun yerine en son yapılan değişiklikler gönderilir. Bu nokta da transactional replicationdan da farklılaşmaktadır. Çünkü transactional replicationda data üzerinde yapılan bütün değişiklikler adım adım olarak diğer üyelere yansıtılır. Bununla birlikte transactional replication bize "Updatable Subscriptions for transactional replication" adında ekstra bir seçenek sunmakta. Bunun seçilmesi durumunda  transactional replicationda  da aynı merge replicationda olduğu gibi çift yönlü bir etkileşim sağlanmış olur. Yani üye sunuculardaki değişiklikler publishera da yansıltılmış olacaktır. Eğer Snapshot yada Transactional modelini kullanıyorsanız yani tek taraflı bir etkileşim modeli söz konusu ise SQL Server da subscriber sunucuların default değeri READ ONLY olarak düzenlenmektedir. Bunun sebebi ise Subscriber tarafındaki bir kullanıcının yanlışlık bir veri üzerinde değişklik yapması durumunda publsiher ile subscriber sunucu arasında veri tutarsızlığı oluşturacaktır.
Yukarıdaki hangi replication türünü seçersek seçelim öncelikli yapılması gereken işlemin publisher ile subscriber tarafındaki verilerin senkronize edilmesi gererkir. Bu noktda publisherın full backup'ı alındıktan sonra subscriber sunuculara restore edilmese gerekecektir.
Son olarak replication işlemleri tarafında çalışan agentlardan size bahsetmek istiyorum. Tüm bu yukarıda anlattığım işlemler SQL Server Agent servisi ve bunun altında çalışan bağımsız agentlar tarafından yönetilir. Snapshot Agent, yedek db yi hazırlamak amacıyla publisher tarafındaki verilere erişip bunları kopyalanmak üzere hazırlar ve bu agent distributor sunucu üzerinde çalışır. Bütün replication türlerinde aktif olarak çalışır.Distribution Agent ise snapshot'ın kopyaladığı verilere erişerek bunları subscriber sunuculara gönderir. Eğer bu aktarım işleminde pull yöntemi kullanılıyorsa agent subscriber sunuclar üzerinde çalışır, eğer push yöntemini kullanılıyorsa agent distributor üzerinde çalışır. Snapshot ve transactional replicationlar da kullanılan agent'tır. Log Reader Agent ise sadece transactional replication da çalışır ve publisher veritabanına ait log dosyasını dinleyerek distributor sunucuya aktarır. Bu agent distributor tarafında çalışmaktadır. Merge Agent da durum biraz daha farklı aslında, distribution agent'ın yaptığı işleri merge replicationda merge agent tarafından yapmakta. Merge replicaiton kullanıldığında veri aktarımı için distribution agent devreye girmez ve bu noktada işleri merge agent gerçekleştirir. Publisher ve subscriber arasında yayın senkronizasyonu sağlayan bu agent Pull yönteminde subscriber üzerinde, push yönteminde publisher üzerinde çalışır.

SQL Server Index Nedir ?

SQL Server Index nedir, ne işe yarar ve kullanımı ? Video konu anlatımı.