Verwalten einer Hyperscale-Datenbank

Artikel
09/12/2024

Die Hyperscale-Dienstebene bietet eine hochgradig skalierbare Speicher- und Computeleistungsstufe, mit der die Speicher- und Computeressourcen für eine Azure SQL-Datenbank-Instanz mithilfe der Azure-Architektur weit über die Grenzen der Dienstebenen „Universell“ und „Unternehmenskritisch“ hinaus aufskaliert werden können. In diesem Artikel wird beschrieben, wie grundlegende Verwaltungsaufgaben für Hyperscale-Datenbanken durchgeführt werden, einschließlich der Migration einer vorhandenen Datenbank zu Hyperscale, der Wiederherstellung einer Hyperscale-Datenbank in einer anderen Region, der umgekehrten Migration von Hyperscale zu einer anderen Dienstebene und der Überwachung des Status aktueller und kürzlich durchgeführter Vorgänge mit einer Hyperscale-Datenbank.

Erfahren Sie, wie Sie eine neue Hyperscale-Datenbank erstellen: Schnellstart: Erstellen einer Hyperscale-Datenbank in Azure SQL-Datenbank.

Tipp

Vereinfachte Preise für SQL-Datenbank Hyperscale im Dezember 2023. Ausführlichere Informationen dazu finden Sie im Hyperscale-Preisblog.

Migrieren einer vorhandenen Datenbank zu Hyperscale

Sie können vorhandene Datenbanken in Azure SQL-Datenbank über das Azure-Portal, die Azure CLI, PowerShell oder Transact-SQL zu Hyperscale migrieren.

Die Zeit zum Verschieben einer vorhandenen Datenbank zu Hyperscale umfasst die Zeit zum Kopieren der Daten und die Zeit zum Wiedergeben der Änderungen, die beim Kopieren von Daten in der Quelldatenbank vorgenommen wurden. Die Zeit für das Kopieren der Daten verhält sich proportional zur Datenmenge. Es wird empfohlen, die Migration zu Hyperscale in einem Zeitraum mit geringerer Schreibaktivität durchzuführen, damit die Zeit für die Wiedergabe der aufgelaufenen Änderungen kürzer ist.

Während der endgültigen Umstellung auf die Dienstebene „Hyperscale“ kommt es nur zu einer kurzen Ausfallzeit, die in der Regel nur wenige Minuten dauert.

Voraussetzungen

Um eine Datenbank, die Teil einer Georeplikationsbeziehung ist, entweder als primäres oder als sekundäres Replikat zu Hyperscale zu verschieben, müssen Sie zunächst die Datenreplikation zwischen dem primären und dem sekundären Replikat beenden. Datenbanken in einer Failovergruppe müssen zuerst aus der Gruppe entfernt werden.

Nachdem eine Datenbank nach Hyperscale verschoben wurde, können Sie ein neues Hyperscale-Georeplikat für diese Datenbank erstellen.

Direkte Migration von der Standarddienstebene zur Hyperscale-Dienstebene wird nicht unterstützt. Um diese Migration durchzuführen, ändern Sie zuerst die Datenbank in eine andere Dienstebene als „Basic“ (z. B. „Allgemein“) und fahren Sie dann mit der Migration zu Hyperscale fort.

Migrieren einer Datenbank zur Hyperscale-Dienstebene

Um eine vorhandene Datenbank in Azure SQL-Datenbank zur Hyperscale-Dienstebene zu migrieren, identifizieren Sie zuerst Ihr Dienstziel. Ziehen Sie Ressourcengrenzen für einzelne Datenbanken zu Rate, wenn Sie nicht sicher sind, welches Dienstziel für Ihre Datenbank geeignet ist. In vielen Fällen können Sie ein Dienstziel mit derselben Anzahl von virtuellen Kernen und derselben Hardwaregeneration wie die ursprüngliche Datenbank auswählen. Bei Bedarf können Sie das Dienstziel ändern. Dies führt nur zu einer minimalen Ausfallzeit.

Wählen Sie die Registerkarte für Ihr bevorzugtes Tool aus, um Ihre Datenbank zu migrieren:

