24 Mart 2019 Pazar

VS ile Veritabanları Arasında Tablo Seviyesinde Veri Karşılaştırması ve Senkronizasyonu (Data Comparison)

Visual Studio içerisinde gelen araçlar sadece yazılım geliştiricileri için değil aynı zamanda veritabanı geliştiricileri için de büyük kolaylık sağlamakta. Bu araçlar sayesinde hem veritabanı projesi geliştirebilir hem SQL Server yeteneklerini genişletecek nesneleri üretmek için CLR alt yapısına uygun dller yazabilir hem  de veritabanlarını yapı ve veri bazında karşılaştırıp senkronize edebilirsiniz. 

Daha önceki yazılarımızda Visual Studio ile veritabanı geliştirme ve veritabanlarını yapısal olarak karşılaştırma konularına değinmiştik.

Bu konuyla ilişkili önceki yazılarımıza aşağıdaki linklerden bir göz atabilirsiniz:

Veritabanı Proje Geliştirme Çözümleri - Visual Studio Özellikleri
http://www.abdullahkise.com/2014/03/veritaban-proje-gelistirme-cozumleri.html

VS ile Veritabanları Arasında Yapısal Kıyaslama Yapma ve Değişiklikleri Geri Alma (Schema Comparison + Restore from Snapshot)

Biz bu yazımızda Visual Studio içerisinde gelen Data Comparison aracı ile veritabanlarını tablo seviyesinde veriler bazında nasıl karşılaştırabileceğimize ve değişiklikleri hedefe nasıl yansıtabileceğimize odaklanacağız.

Data Comparison aracı sayesinde mesela test ve production ortamlarınızı tablo seviyesinde kontrol edebilir, farklı satırları senkronize edebilirsiniz. Karşılaştırmanın yapılabilmesi için bir takım şartlar mevcut. Şartların sağlanmadığı nesneler karşılaştırma listesinde görünmez. 

Bu şartlar şöyle:
  • Karşılaştırılan tabloların/viewlerin adları, kolon adları ve tipleri aynı olmalı
  • Karşılaştırma amaçlı kullanılmak üzere benzersizliği sağlayacak Key veya Index tanımlı olmalı
  • Benzersizliği sağlayan Key ve Constraintler aynı olmalı (Primary Key, Unique Index, Unique Contraint)
  • Unique ve Clustered Indexler aynı olmalı
Aracının kullanımı oldukça kolay. Adımlar şöyle:
  1. Kaynak ve hedef belirle
  2. Karşılaştırılacak Table ve Viewleri seç
  3. Seçilen nesneleri veri bazında karşılaştır
  4. Farklı kayıtları, sadece kaynakta olanlar, sadece hedefte olanlar ve her ikisinde olan (özdeş) kayıtları incele
  5. Tüm farklılıkları veya bir kısmını hedefe yansıt
    • Dilerseniz sadece scripti alarak birden fazla hedefe uygulayabilirsiniz

Data Comparison aracının nasıl çalıştığını bir senaryo üzerinden inceleyelim.

Senaryo şöyle:

ChangeableDB isimli bir veritabanımız var ve içerisinde Products isimli bir tablo mevcut. Production ortam olan bu veritabanı için bir de ChangeableDB_PreProd isimde Preproduction ortam oluşturduk. preproduction ortamda bir takım testler yapmaktayız ve başarılı olduğunda production ortama uygulamaktayız. Testlerin başarılı olabilmesi için çalışmaya başlamadan önce productiondaki verilerin tablo seviyesinde veri bazında birebir preproduction ortamda da olmasını istiyoruz.

Data Comparison aracını kullanarak bu senaryo ile nasıl başa çıkabiliriz?

Farklı yöntemlerde uygulanabilir. Biz bu senaryo için Data Comparison aracını kullanmaya odaklandık.

ChangeableDB veritabanında veri bazında bir takım değiklikler yapıyorum. Yeni satırlar ekliyorum. Color kolonunda güncelleme yapıyorum ve mevcut bir satırı siliyorum. Şimdi Data Comparison aracını kullanarak karşılaştırmayı yapalım.

1-Kaynak ve hedef belirle


Visual Stuido içerisinde gelen Data Comparison aracını üst menuden Tools/SQL Server/New Data Comparison.. adımlarıya açabilirsiniz.


Sonra açılan pencereden kaynak ve hedef seçimini yapabilirsiniz. Kaynak olarak ChangeableDB hedef olarak da ChangeableDB_Preprod veritabanını seçiyorum.

Hemen altta karşılaştırma seçeneklerini işaretliyorum. Farklı kayıtlar, sadece kaynakta olanlar ve sadece hedefte olanlar gelsin istiyorum. Özdeş satırların gelmesini istemediğim için Identical Records seçeneğini işaretlemiyorum.


2-Karşılaştırılacak Table ve Viewleri seç


Next butonu ile bir sonraki adıma geçebilirsiniz. Sonraki adımda yukarıda bahsettiğimiz şartlara uyan Table ve Viewler listelenecektir. Bu listeden karşılaştırılmasını istediğiniz nesneleri seçebilirsiniz.


3-Seçilen nesneleri veri bazında karşılaştır


Finish butonuna bastığınızda karşılaştırma başlar ve sonuçlar karşılaştırma seçeneklerinize göre gruplanır.

