Tool zum Bearbeiten (Reindizieren, Zusammenführen, Löschen, Reparieren) von B2B-Indizes

Übersicht

Die B2B verwendet verschiedene Indizes (z. B. Volltext, Archiv und CCM), um schnell auf Informationen der verarbeiteten Nachrichten der Marktkommunikation zugreifen zu können. Die Indizes werden durch die B2B fortlaufend gefüllt. Unter Umständen kommt es vor (z. B. die Indizierungsdienste wurden deaktiviert), dass die Indizes unvollständig oder korrupt sind.

In diesen Fällen können die Indizes aktualisiert, repariert oder bereinigt werden. Diese Dokumentation beschreibt, wie das IndexRepairKit installiert wird und anhand einiger UseCases, wie mithilfe des IndexRepairKits vorgegangen werden kann, um evtl. Probleme mit den Indizes zu bewältigen.

Download

Der IndexRepairKit kann aus dem Public DL heruntergeladen werden.

Die aktuelle Version ist indexrepairkit-2023-05-17.zip.

Docker-Image: docker-nob-erf.next-level-apps.com/indexrepairkit:2023-05-17

Einrichtung und Installation

  • indexrepairkit.zip im Dateisystem entpacken.
  • Falls noch nicht vorhanden, die nötigen Datenbanktreiber dem Verzeichnis hinzufügen (zu finden zum Beispiel im tomcat/lib-Verzeichnis).
  • Zugangsdaten für die Datenbank in dbconnection.txt analog zum dortigen Beispiel konfigurieren. Die Datenbankeinstellungen können aus der b2bbp-engine.xml entnommen werden. (Standard-Verzeichnispfad tomcat/conf/Catalina/localhost/b2bbp-engine.xml)

Verzeichnis

DBconnection

Docker-Version

Da es auf manchen Systemen nicht möglich ist, jar-Anwendungen direkt auszuführen, wurde ein Docker-Image gebaut, welches die Ausführung ermöglicht. Dieses wird von einem Admin auf dem gewünschten System installiert und mit Hilfe von Umgebungsvariablen konfiguriert.

  1. Kopieren der unten abgebildeten docker-compose.yml in ein Verzeichnis auf dem Host-System.

     version: '3.3'
    
     services:
       indexrepairkit:
         image: ${DOCKER_REPOSITORY}/indexrepairkit:${IRK_VERSION}
         container_name: indexrepairkit
         restart: always
         environment:
           TZ: Europe/Berlin
           JAVA_OPTS: –Xmx4096m
           VERSION: ${IRK_VERSION}
           DB_DRIVER_CLASS: ${DB_DRIVER_CLASS}
           DB_DRIVER: ${DB_DRIVER}
           DB_CONNECTION_URL: ${DB_CONNECTION_URL}
           DB_USER_NAME: ${DB_USER_NAME}
           DB_USER_PASSWORD: ${DB_USER_PASSWORD}
         volumes:
           - ${IRK_INDEX_DIRECTORY}:/home/indexrepairkit/index
           - ${DB_DRIVER_PATH}/${DB_DRIVER}:/home/indexrepairkit/indexrepairkit-${IRK_VERSION}/${DB_DRIVER}
           - ${IRK_LOG_DIRECTORY}:/home/indexrepairkit/indexrepairkit-${IRK_VERSION}/log
    
  2. Erstellen einer .env-Datei mit unten abgebildetem Inhalt. Diese muss in dem selben Verzeichnis liegen, wie die docker-compose.yml.

     IRK_VERSION=2022-05-17
     DOCKER_REPOSITORY=docker-nob-erf.next-level-apps.com
    
     # path to given index
     IRK_INDEX_DIRECTORY=/global/b2b_all/index/ccm
     IRK_LOG_DIRECTORY=/global/sep/logs/indexrepairkit
    
     # db connection
     DB_DRIVER_PATH=/global/sep/indexrepairkit/lib
     DB_DRIVER=mssql-jdbc-8.2.1.jre8.jar
     DB_DRIVER_CLASS=org.apache.derby.jdbc.ClientDriver
     DB_CONNECTION_URL=jdbc:derby://host.docker.internal:1527/WORKPLACE
     DB_USER_NAME=admin
     DB_USER_PASSWORD=b2bbp
    
  3. .env entsprechend konfigurieren und ergänzen: siehe Umgebungsvariablen unten.

Umgebungsvariablen

Variable Beschreibung Hinweis
IRK_VERSION Version des IndexRepairKits  
DOCKER_REPOSITORY Link zum Nexus Standardwert: docker-nob-erf.next-level-apps.com
IRK_INDEX_DIRECTORY Verzeichnis des zu bearbeitenden Indexes Ein Beispiel für das Format des Links findet sich in der ´sample.env´.
DB_DRIVER_PATH, DB_DRIVER Verzeichnis, in welchem der/die Datenbanktreiber liegt/liegen und der Dateiname des Treibers  
DB_DRIVER_CLASS, DB_CONNECTION_URL, DB_USER, DB_PASSWORD Daten zur Verbindung mit der Datenbank Diese Informationen können der b2bbp-engine.xml entnommen werden, meist zu finden unter: tomcat/conf/Catalina/localhost/b2bbp-engine.xml.

