?
Solved

SQL 2005 transaction log

Posted on 2011-03-11
9
Medium Priority
?
271 Views
Last Modified: 2012-05-11
Hi,

I have a SQL 2005 cluster server running 32 bit. I have a database roughly around the size of 520gb. The transcation log is currently sitting at 72GB. I have a full backup that runs daily which is supposed to truncate the logs files? It appears this transcation log is not shrinking.

What can i do to solve this and it is effecting performance.

Regards
0
Comment
Question by:monarchit
9 Comments
 
LVL 7

Expert Comment

by:Gene_Cyp
ID: 35108099
0
 
LVL 31

Expert Comment

by:Rich Weissler
ID: 35108110
Backing up, and truncating the logs doesn't cause them to shrink, it allows the space to be reused.

The best practice recommendation is also to NOT shrink the transaction logs, unless you know something very unusual has occurred to cause them to grow much larger than they need to be.
0
 
LVL 7

Expert Comment

by:Gene_Cyp
ID: 35108126
One key way to stop it from growing too much is to change the recovery type to:

"Simple recovery model" in the SQL Settings

Just make sure that the recovery model you select meets your recovery needs.
0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

 
LVL 6

Expert Comment

by:Maciej Pilecki
ID: 35108240
If you don't need to take transaction log backups, just switch the database to Simple Recovery Model and shrink the log file manually, using Tasks > Srink > Files on the database.
0
 
LVL 31

Expert Comment

by:Rich Weissler
ID: 35108296
If you don't need the point in time recovery... I concur with Gene_Cyp and graf0 -- Simple Recovery Model might be a good fit for you.  

I feel I should mention however -- one of the mistakes I made when starting with SQL was to assume the Transaction Log in the Simple Recovery Model was either minimally used or not used.  Be aware that the Transaction Log still needs to be sized sufficient to hold entire transactions while they are being committed to the database.  It won't be 'nothing' and probably won't be just the size of a single transaction... but it will probably be smaller than your transaction log will want to be with the Full Recovery Model.

One of the worst things you can do for performance would be to go through repeated cycles of shrinking and growing your transaction log files...
0
 
LVL 21

Expert Comment

by:Alpesh Patel
ID: 35108321
Hi,

First take back off Log file and truncate it.
0
 
LVL 2

Expert Comment

by:Umesh_Madap
ID: 35115890
most of the guys have answered to u r question.

I would like to know how frequent u r taking the t-log backups, for example if u r taking t-log backup every 1 hr then change it to 30 min.. and see. if you don't want point in time recovery then u r set it to simple recovery model.
0
 
LVL 1

Accepted Solution

by:
rcharlton earned 2000 total points
ID: 35116075
I've worked in high availability VLDBs (Very Large Database Environments) with SQL Server 2005. The best way that I've found is to perform the following:

1. Set the recovery interval to 5 minutes. Too long of a recovery interval and SQL Server is doing to many "background things" while your DB users are waiting for it. Too short and you have the same scenario. If there's a restore necessary, you're only talking about granularly losing data for the last 5 minutes prior to the failure.
2. Backup the transaction log every 5 minutes; this keeps it small and compact, allows you to shrink the transaction log (yikes! Yours is at 72GB? Do you need that much for the transaction log? Probably not)
3. You only have to worry about space where the transasction log backups are being placed.

As a caveat, I would implement the following backup strategy:

1. Perform a full backup once a week, say on Sunday.
2. Perform a differential backup Monday through Saturday.
3. Perform a log backup every 5 minutes.
4. Create stored procedures for the above, including ones that will do the restore.
5. Optionally, your database can be architected to use filegroups and partitioning. Non frequently accessed data, or data that never changes, can be on filegroups; data that frequently changes can be on other file groups. You only need to backup data on filegroups that are changing. This SIGNIFICANTLY reduces the amount of time to perform the backup. Although somewhat more complex to implement, once you get the hang of it -- it's a breeze, and your backups / restores happen very quickly. In my scenario for example, I had imports which happened on a certain day of the week. Those tables were targeted for certain filegroups, with partitioning, and a backup of those filegroups was performed on those days. The same was true for other filegroups which accepted data on different days. Those filegroups were backed up on those certain days as well. IT sounds complicated, but it reduces the amount of backup space required, and frees up the server for the production users, and will increase performance.
0
 

Author Closing Comment

by:monarchit
ID: 36032707
thanks
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I've encountered valid database schemas that do not have a primary key.  For example, I use LogParser from Microsoft to push IIS logs into a SQL database table for processing and analysis.  However, occasionally due to user error or a scheduled task…
Data architecture is an important aspect in Software as a Service (SaaS) delivery model. This article is a study on the database of a single-tenant application that could be extended to support multiple tenants. The application is web-based develope…
SQL Database Recovery Software repairs the MDF & NDF Files, corrupted due to hardware related issues or software related errors. Provides preview of recovered database objects and allows saving in either MSSQL, CSV, HTML or XLS format. Ensures recov…
Stellar Phoenix SQL Database Repair software easily fixes the suspect mode issue of SQL Server database. It is a simple process to bring the database from suspect mode to normal mode. Check out the video and fix the SQL database suspect mode problem.
Suggested Courses
Course of the Month3 days, 9 hours left to enroll

601 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question