Kimsin sen Kim?
Adının içinde yanlışlıkla mertlik geçen kan heykeli adam …
Kimsin sen…
Seni çekiç suyuyla mı beslediler…
Asitli diken kundağında mı büyüdün.
Evinizin penceresi hep merhametsizliğe mi baktı küçükken.
Annen saçlarını çamurla mı yıkadı…
Sınıfta en arka sırada oturup, tahtaya kalaşnikofla mı kalktın..
En sevdiğin hayvan yılan mıydı senin…
Rezil mi olurdun arkadaşlarına bir kuşu öldürmeyince…
Defterin köpeklerle mi kaplıydı.
Seni Rahibe terasalar mı kutsadı…

Kimsin sen Kim?
Saçlarının arasında mıydı bitlenmiş bombalar…
Vicdansızlık ormanının tanrısız kralı mıydın.
Isırgan otlarını mı dişledi ateş yutan ağzın…
İnsan olmayacaksan niye giydin bu şehrin ölümünü…
Düğününde sırtlanlar mı çekti fotograflarını
Eve giderken ekmek yerine kurt mu kaptın mermi fırınlarından…

Bizi soracak olursanız biz çok öfkeliyiz…
Olmertin insafına kalmadı Gazze…
Olmertin insafına tenezzül etmeyen Gazze’li çocukların ruhuna düğüm düğüm cennet sessizliği diliyoruz…

Bırakalım Olmertin ikinci adını Allah koysun…
Allah koysun…

Bizi soracak olursanız biz Olmertin insan olmadığını düşünmeye devam ediyoruz..

Esra Elönü

Günümüzde özellikle veritabanına dayalı uygulamalar, katmanlı mimari (multi-tier architecture) üzerine kurulur. Bu konsept dahilinde uygulamalar, veri (data), iş (business logic) ve sunum (presentation) olmak üç temel katmandan oluşur. Tasarım sürecinde ilk sırada bulunan veri katmanı oluşturulurken çeşitli veri modelleri kullanılır. “Verileri mantıksal düzeyde düzenlemek için kullanılan kavramlar, yapılar ve işlemler bütününe veri modeli denir.”
70′lı yıllardan bu yana Veritabanı Yönetim Sistemleri’nin (Database Management System – DBMS [VTYS]) değişmesiyle birlikte çeşitli veri modelleri geliştirildi:

• Sıradüzensel veri modeli (Hierarchical data model)
• Ağ veri modeli (Network data model)
• İlişkisel veri modeli (Relational data model)
• Nesneye yönelik veri modeli (Object oriented data model)

Her VTYS’nin kendine özgü veri modeli bulunur. Veri modeli kullanılarak veritabanının kavramsal ve dış şemaları oluşturulur. Burada bu modellerle ilgili kavramları tanımlayacağız ve VTYS’den bağımsız tasarım yapmamızı sağlayan ER modelini ayrıntılı ele elacağız.

Entity Relationship (ER) Modeling

Günümüzde bir veritabanı uygulamasının başarılı olmasını sağlayacak ilk parametre, iyi bir veritabanı tasarımına sahip olmasıdır. Bir uygulama geliştirileceği zaman öncelikle bu uygulamanın ne tür bir uygulama olduğu ve ne tür verileri içereceği belirlenir. Veritabanı tasarımı, bu soruların yanıtları doğrultusunda şekillenir. İlişkisel veritabanı sistemlerinde veritabanı tasarımının ilk adımı veri modellemedir.
Veri modelleme, veritabanı verilerinin ve bunların arasındaki ilişkinin organizasyon içindeki herkesin rahatlıkla anlayabileceği metin ve şekillerle ifade edilmesidir. Bilindiği gibi organizasyon içindeki kullanıcı, tasarımcı ve programcı gibi teknik veya teknik olmayan kişilerin veriye bakış açıları ve veriyi tanımlamaları farklılık arzeder. Hazırlanacak olan veritabanı tasarımında bu kişilerin hepsinin rolü olduğu için bu kişiler arasında ortak bir dil oluşturmak gerekir. Bu dilin temeli hiç şüphesiz gerçek dünya varlıklarıdır. Veritabanını kullanacak olan kullanıcı, tasarlayacak olan tasarımcı ve kodlayacak programcı ihtiyacını ancak gerçek varlıklar (nesneler) üzerinden daha kolay anlatabilir. Fakat gerçek dünyada varlıklar daha karmaşık özellik ve yeteneklere sahip olduğu için bu varlıklar üzerinden ifade edilmiş yapıyı, veri modellemesi aracılığıyla daha anlaşılır hale getirmek gerekir. Buradaki amaç, organizasyon içindeki herkesin gördüğü zaman kolaylıkla anlayabileceği ve veritabanı yapısını gözünde canlandırabileceği bir veri modeli çıkarmak ve bu model üzerinden organizasyon ihtiyaçlarını doğru şekilde karşılayacak fiziksel bir veritabanı tasarımına zemin hazırlamaktır.
Veritabanı modellemenin üç türü vardır. Bu türler aynı zamanda veritabanı model veya tasarımın aşamalarını da bildirir.

Kavramsal tasarım (Conceptual design): Veri tabanının hangi verileri içereceğinin ve bu veriler arasındaki ilişkilerin belirlendiği aşamadır. Bu aşamanın en önemli özelliği veritabanı nesneleri herhangi bir VTYS şemasına bağlı kalınmadan modellenir. Bu aşamada organizasyon içindeki herkes aktif olabilir. Kavramsal modelleme, mantıksal modellemenin çözümlenmesini ve tasarımını kolaylaştırmak için atılmış bir adımdır.

Mantıksal tasarım (Logical design): VTYS’nin tanımlandığı aşamadır. Kavramsal tasarımda modellenen yapı, karar verilmiş olan VTYS’ye uygun şemaya dönüştürülür. Veritabanında kullanılacak veri türleri, tablo üzerindeki anahlarlar, tablo satırlarının birbirleriyle ilişkileri bu aşamada belirlenir. Bu aşamada daha çok tasarımcı ve programcı rol oynar.

Fiziksel tasarım (Physical design): Verilerin hangi disk veya başka fiziksel depolama sistemlerinde nasıl tutulacağı, ne tür işlemci yapılarının kullanılacağı, aygıtların verilere hangi yol ve kurallar dahilinde ulaşacağı ve bunların doğrultusunda VTYS yazılımın hangi işletim sistemi üzerinde koşacağı belirlenir. Daha çok veritabanı programcısının aktif rol oynadığı bu aşamada oraya çıkan modelin daha önce organizasyon elemanlarıyla birlikte karar verilmiş olan kavramsal ve mantıksal modelle olan uyumluluğu test edilir. Kısaca, kavramsal ve mantıksal tasarım aşamasında, veritabanı şemasına karar verildiğini, fiziksel tasarım aşamasında da veritabanının fiziksel yapısına karar verildiğini söyleyebiliriz.

Bu aşamalardan sonraki süreç, uygulama programının yazılarak kullanıcıların belirlenmiş yetkiler ölçüsünde veriye ulaşmasıdır.

Kendisi soyut bir yapı olan veri modeli, ANSI-SPARC mimarisine göre kavramsal (conceptual), dış (external) ve iç (internal) olmak üzere üç seviyeli soyutlama derecesine sahiptir. Bu seviyeler, veri ortamının organizasyon içindeki kişiler tarafından görünen görünümü temsil eder. Dış seviye, veritabanının kullanıcıya olan görüntüsü ifade eder. Her kullanıcının özgül bakışı ve bilgisi doğrultusunda birçok dış görünüm oluşturulabilir. Bu görünümler kullanıcı programları veya doğrudan SQL cümleleriyle oluşturulur. Daha çok veritabanı sahiplerinin hazırladığı ve veritabanının üst düzeyde soyutlanmış hali olan kavramsal seviye, veritabanının kuş bakışı görüntüsünü temsil eder. Bu seviyede veritabanında hangi verilerin saklandığı ve bu veriler arasındaki ilişki görünür. Kavramsal modelde veritabanı yazılım ve donanımla ilgili bilgi bulunmaz yani VTYS’den bağımsız bir görüntü sunar. İç seviye ise VTYS’ye bağımlı olup veritabanının VTYS’ye göre hazırlanmış şemasını belirtir. Veritabanının en alt düzeyde soyutlanmış olan bu seviyede verilerin veritabanın nasıl saklandığı ifade edilir. Aynı zamanda fiziksel seviye olarak ta bilinir.

Veritabanı tasarımı konusunda bu kadar giriş yapmamız yeterli olacaktır. Asıl konumuz; kavramsal tasarım aşamasında en çok kullanılan yöntem olan Varlık-İlişki (Entity-Relationship, ER) modelidir. ER modeli, kavramsal veri modelini herhangi bir VTYS şemasına bağlı kalmadan ana hatlarıyla ER diyagramı üzerinde şematik olarak gösterme tekniğidir. Bu teknik, organizasyon içerisindeki teknik veya teknik olmayan kişiler arasında verinin farklı görünümlerini ortak bir kalıba dönüştürür ve veritabanı uygulamalarının daha kolay geliştirilmesini sağlar. ER çizenekleri için, genellikle UML gösterimleri kullanılır.

ER yönteminin çıkış amacı tasarımcıların oluşturduğu nesne modelini, nesne kavramını anlamayan ilişkisel veritabanı yönetim sistemlerine kolaylıkla uyarlayabilmektir.
ER modeli, teknik olarak varlıklar (entities) ve ilişkiler (relationships) koleksiyonundan oluşur. ER modelinin temelinde bu bölümün de anahtar kelimesi olan varlık bileşeni bulunur. Varlık ifadesi, Yazılım Mühendisliği literatüründe gerçek dünyadaki anlamıyla kullanılır. Yani soyut veya somut olarak var olan ve benzerlerinden ayırt edilebilen her şeye varlık denilir. Örneğin gerçek dünyada insanoğlu, araba, devlet nesneleri varlık olarak nitelendirildiği gibi nesne tabanlı programlamada sınıflar, veritabanı yönetim sisteminde de tablolar varlık olarak nitelendirilir. Her varlık, kendisini diğer varlıklardan ayırteden öznitelik (attribute) olarak bilinen karakteristiklere sahiptir. Veritabanındaki tablolar, satır ve sütunlardan oluşur. Tablo satırlarının her biri bir tek varlığı temsil eder. Varlığın her bir niteliği bir sütunda temsil edilir. Örneğin bir elektronik ticaret projesinde “Musteri” bir varlık, müşterinin “AdSoyad” bilgisi, bu varlığa ait bir nitelik olarak tanımlanabilir. “AdSoyad” bilgisinin “Murat Şensoy” olarak belirlenmesi bu niteliğin değeridir (data value). Özniteliğin alabileceği veya aldığı değerler etki alanı (domain) olarak tanımlanır.

VTYS’ler varlık kümesi ve onların arasındaki etkileşimden oluşur. Varlıklar arasındaki etkileşim, varlık ilişkisi olarak tanımlanır. Varlıklar arasında üç tür ilişki kurulur:

Birden çoğa ilişki (one-to-many relationship): Bir tablonun bir kaydına karşılık ikinci tabloda birden fazla kaydın olmasıdır. “Siparis” ve “Musteri” tabloları arasındaki ilişkidir. Bir sipariş, sadece bir müşteriye ait olabilir fakat bir müşterinin birden fazla siparişi olabilir. Bu ilişki 1:M ile temsil edilir.

Çoktan çoğa ilişki (many-to-many relationship): Bir tablonun birden fazla kaydı, diğer tablonun birden fazla kaydıyla ilişkilidir. M:N ile temsil edilen bu ilişki genellikle üçüncü bir tablo üzerinde oluşturulur. “Ogrenci” ve “Kurs” tablolarını örnek olarak verebiliriz. Bir öğrenci birden fazla kursa katılabilir aynı şekilde bir kursa birden fazla öğrenci katılabilir. Bu ilişki “OgrenciKurs” tablosunda tutulur.

Birden bire ilişki (one-to-one relationship): Bir müşterinin bir şifresi var ve her bir şifre bir müşteriye aittir. Bu durum, bir tablo ilişkisinden ziyade ikinci tablonun birinci tablonun uzantısı olmasıdır.

Tasarım aşamasında varlık ve onlara ait öznitelikler belirlendikten sonra varlıklar arasındaki ilişkiler belirlenir ve öğe ilişki çizeneği çıkarılır (entity relationship diagramming - öğe ilişki çizeneği). Bu çizelgede veritabanı varlıkları, varlıkların türleri, varlıklar arası ilişkiler ve ilişki kuralları gösterilir. ER diyagramı hazırlayabilmek için Microsoft Visio, Sybase Power Designer gibi araçlar kullanılır. Aşağıdaki çizelgede üç tablonun yapısı ve ilişkileri gösterilmiştir.

Sonuç olarak ER tekniğinin, veritabanı oluşturulmadan önce veritabanı tasarımını kolaylaştırmak amacıyla veritabanının hangi varlıklardan oluştuğunu ve bu varlıkların nasıl ilişkilendirildiğini çeşitli şemalarla belirtme yöntemi olduğunu söyleyebiliriz. ER modelinin en önemli özelliği bu mantıksal tasarımı VTYS şemasına bağlı kalınmadan yapmasıdır.

