Abfragen, die in der Spiegeldatenbank ausgeführt werden, können Sperren abhängig von der angegebenen Isolationsstufe einrichten. Wenn sich Sperren mit vom Primärserver angewendeten Vorgängen überlagern, 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, erwerben aber dennoch Schemasperren. Wenn sich Schemasperren mit Vorgängen überlagern, die vom Primärserver angewendet werden, werden die Transaktionen in der Spiegeldatenbank zurückgesetzt.
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 der Snapshot-Isolation zugeordneten Kosten berücksichtig 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.
Kommentieren Sie diese Seite in DocCommentXchange. Senden Sie uns Feedback über diese Seite via E-Mail. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |