SQL Server Agent Best Practices: Job Sahipleri, Bildirimler, Geçmiş ve Zamanlama

SQL Server Agent; yedekleri, CHECKDB’yi, index bakımını, ETL’leri ve raporları çalıştıran görünmez operasyon ekibidir. Çoğu zaman kurulumdan sonra kimse ona bakmaz; ta ki yedek job’ının haftalardır sessizce başarısız olduğu, job geçmişinin tam ihtiyaç duyulduğunda silindiği ya da işten ayrılan bir çalışanın hesabıyla birlikte gece job’larının durduğu fark edilene kadar.

Bu rehberde Agent’ı güvenilir hale getiren pratikleri tek bir yerde topluyoruz: job sahipleri, bildirimler ve fail-safe operator, job geçmişinin saklanması, çakışan zamanlamalar, yetkiler ve Always On ortamlarında job yönetimi.

1. Job Sahipleri: Kişisel Hesaplar Kullanmayın

Bir job’ı oluşturan kişinin login’i varsayılan olarak job’ın sahibi olur. O kişi işten ayrılıp Active Directory hesabı kapatıldığında ya da etki alanı denetleyicisine geçici olarak ulaşılamadığında job, sahibinin yetkisi doğrulanamadığı için başarısız olur. Bu, genellikle tam da kimsenin bakmadığı gece saatlerinde olur.

Job’ların sahibini sa ya da bu iş için ayrılmış, kişisel olmayan bir login yapın. Kişisel hesaba ait job’ları bulmak için:

SELECT j.name AS job_name,
       SUSER_SNAME(j.owner_sid) AS owner_name,
       j.enabled
FROM msdb.dbo.sysjobs AS j
WHERE SUSER_SNAME(j.owner_sid) IS NULL          -- sahibi artık olmayan job'lar
   OR SUSER_SNAME(j.owner_sid) <> N'sa'
ORDER BY owner_name, job_name;

-- Sahibi değiştirmek
EXEC msdb.dbo.sp_update_job @job_name = N'Gece Yedek', @owner_login_name = N'sa';

Aynı ayar, job özelliklerindeki General sayfasında Owner alanından da değiştirilebilir:

2. Bildirimler: Başarısız Job Sessiz Kalmasın

Bir job başarısız olduğunda bunu ilk fark eden kullanıcılar olmamalıdır. Bunun için üç parça birlikte çalışmalıdır: çalışan bir Database Mail profili, Agent’a atanmış bu profil ve job’lara tanımlı bir operator.

1. Database Mail’i yapılandırıp bir test e-postası gönderin.
2. Agent özelliklerinde Alert System sayfasında mail profilini etkinleştirin. Bu değişiklik, Agent servisi yeniden başlatıldığında geçerli olur.
3. Kişi yerine bir ekip adresine giden bir operator oluşturun (örneğin DBA Ekibi).
4. Her job’da Notifications sayfasında “When the job fails” için e-posta bildirimini açın.

Başarısızlık bildirimi tanımlı olmayan etkin job’ları bulmak için:

SELECT j.name AS job_name
FROM msdb.dbo.sysjobs AS j
WHERE j.enabled = 1
  AND (j.notify_level_email = 0 OR j.notify_email_operator_id = 0)
ORDER BY j.name;

Fail-safe operator

Fail-safe operator, normal operator’a ulaşılamadığında ya da Agent msdb’deki operator bilgisine erişemediğinde bildirimleri alan yedek alıcıdır. Belirli saatlerde bildirim alacak şekilde tanımlanmış operator’ların kapsamadığı saatlerde de devreye girer. Agent özelliklerinde Alert System sayfasından tanımlanır:

Ciddi hatalar ve disk bozulmaları için Agent uyarılarının nasıl kurulacağını SQL Server uyarıları rehberimizde anlatıyoruz.

3. Job Geçmişi: Varsayılan Değerler Çok Düşük

Agent, job geçmişini varsayılan olarak toplam 1.000 satır ve job başına 100 satırla sınırlar. Sık çalışan birkaç job (örneğin her 15 dakikada bir log yedeği) bu sınırı birkaç gün içinde doldurur ve diğer job’ların geçmişi siler. Bir sorunu araştırmanız gerektiğinde ihtiyaç duyduğunuz kayıt çoktan gitmiş olur.

Sınırları Agent özelliklerinin History sayfasından artırın; çoğu ortam için toplamda on binlerce, job başına birkaç bin satır makul bir başlangıçtır:

