这不是关于如何应对或限制停机或数据丢失的问题，我对此了如指掌。我正在为我的 PASS 灾难恢复后会整理一个“故事”部分，我希望能够分享一些比我在微软工作时更近期、更令人印象深刻的故事，尽管如果你在过去 3 年里听过我介绍我的腐败套牌，你会记得它们都是很棒的。
所以，请把这当作是一种忏悔（虽然我不能提供赦免 :-)，当然，这里讲述的所有故事都发生在朋友或同事身上，或者发生在之前的公司，除非你很勇敢，愿意坦白。我不会对任何答案做出判断或嘲笑，只会在被要求时提供见解。
其实，这个想法是为了让每个人都能从错误和失误中吸取教训。我听过一个故事，例如，一个关于失误和腐败的悲伤故事。
不确定这在这个论坛上是否有效，但值得一试。
谢谢！
PS：如果你还没有看过我的腐败会议并听过这些故事，那是去年 TechEd IT Pro 上的第二次会议，他们把它录了下来：见TechEd：80 分钟腐败生存技巧演示视频。博客文章链接到一堆损坏的数据库和演示脚本，您可以下载并使用它们（我们的网站上没有广告或类似的东西，只有信息）。
答案1
除了经典的“我忘记包含 WHERE 子句并且我不在事务中”更新/删除语句之外，还有其他什么吗？
在我们的实验室环境中，一台服务器上的数据库不断离线。MDB 文件所在的驱动器会消失，SQL 会出现问题，当驱动器重新出现时（通常几分钟后），我需要手动将数据库重新联机。我花了一周的时间与操作人员一起尝试确定驱动器消失的原因。它是 SAN 上的 LUN，具有到交换机的冗余路径。
长话短说，结果发现光缆没有完全卡入交换机的端口，而且在最近的维护过程中，光缆发生了移动。它们现在位于机架门和其关闭的凹槽之间的空腔中。当门关闭时，它会拉动光缆，刚好足以使插头滑出并断开连接。门没有锁，只是自由摆动，当实验室的门打开/关闭时，空气流动导致机架门来回摆动。
答案2
我所在的一家小公司刚刚推出了一个基本的 Sharepoint 服务网站。虽然公司规模很小，但员工遍布世界各地，因此 Sharepoint 的 Web 访问和 MS Office 集成非常棒（其他一切都很糟糕，但那是另一个故事了）由于我们资金不多，而且规模很小，所以我们保持了简单，一个带 RAID 的 SQL 服务器和一个也带 RAID 的 Web 服务器。大约 1 周后，在将 5 GB 的项目数据放入其中后，SQL 框中的电源出现故障。我们停机了一天，等待新电源的交付。我们本可以将备份转移到另一台服务器上，但由于我们还是 Sharepoint 的新手，DR 计划仍在制定中，我们认为弄清楚这一切需要的时间与等待电源到达的时间一样长，而且我们知道一旦有了新电源，我们就可以上线，而不必进行故障回复，所以我们选择等待，以免冒弄乱 Sharepoint 的风险。
答案3
人为错误导致 2 TB 的 MS-SQL 数据库的所有索引都丢失。他们很快注意到了这一点，并决定重建索引。不幸的是，这个过程花了 48 个小时。事后看来，从磁带恢复会更容易（并且停机时间更少）。
答案4
几年前，我在一家汽车金融公司工作时，在部署过程中搞垮了一台数据库服务器。这是我职业生涯中犯下的重大失误之一，尽管我最终摆脱了这一问题。
我们有从 SQL 2K (SP3) 到 SQL 2K (SP3) 的单向事务复制，在部署期间，如果复制涉及表，则根据公司政策，应拆除并重建复制。在某个时候，我们决定升级到 SP4，并将更改滚动到所有生产服务器，但升级后没有重建复制。
几周后，我的项目（我是一名数据库开发人员和承包商）即将部署，而我正在数据中心支持部署（通常部署在午夜进行）。复制已关闭，项目部署成功，而重建复制在 2 小时后失败。SCM 人员在凌晨 3 点重新启动它，没有阅读完整的错误消息，2 小时后再次失败，我们几乎接近 SLA。我知道我必须在凌晨 5 点打电话给我的经理，并且打了很多电话将问题上报给所有级别/组。
DBA 组在早上 6 点接手了这个问题，但我对故障排除步骤一无所知，我的经理在 2 小时内问我 3 次，检查我的脚本是否导致了这个失误。我当时非常焦虑。4 个产品 DBA 和 2 个经理对这个问题非常关注，并向 MSFT 提出了问题，但直到下午 3 点之后，问题仍未解决，直到我弄清楚到底发生了什么。在一篇文章（表格）中，我们在一列上有一个唯一索引，但数据质量不佳。我们有 '' 和空值，其余数百万条记录都是合法值，尽管一些遗留数据值得怀疑。升级到 SP4 之后，SQL Server 尝试在订阅端将 '' 和空值转换为空值，但由于唯一键/索引冲突而失败。在获得业务组的高级许可后，坏数据被删除，我又可以保留我的工作一年。
获得的经验是：在升级之前，测试、测试、再测试您拥有的每一个程序。