Mit dem Azure-Portal können Sie zur Hyperscale-Dienstebene migrieren, indem Sie den Tarif für Ihre Datenbank ändern.

Navigieren Sie zur Datenbank, die Sie im Azure-Portal migrieren möchten.
Wählen Sie in der linken Navigationsleiste Compute und Speicher aus.
Wählen Sie die Dropdownliste Dienstebene aus, um die Optionen für Dienstebenen zu erweitern.
Wählen Sie Hyperscale (skalierbarer Speicher nach Bedarf) im Dropdownlistenmenü aus.
Überprüfen Sie die Liste Hardwarekonfiguration. Wählen Sie, falls gewünscht, Konfiguration ändern aus, um die geeignete Hardwarekonfiguration für Ihre Workloads auszuwählen.
Wählen Sie den vCores-Schieberegler aus, wenn Sie die Anzahl der für Ihre Datenbank unter der Hyperscale-Dienstebene verfügbaren virtuellen Kerne ändern möchten.
Wählen Sie den Schieberegler High-AvailabilitySecondaryReplicas aus, wenn Sie die Anzahl der Replikate unter der Hyperscale-Dienstebene ändern möchten.
Wählen Sie Übernehmen.

Sie können Vorgänge für eine Hyperscale-Datenbank überwachen, während der Vorgang ausgeführt wird.

In diesem Codebeispiel wird az sql db update aufgerufen, um eine vorhandene Datenbank in Azure SQL-Datenbank zur Hyperscale-Dienstebene zu migrieren. Sie müssen sowohl die Edition als auch das Dienstziel angeben.

Ersetzen Sie resourceGroupName, serverName, databaseName und serviceObjective durch die entsprechenden Werte, bevor Sie das folgende Codebeispiel ausführen:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="HS_Gen5_2"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition Hyperscale --service-objective $serviceObjective

Sie können Vorgänge für eine Hyperscale-Datenbank überwachen, während der Vorgang ausgeführt wird.

Im folgenden Beispiel wird das Cmdlet Set-AzSqlDatabase verwendet, um eine vorhandene Datenbank in Azure SQL-Datenbank zur Hyperscale-Dienstebene zu migrieren. Sie müssen sowohl die Edition als auch das Dienstziel angeben.

