RE: Downsides to OMF?
- From: "Powell, Mark" <mark.powell2@xxxxxx>
- To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 23 Mar 2010 14:54:01 +0000
By why should you need to know where the database data files were so you can
manually set the file locations via SET NEWNAME in order to perform recovery.
A recovery operation should basically be an automatic idiot proof operation.
By default every file should automatically be copied back to the source files
full path location when you perform an rman recovery. Only if you need to
relocate the database should you have to deal with SET NEWNAME.
I have never liked OMF though I understand why Oracle created the feature, but
if you are thinking of using OMF I would go with ASM instead. Otherwise I
would name the files manually.
Just my opinion and the choice really probably does not matter so long as you
understand the backup and recovery requirements for your choice.
-- Mark D Powell --
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Tim Gorman
Sent: Monday, March 22, 2010 4:34 PM
To: toon.koppelaars@xxxxxxxxxxx
Cc: sacrophyte@xxxxxxxxx; ORACLE-L
Subject: Re: Downsides to OMF?
Toon,
>> The issue now is when you perform a restore (through RMAN). The restore will
>> put all files at the 'mount point' that the init.ora parameter is currently
>> pointing at.
Are you quite sure of this? Isn't this functionality associated with the SET
NEWNAME ... TO NEW command commonly used in migrating into/from ASM using RMAN?
I've found that if you do a simple RESTORE (without SET NEWNAME ... TO NEW),
then OMF are restored back into the locations in which they were originally
created, just like "manually-managed" datafiles.
Thanks!
Tim Gorman
consultant -> Evergreen Database Technologies, Inc.
postal => P.O. Box 630791, Highlands Ranch CO 80163-0791
website => http://www.EvDBT.com/
email => Tim@xxxxxxxxx<mailto:Tim@xxxxxxxxx>
mobile => +1-303-885-4526
fax => +1-303-484-3608
Lost Data? => http://www.ora600.be/ for info about DUDE...
Toon Koppelaars wrote:
Here's a thought that pops into my mind, having used it once (and never
thereafter).
Set db_file_create_dest once, and once only.
Never change it.
Allthough it's a parameter that can dynamically changed. I wish they hadn't
done that.
The trap with that is:
- you want to create another tablespace.
- but rather have it at a different 'mount point' (ie. db_file_create_dest
value).
- so you alter system set db_file_create_dest = .... scope = ....;
- and create the other tablespace.
The issue now is when you perform a restore (through RMAN). The restore will
put all files at the 'mount point' that the init.ora parameter is currently
pointing at.
On Mon, Mar 22, 2010 at 7:28 PM, Charles Schultz
<sacrophyte@xxxxxxxxx<mailto:sacrophyte@xxxxxxxxx>> wrote:
Good day, list,
We are holding an internal discussion about the pros and cons of using
Oracle-managed files. In trying to gauge what Real World DBAs have concluded, I
am finding a lot of google hits that basically parrot the mantra put forth by
the Oracle Documentation. Basically, from what little exposure we have had and
what little I can find online, the major disadvantage of using OMF can be
boiled down to:
1. non-human-sensical names
2. Oracle related bugs (*gasp*)
Is that it? Has anyone ever run into a situation where they were using OMF and
thought, for a second, "Man, this would be so much easier if I had
manually-managed files!"?
Note that I am not concerned about ASM/RAC in this context - that adds a lot of
spice to this discussion that I'll get into later. *grin*
--
Charles Schultz
--
Toon Koppelaars
RuleGen BV
Toon.Koppelaars@xxxxxxxxxxx<mailto:Toon.Koppelaars@xxxxxxxxxxx>
www.RuleGen.com<http://www.RuleGen.com>
TheHelsinkiDeclaration.blogspot.com<http://TheHelsinkiDeclaration.blogspot.com>
(co)Author: "Applied Mathematics for Database Professionals"
www.RuleGen.com/pls/apex/f?p=14265:13<http://www.RuleGen.com/pls/apex/f?p=14265:13>
-- //www.freelists.org/webpage/oracle-l
Other related posts:
