Discussion :

[Depite]

Bonjour,

Je travaille sur un ensemble de bases de données SQL sur un serveur SQL 2008 R2.
Les postes clients utilisent soit Access 2010 (projets .ADP) soit des applications VB.net

Je constate que les fichiers .log de mes bases de données augmentent considérablement, en particulier une d'entre elles accédée essentiellement par des applications VB.net/ADODB.
Sur des versions plus anciennes de SQL server j'utilisais la command TRUNCATE LOG mais, à priori, cette commande n'existe plus. J'ai donc programmé une sauvegarde incrémentielle toues les heures sur les bases concernées mais malgré tout le fichier journal fait en moyenne 8 fois la taille du fichier de données (exemple: Data = 880 Mo, log = 6,8 Go)

Est-ce un comportement normal ?
Quelqu'un aurait-il de bons conseils à me donner pour atténuer ce gonflement ?

Je vais basculer prochainement sur un serveur SQL 2025 standard, y aura t-il de nouvelles possibilités concernant ce sujet ?

Merci pour vos conseils !

Bien cordialement.

[Rep.Movs]

Bonjour,
Le cas le plus fréquent pour ce problème, c'est d'être en mode de récupération 'complet'. Dans ce cas, le log ne se vide pas - et c'est maintenant le mode par défaut il me semble.
Ce mode bloque d'ailleurs le truncate log.

Il faut donc passer en mode de récuperation simple, faire un dbcc checkpount et une sauvegarde puis réduire les logs à une taille normale.

[Depite]

Merci Rep.Movs,
Je vais appliquer cette modification dès que possible

[elsuket]

Bonjour,

Sous le mode de récupération complet, vous devrez prendre des sauvegardes régulières du fichier du journal des transactions.
Celui-ci reflétant la vie de la base de données, si d'aventure vous deviez restaurer la base à une date et une heure bien précise (après un crash, la perte de disques, ou comme base de test, ou pour retrouver des données supprimées par accident), vous pourrez.
Si vous voulez placer votre base de données en haute disponibilité, vous n'aurez pas d'autre choix, puisque la réplication en temps réel se fait sur la base des transactions, et donc de son journal

Au contraire, si vous êtes en mode de récupération simple, vous ne pourrez compter que sur les sauvegardes complètes et différentielles (qui sont aussi nécessaires en mode de récupération complet).

Suivant l'usage de votre base de données, l'un ou l'autre des modes peut convenir.
Il faut donc le choisir correctement, et prévoir le stockage en conséquence.
Un plan de maintenance peut faire l'affaire.

Par ailleurs, SQL Server 2008 R2 a atteint sa fin de vie le 9 Juillet 2019, il vous faudrait considérer le passage à une version plus récente de SQL Server