Merci vraiment pour votre éclairage et votre aide. C'était effectivement ça la difficulté. J'ai pu grâce à vos orientations importer tous les fichiers.
Bien à vous,
Stephane
]]>Sinon si c'est pour copier d'une base access vers postgres, vous pouvez aussi demander à access de vous produire un CSV. COPY peut importer le format CSV directement, et vous serez sûr de garder vos caractères supplémentaires
]]>Merci pour votre retour, vous avez effectivement bien saisi la question et m'avez apporter une confirmation. La deuxième migration passera donc par un pg_dump/pg_restore
Geoffroy
]]>La grosse limitation concerne les versions de la libc / ICU. En cas de version différentes, il est possible (voire probable en fonction des versions présentes et des collations utilisées) que les index portant sur des données collationnables soient corrompues. La solution consiste à faire un reindex de tous les index index impactés, mais même faire un pg_upgrade puis réindexer tous les index (puis faire le vacuum/analyze préconisé par pg_upgrade) devrait être beaucoup moins long que tout restaurer à coup de pg_dump / pg_restore.
]]>Si vous n'avez rien changé pourquoi la moitié des logs à l'air d'être dans un encodage différent ?
Sinon, les logs indique que le serveur a été arrêté explicitement. On dirait cependant que 2 instances étaient démarrées sur le même répertoire de données, est-ce le cas ?
D'après ce que j'ai trouvé la solution est d'utiliser pg_resetlogx
Non, pg_resetxlog / pg_resetwal n'est JAMAIS une solution. Cet outil permet de forcer le démarrage de l'instance malgré des problèmes en forçant une corruption définitive des données.
]]>La migration a bien fonctionné je vous remercie.
Pourquoi migrer vers PG13 et pas PG15 directement ?
Tout simplement parce que notre logiciel applicatif SIG n'est compatible uniquement jusqu'à la 13 pour le moment.
Léandre
]]>SELECT ind.name as "Name"
, ind.sex as "Sex"
, S1.date as "First observation"
, S1.troop_ID as "Troop FirstObs"
, S1.present as "Present FirstObs"
, S2.date as "Last observation"
, S2.troop_ID as "Troop LastObs"
, S2.present as "Present LastObs"
FROM individuals as ind, sightings S1, sightings S2
WHERE
(
S1.individual_ID = ind.individual_ID
AND S2.individual_ID = ind.individual_ID
AND S2.individual_ID = S1.individual_ID -- ajout de la transitivité au cas où
)
AND NOT EXISTS
(SELECT 1 FROM sightings as S1b WHERE S1.date > S1b.date and S1.individual_ID = S1b.individual_ID )
AND NOT EXISTS
(SELECT 1 FROM sightings as S2b WHERE S2.date < S2b.date and S1.individual_ID = S2b.individual_ID )
order by ind.name
, S1.date
, S2.date
;
Merci
]]>psql [options] -c 'COPY nomtable TO STDOUT' > export-table.sql
Si la table est déjà créée dans la base cible, le contenu peut se recharger dans cette base avec la commande en sens inverse:
psql [options] -c '\copy nomtable FROM export-table.sql'
Si la structure de la table n'existe pas déjà dans la base cible et qui faut l'extraire au préalable de la base source, c'est faisable avec
pg_dump [options] -s -t nomtable > structure-table.sql
qui est utilisable avec un compte en lecture seule sans droit d'accès aux séquences liées à la table.
]]>faut-il appliquer toutes les recommandations des différentes releases notes de 10.2 à 10.20 ?
Oui. Sauf cas exceptionnel précisé dans les notes, une mise à jour mineure remplace juste les exécutables, et ne fait aucune autre action en dehors de ça sur aucune des bases. Donc toutes les actions préconisées à faire manuellement restent à faire dans le cas où on saute des m.a.j. intermédiaires.
]]>Quoi qu'il en soit, le programme dit bien qu'aucun package n'est trouvé. De plus, quelle version d'ora2pg utilisez-vous ? Ne connaissant rien à oracle, difficile de dire si cela peut venir de la configuration ou pas (par exemple mauvais utilisateur ou autre). Je serais vous j'ouvrirais une issue sur le dépot github : https://github.com/darold/ora2pg
]]>psql:data.sql:46131: error: invalid command \N
Généralement cette erreur arrive après d'autres erreurs qui indiquent que la table n'a pas pu être créée, ou bien s'il est créée, que COPY ne peut pas écrire dedans (pas les droits, read-only, etc...)
A partir du moment où le COPY part en erreur, les données en dessous qui devaient être copiées dans la table sont prises comme des commandes et ça génère un déluge d'erreur. Il faut remonter au tout début des erreurs pour avoir les messages intéressants.
]]>