18 Ekim 2007 Perşembe

Replication (Sürekli Kullanılabilirlik - 3)

SQL Server Replication

Merhaba arkadaşlar,

Bu makalemde, SQL Server Replication teknolojisinin kavramsal olarak yapısını irdeleyeceğiz. Ayrıca, Replication yöntemlerinden de bahsedeceğim.

Sürekli Kullanılabilirlik (High Availability) konusunda şimdiye kadar SQL Server Failover Clustering ve Database Mirroring’ ten bahsetmiştim. Bunların avantaj ve dezavantajlarından, özelliklerinden ve hangi durumlarda kullanılabileceğinden kısaca bahsetmiştim. Replication konusu ile, Sürekli Kullanılabilirlik yazı dizimin üçüncü bölümünü tamamlamış olacağım. Dördüncü bölüm ise Log Shipping konusunda olacak ve böylelikle Sürekli Kullanılabilirlik konusunu tamamlamış olacağız. En sonunda, bu teknolojilerin birlikte nasıl kullanılabileceklerinden ve genel olarak duruma göre birbirlerine karşı üstünlüklerinden ve dezavantajlarından bahsedeceğim. Ayrıca, Log Shipping konusunun sonunda değişik senarolar da kurgulayacağım. Böylece, hangi teknolojinin nerede kullanılabileceği daha anlaşılır bir hale gelecek umarım.

Makalemde yer yer terimlerin Türkçe ve İngilizcelerini karışık şekilde kullanacağım. Böylece bu terimlerin daha iyi öğrenilebileceği kanısındayım. İki dildeki terimlere aşina olmanızı uygun görmemin nedeni, yazılımların ingilizce olması ve bunların anlaşılabilmesinin de türkçe olarak daha kolay olabilmesi. Umarım işe yarar.


KONU BAŞLIKLARI:

- Replication ve Elemanları
- Publisher, Distributor ve Subscriber
- Replication Teknolojisinde Kullanılan Agent’ lar
- Replication Yöntemleri



REPLICATION YÖNTEMLERİ ve ELEMANLARI

Replication’ ın temel olarak üç yöntemi var, bunlar:

- Snapshot Replication
- Transactional Replication
- Merge Replication’ dır.


Her yöntem, ayrı ayrı seçenekler sunar. İhtiyacımıza göre hangisini kullanabileceğimizi öğrenmek için bu konularda, kendi başlıklarında söz edeceğim.

Fakat daha önce, Replication yapısını oluşturan öğelerden bahsetmek istiyorum. Replication yapısını genel olarak “Yayımevinin yayınladığı makalelere üye olan ve bu yayınları dağıtıcı sayesinde alan aboneler” şeklinde düşünebilirsiniz.

Publisher (Yayıncı) : Yayınlanacak olan makaleleri (Article), yayın (Publication) şeklinde yayınlanmak üzere üzerinde barındırır.

Distributor (Dağıtıcı) : “Publisher” daki “Article” ları, “Subscriber” lara ulaştırır.

Subscriber(Abone) : “Publisher” ın yayınladığı “Article” lara abone olarak, “Distributor” vasıtasıyla yayınları alır.

Publication (Yayın) : Bunu bir gazete gibi varsayın, “Article” lar da bu gazetenin makaleleri.

Article (Makale) : Table, Stored Procedure, View gibi nesneleri makalelere örnek olarak verebiliriz. Yukarıdaki örnekte de söylediğim gibi, Publication’ lar, makalelerden oluşur. Bir tane bile makaleniz olsa, bu, Publication şeklinde Publisher tarafından yayınlanır.

Burada anlattıklarımı, bir de görsel olarak aşağıdaki Şekil-1’ de anlatmanın daha yararlı olacağını düşünüyorum.

Şekil-1

Yukarıdaki Şekil-1’ de gördüğünüz gibi, “Publication_1” isimli bir yayınımız var ve bu yayın 4 makaleden (Article) oluşuyor. Bu Yayını (Publication) ise, Yayıncı (Publisher) yayımlıyor. Dağıtıcı (Distributor), yayını yayıncıdan alıp, ya iterek (Push) ya da abonelerin kendisinden yayını çekerek (Pull) yayınlama işlemini gerçekleştiriyor.

Bu arada, biliyorum bazen çok sıkıcı olabiliyorum. Aynı terimleri defalarca yazıyorum, ama maksadım bu terimlerin kafanızda daha belirgin şekilde yer etmesidir.


REPLICATION TEKNOLOJISINDE KULLANILAN AGENT’ lar

Yukarıda bahsetmiş olduğum yayınlama, itme, çekme gibi işler, Agent’ lar vasıtasıyla yapılıyor. Replication yapısında beş adet Agent bulunmaktadır. Her Agent aslında SQL Server’ dan bağımsız olarak uygulama şeklinde çalışırlar. Yani her Agent aslında bir uygulama (exe) dosyasıdır. Biraz da bu Agent’ lardan başlıklar halinde bahsedelim. O zaman inanıyorum ki işlevleri ve yapıları daha iyi anlaşılacaktır.

Snapshot Agent (snapshot.exe) : Snapshot Agent, Replication’ ın tüm yöntemlerinde kullanılan bir Agent’ tır. Tabloların ve diğer nesnelerin Şema (Schema) ve veri dosyalarını hazırlar. Snapshot dosyalarını depolar ve Dağıtım (Distribution) veritabanına, eşleşmeler (senkronizasyon) hakkındaki bilgileri kaydeder. Snapshot Agent, Dağıtıcı (Distributor) ‘nın üstünde çalışır. Yani Dağıtıcı görevi hangi SQL Server sunucusundaysa, Snapshot Agent da orada çalışır.

Log Reader Agent (logread.exe) : Log Reader Agent, sadece Transactional Replication yönteminde kulanılır. Yayıncının (Publisher) yayınladığı veritabanının Transaction Log’ unda bulunan ve Replication işlemi için işaretlenen kayıtları, Dağıtıcı (Distributor) görevini yapan SQL Server’ daki Dağıtım (Distribution) veritabanına taşır. Transactional Replication kullanılarak yayınlanan her veritabanının, Dağıtıcı’ da çalışan ve Yayıncı’ ya bağlanıp verileri alan Log Reader Agent’ ı vardır.

Distribution Agent (distrib.exe): Distribution Agent, Snapshot Replication ve Transactional Replication ile birlikte kullanılır. Başlangıç bilgilerini Abone’ ye (Subscriber) uygular; ayrıca Dağıtım (Distribution) veritabanında bulunan işlemleri de abonelere aktarır. Eğer Replication veri aktarma şekli olarak çekme (Pull) şekli kullanılırsa, Distribution Agent, Abone’ lik yapan SQL Server sunucusunda çalışır; Eğer itme (Push) kullanılırsa, o zaman da Dağıtıcı görevini üstlenen SQL Server’ da çalışır.

Merge Agent (replmerg.exe): Merge Agent, sadece Merge Replication yönteminde kullanılan bir Agent’ tır. Distribution Agent’ ın Snapshot Replication ve Transactional Replication’ da yaptığı görevi yapar. Başlangıç bilgilerini Abone’ ye uygular ve Dağıtım veritabanında bulunan işlemleri de abonelere aktarır. Her Merge Replication abonesinin, Yayıncıya ve Aboneye bağlayıp verileri güncelleyen kendi Merge Agent’ ları vardır. Gene Distribution Agent’ ta olduğu gibi veri aktarma yolu olarak Çekme yöntemi kullanılırsa Merge Agent Abone’ de çalışır, eğer İtme yöntemi kullanılırsa da Dağıtıcı’ da çalışır. Merge Agent, varsayılan olarak, değişiklikleri Abone’ den Yayıncıya gönderir ve Yayıncı’ daki veritabanında yapılan değişiklikleri de Abone’ nin veritabanına yansıtır.

Queue Reader Agent (qrdrsvc.exe): Queued Updating seçeneği ile birlikte Transactional Replication’ da kullanılır. Bu Agent, Dağıtıcı’ da çalışır ve Abone’ de yapılan değişiklikleri Yayıncıya aktarır. Distribution Agent ve Merge Agent’ ın aksine, sadece bir Queue Reader Agent örneği vardır.


PUBLISHER, DISTRIBUTOR ve SUBSCRIBER

SQL Server Replication teknolojisini SQL Server’ ın tüm sürümlerinde kullanabilirsiniz. Fakat kullandığınız sürüme göre, bazı kısıtlamalar vardır. Genel olarak aşağıdaki tabloda bu kısıtlamaları bulabilirsiniz.




