Re: Database snapshot cloning and lockfiles

From: Don Seiler <don_at_seiler.us>
Date: Tue, 7 Apr 2015 13:24:55 -0500
Message-ID: <CAHJZqBCOy=iFsv1TtZMDmjTM3iSb-XNoKH=Q4GRSQNJ=0SVY4w_at_mail.gmail.com>

And to clarify, the DB_NAME is identical in both databases. The CREATE CONTROLFILE command uses the same DB_NAME as well, otherwise Oracle would complain when it tried to open the snapshot-cloned datafiles.

The DB_UNIQUE_NAME and ORACLE_SID are different. So the question remains: Why is this instance using the TEST1 name in the lk file, when I would (reasonably) expect it to use the CLONE1 name used in both the DB_UNIQUE_NAME and ORACLE_SID.

Don.

On Tue, Apr 7, 2015 at 1:18 PM, Don Seiler <don_at_seiler.us> wrote:

> At first I thought it used the SID as well, but looking at other "lk"
> files for other databases using the same home, it is definitely using the
> db_unique_name in those cases. Those cases are for standby databases that
> would share the same db_name.
>
> We aren't using NFS here, for what it's worth. All storage used here is
> fibre channel connected. I'll give the note a read though.
>
> Thanks very much for the reply!
>
> Don.
>
> On Tue, Apr 7, 2015 at 1:14 PM, Seth Miller <sethmiller.sm_at_gmail.com>
> wrote:
>
>> Don,
>>
>> I think it uses the SID for the lock file but since you are using a
>> different SID and db_name, my guess is that you are seeing a symptomatic
>> error message being caused by something else.
>>
>> I have run into a similar issue in the past and the problem turned out to
>> be NFS locks, rather than database file locks. Check note 236794.1.
>>
>> Seth Miller
>>
>> On Tue, Apr 7, 2015 at 11:10 AM, Don Seiler <don_at_seiler.us> wrote:
>>
>>> Oracle 11.2.0.3 on RHEL 6.3 x86-64.
>>>
>>> Testing out a process to do snapshot clones of databases onto the same
>>> host. These snapshot the datafiles and online logs with a crash-consistent
>>> snapshot, so the clone should just be able to more or less fire up and
>>> perform online recovery and go.
>>>
>>> The disk cloning works fine, but setting up the new instance is running
>>> into some hurdles. In the pfile for the new instance, I keep the db_name
>>> the same as the original instance, setting a new db_unique_name. Obviously
>>> I use a new ORACLE_SID as well. In new CREATE CONTROLFILE script, I use the
>>> same name as the original as well since it is stamped into the DB file
>>> headers.
>>>
>>> In my example, the original DB is TEST1 and the clone is CLONE1 (set for
>>> both db_unique_name and ORACLE_SID).
>>>
>>> However, when I run the controlfile script, it complains about the
>>> $ORACLE_HOME/dbs/lkTEST1 file already being locked (which it is, by TEST1).
>>>
>>> sculkget: failed to lock /oracle/app/product/11.2/dbs/lkTEST1 exclusive
>>> sculkget: lock held by PID: 46780
>>> ORA-09968: unable to lock file
>>> Linux-x86_64 Error: 11: Resource temporarily unavailable
>>>
>>> I'm curious why it is using the "TEST1" name for the lockfile. For other
>>> databases on this host, it seems like it is using the db_unique_name value,
>>> so I would expect it to use a name like lkCLONE1. The alert log clearly
>>> shows the db_unique_name is set on instance startup into nomount mode.
>>>
>>> db_name = "test1"
>>> db_unique_name = "clone1"
>>>
>>> Don.
>>>
>>> PS - I can't do the CREATE CONTROLFILE SET DATABASE here to rename it
>>> since that requires RESETLOGS and then I lose the advantage of having my
>>> online redo logs in a crash-consistent snapshot (which requires no downtime
>>> of the source database).
>>>
>>> --
>>> 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

Received on Tue Apr 07 2015 - 20:24:55 CEST