VTYS tarafında, tasarımcılar tarafından oluşturulmuş olan nesne modelini VTYS’de saklamak için aracı olarak ER modelini kullanıyoruz. Bu ek işlem, şu anki VTYS’lerin nesne yönelimli (Object Oriented) olmamasından kaynaklanmaktadır. Aynı sorun kullanıcılarla veritabanı arasında iletişim sağlayacak veritabanı uygulamaları yazılırken de yaşanır. Özellikle nesne yönelimli bir programlama dili kullanıldığı zaman class, inheritance, property, method gibi OOP varlıkları VTYS tarafından desteklenmediği için iş katmanında OOP ve ilişkisel veritabanı özellikleri iç içe kullanılır. Uygulamaların iş katmanındaki bu iş yükünü azaltmak amacıyla O/R Mapping isimli nesne-ilişki eşleştirme yöntemi kullanılır.

Nesne-İlişkili Haritalama (Object-Relational Mapping - O/R Mapping)

Günümüzde en çok kullanılan veri modeli, ilişkisel veri modelidir. Aynı şekilde uygulamaların iş katmanı yazılırken en çok nesne odaklı programlama modeli tercih edilir. Uzun yıllardır kullanılan bu iki yöntem, uygulama geliştiriciler için ciddi kolaylıklar sağlamıştır. Bununla birlikte bu iki yöntemin kullanıldığı geniş çaplı kurumsal uygulamaların en önemli sorunu, bu uygulamaların tasarım ve geliştirme süreçlerinin yönetimi zor ve zaman alıcı bir hal almasıdır. Özellikle iş katmanında veritabanı sorgulama işlemlerinde yoğun bir şekilde SQL dilinin kullanılıyor olması ve uygulama kodlarının veritabanı şemasına bağlı kalması, uygulama geliştiricilerinin veritabanı tarafında çok zamanını almaktadır. Veritabanında yeni bir kolon ekleme, kolon değiştirme gibi tablonun şemasının değişmesi durumunda uygulamanın iş katmanındaki veri erişim kodlarının yeniden gözden geçirilmesi gerekir. Bir veritabanı uygulamasında, kodun üçte birinin veri erişimiyle ilgili olduğunu göz önünde bulundurduğumuzda veri erişim katmanında her modül için sorgulama, ekleme, güncelleme, silme gibi işlemleri yeniden kodlamak birçok yazılım mühendisi için sıkıcı ve zaman alıcı olabilmektedir.

Ayrıca iş katmanında nesne odaklı programlama tercih edildiği halde veriye nesnesel olmayan yöntemlerle erişilir. Yani veritabanında veri tutmaya yarayan tabloları, uygulama geliştirme tarafında gerçek varlıkları temsil etmek için kullandığımız nesnelerle ifade edememekteyiz. Aynı şekilde uygulama tarafında oluşturulmuş bir nesneyi de veritabanı tarafında uygun bir şekilde temsil edememekteyiz. Bu işlemleri yapabilmek için diğer veri modeli olan ve gerçek dünyayı daha iyi modelleyebilecek “nesneye yönelik veri modeli”nin gelişmiş olması lazım. Şu ana kadar bu modeli desteklemek amacıyla Nesne Yönelimli VTYS (Object Oriented DBMS - OODBMS) üzerinde çalışmalar yapılmışsa da ciddi sonuçlar elde edilemedi. Bu yüzden sözkonusu sorunları aşmak için şimdilik yapabileceğimiz ancak yöntemin iyileştirilmesi olacaktır. Bu amaçla ilişkisel veritabanı ile nesneler arasında bağlantı kurma ve eşleştirme yapma yöntemi olarak bilinen Nesne/İlişkisel Eşleme (O/R Mapping-ORM) modeli kullanılır. Bu model, uygulamaların iş katmanında kod yazımını kısaltarak veritabanı işlemlerinin daha kısa sürede geliştirilmesini, veritabanı işlemlerinde OOP yeteneklerinin kullanılmasını sağlar ve sonuçta yazılım bakımını kolaylaştırır. Bu cümleleri biraz daha detaylandıralım.

ORM yöntemi, en çok tercih ettiğimiz nesne odaklı programlama modeli ile ilişkisel veritabanı modeli arasında ilişki kurup ilişkisel veritabanındaki öğelerin, nesne odaklı dildeki nesnelere nasıl karşılık geleceğini yönetir. Tabloları sınıflara (class), satırları nesnelere (instance), kolonları bu nesnelerin özniteliklerine (attribute) bağlar, oluşturulan sınıf yordamları, tablo seviyesinde, nesne yordamları da satır seviyesinde işlemler yapmak için kullanılır. Böylece verileri sorgularken, güncellerken, eklerken, silerken nesnesel ifadeler kullanmamıza olanak tanır. VTYS tarafındaki öğelere karşılık gelen uygulama nesnelerine alan nesnesi (domain object) denilir. Bu kalıcı sınıflar, uygulama tarafında, veri erişim katmanı (persistence layer) olarak isimlendirilen alanda yaşar.

Bir anlamda uygulamayı, veritabanından soyutlamış olan ORM yaklaşımı, veri işleme katmanını daha hızlı oluşturmamızı, veritabanı işlemlerinde daha az SQL kodu yazmamızı ama bununla birlikte verileri en az SQL kadar güçlü bir yöntemle sorgulamamızı ve performans açısından otomatik ön bellekleme yapılmasını sağlar. Ayrıca veritabanı şemasında yapılan bir değişiklikte (veri erişim katmanındaki sınıflar doğrudan veritabanına bağlı olmadığı için) veri erişim kodlarını gözden geçirmek yerine daha önce oluşturulmuş olan xml tabanlı nesne-tablo eşleştirme dosyasının düzenlenmesi yeterli olacaktır.

O/R Mapping yönteminde kullanılmak üzere birçok araç geliştirilmiştir bunların en popüleri ilk olarak Java platformu için çıkarılmış ama daha sonra .NET sürümü de geliştirilmiş olan açık kaynak NHibernate ürünüdür (www.hibernate.org). Bunun dışında başta LLBLGen ürünü olmak üzere .NET platformunda kullanılacak birçok O/R Mapping aracı bulunmaktadır. Günümüzde birçok yazılım evi, uygulamalara ait ORM kodu üreten framework’ler geliştirmiştir. Bu araçlar kullanılarak sorgulama cümleleri elle yazılmak yerine otomatik olarak üretilir ve veri erişim katmanı kısa sürede oluşturulmuş olur. Dolayısıyla yazılım mühendisinin veri erişim ve sorgulama için ayıracağı kodlama zamanını iş katmanındaki algoritmaya ayırması, o alana odaklanması, veri erişim katmanını düşünmemesi sağlanmış olur.

Bir diğer konu da ugulamalar içerisinde veritabanı işlemleriyle ilgili kodların çalıştırılma yönteminin ne olacağıdır. Bu yöntemin ne olacağı yazılım uzmanları arasında birçok tartışma konusu olmuştur. .NET Framework’ün ilk sürümlerinde iş katmanında dinamik SQL yerine SQL yordamlarının (stored procedure) kullanılması tavsiye edilmiştir. Bu yöntemin daha fazla güvenlik ve hız kazandırdığı dile getirildi. Ancak günümüzde bu yöntemin güvenli olduğu kabul edilse de performans ve kullanım konusunda fikir birliği sağlanamamıştır. Stored procedure yerine dinamik SQL kullanılmasını tavsiye edenlerin dayanağı; stored procedure’lerin versiyonlama, taşınma ve kurulumun kolay olmaması ve büyük ölçekli kurumsal uygulamalarda iş kurallarının genişlemesiyle birlikte yönetimi ve bakımı zorlaşacak çok sayıda procedure yazmak zorunda kalınmasıdır. Aslında asıl sorun iş katmanı ve veri katmanı sınırlarının iç içe geçmesi ve ilk paragraflarda bahsettiğimiz gibi uygulama geliştiricinin veri katmanında çok zaman harcamasıdır. Veritabanının doğası gereği görevi veri arama, tarama olduğu için kod güvenliği, matematiksel işlemler, koşula dayalı işlemler gibi ek faaliyetlerle uğraşmaması gerekir. Bununla birlikte farklı türden veritabanı üzerinde çalışma ihtimali olan paket haline getirilecek bir ürün için iş kurallarını stored procedure üzerinde oluşturmak uyarlama sürecini zorlaştıracak, zaman kaybına neden olacaktır. Stored procedure’lere alternatif olarak dinamik SQL yapısının kullanılması da uygulamayı, veritabanı şemasına bağımlı hale getirecektir. Bu yüzden O/R Mapping yöntemini kullanarak iş katmanını SQL kodlarından temizleyip bu katmanın sadece iş mantığı algoritmasını içermesini ve uygulama geliştiricinin de sadece o katmana odaklanmasını, T-SQL ile boğuşmak yerine sadece OOP destekli dil ile işlemlerini yürütmesi sağlanmalıdır. ORM yöntemini tercih ettiğimizde aşağıdaki gibi bir T-SQL cümlesi veya stored procedure yerine

UPDATE Musteri SET AdSoyad='Murat Şensoy'
WHERE MusteriId = 10

aşağıdaki gibi bir kod yazmış olacağız.

Musteri.AdSoyad = "Murat Şensoy"
oRm.Save(Musteri)

Görüldüğü gibi CRUD (create, read, update, delete) işlemlerini OOP kurallarına göre yazmış oluyoruz. Böylece iş katmanını kodlayan yazılımcının yöntem alışkanlığı bozulmamış olmaktadır.

O/R Mapping modelinin geliştirme sürecinde kolaylık sağlamasına karşılık çalışma zamanında klasik yöntemle kıyaslandığında performans konusunda yeterince iyi olduğunu söyleyemeyiz. Bunun nedenlerini şu şekilde sıralayabiliriz:

• ORM, uygulama mimarisine veri erişim isminde yeni bir katman ekler.
• Veri katmanı, veritabanına doğrudan erişemez.
• SQL dilinin kompleks sorgu oluşturma ve çözmedeki gücünden yararlanılmaz.
• ORM, uygulamanın veritabanı bağımsız olmasını sağladığı için o anda kullanılan VTYS’nin yeteneklerinden yararlanılamaz.

Sonuç olarak O/R Mapping yönteminin zorunlu bir yöntem olmadığını ancak kompleks iş katmanına sahip büyük ölçekli kurumsal uygulamalarda veri erişim katmanını daha az kodla ve kısa sürede üretmeye yardımcı olduğu ve sonuçta yazılım mühendisinin üzerindeki yükü hafiflettiği için tercih nedeni olabileceğini söyleyebiliriz. Bu yöntemi kullanıp kullanmamak birazcık ta “uygulama içerisinde klasik veri sorgulama ifadelerini (select, insert, update, delete) SQL ile manual mi oluşturacağız yoksa bunlar otomatik mi oluşturulmalı?” sorusuna vereceğimiz yanıta bağlıdır.
Tanımını, avantaj ve dejavantajını verdiğimiz ORM yönteminin .NET cephesindeki durumunu inceleyelim.

ADO.NET Entity Framework

Microsoft, ADO.NET 2.0 ile birlikte sunduğu ObjectSpaces (OS.Net) ürünüyle O/R Mapping çözümüne ilk adımını atmış oldu. ADO.NET 3.5 ile birlikte ObjectSpaces ürününü yeniden düzenleyerek bu bölümde işleyeceğimiz ADO.NET Entity Framework isimli eklentiyi geliştirerek O/R Mapping alanındaki adımlarını daha da belirginleştirdi.

Entity Framework eklentisi, sadece bir O/R mapping aracı veya bir code generator olmanın ötesinde bunları da içinde barındıran ve uygulama içerisindeki varlıkları ve ilişkilerini sorgulamamızı sağlayan servisler bütünüdür. Entity Framework’ün servisleri aşağıdaki şekilde gösterilmiştir.

ADO.NET Entity Framework’ün bir parçası olarak Framework ortamında ER modelinin oluşturulması için Varlık Veri Modeli (Entity Data Model-EDM) isimli konsept sunulmaktadır. EDM’yi veritabanı şemasını kavramsal ve mantıksal boyutta gösteren ve ilgili ORM haritasını oluşturan bir araç olarak değerlendirebiliriz. EDM, varlıklarla ilgili şemayı XML belgelerinde (CSDL, SSDL, MSL) saklar. Bu üç dosya, Entity Framework’ün üç temel boyutu olan kavramsal (conceptual), mantıksal (logical) ve haritalama (mapping) modelleriyle ilgili bilgileri içerir.

CSDL (Conceptual Schema Definition Language): Varlıkların ve onlara ait ilişkilerin tanımlandığı dosya olup uygulamanın çekirdek veri modelini (core data model) teşkil eder. Uygulama katmanında varlıklar (nesneler), CSDL şeması referans alınarak oluşturulur. Bu şema, kavramsal şema formatına sahiptir.

SSDL (Store Schema Definition Language): Veri kaynağı olarak kullanılacak veritabanına ait üstveri (metadata) bilgisini içerir. Mantıksal model için oluşturulan bu dosya, varlıklarla veri kaynağı arasındaki iletişimi kurar.

MSL (Mapping Specification Language): CSDL dosyasındaki varlıkları SSDL dosyasında belirtilmiş tablolarla eşleştirir.

Entity Client, SQLClient, OracleClient gibi ADO.NET’in bir yönetilebilir veri sağlayıcısı (managed provider) olup EDM tarafından tanımlanmış olan veriye erişmeyi sağlar. Diğer sağlayıcılar gibi bunun da EntityCommand, EntityConnection ve EntityTransaction bileşenleri bulunur.

