pourquoi no_truncate?

Pour faire vite et court, oui en effet le journal de transaction est tronqué
lors d'une sauvegarde. Ceci a cours sauf si ta base est en modèle de
récupération simple ( ce qui correspond à l'activation de base de données
"trunc. log. on chkpt.").
En revanche, tout n'est pas purgé : seules les transactions terminées
(commitées ou annulées) le sont. Celles-qui sont en cours sont maintenues
bien entendues.
De là en découle par exemple l'estimation d'une fréquence correcte de
sauvegarde afin que ton log ne prenne pas une taille Gargantuesque.

Pour plus d'infos je t'invite vivement à te rapprocher de la doc en ligne
livrée avec Sql Server. Dans l'onglet index : backup log ---> Rubrique
"Architecture : Troncature du journal des transactions". C'est très bien
expliqué et tout y est détaillé.

Quant à l'option no_truncate, c'est une option qui permet de sauvegarder le
journal sans le purger, typiquement quand la base est endommagée.

J'espère avoir répondu à tes interrogations...

"vivi" a écrit :

bonjour

je debute en sql server et je cherche a comprendre le fonctionnement du
journal des transactions
1- quand je fais une sauvegarde exemple backup log mabase...
que se passe t-il est ce qu'il tronque les transactions exécutées? ou il
sauvegarde toutes les transactions effectuées et celles pas encore validées ?

2- si il ne tronque rien pourquoi alors preciser no_truncate?


merci

"Fred.M." wrote:

Pour faire vite et court, oui en effet le journal de transaction est tronqué
lors d'une sauvegarde. Ceci a cours sauf si ta base est en modèle de
récupération simple ( ce qui correspond à l'activation de base de données
"trunc. log. on chkpt.").
En revanche, tout n'est pas purgé : seules les transactions terminées
(commitées ou annulées) le sont. Celles-qui sont en cours sont maintenues
bien entendues.
De là en découle par exemple l'estimation d'une fréquence correcte de
sauvegarde afin que ton log ne prenne pas une taille Gargantuesque.

Pour plus d'infos je t'invite vivement à te rapprocher de la doc en ligne
livrée avec Sql Server. Dans l'onglet index : backup log ---> Rubrique
"Architecture : Troncature du journal des transactions". C'est très bien
expliqué et tout y est détaillé.

Quant à l'option no_truncate, c'est une option qui permet de sauvegarder le
journal sans le purger, typiquement quand la base est endommagée.

J'espère avoir répondu à tes interrogations...

"vivi" a écrit :

> bonjour
>
> je debute en sql server et je cherche a comprendre le fonctionnement du
> journal des transactions
> 1- quand je fais une sauvegarde exemple backup log mabase...
> que se passe t-il est ce qu'il tronque les transactions exécutées? ou il
> sauvegarde toutes les transactions effectuées et celles pas encore validées ?
>
> 2- si il ne tronque rien pourquoi alors preciser no_truncate?
>
>
> merci

merci de ta réponse mais je suis dans le flou total et même avec la doc en
ligne je ne comprend pas

"vivi" wrote:

"Fred.M." wrote:

> Pour faire vite et court, oui en effet le journal de transaction est tronqué
> lors d'une sauvegarde. Ceci a cours sauf si ta base est en modèle de
> récupération simple ( ce qui correspond à l'activation de base de données
> "trunc. log. on chkpt.").
> En revanche, tout n'est pas purgé : seules les transactions terminées
> (commitées ou annulées) le sont. Celles-qui sont en cours sont maintenues
> bien entendues.
> De là en découle par exemple l'estimation d'une fréquence correcte de
> sauvegarde afin que ton log ne prenne pas une taille Gargantuesque.
>
> Pour plus d'infos je t'invite vivement à te rapprocher de la doc en ligne
> livrée avec Sql Server. Dans l'onglet index : backup log ---> Rubrique
> "Architecture : Troncature du journal des transactions". C'est très bien
> expliqué et tout y est détaillé.
>
> Quant à l'option no_truncate, c'est une option qui permet de sauvegarder le
> journal sans le purger, typiquement quand la base est endommagée.
>
> J'espère avoir répondu à tes interrogations...
>
> "vivi" a écrit :
>
> > bonjour
> >
> > je debute en sql server et je cherche a comprendre le fonctionnement du
> > journal des transactions
> > 1- quand je fais une sauvegarde exemple backup log mabase...
> > que se passe t-il est ce qu'il tronque les transactions exécutées? ou il
> > sauvegarde toutes les transactions effectuées et celles pas encore validées ?
> >
> > 2- si il ne tronque rien pourquoi alors preciser no_truncate?
> >
> >
> > merci


