[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference decwet::winnt-clusters

Title:WinNT-Clusters
Notice:Info directories moved to DECWET::SHARE1$:[NT_CLSTR]
Moderator:DECWET::CAPPELLOF
Created:Thu Oct 19 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:863
Total number of notes:3478

738.0. "[DEC Cluster] Strange Cluster Problem with SQL" by ALFAM7::SIEBOLD (Thomas, TSO Munich - ALPHAholics can not be VAXinated!) Fri Apr 11 1997 11:24

the following was encountered during the demonstartion of a Digital WNT Cluster
at CEBIT97 on Microsoft's Backoffice booth. They demonstrated SQL and SQL
failover on our cluster at this fair.

Assume 2 Alphaservers running NT V4.0 with SP2 and Cluster V1.1 (final).
They are connected to a RAID310 with 2 raidsets. Both servers run SQL server,
each SQL server is primary for a database on the respective raidsets. One of 
the servers has a database (bench) local (not on a shared drive.

The promoter usually demonstrated SQL access from the client through ISQL and
through access from EXCEL and ACCESS. Sometimes he ran a benchmark program
to the local DB. Whenever he showed SQL failover there was no other access
active.

So what happened was:

After several failovers all of a sudden (but reproducable at will after 2-3
failovers) one of the DBs on the shared devices appeared TWICE in Enterprise
Manager on one of the systems. The DBs even appeared twice in the manage
SQL DBs applet from Clusteradmin! They also appeared twice in the output when 
you do the sp_fallback_help.
To repair we rebootet the system where the database where appearing twice,
which fixed the situation.

I know this sounds rather odd, but it really happened regularly.

I have collected:
			SQL error log file
			the event log file
			the sp_fallback_help output
			the cluster trace log
			the select * from sysdatabases output

from both systems.

I will not include it here but will send it from my exchange system directly to
Carl, Will, and Donna.

Thanks
	Thomas
T.RTitleUserPersonal
Name
DateLines
738.1Same thing happen to me !!NNTPD::"Eddy.Wang@hgo.mts.dec.com"HKTSSun Apr 20 1997 17:169
This also happen to my Cluster setup!   I have encountered same problem
during my demo to customer.  

Somebody pls help us out and just tell me what leads to the problem!

Rgds,
:| 
[Posted by WWW Notes gateway]
738.2ALFAM7::SIEBOLDThomas, TSO Munich - ALPHAholics can not be VAXinated!Mon Apr 21 1997 13:557
A status/problem solution update would be appreciated.

If you need more data ( I have sent all the eveidence I have to Donna, Carl and
Will.

Thomas
738.3LJSRV1::BOURQUARDDeb Walz BourquardTue Apr 22 1997 19:358
I tested this scenario today manually failing over a
group which contained 2 enrolled SQL Server databases 
~7 times and did not see a database name duplicated.

I was testing with the V1.1SP1 FT kit.

Thus, if this problem was truly readily reproducible,
then I believe it is fixed in the current FT kit.
738.4ALFAM7::SIEBOLDThomas, TSO Munich - ALPHAholics can not be VAXinated!Wed Apr 23 1997 11:1514
Deb,

did you try it with:

	- an open ACCESS or EXCEL connectioan via ODBC?
	- a batch file running on a client doing a SQL query in an endless loop

According to Carl ( he has the query command file and has analyzed the problem)
SQL server was not able to 'shutdown' a client connection (being bombarded by
the endless loop from the client, and failover manager didn't care whether  SQL
server was 'ready' for failover. It just did it!

thanks
	Thomas  
738.5LJSRV1::BOURQUARDDeb Walz BourquardWed Apr 23 1997 14:0011
Thomas,

No, I didn't try it the way you described in .4.
I just checked the PTR database but was unable to
quickly find which PTR matched the problem you've
described.  

I think I should quietly bow out of this conversation and
let Davis or Carl provide the real answer...

- Deb