Vous n'êtes pas identifié(e).
Pages : 1
Quand je lances des pg_dump, et surtout pg_dump_all, ça bloque toutes modifications des tables tant que l'opération n'est pas terminée.
merci de confirmer est ce normal ?
Hors ligne
Ce n'est ni vrai, ni normal.
Marc.
Hors ligne
ca bloque sur les create table
genre create table ma table as select ...
Si ce n'est pas normal existe t'il un parametre de
configuration
merci!
Hors ligne
Ah, ok.
Oui, effectivement, pg_dump bloque les modifications de structure des tables pendant son exécution. Comme n'importe quel SELECT d'ailleurs. Ce n'est pas désactivable.
Marc.
Hors ligne
comment puis je contourner ???
existe t'il une commande qui annule toutes les transactions
(requete en cours des utilisateurs )
de tous le utilisateurs afin que le pg_dump puisse se lancer automatiquement ?
Comment font les autres utilisateurs qui sauvegarde a 3 heures du matin mais
un utilisateur a lancer une une grosse requete qui est en train de tourner ?
merci
Dernière modification par mich30 (30/05/2011 11:56:43)
Hors ligne
Si la grosse requête ne fait que lire des données ou en écrire, ils n'ont pas de problème.
Si ils lancent des scripts de réorganisation de base en même temps que le dump, ils sont coincés. Ce n'est pas le dump le problème, c'est les modifications de schéma (alter table, vacuum full, reindex…)
Marc.
Hors ligne
1)
donc il vaut mieux faire
create table t1
puis faire des inserts de la grosse table vers t1
plutot
que
create table matablet1 as select * from grossetable
2)
j'ai le autovacum a on ce n'est pas genant ?
merci
Hors ligne
1) si c'est en deux transactions séparées oui, vous tiendrez des verrous moins longtemps (seulement pendant la durée du create table)
2) Non, l'autovacuum libère ses verrous et arrête ses traitements si il se rend compte qu'il gêne.
Marc.
Hors ligne
ok merci
Hors ligne
Comment font les autres utilisateurs qui sauvegarde a 3 heures du matin mais
un utilisateur a lancer une une grosse requete qui est en train de tourner ?
La sauvegarde à chaud est quelque chose de complexe. Par exemple elle n'est toujours pas implémentée sous MySQL.
Pour vous donner un exemple de ce que fais SQL Server qui possède un des algo les plus avancés sur le sujet, il procède de cette manière :
1) avant de démarrer la sauvegarde il met une marque dans le journal de transaction.
2) il sauvegarde les pages de données de manière binaire, sans aucun verrouillage en commençant par les pages les moins modifiées depuis les fichiers et en finissant par les pages les plus modifiées depuis la mémoire (pour calculer cela il conserve des statistiques en mémoire pendant toute la durée de vie du serveur, stats qui sont remise à zéro à chaque sauvegarde)
Les pages vides ou supprimées sont ignorées.
3) il sauvegarde le journal des transactions, depuis la marque qu'il a fait et jusqu'à la fin du journal.
Ainsi, aucun verrouillage ne ralentis la production. Seule les ressources utilisées par le processus de sauvegarde ralentissent globalement le serveur, et notamment les écritures disques des fichiers de sauvegardes.
Comme dans SQL Serveer les CREATE TABLE, ALTER et DROP sont journalisés, aucune transaction n'est perturbée !
Lors de la restaurations, le processus est le suivant :
1) recréation des fichiers originaux vide.
2) lecture des pages et replacement des pages dans les fichiers
3) lecture du journal de transaction et application des transactions validées.
Hélas, PG a encore du boulot pour arriver à ce niveau... Mais comparer à MySQL, y'a pas photo....
A +
Dernière modification par SQLpro (31/05/2011 15:38:40)
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
Wouah ! SQL serveur est vraiment impressionnant, c'est vrai que PostgreSQL c'est un peu limite des fois, hein. Moi je sais pas ce que t'en pense SQLPro mais le mieux se serait d'aller sur un forum dédié à SQL Serveur, parce que là y a plus rien a dire, moi je suis convaincu. En plus ici ils comprennent rien.
Aller à bientôt sur http://forum.sqlserver.fr !
Sérieux ca commence à être gonflant.
Dernière modification par gilles (31/05/2011 16:05:16)
Hors ligne
Je ne voit pas ce qu'il y a de gonflant à comparer des techniques mise en œuvre. Chacune à ses limites, ses avantages et inconvénients.
Il s'agit juste de replacer l'outil à son usage et comprendre ce que font les autres permet de choisir ce qu'il y a de mieux.
Par exemple si la base de données doit en permanence subir des ordres DDL la sauvegarde PG sera un point bloquant.
Il faut donc, soit déporter ses commandes DDL à un moment hors sauvegarde, soit changer de SGBDR.
La plupart des SGBDR, y compris PG et SQL Server s'inspirent de réalisation déjà existantes pour s'améliorer...
Il n'y a donc aucune honte à montrer cela. Ce n'est pas du dénigrement, comme certains intégristes voudrait le faire croire.
PG a fait de grand progrès depuis que je le connais (c'est à dire depuis 1997 - à l'époque PostGres95)...
Et aujourd'hui, depuis la V9, c'est un SGBDR que je recommande pour un grande partie des applications de gestion non critique (c'est à dire la majeure partie)...
Par exemple dans ce post, j'ai commis le crime de défendre PG... http://www.developpez.net/forums/d10844 … se-donnee/
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
Salut,
Je pense que l'objet initial du thread n'est pas de comparer PostgreSQL avec d'autres sur la sauvegarde, mais plutot d'aider mich30 à faire réussir sa sauvegarde. Ce qui me fait dire que vos réponses sont un peu hors sujet, comme souvent, et je comprends la fatigue de gilles.
Si vous tenez vraiment à convertir des utilisateurs à SQL Server, bon courage, la plupart des membres actives ici sont de fervent(e)s défenseur(e)s du Logiciel Libre et de l'Open Source. Dans ce cas, ouvrez des threads séparés plutôt que de perturber les fils existants.
Merci d'avance.
PS: tiens, la sauvegarde que vous décrivez ressemble beaucoup à la sauvegarde PITR de PostgreSQL (http://docs.postgresql.fr/9.0/continuous-archiving.html), si vous voulez continuer sur ce sujet, lancez un fil à côté 
Hors ligne
Petite précision historique; en 1997 il s'agissait déjà de PostgreSQL 6.0, enfin ca n'a pas été trop dur vu qu'on est passé directement de la version 1.x a la version 6.x :-) C'est vrai qu'à l'époque on était pas nombreux.
Hors ligne
PS: tiens, la sauvegarde que vous décrivez ressemble beaucoup à la sauvegarde PITR de PostgreSQL (http://docs.postgresql.fr/9.0/continuous-archiving.html), si vous voulez continuer sur ce sujet, lancez un fil à côté
C'est normal, les mécanismes des journalisation des transactions des SGBDR sont tous basés sur le même algo de base : ARIES (sauf MySQL), suite aux travaux de Gray et Bernstein sur le sujet, vers la fin des années 70...
A lire :
http://portal.acm.org/citation.cfm?id=128770
http://www.cs.uwaterloo.ca/~david/cs448/aries-mohan.pdf
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
*BLONG* Raté... Un autre fil, c'est pourtant pas dur ! De mon coté je m'arrete là sur ce fil, vu votre mauvaise volonté et votre attitude.
Hors ligne
Pages : 1