Object Services bileşeni, veri nesneleri üzerinde CRUD (Create, Read, Update, Delete) işlemleri için gerekli sorguları oluşturur. Bu sorgulama servisi, “Entity SQL” ve “LINQ to Entities” türü sorgulama destekler. Entity SQL (eSQL) ismindeki sorgulama dili, T-SQL’ dilinden türemiş olup EDM modelindeki varlıkları ve aralarındaki ilişkileri sorgulamak için kullanılır. LINQ to Entities bileşeni de daha sonra yazılarda anlatacağımız LINQ teknolojisinin varlıkları sorgulamak için sunduğu bir sağlayıcıdır.

Örnek verdiğimiz aşağıda tabloda bir tarihin, tarih formatı, hafta ve ay bilgisi, haftanın, ayın ve yılın kaçıncı günü olduğu, haftasonuna denk gelip gelmediği gibi bilgiler verilmektedir.

CREATE TABLE L_Tarih(
	Bugun int NOT NULL, --YYYYMMDD formatında tarih. Tablonun primary key'i.
	FormatliBugun char(10) NULL,--DD.MM.YYYY formatında tarih
	GunAd char(10) NULL,
	AyAd char(10) NULL,
	TarihAd varchar(50) NULL,--'10 Aralık 2007 Pazartesi' gibi
	BuYil char(4) NULL,--Sene bilgisi
	BuAy char(6) NULL,--Yıl ve ay bilgisi. YYYYMM
	BuHafta char(6) NULL,--Yıl ve hafta bilgisi. YYYYWW
	Dun char(10) NULL,
	GecenHaftaBugun char(10) NULL,
	GecenAyBugun char(10) NULL,
	GecenYil char(4) NULL,
	GecenYilBugun char(10) NULL,
	GecenYilBuHafta char(6) NULL,
	GecenYilBuAy char(6) NULL,
	HaftaIlkGun char(10) NULL,--Bugünün bulunduğu haftanın başı
	HaftaSonGun char(10) NULL,--Bugünün bulunduğu haftanın sonu
	AyIlkGun char(10) NULL,
	AySonGun char(10) NULL,
	HaftaGunNo int NULL,--Haftanın kaçıncı günü
	AyGunNo int NULL,--Ayın kaçıncı günü
	YilGunNo int,--Yılın kaçıncı günü
	AyGunSayi int NULL,
	YilIlkGun char(10) NULL,
	YilSonGun char(10) NULL,
	HaftaSonu bit NULL--Haftasonu olup olmadığını belirtir
)

Şeması bu şekilde olan tabloya aşağıdaki script’i çalıştırarak iki tarih aralığındaki tarih detaylarını yazdıralım.

DECLARE @IlkTarih DATETIME
DECLARE @SonTarih DATETIME

SET @IlkTarih = '01-01-2007'
SET @SonTarih = '31-12-2008'

DECLARE @Bugun INT, @FormatliBugun CHAR(10), @GunAd CHAR(10), @AyAd CHAR(10),
	@TarihAd VARCHAR(50), @BuYil CHAR(4), @BuAy CHAR(6), @BuHafta CHAR(6),
	@Dun CHAR(10), @GecenHaftaBugun CHAR(10), @GecenAyBugun CHAR(10),
	@GecenYil CHAR(4), @GecenYilBugun CHAR(10),@GecenYilBuHafta CHAR(6),
	@GecenYilBuAy CHAR(6),@HaftaGunNo INT, @AyGunNo INT,@YilGunNo INT,
	@HaftaIlkGun CHAR(10), @HaftaSonGun CHAR(10),@AyGunSayi INT,
	@AyIlkGun CHAR(10), @AySonGun CHAR(10), @YilIlkGun CHAR(10),
	@YilSonGun CHAR(10), @HaftaSonu BIT

WHILE @IlkTarih <= @SonTarih
BEGIN
	SET @Bugun=CONVERT(VARCHAR(8), @IlkTarih, 112)
	SET @FormatliBugun=CONVERT(VARCHAR(10), @IlkTarih, 104)
	SET @GunAd=DATENAME(dw, @IlkTarih)
	SET @AyAd=DATENAME(mm, @IlkTarih)
	SET @TarihAd=CAST(DATEPART(dd, @IlkTarih) AS CHAR(2)) +' '+ DATENAME(mm, @IlkTarih) + ' '
			+ CAST(DATEPART(yy, @IlkTarih) AS CHAR(4))+' '+ @GunAd
	SET @BuYil=DATENAME(yy, @IlkTarih)
	SET @BuAy=LEFT(@Bugun,6)
	SET @BuHafta=CAST(DATEPART(ww, @IlkTarih) as CHAR(2))
	--Tek hane ise başına "0" ekleyelim
	SET @BuHafta=@BuYil+REPLICATE('0', 2 - LEN(@BuHafta))+@BuHafta
	SET @Dun= CONVERT(VARCHAR(8),DATEADD(dd,-1, @IlkTarih),112)
	SET @GecenHaftaBugun=CONVERT(VARCHAR(8),DATEADD(dd,-7, @IlkTarih),112)
	SET @GecenAyBugun=CONVERT(VARCHAR(8),DATEADD(mm,-1, @IlkTarih),112)
	SET @GecenYil=CONVERT(VARCHAR(8),DATEADD(yy,-1, @IlkTarih),112)
	SET @GecenYilBugun=CONVERT(VARCHAR(8),DATEADD(dd,-365, @IlkTarih),112)
	SET @GecenYilBuHafta=CAST(DATEPART(ww, @GecenYilBugun) as CHAR(2))
	--Tek hane ise başına "0" ekleyelim
	SET @GecenYilBuHafta=@GecenYil+REPLICATE('0', 2 - LEN(@GecenYilBuHafta))+@GecenYilBuHafta
	SET @GecenYilBuAy=LEFT(@GecenYilBugun,6)
	--Tarihin bulunduğu haftanın ilk günü
	SET @HaftaIlkGun=CONVERT(VARCHAR(8),DATEADD(dd,-(DATEPART(dw, @IlkTarih) - 1),@IlkTarih),112)
	--Tarihin bulunduğu haftanın son günü
	SET @HaftaSonGun=CONVERT(VARCHAR(8),DATEADD(dd,-(DATEPART(dw, @IlkTarih) - 7),@IlkTarih),112)
	--Ayın ilk günü
	SET @AyIlkGun=@BuAy+'01'
	--Ayın son günü
	SET @AySonGun=CONVERT(VARCHAR(8),DATEADD(d, -DAY(DATEADD(m,1,@IlkTarih)),DATEADD(m,1,@IlkTarih)),112)
	SET @YilIlkGun=@BuYil+'0101'
	SET @YilSonGun=@BuYil+'0131'
	--Ayın kaç gün olduğunu hesaplayalım
	SET @AyGunSayi=DAY(DATEADD(d, -DAY(DATEADD(m,1,@IlkTarih)),DATEADD(m,1,@IlkTarih)))
	--Tarihin haftanın kaçıncı günü olduğunu hesaplayalım
	SET @HaftaGunNo=DATEPART(dw , @IlkTarih)
	--Tarihin ayın kaçıncı günü olduğunu hesaplayalım
	SET @AyGunNo=DATEPART(day , @IlkTarih)
	--Tarihin yılın kaçıncı günü olduğunu hesaplayalım
	SET @YilGunNo=DATEPART(dy , @IlkTarih)

	--Tarihin haftasonu olup olmadığını bulalım
	SET @HaftaSonu= CASE WHEN @HaftaGunNo IN (6,7) THEN 1 ELSE 0 END

	--Elde ettiğimiz bilgileri lookup tablosuna aktaralım
	INSERT L_Tarih (Bugun, FormatliBugun, GunAd, AyAd, TarihAd,
			BuYil,BuAy,BuHafta,Dun,GecenHaftaBugun,GecenAyBugun,
			GecenYil,GecenYilBugun,GecenYilBuHafta,GecenYilBuAy,
			HaftaIlkGun,HaftaSonGun,AyIlkGun,AySonGun,HaftaGunNo,
			AyGunNo,YilGunNo,AyGunSayi,YilIlkGun,YilSonGun,HaftaSonu)
	VALUES(@Bugun, @FormatliBugun, @GunAd, @AyAd, @TarihAd,
			@BuYil,@BuAy,@BuHafta,@Dun,@GecenHaftaBugun,@GecenAyBugun,
			@GecenYil,@GecenYilBugun,@GecenYilBuHafta,@GecenYilBuAy,
			@HaftaIlkGun,@HaftaSonGun,@AyIlkGun,@AySonGun,@HaftaGunNo,
			@AyGunNo,@YilGunNo,@AyGunSayi,@YilIlkGun,@YilSonGun,@HaftaSonu)

	--Döngü içerisinde bir sonraki güne geçelim
	SET @IlkTarih = DATEADD(dd, 1, @IlkTarih)
END

Bu scriptleri dili Türkçe olan bir kullanıcıyla çalıştırdığımızda tarih tablosu Türkçe formatına göre oluşturulur. L_Tarih tablosuna 2007 ve 2008 yıllarına ait tarih bilgileri eklenmiş olur.

Bu tablo üzerinde bazı sorgular çalıştıralım. 2008 yılında hangi günden kaç adet bulunduğunu sorgulayalım.

SELECT Max(HaftaGunNo) [Gün Numarası],GunAd [Gün Adı], COUNT(*) Adet
FROM L_Tarih WHERE BuYil = 2008
GROUP BY GunAd ORDER BY 1

Görüldüğü gibi 2008 yılında 53 adet Salı ve Çarşamba günü bulunmaktadır. Aynı şekilde 2008 yılında ayların kaçar güne sahip olduğunu sorgulayalım.

SELECT BuAy [Ay], Max(AyAd) [Ay Adı], COUNT(Bugun) [Gün Sayısı]
FROM L_Tarih WHERE BuYil = 2008
GROUP BY BuAy ORDER BY 1

Bu tür tablolar OLAP uygulamalarında özetleme seviyeleri olarak kullanılır. Örneğin özellikle reel büyüme değerleri için haftalık, aylık, yıllık karşılaştırmalar herhangi bir tarih hesaplaması yapılmadan kolayca buradaki veriler kullanılabilir. Örneğin satış, sipatiş tablolarıyla JOIN edilerek farklı zaman dilimine göre satış veya sipariş analizleri yapılabilir.

FTP ile dosya alma veya gönderme

Ne yazık ki T-SQL aracılığıyla doğrudan ftp işlemini yönetilememektedir. Bu işlemi yapabilmek için T-SQL’in Ms-Dos Komut istemine komut gönderen harici master..xp_cmdshell yordamı kullanılır. Bu yordam iki parametre alır, ilk parametre işletim sistemi tarafından yürütülecek komutu, ikinci parametre ise yürütme sonucunda istemciye herhangi bir dönüş mesajının döndürülüp döndürülmeyeceğini belirtir.

xp_cmdshell {’command_string’} [, no_output]

FTP işlemi nihayetine System32 klasörünün altında bulunan FTP.EXE aracılığıyla yapıldığı için bu xp_cmdshell yordamına ftp.exe komutunu parametre olarak göndermemiz yeterli olacaktır. Peki FTP için gerekli güvenlik ve dosya bilgileri nasıl gönderilecek. Bunun en güzel çözümü ftp komutlarının harici bir dosyaya yazılması ve bu dosyasının FTP.EXE programına “-s” parametresiyle gönderilmesidir. C:\FtpIslem.txt dosyası oluşturup aşağıdaki gibi sunucu bilgilerini ve sunucu üzerinde çalıştırılacak (put, push) komutları yazıyoruz.

open ftp.ahmetkaymaz.com -> Sunucu Adı
admin -> Kullanıcı Adı
123 -> Şifre
cd /Blog/Upload/Image/ -> Logon olduktan sonra konumlanacak klasör
put C:\Resim1.jpg -> İstemcideki dosyayı sunucuya gönder
quit ->Çıkış komutu

Şimdi Query Analyzer tarafına geçip aşağıdaki gibi T-SQL komutunu çalıştıralım.

EXEC master..xp_cmdshell "ftp -s:C:\FtpIslem.txt"

İhtiyaç duyulduğu durumda bu yordamın sonucu bir tabloya da aktarılabilir. Bunun için aşağıdaki gibi procedure çalıştırılır ve sonuçlar geçici veya kalıcı bir tabloya aktarılır.

CREATE TABLE Sonuc (SatirId int identity(1,1), Aciklama varchar(100))
INSERT Sonuc
EXEC master..xp_cmdshell "FTP -s:C:\FtpIslem.txt"

Eğer FTP işlemini DTS içerisinde yapmak istersek DTS, download işlemi için hazır bir nesne sunar.

FTP Task nesnesini kullanarak güvenlik bilgilerini ve karşıdan hangi dosyanın indirileceği seçilir.

DTS içerisinde FTP tabanlı upload işlemi için yine xp_cmdshell yordamı kullanılır. DTS tasarım ekranındaki “Execute Process Task” aracı kullanılarak FTP.EXE’nin çalıştırılması sağlanır.

SQL Server 2005 ile birlikte DTS’lerin yerini almış olan SQL Server Integration Services (SSIS) aracılığıyla FTP işlemini gerçekleştirmek için daha da kolaylaştırıldı.

