VERTRIEB: 1-800-867-1380

Basic-, Standard- und Premium-Vorschau für die Azure SQL-Datenbank

Letzte Aktualisierung: Mai 2014

Autoren: Conor Cunningham, Kun Cheng, Jan Engelsberg

Technische Bearbeiter: Morgan Oslake, Joanne Marone, Keith Elmore, José Batista-Neto, Rohit Nayak

Zusätzlich zur Premium-Dienstebene wurden in Azure SQL-Datenbank die beiden neuen Dienstebenen Basic und Standard eingeführt. Da der Ressourcenverbrauch für die Azure SQL-Datenbank und deren sekundäre Replikate auf der Premium-Dienstebene streng kontrolliert werden, kann die Leistung für Cloud-Anwendungen zuverlässiger vorhergesagt werden. Azure SQL-Datenbank weitet dieses Konzept auf die neue Standard-Dienstebene aus. So profitieren auch Datenbanken, die weniger Leistung beanspruchen als auf der Premium-Dienstebene verfügbar von der hohen Vorhersagbarkeit der Leistung. Die Dienstebene Basic ist für die Leistungsanforderungen kostengünstigerer Datenbanken konzipiert.

Das Whitepaper unterstützt Sie bei der Entscheidung, welche der zur Zeit als Vorschau verfügbaren Dienstebenen für Ihre Anwendung geeignet ist. Weiter enthält es Empfehlungen, wie Sie die Anwendung optimieren, um die Leistungsfähigkeit der Azure SQL-Datenbank voll auszuschöpfen. Der Artikel enthält die folgenden Abschnitte:

Hintergrundinformationen zur Azure SQL-Datenbank

Worin unterscheiden sich die neuen Dienstebenen?

Gründe für die Verwendung der neuen Dienstebenen

Grundlegendes zur Ressourcenverwendung

Optimieren der Anwendung

Zusammenfassung

Um eine Vorstellung davon zu erhalten, wie der vorhandene Azure SQL-Datenbankdienst durch die Basic-, Standard- und Premium-Dienstebene erweitert werden kann, sind fundierte allgemeine Kenntnisse der Azure SQL-Datenbank von Vorteil. Kunden wählen heutzutage die Azure SQL-Datenbank aus verschiedenen Gründen. Ein Grund besteht darin, den langwierigen Prozess des Erwerbs und der Installation von Hardware zu vermeiden. Mit Azure SQL-Datenbank können Sie Datenbanken ad-hoc erstellen und außer Betrieb nehmen, ohne darauf zu warten, dass Bestellungen genehmigt, Computer geliefert, Stromversorgungs- und Kühlkomponenten aufgerüstet oder die Installation fertiggestellt wird. Microsoft löst diese Herausforderungen und verkürzt die Implementierungszeit immens, indem in jedem unserer Rechenzentren Hardware basierend auf der Gesamtnachfrage im Voraus bereitgestellt wird. Dies erspart Geschäftskunden Wochen oder Monate, die benötigt werden, wenn Kauf und Bereitstellung der Hardware manuell erfolgen.

Microsoft bietet mit Azure SQL-Datenbank außerdem viele automatische Verwaltungsfunktionen, z. B. automatische hohe Verfügbarkeit, Lastenausgleich und integrierte Verwaltung.

  • Automatische Hochverfügbarkeit (High Availability, HA)

    Azure SQL-Datenbank speichert für jede Benutzerdatenbank mindestens drei Replikate und verfügt über eine Logik, die jede Änderung automatisch und synchron per Commit an ein aus Replikaten gebildetes Quorum übergibt. Dies verhindert, dass der Ausfall eines einzelnen Computers den Verlust von Daten verursacht. Darüber hinaus wird jedes Replikat auf einem jeweils anderen Hardwarerack platziert, damit der Ausfall der Stromversorgung oder von Netzwerkswitches ohne Auswirkung auf die Datenbank bleibt. Und schließlich verfügt die SQL-Datenbank über Logik für die Neuerstellung von Replikaten, wenn ein Computer ausfällt, sodass die gewünschten Zustandseigenschaften auch dann erhalten bleiben, wenn ein Computer fehlerhaft ist. Durch diese Mechanismen wird der zeitaufwendige Prozess vermieden, der heutzutage zum Installieren und Konfigurieren von Hochverfügbarkeitslösungen erforderlich ist. Wenn Sie über eine vorkonfigurierte Hochverfügbarkeitslösung für Ihre Daten verfügen, entfallen die Sorgen und Probleme, die das Erstellen einer unternehmenswichtigen Datenbanklösung mit herkömmlichen Verfahren bereiten kann.

  • Lastenausgleich

    Azure SQL-Datenbank bietet im Gegensatz zu herkömmlichen virtuellen Computern einen Mechanismus für den automatischen Lastenausgleich zwischen mehreren Computern. Der Lastenausgleich überwacht dynamisch die Ressourcennutzung für einen Cluster und verschiebt Datenbankreplikate auf Computer im Cluster, um die Last dynamisch und gerecht auf viele Benutzer zu verteilen. Dies erhöht die bedarfsgesteuerte Datenbankkapazität und ermöglicht es einem Benutzer, die Kapazitätsanforderungen für jede Datenbank unabhängig zu ermitteln, da der Lastenausgleich ausgelastete Datenbanken isoliert migrieren kann. Beim Erstellen von Lösungen, die sich über viele Datenbanken erstrecken, bietet diese Logik eine Abstraktionsebene, die es einem Kunden ermöglicht, sich statt auf die Größenbeschränkungen eines virtuellen Computers auf die Kapazitätsanforderungen jeder Datenbank zu konzentrieren.

  • Integrierte Verwaltung

    Azure SQL-Datenbank wird als Dienst ausgeführt. Dies bedeutet, dass für jede Datenbank Betriebszeiten definiert sind und somit Downtimefenster langer Dauer für die Wartung vermieden werden. Microsoft bietet einen einzigen Anbieter für den gesamten Dienst, d. h., Sie müssen sich nur an eine einzige Firma wenden, falls Probleme auftreten. Der Dienst wird außerdem kontinuierlich durch neue Funktionen und zusätzliche Kapazitäten ausgebaut, und Microsoft ist bestrebt, die Benutzererfahrung mit jedem neuen Update zu verbessern. Updates erfolgen transparent und ohne Stillstandzeiten. Dies bedeutet, dass sie in den normalen Failovermechanismus für hohe Verfügbarkeit integriert sind. Dadurch können Kunden neue Funktionen immer sofort nutzen, wenn ihre Verfügbarkeit mitgeteilt wird, statt darauf zu warten, dass in einem zukünftigen Downtimefenster das Upgrade eines Servers erfolgt.

Sämtliche Funktionen sind in allen Dienstebenen bereits zu einem niedrigen Einstiegspreis pro Monat erhältlich. Dieser Preis ist weitaus niedriger als die Kosten für den Kauf und Betrieb eines eigenen Servers. Daher kann Azure selbst für äußerst kleine Projekte kostengünstig genutzt werden.

