Ressourcenverwaltung in umfangreichen Pools für elastische Datenbanken

Gilt für:: Azure SQL-Datenbank

Pools für elastische Azure SQL-Datenbanken sind eine kostengünstige Lösung zum Verwalten einer großen Zahl von Datenbanken mit variierender Ressourcenauslastung. Für alle Datenbanken eines Pools für elastische Datenbanken wird die gleiche Zuordnung von Ressourcen verwendet, z. B. CPU, Arbeitsspeicher, Workerthreads, Speicherplatz und tempdb. Dies erfolgt aufgrund der Annahme, dass Computeressourcen jeweils nur von einer Teilmenge der Datenbanken im Pool genutzt werden. Diese Annahme ermöglicht für Pools für elastische Datenbanken die Erzielung von Kosteneffizienz. Anstatt für alle Ressourcen zu bezahlen, die von jeder einzelnen Datenbank unter Umständen benötigt werden, zahlen Kunden für einen deutlich kleineren Ressourcensatz, der für alle Datenbanken des Pools genutzt wird.

Ressourcengovernance

Bei der Ressourcenfreigabe muss das System die Ressourcenauslastung sorgfältig kontrollieren, um den „Noisy Neighbor“-Effekt (lauter Nachbar) zu verringern, bei dem eine Datenbank mit hohem Ressourcenverbrauch andere Datenbanken in demselben Pool für elastische Datenbanken beeinträchtigt. Azure SQL-Datenbank erreicht diese Ziele durch Implementierung von Ressourcengovernance. Außerdem muss das System genügend Ressourcen für Features bereitstellen, z. B. Hochverfügbarkeit und Notfallwiederherstellung, Sicherung und Wiederherstellung, Überwachung, Abfragespeicher, automatische Optimierung usw., um zuverlässig zu funktionieren.

Das wichtigste Entwurfsziel von Pools für elastische Datenbanken ist Wirtschaftlichkeit. Aus diesem Grund lässt das System für Kunden absichtlich die Erstellung von umfangreichen Pools zu. Dies sind Pools, bei denen die Anzahl von Datenbanken nahezu oder vollständig erreicht wird, aber die nur über eine relativ geringe Zuordnung von Computeressourcen verfügen. Aus demselben Grund werden nicht alle potenziell benötigen Ressourcen für interne Prozesse reserviert, sondern die Ressourcenfreigabe zwischen internen Prozessen und Benutzerarbeitsauslastungen ermöglicht.

Diese Vorgehensweise ermöglicht Kunden die Verwendung von umfangreichen Pools für elastische Datenbanken, um eine ausreichende Leistung und größere Kosteneinsparungen zu erzielen. Wenn die Workload vieler Datenbanken in einem dichten Pool aber intensiv genug ist, müssen ggf. Ressourcenkonflikte beachtet werden. Bei Ressourcenkonflikten wird die Leistung von Benutzerarbeitsauslastungen reduziert, und es kann sich eine negative Auswirkung auf interne Prozesse ergeben.

Falls es in einem dicht gepackten Pool zu Ressourcenkonflikten kommt, können Kunden eine oder mehrere der folgenden Aktionen auswählen, um diese zu beheben:

• Optimieren Sie die Abfrageworkload, um den Ressourcenverbrauch zu reduzieren oder diesen mit der Zeit auf mehrere Datenbanken zu verteilen.
• Reduzieren der Pooldichte, indem einige Datenbanken in einen anderen Pool verschoben oder zu eigenständigen Datenbanken gemacht werden
• Hochskalieren des Pools zum Abrufen von weiteren Ressourcen

Vorschläge zur Implementierung der letzten beiden Aktionen finden Sie unter Empfehlungen zum Betrieb weiter unten in diesem Artikel. Die Reduzierung von Ressourcenkonflikten wirkt sich sowohl auf Benutzer als auch auf interne Prozesse positiv aus und ermöglicht es dem System, den erwarteten Servicelevel aufrechtzuerhalten.

Überwachen des Ressourcenverbrauchs

Zur Vermeidung von Leistungsbeeinträchtigungen aufgrund von Ressourcenkonflikten sollten Kunden, die umfangreiche Pools für elastische Datenbanken nutzen, den Ressourcenverbrauch proaktiv überwachen und rechtzeitig Maßnahmen ergreifen, falls sich zunehmende Ressourcenkonflikte auf die Arbeitsauslastungen auswirken. Eine fortlaufende Überwachung ist wichtig, weil sich die Ressourcenauslastung in einem Pool im Laufe der Zeit verändert, z. B. aufgrund von Änderungen der Benutzerworkloads, der Datenmenge und -verteilung, der Pooldichte und im Azure SQL-Datenbank-Dienst.

