数据库恢复

数据库损坏的常见表现与原因

数据库故障和文件损坏不一样，它的症状很「专业」，对应的病因也不同：

• SQL Server 数据库变「置疑(Suspect)」：最常见。多因断电时事务日志(.ldf)写到一半、或磁盘空间满导致日志无法扩展。数据文件(.mdf)本身往往完好。
• MySQL 表标记 crashed：MyISAM表断电后索引损坏，InnoDB则可能报page corruption。强制重启循环会加重损坏。
• Oracle ORA-01578 数据块损坏：坏块扩散前处理损失最小。
• 金蝶/用友账套「账套损坏无法登录」：底层就是SQL Server数据库，财务软件还叠加了自身校验表。这类我们有专门的修复流程。
• 勒索病毒加密数据库文件：.mdf/.bak被加密。数据库文件的特殊性是：大文件往往只有头部被加密（病毒为了速度），表数据区可能完整，修复希望比普通文件大。

共同的原因就三个：断电（占一半以上）、磁盘坏道、误操作/病毒。

数据库恢复流程：每一步都在防止二次损坏

1. 停机保护现场：数据库服务停掉，禁止任何程序再写入。最忌「一边用一边修」。
2. 全盘镜像：先对数据文件所在磁盘做只读镜像，之后所有修复都在镜像副本上做——修坏了也不影响原始数据。这是和「直接上手改」的业余做法的本质区别。
3. 损坏评估：解析数据库文件头、页结构、系统表，确定损坏范围：是日志坏了（好修）、还是系统表坏了（中等）、还是数据页大面积损坏（难修但仍有办法）。
4. 分层修复：日志重建/截断 → 系统表修复 → 坏页跳过提取 → 底层解析直接抽取表数据。能走浅层就不走深层，每层都验证。
5. 一致性校验：修完的库要跑完整性检查（DBCC CHECKDB等），并抽查关键业务表：行数、金额合计、最近的单据能不能打开。数据库不是「能挂载」就算恢复成功，业务数据对得上才算。
6. 交付与加固建议：交付修复后的库+损坏原因分析。断电导致的，建议配UPS+规范关机；磁盘导致的，建议换盘+做备份计划。

财务软件账套：金蝶/用友的专项经验

番禺中小企业的财务软件以金蝶（KIS/K3）和用友（T3/T6/U8）为主，账套损坏是我们的高频业务，说几个要点：

• 先修库，再修账：账套底层是SQL Server，第一步永远是数据库层修复；库修好后财务软件还报错的，再处理软件层的账套注册信息和校验表。
• 年度账套结构我们熟：金蝶K3的AIS文件、用友的UFDATA库、T3的账套库，各版本的表结构差异都有积累，修复时知道哪些表必须完整、哪些可以从日志重建。
• 期末数据最怕丢：损坏常发生在月末结账/年结时（操作重、日志大）。我们对结账期损坏的账套会优先核对「凭证连续性」——凭证号断号意味着有单据没修回来，必须明确告知，不能糊弄交付。
• 修好后必做备份制度：财务数据丢不起。我们交付时会顺手配好自动备份（每日全盘+每小时事务日志），成本几乎为零。