Safely Truncate Transaction Log After Backup in SQL Server 2005 : sql, log, 2005, truncate, transaction

May 17, 2008 12:57pm pdt

1. chapmandew 1,139,490
2. angelIII 656,012
3. aneeshat... 347,059
4. ee_rlee 305,823
5. dtodd 190,705
6. brejk 170,605
7. ptjcb 151,519
8. mark_wills 146,165
9. PFrog 98,658
10. acperkins 86,575
11. dqmq 75,630
12. dportas 74,146
13. momi_sabag 71,940
14. maradam 71,186
15. Thomasian 70,100

1. angelIII 1,936,203
2. chapmandew 1,139,490
3. aneeshat... 912,164
4. ptjcb 515,911
5. Yveau 505,473
6. dtodd 401,710
7. PFrog 368,686
8. dqmq 346,978
9. imitchie 324,100
10. ee_rlee 305,823
11. appari 277,897
12. Lowfatsp... 220,339
13. rboyd56 192,515
14. SQL_SERV... 183,215
15. acperkins 181,914

11.13.2007 at 06:28AM PST, ID: 22957096

	[x] Attachment Details

[x]

The Solution Rating System

With so many solutions, how can you tell which solutions are most likely to help you and which ones are not? To provide you with a tool to use, we rate our solutions based on various elements that most accurately determine if a solution is a quality solution. To explain what factors affect the solution rating, here are the elements we take into consideration when formulating our solution rating.

The Grade of the Solution
The Zone Rank of the Expert Providing the Solution
The Number of Author and Expert Comments
The Number of Experts Contributing
The Feedback of the Community

Your Input Matters
Because of the way the system is set up, the most important variable in this equation is you. As a member of Experts Exchange, you are able to cast your vote on the quality of the solutions in regard to how complete, accurate, helpful and easy to understand each solution is. When you provide your feedback, each rating is adjusted accordingly. So, if you see a solution that has a poor rating that you think is a good solution, let us know by rating it. As you do, the rating will be adjusted and will become more accurate for other members of our site.

If you have any suggestions that you would like to make for our rating system, please ask a question in the Suggestions Zone of Community Support.

Thank you!

9.4

Safely Truncate Transaction Log After Backup in SQL Server 2005

Zone: SQL Server 2005

Tags: sql, log, 2005, truncate, transaction

I have a nightly maintenance plan that backs up all SQL databases
I have one database that has the transaction log set to autogrow
The recovery model is full
Unless I manually set recovery mode to simple, then shrink trans log file - it just keeps growing - and when it hits 20gb, performance begins to suffer
Currently grows at approx 150mb a day
What can I do in the maintenance plan to safely shrink the transaction log after backup - or what is the current best practice to follow
Thanks
BBDC

Start your free trial to view this solution

Question Stats

Zone: Microsoft

Question Asked By: bigbillydotcom

Solution Provided By: Yveau

Participating Experts: 2

Solution Grade: A

Translate:

Loading Advertisement...

Microsoft

Internet Protocols
Applications

Development
OS

Hardware
Windows Security

Apple

Operating Systems
Hardware

Programming
Networking

Software

Internet

Search Engines
File Sharing
WebTrends / Stats
Spy / Ad Blockers

Web Browsers
New Net Users
Web Development
Chat / IM

Anti Spam
Web Servers
Anti-Virus
Email Clients

Gamers

Tips
Online / MMORPG
Puzzle
Emulators

Action / Adventure
Role Playing
Consoles
Game Programming

Strategy
Sports
Misc
Computer Games

Digital Living

Hardware
New Net Users
New Users

Software
Digital Music
Gaming World

Home Security
Apple
Networking Hardware

Virus & Spyware

Vulnerabilities
IDS
Encryption
Anti-Virus

Operating Systems Security
Software Firewalls
WebApplications
Cell Phones

Operating Systems
Internet
Hardware Firewalls

Hardware

Handhelds / PDAs
Displays / Monitors
Components
Networking Hardware

Peripherals
Laptops/Notebooks
Storage
Servers

Desktops
New Users
Misc
Apple

Software