Microsoft hat eine Reihe von Kunden intensiv bei der Einführung von Azure SQL-Datenbank begleitet, um zu erfahren, wie der Dienst genutzt wird, und die Ergebnisse für die Planung zukünftiger Funktionen an das Entwicklungsteam weitergeleitet. Dabei stellten wir fest, dass manche Arten von Kunden die Funktionen als für ihre Anforderungen gut geeignet fanden. Beispielsweise empfanden Startupunternehmen, die neue Cloud-Dienste entwickeln, häufig die Kombination von bedarfsgesteuerter Kapazität und reduziertem Verwaltungsaufwand als Vereinfachung, die es Ihnen ermöglichte, sich auf ihre Kernaufgaben zu konzentrieren. Die Herausforderungen anderer Kunden wiederum lagen in Bereichen mit hohen Leistungsanforderungen, z. B. die Verwaltung einer zentralen API in einer umfassenden Multi-Tier-Datenbanklösung, die vom Azure SQL-Datenbankdienst zur gegebenen Zeit nicht bewältigt wurden. Das Feedback ergab, dass einige Kunden bereit waren, höhere Leistungsschwankungen zugunsten niedrigerer Preise in Kauf zu nehmen, während andere eher an bestimmten Leistungszusicherungen interessiert waren, um mit den Datenbanken einen Mehrwert zu erzielen.

Zur Berücksichtigung sämtlicher Kundenanforderungen hat Microsoft die Dienstebenen Basic, Standard und Premium eingeführt, die derzeit in der öffentlichen Vorschau verfügbar sind. Jede Dienstebene bietet eine oder mehrere Leistungsstufen, die die nötigen Kapazitäten zur Ausführung der Datenbanken in einer vorhersagbaren Weise bereitstellen. Die Leistung wird in DTUs (Database Throughput Units, Einheiten für den Datenbankdurchsatz) ausgedrückt. In der folgenden Tabelle sind die Dienstebenen, Leistungsstufen und DTUs aufgeführt:

 

Dienstebene

Leistungsstufe

DTU

Basic

5

Standard

S1

15

Standard

S2

50

Premium

P1

100

Premium

P2

200

Premium

P3

800

Die Dienstebene Basic bietet eine gute Vorhersagbarkeit der Datenbankleistung auf Stundenbasis. Die DTU einer Basic-Datenbank stellt ausreichende Ressourcen für kleinere Datenbanken bereit und eignet sich sehr gut für Datenbanken, die nicht mehrere Anforderungen gleichzeitig verarbeiten müssen.

Um die Vorhersagbarkeit der Leistung zu verbessern und Datenbanken, die mehrere gleichzeitige Anforderungen z. B. von Arbeitsgruppen- und Webanwendungen verarbeiten müssen, mehr Kapazität zur Verfügung zu stellen, hat Microsoft die Dienstebene Standard eingeführt. Bei einer Datenbank mit der Dienstebene Standard können Kunden die Größe der Datenbankanwendung auf Grundlage der vorhersagbaren Leistung in 1-Minuten-Intervallen anpassen. Die Dienstebene Standard bietet die beiden Leistungsstufen S1 und S2, mit denen Sie die Kapazität nach Bedarf erhöhen oder verringern können.

Im Hinblick auf die Leistung der Premium-Dienstebene entspricht die Marqueefunktion der vorhersagbaren Leistung der einzelnen Premium-Datenbanken auf Sekundenbasis. Bei Verwendung der Premium-Dienstebene können Kunden die Größe der Datenbankanwendung an die Spitzenlast der jeweiligen Datenbank anpassen. Außerdem vermeiden sie Situationen, in denen kleinere Abfragen bei latenzkritischen Vorgängen aufgrund von Leistungsschwankungen länger als erwartet dauern. Mit diesem Modell lassen sich die Entwicklungs- und Produktüberprüfungszyklen für Anwendungen, für die strenge Kriterien im Hinblick auf Spitzenressourcenanforderungen, Leistungsschwankungen oder Abfragelatenz gelten, erheblich vereinfachen. Es bietet außerdem die Möglichkeit, einige lokale Anwendungen ohne wesentliche Änderungen zu migrieren. Dieses Verhalten ähnelt mehr der herkömmlichen, isolierten Vorgehensweise, die bei der ursprünglichen Erstellung dieser Anwendungen angewendet wurde.

Wie bei der Standard-Dienstebene können auch bei der Premium-Dienstebene je nach der vom Kunden gewünschten Isolation unterschiedliche Leistungsstufen ausgewählt werden.

Da die Leistungsstufen in der Standard- und Premium-Dienstebene individuell festgelegt werden können, zahlt der Kunde nur für die benötigte Kapazität. Diese kann bei einer Änderung der Arbeitsauslastung beliebig erhöht oder verringert werden. Wenn die Datenbank z. B. während des Vorweihnachtsgeschäfts extrem ausgelastet ist, können Sie die für die Datenbank ausgewählte Leistungsstufe in diesem Zeitraum erhöhen und nach Ende der Spitzenauslastung wieder verringern. So können die Kunden die Kosten minimieren, indem sie ihre Cloud-Umgebung entsprechend der Saisonabhängigkeit ihres Unternehmens optimieren. Dieses Modell eignet sich auch gut für die Veröffentlichungszyklen von Softwareprodukten. Beispielsweise kann ein Testteam während eines Testdurchlaufs mehr Kapazitäten zuweisen und diese nach dem Test wieder freigeben. Diese Kapazitätsanforderungen entsprechen dem Modell, dass Sie für die Kapazität zahlen, wenn Sie sie benötigen, und Kosten für dedizierte Ressourcen vermeiden, die selten verwendet werden. Dies bietet Ihnen eine Benutzererfahrung im Hinblick auf Leistung, die in größerem Umfang dem herkömmlichen Modell dedizierter Hardware entspricht, das viele Microsoft-Kunden für SQL Server verwendet haben. So kann eine größere Anzahl von Anwendungen leichter unter Azure SQL-Datenbank ausgeführt werden.

Arbeitsauslastungen können variieren. Die neuen Dienstebenen sollen eine hohe Vorhersagbarkeit der Leistung auf unterschiedlichen Leistungsstufen gewährleisten. So können Kunden, deren Datenbanken einen hohen Ressourcenbedarf haben, eine speziell auf ihre Bedürfnisse zugeschnittene Rechenumgebung nutzen.

Die Basic-Dienstebene eignet sich im Allgemeinen für folgende Szenarien:

  • Einstieg in Azure SQL-Datenbank – Entwicklungsanwendungen benötigen häufig keine hohen Leistungsstufen. Basic-Datenbanken bieten eine ideale Umgebung für die kostengünstige Datenbankentwicklung.

  • Datenbank im Einzelbenutzermodus – Anwendungen, die einen einzelnen Benutzer mit einer Datenbank verbinden, stellen normalerweise keine hohen Parallelitäts- und Leistungsansprüche. Für diese Art von Anwendungen empfiehlt sich die Basic-Dienstebene.

Die Standard-Dienstebene eignet sich im Allgemeinen für folgende Szenarien:

