Nach der Azure-Migration langsamer? So grenzen Sie die Ursache ein

Der schnellste Einstieg: eine Beobachtung einordnen

Was beobachten Sie? Wählen Sie die passende Karte; sie führt zum ersten Schritt.

Die Beobachtung bestimmt den Einstieg. Eine Ursache ist damit noch nicht nachgewiesen.

Schritt 1: Die langsame Arbeit genau benennen

Wählen Sie einen konkreten Vorgang: einen Auftrag speichern, eine Liste öffnen oder einen bestimmten Import ausführen. Notieren Sie Beginn, Ende, beteiligte Anwendung und die fachlichen Eingaben. „Die Datenbank ist langsam“ ist als Arbeitsauftrag zu ungenau.

Klären Sie anschließend, welche Zeit gemessen wurde. Die Antwortzeit in der Anwendung kann Verbindungsaufbau, mehrere Datenbankaufrufe, Ergebnisübertragung und weitere Verarbeitung enthalten. Die Laufzeit eines SQL-Statements beschreibt einen anderen Ausschnitt.

Wenn ein Vorgang viele Datenbankaufrufe nacheinander ausführt, kann seine Antwortzeit steigen, während die einzelnen SQL-Aufrufe ähnlich schnell bleiben. Umgekehrt kann eine einzige teure Abfrage den größten Teil der Zeit bestimmen.

Halten Sie drei Werte getrennt fest: die Antwortzeit des gesamten Vorgangs, die Anzahl seiner Datenbankaufrufe und die gemessenen Zeiten auf der Datenbankseite. Überlappende oder asynchrone Arbeit muss bei der Zuordnung berücksichtigt werden.

Eine gemessene Differenz zwischen Anwendungs- und Statementzeit ist nicht automatisch reine Netzwerklatenz. Dazu können auch Verarbeitung in der Anwendung, Wartezeit auf eine Verbindung oder weitere Dienste beitragen.

Schritt 2: Einen fairen Vergleich herstellen

Ein Vorher-/Nachher-Vergleich hilft nur, wenn die verglichene Arbeit ausreichend ähnlich ist. Prüfen Sie deshalb:

• Daten und Eingaben: dieselbe fachliche Aufgabe, vergleichbare Datenmenge und relevante Parameterwerte.
• Last: Aufrufe je Zeiteinheit, Arbeitsmix und gleichzeitig laufende Verarbeitung.
• Konfiguration: Quelle und Ziel, Version beziehungsweise Dienstmodell, Kompatibilitätsgrad und wichtige Einstellungen.
• Zeitfenster: gemeinsame Zeitbasis für Anwendung, SQL-Daten und Azure-Metriken; Änderungen und Ereignisse mit Zeitstempel.
• Betriebszustand: regulärer Betrieb, erster Lauf nach Neustart oder Pause, laufende Wartung und andere besondere Ereignisse.

Vergleichen Sie zusätzlich die Anzahl erfolgreicher Abschlüsse und die Fehler. Eine niedrige gemessene Auslastung kann auch entstehen, wenn viele Anfragen vorher scheitern oder auf der Anwendungsseite warten.

Wenn die alte Messbasis fehlt

Sichern Sie die noch verfügbaren Daten und schreiben Sie auf, was sich daraus beantworten lässt. Vorhandene Query-Store-Historie, Anwendungsprotokolle oder frühere Betriebsberichte können helfen. Ihre Aussagekraft hängt von Zeitraum, Erfassung und Vergleichbarkeit ab.

Fehlende Daten lassen sich nicht nachträglich erzeugen. Sie können aber einen heute langsamen Zeitraum mit einem heute unauffälligen vergleichen oder denselben Vorgang kontrolliert vor und nach einer Änderung prüfen. Die Feststellung lautet dann „unter diesen heutigen Bedingungen verbessert“. Eine vollständige Erklärung des ursprünglichen Migrationsunterschieds ist damit noch nicht bewiesen.

Schritt 3: Die Ressourcen im richtigen Rahmen betrachten

