SQL Server Veritabanı Yöneticisinin Yol Haritası

Bu makalede sql server veritabanı yöneticisinin yapması gereken işlemleri madde madde belirterek her maddenin nasıl yapıldığıyla ilgili makalelere link vereceğim. Bu şekilde yeni veritabanı yöneticisi adayları için bir rehber olmasını hedefliyorum.

1. İşletim Sistemi Logları ve SQL Server logları her gün kontrol edilmeli ve sıradışı bir hata varsa müdahale edilmelidir. “İşletim Sistemi ve SQL Server Log’larını Kontrol Etmek” isimli makalede detayları bulabilirsiniz.
    
2. Schedule edilmiş jobların doğru çalışıp çalışmadığı kontrol edilmelidir. Job’lar hata alırsa veritabanı yöneticilerine mail atacak şekilde konfigüre edilmelidir. “Hatalı Biten Job’ları Mail Attırmak” isimli makaleyi okumak isteyebilirsiniz.
    
3. Backuplar sorunsuz bir şekilde alınmış mı kontrol edilmelidir. Backup’ların doğru alınıp alınmadığını kontrol edip veritabanı yöneticilerine mail atacak script job olarak tanımlanmalıdır. “Yedeği Alınmamış Veritabanlarının Mail ile Bildirilmesi” isimli makaleden faydalanabilirsiniz.
    
4. Backuplar mutlaka farklı bir lokasyona alınmalı ya da alındıktan sonra taşınmalıdır. Çünkü sunucu erişilemez bir hale gelirse backup’larınıza farklı bir kaynak üzerinden ulaşıp yeni bir ortama restore işlemi yapabilmeniz gerekir. 
    
5. Acil durumlarda hızlıca backuptan dönebilmek için mutlaka bir geri dönüş planı hazırlanmalıdır ve mutlaka ay da en az 1 kere geri dönüş testi yapılmalıdır. Backup ve Restore hakkında detaylı bilgi için sitemizdeki arama kısmında Backup ya da Restore ifadeleriyle ilgili makaleleri aratabilirsiniz.
    
6. Veritabanının yer sıkıntısı yaşamaması için diskler düzenli olarak kontrol edilmelidir. Hatta disklerin doluluk oranını kontrol eden bir script’i düzenli olarak dba’lere mail atacak bir job schedule edilmelidir. İlgili script’e “Disklerdeki Boş Alanların Veritabanı Yöneticilerine Mail ile Bildirilmesi” isimli makaleden ulaşabilirsiniz.
    
7. Gün boyunca sistem monitör edilerek performans kontrol edilmelidir. Birbirini lock’layan sorgular  ya da uzun süren sorgular var mı incelenmelidir. Anlık sorguları izleyebilmek için “SQL Server’a gelen anlık sorguları çeşitli filtrelerle listelemek” isimli makaleyi, veritabanında yavaşlık talebiyle size gelindiğinde sadece ilgili veritabanı için uzun süren sorguları izlemek için de “SQL Server Profiler Kullanarak Uzun Süren Sorguları Bulmak ve Tablo Olarak Kaydetmek”  ya da “Extended Events Kullanarak Performans Monitoring Yapmak” isimli makalelerden okuyabilirsiniz.
    
8. Potansiyel problemler için alert oluşturulmalı ve gerektiğinde soruna anında müdahale edilebilmesi için veritabanı yöneticilerine mail gidecek şekilde sistem konfigüre edilmelidir. Gerekli alertleri oluşturabilmek için “Yeni Kurulumda Yapılması Gereken Konfigürasyonlar” isimli makalemde belirttiğim script’i çalıştırabilirsiniz. Sitemizin Arama kısmına alert yazarsanız alert’ler ile ilgili diğer makalelere de erişebilirsiniz.
    
9. Veritabanı kullanım amacına ve ihtiyaçlara uygun özelliklerde yaratılmalıdır. Veritabanı oluşturmak sağ tık değildir. Doğru veritabanı dizayn’ı için “Veritabanı Oluşturmak Deyip Geçmeyin!” isimli makaleyi okumanızı tavsiye ederim.
    
10. Üretim ortamını upgrade etmeden önce, test ortamında bu işlem gerçekleştirilmelidir. Upgrade sonrası mutlaka uygulamaların doğru çalıştığından emin olunmalıdır. Ben upgrade işlemlerini genelde yeni bir instance kurarak yaparım. Kurduğum yeni instance’a veritabanlarını teker teker aktararak önce testlerini gerçekleştiririm. Bu şekilde, testler’de bir problem meydana gelirse hızlı bir şekilde eski instance üzerindeki veritabanını ayağa kaldırarak riskleri minimum’a indirgerim. Herkesin böyle bir  şansı olmayabilir. Eğer böyle bir şansınız yoksa mutlaka kendinize bir geri dönüş senaryosu hazırlamalı ve bu senaryoyu test etmelisiniz. Yeni kurulumla ilgili detaylı bilgi almak için “SQL Server Kurulumu” isimli makaleden faydalanabilirsiniz.
     
