Deutsch

Problem: Bei ArcGIS-Clients treten bei Verwendung von SQL Server-eigenen räumlichen Datentypen Fehler im Zusammenhang mit Änderungen am Tabellenschema, beim Entladen der App-Domäne oder im Zusammenhang mit Fetchpuffern auf

Beschreibung

Beim Bearbeiten oder Anzeigen von räumlichen Daten, die mithilfe von SQL Server-eigenen räumlichen Datentypen gespeichert wurden, werden bei ArcGIS-Client-Anwendungen möglicherweise folgende Fehlermeldungen angezeigt:

Error:
Cursor-Operation konnte nicht abgeschlossen werden, da das Tabellenschema geändert wurde, nachdem der Cursor deklariert wurde.
 
Error:
Die App-Domäne mit der angegebenen Versions-ID (%d) wurde aufgrund von nicht genügendem Speicher entladen und konnte nicht gefunden werden.
 
Error:
[Microsoft][SQL Server Native Client 11.0][SQL Server]Es sind keine Zeilen im aktuellen Fetchpuffer vorhanden.

In den SQL Server-Fehlerprotokollen bezieht sich der Fehler in der Regel auf ungenügenden Speicher, der dazu führt, dass die CLR-Anwendungsdomäne (Common Language Runtime) entladen wird.

Hinweis:
Das Fehlerprotokoll befindet sich im folgenden Verzeichnispfad: 
C:\Program Files\Microsoft SQL Server\MSSQL##.MSSQLSERVER\MSSQL\Log

Ursache

Räumliche Microsoft SQL Server-Datentypen hängen stark von der CLR ab. Wenn die Anwendungsdomäne, in der die CLR-Daten gehostet werden, entladen wird, wird dies als Schemaänderung an der Datenbank-Engine betrachtet und kann zu Fehlern beim Anzeigen und Bearbeiten von Feature-Classes führen, die mithilfe der Geometrie- oder Geographietypen gespeichert wurden.

Wie in den Fehlermeldungen angegeben, ist dies ein Speicherfehler innerhalb von SQL Server, der dazu führt, dass die CLR-Anwendungsdomäne, die den räumlichen Datentyp hostet, entladen wird.

Lösung oder Problemumgehung

In früheren Versionen von SQL Server (SQL Server 2005, SQL Server 2008 und SQL Server 2008 R2) wurden die Beschränkungen des vom Pufferpool belegten physischen Speichers durch die Konfigurationsoptionen "Max. Serverarbeitsspeicher (MB)" und "Min. Serverarbeitsspeicher (MB)" bestimmt. CLR-Zuweisungen wie die SQL CLR-Heaps und die entsprechenden globalen Zuweisungen, die während der CLR-Initialisierung erstellt werden, werden durch diese Konfigurationsoptionen nicht festgelegt.

Ab SQL Server 2012 sind Zuweisungen von einzelnen oder mehreren Seiten und CLR-Zuweisungen in einer Seitenzuweisung für "alle Größen" konsolidiert. Diese ist Speicherbeschränkungen enthalten, die durch "Max. Serverarbeitsspeicher (MB)" und "Min. Serverarbeitsspeicher (MB)" gesteuert werden. Durch diese Änderung wird eine präzisere Dimensionierungsfunktion für alle Speicheranforderungen bereitgestellt, die vom SQL Server Memory Manager verwaltet werden. Wenn der SQL Server Memory Manager feststellt, dass wenig Speicher vorhanden ist, beginnt er, Seiten aus dem Speicher zu entladen. CLR-Zuweisungen haben eine niedrigere Priorität und werden daher häufiger entladen.

Diese Information ist wichtig bei der Entscheidung, wie viel Speicher mit den Konfigurationsoptionen "Max. Serverarbeitsspeicher (MB)" und "Min. Serverarbeitsspeicher (MB)" zugewiesen werden muss. Standardmäßig wird für den maximalen Serverarbeitsspeicher eine Größe von 2147483647 MB bzw. der gesamte auf dem Server verfügbare Speicher zugewiesen. Wichtig ist, dass die Konfigurationsoption für den maximalen Serverarbeitsspeicher auf einen Wert festgelegt wird, der die Arbeitsspeichernutzung durch SQL Server so einschränkt, dass andere Prozesse wie das Betriebssystem Zugriff auf ausreichend Speicher haben. Obwohl es zunächst unlogisch erscheint, können andere Prozesse oder Anwendungen durch Verkleinern des SQL Server-Speicherpools den Speicher nutzen, den sie benötigen, ohne die Zuweisung von Speicher für SQL Server zu beeinträchtigen. Wenn der gesamte Speicher auf dem Server SQL Server zugewiesen wird, ist die Wahrscheinlichkeit größer, dass Fehler aufgrund von ungenügendem Speicher auftreten.

  • Wenn bei SQL Server 2005, 2008 und 2008 R2 für den maximalen Serverarbeitsspeicher ein zu hoher Wert festgelegt wird, wird über den Speicher-Manager möglicherweise ein zu großer Teil des gesamten Serverarbeitsspeichers gesteuert und dem Pufferpool zugewiesen. CLR-Zuweisungen würden dann nur noch über den restlichen verfügbaren Speicher erfolgen, sodass für CLR zu wenig Speicher bleibt.
  • Bei SQL Server 2012 oder höheren Version kommt eine andere Speicherverwaltungsstrategie zum Einsatz. Da CLR-Speicherzuweisungen ab dieser Version über die Konfigurationsoptionen für den Serverarbeitsspeicher gesteuert werden, kann für den maximalen Serverarbeitsspeicher ein höherer Wert festgelegt werden als bei früheren Versionen von SQL Server.
  • Ab SQL Server 2016 wird die native Implementierung verschiedener räumlicher Methoden aufgerufen, was eine bessere Leistung zur Folge hat und weniger CLR-bezogene Fehler aufgrund von ungenügendem Speicher verursacht.
Überlegen Sie, ob es andere Anwendungen oder Prozesse gibt, die neben SQL Server auf dem System ausgeführt werden und wie viel Speicher auf dem Server tatsächlich verfügbar ist. Möglicherweise ist auf dem Server nicht genügend Arbeitsspeicher installiert, um SQL Server-Operationen zusammen mit den vom Betriebssystem benötigten Operationen zu verarbeiten. Möglicherweise nutzen andere Anwendungen physischen Speicher, der für SQL Server verfügbar sein sollte. Generell wird empfohlen, SQL Server auf einem eigenen Server zu installieren. Andere Anwendungen, die um Arbeitsspeicher konkurrieren, wie etwa ArcGIS, sollten auf einem anderen Computer installiert werden

Microsoft gibt an, dass daran gearbeitet wird, allgemeinere CLR-bezogene Fehler vom Typ" Nicht genügend Arbeitsspeicher" zu beheben. Wenn einer der beschriebenen Fehler bei Verwendung von ArcGIS auftritt oder in den SQL Server-Fehlerprotokollen angegeben wird, sollten Sie sich zur weiteren Ursachenforschung telefonisch an den Support von Microsoft wenden.

Wenn Sie sich wegen dieses Fehlers telefonisch an den Support von Microsoft wenden, nennen Sie dem Support-Mitarbeiter Incident 114080611682006 und Defect 3374271.
 

Knowledge Base-Hinweis:
Dieser Artikel wurde ursprünglich als KB 43036 dokumentiert.