Discussion :

[phoenix40]

Bonjour à tous.

Je viens ici chercher quelques conseils concernant l'optimisation d'un serveur SQL 2012 r2 et aussi les coordonées de quelqu'un pouvant nous aider sur le sujet.

Me concernant je suis l'administrateur systeme et reseau d'une boite et j'ai été embauché dans cette boite lors de l'arrivée de la nouvelle mouture du logiciel de gestion de production. Je n'ai que tres peu de de connaissance en BDD (le reste ça va).

Le probleme actuel est que nous avons un serveur SQL (6 vcpu et 24 go de ram) qui, par moment dans la journée, sature au niveau CPU (j'ai mis 6 cpu ya pas longtemps et c tj pareil).

Je suis donc à la recherche d'infos pouvant me permettre d'endiguer le probleme. J'ai deja utilisé le "moniteur d'activité" pour voir quand ça rame qu'elles etaient les requetes "running". J'ai mis en place tous les week-end des plans de maintenance.

Pour info, l'editeur du logiciel est sponsor de l'equipe de foot de l'OL.

Je suis donc preneur d'infos et de liens et aussi de nom de sociétés ou d'independant pouvant nous aider à optimiser le serveur et surtout la bases et les requetes.

Merci à tous pour votre aide.

[SQLpro]

Nous avons écrit un ouvrage consacré à SQL Server (1 238 pages) dont l'angle d'attaque est la performance :
http://mssqlserver.fr/

Commencez par l'acheter, le lire et appliquer les quelques centaines de préconisations que vous y trouverez...

Ensuite, les choses importantes au niveaux des performances sont, dans l'ordre des gains :
1) le modèle de données (souvent 70% des problèmes de perf...)
2) le stockage et l'indexation
3) les journaux de transactions
4) la base tempdb
5) le style de codage
6) la maintenance (index et stats)

N'hésitez pas à poser des questions à ce sujet

A +

[phoenix40]

Merci SQLPRO pour cette réponseet ne t'offusque pas de la mienne.

Un jour peut-être lirais-je ce roman, lorsque je serais DBA.

Pour toutes les autres personnes qui pourrais lire mon message premier, je suis donc à la recherche d'un expert SQL qui serait basé dans le sudouest (nous sommes du coté de biarritz).

En effet je n'ai pas, pour l'instant, le temps de me plonger dans la lecture d'un roman fleuve.

Mais si quelqu’un à déjà 2 ou 3 pistes à me donner pour améliorer ne serait-ce qu'un chouya le fonctionnement actuel (ram/proc suffisamment dimensionnée, taille et type de fs, plans de maintenance) que je puisse juste savoir si la situation est désespérée ou si ya de l'espoir.

Comme toujours dans mon role d'amin systeme, je suis entre le marteau et l'enclume : tout le monde viens se pleindre "gnagnagna sa rame et le responsable du projet plane complet et s'en fout".

Merci à tous (promis j’arrête de faire ma pleureuse)

[nico84]

Bonjour,

Je ne sais pas qui sponsorise l'OL mais si j'ai bien suivi c'est clairement à lui de dimensionner le serveur. Pour reprendre la liste de SQLPro il est le seul à maitriser la plupart des points.

[phoenix40]

C'est bien la le problème.

Si l’éditeur du logiciel (gestion de production, de la compta et de la paie) était vraiment capable de le faire je ne viendrais pas ici pleurer.

L'éditeur du logiciel à bien vendu à la société dont je fais partis, la nouvelle mouture de son logiciel qui commence à être stable en terme de gestion production. Concernant la paie qui est son cœur de métier depuis des année, no problemo.

Cet éditeur, ne fais pas grand chose en direct et nous redirige vers ses prestataires, dont les compétences sont toutes relatives.

En gros ça tourne, mais sur 3 pattes. J'ai 5 utilisateurs connectés en client "lourd" et autant en client "léger" et le serveur SQL pédale dans la semoule (ou la choucroute, tout dépends d’où vous venez).

Certaines table ont plus de 2 millions de lignes et je pense que certaines requetes ne sont pas optimisées, mais la s’arrête mes compétences.

Voilou et merci.

[SQLpro]

Il n'y a pas beaucoup d'experts SQL Server disponible en ce moment pour différentes raisons :
1) le 4e trimestre est en général très chargé
2) SQL Server ayant un fort vent de poupe, nous sommes submergés de missions
3) les formations d'école d'ingé et universitaires ont longtemps tourné sur SQL Server, puis sur MySQL…
4) il y a peu d'experts SQL Server...

