PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48

transfert d'oracle vers postgresql

Technique - php | transfert d'oracle vers postgresql

Par ee_lars le 26/10/2007 - 11:26

Bonjour,

Je rencontre un petit problème :
Une personne a developpé une application en php / postgresql, avec tous les soirs des transferts d'une base Oracle vers la base Postgresql :
Ce developpement a été réalisé sous windows (utilsant easyphp, postgresql 8.2 et un client oracle 10) et le transfert d'une base à l'autre dure 15 minutes...

Voulant mettre cette application en production, nous l'avons fait basculé sur un serveur Linux (debian) avec php5, un instant client ORACLE(pecl) et postgresql 8.2.5 (compilé manuellement). Sur cette architecture, le transfert dure 45 minutes...

A priori la requete de selection sur le serveur Oracle est aussi rapide sur les 2 architectures, donc je pense que le problème vient des insertions dans la base Postgresql mais les configurations des 2 serveurs Postgres sont similaires (laissées par défaut).

Auriez vous une idée?? j'ai lu dans plusieurs documentations que l'oubli de LOCK TABLE pouvaient causer ce genre de ralentissement sur d'autres SGBDR, qu'en est-il???

Merci d'avance pour votre réponse.

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

Bonjour Pourriez vous nous

Christophe Chauvet/ = 26 Octobre, 2007 - 16:07

Bonjour

Pourriez vous nous en dire plus sur les valeur de SHMALL et SHMMAX

et des infos sur le serveur Linux (config hardware et OS)

Cordialement.

Christophe Chauvet
KrysKool.org


L'os est debian Etch, le serv

ee_lars/ = 28 Octobre, 2007 - 11:47

L'os est debian Etch, le serveur est un IBM bi proc avec 4go de ram
Je n'ai pas modifié les valeurs SHMALL et SHMMAX du noyau et en effet c'est surement ça qui pose problème...

Je testerai ça dès lundi!!

Merci pour votre réponse, j'aurais du y penser plus tôt :)


Bonjour Bien sur il faudra

Christophe Chauvet/ = 28 Octobre, 2007 - 13:55

Bonjour

Bien sur il faudra adapter en conséquence les paramètres du postgresql.conf

Cordialement.

Christophe Chauvet
KrysKool.org


Bonjour, J'ai retesté ave

ee_lars/ = 30 Octobre, 2007 - 10:31

Bonjour,

J'ai retesté avec la modification mémoire du noyau mais la durée du transfert est toujours la même, je vous liste les modifications de configuration que j'ai fait :

Noyau :
SHMALL et SHMMAX = 536870912

Postgresql.conf :
shared_buffers = 100MB
maintenance_work_mem = 100MB
max_fsm_pages = 153600

Voyez vous un autre point à vérifier??


fsync ?

jmreymond/ = 30 Octobre, 2007 - 10:54

bonjour,
La différence de performances constatée pourrait bien provenir de la valeur de fsync. Est ce la même pour les deux configurations ?

Jean-Max Reymond
CKR Solutions Open Source
http://www.ckr-solutions.com


les valeurs sont les mĂŞmes p

ee_lars/ = 30 Octobre, 2007 - 12:30

les valeurs sont les mêmes pour les deux configurations (par défaut dans postgresql 8.2.5):

fsync = on
wal_sync_method = fsync


© PostgreSQLFr, tous droits rĂ©servĂ©s.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.