Nach vielen Tests mit dem neuen TileUpdater haben wir für unsere Umgebung die beste Lösung gefunden, die ich hier einmal dokumentieren möchte, damit andere vielleicht schneller zum Ziel kommen.

Mit Sicherheit ist unsere Umgebung besonders, weil wir nur ein einziges Schema haben, in dem sämtliche Fachschalen enthalten sind. Zudem sind die Fachschalen alle selbst entwickelt. Das führt zu besonderen Herausforderungen für den TileUpdater. Trotzdem denke ich, dass viele Erkenntnisse auch auf andere zutreffen.

Ich persönlich finde, dass die Hilfe nicht wirklich hilfreich ist, um den richtigen Weg vorzubestimmen. Sie lässt einen eher ratlos zurück und man muss es selbst ausprobieren, was sehr viel Zeit in Anspruch nehmen kann, je nach Komplexität der Umgebung. In der Hilfe steht häufig, dass der neue TileUpdater „immer selbst die beste Konfiguration“ zu finden versucht. In unserem Beispiel ist das definitiv falsch. Der TileUpdater versucht es zwar, aber das Ergebnis sind eindeutige Fehlkonfigurationen, die von MuM bisher nur zum Teil behoben werden konnten.

Eine grundsätzliche Info vorweg: Der TileUpdater kann nur Änderungen bearbeiten, die auf den Tabellen selbst passieren (Insert, Update, Delete). Wenn eine Änderung am Darstellungsmodell vorgenommen wird, dann müssen die Kacheln manuell neu erzeugt werden.

Für uns optimale Vorgehensweise:

1. Modus Trigger wählen
2. Nicht verwendete Tabellen auf Off stellen
3. Nicht verwendete Views auf Aktiv = Nein und Methode = AutoNoAction stellen
4. Alle anderen Views auf Launch stellen und die Relationen in den Views konfigurieren
5. Alle doppelten Konfigurationszeilen mit geleichen Tabellen-Relationen deaktivieren
6. Alle Zeilen deaktivieren, wo nur Geometrie und keine Attribute in der View abgefragt werden
7. Alle Views deaktivieren, wo schon per se ein Update durch Trigger auf den beteiligten Tabellen gewährleistet ist (Label-Tabellen, Compound-Tabellen) und keine weiteren Tabellen beteiligt sind
8. Methode Hash nur verwenden, wenn Änderungen nicht von Triggern registriert werden können
9. Regelmäßige Jobs, die kartenrelevante Objekte aktualisieren, vermeiden

Im Folgenden gehe ich auf die TileUpdater-Konfiguration allgemein und die genannte Vorgehensweise im Speziellen ein.

Beim Anlegen einer neuen TileUpdater-Konfiguration muss man sich direkt am Anfang entscheiden, ob man mit oder ohne Trigger arbeiten möchte. Beim Trigger-Modus steht in Klammern direkt ULTRA FAST und ohne Trigger VERY SLOW:

Wer entscheidet sich bei dieser Beschreibung schon für die zweite Option? Und richtig so, denn ich kann auf jeden Fall bestätigen, dass es ohne Trigger sehr langsam ist (Hash-Methode über alles). In unserm Fall kommt hinzu, dass einige Änderungen gar nicht registriert werden und damit die Kacheln im alten Zustand bleiben. Also untauglich.

Sobald man aber Trigger wählt, kommt man in den Zwang die Konfiguration manuell bearbeiten zu müssen, weil der Automatismus eben falsche Annahmen trifft. Der Hinweis in der Hilfe „Das Konfigurieren in den Registern Tables und Views ist optional und muss NICHT durchgeführt werden“ ist also falsch. Streiche „ist optional“ und „NICHT“ und schreibe MUSS in Großbuchstaben.

Der Trigger-Modus erzeugt zunächst auf JEDER Tabelle einen Trigger mit Namen TRG_TU%. Damit wird jedes Insert, Update oder Delete in einer Log-Tabelle protokolliert (ME_TILEUPDATER_LOG). In der Regel werden aber gar nicht alle Tabellen in MapEdit-Karten verwendet, sei es als angezeigte Geometrie oder als Werte, die die angezeigten Objekte in ihrer Ausgestaltung bestimmen (Farbe, Größe etc.). Deshalb ist es wichtig, dass man nicht benötigte Tabellen direkt ausschaltet, damit weniger Trafik auf der Datenbank herrscht:

