Vermeiden Sie zusätzliche Kosten durch Rückgewinnung ungenutzten Speicherplatzes

Eine Standard-ServiceNow-Instanz kann bis zu 4 TB groß werden, bevor ServiceNow darauf hinweist, dass die Instanz zu groß wird und zusätzlicher Speicher erworben werden muss.

Keine Sorge. 4 TB sind eine Menge, und ich habe mit Kunden gearbeitet, deren Instanzen seit Jahrzehnten laufen und kaum zusätzliche Bereinigungen hatten, abgesehen von alten Tickets und der standardmäßigen OOB-Bereinigung.

Kürzlich wurden wir jedoch gebeten, uns eine Instanz anzusehen, die bereits zusätzlichen Speicher gekauft hatte und sogar über eine weitere Erweiterung sprach. Die Datenbank war auf 6,9 TB angewachsen. Die Teams hatten bereits zusätzliche Cleanup-Regeln eingeführt, um alte Datensätze und Anhänge zu löschen, doch das reichte nicht aus, um die Datenbankgröße ausreichend zu reduzieren.

Es gibt Dokumentation zu Datenbank-Footprints (insbesondere die Community-Artikel von Mark Roethof), doch ein Artikel von Dominik Simunek, den ich zufällig entdeckte, erwies sich als echter Schatz. Er gab uns Einblick in die ServiceNow Database Compaction und ermöglichte es uns, 2 TB Speicherplatz zurückzugewinnen.

Dazu mussten lediglich einige System Properties hinzugefügt und optimiert werden. Lesen Sie weiter, wenn Sie wissen möchten, wie das funktioniert.

Datenbanken wachsen. Daten werden hinzugefügt und gelöscht. Beim Löschen wird der Speicherplatz jedoch nicht automatisch freigegeben. Database Compaction gibt diesen Speicher zurück.

TABELLEN
Mehrere Tabellen helfen dabei, den Zustand der Datenbankgröße zu analysieren.

[sys_physical_table_stats] – zeigt Tabellengröße in GB, Zeilenanzahl (in Tausendern) und geschätzten rückgewinnbaren Speicherplatz.

[sys_schema_change] – zeigt Tabellenänderungen. Mit dem Alter Type „Compact Table“ sehen Sie die durch Database Compaction geänderten Tabellen.

[sys_compaction_run] – zeigt, auf welchen Tabellen die Kompaktierung ausgeführt wurde sowie Gründe, warum Tabellen übersprungen wurden.

PROPERTIES
Die Tabelle [sys_compaction_run] zeigt, warum Tabellen nicht kompaktieren. Die Bedingungen basieren auf Standardwerten, die angepasst werden können, ohne Performance-Risiken. Dazu müssen bestimmte System Properties manuell erstellt werden.

Property	Description	Default value
glide.db.compaction.criteria.reclaim_size_mb	Minimum reclaim size (MBs) for a table to be eligible for the database compaction	10240
glide.db.compaction.max_tables_compacted_timeframe_days	Number of days for the maximum tables compacted timeframe	1
glide.db.compaction.criteria.max_table_size_mb	Maximum table size (MBs) for a table to be eligible for database compaction	102400 (100 GB)
glide.db.compaction.criteria.reclaim_percentage	Minimum reclaim percentage (%) for the table to be eligible for database compaction	50
glide.db.compaction.criteria.max_row_count	Maximum row count for the table to be eligible for database compaction	100000000 (100 million)
glide.db.compaction.max_tables_compacted	Maximum number of tables to be compacted within the defined timeframe	5

Mit den Standardwerten werden täglich maximal 5 Tabellen mit bis zu 100 Millionen Zeilen und 100 GB Größe kompaktiert, sofern mindestens 10 GB bzw. 50 % der Tabellengröße zurückgewonnen werden können.

Wir haben diese Werte angepasst und konnten innerhalb von zwei Wochen 2 TB Speicherplatz zurückgewinnen, allein durch Optimierung von 6 Properties. Das entsprach einer Reduktion von 28 %.

Die größten Tabellen finden Sie im OOB-Dashboard „Telemetry – Table Growth“. Für Gespräche mit ServiceNow sollten Sie jedoch stets die offiziellen Database-Footprint-Daten aus NowSupport verwenden.

Dominik Simunek’s blog (highly recommended read!)
ServiceNow Database Compaction