DBA Tips Archive for Oracle

  


Oracle-Managed Files (OMF)

by Jeff Hunter, Sr. Database Administrator


Contents

  1. Introduction
  2. Uses, Rules and Restrictions
  3. Configuring the Database to Use Oracle Managed Files
  4. Creating a Database Using Oracle Managed Files
  5. Using Oracle Managed Files
  6. Renaming non-Oracle Managed Files to Oracle Managed Files



Introduction

Simply put, Oracle-Managed Files (OMFs) is a feature introduced in Oracle9i that allows the Oracle RDBMS manage datafiles for you. Oracle has been making significant strides in making the database easier to manage and OMF falls into this category of features. For example, in Oracle databases prior to 9i, when you dropped a tablespace, you would also have to remove the physical datafile associated with that tablespace. With Oracle9i, you can leave physical file management to the database itself by using OMFs.

This document provides an overview for using Oracle-Managed Files and the types of datafiles that are managed by this feature and some of the benefits and restrictions of OMFs. I will then continue in the document to show you how to configure your database to take advantage of OMFs and some examples of using OMFs.

  There was a significant change in OMF behavior and file name format introduced in the 2nd patch set for Oracle9i Release 1 (9.0.1.2) and also in Oracle9i Release 2 (9.2) and higher. All of the examples used in this article will make use of the newer OMF file name format!

Also note that all examples will be performed using Oracle10g Release 2.

Before going into the details of Oracle-Managed Files, it might be useful to discuss the different situations where OMF is most useful. First, it is very useful in low-use / smaller databases in order to reduce the administrative overhead associated with such a database. OMF reduces the overall administrative overhead required for such smaller databases and also helps to ensure that old, unused datafiles do not reduce the overall availability of disk space. Keep in mind that configuring the database to use OMFs does not imply that the alternative ability to define datafile names and locations is not available. You can easily use both features of the database if you choose.

The OMF feature can be particularly useful for development and test databases. With this feature, you can allow the developers some latitude to create and remove their own tablespaces (though there is no support at this time for forcing the use of OMF).

One of the most useful advantages of using OMFs is to simplify management of a standby database. In pre-Oracle9i databases, when you added a tablespace or datafile to the primary database, human intervention was required on the standby database to perform the same operation. (i.e. adding database files and tablespaces) With OMF, this is no longer the case. If the standby database is configured to use OMF, then the creation of a tablespace or addition of a datafile to the primary database will result in the automated creation of that tablespace or datafile on the standby server. No other administrative activity is required!

  If datafiles are removed from the primary database, Oracle will not automatically remove the related datafiles on the standby database.

Using OMF is also useful if you have a large database environment that is using large disk arrays. In these environments, typically a small number of large file systems are created that are striped across a number of disks. (i.e. RAID-0) The idea is to stripe these large files across as many disks as you can. This can cause significant performance gains.

OMF is not an appropriate choice for use with a high-volume or mission-critical database that is not using high-end striped disk arrays. For example, OMF is not recommended on systems with many smaller file systems, or systems running RAID-5. This is because the nature of managed datafiles is such that the DBA is not able to distribute I/O as required. Also, the managed datafile feature does not support the use of raw disk devices.



Uses, Rules and Restrictions

Introducing OMF
OMFs can be used when creating database datafiles, tempfiles, online redo logfiles, and database controlfiles. Before attempting to use OMF, you must first configure the database to use OMF. Once the database is configured for OMF, Oracle will create the required database files during the execution of a DDL statement like CREATE TABLESPACE... if you do not specifically define the database files associated with that statement. OMF can be associated with tablespaces, temporary tablespace, redo logs, and controlfiles in Oracle9i.
Tablespace OMF
Any tablespace can be created using OMF, even the SYSTEM tablespace. Configuring Oracle to use OMF can be done by setting the database parameter: db_create_file_dest parameter. If for example you were to create a tablespace, (using the CREATE TABLESPACE... or CREATE TEMPORARY TABLESPACE... command), without specifying any datafile names, Oracle will create the needed datafile for that tablespace. Furthermore, if you issue the create database command and do not supply a datafile name for the SYSTEM tablespace, then an OMF datafile will be created. Also, if you define a TEMPORARY tablespace or an UNDO tablespaces in the create database command, then an OMF will be created for each of those tablespace types.

The default size for any OMF is 100M, and the datafile(s) are set to "AUTOEXTEND ON" with an "UNLIMITED maximum extent". You can define a file size other than 100M for a datafile by including the DATAFILE keyword, and then including the SIZE parameter (without the filename). The datafile will be created at the requested size. It is also possible to include "AUTOEXTEND OFF" to disable the setting of autoextend on the OMF when it is created.

An example is show below:

  SQL> CREATE TABLESPACE app_data DATAFILE SIZE 100M AUTOEXTEND OFF;
The next example shows how to create a tablespace using two OMFs:
  SQL> CREATE TABLESPACE app_data DATAFILE SIZE 100M, SIZE 100M AUTOEXTEND OFF;
The DBA can change the datafile size (via the ALTER DATABASE DATAFILE RESIZE command) or change the datafile AUTOEXTEND parameter without affecting the ability of the Oracle database to manage the datafile.

As datafiles associated with tablespaces fill, they will extend (as long as the ability to autoextend has not been changed by the DBA). Rather than extending the existing OMF, the DBA can also create an additional datafile for the tablespace by issuing an ALTER TABLESPACE ADD DATAFILE... command. If the DBA does not include the datafile name, then the new datafile added will be an OMF. You can mix and match OMF and non-OMF files in the same tablespace if you desire. Oracle will not remove any non-OMF files unless you use the new INCLUDING CONTENTS and DATAFILES keyword of the DROP TABLESPACE... command.

When you drop a tablespace that contains OMF, Oracle will remove the OMFs associated with that tablespace from the operating system. For example, issuing a DROP TABLESPACE... command will cause Oracle to remove the datafiles associated with that tablespace, as long as they are Oracle managed. Of course, if you have defined the names and locations of the datafiles, then Oracle will not remove those datafiles. You will be responsible for that administrative activity yourself.

Another interesting bit of functionality is that you can mix and match OMF with manually defined ones. For example, the following command is perfectly legal:

SQL> CREATE TABLESPACE app_data DATAFILE
  2  SIZE 100M,
  3  '/u02/oradata/TESTDB/datafile/app_data02.dbf' SIZE 100M;

Tablespace created.

SQL> HOST ls -l /u02/oradata/TESTDB/datafile/*app_data*
-rw-r-----  1 oracle  dba   104865792 Aug 11 18:27 /u02/oradata/TESTDB/datafile/app_data02.dbf
-rw-r-----  1 oracle  dba   104865792 Aug 11 18:27 /u02/oradata/TESTDB/datafile/o1_mf_app_data_2ft11rb6_.dbf

In this event, Oracle will create both the OMF and the manually defined datafile. If you drop the tablespace, the default action will be that Oracle will remove only the OMF, and the DBA will need to manually remove all datafiles that are not Oracle managed.

SQL> DROP TABLESPACE app_data;

Tablespace dropped.

SQL> HOST ls -l /u02/oradata/TESTDB/datafile/*app_data*
-rw-r-----  1 oracle  dba   104865792 Aug 11 18:27 /u02/oradata/TESTDB/datafile/app_data02.dbf

SQL> HOST rm /u02/oradata/TESTDB/datafile/app_data02.dbf

This feature can be extended to existing tablespaces that use manually created datafiles. For example, adding additional OMFs to an existing tablespace can expand space allocated to the tablespace created originally in Oracle8i with manually created datafiles.

Redo Log OMF
If you decide to use Oracle-managed redo logfiles, you can create as many redo log groups as you need, bounded of course by the MAXLOGFILES clause setting you used in the CREATE DATABASE... command. You can multiplex each of those groups with up to five additional OMF members (again bounded by the MAXLOGMEMBERS setting when the database is created). The different redo log group members are created in different locations, as defined by multiple parameters such as db_create_online_log_dest_n

You can initially create a database with the create database statement, using OMF redo logs. Simply omit the name of the database datafiles. Depending on the operating system, if none of the db_create_online_log_dest_n parameters are set, then one member for each redo log group will get created in the location pointed to by the db_create_file_dest parameter. If neither parameter is set, then Oracle will return an error when you issue the CREATE DATABASE... statement.

If you issue either the ALTER DATABASE DROP LOGFILE GROUP... or ALTER DATABASE DROP LOGFILE MEMBER..., Oracle will remove the associated logfile group or member - if they were created as OMFs. By default, Oracle-managed redo logs are 100M in size.

Controlfile OMF
If the CONTROL_FILES parameter is not listed in the database parameter file (init.ora) when you create the database, and if the database parameter db_create_online_log_dest_n is configured, Oracle will create the controlfiles for you as OMFs in the directories defined. As with the redo logfiles, you can configure the database so up to five copies of the controlfiles will be created. If the db_create_file_dest parameter is set, but the db_create_online_log_dest_n is not, then a single controlfile is created in the db_create_file_dest. If the db_create_online_log_dest_n parameters are set, then the controlfiles will be written there.

Depending on the operating system, if neither the control_files, db_create_online_log_dest_n nor the db_create_file_dest parameters are set, Oracle might choose to do a couple of things. In some cases, Oracle might create an OMF controlfile in a default directory that is OS specific. In this case, the controlfiles will not be Oracle-managed controlfiles. If you wish the controlfiles to be Oracle managed, you will need to make sure that the OMF parameters (either db_create_file_dest or db_create_online_log_dest_n) are correctly set. On some platforms, Oracle will simply signal an error if the location of the controlfile is not defined by the presence of the control_files parameter.

OMF File Name Formats
When Oracle creates managed database files, it follows a naming convention for these files. You cannot create a new datafile using the OMF naming convention. Any attempt to do so will result in an error.
SQL> ALTER TABLESPACE app_data ADD DATAFILE
  2  '/u02/oradata/TESTDB/datafile/o1_mf_app_data_2ixfh90q_.dbf' SIZE 100M;

ALTER TABLESPACE app_data ADD DATAFILE
*
ERROR at line 1:
ORA-01276: Cannot add file /u02/oradata/TESTDB/datafile/o1_mf_app_data_2ixfh90q_.dbf.
File has an Oracle Managed Files file name.

There was a significant change in OMF behavior and file name format introduced in the 2nd patch set for Oracle9i Release 1 (9.0.1.2) and also in Oracle9i Release 2 (9.2) and higher.

  All of the examples used in this article will make use of the newer OMF file name format!

The naming conventions of the database files are shown in the following table:

Oracle 9.0.1.2 and higher
File Type Naming Convention Example
Datafile o1_mf_%t_%u_.dbf o1_mf_tbs1_2ixfh90q_.dbf
Tempfile o1_mf_%t_%u_.tmp o1_mf_temp1_6dygh80r_.tmp
Redo Logfile o1_mf_%g_%u_.log o1_mf_1_wo94n2xi_.log
Controlfile o1_mf_%u_.ctl o1_mf_cmr7t90p_.ctl
  Where:
    %t is the tablespace name (possibly truncated). Up to eight 
       characters of the tablespace name are used. This is why 
       the second part of the name, the unique character string,
       is important, as two tablespaces might have unique names,
       but the first eight characters of the tablespace might be
       the same.
    %u is an eight character string that guarantees uniqueness
    %g is the online redo log file group number

  A file is considered OMF if its base file name has:
    - a "o1_mf_" prefix
    - and a ".dbf", ".tmp", ".log", or ".ctl" extension
    - and an "_" character immediately preceding the extension
Oracle 9.0.1.0 and 9.0.1.1
File Type Naming Convention Example
Datafile ora_%t_%u.dbf ora_tbs1_2ixfh90q.dbf
Tempfile ora_%t_%u.tmp ora_temp1_6dygh80r.tmp
Redo Logfile ora_%g_%u.log ora_1_wo94n2xi.log
Controlfile ora_%u.ctl ora_cmr7t90p.ctl
  Where:
    %t is the tablespace name (possibly truncated). Up to eight 
       characters of the tablespace name are used. This is why 
       the second part of the name, the unique character string,
       is important, as two tablespaces might have unique names,
       but the first eight characters of the tablespace might be
       the same.
    %u is an eight character string that guarantees uniqueness
    %g is the online redo log file group number

  A file was considered OMF if its base file name had:
    - an "ora_" prefix
    - and a ".dbf", ".tmp", ".log" or ".ctl" extension

  Users can easily migrate from the old OMF file name format (Oracle 9.0.1.0 and 9.0.1.1) to the newer OMF file name format introduced in the 2nd patch set for Oracle9i Release 1 (9.0.1.2) and also in Oracle9i Release 2 (9.2) and higher. For datafiles, tempfiles, and log files, simply rename them in the file system and in the controlfile.

Alternatively one can recreate the controlfile itself after renaming all files at the operating system level. Note that recreating the controlfile will loose archive log history and RMAN backup information.

Migrating datafiles, tempfiles, controlfiles and log files are discussed in much greater detail in the section "Renaming non-Oracle Managed Files to Oracle Managed Files".

  Note that some OMF file formats may be different for various operating system ports. Check your operating system documentation for the file-naming convention used.

Administering OMF
As a DBA, you can use the names of OMF in SQL statements, just as you would normal files. For example, you can use the ALTER DATABASE RENAME FILE... or ALTER TABLESPACE RENAME DATAFILE... commands to rename an Oracle database-managed datafile, you can drop a specific Oracle-managed redo logfile with the ALTER DATABASE DROP LOGFILE... command, and so on.

To rename an OMF datafile, you will first need to offline the tablespace that the OMF datafile is associated with (or offline the OMF datafile). Then, physically rename the datafile at the OS level. Once you have renamed the OMF file, you can issue the RENAME command from within the database (using the ALTER DATABASE... or ALTER TABLESPACE... command) to rename the OMF within the database. Lastly, online the tablespace or datafile.

If you rename the OMF datafile using a file-naming convention that does not follow the OMF naming convention, that file will no longer be an OMF. You cannot rename any existing non-OMF Oracle datafile to a filename that matches the OMF file format. Attempting to RENAME OMF files at the mount stage will fail in 9.0.1.2 onwards with:

ORA-01276: Cannot add file <file_name>. File has an Oracle Managed Files file name.

Here is an example of renaming an existing OMF datafile:

SQL> show parameter db_create_file_dest

NAME                        TS Type      VALUE
--------------------------- ------------ --------------
db_create_file_dest         string       /u02/oradata


SQL> CREATE TABLESPACE app_data DATAFILE SIZE 2M;

Tablespace created.


SQL> SELECT file_name, tablespace_name
  2  FROM dba_data_files
  3  WHERE tablespace_name = 'APP_DATA';

FILE_NAME                                                  TABLESPACE_NAME
---------------------------------------------------------- ------------------------------
/u02/oradata/TESTDB/datafile/o1_mf_app_data_2ft08n6s_.dbf  APP_DATA


SQL> ALTER TABLESPACE app_data OFFLINE;

Tablespace altered.


SQL> HOST mv /u02/oradata/TESTDB/datafile/o1_mf_app_data_2ft08n6s_.dbf /u02/oradata/TESTDB/datafile/o1_mf_app_data_8e2jh3eq_.dbf


SQL> ALTER TABLESPACE app_data RENAME DATAFILE
  2  '/u02/oradata/TESTDB/datafile/o1_mf_app_data_2ft08n6s_.dbf' TO
  3  '/u02/oradata/TESTDB/datafile/o1_mf_app_data_8e2jh3eq_.dbf';

Tablespace altered.


SQL> ALTER TABLESPACE app_data ONLINE;

Tablespace altered.

  The example above is only meant to demonstrate that many of the same capabilities used to manage non-OMF files still exist with OMF files. I do not recommend renaming the file name of an Oracle-managed file. The database identifies an Oracle-managed file based on its name. If you rename the file, the database is no longer able to recognize it as an Oracle-managed file and will not manage the file accordingly.

The backup and recovery procedures for Oracle-managed database files are no different than those for DBA managed files. Also, the use of the Oracle imp and exp utilities are not affected by the presence of OMF.

The procedure for recovering from the loss of a controlfile when using backup controlfiles or re-creating the controlfile using the results of an ALTER DATABASE BACKUP CONTROL FILE TO TRACE; has not changed either.

  Note that I will be dedicating an entire section in this article with the steps required to rename OMF files for various file types (datafiles, tempfiles, controlfiles, and redo logfiles).



Configuring the Database to Use Oracle Managed Files

Before using OMF, you must configure certain database parameters. These parameters define the locations that the different OMF should be created in. The parameters associated with OMF are seen in the following table. Note that each of the parameters described in this table can be dynamically altered via the ALTER SYSTEM... or the ALTER SESSION... command, such as:
SQL> ALTER SYSTEM SET db_create_file_dest='/u02/oradata';

Parameter Name Default Purpose
db_create_file_dest None This defines the file system where OMF and tempfiles are to be located. This location is also used for Oracle-managed controlfiles and redo logs if the DB_CREATE_ONLINE_LOG_DEST_n parameter is not configured.
db_create_online_log_dest_n None This parameter defines the file system location where Oracle-managed online redo logs are to be created. The n value is replaced by a number, 1-5. This allows for up to 5 multiplexed copies of each redo log group member, and up to 5 copies of the control files to be created.

Changing the location to create files does not affect Oracle's ability to manage datafiles already created in other directories.

  Even if you have not configured db_create_file_dest or db_create_online_log_dest_n, you can still configure them dynamically and take advantage of OMF without having to shut down and restart the database.

The first step in using OMF is to configure the init.ora database parameter file (or SPFILE) to support the use of this feature. Here is an example of the initTESTDB.ora for the TESTDB database. (Note that I left out many of the settings that don't pertain to configuration of OMF.)

  db_name                     = TESTDB
  db_create_file_dest         = '/u02/oradata'
  db_create_online_log_dest_1 = '/u02/oradata'
  db_create_online_log_dest_2 = '/u02/oradata'

With the above configuration, Oracle creates OMF datafiles and tempfiles in the '/u02/oradata/TESTDB/datafile' directory.

Next, two directory locations are defined for redo logs and controlfiles to be created using the db_create_online_log_dest_1 and db_create_online_log_dest_2 parameters. Notice that the directories could have used two different mount points to protect the redo logs and controlfiles from accidental erasure and for some I/O balancing. With the above configuration, Oracle creates OMF controlfiles and online redolog files in the '/u02/oradata/TESTDB/controlfile' and '/u02/oradata/TESTDB/onlinelog' directories respectively.

  New OFA Based Directories with Oracle10g!

If you have ever used OMF in Oracle9i, you will notice a significant change with regards to the directories automatically created based on setting db_create_file_dest and db_create_online_log_dest_n. In Oracle9i, when you set db_create_file_dest or db_create_online_log_dest_n, Oracle simply places the OMF file in that directory. Basically, it just does what you told it to do. So in Oracle9i, when I wanted to somewhat comply with OFA, I would have to append the database name to the end of the directory as illustrated in the following example:

db_name                     = ORA920
db_create_file_dest         = /u02/oradata/ORA920
db_create_online_log_dest_1 = /u02/oradata/ORA920
db_create_online_log_dest_2 = /u02/oradata/ORA920
Given the above settings, database files will be created in the defined location, for example:
/u02/oradata/ORA920/o1_mf_app_data_2ftbvrdf_.dbf

With Oracle10g, the values used for db_create_file_dest and db_create_online_log_dest_n are used as a mount point or prefix location for creating OMF files. At last, Oracle is finally doing what they preach and that is to create filenames and directories that comply with the Optimal Flexible Architecture (OFA) standard for file naming. The specification for OMF file naming is:

<destination_location>/<db_unique_name>/<file_type>/<OMF_file_name>
where:
  • <destination_location> is the value provided for db_create_file_dest or db_create_online_log_dest_n.

  • <db_unique_name> is the globally unique name (DB_UNIQUE_NAME initialization parameter) of the target database. If there is no DB_UNIQUE_NAME parameter, then the DB_NAME initialization parameter value is used.

  • <file_type> is automatically provided by Oracle to identify what type of file it is. Values include:
    controlfile
    datafile
    onlinelog

  • <OMF_file_name> is the actual OMF file name. File name formats are discussed in the section "OMF File Name Formats".

With Oracle10g, we no longer have to provide the database name in the path when defining db_create_file_dest and db_create_online_log_dest_n:

db_name                     = TESTDB
db_create_file_dest         = /u02/oradata
db_create_online_log_dest_1 = /u02/oradata
db_create_online_log_dest_2 = /u02/oradata
Given the above parameter settings, here are a few example directories and file names:

Controlfile
/u02/oradata/TESTDB/controlfile/o1_mf_8du3s3er_.ctl

Tempfile
/u02/oradata/TESTDB/datafile/o1_mf_temp_2fr0rh66_.tmp

Datafile
/u02/oradata/TESTDB/datafile/o1_mf_system_2ft5o22l_.dbf

Online Redo Logfile
/u02/oradata/TESTDB/onlinelog/o1_mf_1_2fr0l4x5_.log



Creating a Database Using Oracle Managed Files

This section demonstrates how to create a database using all OMF files.

CREATE DATABASE Example 1

Actually, once an appropriate Oracle instance is start, all we really need to do is issue the CREATE DATABASE and let Oracle do all of the work for us! To demonstrate how to use just the CREATE DATABASE statement, define the following initialization parameters:

initTESTDB.ora
db_name                     = TESTDB
db_create_file_dest         = '/u02/oradata'
db_create_online_log_dest_1 = '/u02/oradata'
db_create_online_log_dest_2 = '/u02/oradata'
undo_management             = AUTO
undo_tablespace             = SYS_UNDOTS

$ ORACLE_SID=TESTDB; export ORACLE_SID
$ sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.2.0 - Production on Fri Aug 11 19:07:42 2006

Copyright (c) 1982, 2005, Oracle.  All Rights Reserved.

Connected to an idle instance.

SQL> STARTUP NOMOUNT
ORACLE instance started.

Total System Global Area  113246208 bytes
Fixed Size                  1259432 bytes
Variable Size              58722392 bytes
Database Buffers           50331648 bytes
Redo Buffers                2932736 bytes

SQL> CREATE DATABASE;

Database created.

SQL> HOST ls -l /u02/oradata/ALEXDB/*
/u02/oradata/ALEXDB/controlfile:
total 11896
-rw-r-----   1 oracle   dba   6078464 Aug 11 19:26 o1_mf_2ft4c1s3_.ctl
-rw-r-----   1 oracle   dba   6078464 Aug 11 19:26 o1_mf_2ft4c21m_.ctl

/u02/oradata/ALEXDB/datafile:
total 215288
-rw-r-----   1 oracle   dba   104865792 Aug 11 19:24 o1_mf_sysaux_2ft4d6oh_.dbf
-rw-r-----   1 oracle   dba   104865792 Aug 11 19:24 o1_mf_system_2ft4clww_.dbf
-rw-r-----   1 oracle   dba   10493952 Aug 11 19:24 o1_mf_sys_undo_2ft4d619_.dbf

/u02/oradata/ALEXDB/onlinelog:
total 410032
-rw-r-----   1 oracle   dba   104858112 Aug 11 19:24 o1_mf_1_2ft4c2b4_.log
-rw-r-----   1 oracle   dba   104858112 Aug 11 19:24 o1_mf_1_2ft4c2wd_.log
-rw-r-----   1 oracle   dba   104858112 Aug 11 19:23 o1_mf_2_2ft4c6sx_.log
-rw-r-----   1 oracle   dba   104858112 Aug 11 19:23 o1_mf_2_2ft4cbv3_.log

  After the database creation process, you will want to update the control_files initialization parameter to reflect the new OMF controfiles created:
control_files = '/u02/oradata/ALEXDB/controlfile/o1_mf_2ft4c1s3_.ctl',
                '/u02/oradata/ALEXDB/controlfile/o1_mf_2ft4c21m_.ctl'

  Note that with Oracle10g, the CREATE DATABASE statement will create the SYSAUX tablespace for you!

CREATE DATABASE Example 2
In the next example, we want to exert a bit more control over our database creation process This example assumes the instance was started using the initialization parameters defined below:

initTESTDB.ora
db_name                     = TESTDB
db_create_file_dest         = '/u02/oradata'
db_create_online_log_dest_1 = '/u02/oradata'
db_create_online_log_dest_2 = '/u02/oradata'
undo_management             = AUTO
undo_tablespace             = UNDOTBS1

$ ORACLE_SID=TESTDB; export ORACLE_SID
$ sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.2.0 - Production on Fri Aug 11 19:07:42 2006

Copyright (c) 1982, 2005, Oracle.  All Rights Reserved.

Connected to an idle instance.

SQL> STARTUP NOMOUNT
ORACLE instance started.

Total System Global Area  113246208 bytes
Fixed Size                  1259432 bytes
Variable Size              58722392 bytes
Database Buffers           50331648 bytes
Redo Buffers                2932736 bytes

SQL> CREATE DATABASE testdb DATAFILE SIZE 800M
  2  LOGFILE GROUP 1 SIZE 10M, GROUP 2 SIZE 10M
  3  DEFAULT TEMPORARY TABLESPACE temp TEMPFILE SIZE 100M
  4  UNDO TABLESPACE undotbs1 DATAFILE SIZE 50M
  5  MAXLOGFILES   5
  6  MAXLOGMEMBERS 5
  7  MAXDATAFILES  600
  8  NOARCHIVELOG;

Database created.

SQL> HOST ls -l /u02/oradata/ALEXDB/*
/u02/oradata/ALEXDB/controlfile:
total 24704
-rw-r-----   1 oracle  dba    12632064 Aug 11 19:46 o1_mf_2ft5nz9w_.ctl
-rw-r-----   1 oracle  dba    12632064 Aug 11 19:46 o1_mf_2ft5nzt4_.ctl

/u02/oradata/ALEXDB/datafile:
total 973864
-rw-r-----   1 oracle  dba    104865792 Aug 11 19:46 o1_mf_sysaux_2ft5pmpy_.dbf
-rw-r-----   1 oracle  dba    838868992 Aug 11 19:46 o1_mf_system_2ft5o22l_.dbf
-rw-r-----   1 oracle  dba    104865792 Aug 11 19:46 o1_mf_temp_2ft5psst_.tmp
-rw-r-----   1 oracle  dba    52436992 Aug 11 19:46 o1_mf_undotbs1_2ft5pjv2_.dbf

/u02/oradata/ALEXDB/onlinelog:
total 41040
-rw-r-----   1 oracle  dba    10486272 Aug 11 19:46 o1_mf_1_2ft5o0bl_.log
-rw-r-----   1 oracle  dba    10486272 Aug 11 19:46 o1_mf_1_2ft5o0dk_.log
-rw-r-----   1 oracle  dba    10486272 Aug 11 19:46 o1_mf_2_2ft5o0sh_.log
-rw-r-----   1 oracle  dba    10486272 Aug 11 19:46 o1_mf_2_2ft5o16m_.log

  After the database creation process, you will want to update the control_files initialization parameter to reflect the new OMF controfiles created:
control_files = '/u02/oradata/ALEXDB/controlfile/o1_mf_2ft5nz9w_.ctl',
                '/u02/oradata/ALEXDB/controlfile/o1_mf_2ft5nzt4_.ctl'

So, in our example, the database TESTDB will be created with a SYSTEM tablespace that is 800M in size. Based on the initialization parameters we set, the datafile for the SYSTEM tablespace will reside in the directory '/u02/oradata/ALEXDB/datafile'. Next, we have defined a default temporary tablespace called TEMP. This tablespace is 100M in size and will also be created in '/u02/oradata/ALEXDB/datafile'. We have also created an UNDO tablespace called UNDOTBS1 that is 50M in size. Again, this tablespace's datafile will be in '/u02/oradata/ALEXDB/datafile'. When this database is created, the redo logfiles will be created in the two locations provided by defining db_create_online_log_dest_1 and db_create_online_log_dest_2. The first member of each group will be in the directory '/u02/oradata/ALEXDB/onlinelog' directory. Also notice that two controlfiles will be created, both in the /u02/oradata/ALEXDB/controlfile directory. Please note that when defining db_create_online_log_dest_1 and db_create_online_log_dest_2, that these could have been separate mount points!



Using Oracle Managed Files

It's now time to look at some examples of administrative functions involving OMF. This includes adding and dropping tablespaces. Other administrative items you will see are the changing of the default locations for datafile creations and the process of adding and dropping redo logs from a database that is using OMF.

Adding a Tablespace

Adding a tablespace is a simple operation when using OMF. Simply issue the create tablespace command with only the name of the tablespace, and Oracle will create the tablespace using the 100M default datafile size. AUTOEXTEND will be turned on with a NEXT value set to 100M and MAXSIZE set to UNLIMITED (34,359,721,984 bytes). Note the following example:
SQL> CREATE TABLESPACE app_data;

Tablespace created.

If you wanted to create the same tablespace as above where the datafile does not have AUTOEXTEND turned on, you can use the NOEXTEND clause:

SQL> CREATE TABLESPACE app_data NOEXTEND;

Tablespace created.

If we wanted a larger tablespace created, we could include the DATAFILE clause and indicate what the size of the datafile should be. Note that when you specify the DATAFILE clause and the size, Oracle will turn AUTOEXTEND off, disabling the datafile's ability to extend when more space is required in the tablespace. The following example creates a 500M datafile with the AUTOEXTEND functionality of the datafile disabled.

SQL> CREATE TABLESPACE app_data_bigger DATAFILE SIZE 500M;

Tablespace created.

You can also use OMF when creating TEMPORARY and UNDO tablespaces, as shown in this example:

SQL> CREATE TEMPORARY TABLESPACE temp2 TEMPFILE SIZE 200M;

Tablespace created.

SQL> CREATE UNDO TABLESPACE UNDOTBS2 DATAFILE SIZE 200M;

Tablespace created.
Dropping a Tablespace
Now that we have created tablespaces, there will be a need to drop them from time to time. In this example, let's drop the app_data_bigger we created earlier in this section. Simply use the drop tablespace command, and Oracle will handle the rest, as shown in the following example:
SQL> DROP TABLESPACE app_data_bigger;

Tablespace dropped.
The datafile for the app_data_bigger tablespace will be dropped by Oracle automatically during the execution of the statement.

  Even if the db_create_file_dest parameter has been changed, Oracle will remove any OMF as long as it remains in its original directory.

  The INCLUDING CONTENTS clause of the DROP TABLESPACE... statement has had a new clause added to it, AND DATAFILES. When this clause is included in the DROP TABLESPACE... command, the tablespace will be dropped and all associated datafiles will be dropped as well. This is a new feature in Oracle9i!
SQL> DROP TABLESPACE app_data_bigger INCLUDING CONTENTS AND DATAFILES;

Changing the Location of Datafile Creation
The ALTER SYSTEM... and ALTER SESSION... commands can be used to alter all the parameters associated with OMF. Thus, we can change the location that database datafiles, as well as redo logs, are created in. Here is an example of changing the location of the parameter db_create_file_dest, and then creating a datafile after that operation:
SQL> ALTER SYSTEM SET db_create_file_dest = '/u03/oradata';

System altered.

SQL> CREATE TABLESPACE app_data2 DATAFILE SIZE 200M NOEXTEND;

Tablespace created.
In this case, any newly created datafile will be created in the /u03/oradata/TESTDB/datafile directory. If we dropped any tablespace that had datafiles in the old directory, those datafiles would be removed by Oracle, just as Oracle would remove the datafiles for the APP_DATA2 tablespace just created.
Adding a Redo Log Group
When we created our database, two redo log groups of 10M each were defined for our database. Let's create a third logfile group. To do this, simply issue the ALTER DATABASE ADD LOGFILE statement. Note that without specifying the size for the member, it will default to 100M:
SQL> ALTER DATABASE ADD LOGFILE;

Database altered.

Alternatively, you can issue the following statement to create a redo log group of 300M as opposed to the 100M default size.

SQL> ALTER DATABASE ADD LOGFILE GROUP 3 SIZE 300M;

Database altered.
Dropping a Redo Log Group
Perhaps you have discovered that your existing redo log members are not large enough and you wish to re-create them so they are larger. In this case, first you need to remove one of the existing redo log groups, and then re-create it. This is a simple operation, performed with the ALTER DATABASE command:
SQL> ALTER DATABASE DROP LOGFILE GROUP 4;

Database altered.

  As a DBA, you should already be aware that if you are going to drop a logfile group, it cannot be the current logfile group. I have run into instances; however, where attempting to drop the logfile group resulted in the following error as a result of the logfile group having an active status:
SQL> ALTER DATABASE DROP LOGFILE GROUP 4;
ALTER DATABASE DROP LOGFILE GROUP 4
*
ERROR at line 1:
ORA-01624: log 4 needed for crash recovery of instance TESTDB (thread 1)
ORA-00312: online log 4 thread 1: '/u02/oradata/TESTDB/onlinelog/o1_mf_4_2fth85yc_.log'
ORA-00312: online log 4 thread 1: '/u02/flash_recovery_area/TESTDB/onlinelog/o1_mf_4_2fth8jso_.log'
Easy problem to resolve. Simply perform a checkpoint on the database:
SQL> ALTER SYSTEM CHECKPOINT GLOBAL;

System altered.

SQL> ALTER DATABASE DROP LOGFILE GROUP 4;

Database altered.

  Something to keep in mind is that it's not possible to add an additional log group member that is an OMF (that is, ALTER DATABASE ADD LOGFILE MEMBER TO GROUP 2). You can drop an OMF redo log member, however, with the ALTER DATABASE DROP LOGFILE MEMBER.... In this event, Oracle will remove the dropped redo log member.



Renaming non-Oracle Managed Files to Oracle Managed Files

This section provides the steps necessary to rename non-OMF files to conform to the newest OMF file name format and therefore be recognized as Oracle Managed Files. The newer file name format was introduced in the 2nd patch set for Oracle9i Release 1 (9.0.1.2) and also in Oracle9i Release 2 (9.2) and higher. The section "OMF File Name Formats" for details about OMF file name formats.

The examples in this section will be performed against an Oracle10g Release 2 (10.2.0.2.0) database.

Note that steps required to rename different file types (controlfile, datafile, tempfile, redo logfile) requires its own unique method. Each of the renaming methods for the different file types will be explained in this section.

Controlfiles

Renaming a non-OMF controlfile to OMF is a very straightforward process. Simply rename the non-OMF controlfile in the file system and in the control_files initialization parameter. The steps are:

  1. Find the non-OMF controlfiles by examining the control_files initialization for the instance:
    SQL> select name from v$controlfile;
    
    NAME
    ---------------------------------
    /u02/oradata/TESTDB/control01.ctl
    /u02/oradata/TESTDB/control02.ctl

  2. Shutdown the database:
    SQL> shutdown immediate
    Database closed.
    Database dismounted.
    ORACLE instance shut down.

  3. Rename the non-OMF files in the file system to the newest OMF file name format:
    $ cd /u02/oradata/TESTDB
    $ mkdir -p controlfile
    $ mv control01.ctl controlfile/o1_mf_8du3s3er_.ctl
    $ mv control02.ctl controlfile/o1_mf_y2is93je_.ctl

  4. Modify the control_files initialization parameter in your init.ora or SPFILE to reference the new name(s):
    SQL> startup nomount
    ORACLE instance started.
    
    Total System Global Area  285212672 bytes
    Fixed Size                  1260420 bytes
    Variable Size             150996092 bytes
    Database Buffers          130023424 bytes
    Redo Buffers                2932736 bytes
    
    SQL> alter system set
      2  control_files='/u02/oradata/TESTDB/controlfile/o1_mf_8du3s3er_.ctl',
      3                '/u02/oradata/TESTDB/controlfile/o1_mf_y2is93je_.ctl'
      4  scope=spfile;
    
    System altered.
    
    SQL> shutdown immediate
    ORA-01507: database not mounted
    
    
    ORACLE instance shut down.

  5. Mount and open the database:
    SQL> startup
    ORACLE instance started.
    
    Total System Global Area  285212672 bytes
    Fixed Size                  1260420 bytes
    Variable Size             180356220 bytes
    Database Buffers          100663296 bytes
    Redo Buffers                2932736 bytes
    Database mounted.
    Database opened.

  6. Verify location of new controlfile(s):
    SQL> select name from v$controlfile;
    
    NAME
    ---------------------------------------------------
    /u02/oradata/TESTDB/controlfile/o1_mf_8du3s3er_.ctl
    /u02/oradata/TESTDB/controlfile/o1_mf_y2is93je_.ctl
Datafiles
The steps to rename non-OMF named datafiles to OMF files are:

  1. Determine the non-OMF files to rename by examining the file names in DBA_DATA_FILES:
    SQL> SELECT tablespace_name, file_name
      2  FROM dba_data_files;
    
    TABLESPACE_NAME FILE_NAME
    --------------- ----------------------------------
    APP_DATA        /u02/oradata/TESTDB/app_data01.dbf
    SYSTEM          /u02/oradata/TESTDB/system01.dbf
    UNDOTBS1        /u02/oradata/TESTDB/undotbs01.dbf
    SYSAUX          /u02/oradata/TESTDB/sysaux01.dbf
    EXAMPLE         /u02/oradata/TESTDB/example01.dbf
    USERS           /u02/oradata/TESTDB/users01.dbf
    APEX22          /u02/oradata/TESTDB/apex22.dbf
    FLOW_1          /u02/oradata/TESTDB/flow_1.dbf
    
    8 rows selected.

  2. Shutdown the database:
    SQL> shutdown immediate
    Database closed.
    Database dismounted.
    ORACLE instance shut down.

  3. Rename the non-OMF files in the file system to the newest OMF file name format:
    $ cd /u02/oradata/TESTDB
    $ mkdir -p datafile
    $ mv app_data01.dbf datafile/o1_mf_app_data_2ftf95wm_.dbf
    $ mv system01.dbf   datafile/o1_mf_system_2fb4b8s2_.dbf
    $ mv undotbs01.dbf  datafile/o1_mf_undotbs1_2fb4c2wf_.dbf
    $ mv sysaux01.dbf   datafile/o1_mf_sysaux_2fb4cb7z_.dbf
    $ mv example01.dbf  datafile/o1_mf_example_2fb4ccw2_.dbf
    $ mv users01.dbf    datafile/o1_mf_users_2fb4cqf4_.dbf
    $ mv apex22.dbf     datafile/o1_mf_apex22_2ft4eswu_.dbf
    $ mv flow_1.dbf     datafile/o1_mf_flow_1_2fb4cegw_.dbf

  4. Rename the files in the controlfile:
    SQL> startup mount
    ORACLE instance started.
    
    Total System Global Area  285212672 bytes
    Fixed Size                  1260420 bytes
    Variable Size             180356220 bytes
    Database Buffers          100663296 bytes
    Redo Buffers                2932736 bytes
    Database mounted.
    
    SQL> alter database rename file '/u02/oradata/TESTDB/app_data01.dbf'
      2  to '/u02/oradata/TESTDB/datafile/o1_mf_app_data_2ftf95wm_.dbf';
    
    Database altered.
    
    SQL> alter database rename file '/u02/oradata/TESTDB/system01.dbf'
      2  to '/u02/oradata/TESTDB/datafile/o1_mf_system_2fb4b8s2_.dbf';
    
    Database altered.
    
    SQL> alter database rename file '/u02/oradata/TESTDB/undotbs01.dbf'
      2  to '/u02/oradata/TESTDB/datafile/o1_mf_undotbs1_2fb4c2wf_.dbf';
    
    Database altered.
    
    SQL> alter database rename file '/u02/oradata/TESTDB/sysaux01.dbf'
      2  to '/u02/oradata/TESTDB/datafile/o1_mf_sysaux_2fb4cb7z_.dbf';
    
    Database altered.
    
    SQL> alter database rename file '/u02/oradata/TESTDB/example01.dbf'
      2  to '/u02/oradata/TESTDB/datafile/o1_mf_example_2fb4ccw2_.dbf';
    
    Database altered.
    
    SQL> alter database rename file '/u02/oradata/TESTDB/users01.dbf'
      2  to '/u02/oradata/TESTDB/datafile/o1_mf_users_2fb4cqf4_.dbf';
    
    Database altered.
    
    SQL> alter database rename file '/u02/oradata/TESTDB/apex22.dbf'
      2  to '/u02/oradata/TESTDB/datafile/o1_mf_apex22_2ft4eswu_.dbf';
    
    Database altered.
    
    SQL> alter database rename file '/u02/oradata/TESTDB/flow_1.dbf'
      2  to '/u02/oradata/TESTDB/datafile/o1_mf_flow_1_2fb4cegw_.dbf';
    
    Database altered.

  5. Open database and verify new OMF files:
    SQL> alter database open;
    
    Database altered.
    
    SQL> SELECT tablespace_name, file_name
      2  FROM dba_data_files;
    
    TABLESPACE_NAME FILE_NAME
    --------------- ---------------------------------------------------------
    APP_DATA        /u02/oradata/TESTDB/datafile/o1_mf_app_data_2ftf95wm_.dbf
    SYSTEM          /u02/oradata/TESTDB/datafile/o1_mf_system_2fb4b8s2_.dbf
    UNDOTBS1        /u02/oradata/TESTDB/datafile/o1_mf_undotbs1_2fb4c2wf_.dbf
    SYSAUX          /u02/oradata/TESTDB/datafile/o1_mf_sysaux_2fb4cb7z_.dbf
    EXAMPLE         /u02/oradata/TESTDB/datafile/o1_mf_example_2fb4ccw2_.dbf
    USERS           /u02/oradata/TESTDB/datafile/o1_mf_users_2fb4cqf4_.dbf
    APEX22          /u02/oradata/TESTDB/datafile/o1_mf_apex22_2ft4eswu_.dbf
    FLOW_1          /u02/oradata/TESTDB/datafile/o1_mf_flow_1_2fb4cegw_.dbf
    
    8 rows selected.

  The process of renaming a database file that is in the older OMF file name format (Oracle 9.0.1.0 and 9.0.1.1) to the newest OMF file name format (Oracle 9.0.1.2 onwards) can be a bit tricky in Oracle 9.0.1.2. Attempting to RENAME the old OMF datafiles at the mount stage will fail in Oracle 9.0.1.2 with:
ORA-01276: Cannot add file <file_name>. File has an Oracle Managed Files file name.
Please note that this problem is fixed in Oracle9i R2 and Oracle10g!

These steps can be used to migrate old OMF database files (Oracle 9.0.1.0 and 9.0.1.1) to conform to the newest OMF file name format and therefore be recognized as Oracle Managed Files when using Oracle 9.0.1.2:

  1. Open the database in RESTRICTED mode:
    SQL> shutdown immediate
    SQL> startup open exclusive
    SQL> alter system enable restricted session;

  2. Find the old OMF file(s) (and tablespace they belong to) to rename by examining the file names in DBA_DATA_FILES:
    SQL> select tablespace_name, file_name
      2  from dba_data_files;

  3. Offline the tablespace which use old OMF files:
    SQL> alter tablespace <tablespace_name> offline;

  4. Rename the file(s) in the file system:

    • Change "ora_" to "o1_mf_"
    • And add "_" before the extension

    For example:

    $ mv ora_tbs1_2gu7sx6e.dbf o1_mf_tbs1_2gu7sx6e_.dbf

  5. Rename the file(s) in the controlfile. For example:
    SQL> alter tablespace <tablespace_name>
      2  rename datafile '<old-omf-filename>' to '<new-omf-filename>';

  6. Put the tablespace back online:
    SQL> alter tablespace <tablespace_name> online;

  7. Bounce the database if in RESTRICTED mode.

Tempfiles
Oracle introduced the capability in 9i to drop tempfiles from a temporary tablespace. Using this new feature, we can simply drop the non-OMF tempfiles and re-create new OMF files in their place!

Note that this operation should be performed during off hours with no users logged on performing work.

The steps to rename non-OMF named tempfiles to OMF files are:

  1. Determine the non-OMF tempfile(s) to rename by examining the file names in DBA_TEMP_FILES:
    SQL> select tablespace_name, file_name from dba_temp_files;
    
    TABLESPACE_NAME FILE_NAME
    --------------- ----------------------------------
    TEMP            /u02/oradata/TESTDB/temp01.dbf

  2. Drop the non-OMF tempfile:
    SQL> alter database tempfile '/u02/oradata/TESTDB/temp01.dbf' drop including datafiles;

      If users are currently accessing the tempfile you are attempting to drop, you may receive the following error:
    SQL> alter database tempfile '/u02/oradata/TESTDB/temp01.dbf' drop including datafiles;
    alter database tempfile '/u02/oradata/TESTDB/temp01.dbf' drop including datafiles;
    *
    ERROR at line 1:
    ORA-25152: TEMPFILE cannot be dropped at this time
    As for the poor users who were using the tempfile, their transaction will end and will be greeted with the following error message:
    SQL> @testTemp.sql
           join dba_extents  c on (b.segment_name = c.segment_name)
                *
    ERROR at line 4:
    ORA-00372: file 601 cannot be modified at this time
    ORA-01110: data file 601: '/u02/oradata/TESTDB/temp01.dbf'
    ORA-00372: file 601 cannot be modified at this time
    ORA-01110: data file 601: '/u02/oradata/TESTDB/temp01.dbf'
    If this happens, you should attempt to drop the tempfile again so the operation is successful:
    SQL> alter database tempfile '/u02/oradata/TESTDB/temp01.dbf' drop including datafiles;
    
    Database altered.

  3. Create OMF tempfile:
    SQL> alter tablespace temp add tempfile size 512m
      2  autoextend on next 250m maxsize unlimited;
    
    Tablespace altered.

  4. Verify new OMF tempfiles:
    SQL> select tablespace_name, file_name from dba_temp_files;
    
    TABLESPACE_NAME FILE_NAME
    --------------- -----------------------------------------------------
    TEMP            /u02/oradata/TESTDB/datafile/o1_mf_temp_2g17lvcq_.tmp
Online Redo Logfiles
To create OMF online redo logfiles, simply drop the old non-OMF logfiles and re-create them using OMF. The steps to rename non-OMF named online redo logfiles to OMF files are:

  1. Determine the non-OMF online redo logfiles to rename by examining the file names (and sizes) V$LOGFILE:
    SQL> select a.group#, a.member, b.bytes
      2  from v$logfile a, v$log b where a.group# = b.group#;
    
        GROUP# MEMBER                                     BYTES
    ---------- ----------------------------------- ------------
             1 /u02/oradata/TESTDB/redo_g01a.log    104,857,600
             2 /u02/oradata/TESTDB/redo_g02a.log    104,857,600
             3 /u02/oradata/TESTDB/redo_g03a.log    104,857,600
    
    3 rows selected.

  2. Force a log switch until the last redo log is marked "CURRENT" by issuing the following command:
    SQL> select group#, status from v$log;
    
        GROUP# STATUS
    ---------- ----------------
             1 CURRENT
             2 INACTIVE
             3 INACTIVE
    
    SQL> alter system switch logfile;
    
    SQL> alter system switch logfile;
    
    SQL> select group#, status from v$log;
    
        GROUP# STATUS
    ---------- ----------------
             1 INACTIVE
             2 INACTIVE
             3 CURRENT
    

  3. After making the last online redo log file the CURRENT one, drop the first online redo log:
    SQL> alter database drop logfile group 1;
    
    Database altered.
    
    SQL> host rm /u02/oradata/TESTDB/redo_g01a.log

      As a DBA, you should already be aware that if you are going to drop a logfile group, it cannot be the current logfile group. I have run into instances; however, where attempting to drop the logfile group resulted in the following error as a result of the logfile group having an active status:
    SQL> ALTER DATABASE DROP LOGFILE GROUP 1;
    ALTER DATABASE DROP LOGFILE GROUP 1
    *
    ERROR at line 1:
    ORA-01624: log 1 needed for crash recovery of instance TESTDB (thread 1)
    ORA-00312: online log 1 thread 1: '<file_name>'
    Easy problem to resolve. Simply perform a checkpoint on the database:
    SQL> ALTER SYSTEM CHECKPOINT GLOBAL;
    
    System altered.
    
    SQL> ALTER DATABASE DROP LOGFILE GROUP 1;
    
    Database altered.

  4. Re-create the dropped redo log group as OMF (and a different size if desired):
    SQL> alter database add logfile group 1 size 250m;
    
    Database altered.

  5. After re-creating the online redo log group, force a log switch. The online redo log group just created should become the "CURRENT" one:
    SQL> select group#, status from v$log;
    
        GROUP# STATUS
    ---------- ----------------
             1 UNUSED
             2 INACTIVE
             3 CURRENT
    
    SQL> alter system switch logfile;
    
    SQL> select group#, status from v$log;
    
        GROUP# STATUS
    ---------- ----------------
             1 CURRENT
             2 INACTIVE
             3 ACTIVE

  6. After re-creating an online redo log group, loop back to step 3 until all logs are rebuilt. Continue to re-create (and resize if desired) all online redo log groups until all of them are rebuilt.

  7. Verify new OMF online redo logfiles:
    SQL> select a.group#, a.member, b.bytes
      2  from v$logfile a, v$log b where a.group# = b.group#;
    
    GROUP# MEMBER                                                              BYTES
    ------ --------------------------------------------------------------- ---------
         1 /u02/oradata/TESTDB/onlinelog/o1_mf_1_2g1g61bm_.log             262144000
         2 /u02/oradata/TESTDB/onlinelog/o1_mf_2_2g1gd4pr_.log             262144000
         3 /u02/oradata/TESTDB/onlinelog/o1_mf_3_2g1ghs0t_.log             262144000
         1 /u02/flash_recovery_area/TESTDB/onlinelog/o1_mf_1_2g1g6bq0_.log 262144000
         2 /u02/flash_recovery_area/TESTDB/onlinelog/o1_mf_2_2g1gdgn1_.log 262144000
         3 /u02/flash_recovery_area/TESTDB/onlinelog/o1_mf_3_2g1ghz8z_.log 262144000


Copyright (c) 1998-2017 Jeffrey M. Hunter. All rights reserved.

All articles, scripts and material located at the Internet address of http://www.idevelopment.info is the copyright of Jeffrey M. Hunter and is protected under copyright laws of the United States. This document may not be hosted on any other site without my express, prior, written permission. Application to host any of the material elsewhere can be made by contacting me at jhunter@idevelopment.info.

I have made every effort and taken great care in making sure that the material included on my web site is technically accurate, but I disclaim any and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on it. I will in no case be liable for any monetary damages arising from such loss, damage or destruction.

Last modified on
Saturday, 18-Sep-2010 17:53:17 EDT
Page Count: 70249