Re: Downsides to OMF?
- From: TESTAJ3@xxxxxxxxxxxxxx
- To: "wbfergus" <wbfergus@xxxxxxxxx>, "sacrophyte" <sacrophyte@xxxxxxxxx>
- Date: Mon, 22 Mar 2010 18:56:51 -0400
There was at one time a document that helps complete a failed duplicate at just
abouit any point, check metalink for it
Joe
Sent from the crackberry, so please excuse the typos and terseness.
----- Original Message -----
From: Bill Ferguson [wbfergus@xxxxxxxxx]
Sent: 03/22/2010 01:59 PM CST
To: sacrophyte@xxxxxxxxx
Cc: Toon Koppelaars <toon.koppelaars@xxxxxxxxxxx>; ORACLE-L
<oracle-l@xxxxxxxxxxxxx>
Subject: Re: Downsides to OMF?
This discussion came at a rather opportune time for me. I am in the
process of trying to figure out how to duplicate my database across 3
other machines (which are Windows Server machines), where the disk
layout is completely different on each one.
On my latest rman duplicate run, after 23 hours it finally died with
the following message:
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
WARNING: OMF is enabled on this database. Creating a physical
standby controlfile, when OMF is enabled on the primary
database, requires manual RMAN intervention to resolve OMF
datafile pathnames.
So, now I'm trying to figure out what I need to do to manually finish
the process, or if there is something I simply add to the end of the
script (to make it easier to duplicate to the other machines as well).
This is a bit off topic, but it seems to be one disadvantage to OMF.
--
-- Bill Ferguson
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
