Freigeben über

Manuelles Vorbereiten einer sekundären Datenbank auf eine Verfügbarkeitsgruppe (SQL Server)

  • Artikel

In diesem Thema wird beschrieben, wie Sie eine sekundäre Datenbank für eine AlwaysOn-Verfügbarkeitsgruppe in SQL Server 2014 mithilfe von SQL Server Management Studio, Transact-SQL oder PowerShell vorbereiten. Die Vorbereitung einer sekundären Datenbank erfordert zwei Schritte: (1) das Wiederherstellen einer aktuellen Datenbanksicherung der primären Datenbank und nachfolgender Protokollsicherungen auf allen Serverinstanzen, auf denen das sekundäre Replikat gehostet wird, mit RESTORE WITH NORECOVERY und (2) das Verknüpfen der wiederhergestellten Datenbank mit der Verfügbarkeitsgruppe.

Tipp

Wenn Sie eine vorhandene Protokollversandkonfiguration haben, können Sie möglicherweise die primäre Datenbank für den Protokollversand zusammen mit einer oder mehreren sekundären Datenbanken in eine primäre AlwaysOn-Datenbank und eine oder mehrere sekundäre AlwaysOn-Datenbanken konvertieren. Weitere Informationen finden Sie unter Voraussetzungen für die Migration vom Protokollversand zu AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

Vorbereitungen

Voraussetzungen und Einschränkungen

  • Stellen Sie sicher, dass das System, auf dem die Datenbank gespeichert werden soll, einen Datenträger mit ausreichend Speicherplatz für die sekundären Datenbanken besitzt.

  • Der Name der sekundären Datenbank muss dem Namen der primären Datenbank entsprechen.

  • Verwenden Sie RESTORE WITH NORECOVERY für jeden Wiederherstellungsvorgang.

  • Wenn sich die sekundäre Datenbank unter einem anderen Dateipfad (einschließlich des Laufwerkbuchstabens) als die primäre Datenbank befinden muss, muss vom Wiederherstellungsbefehl auch die WITH MOVE-Option für alle Datenbankdateien verwendet werden, um für sie den Pfad der sekundären Datenbank anzugeben.

  • Wenn Sie die Datenbank dateigruppenweise wiederherstellen, stellen Sie sicher, dass Sie die vollständige Datenbank wiederherstellen.

  • Nach dem Wiederherstellen der Datenbank müssen Sie alle seit der letzten wiederhergestellten Datensicherung erstellten Protokollsicherungen wiederherstellen (WITH NORECOVERY).

Empfehlungen

  • Bei eigenständigen Instanzen von SQL Serversollte der Dateipfad (einschließlich des Laufwerkbuchstabens) einer sekundären Datenbank nach Möglichkeit mit dem Pfad der entsprechenden primären Datenbank übereinstimmen. Grund: Wenn beim Erstellen einer sekundären Datenbank die Datenbankdateien verschoben werden, tritt beim späteren Hinzufügen einer Datei auf der sekundären Datenbank möglicherweise ein Fehler auf und bewirkt, dass die sekundäre Datenbank angehalten wird.

  • Vor dem Vorbereiten der sekundären Datenbanken sollten Sie unbedingt geplante Protokollsicherungen auf den Datenbanken in der Verfügbarkeitsgruppe anhalten, bis die Initialisierung sekundärer Replikate abgeschlossen ist.

Sicherheit

Beim Sichern einer Datenbank wird die TRUSTWORTHY-Datenbankeigenschaft auf OFF festgelegt. Deshalb ist TRUSTWORTHY bei einer neu wiederhergestellten Datenbank immer auf OFF festgelegt.

Berechtigungen

Mitglieder der festen Serverrolle sysadmin und der festen Datenbankrollen db_owner und db_backupoperator verfügen standardmäßig über BACKUP DATABASE- und BACKUP LOG-Berechtigungen. Weitere Informationen finden Sie unter BACKUP (Transact-SQL).

