2. Bölüm: Yedeklemeye gereken önemi vermek için canınızın yanması şart mı?

Bir önceki yazımda doğru yedeklemenin önemini vurgulamış, bir canlı ortamda disklerin silindiğini ve yedeklerden nasıl (neredeyse) hiç veri kaybetmeden geri döndüğümüzü bir sonraki yazımda anlatacağımı söylemiştim. Doğru yedeklemenin nasıl hayat kurtardığını somut bir örnekle bu yazımda anlatacağım.

1-2 ay önce ortamlardan birinde bir Cuma öğlen saat 14:30 gibi çok kritik olan bir canlı SQL Server sunucusundan ilginç mesajlar ve son kullanıcıdan şikayetler gelmeye başladı.

İlgili sunucuya bağlanmaya çalıştım, ama nafile. Ne SQL Server Management Studio ile bağlanabiliyordum ne de uzak masa üstü bağlantısı yapabiliyordum. Sunucu sanal bir sunucuydu. İlgili sistemci arkadaşımla temas kurdum ve şikayetimi ilettim. Az sonra sistemci arkadaşımdan telefon geldi ve telefondaki ses şöyle diyordu: "Diskleri kaybettik...".

Bir felaket senaryosunun yolunu açan ilk kelimelerdi bunlar. Daha fazla bilgiye ihtiyacım olduğu için doğrudan disk yöneticisi arkadaşlarla temas kurdum. Yeni bir disk verilmeye çalışılırken, varolan veritabanı Transaction Log, SQL Server ve işletim sistemi dosyalarının bulunduğu diskler silinmişti ve geri getirilme olasılığı yoktu. Sorunun teknik olmadığını ve insan hatasından kaynaklandığını öğrendikten sonra, sorun en azından o anda tekrar etmeyeceği için ilk etapta öğrenmek istediklerim sadece bunlardı. Neden ve nasıl olduğunun ayrıntıları bu etapta beni ilgilendirmiyordu, çünkü sorunun çözümüne hiçbir katkısı yoktu.

Sistemi geri ayağa kaldırabilmek için elimdeki seçeneklerimi düşündüm.
- Yerel sunucuda, veritabanlarının bulunduğu fiziksel disk altyapısından hariç başka bir disk altyapısından verilen disklere düzenli ve sık aldırdığım yedeklerim vardı,
- Uzakta Log Shipping ile beslediğim, tüm veritabanlarının ve Instance düzeyindeki nesnelerin olduğu bir yedek sunucum vardı,
- Alınan imaj yedekleri vardı (hatırlatırım, ortam sanal makine idi).

Buradaki en kilit madde 1. madde, o maddeyi birkaç kere okuyun lütfen. Eğer disk altyapıları fiziksel olarak farklı olmasaydı o zaman disk yönetimi bölümündeki arkadaş bu diskleri de silebilirdi, büyük risk. 2. madde bize ekstra bir yedekleme seçeneği sağlamıştı. Eğer 2. disk altyapısında da bir sıkıntı olsaydı, ODM ortamımıza yönelecektik.

Eldeki imkanları ve seçenekleri düşünerek hemen bir plan yaptık ve sıfırdan bir makine kurarak sistemi en kısa sürede tekrar ayağa kaldırdık. Eğer üzerinde düşünülmüş bir yedekleme planı olmasaydı, belki de şirket iş hayatına devam edemeyecekti.

Bazen gayet güzel bütçe imkanı oluyor, ama güzel yedekleme planları olmuyor. Biri olmadan, diğeri hiçbir işe yaramıyor. İyi bir felaketten kurtarma planı, hayat kurtarır.

Kazasız, belasız iyi işler dilerim,
Ekrem Önsoy

Yedeklemeye gereken önemi vermek için canınızın yanması şart mı?

