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 » Verbindungen mit Datenbank in Spiegelungssystemen herstellen

 

Abfragen in der Spiegeldatenbank

In einem Datenbankspiegelungssystem können Sie über eine schreibgeschützte Verbindung auf die Datenbank zugreifen, die auf dem Spiegelserver läuft. Diese Funktion ist nützlich, wenn Sie Berichterstellungs- oder andere Vorgänge auslagern möchten, die einen schreibgeschützten Zugriff auf diese Datenbank erfordern.

Der Versuch, die Spiegeldatenbank zu ändern, führt zu einem Fehler, was dem Verhalten entspricht, wenn eine Datenbank mit der Option -r als schreibgeschützt gestartet wird. Sie können Vorgänge in temporären Tabellen ausführen.

Abfragen, die in der Spiegeldatenbank ausgeführt werden, können Sperren abhängig von der angegebenen Isolationsstufe einrichten. Wenn sich Sperren mit Vorgängen überlagern, die vom Primärserver angewendet werden, werden die Transaktionen der Verbindungen, die die Sperren halten, zurückgesetzt und etwaige geöffnete Cursor für diese Verbindungen werden geschlossen. Anwendungen, die auf der Isolationsstufe 0 ausgeführt werden, fügen zwar keine Zeilensperren hinzu, setzen aber dennoch Schemasperren. Wenn die Schemasperren Vorgänge stören, die vom Primärserver angewendet werden, erfolgt einfach ein Rollback der Transaktionen in der Spiegeldatenbank.

Anwendungen, die eine konstante Ansicht der Datenbank erfordern (und daher nicht Isolationsstufe 0 verwenden können), sollten Snapshot-Isolation verwenden. Um dies zu tun, muss die Option allow_snapshot_isolation auf "On" gesetzt sein. Diese Option wird sowohl auf dem Primärserver als auch auf dem Spiegelserver wirksam. Daher müssen die mit der Snapshot-Isolation verbundenen Kosten berücksichtigt werden.

Verbindungen zur Spiegeldatenbank sind von Transaktionen im Primärserver betroffen, da diese Vorgänge anschließend abgearbeitet und durch den Spiegelserver angewendet werden. Es kann eine kleine Verzögerung zwischen dem Zeitpunkt, an dem ein Update auf dem Primärserver festgeschrieben wird, und dem Zeitpunkt auftreten, an dem das Update dem Spiegelserver zur Verfügung steht. Normalerweise ist diese Verzögerung nur kurz, aber Sie sollten sie berücksichtigen, wenn Sie auf die Datenbank zugreifen, die auf dem Spiegelserver läuft.

Verbindungen zur Spiegeldatenbank bleiben aufrecht, wenn ein Failover auftritt und der Spiegelserver zum Primärserver wird. Nach einem Failover kann eine Verbindung Änderungen an der Datenbank durchführen. Fragen Sie den Wert der ReadOnly-Datenbankeigenschaft ab, um zu ermitteln, ob die Datenbank, mit der Sie verbunden sind, aktualisierbar ist:

SELECT DB_PROPERTY( 'ReadOnly' );

Verbindungen mit einem Kopieknoten oder einer Spiegeldatenbank werden in manchen Fällen getrennt oder abgebrochen, wenn diese Verbindungen das Übernehmen des Transaktionslogs verhindern. Wenn beispielsweise eine Verbindung eine Prozedur verwendet, die das Transaktionslog zu ändern oder zu löschen versucht, wird die Verbindung getrennt, die das Übernehmen des Transaktionslogs blockiert, und eine Meldung wird in die Serverkonsole gedruckt.

 Siehe auch