Re: Snapshot Thin Clone of Physical Standby

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?

Don.

On Fri, Oct 2, 2015 at 2:26 PM, Don Seiler <don_at_seiler.us> 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_at_seiler.us> 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_at_ardentperf.com> wrote:
>>
>>> On Fri, Oct 2, 2015 at 12:36 PM, Don Seiler <don_at_seiler.us> 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
>>>
>>
>>
>>
>> --
>> Don Seiler
>> http://www.seiler.us
>>
>
>
>
> --
> Don Seiler
> http://www.seiler.us
>

-- 
Don Seiler
http://www.seiler.us

--
http://www.freelists.org/webpage/oracle-l