Dans Dynamics AX, il existe un mécanisme de mise en cache dans lequel les tables peuvent être configurées pour être chargées en mémoire et mises en cache. Ce cache est limité à une certaine quantité de Ko pour éviter les problèmes de mémoire. Le paramètre dont je parle est appelé entiretablecache
et charge toute la table en mémoire dès qu'un seul enregistrement est demandé.
Jusqu'à récemment, nous nous sommes appuyés sur certains scripts pour vérifier la taille des tables qui ont ce paramètre pour voir si la taille de la table est supérieure à cette limite.
Maintenant cependant, la compression entre en jeu et des choses comme sp_spaceused ou sys.allocation_units semblent signaler l'espace réellement utilisé par les données compressées.
De toute évidence, le serveur d'applications fonctionne avec des données non compressées, de sorte que la taille des données sur le disque dans SQL Server n'est pas pertinente. J'ai besoin de la taille réelle des données non compressées.
Je connais sp_estimate_data_compression_savings mais comme son nom l'indique, ce n'est qu'une estimation.
Je préférerais avoir une taille aussi correcte que possible.
La seule façon dont je pouvais penser était un SQL dynamique alambiqué créant des tables non compressées avec la même structure que les tables compressées, insérant les données compressées dans cette table fantôme, puis vérifiant la taille de cette table fantôme.
Inutile de dire que cela est un peu fastidieux et prend du temps pour fonctionner sur une base de données de plusieurs centaines de Go.
Powershell pourrait être une option, mais je ne voudrais pas parcourir toutes les tables pour effectuer une select *
sur elles pour vérifier la taille dans le script car cela inonderait simplement le cache et prendrait probablement aussi beaucoup de temps.
En bref, j'ai besoin d'un moyen d'obtenir la taille de chaque table car elle sera une fois non compressée et avec une fragmentation hors de l'équation telle que présentée à l'application, si cela est possible. Je suis ouvert à différentes approches, T-SQL est préféré mais je ne suis pas opposé à Powershell ou à d'autres approches créatives.
Supposons que le tampon dans l'application correspond à la taille des données. Un bigint est toujours la taille d'un bigint, et un type de données de caractère est de 2 octets par caractère (unicode). Les données BLOB prennent également la taille des données, une énumération est fondamentalement un entier et les données numériques sont numériques (38,12), datetime est la taille d'un datetime. De plus, il n'y a pas de NULL
valeurs, elles sont soit stockées sous forme de chaîne vide, 1900-01-01
soit zéro.
Il n'y a pas de documentation sur la façon dont cela est implémenté, mais les hypothèses sont basées sur certains tests et les scripts utilisés par les PFE et l'équipe de support (qui ignorent également la compression apparemment, car la vérification est intégrée dans l'application et l'application ne peut pas le dire si les données sous-jacentes sont compressées) qui vérifient également les tailles de table. Ce lien indique par exemple:
Évitez d'utiliser des caches de table entière pour les tables volumineuses (dans AX 2009 sur 128 Ko ou 16 pages, dans AX 2012 sur le paramètre d'application 'taille de cache de table entière' [par défaut: 32 Ko, ou 4 pages]) - passez à la mise en cache des enregistrements à la place.