none
Traitement de données lent dans SQL SERVER via une application VB.NET RRS feed

  • Question

  • Bonjour,

    Je fais la maintenance d'une application VB.NET avec une base de données SQL SERVER 2008R2.

    En effet la base étant devenu très volumineuse les requêtes vers celle ci mettent trop de temps pour donner les résultats.

    J'utilise des procédures stockées. et même avec des index c'est parfois même plus lent. Et je n'arrive plus à créer de nouveaux index dans la base. j'utilise donc ceux qui existaient. Il n'y a aucune d'erreur dans mon code.

    L'application fonctionne mais le temps d'attente est excessivement long.

    Pouvez vous m'aider???

    Cordialement,


    CRMUSER


    mercredi 29 juillet 2015 12:15

Réponses

Toutes les réponses

  • Bonjour

    Comme ce sont des procédures stockées, il est envisageable que le plan d'exécution associées à la procédure soit obsolète. Je t'invite à les supprimer via la commande : DBCC FREEPROCCACHE

    Après, il faut regarder le wait_type de la session exécutant la procédure lente, voir si les statistiques des objets sont à jour, s'assurer qu'il n'y a pas de verrou, envisager des indexs filtré, fixé des plans d'exécution.

    Les possibilités sont très nombreuse.

    mercredi 29 juillet 2015 12:20
  • Bonjour,

    Merci pour votre réponse. Je reconnais une la commande DBCC FREEPROCCACHE que  j'ai vu une fois dans un post des commandes qui serviraient à réinitialiser le cache de SQL SERVER.

    Veuillez m'excuser mais je n'ai pas une connaissance avancée de SQL Server donc j'ai un peu de mal à vous suivre. Néanmoins voici les commandes que j'ai vu :

    DBCC FREESYSTEMCACHE('ALL')
    DBCC FREESESSIONCACHE
    DBCC FREEPROCCACHE
    DBCC FLUSHPROCINDB( db_id )
    CHECKPOINT
    DBCC DROPCLEANBUFFERS

    j'aimerais savoir à quoi chacune d'elles signifie réellement et que devrais-je mettre en lieu de db_id si je dois les exécuter sur ma base?

    Cordialement,



    CRMUSER


    mercredi 29 juillet 2015 18:00
  • SQL Server ne lis rien et n'écris rien directement sur le disque, il passe toujours par la mémoire, par de page de 8ko en mémoire. Dans cette mémoire, on y trouve tous ce qui permet à sql server de fonctionner :

    • un cache de connexion
    • un cache des plans d'exécution
    • un cache de données 
    • ...

    Du coup :

    CHECKPOINT :
    redescent sur le disque les pages en mémoire pour la base ou la commande a été joué. L'exécution est faite automatiquement par le moteur SQL

    Pour le reste je vous invite a regarder les 2 liens suivants :

    DBCC FREESYSTEMCACHE('ALL')
    DBCC FREESESSIONCACHE
    DBCC FREEPROCCACHE
    DBCC FLUSHPROCINDB( db_id )
    DBCC DROPCLEANBUFFERS

    db_id correspond à l'identifiant de la base de données qui peut être retrouvé dans la DMV : sys.databases

    mercredi 29 juillet 2015 20:20
  • Merci beaucoup pour votre aide. A présent je comprends mieux à quoi servent ces commandes et d'où pourrait venir ce problème de lenteur.

    j'essaierai de les exécuter sur la base cible pour ne pas affecter les autres contenues sur le même serveur.

    et je verrai si les choses s'améliorent.

    Cordialement,

    CRMUSER


    jeudi 30 juillet 2015 10:28
  • J'aimerais savoir si l'utilisation de tables temporaires (globales et locales) peut avoir des conséquences sur la performance? Car je les utilise dans presque toutes mes PS. Un exemple de PS que j'ai écrite, le principe est le suivant: Je veux récupérer des informations des tables A,B,C,D(qui contiennent toutes des milliers voir millions de lignes). Je fais une requête de sélection dans une table A en fonction de certains critères. je mets le résultat dans une table temporaire globale ##A. Pour récupérer les lignes A qui sont associées aux autres tables selon des critères de jointures, je fais une jointure de la table B et la ##A pour éviter de repasser par la table A qui a beaucoup plus de données. J'utilise également la table ##A pour faire les autres jointures avec les tables C et D. Est-ce une bonne méthode? Cela permet-il de gagner en performance? Devrais-je plutôt faire mes différentes jointures directement sur la table? Quel cheminement serait le plus optimisé?

    Cordialement,


    CRMUSER


    jeudi 30 juillet 2015 12:32