Azure SQL-Datenbank verfügt über mehrere Metriken, die für diese Art von Überwachung relevant sind. Wenn Sie den empfohlenen Durchschnittswert für jede Metrik überschreiten, wird ein Ressourcenkonflikt für den Pool angezeigt, den Sie mit einer der oben beschriebenen Maßnahmen beseitigen sollten.

Um eine Warnung zu senden, wenn die Poolressourcenauslastung (CPU, Daten-E/A, Protokoll-E/A, Workers usw.) einen Schwellenwert überschreitet, können Sie über das Azure-Portal oder das PowerShell-Cmdlet Add-AzMetricAlertRulev2 Warnungen erstellen. Bei der Überwachung von Pools für elastische Datenbanken können Sie ggf. auch Warnungen für einzelne Datenbanken im Pool erstellen, sollte dies in Ihrem Szenario erforderlich sein. Ein Beispielszenario für die Überwachung von Pools für elastische Datenbanken finden Sie unter Überwachen und Verwalten der Leistung von Azure SQL-Datenbank in einer mehrinstanzenfähigen SaaS-App.

Zusätzlich zu diesen Metriken bietet Azure SQL-Datenbank eine Ansicht, in der die tatsächlichen Grenzwerte für die Ressourcenkontrolle zurückgegeben werden. Außerdem gibt es zusätzliche Ansichten, in denen statistische Daten zur Ressourcenauslastung auf Ebene des Ressourcenpools und auf Ebene der Arbeitsauslastungsgruppe zurückgegeben werden.

Diese Ansichten können verwendet werden, um die Ressourcennutzung zu überwachen und Probleme aufgrund von Ressourcenkonflikten nahezu in Echtzeit zu behandeln. Die Benutzerarbeitsauslastung auf den primären und lesbaren sekundären Replikaten, einschließlich Georeplikaten, wird als Ressourcenpool SloSharedPool1 und Arbeitsauslastungsgruppe UserPrimaryGroup.DBId[N] klassifiziert, wobei N für den Datenbank-ID-Wert steht.

Zusätzlich zur Überwachung der aktuellen Ressourcennutzung können Kunden, die umfangreiche Pools nutzen, Verlaufsdaten zur Ressourcennutzung in einem separaten Datenspeicher aufbewahren. Diese Daten können für Vorhersageanalysen verwendet werden, um die Ressourcennutzung basierend auf verlaufsabhängigen und saisonalen Trends proaktiv zu verwalten.

Empfehlungen zum Betrieb

Bereitstellen von genügend Platz für Ressourcen: Wenn es zu Ressourcenkonflikten und Leistungsbeeinträchtigungen kommt, kann eine Entschärfung – wie bereits erwähnt – das Verschieben einiger Datenbanken aus dem betroffenen Pool für elastische Datenbanken oder das zentrale Hochskalieren des Pools umfassen. Für diese Aktionen sind aber zusätzliche Computeressourcen erforderlich. Vor allem für Premium- und unternehmenskritische Pools müssen für diese Aktionen alle Daten für die zu verschiebenden Datenbanken bzw. für alle Datenbanken des Pools für elastische Datenbanken übertragen werden, wenn der Pool zentral hochskaliert wird. Die Datenübertragung ist ein zeit- und ressourcenintensiver Vorgang. Wenn die Ressourcenauslastung im Pool bereits hoch ist, wird die Leistung durch die Behebungsmaßnahmen noch weiter beeinträchtigt. In Extremfällen ist es unter Umständen nicht möglich, Ressourcenkonflikte durch eine Datenbankverschiebung oder das zentrale Hochskalieren des Pools zu lösen, weil die benötigten Ressourcen nicht verfügbar sind. Die einzige Lösung ist dann ggf. das vorübergehende Reduzieren der Arbeitsauslastung von Abfragen für den betroffenen Pool für elastische Datenbanken.

Kunden, die umfangreiche Pools nutzen, sollten die Nutzungstrends sorgfältig überwachen (wie oben beschrieben) und Maßnahmen zur Entschärfung ergreifen, während die Metriken noch in den empfohlenen Bereichen liegen und im Pool für elastische Datenbanken noch genügend Ressourcen vorhanden sind.

Die Ressourcennutzung hängt von mehreren Faktoren ab, die sich je nach Datenbank und Pool für elastische Datenbanken im Laufe der Zeit ändern. Zur Erzielung eines optimalen Preis-Leistungs-Verhältnisses in umfangreichen Pools sind eine fortlaufende Überwachung und erneute Anpassungen erforderlich, bei denen Datenbanken aus stärker genutzten Pools in weniger stark genutzte Pools verschoben und je nach Bedarf neue Pools erstellt werden, um eine erhöhte Arbeitsauslastung abdecken zu können.

