Version imprimable
Bonjour,
Comment se fait-il que le fichier log, partant de 100Mo, arrive à 8Go en quelques minutes, alors que la base est en mode simple ? Certes plusieurs grosses requêtes sont lancées en même temps, mais SQL devrait plutôt utiliser Tempdb, non ?
J'avais cru (mal ?) comprendre que le log n'était plus utilisé en mode simple.
Merci.
surement transaction ouvert non commité
Code:dbcc opentran
Citation:
Envoyé par bimiman
Le journal de transaction est TOUJOURS utilisé quelque soit le mode. Sans journal de transaction, pas de transaction, donc pas d'insert/update/Delete...
Le mode SIMPLE minimise les entrées... Et purge en permanence. Comme le dit BOUBOU, si une transaction ouverte n'est pas refermée, alors ça bloque et il est impossible de purger !
A +
OK merci.
Toutefois avec un DBCC SHRINKFILE j'arrivais à réduire le fichier alors que les transactions n'étaient pas terminées.
Disons que le terme "journal" est un peu usurpé, normalement c'est un historique, dans le même sens que "journal des événements" de Windows.
Dans l'absolu c'est possible de gagner un peu d'espace si tu as des VLF du journal qui sont inactifs et pas utilisés dans une transaction ouverte.Citation:
Envoyé par bimiman
Mais généralement une transaction ouverte aura pour effet de remplir le journal donc utiliser tous les VLFs et les opérations de réduction de journal restent sans effet.
++
Pour compléter ce que dit David, et Frédéric ou David me reprendront si je fais erreur.
Un VLF se crée à chaque fois qu'il y a un agrandissement. Si on en voit beaucoup, l'idéal est que si on peut, on shrink le log et on augmente la taille d'un coup afin de réduire au maximum le nombre.
On commence à avoir des problèmes si on a plus de 200 VLF
On en parle ici
https://www.developpez.net/forums/d1...n/#post9142270
Pour connaitre le nombre de VLF sur une DB :
DBCC LOGINFO('maDB')
Si mes souvenirs sont bon, le VLF qui est en cours d'utilisation, il y a un 2 devant. (Je suis à la maison, je ne sais pas vérifier si ma mémoire est bonne).
Et donc quand tu fais un shrink, il va réduire jusqu'à ce VLF.
Pas du tout. Le journal de transaction est un fichier contenant des informations binaires de deux natures :Citation:
Envoyé par bimiman
1) les métadonnées de la transaction (verrous, objets modifiées...)
2) les images binaires avant nécessaires en cas d'annulation de la transaction
Vous pouvez avoir une idée du contenu en utilisant la fonction table
Qui rend un peu plus humainement lisible de journal de transaction...Code:SELECT * FROM sys.fn_dblog(NULL, NULL)
A +
Non... un agrandissement c'est juste l'incrément pas que vous avez décidé lors de la création du fichier. Les tailles des VLF sont fixées par un algorithme qui a changé avec la version 2014 je crois.... Autrefois fixe en fonction de la taille initiale, ils sont désormais de taille variable en fonction de la taille acquise en fonctionnement.Citation:
Envoyé par janlouk
A +Citation:
Si on en voit beaucoup, l'idéal est que si on peut, on shrink le log et on augmente la taille d'un coup afin de réduire au maximum le nombre.
On commence à avoir des problèmes si on a plus de 200 VLF
On en parle ici
https://www.developpez.net/forums/d1...n/#post9142270
Pour connaitre le nombre de VLF sur une DB :
DBCC LOGINFO('maDB')
Si mes souvenirs sont bon, le VLF qui est en cours d'utilisation, il y a un 2 devant. (Je suis à la maison, je ne sais pas vérifier si ma mémoire est bonne).
Et donc quand tu fais un shrink, il va réduire jusqu'à ce VLF.