Skalieren von Einzeldatenbankressourcen in Azure SQL-Datenbank

In diesem Artikel wird beschrieben, wie die für eine Azure SQL-Datenbank-Instanz im bereitgestellten Computetarif verfügbaren Compute- und Speicherressourcen skaliert werden können. Alternativ bietet die serverlose Computeebene automatische Computeskalierung und eine Abrechnung der genutzten Computekapazität pro Sekunde.

Nach dem Auswählen der Anzahl von virtuellen Kernen und DTUs können Sie eine einzelne Datenbank dynamisch und bedarfsgerecht zentral hoch- oder herunterskalieren. Hierzu können Sie Folgendes verwenden:

Das folgende Video zeigt die dynamische Änderung von Dienstebene und Computegröße zum Heraufsetzen verfügbarer DTUs für eine einzelne Datenbank.

Wichtig

Unter bestimmten Umständen müssen Sie ggf. eine Datenbank verkleinern, um ungenutzten Speicherplatz freizugeben. Weitere Informationen finden Sie unter Verwalten von Dateispeicherplatz in Azure SQL-Datenbank.

Auswirkung

Zum Ändern der Dienstebene oder der Computegröße müssen hauptsächlich die folgenden Schritte ausgeführt werden:

  1. Erstellen Sie eine neue Computeinstanz für die Datenbank.

    Eine neue Computeinstanz wird mit der angeforderten Dienstebene und Computegröße erstellt. Bei einigen Kombinationen aus Änderungen der Dienstebene und der Computegröße muss in der neuen Computeinstanz ein Replikat der Datenbank erstellt werden. Dies umfasst das Kopieren von Daten und kann sich stark auf die Gesamtwartezeit auswirken. Die Datenbank bleibt unabhängig davon während dieses Schritts online, und Verbindungen werden weiterhin an die Datenbank in der ursprünglichen Computeinstanz weitergeleitet.

  2. Leiten Sie die Verbindungen zu einer neuen Computeinstanz um.

    Vorhandene Verbindungen zur Datenbank in der ursprünglichen Computeinstanz werden verworfen. Alle neuen Verbindungen werden mit der Datenbank in der neuen Computeinstanz hergestellt. Bei einigen Kombinationen von Dienstebenen- und Computegrößenänderungen werden Datenbankdateien während des Wechsels getrennt und neu angefügt. Der Wechsel kann zu einer kurzen Dienstunterbrechung führen, in der die Datenbank in der Regel für weniger als 30 Sekunden nicht verfügbar ist. Sollten zu dem Zeitpunkt, zu dem die Verbindungen getrennt werden, zeitintensive Transaktionen ausgeführt werden, kann dieser Schritt länger dauern, weil abgebrochene Transaktionen wiederhergestellt werden müssen. Mit der schnelleren Datenbankwiederherstellung können die Auswirkungen abgebrochener, zeitintensiver Transaktionen reduziert werden.

Wichtig

Während dieses Workflows gehen keine Daten verloren. Implementieren Sie unbedingt auch Wiederholungslogik in den Anwendungen und Komponenten, die Azure SQL-Datenbank verwenden, während die Dienstebene geändert wird.

Latency

Beim Ändern der Dienstebene, beim Skalieren der Computegröße einer Einzeldatenbank oder eines Pools für elastische Datenbanken, beim Verschieben einer Datenbank in einen/aus einem Pool für elastische Datenbanken oder beim Verschieben einer Datenbank zwischen Pools für elastische Datenbanken wird die geschätzte Wartezeit wie folgt parametrisiert:

Dienstebene Einzeldatenbank des Tarifs „Basic“,
Standard (S0-S1)
Pools für elastische Datenbanken des Tarifs „Basic“,
Standard (S2-S12),
Einzeldatenbank oder Pool für elastische Datenbanken des Tarifs „Universell“
Einzeldatenbank oder Pool für elastische Datenbanken der Tarife „Premium“ oder „Unternehmenskritisch“ Hyperscale
Einzeldatenbank des Tarifs „Basic“,
Standard (S0-S1)
•  Konstante Wartezeit unabhängig vom verwendeten Speicherplatz
•  In der Regel weniger als fünf Minuten
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
Pool für elastische Datenbanken des Tarifs „Basic“,
Standard (S2–S12),
Einzeldatenbank oder Pool für elastische Datenbanken des Tarifs „Universell“
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Bei Einzeldatenbanken konstante Wartezeit unabhängig vom verwendeten Speicherplatz
•  In der Regel weniger als fünf Minuten bei Einzeldatenbanken
•  Bei Pools für elastische Datenbanken proportional zur Anzahl der Datenbanken
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
Einzeldatenbank oder Pool für elastische Datenbanken der Tarife „Premium“ oder „Unternehmenskritisch“ •  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
•  Wartezeit proportional zum verwendeten Datenbankspeicherplatz aufgrund des Kopierens von Daten
•  In der Regel weniger als eine Minute pro GB (verwendeter Speicherplatz)
Hyperscale N/V Nicht zutreffend N/V •  Konstante Wartezeit unabhängig vom verwendeten Speicherplatz
•  In der Regel weniger als zwei Minuten

Hinweis

Darüber hinaus ist bei Datenbanken vom Typ „Standard (S2-S12)“ und „Universell“ die Wartezeit beim Verschieben einer Datenbank in einen/aus einem Pool für elastische Datenbanken oder zwischen Pools für elastische Datenbanken proportional zur Datenbankgröße, wenn für die Datenbank PFS-Speicher (Premium File Share, Premium-Dateifreigabe) verwendet wird.

Um zu ermitteln, ob eine Datenbank PFS-Speicher verwendet, führen Sie die folgende Abfrage im Kontext der Datenbank aus. Wenn der Wert in der Spalte „AccountType“ PremiumFileStorage oder PremiumFileStorage-ZRS lautet, verwendet die Datenbank PFS-Speicher.

SELECT s.file_id,
       s.type_desc,
       s.name,
       FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');

Hinweis

Die Zonen redundante Eigenschaft bleibt bei der Skalierung von der unternehmenskritisch auf die universell Ebene standardmäßig unverändert. Die Latenz für diese Herabstufung, wenn die Zonenredundanz aktiviert ist, sowie die Latenz für den Wechsel zur Zonenredundanz für die universelle Schicht ist proportional zur Datenbankgröße.

Tipp

Weitere Informationen zum Überwachen aktuell ausgeführter Vorgänge finden Sie unter: Verwalten von Vorgängen mit der SQL-REST-API, Verwalten von Vorgängen mithilfe der CLI, Überwachen von Vorgängen mit T-SQL und unter diesen beiden PowerShell-Befehlen: Get-AzSqlDatabaseActivity und Stop-AzSqlDatabaseActivity.

Abbrechen von Änderungen

Die Änderung einer Dienstebene oder der Vorgang zur Computeneuskalierung kann abgebrochen werden.

Das Azure-Portal

Navigieren Sie auf dem Blatt mit der Datenbankübersicht zu Benachrichtigungen, und klicken Sie auf die Kachel mit dem Hinweis, dass derzeit ein Vorgang ausgeführt wird:

Laufender Vorgang

Klicken Sie anschließend auf die Schaltfläche mit der Bezeichnung Diesen Vorgang abbrechen.

Abbrechen des laufenden Vorgangs

PowerShell

Legen Sie an einer PowerShell-Eingabeaufforderung $resourceGroupName, $serverName und $databaseName fest, und führen Sie dann den folgenden Befehl aus:

$operationName = (az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv)
if (-not [string]::IsNullOrEmpty($operationName)) {
    (az sql db op cancel --resource-group $resourceGroupName --server $serverName --database $databaseName --name $operationName)
        "Operation " + $operationName + " has been canceled"
}
else {
    "No service tier change or compute rescaling operation found"
}

Weitere Überlegungen

  • Wenn Sie ein Upgrade auf eine höhere Dienstebene oder Computegröße durchführen, wird die maximale Datenbankgröße nur erhöht, wenn Sie explizit eine höhere Maximalgröße angeben.
  • Für das Downgrade einer Datenbank muss die verwendete Datenbankmenge kleiner als die maximal zulässige Größe der Zieldienstebene und der Zielcomputegröße sein.
  • Bei einem Downgrade von der Dienstebene Premium zu Standard fallen zusätzliche Speicherkosten an, wenn (1) die maximale Größe der Datenbank von der Zielcomputegröße unterstützt wird und (2) die maximale Größe in der Zielcomputegröße die enthaltene Speichermenge überschreitet. Wenn z.B. eine P1-Datenbank mit einer maximalen Größe von 500GB auf S3 reduziert wird, fallen zusätzliche Speicherkosten an, da S3 eine maximale Größe von 1TB unterstützt und die enthaltene Speichermenge nur 250GB beträgt. Daher beträgt die zusätzliche Speichermenge 500 GB – 250 GB = 250 GB. Informationen zu den Preisen für zusätzlichen Speicherplatz siehe Preise für Azure SQL-Datenbank. Wenn die tatsächlich verwendete Speichermenge kleiner als die enthaltene Speichermenge ist, können Sie diese zusätzlichen Kosten vermeiden, indem Sie die maximale Datenbankgröße auf die enthaltene Menge reduzieren.
  • Beim Upgrade einer Datenbank mit aktivierter Georeplikation führen Sie zuerst ein Upgrade der sekundären Datenbanken auf die gewünschte Dienstebene und die gewünschte Computegröße durch, bevor Sie ein Upgrade für die primäre Datenbank vornehmen (allgemeine Richtlinie für optimale Leistung). Wenn Sie ein Upgrade auf eine andere Edition durchführen möchten, muss zuerst die sekundäre Datenbank aktualisiert werden.
  • Beim Downgrade einer Datenbank mit aktivierter Georeplikation führen Sie zuerst ein Downgrade der primären Datenbank auf die gewünschte Dienstebene und die gewünschte Computegröße durch, bevor Sie ein Downgrade für die sekundären Datenbanken vornehmen (allgemeine Richtlinie für optimale Leistung). Bei einem Downgrade auf eine andere Edition muss zuerst die primäre Datenbank herabgestuft werden.
  • Die Angebote des Wiederherstellungsdiensts variieren für die verschiedenen Dienstebenen. Bei einem Downgrade auf den Tarif Basic ergibt sich ein kürzerer Aufbewahrungszeitraum für Sicherungen. Weitere Informationen finden Sie unter Azure SQL-Datenbanksicherungen.
  • Die neuen Eigenschaften für die Datenbank werden erst angewendet, wenn die Änderungen abgeschlossen sind.
  • Wenn beim Ändern der Dienstebene Daten kopiert werden müssen, um eine Datenbank zu skalieren (siehe Wartezeit), und während der Skalierung eine hohe Ressourcenauslastung besteht, kann die Skalierung mehr Zeit erfordern. Bei der beschleunigten Datenbankwiederherstellung (Accelerated Database Recovery, ADR) ist ein Rollback von Transaktionen mit langer Ausführungszeit kein wesentlicher Faktor für Verzögerungen. Eine hohe gleichzeitige Ressourcenauslastung kann jedoch bewirken, dass weniger Compute- und Speicherressourcen und weniger Netzwerkbandbreite für die Skalierung verfügbar sind, insbesondere bei geringeren Computegrößen.

Abrechnung

Die Abrechnung erfolgt für jede Stunde, in der eine Datenbank die höchste in dieser Stunde angewendete Dienstebene und Computegröße nutzt – unabhängig von der Nutzung und unabhängig davon, ob die Datenbank weniger als eine Stunde aktiv war. Wenn Sie beispielsweise eine Einzeldatenbank erstellen und diese fünf Minuten später löschen, wird Ihnen eine volle Datenbankstunde in Rechnung gestellt.

Ändern der Speichergröße

vCore-basiertes Kaufmodell

  • Speicher kann in Inkrementen von 1 GB bis zur maximalen Datenspeichergröße bereitgestellt werden. Die konfigurierbare Mindestdatenspeichergröße ist 1 GB. Informationen zur maximalen Größe der Datenspeicherung in den einzelnen Dienstzielen finden Sie auf den Dokumentationsseiten zu Ressourcenlimits unter Ressourcenlimits für Singletons mit dem auf virtuellen Kernen (V-Kernen) basierenden Kaufmodell sowie unter Ressourcengrenzwerte für Einzeldatenbanken, die das DTU-Kaufmodell verwenden: Azure SQL-Datenbank.
  • Datenspeicher für eine Einzeldatenbank kann durch Erhöhen oder Verringern der maximalen Größe über das Azure-Portal, Transact-SQL, PowerShell, die Azure CLI oder die REST-API bereitgestellt werden. Wenn der Wert für die maximale Größe in Bytes angegeben wird, muss er ein Vielfaches von 1 GB (1073741824 Bytes) sein.
  • Die Menge der Daten, die in den Datendateien einer Datenbank gespeichert werden kann, ist durch die konfigurierte maximale Größe des Datenspeichers begrenzt. Zusätzlich zu diesem Speicher teilt Azure SQL-Datenbank automatisch 30 Prozent mehr Speicher für das Transaktionsprotokoll zu.
  • Azure SQL-Datenbank ordnet für die tempdb-Datenbank automatisch 32 GB pro virtuellem Kern zu. tempdb befindet sich in allen Dienstebenen auf einem lokalen SSD-Datenträger.
  • Der Preis für Speicher für eine Einzeldatenbank oder einen Pool für elastische Datenbanken errechnet sich aus der Summe des Datenspeichers und des Transaktionsprotokollspeichers multipliziert mit dem Speichereinheitenpreis für die Dienstebene. Die Kosten für die tempdb-Datenbank sind im Preis enthalten. Ausführliche Informationen zu den Speicherpreisen finden Sie unter Preise für Azure SQL-Datenbank .

