Datenbank-Verfügbarkeitsverlust und seine Auswirkungen
Die DPM Lösung verwendet zwei Datenbanken: die DPM Datenbank, die bei der anfänglichen Bereitstellung der Lösung erstellt wird, und die ThingWorx Datenbank. Eine Datenbank kann aus vielen Gründen nicht mehr verfügbar werden, wie regelmäßige Datenbankwartung, Verlust der Netzwerkverbindung oder Datenträgerfehler. Falls eine der beiden Datenbanken nicht mehr verfügbar ist, besteht die Möglichkeit des Verlusts von Daten, die durch Datenautomatisierung eingehen, oder der Duplizierung dieser Daten.
• Wenn verlorene oder duplizierte Daten Projektauftrags-, Material-Master- oder Zielmengenereignisse enthalten, kann es sein, dass alle nachfolgenden Ereignisse und Anzahlen anhand der falschen Projektaufträge oder Materialien aufgezeichnet werden.
• Wenn verlorene oder duplizierte Daten Produktionszahl- oder Ausschusszahlereignisse enthalten, kann es sein, dass der Wert für die Produktions- und Ausschusszähler inkorrekt wird. Bei Rollover-Zählern hat dies einen negativen Welleneffekt. Weitere Informationen zu Rollover-Zählern finden Sie unter
Datenautomatisierung einrichten.
Sowohl DPM als auch ThingWorx verfügen über Prozesse, um Datenverlust oder duplizierte Daten in den meisten Szenarios zu vermeiden, wenn eine Datenbank nicht mehr verfügbar ist:
• Wenn die DPM Datenbank zu einem beliebigen Zeitpunkt während der Stapelverarbeitung nicht verfügbar ist, wird die Stapelverarbeitung zu diesem Zeitpunkt beendet. Die Eigenschaft PTCLastProcessedEventTimestamp wird auf den Zeitstempel des letzten erfolgreich verarbeiteten Ereignisses festgelegt. Wenn der Zeitgeber für Automatisierungsereignisse das nächste Mal ausgelöst wird, wird der Wert-Stream nach unverarbeiteten Ereignisdaten abgefragt. Alle Ereignisse mit einem Zeitstempel, der nach der Verarbeitung des aktuellen Werts der Eigenschaft PTCLastProcessedEventTimestamp auftritt, einschließlich der Ereignisse, die noch nicht verarbeitet wurden, als die Stapelverarbeitung zuvor abgebrochen wurde, werden verarbeitet.
• Wenn die ThingWorx Datenbank nicht mehr verfügbar ist, werden Ereignisdaten in die Wert-Stream-Warteschlange geschrieben. ThingWorx hat einen Wiederholungsmechanismus, um die Verbindung zur Datenbank wiederherzustellen. Wenn die Datenbank verfügbar wird, werden Einträge aus der Wert-Stream-Warteschlange zum Wert-Stream hinzugefügt.
In diesem Thema werden die
ungewöhnlichen Szenarien beschrieben, in denen die Nichtverfügbarkeit der Datenbank zu Datenverlusten oder duplizierten Daten führen kann. Es wird darüber informiert, wie
ermittelt werden kann, wann diese Szenarien aufgetreten sind, und wie sich die
daraus ergebenden Datenprobleme beheben lassen.
Ablauf der Datenautomatisierung
Für ein besseres Verständnis dieser Szenarien ist es hilfreich, sich mit dem allgemeinen Ablauf für die Verarbeitung von Ereignisdaten aus der Datenautomatisierung vertraut zu machen. Jeder Schrittmacher, der für die Datenautomatisierung konfiguriert ist, führt den folgenden Ablauf aus:
1. Ereignisdaten werden per Datenautomatisierung empfangen. Daten guter Qualität werden in die Wert-Stream-Warteschlange geschrieben. Einträge aus der Warteschlange werden dem Wert-Stream hinzugefügt.
2. Der Zeitgeber für Automatisierungsereignisse wird ausgelöst, und die
Stapelverarbeitung beginnt:
a. Der Wert-Stream wird nach unverarbeiteten Ereignisdaten abgefragt. Unverarbeitete Ereignisse sind Ereignisse, die einen Zeitstempel aufweisen, der nach dem aktuellen Wert der Eigenschaft PTCLastProcessedEventTimestamp auftritt.
b. Die abgefragten Ereignisse werden für jeden Zeitstempel in der Reihenfolge verarbeitet.
c. Produktionszahlen und Ausschusszahlen werden
gepuffert, um die Anzahlen für jeden Zähler in Gruppen zu konsolidieren.
d. Die gruppierten Anzahlen werden in die DPM Datenbank eingefügt.
3. Die Eigenschaft PTCLastProcessedEventTimestamp wird aktualisiert, nachdem jedes Ereignis erfolgreich verarbeitet wurde. Für Produktionszahlen und Ausschusszahlen wird die Eigenschaft PTCLastProcessedEventTimestamp erst dann aktualisiert, wenn alle gruppierten Anzahlen in die Datenbank eingefügt wurden. Der neueste Zeitstempel aller gepufferten Gruppen wird als Wert der Eigenschaft PTCLastProcessedEventTimestamp festgelegt.
Szenarien
In der folgenden Tabelle werden ungewöhnliche Szenarien beschrieben, die zu verlorenen oder duplizierten Daten führen können. Beachten Sie, dass der Ablauf der Datenautomatisierung bei jedem Schrittmacher erfolgt, der für die Datenautomatisierung konfiguriert ist. Je nachdem, wann ein Szenario auftritt, kann es sich auf einige Schrittmacher auswirken, während andere unberührt bleiben.
|
Szenario
|
Beschreibung
|
Ergebnis
|
|
Die DPM Datenbank ist bei der Verarbeitung mehrerer Ereignisse mit demselben Zeitstempel nicht mehr verfügbar.
|
Jedes per Datenautomatisierung empfangene Ereignis hat einen Zeitstempel. Es ist jedoch möglich, dass mehrere Ereignisse denselben Zeitstempel aufweisen, was allerdings selten vorkommt. Wenn dies geschieht, werden Ereignisse mit demselben Zeitstempel in der folgenden Reihenfolge verarbeitet: Projektauftrag, Material-Master, Zielmenge, Verfügbarkeit und schließlich Produktionszahlen und Ausschusszahlen.
Wenn mehrere Ereignisse mit demselben Zeitstempel vorhanden sind, wird die Eigenschaft PTCLastProcessedEventTimestamp nach der Verarbeitung des ersten Ereignisses mit diesem Zeitstempel aktualisiert.
Wenn die DPM Datenbank nicht mehr verfügbar ist, bevor alle Ereignisse mit demselben Zeitstempel erfolgreich verarbeitet wurden, gehen alle unverarbeiteten Ereignisse mit diesem Zeitstempel verloren, einschließlich der Produktionszahl- und der Ausschusszahlereignisse mit diesem Zeitstempel. Dies liegt daran, dass beim nächsten Auslösen des Zeitgebers für Automatisierungsereignisse während der Stapelverarbeitung Ereignisse mit Zeitstempeln abgefragt werden, die nach dem aktuellen Wert der Eigenschaft PTCLastProcessedEventTimestamp auftreten.
|
Alle unverarbeiteten Ereignisse, die denselben Zeitstempel wie die Eigenschaft PTCLastProcessedEventTimestamp aufweisen, einschließlich Produktionszahl- und Ausschusszahlereignisse, gehen verloren.
|
|
Die ThingWorx Datenbank ist nicht verfügbar, und die Wert-Stream-Warteschlange wird voll.
|
Wenn die ThingWorx Datenbank nicht mehr verfügbar ist, werden aus der Datenautomatisierung kommende Ereignisse weiterhin zur Wert-Stream-Warteschlange hinzugefügt, bis die Warteschlangengröße erreicht ist. Wenn die Datenbank wieder verfügbar wird, wird die Wert-Stream-Warteschlange verarbeitet, damit Einträge zum Wert-Stream hinzugefügt werden können, wo sie während der Stapelverarbeitung abgefragt werden, wenn der Zeitgeber für Automatisierungsereignisse das nächste Mal ausgelöst wird. Wenn die Wert-Stream-Warteschlange voll ist, werden alle neuen Ereignisse, die aus der Datenautomatisierung stammen, zurückgewiesen.
|
Zurückgewiesene Ereignisse gehen verloren.
|
|
Die ThingWorx Datenbank ist nicht verfügbar, und der ThingWorx Server wird neu gestartet.
|
Wenn der ThingWorx Server neu gestartet wird, gehen alle Inhalte in der Wert-Stream-Warteschlange und in der Persistenz-Warteschlange verloren. Einträge, die zum Wert-Stream hinzugefügt, aber noch nicht verarbeitet wurden, werden beibehalten.
|
Alle Daten in der Wert-Stream-Warteschlange und der Persistenz-Warteschlange gehen verloren.
|
|
Die ThingWorx Datenbank ist nicht verfügbar, die Anzahl der Verbindungswiederholungen wurde ausgeschöpft, und ThingWorx wird heruntergefahren.
|
Wenn die Anzahl der Wiederholungsversuche, die für den Wiederholungsmechanismus der ThingWorx Datenbank konfiguriert sind, ausgeschöpft ist, wird der ThingWorx Server heruntergefahren. Weitere Informationen zum ThingWorx Wiederholungsmechanismus finden Sie unter Daten in ThingWorx speichern im ThingWorx Hilfe-Center. |
Alle Daten in der Wert-Stream-Warteschlange und der Persistenz-Warteschlange gehen verloren.
Alle neuen Ereignisse, die, während ThingWorx heruntergefahren wird, aus der Datenautomatisierung kommen, gehen verloren.
|
|
Die ThingWorx Datenbank ist nicht verfügbar, bevor die Persistenz-Warteschlange zum Aktualisieren der Eigenschaft PTCLastProcessedEventTimestamp verarbeitet wird, und der ThingWorx Server wird neu gestartet.
|
Wenn die ThingWorx Datenbank nicht verfügbar ist, bevor die Persistenz-Warteschlange zum Aktualisieren der Eigenschaft PTCLastProcessedEventTimestamp verarbeitet wird, und der ThingWorx Server neu gestartet wird, geht der Inhalt der Persistenz-Warteschlange verloren. Der Wert der Eigenschaft PTCLastProcessedEventTimestamp bleibt beim vorherigen Wert. Dies bedeutet, dass Ereignisse mit nach dem Wert der Eigenschaft PTCLastProcessedEventTimestamp auftretenden Zeitstempeln, die bereits verarbeitet und zur DPM Datenbank hinzugefügt wurden, erneut verarbeitet und erneut zur Datenbank hinzugefügt werden.
|
Erneut verarbeitete Ereignisse erstellen duplizierte Daten.
|
Datenbank-Verfügbarkeitsvorfälle identifizieren
Sie können auf zweierlei Weise identifizieren, ob ein Datenbank-Verfügbarkeitsereignis zu Datenverlust oder Datenduplizierung geführt hat:
• Überwachen Sie das
Produktions-Dashboard während der Produktion. Bediener automatisierter Schrittmacher können falsche Daten identifizieren, sowohl wenn sie in den aktuellen Produktionsblöcken als auch in den erweiterten Ereignisprotokollen angezeigt werden.
• Überprüfen Sie die ThingWorx Protokolle auf Fehler aufgrund von Datenbank-Nichtverfügbarkeit, insbesondere wenn Sie von Datenbankwartung oder anderen Aktionen Kenntnis haben, die sich auf die Verfügbarkeit der Datenbank auswirken können. Identifizieren Sie die betroffenen Schrittmacher, und prüfen Sie die Daten im Produktions-Dashboard, um festzustellen, ob fehlende oder duplizierte Daten vorhanden sind.
Datenprobleme beheben
Zur Vermeidung solch seltener Szenarien gibt es zwar keine garantierten Strategien, wenn sie eingetreten sind, gibt es jedoch Aktionen, die Sie ergreifen können, um die Folgen zu beheben.
• Setzen Sie falsche Produktions- und Ausschusszähler für einzelne Schrittmacher zurück:
1. Halten Sie den Kepware Server an.
2. Navigieren Sie in ThingWorx Composer zum Schrittmacher-Ding.
3. Fügen Sie unter Eigenschaften eine Zeile zur Infotable der Eigenschaft PTCLastAutomationProcessedValues mit den folgenden Informationen für jeden Zähler hinzu, den Sie zurücksetzen:
▪ propertyName – Geben Sie für Produktionszähler PTCPoductionCount ein. Geben Sie für Ausschusszähler den Namen der Ausschusseigenschaft ein.
▪ value – Der Wert, auf den der Zähler zurückgesetzt werden soll
▪ jobOrderUid – Dieses Feld wird von DPM ignoriert.
4. Starten Sie den Kepware Server.
• Geben Sie die fehlenden Daten für einzelne Schrittmacher manuell über das
Produktions-Dashboard ein. Bei der Produktion aus den letzten 24 Stunden können Verlustereignisse, Produktionszahlen und Ausschusszahlen, die sich in den letzten 24 Stunden ereignet haben, für jeden Schrittmacher manuell eingegeben werden. Außerdem können historische Ausschussereignisse bis zu einer Woche hinzugefügt werden.
• Entfernen Sie duplizierte Produktionszahlen für einzelne Schrittmacher mithilfe des
Produktions-Dashboards manuell. Für den aktuellen Produktionsblock können Sie die
Produktionszahl aus dem Fensterbereich
Produktionseintrag des Produktions-Dashboards entfernen. Sie können zum Entfernen der Produktionszahl der letzten 24 Stunden das Fenster
Zeitverlustrechnung verwenden.