Discussion :

[Pol63]

Bonjour,

j'ai une base de données en prod qui a voulu passer de 14 à 15Go (fichier mdf, 1000 Mo de grow, pas de fast grow activé, journalisation complète, ldf quasi vide)
et pendant 2h le log d'sql server contient l'erreur auto grow failed timeout ou cancelled, parfois la tentative s'arrête après 2 secondes, parfois presque 20 ...

1/ quelles sont les causes qui pourraient faire fail l'auto grow ?
2/ on est d'accord que 20s pour 1Go sur un serveur avec des disque sas 15kt/min c'est déjà trop ? ^^

infos complémentaires :
une petite dizaine d'applis connectés (3 sur le serveur et le reste en réseau local)
surement des centaines de connexions à la seconde sur la base (jamais en dessous de 100 par seconde je pense)
je ne sais pas ce qui a débloqué la situation, un collègue a fait quelques manip (redémarrage d'sql server surement, arret de quelques appli aussi)

Merci.

[Invité]

Deux points évidents mais à vérifier :
Est-ce que la taille maximale du fichier est atteint ?
Est-ce qu'il reste de l'espace sur le disque ?

[Pol63]

taille illimitée
300Go de libre

[Invité]

Peut-être que le 1 Go d'incrément prend trop de temps à être appliqué, si les disques sont pas mal sollicités.
Essaie de passer le pas à 500 Mo ou 250 Mo.

[Pol63]

j'ai en effet passé à 500Mo

mais vu que des fois c'est failed au bout de 2 secondes, et qu'il y a eux des dizaines de tentatives, je voulais savoir concrètement qu'est ce qui fait qu'sql server puisse se dire j'abandonne
j'ai bien pensé à des verrous, mais je ne vois pas en quoi écrire sur une zone du disque inutilisée ferait qu'sql server pose des verrous quelquepart

[SQLpro]

j'ai en effet passé à 500Mo

mais vu que des fois c'est failed au bout de 2 secondes, et qu'il y a eux des dizaines de tentatives, je voulais savoir concrètement qu'est ce qui fait qu'sql server puisse se dire j'abandonne
j'ai bien pensé à des verrous, mais je ne vois pas en quoi écrire sur une zone du disque inutilisée ferait qu'sql server pose des verrous quelquepart

Il pose des verrous pour analyser le disque, afin de n'avoir aucune écriture le temps de faire cette analyse !

Pour info :

What are the performance implications?

If you run a transaction that requires more log space than is available, and you have turned on the autogrow option for the transaction log of that database, then the time it takes the transaction to complete will include the time it takes the transaction log to grow by the configured amount. If the growth increment is large or there is some other factor that causes it to take a long time, the query in which you open the transaction might fail because of a timeout error. The same sort of issue can result from an autogrow of the data portion of your database. To change your autogrow configuration, see the "ALTER DATABASE" topic in SQL Server Books Online.

Extrait de :
https://support.microsoft.com/en-us/kb/315512


A +

[SQLpro]

j'ai une base de données en prod qui a voulu passer de 14 à 15Go (fichier mdf, 1000 Mo de grow, pas de fast grow activé, journalisation complète, ldf quasi vide)

Pourquoi ne pas avoir provisionné au départ ? Plus vous allez faire de grands incréments et plus cela va prendre de temps et plus cela va conduire à des time out. C'est de la mauvaise gestion. Vous devez provisionner vos fichiers de données pour 3 à 5 ans de production ou bien surveiller préventivement le remplissage de vos fichier et agir avant qu'il ne soit trop tard manuellement

et pendant 2h le log d'sql server contient l'erreur auto grow failed timeout ou cancelled, parfois la tentative s'arrête après 2 secondes, parfois presque 20 ...

C'est normal il cherche sur tout le disque la meilleurs place pour créer cette extension => analyse du disque et de ses plateaux... Comme vous êtes en autogrowth, votre disque est déjà terriblement morcelé. Il constitue donc une table des possibilité d'extensions compte tenu des différentes bribes que vous lui laissez pour trouver la meilleurs config de raboutage de bout de fichier et cela prend du temps. Ensuite il doit "formater le raboutage effectué...

1/ quelles sont les causes qui pourraient faire fail l'auto grow ?
2/ on est d'accord que 20s pour 1Go sur un serveur avec des disque sas 15kt/min c'est déjà trop ? ^^

Non... c'est normal. C'est votre organisation qui est nullissime et le DBA aux abonnés absent !

infos complémentaires :
une petite dizaine d'applis connectés (3 sur le serveur et le reste en réseau local)
surement des centaines de connexions à la seconde sur la base (jamais en dessous de 100 par seconde je pense)
je ne sais pas ce qui a débloqué la situation, un collègue a fait quelques manip (redémarrage d'sql server surement, arret de quelques appli aussi)

Merci.

Ha chapeau on redémarre parce que personne ne sait quoi faire !

DIMENSIONNEZ votre fichier à 20 Go au minimum et c'est tout. Prévoyez un incrément beaucoup plus, modeste (25 M0 par exemple)

A +

[Pol63]

merci sqlpro pour ton accueil toujours aussi chaleureux, mais bon on vient pour de la technicité pas pour de la délicatesse

Pourquoi ne pas avoir provisionné au départ ? Plus vous allez faire de grands incréments et plus cela va prendre de temps et plus cela va conduire à des time out. C'est de la mauvaise gestion. Vous devez provisionner vos fichiers de données pour 3 à 5 ans de production ou bien surveiller préventivement le remplissage de vos fichier et agir avant qu'il ne soit trop tard manuellement.

la base doit avoir pas loin de 5 ans
on pourrait dimensionner dès le début à 100Go pour être tranquille pendant 10 ans en effet, mais on préfère dimensionner à 2Go avec autogrow à 1Go pour de mauvaises raisons
quand on ramène une copie d'une base chez nous, au moment de rattacher le backup ca créé des fichiers de la même taille, et déjà qu'on nous emmerde quand on a 10Go de code source sur notre serveur de développement tu imagines bien qu'on a pas 100go de libre

C'est normal il cherche sur tout le disque la meilleurs place pour créer cette extension => analyse du disque et de ses plateaux... Comme vous êtes en autogrowth, votre disque est déjà terriblement morcelé. Il constitue donc une table des possibilité d'extensions compte tenu des différentes bribes que vous lui laissez pour trouver la meilleurs config de raboutage de bout de fichier et cela prend du temps. Ensuite il doit "formater le raboutage effectué...Non... c'est normal.

alors oui maintenant que vous le dites je savais qu'il analysait les plateaux lors de la création d'une base mais ca ne m'est pas venu à l'idée qu'il le faisait sur une extension, au temps pour moi.
après morcelé je bien veux croire, mais il reste quand même plus de 50% d'espace libre (mais bon windows n'a jamais été fort en fragmentation je crois, et on a pas mal de fichier écris puis supprimés donc pourquoi pas que ca lui prenne beaucoup de temps)

C'est votre organisation qui est nullissime et le DBA aux abonnés absent !

si si je suis là, c'est même marqué sous mon avatar
je suis peut etre loin du dba mais on ne peut pas toujours avoir un truc parfait, on a pas un budget pour se former à tout, donc on fait au mieux pour que ca se passe bien et que ca tienne longtemps
et de côté là on s'en sort plutot bien quand même
si on avait le temps on définirait aussi des taux de remplissage au mieux, on ferait de l'administration sur mesure pour chaque client en fonction de son utilisation et plein d'autres choses qui paraissent logiques pour un dba à plein temps, mais tout est affaire compromis

Ha chapeau on redémarre parce que personne ne sait quoi faire !

certes
mais 9 fois sur 10 ca remet tout d'aplomb
et il y a la théorie des écoles et la pratique en entreprise
une entreprise doit faire de l'argent, pas des trucs parfaits, donc sur du SAV vous n'avez jamais quelqu'un de pointu dans tous les domaines, donc le but c'est d'agir rapidement pour que ca reparte, et après on regarde, et si on ne trouve pas c'est sur la 2ème occurrence du problème qu'on étudie à chaud

après on préfèrerait surement tous un monde meilleur où on a le temps et le budget de tout faire au mieux

Prévoyez un incrément beaucoup plus, modeste (25 M0 par exemple)

en fait je me disais qu'un grow trop petit serait pas génial pour la fragmentation du mdf, mais au final ca ne doit pas changer grand chose vu que ce sont des pages qui sont gérées
là j'ai peut être mal prévu oui

bref, je m'étend un peu, mais merci pour la réponse précise