脱机压缩 AD 数据库（ntds.dit）必须先停用 NTDS 服务并进入目录服务还原模式（DSRM），使用 esentutl /d 命令执行物理层压缩与碎片整理，同时需确保临时盘空间充足、备份完整，并在重启后验证 AD 启动及复制状态。
脱机压缩 AD 数据库（ntds.dit）前必须停用 NTDS 服务
直接在运行状态下操作 ntds.dit 会触发文件锁定，导致 esentutl.exe 报错 operation not supported on a database that is in use。唯一安全方式是进入目录服务还原模式（dsrm）或使用 windows server 安全模式（带网络驱动器的 dsrm 更稳妥）。
实操建议：
- 重启服务器，在启动时按 F8（或通过
bcdedit /set safeboot dsrepair配置后重启），进入 DSRM - 以 DSRM 管理员账户登录（不是域管理员，是安装 AD 时设定的 DSRM 密码）
- 确认
NTDS服务未运行：sc query ntds应返回STATE: 1 STOPPED - 数据库路径通常为
%SystemRoot%\NTDS\ntds.dit，务必先备份整个NTDS文件夹
用 esentutl /d 执行脱机压缩与碎片整理
esentutl.exe 是 Windows 内置的 ESE（Extensible Storage Engine）工具，/d 参数会重建数据库、释放未使用空间、重排页结构并校验完整性——这既是“压缩”，也是底层索引物理优化。
关键参数说明与避坑点：
- 基础命令：
esentutl /d "%SystemRoot%\NTDS\ntds.dit" /t"%SystemRoot%\Temp\tempd.it"——/t指定临时文件路径，**必须有足够空间（至少等于当前ntds.dit大小）** - 加
/p可强制修复损坏（仅当esentutl /g检出错误时才用，否则可能引入不一致） - 不加
/o时默认保留旧文件（ntds.dit.001），磁盘空间吃紧时需手动清理 - 执行时间取决于数据库大小和磁盘 I/O，10 GB 文件常需 30–90 分钟；期间不可中断电源或强制关机
索引优化不能靠 esentutl，得靠 repadmin 和 ADSI Edit 检查逻辑结构
esentutl /d 优化的是物理存储层，但 AD 的查询性能瓶颈往往来自低效的 LDAP 查询路径或缺失/冗余索引。Windows 不允许手动增删 AD 索引，所有索引由系统自动管理，但可验证和触发重建：
- 检查当前索引状态：
repadmin /showattr * "CN=Schema,CN=Configuration,DC=domain,DC=com" /atts:searchFlags /schemamode - 若发现某属性
searchFlags值为 1（仅存储）、没设 9（可索引+在 GC 中复制），说明它不参与快速查找——但这属于架构设计问题，不能现场改 - 真正能做的：用
ldp.exe连接 localhost:389（DSRM 下连不上，必须回到正常启动后），执行Search查看慢查询是否命中索引（看返回结果中的searchTime和entriesReturned比值） - 如长期存在高开销查询，应归因于缺乏对应索引属性，而非数据库文件本身——这时要修改 schema（需谨慎，且需林功能级别 ≥ 2003）
压缩后必须运行完整 AD 启动验证，否则可能白干
压缩完成不代表 AD 能正常工作。常见失败场景是日志文件（edb.log、res1.log）残留或权限异常，导致启动时卡在 Event ID 1000 或 NTDS General 1168 错误。
- 退出 DSRM，正常重启，观察事件查看器中
Directory Service日志是否有1000（成功启动）或1137（数据库恢复失败） - 运行
dcdiag /v /test:replications /test:intersite，重点看VerifyReferences和CheckSecurityError是否通过 - 确认
ntds.dit文件大小确实下降（对比压缩前的dir %SystemRoot%\NTDS\ntds.dit），但若降幅小于 5%，大概率是空闲空间本就不多，或压缩被中断 - 切勿跳过
backup步骤：压缩后的数据库一旦启动失败，只能靠之前备份回滚，esentutl /r在脱机状态下无效
AD 数据库没有“在线索引重建”这种操作，所谓优化本质是两件事：脱机物理整理（esentutl /d） + 长期查询模式分析（ldp/repadmin）。很多人卡在 DSRM 登录失败或临时盘空间不足，这两个点比命令本身更常导致整个流程中断。
