Zur Sicherstellung der Datenintegrität wenden alle Datenbankmanagementsysteme (DBMSs) Sperren auf Daten an. Wenn ein Editor beispielsweise mit dem Aktualisieren von Zeilen beginnt, werden die Zeilen gesperrt, um Änderungen an diesen Zeilen durch andere Editoren zu verhindern. Sobald die Transaktion abgeschlossen ist, werden die Sperren aufgehoben.
In jedem DBMS werden Sperren auf verschiedene Weise angewendet, und Isolationsgrade werden unterschiedlich interpretiert. Daher müssen Sie das Verhalten Ihres DBMS prüfen, um zu ermitteln, auf welcher Ebene die Sperren gesetzt, wie Isolationsgrade festgelegt und wie Timeouts für Sperren und Deadlocks behandelt werden sollen. Ausführlichere Informationen erhalten Sie in der DBMS-Dokumentation.
Zudem arbeitet ArcGIS nicht mit jedem DBMS auf dieselbe Weise. Deshalb sind unterschiedliche Probleme mit der Nebenläufigkeit beim Durchführen nicht versionierter Änderungen zwischen den verschiedenen DBMS möglich. In diesem Thema erhalten Sie eine kurze Einführung zur Nebenläufigkeit und zu Sperren im Zusammenhang mit ArcGIS; Datenbanksperren sind jedoch ein komplexes Thema.
ArcGIS und Isolationsgrade
Wenn Sie eine Geodatabase in Oracle, DB2 oder Informix in einer nicht versionierten Editiersitzung bearbeiten, ändert ArcGIS diese Umgebung nicht durch Festlegung des Isolationsgrades. Stattdessen wird der aktuell im DBMS festgelegte Isolationsgrad verwendet. Daher können Sie die Isolation auf einen beliebigen Grad festlegen und diesen beim Bearbeiten in einer nicht versionierten Editiersitzung verwenden.
Ab ArcGIS 10.4 müssen die SQL Server-Datenbankoptionen "READ_COMMITTED_SNAPSHOT" und "ALLOW_SNAPSHOT_ISOLATION" für Geodatabases auf "ON" eingestellt werden. Wenn Sie eine Geodatabase in SQL Server in einer nicht versionierten Editiersitzung bearbeiten, verwendet ArcGIS den Isolationsgrad "READ COMMITTED" für Transaktionen.
In den folgenden Abschnitten werden mögliche Probleme mit der Nebenläufigkeit unter gängigen Bedingungen erläutert. Soweit nicht anderweitig ausgeführt, wird bei diesen Erläuterungen davon ausgegangen, dass im zugrunde liegenden DBMS der standardmäßige Isolationsgrad COMMITTED READ oder dessen Entsprechung festgelegt ist.
Oracle
Schreibvorgänge blockieren Schreibvorgänge: Wenn Sie einen Bearbeitungsvorgang für ein Feature oder eine Gruppe von Features ausführen, z. B. diese verschieben oder deren Attribute ändern, werden die Zeilen durch das DBMS gesperrt. Die Features bleiben gesperrt, bis Sie die Editiersitzung speichern oder ohne zu speichern beenden. Daher wird jedes bearbeitete Feature oder jeder bearbeitete Datensatz für die Dauer der Editiersitzung gesperrt.
Wenn zwei Benutzer versuchen, dasselbe Feature gleichzeitig zu bearbeiten, wird das Feature gesperrt, sobald der erste Editor einen Vorgang abschließt. Die Sperre wird aufrechterhalten, selbst wenn dieser Editor mit der Arbeit an anderen Features begonnen hat. Das Feature bleibt gesperrt, bis dieser Editor es speichert und somit die Änderungen in der Datenbank festschreibt oder die Editiersitzung ohne Speichern beendet, wodurch alle in dieser Editiersitzung vorgenommenen Bearbeitungen rückgängig gemacht werden.
Während der Sperre des Features versucht der zweite Editor, dasselbe Feature zu bearbeiten. Die ArcMap-Sitzung des zweiten Editors wartet auf die Freigabe der Sperre, indem eine Sanduhr dargestellt wird, die angibt, dass die Sitzung eine Aktion verarbeitet. Die Sanduhr wird angezeigt, bis die Sperre aufgehoben wird, wenn der erste Editor die Änderungen speichert (die Änderungen in der Datenbank übernimmt) oder die Editiersitzung ohne Speichern der Änderungen beendet (die Änderungen verwirft). Zu diesem Zeitpunkt kann der zweite Editor die Tabelle bearbeiten. (Dies bedeutet allerdings, dass die Änderungen des zweiten Editors die des ersten überschreiben.)
Dieses Sperrproblem kann auch gleichzeitig für zwei Editoren auftreten, wenn folgende Umstände vorliegen:
- Beide nehmen die Änderungen gleichzeitig vor.
- Die Editoren haben Zeilen in ihrer jeweils aktuellen Editiersitzung geändert.
- Jeder Editor versucht, eine Zeile zu ändern, die bereits vom jeweils anderen Editor geändert wurde.
Für den ersten Editor, der versucht, eine gesperrte Zeile zu ändern, wird eine Sanduhr angezeigt, während die ArcMap-Sitzung auf die Aufhebung der Sperre wartet. Wenn der zweite Editor versucht, eine durch den ersten Editor gesperrte Zeile zu ändern, tritt eine so genannte Deadlock-Situation ein, da sich nun beide Editoren gegenseitig blockieren. Das DBMS wählt automatisch eine der Transaktionen aus, deren Änderungen zurückgesetzt werden, sodass die andere fortgesetzt werden kann. Der Editor, dessen Transaktion zurückgesetzt wurde, muss alle Bearbeitungsvorgänge wiederholen, die seit dem letzten Speichern vorgenommen wurden.
Schreibvorgänge blockieren keine Lesevorgänge: Editoren, die in die Datenbank schreiben, verhindern nicht, dass andere Editoren dieselben Daten lesen, wobei der Isolationsgrad keine Rolle spielt. Den Benutzern oder Anwendungen, die die gesperrten Daten lesen, werden diese so angezeigt, wie sie vor Beginn der aktuellen Transaktion angezeigt wurden.
Lesevorgänge blockieren keine Schreibvorgänge: Benutzer oder Anwendungen, die die Datenbank lesen, verhindern nicht, dass andere Benutzer dieselben Daten ändern können, wobei der Isolationsgrad keine Rolle spielt.
DB2 und Informix
Schreibvorgänge blockieren Schreibvorgänge: Schreibvorgänge blockieren Schreibvorgänge in DB2 und Informix ähnlich wie in Oracle. Weitere Informationen hierzu finden Sie in den Erläuterungen im Abschnitt zu Oracle.
Schreibvorgänge blockieren Lesevorgänge: In DB2 und Informix verhindern Schreibvorgänge, dass andere Benutzer und Anwendungen dieselben Daten lesen können; dies gilt für jeden Isolationsgrad oberhalb von UNCOMMITTED READ. Bei diesen höheren Isolationsgraden kann das Sperren der Daten bis zum Speichern bzw. bis zum Zurücksetzen der Änderungen zu Nebenläufigkeitsproblemen führen. Solange Sie in einer Editiersitzung arbeiten, können die von Ihnen bearbeiteten Daten von keiner anderen Person gelesen werden. Dies kann zu folgenden Situationen führen:
- Wenn Sie ArcMap denselben Layer hinzufügen, wird die Sanduhr angezeigt und der Layer erst nach dem Aufheben der Sperren dargestellt.
- Wenn Sie versuchen, die Ansicht der bearbeiteten Daten zu schwenken, wartet ArcMap bis zum Aufheben der Sperre und aktualisiert anschließend die Anzeige.
- Wenn Sie ein gesperrtes Feature identifizieren, wird die Sanduhr angezeigt und bis zum Aufheben der Sperre werden keine Informationen zurückgegeben.
Lesevorgänge blockieren Schreibvorgänge: In DB2 und Informix verhindern Lesevorgänge bei einem beliebigen Isolationsgrad über UNCOMMITTED READ möglicherweise, dass Editoren dieselben Daten ändern. In ArcGIS wird dies jedoch praktisch nur selten bemerkt, da eine Lesesperre für eine Zeile über eine äußerst kurze Zeitspanne aufrechterhalten wird. Wenn die Daten angezeigt werden, ist die Sperre bereits wieder freigegeben. Lesevorgänge können Schreibvorgänge nur in Anwendungen blockieren, in denen im DBMS ein Cursor geöffnet und jeweils eine Zeile abgerufen wird und anschließend die Ergebnisse im Rahmen der Verarbeitung durchlaufen werden. In einem solchen Fall setzen DB2 und Informix Sperren und erhalten diese aufrecht, solange die Ergebnisse verarbeitet werden.
PostgreSQL
Schreibvorgänge blockieren Schreibvorgänge: In PostgreSQL kann eine Zeile erst aktualisiert werden, wenn die erste Transaktion, mit der eine Änderung an der Zeile vorgenommen wurde, in der Datenbank festgeschrieben oder zurückgesetzt wurde. Wenn zwei Editoren versuchen, dasselbe Feature gleichzeitig zu aktualisieren oder zu löschen, sperrt der erste Editor die Zeile für Aktualisierungen. Andere Editoren können die Zeile erst bearbeiten, wenn dieser Editor sie speichert und somit die Änderungen in der Datenbank festschreibt oder die Editiersitzung ohne Speichern beendet, wodurch alle in dieser Editiersitzung vorgenommenen Bearbeitungen rückgängig gemacht werden.
Während der Sperre des Features versucht der zweite Editor, dasselbe Feature zu bearbeiten. Die ArcMap-Sitzung des zweiten Editors wartet auf die Freigabe der Sperre, indem eine Sanduhr dargestellt wird, die anzeigt, dass die Sitzung eine Aktion verarbeitet. Die Sanduhr wird angezeigt, bis der erste Editor die Änderungen speichert (die Änderungen in der Datenbank festschreibt) oder die Editiersitzung ohne Speichern der Änderungen beendet (die Bearbeitungen verwirft). Zu diesem Zeitpunkt kann der zweite Editor die Tabelle bearbeiten. (Dies bedeutet allerdings, dass die Änderungen des zweiten Editors die des ersten überschreiben.)
Schreibvorgänge blockieren keine Lesevorgänge: Wenn Sie die Steuerung der Nebenläufigkeit mehrerer Versionen (Multiversion Concurrency Control, MVCC) von PostgreSQL verwenden, also das standardmäßige und empfohlene Verhalten der Datenbank, blockieren Transaktionen, die in die Datenbank schreiben, keine Leserabfragen der Datenbank. Dies gilt für den Isolationsgrad READ COMMITTED in der Datenbank und für den Isolationsgrad SERIALIZABLE.
Lesevorgänge blockieren keine Schreibvorgänge: Unabhängig vom für die Datenbank festgelegten Isolationsgrad blockieren Lesevorgänge keine Daten.
SQL Server
Ab ArcGIS 10.4 müssen die SQL Server-Datenbankoptionen "READ_COMMITTED_SNAPSHOT" und "ALLOW_SNAPSHOT_ISOLATION" für Geodatabases auf "ON" eingestellt werden und ArcGIS verwendet den Isolationsgrad "READ COMMITTED" für Transaktionen. Weitere Informationen zum Isolationsgrad "READ COMMITTED" finden Sie in der SQL Server-Dokumentation.
Schreibvorgänge blockieren Schreibvorgänge: Schreibvorgänge blockieren Schreibvorgänge in SQL Server ähnlich wie in Oracle.
Schreibvorgänge blockieren keine Lesevorgänge: Lesevorgänge rufen die übergebene Version der Zeile in dem Zustand ab, in dem sie sich beim Starten der Anweisung oder Transaktion befand.
Lesevorgänge blockieren keine Schreibvorgänge: Wenn Transaktionen Daten lesen, die unter zeilenversionsbasierter Isolation ausgeführt werden, sind für die Lesevorgänge keine freigegebenen Sperren für die gelesenen Daten erforderlich, und Editoren werden daher nicht an der Datenänderung gehindert. Zudem wird dabei die Anzahl der erforderlichen Sperren reduziert und der Aufwand für die Sperrung von Ressourcen minimiert. READ COMMITTED-Isolation mit Zeilenversions- und Schnappschussisolation dienen dazu, Lesekonsistenzen versionierter Daten auf Anweisungs- oder Transaktionsebene bereitzustellen.
Verhindern von Problemen mit Nebenläufigkeit
Probleme bei der Nebenläufigkeit lassen sich minimieren, indem die folgenden Empfehlungen befolgt werden:
Entwerfen von Anwendungen und Workflows unter Berücksichtigung von Sperren
Anforderungen, die auf die Freigabe von Sperren warten, sind häufig das Ergebnis ungenau entworfener Anwendungen oder Workflows. Stellen Sie beim Entwickeln einer Anwendung oder eines Workflows sicher, dass Sperren in geordneter Weise angefordert werden. Dies können Sie erreichen, indem Sie die Folge der Aktualisierungen für alle Tabellen standardisieren. Auf diese Weise sollten Deadlocks verhindert werden. Zum Verringern der Haltezeit von Sperren empfiehlt es sich, alle Datenänderungsanforderungen am Ende jeder Einheit der Anwendungslogik bzw. des Workflows auszugeben, mit der eine Transaktion ausgeführt wird.
Festlegen des geeigneten Isolationsgrades (Oracle, DB2, Informix)
Der Isolationsgrad wirkt sich auf den Zeitraum aus, für den eine Transaktion Daten sperrt. Je höher der Isolationsgrad, desto länger erhält die Transaktion die Sperre aufrecht. Je länger die Transaktion die Sperre aufrechterhält, desto höher ist die Datenintegrität, jedoch auf Kosten der (abnehmenden) Nebenläufigkeit. Wenn dies für die Anwendung akzeptabel ist, können Sie den Isolationsgrad verringern, um die Nebenläufigkeit zu verbessern.
Registrieren der Daten als versioniert
Verbessern Sie die Nebenläufigkeit, indem Sie die Daten als versioniert registrieren. Wenn Sie Daten mit Anwendungen von Drittanbietern verwalten, können Sie die Daten mit der Option zum Verschieben von Änderungen in die Basistabelle als versioniert registrieren. Auf diese Weise können in Anwendungen von Drittanbietern Änderungen angezeigt werden, die an der Standard-Geodatabase-Version vorgenommen wurden. ArcGIS- und ArcObjects-Anwendungen, die andernfalls Probleme mit der Nebenläufigkeit verursachen würden bzw. von solchen betroffen wären, wird so jedoch die Möglichkeit gegeben, Versionen der Daten zu bearbeiten und zu verwalten. Wenn ein Editor eine Versionstabelle ändert, werden keine Sperren gesetzt. Die Bearbeitung der Daten erfolgt somit in vollständiger Isolation von anderen Editoren.