如要让数据库进行自动管理，则管理员需要预先定义一些可预测的管理任务以及这些任务发送的条件。当满足这些指定的条件，则数据库会自动运行管理员指定的操作。使用自动管理来处理日常事务，则让管理员可以抽出时间去关注其他的事情，如数据库优化等等更加具有价值的作业。
计划就是自动化管理组件的一个成员。计划指定了作业运行的时间。多个作业可以根据一个计划运行;多个计划也可以应用到一个作业。但是这个时间跟我们普通上的几点几分又有差异。这个时间不仅指特定的日期或者时间，而且还可以表示特定的时间。如当SQL Server代理启动的时候或者服务器的CPU使用率处于定义的空闲状态水平时。也就是说，这里指的时间计划也可以实现一定的条件状态控制。简而言之，计划作业就是定义使得作业在没有哦能够互交互情况下开始运行的条件，包括具体的日期或者特定的在状况。通过为作业创建新计划或者将现有的计划添加到作业可以将作业计划设置为自动运行。不过在设置自动执行计划的时候，需要注意一个问题。即一次只能够运行一个作业实例。假如在作业按计划运行时尝试手工运行该作业，则SQL Server代理将拒绝这个请求。另外，即使计划未启用，作业仍可以为响应警报而运行，或者由用户手动运行。假如作业计划未启用，则任何使用该计划的作业都不会启用该计划。
一、 计划触发的时间与事件。
上面笔者说过，计划可以基于特定的时间与事件而触发。那么这些具体的时间与事件是什么呢 笔者平时用到的最多的就是如下几种情况。
一是特定的日期和时间运行一次。这个计划时间在数据库备份的时候特别有用。大家都知道，数据库备份会占用比较多的系统资源。假如在数据库服务器使用高峰期(如白天上班时间)进行备份的话，那么会对用户的访问造成比较大的影响。为此笔者就把数据库备份的时间放在晚上12点之后。这个时段相对来说，很少有用户会访问数据库。此时管理员就可以利用计划功能，让其在每天的12点之后进行数据库备份。这就是基于特定的日期和时间计划的典型应用。
二是安重复执行的计划运行。这个跟上面讲的特定日期和时间运行一次比较类似。只是上面的情况只运行一次。而这个按重复执行计划运行则是指会重复运行多次。如每天晚上12点都进行数据库备份等等。在实际工作中，特定日期和时间运新一次往往只是针对一些特殊的情况。如今天刚对数据库结构进行了比较大的更改，如添加了几张表或者视图，此时就需要对数据库进行一次完全备份。如故不急于进行备份的话，则就可以建立一个在特定的日期和时间运行的数据库完全备份计划，让其在午后进行数据库备份。但是对于常规的数据库备份，则需要采取这个按重复执行计划运行。
三是当计算机的CPU使用率处于定义的空闲状态水平时。也就是说，数据库服务器当前的CPU使用率比较低，可以执行其他一些比较复杂的管理任务。如有些数据库系统在设计的时候，有一个库存补货点作业。当库存低于安全库存的时候，系统就会自动生成一张物料请购单，来满足安全库存的需要。由于这张表设计到的物料比较多，会占用比较多的系统资源。故可以设置每天运行一次，而运行的时间就定在CPU使用率比较低的时候。如此就可以减少对其他作业造成的负面影响。
二、 CPU空闲计划的典型应用。
其他的几种计划类型，不少数据库管理员已经非常了解。笔者今天想谈的是CPU空闲计划的应用。这个计划假如应用的好的话，可以大大提高数据库的性能。假如要想利用好这个功能，则需要回答如下两个问题。
一是什么作业需要使用CPU空闲计划 这个问题比较难回答。从理论上来说，任何作业都可以采用CPU空闲计划在自动执行。只是他们带来的效果不同。有的作业即使采用了CPU空闲计划，也不能够带来很大的性能改善。简单的来说，一些占用CPU资源比较大的作业，采用CPU空间计划规则来自动执行，可以取得比较好的效果。如数据库有时候需要重新生成索引，这项工作会占用比较多的CPU资源。而且随着数据量的增多，这个CPU使用率也会越来越高。为此，假如可以把重新生成索引的作业，放在CPU空闲时间来进行的话，那么对于提高数据库的性能效果是比较明显的。总之当某个作业比较复杂，可能需要占用到比较多的CPU或者内存资源的话，则可以采用这个CPU空闲计划。
二是什么时候CPU是空闲的 空闲是一个相对的标准。有时会CPU使用率30%以下可以定义为空闲;而有时候CPU使用率只有不到60%，就是空闲。这要根据服务器的配置已经所部属的应用来考虑。所以管理员在采用CPU空闲计划之前，先要对服务器进行观测一定时间，采用性能监视器等工具来监视服务器流量并收集相关的统计信息。然后利用收集到的信息来分析CPU空闲的标准，并在数据库中进行相关的设置。将 CPU 空闲条件定义为一个百分比，在该百分比以下，CPU 使用率必须持续指定的时间。然后，设置持续时间长度。假如 CPU 使用率在指定时间内低于指定的百分比，则 SQL Server 代理将启动具有 CPU 空闲时间计划的所有作业。如管理员认为CPU使用率在35%以下可以运行重建索引的作业，即当这个重建索引作业运行时CPU使用率在可以忍受的范围之内，此时就可以把CPU的空闲率标准设置为35%。而且这个低于35%的CPU使用率必须要持续一段时间。如这个低于35%的CPU持续时间很短，那么系统仍然不会认为这个CPU是出于空闲状态。这个持续时间最好能够参考具体作业的执行时间。若重建索引作业所需要的时间等等。
三、 如何停止计划的自动执行
有些时间我们可能并不需要自动执行计划。如在数据库设计的时候，管理员并不需要这些自动执行的计划。为此需要把他们暂时停止。此时有哪些方法可以做到这一点呢
一是可以把计划与作业剥离。计划与作业是两个独立的内容。如数据库完全备份与计划时间就是相互独立的。假如设置好了数据库完全备份的策略，但是没有把计划时间与这个作业进行关联的话，则数据库完全备份不会自动执行。此时假如需要执行这个作业的话，则就要进行手工启动。故当管理员暂时不想要某个计划的时候，可以把计划作业剥离，即在作业中去掉这个时间计划即可。
二是禁用作业或者计划。当管理员不需要某个作业自动运行的时候，可以把这个计划或者作业进用掉。禁用计划或者禁用作业都会让某个作业停止自动运行，但是他们仍然有微小的差异。如禁止计划的话，只是这个这个作业停止自动运行，但是管理员仍然可以手工执行它。可是禁用作业的话，则系统不仅不会自动运行，而且管理员还不能够手工执行它。这就好像给这个作业设置了终身监禁。为此，为了避免这种情况的发生，笔者是建议最好采用禁用计划而不是禁用作业。如此的话，在必要的时候管理员还可以手工启动该作业来应急。另外，假如这个计划将来仍然需要采用的话，笔者不建议把计划与作业剥离的方式来停止计划的自动执行;而是建议这种禁用计划的方式来完成。不然的话，下次需要的时候仍然需要把计划与作业关联，反而会增加工作量。
另外，假如这个测试计划以后再也不用时，有两种处理方法。一是把计划直接删除。这个是最彻底的方法，但是不会留下任何历史纪录。二是先把计划跟作业玻璃，然后再禁用这个计划。这虽然比较麻烦一点，而且会在数据库中留下垃圾数据。但是却可以保留历史纪录。这可能会对数据库的后续维护带来一定的帮助。到底不用的计划是删除还是禁用，没有一个统一的标准。还是需要根据数据库管理员的操作习惯来判断。
无论采取哪种方式，管理员都需要注意两点内容。一是必须显示的重新启动已禁用的计划。假如管理员只是更改了已禁用的计划策略，并不会重新启动这个计划，而需要管理员手工的启动。二是即使计划未启用，作业仍可以为响应警报而运行，或者由用户手动运行。假如作业计划未启用，则任何使用该计划的作业都不会启用该计划。