Sichern von Stretch-aktivierten Datenbanken (Stretch Database)

  • Artikel

Gilt für: SQL Server 2016 (13.x) und höher – nur Windows

Wichtig

Stretch Database ist in SQL Server 2022 (16.x) und der Azure SQL-Datenbank veraltet. Diese Funktion wird in einer zukünftigen Version der Datenbank-Engine entfernt. Nutzen Sie diese Funktionen bei Neuentwicklungen nicht mehr, und planen Sie die Änderung von Anwendungen, die diese Funktion zurzeit verwenden.

Datenbanksicherungen erleichtern de Wiederherstellung nach verschiedensten Fehlern und Notfällen.

  • Daher sollten Sie die SQL Server-Datenbanken mit aktivierter Stretch-Datenbank-Funktion sichern.

  • Microsoft Azure sichert automatisch die Remotedaten, die von Stretch Database von SQL Server zu Azure migriert wurden.

Die Datensicherung ist nur ein Teil einer vollständigen Lösung für Hochverfügbarkeit und Geschäftskontinuität. Weitere Informationen zu Hochverfügbarkeit finden Sie unter Lösungen für Hochverfügbarkeit.

Sichern Ihrer SQL Server-Daten

Zum Sichern Ihrer SQL Server-Datenbanken, für die Stretch-Datenbank aktiviert wurde, können Sie weiterhin die SQL Server-Sicherungsmethoden verwenden, die Sie derzeit verwenden. Weitere Informationen finden Sie unter Sichern und Wiederherstellen von SQL Server-Datenbanken.

Sicherungen von SQL Server-Datenbanken mit aktivierter Stretch-Datenbank-Funktion enthalten nur lokale Daten und nur Daten, die zu dem Zeitpunkt der Sicherung migriert werden dürfen. (Zur Migration berechtigte Daten sind Daten, die noch nicht migriert wurden. Sie werden jedoch basierend auf den Migrationseinstellungen der Tabellen zu Azure migriert.) Dies wird als flaches Sichern bezeichnet und berücksichtigt nicht Ihre bereits zu Azure migrierten Daten.

Sichern Ihrer Azure-Remotedaten

Microsoft Azure sichert automatisch die Remotedaten, die von Stretch Database von SQL Server zu Azure migriert wurden.

Azure reduziert das Risiko eines Datenverlusts durch das automatische Sichern

Der Azure-Dienst SQL Server Stretch Database schützt Ihre Remotedatenbanken mindestens alle acht Stunden durch automatische Speichermomentaufnahmen. Jede Momentaufnahme wird sieben Tage lang beibehalten, um den größtmöglichen Bereich von möglichen Wiederherstellungspunkten für Sie bereitzustellen.

Azure reduziert das Risiko eines Datenverlusts durch Georedundanz

Datenbanksicherungen in Azure werden im georedundanten Azure-Speicher (Read-Access Geo Redundant-Speicher; RA-GRS) gespeichert und sind daher standardmäßig georedundant. Georedundanter Speicher repliziert Ihre Daten in eine sekundäre Region, die Hunderte von Meilen von der primären Region entfernt ist. In primären und sekundären Regionen werden Ihre Daten jeweils dreimal in separaten Fehler- und Upgradedomänen repliziert. Dadurch wird sichergestellt, dass Ihre Daten erhalten bleiben, sogar im Falle eines vollständigen, regionalen Stromausfalls oder eines Notfalls, der eine ganze Region unzugänglich macht.

Stretch Database reduziert das Risiko eines Verlusts Ihrer Azure-Daten, indem migrierte Zeilen vorübergehend beibehalten werden.

Nachdem Stretch Database relevante Zeilen aus SQL Server zu Azure migriert hat, behält sie diese Zeilen mindestens acht Stunden lang in der Stagingtabelle bei. Wenn Sie eine Sicherungskopie Ihrer Azure-Datenbank wiederherstellen, verwendet Stretch Database die in der Stagingtabelle gespeicherten Zeilen, um die SQL Server- und die Azure-Datenbanken abzustimmen.

Nach der Wiederherstellung einer Ihrer Azure-Datenbanksicherungen müssen Sie die gespeicherte Prozedur sys.sp_rda_reauthorize_db ausführen, um eine SQL Server-Datenbank, für die Stretch-Datenbank aktiviert wurde, wieder mit der Azure-Remotedatenbank zu verbinden. Wenn Sie sys.sp_rda_reauthorize_db ausführen, stimmt Stretch Database automatisch die SQL Server- und die Azure-Datenbanken ab.

Um die Anzahl von Stunden zu erhöhen, für die migrierte Daten von Stretch Database vorübergehend in der Stagingtabelle beibehalten werden, führen Sie die gespeicherte Prozedur sys.sp_rda_set_rpo_duration aus, und geben Sie eine Stundenanzahl von über acht an. Bedenken Sie bei der Entscheidung, wie viele Daten beibehalten werden sollen, die folgenden Faktoren:

  • Die Häufigkeit der automatischen Azure-Sicherungen (mindestens alle 8 Stunden)
  • Die erforderliche Zeit, um ein Problem zu erkennen und zu entscheiden, ob eine Sicherung wiederhergestellt werden soll
  • Die Dauer des Azure-Wiederherstellungsvorgangs

Hinweis

Wird die Datenmenge erhöht, die Stretch Database vorübergehend in der Stagingtabelle beibehält, erhöht sich dadurch auch der erforderliche Speicherplatz auf dem SQL Server-Computer.

Um die Anzahl von Stunden zu überprüfen, für die Daten von Stretch Database vorübergehend in der Stagingtabelle beibehalten werden, führen Sie die gespeicherte Prozedur sys.sp_rda_get_rpo_duration aus.

Siehe auch