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