Running Jobs

You may need to execute a job often, but not regularly. In such cases, you can write a job once and execute it manually as needed. You can also execute jobs manually that have been assigned a 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 system tables.

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 job if you do not want it to run. You can also stop a job while it is executing. 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

You can run a multiserver job on one or more target servers. Each target server connects periodically to the master server, downloads an actual copy of any new jobs assigned to the target server, then disconnects from the master server. The target server stores a complete copy of the job locally, then reconnects to the master server to upload the job outcome status.

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