Ausführung

Je nach Betriebssystem reIndex.bat oder reIndex.sh ausführen. Im Falle einer OutOfMemoryException kann in den Ausführungsdateien mittels set JAVA_OPTS=–Xmx1024m zusätzlich Speicher (hier 1024 MB) für die JVM reserviert werden. In der Kommandozeile wird man zur Eingabe von Operation, Indextyp und Indizierungsgrenzen aufgefordert. Welche weiteren Einstellungsmöglichkeiten es gibt, wird im Folgenden erläutert.

Bat

Docker-Version

  1. Ausführen mit docker-compose up -d aus dem Verzeichnis heraus, in welchem die docker-compose.yml liegt.
  2. In die Konsole innerhalb des Containers wechseln mit docker exec -it indexrepairkit /bin/sh
  3. Dort in das Verzeichnis des IndexRepairKits wechseln mit cd /home/indexrepairkit/indexrepairkit-YYYY-MM-TT - dabei das Datum anpassen wie IRK_VERSION.
  4. Das IndexRepairKit starten mit ./reIndex.sh.
  5. Weiter wie bei der Kommandozeilen-Variante. Die einzige Ausnahme ist der Pfad zum Index.

Anwendungsfälle

In diesem Kapitel werden verschiedene Szenarien beschrieben, die mit dem IndexRepairKit durchgeführt werden können.

Aktualisieren/Erstellen eines Index für die Volltextsuche

Ausgangslage:

Es soll ein Index für die Volltextsuche anhand der Nachrichten in der B2B aufgebaut werden.

Ausführung:

Nach dem Start des IndexRepairKits ist zunächst die Option “1) Nicht indizierte Nachrichten aus der B2B Engine nachindizieren” auszuwählen:

******************** ReIndexer-Tool ***************
Mit diesem Tool können Sie:
1) Nicht indizierte Nachrichten aus der B2B Engine nachindizieren
2) Indizierte Nachrichten aus dem Index löschen, um Speicherplatz zurückzugewinnen
3) Mehrere Indexdateien zusammenführen
4) Einen korrupten Index reparieren (EXPERIMENTELL! NUTZEN AUF EIGENE VERANTWORTUNG!)
Was möchten Sie tun? [1-4] 1 

Anschließend werden die in der B2B konfigurierten Indizes aufgelistet. Standardmäßig ist der Volltextindex als “B3P_SEARCH_INDEX_DIRECTORY” konfiguriert und hier nun auszuwählen:

In B3P_INDEX_MANAGEMENT konfigurierte Indizes:
1) B3P_SEARCH_INDEX_DIRECTORY
2) B3P_LUCENE_INDEX_FOLDER
3) B3P_FLEXIBLE_INDEX_CORR_DIRECTORY
Bitte geben Sie den zu bearbeitenden Indextyp ein: 1

Im nächsten Schritt muss das Verzeichnis angegeben werden, in das der Index geschrieben werden soll. Enthält das Verzeichnis bereits einen Volltextindex, wird dieser aktualisiert. Wird hier ein leeres Verzeichnis angegeben, wird ein komplett neuer Index erstellt. In diesem Szenario ist ein leeres Verzeichnis anzugeben, z. B. “C:\temp\volltextindex":

Verwende Index B3P_SEARCH_INDEX_DIRECTORY
Bitte geben Sie den (relativen oder absoluten) Pfad zum Index ein: C:\temp\volltextindex

Die nächste Frage betrifft das Locking des IndexServices

Während der Reinidzierung soll keine normale Indizierung durch den IndexService in diesen Index laufen. 
Dafür wird ein B2B-Lock gesetzt. Wenn Sie sich sicher sind, dass das gerade angegebene Verzeichnis 
nicht in einer laufenden B2B benutzt wird, kann auf das Setzen des Locks verzichtet werden. 
Der IndexService wird in seinem eigenen Index parallel indizieren.
Damit kein Lock gesetz wird, geben Sie bitte "keinen Lock setzen" ein (EXPERTS ONLY!). Ansonsten bitte Enter drücken.

Falls man sich sicher ist, dass der zu reindizierende Index gerade nicht von der B2B benutzt wird, kann keinen Lock setzen eingegeben werden. In den meisten Fällen soll einfach Enter gedrückt werden.

Die nächste Option erfragt die Art der Indizierung. Da in diesem Szenario ein Index für die Volltextsuche erstellt werden soll, ist “1) Volltext” auszuwählen:

Welcher Indexer soll genutzt werden?
1) Volltext
2) Flexible
3) Archive
Bitte gewünschte Zahl eingeben: 1

