Freigeben über


SQL Server: Bewährte Methoden und Problembehandlung für das Sichern über URLs für Microsoft Azure Blob Storage

Gilt für: SQL Server Azure SQL Managed Instance

Dieser Artikel enthält bewährte Methoden und Tipps zur Problembehandlung im Zusammenhang mit SQL Server-Sicherungs- und -Wiederherstellungsvorgängen in Microsoft Azure Blob Storage.

Weitere Informationen zur Verwendung von Azure Blob Storage für SQL Server-Sicherungs- oder -Wiederherstellungsvorgänge finden Sie hier:

Verwalten von Sicherungen

Die folgende Liste enthält allgemeine Empfehlungen zur Verwaltung von Sicherungen:

  • Für jede Sicherung sollte ein eindeutiger Dateiname verwendet werden, um zu verhindern, dass BLOBs versehentlich überschrieben werden.

  • Beim Erstellen eines Containers sollten Sie die Zugriffsebene auf Privat festlegen, sodass der Lese- oder Schreibzugriff auf Blobs im Container nur Benutzern oder Konten mit den erforderlichen Authentifizierungsinformationen gestattet ist.

  • Für SQL Server-Datenbanken auf einer Instanz von SQL Server, die in einer Azure Virtual Machine ausgeführt wird, verwenden Sie ein Speicherkonto in derselben Region wie die virtuelle Maschine, um Kosten für die Datenübertragung zwischen den Regionen zu vermeiden. Wenn Sie innerhalb einer Region bleiben, erzielen Sie darüber hinaus optimale Leistung bei Sicherungs- und Wiederherstellungsvorgängen.

  • Eine fehlerhafte Sicherungsaktivität kann dazu führen, dass eine Sicherungsdatei unbrauchbar wird. Es wird empfohlen, regelmäßig nach fehlerhaften Sicherungen zu suchen und die BLOB-Dateien zu löschen. Weitere Informationen hierzu finden Sie unter Löschen von Backup Blob-Dateien aktiver Lease.

  • Wenn Sie die Sicherung mit der WITH COMPRESSION-Option durchführen, können Sie die Speicherkosten und Speichertransaktionskosten minimieren. Darüber hinaus verkürzt die Option die Dauer des Sicherungsvorgangs.

  • Legen Sie die Argumente MAXTRANSFERSIZE und BLOCKSIZE wie im Artikel SQL Server-Sicherung über URLs empfohlen fest.

  • SQL Server ist unabhängig von der Art der verwendeten Speicherredundanz. Die Sicherung in Seiten-Blobs und Block-Blobs wird für jede Speicherredundanz (LRS/ZRS/GRS/RA-GRS/RA-GZRS, etc.) unterstützt.

Behandlung großer Dateien

Bei SQL Server-Sicherungsvorgängen werden mehrere Threads verwendet, um die Datenübertragung an Azure Blob Storage zu optimieren. Die Leistung hängt jedoch von verschiedenen Faktoren ab wie der Bandbreite des unabhängigen Softwareherstellers (ISV) und der Größe der Datenbank. Wenn Sie beabsichtigen, große Datenbanken oder Dateigruppen von einer lokalen SQL Server-Datenbank zu sichern, sollten Sie zunächst den Durchsatz testen. Die SLA zum Speicher von Azure bietet maximale Verarbeitungszeiten für Blobs, die Sie als Ausgangspunkt verwenden können.

Die Verwendung der im Abschnitt Verwalten von Sicherungen empfohlenen WITH COMPRESSION-Option ist besonders beim Sichern umfangreicher Dateien von Bedeutung.

Problembehandlung bei Sicherungs- oder Wiederherstellungsvorgängen über URLs

Im Anschluss finden Sie einige schnelle Lösungen zur Behandlung von Sicherungs- und Wiederherstellungsfehlern bei Verwendung von Azure Blob Storage.

Um Fehler aufgrund nicht unterstützter Optionen oder Einschränkungen zu vermeiden, lesen Sie die Liste der Einschränkungen und Informationen zur Unterstützung der Befehle BACKUP und RESTORE im Artikel SQL Server Sichern und Wiederherstellen mit Microsoft Azure Blob Storage.

Fehler bei der Initialisierung

