Database snapshot cloning and lockfiles

From: Don Seiler <don_at_seiler.us>
Date: Tue, 7 Apr 2015 11:10:08 -0500
Message-ID: <CAHJZqBAODL8YHxcYdGRSN_wpymn53wMFECBjzFy69SkJRoN9DA_at_mail.gmail.com>



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
Received on Tue Apr 07 2015 - 18:10:08 CEST

Original text of this message