资料库作为信息系统的根基，支撑着整个套用系统，发挥着非常重要的作用，，它的健壮与否直接决定着整个信息系统能否高效、稳定运行。其中SQL Server凭藉着简单易用性占据了大部分的资料库市场份额。

从大量用户群体中出大部分SQL Server系统存在以下问题

1. 快速开发导致的结构设计以及代码的低效性

2. 参数配置不合理，导致硬体的利用率低下

3. 没有专业的资料库DBA(资料库管理员)来保障资料库的持续健康运行

4. 公司的资料库伺服器系统服务于关键业务流程，一旦出现故障影响重大

5. 担心资料库系统有潜在的严重问题，可能会影响其正常运行

6. 面对众多的系统配置选项及管理任务方案，感觉无从下手

Expert for SQL Server可以做到

1. 从硬体、作业系统、SQL Server、资料库配置、高可用及备份、安全、性能七个方面清晰地了解到系统的真实运行状况，做到“让你知道真实的自己”。

2. 採用专用的分析工具对数据汇总、分析；

3. 维护人员可以监控关键性能指标的趋势，如资源消耗、资料库对象、统计数据等，让维护人员能够在问题影响最终用户之前解决问题。

4. 呈现出当前系统的性能指标，定位导致系统性能变慢的原因，并提出性能最佳化后回响速度提升的预期。

5. 为维护人员提供多次、持续的健康检查及故障处理服务，确保资料库能稳定、高效运行。

1. 伺服器参数检测

伺服器记忆体参数的配置

最大用户连线参数是否限制

允许更新参数

锁参数

打开对象参数

CPU资源调度优先权参数

恢复间隔参数

填充因子参数

相似性掩码参数

轻量级执行绪参数

工作集参数

远程存储过程访问参数

远程登录延时参数

资料库的自动收缩参数

资料库的自动关闭参数

资料库的自动更新统计信息参数

资料库的恢复模型设定

2. 性能计数器检测

--1指处理器执行非闲置执行绪时间的百分比,测量处理器繁忙的时间 这个计数器设计成用来作为处理器活动的主要指示器,可以选择单个CPU实例,也可以选择Total。30%以上代表存在少许等待现象，60%以上代表等待比较严重。

--"\\!HN!\Processor(_Total)\%% Processor Time"

--2磁碟平均的读伫列，正常指标在1以下，大于1就说明有排队现象了

--"\\!HN!\PhysicalDisk(_Total)\Avg. Disk Read Queue Length"

--3磁碟平均的写伫列, 正常指标在1以下，大于1就说明有排队现象了

--"\\!HN!\PhysicalDisk(_Total)\Avg. Disk Write Queue Length"

--4定义该数值小于15ms为Excellent，介于15～30ms之间为良好，30～60ms之间为可以接 受，超过60ms则需要考虑更换硬碟或 是硬碟的RAID方式了

--"\\!HN!\PhysicalDisk(_Total)\Avg. Disk sec/Transfer"

--5它测量磁碟在採样间隔期间的空闲时间百分比。如果此计数器低于 20%，则表示磁碟系统处于满负荷状态。可考虑将当前的磁碟系统更换为速度更快的磁碟系统。

"\\!HN!\PhysicalDisk(_Total)\% Idle Time"

--6由要求刷新所有髒页的检查点或其他操作每秒刷新到磁碟的页数，如果此值过高，可能是磁碟或时记忆体不足造成的

"\\!HN!\SQLServer:Buffer Manager\Checkpoint pages/sec"

--7惰性编写器不需要为创建可用缓冲区而频繁执行检查点。合理範围0

"\\!HN!\SQLServer:Buffer Manager\Lazy writes/sec"

--8快取命中率,在缓冲区高速快取中找到而不需要从磁碟中读取(物理I/O)的页的百分比. 如果该值较低则可能存在记忆体不足或不正确的索引

--"\\!HN!\SQLServer:Buffer Manager\Buffer cache hit ratio"

--9每秒发出的物理资料库页读取数。此统计信息显示的是所有资料库间的物理页读取总数。

--由于物理 I/O 的开销大，可以通过使用更大的数据快取、智慧型索引、 更有效的查询或更改资料库设计等方法，将开销降到最低

--"\\!HN!\SQLServer:Buffer Manager\Page Reads/sec"

--10指每秒等待工作空间,记忆体授权的进程数. 该计数器应该儘可能接近0,否则预示可能存在着记忆体瓶颈