Wird die anschließende Frage, ob auch bereits vorhandene Dokumente reindiziert werden sollen, mit “J” beantwortet, werden bereits indizierte Nachrichten im Index zunächst gelöscht und dann erneut indiziert. Da es sich in diesem Szenario jedoch um einen neuen Index handelt, wird diese Fragen mit “N” beantwortet:

Sollen auch bereits vorhandene Dokumente reindiziert werden? [J/N] N

In der folgenden Option wird gefragt, ob die PREDEFINED_SEARCHTERMS gelesen werden sollen. Wird diese Frage mit “J” beantwortet, werden die unter der B2B-Extension “B3P_PREDEFINED_SEARCH_TERMS” angegebenen Parameter ausgelesen und zusätzlich zu der eigentlichen Nachricht indiziert. Hiermit wird die Möglichkeit geboten, die Volltextsuche um weitere Parameter zu erweitern. Da hier zusätzliche Parameter interpretiert werden, ist je nach Anzahl der zu indizierenden Nachrichten mit einer längeren Indizierungszeit zu rechnen. In diesem Szenario wird die Frage jedoch mit “N” beantwortet:

Sollen die PREDEFINED_SEARCHTERMS gelesen werden (langsamer)? [J/N] N

Als nächste Option wird die Möglichkeit geboten, eine abschließende Optimierung des Index durchzuführen.

Da in diesem Szenario jedoch ein neuer Index erstellt wird, ist die Frage mit “N” zu beantworten:

Es wird empfohlen, nach der Reindizierung eine Optimierung durchzuführen. Möchten Sie dies tun? [J/N] N

Die nun folgende Option ermöglicht die Angabe einer Startzeit. Diese Zeit wird genutzt, um die zu indizierenden Nachrichten in der B2B zu selektieren. Wählt man hier “X”, wird das Datum “01.01.2000 00:00:00” für diese Selektion verwendet. Es ist ratsam, hier explizit ein Datum anzugeben, da eine möglichst genaue zeitliche Selektion die Ausführungszeit der Indizierung minimiert. Als Beispiel für dieses Szenario wird hier “15.06.2020 12:00:00” verwendet:

Reindizieren von, X -> 01.01.2000[ 00:00:00]: 15.06.2020 12:00:00

Im nächsten Schritt ist analog zur vorherigen Option die Endzeit der Selektion der Nachrichten anzugeben. Wird hier “X” angegeben, wird die aktuelle Zeit verwendet. In diesem Szenario wird hier “21.06.2020 00:00:00” angegeben:

Reindizieren bis, X -> jetzt, 07.08.2020[ 10:15:24]: 21.06.2020 00:00:00

Nach der Definition des Selektionszeitraums wird in der nächsten Option gefragt, ob eine WHERE-Klausel zur weiteren Einschränkung der zu selektierenden B2B-Nachrichten angegeben werden möchte:

Möchten Sie eine Einschränkung der erfassten Nachrichten als WHERE-Clause eingeben [J/N] (EXPERTS ONLY!) N

Sofern dies gewünscht ist, sollte eine solche in valider SQL-Syntax und mit validen Feldbezeichnern vorgenommen werden. Ein Beispiel wäre hier:

 REFERENCEID != 'UNKNOWN'

Welche Feldbezeichner für die Definition der WHERE-Klausel zur Verfügung stehen, wird nach der Beantwortung der Frage mit “J” ausgegeben. Nach der Eingabe der WHERE-Klausel wird die komplette SQL-Abfrage nochmals ausgegeben und um eine Freigabe gebeten. In diesem Szenario soll aber keine weitere Einschränkung durch eine WHERE-Klausel vorgenommen werden und die Frage wird dem entsprechend mit “N” beantwortet.

Der zuvor definierte Selektionszeitraum wird vom IndexRepairKit in mehreren Iterationen durchlaufen. Mit der Option “Stunden pro Iteration” können Anzahl und Größe dieser Iterationen und damit Last und Ausführungszeit der Indizierung beeinflusst werden. Viele Iterationen mit relativ kleinen Intervallen (kleine Stundenzahl) führen zu entsprechend vielen, aber schnelleren Datenbankabfragen und Indexzugriffen als solche mit großen Selektionszeiträumen (große Stundenzahl) und belasten/blockieren B2B-Datenbank und Index entsprechend weniger, führen aber zu einer länger Ausführungszeit der Indizierung. Für dieses Szenario wird “24” ausgewählt, also eine Iteration pro Tag, was bei dem o. g. Selektionszeitraum zu 6 Iterationen führen sollte:

Wieviele Stunden sollen pro Iteration indiziert werden (es wird batch-weise reindiziert)? (Ganze Zahl eingeben, default 6) 24

Auch die nächste Option dient der Optimierung der Ausführungszeit und des Lastverhaltens der Indizierung. Durch die Angabe der Anzahl an Dokumenten, nach denen ein COMMIT in Lucene ausgeführt wird, kann durch eine höhere Zahl die Ausführungszeit minimiert werden. Eine höhere Zahl bedingt aber auch, dass bei einem evtl. Abbruch der Indizierung entsprechend viele Einträge nicht in den Index geschrieben werden. In diesem Szenario wird der Wert “20” verwendet:

