如何将意外修改错误数据库的风险降至最低？

Question

我刚刚了解到，在对象资源管理器中断开与服务器的连接并不会阻止您执行已经在该服务器上打开的查询窗口。

我的情况是这样的：我有一个 SSMS 实例，用于连接到我们的开发/登台服务器和我们的生产服务器。我不得不在 dev 上删除一堆数据，所以我想我应该关闭与生产的连接，但我没有注意我正在使用的查询窗口。（幸运的是，我们只有几个小时前的备份。）

我不是第一个破坏生产数据的人，也不会是最后一个，我敢肯定。因此，我正在寻找可帮助您将在错误数据库上执行查询的风险降至最低的清单、最佳实践等。您以前是否遇到过这种情况，您是如何调整工作流程以尽量避免这种情况的？

Answer 1

我喜欢在 SSMS 中做的一件事是在连接到数据库时使用自定义颜色。因此，您为 Live 数据库选择漂亮的亮红色，为开发或测试系统选择柔和的蓝色或绿色。我曾经使用内置的 SSMS，但现在我更喜欢 SSMS 工具插件颜色编码。

或者像 SSMS 工具这样（一个非常好的插件，我发现它在顶部时颜色更好，而不是像内置的那样在底部）

Answer 2

为生产更改创建第二个用户帐户并撤销您的帐户当前拥有的访问权限。当您想在生产中进行操作时，您可以以第二个用户身份运行 ssms。

编辑：这只会在域登录的情况下有益。如果您有两个单独的域帐户，您将被迫为 DEV 和 PROD 拥有单独的 SSMS 实例。如果您没有使用域帐户，这个建议不会真正帮到您。

此外，如果您使用单独的域帐户，您可以调整每个用户的 SSMS 颜色设置，可能为连接到 PROD 的帐户使用亮红色背景。

这是一个很好的白皮书，我也想到了：http : //download.microsoft.com/download/D/2/D/D2D931E9-B6B5-4E3B-B0AF-22C749F9BB7E/SQL_Server_Separation_of_Duties_White_Paper_Jul2011.docx

它讨论了诸如不授予您的日常登录帐户完全 SA 访问权限之类的问题。

Answer 3

根据谁你问，这将需要多一点的工作，但我一直在使用下面的语句习惯了所有的生产或试生产的查询窗口，并为所有UPDATE，DELETE并INSERT在所有环境中的语句。

BEGIN TRAN
-- END OF QUERY WINDOWS
ROLLBACK TRAN
PRINT 'Transaction rolled back.'

如果我看到这个，我会立即知道，“哎呀，那个查询窗口仍然连接着”或“哦，废话，我自动做了一些我不应该做的事情” - 是的，你可以在对象资源管理器中关闭数据库，但是查询窗口仍然可以连接。在我看来，所有生产查询都应该突出显示并使用BEGIN TRAN; 一个意外的 F5，应该回滚所有内容，而不是COMMIT. 这会迫使用户意识到他或她的行为；类似于给你吃的每顿饭拍张照片会帮助你减肥，因为你必须停下来想想你在做什么。

是否需要更长的时间来完成？是的。它是否可以阻止 100% 的错误。是的，因为没有任何内容提交，除非我手动强制COMMIT, 后键入它，其本质将迫使我考虑COMMIT.

Answer 4

在我的一份工作中，我们为此开发了一种工具。

如果您想在 PROD 上运行一条语句，它会强制您编写：

run_sql servername PROD <file_with_sqlstatements>.sql

它将结果写入日志文件并将执行附加到我们管理数据库的日志中。例如，当我们想弄清楚谁是最后一个更改某个桌子的人时，它就非常方便。

在 SSMS 中，当您注册了服务器时，您可以将某种颜色应用于连接，例如所有 PROD 连接的底部都有红色。但如果可能的话，最好避免在生产服务器上使用 GUI 工具。