“FTP Task” aracı hem dosya gönderme hem de alma işlemini sağlar. Öncelikle bu işlem için bir “FTP Connection” nesnesi tanımlanır. Bu nesnenin özelliklerine ftp güvenlik bilgileri girilir. Ardından aynı şekilde “FTP Task Editor” aracında ne tür bir işlemin yapılacağı girilir.

Uzaktaki dosyaların yereldeki hangi klasöre yükleneceği ve yereldeki hangi dosyaların sunucuya gönderileceği “File Connection Manager Editor” aracılığıyla tanımlanır.

SQL Server üzerinde mail işlemi

SQL Server üzerinde mail göndermek veya okumak için kurulumla birlikte standart olarak gelen SQL Mail aracı veya third party bir araç kullanılabilir. SQL Mail aracı, mail almak ve göndermek için aşağıdaki yordamlar tarafından kullanılan bir T-SQL arabirimi sunar.
xp_startmail
xp_sendmail
xp_findnextmsg
xp_readmail
xp_deletemail
sp_processmail
xp_stopmail

Bu yordamlar harici yordamlar olup sqlmap.dll bileşeni içerisinde bulunur. SQL Mail, MAPI (Messaging Application Programming Interface) tabanlı bir uygulama olup bulunduğu sunucunun MAPI uyumlu bir istemci olarak yapılandırılmasını ister.

SQL Mail servisini başlatmak için sunucu üzerinde bu işlemler için kullanılanacak e-mail adresiyle ilişkili bir mail profilinin oluşturulması gerekir. Sunucu üzerindeki profil oluşturmak veya var olan profilleri düzeltmek için Denetim Masası’ndaki (Control Panel) Mail ikonu kullanılır. Bu ikon Microsoft Outlook ile birlikte oluşturulur. Ardından Enterprise Manager içinde sunucunun altındaki Support Services bölümünden SQL Mail çift tıklanarak varolan profillerden biri seçilir.

Aynı şekilde SQL Agent aracının Properties bölümünden agent’in ilişkili olacağı profil de seçilir. Böylece SQL Server üzerinde otomatik olarak işlenen Job’ların sonucuna dair ilgili profil üzerinde ilgili kişilere mail atılabilir. SQL Mail, SQL Agent servisi başladığında otomatik olarak başlatılır. Veya SQL Mail oturumunu manual başlatmak için xp_startmail yordamı kullanılır. Burada dikkat edilmesi gereken konu SQL Mail içerisinde mevcut profillerin doğru görüntülenmesi için SQL Server ve SQL Agent servisinin bir domain veya local account ile başlatılması gerekir. Mevcut bir profili test etmek için SQL Mail’in Properties menüsü kullanılabileceği gibi master.dbo.xp_test_mapi_profile yordamı da kullanılabilir. Test işlemleri başarılı olduktan sonra xp_sendmail yordamını kullanarak bir mailing denemesi yapabiliriz.

EXEC xp_sendmail @recipients='ahmet.kaymaz@ahmetkaymaz.com;blog@ahmetkaymaz.com', @subject='ALISVERIS veritabanı yedeği başarıyla alındı.'

xp_sendmail yordamı birçok parametreye sahiptir. SQL Mail’i kullandığımız diğer alan ise SQL Server üzerinde tanımlı operatörlerdir. SQL Agent’in çalıştırdığı Job’ların sonucunu operatörleri bildirmek için SQL Mail alt yapısı kullanılır. SQL Server Agent bölümünün altındaki Operators alanında bir operatör tanımlayalım. Operatör için e-mail adresi, cep telefonu gibi bilgiler girilir. Aşağıdaki şekilde

Outlook Express mail profili oluşturmayı desteklemediği için SQL Mail için kullanılamaz. SQL Mail 2000 için en az Microsoft Outlook 98 veya 2000 sürümlerinin istemci olarak kullanılıyor olması lazım. Bununla birlikte SQL Mail, Lotus Notes veya Novell Groupwise gibi third-party sunucularla birlikte de kullanılabilir.

xp_sendmail yordamının SQL Server 2005′ten sonraki sürümlerde kaldırılması muhtemel. Bu yüzden SQL Server 2005 ile birlikte gelmiş olan Database Mail servisinin kullanılması tavsiye edilir.

Görüldüğü gibi SQL Mail bileşeni biraz uğraştırıcı ve yönetimi zor bir hizmet sunmaktadır. Ayrıca SQL Mail ile halıhazırda HTML formatında mail de atılamamaktadır. Başka bir alternatif ise SQL Mail kullanmadan yine Microsoft ürünü olan CDO for NT Server (CDONTS) veya CDO for Windows 2000 (CDOSYS) bileşenlerini kullanmaktır. Bu bileşenler sp_OA (SQL Server OLE Automation) stored procedure’leri aracılığıyla T-SQL içerisinde kullanılabilir. Bu bileşenler özellikler web tabanlı uygulamalarda mail atmak için tercih edilen basit SMTP bileşenleridir. Microsoft Internet Information Server (IIS) 4.0 ve üstü versiyonlar varsayılan olarak CDONTS bileşenini install eder. Aşağıdaki T-SQL yordamda CDONTS nesnesi yaratılmış ve Send() yordamına parametreler set edilmiştir.

CREATE PROCEDURE xp_CDOMailGonder(
	@Kimden varchar(100),
	@Kime varchar(255),
	@Baslik varchar(255),
	@Mesaj varchar(500)
) AS

DECLARE @Obj int, @OLESonuc int

--CDONTS.NewMail nesnesini oluşturalım
EXECUTE @OLESonuc = sp_OACreate 'CDONTS.NewMail', @Obj OUT

--Nesnenin Send yordamını çağıralım
execute @OLESonuc = sp_OAMethod @Obj, 'Send', Null, @Kimden, @Kime, @Baslik, @Mesaj, 0

--Destroy CDO nesnesini yok edelim
EXECUTE @OLESonuc = sp_OADestroy @Obj

return @OLESonuc

Bu yordamı çağıralım.

xp_CDOMailGonder 'ahmet.kaymaz@ahmetkaymaz.com','mehmet@hotmail.com','Başlık','Açıklama'

SQL Mail yerine CDONTS bileşenini kullandığımızda Microsoft Outlook gibi mail istemciye ve Microsoft Exchange sunucusuna ihtiyacımız olmayacaktır. Fakat SQL Mail gibi herhangi bir profilin bağlı olduğu mail hesabına ait mailler okunamaz. SQL Mail’de mailleri okumak için xp_readmail yordamı kullanılır. Ayrıca CDONTS.NewMail yalnızca local smtp sunucuları destekler uzataki bir SMTP sunucusunu relay olarak kullanamayız. Son olarak Windows Server 2003 ve üstü işlem sistemlerinde CDONTS bileşeninin desteklenmeyeceğini göz önünde bulundurmalıyız.

CREATE PROCEDURE xp_CDOSYSMailGonder
	@Kimden  varchar(500) ,
	@Kime varchar(500) ,
	@Baslik varchar(500),
	@Mesaj varchar(4000) ,
	@SmtpSunucu varchar(25),
	@MesajTip varchar(10)
as
declare @Obj int
declare @OLESonuc int
declare @source varchar(255)
declare @description varchar(500)
declare @output varchar(1000)

exec @OLESonuc = sp_OACreate 'CDO.Message', @Obj out
exec @OLESonuc = sp_OASetProperty @Obj,
'configuration.fields("http://schemas.microsoft.com/cdo/configuration/sendusing").value','2'

exec @OLESonuc = sp_OASetProperty @Obj,
  'configuration.fields("http://schemas.microsoft.com/cdo/configuration/smtpserver").value',
  @SmtpSunucu 

exec @OLESonuc = sp_OAMethod @Obj, 'configuration.fields.update', null
exec @OLESonuc = sp_OASetProperty @Obj, 'to', @Kime
exec @OLESonuc = sp_OASetProperty @Obj, 'from', @Kimden
exec @OLESonuc = sp_OASetProperty @Obj, 'subject', @Baslik

-- Html e-mail için 'htmlbody' düz metin için 'textbody' özelliği kullanılır

exec @OLESonuc = sp_OASetProperty @Obj, @MesajTip, @Mesaj
exec @OLESonuc = sp_OAMethod @Obj, 'send', null

exec @OLESonuc = sp_oadestroy @Obj

Bu stored procedure’i çağıralım.

exec xp_CDOSYSMailGonder
	@Kimden='ahmet.kaymaz@ahmetkaymaz.com',
	@Kime ='sqlblog@ahmetkaymaz.com',
	@Baslik ='Yeni Mail',
	@Mesaj ='HTML formatında mail.',
	@SmtpSunucu ='192.1.1.120',
	@MesajTip ='HTMLBody'

Son iki yöntemin özelliği Microsoft’a ait SMTP bileşenlerini kullanıyor olmamızdır. Bilindiği gibi dışarıdan herhangi bir bileşeni T-SQL içerisinde kullanmak için sp_OAXXX yordamları kullanılır. Bu yordamları kullanarak nesne oluşturulur ve nesnelerin yordam ve özellikleri dışarıdan çağrılabilir. Dolayısıyla yine bu yordamları kullanarak sadece CDONTS veya CDOSYS bileşenlerini kullanmak zorunda değiliz herhangi başka bir SMTP componentini de kullanabiliriz. Bu noktada kişisel olarak uygulamalarda bu iki nesneden kaçınarak http://www.sqldev.net/xp/xpsmtp.htm sitesinden indirilebilecek olan XPSMTP.DLL - SQL Server SMTP Mail XP bileşenini tercih ediyorum. Sqldev sitesinden indirilecek olan XPSMTP80.DLL
dosyası sunucuya register edilir. Register işleminden sonra ilgili database altında xp_smtp_sendmail yordamı oluşturulur. Sitede anlatılan parametreleri kullanarak kolayca mailing işlemi yapılabilir.

SQL Server üzerinde mail atmak için kullanılabilecek diğer bileşen de bir çok yazılımcının özellikle web uygulamalarında tercih ettiği JMAIL componentidir. Bu componentin sınıf yapısı http://dimac.net/ adresinden öğrenbilebilir. JMAIL’in kullanımı da örneklendirelim.

CREATE PROCEDURE xp_JMailMailGonder
	@Kimden varchar(255),
	@Kime varchar(255),
	@Attachment varchar(255) = '', -- Attach edilecek dosyanın konumu
	@Baslik varchar(255),
	@Mesaj varchar(1000),
	@MesajDosya varchar(1000) = '', -- Mailin içeriğinin bulunduğu dosya
	@SmtpSunucu varchar(100)
as

DECLARE @Obj int
DECLARE @Sonuc int
DECLARE @Sonuc1 int
DECLARE @Sonuc2 varchar(255)

EXEC @Sonuc = sp_OACreate 'jmail.Message', @Obj out

EXEC @Sonuc = sp_OAMethod @Obj, 'AddHeader', NULL, 'App-Sender',@Kimden

EXEC @Sonuc = sp_OASetProperty @Obj, 'From', @Kimden

EXEC @Sonuc = sp_OAMethod @Obj, 'AddRecipient', NULL, @Kime,''
--Son parametre gönderilen kişinin adını belirtir

IF @Attachment <> ''
	BEGIN
		EXEC @Sonuc = sp_OAMethod @Obj, 'AddAttachment', @Sonuc1 out, @Attachment, TRUE
	END

EXEC @Sonuc = sp_OASetProperty @Obj, 'Subject', @Baslik

IF @MesajDosya <> ''
	BEGIN
		EXEC @Sonuc = sp_OAMethod @Obj, 'AppENDBodyFromFile', NULL, @MesajDosya
	END
ELSE
	BEGIN
		EXEC @Sonuc = sp_OASetProperty @Obj, 'Body', @Mesaj
	END

EXEC @Sonuc = sp_OASetProperty @Obj, 'ContentType', 'text/html'

EXEC @Sonuc = sp_OASetProperty @Obj, 'Charset', 'ISO-8859-9'

EXEC @Sonuc = sp_OAMethod @obj, 'SEND', @Sonuc2 out, @SmtpSunucu

RETURN 0

Bu yordam her EXEC satırından @Sonuc değişkeninin “IF @Sonuc <> 0 RETURN 1″ şeklinde bir kontrol eklenerek o satırın hata döndürmediği kontrol edilebilir. Sonuçta eğer procedure 1 döndürürse hata oluştuğu 0 döndürürse işlemin başarı olduğu anlamına gelir. Yordamı aşağıdaki gibi kullanabiliriz.

SQL Server 2005 Database Mail

Yazının girişinde SQL Mail özelliğinin SQL Server 2005′ten sonraki sürümlerde kaldırılacağını bunun yerine Database Mail aracının geliştirildiğini söylemiştik. Database Mail, SQL Mail gibi herhangi bir Outlook veya Exchange Server’e ihtiyaç duymadan sunucu üzerinden mail atmamıza sağlar. Aynı zamanda birden fazla SMTP sunucuyu da parametre olarak kabul eder. Management Studio içerisinde bağlı olunan sunucuda Management bölümünün altında Database Mail aracını sağ tıklayıp yapılandırmaya başlayabiliriz.

“Database Mail Configuration Wizard” aracının ilk ekranında profil yönetimi sunulur. Bu ekranda yeni bir profil oluşturulabilir veya var olan profiller düzenlenebilir. Profil altında bir veya daha fazla mail hesabı tanımlaması yapılır.

