SQL-Datenbank braucht mehr Kapazität? Datenbank skalieren

Veröffentlicht am:
#azure-sql#scaling#performance#dtu

Mit mehr gleichzeitigen Abfragen können die zugewiesenen Datenbankressourcen zum Engpass werden. Hochskalieren gibt derselben Datenbank mehr Kapazität; Herunterskalieren senkt bei geringerem Bedarf die Kosten. Dieses Lab wechselt von Basic (5 DTUs) zu Standard S0 (10 DTUs). Eine Database Transaction Unit (DTU) misst eine gebündelte Zuweisung von CPU, Arbeitsspeicher und Datenein-/ausgabe (I/O). Mehr DTUs geben der Datenbank mehr Ressourcen für Abfragen; Standard mit 10 DTUs entspricht der Leistungsstufe S0.

Das DTU-basierte Kaufmodell bietet vorgegebene Ressourcenpakete: Es eignet sich für einfache Dimensionierung, wenn eine Leistungsstufe von Basic, Standard oder Premium zur Last passt. Dieses Lab nutzt DTUs für eine kleine, unkomplizierte Konfiguration.

Das vCore-basierte Kaufmodell lässt dich virtuelle CPU-Kerne wählen und Speicher separat dimensionieren; der Arbeitsspeicher hängt von Hardware und Kernzahl ab. Es eignet sich für genauere Kapazitätsplanung, die Übertragung bestehender Serveranforderungen oder unterstützte Serverless-Optionen. Vergleiche die Kosten für deine Last—keines der Modelle ist grundsätzlich günstiger.

Ausgangspunkt prüfen

Verwende sqldb-cloudtrips aus Azure SQL Database erstellen. Falls gelöscht, erstelle zuerst erneut die kleine Basic-Datenbank.

Öffne SQL databases → sqldb-cloudtrips → Compute + storage und prüfe Basic, 5 DTUs. Bei realer Last betrachte unter Monitoring → Metrics die Werte DTU percentage, CPU percentage und Data IO percentage. Dauerhaft hohe Werte helfen, Ressourcenengpässe zu erkennen; eine ruhige Labdatenbank zeigt wenig Aktivität.

Kapazität erhöhen

Wähle unter Compute + storage die DTU-basierte Ebene Standard und S0 (10 DTUs). Behalte die Daten unverändert, prüfe die angezeigten Kosten und wähle Apply.

Compute-and-storage-Konfiguration mit Standard S0, 10 DTUs und geschätzten Kosten

Prüfe das Ziel S0 / 10 DTUs. Die Zuweisung verdoppelt sich; die tatsächliche Abfragegeschwindigkeit hängt von Last, Indizes und Engpässen ab.

Warte unter Notifications oder Overview auf den Abschluss. Der Wechsel kann Verbindungen kurz unterbrechen; Anwendungen sollten sich neu verbinden und vorübergehend fehlgeschlagene Vorgänge wiederholen. Serveradresse und Datenbankname bleiben gleich.

Neue Dienstebene prüfen

Verbinde dich erneut über Query editor (preview) oder dein SQL-Profil in VS Code und führe aus:

SELECT DB_NAME() AS DatabaseName,
       DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS Edition,
       DATABASEPROPERTYEX(DB_NAME(), 'ServiceObjective') AS ServiceObjective;

Abfrageergebnis mit sqldb-cloudtrips, Edition Standard und ServiceObjective S0

Erwarte sqldb-cloudtrips, Standard und S0. Diese Werte bestätigen die Kapazitätskonfiguration; ein Leistungsvergleich benötigt vergleichbare Abfragen unter Last vor und nach der Skalierung.

Zurückskalieren oder bereinigen

Wähle unter Compute + storage wieder Basic (5 DTUs), setze die maximale Datengröße auf 2 GB und bestätige. Die zugewiesene Datenmenge muss in das Basic-Limit passen. Das kleine Lab sollte passen; bei größeren Datenbanken muss der Speicher vor dem Wechsel geprüft werden.

Führe nach Abschluss die Abfrage erneut aus: Edition und ServiceObjective sollten Basic anzeigen. Behalte die Datenbank für den nächsten Trip oder lösche rg-cloudtrips-sql-test-weu, um laufende Kosten zu beenden.