Salut à tous,

je me retrouve avec un gros problème (c'est le cas de le dire) sous SQLServer 2005

J'ai une base de donnée totalement vierge (par rapport à l'appli qui la gère) qui ne devrait pas dépasser les 200 Mo or actuellement elle dépasse les 11 Go

En fouillant un peu, j'ai découvert que le journal de transaction à pour valeur initiale 10 Go, et qu'il fait effectivement plus de 10 Go.

Comment est-il possible de purger ce journal et de réduire sa taille ????
J'ai essayé avec la fonction de réduction de base, mais ça ne marche pas.

Je ne comprend pas pourquoi cette configuration a été appliquée. Habituellement, l'application qui gère cette base initialise la taille du journal à 1Mo

---- Sevyc64  (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #    [ Lien ]

Premièrement si ton journal des transaction est lourd, c'est qu'il y a beaucoup de transaction effectué et que la base de donnée est configurée pour un enregistrement de toutes les transactions (COMPLET).

Si une sauvegarde des transactions effectuées n'est pas nécessaire, peut etre faudrait-il passer la Bdd en SIMPLE!!

Pour réduire le journal des transaction faire une requète :

BACKUP LOG MaBase WITH TRUNCATE_ONLY

puis dans management studio compacté le fichier log de la Bdd.

Il y a peut-etre eu quelques tests de fait sur la base, mais c'est une base théoriquement vierge, elle n'a pas encore été mise en prod, donc le journal de transaction devrait quasiment vide.

Mais ce qui est étrange c'est que ce journal est configuré avec une taille initiale de 11Go. Je ne vois l'interet d'une telle chose (je ne maitrise pas la configuration, sur ce dossier, je ne suis que sous-traitant d'un prestataire, c'est bien là le problème).
Toutes les autres bases que je peux avoir chez d'autres clients, les journaux sont tous configurés avec une taille initiale de 1Mo et ça marche très bien.



J'essairais ta requette à l'ocasion, pour le moment j'ai été obligé de supprimer la base de mon poste, le disque était plein au point que SQLServer refusait même de démarer.



---- Sevyc64  (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #    [ Lien ]

Salut,

Principalement par souci de performance.
Ca évitera par exemple :
- d'avoir une fragmentation du fichier de log
- des requêtes qui échouent si l'agrandissement prend trop de temps
Et j'en oublie sans doute, n'étant pas expert dans le domaine.

Quelques informations sur le sujet : Considerations for the "autogrow" and "autoshrink" settings in SQL Server


/*
coq
MVP Visual C#
CoqBlog
*/