Wenn die Datenbank, die wiederhergestellt wird, auf der Serverinstanz nicht vorhanden ist, erfordert die RESTORE-Anweisung CREATE DATABASE-Berechtigungen. Weitere Informationen finden Sie unter RESTORE (Transact-SQL).

Verwendung von SQL Server Management Studio

Hinweis

Wenn die Sicherungs- und Wiederherstellungsdateipfade zwischen der Serverinstanz, auf der das primäre Replikat gehostet wird, und jeder Instanz identisch sind, auf der ein sekundäres Replikat gehostet wird, können Sie sekundäre Datenbanken mithilfe des Assistenten für neue Verfügbarkeitsgruppen, des Assistenten zum Hinzufügen von Replikaten zu Verfügbarkeitsgruppenoder des Assistenten zum Hinzufügen von Datenbanken zu Verfügbarkeitsgruppenerstellen.

So bereiten Sie eine sekundäre Datenbank vor

  1. Wenn Sie noch keine aktuelle Sicherung der primären Datenbank besitzen, erstellen Sie neue vollständige oder differenzielle Datenbanksicherung. Es wird empfohlen, diese Sicherung und nachfolgende Protokollsicherungen auf der empfohlenen Netzwerkfreigabe zu speichern.

  2. Erstellen Sie mindestens eine neue Protokollsicherung der primären Datenbank.

  3. Stellen Sie auf der Serverinstanz, die das sekundäre Replikat hostet, die vollständige Datenbanksicherung der primären (und optional eine differenzielle Sicherung) und anschließend nachfolgende Protokollsicherungen wieder her.

    Aktivieren Sie auf der Seite RESTORE DATABASE-Optionen die Option Datenbank nicht betriebsbereit belassen und kein Rollback für Transaktionen ohne Commit ausführen. Zusätzliche Transaktionsprotokolle können wiederhergestellt werden. (RESTORE WITH NORECOVERY).

    Wenn sich die Dateipfade der primären Datenbank und der sekundären Datenbank unterscheiden, z. B. wenn sich die primäre Datenbank auf Laufwerk F: befindet, bei der Serverinstanz, die das sekundäre Replikat hostet, jedoch das Laufwerk F: fehlt, schließen Sie die MOVE-Option in die WITH-Klausel ein.

  4. Um die Konfiguration der sekundären Datenbank abzuschließen, müssen Sie die sekundäre Datenbank mit der Verfügbarkeitsgruppe verknüpfen. Weitere Informationen finden Sie unter Verknüpfen einer sekundären Datenbank mit einer Verfügbarkeitsgruppe (SQL Server).

Hinweis

Informationen zum Ausführen dieser Sicherungs- und Wiederherstellungsoptionen finden Sie weiter unten in diesem Abschnitt unter Verwandte Sicherungs- und Wiederherstellungsaufgaben

Verwandte Sicherungs- und Wiederherstellungsaufgaben

So erstellen Sie eine Datenbanksicherung

So erstellen Sie eine Protokollsicherung

So stellen Sie Sicherungen wieder her

Verwenden von Transact-SQL

So bereiten Sie eine sekundäre Datenbank vor

Hinweis

