(0) exportieren Drucken
Alle erweitern
Dieser Artikel wurde noch nicht bewertet - Dieses Thema bewerten.

Überlegungen zu hoher Verfügbarkeit und Notfallwiederherstellung bei Windows Azure SQL-Datenbanken

Letzte Aktualisierung: Dezember 2013

Bei der Migration einer lokalen SQL Server-Datenbank zu einer Windows Azure SQL-Datenbank (SQL-Datenbank) stellt sich häufig die Frage, wie eine Sicherungs- und Wiederherstellungsstrategie implementiert werden sollte, um Daten vor Benutzer-, Anwendungs- und Hardwarefehlern sowie vor Datencenterausfällen im Falle von Naturkatastrophen und anderen Notfällen im Hinblick auf Datenbanken zu schützen. Anders als bei lokalen Bereitstellungen werden in einer SQL-Datenbank physische Verwaltungsaufgaben und Vorgänge für Datenbankdateien von Datenbankadministratoren unbemerkt im Hintergrund ausgeführt. Beachten Sie, dass ein SQL-Datenbankserver ein logischer Server ist, der eine Gruppe von Datenbanken definiert. Datenbanken, die dem SQL-Datenbankserver zugeordnet sind, können sich auf separaten physischen Computern im Microsoft-Datencenter befinden. Eine einzelne logische Datenbank könnte den Speicherplatz einer einzelnen physischen Datenbank mit einer anderen logischen Datenbank gemeinsam nutzen. In einer mehrinstanzfähigen Windows Azure-Umgebung werden herkömmliche Sicherungs- und Wiederherstellungstools von SQL Server nicht unterstützt.

Autoren: Kun Cheng, Selcin Turkarslan
Bearbeiter: Steve Howard, Adrian Bethune

Schützen der Datenbank vor Ausfällen einzelner Server, Geräte oder Netzwerkverbindungen

Jede SQL-Datenbankinstanz verfügt über drei Replikate, d. h. ein primäres und zwei sekundäre Replikate, die sich auf drei unterschiedlichen physischen Computern innerhalb eines Datencenters befinden. Alle Lese- und Schreibvorgänge durchlaufen das primäre Replikat, und alle Änderungen werden asynchron auf die sekundäre Replikate repliziert.

Eine SQL-Datenbank verwendet ein quorumbasiertes Commitschema, bei dem der Schreibvorgang auf dem primären Replikat und einem sekundären Replikat abgeschlossen sein muss, bevor die Transaktion als Transaktion mit ausgeführtem Commit angesehen wird. Tritt auf dem primären Replikat ein Hardwarefehler auf, wird er von der SQL-Datenbankstruktur erkannt und ein Failover auf das sekundäre Replikat ausgeführt. Daher befinden sich in einem Datencenter auch mindestens zwei hinsichtlich der Transaktion konsistente physische Kopien der Daten. Die drei Replikate für jede Windows Azure SQL-Datenbankinstanz schützen Ihre Daten vor dem Ausfall einzelner Server, Geräte oder Netzwerkverbindungen. Zusätzlich zu den redundanten Replikaten werden in der Windows Azure SQL-Datenbankstruktur die für alle Datenbanken im Datencenter in Intervallen von fünf Minuten erstellten Sicherungen mindestens der letzten 14 Tage vorgehalten. Diese Sicherungen werden zum Schutz vor gleichzeitigen oder schwerwiegenden Hardware- und Systemfehlern im Datencenter gespeichert.

Die SQL-Datenbank-Umgebung ist dafür ausgelegt, die Serververfügbarkeit und Datenintegrität bei Hardwarefehlern aufrechtzuerhalten. Während eines Failoverereignisses kann auf eine SQL-Datenbankinstanz u. U. kurzzeitig nicht zugegriffen werden. Die Anwendung benötigt eine Wiederholungslogik für derartige Failoverereignisse. Nach dem Failover auf das sekundäre Replikat können Sie jedoch mit derselben Verbindungszeichenfolge eine neue Verbindung herstellen. Weitere Informationen zum Behandeln von Verbindungsfehlern finden Sie im Artikel Verbindungsverwaltung in der Windows Azure SQL-Datenbank im TechNet Wiki.

Schützen der Datenbank vor unbeabsichtigten Löschungen oder Änderungen

Benutzer- oder Anwendungsfehler stellen in vielen Softwareanwendungen eine der häufigsten Ursachen für Datenverluste oder -beschädigungen dar. Ein Benutzer könnte eine Tabelle oder Anwendung versehentlich löschen oder eine Transaktion zweimal senden. Diese Fehlertypen sind schwer zu kontrollieren und erschweren die Wiederherstellung. Mithilfe folgender Tools können derartige Probleme behandelt werden:

  • Datenbankkopie

  • Import/Export-Dienst für SQL-Datenbanken

  • "bcp" und SQL Server Integration Services

Mit Datenbankkopie können Sie eine Kopie der Datenbank auf demselben Server oder auf einem anderen Server im selben Datencenter erstellen. Dieser Onlinevorgang ist asynchron und hinsichtlich der Transaktion konsistent. Da dies ein asynchroner Vorgang ist, können Sie den Kopierbefehl ausgeben und dann den Status überwachen, indem Sie die sys.dm_database_copies (SQL Database)-Systemsicht abfragen.

Zum Kopieren einer SQL-Datenbankinstanz muss Ihr Anmeldename auf dem Zielserver der dbmanager-Rolle auf Serverebene angehören und auf dem Quellserver dem DBO der Quelldatenbank entsprechen. Die Anmeldung muss auf beiden SQL-Datenbankservern, d. h. Quell- und Zielserver, unter demselben Anmeldenamen und Kennwort erfolgen. Die empfohlene Häufigkeit für das Kopieren einer Datenbank kann variieren und ist abhängig von den Geschäftsanforderungen. Wenn Sie Benutzer- oder Anwendungsfehler beheben möchten, empfehlen wir, täglich eine Kopie zu erstellen und zwei oder drei Kopien im Rotationsverfahren bereitzuhalten, wobei die älteste Kopie jeden Tag nach Abschluss der neuen Kopie verworfen werden kann.

Obwohl wir das Erstellen täglicher Kopien empfehlen, können Sie Ihre Datenbank bei Bedarf natürlich auch häufiger kopieren. Es empfiehlt sich, den Datenbankkopiervorgang maximal einmal pro Stunde auszuführen. Jeder Datenbankkopiervorgang wird zwar unabhängig von allen anderen Datenbankkopiervorgängen ausgeführt, erzeugt jedoch eine Datenbankkopie, die am Ende des Kopiervorgangs hinsichtlich der Transaktion konsistent ist. Jede Kopie fließt in das Datenbanklimit von 150 Datenbanken pro SQL-Datenbankserver ein und wird als separate Datenbank berechnet. Daher kann ein zu häufiges Kopieren dazu führen, dass für Ihr Konto nicht mehr genügend Datenbanken zur Verfügung stehen und unnötige Gebühren für Datenbankkopien entstehen, die fast identisch sind. Weitere Informationen finden Sie im SQL-Datenbankthema Copying Databases in SQL Database in der MSDN Library.