Parallele Sicherungen im selben Blob führen dazu, dass bei einer der Sicherungen die Meldung Fehler beim Initialisieren ausgegeben wird.

  • In SQL Server 2016 (13.x) und höheren Versionen wird Blockblob für die Sicherung auf URL bevorzugt.

  • Wenn Sie Seitenblöcke mit BACKUP TO URL verwenden, können Sie mit dem Trace-Flag 3051 die Protokollierung in einem bestimmten Fehlerprotokoll mit folgendem Format einschalten: BackupToUrl-\<instname>-\<dbname>-action-\<PID>.log, wobei \<action> eine der folgenden Optionen ist:

    • DB
    • FILELISTONLY
    • LABELONLY
    • HEADERONLY
    • VERIFYONLY

Ebenso erhalten Sie Informationen, wenn Sie im Windows-Ereignisanzeige in den Anwendungsprotokollen nach dem Namen SQLBackupToUrl suchen.

Die Anforderung konnte aufgrund eines E/A-Gerätefehlers nicht ausgeführt werden.

Berücksichtigen Sie beim Sichern großer Datenbanken COMPRESSION, MAXTRANSFERSIZE, BLOCKSIZE und mehrere URL-Argumente. Weitere Informationen finden Sie unter Sichern einer VLDB in Azure Blob Storage.

Der folgende Fehler:

Msg 3202, Level 16, State 1, Line 1
Write on "https://mystorage.blob.core.windows.net/mycontainer/TestDbBackupSetNumber2_0.bak" failed:
1117(The request could not be performed because of an I/O device error.)
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

Eine Beispielauflösung:

BACKUP DATABASE TestDb
TO URL = 'https://mystorage.blob.core.windows.net/mycontainer/TestDbBackupSetNumber2_0.bak',
URL = 'https://mystorage.blob.core.windows.net/mycontainer/TestDbBackupSetNumber2_1.bak',
URL = 'https://mystorage.blob.core.windows.net/mycontainer/TestDbBackupSetNumber2_2.bak'
WITH COMPRESSION, MAXTRANSFERSIZE = 4194304, BLOCKSIZE = 65536;

Meldung Filemark auf dem Gerät ist nicht ausgerichtet

Bei der Wiederherstellung von einer komprimierten Sicherung kann eine Fehlermeldung mit etwa folgendem Wortlaut angezeigt werden:

SqlException 3284 occurred. Severity: 16 State: 5
Message Filemark on device 'https://mystorage.blob.core.windows.net/mycontainer/TestDbBackupSetNumber2_0.bak' is not aligned.
Reissue the Restore statement with the same block size used to create the backupset: '65536' looks like a possible value.

Um diesen Fehler zu beheben, übergeben Sie die RESTORE-Anweisung erneut mit BLOCKSIZE = 65536.

Eine fehlerhafte Sicherungsaktivität kann zu Blobs mit aktiven Leases führen

Fehler während der Sicherung aufgrund von Blobs mit aktiver Lease: Failed backup activity can result in blobs with active leases.

Wenn eine Backup-Anweisung erneut versucht wird, schlägt der Backup-Vorgang möglicherweise mit einer Fehlermeldung ähnlich der folgenden Ausgabe fehl:

Backup to URL received an exception from the remote endpoint. Exception Message:
The remote server returned an error: (412) There is currently a lease on the blob and no lease ID was specified in the request.

Wenn versucht wird, eine RESTORE-Anweisung für eine BLOB-Sicherungsdatei mit aktiver Leasedauer auszuführen, wird eine Fehlermeldung mit etwa folgendem Wortlaut angezeigt:

Exception Message: The remote server returned an error: (409) Conflict..

Wenn dieser Fehler auftritt, müssen die BLOB-Dateien gelöscht werden. Weitere Informationen zu diesem Szenario und Lösungsvorschläge finden Sie unter Löschen von Sicherungsblobdateien mit aktiver Lease.

Betriebssystemfehler 50: Die Anforderung wird nicht unterstützt

