sqlserver 性能优化流程

sqlserver 性能优化流程

数据库作为数据的主要载体，当用户突然反馈数据库出现性能下降时，问题的原因往往多种资源相互作用的结果。

本文总结了一次实际工作中遇到的典型案例，方便同类问题的处理。

1、Windows 日志-系统

【现象描述】

2017-01-01 至今，windows日志中存在大量磁盘，网络等硬件错误，且故障时间多发生在业务高峰时间；硬件问题汇总信息如下：

磁盘错误汇总:

传呼期间在设备 \Device\Harddisk3\DR3 上检测到一个错误。

传呼期间在设备 \Device\Harddisk5\DR5 上检测到一个错误。

驱动程序在 \Device\Harddisk1\DR1 上检测到控制器错误。

网络错误汇总:

网络“群集网络 1”上群集节点“xxxx”的群集网络接口“xxxx - 心跳”出现故障。请运行“验证配置”向导检查网络配置。如果此情况持续出现，请检查与网络适配器相关的硬件或软件错误。同时还要检查节点所连接的任何其他网络组件(如集线器、交换机或网桥)中的故障。

群集网络“群集网络 1”处于关闭状态。没有任何可用节点可以使用该网络进行通信。请运行“验证配置”向导检查网络配置。如果此情况持续出现，请检查与网络适配器相关的硬件或软件错误。同时还要检查节点连接到的任何其他网络组件(如集线器、交换机或网桥)中的故障。

【优化建议】

建议咨询硬件相关人员进行磁盘与网络检查，修复硬件故障；如果该硬件故障无法修复，需要由硬件提供商给出合理的问题原因解释，与规避该问题的方式，并进行归档备案；

2、资源监视器

【现象描述】

通过监控图，发现 tempdb 数据库的 读、写资源消耗较高；

【优化建议】

建议将 tempdb 数据文件与 db_name 数据文件分别存储在 独立的 物理硬盘，减少IO资源争用；

建议将 tempdb 数据文件放在 ssd 固态硬盘上，提供IO响应性能（db_name 库仍存储在机械硬盘）；

参考：

http://www.cnblogs.com/changbluesky/archive/2010/04/15/1711733.html

http://blog.csdn.net/misterliwei/article/details/45395463

3、索引碎片整理

【现象描述】

逻辑扫描碎片：无序页的百分比。该百分比应该在0％到10％之间，高了则说明有外部碎片。

对 数据库 db_name 中的表 my_table 进行索引碎片扫描，发现逻辑碎片数高达97.34%，说明当前索引碎片很多；

DBCC SHOWCONTIG 正在扫描 ‘my_table’ 表…

表: ‘my_table’ (1023342710)；索引 ID: 1，数据库 ID: 8

已执行 TABLE 级别的扫描。

- 扫描页数…………………………..: 7484

- 扫描区数…………………………: 944

- 区切换次数…………………………: 4353

- 每个区的平均页数……………………: 7.9

- 扫描密度 [最佳计数:实际计数]…….: 21.50% [936:4354]

- 逻辑扫描碎片 ………………: 97.34%

- 区扫描碎片 ………………: 67.58%

- 每页的平均可用字节数……………………: 2311.6

- 平均页密度(满)…………………: 71.44%

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

【优化建议】

建议在业务空闲时，执行索引碎片整理；

– 显示指定的表的数据和索引的碎片信息。

– 结果分析：

– “逻辑扫描碎片”和“区扫描碎片”（对于较小的区）的值是表的碎片级别的最好指标。这两个值应尽可能接近零，但 0% 到 10% 的值都是可接受的。

dbcc showcontig(my_table);

dbcc showcontig(my_table) with FAST, TABLERESULTS, ALL_INDEXES, NO_INFOMSGS;

– 索引碎片整理完成后，需要更新表统计信息

– 对当前数据库中所有用户定义表和内部表运行 UPDATE STATISTICS。

EXEC sp_updatestats

– 显示指定表上的指定目标的当前分发统计信息。

DBCC SHOW_STATISTICS(‘my_table’,’PK_my_table’);

参考：http://blog.csdn.net/y_h_t/article/details/6120945

4、规范大范围量查询在高峰期的执行

【现象描述】

在高峰期，执行大范围数据查询，将增加io消耗，导致正常挂号，收费业务等待；

【优化建议】

建议尽量在空闲时间执行大范围数据查询业务；

5、历史业务数据截断

【现象描述】

当前 db_name 数据库存储最近6年的历史数据，数据库文件47G；

常规的数据查询多集中在最近1月或最近1年的数据，历史数据访问频率极低；

大量历史数据占用服务器硬件资源(IO，内存，CPU)，增加了常规业务的IO操作等待时间；

【优化建议】

建议按业务日期截断数据，在线库只保留最近1（或n）年的数据，历史数据到备份库检索；

建议将历史数据库放到闲置服务器，减少与 db_name 库的io争用；

6、将查询业务与事务分库；

参照二三级医院的实施方案；

考虑到实现复杂且运维成本较高，不建议采用；