自己认为Oracle-Managed Files不是多么的吸引人而只不过是为了为了方便文件系统的管理而已。OMF是建立在OS文件系统层之上的,所以对于RAW设备来说是不适合的。 更重要的是,当实现管理便利性的同时,失去的却是对I/O优化的干预能力。
以下三个初始化参数决定DB是否使用OMF特性:
DB_CREATE_FILE_DEST
DB_CREATE_ONLINE_LOG_DEST_n
DB_RECOVERY_FILE_DEST
对于第一个参数DB_CREATE_FILE_DEST来说,它决定了SYSTEM和SYSAUX及UNDO和TEMP表空间数据文件的位置。对于除UNDO外前两个文件,默认数据文件为100M,且可自动扩展。对于UNDO,为10M,也可自动扩展。在声明default temporary tablesapce的前提下,当该参数未被指定而TEMP也未显式指定时,系统汇报错。在设置DB_CREATE_FILE_DEST参数时,不要忘记一并设置DB_RECOVERY_FILE_DEST_SIZE参数。
在DB_CREATE_ONLINE_LOG_DEST_n未被设置且建库脚本中也未显式指名controlfile和redolog时,控制文件和重昨日志文件也将存放在DB_RECOVERY_FILE_DEST所确定的目录中。建议multiplex此设置以避免单点故障导致系统不可用。
对于第二个参数DB_CREATE_ONLINE_LOG_DEST_n是系统专为controlfile和redolog指定的目录(最多5个目录)。仅针对于redologfile和controlfile,若指定此参数则系统忽略DB_CREATE_FILE_DEST和DB_RECOVERY_FILE_DEST的目录设置!换句话说,DB_CREATE_ONLINE_LOG_DEST_n是redologfile和controlfile的首选OMF归宿。
对于第三个参数DB_RECOVERY_FILE_DEST就不多说了!主要用于存贮RMAN生成的备份文件及归档日志文件。
值得一提的是,当DB_CREATE_ONLINE_LOG_DEST_n未被指定而DB_CREATE_FILE_DEST 和 DB_RECOVERY_FILE_DEST都被指定时,redologfile会在这两个目录里生成一个redologfile。
对于OMF优化设置的几点考虑:
[@more@]
Tuning Oracle-Managed Files
Several points should be considered when tuning Oracle-managed files.
■ Because Oracle-managed files require the use of a file system, DBAs give up
control over how the data is laid out. Therefore, it is important to correctly
configure the file system.
■ The Oracle-managed file system should be built on top of an LVM that supports
striping. For load balancing and improved throughput, the disks in the
Oracle-managed file system should be striped.
■ Oracle-managed files work best if used on an LVM that supports dynamically
extensible logical volumes. Otherwise, the logical volumes should be configured
as large as possible.
■ Oracle-managed files work best if the file system provides large extensible files.
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/404722/viewspace-920241/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/404722/viewspace-920241/