在我职业生涯的早期，我曾帮助一家规模不大的公司维护客户关系管理系统。有时需要清理数据。我们有一条无主客户记录，导致前端出现问题。于是，我和老板决定把它从数据库中删除。
于是我运行：
SELECT * |
验证只有一条记录会被删除，而且是有问题的记录
然后复制 WHERE 子句并写道：
DELETE |
然后，我在 SSMS 中突出显示了查询并运行了它。当查询运行时间超过 5 秒时，我的 WTF 内部警报开始响起。我看了看我的工作，发现我只复制了：
DELETE |
我很快意识到，我删除的不仅仅是一条记录，而是每一条客户记录。慌乱之中，我赶紧取消了查询，并祈祷它能回滚更改，它确实做到了。但为了确保万无一失，我又花了一个小时确认数据没有丢失。
谢天谢地，我没有把这件事告诉我的老板！不过，这也给我上了重要的一课，那就是在删除或修改记录时一定要格外小心，从那以后，我再也没有犯过类似的愚蠢错误。
======================================================
使用下面脚本删除记录：
SELECT 将更新或删除的记录 |
最后讲 ROLLBACK 改为 COMMIT 再次运行上面脚本。
=======================================================
据我所知，没有人（在 IT 行业工作了 44 年）因为意外更改/删除了错误的内容而被解雇。我知道至少有两人因试图掩盖此事和/或延迟报告而被解雇。
=======================================================
在我工作的第一年，我在排除 tempdb 驱动器空间问题时关闭了 SQL Agent 作业。结果发现是 CDC 工作，它本应全天候运行。在周五下午 4 点关闭后，我忘记了重新打开它。然后我就去看了一场 MLB 比赛。晚上 8:00 接到了一个电话，是一个愤怒的值班 DBA 打来的。这也是理所当然的。
=======================================================
我曾是一名会计，但为了能从我们的企业资源规划系统中做出更好的报告，我学习了 SQL，因此我有 SQL 访问权限，但从未亲自动手修改过。唯一的例外是，我们的一个附加产品导致采购订单在发布时陷入 "正在验证 "状态，而唯一的解决方法就是使用 SQL 命令。该命令运行良好，并在 WHERE 子句中进行了自己的验证，以防止打开错误的批次（重要提示--系统中的每件事情都在批次中运行，无论是采购订单、工作成本还是工资单）。
又过了一段时间，我要去参加一个会议。我的老板让我在外出时找一个备份来运行这个命令，于是我做了一个完整的书面程序，并将整个脚本复制到其中以方便使用。会议第二天，我接到一个电话，说系统中的每个批次都打开了。我说的每一个批次，是指过去 4 年中发布的每一笔交易现在都是开放的。我的备份运行了脚本，除了超级重要的 WHERE 子句。
========================================================
测试服务器上有一个名为 "TruncateAllCustData "的存储过程，可以截断数据录入模式中的每一张表。你可以看到这将会发生什么。
它被莫名其妙地推送到了开发服务器上
我有一个（非常糟糕的！）习惯，那就是通过工作站上的 SSMS 同时连接测试和生产环境。
在运行进程之前，我没有仔细检查。
幸运的是，当时时间还早，我们损失了大约一个小时的数据录入时间。情况可能更糟。
编辑补充：这至少是 15 年前的事了，所以现在已经没有这样的问题了。
==========================================================
Oracle SQL Developer 是最容易出错的系统。有一个连接的下拉菜单。尽管我对每个连接都有只读和写版本（我们有生产和测试实例），但多年来我还是有几次不小心连接错了，写了一些我不想在生产中做的）。这种情况时有发生。学习。下次要更加小心。利用这些经验制定更好的变更管理程序和制衡措施。
===========================================================
- UPDATE tickets SET Status = 'A'
- FROM tickets
- WHERE ...
为了检查 where 子句的准确性，我添加了一个 select
- UPDATE tickets SET Status = 'A'
- SELECT *
- FROM tickets
- WHERE ...
然后运行了整个报表。当我看到 "X 万行更新 "的信息时，我的老板正从我的肩膀上看过来，他说："哦，该死！"。他说看起来不错，我解释了问题所在。更大的问题是我们没有备份。我保住了我的工作，因为这是在编写临时查询时的一个诚实错误。而 DBA 却没有，因为他在最初编写备份脚本时出现了语法错误，所以一直没有备份。现在我总是在更新时别名表。
还有一次，我在测试环境而不是开发环境上恢复了 prod 数据库，这导致一个非常重要的版本推迟了一天发布。我们有大约 15 名昂贵的顾问，他们必须支付费用，但却无法工作，所以代价相当高昂。几个小时后，我被叫到副总裁办公室。我以为自己要被解雇了。但他们说的第一句话却是 "请不要辞职"。然后，每个人都在房间里转了一圈，承认了自己的问题所在。备份测试被关闭了，因为这会导致部署速度变慢。那天晚上我一直在工作，没有睡觉。幸运的是，我是小时工，而且很喜欢这份工作。事后，我对那个团队感觉非常好。
===========================================================
我曾在生产中删除过一次主事务表。那是我刚开始使用 SSMS 的时候，不习惯多个窗口连接到不同的服务器。我以为两个窗口都是开发窗口，但其中一个是生产窗口。在查询分析器中，你只能连接到一台服务器。
这是非常非常愚蠢的部分。网络人员决定在事务完成之前强行硬关闭服务器。当服务器重新上线时，数据库处于无法使用的状态。
我恢复了每天的完整备份和 15 分钟的日志备份，因此只丢失了 15 分钟的数据。重新启动服务器也浪费了 15 分钟，因此损失了大约一个小时的工作效率和 15 分钟的工作时间。这是一家小公司，所以影响不大，我觉得我很幸运。
===========================================================
我作为 DBA 和程序员工作了 35 年。老板给过我的最好建议是“每个人都搞砸了。只要确保你能康复就可以了。”
===========================================================
我担任 dba 已有 20 多年了……每次我被要求删除生产中的数据时，我仍然会皱起眉头。批量更新等等。我觉得，就像使用电动工具一样，如果你不有点害怕，你就会搞砸。
我的建议是在产品更改之前始终进行安全备份。- - 在合理范围内
===========================================================
有一次，作为一所重点大学图书馆系统的年轻开发人员，我接到一项任务，要重建一个数据库，跟踪电子期刊、电子书、研究数据库持有量和其他资源持有量，以及资源利用率数据。
我们并没有真正意义上的 prod/test/dev 分割，只有一个 prod 环境，所以我启动了一个名为"<prod db name>_tmp "的新数据库，复制了数据子集，重新建模，在新外观下测试数据的完整性，然后更新我的脚本并对 prod db 进行修改。我很高兴能受托处理这样的大事，所以我大概用了 11 个小时就完成了全部工作。
一天结束时，我筋疲力尽地删除了临时数据库，然后回家了。第二天一大早，我就被老板的电话吵醒了，问我们的数据库到底出了什么事。原来，我不小心删除了临时数据库，现在我们领导层的所有可视化界面 都失效了。我们能够顺利地将其回滚到之前的备份，我再次用脚本进行了修复（在我的团队领导的监督下），但接下来的三天我都在重新构建 Tableau 虚拟信息，因为数据连接已经完成，其中一些必须完全重建，因为 Tableau 的数据连接当时很糟糕（现在重新指向数据连接仍然很糟糕）。
===========================================================
我在技术行业的第一份工作是在 16 岁那年，当时我正处于大学间歇期，在一家大型制造公司工作，这家公司正在建造一座石油钻井平台。
他们使用的数据库平台是 Progress 4GL，而我之前对这个平台毫无经验，所以我不得不临时学习。我很快就证明了自己的能力，但那时我还只是个没有企业经验的孩子。
随着时间的推移，他们开始让我承担越来越多的开发责任。当时没有质量保证或代码审查，他们只是让一个 16 岁的孩子自由地将 DB 代码部署到生产数据库中，整个网站都是如此。
最终，不可避免的事情发生了。我推送了一个低劣的查询，不小心将石油钻井平台上的每一个焊缝都标记为已完成、已检查、已完全签收（数十万个）。
大约过了 60 秒，我的老板就开始不断接到电话，询问数据库到底出了什么问题。