Steve Jones - SSC Editor wrote:
Change is change. Whether its better or not is something we have to evaluate, test, experiment with, and decide. I worry about people getting caught up in thinking we need to change or we need to not change.
Often the best choice is situational.
What I worry about is when change is actually for the worse as in often the only choice is damaging and there is no real choice. So many people institutionalize change as being something that is absolutely necessary and that something is wrong if there isn't change. There's also a whole lot of times when changes for the worse leave us no choice in the matter, something that Microsoft has recently gotten very good at.
For example, Microsoft's "Fast Inserts" killed me. This is where "they" decided to "help" people that may not know better and make it so that, rather than spend the time to check to see if any partially full extents are available to be populated during inserts, they decided that it would be better to just allocate full extents for every "insert bulk" (and similar but not to be confused with BULK INSERT)... even if it's just for one freakin' row!!! That caused my WhatsUp Gold database to grow to well over 50GB even though there was only 8GB worth of data. The rest was all "allocated but unused" and the only way to fix the wasted space is to rebuild then affected indexes. Fortunately, they DO allow us to get around that by invoking Trace Flag 692 but most people don't realize the extra load placed on index maintenance because of it and, because their index maintenance "covers up the steamer", most people aren't even aware because it's not exactly well advertised (the problem found me and I had no inclination except for a random post that I wasn't even looking for and was getting ready to blame the vendor). For ever increasing indexes, they might not realize it for quite a while.
Then there's the double whammy of SET IDENTITY INSERT ON forcing a SORT in TempDB even during BULK OPERATIONs on empty tables when the source table is already sorted by a Clustered Index and the fact that they did the equivalent of PERMANENTLY invoking Trace Flag 1117 on TempDB with no option to temporarily disable it. Imagine my surprise when I tried to copy a small 25GB table from one database to another causing my 8 file 100GB TempDB drive to fill up because each of the files insisted on growing to 25GB (25GB * 8 > 100GB) and blow a weekend project out of the water as a result.
As you say, change is good if it's tested but it appears that Microsoft has virtually no practical experience in what people actually need to do. All this automatic "improvement" coming up in 2019 scares the cannolies out of me. The "It just runs faster" initiative has made it so that some of my stuff just doesn't run at all (it used to) and I'm left with coming up with panic work-arounds.
So change is NOT change. Sometimes it's a totally wasted and damaging effort that some of us have no choice in. I'll say it again...
"Change is inevitable... change for the better is not" ...
... and, especially lately, MS has not been good at it. What's next? Them putting data centers in glorified sewer pipes with end-caps and a bazillion sacrificial anodes on them and then putting them in the oceans to dissipate heat? Funny I should ask...
I'm sure that someday soon we'll be reading about how a foreign country built a submarine to steal the damned things out from under our noses. If I had the money, I'd build a thief sub myself just to prove the point. Who needs "ransomware"? 😀 Might not be enough time, though. Those sacrificial anodes don't last as long as some may expect, especially if they're using the hull as a ground and it's not a single point ground attached to the hull.