Nach wievielen Dokumenten soll ein Commit (in Lucene!) ausgefuehrt werden? (Ganze Zahl) 20

Im nächsten Schritt kann angegeben werden, ob die Indizierung zu einem bestimmten Zeitpunkt abgebrochen werden soll. Mithilfe dieser Option kann bei leistungskritischen Systemen oder voraussehbaren Lastspitzen die Indizierung abgebrochen werden, um das System nicht weiter zu belasten. Für dieses Szenario ist dies jedoch nicht relevant und die Frage wird mit “X” beantwortet:

Wann soll die Reindizierung gestoppt werden? (dd.MM.yyyy[ HH:mm:ss], 'X' -> keine Stoppzeit) X

Mittels der nachfolgenden Option kann der Start der Indizierung auf eine bestimmte Uhrzeit terminiert werden. Die Gründe hierfür ähneln denen der vorherigen Option. Es ist z. B. denkbar, eine Indizierung immer nur nachts durchführen zu wollen, ohne diese manuell starten zu müssen. Für dieses Szenario ist dies jedoch ebenfalls nicht relevant und die Frage wird mit “X” beantwortet:

Wann soll die Reindizierung gestartet werden? (dd.MM.yyyy[ HH:mm:ss], 'X' -> Sofort) X

Durch Bestätigung der letzten Option mit “J” wird die Indizierung gestartet:

Soll die Verarbeitung gestartet werden? [J/N]   J

Ergebnis: Nachdem die Indizierung wie zuvor beschrieben gestartet wurde, werden die Ergebnisse der einzelnen Iterationen auf der Console ausgegeben. In diesem Szenario erscheinen die folgenden Ausgaben:

************** Zwischenbericht **********************
Indiziert bis 16.06.2020 12:00:00
Es wurden 20 Nachrichten gefunden, die nicht im Index enthalten sind.
Dokumente zur Indizierung    : 20
Dokumente indiziert          : 20
Keine Edi Nachricht gefunden : 12
Nachrichten nicht indiziert  : 12
Verarbeitungszeit: 1 s
Durchschnittlich benötigte Zeit pro Dokument: 66 ms
******************************************************
...
für Dokumentation gekürzt
...
************** Zwischenbericht **********************
Indiziert bis 21.06.2020 00:00:00
Es wurden 163 Nachrichten gefunden, die nicht im Index enthalten sind.
Dokumente zur Indizierung    : 163
Dokumente indiziert          : 163
Keine Edi Nachricht gefunden : 153
Nachrichten nicht indiziert  : 153
Verarbeitungszeit: 6 s
Durchschnittlich benötigte Zeit pro Dokument: 39 ms
******************************************************
******************* Abschlussbericht - Indizierung ********************************************
Ende der ReIndizierung um 2020-08-06 10:04:56.291
Es wurden 163 Nachrichten gefunden, die nicht im Index enthalten sind.
Dokumente zur Indizierung    : 163
Dokumente indiziert          : 163
Keine Edi Nachricht gefunden : 153
Nachrichten nicht indiziert  : 153
Verarbeitungszeit: 6 s
Durchschnittlich benötigte Zeit pro Dokument: 39 ms
******************************************************
*******************  PROFILING ***************************
Benötigte Zeit Datenbankabfrage: 149 ms
Benötigte Zeit Schreiben in den Index: 0 ms
Benötigte Zeit Dokumentaufaufbau: 3560 ms
Benötigte Zeit Systemausgaben: 0 ms
Benötigte Zeit Edi aus Datenbank lesen 5191 ms

Die ausgegeben Informationen sind in Blöcke unterteilt. Es gibt “Zwischenbericht”, “Abschlussbericht - Indizierung” und “PROFILING”. Ein “Zwischenbericht” enthält die Informationen einer Iteration. Der “Abschlussbericht - Indizierung” enthält die Informationen über die gesamte Indizierung. Und der Block “PROFILING” enthält Informationen zu den Ausführungszeiten der einzelnen Aktionen.

Nachdem die Indizierung abgeschlossen wurde, befindet sich im zuvor angegebenen Verzeichnis der erstellte Index. Dieser kann mit geeigneten Tools (z. B. Luke) zunächst gesichtet, durch andere Funktionen des IndexRepairKits weiter bearbeitet oder wieder der B2B zur Verfügung gestellt werden.

Aktualisieren/Erstellen eines CCM-Index

Ausgangslage:

Der CCM-Index unterscheidet sich vom Volltextindex dahingehend, dass hier nicht die Nachricht als Ganzes, sondern einzelne in der B2B konfigurierte Felder je nach Nachrichtentyp indiziert werden. Die Reindizierung des CCM-Index bietet zudem weitere Optionen und wird aus diesem Grund separat beschrieben.

Ausführung:

