Discussion :

[shamouda]

Bonjour a tous,

J'ai une base de donnees sous SQL Server 2005, et depuis quelques jours, je fais face a un immense probleme depuis l'execution d'un "Maintenance Plan" etabli par un consultant pour notre base de donnees.

La "Maintenance Plan" inclut les taches suivantes:
- Check DB Integrity
- Rebuild indexes
- Maintenance Clean-up

Apres son execution, la taille de la base de donnees est passee de 45 Go a 500 Go !!!

Quelqu'un aurait-il une idee sur ce qui a pu se passer? Ceci represente un probleme de performance immense pour nous.

Merci pour votre aide.

-- Selma.

[mikedavem]

Bonjour,

Au vu de votre plan de maintenance, il y a de très forte chance que l'opération de reconstruction d'index soit à l'origine de votre problème.
Vérifiez la taille du fichier journal de votre base. Il a dû en principe grossir.

La tâche de reconstruction d'index des plans de maintenance enregistre toutes les opérations pour l'ensemble des index de votre base sans tenir compte de leur fragmentation. Ils ont leur limite.

Quel est le mode de récupération de votre base ? Avez vous une tâche de sauvegarde des journaux de votre base ?

Une solution consiste à créer un script personnalisé de maintenance de vos index qui réorganise vos index et met à jour les statistiques pour une fragmentation > 10 % et < 30 % et reconstruit les index pour une fragmentation de > 30 %. Ainsi seul les index vraiment fragmentés seront pris en compte et vous éviterez une journalisation excessive.

Vous pouvez également augmenter les performances de votre tâche en utilisant l'option SORT_IN_TEMPDB si votre base tempdb se situe sur un axe disque différent de vos fichiers de bases de données. Il faudra, au préalable, dimensionner correctement celle-ci.

++

[SQLpro]

Vous pouvez aussi temporairement passer au mode de journalisation BULK LOGGED le temps de cette maintenance :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER DATABASE MaBase SET RECOVERY BULK LOGGED

puis revenir au mode FULL.
En effet dans le mode BULK LOGGED, les données détaillées de reconstruction des index ne sont pas journalisées, ce qui minimise le volume du JT.

A +

[shamouda]

Bonjour,

Je vous remercie pour vos reponses.

J'ai execute le script pour la reconstruction des indexes et la defragmentation de la base de donnees que vous m'avez indique, mais la taille de ma base de donnees est toujours la meme.

Ce probleme est entrain d'affecter les performances de notre systeme, il est vraiment urgent de le regler.

Toutes vos idees sont les bienvenues.

Merci par avance,

- Selma.

[mikedavem]

- J'ai execute le script pour la reconstruction des indexes et la defragmentation de la base de donnees que vous m'avez indique, mais la taille de ma base de donnees est toujours la meme.

Avez vous réduit la taille de vos fichiers journaux à une taille raisonnable dans un premier temps ?

++

[shamouda]

La taille des fichiers journaux n'est pas tres importante (800 Mo)

[mikedavem]

Que donne la requête suivante dans le contexte de votre base de données :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
USE <maBase>;
GO
 
SELECT 
	physical_name,
	size * 8. / 1024 AS size_in_mb,
	FILEPROPERTY(name, 'SpaceUsed') * 8. / 1024 AS space_used_mb
FROM sys.database_files;

++

[shamouda]

Apres execution de la requete ci-dessus, voici le resultat:

Physical_name: MyDB.mdf
Size_in_mb: 42797.25
Space_used: 42793.94

Physical_name: MyDB_log.ldf
Size_in_mb: 816.5
Space_used: 29.88

[mikedavem]

Etes vous sûr que votre base fasse encore 500 Go ?

D'après ce que je lis votre fichier de données fait 42 Go et le journal 816 Mo

++

[shamouda]

J'ai oublie un zero, toutes mes excuses !

la base de donnees: 420797.25
Espace utilise: 420793.94