Une nouvelle version 8.10 de Ora2Pg est sortie ce 2 mars 2012 ; cet outil, développé en Perl depuis 2005, permet d'exporter le schéma d'une base de données Oracle vers PostgreSQL. Il est disponible sous licence GPL3+.
Les fonctionnalités de migration automatique proposées concernent les schémas, mais aussi les données et — en partie — les fonctions voire les procédures PL/SQL :
- export de schéma complet
- tables, vues, séquences, index
- droits/privilèges pour des utilisateurs et groupes
- export des vues Oracle en tant que table PostgreSQL
- export de données
- par table
- export complet des données ou par sélection via une clause WHERE
- gestion des objets BLOB Oracle en tant que PG BYTEA
- export des fonctions prédéfinies, triggers, procédures, packages
- assistance simple à la conversion de code PL/SQL en code PL/pgSQL
- pour le code spécifique PL/SQL, la conversion reste principalement manuelle
Ce genre d'outil permet de migrer un parc de bases de données Oracle vers un vrai gestionnaire de base de données relationnelles libre tel que PostgreSQL. Les retours d'expérience sont les bienvenus ! Cela peut être la première étape d'une migration, sans oublier d'effectuer les adaptations et tests de non-régression des développements applicatifs se connectant à votre base de données.
Aller plus loin
- Site web de Ora2Pg et liste des fonctionnalités (676 clics)
- Documentations / liens de migration sur wiki PostgreSQL (199 clics)
- Documentation en français de portage du PL/SQL vers PL/pgSQL (594 clics)
- Témoignages d'utilisation de PostgreSQL (197 clics)
- Annonce de PostgreSQL 9.1 sur LinuxFr.org (44 clics)
# question bête
Posté par Yao Kuramoto . Évalué à 8.
Bonjour les gents,
J'ai une question bête, que m'on déjà posée certains user : postresql c'est du niveau d'oracle ? (d'un point de vue fonctionalités et robustesse)
car certains choisissent oracle, non pas pour sa fiabilité ou ses fonctionnalités mais pour la "prestance" du nom…
merci d'éclairer ma lanterne ;-)
[^] # Re: question bête
Posté par Eric P. . Évalué à 10.
Les entreprises utilisant Oracle sur des bases de donnees a tres forte volumetrie, traffic et concurrence ne peuvent pas migrer vers PostgreSql si facilement. Elles utilisent habituellement des fonctionnalites avances, parfois fournies par des entreprises tierces, notamment en ce qui concerne le stockage/backup/encryption. La plupart des requetes sont 'hintees' ce qui n'est pas dispo dans PostgreSql, elles utilisent des pools de connexions, des regles avancees de partitionnement…
Je ne dis pas qu'une migration ne serait pas possible mais que la raison pour laquelle elles ne migrent pas ne vient pas que de la prestance du nom.
Souvent la solution preferee est de migrer les fonctionnalites petit a petit vers un plus grand nombre de bases de donnees plus petites, sur MySql ou PostgreSql, a la place de faire une migration big bang.
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
[^] # Re: question bête
Posté par BAud (site web personnel) . Évalué à 9.
Je suis assez d'accord avec toi, mais pas avec ta manière de le présenter ;-)
La plupart des entreprises pourraient migrer vers PostgreSQL car elles ont des bases à volumétries faibles (bien souvent < 100 Go), peu de trafic et peu de concurrence ;-)
Les options de stockage, sauvegardes, chiffrement, partitionnement doublent voire quadruplent rapidement le prix du moteur Oracle, de l'intérêt d'utiliser un logiciel libre où les fonctionnalités ne sont pas bridées lorsqu'elles arrivent enfin à maturité ou deviennent enfin utilisables (je peux donner des exemples…). C'est justement le coût (et leur complexité de mise en œuvre) qui fait qu'elle sont justement peu souvent utilisées en réalité.
Peu de produits utilisent réellement les fonctions avancées de ce que j'en ai vu (ou en tout cas leur mise en œuvre n'a pas été prévue initialement et cela réclame plus d'intégration que simplement "activer" la fonctionnalité).
Bien sûr, d'un point de vue migration, pour démarrer, autant choisir les petites bases ne nécessitant pas réellement Oracle (pas de développement spécifique PL/SQL, pas de fonctionnalité ésotérique ou d'adhérence à une fonctionnalité spécifique d'Oracle), soit avec des développements internes maîtrisés soit avec des produits gérant déjà plusieurs types de bases si l'éditeur est prêt à faire le support aussi pour PostgreSQL, cet outil de migration servira pour les développements/tables spécifiques ajoutés (vu qu'il y en a souvent…). Cela permettra de voir l'ampleur des nombres d'instances créées ne nécessitant pas réellement Oracle et se faire la main sur des projets dont le fonctionnement est connu et faire monter en compétence l'équipe de DBA sur un nouveau moteur, avec ses particularités.
[^] # Re: question bête
Posté par Misc (site web personnel) . Évalué à 5.
Au passage, j'ai tenté de voir combien compte une base oracle, et j'ai pas très bien compris. dans la mesure ou c'est visiblement cher ( on me parle de 10 000 euros, mais je sais pas si c'est avec ou sans maintenance, sur combien de core, avec quel features etc ), et qu'il faut du personnel formé pour ( car ayant fait de l'oracle à la fac et faisant du postgresql, je pense pas que j'aurais pu m'autoformer sur Oracle, et ça reste beaucoup plus complexe à déployer et à intégrer dans un environnement Linux que du postgresql ).
Est ce que quelqu'un a des chiffres à partager, histoire qu'on voit bien combien ça coute à une société ( genre 1 à 3 mois de salaire d'une admin, d'un presta, plus, moins ? ) ?
car bon, j'ai le sentiment que ce qui tire oracle, c'est plus les différentes dépendances et l'historique que de véritable besoin de faire du warehouse de folie ( surtout en voyant que finalement, il y a un certain nombre d'alternative comme hadoop et compagnie qui ont émergé grâce aux besoins d'entreprise à forte croissance comme Facebook, Google, Yahoo ).
Et je pense qu'en tant de crise, se pencher sur les dépenses excessives de ce genre ne me parait pas déconnant.
[^] # Re: question bête
Posté par Buf (Mastodon) . Évalué à 10.
Oracle doit avoir un des systèmes de tarification les plus opaques qui existe. En gros, le seul moyen d'avoir un prix, c'est de prendre contact avec un vendeur qui fera une offre personnalisée sur la base de critères divers et variés. Le seul truc qu'on sait d'avance, c'est que ça va couter cher… (prix à 5 chiffres minimum)
[^] # Re: question bête
Posté par palm123 (site web personnel) . Évalué à 4.
On m'avait expliqué que les tarifs de licence Oracle sont juste une base de discussion. Je ne sais pas si il faut obtenir 30%, 60% ou 90% de réduction pour éviter de se faire avoir dans les grandes largeurs.
Je sais qu'un DSI avait hurlé pour un projet, car le coût des licences Oracle était bien supérieur au matériel prévu pour cette base…
ウィズコロナ
[^] # Re: question bête
Posté par nimnim . Évalué à 10.
Oracle n'aime pas les relations commerciales équilibrées, donc leurs conditions de vente officielles sont exorbitantes, les conditions réelles moins mais au moindre conflit ils te ressortent les tarifs publics.
Comment se faire avoir par Oracle (non exhaustif) :
— accepter une belle ristourne pour les laisser entrer chez soi (sans budgéter sa baisse une fois qu'Oracle pourra prendre la base installée en otage)
— baser sa stratégie d'achat matériel sur les coefficients CPU les plus favorables dans l'offre Oracle (les coefficients valsent d'années en année en fonction des partenaires qui ont le plus offensé Ellison ; il y a des variantes : en ce moment Oracle ne tourne soit-disant pas sous RHEL6 ou VMWare)
— installer sans compter en espérant une reconduction tacite de l'accord commercial du moment (Oracle adore exiger un audit de la base installée pendant les renégo, en menaçant de faire payer toutes les installations en plus au tarif public)
— négocier un tarif imbattable sur un produit Oracle particulier (si Oracle a accepté des conditions trop favorables à trop de monde sur un produit pour le lancer, dans le catalogue suivant il n'existera plus et il y aura autre chose avec les mêmes fonctionnalités, l'essentiel du même code, et un tarif différent)
[^] # Re: question bête
Posté par georgeswwbush . Évalué à -1.
FUD.
Sur: https://shop.oracle.com/pls/ostore/product?p1=OracleDatabase&p2=&p3=&p4=
En gros, deux licences: standard, plus enterprise, plus options.
Deux mode de licensing: à l'utilisateur, ou aux CPUs
En gros, 1 CPU Enteprise coûte 38 000€ (mais il y a des pondérations avec les multi-coeurs, 1 coeur de puce Intel ne compte que 0,5).
La maintenance annuelle est d'environ 20% du prix des licences.
C'est cher, mais aucune base de données libre ne sait gérer le même volume de données, le même nombre de connectés, et n'offrent les mêmes fonctionnalités - par exemple le cluster actif.
[^] # Re: question bête
Posté par BAud (site web personnel) . Évalué à 6.
oui, le moindre serveur 8 cœurs en cluster actif/passif croisé (chaque serveur actif mais pouvant basculer sur l'autre) reviendrait à 76 k€ pour les deux serveurs, soit 4000 euros chaque instance si on en a 20 (en dessous, c'est plus cher par instance…). Bon, c'est les prix négociés ça hein (ça peut être plus cher que le prix public, va comprendre).
En réalité, dans les grandes entreprises, ça ne coûte que 5 M€ (au moins ou 10 parfois), quel que soit le nombre d'instance et les volumétries (ne vous emmerdez pas à les recenser hein, ya que les allemands pour tenter d'être en règle d'un point de vue technique alors que c'est une négociation commerciale…). Vu dans 3 grandes entreprises (au moins). Attention, les options (partitionnement, spatial…) sont facturées aux maîtrises d'ouvrage (elles ne savent pas qu'il faut passer par les achats), donc bon c'est payé, 2 fois parfois, à chacun d'assumer que le bras droit ne parle pas au bras gauche hein… (manque de coordination).
Pour l'exemple (soit disant pertinant) du cluster actif : cela correspond à quoi ? Le fait que quand le moteur est down bin la base n'est plus accessible du cluster ? (oui le cluster est actif, pas le stockage par défaut… ça c'est une option plus chère encore).
[^] # Re: question bête
Posté par georgeswwbush . Évalué à 2.
cluster actif: option RAC - real application cluster
Une DB, stockée sur un SAN.
Plusieurs serveurs voient les LUNs, et démarrent une instance de la DB.
Max instances: 256.
On peut même utiliser plusieurs SAN, et faire du mirroring de la DB, un peu comme avec LVM mirroir.
[^] # Re: question bête
Posté par BAud (site web personnel) . Évalué à 2.
ce n'est pas lié à Oracle, c'est lié au SAN, une autre manière de facturer une fonction native pour pouvoir l'utiliser (ou comment payer 2 fois) ?
[^] # Re: question bête
Posté par georgeswwbush . Évalué à 2.
pas du tout… la valeur ajoutée d'Oracle, et ce qui fait son prix, c'est la fonctionnalité requise par le cluster actif: la synchronisation de tous les caches.
Et c'est ce qui s'appelle le Cache Fusion: une DB, présentée par plusieurs hosts, qui travaillent tous en parallèle - en conservant les propriétés ACID des transactions.
Autrement dit, scalabilité (presque) linéaire. Aucune autre DB (commerciale ou pas) ne le fait.
[^] # Re: question bête
Posté par BAud (site web personnel) . Évalué à 4.
reference needed, je ne l'ai pas vu mis en œuvre, hormis au prix des perfs (/10 au mini en local, un peu plus en distant on va dire… autant aller voir des artistes du cirque faire des pirouettes, les commerciaux Oracle ils finissent dans le filet hein…)
[^] # Re: question bête
Posté par georgeswwbush . Évalué à 3.
allez, une référence de mon époque: 2004, site web Meetic.
9iRac, 4 noeuds Linux Itanium, storage HP Eva.
En pointe le lundi soir, 30 000 connectés.
Chaque instance:
- user commits / seconde -> 4000
- executes / seconde -> 10000
Même de nos jours, je vois mal un autre SGBD supporter ça.
Et des exemples comme celui-ci, je peux en citer des dizaines en France, plus en europe.
[^] # Re: question bête
Posté par BAud (site web personnel) . Évalué à 3.
je veux bien te croire :) une référence ce serait une URL de l'époque (au pire 01net hein)
servir 4000 en statique avec 10 serveurs me semble plausible, une présentation de l'archi m'intéresse avec une base :)
[^] # Re: question bête
Posté par georgeswwbush . Évalué à 2.
URL ?? la source c'est moi, j'étais le DBA - les données viennent de PERFSTAT
[^] # Re: question bête
Posté par BAud (site web personnel) . Évalué à 3.
combien de serveurs, quels CSPECs ? (un v490 ça me va, un SF25K donner les CPU/RAM)
quel type de baie ? HP ? Sun ? EMC² ?
[^] # Re: question bête
Posté par georgeswwbush . Évalué à 3.
je l'ai dit: 4 machines HP rx4640 Itanium II, baie HP EVA avec 60 shelves - 133 Go FC.
HBA dual port en 4 Gb, et réseaux ethernet 1 Go dédié pour l'interconnect.
La RHEL3 sortait tout juste à cette époque…
[^] # Re: question bête
Posté par Jean-Max Reymond (site web personnel) . Évalué à 6.
Un exemple sous Postgres, "le bon coin" avec
200 millions de pages lues et ses 4 millions de visiteurs uniques par jour
http://www.postgresql.fr/temoignages:le_bon_coin
[^] # Re: question bête
Posté par yellowiscool . Évalué à 2.
La machine est quand même impressionnante
Envoyé depuis mon lapin.
[^] # Re: question bête
Posté par djano . Évalué à 2.
leboncoin.fr utilise une BD relationelle?
Je suis quand même très surpris! Pourtant il me semble qu'une base NoSQL orientée document serait très bien adaptée, avec une petite annonce = un document .
Je me demande ce qu'ils retirent de l'utilisation d'une base relationnelle a part le besoin d'avoir un très gros serveur?
[^] # Re: question bête
Posté par duf . Évalué à 3.
Bonjour,
En fait RAC ça englobe plusieurs choses, cache fusion comme cité par "georgeswwbush" mais aussi une gestion de répartition de charge, une redondance même lors de crash matériel et sans doute le mode le plus impressionnant à voir sous forte charge : le TAF (Transparent Application Failover).
Avec le TAF tu peux garantir (si le moteur transactionnel le gère) l'intégrité de tes transactions si tu as par exemple un moteur transactionnel avec une api XA (Encina, tuxedo…) même si un de tes serveurs physiques de ton cluster RAC explose en plein vol.
Bon bien sûr ça nécessite que toute la chaîne permette de ne jamais rompre une transaction ou d'être capable de la reprendre et les cas où c'est utile sont marginaux. Mais pour certains SI critiques cela peut se concevoir.
Au passage si quelqu'un a déjà expérimenté ou a des références sur une technologie équivalente mais en logiciel libre (si possible au minimum une 100aines de requêtes r/w par seconde) je suis preneur.
@+
[^] # Re: question bête
Posté par duf . Évalué à 2.
Je suis comme un con, j'arrive pas à modifier mon précédent commentaire alors que j'avais le bouton "modifier" sous les yeux il y a 2s…
Je voulais juste ajouter que si je suis intéressé c'est surtout qu'enterpriseDB est en train d'être ajouter à nos socles BDD (youpi) donc si quelqu'un a des informations sur une technologie équivalente ce serait super. D'ailleurs le minimum de requêtes r/w par seconde c'est "vraiment" un minimum, si vous avez des références avec plus ce serait super et surtout une aide précieuse pour ajouter postgre à notre socle BDD. Les acheteurs c'est toujours frileux et ça veut toujours une grosse boite en face :)
[^] # Re: question bête
Posté par Kwiknclean . Évalué à 1. Dernière modification le 14 mars 2012 à 18:04.
Oui et les midleware de SGBD ne sont sûrement pas les plus cher en entreprise, je vous laisse apprécier le prix des outils développés par AXWAY … CFT et compagnie …
[^] # Re: question bête
Posté par benoar . Évalué à 10.
Bah, dans ma faible expérience, la très grande majorité des utilisations d'Oracle que j'ai vu n'étaient pas du tout justifiées par les qualités techniques que tu cites. Oracle, c'est 99% du temps pour le nom, et aussi le nombre de personnes qui le connaissent (c'est facile de trouver de la main-d'œuvre pour). Bref, parce que le système s'auto-entretien.
[^] # Re: question bête
Posté par thecat . Évalué à 3.
Oracle a le gros avantage de proposer quasiment toutes les fonctionnalité de "gestion de données":
Outre les tables SQL classiques, ca intègre aussi: le langage PLSQL (pourri mais il a l'avantage d'exister), un "Full Text Index" avec des opérateurs de recherches de type "fuzzy", "ce prononce comme", traductions des terme de recherches, la gestion de données "spatiales" (points, polygones, distances …), la gestion de données "sémantiques" (RDF datastore), …
Et toutes ces fonctionnalités sont inter-opérable: une seule grosse base de donnée que tu peut questionner dans tout les sens suivant tes envies (tu peut faire une jointure sur entre le résultat d'une requette SPARQL -RDF- et d'une recherche "Full Text").
Bon sur ce dernier point (l'interopérabilité des fonctionnalités) c'est la théorie, en pratique ça peut te péter à la gueule ou avoir des performances catastrophique; mais au moins c'est possible au sein de la même "base de donnée" !
[^] # Re: question bête
Posté par BAud (site web personnel) . Évalué à 10.
ah mais PostgreSQL aussi ;-)
[^] # Re: question bête
Posté par Misc (site web personnel) . Évalué à 7.
Rajoute aussi la possibilité de faire autre chose que du PL/SQL ( genre, tu peux faire du perl, du python, etc, ce qui permet d'avoir plus facilement des développeurs opérationnels en utilisant un langage potentiellement déjà connu ).
Rajoute aussi le fait de pouvoir définir tes propres types de données , le fait de pouvoir taper dans des bases de données externes ( sql/med : https://wiki.postgresql.org/wiki/SQL/MED ), l'isolation des bases via SELinux ( https://wiki.postgresql.org/wiki/SEPostgreSQL_SELinux_Overview ) et une intégration plus simple avec la plupart des logiciels libres.
[^] # Re: question bête
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 17 mars 2012 à 13:33.
Tu peux aussi ajouter que PostgreSQL permet d'appeler du Java dans ses procédures stockées d'après http://www.postgresql.org/about/ (histoire de compléter, dans une optique dissaïdor pressé souhaitant occuper ses multiples développeurs).
Concernant les logiciels libres, j'ai déjà cité quelques Système d'information géographique, il y a aussi wikipedia qui fonctionne très bien sur PostgreSQL (c'est ce que nous utilisons sur TuxFamily) mais il faut reconnaître qu'il faudrait tester un peu plus de wiki et forums pour avérer leur bon fonctionnement (au moins dokuwiki et phpBB voire PmWiki ou drupal /o\).
[^] # Re: question bête
Posté par let antibarbie = xp <- xp - 1 . Évalué à 6. Dernière modification le 13 mars 2012 à 23:52.
Pour avoir utilisé un SQL Server, Oracle, MySQL et PostgreSQL en entreprise (principalement pour de l'archivage—qui pourrait maintenant être fait avec du NoSQL), PostgreSQL domine largement dans les fonctionnalités pour le développeur, l'installation, la facilité de paramétrage, et l'absence de trop mauvaises surprises. Oracle domine pour la complexité, et l'impression de "savoir tout faire".
il y a cependant quelque (gros) couacs dès que la volumétrie de la base augmente :
Bref c'est bien mais il manque des trucs… mais grosso modo ça va dans la bonne direction.
Un petit doc intéressant (nb: même si je ne sais pas comment elle fait pour avoir 400000 tables !)
http://www.pgcon.org/2011/schedule/events/366.en.html
[^] # Re: question bête
Posté par Misc (site web personnel) . Évalué à 3.
Pour avoir des ordres de grandeurs, c'était quel genre de volumétrie, grosso modo ? ( et avec quel genre de hardware ).
[^] # Re: question bête
Posté par let antibarbie = xp <- xp - 1 . Évalué à 4.
j'avais à l'époque fait quelques comparatifs, sur une application qui travaille basiquement sur des tables clef/valeur. Oracle (sans tuning) et PostgreSQL (réglage en suivant le manuel) tenaient la charge jusqu'à 7000 trans/s. SQL Server 2005 (sans tuning) autour de 3000 et MySQL 5.0 (sans tuning) 2300 en InnoDb : sur un vieux Dell Poweredge 2900 (1x Xeon 5160, linux 64 bits) en RAID10 SAS.
Pour les question de "bloat" sur des tables de 200.000.000 de lignes, en faisant confiance uniquement à l'auto-vacuum, on perdait jusqu'à 5Go dans la table et 2Go dans les index, les "Bitmap Index Scan" de PostgreSQL passaient de quelques ms à plusieurs secondes.
Après, selon la doc et le forums, ça dépend du type d'utilisation, on peut tomber dans des cas qui accentuent le "bloat".
(aujourd'hui je vois plutôt des setup "low cost", certes pour des applications non critiques, avec une volumétrie raisonnable de 500Go sur du bête HP DL360 G6)
[^] # Re: question bête
Posté par Misc (site web personnel) . Évalué à 2.
Phpbb et Postgresql est ce qui est utilisé par les forums mageia sur forums.mageia.org.
Donc ça marche.
[^] # Re: question bête
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 2.
dokuwiki n'utilise pas de SGBD(R), la question ne pose donc pas :)
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: question bête
Posté par djano . Évalué à 4.
J'ai cru que tu parlais de PostgreSQL! :D
[^] # Re: question bête
Posté par Marotte ⛧ . Évalué à 2.
Bah c'est vrai que "oracle" pour un SGBD fallait le trouver, ça claque pas mal.
Postgresql je vois pas trop. MySQL je sais que ça vient du prénom My et MariaDB je n'en sais rien non plus.
[^] # Re: question bête
Posté par Maclag . Évalué à 8.
Ben je sais pas pour vous, mais pour moi un oracle c'est un illuminé qui fait des prédictions vaseuses en communiquant soit-disant avec les Dieux. Je ne lui confierais pas mes données personnellement…
Si je te sors:
"Aléatoire, le tout nouveau système de simulation numérique!" ça t'inspire confiance à toi?
[^] # Re: question bête
Posté par ElectronLibre63 . Évalué à 4.
Ça dépend, ça utilise une méthode de Monte-Carlo ?
[^] # Re: question bête
Posté par Flo . Évalué à 6.
Post : après
gres : Ingres
SQL : SQL
En gros, c'est le successeur de Ingres (à la base c'est un projet de M. Stonebraker, le créateur d'Ingres). Les premières versions s'appelaient Postgres, il y a eu un Postgres95, puis c'est devenu PostgreSQL.
[^] # Re: question bête
Posté par djano . Évalué à 2.
My est le prénom de la première fille du créateur de MySQL: Monty Widenius.
Maria est le prénom de la deuxième fille du créateur de MySQL (aussi créateur de MariaDB).
# [^] [-] # Re: question bête
Posté par nax71 . Évalué à -7.
Difficile de faire une comparaison. Assez souvent à cette question la réponse est: Ça dépends …
Mais en plus de ce qui est dit :
* au delà de 1To PostgreSQL a un peux du mal,
* le parallélisme n'est pas supporté nativement
Au moins ce deux points font que le choix pour une utilisation professionnelle/industrielle est vite fait.
Le seul point qui je vois en faveur de PostgreSQL est le prix.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: [^] [-] # Re: question bête
Posté par Niniryoku . Évalué à 9. Dernière modification le 13 mars 2012 à 19:26.
Il s'agit de pur FUD. Le compte a été crée pour l'occasion avec (au jour où j'écris) ce seul commentaire.
Je ne sais pas si c'est quelqu'un de chez oracle, ou un double compte d'une moule qui veux juste troller.
Quoi qu'il en soit :
C'est tout simplement du n'importe quoi. C'est comme dire « à partir de 200 km/h, telle voiture vibre », n'importe quelle voiture vibre avec un mauvais équilibrage des pneus, et une route toute pourrie.
« Une base de 1 To » n'est pas un critère. Ça dépend de :
Une base de donnée d'un teraoctet, sur n'importe quel SGBDR, peut avoir des performances totalement différentes, avec ces derniers critères qui changent.
Ça sert à rien de débatre la dessus. La réputation de PostgreSQL suffit. Il a toujours été considéré se mettant plus à l'échelle ( « scalant plus » comme diraient les décideurs pressés) que MySQL. C'est toute la puissance de PostgreSQL le parallélisme.
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: [^] [-] # Re: question bête
Posté par Larry Cow . Évalué à 3.
L'orthographe est curieuse en tous cas. Des phrases entières bien écrites, accents et cédilles compris. Et puis d'un coup, on te rajoute un s ou un x qui n'a rien à faire là.
Si j'étais parano, c'est tout à fait comme ça que j'imaginerais l'écriture d'un communicant qui fait semblant de ne pas en être un.
[^] # Re: [^] [-] # Re: question bête
Posté par georgeswwbush . Évalué à -10.
"PS : Personnellement, rien que sachant que la licence d'utilisation d'oracle interdit de publier des benchmarks, je ne les choisirais pas. Je doute par ailleurs de la légalité de ce genre de clause. "
-> FUD. -> www.tpc.org
"Mais légal ou pas, ce genre d'entreprise ne mérite pas la moindre attention et le moindre euro de ma part."
-> un avis, c'est comme un trou de balle, tout le monde en a un. Mais on s'en fout du tiens.
[^] # Re: [^] [-] # Re: question bête
Posté par Misc (site web personnel) . Évalué à 7.
Ceci dit, d'autres personnes le disent :
http://archives.postgresql.org/pgsql-performance/2009-02/msg00230.php
Et hélas, je n'ai pas trouvé de lien vers la license entreprise, donc je doit me tourner vers :
http://www.oracle.com/technetwork/licenses/standard-license-152015.html
"You may not :
- disclose results of any program benchmark tests without our prior consent. "
D'ailleurs, hp se plaint de censure sur tpc :
http://h30507.www3.hp.com/t5/Mission-Critical-Computing-Blog/Oracle-Limits-Customer-Choice-Refuses-to-Publish-HP-Server/ba-p/90395
et d'ailleurs, cette article explique que oracle valide les benchs sur tpc :
http://www.theregister.co.uk/2011/03/11/oracle_allegedly_stifles_hp_oracle_tpc_benchmark/
C'est marqué d'ailleurs dans la FAQ :
http://www.tpc.org/information/about/faq-generic.asp#run
Donc bon, je pense pas que ça soit du FUD.
Oracle se reserve le droit de valider la publication de benchmark. C'est vrai que ça n'interdit pas de publier, ça requiert juste qu'Oracle l'autorise, subtil différence sémantique.
[^] # Re: [^] [-] # Re: question bête
Posté par georgeswwbush . Évalué à -10.
"Oracle se reserve le droit de valider la publication de benchmark. C'est vrai que ça n'interdit pas de publier, ça requiert juste qu'Oracle l'autorise, subtil différence sémantique"
Donc c'était bien du FUD, Oracle n'interdit pas de publier des benchs.
[^] # Re: [^] [-] # Re: question bête
Posté par Misc (site web personnel) . Évalué à 7.
Si par défaut, c'est pas autorisé, c'est que c'est interdit. Y a pas à tortiller.
Mais bon, faut pas se prendr ela tête non plus, personne ne va investir des dizaines de milliers d'euros juste pour montrer qu'Oracle pipote, parce que d'une part, tout le monde s'en fout globalement, et d'autre part, il y a tellement à redire sur tout le reste que le détal des benchmarks importent peu.
Au tarif des serveurs comparé à celui de la base de données, ç'est même plus la peine de penser aux performances vu le tarif exhorbitant proposé sur le site ( car bon, tu as dit plus haut que la tarification est simple et clair, ça veut bien dire que les ristournes et magouilles ne sont pas de mise, et donc qu'on peut partir sur la base de 38000 ou 36000 + 6000 euros par an ? )
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: [^] [-] # Re: question bête
Posté par Maclag . Évalué à 10.
Ah ouai.
"ils ne censurent pas les informations, ils les filtrent, ça n'a rien à voir!"
T'as pris des cours en Chine, non?
Donc c'est du FUD, Oracle autorise la publication de tout benchmark présentant leur produit sous un angle favorable et se réserve le droit d'interdire la publication de tout benchmark n'allant pas dans leur intérêt commercial.
Effectivement, c'est très différent que tout interdire, c'est encore plus malhonnête!
[^] # Re: [^] [-] # Re: question bête
Posté par Kwiknclean . Évalué à 2.
De toutes façons dans les grosses structures on ne vous demande pas de choisir on choisit pour vous.
[^] # Re: [^] [-] # Re: question bête
Posté par BAud (site web personnel) . Évalué à 4.
pourrais-tu argumenter ?
Les sujets dont tu parles demandent justement d'y mettre le prix (et les compétences) et cela vaut le coût de regarder du côté de PostgreSQL dans ce cas là (car bon côté Oracle, passé 1 To c'est à la ramasse aussi, s'appuyant sur des baies pour les snapshots - aka BCV en local ou SRDF en distant - sur un slave pour pouvoir l'arrêter pour le copier, digne de MySQL pour ses sauvegardes… une opération de base en exploitation…)
Pour le parallélisme, ah bah Oracle là quadruple le prix avec son Oracle RAC (aka, "tu raques") entre le coût de la licence et des compétences liées à la complexité (limitées par le produit choisi, je n'ai vu RAC mis en œuvre que 3 fois : 2 fois sur des bases petites, 1 fois sur une base conséquente, pour des coûts pas forcément acceptables en temps normal…).
J'ai plutôt vu du MySQL répondant en actif/actif et efficacement (bon avec du slave pour les sauvegardes) pour faire du 24/24, ce qu'aurait fait un bon DBA connaissant PostgreSQL et son exploitation de base, vu qu'il est assez bien outillé par défaut (cela ne demande que de la compétence pour le mettre en œuvre, un peu de temps et d'industrialisation dans le contexte demandé, soit du standard à qui s'investit normalement, sans avoir trop à se battre avec l'éditeur pour y arriver en plus vu que les experts PostgreSQL sont réactifs sur les ML, eux :D).
[^] # Re: [^] [-] # Re: question bête
Posté par georgeswwbush . Évalué à -3.
Le parallélisme, c'est PQO: parallel query option.
Ça vient avec la licence enteprise, et permet à une requête d'être divisée en plusieurs tâches, exécutées par des CPUs distincts.
[^] # Re: [^] [-] # Re: question bête
Posté par Misc (site web personnel) . Évalué à 4.
Donc une de ces features qui implique de prendre entre 50% et 100% de 36000 euros en plus ( vu qu'il te faut un cpu de plus ) ?
[^] # Re: [^] [-] # Re: question bête
Posté par georgeswwbush . Évalué à -2.
Oui, mais très utile pour faire un GROUP BY sur une table de 200 milliard de lignes…. très courant sur Oracle, par exemple pour les opérateurs telco lors du billing:
select sum(temps) from compteur_appels where mois=le_mois_precedent group by numero_appelant
[^] # Re: [^] [-] # Re: question bête
Posté par BAud (site web personnel) . Évalué à 4.
les telco ont pris l'option de partitionnement hein :-) (et pour y avoir travaillé, c'est dans plusieurs instances afin de faire tenir la facturation sur plusieurs serveurs et dans les 24 heures… à mon époque ça prenait entre 3 et 8h, ce qui était incompatible avec l'activité des conseillers de clientèle sur la base client…).
Ce n'était pas tant Oracle le souci d'ailleurs (on avait optimisé malgré le manque de partitionnement à l'époque en Oracle 7 et en leurrant le progiciel choisi, grâce aux synonymes et des tables physiques réparties sur les disques, EMC² n'y avait rien compris à l'époque… début 2000 et ça fonctionnait bien en 3h la plupart du temps pour éviter les 700000 francs par jour de retard d'envoi à la facturation facturés par La Poste).
Oracle 8 nous avait promis le partitionnement, mais n'est arrivé qu'avec les partition views… il a fallu attendre Oracle 9 pour les partition tables (et j'étais parti des telcos).
Tout cela est maintenant possible avec PostgreSQL àmha (et ça me ferait bien plaisir de gérer ces volumétries avec un moteur efficace, je pense que je côtoierais des DBA compétents de nouveau et impliqués :p). Si ça se trouve, ce sera moins des diva et plus des gens qui aiment leur taff' simplement et que l'on reconnaît pour cela (ce dont étaient en manque les DBA que j'ai croisés à l'époque, même si j'ai récupéré 38 MF(*) avec eux, euh pour ma boîte hein, moi j'ai eu droit à une bonne bouffe :p avec les 15 autres qui ont sacrifié leur week-end et leurs nuits à l'époque pour récupérer une table supprimée le 26 qui devait être facturée le 2 au soir, et on l'a fait, que ceux qui se reconnaissent lèvent le bras _o/).
(*) oui, en francs, bon en réalité on n'a récupéré que 9 MF (les dépassements de forfait, le forfait aurait été facturé, mais oui, ça nous a pris du vendredi au mardi soir pour gérer le rattrapage des communications en utilisant la pré-prod' et la procédure définie mais non écrite. Et je confirme que je n'ai eu qu'une bouffe pour cela (comme les 15 autres qui y ont passé plus de temps que moi d'ailleurs), autres temps… J'y ai gagné de l'expérience, de l'aplomb, une confirmation de mes compétences, une confiance dans certaines personnes, une satisfaction du travail bien fait malgré tout (et un certain cynisme, voire un cynisme certain mais réaliste, mais c'est une autre histoire, c'est une question de richesse au sens de la compétence, pas d'argent, qu'est-ce qui est important pour l'avenir ? bref).
[^] # Re: [^] [-] # Re: question bête
Posté par georgeswwbush . Évalué à -4.
Tout à fait… de nos jours, pour comptabiliser les CDS, on fait:
- PQO over RAC instances
- partitionning
- index bitmap
- retrieve des datas directement sur le stockage (nouveauté de la 11, dont j'ai oublié le nom)
Exemple, billing WAP d'un opérateur entre le rouge et le jaune, cluster RAC 4 noeuds solaris + storage EMC:
-> la requête de comptage tourne sur 4 x 16 x 8 coeurs
-> évidemment, le stockage dispose de pas mal (beaucoup même) de spindles
[^] # Re: [^] [-] # Re: question bête
Posté par windu.2b . Évalué à 5.
FOUTAISES !
[^] # Re: [^] [-] # Re: question bête
Posté par Misc (site web personnel) . Évalué à 4.
Je suis pas sur que ça soit vachement plus performant , vu qu'une addition est à un autre ordre de magnitude d'un accès en I/O ( à condition bien sur d'avoir assez de cache pour garder le résultat en mémoire, ce qui est le cas optimal, sinon c'est encore pire si il faut écrire le résultat sur le disque ).
Donc l'exemple est foireux. Soit parce qu'il est destiné à quelqu'un d'encore moins compétent que moi, soit parce qu'il a voulu trop simplifier les choses. Mais je ne doute pas qu'il soit vachement plus convaincant dans la vraie vie.
Et c'est trivial à faire avec du map/reduce sur une base nosql, donc je pige pas vraiment pourquoi garder Oracle, à part le lock in, le manque de temps et l'envie d'être plus cher que les concurents ( ce qui, dans le domaine des telco, ne va plus être à la mode très longtemps je crois, au vue des echos que j'ai du marché ).
D'ailleurs, c'est surement pour ça que Oracle tente de rentrer sur le domaine du big data, en s'alliant avec Cloudera avant de les lacher en se lancant en concurence avec ses ex partenaires comme à chaque fois ( exemple, comme avec les distributions Linux, comme avec les fabricants de hardware, la virtualisation, etc ).
[^] # Re: [^] [-] # Re: question bête
Posté par georgeswwbush . Évalué à -7.
Le jour où tu verras des volumétries qui le justifient, tu comprendras l'intérêt du PQO.
[^] # Re: [^] [-] # Re: question bête
Posté par BAud (site web personnel) . Évalué à 2.
son exemple est largement incomplet (outre être irréaliste) :
[^] # Re: [^] [-] # Re: question bête
Posté par BAud (site web personnel) . Évalué à 4.
ah, les threads sont payants chez Oracle, intéressant o_O
Utiliser un serveur multi-cœur ça semblait pourtant une fonction de base (avec jeu de mot) pour un moteur de base de données. Ça doit être pour ça qu'il y a database pump (expdp, impdp) pour utiliser plus qu'un cœur pour charger des données (payant hein).
[^] # Re: [^] [-] # Re: question bête
Posté par Kwiknclean . Évalué à 1. Dernière modification le 14 mars 2012 à 18:00.
Dans mon cas, au boulot sur les bases du décisionnel, la volumétrie commence à être tellement immense et les performances tellement foireuses qu'ils ont décidé de dégager Oracle … pour le remplacer par une base orientée SID : Netezza un produit IBM
Les chefs de projets nous annoncent des performances en production jusqu’à 10 fois plus rapide par rapport à l'implémentation actuelle..
Sinon je ne suis pas DBA , mais bon j'ai cru comprendre que toute la surcouche de gestion ASM+ était rudement pratique pour les administrateurs, notamment pour définir les VG, espace disque et tutti.
Après avis personnel c'est clair que je vois mal PostgreSQL branché sur sur des outils transactionnels du genre Tuxedo à très fort trafic et sur SI à haute criticité (banque/assurance/industrie), à mon avis le produit risque vire de partir en sucette et toute la couche RAC clustering apparue avec la 10g si je ne me trompe c'est tout de même bien pratique non ? D'ailleurs les version 9/10/11 g apportent leur lot de nouveauté et de sucrerie (bon à part démultiplier le nombre de processus … il est fini le temps ou tu n'avais que SMON PMON … ) en terme de sécurité et rétention de l'info non ?
# Vide c'est nul(l) chez oracle.
Posté par petit_bibi . Évalué à 5.
De mon coté, une bonne raison de ne pas utiliser Oracle et de préférrer PostgreSQL ou H2, c'est cette dissymétrie sur les VARCHAR:
Tu insères une chaine vide dans une colonne, tu récupères un NULL lors de la lecture. Aucune distinction.
Ce genre de dissymétrie est très problématique dans le contexte d'un ORM, un champ pourtant affecté NON-NULL par le programmeur peut devenir NULL plus loin dans l'application.
Puis, sachant que deux NULL en SQL ne sont pas égaux. je pense qu'un [select * from where name=''] ne retourne jamais rien avec oracle.
C'est probablement très pénible dans d'autres contextes comme avec des contraintes genre VARCHAR2 UNIQUE NOT NULL.
Si mes souvenirs sont corrects, c'est historiquement pour gagner quelques bits d'espace lors du stockage.
VARCHAR ne suivant donc pas le standard SQL (arrivé plus tard), VARCHAR2 a été introduit pour assurer la compatibilité.
Ainsi, un jour peut-être, VARCHAR sera modifié afin de suivre le standard SQL.
Je ne sais pas ce qu'il en est aujourd'hui.
Je me demande comment ora2pg traite ça d'ailleur.
[^] # Re: Vide c'est nul(l) chez oracle.
Posté par DerekSagan . Évalué à 3.
Je doute que VARCHAR soit un jour modifié, car la préco d'Oracle depuis des lustres est d'utiliser VARCHAR2 et que la compatibilité ascendante intéresse quand même quelques clients.
Cela dit comme tu finis presque par le conclure tout seul, l'ensemble de ton commentaire n'a plus d'intérêt depuis l'introduction de VARCHAR2. Je ne me souviens plus quand. 1995 peut-être…
Et sinon les ORM c'est le Mal©® quel que soit le moteur de SGBD. Mais ça ça n'engage que moi.
[^] # Re: Vide c'est nul(l) chez oracle.
Posté par petit_bibi . Évalué à 3.
Justement, de ce que j'ai lu ça et là, Oracle a pondu VARCHAR2 pour permettre à l'avenir de modifier le comportement de VARCHAR et le rendre standard. Ceux qui suivent la dite préconisation ne seront donc pas touchés par cette modification.
Dans la doc c'est moins clair, mais ils précisent tout de même que VARCHAR va être cassé:
http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#sthref80
Oui, l'ORM sapue dans plusieurs cas d'utilisations mais pas tous à mon avis.
Un des cas ou je trouve qu'un ORM est pratique c'est quand l'application n'a pas tellement besoin d'exploiter les capacités de la base et ne fait que du stockage (de la persistance?).
[^] # Re: Vide c'est nul(l) chez oracle.
Posté par DerekSagan . Évalué à 1.
Sur VARCHAR: la seule phrase que tu aurais dû recopier est la première:
Le reste est décoratif.
Sur l'ORM:
Mélol, ton argument est: oui on peut utiliser un ORM dans les cas où on n'a pas vraiment besoin de base de données.
Mais ce sont aussi les cas où on peut utiliser des fichiers plats, des technos expérimentales ou inadaptées (qui a pensé NoSQL ?), voire de la persistance over pigeons!
Merci pour le lien je connaissais pas sapue.fr j'aime beaucoup :-)
[^] # Re: Vide c'est nul(l) chez oracle.
Posté par petit_bibi . Évalué à 2.
Le VARCHAR2 ne gère pas la chaine vide non plus, donc le problème reste le même.
J'aurais tendance à dire 'Do not use VARCHAR and VARCHAR2.. well do not use Oracle'.
J'aime pas Oracle pour ce genre de chose et des outils comme ora2pg sont appréciables.
(Il y a bien d'autres raisons, mais se serait mieux d'attendre Vendredi.)
Pour la petite histoire,
J'ai utilisé des fichiers plats par le passé et j'ai eu logiquement des problèmes dans une application de monitoring grossissante après avoir stocké des dizaines de GO dans des fichiers similaires au format RRD. Remonter dans l'historique avec des filtres dans un RDBMS est plus efficace que scanner de simples fichiers de logs (ou alors il faut refaire la roue en commençant par indexer ..) Ça tombe bien, un RDBMS fait tout ça en mieux, en plus fiable, avec redondance, et fourni des outils de navigation, sauvegarde etc..
L'ORM permet de fabriquer la DDL, génère les bonnes requêtes INSERT/UPDATE sans que mon code n'ait à ce soucier de la base sous-jacente, de plus il se charge des conversions de types, des transactions, de la gestion propre des connexions et de la fabrication des objets.
Dans mon cas, l'ORM à facilité l'utilisation de l'infra existante chez le client (Oracle habituellement) afin d'y stocker les données collectées, mais surtout il peut générer des rapports PDF ou autre joyeusetés avec ses propres outils (basés la plupart du temps sur des requêtes SQL aussi).
Pour ce genre de situation, stockage et quelques requêtes dans l'historique, l'ORM est parfait et nécessite que très peu de changement dans le code de l'application. (Du coté perf, ce n'est pas une utilisation bien compliquée pour un ORM).
Donc oui, pour moi l'ORM à sa place dans certains contextes utilisants un RDBMS.
Ceci dit, les systèmes NOSQL sont intéressants.
[^] # Re: Vide c'est nul(l) chez oracle.
Posté par windu.2b . Évalué à 7.
Tu m'étonnes ! Il manque le nom de la table… :-p
# ratp + carrefour
Posté par gmuff . Évalué à 2.
J'avais entendu que la RATP et Carrefour avait migré d'Oracle vers PostGreSQL, est-ce cette technologie qu'ils ont utilisé ?
[^] # Re: ratp + carrefour
Posté par DerekSagan . Évalué à 1.
Il reste une palanquée de bases Oracle chez Carrefour pour encore plusieurs décennies.
(Ce qui ne veut pas dire qu'une des nombreuses bases n'ait pas été migrée sur autre chose, et Postgresql est un bon candidat.)
[^] # Re: ratp + carrefour
Posté par BAud (site web personnel) . Évalué à 3.
la question est plutôt MySQL retenu (Oracle encore) ou PostgreSQL ? (une vraie base libre)
[^] # Re: ratp + carrefour
Posté par DerekSagan . Évalué à 1.
Moi aussi je suis pour un troll MariaDB vs MySQL. :-)
# Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 3.
Bonsoir à tous,
Je vais me permettre de tenter d'apporter quelques éléments techniques sur Oracle (version 10g) - c'est un moteur avec lequel je travaille depuis plusieurs années, je ne suis pas "gourou" Oracle, je n'ai pas d'actions chez eux, et je n'ai pas choisi de travailler avec ce produit.
J'insiste : je parle de technique, pas de prix - c'est un autre débat qui dépend du contexte de chacun et de la valeur que chacun donne à ce qui est dans son moteur de base de données versus le coût de développement (+ maintenance + degré de qualité) des fonctionnalités qui manquent dans ce moteur pour répondre aux exigences du client + la réactivité et la qualité du support de l'éditeur + le savoir-faire des équipes en place + plein d'autre choses. Donc, ça varie et chacun a sa vision de la vérité, elle n'est ni meilleure ni moins bonne qu'une autre vérité. Ce post n'a pas pour volonté d'ouvrir ce genre de débat sans issue, je souhaite juste apporter ma pierre à l'édifice.
Voici pour le préambule afin de "fixer le décor".
Maintenant, le plus important est de comprendre que le moteur de base de données SQL d'Oracle ne représente finalement qu'une petite partie du produit. Ce moteur SQL est apprécié, il a des qualités et des défauts (comme les autres), etc mais choisir Oracle uniquement pour son moteur SQL c'est comme acheter une voiture de course en pensant que l'on a acheté une charrette à bras : c'est globalement sous-optimal, on passe à côté de beaucoup de fonctionnalités offertes par le produit que l'on risque de s'évertuer à vouloir re-implémenter ou re-développer à côté (et, partant du principe qu'une ligne de code fiable et bien débugée est une ligne de code que l'on n'a pas à écrire car d'autres l'ont déjà fait, je laisse à chacun le soin de conclure).
Donc, on trouve par exemple dans Oracle :
* un broker de messages applicatifs offrant notamment une API JMS (et de la cohérence transactionnelle avec la base, évidemment) ;
* (déjà cité dans un autre post) un langage nommé PL/SQL qui peut ne pas plaire à tout le monde mais qui offre plein de possibilités dont un compilateur ;
* une foultitude de packages PL/SQL prêts à l'emploi ;
* du Java avec compilateur natif ;
* des API et des pré-compilateurs variés ;
* un scheduler, c.à.d un moteur d'exécution de jobs ;
* un socle de Change Data Capture (CDC) en temps réel permettant de faire de la réplication de données multi-sites, multi-bases, et bien plus encore ;
* un outil de backup / restore évolué (gestion de la péremption des backups, de leur redondance, …) ;
* un stockage raw (comprendre "pas des fichiers") redondant et stripé ;
* un outil d'administration / supervision Web ;
* des métriques de performance très vastes, avec une vision instantanée et une vision historique ;
* une documentation très complète ;
* …
… et plein d'autres choses encore.
On constatera donc que dire qu'Oracle est une base de données est une définition finalement assez réductrice. Son moteur SQL est riche, mais quand on considère l'ensemble des fonctionnalités apportées par ce que l'on appelle "Oracle" et qui est disponible sur plusieurs OS et plusieurs plate-formes matérielles (du PC x86 "basique" Linux / Windows jusqu'aux mainframes en passant par Solaris, AIX, …), on obtient un socle d'exécution dans lequel le moteur SQL n'est qu'une brique parmi d'autres.
Ce qui fait l'intérêt d'Oracle, bien au-delà des qualités (ou pas) du moteur SQL que l'on peut aimer ou pas, c'est tout ce qui est disponible en plus du moteur SQL, qui fait partie intégrante du produit et qui forme un socle cohérent, homogène, documenté, supporté, et d'une certaine manière, portable (on ne développe plus sous Linux ou Windows ou mainframe, on développe sur Oracle).
Chacun appréciera en fonction de son contexte, des exigences techniques et fonctionnelles du projet, du budget, des compétences en place, …
Disclaimer :
* J'espère que tout ceci ne ressemble pas à une publicité pour Oracle car ce n'est pas mon intention, ils ont bien assez de budget pour faire de la pub' sans moi, je ne suis pas attaché à Oracle plus qu'à un autre produit (j'utilise par ailleurs SQL Server et postgres - sur des projets de moindre envergure - et cela donne entière satisfaction).
* Et Oracle n'est pas un produit parfait ni miraculeux, tout le monde s'en doutait !
Plus de détails ci-dessous (je ne suis pas assez "calé" en Oracle mais à priori, tout ce qui est décrit ci-dessous est disponible à l'identique sur tous les OS et toutes les plate-formes matérielles supportés par Oracle).
Un broker de messages applicatifs :
* pas besoin d'installer un serveur JMS : il y en a déjà un dans le moteur ;
* pas besoin de chercher comment on fait une transaction XA afin d'embarquer dans un seul commit ou rollback un put dans une file de messages et des actions quelconques en base de données : c'est nativement supporté sans faire du XA ;
* comme c'est natif et intégré au moteur, l'état du broker (messages en cours, …) est backupé avec la base et cela forme donc un ensemble transactionnellement cohérent si on doit faire un restore ;
* ce broker s'utilise aussi en PL/SQL et autres langages (Java/JMS n'est qu'une API au-dessus du composant Oracle qui se nomme Advanced Queuing) ;
* il permet d'échanger des messages entre différents serveurs Oracle ;
* il supporte le publish and subscribe ou le point à point ;
* … bla bla, voir par ici pour en savoir plus AQ 10g ;
* … le fonctionnement est supervisable via des tables, tant sur son bon fonctionnement que sur les performances et la volumétrie, voir par exemple DBA_HIST_BUFFERED_SUBSCRIBERS qui historise certaines des statistiques d'utilisation dans un scénario publish and subscribe (la même chose existe temps réel).
(déjà cité dans un autre post) Un langage nommé PL/SQL qui peut ne pas plaire à tout le monde mais qui offre tout ce que l'on peut raisonnablement attendre d'un langage procédural dont par exemple :
* la possibilité de créer des packages avec une partie publique et une partie privée ;
* un compilateur optimisant ;
* un profiler de code afin de collecter des métriques de performance ;
* un debuger live ;
* des concepts tels que des tableaux associatifs, des structures, de l'héritage aussi si ma mémoire est bonne, … ;
* la possibilité de créer des types personnels autant que de besoin ;
* la possibilité de créer des fonctions dont les résultats peuvent être consommés par une requête SQL comme si c'était une table ;
* un mécanisme
try / catch;* un traitement efficace des opérations de masse afin de limiter les fetch en base ;
* la possibilité de créer des fonctions dont le résultat sera mis en cache par le moteur afin d'accéler les appels suivants avec les mêmes arguments ;
* la présence de ce langage, à l'identique et avec les mêmes possibilités, sur toutes les plateformes matérielles et tous les OS supportés par Oracle : Linux, Windows, HP/UX, z/OS, Solaris, AIX, … celui qui cherche la portabilité devrait pouvoir trouver son bonheur ;
* … bla bla - ceux qui veulent en savoir plus peuvent aller faire un tour ici PL/SQL 10g.
Une foultitude de packages PL/SQL prêts à l'emploi :
* je ne vais pas tous les citer, il doit y en avoir plus d'une centaine ;
* la liste se trouve ici packages 10g.
Pour ceux qui préfèrent Java :
* on peut aussi écrire des procédures stockées en Java ;
* avec un compilateur natif ;
* et on peut appeller du code Java depuis PL/SQL (et vice-versa je crois me souvenir) ;
* plus de détails ici Java 10g.
Des API et des pré-compilateurs variés :
* on peut travailler en C#, C/C++, Java, Cobol, Fortran ;
* sur différents systèmes d'exploitation : Linux, Windows, Solaris, AIX, OpenVMS, z/OS, … ;
* et d'autres (PHP par exemple), mais je ne connais pas assez pour détailler.
Un scheduler, c.à.d un moteur d'exécution de jobs
* permettant de définir des enchaînements de tâches ;
* permettant de définir des fenêtres temporelles durant lesquelles un job peut ou ne peut pas se déclencher (par exempe : job XYZ déclenché tous les avant-derniers jeudi du mois à 2h du matin en heure locale) ;
* permettant de définir des quotas à un job en fonction de la fenêtre temporelle courante (jobs de maintenance = 100% quota tous les dimanche mais seulement 10% en semaine afin de ne pas "plomber" les IO des requêtes applicatives) ;
* tout ceci est transactionnel, intégré à la base et correctement audité ;
* ceci est décrit ici Scheduler 10g.
Un socle de Change Data Capture en temps réel permettant de faire de la réplication multi-sites, multi-bases, et avec des boucles si on le souhaite :
* je manque un peu de courage pour détailler la chose, j'espère que cela restera compréhensible et assez proche de la réalite ;
* CDC permet de collecter en temps réel les modifications apportées à une table (ou mille tables), soit en mémoire soit par analyse des journaux si ça va trop vite, puis alimente une table qui décrit ces modifications ("la 678ème opération de la transaction 5772829 était un update ; les données avant l'update sont : bla bla ; les données après l'update sont bla bla") ;
* ces tables de changements sont accessibles directement si on veut ;
* mais on préfère y accéder via des vues (mise en place par une API PL/SQL) afin que plusieurs consommateurs puissent traiter lesdites données, chacun à son rythme (dans le principe, c'est un peu comme du publish and subscribe dans le monde JMS sauf que l'on ne consomme pas des messages mais des infos stockées dans des tables) ;
* CDC se charge de supprimer les anciennes données de ces tables lorsque tout le monde les a consommées ;
* le composant CDC n'est qu'une surcouche simplificatrice à un autre composant nommé Oracle Streams (qui s'appuie lui-même sur le broker de messages applicatifs cité auparavant) ;
* Streams permet de faire à peu près tout ce dont on peut rêver de faire dans n'importe quel scénario de réplication de données ;
* on peut inspecter les données, les transformer, les router, … ;
* cela réplique non seulement les opérations type DML (insert / …) mais aussi le DDL (create table, …) ;
* pour CDC, la porte d'entrée est ici CDC - il y a plusieurs options techniques (triggers = beurk ou via journaux comme expliqué au dessus = mieux = ici par exemple) ;
* pour Streams, la porte d'entrée est ici Streams ;
* ceci est supervisable via des tables afin d'en contrôler le bon fonctionnement et la performance ;
* ceci étant intégré au moteur, c'est également intégré au backup / restore, ce qui garantit de toujours revenir à un état transactionnellement cohérent si on doit faire une restauration.
Un outil de backup / restore évolué :
* il se nomme RMAN ;
* il sait compresser ;
* il sait faire des backups redondants ;
* il sait gérer la péremption des backups ("je veux deux backups de ma base dans ce répertoire-ci et ce répertoire-là et je veux être capable de revenir en arrière de trois semaines à tout instant : débrouille-toi !") ;
* ceci est supervisable via des tables ;
* … pour en savoir plus sur RMAN, voir par exemple ici RMAN.
Un stockage raw nommé ASM (warning : je n'ai jamais mis en oeuvre) :
* les fichiers c'est bien mais cela suppose de traverser pas mal de couches de l'OS ;
* cela n'est pas obligatoirement optimal en termes de performance ;
* cela peut imposer à l'OS de gérer beaucoup de blocs en cache, ce qui réduit d'autant la mémoire que peut utiliser Oracle pour son propre cache (et ce qui pénalise aussi les autres applications) ;
* c'est pourquoi ASM permet de dédier plusieurs partitions à Oracle ;
* ASM se charge ensuite de la redondance des données (0, 1 ou 2 copies) et du striping ;
* pour en savoir plus, c'est ici ASM.
Un outil d'administration / supervision Web :
* il se nomme OEM ;
* la licence Oracle permet de l'utiliser dans sa version mono-instance (de ce que j'ai compris : 1 licence Oracle = 1 droit d'utilisation de OEM) ;
* il y a une version dite "grid", c.à.d multi-bases et qui fait le café mais il faut sortir le chéquier ;
* OEM permet de faire par clic-clic beaucoup d'opérations d'administration : backup ponctuel, gestion des utilisateurs, de l'espace de stockage, … ;
* OEM permet aussi de faire de la supervision de performance du moteur dans sa globalité, des requêtes, et du système d'exploitation ;
* on peut obtenir des rapports de performance détaillés afin de savoir à quoi la base passe son temps ;
* on peut comparer deux périodes d'activité de la base (par exemple : comparer l'activité du mercredi 10H-12H avec l'activité du mercredi précédent sur le même créneau horaire afin d'aider à comprendre pourquoi il y a eu des problèmes de performance) ;
* OEM peut vérifier si la configuration de la base est conforme à un certain nombre de règles de sécurité (pré-définies ; je suppose qu'on peut en ajouter) ;
* si cela lui est permis, OEM peut identifier les patchs qui n'ont pas été déployés sur la base ;
* … pour en savoir plus, voir ici OEM ;
* … pour quelques copies d'écran du monitoring de perfs en temps réel, voir ici OEM perf ;
* … pour un petit aperçu de quelques métriques disponibles, voir la fin de cette page MET.
Des métriques de performance très vastes, avec une vision instantanée et une vision historique :
* en instantané, une fois par seconde pour être précis, il y a ASH qui collecte une multitude d'indicateurs de performance et qui permet, en cas de souci, d'aider à comprendre où se situe le problème (IO ? quel type d'IO : journaux ? données ? lectures de blocs en séquentiel ou en aléatoire ? mémoire ? quelle(s) requête(s) sont responsables de cette activité ? …) ;
* en historique, il y a ADDM et AWR qui stockent tout ceci (pas 100%, il y a du sampling) en base de données ;
* il est alors possible de d'obtenir des tendances sur plusieurs jours, semaines, mois, … (la durée de rétention de ces données de performance est paramétrable) ;
* il est également possible de comparer l'activité de la base entre deux périodes (par exemple : évolution entre cette semaine et la semaine précédente) ;
* tout ceci est exploitable par des tables et / ou une API PL/SQL et / ou via l'IHM Web de OEM ;
* … et pour en savoir plus, c'est ici, au chapitre 5 par exemple PERFS ;
* … pour une liste plus exhaustive, voir "Part III" ici V$, quand on est un peu (beaucoup !) maniaque sur les perfs, on peut apprécier des choses telles que V$FILE_HISTOGRAM par exemple.
Une documentation très complète :
* le point d'entrée est ici DOC ;
* un index index donnera une idée de la quantité de documentation disponible ;
* cette documentation peut être installée localement sur n'importe quel PC (on perd la recherche dans la doc au format HTML mais elle est également fournie en fichiers PDF avec possibilité de faire des recherches globales) ;
* ceci est un réel atout pour le développeur, l'administrateur DBA ou le concepteur que de pouvoir s'appuyer sur une documentation aussi riche (de mémoire : quelques centaines de Mo) ;
* cette documentation prend soin de définir les concepts importants : c'est bête mais c'est vital ;
* pour se faire une idée, voir ici CONCEPTS : c'est 400 ou 500 pages qui donnent un aperçu de tout, du sol au plafond.
Toutes mes félicitations à celles et ceux qui ont tout lu jusqu'ici, bonne continuation.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par hamelg . Évalué à 0.
Tu as oublié de citer le site de support metalink qui est également un atout.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à -2.
@hamelg
Même avis, mais je ne sais pas si je dois l'écrire, je vais finir par me prendre une bordée d'injures :-)…
Cordialement.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par Niniryoku . Évalué à 3.
Je tiens à préciser que j'ai plussé le commentaire precédent, car il est exhaustif, interagissant à lire et objectif. Je ne suis pas spécialiste de PostgreSQL peut être qu'un vrai spécialiste contredira/affirmera.
PostgreSQL possède une site dédié au développement de logiciel en rapport avec le moteur SQL PostgreSQL. Le plus souvent, il s'agit de concurrencer oracle, mais les développeurs innovent aussi.
PL/pgSQL
Peut être est-ce comparable à PL/Python
Il faut bidouiller aussi, mais on peut utiliser les journaux de transaction pour ça. PostgreSQL a aussi un très bon système de réplication.
Cette partie reste objective. Celle de PostgreSQL est bien fournie elle aussi.
Contrairement à Oracle, on n'achète pas le logiciel mais le support. Les prix peuvent donc aller de 0 € si on internalise toute la compétence, à très très cher (mais de très bonne qualité) si on va chez Red Hat, ou des prix variables d'un prestataire à un autre.
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 2.
Je ne sais pas s'il s'agit de mon commentaire ou pas mais je te remercie de me répondre de manière civilisée, ce qui est toujours agréable.
Pour ce qui est de la comparaison Oracle / pg sur les points que tu cites, je n'ai pas d'avis car je ne connais pas pg aussi bien qu'Oracle (le hasard m'a amené à mettre les mains dans le cambouis très profondemment dans Oracle et dans Ingres) et OpenIngres (même lien) mais pas beaucoup dans leur successeur, c.à.d postgres).
Pour le PL/Python, je me permets d'ajouter que la doc de la 9.1 présente de nombreuses améliorations par rapport à la 8.2 que tu cites.
Sur la réplication de pg, GLMF a publié quelques articles instructifs (voir par exemple numéros 130++ à la fin de cette liste) [begin sequence publicité]soutenez-les, abonnez-vous à leurs revues ou faites abonner votre employeur[end sequence publicité].
"bidouiller" : tu peux préciser dans quel sens tu emploies "bidouiller" ? (c'est une formulation qui peut faire un peu peur)
Au plaisir de te lire à nouveau.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par BAud (site web personnel) . Évalué à 1. Dernière modification le 14 mars 2012 à 21:34.
Oracle_Streams dont tu parles pour la gestion des messages est déprécié par Oracle… sympa pour ceux qui auraient passé du temps à tenter de l'utiliser (bon, je ne l'ai pas rencontré, c'est pas du stockage de données donc les DBA ne l'ont sans doute pas suggéré…).
Pour le scheduler dont tu parles, même Job Scheduler - qui n'était pas apprécié là où je l'ai rencontré - semble pouvoir faire mieux. Ton truc il n'a visiblement pas d'interface graphique, c'est apparemment un simple cron utilisable en créant des lignes dans des tables… Je n'ai vu que des DBA pour l'utiliser (relever des stats par exemple et générer le rapport qui va avec).
Tu parles beaucoup de Oracle 10g, dépêche-toi le "support premier" est terminé depuis juillet 2010 ;-)
Pour le commentaire au-dessus, oui metalink c'est génial : pas indexé par google, une "recherche" intégrée qui ne te retrouve pas ce que tu veux… j'imagine que c'était du second degré :-)
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 4.
Sommaire
@hamelg et @Niniryoku : j'aurais aimé compléter vos sujets mais il se fait trop tard pour mon petit cerveau.
@baud123
10g
Chantier "migration" en cours :-) (mais, à ma connaissance, on est toujours supporté).
Ceci explique aussi pourquoi je parle beaucoup de la 10g : c'est ce que nous avons en prod' depuis longtemps, c'est donc ce que je connais le mieux.
Streams
En effet, déprécié comme tu dis.
Mais cela ne signifie pas que ce composant va disparaître demain. Voir par exemple "Oracle Streams: What's New in Oracle Database 11g Release 2" : ça bouge encore pas mal.
Et quand bien même ils arrêtent sur la 12 ou 13 d'améliorer le composant, il restera en place un bon bout de temps (comme l'ancien scheduler de jobs par exemple). Ces deux point sont clairement annoncés dans Oracle GoldenGate Statement of Direction , page 4 :
Evidemment, les promesses n'engagent que ceux qui y croient comme on dit…
Scheduler
Merci du retour sur le produit que tu cites, il fut un candidat potentiel pour un projet passé et je suis heureux de ne pas l'avoir retenu (je crois qu'on a remplacé le scheduler par un humain dans cette histoire).
Concernant le scheduler d'Oracle, c'est sans doute différent de l'idée que tu en as. En résumé :
Pour l'IHM :
Pour les fonctionnalités :
FREQ=MONTHLY; BYDAY=MON; EXCLUDE=JoursFeries; BYSETPOS=-1(JoursFeriesétant le nom d'un calendrier que l'on a défini par ailleurs avec la liste … des jours fériés).Je ne doute pas qu'il existe des schedulers (? $U ?) qui savent faire bien plus que celui qui est nativement intégré à Oracle. Ce dernier possède cependant, à mon sens, quelques caractéristiques qui peuvent avoir de la valeur selon l'environnement dans lequel on travaille, les contraintes, les besoins, …
En résumé : "ça juste fonctionne" ("it just works"), c'est toujours installé, toujours disponible, et c'est la même chose partout où une base Oracle est déployée.
Perspectives
En complément, par rapport à mon premier post :
Au final, cela peut représenter une "force de frappe" conséquente quand on commence à faire l'inventaire de tous les composants qu'il faut assembler, faire fonctionner de manière harmonieuse et maintenir si on souhaite (ou si on doit !) partir sur une approche "brique par brique" plutôt que "all in one".
Oracle n'est certainement pas une solution miracle mais le produit a de réelles qualités, sur un vaste périmètre, souvent méconnues, et qui prennent tout leur sens quand on considère l'architecture d'un système d'information, sa réalisation, sa qualité, sa maintenance, et son exécution. Libre à chacun de déterminer si les fonctionnalités du produit fournissent de la valeur (qualitatif : moins de code à écrire = moins de bug, moins de technos à assembler et maîtriser, portabilité, …) et si le coût (quantitatif) est compétitif avec d'autres solutions.
Cela influe évidemment sur l'intérêt et le coût d'une migration :
En tout état de cause, merci de ton article initial sur Ora2Pg - il a intégré mon catalogue d'outils "au cas où" et il me permettra peut-être un jour de proposer une solution pertinente à un client.
Au plaisir de te lire à nouveau.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 2.
Sommaire
@baud123
Degrés
Je ne sais pas ce que voulait dire hamelg mais si c'était du 1er degré, je suis du même avis que lui.
Usage
Je m'en suis beaucoup servi durant environ une année et voici ce que j'ai apprécié à l'usage :
Et derrière Metalink, il y a le support (ML n'étant finalement qu'une interface qui n'a que peu d'intérêt) :
Contenu
Sur le contenu :
La première marche est donc haute et cela ne rend pas l'outil facile d'accès, c'est une certitude. Il m'est souvent arrivé de récupérer 150 articles sans intérêt pour un problème qui me semblait bête et courant et c'est très décourageant. Mais je n'étais qu'un petit scarabé à l'époque et je ne savais pas encore que ces problèmes font partie de ceux que j'étais supposé savoir résoudre sans appeller à l'aide :-)
Plus sérieusement : ça m'arrive encore, parfois, de me retrouver avec des réponses qui ne m'aident pas mais Metalink est un outil très utile dès lors que l'on a pris le temps d'apprendre à formuler sa question. Chaque moteur de recherche possède sa logique et, surtout, les contenus indexés ont leur particularité : on ne cherche pas avec Google comme avec Metalink ni comme le Bugzilla d'ASF ni comme…
Backport
Sur le thème du backport des patchs : quelqu'un (Niniryoku ?) sait comment cela se passe avec postgres / RH / … si on achète du support ?
RDA
RDA :
Désolé de ne pas avoir d'exemple plus récent de RDA - je ne peux pas poster ici ce qui vient de l'environnement sur lequel je travaille.
Au plaisir
Au plaisir de te lire à nouveau.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 1.
@baud123
Je viens de relire la totalité des commentaires et je pense que ce n'est pas ce qui t'a rebuté avec Metalink…
Cordialement.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par BAud (site web personnel) . Évalué à 4.
merci pour cette hagiographie de metalink qui en pointe clairement les défauts (je n'en connaissais pas autant, notamment sur le côté intrusif) et qui met tant en valeur les bonnes pratiques qui ont lieu dans le libre (réactivité, pertinence, apport technique de qualité et renvoi factuel vers les documentations existantes).
Le support d'Oracle francophone est donc maintenant canadien au vu de vos horaires respectifs ?
Quels points forts avez-vous trouvé à PostgreSQL dans vos essais ? Un lien vers un benchmark officiel et public serait intéressant (au niveau fonctionnalités principalement, éventuellement au niveau performances de traitement mais cela n'est pas le principal, vu que c'est trop souvent contextuel - et trop déconnecté de cas concrets qui m'intéressent plus - et que cela peut évoluer dans le temps).
Stéphane Fermigier a pointé dernièrement le travail d'Oracle autour du logiciel libre Hadoop porté par la fondation apache (il faut lire son livre blanc pour le voir) ; y-a-t-il une incitation à travailler de plus en plus avec du logiciel libre ? Quels ont été les retours concrets faits à la communauté du libre et dans quel cadre (R&D ? contractualisation client pour remonter upstream les points corrigés ? quel a été l'accueil pour ces remontées / patchs / demandes / documentations ?)
L'a-priori de djano àmha est lié à la date de création du compte, l'oubli du sujet principal de cette dépêche : PostgreSQL (et non Oracle) et la logorrhée fournie ;-) En terme d'ouverture, pourquoi justement ne pas faire de retours de vos essais plutôt que de défendre à tous crins du propriétaire, ne faudrait-il pas faire preuve d'ouverture pour montrer ce qui fonctionne bien ? (l'exemple du projet Naca est très bien trouvé, je m'étais justement fait la remarque cette semaine :p)
Bienvenue en tout cas dans notre (autre) monde du libre sur LinuxFr.org, tout autant rempli de gens compétents mais qui hésitent parfois à s'exprimer et préfèrent souvent les discussions factuelles sur le libre (ce qui devrait devenir intéressant si cela continue :D).
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 3.
Sommaire
@baud123
Mais qui est cet intrusif dans mon bug tracking ?
Tout le plaisir est pour moi :-)
Plus sérieusement : je ne saisis pas très bien point de vue.
Il y a un truc qui m'échappe un peu dans ton discours.
A titre personnel, si des structures comme Apache et les autres me fournissent via leur outil de bug tracking un outil fait par leur soin, répondant à leur besoin, et qui me permet de joindre au ticket que j'ouvre un tar.gz contenant toutes les informations techniques qu'ils jugent utiles à l'analyse d'un dysfonctionnement, je prends à 200%.
Que trouverais-tu de choquant à cette fonctionnalité si Apache ou d'autres la proposaient ?
Il faudrait sans doute prévoir d'anonymiser quelques éléments puisque ces infos se retrouveraient alors dans la nature.
Mais, sur le fond, où serait le problème ? Ne serait-ce pas profitable à tout le monde ?
Pour info, je viens d'essayer reportbug de Debian car j'en ai entendu dire du bien et ça semblait se rapprocher de ce que je décris sur le RDA de Metalink :
Connais-tu d'autres projets open source qui disposent de ce genre d'outils ?
Il se fait tard en France
Je comprends que ton propos est de dire que le support peut être de qualité dans le monde open source.
J'en suis convaincu (j'ai déjà eu l'occasion d'ouvrir quelques tickets de bug, sur Apache ou Tomcat par exemple).
Aucune idée.
Je travaille en France mais je ne dialogue qu'en anglais avec le support Oracle et je ne leur ai jamais demandé où ils vivent.
Ta question vient peut-être de l'horaire de mes commentaires ?
Incitez-moi mais pas trop vite
(je reconnais que j'ai un peu honte d'avoir copié sur Gréco)
Je comprends que tu ouvres des questions plus générales qui vont bien au-delà de mon commentaire auquel tu réponds (car je n'ai jamais évoqué un quelconque bench Oracle vs pg dans mes commentaires).
Je me permets de rebondir sur l'incitation. Si je compare aujourd'hui par rapport à la situation d'il y a 5 / 6 ans, il apparaît (de mon point de vue à moi que j'ai et que je partage) qu'il n'y a pas d'incitation mais une normalisation bien amorcée :
Au delà du produit HP fossology et du pur aspect "licences", ceux qui se sentent concernés par cette problématique de choix de logiciels open source peuvent jeter un oeil à QSOS. Je cite : "QSOS est une méthode conçue pour qualifier, sélectionner et comparer les logiciels open source. Elle est mise à disposition de la communauté sous licence libre GNU Free Documentation License". Parmi les critères : la licence.
Si, ça colle
Je ne suis pas d'accord : au contraire, je pense que je "colle" parfaitement au sujet qui est "aller de Oracle vers PostgreSQL". C'est d'ailleurs ce qui a fait le déclic et qui m'a donné envie d'écrire un commentaire.
En effet, ce chemin de migration peut nécessiter de traiter des dizaines d'autres éléments qui font partie d'Oracle mais qui ne sont pas couverts par l'outil ora2pg ni par postgres (jobs, CDC et Streams, vues matérialisées, rman, …). Je crains de me répéter, mais tant pis : Oracle n'est pas un moteur SQL, ça ressemble plus à un socle d'exécution.
Il n'est donc pas inutile d'avoir une vision un peu plus complète de la chose.
Et puisque tu mentionnes ma "logorrhée", je vais me permettre d'en ajouter un peu :-) : il peut aussi s'avérer nécessaire, pour faire ce genre de migration de traiter quelques trucs qui ne sont peut-être pas vraiment mineurs ni drôles au niveau des requêtes SQL de l'application.
Par exemple :
Par contre, postgres supporte la clause "over", comme Oracle, et c'est une très bonne nouvelle car ça fait aussi partie des trucs qui peuvent être très difficiles à remplacer par du SQL "fait main" (pour postgres, voir ici, il y a aussi ceci pour se faire une idée).
Je reviens sur la "logorrhée" : je ne vois pas comment écrire avec moins de mots ce que j'ai écrit plus haut sur le sujet de l'"incitation à travailler de plus en plus avec du logiciel libre". On ne peut pas tout compresser à l'extrême. Mais j'admets volontiers que c'est un défaut si tu le juges ainsi.
Sun Tzu
Oups… Je viens de me rendre compte que vous me vouvoyez alors que je te tutoie. Je propose de rester au "tu", si cela vous / te convient.
Je ne sais pas comment dire que je ne défends personne, je ne cherche pas à convaincre qui que ce soit que Oracle est meilleur que les autres (car il y a autant de réponses à cette question qu'il y a d'architectures à créer, de projets à mettre en place, … et, comme tu le dis, en plus, ça varie dans le temps !).
Jusqu'à présent, il me semble, j'ai décrit ce que je connais et sauf erreur de relecture de ma part, je n'ai à aucun moment prétendu que c'était mieux qu'autre chose. On peut comprendre que c'est différent (voir "merge" par exemple plus haut dans mon commentaire).
En quoi est-ce défendre Oracle ?
On peut même aller plus loin :
Begin séquence "cours de récréation"
Trop tard !!! J'étais prem's sur NACA :-)
Et j'ai aussi QSOS et Fossology : et toc !
End séquence "cours de récréation"
Bienvenue à bord
Merci pour l'invitation, je dois t'avouer que c'est un peu rebutant de se prendre des claques quand on pense juste être sincère et factuel :
Je ne me sens pas concerné par "autre" dans "(autre) monde du libre" : je baigne dans l'open source depuis l'époque de l'Amiga grâce à un "fondu" qui envoyait des disquettes à la terre entière avec des applis faites par des passionnés + les sources (mais j'ai perdu le nom du gars en question…).
Au plaisir de te lire.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par djano . Évalué à 3.
Dites donc le sujet devient très intéressant :)
Je me mêle a la conversation car nous essayons actuellement de remplacer Oracle par HSQLDB pour exécuter les tests d’intégrations sur notre logiciel, car HSQLDB dispose d'un mode de compatibilité avec Oracle (syntaxe, mais je ne suis pas sur pour l’exécution (De toute façon, c'est configurable). J'ai entendu dire que H2 avait aussi une compatibilité avec Oracle, mais je ne l'ai pas essayé.
Il y avait bien sûr les minimes différences syntaxiques facilement corrigées dans le code de l'appli:
Nous avons trouvé quelques autres bugs qui ont été corrigés depuis:
utilisation de ROWNUM dans des requêtes imbriquées
différence dans l'implémentation de JDBC
…
Il y a également des truc plus lourd, genre SELECT COUNT(*) OVER() et START WITH… CONNECT BY PRIOR. Pour START WITH… CONNECT BY PRIOR, le mainteneur de HSQLDB nous suggérait de le remplacer par une requête "WITH RECURSIVE" standard. Pas possible pour nous :( Alors on essaie de rentrer en contact avec le mainteneur de HSQLDB pour qu'il les implémente pour nous.
Heureusement que l'on n'utilise pas MERGE dans notre appli :) Cette instruction ressemble a la méthode merge() dans Hibernate.
Bref au final, ce petit project réalisé pour un logiciel propriétaire (hélas) aura permis d'améliorer un projet libre ce qui peut être permettra a d'autres personnes de sauter le pas et de remplacer Oracle par HSQLDB?
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par windu.2b . Évalué à 2.
Pour le coup de la syntaxe table.col qui ne passe pas avec HSQLDB, c'est très étrange… Le même problème se pose-t-il si tu "aliases" la table ? Car dans ce cas, comment différencier 2 champs ayant le même mais provenant de 2 tables distinctes…
La syntaxe oracle avec un '+', j'ai toujours trouvé ça dégueulasse (en plus du fait qu'elle n'est pas portable car pas standardisée) pour (au moins) une raison : on se retrouve à devoir mélanger les jointures et les filtres dans la clause WHERE !
Et ça, caÿ mâl !!!
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par djano . Évalué à 2.
Je n'ai peut être pas été assez clair, mais HSQLDB ne supporte pas la syntaxe table.col dans un INSERT (mais a qui cela sert donc dans ce cas?), sinon il n'y a bien sûr aucun problème avec une requête SELECT.
Oui le '+' n'est vraiment pas simple a comprendre lorsque l'on lit le code SQL, heureusement qu'ils supportent la clause standard avec LEFT OUTER JOIN.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par windu.2b . Évalué à 2.
Désolé, j'avais mal lu ta première requête, qui précisait bien qu'il s'agissait d'un INSERT… OTAN pour moi !
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 2.
Plus
En fait, c'est pire : selon que le (+) est attaché aux colonnes d'une table ou d'une autre, il va s'agir d'un left outer join ou d'un right outer join (détails ici, et plus bas pour savoir pourquoi ce "bidule" existe).
Tu as peut-être du code qui date un peu, non ?
Pour ce qui est de l'ancienne notation (+) qui n'est pas standardisée, il y a une "histoire" derrière : cette notation fut introduite par Oracle sur la 8 avant que cette fonctionnalité ne soit standardisée (chercher "outer join" par exemple ici).
Standard ? Quel standard ?
Puisqu'on parle de standard, c'est d'ailleurs un sujet passionnant que celui du standard SQL (enfin, "passionnant", ça peut aussi signifier "utile pour passer une longue soirée d'hiver au coin du feu", à chacun de se faire son idée) :
C'est donc plutôt une mauvaise nouvelle car, en pratique, cela signifie qu'il n'existe plus de standard. On ne peut que se reposer sur ce qu'affirment les éditeurs de moteurs SQL et leur faire confiance.
Quelqu'un est-il assez calé en standard SQL pour contre-dire ce que j'ai écrit sur cet aspect "certification" ?
Cordialement.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par djano . Évalué à 3.
Tout a fait! Je suis passé un peu vite sur la chose.
Même pas, c'est quelqu'un qui a trouvé ça plus rapide, mais je trouve ça carrément mois compréhensible pour le premier venu.
Tiens je ne m'étais jamais posé la question de qui validait les implémentations, mais je considérais plutôt le standard SQL que comme une base syntaxique que chaque vendeur était libre de suivre… ou pas! Je ne pense pas que les vendeurs de bases de données compatibles SQL soient intéressés pour collaborer a ce qu'une telle certification existe, et surtout pas le principal vendeur actuel: Oracle.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 1.
C'est bien plus vaste : voir Wikipedia, chapitre "Standard structure".
C'est géré par l'ISO : "sql" dans la boîte de recherche te donnera une vingtaine de résultats. Les spec' sont payantes mais ça reste raisonnable.
Aucune idée sur les intérêts des éditeurs.
Par contre j'aimerais vraiment que cette certification existe quand :
D'après ce que j'ai lu sur le sujet : il existait, pendant un temps, un organisme US qui avait cette capacité à certifier un moteur SQL.
Au plaisir.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 1.
Sommaire
MVCC mon amour
Pour l'exécution, n'oublie pas le comportement MVCC d'Oracle et son implémentation : que je sache, Postgres ou HSQLDB s'appuient aussi sur du MVCC mais tu devrais vérifier que c'est suffisant pour t'éviter des effets de bord indésirables et potentiellement ardus à détecter et reproduire.
Premier écueil (mais que tu ne devrais peut-être pas avoir avec HSQLDB ?) : en résumé, un update ne bloque jamais un select.
MVCC et journaux
Second écueil : la "durée de vie"
Je ne connais pas HSQLDB mais tu devrais peut-être vérifier que ton application ne s'appuie pas (peut-être sans que ce soit volontaire) sur ce comportement Oracle.
MVCC et update contre update
De plus, ce que je viens de décrire a également des conséquences surprenantes sur le comportement des update : ce comportement est évidemment correct d'un point de vue transactionnel mais le MVCC et l'implémentation Oracle font que cela n'est pas toujours conforme à notre intuition. Donc, danger.
Si tu veux approfondir ce genre de sujets, je ne peux que te recommander un seul bouquin, celui de Tom Kyte : Expert Oracle Database Architecture. Je sais qu'il existe en version PDF.
L'exemple présenté au chapitre "Seeing a Restart" évoqué plus haut commence ainsi :
Tu as peut-être du code qui fonctionne correctement du fait de ce comportement. Comment le détecter ? Qu'en sera-t-il après portage ?
Pour les longues soirées d'hiver : que doit-il se passer si "where y = 5" correspond à des millions de lignes ? Là, l'asynchronisme prend de l'importance.
MVCC et triggers
Troisième écueil : les triggers
Au plaisir.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par djano . Évalué à 2.
Ça vient sûrement du fait qu'ils ont pu "s’entraîner" sur une base Oracle, et pas forcément sur aucune autre dans le cadre des cours.
Je suis sur que ce comportement existe dans l'appli, mais puisque HSQLDB ne sera vraiment utilisé que pour exécuter les tests d’intégration, avec une base dédiée par test (single thread), donc on devrait éviter les écueils que tu cite :)
Tu soulèves des questions bien intéressantes. Tout ceci m'a l'air dépendant de l’implémentation si le standard ne définit rien en ce sens. Sachant dans quelles conditions le standard se trouve actuellement, je ne serais pas surpris que 1) la norme SQL ne définisse rien 2) personne ne le vérifie de toute manière alors comme d'habitude chaque vendeur le fait a sa manière.
Heureusement pour nous, on n'a quasiment pas de triggers, et pas dans les cas que tu cites, alors on est tranquille de ce côté!
Merci beaucoup de me prévenir des différents problèmes auxquels je pourrais faire face! ;)
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 0.
Heu … non, c'est l'inverse, je n'ai peut-être pas été très clair : avec un moteur MVCC, un update ne bloque pas les select.
A lire ici : une discussion lancée en 2008 et qui dure, sur ce sujet. Ca a l'air sérieux.
Dans ton contexte, tu pars d'un moteur MVCC pour aller sur un autre moteur MVCC : il est raisonnable de penser que tu n'auras pas trop de soucis sur ce sujet, hors quelques comportements parfois peu intuitifs, et surtout, difficiles à reproduire.
Au plaisir.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 1.
Sommaire
Toi aussi, gagne de l'argent facilement :-)
Une question bête : quelles sont les motivations derrière ce remplacement ?
Est-ce seulement, ou majoritairement, un aspect financier ?
Si tel est le cas, je te suggère de regarder deux trucs chez Oracle :
Si tu mènes un chantier "comment sortir d'Oracle", ces deux trucs, surtout le premier, peuvent te donner un peu d'air en attendant d'avoir terminé en fournissant à tes développeurs un environnement technique qui est très proche de ce que tu as en production (= "c'est bien").
Si tu as des besoins pas trop élevés en volumétrie et fonctionnalités, le second truc peut là aussi te donner de l'air : c'est gratuit, y-compris sur la prod'. Donc, ça peut faire "sauter" une licence, ou t'éviter d'avoir à en racheter tant que tu n'as pas terminé ton chantier de migration.
Cela ne te fera pas sortir d'Oracle, c'est sûr, mais ça peut de permettre de réduire tes coûts et / ou d'améliorer la qualité des test en attendant d'avoir remplacé le moteur SQL de ton produit.
Détails ci-dessous.
OTN
Tu devrais regarder de près ce que dit la licence OTN (Oracle Technology Network Development License Agreement).
Je cite :
Cela te permet de télécharger ici la version Enterprise ou Standard en 11g ou 10g (plus bas dans la page pour la 10g) et de l'installer comme tu veux où tu veux, tant que c'est pour du dev, sur du Windows, du Linux, du Solaris, de l'HP/UX, …, en 32 bits ou en 64 bits. La 9i est peut-être aussi disponible sous cette licence mais je ne connais pas assez cette version pour t'en parler.
Tu peux même t'en servir pour faire des démos de ton produit. Ils ne sont pas que idiots chez Oracle : si tu fais une démo de ton produit avec un moteur Oracle, c'est tout bénef' pour eux, alors autant te faciliter la vie et te permettre de le faire gratuitement (toi et / ou ton client passeront "à la caisse" plus tard, quand tu auras vendu ton produit et que ça passera en production).
Mais si cette licence gratuite te permet aussi d'avoir des développeurs qui utilisent pour leur activité le même moteur que celui qui est en production, autant en profiter :
Il y a un seul danger, mais un véritable danger, auquel il faut faire attention :
Mais pour le reste, c'est tout bénef.
Warning : je ne suis expert en licence. Prends le temps de lire ce que dit la licence OTN et fais-toi ton opinion. Dans mon environnement, j'ai conclu que "OTN = gratuit pour les dev". Mais cela n'engage que moi.
Oracle Express
Il y a aussi la version Oracle Express :
Je n'en dis pas plus sur cette version, je ne l'ai installée qu'une fois "pour voir", donc mon niveau de connaissance est peu éloigné du zéro absolu.
APEX fait sans doute d'autres trucs car on peut aussi créer des applis Web, des rapports PDF, etc, mais là encore, je n'y connais pas assez pour t'en parler sérieusement. Il y a des tutoriaux par là par exemple, ou certainement ailleurs sur OTN.
Au plaisir.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par weonbin . Évalué à 1.
Vu que le compte a été crée pour l'occasion (comme ce commentaire) et que le contenu ressemble fort à un copier-coller d'une brochure commerciale oracle, je dirai qu'il faut prendre ca avec des pincettes.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 2.
@weonbin - Je suis resté "sur le c*l" en lisant ton commentaire, je ne sais pas trop comment te répondre, j'ai beaucoup hésité car je ne suis pas un habitué de ce genre de lieu d'expression et je n'en connais pas les règles, explicites ou implicites, donc j'ai toutes les chances de me planter.
En fait, je ne sais même pas comment je dois comprendre ton commentaire : est-ce méchant, désinvolte, dois-je t'ignorer, pourquoi utilises-tu le conditionnel pour discréditer mon propos en une petite phrase fielleuse et rapide au lieu de prendre le temps de vérifier par toi-même les documentations que je cite, veux-tu seulement me faire comprendre que la forme de mon post te semble inappropriée, pourquoi le dire ainsi alors, … ?
Comme je ne sais pas comment comprendre ton commentaire, j'ai plusieurs idées de réponses en tête et je vais donc te fournir celle-ci, qui est factuelle, donc à priori appropriée (je l'espère - sinon, il ne me restera plus qu'à ouvrir un nouveau compte et publier un commentaire le jour même :-)) :
Cordialement.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par djano . Évalué à 3.
Bah, ne le prend pas mal, ça fait partie du folklore et de l'historique local. Les comptes créés pour l'occasion pour troller ont fait partie intégrante de l'histoire du site, avec ce que l'on appelle les "multi" (les utilisateurs avec plusieurs comptes).
Ça vient du fait que le site est ouvert (comme l'open source), il est donc plus facile pour les trolleurs de venir faire des dégâts tout en ne faisant aucune contribution positive. La communauté se blinde contre ça, mais du coup il est plus difficile pour un nouvel entrant de s'y habituer.
Bref, ce n'est pas personnel, et tu as bien prouvé que tu avais de la ressource pour répondre.
Il y a également un historique de personnes qui ont un avis différent de l'opinion moyenne du site (PasBill PasGates, Zenitram), et bien je peux te dire qu'il faut avoir la peau dure!
Au plaisir de lire tes commentaires futurs.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 1.
Je confirme, c'est bien ainsi que cela semble fonctionner :-)
Bien compris.
J'ai également lu ton autre commentaire : merci d'avoir eu le cran d'écrire que tu t'es trompé.
En espérant qu'on se recroise au hasard de futurs commentaires (après j'arrête d'envoyer des fleurs, sinon on va croire que c'est un coup monté ou un truc louche entre nous deux :-)
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par djano . Évalué à 2.
C'est quand même fou le nombre de pseudo qui se sont créés a l'occasion de cette dépêche! :)
Bon ta prose est très jolie, mais elle a quand même l'air un peu trop carrée pour avoir été rédigée comme un commentaire.
Copier / coller avec un peu de changement du texte pour appuyer un peu plus ton disclaimer?
Bof j'y crois pas, mais comme tu dis: a chacun de juger (ou pas).
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 2.
@djano
Carrés, ronds, losanges, … : après la lutte des classes, voici la lutte des formes :-)
Je le prends au 1er degré, donc : merci.
Tu as quelque chose de factuel pour … appuyer ;-) ton propos ?
"Trop carré" ? Je crois que c'est la première fois que l'on me reproche de rédiger un texte qui est trop carré : je trouve que c'est plutôt quelque chose de positif.
Et si ça ne ressemble pas à un commentaire, c'est peut-être parce que j'ai pris le temps de préparer mon texte. Je n'ai pas tenu spécialement de comptabilité, mais ça doit faire au moins 3 ou 4 heures pour les deux commentaires combinés : il faut organiser ses idées, tenter de trouver des exemples "parlants", éviter les redites dans la formulation, trouver la meilleure formulation (objective, non ambigüe, factuelle), et identifier un point d'entrée adéquat dans la documentation technique, point d'entrée auquel un lecteur curieux pourra se "raccrocher" s'il veut en savoir plus ou s'il souhaite se faire sa propre idée.
J'ai pris la peine de citer la documentation technique de référence pour que tu puisses te faire ton idée or j'ai vaguement le sentiment que tu juges mes commentaires sur leur forme : as-tu pris le temps de lire cette documentation, même sommairement, pour te faire ton idée autrement que sur la forme de mes commentaires, même si cette forme te semble inhabituelle ?
170 minutes
Revenons à ton commentaire de manière plus globale : je ne pense pas trop me tromper en faisant l'hypothèse qu'il t'a fallu moins de dix minutes pour l'écrire. Tu confirmes ?
Il m'a fallu (au moins) 3H pour écrire mes deux premiers commentaires.
Pourquoi ne consacrerais-tu pas 170 minutes supplémentaires de ton temps à nous faire découvrir des fonctionnalités méconnues de postgres ? Ou de slony ? Ou d'un autre logiciel de ton choix ? (ou la moitié de 170 si tu penses que j'écris lentement)
Dans l'attente d'avoir le plaisir de te lire, cordialement.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par djano . Évalué à 3.
Ha ha! Je comprend que mon commentaire ne t'aie pas du tout plus.
Au temps pour moi, tes commentaires suivant m'ont montré que tu n'était pas celui que je pensais que tu étais, donc je te prie de m'excuser. En effet tes commentaires était très fouillés et je te crois sans hésiter lorsque tu dis qu'il t'as fallu 3-4 heures pour les écrire. Merci de l'avoir fait.
La forme de ton commentaire m'avait donné a penser que c'était copié coller de quelque part. Je me suis visiblement trompé et j'en suis content. Je préfère des commentaires appuyés que les commentaires stériles. Comme baud123 l'a fait remarqué, la date de création de ton compte était suspecte (vieille technique connue par ici), mais je me rappelle avoir créé mon compte dans des circonstances similaires a toi. J'avais lu le siite pendant longtemps avant de vouloir poster un jour et donc de devoir créer mon compte.
Je vais relire un peu tout ça et sûrement revenir avec des commentaires plus pertinents. A plus!
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par djano . Évalué à 3.
En effet, je ne savais pas qu'il y avait tout ça dans Oracle! (Un serveur JMS!!)
Mais tout ça a du sens si l'on pense a tout ce dont une BD Oracle est capable, une fois debuggé, pourquoi ne pas le fournir aux utilisateurs et appliquer les même standards de documentation?
Je dois avouer que je suis bluffé par les rapports de perfs avec AWR et comment OEM rend cela facile. Je me demandais justement si PostgreSQL avait un équivalent aux AWR? Apparemment oui: [dans http://blog.postgresql.fr/index.php?post/2009/04/28/Nouveaut%C3%A9s-PostgreSQL-8.4], chercher "fonctions de monitoring" (explain plan, pg_stat_statements, pg_statsinfo). Je ne sais pas a quel point cela peut être comparé avec les AWR d'Oracle, mais je suppose que cela a été amélioré depuis.
C'est vrai que la doc Oracle est bonne - merci de me la faire découvrir - mais j'ose espérer que la doc pour PostgreSQL est également bien fournie.
Je ne sais pas si PostgreSQL a l'équivalent de tout ce que tu mentionnes - probablement pas (Je ne vois pas quel intérêt ils auraient à avoir un serveur JMS :) ) - mais ils font des progrès conséquents à chaque nouvelle version, ce qui est pas mal du tout pour une base de donnée libre et développée entièrement par une communauté plutôt qu'une entreprise.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . Évalué à 1.
Au delà de l'affrontement "open source vs propriétaire", des pratiques commerciales, du coût des licences, etc, c'est un produit que je trouve techniquement jouissif. Il y a une flopée de fonctionnalités à découvrir, bien plus que le peu que je connais et que j'ai tenté de décrire de mon mieux (flashback pour "voir" la base dans le passé, total recall, la compression, le chiffrement, DBMS_ADVANCED_REWRITE pour remplacer "à la volée" une requête émise par une application dont on n'a pas le code source ou que l'on ne peut plus recompiler, Edition-Based Redefinition pour versionner une base "à chaud", un peu comme Subversion le ferait dans un processus branche + merge, les Function based index, etc etc c'est monstrueux : à coté, la doc d'un JDK récent ressemble à une promenade de santé)
Il y a bien sûr d'autres produits, open source, qui sont tout autant "jouissifs" au niveau technique.
Mais si cela permet, dans le respect des contraintes d'un projet, d'aller bosser le matin en se disant des trucs tels que "on m'a imposé Oracle / je n'aime pas Oracle / etc mais je vais quand même apprendre des choses aujourd'hui, me faire plaisir et peut-être trouver une solution satisfaisante à un besoin métier", ce serait dommage de s'en priver.
Si tu aimes "mettre les mains dedans", autant se faire plaisir (plutôt que de prendre des anti-dépresseurs :-). Après le bouquin de Tom Kyte pour l’échauffement, cela te donnera l'occasion de lire des trucs tels que ce bouquin : 450 pages, sans les annexes, sur l'optimiseur de requête (une version plus récente est peut-être sortie). C'est ardu mais on le referme en ayant appris quelque chose.
Cela n'empêche évidemment pas de vouloir ou devoir migrer vers un autre moteur pour plein de bonnes raisons, ou de vouloir démarrer un projet avec un autre moteur qui fait ceci ou cela "plus mieux" qu'un autre.
D'après leur doc, EnterpriseDB va dans cette direction, en visant à offrir ce que font notamment OEM + AWR ; voir par exemple ce PDF.
D'après la doc, cela semble moins riche, mais si on me demande d'aller chercher une baguette à la boulangerie du coin, je ne vais pas prévoir d'acheter une voiture de luxe avec intérieur cuir.
Et ça "sent" clairement l'affrontement avec Oracle.
C'est indéniable.
Voir par exemple les sous-chapitres ici pour tout ce qui touche au monitoring des performances.
On peut être plus réservé sur les probes :
Il y a certainement de bonnes raisons pour qu'ils aient choisi cette voie.
Et, là encore, ça "sent" l'affrontement direct avec Oracle (notions d'events et latchs).
En tout cas, même si ce n'est pas dit clairement, la cible est identifiée et ça va donner du boulot aux auteurs d'ora2pg :-)
Au plaisir.
# Dommage...
Posté par Andréas Livet . Évalué à 0.
Dommage pour nous mais la où je travail on utilise massivement les packages oracle, les variables de package et les valeurs par défaut pour les paramètres de fonctions.
Donc pas de migration possible pour nous.
De plus, notre BDD est aussi serveur web ; et oui on utilise PL/SQL comme d'autres utiliseraient PHP, Java ou Ruby ! Super non ? :)
Bref, j'aurai aimé passé sous PostgreSQL mais ça ne sera pas pour tout de suite.
A+
[^] # Re: Dommage...
Posté par djano . Évalué à 3.
Oracle Forms est aussi pas mal dans le genre "je me lie ad vitam æternam avec ma base de données".
C'est une des raisons pour laquelle l'architecture 3 tiers a du succès.
[^] # Re: Dommage...
Posté par ekp . Évalué à 1.
@djano
La vie est dure
Tu as raison, la vie est parfois dure.
Je ne vais pas parler spécifiquement de Oracle Forms car je n'y connais rien mais de la problématique de portage que tu abordes.
Si tu as ce genre de problème à résoudre (ça y ressemble un peu, étant donné l'amour que tu portes à Forms), tu pourrais te rapprocher de Eranea après avoir lu cet article de linuxfr.
Pour aller vite :
Mais il y a de l'espoir
L'existence du produit, qui a manifestement assez de succès pour construire une société autour, montre qu'il est possible de "sortir" totalement d'un environnement avec des écrans verts 80x25 pour aller progressivement vers quelque chose de très différent.
Certes, 3270 et OracleForms sont différents mais s'ils ont réussi à le faire pour 3270, alors on peut espérer que c'est également faisable pour OracleForms.
Et c'est une bonne nouvelle.
Qu'en penses-tu ?
Cordialement.
Précisions, disclaimer, etc
[^] # Re: Dommage...
Posté par djano . Évalué à 2.
Merci de ta réponse.
Heureusement pour moi je ne suis pas du tout dépendant de Oracle Forms au boulot, sinon j'aurais déjà changé de boulot :) C’était juste un exemple pris comme ça.
J'avais été assez fasciné par le projet NACA, voila une approche raisonnée (petit pas), innovante (Je ne connais pas d'équivalent de remplacement d'une stack complète) et couronnée de succès! Toute mes félicitations a l'auteur du projet.
Je ne savais pas qu'ils avaient créé une boite autour. Je leur adresse tous mes encouragements!
[^] # Re: Dommage...
Posté par Didier DURAND (site web personnel) . Évalué à 0.
Bonjour Djano,
Merci pour les encouragements!
De toute façon, on s'éclate bien: le sujet est passionnant et, en cette période économiquement difficile, le sujet intéresse les DSI.
cordialement
d. durand (fondateur d'Eranea)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.