|
The uniqueness problem stems from duplicate vstart and/or dbid entries
in the spt_fallback_* tables.
Look at the spt_fallback_db,_dev and _usg tables to see if there are
old entries pertaining to your test database.
select * from spt_fallback_db
select * from spt_fallback_dev
select * from spt_fallback_usg
The easiest way to clean out the spt_fallback_* tables is to rebuild
the master database. Once you do that, rebuild your sales database on
the shared storage and enroll it via the cluster administrator running
on the machine that is the primary machine for the database/group.
After you enroll it, if you issue the above queries again, you should
only see references to the sales database.
|
|
If you don't have the luxury of being able to rebuild the master
database, you could try removing the bogus spt_fallback* table entries
by "withdrawing" the bogus database from fallback support.
1) Make sure the primary server owns the database/group
2) On the secondary server, issue the following:
sp_fallback_withdraw_svr_db PrimaryName, Dbname
3) On the primary server, issue the following:
sp_fallback_DEC_perm_svr_db PrimaryName, Dbname
The sp_fallback_DEC_perm_svr_db procedure gets installed with Clusters
for NT.
If you look at the spt_fallback* tables now, the bogus entry should be
gone.
If you're still having the problem, rebuild the master database and
you'll most likely have to re-install Clusters for NT (if the original
test database was deleted and un-enrolled out of the proper sequence,
there may be some remnants in the cfmd database).
|