Hi,
Does backing up a primary database in a log shipping pair cause problem in
the log shipping?
Aside from an on-going log shipping maintenance between a Primary &
Secondary (latency 15 minutes) database, I would like to schedule a daily
complete backup of the primary database and an hourly transaction log backup
.
I already tested this and so far log shipping continued but I just want to
confirm if this has no lurking issues. AFAIK, transaction log backup
truncates the log files that is why I am wondering how can the other
transaction log backup the log files if it is already truncated.
Your comments will be highly appreciated.
--
...A database backup does *not* break the sequence of log backups. I.e., it is
safe to do database
backups of a log shipped database.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"CarloVino" <CarloVino@.discussions.microsoft.com> wrote in message
news:714B75B2-AA8C-46FF-8B1F-A1B6B348F2CA@.microsoft.com...
> Hi,
> Does backing up a primary database in a log shipping pair cause problem in
> the log shipping?
> Aside from an on-going log shipping maintenance between a Primary &
> Secondary (latency 15 minutes) database, I would like to schedule a daily
> complete backup of the primary database and an hourly transaction log back
up.
> I already tested this and so far log shipping continued but I just want
to
> confirm if this has no lurking issues. AFAIK, transaction log backup
> truncates the log files that is why I am wondering how can the other
> transaction log backup the log files if it is already truncated.
> Your comments will be highly appreciated.
> --
> ...|||But what about transaction log backups? Does xp_sqlmaint (when it's
doing the copy phase on the secondary server) look up the msdb.backupset
& msdb.backupmediafamily tables on the primary server to get the
location of the physical log backup files (even the ones done by
processes other than the logshipping plan's xp_sqlmaint call, like
another maint plan or ad-hoc tlog backups)? Or does it just pick up log
backup files from a certain directory or created by the xp_sqlmaint
backup phase on the primary?
If it's the later then ad-hoc log backups, or log backups done by
another maint plan, would disrupt the logshipping sync (and in fact the
log shipping tlog backups would make the log backups done by the other
maint plan out of sequence).
On the whole, having 2 different plans (one log shipping plan and one
other maint plan) doing transaction log backups just sounds like a bad
idea (and redundant anyway). Why have another plan doing hourly tlog
backups when the logshipping plan is doing them every 15 minutes anyway?
*mike hodgson*
blog: http://sqlnerd.blogspot.com
Tibor Karaszi wrote:
>A database backup does *not* break the sequence of log backups. I.e., it is
safe to do database
>backups of a log shipped database.
>
>|||I don't use xp_sqlmaint for log shipping. But I'd be very surprise if it wou
ld pick up out-of-band
backups. My point was that out-of-band *database* backup doesn't disrupt log
shipping. Out-of-band
log backups does. I was under the impression that the OP was asking about da
tabase backup, so thanks
for pushing the point, Mike. :-)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:ONlx0j4zFHA.1192@.TK2MSFTNGP10.phx.gbl...
> But what about transaction log backups? Does xp_sqlmaint (when it's
> doing the copy phase on the secondary server) look up the msdb.backupset
> & msdb.backupmediafamily tables on the primary server to get the
> location of the physical log backup files (even the ones done by
> processes other than the logshipping plan's xp_sqlmaint call, like
> another maint plan or ad-hoc tlog backups)? Or does it just pick up log
> backup files from a certain directory or created by the xp_sqlmaint
> backup phase on the primary?
> If it's the later then ad-hoc log backups, or log backups done by
> another maint plan, would disrupt the logshipping sync (and in fact the
> log shipping tlog backups would make the log backups done by the other
> maint plan out of sequence).
> On the whole, having 2 different plans (one log shipping plan and one
> other maint plan) doing transaction log backups just sounds like a bad
> idea (and redundant anyway). Why have another plan doing hourly tlog
> backups when the logshipping plan is doing them every 15 minutes anyway?
> --
> *mike hodgson*
> blog: http://sqlnerd.blogspot.com
>
> Tibor Karaszi wrote:
>
>|||How do you implement log shipping if you don't use xp_sqlmaint (as
that's what the DB Maintenance Wizard uses when it creates all the
SQLAgent jobs)? Have you implemented your own home-grown log shipping
solution?
*mike hodgson*
blog: http://sqlnerd.blogspot.com
Tibor Karaszi wrote:
>I don't use xp_sqlmaint for log shipping. But I'd be very surprise if it wo
uld pick up out-of-band
>backups. My point was that out-of-band *database* backup doesn't disrupt lo
g shipping. Out-of-band
>log backups does. I was under the impression that the OP was asking about d
atabase backup, so thanks
>for pushing the point, Mike. :-)
>
>|||> Have you implemented your own home-grown log shipping
> solution?
Yep. I'm using www.dbmaint.com (since I write part of it, and while implemen
ting test-restore I
realized it was pretty much same thing as implementing log shipping), but lo
ts of people here also
just use their own jobs (I'm, pretty certain some has been posted here).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:uayUtD8zFHA.1168@.TK2MSFTNGP10.phx.gbl...
> How do you implement log shipping if you don't use xp_sqlmaint (as
> that's what the DB Maintenance Wizard uses when it creates all the
> SQLAgent jobs)? Have you implemented your own home-grown log shipping
> solution?
> --
> *mike hodgson*
> blog: http://sqlnerd.blogspot.com
>
> Tibor Karaszi wrote:
>
>sql
No comments:
Post a Comment