我有一个Sun M4000连接到EMC CX4-120arrays与写入重型数据库。 写入峰值在1200 IO / s和12MB / s左右。
根据EMC的说法，我正在使EMCarrays上的写caching饱和。
我认为最简单的解决scheme是将重做日志移到基于DRAM的SSD上。 这将使EMCarrays上的负载减less一半，应用程序不会看到日志缓冲区等待。 是的，DBWR可能会成为一个瓶颈，但应用程序不会等待它（就像他们做重做提交一样！）
我目前正在循环大约4个4GB的重做日志，所以即使是20GB左右的SSD也会有很大的不同。 由于这是短期存储并且不断被覆盖，基于闪存的SSD可能不是一个好主意。
M4000没有任何额外的驱动器，所以一个PCI-E卡将是完美的，我可以去外部或移动启动卷到EMC和释放本地驱动器。
Sun出售Flash Accelerator F20 PCIe卡，但似乎是一些SATA磁盘caching，而不是DRAM SSD解决scheme。 细节是粗略的，它没有列出M4000支持，我厌倦了打击孙的电话树寻找人的帮助。 🙁
其他人是否同意DRAM SSD是一条路？ 任何硬件build议？
更新除了在下面的评论中的信息，我尝试了“commit_write”的各种设置，并没有什么差异。
首先 – 我猜你阵中有很less的磁盘。 1200个磁盘可以很容易地支持12个旋转磁盘（每个磁盘100 IOPS是非常合理的）。 如果caching无法处理，则意味着1200 IOPS的持续写入速度远远超过您的磁盘所能支持的速度。
无论如何，重做日志的SSD不太可能帮助。 首先，你的会话主要在COMMIT语句上等待？ 检查statspack / AWR中的顶级等待事件来validation。 我猜想你的I / O的95％根本就不是重做日志。 例如，对具有5个索引的表的单行插入可以执行1个I / O来读取表格块（其具有用于该行的空间），读取5个索引块（更新它们），写入1个数据块，1次撤消块和5个索引块（或更多，如果非叶块被更新）和1个重做块。 因此，检查statspack并查看您的等待事件，您可能会等待大量的数据/索引的READ和WRITE。 等待读操作会降低INSERT的速度，写操作会使读取速度更慢 – 这是相同的磁盘（顺便说一下，你真的需要所有的索引吗？删除那些不是必须的将会加速插入）。
另一个要检查的是RAID定义 – 是RAID1（镜像 – 每个写入是两个写入）还是RAID 5（每个写入2个读取和两个写入用于校验和计算）。 RAID 5在写入密集型负载方面速度较慢。
顺便说一句 – 如果磁盘不能处理写入负载，DBWR将是一个瓶颈。 你的SGA将满脏块，你不会有空间去读新的块（如索引块需要处理/更新），直到DBWR可以写一些脏块到磁盘。 再次检查statspack / awr report / addm来诊断瓶颈，通常是根据前5个等待事件。
相比于块I / O，DD是没有什么。
对于一些其他的看法，anandtech.com做了一个激烈的testing（与MS SQL服务器授予）与SAS旋转与SSD，以各种组合，和Solaris世界有ZFS与SSD组成各部分（日志，caching等）。
但是，是的，如果RAID 5与RAID 10是相同的（用于写入），那么你做错了什么。 使用线性写入，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 / Ofunction类似。 它基本上只是一个PCIe连接闪存SSD。 由于写入工作量很大，您需要担心维护足够的空闲块（通过基于驱动器的某种垃圾收集），因此您不会在SSD上的擦除/编程周期结束时成为瓶颈，在基于闪存的SSD上可用的写周期有限。 这绝对是快，但可能不是这个工作最好的工具包。