SQL Server sürümleri arasındaki farkları daha ayrıntılı görmek için şu adresi ziyaret edebilirsiniz:
http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx

Duruma göre, Replication kurulumlarında Publisher ve Distributor bir SQL Server sunucusu üzerinde konuşlandırılabilir. Bu, sisteminizdeki yük miktarına bağlı olarak değişir. Eğer sisteminizdeki yük fazla değilse ve SQL Server sunucunuz hem Publisher hem de Distributor görevlerinin yükünü kaldırabilecekse, o zaman Replication topolojinizi bu yönde şekillendirebilirsiniz. Yani Yayını, Yayıncı yayınlar ve dağıtır. Yalnız bu, Dağıtıcı’ nın aradan kalktığı anlamına gelmemektedir. Sadece Yayıncı ve Dağıtıcı’ nın aynı SQL Server üzerinde konuşlandırılacağı anlamına gelir. Sistem, gene aynı şekilde işler. Bu şekilde, merkezde bir SQL Server sunucusu kullanmış olursunuz. Bu da hem donanım, hem de lisans tasarrufu sağlar. Fakat yükün fazla olduğu ortamlarda, Publisher ve Distributor görevlerini ayrı ayrı SQL Server sunucularında gerçekleştirmek kaçınılmazdır.

Bu arada, veri aktarma yöntemi olarak İtme (Push) ve Çekme (Pull) yöntemlerine de bu noktada tekrar değinmek istiyorum. Neden ve neye göre İtme ve Çekme yöntemlerini kullanırız? Nedeni şu, Eğer dağıtım işiyle ilgili Agent’ ın (Yukarıda da bahsettik: Distribution veya Merge Agent) yükünü Distributor’ a yüklemek istiyorsak, Push kullanıyorduk; yani veri Distributor vasıtasıyla Publisher’ dan alınıyor ve Subscriber’ lara doğru itilmek suretiyle gönderiliyoruz. Eğer Distributor görevini ifa eden SQL Server’ daki bu yükü azaltmak istersek, o zaman Pull yöntemini kullanarak bahsini ettiğimiz Ditribution ve Merge Agent’ ın Subcriber’ lar üzerinde çalışmasını sağlıyoruz. Böylece yük sadece bir noktada toplanmamış oluyor, yükü abonelere dağıtıyoruz. Fakat Distributor bu görevi rahatlıkla ifa ediyor ise ve kısa ve orta vadede de geniş çaplı bir büyüme beklenmiyorsa, o zaman bu Agent’ lar Distributor üzerinde çalıştırılabilir; böylece Distribution ve Merge Agent’ larının yükleri güçsüz Abone cihazlarına yüklenmemiş olur.


REPLICATION YÖNTEMLERİ

Bu başlık altında, hangi Replication yönteminin ne işe yaradığını, ne amaçla kullanılabileceğini ve belli başlı özelliklerini anlatacağım.


Snapshot Replication:
Snapshot Replication yönteminde, kaynaktaki veriler olduğu gibi hedefe aktarılır. Kaynak veritabanında yapılan değişiklikler takip edilmez. Yani Snapshot Replication’ da, yapılan değişikliklere göre bir aktarma söz konusu değildir. Snapshot Replication, aşağıdaki durumlar söz konusu olduğunda kullanılmalıdır:

- Veri, nadir olarak değişiyorsa;

- Replication ile aktarılan verilerin güncelliğinin, Publisher’ daki verilere
nazaran eski olması kabul edilebiliyorsa;

- Replication için küçük miktardaki veriler kullanılıyorsa;

- Eğer kısa bir süre içerisinde, çok fazla veri değişikliği
gerçekleştiriliyorsa.

Bu Replication yönteminin kullanılabileceği bir örnek vermek istiyorum. Meselâ bir ürün listeniz var. Ürünleriniz senede bir veya iki kez güncelleniyor ve güncellendiklerinde de ürün listesinin %70’ i veya daha fazlası değişiyor. İşte bu durumda, Snapshot Replication kullanılabilir. Çünkü sürekli bir şekilde veri değişikliği yapılmıyor, ayrıca veri değişikliği yapıldığında da veriler büyük miktarda değişiyor.

Bir örnek daha verelim, meselâ küçük boyutlarda bir tablomuz var. Bu tablomuzun her gece saat 12’ de güncellenmesi gerekiyor. Tablo boyutu küçük olduğundan dolayı ve güncellemenin sürekli veya tam zamanlı değil de, geceden geceye yapılması gerektiğinden dolayı Snapshot Replication bu durum için idealdir.

Eğer veri boyutu büyük olsaydı veya güncellemelerin sürekli takip edilmesi gerekseydi, o zaman Snapshot Replication senaryolarımız için uygun olmayacak ve diğer Replication yöntemlerini düşünecektik.


Transactional Replication:
Transactional Replication, Şema ve verilerin tamamının abonelere gönderilmesiyle başlar. Daha sonra, Publisher’ daki veritabanında yapılacak olan değişiklikler nerdeyse gerçek zamanlı olarak abonelere aktarılır. Publisher’ daki veritabanında yapılan değişiklikler, aynen değişiklik sırasına göre Abone’ lerde de uygulanır. Böylece, veri tutarlılığı garanti edilmiş olur. Transactional Replication, daha ziyade sunucular arası kullanılan bir Replication yöntemidir.

Transactional Replication’ ın kullanımı, aşağıdaki durumlarda uygun olacaktır:

- Eğer Publisher’ da gerçekleşen değişikliklerin, gerçekleşir gerçekleşmez
Subscriber’ lara iletilmesini istiyorsanız;

- Eğer toptan değil de, her veri değişikliğinin tek tek Abone’ de uygulanmasını
istiyorsanız (Örn: Publication’ daki bir tabloda bulunan bir veri, Abonelere
ulaştırılmadan önce 5 kere değişmişse, her değişiklik sırasıyla Abone’ de de
uygulanır. Yani sadece 5nci değişiklik yapılmaz.);

- Eğer Publisher’ da çok sık olarak Insert, Update ve Delete işlemleri
uygulanıyorsa;

- Eğer Publisher veya Subscriber, SQL Server değil de Oracle gibi başka bir
uygulama ise.

Transactional Replication varsayılan olarak tek taraflı çalıştığı için, yani Publisher’ dan Subscriber’ a gönderilen veriler sadece Publisher’ da günellenebildiği için ve Subscriber’ daki veritabanında yapılacak değişikliklerin Publisher’ daki veritabanına bir etki yapmayacağı için Subscriber’ daki verilere Salt Okunur olarak davranılmalıdır. Aksi takdirde, Publisher’ daki verilerle Subscriber’ daki veriler birbirlerini tutmayacaktır.

Transactional Replication’ da, Subscriber’ ların da veri güncellemesi yapabileceği bir biçim vardır. Updatable Subscriptions for Transactional Replication yöntemi kullanılarak, Abone’ lerin de güncelleme yapması ve bu güncellemelerin Publisher’ a da yansıtılması sağlanabilir. Fakat bu yöntem daha ziyade arada sırada değişiklik yapılan Abone’ lerde kullanılmalıdır.

Bir de, SQL Server 2005 ile birlikte gelen yeni bir yöntem olan Peer to Peer Replication yöntemi mevcuttur. Bu yöntem ise her noktadaki bilgilerin aynı olması ve her noktanın hem Publisher hem de Subscriber gibi davranmasını istediğinizde kullanılabilir. Aynı satır, her seferinde sadece bir nokta tarafından değiştirilebilir.


Merge Replication:
Merge Replication da, Transactional Replication gibi tipik olarak Yayın nesnelerinin Şema ve verilerin Abone’ lere gönderilmesiyle başlar. Devamında Publisher’ da ve Subscriber’ da yapılacak Şema ve veri değişiklikleri, Trigger’ lar vasıtasıyla takip edilir. Abone, Yayıncı ile yapacağı veri eşleştirmesini, ağa bağlandıktan sonra yapar; son eşleştirmeden bu yana kendinde (yani Abone’ de) ve Yayıncı’ da yapılan tüm değişiklikler iki tarafa da işlenir ve eşleştirme yapılmış olur. Merge Replication, daha ziyade Sunucu ve İstemci’ ler arası kullanılan bir Replication yöntemidir.

Aşağıdaki koşullar gerçekleştiğinde, Merge Replication’ ı kullanmak avantajlıdır:

- Bir çok Abone’ nin aynı veriyi değişik zamanlarda güncellemesi ve
değişiklikleri Yayıncıya ve diğer Abonelere yapması gerektiğinde;

- Abone’ lerin veriyi alması, veri üstünde çevrimdışıyken değişiklik yapması ve
daha sonra Yayıncı ile diğer Abonelere eşletirme yapması gerektiğinde;

- Her abonenin, verinin farklı bir bölümüne ihtiyaç duyduğu zaman;

- Transactional Replication’ ın aksine, Abone’ de 5 değişiklik yapıldığında,
Yayıncı’ ya sadece beşinci değişikliğin ardından çıkan sonuç gönderilir. Yani
değişiklikleri sayı ile gösterirsek, bir tablonun 4. satırında 5 defa
değişiklik yapıldı diyelim, Transactional Replication’ da, Yayıncı’ ya
bu beş değişiklik de tek tek gönderilirdi; ama Merge Replication’ da, Abone’
de 1., 2., 3., 4. değişiklik yapılır; ama Yayıncı’ ya, kaydın sadece 5.
değişiklik yapılmış hali gönderilir.

Merge Replication yöntemi, değişik noktalara değişik zamanlardayken ve çevrimdışıyken değişiklik yapma şansı verdiği için, aynı veri iki noktada ve aynı zamanda değiştirilmiş olabilir. İki nokta da eşleştirme yapmaya kalktığı zaman, çatışma (Conflict) yaşanacaktır. Bunun da Merge Replication’ da farklı çözümleri bulunmaktadır. Bu makaledeki konumuz çatışmaları kapsamıyor, başka bir makalede değinirim bu konuya da.

Merge Replication’ ı, el terminallerinin, dizüstü bilgisayarların vs. kullanıldığı ortamlarda kullanabiliriz. Meselâ büyük bir firmanın pazarlamacılarının sabah şirketten çıktığını, gündüz el terminalleriyle bakkallardan ve restaurantlardan sipariş aldığını ve akşam da şirkete gelip, el terminallerindeki verileri veritabanına aktardıklarını düşünebiliriz...


Selamlar!
Ekrem Önsoy

9 Ekim 2007 Salı

Database Mirroring (Sürekli Kullanılabilirlik - 2)

Database Mirroring

Merhaba,

Bu makalemde, Database Mirroring çözümünün nerede, ne zaman ve nasıl kullanılabileceğinden bahsedeceğim.

Bundan önceki yazımda SQL Server Failover Clustering konusundan bahsetmiştim. Sürekli Kullanılabilirlik seçenekleri olarak SQL Server Fileover Clustering ve SQL Server 2005 SP1 ile birlikte gelen Database Mirroring en çok kullanılan seçeneklerdir. Aslında Database Mirroring, SQL Server 2005’ in RTM (Release to Manufacturer) versiyonunda da vardı. Fakat Microsoft tarafından sadece test amaçlı kullanılması öneriliyordu. SQL Server 2005’ in birinci Servis Paketi ile herkes tarafından kullanılabilir olduğu açıklandı ve kullanılması teşvik edildi. Database Mirroring özelliği sadece SQL Server’ ın Standard ve Enterprise Edition’ larında kullanılabilir durumdadır. SQL Server Express Edition ise, Şahit Rolü için kullanılabilir.

Database Mirroring’ in özelliklerinden bahsettikten sonra Database Mirroring’ in, SQL Server Failover Clustering’ e karşı eksileri ve artıları konusundan da bahsedeceğim. Meselâ Failover Clustering yerine, neden ve ne zaman Database Mirroring Kullanabiliriz? Database Mirroring’ in, Failover Clustering’ e karşı avantajları ve dezavantajları nelerdir?


Database Mirroring’ in Çalışma Biçimleri:

Database Mirroring’ in üç adet çalışma biçimi bulunmaktadır. Bunlar:
- High Availibility Mode
- High Performance Mode
- High Protection Mode’ dur.

Her çalışma biçimi, değişik durumlara göre uygulanabilir. Bununla birlikte, High Protection Mode, Microsoft tarafından çok gerekmedikçe önerilmiyor. Nedenini konu başlıklarından bahsederken anlatacağım. Şimdi çalışma biçimlerinden biraz daha ayrıntılı bahsedelim.

1- High Availibility Mode: Otomatik Geçiş özelliği sadece bu çalışma biçiminde bulunmaktadır. Bu çalışma biçiminin çalışma mantığını aşağıdaki Şekil 1’ de betimlemeye çalıştım:

Şekil-1


Şekil 1’ de de gösterdiğim gibi, High Availibility Mode’ da, tüm sunucular sürekli birbirleriyle haberleşiyorlar. Bu topolojide, etkin olarak kullanılan veritabanı Birincil SQL Server’ dadır. Fakat Birincil sunucudaki veritabanında bir değişiklik yapılırken, aynı değişikliğin Kopya SQL Server’ daki veritabanında da yapıldığından emin olunur. Bu da senkron bir sistem demektir. Sistem, aynı işlemin iki veritabanında da yapılmasından emin olmak zorundadır. Bu nedenle, Birincil veritabanı, ancak işlemin Kopya veritabanında da gerçekleştirildiğinden emin olduktan sonra diğer işlemleri işlemeye başlayabilir.Bu senkronizasyon zorunluğu nedeniyle de bazı performans sorunları yaşanabilir. Bu, kesinlikle dikkate alınmalıdır.

SQL Server Express Edition’ ın, Şahit Rolü için kullanılabileceğinden önceden bahsetmiştim. Fakat Birincil ve Kopya sunucularda SQL Server’ ın Standard veya Enterprise Edition’ larının yüklü olması gerekmektedir.

Şahit, sunucuların çalıştığından emin olmak için kullanılır. Otomatik Geçiş işlemi, Şahit sayesinde gerçekleştirilir. Şahit, Birincil ve Kopya rollerini üstlenen sunuculara belirli aralıklarla PING atar. Böylece çalışıp çalışmadıklarını kontrol eder. Şayet Birincil sunucudan attığı PING’ e cevap alamazsa, bu rolü otomatik olarak Kopya sunucuya devreder ve eskiden Kopya rolünü oynayan sunucu, artık Birincil rolü alır ve kullanıcılar da bu veritabanını kullanmaya başlarlar. Peki kullanıcılar, daha doğrusu, kullanıcıların kullandığı program bunu nereden bilecek? SQL Server Native Client ve ADO.Net 2.0 bunu hallediyor.

Peki, eski Birincil sunucu tekrar ayağa kaldırıldığında ne mi oluyor? Şu oluyor, eski Birincil sunucu, artık Kopya sunucu rolünü üstleniyor ve yeni Birincil sunucu ile eşleşiyorlar. Tabii ki illa da eski Birincil sunucuyu kullanacağım derseniz, bu sunucuyu ayağa kaldırdıktan sonra ve eşleştirmeyi (senkronizasyon) de tamamladıktan sonra el ile Geçiş yapabilirsiniz. Böylece eski Birincil sunucunuz yine Birincil sunucu olur.


2- High Performance Mode: Bu çalışma biçiminde Otomatik Geçiş özelliği yoktur. Sadece elle geçiş yapabilirsiniz. Ayrıca bu, asenkron bir moddur. Aşağıda gene bir şekil yaptım, onun üzerinden anlatmaya çalışayım.

Şekil-2


Görüldüğü gibi, bu çalışma biçiminde bir Şahit bulunmamaktadır. Sadece iki rol söz konusudur. Ayrıca, High Availibility Mode’ dan farklı olarak, senkron değil, asenkron bir işlem süreci söz konusudur. Bunu bir örnekle açıklayayım: Meselâ kullanıcılar Birincil sunucuda bir işlem yaptıklarında, Birincil sunucu, bu işlemi gerçekleştirmek için Kopya sunucudan gelecek teyidi beklemez. Bu da herhangi bir performans sorununa neden olmayacak demektir. Fakat bununla birlikte, Kopya sunucunun, Birincil sunucu ile ne derecede eşleşmiş olduğunu da takip edemeyeceksiniz. Yani Kopya sunucusunda veri kaybı söz konusu olabilir.

Veri kaybının söz konusu olması, ayrıca Otomatik Geçiş niteliğinin de bulunmaması nedeniyle, “üretim” ortamlarında bu çalışma biçiminin kullanılmasını şahsen önermiyorum.


3- High Protection Mode: Bu çalışma biçimi bazı yönleriyle High Availibility Mode’ a benzer. Hatta tek farklılıkları, bu çalışma biçiminin Otomatik Geçiş özelliğinin olmaması da diyebiliriz.

