Empfohlene Aktivierungen

Um das Datenwachstum zu begrenzen, das mit der häufigen Nutzung von Virtual Agent und Mitarbeiterchatverbunden ist, aktivieren Sie die Bereinigungsaufträge in der folgenden Tabelle:

Welche Tabellen bereinigt werden sollen

Diese Tabellen sollten bereinigt werden, da sie in Instanzen mit langer Ausführungszeit auf Millionen von Datensätzen anwachsen können:

• Agent-Anwesenheitsverlauf [awa_agent_presence_history]
• AWA Dokumentgröße [awa_document_size]
• AWA Arbeitselement [awa_work_item]
• Verbraucher [sys_cs_consumer]
• Verbrauchergerätkontext [sys_cs_consumer_device_context]
• Konversation [sys_cs_conversation]
• Interaktion [interaction]
• Interaktions-JSON-Blob [interaction_json_blob]
• Live-Gruppenprofil [live_group_profile]

Es gibt andere zugehörige Tabellen, z. B. die Tabellen „Konversationsnachricht“ [sys_cs_message] und „Live Feed-Nachricht“ [live_message], die ebenfalls groß werden können. Diese Tabellen haben reference_cascade_rule_delete -Attribute, die bewirken, dass sie als Nebeneffekt der Bereinigung der Tabellen in der vorherigen Liste bereinigt werden.

Welche Datensätze in den Tabellen gelöscht werden sollen

Mit der Auto-Flush-Konfiguration können Sie die Felder Matchfield und Alter in Sekunden auswählen. Das Feld Matchfield entspricht einer Datumsspalte in der Tabelle, und das Feld Alter in Sekunden gibt an, wann die Löschungen ausgelöst werden. Wenn ein Datensatz einen Punkt erreicht, an dem das Feld Matchfield ein Datum aufweist, das weiter in der Vergangenheit liegt als das Feld Alter in Sekunden, löscht die Bereinigung den Datensatz, wenn sie ausgeführt wird.

Idealerweise sollte das Feld Matchfield angeben, wie lange der Datensatz aktiv ist. Die Spalten in der folgenden Tabelle funktionieren gut als Matchfield -Feld für die betreffenden Tabellen, mit der zusätzlichen Bedingung im Feld Bedingungen, wo angegeben.

„interaction.closed_at“ und „sys_cs_conversation.conversation_completed“ sind keine guten Optionen für das Feld „Matchfield“, da sie keine Werte für fehlerhafte Konversationen und einige geschlossene Interaktionen enthalten. Die Lücken können mit Business Rules geschlossen werden, die dieses Datum festlegen, wenn es bei einer entsprechenden Statusänderung leer ist. Verwenden Sie jedoch der Einfachheit halber das Feld sys_updated_on für diese Tabellen.

Andere Tabellen können durch Bedingungen im Statusfeld eingeschränkt werden, die sicherstellen, dass nur geschlossene Chats gelöscht werden. Da Interaktionen im Allgemeinen nie länger als ein paar Tage offen bleiben sollten, können diese Bedingungen ausgelassen werden, um die Abfragen zu vereinfachen und nach der letzten Aktualisierung schneller auszuführen. Der Status in der Tabelle awa_work_item kann wichtiger sein, da auch länger laufende Aufgaben wie Fälle dargestellt werden.

Das Problem mit der Tabelle „sys_cs_consumer“ besteht darin, dass Sie diese Datensätze normalerweise beibehalten möchten, um neue Konversationen vorhandenen Benutzern zuzuordnen, bei Gastbenutzern jedoch für jede Konversation ein anderer Datensatz erstellt wird.

Für die Tabelle „sys_cs_consumer_device_context“ gibt es einen Verweis auf die Tabelle „CS-Verbraucherkonto“ [sys_cs_consumer_account] (die selbst einen Verweis auf die Tabelle „sys_cs_consumer“ enthält), aber der Verweis ist nicht mit reference_cascade_rule=delete markiert. Es wird empfohlen, diese Regel der Verbraucherkontoreferenz hinzuzufügen. Auf diese Weise werden beim Löschen der Datensätze in den Tabellen sys_cs_consumer und sys_cs_consumer_account durch die Bereinigung diese auch gelöscht.

