SQL Server'da Partition Değişiklikleri Nasıl Yönetilmeli?
I’m a passionate software engineer specializing in SQL change management, database security, and DevOps automation. With over 17 years of experience in the banking sector, I focus on building tools and processes that make database deployments safer, more auditable, and automated.
As the creator of SQL Change Guard, I develop solutions that use risk scoring and AI-powered code analysis to detect dangerous SQL scripts before they reach production. I’m dedicated to helping teams minimize downtime and data loss through smarter change governance.
When I’m not coding, I enjoy sharing insights about secure development practices, WPF desktop applications, and integrating modern CI/CD pipelines.
Feel free to connect or reach out at info@sqlchangeguard.com
Table partitioning büyük tablolar için güçlü bir performans aracı. Ama partition yapısında yapılan değişiklikler doğru yönetilmezse hem performans hem veri bütünlüğü açısından ciddi riskler doğurur.
Partition Nedir, Neden Değiştirilir? Partition, büyük bir tabloyu mantıksal parçalara böler. Genellikle tarih bazlı yapılır: her ay ya da her yıl ayrı bir partition. Bu yapı sorgu performansını artırır, bakım işlemlerini kolaylaştırır. Ama zamanla partition yapısının değiştirilmesi gerekebilir:
Yeni partition function tanımlanması Partition scheme değiştirilmesi Mevcut partition'ların bölünmesi ya da birleştirilmesi Filegroup yapısının güncellenmesi
Partition Değişikliğinin Riski Veri taşıma süresi: Partition yapısı değiştiğinde mevcut verinin yeniden organize edilmesi gerekebilir. Büyük tablolarda bu saatler alabilir. Kilit problemi: Partition değişikliği sırasında tablo kilitlenebilir. Yoğun saatlerde yapılırsa sistem durabilir. Sorgu planı değişimi: Partition yapısı değiştiğinde query optimizer farklı planlar seçebilir. Performans beklenmedik şekilde değişebilir.
Mevcut Partition Yapısını İnceleme sql-- Tablonun partition bilgilerini görüntüle SELECT p.partition_number AS PartitionNo, p.rows AS SatirSayisi, prv.value AS SinirDegeri, fg.name AS FilegroupAdi FROM sys.partitions p JOIN sys.indexes i ON p.object_id = i.object_id AND p.index_id = i.index_id JOIN sys.partition_schemes ps ON i.data_space_id = ps.data_space_id JOIN sys.partition_functions pf ON ps.function_id = pf.function_id LEFT JOIN sys.partition_range_values prv ON pf.function_id = prv.function_id AND p.partition_number = prv.boundary_id + 1 JOIN sys.destination_data_spaces dds ON ps.data_space_id = dds.partition_scheme_id AND p.partition_number = dds.destination_id JOIN sys.filegroups fg ON dds.data_space_id = fg.data_space_id WHERE p.object_id = OBJECT_ID('dbo.BuyukTablo') AND i.index_id = 1 ORDER BY p.partition_number;
Yeni Partition Ekleme En yaygın senaryo: aylık partition yapısında yeni ay eklenmesi. sql-- Yeni partition ekle ALTER PARTITION FUNCTION pfAylik() SPLIT RANGE ('2025-01-01'); Bu işlem görece güvenli ama yine de değişiklik yönetim sürecinden geçmeli. Özellikle hangi filegroup'a eklendiği kontrol edilmeli.
Partition Değişikliklerini Değişiklik Sürecine Dahil Etmek Partition değişikliği büyük tablolarda yüksek riskli operasyon olarak sınıflandırılmalı. Bu kategorideki değişiklikler için: Etkilenen tablo boyutu önceden hesaplanmalı. Tahmini süre deployment planına eklenmeli. Kesinti penceresi genişletilmeli. DBA ve uygulama ekibinin birlikte hazır bulunması sağlanmalı.
Sonuç Partition değişiklikleri teknik karmaşıklığı yüksek operasyonlar. Değişiklik yönetim sürecine dahil edilmesi hem riskleri azaltır hem de sorun çıktığında geri dönüş yolunu netleştirir. Detaylı bilgi için: sqlchangeguard.com