We don’t change the DB_NAME on the snapshot - just the instance name.
The scripted process at a high level does the following:
1. Cancel media recovery on the standby.
2. Backup the controlfile from the standby to a location visible to the
snapshot host.
3. Take the snapshots for the database file directories from the standby.
4. Start media recovery on the standby.
5. Startup the snapshot nomount.
6. Set the control_files parameter to the controlfile backup taken in 2. above.
7. Mount the snapshot database.
8. Add new redo log file groups that are in the snapshot db filesystems.
9. Active the snapshot db - using ‘alter database activate standby database’.
10. Open the snapshot database.
The instance name is different for the snapshot - but all else the same.
When we used to snapshot on the same host as the standby the process was
different - more renaming of files etc.
Using this approach - different host, same db_name, different instance_name is
certainly the most straight forward way of doing this for us.
Regards,
Mark
On 6 Oct 2015, at 5:25 AM, Don Seiler <don@xxxxxxxxx> wrote:
Ironically now, when I take the method we have for creating a new controlfile
and apply it to cloning from a primary database, it tells me that datafile 1
needs more recovery when I try to open resetlogs. I even tried putting the
primary into backup mode first just to see if that was it, but I got the same
error. All the online redo logs were in the same snapshot as the datafiles
(same protection group), but it doesn't seem to want to use them. No
errors/complaints from the CREATE CONTROLFILE statement.
The one thing that I'm curious about is that we ARE changing the DB name in
the CREATE CONTROLFILE statement. Would that impact our ability to use the
online redo logs that were snapshotted?
Don.
On Mon, Oct 5, 2015 at 11:54 AM, Jeremy Schneider
<jeremy.schneider@xxxxxxxxxxxxxx <mailto:jeremy.schneider@xxxxxxxxxxxxxx>>
wrote:
On Fri, Oct 2, 2015 at 3:32 PM, Don Seiler <don@xxxxxxxxx
<mailto:don@xxxxxxxxx>> wrote:
Jeremy, I'm curious why a backup primary controlfile would work when
recreating a controlfile would not. We've tried the latter and that's when
it said we had incomplete media recovery. Why would the backup primary
controlfile not also have the same issue?
On Mon, Oct 5, 2015 at 10:56 AM, Don Seiler <don@xxxxxxxxx
<mailto:don@xxxxxxxxx>> wrote:
Seth, that did appear to work now when I create a new controlfile. I'll see
how best to script that part of it.
Glad to hear it started working! I couldn't think if any reason that a
create controlfile shouldn't work. Just was pointing out that the
primary controlfile backup works routinely for me to avoid the issue
with standby controlfile backups.
-J
--
http://about.me/jeremy_schneider <http://about.me/jeremy_schneider>
On Fri, Oct 2, 2015 at 2:26 PM, Don Seiler <don@xxxxxxxxx
<mailto:don@xxxxxxxxx>> wrote:
To answer your question, no we didn't try the copy-controlfile-from-prod
method. I'll look into that.
Don.
On Fri, Oct 2, 2015 at 1:56 PM, Don Seiler <don@xxxxxxxxx
<mailto:don@xxxxxxxxx>> wrote:
In 11.2 I used to be able to mount the clone, and if the controlfile was
a standby I would just backup the controlfile and restore it from that
backup and (voila) it would now be a primary. That doesn't seem to be the
case in 12.1 now. Not sure if that alone is at the root of the problem.
I was hoping to avoid having to connect to any source databases for this,
but maybe there's no away around it. It would have been cleaner to just be
able to snapshot from the storage array and do all the work from the
cloned
instance.
Don.
On Fri, Oct 2, 2015 at 12:43 PM, Jeremy Schneider
<jeremy.schneider@xxxxxxxxxxxxxx
<mailto:jeremy.schneider@xxxxxxxxxxxxxx>> wrote:
On Fri, Oct 2, 2015 at 12:36 PM, Don Seiler <don@xxxxxxxxx
<mailto:don@xxxxxxxxx>> wrote:
ORA-01511: error in renaming log/data files
ORA-00261: log 52 of thread 1 is being archived or modified
well it's nice to hear that this problem still exists in 12c - i'm
very aware of it in 11.2.0.3
it's because the software isn't really able to handle the standby log
which is currently active. i have run into the exact same issue doing
a "recover datafile" on a clone which was created using a backup
controlfile from the standby. in my case, i simply used the backup
from the primary (and changed nothing else) and i don't have the
issue.
So we go to plan B, which is to try to create a new controlfile. The
new
CREATE CONTROLFILE script doesn't specify the standby redo logs.
ERROR at line 1:
ORA-01196: file 1 is inconsistent due to a failed media recovery
session
ORA-01110: data file 1: '/file/name/here.dbf'
Every variation of this that we've tried fails similarly.
So you did also try taking a backup of the primary controlfile and
restoring this into the standby, then renaming all your logfiles and
datafiles to match the new locations? That has worked for me on 11203
for avoiding the error you mentioned above.
-J
--
http://about.me/jeremy_schneider <http://about.me/jeremy_schneider>
--
Don Seiler
http://www.seiler.us <http://www.seiler.us/>
--
Don Seiler
http://www.seiler.us <http://www.seiler.us/>
--
Don Seiler
http://www.seiler.us <http://www.seiler.us/>
--
Don Seiler
http://www.seiler.us <http://www.seiler.us/>