Düşününce İstanbul'daki bir sonraki deprem için alınması gereken, alınıyormuş gibi gösterilen ama aslında alınmayan ve yedeklemeye verilmesi gereken, veriliyormuş gibi görünen ama aslında verilmeyen önem ve ciddiyet arasında ne kadar benzerlik olduğu geliyor aklıma. İstanbul'daki son büyük depremde ne kadar canımız yanmıştı, o kadar konuşuldu, yazıldı, çizildi... Sonuç? Önce sağda solda, içlerinde kazma kürek olduğu söylenen konteynırlar gördük, bir süre sonra yok oldular tek tek, sonra "Kentsel Dönüşüm" adı altında, sadece müteahhitlerin kar edebileceği binaların yenilendiği abuk bir çözüm çıktı ortaya. Altyapı, aynı. Maksadım elbette politik bir tartışma yaratmak değil, yedeklemeye dikkat çekmek.

Çünkü, efendim birçok firmada şahit oldum ve olmaya da devam ediyorum:

- "Yedekleme bizim için çok önemli!"

- "Yedekleme için Veaam, Data Protection Manager, Glasshouse gibi çeşitli çözümler kullanıyoruz."

- "Yedekleme araçlarımızdan sorumlu, kullanan personelimiz var."

- "Yedekleme için gerekli tüm kaynaklarımız var"

deniyor... Sonuç? Yıllardır biriktirdiğim tecrübeye dayanarak çok farklı ortamlardan, ama gerçek örneklerle anlatıyorum, sonuç şöyle:

- Çok daha kısa sürede alınabilecek yedeğin alınması 10 saat sürüyor,

- Veaam ile aynı veritabanlarının günde 8 kere yedeği alınıyor. VSS ile aldığı için gün içerisinde donmalara neden oluyor,

- Data Protection Manager (DPM) ile alındığı zannedilen yedek konusunda DPM yöneticisinin bile haberi yok,

- Yedekler, veritabanı ve diğer tüm dosyaların da bulunduğu aynı disk altyapısındaki disklere alınıyor. Yani disk altyapısı gitti mi, yedekler de gidiyor, asıl dosyalar da..

- Yedekler alınıyor, ama ne sıkıştırma özelliği kullanılıyor, ne "checksum" kontrolü yapılıyor. Bu nedenle yedek depolama maliyeti artıyor. Çok daha fazla yedek, daha uzun süre depolanabileceğine, çok daha az yedek daha kısa süreliğine tutulabiliyor. Sonra yenilerine yer açmak için eskiler, daha uzun süre tutulabilecekken siliniyorlar. Yani kaynaklar verimli kullanılmıyor,

- Çok kritik veritabanları için sadece bir kere tam veritabanı yedeği (full database backup) alınıyor, ama Transaction Log yedeği alınmıyor, yani bir kriz anında 24 saatlik veri kaybı olasılığı var,

- Restore testleri yapılmıyor veya yapılıyor, ama bir düzen yok. Restore testlerine gerekli önem verilmiyor,

- Hangi veritabanı ve sunucu ne kadar kritik? Hangisi için hangi yedek ne kadar süre tutulmalı? Ne kadar sürede geri dönüş sağlanmak zorunda? Ne kadarlık veri kaybı tolere edilebilir? RPO ve RTO'lar belirlenmemiş.

Ve daha neler neler... Nasıl? Size de bir şeyler hatırlattı mı yukarıdaki maddeler? Eminim birçok kişiye kendi ortamlarıyla ilgili bir şeyler çağrıştırmıştır.

Öyle veya böyle, üzgünüm ama o felaket bir gün başınıza gelecek ve felaketin binbir türlü çeşidi var. Disk altyapısı bozulabilir, yeni bir disk verilirken varolan canlı ortam diskleri silinebilir (daha 1,5 ay önce geldi başıma), Windows veya SQL Server Update'leri nedeniyle makine bir daha açılmayabilir veya servisler doğru çalışmayabilir (bu da 1 ay önce geldi başıma), bir çalışan yanlışlıkla veya kızgınlıkla verilerinizi bozabilir, güncelleyebilir veya silebilir...  Bunun için artık çok daha çeşitli, uygun fiyatlı seçenekler ve birçok şirketin bu seçenekleri kullanabilmesi için kaynak da var. Tek sorun, bu konuya vaktinde yeterince önem verilmemesi gibi geliyor bana. Vaktinde önem verilmeyince de, imkan da olsa, personel de olsa, artık iş işten geçmiş oluyor.

