Vous n'êtes pas identifié(e).
Pages : 1
Finalement, je n'ai pas réussi à exécuter pgloader, il y avait plusieurs messages d'erreur pour lesquels mes recherches sur Google n'ont pas abouti. Ensuite j'ai testé l'ETL Talend, mais vu la volumétrie très importante des données à charger, le temps d'exécution n'était pas du tout raisonnable et en plus une bonne partie de mes données ayant le bon format et respectant les contraintes d'intégrité, n'étaient même pas chargées dans la base (pourquoi? aucune idée).
J'ai fini donc par développer en Python ma propre solution en passant par psycopg2. J'utilise la méthode copy_from qui ne fait qu'appeler la commande COPY de PostgreSQL et c'est très intéressant car cela veut dire que l'on bénéficie de la performance de la vraie commande COPY. Sauf que, dans le code que j'ai développé, je fait ça dans un bloc try ... catch ... et s'il y a une exception ( = échec du chargement), à ce moment-là dans une boucle while, je découpe le fichier par paquets (= un fichier intermédiaire/temporaire que le programme crée pendant l'exécution) de 100 000 ligne et je continue le chargement en récupérant à chaque fois les numéros de lignes rejetées (cette information se trouve dans le message d'exception lancée par COPY) et en sautant ces lignes problématiques dans ces fichiers temporaires/intermédiaires, j'arrive à charger le reste de mes données (d'ailleurs il me semble que c'est un peu le même principe avec pgloader). Pendant l'exécution du programme, les numéro de lignes rejetées sont sauvegardés dans une liste ce qui me permet à la fin, de faire un export de l'ensemble des lignes problématique dans un fichier.
Voilà, c'était juste pour confirmer, dans le cas où ça pourrait intéresser ceux et celles qui ont eu mon problème, qu'effectivement Psycopg2 avec un peu de développement est en effet une solution (parmi d'autres).
Je remercie encore une fois pour les commentaires et suggestions.
Merci beaucoup pour votre aide. Je vais d'abord faire un test sur une machine virtuel Linux (virtualbox) sur mon ordinateur pour faire un premier test avec pgloader. J'écrirai le résultat.
Bonjour à tous,
Je voulais poser une question concernant l'utilisation de la commande COPY (à partir d'une session psql).
Environnement:
OS: Windows 10 (64 bits)
PostgreSQL: 10J'utilise cette commande afin de charger des fichier CSV très volumineux dans un certain nombre de tables dans ma base. Le problème c'est que depuis plusieurs jours, apparemment il y a des données erronées qui sont rejetées par les contraintes d'intégrité définies sur les tables et dès le premier rejet, PostgreSQL fait un ROLLBACK complet. C'est-ce qu'il est d'ailleurs écrit dans la documentation en ligne:
https://www.postgresql.org/docs/10/sql-copy.html
COPY stops operation at the first error. This should not lead to problems in the event of a COPY TO, but the target table will already have received earlier rows in a COPY FROM. These rows will not be visible or accessible, but they still occupy disk space. This might amount to a considerable amount of wasted disk space if the failure happened well into a large copy operation. You might wish to invoke VACUUM to recover the wasted space.
Je n'ai pas la possibilité de nettoyer les fichiers avant le chargement dans PostgreSQL et d'ailleurs ce n'est pas le but. Au contraire, nous souhaitons pouvoir rassembler les lignes rejetées en un seul fichier et l'envoyer à l'équipe de développement, qui est responsable de la production de ces fichiers, afin de leur montrer le problème et donc faciliter/accélérer le travail d'analyse de ces anomalies.
Avec Oracle, je n'aurai aucune difficulté, le programme SQL*Loader permet de récupérer facilement les lignes rejetées dans un fichier, tout en continuant à charger les données ayant le bon format dans les tables. Comment je peux faire pour avoir le même résultat sur PostgreSQL? C'est-à-dire au lieu d'un ROLLBACK, écrire les données rejetées dans un fichier? Le problème me paraît un grand classique notamment dans le cadre des missions de la reprise de données où parfois on trouve un peu tout dans les fichiers. Je serai vraiment étonné si une solution similaire/équivalent à SQL*Loader n'existe pas pour régler le même problème sur PostgreSQL.
Merci d'avance,
Ok. Merci de l'avoir confirmé.
Bonjour,
Je voulais poser une question concernant les plans d'exécution dans PostgreSQL. En fait au chapitre 14.1 de la documentation en ligne (14.1. Using EXPLAIN) il y a la présentation des éléments liés à ce sujet comme par exemple différents types de scan et les coûts, etc.
Ce que je voulais savoir, c'est l'ordre de la lecture de l'arbre d'un plan d'exécution qui est imprimé sous forme d'une table quand l'on fait un EXPLAIN. Sous oracle, voici comment je procède:
Dans la table du plan d'exécution, je regarde la ligne la plus décalée à droite et s'il y en a plusieurs qui sont au même niveau le plus décalées à droite alors je prends la première (en lisant les lignes du haut vers le bas). J'évalue l'opération. Ensuite j'évalue son parent et je répète exactement la même procédure jusqu'à épuiser l'ensemble des opérations (= noeuds de l'arbre du plan d'exécution) et arriver finalement à la première ligne qui est la requête principale.
Ma question est donc la suivante: est-ce que la lecture du plan d'exécution sous PostgreSQL, se fait de la même manière décrite ci-dessus? Car dans la documentation je n'ai rien trouvé concernant ce sujet.
Merci d'avance,
Pages : 1