Wie kann man antworten, warum plötzlich Indizes oder Abfragen geändert werden müssen?

Ich bin Junior DBA mit 3 Jahren Erfahrung. Unsere Aufgabe ist es, Abfragen zu optimieren oder Entwicklern mitzuteilen, dass bestimmter Code neu geschrieben werden sollte oder Indizes benötigt werden.

Eine einfache Frage, die das Entwicklerteam häufig stellt, lautet: "Gestern lief es gut, was hat sich plötzlich geändert?" und wir werden gebeten, die Infrastrukturseite zu überprüfen. Die erste Reaktion auf ein Problem scheint immer darin zu bestehen, der Infrastruktur die maximale Schuld zu geben, was immer als erstes validiert wird.

Wie sollen wir auf "Was hat sich geändert" -Fragen des Entwicklungsteams beantworten? Habt ihr jemals die gleiche Situation erlebt? Wenn ja, teilen Sie uns bitte Ihre Erfahrungen mit.

Wie beantworte ich die veränderte Frage von dev?

Dies ist nicht nur bei DEV eine sehr häufige Frage, sondern gilt für jedes Team in IT und Business.

Was hat sich geändert ? ==> kann durch Zahlen und Fakten beantwortet werden.

Fakten beziehen sich zum Beispiel

• die Anzahl der Benutzer erhöhen, die auf die Datenbank zugreifen?
• Änderung des Serverkonfigurationsparameters?
• Datenbankwartung - Statistiken aktualisieren, Reorg / Rekonstruktion von Indizes nicht durchgeführt? Aus diesem Grund werden die Pläne falsch generiert!
• Datenmenge hat zugenommen?
• Auf der Netzwerkseite wurden Änderungen vorgenommen, das Betriebssystem wurde gepatcht und / oder ein neues Service Pack oder eine neue CU für SQL Server wurde bereitgestellt - ohne einen vollständigen Regressionstest Ihres Anwendungsgeschäftszyklus durchzuführen ?
• Das zugrunde liegende SAN ist plötzlich langsam geworden?

Zahlen können abgeleitet werden, wenn Sie Daten anzeigen müssen. Zum Beispiel :

• In dieser Situation ist das Baselining Ihres Servers von entscheidender Bedeutung. Dies wird das Schuldspiel lindern , da Sie die Fakten mit soliden Zahlen belegen können.
• Beginnen Sie mit dem Sammeln von Daten mithilfe von DMVs oder sp_whoisactive in einer Tabelle, damit die Daten nach einem Neustart des SQL-Servers erhalten bleiben.

(Sie müssen basierend auf Ihrer Umgebung und Ihren Anforderungen trainieren , wie oft die Daten erfasst werden sollen / welche Daten erfasst werden sollen und wie lange die Aufbewahrungsfrist dauern wird ) oder (Sie können in eine Software von Drittanbietern wie sqlsentry oder ideras Diagnosemanager investieren wird die oben genannte Arbeit für Sie erledigen) .

Nun, Sie könnten einen anderen Plan bekommen, weil:

• Der Plan könnte aus folgenden Gründen aus dem Cache entfernt worden sein:
  • ein Dienstneustart
  • manuelles Löschen des Plan-Cache
  • ein Dienstneustart oder ein Failover
  • Eine versehentliche Änderung, z. B. bestimmte sp_configureÄnderungen, kann den Cache leeren
  • Einige Änderungen an zugrunde liegenden Objekten, Indizes, Statistiken oder anderen Abhängigkeiten lösten eine Neukompilierung aus
• Möglicherweise erhalten Sie nur einen anderen Plan als die anderen Benutzer oder frühere Aufrufe, weil:
  • Der Abfragetext ist möglicherweise nicht identisch (dies schließt Groß- und Kleinschreibung und Leerzeichen ein, unabhängig von unterschiedlichen Spalten, Verknüpfungskriterien, Filtern usw.).
  • Die Abfrage kann von verschiedenen Benutzern mit unterschiedlichen Set-Optionen ausgeführt werden (oder von verschiedenen Standardschemata, wenn ein Objekt im Plan keinen vollständig qualifizierten Namen hat, einschließlich Schema ).
