Bewährte Methoden für die Sicherung und Wiederherstellung (Windows Azure-BLOB-Speicherdienst)
In diesem Thema werden bewährte Methoden und Tipps zur Problembehandlung beschrieben, die sich auf SQL Server-Sicherungs- und Wiederherstellungsvorgänge im Windows Azure-BLOB-Dienst beziehen.
Weitere Informationen zur Verwendung des Windows Azure-BLOB-Speicherdiensts für SQL Server-Sicherungs- oder -Wiederherstellungsvorgänge finden Sie unter:
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 Windows Azure-BLOB-Containers wird empfohlen, die Zugriffsebene auf Privat festzulegen, sodass der Lese- oder Schreibzugriff auf BLOBs im Container nur Benutzern oder Konten mit den erforderlichen Authentifizierungsinformationen gestattet ist.
Um Übertragungskosten zwischen Regionen zu vermeiden, verwenden Sie für Datenbanken auf einer SQL Server-Instanz, die auf einem virtuellen Windows Azure-Computer ausgeführt wird, ein Speicherkonto, das derselben Region wie der virtuelle Computer angehört. 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 die 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 BLOB-Sicherungsdateien mit 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.
Behandlung großer Dateien
SQL Server-Sicherungsvorgänge verwenden mehrere Threads, um die Datenübertragung an die Windows Azure-BLOB-Speicherdienste 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 Windows Azure-Speicher bietet maximale Verarbeitungsleistung 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.
Optimieren der Wiederherstellungsvorgänge
Um das Schreiben von Wiederherstellungsdaten zu beschleunigen, fügen Sie dem SQL Server-Benutzerkonto die Benutzerberechtigung Durchführen von Volumewartungsaufgaben hinzu. Weitere Informationen finden Sie unter Datenbankdatei-Initialisierung
Überlegungen zur Leistung
Die Leistung bei Sicherungen und Wiederherstellungen kann abhängig von der Netzwerkbandbreite, der Datenbankgröße und dem Standort der Speicherdienste von Windows Azure im Verhältnis zum lokalen Standort variieren. Um die Sicherungs- und Wiederherstellungsleistung für Ihre Umgebung zu beurteilen, sollten Sicherungen und Wiederherstellungen getestet sowie Durchsatz und Leistung gemessen werden. Folgende Aspekte sollten beim Ausführen von Sicherungen in den Windows Azure-BLOB-Speicherdienst berücksichtigt werden:
Sicherungs- und Wiederherstellungszeiten verhalten sich proportional zur Netzwerkbandbreite.
Die minimale Netzwerkbandbreite für Sicherungen beträgt 1 MB pro Sekunde. Bei Bandbreiten unter 1 MB pro Sekunde können Sicherungen Timeoutfehler verursachen.
Die Wiederherstellungszeit verhält sich auch proportional zur Netzwerklatenz, insbesondere wenn Sie eine Datei aus einer Windows Azure-Region wiederherstellen, die geografisch von der SQL Server-Instanz entfernt ist, auf der die Wiederherstellung erfolgen soll. In derartigen Fällen werden Testverfahren besonders wichtig, um sicherzustellen, dass die RTO-Bedingungen erfüllt werden.
Problembehandlung bei Sicherungs- und Wiederherstellungsvorgängen im Windows Azure-BLOB-Speicherdienst
Im Folgenden finden Sie einige schnelle Lösungen zur Behandlung von Sicherungs- und Wiederherstellungsfehlern im Windows Azure-BLOB-Speicherdienst.
Zur Vermeidung von Fehlern, die durch nicht unterstützte Optionen oder Einschränkungen verursacht werden, informieren Sie sich anhand der Liste im Artikel SQL Server-Sicherung und -Wiederherstellung mit dem Windows Azure-BLOB-Speicherdienst über die Möglichkeiten und Grenzen von BACKUP- und RESTORE-Befehlen.
Authentifizierungsfehler:
WITH CREDENTIAL ist eine neue Option, die für Sicherungs- oder Wiederherstellungsvorgänge im Windows Azure-BLOB-Speicherdienst erforderlich ist. In Zusammenhang mit Anmeldeinformationen können folgende Fehler auftreten:
Die im BACKUP-Befehl oder RESTORE-Befehl angegebenen Anmeldeinformationen sind nicht vorhanden. 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> ;Die Anmeldeinformationen sind zwar vorhanden, aber das Anmeldekonto zum Ausführen des Sicherungsbefehls verfügt über keine Berechtigung für den Zugriff auf die Anmeldeinformationen. Verwenden Sie ein Anmeldekonto aus der db_backupoperator-Rolle, das über die Alter any credential-Berechtigung verfügt.
Überprüfen Sie den Namen des Speicherkontos und die Schlüsselwerte. Die in den Anmeldeinformationen gespeicherten Informationen müssen den Eigenschaftswerten des Windows Azure-Speicherkontos entsprechen, das Sie für Sicherungs- und Wiederherstellungsvorgänge verwenden.
Sicherungsfehler:
Parallele Sicherungen im selben BLOB führen dazu, dass bei einer der Sicherungen die Meldung Fehler beim Initialisieren ausgegeben wird.
Verwenden Sie die folgenden Fehlerprotokolle, die Ihnen die Problembehandlung bei Sicherungsfehlern erleichtern:
Legen Sie das Ablaufverfolgungsflag 3051 wie folgt fest, um die Protokollierung in einem bestimmten Fehlerprotokoll zu aktivieren:
BackupToUrl-<instname>-<dbname>-action-<PID>.log. Dabei entspricht <action> einem der folgenden Schlüsselwörter:
DB
FILELISTONLY
LABELONLY
HEADERONLY
VERIFYONLY
Sie finden die Informationen auch, indem Sie im Windows-Ereignisprotokoll in den Anwendungsprotokollen nach dem Namen "SQLBackupToUrl" suchen.
Sicherungsfehler aufgrund von BLOBs, die über eine aktive Lease verfügen: Fehlerhafte Sicherungsaktivitäten können dazu führen, dass BLOBs eine aktive Lease aufweisen.
Wenn die BACKUP-Anweisung erneut ausgeführt wird, kann ein Sicherungsvorgang einen Fehler mit etwa folgendem Wortlaut verursachen:
Bei BACKUP TO URL wurde eine Ausnahme vom Remoteendpunkt empfangen. Ausnahmemeldung: Der Remoteserver hat einen Fehler zurückgegeben: (412) Derzeit weist der BLOB eine Lease auf, obwohl in der Anforderung keine Lease-ID angegeben wurde.
Wenn versucht wird, eine RESTORE-Anweisung für eine BLOB-Sicherungsdatei mit aktiver Lease auszuführen, wird eine Fehlermeldung mit etwa folgendem Wortlaut angezeigt:
Ausnahmemeldung: Der Remoteserver hat einen Fehler zurückgegeben: (409) Konflikt...
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 BLOB-Sicherungsdateien mit aktiver Lease.
Proxyfehler
Wenn Sie über Proxyserver auf das Internet zugreifen, können folgende Probleme auftreten:
Durch Proxyserver gedrosselte Verbindungen:
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:
Fehler beim Schreiben auf "http://storageaccount.blob.core.windows. net/container/BackupAzurefile.bak": Bei einer URL-Sicherung wurde eine Ausnahme vom Remoteendpunkt empfangen. Ausnahmemeldung: Von der Übertragungsverbindung können keine Daten gelesen werden: Die Verbindung wurde geschlossen.
Nicht behebbarer E/A-Fehler für die Datei "http://storageaccount.blob.core.windows. net/container/BackupAzurefile.bak:" Der Fehler konnte nicht vom Remoteendpunkt erfasst werden.
Meldung 3013, Ebene 16, Status 1, Zeile 2
BACKUP DATABASE wird fehlerbedingt beendet.
BackupIoRequest::ReportIoError: Schreibfehler auf Sicherungsmedium "http://storageaccount.blob.core.windows. net/container/BackupAzurefile.bak". Betriebssystemfehler: Bei einer URL-Sicherung wurde eine Ausnahme vom Remoteendpunkt empfangen. Ausnahmemeldung: Von der Übertragungsverbindung können keine Daten gelesen werden: Die Verbindung wurde geschlossen.
Wenn Sie die ausführliche Protokollierung mit Ablaufverfolgungsflag 3051 aktivieren, können auch folgende Meldungen in den Protokollen angezeigt werden:
HTTP-Statuscode 502, HTTP-Statusmeldung: Proxyfehler (Die Anzahl der HTTP-Anforderungen pro Minute hat das konfigurierte Limit überschritten. Wenden Sie sich an Ihren ISA Server-Administrator. )
Standardproxyeinstellungen wurden nicht abgerufen:
In einigen Fällen werden die Standardeinstellungen nicht abgerufen, wodurch Proxyauthentifizierungsfehler wie der folgende verursacht werden: Nicht behebbarer E/A-Fehler für die Datei "http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak:" Bei einer URL-Sicherung wurde eine Ausnahme vom Remoteendpunkt empfangen. Ausnahmemeldung: Der Remoteserver hat einen Fehler zurückgegeben: (407) Proxyauthentifizierung erforderlich.
Um dieses Problem zu beheben, erstellen Sie mithilfe folgender Schritte eine Konfigurationsdatei, durch die beim URL-Sicherungsprozess die Standardproxyeinstellungen verwendet werden können:
Erstellen Sie eine Konfigurationsdatei mit dem Namen BackuptoURL.exe.config und folgender XML:
<?xml version ="1.0"?> <configuration> <system.net> <defaultProxy enabled="true" useDefaultCredentials="true"> <proxy usesystemdefault="true" /> </defaultProxy> </system.net> </configuration>Speichern Sie die Konfigurationsdatei im Ordner Binn der SQL Server-Instanz. Beispiel: Wenn SQL Server auf dem Computer auf Laufwerk "C" installiert ist, legen Sie die Konfigurationsdatei im folgenden Ordner ab: C:\Programme\Microsoft SQL Server\MSSQL11.<InstanceName>\MSSQL\Binn.