Nice job, Mike.
One of the biggest problems is that there are a huge number of common circumstances where lowing the FILL FACTOR will do absolutely nothing to prevent the page splits. Most of these circumstances occur when you have a large number of "Append Only" Inserts followed by (usually) "ExpAnsive" Updates. The Inserts will NOT follow the FILL FACTOR. Instead, they will fill each page to the max (approaching 100%) as the average row size will allow. When those same rows are Updated with "ExpAnsive" Updates, they're virtually guaranteed to split.
That's really, really bad and not just for Selects. Paul Randal demonstrates that a bad (he calls them "nasty") page split will take 4.5 to 43 times longer longer than a good one. Since these types of splits are all happening on the latest data and they're all very close together at the logical end of the index, you all get massive blocking for other Inserts not to mention for Selects. It also causes a shedload of extra activity on the log file and that can slow a whole lot more down than just things having to do with the given table.
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
"If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
"Change is inevitable... change for the better is not."
When you put the right degree of spin on it, the number 3|8
is also a glyph that describes the nature of a DBAs job. 😉
How to post code problems
Create a Tally Function (fnTally)