Die Optionen für die Reindizierung des CCM-Index haben die gleiche Bedeutung wie beim Volltextindex. Bei Option 2, “zu bearbeitender Indextyp”, ist jedoch der CCM-Index, üblicherweise “B3P_FLEXIBLE_INDEX_CORR_DIRECTORY”, auszuwählen. Option 4 fragt, ob auch Template-Funktionen ausgewertet werden sollen. Wählt man hier “J”, werden die ggf. in der B2B-Extension “FLEXIBLE_INDEX” enthaltenen Template-Funktionen interpretiert und deren Ergebnisse entsprechend indiziert.

Ergebnis: Auch für die Ergebnisse gilt das Gleiche wie zuvor für die Reindizierung des Volltextindex beschrieben.

Aktualisieren/Erstellen eines Archiv-Index

Ausgangslage:

Der Archiv-Index dient dem Zugriff (z. B. aus der Suche im Nachrichtenmonitor der B2B) auf die Nachrichten, die in der B2B bereits archiviert wurden. Es kann vorkommen, dass diese bereits archivierten Nachrichten erneut indiziert werden müssen. Für eine solche Reindizierung ist es maßgeblich, dass der Archiv-Job in der B2B korrekt konfiguriert ist und einwandfrei funktioniert.

Ausführung:

Nach dem Start des IndexRepairKit ist mit der Option “1” die Reindizierungsfunktion auszuwählen.

Die zweite Option erfragt wieder den Index, der reindiziert werden soll. Hier ist der in der B2B konfigurierte Archiv-Index, in der Regel “B3P_LUCENE_INDEX_FOLDER”, auszuwählen.

Anschließend ist der Pfad auf das Index-Verzeichnis anzugeben.

Bei der nächsten Frage nach dem Lock soll in den meisten Fällen Enter gedrückt werden. Siehe ansonsten den Abschnitt zu Volltextindex oben.

Die nächste Option erfragt die Art der Indizierung und ist in diesem Szenario mit “3” zu beantworten:

Welcher Indexer soll genutzt werden?
1) Volltext
2) Flexible
3) Archive
Bitte gewünschte Zahl eingeben: 3

In der folgenden Option ist anzugeben, welche Art von archivierten Nachrichten reindiziert werden soll. Wird die Frage nach der Verwendung eines DBBackup-Reindexers mit “N” beantwortet, werden lediglich die Nachrichten reindiziert, die zwar bereits durch den Archiv-Job archiviert (und dabei als archiviert markiert) wurden, aber noch nicht aus der B2B gelöscht sind. Da in diesem Szenario jedoch Nachrichten reindiziert werden sollen, die bereits aus der B2B gelöscht wurden, ist hier “J” anzugeben:

Soll ein DBBackup-Reindexer verwendet werden? [J/N] J

Durch die Verwendung des DBBackup-Reindexers werden nun Nachrichten indiziert, die in der B2B bereits gelöscht wurden. Als Basis der Reindizierung werden die Einträge der durch die GlobalProperty “B3P_ARCHIVE_DB_BACKUP_TABLE” konfigurierten Datenbanktabelle verwendet. Diese Tabelle enthält Metainformationen der in der B2B archivierten Nachrichten, damit diese auch nach deren Löschung wieder reindiziert werden können. Physisch sind die Nachrichten durch die Archivierung in externe Archivsysteme (z. B. IXOS, BFlow, NScale oder Dateisystem) verschoben worden und können bei der Reindizierung wieder aus diesen ausgelesen und indiziert werden. Weitere Informationen sind in dem Abschnitt DB-Backup des Archivindexes enthalten.

In der nächsten Option ist das konkrete externe Archivsystem auszuwählen, beispielsweise “B” für “Bflow”:

Welche Klasse soll verwendet werden? IXOS [I], Bflow [B], Nscale [N] oder EASY-Reindexer [E]? B

In den nächsten 5 Optionen werden die bereits unter Aktualisieren/Erstellen eines Index für die Volltextsuche beschriebenen Optionen zur Verwendung der PREDEFINED_SEARCHTERMS, der anschließenden Optimierung, dem Selektionszeitraum und der Angabe weiterer Selektionskriterien abgefragt und sind entsprechend der konkreten Anforderung zu beantworten.

Die darauf folgende Option fragt, ob der originale Verarbeitungsstatus indiziert werden soll. Wird die Frage mit “J” beantwortet, wird die Selektion der Daten auf weitere Datenbanktabellen ausgedehnt. Das kann zu einer längeren Ausführungszeit führen. Für dieses Szenario wird “J” gewählt:

Soll versucht werden, den originalen Verarbeitungsstatus (VS) zu indizieren? Es wird ein JOIN zw. DATA_MESSAGE und DATA_CLEARING ausgeführt. Die Verarbeitung dauert etwas länger. [J/N] J

Anschließend ist anzugeben, ob die Edifact-Nachricht indiziert werden soll. Diese Frage ist mit “J” zu beantworten, wenn die Nachricht für eine Archiv-Volltextsuche im B2B-Monitor verfügbar sein soll. In diesem Szenario wird “J” gewählt:

