October 15, 2009 at 7:38 am
I noticed the following note in BOL for the Backup Log NO_LOG | TRUNCATE ONLY options.
Note:
This option will be removed in a future version of SQL Server. Avoid using it in new development work, and plan to modify applications that currently use it.
What is the alternative method to use going forward? How do achieve the same results with compliant code?
October 15, 2009 at 7:50 am
dmc-608719 (10/15/2009)
What is the alternative method to use going forward? How do achieve the same results with compliant code?
ALTER DATABASE ... SET RECOVERY SIMPLE
Not that you should need to truncate the logs, not that you should be truncating the logs.
Please read through this - Managing Transaction Logs[/url]
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
October 15, 2009 at 9:23 am
BACKUP LOG with TRUNCATE_ONLY was deprecated in SQL 2008. To obtain the same functionality, you have to set the database to SIMPLE RECOVERY, CHECKPOINT and then put it back in FULL RECOVERY at which point you should immediately take a FULL BACKUP. That being said, there's rarely a good reason to put a production database in SIMPLE RECOVERY unless you're running some very large batch / maintenance process that can be recreated without risk to losing data.
October 15, 2009 at 11:06 am
Simple Recovery it is then...
The issue is that occassionaly developers and other users will load data into database without bulk load or other methods and create large logs. This is a one time load, or one time manipulation, etc that makes large logs that are not indicative of normal use. So in the past I would run a TRUNCATE_ONLY and then a backup. Seing as how it was being phased out I wondered the preferred method.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply