Bonjour à tous.... je me retrouve aujourd'hui avec un énorme problème....
j'ai un Transaction Log qui est aujourd'hui d'une grosseur de plus de 3
Gigs..... et je ne sais pas quoi faire avec ca.... quelqu'un peut
m'expliquer a quoi sert ces Transaction Log.... et comment faire pour en
réduire la grosseur et pour ne plus que ce problème ne surviennent....
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jerome BERTHAUD
Bonjour,
Le journal de transaction enregistre toutes les modifications effectuées sur les données. Le journal sert dans les cas suivants : - annuler une modification de données en cours lorsque la transaction est active. - restaurer l'etat de la base de données jusqu'à un instant T - conserver les transactions à répliquer quand la réplication est active.
Sa taille et son utilisation dépendent du model de recovery utilisé : - Simple - bulk logged - full attention en changeant d'un mode à l'autrre à la perte des informations du journal.
Tant que la base de données n'a jamais été sauvegardée (backup complet), sa taille n'augmente pas. Ensuite, toutes les transactions effectuées sur les données sont conservées jusqu'à ce qu'elles soient sauvegardées physiquement. Le seul moyen d'éviter un accroissement de la taille du fichier est sa sauvegarde. Après la sauvegarde, l'espace occupé par les transactions peut être recyclé (voir plus loin comment les perdre). Pour sauvegarder les transactions, utilser l'instruction BACKUP LOG. Elle est indépendante de l'instruction BACKUP DATABASE. Dans les options, vous trouverez WITH TRUNCATE ONLY. Dans ce cas, aucun device n'est nécéssaire mais toutes les transactions sont perdues. Le fait de passer le recovery model à simple va également avoir pour conséquence de perdre les informations du journal de transaction.
un DBCC SRINKFILE permettra ensuite de diminuer lal taille du fichier.
Les infos ci-dessus doivent être complétées par ma lecture du BOL pour connaitre exactement le fonctionnement du journal. Chercher : - Truncating the Transaction Log - Checkpoint
Jerome BERTHAUD MCSD, MCT http://www.winsight.fr
"Gators" wrote in message news:uXJhT#
Bonjour à tous.... je me retrouve aujourd'hui avec un énorme problème....
j'ai un Transaction Log qui est aujourd'hui d'une grosseur de plus de 3 Gigs..... et je ne sais pas quoi faire avec ca.... quelqu'un peut m'expliquer a quoi sert ces Transaction Log.... et comment faire pour en réduire la grosseur et pour ne plus que ce problème ne surviennent....
merci énormément de votre aide....
DL
Bonjour,
Le journal de transaction enregistre toutes les modifications effectuées sur
les données.
Le journal sert dans les cas suivants :
- annuler une modification de données en cours lorsque la transaction est
active.
- restaurer l'etat de la base de données jusqu'à un instant T
- conserver les transactions à répliquer quand la réplication est active.
Sa taille et son utilisation dépendent du model de recovery utilisé :
- Simple
- bulk logged
- full
attention en changeant d'un mode à l'autrre à la perte des informations du
journal.
Tant que la base de données n'a jamais été sauvegardée (backup complet), sa
taille n'augmente pas.
Ensuite, toutes les transactions effectuées sur les données sont conservées
jusqu'à ce qu'elles soient sauvegardées physiquement. Le seul moyen d'éviter
un accroissement de la taille du fichier est sa sauvegarde. Après la
sauvegarde, l'espace occupé par les transactions peut être recyclé (voir
plus loin comment les perdre).
Pour sauvegarder les transactions, utilser l'instruction BACKUP LOG. Elle
est indépendante de l'instruction BACKUP DATABASE. Dans les options, vous
trouverez WITH TRUNCATE ONLY. Dans ce cas, aucun device n'est nécéssaire
mais toutes les transactions sont perdues.
Le fait de passer le recovery model à simple va également avoir pour
conséquence de perdre les informations du journal de transaction.
un DBCC SRINKFILE permettra ensuite de diminuer lal taille du fichier.
Les infos ci-dessus doivent être complétées par ma lecture du BOL pour
connaitre exactement le fonctionnement du journal.
Chercher :
- Truncating the Transaction Log
- Checkpoint
Jerome BERTHAUD MCSD, MCT
http://www.winsight.fr
"Gators" <dany.larouche@videotron.ca> wrote in message
news:uXJhT#WVEHA.2520@TK2MSFTNGP12.phx.gbl...
Bonjour à tous.... je me retrouve aujourd'hui avec un énorme problème....
j'ai un Transaction Log qui est aujourd'hui d'une grosseur de plus de 3
Gigs..... et je ne sais pas quoi faire avec ca.... quelqu'un peut
m'expliquer a quoi sert ces Transaction Log.... et comment faire pour en
réduire la grosseur et pour ne plus que ce problème ne surviennent....
Le journal de transaction enregistre toutes les modifications effectuées sur les données. Le journal sert dans les cas suivants : - annuler une modification de données en cours lorsque la transaction est active. - restaurer l'etat de la base de données jusqu'à un instant T - conserver les transactions à répliquer quand la réplication est active.
Sa taille et son utilisation dépendent du model de recovery utilisé : - Simple - bulk logged - full attention en changeant d'un mode à l'autrre à la perte des informations du journal.
Tant que la base de données n'a jamais été sauvegardée (backup complet), sa taille n'augmente pas. Ensuite, toutes les transactions effectuées sur les données sont conservées jusqu'à ce qu'elles soient sauvegardées physiquement. Le seul moyen d'éviter un accroissement de la taille du fichier est sa sauvegarde. Après la sauvegarde, l'espace occupé par les transactions peut être recyclé (voir plus loin comment les perdre). Pour sauvegarder les transactions, utilser l'instruction BACKUP LOG. Elle est indépendante de l'instruction BACKUP DATABASE. Dans les options, vous trouverez WITH TRUNCATE ONLY. Dans ce cas, aucun device n'est nécéssaire mais toutes les transactions sont perdues. Le fait de passer le recovery model à simple va également avoir pour conséquence de perdre les informations du journal de transaction.
un DBCC SRINKFILE permettra ensuite de diminuer lal taille du fichier.
Les infos ci-dessus doivent être complétées par ma lecture du BOL pour connaitre exactement le fonctionnement du journal. Chercher : - Truncating the Transaction Log - Checkpoint
Jerome BERTHAUD MCSD, MCT http://www.winsight.fr
"Gators" wrote in message news:uXJhT#
Bonjour à tous.... je me retrouve aujourd'hui avec un énorme problème....
j'ai un Transaction Log qui est aujourd'hui d'une grosseur de plus de 3 Gigs..... et je ne sais pas quoi faire avec ca.... quelqu'un peut m'expliquer a quoi sert ces Transaction Log.... et comment faire pour en réduire la grosseur et pour ne plus que ce problème ne surviennent....
merci énormément de votre aide....
DL
Jerome BERTHAUD
Bonjour,
Le journal de transaction enregistre toutes les modifications effectuées sur les données. Le journal sert dans les cas suivants : - annuler une modification de données en cours lorsque la transaction est active. - restaurer l'etat de la base de données jusqu'à un instant T - conserver les transactions à répliquer quand la réplication est active.
Sa taille et son utilisation dépendent du model de recovery utilisé : - Simple - bulk logged - full attention en changeant d'un mode à l'autrre à la perte des informations du journal.
Tant que la base de données n'a jamais été sauvegardée (backup complet), sa taille n'augmente pas. Ensuite, toutes les transactions effectuées sur les données sont conservées jusqu'à ce qu'elles soient sauvegardées physiquement. Le seul moyen d'éviter un accroissement de la taille du fichier est sa sauvegarde. Après la sauvegarde, l'espace occupé par les transactions peut être recyclé (voir plus loin comment les perdre). Pour sauvegarder les transactions, utilser l'instruction BACKUP LOG. Elle est indépendante de l'instruction BACKUP DATABASE. Dans les options, vous trouverez WITH TRUNCATE ONLY. Dans ce cas, aucun device n'est nécéssaire mais toutes les transactions sont perdues. Le fait de passer le recovery model à simple va également avoir pour conséquence de perdre les informations du journal de transaction.
un DBCC SRINKFILE permettra ensuite de diminuer lal taille du fichier.
Les infos ci-dessus doivent être complétées par ma lecture du BOL pour connaitre exactement le fonctionnement du journal. Chercher : - Truncating the Transaction Log - Checkpoint
Jerome BERTHAUD MCSD, MCT http://www.winsight.fr
"Gators" wrote in message news:uXJhT#
Bonjour à tous.... je me retrouve aujourd'hui avec un énorme problème....
j'ai un Transaction Log qui est aujourd'hui d'une grosseur de plus de 3 Gigs..... et je ne sais pas quoi faire avec ca.... quelqu'un peut m'expliquer a quoi sert ces Transaction Log.... et comment faire pour en réduire la grosseur et pour ne plus que ce problème ne surviennent....
merci énormément de votre aide....
DL
Bonjour,
Le journal de transaction enregistre toutes les modifications effectuées sur
les données.
Le journal sert dans les cas suivants :
- annuler une modification de données en cours lorsque la transaction est
active.
- restaurer l'etat de la base de données jusqu'à un instant T
- conserver les transactions à répliquer quand la réplication est active.
Sa taille et son utilisation dépendent du model de recovery utilisé :
- Simple
- bulk logged
- full
attention en changeant d'un mode à l'autrre à la perte des informations du
journal.
Tant que la base de données n'a jamais été sauvegardée (backup complet), sa
taille n'augmente pas.
Ensuite, toutes les transactions effectuées sur les données sont conservées
jusqu'à ce qu'elles soient sauvegardées physiquement. Le seul moyen d'éviter
un accroissement de la taille du fichier est sa sauvegarde. Après la
sauvegarde, l'espace occupé par les transactions peut être recyclé (voir
plus loin comment les perdre).
Pour sauvegarder les transactions, utilser l'instruction BACKUP LOG. Elle
est indépendante de l'instruction BACKUP DATABASE. Dans les options, vous
trouverez WITH TRUNCATE ONLY. Dans ce cas, aucun device n'est nécéssaire
mais toutes les transactions sont perdues.
Le fait de passer le recovery model à simple va également avoir pour
conséquence de perdre les informations du journal de transaction.
un DBCC SRINKFILE permettra ensuite de diminuer lal taille du fichier.
Les infos ci-dessus doivent être complétées par ma lecture du BOL pour
connaitre exactement le fonctionnement du journal.
Chercher :
- Truncating the Transaction Log
- Checkpoint
Jerome BERTHAUD MCSD, MCT
http://www.winsight.fr
"Gators" <dany.larouche@videotron.ca> wrote in message
news:uXJhT#WVEHA.2520@TK2MSFTNGP12.phx.gbl...
Bonjour à tous.... je me retrouve aujourd'hui avec un énorme problème....
j'ai un Transaction Log qui est aujourd'hui d'une grosseur de plus de 3
Gigs..... et je ne sais pas quoi faire avec ca.... quelqu'un peut
m'expliquer a quoi sert ces Transaction Log.... et comment faire pour en
réduire la grosseur et pour ne plus que ce problème ne surviennent....
Le journal de transaction enregistre toutes les modifications effectuées sur les données. Le journal sert dans les cas suivants : - annuler une modification de données en cours lorsque la transaction est active. - restaurer l'etat de la base de données jusqu'à un instant T - conserver les transactions à répliquer quand la réplication est active.
Sa taille et son utilisation dépendent du model de recovery utilisé : - Simple - bulk logged - full attention en changeant d'un mode à l'autrre à la perte des informations du journal.
Tant que la base de données n'a jamais été sauvegardée (backup complet), sa taille n'augmente pas. Ensuite, toutes les transactions effectuées sur les données sont conservées jusqu'à ce qu'elles soient sauvegardées physiquement. Le seul moyen d'éviter un accroissement de la taille du fichier est sa sauvegarde. Après la sauvegarde, l'espace occupé par les transactions peut être recyclé (voir plus loin comment les perdre). Pour sauvegarder les transactions, utilser l'instruction BACKUP LOG. Elle est indépendante de l'instruction BACKUP DATABASE. Dans les options, vous trouverez WITH TRUNCATE ONLY. Dans ce cas, aucun device n'est nécéssaire mais toutes les transactions sont perdues. Le fait de passer le recovery model à simple va également avoir pour conséquence de perdre les informations du journal de transaction.
un DBCC SRINKFILE permettra ensuite de diminuer lal taille du fichier.
Les infos ci-dessus doivent être complétées par ma lecture du BOL pour connaitre exactement le fonctionnement du journal. Chercher : - Truncating the Transaction Log - Checkpoint
Jerome BERTHAUD MCSD, MCT http://www.winsight.fr
"Gators" wrote in message news:uXJhT#
Bonjour à tous.... je me retrouve aujourd'hui avec un énorme problème....
j'ai un Transaction Log qui est aujourd'hui d'une grosseur de plus de 3 Gigs..... et je ne sais pas quoi faire avec ca.... quelqu'un peut m'expliquer a quoi sert ces Transaction Log.... et comment faire pour en réduire la grosseur et pour ne plus que ce problème ne surviennent....