Eine Azure-SQL-Umgebung hat mehrere mögliche Leistungsgrenzen. CPU ist eine davon. Auch Datenzugriffe, Logdurchsatz, Arbeitsspeicher oder verfügbare Ausführungskapazität können die Verarbeitung begrenzen.

Wichtig ist die Bezugsgröße: Eine Prozentmetrik bezieht sich auf die Ressource und Grenze, die ihre Definition nennt. Die Auslastung einer Datenbank beschreibt nicht automatisch die Auslastung der physischen Azure-Hardware.

In Hyperscale bezieht sich die Metrik für Daten-IO nur auf den lokalen Cache des Compute-Replikats. Seitenzugriffe auf die Page Server erscheinen dort nicht; Microsoft weist sie in eigenen Spalten von DMVs, in den Laufzeitstatistiken des Query Store und im Ausführungsplan aus. Eine gedrosselte Log-Erzeugung zeigt sich an Wait Types der Gruppe RBIO_RG_*. Ein niedriger Daten-IO-Wert schließt in Hyperscale langsame Datenzugriffe deshalb nicht aus.

Achten Sie auf kurze Spitzen und die Aggregation der Metrik. Ein geglätteter Mittelwert über einen langen Zeitraum kann einen kurzen Engpass verdecken. Lesen Sie CPU, IO oder Waits deshalb im selben Problemfenster wie die langsamen Vorgänge.

Bei Schreiblast lohnt die Trennung zwischen Daten-IO und Transaktionslog. Ein Engpass im Logpfad kann Speicher- oder Importvorgänge bremsen, während die CPU noch Spielraum hat. Der passende nächste Schritt ergibt sich aus dem Zusammenhang von Plattformmetriken, SQL-Warteverhalten und betroffenen Vorgängen.

Quellen: Microsofts Baseline-Empfehlung für Azure-VMs, MI-Monitoring und Ressourcenverwaltung in Elastic Pools, zu Hyperscale die Performance-Diagnose für Hyperscale.

Schritt 4: Abfragen und gegenseitige Behinderung prüfen

Hat dieselbe Arbeit nach dem Umstieg mehr CPU, mehr logische Lesezugriffe oder längere Datenbanklaufzeiten? Oder kommt mehr Arbeit gleichzeitig an? Diese Fragen helfen, Ursachen und Folgen zu trennen.

Mit Query Store eine Veränderung nachvollziehen

Query Store kann zeigen, welche Abfragen und Pläne in einem Zeitraum erfasst wurden und wie sich ihre aggregierten Laufzeitwerte verändert haben. Prüfen Sie zuerst, ob die benötigte Historie vorhanden und die Erfassung für Ihre Frage geeignet ist.

Vergleichen Sie für fachlich zusammengehörige Ausführungen:

• Ausführungszahl und Arbeitsmix;
• CPU-Arbeit und logische Lesezugriffe je Ausführung;
• Datenbanklaufzeit und, soweit erfasst, Wait-Kategorien;
• verwendete Pläne und Zeitpunkt einer Veränderung.

Ein neuer Plan ist ein Anlass zur Untersuchung. Ob er die Verschlechterung erklärt, zeigt erst der Vergleich bei passenden Daten, Parametern und Lastbedingungen. Auch Statistiken und Konfigurationsänderungen gehören in diese Prüfung.

Query Store fasst Laufzeitdaten in Intervallen zusammen. Er ist kein vollständiges Protokoll jedes Benutzeraufrufs. Aus einem Intervallmittelwert lässt sich weder der genaue Ablauf eines einzelnen Anwendungsfehlers noch ein korrektes 95. Perzentil aller Benutzerantworten ableiten. Für solche Fragen brauchen Sie geeignete ergänzende Anwendungs- oder Einzelereignisdaten.

Wenn Sie Werte über mehrere Intervalle zusammenfassen, berücksichtigen Sie deren unterschiedliche Ausführungszahlen. Ein einfaches Mitteln der Intervallmittelwerte kann das Ergebnis verzerren. Beim Vergleich separater Systeme ordnen Sie Abfragen über Inhalt und Kontext zu; die numerischen Query- und Plan-IDs allein sind keine belastbare systemübergreifende Identität.

