例如：更新customer表的所有行，因为您忘记添加where子句。
答案 0 :(得分：11)
我认为我最大的错误是
truncate table Customers
truncate table Transactions
我没看到我登录的是什么MSSQL服务器，我想清除我的本地副本...熟悉的“OH s ** t”当它花费的时间大于半秒以上时，我的老板注意到我去了白色，问我刚做了什么。大约半分钟后，我们的网站监控器发疯了，并开始向我们发送电子邮件说该网站已关闭。
经验教训？永远不要让连接开放的时间超过绝对需要的时间。
直到凌晨4点才恢复备份中的数据！我的老板为我感到难过，给我买了晚餐......
答案 1 :(得分：5)
我在一家小型电子商务公司工作，有2名开发人员和一名DBA，我是其中一名开发人员。我通常不习惯在动态更新生产数据，如果我们已经改变了存储过程，我们将它们通过源代码控制并进行正式的部署例程设置。
无论如何，用户来找我需要对我们的联系人数据库进行更新，批量更新一堆设施。所以我在测试环境中写出了查询，比如
update facilities set address1 = '123 Fake Street'
where facilityid in (1, 2, 3)
这样的事情。在测试中，3行更新。将它复制到剪贴板，将其粘贴到我们的生产sql框中的终端服务中，运行它，惊恐地看着它花了5秒钟执行并更新了100000行。不知怎的，我复制了第一行，而不是第二行，并没有注意，因为我 CTRL + V ， CTRL + E 'd。
我的DBA，一位年长的希腊绅士，可能是我见过的最脾气暴躁的人并不激动。幸运的是，我们有一个备份，并没有打破任何页面，幸运的是，该字段仅用于显示目的（和计费/运输）。
吸取的教训是关注你正在复制和粘贴的内容，也可能是其他一些内容。
答案 2 :(得分：4)
大约7年前，我在工作到很晚之后为客户端的数据库生成了一个更改脚本。我只更改了存储过程，但是当我生成SQL时，我检查了“脚本依赖对象”。我在我的本地机器上运行它，一切似乎都运行良好。我在客户端的服务器上运行它，脚本成功了。
然后我加载了网站，网站是空的。令我惊恐的是，“脚本依赖对象”设置为我的存储过程触及的每个表执行了DROP TABLE。
我立即打电话给主管开发人员和老板让他们知道发生了什么，并询问数据库的最新备份可能位于何处。其他2个开发者参加了会议，我们得出的结论是，没有备份系统，甚至没有数据可以恢复。客户丢失了整个网站的内容，我是根本原因。结果是给我们的客户 $ 5000 信用。
对我来说这是一个很好的教训，现在我对运行任何更改脚本以及首先备份数据库非常谨慎。我今天仍然在同一家公司工作，每当有关备份或数据库脚本的笑话出现时，总会出现着名的“DROP TABLE”事件。
答案 3 :(得分：4)
产生效果：
update email set processedTime=null,sentTime=null
在生产新闻稿数据库中，重新发送数据库中的每封电子邮件。
答案 4 :(得分：4)
初级DBA意图：
delete from [table] where [condition]
相反，他们输入了：
delete [table] where [condition]
哪个是有效的T-Sql但基本上完全忽略了where [condition]位（至少它在MSSQL 2000/97上做了 - 我忘了哪个）并擦除了整个表。
这很有趣： - /
答案 5 :(得分：3)
我曾经设法编写一个永不退出的更新游标。在2M +行表上。这些锁只是升级并升级，直到这个16核，8GB RAM（2002年！）的盒子实际上停止了（蓝屏种类）。
答案 6 :(得分：2)
update Customers set ModifyUser = 'Terrapin'
我忘记了where子句 - 相当无辜，但在一张有5000多名顾客的桌子上，我的名字会在一段时间内出现在每一条记录上......
获得的经验：使用事务提交和回滚！
答案 7 :(得分：2)
我们试图修复Oracle群集上的已破坏节点。
存储管理模块出现问题，因此我们点击了卸载按钮，意图重新安装并从另一个节点复制配置。
嗯，事实证明应用于整个集群的卸载按钮，因此它从系统中的所有节点中快速地删除了存储管理模块。
导致生产群集中的每个节点崩溃。由于没有一个节点有一个存储管理器，它们不会出现！
这是一个关于备份的有趣事实......最旧的备份会在异地进行轮换，您知道数据库中最旧的文件是什么吗？安装系统时设置的配置文件。
因此我们不得不让异地人员用该磁带发送快递，几个小时后我们重新安装并运行了所有东西。现在我们保留安装和配置文件的本地副本！
答案 8 :(得分：1)
我以为我在测试数据库中工作（显然不是这样），所以当我完成'测试'时，我运行一个脚本将所有数据重置回标准测试数据我们用...哎哟！
幸运的是，这发生在一个备份到位的数据库上，所以在弄清楚我做错了之后我们就可以轻松地恢复原来的数据库了。
然而，这件事确实教会了我工作的公司真正分离生产和测试环境。
答案 9 :(得分：1)
我不记得所有失控的sql语句，但我学到了一个教训 - 在事务中执行，如果可以的话（谨防大日志文件！）。
在制作中，如果可以的话，继续采用传统方式：
非常不酷，但通常工作，甚至可以将这个程序交给其他人在夜班期间运行它，同时你得到你当之无愧的睡眠： - ）
答案 10 :(得分：1)
我完全按照你的建议行事。我更新了包含客户文档的表中的所有行，因为我忘了在最后添加“where ID = 5”。这是一个错误。
但我很聪明，偏执狂。我知道有一天我会搞砸。我发出了“开始交易”。我发出了回滚，然后检查表是否正常。
不是。
在生产中学到的经验：尽管我们喜欢在MySQL中使用InnoDB表有很多原因...确实你没有设法找到一些不尊重交易的MyISAM表之一，你可以不要再回头了。在任何情况下都不要相信MySQL，习惯性地发布“启动事务”是件好事。即使在最糟糕的情况下（这里发生的事情）它也没有伤害任何东西，它会在InnoDB表上保护我。
我不得不从备份中恢复表。幸运的是，我们有夜间备份，数据几乎从不改变，并且表格是几十行，所以它几乎是即时的。作为参考，没有人知道我们仍然有非InnoDB表，我们以为我们很久以前就把它们转换了。没有人告诉我要注意这个问题，没有人知道它在那里。我的老板也会做同样的事情（如果他在输入where子句之前太早点击进入）。
答案 11 :(得分：0)
对于大多数人来说，最糟糕的情况是生产数据丢失，但如果他们没有每晚运行备份或将数据复制到灾难恢复站点，那么他们应该得到他们得到的一切！
在T-SQL中，@ Keith对DELETE来说不是FROM关键字的可选项吗？这两个陈述完全相同......
答案 12 :(得分：0)
我发现我不了解Oracle重做日志文件（术语？很久以前）并且丢失了一周的交易数据，这些数据必须从纸质票据中手动重新键入。
是一线希望 - 在周末我投入了资金，我学到了很多关于我的交易输入屏幕的可用性，之后这种情况有了很大改善。
答案 13 :(得分：0)
发生在我身上的最糟糕的事情是，生产服务器消耗了HD中的所有空间。我正在使用SQL Server，因此我看到了数据库文件并看到日志大约是10 Gb所以我决定在我想要截断日志文件时做我经常做的事情。我做了一个Detach删除日志文件，然后再次附加。好吧，我意识到如果日志文件没有正确关闭，这个过程不起作用。所以我最终得到一个mdf文件，没有日志文件。值得庆幸的是，我去了微软网站，我得到了一种方法来恢复数据库作为恢复并移动到另一个数据库。
答案 14 :(得分：0)
我删除了实时数据库并删除了它。
获得的经验教训：确保您了解自己的SQL - 并确保在触摸内容之前备份。
答案 15 :(得分：0)
更新customer表的所有行，因为您忘记添加where子句。
这正是我所做的：| 。我已将所有用户的密码列更新为我在控制台上输入的示例字符串。最糟糕的部分是我正在访问生产服务器，当我这样做时，我正在检查一些查询。然后我的老年人不得不恢复一个旧的备份，不得不从一些真正心怀不满的客户那里打电话。当然还有另一次我使用删除语句，我甚至不想谈论; - ）
答案 16 :(得分：0)
截断表T_DAT_STORE
T_DAT_STORE是我工作的部门的事实表。我想我已连接到开发数据库。幸运的是，我们有一个每日备份，直到那天才使用，并且数据在六小时内恢复。
从那时起我在截断之前修改了所有内容，并且我会定期请求备份恢复次要表，以检查备份是否正常（备份不是由我的部门完成）
答案 17 :(得分：0)
这不会发生在我身上，只是我们的客户，我不得不清理它。
他们有一个在RAID5磁盘阵列上运行的SQL服务器 - 不错的热交换驱动器带有点亮的磁盘状态指示器。绿色=好，红色=坏。
他们的一个驱动器从绿色变为红色，被告知拉动并替换（红色）坏驱动器的天才取而代之的是（绿色）好驱动器。好吧，这并不能完全降低raid设置 - 选择几分钟可读（红色）与不可用（绿色）几分钟......在意识到错误并将驱动器交换回在此期间写入的任何数据块之后由于磁盘同步丢失，时间变成了jyberish）......连续24个小时后编写元程序来恢复可读数据并重新构建一个中等大小的模式，它们已经备份并运行。
这个故事的道德包括......永远不要使用RAID5，始终保持备份，小心你雇用的人。
我曾经在客户生产系统上犯了一个重大错误 - 幸运的是，我想知道为什么命令花了这么长时间才意识到我做了什么并在世界结束之前取消了它。
这个故事的道德包括......总是在改变任何事情之前开始一个新的交易，测试结果是你所期望的然后然后才提交交易。
作为一般观察，可以通过在模式上正确定义外键约束并远离任何标记为“CASCADE”的命令来防止许多类rm -rf /类型错误