Ein Beispiel für diese Prozedur finden Sie weiter oben in diesem Thema Beispiel (Transact-SQL).

  1. Wenn Sie keine aktuelle vollständige Sicherung der primären Datenbank besitzen, stellen Sie eine Verbindung mit der Serverinstanz her, die das primäre Replikat hostet, und erstellen Sie eine vollständige Datenbanksicherung. Es wird empfohlen, diese Sicherung und nachfolgende Protokollsicherungen auf der empfohlenen Netzwerkfreigabe zu speichern.

  2. Stellen Sie auf der Serverinstanz, die das sekundäre Replikat hostet, die vollständige Datenbanksicherung der primären (und optional eine differenzielle Sicherung) und anschließend alle nachfolgenden Protokollsicherungen wieder her. Verwenden Sie WITH NORECOVERY für jeden Wiederherstellungsvorgang.

    Wenn sich die Dateipfade der primären Datenbank und der sekundären Datenbank unterscheiden, z. B. wenn sich die primäre Datenbank auf Laufwerk F: befindet, bei der Serverinstanz, die das sekundäre Replikat hostet, jedoch das Laufwerk F: fehlt, schließen Sie die MOVE-Option in die WITH-Klausel ein.

  3. Wurden seit der erforderlichen Protokollsicherung zusätzliche Protokollsicherungen in der primären Datenbank vorgenommen, müssen Sie diese ebenfalls auf die Serverinstanz kopieren, die das sekundäre Replikat hostet, und alle Protokollsicherungen auf die sekundäre Datenbank anwenden, beginnend mit der frühesten und mithilfe von RESTORE WITH NORECOVERY.

    Hinweis

    Eine Protokollsicherung ist nicht vorhanden, wenn die primäre Datenbank erst kürzlich erstellt wurde und bisher keine Protokollsicherung vorgenommen wurde oder wenn das Wiederherstellungsmodell soeben von SIMPLE in FULL geändert wurde.

  4. Um die Konfiguration der sekundären Datenbank abzuschließen, müssen Sie die sekundäre Datenbank mit der Verfügbarkeitsgruppe verknüpfen. Weitere Informationen finden Sie unter Verknüpfen einer sekundären Datenbank mit einer Verfügbarkeitsgruppe (SQL Server).

Hinweis

Informationen zum Ausführen dieser Sicherungs- und Wiederherstellungsoptionen finden Sie weiter unten in diesem Thema unter Verwandte Sicherungs- und Wiederherstellungsaufgaben

Beispiel für Transact-SQL

Im folgenden Beispiel wird eine sekundäre Datenbank vorbereitet. In diesem Beispiel wird die AdventureWorks2012 -Beispieldatenbank verwendet, in der standardmäßig das einfache Wiederherstellungsmodell verwendet wird.

  1. Damit die AdventureWorks2012 -Datenbank verwendet werden kann, ändern Sie sie so, dass das vollständige Wiederherstellungsmodell verwendet wird.

    USE master;  
GO  
ALTER DATABASE MyDB1   
SET RECOVERY FULL;  
GO

  2. Nach dem Ändern des Wiederherstellungsmodells der Datenbank von SIMPLE in FULL erstellen Sie eine vollständige Sicherung, die zum Erstellen der sekundären Datenbank verwendet werden kann. Da das Wiederherstellungsmodell soeben geändert wurde, wird die Option WITH FORMAT angegeben, um einen neuen Mediensatz zu erstellen. Dies ist hilfreich, um die Sicherungen unter dem vollständigen Wiederherstellungsmodell von vorherigen Sicherungen zu trennen, die unter dem einfachen Wiederherstellungsmodell erstellt wurden. Im Rahmen dieses Beispiels wird die Sicherungsdatei (C:\AdventureWorks2012.bak) auf dem gleichen Laufwerk wie die Datenbank erstellt.

    Hinweis

    Bei einer Produktionsdatenbank sollten Sie die Sicherung stets auf einem separaten Medium erstellen.

    Erstellen Sie auf der Serverinstanz, die das primäre Replikat (INSTANCE01) hostet, folgendermaßen eine vollständige Sicherung der primären Datenbank:

    BACKUP DATABASE MyDB1   
    TO DISK = 'C:\MyDB1.bak'   
    WITH FORMAT  
GO

  3. Kopieren Sie die vollständige Sicherung auf die Serverinstanz, die das sekundäre Replikat hostet.

  4. Stellen Sie mit RESTORE WITH NORECOVERY die vollständige Sicherung auf der Serverinstanz wieder her, auf der das sekundäre Replikat gehostet wird. Der Wiederherstellungsbefehl hängt davon ab, ob die Pfade der primären und sekundären Datenbanken identisch sind.

    • Wenn die Pfade identisch sind, führen Sie Folgendes aus:

      Stellen Sie folgendermaßen die vollständige Sicherung auf dem Computer wieder her, der das sekundäre Replikat hostet:

      RESTORE DATABASE MyDB1   
    FROM DISK = 'C:\MyDB1.bak'   
    WITH NORECOVERY  