Beim Sichern einer Datenbank kann der Fehler Operating system error 50(The request is not supported) aus den folgenden Gründen auftreten:

  • Das angegebene Speicherkonto ist kein universelles V1/V2-Konto.
  • Das SAS-Token enthielt bei der Erstellung der Anmeldeinformationen ein ?-Symbol am Anfang des Tokens. Wenn ja, entfernen Sie es.
  • Die aktuelle Verbindung kann vom aktuellen Computer aus über Storage-Explorer oder SQL Server Management Studio (SSMS) keine Verbindung mit dem Speicherkonto herstellen.
  • Die dem SAS-Token zugewiesene Richtlinie ist abgelaufen. Erstellen Sie mithilfe von Azure Storage-Explorer eine neue Richtlinie. Erstellen Sie dann entweder ein neues SAS-Token mit der Richtlinie, oder ändern Sie die Anmeldeinformationen, und versuchen Sie erneut, eine Sicherung durchzuführen.
  • Das Stammzertifikat fehlt im Vertrauenswürdigen Stammzertifizierungsspeicher. Weitere Informationen finden Sie unter Informationen zu Stammzertifizierungsstellen.

Authentifizierungsfehler

WITH CREDENTIAL ist eine neue Option, die für Sicherungs- oder Wiederherstellungsvorgänge mit Azure Blob Storage erforderlich ist.

In Zusammenhang mit Anmeldeinformationen können folgende Fehler auftreten: The credential specified in the **BACKUP** or **RESTORE** command does not exist.

Um dieses Problem zu vermeiden, können Sie T-SQL-Anweisungen zum Erstellen von Anmeldeinformationen einschließen, falls in der Backup-Anweisung keine Anmeldeinformationen enthalten sind. Beachten Sie das folgende Anwendungsbeispiel:

IF NOT EXISTS (
   SELECT *
   FROM sys.credentials
   WHERE credential_identity = 'mycredential'
)
CREATE CREDENTIAL [<credential name>]
   WITH IDENTITY = 'mystorageaccount',
      SECRET = '<storage access key>';

Der Berechtigungsnachweis existiert, aber das Login, mit dem der Backup-Befehl ausgeführt wird, hat keine Berechtigung für den Zugriff auf den Berechtigungsnachweis. Verwenden Sie ein Anmeldekonto der Rolle db_backupoperator mit Berechtigungen des Typs Beliebige Anmeldeinformationen ändern.

Überprüfen Sie den Namen des Speicherkontos und die Schlüsselwerte. Die in den Anmeldeinformationen gespeicherten Informationen müssen den Eigenschaftswerten Azure-Speicherkontos entsprechen, das Sie für Sicherungs- und Wiederherstellungsvorgänge verwenden.

Fehler 400: Ungültige Anforderung

Bei Verwendung von SQL Server 2012 (11.x) tritt möglicherweise ein Fehler auf, der der folgenden Art von Ausgabe ähnelt:

Backup to URL received an exception from the remote endpoint. Exception Message:
The remote server returned an error: (400) Bad Request.

Dies wird durch die vom Azure Storage-Konto unterstützte TLS-Version verursacht. Die unterstützte TLS-Version wird geändert, oder die in KB4017023 aufgeführte Problemumgehung wird verwendet.

Proxyfehler

Wenn Sie über Proxyserver auf das Internet zugreifen, können folgende Probleme auftreten:

Verbindungsdrosselung durch Proxyserver

Proxyserver können über Einstellungen verfügen, die die Anzahl der Verbindungen pro Minute begrenzen. Der URL-Sicherungsprozess ist ein Multithreadprozess und kann diese Begrenzung folglich überschreiten. In diesem Fall wird die Verbindung vom Proxyserver abgebrochen. Um das Problem zu beheben, ändern Sie die Proxyeinstellungen, damit der Proxy von SQL Server nicht verwendet wird. Im Folgenden einige Beispiele für Fehlertypen oder -meldungen, die im Fehlerprotokoll angezeigt werden können:

Write on "https://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak" failed: Backup to URL received an exception from the remote endpoint. Exception Message: Unable to read data from the transport connection: The connection was closed.
A nonrecoverable I/O error occurred on file "https://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak:" Error could not be gathered from Remote Endpoint.

Msg 3013, Level 16, State 1, Line 2

BACKUP DATABASE is terminating abnormally.
BackupIoRequest::ReportIoError: write failure on backup device https://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak'. Operating system error Backup to URL received an exception from the remote endpoint. Exception Message: Unable to read data from the transport connection: The connection was closed.

Wenn Sie mithilfe des Ablaufverfolgungsflags 3051 die ausführliche Protokollierung aktivieren, werden ggf. auch folgende Meldungen in den Protokollen angezeigt: HTTP status code 502, HTTP Status Message Proxy Error (The number of HTTP requests per minute exceeded the configured limit. Contact your ISA Server administrator.)

