将Oracle重做日志放在DRAM SSD上以获取大量写入数据库？

我将Sun M4000连接到具有大量写入数据的EMC CX4-120阵列。以大约1200 IO / s和12MB / s的速度写入峰值。

根据EMC的说法，我使EMC阵列上的写缓存达到饱和。

我认为最简单的解决方案是将重做日志移至基于DRAM的SSD。这样可以将EMC阵列上的负载减少一半，并且应用程序不会看到日志缓冲区等待。是的，DBWR可能会成为瓶颈，但是应用程序不会等待它（就像在重做提交时一样！）

我目前循环浏览约4个4GB的重做日志，因此，即使20GB左右的SSD也会有很大的不同。由于这是短期存储并且经常被覆盖，因此基于闪存的SSD可能不是一个好主意。

M4000没有很多额外的驱动器，因此PCI-E卡非常完美，我可以将其放入外部或将启动卷移至EMC并释放本地驱动器。

Sun销售Flash Accelerator F20 PCIe卡，但这似乎是某些SATA磁盘的缓存，而不是DRAM SSD解决方案。详细信息是粗略的，它没有列出M4000受支持的内容，而且我厌倦了与Sun的电话树战斗，寻求人为帮助。:(

其他人是否同意DRAM SSD是必经之路？有硬件建议吗？

更新 除了下面注释中的信息外，我还尝试了“ commit_write”的各种设置，但并没有什么不同。

首先-我猜您阵列中的磁盘很少。1200IOPS可以轻松支持12个旋转磁盘（每个磁盘100 IOPS是非常合理的）。如果缓存无法处理，则意味着1200 IOPS的持续写入速率远远超过磁盘可以支持的速率。

无论如何，用于重做日志的SSD可能无济于事。首先，您的会话是否主要在COMMIT语句上等待？检查statspack / AWR中最重要的等待事件以进行验证。我想您的I / O的约95％根本没有重做日志。例如，对具有5个索引的表进行单行插入可以执行1个I / O来读取一个表块（该行具有空间），读取5个索引块（以对其进行更新），写入1个数据块，1个撤消操作块和5个索引块（如果更新了非叶子块，则为更多）和1个重做块。因此，检查statspack并查看您的等待事件，您可能正在等待很多READ和WRITE来获取数据/索引。等待读取会降低INSERT的速度，而WRITE活动会使READS变得更慢-这是相同的磁盘（顺便说一句，您真的需要所有索引吗？删除那些不必要的索引会加速插入）。

要检查的另一件事是RAID定义-是RAID1（镜像-每个写入是两个写入）还是RAID 5（每个写入是2个读取，两个写入用于校验和计算）。RAID 5在写入密集型负载中的速度要慢得多。

顺便说一句-如果磁盘无法处理写入负载，则DBWR将成为瓶颈。您的SGA将充满脏块，并且您将没有空间读取新块（例如需要处理/更新的索引块），直到DBWR可以将一些脏块写入磁盘为止。再次检查statspack / awr报告/ addm来诊断瓶颈，通常基于前5个等待事件。

与块I / O相比，dd没什么。

对于其他观点，请查看一下，anandtech.com通过SAS旋转与SSD进行了多种组合的详尽测试（授予MS SQL服务器），并且Solaris世界中ZFS和SSD组成了各个部分（日志，缓存等）。 ）。

但是，是的，如果RAID 5与RAID 10相同（写操作），则说明您做错了。使用线性写入时，hack RAID 5可能会更快（即它可以在内存中执行奇偶校验，然后一次写入条带和奇偶校验），但是对于随机的小块（4-8k），您会由于更新条带而被杀死（因为突击行动10的速度应该快2倍以上，如果没有，那是错误的。

在花钱购买硬件之前，您需要深入研究。

我看到了有关使用“ forcedirectio”选项安装UFS分区并将Oracle参数“ filesystemio_options”设置为“ setall”的帖子。

我尝试了一下，发现Oracle写入提高了4-5倍！是的

关键症状是吞吐量低但磁盘上的响应时间好。这似乎对某些人有帮助，但对其他人没有帮助。它确实为我完成了工作。

我可能会考虑将SSD用于新服务器，但是此服务器现在运行良好。

罗伯特

如果此盒只是运行Linux的x86 / 64盒，我会很乐意推荐其中一种FusionIO PCIe驱动器卡-它们的速度惊人，并且不会像SSD那样大量写入而“死”。不幸的是，Sparc或Solaris不支持它们，但是您可能希望与他们联系以讨论此问题。

F20e PCIe卡在功能上类似于Fusion I / O。它基本上只是一个PCIe连接的Flash SSD。面对繁重的写工作，您将需要担心是否需要维护足够的可用块（通过某种基于驱动器的垃圾收集），这样就不会使SSD的擦除/程序周期成为瓶颈，并且基于闪存的SSD上可用的有限写入周期。它肯定很快，但可能不是完成此工作的最佳工具。