Sql-server – SQL Rebuild Index, Recovery Model, and db log filesize

maintenancesql-server-2008

I have a database that we currently run transaction log backups throughout the day, every 30 minutes to be exact, and we run a full backup each day at 2am.

Every Saturday at 3am, we have a job setup to rebuild the indexes on all tables.

That being said, doing the index rebuild causes our transaction log to grow greatly. I'm toying with different ideas to alleviate the extra drive space needed (approximately 25gb post re-index).

I was considering setting the database recovery model to simple prior to the rebuild task, to prevent all of the index rebuilding from being logged, and then setting it back to full once the rebuild is complete.

Is anyone else using this method? Or can anyone provide insight/advice as to why this may be a bad idea? Or any tips about how to handle huge log files while performing db maintenance tasks?

Best Answer

There are a number of considerations here:

  • Simple or full, the same data will be written to the transaction log. The difference is that in simple recovery the log will be truncated between operations, in full you need to backup the log to free log space to be re-used.
  • One or two tables might be responsible for the majority of the fragmentation. If that's the case, you might find your log growing to a similar size regardless of the recovery model.
  • You've determined that this database requires full recovery. Can you take the risk of switching to simple, a problem occurring and being unable to point-in-time restore?
  • You're maintenance process generates 25GB of log. On a state of the art, paying-through-the-nose SAN array that's not an expensive chunk of disk you need.

One approach I've taken in the past is to incorporate log backups in to the reindex/rebuild scripts. Record the log size and free percentage before processing each table, check free percentage and size afterwards. If less than x% of space is free or if log growth has occurred, backup the log.