存储区域网络 – 我的新Oracle DBA是否具有说服力

存储区域网络 – 我的新Oracle DBA是否具有说服力,第1张

概述当我们为MSSQL盒设置FC LUN时,我们很少需要为它们提供超过8种不同类型的LUN(Quorum,MSDTC,TempDB,Data,Logs,Backup和其他一些). 我们有一个新的Oracle DBA,他给了我一个他想要的第一个新服务器的LUN列表 – 其中有38个!这是一个非常基本的数据库框,只有一个数据库.它们都是相当小的(100GB)LUN,并且它们以LVM类型的方式使用ASM明显 当我们为MSsql盒设置FC LUN时,我们很少需要为它们提供超过8种不同类型的LUN(Quorum,MSDTC,TempDB,Data,Logs,Backup和其他一些).

我们有一个新的Oracle DBA,他给了我一个他想要的第一个新服务器的LUN列表 – 其中有38个!这是一个非常基本的数据库框,只有一个数据库.它们都是相当小的(100GB)LUN,并且它们以LVM类型的方式使用ASM明显地连接在一起.

这是最好的方法,我真的不是Oracle专家,但对我来说似乎过于复杂,你对这件事有什么想法和经验?

我是Oracle DBA.您的新DBA表现得像很多Oracle DBA和工程.

>没有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非常复杂.

总结

以上是内存溢出为你收集整理的存储区域网络 – 我的新Oracle DBA是否具有说服力全部内容,希望文章能够帮你解决存储区域网络 – 我的新Oracle DBA是否具有说服力所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/1167459.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-06-01
下一篇 2022-06-01

发表评论

登录后才能评论

评论列表(0条)

保存