System Utilities
Industry Specific
Network Management
Photos / Graphics
Page Layout
VMWare
Misc
Web Development

OS
CYGWIN
Voice Recognition
Message Queue
Quality Assurance
Security
Firewalls
MultiMedia Applications

Development
Database
Office / Productivity
Business Management
OS/2 Apps
Server Software
Internet / Email

ITPro

OS
Storage
Encryption
Operating Systems Security
Apple Hardware
Laptops & Notebooks
Servers
Networking Hardware
Peripherals

Devices
Displays / Monitors
WebTrends / Stats
Search Engines
Firewalls
WebApplications
IDS
Vulnerabilities
Email Clients

File Sharing
Spy / Ad Blockers
Web Browsers
Web Servers
Networking
Anti-Virus
Chat / IM
Anti Spam

Developer

Web Servers
Web Browsers
Game Programming
Dev Tools
Industry Specific
Office / Productivity

Database
CYGWIN
Web Development
Search Engines
File Sharing
WebTrends / Stats

Programming
Content Management
Application Servers
Protocols

Storage

Removable Backup Media
Storage Technology
Servers

Grid
Remote Access
Backup / Restore

Misc
Hard Drives

Miscellaneous
Security
Development
Linux
VMWare

MainFrame OS
Unix
Apple
OS / 2
AS / 400

BeOS
Microsoft
VMS / OpenVMS

Database

Oracle
Miscellaneous
MySQL
Software
Sybase
Contact Management
PostgreSQL
Data Manipulation
Clarion
InterSystems Cache

Siebel
MUMPS
OLAP
SQLBase
SAS
GIS & GPS
4GL
Berkeley DB
DB2
Informix

Interbase / Firebird
FoxPro
Reporting
LDAP
Filemaker Pro
MS SQL Server
dBase
MS Access

Security

Misc
Web Browsers
Software Firewalls
Operating Systems Security
File Sharing

Spy / Ad Blockers
Vulnerabilities
WebApplications
IDS
Anti-Virus

Encryption
Anti Spam
Email Clients
VPN
Chat / IM

Programming

Editors IDEs
Installation
Handhelds / PDAs
Multimedia Programming
System / Kernel

Algorithms
Game
Signal Processing
Project Management
Open Source

Database
Misc
Languages
Processor Platforms
Theory

Web Development

Scripting
Blogs
Web Servers
Software
Search Engines
Web Graphics
Images

Internet Marketing
Images and Photos
Components
Document Imaging
Web Languages/Standards
Illustration
WebApplications

Fonts
WebTrends / Stats
Authoring
Digital Camera Software
Miscellaneous

Networking

Protocols
Apple Networking
Network Management
Message Queue
Application Servers
Content Management
File Servers
Email Servers
Misc
Java Editors & IDEs

Wireless
Networking Hardware
Backup / Restore
System Utilities
ISPs & Hosting
Web Servers
Storage Technology
Removable Backup Media
Servers
Broadband

Grid
OS / 2
Novell Netware
Unix Networking
Windows Networking
Security
Telecommunications
Operating Systems
Linux Networking

Other

Community Advisor
Lounge
Community Support
New Net Users

Philosophy / Religion
Math / Science
Miscellaneous
URLs

Expert Lounge
Politics
Puzzles / Riddles

Community Support

Suggestions
New to EE
New Topics
Community Advisor

CleanUp
Announcements
General

Feedback
Input
EE Bugs

11.13.2007 at 06:34AM PST, ID: 20271688

Rank: Sage

aneeshattingal:

seems like you are making the biggest mistake of "Not taking the log backup" , this is really very very critical as far as a DBA is concerned, 'remember' data is a valueable thing and the dba is responsable for taking care of that. So schedule a job to take the backup of your log file and schedule it at least twise in an hour.

11.13.2007 at 06:35AM PST, ID: 20271696

Rank: Sage

Yveau:

When you have your recovery mode to full, you are supposed to make two types of backups:
Full backup every ones in a while - goes without saying I guess.
Transaction log backups every hour (or so) to keep the log file small and being able to do a point in time recovery I.C.E. If you skip this not only will the log file keep on growing, but the only restore you can do will be a restore from the full backup. And in that case you loose all the work from that moment on. If you backup the transaction log as well, you can do a roll forward and restore up until the last transaction log backup ... being max an hour ago ...

