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