我是一名最近被SQL DBA负责登陆的系统pipe理员。 我可以补充说，这是一个我非常希望沉浸其中的世界。
我对我们现有的设置（DBA任务之前主要留给开发人员）的一个方面感到好奇，也就是我们的一个生产数据库的更新机制。
基本上发生的情况是，底层数据发生变化时，开发人员在开发环境中创build一个新的数据库，并将其恢复到生产环境中。 为了方便这个开发团队已经给了dbcreator权限。 这种情况一周发生一次或两次。
任何更有经验的DBA都可以发现这种方法的缺陷吗？ 我应该坚持自己处理所有的恢复（我已经写出了开发团队使用的T-SQL命令，而不是SSMS，它需要sysadmin权限浏览可用的媒体）？ 在还原过程中可能会出现问题，导致数据库脱机？
我们正在使用SQL Server 2008 R2标准版。
谢谢大家。
作为一般规则，我有一个与开发团队将更改应用到我负责的生产数据库的问题。
如果我在你的鞋子里，我会改变这个过程，所以我在生产中应用了所有的数据库更改。 这消除了（为你）的意外，并在这个过程中增加了一个新的眼睛，这是至关重要的。
我也坚信使用比较工具。 我目前的select是RedGate SQL Compare（用于结构比较）和RedGate SQL Data Compare（用于数据比较）。 如果已加载，您也可以使用Visual Studio for Database Professionals。
使用比较工具的另一个好处是可以最大限度地减less对已修改数据库的更改，同时为您提供一组脚本，您可以将其添加到源代码pipe理系统以logging每个版本。
按照此path，开发人员无需在生产数据库中拥有更高的权限，并且可以降低您的风险。 在我看来，减less接触总是好的。
我猜这是一个只读数据库？ 如果是这样，我不觉得有什么大问题。 我之前完成的方法是保存对开发数据库写入的更新脚本（在源代码控制中，当然！），然后重新应用自上次更新以来的更新。 这个方法可能比做一个完整的数据库恢复要快一点，不过如果你不经常这样做，或者恢复很小的话，这个方法可能不会太重要。 在每次更新之前快照产品仍然很好，万一有什么事情发生了可怕的错误，产品和开发分歧。