Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'utilise ora2pg pour exporter les données de ma base Oracle (11.2) vers ma base PG (13) en mode "TYPE COPY". L'outil génère les données de toutes les tables (plus de 1600) dont la plus volumineuse génère un fichier de 25Go.
Par contre il y a une table dont le fichier est incomplet, l'export s'arrête toujours au même endroit, environ 300.000 lignes sont présentes dans le fichier généré (25Mo) sur les plus de 600.000 que comporte la table. J'ai essayé plusieurs combinaisons de configuration pour relancer l'export de cette table uniquement (qui ne comporte aucune spécificité supplémentaire par rapport aux autres), et j'ai systématiquement le même résultat. Lorsque j'exporte le contenu de la table avec un client Oracle (toad ou datagrip), la table est alors bien complète.
Voici le log d'exécution :
[2021-03-04 13:05:28] [1] Scanning table ARTICLEFOURNISSEURS (604380 rows)...
[2021-03-04 13:05:28] ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1
[2021-03-04 13:05:28] NLS_LANG = american_AMERICA.UTF8
[2021-03-04 13:05:28] NLS_NCHAR = AL32UTF8
[2021-03-04 13:05:28] Trying to connect to database: dbi:Oracle:host=localhost;sid=DEVARI
[2021-03-04 13:05:28] Isolation level: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
[2021-03-04 13:05:28] Creating new connection to Oracle database to export table ARTICLEFOURNISSEURS...
[2021-03-04 13:05:28] Looking how to retrieve data from ARTICLEFOURNISSEURS...
[2021-03-04 13:05:28] DEGUG: Query sent to Oracle: SELECT "ID_ARTICLE","ID_ARTICLEFOURNISSEUR","ID_FOURN","REF_FOURN","DESIGNATION","DELAI_LIVR_MOYEN","QTE_ACHAT","PRIX_ACHAT_BASE","POURC_REM","ID_DEVISE","ID_DIVISION","AF_CHK_DEFAULT","AF_CHK_UPDATE_ARTICLE","AF_DEFAULTCOPYFORPK","AF_ID_WARRANTY_UW","AF_TRANSLATION_01","AF_QTY_AVAILABLE","AF_AVAILABILITY","AF_AVAILABILITY_DATE" FROM "TESTUSER"."ARTICLEFOURNISSEURS" a
[2021-03-04 13:05:28] Data type TYPE_ENTRY_TRANSLATION_TABLE is not native, searching on custom types.
[2021-03-04 13:05:28] ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1
[2021-03-04 13:05:28] NLS_LANG = american_AMERICA.UTF8
[2021-03-04 13:05:28] NLS_NCHAR = AL32UTF8
[2021-03-04 13:05:28] Trying to connect to database: dbi:Oracle:host=localhost;sid=DEVARI
[2021-03-04 13:05:28] Isolation level: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
[2021-03-04 13:05:28] Found Type: TYPE_ENTRY_TRANSLATION_TABLE
[2021-03-04 13:05:28] Looking inside custom type TYPE_ENTRY_TRANSLATION_TABLE to extract values...
[2021-03-04 13:05:28] ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1
[2021-03-04 13:05:28] NLS_LANG = american_AMERICA.UTF8
[2021-03-04 13:05:28] NLS_NCHAR = AL32UTF8
[2021-03-04 13:05:28] Trying to connect to database: dbi:Oracle:host=localhost;sid=DEVARI
[2021-03-04 13:05:28] Isolation level: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
[2021-03-04 13:05:28] Found Type: TYPE_ENTRY_TRANSLATION
[2021-03-04 13:05:28] Can not found subtype for TYPE_ENTRY_TRANSLATION_TABLE into code: TYPE TYPE_ENTRY_TRANSLATION_TABLE IS TABLE OF TYPE_ENTRY_TRANSLATION;
[2021-03-04 13:05:28] DEBUG: cloning Oracle database connection.
[2021-03-04 13:05:28] Fetching all data from ARTICLEFOURNISSEURS tuples...
[2021-03-04 13:05:31] DEBUG: Formatting bulk of 100000 data (real: 100001 rows) for PostgreSQL.
[2021-03-04 13:05:37] DEBUG: Creating output for 100000 tuples
[2021-03-04 13:05:37] Dumping data from ARTICLEFOURNISSEURS to file: tmp_ARTICLEFOURNISSEURS_copy_spe.sql
[2021-03-04 13:05:37] Extracted records from table ARTICLEFOURNISSEURS: total_records = 100001 (avg: 11111 recs/sec)
[2021-03-04 13:05:40] DEBUG: Formatting bulk of 100000 data (real: 100001 rows) for PostgreSQL.
[2021-03-04 13:05:46] DEBUG: Creating output for 100000 tuples
[2021-03-04 13:05:46] Dumping data from ARTICLEFOURNISSEURS to file: tmp_ARTICLEFOURNISSEURS_copy_spe.sql
[2021-03-04 13:05:46] Extracted records from table ARTICLEFOURNISSEURS: total_records = 200002 (avg: 11111 recs/sec)
[2021-03-04 13:05:49] DEBUG: Formatting bulk of 100000 data (real: 100001 rows) for PostgreSQL.
[2021-03-04 13:05:55] DEBUG: Creating output for 100000 tuples
[2021-03-04 13:05:56] Dumping data from ARTICLEFOURNISSEURS to file: tmp_ARTICLEFOURNISSEURS_copy_spe.sql
[2021-03-04 13:05:56] Extracted records from table ARTICLEFOURNISSEURS: total_records = 300003 (avg: 10714 recs/sec)
[2021-03-04 13:05:58] ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1
[2021-03-04 13:05:58] NLS_LANG = american_AMERICA.UTF8
[2021-03-04 13:05:58] NLS_NCHAR = AL32UTF8
[2021-03-04 13:05:58] Trying to connect to database: dbi:Oracle:host=localhost;sid=DEVARI
[2021-03-04 13:05:58] Isolation level: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
... (séquences)
[2021-03-04 13:06:03] Total time to export data from 1 tables (0 partitions, 0 sub-partitions) and 604380 total rows: 35 wallclock secs ( 0.05 usr 0.14 sys + 27.75 cusr 0.55 csys = 28.49 CPU)
[2021-03-04 13:06:03] Speed average: 17268.00 rows/secUne idée sur ce qui peut causer ce problème ?
Merci
Dernière modification par Hakkai94 (05/03/2021 12:18:01)
Hors ligne
Si ce n'est pas un probleme d'espace disque qui empêcherai l'extraction complète des données de la table ou un coup de l'OOM killer parce que le DATA_LIMIT est trop haut, c'est possiblement parce qu'il il a un problème de reconnaissance d'un type personnalisé:
[2021-03-04 13:05:28] Found Type: TYPE_ENTRY_TRANSLATION
[2021-03-04 13:05:28] Can not found subtype for TYPE_ENTRY_TRANSLATION_TABLE into code: TYPE TYPE_ENTRY_TRANSLATION_TABLE IS TABLE OF TYPE_ENTRY_TRANSLATION;Pour ce cas malheureusement il y a un patch a faire dans Ora2Pgg.
Pour ce qui est de la valeur de DATA_LIMIT, 100000 est beaucoup trop élevé au vue de la vitesse moyenne d'export: Speed average: avg: 11111 recs/sec
Une valeur de 15000 serait plus adaptée. Toute excèdent se retrouve occuper de la mémoire pour rien. Pour aller plus vite pour l'extractionn d'une table il faut à minima -j 2 et -J N en fonction du nombre de cpu disponible (-j x -J). N= 2 par exemple si il y a 4 cpu. Mais dans ce cas DATA_LIMIT reste toujours à 10 ou 15000.
Hors ligne
Bonjour,
Ce type est utilisé dans plein d'autres tables, ça n'a posé aucun problème, j'ai un traitement qui va ensuite les traiter. On peut voir dans le début du fichier généré que des lignes ayant ce type non null ont été correctement exportées :
COPY articlefournisseurs (id_article,id_articlefournisseur,id_fourn,ref_fourn,designation,delai_livr_moyen,qte_achat,prix_achat_base,pourc_rem,id_devise,id_division,af_chk_default,af_chk_update_article,af_defaultcopyforpk,af_id_warranty_uw,af_translation_01,af_qty_available,af_availability,af_availability_date) FROM STDIN;
886353 903725 814 2000100203811 2000100203811 6 1 635.59 0 2 2 \N 0 903725 2 \N \N \N \N
886354 903726 2262 2000100203835 2000100203835 6 1 42.52 0 2 2 on 1 \N 2 \N \N \N \N
886355 903727 2262 2000100203842 2000100203842 6 1 6.8 0 2 2 on 1 \N 2 \N \N \N \N
886356 903728 2246 2000100203866 2000100203866 6 1 440.58 0 2 2 on 1 \N 2 \N \N \N \N
886357 903729 2123 2000100203873 2000100203873 6 1 9.4 0 2 2 on 1 \N 2 \N \N \N \N
886358 903730 703 2000100203941 2000100203941 6 1 394.73 0 2 2 on 1 \N 2 ("(fr,2000100203941)") \N \N \N
886359 903731 814 2000100203958 2000100203958 6 1 390.29 0 2 2 on 1 \N 2 \N \N \N \N
886360 903732 814 2000100204030 2000100204030 6 1 412.72 0 2 2 \N 1 903732 2 \N \N \N \N
886361 903733 2123 2000100204177 2000100204177 6 1 7.34 0 2 2 on 1 \N 2 \N \N \N \NJ'utilise la valeur DATA_LIMIT à 100000 pour les grosses tables (>1Go) qui ont été exportées sans problème. Je viens de relancer l'export avec 15000, et ça plante à nouveau au delà de 300000 lignes :
[2021-03-05 09:18:11] DEBUG: Creating output for 15000 tuples
[2021-03-05 09:18:11] Dumping data from ARTICLEFOURNISSEURS to file: tmp_ARTICLEFOURNISSEURS_copy_spe.sql
[2021-03-05 09:18:11] Extracted records from table ARTICLEFOURNISSEURS: total_records = 285019 (avg: 10962 recs/sec)
[2021-03-05 09:18:12] DEBUG: Formatting bulk of 15000 data (real: 15001 rows) for PostgreSQL.
[2021-03-05 09:18:13] DEBUG: Creating output for 15000 tuples
[2021-03-05 09:18:13] Dumping data from ARTICLEFOURNISSEURS to file: tmp_ARTICLEFOURNISSEURS_copy_spe.sql
[2021-03-05 09:18:13] Extracted records from table ARTICLEFOURNISSEURS: total_records = 300020 (avg: 10715 recs/sec)
[2021-03-05 09:18:14] ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1
[2021-03-05 09:18:14] NLS_LANG = american_AMERICA.UTF8
[2021-03-05 09:18:14] NLS_NCHAR = AL32UTF8Ce n'est pas non plus un problème d'espace disque, la partition de 500Go n'est remplie qu'à 34%.
Hors ligne
Rebonjour,
J'ai résolu mon problème. C'était bien le type TYPE_ENTRY_TRANSLATION_TABLE qui posait problème : l'export plantait lorsque cette colonne était non nulle, mais sans donnée dans le tableau. J'ai corrigé mes données avec cette requête :
update ARTICLEFOURNISSEURS SET AF_TRANSLATION_01=null WHERE ID_ARTICLEFOURNISSEUR IN (
SELECT ID_ARTICLEFOURNISSEUR FROM ARTICLEFOURNISSEURS,TABLE (AF_TRANSLATION_01)(+) WHERE AF_TRANSLATION_01 IS NOT NULL AND LANG IS NULL
)Comme ça plantait toujours au même endroit, je me suis dit que le problème venait peut-être d'une donnée en particulier. J'ai donc exporté par lot de 10 avant de trouver le lot qui n'était pas exporté et j'ai vu cette donnée étrange. Ce qui est curieux, c'est que la ligne est bien exportée en mettant DATA_LIMIT à 1 (j'avais alors utilisé le paramètre REPLACE_QUERY pour ne sélectionner que les 10 lignes en question.
Dernière modification par Hakkai94 (05/03/2021 12:19:23)
Hors ligne
Merci pour le retour, j'essayerai de reproduire ce cas pour corriger le problème dans Ora2Pg.
Hors ligne
Pages : 1