Aylar: Mart 2018

SQL Data Discovery and Classification

SQL Data Discovery and Classification

SQL Data Discovery and Classification , veri gizliliği standartlarını ve GPDR(General Data Protection Regulation)  gibi yasal uyumluluk gereksinimlerini  karşılamak ve veritabanında  bulunan sütunların kritik seviyelerini öğrenebileceğimiz ve bunları kendimize göre etiketleyip rapor halinde sunabileceğimiz  SSMS 2017(17.5) üzerine entegre edilmiş faydalı tool’dur.
SQL Data Discovery and Classification, SQL Server 2008 ve sonrası için desteklenir.

Bu kadar bilgiden sonra uygulamaya geçelim 🙂

Veritabanı üzerinde sağ tuş yaptıktan sonra  Tasks/Classify Data sekmesini seçiyoruz.

Classify Data sekmesine tıkladıktan sonra aşağıda ki ekran gelecektir bu ekranda manuel olarak  kolonları ekleyebilir yada  aşağıdaki gibi mevcut kolonları  işaretli SSMS yardımı ile otomatik ekleyebilirsiniz.

İşaretli olan yer seçildikten sonra  kolonları seçiyoruz , buradan verilerin hassasiyetini kendimiz manuel olarak da değiştirebiliriz bu işlemler yapıldıktan sonra  “Accept selected recommendations” butonuna tıklayarak   veri analizine başlatıyoruz ve bundan sonra save butonuna tıklayarak  son durumu kaydetmiş oluyoruz.

Bütün  işlemler bittikten sonra “View Report” sekmesine tıklayarak  raporlama kısmına geçiyoruz.

Ve rapor aşağıda ki  gibi veri hassasiyetlerine göre sınıflandırılmış şekilde karşımıza çıkıyor.

 

SQL de Sysadmin yetkisine sahip kullanıcıları görüntülemek

SQL de Sysadmin yetkisine sahip kullanıcıları görüntülemek

Bazı durumlarda sysadmin yetkisine sahip kullanıcıları görmek isteriz manuel olarak ssms üzerinden loginlere tek tek bakmaktan ise aşağıda ki T-SQL ‘i  kullanarak listeyebilirsiniz.

Aşağıda ki T-SQL de SQLServer Authentication ve Windows Authentication loginlerin sysadmin olanları görüntülenmektedir.

 

MSSQL Compatibility Level

MSSQL Compatibility Level

SQL Server da her sürüm için veritabanına numara verilmiştir. SQL Server belirtilen veritabanın davranışlarının belirtilen sürüm ile uyumlu olacak şekilde ayarlar bundan dolayı bazı özellikler bazı sürümlerde kullanılmamaktadır.

 

Örneğin: SQL Serverın 2012  versiyonunda Alter Table komutunu kullanırken servername.databaseadı.schemadı.table formatında kullanılmıyordu fakat  SQL Serverın 2014  versiyonundan sonra bu formatta da kullanabiliriz. Daha iyi anlaşılabilmesi için aşağıda  örnek ile açıklamak istedim.

SQL Server 2012 : Alter Table dbo.Table_1 ADD  name nvarchar(30)

 

SQL Server 2014  ve Sonrası için: Alter Table MSSQLServer.Mssqlİnstance. Dbo.Table_1 ADD name nvarchar(30)

 

Burada dikkat edilecek diğer bir konu eski sürümden yeni sürüme geçtiğinizde eğer birkaç  versiyon birden atlama yaptıysanız SQL Server Compatibility Level’e  kendi destekleyeceği en düşük seviyeye çekecektir. Bundan dolayı bazı problem yaşayabilirsiniz. Compatibility Level’i  Veritabanın üzerine sağ  tıklayarak  Properties kısmındaki options içinde yer alan  Compatibility Level bölümünden değiştirebiliriz.

Örnek olarak SQL Server 2008 kullanılırken SQL Server 2012 ye geçtiğinizde   hala 2008 versiyonunda ki bazı şeyleri kullanabilirsiniz fakat SQL Server 2016 versiyonuna yükselttiğinizde SQL Server 2008 de bulunan bazı özellikleri kullanamayacaksınız.

 

Aşağıda Sql Server sürümleri ve onlara karşılık gelen compatibility leveller bulunmaktadır.

Ürün Veritabanı  Sürümü Uyumluluk Düzeyi Tanımı Desteklenen Uyumluluk Seviyesi Değerleri
SQL Server 2017 14,00 140 140, 130, 120, 110, 100
Azure SQL Veritabanı 12,00 *130 140, 130, 120, 110, 100
SQL Server 2016 13,00 130 130, 120, 110, 100
SQL Server 2014 12,00 120 120, 110, 100
SQL Server 2012 11,00 110 110, 100, 90
SQL Server 2008 R2 10,00 100 100, 90, 80
SQL Server 2008 10,00 100 100, 90, 80
SQL Server 2005 9,00 90 90, 80
SQL Server 2000 8,00 80 80

 