Aussi te renouvelle-je mon offre. Je ne te dis pas de lire le livre, mais comme son titre le dit, l'ouvrage est tourné vers la performance, avec de nombreuses exergues sur ce sujet, qu'il est facile de retrouver dans l'ouvrage et dont certaines peuvent être mises en pratique immédiatement.

A +

[janlouk]

Si tu veux gagner du temps, tu peux suivre cette courte formation de Rudi ici : https://www.linkedin.com/learning/sq...ogiciels-tiers

Le soucis, c'est Biarritz, mais tu peux tenter ta chance avec ces personnes et ils ne sont pas dans un ordre de préférence de ma part et accepteront peut-être de se déplacer :

Rudi Bruchez
Sarah Bessart
Christophe Laporte (Toulouse)
Jean-Pierre Riehl (Azeo, donc une grande équipe à son service)
Arian Papillon
Et bien sûr Frédéric Brouart (SQLPro)

Voici des petites choses que tu peux regarder et tester. C'est une liste que j'ai trié pour toi mais c'est très bref et à ne pas suivre à la lettre, c'est en fonction. Mais ça te fait gagner du temps sur le livre de Frédéric. Attention, je n'applique pas tout, c'est en fonction des besoins.

- Avoir le dernier Service Pack d’installé et le CU aussi
- Bien dimensionner ses DB
- Mettre l’autogrowth en MB
- Vérifier que des DB en FULL ait bien un backup du log, si pas, alors pourquoi être en full ?
- Hyper-threading, on peut l'activer au niveau du bios
- Il faut aussi activer l'Intel turbo boost
- Il ne faut pas mixer des générations de disque (512 et 4K par exemple). Si c'est le cas, ça peut poser des problèmes entre autres avec Always On, même s'il y a des traces flag pour ça.
- Dans Windows Server 2008 et +, le réglage d'économie d'énergie par défaut est réglé sur Balanced, ce qui signifie que les composants tels que le processeur et le stockage seront réduit si le système n’est pas occupé. Dans certains cas, cela peut entraîner une dégradation des performances de SQL Server.
- Il faut désactiver l'option qui est à cocher (properties), pour l'indexation des disques stockant des fichiers SQL.
- Redimensionner correctement les DB system, surtout la db Model
- Faire plusieurs fichiers Data pour la TempDB (1 par core), et si on a encore de la contention, on peut en mettre plus, autant que besoin. On peut même en avoir 64…
- Ne pas avoir la TempDB sur le C, et idéalement aucune DB system sur le C
- Ne pas avoir l’option auto_shrink et auto_close d’activées
- Auto create Statistics & update Statistics doivent être à True sauf pour Sharepoint
- Les statistics doivent bien être à jour, plus important que les indexes même
- Configurer la mémoire pour ne pas tout donner à SQL Server
Exemple :
De 4 à 8 GB de mémoire sur le serveur, on garde 2 GB pour l'OS
De 8 à 32 GB de mémoire sur le serveur, on garde 3 GB pour l'OS
De 32 à 128 GB de mémoire sur le serveur, on garde 4 GB pour l'OS
De 128 à 512 GB de mémoire sur le serveur, on garde 6 GB pour l'OS
De 512 à 4096 GB de mémoire sur le serveur, on garde 8 GB pour l'OS
- Désactiver l'annotation 8.3, qui est l'annotation qui existe depuis Windows 3.11 (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation et mettre à 1)
- Désactiver l'option d'ouverture du server manager (Server manager/manage/Server manager Properties), cela ne s'ouvre que quand on se connecte sur le serveur, mais ça utilise un peu de ressource inutilement
- Activer la compression des backups, il n'y a aucune raison de ne pas le faire si on fait ses backups avec SQL Server. Attention, à voir si cela ne peut pas faire de conflit avec une autre application qui s’occuperait des backup.
- Optimize for adhoc workload, une requête est compilée puis mise dans le plan d'exécution, cela est stocké et gardé. Si on ne l'utilise plus jamais, il va la garder et prendre de la place. En activant cette option, on en libère. Ce n’est pas intéressant si on a plusieurs fois les mêmes query. Pour le tester, utiliser la query ici : https://www.sqlskills.com/blogs/kimb...hoc-workloads/ et première query ici : https://dba.stackexchange.com/questi...-hoc-workloads ou dans mon fichier «Optimize for adhoc workload »
- Network packet size : voir pour augmenter sa valeur
https://docs.microsoft.com/en-us/sql...uration-option
- Seuil de parallélisme (Cost Threshold for Parallelism), voir pour monter la valeur à 25, 30 ou 35 https://www.brentozar.com/archive/20...t-be-set-to-5/
- Maxdop : à voir en fonction du nombre de cœur, mais ne pas dépasser 8
- Il faut idéalement avoir 20% d'espace libre dans les fichiers SQL (mais pour les gros fichiers, c'est plus compliqué)
- Il faut avoir le minimum de VLF
- Delayed durablity: La transaction n'est pas écrite directement dans le log, donc ça améliore les performances. Mais par contre, si on a un crash juste avant qu'il écrive, on perd la transaction et donc la donnée. (N’existe pas en 2008)
https://docs.microsoft.com/en-us/sql...ion-durability
https://blog.sqlauthority.com/2014/0...l-server-2014/
https://docs.microsoft.com/en-us/sql...ql-server-2017
https://www.brentozar.com/archive/20...e-flag-appears
https://blogs.msdn.microsoft.com/sql...-updates-oh-my
http://www.sqlservercentral.com/arti...ce-flag/152989
https://www.brentozar.com/archive/20...ath-trace-flag
https://www.brentozar.com/blitz/trac...bled-globally/
- Trace flag 1117 so when a single file in a database filegroup needs to grow, they all grow together
Note: Starting with SQL Server 2016 (13.x) this behavior is controlled by the AUTOGROW_SINGLE_FILE and AUTOGROW_ALL_FILES option of ALTER DATABASE, and trace flag 1117 has no effect. For more information, see ALTER DATABASE File and Filegroup Options (Transact-SQL).
Est par défaut depuis SQL 2016 pour la TempDB donc inutile de l'activer. Et donc ne se fait plus sur les users DB, donc si on veut l'activer pour les users DB, il faut mettre ceci : ALTER DATABASE AdventureWorks MODIFY FILEGROUP [PRIMARY] AUTOGROW_ALL_FILES;
- Trace flag 1118 to reduce SGAM contention
Note: Starting with SQL Server 2016 (13.x) this behavior is controlled by the SET MIXED_PAGE_ALLOCATION option of ALTER DATABASE, and trace flag 1118 has no effect. For more information, see ALTER DATABASE SET Options (Transact-SQL).
A voir à ne pas le généraliser, voir ici : https://www.developpez.net/forums/d1...hiers-donnees/
Est par défaut depuis SQL 2016 pour la TempDB donc inutile de l'activer. Si on veut l'activer pour les users DB, il faut mettre ceci : ALTER DATABASE <dbname> SET MIXED_PAGE_ALLOCATION { ON | OFF }
- Trace flag 2371 so statistics are recomputed less rarely as tables grow larger
-> très important d'après Christophe Laporte
Note: Starting with SQL Server 2016 (13.x) and under the database compatibility level 130, this behavior is controlled by the engine and trace flag 2371 has no effect.
- Trace flag 3023 Enables CHECKSUM option as default for BACKUP command.
Note: Starting with SQL Server 2014 (12.x) this behavior is controlled by setting the backup checksum default configuration option.Sur les scripts d'OLA, on peut choisir de le faire donc pas besoin que le TF soit activé dans la configuration. https://blog.developpez.com/elsuket/...um_compression
- Trace Flag 3226 By default, every successful backup operation adds an entry in the SQL Server error log and in the system event log. If you create very frequent log backups, these success messages accumulate quickly, resulting in huge error logs in which finding other messages is problematic.
- Trace flag 3427 Enables fix for issue when many consecutive transactions inserting data into temp table in SQL Server 2016 (13.x) or SQL Server 2017 (14.x) consumes more CPU than in SQL Server 2014 (12.x). -> Remplace TF1118 depuis SQL2016
Note: This trace flag applies to SQL Server 2016 (13.x) SP1 CU2 and higher builds. Starting with SQL Server 2017 (14.x) CU4 this trace flag has no effect.
- Trace flag 4199 to get new query optimizer hotfixes that produce different query plans
https://dba.stackexchange.com/questi...nable-globally
- Trace flag 8048 enables SOFT NUMA when SQL’s NUMA-awareness code doesn’t work on larger systems
Note: Starting with SQL Server 2014 (12.x) SP2 and SQL Server 2016 (13.x) this behavior is controlled by the engine and trace flag 8048 has no effect.



