oracle dbra,资源供给：IO子系统之二

案例描述：

某运营商的dbra备份系统，备份构建在vxvm和vxfs文件系统之上，串行更新的速度基本理想。由于无法达到更新目标，通过增加并行来增加IO写速度，结果并行度加大之后，iops快速下跌，io子系统无法提供并发能力。由于对于vxvm不是很了解，又没有厂商支持，测试了vxvm依赖的磁盘层次，发现磁盘层次可以提供很好的并行度扩充。简单的构建了一个hp-ux缺省的vxfs，也可以很好的进行并行扩展，现在可以判断是vxvm的并行能力出现了问题，估计是vxvm队列的问题，由于缺乏支持，无法对于vxvm作出优化调整。在客户的支持下，放弃了vxvm之后，建立在hp-ux的lvm之上，具有很好的并行度扩充，达到了优化目标。

卷管理器和文件系统是方便用户使用的磁盘基本管理单元，在带来了方便性的同时也可能会带来些性能方面的问题。

文件系统带来的主要障碍：

(1)、日志卷会对于更新带来比较大的压力。

文件系统的日志设备对于频繁更新的文件系统可能会带来一定的压力，这个时候可以采用独立日志设备来避免日志设备对于文件系统的IO影响。

(2)、元数据过大，会使文件系统的搜索延迟变强，特别是在寻找自由空间的时候。元数据过大主要表现在文件系统中的文件过多，达到几千几万的范畴。从这点考虑必须考虑Oracle数据库的数据文件不要和Oracle安装软件处于相同的文件系统。同样太大的文件会需要更多的inode，自然也就需要更高的元数据搜索成本。

(3)、文件系统碎片，文件系统碎片导致的问题事实上就是元数据过大，使其寻求自由空间的成本变高。

一般现代文件系统采用Block,Extent的方式来管理文件，主要是为了提高性能。而Extent的全局管理则一般使用位图。大家只要简单考虑下Oracle的表空间管理，只要把文件系统的空间管理类似于Oracle表空间管理即可。在位图模式下，Extent的大小并不会带来多大的性能问题，但是为了支持Oracle全表扫描，必须要使文件系统的Extent大于Oracle全表扫描的范畴，一般为1M。当系统中存在大量的小空闲Extent的时候就会存在比较大的性能问题，在搜索自由空间的成本会大幅度增加，这个时候可能需要对于文件系统进行碎片整理。

一般来说，建议文件系统的Block Size=Oracle Block Size, Oracle extent size:=File system extent size * N，File system Exetnt Size至少要1M大小，并且是1M的倍数。

(4)、文件锁，相对于lv使其并发能力会降低。

文件操作和lv操作不同，一般需要增加文件锁，从而使其并发能力下降。不过现代文件系统都开始进行不需要文件锁的实践，增加了并行IO，降低或者彻底消除了文件锁的需求。

文件系统的Buffer Cache:

文件系统的Buffer Cache在两个层面会带来收益：

(1)、读操作

(2)、预读缓存

在文件系统的Buffer带来好处的同时可能会给Oracle带来负面的影响，主要因素在于文件系统Buffer和Oracle SGA Buffer共享使用物理内存。当文件系统需要更多的内存而操作系统无法提供的时候将从Oracle SGA Buffer偷取内存，把Oracle SGA Buffer交换到磁盘上，从而导致Oracle性能大幅度下降。

为了使文件系统缓存不影响到Oracle SGA Buffer，必须保证文件系统缓存和Oracle SGA Buffer的共用内存不超过操作系统内存memory pin部分。一般而言，由于Oracle数据库具有更加重要的价值，一般来说对于Oracle数据库来说不建议缓存文件，或者仅仅分配很小的缓存空间。

比如：我们设置文件系统缓存最大不超过5%的内存，并且使系统有限交换文件页，从而保留SGA Buffer在物理内存之中。具体如何设置，参考各自操作系统和文件系统。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/92650/viewspace-776769/，如需转载，请注明出处，否则将追究法律责任。