Das Setzen auf Off löscht dann auch die Trigger wieder (ab Version 25.1). Man muss nur aufpassen, wenn man neue Karten oder neue Inhalte konfiguriert, dann auch hier ggf. die Tabellen wieder zu aktivieren.

Wir arbeiten in unseren Darstellungsmodellen ausschließlich mit Views, so dass wir an dieser Stelle nie die Methode Hash eingestellt haben, sondern nur die Methoden Trigger oder Off. Die Methode Hash gilt es ohnehin zu vermeiden, weil sie eben langsam und unzuverlässig ist, wie oben beschrieben.

Die Einstellungen für die Views muss man dann auf dem nächsten Registerblatt vornehmen:

Auch hier ist es wichtig, dass nur solche Views aktiv sind, die auch an den konfigurierten Karten beteiligt sind. Bei uns sind viele Views nur für Darstellungsmodelle in Map 3D, so dass man direkt viele auf Aktiv = Nein und Methode = AutoNoAction stellen kann.

Herauszufinden, welche Views und Tabellen an den Karten beteiligt sind, ist etwas tricky, aber mithilfe von FME haben wir die Karten aus den MapEdit-Repository-XML-Files mit den Darstellungsmodell-Dateien von Map 3D verknüpft, um die verwendeten View-Namen herauszufinden. Über die Views kommen wir dann über das Oracle-Dictionary zu den beteiligten Tabellen. Das ist aber nur bei komplexeren Umgebungen erforderlich.

Für alle verwendeten Views hat man folgende Auswahl für die Methode:

Auto (Launch) und Auto (Hash) sind Methoden, die der Automatismus liefert. Diese sollte man nicht manuell einstellen und wegen der Langsamkeit und Fehler des Automatismus auch auf eine andere Methode ändern. Die Hilfe gibt einem dazu auch wieder allen Grund, denn „Das Verarbeiten der Views mit der Standard Methode „AutoHash“ macht das Programm langsam.“ Also selbst schuld, wenn man diese Methode stehen lässt.

Beim Anlegen neuer Views wird beim nächsten Aufruf der TileUpdater-Konfiguration immer eine neue Zeile mit AutoHash eingefügt, so dass man dann immer einmal Methode und/oder Aktiv umstellen muss.

 

Launch ist die Methode der ersten Wahl für die in den Karten verwendeten Views. Launch bedeutet, dass hier ein Update ausgelöst (gelauncht) wird, das die Darstellung eines Objektes verändert.

Views setzen sich in der Regel aus mehreren Tabellen zusammen, die im View-Select miteinander gejoint werden. Deshalb muss pro View in der Launch-Konfiguration einmal für jeden Join eine Zeile angelegt werden, die die Geometrie-Tabelle plus die Tabelle, in der ggf. eine darstellungsrelevante Änderung stattfindet, sowie deren Relation zueinander dokumentiert. Das können dann auch mehrere Datensätze pro View werden, je nachdem, wie viele Joins oder Unions beteiligt sind:

Man kann eine Zeile duplizieren, indem man folgenden Button drückt:

Joins zu Tabellen, die normal keine Änderungen erfahren, müssen nicht eingetragen werden. Beispielsweise sind Änderungen in Domaintabellen eher selten und dann immer mit einer Anpassung der Darstellungsmodelle verbunden (Regeln hinzufügen oder ändern), so dass dann ohnehin auch die Kacheln manuell neu erzeugt werden müssen, weil diese Änderungen vom TileUpdater nicht registriert werden können.

In unserem Fall gibt es häufig mehrere Views mit denselben beteiligten Tabellen. In diesem Fall ist es ratsam die Konfiguration nur für eine View zu machen bzw. zu aktivieren, weil der TileUpdater die identischen Zeilen nicht zusammenfasst, sondern tatsächlich jede für sich abarbeitet und deshalb an der Stelle zu viel macht. Wenn man aber nur eine Variante aktiv lässt, muss man natürlich darauf achten, dass bei Änderungen im Datenmodell oder an den Views immer eine aktive Konfiguration bestehen bleibt, sonst macht der TileUpdater natürlich nichts bei einer darstellungsrelevanten Änderung. Wir haben in diesen Fällen die Relationen eingetragen und nur Aktiv = Nein gesetzt, damit man zur Not solche Zeilen schnell aktivieren kann.

