Skip to main content
TechNet

Häufig gestellte Fragen und Antworten zur Datenbankspiegelung

Dieses Dokument enthält Antworten auf häufig gestellt Fragen zum Thema Datenbankspiegelung unter SQL Server 2005.

Auf dieser Seite

Verfügbarkeit der DatenbankspiegelungVerfügbarkeit der Datenbankspiegelung

ClusterCluster

NetzwerkNetzwerk

AllgemeinesAllgemeines

Verfügbarkeit der Datenbankspiegelung

F: Warum ist die Datenbankspiegelung erst nach der Veröffentlichung von SQL Server 2005 verfügbar?

A: Die Datenbankspiegelung bleibt eines der Vorzeigefeatures von SQL Server 2005 und wird im Moment für einige geschäftskritische interne Systeme bei Microsoft bereitgestellt (zum Beispiel unser SAP-System). Das Feedback unserer Kunden hat gezeigt, dass SQL Server 2005 für einige der größten und kritischsten Systeme der Welt genutzt werden wird. Daher muss ein Hochverfügbarkeitsfeature wir die Datenbankspiegelung umfassend überprüft werden.

Wir haben uns deshalb dazu entschieden, dass das Feature noch länger durch bestimmte Kunden getestet werden muss, bevor es allgemein verfügbar wird. Es ist bereits vollständig und hat umfangreiche interne Tests bestanden. Wir wollen es im ersten Halbjahr 2006 zur Verfügung stellen.

F: Bedeutet das, dass SQL Server 2005 nicht für Unternehmen geeignet ist?

A: Nein. Wir stellen auch weiterhin fest, dass einige der wichtigsten Systeme der Welt mit SQL Server umgesetzt werden (siehe auch der Winter Corporation report - engl.). Zusätzlich zu einem 19,5 Terabyte-System, das als größtes Datawarehouse-System der Welt gilt, arbeiten drei der größten Online Transaction Processing (OLTP) Systeme der Welt und zwei der weltgrößten Datawarehouse-System mit SQL Server.

F: Welcher Support steht für die Datenbankspiegelung zur Verfügung?

A: Die Microsoft-Supportrichtlinien finden keine Anwendung auf das Datenbankspiegelungsfeature von SQL Server 2005. Die Datenbankspiegelung ist im Moment standardmäßig deaktiviert, kann aber für Evaluierungszwecke aktiviert werden. Die Datenbankspiegelung sollte nicht in Produktivumgebungen eingesetzt werden. Microsoft unterstützt keine Datenbanken oder Anwendungen, die eine Datenbankspiegelung verwenden. Die entsprechende Dokumentation ist nur zu Evaluierungszwecken in SQL Server 2005 enthalten. Die Dokumentationsrichtlinien für SQL Server 2005 Support and Upgrade gelten nicht für die Dokumentation zur Datenbankspiegelung.

 

Cluster

F: Kann ich die Spiegelung und Cluster nutzen?

A: Ja. Sie können eine Datenbank von einem virtuellen Server auf einen anderen virtuellen Server in einem anderen Cluster spiegeln. Sie können sogar von einem virtuellen Server auf einen anderen virtuellen Server im gleichen Cluster spiegeln (allerdings empfiehlt Microsoft dieses Verfahren nicht).

Wenn Sie sowohl die Spiegelung als auch Cluster nutzen sollten Ihnen klar sein, dass beide getrennt voneinander arbeiten. Die Spiegelung weiß nicht von Clustern und die Cluster wissen nicht von der Spiegelung. Wenn ein Knoten fehlschlägt, führt die Spiegelung möglicherweise einen Failover durch, bevor dies der Cluster tut. Daher wird der andere Knoten eines Clusters dann als Spiegel verwendet, wenn er wieder online ist. Wenn Sie Cluster in Ihrer Produktivumgebung problemlos einsetzen, sollte auch die zusätzliche Spiegelung funktionieren.

F: Wie kann ich dafür sorgen, dass der Failover für die Spiegelung erst nach dem Failover für den Cluster durchgeführt wird?

A: Unter Microsoft SQL Server 2005 gibt es keine Garantie dafür, dass der Failover für die Spiegelung nach dem Failover für den Cluster durchgeführt wird.

F: Kann sich ein Zeugenserver in einem Cluster befinden?

A: Ja. Allerdings ist dies nicht erforderlich.

Bedenken Sie, dass Zeugenserver nicht die wichtigsten Mitglieder einen Spiegelsitzung sind. Der Zeugenserver beantwortet nur die Frage "Wenn kannst Du sehen?". Wenn die Partnerserver sich nicht sehen können, nehmen Sie Kontakt mit dem Zeugenserver auf, um zu sehen, ob dieser den anderen Partner sehen kann oder um zu bestätigen, dass ein Fehler aufgetreten ist.

F: Kann ich mehrere virtuelle Server in einem Cluster spiegeln?

A: Ja. Microsoft empfiehlt dies jedoch nicht.

 

Netzwerk

F: Wie zuverlässig muss mein Netzwerk sein?

A: Wenn Sie den Betriebsmodus Hohe Verfügbarkeit verwenden, hängt die Erkennung eines Failovers von der Netzwerkverbindung ab. Wenn es ein Problem im Netzwerk gibt, kann es zu einem Failover kommen oder der Zugriff wird verweigert (aufgrund der Quorum-Anforderungen). Auch wenn die Spiegelung korrekt arbeitet, kann es zur Verweigerung des Zugriffs kommen - und dies, obwohl die Datenbank mit einem normalen Standardserver korrekt funktionieren würde. Um ein Verständnis dafür zu entwickeln, wie das System ohne ein automatisches Failover arbeitet, versuchen Sie die Datenbankspiegelung eine Zeitlang ohne Zeugenserver einzusetzen.

F: Wie hoch ist die langsamste Netzwerkgeschwindigkeit, bei der ich noch eine Spiegelung einsetzen kann?

A: Es gibt keine exakten Einschränkungen für den Einsatz der Spiegelung. Die Netzwerkverbindungen zwischen den Servern sind jedoch ein kritischer Faktor. Es sollte sich generell um ein dediziertes Netzwerk mit hoher Qualität und hoher Bandbreite handeln. Als grobe Richtlinie sollte die Netzwerkbandbreite drei Mal so hoch wie die Generierungsrate des Protokolls sein.

F: Wie lege ich einen speziellen Netzwerkadapter nur für die Spiegelung fest?

A: Weisen Sie dem Netzwerkadapter, den Sie für die Spiegelung verwenden möchten, eine bestimmte IP-Adresse zu. Weisen sie der IP-Adresse dann einen bestimmten Namen zu. Nutzen Sie diesen Namen bei der Einrichtung der Datenbankspiegelung.

F: Was passiert, wenn ich ein COMMIT durchführe und ein Failover durchgeführt wird, bevor ich eine Antwort erhalte? Es bekommt dann zu einem Connection Closed-Fehler.

A: Ein COMMIT-Statement kann grundsätzlich zu drei möglichen Ergebnissen führen:

  • Acknowledgement - die Transaktion ist garantiert durchgeführt.
  • Rollback - die Transaktion ist garantiert nicht durchgeführt.
  • Connection Closed - es kann nicht festgestellt werden, ob die Transaktion durchgeführt wurde oder nicht. Der Client muss die Datenbank erneut abfragen.

Im Fall der Datenbankspiegelung ändert sich an dieser Situation nichts. Der einzige Unterschied ist, dass die Datenbank schnell über einen anderen Server wieder verfügbar ist. Wenn der Commit-Protokolleintrag sich nicht vor dem Failover auf dem Spiegelserver befindet, wurde der Client nie darüber informiert, dass ein COMMIT-Statement aufgetreten ist. Daher ist es nicht von Bedeutung, ob der Protokolleintrag auf dem ursprünglichen Prinzipal auf die Festplatte geschrieben wurde oder nicht.

 

Allgemeines

F: Warum arbeiten einige Technologien nach einem Failover nicht nahtlos weiter?