Bu çalışma biçiminde de Şahit bulunmamaktadır. Gene Birincil ve Kopya rollerini üstlenen suncular birbirleriyle haberleşirker. Senkron bir çalışma söz konusudur. Birincil’ e gelen işlem, Kopya’ da da işlenmeden Birincil’ deki diğer işlemlere geçilmez.

Bu açıdan, eğer bu çalışma biçimini kullanacaksanız hem performans yükünü hem de Otomatik Geçiş özelliğinin olmamasını kabul edeceksiniz demektir. Madem olası performans yükü göze alınıyor, o zaman High Availibility Mode’ u kullanmanız çok daha işe yarar olacaktır.


Database Mirroring’ in Kurulumu:

Database Mirroring sistemini kurmak çok kolay bir işlemdir. T-SQL dili kullanılarak yapılabildiği gibi, doğrudan SQL Server Management Studio kullanılarak da yapılabilir. Gözönünde bulundurulması gereken bazı şartlar vardır. Genel olarak bunları aşağıda yazdım.

Bir veritabanı, sadece bir Database Mirroring işleminde kullanılabilir.

Database Mirroring işlemi uygulanacak veritabanlarının Recovery Model’ larının da FULL olması gerekmektedir.

Database Mirroring işlemi uygulamak istediğiniz veritabanınının bir yedeğini aldıktan sonra, bu yedeği Kopya rolünü üstlenecek olan SQL Server’ da açın. Yalnız, yedeği konuşlandırırken Recovery State’ inin (Onarım Durumu) NORECOVERY olmasına dikkat edin. Bu, Database Mirroring için zorunlu bir ayardır.

Not: Sistem veritabanlarına (master, msdb, model, tempdb) Database Mirroring işlemi uygulayamazsınız.


Database Mirroring’ in, Failover Clustering’ e karşı avantajları:

- Database Mirroring’ te, Failover Clustering’ te gerekli olan ek donanıma ihtiyaç yoktur (SAN, HBA vb.). Eldeki normal donanımlarla da Database Mirroring sistemi kurulabilir.

- Failover (geçiş) işlemini çok daha erken tamamlar. Bu süre yaklaşık olarak 2-3 saniyedir. Meselâ Failover Clustering kullanıldığında geçiş işlemi ortalama 13-17 sn. arasında bir zamanda tamamlanır. (Not: Failover Clustering’ te, hata durumuna düşen sistemdeki servisler kapanır ve bu servisler diğer çalışan düğümde çalıştırılmaya başlanır.)

- SQL Server Failover Clusterin’ te sadece sürekli kullanılabilirlik vaadedilirken, Database Mirroring’ te hem sürekli kullanılabilirlik, hem de veritabanının canlı bir kopyasının yedeği vaadedilmektedir.


Database Mirroring’ in, Failover Clustering’ e karşı dezavantajları:

- Database Mirroring, sadece High Availability Mode kullanıldığında otomatik geçiş (Automatic Failover) yapabilir. Bu mod da senkron bir mod olduğundan dolayı veritabanına karşı yapılan işlemlerin işlenişinde ek performans yüküne neden olabilir. İşlem akışı, ihtiyaçlara göre iyi analiz edilmelidir.

- Database Mirroring’ te kullanılan Kopya rolündeki veritabanı NORECOVERY durumunda olduğu için, raporlama amacıyla doğrudan kullanılamaz. Ancak, Database Snapshot kullanılmak suretiyle raporlama için kullanılabilir. Database Snapshot özelliği ise sadece SQL Server Enterprise Edition’ da bulunmaktadır. (Developer Edition’ da da bulunmaktadır, fakat bu sürümü üretim ortamında kullanmanız yasa dışıdır.)

- Bir veritabanına sadece bir kere Database Mirroring işlemi uygulanabilir. Yani sadece bir kopyası başka bir sunucu üzerinde Database Mirroring kullanılarak tutulabilir.


Özet

Aşağıdaki koşullar oluştuğunda Database Mirroring’ i kullanmanızı tavsiye edebilirim.

- Eğer iki adet sunucunuz varsa ve bir tane makineyle de Şahit görevini kullanabilecekseniz,

- Ek donanım almak için yeterli bütçeniz yok ise,

- İkincil sunucunuzda tuttuğunuz veritabanının yedeğini raporlama için kullanmayacaksanız veya sürekli güncel bir şekilde raporlama bilgisi gerekmeyecekse, (Burayı biraz daha açmakta yarar var. Raporlama bilgisinin güncelliğinden kastettiğim şu; hatırlarsanız raporlama için Database Snapshot kullanmanız gerekir demiştim ve bu da sadece Enterprise Edition’ da vardı. Burada Database Snapshot’ tan bahsetmeyeceğim, çünkü konumuz dışında bir konu. Ama veritabanındaki güncel bilgiye ulaşmak için Database Snapshot’ ı ara ara güncellemeniz gerekir. Bu da ek iş gücü demektir. Hem de daha yüksek lisans ücreti).



--
Ekrem Önsoy

SQL Server 2005 Failover Clustering (Sürekli Kullanılabilirlik - 1)

Sisteminiz İçin En Uygun Sürekli Kullanılabilirlik Sistemini Seçmek

Makalem daha ziyade, Veritabanı Yöneticileri “VTY” (İngilizcesi de “Database Administrator” dır ve kısaltması da ”DBA” dir. ) ‘ ne yöneliktir. Terimleri ve kavramları daha iyi anlayabilmek için Bilgi Teknolojileri konusuna biraz aşina olmanız, donanım hakkında ve SQL Server 2005 hakkında genel bilgi sahibi olmanız gerekir.

Bu yazı dizimde size, SQL Server 2005 ile birlikte kullanabileceğiniz Sürekli Kullanılabilirlik (High Availibility) sistemlerinden bahsedeceğim; sistemlerin kurulumlarının tek tek nasıl yapıldığını anlatmaktan veya her şeyin ayrıntısına inmekten ziyade, “Neden?”, “Hangi durumlarda?” ve “Ne zaman?” kullanılabileceklerini anlatmaya çalışacağım. Zaman zaman da ayrıntı gibi görünen güzel tiyolar da vereceğim. Amacım, bu kavramlar hakkında genel olarak bilgi sahibi olmanızı sağlamak. Yazı dizimin en bölümünde de anlattığım sistemler arasındaki artı ve eksileri özetleyeceğim. Böylece hangi teknolojinin sizin için avantajlı olduğunu daha kolay kavrayabileceğinizi düşünüyorum.

Sürekli Kullanılabilirlik nedir?
“Sürekli Kullanılabilirlik” kavramını daha iyi anlatabilmek için sizinle bir örnek paylaşmak istiyorum.

7\24 çalışan ve alış-veriş işlemleri yapılan ve adı da www.aldım-verdım.kom.tr olan bir internet sitesi düşünün. Bir tıraş makinesi satın almak istiyorsunuz ve ilk önce, önceden de alışveriş yaptığınız ve güvendiğiniz bu siteye bakmak istediniz; ama bir de bakıyorsunuz ki site çalışmıyor! Neden? Ya bir donanım arızası, ya bir sistem içi kullanıcı hatası, ya yazılım\donanım bakımı vb. sonuçta bir kesinti var ve sisteme bağlanamıyorsunuz. Ne yaparsınız? Eğer aceleniz varsa ve hemen bir sonuca varmak istiyorsanız, o zaman başka bir alış veriş sitesine bakarsınız ve belki de gördüğünüz seçenekler size cazip gelir ve siparişinizi o siteye verirsiniz.

Sürekli Kullanılabilirlik sistemi olmayan www.aldım-verdım.kom.tr ne kaybetti? Müşteri, bir anlamda da para kaybetti. Belki de bahsi geçen müşteri alışveriş yaptığı diğer siteden memnun kalacak ve bir daha www.aldım-verdım.kom.tr ‘den alışveriş yapmayacak. Tam tersi, kötü olarak etrafına reklamınızı da yapabilir.

İşte bu gibi durumları yaşamamak için, bir Sürekli Kullanılabilirlik sistemi kurmak ve ileriye dönük, doğru bir sistem seçimi yapmak kaçınılmaz ve zorunludur.

