SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Log size is Big


Log size is Big

Author
Message
anthony.green
anthony.green
SSChampion
SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)

Group: General Forum Members
Points: 10041 Visits: 6303
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
When a question, really isn't a question - Jeff Smith
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


GilaMonster
GilaMonster
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86358 Visits: 45232
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, MVP, M.Sc (Comp Sci)
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


DIB IN
DIB IN
Valued Member
Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)

Group: General Forum Members
Points: 51 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)
GilaMonster
GilaMonster
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86358 Visits: 45232
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, MVP, M.Sc (Comp Sci)
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


homebrew01
homebrew01
SSCarpal Tunnel
SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)

Group: General Forum Members
Points: 4777 Visits: 9108
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.



chuck.hamilton
chuck.hamilton
SSC-Enthusiastic
SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)

Group: General Forum Members
Points: 152 Visits: 395
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.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search