MS SQL SERVER

<br /> <br />前段时间数据库健康检查发现SQL Server服务器的idle时间变少，IO还是比较空闲，估计是遇到了高CPU占用的语句了。<br />介绍一下背景，我们公司负责运维N多的应有系统，负责提供良好的软、硬件环境，至于应用的开发质量，我们就无能为力了<br />解决这个问题，我的思路是：找出CPU占用最大的语句。 分析查询计划。 优化。 <br />1、找出语句<br />使用SQL Server自带的性能报表（不是报表服务），找出CPU占用最大的语句。如图1所示<br /><

<br />发现问题<br />今天服务器检查的时候发现SQL Server 2005服务器的CPU负载很高，而且一直居高不下，这是我当时在现场的截图: <br /> <br />服务器是一台4路服务器有4颗XEON 3GHz的CPU，8G的内容，SQL Server 2005是32位，打了SP2。<br />该服务器上跑了很多个业务系统的数据其中属于JT的数据库就有好几个，业务量还是挺大的。<br />排除是其他进程搞的鬼，确定是SQL Server 进程把服务器搞得这么忙。<br /> 定位问题<br

<br /><br />A table scan is where the table is processed row by row from beginning to end.<br />An index scan is where the index is processed row by row from beginning to end.<br />If the index is a clustered index then an index scan is really a tabl

<br />Sqlserver 会为sql语句生成相应的执行计划，然后将编译好的sql执行计划存储到缓存中，等下次再使用相同的sql语句的时候，如果执行计划使用的索引，还有相关的统计数据，还有相关的数据没有显著的更新发生，sqlserver将从缓存中直接取出执行计划来使用，以提高sqlserver的性能。<br />sqlserver可以自动将执行的sql语句进行参数化，并在缓存中存储一条prepared的执行计划。如果使用.net应用程序使用ado.net 来调用sql语句的话，如果不使用参数，如

<br /><br />性能调校的工作千头万绪，最怕的就是像无头苍蝇般盲目地错误尝试（ trial and error ），不但旷日费时，还累积不到经验，团队与个人都难以成长，也就是说下次再碰到性能议题时，还是乱试一通。 <br />我们需要拟定计划、有步骤分阶段地执行，如此才能循序渐进，一步步朝目标前进。据微软的研究显示，过程应该分为 6 个阶段，分别是发现、探究、提案、执行、复查、收尾。这不一定适用于任何调校的情境，笔者从来也没有完全这么做，但却是个可供参考的方法论，能据以修正成自己的方法。有固

在使用SQL Server 2005的性能报表进行调优的过程中，有些语句不知在哪个数据库中执行，可参看这篇文章[原]一次SQL Server调优经历 ，于是针对这个问题，我写了两段脚本用于按照对象名找出其所在的数据库。在编写的过程中发现SQL Server 2005比SQL Server 2000在操作集合方面完善很多。第一段SQL Server 2005专用脚本使用了集合的交操作，非常简单地完成任务了，而第二段通用的就要借助临时表。运行方式很简单，把“用户修改区域”里面改成你需要查找的对象

前言:最近溫習了執行計劃方面的部份知識,為了加深印象與方便初學者,特做了如下整理.不對地方歡迎提出並指正.查看执行计划的方式:(1)菜單方式:(1.1)显示实际执行计划(1.2)显示预估的执行计划以上兩種均位於位于”查询”下拉菜单中,两者的不同之处在于当实际运行一个查询时,当前的服务器上的运算也会被考虑进去。大多数情况下,两种方式产生的执行计划产生的结果是相似的.(2)命令方式SET SHOWPLAN_TEXT ON这条命令被执行后,所有在当前这个查询分析器会话中执行的查询都不会运行,而是会显示一个基于文本