Skip to main content

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

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.

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.

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

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.

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.

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.

A: Ja. Microsoft empfiehlt dies jedoch nicht.

 

Netzwerk

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.

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.

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.

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

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.

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.

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.

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.

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