最近，我们遇到了主要的生产问题，因为我们的一个团队成员在SQL连接中编写了错误的代码。
我们在SQL Server中有50个数据库。
我们是否创建了服务器级触发器，以便在任何数据库表记录更改（更新，删除）的情况下，我们收到了警报邮件？
注意：我正在考虑服务器级触发器而不是单个表级触发器
（似乎OP正在就生产版本中的失败实施哪种解决方案提出建议 - 听起来有一个惊人的爆炸。）
答案是，这取决于。 Stack Overflow更适合解决特定问题，而不是提供建议和培训（即，为我们提供给您提供问题的代码）。但是，我至少会尝试给你一些事情来考虑，以便在你的路上帮助你。也许，这些答案可以让您更好地阐明您将来要解决的问题。
解决方案1：创建UPDATE / DELETE触发器以保留对数据库的更改，以便可以从姐妹表中轻松还原损坏的数据（而不是进行数据库还原）。为此，请参阅How to Create Trigger to Keep Track of Last Changed Data。我不喜欢这个想法，因为你正在复制数据，并可能导致数据维护的噩梦。
解决方案2：在整个设计过程中实施审计，方法是向所有表和数据库添加Create（对于INSERT）和Update列，每个列存储两个存储时间戳和用户名（总共4列）。这似乎不太可能，因为您的公司已经拥有50个数据库，其中包含未知数量的表和作业（注意：需要更新作业以反映此更改并重新部署）。
但是，遵循这个原则是一个很好的原则，因为您可以在不必复制数据的情况下跟踪系统何时以及由谁进行更改（解决方案1）。这使得追踪问题和识别不良数据成为一项简单的任务。修复错误后，您可以在包含所有带有错误数据的时间戳的时间段内重新运行作业，以便可以修复数据。这也是一个很好的（完美？）测试用例来验证错误修复。您可以通过添加一个单独的审计表来更进一步，所有作业都会报告作业名称，运行时间，进程日期，文件名，文件夹路径，记录计数（INSERT，UPDATE，DELETE，ERROR，BYPASS），等等
然后，为事实表实现外键，以便于交叉引用。请记住，您可以使用维度表规范化此任务。从设计和开发的角度来看，这是一项很多工作，但是当试图通过提供清晰简洁的表驱动记录的人员，内容，在哪里，它将为DBA和开发人员节省时间和理智。 ，何时以及为什么 - 而不是挖掘日志，或者更糟糕的是，未能在当前数据模型中识别问题。
可能有更多的解决方案可以遵循这一点，但上面两个封装了我能想到的整个解决方案领域，即：没有最佳解决方案来修复糟糕的设计，编码和回归测试。您可以使用触发器对其进行乐队助手，或者实施可以对您的表格进行一些审核的设计方法。