Yapılan ayarların doğru çalışıp çalışmadığını da Database Mail aracını sağ tıklayarak test edebiliriz. SQL Agent servisini oluşturulmuş olan profillerle ilişkilendirebiliriz. Böylece Job’ların başarılı veya başarısız olması durumunda profildeki kişi veya kişiler haberdar edilir. SQL Agent’in bilgilendirme ayarları için servisi sağlayıp Properties penceresine girelim.

T-SQL içerisinde Database Mail ile ilgili kullanılabilecek başlıca yordamlar şunlardır;
sp_send_dbmail
sysmail_add_account_sp
sysmail_add_profile_sp
sysmail_delete_account_sp
sysmail_delete_profile_sp
sysmail_start_sp
sysmail_stop_sp

Bu yordamlar msdb veritabanının altında bulunmaktadır. Örneğin aşağıdaki script Ahmet Kaymaz profilini kullanarak listedeki kişilere mail atar.

EXEC msdb.dbo.sp_send_dbmail
	@recipients=N'ahmet@ahmetkaymaz.com',
	@subject = 'Mail başlığı',
	@body= 'Mailin içeriği',
	@profile_name = 'Ahmet Kaymaz'

Gönderilmiş olan mailler msdb.dbo.sysmail_allitems tablosunda tutular.

SQL Server 2005′te SQL Mail ve Database Mail özellikleri varsayılan olarak kapalı durumdadır. Bunları “SQL Server Surface Area Configuration” aracını kullanarak enable edebiliriz.

12 Öfkeli Adam, yönetmen Sidney Lumet’in ilk filmi olmasına rağmen farklı bir teknik kullanması ve oyuncuların etkileyici performası sayesinde sinema dünyasının klasikleri arasına girmiştir. Bu filmde 12 adam 1 odada 1 hayat üzerinden Amerika’nın hukuk sistemini tartışmaktadır. Bir kişi hariç tüm jüri, İspanyol-Amerikalı genç için “suçludur” kararını verir. Fakat 8.jüri olan Bay Davis (Henry Fonda) bu karara karşı çıkar ve bu küçük odada genç sanığı önemsemeyip biran önce evine işine dönmek için sabırsızlanan 11 jürinin ahlaki ve vicdani boyutlarını sorgulamalarını sağlar. 12 Öfkeli Adam filmi, sürü psikolojine, önyargılara ve ezberciliğe karşı cesaret, sabır ve zekayla nasıl savaşılacağının bir örneğidir. Seyirciyi 90 dakika boyunca o küçük odada bir koltuğa oturtan ve sonunda karar konusunda seyirciye sorumluluk yükleyen bir filmdir. Ayrıca milyon dolarları harcamadan, etkileyici bir senaryo sayesinde klasik filmlerinin de yapılabileceğinin bir göstergesidir.

Arşive eklenmesi ve önyargıların, şüpheciliğin etkili olduğu ülkemizde örnek olması açısından şiddetle tavsiye edilir.

Snapshot’ların normal kopyalamadan diğer farkı da bunların ana veritabanına bağlı yaşamalarıdır. Ana veritabanı erişilemez olduğu durumda ona bağlı snapshot’lar da erişilmez olur. Aynı zamanda snapshot, doğrudan peer to peer transactional replikasyon gibi çalışmadığı için bir failover çözümü (high availability) olarak kullanılamaz. Database Snapshot, SQL Server 2005 Enterprise Edition ve üst sürümler tarafından desteklenmektedir ve snapshot üzerinden bir backup alınamaz. Son not olarak snapshot’un FAT32 dosya sistemi ve RAW partition’lar üzerinde oluşturulamayacağını da yazıp snapshot’un nasıl oluşturulacağını bakalım.

Database snapshot oluşturmak için T-SQL’de aşağıdaki gibi basit bir komut yapısı kullanılır.

CREATE DATABASE Kaynak_ss_20080115 ON (
NAME = Kaynak,
FILENAME = 'C:\Kaynak_20080115.ss')
AS SNAPSHOT OF Kaynak;

Bu script, 15/01/2008 tarihi itibariyle Kaynak veritabanının fotoğrafını çekip C:\Kaynak_20080115.ss dosyasını aktarır. Snapshot nihayetinde bir database olduğu için management studio içerisinde diğer databaseler üzerinde gezindiğimiz gibi bunun üzerinde de gezinebilir. Oluşturulmuş snapshot’lar Databases bölümündeki “Database Snapshots” bölümünde listelenir.

Şu an itibariyle snapshot dosyasının içeriği boş durumdadır. Aşağıdaki gibi snapshot üzerinde bir sorgulama yaptığımızda otomatik olarak orijinal veritabanından okunma yapmış oluruz.

SELECT * FROM Kaynak_ss_20080115.dbo.Musteri

Snapshot bir ve daha fazla sparse file (seyrek dosyas) kullanır. Sparse file NTFS’in bir özelliği olup sadece veri yazılan kısımlarının diskte yer kapladığı dosyadır. Yani sparse file başlangıçta herhangi bir data içermez ve henüz data için disk üzerinde herhangi bir yer kaplamaz. Snapshot’un bağlı olduğu orijinal veritabanı ne kadar çok güncellenirse sparse file o kadar büyümeye başlar. MSDN’den alınmış aşağıdaki şekilde bu süreci göstermektedir.

Herhangi bir geri dönme durumunda snapshot ile orijinal database’i JOIN edip orijinal database’i update edebiliriz. Tanımlı bir snapshot’tan doğrudan restore işlemini yapmak için aşağıdaki tanım kullanılır.

RESTORE DATABASE Kaynak
FROM DATABASE_SNAPSHOT= 'Kaynak_ss_20080115'

Eğer bu işlem esnasında “Database cannot be reverted. Either the primary or the snapshot names are improperly specified, all other snapshots have not been dropped, or there are missing files.” hatası oluşursa restore edilecek snapshot dışındaki snapshotların silinmesi gerekir.

Snapshot’u silmek için DROP komutu kullanılır.

DROP DATABASE 

Snapshot’ların kendine özgü üst-veri (metadata) bilgisi bulunmaz. Orijinal veritabanına ait üst-veri bilgileri taşırlar. Nitekim herhangi bir snapshot veritabanının veri ve log dosyalarını sorguladığımızda o snapshot’un bağlı olduğu orijinal veritabanının bilgileri gelir.

USE  SELECT * FROM sys.database_files 

Önceki yazıda ifade ettiğimiz gibi database mirroring’de yedek sunucunun NORECOVERY modunda olması bir dezavantaj olarak karşımıza çıkmaktadır. Fakat mirroring ile birlikte snapshot’un kullanılması yedek sunucunun readonly olarak hizmet vermesini sağlar.

Database Mirroring modelini önemli kılan özellikleri şunlardır;

• Tam yedekleme yaparak ikinci sunucunun daima hazır olmasını sağlar.(Hot standby)
• Sistemde bir hatanın oluşması durumunda otomatik geçiş (automatic failover) zamanın kısa olmasıdır.
• Database failover’da veri kaybının yok denecek kadar az olması
• Standart sunucular ve depolama aygıtlarıyla birlikte çalışır.

Database mirroring modelinde principal (ana veritabanı), mirror (yedek veritabanı) ve witness (şahit sunucu) olmak üzere aktör bulunur. Principal ve mirror sunucuları zorunlu witness sunucusu ise seçmeli olarak kurulur. Principal rolündeki sunucu merkezi sistem olup ana transactionların çalıştırıldığı yerdir. Bu sunucu üzerinde çalışan her transaction mirror servisi tarafından mirror rolündeki yedek sunucu üzerinde de çalıştırılır. Böylece her iki sunucu veri ve şema anlamında eşleşmiş olur. Witness rolündeki sunucu ana ve yedek sunucuların ayakta olup olmadığını kontrol eden, ana sunucu devre dışı olduğu zaman sistemi yedek sunucuya otomatik olarak geçiren bağımsız bir sunucudur. Herhangi bir SQL Server sürümünü witness sunucu olarak kullanabiliriz. Witness sunucu birden fazla mirroring oturumuna destek verebilir. Aşağıdaki şekilde bu temel kavramlar ve gerektiğinde automatic failover sürecinin nasıl gerçekleşeceği gösterilmiştir.

Database mirroring modelinde sadece bir principal ve ona ait bir mirror veritabanı/sunucu olabilir.

Database mirroring işlemi veritabanı bazında yapılır. Hangi veritabanının yedeği alınacaksa öncelikle recovery modelini full olarak işaretlemeliyiz. Diğer önemli adım diğer yöntemlerde olduğu gibi SQL Server Agent kullanıcı yetkilerini uygun şekilde düzenlemeliyiz. Örnek senaryomuzda aynı makine üzerinde koşan üç sunucuyu kullanacağız.
Principal: AHMETKAYMAZ\AHMETKAYMAZ1
Mirror: AHMETKAYMAZ\AHMETKAYMAZ2
Witness: AHMETKAYMAZ

AHMETKAYMAZ1 sunucu üzerindeki KAYNAK veritabanını AHMETKAYMAZ2 üzerinde yedekleyeceğiz. Bunun için ilk adım olarak kaynak veritabanının full backup’ını alıp karşı makineye restore etmemiz gerekir. Yedek alma işlemini Management Studio üzerinden yapabileceğimiz gibi T-SQL Script ile de yapabiliriz.

BACKUP DATABASE Kaynak TO DISK='C:\Kaynak_full.BAK'

İkinci adım olarak bu full backup karşı makineye restore edeceğiz. Aynı şekilde işlemi Management Studio üzerinden yapabileceğimiz gibi T-SQL script ile de yapabiliriz. Bizim senaryoda tüm sunucular aynı makine üzerinde olduğu için ikinci sunucuda mdf ve ldf dosyalarına farklı bir konum vermek gerekir.

RESTORE DATABASE Kaynak
	FROM DISK='C:\Kaynak_full.BAK' WITH NORECOVERY,
		MOVE 'Kaynak' TO 'C:\Kaynak.mdf',
		MOVE 'Kaynak_Log' TO 'C:\Kaynak.ldf'

Database Mirroring modelinde başlangıç adımı olarak kaynak veritabanına ait full backup’tan sonra bir log backup’ın yedek sunucuya restore edilmesi gerekir. Bunun için full backup sonrası bir log backup alalım.

Backup Log Kaynak to Disk='C:\Kaynak_log.bak'

Bu log backup yedek sunucuya restore edelim.

Restore Log Kaynak from Disk='C:\Kaynak_log.bak' with NORECOVERY

Burada dikkat edilemesi gereken konu yedekler yedek sunucuya NORECOVERY seçeneğiyle restore edilmesidir. Bu da çalışma anında yedek sunucu üzerinde sorgulama yapılamayacağı anlamına geliyor. Bu özellike mirroring’in diğer yöntemlere göre bir dejavantajı olarak karşımızı çıkmaktadır.

Modeldeki sunucuların rollerini tanımlamadan önce Endpoint’leri tanımlamamız gerekir. SQL Server 2005′te EndPoint (Uç Nokta) kavramı harici kaynaklar ile SQL Server arasındaki iletişimi güvenlik kılmak için oluşturulan bir yönetim mekanizmasıdır. Endpoint, uzaktan erişilen sunucunun içerdeki bir yordamı güvenli bir şekilde çağırmasını sağlar.

SQL Server üzerinde TCP ve HTTP olmak üzere iki tür endpoint yaratılabilir. TCP endpoint’ler, database mirroring iletişimi için kullanılırken HTTP point’ler SOAP tabanlı talepler için kullanılır. SQL Server 2005′in XML web servisi desteği HTTP endpoint’ler aracılığıyla gerçekleşir. Sunucu üzerindeki Http dinleyicisi (Http Listener - HTTP.sys) gelen talepleri SQL Server üzerinde tanımlı endpoint’lere iletir. Endpoint’ler aracılığıyla SQL Server 2005 üzerindeki bir function veya stored procedure’in http üzerinde gelen talepleri yanıtlanması sağlanmıştır. Bir endpoint oluşturulurken başlangıç durumu (Started, Stoped veya Disabled), hangi iletişim protokolü (Tcp, Http) üzerinden servis vereceği, dışarıdan erişim için url adresi ve portu, endpoint’in yer aldığı veritabanı gibi bilgiler başta belirtilir. Endpoint nesneleri diğer nesneler gibi CREATE, ALTER, DROP ifadeleriyle yönetilir. Endpoint’lerle ilgili ek parametreler için “CREATE ENDPOINT” ifadesini bakılabilir. Her Bir SQL Server sunucu için tek bir database mirroring endpoint’i oluşturulabilir. Konumuza tekrar dönecek olursak ana sunucu için Kaynak veritabanı üzerinde bir endpoint tanımlayalım.

Create Endpoint Mirroring_Endpoint
	State= Started as TCP (Listener_Port=5001)
	For Database_Mirroring (Role=Partner);

Aynı komutu yedek sunucu üzerinde de çalıştıralım. Burada dikkat edilmesi gereken konu mirror, principal ve witness noktaları aynı sunucu üzerinde tanımlı olacaksa her birinin hizmet verdiği portun farklı olması gerekir. Bu yüzden principal için 5001, mirror için 5002 ve witness için 5003 portunu girelim. Witness rolündeki sunucu için yukarıdaki komutu (Role=Partner) ifadesini (Role=Witness) ile değiştirerek çalıştıralım.

Create Endpoint Mirroring_Endpoint
	State= Started as TCP (Listener_Port=5003)
	For Database_Mirroring (Role=Witness);

