Running Jobs
You may need to run a job often, but not regularly. In such cases, instead of scheduling a job, you can simply run it manually as needed. You can also run jobs manually that have an assigned schedule. For example, even though you have scheduled a master database backup job to occur in the evening, you may want to back up the database immediately after making changes to the instance configuration.
A SQL Server instance can only run one instance of a job at a time. If a job has started according to its schedule, you cannot start another instance of that job on the same server until the scheduled job has completed. In multiserver environments, every target server can run one instance of the same job simultaneously.
You can disable a scheduled job you do not want to run. You can also stop a job while it is running. In most cases, when you issue a stop command, the current job step is canceled and any retry logic is ignored. Some job steps, such as long-running Transact-SQL statements (BACKUP) or some DBCC commands, may not respond quickly to stop requests. When you stop a job, a "Job Canceled" entry is recorded in the job history.
Multiserver Job Processing
A multiserver job is a job that a master server runs on one or more target servers. Each target server periodically polls the master server, downloads a copy of any new jobs assigned to the target server, and then disconnects. The target server runs the job locally and then reconnects to the master server to upload the job outcome status when finished.
Note
If the master server is inaccessible when the target server attempts to upload job status, the job status is spooled until the master server is accessible again.
To start a job
To stop a job
To force a target server to poll the master server
To set the polling interval for target servers
See Also
Other Resources
sysdownloadlist (Transact-SQL)
Help and Information
Getting SQL Server 2005 Assistance
Change History
| Release | History |
|---|---|
14 April 2006 |
|
5 December 2005 |
|