Datenbank mit mehreren gleichzeitigen Anforderungen – Anwendungen, die mehrere Benutzer gleichzeitig unterstützen, z. B. Websites mit mäßigem Datenverkehr oder Abteilungsanwendungen, die einen höheren Ressourcenbedarf haben, eignen sich gut für die Standard-Dienstebene.

Die Premium-Dienstebene eignet sich im Allgemeinen für folgende Szenarien:

  • Hohe Spitzenlast – Eine Anwendung, die zum Ausführen ihrer Vorgänge einen hohen Bedarf an CPU-, Arbeitsspeicher- oder E/A-Ressourcen hat. Wenn beispielsweise ein Datenbankvorgang bekanntermaßen über einen längeren Zeitraum mehrere CPU-Kerne nutzt, empfiehlt sich möglicherweise für diesen Datenbankvorgang die Verwendung von Premium-Datenbanken.

  • Zahlreiche gleichzeitige Anforderungen – Einige Datenbankanwendungen müssen mehrere Anforderungen gleichzeitig verarbeiten, z. B. bei einer Website mit starkem Datenverkehr. Bei der Basic- und Standard-Dienstebene ist die Anzahl gleichzeitiger Anforderungen beschränkt. Anwendungen, die mehr Verbindungen erfordern, müssen eine entsprechende Reservierungsgröße auswählen, um die maximale Anzahl erforderlicher Anforderungen zu behandeln.

  • Geringe Latenz – Einige Anwendungen müssen gewährleisten, dass die Datenbank in kürzester Zeit antwortet. Wenn eine bestimmte gespeicherte Prozedur im Rahmen eines umfassenderen Vorgangs bei einem Kunden aufgerufen wird, ist es möglicherweise erforderlich, dass dieser Aufruf in 99 % der Zeit innerhalb von 20 Millisekunden einen Rückgabewert liefert. Premium-Datenbanken stellen für diese Art von Anwendung sicher, dass Rechenleistung verfügbar ist.

Weitere Informationen zu häufigen Szenarien, die bei Verwendung der Azure SQL-Datenbank Leistungsprobleme verursachen können, finden Sie unter Azure SQL-Datenbank und SQL-Server – Vergleich und Gegenüberstellung der Leistung und Skalierbarkeit.

Welche Stufe genau benötigt wird, hängt davon ab, welche Spitzenlasten von den einzelnen Ressourcendimensionen gefordert werden. Einige Anwendungen nutzen möglicherweise geringfügige Mengen einer Ressource und benötigen beträchtliche Mengen einer anderen Ressource.

Die neuen Dienstebenen sind wie folgt strukturiert:

 

Dienstebene/Leistungsstufe DTU Max. Datenbankgröße Max. Arbeits- threads Max. Sitzungen Vorhersagbarkeit

Basic

5

2 GB

20

100

Gut

Standard/S1

15

250 GB

50

200

Besser

Standard/S2

50

250 GB

100

500

Besser

Premium/P1

100

500 GB

200

2,000

Optimal

Premium/P2

200

500 GB

400

4,000

Optimal

Premium/P3

800

500 GB

1,600

16,000

Optimal

Das folgende Diagramm zeigt die CPU-Ressourcennutzung einer Premium-Datenbank mit der Leistungsstufe P2 aufgeschlüsselt nach den Stunden einer Woche. In diesem Diagramm werden 5 Arbeitstage ab Montag und ein Wochenende, in dem in der Anwendung weitaus weniger Vorgänge ausgeführt werden, dargestellt.

Es ist erkennbar, dass die Datenbank derzeit eine CPU-Spitzenlast aufweist, die relativ zur Leistungsstufe P2 knapp über 50 % der CPU-Nutzung liegt (Dienstagmittag). Wenn die CPU der bestimmende Faktor im Ressourcenprofil der Anwendung ist, kann der Kunde davon ausgehen, dass P2 die richtige Leistungsstufe ist, bei der immer genügend Kapazität für die Arbeitsauslastung bereitsteht. Wenn erwartet wird, dass die Auslastung einer Anwendung mit der Zeit zunimmt, sollte ein zusätzlicher Ressourcenpuffer vorgesehen werden, damit das Kapazitätslimit von der Anwendung nicht überschritten wird. Auf diese Weise werden vom Kunden wahrnehmbare Fehler vermieden, die z. B. auftreten, wenn Datenbankanforderungen aufgrund unzureichender Ressourcen nicht effizient verarbeitet werden können. Dies gilt insbesondere für latenzkritische Umgebungen (z. B. eine Datenbank für eine Anwendung, die Webseiten auf Grundlage der Ergebnisse von Datenbankaufrufen generiert).

Es ist zu beachten, dass das gleiche Diagramm für andere Anwendungstypen möglicherweise eine andere Bedeutung hat. Würde dieses Diagramm z. B. für eine Anwendung generiert, von der täglich Gehaltsdaten verarbeitet werden, wäre die Leistungsstufe P1 für diese Art von Batchauftragsmodell wahrscheinlich völlig ausreichend. Die Leistungsstufe P1 umfasst 100 DTUs, während die Leistungsstufe P2 200 DTUs umfasst. Dies bedeutet, dass Leistungsstufe P1 50 % der Leistung von Leistungsstufe P2 bereitstellt. Also entsprechen 50 % der CPU-Nutzung in P2 100 % der CPU-Nutzung in P1. Wenn keine Timeouts in der Anwendung auftreten, ist es unerheblich, ob 2 Stunden oder 2,5 Stunden bis zum Abschluss eines großen Auftrags benötigt werden, solange der Auftrag bis zum Ende des Tages abgeschlossen wird. Eine Anwendung in dieser Kategorie kann u. U. lediglich Leistungsstufe P1 nutzen. Dieser Kunde kann den Umstand nutzen, dass zu bestimmten Zeiten während des Tags die Ressourcenverwendung geringer ist, sodass Spitzenlasten möglicherweise in die anschließenden Senken überschwappen. Solange die Aufträge jeden Tag pünktlich verarbeitet werden, ist die Leistungsstufe P1 für eine solche Anwendung sehr gut geeignet (und kostensparend).

Azure SQL-Datenbank stellt für jede aktive Datenbank Informationen zum Ressourcenverbrauch in der Sicht sys.resource_stats bereit, die in der Masterdatenbank der einzelnen Server enthalten ist. Die Daten in der Tabelle werden für Intervalle von 5 Minuten aggregiert. In der Vorschau der Basic-, Standard- und Premium-Dienstebene kann es über 5 Minuten dauern, bis die Daten in der Tabelle angezeigt werden. Daher eignen sich diese Daten besser für nachträgliche als für zeitnahe Analysen. Um zu überprüfen, ob die benötigte Kapazität bei der ausgewählten Reservierung zum richtigen Zeitpunkt bereitgestellt wurde, können Sie die Sicht sys.resource_stats abfragen, um den neuesten Datenbankverlauf zu erhalten. Das folgende Beispiel zeigt, wie die Daten in dieser Sicht verfügbar gemacht werden:

SELECT TOP 10 * 
FROM sys.resource_stats 
WHERE database_name = 'resource1' 
ORDER BY start_time DESC

