29 Temmuz 2015 Çarşamba

SQL Server 2016: Dynamic Data Masking

Selam arkadaşlar,

SQL Server 2016 test ortamımda Dynamic Data Masking özelliğini test ettim, sonucu sizinle de paylaşmak istiyorum. Test için AdventureWorks2012.Person.PersonPhone tablosundaki PhoneNumber alanını kullandım. Dynamic Data Masking özelliğini kullanarak, aşağıdaki komutlarla NVARCHAR(25) veritipiyle oluşturulmuş PhoneNumber alanındaki değerlerin ortasındaki 3 karakteri XXX karakterleriyle maskeledim.

Maskelemeden önce verinin nasıl göründüğü

Maskeleme için kullandığım komutlar:

USE [AdventureWorks2012]
GO
ALTER TABLE Person.PersonPhone
ALTER COLUMN PhoneNumber ADD MASKED WITH (FUNCTION = 'partial(3,"-XXX-",4)');

Bu komut ile veriyi değiştirmiş olmuyoruz, sadece soyut olarak maskeliyoruz. db_owner ve sysadmin olmayan ve UNMASK yetkisi bulunmayan tüm kullanıcılar veriyi aşağıdaki gibi görüyor:

Maskelemeden sonra verinin yetkisiz bir kullanıcıya nasıl göründüğü

Eğer isteseydim telefon numaralarına dair hiçbir veriyi göstermezdim ve/veya istediğim sayıda "X" kullanırdım ve değerin kaç karakter olabileceği hakkında da yetkisiz kullanıcılara fikir vermeyebilirdim.

Aşağıdaki komut ile de maskeli bir alanın bu özelliğini kaldırabilirsiniz:

ALTER TABLE Person.PersonPhone ALTER COLUMN PhoneNumber DROP MASKED;

Dynamic Data Masking özelliğinin çalışabilmesi için, bu özelliğin kullanılacağı veritabanının Compatibility Level ayarının 130 (SQL Server 2016) yapılması gerekiyor. Örneğin Compatibility Level ayarı 90 (SQL Server 2005) olan bir veritabanı için bu özellik kullanılamıyor. 

Büyük bir olumsuzluk beklemesem de, performansa nasıl bir etkisi olacağını bilemiyorum; ama kullanımı gayet pratik, uygulama tarafında hiçbir değişiklik gerektirmiyor. Tek değişiklik yönetim tarafında, ilgili alanının yukarıda belirttiğim komut ile MASKED olarak tanımlanması ve ilgili / yetkili olacak kullanıcılara UNMASK yetkisinin verilmesi.

Bu özellik hakkında daha fazla bilgiye Books Online'dan ulaşabilirsiniz:

Kolay gelsin,


Ekrem Önsoy

24 Temmuz 2015 Cuma

SSMS yenileniyor! Artık daha yeni, daha dinamik, daha güncel!

Merhabalar,

Enterprise Manager'dan sonra SQL Server 2005 ile birlikte hayatımıza giren SQL Server Management Studio (SSMS) artık daha güncel ve dinamik olacak. Nasıl mı?

Şöyle efendim, şimdiye kadar SSMS'in yeni versiyonları hep SQL Server Database Engine'in yeni versiyonlarıyla birlikte, yani son versiyonlara göre bakarsak, iki senede bir çıkardı piyasaya. Özellikle Azure SQL Database gibi, 2 yıl gibi uzun aralıkları beklemeden sürekli yeni özelliklerin eklendiği dinamik bir servisin de devreye girmesiyle, SSMS'in de böyle dinamik bir şekilde güncellenmesi ihtiyacı hasıl oldu. Çünkü SSMS, Azure SQL Database servisinin yönetimi ve bu ortamda yapılacak geliştirme işleri için de kullanılacak en temel araç. Bu nedenle Azure SQL Database servisine yeni bir özellik eklendiğinde, bu özelliğin SSMS tarafından da desteklenmesi gerekiyor ve bu destek artık içinde bulunduğumuz bu süreçte 2 yıl gibi bir süre bekleyemez.

Bu kapsamda ben de Microsoft'un ilgili sayfasından SSMS'in bu yeni versiyonunu test makimene indirdim ve kurdum. SSMS'in bu versiyonu (SQL Server 2016 CTP 2.2 - 31,5MB), SSMS'in önceki versiyonlarıyla yanyana çalışabiliyor, yani bunu kurmadan önce eski versiyonları kaldırmanız şart değil. Ayrıca, SSMS'in bu versiyonu SQL Server 2005 versiyonundan itibaren tüm SQL Server servislerini de destekliyor.

SSMS SQL Server 2016 CTP 2.2
Yukarıdaki ekran görüntüsünden de görebileceğiniz gibi SSMS'in bu yeni versiyonu, güncellemeleri otomatik olarak yapabiliyor. Bunun yanında, aşağıdaki ekran görüntüsünde "Check for Updates…" menüsünü de görebilirsiniz. Eğer güncellemeleri kendiniz kontrol etmek isterseniz, bu yöntemi seçebilirsiniz.



