İlk yazıda genel mantığını konuştuğumuz ve bir örnekle giriş yaptığımız Partitioning konusuna ikinci yazımızla devam ediyoruz. Burada SQL Server versiyonları ile beraber Partitioning kavramındaki değişiklikleri ve yenilikleri görüp, Partition Switch konusunda bir örnekle bitireceğiz.
SQL Server 2005 versiyonu ile hayatımıza giren Partitioning bu ilk versiyonda 1000 adete kadar Partition oluşturmamıza izin veriyordu. SQL Server 2008 de aynı kısıtlamalarla piyasaya sürüldü ancak bu sürümün üzerine gelen SP2 güncellemesi limiti 15000 e çıkardı. Aynı şekilde SQL 2008 R2 1000 Partition limiti ile Release olurken, gelen SP1 güncellemesi limiti 15000 e çıkardı.
SQL Server 2012 ve 2014 de de Partition limitimiz 15000,SQL 2014 ile birlikte Partition bazında Online Index Rebuild işlemi yapılabilmekte, yani işlem sırasında kullanıcılarımız tabloyu kullanmaya devam edebilecek.
Partition kullanmaya başlamadan önce üzerinde durmamız gereken birkaç madde var;
- Partitioning SQL Server Enterprise Edition tarafından desteklenen bir özelliktir. Bu yüzden ihtiyacın doğru tespit edilip doğru karar verilmesi önemlidir.(Partitioning kullanılan bir database Enterprise olmayan bir sunucuya restore edemeyiz, lisans maliyeti vb.)
- Performans alabilmek için Partition yaparken kullandığımız key alanımız bu tabloya erişirken kullanacağımız sorgularda kullanılmalıdır. (Aksi durumda Partition’ın bir faydası olmayacaktır, dahası eski halinden daha kötü bir sorgulama performansı verebilir.)
- Partition koşulumuzu içeren Partition fonksiyonu zaman zaman olarak gelen yeni datalarla kontrol edilmelidir. Aksi halde yeni gelen satırlar Data’nın partitonlar üzerindeki dağılımını bozarak Partitionın amacından uzaklaşmasına sebep olabilir.
Partitioning kavramının kısıtlamalarını ve bu işe girişmeden önce dikkate almamız gereken konuları kısaca inceledik. Şimdi gelelim başta bahsettiğimiz Partition Switch’e.
Programlama geçmişi olanlar pointer kavramını hatırlayacaktır. Kısaca pointer, bellekte bir alana erişmek için kullanabileceğimizi bir adres bilgisidir. Veritabanın’da da aynı adresleme yapısının disk üzerindeki Data’lar için kullanıldığını düşünelim.
Partition yapısı kullanmayan bir tabloya bakalım;
Resim-1
Resim-1 de kullanıcının önyüzden eriştiği tabloyu ver arkasındaki Data’nın diskte tutulduğu bloğu görüyoruz.
Şimdi Partitioned bir tablo düşünelim;
Resim-2
Resim-2 iki parçaya ayrılmış bir tablonun disk üzerinden 2 parçaya erişen 2 adresi olduğunu gösteriyor.
Partition Data’sının disk üzerindeki tutulabileceği temel senaryoyu görmüş olduk. Bunun haricinde Partition parçalarımız ayrı ayrı disklere de dağıtılmış olabilir.
Şimdi Partition yapılmış tbl_Satis tablomuzun birebir kopyası bir başka tablo düşünelim; tbl_Satis_2.
Resim-3
Bu iki tablo yapısal olarak birebir eş olduğu için (alan sayıları ve alanların Data tipleri eşit ve her ikisi de aynı Partition schema üzerinden partiton yapılmış) bu iki tablomuzun partitonlarını kolayca Switch edebiliriz.
Örnek yapalım;
ALTER TABLE dbo.tbl_Satis
SWITCH PARTITION 2 TO dbo.tbl_Satis_2 PARTITION 2
İşlemden önce tbl_Satis tablomuzun 2. Partitionın’da Marmara bölgesi satış bilgileri olduğunu düşünürsek. Artık bu bilgiler tbl_Satis_2 tablomuzun içerisine aktarılmış oldu ve artık tbl_Satis tablosunda yok.
Burada 20 milyon satır kayıt olduğunu düşünsek bile bu Switch operasyonunun toplam süresi birkaç saniyeyi geçmeyecektir. Bunun sebebi Data’nın taşınmaması sadece adres bilgisinin değiştirilmesidir(bkz. Resim-4).
Resim-4
Bu işlemi klasik DML ile yapmak istesek ,20 Milyon kaydı tbl_Satis tablomuzdan tbl_Satis_2 tablosuna INSERT etmemiz daha sonra da tbl_Satis tablomuzdan bu kayıtları silmemiz gerekecekti…
Son olarak kısıtlamalara bakalım;
*Yazı içerisinde bahsettigimiz iki tablonun yapı olarak birebir uyumlu olması zorunluluğu
*Hedef partiton ın mutlaka boş olması gerektiği (Switch öncesi tbl_Satis_2 tablomuzun ikinci Partitionın’da hiç data olmamalı)
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