4-Farklı kayıtları, sadece kaynakta olanlar, sadece hedefte olanlar ve her ikisinde olan (özdeş) kayıtları incele


Sonuçları incelediğimizde Different Records grubuna bakarak kaynaktaki 248 kaydın hedeften farklı olduğunu görebiliyoruz. İkonlara dikkat ederek incelediğinizde ilgili kaydın kaynaktaki ve hedefteki halini görebilirsiniz. 

Sonuçlara bakmaya devam ettiğimizde Only in Soruce grubunda 2 satırın sadece kaynakta yer aldığını, Only in Target grubunda ise 1 satırın sadece hedefte yer aldığını görebilirsiniz.



5-Tüm farklılıkları veya bir kısmını hedefe yansıt. Dilerseniz sadece scripti alarak birden fazla hedefe uygulayabilirsiniz


Kayıtları inceledikten sonra hedefe yansıtılmasını istediklerinizi seçip üstten Update Target butonu basabilir hedefin güncellenmesini sağlayabilirsiniz. Dilerseniz Generate Script butonu ile güncelleme kodlarını görebilir, dilerseniz Script butonu ile güncelleme kodlarını dosya olarak kaydedebilirsiniz.

Senaryomuzda production ortamındaki tüm değişikliklerin preproduction ortama yansıtılmasını istediğimiz için Update Target butonua basıyorum. 

Sonuçları kontrol ettiğinizde veritabanlarının senkronize olduğunu görebilirsiniz.

Data Comparison aracı Tablo seviyesinde veri bazlı karşılaştırma yapma konusunda büyük konfor sağlıyor. Bu konfordan faydalanmadan önce yukarıda bahsettiğimiz gereksinimleri gözden geçirmek ve sağlamak gerekir. Tabi ki her zamanki gibi önce test ortamında çalışılmalı ve istenen tepkiler elde edildiğinde canlı ortamlarda uygulanmalıdır. 

İstediğiniz şey veri değil de yapının karşılaştırılması ise şu yazımıza bir göz atın:

VS ile Veritabanları Arasında Yapısal Kıyaslama Yapma ve Değişiklikleri Geri Alma (Schema Comparison + Restore from Snapshot)

Faydalı olması dileğiyle.

23 Mart 2019 Cumartesi

VS ile Veritabanları Arasında Yapısal Kıyaslama Yapma ve Değişiklikleri Geri Alma (Schema Comparison + Restore from Snapshot)

Veritabanı tasarlama yöntemlerine daha önceki bir yazımızda değinmiştik. Bahsettiğimiz yöntemler arasında Visual Studio üzerinde SQL Server Database Project isimli proje ile çalışmanın farklı bir yeri var. Bu şekilde çalışmak sadece veritabanı tasarlamayı kolaylaştırmıyor aynı zamanda projenin anlık görüntüsünü almayı, yapı ve veri karşılaştırmaları yapabilmeyi ve birden fazla kişi ile aynı tasarımı farklı projeler üzerinden ortaklaşa geliştirebilmeyi sağlıyordu. 

Önceki yazımıza aşağıdaki linkten bir göz atabilirsiniz:

Veritabanı Proje Geliştirme Çözümleri - Visual Studio Özellikleri
http://www.abdullahkise.com/2014/03/veritaban-proje-gelistirme-cozumleri.html

Biz bu yazımızda Visual Studio'nun SQL Server ile ilgili sunduğu nimetlerden Schema Comparison aracına odaklanacağız.

Schema Comparison aracı SQL Server Data Tools üzerinden de erişebilirsiniz. Bu özellik iki nokta arasındaki yapısal farklılıkları gayet şık bir arayüzle bize sunabilmekte. iki nokta diyorum çünkü kaynak ve hedef olarak şunları belirtebilirsiniz:
  • Bağlı veritabanları
  • SQL Server Database Project projeleri
  • Veritabanı Snapshotları
  • Data Tier Application (.dacpac) dosyaları
Schema Comparison aracının kullanımı oldukça kolay. Adımlar şöyle:
  1. Kaynak ve hedef belirle.
  2. Karşılaştır.
  3. Farklılıkları hedefe doğrudan yansıt veya
  4. Farklılıkları yansıtacak scriptleri dışarı al (Bu birden fazla hedefi değiştirmek için idealdir.)
Schame Comparison aracını bir senaryo ile birlikte inceleyelim.

Senaryo şöyle:

ChangeableDB isimli bir veritabanımız var. Bu veritabanında bir takım yapısal değişiklikler yapılmak isteniyor. Çalışma sonunda yapısal farklılıklara bir göz atıp belki değişikliklerin tümünü belki de bir kısmını geri eski haline çevirmek isteyebiliriz.

Schame Comparison aracını da kullanarak bu senaryoyla nasıl başa çıkabiliriz?

Çeşitli yöntemler uygulanabilir. Biz yazımızda şu şekilde ilerleyeceğiz:
  1. Çalışma öncesi veritabanının snapshotını al
  2. Yapısal değişiklikler uygulansın
  3. Schema Comparison aracında Source olarak çalışma öncesi alınan snapshotı seç
  4. Schema Comparison aracında Target olarak değişiklikler uygulanmış veritabanını seç
  5. Kaynak ve hedefi yapısal olarak karşılaştır
  6. Değişiklikleri geri almak için iki yöntem var:
    • Schema Comparison ile tüm yapısal değişiklikleri veya bir kısmını hedefe yani veritabanına uygula
    • Snaphsot kullanarak veritabanını restore et. (veri ve yapı dahil snapshot alınan zamana döner)

