�ݺ�ߣ

Editor's Notes

1. Yazdığımız bir sorgu çalıştırılmadan önce, SQL Server tarafında sorgumuzda istediğimiz veriye en hızlı nasıl erişebileceğimiz sorusuna cevap veren ve bizim veriye erişim sıramızı tayin eden Query Optimizer bileşenidir. Daha açık bir ifadeyle , karmaşık yani birden fazla tablo veya ifade içeren sorgularımızda öncelikle hangi tabloda ki veriye erişerek sorgu sonucuna daha hızlı erişebilirim ? Hangi tablo üzerinde ki hangi indeksi kullanarak istenen veriye daha hızlı erişebilirim. Hatta bazı durumlarda biz belirtsek dahi iki tabloyu ne şekilde JOIN edersem yani birleştirirsem daha hızlı veriye erişebilirim gibi soruları bizim yerimize soran ve sorgumuzun en optimum şekilde çalışması için bir çalışma planı (Execution Plan) oluşturan SQL Server bileşenidir. ‘ Execution Plan : Query Optimizer tarafından hesaplanan ve bir sorgunun en ideal şekilde çalışması için bize önerilen optimum yoldur.’
2. Table Scan : Üzerinde Clustered Index bulunmayan tablolarda veriye erişmek için tüm tabloyu tarama işlemine denir. Üzerinde Clustered Index tanımlanmamaış tablolara HEAP table denmektedir. Kısaca bir tabloda ki tüm kayıtların teker teker okunama işlemine denmektedir. Clustered Index Scan : Bu işlem de Table Scan işlemi gibi SQL Server Clustered Index üzerinden tablodaki kayıtlara satır satır erişip işlem yaptığını gösterir. Aslında bakıldığında Index in kullanılmadığını görmketesiniz. Çünkü tablodaki tüm veri,ye Table Scan de ki gibi satır satır erişip sonra sonucu döndürecektir. SQL Server’ın bu şekilde işlem yapmasının sebebi sorgu sonucunda çok fazla kayıt döndürüleceği için tablodaki verilere Table Scan işlemindeki gibi satır satır erişmenin daha hızlı olacağına karar vermesinden kaynaklanmasıdır. Bu sebeple Clustered Index Scan işlemi için Table Scan işlemi ile hemen hemen aynıdır demek de yanlış bir tabir olmaz. Çünkü SQL Server clustered indeksi filtreleme amaçlı kullanmadan tüm veriye satır satır erişmiştir. Bu yüzden özellikle büyük tablolardaki veriye erişen sorgularımızın Execution planlarında Clustered Index Scan operatörünü görünce ne yapmalıyız sorusu akla gelebilir. Cevap aslında çok zor değil. Sorgumuz sonucunda kullanabileceğimiz bir Clustered indeksimiz zaten var bu yüzden sorgumuzdan dönen kayıt sayısını eğer gerekli değilse azaltabiliriz. Bunun için özellikle WHERE operatörü ile belirtmiş olduğumuz koşulları tekrar gözden geçirip eğer gerekli değilse sorgu sonucunda dönen kayıt sayısını azaltabilirsek istediğimiz sonuca ulaşabiliriz. Kısaca Index lerin Çalışma Prensibi Değinelim , Index
3. Clustered Index Seek : Index Scan ile Index Seek işlemleri tamamen birbirinden farklıdır. Bunun en büyük sebebi Scan işleminde tabloda ki tüm verileri satır satır tarayarak sonuca gidilirken. Seek işlemlerinde direkt datanın kendisine erişim sağlanmış oluyor. Bu sebeplerden dolayı Seek işlemi Scan işlemlerdinden daha performanslıdır. ( Çoğu durumlarda !) NonClustered ındex Seek : Nonclustered Index işlemide direkt dataya erişimimizi Nonclustered Index üzeirnden erişme işlemine denmektedir. Index kullanım amacımız , istenilen bilgiye daha az veri okuyarak daha hızlı bir şekilde erişmektir. Kısaca Index lerin Çalışma Prensibi Değinelim , SQL Serverda klasik Index yapısına değinecek olur isek , Index ler B-Tree (Balanced Tree) yapısına organize olmuş durumdadırlar. B-Tree nin en üst page inden (Root Level) başlayarak ağaç üzerinde kayıdı bulmak için dallanmalar yapılır.Root Level dan sonra Intermediate Level Page ler gelmektedir.Bu page ler tabloda ki kayıt sayısına ve index in boyutu gibi durumlara göre 1 leveldan fazla olabilmektedir. Yani bir B-Tree yapısında 1 level Root, 1 lefel Leaf ve 1 ya da daha fazla Intermediate Level bulunmaktadır. Root ve Intermediate Level lara Non-Leaf Level denmektedir. Hem Clustered hem de NonClustered Index ler için Non-Leaf Level Page lerde Index Key ler bulunmaktadır. Örneğin, Personel_ID kolonu için Clustered Index tanımlandıysa Non-Leaf Level Page lerde bu Personel_ID kolonu bulunur. Personel_ID Clustered Index ‘in Key kolonudur. Eğer bu Clustered Index unique olarak tanımlanmamışsa SQL Server arka tarafta bu veriyi Unique leştirmek için her bir veri için 4 byte ‘lık Integer bir kolon tutmaktadır. Bunada Uniquifier konu denmektedir. Non-Leaf Level Page lerde ayrıca NonClustered Index le riçin , Eğer NonClustered ındex ler Unique değil ise , Heap ‘ın POINTER bilgileri ya da Clustered Index ‘in KEY kolon bilgileri bulunur. NOT : SQL Server için bir ındex in Unique olup olmaması oluşturulurken kullanılan Unique sözcüğüne bağlıdır. Yani Index I oluştururken UNIQUE ifadesi kullanılmazsa Index unique değildir. Şimdi gelelim B-Tree nin enlat Level I olan Leaf Level Page ‘lere. Bu page lerde bulunan bilgiler Clustered ya da NonClustered ındex lere göre farklılık göstermektedir. Clustered Index için , Leaf Level da verinin tüm kolonları ile beraber kendisi bulunmaktadır. B-Tre nin Leaf Level ında Index I bulduğumuz anda verinin kendisine de erişmiş oluruz. NonClustered Index için , Leaf Levelda ise Include edilmiş kolonlar ve ayrıca verinin geri kalanına erişebilmek için Row Locator yani satır belirleyici bilgileri bulunur. ÖNEMLİ NOT : NonClustered Index te aranan kayıt bulunduktan sonra Cluster ya da Heap ‘a yönelerek kayıdın geri kalanını bulma işlemine LookUp denilmektedir. ÖRNEK DEMO : INDEX-PAGEveLookUp-Ornek.sql dosyası içerisinde. ÖRNEK Anlatımı : Örneğimize başlamadan iki adet Clone tablo oluşturuyoruz . Address tablosunun bir Clone unda Clustered ve NonClustered Index ekliyoruz ki bu tablomuz AddressDemo_Clustered tablosu. Diğer Clone tablomuz ise Clustered Index olmadan NonClustered ındex oluşturuyoruz. Bu tablomuzda AddressDemo_Heap tablomuzdur. AddressDemo_Clustered tablomuza AddressID kolonuna sqltr_CIX_AddresDemo_AddressId isimli bir Clustered Index oluşturuyoruz. City alanına da sqltr_NCIX_AddressDemo_Clustered_City isimli bir NonClustered Index oluşturuyoruz. Daha sonra 'AddressDemo_Clustered tablosunun Page lerini listelemek için Undocumented DBCC IND komutu ile Tablo Page lerini listeliyoruz. DBCC IND ( 'AdventureWorks2016', 'AddressDemo_Clustered', 2) GO  Syntax : dbcc ind( dbid|dbname, objid|objname, printopt = {-2|-1|0|1|2|3} ) 1 – data page 2 – index page 3 veya 4 – text pages 8 – GAM page 9 – SGAM page 10 – IAM page 11 – PFS page DBCC IND komutundan PageId yi alıyoruz ve Page yapısını inceliyoruz DBCC PAGE komutu ile DBCC traceon(3604) DBCC page('AdventureWorks2016', 1, 59536, 3) GO DBCC PAGE ({dbid|dbname}, pagenum [,print option] [,cache] [,logical]) Gördüğübüz üzere Page içerisinde City kolonu NonClustered Index in Key kolonu, AddressId ve Uniqufier kolonları ise verinin geri kalanlarına Lookup yapabilmek için tutulan bilgilerdir. Heap tablomuzda yani Clustered Index olmayan ama NonClustered index olan örneğimizi incelediğimizde ise gördüğünüz üzere Lookup yapmak için gerekli Clustred Key ve Uniqufier kolonları yerine RowID Key kolonu (HEAP RID (Key)) bulunmaktadır. B-Tree üzerinde arama işlemi en üst level’dan (Root) yapılmaya başlanır. Ağaç mantığında diğer kollara dallanılarak Intermediate level’larda arama devam ettirilir. Aramanın sonunda aranan key’e Leaf Level’da erişilir. Eğer bu bir Clustered Index ise veriye direk erişilmiş olur, NonClustered Index ise ve key kolonlar hariç başka kolonlara da ihtiyacımız var ise heap’e ya da Clustered Index’e LookUp yapılarak diğer ihtiyaç olunan bilgiler getirilir ÖZET OLARAK : Eğer table clustered index içeriyorsa; row locator Clustered Index key’lerini içerir. Eğer Clustered Index unique olarak tanımlanmadıysa, row locator bu key’leri unique hale getirmek için key’in sonuna 4 bytle’lık bir belirleyici (uniqueifier) koyar. NonClustered Index’in Leaf Level’ıne erişildiğinde ve Clustered Index’e Key LookUp yapılması gerektiğinde Clustered key unique değil ise Clustered Index’te arama hem key’ler hem de bu uniqueifier kolonu ile beraber yapılır.