August 14, 2013 at 12:03 pm
I just joined this company
and look at some SQL jobs they run on production server.
One of them looks really odd.
It's a weekly job that rebuilds 1625 indexes.
There are about 920 tables so it looks like they rebuild a lot of their indexes.
I am just curious if it slows the performance on the server
and why why would they do it so frequently.
It's a SQL Server 2008 R2 SP2 databse behind online Financial Application (BST Enterprise).
August 14, 2013 at 12:17 pm
Somebody read on the internet that it's good to rebuild indexes, so they created a job to do it ...
It could easily be negatively impacting other processes.
August 15, 2013 at 7:29 am
Or, if it's not causing any problems, don't fix it. I wouldn't recommend someone to automatically rebuild 1000+ indexes every week. Instead, I'd probably have a script that only rebuilds those indexes that truly need it as determined by the size of the index and the amount of fragmentation. But, if someone puts that in place and you're not seeing negative impacts... spend time where you do have problems. Rebuilding the index also results in updated statistics with a full scan as well as defragmentation of the index, so it's a "good thing."
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 15, 2013 at 7:34 am
I agree with Grant. We rebuild all of our indexes once a month, we have problems with stats skew due to parent child relationships in many tables.
As Grant said if it isn't causing any problems leave it. Concentrate on other areas.
Thanks,
Simon
August 15, 2013 at 8:12 am
Thank you all.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply