Log Shipping with HOLD

I had an interview question the other day I don't understand. He asked about
types of replication and when you would use them. One of the options was "lo
g
shipping with hold" and why?
I can't think of a good reason to do this, as with that type of replication,
you would want the replicant/subscriber to be as close as possible to the
primary/publisher. Otherwise, why not just use snapshot?
Thoughts please.JayKon wrote:
> I had an interview question the other day I don't understand. He asked abo
ut
> types of replication and when you would use them. One of the options was "
log
> shipping with hold" and why?
> I can't think of a good reason to do this, as with that type of replicatio
n,
> you would want the replicant/subscriber to be as close as possible to the
> primary/publisher. Otherwise, why not just use snapshot?
> Thoughts please.
For a standby or "disaster recovery" server, having a delay in the
restore process can help protect from logical disasters, i.e. somebody
nukes a million rows in a table by accident. You have time to prevent
that mistake from reaching your standby machine in case you need it.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||My first reaction is "DOH!", that makes sense. But after that, I wonder if
thats really such a good idea. After all, you can still do a point-in-time
restore, or even restore to a seperate DB and manually extract the rows to
recover.
Anyway, thanks Tracy, I should have thought of that.
"Tracy McKibben" wrote:

> JayKon wrote:
> For a standby or "disaster recovery" server, having a delay in the
> restore process can help protect from logical disasters, i.e. somebody
> nukes a million rows in a table by accident. You have time to prevent
> that mistake from reaching your standby machine in case you need it.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||"JayKon" <JayKon@.discussions.microsoft.com> wrote in message
news:B04C4FDD-89F3-468E-8626-B335D964D61F@.microsoft.com...
> My first reaction is "DOH!", that makes sense. But after that, I wonder if
> thats really such a good idea. After all, you can still do a point-in-time
> restore, or even restore to a seperate DB and manually extract the rows to
> recover.
>
Also,
Using Secondary Servers for Query Processing
http://msdn2.microsoft.com/en-us/library/ms189572.aspx
David|||JayKon wrote:
> My first reaction is "DOH!", that makes sense. But after that, I wonder if
> thats really such a good idea. After all, you can still do a point-in-time
> restore, or even restore to a seperate DB and manually extract the rows to
> recover.
>
All true, but if you're in a low- or no-downtime environment, doing
weekly full/hourly log backups, with a two-hour delay in log shipping,
if something happens on Thursday, will it take longer to restore the
full and 4 days of logs, or two hours of logs (up to the failure)?
It's just another tool, another way of protecting yourself...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||David, the question was not about uses of replication, but rather the "with
hold" option.
"David Browne" wrote:

>
> "JayKon" <JayKon@.discussions.microsoft.com> wrote in message
> news:B04C4FDD-89F3-468E-8626-B335D964D61F@.microsoft.com...
> Also,
> Using Secondary Servers for Query Processing
> http://msdn2.microsoft.com/en-us/library/ms189572.aspx
>
> David
>|||"JayKon" <JayKon@.discussions.microsoft.com> wrote in message
news:6BA5BF29-8848-46C4-9C8A-A238AAB4E5E9@.microsoft.com...
> David, the question was not about uses of replication, but rather the
> "with
> hold" option.
>
My point, perhaps not really explained, was that the secondary database is
available for querying only while you are not restoring logs. If, for
instance, you only restore logs at the end of the day, you can use the log
shipping secondary server for point-in-time reporting.
David