Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Eine bestimmte Datenbank kann gespiegelt oder mittels Log-Shipping übertragen werden; sie kann auch gleichzeitig gespiegelt und mittels Log-Shipping übertragen werden. Um auszuwählen, welcher Ansatz verwendet werden soll, beachten Sie Folgendes:
Wie viele Zielserver benötigen Sie?
Wenn Sie nur eine einzelne Zieldatenbank benötigen, ist die Datenbankspiegelung die empfohlene Lösung.
Wenn Sie mehr als eine Zieldatenbank benötigen, müssen Sie den Protokollversand entweder allein oder mit Datenbankspiegelung verwenden. Die Kombination dieser Ansätze bietet Ihnen die Vorteile der Datenbankspiegelung sowie die Unterstützung für mehrere Ziele, die durch Logversand ermöglicht wird.
Wenn Sie das Wiederherstellen des Logs in der Zieldatenbank verzögern müssen (in der Regel zum Schutz vor logischen Fehlern), führen Sie den Protokollversand allein oder zusammen mit der Datenbankspiegelung durch.
In diesem Thema werden Überlegungen zum Kombinieren des Protokollversands und der Datenbankspiegelung erläutert.
Hinweis
Eine Einführung in diese Technologien finden Sie unter Database Mirroring (SQL Server) und Informationen zum Protokollversand (SQL Server).For introductions to these technologies, see Database Mirroring (SQL Server) and About Log Shipping (SQL Server)
Kombinieren von Logversand und Datenbankspiegelung
Die Hauptdatenbank in einer Spiegelungssitzung kann auch als primäre Datenbank in einer Protokollversandkonfiguration fungieren oder umgekehrt, da die Sicherungsfreigabe für den Protokollversand intakt ist. Die Datenbankspiegelungssitzung wird in jedem Betriebsmodus ausgeführt, unabhängig davon, ob synchron (mit Transaktionssicherheit auf FULL festgelegt) oder asynchron (mit Transaktionssicherheit auf OFF festgelegt).
Hinweis
Um die Datenbankspiegelung für eine Datenbank zu verwenden, ist das vollständige Wiederherstellungsmodell immer erforderlich.
In der Regel wird beim Kombinieren des Protokollversands und der Datenbankspiegelung die Spiegelungssitzung vor dem Protokollversand eingerichtet, obwohl dies nicht erforderlich ist. Anschließend wird die aktuelle Prinzipaldatenbank zusammen mit einer oder mehreren sekundären Remotedatenbanken als primäre Protokollversanddatenbank (Prinzipal-/Primärdatenbank) konfiguriert. Außerdem muss die Spiegeldatenbank als primäre Protokollversand-Datenbank (Spiegel-/Primärdatenbank) konfiguriert werden. Sekundäre Protokollversanddatenbanken sollten sich auf anderen Serverinstanzen als dem Prinzipal- oder Spiegel-/Primärserver befinden.
Hinweis
Die Einstellungen für die Groß-/Kleinschreibung der Server, die am Protokollversand beteiligt sind, sollten übereinstimmen.
Während einer Protokollversandsitzung erstellen Sicherungsaufträge in der primären Datenbank Protokollsicherungen in einem Sicherungsordner. Von dort aus werden die Sicherungen durch die Kopieraufträge der sekundären Server übertragen. Damit die Sicherungsaufträge und Kopieraufträge erfolgreich ausgeführt werden können, müssen sie Zugriff auf den Sicherungsordner für den Protokollversand haben. Um die Verfügbarkeit des primären Servers zu maximieren, empfehlen wir, den Sicherungsordner an einem freigegebenen Sicherungsspeicherort auf einem separaten Hostcomputer einzurichten. Stellen Sie sicher, dass alle Protokollversandserver, einschließlich der Spiegel-/Primärserver, auf den freigegebenen Sicherungsspeicherort (als Sicherungsfreigabe bezeichnet) zugreifen können.
Damit der Protokollversand fortgesetzt werden kann, nachdem die Datenbankspiegelung fehlschlägt, müssen Sie den Spiegelserver auch als primärer Server konfigurieren, indem Sie dieselbe Konfiguration verwenden, die Sie für die primäre Datenbank in der Prinzipaldatenbank verwenden. Die Spiegeldatenbank befindet sich im Wiederherstellungszustand, was verhindert, dass die Sicherungsprozesse das Protokoll der Spiegeldatenbank sichern. Dadurch wird sichergestellt, dass die Spiegel-/Primärdatenbank die Prinzipal-/Primärdatenbank nicht beeinträchtigt, deren Protokollsicherungen derzeit von sekundären Servern kopiert werden. Um fehlerhafte Warnungen zu verhindern, protokolliert der Sicherungsauftrag nach Durchführung des Sicherungsauftrags auf der Spiegel-/Primärdatenbank eine Nachricht in der Tabelle "log_shipping_monitor_history_detail", und der Agentauftrag gibt einen Erfolgsstatus zurück.
Die Spiegel-/Primäre Datenbank ist in der Protokollversandsitzung inaktiv. Wenn die Spiegelung jedoch fehlschlägt, wird die frühere Spiegeldatenbank als Prinzipaldatenbank online. Zu diesem Zeitpunkt wird diese Datenbank auch als primäre Datenbank für den Protokollversand aktiv. Die Sicherungsaufträge für den Protokollversand, die zuvor nicht den Protokollversand auf dieser Datenbank durchführen konnten, beginnen nun mit der Fortsetzung des Protokollversands. Umgekehrt bewirkt ein Failover, dass die frühere Prinzipal-/Primärdatenbank zur neuen Spiegel-/Primärdatenbank wird und der Wiederherstellungszustand eintritt, und Sicherungsaufträge in dieser Datenbank werden nicht mehr im Sicherungsprotokoll gespeichert.
Hinweis
Im Falle eines automatischen Failovers wird die Spiegelrolle übernommen, wenn die frühere Hauptdatenbank wieder in die Spiegelungssitzung eintritt.
Zur Ausführung im Hochsicherheitsmodus mit automatischem Failover wird die Spiegelungssitzung mit einer zusätzlichen Serverinstanz konfiguriert, die als Zeuge bezeichnet wird. Wenn die Hauptdatenbank aus irgendeinem Grund verloren geht, nachdem die Datenbank synchronisiert wurde und der Spiegelserver und der Zeugenserver weiterhin miteinander kommunizieren können, erfolgt ein automatisches Failover. Ein automatisches Failover bewirkt, dass der Spiegelserver die Rolle des Hauptservers übernimmt und seine Datenbank als Primärdatenbank online schaltet. Wenn der Speicherort für Sicherungen im Protokollversand vom neuen Hauptserver zugänglich ist, beginnen die Sicherungsaufträge, Protokollsicherungen an diesen Ort zu senden. Der synchrone Modus der Datenbankspiegelung garantiert, dass die Protokollkette von einem Spiegelfailover nicht betroffen ist und dass nur gültige Protokolle wiederhergestellt werden. Die sekundären Server kopieren weiterhin Protokollsicherungen, ohne zu wissen, dass eine andere Serverinstanz zum primären Server geworden ist.
Bei verwendung eines lokalen Protokollversandmonitors sind keine besonderen Überlegungen erforderlich, um dieses Szenario zu berücksichtigen. Informationen zur Verwendung einer Remoteüberwachungsinstanz mit diesem Szenario finden Sie weiter unten in diesem Thema unter "Auswirkungen der Datenbankspiegelung auf eine Remoteüberwachungsinstanz".
Umschaltung von der Hauptdatenbank zur Spiegeldatenbank
Die folgende Abbildung zeigt, wie der Protokollversand und die Datenbankspiegelung zusammenarbeiten, wenn die Spiegelung im Hochsicherheitsmodus mit automatischem Failover ausgeführt wird. Zunächst ist Server_A sowohl der Prinzipalserver für die Spiegelung als auch der primäre Server für den Protokollversand. Server_B ist der Spiegelserver und ist auch als primärer Server konfiguriert, der derzeit inaktiv ist. Server_C und Server_D sind sekundäre Logversand-Server. Um die Verfügbarkeit der Protokollversandsitzung zu maximieren, befindet sich der Sicherungsspeicherort in einem Freigabeverzeichnis auf einem separaten Hostcomputer.
Nach einem Spiegelungsfailover ist der primäre Servername, der auf dem sekundären Server definiert ist, unverändert. .
Auswirkungen der Datenbankspiegelung auf eine Remoteüberwachungsinstanz
Wenn der Protokollversand mit einer Remoteüberwachungsinstanz verwendet wird, wirkt sich die Kombination aus Protokollversandsitzung und Datenbankspiegelung auf die Informationen in den Monitortabellen aus. Die Informationen zur Primäreinheit sind eine Kombination aus der Konfiguration an der Haupteinheit und der Überwachung, die auf jeder sekundären Seite konfiguriert ist.
Um die Überwachung so nahtlos wie möglich zu halten, sollten Sie bei Verwendung eines Fernmonitors den ursprünglichen primären Namen angeben, wenn Sie den Primärmonitor am Sekundärmonitor konfigurieren. Dieser Ansatz erleichtert auch die Änderung der Protokollversandkonfiguration vom Microsoft SQL Server-Agent. Weitere Informationen zur Überwachung finden Sie unter Überwachen des Protokollversands (Transact-SQL).
Einrichten von Datenbankspiegelung und Protokolldatei-Versand zusammen
Um die Datenbankspiegelung und den Protokollversand zusammen einzurichten, sind die folgenden Schritte erforderlich:
Stellen Sie Sicherungen der Primärdatenbank mit NORECOVERY auf einer anderen Serverinstanz wieder her. Diese wird später als Spiegeldatenbank für die Primärdatenbank verwendet. Weitere Informationen finden Sie unter Vorbereiten einer Spiegeldatenbank auf die Spiegelung (SQL Server).
Einrichten der Datenbankspiegelung. Weitere Informationen finden Sie unter Einrichten einer Datenbankspiegelungssitzung mit der Windows-Authentifizierung (SQL Server Management Studio) oder einrichten der Datenbankspiegelung (SQL Server).
Stellen Sie Sicherungen der Prinzipal-/Primärdatenbank in anderen Serverinstanzen wieder her, die später als sekundäre Protokollversanddatenbanken für die primäre Datenbank verwendet werden sollen.
Richten Sie den Protokollversand in der Prinzipaldatenbank als primäre Datenbank für eine oder mehrere sekundäre Datenbanken ein.
Sie sollten eine einzelne Freigabe als Sicherungsverzeichnis (eine Sicherungsfreigabe) einrichten. Dadurch wird sichergestellt, dass sicherungsaufträge nach dem Wechseln zwischen prinzipal- und spiegelservern weiterhin in dasselbe Verzeichnis wie zuvor schreiben. Eine bewährte Methode besteht darin, sicherzustellen, dass sich diese Freigabe auf einem anderen physischen Server befindet als die Server, auf denen die Datenbanken gehostet werden, die an spiegelungs- und Protokollversand beteiligt sind.
Weitere Informationen finden Sie unter Konfigurieren des Protokollversands (SQL Server).
Manuelles Umschalten vom Primär zum Spiegel.
So führen Sie ein manuelles Failover aus:
Richten Sie den Protokollversand für den neuen Hauptserver (zuvor Spiegel) als primäre Datenbank ein.
Von Bedeutung
Führen Sie keine Einrichtung von einem Sekundärgerät durch.
Sie müssen dieselbe Sicherungsfreigabe verwenden, die Sie in Schritt 4 genutzt haben.
Die Transaktionsprotokollversandschnittstelle in SQL Server Management Studio unterstützt nur eine primäre Datenbank pro Protokollversandkonfiguration. Daher müssen Sie gespeicherte Prozeduren verwenden, um den neuen Prinzipal als primär einzurichten.
Führen Sie ein weiteres manuelles Failover aus, um zum ursprünglichen Prinzipal zurückzukehren.