# SQL Agent Job'ları da Değişiklik Yönetimine Tabi Olmalı

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

```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](http://sqlchangeguard.com)