SQL transaction log growth during maintenance plan

I have a reasonably large database (25GB) with a backup plan:

Full database backup daily at 10pm
Transaction log backup every 30minutes between 8am - 9.30pm

Additionally there is a maintenance plan which runs at midnight.

When the maintenance plan runs the transaction log grows to about 6GB.
Why is this? Could it/should it be avoided?

When the transaction log backups start in the morning, I "think" the log is cleared down (when I checked at 9am it was 98% free space) but after several hours (a few more transaction log backups) it eventually shrinks back to 10MB (and will remain roughly this size throughout the day).
Why is this? Could it/should it be avoided?


LVL 11
Who is Participating?
mastooConnect With a Mentor Commented:
A source as to frequency of index maint?  If we can count microsoft mvp discussions as authoritative, this discusses it and has a few good links itself:


and yes, tailoring your index maint can reduce the impact but is just slightly more work
Andrei FomitchevCommented:
What your maintenance plan does? - What steps are included in it?

There is SHRINK step - it decreases LOG SIZE.
tickettAuthor Commented:
Check Database Integrity
Reorganize Indexes
Update Statistics
Shrink Database
Clean Up History

And the option is set to "Return freed space to the operating system".
What Kind of Coding Program is Right for You?

There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.

As you backup your transaction log every half an hour, it's probably at very low size all over the day, as it get shrinked after the backup.

However, when you run your maintenance plan, lots of operations get made and are pushed to the log.

I would try to run the maintenance plan operations separately seeing the growth of the transaction log between each one of them. If there is any of the operations specially hard with operations on transaction log I would try to make a log backup after that operation.
tickettAuthor Commented:
I think I'm more looking for a best practice solution? It almost makes sense why it is happening (although it definitely doesn't seem right- surely SQL is designed better than that!?). This would be a common issue and there must be a common solution/best practice approach?

Sincerely I don't know, I'm not a dba, only have some knowledge of it.
You might rethink the reorg indices nightly.  They might be happy with a weekly index maintenance depending on the database volatility.

And regardless, don't worry about shrinking the database each night.  You need sufficient disk space for the max size each day anyway, so you might as well let it stabilize at the larger size.
tickettAuthor Commented:
Thanks Bardobrave

mastoo: can you state a source? i think what you're saying is probably right but was hoping for more reasoning/documented practice.

I have found scripts in the past which identify certain indexes based on the number of pages and fragmentation- so it might be that i need to drop the maintenance plan and actually run my own custom script to only process the tables/indexes which need to be improved.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.