Nice article, thanks for sharing. We have a number of systems that have some high “peakedness” for CPU. It hasn’t become an issue yet, but I’ll look into this approach you’ve outlined.
In relation to skeleton567 comment(s), I would suggest a different approach to your job processing. I consider Agent as a “batch” system meant to deal with larger operations. Maintenance plans and such makes sense in Agent, as well as larger “functions” of your database application. If you are scheduling a 1 (or 5) minute job to process application data, I think you could consider other approaches.
I’ve been spending a lot of time lately with Service Broker (SSB), and the concept of asynchronous triggers. The design approach is to use a trigger on a table (in your case, the one being updated sub-minute) that first INSERTs data to another table, then sends a message to a SSB queue. Depending on the data involved (size, complexity, etc) you could put the data in the SSB message itself. Then your “processing” code that currently runs in Agent can be run from within an “activation” procedure.
If you’re interested in this approach, these 2 site www.davewentzel.com and http://www.sqlnotes.info[/url] are probably the best I’ve found so far.
Beer's Law: Absolutum obsoletum
"if it works it's out-of-date"