Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> How closely do you adhere to OFA standards? e.g. arch directory?

How closely do you adhere to OFA standards? e.g. arch directory?

From: Richard A Papaj <papaj_at_acsu.buffalo.edu>
Date: Tue, 26 Feb 2002 18:44:45 -0500
Message-ID: <a5h5vm$g66$1@prometheus.acsu.buffalo.edu>


How closely do you adhere to Optimal Flexible Architecture (OFA) standards? Where, if any, are the areas where you think it makes sense to deviate from the standards? We're a Sun Solaris environment.

For example, the standard (Appendix A in the Sun Sparc 8.1.7 Administrator's manual) calls for a minimum of 2 mount points (to separate data from everything else) with the administrative sub-directories (e.g. arch, etc) being defined within the non-data mount point. Therefore, the archived redo logs would go within that area according to the standard. As long as there is enough space allocated for that partition (and you set up a script to possibly compress and eventually purge older, backed up archived log files), the archived redo log files won't fill up the partition and lock the instance.

Another view is that the archived redo log files should be separated from the common mount point (i.e. ORACLE_BASE) that it shares with the product software. Are there enough benefits that warrants separating them out? That arrangement would deviate from the OFA standard.

Aside from the mount point dedicated for data, does it matter from a contention issue where the archived redo log files go (i.e. the non-data mount point vs its own unique mount point)? Is a unique mount point just for archived redo log files overkill? As long as there's sufficient space, should the arch directory remain in its location according to the standard? Are there any implications if not complying with the OFA standards?

Thanks in advance for any feedback,
-Rick Received on Tue Feb 26 2002 - 17:44:45 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US