That is correct, but here are some of the cons. This isn't to say tran log shipping isn't a good high-reliability solution. If it wasn't, no one would have figured out how to put things together in SQL Server 7.0 (and Microsoft wouldn't have implemented in SQL Server 2000 EE).

With log shipping, one database will always be slightly behind the other. Up to the amount of time between transaction log backups.

A second catch is you have a read-only solution in the second server, it has to be that way in order to accept the transaction log backups (and you certainly don't want anything written to it, because then there would be no way of getting it back to the first server).

With tran log shipping, you rely on the reliability of the network. In a pure fail-over clustering solution, you don't. The media is shared, so if the hardware on the first server fails, you come up on the second server. If you have a network outage, your transaction log backups don't make it across. Of course, I'm considering a case where a network outage affects connectivity to the second server but not clients (which does happen).

Finally, you've got the whole process of bringing the warm standby up as the primary and switching roles if log-shipping is in effect, something you don't worry about in fail-over clustering.

K. Brian Kelley

http://www.truthsolutions.com/

Author: Start to Finish Guide to SQL Server Performance Monitoring

http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1