Bu ifadeyle birlikte her sunucu üzerinde o sunucunun rolüne uygun olarak 5001 portunda hizmet veren bir endpoint tanımlanmış oldu. Bir endpoint’in aynı anda mirror, principal ve witness olarak çalışabilmesi için yukarıdaki komutta (Role=ALL) olarak tanımlanmalıdır. Sunucu üzerinde tanımlı endpoint bilgileri sys.endpoints, sys.database_mirroring_endpoints, sys.http_endpoints, sys.tcp_endpoints, sys.soap_endpoints katalog tablolarında tutulur. Tanımlı olan endpoint’i kaldırmak için aşağıdaki satır kullanılır.

Drop Endpoint 

Sonraki adım olarak sunucuların dışarıdan gelecek istekleri dinleyecek protokol ve portlarını tanımlıyoruz. Sunucular üzerinde database mirroring oturumlarını başlatmak için aşağıdaki komut kullanılır. Öncelikle yedek sunucu üzerinde database mirroring session açalım. Yedek sunucuda aşağıdaki satırı çalıştıralım.

ALTER DATABASE [Kaynak]
SET PARTNER = N'TCP://Ahmetkaymaz:5001'

Ardından ana sunucuya geçip bu sunucu üzerinde oturumu başlatalım.

ALTER DATABASE [Kaynak]
Set Partner= 'TCP://Ahmetkaymaz:5002';

Eğer bu işlemler esnasında Database “Kaynak” is not configured for database mirroring. hata mesajıyla karşılaşırsak işlemleri buradaki sıralamaya uygun yapmadığımız anlamına gelir.

Üçüncü adım olarak witness server üzerinde oturumu başlatalım. Ana sunucu üzerinde aşağıdaki komutu çalıştırarak mirroring modelinde kimin şahitlik yapacağını bildirelim.

ALTER DATABASE [Kaynak]
SET WITNESS = N'TCP://Ahmetkaymaz:5003'

Bu komutla birlikte Kaynak veritabanını ve diğer sunucuları database mirroring için yapılandırmış olduk.

Eğer bu aşamada “Database mirroring is disabled by default. Database mirroring is currently provided for evaluation purposes only and is not to be used in production environments . . .” hata mesajı alınırsa sunucunun üzerinde SP1′in kurulu olmadığı anlamına gelir. SQL Server 2005 RTM sürümü (9.0.1399) varsayılan olarak database mirroring işlemine kapalıdır. Eğer “Database Mirroring Transport is disabled in the endpoint configuration.” hata mesajı oluşursa sunucu üzerinde mirroring endpoint’lerin yaratılmadığı anlamına gelir.

Sunucular üzerinde mirroring oturumlarını açtığımız için otomatik olarak mirroring işlemi başlatılmış olur. Nitekim Management Studio içerisinde ana ve yedek sunucuların durumları aşağıdaki gibi görünür.

Database mirroring geçici olarak durdurmak için aşağıdaki komut yapısı kullanılır.

ALTER DATABASE [Kaynak] SET PARTNER SUSPEND

Süreci kaldığı yerden devam ettirmek için aşağıdaki komut yapısı kullanılır.

ALTER DATABASE [Kaynak] SET PARTNER RESUME

Bundan böyle ana veritabanı üzerinde yapılan değişiklikler otomatik olarak yedek sunucuya da gönderilir. Witness sunucu kısa aralıklar her iki sunucunun ayakta olup olmadığını denetler. Herhangi bir şekilde ana sunucunun erişilmemesi durumunda yedek sunucuyu devreye sokar ve ona principal rolünü verir. Özellikle Witness sunucunun erişilmedi durumlarda otomatik geçişini manual yapmak gerekebilir. Bunun için birinci sunucuda aşağıdaki komut satırı kullanılır.

ALTER DATABASE Kaynak SET PARTNER FAILOVER

Bu durumda ana veritabanı ikinci sunucu üzerine geçirilmiş olur. Nitekim Management Studio içerisinden baktığımızda rollerin değiştiğini görebiliriz.

Aynı senaryoyu birinci sunucunun SQL Server servisini durdurarak ta gerçekleştirebilirdik.

Burada failover işlemini principal veritabanı üzerinde başlattık. Fakat bazı durumlarda bu veritabanı erişilemiyor olabilir. Bu durumda failover işlemini mirror veritabanı üzerinden başlatmak daha doğru olacaktır. Bunun için de aşağıdaki komut satırı kullanılır.

ALTER DATABASE Kaynak SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

Aslında eğer ortada bir witness sunucu varsa telaşlanmamıza gerek yok çünkü ana veritabanının failure olması durumunda yedek sunucu otomatik olarak tetiklenecektir. Eğer witness sunucu yoksa veya aktif değilse o zaman geçiş işlemini önceki iki komutla manual yapmak gerekir.

Şu ana kadar komut sistemiyle anlattığımız tüm işlemler Management Studio aracında görsel olarak daha kolayca hazırlanabilir. Bunun için yapılması gereken şey backup ve restore işlemlerini yaptıktan sonra ana veritabanını sağ tıklayıp “Tasks » Mirror” menüsüyle Properties penceresindeki Mirroring bölümünü açmaktır.

Bu bölümde database mirroring ayarları, durumu görülebilir ve gerekirse durdurma, başlatma, failover gibi işlemler buradan yapılır. Bu penceredeki “Configure Security” düğmesi tıklanarak yoksa endpointler ve roller tanımlanır. Tanımlanmış olan roller penceredeki “Server network addresses” bölümünde listelenir.

Database mirroring bu penceredeki “Stop Mirroring” düğmesiyle kapatılabileceği gibi aşağıdaki komut satırıyla da iptal edilebilir.

ALTER DATABASE [Kaynak] SET PARTNER OFF

Database Mirroring Çalışma Modları

Database mirroring yönteminin High Performance (Yüksek Performans), High Availability (Yüksek Erişilebilirlik) ve High Protection (Yüksek Koruma) olmak üzere üç temel operasyon modeli mevcuttur.

High performance (asynchronous) Witness sunucuya gerek duyulmayan bu modelde transactionlar öncelikle ana veritabanı üzerinde commit edilir ardından başka bir proses tarafından yedek sunucu tarafına transfer edilir. Yani birinci sunucu kendisi üzerinde çalıştırılan bir transaction’nın yedek sunucuda da commit edilmesini beklemez hatta ondan haberdar olmaz. Asekron çalışması bu demektir. Performansın önemli olduğu bu modelde otomatik geçiş işlemi sunulmaz yalnızca manual failover yapılabilir bu yüzden principal sunucu erişilemez olduğu zaman mirror sunucuya ancak warm standby (read-only) olarak erişilebilir. Database yöneticisi mirror sunucunun yukarıda bahsettiğimiz komutları kullanarak rolünü değiştirmelidir. Ayrıca transactionlar asenkron işlendiği için ana veritabanının fail olması durumunda veri kaybı fazla olabilir.

High safety without automatic failover (synchronous)/High-Protection Önceki modelden farkı bu modelde tüm commit edilmiş transactionların mirror sunucunun diskine de yazıldığı garanti edilir. Transactionlar mirror sunucu tarafında onaylandıktan sonra birinci sunucu tarafında onaylanır. Aynı şekilde bir witness sunucu bulunmaz ve principal sunucu erişilemez olduğu zaman mirror sunucu da fakat kendisine warm standby olarak erişilebilir.

High safety with automatic failover (synchronous)/High-Availability Önceki model ile aynı olup tek farkı bir witness sunucunun olmasını zorunlu kılması ve bunun sayesinde automatic failover desteğini vermesidir. Yüksek erişim sunan bu modelde aynı şekilde tüm transactionlar hem principal hem de mirror üzerinde commit edilir. Ana sunucunun erişilemez olması durumunda witness sunucu yedek sunucuya otomatik olarak geçiş yapar. Bu seçeneğin seçilmesi durumunda Replikasyon ve Log Shipping yöntemlerine göre daha yüksek bir erişilebilirlik sağlanmış olur.

Bu seçenekler en son şekilde verilmiş olan “Database Properties” penceresindeki Mirroring bölümünden seçilebilir. Sunucuları düzenlerken Witness server seçmemiz otomatik olarak “High-Availability” modelini seçtirir.

Transparent Client Redirect (Şeffaf İstemci Yönlendirme)

Transparent Client Redirect, Database Mirroring ile ilişkili bir özellik olup primary sunucu erişilemez olduğu zaman istemcilerin otomatik olarak mirror sunucuya yönlendirilmesini sağlar. SQL Server 2005 MDAC’e eklenmiş olan bu özellik sayesinde istemcinin veri erişim katmanında herhangi bir kod değişikliği yapılmaya gerek kalmamaktadır. İlk principal bağlantısında istemci kütüphanesi mirror sunucu adını ön belleğe alır. MDAC primary sunucuyla olaran bağlantısını kaybettiği zaman primary sunucuya yeniden bağlanmayı dener eğer başarılı olmazsa bu sefer yönünü mirror sunucuya döndürür. Bir anlamda MDAC, primary ve mirror sunucular arasında middleware olarak çalışır. Bu için connection string içerisinde ana sunucuyla birlikte yedek sunucunun adresi de verilir. Connection string içerisine eklenecek “Failover Partner” anahtar sözcüğü aracılığıyla birincil veritabanıyla bağlantı kurulamadığı anlarda ek bir kodlama veya yapılandırmaya gerek kalmadan ikinci veritabanına yönlendirme yapılır. Aşağıdaki cümlede belirlenmiş connection süresinde eğer birinci veritabanı (initial partner) olan “DW1″ sunucuyla bağlantı kurulamazsa onun yansıması olarak yapılandırılmış olan ikinci veritabanıyla (failover partner) “DW2″ ile bağlantı kurulmaya çalışılır.

Data Source=DW1;Failover Partner=DW2;Initial Catalog=Kaynak;Integrated Security=True;

Sonuç olarak erişilebilirlik ve performans açısından database mirroring’in iyi bir çözüm olduğunu ve failover clustering ile kıyaslandığında otomatik geçiş süresinin daha kısa olduğunu, ek donanıma ihtiyaç duymadığını ve en önemlisi failover clustering gibi sadece yüksek erişilebilirlik sağlamadığını bu en ek olarak yüksek performans ve koruma sağladığını da söyleyebiliriz. Bununla birlikte yedek sunucunun NORECOVERY modunda olması ve bir veritabanına ait sadece bir mirror’un olması bir dejavantaj olarak değerlendirilebilir.

İlk adım olarak WXX sunucusunu hem publisher hem de distributor olarak yapılandıracağız. Bunun için üst menüdeki Wizard bölümüden veya sunucu ismini sağ tıklayıp Properties bölümünden replikasyon sihirbazını başlatabiliriz. Enterprise Manager içerisinde WXX sunucunu sağ tıklayıp Properties bölümünden Replication sekmesine girelim. Burada Configure düğmesini tıklayalım.

Karşılama ekranını geçtikten sonra “Select Distributor” penceresine geçelim. “Make ‘WXX’ its own Distributor; SQL Server will create a distribution database and log” seçeneği ile Publisher ve Distributor’un aynı sunucu olacağını belirtelim.

Sonraki ekranda snapshot klasörünü belirteceğiz. Replikasyonun mantığı gereği yayıncı ve abonelerin farklı makinelerde koşuyor olmasından dolayı tüm sunucuların erişmesi için bu klasörün network yolunun tanımlanması daha mantıklı olacaktır. Eğer yerel adres verilirsen sadece push subscription’lar desteklenir. Burada C:\SnapshotYedek klasörü için \\WXX\SnapshotYedek ağ yolunu giriyoruz.

Bir sonraki ekranda yayınlama ve dağıtma ayarları gerçekleştirilir. Burada istenilirse ‘distribution’ veritabanının adı ve ona ait data ve log dosyalarının konumu değiştirilebilir.

Bu ekranla birlikte WXX sunucunun hem yayıncı hem de dağıtıcı rolünde olması sağlandı. Bu bölümdeki adımları bitirdiğimizde WXX üzerinde ‘distribution’ veritabanı oluşturulur ve replikasyon sürecini yönetmek ve takip etmek için “Replication Monitor” aracı aktifleştirilir.

Şu an itibariyle yayımcı ve dağıtıcı sunucularını tanımlamış olduk. Şimdi yayımcı sunucunun ne yayınlanacağını (publication), abonelere gönderilecek artikelleri tanımlayacağız. Bunu farklı menülerden yapabiliriz. Bunun en kısa yolu Enterprise Manager içerisindeki “Tools » Replication » Create and Manage Publications…” menüsünü kullanacağız.

Bu menünün açtığı pencerede WXX altındaki Kaynak veritabanını seçip “Create Publications” düğmesini tıklayarak bu database için bir yayın hazırlayalım. Karşılama ekranından sonra bu yayının hangi replikasyon türüyle yayınlacağı seçilir. Burada en basit olan “Snapshot Replication” yöntemini seçeceğiz.

Sonraki ekranda abonelerin veritabanı sistemi düzeyinde türü seçilir. Aboneler SQL Server sisteminden olduğu gibi Oracle, Access gibi heterojen sistemler de olabilir. Burada SQL Server 2000 seçeneğini işaretleyip bir sonraki ekrana geçelim. Bu yeni ekranda yayınlanacak artikelleri seçeceğiz. Burada Kaynak veritabanı altında örnek olarak oluşturduğumuz Musteri tablosunu seçeceğiz.

