J'aimerais savoir si le comportement de Sql Server 2000/2005 est différent,
comme je le crois, en ce qui concerne les transactions de Oracle.
Ce que je crois comprendre: dans Sql Server, seule les transactions
commitées sont écrites dans la base. Lorsqu'on veut restaurer, on nprend le
fichier journal et on applique les transactions commitées non encore écrites
en base. On a donc un redo log.
En Oracle, sur un checkpoint, toutes les transactions sont écrites dans la
base. Lors d'une restauration on applique les redo log, puis le undo log
(rollback segment) qui défait les transactions non commitées.
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
Vuillermet Jacques
Pour le côté SQL Server, oui, à mon avis.
Jacques.
"Oriane" a écrit dans le message de news: dq2gjt$e9a$
Bonjour,
J'aimerais savoir si le comportement de Sql Server 2000/2005 est
différent,
comme je le crois, en ce qui concerne les transactions de Oracle. Ce que je crois comprendre: dans Sql Server, seule les transactions commitées sont écrites dans la base. Lorsqu'on veut restaurer, on nprend
le
fichier journal et on applique les transactions commitées non encore
écrites
en base. On a donc un redo log.
En Oracle, sur un checkpoint, toutes les transactions sont écrites dans la base. Lors d'une restauration on applique les redo log, puis le undo log (rollback segment) qui défait les transactions non commitées.
Ma vision est-elle exacte ?
Oriane
Pour le côté SQL Server, oui, à mon avis.
Jacques.
"Oriane" <oriane@guermantes.fr> a écrit dans le message de news:
dq2gjt$e9a$1@yucatan.franconews.org...
Bonjour,
J'aimerais savoir si le comportement de Sql Server 2000/2005 est
différent,
comme je le crois, en ce qui concerne les transactions de Oracle.
Ce que je crois comprendre: dans Sql Server, seule les transactions
commitées sont écrites dans la base. Lorsqu'on veut restaurer, on nprend
le
fichier journal et on applique les transactions commitées non encore
écrites
en base. On a donc un redo log.
En Oracle, sur un checkpoint, toutes les transactions sont écrites dans la
base. Lors d'une restauration on applique les redo log, puis le undo log
(rollback segment) qui défait les transactions non commitées.
"Oriane" a écrit dans le message de news: dq2gjt$e9a$
Bonjour,
J'aimerais savoir si le comportement de Sql Server 2000/2005 est
différent,
comme je le crois, en ce qui concerne les transactions de Oracle. Ce que je crois comprendre: dans Sql Server, seule les transactions commitées sont écrites dans la base. Lorsqu'on veut restaurer, on nprend
le
fichier journal et on applique les transactions commitées non encore
écrites
en base. On a donc un redo log.
En Oracle, sur un checkpoint, toutes les transactions sont écrites dans la base. Lors d'une restauration on applique les redo log, puis le undo log (rollback segment) qui défait les transactions non commitées.
Ma vision est-elle exacte ?
Oriane
Med Bouchenafa
C'est le même principe sous SQL Server sauf que c'est fait automatiquement Il n'y a pas de commande specifique pour defaire les transactions non commitées mais enregistrées dans le journal Lorsque l'on demarre SQL Server et que le journal contient encore des transactions non committées, elles sont défaites automatiquement
-- Avec mes meilleurs voeux 2006 Med Bouchenafa
"Oriane" a écrit dans le message de news: dq2gjt$e9a$
Bonjour,
J'aimerais savoir si le comportement de Sql Server 2000/2005 est différent, comme je le crois, en ce qui concerne les transactions de Oracle. Ce que je crois comprendre: dans Sql Server, seule les transactions commitées sont écrites dans la base. Lorsqu'on veut restaurer, on nprend le fichier journal et on applique les transactions commitées non encore écrites en base. On a donc un redo log.
En Oracle, sur un checkpoint, toutes les transactions sont écrites dans la base. Lors d'une restauration on applique les redo log, puis le undo log (rollback segment) qui défait les transactions non commitées.
Ma vision est-elle exacte ?
Oriane
C'est le même principe sous SQL Server sauf que c'est fait automatiquement
Il n'y a pas de commande specifique pour defaire les transactions non
commitées mais enregistrées dans le journal
Lorsque l'on demarre SQL Server et que le journal contient encore des
transactions non committées, elles sont défaites automatiquement
--
Avec mes meilleurs voeux 2006
Med Bouchenafa
"Oriane" <oriane@guermantes.fr> a écrit dans le message de news:
dq2gjt$e9a$1@yucatan.franconews.org...
Bonjour,
J'aimerais savoir si le comportement de Sql Server 2000/2005 est
différent, comme je le crois, en ce qui concerne les transactions de
Oracle.
Ce que je crois comprendre: dans Sql Server, seule les transactions
commitées sont écrites dans la base. Lorsqu'on veut restaurer, on nprend
le fichier journal et on applique les transactions commitées non encore
écrites en base. On a donc un redo log.
En Oracle, sur un checkpoint, toutes les transactions sont écrites dans la
base. Lors d'une restauration on applique les redo log, puis le undo log
(rollback segment) qui défait les transactions non commitées.
C'est le même principe sous SQL Server sauf que c'est fait automatiquement Il n'y a pas de commande specifique pour defaire les transactions non commitées mais enregistrées dans le journal Lorsque l'on demarre SQL Server et que le journal contient encore des transactions non committées, elles sont défaites automatiquement
-- Avec mes meilleurs voeux 2006 Med Bouchenafa
"Oriane" a écrit dans le message de news: dq2gjt$e9a$
Bonjour,
J'aimerais savoir si le comportement de Sql Server 2000/2005 est différent, comme je le crois, en ce qui concerne les transactions de Oracle. Ce que je crois comprendre: dans Sql Server, seule les transactions commitées sont écrites dans la base. Lorsqu'on veut restaurer, on nprend le fichier journal et on applique les transactions commitées non encore écrites en base. On a donc un redo log.
En Oracle, sur un checkpoint, toutes les transactions sont écrites dans la base. Lors d'une restauration on applique les redo log, puis le undo log (rollback segment) qui défait les transactions non commitées.
Ma vision est-elle exacte ?
Oriane
Oriane
"Med Bouchenafa" a écrit dans le message de news:
C'est le même principe sous SQL Server sauf que c'est fait automatiquement Il n'y a pas de commande specifique pour defaire les transactions non commitées mais enregistrées dans le journal
Il fallait comprendre que c'est automatique aussi pour Oracle !
Lorsque l'on demarre SQL Server et que le journal contient encore des transactions non committées, elles sont défaites automatiquement
Comment peut-on fermer Sql Server avec une transaction non commitée ?
Merci de votre réponse et meilleurs voeux
-- Avec mes meilleurs voeux 2006 Med Bouchenafa
"Med Bouchenafa" <com.hotmail@bouchenafa> a écrit dans le message de news:
uueDJNqFGHA.2696@TK2MSFTNGP14.phx.gbl...
C'est le même principe sous SQL Server sauf que c'est fait automatiquement
Il n'y a pas de commande specifique pour defaire les transactions non
commitées mais enregistrées dans le journal
Il fallait comprendre que c'est automatique aussi pour Oracle !
Lorsque l'on demarre SQL Server et que le journal contient encore des
transactions non committées, elles sont défaites automatiquement
Comment peut-on fermer Sql Server avec une transaction non commitée ?
C'est le même principe sous SQL Server sauf que c'est fait automatiquement Il n'y a pas de commande specifique pour defaire les transactions non commitées mais enregistrées dans le journal
Il fallait comprendre que c'est automatique aussi pour Oracle !
Lorsque l'on demarre SQL Server et que le journal contient encore des transactions non committées, elles sont défaites automatiquement
Comment peut-on fermer Sql Server avec une transaction non commitée ?
Merci de votre réponse et meilleurs voeux
-- Avec mes meilleurs voeux 2006 Med Bouchenafa
Oriane
Bonjour, "Vuillermet Jacques" a écrit dans le message de news:
Pour le côté SQL Server, oui, à mon avis.
Pourtant vous parlez vous même de transactions non commitées "défaites" dans le fil "Problème de restauration". N'est-ce pas contradictoire...
Cdt
Bonjour,
"Vuillermet Jacques" <nospam@nospam.com> a écrit dans le message de news:
OMakZSpFGHA.1396@TK2MSFTNGP11.phx.gbl...
Pour le côté SQL Server, oui, à mon avis.
Pourtant vous parlez vous même de transactions non commitées "défaites" dans
le fil "Problème de restauration".
N'est-ce pas contradictoire...
Bonjour, "Vuillermet Jacques" a écrit dans le message de news:
Pour le côté SQL Server, oui, à mon avis.
Pourtant vous parlez vous même de transactions non commitées "défaites" dans le fil "Problème de restauration". N'est-ce pas contradictoire...
Cdt
Vuillermet Jacques
Les transactions non commitées ne sont présentes que dans les logs. Les "défaire" consiste simplement à les supprimer des logs.
Jacques.
"Oriane" a écrit dans le message de news: dq2uvl$6v0$
Bonjour, "Vuillermet Jacques" a écrit dans le message de news:
> Pour le côté SQL Server, oui, à mon avis. Pourtant vous parlez vous même de transactions non commitées "défaites"
dans
le fil "Problème de restauration". N'est-ce pas contradictoire...
Cdt
Les transactions non commitées ne sont présentes que dans les logs.
Les "défaire" consiste simplement à les supprimer des logs.
Jacques.
"Oriane" <oriane@guermantes.fr> a écrit dans le message de news:
dq2uvl$6v0$1@yucatan.franconews.org...
Bonjour,
"Vuillermet Jacques" <nospam@nospam.com> a écrit dans le message de news:
OMakZSpFGHA.1396@TK2MSFTNGP11.phx.gbl...
> Pour le côté SQL Server, oui, à mon avis.
Pourtant vous parlez vous même de transactions non commitées "défaites"
dans
le fil "Problème de restauration".
N'est-ce pas contradictoire...
Les transactions non commitées ne sont présentes que dans les logs. Les "défaire" consiste simplement à les supprimer des logs.
Jacques.
"Oriane" a écrit dans le message de news: dq2uvl$6v0$
Bonjour, "Vuillermet Jacques" a écrit dans le message de news:
> Pour le côté SQL Server, oui, à mon avis. Pourtant vous parlez vous même de transactions non commitées "défaites"
dans
le fil "Problème de restauration". N'est-ce pas contradictoire...
Cdt
Oriane
Ah là je ne suis pas d'accord. Les défaire, c'est les défaire sur le disque. Un fichier de log est par définition "append only".
"Vuillermet Jacques" a écrit dans le message de news:
Les transactions non commitées ne sont présentes que dans les logs. Les "défaire" consiste simplement à les supprimer des logs.
Jacques.
"Oriane" a écrit dans le message de news: dq2uvl$6v0$
Bonjour, "Vuillermet Jacques" a écrit dans le message de news:
> Pour le côté SQL Server, oui, à mon avis. Pourtant vous parlez vous même de transactions non commitées "défaites"
dans
le fil "Problème de restauration". N'est-ce pas contradictoire...
Cdt
Ah là je ne suis pas d'accord. Les défaire, c'est les défaire sur le disque.
Un fichier de log est par définition "append only".
"Vuillermet Jacques" <nospam@nospam.com> a écrit dans le message de news:
OkScDztFGHA.1260@TK2MSFTNGP15.phx.gbl...
Les transactions non commitées ne sont présentes que dans les logs.
Les "défaire" consiste simplement à les supprimer des logs.
Jacques.
"Oriane" <oriane@guermantes.fr> a écrit dans le message de news:
dq2uvl$6v0$1@yucatan.franconews.org...
Bonjour,
"Vuillermet Jacques" <nospam@nospam.com> a écrit dans le message de news:
OMakZSpFGHA.1396@TK2MSFTNGP11.phx.gbl...
> Pour le côté SQL Server, oui, à mon avis.
Pourtant vous parlez vous même de transactions non commitées "défaites"
dans
le fil "Problème de restauration".
N'est-ce pas contradictoire...
Ah là je ne suis pas d'accord. Les défaire, c'est les défaire sur le disque. Un fichier de log est par définition "append only".
"Vuillermet Jacques" a écrit dans le message de news:
Les transactions non commitées ne sont présentes que dans les logs. Les "défaire" consiste simplement à les supprimer des logs.
Jacques.
"Oriane" a écrit dans le message de news: dq2uvl$6v0$
Bonjour, "Vuillermet Jacques" a écrit dans le message de news:
> Pour le côté SQL Server, oui, à mon avis. Pourtant vous parlez vous même de transactions non commitées "défaites"
dans
le fil "Problème de restauration". N'est-ce pas contradictoire...
Cdt
Oriane
"Med Bouchenafa" a écrit dans le message de news:
C'est le même principe sous SQL Server sauf que c'est fait automatiquement Il n'y a pas de commande specifique pour defaire les transactions non commitées mais enregistrées dans le journal
Autre différence par rapport à Oracle: pour Sql Server le log est à la fois le "redo" et le "undo". Sor Oracle le Undo log, ce sont les Rollback segments, qui sont une structure séparée de celle du "redo log" (cad du fichier de log des transactions).
"Med Bouchenafa" <com.hotmail@bouchenafa> a écrit dans le message de news:
uueDJNqFGHA.2696@TK2MSFTNGP14.phx.gbl...
C'est le même principe sous SQL Server sauf que c'est fait automatiquement
Il n'y a pas de commande specifique pour defaire les transactions non
commitées mais enregistrées dans le journal
Autre différence par rapport à Oracle: pour Sql Server le log est à la fois
le "redo" et le "undo". Sor Oracle le Undo log, ce sont les Rollback
segments, qui sont une structure séparée de celle du "redo log" (cad du
fichier de log des transactions).
C'est le même principe sous SQL Server sauf que c'est fait automatiquement Il n'y a pas de commande specifique pour defaire les transactions non commitées mais enregistrées dans le journal
Autre différence par rapport à Oracle: pour Sql Server le log est à la fois le "redo" et le "undo". Sor Oracle le Undo log, ce sont les Rollback segments, qui sont une structure séparée de celle du "redo log" (cad du fichier de log des transactions).
bruno reiter [MVP]
défaire les transactions, c'est s'assurer que les datas sont dans l'état AVANT modif, dans le cas où le lazy writer aurait fait la mise à jour avant la fin de la transaction.
br
"Oriane" wrote in message news:dq3rl5$k5u$
Ah là je ne suis pas d'accord. Les défaire, c'est les défaire sur le
disque.
Un fichier de log est par définition "append only".
"Vuillermet Jacques" a écrit dans le message de news:
> Les transactions non commitées ne sont présentes que dans les logs. > Les "défaire" consiste simplement à les supprimer des logs. > > Jacques. > > > "Oriane" a écrit dans le message de news: > dq2uvl$6v0$ >> Bonjour, >> "Vuillermet Jacques" a écrit dans le message de
news:
>> >> > Pour le côté SQL Server, oui, à mon avis. >> Pourtant vous parlez vous même de transactions non commitées "défaites" > dans >> le fil "Problème de restauration". >> N'est-ce pas contradictoire... >> >> Cdt >> >> > >
défaire les transactions, c'est s'assurer que les datas sont dans l'état
AVANT modif, dans le cas où le lazy writer aurait fait la mise à jour avant
la fin de la transaction.
br
"Oriane" <oriane@guermantes.fr> wrote in message
news:dq3rl5$k5u$1@yucatan.franconews.org...
Ah là je ne suis pas d'accord. Les défaire, c'est les défaire sur le
disque.
Un fichier de log est par définition "append only".
"Vuillermet Jacques" <nospam@nospam.com> a écrit dans le message de news:
OkScDztFGHA.1260@TK2MSFTNGP15.phx.gbl...
> Les transactions non commitées ne sont présentes que dans les logs.
> Les "défaire" consiste simplement à les supprimer des logs.
>
> Jacques.
>
>
> "Oriane" <oriane@guermantes.fr> a écrit dans le message de news:
> dq2uvl$6v0$1@yucatan.franconews.org...
>> Bonjour,
>> "Vuillermet Jacques" <nospam@nospam.com> a écrit dans le message de
news:
>> OMakZSpFGHA.1396@TK2MSFTNGP11.phx.gbl...
>> > Pour le côté SQL Server, oui, à mon avis.
>> Pourtant vous parlez vous même de transactions non commitées "défaites"
> dans
>> le fil "Problème de restauration".
>> N'est-ce pas contradictoire...
>>
>> Cdt
>>
>>
>
>
défaire les transactions, c'est s'assurer que les datas sont dans l'état AVANT modif, dans le cas où le lazy writer aurait fait la mise à jour avant la fin de la transaction.
br
"Oriane" wrote in message news:dq3rl5$k5u$
Ah là je ne suis pas d'accord. Les défaire, c'est les défaire sur le
disque.
Un fichier de log est par définition "append only".
"Vuillermet Jacques" a écrit dans le message de news:
> Les transactions non commitées ne sont présentes que dans les logs. > Les "défaire" consiste simplement à les supprimer des logs. > > Jacques. > > > "Oriane" a écrit dans le message de news: > dq2uvl$6v0$ >> Bonjour, >> "Vuillermet Jacques" a écrit dans le message de
news:
>> >> > Pour le côté SQL Server, oui, à mon avis. >> Pourtant vous parlez vous même de transactions non commitées "défaites" > dans >> le fil "Problème de restauration". >> N'est-ce pas contradictoire... >> >> Cdt >> >> > >
lionelp
Bonjour,
Tout à fait, Oracle gère une image avant et après du fait de son mode d'isolation, un mécanisme similaire peut être mis en oeuvre dans SQL Server 2005.
Cordialement, LionelP
"Oriane" a écrit :
"Med Bouchenafa" a écrit dans le message de news:
> C'est le même principe sous SQL Server sauf que c'est fait automatiquement > Il n'y a pas de commande specifique pour defaire les transactions non > commitées mais enregistrées dans le journal Autre différence par rapport à Oracle: pour Sql Server le log est à la fois le "redo" et le "undo". Sor Oracle le Undo log, ce sont les Rollback segments, qui sont une structure séparée de celle du "redo log" (cad du fichier de log des transactions).
Bonjour,
Tout à fait, Oracle gère une image avant et après du fait de son mode
d'isolation, un mécanisme similaire peut être mis en oeuvre dans SQL Server
2005.
Cordialement,
LionelP
"Oriane" a écrit :
"Med Bouchenafa" <com.hotmail@bouchenafa> a écrit dans le message de news:
uueDJNqFGHA.2696@TK2MSFTNGP14.phx.gbl...
> C'est le même principe sous SQL Server sauf que c'est fait automatiquement
> Il n'y a pas de commande specifique pour defaire les transactions non
> commitées mais enregistrées dans le journal
Autre différence par rapport à Oracle: pour Sql Server le log est à la fois
le "redo" et le "undo". Sor Oracle le Undo log, ce sont les Rollback
segments, qui sont une structure séparée de celle du "redo log" (cad du
fichier de log des transactions).
Tout à fait, Oracle gère une image avant et après du fait de son mode d'isolation, un mécanisme similaire peut être mis en oeuvre dans SQL Server 2005.
Cordialement, LionelP
"Oriane" a écrit :
"Med Bouchenafa" a écrit dans le message de news:
> C'est le même principe sous SQL Server sauf que c'est fait automatiquement > Il n'y a pas de commande specifique pour defaire les transactions non > commitées mais enregistrées dans le journal Autre différence par rapport à Oracle: pour Sql Server le log est à la fois le "redo" et le "undo". Sor Oracle le Undo log, ce sont les Rollback segments, qui sont une structure séparée de celle du "redo log" (cad du fichier de log des transactions).