Elbette kimse işlerinin kesintiye uğramasını istemez, ama...
“Kim işlerinin yarıda kalmasını ve boş boş beklemeyi, bunun sonucunda mali kayıplar yaşamayı ister ki?” diye düşünebilirsiniz. Aslında kimse işinin bölünmesini elbette istemez; ama ya yeterli bilgi donanımına sahip olmayan (bu nedenle de ne yapabileceğinden bihaber) personelden dolayı ya da Bilgi İşlem bölümüne ayrılan yetersiz bütçeden dolayı Sürekli Kullanılabilirlik için gerekli yatırımlar yapılmaz.

Her şeyin olduğu gibi, bilgisayarlarımızda veya sunucularımızda kullandığımız donanım bileşenlerinin de sınırlı ömürleri vardır ve bu donanımlardan birinde veya birkaçında herhangi bir sorun yaşandığında, en azından bir Sürekli Kullanılabilirlik sisteminin kurulmadığı ortamlarda kesinti sorunları yaşanır. Yani beklenmeyen başa gelir. Bu gibi iş kesintilerinden kaçınmak için, Sürekli Kullanılabilirlik çözümlerini kullanırız.

SQL Server 2005 ile birlikte kullanabileceğimiz Sürekli Kullanılabilirlik seçenekleri:
- SQL Server Failover Clustering,
- Database Mirroring,
- Replication ve
- Log Shipping’
tir.

Hesinin de duruma göre artıları da var eksileri de. Hangisini seçmek isteyeceğiniz de, başta dediğim gibi ihtiyacınıza göre değişir. Yukarıda bahsettiğim Sürekli Kullanılabilirlik seçeneklerinden tek tek bahsedeceğim. Her seçenek sırayla ayrı bir yazı olarak yayınlanacak.

SQL Server Failover Clustering
Eğer gerekinimleriniz ve ihtiyaçlarınız donanımsal bazda sürekli kullanılabilirlik gerektiriyor ve etkin olarak kullanılan sunucunuzda donanımsal bir arıza olduğunda da yedek sunucunuza otomatik olarak geçiş yapmak istiyorsanız ve bununla birlikte bütçeniz de çok kısıtlı değilse SQL Server Failover Clustering tam size göre! Bu noktada, Otomatik Geçiş (Automatic Failover) hakkında az çok bilgi sahibi olan arkadaşlar hemen “Neden Database Mirroring değil?” diyebilir; o noktaya da daha sonra değineceğim.

Aslında Clustering (küme), SQL Server’ a has bir özellik değildir. SQL Server Failover Cluster’ ı, MSCS (Microsoft Cluster Services- Microsoft Küme Servisleri) üzerine kurarız. Yani SQL Server Failover Cluster sistemini kurmadan önce, Windows Server’ da bulunan Küme Yöneticisi (Cluster Administrator) ‘ni kullanarak MSCS’ i yapılandırmamız ve gerekli ayarları da yapmamız gerekir. (MSDTC servisinin kurulumu, Kaynak ve Grup ayarları, Otomatik Geçiş ve Otomatik Geri-Geçiş sistemlerinin ayarları gibi)

Her Kümenin bir Quorum Disk’ i vardır. Bu diskte, Küme sistemi hakkında üretilen kayıtlar (log) tutulur. Bu kayıtlar geçiş bilgilerini barındırır. SAN (“Storage Area Network”, yani bir veya bir çok SCSI veya SATA diskten oluşan bir depolama birimi) üzerinde 100MB’ lık bir disk alanı bile kâfidir. Bununla birlikte Microsoft 250MB önerir.

SQL Server Failover Clustering’ in iki biçimi vardır. Bunlar: “Active\Active” ve “Active\Passive” dir.



Yukarıdaki şekilde, iki düğümden (“Node” yani iki SQL Server sunucusu), bir SAN ‘dan oluşan SQL Server “Active\Active” Failover Clustering şeması görüyorsunuz.

Düğümlerde yerel diskler mevcuttur. Fakat veritabanı dosyaları ve Küme kayıt (log) dosyaları SAN üzerindeki Quorum Disk’ te saklanır. Nedeni de çok basit, Küme içerisinde bulunan Düğüm1 veya Düğüm2’ de bir sorun çıktığında, sorunlu düğümdeki servisler Otomatik Geçiş ile sağlıklı düğüm üzerinde çalışmaya başlarlar. Veritabanı dosyaları da SAN’ da olduğu için sağlıklı düğüm, veritabanı dosyalarını istemcilere kullandırtmaya devam edebilir. Eğer veritabanı dosyaları düğümlerin yerel disklerinde olsaydı, o zaman sorunlu düğüm kapandığında ve ulaşılamaz olduğunda Küme sisteminin bir anlamı kalmayacaktı; çünkü bozulan düğümün servisleri sağlıklı düğüme geçseler bile veritabanları, bozulan düğümün yerel diskinde olduğu için istemciler ulaşmaları gereken dosyalara ulaşamayacaklardı.

Düğümler arasında Kalp Atışı (Heartbeat) denilen bir sistem mevcuttur. Bu sistemi, iki düğüm arasında bir “Crossover” kablo bağlayarak veya sadece Küme içerisindeki düğümlerin yer alacağı bir HUB veya Switch kullanarak da gerçekleştirebilirsiniz. Maksat, kalp atışını dinleyerek, hangi sunucunun yaşayıp, hangisinin öldüğünü (yani o an çalışmadığını) tespit etmektir.

En fazla 8 düğümden oluşan bir Küme oluşturabilirsiniz. Bu arada, Küme sistemini kullanabileceğiniz işletim sistemleri Windows Server 2003 Enterprise ve Datacenter Edition’ lardır. SQL Server 2005’ in Standard Edition’ ınında 2, Enterprise Edition’ ınında da 8’ e kadar düğüm kullanabilirsiniz.

Windows Server 2003’ ün Edition’ larındaki farklılıkları görmek için http://www.microsoft.com/technet/windowsserver/evaluate/features/compare.mspx adresine göz atabilirsiniz.

SQL Server 2005 Edition’ larındaki farklılıkları görmek için ise http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx adresine göz atabilirsiniz.

Active\Active yapı için iki SQL Server lisansına ihtiyacınız olacak. Çünkü iki sistemde etkin olarak çalışıyor. Ama Active\Passive’ de sadece bir lisans yeterli oluyor. Peki nedir Active\Active ile Active\Passive arasındaki fark?

İki düğümü de etkin şekilde kullanmak istediğimizde, yani meselâ Düğüm1’ i daha ziyade veritabanına veri yazmak (OLTP), Düğüm2’ yi ise raporlama (OLAP) için (veya başka bir amaçla da olabilir tabii ki; ana tema, iki düğümün de etkin olarak kullanılmasıdır) kullanacağınız zaman Active\Active bir yapı kullanabilirsiniz. Bu yapıda iki düğüm de etkin olarak çalışmaktadırlar ve her düğümün kendi sahip olduğu ve SAN üzerinde bulunan Paylaşılmış Disk’ i vardır. Düğüm1’ de donanımsal olarak bir arıza başgösterdiğinde, Düğüm1’ in servisleri Otomatik Geçiş ile Düğüm2’ ye geçecektir. Bu noktada da şöyle bir sorun oluşabilir. İki düğümün de donanımsal olarak aynı özelliklere haiz olduğunu varsayalım (ki tavsiye edilen budur). Düğüm1’ in %70 kapasiteyle çalıştığını ve Düğüm2’ nin de %60 kapasiteyle çalıştığını düşünün. Düğüm1’ in servisleri Düğüm2’ nin üzerine geçtiğinde, Düğüm2’ nin üzerine binen yük %130 olacaktır ki, bu da darboğaz demektir. İster hafızada olsun, ister disklerde, isterse işlemcide. Sisteminiz kitlenecek ve gelen isteklere cevap veremez duruma gelecektir. Bu nedenle, Active\Active yapıda bu noktaya çok dikkat etmek gerekir.

Eğer Düğüm1’ i hem veri yazmak hem de raporlama için kullanacaksanız ve sunucunuz da bu yükü kaldırabiliyorsa ve “Düğüm2 boşa yatsa da olur, yeter ki vakti geldiğinde Otomatik Geçiş işlemi gerçekleştirilsin ve ben de çalışmalarıma devam edebileyim” diyorsanız o zaman Active\Passive’ de size göre. Bu yapıda sadece bir Paylaşılmış Disk vardır. Active\Passive’ te de iki düğümdeki donanımın da aynı olmasına dikkat edin. Meselâ Düğüm1’ in hafızasının 4GB, Düğüm2’ nin ise 2GB olduğu bir senaryo düşünün. Düğüm1’ in de mevcut hafızasının %75’ ini kullanarak çalıştığını varsayalım. O zaman Düğüm1’ de bir sorun olduğunda ve Düğüm2’ ye geçiş yapıldığında ne olur? Tabii ki hafıza darboğazı sorunu ile karşı karşıya kalırsınız ki, inanın hiç de hoş olmaz.

