timeout sql server 2008

[tortuegenie]

Bonjour, ma base de donnée Sql server 2008 vient de passer de 20Mo á 780Mo, car j'ai du faire beaucoup d'insertion pour mon projet.

Seulement depuis que la taille de ma bdD a augmenté, j'ai des erreurs de timeout.

Comment puis-je faire en sorte de ne plus avoir ces erreurs de timeout ?

Merci d'avance

[zinzineti]

Peux-tu poster le message d'erreur ?

[aieeeuuuuu]

Bonjour

Je suppose que tu parle de timeout au niveau de l'application qui effectue la requete. Dans ce cas, augmente la durée du timeout.

Mais le mieux dans ton cas, c'est encore de retrousser tes manches, et d'optimiser ta base pour qu'elle réponde dans des délais acceptables :
Création d'index, optimisation des requêtes, ...

[mikedavem]

Envoyé par tortuegenie

Bonjour, ma base de donnée Sql server 2008 vient de passer de 20Mo á 780Mo, car j'ai du faire beaucoup d'insertion pour mon projet.

Seulement depuis que la taille de ma bdD a augmenté, j'ai des erreurs de timeout.

Comment puis-je faire en sorte de ne plus avoir ces erreurs de timeout ?

Merci d'avance

Mettez à jour vos statistiques et effectuez une maintenance de vos index.
Dites nous si cela règle votre problème.

++

[Papy Normand]

Envoyé par tortuegenie

Bonjour, ma base de donnée Sql server 2008 vient de passer de 20Mo á 780Mo, car j'ai du faire beaucoup d'insertion pour mon projet.

Seulement depuis que la taille de ma bdD a augmenté, j'ai des erreurs de timeout.

Comment puis-je faire en sorte de ne plus avoir ces erreurs de timeout ?

Merci d'avance

Bonjour,

D'habitude, ce genre de problème se produit lors des insertions car le créateur de la base de données a oublié de mettre une augmentation de taille du fichier data (.mdf) avec une valeur suffisante pour que l'augmentation de la taille se fasse peu de fois. Cette opération est très couteuse en ressources système et est loin d'etre instantanée ( il faut que Windows trouve de la place libre de taille suffisante, la rattache à la base et initialise le contenu... ). Une des 1ères régles que j'ai apprise est de configurer la taille et l'augmentation de cette taille de la base de telle sorte qu'aucune augmentation de taille se fasse de jour , avec la nuit après la sauvegarde, une augmentation automatique de cette taille ( voir à prévoir une base de données qui pourrait stocker les tailles de vos bases et des valeurs raisonnables d'augmentation de la base ).

La solution d'augmenter le timeout de la commande ( par défaut 30 secondes ) peut sembler judicieuse.Par contre, il faudrait peut-être regarder aussi si le(s) disques n'est ( ne sont ) pas trop fragmentés car , si je me souviens , il faudrait que l'extension de taille de la base lors d'une augmentation , soit d'un seul tenant.
Pour mikedavem, mettre à jour les statistiques , je ne suis pas sûr que ce soit une solution intéressante , par contre la maintenance des index oui et voir s'il est possible de mettre les index sur un autre disque physique, pourquoi pas ?

Je serai curieux de savoir en combien de temps la taille est passée de 20 Mo à 780 Mo et si cette augmentation risque d'être répétitive (chaque jour ) et se reproduira souvent ( cette augmentation brutale peut simplement être due à un chargement initial ou ponctuel de la base , si c'est sur une très courte période et à prévoir souvent, il faudrait revoirà la hausse la valeur de l'augmentation de taille )
C'est un sujet très vaste, mais j'ai déjà vu ce genre de problème sur une base où tous champs de type chaine étaient définis en nchar(3000) alors que dans 98% des enregistrements, ils n'étaient remplis qu'à 5%

Bonne soirée

PS : s'il y a augmentation de la taille, le temps nécessaire pour cette augmentation est compté dans le timeout. De plus, le timeout se déclenche si la transaction n'est pas terminée dans le temps imparti. Il faudrait connaître le texte de votre Insert pour savoir si par hasard, vous n'auriez pas en fait non pas une insertion dans une table mais plusieurs insertions dans plusieurs tables ou plus vicieux à trouver une multitude d'index ( ou de clés étrangères ) dont les statistiques sont mis à jour à chaque insertion

[mikedavem]

D'habitude, ce genre de problème se produit lors des insertions car le créateur de la base de données a oublié de mettre une augmentation de taille du fichier data (.mdf) avec une valeur suffisante pour que l'augmentation de la taille se fasse peu de fois. Cette opération est très couteuse en ressources système et est loin d'etre instantanée ( il faut que Windows trouve de la place libre de taille suffisante, la rattache à la base et initialise le contenu... ). Une des 1ères régles que j'ai apprise est de configurer la taille et l'augmentation de cette taille de la base de telle sorte qu'aucune augmentation de taille se fasse de jour , avec la nuit après la sauvegarde, une augmentation automatique de cette taille ( voir à prévoir une base de données qui pourrait stocker les tailles de vos bases et des valeurs raisonnables d'augmentation de la base ).

Depuis SQL Server 2005, il est possible d'eviter ces operations coûteuses avec la fonctionnalité Database Instant File Initialization. Il faut bien sûr s'assurer que le compte de service ait le privilège SE_MANAGE_VOLUME_NAME.

Bien entendu cela n'empêche pas de dimensionner correctement les fichiers de bases sur une durée suffisante de production pour éviter la fragmentation des fichiers de bases de données sur disque.

Ici en l'occurence, le problème est apparu après l'insertion. Il y a fort à parier que les statistiques et / ou les index soient en causes. Le volume de la base reste assez faible pour mettre en cause la volumétrie ... quoi que ...

Il faudrait avoir un exemple ou des exemples de requête qui partent en timeout ....

On attend la suite ....

PS : Papy Normand du msdn ? Welcome :-)

++

[Papy Normand]

Bonjour mikedavem,

A votre question du postscriptum : oui

Je suppose que vous faites allusion à
http://support.microsoft.com/kb/315512/en-us
( je ne donne pas le lien français , la traduction automatique est une horreur )
Comme origine du timeout, j'oscille entre 2 possibiltés :
- une fragmentation de la base à cause de trop nombreuses augmentations de la taille de la base
- et comme vous, des procédures stockées ou fonctions de conception douteuses ( par suite d'index manquants ou mal construits ou des clés primaires manquantes )
Par contre , tortuegenie pourrait essayer de voir 3 choses :
- le plan d'execution de ses requetes avant et après les insertions de masse
http://msdn.microsoft.com/fr-fr/libr...=SQL.100).aspx
http://msdn.microsoft.com/fr-fr/libr...=SQL.100).aspx
- utiliser SQL Server Profiler ( malheureusement non disponible pour toutes les éditions )
- regarder si certaines procédures stockées ne seraient pas par hasard avec l'option with recompile ( petite erreur qui m'a couté il y a 3 ans 1 journée de recherche, une personne avait introduite cette option parce qu'elle avait souvent à modifier une procédure stockée )

Bonne journée

PS : mikedavem, j'espère que je ne vous ai jamais géné avec mes commentaires

[mikedavem]

Non non pas du tout ... nous sommes dans un espace d'échange .. tout commentaire est le bienvenue

++