Comment ne pas utilser le journal de transactions

Question

Bonjour,

J'alimente une base de données datawarehouse avec des fichiers externes.

La taile de la base est de 13 Go, elle est en mode recovery simple.

Lorsque je charge les fichiers, le journal des transactions augmente jusqu'à 31 Go.

Le mode d'alimentation est en annule et remplace, c'est à dire que dans une même transaction je supprime un ensemble de lignes puis j'insère un autre ensemble de lignes. Le volume traité est de plusieurs millions de lignes.

Ya t'il une solution pour que le journal soit moins volumineux ou encore mieux que le journal ne soit pas du tout utilisé (après l'alimentation une sauvegarde complète est effectuée donc en cas de problème je peux restaurer la base et exécuter l'alimentation avec le dernier jeu de fichier).

Merci d'avance pour votre aide

Answer 1

Bonjour,

Il n'est pas possible de "ne pas utilisé" dans SQL Server. Le mode de récupération simple ne veut pas dire que le journal n'est pas utilisé. On dit seulement qu'il ne permet pas de récupérer toutes les données de la base à partir du journal en rejouant les transactions, car il n'est pas ... complet.

En mode de récupération simple, un checkpoint va se produire lorsque le juornal est rempli à 70%. A ce moment là, les VLF de na partie inactive du journal sont de nouveau disponibles pour accueillir des données. Dans votre cas, la taille des transactions dépasse la taille initiale de votre journal, donc tant qu'une transaction n'est aps terminée, le checkpoint ne vas pas "libérer" de l'espace dans votre journal. N'oubliez pas non plus que la log stocke els images avant et après de vos enregistrements.

Sachant que vous faire un "annule et remplace", est-ce que vous faites un delete ? Un truncate ? Je vous suggère le truncate.

Pour votre import, essayez du mode bulk, cela vous permettra de consommer moins d'esapce dans votre journal.

Sinon, il vous faudra découper votre traitement en transactionplus petites de manière à ce que le checkpoint puisse réinitialiser les VLFs.

Cdlt,

Christophe

---

Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

Answer 2

Avant tout merci pour votre réponse.

je ne peux pas faire de truncate car j'annule et remplace seulement une partie des données sur un critère de dates.

J'utilise le bulk insert.

Avez-vous une idée de ce qui se passerait pour le journal si je ne fais pas du tout de transaction, c'est à dire pas de BEGIN TRANSACTION, ni de COMMIT/ROLLBACK?

Answer 3

Bonjour,

Même si vous n'incluez pas d'ordre explicite de transaction, SQL Server va traiter chaque requete comme une transaction.

Si vous ne pouvez pas faire de truncate, je vous sugère de travailelr avec les partitions et de faire un switch de vos donneés à supprimer dans une partition (une table) vide. Ainsi, la supression des données sera quasi immédiate et votre journal ne vas pas trop être impacté. Mais cela implique d'avior une édition entreprise.

Sinon, faites vos delete par paquet de 5000 ou de 10 000.

Christophe.

---

Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

Answer 4

Encore Merci pour vos suggestions.

Finalement, j'utilise la réduction des logs, que j'avais mise en oeuvre dans la phase de développement, après différentes étapes du traitement avec un DBCC SHRINKFILE(N'FichierLog' , 5000) dans la mesure ou l'exécution est rapide par rapport à la durée totale du traitement.

Cordialement

 

Answer 5

Bonjour,

Si vous voulez, mais je ne suis pas sur que cela soit une bonne solution. Shrinker un fichier de log est consommateur en ressources système, et, de plus, pas judicieux car lors de votre prochaine intégration le journal va devoir croitre à nouveau. Et l'augmentation de la taille du journal est suivie par une initialisation à zéro de l'espace ajouté. Avec blocage de toute activité pour la base. Votre import sera lent.

Mon conseil : laissez votre journal de transaction à sa taille de 30 ou 40 Gb, ce n'est pas plus problématique que cela, d'autant que vous être en mode de récupération simple.

Bonne journée

Christophe

---

Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM