SQL Server Table Partition Oluşturmak

SQL Server Table Partition Oluşturmak

Bir tabloda yer alan verileri kendi belirlediğiniz kümeler halinde istediğiniz diskte tutabileceğinizi biliyor muydunuz? Bu yazımızda birçok farklı amaç için kullanabileceğiniz bu güzel özelliği, table partition yapısını anlatacağız.

Hemen aklıma gelen birkaç örnek ile ne için kullanılabileceğinden bahsedelim. Zamanla büyüyen bir tablomuz olduğunu düşünelim. Tabloyu yönetmemiz günden güne zorlaşacak, index bakım süreleri her geçen gün artacaktır. Hatta eski verilerin çok az sorgulandığı ancak yeni verilerin çok sık sorgulandığı bir durumda olabilir. Böyle bir durumda partition işleminin bize ne gibi bir faydası olabilir?

  • Yeni eklen verileri hızlı disklere konumlandırabiliriz.
  • İndex bakımlarını sadece belirlediğimiz aralıktaki verileri kapsayacak şekilde ayarlayabiliriz.
  • Partition Switch işlemi ile TB’larca veriyi saniyeler içerisinde taşıyabilirsiniz.

Şimdi gelelim nasıl yapıldığına.

Öncelikle partitionlarımızı ekleyeceğimiz file groupları ekleyerek başlamamız gerekiyor.

Yukarıda yer alan resimde görüldüğü gibi 3 adet file group ekledim.

Ardından bu file grouplara file eklememiz gerekiyor.


File eklerken kırmızı ile işaretlediğim kısma dikkat etmeniz gerekir. Oluşturduğumuz fileları daha önce oluşturduğumuz file grouplara tanımlamalıyız.

Belirlediğimiz diskler üzerine belirlediğimiz fileları oluşturduk şimdi sıra geldi tablomuzu oluşturmaya ve içerisindeki verileri belirlediğimiz bir aralığa göre belirlediğimiz filelara yazmaya.

Bu işlemi yapmak için iki şeye ihtiyacımız var. Birisi Partition Function diğeri ise bu Partition Schema

Partition Function kısmında tabloda yer alacak verimizi hangi kritere göre bölmek istediğimizi belirtiyoruz. Partition Schemada ise bu belirlediğimiz aralığı hangi dosyalara yazacağımızı belirliyoruz. Ben tablomu otomatik artan bir bigint alanına göre bölmek istiyorum. Ve bunun için aşağıdaki script ile partition function oluşturuyorum.

— PF_OrderByBigIntId(Bigint) fonksiyonum adını ve alacağı değerin Bigint formatında olduğunu belirtiyorum.

— RIGHT – LEFT ifadesi ile alakalı bilgiyi daha geniş bir zamanımda uzunca anlatmam gerekecek.

— Values kısmında ise 100000 diyerek 0 ile 100000 arasında kalan değerleri, ardından 100000 ile 200000 arasında kalan değerleri aralık olarak belirliyorum.

Sıra geldi partition scheme oluşturmaya.

 

— PS_OrderByBigIntId şemamızın ismini belirtiyor.

— AS PARTITION PF_OrderByBigIntId ifadesi ile parçalama fonksiyonumu tanımlıyorum.

— Dikkatinizden kaçmamıştır, oluşturduğumuz fonksiyonda 2 aralık belirtmemize rağmen burada 3 file group belirtiyoruz, bunun sebebi aralığın dışında kalacak değerler için de en az bir file istemesidir. Yani 200000 den yüksek bir değerli kayıt gelirse FG_partition3 dosyasına yazacaktır.

 

Sıra geldi tablomuzu oluşturmaya.

 

 

— Gördüğünüz gibi  tabloyu oluşturuken ON [PRIMARY] ibaresi yerine şemamızın adını yazdık ve Id kısmını da parametre olarak içerisine ekledik.

— Tabloya veri eklemek için aşağıdaki gibi basit bir script yazıp testini yapabiliriz.

— Aşağıdaki script yardımı ile hangi partitionda kaç adet veri olduğunu da görebiliriz.

Benzer Yazılar

SQL SERVER SERViS RESTART HATASI

SQL Server 2 gün önce

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

SQL’DE İKİ NODE’UN RESOLVING DURUMA DÜŞMESİ VE ÇÖZÜMÜ

SQL Server 3 hafta önce

Bu yazımızda failover olma işlemi esnasında karşılaşılan bir durumdan kısaca bahsedeceğim. Kısa bir yazı olacak ama önemli olduğunu düşünüyorum. Bazen failover olmak istediğinizde cluster secondary’e node’a failover olamaz, hem secondary hem de primary node’unuz resolving durumuna geçer. Bu durumla daha çok otomatik failover olma durumlarında karşılaşılır çünkü sistem failover’a aslında hazır değildir ancak cluster bunu bir şekilde bilemez. Failover olma gerçekleşemez bir anlamda sql cluster askıda kalır ve hiçbir sunucu da sql engine çalışmaya devam edemez. (GÖRSEL-1) GÖRSEL-1 GÖRSEL-1 üzerinde gördüğünüz üzere availability group resolving duruma düşer. Availability replica’lar üzerinde de gördüğünüz üzere primary ve secondary tüm node’lar resolving state’e düşer. Böyle bir durumunda iki farklı çözüm yolumuz var;   Çözüm: ikinci node’a sunucu restart’ı atmak. Bu noktada secondary sql node’a servis restart atmak işe yaramıyor. Zaten db’ler iki taraflı resolving modda. O sebeple ancak sunucu restart atıldığında cluster ayakta olan sunucuyu görüyor ve askıda kalma durumundan ilk başta primary […]

Query Store Nedir?

SQL 3 hafta önce

Query Store ile birlikte execution planın seçimi ve bu sürecin performansa etkisini anlayabiliriz. SQL Server içerisinde bulunan Query Store özelliği, çalıştırılan sorguların execution planını ve bu sırada oluşan istatistiklerini otomatik olarak yakalar. Böylece query plan değişikliği ile oluşan problemleri de hızlı ve kolay şekilde fark edebiliriz. Elinizde bulunan bir sorguya ait query plan zamanla değişebilir. Bunun birçok sebebi vardır. Tablo yapısına yeni bir column eklenmesi Veri tipinin değiştirilmesi Sorgularda yeni parametrelerin eklenip çıkarılması Verilerde, schemalarda veya sorgu parametrelerindeki değişiklik Burada önemli olan ise bazen bu değişimler sorgunun yavaş çalışmasına neden olur. Query Store ile beraber bu yavaşlığın kök nedenine inmek daha kolay oldu. Ayrıca query store sayesinde ilgili sorguya ait read-write bilgileri ve cpu tüketimi bilgilerine de erişebilirsiniz. Query Store’u veritabanı seviyesinde aktif edebiliyoruz. Veritabanı üzerine sağ tıklayarak properties diyoruz ve Query Store sekmesine geliyoruz. Operation Mode alanından Read Write’ı seçiyoruz. Böylelikle Query Store gerekli bilgiyi toplayabilir ve size ilgili sonuçları […]

0 Yorum

Yorum Yaz

Rastgele