Stored Procedure Değişikliği Production'ı Nasıl Çökertir?
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
Stored procedure'ler veritabanının en kritik nesnelerinden biri. Uygulamalar onlara bağımlı, raporlar onlara bağımlı, bazen başka stored procedure'ler onlara bağımlı. Küçük bir değişiklik domino etkisi yaratabilir.
Neden Bu Kadar Riskli?
Bir tablo değişikliğinde etki görece sınırlıdır. Ama bir stored procedure'ü değiştirdiğinizde şunların tamamını test etmek gerekir:
Bu procedure'ü çağıran uygulamalar
Bu procedure'ü çağıran diğer procedure'ler
Bu procedure'e bağlı raporlar
Bu procedure'ü kullanan zamanlanmış işler
Çoğu DBA bu bağımlılıkları kafasından biliyor ama "biliyor olmak" ile "test etmiş olmak" arasında production krizi kadar fark var.
En Sık Yaşanan Senaryolar
Parametre değişikliği
Bir stored procedure'e yeni parametre eklendi. Varsayılan değer verilmedi. Eski çağrımlar parametre sayısı uyuşmadığı için hata vermeye başladı. Hangi uygulama bu procedure'ü çağırıyor? Kaç yerde?
Return değeri değişikliği
Procedure bir kolon daha döndürmeye başladı. Sonucu belirli bir sırayla okuyan uygulama yanlış kolonu işlemeye başladı. Hata açık vermedi, sessizce yanlış veri işlendi.
İş mantığı değişikliği
Bir hesaplama güncellenidi. Test ortamında çalıştı. Ama production'daki veri dağılımı farklıydı, edge case'ler production'da ortaya çıktı.
Bağımlılık Analizi Nasıl Yapılır?
Değişiklik öncesi şu sorguyu çalıştırın:
sql
SELECT
referencing_schema_name,
referencing_entity_name,
referencing_class_desc
FROM sys.dm_sql_referencing_entities('dbo.ProcedureAdi', 'OBJECT')
ORDER BY referencing_entity_name;
Bu sorgu ilgili procedure'e bağımlı tüm nesneleri listeler. Ama dikkat: sadece veritabanı içindeki bağımlılıkları gösterir. Dış uygulamaların bağımlılıkları bu sorguda görünmez.
Değişiklik Öncesi Kontrol Listesi
Bir stored procedure'ü değiştirmeden önce şu soruları yanıtlayın:
Bu procedure'ü hangi uygulamalar çağırıyor? Bu uygulamaların geliştiricilerine haber verildi mi? Test ortamında bağımlılıklar test edildi mi? Rollback planı hazır mı? Deployment zamanı uygun mu, yani yoğun olmayan bir saatte mi?
Sonuç
Stored procedure değişiklikleri basit görünür ama etki alanı geniştir. Her değişiklik bağımlılık analizi, test ve onay sürecinden geçmeli.
Detaylı bilgi için: sqlchangeguard.com