Hinweis: Einige Spalten der Tabelle wurden aus Platzgründen abgeschnitten. Eine vollständige Beschreibung der Ausgabe finden Sie im Thema sys.resource_stats.

In diesem Abschnitt wird beschrieben, wie Sie die Ressourcenverwendung der Azure SQL-Datenbank überwachen und den aktuellen Ressourcenverbrauch mit unterschiedlichen Leistungsstufen vergleichen.

  1. In der aktuellen Vorschau wurde die Katalogsicht sys.resource_stats durch zusätzliche Informationen zur früheren Ressourcenverwendung auf Datenbankebene erweitert. Beispielsweise können Sie die folgende Abfrage ausführen, um die Ressourcenverwendung der letzten Woche für die Datenbank userdb1 zu überprüfen:

    SELECT * 
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND 
          start_time > DATEADD(day, -7, GETDATE())
    ORDER BY start_time DESC;
    
    
  2. Um festzustellen, wie gut die Leistungsstufe für die Arbeitsauslastung geeignet ist, müssen Sie einen Drilldown auf die einzelnen Komponenten der Ressourcenmetriken ausführen: CPU, Lesevorgänge, Schreibvorgänge, Anzahl von Arbeitsthreads und Anzahl von Sitzungen. Im Folgenden sehen Sie eine überarbeitete Abfrage, in der anhand von sys.resource_stats sowohl die Durchschnitts- als auch die Höchstwerte der Ressourcenmetriken angegeben werden.

    SELECT 
        avg(avg_cpu_percent) AS 'Average CPU Utilization In Percent',
        max(avg_cpu_percent) AS 'Maximum CPU Utilization In Percent',
        avg(avg_physical_data_read_percent) AS 'Average Physical Data Read Utilization In Percent',
        max(avg_physical_data_read_percent) AS 'Maximum Physical Data Read Utilization In Percent',
        avg(avg_log_write_percent) AS 'Average Log Write Utilization In Percent',
        max(avg_log_write_percent) AS 'Maximum Log Write Utilization In Percent',
        avg(active_session_count) AS 'Average # of Sessions',
        max(active_session_count) AS 'Maximum # of Sessions',
        avg(active_worker_count) AS 'Average # of Workers',
        max(active_worker_count) AS 'Maximum # of Workers'
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
  3. Mithilfe der oben aufgeführten Durchschnitts- und Höchstwerte der einzelnen Ressourcenmetriken können Sie beurteilen, wie gut die ausgewählte Leistungsstufe für Ihre Arbeitsauslastung geeignet ist. In den meisten Fällen liefern die Durchschnittswerte aus sys.resource_stats einen guten Anhaltspunkt zum Ermitteln der Zielgröße. Sie sollten sie als wichtigste Messgrößen verwenden. Wenn Sie beispielsweise die Standard-Dienstebene mit Leistungsstufe S2 verwenden und die durchschnittlichen prozentualen Nutzungswerte für CPU, Lesevorgänge und Schreibvorgänge unter 20 %, die durchschnittliche Anzahl von Arbeitsthreads unter 50 und die durchschnittliche Sitzungsanzahl unter 200 liegen, ist Leistungsstufe S1 für die Arbeitsauslastung wahrscheinlich ausreichend. Ob die maximale Anzahl von Arbeitsthreads und Sitzungen die Voraussetzungen für die Datenbank erfüllt, lässt sich leicht feststellen. Um zu ermitteln, ob eine Datenbank mit den CPU-, Lese- und Schreibkapazitäten einer niedrigeren Leistungsstufe auskommen würde, dividieren Sie die DTU-Anzahl der niedrigeren Leistungsstufe durch die DTU-Anzahl Ihrer aktuellen Leistungsstufe und multiplizieren das Ergebnis mit 100:



    S1 DTU / S2 DTU * 100 = 5 / 25 * 100 = 20



    Daraus ergibt sich die relative prozentuale Differenz zwischen den beiden Leistungsstufen. Wenn Ihre Nutzungswerte unter diesem Prozentsatz liegen, kommt für die Arbeitsauslastung möglicherweise auch die niedrigere Leistungsstufe in Frage. Sie müssen jedoch alle Bereiche der Ressourcenverwendung überprüfen und prozentual bestimmen, in wie vielen Fällen die niedrigere Leistungsstufe für die Datenbankarbeitsauslastung geeignet ist. Die folgende Abfrage gibt die prozentuale Eignung pro Ressourcendimension auf Grundlage des oben berechneten Schwellenwerts von 20 % aus:

    SELECT 
        (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
    Anhand des Servicelevelziels (Service Level Objective, SLO) für die Datenbank können Sie entscheiden, ob die niedrigere Leistungsstufe für Ihre Arbeitsauslastung geeignet ist. Wenn das SLO der Datenbankarbeitsauslastung 99,9 % beträgt und die vorangehende Abfrage für alle drei Ressourcendimensionen Werte über 99,9 zurückgibt, reicht die niedrigere Leistungsstufe sehr wahrscheinlich für die Arbeitsauslastung aus.

    Die prozentuale Eignung gibt auch Aufschluss darüber, ob Sie zur nächsthöheren Leistungsstufe wechseln müssen, um Ihr SLO einzuhalten. "userdb1" weist für die vorausgehende Woche z. B. folgende Nutzungswerte auf:

     

    Durchschnittlicher CPU-Prozentsatz

    Maximaler CPU-Prozentsatz

    24.5

    100.00

    Der durchschnittliche CPU-Wert beträgt ungefähr ein Viertel des maximalen Limits der Leistungsstufe und liegt perfekt innerhalb der Datenbank-Leistungsstufe. Der maximale Wert lässt allerdings erkennen, dass die Datenbank das Limit der Leistungsstufe erreicht. Ist ein Wechsel zur nächsthöheren Leistungsstufe erforderlich? Auch hier müssen Sie bestimmen, wie häufig die Arbeitsauslastung 100 % erreicht und den Wert mit dem SLO für die Datenbankarbeitsauslastung vergleichen:

    SELECT 
    (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
    ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent’
    ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    Wenn die vorangehende Abfrage für eine der drei Ressourcendimensionen einen Wert unter 99,9 zurückgibt, sollten Sie entweder zur nächsthöheren Leistungsstufe wechseln oder die Auslastung der Azure SQL-Datenbank verringern, indem Sie Anwendungen optimieren.

  4. Im vorangehenden Beispiel sollte außerdem die zukünftig erwartete Zunahme der Arbeitsauslastung berücksichtigt werden.

Bei der herkömmlichen lokalen Verwendung von SQL Server erfolgt die anfängliche Kapazitätsplanung häufig getrennt von der Ausführung einer produktiven Anwendung. Das heißt, dass der Kauf der Hardware und der entsprechenden Lizenzen für die Ausführung von SQL Server vorab erfolgt, während die Leistungsoptimierung später durchgeführt wird. Bei Verwendung von Azure SQL-Datenbank ist es im Allgemeinen empfehlenswert (und aufgrund des monatlichen Abrechnungszyklus wahrscheinlich auch erwünscht), die Ausführung und Optimierung einer Anwendung zu verbinden. Das Zahlungsmodell, gemäß dem der Kunde für bedarfsgesteuerte Kapazität zahlt, ermöglicht das Optimieren der Anwendung für die Verwendung der derzeit benötigten minimalen Ressourcen, statt auf Grundlage von Wachstumsschätzungen für eine Anwendung (die häufig äußerst fehlerhaft sind, da sie weit in die Zukunft reichen müssen) weitaus mehr Hardware als erforderlich bereitzustellen. Einige Kunden bevorzugen es, die Anwendung nicht zu optimieren und stattdessen eine zu große Menge an Hardwareressourcen bereitzustellen. Dieser Ansatz kann sinnvoll sein, wenn ein Kunde eine wichtige Anwendung nicht während eines Zeitraums hoher Auslastung der Anwendung ändern möchte. Mit einer optimierten Anwendung lassen sich Ressourcenanforderungen und monatliche Kosten bei Verwendung der neuen Dienstebenen in Azure SQL-Datenbank reduzieren.

Während die neuen Dienstebenen die Stabilität und Voraussagbarkeit der Anwendungsleistung verbessern sollen, gibt es einige bewährte Methoden, mit denen eine Anwendung optimiert werden kann, um die Funktion besser zu nutzen. Viele Anwendungen erzielen bereits durch den Wechsel zu einer höheren Leistungsstufe und/oder Dienstebene deutliche Leistungssteigerungen. Andere Anwendungen profitieren aber erst von einem Wechsel, nachdem sie optimiert wurden. Anwendungen mit folgenden Eigenschaften sollten zusätzlich optimiert werden, um die Leistung bei Verwendung der Azure SQL-Datenbank weiter zu verbessern.

  • Anwendungen, deren Leistung aufgrund von "geschwätzigem" Verhalten gering ist

    Hierzu zählen Anwendungen mit einer übermäßigen Anzahl von Datenzugriffsvorgängen, bei denen Netzwerklatenz eine kritische Größe ist. Diese Anwendungen müssen u. U. überarbeitet werden, um die Anzahl der Datenzugriffe auf die Azure SQL-Datenbank zu verringern. Beispielsweise kann die Anwendung eventuell durch die Batchverarbeitung von Ad-hoc-Abfragen oder das Verschieben der Abfragen in gespeicherte Prozeduren optimiert werden. Weitere Informationen finden Sie weiter unten im Abschnitt "Batchverarbeitung von Abfragen".

  • Datenbanken mit einer hohen Arbeitsauslastung, die nicht von einem einzelnen gesamten Computer bewältigt werden kann

    Datenbanken, deren Ressourcenanforderungen die höchste Premium-Leistungsstufe überschreiten, sind weniger geeignet. Diese Datenbanken profitieren möglicherweise von einer horizontalen Skalierung der Arbeitsauslastung. Weitere Informationen finden Sie weiter unten in den Abschnitten "Datenbankübergreifendes Sharding" und "Partitionierung von Funktionen".

  • Anwendungen, die suboptimale Abfragen enthalten

    Insbesondere Anwendungen auf der Datenzugriffsebene, die schlecht optimierte Abfragen aufweisen, profitieren von einer höheren Leistungsstufe möglicherweise nicht wie erwartet. Zu diesen suboptimalen Abfragen zählen Abfragen, in denen eine WHERE-Klausel fehlt, in denen Indizes fehlen oder deren Statistiken veraltet sind. Diese Anwendungen profitieren von standardmäßigen Verfahren zur Abfrageoptimierung. Weitere Informationen finden Sie weiter unten in den Abschnitten "Fehlende Indizes" und "Abfrageoptimierung/Abfragehinweise".

  • Anwendungen mit einer nicht optimalen Gestaltung des Datenzugriffs

    Anwendungen mit Parallelitätsproblemen beim Datenzugriff, die z. B. Deadlocks verursachen, können die Vorteile einer höheren Leistungsstufe nicht ausnutzen. Anwendungsentwickler sollten Roundtrips zur Azure SQL-Datenbank reduzieren, indem Daten mithilfe des Azure-Cachediensts oder anderer Cacheverfahren auf der Clientseite zwischengespeichert werden. Weitere Informationen finden Sie weiter unten im Abschnitt "Caching auf Anwendungsebene".

In diesem Abschnitt werden verschiedene Verfahren erläutert, mit denen Sie die Azure SQL-Datenbank optimieren können, um mit der geringstmöglichen Leistungsstufe eine optimale Anwendungsleistung zu erzielen. Einige Verfahren entsprechen herkömmlichen bewährten Optimierungsmethoden für SQL Server, während andere spezifisch für Azure SQL-Datenbank sind. In manchen Fällen können herkömmliche SQL Server-Verfahren auf Azure SQL-Datenbank ausgeweitet werden. Dabei wird der Ressourcenverbrauch einer Datenbank auf weitere Verbesserungsmöglichkeiten untersucht.

Ein häufiges Problem bei der OLTP-Datenbankleistung betrifft den physischen Datenbankentwurf. Datenbankschemas werden häufig entworfen und geliefert, ohne Skalierungstests (im Hinblick auf Last oder Datenmenge) auszuführen. Leider kann die Leistung eines Abfrageplans bei geringen Mengen akzeptabel sein, jedoch bei Datenmengen auf Produktionsniveau erheblich abfallen. Die häufigste Ursache dieses Problems ist das Fehlen geeigneter Indizes zum Erfüllen der Bedingungen von Filtern oder anderer Beschränkungen in einer Abfrage. Eine häufige Folge hiervon ist, dass ein Tabellenscan erfolgt, obwohl lediglich eine Indexsuche erforderlich ist.

Im folgenden Beispiel wird ein Fall erzeugt, in dem der ausgewählte Abfrageplan einen Scan enthält, obwohl eine Suche ausreicht:

DROP TABLE dbo.missingindex;
CREATE TABLE dbo.missingindex (col1 INT IDENTITY PRIMARY KEY, col2 INT);
DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
WHILE @a < 20000
BEGIN
    INSERT INTO dbo.missingindex(col2) VALUES (@a);
    SET @a += 1;
END
COMMIT TRANSACTION;
GO
SELECT m1.col1 
FROM dbo.missingindex m1 INNER JOIN dbo.missingindex m2 ON(m1.col1=m2.col1) 
WHERE m1.col2 = 4;


Bestimmte Funktionen in Azure SQL-Datenbank liefern Datenbankadministratoren Hinweise zum Suchen und Beheben allgemeiner Probleme, die durch fehlende Indizes verursacht werden. In den integrierten dynamischen Verwaltungssichten (Dynamic Management Views, DMVs) von Azure SQL-Datenbank wird die Abfragekompilierung daraufhin überprüft, ob die geschätzten Kosten zur Ausführung einer Abfrage durch einen Index spürbar verringert werden könnten. Während der Abfrageausführung werden die Ausführungshäufigkeit jedes Abfrageplans sowie die geschätzte Differenz zwischen dem ausgeführten Abfrageplan und einem imaginären Abfrageplan, der den Index enthält, nachverfolgt. So kann ein Datenbankadministrator schnell abschätzen, welche Änderungen am physischen Datenbankentwurf zu einer Optimierung des allgemeinen Kostenaufwands für die Arbeitsauslastung und der tatsächlichen Arbeitsauslastung einer angegebenen Datenbank führen können.

Mit der folgenden Abfrage kann überprüft werden, ob Indizes fehlen.

SELECT CONVERT (varchar, getdate(), 126) AS runtime, 
    mig.index_group_handle, mid.index_handle, 
    CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact * 
            (migs.user_seeks + migs.user_scans)) AS improvement_measure, 
    'CREATE INDEX missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + 
              CONVERT (varchar, mid.index_handle) + ' ON ' + mid.statement + ' 
              (' + ISNULL (mid.equality_columns,'') 
              + CASE WHEN mid.equality_columns IS NOT NULL 
                          AND mid.inequality_columns IS NOT NULL 
                     THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '')
              + ')' 
              + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, 
    migs.*, 
    mid.database_id, 
    mid.[object_id]
FROM sys.dm_db_missing_index_groups AS mig
INNER JOIN sys.dm_db_missing_index_group_stats AS migs 
    ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details AS mid 
    ON mig.index_handle = mid.index_handle
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

In diesem Beispiel wird der folgende Index empfohlen:

CREATE INDEX missing_index_5006_5005 ON [dbo].[missingindex] ([col2])

Nach der Erstellung wird mit der gleichen SELECT-Anweisung ein anderer Plan ausgewählt, der statt eines Scans eine Suche verwendet und effizienter ausgeführt wird, wie im folgenden Abfrageplan gezeigt.

Die wichtigste Erkenntnis ist, dass die E/A-Kapazität eines freigegebenen Standardsystems im Allgemeinen stärker beschränkt ist als die E/A-Kapazität eines dedizierten Servercomputers. Insofern lohnt es sich, unnötige E/A-Vorgänge zu reduzieren, um das System innerhalb der DTU, die für die einzelnen Leistungsstufen der neuen Dienstebenen gelten, in der Azure SQL-Datenbank optimal zu nutzen. Durch einen geeigneten physischen Datenbankentwurf lassen sich die Latenz für einzelne Abfragen und der Durchsatz gleichzeitiger Abfragen, die pro Skalierungseinheit behandelt werden können, wesentlich verbessern und die Kosten für die Abfrage minimieren. Weitere Informationen zu DMVs für fehlende Indizes finden Sie unter sys.dm_db_missing_index_details.

Der Abfrageoptimierer in Azure SQL-Datenbank ist dem bekannten SQL Server-Abfrageoptimierer sehr ähnlich. Viele bewährte Methoden, die die Abfrageoptimierung betreffen und die Beschränkungen des Argumentationsmodells für den Abfrageoptimierer verdeutlichen, gelten auch für die Azure SQL-Datenbank. Die Abfrageoptimierung in Azure SQL-Datenbank hat u. U. zusätzliche Vorteile, da der gesamte Ressourcenbedarf reduziert wird und eine Anwendung im Gegensatz zu ihrer nicht optimierten Entsprechung auf einer niedrigeren Leistungsstufe kostengünstiger ausgeführt werden kann.

Ein allgemeines Beispiel in SQL Server, das auch für Azure SQL-Datenbank gilt, ist das Ermitteln (Sniffing) von Parameterwerten während der Kompilierung, um die Planerstellung zu optimieren. Als Parametersniffing wird der Prozess bezeichnet, mit dem der Abfrageoptimierer beim Kompilieren einer Abfrage den aktuellen Wert eines Parameters berücksichtigt, um zu versuchen, einen besseren Abfrageplan zu generieren. Häufig lässt sich mit dieser Strategie ein Abfrageplan generieren, der wesentlich schneller als ein Plan ist, der ohne Berücksichtigung der Parameterwerte kompiliert wurde. Allerdings ist das derzeitige Verhalten von SQL Server/Azure SQL-Datenbank unzuverlässig. In einigen Fällen wird beim Parametersniffing kein Parameterwert ermittelt, und manchmal ist der generierte Plan für den vollständigen Satz von Parameterwerten in einer Arbeitsauslastung nicht geeignet, obwohl die Parameterwerte ermittelt werden konnten. Microsoft stellt Abfragehinweise (Direktiven) bereit, die es dem Kunden ermöglichen, Absichten gezielter anzugeben und das Standardverhalten für Parametersniffing zu überschreiben. Häufig lassen sich mit Hinweisen Situationen korrigieren, in denen das Standardverhalten von SQL Server/Azure SQL-Datenbank für die Arbeitsauslastung eines bestimmten Kunden nicht geeignet ist.

Das folgende Beispiel zeigt, wie der Abfrageprozessor einen Plan generieren kann, der sowohl für die Leistung als auch für die Ressourcenanforderungen wenig geeignet ist, und wie die Abfragelaufzeit und Ressourcenanforderungen für Azure SQL-Datenbank mithilfe eines Abfragehinweises reduziert werden können.

Beispiel für den Setupcode:

DROP TABLE psptest1;
CREATE TABLE psptest1(col1 int primary key identity, col2 int, col3 binary(200));

DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
WHILE @a < 20000
BEGIN
    INSERT INTO psptest1(col2) values (1);
    INSERT INTO psptest1(col2) values (@a);
    SET @a += 1;
END
COMMIT TRANSACTION
CREATE INDEX i1 on psptest1(col2);
GO

CREATE PROCEDURE psp1 (@param1 int)
AS
BEGIN
    INSERT INTO t1 SELECT * FROM psptest1 
    WHERE col2 = @param1
    ORDER BY col2;
END
GO

CREATE PROCEDURE psp2 (@param2 int)
AS
BEGIN
    INSERT INTO t1 SELECT * FROM psptest1 WHERE col2 = @param2
    ORDER BY col2
    OPTION (OPTIMIZE FOR (@param2 UNKNOWN))
END
GO

CREATE TABLE t1 (col1 int primary key, col2 int, col3 binary(200));
GO

Durch den Setupcode wird eine Tabelle erstellt, die eine schiefe Datenverteilung enthält. Der optimale Abfrageplan variiert abhängig davon, welcher Parameter ausgewählt ist. Leider wird durch das Plancaching nicht immer die Abfrage auf Grundlage des häufigsten Parameterwerts neu kompiliert. Das bedeutet, dass möglicherweise ein nicht optimaler Plan zwischengespeichert und für viele Werte verwendet wird, selbst wenn ein anderer Plan für den Durchschnittsfall besser geeignet ist. Anschließend werden zwei gespeicherte Prozeduren erstellt, die fast identisch sind und sich nur darin unterscheiden, dass eine von ihnen einen speziellen Abfragehinweis enthält (die zugrunde liegende Überlegung wird weiter unten erläutert).

Beispiel (Teil 1):

-- Prime Procedure Cache with scan plan
EXEC psp1 @param1=1;
TRUNCATE TABLE t1;

-- Iterate multiple times to show the performance difference
DECLARE @i int = 0;
WHILE @i < 1000
BEGIN
    EXEC psp1 @param1=2;
    TRUNCATE TABLE t1;
    SET @i += 1;
END

Beispiel (Teil 2 – bitte warten Sie 10 Minuten, bevor Sie diesen Teil ausführen, damit sich die resultierenden Telemetriedaten deutlich unterscheiden):

EXEC psp2 @param2=1;
TRUNCATE TABLE t1;

DECLARE @i int = 0;
WHILE @i < 1000
BEGIN
    EXEC psp2 @param2=2;
    TRUNCATE TABLE t1;
    SET @i += 1;
END


In jedem Teil dieses Beispiels wird versucht, eine parametrisierte INSERT-Anweisung 1.000 Mal auszuführen (um eine ausreichende Last für ein relevantes Testdataset zu generieren). Der Abfrageprozessor überprüft beim Ausführen gespeicherter Prozeduren den Parameterwert, der während der ersten Kompilierung der Prozedur an diese übergeben wird (als Parametersniffing bezeichnet). Der resultierende Plan wird zwischengespeichert und für spätere Aufrufe verwendet, selbst wenn der Parameterwert abweicht. Daher wird der optimale Plan möglicherweise nicht in allen Fällen verwendet. Manchmal müssen Kunden den Optimierer anweisen, einen Plan auszuwählen, der besser für den Durchschnittsfall als für den speziellen Fall geeignet ist, als die Abfrage zuerst kompiliert wurde. In diesem Beispiel generiert der ursprüngliche Plan einen Scanplan, der alle Zeilen liest, um jeden Wert zu suchen, der mit dem Parameter übereinstimmt:

Da die Prozedur mit dem Wert 1 ausgeführt wurde, war der resultierende Plan für 1 optimal, jedoch für alle anderen Werte in der Tabelle nicht optimal. Das resultierende Verhalten ist wahrscheinlich nicht das gewünschte Verhalten, wenn der Kunde jeden Plan nach dem Zufallsprinzip auswählt, da der Plan langsamer ausgeführt wird und seine Ausführung mehr Ressourcen erfordert.

Wenn der Test mit "SET STATISTICS IO ON" ausgeführt wird, werden die logischen Scanvorgänge angezeigt, die in diesem Beispiel verdeckt erfolgt sind. Es ist ersichtlich, dass durch den Plan 1.148 Lesevorgänge ausgeführt werden (was ineffizient ist, wenn im Durchschnittsfall nur eine Zeile zurückgegeben wird):

Im zweiten Teil des Beispiels wird ein Abfragehinweis verwendet, um den Optimierer anzuweisen, während der Kompilierung einen bestimmten Wert zu verwenden. In diesem Fall wird der Abfrageprozessor gezwungen, den als Parameter übergebenen Wert zu ignorieren und stattdessen anzunehmen, dass der Wert "UNKNOWN" lautet. Dies ist ein Wert, der die durchschnittliche Häufigkeit in der Tabelle aufweist (wobei Verzerrung ignoriert wird). Der resultierende Plan ist ein Suchplan, der durchschnittlich schneller ausgeführt wird und weniger Ressourcen erfordert als der Plan aus Teil 1 des Beispiels:

Die Auswirkungen sind in der Tabelle sys.resource_stats zu sehen. (Hinweis: Nach dem Ausführen des Tests wird die Tabelle erst nach einer Verzögerung mit Daten aufgefüllt). In diesem Beispiel wurde Teil 1 um 22:25:00 und Teil 2 um 22:35:00 ausgeführt. Beachten Sie, dass im früheren Zeitfenster mehr Ressourcen als im späteren Zeitfenster beansprucht wurden (weil die Effizienz des Plans verbessert wurde).

SELECT TOP 1000 * 
FROM sys.resource_stats 
WHERE database_name = 'resource1' 
ORDER BY start_time DESC

ImportantWichtig
Das hier verwendete Beispiel wurde absichtlich klein gehalten, jedoch kann besonders bei größeren Datenbanken die Auswirkung von nicht optimalen Parametern beträchtlich sein. In extremen Fällen kann es sich um einen Unterschied zwischen Sekunden und Stunden für den schnellsten bzw. langsamsten Fall handeln.

Kunden können anhand von sys.resource_stats bestimmen, ob für einen bestimmten Test mehr oder weniger Ressourcen als für einen anderen Test verwendet werden. Wenn Sie Daten vergleichen, sollte zwischen den Tests genügend Zeit liegen, damit sie in der Sicht sys.resource_stats nicht im gleichen 5-Minuten-Zeitfenster gruppiert werden. Darüber hinaus besteht das Ziel darin, den Gesamtressourcenverbrauch und nicht die Ressourcen für Spitzenlasten zu reduzieren. Wenn Code zur Minimierung von Latenzzeiten optimiert wird, wirkt sich dies im Allgemeinen auch günstig auf den Ressourcenverbrauch aus. Wenn Sie Abfragehinweise verwenden, stellen Sie sicher, dass die für eine Anwendung erwogenen Änderungen tatsächlich erforderlich sind und nicht die Benutzererfahrung bei der Verwendung einer Anwendung beeinträchtigen.

Wenn eine Arbeitsauslastung eine Reihe wiederholter Abfragen enthält, ist es häufig sinnvoll, die Planoptionen aufzuzeichnen und ihre Optimalität zu überprüfen, da hierdurch wahrscheinlich die minimale Einheit für die Ressourcengröße erhöht wird, die zum Hosten der Datenbank erforderlich ist. Nachdem diese Pläne überprüft wurden, lässt sich durch ihre gelegentliche nochmalige Überprüfung sicherstellen, dass sich ihre Eignung nicht verringert hat. Weitere Informationen zu Abfragehinweisen finden Sie unter Abfragehinweise (Transact-SQL).

Da Azure SQL-Datenbank auf Standardhardware ausgeführt wird, gelten für eine einzelne Datenbank in der Regel niedrigere Kapazitätsgrenzen als bei einer herkömmlichen, lokalen SQL Server-Installation. Einige Kunden verteilen Datenbankvorgänge mithilfe von Shardingtechniken auf mehrere Datenbanken, wenn sie die Beschränkungen einer einzelnen Datenbank in Azure SQL-Datenbank überschreiten. Die meisten Kunden, die derzeit Shardingverfahren in Azure SQL-Datenbank verwenden, teilen die Daten einer einzelnen Dimension auf mehrere Datenbanken auf. Bei diesem Ansatz muss berücksichtigt werden, dass OLTP-Anwendungen häufig Transaktionen ausführen, die nur auf eine Zeile oder eine kleine Gruppe von Zeilen im Schema angewendet werden. Wenn eine Datenbank beispielsweise Daten zu Kunden, Aufträgen und Auftragsdetails enthält (wie in der ursprünglichen Northwind-Beispieldatenbank, die mit SQL Server geliefert wird), können diese Daten auf mehrere Datenbanken aufgeteilt werden, indem ein Kunde mit den zugehörigen Auftrags- und Auftragsdetailinformationen gruppiert und sichergestellt wird, dass diese in einer einzelnen Datenbank bleiben. Die Anwendung teilt unterschiedliche Kunden auf mehrere Datenbanken auf, wobei die Last auf mehrere Datenbanken verteilt wird. So können Kunden nicht nur die maximale Größenbeschränkung für Datenbanken umgehen, sondern mit Azure SQL-Datenbank auch Arbeitsauslastungen verarbeiten, die deutlich über den Kapazitätsgrenzen der verschiedenen Leistungsstufen liegen, solange jede einzelne Datenbank ihre DTUs nicht überschreitet.

Auch wenn das Datenbanksharding nicht die aggregierte Ressourcenkapazität für eine Lösung reduziert, arbeitet diese Technik bei sehr umfangreichen Lösungen, die über mehrere Datenbanken verteilt sind, äußerst effektiv. So kann jede Datenbank auf einer unterschiedlichen Leistungsstufe ausgeführt werden, um sehr große "effektive" Datenbanken mit hohem Ressourcenbedarf zu unterstützen.

SQL Server-Benutzer kombinieren häufig viele Funktionen in einer einzelnen Datenbank. Wenn beispielsweise eine Anwendung Logik zum Verwalten des Bestands für ein Geschäft enthält, kann die Datenbank Logik für den Bestand, zum Nachverfolgen von Bestellungen, gespeicherte Prozeduren und indizierte/materialisierte Sichten zum Verwalten von Monatsabschlussberichten sowie weitere Funktionen enthalten. Diese Technik bietet den Vorteil, dass die Datenbank, z. B. bei Sicherungsvorgängen, einfach verwaltet werden kann. Sie erfordert jedoch auch, dass der Kunde die Hardware so dimensioniert, dass Spitzenlasten für alle Funktionen einer Anwendung bewältigt werden können.

Wenn in Azure SQL-Datenbank eine Architektur für horizontales Skalieren verwendet wird, ist es häufig von Vorteil, unterschiedliche Anwendungsfunktionen auf verschiedene Datenbanken zu verteilen. Dadurch kann jede Funktion unabhängig skaliert werden. Wenn die Auslastung einer Anwendung (und damit die Datenbanklast) zunimmt, kann der Administrator für jede Funktion in einer Anwendung unabhängig Leistungsstufen wählen. Diese Architektur ermöglicht es durch Verteilen der Last auf mehrere Computer, dass eine Anwendung die Größe überschreitet (innerhalb der Größenbeschränkung), die von einem einzelnen Standardcomputer bewältigt werden kann.

Bei Anwendungen, die mittels vieler, häufiger Ad-hoc-Abfragen auf Daten zugreifen, verursacht die Netzwerkkommunikation zwischen Anwendungsebene und Azure SQL-Datenbankebene lange Antwortzeiten. Selbst wenn sich die Anwendung und die Azure SQL-Datenbank im selben Rechenzentrum befinden, kann sich die Netzwerklatenz zwischen Anwendung und Datenbank durch eine große Anzahl von Datenzugriffen deutlich erhöhen. Um die Netzwerkroundtrips für diese Datenzugriffsvorgänge zu reduzieren, sollte der Anwendungsentwickler Optionen für die Batchverarbeitung der Ad-hoc-Abfragen oder das Kompilieren der Abfragen in gespeicherten Prozeduren in Betracht ziehen. Bei der Batchverarbeitung der Ad-hoc-Abfragen können mehrere Abfragen als großer Batch in einem einzelnen Vorgang an die Azure SQL-Datenbank gesendet werden. Durch Kompilieren von Ad-hoc-Abfragen in einer gespeicherten Prozedur lässt sich das gleiche Ergebnis wie durch die Batchverarbeitung erzielen. Durch eine gespeicherte Prozedur erhöhen sich außerdem die Chancen, dass die Abfragepläne für nachfolgende Ausführungen derselben gespeicherten Prozedur in der Azure SQL-Datenbank zwischengespeichert werden.

Einige Anwendungen sind schreibintensiv. Manchmal ist es möglich, die E/A-Gesamtlast einer Datenbank zu reduzieren, indem erwogen wird, wie sich Schreibvorgänge als Batch ausführen lassen. Häufig lässt sich dies einfach durch die Verwendung von expliziten Transaktionen anstelle von Transaktionen mit automatischem Commit in gespeicherten Prozeduren und Ad-hoc-Batches erreichen. Eine Bewertung von verschiedenen Verfahren, die verwendet werden können, finden Sie unter Stapelverarbeitungsverfahren für SQL-Datenbankanwendungen in Azure. Experimentieren Sie mit der eigenen Arbeitsauslastung, um das richtige Modell für die Batchverarbeitung zu ermitteln, und beachten Sie, dass sich die Garantie der Transaktionskonsistenz je nach Modell geringfügig unterscheiden kann. Um letztendlich die richtige Arbeitsauslastung zu ermitteln, mit der sich die Ressourcenverwendung reduzieren lässt, muss die richtige Balance zwischen Konsistenz und Leistung gefunden werden.

Manche Datenbankanwendungen enthalten Arbeitsauslastungen mit vielen Lesevorgängen. Mithilfe von Cachingebenen können die Datenbanklast und möglicherweise auch die Leistungsstufe reduziert werden, die zur Unterstützung einer Datenbank mit Azure SQL-Datenbank erforderlich ist. Der Azure-Cache (Cachedienst) bietet Kunden mit leseintensiven Arbeitsauslastungen die Möglichkeit, die Daten einmal (oder abhängig von der Konfiguration u. U. einmal pro Anwendungsebenencomputer) zu lesen und diese Daten außerhalb der Azure SQL-Datenbank zu speichern. Dies bietet eine Möglichkeit, die Datenbanklast (CPU und Lese-E/A) zu verringern, es beeinträchtigt jedoch die Transaktionskonsistenz, da die aus dem Cache gelesenen Daten möglicherweise in Bezug auf die Daten in der Datenbank veraltet sind. Während für viele Anwendungen ein gewisser Betrag von Inkonsistenz akzeptabel ist, gilt dies nicht für alle Arbeitsauslastungen. Machen Sie sich über alle Anwendungsanforderungen umfassend kundig, bevor Sie eine Cachingstrategie auf Anwendungsebene verwenden.

Die Einführung der neuen Leistungsstufen in Azure SQL-Datenbank eröffnet Kunden die Möglichkeit, weitere Anwendungstypen in der Cloud zu entwickeln. In Kombination mit sorgfältiger Anwendungsoptimierung können die Kunden eine hohe und zuverlässige Leistung für die Anwendung erzielen. In diesem Dokument werden empfohlene Verfahren vorgestellt, mit deren Hilfe der Ressourcenverbrauch einer Datenbank optimiert und effizient auf die Nutzung einer der neuen Leistungsstufen vorbereitet werden kann. Die Optimierung im Cloud-Modell ist ein kontinuierlicher Prozess. Mithilfe der neuen Dienstebenen und zugehörigen Leistungsstufen können Administratoren die Leistung auf der Microsoft Azure Platform maximieren und gleichzeitig Kosten senken.

Siehe auch

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft