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.
Gilt für:
SQL Server
Während eines Rollenwechsels ist der Zeitraum, für den die Datenbankspiegelung außer Dienst ist, abhängig von der Art des Rollenwechsels und vom Grund für den Rollenwechsel.
Beim automatischen Failover tragen zwei Faktoren zur Dauer der Dienstunterbrechung bei: zum einen die benötigte Zeit, bis der Spiegelserver erkennt, dass in der Prinzipalserverinstanz ein Fehler aufgetreten ist, also die Fehlererkennungszeit, zum anderen die Zeit, die für das Failover der Datenbank benötigt wird, also die Failoverzeit.
Bei einem erzwungenen Servicebetrieb hängen das Erkennen des Fehlers und die Reaktion darauf, obwohl ein Fehler aufgetreten ist, von der menschlichen Reaktionsfähigkeit ab. Das Schätzen der potenziellen Dienstunterbrechung ist jedoch beschränkt auf das Schätzen der Zeit, die der Spiegelserver für den Rollenwechsel benötigt, nachdem der Befehl für den erzwungenen Dienst ausgegeben wurde.
Hinweis
Um die zum Erkennen bestimmter Bedingungen, z. B. einiger Fehlertypen, erforderliche Zeit zu reduzieren, können Sie Warnungen für diese Bedingungen definieren.
Bei einem manuellen Failover wird nur die für das Failover der Datenbank erforderliche Zeit nach dem Failoverbefehl ausgegeben.
Fehlererkennung
Die Zeit, die das System zum Erkennen eines Fehlers benötigt, hängt von der Art des Fehlers ab. Beispielsweise wird ein Netzwerkfehler nahezu sofort bemerkt, während es 10 Sekunden dauert, um festzustellen, dass ein Server nicht reagiert (bei Standardtimeout).
Informationen zu Fehlern, die während einer Datenbank-Spiegelungssitzung zu Problemen führen können, und zur Timeouterkennung im Modus für hohe Sicherheit mit automatischem Failover finden Sie unter Mögliche Fehler während der Datenbankspiegelung.
Failoverzeit
Die Failoverzeit setzt sich hauptsächlich aus der Zeit zusammen, die der frühere Spiegelserver benötigt, um die noch in seiner Wiederholungswarteschlange befindlichen Protokolle vorwärtszurollen, plus einer kurzen zusätzlichen Zeit (Informationen dazu, wie der Spiegelserver Protokolldatensätze verarbeitet, finden Sie unter Datenbankspiegelung (SQL Server)). Informationen zum Abschätzen der Failoverzeit finden Sie weiter unten in diesem Thema unter „Abschätzen Ihrer Failover-Redo-Rate“.
Wichtig
Wenn ein Failover während einer Transaktion auftritt, in der ein Index oder eine Tabelle erstellt und anschließend geändert wird, kann das Failover mehr Zeit als gewöhnlich in Anspruch nehmen. So kann ein Failover während der folgenden Folge von Operationen die Failoverzeit verlängern: BEGIN TRANSACTION, CREATE INDEX in einer Tabelle und SELECT INTO für die Tabelle. Die Möglichkeit einer erhöhten Failoverzeit während einer solchen Transaktion bleibt bis zu ihrem Abschluss durch eine COMMIT TRANSACTION- oder ROLLBACK TRANSACTION-Anweisung bestehen.
Redo-Warteschlange
Um ein Rollforward für die Datenbank auszuführen, müssen die Protokolldatensätze angewandt werden, die sich derzeit in der Wiederholungswarteschlange auf dem Spiegelserver befinden. Die Wiederholungswarteschlange besteht aus den Protokolldatensätzen, die auf den Datenträger des Spiegelservers geschrieben wurden, für die aber noch kein Rollforward in der Spiegeldatenbank ausgeführt wurde.
Die Failoverzeit für die Datenbank hängt davon ab, wie schnell der Spiegelserver die Protokolle in der Wiederherstellungswarteschlange vorwärts verarbeiten kann, was wiederum in erster Linie von der Systemhardware und der aktuellen Auslastung bestimmt wird. Eine Prinzipaldatenbank kann potenziell so stark ausgelastet sein, dass der Prinzipalserver den Protokollversand zum Spiegelserver wesentlich schneller als ein Rollforward des Protokolls ausführen kann. In dieser Situation kann das Failover viel Zeit in Anspruch nehmen, während der Spiegelserver ein Rollforward für das Protokoll in der Wiederholungswarteschlange ausführt. Um die aktuelle Größe der Wiederholungswarteschlange festzustellen, verwenden Sie den Leistungsindikator Wiederholungswarteschlange im Datenbankspiegelungs-Leistungsobjekt. Weitere Informationen finden Sie unter SQL Server, Database Mirroring Object.
Schätzen der Rollforwardrate für das Failover
Sie können die erforderliche Zeitdauer für ein Rollforward von Protokolldatensätzen (die Rollforwardrate) mithilfe einer Testkopie der Produktionsdatenbank messen.
Die Methode zur Schätzung der Dauer des Rollforwardvorgangs während eines Failovers hängt von der Anzahl der Threads ab, die der Spiegelserver während der Redo-Phase verwendet. Die Anzahl von Threads hängt von folgendem Faktoren ab:
In der SQL Server Standard-Edition verwendet der Spiegelserver immer einen einzigen Thread für das Rollforward der Datenbank.
In der SQL Server Enterprise-Edition verwenden Spiegelserver auf Computern mit weniger als fünf CPUs ebenfalls nur einen einzigen Thread. Bei mindestens fünf CPUs verteilt ein Spiegelserver während eines Failovers die Rollforwardvorgänge auf mehrere Threads (dies wird als paralleles Rollforwardbezeichnet). Paralleles Redo ist so optimiert, dass pro vier CPUs ein Thread verwendet wird.
Schätzen der Single-Thread-Redo-Rate
Bei einem Rollforward mit einem einzelnen Thread dauert das Rollforward der Spiegeldatenbank während des Failovers etwa genauso lange wie eine Wiederherstellung einer Protokollsicherung benötigt, um ein Rollforward für den gleichen Protokollumfang auszuführen. Um die Failoverzeit zu schätzen, erstellen Sie eine Testdatenbank in der Umgebung, in der Sie die Spiegelung ausführen möchten. Anschließend erstellen Sie eine Protokollsicherung von der Produktionsdatenbank. Um die Rollforwardrate für diese Protokollsicherung zu schätzen, messen Sie, wie lange Sie benötigen, um die Protokollsicherung mit WITH NORECOVERY in der Testdatenbank wiederherzustellen.
Sobald Sie die Rollforwardrate des Spiegelservers kennen, können Sie den Zeitaufwand für das Failover der Datenbank zu einem bestimmten Zeitpunkt schätzen, indem Sie den aktuellen Protokollumfang auf dem Spiegelserver, für den ein Rollforward ausgeführt werden muss (gemessen mithilfe des Wiederholungswarteschlange -Leistungsindikators) durch die Rollforwardrate dividieren. Unter normalen Bedingungen ist die Redo Queue klein oder nahezu null, wenn der Spiegelserver mit der Last des Prinzipalservers Schritt halten kann, und ein Failover dauert nur wenige Sekunden.
Schätzung der parallelen Redo-Rate
In der SQL Server Enterprise-Edition ist das parallele Redo so optimiert, dass pro vier CPUs ein Thread verwendet wird. Um die Rollforwardzeit für das parallele Rollforward zu schätzen, stellt der Zugriff auf ein laufendes Testsystem genauere Ergebnisse bereit als lediglich eine Testdatenbank. Erhöhen Sie beim Überwachen der Wiederholungswarteschlange auf dem Spiegelserver die Arbeitsauslastung auf dem Prinzipalserver. Im Normalbetrieb liegt die Redo-Warteschlange nahe null. Erhöhen Sie die Last auf dem primären Server, bis die Redowarteschlange kontinuierlich anwächst; das System hat dann seine maximale Redo-Rate erreicht, und der Leistungsindikator Redo Bytes/sec stellt an diesem Punkt die maximale Redo-Rate dar. Weitere Informationen finden Sie unter SQL Server, Database Mirroring Object.
Abschätzung des Dienstausfalls beim automatischen Failover
In der folgende Abbildung wird veranschaulicht, wie die Fehlererkennung und die Failoverzeit zur Gesamtzeit beitragen, die zum Abschließen eines automatischen Failovers auf Partner_Berforderlich ist. Das Failover benötigt Zeit zum Ausführen des Rollforwards für die Datenbank (die Rollforwardphase) sowie zusätzlich ein wenig Zeit, um die Datenbank online zu schalten. In der Rollbackphase wird ein Rollback für Transaktionen ohne Commit ausgeführt wird. Diese Phase erfolgt, nachdem die Prinzipaldatenbank online geschaltet wurde, und wird nach dem Failover fortgesetzt. Die Datenbank ist während der Rollbackphase verfügbar.
