Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
suite à une coupure de connexion qui n'a révélé aucune erreur au final, j'aimerai connaitre quelle est le temps d'exécution d'une transaction.
Ou puis je trouver cette information ?
merci
Hors ligne
tout dépend du contenu de la transaction ....
un :
begin;
select 1;
commit;
en plus d'etre inutile est tres rapide,
au contraire:
begin;
insert into foo select generate_series(1,10000000);
commit;
sera assez long... et en fonction des triggers et autres contraintes, cela impacte la durée.
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
Hors ligne
il n'y a donc pas moyen de connaitre le temps maximum accordé à une transaction lors d'une perte de connexion par exemple ?
Dans mon problème , c'est qu'il y a une coupure entre des serveurs, mais aucun incident sur leurs bases et donc je me demandais combien de temps peut durer une interruption de service sans avoir de problème derrière sur les bases.
Merci
Par contre je dois dire qu'a Postgres je connais pas grand chose 
Hors ligne
Que font ces différents serveurs ? quel problème craignez-vous ? sans plus d'infos, c'est difficile de vous répondre.
Tout ce qu'on peut vous dire, c'est qu'à partir du moment où la connexion réseau est perdue entre un client et le serveur, la transaction en cours est automatiquement et immédiatement abandonnée.
Guillaume.
Hors ligne
En fait c'est juste une question de curiosité, car j’étais surpris que malgré la coupure, il n'y ait eu d'incidents sur mes tables postgres, et ne trouvant rien dans le fichier postgresql.conf je me demandais s'il existait une tel valeur (sur le temps d’exécution maximum accordé a une transaction lors d'une coupure) et ou la trouver/paramétrer.
Merci pour tes informations
Hors ligne
A première vu il n'y aurait donc pas eu de coupure 
fausse alerte ^^
Hors ligne
Il n'y a pas de temps maximum (ni time out d'aucune sorte) et la durée d'une transaction peut être de plusieurs jours si nécessaire.
En cas de coupure de courant, si une transaction est en cours, elle est annulée par un ROLLBACK qui s'effectuera lorsque le serveur sera remis en marche (phase de RECOVERY).
Toutes les autres transactions sont validées.
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Hello,
alors la je suis un peu perdu :
Gleu dit : A partir du moment où la connexion réseau est perdue entre un client et le serveur, la transaction en cours est automatiquement et immédiatement abandonnée.
et
SQLpro répond : En cas de coupure de courant, si une transaction est en cours, elle est annulée par un ROLLBACK qui s'effectuera lorsque le serveur sera remis en marche (phase de RECOVERY)
c'est a dire que quelque soit la coupure il y a toujours un ROLLBACK ou pas ?? Gleu ne précisant pas s'il y a un ROLLBACK lors d'une coupure réseau.
Merci
Dernière modification par wazadex (26/07/2011 09:40:54)
Hors ligne
Une transaction se termine toujours soit par un COMMIT soit par un ROLLBACK. Il n'y a pas d'intermédiaire.
Nous avons tous les deux raison en ce sens qu'au moment de la coupure les transactions en cours sont dans un état "pendant" (de verbe pendre) c'est à dire non finalisées (le SGBRD ne peut pas savoir à l'avance quand aura lieu la coupure !!!! il n'est pas voyant extra lucide...)
Au moment de la reprise du service, le SGBDR interdit l'utilisation des bases de données tant qu'il n'a pas vérifié s'il y avait des transactions en cours.
Si ce n'est pas le cas il rend immédiatement la main et les utilisateurs peuvent travailler. La base est intègre.
S'il y a des transactions non finalisées, elles vont être annulées par un ROLLBACK forcé, et tant que ces ROLLBACK ne sont pas finalisés, alors les utilisateurs ne peuvent pas travailler car la base n'est pas intègre (certaines données sont incohérente). Une fois les ROLLBACK achevés, la basez devient de nouveau intègre et les utilisateurs peuvent désormais s'en servir.
Le mécanisme qui permet ceci est le journal de transaction qui enregistre tous les changements d'état de la base et les images avant et/ou après des données manipulées. Ceci permet donc de revenir à un état antérieur intègre de la base. Pour ce faire le journal de transaction enregistre les données dans le journal avec un marquage à base de LSN (Log Segment Number) et répercute ce LSN dans les fichiers de données afin de contrôler la cohérence. S'il y a différence dans les LSN entre les données et le JT, alors on revient sur une version intègre antérieure en se calant sur un LSN "stable"... (j'ai beaucoup simplifié...)
Ceci a été mis au point dans les années 70 par les travaux de Gray et Bernstein et l'algorithme utilisé pour ce faire est basé sur ARIES dans la plupart des SGBDR (PG compris) avec quelques variantes spécifiques.
Pour en savoir plus :
Les transactions : http://sqlpro.developpez.com/cours/sqlaz/techniques/
ARIES : http://www.sai.msu.su/~megera/postgres/ … -mohan.pdf
A +
Dernière modification par SQLpro (26/07/2011 11:46:03)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
merci beaucoup pour ta réponse claire
Hors ligne
Au moment de la reprise du service, le SGBDR interdit l'utilisation des bases de données tant qu'il n'a pas vérifié s'il y avait des transactions en cours.
Si ce n'est pas le cas il rend immédiatement la main et les utilisateurs peuvent travailler. La base est intègre.
S'il y a des transactions non finalisées, elles vont être annulées par un ROLLBACK forcé, et tant que ces ROLLBACK ne sont pas finalisés, alors les utilisateurs ne peuvent pas travailler car la base n'est pas intègre (certaines données sont incohérente). Une fois les ROLLBACK achevés, la basez devient de nouveau intègre et les utilisateurs peuvent désormais s'en servir.
Ceci n'est pas vrai avec PostgreSQL. En cas de ROLLBACK, PostgreSQL a juste à indiquer l'état de la transaction dans l'un des fichiers du répertoire pg_clog. Au moment de la reprise du service, PostgreSQL ne fait que vérifier que le serveur s'est proprement arrêté. Dans le cas contraire, il synchronise journaux de transactions et fichiers de données (autrement dit, il applique sur les fichiers de données les données des journaux de transactions qu'il n'a pas eu le temps de synchroniser avant le crash). Bref, rien à voir avec les ROLLBACK.
Guillaume.
Hors ligne
Pages : 1