Soll die Edifact-Nachricht mit indiziert werden, um eine Volltextsuche für die Suche im Archiv zu unterstützen? [J/N] J

Die nächsten 5 Optionen sind analog zu Aktualisieren/Erstellen eines Index für die Volltextsuche und entsprechend zu beantworten.

Nach der vermeintlich letzten Option zum Starten der Reindizierung wird gefragt, ob auch “Split-Nachrichten” indiziert werden sollen. Wird diese Frage mit “J” beantwortet, werden Nachrichten, deren Channel-ID “SPLIT” enthält, NICHT reindiziert.

Ergebnis: Als Ergebnis der Ausführung werden die Informationen zu jeder Iteration und abschließende Informationen ausgegeben. Nach einer Sichtung des Index kann dieser der B2B zur Verfügung gestellt werden.

Löschen von alten Einträgen aus einem Index

Ausgangslage:

Um die Größe eines Index zu optimieren, sollen alte Nachrichten entfernt werden.

Ausführung:

Nach dem Start des IndexRepairKits ist zunächst die Option “2) Indizierte Nachrichten aus dem Index löschen, um Speicherplatz zurückzugewinnen” auszuwählen:

******************** ReIndexer-Tool ***************
Mit diesem Tool können Sie:
1) Nicht indizierte Nachrichten aus der B2B Engine nachindizieren
2) Indizierte Nachrichten aus dem Index löschen, um Speicherplatz zurückzugewinnen
3) Mehrere Indexdateien zusammenführen
4) Einen korrupten Index reparieren (EXPERIMENTELL! NUTZEN AUF EIGENE VERANTWORTUNG!)
Was möchten Sie tun? [1-4] 2

Im nächsten Schritt ist der zu verwendende Index anzugeben. Dabei ist die GlobalProperty zu verwenden, unter der der Index in der B2B konfiguriert ist:

Verfügbare Indizes:' 'B3P_SEARCH_INDEX_DIRECTORY' 'B3P_LUCENE_INDEX_FOLDER' 'B3P_FLEXIBLE_INDEX_CORR_DIRECTORY
Bitte geben Sie den Indextyp ein ( s. Global Properties):  B3P_SEARCH_INDEX_DIRECTORY

Die folgende Option erfragt wieder das Verzeichnis unter dem der zu bearbeitende Index existiert:

Bitte geben Sie den (relativen oder absoluten) Pfad zum Index ein: C:\temp\volltextindex

In der nächsten Option muss der zu verwendende Analyzer angegeben werden. Bei dem hier abgefragten Analyzer handelt es sich um die Art, wie die folgenden Einschränkungen interpretiert werden. Wenn die Einschränkung nur auf die Metadaten und nicht auf die indizierte Nachricht vorgenommen werden soll, dann ist der Keyword-Analyzer die richtige Wahl. Sollen die zu löschenden Einträge durch Informationen in den indizierten EDI-Nachrichten eingeschränkt werden, dann sollte der Standard-Analyzer verwendet werden.

In diesem Szenario wird der “2) Keyword-Analyzer” gewählt:

Welcher Analyzer soll genutzt werden?
1) Standard-Analyzer
2) Keyword-Analyzer
3) Archive-Analyzer
Bitte gewünschte Zahl eingeben:  2

Anschließend muss eine Lucene-Query angegeben werden, um die zu löschenden Einträge zu selektieren. In diesem Szenario wird davon ausgegangen, dass in dem Index Einträge vom 25.05.2020 bis zum 13.07.2020 existieren. Es sollen alle Einträge vom Mai und Juni gelöscht werden:

Bitte geben Sie Bedingungen fuer den Loeschvorgang als Lucene Query:  created:202005* OR created:202006*

Eine weitere beispielhafte Einschränkung für den Keyword-Analyzer ist:

created:202005* AND referenceId:NLI-DEV*

Mit dieser Einschränkung würden alle Nachrichten aus dem Index gelöscht, die im Mai 2020 eingegangen sind und “NLI-DEV” als Teil der Dokumentennummer haben.

Für den Standard-Analyzer, ist die folgende Einschränkung beispielhaft:

data:MSCONS AND NOT data:13017

Diese Einschränkung würde alle MSCONS-Nachrichten aus dem Index löschen, die keine Zählerstände sind.

Mithilfe der nächsten Option, kann eine anschließende Optimierung veranlasst werden. Dies wird empfohlen, sofern ausreichend Platz auf der Festplatte vorhanden ist und genügen Zeit zur Verfügung steht (siehe auch diesen Hinweis):

Soll der Index nach dem Loeschen optimiert werden? [J/N]  J

Die nächste Option erfragt, ob beliebig viel Bool-Ausdrücke unterstützt werden sollen. Diese Frage sollte nur dann mit “J” beantwortet werden, wenn zuvor eine äußerst komplexe Lucene-Query verwendet wurde, da je nach Schachtelung und Vielfalt der verwendeten Einzelabfragen (Term, Range, Fuzzy, Phrase, etc.) Lucene entsprechend viel Speicher benötigt. Wird diese Frage mit “N” beantwortet, werden standardmäßig max. 1024 Bool-Ausdrücken (Einzelabfragen) unterstützt, was in der Regel ausreichend ist. In diesem Szenario wird diese Frage mit “N” beantwortet:

Sollen beliebig viele Bool-Ausdrücke unterstützt werden? (Kann zu erhoehtem RAM und CPU Verbrauch führen - nur aktivieren, wenn es entsprechende Exceptions gab) [J/N]  N

Durch Bestätigung der folgenden Option wird die Verarbeitung fortgesetzt. Sie bietet die Möglichkeit die zuvor angegebenen Parameter/Optionen nochmals zu prüfen:

Soll die Verarbeitung fortgesetzt werden? [J/N]  J

Die abschließende Frage, ob die Dokumente tatsächlich gelöscht werden sollen, ist eine zusätzliche Sicherheitsabfrage und wird in diesem Szenario mit “J” beantwortet:

Dokumente werden geloescht. Sicher das diese Dokumente gelöscht werden sollen? [J/N] J

Ergebnis: Als Ergebnis der oben beschriebenen Ausführung wird lediglich die folgende Meldung ausgegeben:

******************* Abschlussbericht - Indizierung ********************************************
Ende des Löschvorgangs um 2020-08-07 09:30:39.333
Verarbeitungszeit: 0 s
******************************************************

Wurde zuvor einer abschließenden Optimierung des Index zugestimmt, so wird ebenfalls über dessen Abschluss informiert.

Der Index sollte nach dem Löschen von Einträge gesichtet werden, bevor er wieder der B2B zur Verfügung gestellt oder weiter mit dem IndexRepairKit bearbeitet wird.

Zusammenführen mehrerer Indizes

Ausgangslage:

Das Zusammenführen mehrerer Indizes ist sinnvoll, um mehrere inhaltlich klar voneinander abgegrenzte Indizes in einem zu vereinen. So wurden z. B. für mehrere verschiedene Zeiträume Indizes erstellt, die nun in einem Index zusammengefasst und der B2B zur Verfügung gestellt werden sollen.

Ausführung:

Nach dem Start des IndexRepairKits ist zunächst die Option “3” auszuwählen:

******************** ReIndexer-Tool ***************
Mit diesem Tool können Sie:
1) Nicht indizierte Nachrichten aus der B2B Engine nachindizieren
2) Indizierte Nachrichten aus dem Index löschen, um Speicherplatz zurückzugewinnen
3) Mehrere Indexdateien zusammenführen
4) Einen korrupten Index reparieren (EXPERIMENTELL! NUTZEN AUF EIGENE VERANTWORTUNG!)
Was möchten Sie tun? [1-4] 3

Anschließend ist das Verzeichnis anzugeben, in dem sich die Verzeichnisse der zusammenzuführenden Indizes befinden:

Die zu mergenden Indizes müssen sich unterhalb eines Verzeichnis befinden.
Wo liegen die zu mergenden Indizes? C:\temp\idx_to_merge

In der folgenden Option ist das Verzeichnis anzugeben, in das der zusammengeführte Index abgelegt werden soll:

Geben sie den Pfad für den zusammengeführten Index an C:\temp\volltextindex

Durch eine Bestätigung der letzten Option, wird der zusammengeführte Index abschließend optimiert:

Soll der zusammengeführte Index optimiert werden (seehr langwierig, optional) [J/N] J

Eine Optimierung ist sinnvoll, wenn die zusammenzuführenden Indizes zuvor noch nicht optimiert wurden. Die unter dem diesen Hinweis gegeben Informationen gelten auch hier.

Ergebnis: Als Ergebnis werden die einzelnen Aktionen wie im Folgenden beispielhaft ausgegeben:

Adding: full_idx_1
Adding: full_idx_2
Merging added indexes...done
Optimizing index...done
It took: 0 seconds

Auch der bereits erwähnte Fehler kann hier auftreten und entsprechend ignoriert werden.

Prüfung und Reparatur eines Index

Ausgangslage:

Sollte es mal vorkommen, dass es Probleme mit dem Index gibt (weil z. B. entsprechende Fehlermeldungen in der B2B erscheinen), dann kann mithilfe des IndexRepairKits der Index überprüft werden. Es wird angeraten, die Prüfung immer separat durchzuführen und nur im Fall, dass ein korrupter Index identifiziert wird, eine Reparatur in Betracht zu ziehen. Bei einem korrupten Index werden Dokumente nicht korrekt indiziert d.h. sie sind zwar im Index vorhanden, sind aber nicht korrekt in der internen Index-Struktur referenziert. Eine Reparatur, identifiziert diese verwaisten Dokumente, löscht diese und erzeugt eine neue korrekte Index-Struktur.

