Der Abschnitt beschreibt Vorgehensweisen zur Prüfung der Daten einer MyCoRe-Anwendung und deren Korrekturmöglichkeiten.
Diese Abschnitt beschreibt Kommandos für die MyCoRe Kommandozeile, um die Konsistenz der eigenen Anwendung zu prüfen und ggf. Korrekturen vorzunehmen. Dabei wird vor allem von den flach auf der Platte gespeicherten Metadaten und Bildern ausgegangen. Diese stellen die Grundlage für eventuelle Korrekturen dar, da in MyCoRe einige Datenteile nur sekundär wirken bzw. für eine akzeptable Performacne-Verbesserung existieren. Ein Überblick dazu ist auf der Seite Backup und Recovery zu finden.
MyCoRe-Objekte können innerhalb der Metadatenstrukturen Verweise auf externe URLs aber auch auf andere
MyCoRe-Objekte innerhalb der Anwendung enthalten. Ein Spezialfall sind dabei Verweise auf Kindobjekte innerhalb
der Metadatenstruktur
<structure />
.
In
<structure />
sind auch Verweise auf die angefügten Derivate abgelegt. Mit dem nachfolgenden Kommando aus der Kommandogruppe
MCRObjectCommands kann geprüft werden, ob alle eingetragenen Derivate auch
als XML-Metadaten
vorhanden sind. Dies sagt noch nichts über die innere Konsistenz des Derivates aus!!!
mycore.sh check derivate entries in objects for base {mcr_base_id des Objektes}
Reparaturhinweis: Es ist abzuklären wohin und warum die Derivate verschwunden sind. Ist klar, dass das Derivate nicht mehr existiert, so sollte der Eintrag in den Objektdaten entfernt werden. Am sinnvollsten ist der direkte Zugriff auf das MCRObject unter data/metadata mittels geeignetem XML-Editor z. B. vi .
Nun kann auch der umgekehrte Weg geprüft werden.
mycore.sh check object entries in derivates for base {mcr_base_id des Objektes}
Reparaturhinweis: Offensichtlich sind die fehlerhaften Derivate nicht mehr verknüpft. Es ist abzuklären, ob nur der Verweis im Objekt fehlt oder das Derivat nicht mehr zugeordnet werden kann. In diesem Fall kann das Derivate gelöscht werden. Hierfür sollte zuerst das Kommando
mycore.sh delete derivate {derivate_id}
versucht werden. Hilft dies nicht, müssen die Restfragmente aus dem Metadaten-Store auf der Platte sowie auf dem File-Store händisch entfernt werden. Weiterhin sollten die Einträge in der SQL-Tabelle MCRFSNODES entfernt werden:
echo "use {xyz}; delete from MCRFSNODES where OWNER = '{derivate_id}'" | mysql
Nachdem die XML-Seite der Anwendungsdaten getestet wurde, soll nun der Inhalt der Derivate näher untersucht werden. Hierbei ist zu unterscheiden zwischen Tests, welche unabhängig vom verwendeten Store-Modell sind und speziellen Test für einzelne Stores. Die MCRFSNODES-Tabelle kann aus Sicht der Derivate mit folgendem Kommando auf Konsistenz geprüft werden:
mycore.sh check derivates of mcrfsnodes with project id {project_id}
Hier wird geprüft, ob für ein Verzeichnetes Derivate Einträge in der MCRFSNODES hat und ob diese korrekte Verweise auf existierende Dateien haben.
Im Gegenzug kann auch geprüft werden, ob in der Tabelle MCRFSNODES Einträge sind, welche keine existierenden Derivate mehr haben. Hierfür dient das Kommando:
mycore.sh check mcrfsnodes of derivates with project id {project_id}
Reparaturhinweis: Die Reparatur ist abhängig vom verwendete Store. Für den Store IFS2 sind in den folgenden Abschitten Wege aufgezeigt.
Der IFS2 Store zeichnet sich dadurch aus, dass alle zum Wiederherstellen benötigten Daten direkt auf der Platte stehen. Somit kann aus einer einfachen File-Sicherung das Speichersystem wieder hergestellt werden. Derzeit enthält jedes Derivate-Verzeichnis im IFS2-Store zusätzlich eine Datei mcrdata.xml. Diese beinhaltet eine Beschreibung der abgelegten Daten. Sie wird aber im aktuellen Codestand noch nicht genutzt, jedoch existieren bereits Kommandos, welche diese Datei mit dem aktuellen Stand in Verzeichnis zu synchronisieren.
Reparaturhinweis: Die Synchronisation der Daten kann mittels folgender Kommandos wieder hergestellt werden.
mycore.sh repair mcrdata.xml for project id {project_id} in content store {store_id}
mycore.sh repair mcrdata.xml for object {object_id} in content store {store_id}
mycore.sh repair mcrdata.xml for derivate {derivate_id} in content store {store_id}
Um die Konsistenz zwischen den Derivate-Verzeichnissen auf der Platte und der Tabelle MCRFSNODES zu prüfen sind die nachfolgenden Kommandos entwickelt worden. Hierbei ist zu beachten, dass eine Reparatur für ein ganzes Projekt nur bedingt sinnvoll ist. Vorher sollten auf jeden Fall mit den Check-Kommandos die fehlerhaften Tabelleneinträge ausgelistet und verifiziert sein!
mycore.sh check mcrfsnodes for project id {project_id} of content store {store_id}
mycore.sh check mcrfsnodes for object {object_id} of content store {store_id}
mycore.sh check mcrfsnodes for derivate {derivate_id} of content store {store_id}
Reparaturhinweis: Die Repair-Kommandos leisten folgende Dinge:
mycore.sh repair mcrfsnodes for project id {project_id} of content store {store_id}
mycore.sh repair mcrfsnodes for object {object_id} of content store {store_id}
mycore.sh repair mcrfsnodes for derivate {derivate_id} of content store {store_id}
Unter den Derivaten nehmen die Bilddaten eine besondere Rolle ein. Über den in MyCoRe integrierten IView2-Bildbetrachter werden die Bilder in gekachelter Form dargestellt. Dieser wie auch das DFGViwerServlet nutzen außerdem mets.xml-Dateien.
Der IView2 arbeite mit dem Tiler-Konzept. Hier werden die Bilder in Kacheln verschiedener Zoom-Stufen zerlegt und in einem speziellen Store abgelegt. Maßgeblich ist die SQL-Tabelle MCRTileJob hier ausschlaggebend. Grundsätzlich könne sowohl die Tabelle wie auch das Verzeichnis mit den Kacheln gelöscht und neu angelegt werden. Es sei jedoch darauf hingewiesen, dass dies je nach Bildumfang SEHR lange dauern kann, bis alle Bilder wieder neu gekachelt sind!!!
Das Kommando prüft alle Kacheln und veranlasst das Bauen fehlender.
mycore.sh check tiles of all derivates
Detaillierter kann Derivat-bezogen vorgegangen werden.
mycore.sh check tiles of derivate {derivate_id}
Gelöscht werden kann das gesamte Kachelsystem mit
mycore.sh delete all tiles
wobei auch ein dediziertes Arbeiten mit
mycore.sh delete tiles of object {object_id}
oder
mycore.sh delete tiles of derivate {derivate_id}
möglich ist. Das Wiederherstellen erfolgt dann mit
mycore.sh tile images of all derivates
sowie wieder in kleinen Teilen mit
mycore.sh tile images of object {object_id}
oder
mycore.sh tile images of derivate {derivate_id}
Für bereits bestehende mets.xml-Dateien kann auch eine Validierung erfolgen. Dabei ist aber ein vorheriges select -Kommando vorher erforderlich.
mycore.sh validate selected mets
Sind noch keine mets.xml-Dateien vorhanden und sollen diese schon mal in ihrer Grundform angelegt werden, so generiert das nacholgende Kommando diese für ein einzelnes Derivat {0} oder eine Derivatgruppe einer angegebenen Projekt-ID {0}
mycore.sh add mets files for derivate {0}
mycore.sh add mets files for project id {0}
Bei der Frage des Umgangs und der Wiederherstellung von Klassifikationen müssen drei Ansätze zu deren Handhabung unterschieden werden:
Beginnen wir mit dem letzten Punkt. Mit Umstieg auf das User2-Modul werden alle Rollen (früher Gruppen) und ihre Struktur in der Klassifikation mcr-roles abgespeichert. Die Bearbeitung erfolgt direkt über den Klassifikationseditor. Daher ist es wichtig, nach jeder Änderung diese Klassifikation zu sichern, um sie ggf. wieder neu laden zu können. Ähnlich verhält es sich mit den Klassifikationen, welche über den Editor online änderbar sind. Je nach Häufigkeit der Änderungen müssen hier Exporte der Klassifikation(en) ggf. zyklisch durchgeführt werden. Vorher ist es angeraten, die Klassifikationen noch auf Datenfehler zu prüfen.
mycore.sh check all classifications
mycore.sh export all classifications to directory {dir} with save
Die so erzeugten Dateien können nun mittels Load/Update-Kommando wiederhergestellt werden. Ggf. sind vorher die SQL-Tabellen MCRCategory, MCRCategoryLabel und MCRCategoryLink zu löschen und mit
mycore.sh init hibernate
neu anzulegen. Das Einspielen erfolgt dann mit
mycore.sh update all classifications from directory {dir}
Um Inkonsistenzen in den Daten zu vermeiden, sollte immer die letzte Sicherung nach Änderungen am Klassifikationssystem verwendet werden! Im Falle einzelner beschädigter Klassifikationen können diese mit dem Commandline-Tool (CLI) mycore.sh auch einzeln eingespielt werden.
Wenn es "Lücken" gibt bei der positionInParent
Angabe, dann werden diese mit folgendem Kommando entfernt. Das
kann durch alte inzwischen behobene Fehler entstehen.
mycore.sh repair position in parent
Durch (alte) Fehler können die Links- und Rechte-Werte falsch sein. Diese sind aber erforderlich, um schnell zu überprüfen, ob ein Objekt in einer bestimmten Kategorie enthalten ist. Fehler werden behoben mit
mycore.sh repair left right values for classification {classification}
Kategorien, die kein Label haben, verursachen Probleme (bei Anzeige etc.). Das Kommando findet alle Label-losen
Kategorien und hängt ein Label mit @text=@id
in der Standard-Sprache an.
mycore.sh repair category with empty labels
mycore.sh check all classifications
überprüft die letzten beiden Probleme.
Die Daten der einzelnen Anwendungsnutzer können mit den nachfolgenden Kommandos gesichert und bei Bedarf wieder geladen werden. Die erforderlichen Rollen sind bereits über die Klassifikationen vorher zu laden. Es gibt auch Kommandos für die Arbeit mit einzelnen Nutzern.
mycore.sh export all users to directory {dir}
mycore.sh import all users from directory {dir}
Die Zugriffsrechte sind differenziert zu betrachten. Es können folgende Gruppen ausgemacht werden:
In den meisten Anwendungen werden die Typen 2-5 bei der Initialisierung einmalig geladen oder einmalig händisch nachgetragen. Somit bilden diese Informationen einen Teil der Anwendungsquelle und können z. B. im build-Prozess mit ant create.default-rules in die Tabellen MCRACCESS und MCRACCESSRULES jederzeit geladen werden. Dieses Vorgehen erfordert die Zugriffsstrategien MCRObjectTypeStrategy oder MCRObjectBaseStrategy.
Kritisch ist der 1. Typ. Dieser wird bei der Standardzugriffsstrategie verwendet und erfordert das Auslesen der gesamten Metadaten für Objekte und Derivate mit den save-Kommandos. Ein Recovery kann nur über ein erneutes Laden der Daten erfolgen (kein update!). Hier bleibt nichts weiter, als die entsprechenden SQL-Tabellen separat zu sichern und mit dem Datenbestand konsistent zu halten.
Eine wichtige Gruppe bei der Reparatur einer beschädigten Anwendung ist die Wiederherstellung von Verweisen und Suchindizes. Alle Verweise zwischen MCRObjects, MCRDerivates und MCRClassifications werden in der Tabelle MCRLINKHREFgespeichert. Dies ist eine sekundäre Tabelle. Sie kann gelöscht und wieder hergestellt werden. Gleiches gilt für den SOLR Suchindex. Auch er kann per Kommando gelöscht und neu aufgebaut werden.
Die unten vorgestellten Kommandos gestatten ein reinidzieren des SOLR-Suchindex. Dies kann bei laufender Anwendung erfolgen, da der SOLR-Server eine applikationsunabhängige Instanz darstellt. Ein teilweises Reinidizieren erfolgt mit:
mycore.sh rebuild solr metadata index
mycore.sh rebuild solr content index
mycore.sh restricted rebuild solr metadata index for objecttype {0}
mycore.sh restricted rebuild solr metadata index for object {0}
mycore.sh restricted synchronize metadata index for objecttype {0}
Anschließend kann der SOLR-Index wieder optimiert werden.
mycore.sh optimize solr index
mycore.sh synchronize metadata index
Ggf. kann dieser auch komplett gelöscht und dann neu angelegt werden. Die dazu erforderlichen Kommandos sind:
mycore.sh drop solr index
mycore.sh rebuild solr metadata and content index
mycore.sh drop solr classification index
mycore.sh rebuild solr classification index
Auch einzelne Teile des Index können per Kommando gezielt gelöscht werden.
mycore.sh delete from solr index for type {0}
mycore.sh delete from solr index by id {0}
Neben den Auswahlmöglichkeiten über MyCoRe-ID und Objekt-Type besteht auch die Möglichkeit eines Selects über eine SOLR-Suche und die Nutzung des Ergebnisses zur Weiterverarbeitung.
mycore.sh select objects with solr query {0}
mycore.sh restricted rebuild solr metadata index for selected
mycore.sh restricted rebuild solr content index for selected
Zum Schluss noch die Möglichkeit, eine neue URL für den SOLR-Server zu setzen.
mycore.sh set solr server {0}
Diese Möglichkeit sollte jedoch nur in Ausnahmefällen genutzt werden, da sie ggf. je nach Datenmenge länger dauern könnte.