Problèmes de performance, mais pas que …

Il y a quelques jours, je faisais un point sur les prestations que j’avais réalisées récemment et celles à venir dans les prochaines semaines / mois. Il ressort de cette étude qu’une majorité de mes prestations est liée à des problèmes de performance.

Les prestations d’audit et d’optimisation semblent être au cœur des préoccupations. Cela se comprend. recevoir des complaintes d’utilisateurs plus ou moins aigris n’est jamais agréable. Mais au-delà du côté râleur bien français il est possible de mesurer l’impact financier d’une application souffrant de problèmes de performance. Des traitements de nuit trop lents peuvent aussi avoir un impact sur la production dans la journée. Et je ne parle pas forcément des opérations de maintenance telle que les sauvegardes, les tests d’intégrité ou la gestion des index.

Dans bien des cas les problèmes de performance sont résolus côté serveur, sans remise en cause de l’application. Des index correctement positionnés sur les clé étrangères (on en rit pas SVP, il y a encore des bases de données qui partent en production sans index sur les FK, voire même pas de clé primaire (!!!!) dans certains cas. Une bonne configuration hardware, système et SQL complète la liste des vérifications a effectuer. Malheureusement, et cela reste frustrant pour un DBA car on na pas d’impact direct sur l’amélioration des performances, l’amélioration des performance passe souvent par des réécritures de requêtes, une revue des l’algorithmique, l’utilisation de boucles qui envoient des centaines de milliers de requêtes pour un traitement ….

Je râle aussi énormément après des développeurs qui ne prennent pas le temps de typer correctement des paramètres de requêtes, principalement les requêtes LinQ ou bien via Entity Framework. Extrêmement simple à déceler via une session xEvent ou bien via le profiler car les paramètres sont tous de type NVARCHAR(4000). Lorsque ce type de données ne correspond pas aux colonnes de la table, cela implique une conversion implicite de la part de SQL Server, ce qui se traduit par un Cluster Index scan / Table Scan dans le pire des cas, ou un Nonclustered index scan dans le meilleur des cas. Bref, bien moins optimum qu’un index seek.

Afin de démontrer ce comportement, je vous propose de créer un table dont la colonne FirstName est de type VARCHAR, de créer un index non cluster sur cette même colonne et d’exécuter une requête SELECT avec un paramètre de type NVARCHAR.

CREATE TABLE Contact
(
	ID INT PRIMARY KEY,
	FirstName VARCHAR(50),
	LastName NVARCHAR(50)
);


CREATE INDEX IX_FirstName
ON Contact (FirstName);

SELECT *
FROM Contact
WHERE FirstName = 'Carina';
GO

SELECT *
FROM Contact
WHERE FirstName = N'Carina';
GO

Il apparait clairement que le mauvais typage des données rends la requête non SARGABLE. Bon, OK, vous ne trouverez pas ce mot dans le dictionnaire, mais basiquement cela veut dire que SQL Server ne pourra pas utiliser les arguments dans une recherche (comprenez un index seek) : Search ARGument ABLE.

Alors, oui, cela embête forcément le développeur de revoir son code, mais al performance est à ce prix là.

Résoudre un problème de performance est gratifiant, on voir immédiatement le fruit de son travail et l’on peut aisément mesurer la satisfaction client/utilisateur.

A l’inverse d’une solution de haute disponibilité qui au final n’est que peu visible par l’utilisateur final ! Au vu des différentes prestations effectuées, je suis étonné que l’on ne me sollicite pas davantage sur l’implémentation d’architectures hautement disponibles. Idem pour les formations que je dispense, la formation sur la haute disponibilité a moins de succès que les formations relatives à la performance !

Ne vous inquiétez pas pour autant, je ne passe pas une semaine sans faire de la HA, mais je n’arrive pas à comprendre que ce point ne soit pas plus une préoccupation pour l’IT comme pour le métier.

Alors oui une application performante c’est bien, mais si votre serveur SQL est HS, il n’y a plus d’application du tout ! Est-ce que vous avez réellement évalué la perte financière (chiffre d’affaire, salaire, …) liée à la non disponibilité de votre base de donnée ? Investir quelques milliers d’euros supplémentaires dans une solution hautement disponible pourrait vous éviter de perdre des dizaines ou centaines de milliers d’euros plus tard.

Les solutions actuelles de haute disponibilité offertes par SQL Server couvrent de multiples scénarios, en HA, en DR et offloading de traitements en lecture seule. La simplicité de mise en œuvre est sans pareille sur le marché, que ce soit sur des instance de basculement (FCI), des groupes de disponibilité, éventuellement du Log Shipping. Pourquoi ne pas tirer parti des possibilités offertes par Kubernetes pour héberger votre instance SQL Server ???

Attention cependant, beaucoup de mes clients se reposent sur les systèmes de « haute disponibilité » offertes par leur hyperviseur pour maintenir Online une machine virtuelle. Une VM online ne signifie pas un SQL Server Online. Rien à voir. Donc une VM en HA ne peut nullement être comparée à de la haute disponibilité SQL Server, ne vous en déplaise.

Alors, oui, j’entends les critiques qui pointent du doigt l’impact sur les performance d’un systèmes de haute disponibilité. Et effectivement, je ne peux pas le nier, en fonction de la solution choisie, il peut y avoir un impact négatif. Mais est-ce que vous êtes réellement à la recherche des 5%, peut être un peu plus, de différence en performance ? Le jeu en vaut il la chandelle si votre SQL reste indisponible des heures ?

On revient invariablement à deux acronymes : RPO et RTO
RPO : Recovery Point Objective, autrement dit les données que vous vous autorisez à perdre dans le pire des cas. Si votre RPO est de 24heures, alors probablement pas besoin de haute disponibilité, et une sauvegarde quotidienne peut vous satisfaire. Mais si le RPO tend vers zéro, alors il est probable que, quelques soit al stratégie de sauvegarde choisie, cela ne suffise pas et qu’il faille ajouter une brique de haute disponibilité pour satisfaire au besoin.
RTO : Recovery Time Objective. Bon, OK, tout est cassé, il y a eu un problème, maintenant il faut redevenir opérationnel le plus rapidement possible. N’espérez pas pouvoir restaurer une base de donnes de 5TB en 2 minutes, même avec un sous système disque hyper rapide. Il faut donc garder en réserve une base de données quasi prête à l’emploi (Hot Standby pour les intimes).

Et d’autres considérations rentrent en ligne de mire : quelle est la granularité de protection souhaitée ? le datacenter, le serveur, l’instance, une base, une table, un traitement ? En H24 7/7, ou bien sur une période ouvrée de 8h à 19h ? Bref, en fonction des cas, l’architecture mise en place et la technologie utilisée vont différer.

Loin de moi l’idée de noircir le tableau pour vous faire adopter une solution de HA. Prenez un bout de papier et notez les incidents liés à un SQL Server crashé (OS et/ou SQL Server, pas de cause lié à l’infra). Il ne doit vraiment pas y en avoir beaucoup. SQL Server est fiable, et ce depuis des années. J’interviens sur des environnements qui n’ont pas été stoppés / rebootés depuis des années. Oui, ces environnements n’ont pas été patchés, mais cela fonctionne très bien. Il faut discuter avec les responsables sécurité pour voir si cela pose un problème …

Il y a une chose que je ne peux pas faire pour vois, et que pourtant je vous suggère de faire rapidement. Prenez une journée avec les différents acteurs, management, métier, IT, et évaluez la perte financière en cas de non disponibilité de SQL Server. Le chiffre, en euros, qui en ressortira, vous indiquera clairement si il faut mettre en place une solution de HA. Une fois qu’elle sera en place vous pourrez dormir sur vos deux oreilles et penser … à l’optimisation 🙂

Enjoy !

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM/MCSM SQL Server
Cet article a été publié dans SQL Server. Ajoutez ce permalien à vos favoris.

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s