Forums PostgreSQL.fr

genio

Membre

Encore des questions...

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...

Marc Cousin

Membre

Re : Encore des questions...

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.

genio

Membre

Re : Encore des questions...

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 ?

Marc Cousin

Membre

Re : Encore des questions...

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.

genio

Membre

Re : Encore des questions...

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 ?

Marc Cousin

Membre

Re : Encore des questions...

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.

genio

Membre

Re : Encore des questions...

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 !)...

Marc Cousin

Membre

Re : Encore des questions...

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.

genio

Membre

Re : Encore des questions...

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 !

genio

Membre

Re : Encore des questions...

Une dernière qui me vient en tête : Postgrès peut-il s'installer sur des serveurs logiques ?

Marc Cousin

Membre

Re : Encore des questions...

logiques ? des machines virtuelles ? si c'est bien la question, oui.

---

Marc.

genio

Membre

Re : Encore des questions...

Oui c'était bien de machines virtuelles dont je voulais parler...
Autre question : Comment s'effectuent les reorganisations de databases ?

gleu

Administrateur

Re : Encore des questions...

Qu'est-ce que vous appelez une réorganisation de bases ?

---

Guillaume.

genio

Membre

Re : Encore des questions...

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...

Marc Cousin

Membre

Re : Encore des questions...

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.

genio

Membre

Re : Encore des questions...

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...

Marc Cousin

Membre

Re : Encore des questions...

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.

genio

Membre

Re : Encore des questions...

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 ?

Marc Cousin

Membre

Re : Encore des questions...

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.

genio

Membre

Re : Encore des questions...

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 ?

Marc Cousin

Membre

Re : Encore des questions...

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.

genio

Membre

Re : Encore des questions...

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

Marc Cousin

Membre

Re : Encore des questions...

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.

genio

Membre

Re : Encore des questions...

Merci pour tout...
à bientôt !