存储LUN条带和OS上条带有无差别？

不知道两者实现stripe的底层原理一不一样？

就看主机做stripe处理和存储做stripe处理哪个更有效。

这种对比有趣，有人测试过吗？

个人偏好使用第一种方式：1.主机配置更简单；2.主机不需要承受LVM做stripe的负载；3.存储端使用metalun，容量管理方便。

你oracle的日志卷后端连的是什么raid类型，物理磁盘是哪种的？。数据库事务量如果大的话，事务日志写压力会比较大的。

这么惨。。。

你SP的CPU和内存资源使用什么情况? 从两个SP上面分lun给主机看看，这样或许能减轻单个SP的压力。

简单把metalun换成LVM，估计效果不大。主机做了LVM，应该不会另外增加存储上面的IO。所以要想减轻存储的压力，可以用上两个SP试试。

性能到底哪个效果好，个人觉得还是存储端做Strip操作更加好一些。主机上做条带，肯定要分配CPU资源来做运算。存储的话就释放了主机的CPU资源，专心为应用服务。

呵呵，这个真就不清楚了。

我这边是IBM的Power750小型机，CPU和内存资源挺丰富的，但存储却是低端的CX，不知道上面的问题是不是出在存储那边。

8+1 raid5，450G FC

没办法，存储资源比较紧张，没办法做raid10。

之前是有5个LUN分给数据库，tablespace平均分配在每个LUN上，但没考虑日志卷的问题，结果发现5个LUN中其中有一个LUN IO繁忙率能到80%，其余4个LUN的繁忙率只有40%左右。

这才考虑到日志卷的隔离问题，于是就按照上面的方法做了2个lun的meta给log用，结果log卷使用率直接飙到100%，其余几个数据卷只有30%。

这才有帖子里面的疑问。

这台主机由好几个LUN，是分给不同的SP的。一个meta就只能从属于一个SP，没办法。

SP的cpu和内存使用这个要让工程师过来做性能分析才知道，改天就去收集下数据先。

嗯，现有条件下的话，如果要调整raid方式的话，就只能扩容了。

做meta其实已经是分散到别的LUN上了，但还是IO高，看来raid5还是要慎用。

通常做法不是要把日志文件分散到不同的逻辑卷上吗？Raid5写入的性能还是硬伤啊。不过建议你收集下当前的IOPS等性能数据。然后，如果有条件的话再用LVM建一个条带，比较下，也只能是补救办法了。数据库日志以顺序写为主的，不能用Raid5，改成Raid1也会好很多。

也可以考虑把log文件分散到其他lun上，让oracle来控制不要每次都写那个LUN，可能也会有点帮助的。

应该CX存储端也有可以改善的方法，不过CX不是很了解，帮不了你。

CX340，内存4G

你的是CX多少？如果型号太低，估计2种方式做起来，还是那么繁忙。    

连接数一般有多少呢？估计是存储本身的问题了，调不调整lun的分布，应该都差不多呵呵。