例如：更新客户表的所有行，因为我们忘记添加where子句。

• 将其实现并将其报告给同事或者客户是什么样的感觉？
• 从中学到了什么？

解决方案

回答

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

获得的经验教训：确保我们了解SQL，并确保在备份内容之前先进行备份。

回答

初级DBA的目的是：

delete from [table] where [condition]

相反，他们输入：

delete [table] where [condition]

哪个是有效的T-Sql，但基本上完全忽略了where [condition]位(至少在MSSQL 2000/97上它确实做到了，我忘记了那个)，并擦除了整个表。

蛮好玩的 ：-/

回答

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

我在输入上花费的周末有一线希望，我从我的交易输入屏幕的可使用性中学到了很多，此后大大改善了。

回答

我认为我最严重的错误是

truncate table Customers
truncate table Transactions

我没有看到我登录的MSSQL服务器，我想清除本地副本...熟悉的" OH s ** t"，删除时间要长于大约半秒钟，我的老板注意到我去了见白，问我刚刚做了什么。大约半分钟后，我们的站点监控器崩溃了，并开始通过电子邮件向我们发送电子邮件，说站点已关闭。

学过的知识？打开活动数据库的连接绝对不要超过绝对需要的时间。

直到凌晨4点才从备份中还原数据！老板为我感到难过，并给我买了晚餐。

回答

对于大多数人来说，最糟糕的情况是生产数据丢失，但是如果他们不执行每晚备份或者将数据复制到灾难恢复站点，则他们应得到的一切！

在T-SQL中，@ Keith是DELETE的FROM关键字不是可选的吗？这两个语句都做完全相同的事情...

回答

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

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

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

这样的事情。在测试中运行它，更新了3行。将其复制到剪贴板，将其粘贴到我们的生产sql框中的终端服务中，运行它，惊恐地看着它花了5秒钟执行并更新了100000行。不知何故，我复制了第一行而不是第二行，并且由于我CTRL+V，CTRL+Ed而没有引起注意。

我的DBA是一位年纪较大的希腊绅士，可能不是我遇到的最脾气暴躁的人。幸运的是，我们有一个备份，它没有中断任何页面，幸运的是，该字段仅用于显示目的(以及计费/运输)。

吸取的教训是要注意我们要复制和粘贴的内容，可能还需要注意其他一些内容。

回答

对我而言，最糟糕的事情是生产服务器占用了HD中的所有空间。我使用的是SQL Server，因此我看到数据库文件，并且看到日志大约是10 Gb，因此我决定做我想截断日志文件时经常执行的操作。我做了一个分离，删除了日志文件，然后再次添加。好吧，我意识到，如果未正确关闭日志文件，则此过程将不起作用。所以我最终得到的是mdf文件，而没有日志文件。值得庆幸的是，我去了Microsoft站点，我有一种方法可以将数据库恢复为恢复状态并移到另一个数据库。

回答

update Customers set ModifyUser = 'Terrapin'

我忘记了where子句非常清白，但是在有5000多个客户的表上，我的名字将在一段时间内出现在每条记录上。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

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

回答

我曾经设法编写一个从未退出过的更新游标。在2M +行表上。锁只是逐步升级，直到这个16核8GB RAM(在2002年！)盒实际上停滞了(蓝屏)。

回答

大约7年前，我工作到很晚才为客户的数据库生成一个更改脚本。我只更改了存储过程，但是在生成SQL时，我检查了"脚本相关对象"。我在我的本地计算机上运行了它，并且一切似乎都运行良好。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。我在客户端的服务器上运行它，脚本成功。

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

我立即打电话给首席开发人员和老板，让他们知道发生了什么，并询问数据库的最新备份可以存放在哪里。参加了另外两个开发人员会议，我们得出的结论是，甚至没有备份系统，也无法恢复数据。客户失去了他们整个网站的内容，而我才是根本原因。结果是向我们的客户提供了$ 5,000的信用额。

对我来说，这是一个很棒的课程，现在我对运行任何更改脚本和首先备份数据库非常谨慎。我今天仍在同一家公司工作，每当有关备份或者数据库脚本的笑话浮出水面时，总会有人提出著名的" DROP TABLE"事件。

回答

我以为我正在测试数据库中工作(显然情况并非如此)，所以当我完成"测试"时，我运行了一个脚本以将所有数据重置为我们使用的标准测试数据。
幸运的是，这发生在有备份的数据库上，因此在弄清楚我做错了什么之后，我们可以轻松地恢复原始数据库。

但是，此事件确实教会了我工作的公司真正将生产和测试环境区分开来。

