十大最佳存储实践
2009-12-30 11:01
357 查看
要想让 SQL Server 系统的性能和运行达到最佳,关键在于适当配置 IO 子系统。以下是 SQL Server 小组推荐的一些最常用、最好的 SQL Server 存储配置方法。
了解
SQL Server
的
IO
特征以及
您的
应用的具体
IO
要求
/
特征。
为了成功地为您的 SQL Server 应用设计和部署存储,您需要了解您的应用的 IO 特征,并对 SQL Server 的 IO 模式有个基本了解。性能监视器是捕获现有应用的这些信息的最佳位置。在此,您需要问自己以下几个问题:
应用程序的读写比率是多少?
典型的 IO 速率(每秒 IO、MB/s 和 IO 的大小)都是多少? 监视以下性能监视器计数器:
Average read bytes/sec、average write bytes/sec
Reads/sec、writes/sec
Disk read bytes/sec、disk write bytes/sec
Average disk sec/read、average disk sec/write
Average disk queue length
有多少 IO 本质上是有序的?又有多少 IO 本质上是随机的? 此应用从根本上来说是 OLTP 应用还是关系数据仓库应用?
若要了解 SQL Server IO 的核心特征,请参阅 SQL Server 2000 I/O 基本知识
。
更多
/
更快的心轴
有助于改善
性能
确保拥有足够多的心轴来支持 IO 要求,且滞后时间可以接受。
使用文件组来满足备份/还原和部分数据库可用性等管理要求。
使用数据文件跨特定 IO 配置(物理磁盘和 LUN 等)将数据库“条带化”。
不要“过度”优化存储设计;通常,设计越简单,性能越好,灵活性也更高。
除非您对自己的应用非常了解,否则不要通过将对象有选择性地放在不同的心轴上来过度优化 IO。
务必预先考虑增长策略。随着数据的增多,您将如何管理数据文件/LUN/RAID 组的增长? 最好预先设计这一策略,不要等以后到了生产部署中再重新调整数据文件或 LUN。
在
部署之前验证配置
在
部署 SQL Server 之前,务必对 IO 子系统进行基本的吞吐量测试。确保这些测试可以达到您的 IO
要求,且其滞后时间也在可以接受的范围内。SQLIO 就是一个可用来实现该目的的工具。该工具附带了一个文档,其中介绍了测试 IO
子系统的基本知识。请下载 SQLIO 磁盘子系统基准工具
。
您要明白,运行 SQLIO 测试的目的不是模拟 SQL Server 的准确 IO 特征,而是测试 IO 子系统对于常用 SQL Server IO 类型可达到的最大吞吐量。
也可以使用 IOMETER 取代 SQLIO。
始终
将日志文件放在
RAID 1+0
(或
RAID 1
)磁盘上。这么做可以:
更好地保护文件免受硬件故障的破坏,以及
获得更好的写性能。
注
意:通常,RAID 1+0 可为写密集型应用提供更大的吞吐量。所获得的性能将因硬件供应商的 RAID 实现方式而异。RAID 1+0
最常见的替代方式是 RAID 5。通常, RAID 1+0 比任何其他提供数据保护的 RAID 级别(包括 RAID 5)所提供的写性能都要好。
在物理磁盘级将日志与数据隔离
无法实现这一点时(如在整合的 SQL 环境中),请考虑 I/O 的特征,并将相似的 I/O 特征(即所有日志)分到同一个心轴上。
将异类工作负荷(IO 和滞后时间特征迥异的工作负荷)组合在一起可能会对整体性能产生不利影响(例如,将 Exchange 和 SQL 数据放在同一个物理心轴上)。
考虑
TEMPDB
数据库的配置
在安装 SQL Server 之后,务必先确定 TEMPDB 的大小,并将其移到足够大的存储区。
如果将 TEMPDB 放在 RAID 1+0,性能可能会有所提升(取决于 TEMPDB 的使用)。
对于 TEMPDB 数据库,为每个 CPU 创建 1 个数据文件,如下文第 8 项中所述。
按照
CPU
的
个数创建相应数量的数据文件有利于提高分配密集型工作负荷的可伸缩性。
建议为主机服务器上的每个 CPU 创建 .25 到 1 个数据文件(每个文件组)。
TEMPDB 更应如此,此时,建议为每个 CPU 创建 1 个数据文件。
双核按 2 个 CPU 算;逻辑处理器(超线程)不算。
请勿
忽视
SQL Server
的一些基本
知识
数据文件的大小应该一致 – SQL Server 使用按比例的填充算法,该算法倾向于将数据分配到在空闲空间多的文件中。
预先确定数据和日志文件的大小。
不要依赖 AUTOGROW,请手动管理这些文件的增长。为安全起见,可以保留 AUTOGROW 为 ON,但应主动管理数据文件的增长。
不要忽视存储配置的基础
使用存储供应商推荐的最新 HBA 驱动程序
使用从 HBA 生产商网站下载的存储供应商特定的驱动程序
根据您的 IO 量优化 HBA 驱动程序的设置。通常,驱动程序特定设置应由存储供应商提供。但我们发现默认的队列深度值一般不够深,无法支持 SQL Server IO 量。
确保存储阵列固件满足最新建议要求。
使用多路径软件在 HBA 和 LUN 之间达到平衡,并确保运行正常
简化配置并提供可用性优势
Microsoft Multipath I/O (MPIO):供应商借助 Microsoft 提供的驱动程序开发工具包生成设备特定模块 (DSM)。
了解
SQL Server
的
IO
特征以及
您的
应用的具体
IO
要求
/
特征。
为了成功地为您的 SQL Server 应用设计和部署存储,您需要了解您的应用的 IO 特征,并对 SQL Server 的 IO 模式有个基本了解。性能监视器是捕获现有应用的这些信息的最佳位置。在此,您需要问自己以下几个问题:
应用程序的读写比率是多少?
典型的 IO 速率(每秒 IO、MB/s 和 IO 的大小)都是多少? 监视以下性能监视器计数器:
Average read bytes/sec、average write bytes/sec
Reads/sec、writes/sec
Disk read bytes/sec、disk write bytes/sec
Average disk sec/read、average disk sec/write
Average disk queue length
有多少 IO 本质上是有序的?又有多少 IO 本质上是随机的? 此应用从根本上来说是 OLTP 应用还是关系数据仓库应用?
若要了解 SQL Server IO 的核心特征,请参阅 SQL Server 2000 I/O 基本知识
。
更多
/
更快的心轴
有助于改善
性能
确保拥有足够多的心轴来支持 IO 要求,且滞后时间可以接受。
使用文件组来满足备份/还原和部分数据库可用性等管理要求。
使用数据文件跨特定 IO 配置(物理磁盘和 LUN 等)将数据库“条带化”。
不要“过度”优化存储设计;通常,设计越简单,性能越好,灵活性也更高。
除非您对自己的应用非常了解,否则不要通过将对象有选择性地放在不同的心轴上来过度优化 IO。
务必预先考虑增长策略。随着数据的增多,您将如何管理数据文件/LUN/RAID 组的增长? 最好预先设计这一策略,不要等以后到了生产部署中再重新调整数据文件或 LUN。
在
部署之前验证配置
在
部署 SQL Server 之前,务必对 IO 子系统进行基本的吞吐量测试。确保这些测试可以达到您的 IO
要求,且其滞后时间也在可以接受的范围内。SQLIO 就是一个可用来实现该目的的工具。该工具附带了一个文档,其中介绍了测试 IO
子系统的基本知识。请下载 SQLIO 磁盘子系统基准工具
。
您要明白,运行 SQLIO 测试的目的不是模拟 SQL Server 的准确 IO 特征,而是测试 IO 子系统对于常用 SQL Server IO 类型可达到的最大吞吐量。
也可以使用 IOMETER 取代 SQLIO。
始终
将日志文件放在
RAID 1+0
(或
RAID 1
)磁盘上。这么做可以:
更好地保护文件免受硬件故障的破坏,以及
获得更好的写性能。
注
意:通常,RAID 1+0 可为写密集型应用提供更大的吞吐量。所获得的性能将因硬件供应商的 RAID 实现方式而异。RAID 1+0
最常见的替代方式是 RAID 5。通常, RAID 1+0 比任何其他提供数据保护的 RAID 级别(包括 RAID 5)所提供的写性能都要好。
在物理磁盘级将日志与数据隔离
无法实现这一点时(如在整合的 SQL 环境中),请考虑 I/O 的特征,并将相似的 I/O 特征(即所有日志)分到同一个心轴上。
将异类工作负荷(IO 和滞后时间特征迥异的工作负荷)组合在一起可能会对整体性能产生不利影响(例如,将 Exchange 和 SQL 数据放在同一个物理心轴上)。
考虑
TEMPDB
数据库的配置
在安装 SQL Server 之后,务必先确定 TEMPDB 的大小,并将其移到足够大的存储区。
如果将 TEMPDB 放在 RAID 1+0,性能可能会有所提升(取决于 TEMPDB 的使用)。
对于 TEMPDB 数据库,为每个 CPU 创建 1 个数据文件,如下文第 8 项中所述。
按照
CPU
的
个数创建相应数量的数据文件有利于提高分配密集型工作负荷的可伸缩性。
建议为主机服务器上的每个 CPU 创建 .25 到 1 个数据文件(每个文件组)。
TEMPDB 更应如此,此时,建议为每个 CPU 创建 1 个数据文件。
双核按 2 个 CPU 算;逻辑处理器(超线程)不算。
请勿
忽视
SQL Server
的一些基本
知识
数据文件的大小应该一致 – SQL Server 使用按比例的填充算法,该算法倾向于将数据分配到在空闲空间多的文件中。
预先确定数据和日志文件的大小。
不要依赖 AUTOGROW,请手动管理这些文件的增长。为安全起见,可以保留 AUTOGROW 为 ON,但应主动管理数据文件的增长。
不要忽视存储配置的基础
使用存储供应商推荐的最新 HBA 驱动程序
使用从 HBA 生产商网站下载的存储供应商特定的驱动程序
根据您的 IO 量优化 HBA 驱动程序的设置。通常,驱动程序特定设置应由存储供应商提供。但我们发现默认的队列深度值一般不够深,无法支持 SQL Server IO 量。
确保存储阵列固件满足最新建议要求。
使用多路径软件在 HBA 和 LUN 之间达到平衡,并确保运行正常
简化配置并提供可用性优势
Microsoft Multipath I/O (MPIO):供应商借助 Microsoft 提供的驱动程序开发工具包生成设备特定模块 (DSM)。
相关文章推荐
- 【转】MS SQL 十大最佳存储实践
- SQL-Server十大最佳存储实践
- API设计的十大最差和五大最佳实践
- hadoop-impala十大优化之(8)—impala优化之HDFS缓存最佳实践
- 虚拟机最佳实践:单个 VM、临时存储和已上传磁盘
- js-新兴的API,最佳实践,离线应用于客户端存储
- 提高DB2存储过程性能和健壮性的3个最佳实践.
- Hadoop-impala十大优化之(4)—根据执行计划进行性能优化及最佳实践
- 构建大型关系数据仓库的十大最佳实践
- 业务连续管理(BCM)十大最佳实践标准
- (转)针对 SAP 数据库维护 SQL Server 的十大最佳实践
- 桌面虚拟化最佳实践3—存储规划(上) 推荐
- hadoop-impala十大优化之(6)—控制资源使用最佳实践
- DB2存储过程开发最佳实践(1)
- DB2 存储过程开发最佳实践
- 虚拟机最佳实践:单个 VM、临时存储和已上传磁盘
- 十大PHP最佳安全实践
- 虚拟化:十大虚拟化最佳实践
- DB2 存储过程开发最佳实践
- DB2 存储过程开发最佳实践