SQL Agent Job'ları da Değişiklik Yönetimine Tabi Olmalı
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
SQL Agent Job'ları veritabanı yönetiminin en çok atlanan nesnelerinden biri. Tablolar, stored procedure'ler, index'ler dikkatle izlenirken job değişiklikleri çoğunlukla kimsenin radarında değil.
Ama bir job değişikliği bazen şema değişikliğinden daha kritik sonuçlar doğurabilir.
Job Değişikliği Neden Kritik?
SQL Agent Job'ları arka planda çalışır, sessizce. Backup alma, veri senkronizasyonu, raporlama, cleanup işlemleri, ETL süreçleri — bunların tamamı genellikle job'lar üzerinden yönetilir.
Bir job'un schedule'ı değişti. Ya da bir step devre dışı bırakıldı. Ya da komut satırı güncellendi. Bunları kim fark eder?
Çoğu ortamda cevap: kimse, ta ki bir şeyler ters gidene kadar.
Yaygın Senaryolar
Backup job'u devre dışı bırakıldı
Biri geçici olarak devre dışı bıraktı, sonra unuttu. Haftalarca backup alınmadı. Bir disaster yaşandığında fark edildi.
Schedule değiştirildi
Gece 02:00'de çalışan bir ETL job'u mesai saatlerine taşındı. Sistem yavaşladı, kimse nedenini anlayamadı.
Job step güncellendi
Bir step'teki stored procedure adı değiştirildi ama job güncellenmedi. Job hata vermeye başladı ama sessiz hata olduğu için fark edilmedi.
Job Değişikliklerini Tespit Etmek
SQL Server'da job değişikliklerini izlemek için DDL Trigger çalışmaz, çünkü job'lar veritabanı nesnesi değil, msdb veritabanında sistem tabloları. Ama şu sorgu ile son değişiklikleri görebilirsiniz:
sql
SELECT
j.name AS JobAdi,
j.date_created AS OlusturmaTarihi,
j.date_modified AS SonDegisiklikTarihi,
l.name AS SonDegistirenKullanici
FROM msdb.dbo.sysjobs j
LEFT JOIN master.sys.syslogins l ON j.owner_sid = l.sid
ORDER BY j.date_modified DESC;
Bu sorgu son değiştirilen job'ları listeler. Ama kim değiştirdi bilgisi doğrudan tutulmaz, bu native SQL Server'ın bir eksikliği.
Job Değişiklikleri İçin Süreç
Job değişiklikleri de tıpkı şema değişiklikleri gibi onay sürecinden geçmeli.
Bir job değişikliği talebi geldiğinde şu soruların yanıtı alınmalı: Hangi job değişiyor? Ne değişiyor, neden? Bu değişiklik başka job'ları ya da süreçleri etkiliyor mu? Rollback planı ne?
Onay sonrası değişiklik yapılmalı ve kayıt altına alınmalı.
Periyodik Job Denetimi
Ayda bir şu kontrolü yapmak iyi bir pratik:
Tüm job'ların listesi ve durumları gözden geçirilmeli
Devre dışı olan job'ların neden devre dışı olduğu bilinmeli
Son 30 günde hata veren job'lar incelenmeli
Gereksiz ya da kullanılmayan job'lar temizlenmeli
Bu denetim hem operasyonel sağlığı korur hem de yetkisiz değişiklikleri yakalamak için fırsat sağlar.
Sonuç
SQL Agent Job'ları görünmez ama kritik nesneler. Değişiklik yönetimi kapsamına dahil edilmediğinde sessiz riskler birikir. İyi haber şu: sürece dahil etmek düşündüğünüzden çok daha kolay.
Detaylı bilgi için: sqlchangeguard.com
