ORACLE对读写性能都非常敏感，因此对不同ORACLE文件保存的RAID类型是有推荐滴，小虾以前在文档《Overview of I/O performance and RAID in an RDBMS Environment》中看到过一些推荐值，楼主可以参考一下：

OS卷：推荐RAID 1

重做日志文件（Redo log files）：推荐RAID 1和RAID 0+1

数据文件：如果I/O读使用率低于90%，推荐RAID 0+1，如果I/O读使用率高于90%，RAID 5也可以。

归档日志文件（Archive log files）：推荐RAID 0+1，安装在RAID 5性能会差很多。

顺便问一下楼主使用的存储类型是什么？如果是VNX那么新版VNX开始支持混合RAID级别了，一个存储池中支持多种RAID类型，扩展起来更方便了。

    客户那边用的 DMX-4

    是因为看到一些最简单DML都会由 logfile sync的情况而语句本身不可能再进一步优化了于是想到磁盘的问题。问了那个管理员他不敢确定，听说是生产卷与BCV都是RAID 5 只是 XP+YD 的区别。如果要重新把生产卷弄成RAID 1会很麻烦吗？

如果你的ORACLE都建在RAID 5上，我感觉性能是会受到一些影响。如果你们买了ORACLE的服务，我建议你结合目前的版本情况咨询一下厂商，具体版本会有具体配置最佳实践。然后再规划一下调整计划，总之生产环境动数据库是要谨慎点滴！

DMX设备的迁移不熟悉，欢迎后面大虾介绍一下这种情况的迁移操作。

      面对一脸无辜当地的管理员我能说什么呢？要不是他啥都来问我，我一直还被蒙在鼓里呢。估计当时PM原来没想到负载突然来的这么快，做完了啪啪屁股走人了。现在由于大量类似于 "insert into A values (bbbb)"和“update x  set y=z where .....” 这样的语句并发执行弄得 有些时候会瞬时出现 “log file sync”这样的event。

       但是从主机层面上表现为CPU在高并发时候也突然蹿高，当地竟然意外增加CPU就能解决问题 。我这不是为他们着急嘛，我就和那哥们说做好准备随时跑路吧。

哎 不问还好  牵扯到很多人很多事 水深啊

“update x  set y=z where”，更新个数据要查索引的啊，看样子还不是更新一点点，字段上没索引就更加杯具了，整表扫。

理解，有时候非技术上问题变成主要障碍。话说让你那位兄弟来论坛问问解决方案啊，有备无患，万一出了事情可以有对策。

已经让那边请求EMC与Oracle工程师上门诊断了先看看结果如何。

如果真的是送所想的那样，那就有事情做了。

liulei还是热心肠呐，LUN就是一个傻瓜设备，主机上识别以后纳入LVM里面，就是LVM的事情了。所以，一个VG里有raid5和raid10的LUN从技术上看是没有问题的，不同层面的事情。

但是具体到应用的话，就真应该考虑了，新分配LUN的时候没注意已经分配LUN的raid级别吗？这种事儿怎么都能出？

     谢谢关心.

    我只是觉得客户把数据库交给了我,.我就有责任把东西给管好.数据丢了你得给人家找回来吧,总觉得慢你得给找出问题来吧。存储与主机都与数据库运维息息相关不可不察也，我这边的确有人以为运维只是与客户与厂家之间发邮件打电话那么简单，我认为只要是自己的地盘最好都要懂。所以我发现干了这么多年自己神马都不懂。

谢谢楼上的兄弟

估计领导们都嫌弃偶多管闲事、没事找事。

好筒子，公司里要都是兄弟这样的人，何愁运维不稳定！

，存储已经创建卷了，映射给主机能请教下方法吗