merci de ta réponse mais je suis dans le flou total et même avec la doc en
ligne je ne comprend pas

quel est l'intérêt de faire un backup log mabase si il ne sauvegarde pas les
transactions realisées ? comment je fais si ma base plante pour restaurer la
base de données + les modifs apportées par les transactions

Le BACKUP LOG va sauvegarder les Transactions dans le fichier de BackUp
puis va supprimer celles-ci du journal des transactions.

En cas de plantage:
Restauration du dernier BACKUP de base puis restauration de tous les BACKUP
de Transactions effectués après le Backup de la base.
(s'il n'y a pas de backup diff de la base, mais on va pas compliquer
plus...)


Laurent.





"vivi" <vivi@discussions.microsoft.com> wrote in message
news:CA861345-C39D-49E1-AF2E-420833A134BB@microsoft.com...

"vivi" wrote:

>
>
> "Fred.M." wrote:
>
> > Pour faire vite et court, oui en effet le journal de transaction est

tronqué

> > lors d'une sauvegarde. Ceci a cours sauf si ta base est en modèle de
> > récupération simple ( ce qui correspond à l'activation de base de

données

> > "trunc. log. on chkpt.").
> > En revanche, tout n'est pas purgé : seules les transactions terminées
> > (commitées ou annulées) le sont. Celles-qui sont en cours sont

maintenues

> > bien entendues.
> > De là en découle par exemple l'estimation d'une fréquence correcte de
> > sauvegarde afin que ton log ne prenne pas une taille Gargantuesque.
> >
> > Pour plus d'infos je t'invite vivement à te rapprocher de la doc en

ligne

> > livrée avec Sql Server. Dans l'onglet index : backup log ---> Rubrique
> > "Architecture : Troncature du journal des transactions". C'est très

bien

> > expliqué et tout y est détaillé.
> >
> > Quant à l'option no_truncate, c'est une option qui permet de

sauvegarder le

> > journal sans le purger, typiquement quand la base est endommagée.
> >
> > J'espère avoir répondu à tes interrogations...
> >
> > "vivi" a écrit :
> >
> > > bonjour
> > >
> > > je debute en sql server et je cherche a comprendre le fonctionnement

du

> > > journal des transactions
> > > 1- quand je fais une sauvegarde exemple backup log mabase...
> > > que se passe t-il est ce qu'il tronque les transactions exécutées?

ou il

> > > sauvegarde toutes les transactions effectuées et celles pas encore

validées ?

> > >
> > > 2- si il ne tronque rien pourquoi alors preciser no_truncate?
> > >
> > >
> > > merci
>
>
> merci de ta réponse mais je suis dans le flou total et même avec la doc

en

> ligne je ne comprend pas


quel est l'intérêt de faire un backup log mabase si il ne sauvegarde pas

les

transactions realisées ? comment je fais si ma base plante pour restaurer

la

base de données + les modifs apportées par les transactions

Pour mieux comprendre les transactions, je t'invite a lire l'excellent
article de Bruno:

http://www.frenchsql.com/Default.aspx?page=5&ArticleIDH

Laurent.



"vivi" <vivi@discussions.microsoft.com> wrote in message
news:CA861345-C39D-49E1-AF2E-420833A134BB@microsoft.com...

"vivi" wrote:

>
>
> "Fred.M." wrote:
>
> > Pour faire vite et court, oui en effet le journal de transaction est

tronqué

> > lors d'une sauvegarde. Ceci a cours sauf si ta base est en modèle de
> > récupération simple ( ce qui correspond à l'activation de base de

données

> > "trunc. log. on chkpt.").
> > En revanche, tout n'est pas purgé : seules les transactions terminées
> > (commitées ou annulées) le sont. Celles-qui sont en cours sont

maintenues

