SQL数据库管理—第四章使用windows性能监控器监控数据库
4.1 监控概述
监控数据库的目标就是了解SQL数据库内部发生的情况，SQL数据库的并发，用户连接数，服务器资源（CPU,内存，IO）效率，应用等待情况。捕捉这些情况让DBA门了解系统正常运行的情况。
4.2 建立基准
系统上线后，并发，用户连接数，服务器资源（CPU,内存，IO）效率，应用等待情况建立基准，系统更新或者长时间运行后可以根据基准做出对比，出现问题及时解决。
4.3 识别瓶颈
| 可能的瓶颈方面 |
对数据库的影响 |
| 内存使用量 |
分配的内存不足或可由 Microsoft SQL Server 使用的内存不足导致性能下降。 数据必须从磁盘读取而非直接从数据缓存读取。 当需要页时，Microsoft Windows 操作系统将通过与磁盘交换数据来执行大量分页操作。 |
| CPU 使用率 |
长期的高 CPU 使用率可能表明 Transact-SQL 查询需要优化或 CPU 需要升级。 |
| 磁盘输入/输出 (I/O) |
Transact-SQL 可以优化查询以减少不必要的 I/O（例如，使用索引）。 |
| 用户连接与并发 |
可能有太多用户同时访问服务器，从而导致性能下降。并发操作批处理导致性能下降。 |
| 阻塞锁 |
应用程序设计不合理可能导致锁定或妨碍并发，因而导致更长的响应时间和更低的事务吞吐速度。 |
4.4 监控数据库用户连接数，并发数。
SQL数据库设置最大连接数select @@max_connections 默认32767
设置SQL数据库最大连接数（一般不用设置）exec sp_configure 'user connections', 100
SELECT @@CONNECTIONS查看数据库自上次启动以来的连接次数。
并发数是SQL数据库每秒进行的批处理数目。
可以利用windows自带的性能计数器查看用户连接处与并发数
4.4.1 SQLServer： SQL Statistics： Batch Requests/Sec （SqlServer统计：批请求/秒）。用户确定系统负载大小。
批请求/秒是指SQL Server是每秒接收批处理的数量。这个计数器是可以查看我们的服务器处理速度。数字越大，表明我们的数据库处理查询的吞吐量越大。像许多计数器一样，没有一个单一的数字，可以说明服务器是太忙了。如今的服务器越来越强大，因此可以一刻不停的处理更多批次的请求。随着时间的推移，应该收集这个计数器，以确定我们的服务器环境基准数值是什么。
4.4.2 SQLServer： General Statistics： User Connections（SqlServer的：一般统计：用户连接 ）
用户连接计数器是指同一时刻连接到服务器的用户的数量。我们需要观察这个基线用户连接数，不同时间的用户数量是不同的，且有个高低区间。如果此计数器的值下降，并在系统上的负荷是相同的，那么可能有一个瓶颈，导致我们的服务器不能来处理的正常负荷，这个需要检查了。当然也要注意计数器的值下降也可能是因为连接的确少了的原因。
4.4.3 SQL Server Databases ：Transactions/sec：每秒为数据库启动的事务数。用户确定系统负载大小。
4.5 监控数据库CPU
CPU是服务器中最重要的资源。在数据库服务器中，CPU的使用情况应该时刻监控以便SQLServer一直处于最佳状态。
4.5.1 Processor:% Processor Time 达到75%就需要注意了。
一个确定 CPU 使用率的有效方法是使用系统监视器中的 Processor:% Processor Time 计数器。 该计数器监视 CPU 执行非闲置线程所用的时间。 持续 80% 到 90% 的状态可能表明需要升级 CPU 或需要增加更多的处理器。
4.5.2 System: Processor Queue Length 达到处理器数+1就需要注意了
对应于等待处理器时间的线程数。 当一个进程的线程需要的处理器循环数超过可获得的循环数时，就产生了处理器瓶颈。 如果有很多进程在争用处理器时间，可能需要安装一个速度更快的处理器。 如果使用的是多处理器系统，则可以增加一个处理器。
如果处理器队列的长度一直超过服务器上可用处理器的总数量+1，则可能表示处理器堵塞。
4.6 监控数据库内存（需要在理解）
监控内存使用。监控服务器的内存是非常重要的事情，有很多情况会引起内存消耗。所以要经常性地做检查。
1 Memory: Available Mbytes:剩余可用内存
2 Memory: Pages/sec:理解为从硬盘读到内存的数据。服务器上只跑的sqlserver，那这个指标的理想范围应该是0-20之间，偶尔超过20的话影响不大，如果这个值频繁的超过20，那说明你的这台服务器可能需要加内存了。
3 SQL Server: Buffer Manager: Buffer Cache Hit Ratio: 缓存命中率,在缓冲区高速缓存中找到而不需要从磁盘中读取(物理I/O)的页的百分比。可判断内存是否充足，最好保证95%以上。95% 或更高的命中率是令人满意的。 添加更多内存，直到该值始终大于 95%。 大于 95% 的值表示数据缓存满足所有数据请求中 95% 以上的请求。
4SQL Server: Buffer Manager: Page life expectancy，表示数据页驻留在内存的秒数。微软建议最少300秒。如果在一个实例中经常低于300秒，意味着数据保留的时间少于5分钟就被移出内存。
4.7 监控数据库IO
Microsoft SQL Server性能在很大程度上取决于I / O子系统（IOS）。IOS的延迟可能导致许多性能问题。
4.7.1 Primary主要
PhysicalDisk: Avg. Disk sec/Write 平均 磁盘秒/写
PhysicalDisk: Avg. Disk sec/Read 平均 磁盘秒/读
数据库日志不超过5ms
OLTP数据库不超过10MS
OLAP不超过25MS
Less than 10 ms - very good 棒
Between 10 - 20 ms – good 好
Between 20 - 50 ms - slow, needs attention 慢需要注意
Greater than 50 ms – Serious I/O bottleneck 严重的IO瓶颈
4.7.2 Secondary 次要
PhysicalDisk: Avg. Disk Queue Length Disk Queue也就是服务器端发出的存储操作正在等待被存储处理的请求数目。例如有一个应用发出一条读请求，但是目标磁盘当时正在处理其他任务。那么这个新的读请求就会被放在磁盘队列里。这时候磁盘队列的值就是1。如果这个值大于2，说明由磁盘阵列性能问题。
PhysicalDisk: Avg. Disk Queue Length 如果这个值特别大，可以在监控这三个参数，Avg. disk read queue length、Avg. disk write queue length、Current Disk Queue Length。
举例 由4块硬盘组合成的RAID5
Avg. Disk Queue Length=12 平均每块硬盘就是12/4=3 很显然由性能问题。
PhysicalDisk: Disk Bytes/sec 用来确定存储的带宽是否够用。
PhysicalDisk: Disk Transfers/sec 用来确定IOPS是否够用。
首先要监控主要计数器，如果主要计数器没有问题，就不用监控次要计数器了。
磁盘传输/秒由磁盘读取/秒和 磁盘写入/秒组成。您可以使用这些计数器来确定驱动器是否没有足够的支持磁盘。使用这些计数器时，可能需要调整已实现的RAID类型的值。要确定要使用的值，请使用以下公式：
Raid 0 - 每个磁盘的I / O =（读取+写入）/磁盘数量
Raid 1 - 每个磁盘的I / O = [读取+（2 *写入）] / 2
Raid 5 - 每个磁盘的I / O = [读取+（4 *写入）] /磁盘数量
Raid 10 - 每个磁盘的I / O = [读取+（2 *写入）] /磁盘数量
例如，如果磁盘传输/秒的最大值为1800，则可以确定该驱动器的RAID组中至少需要10个15k RPM磁盘。通常，15k RPM磁盘每秒能够执行大约180个I / O请求（IOPS）。180 * 10 = 1800.对于更高的值，您可能需要10个以上的磁盘。因为达到单个硬盘的IOPS80%就会出现性能问题，所以最少需要12个以上的硬盘。
如果出现严重的性能问题，可以考虑以下解决。
- 使用更快的磁盘
- 增加硬盘数量
- 使用更快的RAID类型，例如RAID 10。
- 数据文件和日志文件放置在不同的磁盘阵列中。
Disk Bytes/sec很高， Avg. Disk sec/Write ，Disk sec/Read 都很高说明是硬盘的问题，每秒读出数据很多，平均读写很高说明，也许硬盘性能就是很好。 Disk sec/Write ，Disk sec/Read高，Disk Bytes/sec很低说明是硬盘的问题。所有参数要综合起来看。
4.8 监控数据库阻塞与锁
4.8.1 SQLServer： Locks： Lock Waits / Sec： （SqlServer的：锁：锁等待/秒：所有 ）这个值最好为0.
为了使SQL Server来管理系统上的并发用户时，SQL Server需要经常锁定资源，有时长有时短暂。锁等待/秒是指每秒针系统等待恰好所申请的资源被锁定的次数。理想情况下我们不希望任何要求等待锁，因此，要保持这个计数器为零或接近零。
4.8.2 SQLServer： Locks：Number of Deadlocks/sec： （SqlServer的：锁：每秒导致死锁的锁请求数 ）这个值最好为0.
指每秒导致死锁的锁请求数。死锁对于应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器必须为0，最好也为0.
4.8.3 SQLServer： General Statistic： Processes Block（SqlServer的：一般统计：进程阻塞）
进程阻塞计数器是指某一时刻进程阻塞的的个数。当一个进程因为申请的资源得不到释放时，这个进程被阻塞了，而其它依赖于同一个资源的进程都不能向前推进，最后导致阻塞的进程越来越多，要解决这个问题唯一的办法是直到其资源释放。理想情况下我们不希望看到任何阻塞的进程，当进程被阻止时应该深入调查。
4.9 监控数据库日志性能
SQL Server ：Databases 计数器
4.9.1 SQL Server ：Databases ：Log Flushes/sec
SQL Server每秒在这个数据库上做的日志写的次数。每秒日志刷新数目
4.9.2 SQL Server ：Databases ：Log Bytes Flushed/sec
SQL Server每秒在这个数据库上做的日志写的量Bytes。
4.9.3 SQL Server ：Databases ：Log Flush Wait Time
写入日志的操作曾经因为磁盘来不及响应而遇到的等待时间。这种等待会导致前端的事务不能提交，所以会严重影响SQL Server的性能。正常的SQL Server，刷新日志的总等待时间（毫秒）这个值应该在绝大多数时间里都是0.
4.9.4 SQL Server ：Databases ：Log Flush Waits/sec
在每秒提交的事务里，有多少个事务曾经等待过日志写入完成。理想情况下，日志写入应该立刻完成，不需要等待。如果有等地啊，需要检查存放日志文件的磁盘性能。每秒等待日志刷新的提交数目
