Discussion :

[pypik]

Bonjour,

Chez un client dont la taille du fichier MDF était de 800Gb un « auto-growth » de 10Gb était en place.
Lorsque le MDF a eu besoin de s'agrandir je m'attendais à voir un seul événement de type "auto-growth" d'une taille de 10Gb.

Or, en analysant les rapports et événements étendus, j’ai vu que deux événements d'accroissement ont eu lieu l’un à la suite de l’autre avec un session_id différent.
- l'un à 18:09:26 et d'une durée de 29s
- l'un à 18:09:53 et d'une durée de 27s
Du coup le MDF s'est vu accroitre de 20 Gb.



Comment expliquer cela ?

(1) Est-ce que réellement le process ou mouvement de data demandé pour déclencher l'évènement 1 aurait eu réellement besoin de plus de 10GB de libre ce qui me paraitrait plutôt surprenant, surtout que j'ai vu que l’espace libre du MDF était à environ 19GB une fois le "growth" fait.

(2) Est-ce que deux process « d'autogrowth » concurrents pourrait-être possible ? enfin ils n'ont pas l'air si concurrent que ça... juste très proches et du coup (1) expliquerait éventuellement cela ?

Merci d'avance pour vos réponses

[SQLpro]

Réponse 1...

Notez que l'accroissement de 10 Go est très dangereux ! En effet, le temps de faire cet accroissement atteint les 30 secondes qui est le timeout par défaut des applications. Si cette opération se reproduit et dépasse les 30 secondes, alors :
1) les demande de connexion sont rejetées
2) les nouvelles demandes de verrous sont rejetées et si une transaction explicite est en cours, alors elle est automatiquement rollbackée...

Réduisez l'autogrow à quelques Mo et si possible faite du préventif...

A lire sur le sujet : https://blog.developpez.com/sqlpro/p..._fichiers_et_t

[pypik]

@SQLpro Merci pour vos explications et vos recommandations. Je comprends tout à fait votre remarque par rapport au 30s.

Ce que je n'arrivais pas à comprendre c'est que dans le cas où un mouvement de données a provoqué l'événement 1, et aussi le 2eme dans la foulée, pourquoi une requête analysant l'espace libre du MDF après moins de 10min me donnait 19Gb... Je me serais attendu à voir quelque-chose comme un peu moins de 10GB expliquant pourquoi 2 évènements ont eu lieu.

Cela étant dit il est peut-être possible qu’entre le moment de l’évènement 2 et celui de ma capture d'espace libre du MDF, soit un peu moins de 10 min, des jobs/requêtes faisant du nettoyage de datas ont pu libérer entre temps un tel espace.

[SQLpro]

Le volume récupérable indiqué correspond à des pages de 8Ko dans des extensions de 8 pages contiguës soit 64 Ko. Depuis la version 2012 (à vérifier) les extensions étant uniforme, elles contiennent 8 pages du même objet (table ou index). Si une extension comporte une seule page occupée, les 7 autres vides, l'extension n'est pas récupérable.
En revanche, le calcul étant basé sur des pages, 7 pages vides représentent donc 56 Ko.
En sus, au cours des transactions d'écritures, les données nouvelles fragmentent les pages et les extensions. Cela est aussi pris en compte dans le calcul de l'espace vide dans une moindre mesure.
Pour aller vers les 19 Go, et en ne tenant compte que des extensions non totalement pleines, disons en moyenne à 50% soit 32 Ko, cela vaudrait dire que vous avez près de 30 000 objets ayant une queue de stockage...

Voila pourquoi je considère que l'enveloppe de stockage (les fichiers) d'une base de données devrait toujours avoir une taille d'environ 20 à 30 % de plus que la taille réelle des données stockées. Afin d'éviter toute opération de croissance pendant la production.

A +

[pypik]

Merci pour tous ces détails ! Je vais devoir lire plus de documentation sur ce sujet pour mieux en comprendre les subtilités.