Die Tabellen „awa_agent_presence“ und „awa_agent_channel_availability“ wachsen pro Chat nicht auf die gleiche Weise wie andere Tabellen, sondern werden regelmäßig von der Zuweisungs-Engine aufgerufen und können veraltete Einträge von Benutzern enthalten, die nicht mehr aktiv sind. Lange nicht verwendete Einträge sollten auch hier bereinigt werden. Bei der Spalte awa_agent_channel_availability ist besondere Vorsicht geboten, da sie möglicherweise nicht oft aktualisiert wird. Aus diesem Grund sollte dieser Bereinigung eine zusätzliche Bedingung hinzugefügt werden, damit nur Datensätze entfernt werden können, die inaktiven Benutzern zugeordnet sind.

Wann können die Datensätze sicher gelöscht werden?

Es gibt mehrere Aspekte, um zu bestimmen, wann die Datensätze sicher gelöscht werden können:

• Löschen Sie keine Datensätze für laufende Konversationen.

  Für sitzungsbasierte Chatkonversationen beträgt die Altersgrenze nur einige Tage. Wenn SMS-/Messaging-Konversationen enthalten sind, kann die Altersgrenze einige Wochen oder länger betragen. Eine Möglichkeit, dies auszuwerten, besteht darin, alle Eigenschaften des Formulars com.glide.cs.*_idle_timeout zu durchsuchen und diejenige mit dem höchsten Wert zu suchen.

• Löschen Sie keine Datensätze, die zu Dashboards/Berichten über aktuelle Aktivitäten beitragen.

  Das Dashboard AWA für Interactions-Advanced Analytics enthält einen Indikator für wöchentliche Trends, der drei Monate zurückblickt. Um dies vollständig zu unterstützen, müssen Sie die Interaktions- und awa_work_item-Datensätze mindestens 90 Tage lang aufbewahren.

• Löschen Sie keine Datensätze, wenn deren Daten zur späteren Referenz archiviert werden müssen.

  Das Timing hierfür hängt vom Timing der benutzerdefinierten Logik ab, die für die erforderliche Archivierung hinzugefügt wird. Sie sollten in der Lage sein, dies so einzurichten, dass es früh genug ausgeführt wird, um nicht der entscheidende Faktor zu sein.

Leistungsüberlegungen

Werden sys_updated_on-Indizes für die Tabellen benötigt, in denen sie fehlen?

Tests wurden in einer Instanz mit mehr als 12.000.000 Interaktionen ausgeführt, wobei eine Tabellenbereinigung für eine Tabelle mit einem Index im Feld „sys_updated_on“ (Interaktion) und eine Tabelle ohne Index (interaction_json_blob) konfiguriert wurde. In beiden Fällen überwog die Zeit, die für das Löschen aufgewendet wurde (möglicherweise viele Minuten), bei der ersten und nachfolgenden Ausführung bei weitem mehr als die Zeit, die für das Abfragen der Datensätze aufgewendet wurde (2 Sekunden oder weniger). Angesichts dieses Ergebnisses müssen den Tabellen keine zusätzlichen Indizes hinzugefügt werden, da die Auswirkungen auf die Leistung minimal wären.

Wann sollten der anfängliche und der wiederholte Tabellenbereinigungsauftrag ausgeführt werden?

Normalerweise wird sys_trigger einmal pro Stunde ausgeführt. Wenn eine oder mehrere Bereinigungen für Tabellen mit vielen veralteten Datensätzen festgelegt werden, kann die Anzahl der während dieser ersten Ausführung durchgeführten Löschvorgänge sehr hoch sein und das System zusätzlich belasten. Bevor Sie die Tabellenbereinigungskonfiguration anpassen und aktivieren, ändern Sie diesen Zeitplan für die Tabellenbereinigung vorübergehend so, dass die nächste Ausführung außerhalb der Geschäftszeiten erfolgt (eine Zeit, zu der das System normalerweise einer geringeren Last ausgesetzt ist).

Wenn es keine Ruhezeiten gibt, können einige Eigenschaften für die Tabellenbereinigungen hilfreich sein. Insbesondere begrenzt glide.db.tablecleaner.chunk_delete_max_time_sput, wie lange die Bereinigung versucht, Datensätze während einer einzelnen Ausführung im Batch zu löschen. Der Wert wird in Sekunden angegeben und ist standardmäßig auf 1200 (20 Minuten) festgelegt. Dies bedeutet, dass im Basissystem-Setup die Tabellenbereinigung stündlich für maximal 20 Minuten ausgeführt wird (als Referenz: Während eines Tests konnten in 20 Minuten etwa 400.000 Interaktionen gelöscht werden, einschließlich kaskadierter Löschungen). Wenn 20 Minuten pro Stunde zu aggressiv sind, kann der Eigenschaftswert reduziert werden.