SQL Server 日志传送：RESTORE LOG 期间最热的 IO 在哪里：To db or to log？

Question

使用 SQL Server 2008。

我已经使用 SQL 日志传送多年了。效果很好。

使用新的备用服务器（日志传送的接收者），我看到日志还原性能非常差，我想知道：在 MDF 和 LDF 中，在日志还原期间，一个命中率是否比另一个特别高？

背景：使用专用硬件，我对这方面没有问题。（公平地说，我一直对目标上的 ldf 大小不满意......但是你打算用恢复状态的数据库做什么？）

我现在正在试验云服务器和块存储。到目前为止......我对块存储的 IOPS 相当失望。日志恢复操作真的很慢（我们的主数据库服务器每 4 分钟输出一个日志文件，在目标上恢复每个文件需要 2 分钟以上！）。

所以我在争论是否：

• 获得更快的块存储设备（mucho $$）---但这仅对 LDF 或 MDF 才有意义...如果我必须同时做这两个，那就太贵了（所以我的问题）
• 找出云中 SQL Server 的另一个解决方案
• 忘记 SQL Server 的云，因为 iops 不存在......

进一步挖掘发现：https : //serverfault.com/questions/261631/temporary-io-boost-for-an-mssql-server

这表明热 IO 将是 LDF ......这将是优化的地方......（尽管“恢复日志”不是该线程的明确议程）。

我们是否同意提高 LDF 磁盘的 IOPS 应该提高 RESTORE LOG 性能？

谢谢！

Answer 1

数据在：

提高 LDF 存储的速度可以显着缩短日志恢复时间。

谢谢大家的意见！

我做了什么：

我正在使用 Rackspace 云服务器。不是他们的“SQL Server”实例，只是简单的 jane Win 2008 图像，我将 SQL 2008 加载到其中。对于存储，我使用 Rackspace 块存储。我还使用 EBS（Amazon 块存储）评估了 Amazon EC2。

我攻击的核心问题：

1) 在云服务器上为 300+ GB 的数据库运行 SQL Server 是否可行？

2) 获得基于 Rackspace SSD 的块存储的额外支出是否有好处？（它相当昂贵）。

我使用的方法：

我做了两种测试：

i) SQL IO 测试工具，用于测量块存储的磁盘性能，并与专用硬件进行比较（“在金属上”和在虚拟机中）

ii) 大型数据库的实际恢复，以及从生产数据库自动传送日志。

答案：

a) Rackspace 常规块存储比 Amazon AWS (EBS) 快得多。很多。

b) 根据我的测量和经验，我不会将生产 SQL Server 数据库放到 Amazon EBS 上。有太多的“暂停”和其他糟糕的性能问题。请注意，SQL Server 将在 EC2 w EBS 上运行——很多人都这样做——只是根据我的测量，会有 IO 延迟（很多）。这将特别影响 RESTORE LOG 操作和所有写入密集型操作（读取可以缓存......但 LDF 写入不会缓存......）。

c) 具有常规块存储的 Rackspace 云绝对可以用于 SQL Server。它并不令人兴奋，但它非常适合读取，并且可以写入。

d) Rackspace SSD 块存储对日志恢复操作产生了巨大的影响，并且（我在这里推断），SQL 服务器的任何写入密集型使用都将得到很大的提升。

所以坏消息是：当您推动 500GB 的数据库时，您无法以 300 美元/月的价格获得 15 万美元的 SAN 的性能。

好消息是：您可以获得非常不错的性能，在专用硬件上的虚拟机上与 RAID5 匹敌或胜过 RAID5，每月约 480 美元

数据

这是日志还原操作的数据，首先显示日志还原操作在较慢系统上的持续时间，然后在较快系统上，然后是差异。此日志还原在两个系统上每 10 分钟发生一次。