Re: Trimming HUGE Transaction Log

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Duh - I should have figured that one out! Based on this, my plan will be:
-- Keep the Recover Model FULL
-- Do differential backups hourly during the day.
-- Do full backups at night.
Seems like this would allow Point-In-Time recovery with a much smaller
transaction file.

Did I interpret your suggestions properly?
Thanx in advance - I really do appreciate the help!

Angelo Michel


"Aaron Bertrand [SQL Server MVP]" wrote:

If you want the benefits of full recovery model without the log growth you
are experiencing, then back up the log more often between full backups!


On 10/13/08 2:04 PM, in article
E84FFBD1-83A4-472A-91A0-C8C6CA2737B7@xxxxxxxxxxxxx, "Always OpenTo
Suggestions" <AlwaysOpenToSuggestions@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

But if I keep the recovery model SIMPLE - wouldn't that eliminate the ability
to restore transactions to a point in time. I was hoping that turning the
recovery model to SIMPLE would trim the transaction log and that putting it
back to FULL would allow recovery to a point in time.


.

Relevant Pages

  • Backup Strategies
    ... Our environment is development and data warehousing with many non logged ... trasactions. ... Our recover model is simple and our backups are always full ...
    (microsoft.public.sqlserver.server)
  • Timing of Backups
    ... I know you need to back up all the players invloved (msdb, distribution, ... I was curious as to the timing of the backups. ... transaction dumps every half hour. ... example, do we back up the transaction log of the publisher first, then the ...
    (microsoft.public.sqlserver.replication)