SQL Server Failover Clustering çözümü size sadece Sürekli Kullanılabilirlik işlevini kazandırır. Felâket Önleyici (Disaster Recovery, Redundancy) gibi bir niteliği yoktur. Yani Paylaşılmış Disk’ lerinizde oluşabilecek bir veri kaybını, tek başına Failover Clustering kullanarak önleyemezsiniz. Replication, Database Mirroring ve Log Shipping Felâket Önleyici sistemler olarak kullanılabilirler. İlgili konularda bu teknolojilerin bu niteliklerinden de bahsedeceğim.

SQL Server Failover Clustering’ i, Replication, Database Mirroring ve Log Shipping çözümleriyle birlikte de kullanabilirsiniz.

Meselâ Active\Active bir yapıda, Düğüm2’ yi raporlama amacıyla kullanabileceğimizden bahsetmiştim. İşte bunu, yukarıda saydığım çözümlerden biriyle yapabilirsiniz. Bununla birlikte, raporlama amacıyla kullanılabilecek en iyi çözüm bence Transactional Replication’ dır. Neden diğer çözümlerin değil de bu çözümün en iyisi olduğunu düşündüğümü ve diğer çözümlerin artı ve eksilerini, diğer çözümleri de anlattıktan sonra bu yazı dizimin en sonunda anlatacağım.

Konu hakkındaki aklınıza takılan soruları, yaşadığınız sorunları veya eleştirilerinizi lütfen bana bildirin.


--
Ekrem Önsoy

SQL Server 2005' te Veritabanı Oluşturma...

Bu makalemde size SQL Server 2005' te T-SQL ve SQL Server Management Studio kullanarak temel olarak nasıl yeni bir veritabanı oluşturulabileceğini adım adım anlatacağım.

T-SQL kullanarak yeni bir veri tabanı oluşturma

SQL Server Management Studio' yu açın, çalıştığınız Instance' a ait gerekli Login bilgilerini girerek sisteme giriş yapın. Instance' ınız açıldıktan sonra, varsayılan olarak ekranın sol üst köşesinde bulunan "New Query" düğmesine tıklayın. Daha sonra aşağıdaki T-SQL kodunu girin.

Yalnız, kodu çalıştırmadan önce şuna dikkatinizi çekmek istiyorum ki, ben deneme için "D:" sürücümde "SQLDeneme" isimli bir klasör oluşturdum. Aşağıdaki kod çalıştırıldıktan sonra, veritabanı dosyası olan "TransactTestDB.mdf" ve Transaction Log dosyası olan "TestDB_Log.ldf" dosyaları "D:\SQLDeneme" klasörüne kaydedecektir. Eğer istiyorsanız bu klasörü ve diğer seçenekleri kendi seçiminize göre değiştirebilirsiniz.

Şimdi kodumuzu çalıştırabiliriz. Diğer kavramların açıklamalarını hemen koddan sonra yapacağım.

CREATE DATABASE TestDB
ON (
NAME = 'TestDB_Data',
FILENAME = 'D:\SQLDeneme\TransactTestDB.mdf',
SIZE = 20 MB,
FILEGROWTH = 0)
LOG ON (
NAME = 'TestDB_Log',
FILENAME = 'D:\SQLDeneme\TestDB_Log.ldf',
SIZE = 5 MB,
FILEGROWTH = 0)

Bu kodu çalıştırdıktan sonra, kodu yazdığınız Query penceresinin hemen altındaki Messages penceresinde "Command(s) completed successfully." yazan bir mesaj göreceksiniz. Bu mesajın anlamı "istediğiniz kodlar ve komutlar hatasız olarak çalıştırıldı" dır.

"NAME"
Karşısına, oluşturmak istediğiniz veritabanının adını yazın.

"FILENAME"
Karşısına, oluşturmak istediğiniz veritabanınızın veritabanı dosyasının nereye saklanmasını istiyorsanız orayı yazın. Unutmayın ki, belirttiğiniz yoldaki tüm klasörler önceden oluşturulmuş olmalıdır. Eğer belirttiğiniz yoldaki klasörlerden bir veya birkaçı mevcut değil ise, SQL Server bu klasörleri kendisi oluşturmayacaktır ve kod hata verecektir.

"SIZE"
Karşısına veritabanınızın ilk oluşturulma sırasında olmasını istediğiniz boyutunu girin.

"FILEGROWTH" = Veritabanınız zamanla büyüyecektir ve nihayet SIZE ile belirleyeceğiniz sabit boyuta ulaşacaktır. Filegrowth, bu sınıra gelindiğinde devreye girer. Veritabanının boyutunun ne kadar arttırılacağı Filegrowth ile belirlenir. "0" değeri, Filegrowth özelliğinin kullanılmayacağı anlamına gelir. "20%" değeri girerek veritabanı boyutu "SIZE" sınırına gelindiğinde, "SIZE" değerinin %20' si kadar büyüyeceği; "5 MB" değeri girilerek de, bu sınıra gelindiğinde 5 MB büyüyeceği belirtilmiş olur.

Veritabanı dosyasına *.mdf, Transaction Log dosyasına ise *.ldf uzantısı vermem belki dikkatinizi çekmiştir. Bu uzantıları özellikle verdim, çünkü standart olarak Primary Filegroup' taki veritabanı dosyalarına *.mdf, Secondary ve diğer Filegroup' taki veritabanı doslarına ise *.ndf uzantıları verilir. Ayrıcas Transaction Log dosyalarına da *.ldf uzantısı verilir.

Yeni bir veritabanı oluşturduğumuzda, ki örneğimizde de, belirtmememize rağmen "TestDB_Data" isimli veritabanımız Primary dosya grubunun üyesi olarak oluşturulmuştur. TestDB_Data' nın üyeliğini değiştiremezsiniz. Dosya gruplarını (Filegroup) daha sonraki makalelerimde anlatacağım. Her veritabanında muhakkak bir "Primary Filegroup" ve bir adet "Transaction Log" bulunmaktadır.

Kısaca Dosya Grubu (Filegroup)
Dosya grupları temel olarak fiziksel olmaktan ziyade, mantıksal bir işlemdir. Veritabanlarını dosyalara böleriz ve bu dosyaların en çok işlenilenlerini de farklı sabit disklere koyarız ki, veritabanımızın performansını arttıralım. Bu konuya ayrıntılı olarak daha sonra döneceğim.

Transaction Log
Log dosyaları veritabanları için hayati öneme haizdirler. Bir veritabanına yapılacak olan her işlem, ilk önce istemci bilgisayardan yola çıkar, daha sonra SQL Server' a ulaşır, burada doğruluğu denetlenir, daha sonra Transaction Log' a işlenir ve en son olarak da veritabanındaki ulaşılmak istenen nesneleri etkiler. Yani her komut ilk önce Transaction Log' lara işlenir. Bu da, yapılan her işlemin geri alınabileceği anlamına gelir.

SQL Server Management Studio kullanarak yeni bir veritabanı oluşturma

Yazımın devamı olan bu bölümde de, birlikte adım adım SQL Server 2005' in yönetim arayüzü olan Management Studio kullanarak yeni bir veritabanı oluşturacağız. SQL Server 2000' de Enterprise Manager vardı ve ben ilk SQL Server 2005' imi kurduğumda Management Studio' yu kurmamışım ve Enterprise Manager' ı göremediğimde çok şaşırmıştım :) Neyse...

Başlat / Programlar / Microsoft SQL Server 2005 / SQL Server Management Studio' ya tıklayarak arayüzü açın. Gerekli Login bilgilerini girerek Instance' a giriş yapın.

Object Explorer penceresindeki Databases' ın üzerinde farenizin sağ tuşuna tıklayarak açılan menüden New Database' e tıklayın. (Resim-1)

Resim-1


Aşağıdaki resimde (Resim-2) gösterildiği gibi veritabanı adını DenemeDB yazarak ve önceki sayfada öğrendiğiniz diğer özelliklerden istediğinizde gerekli değişiklikleri yaparak OK düğmesine tıklamak suretiyle DenemeDB veritabanını oluşturabilirsiniz.

Aşağıdaki Add ve Remove düğmeleri vasıtasıyla veritabanınıza yeni dosyalar ekleyip, silebilirsiniz.

