shrinking log transaction file (ldf) will break logs chain?

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 2008 » SQL Server 2008 Administration » shrinking log transaction file (ldf) will...

shrinking log transaction file (ldf) will break logs chain?

Rate Topic

Display Mode

Topic Options

Author

Message

Al-Rahim

Posted Wednesday, October 24, 2012 3:20 PM

Grasshopper

Group: General Forum Members
Last Login: Wednesday, May 08, 2013 12:02 PM
Points: 21, Visits: 140

Hi!, I've read several post about logs & shrinking, but i don't know -i can't decide- where I must ask about my problem...
Well, situation is i've a db in PRO server which have transaction log shipping to another one. The original schedule for backup log's job was "occurs every day every 15 minutes" but the trn files grows up to a big size, so i reschedule that job so now it is running every 5 minutes. However, the ldf file remains much bigger than i should like ... Question is, if I shrink it, I'll break the log chain? What do you think i must to do?

Post #1376695

george sibbald

Posted Wednesday, October 24, 2012 4:07 PM

SSCertifiable

Group: General Forum Members
Last Login: Today @ 3:21 PM
Points: 5,317, Visits: 11,307

shrinking does not break the log chain.

Make the shrink a one off operation, do not repeatedly shrink it. Be sure first of all the log does not need to be the size it currently is to support activity. the largest log is likely to be produced when your reindexing runs.

---------------------------------------------------------------------

Post #1376707

Bhuvnesh

Posted Thursday, October 25, 2012 3:44 AM

SSCrazy

Group: General Forum Members
Last Login: Thursday, June 13, 2013 7:03 AM
Points: 2,562, Visits: 3,453

Al-Rahim (10/24/2012)

However, the ldf file remains much bigger than i should like

It wil grow as it is nature of LOG file. the operation will get performed more LOG will grow , manage certain tasks like rebuild indexing , T-sql which are handling long heavy intermediate steps MEANS long-running transaction case.

So better to do proper regular log backup OR add more disk for log

-------Bhuvnesh----------
While 1 = 1 (Learning SQL....)
Click to get fast response of your post

Post #1376872

George M Parker

Posted Thursday, October 25, 2012 9:41 AM

Mr or Mrs. 500

Group: General Forum Members
Last Login: Wednesday, June 12, 2013 2:44 PM
Points: 526, Visits: 1,007

As already mentioned, there is zero impact on the log chain if you shrink the transaction log. But the question remains, why do you want to shrink the transaction log? Other than doing restores to other environments with inadequate space, there really isn't a good reason to shrink the transaction log. It grows to a certain size because it requires that amount of space to log transactions until the next transaction log backup occurs.

Typically, the index maintenance process is what causes it to grow the most. Make sure that you have a smart index maintenance process in place and do not just use the database maintenance wizard so that you are only rebuilding the indexes that are fragmented. Rebuilding an index that isn't fragmented generates a lot of unnecessary entries in the transaction log.

Check out the following two BLOGS by Kimberly Tripp:

http://www.sqlskills.com/blogs/kimberly/post/8-Steps-to-better-Transaction-Log-throughput.aspx

This one contains links to several smart index maintenance processes.

http://www.sqlskills.com/blogs/kimberly/post/Database-Maintenance-Best-Practices-Part-I-e28093-clarifying-ambiguous-recommendations-for-Sharepoint.aspx

You can also check out Ola Hallengren's scripts. I know a lot of DBA's who have implemented his maintenance scripts.

http://ola.hallengren.com/

Post #1377090

Al-Rahim

Posted Thursday, October 25, 2012 1:45 PM

Grasshopper

Group: General Forum Members
Last Login: Wednesday, May 08, 2013 12:02 PM
Points: 21, Visits: 140

I know ldf will increase 'ad infinitum' if i do not take backup log... and the TLS schema will not works if i don't. Refering to indexing... well, Olla's solution is what i've implemented in deed...

As i've wrote, my goal is to give to ldf an ideal size between it gigant current size and that wich contemplating the longest estimated transaction.That is the reason why i want to shrink a little the ldf file, desallocate the innecesary allocated space, not all the allocated space. Resources are limited, the requirement, aren't... So, we need do a balance of it.

Thanks a lot to all for suggestions.

Post #1377258

« Prev Topic | Next Topic »

Permissions