Vous n'êtes pas identifié(e).
Pages : 1
Ok en l’occurrence : les données sont identiques et les requêtes aussi.
Seule la plateforme et la conf matériel change effectivement.
Merci pour la réponse,
Quand vous dites que nos serveurs ne sont pas identiques, ya t'il une option qui serait activé par défaut par exemple sous Linux et qu'une installation Windows n'arriverait pas à faire ?
Est-ce que c'est un paramètre à activer dans le postgresql.conf en dehors des classiques :
max_worker_processes = 20
max_parallel_workers_per_gather = 4
max_parallel_workers = 20
max_parallel_maintenance_workers = 4
Bonjour,
Je rencontre cette erreur et je n'en comprends pas la raison.
Je ne rencontre pas ce problème sur un serveur Linux ou même sur une instance Docker que j'ai pour des tests
Mais un de mes contacts sous Windows lui a ce message d'erreur pour les mêmes fonctions SQL
On utilise généralement le site de pgtune pour une première base de performance.
Version PG : 10 et 11 avec l'extension PostGIS 2.5
Merci pour votre aide.
CONTEXTE
SIRS (http://www.sirs-fr.com/fr), intégrée au groupe CLS (https://www.cls.fr), filiale du CNES, de l’IFREMER et de la société d’investissements Ardian, est une société française spécialisée dans le développement de solutions innovantes à partir de données d’observation de la terre. Leader sur différents segments en France et à l’international, la société recherche un(e) développeur-se pour accompagner le déploiement de nouvelles solutions géomatiques.
MISSIONS / ACTIONS À MENER
Rattaché-e au département IT/géomatique de la société, vous travaillez sous la responsabilité d’un chef de projet en y intégrant son équipe pluridisciplinaire. Le projet consistera à étudier, corriger et optimiser une base de données hydrographiques à l’échelle européenne en respectant un cahier des charges précis. Le travail traitera à la fois les problématiques de topologie du réseau ainsi que les calculs d’attributs. Compte tenu de l’échelle de travail, l’automatisation de ces processus sera un facteur déterminant dans la réussite du projet.
PROFIL ET COMPÉTENCES
De formation supérieure bac+3 minimum avec un profil informatique, scientifique et/ou mathématique intégrant les compétences et aptitudes suivantes :
- Proposer des solutions techniques fiables et innovantes sur des projets
- Optimiser et gérer les performances, la disponibilité et la scalabilité
- Industrialiser des composants (automatisation, test et intégration, documentation)
- Optimiser les applications soumises à de fortes charges.
Environnements et compétences techniques souhaitées :
- Base de données SQL PostGreSQL
- Connaissance de l’extension PostGIS et de son module topologique
- Langages procéduraux : PL/pgSQL, PL/Python, etc.
DATES ET LIEU
Début de la mission : dès que possible.
Durée : 6 mois (renouvelable)
Lieu : dans les locaux de SIRS. 27, rue du Carrousel, Parc de la Cimaise - 59650 Villeneuve d'Ascq - FRANCE
Durée hebdomadaire : 35 heures
Salaire indicatif : 30 à 32k brut / an
PROCEDURE DE CANDIDATURE
Les candidatures sont à envoyer par mail à l’attention de Nicolas Rochard à l'adresse suivante : recrutements@sirs-fr.com
Date limite des candidatures : 06 avril 2018 18h00
Ok merci pour l'explication. Je vais l'enlever et refaire des tests de restauration demain.
Juste une petite info en passant, l'option -b dans ce cas ne sert à rien.
Dans la doc, je comprenais que ça prenais en compte des objets longs qui ne serait pas pris en charge autrement. C'est donc inutile même dans le cas d'une base de données spatiales avec des champs géométriques assez longs ?
Je viens de faire le test cette nuit ça fonctionne très bien avec la syntaxe :
pg_dump -U postgres -h localhost -Fc -b mabase > /data/backup/postgres/mabase.backup
...que ce soit une restauration complète ou partielle testée et approuvée !
Cerise sur le gâteau, pour ma base de 63 Go, au lieu d'avoir un fichier SQL de 55 Go, celui-ci ne fait que 10 Go.
Merci beaucoup pour votre aide, très bonnes fêtes de fin d'année à toute la communauté 
Ok merci, je vais tester cela
Re,
Alors j'ai pu remettre la main sur les scripts et ils sont sont configuré ainsi :
pg_dump -U postgres -h localhost base1 > /data/backup/postgres/base1.backup
pg_dump -U postgres -h localhost base2 > /data/backup/postgres/base2.backup
pg_dump -U postgres -h localhost base3 > /data/backup/postgres/base3.backup
pg_dumpall -U postgres -h localhost --globals-only > /data/backup/postgres/users.backup
Comment faudrait il arranger cela pour que je puisse utiliser pgrestore et pouvoir ne restaurer qu'une partie de base ?
Bonjour à vous,
Merci pour vos réponses et votre aide.
Effectivement, Pg_Restore ne fonctionne pas, le terminal me dit que c'est du SQL et qu'il faut passer par psql...
En attendant, j'ai recréé une base PostGIS vide dans laquelle je vais réinjecter le backup complet : psql bddvierge < masauvegarde.backup
Je vois avec mon prestataire informatique où sont stockés les scripts de sauvegarde sur le serveur et je reviens vers vous pour améliorer la syntaxe pour que ce soit plus confortable à la prochaine boulette
@+
Bonjour,
Je suis face à un petit blocage, en effet, chaque soir mon serveur de base de données fait un dump sous la forme d'un fichier .backup
Les rares fois où j'ai du restaurer, je shootais la bdd complète et restaurais le fichier intégralement via psql.
Seul problème cette fois, des tables ont été mise à jour et il faudrait que je ne restaure qu'une seule table. Le hic c'est que la syntaxe que j'ai trouvé ne fonctionne pas :
pg_restore --data-only --table=tablename fulldump.pg > onetable.pg
Des idées ? Mon backup fait plus de 50 Go, je n'ai pas moyen de l'ouvrir pour récupérer les lignes SQL correspondantes.
@+
Bonjour
effectivement, je ne comprends pas pourquoi il ne cherchait plus dans le répertoire postgresql91 mais juste postgresql. En utilisant les liens symboliques, on a pu restaurer la base.
Merci beaucoup pour la réponse
Salut,
Mon serveur PostGIS ayant cramé, je comptais restaurer les bases de données sur un serveur de secours.
J'ai déjà fait la manipulation plusieurs fois pour tester et ça a toujours fonctionné sauf évidemment aujourd'hui que j'en ai vraiment besoin ...
Il commence à m’exécuter la restauration de la base mais au bout de quelques minutes, il me dit \Ninvalid command \N ...
Avez vous déjà eu ce genre de problème et comment avez vous fait ?
Ma commande c'est :
psql -U postgres pigs < /mnt/data/base/Requetes_Sql/data_save/pigs.backupEn attendant, je procède à une méthode tordue en faisant une copie de base vers base sur une autre install de PostGIS (une bécane de test) qui semble fonctionner via la commande
pg_dump -C -h becanetest -U postgres mabase | psql -h serveurdesecours -U postgres mabaseMes 3 machines sont sous PostGreSQL 9.1.6 et PostGIS 2.0.5
Auriez vous des idées pour me débloquer ?
Merci
Bonjour,
J'ai eu le plaisir d'aller glaner des informations sur le stand PostGreSQL France à Solution Linux, en retour j'aimerai proposer une documentation d'installation de postgresql/postgis sur Linux (openSUSE) qui est consultable ici : http://portailsig.org/content/installat … x-opensuse
Elle est axée débutant puisque la distribution le permet. si vous avez des remarques, je suis ouvert aux commentaires.
@+
Pages : 1