Tu peux aussi utiliser les scripts de Brent Ozar (SP_Blitz par exemple) pour te montrer ce qui ne va pas sur ton instance.

[SQLpro]

Scandale !!!! Tu as plagié mon livre !!!!!
Je vais te demander des droits d'auteur !!!

A +

Voici des petites choses que tu peux regarder et tester. C'est une liste que j'ai trié pour toi mais c'est très bref et à ne pas suivre à la lettre, c'est en fonction. Mais ça te fait gagner du temps sur le livre de Frédéric. Attention, je n'applique pas tout, c'est en fonction des besoins.

- Avoir le dernier Service Pack d’installé et le CU aussi
- Bien dimensionner ses DB
- Mettre l’autogrowth en MB
- Vérifier que des DB en FULL ait bien un backup du log, si pas, alors pourquoi être en full ?
- Hyper-threading, on peut l'activer au niveau du bios
- Il faut aussi activer l'Intel turbo boost
- Il ne faut pas mixer des générations de disque (512 et 4K par exemple). Si c'est le cas, ça peut poser des problèmes entre autres avec Always On, même s'il y a des traces flag pour ça.
- Dans Windows Server 2008 et +, le réglage d'économie d'énergie par défaut est réglé sur Balanced, ce qui signifie que les composants tels que le processeur et le stockage seront réduit si le système n’est pas occupé. Dans certains cas, cela peut entraîner une dégradation des performances de SQL Server.
- Il faut désactiver l'option qui est à cocher (properties), pour l'indexation des disques stockant des fichiers SQL.
- Redimensionner correctement les DB system, surtout la db Model
- Faire plusieurs fichiers Data pour la TempDB (1 par core), et si on a encore de la contention, on peut en mettre plus, autant que besoin. On peut même en avoir 64…
- Ne pas avoir la TempDB sur le C, et idéalement aucune DB system sur le C
- Ne pas avoir l’option auto_shrink et auto_close d’activées
- Auto create Statistics & update Statistics doivent être à True sauf pour Sharepoint
- Les statistics doivent bien être à jour, plus important que les indexes même
- Configurer la mémoire pour ne pas tout donner à SQL Server
Exemple :
De 4 à 8 GB de mémoire sur le serveur, on garde 2 GB pour l'OS
De 8 à 32 GB de mémoire sur le serveur, on garde 3 GB pour l'OS
De 32 à 128 GB de mémoire sur le serveur, on garde 4 GB pour l'OS
De 128 à 512 GB de mémoire sur le serveur, on garde 6 GB pour l'OS
De 512 à 4096 GB de mémoire sur le serveur, on garde 8 GB pour l'OS
- Désactiver l'annotation 8.3, qui est l'annotation qui existe depuis Windows 3.11 (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation et mettre à 1)
- Désactiver l'option d'ouverture du server manager (Server manager/manage/Server manager Properties), cela ne s'ouvre que quand on se connecte sur le serveur, mais ça utilise un peu de ressource inutilement
- Activer la compression des backups, il n'y a aucune raison de ne pas le faire si on fait ses backups avec SQL Server. Attention, à voir si cela ne peut pas faire de conflit avec une autre application qui s’occuperait des backup.
- Optimize for adhoc workload, une requête est compilée puis mise dans le plan d'exécution, cela est stocké et gardé. Si on ne l'utilise plus jamais, il va la garder et prendre de la place. En activant cette option, on en libère. Ce n’est pas intéressant si on a plusieurs fois les mêmes query. Pour le tester, utiliser la query ici : https://www.sqlskills.com/blogs/kimb...hoc-workloads/ et première query ici : https://dba.stackexchange.com/questi...-hoc-workloads ou dans mon fichier «Optimize for adhoc workload »
- Network packet size : voir pour augmenter sa valeur
https://docs.microsoft.com/en-us/sql...uration-option
- Seuil de parallélisme (Cost Threshold for Parallelism), voir pour monter la valeur à 25, 30 ou 35 https://www.brentozar.com/archive/20...t-be-set-to-5/
- Maxdop : à voir en fonction du nombre de cœur, mais ne pas dépasser 8
- Il faut idéalement avoir 20% d'espace libre dans les fichiers SQL (mais pour les gros fichiers, c'est plus compliqué)
- Il faut avoir le minimum de VLF
- Delayed durablity: La transaction n'est pas écrite directement dans le log, donc ça améliore les performances. Mais par contre, si on a un crash juste avant qu'il écrive, on perd la transaction et donc la donnée. (N’existe pas en 2008)
https://docs.microsoft.com/en-us/sql...ion-durability
https://blog.sqlauthority.com/2014/0...l-server-2014/
https://docs.microsoft.com/en-us/sql...ql-server-2017
https://www.brentozar.com/archive/20...e-flag-appears
https://blogs.msdn.microsoft.com/sql...-updates-oh-my
http://www.sqlservercentral.com/arti...ce-flag/152989
https://www.brentozar.com/archive/20...ath-trace-flag
https://www.brentozar.com/blitz/trac...bled-globally/
- Trace flag 1117 so when a single file in a database filegroup needs to grow, they all grow together
Note: Starting with SQL Server 2016 (13.x) this behavior is controlled by the AUTOGROW_SINGLE_FILE and AUTOGROW_ALL_FILES option of ALTER DATABASE, and trace flag 1117 has no effect. For more information, see ALTER DATABASE File and Filegroup Options (Transact-SQL).
Est par défaut depuis SQL 2016 pour la TempDB donc inutile de l'activer. Et donc ne se fait plus sur les users DB, donc si on veut l'activer pour les users DB, il faut mettre ceci : ALTER DATABASE AdventureWorks MODIFY FILEGROUP [PRIMARY] AUTOGROW_ALL_FILES;
- Trace flag 1118 to reduce SGAM contention
Note: Starting with SQL Server 2016 (13.x) this behavior is controlled by the SET MIXED_PAGE_ALLOCATION option of ALTER DATABASE, and trace flag 1118 has no effect. For more information, see ALTER DATABASE SET Options (Transact-SQL).
A voir à ne pas le généraliser, voir ici : https://www.developpez.net/forums/d1...hiers-donnees/
Est par défaut depuis SQL 2016 pour la TempDB donc inutile de l'activer. Si on veut l'activer pour les users DB, il faut mettre ceci : ALTER DATABASE <dbname> SET MIXED_PAGE_ALLOCATION { ON | OFF }
- Trace flag 2371 so statistics are recomputed less rarely as tables grow larger
-> très important d'après Christophe Laporte
Note: Starting with SQL Server 2016 (13.x) and under the database compatibility level 130, this behavior is controlled by the engine and trace flag 2371 has no effect.
- Trace flag 3023 Enables CHECKSUM option as default for BACKUP command.
Note: Starting with SQL Server 2014 (12.x) this behavior is controlled by setting the backup checksum default configuration option.Sur les scripts d'OLA, on peut choisir de le faire donc pas besoin que le TF soit activé dans la configuration. https://blog.developpez.com/elsuket/...um_compression
- Trace Flag 3226 By default, every successful backup operation adds an entry in the SQL Server error log and in the system event log. If you create very frequent log backups, these success messages accumulate quickly, resulting in huge error logs in which finding other messages is problematic.
- Trace flag 3427 Enables fix for issue when many consecutive transactions inserting data into temp table in SQL Server 2016 (13.x) or SQL Server 2017 (14.x) consumes more CPU than in SQL Server 2014 (12.x). -> Remplace TF1118 depuis SQL2016
Note: This trace flag applies to SQL Server 2016 (13.x) SP1 CU2 and higher builds. Starting with SQL Server 2017 (14.x) CU4 this trace flag has no effect.
- Trace flag 4199 to get new query optimizer hotfixes that produce different query plans
https://dba.stackexchange.com/questi...nable-globally
- Trace flag 8048 enables SOFT NUMA when SQL’s NUMA-awareness code doesn’t work on larger systems
Note: Starting with SQL Server 2014 (12.x) SP2 and SQL Server 2016 (13.x) this behavior is controlled by the engine and trace flag 8048 has no effect.