1- Çalışma öncesi veritabanının snapshotını al


Veritabanı snapshotını aşağıdaki script ile alabiliyoruz. Snapshotlar sayesinde veritabanının o anki görüntüsünü sadece okuma amaçlı alabiliriz. Snapshotlar bazen çoğu zaman kullanışlı olur fakat çok fazla değişiklik yapıldığında görüntünün korunması için işlem sayısında ciddi artış olmaktadır.

Veritabanlarının anlık görüntüsünü aşağıdaki script ile alabilirsiniz:

CREATE DATABASE ChangeableDB_20190323 ON
(
       NAME = ChangeableDB,
       FILENAME = 'G:\DBSnaps\ChangeableDB_20190323.ss'
)
AS SNAPSHOT OF ChangeableDB ;
GO


2- Yapısal değişiklikler uygulansın


Örneğimizdeki ChangeableDB üzerinde bir takım değişiklikler yapalım.Veritabanımızda Products  isimli bir tablo var. Örneğimizde tablonun veri tiplerini değiştiriyorum, kolon silip primary key ekliyorum.

3- Schema Comparison aracında Source olarak çalışma öncesi alınan snapshotı seç


Schema Comparison aracına Visual Studio'yu açıp yukarıdaki menuden Tools/SQL Server /New Schema Comparison.. ile ulaşabilirsiniz. Visual Stuido bir kaç versiyondur bu aracı içermekte. Ben örneğimizde Visual Studio 2017 kullanıyorum.


Açılan pencerede Source ve Target belirtebilirsiniz. Burada proje, veritabanı ve dacpac uzantılı dosyaları kaynak veya hedef olarak belirtebilirsiniz. Biz Database seçeneğini seçelim ve kaynak olarak çalışma öncesi oluşturduğumuz ChangeableDB_20190323 isimli snapshotı gösterelim.


4- Schema Comparison aracında Target olarak değişikliklerin uygulandığı veritabanını seç


Benzer adımları atarak değişikliklerin uygulandığı hali yani ChangeableDB veritabanını hedef olarak gösterelim.


5- Kaynak ve hedefi yapısal olarak karşılaştır


Kaynak ve hedefi belirtikten sonra Compare butonuna basarak yapısal karşılaştırmayı başlatabilirsiniz. Bir süre sonra iki nokta arasındaki tüm değişiklikler listelenecektir. Listeleri açıp maddeler arasında gezerek değişiklikler hakkında detaylı bilgi alabilirsiniz. Değişikliklerin kaynak ve hedefte nasıl göründüğüne scriptlerin olduğu en attaki pencereden bakabilirsiniz.


6-Değişiklikleri geri almak için Schema Comparison ile tüm yapısal değişiklikleri veya bir kısmını hedefe yani veritabanına uygula


Menude bulunan Update butonu ile kaynaktaki yapıyı hedefe uygulayabilirsiniz. Yanında Script butonu ile aksiyonların scriptini alıp üzerinde değişiklikler yapabilirsiniz. Bu şekilde birden fazla hedefe uygulama imkanı olur. Hemen bir yandaki Optioms butonu ile aksiyonların seçeneklerini yönetebilirsiniz.


7- Değişiklikleri geri almak için snaphsotı kullanarak veritabanını restore et


Eğer veritabanını tümüyle snapshot alınan zamana geri çevirmek isterseniz snapshottan restore etme yöntemini kullanabilirsiniz. Yalnız bu yöntemin hem veri hem de yapı anlamında o ana dönülmesini sağladığını unutmayalım. Veri kaybı yaşamamak için dikkatli kullanmakta fayda var.

Snapshottan restore işlemi şu şekilde yapılabilir:

use master
GO

RESTORE DATABASE ChangeableDB
FROM DATABASE_SNAPSHOT=N'ChangeableDB_20190323'

Snapshotları kaldırmak için şu komutu kullanabilirsiniz:

use master
GO

DROP DATABASE [ChangeableDB_20190323]

Schema Comparison, farklılıkları takip etmek ve değişiklikleri kısmen veya tamamen hedefe uygulayabilmek için geliştirilmiş güzel bir araç. Bir göz atmakta fayda var. Yalnız bu gibi çalışmaları önce test ortamlarında yapmayı ve istediğiniz tepkileri elde ettiğinizde canlı ortamlarda uygulamayı unutmamak gerekir.

Faydalı olması dileğiyle...

16 Mart 2019 Cumartesi

SQL Server 2017 Yüksek Erişilebilirlik Çözümleri - 3 (High Availability Solutions)

Serinin bir önceki yazısında AlwaysOn Failover Cluster ve AlwaysOn Availability Group özelliklerine odaklanmıştık. 

Önceki yazıya şu linkten ulaşabilirsiniz:

SQL Server 2017 ile birlikte kullanılabiliecek Yüksek Erişebilirlik çözümleri özetle şöyle:


