Bonjour,
J'ai actuellement un gros problème sous MSSQL server 2005 : les fichiers de logs (journaux de transactions *.ldf) saturent le disque dur du serveur et je ne sais pas comment faire pour les "vider". J'ai des fichiers de 10 à 30 Go!!!   J'ai essayé avec un plan de maintenance pour faire une sauvegarde complète de toutes les BD, mais ça plante en plein milieu J'ai trouvé ce tuto http://sqlpro.developpez.com/cours/sqlserver/log/ mais c'est pas pour MSSQL 2005 et j'ai peur de faire une connerie, je maîtrise pas du tout ce type de sqbd...
 
J'ai essayé aussi avec le menu "tâche" -> "réduire" -> base de données mais rien n'y fait non plu...
 
Y'aurait qq'un qui pourrait m'aider, svp?
 
Merci par avance, car la, ça craint...

Bon, j'ai finalement trouvé une solution Pour chaque table yant un gros log :
1) dans les propriétés, la passer en mode de récupération "simple",
2) après, menu contextuel "Taches" -> réduire -> base de données. Là, le log est vidé
3) repasser le mode de récup à "complet"
4) pour pas que ça se reproduire, dans les propriétés, "Fichiers" -> pour le log, dans le colonne "croissance automatique", mettre la croissance en mégaoctets (genre 10 Mo) et limiter la croissance à 200 Mo (par ex).

D'abord, est-ce que tu as besoin d'etre cappable de faire un point in time restore ou est-ce qu'un restore depuis le dernier backup est suffisant?
 
Si tu n'as pas besoin du point in time restore, tu changes le recovery model de ta DB de FULL en SIMPLE (Properties -> Options -> Recovery model).
Si tu veux garder la possiblité de faire un point in time restore tu dois faire des backup du Log (BACKUP LOG dbName TO ... ).
Soit tu fais des backup log toutes les heures (si c'est suffisant) ou tu ponds un script qui fait un backup log quand ton log atteint une certaine taille.
 
Pour te sortir de ton probleme la tout de suite, tu peux mettre ta DB en simple recovery, faire un shrink du log, la remettre en FULL recovery et faire un backup complet de la DB.
 
Si tu fais un backup log suffisement souvent, la taille du log n'augmentera pas (il ne reduit pas la taille automatiquement pour des raisons de performance), si tu ne fais pas de backup log assez souvent il ne voudra pas que tu fasses un shrink, car il n'y a pas vraiment d'espace non utilisé dans ton log.
 
Ton log peut aussi grossir tres fort si un utilisateur utilises des transactions tres importante.
 
Si tu veux savoir pourquoi un shrink ne marche pas sur ton log tu peux faire ca:

SELECT * FROM sys.DATABASES

Tu trouves la lignes correspondant a ta DB et tu regardes la colonne Log_reuse_wait_desc:
 si c'est a NOTHING, tu devrais pouvoir faire un shrink sans problemes
 si c'est a ACTIVE_TRANSACTION ca veut dire qu'un utilisateur est en train de remplir ton log avec une grosse transaction
 si c'est a LOG_BACKUP ca veut dire qu'il attend un backup du log
 ca peut aussi etre a CHECKPOINT, dans ce cas la tu fais un checkpoint toi meme, ou tu attends un peu que le server le fasse tout seul.

Merci pour ton aide mais comme j'ai jamais eu de formation même minimal sur MsSql, ta "procédure" n'est pas encore assez détaillée pour que je m'en sorte avec. Mais bon, j'ai résolu mon pb et je pense que ce que j'ai fait ressemble pas mal à ta solution (dans le principe).

Oui en gros t'as fait ce qu'il fallait, mais prends toujours un backup de ta DB apres l'avoir fait passer de FULL -> SIMPLE -> FULL, ou mieux, laisse la en SIMPLE (ca n'affecte que ta cappacité de faire des restore point in time).

 
1) pourquoi? et que ce passe t-il si on le fait (ou que risque t-on)?
2) comment on fait?

Le plus facil c'est de faire click droit -> Task -> Backup...
Ou alors BACKUP DATABASE MyDB TO DISK = 'E:\MonBackup'
 
Le but de garder la DB en FULL recovery est de pouvoir utiliser le transaction log apres un restore (point in time restore).
Si il y a un probleme (mauvaise manipulation de la part du business, crash server, etc ...) tu peux restorer le dernier backup complet, puis restorer tout les transaction logs et lui dire de s'arreter 1 sec avant le probleme (si tu as l'heure exacte), comme ca tu te retrouves avec une DB dans l'etat dans la quelle elle etait juste avant le probleme par contre si tu es en SIMPLE recovery tu ne peux recuperer tes données qu'avec un backup complet, donc tu perds tout depuis le dernier backup (ce qui est acceptable dans la plus part des cas).
 
Pour que ca marche il faut que la sequence des logs soit continue, donc quand tu fais un backup complet, tu dois avoir tout les backup logs qui suivent. Quand tu fais passer la DB en FULL -> SIMPLE -> FULL la sequence est cassée et tu ne peux plus réutiliser les eventuel backup log que tu fais apres ca, c'est pour ca qu'il faut prendre un backup complet, pour recommencer la sequence.
 
Si tu n'as pas besoin de pouvoir faire un point in time restore je te conseille de laisser ta DB en SIMPLE recovery, ca t'evitera de devoir gerer les backup logs en plus des backups normaux.

Ok, merci pour ces précisions