Précédent   Forum des professionnels en informatique > Bases de données > Décisions SGBD
Décisions SGBD Forum de décisions sur le choix en bases de données. Le Comparatif
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 30/07/2005, 17h57   #1
Invité de passage
 
Inscription : juillet 2005
Messages : 4
Détails du profil
Informations forums :
Inscription : juillet 2005
Messages : 4
Points : 1
Points : 1
Par défaut Journal de transaction

salut
aprés avoir lu un peu sur les transactions et la gestion des concurence d'accés je me suis posé la question suivante:
- les effets d'une transaction ne sont répercuté sur la base de données que s'il ya validation ( COMMIT ) ; donc comment une transaction pourrait t'elle modifié l'etat de la base sans avoir été totalement exécuté et terminé .
Donc en cas d'incident les transactions intérompues n'aurant pas d'effet sur la base de donnée .
Voila , j'espere qu'on m'aiderai à surmenter ce que j'arrive pa à pigé
zamine81 est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 31/07/2005, 14h07   #2
Rédacteur/Modérateur

 
Avatar de SQLpro
 
Homme Frédéric BROUARD
Expert SGBDR & SQL
Inscription : mai 2002
Messages : 10 959
Détails du profil
Informations personnelles :
Nom : Homme Frédéric BROUARD
Localisation : France

Informations professionnelles :
Activité : Expert SGBDR & SQL
Secteur : Conseil

Informations forums :
Inscription : mai 2002
Messages : 10 959
Points : 17 793
Points : 17 793
Ce que tu dis n'est pas clair...

Citation:
...donc comment une transaction pourrait t-elle modifier l'etat de la base sans avoir été totalement exécuté et terminé .
C'est le principe même des transactions : tant quelle n'est pas validée aucune modification des données n'a lieu.

Citation:
...Donc en cas d'incident les transactions intérompues n'aurant pas d'effet sur la base de donnée
Faux ! les transaction interrompues sont reprises jusqu'à achévement pas un commit ou un rollback.

Lit ce que j'ai écrit sur le sujet : http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1

A +
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
SQLpro est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 01/08/2005, 08h42   #3
Rédacteur/Modérateur
 
Avatar de orafrance
 
Inscription : janvier 2004
Messages : 15 861
Détails du profil
Informations personnelles :
Âge : 35

Informations forums :
Inscription : janvier 2004
Messages : 15 861
Points : 16 212
Points : 16 212
j'ajouterai que ce n'est pas parce que tu tues un process que la transaction se termine. Un exemple sous Oracle, j'ai souvent vu des admins peu expérimenté killer une session de DELETE trop longue espérant ainsi reprendre la main. Sauf que même dans ce cas, Oracle termine la transaction et donc le rollback se qui peut s'avérer TRES long. Seul un shutdown immediate (kill -9 de tous les process) met fin à ces transactions mais là, gare à la survie de la base
orafrance est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 01/08/2005, 14h05   #4
Invité de passage
 
Inscription : juillet 2005
Messages : 4
Détails du profil
Informations forums :
Inscription : juillet 2005
Messages : 4
Points : 1
Points : 1
Par défaut Journal de transaction

merci pour la réponse SQLpro et j'avoue que ce que j'ai écrit etait assez embrouillé, ce dont je voulais parlais c'est le principe de la reprise aprés panne utilisé dans le SGBDR et l'utilisation de la journalisation des transactions pour remetre la BDD dans un etat coherant:

Aprés avoir lus plusieurs documentation j'arrive toujour pas à comprendre comment dans un cas d'incident et qu'il ya des transactions en cours d'éxecution ,la BDD se trouverait dans un etat incoherant puisque avant l'incident elle etait dans un état coherant et que les transactions Normalement ne sont pa responsable d'un etat incoherant de la BDD ?

Voila, j'espere que cette fois j'etait plus clair et ce que je cherche déssepérement c'est un exemple illustrant le le mécanisme de reprise aprés panne pour comprendre une bonne fois pout toute
zamine81 est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 11h57.


 
 
 
 
Partenaires

Hébergement Web