• Die Abfrage und der Plan können identisch sein, aber Sie erhalten möglicherweise eine andere Leistung, weil:
  • Der Plan wurde mit verschiedenen Parametern zwischengespeichert, und dieser Plan ist für den aktuellen Parametersatz nicht optimal (dies wird üblicherweise als "Parameter-Sniffing" bezeichnet).
  • Die Datenmenge basierend auf den Parametern oder einfach aufgrund von Datenänderungen in der Zwischenzeit ist erheblich unterschiedlich
  • Die Daten haben sich genug geändert, um die effizienteste Art des Zugriffs auf die Daten zu ändern, aber nicht genug, um statistische Aktualisierungen oder Neukompilierungen auszulösen (Suche nach aufsteigendem Schlüsselproblem sowie Algorithmus für automatische Statistiken).
  • Die Daten wurden aus dem Pufferpool entfernt und müssen nun von der Festplatte gelesen werden
  • Es gibt eine höhere Parallelität, Blockierung oder andere Belastungen für Ressourcen, die zur Erfüllung der Abfrage erforderlich sind

Ich gehe hier viele davon genauer durch:

• Mehrere Pläne für eine "identische" Abfrage

Wenn diese in verschiedenen Umgebungen ausgeführt werden, muss ich hier eine ganze Reihe von Dingen überprüfen:

• Unterschiedliche Pläne für "identische" Server

Es ist auch wichtig zu beachten, dass das Erstellen eines Index oder das Ändern der Abfrage möglicherweise nicht der direkte Grund dafür ist, dass eine Abfrage plötzlich eine bessere Leistung erbringt. Manchmal liegt dies nur daran, dass diese Änderungen tatsächlich einen neuen Plan generiert und / oder den bereits vorhandenen ungültig gemacht haben .

Wie üblich gaben Aaron Bertrand und Kin hervorragende Antworten. Beide Antworten enthalten jedoch einen gemeinsamen Thread. Wenn Sie eine der Antworten analysieren, werden Sie feststellen, dass der Grund, warum XYZ nicht so funktioniert wie gestern, nicht in etwas liegt, das Sie / sie / Person X getan haben. Der Grund, warum sich die Dinge geändert haben, ist, dass die Datenbank aus XYZ-Gründen beschlossen hat, die Dinge anders zu machen.

Eine Datenbank ist eine lebende, atmende Einheit . Datenbanken treffen Entscheidungen und ändern ihre Meinung aufgrund einer Kombination aus Annahmen, Statistiken und anderen heuristischen Werkzeugen. Dies unterscheidet sich erheblich von den meisten Programmen auf Anwendungsebene (maschinelles Lernen ist eine bemerkenswerte Ausnahme).

_{Ich werde einige militärische Referenzen verwenden, weil ich mir momentan nichts Besseres vorstellen kann. Eine allgemeinere Metapher wäre wünschenswert (kein Wortspiel beabsichtigt).}

In den meisten Anwendungen fungiert der Programmierer als Drill Instructor. Sie sagen dem Computer genau, was zu tun ist, in welcher Reihenfolge und manchmal wie lange. Das Programmieren einer Datenbank ähnelt eher dem Kommandieren. Sie sagen ihm, was er auf hohem Niveau tun soll, und bieten bei Bedarf eine Anleitung an. Die Datenbank übernimmt die Aufgabe, herauszufinden, wie der Plan auf der Grundlage aktueller Erkenntnisse wie der Junior-Offiziere und der Unteroffiziere am besten ausgeführt werden kann.

Indem sie diese Unterscheidung in den Köpfen der anderen Programmierer deutlich machen, werden sie hoffentlich erkennen, dass Sie keine diktatorischen Kräfte haben, wie sie es in ihrer Umgebung tun. Sie führen die Datenbank zur Lösung, und gelegentlich gerät die Datenbank aus guten oder schlechten Gründen aus der Spur. Erinnern Sie sie daran, dass es am Ende keine Rolle spielt, warum * die Datenbank vom Kurs abgekommen ist, sondern was wir tun können, um sie zurückzubringen.

_{* Ich erkenne, dass "warum" für die zukünftige Prävention, das Lernen usw. sehr wertvoll ist, aber es scheint, dass das OP auf Widerstand von Menschen stößt, die nicht versuchen, das Problem kennenzulernen oder ihm zu helfen.}