Home > Articles > Data > SQL Server

SQL Server Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

Automating Tasks with SQL Server Agent

Last updated Mar 28, 2003.

Computers excel at doing things over and over the same way, every time. So it stands to reason that you should use the computer to automate the things that you need to do in SQL Server repeatedly. Of course it's easier for the computer to do the work, but more than that if you take your time automating a process properly, you guarantee that it will be done properly (or at least consistently) every time.

Like Microsoft Windows, SQL Server includes a facility to automate tasks. You can also use it for more than just SQL Server activities as I'll explain shortly. This facility involves three main parts: The SQL Server Agent Service, SQL Server Agent Jobs, and the msdb database. These are all often referred to as “The Agent” or “SQL Agent”, because they work in concert to perform tasks that you specify, either on-demand or on a schedule.

SQL Server Agent Service

The first part of SQL Server automation is the SQL Server Agent Service. The SQL Server Agent is a set of software components on the server and a service for each instance of SQL Server installed. On SQL Server 2000, if the only instance is installed the service is called SQLAgent. For every instance after that, it's called SQLAgent$InstanceName. For SQL Server 2005 and higher, the default instance is called SQL Server Agent, and for each named instance installed after that it is called SQL Server Agent (InstanceName).

There are two important considerations for this service account. The first is that it needs to be started. Unless the service is started, no automation occurs. You can check to see if the service is started at the command line in the operating system with this command:

NET START

Once you run that command, look for the service names I just described. You can also use the Windows Services Control Panel applet to check the state of the service. In SQL Server 2005 and higher however, you should use the SQL Configuration Manager tool, because it performs other tasks for you. In most cases, you'll want the Agent service set to Automatic so that it starts up when the server does.

The second important consideration with this service is the account you use to start it. The service should be started with an account that has sufficient privileges to access any drives, systems or network shares you might to use in an automation task. But it's important that the account has only the rights and privileges it absolutely needs – in the previous graphic this system is using the local administrator's account, which is far too powerful. Again, you should set this system using the Configuration Manager in SQL Server 2005 and higher, since that tool will handle things like granting the account the “logon as a service” right in Windows, and access to the msdb database and so on.

Another important consideration for setting each instance’s Agent account to a different Windows account is that when activities and errors are logged, they are tagged with this name. If they are all the same, it’s more complicated to do troubleshooting and performance tuning.

I recommend that you create a service for the SQL Server Agent and give it very limited permissions on the server. You can read more about what the account needs to be able to do in Books Online.

If you set up a regular user account to start the Agent, you need to make sure that you consider the password policies that account has. If its password will expire, make sure you send yourself a reminder to change it in the services control panel, or the Agent will fail to log on and run. If you decide to override that policy for this account, make sure the password is very complex so that it can't be compromised easily. And keep that password safe! Allowing others to know the password in effect gives them the keys they need to compromise your systems.

SQL Agent Jobs

Within SQL Server, the Agent interacts through Jobs. Jobs are a combination of steps, notifications and schedules.

The Jobs object can be graphically controlled in Enterprise Manager (SQL Server 2000) under the SQL Server Group | ServerName | Management area.

In SQL Server 2005 and higher, you can use SQL Server Management Studio (SSMS) and open the SQL Server Agent object directly under the instance name.

In both versions, Jobs contain steps. A step is a unit of work, which can be as varied as a Transact-SQL script all the way to an operating system command or ActiveX code, and in SQL Server 2008 and higher even PowerShell scripts. This is why you'll want to restrict the users that have access to this facility.

You can also link steps in the Job based on success or failure, forming rudimentary branching logic. For instance, you could make a Transact-SQL step that checks a table, and another that runs if that fails to log the information.

You don't have to create your own logging process, however, since both Jobs and steps are logged for you. There are also notifications that the Job can send, if you have an operator set up. I'll show you that in another tutorial. The Job has a history associated with it, that you can find by right-clicking the Job and selecting “View History” from the menu that appears. This information is kept in tables in msdb.

SQL Server Agent also has its own set of Error Logs in SQL Server Management Studio. Open the Error Logs area and select the SQL Server Agent.

The last part of the Job is the schedule. You can create a schedule at the Job level that runs once, repeatedly, on a certain day or a certain date. Clicking the Schedule tab when you create the Job allows you to pick an existing schedule you’ve created earlier or create a new one.

With the Job created you can enable it to run. Disabling the Job allows you to keep it around but not run it.

The msdb Database

SQL Server Agent and its Jobs with steps and schedules are all controlled by tables in the msdb database. The SQL Server Agent uses the tables that start with dbo.sysJobs* in the msdb database, and in the latest versions it uses other tables there as well. Books Online for each release has the affected tables for the SQL Server Agent.

There are also several stored procedures that you can use to create, control and monitor SQL Server Agent Jobs. Here are a few, starting with the ones that show you information about various Jobs:

sp_help_Job

sp_help_Jobactivity

sp_help_Jobschedule

sp_add_Jobserver

sp_add_Job

sp_add_Jobstep

sp_add_schedule

sp_attach_schedule

sp_update_Job

sp_delete_Job

sp_start_Job

sp_stop_Job

I'll cover and use these in greater detail in future tutorials. I’ve linked them here for you to reference easily.

You can also use the SQL Server Agent to automate tasks involving more than just one server. I'll cover that more later, and in the next tutorial I'll show you how to put this information to use and monitor your backups on a server. You can easily extrapolate the example to multiple servers.

InformIT Articles and Sample Chapters

In a chapter from the book SQL Server 2005 Management and Administration called "Administering the SQL Server 2005 Database Engine," there’s a section on the SQL Server Agent called Administering the SQL Server Agent.

Books and eBooks

And there are newer references as well — Ross Mistry covers SQL Server 2008 administration in his book called Microsoft SQL Server 2008 Management and Administration.

Online Resources

The main site to start with is Books Online, Online. Microsoft has a series of articles starting here on the SQL Server Agent.