SQL Server 2017 editionları ve desteklenen özellikleri aşağıdaki linkten inceleyebilirsiniz:

HA çözümleri birlikte kullanılarak farklı topolojiler elde edilebilir. Biz özetle temel topolojilere ve çözümlerin avantajlı-dezavantajlı yönlerine odaklanmaya kaldığımız yerden devam edelim.

Database Mirroring


Uzun zamandır var olan bir çözümdür ilerleyen versiyonlarda görmeyebiliriz. Her bir veritabanı için ayrıca uygulanır. Aktif olan Principal sunuculardan pasif olan Mirror sunucuya Senkron ve asenkron veri aktarımı yapabilir. Eğer Witness sunucu eklerseniz otomatik failoverı da destekler. Mirror sunuculardaki veritabanları doğrudan okunamaz. Ancak veritabanı snapshotları alınarak okuma yapılabilir.

Aynı versiyon ve edition olmasına dikkat etmelisiniz. Veritabanı adını sağ tıklayarak ulaştığınız Task/Mirror menüsüyle veya scriptler yardımıyla çözümü ilgili veritabanına uygulayabilirsiniz. Her edition Database Mirroring özelliğini farklı şekilde destekler. Witness sunucudaki versiyon aynı olmalıdır fakat edition farklı olabilir. Mesela Express edition kullanabilirsiniz. Witness sunucu iki sunucuyu takip edip yük devrinin otomatik yapılmasını sağlar. Witness olmadan da Database Mirroring kurulabilir.

Temel topolojisi:

Avantajlar:
  • Senkron ve asenkron çalışabilir.
  • Full Safety modeda senkron çalışır ve yük devrinde (failover) veri kaybı olmaz.
  • Witness sunucu topolojiye dahil edilmişse saniyeler içerisinde otomatik yük devrinde (failover) yapılabilir.
  • Mirror sunucularda veritabanının kopyaları (replica) olur ve bu kopyalar snapshotlar yardımıyla okunabilir.
Dezavantajlar:
  • Otomatik yük devri (failover) yapılabilmesi için ek Witness sunucuya ihtiyaç duyulur.
  • Tek pasif node aktarılabilir.
  • Veritabanları tek tek ayarlanır. Uygulamalar birden fazla veritabanı kullanıyorsa failover sırasında veritabanlarının bir kısmı diğer tarafa geçmezse sorun oluşturur.
  • Pasif nodelardaki veritabanları okunamaz. Sadece snapshot alınarak okunabilir.
  • Veritabanlarının diğer nodelar üzerinde kopyası oluştuğu için daha fazla disk alanına ihtiyaç duyulur.
  • Failover sonrası uygulama tarafında Connection Stringlerin değiştirilmesi gerekir. Bağlantı cümesine "Failover Partner" ibaresi eklenmelidir.
  • Server seviyesinde tanımlanan nesnelerin (job, login vs.) diğer nodelara da tanımlanması gerekir.


Basic Availability Groups


Database Mirroring özelliğinin yerini alacak yeni bir özellik. Sadece Standart editionda 2 sunucu 1 veritabanı için kurulabilir. AlwaysOn Availability Group özelliğine benzer şekilde kurulsa da bir çok yetenekten mahrumdur. Mesela pasif sunuculardaki veritabanları okuma ve yedeklemede kullanılamaz, page bozukluklarını düzeltilmez. Enterprisea geçerken upgrade ile geçmek mümkün değildir. Availability Groupun yeniden kurulması gerekir. Bu hali daha çok Mirroringi andırır.

Windows Failover Cluster üzerinde kurulur ve Enterprisedaki AlwaysOn Availability Group ile aynı şekilde uygulanır. 

Temel topolojisi:


Avantajlar:
  • Database Mirroringin yeni hali (yakında yerini alacak) ve AlwaysOn Availability Groupun kısıtlı halidir.
  • Standart editionda 2 sunucu 1 veritabanı için oluşturulabilir.
  • Senkron-asenkron çalışabilir.
  • Otomatik yük devri (failover) yapılabilir.
Dezavantajlar:
  • Yalnızca 2 sunucu arasında 1 db için oluşturulabilir.
  • AlwasyOn Availability Groupa geçişte Basic Availability Groupun kaldırılması gerekir. AO AG kurulumu sıfırdan yapılır.
  • Pasif nodeki veritabanı okuma için kullanılamaz, backup alınamaz.
  • Page bozuklukları pasif nodea gönderilirken kontrol edilmez.
  • Sadece SQL Server 2016 ve sonrası Standart editionda kullanılabilir.
  • Server seviyesinde tanımlanan nesneler (job, login vs.) diğer nodelarda da tanımlanması gerekir.

Buraya kadar değindiğimiz özellikler otomatik yük devrini (failover) destekleyen tam manasıyla Yüksek Erişilebilirlik çözümleri nitelemesini hak eden özelliklerdi. Şimdi ise otomatik yük devrini desteklemeyen sadece kopya veritabanı oluşturmak için kullanılan kısmen Yüksek Erişilebilirlik çözümlerinden sayılan diğer özellikleri inceleyelim. Bu özelliklerin topolojilerini çizmeden direk avantaj ve dezavantajlarına değineceğim.

Bu arda serimizde Replication özelliğini odağımızın dışında tutuyorum. Çünkü Replication tablo seviyesinde yayıncı, dağıtıcı ve abone rollerinde gazete dağıtım mantığında veri kopyalamak için kullanılır. Yüksek erişilebilirlik çözümü sayılmaz.

Clusterless Availability Group


Hem Enterprise hem Standart editionda destekleniyor. Windows Failover Cluster kurulumuna ihtiyaç olmuyor. Ancak bu bir zayıflığı da beraberinde getiriyor. sadece Windows Server 2016 ve SQL Server 2017 versiyonlarında geçerli bu özellikte bir Yüksek Erişebilirlik Çözümünden beklenen pek az şey mevcut. Bu haliyle Log Shippingi andırıyor diyebilirim. Clusterless Availability Group özelliğinin amacı kopya veritabanları oluşturmaktır. Read-Scale Availability Group olarak da anılır.

Avantajlar:
  • Windows Failover Cluster kurulmaz diğer yönleriyle Availability Group özelliklerine benzer şekilde yönetilir.
  • Veritabanı kopyası oluşturmak için kullanılır. Kopyalar okuma ve yedekleme için kullanılabilir.
  • Senkron-asenkron veri aktarımı yapılabilir.
Dezavantajlar:
  • Windows Failover Cluster üzerine kurulmamıştır. Yüksek erişilebilirlik için gerekli mekanizma mevcut değildir.
  • Otomatik yük devri (failover) olmaz
  • Page bozuklukları pasif nodea gönderilirken kontrol edilmez.
  • Minimum Windows Server 2016, SQL Server 2017 gereklidir.
  • Server seviyesinde tanımlanan nesneler (job, login vs.) diğer nodelarda da tanımlanması gerekir.

Log Shipping


Uzun zamandır var olan bir çözümdür. Temelde Backup/Restore ile diğer sunucularda kopya veritabanı oluşturur. En basit ve ucuz yöntemdir diyebiliriz. Ancak zamanlanmış backupları takip etmek gerekir. Bu yöntemle kopya veritabanının belli bir süre geriden gelmesini sağlayabilirsiniz.

Avantajlar:
  • Kurulumu basittir. Temel olarak Backup/restore işlemi otomatik yapılır.
  • Pasif nodelarda veritabanının kopyaları oluşur.
  • Pasif nodeların ne kadar geriden geleceği ayarlanabilir.
  • Farklı edition ve üst versionlar arasında kurulabilir.
Dezavantajlar:
  • Otomatik yük devri (failover) desteklemez. Failover dakikalar hatta saatler alabilir.
  • Dakikalar seviyesinde veri kaybı olur.
  • Veritabanları tek tek ayarlanır.
  • Backup/restore işlemleri takip edilmelidir.
  • Log shipping aktifken pasif nodelarda veritabanları restoring modeda olduğu için okuma yapılamaz.
  • Diğer nodelar üzerinde veritabanlarının kopyası olduğu için daha fazla disk alanına ihtiyaç duyulur.
  • Failover sonrası uygulama tarafında connection stringlerin değiştirilmesi gerekir.
  • Server seviyesinde tanımlanan nesneler (job, login vs.) diğer nodelarda da tanımlanması gerekir.

AlwaysOn Availability Groups yaygınlaşmadan önce Database Mirroring yaygın şekilde kullanılmaktaydı. Log Shipping ise yıllar önce tercih ediliyordu. Şimdilerde ise Yüksek Erişilebilirlik denince akla ilk gelen AlwaysOn Availability Groups olmaktadır. Belki özetlediğimiz çözümlerden bazıları sizin için diğerlerinden daha uygundur. Belki çözümleri bir arada kullanmak istersiniz. Seçim sizin.

Sistemi ayakta tutmak büyük uğraş ister. Maliyetler, eldeki kaynaklar ve özetlediğimiz çözümler sayesinde sisteminizi 7/24 ayakta tutabilirsiniz. Biz temel topolojilere odaklandık. Sizler bu çözümleri bir arada kullanarak daha büyük topolojiler elde edebilirsiniz.

SQL Server 2017 Yüksek Erişilebilirlik Çözümleri - 2 (High Availability Solutions)

Serinin bir önceki yazısında da belirttiğimiz gibi; ihtiyaç duyduğumuz hizmetlerin her an erişilebilir olması son derece önemlidir. Özellikle kurumsal firmalar müşteri memnuniyeti, kurumsal imaj, rekabet ve karlılık gibi daha bir çok nedenden dolayı hızlı ve sürekli erişebilir olmaktan vazgeçemezler.

Sürekli erişilebilir olmak sizin için önemliyse ve olası bir felakette hizmet kesintisini saniyeler, hatta mili saniyeler seviyesinde tutmak isterseniz; yüksek erişilebilirlik - HA çözümlerine odaklanmanız gerekir.

SQL Server 2017 ile birlikte felaket öncesi alınabilecek önlemler (Yüksek Erişilebilirlik Çözümleri) şunlardır:

  1. AlwaysOn Failover Cluster (Uzun zamandır var. Bazı versiyonlarda geliştirildi.)
  2. AlwasyOn Availabilty Groups (SQL Server 2012 ile birlikte geldi ve her versiyonda geliştirildi.)
  3. Database Mirroring (Uzun zamandır var. Yeni versiyonlarda görmeyebiliriz.)
  4. Basic Availability Groups (Mirroringin yerini alıyor. Standart editionda 2 Server 1 DB için kurulabilir.)
  5. Clusterless Availability Group (Yüksek erişilebilirlik çözümü sayılmaz. DB kopyası oluşturur.)
  6. Log Shipping (Uzun zamandır var. Backup-restore ile DB kopyası oluşturulur.)
