SQL Server 2019列存储索引重建触发OOM导致AlwaysOn AG故障转移问题咨询

• 第一步：定位内存分配明细
  首先导出故障时间点的SQL错误日志、Windows系统应用/系统事件日志，确认OOM报错的具体触发进程。通过sys.dm_os_memory_clerks的历史采集数据（如果有监控的话），排查列存储相关内存clerk、内存优化表相关clerk、TDE加密相关内存占用的增长趋势，确认是否存在非预期的内存泄漏或超额分配。
• 第二步：核实列存储索引重建的资源占用
  拉取Ola Hallengren维护脚本的执行历史，确认故障时正在重建的列存储索引的大小、并行度配置，对比SQL 2016和2019的列存储重建逻辑差异：SQL 2019默认会为大规模列存储重建申请更高的内存授予，若未限制最大并行度，单操作可申请的内存上限远高于2016版本。同时排查故障时间点是否有其他大查询、批量写入操作和索引重建争抢内存资源。
• 第三步：验证最大内存配置合理性
  核算当前环境的固定内存开销总和：内存优化表的总数据大小、memory-optimized tempdb的预留内存、polybase服务进程的内存占用（即使未使用，启动状态也会占用独立于SQL最大内存的系统内存），确认给操作系统预留的64GB空间是否足够覆盖上述非SQL进程+系统本身的内存需求，是否存在操作系统内存不足触发SQL进程被查杀的情况。
• 第四步：排查已知BUG
  对照SQL Server 2019 CU12的官方补丁说明，确认是否存在列存储索引重建、TDE、内存优化表组合场景下的内存泄漏已知问题，重点关注内存clerk的未释放内存统计。

• 临时规避方案：调整Ola Hallengren索引重建作业的参数，添加MAXDOP = 8（可根据CPU核心数调整为总核心数的1/4~1/2）、MAX_GRANT_PERCENT = 10参数，限制单次索引重建操作的最大并行度和内存授予占比，避免单操作吃掉过多内存。对超过100GB的大尺寸列存储索引，调整为分区级逐分区重建，降低单次操作的内存需求。
• 内存配置优化：如果核算后发现固定内存开销超出预留的64GB，可适当调低SQL最大内存配置，为操作系统和外部进程预留足够空间；若内存优化表占用了超过预期的SQL内存空间，可评估是否可以将非高频访问的内存优化表调整为普通磁盘表，释放内存空间。
• 补丁升级：若排查确认故障由CU12的已知内存泄漏BUG导致，可将SQL Server 2019升级至最新的累计更新补丁，修复已知问题。
• 常态化管控：启用资源调控器，为索引重建、统计信息更新等维护作业单独配置资源池，限制维护操作的最大内存、CPU占用上限，避免维护操作影响业务稳定性。

内容的提问来源于stack exchange，提问作者Wilfred van Dijk