Hi Eric,
Backup/Restore solution is a better choice. Replication is not a warm
standby solution.
1. Pure Backup/Restore with disk redundancy of data via RAID
Using disk redundancy of data via RAID 0+1 or RAID 5, and performing pure
backups and restores comes as close as possible to insuring that you will
never lose data due to media or hardware failure. The RAID technologies
noted allow for single drive failure and replacement without the server
going offline.
RAID 0+1 uses two identical striped sets of drives that are constantly
updated so that the information stored is the same on both arrays. When one
array fails, the other automatically takes over until the problems with the
original array can be brought back on-line.
RAID 5, also known as striping with parity, uses a single striped drive
array with parity bits written along with the data. When a single drive
fails, the parity bits can be used to calculate the missing data until the
drive is replaced.
At that time, the parity information and remaining data is used to recreate
the data from the failed drive onto the new drive. All of this can occur
without system down time.
There are many other options and features available for insuring that your
systems encounter as little down time as possible. The above descriptions
are only intended to be a general description of the technologies for the
purpose of comparing disaster recovery methods and plans.
Choosing RAID with backup recovery option means that you could have an
extended outage in the case of a multiple drive failure. In this case
restoration of the data would come from a backup. Which method that is used
for creating backups depends many business factors and is the subject of
information in the articles linked below. Recovery time will vary depending
on the amount of data that must be restored.
Advantages :
No data loss during single drive failure
Little data loss with multiple drive failure with recovery from backup
Disadvantages
Potential long recovery time from backup
For more information on Drive Performance and RAID architectures, see RAID
on MSDN
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/optimsql/od
p_tun_1_0m5g.asp?frame=true
For more information on Backing up and Restoring SQL Server Databases, see
Backing
Up and Restoring Databases on MSDN
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/ad
_bkprst_9zcj.asp?frame=true
2. Replication is not a warm standby solution. It only replicates data, not
things such as schema or security changes. Replication is predominantly a
solution to continuously maintain copies of specific data at other sites
(called subscribers). Those subscribers can actively work with the data
while the publisher is continually updating them - they are not typically
idle or in 'warm standby mode'. Subscribers are used for reporting servers
to segregate away from OLTP servers (like for OLAP datamarts), or for
browsing servers (e.g. in a web site where shoppers browse but not place
orders).
In a well-connected environment, the distribution task tends to run
continually. In such an environment, as a change is made at the publisher,
it flows nearly immediately to all subscribers. Latency tends to be a few
seconds in normal loads.
It is for this reason that many DBAs assume that replication will make a
better warm standby solution than will log shipping. This assumption is
incorrect.
The distribution task to a subscriber is a normal ODBC or OLEDB connection.
As such, it cannot match the very high performance of the low level RESTORE
TRANSACTION.
Secondly, only data is replicated. Actions like schema changes (beyond
add/drop column) and security changes are not replicated.
Thirdly, the switchover to the replicated standby server necessarily wipes
out the replication configurations that were set up and must be
reconfigured twice (once on switchover and again to switch back) to return
to normal production mode. This can be quite a large time investment.
Lastly, there is no automatic cutover/failover of applications who were
updating the publisher to be redirected to the subscriber. There is also no
automatic way to fail back to the publisher. If you have moved your
applications to the subscriber, and updates have been done there, then
those updates will need to be applied to the publisher before you bring
your publisher back online.
Please note that log shipping and replication are far from mutually
exclusive in SQL Server 2000. It is very reasonable that a transactional
replication environment exists whereby the publisher also performs the
backup and ships the log to a warm standby server. In fact, you might use
clustering, log shipping, AND replication.
The subscribers in this scenario are fully utilized machines. The target
server in log shipping stands by to take over the publisher's job should
that be necessary.
For further information regarding replication, see the following articles:
195757 INF: Frequently Asked Questions - SQL Server 7.0 - Replication
http://support.microsoft.com/?id=195757 I hope the explanation is clear. Please let us know if you need further
assistance on this issue.
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! -
www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights.
