OMF

自己认为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/