标签: hardware

有许多博客文章和最佳实践文章颂扬将 SQL Server 数据文件放在一个硬盘驱动器上并将事务日志放在另一个硬盘驱动器上的优点。给出的原因是数据库文件将经历随机读取和写入，而事务日志将只有顺序写入。

但是，如果您有数百个数据库呢？将数百个事务日志文件放在一个单独的磁盘上是否有真正的性能优势？如果要写入多个事务日志，那么我认为事务日志写入与数据库写入一样随机。

我正在尝试针对 95% 的数据已存档和删除的数据库以 1GB 的块运行 dbcc 收缩文件。我有一个 235GB 的文件，其中 9GB 是数据/索引。我想把它缩小到 50GB。我知道收缩数据库文件是不好的，它会导致碎片等。作为数据清除/收缩的一部分，我们还有一个重建 idnex 脚本。

当我在自己的工作站（四核、12GB RAM、2 个 SATA 驱动器）上针对数据库运行 dbcc 收缩文件脚本时，收缩需要大约 8-10 分钟。

在数据清除后针对数据库的相同副本运行相同的代码时，在我们的测试环境中（80 多个内核、128GB RAM、SSD SAN），需要 70 分钟。请注意，在运行收缩文件时，此服务器上几乎没有活动。它已运行 4 次，结果相同。

然后我采用了不同的方法，将剩余的 9GB 移动到不同的文件组和物理文件。在我自己的工作站上对空的 230GB 文件运行 dbcc shrinkfile 以将其缩小到 50GB 需要 < 1 分钟。

使用相同的方法，在测试环境中，再次需要 70 分钟以上。

在测试环境的 70 分钟运行期间，我根据 Brent Ozar 的脚本拍摄了前后的 waitstats 快照，并且返回的 waittypes 没有显示任何值得关注的内容。下面的前 3 行：

第二采样时间 采样持续时间（以秒为单位） wait_type 等待时间（秒） 每次等待平均等待毫秒数
2013-05-28 11:24:22.893 3600 写日志 160.8 143066 1.1
2013-05-28 11:24:22.893 3600 CXPACKET 20.9 13915 1.5
2013-05-28 11:24:22.893 …

我们正在扩展我们的数据库服务器。我想知道我们应该如何计算我们的数据库需要多少硬件资源？

以下是有关我们当前数据库服务器的一些信息：

• MySQL 数据库
• 所有表的 InnoDB
• 约80桌
• 最大的表是：15 GB、13 GB、12 GB、5 GB，其余小于 1 GB
• 磁盘上的数据库大小为 175 GBibdata1和 56 GB 没有它
• 数据库每月增长约 10%——12 个月前约为 5-6%
• 大约 60 个连接在正常使用中运行
• InnoDB 缓冲区大小为 24 GB 中的 16 GB，利用率为 99%
• CPU 使用率在 2.27GHz Intel Xeon 8 核 L5520 上约为 30%
• 我们有大约 33% 的写入和 66% 的读取
• 根据下面的代码片段，我们有大约 2.31 TPS 和 1126 QPS——QPS 似乎在 750 和 1500 之间上下波动

.

use information_schema;
select VARIABLE_VALUE into @num_queries from GLOBAL_STATUS where VARIABLE_NAME = 'QUESTIONS';
select VARIABLE_VALUE into @uptime …

我们现在为我们的数据库配备了一台新服务器，除此之外，我们还有 128GB 的​​ RAM 可用（以前我有 16GB）。我知道 SQL Server 非常擅长管理它的资源，但我想知道是否应该在服务器/数据库设置或处理代码（存储过程/索引等）中使用任何特殊设置或策略来确保 SS可用内存的最佳优势。

DB 大约 70GB，它是一个非事务性数据库（它是一个数据仓库）。所以基本上大写然后大量读是事情的正常流程。

Windows 2008R2 Enterprise 上的 SQL Server 2008 R2 标准版（64 位）

• 服务器有超过 300 GB 的内存，但控制面板中的总内存使用量从未超过 86 GB
• 将 SQL 配置为使用最大内存量

• 即使在大量使用情况下 - CPU 超过 80% 数分钟

• 专用 SQL Server

• 几个大型数据库
• 一个频繁使用的表的索引大小超过 10 GB

将服务帐户设置为在内存中锁定

这是正常的吗？

我可以测试什么？

我可以让 SQL Server 使用更多内存吗？

一位潜在客户想要评估我们的存储系统。他们在发送给我们的虚拟测试机上运行带有 4KB NTFS 的 Windows 2008R2 x64。他们似乎并不知道这一点，所以我认为假设环境没有被调整是合理的。测试是插入、索引、搜索、删除。我不知道工具。

鉴于 Windows NTFS 块大小为 4KB，SQL 写入 64KB 块 - 假设 SAN 上的块大小为 64k 是一个不错的选择是否安全？

它们运行 SQL Server 2008，也许是标准的。

我们有 14 GB 的 CSV，总计 1.38 亿行。我首先使用 InnoDB 将其导入到 MySQL 表中，然后使用 MyISAM 再次尝试。在这两种情况下，对主键（只是一个自动递增的 int）的简单 SELECT 需要 6-7 秒，尽管 MyISAM 有时在 5-6 秒时快一点。

我们只需要写一次数据，我一直在使用mysqlimport。考虑到这一点，如何提高查询速度？

...我们有 2 演出 RAM 并且一切都是一张表，这毫无价值（并且由于查询的性质，它必须保持这种状态）。考虑到硬件，这是我可以期待的最佳性能吗？或者还有什么我应该尝试的，比如压缩？或者真的，我需要更多的内存？

我想将 SQL Server 数据库从与 Web 服务器的共享配置移动到它自己的专用框。我目前的预算允许我将 4 个磁盘放在一个阵列中，并带有一个热备用。我想扩展到 8 个以上的驱动器，但现在的成本有点超出我的预算（而且可能有点矫枉过正）。

所以我的问题是，当限制为 4 个磁盘时，SQL Server 2012 的最佳配置是什么？该数据库大约为 29 GB，并且每月增长大约 250-500 MB。数据库通常会提供 80% 的读取到 20% 的插入/更新/删除。

我从研究这个主题中了解到，我的选择如下：

1. 在单个卷上具有所有功能的RAID 5。
2. 双 RAID 1，一个卷上有操作系统、备份和系统数据库，另一个是数据库 + 日志文件。
3. RAID 10在单个卷上具有所有功能。