Lang geleden publiceerde ik Connect-samenvattingen - kleine berichten die een paar bugrapporten of suggesties over Connect naar voren brachten waarvan ik dacht dat ze meer aandacht verdienden. Nu zal ik dit zeggen:ik ben niet echt een grote fan van een systeem waarbij de persoon met de meeste vrienden die willen stemmen zijn of haar zin krijgt, omdat het SQL Server-team ruis moet kunnen negeren of uitstellen, en zich moet concentreren op de belangrijkste en meest impactvolle bugs of suggesties. Maar zo doen ze dat niet in Redmond . Dus vandaag heb ik een verzoek:help me door te stemmen en commentaar te geven op deze drie Connect-items, die allemaal bedoeld zijn om de werking van SQL Server-statistieken te verbeteren.
(Houd er rekening mee dat opmerkingen veel meer gewicht in de schaal leggen dan alleen stemmen, dus vermeld uw businesscase, als u er een heeft die kan worden gedeeld.)
MAXDOP hint voor UPDATE STATISTIEKEN
SQL Server 2016 heeft een MAXDOP-hint toegevoegd voor DBCC CHECK-opdrachten, dus waarom niet voor stats-updates? Op gepartitioneerde tabellen kan dit een grote impact hebben op de rest van de werklast. We zouden ook in staat moeten zijn om de door het systeem gedefinieerde MAXDOP te overschrijven voor automatische statistiekupdates, maar voor nu zou ik blij zijn met meer controle over handmatig statistiekbeheer. Het verzoek wordt vastgelegd in het volgende Connect-item:
- Connect #628971:MAXDOP-parameter toevoegen om statistieken bij te werken
Laat de query-optimizer statistieken op partitieniveau zien
Erin Stellato heeft hier geblogd over de voordelen van incrementele statistieken, maar slaat in dit bericht echt de spijker op de kop over de problemen:incrementele statistieken worden NIET gebruikt door de Query Optimizer. Lees dat alsjeblieft door en stem en becommentarieer het item dat ik zojuist heb gemaakt (ik kan niet geloven dat het me nooit is opgevallen dat hier nog geen DCR voor bestond):
- Connect #2010834:Optimizer zou eigenlijk *per-partitiestatistieken moeten gebruiken
Auto-statistieken moeten rekening houden met het aantal rijen in een gefilterde index/statistiek
Momenteel is vertrouwen op automatische updates van gefilterde indexen en statistieken vergelijkbaar met Wachten op Godot:het algoritme gebruikt het aantal rijen in de tabel bij het bepalen van de churn-drempel, niet het aantal rijen in de index. Dit betekent dat de meeste gefilterde indexen – en inderdaad de meest bruikbare gefilterde indexen - worden nooit automatisch bijgewerkt. (Ik heb het hier hier over, en Kimberly Tripp praat er hier en hier over. Ik weet zeker dat anderen er ook over hebben geblogd.) Ik denk dat het tijd is om hier verandering in te brengen - als je het ermee eens bent, stem en reageer dan op het item van Joe Sack (de titel geeft gefilterde statistieken aan, maar het heeft echt betrekking op beide):
- Connect #509638:wijziging voorstellen voor gefilterde statistiekenupdates