Forums PostgreSQL.fr

Merci pour ces quelques précisions.

Entre ces 2 dates, le serveur a été arrêté pour une maintenance (upgrade hardware).

Est il possible que ce problème vienne de là et y a t il une commande pour éviter ce genre de problème avant l'arrêt du serveur ?

edit : toutes les séquences n'ont pas de cache (valeur 1), ce comportement reste assez étrange.

Autant pour moi, j'ai lu un peu rapidement et ma réponse passait par la simplicité.

D'après les messages d'erreurs que vous avez, c'est une erreur de propriété du schéma pour résoudre cela, vous pouvez essayer la commande suivante :

ALTER SCHEMA [nom du schema] OWNER TO userB;

Cela devrait résoudre votre problème puisqu'ensuite le schéma appartiendra au userB et le supprimer ne posera plus de problème.

La base de destination à sans doute été crée avec le mauvais user; je suppose que le propriétaire de la base n'est pas userB.

Je suis plutôt d'accord avec gleu, c'est complexe et surtout au niveau perfs tu seras loin du compte.
Ca dépend également du type de dump que tu veux faire : sauvegarde intégrale de ta base ou simple extraction des données de tables ?

Bonjour,

C'est pas évident de répondre comme ca. Ca dépend de la puissance du serveur employé, de la vitesse des disques, de la quantité de RAM, de se qui tourne au moment du dump, etc....

Si tu pouvais être plus précis sur la configuration employée par ton serveur qui héberge ta BDD Oracle, on pourrait éventuellement te répondre .

Bonjour,

déjà tu demandes de faire du dump de masse via pg_admin .... ca va être laborieux.
Pour faire le dump de tes tables je vais t'indiquer la ligne de commande à exécuter dans un shell windows car les options passées en paramètres par défaut dans pg-admin son trop limitées et les modifier n'est pas pratique.

Il faut que tu te déplaces dans le dossier où se trouve pg_admin (c'est pour avoir la commande pg_dump.exe si cette commande est dans le classpath de ton serveur alors pas besoin de se déplacer).
Ensuite,exécutes la commande suivante :

pg_dump -i -c -h [adresse de l'hote] -U [utilisateur] -F p -t [nom table1] -t [nom table2] etc. -d -f [chemin et nom du fichier de sauvegarde] [nom de la base]

Petite explication des options employées :
-i : exécute le dump même si les versions de pg_dump et de la base sont différentes.
-c : (clean) supprime la table si elle existe, sinon une erreur est envoyée.
-F p : force le format a employer, p pour plain text (il me semble que c'est le format par défaut mais j'en suis pas sur).
-t : pour dumper une table spécifique avec les données.
-d : va mettre les données de ta table sous forme d'insert dans ton fichier, si cette option n'est pas mise, les données seront restaurées en utilisant COPY.
-f : signifie fichier.

TRUNCATE sert effectivement à vider les tables.

Maintenant que tu as tes fichiers, il te suffit de les ouvrir sous pd admin et de les excécuter.

Attention, si tu drop une table qui n'existe pas sous pg_admin ca annulera la transaction entière, alors qu'en utilisant psql sur le serveur ca ignore juste la commande qui ne fonctionne pas.

Les triggers existent bien dans la base de pé-prod puisque sous pgadmin un "activer tous les triggers sur cette table" fonctionne.
P-e suis je tombé sur un bug... toujours est il qu'au lieu de chercher encore pendant 3 heures, voici une fonction qui active tous les triggers présents dans une base.
Testée et approuvée .

create or replace function public.f_enable_all_triggers()
returns integer as
$$
declare
l record;
requete character varying;
nbt integer;

begin
nbt := 0;

for l in select trigger_schema, trigger_name, event_object_table 
	from information_schema.triggers where trigger_schema != 'pg_catalog' loop

	requete := 'alter table ' || l.trigger_schema || '.' || l.event_object_table;
	requete := requete || ' enable trigger ' || l.trigger_name || ';';

	raise notice '%', requete;

	execute requete;
	
	nbt := nbt + 1;
	
end loop;

return nbt;

end;

$$
LANGUAGE 'plpgsql' VOLATILE
  COST 100;

Il faut croire que non, j'en ai fait l'expérience suite à une remarque d'un utilisateur.

Dans la base d'origine, les triggers sont activées après réplication sur le serveur de pré-prod, ils sont tous désactivés : ca pose problème puisque l'intégrité des données filtré par ces triggers n'est plus respecté.

Comme dit plus haut, j'ai essayé avec et sans l'option disable-triggers. Cela ne change rien, avec l'option -clean ca va être difficile de désactiver quelque chose qui n'existe plus au moment de la restauration.

edit : cela a un p-e un lien mais la version de pg_dump et en 8.1 et la base en 8.3 et je suis oligé d'ajouter l'option ignore pour réaliser le dump.