6 Aralık 2016 Salı

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

21 Kasım 2016 Pazartesi

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

18 Kasım 2016 Cuma

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

14 Kasım 2016 Pazartesi

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

22 Ekim 2016 Cumartesi

"SQL Server Reporting Services: The feature: "Scale-out deployment" is not supported in this edition of Reporting Services."


Selam millet,

Ortamlardan birinde bir felaket yaşandı ve yeniden kurulum gerekti. Bunu belki başka bir yazıda yazarım. Bu yazıda değinmek istediğim şey Reporting Services ile ilgili.

İlgili ortamda kurulumları tekrar yaptık, tahmin edeceğiniz üzere bu ortamda Reporting Services da kullanılıyor.

Daha sonra kullanıcılardan Reporting Services ile ilgili şikayetler gelmeye başladı, aşağıdaki gibi:

No connection could be made because the target machine actively refused it XXX.XX.X.XXX:80

Önce Reporting Services servisinin çalıştığından emin oldum, sonra fark ettim ki Encryption Key'i Restore etmemişim. Onu da hallettikten sonra bir baktım aşağıdaki hatayı alıyorum:

"SQL Server Reporting Services: The feature: "Scale-out deployment" is not supported in this edition of Reporting Services."

Emin olamadım, bir Google'a sorayım dedim. Baktım Enterprise Edition özellikleri kullanılıp Standard Edition'a geçilince böyle sorun oluyor falan demiş birçok kişi. Mantıklı gelmedi, çünkü önceki kurulum da, bu kurulum da Standard Edition idi ve bir şey değişmemişti.

Biraz daha inceledikten sonra Reporting Services Configuration Manager'daki Scale-out Deployment bölümünde aynı sunucu adından 2 tane olduğunu gördüm. Emin değilim, ama sanırım Encryption Key'i Restore ettikten sonra oluştu bu durum. 

Basit bir şekilde listedeki sunuculardan birini "Remove Server" düğmesiyle kaldırdım ve Ta taaa! Sorun çözüldü.

Olur da bu sorun ile karşılaşırsanız tek nedeninin Edition farkı olduğunu düşünmeyin diye bu yazıyla bu durumu tarihe not etmek istedim.

Sevgiler!
Ekrem Önsoy