Rép. : Re: Oracle to PostgreSQL

Qu'entends-tu par une "grosse base"? combien de Go/lignes/tables/users...?

Avant tout, pour cadrer ma "connaissance": Je connais assez bien Oracle, je travaille dessus au quotidien comme DBA et développeur. Ma connaissance de PG est plus livresque-doc, site web et mailing lists-, car on ne l'a jamais mis réellement en oeuvre chez nous. A mon grand dam.

Concept de base: Postgres propose nettement moins de réglages qu'Oracle en terme de gestion d'espace disque. Il est plus proche dans ce domaine de la philosophie de MSSQL (issu lui même de Sybase): _le système se débrouille_. Le résultat sera correct au lieu d'être optimal, mais ca fait moins de boulot au DBA. Et moi, moins j'ai de boulot, mieux je me porte.

Personnellement, je préfère, mais les DBA Oracle expérimentés peuvent être surpris et avoir l'impression de perdre de la finesse dans les réglages.
Je trouve pour ma part qu'un des principaux défauts d'Oracle (mis à part son prix prohibitif), c'est qu'il faut un DBA pointu et à plein temps pour le faire fonctionner correctement.

Pour répondre plus en détail:

- Emplacement des tables:
- Toutes les tables et index sont dans le même répertoire, $PGDATA/base ( et /global, pour les tables "système" communes )
- Les équivalents (en gros) des redo log et rollback sont dans $PGDATA/pg_clog et $PGDATA/pg_xlog.
- Quand on crée une table, on ne précise pas de clause STORAGE(tablespace, ...). Tout est dans $PGDATA. Un équivalent des tablespace est annoncé dans la prochaine version de PostgreSQL, en fin d'année. Mais sans garantie.
- On ne préaloue pas de taille à une table (Extents, inital, next...). Tout se fait par blocs de (je crois) 8K par défaut. La table est agrandie au fur et à mesure des besoins. Idem pour les index.
Les grosses tables (>1Go), sont coupées en plusieurs fichiers de 1Go.

Il y a donc peu de possibilités de réglages de ce côté là. mais il n'y a pas non plus les pb de fragmentation ou autre.
La ruse, si on veut optimiser, c'est de faire des liens symboliques pour mettre les répertoires sur des files système ( et des disques physiques) différents. En particulier, séparer /base et les pg_[cx]log.
Tu peux aussi jouer avec les liens symboliques au niveau table, mais là, c'est à la pince à épiler, surtout qu'il faut aller à la pêche dans les tables systèmes pour avoir la correspondance nom de table <=> nom de fichier. A n'utiliser que dans les cas critiques.

- l'équivalent du initSID.ora est $PGDATA/postgresql.conf. Il y a de pas mal de paramètres, mais beaucoup moins que dans Oracle. Comme pour tout: Voir la doc pour plus de détail.

- pour la mémoire: comme pour Oracle, plus il y en a, mieux c'est. Par contre, on ne préaloue pas des centaines de Mo au lancement.
L'idée est de laisser le "cache fichier" de l'OS se débrouiller. Les gourous disent: pourquoi se compliquer la vie à avoir des caches énormes et complexes, alors que cette fonctionnalité existe de manière optimisée dans l'OS? Voir en particulier les interventions de
Ce qui à l'air d'être conseillé : allouer une quantité très modérée de mémoire (paramètre shared_buffers équivalent de db_block_buffers dans Oracle), genre 20% de ta RAM et pas plus de 256 Mo.

- Taille des tables: aucune idée. Mais ça ne devrait pas être très différent d'Oracle. Tout ce que je peux te dire: fais qq essais. En tout cas, il n'y a pas de place "immobilisée" à l'avance par la création de tablespace et d'extends.

- Migration
- http://techdocs.postgresql.org/ , chercher Oracle
- il y a un outil perl appelé pg2ora qui a l'air bien, mais qui te demandera d'écrire un peu de Perl.
- il y a un outil de migration dans pgadminIII. Cf plus loin.
- pour les données:
- l'équivalent du SQL*LOAD ( ou bcp pour les MSSQLiens) est la commande copy.
- une méthode est de faire des exports sous forme d'insert into. Personnellement, je fais ça en 2 clics avec Toad ( http://www.toadsoft.com ).
( [OT] Toad est un outil INDISPENSABLE pour l'Oraclien. Il y a une version gratuite qui est bien, et une version payante qui est carrément géniale. Il y a depuis peu une version pour SQL Server. J'aimerais bien avoir un équivalent pour Pg ).

