D365 Finance and Operations: Utilisation DTU pour les base de données Azure SQL

Les environnements D365 F&O Tier 2+ utilisent Azure SQL pour les bases de données AX, Financial Reporter et Data Warehouse. Étant donnée que les environnements son hébergé par Microsoft, nous n’avons pas accès aux serveurs Azure SQL via le portail Azure. Ainsi, nous ne pouvons pas utiliser les outils de monitoring d'Azure.

Toutefois, nous pouvons utiliser l’outil Environnement Monitoring de LCS pour voir le pourcentage  d’utilisation SQL pour la base de données AxDB.


Toutefois, aucune information pour les bases de données AxDW et MrDB. Afin de savoir l’utilisation SQL pour ses deux bases de données, il faut se connecter sur le serveur Azure SQL et exécuter la requête suivante:

WITH workload_group_resource_stats_cte (end_time, avg_cpu_percent, avg_data_io_percent, avg_log_write_percent) 
AS (SELECT end_time, 
    Sum(avg_cpu_percent)       AS AVG_CPU_PERCENT, 
    Sum(avg_data_io_percent)   AS AVG_DATA_IO_PERCENT, 
    Sum(avg_log_write_percent) AS AVG_LOG_WRITE_PERCENT 
FROM   sys.dm_db_workload_group_resource_stats 
GROUP  BY end_time)
SELECT END_TIME,
 (SELECT Max(v) 
  FROM (VALUES (avg_cpu_percent), 
    (avg_data_io_percent), 
    (avg_log_write_percent)) AS VALUE(v)) AS DTU_CONSUMPTION_PERCENT,
avg_cpu_percent,avg_data_io_percent,avg_log_write_percent
FROM workload_group_resource_stats_cte
ORDER BY END_TIME DESC


SQL Server: FETCH_API consommes beaucoup de resources SQL

Lors d’une investigation d’un problème de performance avec D365 for Finance and Operations, j’ai exécuté le script Find Most Expensive Queries Using DMV de Pinal Dave et j’ai trouvé ceci:


Étant donné que le processus était toujours en cours d’exécution dans l’application, j'ai utilisé mon script qui me retourne toute les requêtes en cours d’exécution et j’ai vu le résultat ci-dessous. Il faut dire que ce fut par chance parce que comme vous pouvez le voir, c’est une petite requête qui ne consomme pas de CPU, reads, writes et logicial reads, donc elle passe vite. J’ai dû exécuter mon script plusieurs fois avant avant de la voir.


Qu’est-ce que FETCH_API ? C’est bien expliquer dans l’article suivant: Hunting down the origins of FETCH API_CURSOR and sp_cursorfetch. En résumé, le curseur est défini au début de la transaction et SQL travaille a l’intérieur de ce curseur.

Afin de voir la requête derrière le curseur, l’article mentionner plus haut propose la requête suivante (il faut remplacer le chiffre 53 par le SPID):

SELECT c.session_id, c.properties, c.creation_time, c.is_open, t.text
FROM sys.dm_exec_cursors (53) c
CROSS APPLY sys.dm_exec_sql_text (c.sql_handle) t

Celle-ci fonctionne bien si le SPID reste le même pour une longue durée. Pour ma part, j’ai fait une modification au script afin de voir tous les curseurs ouverts en ordre de worker_time, read and writes afin de facilement identifier le curseur qui consomme le plus de ressource.

SELECT c.session_id, c.properties, c.creation_time, c.is_open, t.text, worker_time, reads, writes
FROM sys.dm_exec_cursors (0) c
CROSS APPLY sys.dm_exec_sql_text (c.sql_handle) t
ORDER BY 
worker_time DESC
reads DESC
writes DESC


Voilà, je peux maintenant voir les requêtes en question.

D365 Finance and Operations: The request channel timed out while waiting a reply after 00:59:59.

Récemment, j’écrivais un article sur comment trouver les messages d’erreur lors de l’exécution d’une job export entity to database qui échoue: Export failed while copying data from target to staging.

J’ai diagnostiqué un autre cas ou l’export échouait avec l’erreur suivante:

The request channel timed out while waiting a reply after 00:59:59. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding.

Dans une architecture WCF, la valeur du SendTimeout est établie par le client. Dans ce cas-ci, le client est le service AOS et le serveur est Data Import Export Framework service. Afin de modifier la valeur du SendTimeout du côté client, il faut modifier le fichier suivant:

Fichier: Microsoft.Dynamics.AX.Framework.Tools.DMF.ServiceProxy.dll.config

Microsoft-Hosted
  • G:\AosService\WebRoot\bin\
Cloud-Hosted
  • K:\AosService\WebRoot\bin

Ensuite il faut redemarrer IIS.

Dynamics AX 2012 R3: An error (1332) occurred while enumerating the group membership.

Lors du déploiement des rapports SSRS d’un environnement Dynamics AX 2012 R3, j’ai reçu le message d’erreur suivant:

Warning: The security group Administrator contains a member that is causing the following error : An error (1332) occurred while enumerating the group membership. The member’s SID could not be resolved.



L’erreur m’empêchait de déployer les rapports SSRS. Une recherche sur Internet indique que le paramètre -SkipReportServerAdminCheck pour faire partie de la solution, mais je n’ai pas essayer.

Ensuite, je sais que mon compte était membre d’un groupe de domaine et ce groupe était membre du groupe administrateur local. Donc, j’étais bel et bien administrateur de la machine, mais comme le message l’indique, il y a un problème lors de l’énumération des membres du groupe administrateur local. L'erreur est explicite, il semble y avoir un membre du groupe administrateur local qui n’existe plus dans l’Active Directory et ceci cause probleme, mais j’ai oublier de vérifier cela avant d’appliquer la solution suivante: j’ai ajouté mon compte dans le groupe administrateur local et ensuite j’ai fait le déploiement et ça l’a fonctionner.

D365 for Finance and Operations: Export failed while copying data from target to staging

Un utilisateur rapporte un problème lors de l’exécution d’une job export entity to database. La tache rapporte un warning, mais lorsqu’on clique sur Execution Details, on peut y voir que certaines entités ont complètement échoué.




Afin de voir les détails de l’échec, on peut cliquer sur View execution log.


Toutefois, il n’y a rien dans la section log text.


Dans ce cas, je suis chanceux, ce n’est un environnement de production et je peux aller sur le serveur AOS. Je peux y trouver l’information dans le journal d’évènement sous Application and Services Logs > Microsoft > Dynamics > AX-DIXFRuntime

Dans ce cas-ci, voici les erreurs que j’ai trouvées:

Export failed while copying data from target to staging

Exception from HRESULT: 0xC0010009



Pour corriger ce problème, il faut augmenter la valeur du SqlCommandTimeOut du fichier DMFConfig.xml  qui se trouve dans: 
  • C:\Program Files (x86)\Microsoft Dynamics AX\70\DataImportExportFramework\


Ensuite, il faut redemarrer les services Batch Management Service et Data Import Export Framework Service.