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 d 
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.

SQL Server: Method not found:'System.Collections.Specialized.StringCollection

Suite au déploiement d'un environnement de développement sur la plate-forme 11, je recevais le message d'erreur suivant lorsque je tentais d'aller dans les propriétés d'une base de données.

Cannot show requested dialog. (SqlMgmt)

Method not found:'System.Collections.Specialized.StringCollection
Microsoft.SqlServer.Management.Smo.Server.GetPropertyNames(System.Type)'
(SqlManagerUI)

Pour corriger le problème, j'ai mis à jour SQL Serveur Management Studio (SMSS) avec la version dernière version 16. X qui se trouve ici.

SQL Server Diagnostic Information

J'aime bien l'outil Dynamics AX Perf pour débuter le diagnostic d'un serveur SQL. Toutefois, il arrive que Dynamics Perf ne soit pas configuré pour un environnement en particulier. Dans ce cas, je suggère d'utiliser SQL Serveur diagnostic Queries de Glen Berry. Vous pouvez télécharger le script à cette adresse: http://www.sqlskills.com/blogs/glenn/

DMV Queries: https://www.sqlskills.com/blogs/glenn/category/dmv-queries/