Doğru yedekleme politikası zamanı gelince hayat kurtarır. Bir sonraki yazımda, yukarıdaki paragrafta başıma gelen canlı ortam disklerinin silinmesinden ve doğru bir yedekleme politikasıyla neredeyse hiç veri kaybetmeden nasıl o ortamı kurtardığımızdan bahsedeceğim.

Sevgiler,

Ekrem Önsoy

SQL Server on Linux ile ilk flört!

Selamlar!

Microsoft'taki bu değişim ve dönüşüm herkesin malumu, yeni bir şey değil. Buna Steve Ballmer'dan sonra göreve gelen Satya Nadella ile başlayan veya belki çığ gibi büyüyen bir hareketlenme demek sanırım yanlış olmaz.

Geçen gün SQL Server'ın Linux Red Hat ve Ubuntu üstünde çalışan versiyonları yayınlandı. SuSE versiyonu da yakında geliyormuş. Bunların yanında Linux, MacOS ve Windows'ta Docker Container'da çalışacak versiyonu da mevcut.

Madem gelmiş, hoş gelmiş diyerek ben de bir makinede Ubuntu Linux kurulumu yaptım ve "bakalım Linux üstünde Microsoft SQL Server kullanımı nasıl oluyormuş?" dedim. SQL Server'ın bu versiyonuyla yaptığım ilk flörtümün tecrübelerini sizlerle de paylaşayım istedim.

Efendim öncelikle Ubuntu'nun sitesinden 1,51GB boyutundaki son versiyonun imaj dosyasını indirip Linux kurulumunu yaptım. Daha sonra da Microsoft'un yayınladığı dokümantasyona göre SQL Server on Linux kurulumunu yaptım. Çeşitli adımlardan sonra yükleme adımının sonucunu aşağıda görebilirsiniz.

Database Engine kurulumu

Yukarıdaki ilk kurulum adımını hallettikten sonra kurulumu tamamlamak için yine yukarıdaki açıklamada belirtilen dosyayı çalıştırdım ve sonucu aşağıdaki gibi oldu.

Database Engine kurulumunun tamamlanması

Yukarıdaki hamleyle SQL Server kurulumumu tamamlamış oldum. Bu kurulum sadece SQL Server Database Engine servisini içeriyor. SQL Server Instance'ımıza bağlanabilmemiz için SQL Server Management Studio veya SQLCMD gibi Tool'lara ihtiyacımız var. Neyse ki SQLCMD yardımımıza koşuyor! SQLCMD'yi kurmak için yine ve bu sefer başka bir adresteki dokümantasyondan faydalanabiliyoruz.

SQLCMD ve Provider kurulumlarından sonra bu sefer aşağıdaki ekranda gösterdiğim gibi SQL Server servisimin çalışıp çalışmadığını kontrol ettim.

SQL Server Database Engine servisinin çalışma durumu

Servisimin çalışıyor olduğunu gördükten sonra biraz SQL Server Error Log dosyasını kurcalamak istedim. Error Log, Extended Event Log ve Default Trace dosyaları /var/opt/mssql/log altında barındırılıyor varsayılan olarak. Ekran görüntüsü aşağıda.

Log dosyalarının konumu

Güncel Error Log'un içeriğini biraz incelediğimde aşağıdaki gibi hoş bir sürpriz ile karşılaştım, dosya yolları "C:\..." olarak duruyor hala =) Bu bilinen bir Bug imiş, Microsoft bunun gelecek versiyonlarda düzeltileceğini söylüyor.

SQL Server Error Log dosyasının içinden bir görüntü

Sistem veritabanlarının dosyaları /var/opt/mssql/data yolunda konumlandırılmış. Yeni bir veritabanı oluşturulduğunda da varsayılan olarak burada oluşturuluyor dosyalar.

SQLCMD Tool'unun kullanımı aşağı yukarı Windows'taki kardeşiyle aynı. Mesela aşağıdaki gibi bir komut ile SQL Server Instance'ıma bağlandım ve versiyon bilgisini aldım:

SQLCMD ile SQL Server Instance'ına bağlantı

Gördüğünüz gibi bildiğiniz -U ve -P parametreleri. Elbette şu anda diğer parametrelerde farklılıklar olabilir, hepsini tek tek incelemedim henüz.

Bu konudaki gelişmeleri tararken bir Microsoft çalışanının aşağıdaki yorumunu gördüm ve aslında dün akşam Twitter'dan paylaştım (@EkremOnsoy).

