January 22, 2020 at 6:28 am
Hi All,
The DBA who was before me had used the Ola's code in the sql job. But as i found out, it did not removed fragmentation. So i tried to make a script of my own to accomplish the task. @jeff : Thanks brother, i ll keep those points in mind while re-creating another script shortly.
January 22, 2020 at 12:45 pm
Hi All,
The DBA who was before me had used the Ola's code in the sql job. But as i found out, it did not removed fragmentation. So i tried to make a script of my own to accomplish the task. @jeff : Thanks brother, i ll keep those points in mind while re-creating another script shortly.
Keep in mind that it's not the fault of Ola's code. It was how Ola's code was used... probably in a 5 or 10/30 mode. Larger indexes get stuck in the REORGANIZE mode because they fragment less quickly than small indexes.
I do agree that Ola's code handles things rather homogeneously. Different insert and update patterns deserve different handling based on both logical fragmentation and page density. And large indexes deserve special handling to keep from blowing out the MDF file with possibly tons of unwanted free-space.
I'm still testing an auto-assignment for Fill Factors but I can tell you that if you have indexes that begin with Random GUIDs, start by REBUILDing them at 81% and REBUILD them as soon as they go over 1% logical fragmentation. If they need defragmentation more than about once per month, then you're either doing a crazy number of inserts (try dropping the Fill Factor to 71% and see what happens) or you're dealing with "ExpAnsive" updates that "don't fit", which will need to be fixed somehow.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply