| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 717.1 | | LJSRV1::GOODMAN | | Thu Mar 27 1997 09:21 | 12 |
| You are get a uniqueness violation. Are there any other databases enrolled?
If so, from the server that has the databases online, unenroll them. You should
then be able to enroll both databases.
If you have failed over the database without enrolling it, the database will be suspect
and if you try to failback the group to the primary the SQL server will hang. So
don't do this.
This is a SQL problem not a cluster problem.
Donna
|
| 717.2 | SQL - Uniqueness Violation | NETRIX::"[email protected]" | Robson | Thu Mar 27 1997 11:31 | 6 |
| There are no other databases on the server. I had created a test database
called "newpub", and I enrolled it with no problem. I then deleted the
devices, database and fail-over group. I created a new fail-over group and a
new database called "sales. This is the database that is getting the
"uniqueness violation". Any suggestions on how to fix this problem?
[Posted by WWW Notes gateway]
|
| 717.3 | | LJSRV1::GOODMAN | | Thu Mar 27 1997 13:37 | 11 |
| What happened is the first database is still in the fallback table.
Deleting a database & device and the failover group in the wrong order
leaves the database in the fallback table with no reference to an
actually database. sp_fallback_help should confirm this.
Try withdrawing the database from the fallback table. If this does not
work you will have to update the master database, install SQL sp1, re-install
the cluster software.
Good luck
Donna
|
| 717.4 | recovering from SQL server hangs etc. | AEOENG::16.40.240.154::annecy::lehy | | Fri Mar 28 1997 12:51 | 18 |
| >If you have failed over the database without enrolling it, the database
>will be suspect and if you try to failback the group to the primary the SQL
>server will hang. don't do this.
primary ? SQL primary or DIGITAL cluster primary ?
Does the primary cluster member has to be primary SQL server for
all SQL dbs in the group ?
How do we recover from the situation described above ?
What can we do it the SQL server hangs ? Can we stop it and
restart it ?
I have seen situations were a DB on shared disk vanished from
the SQL configurations on both cluster members and nevr managed
to recover from such situations.
|
| 717.5 | answers and configuration tips | LJSRV1::GOODMAN | | Fri Mar 28 1997 15:08 | 25 |
|
1.The SQL server that you created the database from and which normally controls
it. There is no digital cluster primary. The Cluster primary server is
defined by failover group policies.
2.All databases in a group (one or more disks possible) will have the same
SQL primary. Each group can have a different SQL primary.
3.Stopping the SQL server will not work. The SQL server will be in an indeterminite
state. You will have to re-boot the server and un-suspect the database.
There are some known abnormalities (good word) in V1.1 and Sp2 FMsql.dll. Because of this
when you create sql databases, create them from one sql server. You can put them in different
groups. After creating the databases enroll them. The next step would be to change
one of the group policies, configuring the other server as the primary for that group. This
is of course if you are configuring dual primary sql servers.
Configuring this way helps with the Uniqueness problem. Fixes for this restrictive configuration
procedure will be available in service pack one for V1.1.
Soon to come, SQL configuration hint and tip for V1.1 and sp2.
DG
|
| 717.6 | the last question answered | LJSRV1::GOODMAN | | Fri Mar 28 1997 15:13 | 4 |
| If the database configured is not seen from either SQL server then "it has not been activated after
a failover" An unenrolled or suspect database might not be activated. Part of the failover process is to
get a list of databases from either the master database active list or the fallback table. For details
on the process look at the FMtracelogs.
|
| 717.7 | How I managed to do it... | MBSVAX::SLOAN | Just Another Manic Monday | Fri Apr 04 1997 06:01 | 18 |
| I too have been struggling with enrolling SQL databases under
V1.1. What I was trying to achieve was a database on seperate disks
serviced by SQL Server on seperate servers. I had scenarios where the
second database was enrolled on the primary server with an unenrolled
copy of it as well, as it being unenrolled on the failover server.
I had another scenario where I had both databases enrolled twice on
both servers!
Eventually I resolved the problem by unenrolling the databases, deleting
them and the devices, then recreate them all again. Enroll the database
on the primary server, then manually failover the second server
failover group and enroll the second database on the primary server,
fail it back and hey presto all is well!!
Hth,
Shaun
|