Tu peux aussi utiliser les scripts de Brent Ozar (SP_Blitz par exemple) pour te montrer ce qui ne va pas sur ton instance.

[janlouk]

Même pas , 5 ans d'expériences, des centaines d'heures de lecture sur internet et de nombreux km en voiture et en train pour suivre les sessions SQL en France
J'ai ton livre, mais je manque de temps pour le lire à la maison et j'ai des clients très compréhensif mais pas au point de me laisser lire un livre au boulot
Ah non, sauf pour la mémoire, ça j'ai souvenir de l'avoir recopier de ton livre
Je t'offrirai un verre lors du prochain évènement SQL

[phoenix40]

Merci à tous.

J'ai deja de quoi faire, mais je ne peux le faire que le week-end, donc on verra ce que ça donne.

Du coup je reposterais quand j'aurais pu tester, car j'ai aussi une vie à coté (sisi en informatique ça existe ;-) )

Encore merci pour votre temps et à toute.

[Chess_cgi]

Bonjour à tous.

Je viens ici chercher quelques conseils concernant l'optimisation d'un serveur SQL 2012 r2 et aussi les coordonées de quelqu'un pouvant nous aider sur le sujet.

Me concernant je suis l'administrateur systeme et reseau d'une boite et j'ai été embauché dans cette boite lors de l'arrivée de la nouvelle mouture du logiciel de gestion de production. Je n'ai que tres peu de de connaissance en BDD (le reste ça va).

