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:

• SQL Server-Sicherung und -Wiederherstellung mit Microsoft Azure Blob Storage

• Schnellstart: Sichern und Wiederherstellen von SQL in Azure Blob Storage

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

Zugehöriger Inhalt

• Wiederherstellen von in Microsoft Azure gespeicherten Sicherungen
• BACKUP (Transact-SQL)
• RESTORE (Transact-SQL)