11. Veritabanı sunucuları fiziksel olarak güvenli bir ortamda tutulmalıdır. Sunucuların rack server olmasını tavsiye ederim. Çünkü blade sunucularda bir problem olduğunda(ki birkaç kez problem olduğunu gördüm) high availability(yüksek erişilebilirlik) bir işe yaramıyor.
     
12. Veritabanı sistemlerinizde mutlaka HA(High Availaiblity/Yüksek Erişilebilirlik) çözümlerinden birini kullanın. Bu şekilde beklenmedik sunucu hatalarının, disk hatalarının önüne geçebilirsiniz. Ayrıca sistemlerinizde yapacağınız upgrade yada sunucu bakım işlemlerini kesinti olmadan yapabilirsiniz. Ben always on’u tercih ve tavsiye ederim. HA(High Availaiblity/Yüksek Erişilebilirlik) çözümleri hakkında detaylı bilgi almak için sitemizde MSSQL menüsünden HA(YÜKSEK ERİŞİLEBİLİRLİK) & DR(FELAKET KURTARMA) sekmesine tıklayarak ilgili makalelere erişebilirsiniz. Özellikle ilk defa bu çözümleri öğreneceksiniz ilk etapta karşılaştırma makalesi olan “SQL Server Failover Cluster, Database Mirroring, Always ON,Replication ve Log Shipping Farkları” isimli makaleyi okumanızı tavsiye ederim.
     
13. Veritabanı sunucuları ve uygulama sunucuları aynı vlan’da olmamalıdır! Aynı Vlan’da olursa uygulama sunucuları ile arasında port kısıtlaması yapılamaz. Bu yüzden güvenli olmayacaktır.
     
14. Veritabanı sunucuları ve uygulama sunucuları arasında mutlaka firewall olmalıdır. Bu firewall üzerinden sadece gerekli portlar’a izin verilmelidir. Bütün network trafiği açık olmamalıdır. Örneğin veritabanı sunucusu 1433 portun’dan hizmet veriyorsa, uygulama sunucusu veritabanı sunucusuna sadece 1433 portundan erişebilmelidir.
     
15. Veritabanına ulaşan sysadmin sayısı minimize edilmelidir. Yetkilerle ilgili detaylı sonuçları veren script’e “SQL Server’da Tüm Yetkilendirmeleri Listelemek” isimli makaleden ulaşabilirsiniz.
     
16. Kullanıcılara sadece ihtiyaçları kadar yetki verilmelidir. Eğer uygulama sadece read,write ve execute yapacaksa db_owner hakkı verilmemelidir. Çünkü db_owner olan biri aynı zamanda backup’ta alabilir. Backup’ı alan uygulamacı hangi diskte ne kadar yer olmadığını bilmediği için sisteminizi çökertebilir. Bu konuyla ilgili “Loginlerin Owner Oldukları Veritabanında Backup Almasını Engellemek” isimli makaleyi okuyabilirsiniz.
     
17. Kullanıcıların veriye direk ulaşmasına izin vermek yerine, mümkünse stored procedure veya view gibi nesneler üzerinden yetkilendirmek daha sağlıklı olacaktır. Stored Procedure ve view’ler ile ilgili sitemizde detaylı bilgiler bulabilirsiniz. Arama kısmına anahtar kelimeleri(Stored Procedure, View, Indexed View vb.) yazarak erişebilirsiniz.
     
18. Tüm veritabanı kullanıcıları için güçlü şifre kullanma kriterleri oluşturulmalıdır. Windows üzerindeki policy’lerle güçlü şifre kullanımı garanti altına alınmalıdır. “secpol.msc(Security Policy SQL Server Ayarları)“, “SQL Server Parola Politikası” ve “SQL Server Kullanıcı Locklama Politikası” isimli makalelerimde detaylı bilgiye ulaşabilirsiniz.
     
19. Uzun süredir login olmayan kullanıcılar sahibiyle irtibatlı bir şekilde silinmelidir. Logon Trigger kullanarak sql server’a bağlanan kullanıcıları bir tabloya aktaracak bir job oluşturabilirsiniz. “SQL Server Trigger Çeşitleri” isimli makalemde bu işlemin nasıl yapılacağını detaylı olarak açıkladım.
     
20. Veritabanı sunucusu kesinlikle internete açık olmamalıdır! Bu en temel güvenlik prensibidir ve olmazsa olmazdır.
     