> > bien entendues.
> > De là en découle par exemple l'estimation d'une fréquence correcte de
> > sauvegarde afin que ton log ne prenne pas une taille Gargantuesque.
> >
> > Pour plus d'infos je t'invite vivement à te rapprocher de la doc en

ligne

> > livrée avec Sql Server. Dans l'onglet index : backup log ---> Rubrique
> > "Architecture : Troncature du journal des transactions". C'est très

bien

> > expliqué et tout y est détaillé.
> >
> > Quant à l'option no_truncate, c'est une option qui permet de

sauvegarder le

> > journal sans le purger, typiquement quand la base est endommagée.
> >
> > J'espère avoir répondu à tes interrogations...
> >
> > "vivi" a écrit :
> >
> > > bonjour
> > >
> > > je debute en sql server et je cherche a comprendre le fonctionnement

du

> > > journal des transactions
> > > 1- quand je fais une sauvegarde exemple backup log mabase...
> > > que se passe t-il est ce qu'il tronque les transactions exécutées?

ou il

> > > sauvegarde toutes les transactions effectuées et celles pas encore

validées ?

> > >
> > > 2- si il ne tronque rien pourquoi alors preciser no_truncate?
> > >
> > >
> > > merci
>
>
> merci de ta réponse mais je suis dans le flou total et même avec la doc

en

> ligne je ne comprend pas


quel est l'intérêt de faire un backup log mabase si il ne sauvegarde pas

les

transactions realisées ? comment je fais si ma base plante pour restaurer

la

base de données + les modifs apportées par les transactions

Imaginons que ton log contiennent les infos suivantes (je caricature
volontairement) :
Begin Trans T1
insert ...
Commit T1
Begin Trans T2
Update ...
Commit T2
Begin Trans T3
Update ...
Update ...
Rollback T3
Begin Trans T4
Update ...
Update ...

Si tu opères une sauvegarde a ce stade, les transactions T1, T2 & T3 seront
purgés du log, puisqu'elles sont terminées (commit ou rollback). Elles sont
copiées de toutes façon dans ton fichier *.bak, donc il est inutile de les
garder ds le log. Ainsi quand tu vas restaurer ta base, il va récupérer les
transactions à partir de ton fichier de sauvegarde *.bak.
En revanche, comme la transaction T4 n'est pas encore terminée, Sql Server
n'est pas en mesure de savoir si cette transaction est valide ou pas. Il ne
va donc pas la tronquer et la maintenir dans le log.

Conclusion : toutes les modifs valides de tes transactions sont enregistrées
ds ton fichier de sauvegarde. La restauration les met toute seule en cas de
besoin.

quel est l'intérêt de faire un backup log mabase si il ne sauvegarde pas les
transactions realisées ? comment je fais si ma base plante pour restaurer la
base de données + les modifs apportées par les transactions

"Fred.M." a écrit :

Imaginons que ton log contiennent les infos suivantes (je caricature
volontairement) :
Begin Trans T1
insert ...
Commit T1
Begin Trans T2
Update ...
Commit T2
Begin Trans T3
Update ...
Update ...
Rollback T3
Begin Trans T4
Update ...
Update ...

Si tu opères une sauvegarde a ce stade, les transactions T1, T2 & T3 seront
purgés du log, puisqu'elles sont terminées (commit ou rollback). Elles sont
copiées de toutes façon dans ton fichier *.bak, donc il est inutile de les
garder ds le log. Ainsi quand tu vas restaurer ta base, il va récupérer les
transactions à partir de ton fichier de sauvegarde *.bak.
En revanche, comme la transaction T4 n'est pas encore terminée, Sql Server
n'est pas en mesure de savoir si cette transaction est valide ou pas. Il ne
va donc pas la tronquer et la maintenir dans le log.

Conclusion : toutes les modifs valides de tes transactions sont enregistrées
ds ton fichier de sauvegarde. La restauration les met toute seule en cas de
besoin.



> quel est l'intérêt de faire un backup log mabase si il ne sauvegarde pas les
> transactions realisées ? comment je fais si ma base plante pour restaurer la
> base de données + les modifs apportées par les transactions + celle qui n'est pas encore

ok merci de m'accorder un peu de votre savoir

