首先意淫这篇文字，任务是要说SQL SERVER 数据库要被消灭等等的就可以到此为止了。本篇文字，主要说的这两天，恢复SQL SERVER 数据库文件，拯救系统的始末.
前天下午，接到运维同学的电话，（估计之前已经有人报警说系统无法运行了），他告诉我我们的SQL SERVER 集群的主库正在被还原，问我有什么解决方法吗？
WHAT HOW ，是我脑子里闪出的东西，当然还有别的，STOP
冷静，我脑子里面里面开始运转，从脑子里面的数据库搜索各种方案和使用这样方案会造成的影响。
首先我确认的是
1 业务终止了
2 是否能终止整体数据库还原
3 终止后怎么让业务数据库上线
4 我能保证数据的一致性吗
5 我需要多长时间
6 情况还能多糟糕
可能说道这里，有观众已经想问，怎么会？ OMG ，好好的怎么会数据库还原。
我倒是想奉劝，怎么就不可能，这世界上什么事情不会发生，没有什么好奇怪的，发生了，也别问怎么样，谁干的，诸如此类无聊的问题。他发生了，现在给我打电话就是要SAVE IT， 其他的我不关心。
问完我自己那些问题，脑子的数据库首先的第一条反映就是，不能让他继续还原，如果继续的话，我半点拯救数据库的机会都没有，OK 我们的SQL SERVER 是ALWAYS ON ，OMG ，三台机器，
有人问，HI 关机不就完啦，反正业务已经停止了，SHUT UP，那个数据库上还跑着其他的数据库，不光正在还原的这一个数据库，已经停止了关键业务，难道关了数据库服务器，让整个公司都沸腾吗？
1 decision ，不能关机，必须正常输出其他的服务，影响不能扩大化
又会有人说，你不关机，就让他继续还原数据库，NO NO NO ，幸亏我们的公司有ALWAYS ON （那些还让SQL SERVER （尤其主营业务）还不适用 ALWAYS ON 的 当然还有使用集群方式的（类似 ORACLE RAC））就等着哭吧，
2 我立即告诉运维人员，我要关闭一台SQL SERVER 从库，这里解释一下为什么再次提到 ORACLE RAC 和 SQL SERVER 类似的功能 SQL SERVER CLUSTER。 使用这样的方案，必须在发生这样问题的情形下，必死无疑，必死无疑，必死无疑，重要的事情说三遍。分布式数据库的优点，关闭一台机器，不影响业务，数据服务的继续输出。
关闭后，我在想，我不怕了，至少我留下了一台数据库服务器的数据，虽然分布式数据库上的数据也已经在还原的状态，但我保住了原始的数据，不再被损坏，我还有生还的机会。
我还应该在做点什么，下一步怎么办，停止那的备份软件的误操作，得到第三方的软件供应商的答复是NO。
OMG ，这就是花了钱后得到的服务，我明白为什么互联网公司什么都要自己开发，从不买什么备份软件，监控软件，系统保护软件之类的。因为如果是公司内部自己开发的，那绝对不会说出冷冰冰的 NO 。 而是大家继续想办法拯救需要拯救的东西。（后来事实证明，只有公司内部的团队是靠谱的，关键的东西其实还是自己研发比较好）
既然软件上说NO ，那就是不能停止还原的操作，怎么办，查看软件的线程，一直在连接SQL SERVER 进行数据还原，还是多线程的，停止时够呛了，因为他有强大的重试功能，估计还是使用的SA 之类的高级账号给他做连接数据库的账号，我已经不奢望什么了。
好吧，我的关注点，回到我保留下的那个关闭的服务器，又接到电话，说那个关闭的服务器，还要在开机，因为要尝试解散集群，尝试数据库停止恢复B PLAN。 OMG
在开机后，我再次决定停止SQL SERVER 的服务，不让马上连接的节点，被继续破坏，我开始拷贝节点的数据库的文件，（这里又有故事，缺少这个故事，估计也搞不定，BULABULA）。 拷贝完我的数据库文件到一个安全的地方，我打开了SQL SERVER 的服务，如同电影 奇幻PI旅行中最后老虎消失的一幕，我知道，这台机器的数据库也完蛋了。
不过我已经拷贝了数据库，下面面对我有时连续的奇葩问题
1 我光有数据文件，没有能让我使用的恢复数据库的服务器
2 这些文件已经部分还原，我拿到这些能还原多少文件
3 怎么恢复这些数据文件
以前学习过的 SQL SERVER PAGE 页的知识，浮现在脑子里面
SQL Server中的在页面顶部有一个96字节的头，它包括PageID、页面所属的结构类型、页面中的记录数量以及指向上一页和下一页的指针。所以有8096字节可用来存储记录。但是，数据记录的最大长度是8060字节，正如页面底部(最新的36字节)所示，它驻留的slot数组包含关于行的偏移量的信息(每行2字节)
马上问题又在脑子里面翻转
1 如果页头毁掉了，那就完蛋了
2 数据页面如果不连续了，很可能会有数据的缺失和损坏
3 如果有跨页的情况，那损坏也许更多
并且根据SQL SERVER 数据库文件的页面分配，9，0 1 2 3 首页面如果被毁，那简直就是死路一条。
怎么办，本来我想用以前用过的 APEXLOG ，来尝试重新读取文件，不过原理不对，那个软件是读取日志文件，来恢复数据的，而这次毁灭性的打击，根据 ALWAYS ON 的原理，很可能日志是最先被毁灭的文件。并且我如果想恢复，至少我的先让这些数据文件再次挂在在数据库服务器上，才能使用 APEXLOG ，不幸的是，这些条件都不具备。
尝试挂载数据文件，报告，MASTER FILE 32:32 损坏，无法挂载数据库。好吧我早就该想到这一点，被覆盖，还强行关机，挂不上那是应该的，挂上那是上帝显灵了。
那也不能坐以待毙，我尝试寻找其他方法，那不具备那些条件的情况下，我可以通过读取数据文件的方式恢复数据，根据文件的物理特性，其实可以通过SQL SERVER DBCC的方式直接读取数据页，并且恢复数据，但前提是数据库的联机，现在这个问题是数据库不能联机，并且联机的也是那个正在还原停不了的数据库，并且也不能拿现在的数据库冒险。 更糟糕的我想把数据拷贝到 UAT 或者 测试库的想法 也都落空，倒霉催的网络带宽，倒霉催的网络带宽，倒霉催的网络带宽。
SQL SERVER 本身能读取数据PAGE，其实按原理上个来说，只要有读取这个PAGE的软件就可以，尝试找找，还真有类似的软件，那试试吧，装上软件，开始对我拷贝的数据文件，进行SEARCH，上线，我看到久违的数据，好像初恋一样的感觉。好吧后面就是，恢复数据，BULABULA。
此外，开发团队在得到 AUDIT LOG 后，想尝试另一种恢复的方法，也可歌可泣，绝对应该载入公司的史册，并且我也从这次开发的努力中看到了不放弃，并且我们也得到一些在此类问题上的经验，绝对是有益的。
总结：
1 首先感谢开发者软件的公司，并且有破解这个软件的人，再次感谢
2 如果让我做数据库部署的抉择，1 不会使用ORACLE RAC 或类似的功能，因为越复杂的东西，遭遇不测恢复很难，如果是ORACLRE 估计也很难有公司能得到技术内幕并开发此类软件。换做是MYSQL 估计连第三方软件都不用，很快就能将这样的问题解决（前提的做些工作）
运维的同学虽然不在一个部门，不过我想他们积极的找解决问题的出路的努力应该被肯定.
身处这样的公司，出了问题大家一起努力解决，而不是冷冰冰的指责（某些公司体会过，放心这样的事情放在那些公司，我只有三个字 OMG ），虽然出了问题，但我们解决了，这很了不起。这也让我想起到底是职责划清好，还是大家“大锅饭”好，都有优点，和缺点，不过这次，彻底让我感觉到 “大锅饭”的好处。 记得4年前在某公司，也是这样的问题，而处境，各个部门事不关己高高挂起的嘴脸，真让我厌恶，并且还落井下石。
3 分布式数据库，（是分布式不是数据分片，那将毫无帮助），对此类问题是有帮助。
4 冷静，冷静，冷静，和信心
5 经验值和一些发现的问题（就让他们在我脑子里面吧）
结果： We saved it
