In SQL Server 2016 laufen Statistikaktualisierungen im Beispielmodus jetzt parallel unter Kompatibilitätsgrad 130, und so funktioniert es standardmäßig für alle automatischen und manuellen Statistikaktualisierungen. Dies wird hier kurz erklärt:
- Ergänzungen des Abfrageoptimierers in SQL Server 2016
(Die Dokumentation wurde ebenfalls aktualisiert, sowohl das Thema zum Kompatibilitätsgrad als auch das Thema UPDATE STATISTICS.)
Wäre es nicht schön, angeben zu können, wie viele CPUs tatsächlich für diese Operationen verwendet werden können (abgesehen davon, dass nur die Obergrenze von 16 zugelassen wird)? Ich denke, dass die Möglichkeit, dies auf 4 oder 8 zu begrenzen, eine offensichtliche und logische Sache wäre, die es zu unterstützen gilt. Besonders für Kunden, die Systeme mit 16 oder weniger Kernen oder mehrere Instanzen auf einer Box betreiben, die sich nicht auf Enterprise-Funktionen wie Resource Governor verlassen können (die die meisten Enterprise-Kunden meiner Meinung nach auch nicht stören würden).
Die geschäftliche Begründung dafür wäre dieselbe wie die Begründung für das Hinzufügen von MAXDOP-Unterstützung REBUILD, DBCC CHECKDB und seiner Familie von Wartungsvorgängen usw. Sie möchten verhindern, dass diese Art von Aktivität alle Kerne übernimmt, ohne etwas so Drastisches zu tun wie das Deaktivieren von automatischen Updates oder die Verwendung von instanzweitem MAXDOP – denn nicht jeder hat den Luxus von Wartungsfenstern.
Und in diesem Fall hilft instanzweites MAXDOP sowieso nicht , weil SQL Server 2016 RTM einen Fehler hat, bei dem MAXDOP ignoriert wird für aktualisierte Stichprobenstatistiken. Eine Lösung steht bevor, aber ich dachte, Sie sollten es wissen; Wenn dies ein Problem verursacht, besteht eine Möglichkeit darin, eine niedrigere Kompatibilitätsstufe zu verwenden.
Aber ich werde wiederholen, was ich oft sage:Das Kompatibilitätsniveau wird viel zu voll. Wenn ich parallel abgetastete Statistiken in meiner Datenbank haben möchte, aber genug Kardinalitätsschätzungsregressionen habe, um das alte CE zu benötigen, muss ich mich für das eine oder andere entscheiden.
Und noch etwas:Resource Governor ist für diesen Anwendungsfall übertrieben, und die Begrenzung der Kernnutzung durch Statistikaktualisierungen sollte nicht wirklich ein Enterprise-Feature sein (genau wie das oben erwähnte REBUILD und CHECKDB). Sagen Sie mir bitte nicht, dass RG eine akzeptable Alternative ist, da dies nur für Benutzer mit Enterprise Edition *und* Workload-Klassifizierungen möglich ist, die ständig durch MAXDOP eingeschränkt werden sollten . Ich sollte in der Lage sein, dies durch bestimmte Operationen (oder sagen wir nur für meine größten/problematischen Tabellen) einzuschränken, nicht indem ich die gesamte Sitzung eines Logins einschränke.
Wie ich wünschte, sie würden es tun
Idealerweise könnten wir dies auf Datenbankebene mit der neuen Option DATABASE SCOPED CONFIGURATION und auf Anweisungsebene mit der vertrauten OPTION (MAXDOP n)-Syntax festlegen. Die Anweisungsebene würde gewinnen, und alle Statistikaktualisierungen im Stichprobenmodus (einschließlich automatischer) ohne einen expliziten MAXDOP-Hinweis würden auf die Einstellung der Datenbankebene zurückgreifen. Damit könnte ich beispielsweise einen MAXDOP von 4 für alle automatischen Statistikaktualisierungen festlegen, die zu unvorhersehbaren Zeiten erfolgen, aber 8 oder 16 für manuelle Vorgänge in bekannten Wartungsfenstern. Als ein Beispiel.
Wenn Sie dafür stimmen möchten, sehen Sie sich bitte den folgenden Connect-Artikel an und fügen Sie eine geschäftliche Begründung dafür hinzu (a la Michael Campbell):
- Connect #628971 :MAXDOP-Parameter zu Statistik aktualisieren hinzugefügt
Natürlich gibt es diesen Punkt seit 2010, also wird die DATABASE SCOPED CONFIGURATION-Allee überhaupt nicht erwähnt, weshalb ich auch einen Kommentar hinterlassen habe.
Wenn Sie in der Zwischenzeit die Parallelität für den Beispielmodus deaktivieren möchten, gibt es ein Trace-Flag, um effektiv zu älterem Verhalten zurückzukehren (Sie können dies auch tun, indem Sie zu einem Kompatibilitätsgrad von weniger als 130 zurückkehren, aber ich empfehle dies nicht, weil es beeinflusst viele andere Dinge). Ich werde diesen Bereich aktualisieren, wenn ich das Okay erhalten habe, das Trace-Flag öffentlich offenzulegen, aber im Moment hält Microsoft es fest an ihrer Brust.