Serinin bir önceki yazısına şu linkten ulaşabilirsiniz:

Bu yazımızda SQL Server 2017 ile birlikte kullanılabilen Yüksek Erişilebilirlik - HA çözümlerini karşılaştıralım ve temel topolojilere bir göz atalım.

SQL Server 2017 Enterprise ve Standart Editionda desteklenme durumu şöyle demiştik:


SQL Server 2017 editionları ve desteklenen özellikleri aşağıdaki linkten inceleyebilirsiniz:

HA çözümleri birlikte kullanılarak farklı topolojiler elde edilebilir. Biz özetle temel topolojilere ve çözümlerin avantajlı-dezavantajlı yönlerine odaklanacağız.

AlwaysOn Failover Cluster


Uzun zamandır var olan bir teknolojidir. Bazı versiyonlarda bir takım geliştirmeler yapıldı ancak temel mantık aynı. Öncelikle sunucularda arasında Windows Failover Cluster kurulur. Hemen ardından bir sunucuya SQL Server kurulumu yapılır ve diğer sunuculara da SQL Server kurulumları Cluster olarak eklenerek yapılır.

Bu çözüm servis seviyesine odaklanır. Bir aktif sunucu olur ve bu sunucuda yazma okuma yapılabilir. Bir felaket anında pasif sunucular elle veya otomatik olarak aktif hale gelebilir. pasif sunucular aktif olana kadar atıldır. Çapraz şekilde aktif-aktif olacak bir tasarım yapılabilir. Ancak pasif kalan makine üzerinden aynı veritabanı yazma/okuma amaçlı kullanılamaz. 

Sunucular ortak diske baktığı için disk bazlı bir felaket olduğunda bu çözüm işe yaramaz.

Temel topolojisi:
Avantajlar:
  • Standart editionda 2 makine desteklenir.
  • Windows Cluster alt yapısı kullanılır ve Clientlar Public IP üzerinden eriştiği için yük devri (failover) sonrası uygulama tarafında değişiklik gerekmez.
  • Saniyeler/dakikalar (20 sn + Recovery süresi kadar) içerisinde diğer makineye otomatik yük devri (failover) yapılabilir.
Dezavantajlar:
  • SQL Server 2012 sonrası kullanımı azaldı. Yerine AlwaysOn Availability Group trend oldu.
  • Pasif nodelar üzerinden okuma yapılamaz. Pasif nodelar tamamen atıl kalır.
  • Pasif nodelarda veritabanı kopyası (replica) yoktur.
  • Nodelar (sunucular) ortak disk kullandığı için disk hatalarına karşı veri korunmaz. Veritabanı değil servis seviyesinde erişilebilirlik sağlar.


AlwasyOn Availabilty Groups


SQL Server 2012 ile birlikte geldi. Her versiyonda geliştirildi ve yeni özellikler eklendi. Bir çok açıdan güçlü ve başarılı bir çözüm. Eskiden beri kullanılan Database Mirroring ve Log Shipping'in iyi tarafları birleştirilmiş ve Windows Failover Cluster alt yapısı üzerine inşa edilmiş bir çözüm. Database Mirroring gibi senkron/asenkron veri aktarımı yapılabilir. Felaket anında bir kaç saniyede görevi diğer sunucuya otomatik olarak devredebilir. Log Shipping gibi birden fazla sunucu/veritabanı için kurulabilir. Hatta pasif olan nodelardaki veritabanları özel bir çaba gerektirmeden veri okuma ve backup alma amaçlı kullanılabilir.

Primary node üzerinden yazma okuma taleplerinize cevap bulabilirsiniz. Secondary nodeları da raporlama ve yedekleme amaçlı kullanabilirsiniz. Bu şekilde 8 nodeu birden fazla veritabanı için yüksek erişilebilirlik kapsamına alabilirsiniz.

Öncelikle Windows Failover Cluster kurmanı gerekir. Sonra sunuculara ayrı ayrı SQL Server  Enterprise kurulumları normal şekilde yapılır. Hemen ardından SQL Server Database Engine servislerinden AlwaysOn Availability Group aktif edilir ve Availability Grouplar arayüzlerden veya scriptler yardımıyla oluşturulur.

Temel topolojisi:
Avantajlar:
  • Senkron ve asenkron çalışabilir. 10 saniyeden kısa sürede otomatik yük devri (failover) yapılabilir.
  • Senkron olduğunda veri kaybı sıfırdır.
  • Pasif nodelarda veritabanı kopyaları (replica) oluşur.
  • Primary nodea yazma/okuma diğer nodelarda sadece okuma yapılabilir. Pasif nodelar raporlama ve backup amaçlı kullanılabilir.
  • Birden fazla veritabanı tek bir availability group altınta toplanabilir. Felaket anında tüm veritabanları için yük devri (failover) yapılır.
  • Windows Failover Cluster alt yapısı kullanılır ve istemciler listener adı ile erişim sağladığı için failover sonrası uygulama tarafında değişiklik gerekmez.
  • Pagelerde oluşan tutarsızlıklar pasif nodelara düzeltilerek aktarılır.
