Voorkom dat je extra moet betalen door ongebruikte opslag terug te winnen
Een standaard ServiceNow-instance kan groeien tot 4 TB voordat ServiceNow bij je aanklopt om te melden dat je instance te groot wordt en dat je extra capaciteit moet aanschaffen om je database op te slaan.
Geen paniek. 4 TB is veel, en ik heb met klanten gewerkt die hun instance al tientallen jaren draaien en nauwelijks extra opschoning hebben gedaan, behalve wat oude tickets en de standaard OOB-opschoning.
Onlangs werden we echter gevraagd om te kijken naar de instance van een klant die al extra opslag had gekocht en zelfs met ServiceNow in gesprek was om die extra opslag opnieuw uit te breiden. Hun database was gegroeid tot 6,9 TB. De teams die aan het platform werkten, hadden al extra opschoningsregels geïmplementeerd om oude records (en bijlagen!) te verwijderen die niet langer bewaard hoefden te worden, maar dit resulteerde niet in een voldoende vermindering van de database-footprint om extra kosten te voorkomen.
Er is documentatie beschikbaar over database-footprints (bekijk zeker de uitgebreide bibliotheek met Community-artikelen van Mark Roethof), maar een artikel van Dominik Simunek dat ik toevallig tegenkwam, bleek voor ons een enorme vondst te zijn (link onderaan deze blog). Hij gaf inzicht in ServiceNow Database Compaction, waarmee we 2 TB opslagruimte hebben teruggewonnen op onze instance (ja, TWEE TERABYTE, geen typfout).
En alles wat we hoefden te doen, was enkele systeemproperties toevoegen aan de instance en deze optimaliseren voor onze tabellen. Lees vooral verder als je benieuwd bent hoe je dit zelf ook kunt doen (indien nodig).
Databases groeien. Data wordt toegevoegd en verwijderd. Maar bij het verwijderen van data krijg je de gebruikte opslagruimte niet automatisch terug. Database Compaction geeft die ruimte wel terug.
TABELLEN
Er zijn een aantal tabellen die je kunt gebruiken om inzicht te krijgen in wat er gebeurt met de databasegrootte van je instance.
[sys_physical_table_stats] – toont de tabelgrootte in GB, het aantal records (in duizenden) en de geschatte hoeveelheid GB die kan worden teruggewonnen. Houd er rekening mee dat deze waarden kunnen afwijken van de daadwerkelijke data in de tabel of van het database-footprintoverzicht in NowSupport.
[sys_schema_change] – toont wijzigingen aan tabellen via verschillende Alter Types. Als je ‘Compact Table’ selecteert als Alter Type, zie je welke tabellen zijn aangepast door de Database Compaction-job.
[sys_compaction_run] – toont de tabellen waarop Database Compaction is uitgevoerd. Je ziet start- en eindtijd en, voor ons het belangrijkst, de reden waarom een tabel niet is gecompacteerd (de job controleert elke tabel of compaction nodig is).
PROPERTIES
De tabel [sys_compaction_run] laat zien waarom een tabel niet wordt gecompacteerd. Dat is gebaseerd op meerdere voorwaarden die standaard worden bepaald door instellingen. Deze instellingen kunnen worden aangepast (zonder prestatierisico’s, zo hebben wij ervaren). Hiervoor moet je enkele systeemproperties aanmaken. Deze bestaan om onduidelijke redenen niet standaard OOB.
| 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 |
Met deze standaardinstellingen worden dagelijks maximaal 5 tabellen gecompacteerd, met maximaal 100 miljoen records en een maximale grootte van 100 GB, mits er minstens 10 GB kan worden teruggewonnen en dat minimaal 50% van de tabelgrootte is.
Zoals je kunt voorstellen zorgt dit voor enige Database Compaction, maar sluit het ook veel tabellen uit vanwege de voorwaarden.
Wij hebben deze waarden aangepast om meer tabellen toe te laten en sneller ruimte terug te winnen. Met maximaal 8 tabellen per dag, een maximum van 500 miljoen records, een maximale grootte van 1 TB, een minimale reclaim-percentage van 10% en een minimale reclaim-grootte van 5 GB waren we verbaasd over de resultaten.
Binnen twee weken hebben we 2 TB opslagruimte teruggewonnen door slechts 6 systeemproperties aan te maken en te optimaliseren. Een reductie van 28%, waarmee onze klant weer compliant was.
Benieuwd welke tabellen het grootst zijn in jouw instance? Bekijk het OOB-dashboard ‘Telemetry – Table Growth’. Maar zoals altijd: als je zaken bespreekt met ServiceNow, gebruik dan de Database Footprint-data uit NowSupport. De data in je instance is indicatief; het exacte overzicht vind je daar.
Dominik Simunek’s blog (highly recommended read!)
ServiceNow Database Compaction
