标签: storage

磁盘可以维持的平均每秒输入/输出操作是调优 MySQL / InnoDB 数据库的一个非常重要的因素，因为它推动了脏 InnoDB 缓冲池页面刷新回磁盘的速度。

有没有一种方法或公式可以用来估计我的 RAID 10 磁盘阵列可以运行的每秒平均 I/O 操作数？

我正在使用具有以下格式的表格：

CREATE TABLE dbo.ID_STORE
( WORKING_ID bigint PRIMARY KEY CLUSTERED )

该表存储了大约 200 万行，但存储的 id 不是连续的，MAX(WORKING_ID)-MIN(WORKING_ID) 大约是 24百万。

当我查看已用空间时，我发现大约 57 兆字节，而我预期略高于 2 10 ^ 6 x 8 = 16 兆字节。谁能解释一下区别？

编辑：这些数字是从第一次导入到所述表中获得的。该表在填充之前也会被截断。

我们正在运行 SQL Server 2008 R2。

我正在使用 SPBlitz，它说我在驱动器 H 上的存储写入速度很慢。 Blitz 将这些定义为“平均超过 20 毫秒”。

但当然，有人问：“超过多少？”

是否可以使用查询来确定以毫秒为单位的平均存储写入量？

谢谢，嗯

我的公司有一个用于 LANDesk 的小型 SQL 环境，他们希望将所有服务器迁移到每个区域的单个 SQL 集群。我想知道的是，我如何确定这种场景的容量？我已经获得了每台服务器（All Landesk）的数据库增长，我可以将这些数据作为整合到单个 SQL 集群的粗略估计吗？Windows 团队告诉我，来自这些服务器的数据有点不稳定，可能无法给出他们想要的准确结果。

有问题的新集群已经有几个数据库，但还没有达到最大容量。一旦他们开始添加来自服务器的剩余数据，它应该达到其全部容量。我已经运行 Perfmon 一段时间了，为了检查数据库增长，我使用了 sqlskills.com 中的以下 TSQL 代码

SELECT
[database_name] AS "Database",
DATEPART(month,[backup_start_date]) AS "Month",
AVG([backup_size]/1024/1024) AS "Backup Size MB",
AVG([compressed_backup_size]/1024/1024) AS "Compressed Backup Size MB",
AVG([backup_size]/[compressed_backup_size]) AS "Compression Ratio"
FROM msdb.dbo.backupset
WHERE [database_name] = N'AdventureWorks'
AND [type] = 'D'
GROUP BY [database_name],DATEPART(mm,[backup_start_date]);

我能做些什么来获得准确的结果吗？LANDesk 团队不希望我使用旧服务器，我唯一的选择是使用他们计划迁移所有数据的新集群，而我只有 6 个月的数据。我应该问他们这个新集群的使用年数之类的问题吗？等等...

谢谢大家的答案。这是我从 PAL 工具中得到的

我使用 PAL 工具来确定 perfmon 数据，这些是它给出的一些警告
1) 响应时间大于 25 毫秒 2) 空闲时间少于 10% - 磁盘队列在 90% 的时间内至少有 1 个未完成的 I/O 3) …

我们即将启动一个项目，将大型 DWH 迁移到新数据中心的新物理服务器。当前的服务器规范是在 Windows 2012 R2 上运行的 SQL Server Enterprise 2016 SP2。新服务器将是在 Windows 2019 上运行的 MSSQL 2019 Enterprise。

用于当前和新服务器的 SAN 存储是全闪存存储阵列。在当前环境中，除了将数据和日志文件分离到不同的逻辑驱动器之外，不同的数据库（仅数据文件）也被分离到不同的逻辑驱动器上。

• 本地 SSD - TempDb
• 逻辑驱动器 1 - 日志文件
• 逻辑驱动器 2 - 用于暂存数据库的数据文件
• 逻辑驱动器 3 - 面向用户的数据库的数据文件
• 逻辑驱动器 4 - 支持数据库的数据文件（ReportServer、MDS 数据库）

作为服务器迁移的一部分，我正在考虑将所有数据文件合并到一个逻辑驱动器上。

• 本地 SSD - TempDb
• 逻辑驱动器 1 - 日志文件
• 逻辑驱动器 2 - 数据文件

除了数据库文件管理之外，是否有任何性能优势可以将数据文件拆分到不同的逻辑驱动器上？多个逻辑驱动器是否提供更好的 IO，即使最终它是相同的物理存储阵列？

介绍 我从我之前的问题单驱动器与多驱动器中得出了这个问题

从一位非常有帮助的成员RolandoMySQLDBA那里得到非常详细的回答并了解到多驱动器在某些情况下可以提供很大帮助的事实之后。我开始为我的设置寻找多驱动器，与我发现的相比，这只是一点点。

