Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous...
1°) Est-il encore vrai (cf : http://en.wikipedia.org/wiki/Comparison … formation) que Postgrès n'accepte pas les formats LOB, CLOB etc... ?
2°) J'ai lu que l'utilitaire pg_rman n'était pas vraiment au point => Ok ... mais j'ai l'impression que les restaurations d'instances Postrgrès seraient le gros point noir de l'outil... me trompe-je ?
3°) Les vue matérialisées n'existant pas encore dans Postgrès, l'outil serait-il à déconseiller en cas de création de Dataware ?
Merci pour vos réponses...
Hors ligne
1, Je ne vois pas bien. Il y a YES partout pour PostgreSQL, pour le support des large objects.
2. Ce n'est pas du tout un point noir. C'est juste manuel pour le moment. Mais la restauration marche parfaitement. pg_rman permettra seulement de le faire simplement (sans avoir à se préoccuper soi même des fichiers à restaurer)
3. PostgreSQL est utilisé dans beaucoup de datamarts. Ce qui n'est pas supporté, par rapport à Oracle, c'est principalement la réécriture automatique de requêtes s'appuyant sur les tables pour qu'elles réutilisent les vues matérialisées. Il n'y a pas non plus de materialized views logs, mais on s'en sort très bien avec des triggers simples (c'est d'ailleurs uniquement dans le cas de ces triggers simples qu'Oracle sait utiliser les logs de vues matérialisées pour maintenir les vues matérialisées. dans les cas compliqués, il fait comme tout le monde: il rééxécute les requêtes permettant de construire les vues matérialisées à intervalle régulier).
Marc.
Hors ligne
Dans le tableau 'Data type' colonne 'string', il semblerait que contrairement à Oracle par exemple, il n'y ait que des formats 'CHAR, VARCHAR et TEXT'... peut-être est-ce une erreur ?
Hors ligne
BLOB et CLOB ne sont pas normalisés, à ma connaissance. Le format TEXT vous permet de stocker une chaine de caractère de 1Go. Ça devrait suffire non ? 
Bref, TEXT c'est l'équivalent postgresql de CLOB, et BYTEA de BLOB.
Marc.
Hors ligne
merci pour votre réponse, qui appelle une question : Si pas de blob, pas d'indexation de texte intégral, de catalogue Fulltext et tout l'tintouin sur Postgrès ? me trompe-je ?
Autre question : Postgrès active t'il des traces (comme Oracle) sur une transaction afin de définir les prédicats les + consommateurs ?
En général, le débuggage coté 'performance' est il difficile à installer ?
Hors ligne
Vous vous trompez : pour l'indexation full text, il y a tout ce qu'il faut (regardez la doc). Elle s'appuie sur le type TEXT.
L'autre partie de la question est trop vague. Une transaction n'a pas de prédicat. Si vous voulez parler des prédicats d'une requête, PostgreSQL utilise des statistiques, de type histogramme, similaires à celles d'Oracle.
Le 'debuggage' est assez similaire à ce qu'on peut trouver sur oracle, même si pour l'instant moins aboutit (il manque principalement l'instrumentation des wait events).
Marc.
Hors ligne
En fait je parlais de tracer un thread avant d'effectuer un tkprof et de déterminer les requêtes les + couteuses (pur Oracle !)... y a t'il une quelconque similitude sur Postgrès (je n'ai pas encore lu les documents s'y référant !)...
Hors ligne
Ah. Non, sous PostgreSQL c'est à la fois plus simple et plus compliqué: on n'a pas besoin de tkprof, vu que les traces sont lisibles.
Il suffit de jouer, dans la session, avec par exemple le paramètre log_min_duration_statement. Vous tracerez dans la log tous les ordres plus lents à s'exécuter que la valeur donnée. Vous pouvez aussi utiliser après cela un outil tel que pgfouine pour analyser les traces d'une journée.
La grosse différence, c'est que la log est directement lisible par un être humain. Et qu'on ne génère pas un fichier par session.
Marc.
Hors ligne
Merci encore pour vos réponses... effectivement cela a l'air plus simple sur Postgrès... Je vais effectuer des teste avec cette 'pgfouine' afin d'en avoir le coeur net !
Hors ligne
Une dernière qui me vient en tête : Postgrès peut-il s'installer sur des serveurs logiques ?
Hors ligne
logiques ? des machines virtuelles ? si c'est bien la question, oui.
Marc.
Hors ligne
Oui c'était bien de machines virtuelles dont je voulais parler...
Autre question : Comment s'effectuent les reorganisations de databases ?
Hors ligne
Qu'est-ce que vous appelez une réorganisation de bases ?
Guillaume.
Hors ligne
Ben en fait, quand un tablespace est désorganisé suite à de nombreuses insertions/delete d'occurences, les trous laissés par les applicatifs peuvent gréver fortement les performances... la réorganisation rassemble les données, les retrie, les compacte et comble les trous laissé par les applicatifs... l'outil Import d'oracle (maintenant datapump) réorganise ses tables et index lors du rechargement d'une database... idem l'outil REORG pour DB2 mainframe...
Hors ligne
Si c'est pour faire des exports/imports, à la oracle, il y a toujours pg_dump/pg_restore.
On peut aussi le faire sans sortir les données de la base (il y a des commandes pour ça, mais il vaut mieux savoir ce que l'on fait, sinon on peut faire pire que mieux, comme avec vacuum full par exemple).
Marc.
Hors ligne
Merci ...
Le Pg_Restore peut-il, à partir d'un pg_dump 'full', ne restaurer par exemple, qu'une seule table ?
Ces outils sont-ils aussi 'avancés' que l'Import/Export d'Oracle ?
Au sujet du vacuum : Peut-on dire que la meilleur façon d'utiliser le vacuum 'full' c'est la nuit, dans les procédures de maintenances ?
Merci pour vos réponses...
Hors ligne
Oui, on a le choix de ce qu'on restaure.
La meilleure façon d'utiliser vacuum full, c'est jamais. Si vous en avez besoin, c'est probablement à cause d'une mauvaise application. Ou d'un mauvais paramétrage. En tout cas, une chose est sûre, c'est encore plus mauvais de l'utiliser en période de production, vu qu'il verrouille complètement la table en cours.
Marc.
Hors ligne
Donc pour vous, il vaut mieux utiliser le vacuum 'pas full' de temps en temps en journée, sur une ou plusieurs tables de l'instance ?
Hors ligne
Il faut surtout utiliser autovacuum (ne pas le désactiver). Il s'occupera de lancer les vacuum en cours de journée.
La «nuit» (période creuse, s'il y en a), un vacuum verbose analyze sur l'ensemble des tables ne fait pas de mal, et permet de prendre de l'avance sur les éventuels vacuum d'autovacuum de la journée.
Pour les versions < 8.4, il faut aussi se méfier de la FSM (la zone où postgres stocke les coordonnées des espaces réutilisables). Elle est dynamique à partir de la 8.4 et ne pose plus de problèmes. Avant, on pouvait avoir des ennuis si elle était dimensionnée trop petite.
Marc.
Hors ligne
Merci pour toutes vos réponses...
Donc si je comprends bien, il n'est pas obligatoire (disons tous les mois pour une database fortement mise à jour), d'effectuer un pg_dump et un pg_restaure 'full' afin de réorganiser tout l'bazar, si l'auto-vacuum est activé... Me trompe-je ?
Hors ligne
Sauf si vous avez une application avec un comportement vraiment 'extrême' (mettre à jour tous les enregistrements d'une table en une seule passe par exemple, ce qui fait deux versions de chaque enregistrement dans la table).
Mais de toutes façons, un dump/restore n'est pas la solution la plus pratique. VACUUM FULL + REINDEX de la base est largement plus pratique (surtout depuis la 9.0, où VACUUM FULL est beaucoup plus rapide et reconstruit de lui-même les index).
Les applications qui nécessitent ce genre de manipulation sont heureusement très rares (avoir une telle interruption de service serait une contrainte majeure dans beaucoup d'environnements).
Marc.
Hors ligne
Merci encore...
une dernière : en lisant l'excellent document de Guillaume sur sa présentation Postgrès9, je n'ai aps compris la choses suivante :
Dans les fonctionnalités HS (Hot Standby) et SR (Streaming replication) il dit que les inconvénients sont :
1°) Pas de switchover
2°) Failover facile mais sans récupération des autres esclaves.
Qu'est-ce que cela veut dire ?
3) Excusez si je saute du coq à l'âne mais j'aimerai aussi savoir quelles sont les fonctionnalité/améliorations de PHPGAdmin par rapport PGAdminIII
Hors ligne
Switchover, c'est une bascule programmée. L'avantage, c'est qu'on arrête proprement le maître, on bascule sur l'esclave, et l'ancien maître peut alors être utilisé comme esclave sans être reconstruit. C'est impossible pour le moment, il faut reconstruire le nouvel esclave à partir du nouveau maître. Ce qui veut dire que pendant ce temps, on n'a plus de redondance.
3) Aucune amélioration. Ce sont deux projets différents. pgadmin3 est un client lourd, phppgadmin un client web.
Marc.
Hors ligne
Merci pour tout...
à bientôt !
Hors ligne
Pages : 1
