Évitez d’acheter du stockage supplémentaire en récupérant l’espace inutilisé
Une instance ServiceNow standard peut atteindre 4 To avant que ServiceNow ne vous contacte pour vous signaler que votre instance devient trop volumineuse et que vous devez acheter de la capacité supplémentaire pour stocker votre base de données.
Pas d’inquiétude. 4 To est une quantité importante, et j’ai travaillé avec des clients dont l’instance fonctionne depuis des décennies sans réel nettoyage supplémentaire, à part quelques anciens tickets et le nettoyage standard OOB.
Récemment, nous avons toutefois été sollicités pour analyser l’instance d’un client ayant déjà acheté du stockage supplémentaire et discutant avec ServiceNow pour encore l’étendre. Leur base de données atteignait 6,9 To. Les équipes avaient déjà mis en place des règles de nettoyage supplémentaires pour supprimer les anciens enregistrements (et pièces jointes) devenus inutiles, mais cela ne réduisait pas suffisamment l’empreinte de la base de données pour éviter des coûts supplémentaires.
Il existe de la documentation sur les empreintes de bases de données (consultez notamment les nombreux articles de la Community écrits par Mark Roethof), mais un article de Dominik Simunek que j’ai découvert par hasard s’est révélé être une véritable mine d’or (lien en bas de ce blog). Il nous a apporté un éclairage précieux sur la Database Compaction de ServiceNow, nous permettant de récupérer 2 To d’espace disque sur notre instance (oui, DEUX TÉRAOCTETS).
Et tout ce que nous avons eu à faire a été d’ajouter quelques propriétés système à l’instance et de les ajuster pour qu’elles soient optimisées pour nos tables. Lisez la suite si vous êtes curieux de savoir comment faire de même.
Les bases de données grandissent. Les données sont ajoutées et supprimées. Mais supprimer des données ne libère pas automatiquement l’espace utilisé. La Database Compaction permet justement de récupérer cet espace.
TABLES
Plusieurs tables permettent d’analyser ce qui se passe concernant la taille de la base de données.
[sys_physical_table_stats] – affiche la taille des tables en Go, le nombre de lignes (en milliers) et l’estimation de l’espace récupérable. Ces valeurs peuvent différer des données réelles ou de l’aperçu de l’empreinte dans NowSupport.
[sys_schema_change] – affiche les modifications de tables via différents types d’alter. En sélectionnant « Compact Table », vous voyez les tables modifiées par le job de Database Compaction.
[sys_compaction_run] – affiche les tables traitées par la Database Compaction, avec les heures de début et de fin et, point crucial, la raison pour laquelle une table n’a pas été compactée.
PROPRIÉTÉS
La table [sys_compaction_run] indique pourquoi une table n’est pas compactée, sur la base de conditions définies par des paramètres par défaut. Ces paramètres peuvent être modifiés sans impact négatif sur les performances, d’après notre expérience. Il est nécessaire de créer manuellement certaines propriétés système qui n’existent pas 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 |
Avec les paramètres par défaut, jusqu’à 5 tables par jour sont compactées, avec un maximum de 100 millions de lignes et une taille maximale de 100 Go, à condition qu’au moins 10 Go et 50 % de la taille de la table puissent être récupérés.
Nous avons ajusté ces valeurs pour inclure davantage de tables et accélérer la récupération. Avec 8 tables par jour, jusqu’à 500 millions de lignes, une taille maximale de 1 To, un seuil de récupération de 10 % et 5 Go, les résultats ont été impressionnants.
En deux semaines, nous avons récupéré 2 To d’espace en optimisant seulement 6 propriétés système, soit une réduction de 28 %.
Pour identifier les tables les plus volumineuses, consultez le tableau de bord OOB « Telemetry – Table Growth ». Pour toute discussion avec ServiceNow, basez-vous cependant sur les données officielles de Database Footprint dans NowSupport.
Dominik Simunek’s blog (highly recommended read!)
ServiceNow Database Compaction