更多信息 我发现了相当大的存储，比如

http://www.newegg.com/Product/Product.aspx?Item=N82E16811152212

虽然有些视频显示此类设备的写入速度甚至达到 GB

• http://www.youtube.com/watch?v=Xjgw2ENYF6w
• http://www.youtube.com/watch?v=PniGlSI900k
• http://www.youtube.com/watch?v=I8ToJ4Blw74

真正的问题 假设有足够的 RAM 来保存索引，MySQL 或其他开源 RDBMS（不是像 Oracle 这样的企业级 RDBMS，因为它在 SAN 上运行很常见）可以轻松地在这些野兽上运行吗？

因为它们包含真正的多驱动器设置，并且有几十个磁头可用。

我相信它不会那么简单，因为如果它有那么简单，那么为什么大多数企业设置使用商品服务器。那么，使用这些极限存储解决方案会面临哪些问题呢？

我有一些表可以从Postgres SQL 中的CLUSTER ON/CLUSTER USING中受益匪浅：

# CLUSTER table USING index_name;
# ANALYZE VERBOSE table;
# CLUSTER VERBOSE;

维护任务会定期运行 CLUSTER VERBOSE 以保持最新状态。但是，在运行 CLUSTER VERBOSE 之前，是否可以运行测试来查看表的碎片化程度？也许是这样的：

# CLUSTER ANALYZE
table 40000 records. 4000 observed clusters, 5000 potential clusters (20% fragmentation)

请注意，我使用 CLUSTER，因此同时访问的数据被“整理”为少量磁盘块。例如，每个页面都有数千个属性。aCLUSTER page_attribute USING page_id;将所有属性放在一起，大大减少了磁盘负载。

有大量文章推荐 SQL Server 的 RAID/LUN/驱动器配置，但大多数让我仍然质疑，因为他们通常说“这取决于”，因此我想提供一些细节并获得一些更直接的建议：

我有一个客户已经在 Cyber​​netics SAN 上安装了 SQL Server，具体细节如下：

• SQL Server 2008 R2 安装在虚拟服务器上

• 贮存：

 o       Cybernetics miSAN-D8/T16 SAN iSCSI storage appliance 
 o       4+1 GbE ports 
 o       8 GB SAN controller cache
 o       USB and eSATA ports
 o       Two miniSAS device
 o       8 drive bays all filled with 600 GB SATA-II 7.2K drives (5.4 TB total) 
 o       All 8 drives set up in RAID 6
 o       Three logical drives:
       1. C (156 GB) – for system …

Run Code Online (Sandbox Code Playgroud)

我正在设计新 SQL Server 安装的要求。我一直在研究磁盘存储，一切似乎都指向使用 RAID。

但是，我发现了这篇文章，它表明 RAID 在今天不再适用。

任何人都可以指出我可以在哪里了解 SQL Server 的最新磁盘存储的方向。

我正在开发一种软​​件解决方案，需要将源自许多 PLC（可编程逻辑控制器，用于控制传送带和机器人等工业机器）的原始数据点存储到 SQL Server 数据库中。我主要关心的是如何正确存储大量原始数字数据。

每个数据点具有以下属性：

1. 日期时间戳
2. 可能是：布尔值、整数、浮点数或字符串
3. 全年每秒可存储一个数据点（每年约 31,536,000 个数据点）

我从中收集数据的每个 PLC 可能有多达 500 个数据点，我想计划支持数千个 PLC。这意味着，我每年至少有 15,768,000,000,000 个数据点（每年 31,536,000 个点 * 500 个点 * 1000 个 plcs）。我目前为每种数据类型（bool、int、float、string）都有一个表。为了减少记录和存储的数量，我为每条记录存储了 4 个数据点 [ID、DateTime、DataGroupID、Value1、Value2、Value3、Value4]。

我实现了这个，它运行良好（使用我最大的表进行约 7200 万条记录的快速查询），尽管它不是很灵活（更改数据类型需要在表之间移动数据，重新分组数据需要表/列更改，等等。）

因此，我想提高灵活性的想法是保留数据类型特定的表，而只是将每个数据点存储为自己的记录。bigint 的最大大小（记录 ID 的数据类型）的一些简短数学表明我有很多可用的 ID。尽管存储要求和查询性能仍然是一个问题。我应该担心使用这种方法的任何事情吗？有更好的选择吗？

我担心的根源是我根本没有体验过巨大的数据库/表，所以虽然我知道几百万条记录很小，但我仍然不知道一个过顶的表会是什么样子。此外，数据的存储是我的软件的基础，因此更新需要大量工作才能实现。