6、查到这里，事情已经有了一定的眉目，这个多半是windows内存泄露Bug，遂google关键词: windows server 2008 r2 remote registry memory leak
找到如下链接：http://support.microsoft.com/kb/2699780/en-us
果然：Assume that you query performance counters on a remote computer by using an application on a computer that is running Windows 7 or Windows Server 2008 R2. In this situation, the memory usage of the Remote Registry service on the local computer increases until the available memory is exhausted.
解决方法：1、重启服务器，安装hotfix
2、因为重启服务器会影响到业务，所以我在想重启RemoteRegistry服务，应该也能暂时解决问题，这个bug应该是在某种固定情景下发生的。
随后，在合适的时间，我重启了这个服务，SQL Server的TargetMemory重新恢复到60多G，CPU也正常了，目前为止该问题未再发生。
后续跟进：DBA的工作，说难也难，说容易也容易，发现问题，解决问题还不够，我们还要意识到自己的欠缺，在本案例中，我之前并没有建立起SQL Server内存的监控，所以没有在第一时间就发现病情的严重性，好在该服务器并未承担重要业务，否则后果不堪设想，说不定早就崩溃过了，后怕之处在于，如果崩溃了，自然要重启服务器，到那个时候，我们连第一现场都没有，当leader问起来，我又该使劲挠头了。
该事件之后，我建立起了SQL Server内存的监控，1天后，我从新的监控数据中，又发现了一台服务器出现相同的问题！我很庆幸，不是庆幸服务器没宕机，而是庆幸我做对了。
附一张内存监控图，可以看到服务重启之后，SQL Server的Total Pages一直在上升，并逐渐稳定,Page life expectancy也在变得越来越大，CPU也能指示病症已消除，我很欣慰。
总结：
服务器在出现性能问题前，大部分是提前有一些征兆的，尤其是内存泄露，因为内存是一点点被压榨掉的，最后到达一个极限时，SQL Server就会突然Crash掉，然后只留给你一个dump，微软就笑了。有经验的大夫应该从日常的腰酸背痛中看出一些端倪，然后进一步分析，提前预知重大疾病的发生，这就是DBA的价值。这个案例，告诉我，重视服务器异常的细节变化，才能做到防患于未然。
您可能感兴趣的文章:SQL语句实现查询SQL Server内存使用状况优化SQL Server的内存占用之执行缓存SQL Server 数据页缓冲区的内存瓶颈分析SqlServer如何通过SQL语句获取处理器(CPU)、内存（Memory）、磁盘（Disk）以及操作系统相关信息SQL Server 2008 R2占用cpu、内存越来越大的两种解决方法解决SQL Server虚拟内存不足情况揭秘SQL Server 2014有哪些新特性(1)-内存数据库浅谈SQL Server 对于内存的管理[图文]SQL Server在AlwaysOn中使用内存表的“踩坑”记录sql server学习基础之内存初探
