Ben bile veritabanı olmayan görevleri zamanlamak için SQL Server Agent kullanıyorum - bu kötü bir fikir mi?

Ben bir DBA olduğumdan (ve birçok durumda de-facto sysadmin), SQL Server düzenli olarak çalışmak zorunda olduğum hemen hemen her sunucuya yüklenir. Son zamanlarda yerel Windows Görev Zamanlayıcı yerine hemen hemen her durumda SQL Agent iş zamanlayıcı olarak kullandığımı fark ettim.

Benim bakış açımdan, SQL Agent'ın yerel Windows Görev Zamanlayıcı'ya göre bir takım avantajları vardır:

• Görevleri uzaktan (iş istasyonumdan) başlatma / durdurma / izleme
• Paylaşılan zamanlamalar (her görev tek başına değil)
• Birden fazla adım ve kontrol akışı
• Farklı görev türleri
• Hata / tamamlanma ile ilgili uyarılar
• Farklı kullanıcılar gibi davranacak şekilde yapılandırılabilir
• Sadece bir hata kodu yerine (orta derecede) açıklayıcı hata mesajları

Ancak, bunun kötü bir uygulama olduğu hissinden kaçamam - SQL Aracısı sadece veritabanı ile ilgili görevler için ayrılmalıdır ve kullanılabilirliğini beğenmeme rağmen işletim sistemi düzeyinde görevleri Windows Görev Zamanlayıcı'da çalışır durumda bırakmalıyım.

Bu şekilde SQL Agent'a güvenmek uygun mudur? Değilse, aradığım işlevselliklerden bazılarını elde etmek için üçüncü taraf bir Windows görev zamanlayıcısı düşünmeliyim?

Şahsen en büyük uyarının iş listesini düzenli tutmakta zorluk olacağını düşünüyorum. Bildiğim kadarıyla işleri düzenlemek için klasör oluşturamazsınız, bu yüzden çok sayıda hantal olur. Sunucularımın hiçbirinde bir düzineden fazla iş olmadığı için bundan% 100 emin değilim. Server 2008 ve sonraki sürümlerin Görev Zamanlayıcısı, daha kolay organizasyon, IMO ve genel olarak önceki sürümlere göre çok daha iyi işlevsellik sağlar. Eminim üçüncü taraf uygulamaları daha da iyi bir iş çıkarır. Server 2003'ün görev zamanlayıcısını kullanmam gerekirse ağlardım at.exe.

Düşünebileceğim ikinci uyarı, potansiyel olarak SQL sunucusuna çok fazla yük koymak olacaktır. Temsilci küçük bir programdır, ancak uzun veya karmaşık bir görevi yürütmek çok fazla kaynağı kolayca tüketebilir. Bu kaynaklar SQL motoru için kullanılamaz. SQL motoru kullanılabilir sistem belleğinin yaklaşık% 80'ini alacak şekilde programlandığından, bu bir sorun olabilir.

Üçüncü olarak, yedekleme bir sorun olabilir. İşlerin kurtarılmasına izin vermek için yalnızca dosya sistemini değil, msdb veritabanını da yedeklemeniz (veya görevleri bir metin dosyasına kodlamak için bir şey kullanmanız) gerekir. Bu, olağanüstü durum kurtarmaya bir karmaşıklık katmanı ekler.

Son olarak, sadece SQL Server Agent'ı çalıştırmak için bir SQL Server lisansı için ödeme yaptığınız bir konumda olmak istemezsiniz. Veritabanı hizmetten çıkarılırsa, SQL Server Agent'ı geçirmek için bir plan geliştirmeniz gerekir.

Önceki işimde bunu yaptım, çünkü işlerin hepsi en görünür sunucu olan merkezi, birincil kümemizden yürütülüyordu. Bir grup sunucudaki komut satırı öğelerini kontrol etmek yerine tüm zamanlanmış görevlerimizi tek bir yerde görebiliyordum.

Bu büyük ölçüde öznel olsa da (ve bu formatta "doğru" bir cevap elde etmek zor olacaktır), bu yaklaşımda tek bir başarısızlık noktası olmaktan başka doğal olarak yanlış bir şey olduğunu düşünmüyorum.

Tüm görevler, çalışmakta olan veritabanı sunucusuyla ve çalışan SQL Server hizmetleriyle (bizim durumumuzda) etkileşime giriyorsa veya bunlara bağlıysa, bu uygun olmayabilir.

Oh, ve görevin çalıştırmaya çalıştığı sunucunun çalışmıyor olduğu durumlarda hata işleme eklemeniz gerekir - görev o sunucuda ayarlanmışsa yapmanız gerekmeyecek bir şey.

Ben ~ muhtemelen ~ SQL görev windows görev yöneticisi üzerinden almak ... Açıkçası veritabanı ile ilgili görevler için.

Hiç kod yazabiliyor veya kod yazabilecek kişilere sahipseniz, konsol uygulamaları ve bunları TopShelf (http://topshelf-project.com/) gibi bir hizmet oluşturucuya sararak biraz yapabilirsiniz. SQL Hacker için her şey için biraz ayırma almak ve aynı zamanda size kuyruk için bir katman vermeye başlamak için kolay kesmek.

Şahsen, bu konuda yeterince önemsiyorsunuz ve iyi olacağınızı düşündüğüm gotcha'larınızı yeterince biliyorsunuz. Gerçekten endişe ettiğim umursamayan / bilmeyen insanlar. Çözümlerinizi makul aralıklarla değerlendireceğinizden ve buna göre hareket edeceğinizden şüphem yok.

Başka bir seçenek de, bir mesaj kuyruğu tablosunu güncellemek üzere saklı yordamla zamanlanmış görevler için bir tablo oluşturmaktır. Daha sonra SQL Server Agent, iletileri oluşturmak ve görev durumunu güncellemek için saklı yordamı sık sık çağırır. Diğer sistemler ileti kuyruğu tablosunu bir SQL bağlantısı veya web API katmanı üzerinden JSON olarak sorgulayacaktır.