Rob*_*bie 15 sql-server configuration
我正在构建一个带有 48 GB RAM、1 个 CPU 和 8 个 SATA III (6GB/s) SSD 驱动器 (128 GB Crucial m4) 和一个 LSI MegaRAID 控制器 (SAS 9265-8i) 的 SQL Server。我希望典型的工作负载主要是读取。会有一些较重的写入活动（每小时数据与 3rd 方数据提供商同步 - 每晚备份），但我怀疑典型的读/写比率约为 90% 读取/10% 写入。
选项 1：
逻辑驱动器 C：- RAID 1（2 个物理驱动器）- OS
逻辑驱动器 D：- RAID 10（6 个物理驱动器）- DB 文件/日志/tempdb/备份？
或者
选项 2：
逻辑驱动器 C：- RAID 1（2 个物理驱动器）- OS
逻辑驱动器 D：- RAID 1（2 个物理驱动器）- Db 文件
逻辑驱动器 E：- RAID 1（2 个物理驱动器）- 日志文件/备份？
逻辑驱动器 F：- RAID 1（2 个物理驱动器）- tempdb
或者
选项 3：
其他建议？
我在想选项 1 会给我更好的性能，因为所有数据库活动都将在 3 个驱动器上进行条带化（并在阵列中的其他 3 个驱动器上进行镜像），尽管选项 2 似乎模仿了传统智慧（这似乎更多地适用于机械驱动器而不是 SSD）。似乎 Stack Overflow 已经选择了选项 1。
我猜使用 SSD 可以将所有东西都放在一个逻辑驱动器上，因为此时您的服务器可能受到更多 CPU 限制而不是 I/O 限制？
我的另一个问题是我应该在哪里放置每晚备份？我们不希望备份减慢 SQL Server 的其余部分的速度，我猜将备份写入与日志相同的位置是一种很好的做法，因为这两种情况下的读/写行为都是顺序写入。
关于 RAID 的传统观点不适用于 SSD。他们并不真正需要条带化 (RAID0)。他们还容易被设计的失败，但是RAID-1通常不是SSD正确的答案，原因有二：1）是一种浪费，半SSD阵列的容量（他们是昂贵的）和2）固态硬盘的故障特征线索朝向两个镜中的驱动器在非常近的时间间隔，以失败（即相关的故障），因此使整个阵列无用。有关更长的讨论，请参阅差分 RAID：重新思考 RAID 以提高 SSD 的可靠性。有些人建议将Raid-6用于 SSD。
此外，SQL Server 文件布局的传统智慧不适用于 SSD。我建议您观看SSD 上的 SQL：Hot and Crazy Love并查看此答案中的基准链接。
将数据的随机 IO 模式与日志序列分离的标准方法根本不适用于 SSD，因此我会选择您的选项 1 并提出警告：
将日志与使用 SSD 的数据分离的问题是系统的 RPO（恢复点目标）问题，而不是性能问题。如果 RPO 以分钟为单位定义，则使用一个共享阵列并每 [RPO] 分钟进行一次日志备份。如果 RPO 在几秒钟内定义，则使用单独的阵列。
老实说，如果 RPO 很紧，我会为数据阵列保留 SSD，并为日志使用一对镜像的昂贵（企业）可靠的微调器。
您应该选择选项 2，如下所示：
Logical Drive - RAID 1 (2 physical drives)
1 partition C: OS
2 partition D: backups / log files
Logical Drive E: - RAID 1 (2 physical drives) - DATA files
Logical Drive F: - RAID 1 (2 physical drives) - INDEX files
Logical Drive G: - RAID 1 (2 physical drives) - tempdb
通过将数据和索引分离在 2 个不同的数据文件中，然后将其存储在 2 个不同的物理逻辑驱动器中，您将获得磁盘 io 的巨大增加，因为当您查询时，您将有一个磁盘旋转用于表数据，另一个磁盘旋转用于存储表数据。同时为您的索引旋转。
将 tempdb 与备份分开，因为那里也会发生很多事情。不要混淆备份和数据文件。尽管备份不是每天进行，但一旦发生就会对您的 IO 造成巨大影响。根据您的业务和数据库的使用情况，有些人或很多人可能会在备份期间抱怨。
希望这可以帮助
| 归档时间： |
|
| 查看次数： |
13545 次 |
| 最近记录： |