我有一台 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”的各种设置，但没有什么区别。
答案1
首先 - 我猜你的阵列中磁盘很少。12 个旋转磁盘可以轻松支持 1200IOPS（每个磁盘 100 IOPS 非常合理）。如果缓存无法处理，则意味着你的持续写入速率 1200 IOPS 远远超过你的磁盘可以支持的速率。
无论如何，重做日志的 SSD 不太可能有帮助。首先，您的会话是否主要等待 COMMIT 语句？检查 statspack/AWR 中的顶级等待事件以进行验证。我猜您的 I/O 中 ~95% 根本不是重做日志。例如，向具有 5 个索引的表插入一行可以执行 1 次 I/O 来读取表块（有空间容纳该行），读取 5 个索引块（以更新它们），写入 1 个数据块、1 个撤消块和 5 个索引块（或更多，如果非叶块被更新）和 1 个重做块。因此，检查 statspack 并查看您的等待事件，您可能正在等待大量数据/索引的读取和写入。等待读取会减慢插入速度，而写入活动会使读取速度更慢 - 它是相同的磁盘（顺便说一句 - 您真的需要所有索引吗？删除那些不是必须的索引将加速插入）。
另一件需要检查的事情是 RAID 定义 - 是 RAID1（镜像 - 每次写入都是两次写入）还是 RAID 5（每次写入都是两次读取和两次写入以进行校验和计算）。RAID 5 在写入密集型负载下速度要慢得多。
顺便说一句 - 如果磁盘无法处理写入负载，DBWR 将成为瓶颈。您的 SGA 将充满脏块，并且您将没有剩余空间来读取新块（例如需要处理/更新的索引块），直到 DBWR 可以将一些脏块写入磁盘。再次检查 statspack / awr report /addm 以诊断瓶颈是什么，通常基于前 5 个等待事件。
答案2
与块 i/o 相比，dd 不算什么。
对于其他一些观点，请查看，anandtech.com 进行了详尽的测试（使用 MS SQL 服务器），其中 SAS 旋转与 SSD 进行了各种组合，并且 Solaris 世界有 ZFS 和 SSD 组成各种部分（日志、缓存等）。
但是，是的，如果 RAID 5 与 RAID 10 相同（对于写入而言），那么您做错了。对于线性写入，RAID 5 可能会更快（即它可以在内存中进行奇偶校验，然后一次性写入条带和奇偶校验），但是对于随机小块（4-8k），您会因更新条带而死（正如其他人所指出的那样），raid 10 应该快 2 倍以上，如果不是，那就出了问题。
在花钱购买硬件之前，您需要进行更深入的挖掘。
答案3
我看到一篇关于使用“forcedirectio”选项挂载 UFS 分区并将 Oracle 参数“filesystemio_options”设置为“setall”的帖子。
我试了一下，发现 Oracle 写入速度提高了 4-5 倍！太棒了！
主要症状是吞吐量低，但磁盘响应时间良好。这似乎对某些人有帮助，但对其他人则没有帮助。对我来说，它确实起了作用。
我可能会考虑为新服务器配备 SSD，但现在这台服务器运行良好。
罗伯特
答案4
F20e PCIe 卡的功能与 Fusion I/O 类似。它基本上只是一个 PCIe 连接的闪存 SSD。在写入繁重的工作负载下，您需要担心维护足够的可用块（通过某种基于驱动器的垃圾收集），这样您就不会最终导致 SSD 上的擦除/编程周期成为瓶颈，以及基于闪存的 SSD 上可用的有限写入周期。它肯定很快，但可能不是这项工作的最佳套件。