Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> Re: OFA Question
Since Greg originally asked "Is there ANY reason...", I'll add another element to the consideration. I agree with what Mike says, but if you are really, really picky, putting other files on the filesystem with Oracle datafiles can cause file fragmentation when a datafile is extended in size (auto or otherwise). Also, the filesystem can become fragmented as new (other) files are added and deleted - resulting in a lot of odd sized chunks of contiguous free space in the filesystem. Is this critical? Probably not, but I don't like doing it on critical production servers. OFA allows, even encourages, this in its "normal" incarnation. I often use the VLDB OFA model for significant production databases specifically to prevent this.
It looks like you have adopted the VLDB OFA model - I didn't see a "/" in front of "oradata1/prod", but if these mount points are actually "/oradata1/prod", etc., then that is the VLDB model. (see trailing note). This model is for sites where there is no intention of putting "other" stuff in these filesystems. "/u01/oradata/<dbname>/..." and "/u01/junk/other.file(s)" are OK in the normal OFA model, but "/oradata1/junk/other.file(s)" is at least misleading in the VLDB model since other.file(s) are not "oradata". (A picky point to be sure.)
Also, my experience is that the noble intention of not accessing other files on the data filesystems during critical periods will most likely be abandoned at some point. I have received calls reporting database performance problems only to find someone doing something like uncompressing and expanding very large (1 GB+) .tar.Z files on a performance critical filesystem. (Your mileage may certainly vary!)
Note:
The OFA documentation in the Oracle manuals and at technet.oracle.com is
not really complete - it is sort of the "Reader's Digest" version. For the
full blown OFA documentation, see either:
http://www.hotsos.com/dnloads/0.Millsap1995.09.24-OFA.pdf . That is Cary
Millsap's company site and it may require a (free) registration. You could
also use: http://www.vampired.net/articles/php/standards.php and download it
from there. (See "6. Mount Points for VLDB sites" - OFA 11. I allow at
least one exception to it though - for multiple databases. For example,
/oradata1/prod1/... /oradata1/prod2/... ).
-Don Granaman
[Certifiable OraSaurus]
>
>
> In performance terms it won't really make a difference but from an admin
point
> of view it's not a great idea.
> It's way too easy to accidentally move or remove a file during a routine
> operation and it can can confuse backup and restore operations. If I ever
have
> to do this I create a subdirectory so that at least they're logically
separate
> and risk is minimised.
>
> regards,
> Mike Hately
> Oracle DBA
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author:
> INET: MHately_at_etech-uk.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Don Granaman INET: granaman_at_home.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Thu Jun 07 2001 - 13:37:41 CDT