D365 for Finance and Operations : The transaction log for database is full due to LOG_Backup.

Les utilisateurs d'un système D365 for Finance and Operations d’un environment Tier-2 recevait le message d’erreur suivant:

Sorry, we lost the connection temporarily. Please be patient while we reconnect you.



J’ai été voir dans le l’observateur d’évènement et j’ai trouver les messages d’erreur suivants:

The transaction log for database is full due to LOG_Backup.



J’étais un peu perplexe puisque c’est une base de données Azure SQL, mais j’ai tout de même fait une investigation. J'ai établi une connexion à la base de données Azure SQL et j’ai exécuté la requête suivante:

SELECT file_id, name, type_desc, physical_name, (size * 8) / 1024/1024 "Current Size in GB", (max_size * 8) / 1024/1024 "Maximum Size in GB"
FROM sys.database_files ;

On peut y voir qu’effectivement le fichier de log est rempli à pleine capacité.


La taille maximum du fichier de log = 45875200 KB = 367GB.
La taille maximum du fichier données = 134217728 KB = 1TB.

Ensuite, j’ai exécuté la requête suivante afin de connaitre le service tier de la base de données AxDB

SELECT  d.name,  slo.* 
FROM sys.databases
JOIN sys.database_service_objectives slo 
ON d.database_id = slo.database_id;


Je sais que la grosseur maximum de la base de données pour service tier P11 est de 4TB, donc il est clair que Microsoft a limité la grosseur à 1TB. De plus, 1TB est la grosseur limite de la base de données, aucune information sur la limite du fichier de log.

Je sais que la grosseur maximum de la base de données pour service tier P11 est de 4TB, donc il est clair que Microsoft a limité la grosseur à 1TB. De plus, 1TB est la grosseur limite de la base de données, aucune information sur la limite du fichier de log.


Dans ce cas-ci, j’ai décidé de réduire la taille du fichier de log plutôt que de demander à Microsoft d’augmenter la limite. J’ai utilisé la requête suivante.

dbcc SHRINKFILE(1,250000)

SQL Server : Memory (Private Working Set)

Dernièrement, un collègue de travail m’a demandé pourquoi Task Manager indiquait que 98% de la mémoire du serveur SQL était utilisé, mais que le  service MSSQLSERVER en utilisait seulement 1.4 Gb.


C’est un comportement normal lorsque le compte de service SQL possède les permissions Lock Pages in Memory puisque les "locked pages" en mémoire ne fait pas partie du du Memory Private Working Set.

Voici la différence avec une instance SQL dont le compte de service n’est pas configure avec les permissions Lock Pages in Memory.


Dans tous les cas, la meilleure façon de savoir la mémoire utilisée par SQL est via la DMV dm_os_process_memory.

SELECT
(physical_memory_in_use_kb/1024)Memory_usedby_Sqlserver_MB
FROM sys.dm_os_process_memory

Dynamics AX et SQL Resource Governor

Un de mes clients éprouvait des problèmes de performance avec leur serveur SQL. Après avoir utilisé le script de Glen Barry afin d'effectuer un diagnostique, il était évident que SQL souffrait de congestion au niveau de la mémoire et des disques. De plus, j’ai constaté que la majorité des ressources du serveur était utilisée par des  bases de données autre que MicrosoftDynamicsAX et MicrosoftDynamicsAX_model. Les instructions du client étaient claires: les bases de données de Microsoft Dynamics AX doivent avoir priorité sur les ressources.

Le client possède une architecture SQL AlwaysOn Availability groups avec 3 serveurs de réplication, dont un dans un leur site de recouvrement (DR). Les serveurs SQL sont hébergés sur la plateforme Azure dans un mode de déploiement Classic.  La taille des serveurs est déjà au maximum 8vCPU, 56GB et il est impossible pour le moment de migrer les serveurs dans le mode Azure Resource Manager (ARM). Impossible aussi pour l'instant de déplacer les autres bases de données.

C’est un excellent cas pour Resource Governor! C'est la première fois que j'utilisais Resource Governor parce que lors de toutes mes implantations précédentes, les clients ont décidé d'y aller avec une architecture SQL dédiée pour Dynamics AX.

Je ne vais pas entrer dans les détails de Resource Governor, mais en résumé c’est un outil qui permet de limiter la consommation de CPU, mémoire et IOPS. Bref, un outil parfait dans mon cas afin de limiter les ressources utilisées par les autres bases de données sur le serveur et laisser plus de performance pour Dynamics AX.

Tout d’abord, j’ai créé un nouveau Resource Pool nommé DynamicsAX. Mon intention est de rediriger toutes les sessions provenant des serveurs AOS vers ce Resource Pool. Je lui assigne un minimum de 50% du CPU et un minimum de 70% de la mémoire.  Prenez note que je ne peux pas assigner un minimum et maximum de IOPS via l’interface graphique, l'option est disponible seulement via T-SQL.

