发新话题
打印

讨论多os共享lun,以及文件系统,数据库方面的问题!

说来说去,都是一样的
敝人博客
《大话存储》预订链接:http://www.china-pub.com/301645

TOP

> oracle好像从来没有推荐RAC使用ocfs2,ocfs的问题还是不少的

有的人说“没有”,不知道是从事实还是来自其他看法。

另外,就所知道的一些相关内容以供各位参考。

OCFS 的问题主要表现在性能低,这是事实。所以,不能够被用户认可。当然,其可靠性也被人质疑。

OCFS2 也有个 OCFS 的前缀,但不是 OCFS 简单的 bugs 更新版本,可以认为是针对性能问题在缓存以及结构上的重写。

OCFS2 目前的主要问题在可靠性方面,但还不至于说 OCFS2 在多节点集群的生产环境下不可用。当然,对于心里有着几打 checklist 的 SA/DBA 来说,这是很敏感的而且非常受关注的。OCFS2 还需要在可靠性上加强。然而,衡量一个软件应用方案,可靠性并非只是一个因素。题外话,在应用方案设计与实施上,同样可用的的方案里,相对最可靠的常被采用是事实。在一些论坛上,GFS 被推荐可以作为生产环境。有个省级的集成开发商测试后却不放心,找到 RH 北京几个月得不到正确支持。个人认为,这不在于 RH 总部的支持响应是否及时,更重要的是在于方案设计和实施者对产品及其技术特性的掌握和理解的程度。

OCFS2 在对数据库系统的存储管理方面有具有相对的优势(最好管理的是 ASM),其实,这也是作为 FS 本身具来的特性。

OCFS2 的性能还可以,而且相比在“裸设备”上建立数据库系统的存储,并没有数量级的差距,无论是实际测试还是理论上。

在多节点集群时,OCFS2 被 Oracle 推荐也是事实。

TOP

关于ocfs2的情况,请你订阅一下ocfs2的maillist

TOP

OCFS2 目前的主要问题在可靠性方面,但还不至于说 OCFS2 在多节点集群的生产环境下不可用。当然,对于心里有着几打 checklist 的 SA/DBA 来说,这是很敏感的而且非常受关注的。OCFS2 还需要在可靠性上加强。然而,衡量一个软件应用方案,可靠性并非只是一个因素。
-----------------------------------------------------------------------------------------------------
这是数据库,一个企业核心的地方,你说可靠性意味着什么

TOP

> 关于ocfs2的情况,请你订阅一下ocfs2的maillist

呵呵,看 OSSs 的 mail lists 是需要胆量的。开个玩笑

常看,只是没有看过 OCFS/OCFS2 的;花了些时间,翻阅了 OCFS2 的几个 mail lists。

TOP

> 这是数据库,一个企业核心的地方,你说可靠性意味着什么

同意,这是 Oracle 数据库。可靠性在企业核心业务的应用领域应该是决定性因素。此外,“企业核心”不能够将宝押在某一运行“部件”的可靠性上。只要能够使用,就要平衡,这也是应用方案设计费时最多的地方。

题外话,可靠性对于软件开发/应用是一个技术性的描述词汇,个人尚不知道有相关的检验标准/指标来衡量这一点(如有知道,请示下)。软件 bugs 也有等级,如果 Oracle 放出的 OSS 会咬人,市场会检验其结果,但这并不妨碍 OCFS2 被推荐应用。软件不是(近乎)完美的世界。

TOP

引用:
原帖由 冬瓜头 于 2007-2-12 08:31 发表


感谢这位仁兄的数据库方面的解释,受教了,不过有一句话我不同意:
“如果使用裸设备,oracle自己IO,绕过操作系统”
oracle使用裸设备也绕过os么?oracle有自己的磁盘控制器驱动?和os是两套驱动程序?如 ...
这句话说的不太严谨,我的确不知道OS是否有系统调用可以不buffer dirty data,而是直接write。
建议你去了解一下ORACLE的SGA(内存区域),这块内存区域当中有一个子区域叫buffer cache,它是做什么的呢?
buffer cache缓存脏块,即dirty block,而不是每次commit的时候就往磁盘上面去write,这样做和大多数buffer的功能是一样的,目的就是为了最大限度的利用磁盘的IO bandwith。
buffer cache还要cache从磁盘上读取出来的block,目的为了提高hit ratio。
所以说,它不需要再从OS里面提供的buffer或cache去绕一圈。

raw device本身是character device,其IO Unit为byte,我们知道一个硬盘的IO Unit是sector,也就是512 bytes。你说用了raw device,硬盘就能改成1 byte per IO request了吗?也不是。那么就肯定要攒到了512bytes才write一次吧?(猜测)那么这样的buffer是谁来提供的呢?我认为是oracle提供的。

但是what the hell the objective of using raw device?使用raw device或者CFS只是为了绕开native file system的open lock,spin(这些机制oracle自己提供,而且功能完备)让更多的hosts去修改同一个数据文件(我在这里的理解是,它降低了的对数据的修改粒度,从native file system中的文件尺度,下降到了byte的尺度)。附带好处是可以绕开OS的buffer与cache的机制。而没有绕开device driver,单实例的oracle数据库并没有一味的去强调使用raw device吧?只有在rac环境中才这样。
站在VFS这堵墙后面,我们有了raw device和block device之分,跨过这堵墙,我们看到的basic unit是sector。

TOP

“buffer cache还要cache从磁盘上读取出来的block,目的为了提高hit ratio。
所以说,它不需要再从OS里面提供的buffer或cache去绕一圈。”
这并不能说明oracle就绕开了os的device driver把?

“raw device本身是character device,其IO Unit为byte,我们知道一个硬盘的IO Unit是sector,也就是512 bytes。你说用了raw device,硬盘就能改成1 byte per IO request了吗?也不是。那么就肯定要攒到了512bytes才write一次吧?”
磁盘设备当然是块设备,tty等字符终端,才是字符设备,而且必须是异步串口才是字符,同步串口是群同步,一次多个字符,算是frame设备了。


oracle当然可以自己管理磁盘数据,但是他不能脱离os的device driver,底层还是依靠os。
敝人博客
《大话存储》预订链接:http://www.china-pub.com/301645

TOP

我对存储不熟悉,班门弄斧了。
不过我没有否认它脱离os,从来不能脱离os,关键是避免了os的锁机制,这样做带来了一些好的副作用。
我倒是想向冬瓜多了解一下存储方面的知识。

TOP

呵呵,多交流,互通有无,大家共同进步
敝人博客
《大话存储》预订链接:http://www.china-pub.com/301645

TOP

发新话题