SQL Server 2012数据库文件超maxsize限制问题咨询

• 版本固有缺陷：SQL Server 2012 SP3 CU10 存在自动增长逻辑校验bug，当数据/日志文件采用百分比自动增长配置时，增长触发时的大小计算存在整数溢出问题，单次增长操作可能直接突破预设的maxsize阈值，该问题在SQL Server 2012 SP4及后续正式版本中已完成修复。
• 手动操作遗留：如果曾通过ALTER DATABASE语句或SSMS图形界面手动修改过文件物理大小，且操作时设置的文件大小大于原有maxsize配置，系统不会自动触发maxsize和实际文件大小的一致性校验，会直接保留实际大小大于配置maxsize的状态。
• 元数据不同步：数据库经历过异常宕机、存储故障恢复、强制分离/附加、中断的还原操作后，系统目录中存储的文件配置元数据可能和磁盘上的实际文件属性出现偏差，导致maxsize约束记录和实际文件大小不匹配。

sp_helpfile执行结果参考：

所有操作前必须先完成数据库全量备份，优先在测试环境验证无误后再操作生产环境。

• 低风险零停机方案：更新maxsize配置匹配实际需求
  1. 执行DBCC UPDATEUSAGE (当前数据库名)更新数据库空间使用统计，再通过sp_spaceused确认各文件的实际已用空间大小
  2. 结合业务后续3-6个月的空间增长预期，重新设置合理的maxsize阈值，执行语句参考：

  ALTER DATABASE [对应数据库名]
  MODIFY FILE (
    NAME = N'文件逻辑名（从sp_helpfile结果中获取）',
    MAXSIZE = 目标最大大小（单位MB，例如预留100G则设置为102400）
  )
  

  3. 执行完成后重新运行sp_helpfile确认配置生效即可，该操作仅更新元数据，不会阻塞业务运行。
• 低峰操作方案：收缩文件至maxsize阈值内
  如果确认超出maxsize的部分属于未使用的空闲空间，可在业务低峰期执行文件收缩操作，将文件物理大小调整到maxsize阈值范围内：

  DBCC SHRINKFILE (N'文件逻辑名', 目标大小MB（需小于等于设置的maxsize值）)
  

  注意不要将文件收缩到小于实际已用空间的大小，否则后续自动增长会产生大量磁盘碎片，拖慢查询性能。
• 长期根治方案：完成数据库版本升级
  当前运行的SQL Server 2012 SP3 CU10已停止官方支持，除文件大小校验bug外还存在多个已知稳定性、安全漏洞，按现有升级计划完成版本升级后，即可从底层修复自动增长突破maxsize的逻辑缺陷，避免同类问题重复出现。

目前数据库可正常运行属于符合预期的状态：当文件大小已经超过maxsize后，SQL Server不会强制拦截现有读写请求，仅会在后续触发自动增长时抛出空间不足错误，因此不会影响现有业务运行，但需尽快处理避免后续写入失败。

内容的提问来源于stack exchange，提问作者Hans van Dam