Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SAP Sybase SQL Anywhere 16.0 (Deutsch) » SQL Anywhere Server - Datenbankadministration » Hochverfügbarkeit und Scale-Out-Systeme mit Schreibschutz » Datenbankspiegelung » Hinweise zur Anwendungsentwicklung bei Datenbankspiegelung

 

Anforderungen und Einschränkungen für Datenbankspiegelungssysteme

Bei der Datenbankspiegelung gibt es keine besonderen Hardware- oder Software-Anforderungen, und die Datenbankserver können an örtlich verschiedenen Standorten ausgeführt werden. Datenbankserver, die an einem Datenbankspiegelungssystem teilnehmen, können gespiegelte wie auch ungespiegelte Datenbanken ausführen. Überdies kann der Arbiterserver der Arbiter bei mehreren Datenbankspiegelungssystemen sein.

Bei der Verwendung der Datenbankspiegelung gelten die folgenden Anforderungen und Einschränkungen:

  • Netzwerk-Datenbankserver erforderlich   Da eine Spiegelung Netzwerkkommunikation zwischen den Datenbankservern beinhaltet, müssen Sie den Netzwerk-Datenbankserver (dbsrv16) verwenden. Der Personal Server kann nicht verwendet werden.

    Alle Datenbankserver in einem Datenbankspiegelungssystem müssen dieselbe Minor Release verwenden, können jedoch unterschiedliche Supportpakete ausführen.

  • TCP/IP erforderlich   Nur TCP/IP-Verbindungen sind zwischen gespiegelten Servern zulässig.

  • Transaktionslog-Einschränkungen   Bei Verwendung der Datenbankspiegelung können Sie das Transaktionslog auf dem Primärserver nicht kürzen, weil dies zum Verlust von Transaktionen führen kann. Sie können das Transaktionslog beliebig oft umbenennen. Weitere Hinweise zur Verwendung von Ereignissen zum Verwalten von Transaktionslogs in Spiegelungssystemen finden Sie unter Verwaltung von Transaktionslogdateien in einem Datenbankspiegelungssystem.

  • Webserver   Bei gleichzeitiger Verwendung von SQL Anywhere als Webserver und in einem Spiegelungssystem ist es nicht möglich, die URL für eine Webanforderung so anzugeben, dass gewährleistet ist, dass die Anforderung zum aktuellen Primärserver geleitet wird. Wenn einer der Servercomputer in der URL genannt wird und dieser Server nicht aktiv ist, tritt ein Timeout für die Anforderung ein.

  • Regelmäßige Sicherungen weiterhin erforderlich   Die Datenbankspiegelung ist kein Ersatz für einen Sicherungs- und Wiederherstellungsplan. Implementieren Sie eine Sicherungs- und Wiederherstellungsstrategie für Ihre Datenbank. Siehe Sicherungen in Datenbankspiegelungssystemen und Sicherung und Datenwiederherstellung.

  • DDL-Einschränkungen   Minimieren Sie die Anzahl von DDL-Anweisungen, die in der Primärdatenbank ausgeführt werden, während ein Objekt möglicherweise auf einem Kopieknoten oder dem Spiegelserver verwendet wird. Das Löschen oder Ändern eines Systemobjekts kann dazu führen, dass Benutzerverbindungen mit dem Spiegelserver oder den Kopieknoten getrennt werden, wenn diese Verbindungen das gelöschte bzw. geänderte Objekt verwenden.

  • Failover und geplante Ereignisse   Wenn für Ihre Datenbank Ereignisse geplant sind und ein Failover auftritt, muss der Failover vor dem Starten der Ereignisse abgeschlossen werden. Andernfalls werden die Ereignisse erst zum nächsten geplanten Zeitpunkt ausgeführt. Wenn der Spiegelserver zur Primärserver-Rolle wechselt, aber der Übergang noch nicht abgeschlossen wurde, wird das geplante Ereignis nicht ausgeführt. Die Ausführung erfolgt dann zum nächsten geplanten Zeitpunkt. Wenn ein Ereignis ausgeführt wird und der Primärserver die Verbindungen zum Spiegelserver und Arbiterserver verliert, werden die Ereignisverbindung und alle anderen Verbindungen getrennt. Wenn für den Zeitpunkt, nachdem der Spiegelserver die Primärserver-Rolle übernommen hat, die Ausführung eines Ereignisses geplant ist, wird dieses Ereignis auf dem neuen Primärserver ausgeführt.

 Siehe auch