Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Log size is Big Expand / Collapse
Author
Message
Posted Tuesday, January 8, 2013 3:56 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Wednesday, August 27, 2014 8:53 AM
Points: 5,218, Visits: 5,072
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
Posted Tuesday, January 8, 2013 4:15 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Yesterday @ 7:53 AM
Points: 42,822, Visits: 35,952
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
Posted Tuesday, January 8, 2013 4:39 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, March 6, 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
Posted Tuesday, January 8, 2013 5:07 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Yesterday @ 7:53 AM
Points: 42,822, Visits: 35,952
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
Posted Tuesday, January 8, 2013 7:36 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, August 22, 2014 12:24 PM
Points: 2,829, Visits: 8,477
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
Posted Wednesday, January 9, 2013 5:52 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, August 27, 2014 7:28 AM
Points: 50, Visits: 240
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 »

Add to briefcase ««12

Permissions Expand / Collapse