Discussion :

[bimiman]

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.

[Boubou2020]

surement transaction ouvert non commité

Code :

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

dbcc opentran

[SQLpro]

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.

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 +

[bimiman]

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.

[mikedavem]

OK merci.
Toutefois avec un DBCC SHRINKFILE j'arrivais à réduire le fichier alors que les transactions n'étaient pas terminées.

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.
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.

++

[janlouk]

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.

[SQLpro]

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.

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.

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.

A +

[SQLpro]

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.

Pas du tout. Le journal de transaction est un fichier contenant des informations binaires de deux natures :
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

Code :

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

SELECT * FROM sys.fn_dblog(NULL, NULL)

Qui rend un peu plus humainement lisible de journal de transaction...

A +