故障现象：Exchange数据库“脱机”与磁盘告警
在企业IT运维中，Microsoft Exchange Server作为核心通信平台，其稳定性至关重要。近期，我们在处理一起典型的Exchange故障时遇到了如下场景：某中型企业的Exchange 2016/2019环境突然报错，邮箱数据库（.edb）显示为"Unmounted"（脱机）状态，且EMC（Exchange管理中心）或EAC界面无法重新挂载。与此同时，系统监控发出警报，提示数据库服务器C盘或数据盘空间已满（可用空间低于1GB），导致事务日志（Transaction Logs）无法写入，进而引发数据库引擎停机。
此类故障通常由长时间未进行日志循环（Log Circularization）、意外断电、文件系统错误或磁盘容量耗尽引起。若处理不当，可能导致数据永久丢失或服务长时间中断。本文将结合一线运维经验，分享标准化的排查与修复流程，重点解析ISINTEG工具的适用边界与替代方案。
第一步：确认真实原因与日志状态
在面对数据库脱机时，首要任务是确定故障根源，而非盲目尝试修复。请按照以下步骤操作：
- 查看系统日志：打开事件查看器（Event Viewer），导航至“应用程序和服务日志” > “Microsoft” > “Exchange” > “HighAvailability”或“DatabaseAvailabilityGroup”。查找来源为MSExchangeIS的错误ID，常见的如ID 9535（数据库脱机）或ID 1221（日志文件创建失败）。
- 检查磁盘空间：确认数据库文件（.edb）及其所在日志文件夹所在的卷是否有剩余空间。Exchange需要足够的磁盘空间来增长日志文件和临时工作文件。如果磁盘已满，必须先释放空间。
- 判断日志序列号（LSN）：使用PowerShell命令
Get-MailboxDatabaseCopyStatus查看数据库副本状态。如果显示"DagCopyFailed"或"MountedOnOtherServer"，需进一步分析复制队列。
第二步：解决空间不足与日志堆积
大多数“无法挂载”的故障源于日志文件过多导致磁盘写满或数据库文件大小异常增长。以下是标准处理流程：
1. 释放磁盘空间
如果磁盘已满，请立即清理不必要的文件（如旧备份、临时文件）。确保至少有数据库文件大小110%的可用空间，以便Exchange进行页面整理和日志重放。
2. 强制日志循环（Log Circularization）
如果数据库处于不一致状态（Dirty Shutdown），但磁盘空间充足，可以尝试让Exchange自动修剪已提交的事务日志。执行以下PowerShell命令：
Remove-StorageFolder -Path "D:\Exchange\Logs" -Recurse -Force # 谨慎操作，仅适用于确认无需保留的旧日志
Or better yet, use ESEUTIL to check:
Eseutil /ml <DatabasePath>注意：直接删除日志文件是极高风险行为，除非你确信数据库已定期备份且处于可修剪状态。更安全的做法是执行离线 defrag（页面整理）前的预检。
第三步：ISINTEG 还是 Eseutil？——关键抉择
在传统认知中，ISINTEG是修复Exchange数据库关联对象（如邮箱存储）的首选工具。然而，现代Exchange运维中，ISINTEG的使用频率已大幅降低，甚至在某些情况下被微软官方建议避免使用，除非特定场景。我们需要区分两种情况：
情况A：数据库处于Dirty Shutdown（脏关闭）
这是最常见的情况，表现为数据库无法挂载，报错“Log files are missing”或“Database is inconsistent”。此时，数据库本身（EDB文件）可能结构完好，只是日志未重放。
解决方案：使用ESEUTIL /R重放日志
- 检查完整性：执行
Eseutil /mh <path_to.edb>，查看状态是否为"Dirty Shutdown"。 - 尝试在线修复（不推荐用于生产）：通常不建议对生产库直接运行
Eseutil /d（脱机压缩），因为这耗时极长且风险高。 - 重放日志：如果日志文件齐全，只需确保日志目录正确。有时，手动将日志文件复制到日志目录，然后再次尝试挂载数据库即可触发自动重放。
- 强制脱机修复（最后手段）：如果日志严重缺失或损坏，且你有最新的全量备份，可能需要恢复备份并应用增量备份/日志。若无备份，则
Eseutil /p（页面整理/硬修复）可能成功，但会丢弃损坏部分，导致数据丢失。
情况B：数据库挂载成功，但邮箱访问报错或内容索引失效
当数据库可以正常挂载（Clean Shutdown），但用户无法登录、搜索无结果或收到"Corrupted Items"错误时，才考虑使用ISINTEG。
ISINTEG的正确用法
警告：ISINTEG是一个破坏性极强的工具。它会扫描并标记或删除损坏的消息对象。在执行前，务必备份整个数据库文件（.edb）和日志文件。
- 停止Exchange服务：确保MSExchangeIS和Microsoft Search服务已停止。
- 执行预连接检查：运行
isinteg -s <ServerName> -test alltests -prerepair。这将生成一份报告，列出预计需要修复的项目数量，帮助你评估影响范围。 - 执行实际修复：运行
isinteg -s <ServerName> -test alltests -fix。此过程可能耗时数小时甚至数天，取决于数据库大小。 - 重启服务并验证：完成后，启动服务，检查日志确认无新错误，并让用户测试邮箱访问。
第四步：预防优于治疗——最佳实践总结
为了避免未来再次出现此类棘手的故障，建议实施以下维护策略：
- 监控磁盘空间：设置阈值告警，当数据库卷可用空间低于20%时立即通知管理员。
- 定期备份：确保每天执行全量备份，并启用日志循环。使用VSS（卷影复制服务）快照进行一致备份。
- 保持补丁更新：及时应用Exchange Cumulative Update（CU），以修复已知的数据库引擎bug。
- 避免直接操作EDB文件：永远不要在数据库挂载状态下复制或移动.edb文件。所有修复操作应在数据库脱机状态下进行。
- 文档化恢复计划：建立明确的RTO（恢复时间目标）和RPO（恢复点目标），并定期演练灾难恢复流程。
结语
Exchange数据库挂载失败是令人焦虑的紧急事件，但通过科学的排查步骤，我们可以有效降低风险。请记住，ESEUTIL主要用于处理底层数据库结构和日志一致性，而ISINTEG则专注于顶层消息对象的完整性。混淆两者的使用场景可能导致不可逆的数据损失。在不确定情况下，寻求微软支持或专业数据恢复服务的帮助总是明智之选。