Discussion :

[gilbert42]

Bonjour,

depuis quelques temps nous subissons périodiquement sur notre serveur de grosse lenteur.
En effet cela concerne la journée du lundi matin (alors que nous devrions être en situation Light après le week-end).

Après analyse je constate tous les lundis matins dans les traces de SQLSERVER PROFILER qu'un autoshrink se fait sur une grosse base et qu'il dure plus de 06:00 (option de la base de données à "true") et passe dans la matinée du lundi.

A votre avis, est-ce une bonne piste ?
pour exemple un job appelant des package SSIS qui tourne en 40 minutes habituellement, contre plus de 06:00 le lundi matin.

Je vais faire le test pour lundi matin. Pour désactiver cette option autoshrink, je le positionne à false dans propriété et option, cela suffit il ? vous confirmez ??

Autre question, l'autoshrink se déclenche après quels évènements ?

De plus cette database à un auto grow à 1 mega, n'est-ce pas trop peu ?

Merci pour votre aide

si j'ai des réponses avant lundi, cela serait très sympa.

Gilbert

[jero44]

Bonjour,
Oui l'option AUTO_SHRINK peut être extrêment gourmande en terme de temps de traitement et c'est pourquoi il souvent préférable de désactiver cette option.Plus d'info sur : http://blogs.msdn.com/sqlserverstora...hrink-off.aspx
De même si vos fichiers sont en accroissement automatique, il est préférable de faire des pas un peu plus gros.

De plus compte tenu des symptômes, il y a des chances que la taille de votre base se "stabilise" car elle grossit au cours de la semaine puis elle est réduite pendant le W.E.

Dans tous les cas si vous souhaitez réduire la taille des fichiers préférez les instrcuctions DBCC SHRINKDATABASE et DBCC SHRINKFILE, par exemple dans un travail avec une date d'exécution planifiée.

[dily0403]

Bonjour,

Je confirme les dires de jero44 :
- Les opérations de "autoshrink" et "autogrow" sont très gourmandes en ressources CPU/HDD.
- Désactiver l'option "Autoshrink"
- Adapter la taille des "autogrow"

Aussi, il est préférable de laisser de l'espace libre dans les datafiles et logfiles de façon adéquate et d'utiliser DBCC SHRINKFILE ou DBCC SHRINKDATABASE sous contrôle , ceci afin d'éviter que SQL Server passe son temps à faire du yoyo avec ces différents fichiers...

L'idéale serait même de déterminer le cycle quotidien et hebdomadaire de ces différents fichiers afin de lui appliquer une politique de gestion appropriée...

David.

[elsuket]

Bonjour,

Les opérations de rétrécissement de fichiers doivent être réservées aux cas d'urgence, c'est à dire par manque d'espace disque.

En plus d'être gourmandes en ressources CPU et disque, vous supprimez des pages de la base de données que SQL Server a laissées vides pour s'en servir lors de futures insertions.

Dès lors que vous rétrécissez la taille d'une base de données, SQL Server est donc obligé, à chaque fois que cela est nécessaire, d'allouer des pages sur le disque, 1000 fois plus lent qu'un accès en RAM, alors qu'elles y étaient déjà !
Je vous laisse imaginer l'impact que cela peut avoir sur les performances de vos requêtes.

Le mieux reste donc de bien évaluer (je vous accorde que ce n'est pas simple) la taille d'exploitation de vos fichiers de base de données (données + journal de transactions), en prenant en plus une marge, et de les laisser vos fichier en AUTO_GROW.
Veillez à ne pas mettre un pas de grossissement de vos fichiers trop élevé, sans quoi le temps que celui-ci s'opère peut être long, et pourrir encore les performances de vos requêtes

@++