log shipping vs. Replication

>Now, having said that, once box A is back up, in an ideal
>world, why would you make the switch back to A as a
>primary since B should hopefully have the same capacity.
>
Because BoxA is in a location that meets the specs for our
customers. BoxB is not.

>As for a full restore back on A, it depends on what state
>it was in, where the secondary was, etc. Even if you
wind
>up depending on your situation having to do a full
restore
>on A, you essentially set up log shipping. Do your point
>in time on B, restore on A, then use log shipping to
catch
>up.
Ive never used it so please bear with me. I was told that
I would have to:
Take a full backup of BoxB.
Transfer it to the Location of BoxA.
Restore it on BoxA.
Is this not the case? I thought it sounded odd but was re-
assured.
The way I look at it is
1) Clustering replicates/clones a server
2) backing up and restoring the database to the standy server, replicates
the database
3) Log Shipping is a continous backup and restore of the database
4) replication replicates transactions
It depends on your requirements, and how expensive downtime is to you, or
how valuable your data is. For disaster recovery most people look at
clustering solutions.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Allan Hirt" <anonymous@.discussions.microsoft.com> wrote in message
news:53e601c47424$b14a55a0$a601280a@.phx.gbl...
> Usually it is a capacity issue, not one like this. So if
> Box B is in an unsuitable location, do your customers
> know? Usually this is part of any SLA you establish with
> them.
>
> Again, it depends, especially on the type of failure. If
> you were able to grab the tail of the log on the primary,
> and at some point get it to standby, the secondary when
> all logs are applied at the time BEFORE you redirect
> traffic, they are in the same place data/etc. wise.
> Now, if your DBs are inconsistent, it's pretty much
> impossible. Remember that backup is an online operation,
> so if you need to do a full backup, do it, still allow
> work on B, restore the backup on A, then configure log
> shipping from B to A, and make the switch. It's pretty
> painless.
> If you did it your way, you would need to pretty much stop
> activity on B to ensure they are at the same point, which
> is probably what you don't want to do. Transaction logs
> exist for a reason.
> So again, it is completely dependent upon what state
> you're in at the time of failure.
> I've had customers do upgrades using log shipping and
> we've incurred only minutes of actual downtime because of
> it.