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

Log shipping Fail over

Hi Paul,
To switch back roles from the new primary to old primary, why you need to
rename the server, use sp_dropserver, sp_addserver and restart the services?
Thanks for your help.
Pierre,
the reason is that you can't (easily) have 2 computers with the same NETBIOS
name on the same LAN.
Rgds,
Paul Ibison (SQL Server MVP)
|||Pierre,
Normally in log shipping role changes you do not change the server names.
Instead, the application must change its connection string to reference the
correct server.
Ron
Ron Talmage
SQL Server MVP
"Pierre Pilon" <Pierre Pilon@.discussions.microsoft.com> wrote in message
news:36E83F31-CEC9-4082-ABAF-96AC51DBA8BC@.microsoft.com...
> Hi Paul,
> To switch back roles from the new primary to old primary, why you need to
> rename the server, use sp_dropserver, sp_addserver and restart the
services?
> Thanks for your help.
|||Ron,
with respect, I think this depends on the setup
implemented. EG if there are loads of desktop
applications using DSNs which refer to the servername,
then changing each connection string may not be so
feasible. Also, if linked servers are being used to
reference the production server with 4-part qualified
names this will cause issues. Rescuing replication with
existing subscribers would be another issue, although
the 'standard' seems to be setting it up from scratch.
Master-slave jobs would probably be another difficulty.
Rgds,
Paul Ibison (SQL Server MVP)