3 Eylül 2019 Salı

Staj Okulu Etkinliklerinde (2019) Büyük Veri ve Makine Öğrenimi Başlıklarına Odaklandık

Geçtiğimiz ay (1 Temmuz 2019) İstanbul Medeniyet Üniversitesi'nde düzenlenen Staj Okulu etkinliklerinde üniversiteli arkadaşlarla bir araya geldik. Etkinlikte Veri Yönetiminin evrimi, Büyük Veri ve Makine Öğrenimi başlıklarına odaklandık.

Geçmişten bu güne veri yönetimi metot ve teknolojilerinde ne gibi gelişmeler oldu. Gelecekte ne gibi yaklaşım ve teknolojiler bizi bekliyor. Büyük Veri, Veri Madenciliği, Yapay Zeka, Makine Öğrenimi, Derin Öğrenme nedir? Hayatımızı nasıl etkiler? ve en önemlisi nasıl yapılır? konusuna değindik.

Konuyu teorik olarak ele almakla birlikte Microsoft Azure Machine Learning ile nasıl makine öğrenimi yapılır, Microsoft AI platformu nasıl kullanılır ve Power BI üzerinde bu bilgiler nasıl raporlanır şeklinde pratiği dönük çalışmalar da yapmış olduk.

Katılımcı arkadaşların Staj Okulu bünyesinde hem stajlarını yapabilmeleri hem de bir birinden değerli profesyonellerden güncel teknik ve teknolojileri dinleyebilmeleri çok kıymetli.

Staj Okulu'nu her yıl düzenlediği bu verimli etkinlikten dolayı kutluyorum. Sağladığı imkanlardan dolayı İstanbul Medeniyet Üniversitesi'ne de teşekkür ediyoruz.




4 Ağustos 2019 Pazar

Yeni Dönemde de Data Platforma Alanında MVP Ödülüne Layık Görüldük (2019-2020)

Dünya çapında saygınlığı olan MVP (Most Valuable Professional) ödülüne 2019-2020 döneminde de layık görülmek çok sevindirici.

Bu ödül Microsoft tarafından topluluk lideri olarak tanımlanan dünya çapında bir kaç bin kişiye çeşitli alanlardaki profesyonel hayata katkıları neticesinde verilmektedir. Biz de dört yıldır Data Platform alanında bu ödüle layık görülmekteyiz.

Etkinlikler, makaleler, videolar, seminerler, öğrenciler-girişimciler-profesyoneller için mentörlük çalışmaları ve e-kitap gibi çeşitli kanallar üzerinden yaptığım gönüllü paylaşımların profesyonel hayata değer katmış olması sevindirici.

Kendi şirketimi kurduğum ve yoğun günler geçirdiğim bu dönemde motive edici bir haber oldu.

Dilerseniz siz de, bir çok Yapay Zeka Mühendisi, Veri Mühendisi, Veri Bilimcisi, İş Zekası Uzmanı, Veritabanı Yöneticisi ve Veri Analisti gibi veri teknolojilerine meraklı iseniz, kendinizi geliştiriyor veya veri teknolojileri konusunda uzmansanız, fikir alışverişinde bulunmak üzere benimle iletişime geçebilirsiniz.

İlginiz, takibiniz ve takdiriniz için teşekkürler...

http://www.abdullahkise.com/
http://www.youtube.com/c/abdullahkise
http://twitter.com/AbdullahKise
http://linkedin.com/in/abdullahkise
abdullahkise@hotmail.com

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:

27 Şubat 2019 Çarşamba

Yıldız Teknik Üniversite Teknopark'ta Etkinlikteyiz - 28 Şubat 2019

MSHOWTO topluluğunun organize ettiği etkinlik 28 Şubat 2019 Perşembe günü YTÜ Teknopark'ta gerçekleşecek olan SQL DAY etkinliğine davetlisiniz.

