这不是一个关于如何应对或限制停机或数据丢失的问题，我知道这一切。 我正在为我的PASS post-con灾难恢复编写一个“故事”部分，我希望能够分享一些比我在微软的日子更令人印象深刻的故事，在过去的三年中，我已经听到了任何时候提交我的腐败套牌，你会记得他们都是doozies。
所以，认为这是一种自白（虽然我不能提供赦免:-)，当然，这里所讲的所有故事都发生在一个朋友或同事，或者在一个以前的公司，除非你很勇敢并且想要“大失所望。 我不会通过判断或嘲笑任何答案，只会提供见解，如果要求。
真的，这个想法是让每个人从错误和错误的步骤中学习。 作为一个我听到的故事的例子，看到一个错误的步骤和腐败的悲惨故事 。
不知道这是否会在这个论坛上工作，但它是值得一试。
谢谢！
PS如果你还没有看到我的腐败会议和听到的故事，这是TechEd IT专业人士去年的第二届会议，他们录像：参见TechEd：腐败生存技术演示文稿的80分钟video 。 博客文章链接到一堆损坏的数据库和演示脚本，你可以下载和玩（也没有广告或类似的东西在我们的网站上，只是信息）。
其他的经典的“我忘了包括WHERE子句，我不是在一个事务中”更新/删除语句？
不要在我们的实验室环境中让一台服务器上的数据库脱机。 MDB文件所在的驱动器将会消失，SQL会打嗝，当驱动器重新出现时（通常在几分钟之后），我需要手动将数据库重新联机。在操作系统上花费了一周的好时间伙计们试着去确定驱动器为什么会消失。 这是SAN上的一个LUN，具有到交换机的冗余path。
长话短说，事实certificate，光纤电缆没有被完全卡入交换机的端口，而且在最近的一些维护工作中电缆已经转移了。 他们现在rest在机柜门和它closures的凹槽之间的空腔中。 当门closures时，它将电缆拉到恰好足以使插头跳出来并断开连接。 门没有锁，只是自由地摆动，打开/closures实验室门时，空气的移动导致机架门前后摆动。
在我当时的一家小公司，我们刚刚build立了一个基本的Sharepoint Services站点。 我们很小，但是我们的员工在世界各地，所以networking访问和MS Office整合为Sharepoint是惊人的（一切都被吸引，但多数民众赞成在另一个故事）由于我们没有太多的钱，我们很小，我们保持简单，一个SQL服务器与RAID和一个Web服务器也与RAID。 大约1个星期和5个演出数据的演出数据在SQL框中的电源供应失败。 我们有一天的等待交付新的宕机。 我们可以将备份放到另一台服务器上，但是由于我们还是一个新的共享点，DR计划还在开发中，我们认为只需要等待电源到达就需要等待很长时间，因为我们知道一旦我们有了新的电力供应，我们就可以上网了，而且不用倒车，我们只是select了等待，而不会冒险搞乱分享点。
人为错误导致两TB的MS-SQL数据库的所有索引都被删除。 他们很快注意到，决定重build索引。 不幸的是，这个过程花费了48个小时。 事后看来，从磁带恢复会更容易（并导致更less的停机时间）。
几年前在为一家汽车金融公司工作时，我在部署期间放下了一台数据库服务器。 这是我在职业生涯中涉及的重大失误之一，尽pipe我从这个问题中清醒过来了。
我们进行了从SQL 2K（SP3）到SQL 2K（SP3）的单向事务复制，并且在部署过程中，如果涉及到复制中的表，则复制应该作为公司策略来解散和重build。 在某个时候，决定升级到SP4，并且更改已经转移到所有prod服务器，但升级后不会重build复制。
几个星期后，我的项目（我是一个数据库开发人员和一个承包商）已经到期部署了，而且我在支持部署的数据中心（通常部署在午夜完成）。 复制被取消，项目部署成功，2小时后重build复制失败。 供应链pipe理人员在凌晨3点没有阅读完整的错误信息就重新启动，2小时后再次失败，我们几乎接近服务水平协议。 我知道我必须在凌晨五点打电话给我的经理，并且很多人打电话给这个问题。
DBA团队在早上6点接pipe了这个问题，在故障排除步骤中我一直处于黑暗状态，我的经理在2个小时内问了我三次，以检查我的脚本是否对这个问题负责。 我的头在线。 4 Prod DBA和2位pipe理人员在这个问题上很热门，并向MSFT提出了一个Ticket，甚至在下午3点之后，问题才得以解决，直到我找出真正发生的事情。 在一篇文章（表格）中，我们对列有一个唯一的索引，但数据质量不好。 尽pipe一些遗留数据是有问题的，但我们拥有“空值”，剩余的数百万条logging是合法的值。 在SP4升级之后，SQL Server试图在订户端将“'和空值转换为空，并且因为唯一的键/索引违例而失败。 从业务组获得高级权限后，不良数据被删除，我得继续工作一年。
获得的经验：在升级之前testing，testing和testing您拥有的每个程序。