Pencerenin sol tarafındaki "Select a page" bölmesindeki Options sekmesinde veritabanı hakkında gerekli ayarlamaları yapabilir, Filegroups sekmesinde ise Dosya grubu ayarlarını yapabilirsiniz.

Resim-2


--
Ekrem Önsoy

Microsoft' un Yeni Nesil Sertifika Sistemi

MICROSOFT' UN YENİ NESİL SERTİFİKA SİSTEMİ

Yeni nesil Microsoft sertifikasyon sistemi 3 seri ve 4 temel sertifikadan oluşuyor.

Seriler:
- Architect Series
- Professional Series
- Technology Series

Sertifikalar:
- Microsoft Certified Architect (MCA)
- Microsoft Certified IT Professional (MCITP)
- Microsoft Certified Professional Developer (MCPD)
- Microsoft Certified Technology Specialist (MCTS)


ARCHITECT SERIES: MICROSOFT CERTIFIED ARCHITECT (MCA)

MCA programı, IT mimarisindeki en iyi uzmanlara yöneliktir. Bu uzmanların IT endüstrisinde asgari olarak 10 senelik ileri seviye tecrübeleri vardır. Bu uzmanlar, üç yıl veya daha fazla mimarlık pratiği olan, güçlü teknik bilgi ve yönetici yetenekleri olan seçkin bir topluluktur. Diğer sertifika sistemlerinden farklı olarak, bu sertifika önceki mimarlar tarafından önerilme yoluyla verilecektir.

Adaylar olarak, profesyoneller, yeteneklerini ve bilgilerini Denetim Kurulunun (Review Board) onayına sunacaklar. MCA sertifikası, ancak bu Kurul onayıyla kazanılabilir. Adaylar, bir çok farklı teknoloji kullanarak iş yaşamındaki sorunları nasıl çözdüklerini sergileyecek ve başarı veya başarısızlıkları açıklamak için, projelerinde kullandıkları iş metrik ve önlemlerini sunacaklar.

Sertifika sistemi 3 aşamadan oluşuyor:
- Yazılı Testler (Written Tests),
- Yeterlilik Laboratuarı (Qualification Lab),
- Denetim Kurulu(Review Board)

Microsoft Certified Architect (MCA) Sertifikaları:
- Microsoft Certified Architect: Infrastructure
- Microsoft Certified Architect: Solutions
- Microsoft Certified Architect: Messaging


PROFESSIONAL SERIES:

MICRISOFT CERTIFIED IT PROFESSIONAL (MCITP)

MCITP kendi içerisinde dört kola ayrılıyor. Bunlar: Database Developer, Database Administrator, Business Intelligence Developer ve Enterprise Support Technocian' dır. Ayrıntılar aşağıdadır.

IT Professional: Database Developer
MCITP Database Developer adayları, önce (tek sınav) MCTS: SQL Server 2005 (70-431) almalılar. Sonra da iki temel sınavı geçmeliler.

EXAMS:
70-431: TS: Microsoft SQL Server 2005 - Implementation and Maintenance
70-441: PRO: Designing Database Solutions by Using Microsoft SQL Server 2005 Open License 6.0
70-442: PRO: Designing and Optimizing Data Access by Using Microsoft SQL Server 2005

MOCs:
70-431: 2779, 2780
70-441: 2781, 2782
70-442: 2781, 2783, 2784


IT Professional: Database Administrator
MCITP Database Administrator adayları, önce MCTS: SQL Server 2005 (70-431) sınavını geçmeliler. Sonra da iki temel sınavı geçmeliler. Şu anda MCDBA olanlar, tek sınavla Upgrade yapabilirler. Ama yine de önce MCTS: SQL Server 2005 sınavını geçmeliler.

EXAMS:
70-431: TS: Microsoft SQL Server 2005 - Implementation and Maintenance
70-443: PRO: Designing a Database Server Infrastructure by Using Microsoft SQL Server 2005 70-444: PRO: Optimizing and Maintaining a Database Administration Solution by Using Microsoft SQL Server 2005

MOCs:
70-431: 2779, 2780
70-443: 2786, 2787, 2788
70-444: 2787, 2789, 2790

UPGRADE EXAM:
70-447: UPGRADE: MCDBA Skills to MCITP Database Administrator by Using Microsoft SQL Server 2005

UPGRADE MOCs:
70-447: 2786, 2787, 2788, 2789, 2790


IT Professional: Business Intelligence Developer
MCITP Business Intelligence Developer adayları, önce MCTS: SQL Server 2005 Business Intelligence sınavını geçmeliler. Sonra da bir temel sınavı geçmeliler.

EXAMS:
70-445: TS: Microsoft SQL Server 2005 Business Intelligence - Implementation and Maintenance
70-446: PRO: Designing a Business Intelligence Solution by Using Microsoft SQL Server 2005

MOCs:
70-445: 2794, 2795, 2796, 2797
70-446: Henüz resmi bir Microsoft Learning ürünü yok.


IT Professional: Enterprise Support Technician
Microsoft' un verdiği adres şu anda çalışmıyor, sonra tekrar aşağıdaki adresten denenebilir. http://www.microsoft.com/learning/mcp/mcts/enterprisesupport/


MICRISOFT CERTIFIED PROFESSIONAL DEVELOPER (MCPD)
MCPD kendi içerisinde üç kola ayrılıyor. Bunlar: Web Developer, Windows Developer ve Enterprise Applications Developer' dır. Ayrıntılar aşağıdadır.

MCPD: Web Developer
MCPD Web Developer adayları, önce MCTS: .NET Framework 2.0 Web Applications (70-528, 70-536) sınavlarını geçmeliler. Sonra da bir ek sınavı geçmeliler.

Şu anda MCAD.Net unvanına sahip olanlar, 70-551 sınıvını geçerek, MCTS gerekliliklerini yerine getirmiş olurlar. Eğer 70-552 sınavını başarıyla geçerlerse ve 70-528 ve 70-547 sınavlarını da başarıyla geçerlerse, MCPD Web Developer unvanını kazanabilirler.

Şu anda MCSD.Net unvanına sahip olup 70-553 sınavını geçenler ve buna ek olarak da 70-547 sınavını geçenler, MCPD: Web Developer sertifikasını kazanırlar.

EXAMS:
70-528: TS: Microsoft .NET Framework 2.0 - Web-Based Client Development
70-536: TS: Microsoft .NET Framework 2.0 - Application Development Foundation
70-547: PRO: Designing and Developing Web Applications by Using the Microsoft .NET Framework

MOCs:
70-547: Henüz resmi bir Microsoft Learning ürünü yok.
70-536: Henüz resmi bir Microsoft Learning ürünü yok.
70-528: 2543, 2544, 2541, 2542

UPGRADE EXAM:
70-551: UPGRADE: MCAD skills to MCPD: Web Developer by Using the Microsoft .NET Framework
70-552: UPGRADE: MCAD Skills to MCPD: Windows Developer by Using the Microsoft .NET Framework
70-553: UPGRADE: MCSD Microsoft .NET Skills to MCPD Enterprise Application Developer by Using the Microsoft .NET Framework: Part 1

UPGRADE MOCs:
70-551: 2543, 2544, 2541, 2542
70-552: 2546, 2547, 2541, 2542
70-553: 2451, 2542, 2543, 2544, 2546, 2547


MCPD: Windows Developer
MCPD Windows Developer adayları, önce MCTS: .NET Framework 2.0 Windows Applications (70-526, 70-536) sınavlarını geçmeliler. Sonra da bir ek sınavı geçmeliler.

Şu anda MCAD.Net unvanına sahip olanlar, 70-552 sınıvını geçerek, hem MCPD: Windows Developer sertifikasını hem de MCTS sertifikasını kazanmış olurlar.

Eğer 70-551 sınavını geçtiyseniz, 70-526 ve 70-548 sınavlarını da geçerek, MCPD: Windows Developer sertifikasını kazanabilirsiniz.

Şu anda MCSD.Net unvanına sahip olup 70-553 sınavını geçenler ve buna ek olarak da 70-548 sınavını geçenler, MCPD: Windows Developer sertifikasını kazanırlar.

EXAMS:
70–548: PRO: Designing and Developing Windows Applications by Using the Microsoft .NET Framework
70-536: TS: Microsoft .NET Framework 2.0 - Application Development Foundation
70-526: TS: Microsoft .NET Framework 2.0 - Windows-Based Client Development