Vermeiden der Verschiebung von „heißen“ Datenbanken: Wenn Ressourcenkonflikte auf Poolebene hauptsächlich durch eine geringe Anzahl von hoch ausgelasteten Datenbanken verursacht werden, kann es verlockend sein, diese Datenbanken in einen weniger stark genutzten Pool zu verschieben oder sie zu eigenständigen Datenbanken zu machen. Dies ist aber nicht empfehlenswert, wenn eine Datenbank längere Zeit stark ausgelastet ist, weil die Leistung durch den Verschiebungsvorgang noch mehr beeinträchtigt wird. Dies gilt sowohl für die zu verschiebende Datenbank als auch für den gesamten Pool. Warten Sie stattdessen entweder, bis die hohe Auslastung abnimmt, oder verschieben Sie weniger stark genutzte Datenbanken, um die Ressourcenauslastung auf Poolebene zu reduzieren. Das Verschieben von Datenbanken mit sehr geringer Auslastung ergibt in diesem Fall aber keinen Vorteil, da die Ressourcenauslastung auf Poolebene nicht wesentlich verringert wird.

Erstellen von neuen Datenbanken in einem „Quarantänepool“ : In Szenarien, in denen häufig neue Datenbanken erstellt werden, z. B. bei Anwendungen mit dem Modell „ein Mandant pro Datenbank“, besteht die folgende Gefahr: Eine neue Datenbank, die in einem vorhandenen Pool für elastische Datenbanken angeordnet wird, verbraucht unerwartet eine sehr große Menge an Ressourcen und beeinträchtigt andere Datenbanken und interne Prozesse im Pool. Erstellen Sie zur Verringerung dieser Gefahr einen separaten „Quarantänepool“ mit einer ausreichenden Ressourcenzuordnung. Verwenden Sie diesen Pool für neue Datenbanken, für die das Muster des Ressourcenverbrauchs noch nicht bekannt ist. Nachdem sich eine Datenbank einen Geschäftszyklus lang in diesem Pool befunden hat, z. B. eine Woche oder einen Monat, und der Ressourcenverbrauch bekannt ist, kann sie in einen Pool mit ausreichender Kapazität verschoben werden, um diese zusätzliche Ressourcennutzung abzudecken.

Überwachen Sie sowohl den verwendeten als auch den zugewiesenen Speicherplatz. Wenn der im Pool zugewiesene Speicherplatz (Gesamtgröße aller Datenbankdateien im Speicher für alle Datenbanken in einem Pool) die maximale Poolgröße erreicht, können Fehler aufgrund von fehlendem Speicherplatz auftreten. Wenn die Trends beim zugeordneten Speicherplatz hoch sind und die maximale Poolgröße demnächst erreicht wird, stehen Ihnen zur Entschärfung folgende Optionen zur Verfügung:

• Verschieben einiger Datenbanken aus dem Pool, um den zugeordneten Gesamtspeicherplatz zu reduzieren
• Verkleinern von Datenbankdateien, um leeren zugewiesenen Speicherplatz in Dateien zu verringern
• Hochskalieren des Pools auf ein Dienstziel mit einer größeren maximalen Poolgröße

Wenn die Trends beim genutzten Speicherplatz im Pool (Gesamtgröße der Daten in allen Datenbanken in einem Pool, ohne Leerraum in Dateien) hoch sind und demnächst die maximale Poolgröße erreicht wird, stehen Ihnen zur Entschärfung folgende Optionen zur Verfügung:

• Verschieben einiger Datenbanken aus dem Pool, um den genutzten Gesamtspeicherplatz zu reduzieren
• Verschieben (Archivieren) von Daten außerhalb der Datenbank oder Löschen nicht mehr benötigter Daten
• Implementieren einer Datenkomprimierung
• Hochskalieren des Pools auf ein Dienstziel mit einer größeren maximalen Poolgröße

Vermeiden Sie Server mit übermäßiger Dichte. Azure SQL-Datenbank unterstützt bis zu 5000 Datenbanken pro Server. Kunden, die Pools für elastische Datenbanken mit Tausenden von Datenbanken verwenden, können erwägen, mehrere Pools für elastische Datenbanken auf einem einzelnen Server anzuordnen und in Bezug auf die unterstützte maximale Anzahl von Datenbanken ans Limit zu gehen. Server mit vielen Tausenden Datenbanken sind aber mit besonderen Anforderungen an den Betrieb verbunden, die bewältigt werden müssen. Vorgänge, bei denen alle Datenbanken auf einem Server aufgelistet werden müssen, z. B. beim Anzeigen von Datenbanken im Portal, benötigen mehr Zeit. Betriebsbezogene Fehler, z. B. die fehlerhafte Änderung von Anmeldungen auf Serverebene oder von Firewallregeln, wirken sich auf eine größere Zahl von Datenbanken aus. Nach dem versehentlichen Löschen des Servers benötigen Sie Hilfe vom Microsoft-Support, um die Datenbanken auf dem gelöschten Server wiederherstellen zu lassen, und es kommt für alle betroffenen Datenbanken zu einem längeren Ausfall.

