Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#26 Re : Général » Plan de sauvegarde d'une base » 23/06/2011 13:32:52
Bonjour,
L'idée avec le PITR, c'est de faire une sauvegarde complète de la base (avec pg_start_backup) de manière régulière (mais pas tous les jours). Ensuite, vous sauvegarderez tous les jours les archives des journaux de transactions.
Si la base crash, vous pourrez alors reconstruire votre base en prenant la sauvegarde de T-3h et vous indiquez à PostgreSQL (via un fichier recovery.conf) qu'il trouvera les archives des journaux de transactions à tel endroit. Il s'en servira pour appliquer l'ensemble des modifications à votre base restaurée et la ramènera à l'instant T. Sous réserve évidemment que les fichiers soient disponibles.
J'appuie sur le conseil de kenrio qui est de relier votre outil de sauvegarde de fichiers avec le PITR. Ensuite, pour la sauvegarde des archives, vous n'aurez pas un volume très important à sauvegarder, comparativement à la volumétrie de la base.
Pour de plus amples informations sur la mise en oeuvre, je ne peux que vous renvoyer vers le manuel rigolo: PITR.
#27 Re : Publications » PostgreSQL 9 Administration Cookbook & PostgreSQL 9.0 High Performance » 29/04/2011 10:46:51
À noter la parution prochaine du "High Performance" en français chez Pearson:
* http://www.pearson.fr/livre/?GCOI=27440100863920
Il sortira normalement le 20 mai.
#28 Re : Optimisation » tables partitionnées - Perf avant ANALYSE » 29/12/2010 19:12:04
Et si vous lancez la requête sans le explain analyze ? (par curiosité). J'essayerai de voir demain si je peux vous aider, car je dois filer.
#29 Re : Général » Archivage des données » 29/12/2010 19:10:32
1.1) A priori non, vous pouvez vous en rendre compte avec un SHOW archive_command. Si la chaîne renvoyée est vide, rien n'est archivé.
1.2) archive_command permet d'indiquer une commande OS à utiliser pour archiver les logs (plus précisément, on les appelle des WAL). Ce n'est en aucun cas un répertoire de destination. Relisez la doc, c'est expliqué et vous trouverez une explication sur les jokers.
2.1) La 8.2 est encore maintenue. Vous trouverez les matrices de support ici
2.2) pg_log correspond à un répertoire dans lequel PostgreSQL va déposer ses traces (si vous voulez, là où vous trouverez votre alert.log Oracle).
#30 Re : Optimisation » tables partitionnées - Perf avant ANALYSE » 29/12/2010 17:33:31
Bonjour,
Vous nous présentez le résultat d'un EXPLAIN simple et d'un EXPLAIN ANALYZE. Le premier va simplement vous donner le plan d'exécution estimé, tandis que le second va vous donner le plan d'exécution estimé mais va y ajouter des statistiques d'exécution. Or, la collecte de ses statistiques à un coût qui fait grimper rapidement le temps d'exécution de la requête.
En fait, je ne comprends pas vraiment si vous fournissez les temps d'exécution des deux EXPLAIN ou bien les temps d'exécution réels de votre requête ?
#31 Re : Général » Archivage des données » 29/12/2010 17:19:04
Bonjour,
J'ai vu dans un autre sujet du forum que vous utilisez une version 8.2. Dans cette version, ce paramètre n'existe pas, il fait son apparition dans la version 8.3.
Donc en 8.2, il suffit de configurer correctement le paramètre archive_command pour que l'archivage soit actif: la doc explique comment faire.
Consultez les logs de PostgreSQL pour vous assurer que l'archivage est bien en place (vous pouvez forcer l'archivage en appelant la fonction pg_switch_xlog()).
#32 Re : Général » Index spatiaux » 28/12/2010 14:51:23
Tout d'abord bonjour,
Votre index spatial vous permet d'accélérer les temps de réponses d'une requête spatiale, simplement en réduisant le volume de données qui doit être traité par les fonctions spatiales (les fameuses fonctions ST_* de PostGIS). Si vous n'en utilisez pas, la fonction spatiale, prenons par exemple ST_Intersect, devra parcourir toute la table et calculer si oui ou non la géométrie traitée fait partie des résultats ou non.
En fait, ces index de type GiST, permettent d'utiliser des opérateurs qui déterminent quels sont les objets dont les boîtes englobantes (bounding box) se recouvrent, et qui correspondent potentiellement aux objets que vous souhaitez retourner dans la requête, donc en gros de réduire le nombre de géométrie à traiter par les fonctions spatiales. Donc, dans la même requête, vous utiliserez une fonction spatiale (ST_*) pour discriminer plus précisément les résultats.
Votre requête comportera ainsi un opérateur && pour "forcer" l'utilisation d'un index - pour réduire les calculs ultérieurs -, ainsi qu'une fonction spatiale ST_*.
Vous trouverez des exemples d'utilisations dans la documentation officielle de PostGIS
#33 Re : Publications » PostgreSQL 9 Administration Cookbook & PostgreSQL 9.0 High Performance » 02/11/2010 14:49:33
gleu: oui, j'ai vraiment envie de faire quelque chose mais le temps manque toujours. Finalement je l'ai très peu lu, préférant la pêche aux moules à la lecture studieuse, mais c'est une véritable mine d'or d'informations.
#34 Re : Publications » PostgreSQL 9 Administration Cookbook & PostgreSQL 9.0 High Performance » 22/10/2010 21:32:42
PostgreSQL High Performance est sorti ! Je vais passer mes vacances à lire l'ebook, un comble ! 
#35 Re : Publications » PostgreSQL 9 Administration Cookbook & PostgreSQL 9.0 High Performance » 04/10/2010 09:14:10
#36 Publications » PostgreSQL 9 Administration Cookbook & PostgreSQL 9.0 High Performance » 01/10/2010 14:54:39
- frost242
- Réponses : 10
Bonjour,
Simon Riggs annonce la sortie du livre qu'il a co-écrit avec Hannu Krosing sur l'administration des bases PostgreSQL 9.0 (mais le contenu s'appliquera très certainement aux versions précédentes). Pour l'instant il est en pré-commande sur le site de l'éditeur avec une sortie prévue en novembre.
Gregory Smith a, quant à lui, écrit un livre sur l'optimisation des bases PostgreSQL 9.0 (en fait couvre les versions 8.1 à 9.0) ; chez le même éditeur, en pré-commande avec une sortie prévue pour ce mois d'octobre.
Ces deux livres sont décrits à l'adresse suivante: http://www.2ndquadrant.com/postgresql-books/
#37 Re : Optimisation » Eviter de Swapper, mieux utiliser la Ram » 29/09/2010 16:48:48
La valeur de shared_buffers concerne les clients aussi, même si c'est un espace mémoire alloué par le postmaster. PostgreSQL s'en sert pour rendre accessible les blocs de données aux processus fils, modifier les lignes, etc.
Le mieux est probablement que je cite la documentation:
Si vous disposez d'un serveur dédié à la base de données, avec 1 Go de mémoire ou plus, une valeur de départ raisonnable pour ce paramètre est de 25% la mémoire de votre système. Certains cas peuvent nécessiter une valeur encore plus importante pour le shared_buffers mais comme PostgreSQL™ profite aussi du cache du système d'exploitation, il est peu probable qu'une allocation de plus de 40% de la mémoire fonctionnera mieux qu'une valeur plus restreinte.
Sans dire que c'est une erreur de positionner work_mem à 20Mo, je pense que c'est une valeur beaucoup trop haute pour une utilisation courante, surtout si le serveur se met à swapper. Avez-vous ce comportement pour toutes les sessions utilisateurs ? Ou est-ce que cela apparaît de manière ponctuelle ?
Pour revenir au point 3, attention, il n'y a pas de lien entre la taille d'un fichier WAL et de l'espace mémoire wal_buffers. Un fichier WAL fait nécessairement 16Mo. Pour schématiser, l'espace mémoire wal_buffers est plutôt un espace qui sert à PostgreSQL à stocker les données à inscrire dans les fichiers WAL ; plus cet espace est grand, plus PostgreSQL pourra écrire de données simultanément dans les WAL et vos performances en écriture n'en seront que meilleures.
Il n'y a donc aucune conséquence pour votre serveur en warm-standby.
#38 Re : Optimisation » Eviter de Swapper, mieux utiliser la Ram » 29/09/2010 14:58:03
Bonjour,
1) shared_buffers ne définie le max de mémoire globale alloué par PostgreSQL, mais la taille d'un espace mémoire partagé entre le postmaster (processus maître de Postgres) et les différents processus serveurs.
2) en gros, oui.
3) checkpoint_segments ne joue pas sur l'utilisation de la RAM mais va influer sur le nombre de WAL en ligne et par conséquent sur vos performances en écritures (en gros, plus il y en a, mieux c'est...). En revanche, un tampon est alloué, or espace shared_buffers, de la taille de wal_buffers et qui a une influence sur les perfs en écriture (par défaut, sa valeur est de 64 ou 128Ko, j'ai l'habitude de le passer à 1Mo, voire au-delà si le besoin s'en fait sentir).
4) depuis la 8.2 et sur un serveur dédié, on a tendance à utiliser 1/4 de la RAM. Dans votre cas 1Go. On peut aller au-delà évidemment.
Pour moi, le gros point noir dans votre conf est de passer work_mem à 20 Mo. Vous avez bien compris l'impact que cela a sur la consommation mémoire, cf question 2. Avez-vous réellement besoin d'allouer autant de mémoire pour les tris ? Par ailleurs, je conseille souvent aux développeurs de laisser work_mem à 1MB et de l'augmenter dynamiquement (ALTER SESSION SET work_mem = xxMB je crois) au besoin.
Si vous avez de réels problèmes de performance avec work_mem à 5MB, voyez en abaissant shared_buffers à 1Go, ou en augmentant la quantité de RAM physique du serveur.
En dehors de cela, votre configuration me semble bien faite.
#39 Re : Général » Comparatif SGBD » 21/07/2010 15:34:10
Et pour enfoncer le clou vis à vis de MySQL, voici l'avis de Frédéric Brouard qui gagne sa vie plutôt avec SQL Server: http://blog.developpez.com/sqlpro/p9136 … /#more9136
#40 Re : Général » Utilisation du logiciel et outils d'ETL » 02/09/2009 11:31:41
Bonjour,
Talend offre des formations sur son ETL Talend Open Studio. Nous avons eu une formation de 3 jours + 2 jours de prestations sur un projet. Voir le site de Talend.
#41 Re : Général » Un problème de type » 17/11/2008 21:18:47
Pour le timestamp, il n'y a pas trop de choix: timestamp. Mais à mon boulot, les gens avaient tendance à utiliser du char/varchar pour stocker des dates, je n'ai jamais trop su pourquoi...
Attention toutefois à la précision, si elle est importante.
#42 Re : Général » Un problème de type » 13/11/2008 23:10:56
Pour représenter des valeurs entières, il vaut mieux utiliser un type adapté, donc smallint, integer ou bigint en fonction des besoins. En plus, smallint occupera moins d'espace disque.
En tout cas, dans votre cas, je prendrai plutôt un smallint.
Enfin pour citer la documentation, brillamment traduite par Guillaume Lelarge :
Le type numeric peut stocker des nombres contenant jusqu'à 1000 chiffres significatifs et effectuer des calculs exacts. Il est spécialement recommandé pour stocker les montants financiers et autres quantités pour lesquelles l'exactitude est indispensable. Néanmoins, l'arithmétique sur les valeurs numeric est très lente comparée aux types entiers ou aux types à virgule flottante décrits dans la section suivante.
#43 Publications » Entraînez-vous à créer et programmer une base de données relationnelle » 12/11/2008 10:50:27
- frost242
- Réponses : 0
Un billet de Jean-Paul Argudo m'a fait me précipiter chez mon libraire favori pour lui passer commande du nouveau livre sur PostgreSQL: "Entraînez-vous à créer et programmer une base de données relationnelle", aux éditions ENI.
Ecrit par François-Marie Colonna, ce nouvel ouvrage s'adresse à des personnes voulant mettre le pied à l'étrier avec PostgreSQL. Il est avant tout orienté vers l'apprentissage par la pratique, d'ailleurs il est disponible dans la collection "Les TP informatiques" de l'éditeur et ne se veut pas être un ouvrage de cours. Tous les chapitres permettent d'aborder de façon progressive tous les aspects de la programmation avec PostgreSQL, du simple SELECT * FROM table jusqu'aux accès simultanées, en passant par la programmation en langage procédural.
Les chapitres sont articulés en deux parties. La première partie est un QCM qui permet de tester ses connaissances, avant d'entamer la seconde partie qui propose de réaliser différents exercices pour mettre en oeuvre ces connaissances (nouvellement acquises ?). Les corrigés des QCMs et des exercices sont disponibles en fin d'ouvrage et occupent bien la moitié du livre, les explications y sont claires et précises.
J'avoue que c'est le livre que j'aurai aimé avoir quand j'ai abordé le monde des bases de données voici 6-7 ans. L'approche est très pragmatique et une bonne connaissance de PostgreSQL est nécessaire si l'on veut répondre correctement aux questions, ce qui implique de lire la documentation quand on débute, ou d'avoir déjà de bonnes connaissances des bases de données et de SQL. Malgré tout, la difficulté n'est pas extrême, on commence par quelques requêtes simples, pour aborder les jointures, les mises à jour, les vues, les règles, etc. Le programme est vraiment très complet, mais il manque peut-être certains aspects d'administration de base qu'il est bon de connaître quand on utilise PostgreSQL.
#44 Re : PL/pgSQL » Fonctions variables et arguments » 29/10/2008 21:38:36
#45 Demandes » Recherche d'emploi de DBA PostgreSQL sur la région lilloise » 29/10/2008 11:00:56
- frost242
- Réponses : 0
Bonjour,
Je suis à la recherche d'un emploi, idéalement dans l'agglomération lilloise, dans le domaine de l'administration de bases de données PostgreSQL et Oracle.
Merci de me contacter sur mon adresse e-mail personnelle (frosties [at] frosties [dot] org) ou par message privé sur le forum. Mon CV est bien entendu disponible sur demande.
Merci par avance.
Thomas
#46 Re : PL/pgSQL » Fonctions variables et arguments » 29/10/2008 00:30:11
Bien bien d'utiliser les quote_ident, mais il manque toujours les doubles-quotes (") autour des noms de colonnes contenant des lettres capitales (BordDroit par exemple).
Il manque également l'ordre EXECUTE devant les ordres UPDATE et INSERT, il est aussi nécessaire car ce sont des ordres générés dynamiquement.
En fait, il y a aussi un truc assez sympa avec PostgreSQL, c'est le debugger pas à pas PL/pgSQL: pgAdmin III le supporte depuis sa version 1.8 il me semble, et le module est fournie avec PostgreSQL 8.3 pour Windows. Sinon il est disponible à cette adresse: http://pgfoundry.org/projects/edb-debugger/.
#47 Re : PL/pgSQL » Fonctions variables et arguments » 28/10/2008 16:22:10
Et avec ça :
CREATE FUNCTION ri_ajoute_fils(IN nomtable character, IN nom character, IN pk_parent integer) RETURNS void AS
$$
DECLARE
Bornes integer;
BEGIN
EXECUTE SELECT "BordDroite" FROM nomtable WHERE id=pk_parent INTO Bornes ;
EXECUTE UPDATE nomtable
SET "BordDroit" = "BordDroit" + 2
WHERE "BordDroit" >= Bornes;
EXECUTE UPDATE nomtable
SET "BordGauche" = "BordGauche" + 2
WHERE "BordGauche" >= Bornes;
EXECUTE INSERT INTO nomtable ("BordDroit", "BordGauche", nom)
VALUES (Bornes, Bornes+1, nom);
END;
$$LANGUAGE 'plpgsql' VOLATILE;Merci de lire le commentaire de SAS à propos de la capitalisation des noms de tables et de colonnes. PostgreSQL "minusculise" les noms des objets, sauf s'ils sont protégés par des doubles-quotes.
#48 Re : Général » trigger declencher par un changement de date avec current_date » 07/10/2008 21:16:35
Bonjour,
Je ne l'ai pas encore utilisé, mais pgAgent semble répondre au besoin. C'est un démon qui doit tourner en parallèle d'une instance PostgreSQL pour pouvoir fonctionner correctement.
Il me semble que PostgreSQL ne peut pas déclencher de trigger sur autre chose qu'une modification des données (INSERT/UPDATE/DELETE).
#49 Re : ODBC » Probleme de connection sur le port 5432 » 01/10/2008 16:01:03
Dans postgresql.conf, tu dois avoir :
listen_addresses = 'localhost'Tu le remplaces par :
listen_adresses = '*'Et tu arrêtes/relance ton instance PostgreSQL.
Jettes aussi un oeil à cette page de documentation : Authentification des clients.