Log Shipping to old box?

My primary SQL Server box is 2005 Standard x64 running on 2 quad-core processors. I'm licensed for 2 processors.

I'd like to set up some kind of redundancy. The hardware I have available is about 4 years old and is currently running SQL Server 2000. Let's assume I upgrade the old box to SQL Server 2005 Standard. A couple of questions:

1) It seems the hardware gap between the 2 will make little difference in a log shipping. Please confirm this. Any other things that might be an issue?

2) Do I need lots of CALs on the backup box for Log Shipping? Or can I get by with 5?

3) I'd like to schedule log shipping pretty often--maybe every 5 or 10 minutes. Will this be an issue?

Thanks!

1. No

2. No, Yes, as long as it is not accessed by users that are not covered with CALs. A SQL Server CAL is good for all SQL Servers in the domain.

3. 5-10 minutes 'should' not be an issue. As long as the performance/load differential is not so great that the log cannot be applied in the time alloted.

Another option with SQL 2005 is Database Mirroring. Have you explored the benefits of Database Mirroring?

|||>Another option with SQL 2005 is Database Mirroring. Have you explored the benefits of Database Mirroring?

I've read a little about Database Mirroring. How will my old hardware affect the mirroring process? Will I have trouble with the slower server keeping up with the transactions?

Brian

|||

The same issue occurs with Log Shipping.

Will, in fact, the old box have enough 'power' to keep up with the data flow. That is something you will have to test.

|||

I guess I made this assumption (that could be very wrong):

Log Shipping moves data in batches. Database mirroring moves data by record or transaction. (Not sure what method is used). A batch append should be less stressful on a backup server than a bunch of individual appends.

Even if these are true, maybe the difference in stress is much less than I think.

Brian

|||

It could go either way.

I would set up a test environment and test both if they seemed equally valid solution candidates. You're trying to balance the trade-offs of cost of solution vs. speed of recovery.

sql