《Troubleshooting SQL Server》读书笔记-磁盘I/O配置 第二章 Disk I/O Configuration。 对于SQL Server,磁盘I/O的配置主要针对数据库工作负载，考虑和权衡两个点： 1. 磁盘容量VS磁盘吞吐量 一个1TB的库放在一块2TB的磁盘上，容量是够了，但是磁盘吞吐量能
《Troubleshooting SQL Server》读书笔记-磁盘I/O配置
第二章 Disk I/O Configuration。
对于SQL Server,磁盘I/O的配置主要针对数据库工作负载，考虑和权衡两个点：
1. 磁盘容量VS磁盘吞吐量
一个1TB的库放在一块2TB的磁盘上，容量是够了，但是磁盘吞吐量能满足工作负载吗？通常会使用RAID，服务器空间，合适的RAID级别也是容量与吞吐量权衡的一种结果。
2. 顺序IO VS. 随机I/O
数据库日志文件操作通常是顺序IO，数据文件通常随机IO会多很多。而磁盘的顺序IO性能要高于随机IO，因为前者需要移动磁头，后者不需要。
以工作负载不同的IO方式在存储上对数据库做隔离就很重要了。
选择正确的RAID级别(Chose the right RAID level)
使用RAID的好处，通常有：1. 增强IO性能 2. 增加IO吞吐量 3. 增加单个逻辑设备的可用容量 4. 数据冗余
而选择何种RAID级别，主要取决于工作负载的类型。像数据库日志文件以顺序写为主，就要考虑RAID的写入性能，数据文件需要在读、写和可用容量间做权衡。
RAID 0：提供数据条带化和高效的IO性能，但是没有数据冗余保护，所以SQL Server一般不采用。
RAID 1: 提供完全的数据冗余保护，较低IO性能，成本较高。可以考虑放置单个的事务日志文件。如果放置多个事务日志文件，香港空间，则每个日志文件的顺序IO操作交织在一起，
就变成了随机IO，性能会下降。
RAID 5(6): 提供数据冗余保护，且容量损失少，高效读性能。但是写性能相对较低。每次某块数据更新时，则要重新计算和更新奇偶效验数据。当某块磁盘失效，整个RAID的性能会急剧下降，
因为读取失效磁盘上的数据，需要经过效验计算得到。RAID6是RAID5的扩展，只是存有两份效验数据在不同的磁盘上，但可用容量只有磁盘总量的一半且至少4块盘。
这样，虚拟主机，还不如用RAID10。可以考虑放置读多于写的数据文件。
RAID10: 先组成RAID1,再用RAID1组成RAID0。容量只有磁盘总容量的一半，提供数据冗余保护，写入性能相对较快。最多允许每组RAID1失效一块磁盘。
比相同数量的磁盘RAID5读性能要慢一些。
RAID01: 先组成RAID0,再用RAID0组成RAID1。最多只允许其中一组RAID0失效。当任意一块磁盘失效，整个RAID01也失效了。数据丢失风险高于RAID10。
除了磁盘本身的硬性性能外，还有一些很重要因素影响其性能：
1. RAID控制器的缓存大小和配置 2. RAID条带大小 3. 分区对齐 4. NTFS格式化的文件簇大小
一定要做基准测试来确定IO子系统的配置正确性，不能迷恋于理论上的数据。推荐的基准测试工具SQLIO和IOmeter,推荐SQL Server压力测试工具SQLIOSim
数据文件、日志文件和tempdb最好物理隔离。
数据文件：读远多于写、只读或者写延迟不影响系统性能的情况下可置于RAID5或者RAID6.相反则可以考虑RAID10.
日志文件：可以考虑RAID1和RAID10。多个写入频繁的日志文件置于同一个物理磁盘上或者磁盘碎片会加剧写入压力。
tempdb: 它的功能决定它是写密集型数据库，最好与用户库物理隔离，置于raid1或者RAID10。当然也可以置于SSD和RAMDisk上。
可以为tempdb创建多个相同配置的数据文件,减少系统页急用问题。
DAS VS. SAN
DAS简单附加即可使用，性能可预估，也不需要额外经验维护，同时也没有SAN的各种高级功能（如支持集群、磁盘阵列镜像和基于阵列的复制）。相对便宜。
SAN适用于企业级存储，相对较贵。但它是用于优化存储使用方式，而不一定是优化存储性能。
对故障诊断需要额外的存储经验或者依赖于外部资源(SAN管理员或者供应商)。
诊断磁盘IO问题
两个比较重要的性能计数器Avg. Disk sec/Read和Avg. Disk sec/Write。
一般它们的值50ms=存在性能问题。
IO瓶颈通常还有PAGEIOLATCH_*, ASYNC_IO_COMPLETION, IO_COMPLETION, 或者 WRITELOG等待类型的严重等待。
常见的磁盘I/O问题
诊断磁盘问题前，一定要确认系统不存其它方面的瓶颈。
1. 只考虑容量而非性能
一个1TB的OLTP库放在一块2TB的磁盘上，容量满足，性能通常满足不了。SAN网络和磁盘通常不会是SQL Server独占的，SQL Server也不知道LUN是否是独立的物理磁盘。
很多时候是与其它应用共享的，故障诊断时就要特别关注IO指标是否只是SQL Server造成的。
2. 错误的负载隔离
数据文件、日志文件和tempdb要物理隔离，因为IO方式大相径庭。还要特别注意SAN分配给SQL Server的存储单元是否与其它应用物理隔离。
3. 错误的分区对齐
参照Storage Area Network (SAN) for DBA's
4. 错误的SAN带宽配置
不要迷恋理论值或者供应商提供的数据，一定要经过基准测试，确保SAN的性能满足工作负载，尤其是多路SAN。
总结
对于存储，一定要有清晰的规划，一定要经过测试(基准和压力)。
posted on
