Vous n'êtes pas identifié(e).
Bonjour,
Désolé si ce post à déja été traité (je l'aurais raté), j'essaie d'installer une instance Postges dans un environnement SLES10, j'ai téléchargé la distribution mais lorsque je "dezip" le package je n'ai qu'un .bin, aurais-je omis un détail ? je pense que oui ;-)
Merci pour votre aide
Cdt,
Alain
Hors ligne
Qu'as-tu téléchargé et où ? si je ne me trompe pas, SLES, c'est des paquets RPM. Donc tu dois pouvoir trouver un package RPM pour PostgreSQL.
Guillaume.
Hors ligne
Bonjour,
Merci pour votre réponse, effectivement il y a des packages RPM mais le package que j'ai téléchargé n'en contient pas, voici ce que contient la distribution une fois 'dézippé' et 'détarré' :
linux-xcxb:/oradatD90/product/edb-linux-x86-64_82412 # ll
total 118816
-rw-r--r-- 1 postgre users 401 Jul 8 2008 LICENSE_KEY.txt
-rw-r--r-- 1 postgre users 1982 Jul 8 2008 README_FIRST_Linux64.txt
-rwxr-xr-x 1 postgre users 121526272 Aug 13 2007 edb-linux-x86-64_82412.bin
-rwxr-xr-x 1 postgre users 9344 Aug 13 2007 pre-Install.sh
linux-xcxb:/oradatD90/product/edb-linux-x86-64_82412 #
Lorsque j'execute le script pre-Install.sh j'ai maintenant un msg d'erreur m'indiquant que termcap n'est pas installé, j'ai procédé à l'installation de termcap 3.1 mais j'ai tj le même msg d'erreur.
J'avoue que je sèche un peu ..
Hors ligne
Vous avez récupéré le package EDB, une distribution spécifique de PostgreSQL. Je ne vous la recommande pas, il est préférable de passer par la distribution officielle de PostgreSQL. Vous devriez l'avoir dans les paquets de votre distribution.
Guillaume.
Hors ligne
Et bien un grand merci pour ces précieux conseils, à priori l'installation s'est bien déroulée, il ne me reste plus qu'à lancer pgadmin, en fait je souhaite migrer une base Oracle sur une base Postgres, avez vous déjà fait la manip ?
Hors ligne
Hum je rencontre quand même un problème, le répertoire data n'a pas été créé lors de l'installation, je n'ai aucun process de démarrer et lorsque je veux demarrer le serveur Postgres, il me demande de spécifier le répertoire data via la variable d'environnement PGDATA (enfin je suppose)
Aurais-je encore raté une étape ?
Hors ligne
Comme je ne sais plus trop ce que vous avez installé, j'aurais tendance à dire qu'il vous manque l'exécution du initdb pour créer un cluster PostgreSQL. La doc (notamment cette page : http://docs.postgresql.fr/8.3/install-g … rted.html) pourrait vous aider.
Guillaume.
Hors ligne
Bon cette fois je crois que ça marche ;-)
Au risque d'abuser, je cherche maintenant une documentation me permettant de prendre en main assez rapidement un environnement Postgres sous linux, car je suppose qu'il n'y a pas d'interface d'administration graphique sous linux ? à moins que ..
En tout cas, un grand merci pour votre aide et votre réactivité
Hors ligne
La doc officielle est très bien, même si un peu grosse :
http://docs.postgresql.fr/8.3/
Concernant une interface graphique pour gérer des serveurs PostgreSQL, il en existe bien sûr sous Linux :
* pgAdminIII (http://www.pgadmin.org), donc la version 1.10 beta 1 est sortie il y a peu (la beta 2 devrait sortir cette semaine) ;
* phpPgAdmin.
Et certainement quelques autres. Je ne les ai pas tous de tête, mais ça se trouve assez facilement.
Guillaume.
Hors ligne
Et bien je vais potasser tout ça, sinon connaissez vous l'outil ora2pg ?
Hors ligne
Jamais utilisé, mais beaucoup entendu parler. Un excellent outil à ce qu'il se dit.
Guillaume.
Hors ligne
Savez vous s'il y a un moyen de formater le résultat d'une requête SQL ?
Je n'ai pas trouvé de commande du style 'colonne <nom_colonne> format axx' comme on peut trouver sous SQL+ (Oracle)
Merci bien
Hors ligne
Fonction to_char : http://docs.postgresqlfr.org/8.3/functi … tting.html
Guillaume.
Hors ligne
Bonjour Guillaume,
En fait je ne pensais pas à la conversion des champs date, number ect mais plutôt à l'affichage du résultat d'une requête, si par exemple on dispose d'un affichage 80 colonnes, il se peut que le résultat se présente sur une ou plusieurs lignes, rendant ainsi la lecture plus délicate.
Et je me demandais s'il ya avait la possibilité de formater les colonnes pour rendre l'affichage du résultat plus confortable, j'ai lu le post d'une personne disant qu'il n'avait rien trouvé mais je voulais avoir confirmation.
Merci bien,
Alain
Hors ligne
Il n'y a aucun moyen automatique, c'est à la requête SQL ou au programme de s'en assurer. D'où le lien vers la fonction to_char.
Guillaume.
Hors ligne
Bonjour,
Hum désolé je ne parle pas de reformater les données obtenus via une requête mais simplement de modifer la longueur des champs, si par exemple dans le résultat d'une requête j'ai un champ de type varchar (200) et un champ number 3, je risque fort d'avoir un décalage sur plusieurs lignes, tandis que si je modifie la longueur du champ varchar à 30 par exemple, je vais avoir un affichage clair et lisible.
Mais bon ce n'est pas très grave, en fait j'aimerais savoir si Postgres inclu la réplication de données, pas sur une base de secours pg_stdby mais simplement pouvoir repliquer des données d'une application à l'autre.
Sur Oracle il existe un mécanisme appelé snaphot ou vue matérialisée ainsi que des jobs permettant de rafraichir les données et les base que je vais migrer utilisent ce mécanisme.
Merci,
Alain
Hors ligne
Hum désolé je ne parle pas de reformater les données obtenus via une requête mais simplement de modifer la longueur des champs, si par exemple dans le résultat d'une requête j'ai un champ de type varchar (200) et un champ number 3, je risque fort d'avoir un décalage sur plusieurs lignes, tandis que si je modifie la longueur du champ varchar à 30 par exemple, je vais avoir un affichage clair et lisible.
Pas sûr d'avoir bien compris, désolé. Si l'idée est de modifier le type du champ, vous pouvez utiliser ALTER TABLE matable ALTER COLUMN macolonne TYPE le_type_a_utiliser.
Mais bon ce n'est pas très grave, en fait j'aimerais savoir si Postgres inclu la réplication de données, pas sur une base de secours pg_stdby mais simplement pouvoir repliquer des données d'une application à l'autre.
Sur Oracle il existe un mécanisme appelé snaphot ou vue matérialisée ainsi que des jobs permettant de rafraichir les données et les base que je vais migrer utilisent ce mécanisme.
Pas sûr de bien comprendre là-aussi. Au niveau de la réplication, il existe une certain nombre de possibilités avec PostgreSQL, mais pas en interne (si on enlève le logshipping). Slony et Londiste sont les deux plus connus.
Guillaume.
Hors ligne