Ersetzen Sie $resourceGroupName, $serverName, $databaseName und $serviceObjective durch die entsprechenden Werte, bevor Sie dieses Codebeispiel ausführen:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "HS_Gen5_2"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "Hyperscale" `
    -RequestedServiceObjectiveName $serviceObjective

Sie können Vorgänge für eine Hyperscale-Datenbank überwachen, während der Vorgang ausgeführt wird.

Um eine vorhandene Datenbank in Azure SQL-Datenbank zur Hyperscale-Dienstebene mit Transact-SQL zu migrieren, stellen Sie zunächst eine Verbindung mit der master-Datenbank auf Ihrem logischen SQL-Server mit dem Abfrage-Editor im Azure-Portal für Azure SQL-Datenbank, SQL Server Management Studio (SSMS) oder Azure Data Studio her.

Sie müssen sowohl die Edition als auch das Dienstziel in der ALTER DATABASE-Anweisung angeben.

In dieser Beispielausweisung wird eine Datenbank namens mySampleDatabase zur Hyperscale-Dienstebene mit dem Dienstziel HS_Gen5_2 migriert. Ersetzen Sie den Datenbanknamen durch den entsprechenden Wert, bevor Sie die Anweisung ausführen.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_2');
GO

Sie können Vorgänge für eine Hyperscale-Datenbank überwachen, während der Vorgang ausgeführt wird.

Umgekehrte Migration aus Hyperscale

Umgekehrte Migration zur Dienstebene „Universell“ ermöglicht es Kunden, die vor kurzem eine vorhandene Datenbank in Azure SQL-Datenbank zur Dienstebene „Hyperscale“ migriert haben, im Notfall wieder dorthin zurückzukehren, falls Hyperscale ihre Anforderungen nicht erfüllt. Während die umgekehrte Migration durch eine Änderung der Dienstebene eingeleitet wird, handelt es sich im Wesentlichen um eine Verschiebung der Datengröße zwischen verschiedenen Architekturen.

Einschränkungen für die umgekehrte Migration

Umgekehrte Migration ist unter den folgenden Bedingungen verfügbar:

Umgekehrte Migration ist nur innerhalb von 45 Tagen nach der ursprünglichen Migration zu Hyperscale verfügbar.
Datenbanken, die ursprünglich mit der Dienstebene „Hyperscale“ erstellt wurden, sind von der umgekehrten Migration ausgeschlossen.
Sie können umgekehrte Migration nur zur Dienstebene Universell ausführen. Ihre Migration aus „Hyperscale“ zu „Universell“ kann entweder auf die serverlosen oder bereitgestellten Computeebenen abzielen. Wenn Sie die Datenbank zu einer anderen Dienstebene migrieren möchten, z. B. zu Unternehmenskritisch oder zu einer DTU-basierten Dienstebene, führen Sie zunächst eine umgekehrte Migration zur Dienstebene „Universell“ aus, und ändern Sie dann die Dienstebene.
Die umgekehrte Migration zu Datenbanken mit weniger als zwei virtuellen Kernen wird nicht unterstützt. Sie können die Datenbank nach Abschluss der Migration auf weniger als zwei virtuelle Kerne herunterskalieren.
Die direkte umgekehrte Migration von oder zu einem Pool für elastische Datenbanken wird nicht unterstützt. Sie können die Migration eines Singletons nur von „Hyperscale“ zu „Universell“ rückgängig machen.
- Wenn die Hyperscale-Datenbank Teil eines Hyperscale-Pools für elastische Datenbanken ist, müssen Sie sie vor der umgekehrten Migration zunächst aus dem Hyperscale-Pool für elastische Datenbanken entfernen.
- Nach Abschluss der umgekehrten Migration können Sie bei Bedarf den Singleton mit der Dienstebene „Universell“ einem Pool für elastische Datenbanken der Dienstebene „Universell“ hinzufügen.
Für Datenbanken, die nicht für die umgekehrte Migration in Frage kommen, besteht die einzige Möglichkeit der Migration von Hyperscale zu einer anderen Dienstebene im Export/Import mithilfe einer Bacpac-Datei oder anderer Datenverschiebungstechnologien (Massenkopieren, Azure Data Factory, Azure Databricks, SSIS usw.). Der Bacpac-Export/Import über das Azure-Portal, über PowerShell mit New-AzSqlDatabaseExport oder New-AzSqlDatabaseImport, über die Azure CLI mit az sql db export und az sql db import und über die REST-API wird nicht unterstützt. Der BACPAC-Import/-Export für kleinere Hyperscale-Datenbanken (bis zu 200 GB) wird über SSMS und SqlPackage Version 18.4 und höher unterstützt. Bei größeren Datenbanken kann der BACPAC-Export/-Import sehr lange dauern und aus verschiedenen Gründen gegebenenfalls zu Fehlern führen.

Dauer und Ausfallzeit

Im Gegensatz zu regulären Vorgängen zur Änderung von Zielen der Dienstebene in Hyperscale handelt es sich bei der Migration zu Hyperscale und der umgekehrten Migration zu „Universell“ um Vorgänge, die sich auf die Datengröße beziehen.

Die Dauer einer umgekehrten Migration hängt hauptsächlich von der Größe der Datenbank und den gleichzeitigen Schreibaktivitäten während der Migration ab. Die Anzahl der virtuellen Kerne, die Sie der Zieldatenbank auf Dienstebene „Universell“ zuweisen, wirkt sich auch auf die Dauer der umgekehrten Migration aus. Es wird empfohlen, die Zieldatenbank mit der Dienstebene „Universell“ mit einer Anzahl von virtuellen Kernen größer oder gleich der Anzahl von virtuellen Kernen bereitzustellen, die der Quelldatenbank der Dienstebene „Hyperscale“ zugewiesen sind, um ähnliche Workloads zu unterstützen.

Während der umgekehrten Migration kann es bei der Hyperscale-Quelldatenbank zu Leistungseinbußen kommen, wenn sie stark ausgelastet wird. Insbesondere kann die Transaktionsprotokollrate reduziert (gedrosselt) werden, um sicherzustellen, dass die umgekehrte Migration Fortschritte macht.

Während der endgültigen Umstellung auf die neue Zieldatenbank auf der Dienstebene „Universell“ kommt es nur zu einer kurzen Ausfallzeit, die in der Regel nur wenige Minuten beträgt.

Voraussetzungen

Bevor Sie eine umgekehrte Migration aus Hyperscale zur Dienstebene „Universell“ einleiten, müssen Sie sicherstellen, dass Ihre Datenbank die Einschränkungen für umgekehrte Migration und Folgendes erfüllt:

Für Ihre Datenbank ist keine Georeplikation aktiviert.
Ihre Datenbank verfügt nicht über benannte Replikate.
Ihre Datenbank (zugewiesene Größe) ist klein genug, um in die Zieldienstebene zu passen.
Wenn Sie die maximale Datenbankgröße für die Zieldatenbank „Universell“ angeben, stellen Sie sicher, dass die zugewiesene Größe der Datenbank klein genug ist, um in diese maximale Größe zu passen.

Die erforderlichen Überprüfungen erfolgen vor dem Start der umgekehrten Migration. Wenn bestimmte Voraussetzungen nicht erfüllt sind, löst die umgekehrte Migration sofort einen Fehler aus.

Sicherungsrichtlinien

Für alle vorhandenen Datenbanksicherungen innerhalb des konfigurierten Aufbewahrungszeitraums werden Ihnen die regulären Preise in Rechnung gestellt. Die Hyperscale-Momentaufnahmen im Sicherungsspeicher und die Datengrößen-Speicherblobs, die für die Wiederherstellung der Sicherung aufbewahrt werden müssen, werden Ihnen in Rechnung gestellt.

Sie können eine Datenbank zu Hyperscale migrieren und mehrmals eine umgekehrte Migration zu „Universell“ ausführen. Nur Sicherungen der aktuellen und der vorhergehenden Ebene Ihrer Datenbank sind für die Wiederherstellung verfügbar. Wenn Sie aus der Dienstebene „Universell“ zu „Hyperscale“ und dann zurück zu „Universell“ gewechselt sind, sind die nur Sicherungen aus der aktuellen Datenbank mit der Dienstebene „Universell“ und der unmittelbar vorhergehenden Hyperscale-Datenbank verfügbar. Diese aufbewahrten Sicherungen werden gemäß der Azure SQL-Datenbank-Abrechnung abgerechnet. Für alle vorherigen Ebenen, die Sie ausprobieren, sind keine Sicherungskopien verfügbar, und sie werden nicht in Rechnung gestellt.

Sie können z. B. zwischen Hyperscale- und Nicht-Hyperscale-Dienstebenen migrieren:

Universell
Migrieren zu „Hyperscale“
Umgekehrte Migration zu „Universell“
Änderung der Dienstebene in „Unternehmenskritisch“
Migrieren zu „Hyperscale“
Umgekehrte Migration zu „Universell“

In diesem Fall wären nur die Sicherungen aus den Schritten 5 und 6 der Zeitachse verfügbar, wenn sie noch innerhalb des konfigurierten Aufbewahrungszeitraums liegen. Alle Sicherungen aus früheren Schritten sind nicht verfügbar. Berücksichtigen Sie sorgfältig die Verfügbarkeit von Backups, wenn Sie versuchen, dieselbe Datenbank wiederholt zwischen den Dienstebenen „Hyperscale“ und „Universell“ zu migrieren. Backups von Datenbanken, die älter sind als die unmittelbar vorhergehende Datenbank, sind nicht mehr verfügbar, sobald eine Rückwärtsmigration gestartet wird, und bleiben auch dann nicht verfügbar, wenn die Migration abgebrochen wird.

Umgekehrte Migration einer Hyperscale-Datenbank zur Dienstebene „Universell“

Um eine umgekehrte Migration einer vorhandenen Hyperscale-Datenbank in Azure SQL-Datenbank zur Dienstebene „Universell“ vorzunehmen, müssen Sie zunächst Ihr Dienstziel auf der Dienstebene „Universell“ identifizieren und angeben, ob Sie zur bereitgestellten oder serverlosen Computeebene migrieren möchten. Ziehen Sie Ressourcengrenzen für einzelne Datenbanken zu Rate, wenn Sie nicht sicher sind, welches Dienstziel für Ihre Datenbank geeignet ist.

Wenn Sie nach der umgekehrten Migration zu „Universell“ eine weitere Änderung der Dienstebene vornehmen möchten, ermitteln Sie auch Ihr mögliches Dienstziel, und stellen Sie sicher, dass die zugewiesene Größe Ihrer Datenbank klein genug ist, um in dieses Dienstziel zu passen.

Wählen Sie die Registerkarte für Ihre bevorzugte Methode aus, um eine umgekehrte Migration Ihrer Datenbank auszuführen:

Das Azure-Portal ermöglicht Ihnen eine umgekehrte Migration zur Dienstebene „Universell“, indem Sie den Tarif für Ihre Datenbank ändern.

Navigieren Sie zur Datenbank, die Sie im Azure-Portal migrieren möchten.
Wählen Sie in der linken Navigationsleiste Compute und Speicher aus.
Wählen Sie die Dropdownliste Dienstebene aus, um die Optionen für Dienstebenen zu erweitern.
Wählen Sie im Dropdownlistenmenü Universell (skalierbare Compute- und Speicheroptionen) aus.
Überprüfen Sie die Liste Hardwarekonfiguration. Wählen Sie, falls gewünscht, Konfiguration ändern aus, um die geeignete Hardwarekonfiguration für Ihre Workloads auszuwählen.
Wählen Sie den vCores-Schieberegler aus, wenn Sie die Anzahl der für Ihre Datenbank unter der Dienstebene „Universell“ verfügbaren virtuellen Kerne ändern möchten.
Wählen Sie Übernehmen.

In diesem Codebeispiel wird az sql db update aufgerufen, um eine umgekehrte Migration einer vorhandenen Hyperscale-Datenbank zur Dienstebene „Universell“auszuführen. Sie müssen sowohl die Edition als auch das Dienstziel angeben. Sie können Provisioned oder Serverless für das Computezielmodell auswählen.

Ersetzen Sie resourceGroupName, serverName, databaseName und serviceObjective durch die entsprechenden Werte, bevor Sie das folgende Codebeispiel ausführen:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel

Sie können optional das maxsize-Argument einschließen. Wenn der maxsize-Wert die maximal zulässige Größe für das Dienstziel überschreitet, wird ein Fehler zurückgegeben. Wenn das maxsize-Argument nicht angegeben wird, wird der Vorgang standardmäßig auf die maximale Größe festgelegt, die für das angegebene Dienstziel verfügbar ist. Im folgenden Beispiel wird maxsize angegeben:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"
maxsize="200GB"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel --max-size $maxsize

Sie können Vorgänge für eine Hyperscale-Datenbank überwachen, während der Vorgang ausgeführt wird.

In diesem Codebeispiel wird das Cmdlet Set-AzSqlDatabase verwendet, um eine vorhandene Datenbank aus der Hyperscale-Dienstebene zur Dienstebene „Universell“ zu migrieren. Sie müssen sowohl die Edition als auch das Dienstziel angeben. Sie können Provisioned oder Serverless für die Computezielebene auswählen.

Ersetzen Sie $resourceGroupName, $serverName, $databaseName, $serviceObjective und $computeModel durch die entsprechenden Werte, bevor Sie dieses Codebeispiel ausführen:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"
$maxSizeBytes = "268435456000"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective -MaxSizeBytes $maxSizeBytes

Sie können Vorgänge für eine Hyperscale-Datenbank überwachen, während der Vorgang ausgeführt wird.

Um eine umgekehrte Migration einer Hyperscale-Datenbank zur Dienstebene „Universell“ mit Transact-SQL durchzuführen, stellen Sie zunächst eine Verbindung mit der master-Datenbank auf Ihrem logischen SQL-Server mit SQL Server Management Studio (SSMS) oder Azure Data Studio her.

Sie müssen sowohl die Edition als auch das Dienstziel in der ALTER DATABASE-Anweisung angeben.

In dieser Beispielausweisung wird eine Datenbank namens mySampleDatabase zur Dienstebene „Universell“ mit dem Dienstziel GP_Gen5_4 migriert. Ersetzen Sie den Datenbanknamen und das Dienstziel durch die entsprechenden Werte, bevor Sie die Anweisung ausführen.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2');
GO

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2', MAXSIZE = 200 GB);
GO

Sie können Vorgänge für eine Hyperscale-Datenbank überwachen, während der Vorgang ausgeführt wird.

Überwachen von Vorgängen für eine Hyperscale-Datenbank

Sie können den Status aktueller oder kürzlich abgeschlossener Vorgänge für eine Azure SQL-Datenbank über das Azure-Portal, mit der Azure CLI, mit PowerShell oder mit Transact-SQL überwachen.

Wählen Sie die Registerkarte für ihre bevorzugte Methode aus, um Vorgänge zu überwachen.

Das Azure-Portal zeigt eine Benachrichtigung für eine Datenbank in Azure SQL-Datenbank an, wenn ein Vorgang wie eine Migration, umgekehrte Migration oder Wiederherstellung aktuell ausgeführt wird.

Navigieren zur Datenbank im Azure-Portal.
Klicken Sie in der linken Navigationsleiste auf Übersicht.
Überprüfen Sie den Abschnitt Benachrichtigungen unten im rechten Bereich. Wenn aktuell Vorgänge ausgeführt werden, wird ein Benachrichtigungsfeld angezeigt.
Wählen Sie das Benachrichtigungsfeld aus, um Details anzuzeigen.
Der Bereich Laufende Vorgänge wird geöffnet. Überprüfen Sie die Details der laufenden Vorgänge.

In diesem Codebeispiel wird az sql db op list aufgerufen, um aktuelle oder laufende Vorgänge für eine Datenbank in Azure SQL-Datenbank zurückzugeben.

Ersetzen Sie resourceGroupName, serverName, databaseName und serviceObjective durch die entsprechenden Werte, bevor Sie das folgende Codebeispiel ausführen:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"

az sql db op list -g $resourceGroupName -s $serverName --database $databaseName

Das Cmdlet az sql db op list gibt aktuelle oder laufende Vorgänge für eine Datenbank in Azure SQL-Datenbank zurück.

Legen Sie die $resourceGroupName-, $serverName- und $databaseName-Parameter auf die entsprechenden Werte für Ihre Datenbank fest, bevor Sie den Beispielcode ausführen:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"

Get-AzSqlDatabaseActivity -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName

Um Vorgänge für eine Hyperscale-Datenbank zu überwachen, stellen Sie zunächst eine Verbindung mit der master-Datenbank auf Ihrem logischen Server her, indem Sie SQL Server Management Studio (SSMS), Azure Data Studio oder den Client Ihrer Wahl verwenden, um Transact-SQL-Befehle auszuführen.

Fragen Sie die dynamische Verwaltungsansicht sys.dm_operation_status ab, um Informationen zu den zuletzt ausgeführten Vorgängen in Datenbanken auf Ihrem [logischen Server](logical-servers.md] zu überprüfen.

Dieses Codebeispiel gibt alle Einträge in sys.dm_operation_status für die angegebene Datenbank zurück, sortiert nach den zuletzt begonnenen Vorgängen. Ersetzen Sie den Datenbanknamen durch den entsprechenden Wert, bevor Sie das Codebeispiel ausführen.

SELECT *
FROM sys.dm_operation_status
WHERE major_resource_id = 'mySampleDatabase'
ORDER BY start_time DESC;
GO

Anzeigen von Datenbanken in der Hyperscale-Dienstebene

Nachdem Sie eine Datenbank zu Hyperscale migriert oder eine Datenbank innerhalb der Hyperscale-Dienstebene neu konfiguriert haben, möchten Sie die Konfiguration Ihrer Hyperscale-Datenbank möglicherweise anzeigen und/oder dokumentieren.

Das Azure-Portal zeigt eine Liste aller Datenbanken auf einem logischen Server an. Die Spalte Tarif enthält die Dienstebene für jede Datenbank.

Navigieren Sie im Azure-Portal zu Ihrem logischen Server.
Klicken Sie in der linken Navigationsleiste auf Übersicht.
Scrollen Sie zur Liste der Ressourcen am unteren Rand des Bereichs. Im Fenster werden Pools für elastische SQL-Datenbanken und Datenbanken auf dem logischen Server angezeigt.
Überprüfen Sie die Spalte Tarif, um Datenbanken in der Hyperscale-Dienstebene zu identifizieren.

In diesem Azure CLI-Codebeispiel wird az sql db list aufgerufen, um Hyperscale-Datenbanken auf einem logischen Server mit ihrem Namen, Speicherort, Dienstebenenziel, ihrer maximalen Größe und der Anzahl der Replikate mit Hochverfügbarkeit aufzuführen.

Ersetzen Sie resourceGroupName und serverName durch die entsprechenden Werte, bevor Sie das folgende Codebeispiel ausführen:

resourceGroupName="myResourceGroup"
serverName="server01"

az sql db list -g $resourceGroupName -s $serverName --query "[].{Name:name, Location:location, SLO:currentServiceObjectiveName, Tier:currentSku.tier, maxSizeBytes:maxSizeBytes,HAreplicas:highAvailabilityReplicaCount}[?Tier=='Hyperscale']" --output table

Das Azure PowerShell-Cmdlet Get-AzSqlDatabase gibt eine Liste der Hyperscale-Datenbanken auf einem logischen Server mit Name, Speicherort, Dienstebenenziel, maximaler Größe und Anzahl der Hochverfügbarkeitsreplikate zurück.

Legen Sie die $resourceGroupName- und $serverName- Parameter auf die entsprechenden Werte fest, bevor Sie den Beispielcode ausführen:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"

Get-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName | `
    Where-Object { $_.Edition -eq 'Hyperscale' } | `
        Select-Object DatabaseName, Location, currentServiceObjectiveName, Edition, `
        MaxSizeBytes, HighAvailabilityReplicaCount | `
            Format-Table

Überprüfen Sie die Spalte Edition, um Datenbanken in der Hyperscale-Dienstebene zu identifizieren.

Um die Dienstebenen aller Hyperscale-Datenbanken auf einem logischen Server mit Transact-SQL zu überprüfen, stellen Sie zunächst eine Verbindung mit der master-Datenbank mithilfe von SQL Server Management Studio (SSMS) oder Azure Data Studio her.

Fragen Sie die Systemkatalogansicht sys.database_service_objectives ab, um Datenbanken in der Hyperscale-Dienstebene zu überprüfen:

SELECT d.name, dso.edition, dso.service_objective
FROM sys.database_service_objectives AS dso
JOIN sys.databases as d on dso.database_id = d.database_id
WHERE dso.edition = 'Hyperscale';
GO

Weitere Informationen zu Hyperscale-Datenbanken finden Sie in den folgenden Artikeln:

Freigeben über

Verwalten einer Hyperscale-Datenbank

Migrieren einer vorhandenen Datenbank zu Hyperscale

Voraussetzungen

Migrieren einer Datenbank zur Hyperscale-Dienstebene

Umgekehrte Migration aus Hyperscale

Einschränkungen für die umgekehrte Migration

Dauer und Ausfallzeit

Voraussetzungen

Sicherungsrichtlinien

Umgekehrte Migration einer Hyperscale-Datenbank zur Dienstebene „Universell“

Überwachen von Vorgängen für eine Hyperscale-Datenbank

Anzeigen von Datenbanken in der Hyperscale-Dienstebene

Feedback

Zusätzliche Ressourcen

Freigeben über

Verwalten einer Hyperscale-Datenbank

Migrieren einer vorhandenen Datenbank zu Hyperscale

Voraussetzungen

Migrieren einer Datenbank zur Hyperscale-Dienstebene

Umgekehrte Migration aus Hyperscale

Einschränkungen für die umgekehrte Migration

Dauer und Ausfallzeit

Voraussetzungen

Sicherungsrichtlinien

Umgekehrte Migration einer Hyperscale-Datenbank zur Dienstebene „Universell“

Überwachen von Vorgängen für eine Hyperscale-Datenbank

Anzeigen von Datenbanken in der Hyperscale-Dienstebene

Zugehöriger Inhalt

Feedback

Zusätzliche Ressourcen