Re: OMF or not OMF?

From: Mark Bobak <Mark.Bobak_at_proquest.com>
Date: Fri, 21 Mar 2014 14:06:45 +0000
Message-ID: <CF51BF5E.55F5D%Mark.Bobak_at_ProQuest.com>



I agree with Tim. Just use OMF and forget about it.

In my view, ASM, OMF, and bigfile tablespaces go hand in hand, and make life easier for the DBA.

-Mark

On 3/21/14, 9:40 AM, "Tim Gorman" <tim_at_evdbt.com> wrote:

>"What's in a name? That which we call a rose, by any other name would
>smell as sweet." -W. Shakespeare, "Romeo & Juliet", Act 2, scene 2
>
>Why do you prefer manual control of file naming? I recall scripting
>space management and how much needless hassle was involved in file
>naming and the irritation when someone on the team deviated from the
>preferred convention. OMF has made all of that moot, with zero downside.
>
>One thing I recall from bucking OMF, at least from the 10g timeframe;
>if you created a non-OMF file and then later drop the tablespace without
>the clause "INCLUDING CONTENTS AND DATAFILES", ASM would drop the alias
>but not the file itself. So, I periodically had to go into ASMCMD and
>look for "orphaned" files from tablespaces that had been dropped without
>the "INCLUDING" clause; not sure if that is still an issue?
>
>Regardless, it's useful to stop and think about why certain preferences
>exist; sometimes they go obsolete behind your back...
>
>
>On 3/21/2014 6:34 AM, Jeff C wrote:
>> I have never used OMF for my database file structure and I was
>> wondering is this what everybody is doing now? I realize that if you
>> are using ASM you have to go with OMF so I am really only talking no
>> ASM users. I guess I have always like control my file names and
>> locations. But my next database I am about to create I was thinking of
>> trying OMF.
>> If I do go with it I will probably still manually control the location
>> of the control files and archive files. Can you also create a non OMF
>> temp tablespace?
>>
>> Thanks for any input
>--
>http://www.freelists.org/webpage/oracle-l
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Mar 21 2014 - 15:06:45 CET

Original text of this message