Discussion :

[frp31]

salut,

pgsql 9.2


Mon dump ne peut pas etre restauré la cause :
postgresql prétent qu'il y a plusieurs clefs primaires sur plusieurs tables ce qui bien sur est faux (verification manuelle des datas dans le dump et comparaison à la base existante)

un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
psql:/tmp/Postgresql.20141010.dump.ALL:12068: ERREUR:  les clés primaires multiples ne sont pas autorisées pour la table « a_financer »
psql:/tmp/Postgresql.20141010.dump.ALL:12076: ERREUR:  les clés primaires multiples ne sont pas autorisées pour la table « budget »

le schema sur la base modéle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
postgres=# \d+ budget 
                               Table "public.budget"
   Column    |       Type       | Modifiers | Storage  | Stats target | Description 
-------------+------------------+-----------+----------+--------------+-------------
 ref         | integer          | not null  | plain    |              | 
 debit       | integer          |           | plain    |              | 
 designation | text             |           | extended |              | 
 valeur      | double precision |           | plain    |              | 
Indexes:
    "budget_pkey" PRIMARY KEY, btree (ref)
Has OIDs: no
 
postgres=#postgres=# select ref from budget ;
 ref 
-----
   1
   2
   3
   4
   5
   6
   7
   8
   9
  11
  12
  13
  14
  16
  18
  19
  20
  21
  24
(19 rows)

il n'existe donc bien AUCUN DOUBLON ??? ou j'ai de la merde dans les yeux ??????

[frp31]

C'est bien ce que je craignais.... cet *$#&!§? m'a totallement pété la base destination elle est inutilisable cause de données manquantes dans des tables .... à cause de ces erreur à la noix......

PG_dump inccapable de sauver un format restorable dans une base vide neuve......... pas meme en faisant schema/schema et data/data une table à la fois....même résultat sur les memes tables ....
je comprends plus là.... postgres etait un bon produit jusque là ....

[SQLpro]

Le point faible de PostGreSQL est le stockage en général. Celui des données, comme la génération de sauvegardes. En effet PG n'offre aucun outil pour vérifier si une base est intègre (vérification d'intégrité physique et/ou logique de la base) et pas non plus de processus pour vérifier si une sauvegarde est lisible et logiquement consistante. Pour les sauvegardes, le seul moyen est donc de procéder à une restauration systématique sur un autre serveur (si cela s'effectue bien, la sauvegarde est physiquement correcte) et ensuite de comparer avec l'original, table par table et ligne à ligne si l'on a les mêmes données (vérification logique). Évidemment ce processus est long, couteux et mobilisateur de ressources. C'est pour cela que PG est a éviter dans différentes cas de figure :
1) données sensible
2) base fonctionnant 24h/24 et 7j/7

En comparaison, SQL Server permet de vérifier l'intégrité physique d'une base (DBCC CHECKDATABASE et autres) et l'intégrité logique (DBCC CHECK CONSTRAINT), permet aussi la détection à la volée des écritures (par somme de contrôle calculé sur les données logique des pages), voire des lectures. En outre on peut aussi vérifier la consistance physique d'une sauvegarde lors de l'écriture des données dans le fichier de sauvegarde (BACKUP DATABASE ... WITH CHECKSUM) et la consistance de tout fichier de sauvegarde après écriture ou transport de la sauvegarde (RESTORE ... VERIFYONLY).
C'est pour cela que SQL Server est considéré comme l'un des SGBDR les plus fiable au monde (largement devant Oracle d'ailleurs !)

A lire : http://itic-corp.com/blog/2010/09/sq...se-since-2002/

Personnellement nous avons remplacé PostGreSQL par SQL Server pour le système de gestion des crues du grand delta du Rhone, et ceci fonctionne depuis 2009 sans aucune interruption de serveur ni panne depuis la mise en service.

En outre SQL Server est capable de s'auto corriger en cas de page abimé, si l'on met en place un mirroring ! (détection automatique des pages endommagées sur un serveur et replacement de ces pages par celles équivalentes prise sur l'autre serveur....). A lire : http://msdn.microsoft.com/en-us/library/bb677167.aspx

Évidemment, tout cela coûte un peu de sous ! Mais évite d'en perdre beaucoup parfois.....

A +

PS : j'avais écrit un article soulevant les points faibles du stockage de PG... On m'a vilipendé sur les forums de postgresql pour avoir dévoilé cela ! http://blog.developpez.com/sqlpro/fi...PostGreSQL.pdf

[estofilo]

postgresql prétent qu'il y a plusieurs clefs primaires sur plusieurs tables ce qui bien sur est faux (verification manuelle des datas dans le dump et comparaison à la base existante)

L'erreur en question n'est pas liée aux données mais aux ordres SQL de création de la structure. C'est parce qu'il est interdit de mettre une clef primaire à une table qui en a déjà une.

Autrement dit ette erreur va se produire en faisant par exemple ça, tout simplement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE TABLE truc(id int);
...
ALTER TABLE truc add PRIMARY KEY (id);
...
ALTER TABLE truc add PRIMARY KEY (id);

On pourrait donc avoir cette erreur en jouant un dump 2 fois ou avec un fichier qui contient plusieurs dumps successifs.
Il faudrait regarder les ordres SQL du dump relatifs aux tables en question pour juger.

Personnellement je ne crois pas qu'on arrive à ce genre d'erreur avec une séquence dump/restore faite normalement, et surtout on s'en serait rendu compte, pg_dump 9.2 étant utilisé depuis 2 ans par bien du monde.