大约 7 年前，我在加班后为客户的数据库生成更改脚本。我只更改了存储过程，但是当我生成 SQL 时，我检查了“脚本相关对象”。我在本地机器上运行它，一切似乎都运行良好。我在客户端的服务器上运行它，脚本成功了。

然后我加载了该网站，该网站是空的。令我震惊的是，“脚本相关对象”设置为我的存储过程触及的每个表都做了一个 DROP TABLE。

我立即打电话给首席开发人员和老板，让他们知道发生了什么，并询问可以找到数据库的最新备份在哪里。其他 2 位开发人员参加了会议，我们得出的结论是，甚至没有备份系统到位，也无法恢复任何数据。客户丢失了他们整个网站的内容，而我是根本原因。结果是我们的客户获得了 5000 美元的信用。

对我来说这是一个很好的教训，现在我对运行任何更改脚本和首先备份数据库都非常谨慎。我今天还在同一家公司工作，每当出现关于备份或数据库脚本的笑话时，总会有人提起著名的“DROP TABLE”事件。

我发现我不理解 Oracle 重做日志文件（术语？这是很久以前的事了）并且丢失了一个星期的交易数据，这些数据必须从纸质票据中手动重新键入。

有一线希望 - 在我输入的周末期间，我学到了很多关于我的交易输入屏幕的可用性的知识，此后改进了很多。

初级 DBA 的目标：

delete from [table] where [condition]

相反，他们输入：

delete [table] where [condition]

哪个是有效的 T-Sql 但基本上完全忽略了 where [condition] 位（至少在 MSSQL 2000/97 上是这样的 - 我忘记了）并擦除整个表。

那很有趣:-/

我删除了实时数据库并删除了它。

经验教训：确保您了解您的 SQL - 并确保在接触内容之前进行备份。

update Customers set ModifyUser = 'Terrapin'

我忘记了 where 子句 - 很无辜，但是在有 5000 个客户的桌子上，我的名字会出现在每条记录上一段时间......

经验教训：使用事务提交和回滚！

我曾经设法编写了一个永不退出的更新游标。在 2M 行表上。锁定不断升级，直到这个 16 核、8GB RAM（2002 年！）的盒子实际上停止（蓝屏）。

我认为我最大的错误是

truncate table Customers
truncate table Transactions

我没有看到我登录的是哪个 MSSQL 服务器，我想清除我的本地副本...熟悉的“OH s**t”当删除时间明显超过大约半秒时，我的老板注意到我明显变白了，问我刚刚做了什么。大约半分钟后，我们的站点监视器发疯了，并开始给我们发电子邮件说站点已关闭。

学到了什么？永远不要将连接打开到实时数据库的时间超过绝对需要的时间。

直到凌晨 4 点才从备份中恢复数据！老板为我难过，还请我吃饭...

发生在我身上的最糟糕的事情是生产服务器占用了 HD 中的所有空间。我正在使用 SQL Server，所以我看到了数据库文件并看到日志大约为 10 Gb，所以我决定做我想要截断日志文件时经常做的事情。我做了一个分离删除日志文件，然后再次附加。好吧，我意识到如果未正确关闭日志文件，则此过程将不起作用。所以我最终得到一个 mdf 文件而没有日志文件。谢天谢地，我访问了 Microsoft 站点，我得到了一种将数据库还原为恢复并移动到另一个数据库的方法。

我在一家小型电子商务公司工作，有 2 名开发人员和一名 DBA，我是其中一名开发人员。我通常没有动态更新生产数据的习惯，如果我们已经更改了存储过程，我们会将它们通过源代码控制并进行正式的部署例程设置。

无论如何，一个用户来找我需要更新我们的联系人数据库，批量更新一堆设施。所以我在我们的测试环境中写出了查询，比如

update facilities set address1 = '123 Fake Street'
    where facilityid in (1, 2, 3)

类似的东西。在测试中运行它，更新了 3 行。将它复制到剪贴板，将其粘贴到我们生产 sql 框中的终端服务中，运行它，惊恐地看着执行和更新 100000 行需要 5 秒钟。不知何故，我复制了第一行而不是第二行，并且我没有注意 CTRL V、CTRL E'd。

我的 DBA，一位年长的希腊绅士，可能是我见过的最脾气暴躁的人，他并不激动。幸运的是我们有一个备份，它没有破坏任何页面，幸运的是该字段仅用于显示目的（和计费/运输）。

学到的经验是要注意您正在复制和粘贴的内容，可能还有其他一些内容。