Hope this helps ...

11.13.2007 at 06:58AM PST, ID: 20271872

bigbillydotcom:

thanks guys - just don't see where the steps are to do what you are saying
I know the theory - I just wonder how to actually do it
BTW - i have a RAID5 server - and I do a FULL backup to disk and then tape every hour (D-D-T)
of my critical database, and ALL dbases once a night after hours
when I restore the HOURLY backup, it includes the transaction log - so I'm sure I'm grabbing the LOG file
The problem is, the LOG file doesn't shrink after the backup - is there something I am not doing correctly with the backup?
Thanks
BBDC

11.13.2007 at 07:15AM PST, ID: 20272019

Rank: Sage

Yveau:

When you do a full backup every hour, it contains the state of that moment and does NOT include the logfile. But then again, you might not even want to have it.
The only way to keep the logfile small is
1. to go to simple recovery mode, that is what you are acting like, so why don't do that ?!
2. do a BACKUP LOG {database_name} WITH TRUNCATE_ONLY ... you'll just 'empty' the logfile from all finished transaction. The logfile will be sized by the space the biggest transactions need.

Hope this helps ...

11.13.2007 at 07:22AM PST, ID: 20272075

bigbillydotcom:

Yveau - im confused
I have dbase set to FULL recovery mode
when I do a restore from my HOURLY backup - there is a database AND transaction log that are restored
so WHY do you say it DOES NOT include the logfile?
I don't mind doing the FULL each hour - it works fine, doesn't effect performance and seems to provide a FULL backup of ALL data at the time of the backup
I am not sure what you mean by "to go to simple recovery mode, that is what you are acting like, so why don't do that ?!"
So - if I run
BACKUP LOG {database_name} WITH TRUNCATE_ONLY
as a nightly job after the FULL nightly backups - would that truncate my transaction log safely?
Can I run that unattended?
Thanks
BBDC

11.13.2007 at 10:34AM PST, ID: 20273797

Rank: Sage

Yveau:

No need to ...

Full recovery mode simply means that all transactions are kept in the database log file until you do a backup of it. So once the file is full, a file growth will happen and the file will keep growing.
Simple recovery mode means that once the database log file is full, no growth will be done, but the used and inactive part of the log file (the part where the transactions are stored that already have been committed or rolled back) is reused. So the file will stay rather small.

If you restore a database, a new database is created for you, and a new logfile. As SQL Server is a write ahead RDBMS, every transaction first goes to the log, and only then to disk. So a database in SQL Server will always contain a data file and a log file. Right after the restore, your database will be as at the time of the backup, the logfile will be almost empty. Only when you do a 'special' restore, some info from the logfile can be used. Under normal circumstances, all open transactions that are in the logfile are rolled back after a restore. So actually, there is some logfile data in a full backup ... but 'backup database' statement can never 'empty' the logfile for you !

Yes, you could run the backup log {DB} with truncate_only as a nightly job and run it unattended, it's just a normal SQL statement that you can run from a job. But I still think that in your case switching to simple recovery mode is easier, safer and less confusing as you never use or plan on using the database log.

Hope this helps ...

Accepted Solution

bigbillydotcom

11.13.2007 at 10:42AM PST, ID: 20273862

Thanks Yveau
We actually are going to begin using transaction log shipping - so, you're right, we aren't using it now - but as soon as DPM comes out we hope to be able to use transaction log shipping
Thanks for the explanation and help
BTW - is there anything I need to do special (other than backing it all up) prior to running the backup log truncate command?
Thanks
Billy

Yveau

11.13.2007 at 10:53AM PST, ID: 20273943

No, just run the statement and the part that can be dropped from log file, will be dropped. I'm not sure, but I think it will also automatically shrink. If not, run a dbcc shrink to force it to shrink

http://support.microsoft.com/kb/907511

Glad I could be of any help and thanks for the grade !

20080236-EE-VQP-29 / EE_QW_2_20070628