Re: Database snapshot cloning and lockfiles

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
>

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