none
Lenteur d'accés sur une base SQL SERVER 2008 R2 RRS feed

  • Question

  • Bonjour,

    Je suis dans un environnement virtualisé sous VMWARE et nous avons un serveur SQL 2008 R2 sous windows 2008 R2 avec 16 GRAM , 2 processeurs 4 coeurs.

    Notre base actuelle fait 7285,75 Mo avec un espace disponible de 474,39 Mo

    Notre serveur SQL est sollicité par une application en .net depuis un IIS qui nous générent  des temps de réponses de plus en plus longue.

    J'aimerais savoir s'il y a un moyen d'optimiser la base pour gagner en temps de réponse si la RAM est suffisante..Merci pour vos retours

    Cordialement.

    jeudi 19 juin 2014 15:09

Toutes les réponses

  • Bonjour

    De quand date la dernière tâche de réindexation de votre base de données ? SI vous n'avez pas de fragmentation et que vous ne souhaitez pas réindexaer, alors mettez au moins les statistiques à jour.

    Ensuite, sachant que vous être en environnement virtualisé, regardez en premier lieu le balooning. A éviter absolument. Ensuite, vérifiez la latence disque, comme d'habitude, car votre datastore est peut être trop sollicité, une erreur fréquente en virtualisation ou l'on met une bonne dizaine de VMs sur une baie de disque ne contenant qu'une dizaine ou quinzaine d'axes.

    Jetez un œil aux Waits (sys.dm_os_wait_stats) vous aurez un aperçu de ce que attends SQL Server pour gagner en perf.

    Pour terminer, validez avec un profiler que c'est bien votre SQL qui est lent et pas IIS.

    Cdlt

    Christophe


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

    lundi 23 juin 2014 20:04
  • Bonjour,

    Merci pour votre retour et je vais vérifié tous ces point.

    J'ai entre temps réalisé une manipulation de redimensionnement de la base de donnée en test et je remarque une nette amélioration au niveau des temps de réponse.

    Pensez-vous que cela soit une piste intéressante ?

    Par contre l'espace libre au niveau de la base de test à terriblement diminuer, est ce grave, peut on ré augmenter cette espace libre.

    Merci pour votre retour

    mardi 24 juin 2014 13:29
  • Bonjour

    Oui, en général, on préfère tailler large de manière à avoir tout le temps de l'espace disponible. Gardez 20% d'espace libre au moins sur la partie data.

    Pour le journal de transactions, taillez suffisamment grand pour pouvoir héberger les plus grosses transactions qui pourraient arriver sur la base. Tailler au minimum a 8GB, avec un autogrowth à la même valeur.

    Validez que vous l'avez pas l'option autoshrink activée (à ne jamais activer par ailleurs).

    Christophe


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

    mardi 24 juin 2014 19:25
  • Merci pour votre retour.

    Savez-vous si l'on peux mettre en place un plan de maintenance automatique avec avec sql Management studio sur la partie réorganisation des index ou autre option de compactage.

    Merci

    mercredi 25 juin 2014 12:44
  • Je viens de vérifier et on peux tout a fait le réaliser via management studio via une tache de maintenance.

    Par contre le compactage de la base est il conseiller et si oui combien de fois par semaine OU MOIS ?

    Merci

    mercredi 25 juin 2014 13:20
  • Voici mon plan de maintenance planifier une fois par semaines :

    Réorganiser les Index

    Reconstruire les Index

    Mettre à jour les statistiques

    Vérifier l'intégralité de la base

    Est ce le bon ordre ? ou placer la réduction de la base ?

    Merci pour vos retours

    mercredi 25 juin 2014 15:13
  • Bonjour

    Je vous propose simplement

    Intégrité de la base

    Reconstruction d'index

    Surtout PAS de réduction de la base.

    Christophe.


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

    mercredi 25 juin 2014 19:00
  • Bonjour,

    Pourquoi la réduction de base est elle à souscrire ?

    Merci.

    jeudi 26 juin 2014 08:12
  • Proscrire ...

    Pour plusieurs raisons :

    - une partie du boulot de DBA est de faire du capacity planning de manière a toujours avoir de l'espace disponible dans le base. Si possible au moins 20% sur la partie des Data.

    - Et c'est pire pour le journal de transaction : celui dit doit avoir une capacité suffisante, impossible ici de vous donner des chiffres. 10GB, 20GB, 50GB ou beaucoup moins, cela dépend de nombreux paramètres dont la taille de la base de données, le nombre de transactions / sec, le nombre d'utilisateurs, la taille moyenne des transactions ainsi que l'espace occupé par les plus grosses transactions, le modèle de récupération de la base, ... Donc autant le jouer aux dés. Bref quasi impossible à déterminer. Donc on taille relativement large pour ne pas a avoir a agrandir ce fichier LDF car on ne peut pas désactiver le zéroing du fichier (instant file initialization) contrairement aux fichiers de données. Donc si vous diminuez la taille du LDF, alors au moment où SQL Server devra l'agrandir, alors il devra écrire autant de zéros sur disque (1GB, 10GB ...). Et ça prends du temps, beaucoup de temps, voire beaucoup beaucoup de temps si votre sous système disque est lent. PEndant ce temps, aucune transaction ne peut s'effectuer sur la base, bref activité extrêmement ralentie voire quasi bloquée. Et diminuer la taille du fichier demandera également un peu de ressources. Donc en faisant du shrink vous allez jouer au Yo-Yo avec votre fichiers LDF, en consommant beaucoup de ressources et en fragmentant le fichier sur disque de surcroit.

    - Une fois la phase de diminution terminée, il y a de fortes chances que les données soient fragmentées. Alors que l'on essaie de limiter la fragmentation avec des réindexations régulières

    Et le fait de faire un shrink va réduire à néant tout ce travail.

    Bref, a moins d'avoir une bonne raison de diminuer la taille de la BD (pour rendre de l'espace au système, à Windows, qui n'en fera rien par ailleurs), laissez la vivre sa vie avec plein d'espace disponible. SI par contre vous avec eu une activité exceptionnelle, comme une très grosse suppression de données, alors, peut être on pourra envisager un DBCC SHRINKFILE, pas surement pas un DBCC SHRINKDATABASE vous laissant avec un taux d'espace disponible de 10%, ou autre, sans aucun lien avec l'activité supportée par votre base.

    Petite metaphore si vous n'êtes pas convaincu :

    Imaginez simplement que chaque fois que vous roulez avec votre voiture, le volume de votre réservoir d'essence diminue en fonction de la consommation (le shrink). Lorsque vous ferez le plein (des inserts / update / delete), votre réservoir sera tout petit. Avant de pouvoir ajouter du carburant, vous devrez agrandir la réservoir, donc attendre. Puis ajouter quelques litres. Puis il sera à nouveau plein, et vous devrez encore l'agrandir. Donc attendre. Et lorsque vous aurez passé quelques heures à faire le plein (et on est dans un cadre idyllique où les matériaux pour agrandir le réservoir sont disponibles rapidement et que vous n'avez pas a faire la queue trop longtemps à la caisse pour payer (latence disque) ), ou en tous cas mettre suffisamment d'essence pour faire au moins le trajet le plus long ainsi que le retour sur lequel il n'y a pas de station essence (une transaction et la partie undo pour un rollback) alors vous serez convaincu qu'il n'est vraiment pas utile de diminuer la contenance de votre réservoir (espace du fichier LDF).

    Cdlt

    Christophe


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


    jeudi 26 juin 2014 12:58
  • Bonjour,

    Merci pour toutes ces précisions et votre temps passer sur cette demande.

    Je pense avoir bien compris le message, vous pouvez clore ce ticket.

    Merci

    jeudi 26 juin 2014 15:55