Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
j'ai trouvé, il faut jouer sur les paramètres DATA_LIMIT et LONGREADLEN dans le fichier de configuration.
@++
Bonjour,
j'ai lancé la migration d'une base sous Oracle vers PostgreSQL. Tout s'exécute bien à l'exception des valeurs de type LOB.
J'obtiens le type de message d'erreur suivant
DBD::Oracle::st fetchall_arrayref failed: ERROR fetching field 3 of 5. LOB value truncated from 2946765 to 1048576. DBI attribute LongReadLen too small and/or LongTruncOk not set [for Statement "SELECT "COL_ID","COL_TYPEMIME","COL_DOCUMENT",to_char("COL_DATECREATION", 'YYYY-MM-DD HH24:MI:SS.FF'),"COL_DESCRIPTION" FROM MYSCHEMA.TABBLE_TOTO t"] at /usr/lib/perl5/site_perl/5.8.8
/Ora2Pg.pm line 7353.
Auriez-vous une idée pour résoudre ce problème ?
Merci
Bonjour,
J'ai plusieurs questions concernant les fichiers de log PostgreSQL.
- Quand plusieurs clients (des centaines) déclenchent une écriture dans les fichiers de log du database cluster, l'écriture se fait-elle en parrallèle ou en file ?
- Vous est-il arrivé que les fichiers de log (pg_log) deviennent corrompus suite à une utilisation massive de l'instance PostgreSQL ?
- Est-il possible de paramétrer postgresql.conf afin d'avoir un fichier de log par base ?
Cordialement
Bonjour gleu,
oui c'est la solution,
EXEC SQL SET CLIENT_ENCODING TO "ISO-8859-1"
Et là : bim, ça marche quelque soit l'encodage de la base.
C'est puissant PostgreSQL, j'en suis bluffé !
Bonjour,
- J'ai une base en UTF8.
- Je récupère les données UTF8 de ma base via ECPG (programmes C)
- Je souhaite convertir ces données UTF8 en ISO-8859-1
Questions :
- Est-il possible de les faire avec les commandes ECPG i.e. quelque chose comme :
EXEC SQL CONNECT TO maBase USER monUser USING monPassword [ WITH ENCODING ISO-8859-1 ]
- ou en C ? j'ai cherché sur le web mais vraiment pas de réponse. (iconv ? not working)
Exemple :
si je fais un printf("\n mon libellé => %s", variable_hôte ), j'obtiens :
mon libellé => Régulier.
Si quelqu'un maîtrise le sujet, je suis ouvert à ses lumières :=)
Bonjour gleu,
Merci pour ta réponse. En fait, lorsque j'ai migré mes bases vers Postgres, ça m'a paru bizarre que 2 d'entre elles doublent de volume alors que les autres avaient sensiblement perdu en poids. Je pense que je vais simplement supprimé le cluster de base Postgres, et refaire l'import pour voir si cela persiste (puisqu'au départ je n'ai pas eu ce doublage de volume pour ces 2 bases.)
voilà. ^^
Ok,
je vais reformuler la question autrement, vous-est il déjà arrivé de faire un
create database via un psql -file.sql, puis un
drop database , et ensuite un
restore database avec psql -file.sql (le même fichier sql d'origine)
et obtenir une augmentation significative de la taille de sa base ?
cad qu'on a pas la même volumétrie au début et après un restore ?
En principe, je ne pense pas mais pourrait-il exister un cas marginal comme celui-ci ?
Salut,
Ben tout simplement comme cela :
côté Postgres, \l+ dans psql ou du -sh PGDATA/base
côté Informix, du -sh /rep_bases/
Bonjour,
je migre des bases depuis IBM Informix vers Postgres 9.3.4
C'est vraiment étrange car sur certaines bases, la taille des bases de données sont équivalentes. pour d'autres, elles doublent en espace disque.
Ex après migration :
base toto : 1 Go Informix ==> 900 Mo Postgres sur une instance1 Postgres : PGDATA1
base toto1 : 606 Mo ==> 1.2 Go Postgres sur une instance2 Postgres : PGDATA2
base toto2 : 800 Mo ==> 1.5 Go Postgres sur une instance3 Postgres : PGDATA3
Si vous aviez des idées ... merci, pourquoi ce doublage de la taille des bases ?
Autre info : j'ai fait des drop database toto1 et drop database toto2 entre temps.
Pourrait-il s'agir de config ? ou s'agit d'un paramétrage spécifique ?
Bonjour,
j'ai une base template1 avec comme encodage
Nom | Propriétaire | Encodage | Collationnement | Type caract.
template1 | postgres | UTF8 | fr_FR.UTF8 | fr_FR.UTF8
J'ai ensuite créé une nouvelle base comme ceci
CREATE DATABASE toto WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'fr_FR.UTF-8' LC_CTYPE = 'fr_FR.UTF-8';
et psql m'affiche avec \l+
Nom | Propriétaire | Encodage | Collationnement | Type caract.
toto | compta | UTF8 | fr_FR.UTF-8 | fr_FR.UTF-8
Y-a-t-il une différence entre le type de caractère fr_FR.UTF8 et fr_FR.UTF-8 ?
Merci d'avance
Toch
Merci pour votre réponse et la petite indice, effectivement,
postgresql93-server-9.3.4-1PGDG.rhel5
postgresql93-contrib-9.3.4-1PGDG.rhel5
postgresql-libs-8.1.11-1.el5_1.1
postgresql-8.1.11-1.el5_1.1 <==
postgresql93-libs-9.3.4-1PGDG.rhel5
postgresql93-devel-9.3.4-1PGDG.rhel5
postgresql93-test-9.3.4-1PGDG.rhel5
postgresql-devel-8.1.11-1.el5_1.1 <==
postgresql93-9.3.4-1PGDG.rhel5
postgresql93-docs-9.3.4-1PGDG.rhel5
Il faut que je supprime les paquets 8.1.11 qui étaient déjà installés
rpm -e postgresql-8.1.11-1.el5_1.1
rpm -e postgresql-devel-8.1.11-1.el5_1.1
rpm -e postgresql-libs-8.1.11-1.el5_1.1 –nodeps
et les paquets 9.3.4
je refais une réinstall des paquets 9.3.4 et maintenant, j'obtiens
psql --version
psql (PostgreSQL) 9.3.4
Merci
Toch
Bonjour,
J'ai un souci à la fin d'installation de PostgreSQL. .
Je suis sous RHEL 5.3.
Je suis passé par une installation via les RPMs
J'ai téléchargé les packages nécessaires pour l'installation de postgreSQL 9.3.4 (apparemment sorti aujourd'hui).
postgresql93-9.3.4-1PGDG.rhel5.i386.rpm
postgresql93-contrib-9.3.4-1PGDG.rhel5.i386.rpm
postgresql93-devel-9.3.4-1PGDG.rhel5.i386.rpm
postgresql93-docs-9.3.4-1PGDG.rhel5.i386.rpm
postgresql93-libs-9.3.4-1PGDG.rhel5.i386.rpm
postgresql93-server-9.3.4-1PGDG.rhel5.i386.rpm
postgresql93-test-9.3.4-1PGDG.rhel5.i386.rpm
j'ai bien correctement installé les packages. A la fin, je lance :
avec le compte : root
la commande : psql --version
et j'obtiens :
psql (PostgreSQL) 8.1.11
contient une gestion avancée de la ligne de commande
C'est bizarre, non ?
j'avais déjà installé la 9.0.8 et tout s'était bien passé.
Auriez-vous une idée ?
Cordialement
Toch
Pages : 1
