Einschätzen der Unterbrechung des Diensts während des Rollenwechsels (Datenbankspiegelung)

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.

• Obwohl ein Fehler aufgetreten ist, ist bei einem Erzwingen des Diensts das Erkennen des Fehlers und das Reagieren darauf abhängig von der menschlichen Reaktionszeit. 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 ein Rollforward für Protokolle in der Wiederholungswarteschlange auszuführen, sowie einem kurzen zusätzlichen Zeitraum (weitere Informationen zur Verarbeitung von Protokolldatensätzen durch den Spiegelserver finden Sie unter Datenbankspiegelung (SQL Server)). Informationen zum Schätzen der Failoverzeit finden Sie unter "Schätzen der Rollforwardrate für das Failover" weiter unten in diesem Thema.

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.

Wiederholungswarteschlange

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 ein Rollforward für das Protokoll in der Wiederholungswarteschlange ausführen kann. Dies wird wiederum in erster Linie durch die Systemhardware und die aktuelle Arbeitsauslastung bestimmt. 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 zum Schätzen der Rollforwardzeit hängt von der Anzahl von Threads ab, die vom Spiegelserver während der Rollforwardphase verwendet werden. 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). Das parallele Rollforward ist für die Verwendung eines Threads für jeweils vier CPUs optimiert.

Schätzen der Rollforwardrate für Rollforwards mit einem einzelnen Thread

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 verwenden Sie eine Protokollsicherung aus 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. Wenn der Spiegelserver unter normalen Bedingungen mit der Arbeitsauslastung vom Prinzipalserver Schritt halten kann, ist der Wert für Wiederholungswarteschlange niedrig oder liegt bei Null, und ein Failover dauert deshalb nur wenige Sekunden.

Schätzen der Rollforwardrate für parallele Rollforwards

In der SQL Server Enterprise-Edition ist die parallele Wiederholung für die Verwendung eines Threads für jeweils vier CPUs optimiert. 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 der Wert der Wiederholungswarteschlange bei Null. Erhöhen Sie die Arbeitsauslastung auf dem Prinzipalserver, bis die Größe der Wiederholungswarteschlange ständig zunimmt. Das System hat dann seine maximale Rollforwardrate erreicht, und der Bytes wiederholen/Sekunde -Leistungsindikator repräsentiert dann die maximale Rollforwardrate. Weitere Informationen finden Sie unter SQL Server, Database Mirroring Object.

Schätzen der Dienstunterbrechung 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.

Weitere Informationen

Database Mirroring Operating Modes
Rollenwechsel während einer Datenbank-Spiegelungssitzung (SQL Server)
Überwachen der Datenbankspiegelung (SQL Server)