Etkinlikte Abdullah Kise (bendeniz), Mesut Güneş, Çağlar Özenç ve Baki Abacı konuşmacı olarak yer alacak.

Oturumumuzda SQL Server 2017 ile birlikte gelen "Machine Learning In Database" özelliğine odaklanacağız. 

Microsoft Machine Learning in-Database
  • Makine Öğrenimi Nedir? Problem Tipleri Nelerdir?
  • ML In Database Nedir ve Nasıl Aktif Edilir?
  • SQL Server içerisinde R ve Python Kodları Nasıl Kullanılır?
  • SQL Server içerisinde Makine Öğrenimi Modeli Nasıl Oluşturulur ve Nasıl Tahminleme Yapılır?
Etkinlikte görüşmek üzere,

Kayıt olmak için:
https://www.yildizteknopark.com.tr/tr/formlar/kapsl-57-mshowto-sql-day-semineri-129.html


Kayıt olmak için:
https://www.yildizteknopark.com.tr/tr/formlar/kapsl-57-mshowto-sql-day-semineri-129.html

15 Şubat 2019 Cuma

Gebze Teknik Üniveritesi'nde Veri Bilimi Hakkında Konuşmak Üzere Meraklı Matematikçilerle Buluşuyoruz (AppMath)

Önümüzdeki hafta 21 Şubat 2019 Perşembe günü Gebze Teknik Üniversitesi'nde Veri Bilimi hakkında konuşmak üzere matematikçilerle buluşuyoruz. 

IEEE GTÜ Öğrenci kulübü Matematik Komitesi, Applied Matematics isimli bir program başlatmış. Benimle iletişme geçen arkadaşlarım, programın amacının matematik bölümünden mezun olup farklı alanlarda kariyer yapmış ve kendisinden söz ettiren isimleri ağırlamak olduğunu ifade ettiler. Bizi de davet edilmeye layık görmeleri ne hoş.

Veri ve verimlilik adına, en değerli teknik ve teknolojileri kullanarak çeşitli başlıklarda ürün ve hizmet sunmayı hedeflediğimiz Devcosci Bilişim, Danışmanlık ve Eğitim şirketimizi kurduğumuz şu günler yoğun ve hareketli geçiyor. Ne kadar yoğun olsak da genç matematikçi arkadaşlardan gelen bu daveti temel prensiplerimiz gereği geri çeviremedik.

Nazik davetleri için teşekkür ediyorum. Meslektaşlarımla bir arada olmak, onlara kariyer planlarında  takip edebilecekleri bir çizgi sunabilmek beni mutlu eder. Faydalı olabilirsek ne mutlu.

Birbirinden değerli davetlilerin olduğu bu günde oturumumuz 13:00-14:30 olarak planlanmış görünüyor. Veri Bilimi ve bu alandaki kariyer fırsatları hakkında konuşacağımız etkinlikte buluşmak üzere.



27 Ocak 2019 Pazar

