Press "Enter" to skip to content

Category: SQL Agent

Managing SQL Agent Jobs with DBADash

David 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 Comment

Managing SQL Agent Jobs in a Large Environment

Steve Jones shares some tips:

I 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 Comment

SQL Agent “Success” on Failure

Todd 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 Comment

Self-Healing in SQL Agent Jobs

Rob 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 Comment

Visualizing SQL Agent Job History

Andy 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 Comment

The Script-Based Nature of SQL Agent Jobs

Rob 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 Comment

Handling SQL Agent Dates and Durations

Andy 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 querying msdb.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