>没有oracle不需要38个LUN.我已经在大量的lun上传播了数据文件,但这些文件在非常活跃和非常大的系统上. LUN不一定映射到新的RAID组吗？所以在单独的文件上有文件不需要传播任何东西(我不是这方面的专家).
>所有这种文件条带化将为DBA做更多的工作.这增加了他对团队的重要性.很多Oracle DBA都试图让自己看起来更加重要,并且不断设计工作.
>将数据分离到不同的raid组/ luns不是特定于oracle的.它基于用法.为了正确地分发文件,您的DBA需要了解应用程序以了解正在访问的内容(顺便说一句,从数据中分离索引不会提高性能,因为访问是串行的……).他知道申请吗？他是否查看过数据库以查看正在访问的对象？需要分散什么？批量写入和读取需要隔离什么.

这听起来像一个中小型数据库.什么是活动水平？他可能不知道.

通常在较小的数据库上,您不需要在文件系统级别做很多事情来提高性能. 95％是sql,开发人员在循环中运行太多的sql语句.

编辑(多年以后！)：

我花了一些时间与SAN工程师交谈,并且自从发布此内容以来,我已经对SAN和LUN进行了一些改进.首先关闭LUN是“合乎逻辑的”.它没有必要映射到单独的RAID组,磁盘等……这是由SAN工程师设置的,DBA不会看到它.在SAN中分离出大多数人都意识到的IO还有很多.

我正在研究一个活动水平非常高的非常大的系统.我们有数百个LUN,RAID组等…我们在各处传播文件.我们与SAN工程师合作配置LUN,以确保它们分布到SAN的不同部分.我们真的无法了解LUN如何从操作系统级别进行映射.新文件系统并不意味着我们将数据映射到SAN上的新位置.

关于条带化ASM的惠普论文.使用SAN时,这完全没有意义.条带化,镜像,RAID等……都是在表面下完成的.您不会在应用程序或数据库级别看到它.在SAN中配置Oracle ASM以进行“条带化”是没有意义的,因为您只是在使用RAID 5配置的逻辑卷上进行分离(绝大多数是由于控制成本.SAN是数百万美元的投资).您将看到文件系统.这些不一定映射到SAN中的不同磁盘或不同位置.

IBM显然有一项新功能,可让SAN根据活动决定在何处写入磁盘.我的观点是优化SAN的人是专家.你需要和他们一起工作. DBA或应用程序开发人员无法查看是否有任何内容正在展开.

从我所看到的,大多数商店都没有很好的SAN工程师.它往往是初级人员的工作.大多数好人往往是顾问.所以很多时候你只是使用制造商的默认设置.重申添加更多LUN可能不会传播任何数据,除非您有SAN工程师在表面下为您配置它.最重要的是,您可以拥有1个LUN并将其展开给您.除非你有一个优秀的SAN工程师,所有这些东西都没有意义.很明显,有问题的DBA对SANs知之甚少,甚至不知道他什么都不知道.

99.9％的时间标准配置都很好.除非您有特定的IO瓶颈,否则这是不必要的.如果这样做,那么您需要与SA和SAN工程师一起确定问题所在.很多时候它与SAN的布局没有任何关系.同样,DBA和开发人员将无法查看下面发生的事情,更不用说了解这一点的知识. SAN非常复杂.