SSMS'in özellikle Azure SQL Database ile birlikte gelecek olan yeni özellikleri destekleyebilmesi için ve bununla sınırlı kalmayarak SQL Server'ın kendi makinelerimizde kurulu olan versiyonlarındaki henüz desteklenmeyen bazı özelliklerin arayüz olarak desteklenmesi ve zaten var olan arayüzlerin iyileştirilmesi / geliştirilmesi için Microsoft'un bu hamlesi sevindirici. Böylece birçok iş için kullanıyor olduğumuz SSMS, genel SQL Server yüklemelerinden bağımsız bir hale geldi. Bakalım zaman, daha nelere gebe?

Ekrem Önsoy

10 Temmuz 2015 Cuma

Bir forum hikayesi: Shrink it and everything's gonna be fine...

Selam millet,

Dün (9 Temmuz 2015) birisi MSDN SQL Server forumlarında yaşadığı kapasite sorunuyla ilgili bir soru sordu, ibretlik olsun diye bunu bu yazımda irdelemek istiyorum.

Soru şöyle (Noktası virgülüne aynı):
"Hi all,
i've a server which is reside in remote area. my database store in drive E where disk capacity is 1000 GB and DB size reached 800GB , now disk free space showing 10 GB only . how to manage space.
couple of week back i've tried to shrink the database but it is not completed successfully and since the time db size drastically increase. now i'm sitting in corner. please help anyone to resolve this issues.
can we perform partial shrink only on MDF. so that we can manage the space (starting from 10 gb only)
if yes then please share the T-sql script."
Türkçesi:
"Herkese merhaba,

Uzaktaki bir sunucum var. Veritabanı E: diskinde ve kapasitesi 1TB ve veritabanının boyutu da 800GB'a ulaştı, şimdi diskteki boş alan sadece 10GB. Diskteki boşluk durumunu nasıl yönetebilirim?

Birkaç hafta önce veritabanını küçültmeye (Shrink) çalıştım, ama işlem başarıyla tamamlanmadı ve o zamandan beri veritabanının boyu ciddi şekilde arttı. Şimdi çaresiz kaldım, lütfen biri bu sorunu çözmem için yardımcı olsun.

Shrink işlemini sadece veri dosyaları (*.mdf) için yapabilir miyiz? Eğer öyleyse boş alan sorununun bu şekilde halledebiliriz.

Eğer böyle bi şey yapılabiliyorsa lütfen T-SQL Script'ini paylaşın."

Sorunun yorumu:
Şimdi bu sorudan hemen anlaşılıyor ki, bahsi geçen bu firmada bir SQL Server uzmanı yok. Muhtemelen her şeyle ilgilenmeye çalışan bir arkadaşa bu sorumluluk da verilmiş veya nispeten boyut olarak büyük sayabileceğimiz bu veritabanlarını yönetmek için bir Junior çalıştırıyorlar.

İlk gözlemler olarak şunları söyleyebilirim, bu arkadaş her şeyden önce kapasite planlaması yapmıyor. Veritabanlarının ortalama ne hızda büyüdüğünü bilmiyor. Shrink işleminin ne işe yaradığını ve sonuçlarını bilmiyor. Böyle bir durum ile önceden hiç karşılaşmamış.

Olabilir, profesyonel hayata dair sanırım hiçbir şeyi hiçbirimiz annemizin karnında öğrenmiyoruz. AMA! Sen gelmişssin uluslararası bir platformda bu sorununu paylaşmışsın. Sana defaatle "Güzel kardeşim, yapma, etme, Shrink senin sorununun çözümü değil" denmiş, ama belli ki bu konuda hiç tecrübesi olmayan biri "Shrink'e devam et sen kardeşim, iyidir" demiş ve sen çaresizce onu yapmaya devam etmişsin.

Sorunun ideal çözümü:
Dün ben ve başka arkadaşlar tekrar tekrar şunları önerdik:
- Mümkünse büyük ve gereksiz olan tablolardan temizlik yap,
- Eğer Transaction Log dosyanın boyutu çok büyükse, bunu en azından geçici bir süre için de olsa Shrink etmende sıkıntı yok (çünkü veri ve Transaction Log dosyaları aynı diskteydi),
- Yeni disk ekle! Çünkü Transaction Log dosyası veritabanının boyutuyla karşılaştırıldığında büyük değildi ve belli ki veritabanının büyümesi, tek seferlik bir işlemden kaynaklanan bir şişme durumu değildi.
- Eğer mümkünse, böyle bir durumda zaman kazanmak için Enterprise Edition kullanıyorsan (ve tabii CPU kaynakların da yeterliyse) Data Compression'ı düşünebilirsin.

