Discussion :

[hmira]

Je voudrais avoir votre avis sur la démarche suivante concernant les fichiers de données (je n’évoque pas les fichiers de log, pas pour le moment dans ce post !) :

1 - Prévoir pour les fichiers de données une taille initiale qui permet les 6 mois (ou un an) à venir d’exploitation, et ce afin d’éviter autant que possible les événements "Data File Auto Grow" (croissance du fichier de données)
Remarque : Cette étape ne fera pas partie du plan de maintenance. Il s’agit d’une étape "manuelle" : estimation de la taille initiale au moment de l’installation.

2 – En plus de phase 1 ci-dessus, Prévoir cette fois-ci dans le plan de maintenance une étape T-SQL qui fait en sorte que, en tout état de cause (exemple mauvaise estimation de la taille initiale etc..), l’espace libre des fichiers de données ne puisse pas descendre en dessous de 20%. Lorsque l’espace libre est inférieur à 20%, l’étape procédera à une augmentation de la taille du fichier de données pour assurer un minimum de 20% d’espace libre dans le fichier de données.

Que pensez-vous de cette démarche ? Pensez-vous qu’elle peut être envisageable ? Pensez-vous qu’elle peut même être dangereuse ! Peut-on faire mieux ?

Merci d’avance pour vos réponses.

A+

Hamid MIRA

[SQLpro]

1 - Prévoir pour les fichiers de données une taille initiale qui permet les 6 mois (ou un an) à venir d’exploitation, et ce afin d’éviter autant que possible les événements "Data File Auto Grow" (croissance du fichier de données)

En général on prévoit ceci sur la durée de vie du serveur donc 3 à 5 ans. Cependant, comme les calculs d'estimation de taille peuvent être battus en brèche, ne pas hésiter à prévoir une porte de sortie honorable (incrément par pas relativement important, de l'ordre de 10 à 50 Mo

2 – En plus de phase 1 ci-dessus, Prévoir cette fois-ci dans le plan de maintenance une étape T-SQL qui fait en sorte que, en tout état de cause (exemple mauvaise estimation de la taille initiale etc..), l’espace libre des fichiers de données ne puisse pas descendre en dessous de 20%. Lorsque l’espace libre est inférieur à 20%, l’étape procédera à une augmentation de la taille du fichier de données pour assurer un minimum de 20% d’espace libre dans le fichier de données.

Pas bon, vous allez fragmenter votre fichier, ce qu'il faut éviter...

Que pensez-vous de cette démarche ? Pensez-vous qu’elle peut être envisageable ? Pensez-vous qu’elle peut même être dangereuse ! Peut-on faire mieux ?

Pourquoi prévoir si large ? parce que SQL Server taille ses fichiers en tenant compte des plateaux des disques physiques.... Si vous prévoyez trop juste vous allez avoir un entrelacement des "cylindres"...

A +

[hmira]

Merci beaucoup SQLPro pour vos réponses éclairées.

Donc si je comprends bien, il ne faut jamais dans le plan de maintenance procéder à une augmentation du fichier de données. Mon idée était de procéder le cas échéant à une augmentation du fichier de données en dehors des heures de production, puisque le plan de maintenance de déroule la nuit, et éviter ainsi les éventuels autogrows

Pourquoi, l’augmentation de la taille du fichier de données générerait une fragmentation des fichiers à moins que cette opération est accompagnée systématiquement par des déplacements de données et au quel cas je peux le comprendre, une sorte de fragmentation externe (?).

Encore une fois, Merci,

A+

[SQLpro]

Il ne déplace pas les données, mais comme déjà dit : " parce que SQL Server taille ses fichiers en tenant compte des plateaux des disques physiques...." dans ce cas chaque rajout n'est pas lié en continuité avec le précédent, d’où fragmentation !

A +

[hmira]

Merci beaucoup pour ce complément d’information.
Je me suis rapidement renseigné sur la structure interne des disques durs (plateaux, têtes de lectures) (ce n’est pas du tout ma spécialité !) et maintenant je comprends et je réalise un peu mieux les enjeux et la nature de la fragmentation dont vous parlez.

J’avoue que, jusqu’à présent, personnellement, je ne me suis jamais préoccupé de ces aspects "matériels", physiques des disques durs etc.., et qui manifestement, ont une importance notoire.

Je vais donc suivre vos conseils à savoir :
- Prévoir une taille initiale des fichiers de données pour une durée d’exploitation de 3 ans
- Définir un incrément de 16 Mo (au cas où .. )
Et je surveillerais de près l’évolution de la taille des fichiers de données …

Merci et A+,

[SQLpro]

Pas mal, ça, ça me va bien !

A +