<\/HEAD>
Wir befinden uns derzeit in der Entwicklungs- und Testphase der Implementierung des Parcel Fabric für unseren Landkreis und sind auf EXTREME Leistungsprobleme gestoßen, für die scheinbar niemand eine Lösung hat.<\/P>
<\/P>
Als kurze Hintergrundinformation: Wir haben bereits (vor Monaten) einen langwierigen Bereinigungsprozess unserer Parzellen abgeschlossen – dabei wurde die Linienführung vereinfacht, indem überflüssige Scheitelpunkte entfernt und die Mehrheit davon auf 2-Punkt-Linien planarisiert wurden (außer einer Minderheit von Parzellengrenzen, die natürlichen Merkmalen wie Hydro usw. folgen und als Linestrings belassen wurden). Diese Bereinigung entfernte mehr als 10 Millionen überflüssige Scheitelpunkte. Unsere bereinigten Parzellen- und Unterteilungsdaten wurden anschließend weiterverarbeitet und in das von ESRI bereitgestellte Staging-Schema (FGDB) geladen, wo alle Topologiefehler/-probleme korrigiert wurden, bevor sie schließlich in ein neues Fabric (FGDB) geladen wurden. Dieses Quell-Fabric-FGDB wurde anschließend mit dem Werkzeug Copy Parcel Fabric in unsere Entwicklungs-SDE-Datenbank (ArcSDE 10.3.1 | Oracle 11.2.0.3) geladen.<\/P>
<\/P>
Unser erstes Leistungsproblem trat auf, als wir versuchten, das Fabric versioniert zu registrieren. Da der Versionierungsprozess vor der Registrierung eine Reihe von "Analysen" aller Fabric-Objekte/-Tabellen durchführt, scheint der Prozess zu hängen – tatsächlich dauert er einfach sehr lange. In unserem Fall bedeutet "sehr lange", dass sowohl die Feature-Classes "Parcels" als auch "Lines" jeweils 4-5 Stunden zur Fertigstellung benötigten. Ein flüchtiger Blick auf die Tabellen (und deren erstellte Indizes) zeigte, dass allein die Feature-Class "Lines" 2,9 Millionen Linien/Datensätze enthält. Obwohl mir das etwas beunruhigend erscheint, hat niemand bei ESRI angedeutet, dass dies per se unüblich wäre.<\/P>
<\/P>
Nachdem die Registrierung endlich abgeschlossen war, begann ich mit einfachen Tests zur Bearbeitung, hauptsächlich fokussiert auf einfache Parcel Fabric Workflows wie das Teilen einer Parzelle. Sofort an dem Punkt im Workflow, an dem das Construction-Werkzeug aktiviert wird, zeigt der Cursor/Fadenkreuz eine lähmende Verzögerung und verwandelt sich beim Bewegen durch das Kartenfenster in einen Zeiger mit Sanduhr (als ob eine intensive Operation läuft). Wenn man die Mausbewegung stoppt, kehrt das Fadenkreuz nach 10-15 Sekunden zurück … aber es wird sofort wieder zur Sanduhr, sobald man versucht, es erneut zu bewegen. Bewegt man den nicht reagierenden Zeiger innerhalb der Fangdistanz eines Konstruktionslinien-Features und wartet, verhält er sich beim Zurückkehren des Fadenkreuzes so, als wäre er angeschnappt. Von diesem Punkt an bleibt das Fadenkreuz aktiv, wenn man den Cursor LANGSAM entlang des bereits angeschnappten Features bewegt. Bewegt man sich jedoch zu schnell oder außerhalb der Haft-Toleranz der Fangumgebung (10 Pixel), wird das Fadenkreuz wieder zur Sanduhr. Wenn man geduldig genug ist, während dieser Zeit tatsächlich ein Linien-Feature zu konstruieren, zeigt sich dieses Verhalten während des gesamten Hinzufügens von Scheitelpunkten und Fangens an entsprechenden Linien-Features weiterhin. Nach Abschluss kann man die konstruierten Features wie gewohnt erstellen.<\/P>
<\/P>
Nach weiteren Tests stellte ich fest, dass wenn ich die Umgebung „Classic Snapping“ aktiviere, welche erlaubt zu steuern, welche Layer und Feature-Typen im TOC zum Fangen verfügbar sind (im Gegensatz zur neueren Standard-Fangumgebung, in der alle Layer ständig fangaktiv sind), und alle Layer vom Fangen ausschalte, das Leistungsproblem verschwindet. Das Fabric erzwingt weiterhin das Fangen an sich selbst (was notwendig ist), selbst wenn alle Layer nicht fangaktiv sind. Sobald man jedoch die Lines FC einschaltet, bricht die Leistung dramatisch ein.<\/P>
<\/P>
Interessanterweise tritt dieses Verhalten in einem FGDB nicht auf. Das lässt mich vermuten, dass es eine einzigartige Interaktion zwischen ArcMap, SDE und der Oracle-Datenbank gibt bezüglich des datenintensiven Lines FC. Obwohl ESRI mehrere zusätzliche Möglichkeiten bereitgestellt hat, um direkt (via SQL) die Fabric-Tabellen neu zu analysieren und räumliche Indizes neu zu generieren usw., wurde keine Verbesserung erzielt und niemand konnte (via SDE Intercept und Oracle Trace-Dateien) einen offensichtlichen Engpass identifizieren … Dies ist KEIN I/O-Problem noch scheint es ein SQL-Verarbeitungsproblem zu sein.<\/P>
<\/P>
Ich komme wieder auf meine Sorge über die schiere Anzahl der Datensätze in der Lines Feature-Class zurück, habe aber keine Möglichkeit zu belegen wie/warum/ob dies ein berechtigtes Anliegen ist. ArcMap scheint offensichtlich Schwierigkeiten zu haben, in Echtzeit mit den Lines-Daten zu interagieren, aber ich kann dafür keine funktionale Erklärung anbieten außer meinen bloßen Beobachtungen. Offensichtlich erstellt das FGDB seine eigenen räumlichen Indizes usw. für diese große Feature-Class und läuft dennoch reibungslos. Im Gegensatz dazu sollte Oracle noch robuster sein und eine Datentabelle mit nur 3 Millionen Datensätzen problemlos bewältigen – dennoch ist die Leistung hier katastrophal. Daher komme ich immer wieder zu dem Schluss zurück, dass es etwas ist, was die Anwendung tut und nicht nur die Datenbank selbst.<\/P>
<\/P>
Wenn jemand ähnliche Erfahrungen mit diesem Problem gemacht hat oder Einblicke dazu geben kann, wären wir sehr dankbar!<\/P>
<\/P>
Gavin<\/P><\/BODY><\/HTML>