donc si je sauvegarde avec backup log mabase ... il prend toutes les
transactions validées (commit ou rollback) dans la sauvegarde du journal?
sauf celle qui n'est pas encore jouée; et purge celles qui sont validées dans
le journal? c ca?


oki j'y vais pas à pas excusez ...

donc a chaque sauvegarde il fait une purge automatique du journal des
transactions enfin celles qui sont validées?et les transfere dans la
sauvegarde

alors c koi la différence entre backup log mabase et backup mabase with
no_log ou with truncate_only?
car si je comprend bien les deux derniers purgent le journal des
transactiions (log)validées en les sauvegardant ?

dites moi si je me trompe j'aime bien comprendre
si je plante ma base à 12 h00 je remonte ma derniere base de données de la
veille au soir + les sauvegardes des journaux que je fais toutes les 30
minutes mais jusqu'a 11h30, manque de bol celui de 12 h30 a pas pu avoir lieu
j'ai ma base plus les transactions effectuées jusque 11h 30 mais pas celles
qui ont commencé ou été validées apres 11h30 oki?

comment je fais pour recupérer mes transactions commencées ou validées apres
11h30?

je sais c un peu long mais merci de votre patience?

backup log with no_log , backup log with truncate only sont des instructions
de vidage du journal (purje)

par contre backup log with no_truncate est une instruction qui marche meme
si tu perds les fichiers de données et te permet de recuperer la base
integralement !!!

