February 5, 2018 at 6:16 am
Hi,
I have tables in databases with avg_fragmentation of 86% and a page count of 26 and even less page count on some tables.I set up a job to rebuild and organise these indexes using Ola's script.There is no change after the job runs thrice successfully .the avg_fragmentation is the still the same.How can i solve this?
Thanks
February 5, 2018 at 6:25 am
You don't - it doesn't need solving. Indexes of less than, say, 1000 pages don't benefit from maintenance. Indeed Ola's code may even specifically exclude them.
John
February 5, 2018 at 6:26 am
There is no point on a page count of 26 and I think Ola's scripts will only run when it's over 1000 pages (not 100% sure on this though).
Generally don't worry about it if it's below 1000 pages.
Thanks
February 5, 2018 at 6:49 am
Another thing to check is, what is the data type of the key column(s) of the index?
I've got several tables with 90+% fragmentation which I don't even bother with defragmenting, because the key columns (in the clustered index, no less,) are GUIDs.
February 5, 2018 at 6:58 am
Thank you to you all
February 28, 2018 at 6:45 am
tmmutsetse - Monday, February 5, 2018 6:16 AMHi,
I have tables in databases with avg_fragmentation of 86% and a page count of 26 and even less page count on some tables.I set up a job to rebuild and organise these indexes using Ola's script.There is no change after the job runs thrice successfully .the avg_fragmentation is the still the same.How can i solve this?Thanks
checking your stats will get you the most mileage
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 28, 2018 at 7:59 am
Perry Whittle - Wednesday, February 28, 2018 6:45 AMtmmutsetse - Monday, February 5, 2018 6:16 AMHi,
I have tables in databases with avg_fragmentation of 86% and a page count of 26 and even less page count on some tables.I set up a job to rebuild and organise these indexes using Ola's script.There is no change after the job runs thrice successfully .the avg_fragmentation is the still the same.How can i solve this?Thanks
checking your stats will get you the most mileage
+1000 to that.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2018 at 1:56 am
This was removed by the editor as SPAM
March 8, 2018 at 10:54 am
Lj Burrows - Thursday, March 8, 2018 1:56 AMhere is How to Reduce Fragmentation: http://www.sqlserverlogexplorer.com/how-to-find-database-fragmentation/
That's a "good" traditional article on the subject... with absolutely no mal intent directed towards you or that author (neither of you have done the experiments I have and you're both operating on "Best Practice" recommendations) the problem is that most such articles are based on supposed "Best Practices" and the testing I've been doing for about the last 3 months prove that such traditional methods actually cause performance problems because people wait too long to defrag or have a 100% fill factor on out of sorted order indexes. In the former, all the page splits that have been held off suddenly happen on the day before it's detected for defrag and in the later, page splits go absolutely crazy just as soon as the defrag is done. That is, unless the table has gotten large enough for the "Reorg" portion of most code to kick in and then it doesn't do any better than not defragging at all.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply