干数据库运维这行，最怕半夜手机响。尤其是Sybase这种老牌关系型数据库，平时稳得像头老黄牛，一旦出问题，往往就是大事。我见过太多同行在恢复现场手忙脚乱，日志没备份、设备文件损坏、事务日志爆满……每一个坑都能让人熬到天亮。今天不聊理论，就说说实战里那些踩过的坑和救回来的命。
先说最常见的故障场景：设备文件损坏。Sybase的数据和日志存在设备文件里，这些文件一旦物理损坏，很多人第一反应是“完了”。其实别慌，数据库的master设备如果还在，就能尝试用单用户模式启动。我处理过一个案例，客户的数据设备文件被误删，但master和日志设备完好。这时候用参数启动ASE，把数据库标记为“可疑”状态，再用强制拉起来。虽然部分数据可能丢失，但至少保住了一大半，比全盘重来强太多。
事务日志爆满，是另一个高频事故。很多新手遇到日志满，第一反应就是清日志，这其实是饮鸩止渴。Sybase的日志是循环使用的，如果没开，日志满了数据库会挂起。正确的做法是先备份日志，腾出空间，然后排查为什么日志增长这么快。我看过一个小伙子，直接把日志设备删了重建，结果数据库直接变“suspect”，只能从备份恢复，白白丢了半天数据。记住，日志不是垃圾，是救命稻草。
再说说恢复策略里的备份策略。很多企业备份是做了，但从没验证过恢复流程。Sybase的和是配套的，但恢复时有个关键点：日志的连续性。如果备份后没有定期备份日志，恢复时只能恢复到备份点，这之间的数据全丢。我建议运维人员每月至少做一次恢复演练，特别是核心业务库，别等到出事了才第一次尝试恢复。有个客户就吃过这个亏，备份了三个月，从没恢复过，结果真出事时发现备份文件损坏，欲哭无泪。
还有一个实战技巧，就是利用工具做表级恢复。有时候只是几张表的数据被误更新或删除，没必要全库恢复。用导出备份好的表数据，再导回来，比全库恢复快得多。我处理过一个财务系统的案例，操作员误执行了语句，把某张表的数据全部置零。当时全库恢复需要两个小时，但用bcp只花了二十分钟就找回数据，而且不影响其他业务。这个技巧的关键是提前做好表级备份计划，别只依赖全库备份。
说到数据保全，不得不提Sybase的“安全模式”和“离线模式”。当数据库出现逻辑错误时，比如页链断裂，会报错。这时候别急着修复，先做一次，保留现场。然后尝试用进入单用户模式，再用修复。如果修复失败，至少还有备份兜底。我见过一个同行，在没备份的情况下直接跑修复命令，结果越修越坏，只能从磁盘底层恢复，那个痛苦谁经历谁知道。
还有一种特殊情况是系统崩溃后，Sybase服务无法启动。这时候要考虑和这几个系统库是否正常。如果master库损坏，恢复流程会复杂很多。有个客户，服务器突然断电，重启后master设备报错。我们当时用重建master，再把系统表重新加载，折腾了整整一天才把数据库拉起来。这个教训告诉我们，master库的重要性怎么强调都不为过，它的备份要单独做，而且要加密保存。
说说灾难恢复的整体思路。Sybase数据库恢复，核心不是技术有多牛，而是预案有多细。我建议每个DBA都准备一份“故障响应手册”，里面写明：遇到什么症状，第一步做什么，第二步做什么，哪些命令不能碰。别依赖记忆，人在慌的时候脑子是空白的。手册里还要包含所有关键设备的路径、备份文件的存放位置、恢复步骤的详细命令。我自己的包里永远放着三样东西：备份磁带、恢复手册、还有一瓶速效救心丸——别笑，干这行的都知道这是刚需。
回到标题，Sybase数据库恢复实战，说到底就是两件事：故障应对和策略保全。故障应对靠的是平时演练积累的手感和反应速度，策略保全靠的是备份制度的严格执行。别把备份当成例行公事，每一份备份都是你在灾难现场的唯一救生索。我见过太多数据丢失的案例，百分之八十其实都备份了，只是没验证、没演练、没策略。下次做备份的时候，多问自己一句：如果现在就要恢复，我能做到吗？答案如果是否定的，那就赶紧去把恢复流程跑一遍。数据这东西，平时看着不值钱，丢了才知道它的分量。
