引言
在企业邮件系统的日常运维中，Microsoft Exchange Server 是核心组件。然而，由于硬件故障、非正常关机或磁盘IO瓶颈，Exchange数据库（.edb）经常会出现不一致的状态，导致数据库挂载失败或用户无法收发邮件。常见的错误代码包括 MSExchangeIS 的事件ID 1004、1011 或 1013，这通常意味着数据库文件存在逻辑损坏。
本文将深入探讨当Exchange 2019数据库因 ISINTEG 错误而无法启动时，如何进行专业的故障排查与修复。我们将通过具体的命令行工具和逐步操作，帮助IT管理员恢复数据库完整性。
故障现象与分析
当数据库挂载失败时，管理员通常会遇到以下情况：
- 服务状态异常：Microsoft Exchange Information Store 服务启动后立即停止。
- 事件查看器报错：在“应用程序”日志中，来源为 MSExchangeIS 的严重错误，提示“Database is dirty”或“ISINTEG errors detected”。
- 客户端连接失败：Outlook 或 OWA 用户无法连接到邮箱，提示“无法连接到 Microsoft Exchange”。
首先，我们需要确认故障的根本原因。打开 事件查看器 (Event Viewer)，导航至 应用程序和服务日志 -> Microsoft -> Exchange -> Mailbox。查找红色感叹号标记的错误事件。如果错误信息中包含 -2014 (JET_errWriteFailed) 或 -1018 (JET_errRecordCorrupted)，则表明数据库存在物理或逻辑层面的损坏，需要立即进行干预。
修复前的准备工作
在执行任何修复操作之前，必须确保数据的安全性。错误的修复操作可能导致数据进一步丢失或不可逆的损坏。
1. 备份数据库文件
即使数据库处于卸载状态，也建议将 .edb 文件及其关联的事务日志文件（.log）复制到另一个安全的磁盘位置。这是防止修复失败导致数据永久丢失的最后防线。
2. 停止相关服务
确保所有依赖 Exchange 数据库的服务都已停止。以管理员身份打开 PowerShell 或 CMD 窗口，执行以下命令：
net stop "Microsoft Exchange Information Store" net stop "Microsoft Exchange Transport"
核心修复步骤：ISINTEG 工具详解
ISINTEG (Information Store Integrity) 是 Exchange 提供的一个内置命令行工具，用于检查和修复数据库结构的一致性。它分为两个阶段：-PRERUN（预运行检查）和 -FIX（修复模式）。
第一步：执行 ISINTEG -PRERUN 检查
在直接修复之前，先运行预检查以评估损坏程度并生成报告。这将帮助管理员判断是否值得进行修复，或者是否应该从备份中恢复。
1. 打开 Exchange Management Shell (EMS)。
2. 输入以下命令（假设数据库名为 Mailbox Database 1）：
isinteg -s <ServerName> -prerun -d "Mailbox Database 1"
截图描述：执行后，屏幕会显示扫描进度，并列出检测到的错误数量。如果错误数量极少（如几个警告），修复成功率较高；如果错误成千上万，建议谨慎考虑。
第二步：执行 ISINTEG -FIX 修复
如果 PRERUN 确认数据库可修复，则执行实际修复操作。此过程可能会花费较长时间，取决于数据库大小。
1. 在 EMS 中输入：
isinteg -s <ServerName> -fix -d "Mailbox Database 1"
注意：
- -fix 参数会修改数据库文件以清除损坏的对象。
- 建议在维护窗口期间执行，因为此过程会锁定数据库。
截图描述：修复过程中，控制台会不断滚动显示处理的项目名称。完成后，会显示“Processing Complete”以及修复的错误总数。
第三步：验证修复结果
修复完成后，再次运行 -prerun 命令以验证是否还有残留错误。
isinteg -s <ServerName> -prerun -d "Mailbox Database 1"
如果结果显示错误数为 0 或仅有少量无害警告，则修复成功。
后续处理与重新挂载
1. 清理事务日志
如果之前的故障是由于日志链断裂导致的，可能需要手动清理一些旧的、不再需要的日志文件（仅限确定这些日志已备份或无需恢复的情况）。但在大多数 ISINTEG 修复场景下，我们依靠 Exchange 自带的日志回放机制。
2. 尝试重新挂载数据库
使用 PowerShell 命令尝试挂载数据库：
Mount-Database -Identity "Mailbox Database 1"
如果挂载成功，检查事件查看器确认没有新的错误产生。此时，用户可以尝试重新登录 Outlook 或访问 OWA。
3. 使用 Dirty Shutdown 特殊处理
如果数据库状态显示为 Dirty Shutdown，有时需要重置日志序列。可以使用 eseutil /mh 查看数据库状态。如果状态为 Clean Shutdown 但仍无法挂载，可能是元数据不一致，此时可能需要使用 eseutil /p 进行硬修复（High-level repair），但这属于最后手段，风险极高，可能导致数据大量丢失，仅建议在无备份且必须保留数据时使用。
预防措施与建议
为了避免未来再次出现此类问题，建议采取以下措施：
- 定期备份：实施严格的 Exchange 备份策略，确保事务日志的连续性和数据库副本的完整性。
- 监控磁盘健康：使用工具监控存储子系统的 IOPS 和延迟，避免磁盘硬件故障引发数据库损坏。
- 正常关机：确保服务器重启时，Exchange 服务能优雅停止，避免强制断电导致数据库处于 Dirty 状态。
- 补丁管理：保持 Exchange Server 的最新累积更新 (CU)，微软会修复已知的数据库稳定性 bug。
结语
Exchange 2019 数据库的 ISINTEG 错误是常见的运维挑战。通过规范的 isinteg -prerun 检查、-fix 修复以及严谨的数据备份策略，IT 管理员可以有效恢复邮件服务的可用性。切记，在任何修复操作前，备份是不可或缺的第一步。