Lenteur lors de l'accès aux données
Question
Toutes les réponses
-
Hello David,
Je suis désolé je réponds tardivement.
Le script dont vous faites mention correspond à l'idée, oui.Pour l'entretien des bases de données, je vous propose de "ne pas réinventer la roue" et de vous baser sur de merveilleux scripts SQL faits par Ola Hallengren appelés "maintenancesolution".
Qu'est-ce donc ?
C'est un script SQL qui va créer (presque) tout seul des jobs dans le moteur SQL Server.
Paramétrés comme il faut, fiables et robustes.On trouve le script sur son propre site : https://ola.hallengren.com/
Je pense que plein de sites doivent donner des détails.Il crée quoi ?
Il crée tous ces jobs là, mais ne les exécute pas, ils sont simplement créés dans l'instance SQL.
Dans l'exemple ci-dessous, ce qui vous intéresse c'est le job entouré en vert.
Les autres sont (aussi) de fantastiques jobs de sauvegarde.Le mieux c'est de demander à votre prestataire de planifier ce job pour fonctionner (au pire) une fois par semaine. Il va faire des tâches de base sur vos index SQL, qui aident au moins à ce que la situation n'empire pas.
Je rappelle que cela ne remplacera jamais un DBA mais c'est un archi-minimum.Sinon, pour connaître ce qui ralenti votre moteur SQL.
Encore un autre script.
Il vient de là : http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/Il suffit de l'exécuter dans le moteur, et il va ressortir toutes les statistiques de "waits" du moteur SQL.
Ce sont des statistiques calculés depuis que le serveur SQL a été allumé, donc certaines valeurs peuvent être "noyées/diluées".Quand vous (ou votre prestataire) l'exécuterez, il va vous sortir un tableau de statistiques comme celui-ci :
Ce qui nous (et vous) intéresse sont les "Wait Type", de la première colonne.
Il y en a plein de types différents, et un DBA pourrait vous donner des détails.Mais, ils permettent quand même de se faire une idée de "ce qui ne va pas" et de l'ampleur du ralentissement (colonnes WaitCount et AvgWait_S).
Je ne vais pas vous lister tous les "waits" et leur explication, je ne suis pas assez doué.
Mais certains types de wait "montrent du doigt" l'origine du problème.Je vous mets comment on interprète certains des résultats.
Vous avez des problèmes :
- "IO" (donc disque) si vous voyez plein de :
PAGELATCH_EX, WRITELOG, - "Mémoire" (genre, pas assez de mémoire pour l'instance SQL) si vous avez plein de :
PAGEIOLATCH_SH, RESOURCE SEMAPHORE, SOS SCHEDULER - "Client" (le poste/serveur client est très long pour traiter les données que lui renvoie SQL) si vous avez plein de :
ASYNC IO COMPLETION et ASYNC NETWORK IO.
Si vous avez des tonnes de "TRACEWRITE", c'est bénin vous pouvez oublier.
Si vous avez des tonnes de "CXPACKET" c'est un problème de parallélisation de threads (expression compliquée qui se traduit par : "le moteur SQL effectue plusieurs processus en même temps et il doit attendre la fin d'un processus pour en terminer un autre") et qui se résout simplement.N'hésitez pas à me mettre une copie d'écran de ce que le script vous donne comme info.
(il n'y a rien de confidentiel là-dedans).Florent
- Modifié Florent Duret jeudi 5 novembre 2015 17:18
- "IO" (donc disque) si vous voyez plein de :
-
Bonjour,
Tout d'abord merci beaucoup pour votre réponse.
Il me semble que les fichiers sont stocké en FileStream (je ne suis pas sûr, je suis encore débutant), ils sont stocké dans un dossier et ce sont fichier PDF. Comment peut on vérifier s'il vous plait?
Les ralentissements ont lieu dès qu'il y à une requête à la base de donnée (peu importe la requête).
Lors de la restauration de la base, le prestataire qui gérait la base (la base de donnée est fourni avec un progiciel) m'as affirmé que lorsqu'il restaurait sans les pieces jointes (les fameux fichiers PDF), tout allait bien.Voici le resultat du script fournis par florent:
J'ai également fait les tests suivants :
Réindexation de toutes les bases (Master, model, msdb, tempdb, BDDappli) => aucun résultat notable
Défragmentation de toutes les bases (Master, model, msdb, tempdb, BDDappli) => Aucun résultat notable
Suppression du dossier qui contiens les fichiers => Aucun résultat notable
Désactivation des logs => Aucun résultat (Vous inquiétez pas, c'est pas la base de prod mais une base sur une machine virtuelle)
Vidage du cache de toutes les bases (Master, model, msdb, tempdb, BDDappli) => aucun resultat
Vérification des droits des fichiers => Aucun résultat
La config de mon pc :
Core i7
16 Go de ram
SSD
Et la base est sur virtualbox.
Merci beaucoup pour votre précieuse aide.
- Modifié David Lambert lundi 28 décembre 2015 09:47
-
Re-bonjour,
j'ai désactivé l'indexation et le 8.3 (j'ai rien trouvé à propos du lastuseraccess ?) => légére amélioration de l'ordre de 4 secondes (normalement l'opération en question devrait mettre 25 secondes mais prend actuallement plusieurs minutes )
Non il n'y a pas d'antivirus sur le serveur
Pas d'amélioration notable sous vmware :/
j'ai relancé le script de stat
Merci beaucoup de votre aide.
- Modifié David Lambert lundi 28 décembre 2015 14:03
-
Voici les informations sur l'instance:
Il s'agit d'un compte intégré (administrateur)
la mémoire :
min : 0 mo
max : 2147483647 mo
taille minimale par requête : 1024 ko
- Modifié David Lambert lundi 28 décembre 2015 15:40