DB Admin GUI?

Bu henüz muğlak ve resmi olmayan bir yorum olsa da, belli ki bu konuda çalışan takımların böyle bir fikri var. Eğer Microsoft personeli böyle şeyleri sağda solda konuşuyorsa, ki zaten yatırımlar da bu yönde, bence böyle bir Tool'un deneme versiyonunu da yakında görürüz. Sonra Ekrem demedi demeyin!

Beni az çok tanıyan birisi bu işin peşini sadece SQLCMD ile bırakmayacağımı sanırım tahmin ediyordur. Elbette dahili bir ağ kurdum ve bir Windows 7 işletim sistemimdeki SQL Server Management Studio'unun son versiyonu olan 16.5 ile Ubuntu üstündeli SQL Server on Linux (vNext CTP1)'e bağlanmayı denedim. Sonuç aşağıda:

SQL Server Management Studio ile Linux'te çalışan SQL Server Instance'ına bağlantı

Nasıl? Etkileyici değil mi?

Evet arkadaşlar, artık "comfort-zone"dan çıkma veya "dinozor" olarak emekliliğe adım atma zamanının geldiği çok daha net. Cesur olun!

Sevgiler,
Ekrem Önsoy

Daha neler göreceğiz! Microsoft bir bomba daha patlattı!

Merhabalar!

SQL Server 2016 Service Pack 1 duyurusu ile Microsoft çok büyük bir bomba daha patlattı millet!

Sahada pratik olarak kullanabileceğiniz ve çok verimli olan birçok Enterprise Edition özelliği artık diğer Edition'larda da kullanılabilecek! Artık diğer Edition'larda da kullanılabilecek özelliklere ait başlıklar, yukarıdaki duyuru adresinden aldığım aşağıdaki tabloda.

Row-Level Security ve Dynamic Data Masking özelliklerinin zaten Standard Edition'da kullanılabileceğini RTM duyurularından biliyorduk. Fakat yukarıdaki listeden de görebileceğiniz gibi, piyasada birçok firmanın çok işine yarayabilecek özelliklerin özellikle
- Table Partitioning: Neredeyse kesintisiz arşivleme,
- Data Compression: Tabloları, indeksleri sıkıştırabilmek,
- Fine grained auditing: Tablo bazında, SELECT, INSERT, UPDATE, DELETE gibi işlemlerin de artık loglanabilmesi,
- Columnstore: Bu indekslerle raporlama ihtiyaçlarının çok daha verimli karşılanabilmesi,
- Database snapshot: Kritik işlemlerden önce (mesela yeni bir kod yayınını düşünün) veritabanının Snapshot'ının alınması

Not: Dynamic Data Masking ve Row-level security'den de gayet faydalanılabilir, yukarıda özellikle eskiden Enterprise Edition özelliği olanlara değindim.

Not2: In-Memory OLTP'nin ne kadar ilgi göreceğini kestiremiyorum, çünkü henüz Microsoft SQL Server Standard Edition'ın RAM sınırlamasında bir değişiklik yapmadı. In-Memory OLTP de doğrudan RAM kaynakları ile ilgili olduğu için kullanılabilse de çok sınırlı tablolar ve SP'ler için kullanılabilir olur. Bu özelliğin kullanımı düşünülüyorsa kaynak ayarlaması muhakkak iyi hesaplanmalı.

Sahada pratik olarak en çok bunların kullanılabileceğini, Standard Edition kullanan firmaların en çok bu özelliklerden faydalanabileceğini düşünüyorum.

Hemen belirteyim, bu özellikler sadece SQL Server 2016 + Service Pack 1 ile mümkün olacak, geriye dönük, yani SQL Server 2012, 2014 gibi önceki versiyonlarda Standard Edition'da bu özellikle kullanılamayacak.

Yukarıdaki özellikleri iyi planlayarak, kurgulayarak devreye alabilirseniz birçok alanda kaynaklardan tasarruf sağlayıp, firmanıza karlılık sağlayabilirsiniz.

Eğer projelerinizde yardıma ihtiyacınız varsa beni aramaktan çekinmeyin!

Sevgiler,
Ekrem Önsoy

