我是一名系统管理员，最近被任命担任 SQL DBA 的职务。我毫不犹豫地补充说，我非常希望融入这个世界。
我对我们现有设置的一个方面感到好奇（DBA 任务以前大部分留给开发人员），即我们其中一个生产数据库的更新机制。
本质上，每当底层数据发生变化时，开发人员就会在开发环境中创建一个新数据库，并将其恢复到生产环境中。为了实现这一点，开发团队被授予了 dbcreator 权限。这种情况每周发生一到两次。
任何经验丰富的 DBA 都能发现这种方法的缺陷吗？我是否应该坚持自己处理所有恢复（我已经为开发团队编写了 T-SQL 命令，而不是需要系统管理员权限才能浏览可用媒体的 SSMS）？恢复过程中是否会出现问题，导致数据库脱机？
我们正在使用 SQL Server 2008 R2 标准版。
谢谢大家。
答案1
一般来说，我对开发团队对我负责的生产数据库应用更改感到不满。
如果我处于您的位置，我会改变流程，将所有数据库更改应用于生产。这可以消除（对您而言）意外，并在关键时刻为流程增添新的视角。
我也坚信使用比较工具。我目前的选择是 RedGate SQL Compare（用于结构比较）和 RedGate SQL Data Compare（用于数据比较）。如果您已加载 Visual Studio for Database Professionals，您也可以使用它。
使用比较工具的另一个好处是，它们最大限度地减少了对已修改数据库的更改，同时为您提供了一组脚本，您可以将这些脚本添加到您的源代码控制系统中以记录每个版本。
按照这种方式，开发人员就无需在生产数据库中拥有更高的权限，并且可以减少您的风险。在我看来，减少风险总是好的。
答案2
我猜这是一个只读数据库？如果是这样，我认为它没有什么大问题。我以前这样做的方法是保存针对开发数据库编写的更新脚本（自然是在源代码控制中！），然后将自上次更新以来的脚本重新应用于生产。这种方法可能比执行完整的数据库还原要快一点，但如果您不经常执行此操作或还原量很小，这可能不太重要。在每次更新之前对生产进行快照仍然是个好主意，以防出现严重错误并且生产和开发出现分歧。