News & Opinion
Free Webcast: You Shouldn’t Use SQL Agent for Batch Processes.
SQL Server Agent is a solid scheduler for database administration and simple, database-local automation. In a small to midsize shop, it is the right tool for backing up databases, checking for corruption, and maintaining statistics.
But as a shop grows in complexity, Agent starts running into its limits, and teams find themselves duct-taping together workarounds to cover the gaps.
The problem isn’t that Agent does its job poorly: the problem is that its job is just too small.
Once your batch processes need cross-system orchestration, observability, HA-aware recovery, source-controlled deployments, replayability, security boundaries, and cloud portability, Agent is the wrong tool for that layer of the stack.
In this free webcast with JAMS Software, I’ll walks through where that ceiling shows up in batch processing and what to look for as you approach it. Register now.
Free, 3× a week
Get my new posts by email
Three posts a week, plus a Monday roundup of the best database news from around the web.
I work in a fairly large shop and we use SQL Agent for data collection – mostly because we want to minimize permissions on the account we use to collect. Instead of giving high level permissions to that account, we just give it the read permissions to get the data collected by the local agent jobs.