Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
Microsoft SQL Server Administration
- The DBA Survival Guide: The 10 Minute SQL Server Overview
- Preparing (or Tuning) a Windows System for SQL Server, Part 1
- Preparing (or Tuning) a Windows System for SQL Server, Part 2
- Installing SQL Server
- Upgrading SQL Server
- SQL Server 2000 Management Tools
- SQL Server 2005 Management Tools
- SQL Server 2008 Management Tools
- SQL Azure Tools
- Automating Tasks with SQL Server Agent
- Run Operating System Commands in SQL Agent using PowerShell
- Automating Tasks Without SQL Server Agent
- Storage – SQL Server I/O
- Service Packs, Hotfixes and Cumulative Upgrades
- Tracking SQL Server Information with Error and Event Logs
- Change Management
- SQL Server Metadata, Part One
- SQL Server Meta-Data, Part Two
- Monitoring - SQL Server 2005 Dynamic Views and Functions
- Monitoring - Performance Monitor
- Unattended Performance Monitoring for SQL Server
- Monitoring - User-Defined Performance Counters
- Monitoring: SQL Server Activity Monitor
- SQL Server Instances
- DBCC Commands
- SQL Server and Mail
- Database Maintenance Checklist
- The Maintenance Wizard: SQL Server 2000 and Earlier
- The Maintenance Wizard: SQL Server 2005 (SP2) and Later
- The Web Assistant Wizard
- Creating Web Pages from SQL Server
- SQL Server Security
- Securing the SQL Server Platform, Part 1
- Securing the SQL Server Platform, Part 2
- SQL Server Security: Users and other Principals
- SQL Server Security – Roles
- SQL Server Security: Objects (Securables)
- Security: Using the Command Line
- SQL Server Security - Encrypting Connections
- SQL Server Security: Encrypting Data
- SQL Server Security Audit
- High Availability - SQL Server Clustering
- SQL Server Configuration, Part 1
- SQL Server Configuration, Part 2
- Database Configuration Options
- 32- vs 64-bit Computing for SQL Server
- SQL Server and Memory
- Performance Tuning: Introduction to Indexes
- Statistical Indexes
- Backup and Recovery
- Backup and Recovery Examples, Part One
- Backup and Recovery Examples, Part Two: Transferring Databases to Another System (Even Without Backups)
- SQL Profiler - Reverse Engineering An Application
- SQL Trace
- SQL Server Alerts
- Files and Filegroups
- Full-Text Indexes
- Read-Only Data
- SQL Server Locks
- Monitoring Locking and Deadlocking
- Controlling Locks in SQL Server
- SQL Server Policy-Based Management, Part One
- SQL Server Policy-Based Management, Part Two
- SQL Server Policy-Based Management, Part Three
- Microsoft SQL Server Programming
- Performance Tuning
- Practical Applications
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
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:
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:
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.
The main site to start with is Books Online, Online. Microsoft has a series of articles starting here on the SQL Server Agent.