回答

我们正在尝试修复Oracle集群上的无效节点。

存储管理模块出现问题，因此我们单击了"卸载"按钮，目的是从另一个节点重新安装并复制配置。

嗯，事实证明是将卸载按钮应用于整个集群，因此很高兴地从系统中的所有节点上删除了存储管理模块。

使生产集群中的每个节点崩溃。而且由于所有节点都没有存储管理器，因此它们不会出现！

这是有关备份的一个有趣的事实...最旧的备份在站点外轮换，我们知道数据库中最旧的文件是什么吗？安装系统时设置的配置文件。

因此，我们必须让异地的人用该磁带发送快递，几个小时后，我们重新安装并运行了所有内容。现在，我们保留安装和配置文件的本地副本！

回答

Updating all rows of the customer table because you forgot to add the where clause.

那正是我所做的：| 。我已将所有用户的密码列更新为我在控制台上键入的示例字符串。最糟糕的部分是我正在访问生产服务器，并且在执行此操作时正在检查一些查询。然后，我的前辈们不得不还原旧的备份，并且不得不打听一些真正心怀不满的客户的电话。当然，还有一次我确实使用了delete语句，我什至不想谈论它；-)

回答

Truncate table T_DAT_STORE

T_DAT_STORE是我所在部门的事实表。我认为我已连接到开发数据库。幸运的是，我们有每天的备份，直到那天才使用，并且在六个小时内就恢复了数据。

从那时起，我在截断之前修改了所有内容，并定期要求对次要表进行备份还原，只是为了检查备份是否正常(我部门未完成备份)

回答

我不记得所有失去控制的sql语句，但我吸取了一个教训，那就是如果可以的话，请在事务中进行操作(请注意大的日志文件！)。

在生产中，如果可以的话，请按照旧的方式进行：

• 使用维护窗口
• 后备
• 执行更改
• 核实
• 如果出现问题，请恢复

相当不酷，但通常可以正常工作，甚至可以让其他人在夜班期间执行此程序，而我们应该得到应有的睡眠

回答

这不是我发生的事情，只是我必须清理的客户的麻烦。

他们有一个运行在RAID5磁盘阵列上的SQL Server，漂亮的热插拔驱动器配有亮起的磁盘状态指示灯。绿色=良好，红色=较差。

他们的驱动器之一从绿色变为红色，而被告知要拔出并更换(红色)坏驱动器的天才则将(绿色)好驱动器取出来。好吧，这并没有完全使RAID集完全消失，而是选择了几分钟的可读性(红色)对不可用(绿色)的设备。 ...由于失去了磁盘同步而变得混乱起来)。24个小时后，编写元程序以恢复可读数据并重建它们正在运行的中等大小的架构。

这个故事的寓意包括...永远不要使用RAID5，始终维护备份，请小心雇用谁。

我曾经在客户生产系统上犯了一个重大错误-幸运的是，在想知道为什么执行命令要花费这么长时间时，我意识到我所做的一切并在世界灭亡之前取消了它。

这个故事的寓意包括...总是在更改任何内容之前开始新的事务，测试结果是否符合期望，然后才提交事务。

作为一般观察，可以通过在模式上正确定义外键约束并远离任何经过命令标记的" CASCADE"来防止rm -rf /类型错误的许多类

回答

我完全按照你的建议做了。我更新了保存客户文档的表中的所有行，因为我忘记在末尾添加" where ID = 5"。那是个错误。

但是我很聪明，偏执。我知道我会一天搞砸。我已经发出了"开始交易"。我发出回滚，然后检查表是否正常。

不是。

在生产中获得的经验教训：尽管事实上我们出于很多原因希望在MySQL中使用InnoDB表...请确保我们没有设法找到少数几个不遵守事务且无法滚动的MyISAM表之一回来。在任何情况下都不要相信MySQL，习惯性地发出"开始交易"是一件好事。即使在最坏的情况下(这里发生了什么)，它也丝毫没有伤害任何东西，并且可以保护我在InnoDB表上的安全。

我不得不从备份中还原表。幸运的是，我们每夜都有备份，数据几乎从未更改，并且该表只有几十行，因此几乎是瞬时的。作为参考，没有人知道我们周围仍然有非InnoDB表，我们认为很早以前就将它们转换了。没有人告诉我要注意这个陷阱，没人知道它在那里。我的老板会做同样的事情(如果他在键入where子句之前就按回车太早了)。

回答

效果：

update email set processedTime=null,sentTime=null

在生产时事通讯数据库上，重新发送数据库中的每封电子邮件。