--"\\!HN!\SQLServer:Memory Manager\Memory Grants Pending"

--11必须等待锁请求的平均等待时间（毫秒）。如果该指标的值很高，则系统可能正经历严重的资源竞争问题。

--"\\!HN!\SQLServer:Locks(_Total)\Average Wait Time (ms)"

--12未能立即授予的锁请求数，如果该值始终大于0，则表示事物有问题

--"\\!HN!\SQLServer:Locks(_Total)\Lock Waits/sec"

--13锁管理器每秒请求的新锁和锁转换数. 通过最佳化查询来减少读取次数, 可以减少该计数器的值

--"\\!HN!\SQLServer:Locks(_Total)\Lock Requests/sec"

--14指每秒导致死锁的锁请求数. 死锁对于应用程式的可伸缩性非常有害, 并且会导致恶劣的用户体验. 该计数器必须为0

--"\\!HN!\SQLServer:Locks(_Total)\Number of Deadlocks/sec"

--15必须等待授予的闩锁请求的平均等待时间（毫秒）。

--(平均闩等待时间(毫秒)) 一个SQL Server执行绪必须等待一个闩的平均时间，以毫秒为单位。如果这个值很高，你可能正经历严重的竞争问题

--"\\!HN!\SQLServer:Latches\Average Latch Wait Time (ms)"

--16未能立即授予的闩锁请求数。

--(闩等待/秒) 在闩上每秒的等待数量。如果这个值很高，表明你正经历对资源的大量竞争。

--"\\!HN!\SQLServer:Latches\Latch Waits/sec"

--17 批量请求，每秒收到SQL的批处理请求，此数值受（I/O，用户数据，高速快取大小，请求複杂程式）而定，数值越高表明吞吐量越好

--"\\!HN!\SQLServer:SQL Statistics\Batch Requests/sec"

--18每秒SQL的编译次数，当用户达到稳定状态时，该值应该稳定，如果不稳定，就是大量的用户，连线与断开，资源浪费。

--"\\!HN!\SQLServer:SQL Statistics\SQL Compilations/sec"

--19 每秒语句重新编译的次数，一般情况下，此值越小，越好，如果值偏大，就表明SQL语句的重用性不好，请最佳化SQL语句，多次重编译会加重CPU负担

--"\\!HN!\SQLServer:SQL Statistics\SQL Re-Compilations/sec"

--20索引的每秒查找与全表每秒扫描次数

--"\\!HN!\SQLServer:Access Methods\Index Searches/sec"

--"\\!HN!\SQLServer:Access Methods\Full Scans/sec"

--当表上有很多插入动作时，一些页面会被放满。为了维护索引上的顺序，SQL需要把一页劈成两页，这个动作叫“pagesplit”。当资料库的修 改比较多，尤其是插入比较多时，pagesplit是难免的。 如果这个值比较高，而你又 觉得他的确对性能有影响，可以考虑定 期重建索引，使用比较小的填充值(fillfactor)
--"\\!HN!\SQLServer:AccessMethods\PageSplit/sec"

--21系统中活动的SQL连线数. 该计数器的信息可以用于找出系统的最大并发用户数

--"\\!HN!\SQLServer:General Statistics\User Connections"

3. 资源消耗检测

a) 由于语句运行时间太长而导致的阻塞

b) 表扫描或者索引扫描带来的阻塞

c) 未结束事务带来的阻塞

d) 资源消耗类型

4. 查询语句

a) 执行时间长的语句的分布

b) 消耗CPU高的语句

c) 消耗IO高的语句

d) 和执行计画进行匹配找到可以最佳化的语句

1. float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使最佳化器无法执行一些本来可以进行的最佳化操作。

2. 儘量避免在where子句中对栏位进行函式或表达式操作，这将导致引擎放弃使用索引而进行全表扫描

3. 避免使用!=或>、IS NULL或IS NOT NULL、IN ，NOT IN等这样的操作符因为这会使系统无法使用索引。

4. 不要在where子句中的“=”左边进行函式、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

5. 索引并不是越多越好，索引固然可以提高相应的 select 的效率，但也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。

6. 应儘可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若套用系统需要频繁更新 clustered 索引数据列，那幺需要考虑是否应将该索引建为 clustered 索引。

7. 避免频繁创建和删除临时表，以减少系统表资源的消耗。

Expert for SQL Server分为收集和解析两部分

收集工具是一个绿色的可执行的档案，直接放在SQL Server伺服器上运行。

解析工具需要安装，安装后打开收集的档案进行解析。