Sonuç:
Şimdi bu sorunu yaşayan arkadaş dün heyecandan, çaresizlikten veya belki de yapabileceği hiçbir şey olmadığından veya saflğından diyeyim siz başka anlamlar yükleyin, bizim önerilerimiz yerine böyle bir sorun karşısında ısrarla Shrink'i öneren birisini dinledi. Böyle bir durumda Shrink'i önerebilecek biri, zaten hayatında 10GB'tan büyük veritabanı yönetmemiştir. Shrink'in tam olarak ne anlama geldiğini, ne zaman yapılabileceğini ve ne işe yaradığını da bilmiyordur. Fakat biz bunu, soru sorana anlatamadık. Sonra ne mi oldu? Devamı aşağıda.

Sorunu yaşayan arkadaş bu sabah (10 Temmuz 2015) şöyle iki cevap daha vermiş:

"big problem in front of me. disk space gradually decrease and application performance down,
now it is showing
Msg 904, Level 16, State 1, Line 1Database 11 cannot be autostarted during server shutdown or startup."

Türkçesi:
"Büyük bir sorunum var. Diskteki boş alan miktarı adım adım azaldı ve uygulama performansı da düştü. Şu anda şu hataları alıyorum:

Msg 904, Level 16, State 1, Line 1
Database 11 cannot be autostarted during server shutdown or startup.
"

Hemen akabindeki diğer mesajı:

"now while connecting to the database 
massage showing 'database vts not accessible'
help me to fix this issues"

Türkçesi:
"Şimdi, veritabanına bağlanmaya çalıştığımda 'Veritabanına erişilemiyor' hatası alıyorum.

Bu sorunları çözmem için yardımcı olun."

Bu saatten sonra yapabileceği tek şey artık çok daha zor koşullarda yeni bir disk eklemek, ardından ilgili dosya grupları için bu diske yeni dosyalar eklemek. Tabii ki veritabanına erişebilirse ve kesintinin yarattığı stres ile başa çıkabilirse.

İnsanlar bir gün elbette bu işin çocuk oyuncağı olmadığını anlayacak.

Ekrem Önsoy

8 Temmuz 2015 Çarşamba

SQL Server 2016: Live Query Statistics

Merhabalar,

SQL Server 2016 ile ilgili pek öne çıkmamış bir yenilikten bahsetmek istiyorum size, Live Query Statistics!

Live Query Statistics'i, sorgularınız ile ilgili performans sıkıntılarını çözmek için kullanabilirsiniz, zaten diğer zamanlarda kullanmayın, çünkü dokümantasyondaki uyarıya göre sorgunuzun performansını ciddi şekilde olumsuz olarak etkileyebilir. Kullanımı, aynen Include Actual Execution Plan'da olduğu gibi, yine hemen Include Actual Execution Plan simgesinin sağ tarafındaki Include Live Query Statistics simgesine tıklayarak gerçekleştirilmektedir. Aşağıda ekran görüntüsünü de bulabilirsiniz.

Live Query Statistics
Yukarıdaki ekran görüntüsünde de görebileceğiniz gibi önce Include Live Query Statistics simgesine tıklayıp etkinleştirin (Query Editor'de farenin sağ tuşuna tıklayarak veya Main Menu'deki Query alt menüsünden ulaşabilirsiniz bu özelliğe) ve sonra da sorgunuzu çalıştırın.

Eğer sorgunuz yeterince uzun sürüyorsa, karşınıza Live Query Statistics penceresi çıkacak ve burada ilgili operatörde ne kadar zaman geçirildiğini canlı olarak göreceksiniz. O anda hangi operatörde işlem yapılıyorsa ve işin yüzde kaçı tamamlandıysa, o anda o operatörün altında "… % done" yazıyor. Ayrıca sorgu çalışmaya başlar başlamaz da her operatörün altında aynı anda zaman işlemeye başlıyor ve hangi operatörde ne kadar zaman geçirildiyse o operatörün altına bu geçen zaman not ediliyor. Bunu daha iyi görebilmeniz için bir de aşağıdaki gibi sorgu çalışırken ekran görüntüsü aldım.

Live Query Statistics - While a query is being executed
Ayrıca en aşağıda artık sadece "Executing query…" yazmıyor, bunun hemen sağ tarafında da sorgunun toplamda yüzde kaçının tamamlandığı da yazıyor. Henüz çalışma sırası gelmeyen operatörlerin arasında ok değil, sola doğru hareket halinde (animasyonlu) noktalar var.

Dokümantasyonda da görebileceğiniz birkaç hatırlatmayı paylaşayım, Live Query Statistics Memory Optimized Table'larla, Natively Compiled Stored Procedure'larla ve Column Store Index'lerle kullanılamıyor. 

Live Query Statistics ile ilgili Books Online dokümantasyonuna buradan ulaşabilirsiniz.

Ekrem Önsoy