*Not: Azure SQL veritabanları 12 aralık 2014 de piyasaya sürülmüştür. İlk piyasaya sürüldüğünde compatibility level’i 120 olarak ayarlanmıştır fakat 2015 de  yeni veritabanı oluşturulduğunda default’u 130 olarak gelmektedir.

Availability Group da Bulunan Primary Node’un En Son Backupının  Ne Zaman Alındığını Görmek

Availability Group da Bulunan Primary Node’un En Son Backupının Ne Zaman Alındığını Görmek

Always-On yapısını kullanıyorsanız ve sadece o instance üzerinde ki aktif veritabanlarının son  backuplarının ne zaman alındığını görmek istiyorsanız aşağıda ki scriptten faydalanabilirsiniz.

 

Veritabanı Adını Değiştirmek

Veritabanı Adını Değiştirmek

Veritabanın adını değiştirmek için  farklı yöntemler var.

En basit yöntem olarak SSMS(SQL Server Management Studio) üzerinden değiştirmek fakat veritabanı üzerinde session veya lock varsa veritabanı ismini değiştiremezsiniz. Bu yöntemi kullanmak istiyorsanız sp_who yardımı ile sorgulara bakarak  sessionları kill edip veritabanı ismini değiştirebilirsiniz.
Bununla ilgili Rename Failed isimli makalemden yararlanabilirsiniz.

Diğer bir yöntem ise  aşağıda ki gibi veritabanını single_user mode’a çekerek veritabanı üzerinde ki sorguları otomatik olarak kill etmiş oluyorsunuz   veritabanı ismini değiştirerek multi_user’a tekrar çektiğinizde veritabanı adı değişmiş oluyor.

 

*Not: Veritabanı failover cluster ,availability group,Log Shipping gibi  mimarileri kullanıyorsa yukarıdaki  veritabanı ismini değiştiremezsiniz.

SQL Anlık Sorguları Görmek

SQL Anlık Sorguları Görmek

 

DBA olarak anlık sorguları görmek isteriz . Aşağıda ki sorgu da sorgunun ne kadar sürdüğünü, locklanıyorsa hangi session_id ile locklandığını ,sorgunun bekleme tipini ve  hangi makineden geldiği gibi bilgileri bu sorgu yardımı ile görebiliriz.

 

 

SQL Server Analysis Service Port Değiştirirken Alınan Hata(The service cannot be started: The following system error occurred:  Only one usage of each socket address (protocol/network address/port) is normally permitted.  The following system error occurred:  Only one usage of each socket address (protocol/network address/port) is normally permitted. )

SQL Server Analysis Service Port Değiştirirken Alınan Hata(The service cannot be started: The following system error occurred: Only one usage of each socket address (protocol/network address/port) is normally permitted. The following system error occurred: Only one usage of each socket address (protocol/network address/port) is normally permitted. )

SQL Servisinin Başlamama Sorunu” isimli makalemdeki farklı servislerin aynı portu kullanmasından dolayı aldığımız hata mesajı  burda da karşıma çıkıyoruz  fakat oradaki çözümden farklı bir yol izleyeceğiz.


Servisi başlatırken yukarıdaki gibi hata ile karşılaşırsanız  event viewer dan application kısmında ki loglar incelemeniz gerekir.

Yukarıda ki sorunun  sebebi iki instancen aynı portu kullanmak istemesidir. Bundan dolayı instancen portu değiştirmemiz gerekmektedir. SSMS üzerinden değiştiremeyiz çünkü bağlanmaya çalıştığımızda servis durduğu için bağlanamazsınız bundan dolayı da  aşağıda ki path de bulunan msmdsrv.ini dosyasının içinde ki port yazan kısmı  değiştirmemiz gerekiyor.

Yukarıda ki değişikliği yaptıktan sonra servisi başlatarak bağlantı kurabilirsiniz.

SQL Servisinin Başlatılamaması(The request failed or the service did not respond in a timely fashion.Consult the event log or other applicable error logs for details.)

SQL Servisinin Başlatılamaması(The request failed or the service did not respond in a timely fashion.Consult the event log or other applicable error logs for details.)


Servisi başlatırken yukarıda ki hata alıyorsanız bunun sebeplerinden birisi port’un farklı bir uygulama tarafından  kullanılıyor olmasıdır. Bu sorunu çözmek için  eğer server da birden fazla instance varsa bunun konfigurasyonu sırasında iki instance aynı portu vermiş olabilirsiniz .1434 ‘ü ilk tanımlandığınız servis açılır fakat diğer servis açılırken yukarıda ki gibi hata verir.
İşletim seviyesinde(Event  viewer) logları incelediğimizde aşağıda ki gibi hata mesajı döner.

SQL Server Configuration Manager dan  hangi instance’ın hangi veritabanını kullandığını bulamadıysak aşağıda ki komutu kullanarak 1434 portunu kullanan ip’leri görebiliriz.

Yukarıdaki komut iki farklı değer döndürüyorsa  listening yazan   kullanılan porttur diğeri ise boş olan porttur.  Boş olan portun spid’sini aşağıda ki gibi kill ederek sorunu çözebilirsiniz.

 

Theme: Overlay by Kaira Extra Text
Cape Town, South Africa