MOCs:
70-547: Henüz resmi bir Microsoft Learning ürünü yok.
70-536: Henüz resmi bir Microsoft Learning ürünü yok.
70-526: 2546, 2547, 2541, 2542

UPGRADE EXAM:
70-551: UPGRADE: MCAD skills to MCPD: Web Developer by Using the Microsoft .NET Framework
70-552: UPGRADE: MCAD Skills to MCPD: Windows Developer by Using the Microsoft .NET Framework
70-553: UPGRADE: MCSD Microsoft .NET Skills to MCPD Enterprise Application Developer by Using the Microsoft .NET Framework: Part 1

UPGRADE MOCs:
70-551: 2543, 2544, 2541, 2542
70-552: 2546, 2547, 2541, 2542 70-553: 2451, 2542, 2543, 2544, 2546, 2547


MCPD: Enterprise Applications Developer
MCPD Enterprise applications Developer adayları, önce MCTS: .NET Framework 2.0 Web Applications (70-528, 70-536), MCTS: .NET Framework 2.0 Windows Applications (70-526, 70-536), MCTS: .NET Framework 2.0 Distributed Applications (70-529, 70-536) sertifikalarını almalılar. Sonra da bir ek sınavı geçmeliler.

Şu anda MCSD.Net unvanına sahip olanlar, 2 Upgrade sınavıyla MCPD Enterprise applications Developer unvanını kazanabilirler. MCSD.Net unvanına sahip olanlar, bu iki Upgrade sınavını kazanarak yukarıda istenen MCTS unvanlarını da kazanmış olur.

Şu anda MCAD.Net unvanına sahip olanlar, doğrudan MCPD Enterprise applications Developer' a geçiş yapamazlar.

Eğer 70-551 sınavını geçmişseniz, 70-526, 70-529, ve 70-549 sınavlarını da geçerek, MCPD Enterprise applications Developer unvanını kazanabilirsiniz.

Eğer 70-552 sınavını geçmişseniz, 70-528, 70-529 ve 70-549 sınavlarını da geçerek, MCPD Enterprise applications Developer unvanını kazanabilirsiniz.

Eğer 70-551 ve 70-552 sınavlarını geçmişseniz, 70-529 ve 70-549 sınavlarını kazanarak, MCPD Enterprise applications Developer unvanını kazanabilirsiniz.

EXAMS:
70-526: TS: Microsoft .NET Framework 2.0 - Windows-Based Client Development
70-528: TS: Microsoft .NET Framework 2.0 - Web-Based Client Development
70-529: TS: Microsoft .NET Framework 2.0 - Distributed Application Development
70-536: TS: Microsoft .NET Framework 2.0 - Application Development Foundation
70-549: PRO: Designing and Developing Enterprise Applications by Using the Microsoft .NET Framework

MOCs:
70-549: Henüz resmi bir Microsoft Learning ürünü yok.
70-536: Henüz resmi bir Microsoft Learning ürünü yok.
70-526: 2546, 2547, 2541, 2542 70-528: 2543, 2544, 2541, 2542 70-529: 2548, 2549

UPGRADE EXAM:
70-551: UPGRADE: MCAD skills to MCPD: Web Developer by Using the Microsoft .NET Framework
70-552: UPGRADE: MCAD Skills to MCPD: Windows Developer by Using the Microsoft .NET Framework
70-553: UPGRADE: MCSD Microsoft .NET Skills to MCPD: Enterprise Application Developer by Using the Microsoft .NET Framework: Part 1
70-554: UPGRADE: MCSD Microsoft .NET Skills to MCPD: Enterprise Application Developer by Using the Microsoft .NET Framework: Part 2

UPGRADE MOCs:
70-551: 2543, 2544, 2541, 2542
70-552: 2546, 2547, 2541, 2542
70-553: 2451, 2542, 2543, 2544, 2546, 2547 70-554: 2548, 2549



TECHNOLOGY SERIES: MICRISOFT CERTIFIED TECHNOLOGY SPECIALIST (MCTS)

MCTS kendi içerisinde on yedi kola ayrılıyor. Kollar aşağıdaki gibidir:


Technology Specialist: .NET Framework 2.0 Web Applications
EXAMS:
70-528: TS: Microsoft .NET Framework 2.0 - Web-Based Client Development
70-536: TS: Microsoft .NET Framework 2.0 - Application Development Foundation

MOCs:
70-528: 2543, 2544, 2541, 2542
70-536: Henüz resmi bir Microsoft Learning ürünü yok.

Technology Specialist: .NET Framework 2.0 Windows Applications
EXAMS:
70-526: TS: Microsoft .NET Framework 2.0 - Windows-Based Client Development
70-536: TS: Microsoft .NET Framework 2.0 - Application Development Foundation

MOCs:
70-526: 2546, 2547, 2541, 2542
70-536: Henüz resmi bir Microsoft Learning ürünü yok.

Technology Specialist: .NET Framework 2.0 Distributed Applications
EXAMS:
70-529: TS: Microsoft .NET Framework 2.0 - Distributed Application Development
70-536: TS: Microsoft .NET Framework 2.0 - Application Development Foundation

MOCs:
70-529: 2548, 2549
70-536: Henüz resmi bir Microsoft Learning ürünü yok.

Technology Specialist: SQL Server 2005
EXAMS:
70-431: TS: Microsoft SQL Server 2005 - Implementation and Maintenance

MOCs:
70-431: 2779, 2780

Technology Specialist: SQL Server 2005 Business Intelligence
EXAMS:
70-445: Microsoft SQL Server 2005 Business Intelligence - Implementation and Maintenance

MOCs: 70-445: Henüz resmi bir Microsoft Learning ürünü yok.

Technology Specialist: BizTalk Server 2006
EXAMS:
70-235: TS: Developing Business Process and Integration Solutions Using BizTalk Server 2006

MOCs:
70-235: 2933, 2934.

Technology Specialist: Microsoft Office Live Communications Server 2005
EXAMS:
70-262: TS: Microsoft Office Live Communications Server 2005 - Implementing, Managing, and Troubleshooting

MOCs:
70-262: Henüz resmi bir Microsoft Learning ürünü yok.

Technology Specialist: Microsoft Exchange Server 2007, Configuration
EXAMS:
70-236: TS: Microsoft Exchange Server 2007, Configuring

MOCs:
70-236: 5047, 5051

Technology Specialist: Microsoft Office SharePoint Server 2007, Configuration
EXAMS: 70-630: TS: Microsoft Office SharePoint Server 2007, Configuring

MOCs: 70-630: 5061

Technology Specialist: Microsoft Office SharePoint Server 2007, Application Development
EXAMS:
70-542: TS: Microsoft Office SharePoint Server 2007, Application Development

MOCs:
70-542: Henüz resmi bir Microsoft Learning ürünü yok.

Technology Specialist: Windows Mobile 5.0, Applications
EXAMS:
70-540: TS: Microsoft Windows Mobile 5.0 - Application Development

MOCs:
70-540: Henüz resmi bir Microsoft Learning ürünü yok.

Technology Specialist: Windows Mobile 5.0, Implementing and Managing
EXAMS:
70-500: TS: Microsoft Windows Mobile 5.0, Implementing and Managing

MOCs:
70-500: Henüz resmi bir Microsoft Learning ürünü yok.

Technology Specialist: Windows Server 2003 Hosted Environments, Configuration, and Management
EXAMS:
70-501: TS: Microsoft Windows Server 2003 Hosted Environments, Configuring, and Managing

MOCs:
70-501: Henüz resmi bir Microsoft Learning ürünü yok.

Technology Specialist: Windows SharePoint Services 3.0, Application Development
EXAMS:
70-541: TS: Microsoft Windows SharePoint Services 3.0, Application Development

MOCs:
70-541: Henüz resmi bir Microsoft Learning ürünü yok.

Technology Specialist: Windows SharePoint Services 3.0, Configuration
EXAMS:
70-631: TS: Configuring Microsoft Windows SharePoint Services 3.0

MOCs:
70-631: Henüz resmi bir Microsoft Learning ürünü yok.

Technology Specialist: Windows Vista and 2007 Microsoft Office System Desktops, Deploying and Maintaining
EXAMS:
70-624: TS: Deploying and Maintaining Windows Vista Client and 2007 Microsoft Office System Desktops

MOCs:
70-624: 5105, 5058

Technology Specialist: Windows Vista, Configuration
EXAMS:
70-620: TS: Microsoft Windows Vista Client, Configuring

MOCs:
70-620: 5115, 5116, 5117


--
Ekrem Önsoy