邮件告警：当前的SQL Server 使用内存过高，当前VM 的内存为128GB， SQL Server使用了90%的内存，需要调查具体原因以及处理方法。
排查内容：
1 业务逻辑：当前业务每天早上6点到8点半，会有批量ETL导入数据到SQL Server，这个批处理的表象—— 耗费时间长和SQLServer资源使用大
2 监控resource：监控工具检查了当前内存资源使用情况，从内存的置换率以及内存中页中生存周期参数，自上次重启后指标相对平稳
3 内存
page life expactancy ：持平，内存页稳定
buffer cache：100%，内存一点没浪费
5 cpu以及IO等其他参数并不高
6 检查代码级别 -- 查看消耗TopN
可以看到大量的table scan ，index scan，cluster index scan ，hash join。。。额
—— 这基本上可以破案了，但是本着严谨的态度，我们继续往下看
7 物理锁：—— 这是root cause 吗？ 物理锁过多，主要会产生IO瓶颈
针对pagelatch，确实看到PAGELATCH_EX\PAGELATCH_UP\PAGELATCH_SH在等待时间里面属于Top前面的。
通常pagelatch存在是正常的，但是如果因查询效率问题导致lock时间过长，那么对性能影响是比较明显的
8 检查服务器级别的配置
TempDB ，当前已经配置8个tempdb前期已经缓解了tempdb争用问题，与业务数据库放在不同磁盘下。Maxdop默认是0。
小结和建议：
重启服务器来释放内存，是不建议的。
因为一旦清理所有后续需要的数据需要重新磁盘获取需要warm up，对性能有较大影响。
重启的确可以释放所有内存，但是root cause并不在这里。
根据当前情况，我并没有发现内存出现瓶颈问题，内存中页维持平稳，没有出现大量也被pageout现象。
**root cause**：执行语句层面的执行效率问题——比如，
一大表扫描是查询时间比较长
二会有大量的逻辑读甚至物理读，通过线上抓取的语句可以看到，一些语句的物理读次数非常大。
三从历史抓取的SQL也发现很多慢Query，建议从优化Query来提高ETL批处理效率问题，避免因SQL性能问题导致批处理执行缓慢
优化方案：
**执行语句优化**
通过我提供的消耗TopN Sql，抓取Top 的执行次数或读次数以及执行时间等维度的结果
开发和dba需要一起分析上面的结果，针对慢SQL分析执行计划，并结合业务需要，重写或局部修改sql脚本。比如，索引失效
**数据库层面优化**
理清批量处理中涉及的表列表，重点统计如下：
- 索引情况（针对执行语句，是否存在丢失、重复、无用的索引），操作前需要与开发人员、业务人员评估那些索引是常用的，那些是无用的-删除。
- 统计信息情况（统计信息是否过期、是否需要更新统计信息，特别是大表的统计信息维护）
**服务器配置优化：**
TempDB，不需要优化
MaxDOP，不需要优化