Neben der Datenbankkopie kann der SQL Database Import/Export Service verwendet werden. Dieser Dienst ermöglicht es Ihnen, sowohl Daten als auch das Schema in einem Paket mit der .bacpac-Erweiterung zu importieren oder zu exportieren. Das Paket weist ein komprimiertes Format auf und enthält alle mit SQL-Datenbanken kompatiblen Objekte, wie Tabellen, Sichten, Indizes, Einschränkungen, Trigger, gespeicherte Prozeduren, Anmeldenamen, Benutzer usw. Durch den Dienst können BACPAC-Dateien direkt zwischen einer SQL-Datenbankinstanz und dem Windows Azure-BLOB-Speicher importiert oder exportiert werden. Sie können über das Windows Azure-Verwaltungsportal auf den Import/Export-Dienst zugreifen. Wenn Sie einen direkten Import oder Export zwischen einer lokalen SQL Server-Version und einer SQL-Datenbank ausführen möchten, ohne den Windows Azure-BLOB-Speicher zu nutzen, verwenden Sie die Klassen im Microsoft.SqlServer.Dac-Namespace. Sie können ebenfalls DacIESvcCli.exe in den SQL DAC-Beispielen auf der CodePlex-Website verwenden.

Anders als bei der Datenbankkopie wird mit dem Import/Export-Dienst keine Sicherung erstellt, die hinsichtlich der Transaktion konsistent ist. Zum Ausführen einer Sicherung wird empfohlen, die Datenbank zu sperren und Transaktionen zu beenden, bevor die Daten und das Schema exportiert werden, oder stattdessen zunächst mit der Funktion Datenbankkopie eine im Hinblick auf Transaktionen konsistente Kopie zu erstellen und dann den Export unter Verwendung der Kopie auszuführen. Weitere Informationen zu Sicherungs- und Wiederherstellungsstrategien finden Sie unter Windows Azure SQL Database Backup and Restore.

Das Bulk copy utility (BCP.exe), SQL Server Integration Services (SSIS) und System.Data.SqlClient.SqlBulkCopy funktionieren ähnlich wie der Import/Export Service. SQL-Datenbanken unterstützen derzeit BCP, die API für das Massenkopieren und SSIS zum Verschieben von Daten. Sie müssen Schemaobjekte in einer SQL-Datenbank erstellen, bevor Sie die Daten laden. Wenn Sie BCP oder SSIS als Mechanismus zum Massenkopieren verwenden, können Sie steuern, welche Objekte aus einer Datenbank und welche Daten aus diesen Objekten verschoben werden. Sie können auch verschiedene Parameter wie die Batchgröße, Paketgröße und Anzahl der Datenströme angeben, um abhängig von der Netzwerkbandbreite und -latenz einen optimalen Durchsatz zu erzielen.

Schützen der Datenbank vor einem ausgedehnten Ausfall der Datencenterinfrastruktur

Zum Schutz vor dem Ausfall eines ganzen Rechenzentrums im Notfall müssen Sie einen externen Speicherort für Datenbanksicherungen außerhalb des Rechenzentrums einrichten, in dem Ihre Datenbankanwendung gehostet wird. Dazu wird empfohlen, dass Sie sowohl die im vorherigen Abschnitt beschriebene Datenbankkopie als auch den Import/Export-Dienst für SQL-Datenbanken verwenden.

Folgende Tools empfehlen sich besonders für die Verwaltung einer generellen Sicherungs- und Wiederherstellungsstrategie:

  • Zum Behandeln von Benutzer- und Anwendungsfehlern implementieren Sie eine Sicherungs- und Wiederherstellungsstrategie mit:

    • Datenbankkopie

    • Import/Export-Dienst für SQL-Datenbanken

    • "bcp" oder SQL Server Integration Services

  • Zum Behandeln eines ausgedehnten Ausfalls der Datencenterinfrastruktur implementieren Sie eine erweiterte Sicherungs- und Wiederherstellungsstrategie mit:

    • Import/Export-Dienst. Migrieren Sie eine Datenbankkopie zu einem oder mehreren sekundären Datencentern und optional zu Ihrer eigenen lokalen SQL Server-Umgebung.

Weitere Informationen zu den Optionen für die Sicherung, Wiederherstellung und Notfallwiederherstellung in Windows Azure finden Sie in den Artikeln Business Continuity in Windows Azure SQL Database und Technische Dokumentation zur Geschäftskontinuität mit Windows Azure in der MSDN Library.

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft. Alle Rechte vorbehalten.