We are using W2k, SQL2K, clustered, active-active.

We have setup a new clustered sql environment. I am
migrating databases and wondering what will happen if we
create an alias in DNS which has the old virtual sql
instance name associated with the new virtual sql instance
IP address. The hope is to avoid connection string
modification.

Anyone sees any issues? Thanks.

Claudia

Assuming you are using MS DNS, the name/IP is
automatically registered in DNS. From a cluster/DNS
perspective, this is right. Now if you create a new name
(alias) in DNS with the same IP, it should be OK, but I
can't guarantee that. It should since it's resolving down
to the IP level, but you never know.

The reality is that applications, esp. ones that should be
highly available, need to handle this sort of thing. What
if you were using log shipping? It would be a different
server name altogether.

An alias record won't work since all it can specify is an IP address. You
will need to create a service recond in DNS with both the IP address and
Port number (Use the Server Network Utility to specify a port for the
instance). This is what SQL does automatically, but you will have to do it
manually with the alias name. Setting the clustered instance to 1433 won't
work, even though there is no default instance on the virtual server IP. It
seems that MDAC knows the instance isn't the default so it won't let you
connect without an instance name or port specifier.

--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com




"Allan Hirt" <allanh (AT) NOSPAMavanade (DOT) com> wrote

If I understand you correctly, you want to continue to use
your old virtual server name from the client side. If you
are using the fully qualified domain name plus a port
number in your connection string, you can certainly
continue to use that connection string, assuming that
(1) the old virtual server name (FQDN) is not used
elsewhere,
(2) the FQDN (i.e. your alias) is mapped to the IP address
of the new virtual server

This actually has nothing to do with server clustering.
Note that if you use FQDN plus the port number, you are
not going to use any SQL instance name. In this case, the
SQL instance is totally transparent to the client as far
as connection string is concnerned. Your client will
connect to the correct instance by using the correct port
number for that instance.

If you use the FQDN plus the port number, the only thing
you would notice about server clustering is that each
instance would have a different IP address, whereas in a
standalone situation all the instances on the same machine
would have the same IP address(es) with different port
numbers.

Linchi

Don't know if this adds anything useful but the way we use
DNS aliases is as follows.

Our database connections are primarily made through ODBC.
None of our ODBC configurations use server names. Instead
they use fully qualified DNS aliases. That is, instead of
the server being referred to as

ldnsqlserver01\product1instance

it's referred to as

product1server.ourdomain.com\product1instance

product1server is the DNS alias to ldnsqlserver01 and, as
you can see, we can tag the instance name to the end of
it. We don't need to hard code port numbers.

Our log shipping occurs to our disaster recovery server
which is drsqlserver01\product1instance

The important requirement here is that the instance name
is the same as that for our primary site. In our case the
port number can be different as we address the instance
through its name.

Now when a disaster hits none of our client ODBC configs
need to change. Our network admins simply swing the DNS
alias to the dr server.

If your apps address the server through ports, then on the
dr server you configure not just the instance name to be
the same as your primary site but also the port.

--
Nayan

I should add that specifying the instance name on the end
of the server name only works for MDAC 2.8. For previous
versions I've had to specify IP as the protocol and the
port number.