Dezavantajlar:
  • Enterprise edition gereklidir.
  • Veritabanlarının diğer nodelar üzerinde kopyası (replica) olduğu için daha fazla disk alanına ihtiyaç duyulur.
  • Server seviyesinde tanımlanan nesneler (job, login vs.) diğer nodelarda da tanımlanması gerekir.
  • Secondary sunucular primary sunucu kadar güçlü olmazsa senkron modda ciddi yavaşlıklar oluşur.
Serinin bu yazısında bir biri ile karıştırılan iki farklı çözümü ele aldık. Diğer çözümlere sonraki yazımızda odaklanacağız.

YTÜ Teknokent Etkinliğinden Görüntüler ve Paylaşımlar (SQL Day)

Geçtiğimiz günlerde (28 Şubat 2019) YTÜ Teknokent'de SQL Day isimli bir etkinlik düzenledik. Etkinlikde çok kıymetli konuşmacı arkadaşlarımın birbirinden değerli paylaşımları oldu. 

Benim konuşmacı olduğum oturumda SQL Server 2016 ile başlayan SQL Server 2017'de daha da gelişen Machine Learning in Database konusuna odaklandık. Mavcut alışkanlıkları çok fazla değiştirmeden, veriyi veritabanı dışına çıkarmak zorunda kalmadan R ve Python dillerini kullanarak nasıl analitik çalışmalar yapılabileceğini ve hatta nasıl makine öğrenimi yapılabileceğini konuştuk.

Dikkatle takip eden, sorular soran ve cep telefonları ile video kaydı alan arkadaşlarıma ilgilerinden dolayı teşekkür ediyorum. 

Sunuma ve demo sırasında kullandığımız kodlara şu linkten erişebilirsiniz:


YTÜ görevlilerine ve o gün bizi ilgiyle dinleyen tüm değerli katılımcılarımıza arkadaşlarım adına ayrı ayrı teşekkür ediyorum.

Etkinlik sonunda aldığımız güzel geri bildirimler neticesinde bu etkinliğin bir benzerini önümüzdeki günlerde tekrar planlamayı düşünüyoruz.

Daha önce paylaştığımız duyuruya şu linkten ulaşabilirsiniz:

Etkinlikteki sunuma ve demoda kullandığımız kodlara şu linkten ulaşabilirsiniz:

Etkinlikten görüntüler:

Sonraki etkinliklerde görüşmek üzere ...

15 Mart 2019 Cuma

SQL Server 2017 Yüksek Erişilebilirlik Çözümleri - 1 (High Availability Solutions)

Hizmet aldığımız veya verdiğimiz firmaların ihtiyaç duyulduğu her an erişilebilir olması son derece önemlidir. Özellikle kurumsal firmalar müşteri memnuniyeti, kurumsal imaj, rekabet ve karlılık gibi daha bir çok nedenden dolayı hızlı ve sürekli erişebilir olmaktan vazgeçemezler.

Bazı kuruluşlar için hizmet kesintilerinin bedeli çok ağır olabilir. Gartner'ın yapmış olduğu bir araştırmaya göre büyük ölçekli bir kuruluşun 1 saatlik kesintisinin bedeli 42 bin dolar civarındadır. Geçtiğimiz senelerde InformationWeek dergisinde yayınlanan bir analize göre IT kesintilerinin bedeli 26,5 milyar dolara çıkmıştır.

Çoğu kuruluşun hayatı tümüyle kesintisiz devam etmesi gereken hizmetlere bağlıdır. Bu hizmetlerin devamlılığı için fiyat-performans analizleri iyi yapılmış güvenilir sistemler kurmak gerekir.

Sistemlerin durduğu, hizmetin devam edemediği anı felaket anı olarak kabul edersek; felaketten sonra sistemi tekrar işler hale getirmek için yapılacak işlemlere Felaket Kurtarma - Disaster Recovery (DR), felaket olmadan önce alınacak önlemlere de Yüksek Erişilebilirlik - High Availability (HA) deriz.

Felaket olup sistem tekrar işler hale gelene kadar iki tür kayıp yaşanır; bunların ilki hasar gören verinizle veya verinizin yedeklenmemiş kısmıyla ilgilidir. ikincisi ise sistemi tekrar işler hale getirene kadar geçen sürede yakalayamadığınız verilerle ilgilidir.  Her ikisinin de maliyeti maddi ve manevi açılardan çok ciddi seviyelere ulaşabilir.

DR adına yapılacak işlemler temelde sağlıklı şekilde alınmış backuplardan ve snapshotlardan dönmekle ilgilidir.  HA adına alınan önlemler ise temelde birden fazla server için cluster yapısı kurmak ve kopya-replica veritabanları oluşturmakla ilgilidir. 

HA felsefesinde server yönetimi her ne kadar görece daha pahalı olsa da, DR felsefesinde server yönetiminde karşılaşılan kayıplar çok daha pahalıya mâl olabilmektedir.

