供应商希望每5分钟运行一次MSDB作业以进行业务应用程序

我们有一个第三方供应商试图将两个数据库都驻留在我们的SQL Server实例上的两个不同的应用程序与150多个其他数据库进行集成，并且他们想创建一个MSDB作业，以每5分钟“同步”这两个不同的应用程序（首先，他们想每分钟运行一次）。

我最初的直觉是，他们应该以Windows计划的作业，或者甚至是可怕的触发器（在这种情况下通常采用这种方法）在Application层中以某种方式执行此操作。

我宁愿尽可能多地为DBA任务保留MSDB作业，以减少混乱，而且在查看具有此类活动的超级作业时的作业历史时，MSDB的查询速度也很慢（这也会淹没和丢弃重要的作业历史）更重要的事情，例如备份历史）。但是话又说回来，也许我的首选项是错误的，我需要在MSDB中为应用程序层腾出一些空间，并袖手旁观，解决工作历史记录的问题，因为当我需要保留更多历史记录条目来捕获工作记录时，这些问题会永远载入重要内容，例如备份（或清除超级活动作业条目）。

我遇到的另一个问题是，当他们通过GUI执行升级时，我现在需要给该供应商“ sysadmin”权限，而不是仅对他们的DB授予“ dbo”权限，并希望他们不要破坏我的关键任务实例数据库是（整合的缺点之一）。

我想我可以把它们放在另一个“分离”的情况下，我们把所有的不玩好供应商，但这时我们就需要重新配置应用程序以指向新的SQL实例（叹可惜在这种情况下，不平凡的）。

供应商已经回避了我的担忧，谈论触发器的糟糕程度。因此，我对此进行了“搜索”，然后空了出来。有没有人看到任何链接“权威的外观”，这是一个坏主意，我可以推荐给他们？还是我应该接受他们的方法？

我不相信在寻求帮助之前我从未在sql论坛中发布过，所以希望我的查询框架正确。

编辑：我们正在运行SQL Server 2008 Enterprise R2 x64 SP1（感谢您指出我忘记提及版本！）。嗯，希望他们在使用新版本时不需要更改MSDB升级脚本。

谢谢你的时间！丰富

IMO您的供应商实际上是在正确的轨道上。

应用程序层的工作将需要他重做许多现成的SQL Agent功能（例如，不运行已运行的工作的逻辑，提供安全性和凭据存储解决方案，将工作结果与错误报告和SQL等结果等结果跟踪）。并且，最重要的是，为计划提供备份/ HA / DC解决方案。你不希望你的灾难恢复的故事是“和你完成恢复备用服务器去创建这些50个NT调度任务后”。因此，他反对使用系统调度程序是正确的，它没有代理所具有的功能。

在阻止触发器方面，他显得更加正确。用同步触发器替换定期作业会增加请求等待时间，增加内聚和耦合（认为架构更改...），由于同步问题（触发错误->应用程序错误vs.作业错误->修复并稍后重试）会增加停机风险。 ，这大大增加了死锁问题（由于被跟踪者/被跟踪者之间的交叉更新），并且还有许多其他问题。

最简单的解决方案确实是代理作业，msdb绝不保留给DBA。一个更合适的解决方案是使用对话计时器和内部激活，这相对于代理作业具有一些优势，这主要是由于包含问题（一切都在应用程序数据库中，请考虑镜像故障转移方案），但是我可以完全理解您的供应商是否不愿意尝试一些需要非常具体的知识的东西。顺便说一句，我希望您不要表示每个DB每5分钟要做一份工作。

至于sysadmin权限：游戏的名称是code signing。您可以通过使用您的私人证书签名来授予对经过您检查和验证的特定过程的任何许可。

我个人的喜好是使用触发器来处理至少部分同步。我并不特别关心预定的轮询同步，因为您必须处理潜在的冲突，陈旧的数据，重复作业的性能影响等。如果他们想在1到5分钟内积极进行，这是为了减轻冲突和陈旧性，而立即触发即可解决该问题。

如果所有事情都发生在同一服务器上，则可以将同步代码放入触发器中，或者让触发器调用一个存储过程来同步每个受影响的记录。如果同步跨越服务器，或者您要确保使一个数据库脱机不会阻止其他数据库的使用，请考虑使用Service Broker处理异步更新。我这样做是为了在两个不同服务器之间将销售条目数据与CRM数据同步，同时允许其中一个服务器脱机而不影响另一个应用程序。备份后，Service Broker将传递消息并更新远程服务器上的数据。

触发器确实没有内在的坏处，但是像T-SQL的大多数方面一样，编写可怕的代码也是很有可能的。我写了一篇有关触发器常见陷阱的文章，如果有帮助的话。

编写行为良好的触发器