21. Veritabanı sunucusuna lisanslı bir virüs programı yüklenmelidir. Virüs programına veritabanı dosyalarının olduğu path’ler için exception(virüs programı veritabanı file’larını izlememeli, diğer klasörleri izlemeli) tanımlanmalıdır. Eğer exception tanımlamazsanız veritabanınızın performansı yavaşlayacaktır.
     
22. Periyodik olarak bakım işlemleri gerçekleştirilmelidir. Bakım işlemleri ile ilgili “SQL Server Maintenance(OLA HALLENGREN)” isimli makaleyi okuyabilirsiniz. Ayrıca sitemizin arama kısmına ve Maintenance Plan yazarak bakım işlemleri ile ilgili diğer makalelere erişebilirsiniz.
     
23. Belirli aralıklarla instance üzerinde cpu’yu ve disk’i en çok kullanan sorgular tespit edilmeli ve gerekli iyileştirmeler yapılmalıdır. “CPU’yu En Çok Kullanan Sorgular” ve “Disk’i En Çok Kullanan Sorgular” isimli makalelerimden ilgili sorgulara erişebilirsiniz.
     
24. Sistemdeki eksik indexler belirli aralıklarla sorgulanmalı ve gerekirse oluşturulmalıdır. “Eksik Index’leri Tespit Etmek” isimli makaleden faydalanabilirsiniz.
     
25. Kullanılmayan indexler ve tablolar uygulamacı ile irtibatlı bir şekilde kaldırılmalıdır. “Kullanılmayan Index’leri Tespit Etmek” ve “Kullanılmayan Tabloları Tespit Etmek” isimli makalelerden faydalanabilirsiniz.
     
26. İhtiyaç fazlası indexler create edilmemelidir. Örneğin tabloda 4 kolon var ve 3 kolon için index oluşturulması isteniyor. Bu zaten tabloyu yeniden oluşturmakla aynı şey sayılır. Böyle bir index oluşturulmamalıdır. Ayrıca fazla sayıda index tanımlanmamalıdır. Fazla index tanımlanırsa tabloya gelen insert, update ve delete’ler yavaşlayabilir. Index tanımlamadan önce indexler hakkında detaylı bilgi almak için “SQL Server’da Index Kavramı ve Performansa Etkisi” ve “SQL Server’da İstatistik Kavramı ve Performansa Etkisi” isimli makaleleri okumanızı tavsiye ederim.
     
27. Her tabloda mutlaka bir primary key tanımlanmalı ve bu primary key en çok kullanılan integer ve unique bir kolon üzerinde olmalıdır. Bu şekilde tanımlanmayan tablolar tespit edilip uygulamacıya bildirilmelidir. “Primary Key ve Foreign Key” ve “Primary Key ve Unique Constaint’in farkları” isimli makalelerden faydalanabilirsiniz.
     
28. Kendini sürekli tekrar eden sorgular için Select’teki, where’deki, joinde’ki bütün kolonlar index üzerinde tanımlanabilir. Bu şekilde sorgu tablo üzerindeki gerçek dataya hiç erişmeden index üzerinden ihtiyacını karşılayarak I/O’yu azaltacak ve performansı artıracaktır. Bu tip index’lere covering index denir. Ayrıca ORDER BY, GROUP BY ifadelerine de bakmak gerekir.  Detaylar için aşağıdaki makaleleri okumanızı tavsiye ederim.
    

    “SQL Server’da Index Kavramı ve Performansa Etkisi” isimli makaleden faydalanabilirsiniz.

    “Index Oluştururken Sorgudaki Order By Yönüne Bakmak(ASC,DESC)“

    “Index Oluştururken JOIN Yapılan Kolonlara Dikkat Etmek“

    “Index Oluşturuken GROUP BY İfadesindeki Kolona Dikkat Etmek“
    

29. Tablolarda kolonların boyutlarını belirlerken büyüklüğüne dikkat edilmelidir. Gereğinden büyük boyutlar gereksiz I/O ‘ya sebep olacaktır. Doğru veri tipleri tablonun gereksiz büyümesini engelleyecektir. “SQL Server Veri Tipleri” isimli makaleden faydalanabilirsiniz.
     
30. Query Hint’i uygulamadan önce yaptığınız işlemin istediğiniz sonucu verdiğinden emin olmanız gerekir. Çünkü query hint kullanarak SQL Server’ı normal davranışından uzaklaştırarak istediğiniz şekilde hareket etmeye zorlamış oluyorsunuz. Kullanılan query hint performansı artırabilir fakat azaltabilirde. Bu yüzden tam olarak sonuçlarını test etmeden query hint kullanılmamalıdır.

    Microsoft query hint’leri için şöyle bir uyarı veriyor:

    SQL Server genellikle en iyi execution plan’ı seçtiği için sadece son çare olarak query hint’leri kullanın.

    Query Hint’ler hakkında bilgi almak için “SQL Server Query Hint Kavramı ve Bazı Query Hint’ler” isimli makaleyi okumak isteyebilirsiniz.

    
    