Database Mail ile başka bir sorun daha

Merhaba millet!

Bu aralar biraz yoğunum, o nedenle bir süre bir şeyler yazamadım. Geçen hafta yurtdışındaydım, Hollanda'nın Den Haag şehrinde. Orada, önceden Antalya Havalimanında çalışan ve şimdi de Amsterdam'da çalışıyor olan veritabanı yöneticisi Hayri Özler ile de tanışmış olduk, pek de hoş oldu, ona da selam olsun!

Cumartesi gecesi yurtdışından gelir gelmez bir de AlwaysOn Availability Group geçişi yaptık. Yoğunluk hala devam etmesine rağmen araya hemen bir yazı sıkıştırayım dedim.

Bugün ortamlardan birinden bir süredir eposta almadığımı fark ettim. Sorunu incelediğimde Database Mail'in yine çeşitli sebeplerden biri yüzünden çalışmadığını gördüm. Arkadaşlar, yine sonra söyleyeceğimi baştan söyleyeyim, eğer DatabaseMail sizin için kritik bir özellik ise ve ortamınızda bir izleme uygulamanız varsa o zaman muhakkak gönderilirken hata alan veya Queue'da çok bekleyen e-postalarınızı kontrol ettirin.

Sorunu incelemek için ilk önce [msdb] sistem veritabanında bulunan Database Mail ile ilgili tabloları sorguladım. Mesela:

SELECT TOP (10) * FROM msdb.dbo.sysmail_event_log ORDER BY log_date DESC

ve

SELECT TOP (10) * FROM msdb.dbo.sysmail_allitems a ORDER BY a.send_request_date DESC

Bu ortamda hem e-posta'ların gönderilemediğine dair hatalar vardı, hem de öylece gönderilmeyi bekleyen birçok e-posta vardı.

Önce Database Mail yapılandırmamın doğruluğunu kontrol ettim. Database Mail Account'umun kullanıcı bilgilerini kontrol ettim. Doğruluğundan emin olduktan sonra ve Database Mail'in hala çalışmadığını gördükten sonra Database Mail'i tekrar başlatmayı düşündüm. Database Mail, SQL Server kurulumu ile birlikte gelir, ama SQL Server Database Engine servisine gömülü bir özellik değildir. Misal Task Manager'dan bakarsanız DatabaseMail.exe diye harici bir uygulamanın çalıştığını görürsünüz. Bu, SQL Server ile birlikte gelen Database Mail özelliği için kullanılan uygulamanın ta kendisidir. Eğer bu uygulama çalışmıyorsa, Database Mail özelliği de çalışmaz.

Database Mail'i tekrar başlattıktan sonra sorunun yine devam ettiğini gördüm. Bunun üzerine Database Mail'in Queue'larını incelemeye karar verdim. "O da nesi?" diye soran arkadaşlarım, Database Mail özelliği Service Broker'ı kullanır, e-postalarınızı bu sayede asenkron olarak gönderilir. Service Broker yapısında da birçok eleman gibi Queue'lar da vardır. Gönderilmek istenen mesajlar önce Queue'lara kaydedilir, sonra da sırasıyla işlenirler. İşte Database Mail'in yine [msdb] veritabanındaki External Queue'sunu ([msdb].[dbo].[ExternalMailQueue]) incelediğimde 20 binden fazla mesaj biriktiğini gördüm. Bunların çoğu zaten artık vakti geçmiş, gereksiz mesajlardı. Bu Queue'yu temizleyince Database Mail ile bir test e-postası gönderdi ve Voila! Artık Database Mail'im çalışıyordu.

Yine vurgulamakta fayda görüyorum. Eğer Database Mail özelliği sizin için kritikse, yani mesela bazı kritik e-postalarınızı Database Mail ile gönderiyorsanız veya 3. parti izleme uygulamalarına bütçe ayıramıyor ve kendi çözümlerinizi kullanıyor ve yine bu kapsamda alarmları Database Mail ile gönderiyorsanız, aynı SQL Server Database Engine servisini izlettiğiniz gibi (izletiyorsunuz, değil mi?) Database Mail'in sağlıklı çalışırlığını da kontrol ettirmelisiniz.

Sevgiler!
Ekrem Önsoy