Wichtig

Unter bestimmten Umständen müssen Sie ggf. eine Datenbank verkleinern, um ungenutzten Speicherplatz freizugeben. Weitere Informationen finden Sie unter Verwalten von Dateispeicherplatz in Azure SQL-Datenbank.

DTU-basiertes Kaufmodell

  • Der DTU-Preis für eine einzelne Datenbank enthält eine bestimmte Menge Speicher ohne zusätzliche Kosten. Zusätzlicher Speicher über die inbegriffene Speichermenge hinaus kann gegen zusätzliche Gebühren bis zur Obergrenze in Inkrementen von 250 GB bis zu 1 TB und dann in Inkrementen von 256 GB über 1 TB hinaus bereitgestellt werden. Informationen zu enthaltenen Speichermengen und Maximalgrößen finden Sie unter Einzeldatenbank: Speicher- und Computegrößen.
  • Zusätzlicher Speicher für eine Einzeldatenbank kann durch Erhöhen der maximalen Größe über das Azure-Portal, Transact-SQL, PowerShell, die Azure CLI oder die REST-API bereitgestellt werden.
  • Der Preis für zusätzlichen Speicher für eine Einzeldatenbank errechnet sich aus der Menge an zusätzlich bereitgestelltem Speicher multipliziert mit dem Einheitenpreis für zusätzlichen Speicher für die Dienstebene. Ausführliche Informationen zu den Preisen für zusätzlichen Speicherplatz finden Sie unter Preise für Azure SQL-Datenbank.

Wichtig

Unter bestimmten Umständen müssen Sie ggf. eine Datenbank verkleinern, um ungenutzten Speicherplatz freizugeben. Weitere Informationen finden Sie unter Verwalten von Dateispeicherplatz in Azure SQL-Datenbank.

Georeplizierte Datenbank

Zum Ändern der Datenbankgröße einer replizierten sekundären Datenbank ändern Sie die Größe der primären Datenbank. Diese Änderung wird dann auch in der sekundären Datenbank repliziert und implementiert.

Einschränkungen von P11 und P15, wenn die maximale Größe 1 TB übersteigt

In allen Regionen außer den folgenden ist im Premium-Tarif derzeit mehr als 1 TB Speicher verfügbar: China, Osten; China, Norden; Deutschland, Mitte; Deutschland, Nordosten. In diesen Regionen ist der Speicher im Tarif „Premium“ auf 1 TB begrenzt. Die folgenden Aspekte und Einschränkungen gelten für P11- und P15-Datenbanken mit einer maximalen Größe von mehr als 1 TB:

  • Wenn die maximale Größe einer P11- oder P15-Datenbank jemals auf einen Wert über 1 TB festgelegt wurde, kann sie nur in einer P11- oder P15-Datenbank wiederhergestellt oder kopiert werden. Die Datenbank kann folglich auf eine andere Computegröße skaliert werden, sofern der zugewiesene Speicherplatz zum Zeitpunkt der Neuskalierung nicht die maximalen Grenzwerte der neuen Computegröße überschreitet.
  • Szenarien für aktive Georeplikation:
    • Einrichten einer Georeplikationsbeziehung: Wenn es sich bei der primären Datenbank um eine P11- oder P15-Datenbank handelt, müssen auch sekundäre P11- oder P15-Datenbanken verwendet werden. Geringere Computegrößen werden als sekundäre Datenbanken abgelehnt, weil sie nicht mehr als 1 TB unterstützen können.
    • Aktualisieren der primären Datenbank in einer Georeplikationsbeziehung: Die Änderung der maximalen Größe für eine primäre Datenbank in mehr als 1 TB löst die gleiche Änderung für die sekundäre Datenbank aus. Beide Upgrades müssen erfolgreich ausgeführt werden, damit die Änderung für die primäre Datenbank wirksam wird. Für die Option mit mehr als 1 TB gelten Regionseinschränkungen. Wenn sich die sekundäre Datenbank in einer Region befindet, die nicht mehr als 1 TB unterstützt, wird die primäre Datenbank nicht aktualisiert.
  • Die Verwendung des Import/Export-Diensts zum Laden von P11-/P15-Datenbanken mit mehr als 1 TB wird nicht unterstützt. Verwenden Sie „SqlPackage.exe“, um Daten zu importieren und exportieren.

Nächste Schritte

Allgemeine Ressourcengrenzwerte finden Sie unter Ressourcenlimits für Singletons mit dem auf virtuellen Kernen (V-Kernen) basierenden Kaufmodell und unter Ressourcengrenzwerte für Einzeldatenbanken, die das DTU-Kaufmodell verwenden: Azure SQL-Datenbank.