Quelle: Performance mit Query Store überwachen.

Blocking und Transaktionen untersuchen

Auch in Azure können sich Vorgänge durch Sperren behindern. Prüfen Sie im Problemfenster, wer wartet, welcher Vorgang die benötigte Ressource hält und wie lange die betreffende Transaktion offen bleibt.

Eine langsame Transaktion kann die Wartezeit vieler weiterer Vorgänge auslösen. Hohe Auslastung ist dafür keine Voraussetzung. Die Anwendung kann zum Beispiel innerhalb einer Transaktion weitere Arbeit erledigen oder auf die nächste Interaktion warten.

Waits helfen bei der Einordnung. Sie sind wegen paralleler und überlappender Arbeit keine durchgehend addierbaren Stücke der Benutzerantwortzeit. Eine große Wait-Summe ist daher nicht gleichbedeutend mit ebenso vielen Sekunden zusätzlicher Wartezeit für einen einzelnen Benutzer.

Für allgemeine Diagnosewege verweisen wir auf unseren SQL-Server-Performance-Ratgeber. Die Messquellen und Berechtigungen müssen jeweils zur Azure-Plattform passen.

Schritt 5: Netzwerkwege, Startzustand und Fehlererholung prüfen

Viele kleine Aufrufe können zusätzliche Zeit vervielfachen

Wenn die Anwendung am bisherigen Standort bleibt und die Datenbank umzieht, ändert sich der Kommunikationsweg. Für einen großen einzelnen Datenbankaufruf kann das weniger auffallen als für eine Folge vieler kleiner Aufrufe.

Illustratives Rechenbeispiel: Ein Vorgang führt 100 Datenbank-Round-trips seriell aus. Dauert jeder Round-trip durch den veränderten Weg zusätzlich 10 Millisekunden, ergeben sich daraus insgesamt rund eine Sekunde zusätzliche Zeit. Die Rechnung setzt diese seriellen Aufrufe und die angenommene zusätzliche Round-trip-Zeit voraus; sie ist keine Azure-Messung und keine Vorhersage für Ihre Anwendung.

Prüfen Sie die tatsächliche Zahl und Abfolge der Aufrufe. Mögliche Ansatzpunkte sind die Platzierung der Anwendung, das Bündeln von Zugriffen und die Vermeidung unnötiger Wiederholungen. Ob eine solche Änderung fachlich und technisch passt, muss am konkreten Ablauf geprüft werden.

Quelle: Microsofts Tuninghinweise zu häufig kommunizierenden Anwendungen.

Den ersten Vorgang nach einer Ruhephase gesondert ansehen

Verwendet die Umgebung Serverless, prüfen Sie das konfigurierte Skalierungs- und gegebenenfalls Pause-/Resume-Verhalten. Eine automatisch pausierte Datenbank benötigt beim Wiederanlaufen Zeit. Auch das Aufwärmen der Umgebung kann die ersten Vorgänge beeinflussen.

Trennen Sie deshalb die erste Verbindung nach einer Ruhephase vom regulären Betrieb. Prüfen Sie Statusereignisse, Verbindungsversuche und die Anforderungen der Anwendung. Automatische Pause ist nicht für jede Serverless-Konfiguration oder Kombination mit anderen Funktionen verfügbar; für Hyperscale Serverless ist sie zum Stand 27.10.2026 Preview.

In Hyperscale kommt der lokale Cache hinzu. Bei fest bereitgestellter Rechenleistung hält Microsoft den Cache der Hochverfügbarkeitsreplikate vorgewärmt, bei Serverless nicht. Nach einem Wiederanlauf oder Replikatwechsel können die ersten Lesezugriffe deshalb häufiger an die Page Server gehen.

Quelle: Serverless-FAQ von Microsoft.

Wiederholungen sichtbar machen

Eine Anwendung kann einen vorübergehenden Verbindungsfehler abfangen und erneut versuchen, den Vorgang auszuführen. Aus Benutzersicht erscheint dann möglicherweise nur eine längere Antwortzeit. Ohne passende Protokollierung bleiben die Wiederholungen unsichtbar.

