Wie viel Zeit verbringen Sie als Datenbankadministrator oder -entwickler mit der Behebung von Leistungsproblemen? Hast du es schon mal verfolgt? Als durchschnittlicher Gesamtprozentsatz Ihres Tages mag es nicht nach viel Zeit aussehen, aber wenn das Problem ernst ist, können Sie Stunden damit verbringen, es aufzuspüren und an der Ursachenanalyse zu arbeiten. Manchmal verschwindet das Problem und Sie kennen den wahren Ursprung nicht. Und noch schlimmer? Wenn Sie mitten in der Nacht oder am Wochenende mit diesen Problemen kämpfen müssen. Sie kämpfen nicht nur darum, ein Problem zu lösen, sondern verlieren auch Ihre persönliche Freizeit. Wie lindern wir das? Wie können wir unsere Zeit und Mühe aus der Gleichung herausnehmen und gleichzeitig die Leistung verbessern?
Die Funktion „Automatische Optimierung“ in SQL Server 2017 Enterprise Edition und Azure SQL-Datenbank ist der erste Schritt, um die Zeit zu reduzieren, die Datenfachleute mit der Fehlerbehebung und Lösung von Leistungsproblemen verbringen. Das Feature umfasst die automatische Plankorrektur und die automatische Indexverwaltung (nur in Azure SQL-Datenbank verfügbar), die unabhängig voneinander aktiviert werden. In diesem Beitrag möchte ich mich auf die automatische Plankorrektur konzentrieren. Wenn SQL Server bei der automatischen Plankorrektur feststellt, dass eine Abfrage erheblich zurückgegangen ist, wird der letzte bekannte gute Plan für die Abfrage erzwungen, um die Leistung zu stabilisieren. Anstatt dass Sie, der DBA oder Entwickler, am Wochenende wegen der Systemleistung angerufen werden, kümmert sich im Wesentlichen SQL Server darum. Klingt zu einfach, oder? Schauen wir uns das mal an.
Unter der Decke
Zunächst ist es wichtig zu verstehen, dass die automatische Plankorrektur den Abfragespeicher verwendet und daher für die Datenbank aktiviert werden muss. Zweitens ist die automatische Plankorrektur einfach eine automatische Planerzwingung. Während Query Store als Flugschreiber für Ihre Datenbank vermarktet wird, der Abfragetext, Pläne, Laufzeitstatistiken und Wartestatistiken verfolgt, ermöglicht es Ihnen auch, einen Plan für eine Abfrage zu erzwingen, um eine konsistente Leistung zu ermöglichen. Bei der automatischen Plankorrektur wird der Plan ohne Ihr Zutun erzwungen.
Automatische Tarifkorrektur aktivieren
Wie bereits erwähnt, muss der Abfragespeicher zunächst für die Benutzerdatenbank aktiviert werden. Dies kann in SSMS, mit T-SQL und mit der REST-API für Azure SQL-DB erfolgen. Beachten Sie, dass der Abfragespeicher standardmäßig für Datenbanken in Azure aktiviert ist, und zwar seit Q4 2016.
Aktivieren des Abfragespeichers über SSMS
USE [master]; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE (OPERATION_MODE = READ_WRITE); GO
Abfragespeicher mit T-SQL aktivieren
Der obige Code ist das standardmäßige T-SQL von SSMS, wenn Sie es per Skript ausführen. In Azure SQL-Datenbank führen Sie die USE-Anweisung nicht aus. Wenn Sie eine der Standardoptionen ändern möchten, lesen Sie bitte meinen Beitrag zu den Einstellungen des Abfragespeichers zu diesen Optionen und Überlegungen zu alternativen Werten.
Sobald der Abfragespeicher aktiviert ist, können Sie das Azure-Portal, T-SQL oder die EST-API verwenden, um die automatische Plankorrektur in Azure SQL-Datenbank zu aktivieren ((und C# und PowerShell sind in Arbeit). Sie kann nur mit T-SQL aktiviert werden in SQL Server 2017.
Aktivieren der automatischen Plankorrektur im Azure-Portal
ALTER DATABASE [WideWorldImporters] SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON ); GO
Automatische Plankorrektur in T-SQL aktivieren
Beachten Sie, dass die automatische Plankorrektur in naher Zukunft standardmäßig für neue Datenbanken in Azure aktiviert wird. Ab Januar 2018 wird die automatische Optimierung für Azure SQL-Datenbanken aktiviert, für die sie noch nicht aktiviert war, wobei Benachrichtigungen an Administratoren gesendet werden, damit die Option bei Bedarf deaktiviert werden kann.
Wie es funktioniert
Wenn die automatische Plankorrektur aktiviert ist, überwacht SQL Server die Abfrageleistung mithilfe von Abfragespeicherdaten. Es sucht nach einer signifikanten Änderung* der CPU**-Leistung mit einem 48-Stunden-Fenster***. Beachten Sie die Sternchen in diesem Satz … diese sind absichtlich:
- *Der Schwellenwert für eine signifikante Änderung ist nicht dokumentiert, da Microsoft sich das Recht vorbehält, ihn zu ändern.
- **Die zur Bestimmung der Leistungsänderung (CPU) verwendete Metrik ist nicht dokumentiert, da Microsoft sich das Recht vorbehält, sie zu ändern. Das heißt, Microsoft könnte zusätzliche Dimensionen in Betracht ziehen, um die Leistung zu betrachten, wenn diese besser/leistungsstärker wäre als die CPU allein.
- ***Der Zeitraum, über den die Abfrageleistungsdaten verglichen werden, ist aus demselben Grund nicht dokumentiert, Microsoft behält sich das Recht vor, ihn zu ändern.
- Hinweis:Obwohl die oben genannten Punkte nicht dokumentiert sind, habe ich mit den zuständigen Personen bei Microsoft bestätigt, dass diese Informationen mit dem Brechen von Geheimhaltungsvereinbarungen geteilt werden können. Es ist äußerst wichtig zu verstehen, dass die Werte nicht festgelegt sind und sich ändern können, mit der Erwartung, dass sie sich ändern würden, um die Zuverlässigkeit der Funktion zu verbessern.
Der Mangel an Dokumentation und die Möglichkeit, den Schwellenwert zu ändern, kann für manche Personen frustrierend sein, aber hier ist, was wirklich wichtig ist:
Microsoft erfasst täglich Terabytes an betrieblichen Telemetriedaten aus SQL Azure-Datenbanken, und diese Daten sind entscheidend für die automatischen Funktionen, die entwickelt werden. Diese Daten umfassen Dinge wie query_id, query_plan_id und query_hash, und Microsoft erfasst NICHT query_text oder query_plan (sie betrachten nicht Ihre tatsächlichen Daten). Microsoft archiviert diese betrieblichen Telemetriedaten nicht einfach oder verwendet sie zur Fehlerbehebung, sondern sie analysieren diese Daten und verwenden sie zur Entwicklung von Algorithmen und Modellen, die es SQL Server ermöglichen, unabhängige, intelligente Entscheidungen zu treffen.
SQL Server kann die Fülle von Daten im Abfragespeicher nutzen, die die Leistung von Abfragen detailliert beschreiben, und die automatische Plankorrektur beginnt mit dem Vergleich der aktuellen Leistung einer Abfrage mit der früheren Leistung, um festzustellen, ob eine Leistungsregression vorliegt. Hat sich die Leistung verringert oder verschlechtert, und wenn ja, ist sie erheblich?
Wenn die Abfrageleistung zurückgegangen ist, erzwingt SQL Server den letzten bekannten guten Plan für diese Abfrage, der natürlich aus dem Abfragespeicher abgerufen wird. Aber es bleibt nicht dabei. SQL Server überwacht dann weiterhin die Leistung – immer noch unter Verwendung des Abfragespeichers – um zu bestätigen, dass der erzwungene Plan immer noch ein guter Plan für diese Abfrage ist, was bedeutet, dass die Abfrage mit dem erzwungenen Plan eine bessere Leistung als die regressive Version erbringt. Wenn diese Abfrage keine bessere Leistung erbringt, wird der Plan aufgehoben. Das Forcen eines Plans kann auch aufgehoben werden, wenn eine Neukompilierung erfolgt oder das Forcen fehlschlägt.
Dieser Zyklus geht weiter; Wenn eine Abfrage einen erzwungenen Plan hat und dieser Plan dann aus einem der oben genannten Gründe nicht erzwungen wird, kann derselbe Plan später erneut erzwungen werden, oder es kann ein anderer Plan für diese Abfrage zu einem späteren Zeitpunkt erzwungen werden. Dies ist ein kontinuierlicher Prozess, der auftritt, solange Sie die Option Automatische Plankorrektur für die Datenbank aktiviert haben. Interessant ist nun, dass Sie sich dieselben Informationen ansehen können, die diese Funktion erfasst, und sie verwenden können, um Pläne manuell zu erzwingen. Das heißt, in SQL Server 2017 Enterprise Edition und in Azure SQL-Datenbank werden diese Daten in der DMV „sys.dm_db_tuning_recommendations“ erfasst, selbst wenn die Funktion „Automatische Plankorrektur“ nicht aktiviert ist, sodass Sie diese Daten untersuchen und ihren Empfehlungen folgen können, um Pläne zu erzwingen für spezifische Anfragen in Eigenregie. Beachten Sie, dass, wenn Sie einen Plan mithilfe von Empfehlungen aus sys.dm_db_tuning_recommendations erzwingen, dieser nie automatisch aufgehoben wird. Wenn Sie außerdem die automatische Plankorrektur aktiviert haben und einen Plan manuell erzwingen, wird er niemals automatisch aufgehoben. Nur Pläne, die mit der automatischen Plankorrekturfunktion erzwungen wurden, werden automatisch aufgehoben.
Werde ich SQL Server wirklich die Kontrolle überlassen?
Wenn Sie skeptisch sind und sich fragen, ob Sie SQL Server wirklich vertrauen können, um eine planerzwingende Entscheidung zu treffen, sollten Sie sich Folgendes merken:
- Diese Funktion wurde mit einer erstaunlichen Menge an Daten entwickelt, die aus fast zwei Millionen Azure SQL-Datenbanken erfasst wurden. Es ist ein neues Feature in SQL Server 2017, aber es hat es 2016 in Azure in die globale Verfügbarkeit geschafft, sodass dieses Feature wirklich seit weit über einem Jahr verfügbar ist und verfeinert wurde.
- Die Ingenieure haben im Laufe der Zeit Änderungen am Algorithmus vorgenommen, da sie mehr Daten erfasst haben. Es findet möglicherweise nicht jede auftretende Regression – da eine Regression möglicherweise nicht schwerwiegend genug ist, aber ich würde wetten, dass viele von Ihnen diese Funktion lieber seltener als zu oft erzwingen möchten.
- Darüber hinaus ist die Fähigkeit von SQL Server, sich davon zu erholen und die Erzwingung des Plans aufzuheben, äußerst zuverlässig und geschieht sehr schnell, wenn ein Plan erzwungen wird, aber am Ende ein Problem verursacht.
Zusammenfassung
Möglicherweise sind Sie mit der Idee nicht einverstanden, dass SQL Server Leistungsprobleme für Sie angeht. Aber ist das Unbehagen, weil Sie denken, dass es eine schlechte Entscheidung treffen wird? Oder befürchten Sie, dass die Automatisierung Ihren Job übernimmt? Ziemlich direkte Frage, ich weiß. Wenn es ersteres ist, empfehle ich, sich die in sys.dm_db_tuning_recommendations erfassten Daten anzusehen (ohne die automatische Plankorrektur zu aktivieren) und zu sehen, was SQL Server tun möchte. Stimmt es mit dem überein, was du tun würdest? Findet es Regressionen, die Sie möglicherweise übersehen? Wenn Sie die Funktion nicht aktivieren möchten, weil Sie befürchten, dass Sie plötzlich nicht mehr genug zu tun haben, empfehle ich Ihnen, den kürzlich erschienenen Beitrag von Conor Cunningham zu lesen, „Wie Cloud-Geschwindigkeit SQL Server-DBAs hilft“. Microsoft versucht nicht, Sie arbeitslos zu machen. Sie versuchen einfach, mit den niedrig hängenden Früchten umzugehen, damit Sie sich auf wichtigere Aufgaben konzentrieren können.