Achieving High Availability - Part 2 1 2 3 4 5

So we've now determined that you have purchased quality hardware, your server room is laid out properly, and your applications have been tuned to make them extremely stable.   If you haven't accomplished all of this yet, a standby can help.  But, it will just be covering up existing problems.

Standby servers are set up three ways: cold, warm, and hot.

A cold standby server is a server that will require a significant amount of time during fail over to bring on-line.  This server is normally tasked with some other noncritical function in your environment and will function temporarily as the primary server.  You might choose to simply reserve a server as a cold standby and not have it perform other functions, but this is rare.

A cold standby will normally not contain any of the databases from the primary.   It might not even have SQL Server installed.  It will have NT installed otherwise it would not be ready to perform any function in the environment.  These servers are also normally powered off.  If you are using a cold standby, I would suggest having it already preconfigured with the appropriate software in order to ease the fail over.  Cold standbys are usually much smaller than the primary production servers.  An example of a cold standbys is a Compaq 3000.  These servers also do not carry the full storage capacity of the primary production servers.  (Or no storage at all.)

A cold standby is normally marked by two processes that must be performed during failover.  The first one is to power on the server. The second one is to restore a full database backup.  The need to restore a full backup is what sets this solution apart and marks it as a cold standby.  With the exception of the fail over case I'll cover below, you can call your solution anything you want, but it is still a cold standby is it requires a full database restore a part of the fail over.

Bringing a cold standby on-line is as simple as following the steps below:

1. Power on the server
2. Verify the integrity of the NT and SQL Server installations
3. Restore the databases from the last good backup
4. Apply any transaction log or differential backup
5. Verify the integrity of the data
6. Put into production

It is very common to rename the standby server to match the production server. This makes the failover transparent to applications with the exception of the down time required.  This process involves the following:

• Rename the server
• Change the IP address

You must preplan the name and IP switch for the SQL Server.  If you are running SQL Server 6.5 and earlier, simply change the name and IP address and bring the server on-line.  Unless the server is participating in replication or you are accessing the server name, no other changes need be done before placing the server in production.   If it does participate in replication or you are accessing the server name, you will need to execute sp_dropserver and sp_addserver to change the server name that SQL Server has stored.  SQL Server 7 is a completely different ball of wax.  SQL Server 7.0 has a very irritating feature of binding the server name into the SQL Server installation.  If you rename the server, your SQL Server installation will fail.   There are all kinds of suggestions and registry hacks out there to fix this.   None of them completely fix this problem.  Until  Microsoft releases a server name change utility that picks up everything, the only option that will work all of the time is to reinstall the SQL Server.

Achieving High Availability - Part 2 1 2 3 4 5