SQL Server ACID Kuralları

ACID, ilişkisel veritabanı yönetim sistemlerinin(RDBMS) sağlaması gereken 4 ana kuraldır. İlişkisel veritabanları ve sql server hakkında daha detaylı bilgi almak için “SQL Server Nedir?” isimli makaleyi okumak isteyebilirsiniz.

ACID Kuralları:

Atomicity (Bölünmezlik): Ya hep Ya Hiç prensibini benimser. Bir transaction içersinde bir işlem fail ediyorsa tüm işlemler her durumda(sunucu kapanması , hata alınması) fail etmelidir.

Consistency (Tutarlılık): Transaction bitimine kadar, eğer  constraints, cascades, triggers gibi tanımlanmış kuralların ihlali gerçekleşirse veritabanındaki bütün veri transaction başlamadan önceki hali ile kalmalıdır.

Isolation (İzolasyon): Aynı anda aynı veri üzerinde birden fazla transaction değişiklik yapamamalıdır. Bir transaction bir alanda işlem yapıyorsa işlemi bitene kadar bu alan diğer transaction’lardan izole edilmelidir. SQL Server’da bir çok Isolation Level vardır. Default olarak Read Committed Isolation Level’i kullanır. Isolation Level’ler ile ilgili aşağıdaki makaleleri okuyabilirsiniz.

“Isolation Level 1“,

“Isolation Level 2“,

“Isolation Level 3“

Durability (Süreklilik): Eğer bir transaction başarılı bir şekilde gerçekleştiyse(commit edildiyse) bu veri sistem fail etse bile garanti altında olmalıdır. Örneğin bir update işlemini commit ettiniz tam o esnada sunucu kapandı. SQL Server Transaction Log dosyası yardımıyla bu özelliği sağlar. “SQL Server Transaction Log Nedir” isimli makaleyi okumak isteyebilirsiniz.

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.

Page Header ve İçeriği

SQL Server’da her page’in ilk 96 byte’lık bölümü page header olarak adlandırılır. Bu makalemizde page header içinde tutulan verileri detaylı olarak göreceğiz. Yapacağımız örnekleri birebir uygulamak için AdventureWorks2014 veritabanını sisteminize restore edebilirsiniz.

Page Header’ı incelemek için DBCC Page komutunu çalıştırıyorum. DBCC Page ile ilgili detaylı bilgiyi “SQL Server Page Yapısı ve DBCC Page” isimli makaleden okuyabilirsiniz. 

DBCC Traceon(3604)
 
DBCC PAGE('AdventureWorks2014',1,1248,2)

Bu sorgunun sonucunda Page içindeki bilgiler hexadecimal olarak görüntülenecektir. İlk 96 byte’lık yani 192 hexadecimal karakterlik alan Page Header kısmıdır.

Page Header’da bulunan bilgiler ve Page Header içerisindeki konumları şöyledir. Konumlara bakarken hexadecimal bilgileri 2’li gruplar halinde incelememiz gerekir.(2 hexadecimal 1 byte değerindedir) Bazı bilgiler 1 byte’dan büyük değerler almkatadır. Bu bilgilere ait 2’li hexadecimal grupları sağdan sola doğru okumamız gerekecektir. Üstteki resimde de görüldüğü üzere DBCC Page komutuyla gelen hexadecimal değerler 4’er byte olarak gruplandırılmış. Programlama mantığı gereği ilk veri 0. byte olarak adlandırılsa da, bu makalede 1-4. byte 5-8. byte olarak gruplandırarak anlatacağım.

1.Byte: m_headerVersion =1 (Hexadecimal=01) Page Header Versiyon Bilgisini verir. SQL Server 2000’den bir önceki versiyon olan 7.0’dan itibaren bu değer hep 1 olarak gelmektedir.

2.Byte: m_type =1 (Hexadecimal=01) Page tipini belirtir. Data Page için 1, Index Page için 2, IAM Page için 10 gibi farklı değerlere sahiptir.

3.Byte: m_typeFlagBits=0x0 (Hexadecimal=00) PFS page’ler dışında bu bilgi 0 olarak gelmektedir. Ancak eski versiyonlarda data ve index page’ler için 4 değerini almaktadır.