Legen Sie die Anzahl von Datenbanken pro Server auf eine niedrigere Anzahl als den maximal unterstützten Wert fest. In vielen Szenarien ist die Nutzung von maximal 1.000 - 2.000 Datenbanken pro Server optimal. Um die Wahrscheinlichkeit zu verringern, dass ein Server versehentlich gelöscht wird, sollten Sie eine Löschsperre auf dem Server oder in der zugehörigen Ressourcengruppe hinzufügen.

Beispiele

Anzeigen der Kapazitätseinstellungen für einzelne Datenbanken

In der dynamischen Verwaltungssicht sys.dm_user_db_resource_governance können Sie die tatsächlichen Konfigurations- und Kapazitätseinstellungen anzeigen, die von der Ressourcengovernance in der aktuellen Datenbank oder im aktuellen Pool für elastische Datenbanken verwendet werden. Weitere Informationen finden Sie unter sys.dm_user_db_resource_governance.

Führen Sie diese Abfrage in einer beliebigen Datenbank in einem Pool für elastische Datenbanken aus. Für alle Datenbanken im Pool sind die gleichen Einstellungen für Ressourcengovernance festgelegt.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Überwachen des gesamten Ressourcenverbrauchs der Pools für elastische Datenbanken

Verwenden Sie die Systemkatalogsicht sys.elastic_pool_resource_stats, um den Ressourcenverbrauch des gesamten Pools zu überwachen. Weitere Informationen finden Sie unter sys.elastic_pool_resource_stats.

Diese Beispielabfrage zum Anzeigen der letzten zehn Minuten sollte in master-Datenbank des logischen Azure SQL-Servers ausgeführt werden, der den gewünschten Pool für elastische Datenbanken enthält.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Überwachen des Ressourcenverbrauchs einzelner Datenbanken

Verwenden Sie die dynamische Verwaltungssicht sys.dm_db_resource_stats, um den Ressourcenverbrauch einzelner Datenbanken zu überwachen. Weitere Informationen finden Sie unter sys.dm_db_resource_stats. Jede Zeile wird jeweils 15 Sekunden lang beibehalten, auch wenn keine Aktivität vorhanden ist. Historische Daten werden etwa eine Stunde lang gespeichert.

Diese Beispielabfrage zum Anzeigen von Daten der letzten zehn Minuten sollte in der gewünschten Datenbank ausgeführt werden.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Ziehen Sie für eine längere Aufbewahrungsdauer und größere Abstände die folgende Abfrage für sys.resource_stats in Betracht, die in der master-Datenbank des logischen Azure SQL-Servers ausgeführt wird. Weitere Informationen finden Sie unter sys.resource_stats (Azure SQL-Datenbank). Jede Zeile wird jeweils fünf Minuten beibehalten, und Verlaufsdaten werden zwei Wochen lang gespeichert.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Überwachen der Arbeitsspeicherauslastung

Mit dieser Abfrage wird die Metrik oom_per_second für jeden Ressourcenpool für den aktuellen Verlauf berechnet, basierend auf der Anzahl der verfügbaren Momentaufnahmen. Mit dieser Beispielabfrage können Sie ermitteln, für wie viele Speicherzuordnungen im Pool zuletzt durchschnittlich Fehler aufgetreten sind. Diese Abfrage kann in jeder Datenbank eines Pools für elastische Datenbanken ausgeführt werden.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Überwachen der Auslastung des tempdb-Protokollspeichers

Die Abfrage gibt den aktuellen Wert der tempdb_log_used_percent-Metrik zurück und zeigt die relative Nutzung des tempdb-Transaktionsprotokolls im Verhältnis zu seiner maximal zulässigen Größe. Diese Abfrage kann in jeder Datenbank eines Pools für elastische Datenbanken ausgeführt werden.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

Nächste Schritte

• Eine Einführung in Pools für elastische Datenbanken finden Sie unter Pools für elastische Datenbanken als Hilfe beim Verwalten und Skalieren mehrerer Datenbanken in Azure SQL-Datenbank.
• Informationen zum Optimieren der Arbeitsauslastungen von Abfragen zur Reduzierung der Ressourcennutzung finden Sie unter Überwachung und Optimierung und Überwachen und Optimieren der Datenbankleistung.