Delaying the Opening of Datafiles in Read-Only Tablespaces

When substantial portions of a very large database are stored in read-only
tablespaces that are located on slow-access devices or hierarchical storage, you should consider setting the READ_ONLY_OPEN_DELAYED initialization parameter to TRUE. This speeds certain operations, primarily opening the database, by causing datafiles in read-only tablespaces to be accessed for the first time only when an attempt is made to read data stored within them. 

Setting READ_ONLY_OPEN_DELAYED=TRUE  has the following side-effects:

• A missing or bad read-only file is not detected at open time. It is only discovered when there is an attempt to access it.
• ALTER SYSTEM CHECK DATAFILES does not check read-only files.
• ALTER TABLESPACE...ONLINE and ALTER DATABASE DATAFILE...ONLINE do not check read-only files. They are checked only upon the first access.
• V$RECOVER_FILE, V$BACKUP, and V$DATAFILE_HEADER do not access read-only files. Read-only files are indicated in the results list with the error "DELAYED OPEN", with zeroes for the values of other columns.
• V$DATAFILE does not access read-only files. Read-only files have a size of "0"
  listed.
• V$RECOVER_LOG does not   access read-only files. Logs they could need for recovery are not added to the list.
• ALTER DATABASE NOARCHIVELOG does not access read-only files.It proceeds even if there is a read-only file that requires recovery.

Notes:

RECOVER DATABASE and ALTER DATABASE OPEN RESETLOGS continue to access all read-only datafiles regardless of the parameter value.
If you want to avoid accessing read-only files for these operations, those files should be taken offline.
If a backup control file is used, the read-only status of some files may be inaccurate. This can cause some of these operations to return unexpected results. Care should be taken in this situation.