Pour le reste backup log db to unité c'est une sauvgarde du journal des
transactions qui se termine par un vidage des anciennes transactions validées
( cela ne sert a rien de les garder alors qu'elles sont soigneusement
consignées dans le dernier backup du journal !!

hch

"vivi" a écrit :

"Fred.M." a écrit :

> Imaginons que ton log contiennent les infos suivantes (je caricature
> volontairement) :
> Begin Trans T1
> insert ...
> Commit T1
> Begin Trans T2
> Update ...
> Commit T2
> Begin Trans T3
> Update ...
> Update ...
> Rollback T3
> Begin Trans T4
> Update ...
> Update ...
>
> Si tu opères une sauvegarde a ce stade, les transactions T1, T2 & T3 seront
> purgés du log, puisqu'elles sont terminées (commit ou rollback). Elles sont
> copiées de toutes façon dans ton fichier *.bak, donc il est inutile de les
> garder ds le log. Ainsi quand tu vas restaurer ta base, il va récupérer les
> transactions à partir de ton fichier de sauvegarde *.bak.
> En revanche, comme la transaction T4 n'est pas encore terminée, Sql Server
> n'est pas en mesure de savoir si cette transaction est valide ou pas. Il ne
> va donc pas la tronquer et la maintenir dans le log.
>
> Conclusion : toutes les modifs valides de tes transactions sont enregistrées
> ds ton fichier de sauvegarde. La restauration les met toute seule en cas de
> besoin.
>
>
>
> > quel est l'intérêt de faire un backup log mabase si il ne sauvegarde pas les
> > transactions realisées ? comment je fais si ma base plante pour restaurer la
> > base de données + les modifs apportées par les transactions + celle qui n'est pas encore


ok merci de m'accorder un peu de votre savoir

donc si je sauvegarde avec backup log mabase ... il prend toutes les
transactions validées (commit ou rollback) dans la sauvegarde du journal?
sauf celle qui n'est pas encore jouée; et purge celles qui sont validées dans
le journal? c ca?


oki j'y vais pas à pas excusez ...

donc a chaque sauvegarde il fait une purge automatique du journal des
transactions enfin celles qui sont validées?et les transfere dans la
sauvegarde

alors c koi la différence entre backup log mabase et backup mabase with
no_log ou with truncate_only?
car si je comprend bien les deux derniers purgent le journal des
transactiions (log)validées en les sauvegardant ?

dites moi si je me trompe j'aime bien comprendre
si je plante ma base à 12 h00 je remonte ma derniere base de données de la
veille au soir + les sauvegardes des journaux que je fais toutes les 30
minutes mais jusqu'a 11h30, manque de bol celui de 12 h30 a pas pu avoir lieu
j'ai ma base plus les transactions effectuées jusque 11h 30 mais pas celles
qui ont commencé ou été validées apres 11h30 oki?

comment je fais pour recupérer mes transactions commencées ou validées apres
11h30?

je sais c un peu long mais merci de votre patience?

donc backup log mabase ou backup log mabase with no_log ou backup log mabase
with truncate c la meme chose car tous les trois vident le journal des
transactions validées mais pas celles non validées, et sauvegardent les
validées
dans le .bak

tandis que backup log mabase with no_truncate ne vide pas le journal des
transactions et sauvegardent dans le .bak les transactions validées et non
validées ?

is it good?

je vais y arriver c promis






"hch" wrote:

backup log with no_log , backup log with truncate only sont des instructions
de vidage du journal (purje)

par contre backup log with no_truncate est une instruction qui marche meme
si tu perds les fichiers de données et te permet de recuperer la base
integralement !!!

Pour le reste backup log db to unité c'est une sauvgarde du journal des
transactions qui se termine par un vidage des anciennes transactions validées
( cela ne sert a rien de les garder alors qu'elles sont soigneusement
consignées dans le dernier backup du journal !!

hch

"vivi" a écrit :

>
>
> "Fred.M." a écrit :
>
> > Imaginons que ton log contiennent les infos suivantes (je caricature
> > volontairement) :
> > Begin Trans T1
> > insert ...
> > Commit T1
> > Begin Trans T2
> > Update ...
> > Commit T2
> > Begin Trans T3
> > Update ...
> > Update ...
> > Rollback T3
> > Begin Trans T4
> > Update ...
> > Update ...
> >
> > Si tu opères une sauvegarde a ce stade, les transactions T1, T2 & T3 seront
> > purgés du log, puisqu'elles sont terminées (commit ou rollback). Elles sont
> > copiées de toutes façon dans ton fichier *.bak, donc il est inutile de les
> > garder ds le log. Ainsi quand tu vas restaurer ta base, il va récupérer les
> > transactions à partir de ton fichier de sauvegarde *.bak.
> > En revanche, comme la transaction T4 n'est pas encore terminée, Sql Server
> > n'est pas en mesure de savoir si cette transaction est valide ou pas. Il ne
> > va donc pas la tronquer et la maintenir dans le log.
> >
> > Conclusion : toutes les modifs valides de tes transactions sont enregistrées
> > ds ton fichier de sauvegarde. La restauration les met toute seule en cas de
> > besoin.
> >
> >
> >
> > > quel est l'intérêt de faire un backup log mabase si il ne sauvegarde pas les
> > > transactions realisées ? comment je fais si ma base plante pour restaurer la
> > > base de données + les modifs apportées par les transactions + celle qui n'est pas encore
>
>
> ok merci de m'accorder un peu de votre savoir
>
> donc si je sauvegarde avec backup log mabase ... il prend toutes les
> transactions validées (commit ou rollback) dans la sauvegarde du journal?
> sauf celle qui n'est pas encore jouée; et purge celles qui sont validées dans
> le journal? c ca?
>
>
> oki j'y vais pas à pas excusez ...
>
> donc a chaque sauvegarde il fait une purge automatique du journal des
> transactions enfin celles qui sont validées?et les transfere dans la
> sauvegarde
>
> alors c koi la différence entre backup log mabase et backup mabase with
> no_log ou with truncate_only?
> car si je comprend bien les deux derniers purgent le journal des
> transactiions (log)validées en les sauvegardant ?
>
> dites moi si je me trompe j'aime bien comprendre
> si je plante ma base à 12 h00 je remonte ma derniere base de données de la
> veille au soir + les sauvegardes des journaux que je fais toutes les 30
> minutes mais jusqu'a 11h30, manque de bol celui de 12 h30 a pas pu avoir lieu
> j'ai ma base plus les transactions effectuées jusque 11h 30 mais pas celles
> qui ont commencé ou été validées apres 11h30 oki?
>
> comment je fais pour recupérer mes transactions commencées ou validées apres
> 11h30?
>
> je sais c un peu long mais merci de votre patience?
>
>
>

backup log with no_log et backup log with truncate only , vident le journal
mais Attention ne sauvegardent rien ..et ne generent pas de fichiers .bak
alors que backup log db to unité sauvegarde ds un fichier et efface les
transactions validées....
c'est ca la difference ....

Le backup log with no_trucate recupere tout le contenu du log depuis la
derniere sauvegarde reussie et permet donc de restaurer la base jusqu'au
moment du crash..

hch

"vivi" a écrit :

donc backup log mabase ou backup log mabase with no_log ou backup log mabase
with truncate c la meme chose car tous les trois vident le journal des
transactions validées mais pas celles non validées, et sauvegardent les
validées
dans le .bak

tandis que backup log mabase with no_truncate ne vide pas le journal des
transactions et sauvegardent dans le .bak les transactions validées et non
validées ?

is it good?

je vais y arriver c promis






"hch" wrote:

> backup log with no_log , backup log with truncate only sont des instructions
> de vidage du journal (purje)
>
> par contre backup log with no_truncate est une instruction qui marche meme
> si tu perds les fichiers de données et te permet de recuperer la base
> integralement !!!
>
> Pour le reste backup log db to unité c'est une sauvgarde du journal des
> transactions qui se termine par un vidage des anciennes transactions validées
> ( cela ne sert a rien de les garder alors qu'elles sont soigneusement
> consignées dans le dernier backup du journal !!
>
> hch
>
> "vivi" a écrit :
>
> >
> >
> > "Fred.M." a écrit :
> >
> > > Imaginons que ton log contiennent les infos suivantes (je caricature
> > > volontairement) :
> > > Begin Trans T1
> > > insert ...
> > > Commit T1
> > > Begin Trans T2
> > > Update ...
> > > Commit T2
> > > Begin Trans T3
> > > Update ...
> > > Update ...
> > > Rollback T3
> > > Begin Trans T4
> > > Update ...
> > > Update ...
> > >
> > > Si tu opères une sauvegarde a ce stade, les transactions T1, T2 & T3 seront
> > > purgés du log, puisqu'elles sont terminées (commit ou rollback). Elles sont
> > > copiées de toutes façon dans ton fichier *.bak, donc il est inutile de les
> > > garder ds le log. Ainsi quand tu vas restaurer ta base, il va récupérer les
> > > transactions à partir de ton fichier de sauvegarde *.bak.
> > > En revanche, comme la transaction T4 n'est pas encore terminée, Sql Server
> > > n'est pas en mesure de savoir si cette transaction est valide ou pas. Il ne
> > > va donc pas la tronquer et la maintenir dans le log.
> > >
> > > Conclusion : toutes les modifs valides de tes transactions sont enregistrées
> > > ds ton fichier de sauvegarde. La restauration les met toute seule en cas de
> > > besoin.
> > >
> > >
> > >
> > > > quel est l'intérêt de faire un backup log mabase si il ne sauvegarde pas les
> > > > transactions realisées ? comment je fais si ma base plante pour restaurer la
> > > > base de données + les modifs apportées par les transactions + celle qui n'est pas encore
> >
> >
> > ok merci de m'accorder un peu de votre savoir
> >
> > donc si je sauvegarde avec backup log mabase ... il prend toutes les
> > transactions validées (commit ou rollback) dans la sauvegarde du journal?
> > sauf celle qui n'est pas encore jouée; et purge celles qui sont validées dans
> > le journal? c ca?
> >
> >
> > oki j'y vais pas à pas excusez ...
> >
> > donc a chaque sauvegarde il fait une purge automatique du journal des
> > transactions enfin celles qui sont validées?et les transfere dans la
> > sauvegarde
> >
> > alors c koi la différence entre backup log mabase et backup mabase with
> > no_log ou with truncate_only?
> > car si je comprend bien les deux derniers purgent le journal des
> > transactiions (log)validées en les sauvegardant ?
> >
> > dites moi si je me trompe j'aime bien comprendre
> > si je plante ma base à 12 h00 je remonte ma derniere base de données de la
> > veille au soir + les sauvegardes des journaux que je fais toutes les 30
> > minutes mais jusqu'a 11h30, manque de bol celui de 12 h30 a pas pu avoir lieu
> > j'ai ma base plus les transactions effectuées jusque 11h 30 mais pas celles
> > qui ont commencé ou été validées apres 11h30 oki?
> >
> > comment je fais pour recupérer mes transactions commencées ou validées apres
> > 11h30?
> >
> > je sais c un peu long mais merci de votre patience?
> >
> >
> >