Log size is Big

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 2005 » Administering » Log size is Big

16 posts, Page 2 of 2

««1 2

Log size is Big

Rate Topic

Display Mode

Topic Options

Author

Message

anthony.green

Posted Tuesday, January 08, 2013 3:56 AM

SSCertifiable

Group: General Forum Members
Last Login: Friday, April 12, 2013 3:51 AM
Points: 5,075, Visits: 4,831

Then you need to ensure that you setup transaction log backups otherwise the issue will keep happening.

Go back to the business and ask them what the recovery point objective is for the database, that will determine how often you need to backup the transaction log.

If they can loose 15 minutes worth of data, then transaction log backups need to run every 15 minutes etc.

If your not bothered about restoring to a point in time now, then yes setting to simple and shrinking will be one option. If you want the log chain to be intact, do a manual backup of the log, then shrink, which will give you the recoveryability which you get from full without breaking the chain.

Want an answer fast? Try here
How to post data/code for the best help - Jeff Moden
Need a string splitter, try this - Jeff Moden
How to post performance problems - Gail Shaw
CrossTabs-Part1 & Part2 - Jeff Moden
SQL Server Backup, Integrity Check, and Index and Statistics Maintenance - Ola Hallengren
Managing Transaction Logs - Gail Shaw
Troubleshooting SQL Server: A Guide for the Accidental DBA - Jonathan Kehayias and Ted Krueger

Post #1404115

GilaMonster

Posted Tuesday, January 08, 2013 4:15 AM

SSC-Dedicated

Group: General Forum Members
Last Login: Today @ 8:45 AM
Points: 37,637, Visits: 29,891

DIB IN (1/8/2013)

database to be Full recovery.
there will be no data loss or minimum data loss.

Simple recovery model doesn't support that. Have another read through that article, specifically the sections on log backups.

p.s. Don't shrink the log to 0. Once you have log backups running, you can shrink the log to a sensible size (0 is not sensible)

Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1404127

DIB IN

Posted Tuesday, January 08, 2013 4:39 AM

SSC Rookie

Group: General Forum Members
Last Login: Wednesday, March 06, 2013 12:28 AM
Points: 31, Visits: 156

Please confirm if the below points are true for full recovery model without changing the recovery model:-
The below query will take the back up transaction log and shrink the log file:-

USE DBNAME

Take a DB Full bacp of DB

Take a back up of log:-
backup log DBNAME with no_log

Shrink log:-
DBCC SHRINKFILE DBNAME_Log, 10)

Post #1404151

GilaMonster

Posted Tuesday, January 08, 2013 5:07 AM

SSC-Dedicated

Group: General Forum Members
Last Login: Today @ 8:45 AM
Points: 37,637, Visits: 29,891

Nope.

That will break the log chain, prevent further log backups, essentially put you in simple recovery model (which means you cannot meet your SLAs), then shrink the log to a stupidly small size.

Please read the article I referenced.

Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1404165

homebrew01

Posted Tuesday, January 08, 2013 7:36 AM

SSCrazy

Group: General Forum Members
Last Login: Yesterday @ 11:37 AM
Points: 2,551, Visits: 7,201

If you have databases in "FULL" recovery you need to backup the transaction logs. The easiest way to set this up as a new user is to use the Maintenance Plan Wizard.

Start a new plan and give it an appropriate name
Select "Backup DB Transaction Logs"
Set the Schedule to be Daily, every 15 minutes
Select "All databases"
"Create File for every database"
Select the folder location. I like to choose "sub directory for each DB" to keep it organized.

I suggest you do this right away to protect your data.

Once you have it running, you can do more reading and decide how you want to fine tune your processes, and perhaps be more selective in what and when you take backups. But right now, it's better to back up too much and too frequently.

Post #1404244

chuck.hamilton

Posted Wednesday, January 09, 2013 5:52 AM

Grasshopper

Group: General Forum Members
Last Login: Yesterday @ 1:46 PM
Points: 15, Visits: 127

If the database needs to be in FULL recovery (that means you need to be able to recover all or nearly all transactions during a restore) then you must run regular transaction log backups. You should also be running regular full backups. The simplest way to do both is by creating a maintenance plans and scheduling them to run regularly. If you want to guarantee that you can recover to within 30 minutes of a failure, you should run transaction log a backup every 30 minutes.

Your maintenance plans also need to clean up old backups that are no longer necessary.

For DBs using FULL recovery model I typically run a FULL backup weekly, a DIFF backup daily, and LOG backup every 30 minutes. The maintenance plan that runs the FULL backup deletes the old DIFF backups. The one that runs the DIFF backup deletes the old LOG backups.

Post #1404718

« Prev Topic | Next Topic »

16 posts, Page 2 of 2

««1 2

Permissions