Sistemin ayakta olduğu süreye uptime, kesinti olup cevap veremediği süreye downtime denir. Sistemin hizmet vermeye başladığı andan itibaren felaket olup cevap veremediği ve tekrar hizmet vermeye başladığı ana kadar geçen toplam süreye total elapsed time adı verilir. Bu değişkenler üzerinden sistemin erişilebilirlik yüzdesi hesaplanır.  Özellikle bulut hizmeti veren firmalar sistemleri ne kadar ayakta tutabildiklerini bu yüzdelerle ifade ederler.

Bir örnek üzerinden açıklayalım:

Haftalık olarak bakım, onarım ve yükseltme adına bir takım çalışmalar yaptığımızı düşünelim. Bu çalışmalar için serverı en müsait zamanlarda toplamda haftada 2 saat kadar erişime kapattığımızı düşünelim. 

Haftada 2 saat kesinti, kabaca ayda 8 saat kesinti yapar. Bu yılda 96 saat demektir.
Tüm yılda 24*365 yani 8760 saat bulunsun.

Erişilebilirlik Yüzdesi = (( toplam geçen süre - toplam kesinti süresi ) / toplam geçen süre ) * 100
EY = ((8760 - 96)/8760)*100
EY= 98.9

Bu durumda böyle bir sistem yılda %98.9'luk uptime ile hizmet vermektedir deriz.

Haftada 2 saatlik kesinti bazı hizmetler için makul görünebilir. Ancak bazı hizmetler için asla kabul edilemez. Dahası gerçek manada ölümcül sonuçlar doğurabilir.

Rekabette avantajı elden bırakmak istemeyen firmalar için ise yüksek performans ve yüksek erişilebilirlik zorunluluktur. Amazon'un yapmış olduğu bir açıklamaya göre 100 ms gecikmeleri satışarını %1 düşürmektedir. Başka bir açıklamalarına göre her saniyenin değeri 1.6 milyar dolar civarındadır.

Sistemlerin %100 uptimea sahip olması pratikte pek mümkün değildir. Bakım, onarım ve yükseltme her sistemde bir şekilde olur. Kesintiler insan algısının altına düşse de mevcuttur. Bu sebeple sistemlerin uptime yüzdeleri %99.999 biçiminde olur ve kaç dokuz olduğuna göre isimlendirilir.


Mesela; iki dokuzluk yani %99.0'lık uptimea sahip bir sistem yılda 3.65 gün haftada 1.68 saat downtimea sahiptir. Beş dokuzluk yani %99.999'luk uptimea sahip bir sistem ise yılda sadece 5.26 dakika, haftada ise 6.06 saniye downtime sahiptir. Sistemler genelde üç dokuzluk yani %99.9'luk uptimea sahip olur. Bu da yılda 8.76 saat, ayda 43.8 dakika, haftada 10.1 dakika downtime demektir.

Sürekli erişilebilir olmak sizin için önemliyse ve olası bir felakette hizmet kesintisini saniyeler, hatta mili saniyeler seviyesinde tutmak isterseniz; yüksek erişilebilirlik - HA çözümlerine odaklanmanız gerekir.

SQL Server 2017 ile birlikte felaket öncesi alınabilecek önlemler şunlardır:
  1. AlwaysOn Failover Cluster (Uzun zamandır var. Bazı versiyonlarda geliştirildi.)
  2. AlwasyOn Availabilty Groups (SQL Server 2012 ile birlikte geldi ve her versiyonda geliştirildi.)
  3. Database Mirroring (Uzun zamandır var. Yeni versiyonlarda görmeyebiliriz.)
  4. Basic Availability Groups (Mirroringin yerini alıyor. Standart editionda 2 Server 1 DB için kurulabilir.)
  5. Clusterless Availability Group (Yüksek erişilebilirlik çözümü sayılmaz. DB kopyası oluşturur.)
  6. Log Shipping (Uzun zamandır var. Backup-restore ile DB kopyası oluşturulur.)
  7. Replication (Yüksek erişilebilirlik çözümü sayılmaz. Tablo seviyesinde kopya oluşturulur)

Replication tablo seviyesinde yayıncı, dağıtıcı ve abone rollerinde gazete dağıtım mantığında veri kopyalamak için kullanılır. Yüksek erişilebilirlik çözümü sayılmaz. Biz de bu sebeple Replicationı serimizin odağı dışında tutuyoruz.

SQL Server 2017 Enterprise ve Standart Editionda desteklenme durumu şöyle:


Serinin devamında bu çözümlerin hangi editionlarda ne şekilde desteklendiğine, temel topolojilere ve çözümlerin avantajlı-dezavantajlı yönlerine odaklanacağız.

10 Mart 2019 Pazar

Gebze Teknik Üniveritesi Etkinliğinden Görüntüler (AppMath)

Geçtiğimiz günlerde (21 Şubat 2019 Perşembe) Gebze Teknik Üniversitesi'nde keyifli bir etkinlik düzenledik. Veri Bilimi hakkında konuşmak üzere matematikçilerle buluştuğumuz bu etkinliği düzenleyen ve etkinliğe katılım sağlayan tüm arkadaşlarıma, aynı oturumu paylaştığımız Ercan Balcı'ya teşekkür ediyorum.

Daha önce paylaştığımız duyuru:

Oturumdan bir kaç sahne: