我的团队目前安排作业的方式是通过 SQL Server 作业代理。其中许多作业依赖于其他内部服务器，而这些服务器又具有自己的 SQL Server 作业，需要运行这些作业以保持其数据最新。
这在我们每个 SQL Server 作业的开始时间和长度上产生了依赖关系。作业 A 可能依赖于作业 B 的完成，因此我们提前将作业 B 安排到作业 A 的某个估计时间。所有这些过程都非常主观且不可扩展，因为我们添加了更多的作业和服务器，这会产生更多的依赖关系。
我很想摆脱主观安排这些工作的业务，并希望多米诺骨牌按正确的顺序排列。我想知道安排 SQL Server 作业的公认做法是什么。人们是否使用 SSIS 将工作链接在一起？SQL Server 作业代理中是否已内置工具来处理此问题？
处理相互依赖的多个 SQL Server 作业的调度的公认方法是什么？
我之前使用过 Control-M 在不同的环境中安排多个相互依赖的作业。Control-M 通常通过使用批处理文件（据我记得）来执行 SSIS 包。
我们有一个复杂的环境并排托管 2 个数据仓库（1 个国际数据仓库和 1 个美国本地数据仓库）。有些工作依赖于其他工作，而这些工作依赖于其他工作等等，但是通过使用 Control-M，我们可以轻松地确定依赖关系（它有一个非常漂亮和直观的 GUI）。我想到的其他工具是潮汐调度器。
工作安排没有固定的标准，但我认为可以肯定地说工作安排完全取决于组织的需求。例如，财务工作可能依赖于销售和库存销售等。但关键是，如果您需要工作间的依赖关系，使用 Control-M 等第三方软件是一个安全的选择。它可以控制不同环境下的工作，让您真正了解公司范围内的工作控制。
我们也需要管理多个代理工作之间的依赖关系——在查看了各种第 3 方工具并出于各种原因（主要是与使用第 3 方软件相关的内部限制）打折之后，我们决定创建自己的解决方案。
该解决方案以配置数据库为中心，该数据库包含有关需要运行的进程（作业）以及它们如何分组（批次）以及进程之间的依赖关系的详细信息。
使用的配置表总结：
批处理 - 一组相关进程的高级定义，包括元数据，如最大并发进程和当前批处理实例等。进程 - 与进程（作业）相关的元数据，如名称、最大等待时间、最早运行时间、状态（启用/禁用）、批处理（进程所属的批处理）、进程作业名称等。 批处理实例 - 给定批处理的活动实例 进程实例 - 给定批处理的进程的活动实例 进程依赖 - 依赖矩阵 批处理实例状态 -查找批处理实例状态 Process Instance Status - 查找流程实例状态
每个批次有 2 个控制作业 - START BATCH 和 UPDATE BATCH。第一个处理启动属于它的所有进程，第二个是在任何给定批次中运行的最后一个，并处理更新结果状态。
每个进程都有一个与之关联的代理作业，该作业由 START BATCH 作业执行 - 进程具有上限并发（在批处理配置中定义），因此进程一次最多启动 x 个，然后 START BATCH 等待直到空闲槽在开始下一个进程之前可用。
流程代理作业步骤调用一个模板化的 SSIS 包，该包处理实际的 ETL 工作以及围绕流程是否需要运行以及是否必须等待依赖项等做出的决策。
我们目前正在寻求转向 Service Broker 解决方案，以获得更大的灵活性和控制力。
无论如何，这里可能有太多细节和没有足够的例子，所以 VS2010 项目可根据要求提供。
我不确定这会有多大帮助，但我们最终创建了一个用于日程安排的电子邮件解决方案。
我们构建了一个访问交换邮箱的电子邮件阅读器。工作完成后，他们会向邮件阅读器发送一封电子邮件以开始另一项工作。另一个不错的部分是大多数应用程序都内置了电子邮件通知，因此自定义编程的方式确实不多。
我们实际上只是首先构建它来处理来自许多其他合作伙伴的数据文件。给他们一个电子邮件地址比给他们设置一个 ftp 站点等要容易得多。
邮件阅读器应用程序现在已经发展到包括基本过滤、时间安排、使用信号量来防止并发作业等。它真的很好用。