Voici un problème intéressant que j'ai eu dernièrement.
L'équipe de migration de données utilise un outil maison pour copier la configuration d'une compagnie vers une autre. L'outil est très simple, il suffit d'indiquer la compagnie source, la compagnie destination et les tables que vous voulez copier. Le tout est exécuté dans un batch.
Après quelques minutes, le message d'erreur suivant apparaît dans le journal d'événement du serveur AOS:
Object Server 01: Dialog issued for client-less session 5: Cannot create temporary file: C:\Users\SVC_AXAosProd\AppData\Local\Temp\$tmp00050000.$$$.
Je confirme que le disque n'est pas plein.
Après une dizaine de minutes, le service AOS crash:
The Microsoft Dynamics AX Object Server 6.3$01-MicrosoftDynamicsAX service terminated unexpectedly. It has done this 1 time(s).
Heureusement, j'avais configuré le dump automatique de la mémoire du service AOS. Je prends mon dump et je l'upload dans LCS et je l'analyse avec l'outil Crash and Hang Analysis.
J'anticipais voir du code maison, mais ce ne fut pas le cas. En fait le crash semble être lié au kernel. Wow.
Ax32Serv!readPage
Ax32Serv!getPage
Ax32Serv!ServerReadPage
Je jette un coup d'oeil un dossier temporaire qui se trouve sur le serveur AOS et j'y trouve plus de 1000 fichiers. Donc, ce n'est pas un problème d'accès.
Qu'est ce qu'un fichier $tmp*.$$$ ?
Il est possible de mettre des tables AX dans le cache mémoire du serveur AOS. La grosseur limite de la table est de 96 KB. Si la table est plus grosse que la limite, le mémoire déborde sur le disque (spilling to disk). Lorsque la mémoire déborde sur le disque, l'AOS mets les données dans des fichiers temporaires $tmp*.$$$.
Heureusement, j'avais DynamicsPerf d'installer dans mon environnement. J'ouvre le projet DynamicsPerf et j'exécute le requêté: TOO_BIG_FOR_ENTIRE_TABLE_CACHE, Find tables that have entire table cache enabled that are large than 128 KB causes the cache to overflow to disk on the AOS serveur
Voici le résultat:
Pour votre information, 96K = 12 pages. J'ai des tables 138 fois trop grosses pour être mise en cache ! Je demande à l'utilisateur quelle table il tente de copier et sans surprise c'était LEDGERINTERCOMPANY !
J'ai changé la propriété CacheLookup de table LedgerInterCompany et la copie à fonctionner sans faire crasher le service AOS !
