Andy Levy manages some SQL Agent entries:
Thank you to everyone who contributed to this month’s T-SQL Tuesday!
Here’s a roundup of the posts.
Read on for nine posts on the topic of managing SQL Agent jobs.
Leave a CommentA Fine Slice Of SQL Server
Andy Levy manages some SQL Agent entries:
Thank you to everyone who contributed to this month’s T-SQL Tuesday!
Here’s a roundup of the posts.
Read on for nine posts on the topic of managing SQL Agent jobs.
Leave a CommentChad Callihan shares a pair of tips:
These aren’t the most technical SQL Server Agent job topics, but two that came to mind were managing who jobs belong to and making sure the right steps are followed when jobs are removed.
Click through for more thoughts on both of these topics.
Leave a CommentDavid Wiseman shows off an open-source product:
For T-SQL Tuesday #186, Andy Levy asks, “How do you manage and/or monitor your SQL Server Agent jobs?”
This is a great opportunity for me to discuss how DBA Dash can help monitor SQL Agent jobs. DBA Dash is a free and open-source monitoring tool for SQL Server, created by me. It’s used to monitor thousands of SQL Server instances within Trimble alone, and it’s gaining popularity in the SQL Server community.
Read on to see how the product can help if you have a series of SQL Agent jobs.
Leave a CommentI used to work in a fairly large enterprise (5,000+ people, 500+ production SQL instances) with a small staff. It was 2-3 of us to manage all these systems, as well as respond to questions/queries/issues with dev/test systems. As a result, we depended heavily on SQL Agent.
We decided on a few principles which helped us manage jobs, with a (slow) refactoring of the existing jobs people randomly created with no standards. A few of the things we did are listed below. This isn’t exhaustive, but these are the main things I remember.
Read on for Steve’s list.
Leave a CommentTodd Kleinhans does not believe that green is good:
Far too many times, I have seen DBA(s) and others have this false sense that if the Agent run status shows green, then everything must be ok.
Click through for a funny story about a gas station robbery and examples of how a SQL Agent job can report success but actually fail. You also see this a lot with replication or tasks that are asynchronous in nature: the task is reporting that we successfully started whatever operation, but that doesn’t mean the operation itself succeeded.
Leave a CommentDeborah Melkin has three laws for robots, or at least SQL Agent jobs:
How do I manage this all?
I have scripts to create and modify SQL Agent jobs.
And those scripts get checked into source control.
And those scripts get added to the deploy process.
And most importantly, those scripts get tested in all environments from development through production.
Read on for more context around this.
Leave a CommentRob Douglas doesn’t want to click the button a second time:
Recently, someone made an off the cuff comment about using TSQL Tasks in Maintenance Plans to handle more complex logic that SQL Agent handled out of the box. I was briefly excited by the prospect of building improved logic flows directly into SQL Server Maintenance Plans. This months Andy Levy hosts TSQL Tuesday and asks us about how we handle SQL Agent Jobs and this seemed like a great opportunity for me to share a story about how I wasted an afternoon testing a few components I have a passing knowledge with, attempting to implement auto-healing and conditional logic flow, only to snap out of it a few hours later when I realized that I was trying to solve a problem that someone else cracked nearly 2 decades ago.
Click through for the example. Some people might think of this kind of spelunking as a waste of time. My counter-argument is that it is better to know three ways of doing a thing versus one, as inevitably, you’ll run into the situation in which the one way is either not workable or is such a bad option that it’s painful to implement.
Leave a CommentAndy Levy wants a picture or at least a thousand words:
If you don’t have a monitoring suite watching SQL Agent, or you want to get a bigger picture view of when and how your Agent jobs are running,
dbatools
can help you shortcut getting this information.Get-DbaAgentJobHistory
does exactly what its name suggests – it fetches the execution history for one or more Agent jobs on one or more SQL Server instances. Thing is…it can produce a lot of output if you’re not careful.
Read on to see how you can use this to generate a visual indicator of when your jobs are running and how they fare.
Leave a CommentRob Farley praises the textual nature of SQL Agent jobs:
Of course, there are some things that I don’t like about SQL Agent. For example, I’ve never been a big fan of the Operator stuff. I’m sure there are organisations that leverage every feature of it, including pagers, but that has never been me or my clients. Reports that show the status of the jobs are generally more useful than simply relying on Job Notifications (although this also varies from client to client), but on the whole, it’s an area I’m okay, but not writing home about.
The thing I’m going to write about today though – one of my favourite aspects of SQL Agent Jobs – is that it’s all so scriptable.
Read on to learn more. I agree with Rob: it took a little while for me to understand (i.e., actually read what the job is doing), but I like that there’s nothing magical about SQL Agent and that you can simply put this into source control or even draft your own jobs without the UI once you understand the process well enough.
Leave a CommentAndy Mallon disparages some Microsoft intern’s summer of 1996 project:
SQL Agent’s schema is older than me. It handles dates, times, and durations like it’s 1980 by using integers instead of date/time data types. My buddy Aaron Bertrand talks more about Dating Responsibly so that you can have a good datetime with your own database.
I was writing a query to pull recent job failures from SQL Agent’s
msdb
job history, and knew that I didn’t want to deal with the wonky date/time formats. Specifically, I was queryingmsdb.dbo.sysjobhistory
to find the Start Time, End Time, and Duration of job runs that failed. If you aren’t familiar with that table, you can look at it over in the docs.
Andy does point out the built-in function but then explains why a separate function is superior. Andy also happens to furnish that function, so check it out.
Comments closed