Prüfen Sie, welche Fehler auftreten, ob Verbindungen neu aufgebaut werden und wie viele Versuche stattfinden. Wiederholungen brauchen geeignete Grenzen und eine Abstimmung auf den Fehler. Bei Schreibvorgängen muss zusätzlich geklärt sein, ob die vorherige Transaktion bereits wirksam wurde und wie sich eine doppelte Verarbeitung verhindern lässt.

Ein höherer Timeoutwert allein erklärt die Ursache nicht. Er verändert zunächst, wie lange eine Anwendung auf ein Ergebnis wartet.

Quelle: Vorübergehende Verbindungsfehler und Wiederholungslogik.

Schritt 6: Eine Änderung begründen und ihre Wirkung prüfen

Formulieren Sie vor der Änderung eine konkrete Erwartung. Zum Beispiel: „Diese Abfrage benötigt nach der Indexänderung weniger logische Lesezugriffe“ oder „Das Bündeln der Aufrufe verkürzt den betroffenen Anwendungsvorgang bei gleicher Last“.

Legen Sie anschließend fest, wie die Erwartung geprüft wird. Verwenden Sie dieselben fachlichen Vorgänge und ausreichend ähnliche Bedingungen. Vergleichen Sie Antwortzeit, erfolgreiche Abschlüsse, Fehler und den relevanten Ressourcenbedarf. Bei kritischen Abläufen auch die übrige Workload berücksichtigen: Eine Änderung soll nicht nur einen Einzeltest beschleunigen und gleichzeitig andere wichtige Vorgänge ausbremsen.

Eine größere Konfiguration kann als Sofortmaßnahme oder als begrenzter Vergleich helfen. Verbessert sie die Situation, ist damit zunächst ein Effekt unter den getesteten Bedingungen beobachtet. Welche Ressource und welcher Mechanismus die Verbesserung erklären, muss weiter eingegrenzt werden.

Bewerten Sie danach die wirtschaftliche Folge. Bei fest bereitgestellter Kapazität senkt eine effizientere Abfrage die Rechnung erst dann, wenn daraus etwa eine passend kleinere Konfiguration wird. Bei nutzungsabhängigen Modellen gelten deren konkrete Abrechnungsregeln. Eine gemessene technische Verbesserung und eine nachgewiesene Kostenänderung sind zwei getrennte Ergebnisse.

Ihr Befundblatt für den nächsten Prüfschritt

Mit diesen Angaben wird aus „seit Azure langsam“ eine bearbeitbare Untersuchung.

Für eine erste Anfrage reichen die verfügbaren Eckdaten. Produktive Zugangsdaten und vollständige SQL- oder Geschäftsdaten gehören nicht in das Kontaktformular; einen geeigneten Analysezugang stimmen wir gesondert ab.

Häufige Fragen

Quellen und Grenzen

Die Abbildungen auf dieser Seite sind Strukturmodelle und Lehrbeispiele. Sie enthalten keine Messwerte aus Azure-Umgebungen oder Kundensystemen; die Round-trip-Rechnung beruht allein auf den genannten Annahmen.

Produktgrenzen ändern sich mit der Zeit; diese Seite gibt den Stand vom 27.10.2026 wieder. Grundlage ist öffentliche Microsoft-Dokumentation; eigene Messungen in Azure-Umgebungen liegen dieser Seite nicht zugrunde. Prüfen Sie für eine konkrete Entscheidung die dann aktuellen Angaben.

Quellen von Microsoft (Dokumentationsstand geprüft am 27.10.2026): Baseline für SQL Server auf Azure-VMs · Managed Instance mit Azure Monitor überwachen · Ressourcenverwaltung in Elastic Pools · Performance mit Query Store überwachen · Tuninghinweise für Azure SQL Database · Serverless-FAQ · Vorübergehende Verbindungsfehler und Wiederholungslogik · Performance-Diagnose für Hyperscale

Weiterlesen