Ein weiterer Fall kann dazu führen, dass man eine Zeile deaktiviert, obwohl die View an einer Karte beteiligt ist, nämlich wenn die View nur die Geometrie abfragt und keine Attribute die Darstellung beeinflussen. Dann reicht die Methode Trigger bei der entsprechenden Tabelle aus.

Dasselbe gilt für Label- und Compound-Tabellen. Wenn keine weiteren Tabellen an der Darstellung dieser Objekte beteiligt sind, dann reicht die Methode Trigger bei der entsprechenden Tabelle aus, um zu gewährleisten, dass die Kacheln bei Updates neu erzeugt werden.

In ganz seltenen Ausnahmen haben wir bei Views trotzdem die Methode Hash eingestellt, nämlich immer dann, wenn eine Aktualisierung irgendwo passiert, wo wir nicht direkt Einfluss nehmen können. Beispielsweise gibt es bei uns neben dem GIS-Schema noch das FM-Schema und dort sind Mietvereinbarungen abgelegt. Wenn ein Mietvertrag zu einem Stichtag ausläuft (eingetragenes Enddatum überschritten), gibt es kein Datenbank-Ereignis, auf das ein Trigger reagieren könnte. Trotzdem soll dann eine ehemals vermietete Fläche z.B. nicht mehr dargestellt werden. Das kann man dann nur über den Hash-Wert feststellen.

Ein Hash ist ein Wert, der für jeden einzelnen Datensatz einer View abgespeichert wird und der den Zustand des jeweiligen Objektes eindeutig beschreibt. Bei jedem Durchlauf werden alle Objekt-Hash-Werte mit dem vorherigen Zustand der Objekte verglichen, um eventuelle Änderungen festzustellen. So erkennt dann das System auch, dass ein Objekt (Vermietungsfläche) gar nicht mehr angezeigt wird und weiß, dass dann die betroffenen Kacheln neu erzeugt werden müssen.

Wenn der TileUpdater so eingerichtet ist, kann es eigentlich nur noch ein Szenario geben, das dazu führt, dass unerwartet sehr viele Kacheln generiert werden: Regelmäßige Datenbank-Jobs, die in großen Stile Updates auf an Karten beteiligten Tabellen machen. In unserem Fall konnten wir zum Glück auf diese Jobs verzichten, weil der Grund für die Einrichtung dieser Jobs inzwischen hinfällig geworden ist, wir es aber vorher gar nicht realisiert haben. Man kann leider nicht ohne Weiteres bestimmte Attribute vom TileUpdater ausschließen, wenn sie gar nichts mit der Darstellung der Objekte zu tun haben. Wenn sie darstellungsrelevant sind, dann wäre es ja richtig, dass der TileUpdater reagiert, auch wenn dann ggf. sehr viele Kacheln erneuert werden müssen. Dann ist es auf jeden Fall ratsam zu checken, wie lange der TileUpdater braucht und wann der Job fertig ist, um den richtigen Startzeitpunkt des TileUpdaters im Scheduler einzurichten.

Unser TileUpdater läuft jetzt jede Nacht um 0:00 Uhr und benötigt ca. 1,5 bis 2 Stunden, je nach Menge und Verteilung der erfolgten Updates.

Folgende offene Punkte könnten von MuM noch verbessert werden, um die Verarbeitung weiter zu beschleunigen:

1. Es werden pro geändertem Objekt immer 400 Kacheln pro Karte und Zoomstufe gerendert. Eine engere Beschränkung auf die wahre Ausdehnung des Objektes wäre wünschenswert.
2. Pro Datenbankverbindung müssen immer alle Karten eingetragen werden, die vom TileUpdater berücksichtigt werden sollen. Es wird aber nicht unterschieden, ob ein geändertes Objekt überhaupt in einer Karte dargestellt wird. Hier wäre eine Zuordnung von Konfigurationszeile zu Karte sehr hilfreich, um unnötige Renderjobs zu vermeiden.
3. Launch-Konfigurationen sollten zusammengefasst werden, wenn sie hinsichtlich Geometry, Launch-Table und Relation identisch sind, damit die Abarbeitung zügig läuft und der Admin auch doppelte Einträge behalten kann.