[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

650.0. "need help with "Enroll" proceedure" by LEXS01::lexser2.lex.dec.com::lombardi (PCBU Technical Support) Fri Feb 21 1997 17:46

When setting up a SQL database with 1.1 using the "enroll" function, I am 
having a problem.. It does all of the "stuff" in the backround but it 
doesn't set up the the SQL Server as the fallback server. In other words, 
the database that I set up doesn't appear as "gray" and "standby.

I think I know the problem.
When I create the Failover Group(before the database is created), I'm 
calling the Failover Group a different name than the database. The reason 
that this is suspect is that when the enroll proceedure runs, it 
automatically creates a database with the name of the "Failover Group". I 
believe this why I can't do the failover.

Can someone explain how the "Enroll" proceedure is supposed to work.

Thanks in advance,



...chuck

T.R	Title	User	Personal Name	Date	Lines
650.1	Hi Chuck	DECWET::DGOODMAN		`Fri Feb 21 1997 23:47`	11
	The first time you enroll a database, if there is no sql object in the group the FMSQL.dll creates a Sql object with name of the group. What do you mean by gray and standby. When a database is enrolled it will show up on one sql server's master database but not the other. With the Beta V1.1 kit you must create a dummy object so that FMSQL.dll knows the password for the Sql Servers. Don't put the dummy object in any group. Were you able to successfully enroll the database? The sp_fallback_help stored procedure will verify this. Donna
650.2	here's the scoop ...	LEXS01::lexser8.lex.dec.com::lombardi	PCBU Technical Support	`Sat Feb 22 1997 19:28`	42
	Donna, I did all of that. The failover works as far as the Cluster Software is concerned. I know this because if I go into the registry and check the "connection point" when I fail over the "failover group" that contains the Disk and Database, it appears on the correct server and vice versa when I fail it back. It's the SQL part of this that doesn't appear to be working. If I log in from a ISQL client thru named pipes (e.g. \\cluster alias\pipe\database\query)or a socket connection (IP addr), via the cluster alias, it only sees the database if the failover group is on the Primary Server. Once I fail it over, ISQL gives an error message saying connection lost and it never recovers until I fail it back to the Primary Server. Here's the steps I followed: ====================================================== - SQL (w/SP1) installed before Clusters 1.1 installed - Installed Clusters 1.1 on 4.0 (w/SP2) - Created Failover group with nothing in it! - Created SQL database on Primary - Populated it with "pubs" db - Opened mange SQL databases from Cluster Admin - The database appeared as Unenrolled - Clicked on enroll(it did it's thing) - Database showed up as a New SQL Failovergroup(with the name of the Failover Group that I created) - The failover group now contained the new SQL Failover object created as a result of the "Enroll" proceedure - Created dummy SQL object. - Everything looks great! I configured the ISQL Client connect via Named Pipes and couldn't keep the connection when I manually failed over the database. I must have missed a step along the way. Any help would be greatly appreciated. Thanks in advance, ...chuck
650.3	Client needs to reconnect after failover	DECWET::CAPPELLOF	My other brain is a polymer	`Mon Feb 24 1997 17:28`	6
	ISQL does not keep the connection. When a failover occurs, you have to reestablish the connection. ISQL/W seems to be better about this. I'll have more comments on your setup soon.
650.4		DECWET::DGOODMAN		`Mon Feb 24 1997 18:27`	7
	How are you configuring the sql client. Is the named pipe connection via the server name or are you using the sql client configuration utility to create an alias for the group. The group name will be part of the pipe. I didn't see anything about creating an IP object for socket failover?
650.5	What "enroll" does.	DECWET::CAPPELLOF	My other brain is a polymer	`Mon Mar 03 1997 14:19`	39
	Ok, here's how "enroll" works - You create a group called "Failover Group" with some disks in it. (Say "disk1" and "disk2"). This group and its disks come online on "ServerA". On the system where "disk1" is online ("ServerA"), you create an SQL "device" on "Disk1" and create an SQL database "db1" on this "device". Now you run the cluster admin GUI and select "manage databases". YOu should see "db1" is not enrolled. You push the button to enroll it. Cluster software executes the following stored procedure on BOTH ServerA and ServerB - sp_fallback_enroll_svr_db 'ServerA', 'db1' The above step creates new rows in the spt_fallback_xxxx tables on both servers. SQL Enterprise admin shows "db1" online on ServerA, and does not show anything about "db1" on ServerB. Cluster software also creates an SQL failover object called "Failover Group" for use by the SQL failover DLL. It puts this failover object into the group called "Failover Group" (Yes, it's confusing to have two things with the same name. ONe is a "group" object and the other is an "SQL" object.) Within this SQL failover object, cluster software records the name of the database on the shared disk ("db1"), and also records the original disk drive letters used when the database was created. When failover occurs, the database is put offline on ServerA and removed from ServerA's online database tables. The database is put online on ServerB, and magically appears in ServerB's online database tables. If you refresh the SQL Enterprise manager display for ServerB, you'll see "db1" online. You should never see SQL Enterprise manager display a database in gray "standby" mode. IN fact, I don't even know what that kind of display means.