Standard-Proxy-Einstellungen werden nicht erfasst

Manchmal werden die Standardeinstellungen nicht übernommen, was zu Fehlern bei der Proxy-Authentifizierung führt wie beispielsweise:

A nonrecoverable I/O error occurred on file "https://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak:" Backup to URL received an exception from the remote endpoint. Exception Message: The remote server returned an error: (407)* **Proxy Authentication Required.

Um dieses Problem zu beheben, erstellen Sie mithilfe folgender Schritte eine Konfigurationsdatei, durch die beim URL-Sicherungsprozess die Standardproxyeinstellungen verwendet werden können:

  1. Erstellen Sie eine Konfigurationsdatei mit dem Namen BackuptoURL.exe.config und folgendem XML-Inhalt:

    <?xml version ="1.0"?>
    <configuration>
        <system.net>
            <defaultProxy enabled="true" useDefaultCredentials="true">
                <proxy usesystemdefault="true" />
            </defaultProxy>
        </system.net>
    </configuration>
    
  2. Speichern Sie die Konfigurationsdatei im Ordner Binn der SQL Server-Instanz. Als Beispiel: Wenn My SQL Server auf dem Computer auf Laufwerk C installiert ist, legen Sie die Konfigurationsdatei unter C:\Program Files\Microsoft SQL Server\MSSQL13.\<InstanceName>\MSSQL\Binn ab.

  3. BackuptoURL.exe wird nicht aufgerufen, wenn SAS-Schlüssel verwendet werden, aber bei Verwendung eines Zugriffsschlüssels ausgelöst werden. Stellen Sie sicher, dass Sie Zugriffsschlüssel verwenden, oder Sie können die folgende Fehlermeldung erhalten:

    Betriebssystemfehler 50 (Die Anforderung wird nicht unterstützt.)

Häufige Fehler und Lösungen

