Discussion :

[basticx35]

Bonjour,

Je sais que ce sujet à déjà été abordé, mais je ne trouve pas de solution immediate.
Environnement : Windows 2003 / SQL Server 2005
Mon plan de maintenance a échoué cette nuit, le shrinkfile du fichier log ne s'est pas réalisé, et ce matin il atteint 40 Go.

Je lance manuellement
Use master
backup log mabase with truncate_only
use mabase
dbcc shrinkfile (mabase_log, 1024)

et j'obtiens
Impossible de compacter le fichier journal 2 (RFXLEROYPROD_log), car tous les fichiers journaux logiques sont utilisés.

Je lance ensuite (pour vérifier si des transactions sont en cours - requête trouvé sur le forum)
select log_reuse_wait_desc from sys.databases where name = 'mabase'
Resultat :
ACTIVE_TRANSACTION

Mais ensuite je ne sais pas quoi faire. La dernière fois que j'ai eu ce problème j'ai été obligé d'arrêter sql serveur, et au lancement de sql, une reconstruction / vérification se lance. Le problème est que cette manip me parait un peu barbare et m'oblige à arrêter ma prod.

[mikedavem]

Utilisez la commande DBCC OPENTRAN pour voir quelle transaction est en cours.

++

[basticx35]

J'avais également lancé cette commande,

Informations de transaction pour la base de données 'mabase'.

Plus ancienne transaction active*:
SPID (ID du processus serveur) : 232
UID (ID utilisateur)*: -1
Nom : user_transaction
Numéro de séquence d'enregistrement : (3340886:18520:1)
Heure de début*: févr 18 2010 12:27:31:983PM
SID : 0xb869d51985743a479e8ce238f63e019c
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur système.

Par contre je ne sais pas trop quoi faire de tout ça. Je suis aller dans le moniteur d'activité, je retrouve bien mon SPID 232 (information sur les processus / verrous par objet).

[mikedavem]

Si vous êtes dans le moniteur d'activité vous pouvez éventuellement voir la requête associée à la session en cause.

Si vous estimez que vous pouvez la tuer il suffit d'utiliser la commande KILL <spid>

Vous pourrez tenter à nouveau de réduire votre fichier journal.

++

[basticx35]

Ok Merci pour votre aide. J'ai lancé Kill <spid> et relancé dbcc opentran (résultat nothing).

J'ai relancé le shrinkfile du fichier de transaction et je n'ai pas rencontré de blocage.