Vous n'êtes pas identifié(e).
Bonjour,
Afin de comprendre la mécanique de création des WAL et leur recyclage, j'ai fait des insertions dans ma base de données qui ont générées la création de fichiers sous pg_xlog.
J'ai atteint la limite de 47 fichiers de 16 Mo.
Mes paramètres de configuration étant les suivants :
- checkpoint_segments = 16
- checkpoint_completion_target = 0.9
- wal_buffers = 8MB
Ce nombre de fichiers semble correspondre à la limite donnée dans la documentation : (2 + checkpoint_completion_target) * checkpoint_segments + 1 ou checkpoint_segments + wal_keep_segments + 1
Suite au checkpoint, il me reste 36 fichiers WAL de 16Mo.
Lorsque je refais des insertions, je vois que le nombre de fichiers WAL n'augmente pas et qu'il y a un recyclage.
Mais je ne comprends pas pourquoi je ne descends pas en dessous de 36 fichiers.
J'ai essayé de faire un CHECKPOINT manuel mais les traces m'indiquent qu'il n'y a aucun fichier WAL à "récupérer" :
checkpoint complete: wrote 0 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=0.002 s, sync=0.000 s, total=0.035 s; sync files=0, longest=0.000 s, average=0.000 s
==> Pouvez-vous svp m'aider à comprendre quel est le noombre minimum de fichiers WAL ?
==> et pourquoi le nombre de fichiers WAL ne diminue pas, pourquoi les fichiers WAL qui ne sont plus nécessaires ne sont pas supprimés ?
Par avance merci.
Merci pour votre réponse.
Je vais continuer mes essais et voir si cela aboutit.
Alexandra
Bonjour,
Merci pour votre réponse.
La base de données Oracle que je migre est une base 9i mais les types de données utilisées proviennent de Oracle 8i voire 7, donc effectivement, certains champs sont obsolètes.
Si je comprends bien ora2pg va transformé le contenu binaire des champs LONG RAW en text, est-ce correct ?
Si c'est le cas, il vaut peut-être mieux que je force ora2pg à faire la conversion des LONG RAW vers du bytea.
En ce qui concerne le formatage fait par COPY, COPY convertit les données en entrée vers le format du champ cible. Est-ce correct ?
Merci,
Alexandra
Bonjour,
J'utilise ora2pg pour migrer une base Oracle vers PostgreSQL,
et le mode "COPY" pour importer les données dans la base PostgreSQL.
ora2pg permet d'extraire des données selon deux modes
- DATA : extrait les données des tables en tant que lignes INSERT
- COPY : extrait les données des tables en tant que blocs COPY
Certaines tables Oracle possédent des champs "LONG RAW" dans lesquels sont stockées des données binaires.
Ces champs ont été convertis en champ "text" en PostgreSQL par ora2pg.
L'insertion des données de ces champs ne génère aucune erreur si j'utilise le mode COPY avec ora2pg
mais je ne suis pas sûre que ces données une fois migrées contiennent toujours des données binaires.
Le mode DATA renvoie des erreurs :
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
INSERT 0 1
psql:output_data.sql:2169035: WARNING: nonstandard use of escape in a string literal
LINE 1: ...","XTV","PER_NB_N","ROW_D") VALUES (4,155,'\0\0\00...
^
Ma question concerne le fonctionnement interne de la commande COPY :
- est-ce que COPY fait un formatage / encodage à la volée des données ?
- que se passe-t-il pour les données binaires de type LONG RAW qui sont converties en text ?
- par exemple, est-ce qu'un champ "INTEGER" côté Oracle est encodé en champ "NUMBER" côté PostgreSQL ?
Merci pour votre aide.
Cordialement,
Alexandra
Merci pour vos réponses !!
J'en prends bien note pour la suite de la migration.
Bonne fin de journée,
Alexandra
Bonjour,
Merci pour vos réponses, cela devient tout de suite plus clair :-)
Effectivement, je pense qu'utiliser un schéma et un rôle cardplus serait le moyen de se rapprocher d'Oracle.
Dernière question, wilka me suggère de positionner le search_path à (cardplus, public) mais ora2pg (que j'utilise pour cette migration) propose par défaut (cardplus, pg_catalog). J'ai dû mal à comprendre parfaitement la différence, si vous pouvez m'éclairer encore une fois.
Merci,
Alexandra
Bonjour,
Merci pour votre réponse.
Si je comprends bien, sans utiliser de mécanisme de sécurité "ident", il me suffit de :
- créer le schéma cardplus
- positionner le search_path à (cardplus, public) pour que les objets soient bien créés dans le schéma cardplus.
Si je me connecte avec un utilisateur "postgres" par exemple et que je laisse le search_path à ($user,public), les objets seront créés dans le schéma postgres alors que je souhaiterais les créer dans cardplus, c'est bien ça ? Le changement du search_path est donc indispensable à moins de préfixer les ordres de création par exemple des tables par le nom du schéma cardplus, est-ce correct ?
Merci pour votre retour.
Cordialement,
Alexandra
Bonjour,
Je souhaite migrer une base de données Oracle qui possède un schéma "cardplus" associé à un utilisateur "cardplus". Ce schéma / utilisateur possède lui-même un certain nombre d'objets (tables, séquences, vues, etc...).
La migration de cette base Oracle vers PostgreSQL avec ora2pg ajoute un ordre de création du schéma"cardplus" et un positionnement du "search_path" dans la migration des tables mais aucune création d'utilisateur "cardplus" :
CREATE SCHEMA "cardplus";
SET search_path = cardplus, pg_catalog;
Ma question est la suivante : pour se rapprocher le plus du comportement de Oracle dans la gestion d'utilisateur et de schéma,
- est-ce qu'il vaut mieux créer un schéma "cardplus" et positionner le "search_path" ? et éventuellement créer un utilisateur "cardplus" au niveau OS ?
- est-ce qu'il vaut mieux créer un schéma "cardplus" pour l'utilisateur "cardplus" avec la commande :
CREATE SCHEMA AUTHORIZATION cardplus;
Merci pour vos avis et / ou retour d'expérience.
Cordialement,
Alexandra
Bonjour,
J'ai suivi la doc 8.4 concernant les spécificités de AIX (http://docs.postgresql.fr/8.4/installat … notes.html) et voici un retour de ce que j'ai fait :
1. Compilation 64-bit de PostgreSQL 8.3.8 sous AIX 5.3 TL9 OK en utilisant la suite de commande suivante :
# export OBJECT_MODE="64"
# export CFLAGS="-maix64"
# export LDFLAGS="-maix64 -Wl,-bbigtoc"
# ./configure
# gmake 2>&1 | tee gmake_PGS_8.3.8_v5.log
# gmake install 2>&1 | tee gmake_install_PGS_8.3.8.log
Les tests de regression ont été passés avec succés.
La compilation se fait avec succès.
2. Compilation 32-bit de PostgreSQL 8.3.8 sous AIX 5.3 TL9
Si je tente de compiler en définissant uniquement
# export OBJECT_MODE="32"
# ./configure
# gmake
la compilation échoue toujours sur :
In file included from psqlscan.c:2385:
/usr/include/unistd.h:171: error: conflicting types for 'lseek64'
/usr/include/unistd.h:169: error: previous declaration of 'lseek64'
was here
In file included from /usr/include/unistd.h:744,
from psqlscan.c:2385:
/usr/include/sys/lockf.h:64: error: conflicting types for 'lockf64'
/usr/include/sys/lockf.h:62: error: previous declaration of
'lockf64' was here
Si je suis le post du forum http://www.developpez.net/forums/d81671 … -unix-aix/
et que je spécifie :
# export OBJECT_MODE="32"
et l'option "-disable-largefiles" à "configure", la compilation réussit :
All of PostgreSQL successfully made. Ready to install.
J'ai l'impression que définir OBJECT_MODE à 32 bits n'est pas suffisant pour une compilation 32-bits mais je n'ai pas la réponse exacte...
Avez-vous plus d'infos sur l'option "-disable-largefiles" ?
Merci pour votre retour,
Cordialement,
Alexandra
Personne n'a eu à compiler PostgreSQL 8.3.8 sous AIX 5.3 ?
Bonjour,
J'essaye de compiler PostgreSQL 8.3.8 sous AIX 5.3 TL9 (64 bits).
L'exécution du script ".configure" s'est finie sans erreur ni warning mais le "gmake" échoue.
Voici les erreurs que j'ai :
In file included from psqlscan.c:2385:
/usr/include/unistd.h:171: error: conflicting types for 'lseek64'
/usr/include/unistd.h:169: error: previous declaration of 'lseek64' was here
In file included from /usr/include/unistd.h:744,
from psqlscan.c:2385:
/usr/include/sys/lockf.h:64: error: conflicting types for 'lockf64'
/usr/include/sys/lockf.h:62: error: previous declaration of 'lockf64' was here
In file included from psqlscan.c:2385:
/usr/include/unistd.h:807: error: conflicting types for 'ftruncate64'
/usr/include/unistd.h:805: error: previous declaration of 'ftruncate64' was here
/usr/include/unistd.h:843: error: conflicting types for 'truncate64'
/usr/include/unistd.h:841: error: previous declaration of 'truncate64' was here
/usr/include/unistd.h:860: error: conflicting types for 'pread64'
/usr/include/unistd.h:857: error: previous declaration of 'pread64' was here
/usr/include/unistd.h:861: error: conflicting types for 'pwrite64'
/usr/include/unistd.h:858: error: previous declaration of 'pwrite64' was here
/usr/include/unistd.h:928: error: conflicting types for 'fclear64'
/usr/include/unistd.h:925: error: previous declaration of 'fclear64' was here
/usr/include/unistd.h:929: error: conflicting types for 'fsync_range64'
/usr/include/unistd.h:926: error: previous declaration of 'fsync_range64' was here
gmake[3]: *** [psqlscan.o] Error 1
gmake[3]: Leaving directory `/home/PostgreSQL_8.3.8/sources/postgresql-8.3.8/src/bin/psql'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/PostgreSQL_8.3.8/sources/postgresql-8.3.8/src/bin'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/home/PostgreSQL_8.3.8/sources/postgresql-8.3.8/src'
gmake: *** [all] Error 2
En cherchant sur les forums PostgreSQL, je suis tombée sur ce post :
http://forums.postgresql.fr/viewtopic.php?id=421
dans lequel le contournement trouvé consiste à utiliser l'option "-disable-largefile".
L'explication donnée est la suivante :
Il s'agit du support d'adressage de fichiers 64 bits si c'est disponible sur votre système.
Ainsi PostgreSQL pourrait lire et écrire des fichiers de plus de 2 Go.
Aucun intérêt à priori, sauf pour les fichiers de traces. Autrement dit, vraiment aucun intérêt.
Pouvez-vous svp me donner plus d'explications sur cette erreur ?
Je ne comprends pas pourquoi PostgreSQL essayerait de compiler la partie concernant le support d'adressage de fichiers 64 bits si au final il ne l'utilise pas.
Merci pour votre aide.
Cordialement,
Alexandra
