Migrer de Oracle à PostgreSQL : Ora2Pg

Posté par  (site web personnel) . Édité par baud123, Florent Zara, olivierweb et Yves Bourguignon. Modéré par claudex. Licence CC By‑SA.
Étiquettes :
45
13
mar.
2012
Base de données

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

  • # question bête

    Posté par  . É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  . É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  (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é).

        • pour le hint sur les requêtes :
          • cela se voyait beaucoup en Oracle 7, il a fallu tout refaire en Oracle 8 (pas trop au passage en 9 iirc…),
          • beaucoup de migration en 10 ont échoué à cause du changement de moteur et régressions monstrueuses sur les performances,
          • le passage de Oracle 10 à 11 a l'air moins catastrophique déjà de ce que j'ai pu en voir (moins de cas, néanmoins…).
          • Donc bon, quitte à réécrire les requêtes, dans ce cas autant les réoptimiser pour PostgreSQL, il y a les plans d'exécution pour cela.
        • pour les pools de connexion (lorsqu'ils sont utilisés…)
          • d'une part il n'y en a pas forcément besoin (bon, je n'ai qu'un exemple de migration PostgreSQL vers Oracle, qui n'en utilisait pas initialement et où c'est devenu obligatoire, visiblement à cause d'Oracle vu que ça tenait la charge pour 300 utilisateurs connectés auparavant avec un tomcat/PostgreSQL mais pas avec JBoss/Oracle dès 50 utilisateurs connectés…)
          • d'autre part, il y a PgPool http://wiki.postgresql.org/wiki/Pgpool-II disponible au moins depuis PostgreSQL 8.4 (cf. par exemple http://www.dalibo.org/hs44_pgpool_le_pooler_multitache ah bah tiens, une doc' de la boîte qui soutient ora2pg, je n'ai pas d'actions chez eux ;-) )
        • pour le partitionnement :
          • c'est une option payante d'Oracle (elle double le prix du moteur)
          • de ce que je vois sur http://docs.postgresqlfr.org/9.1/ddl-partitioning.html cela correspond à ce qui peut être mis en œuvre côté Oracle (surtout du partitionnement par date pour historiser plus facilement et gérer les grosses volumétries… je l'ai rarement vu ailleurs que sur des bases de datawarehouse)

        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  (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  (Mastodon) . Évalué à 10.

            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 )

            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  (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  . É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  . É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  (site web personnel) . Évalué à 6.

                En gros, 1 CPU Enteprise coûte 38 000€

                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  . É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  (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  . É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  (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  . É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  (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  . Évalué à 2.

                              URL ?? la source c'est moi, j'étais le DBA - les données viennent de PERFSTAT

                              • [^] # Re: question bête

                                Posté par  (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  . É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  (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  . Évalué à 2.

                              La machine est quand même impressionnante

                              Envoyé depuis mon lapin.

                            • [^] # Re: question bête

                              Posté par  . É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  . É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  . É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  . É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  . É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  . É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  (site web personnel) . Évalué à 10.

        Oracle a le gros avantage de proposer quasiment toutes les fonctionnalité de "gestion de données":

        ah mais PostgreSQL aussi ;-)

        • langage PL/SQL => langage PL/pgSQL
        • recherche full text, fuzzy => existe au moins depuis PostgreSQL 8.3 voir full text search et fuzzystrmatch (soundex, distance de Levenshtein, metaphone…)
        • données spatiales (double encore le prix du moteur avec Oracle…) => c'est ce pour quoi PostgreSQL est bien connu tout de même grâce à PostGIS avec utilisation possible dans pas mal de logiciels de système d'information géographique : GeoServer, MapServer, Quantum_GIS
        • données sémantiques => ça je ne sais pas ('fin stocker du RDF dans du PostgreSQL ou toute autre base, ça doit bien exister…)
        • [^] # Re: question bête

          Posté par  (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  (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  . É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 :

              • les backups complets sont bien mais on arrive vite à des problèmes de taille de la sauvegarde
              • difficulté de mettre en place des backups incrémentaux -> pas le même principe que le backup avec pgdump
              • pas de possibilité facile de sharding (le partitionnement des tables est faisable mais c'est purement manuel et ça fait un peu bricolage)
              • même avec auto-vacuum, on a des problèmes de bloat :
                • le niveau de "bloat" des tables nécessite (dans notre cas) une commande CLUSTER de temps en temps
                • le niveau de "bloat" des index nécessite (dans notre cas) une commande REINDEX de temps en temps
              • avec beaucoup de transactions par seconde (quelques milliers d'insertions par seconde dans mon cas) on tombe vite sur le problème du "transaction wraparound"
              • Il n'y a pas de CLUSTERED INDEX comme Oracle ou SQL Server (si on sauve principalement des données de type CLEF/CLEF/VALEUR, l'index prend presque autant d'espace que la table)

              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  (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  . É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  (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  (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  . Évalué à 4.

        J'ai cru que tu parlais de PostgreSQL! :D

    • [^] # Re: question bête

      Posté par  . Évalué à 2.

      la "prestance" du nom…

      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  . É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  . É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  . É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  . É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  . Évalué à 1.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: [^] [-] # Re: question bête

        Posté par  . Évalué à 9. Dernière modification le 13 mars 2012 à 19:26.

        au delà de 1To PostgreSQL a un peux du mal,

        T'as pas des sources ?

        le parallélisme n'est pas supporté nativement

        Qu'entends-tu par « parallélisme » ? Moteur avec thread ? Replication ? Load balancing ?

        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 :

        au delà de 1To PostgreSQL a un peux du mal,

        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 :

        • comment est structurée la base
        • comment est optimisée la base
        • comment est indexée la base
        • quelles sont les requêtes

        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.

        le parallélisme n'est pas supporté nativement

        Ç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  . Évalué à 3.

          Je ne sais pas si c'est quelqu'un de chez oracle, ou un double compte d'une moule qui veux juste troller.

          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  . É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  . É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  (site web personnel) . Évalué à 4.

      Le seul point qui je vois en faveur de PostgreSQL est le prix.

      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  . É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  (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  . É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  (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  . É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  (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  . É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  (site web personnel) . Évalué à 2.

                son exemple est largement incomplet (outre être irréaliste) :

                • la « requête » proposée est bien sûr beaucoup plus complexe
                • ce n'est pas qu'une addition : il y a beaucoup d'I/O pour générer la facture bien sûr
                • les contrats et services souscrits par le client modifient notablement le décompte des appels et leur facturation (outre l'historique des offres à prendre en compte au cours du temps, surtout sur plus de 15 ans…)
                • des clients, c'est quelques millions, ce qui en fait des itérations :-)
        • [^] # Re: [^] [-] # Re: question bête

          Posté par  (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  . É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  . É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  . É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  . É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é:

        Do not use the VARCHAR datatype. Use the VARCHAR2 datatype instead. Although the VARCHAR datatype is currently synonymous with VARCHAR2, the VARCHAR datatype is scheduled to be redefined as a separate datatype used for variable-length character strings compared with different comparison semantics.

        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  . Évalué à 1.

          Sur VARCHAR: la seule phrase que tu aurais dû recopier est la première:

          Do not use the VARCHAR datatype.

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

            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!

            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  . Évalué à 7.

      je pense qu'un [select * from where name=''] ne retourne jamais rien avec oracle.

      Tu m'étonnes ! Il manque le nom de la table… :-p

  • # ratp + carrefour

    Posté par  . É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  . É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.)

  • # Oui mais Oracle n'est pas un moteur SQL...

    Posté par  . É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  . É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  . Évalué à -2.

        @hamelg

        Tu as oublié de citer le site de support metalink qui est également un atout.

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

      • (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 ;

      PL/pgSQL

      • du Java avec compilateur natif ;

      Peut être est-ce comparable à PL/Python

      • un outil de backup / restore évolué (gestion de la péremption des backups, de leur redondance, …) ;

      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.

      • une documentation très complète ;

      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  . Évalué à 2.

        Je tiens à préciser que j'ai plussé le commentaire precédent

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

        (backup) Il faut bidouiller aussi

        "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  (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  . É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

        Tu parles beaucoup de Oracle 10g, dépêche-toi le "support premier" est terminé depuis juillet 2010 ;-)

        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 :

        Given the strategic nature of Oracle GoldenGate, Oracle Streams will continue to be supported, but will not be actively enhanced. Rather, the best elements of Oracle Streams will be evaluated for inclusion with Oracle GoldenGate.
        Current customers depending on Oracle Streams will continue to be fully supported, and Oracle Streams customers should continue using the feature wherever it is deployed today.

        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é :

        • Il y a au moins deux IHM disponibles via des produits Oracle (gratuits).
        • C'est un scheduler dédié aux problématiques de base de données et qui permet - par exemple - de mettre en oeuvre une sorte de QoS, comme pour les réseaux, mais dans un contexte de base de données.

        Pour l'IHM :

        • Elle est fournie nativement avec le produit OEM que je cite dans mon premier post.
        • Il y a aussi SQL Developper (à télécharger gratuitement chez Oracle). Pour les jobs, tu peux jeter un oeil à cette séquence, ça commence à la planche 13, et à partir de la planche 28 tu constateras que c'est assez éloigné d'un truc qui n'a pas d'interface graphique : on peut afficher les graphes de dépendance des tâches et ce genre de trucs.
          • Plus d'infos sur SQL Dev ici.
        • Il y a aussi d'autres outils tiers, Toad par exemple - je n'en suis pas fana à titre perso mais c'est manifestement un produit qui a des utilisateurs fidèles.

        Pour les fonctionnalités :

        • Le calendrier sur lequel s'appuie le cadencement "basique" offre des possibilités que l'on peut qualifier de "crontab aux stéroïdes". Si tu veux te faire une idée rapide, tu peux jeter un oeil au chapitre "Calendaring Syntax" de DBMS_SCHEDULER.
          • Un petit exemple, pour un job à déclencher le dernier lundi du mois sauf si ça tombe un jour férié : 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).
          • Au passage : si quelqu'un connaît un scheduler (pas cher) qui sait faire facilement ce genre de choses et qui fonctionne à l'identique sur Windows, Linux et mainframe, je suis preneur d'informations et de liens vers la documentation technique du produit.
        • Le scheduler s'appuie sur trois concepts qui me semblent aussi correspondre à du "crontab on steroids" : les fenêtres de temps, les classes de job, et les plans de ressource (traduction personnelle "à la hache"). En synthèse, car c'est assez riche en protéines :
          • Une fenêtre de temps permet de définir des plages temporelles telles que "du vendredi 20H au samedi minuit" (voir chapitre "Windows" ici, et le doc de manière globale qui présente les concepts du scheduler).
          • Un plan de ressource permet de définir des quotas d'utilisation du moteur (x % de CPU, consommation de journaux, …), des règles de bascule vers un autre plan de ressource si une application dépasse les bornes (durée d'exécution max par exemple), et des règles d'association par défaut de toutes les sessions ouvertes sur la base (si connection depuis la machine nommée ABC, alors utiliser tel plan de ressource pour les requêtes de cette session). Pour en savoir plus, c'est ici.
          • Enfin, les classes de jobs font le lien entre les deux concepts mais mieux que je ne l'explique ici avec cette phrase lapidaire.
          • Il est ainsi possible de définir des choses telles que "mon job qui fait des trucs super lourds a le droit d'utiliser 80% du temps de calcul d'Oracle tous les vendredi de minuit à 2H du matin, s'il fonctionne encore après 2H alors il devra se limiter à 30% (sauf s'il est tout seul, auquel cas il pourra utiliser 100%)".
          • Cela permet donc de mettre en oeuvre une sorte de QoS, comme pour les réseaux, mais dans un autre contexte.

        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, …

        • Cela fait un composant en moins dans l'architecture logicielle et c'est toujours bon à prendre car c'est une adhérence en moins, des montées de version en moins, des test d'interopérabilité en moins, une hotline en moins, … = moins de complexité.
        • Un backup de la base = un ensemble cohérent avec les données, et le reste, dont les jobs, leur état, leurs journaux d'exécution (et aussi les files de messages par exemple).
        • On peut déployer en prod' sur Solaris, migrer un jour sur du Red Hat, tout en ayant installé Oracle sur les postes Windows XP des développeurs pour leurs tests (ça fonctionne très bien pour du dev), … Dans tous ces types de scénarios :
          • le scheduler reste le même, il exécute donc les mêmes jobs aux mêmes heures en se comportant de la même manière que ce soit en production, en homologation / recette, en développement, …,
          • les DBAs sont à l'aise pour travailler avec un développeur sur une problématique particulière car le socle technique est Oracle et non pas l'OS (les OS),
          • et réciproquement un développeur est à l'aise pour aider les DBAs quand il y a un souci en prod'.
        • Pas besoin d'avoir un login sur le système d'exploitation pour intervenir / superviser / analyser, donc réduction de la surface d'attaque (pas que Oracle soit 100% secure par défaut : c'est seulement que "pas de login sur l'OS" = bon à prendre).
        • Pour info : Oracle mange sa propre nourriture puisque le scheduler est mis en oeuvre pour des tâches d'administration système.

        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 :

        • Il est possible d'envisager des cas d'usage un peu plus riches, avec par exemple plusieurs serveurs, des files de messages, et des jobs qui se déclenchent sur réception de tel ou tel message, puis mettent à jour des tables dont les données sont répliquées sur le serveur A, B ou C selon la nature de l'opération (A reçoit tout mais B ne reçoit que les insert / update) ou selon le contenu de la donnée elle-même (les factures payées sur un serveur, les autres sur un autre serveur), … On peut aussi mettre du XML dans le scénario, c'est pris en charge.
        • Ceci s'exécute dans un contexte 100% transactionnel, ce qui réduit considérablement les question à se poser pour les reprises après crash, coupure réseau, …
        • Ceci se sauvegarde et se restaure de la même manière de partout.
        • Ceci ne nécessite qu'un seul produit, un seul langage et ça fonctionne à l'identique sur de multiples systèmes d'exploitation.
        • Ceci nécessite aussi d'investir du temps pour connaître le produit et d'avoir des personnels compétents, on s'en doutait un peu.

        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 :

        • Si on utilise Oracle (ou autre) juste pour faire insert / select, alors, pour résumer "à la hache" car il se fait tard, on a acheté une voiture de luxe avec un moteur surpuissant mais on ne sert que du cendrier : cela facilite sans doute un portage, mais on peut aussi aussi se demander "que puis-je faire de plus, mieux, ou plus vite" avec ma super voiture pour en rentabiliser le prix, pour en "avoir pour mon argent" ? Au lieu de faire des transactions XA, puis-je simplifier mon code, voire le supprimer ? Comment faire pour ne pas avoir à gérer les cas de reprise après crash entre un transfert via sftp et une piste d'audit en base de données ? Comment faciliter le travail des DBA et des sysadmin pour qu'ils aient des environnements moins hétérogène à gérer ? …
        • Si on cherche à exploiter à fond ce que propose Oracle (Sql Server, DB2, MySql, postgres, openingres)… peu importe) pour en tirer la dernière goutte de "force de frappe", on rentabilise alors le coût de l'engin (licence, support, formation, …) mais un portage sera évidemment plus dur.

        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  . Évalué à 2.

        Sommaire

        @baud123

        Degrés

        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é :-)

        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 :

        • Même quand un débutant, un stagiaire, …, toi, moi, pose une question bête, idiote, un truc simple qui peut se résoudre par Google ou en lisant la documentation, on ne te répond jamais autrement qu'avec une solution. Et le ticket n'est fermé qu'avec ton accord explicite.
          • C'est le B.A/BA, le strict minimum, mais cela n'en reste pas moins appréciable.
          • J'ai vu passer des trucs qui méritaient largement un RTFM ("Lis le foutu manuel"). Mais le support traite quand même le ticket jusqu'au bout.
        • Les échanges "un à un" Oracle / client sont privés, ce qui te permet de donner des informations au support sans craindre qu'un concurrent tombera dessus et s'en servira contre toi, par exemple en expliquant à tes propres clients tous les petits ennuis techniques que tu as sur ton système d'information.
        • On peut enregistrer des modèles de tickets : on peut ainsi y pré-renseigner tout ce qui est constant ou peu volatile (version d'OS, …) puis s'en servir ensuite pour ouvrir rapidement un ticket.
        • Metalink permet de télécharger plusieurs outils dont des outils de "health check" qui facilitent le diagnostic de premier niveau (voir par exemple ici).
        • Metalink permet à OEM de récupérer la liste des patchs qui sont sortis mais qui n'ont pas été appliqués sur ta base de données.
          • Si on est dans un réseau protégé : un script permet de télécharger la liste de référence depuis Internet pour la recopier ensuite via un moyen sécurisé sur le réseau interne protégé au sein de ton infrastructure (j'ai testé mais ce n'est pas déployé).
          • Dans la foulée, OEM permet ensuite de déployer lesdits patchs (jamais testé à titre perso) et si tu as sorti le chéquier pour avoir la version Grid d'OEM, tu peux administrer ainsi toutes tes bases de données sur tous tes serveurs depuis un point central (je sais qu'OEM est aussi capable d'installer - au moins - l'OS et la base de données mais je n'en sais pas plus que ça sur ces sujets).
        • Il y a un outil nommé RDA (voir liens et exemples plus bas) qui permet de collecter une tétra-floppée d'informations techniques sur l'OS et la base de données afin de joindre la chose au ticket que l'on ouvre.
        • Si les règles de sécurité de l'environnement de prod' le permettent, cette remontée d'information peut être automatisée. Ainsi, quand on ouvre un ticket, le support dispose déjà d'une "photo" très détaillée du système et datant d'au plus 24 heures (jamais testé à titre perso).
        • Metalink te permet de gérer les utilisateurs de ton entreprise qui y ont accès, avec quels droits (ouvrir un ticket ou pas, …), et sur quels produits. Cela permet de donner un accès en lecture à un débutant ou un stagiaire. Quand on est un peu parano, cela permet aussi d'être certain que l'on peut fermer l'accès d'un salarié qui quitte la société pour aller bosser chez le client ou chez un concurrent.

        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) :

        • Le support Oracle peut (si on l'y autorise) prendre la main à distance sur le poste de travail du DBA afin d'investiguer en "direct live". Je ne sais pas ce que c'est comme solution technique mais l'important est que l'on peut suivre ce que fait la personne du support (comme du VNC par exemple). Ainsi, le support ne se connecte pas directement depuis son PC à ma base, ce qui peut rendre "nerveux" dans certains environnements professionnels, mais il peut quand même intervenir un week-end très (très) tard le soir et remettre les choses en ordre pour le lundi matin.
        • Quand tu as un souci sur un environnement de prod' et qu'il existe un patch (ou qu'un patch va être créé), tu peux demander que le patch soit backporté sur ta version du moteur, celle que tu as validée, recettée, ce qui fait que tu ne veux surtout pas faire une montée de version. Tu veux juste et uniquement corriger ton problème sans prendre de risques.
          • Je ne suis pas dans le secret des Dieux : je ne connais pas le coût de ce niveau de support, je me contente de m'en servir.

        Contenu

        Sur le contenu :

        • Le support Oracle et les consultants (les vrais, les "poilus sous les bras") utilisent Metalink. On peut voir le côté négatif et penser que cela explique le coût de la maintenance. On peut aussi penser que cela est plutôt positif en vertu du principe "eat your own dog food".
        • Je pense que Metalink est un outil pour les DBA et c'est - peut-être ? - ce qui t'a rebuté : on ne s'en sert pas pour apprendre quelque chose "from scratch" ou pour donner un coup de pied dans l'arbre en espérant que ce que l'on cherche va tomber tout seul. Il faut y aller après avoir déjà bien rongé son os chez soi.
        • Formulé autrement : de mon point de vue, c'est un outil de support dont le seuil d'entrée se situe quelque part entre le "niveau 2" et le "niveau 3".

        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 :

        • PSOUG
        • un exemple (ancien et sur une base pas bien énervée) de ce que génère RDA : cliquer ici puis "RDBMS" dans la partie en haut à gauche. Il y a des choses comme "V$System_Event" qui vont être utiles à un DBA un peu "poilu", d'autres trucs comme "Latch Information" qui sont pour le "très poilu" ou le support niveau 99 chez Oracle mais qui permettent cependant de faire le lien avec d'éventuels points à vérifier tels que décrits dans les articles de Metalink. Et tout le reste, qui fournit un panorama complet du système, depuis le sous-sol jusqu'à la cheminée.

        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  . Évalué à 1.

          @baud123

          Je pense que Metalink est un outil pour les DBA et c'est - peut-être ? - ce qui t'a rebuté

          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  (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  . Évalué à 3.

            Sommaire

            @baud123

            Mais qui est cet intrusif dans mon bug tracking ?

            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)

            Tout le plaisir est pour moi :-)

            Plus sérieusement : je ne saisis pas très bien point de vue.

            • Dans un autre de tes commentaires, on comprend que "être indexé par Google" = "c'est bien". Or, à force d'indexer la terre entière et de collecter des téra-octets de données sur les recherches faites par 66% des utilisateurs d'un moteur, Google en sait sans doute plus sur toi et moi que notre propre médecin.
            • Mais dans ton commentaire que je mets en citation, tu considères comme intrusif le fait de donner ton accord à une équipe de support pour qu'elle puisse disposer d'une description fiable de ton environnement technique (et c'est un choix de ta part : si cela ne te convient pas pour n'importe quelle raison, rien ne remonte à l'équipe support en dehors du texte que tu as saisi lors de l'ouverture de ton ticket de bug)..

            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 :

            • Je ne suis pas allé au bout des étapes de reportbug car je ne connais pas le déroulement de leur "wizard" et je ne veux pas prendre le risque d'ouvrir un faux ticket.
            • C'est mille fois mieux qu'un pauvre formulaire HTML statique, y'a pas photo, et bravo à Debian mais, de ce que j'ai vu, cela ne remonte pas beaucoup d'infos sur mon environnement.

            Connais-tu d'autres projets open source qui disposent de ce genre d'outils ?

            Il se fait tard en France

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

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

            Le support d'Oracle francophone est donc maintenant canadien au vu de vos horaires respectifs ?

            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)

            Quels points forts avez-vous trouvé à PostgreSQL dans vos essais ?
            Un lien vers un benchmark […]
            y-a-t-il une incitation à travailler de plus en plus avec du logiciel libre ?

            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 niveau technique : l'open source est entré dans les moeurs, c'est une solution naturelle, normale - on ne fait presque plus attention au fait que ce soit de l'open source, c'est de plus en plus transparent. Et c'est sans doute le mieux qui puisse lui arriver : se banaliser.
            • Au niveau du support :
              • La crainte existe toujours. Avoir le source de Tomcat, de Linux, du driver de ma carte SAN, … sous la main, c'est bien. Mais avoir en interne des gens capables de comprendre ce code, y backporter un patch, le recompiler avec les bonnes options, le patcher, le debuger, c'est une autre histoire car "you are not Google" (perdu le lien de l'article qui m'a inspiré cette petite phrase, désolé).
              • Dit autrement : les compétences nécessaires à ces tâches sont énormes, gigantesques, et hors de portée pour 99,9% d'entre nous (pour le faire correctement dans un contexte industriel).
              • Il faut donc pouvoir acheter du support auprès d'une société externe. Et là, ça manque encore de reconnaissance, donc de confiance (je ne parle pas du savoir-faire de ces sociétés, mais du fait qu'elles n'ont pas assez de renommée pour franchir certains barrages psychologiques, ce qui est très différent).
            • Au niveau légal : là, ça devient franchement délicat.
              • Il faut une armée d'avocats très pointus et parfaitement anglophones pour comprendre ce que l'on a le droit ou pas de faire en fonction des licences open source.
              • HP a été confronté à ce souci il y a quelques années et a reporté une date de sortie de son OS HP/UX à cause d'un souci de légalité vis-à-vis d'un composant open source qu'ils embarquent (pas de référence - c'est mon souvenir d'une conférence). Ils en ont fait profiter la communauté avec fossology (site en cours de reconstruction pour l'instant car atteint par l'attaque sur Linux Foundation mais on y trouve quand même de l'info). C'est un outil d'identification automatique des licences à partir d'une analyse des sources. D'après les infos qu'ils ont données lors d'une conférence : ils ont trouvé pas moins de 200 licences différentes dans le paquet de logiciels open source qu'ils ont analysés !
              • Comprendre réellement les implications d'une licence telle que la GPL, c'est déjà un exploit. Comment faire quand on mixe 2, 3, ou 5 produits open source dans un projet ?
              • Cette complexité n'est pas que théorique, genre "cela ne me concerne pas" : quand on utilise un logiciel open source, on adhère à sa licence et on s'engage à la respecter. C'est aussi (et peut-être d'abord) une question de principe en plus d'être une question légale : si la licence d'une quelconque bibliothèque (open source) que j'aimerais utiliser est incompatible avec la licence de mon socle (open source) EJB / PHP / …, alors je dois trouver une autre solution (une autre bibliothèque, la re-écrire mais sans la copier, changer de socle (glups !), …). Pas facile.
              • Et dans un environnement commercial "classique" où l'on vend du service ou du logiciel à des clients, cette complexité sur les licences peut vite devenir un cauchemar.

            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

            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 ;-)

            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 :

            • Instruction MERGE), dit aussi "upsert" (Oracle 10g : MERGE) : pas d'équivalent en postgres, et pas simple à remplacer, c'est une instruction qui fait, en résumé "insert si ça n'existe pas, sinon update" (c'est dans le TODO de postgres). L'implémentation Oracle étant conforme au standard d'après Wikipedia, on peut espérer que ce sera aisé de migrer si postgres implémente un jour cette instruction.
            • Requêtes hiérarchiques avec CONNECT BY : je n'ai pas trouvé en postgres (mais ça existe peut-être quand même ?). Et, non, malheureusement, une CTE ou requête récursive n'est pas obligatoirement équivalente car, qui dit "récursion" dit "stack overflow" possible selon l'implémentation faite par le moteur SQL. Donc prudence.
            • Opérateurs ROLLUP et CUBE (même document) pour faire des calculs croisés "de la mort qui tue", ou, de manière plus académique, de l'analyse multidimensionnelle : pas trouvé non plus - quelqu'un sait si cela existe ?
            • Clause LOG ERRORS (chercher "LOG ERRORS" dans ce document) sur INSERT et MERGE : pas trouvé non plus - quelqu'un sait comment on peut faire pour, par exemple, insérer des données dans une table et "ranger" automatiquement dans une autre table toutes les données que l'on n'arrive pas à insérer (doublon de PK, erreur de format numérique, …), en y ajoutant un marqueur perso afin d'identifier la source de l'erreur (nom de l'application, date de l'insert, …) ?

            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

            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 ?

            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 :

            • S'il faut défendre l'open source, alors il importe de connaître l'ennemi (librement et lâchement inspiré de l'art de la guerre, 3.18 : "Je dis que si tu connais ton ennemi et si tu te connais, tu n’auras pas à craindre le résultat de cent batailles. […]").
            • Et je t'apporte un peu de cette connaissance sur un plateau, tout va bien, non :-)

            (l'exemple du projet Naca est très bien trouvé, je m'étais justement fait la remarque cette semaine :p)

            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

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

            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 :

            • Tu me reproches un manque d'ouverture : que devrais-je penser de jugements qui sont manifestement construits sur la date d'ouverture de mon compte ou sur la simple présence du mot "Oracle" ?
            • Je n'ose pas imaginer combien de gens un peu hésitants et compétents ont renoncé ou hésitent à s'exprimer à cause de ce genre de trucs… C'est affligeant.

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

            • Pour la discussion, c'est avec plaisir que j'écris (déjà un peu plus de 2000 mots dans ce commentaire :-) et que je lis ce qui s'écrit ici.
            • Pour le factuel, j'ai la modeste prétention de considérer que je le suis. A défaut, merci de me pointer mes erreurs.
            • Pour la fréquence des écrits, ça risque d'être plus aléatoire : je suis un lecteur régulier de linuxfr (et d'autres) mais j'ai un métier qui est très prenant et qui ne permet pas toujours de m'adonner à ma logorrhée jusqu'à 2H30 du matin.

            Au plaisir de te lire.

            • [^] # Re: Oui mais Oracle n'est pas un moteur SQL...

              Posté par  . É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:

              -- utiliser le nom de la table avec la colonne ne marche pas dans HSQLDB
              INSERT INTO TABLE_NAME (TABLE_NAME.COL1, TABLE_NAME.COL2) VALUES ("", "")
              
              
              -- HSQLDB n'aimait pas ces parenthèses:
              SELECT *
              FROM TABLE1 (LEFT OUTER JOIN TABLE2 ON ...)
              
              
              -- La syntaxe oracle avec un '+' pour les left outer join:
              -- Oracle8i
              select last_name, d.department_id
              from employees e, departments d
              where e.department_id = d.department_id(+);
              
              -- Oracle9i
              select last_name, d.department_id
              from employees e LEFT OUTER JOIN Departments d
                               ON e.department_id = d.department_id;
              
              

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

                    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  . Évalué à 2.

                  Plus

                  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 !

                  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 ?

                  • La notation SQL standard existe depuis la 9i sortie en 2001.
                  • Tu peux jeter un oeil à "alter session set flagger = xxx" (jamais utilisé à titre perso) : ça existe depuis au moins la 9i et cela génère une erreur à chaque instruction SQL qui n'est pas conforme SQL92 (un exemple ici).
                  • Cela ne va pas re-écrire tes requêtes magiquement, mais ça peut en faciliter l'inventaire avant d'envisager un portage par exemple (ou une modernisation du code).

                  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) :

                  • Il en existe en fait plusieurs sous-catégories. Le début de cette question explique un peu la chose (attention, ça date un peu : 2001, donc le reste de cette discussion est à lire - par défaut - avec distance). L'intro de cette documentation postgres en parle également, de manière plus détaillée et surtout plus récente.
                  • Et, à ma connaissance, il n'existe plus aucun organisme indépendant capable de certifier qu'un moteur est conforme ou pas au standard (chercher "Summary and Conclusions" vers la fin de cet article par exemple).

                  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  . Évalué à 3.

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

                    Tout a fait! Je suis passé un peu vite sur la chose.

                    Tu as peut-être du code qui date un peu, non ?

                    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.

                    C'est donc plutôt une mauvaise nouvelle car, en pratique, cela signifie qu'il n'existe plus de standard.

                    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  . Évalué à 1.

                      […] je considérais plutôt le standard SQL que comme une base syntaxique

                      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.

                      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.

                      Aucune idée sur les intérêts des éditeurs.

                      Par contre j'aimerais vraiment que cette certification existe quand :

                      • je dois répondre à un appel d'offre qui comporte une exigence classée primordiale (= éliminatoire) et qui dit "la solution doit être compatible standard SQL92"… ;
                      • je me demande quel moteur choisir pour un projet ;
                      • et combien ça pourrait coûter de changer de moteur.

                      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  . Évalué à 1.

                Sommaire

                MVCC mon amour

                nous essayons actuellement de remplacer Oracle par HSQLDB […] car HSQLDB dispose d'un mode de compatibilité avec Oracle (syntaxe, mais je ne suis pas sur pour l’exécution)

                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.

                • Sur un moteur X non MVCC, tu peux avoir du code qui se retrouve bloqué par un select sur des données updatées dans une autre session : ce blocage est peut-être voulu, mais il peut aussi être fortuit. Dans les deux cas, il s'agit ni plus ni moins que d'un comportement classique de synchronisation d'exécution comme un mutex, un sémaphore, … sauf que ça passe par la base de données et non pas par codage explicite dans l'application.
                • Dès lors que tu migres sur un autre moteur Y qui fonctionne en MVCC, il y a toutes les chances pour que cette synchronisation n'existe plus : le code qui était auparavant bloqué sur le select va dorénavant s'exécuter comme si de rien n'était.
                • Dans le meilleur des cas, l'application continue à fonctionner correctement après changement du moteur SQL et va même peut-être plus vite (car "les verrous c'est pas bien", c'est un tue-l'amour en termes de performances et de scalabilité).
                • Dans le pire des cas, l'application ne se comporte plus de manière correcte (génération de faux résultats) et il faut espérer qu'on le détectera avant passage en production car c'est un truc ultra-vicieux : le bug dépend de la dynamique d'exécution et du comportement multi-threads (ou multi-clients ou multi-sessions) de l'application. Cela peut être un véritable calvaire que de reproduire le bug.
                • Facteur aggravant : je ne sais pas ce qui est enseigné dans les IUT / BTS / écoles d'ingénieurs informatiques / … ces dernières années, mais je constate que 100% des développeurs avec qui j'ai eu l'occasion de travailler sont convaincus que un update bloque obligatoirement un select sur la même donnée : il y a donc toutes les chances de trouver du code qui s'appuie sur ce comportement pour implémenter une logique métier.

                MVCC et journaux

                Second écueil : la "durée de vie"

                • L'implémentation Oracle du MVCC s'appuie sur les journaux.
                • Si je passe sur les détails : une session démarrée à l'instant T travaillera toujours sur l'état complet de la base de données telle qu'elle était exactement à cet instant précis. On peut donc, par exemple, avoir un "batch" quelconque qui mouline durant 2 heures. Dans ce scénario, le batch n'est jamais bloqué (voir point précédent) et à tout instant, il "voit" l'intégralité de la base de données telle qu'elle était à l'instant T même si des millions d'update / commit ont été faits par d'autres sessions sur les tables manipulées par le batch.
                • Le volume de "millions d'update" ne dépend que de la taille allouée aux journaux d'undo / redo : tant que le journal qui contient la version initiale de la donnée demandée par le batch (et qui a été modifiée x fois par d'autres sessions) existe, le batch fonctionne sans souci (et sinon, on obtient la fameuse erreur "ora-01555" : le moteur ne peut plus s'appuyer sur les undo pour retrouver la valeur de la donnée telle qu'elle était il y a 2 heures).
                • Ce comportement est "out of the box", permanent. Je crois que d'autres moteurs ont des notions de "snapshot" et ce genre de choses. Sur Oracle, le MVCC s'appuie toujours sur les journaux : c'est le seul et unique comportement, il n'y a pas d'alternative.

                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.

                • Il traite notamment du MVCC, en lecture et en écriture. Dans ma version (9i + 10g seulement), le chapitre est "Seeing a Restart". Si tu ne dois lire qu'un bouquin sur Oracle (même avant d'en sortir), prends celui-là. C'est écrit par un des meilleurs spécialistes d'Oracle.
                • Point capital : il prend soin de faire en sorte que tout ce qu'il explique soit démontré par l'expérience et reproductible. Son credo est "ne croyez pas les experts, pas même moi, vérifiez toujours avec les scripts que je fournis que vous avez le même résultat".

                L'exemple présenté au chapitre "Seeing a Restart" évoqué plus haut commence ainsi :

                • Une session fait Update t set y = 10 where y = 5
                • Une autre fait Update t Set x = x+1 where y = 5 ; elle est évidemment bloquée. Remarquer que la 1ère requête modifie la colonne qui est utilisée dans le where de cette seconde requête.
                • La première session réalise un commit.
                • La seconde session peut alors continuer.
                • La question est : que doit-il se passer lorsque la 1ère session aura fait son commit ? Cela doit évidemment être conforme aux principes ACID.
                • Et la réponse n'est pas aussi immédiate qu'il y paraît !
                  • On ne peut pas prétendre, dans la seconde session, que "where y=5" ne retourne rien : la première session n'a pas encore été commitée. C'est d'ailleurs pour cela et en vertu du principe ACID que la seconde session est bloquée !
                  • Mais, une fois que la première session a été commitée, que faire ? La donnée existait, a bloqué la seconde session, puis quand elle se débloque, la donnée n'existe plus !
                  • Pour Oracle, la réponse est, sauf en isolation SERIALIZABLE : l'update de la seconde session est rollbacké de manière transparente, le moteur réalise alors un équivalent logique à "select from t where y = 5 for update" pour poser des verrous explicites puis relance l'update (c'est rollbacké car il y a peut-être des milions de lignes qui répondent à la clause where - voir plus bas).
                  • Ceci évite de se retrouver dans le cas de figure initial.
                • Et le bouquin continue, car le scénario n'est pas terminé.

                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.

                • En effet, rien ne garantit dans le standard SQL que les deux sessions vont traiter ces lignes dans le même ordre, ni à la même vitesse.
                • On peut rendre la chose plus explicite en modifiant un peu les requêtes, par exemple la 1ère session fait "where y > 1000" et l'autre "where y > 10", qui est un sur-ensemble de "y > 10" : si ça se trouve, la 2nde requête aura déjà fait des milliers d'update avant d'être bloquée par la première requête qui lui a "tiré le tapis sous les pieds".
                • Quel est le comportement attendu du moteur (n'importe lequel) ?

                MVCC et triggers

                Troisième écueil : les triggers

                • C'est un effet de bord du MVCC en update : si tu as des triggers en update sur une table, le moteur Oracle est susceptible de les déclencher plusieurs fois.
                • Pour les détails : voir bouquin mentionné.
                • Là encore, tu as peut-être du code qui fonctionne correctement avec le comportement Oracle : je ne sais pas dire si ce comportement est, d'un point de vue formel, par rapport au standard, une bizarrerie ou un truc normal.
                • Perso, là encore, je trouve que c'est en tout cas assez étrange pour s'interroger.
                  • Est-ce propre à la manière dont Oracle implémente le MVCC ? Donc danger.
                  • Ou est-ce une conséquence inévitable du MVCC, indépendamment du moteur ?

                Au plaisir.

                • [^] # Re: Oui mais Oracle n'est pas un moteur SQL...

                  Posté par  . Évalué à 2.

                  je constate que 100% des développeurs avec qui j'ai eu l'occasion de travailler sont convaincus que un update bloque obligatoirement un select sur la même donnée : il y a donc toutes les chances de trouver du code qui s'appuie sur ce comportement pour implémenter une logique métier.

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

                  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 :)

                  MVCC et update contre update

                  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.

                  MVCC et triggers

                  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  . Évalué à 0.

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

                    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  . Évalué à 1.

                Sommaire

                Toi aussi, gagne de l'argent facilement :-)

                nous essayons actuellement de remplacer Oracle par HSQLDB pour exécuter les tests d’intégrations sur notre logiciel

                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 :

                • La licence OTN = version Enterprise gratuite pour tout ce qui touche aux activités de développement, test, prototypage et démonstration.
                • La version Oracle Express = version "castrée" mais gratuite pour le dev et la production.

                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 :

                LICENSE RIGHTS
                We grant you a nonexclusive, nontransferable limited license to use the programs only for the purpose of developing, testing, prototyping and demonstrating your application, and not for any other purpose.

                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 :

                • c'est un énorme "plus" en termes de fiabilité puisque l'environnement logiciel des développeurs est plus proche de la prod' qu'avec un autre moteur.
                • Cela évite toutes les petites différences de comportement propres à chaque moteur.

                Il y a un seul danger, mais un véritable danger, auquel il faut faire attention :

                • La licence OTN te donne droit à la version Enterprise, donc aux options de cette version, telles que le partitionnement par exemple.
                • Si d'aventure un développeur ou un concepteur de base de données se prend d'amour pour le partitionnement (ou …) pour résoudre un problème quelconque (performance par exemple) et que le truc part en production, il te faudra sortir le chéquier pour avoir le droit d'utiliser cette option en production…

                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 :

                • C'est une version "castrée" sur certaines fonctionnalités et sur la volumétrie (11 Go de data perso au max, 1 CPU au max, … plus de détails sur leur site et dans la documentation du produit : tout est listé option par option).
                • C'est livré avec un truc qui s'appelle APEX, un frontal Web pour exploiter et administrer la base.
                • Si cette castration te laisse un produit qui répond à ton besoin : il est gratuit pour le dev et la production.

                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  . É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  . É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 :-)) :

        • Comment peut-on penser que j'ai voulu faire passer le message "Oracle c'est mieux que les autres" quand j'écris "Oracle n'est pas un produit parfait ni miraculeux, tout le monde s'en doutait !" ? Ou encore "chacun a sa vision de la vérité, elle n'est ni meilleure ni moins bonne qu'une autre vérité" ? Ou encore "Chacun appréciera en fonction de son contexte, des exigences techniques et fonctionnelles du projet, du budget, des compétences en place, …" ?
          • Franchement : as-tu déjà vu ce genre de propos dans une plaquette commerciale ?
        • Comme tu l'écrivais le 13/01/2012 ici en incitant tes lecteurs à lire un article de Wikipedia, prends le temps de lire les liens que j'ai mis dans mon post : il ne s'agit pas d'une bouillie de plaquettes commerciales, ce sont des documents techniques avec des vrais morceaux de trucs à découvrir pour celui qui en a envie. Pour te mettre en bouche, je te suggère de commencer par les concepts (ici) : cela te permettra de faire un tour du produit et d'accéder ensuite à de nombreuses autres documentations plus détaillées.

        Cordialement.

        • [^] # Re: Oui mais Oracle n'est pas un moteur SQL...

          Posté par  . É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  . Évalué à 1.

            La communauté se blinde contre ça, mais du coup il est plus difficile pour un nouvel entrant de s'y habituer.

            Je confirme, c'est bien ainsi que cela semble fonctionner :-)

            Bref, ce n'est pas personnel […]

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

      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 !

      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  . Évalué à 2.

        @djano

        Carrés, ronds, losanges, … : après la lutte des classes, voici la lutte des formes :-)

        Bon ta prose est très jolie

        Je le prends au 1er degré, donc : merci.

        Copier / coller avec un peu de changement du texte pour appuyer un peu plus ton disclaimer?

        Tu as quelque chose de factuel pour … appuyer ;-) ton propos ?

        … mais elle a quand même l'air un peu trop carrée pour avoir été rédigée comme un commentaire.

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

        Bof j'y crois pas, mais comme tu dis: a chacun de juger (ou pas).

        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  . É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  . É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  . Évalué à 1.

        En effet, je ne savais pas qu'il y avait tout ça dans Oracle! (Un serveur JMS!!)

        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.

        Je me demandais justement si PostgreSQL avait un équivalent aux AWR?

        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.

        ils font des progrès conséquents à chaque nouvelle version

        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 :

        • Ce n'est pas compilé par défaut et ça s'appuie sur les fonctions natives de l'OS (à ce jour, DTrace uniquement d'après la doc).
        • Ca apporte évidemment plus de souplesse …
        • mais on perd en "universalité".

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

        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.

        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  . É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  . É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  . Évalué à 1.

        @djano

        La vie est dure

        Oracle Forms est aussi pas mal dans le genre "je me lie ad vitam æternam avec ma base de données".

        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 :

        • Le gars a développé pour les besoins de son employeur un outil de portage automatique mainframe / Cobol / DB2 / 3270 vers Linux / Java / web + Google Web Toolkit.
        • Il a ensuite fondé une société autour de cet outil.

        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

        • Sur l'usage de GWT dans NACA : lire par exemple ceci.
        • NACA ne fait pas du "revamping" mais de la traduction, de la re-écriture : à l'issue, le mainframe est mis à la poubelle (alors qu'il reste bien présent si on se contente juste d'y ajouter une façade Web).
        • J'ai eu l'occasion de rencontrer le fondateur d'Eranea à un salon Linux mais je ne travaille pas pour lui et je ne touche pas un centime quand je cite le nom de sa société dans un forum de discussion.
        • @djano : je te laisse vérifier que mon texte n'est pas un Copier / coller avec un peu de changement du texte comme tu le soupçonnes dans l'un de tes commentaires précédents :-)
        • [^] # Re: Dommage...

          Posté par  . É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  (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.