SQL Server Best Practices – Exclusions Antivirus

Lors de l’installation/configuration d’un SQL Server sur une machine, il faut toujours penser à vérifier si un antivirus est présent.
En effet, si un scan antivirus est lancé sur des fichiers de base de données (MDF, LDF), ou sur les services SQL,  les performances du serveur seront catastrophiques.
Pour éviter ce genre de probléme, il faut gérer une liste d’exclusion afin de ne pas impacter les performances du SQL Server.

Voici une liste exhaustive des exclusions par catégorie :

Fichiers et dossiers :

  • Les fichiers de base de données (.mdf, .ldf, .ndf)
  • Les fichiers de sauvegarde (.bak, .trn)
  • Les fichiers de catalogue texte intégral (Full-Text)
  • Les fichiers de trace SQL (.trc)
  • Les fichiers d’audit SQL (.sqlaudit)
  • Les fichiers de requête (.sql)
  • Les répertoires Analysis Services (Data, Log, Temp, Backups)
  • Les fichiers de sauvegarde Analysis Services
  • Les fichiers FileStream
  • Le répertoire SSRS contenant les fichiers temporaires et  les logs

Processus :

  • SQLServr .exe
  • ReportingServicesService .exe
  • MSMDSrv .exe

Dans le cas ou vous utilisez la fonctionnalité cluster,  il faut également penser à exclure :

  • C:\Windows\Cluster
  • Le disque de Quorum

Pour plus de détails je vous invite à vous rendre sur le post officiel de Microsoft : ici.

SQL Server Best Practices – Options d’alimentation du serveur

Cette best practice est seulement valable pour les serveurs qui ne sont pas issues de la virtualisation (Hyper-V ou Vmware), car ce paramètre est géré directement au niveau de la console de virtualisation.

Définir le mode de gestion de l’alimentation du serveur en « High Performance » est souvent oublié lors de la configuration des serveurs.
Pourtant, ne pas laisser le mode par défaut est primordial pour faire fonctionner le serveur à 100% de ses capacités.

En effet, laisser le mode Balanced peut réduire drastiquement les performances.

Comme on peut le voir sur cette image, le mode Balanced permet d’allouer au processeur un pourcentage minimum et maximum de fréquence.
C’est donc le système qui va définir quelle fréquence il devra utiliser, en fonction de la charge du serveur.
Le problème qui va se poser est que le système a du mal à définir la bonne fréquence à donner aux processeurs en fonction de la charge du SQL Server.
Par exemple, pour une requête spécifique, SQL pourrait avoir besoin de 100% de CPU, alors que le système n’en donnera que 5% car il n’aura pas détecté cette requête comme étant consommatrice.

La bonne pratique est de mettre le mode en High Performance.

Ce mode permet de laisser la fréquence à 100% en minimum et maximum.
Le SQL Server pourra donc utiliser toutes les capacités du serveur.

Lors de mes interventions, beaucoup de problèmes de performances ont pu être réglés seulement en changeant ce paramètre. Attention donc à ne pas négliger cette best practice !

SQL Server Best Practices – Fixer la mémoire de l’instance

Une des premières étapes de la configuration d’une instance SQL Server est d’appliquer des « Best Practices ». Définir une limite maximale pour la mémoire allouée à l’instance est très important. Cela permet de ne pas se retrouver avec un serveur saturé.

Mais comment définir la meilleure valeur à mettre en place ?

Voici deux règles simples :

  1. (Mémoire du serveur) – ((Mémoire du serveur) * 0,10))
  2. (Mémoire du serveur) – Une valeur fixe en fonction de la mémoire du serveur

Ces règles sont applicables dans le cas ou il n’y a qu’une seule instance SQL sur le serveur.
Pour ma part je préfère celle avec les valeurs fixes, qui sont définies suivant la mémoire totale.

Voici ce que j’utilise :

  • 1 GO pour 4 GO
  • 2 GO pour 8 GO
  • 4 GO pour 16 GO et plus

A ajuster si d’autres services sont installés (SSIS/SSAS/SSRS etc…) ou si la mémoire de votre serveur ne rentre pas dans ces critères.

Pour un serveur de 8 GO nous aurons donc : 8(Mémoire du serveur) – 2(Valeur fixe) = 6 GO allouée à l’instance.

En plus de fixer la mémoire maximum dédiée à l’instance, on peut également mettre une valeur minimum. Si vous mettez une valeur minimum et maximum au même niveau, par exemple 6 GO, l’instance restera à cette valeur fixe tant qu’elle sera active.
C’est intéressant pour avoir une valeur de référence et détecter un problème de mémoire sur le serveur.

Pour fixer la mémoire vous pouvez passer en interface graphique avec SSMS ou directement en requête T-SQL.

Avec SSMS :

Aller dans les propriétés de l’instance, puis Memory et Server memory options.
Puis changer la valeur minimum et maximum de la mémoire dédiée à l’instance.

En T-SQL :

EXEC sys.sp_configure N'show advanced options', N'1'  RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'min server memory (MB)', N'6144'
GO
EXEC sys.sp_configure N'max server memory (MB)', N'6144'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'show advanced options', N'0'  RECONFIGURE WITH OVERRIDE
GO

Remplacer 6144 par la valeur que vous aurez définie.

Cet article est le premier d’une longue série sur les Best Practices  de SQL Server.
D’autres seront postés dans les semaines à venir.