Le probleme actuel est que nous avons un serveur SQL (6 vcpu et 24 go de ram) qui, par moment dans la journée, sature au niveau CPU (j'ai mis 6 cpu ya pas longtemps et c tj pareil).

Je suis donc à la recherche d'infos pouvant me permettre d'endiguer le probleme. J'ai deja utilisé le "moniteur d'activité" pour voir quand ça rame qu'elles etaient les requetes "running". J'ai mis en place tous les week-end des plans de maintenance.

Pour info, l'editeur du logiciel est sponsor de l'equipe de foot de l'OL.

Je suis donc preneur d'infos et de liens et aussi de nom de sociétés ou d'independant pouvant nous aider à optimiser le serveur et surtout la bases et les requetes.

Merci à tous pour votre aide.

Je suis dans une situation similaire à la tienne.
Un ERP dont la base SQL rame parfois sans que l'on sache très bien pourquoi? Des temps de réponses anormalement long sur une base VS d'autres bases de taille comparable sur la même infrastructure réseau ...
Sauf que l'éditeur n'est pas sponsor de l'OM.


As tu pu trouver de l'aide quelque part ? de quelles sortes ?
Comment t'en es tu sorti.

Merci.

[phoenix40]

Ben, j'ai fait appel à une grosse boite informatique de bordeaux pour un audit et un expert indépendant.
Au final la grosse boite m'a fait un audit et un rapport de 10 pages en m'indiquant quelques point à amméliorer en terme de config du serveur et m'a dit qu'il fallait un audit plus poussé (donc plus cher). L'expert independant m'a dit qu'il fallait acheter une bete de course en config harware (tout ssd raid10 controlleur raid séparé, etc).

Au final j'ai apporté quelques ammélioration à la config du serveur, délocalisé certain soft qui venait taper dans la bdd sur une autre bdd et il y a eu le covid et nous avons perdu 70% d'activité (sous traitant aeronautique).

Donc le serveur n'est plus chargé.

Dans ton cas, monitore la charge cpu de ton serveur en snmp et envoi toi des alerte sur une charge cpu trop importante ou iop disque pour voir à quel moment ça le fait pour voir si ça coincide avec une tache qui tourne qquepart sur un autre serveur. Regarde tes requetes lors de charge dans le moniteur sql (pleins de script pour voir les requetes couteuses). Regarde si des requetes ne restent pas à tourner "en boucle" sur le serveur (moi ça m'arrive).

En gros moi j'ai un ERP de merde codé avec les pieds, une base qui fait 80 gigas avec des tables qui contiennent plus de 4 millions de lignes et ou il manque des index ou clés primaire (je sais plus).

Pour les ralentissement j'avais un outils de reporting qui requetait à mort sur la base de prod et du coup je l'ai passé sur un serveur sql ayant une copie de la base de prod et du coup ça va mieux.

Car je pensais (j'etait une bille en sql) que des acces en lecture à une base ne pouvait pas la bloquer !!!! grosse erreur de ma part.

Voilou j'ai essayé de faire court.

[SQLpro]

Pour information lit et applique les éléments que je donne ici :
https://www.developpez.net/forums/d2.../#post11686586

A +