Daha öngörülebilir bir yaklaşım, satır sınırını kaldırıp geçmişi yaşına göre temizlemektir. Bunun için haftalık bir job’da şu komut yeterlidir:

DECLARE @oldest datetime = DATEADD(DAY, -60, GETDATE());
EXEC msdb.dbo.sp_purge_jobhistory @oldest_date = @oldest;

Bu durumda msdb’nin boyutunu izleyin; yedek ve job geçmişi temizlenmeyen msdb veritabanları zamanla gigabaytlarca büyüyebilir.

4. Çakışan Zamanlamalar

Yedek, index bakımı, CHECKDB ve ETL job’larının aynı saatte başlaması, kısa süreli ama yoğun CPU ve disk baskısı yaratır ve hepsinin birlikte yavaşlamasına yol açar. Aynı başlangıç saatine sahip job’ları bulmak için:

SELECT STUFF(STUFF(RIGHT(N'000000' + CAST(s.active_start_time AS nvarchar(6)), 6), 5, 0, N':'), 3, 0, N':') AS start_time,
       COUNT(*) AS job_count,
       STRING_AGG(j.name, N', ') AS jobs
FROM msdb.dbo.sysjobs AS j
JOIN msdb.dbo.sysjobschedules AS js ON js.job_id = j.job_id
JOIN msdb.dbo.sysschedules AS s ON s.schedule_id = js.schedule_id
WHERE j.enabled = 1 AND s.enabled = 1
GROUP BY s.active_start_time
HAVING COUNT(*) > 1
ORDER BY job_count DESC;

Sonuçtaki job’ları birbirinden ayırın, özellikle ağır işleri farklı saatlere ya da tek bir sıralı job içinde ardışık adımlara taşıyın. Bakımın iş saatlerinden önce bittiğini job süresi trendinden kontrol edin.

5. Yetkiler: Proxy ve Credential Kullanın

CmdExec ve PowerShell adımları varsayılan olarak Agent servis hesabının yetkileriyle çalışır. Servis hesabına dosya sunucularında ya da başka sistemlerde geniş yetkiler vermek yerine, adım için gereken yetkiye sahip bir Windows hesabını credential olarak tanımlayıp bir proxy üzerinden kullanın. Böylece her adım yalnızca ihtiyaç duyduğu yetkiyle çalışır ve servis hesabı en az yetki ilkesine uygun kalır.

6. Job Adımlarını Dayanıklı Hale Getirin

• Ağ veya geçici kilitlenmelerden etkilenebilen adımlarda Retry attempts ve Retry interval tanımlayın.
• Uzun çıktı üreten adımlarda Advanced sayfasından çıktıyı bir dosyaya yazın; job geçmişi mesajı 4.000 karakterle sınırlıdır.
• Bir adım başarısız olduğunda sonraki adımların ne yapacağını (On failure action) bilinçli seçin.
• Job’ları script olarak sürüm kontrolünde saklayın; sunucu yeniden kurulduğunda ya da migration’da hiçbir job unutulmaz.

7. Always On Ortamlarında Job’lar

Agent job’ları msdb’de tutulur ve availability group ile birlikte senkronize edilmez. Failover sonrasında job’ların yeni primary’de de çalışabilmesi için:

• Job’ları tüm replikalarda oluşturun ve değişiklikleri hepsine uygulayın.
• Job’ın ilk adımında replikanın primary olup olmadığını kontrol edin; secondary’de job’ı sessizce sonlandırın.
• SQL Server 2022 ve sonrasında Enterprise edition’da contained availability group, job’ları grubun kendi msdb’sinde tutarak bu sorunu ortadan kaldırabilir.

-- Job'ın ilk adımı: bu replika primary değilse çık
IF sys.fn_hadr_is_primary_replica(N'SatisDB') <> 1
BEGIN
    PRINT N'Bu replika primary değil; job adımı atlandı.';
    RETURN;
END

Agent Kontrol Listesi

• Tüm job’ların sahibi sa ya da kişisel olmayan bir login.
• Database Mail çalışıyor; Agent’a mail profili atanmış ve test edilmiş.
• Tüm etkin job’larda başarısızlık bildirimi bir ekip operator’ına gidiyor; fail-safe operator tanımlı.
• Job geçmişi sınırları artırılmış ya da yaşa göre temizleniyor; msdb boyutu izleniyor.
• Ağır job’lar farklı saatlere dağıtılmış.
• CmdExec ve PowerShell adımları proxy ile çalışıyor.
• Always On replikalarında job’lar eşit ve primary kontrolü yapıyor.
• Agent servisi otomatik başlıyor; job’lar sürüm kontrolünde.