31. Uygulama, veritabanına transaction gönderme ihtiyacı hissettiğinde bu sql ‘i stored procedure içine yerleştirmek daha faydalıdır. “Sp(Stored Procedure) Nedir” isimli makaleyi okuyabilirsiniz. Bazen stored procedure’lerde parameter sniffing meydana gelir. Çözümü için “Parameter Sniffing” isimli makaleyi okuyabilirsiniz.
     
32. UNION ifadesini kullanırken tekrar eden kayıt olup olmadığına bakılmalıdır. Çünkü UNION tekrar eden satırları tek satıra düşürür. Eğer sonuç kümesinde tekrar eden kayıtlar varsa ve uygulamanın tekrar eden kayıtlara ihtiyacı yoksa UNION kullanılabilir, aksi takdirde UNION ALL kullanmak gerekecektir. UNION ve UNION ALL ifadelerinin kullanımı ve detayları için “UNION ve UNION ALL” isimli makaleyi okumak isteyebilirsiniz.
     
33. Select ifadesini kullanırken sadece ihtiyaç duyulan kolonlar çekilmelidir. Bazı uygulamacılar select * from tablo şeklinde bütün kolonları çekiyorlar ve bu gereksiz I/O ve performans kaybına yol açıyor.
     
34. Select ifadesine ihtiyaca göre mutlaka where filtresi eklenmeli. Filtre eklendiğinde sadece ihtiyaç duyulan satırlar gelecek ve gereksiz I/O yapılmayacaktır. Ayrıca filtreli sorgulara index ekleyerek sorgunun gelme süresini minimuma indirebilirsiniz.
     
35. Sorgularınızda Where ifadesini kullanırken “<>”, “!=”, “!>”, “!<“, “NOT IN”, “NOT LIKE” gibi olumsuz ifadeler mümkünse kullanılmamalıdır. Çünkü bu ifadelerle yazılmış bir sorgu index’i kullanmak yerine table scan’a sebep olabilir. Örneğin NOT IN yerine LEFT JOIN  yaparak, where koşulunda ikinci tablodan null olanlar gelsin diyebilirsiniz ya da !> yerine <= kullanabilirsiniz.
     
36. SQL Server kurulumu sonrasında doğru konfigürasyonun yapılması gerekir. “Yeni Kurulumda Yapılması Gereken Konfigürasyonlar” isimli makaleyi okumak isteyebilirsiniz.
     
37. Uygulama içersinde şifre girilmemesi ve uygulama kullanıcısı dışındaki kullanıcıları audit ile izleyebilmek için uygulama sunucularını login olarak tanımlayabilirsiniz. “Login olarak Server Tanımlamak” isimli makalede detayları bulabilirsiniz.
     
38. Mutlaka uygulama kullanıcısı dışındaki kullanıcıları audit ile izlemelisiniz.”SQL Server Audit Oluşturmak” isimli makalede detayları bulabilirsiniz.
     
39. Her veritabanı yöneticisi SSMS’e ya da veritabanı sunucusuna bağlanamadığında DAC ile veritabanına bağlanma yöntemini bilmelidir. “DAC(Dedicated Admin Connections)” isimli makalede detayları bulabilirsiniz.
     
40. Her veritabanı yöneticisi zor durumlarda mutlaka cmd komut satırından sql server’a bağlanmayı bilmelidir. “SQL Server’a cmd komut satırını kullanarak bağlanmak” isimli makale ilginizi çekebilir.
     
41. Always On kullanıyorsanız mutlaka alert sisteminiz olmalı. Always On ile ilgili alert kurulumu için “Always On Alert Sistemi” isimli makaleden faydalanabilirsiniz.
     
42. Veritabanı oluştururken herhangi bir değişiklik yapmazsanız, veritabanınız kurulumda yaptığınız path’ler de oluşur. “Veritabanı oluşurken data ve log file’ın oluşacağı default path’leri değiştirmek” isimli makale ilginizi çekebilir.
     
43. Veritabanının Recovery Model’i veritabanı yönetiminde kritik bir rol oynar. “Veritabanı Recovery Modelleri” ve “Veritabanı Recovery Model’ini Değiştirmek” isimli makaleleri okumak isteyebilirsiniz.
     

Aslında buradaki maddeler tabiki veritabanı yöneticisi olmak için yeterli değil. Ama başlangıç için iyi bir yol haritası olacağını düşündüm. Buradaki makaleleri okuduktan sonra sitemizdeki makaleleri sırayla takip etmenizi öneririm. Sitemizdeki tüm makaleler büyük sistemlerde karşınıza çıkan ya  da çıkabilecek senaryolardan oluşmaktadır.