Tips && Tricks

  • SQL Server varsayılan port olarak 1433 numaralı portu kullanır. Ancak bu çok yaygın bilinen bir bilgi olduğu için veritabanı saldırılarına önlem olarak bazen DBA’ler tarafından değiştirilebilir.
  • SQL Server, Always On, Cluster gibi kurulumları kendi domain hesabımızla yapmak daha sonra problem çıkartabilir. Sadece bu kurulumlar için kullanılacak, “password never expire” modunda oluşturulmuş, işletim sistemine oturum açmayan ve “local admin olmayan” hesaplarla yapılması önerilir.
  • SQL Server veriyi diskte tutmak ve yönetmek için extent denilen yapıları kullanır. Bir extent 8 page’den oluşur. Her bir page 8 kb’dır ve extent 64 kb boyutundadır. Bu yüzden SQL Server’ın kullanacağı diskleri 64K ile biçimlendirmek önerilir.
  • SQL Server güncellemeleri ve versiyonları hakkında https://buildnumbers.wordpress.com/sqlserver/ sitesinden bilgi alabilir. İhtiyacınız olan paketleri yükleyebilirsiniz.
  • Transaction Log’un truncate edilmesinin tek yolu transaction log yedeği almaktır. Backup almak ne kadar süre alıyorsa o periyotta yedek alınması önerilir.
  • Veritabanınızla ilgili güvenlik açıklarına dair Veritabanı >> sağ tuş >> Tasks >> Vulnerability Assessment >> scan for vulnerabilities menüsünden bilgi edinebilirsiniz.
  • Backup history msdb sistem veritabanında (backupfile, backupset tabloları) tutulur. Alternatif olarak veritabanı sağ tuş à Reports àStandard Reports >> Backup and Restore Events menüsünden de bilgi alınabilir.
  • Backup özelliklerinde “compressed backup” özelliğinin varsayılan olmasını sağlamak için sunucu özelliklerinde, database settings menüsünden seçim yapılır.
  • Veritabanı özelliklerinden son alınan backup tarih ve saat bilgisi görülebilir.
  • Transaction Log’u sanki backup almış gibi truncate edebilmek için şu kod kullanılabilir : “backup log db to disk = ‘NUL’ “. Buradaki NUL ifadesinin NULL ifadesiyle ilgisi yoktur. Unix’teki \dev\nul gibi bir device ismidir. Ancak üzerine yedek alınması mümkün değildir ve sistem backup almış gibi davranır ve log truncate edilir. Ancak bu çözüm transaction log’un kontrolden çıktığı ve veritabanının durması gibi acil durumlarda kullanılabilecek olan bir çözümdür. Normal şartlarda kullanılması önerilmez.
  • DBCC LOGINFO komutu sonucunda status alanında “2” değeri görüyorsak o vlf lerin kullanımda olduğunu ve o logda truncate işlemi yapılabileceğini düşünürüz. Log yedeği alıp tekrar baktığımızda status alanındaki 2 rakamlarının büyük oranda kaybolduğunu görürüz.
  • SQL Server’da sunucu düzeyinde en yetkili rol sysadmin, veritabanı düzeyinde en yetkili rol db_owner’dır. Oluşturacağımız kullanıcının yönetici yetkileri olmayacaksa db_reader ve db_writer yekileri yeterli olacaktır. Üst seviyeden yetkilendirme yaptıysak (db_owner gibi) alt seviye yetkileri (db_reader, db_writer vb.) yetkileri vermeye gerek kalmaz.
  • SSMS de cmd komutları çalıştırabilmek mümkündür. Bunun için xp_cmdshell in açılması gerekir. Aşağıdaki şekilde yapılabilir. Ancak bu özelliği açmak ciddi güvenlik riskleri ortaya çıkarır. Dikkatli olunması gerekir. Sysadmin yetkisine sahip kullanıcı xp_cmdshell yardımıyla sisteme ciddi zarar verebileceğinden sysadmin yetkisinin kimseye verilmemesi önemlidir.
    exec sp_configure ‘show_advanced_options’, 1
    reconfigure
    exec sp_configure ‘xp_cmdshell’, 1
    reconfigure
  • Yeni bir veritabanı oluşturduğumuzda sistem veritabanlarından olan model veritabanı temel alınır. Oluşturacağımız veritabanlarına dair özellikleri baştan model veritabanı ile belirleyebiliriz.
  • Oluşturduğumuz bakım planları, job’lar msdb veritabanında tutulur. Bir felaket durumunda bunları kaybetmemek için mutlaka yedeği alınmalıdır.
  • Oluşturduğunuz Job’ların hangilerinin şu anda çalıştığını görmek için View >> Object Explorer details menüsünü kullanabilirsiniz. SQL Server Agent >> Jobs altında job larınızın mevcut durumu görüntülenir.
  • Backup/Restore işlemlerinden sonra indexler bozulmaya uğrar. Bu yüzden index bakımını bu işlemlerden sonra yapmakta fayda vardır. Bazı kaynaklarda farklı rakamlar yazsa da genelde fragmantasyon oranı %30 ve üzeri olan index için rebuild işlemi yapılır. %10 ve %30 arası fragmantasyon varsa reorganize işlemi yapılır. Küçük tablolarda defragmantasyon yapmak performans getirisi sağlamaz. Defragmantasyon yapılacak tablonun 1000 page üzerinde olması önerilir.
  • Rebuild işlemi tüm index verisini tekrardan oluşturur. Bu işlem online yapılır. Bu sebeple fazla disk alanı gerektirir. Online rebuild işlemi enterprise versiyonda mümkündür. Yoksa offline yapılır. Rebuild işleminden sonra istatistikler otomatik olarak güncellenir.
  • DBCC CHECKDB çok fazla I/O kullanabilen bir komuttur ve tempdb performansını çok etkiler. Bu komutu çalıştırdığımızda veritabanında bozulmalarla karşılaşırsak önerilen en tutarlı yol yedekten geri dönmektir.
  • Sisteminizde kurulu SQL Server bileşenlerini görmek için başlat menüsünde “SQL Server Installation Center” uygulamasını açıp tools menüsü altında “Installed SQL Server features discovery report” linkini tıklayabilirsiniz.
  • SQL Server kurulurken Instance’a isim verilmezse varsayılan olarak sunucu ismini alır. Bu isim “case sensitive” değildir. “DEFAULT” kelimesi isim olarak seçilemez ve en fazla 16 karakter uzunluğunda olabilir.
  • SQL Server instance’ı her restart edildiğinde mevcut error log sonlandırılır ve errorlog1 adını alır, mevcut errorlog1 dosyası errorlog2 adını alır. Belirlenen dosya sayısı limitine kadar bu böyle devam eder.Varsayılan sayı 6 dır. Bu süreç sp_cycle_errorlog prosedürüyle servisi restart etmeden de yapılabilir.
  • Bir tablo için ancak bir tane full text index oluşturulabilir.
  • Bir kullanıcının disabled ya da enabled olduğunu sys.server_principals view’ından sorgulayabilirsiniz
  • SSMS de sunucu üzerine sağ tuşa basıp Activity Monitor’ü açtığımızda Processes tabında suspended modundaki işlemleri görmek mümkündür.
  • MSDB veritabanındaki dbo.backupset tablosundan alınan yedeklere dair bilgi alınabilir.
  • Sistem veritabanlarında bir bozulma oluşursa ya da sistem collation ayarını değiştirmek istersek bu veritabanlarını rebuild yapabiliriz. Ancak bu işlem sonunda kullanıcıya ait değişiklikler kaybedilir. Msdb veritabanındaki hob lar gibi.
  • Veritabanında yüksek miktarda verinin bulunduğu bir tablodan büyük boyutlarda veri veri silerken “lock escalation” ismi verilen durum ortaya çıkabilir. Bu durum aynı tabloyu kullanan diğer uygulamaların bu işlem bitmeden tabloya erişebilmesine engel olur. Bu işlem SQL Server’ın aslında satır ya da page bazında lock’ları daha kolay yönetmek için tablo bazında lock işlemine çevirmesidir.
  • Her checkpoint işleminde, SQL Server cache’i tarar ve bütün “dirty page’leri diske yazar. Dirty Page SQL server bir veriyi diskten okuduktan sonra değişmiş olan veridir. Cache’deki veri ile diskteki veri farklıdır.
  • Deadlock oluştuğu sırada SQL Server transaction’lardan birini seçip rollback yapar. SQL Server profiler’da yeni trace oluştururken “TSQL_Locks” ile lock’lar izlenebilir.
  • DAC (Dedicated Admin Connection), SQL Server’a bağlanma problemleri yaşadığımız, istemcilerin bağlanamadığı sıradışı durumlarda bir arka kapı bağlantısı yapmamızı sağlayan bir özelliktir. Veritabanına bağlanıp, mevcut problemi anlamaya çalışmak için sorgular çalıştırmamızı sağlar. Varsayılan olarak sadece lokal bağlantılara izin verir. Uzak yönetici bağlantısı için sp_configure prosedürüyle uzak yönetici bağlantısına izin verilmesi gerekir.Bu konu hakkında detay bilgi için şu sayfaya göz atabilirsiniz.
  • SQL Server loglarının çok büyümesini engellemek için, SQL Agent’ın özelliklerinden “include execution trace messages” seçeneğini kapatmak faydalı olacaktır. Bu özelliği sadece Agent ile ilgili problemleri araştırırken açmak önerilir.
  • SQL Server’ı “single user mode” ile başlatmak, sunucudaki lokal yönetici hesaplarının veritabanında sysadmin yetkileriyle oturum açmasını sağlar.
  • Restore işlemleri esnasında backup dosyalarımızın olduğu klasör boş görünüyorsa, o klasöre servis hesabının izinli olarak eklenmesi gerekir.
  • xp_msver komutu SQL server versiyonu ve üzerinde çalıştığı sunucu hakkında bilgiler verir.
  • Proxy account bir job adımının çalışırken servis hesabı dışında biaşka bir hesapla çalışmasını sağlayan bir yapıdır. Proxy account’un bir de yetkili bir kullanıcı adı ve şifresini saklayan credential nesnesi vardır.
  • Veritabanınızdaki güvenlik açıklarını Veritabanı >> sağ tuş >> tasks >> vulnerability assessment menüsünden tespit edebilirsiniz
  • Veritabanınızın mevcut konfigürasyon ayarlarını şu komut yardımıyla öğrenebilirsiniz.
    USE master;
    GO
    SELECT * FROM sys.configurations;
    GO
  • Bir veritabanını yeni versiyon bir instance’a restore ya da attach ettiğinizde, siz değiştirmedikçe database compatibility level değişmez. Database özelliklerinden değiştirmek zorundasınız.
  • Bir login silindiğinde ya da bir veritabanı yeni bir instance’a taşındığında login ile ilişkili “database user” orphaned (yetim) statüsüne düşer. sp_change_users_login sistem prosedürüyle bu kullanıcılar öğrenilebilir ve bir login’e atanabilir.
  • SQL Server backup dosyalarında da , data ve log dosyalarında da (mdf, ndf, ldf) farklı uzantılar kullanılabilir. Ancak, örneğin primary data file için mdf uzantısı önerilmektedir.
  • Master veritabanı zarar görürse SQL Server başlamaz. Bu yüzden düzenli yedeğinin alınması önerilir. Aynı şekilde model veritabanı da hazır bulunmadığı sürece SQL Server başlamaz.
  • Msdb veritabanı bakım planları, job’lar, operatörler vb. SQL Agent tarafından yürütülen bir çok iş ve objeyi tutar. Bu yüzden yedek alınması önerilir.
  • Management Studio’da gördüğümüz dört sistem veritabanı haricinde bir görünmeyen resources sistem veritabanı vardır. Sistem objelerini tutar. Detaylı bilgi için şu yazıya bakabilirsiniz.
  • Veritabanı dosyalarının diskte ne kadar yer tuttuğuna dair sys.dm_db_file_space_usage dmv’sini sorgulayabilirsiniz.
  • Buffer Pool Extension buffer pool’u kalıcı disklere extend etmek(genişlertmek) için kullanılan bir disk alanıdır. SSD disk kullanılması hem fiyat hem performans açısından önerilir. Disk bozulmalarında veri kaybı yaşanmaması için Buffer Pool Extension alanında commit edilmiş veri tutulur. Dirty page dediğimiz yapılar tutulmaz. Sisteminizde aktif olup olmadığını aşağıdaki dmv’yi sorgulayarak öğrenebilirsiniz. sys.dm_os_buffer_pool_extension_configuration
  • DBCC CHECKDB komutu, kontrol edilen veritabanıyla aynı disk bölümünde gizli dosyalar oluşturur. Bu yüzden veritabanının olduğu bölümde yeterli boş alan olması gerekir. Tutarlı verinin yedeğini aldığımız bilgisini bize vereceği için DBCC CHECKDB komutunu cyedek almadan önce çalıştırmak tavsiye edilir.
  • 7/24 çalışan sistemlerde DBCC CHECKDB komutunu aktif veritabanında değil de, en son yedeğin yüklendiği test veritabanında ya da always on kullanıyorsak ikincil veritabanında çalıştırmak performans açısından daha iyi olacaktır.
  • İndex’lerin fragmantasyon durumlarını sys.dm_db_index_physical_stats DMV’sinden avg_fragmentation_in_percent kolonundan gözlemleyebilirsiniz. SSMS’de de bu bilgiye erişmek mümkündür.
  • SQL Server’da veritabanı şu durumlardan birinde bulunur: ONLINE, OFFLINE, RESTORING, RECOVERING, RECOVERY PENDING, SUSPECT, EMERGENCY. Bu durumların ne anlama geldiğini şu yazıdan öğrenebilirsiniz.
  • Veritabanımızın iş yükünü (data ve log için I/O miktarı) dm_io_virtual_file_stats dmf’sini sorgulayarak öğrenebiliriz. Parantez içindeki iki parametreyi NULL girerek tüm veritabanlarına dair sonuç alabiliriz.
    SELECT * FROM sys.dm_io_virtual_file_stats (database_id, file_id );
    GO
  • Veritabanın database_id değerini SELECT DB_ID(N’database_name’) AS [Database ID] sorgusuyla bulabiliriz.
  • Veritabanı her büyümede işletim sisteminden alan istediğinde, performans kaybı oluşmaması için auto growth boyutunun makul verilmesi önemlidir. Duruma göre değişebilmekle birlikte genel best practice öneri data file boyutunun sekizde biri kadar artış vermektir.
  • Always On ortamında secondary sunucu backup almak isterse, primary sunucuya bunu bildirir. Primary sunucu, birden fazla secondary sunucunun aynı anda backup almasını engellemek için veritabanını BulkOp adı verilen mekanizma ile kilitler ve bu durumu ikincil sunucuya bildirir
  • Sql Server instance’ının “Locked memory model” de çalışıp çalışmadığını Error Log’un başında şu cümle varsa anlayabiliriz: “Using locked pages in the memory manager”
  • Alınan başarılı yedeklerin log oluşturmasını engellemek için 3226 numaralı tracel flag’i açabiliriz
  • SQL Server içerisinde mevcut bulunan mevcut stored prosedür’lerin listesini almak için “exec sp_help” yazıp çalıştırabilirsiniz