Wartungsfenster in Azure SQL-Datenbank
Gilt für: 
Azure SQL-Datenbank
Die Funktion „Wartungsfenster“ ermöglicht Ihnen das Konfigurieren von Wartungszeitplänen für Ressourcen in Azure SQL-Datenbank und Azure SQL Managed Instance, sodass beeinträchtigende Wartungsereignisse vorhersehbar werden und weniger störend für Ihre Workloads sind.
Hinweis
Das Wartungsfensterfeature schützt nur vor geplanten Auswirkungen von Upgrades oder geplanten Wartungen. Es schützt jedoch nicht vor allen Failover-Ursachen, also Ausnahmen, die außerhalb eines Wartungsfensters zu kurzen Verbindungsunterbrechungen führen könnten, einschließlich Hardwarefehlern, Clusterlastenausgleichen und Neukonfigurationen von Datenbanken aufgrund von Ereignissen wie einer Änderung des Service-Levelziels der Datenbank.
Vorabbenachrichtigungen sind für Datenbanken verfügbar, für die kein standardmäßiges Wartungsfenster konfiguriert ist. Vorabbenachrichtigungen bieten dem Kunden die Möglichkeit, Benachrichtigungen so zu konfigurieren, dass sie bis zu 24 Stunden vor einem geplanten Ereignis gesendet werden.
Übersicht
Azure führt regelmäßig eine geplante Wartung von Ressourcen in SQL-Datenbank durch. Während eines Wartungsereignisses sind Datenbanken voll verfügbar, können aber im Rahmen der Verfügbarkeits-Vereinbarung zum Service Level (SLA) für SQL-Datenbank kurzzeitig rekonfiguriert werden.
Das Wartungsfenster ist für Produktionsworkloads vorgesehen, die gegenüber Neukonfigurationen von Datenbanken nicht resilient sind und keine kurzen Verbindungsunterbrechungen durch geplante Wartungsereignisse auffangen können. Durch die Wahl eines von Ihnen bevorzugten Wartungsfensters können Sie die Auswirkungen geplanter Wartung minimieren, indem Sie sie außerhalb Ihrer Hauptgeschäftszeiten einplanen. Stabile Workloads und Nicht-Produktions-Workloads sind möglicherweise von der Azure SQL-Standardwartungsrichtlinie abhängig.
Das Wartungsfenster ist kostenlos und kann bei der Erstellung oder für vorhandene Ressourcen konfiguriert werden. Sie kann über das Azure-Portal, PowerShell, CLI oder Azure-API konfiguriert werden.
Wichtig
Das Konfigurieren des Wartungsfensters ist ein zeitintensiver, asynchroner Vorgang, ähnlich dem Ändern der Dienstebene der Azure SQL-Ressource. Die Ressource bleibt während des Vorgangs verfügbar – mit Ausnahme einer kurzen Neukonfiguration, die am Ende des Vorgangs erfolgt und normalerweise etwa 8 Sekunden dauert (auch bei unterbrochenen zeitintensiven Transaktionen). Wenn Sie die Auswirkungen der Neukonfiguration minimieren möchten, sollten Sie den Vorgang außerhalb der Spitzenzeiten durchführen.
Mehr Vorhersehbarkeit bei Wartungsfenstern
Die meisten bedeutsamen Updates werden durch die Azure SQL-Wartungsrichtlinie standardmäßig täglich zwischen 8 und 17 Uhr Ortszeit blockiert, um Unterbrechungen während der normalen Hauptgeschäftszeiten zu vermeiden. Die Ortszeit wird durch die Azure-Region bestimmt, in der die Ressource gehostet wird, und die Sommerzeit könnte gemäß der Definition der lokalen Zeitzone berücksichtigt werden.
Während der Wartung bleiben die Datenbanken verfügbar, aber einige Aktualisierungen können einen Failover erfordern. Das Standard-Wartungsfenster des Systems (17.00 bis 8.00 Uhr) beschränkt die meisten Aktivitäten auf diese Zeit, dringende Updates können jedoch auch außerhalb dieses Zeitfensters erfolgen. Um sicherzustellen, dass alle Aktualisierungen nur während des Wartungsfensters erfolgen, wählen Sie eine andere als die Standardoption.
Sie können Fenster für Wartungsupdates weiter auf eine für Ihre Azure SQL-Ressourcen geeignete Zeit anpassen, indem Sie zwischen zwei nicht standardmäßigen Wartungsfenstern wählen:
- Wartungsfenster Wochentag: 22 Uhr bis 6 Uhr Ortszeit, Montag bis Donnerstag
- Wartungsfenster Wochenende: 22 Uhr bis 6 Uhr Ortszeit, Freitag bis Sonntag
In den aufgelisteten Tagen des Wartungsfensters wird der Starttag jedes achtstündigen Wartungsfensters angegeben. „22:00 Uhr bis 6:00 Uhr Ortszeit, Montag bis Donnerstag“ bedeutet beispielsweise, dass die Wartungsfenster an jedem Tag (Montag bis Donnerstag) um 22:00 Uhr Ortszeit beginnen und am folgenden Tag (Dienstag bis Freitag) um 6:00 Uhr Ortszeit abgeschlossen sind.
Nach Auswahl des Wartungsfensters und nach Abschluss der Dienstkonfiguration werden alle geplanten Wartungen nur im von Ihnen ausgewählten Wartungsfenster ausgeführt. Wartungsereignisse werden in der Regel innerhalb eines einzelnen Fensters abgeschlossen, einige Wartungsereignisse könnten sich jedoch über zwei oder mehr angrenzende Fenster erstrecken.
Hinweis
Die Azure SQL-Datenbank folgt einer sicheren Bereitstellungsmethode, bei der Azure-Regionen garantiert nicht gleichzeitig bereitgestellt werden. Es ist jedoch nicht möglich vorherzusagen, für welche Region zuerst ein Upgrade ausgeführt wird, sodass die Reihenfolge der Bereitstellung nicht garantiert werden kann. Manchmal wird das Upgrade zuerst für Ihre primäre Datenbank, manchmal zuerst für die sekundäre Instanz durchgeführt.
- In Situationen, in denen Ihre Datenbank für die Georeplikation oder für Failovergruppen aktiviert ist und die Georeplikation nicht mit der Azure-Regionskopplung übereinstimmt, sollten Sie unterschiedliche Wartungsfensterzeitpläne für Ihre primäre und sekundäre Datenbank verwenden. Sie können beispielsweise das Wartungsfenster Werktag für Ihre sekundäre Geodatenbank und das Wartungsfenster Wochenende für Ihre primäre Geodatenbank auswählen.
Wichtig
In sehr seltenen Fällen, in denen eine Verschiebung von Aktionen zu schwerwiegenden Auswirkungen führen könnte, wie z. B. das Anwenden eines wichtigen Sicherheitspatches, könnte das konfigurierte Wartungsfenster vorübergehend außer Kraft gesetzt werden.
Vorabbenachrichtigungen
Wartungsbenachrichtigungen können konfiguriert werden, damit Sie über bevorstehende geplante Wartungsereignisse für Ihre Azure SQL-Datenbank benachrichtigt werden. Die Warnungen treffen 24 Stunden vor dem Beginn des Wartungsfensters und am Ende des Wartungsfensters ein. Weitere Informationen finden Sie unter Vorabbenachrichtigungen.
Verfügbarkeit von Funktionen
Unterstützte Subscriptiontypen
Das Konfigurieren und Verwenden des Wartungsfensters ist für die folgenden Angebotstypen verfügbar: Nutzungsbasierte Bezahlung, Cloud Solution Provider (CSP), Microsoft Enterprise Agreement oder Microsoft-Kundenvereinbarung.
Angebote, die auf die Dev/Test-Nutzung beschränkt sind, sind nicht berechtigt (z. B. Dev/Test Pay-As-You-Go oder Enterprise Dev/Test).
Hinweis
Ein Azure-Angebot ist der Typ der Azure-Subscription, die Sie besitzen. Zum Beispiel handelt es sich bei Subscriptions des Typs Nutzungsbasierte Bezahlung (Pay-As-You-Go), Azure in Open und Visual Studio Enterprise insgesamt um Azure-Angebote. Jedes Angebot bzw. jeder Plan hat unterschiedliche Vorteile und unterliegt unterschiedlichen Bestimmungen. Ihr Angebot bzw. Ihr Plan wird in der Subscriptionübersicht angezeigt. Wie Sie mit Ihrer Subscription zu einem anderen Angebot wechseln können, erfahren Sie unter Ändern Ihrer Azure-Subscription in ein anderes Angebot.
Unterstützte Servicelevelziele
Die Wahl eines anderen Wartungsfensters als des Standardfensters ist bei allen SLOs möglich, außer bei den folgenden.
- SLOs nicht unterstützt:
- Azure SQL-Datenbank DTU Basic-, S0- und S1-Ebenen
- DC-Hardware
- Fsv2-Hardware
Andere Szenarien:
- Wartungsfenster für elastische Hyperscale-Datenbanken ist in der Vorschau und ist in bestimmten Regionen und Konfigurationen verfügbar. Für weitere Informationen siehe Blog: Unterstützung für Wartungsfenster für Pools für elastische Hyperscale-Datenbanken in Azure SQL-Datenbank.
- Wartungsfenster wird für benannte Replikate unterstützt.
Probleme beim Wartungsfenster für Azure SQL-Datenbank
Das Auswählen eines Wartungsfensters für eine andere Azure SQL-Datenbank als die Standardeinstellung ist derzeit in den folgenden Regionen verfügbar, organisiert nach Einkaufsmodell.
Die folgende Tabelle richtet sich an Datenbanken, die nicht zonenredundant sind. Informationen zu Datenbanken in einer Azure-Verfügbarkeitszone finden Sie in der Tabelle für zonenredundante Datenbanken.
| Azure-Region | Hyperscale-Premium-Serie und arbeitsspeicheroptimierte Premium-Serie | Hyperscale-Standard-Serie | Kaufmodelle für Azure SQL-Datenbank und Ressourcen |
|---|---|---|---|
| Australien (Osten) | Ja | Ja | Ja |
| Australien, Südosten | Ja | Ja | |
| Brasilien Süd | Ja | Ja | |
| Brasilien, Südosten | Ja | Ja | |
| Kanada, Mitte | Ja | Ja | Ja |
| Kanada, Osten | Ja | Ja | |
| Indien, Mitte | Ja | Ja | |
| USA (Mitte) | Ja | Ja | Ja |
| China, Osten 2 | Ja | Ja | |
| China, Norden 2 | Ja | Ja | |
| US, Osten 1 | Ja | Ja | Ja |
| USA (Ost) 2 | Ja | Ja | Ja |
| Asien, Osten | Ja | Ja | |
| Frankreich, Mitte | Ja | Ja | |
| Frankreich, Süden | Ja | Ja | |
| Deutschland, Westen-Mitte | Ja | Ja | |
| Japan, Osten | Ja | Ja | Ja |
| Japan, Westen | Ja | Ja | |
| USA Nord Mitte | Ja | Ja | |
| Nordeuropa | Ja | Ja | Ja |
| Südafrika, Norden | Ja | Ja | |
| USA Süd Mitte | Ja | Ja | Ja |
| Indien (Süden) | Ja | Ja | |
| Asien, Südosten | Ja | Ja | |
| Schweiz, Norden | Ja | Ja | |
| Vereinigte Arabische Emirate, Norden | Ja | Ja | |
| UK, Süden | Ja | Ja | Ja |
| UK, Westen | Ja | Ja | |
| US Gov Texas | Ja | Ja | |
| US Government, Virginia | Ja | Ja | |
| USA, Westen-Mitte | Ja | Ja | |
| Europa, Westen | Ja | Ja | Ja |
| USA (Westen) | Ja | Ja | Ja |
| USA, Westen 2 | Ja | Ja | Ja |
| USA, Westen 3 | Ja | Ja | Ja |
Die folgende Tabelle ist für zonenredundante Datenbanken vorgesehen.
| Azure-Region | Hyperscale-Premium-Serie und arbeitsspeicheroptimierte Premium-Serie | Hyperscale-Standard-Serie | Alle anderen Azure SQL-Datenbankkaufmodelle und -Ebenen in einer Azure-Verfügbarkeitszone |
|---|---|---|---|
| Australien (Osten) | Ja | Ja | Ja |
| Kanada, Mitte | Ja | Ja | Ja |
| USA (Mitte) | Ja | Ja | Ja |
| US, Osten 1 | Ja | Ja | Ja |
| USA (Ost) 2 | Ja | ||
| Frankreich, Mitte | Ja | Ja | |
| Japan, Osten | Ja | ||
| Nordeuropa | Ja | Ja | Ja |
| USA Süd Mitte | Ja | ||
| Asien, Südosten | Ja | ||
| UK, Süden | Ja | ||
| Europa, Westen | Ja | Ja | Ja |
| USA, Westen 2 | Ja | ||
| USA, Westen 3 | Ja | Ja | Ja |
Gatewaywartung
Für die optimale Nutzung von Wartungsfenstern müssen Sie sicherstellen, dass Ihre Clientanwendungen die Verbindungsrichtlinie „Umleiten“ verwenden. Empfohlen wird die Verbindungsrichtlinie „Umleiten“, da die Clients Verbindungen direkt mit dem Knoten herstellen, der die Datenbank hostet. Dies führt zu niedrigerer Latenz und verbessertem Durchsatz.
In Azure SQL-Datenbank sind möglicherweise alle Verbindungen, die die Verbindungsrichtlinie „Proxy“ verwenden, von dem ausgewählten Wartungsfenster und einem Wartungsfenster für den Gatewayknoten betroffen. Dagegen sind Clientverbindungen, die die empfohlene Verbindungsrichtlinie „Umleiten“ verwenden, bei der Wartung des Gatewayknotens nicht von einer Neukonfiguration betroffen.
Weitere Informationen zur Clientverbindungsrichtlinie in Azure SQL-Datenbank finden Sie unter Azure SQL-Datenbank: Verbindungsrichtlinie.
Abrufen einer Liste mit Wartungsereignissen
Azure Resource Graph ist ein Azure-Dienst zum Erweitern der Azure-Ressourcenverwaltung. Der Azure Resource Graph-Explorer bietet eine effiziente, leistungsstarke Ressourcenuntersuchung mit der Fähigkeit, nach Bedarf für eine bestimmte Gruppe von Subscriptions Abfragen durchzuführen, sodass Vorgaben effektiv in Ihrer Umgebung durchgesetzt werden können.
Sie können den Azure Resource Graph-Explorer verwenden, um Wartungsereignisse abzufragen. Eine Einführung in das Ausführen dieser Abfragen finden Sie unter Schnellstart: Ausführen Ihrer ersten Resource Graph-Abfrage mithilfe des Azure Resource Graph-Explorers.
Um die Wartungsereignisse für alle SQL-Datenbanken in Ihrer Subscription zu überprüfen, verwenden Sie die folgende Beispielabfrage im Azure Resource Graph-Explorer:
servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where impactedService =~ 'SQL Database'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc
Die vollständige Referenz dieser Beispielabfragen sowie Informationen zu ihrer Verwendung mit Tools wie PowerShell oder Azure CLI finden Sie unter Azure Resource Graph-Beispielabfragen für Azure Service Health.