Rebuild index job massively increased DB size. How to get back down?

[Danster]

As a general rule, I like to keep my databases reasonably efficient by running a Maintenance Plan to Rebuild Indexes and Update Statistics. Generally do it weekly.

I was forgetting about FILL FACTOR, and the default for the instance is set to 0, which is what the Maint Plan job uses, so I changed the task to use a fill factor of 90% which I reckon is a nice compromise between reading and writing. i.e the setting reads "Change free space per page percentage to". I set it to 90. Should it have been 10% ?

When the task ran over the weekend, the database (and corresponding BAK) massively blew out in size from about 3.5Gb to 27Gb. On the bright side, the users did note a minor improvement in database responsiveness. Disk space is at a premium on this site, and throwing disk space into the server ain't going to fly.
I want to shrink the database back down to what it was, so I set the Maint task back to use the "reorganise pages to use the default amount of free space". The instance has a default index fill factor = 0.

So the maintenance ran overnight, and the database increased again from 27Gb to about 33Gb!! Running s SHRINKDATABSE would decrease the size from around 33Gb do 27Gb roughly, but ideally I need to get it back down to 3.5Gb.

Any advice appreciated

 

[Danster]

Sorted (I think). I copied the database to another database for testing so I don't impact the live database. I found I fixed it by:
Running my own REBUILD INDEXES script rather than using the Maintenance Plan. I set a FILL FACTOR of 90. After this ran to completion over the whole database, the size had not shrunk.
Ran the SHRINKDATABASE and bingo!

Methinks the whole problem lay in the Maintenence Plan which I set Change Free Space Page percentage to 90. From recollection of past readings, I think this is the inverse of fill factor, so really I should've had it at 10. I guess I could google that to be sure!

Anyway, I have set up a SQL Agent job to do the REBUILD INDEX and then SHRINKDATABASE and then UPDATE STATISTICS, so hopefully tomorrow the live database should be back to normal.

cheers

 

[mjldba]

If you're using a FULL recovery model then rebuilding indexes is growing your log file (ldf). I suggest doing a transaction log backup and then shrinking the log file.

If you're using a SIMPLE recovery model then rebuilding indexes is growing your data file (mdf). If you do a SHRINKDATABASE you will recover unused space in your data file but you'll find that you're also heavily fragmenting the indexes that you just defragged by rebuilding.

There's no need to UPDATE STATISTICS after rebuilding indexes because rebuilding indexes does that for you.

FILL FACTOR 0 means the same as FILL FACTOR 100 which means "leave no (or very little) free space on a page. FILL FACTOR 90 means "leave 10% of every page available for growth" so if you use a fill factor of 10 that means "leave 90% of every page available for growth" and your mdf file will grow to be huge with lots of empty unused space.