域控制器提示数据库空间不足或损坏，本质是ntds数据库（ntds.dit）及其日志文件无法正常读写或校验失败，表现为服务启动卡死、lsass崩溃、登录失败、事件id 1000/1168/1103/623报错乃至蓝屏；需同步排查磁盘物理空间是否耗尽及数据库是否损坏或脏关闭，并通过esentutl校验、垃圾回收、日志回滚或强行修复等手段分级处置。
域控制器提示数据库空间不足或损坏，本质是 NTDS 数据库（ntds.dit）及其配套日志（edb.log、res1.log等）无法正常读写或校验失败。这类问题不会只显示“空间不足”四个字，而是表现为服务启动卡死、LSASS崩溃、登录失败、事件日志报错（如ID 1000/1168/1103/623），甚至蓝屏或自动重启。排查需分两路同步进行：一是确认磁盘物理空间是否真实耗尽，二是验证数据库文件本身是否损坏或处于非一致状态。
检查磁盘可用空间与NTDS路径挂载状态
数据库无法启动，常因底层存储不可用。先排除硬件和系统级瓶颈：
- 进入目录服务还原模式（DSRM）或 Windows PE 环境，避免依赖已失效的 AD 服务
- 运行
diskpart→list volume，确认C:\Windows\NTDS\所在卷是否在线、有足够空间（建议保留 ≥500MB 空闲） - 若使用 SAN 或虚拟磁盘，检查磁盘管理中该卷是否显示为“脱机”；如是，右键选择“联机”，并确认 SAN 策略设为
ONLINEALL - 执行
dir C:\Windows\NTDS\，观察ntds.dit文件大小是否异常（如为 0 字节、被重命名为ntds.dit.bad）；同时检查edb.log、res1.log是否存在且未被锁定或损坏
验证NTDS数据库完整性与关闭状态
即使磁盘有空间，数据库也可能因异常关机或写入中断而处于“脏关闭”或损坏状态：
- 运行命令：
esentutl /mh "C:\Windows\NTDS\ntds.dit"若输出含State: Dirty Shutdown，说明上次未正常关闭，需配合日志回滚；若为State: Invalid或Corrupt，则确认损坏 - 运行
esentutl /g "C:\Windows\NTDS\ntds.dit"进行完整性扫描，定位损坏页（如报告“Page checksum error”） - 检查事件查看器 → “Applications and Services Logs” → “Directory Service”，重点关注 ID 1168（Jet 引擎错误）、ID 1925（元数据不一致）、ID 623（版本存储溢出）
区分“空间不足”真实类型：磁盘满 vs 版本存储溢出
AD 中的“空间不足”常被误解——多数情况并非磁盘满，而是内部版本存储区（Version Store）达到上限，根源是逻辑删除对象堆积或长事务未提交：
- 执行
Get-ADObject -Filter * -IncludeDeletedObjects | Measure-Object，若返回对象数远超实际用户/计算机数量（如超百万），说明回收站残留过多 - 在 DSRM 下运行：
ntdsutil→activate instance ntds→garbage collection，强制清理已删除但未物理清除的对象 - 排查长事务：用
repadmin /showrepl查看复制是否卡在某一步；用 Process Explorer 检查是否有 PowerShell/WMI 进程持续轮询全部安全日志或执行未提交的 LDAP 修改
尝试修复与降级兜底方案
确认损坏后，按风险由低到高依次操作：
- 若有连续日志文件（
edb*.log），执行：esentutl /r edb /l "C:\Windows\NTDS\" /s "C:\Windows\NTDS\"回滚事务 - 日志不全但数据库头可读，用
esentutl /p "C:\Windows\NTDS\ntds.dit"强行修复（⚠️会丢失未提交更改，修复后必须跟esentutl /d碎片整理） - 无备份且软修复失败：立即禁用故障 DC 网卡，从健康 DC 转移 FSMO 角色；若仅剩单点，只能通过
ntdsutil执行元数据清理（metadata cleanup），再重建新 DC
