Re: Database snapshot cloning and lockfiles
Date: Wed, 8 Apr 2015 14:45:29 -0500
Message-ID: <CAHJZqBBZq=mTQe0p1y9uxp1g3pRpvwYQ-kcKWZmBJBk+ofWTtw_at_mail.gmail.com>
I was thinking of the catalog and switch. I'll see how that goes.
However that wouldn't work with the online redo logs, would it? We snapshot clone datafiles and online logs, then bring the clone up, let crash recovery run and then we're open for business (but then yes we run NID).
Don.
On Wed, Apr 8, 2015 at 2:20 PM, Ludovico Caldara <ludovico.caldara_at_gmail.com
> wrote:
> Hi Don,
> I haven't tested it, but can you try to use the new files with a RMAN>
> catalog '...'; (or catalog start with '...%') and then do a switch database
> to copy?
>
> Don't forget to run also the nid to change the DBID (and db_name,
> eventually), before registering it into a rman catalog.
>
> Cheers
> --
> Ludo
>
> 2015-04-08 20:46 GMT+02:00 Don Seiler <don_at_seiler.us>:
>
>> So one workaround I was able to do (again, thanks to Bradd for the tip)
>> was to mount the cloned controlfile (as opposed to creating a new one) and
>> then run ALTER DATABASE RENAME FILE on everything to point to the new
>> locations (via a script generated from the source). Interestingly enough,
>> starting the DB and mounting the cloned controlfile didn't create a
>> lockfile name conflict, it used the new name just fine. It's only when I
>> CREATE a new controlfile that Oracle seems to forget the db_unique_name.
>>
>> The problem with the workaround is that I'm using OMF (ASM). When this
>> happens, Oracle tries to delete the old file when you do a RENAME. Since
>> I'm cloning on the same server, the cloned database has visibility and
>> access to the source files. Thankfully it couldn't delete them since the
>> source database was still open. Marcin P. wrote about this same problem a
>> few years ago on his blog:
>> http://oracleprof.blogspot.com/2010/05/rename-file-and-baag.html
>>
>> I tried "disabling" OMF in the cloned instance by unsetting the
>> db_create% and db_recovery% parameters but it still tried to delete those
>> files. I'd be interested to know if anyone knows of a way to prevent ALTER
>> DATABASE RENAME FILE from trying to delete OMF files.
>>
>> Don.
>>
>> On Tue, Apr 7, 2015 at 11:53 PM, Don Seiler <don_at_seiler.us> wrote:
>>
>>> Yes of course we can clone to a different machine, and we will for other
>>> cases. But in this case we want to be able to perform snapshot clones of
>>> small unit test databases onto the same host. Even having a separate
>>> ORACLE_HOME for each one would start to get out of hand.
>>>
>>> Bradd has also suggested a different workaround to the problem, I'll
>>> test it out and share it after I get it nailed donw.
>>>
>>> On Tue, Apr 7, 2015 at 7:46 PM, Mladen Gogala <
>>> dmarc-noreply_at_freelists.org> wrote:
>>>
>>>> On 04/07/2015 05:13 PM, Don Seiler wrote:
>>>>
>>>>> Bradd "Eagle Eye" Piontek was able to duplicate this issue, and then
>>>>> found bug 5951527 in MOS, an old 10g bug that's never been fixed. I've
>>>>> created an SR and referenced it as well. The workaround of shutting down
>>>>> the original instance defeats the whole point of doing the online snapshot
>>>>> of course.
>>>>>
>>>>> Don.
>>>>>
>>>>>
>>>> Is there a possibility of cloning to a different machine? That seems
>>>> like a good solution, to avoid this issue completely. Or, if it must be the
>>>> same machine, how about creating another ORACLE_HOME?
>>>>
>>>>
>>>> --
>>>> Mladen Gogala
>>>> Oracle DBA
>>>> http://mgogala.freehostia.com
>>>>
>>>> --
>>>> http://www.freelists.org/webpage/oracle-l
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Don Seiler
>>> http://www.seiler.us
>>>
>>
>>
>>
>> --
>> Don Seiler
>> http://www.seiler.us
>>
>
>
-- Don Seiler http://www.seiler.us -- http://www.freelists.org/webpage/oracle-lReceived on Wed Apr 08 2015 - 21:45:29 CEST