GO

    • Wenn die Pfade unterschiedlich sind, führen Sie Folgendes aus:

      Wenn sich der Pfad der sekundären Datenbank vom Pfad der primären Datenbank unterscheidet (z. B. wenn die Laufwerkbuchstaben unterschiedlich sind), ist es für das Erstellen der sekundären Datenbank erforderlich, dass der Wiederherstellungsvorgang eine MOVE-Klausel einschließt.

      Wichtig

      Wenn die Pfadnamen der primären und sekundären Datenbank unterschiedlich sind, können Sie keine Datei hinzufügen. Der Grund hierfür besteht darin, dass die Serverinstanz des sekundären Replikats beim Empfangen des Protokolls für das Hinzufügen einer Datei versucht, die neue Datei unter demselben Pfad abzulegen, der von der primären Datenbank verwendet wird.

      Der folgende Befehl stellt beispielsweise eine Sicherung einer primären Datenbank wieder her, die sich im Datenverzeichnis der Standard-instance von SQL Server 2014, C:\Programme\Microsoft SQL Server\MSSQL12, befindet. MSSQLSERVER\MSSQL\DATA. Der Datenbankwiederherstellungsvorgang muss die Datenbank in das Datenverzeichnis einer Remote-instance von SQL Server 2014 mit dem Namen (AlwaysOn1) verschieben, die das sekundäre Replikat auf einem anderen Clusterknoten hostet. Dort werden die Daten und-Protokolldateien im Verzeichnis C:\Programme\Microsoft SQL Server\MSSQL12. ALWAYSON1\MSSQL\DATA wiederhergestellt. Der Wiederherstellungsvorgang verwendet WITH NORECOVERY, um die sekundäre Datenbank in der wiederhergestellten Datenbank zu belassen.

      RESTORE DATABASE MyDB1  
  FROM DISK='C:\MyDB1.bak'  
 WITH NORECOVERY,   
    MOVE 'MyDB1_Data' TO   
     'C:\Program Files\Microsoft SQL Server\MSSQL12.ALWAYSON1\MSSQL\DATA\MyDB1_Data.mdf',   
    MOVE 'MyDB1_Log' TO  
     'C:\Program Files\Microsoft SQL Server\MSSQL12.ALWAYSON1\MSSQL\DATA\MyDB1_Data.ldf';  
GO

  5. Nach dem Wiederherstellen der vollständigen Sicherung müssen Sie eine Protokollsicherung für die primäre Datenbank erstellen. Die folgende Transact-SQL-Anweisung sichert z. B. das Protokoll in der Sicherungsdatei E:\MyDB1_log.bak:

    BACKUP LOG MyDB1   
  TO DISK = 'E:\MyDB1_log.bak'   
GO

  6. Sie können die Datenbank erst mit dem sekundären Replikat verknüpfen, nachdem Sie die erforderliche Protokollsicherung (und alle nachfolgenden Protokollsicherungen) angewendet haben.

    Mit der folgenden Transact-SQL-Anweisung wird beispielsweise das erste Protokoll aus C:\MyDB1.bak wiederhergestellt:

    RESTORE LOG MyDB1   
  FROM DISK = 'E:\MyDB1_log.bak'   
    WITH FILE=1, NORECOVERY  
GO

  7. Wenn weitere Protokollsicherungen erfolgen, bevor die Datenbank mit dem sekundären Replikat verknüpft wird, müssen Sie mit RESTORE WITH NORECOVERY auch alle Protokollsicherungen nacheinander auf der Serverinstanz wiederherstellen, die das sekundäre Replikat hostet.

    Mit der folgenden Transact-SQL-Anweisung werden beispielsweise zwei zusätzliche Protokolle aus E:\MyDB1_log.bak wiederhergestellt:

    RESTORE LOG MyDB1   
  FROM DISK = 'E:\MyDB1_log.bak'   
    WITH FILE=2, NORECOVERY  
