Discussion :

[davy.g]

Bonjour,

J'ai plusieurs bases Sql server 2005 en mode de récupération simple.
Quelle est la meilleure méthode pour gérer une croissance conséquente des journaux de transaction ?

Merci.

[jero44]

bonjour,
vos journaux sont tronqués lors de chaque sauvgarde complète.
sinon vous pouvez prendre le risque (déconseillé) de simplement tronquer vos journaux de transaction à l'aide de

Code :

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

1
2
 
BACKUP LOG maBase WITH TRUNCATE_ONLY;

[davy.g]

bonjour,
vos journaux sont tronqués lors de chaque sauvgarde complète.
sinon vous pouvez prendre le risque (déconseillé) de simplement tronquer vos journaux de transaction à l'aide de

Code :

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

1
2
 
BACKUP LOG maBase WITH TRUNCATE_ONLY;

Non, mes journaux de transaction ne sont pas tronqués lors de mes sauvegardes : mes bases sont en mode de récupération simple.

[elsuket]

Exact, en mode de récupération simple, le journal est tronqué après chaque validation de transaction.
Il y a plusieurs causes qui peuvent être à l'origine d'un retard de troncature, qui sont exposés sous SQL Server 2005 par la colonne log_reuse_wait_desc de la vue système sys.databases. Qu'obtenez-vous ?

C'est en mode de récupération complète qu'il est nécessaire de sauvegarder le journal des transactions pour tronquer le journal

@++

[davy.g]

Exact, en mode de récupération simple, le journal est tronqué après chaque validation de transaction.
Il y a plusieurs causes qui peuvent être à l'origine d'un retard de troncature, qui sont exposés sous SQL Server 2005 par la colonne log_reuse_wait_desc de la vue système sys.databases. Qu'obtenez-vous ?

C'est en mode de récupération complète qu'il est nécessaire de sauvegarder le journal des transactions pour tronquer le journal

@++

J'ai la valeur "NOTHING" pour toutes mes bases de données utilisateurs.
Il y a eu de gros traitements qui ont tourné hier soir...
Comment expliquer cette montée de taille des journaux ?

[elsuket]

Il y a eu de gros traitements qui ont tourné hier soir...
Comment expliquer cette montée de taille des journaux ?

Lorsque vous exécutez une transaction, c'est à dire un SELECT, INSERT, UPDATE ou DELETE, SQL Server écrit dans le journal de transaction quelques informations plus les données qui ont été modifiées, de sorte qu'en cas de crash, il puisse refaire ou défaire une transaction qui n'aurait pas été validée.
C'est ce qui permet d'assurer que la base de données reste dans un état cohérent et consistant.

Donc lorsque vous faites des traitements qui entraînent une modification importante de données, SQL Server écrit beaucoup de données dans le journal de transaction.

Dans le mode de récupération simple, il attend la fin de la transaction pour tronquer le journal, donc aussi longtemps que la transaction doit durer, votre journal n'est pas tronqué (si vous faites un UPDATE de cent mille lignes, SQL Server écrit d'abord dans le journal de transactions les données correspondant à la mise à jour de ces cent mille lignes, puis effectue la mise à jour de la table)

Dès lors, si cela est nécessaire, le moteur de base de données fait grossir le journal des transaction s'il a été mal taillé (s'il avait été bien taillé au début, il n'aurait pas eu besoin de grossir, donc pas d'accès disque pour allouer des pages, donc un traitement plus rapide )

@++

[davy.g]

Lorsque vous exécutez une transaction, c'est à dire un SELECT, INSERT, UPDATE ou DELETE, SQL Server écrit dans le journal de transaction quelques informations plus les données qui ont été modifiées, de sorte qu'en cas de crash, il puisse refaire ou défaire une transaction qui n'aurait pas été validée.
C'est ce qui permet d'assurer que la base de données reste dans un état cohérent et consistant.

Donc lorsque vous faites des traitements qui entraînent une modification importante de données, SQL Server écrit beaucoup de données dans le journal de transaction.

Dans le mode de récupération simple, il attend la fin de la transaction pour tronquer le journal, donc aussi longtemps que la transaction doit durer, votre journal n'est pas tronqué (si vous faites un UPDATE de cent mille lignes, SQL Server écrit d'abord dans le journal de transactions les données correspondant à la mise à jour de ces cent mille lignes, puis effectue la mise à jour de la table)

Dès lors, si cela est nécessaire, le moteur de base de données fait grossir le journal des transaction s'il a été mal taillé (s'il avait été bien taillé au début, il n'aurait pas eu besoin de grossir, donc pas d'accès disque pour allouer des pages, donc un traitement plus rapide )

@++

OK, mais si la transaction est terminée et que le journal des transaction ne diminue pas, est-ce normal ?

[elsuket]

Non

Essayez DBCC OPENTRAN pour voir s'il existe encore des transaction ouvertes.

@++

[mikedavem]

Bonsoir,

Si vous avez eu des gros traitements et que votre journal des transactions a grossi, il est normal que celui-ci fasse toujours la même taille après ces traitements.

Comme l'explique Elsuket, avant de mettre à jour vos données, celui-ci écrit dans le journal. Si votre journal est mal dimensionné celui-ci va augmenter en taille. Une fois vos traitements terminées et vu que vous êtes en mode de récupération simple, après le prochain CHECKPOINT votre journal sera tronqué mais la taille sera toujours la même. Vous pouvez le voir avec un DBCC SQLPERF(LOGSPACE) qui vous indique la taille de votre journal et le % d'occupation de celui-ci (normalement le % sera proche de 0 de votre cas)

Pour diminuer la taille de votre journal il faut utiliser la commande DBCC SHRINKFILE.

++

[elsuket]

Pour diminuer la taille de votre journal il faut utiliser la commande DBCC SHRINKFILE.

A réserver toutefois à de la maintenance d'urgence

@++