Fehleranalyse, wenn die DB-Tabelle B2BBP_CCM_INDEX_SYNC (Queue für CCM-Index) voll läuft

Einleitung

Die Indizierung von Nachrichten im CCM-Index läuft über die Datenbanktabelle B2BBP_CCM_INDEX_SYNC. Manchmal ist die Verarbeitung der Daten in dieser Tabelle durch den IndexServiceCCM gestört, und die Anzahl Datensätze steigt kontinuierlich an. Wenn der Verdacht besteht, dass die DB-Tabelle B2BBP_CCM_INDEX_SYNC volläuft und damit die Indizierung im CCM-Index blockiert ist, sollten die folgenden Dinge geprüft werden. Es wird vorausgesetzt, dass der CCM-Index im Standardverzeichnis tomcat_all/index/ccm_index_pre liegt.

Prüfung, ob CCM-Index_Job korrekt arbeitet

  • Services: Ist der CCM-Index-Job (INDEX-Service ccm_index_pre) aktiviert (Startup = true)?
  • Lock-Table-Monitor: Ist der CCM-Index-Job nicht dauerhaft gelockt (Datum der letzten Änderung aktuell)?
  • Beliebiger CCM-Arbeitsvorrat: Ist die Anzahl Nachrichten in der CCM_INDEX_SYNC-Tabelle klein (< 1000) oder 0? Dieser Wert kann im Kopfteil jedes CCM Arbeitsvorrats abgelesen werden.
  • Beliebiger CCM-Arbeitsvorrat: Ist das Datum der ältesten Nachricht aktuell und ändert sich (-> aktualisieren); Dieser Wert und der Aktualisierungsbutton findet sich ebenfalls im Kopfteil jedes CCM-Arbeitsvorrats.
  • DB, Tabelle B2BBP_CCM_INDEX_SYNC: Verschwinden die ältesten Nachrichten aus der Tabelle?
  • B2B-Logs: Feststellen, auf welchem Knoten der CCM-Index-Job läuft. Prüfen, ob CCM-Fehler vorhanden sind
  • Index-Management, Übersicht: Wie groß ist der CCM-Index (wieviele GB); Vorsicht!!! bei großen Prodsystemen kann das sehr lange dauern und Speicher verbrauchen.
  • Index-Management, Dokumente: Steigt die Anzahl der Dokumente mit der Zeit?
  • Index-Management, Dokumente: Wurde das letzte Dokument vor kurzem ge-“added”?
  • Index-Management, Suche: Suchen, ob aktuelle Dokumente im Index sind (suchen nach Tagesdatum, z.B. B3P.Date:20170504 AND B3P.Time:12*)
  • Index-Management, Suche: Wie alt sind die ältesten Nachrichten im CCM-Index (werden die noch gebraucht?); Suche nach B3P.Date:2014* zeigt die Anzahl Nachrichten in diesem Jahr; wir empfehlen, nur das aktuelle und das vergangene komplette Jahr im Index vorzuhalten.

Fehlerbilder und Maßnahmen

  • Lock-Table-Monitor: Der CCM-Index-Job ist dauerhaft gelockt? (Datum der letzten Änderung älter als 1h)
    -> CCM-Index-Job neu starten (Im Service Startup-Häkchen wegnehmen, 1 min warten, Startup-Häkchen wieder setzen) -> Wenn das nicht hilft: Knoten neu starten
    -> Wenn das nicht hilft: Sicherstellen, dass nur ein CCM-Index-Job auf den Index zugreift, Index-Job stoppen, im Dateisystem in tomcat_all/index/ccm_index_pre die Datei write.lock löschen, Index-Job wieder starten, evtl. Knoten neu starten.
  • Alles arbeitet korrekt, aber sehr langsam
    Mögliche Gründe:
    DB, Tabelle B2BBP_CCM_INDEX_SYNC: Es sind viele Updates in der Tabelle. Diese werden sehr langsam abgearbeitet und blockieren die Indizierung von neuen Nachrichten. -> Abwarten, bis Updates verarbeitet worden sind, dann sollten die anderen Nachrichten den Rückstand schnell aufholen.
    ODER
    Es gibt OutOfMemoryErrors im Log-File des CCM-Knotens. Dies kann durch zu viele große Nachrichten gleichzeitig entstehen
    -> kurzfristig: Am CCM-Index-job die Anzahl der in einem Batch verarbeiteten Nachrichten herabsetzen (B3P_MAX_FILES)
    -> mittelfristig: Arbeitsspeicher des CCM-Knotens erhöhen. Wir empfehlen mittlerweile 16 GB für CCM-Knoten und 12-16 GB für UI-Knoten.
    ODER
    CCM-Index ist zu groß, enthält Daten aus mehr als 2 Jahren
    -> Index verkleinern und optimieren (Geht nicht ad Hoc -> Projekt)

Typen von Einträgen

In den DB-Tabellen B2BBP_CCM_INDEX_SYNC und B2BBP_CCM_INDEX_SYNC_BU gibt es folgende Typen von Einträgen (“Operation”)

  • ADD Added Documents: Alle Dokumente, die neu in den Index aufgenommen werden
  • UPD Updates: Wenn in der B2B der Status von Dokumenten verändert wird (CONTROL kommt an, manuelle Bearbeitung, Neustart) muss das zugehörige Dokument im CCM angepasst werden. Dies geschieht über Updates.
  • manchmal sehr langsam in der Abarbeitung, z.B. wenn viele Vorgänge in einer Nachricht sind; die Verarbeitung eines Updates besteht aus den Schritten: Suche, Dokument löschen, verändertes Dokument hinzufügen (=ADD)
  • wenn große Mengen Updates gleichzeitig ins System kommen, stoppt die Verarbeitung der normalen Dokumente, bis der Update Block durch ist.
  • Updates können erzeugt werden durch
    • manuelle Statusänderung (Clearing)
    • StatusSync, Rückmeldungen aus dem ISU
    • Neustart von Nachrichten
    • Nachforderungsmails: Setzen des Notify-Flags
  • TS TimeStamp: Spezieller Typ von Update. Wenn für eine Nachricht in der B2B die CONTRL-Frist abläuft und der BS von CTW (warten auf CONTRL) auf CTN (CONTROL nicht rechtzeitig) gesetzt wird.
  • UDD Spezielle Typ von Update (?); meist vor- oder rückdatiert, hat niedrigere Prio, blockiert nicht die ABarbeitung der B2BBP_CCM_INDEX_SYNC-Tabelle

Spezielle Maßnahmen

Updates in DB-TEMP-Tabelle zwischenlagern

  • Neue DB-Tabelle B2BBP_CCM_INDEX_SYNC_TEMP anlegen (mit Skript von B2BBP_CCM_INDEX_SYNC)
  • Störende Updates von B2BBP_CCM_INDEX_SYNC in B2BBP_CCM_INDEX_SYNC_TEMP kopieren
  • Kopierte Updates aus B2BBP_CCM_INDEX_SYNC löschen
    -> Der Stau sollte damit behoben sein und die normalen Nachrichten sollten den Rückstand schnell aufholen
  • Später können die Updates in kleinen Mengen wieder in die B2BBP_CCM_INDEX_SYNC zurück kopiert werden.
View Me   Edit Me