Problem Lösung
Fehler 3063: Fehler beim Schreiben auf das Sicherungsblockblob-Gerät https://storageaccount/container/name.bak. Das Gerät hat den Maximalwert der zulässigen Sperren erreicht. Um dieses Problem zu beheben, entfernen Sie Ihr Sicherungsziel mit mehreren Dateien, und stellen Sie sicher, dass Sie die folgenden Parameter im Sicherungsbefehl verwenden: COMPRESSION, MAXTRANSFERSIZE = 4194304, BLOCKSIZE = 65536.
Fehler 3035: Differenzielle Sicherung schlägt für eine oder mehrere Datenbanken fehl. Dies geschieht, wenn Sie eine den Azure Backup-Dienst zum Sichern von SQL-Datenbanken oder einer (VM)-Momentaufnahme konfiguriert haben, wodurch keine Kopie, sondern nur eine Sicherung erstellt wird. Dies führt dazu, dass Ihr Wartungsplan oder Ihre bedarfsgesteuerten SQL-Agent-Auftrag-Sicherungen nicht erfolgreich sind. Um dies zu beheben, fügen Sie diese Registrierungsschlüssel auf den virtuellen Computern, die SQL Server-Instanzen hosten, zum Schlüssel [HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\BCDRAGENT] hinzu, und fügen Sie "USEVSSCOPYBACKUP"="TRUE" hinzu.
Fehler 3201: Fehler bei der Sicherung mit - Betriebssystemfehler 50 (Die Anforderung wird nicht unterstützt). Generieren Sie das SAS-Token (Shared Access Signature) unter Verwendung von Storage-Explorer erneut: Sie können per Azure Storage-Explorer eine neue Richtlinie sowie ein neues SAS-Token mit dieser Richtlinie erstellen. Erstellen Sie die Anmeldeinformationen neu. Verwenden Sie dabei das neue, über Azure Storage erstellte SAS-Token. Versuchen Sie anschließend erneut, eine Sicherung durchzuführen. Weitere Informationen finden Sie unter Bekannte Probleme mit BACKUP TO URL. Stellen Sie sicher, dass Ihre Netzwerksicherheitsgruppe (NSG) und/oder Firewall eingehende und ausgehende Verbindungen mit den Ports 1433 und 443 zulässt.
Fehler 3271: Backup schlägt aufgrund eines TLS-Fehlers fehl - Backup auf URL hat eine Ausnahme vom entfernten Endpunkt erhalten. Dieses Problem kann bei den SQL Server Versionen 2012, 2014 und 2016 auftreten. Die Sicherung auf eine Microsoft Azure Blob Storage-Dienst-URL ist nicht mit TLS 1.2 kompatibel und kann durch Befolgen der Anweisungen in KB4017023 behoben werden.
Fehler 3271: Die Sicherung über URL hat eine Ausnahme vom Remoteendpunkt empfangen. Ausnahmemeldung: Der Remotename konnte nicht aufgelöst werden. Diese Meldung wird angezeigt, wenn ein falscher Berechtigungsnachweis, ein falsches Geheimnis oder ein falscher SAS-Schlüssel für die Konfiguration des Backups verwendet wurde. Löschen Sie die Anmeldeinformationen, und erstellen Sie sie neu. Für SQL Server 2012/2014 verwenden Sie die Speicherkontoidentität und den Zugriffsschlüssel und für SQL Server 2016 und spätere Versionen verwenden Sie SAS.
Error 18210: Ausnahme: Der Remoteserver hat einen Fehler zurückgegeben: (400) Ungültige Anforderung. Ändern Sie zur Behebung des Problems die minimale TLS-Version für das Speicherkonto auf 1.0 (Storage Account>Configuration>Minimum TLS Version) oder aktivieren Sie eine starke Verschlüsselung, wie in KB4017023 beschrieben.
Ausnahmemeldung: Der Remoteserver hat einen Fehler zurückgegeben: (412) Derzeit weist das Blob eine Lease auf, obwohl in der Anforderung keine Lease-ID angegeben wurde. Identifizieren Sie im Azure Storage-Explorer die Blobs mit einer Größe von 1 TB, unterbrechen Sie die Lease, löschen Sie das Blob, und wiederholen Sie den Sicherungsvorgang.
Fehler: Der Remoteserver hat einen Fehler zurückgegeben: (403) Verboten. Erstellen Sie das Speicherkonto, die Anmeldedaten und das SAS-Token neu, um das Problem zu beheben.
Die Sicherung für eine 1-TB-Datenbank schlägt in SQL Server 2012/2014 fehl. 1-TB-Sicherungen sind eine bekannte Einschränkung für Seitenblobs vor SQL Server 2016 (13.x). Verwenden Sie die Backup-Komprimierung, indem Sie der T-SQL-Sicherungsanweisungen die Klausel "WITH COMPRESSION" hinzufügen oder ihre SQL Server-Instanz auf SQL Server 2016 (13.x) und höhere Versionen aktualisieren.
Fehler: Die Sicherung über URL hat eine Ausnahme vom Remoteendpunkt empfangen. Ausnahmemeldung: Der Remoteserver hat einen Fehler zurückgegeben: (416) Der angegebene Seitenbereich ist ungültig. Dies kann vorkommen, wenn Sie mit SQL Server 2012 (11.x) und SQL Server 2014 (12.x) arbeiten und die Größe Ihres Backups auf 1 TB ansteigt. Entfernen Sie Ihre Sicherungsdateien, und/oder verwenden Sie die Backup-Komprimierung, um die Auflösung zu beheben.
Sicherungsfehler bei Verwendung eines Wartungsplans. Es gibt einige Fehler bei Wartungsplänen. Versuchen Sie, die Sicherung mit T-SQL auszuführen. Wenn T-SQL funktioniert, können Sie einen SQL-Agent-Job erstellen, um die Datenbanken zu sichern.
Fehler bei der Sicherung, weil VM-Grenzwerte erreicht wurden. Wenn Sie die Fehlermeldung erhalten, dass das IOPS/VM-Limit der Festplatte erreicht wurde, werden die Backups möglicherweise langsamer oder schlagen fehl. Verwenden Sie zum Überwachen von IOPS/VM-Grenzwerten Azure Monitor-Metriken, und ändern Sie bei Bedarf die Größe des virtuellen Computers bzw. des Datenträgers, um das Problem zu beheben.
Der Remoteserver hat einen Fehler zurückgegeben: (409) Konflikt für SQL Server 2012/2014" Speicherkonten mit hierarchischem Namespace sind für Blockblobs und nicht für Seitenblobs ausgestattet. Speicherkonten ohne dieses Feature sollten nicht für BACKUP TO URL in SQL Server 2014 (12.x) verwendet werden.