|
|
|
|
|
Achieving High Availability - Part 2 1 2 3 4 5 When bringing the cold standby on-line, use common sense. If you have 5 databases that need to be running, get them function and open for production in order to priority. You will always have one database that takes priority over the others. If this is not readily apparent, make the business decide what that priority should be. You then bring the databases on-line in that order. Don't try to simply restore and verify all databases and then open it for production. Get the top priority database on-line and then turn to restoring the rest. This gets some of the people up and running and relieves some pressure. It also gets the rest of the users settled down, because they see something is occurring.The second way you can bring a cold standby on-line is covered in my disaster recovery plan. This process involves swapping the drive arrays from the production server to the standby server. This process requires that the drive arrays are still intact and functional. (This is rarely the case as drive failures will normally precipitate failing over to a standby.) I have only seen this done with Compaq hardware. I can not say this will work with hardware from any other manufacturer as Compaq is the only server manufacturer I'm aware of that integrates and standardizes their server hardware enough to do this. A warm standby is a server has two primary characteristics.
A warm standby server will have NT and SQL Server installed. Both will be on the same service pack level as the production system. With the exception of physical hardware differences, it will have the same configuration as the production server. All logins and jobs/tasks defined on the production server will also be defined on the warm standby. You will normally implement a policy to create logins on both the production and standby server at the same time when a new login is added. (Many people want to create triggers on the system tables to accomplish this. This approach will not work since triggers on system tables do not get fired.) Each time a configuration option is changed on the production server, you will also change it on the standby server to a appropriate setting. When databases are created on the production server you will also create them on the warm standby. In short, every time you perform an action on the production server with the exception of inputting data, you will perform the equivalent operation on the warm standby. The warm standby should be connected to the production server via a dedicated, high speed link. Many people will place a warm standby next to a production server and link them directly through a second NIC. There isn't any problem with this. If you have the luxury, place the warm standby in another room or building still joined through a dedicate, high speed link so that you are protected from a physical disaster in your server room. The next thing that you do is to implement and test a solid backup plan. You will apply the backups to the warm standby as they are created in order to keep it up to date. The main driver are your tran log backups. I prefer to use a dedicated backup server when it is feasible. This backup server is nothing more than a large storage array. To maintain the warm standby, you would perform the following operations:
If you are not running SQL Server 7.0, you will not be able to perform differential backups. |
All content on this site, except where noted, represents an original work of Michael R. Hotek and is protected by applicable copyright laws. The SQL Server FAQ is the sole work of Neil Pike. No page, portion of a page, or download may be used for commercial purposes in whole or in part without the express, written permission of the applicable author.