Discussion :

[sevyc64]

Bonjour à tous,

Sur mon poste de développement, je suis passé de SQLServer 2008 à SQLServer 2017 et je rencontre depuis quelques problèmes de performance générale de SQLServer. Il est lent, les requêtes mettent 2 à 5 fois plus temps à s’exécuter.
Des scripts qui fonctionnaient très bien sous 2008, sortent souvent en timeout, maintenant.

Quels sont les paramétrages à regarder et ajuster pour revenir à des performances acceptables ?


SQLServer Standard 64 bits 14.0.2027.2
Instance nommée
Windows 10 PRO 1909 64 bits
I7-6700 3.4GHz
16Go de ram

[SQLpro]

1) recalculer toutes les stats en mode FULLSCAN
2) redimensionner les epsaces de stockage pour éviter les opérations de croissance des fichiers
3) revoir le plan d'indexation

A +

[sevyc64]

Je précise, ce n'est pas une base en particulier qui est lente mais le serveur dans son ensemble.

Sur ce serveur, je peux monter, démonter, restaurer, créer dynamiquement de toute pièce, jusqu'à une 10ène de bases par jour, des bases qui fonctionnent correctement sur d'autres postes.
Même les restaurations sont bien plus lentes.
L'espace de stockage est strictement le même que pour le 2008, même dossier sur le même disque.

Autre phénomène observé, une requête exécutée en un temps limite raisonnable (pour un poste de dev) une fois, pour se révéler très lente quelques minutes plus tard, comme si à l’instar de Windows, le serveur s'était mis en veille entre-temps et donc avait besoin de plus de temps pour exécuter la requête, le temps de sortir de veille.
A ma connaissance il n'y a pas de système de veille automatique sur SQLServeur, si ?

SQLpro> pour les points que tu cite, tu peux donner plus de précision, stp. Bien que j'ai quelques connaissances, je suis pas admin sql. Je suis pas sur de savoir où chercher.

[SQLpro]

Autres hypothèses :

1) les bases ne serait_elle pas en mode autoclose ?

Pour voir et rectifier, lancez la requête suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT name, is_auto_close_on, 'ALTER DATABASE [' + name + '] SET AUTO_CLOSE OFF;' AS SQL_COMMAND
FROM   sys.databases 
WHERE  is_auto_close_on = 0;

Copiez coller le code de la colonne SQL_COMMAND dans une nouvelle fenêtre et exécutez-le.

2) quelle est la RAM affectées aux instances ?

Avec 16Go de ram vous devriez mettre 6 Go par instance

3) le PC serait-il en mode d'économie d'énergie ?

Si oui désactivez cette fonctionnalité

Pour recalculer toutes les statistiques en mode FULLSCAN de toutes les bases (sauf systèmes et inaptes) , lancer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
DECLARE @QRY NVARCHAR(max) = 
'SELECT N''UPDATE STATISTICS [???].['' + s.name + N''].['' + o.name + N''] (['' + st.name + N'']) WITH FULLSCAN;'' COLLATE French_CI_AI
FROM   [???].sys.stats AS st
       INNER JOIN [???].sys.objects AS o ON st.object_id = o.object_id
       INNER JOIN [???].sys.schemas AS s ON o.schema_id = s.schema_id';
DECLARE @SQL NVARCHAR(max) = N'';
SELECT @SQL = CASE WHEN @SQL = N''  THEN N'' ELSE @SQL + ' UNION ALL ' END  + REPLACE(@QRY, '???', name)
FROM   sys.databases AS db
WHERE  database_id > 4
  AND  db.is_read_only = 0
  AND  db.state = 0;
EXEC (@SQL);

Copiez, coller le résultat dans une nouvelle fenêtre et exécutez-là.

A +

[sevyc64]

Bon, retour après quelques jours d'utilisation. Les requêtes n'ont rien changé . J'ai tenter une réparation de l'instance, ainsi que l'install de toutes les mises à jours possibles, le dernier patch cumulatif notamment, cela n'a rien changé non plus.

Là, je viens de passer 25min à attendre la suppression de 13500 lignes depuis le mode "Modifier toutes les lignes" de SSMS. Ca ne devrait prendre que quelques secondes habituellement.

Par contre, 2 min après, l'insertion, dans la même table, de 13900 ligne a, elle, pris moins d'une 1s.

Ce matin, je travaille en parallèle sur un autre serveur, 2017 aussi, au bureau, donc connexion distante, plusieurs 100ène de km, à travers un vpn, malgré les lenteurs inhérentes à ce mode de connexion, c'est nettement plus rapide qu'en local sur mon poste

[Bernardos]

Bonjour,
Moi j'ai eu des soucis lors d'une migration de SQl server 2008 R2 à 2016.
Certaines requêtes qui était express se sont mis à prendre des 20 minutes.
C'est un peu loin dans ma mémoire mais de ce que je me souviennes, ca concernait des procedures stockées avec paramètres et pour la plus part des CTE. c'était dans mon cas une histoire de "parameter sniffing".
Je ne dis pas que c'est ton problème mais en tout cas moi je l'ai eu. je l'avais résolu en utilisant l'option Recompile dans les procédures concernées.
En sql server 2017 il y a l'option de bases de données Parameter Sniffing mais je pense que c'est le genre de paramètres à utiliser avec beaucoup de précautions (tout comme le recompile).
Cordialement,

[SQLpro]

Bon, retour après quelques jours d'utilisation. Les requêtes n'ont rien changé . J'ai tenter une réparation de l'instance, ainsi que l'install de toutes les mises à jours possibles, le dernier patch cumulatif notamment, cela n'a rien changé non plus.

Là, je viens de passer 25min à attendre la suppression de 13500 lignes depuis le mode "Modifier toutes les lignes" de SSMS. Ca ne devrait prendre que quelques secondes habituellement.

Par contre, 2 min après, l'insertion, dans la même table, de 13900 ligne a, elle, pris moins d'une 1s.

Ceci est un syndrome très classique lié au capacity planning. Si vous avez taillé des espace de stockage important, l'effort à faire pour l'insertion physique est négligeable. En ayant supprimé, vous avez dégagé de l'espace pour les nouvelles insertions..... Donc, voir a bien dimensionner vos espaces de stockage et vérifier la latence de votre disque...

Ce matin, je travaille en parallèle sur un autre serveur, 2017 aussi, au bureau, donc connexion distante, plusieurs 100ène de km, à travers un vpn, malgré les lenteurs inhérentes à ce mode de connexion, c'est nettement plus rapide qu'en local sur mon poste

Donc, réellement un problème de PC ou de config....

Vous n'avez pas répondu à mon précédent post.....

A +