Bu ekranda tabloların yanındaki “…” düğmesini tıklayarak artikelin adı ve bu nesnelerin karşı taraftaki adı düzenlenebilir. Sonraki ekranlarda varsa IDENTITY uyarısı yapılır ve “define data filters” seçeneğiyle yatay veya dikey filtreleme yapılabilir. Filtreleme işlemi SQL Server replikasyonunun önemli bir özelliği olup tablonun sadece belli kolon veya satırlarını abonelere göndermemize imkan sağlar. Bu ekranlarda varsayılan seçenekleri işaretleyip yayın tanımlama sürecini bitirelim. Bu işlemden sonra hem Kaynak veritabanının altında hem de Publications bölümünde tanımlanan yayın bilgisi görünür.

Bu aşamada yayıncı ve onun yayınlayacağı makaleler ve bunları dağıtacak dağıtıcı tanımlanmış oldu. Şimdi bu yayınlara abone olacak üyeleri tanımlayacağız. Bunun için “Tools » Replication” menüsü kullanılabildiği gibi Replications bölümü altındaki yayın (Kaynak) sağ tıklanarak “Push New Subscription” menüsü kullanılabilir. “Push Subscription Wizard” ekranında bir veya daha fazla muhtemel abone seçilebilir. Burada WXX\KAFKA sunucusunu seçeceğiz.

Sonraki ekranlarda Kaynak veritabanının karşı taraftaki karşılığının ne olacağı ve Distribution Agent’in bir kere mi yoksa belli peryotta mı çalışıp çalışmayacağı belirtilir. Üye makinelerde Kaynak veritabanının oluşturulmuş olması lazım. Bunu bu ekranda “Browse or Create” buttonuyla sağlayabiliriz.

Görüldüğü gibi SQL Server ortamında replication işlemini yapmak çok kolay. Bu yazıda örnek Snapshop replication türünü ele aldık. Replikasyon türünün seçildiği ekranda Transactional veya Merge türleri seçilerek bu yöntemler de yapılandırılabilir. Transactional replikasyon için sözkonusu tablolar üzerinde primary key’in tanımlı olması gerekir.

SQL Server 2005′te replikasyon işlemini yapmak daha da kolaylaştı. Bu işlemi yapılandırmak için Management Studio’da Replication bölümü kullanılır. Aşağıdaki şekilde AHMETKAYMAZ isimli aynı sunucu üzerinde Kaynak1 veritabanı Kaynak2 veritabanını aktarılmıştır.

SQL Server replikasyonla ilgili olarak aşağıdaki notlarla yazımızı bitirelim.

• SQL Server 2005 ile aynı replikasyonda topolojisinde bulunacak SQL Server sürümü en az SQL Server 7.0 (SP4) ve SQL Server 2000 (SP3) olması gerekir.
• Diskte veri saklama formatları aynı olduğu için SQL Server’in 32-bit ve 64-bit sürümleri aynı replikasyon modelinde kullanılabilir.
• Farklı SQL Server sürümleri arasında replikasyon kurulacağı zaman Distributor sunucunun versiyonu Publisher’dan daha eski olmamalı.
• SQL Server 2005 ancak publisher modunda olan SQL Server 2005 ve SQL Server 2000 için Distributor olabilir. SQL Server 7.0 için dağıtıcılık yapamaz.

MSDN’den alınmış aşağıdaki tablolar hangi SQL Server sürümlerinin aynı topolojide bulunabileceğini göstermektedir.

Salt-Okunur Aboneler için Transactional Replication ve Snapshot Replication

Güncellenebilen Aboneler için Transactional Replication

Merge Replication

Bu yazıda SQL Server 2000 replication ve SQL Server 2005 replication işlemlerinin nasıl yapılacağını öğrenmiş olduk.

Publisher (Yayıncı): Üye veritabanlarına veri gönderen merkezi sunucu ya da veritabanı. Replikasyondaki kaynak verinin bulunduğu yerdir.
Subscriber (Abone): Merkezi veritabanından verileri alan sunucu ya da veritabanı. Abonele varsayılan olarak merkezi veritabanının salt-okunur (read-only) kopyasına sahiptir ancak farklı bir konfigürasyonla abonelerde de değişikliğe izin verilebilir veya yapılan değişiklikler merkezi veritabanına yansıtılabilir.
Distributor (Dağıtıcı): Yayıncı ile abone arasındaki veri akışını yöneten sunucu. Bu amaçla distribution isimli veritabanına sahiptir. Bu veritabanında veri ve şema bazında yapılmış değişiklikler tutulur. Bir veritabanı sunucusu aynı anda hem publisher hem de distributor rolünde olabilir.
Article (Makale): Yayıncı tarafından yayınlanan içerik. VTYS’de üye sunuculara gönderilecek veritabanı nesneleridir (table, view, stored procedure). Makale koleksiyonu publication (yayın) olarak tanımlanır.
Push ve Pull Subscription (Abonelik gönderme ve çekme): Push subscription’da distributor verileri subscriber veritabanına kopyalar. Bu yöntemde işin yükünü distributor çeker. Pull subscription’da ise subscriber kendisi distributor’dan verileri çeker yani işin yükü abonelere verilmiş olur.

Replikasyon Topolojileri (Modelleri)
Replikasyon topolojileri, bu yöntemdeki başrollerin (yayıncı, dağıtıcı, abone) sayısını ve fiziksel konumlarını temsil eder.

Central publisher (Merkezi yayıncı): En çok kullanılan topoloji olup bir sunucu yayıncı ve dağıtıcı diğer sunucu veya sunucular abone/aboneler olarak yapılandırılır.

Central subscriber (Merkezi abone): Tek abone/çoklu yayıncı modeline sahip olup data warehouse sistemlerinde kullanılan bir topolojidir. Birden fazla sunucu/veritabanı verilerini tek bir sunucu/veritabanına replike eder.

Central publisher with remote distributor (Merkezi yayıncı/Uzak dağıtıcı): Bu topolojide distribution veritabanı publisher dışındaki başka bir sunucuda bulunur. Bu topoloji yoğun replikasyon işlemlerin olduğu sistemlerde Publisher’in iş yükünü azaltmak için tercih edilir.

Publishing subscriber: Çift yönlü bir topoloji olup yayıncı sunucu/veritabanı aynı zamanda başka bir sunucunun abonesi olarak tasarlanır. Bu senaryoda iki sunucu aynı veriyi yayınlar. Bu model zayıf veya maliyetli bağlantıya sahip abonelere yayın yapılacağı kullanışlı olur.

Central distributor (Merkezi dağıtıcı): Birden fazla yayıncının yayınını abonelerine dağıtan tek bir dağıtıcının olduğu topolojidir.

Replikasyon Türleri
SQL Server sisteminde üç temel replikasyon türü bulunmaktadır;

Snapshot Replication: Static replication olarak ta bilinen Snapshot Replication en basit replikasyon türü olup her defasında kaynak veritanındaki tüm verileri bağlı abonelere toplu olarak yükler. Snapshot replication’da daha önce abonelere hangi verilerin gönderildiğine bakılmaz. Bu işlemi full backup’ın karşı tarafa restore edilmesi gibi düşünebiliriz. Merkezi veritabanından her defasında tüm data article’leri çıkarması ve abonelere taşıması hem zaman hem de kaynaklar açısından maliyetli olabilmektedir. Bu yüzden bu modeli az transaction işlemlerinin yapıldığı VTYS’lerde veya üyelerin sil baştan yapılandırılması gereken durumlarda kurmak daha elverişli olacaktır.

Transactional Replication:Dynamic replication olarak ta bilinen bu yöntem Snapshot Replication’tan farklı olarak incremental modele sahiptir yani sadece son yapılmış replikasyon işleminden bu yana gerçekleşmiş değişiklikleri üye veritabanlarına adım adım yansıtır. Bunu da merkezi veritabanındaki log dosyasını dinleyerek gerçekleştirir. Değişiklikler üyelere gerçek zamanlı gönderilebildiği gibi belli peryotlarda da gönderilebilir. Bu yöntem çok yoğun transaction işlemlerinin yapıldığı sistemlerde tercih edilir.

Merge Replication : Transactional Replication gibi incremental özelliğe sahip olan bu yöntem çift yönlü bir replikasyon sunar yani hem publisher tarafındaki değişikliği subscriber’a yansıtır hem de subscriber tarafındaki değişikliği publisher’a yansıtır. En karmaşık yapıya sahip olan bu yöntemde veri çakışmaları yaşanabilmektedir. Bu yöntem genellikle birden fazla üyenin bulunduğu topolojilerde bir üyenin yaptığı değişikliği hem merkeze hem de diğer üyelere yansıtılması durumunda veya kullanıcıların online/offline çalışabildiği projelerde (bağlantısız ve mobil uygulamalar) tercih edilir. Merge Replication’dan farklı olarak bir veri üzerindeki tüm değişiklikleri değil sadece son değişikliği karşı tarafa gönderir. Örneğin bir kayıt üzerinde 5 kere düzenleme yapıldıysa Transactional Replication’da bu 5 günceleme de karşı tarafa yansıtılır fakat Merge Replication’da sadece son güncelleme gönderilir.

Transactional ve Merge replikasyonların snapshot replikasyondan temel farkı sadece değişiklikleri abonelere yansıtmaları ve veri yerine transaction ifadelerini abonelere taşımalarıdır. Snapshot ve Transactional replikasyonlar tek taraflı oldukları için bu yöntemlerde abonelerin salt okunur olarak düzenlenmesi daha anlamlı olacaktır. Aksi takdirde yayıncı ve üyeler arasında veri bütünlüğü sağlanamayabilir. Bununla birlikte Transactional replication yönteminde “Updatable Subscriptions for Transactional Replication” seçeneği aktif yapılarak üyelerdeki değişiklik de merkeze yansıtılabilir.

Hangi replikasyon türünü seçersek seçelim öncelikle yayıncı ile üyeleri şema/veri düzeyinde senkronize etmek gerekir. Bunun için yayıncının full backup’ı alınıp üyeler restore edilir. Bu işlem veritabanı yöneticisi tarafından manual yapıldığı gibi SQL server tarafından replikasyonun ilk adımı olarak ta yapılabilir.

Replikasyon Agent’leri
Replikasyon modelinde süreç Sql Server Agent servisi ve bunun altında çalışan bağımsız agentler tarafından yönetilir. SQL Agent C:\Program Files\Microsoft SQL Server\90\COM altında bulunan bu agentleri çalıştırarak işlemleri yürütür. Bu agentler şunlardır;

Snapshot Agent (Snapshot.exe): Yedek veritabanını hazırlamak amacıyla kaynak veritabanındaki nesnelerin şemasını ve veri dosyalarını hazırlayıp snapshot klasörüne ekler. Tüm replikasyon yöntemlerinde etkili olup distributor tarafında çalışır.

Distribution Agent (distrib.exe): Snapshot klasörüne erişip şema ve verileri üyelere kopyalarak onları ilklendirir ve distribution veritabanındaki değişiklikleri abonelere aktarır. Aktarım işlemi pull (çekme) yöntemini kullanıyorsa bu agent, distributor üzerinde, push (gönderme) yöntemini kullanıyorsa distributor üzerinde çalışır. Snapshot ve transactional replication’da kullanılır.

Log Reader Agent (Logread.exe): Sadece Transactional replication’da çalışıp publisher veritabanına ait transactional logları okuyup dağıtıcıya (distribution database) aktarır. Bu agent, dağıtıcı tarafında çalışır.

Queue Reader Agent (qrdrsvc.exe): Aboneler tarafında Microsoft Message Queue’da (MMQ) veya SQL Server’in kendisine ait kuyrukta bekleyen değişiklikleri yayıncıya aktarmak için kullanılır. Dağıtıcıda çalışan bu agent Transactional replication’da seçmeli olarak çalışır. Bu agent’in devreye girmesi için “Queued Updating” seçeneğinin aktifleştirilmesi gerekir.

Merge Agent (replmerg.exe): Snapshot ve transactional replication yöntemlerinde abone veritabanının ilklendirilmesi, distribution veritabanındaki değişikliklerin abone veritabanına yansıtılması Distribution Agent tarafında yapılmaktaydı. Distribution Agent, Merge Replication yönteminde devreye girmez. Distribution Agent’in yaptığı bu işi Merge Replication’da Merge Agent üstlenir. Yayıncı ve ona ait aboneler arasında yayın senkronizasyonu sağlayan bu agent, Pull (çekme) yönteminde, subscriber üzerinde, push (gönderme) yönteminde publisher üzerinde çalışır.

Bu agent’lerin hangi replikasyon yönteminde devreye girdikleri aşağıdaki tabloda gösterilmiştir.

Distribution Database
Distribution veritabanı yayıncı ile ona bağılı aboneleri veri ve şema düzeyinde senkronize etmek için kullanılır. Bu amaçla abonelere yansıtılmayı bekleyen transactionları saklar. Transactionlar aboneler tarafından başarılı bir şekilde alınıp restore edilinceye kadar distribution veritabanında saklı tutulur. Distribution veritabanındaki bazı önemli sistem tabloları şunlardır;

