Discussion :

[Vyns1520]

Bonjour,

Mon client se plaint de performances de moins en moins bonnes, je souhaiterais donc effectuer des opérations de maintenance à fréquence régulière, comme par exemple une reconstruction des index ou bien une compression/réduction (SHRINK). Pour information, la base de données concernée est composée d'un seul fichier MDF (actuellement 44 Go avec un espace libre disponible de 10%) et d'un fichier LDF (actuellement 10 Mo avec un espace libre disponible de 92%).

Avez-vous des conseils à me donner à ce sujet ?
Par exemple pour l'ordre des traitements, je dirais qu'il faut d'abord faire un SHRINK puis une reconstruction des index. Est-ce correct ?
De plus, j'ai lu beaucoup de posts qui déconseillaient d'utiliser SHRINK. Pour quelle raison ?

Merci d'avance pour vos réponses.
Vyns

[Donpi]

Bonjour, tout d'abord ce qui suit n'engage que moi.

Selon moi les opération de maintenance, même si elles sont indispensables, dans le cas des baisses de performance sont une fausse bonne idée.
Je regarderais d'abord du côté des statistiques d'indexes manquants ainsi que du coté de l'application pour trouver des pistes.

Le Shrink va libérer l'espace réservé par votre base de données. Mais il risque d'être aussi tôt re-réservé.
Globalement le Shrink est inutile sauf lors d'un traitement particulier qui a fait gonflé l'espace réservé inutilement.

Sinon pour répondre à la question, en fonction de la consommation d’espace disque je dimensionnerais la taille de la base une fois par semaine pour réserver l'espace a consommer dans les jours suivants.
En ensuite une réindexation.

A+

[Vyns1520]

Merci de votre réponse.

En fait, la base de données est utilisée depuis plus d'une dizaine d'années et je pense qu'aucun SHRINK n'a jamais été exécuté.
Nous avons récupéré le projet depuis 8-9 mois suite à un changement d'architecture.
Le serveur précédent était SQL2000 et des opérations de maintenance étaient planifiées (reconstruction des index de mémoire) alors que depuis la migration vers SQL2008R2, aucune opération de maintenance n'a été effectuée et je suppose que c'est pourquoi le client constate des pertes de performances...

Sur une base de tests (copie récente de la base de prod), j'ai procédé aujourd'hui à un SHRINK (une heure de traitement et passage de 44Go à 36Go) + reconstruction des index (6 heures de traitement) et j'ai programmé ces mêmes opérations pour cette nuit. Je vous tiens au courant...

[Invité]

Le shrink c'est le mal absolu : Y a pas mieux pour fragmenter les indexes !
Et si tu veux les recréer juste après, ça revient pas mal à faire une chose et son contraire.

Je te renvoie à cette note de SQLPro : http://www.developpez.net/forums/d14...s/#post7797262
et à son article : http://blog.developpez.com/sqlpro/p5..._fichiers_et_t

[Vyns1520]

OK, merci, cela devient plus clair.

Je pense donc que :
- je vais laisser tomber le SHRINK à fréquence régulière
- je vais quand même faire un SHRINK unitaire pour récupérer 8 Go d'espace disque et on verra comment l'espace libre disponible va évoluer ; je pense qu'il va forcément augmenter car l'application associée fait régulièrement des "DELETE before INSERT", ce qui devrait, sauf erreur, avoir tendance à fragmenter les index...
- je vais en revanche planifier des reconstruction d'index à fréquence régulière

Après avoir lu les différents articles rédigés par SQLPro, je me suis empressé de vérifier comment était configurée la croissance automatique et je me suis aperçu que le fichier MDF était paramétré avec une croissance par tranche de 1Mo !!! Je crois avoir compris que ce n'est vraiment pas l'idéal et j'ai donc modifié cette valeur pour la passer à 100 Mo...
En plus de cela, la réduction automatique "AUTO_SHRINK" était activée !!!! ET apparemment c'est très déconseillé !!!! Je viens donc de la désactiver mais j'ai peur que cela fasse grossir considérablement le fichier MDF ????

Pour résumer si je comprends bien, un bon paramétrage de la croissance automatique optimise les temps de réponse des écritures ; alors que la faible fragmentation des indexes améliore les temps de réponse des lectures. C'est bien cela ?

[Donpi]

Pour résumer si je comprends bien, un bon paramétrage de la croissance automatique optimise les temps de réponse des écritures ; alors que la faible fragmentation des indexes améliore les temps de réponse des lectures. C'est bien cela ?

Dans les grandes des lignes oui, mais ça ne suffit généralement pas pour réglé les problèmes de performances.
A+