Ensuite, j’ai créé 3 différents workload groups. Un pour le serveur AOS qui dessert les utilisateurs, un pour le serveur AOS qui exécute les batch et un pour le serveur AOS qui dessert les utilisateurs Enterprise Portal.


Ensuite, j'ai créer un classifier. Le classifier permet de rediriger les sessions dans un workload group. Le workload group appartient à un Resource Pool. Dans ce cas-ci, j'ai décidé d'utiliser HOST_NAME() pour déterminer la source de la session en sachant que mes serveurs AOS se connectent à la base de données Dynamics AX uniquement via le service AOS. Il est aussi possible d’utiliser d’autre variable comme APP_NAME(), HOST_NAME(), ORIGINAL_DB_NAME(), etc.

CREATE FUNCTION dbo.DynamicsAXClassifier()
RETURNS SYSNAME
WITH SCHEMABINDING
AS
BEGIN
DECLARE @WorkloadGroup AS SYSNAME
IF(HOST_NAME() = 'AOSSERVERNAME_USERS')
SET @WorkloadGroup = 'AOS_Users'
ELSE IF (HOST_NAME() = 'AOSSERVERNAME_BATCH')
SET @WorkloadGroup = 'AOS_Batch'
ELSE IF (HOST_NAME() = 'AOSSERVERNAME_EP')
SET @WorkloadGroup = 'AOS_EP'
ELSE
SET @WorkloadGroup = 'default'
RETURN @WorkloadGroup
END
GO


Toutes les sessions qui ne proviennent pas des serveurs AOS iront dans le resource pool default. Celui -ci a un accès maximum de 100% du CPU et de la mémoire, mais étant donné que le Resource Pool DynamicsAX a une réservation de 70% (CPU) et 70% (mémoire), ceci veut dire que le nouveau maximum est 30% et 30%.

Je voulais ajouter des limitations supplémentaires au Resource Pool default. Dans mon cas, la configuration global de MAXDOP est 4. Mais, il est possible de limiter MAXPOP à 1 pour toute requête autre que Dynamics AX:


Pour finir, j’ai modifié la limite de IOPS a 1000 pour le Resource Pool default:

ALTER RESOURCE POOL [default] WITH(
                min_cpu_percent=0, 
max_cpu_percent=100, 
min_memory_percent=0, 
max_memory_percent=100, 
cap_cpu_percent=100, 
AFFINITY SCHEDULER = AUTO
min_iops_per_volume=0, 
max_iops_per_volume=1000)
GO

Après que le tout est en place, il faut redemarrer les service AOS afin d'initier de nouvelles sessions. Ensuite, j’utilise un rapport SRRS SQL Server Resource Governor Monitoring reports pour surveiller l’utilisation des ressources dans les Ressources Pools.

Finalement, vous avez surment remarqué qu’il y a plusieurs options dont je n’ai pas mentionné. Je suggère la lecture de Resource Governor sur simple-talk afin de connaitre tous les détails.

Dynamics AX 2012 : le menu de navigation vide

Suite au redémarrage des serveurs AOS, un utilisateur n’avait plus accès au menu de navigation dans le client AX:


Pour résoudre ce problème, il suffit de supprimer les éléments NavPaneOptionsButtons et Windows dans le Usage Data de l’utilisateur:

D365 for Finance and Operations : An unexpected client error has occured

Suite au déploiement d’un environnement Tier-2, je voulais tester Power BI embedded qui est déployer et configurer par défaut dans les environnements Tier-2. J’ai donc ouvert CFO workspace et Financial Insights et j’ai reçu le message d’erreur suivant:

An unexpected client error has occurred
Session ID: ee0c7a67-86e8-446b-9015-e2c010b740f7
Search timestamp: 2018-02-13T22:38:11.785Z


Ceci est du au fait que le calendrier fiscal n'est pas configurer pour l'entite legale en question. Les configurations se trouvent sous 
- General Ledger --> Chart of Accounts --> Chart of Accounts
- General Ledger --> Calendard --> Fiscal calendars
- General Ledger --> Ledger Setup --> Ledger

Ou, vous pouvez utiliser la requête suivante dans SQL et remplacer le nom DAT par la compagnie que vous voulez utiliser.

SELECT COUNT(*) 
FROM Ledger l
JOIN FISCALCALENDAR f 
ON l.FiscalCalendar = f.RecId
WHERE name = 'DAT'

Entre temps, vous pouvez toujours vérifier si PowerBI Embedeed est fonctionnel en ouvrant Sales and Profitability ou Cash Overview.