Dump en erreur - Table m_document

Support
1

Bonjour,

Nous avons tester la création d’un dump sur une BD postgres pour copier les données d’un environnement de prod vers une recette.
Nous avons une erreur lié à la table m_document. Ci-dessous la trace :
[08:29] NJIKAM Jean (renexter)
pg_dump: Dumping the contents of table “m_document” failed: PQgetResult() failed.

[08:34] NJIKAM Jean (renexter)
public | m_document | table | mla_simplicite_01_adm | 2166 MB |

[08:34] NJIKAM Jean (renexter)

mla_simplicite_01_db=> \d+ m_document Table “public.m_document” Column | Type | Collation | Nullable | Default | Storage | Stats target | Description ---------------±----------------------------±----------±---------±--------±---------±-------------±------------ row_id | integer | | not null | | plain | | created_dt | timestamp without time zone | | not null | | plain | | created_by | character varying(100) | | not null | | extended | | updated_dt | timestamp without time zone | | not null | | plain | | updated_by | character varying(100) | | not null | | extended | | dbd_path | text | | | | extended | | dbd_name | character varying(255) | | | | extended | | dbd_vers | integer | | | | plain | | dbd_resp_id | integer | | | | plain | | dbd_index_id | integer | | | | plain | | dbd_object_id | integer | | | | plain | | dbd_field_id | integer | | | | plain | | dbd_row_id | integer | | | | plain | | dbd_size | integer | | | | plain | | dbd_mime | character varying(100) | | | | extended | | dbd_content | bytea | | | | extended | | dbd_thumbnail | bytea | | | | extended | | dbd_index | text | | | | extended | | Indexes: “m_document_pkey” PRIMARY KEY, btree (row_id) “m_document_fk1” btree (dbd_index_id) “m_document_fk2” btree (dbd_object_id) “m_document_fk3” btree (dbd_resp_id) “m_document_fk4” btree (dbd_field_id) “m_document_idx1” btree (dbd_name) “m_document_uk” btree (dbd_path)

[08:35] NJIKAM Jean (renexter)
mla_simplicite_01_db=> select count(*) from m_document; count ------- 867 (1 row)

Notre pb est-il lié au volume de données (je ne sais si ces logs sont suffisant pour vous) ?
Cette table peut elle être ignorée dans le processus du dump, ou contient elle des éléments propre au fonctionnement de Simplicité ?

Merci pour votre retour.
Jean-Baptiste

2

Bonjour,

La table m_document est vitale, elle contient tous les documents (des champs Document).

  • Si vous êtes en DOC_DIR = BLOB les documents sont des blob dans cette table (donc énorme).
  • Sinon le dbdoc est stocké sur disque dans la webapp et il faut le sauvegarder en même temps que la base, la table ne contient que les paths relatifs au DOC_DIR.

Je ne comprends la log fournie, ni la commande PG lancée…
La question est plus pour votre DBA, car il doit y avoir des subtilités pour les dumps de BLOB.

3

Bonjour,
Nous rencontrons des soucis pour exporter cette table m_document.

pg_dump: Dumping the contents of table “m_document” failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid memory alloc request size 1927432653
pg_dump: The command was: COPY public.m_document (row_id, created_dt, created_by, updated_dt, updated_by, dbd_path, dbd_name, dbd_vers, dbd_resp_id, dbd_index_id, dbd_object_id, dbd_field_id, dbd_row_id, dbd_size, dbd_mime, dbd_content, dbd_thumbnail, dbd_index) TO stdout;

De ce que nous voyons sur divers forum, c’est signe que certaines données sont corrompues. Notre expert Simplicité nous informe que c’est déjà arrivé sur d’autres projets Simplicité ici chez Renault.

L’idée serait donc de supprimer ces lignes et de refaire l’export.
C’est par contre très délicat vu la criticité de la table.

Nous avons besoin de votre support pour éventuellement avoir des best-practices sur ce problème.

4

Bonjour,

Quelle commande lancez vous exactement, quelle est la taille de la table ? on dirait que votre export se fait en mémoire et dépasse 2Go. Il faut exporter dans un fichier ou augmenter la taille mémoire.

Nous n’avons pas de problème particulier à exporter une base POSTGRESQL contenant des BLOB via la commande suivante :

pg_dump -h $DB_HOST -p $DB_PORT -U $DB_USER $DB_NAME --no-owner --clean > $DB_DIR/simplicite-postgresql.dmp

L’option -b (export des blob) étant vraie par défaut.

5

Quelle sont les logs côté serveur PG ? s’il y a des données corrompues, cela devrait également apparaitre et c’est à donner à votre DBA.

En googlant votre erreur, on trouve beaucoup de littérature sur les records cassés / à supprimer:

6

Bonjour,
Merci du retour.
Notre DBA travaille sur une solution comme celle indiquée sur le forum indiquée. On a l’impression qu’il y a beaucoup de lignes à supprimer manuellement. Est ce vraiment la bonne façon de faire? Purger manuellement tous les lignes en erreur jusqu’à ce qu’on puisse faire l’export?

7

Pouvez vous voir de quels documents il s’agit ? si oui vous pourrez les cibler et les supprimer en masse (via les path…).

Comme indiqué nous n’avons aucun pb de cette ordre. Cela vient donc de votre façon d’utiliser et d’exploiter votre base de données PostgreSQL sur des BLOB.

  • purger tous les imports XML / supervision des imports si ce ne sont que des documents liés à des imports “cassés”,
  • vous pouvez écrire un script qui clean la base comme indiqué sur le post de stackoverflow,
  • si ce sont d’autres documents non importants et liés à des Fields métier de vos objets, écrivez un script qui purge vos tables métier et les documents liés (jointure de la colonne qui référence
    un m_document.row_id) avant l’export,
  • Si ce sont des documents systèmes, vous devrez restaurer une sauvegarde ou repartir d’une (nouvelle) instance qui fonctionne, car là on ne peut pas prédire les effets de resources manquantes sur la plateforme (beaucoup de 404 sur le client, images et scripts perdus…).
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.