GO  
RESTORE LOG MyDB1   
  FROM DISK = 'E:\MyDB1_log.bak'   
    WITH FILE=3, NORECOVERY  
GO

PowerShell

So bereiten Sie eine sekundäre Datenbank vor

  1. Wenn Sie eine aktuelle Sicherung der primären Datenbank erstellen müssen, ändern Sie das Verzeichnis (cd) zur Serverinstanz, die das primäre Replikat hostet.

  2. Verwenden Sie das Backup-SqlDatabase-Cmdlet, um alle Sicherungen zu erstellen.

  3. Ändern Sie das Verzeichnis (cd) in die Serverinstanz, die das sekundäre Replikat hostet.

  4. Stellen Sie die Datenbank und die Protokollsicherungen aller primären Datenbanken mit dem restore-SqlDatabase-Cmdlet wieder her, und geben Sie dabei den Wiederherstellungsparameter NoRecovery an. Wenn sich die Dateipfade zwischen den Computern unterscheiden, die das primäre Replikat und das sekundäre Zielreplikat hosten, verwenden Sie ebenfalls den Wiederherstellungsparameter RelocateFile.

    Hinweis

    Verwenden Sie das Cmdlet in der SQL Server PowerShell-Umgebung, um die Get-Help Syntax eines Cmdlets anzuzeigen. Weitere Informationen finden Sie unter Get Help SQL Server PowerShell.

  5. Um die Konfiguration der sekundären Datenbank abzuschließen, müssen Sie sie mit der Verfügbarkeitsgruppe verknüpfen. Weitere Informationen finden Sie unter Verknüpfen einer sekundären Datenbank mit einer Verfügbarkeitsgruppe (SQL Server).

Einrichten und Verwenden des SQL Server PowerShell-Anbieters

Beispiele für Sicherung, Wiederherstellungsskript und Befehl

Mit den folgenden PowerShell-Befehlen werden eine vollständige Datenbanksicherung und ein Transaktionsprotokoll auf einer Netzwerkfreigabe gesichert und diese Sicherungen von dieser Freigabe wiederhergestellt. In diesem Beispiel wird davon ausgegangen, dass der Dateipfad, unter dem die Datenbank wiederhergestellt wird, mit dem Dateipfad identisch ist, unter dem die Datenbank gesichert wurde.

# Create database backup  
Backup-SqlDatabase -Database "MyDB1" -BackupFile "\\share\backups\MyDB1.bak" -ServerInstance "SourceMachine\Instance"  
# Create log backup  
Backup-SqlDatabase -Database "MyDB1" -BackupAction "Log" -BackupFile "\\share\backups\MyDB1.trn" -ServerInstance "SourceMachine\Instance"  
# Restore database backup
Restore-SqlDatabase -Database "MyDB1" -BackupFile "\\share\backups\MyDB1.bak" -NoRecovery -ServerInstance "DestinationMachine\Instance"  
# Restore log backup
Restore-SqlDatabase -Database "MyDB1" -BackupFile "\\share\backups\MyDB1.trn" -RestoreAction "Log" -NoRecovery -ServerInstance "DestinationMachine\Instance"

Nachverfolgung: Nach dem Vorbereiten einer sekundären Datenbank

Um die Konfiguration der sekundären Datenbank abzuschließen, müssen Sie die neu wiederhergestellte Datenbank mit der Verfügbarkeitsgruppe verknüpfen. Weitere Informationen finden Sie unter Verknüpfen einer sekundären Datenbank mit einer Verfügbarkeitsgruppe (SQL Server).

Weitere Informationen

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)
BACKUP (Transact-SQL)
RESTORE-Argumente (Transact-SQL)
RESTORE (Transact-SQL)
Problembehandlung bei einem fehlgeschlagenen Vorgang zum Hinzufügen einer Datei (AlwaysOn-Verfügbarkeitsgruppen)