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@xxxxxxxxx> 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@xxxxxxxxx>
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@xxxxxxxxx> 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