4.Byte: m_level=0 (Hexadecimal=00) Data Page için 0, Intermediate ve Root Level Page’ler için kaçıncı seviyede olduklarını belirten değeri almaktadır.

5-6. Byte: m_flagbits=0x200 (Hexadecimal=00 02) Bu bilgi 2 byte’lık veriye sahip olduğu için okuma işlemini sağdan sola doğru 02 00 olarak yapmamız gerekecektir. m_flagbits, o page’deki flag’lerin bilgisini verir. Mesela 0x200 ifadesi Checksum kullanıldığını, 0x100 ifadesi ise Torn Page Detection kullanıldığını belirtir.

7-8. Byte: m_indexID= 256 (Hexadecimal=00 01) 256 sayısının hexadecimal karşılığı 01 00’dır m_indexID, ilgili indexin gerçek değerini vermeyebilir. (Mesela bu örnekte Clustered Index olmasına rağmen 256 değerini almış) m_IndexID Allocation Unit ID ‘ye göre Page Header üzerinde tutulmaktadır.

9-12 Byte: m_PrevPage= 4913 (Hexadecimal=31 13 00 00) 4913 sayısının hexadecimal karşılığı 00 00 13 31 ‘dir. m_PrevPage ifadesi ilgili Page’den önceki PageID bilgisinin FileID kısmından sonrasını verir. Bu değer ilgili Page değerinden 1 eksik olmak zorunda değildir. O page üzerindeki Key değerine göre bir önceki verilerin bulunduğu page bilgisidir.

13-14. Byte: m_prevPage=1 (Hexadecimal 01 00) Hexadecimal ifadeyi 00 01 olarak okumamız gerekir. Bu bilgi bize bir önceki Page’in FileID’sini vermektedir.

15-16. Byte: pminlen=41 (Hexadecimal 29 00) 41 sayısının hexadecimal karşılığı 00 29’dur. Pminlen bize sabit uzunlukta olan kolonların toplam byte değerini verir.

17-20. Byte: m_nextPage =1249 (Hexadecimal e1 04 00 00) 1249 sayısının hexadecimal karşılığı 00 00 04 e1’dir. m_nextPage bilgisi bir sonraki Page’in ID’sini verir. Bu bilgide FileID bulunmamaktadır.

21-22. Byte: m_nextPage=1 (Hexadecimal 01 00) Bir sonraki Page’in FileID’si bulunmaktadır.

23-24. Byte: slotcnt= 5 (Hexadecimal 0500) İlgili Page’deki toplam kayıt sayısını verir.

25-28. Byte: m_objID=240 (Hexadecimal f0 00 00 00) 240 sayısının hexadecimal karşılığı 00 00 00 f0’dır. m_objID, Allocation Unit ID’ye göre olan Object ID değeridir. OBJECT_ID fonksiyonu ile gelen Metadata ObjectID ise lookup tablolarda tutulmaktadır.

29-30. Byte: m_freeCnt= 1252 (Hexadecimal e4 04) 1252 sayısının hexadecimal karşılığı 04 e4’tür. m_freeCnt, Page içindeki boş alanın byte değeridir.

31-32. Byte: m_freeData = 6930 (Hexadecimal 12 1b) 6930 sayısının hexadecimal karşılığı 1b 12’dir. m_freeData, ilk byte değerinden içi dolu olan son byte değerine kadar olan değeri verir.

33-36. Byte: m_pageID =1248 (Hexadecimal e0 04 00 00) 1248 sayısının hexadecimal karşılığı 00 00 04 e0’dır. İlgili Page’in ID değerini FileID olmadan verir.

37-38. Byte: m_pageID =1 (Hexadecimal 0100) İlgili Page’in FileID değerini verir.

39-40. Byte: m_reservedCnt=0 (Hexadecimal 00 00) Page üzerinde Active Transaction tarafından ayrılmış olan byte değerini verir.

41-44. Byte: m_lsn= 42 (Hexadecimal=2a 00 00 00) 42 sayısının Hexadecimal karşılığı 00 00 00 2a’dır. İlgili Page üzerinde yapılan son değişikliğe ait lsn bilgisinin ilk kısmını tutar.

44-48. Byte: m_lsn= 6456 (Hexadecimal=38 19 00 00) 6456 saysının Hexadecimal karşılığı 00 00 19 38’dir. İlgili Page üzerinde yapılan son değişikliğe ait lsn bilgisinin ikinci kısmını tutar.

49-52. Byte: m_lsn= 54 (Hexadecimal= 36 00 00 00) 54 sayısının Hexadecimal karşılığı 00 00 00 36’dır. İlgili Page üzerinde yapılan son değişikliğe ait lsn bilgisinin üçüncü kısmını tutar.

53-56. Byte: m_xdesID= 1545 (09 06 00 00) m_xdesID bilgisi, m_reservedCnt alanında son değişikliği yapan Internal ID değerini verir. m_xdesID’nin ikinci kısmı bu alandadır.

57-58. Byte: m_xdesID= 0 (00 00) m_xdesID’nin ilk kısmı bu alandadır.

59-60. Byte: m_ghostRecCnt= 0 (00 00) Ghost kayıt sayısını verir.

61-64. Byte: m_tornBits= 1868363382 (76 f6 5c 6f) 1868363382 sayısının Hexadecimal karşılığı 6f 5c f6 76’dır. m_tornBits, Veritabanı seçeneğine göre ya TornBit değerini ya da Checksum değerini verir.

Kalan 32 Byte’lık kısımda ise 0 değeri bulunmaktadır.

DBCC UPDATEUSAGE Nedir Ve Nasıl Kullanılır

DBCC UPDATEUSAGE Page ve row sayılarındaki hataları tespit eder ve düzeltir.

SQL Server 2005 öncesinde bazı tabloların ve index’lerin satır sayıları negatif gelebiliyordu. DBCC CHECKDB komutunu çalıştırdığınızda DBCC CHECKDB bu kontrolü yapar ve böyle bir durum varsa DBCC UPDATEUSAGE komutunun kullanılmasını tavsiye eder.

Aşağıdaki komut yardımıyla Test veritabanı için bu kontrol yapılır.

USE Test;
GO
DBCC UPDATEUSAGE ('Test');
GO

Aşağıdaki komut yardımıyla Test veritabanındaki TestTable tablosu için bu kontrol yapılır.

USE Test;
GO
DBCC UPDATEUSAGE ('Test',"TestTable");
GO

Aşağıdaki komut yardımıyla Test veritabanındaki TestTable tablosundaki IX_kolon1 index’i için bu kontrol yapılır.

USE Test;
GO
DBCC UPDATEUSAGE ('Test',"TestTable",IX_kolon1);
GO

Lock Compatibility Nedir

Lock Compatibility(Uyumluluğu), birden fazla transaction’ın aynı anda bir kaynağı(row, page) kilitleme isteği oluştuğunda gerekli kontrolü sağlar. Eğer kaynak bir transaction tarafından daha önce kilitli ise(örneğin kaynak üzerinde Exclusive Lock olduğunu farzedin) bu kaynak üzerinde lock(kilit) koymak isteyen transaction’ın koymak istediği lock’ın ilk koyulan lock çeşidi(örneğimizde Exclusive Lock) ile uyumlu olması gerekir. Eğer ikinci gelen lock isteği ilk gelen lock isteği(ikinci lock’da shared lock olsun) ile uyumlu değilse ilk lock’ın bitmesini bekler ve daha sonra bu kayda lock koyabilir.

Örneğimizde ilk lock çeşidi Exclusive Lock, ikincisi ise Shared Lock’tı. Aşağıdaki tabloda da göreceğiniz üzere Exclusive Lock hiçbir lock çeşidi ile uyumlu olmadığından ikinci lock birinci lock’ın bitmesini ve lock’ı serbest bırakmasını beklemek zorunda kalacak.

Aşağıdaki Lock uyumluluk tablosunu bulabilirsiniz.

Yukarıdaki lock çeşitleri ile ilgili detaylı bilgiyi “SQL Server Lock(Kilit) Çeşitleri” isimli makalemde bulabilirsiniz.