I am seeking information related to this subject.
BOL suggests backing up the active transaction log immediately after a
failure, so that the backup can be used in a recovery scenario if necessary.
This is the relevant text from BOL "Transaction Log Backup":
--//
The transaction log backup created at 8:00 P.M. contains transaction log
records from 4:00 P.M. through 8:00 P.M., spanning the time when the
database backup was created at 6:00 P.M. The sequence of transaction log
backups is continuous from the initial database backup created at 8:00 A.M.
to the last transaction log backup created at 8:00 P.M. The following
procedures can be used to restore the database to its state at 10:00 P.M.
(point of failure).
Restore the database using the last database backup created.
1.. Create a backup of the currently active transaction log.
--// end of excerpt
If the failure results in loss of the instance and/or the log's parent db,
how would we back up that log? Even if we could, what confidence would we
have that the backed up log was not corrupted at failure time?
Thanks,
PSGThe standard configuration when loss of transactions is unacceptable:
put the log disk on a separate disk from the data. And mirror the log disk.
You would have to trust (hope) that your log disk didn't suffer loss of
data. That's the point of the mirroring.
If the instance was lost, then you'd have to rebuild/restore master before
you'd be able to issue the
BACKUP LOG WITH NO_TRUNCATE to harvest the tail of the log.
"JustaCowboy" <ppgoodingNOSPAM@.rocketmail.com> wrote in message
news:blj1rd$v1g$0@.pita.alt.net...
<snip
> If the failure results in loss of the instance and/or the log's parent db,
> how would we back up that log? Even if we could, what confidence would we
> have that the backed up log was not corrupted at failure time?
> Thanks,
> PSG|||"Anonymous" <noone@.anon.com> wrote in message
news:3f7f1411$1@.news.microsoft.com...
> The standard configuration when loss of transactions is unacceptable:
> put the log disk on a separate disk from the data. And mirror the log
disk.
Yes.
> You would have to trust (hope) that your log disk didn't suffer loss of
> data. That's the point of the mirroring.
Yes.
> If the instance was lost, then you'd have to rebuild/restore master before
> you'd be able to issue the
> BACKUP LOG WITH NO_TRUNCATE to harvest the tail of the log.
Will SQL backup an unattached log file? If not, to what is the harvested
log attached? I am having trouble understanding the steps that would lead
to being able to backup that log unless SQL will back it up unattached.
Has anyone actually tried the scenario described in BOL?
A local has suggested to me that we frequently back up the log and copy the
backups (along with the preceeding full db backup) to disk or device
external to the subject server. If this log backup/copy were done every 15
mins, then presumably no more than 15 mins' work would be lost after a
failure. Our assumption right now is that the BOL suggestion just won't
work. We'd try simulating it if we thought the simulation were valid, but
that seems very doubtful.
thanks,
PG