MSmerge_history: Abonelerin önceki güncellemeleri hakkındaki bilgiyi içerir.
MSmerge_agents : Merge agent’leri hakkındaki bilgileri içerir.
MSdistribution_agents: Distribution agent’leri hakkında bilgi içerir.
MSdistribution_history : Distribution agent’lerin geçmişteki işlemlerini içerir.
MSlogreader_agents : Yerel dağıtıcıdaki log reader agent’ler hakkında bilgi içerir.
MSlogreader_history : Log reader agent’lerinin geçmişteki işlemlerini içerir.
MSrepl_commands: Replike edilmiş komutları içerir.
MSrepl_errors: Başarısız olmuş replikasyon işlemlerini içerir.
MSrepl_transactions: Replike edilmiş her transaction için tek satır içerir.
MSrepl_version : Tek bir satıra sahip olup mevcut replikasyonun sürümü hakkında bilgi verir.

Bu makalede replikasyonla ilgili terminolojiyi anlatmaya çalıştık. Sonraki makalede SQL 2000 ve 2005 üzerinde replikasyon türlerinin nasıl kurulacağını örneklendireceğiz.

Kaynakça:
msdn.microsoft.com
www.sbeeh.com
www.databasejournal.com
www.dell.com

1 - İlk adım olarak Log shipping modeline dahil edilecek primary server ve secondary server sunucuları tanımlanır. Bu iki sunucu mutlaka iki ayrı fiziksel sunucu olacak diye bir durum yok. Aynı sunucu üzerindeki iki veritabanı arasında da log shipping işlemi yapılabilir. Ayrıca riski azaltmak amacıyla birden fazla secondary server kurulabilir. Primary database’in full veya bulk-logged recovery modelini kullanması gerekir.

2 - Seçmeli olarak bir monitor server kurulur. Monitor server, primary database üzerinde en son ne zaman transaction log alındığını, secondary server’in en son hangi backup dosyalarını kopyaladığını ve restore ettiğini ve bu süreçteki hataları izler. Monitor sunucunun, primary ve secondary sunucularından ayrı olması tavsiye edilir. Bir monitor sunucusu yapılandırıldıktan sonra log shipping kaldırılmadan bir daha yeniden yapılandırılamaz.

3 - Sunucuların güvenlik ayarının düzenlenmesi. Log shipping işlemini yaptığımız Windows kullanıcısının tüm sunucularda SQL Server systems administrator (sa) yetkilerine sahip olması gerekir.

4 - Paylaşım klasörlerinin oluşturulması. Primary ve secondary olmak üzere iki dosya paylaşımının yapılmış olması gerekir. Önce birinci sunucu tarafında kaynak veritabanının transaction loglarının tutulacağı bir klasör ardından ikinci sunucu tarafında bu logların taşınacağı ve restore edileceği bir klasör oluşturulur. Burada dikkat edilmesi gereken konu her ikisi sunucudaki SQL Agent’in kullandığı Windows kullanıcısının bu klasörler üzerinde yetkilerinin olmasıdır.

5 - Ardından bu üç sunucu (primary, secondary ve monitor) Enterprise Manager / Management Studio üzerine register edilir.

Aşağıdaki şekilde log shipping modeli çizilmiştir.

Şimdi bu işlemleri üzerinde adım adım uygulayalım. Kaynak ve hedef olmak üzere iki tane sunucumuz var.
Primary Server -> WXX\KAFKA
Secondary Server -> DW

Birinci sunucu (WXX\KAFKA) üzerinde log backuplarının alınacağı klasörü oluşturalım. Örneğin C:\LogShipOrnek\Logs\ olarak oluşturduğumuz klasör için \\WXX\Logs\ şeklinde erişebileceğimiz şekilde bir share folder oluşturalım. Bu klasöre hem birinci hem de ikinci sunucu erişecek şekilde yetkilendirme yapalım. Dışarıdan bu klasöre backup dosyaları kopyalanacağı için en iyi çözüm Everyone’a full hak vermektir.

Hem DW hem de WXX\KAFKA sunucusunu Enterprise Manager üzerinde register ettikten sonra “Management » “Database Maintenance Plan” aracığını sağ tıklayarak “New Maintenance Plan” menüsünü tıklayıp sihirbazı başlatalım. Bilgilendirme ekranını geçtikten sonraki ikinci ekranda hangi veritabanlarının bu modele dahil edilip edilmeyeceği seçilir. Log shipping işleminin kullanılması için bu ekrandaki “Ship the transaction logs to other SQL Servers (log shipping).” seçeneğinin seçilmiş olması lazım.

Bu ekrandan sonraki ekranlarda optimizing data, checking integrity veya performing a full database backup ile ilgili herhangi bir seçenek girmeyip “Specify Transaction Log Backup Disk Directory” ekranına gelinceye kadar tüm ekranları geçelim. Bu ekranda “Use This Directory” seçeneğini işaretleyip “C:\LogShipOrnek\Logs” klasörünü gösterelim. Aynı zamanda bu ekrandaki “Remove Files Older Than” seçeneğini kullanarak log backupların ne kadar süre arşivde bekleyeceğini de belirleyebiliriz.

Bu ekrandaki ayarlara göre log dosyaları ilgili klasörde Kaynak_tlog_yyyymmddhhmm.trn olarak kayıt edilir. Sonraki ekran olan “Specify the Transaction Log Share” ekranında log backup klasörünün networkten erişim yolunu yazalım (\\WXX\Logs\ ).

“Specify the Log Shipping Destinations” ekranında Add buttonunu tıklayıp ikinci sunucu veya sunucuları ekleyelim.

Bu ekranda yedek sunucu olarak görev yapacak olan DW sunucusunu ekledik. Ayrıca DW üzerinde veri tabanı ilk defa yaratılacağı için mdf ve ldf dosyalarının hangi klasörde olacağını ve log dosyalarının DW tarafında hangi klasöre kopyalanacağını tanımlıyoruz. Bu ikinci sunucunun nonrecovered durumunda olması gerekir.
no recovery mode - Veritabanına her türlü kullanıcını erişimini engeller
standby mode - Sadece okunabilir (read-only) erişimlere izin verir. Ayrıca transaction logların restore edilmesi esnasında bağlı kullanıcıları sonlandırmak için bu ekrandaki “Terminate users in database” seçeneği kullanılır.

Sunucuyu ekleyip diğer ekrana geçelim;”Initialize the Destination Databases”. Bu ekranda iki sunucuyu eşitlemek için gerekli olan full backup’ın şimdi mi alınması yoksa daha önce alınıp alınmadığını belirtiyoruz. Kaynaktaki veritabanımız çok büyükse bu işlemi gece almamız daha uygun olacaktır. Ekranda gösterildiği gibi full backupın şimdi alınmasını sağlayıp diğer ekrana geçelim.

Sonraki ekran olan “Log Shipping Schedules” ekranı log shipping işlemlerinin hangi sürelerde gerçekleştirileceği belirtilir.
Copy/Load Frequency, ne sıklıkta backup dosyalarının ikinci sunucuya kopyalanacağı ve restore edileceğini belirtir.
Load Delay, backup copy veya restore jobları arasındaki süreyi belirtir. Bu süreyi azaltmak için değeri sıfıra yaklaştırmalıyız. Nitekim bu alanın varsayılan değeri 0′dır.
The file-retention period, ikinci sunucuda log backupların ne kadar süre tutulacağını belirtir. Varsayılan değerde olduğu gibi son 24 saate ait backupların tutulması tavsiye edilir.

Bir sonraki ekrana geçelim. “Log Shipping Thresholds” ekranında backupların alınamaması ve restore jobların çalışmaması için ne kadar mühlet verileceği belirtilir. Diğer ekranda monitor server seçilir. Burada birinsi sunucuyu izleme sunucusu olarak işaretledik.

Sonraki ekranları da düzenleyip kurulum işlemini bitirelim.

“DB Maintenance Plan1″ uygulaması oluşturulduğunda öncelikle WXX\KAFKA tarafındaki C:\LogShipOrnek\Logs klasöründe Kaynak_logshipping_init.bak isimli full backup oluşturulur. Ve ikinci sunucu (DW) tarafında aşağıdaki ifade aracılığıyla bu full backup ikinci sunucuya kopyalanır.

DECLARE @rv int
EXECUTE @rv = master.dbo.xp_cmdshell N'copy "\\Wxx\Logs\Kaynak_logshipping_init.bak" "C:\LogShipOrnek\LogBackupFile\Kaynak_init.bak"', no_output
SELECT @rv

Ardından ikinici sunucu tarafında bu full backup verdiğimiz klasörlere uygun olarak restore edilir.

RESTORE DATABASE [Kaynak] FROM  DISK = N'C:\LogShipOrnek\LogBackupFile\Kaynak_init.bak' WITH  FILE = 1,  NOUNLOAD ,  STATS = 10,  STANDBY = N'C:\LogShipOrnek\Data\undo_Kaynak.dat',  MOVE N'Kaynak_Data' TO N'C:\LogShipOrnek\Data\Kaynak.mdf',  MOVE N'Kaynak_Log' TO N'C:\LogShipOrnek\Data\Kaynak_log.ldf'

Ve yeni yaratılan bu database standby moduna geçirilir.

Log shipping modelinde kullanılan birinci ve ikinci sunucu tanımlamaları, en son hangi düzeyde backup alındığı ve restore edildiği gibi bilgiler msdb altındaki log_shipping_primaries, log_shipping_secondaries ve sysdbmaintplan_databases tablolarında tutulur.

Log shipping ayarlarını düzenlemek veya silmek için “DB Maintenance Plan1″ dosyası çift tıklanır ve açılan penceredeki “Log Shipping” sekmesi kullanılır.

Ayrıca Log Shipping sürecinin takibi için Enterprise Manager altındaki Management bölümündeki “Log Shipping Monitor” alanı kullanılır. Buradan en hangi backupların alındığı, kopyalandığı ve karşıya yüklendiği bilgileri öğrenilir.

Log shipping, backup job, copy job, restore job ve alert job olmak üzere 4 temel job oluşturur. Backup Job, her primary database için primary server üzerinde oluşturulur. Varsayılan olarak bu job 15 dk’da bir çalışır. Copy Job, secondary server üzerinde oluşturulur. Bu job, primary server’den secondary server’e backup dosyalarını kopyalar. Restore Job, secondary server üzerinde oluşturulur. Bu job, kopyalanmış olan backup dosyalarını secondary database’ler üzerinde restore eder. Alert Job, eğer kullanıldıysa bu job monitor server üzerinde oluşturulur. Bizim örneğimizde monitor server olarak birinci sunucuyu seçtiğimiz için bu job birinci sunucu üzerinde oluşturuldu. Bu job, primary ve secondary database’ler tarafından paylaşımlı olarak kullanılıp backup ve restore işlemlerinin başarısız olması durumunda uyarı verir. Eğer monitor server kullanılmazsa alert job hem primary server hem de her secondary server üzerinde oluşturulur. Primary server üzerindeki alert job, backup işlemi başarısız olduğu zaman, secondary server üzerindeki alert job ise kopyalama ve restore işlemleri başarısız olduğu zaman uyarı evrir.

SQL 2005′te log shipping işleminin nasıl yapılacağını da örneklendirelim. Bu sefer hem kaynak hem de hedef database aynı sunucu üzerinde bulunsun.

Primary Server -> AHMETKAYMAZ
Secondary Server -> AHMETKAYMAZ
Primary Database -> Kaynak1
Secondary Database -> Kaynak2

Log backupların alınacağı klasör ->C:\LogShipOrnek\Logs
Log backupların ikinci sunucu tarafından kopyalanacağı klasör -> LogsCopy
Kaynak2 veritabanının veri klasörü->C:\LogShipOrnek\Data
Kaynak2 veritabanının log klasörü->C:\LogShipOrnek\Log

SQL Server Management Studio aracını açıp Kaynak1 veritabanını sağ tıklayarak “Tasks » Ship Transaction Logs” menüsünü Log Shipping penceresini açalım. Bu pencereye Kaynak1 veritabanının Properties bölümünden de erişilebilir.

Bu ekranda öncelikle Kaynak1 veritabanının birincil veritabanı olduğunu belirtiyoruz. Ekrandaki “Backup Settings” buttonunu tıklayıp yedek dosyalarıyla ilgili ayarlar yapalım.

Yedek klasörlerinin ağ ve yerel konumlarını girdikten sonra pencereyi kapatalım. Bir sonraki adım yedek sunucularını tanımlamaktır. Bunun için “Secondary server instances and databases” bölümünde Add düğmesini tıklayalım. “Secondary Database Settings” penceresinde ikinci sunucuyla ilgili ayarlar yapılır. Connect düğmesini tıklayıp ikinci sunucu olarak mevcut birinci sunucuyu göstereceğiz. Yedek veritabanının adını Kaynak2 olarak giriyoruz ve bu veritabanı şu anda sistem üzerinde hazır olmadığı için birinci veritabanında full backup alınmasını ve Kaynak2 olarak restore edilmesini sağlayacağız.

İkinci sunucuyla ilgili ayarları da bitirdikten sonra bu süreci izleyecek bir monitor server tanımlayalım. Bunun için ana penceredeki “Use a monitor server instance” seçeneğini işaretleyip Settings düğmesini tıklıyoruz. Monitor server olarak mevcut sunucuyu göstereceğiz.

Artık SQL Server 2005 üzerinde log shipping işlemini hazırlamış olduk. OK düğmesini tıklayarak gerekli jobları oluşturalım. İşlemi başlattığımız anda Kaynak2 veritabanı salt-okunur modunda oluşturulur ve işlemleri yürütecek joblar yaratılır.

Son olarak şu notu ekleyelim SQL 2005 ve SQL 2000 arasında secondary/primary veya primary/secondary olarak log shipping kurulamaz.