A: In der Vergangenheit war die Sicherung und Wiederherstellung auf einen anderen Server oder der Failover für Log-Shipping im Allgemeinen ein schwieriger Prozess. Einige Kunden konnten eine Datenbank nicht korrekt auf einen anderen Server verschieben oder dieser Vorgang dauerte sehr lang. Daher wurde dieses Verfahren nur selten eingesetzt. Beim Verschieben einer Datenbank auf einen anderen Server haben die folgenden Features nicht "reibungslos" funktioniert:

  • Replikation
  • Distributed Transaction Coordinator (DTC)
  • Änderungsbenchrichtigung
  • Logins
  • Jobs
  • Informationen, die in anderen Datenbanken gespeichert waren (zum Beispiel in msdb oder der Masterdatenbank):
    • Datenbankeigenschaft TRUSTWORTHY
    • Jobs
    • Logins
    • In der Systemdatenbank gespeicherte Prozeduren
  • Verwenden von dreiteiligen Namen für den Zugriff auf Datenbanken auf dem gleichen Server
  • Mehrere Datenbanken
  • Log Shipping
  • Performance

Mit der Datenbankspiegelung ist das Verschieben von Datenbanken auf andere Server nun deutlich einfacher geworden.

F: Gibt der Zeugenserver den Partnerservern Anweisungen, oder überwacht er sie?

A: Nein. Der Zeugenserver beantwortet nur die Frage "Wenn kannst Du sehen?". Wenn die Partnerserver sich nicht sehen können, nehmen Sie Kontakt mit dem Zeugenserver auf, um zu sehen, ob diese den anderen Partner sehen kann oder um zu bestätigen, dass ein Fehler aufgetreten ist. Der Zeugenserver ist kein Single Point of Failure.

F: Wie kann der Spiegel einen Rückstand aufholen, nachdem er einige Zeit nicht online war?

A: Wenn Safety = FULL ist, der Spiegel jedoch nicht den Status SYNCHRONIZED hat, dann warten Transaktionen nicht auf COMMIT-Statement. Der Spiegel ist entweder im Status SUSPENDED, Offline oder arbeitet einen Rückstand auf (SYNCHRONIZING). Beim Aufholen eines Rückstandes passiert folgendes:

  1. Der Prinzipal sendet das aktuelle Ende des Protokolls an den Spiegel.
  2. Der Prinzipal stellt fest, wie viele weitere Protokolleinträge gesendet werden.
  3. Wenn der verbleibende Teil des Protokolls weniger als 1 MB ist, wird der Status auf SYNCHRONIZED gesetzt und alle COMMIT-Statements warten auf eine Rückmeldung des Spiegels. Der Rückstand ist aufgeholt.
  4. Wenn der verbleibende Teil über 1 MB liegt, fügt der Prinzipal allen Transaktionen eine Verzögerung von mehreren Millisekunden hinzu.
  5. Der Prinzipal fährt mit Schritt 1 fort und wiederholt den Prozess.
    Jedes Mal, wenn der Prinzipal bei Schritt 4 angelangt ist, wird die Verzögerung erhöht - bis zu einem Maximum von 100 Millisekunden. Da sich die Verzögerung mehr und mehr erhöht, wird der Prinzipal immer mehr ausgebremst - so lange, bis der Spiegel in Schritt 2 den Rückstand aufgeholt hat.
F: Wo sollte sich der Zeugenserver befinden, wenn sich die Partner an verschiedenen Standorten befinden?

A: Der Standort des Zeugenserver hängt (wie der Standort und die Konfiguration aller Server) davon ab, welche Probleme zu erwarten sind und welche Fehler verhindert werden sollen. Im Idealfall sollten sich alle drei Server an Standorten mit qualitativ hochwertigen Diensten und Personal befinden.

Wo sollte sich der Zeugenserver bei zwei Rechenzentren befinden? Beim Spiegel oder beim Prinzipal? Die Antwort auf diese Frage hängt davon ab, wo ein Ausfall eher zu erwarten ist. Wenn ein Fehler am Standort des Prinzipals wahrscheinlicher ist, sollte sich der Zeugenserver beim Spiegel befinden. Allgemein sollte sich der Zeugenserver jedoch eher beim Prinzipal befinden.

F: Wo befinden Sich "Send Queue" und "Redo Queue"?

A: Die Send Queue ist Teil des Transaktionsprotokolls und wird auf dem Prinzipalserver geschrieben. Sie wird nicht an den Spiegel gesendet. Die Redo Queue ist Teil des Transaktionsprotokolls, das auf dem Spiegelserver geschrieben wird.

 

Zum SeitenanfangZum Seitenanfang