Eine Reparatur sollte nur dann in Betracht gezogen werden, wenn der Index schnell wieder zur Verfügung stehen muss und fehlende Dokumente zunächst nicht die Priorität haben. Im Falle einer Reparatur sollte aus diesem Grund auch immer eine anschließende Reindizierung vorgenommen werden.

Ausführung:

Nach dem Start des IndexRepairKits ist die Option “4” zu wählen:

 ******************** ReIndexer-Tool ***************
 Mit diesem Tool können Sie:
 1) Nicht indizierte Nachrichten aus der B2B Engine nachindizieren
 2) Indizierte Nachrichten aus dem Index löschen, um Speicherplatz zurückzugewinnen
 3) Mehrere Indexdateien zusammenführen
 4) Einen korrupten Index reparieren (EXPERIMENTELL! NUTZEN AUF EIGENE VERANTWORTUNG!)
 Was möchten Sie tun? [1-4] 4

Anschließend ist der absolute Verzeichnispfad des zu optimierenden Index auszuwählen:

Bitte geben sie den Pfad zum Index an C:\temp\volltextindex

In der nächsten Option ist “1” zu wählen, um den Index zunächst zu prüfen:

Mit diesem Tool können Sie:
1) Den Index auf Validität prüfen
2) Den Index auf Validität prüfen und reparieren
3) Den Index optimieren
Was möchten Sie tun? [1-3] 1

Sollte das Ergebnis der Prüfung, wie im Folgenden beispielhaft dargestellt, positiv ausfallen, muss der Index nicht repariert werden:

Index ist valide
Größe in MB 0.00547027587890625
Anzahl der Dokumente: 16
Enthält gelöschte Dokumente: false

Hierbei ist lediglich die erste Zeile ausschlaggebend.

Wird dort jedoch darauf hingewiesen, dass der Index nicht valide ist, dann ist das IndexRepairKit erneut zu starten und in der dritten Option ist “2” auszuwählen:

Mit diesem Tool können Sie:
1) Den Index auf Validität prüfen
2) Den Index auf Validität prüfen und reparieren
3) Den Index optimieren
Was möchten Sie tun? [1-3] 2

Ergebnis: Als Ergebnis wird zunächst die obige Ausgabe wiederholt und im Erfolgsfall durch die folgende Ausgabe ergänzt werden:

Index fixing finished!

Eine abschließende Sichtung des Index sollte das Ergebnis bestätigen und der Index kann der B2B wieder zur Verfügung gestellt werden.

Optimierung eines Index

Ausgangslage:

Gelegentlich ist es ratsam, den Index zu optimieren. Insbesondere wenn zuvor Löschoperationen vorgenommen wurden (siehe auch diesen Hinweis) oder der Zugriff (z. B. Suche im B2B-Monitor) zu langsam ist.

Ausführung:

Nach dem Start des IndexRepairKits, ist die Option “4” auszuwählen:

******************** ReIndexer-Tool ***************
Mit diesem Tool können Sie:
1) Nicht indizierte Nachrichten aus der B2B Engine nachindizieren
2) Indizierte Nachrichten aus dem Index löschen, um Speicherplatz zurückzugewinnen
3) Mehrere Indexdateien zusammenführen
4) Einen korrupten Index reparieren (EXPERIMENTELL! NUTZEN AUF EIGENE VERANTWORTUNG!)
Was möchten Sie tun? [1-4] 4

Anschließend ist der absolute Verzeichnispfad des zu optimierenden Index auszuwählen:

Bitte geben sie den Pfad zum Index an C:\temp\volltextindex

In der folgenden Option, kann nun durch die Auswahl der Option “3” die Optimierung des Index gestartet werden:

Mit diesem Tool können Sie:
1) Den Index auf Validität prüfen
2) Den Index auf Validität prüfen und reparieren
3) Den Index optimieren
Was möchten Sie tun? [1-3] 3

Ergebnis: Als Ergebnis erscheint lediglich die Ausgabe, dass der Index erfolgreich optimiert wurde:

Index erfolgreich optimiert

Als Überprüfung kann der Index nun gesichtet werden und anschließend wieder der B2B zur Verfügung gestellt werden.

Trouble Shooting

Der Reindizierer schreibt direkt in den Index und nutzt nicht die Puffertabelle. (Kann also auch ohne B2B laufen), daher muss das Tool direkten Zugriff zum Indexverzeichnis haben.

Bei Fehlern mit einem Lock sollten die Angaben zur Anzahl der Nachrichten pro Commit und dem Zeitraum pro Abfrage variiert werden.

Bei NullPointerException und Problemen mit Messages sollten die Global Properties B3P_REPORTING_DB_ für alle verschiedenen Daten überprüft werden. Wenn die Reportingdatenbank-properties nicht benötigt werden, sollten sie entfernt werden. Alternativ sollten sie so korrigiert werden, dass mit den Daten der von der B2B genutzten Datenbank übereinstimmen (siehe tomcat/conf/Catalina/localhost/b2bbp-engine.xml). (Dieses Problem sollte bei neuem B2B-Deployment nicht auftreten können.)

View Me   Edit Me