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

Gilt für:SQL ServerAzure 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 nur Benutzer oder Konten, die die erforderlichen Authentifizierungsinformationen bereitstellen können, die Blobs im Container lesen oder schreiben können.

• Verwenden Sie für SQL Server-Datenbanken auf einer Instanz von SQL Server, die auf einem virtuellen Azure-Computer ausgeführt wird, ein Speicherkonto in derselben Region wie der virtuelle Computer, um Datenübertragungskosten zwischen 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 finden Sie unter Löschen von Sicherungs-BLOB-Dateien mit aktiven Leases.

• 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. Das Sichern von Seiten-Blobs und Block-Blobs wird für jede Speicherredundanz unterstützt (LRS/ZRS/GRS/RA-GRS/RA-GZRS usw.).

Behandeln 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 aus einer lokalen SQL Server-Datenbank zu sichern, sollten Sie zuerst einige Durchsatztests durchführen. Die SLA zum Speicher von Azure bietet maximale Verarbeitungszeiten für Blobs, die Sie als Ausgangspunkt verwenden können.

Die Verwendung der WITH COMPRESSION Option wie im Abschnitt "Sicherungen verwalten" empfohlen ist beim Sichern großer Dateien wichtig.

Problembehandlung bei der Sicherung oder Wiederherstellung von URL

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 die Unterstützung für informationen zu BACKUP und RESTORE Befehle im Artikel SQL Server Backup and Restore with 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 block blob für die Sicherung auf URL bevorzugt.

• Wenn Sie Seitenblobs verwendenBACKUP TO URL, können Sie die Ablaufverfolgungskennzeichnung 3051 verwenden, um die Protokollierung in einem bestimmten Fehlerprotokoll mit dem folgenden Format zu aktivieren: , wobei \<action> eine der folgenden Optionen angezeigt wird: BackupToUrl-\<instname>-\<dbname>-action-\<PID>.log

  • DB
  • FILELISTONLY
  • LABELONLY
  • HEADERONLY
  • VERIFYONLY

Sie können auch Informationen finden, indem Sie die Windows Ereignisanzeige unter Anwendungsprotokolle mit dem Namen SQLBackupToUrlüberprüfen.

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

Berücksichtigen Sie COMPRESSIONbeim Sichern großer Datenbanken mehrere MAXTRANSFERSIZEBLOCKSIZEURL-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;

Das Nachrichtendateizeichen auf dem Gerät wird 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.

Fehlgeschlagene 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 Sicherungsaufweisung erneut formatiert wird, schlägt der Sicherungsvorgang möglicherweise mit einem Fehler wie die folgende 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 wird möglicherweise ein Fehler Operating system error 50(The request is not supported) aus den folgenden Gründen angezeigt:

• Das angegebene Speicherkonto ist nicht "General Purpose V1/V2".
• 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 Speicher für vertrauenswürdige Stammzertifizierung. Weitere Informationen finden Sie unter Azure-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 einschließen, um die Anmeldeinformationen zu erstellen, wenn eine in der Sicherungsanweisung nicht vorhanden ist. 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>';

Die Anmeldeinformationen sind vorhanden, aber die Anmeldung, die zum Ausführen des Sicherungsbefehls verwendet wird, verfügt nicht über Berechtigungen für den Zugriff auf die Anmeldeinformationen. Verwenden Sie ein Konto in der rolle db_backupoperator mit Ändern aller Anmeldeinformationenberechtigungen .

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

Fehler 400: Ungültige Anforderung

Bei Verwendung von SQL Server 2012 (11.x) tritt möglicherweise ein Fehler auf, der eine Sicherung ähnlich der folgenden Ausgabe ausführt:

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 Proxyserver für den Zugriff auf das Internet verwenden, werden möglicherweise die folgenden Probleme angezeigt:

Verbinden ionseinschränkung durch Proxyserver

Proxyserver können Einstellungen haben, 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 dieses Problem zu beheben, ändern Sie die Proxyeinstellungen so, dass SQL Server den Proxy nicht verwendet. Im Folgenden finden Sie einige Beispiele für die Typen oder Fehlermeldungen, die im Fehlerprotokoll angezeigt werden:

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 Seitenblobs verwenden, aktivieren Sie die ausführliche Protokollierung mithilfe des Ablaufverfolgungskennzeichnungs 3051, möglicherweise wird auch die folgende Meldung 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.)

Standardmäßige Proxyeinstellungen wurden nicht aufgenommen.

Manchmal werden die Standardeinstellungen nicht aufgenommen, was zu Proxyauthentifizierungsfehlern führt, z. B.:

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. Wenn beispielsweise mein SQL Server auf dem C Laufwerk des Computers installiert ist, platzieren Sie die Konfigurationsdatei in C:\Program Files\Microsoft SQL Server\MSSQL13.\<InstanceName>\MSSQL\Binn.

3. BackuptoURL.exe wird nicht aufgerufen, wenn SAS-Schlüssel verwendet werden, aber bei Verwendung einer Zugriffstaste ausgelöst werden. Stellen Sie sicher, dass Sie Zugriffstasten 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)