6

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

  1. 意识到它并将其报告给您的同事或客户是什么感觉？
  2. 吸取了哪些教训？
4

18 回答 18

13

我认为我最大的错误是

truncate table Customers
truncate table Transactions

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

学过的知识？永远不要让实时数据库的连接打开时间超过绝对需要的时间。

直到凌晨 4 点才从备份中恢复数据！老板对不起我，请我吃饭...

于 2008-08-15T11:28:08.407 回答
8

我在一家小型电子商务公司工作，有 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，一位年长的希腊绅士，可能是我见过的最脾气暴躁的人，他并不激动。幸运的是，我们有一个备份，它没有破坏任何页面，幸运的是该字段仅用于显示目的（和计费/运输）。

吸取的教训是注意您正在复制和粘贴的内容，可能还有其他一些内容。

于 2008-08-15T13:17:26.040 回答
6

初级 DBA 打算：

delete from [table] where [condition]

相反，他们键入：

delete [table] where [condition]

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

那很有趣 ：-/

于 2008-08-15T11:20:21.573 回答
6

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

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

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

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

于 2008-08-15T15:46:59.577 回答
6

大意是：

update email set processedTime=null,sentTime=null

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

于 2008-11-23T22:20:58.693 回答
4

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

于 2008-08-15T14:39:26.547 回答
3 
update Customers set ModifyUser = 'Terrapin'

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

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

于 2008-08-15T14:20:12.917 回答
3

我们试图修复 Oracle 集群上的损坏节点。

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

嗯，原来卸载按钮是应用于整个集群的，所以它兴高采烈地从系统中的所有节点上移除了存储管理模块。

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

这是关于备份的一个有趣的事实……最旧的备份在异地轮换，您知道数据库上最旧的文件是什么吗？安装系统时设置的配置文件。

所以我们不得不让异地的人派快递员带着那个磁带，几个小时后，我们重新安装并运行了所有东西。现在我们保留安装和配置文件的本地副本！

于 2008-08-15T18:02:40.613 回答
2

I don't remember all the sql statements that ran out of control but I have one lesson learned - do it in a transaction if you can (beware of the big logfiles!).

In production, if you can, proceed the old fashioned way:

  1. Use a maintenance window
  2. Backup
  3. Perform your change
  4. verify
  5. restore if something went wrong

Pretty uncool, but generally working and even possible to give this procedure to somebody else to run it during their night shift while you're getting your well deserved sleep :-)

于 2008-09-24T16:58:55.003 回答
2

我以为我在测试数据库中工作（显然不是这样），所以当我完成“测试”时，我运行一个脚本将所有数据重置回我们使用的标准测试数据......哎呀！
幸运的是，这发生在一个有备份的数据库上，所以在发现我做错了什么之后，我们可以轻松地恢复原始数据库。

然而这件事确实教会了我工作的公司真正分离生产和测试环境。

于 2008-08-15T16:00:13.683 回答
2

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

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

不是。

生产中的经验教训：尽管我们喜欢在 MySQL 中使用 InnoDB 表有很多原因......请确保您没有设法找到少数不尊重事务并且您无法滚动的 MyISAM 表之一重新开始。任何情况下都不要相信MySQL，习惯性地发出“启动事务”是好事。即使在最坏的情况下（这里发生的事情）它也没有伤害任何东西，它会在 InnoDB 表上保护我。

我不得不从备份中恢复表。幸运的是，我们有每晚的备份，数据几乎从不改变，而且表格有几十行，所以几乎是即时的。作为参考，没有人知道我们周围还有非 InnoDB 表，我们以为我们早就转换了它们。没有人告诉我要注意这个问题，没有人知道它的存在。我的老板也会做同样的事情（如果他在输入 where 子句之前过早地按了 enter）。

于 2008-11-23T21:59:26.710 回答
1

我删除了实时数据库并将其删除。

经验教训：确保你知道你的 SQL - 并确保在你接触东西之前备份。

于 2008-08-15T11:15:45.483 回答
1

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

有一线希望——在我输入的周末，我学到了很多关于我的交易输入屏幕的可用性，此后显着改善。

于 2008-08-15T11:22:33.643 回答
1

对于大多数人来说，最糟糕的情况是生产数据丢失，但如果他们不运行夜间备份或将数据复制到 DR 站点，那么他们应得的一切！

@在 T-SQL 中，对于DELETE，FROM 关键字不是可选的吗？这两个语句的作用完全相同......

于 2008-08-15T11:30:17.903 回答
1

更新客户表的所有行，因为您忘记添加 where 子句。

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

于 2008-08-22T05:23:10.310 回答
1

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

于 2008-08-15T13:23:23.267 回答
1

这没有发生在我身上，只是我们的一个客户，我不得不清理他的烂摊子。

他们有一个在 RAID5 磁盘阵列上运行的 SQL 服务器 - 不错的热插拔驱动器，配有发光的磁盘状态指示器。绿色 = 好，红色 = 坏。

他们的一个驱动器从绿色变为红色，而被告知要拔出并更换（红色）坏驱动器的天才取而代之的是（绿色）好驱动器。好吧，这并没有完全降低raid集-在几分钟内选择了一些可读的（红色）与不可用的（绿色）..在意识到错误并将驱动器交换回在此期间写入的任何数据块之后由于磁盘同步丢失，时间变得乱七八糟）...... 24 小时后，编写元程序来恢复可读数据并重建他们备份并运行的中等大小的模式。

这个故事的寓意包括......永远不要使用 RAID5，始终保持备份，小心你雇用的人。

我曾经在客户的生产系统上犯了一个重大错误——幸运的是，当我想知道为什么命令需要这么长时间才能执行时，我意识到我做了什么，并在世界末日之前取消了它。

这个故事的寓意包括……在改变任何东西之前总是开始一个新的事务，测试结果是你所期望的，然后才提交事务。

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

于 2008-11-23T20:48:57.770 回答
1

截断表 T_DAT_STORE

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

从那以后，我在截断之前修改了所有内容，并定期要求对次要表进行备份恢复，只是为了检查备份是否正常（备份不是由我的部门完成的）

于 2008-08-31T07:38:55.640 回答