Veritabanı Yöneticisinin Rutini - Aylık (DBA's Routine - Monthly)

Bir önceki yazımızda DBA'in haftalık görevlerinin neler olabileceğine odaklandık. Daha önceki yazımızda ise günlük görevlerinin neler olabileceğine odaklanmıştık.

Önceki yazılarımıza şu linklerden ulaşabilirsiniz:

Veritabanı Yöneticisinin Rutini - Haftalık (DBA's Routine - Weekly)

Veritabanı Yöneticisinin Rutini - Günlük (DBA's Routine - Daily)

Daha önce belirttiğimiz şu ibare bu yazının odağını oluşturmaktadır: 

"DBA'in günlük görevleri daha çok üretilen istatistikleri incelemekten, ani ve kısa süreli müdahalelerde bulunmaktan ibarettir. Haftalık ve aylık görevleri ise bu bilgiler ışığı altında bakım ve iyileştirmeler yapmaktır."

Bir DBA'in aylık sorumlukları daha çok uzun süreli toplanan istatistiklere ya da değişikliklere bakılarak yapılan aksiyonları içerir. Bunların neler olduğuna bir göz atalım:

Aylık Görevler

  • Haftalık görevlerde yer verdiğimiz konularda daha detaylı ve kapsamlı çalışmalar yapmak gerekir. Örneğin sadece index bozulmalarını inceleyip bakım yapmak yerine kullanılmayan indexleri de tespit edip kaldırmak gerekir. Bu çalışma sistemdeki kaynak tüketimini azaltacaktır. Üstelik bu sayede daha seyrek bakım ihtiyacı doğar. Kullanılmayan indexleri SSMS'te veritabanı üzerindeki raporlardan veya sys.dm_db_index_usage_stats nesnesinden tespit edebilirsiniz. Seek, Scan, Lookup işlemleri Update işleminden bariz şekilde daha az görünüyorsa bu index pek kullanılmıyor demektir. Sisteme yüktür. Bazen yeni indexler dikkatsizce tanımlandığında önceki indexlere gelen sorguları da cevaplar. Böylece eski indexler okumada kullanılamaz. Ancak her yapılan değişiklik indexlere yansıdığı için sürekli güncellenip bozulur. Bu da hiç ihtiyacınız olmayan bu indexlere gereksiz yere bakım yapmanıza sebep olur. Başka bir örnek de backup stratejiniz hakkında olabilir. FULL, DIFF ve LOG backupları doğru anlamak ve onları tam da gerekli olduğu zamanlarda kullanmak gerekir. Mesela LOG backupa ihtiyacınız yokken veritabanın FULL Recovery modda olmasının hiç bir faydası olmaz. Özellikle veriambarı tasarlarken çok fazla veri akış testleri yapılır. Bu esnada log sürekli büyür. Gereksiz yere kaynak tüketir. Recovery modu Simple moda çekip çalışmak bu gibi durumlarda daha avantajlı olur. Bu arada çok çeşitli yedekleme stratejileri geliştirilebilir. Veritabanın bir kısmını daha sık bir kısmını daha seyrek yedekleyebilirsiniz. Aynı anda birden fazla yere yedek alabilir. Yedeklerinizi sıkıştırabilir, şifreleyebilir, son kullanım tarihi verebilirsiniz. Doğru yedekleme stratejisi geliştirebilmek için temelde iki şeye bakılır. Ne kadar büyüklükte verinin kurtarılamamasına göz yumarım? Ne kadar zamanda sistemin ayağa kalkmasına tahammül edebilirim? Bu örneklerde olduğu gibi aylık görevlerde, haftalık görevleri daha detaylı ve kapsamlı şekilde ele almak gerekir.
  • Gereksiz yetki ve login/user ları temizlemek gerekir. Belli aralıklarla toplanan istatistiklere bakarak kullanıcıların ne sıklıkla, hangi roller ne şekilde giriş yaptığı bilinir. Bu bilgiler ışığı altında gereksiz yetki ve kullanıcıları kaldırmak en iyi seçenek olur. Özellikle sa loginin bir, iki kişide olmasına özen göstermek gerekir. sysadmin rolüne kimlerin sahip olduğunu, Yetki devretme yetkisinin kimlerde olduğunu tespit etmek ve bu yetkileri kısıtlamak gerekir. sysadmin yetkilerine sahip bir kullanıcı dilerse SQL Server içinden disklere format bile atabilir.
  • Server seviyesi konfigurasyonları ihtiyaca uygun hale getirmek gerekir. CPU, Memory kullanımı, parallelism vs. ihtiyaca uygun olarak ayarlanmalıdır. Buradaki ayarlar oldukça güçlüdür. Mesela ClrIntegrationEnabled özelliği ile .net kodlarını kullanarak kullanıcı tanımlı veritabanı nesneleri oluşturabilir, SQL Server'da yapılamayan programatik işleri yapabilirsiniz. xp_cmdshell nesnesi ile shell komutlarının SQL Server üzerinden çalıştırılmasını sağlayabilirsiniz. Buradaki konfigurasyonlar bilinçli kullanılmazsa ciddi güvenlik açığına sebep olabilir. Varsayılan olarak kapalı gelen DAC özelliğini RemoteDacEnabled seçeneğinden aktif edebilir, kimsenin giriş yapamadığı yoğunluktaki bir sisteme admin olarak her zaman giriş yapma imtiyazına sahip olabilirsiniz.
  • Veritabanı seviyesi konfigurasyonları ihtiyaca uygun hale getirmek gerekir. Veritabanlarının uyumluluk modu, recovery modu, verileri dikey veya yatay mantıkta farklı disklere ayırmak için file grouplar oluşturma seçeneği, sadece veri tabanı seviyesinde giriş yapabilen kullanıcı girişinin aktif edilmesi gibi seçenekleri ihtiyaca göre değiştirebilirsiniz.
  • Sistemin zinde kalmasını sağlamak gerekir. Disklerde yeterince boşluk oluşturulması, disklerdeki fragmantasonun azaltılması, bozulmaların giderilmesi, Windows, SQL Server, Management Studio güncellemelerinin takip edilip planlı şekilde uygulanması gerekir. I/O ve network performansı, buffer cache hit ratio, page life expectancy gibi değerler takip edilerek iyileştirmeler yapılmalıdır. Veritabanı tutarlılıkları DBCC CHECKDB gibi komutları ile kontrol edilmeli ve bozukluklar giderilmelidir. Alınan yedekleri sağlığı ve bu yedeklerden geri dönülüp dönülemeyeceği test edilmeli. Test ortamlarında felaket senaryoları, yedekten dönüş senaryoları uygulanmalıdır. Zaman zaman kullanılan nesnelerde performans iyileştirmeleri yapılabilmesi için ilgililere önerilerde bulunmak da isabetli olur. Sistemin zinde kalması için donanımın yükseltilmesi en son çare olmalıdır.
  • Tüm topolojinin ihtiyaca uygun olup olmadığını kontrol etmek gerekir. Zaman içerisinde bazı server ve veritabanları hiç kullanılmamaktadır. Bu da gereksiz lisans maliyeti demektir. Belli aralıklarla farklı serverdaki veritabanlarını aynı server altında birleştirmek mümkün olur mu diye kontrol etmek gerekir. Bazen de iş yükü çok büyüdüğü için okuma ve yazma iş yükleri farklı serverlar üzerine dağıtılır. Bu sefer de birden fazla serverı High Availbility kapsamında aynı amaç için bir araya getirme planları yapılır. SQL Server'ın yüklü olduğu serverlarda yoğun kaynak tüketen diğer programları da bulundurmaktan kaçınmak gerekir. Mesela mümkünse virüs programı kullanmamak, kullanılsa bile veritabanı dosyaları için exceptionlar oluşturmak gerekir.
  • Belli aralıklarla önceden hazırlanmış kontrol listeleri üzerinden sağlık kontrolleri yapmak gerekir. Sağlık kontrollerini belli kapsamda ve belli aralıklarla yapmak sistemin mevcut durumu ve serüveni hakkında bilgi toplamada önemli bir yere sahiptir. Özellikle test sonuçlarını raporlar haline getirmek, görsel olarak karşılaştırmak sistemi zinde tutmak için ciddi bir motivasyon oluşturur.
Son üç yazıda DBA'in günlük, haftalık ve aylık görevlerinin neler olabileceğinden bahsettik. Bu yazılarda bahsi geçen başlıklar birer öneri niteliğindedir. Bu başlıkların altında veya bu başlıklar haricinde bir çok konuda çalışma yapılabilir. Yaygın olarak yapılması gerekenler aşağı yukarı bunlardır. Konunun zenginleştirilmesi veya ihtiyacınız kadarını kullanmak size kalmış. 

DBA'in görevlerini özetlemek gerekirse; 

Bir DBA'in günlük olarak sistem hakkında üretilen bilgileri takip etmesi ve ani gelişen olaylara müdahale etmesi beklenir. Haftalık olarak takip işini bazı konular için biraz daha detaylandırır ve çalışmalarının kapsamını genişletir. Bir takım konularda da bakım yapar, iyileştirme fırsatlarını değerlendirmek üzere aksiyon planları hazırlar. Aylık olarak da daha çok sistemin uzun vadede güncel ve zinde kalması için gerekli güçlü dokunuşları yapar. Sistemi gereksiz yüklerden arındırır, daha fazla iş yükünü göğüsleyebilmek için geniş ölçekli planlar hazırlar, uygular.

Önceki yazılarımıza şu linklerden ulaşabilirsiniz:

Veritabanı Yöneticisinin Rutini - Haftalık (DBA's Routine - Weekly)



Veritabanı Yöneticisinin Rutini - Günlük (DBA's Routine - Daily)


Faydalı olması dileğiyle,

Veritabanı Yöneticisinin Rutini - Haftalık (DBA's Routine - Weekly)

Bir önceki yazımızda Veri Tabanı Yönetim Sistemlerinde yapay zeka akımının etkilerini görebiliyoruz demiştik. Bu akım yakın gelecekte DBA'lerin iş yapma şeklinde ciddi değişikliklere sebep olacağa benziyor. Şimdiden bu değişiklikler olmaya başladı bile.

Bu akımın etkileri gele dursun biz bir DBA'in rutininde neler olabileceğini incelemeye devam edelim. Önceki yazımızda günlük rutine odaklanmıştık. Bu yazımızda haftalık rutinde neler olabileceğini ele alalım.

Önceki yazıya ulaşmak için:

Veritabanı Yöneticisinin Rutini - Günlük (DBA's Routine - Daily)

Önceki yazımızda bahsettiğimiz şu beklenti bu yazının konusunu oluşturmakta ;
"Bir DBA'in riskleri belirleyerek önlemleri zamanında alması, iyileştirme fırsatlarını görerek uzun ve kısa vadede çeşitli aksiyon planları oluşturması beklenir."

DBA'in günlük görevleri daha çok üretilen istatistikleri incelemekten, ani ve kısa süreli müdahalelerde bulunmaktan ibarettir. Haftalık ve aylık görevleri ise bu bilgiler ışığı altında bakım ve iyileştirmeler yapmaktır.

Haftalık Görevler

  • Metadata üzerinde daha kapsamlı ve detaylı inceleme yapılır. Günlük görevlerde bahsettiğimiz tüm takipler gün içinde yetişmeyebilir. Bunları biraz daha detaylı olacak şekilde haftalık görevler arasına almak gerekebilir.
  • Sistem veritabanlarının yedeklerini almak. Tüm yedekler hakkında bilgiyi detaylı bir şekilde incelemek, yedeklerin sağlığından emin olmak gerekir. Bununla birlikte sistem veritabanlarının yedekleri sistem yoğunluğuna göre belli aralıklarla alınmalıdır. tempdb zaten her yeniden başlatmada sıfırdan oluşur. model veritabanı yeni oluşacak veritabanları için bir tür template görevi görür. Genelde tempdb ve model (bazı senaryolar için anlamlı olabilir) veritabanlarının yedeğine ihtiyaç duyulmaz. Ancak master ve msdb veritabanları bir hayli önemlidir. Özellikle master veritabanında server ayarları, kullanıcı, veritabanı, şifrelemeye dair bilgiler gibi hassas veriler yer alır. master kullanılamaz olduğunda sistemi işler hale getirmek ya çok sancılı olur ya da veriler artık kullanılamaz hale gelir.
  • Veritabanı yedeklerin kullanılabildiğinden emin olmak gerekir. Genel en fazla yedek almaya odaklanılır. Ancak yedeklerin kullanılabileceğini kontrol etmek en az yedek almak kadar önemli bir konudur. Yanlış stratejiler veya kullanılan ek ürünlerden dolayı LSN zinciri bozulmuş olabilir. Ya da backup alınan yerde çıkan bir hata yüzünden dosya kullanılamaz hale gelmiş olabilir. Yedekten dönmeyi denemeden yedeklerin işe yarayıp yaramayacağını anlayamayız. Bu yüzden test sunucularda restore senaryolarını belli aralıklarla uygulamak çok önemlidir.
  • Takipler ve incelemeler sonucunda elde edilen bulgulara göre Maintenance Plans (Bakım Planları) hazırlanmalıdır. Bakım planları SSMS / Management / Maintenance Plans altında oluşturabilirsiniz. Daha sonra bu planları SQL Server Agent üzerinde oluşturacağınız job'larda kullanabilir çeşitli periyotlarda bakımların yapılmasını sağlayabilirsiniz. Bu planlar içerisinde yedek alma, index rebuild-reorganize, istatistikleri güncelleme, veritabanı tutarlılık kontrolleri gibi işleri yapabilirsiniz. Daha kompleks işleri yürütmek için SSIS projesi açıp burada oluşturduğunuz paketlerden joblar tanımlamayı da tercih edebilirsiniz.
  • İstatistikleri güncellemek ve indexlere bakım yapmak gerekir. İstatistiklerin güncel, indexlerin bakımlı olması sorgu performansını doğrudan etkiler. önceki yazıda bahsettiğimiz şekilde bu bilgilere erişip bakım planımızı oluşturabiliriz. İstatistikler varsayılan olarak otomatik güncellenir. Eğer güncel değilse Maintenance Planlarla veya Update Statistics 'tabloveyaindexedview' komutu ile güncelleyebilirsiniz. Indexlerin bozulmalarına bakarak eğer bozulma %5 ile %30 arasında ise Reorganize, %30'dan fazla ise Rebuild yapmanız gerekir. Bozulma bilgisine SSMS üzerindeki raporlardan veya ilgili tablonun altında indexleri sağ tıklayıp açılan menüdeki özelliklerden veya sorgu ile sys.dm_db_index_physical_stats nesnesinin avg_fragmentation_in_percent kolonundan öğrenebilirsiniz. Bakımı da yine SSMS üzerinden indexe erişerek veya Maintenance Planlar üzerinden yapabilirsiniz. Dilerseniz Alter Index IndexAdı on TabloAdı REORGANIZE/REBUILD komutlarını ve ihtiyacınız olan parametreleri de kullanabilirsiniz. Index bakım sıklığını ve bozulmayı etkileyebilecek şeyler yoğun veri girişi, fillfactor ve padindex ayarlarıdır. Bu iki ayar sayesinde çok sık bakım gerekmesin diye index sayfalarında boşluk bırakırız. Mesala fillfactor %80 ise %80 sayfalar dolu olsun %20 boşluk kalsın demiş oluruz. Buradaki değeri düşürmek bakımı geciktirir. Ancak çok düşürürsek bu sefer de bilgi çok fazla index pagee dağılacağı için blocking de artış olur. Optimum değer sistemimize bağlıdır. Dilerseniz padindex özelliğini kullanarak doluluk oranının indexin ara seviyelerine de uygulanmasını sağlayabilirsiniz.
  • En maliyetli sorgular ve en çok beklenen görevler için iyileştirmeler yapmak gerekir. Sorgularla ilgili en azından üç noktayı takip etmek lazım. Bunların ilki en maliyetli sorguların neden o kadar maliyetli olduğunu öğrenmektir. Sorgu yazımında, sorgunun kullandığı nesnelerin performansında, sorgunun cachedeki durumunda, index ve istatistiklerin bakımında bir problem var mı diye kontrol edip iyileştirmeleri ekip çalışmalarıyla yapmak gerekir. İkinci nokta ise maliyeti düşük fakat gün için defalarca çalışan sorguları nasıl iyileştirebileceğini araştırmak. Üçüncü nokta ise birer defa çalıştırılan sorgu sayına ulaşmak ve eğer çok fazla tek seferlik sorgu varsa server ayarlarından Optimze for Ad hoc Workloads özelliğini aktif etmek gerekir. Diğer bir konu ise en çok beklenen görevlerin neler olduğunu tespit etmektir. Önceki yazımızda da belirttiğimiz gibi sys.databases, sys.dm_os_wait_stats, sys.dm_os_waiting_tasks nesneleri ile hangi görevlerin beklendiği belirlenebilir. En çok beklenen görevlere bakılarak iyileştirmeler yapılabilir.
  • Latch, lock, block ve deadlock aktivitelerini takip edip çözüm üretmek gerekir. Latch diskten memorye geçişte yaşanan çok küçük kilitlenmelerdir. Normalde gözardı edilir. Ancak sistem çok yoğunsa baş belası olmaya başlar. Latch problem olmaya başladığında donanım bazlı iyileştirmelere veya inmemory özelliklerine göz atılabilir. Lock nesneler üzerinde bir işlem yapıldığında devreye girer. İhtyaca göre küçük veya büyük bir alana kilit konabilir. Lock arttıkça diğer işlemler blocklanır. Blocklamalarda bir işlem yapılırken diğerleri bekler. Blocking takip edilerek sebebi araştırılmalı biran önce çözüm üretilmelidir. Çok fazla işlem yapılması yüzünden daha büyük bir alana kilit uygulanması veya uzun süre açık kalan transactionlar yüzünden kilidin uzun süre kalması en sık görülen bloklama sebepleridir.  Kodlar yapılacak düzenlemelerle veya uygun Isolation seviyeleri ile blocking problemi çözülebilir. Deadlock ise neredeyse hiç fark edilmez. İstekler askıda beklemez tamamen reddolur. Çapraz bir şekilde aynı kaynaklara erişmeye çalışan isteklerden varsayılan olarak geri çevrilmesi en maliyetli olanı işleme alınır, diğerleri iptal edilir. Deadlock aktivitelerini profiler, extended event gibi araçlar takip edebilirsiniz. Elde edilen bilgilere göre deadlocklar azaltılabilir.
  • HA, Audit, Job, Maintenance Plans, Database Mail gibi özelliklerden kaynaklı aktiviteler sağlıklı şekilde devam ediyor mu diye bakılır. Bu aktivitelerin loglarına ve ayarlarına bakılarak sağlıkları kontrol edilmelidir. Beklenenin dışında bir işlem olmuş mu diye kontrol edilmelidir. Gerekli düzeltmeler tespit edilip uygulanmalıdır.
DBA'gün günlük işleri daha çok takip üzerine ve ani ihtiyaçlara cevap verme üzerine kuruludur. Gün ortasında yavaş çalıştığı ifade edilen bir sisteme bakım yapmak çok pratik olmaz. Günlük takipte edilen bilgiler ışığı altında yukarıda bahsettiğimiz şekilde haftalık bakımlar yapmak gerekir. Kendi sisteminizin ihtiyaçlarını göre burada yazanları zenginleştirebilirsiniz.

Burada bahsettiğimiz konuların sayısı, sırası ve içerikleri sistemin büyüklüğüne göre değişebilir. Bu yazıyı tamamlayıcı nitelikte olan önceki yazımıza da göz atmanızı tavsiye ederim.

Önceki yazıya ulaşmak için:

Veritabanı Yöneticisinin Rutini - Günlük (DBA's Routine - Daily)

Faydalı olması dileğiyle,