 |
Write
10,000 lines of code in 10 minutes!
Iron Speed Designer – Free
Evaluation |
|
01.10.06
Microsoft SQL 2000 Disaster Recovery
 By
Efrat Levi
Designing a disaster recovery system requires planning and consideration of the available options that will best fit your company's needs, SLA and budget.
With SANRAD DR Solution there is no need to use Log shipping (which requires extra recovery steps) or Microsoft SQL's built in replication mechanism (which requires the configuration of a publisher and a subscriber). SANRAD DR makes the data and transaction log available to the SQL server on the remote site for immediate use. Even if there is no SQL server on the remote site, once built after a disaster, it will be able to access the data immediately with minimum recover time. SANRAD DR solution is a "hot standby solution" when there is a server on the remote site and a "warm standby solution" when there is no SQL server on the remote site (which will be built after a disaster). This guide will help you design a Disaster Recovery plan for Microsoft SQL 2000. The guide assumes that you have basic knowledge of SANRAD V-Switch and MSSQL 2000 Administration.
Disaster Recovery Planning For Microsoft SQL 2000
This section discusses both general and MSSQL specific considerations that need to be addressed when designing a disaster recovery solution combining and Microsoft SQL 2000.
General Considerations
A solution allows for flexibility with Microsoft SQL 2000 disaster recovery design. The most influential factors affecting design consideration are:
* Budget limitations
* Recovery Time Objective (RTO) requirements (the time until the data is back online)
* Recovery Point Objective (RPO) requirements (the amount of data that can be lost)
* Network bandwidth between the local site and remote site
* Replication method: Synchronous versus Asynchronous
* Replication frequency (only for Asynchronous replication)
* Initial volume synchronization
RTO (Recovery Time Objective)
* With high level RTO, duplicate hardware is required to allow quick recovery making the solution more costly.
RPO (Recovery Point Objective)
RPO requirements are best defined by the amount of data that the company is willing to lose.
* High level RPO requires more bandwidth for both Synchronous and Asynchronous replication.
* Low level RPO requires less frequent replication and smaller bandwidth.
Network Bandwidth between the Local and Remote sites
Bandwidth between the sites is generally the most crucial factor affecting the replication component of a solution.
* T1 (1.5Mb) links impose less frequent data replication and the use of asynchronous replication methods.
* T3 (45Mb) links or a 1Gb links allow frequent replication and the flexibility to choose between synchronous replication or asynchronous replication methods.
Write
10,000 lines of code in 10 minutes!
Iron Speed Designer – Free
Evaluation |
|
Replication method
When considering which replication method to choose it is important to remember:
* In Synchronous Replication the I/O commands are written to the local disk and to the remote volume at the same time. Every IO command requires an acknowledgment from both the local and remote sites before the next command. Consequently, synchronous replication is best deployed with a high bandwidth connection in order to allow the remote acknowledgment to arrive back to the local site as fast as possible and the replication can run faster.
* In Asynchronous Replication the I/O commands are written to the local volume and local journal volume which in turn is replicated periodically to the remote volume as periodically defined by the user. Consequently asynchronous replication can work well with lower bandwidth (minimum recommended for Microsoft SQL 2000 replication is 1.5 Mb).
Read the Rest of the Article.
About the Author:
This article deals with designing a disaster recovery system while planning and considering the available options. It further discusses about suggested Disaster Recovery Designs, fully Mirrored Remote Site, partially Mirrored Remote Site, small Remote Site, combining SANRAD Disaster Recovery Designs with Microsoft SQL 2000 Disaster Restore Models, restore Microsoft SQL 2000 with a Standby Server and restore by Rebuilding Microsoft SQL 2000 Server. For further reading click here. |
