1、1利用 OMF 简化数据文件管理在没有 OMF(托管文件)之前，数据库管理员在创建数据文件的时候，需要关心两个问题。一是该为这个数据文件取一个什么样的名字，二是需要考虑新创建的数据文件会不会与已经存在的数据文件重复。 在没有 OMF(托管文件)之前，数据库管理员在创建数据文件的时候，需要关心两个问题。一是该为这个数据文件取一个什么样的名字，二是需要考虑新创建的数据文件会不会与已经存在的数据文件重复。当企业的数据库比较大，有数百个数据文件时，这项工作就会变得非常的困难。为此需要采用一种机制，对数据文件进行自动管理。在 Oracle 数据库中就提供了 OMF 托管文件这种机制。 使用过程中的相关配
2、置 OMF 托管文件机制相当于是一个批处理。当用户在建立数据文件的时候，只要输入一个命令，不需要带名字、存储位置等参数，系统就会自动根据一定的规则来创建数据文件。故在使用这个托管文件功能之前，管理员需要先在数据库中建立好相关的规则。虽然系统有时候也会采用默认的配置，但是不建议这么做。对于一个复杂的数据库系统来说，根据企业的实际情况，预先创建好数据文件的体系，是一个很好的习惯。系统的默认设置往往针对的是中小型的应用，无法满足大型数据库的要2求。所以管理员需要根据实际情况来配置相关的规则。具体的来说，主要涉及到以下几个参数。 一是 DB_CREATE_FILE_DEST 参数。顾名思义，这个参数主
3、要用来指定数据文件默认的存储位置。设置好这个参数之后，管理员在创建数据文件时就不需要再输入具体的文件位置。这里需要注意的是，这个地址还跟临时文件、重做日志文件、控制文件等等相关。 二是 DB_RECOVERY_FILE_DEST 参数。这个参数主要用来定义重做日志、控制文件、RMAN 备份文件、归档日志和闪回日志的默认位置。当管理员设置了这个参数之后，系统将会重写其默认设置。 三是 DB_CREATE_ONLINE_LOG_DEST_N 参数。这个参数也是用来定义重做日志文件和控制文件的默认位置。这里也许有人会问，如果这个参数与前面的参数定义的位置不同，那该如何处理呢?这里就涉及到一个优先级的
4、问题。通常情况下，如果设置了这个参数，那么前面两个参数的设置就会被覆盖掉。最终系统使用的是这个参数所定义的位置。也许有人会问，这个参数后面为什么会带一个字符 N 呢?其实这主要是为了建立副本的需要。 使用 OMF 来创建数据文件 以上相关的规则配置完毕之后，就可以使用 OMF 托管文件功能来创建数据文件。只需要运行 ALTERTablespaceADDDATAFILE 命令即可。注意在这个命令中，没有指定所需要创建的数据文件的路径与名字。这些都3是系统根据预先定义的规则来自动补充的。在使用这个命令的时候，还需要注意以下几点内容。 一是如何来实现归档日志与控制文件的多个副本?在手工创建归档日志文
5、件和控制文件的时候，我们总会在不同的位置创建多个相同名字的归档日志文件或者控制文件的副本。如此的话，当某个归档日志文件或者控制文件出现问题，还可以通过副本来弥补。通过 OMF 托管文件来自动创建数据文件时，该如何实现这个功能呢?其实实现的方法也很简单。只需要在设置 DB_CREATE_ONLINE_LOG_DEST_N 这个参数的时候，多建几个，系统就会自动创建相关文件的副本。这就是最后一个字符 N 的作用。二是如果创建表空间，则数据文件该如何处理?在没有 OMF 托管文件功能之前，创建表空间与创建数据文件是两个独立的事项。也就是说，创建表空间之后，管理员还需要根据实际情况来手工创建数据文件。
6、不过在有了 OMF 托管文件功能之后，这种情况发生了根本性的变化。换句话说，只需要使用 CreateTablespace 命令，而完全不需要制定涉及的实际数据文件，系统会自动创建相关的数据文件。如果有指定多个镜像位置的话，还会自动创建重做日志文件或者控制文件的副本。 OMF 托管文件的局限性以及应对措施 虽然 OMF 文件可以提高创建数据文件的自动化能力，如自动命名、自动判断重名问题等等。但是其在具体的使用过程中，也具有一定的局4限性。总的来说，OMF 托管文件其主要的优势在于你不用担心会创建已经存在的文件(包括数据文件、重做日志文件、控制文件等等)。而其主要的局限在与，通过 OMF 托管文件
7、创建的文件，没有容量管理和平衡 I/O方面的优点。为此对后续系统的性能等等方面会有一定的影响。在实际工作中，OMF 托管文件往往不是单独使用，而是结合 Oracle 的另一项功能 ASM 来使用。ASM(自动存储管理)是对 OMF 托管文件管理功能的一个有效补充。 OMF 与 ASM 结合使用的注意点 通常情况下，OMF 无法平衡 I/O 和容量管理的功能。这方面的缺陷可以通过 ASM 自动存储管理机制来弥补。两者在结合使用的过程中，需要关注如下内容。 第一裸设备的相关问题。裸设备指的是没有使用文件系统的存储设备。在这种设备上保存数据，其好处是可以提高系统的性能，而其缺陷就是维护比较困难。这里
8、需要注意的是，ASM 自动存储管理其是支持裸设备的，为此就不存在异步 I/O 或者直接 I/O 等问题。而对于 OMF 来说，其大部分情况下还是在文件系统的背景下操作的。所以从应用范围来说，ASM 要比 OMF 功能来的大。在具体配置时，这需要特别注意的。 第二是跨平台的问题。Oracle 数据库是一个跨平台的管理系统，其即可以在微软的操作系统上运行，也可以在 Linux 等操作系统上部署。但是由于不同操作系统之间，其内核等方面存在着比较大的差异，在实5际配制过程中也会遇到很多不同的地方。在使用 OMF 功能于 ASM 功能的时候，也会遇到这种问题。这里需要注意的是，ASM 是专门构建用于简化
9、DBA 工作的管理工具。其提供了跨越所有服务器和存储平台的存储管理界面。也就是说，ASM 其可以支持多个操作系统平台。或者说，在不同的平台上，在操作上其基本是相同的。而对于 OMF 托管文件来说，则没有这么简单。因为 OMF 过关文件这个功能，更像是在跟操作系统打交道，如指定文件存储位置等等，所以受操作系统的影响比较大。最简单的一个例子，就是 Unix 等操作系统与 Windows 等操作系统在文件路径的表示上，就有很大的差异。在具体配置时，需要注意这方面的差异，并选择合适的配置方法。 第三两者分工不同。在实际工作中，很多管理员，特别是第一次接触 Oracle 数据库的管理人员(如从 SQLServer 转到 Oracle)，他们在这方面会有一个误解。OMF 托管文件，其具有自动管理数据文件的功能。但是这个自动管理数据文件，并不是说管理其容量。也就是说，OMF 托管文件只涉及到数据文件的存储路径、数据文件的命名等等。而与存储管理无关。更精确的说，只涉及到存储管理的一小部分。存储管理从大的范围来说，包含存储的路径、存储的名字、存储容量、I/O 等问题。而 OMF 托管文件只涉及到存储的路径、存储的名字；OMF 则涉及到存储容量、I/O等方面的内容。所以这两个功能之间有明显的差异。两者是分工合作，相互补充。为此在实际工作中，往往这两项功能需要同时实现，才能够发挥最佳的效果。
