none
MS-SQL 2016 : améliorer les performances RRS feed

  • Question

  • Bonjour,

    Me utilisateurs me reprochent 3 secondes pour afficher des informations provenant d'une base MS-SQL.
    Sachant que ces informations sont traitées et affichées sous forme de graphique (courbes).
    Cela prend 3 secondes, et pas 1 secondes comme c'était le cas sur l'ancienne génération du logiciel tiers et d'un MS-SQL 2008.

    J'ai fixé la RAM de SQL à 12 Go sur 24 Go pour le serveur.
    J'ai fixé à 4096 la taille maxi des requêtes.

    Ces valeurs peuvent être augmentées. (jusqu'à 128 Go).

    Mais, n'y aurait-il pas une indexation de la base ou une autre maintenance de la base à réaliser ?

    Cdlt,

    mercredi 10 avril 2019 17:37

Toutes les réponses

  • Bonsoir,

    comment s'est faite la migration?

    Même serveur ou nouveau serveur? Mêmes fichiers de bases ou base restaurée ?

    Il y a trop de paramètres...

    - Processeurs utilisés (et bien configurés dans SQL)

    - Volumes disques de données formaté avec des tailles de blocs adaptés (32 ou 64K).

    - Optimisation des procédures stockées...

    et bien entendu, la manière dont ont été constitués ou reconstitués les indexes sur SQL 2016.

    A bientôt,


    Thierry DEMAN-BARCELO. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2012(85 MCPs). MCSA Office 365 http://base.faqexchange.info

    mercredi 10 avril 2019 18:21
    Modérateur
  • Qui plus est la performance de l'application n'est pas un indicateur fiable pour analyser le problème.

    Identifiez la requête, exécutez la en mesurant les temps (set statistics time on) et en fonction du résultat on verra venir.

    • J'ai déjà eu le cas où le programme ne faisait pas une requête mais un ensemble de requêtes. Unitairement les requêtes étaient au top.
      Globalement c'était une catastrophe.
      L'application n'avait pas changé.
      L'algorithme de base n'avait jamais été testé face à une montée en charge (ici le volume).
      Pas de solution possible au niveau SQL server.
      Prouver ça et le maintenir face à l'éditeur est un combat pour le quel il vaut mieux être sûr de soi.


    Modifier des paramètres à l'aveugle, cad sans mesure avant mesure après, est le plus sûr moyen d'accumuler des bêtises. Remettez donc la valeur minimale de mémoire par requête à sa valeur par défaut.

    jeudi 18 avril 2019 08:07
  • Bonjour

    Beaucoup de points a vérifier en effet.

    J'imagine qu'il s'agit d'un nouveau serveur, nouvelle VM ? Déjà conf de l'ESX, conf de la VM, Setup de SQL, conf de SQL.
    Ensuite, process de migration ? Drop des anciennes stat d'index, reconstruction de tous les index post-migration ?

    et ... encore bcp d'autres raisons, dont des changements dans le query optimizer et cost estimator.

    Et dernier point, non des moindres : est-ce que le problème de perf a été validé par des mesures au travers des xEvents et/ou profiler + compteurs de perf Windows ? 

    Cdlt
    Christophe


    Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

    mardi 23 avril 2019 10:24
  • Bonjour

    De manière radicale tu peux toujours opter pour du SSD.

    Toutes mes bases SQL sont en SSD.

    Un pur bonheur.

    De plus grâce aux conseils de M LAPORTE j'ai pu procéder a des petites optimisations.

    Encore Merci M LAPORTE et bonne journée


    "Marquer comme réponse" les réponses qui ont résolu votre problème

    samedi 27 avril 2019 10:59