- Autres infos de base pour le néophite issu d'Oracle:
- PostgreSQL = pg = postgres
- Par défaut , postgreSQL est en AUTO COMMIT. C'est déroutant pour l'Oraclien normal. Si tu veux faire une transaction, il faut explicitement dire "BEGIN". Encore une fois, ça me parait plus proche du comportement de SQL Server.
- Il y a une notion de Base de données. On trouve cette notion de manière proche dans Ms SQL Server/Sybase, mais elle est complétement absente dans Oracle. L'idée la plus proche dans Oracle est le schéma, mais il y a aussi des schémas dans Pg
- Toujours mettre le paramètre fsync=TRUE de postgresql.conf si on tient à ses données. Il force l'écriture des "redo log" sur disque, et garantit donc la cohérence en cas de crash. Mais cela semble ralentir notablement les écritures. Pour moi, la sécurité des données est non négociable.
- Outil graphique d'admin très utile: pgAdminIII. http://www.pgadmin.org/pgadmin3/index.php
- Passer régulièrement un "vacuum", qui nettoie les vieilles "lignes" des tables.
Il faut savoir que dans PG, un update crée une nouvelle ligne dans la table marque l'ancienne comme 'obsolète' => le vacuum enlève les vieilles lignes obsolètes.
Il faut passer un vacuum :
- au moins 1x par jour
- après chaque gros traitement, et (en 1ere approche)
- plusieurs fois par jour si la base vit beaucoup. Disons à chaque fois que 5% des lignes ont été modifiées.
Bien sur, ce sont des "indications". A toi de faire des essais pour trouver des réglages fins.
Il y a plein d'options de Vacuum, la plupart sont non bloquantes pour les utilisateurs. Voir doc.

Les sources d'info: .
- la doc, bien entendu. Elle est suffisamment concise pour être lisible 1 fois de bout en bout, et donc exploitable. La version en Français n'est hélas pas vraiment finie...
- le site web
- les mailing lists et leur archives: indispensables, et en particulier GENERAL . Tu touchera directement les "core developpers" du produit.
CF. réponse de Xavier Poinsard.

J'espère que ça t'aide. A ton service pour plus de détails.
Erwan

-----------------------------------------------------------------------
Erwan DUROSELLE // SEAFRANCE DSI
Tel 01.53.35.12.23. Fax 01.53.35.11.95
------------------------------------------------------------------------

>>> "pierre(dot)chirat(at)freesbee(dot)fr" <pierre(dot)chirat(at)freesbee(dot)fr> 08/01/2004 15:03:48 >>>
La base de donnée actuel est sous Oracle 8.
(en remarque : gros volume de données et tables relativement importante)

En ce qui concerne les demandes plus particulière,
il s'agit des divers espace d'allocation mémoire et disque dur réserver à la base de donnée et à chaque table.
Est-ce que l'on peut parmamétrer ces différents espace.

Merci
0
- Migration

----- Original Message -----
From: "Bruno LEVEQUE" <bruno(dot)leveque(at)net6d(dot)com>
To: <pierre(dot)chirat(at)freesbee(dot)fr>
Cc: "pgsql-fr-generale" <pgsql-fr-generale(at)postgresql(dot)org>
Sent: Thursday, January 08, 2004 2:31 PM
Subject: Re: [pgsql-fr-generale] Oracle to PostgreSQL

> Ceci est une liste en français.
>
> Si je comprends bien, vous avez une base oracle à passer sous postgresql.
> Quelle est la version d'Oracle ?
>
> Pouvez-vous être un peu plus explicite sur vos demandes ?
>
> Bruno
>
>
> pierre(dot)chirat(at)freesbee(dot)fr wrote:
>
> >We want to export a database from Oracle and we need to know
> >informations about :
> >- Tablespace
> >- Memoryspace
> >- Logical and physical space
> >- Diskspace
> >- How to make the export
> >Thanks.
> >

********** PROTEGEZ VOS E-MAILS !**********
Avec Tiscali SuperMail, vos e-mails en toute sécurité !
Anti Spam personnalisable
Anti Virus actualisé en permanence
et de nombreux bonus...
Pour en savoir plus, rendez-vous sur http://www.tiscali.fr/supermail/

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org