Very Computer

Thanks in advance,
Travis

You cannot truncate transaction logs if you want to use transaction log
backups and rollforward recovery.

--

Neil Boyle
Impetus Network Systems DBA's Handbook, A free SQL Server guide at
http://www.impetus-sql.co.uk/

Your log backups are worthless, If you truncate the log _after_ the db
backup.
I don't reccomend truncating the log before db backup either. If you keep
the log, you can survive a corrupt db backup (go back to the previous)...

--
Tibor Karaszi, Cornerstone Sweden AB
MCDBA, MCSE, MCSD, MCT, SQL Server MVP
Please reply to the newsgroup only, not by email.

Quote:> Hello all!  Sorry for my ignorance here, but I probably have a stupid
> question.  I am using HP Omniback to backup SQL 7.0 on an NT cluster.  I
am
> implementing full backups at midnight and transaction log backups every 6
> hours.  There is an option in Omniback where I can truncate the
transaction
> log after a full backup.  If I do this, will I be able to utilize my
> transaction logs to do a point in time restore?  I have not found
> documentation on this, but when you use to do a full database backup using
> SQL Enterprise manager, does it truncate the transaction log by default?

> Thanks in advance,
> Travis

Quote:> Hello all!  Sorry for my ignorance here, but I probably have a stupid
> question.  I am using HP Omniback to backup SQL 7.0 on an NT cluster.  I
am
> implementing full backups at midnight and transaction log backups every 6
> hours.  There is an option in Omniback where I can truncate the
transaction
> log after a full backup.  If I do this, will I be able to utilize my
> transaction logs to do a point in time restore?  I have not found
> documentation on this, but when you use to do a full database backup using
> SQL Enterprise manager, does it truncate the transaction log by default?

> Thanks in advance,
> Travis

When should I truncate the transaction log if I want to do a point in time
restore?  I know that when I have a db failure, I would backup the
transaction log without truncting the transaction log.

The log _is_ truncated when you perform BACKUP LOG. That is the normal way
of "removing log-records" from the transaction log.

--
Tibor Karaszi, Cornerstone Sweden AB
MCDBA, MCSE, MCSD, MCT, SQL Server MVP
Please reply to the newsgroup only, not by email.

Thanks,
Travis

Quote:> At DB failure, run transaction log backup without truncating transaction
> log.  Then use latest full backup and transaction logs to do a point in
time
> restore.

If your database fails at 7:30 p.m., you can only roll forward as far as
6:00 p.m. because that's the last backup you took before the failure - you
start by restoring from the latest full database dump, then applying the
transaction log dumps in sequence.

You can increase your "protection" by taking transaction log backups more
often, and right up to "just before" your next full database dump - which is
what Tibor was getting at earlier.

Don't forget that your backup files need to be *off* your server - no use
backing up to the same machine that your databases live on if the whole
machine goes kaput.

--

Neil Boyle
Impetus Network Systems DBA's Handbook, A free SQL Server guide at
http://www.impetus-sql.co.uk/

(Note that you cannot do log backup if you've lost the mdf file. Some dba's
use file groups and "steer off" data from the mdf file this way. See Wayne
Snyder's article in Oct SQLMag for elaboration...)

--
Tibor Karaszi, Cornerstone Sweden AB
MCDBA, MCSE, MCSD, MCT, SQL Server MVP
Please reply to the newsgroup only, not by email.

Quote:> Just so that I am straight on this.
>   Midnight: full backup (do not truncate transaction log)
>   6AM: transaction log backup (transaction log truncated)
>   noon: transaction log backup (transacation log truncated)
>   6PM: transaction log backup (transaction log truncated)
> At DB failure, run transaction log backup without truncating transaction
> log.  Then use latest full backup and transaction logs to do a point in
time
> restore.

> Thanks,
> Travis

Quote:> At db failure you need a restore, by then it's too late for a backup :-)

<snip>