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.
Ç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.
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.
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.
[…] 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.
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 ?
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 :-)
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" ?
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.
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 ?
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.
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 :-)
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.
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)
@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.
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.
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.
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 ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 1.
Au delà de l'affrontement "open source vs propriétaire", des pratiques commerciales, du coût des licences, etc, c'est un produit que je trouve techniquement jouissif. Il y a une flopée de fonctionnalités à découvrir, bien plus que le peu que je connais et que j'ai tenté de décrire de mon mieux (flashback pour "voir" la base dans le passé, total recall, la compression, le chiffrement, DBMS_ADVANCED_REWRITE pour remplacer "à la volée" une requête émise par une application dont on n'a pas le code source ou que l'on ne peut plus recompiler, Edition-Based Redefinition pour versionner une base "à chaud", un peu comme Subversion le ferait dans un processus branche + merge, les Function based index, etc etc c'est monstrueux : à coté, la doc d'un JDK récent ressemble à une promenade de santé)
Il y a bien sûr d'autres produits, open source, qui sont tout autant "jouissifs" au niveau technique.
Mais si cela permet, dans le respect des contraintes d'un projet, d'aller bosser le matin en se disant des trucs tels que "on m'a imposé Oracle / je n'aime pas Oracle / etc mais je vais quand même apprendre des choses aujourd'hui, me faire plaisir et peut-être trouver une solution satisfaisante à un besoin métier", ce serait dommage de s'en priver.
Si tu aimes "mettre les mains dedans", autant se faire plaisir (plutôt que de prendre des anti-dépresseurs :-). Après le bouquin de Tom Kyte pour l’échauffement, cela te donnera l'occasion de lire des trucs tels que ce bouquin : 450 pages, sans les annexes, sur l'optimiseur de requête (une version plus récente est peut-être sortie). C'est ardu mais on le referme en ayant appris quelque chose.
Cela n'empêche évidemment pas de vouloir ou devoir migrer vers un autre moteur pour plein de bonnes raisons, ou de vouloir démarrer un projet avec un autre moteur qui fait ceci ou cela "plus mieux" qu'un autre.
D'après leur doc, EnterpriseDB va dans cette direction, en visant à offrir ce que font notamment OEM + AWR ; voir par exemple ce PDF.
D'après la doc, cela semble moins riche, mais si on me demande d'aller chercher une baguette à la boulangerie du coin, je ne vais pas prévoir d'acheter une voiture de luxe avec intérieur cuir.
Et ça "sent" clairement l'affrontement avec Oracle.
C'est indéniable.
Voir par exemple les sous-chapitres ici pour tout ce qui touche au monitoring des performances.
On peut être plus réservé sur les probes :
Il y a certainement de bonnes raisons pour qu'ils aient choisi cette voie.
Et, là encore, ça "sent" l'affrontement direct avec Oracle (notions d'events et latchs).
En tout cas, même si ce n'est pas dit clairement, la cible est identifiée et ça va donner du boulot aux auteurs d'ora2pg :-)
Au plaisir.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 0.
Heu … non, c'est l'inverse, je n'ai peut-être pas été très clair : avec un moteur MVCC, un update ne bloque pas les select.
A lire ici : une discussion lancée en 2008 et qui dure, sur ce sujet. Ca a l'air sérieux.
Dans ton contexte, tu pars d'un moteur MVCC pour aller sur un autre moteur MVCC : il est raisonnable de penser que tu n'auras pas trop de soucis sur ce sujet, hors quelques comportements parfois peu intuitifs, et surtout, difficiles à reproduire.
Au plaisir.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 1.
Sommaire
Toi aussi, gagne de l'argent facilement :-)
Une question bête : quelles sont les motivations derrière ce remplacement ?
Est-ce seulement, ou majoritairement, un aspect financier ?
Si tel est le cas, je te suggère de regarder deux trucs chez Oracle :
Si tu mènes un chantier "comment sortir d'Oracle", ces deux trucs, surtout le premier, peuvent te donner un peu d'air en attendant d'avoir terminé en fournissant à tes développeurs un environnement technique qui est très proche de ce que tu as en production (= "c'est bien").
Si tu as des besoins pas trop élevés en volumétrie et fonctionnalités, le second truc peut là aussi te donner de l'air : c'est gratuit, y-compris sur la prod'. Donc, ça peut faire "sauter" une licence, ou t'éviter d'avoir à en racheter tant que tu n'as pas terminé ton chantier de migration.
Cela ne te fera pas sortir d'Oracle, c'est sûr, mais ça peut de permettre de réduire tes coûts et / ou d'améliorer la qualité des test en attendant d'avoir remplacé le moteur SQL de ton produit.
Détails ci-dessous.
OTN
Tu devrais regarder de près ce que dit la licence OTN (Oracle Technology Network Development License Agreement).
Je cite :
Cela te permet de télécharger ici la version Enterprise ou Standard en 11g ou 10g (plus bas dans la page pour la 10g) et de l'installer comme tu veux où tu veux, tant que c'est pour du dev, sur du Windows, du Linux, du Solaris, de l'HP/UX, …, en 32 bits ou en 64 bits. La 9i est peut-être aussi disponible sous cette licence mais je ne connais pas assez cette version pour t'en parler.
Tu peux même t'en servir pour faire des démos de ton produit. Ils ne sont pas que idiots chez Oracle : si tu fais une démo de ton produit avec un moteur Oracle, c'est tout bénef' pour eux, alors autant te faciliter la vie et te permettre de le faire gratuitement (toi et / ou ton client passeront "à la caisse" plus tard, quand tu auras vendu ton produit et que ça passera en production).
Mais si cette licence gratuite te permet aussi d'avoir des développeurs qui utilisent pour leur activité le même moteur que celui qui est en production, autant en profiter :
Il y a un seul danger, mais un véritable danger, auquel il faut faire attention :
Mais pour le reste, c'est tout bénef.
Warning : je ne suis expert en licence. Prends le temps de lire ce que dit la licence OTN et fais-toi ton opinion. Dans mon environnement, j'ai conclu que "OTN = gratuit pour les dev". Mais cela n'engage que moi.
Oracle Express
Il y a aussi la version Oracle Express :
Je n'en dis pas plus sur cette version, je ne l'ai installée qu'une fois "pour voir", donc mon niveau de connaissance est peu éloigné du zéro absolu.
APEX fait sans doute d'autres trucs car on peut aussi créer des applis Web, des rapports PDF, etc, mais là encore, je n'y connais pas assez pour t'en parler sérieusement. Il y a des tutoriaux par là par exemple, ou certainement ailleurs sur OTN.
Au plaisir.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 1.
C'est bien plus vaste : voir Wikipedia, chapitre "Standard structure".
C'est géré par l'ISO : "sql" dans la boîte de recherche te donnera une vingtaine de résultats. Les spec' sont payantes mais ça reste raisonnable.
Aucune idée sur les intérêts des éditeurs.
Par contre j'aimerais vraiment que cette certification existe quand :
D'après ce que j'ai lu sur le sujet : il existait, pendant un temps, un organisme US qui avait cette capacité à certifier un moteur SQL.
Au plaisir.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 1.
Sommaire
MVCC mon amour
Pour l'exécution, n'oublie pas le comportement MVCC d'Oracle et son implémentation : que je sache, Postgres ou HSQLDB s'appuient aussi sur du MVCC mais tu devrais vérifier que c'est suffisant pour t'éviter des effets de bord indésirables et potentiellement ardus à détecter et reproduire.
Premier écueil (mais que tu ne devrais peut-être pas avoir avec HSQLDB ?) : en résumé, un update ne bloque jamais un select.
MVCC et journaux
Second écueil : la "durée de vie"
Je ne connais pas HSQLDB mais tu devrais peut-être vérifier que ton application ne s'appuie pas (peut-être sans que ce soit volontaire) sur ce comportement Oracle.
MVCC et update contre update
De plus, ce que je viens de décrire a également des conséquences surprenantes sur le comportement des update : ce comportement est évidemment correct d'un point de vue transactionnel mais le MVCC et l'implémentation Oracle font que cela n'est pas toujours conforme à notre intuition. Donc, danger.
Si tu veux approfondir ce genre de sujets, je ne peux que te recommander un seul bouquin, celui de Tom Kyte : Expert Oracle Database Architecture. Je sais qu'il existe en version PDF.
L'exemple présenté au chapitre "Seeing a Restart" évoqué plus haut commence ainsi :
Tu as peut-être du code qui fonctionne correctement du fait de ce comportement. Comment le détecter ? Qu'en sera-t-il après portage ?
Pour les longues soirées d'hiver : que doit-il se passer si "where y = 5" correspond à des millions de lignes ? Là, l'asynchronisme prend de l'importance.
MVCC et triggers
Troisième écueil : les triggers
Au plaisir.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 1.
Je confirme, c'est bien ainsi que cela semble fonctionner :-)
Bien compris.
J'ai également lu ton autre commentaire : merci d'avoir eu le cran d'écrire que tu t'es trompé.
En espérant qu'on se recroise au hasard de futurs commentaires (après j'arrête d'envoyer des fleurs, sinon on va croire que c'est un coup monté ou un truc louche entre nous deux :-)
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 2.
Plus
En fait, c'est pire : selon que le (+) est attaché aux colonnes d'une table ou d'une autre, il va s'agir d'un left outer join ou d'un right outer join (détails ici, et plus bas pour savoir pourquoi ce "bidule" existe).
Tu as peut-être du code qui date un peu, non ?
Pour ce qui est de l'ancienne notation (+) qui n'est pas standardisée, il y a une "histoire" derrière : cette notation fut introduite par Oracle sur la 8 avant que cette fonctionnalité ne soit standardisée (chercher "outer join" par exemple ici).
Standard ? Quel standard ?
Puisqu'on parle de standard, c'est d'ailleurs un sujet passionnant que celui du standard SQL (enfin, "passionnant", ça peut aussi signifier "utile pour passer une longue soirée d'hiver au coin du feu", à chacun de se faire son idée) :
C'est donc plutôt une mauvaise nouvelle car, en pratique, cela signifie qu'il n'existe plus de standard. On ne peut que se reposer sur ce qu'affirment les éditeurs de moteurs SQL et leur faire confiance.
Quelqu'un est-il assez calé en standard SQL pour contre-dire ce que j'ai écrit sur cet aspect "certification" ?
Cordialement.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 3.
Sommaire
@baud123
Mais qui est cet intrusif dans mon bug tracking ?
Tout le plaisir est pour moi :-)
Plus sérieusement : je ne saisis pas très bien point de vue.
Il y a un truc qui m'échappe un peu dans ton discours.
A titre personnel, si des structures comme Apache et les autres me fournissent via leur outil de bug tracking un outil fait par leur soin, répondant à leur besoin, et qui me permet de joindre au ticket que j'ouvre un tar.gz contenant toutes les informations techniques qu'ils jugent utiles à l'analyse d'un dysfonctionnement, je prends à 200%.
Que trouverais-tu de choquant à cette fonctionnalité si Apache ou d'autres la proposaient ?
Il faudrait sans doute prévoir d'anonymiser quelques éléments puisque ces infos se retrouveraient alors dans la nature.
Mais, sur le fond, où serait le problème ? Ne serait-ce pas profitable à tout le monde ?
Pour info, je viens d'essayer reportbug de Debian car j'en ai entendu dire du bien et ça semblait se rapprocher de ce que je décris sur le RDA de Metalink :
Connais-tu d'autres projets open source qui disposent de ce genre d'outils ?
Il se fait tard en France
Je comprends que ton propos est de dire que le support peut être de qualité dans le monde open source.
J'en suis convaincu (j'ai déjà eu l'occasion d'ouvrir quelques tickets de bug, sur Apache ou Tomcat par exemple).
Aucune idée.
Je travaille en France mais je ne dialogue qu'en anglais avec le support Oracle et je ne leur ai jamais demandé où ils vivent.
Ta question vient peut-être de l'horaire de mes commentaires ?
Incitez-moi mais pas trop vite
(je reconnais que j'ai un peu honte d'avoir copié sur Gréco)
Je comprends que tu ouvres des questions plus générales qui vont bien au-delà de mon commentaire auquel tu réponds (car je n'ai jamais évoqué un quelconque bench Oracle vs pg dans mes commentaires).
Je me permets de rebondir sur l'incitation. Si je compare aujourd'hui par rapport à la situation d'il y a 5 / 6 ans, il apparaît (de mon point de vue à moi que j'ai et que je partage) qu'il n'y a pas d'incitation mais une normalisation bien amorcée :
Au delà du produit HP fossology et du pur aspect "licences", ceux qui se sentent concernés par cette problématique de choix de logiciels open source peuvent jeter un oeil à QSOS. Je cite : "QSOS est une méthode conçue pour qualifier, sélectionner et comparer les logiciels open source. Elle est mise à disposition de la communauté sous licence libre GNU Free Documentation License". Parmi les critères : la licence.
Si, ça colle
Je ne suis pas d'accord : au contraire, je pense que je "colle" parfaitement au sujet qui est "aller de Oracle vers PostgreSQL". C'est d'ailleurs ce qui a fait le déclic et qui m'a donné envie d'écrire un commentaire.
En effet, ce chemin de migration peut nécessiter de traiter des dizaines d'autres éléments qui font partie d'Oracle mais qui ne sont pas couverts par l'outil ora2pg ni par postgres (jobs, CDC et Streams, vues matérialisées, rman, …). Je crains de me répéter, mais tant pis : Oracle n'est pas un moteur SQL, ça ressemble plus à un socle d'exécution.
Il n'est donc pas inutile d'avoir une vision un peu plus complète de la chose.
Et puisque tu mentionnes ma "logorrhée", je vais me permettre d'en ajouter un peu :-) : il peut aussi s'avérer nécessaire, pour faire ce genre de migration de traiter quelques trucs qui ne sont peut-être pas vraiment mineurs ni drôles au niveau des requêtes SQL de l'application.
Par exemple :
Par contre, postgres supporte la clause "over", comme Oracle, et c'est une très bonne nouvelle car ça fait aussi partie des trucs qui peuvent être très difficiles à remplacer par du SQL "fait main" (pour postgres, voir ici, il y a aussi ceci pour se faire une idée).
Je reviens sur la "logorrhée" : je ne vois pas comment écrire avec moins de mots ce que j'ai écrit plus haut sur le sujet de l'"incitation à travailler de plus en plus avec du logiciel libre". On ne peut pas tout compresser à l'extrême. Mais j'admets volontiers que c'est un défaut si tu le juges ainsi.
Sun Tzu
Oups… Je viens de me rendre compte que vous me vouvoyez alors que je te tutoie. Je propose de rester au "tu", si cela vous / te convient.
Je ne sais pas comment dire que je ne défends personne, je ne cherche pas à convaincre qui que ce soit que Oracle est meilleur que les autres (car il y a autant de réponses à cette question qu'il y a d'architectures à créer, de projets à mettre en place, … et, comme tu le dis, en plus, ça varie dans le temps !).
Jusqu'à présent, il me semble, j'ai décrit ce que je connais et sauf erreur de relecture de ma part, je n'ai à aucun moment prétendu que c'était mieux qu'autre chose. On peut comprendre que c'est différent (voir "merge" par exemple plus haut dans mon commentaire).
En quoi est-ce défendre Oracle ?
On peut même aller plus loin :
Begin séquence "cours de récréation"
Trop tard !!! J'étais prem's sur NACA :-)
Et j'ai aussi QSOS et Fossology : et toc !
End séquence "cours de récréation"
Bienvenue à bord
Merci pour l'invitation, je dois t'avouer que c'est un peu rebutant de se prendre des claques quand on pense juste être sincère et factuel :
Je ne me sens pas concerné par "autre" dans "(autre) monde du libre" : je baigne dans l'open source depuis l'époque de l'Amiga grâce à un "fondu" qui envoyait des disquettes à la terre entière avec des applis faites par des passionnés + les sources (mais j'ai perdu le nom du gars en question…).
Au plaisir de te lire.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 1.
@baud123
Je viens de relire la totalité des commentaires et je pense que ce n'est pas ce qui t'a rebuté avec Metalink…
Cordialement.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 2.
Sommaire
@baud123
Degrés
Je ne sais pas ce que voulait dire hamelg mais si c'était du 1er degré, je suis du même avis que lui.
Usage
Je m'en suis beaucoup servi durant environ une année et voici ce que j'ai apprécié à l'usage :
Et derrière Metalink, il y a le support (ML n'étant finalement qu'une interface qui n'a que peu d'intérêt) :
Contenu
Sur le contenu :
La première marche est donc haute et cela ne rend pas l'outil facile d'accès, c'est une certitude. Il m'est souvent arrivé de récupérer 150 articles sans intérêt pour un problème qui me semblait bête et courant et c'est très décourageant. Mais je n'étais qu'un petit scarabé à l'époque et je ne savais pas encore que ces problèmes font partie de ceux que j'étais supposé savoir résoudre sans appeller à l'aide :-)
Plus sérieusement : ça m'arrive encore, parfois, de me retrouver avec des réponses qui ne m'aident pas mais Metalink est un outil très utile dès lors que l'on a pris le temps d'apprendre à formuler sa question. Chaque moteur de recherche possède sa logique et, surtout, les contenus indexés ont leur particularité : on ne cherche pas avec Google comme avec Metalink ni comme le Bugzilla d'ASF ni comme…
Backport
Sur le thème du backport des patchs : quelqu'un (Niniryoku ?) sait comment cela se passe avec postgres / RH / … si on achète du support ?
RDA
RDA :
Désolé de ne pas avoir d'exemple plus récent de RDA - je ne peux pas poster ici ce qui vient de l'environnement sur lequel je travaille.
Au plaisir
Au plaisir de te lire à nouveau.
[^] # Re: Dommage...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 1.
@djano
La vie est dure
Tu as raison, la vie est parfois dure.
Je ne vais pas parler spécifiquement de Oracle Forms car je n'y connais rien mais de la problématique de portage que tu abordes.
Si tu as ce genre de problème à résoudre (ça y ressemble un peu, étant donné l'amour que tu portes à Forms), tu pourrais te rapprocher de Eranea après avoir lu cet article de linuxfr.
Pour aller vite :
Mais il y a de l'espoir
L'existence du produit, qui a manifestement assez de succès pour construire une société autour, montre qu'il est possible de "sortir" totalement d'un environnement avec des écrans verts 80x25 pour aller progressivement vers quelque chose de très différent.
Certes, 3270 et OracleForms sont différents mais s'ils ont réussi à le faire pour 3270, alors on peut espérer que c'est également faisable pour OracleForms.
Et c'est une bonne nouvelle.
Qu'en penses-tu ?
Cordialement.
Précisions, disclaimer, etc
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 2.
@djano
Carrés, ronds, losanges, … : après la lutte des classes, voici la lutte des formes :-)
Je le prends au 1er degré, donc : merci.
Tu as quelque chose de factuel pour … appuyer ;-) ton propos ?
"Trop carré" ? Je crois que c'est la première fois que l'on me reproche de rédiger un texte qui est trop carré : je trouve que c'est plutôt quelque chose de positif.
Et si ça ne ressemble pas à un commentaire, c'est peut-être parce que j'ai pris le temps de préparer mon texte. Je n'ai pas tenu spécialement de comptabilité, mais ça doit faire au moins 3 ou 4 heures pour les deux commentaires combinés : il faut organiser ses idées, tenter de trouver des exemples "parlants", éviter les redites dans la formulation, trouver la meilleure formulation (objective, non ambigüe, factuelle), et identifier un point d'entrée adéquat dans la documentation technique, point d'entrée auquel un lecteur curieux pourra se "raccrocher" s'il veut en savoir plus ou s'il souhaite se faire sa propre idée.
J'ai pris la peine de citer la documentation technique de référence pour que tu puisses te faire ton idée or j'ai vaguement le sentiment que tu juges mes commentaires sur leur forme : as-tu pris le temps de lire cette documentation, même sommairement, pour te faire ton idée autrement que sur la forme de mes commentaires, même si cette forme te semble inhabituelle ?
170 minutes
Revenons à ton commentaire de manière plus globale : je ne pense pas trop me tromper en faisant l'hypothèse qu'il t'a fallu moins de dix minutes pour l'écrire. Tu confirmes ?
Il m'a fallu (au moins) 3H pour écrire mes deux premiers commentaires.
Pourquoi ne consacrerais-tu pas 170 minutes supplémentaires de ton temps à nous faire découvrir des fonctionnalités méconnues de postgres ? Ou de slony ? Ou d'un autre logiciel de ton choix ? (ou la moitié de 170 si tu penses que j'écris lentement)
Dans l'attente d'avoir le plaisir de te lire, cordialement.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 2.
Je ne sais pas s'il s'agit de mon commentaire ou pas mais je te remercie de me répondre de manière civilisée, ce qui est toujours agréable.
Pour ce qui est de la comparaison Oracle / pg sur les points que tu cites, je n'ai pas d'avis car je ne connais pas pg aussi bien qu'Oracle (le hasard m'a amené à mettre les mains dans le cambouis très profondemment dans Oracle et dans Ingres) et OpenIngres (même lien) mais pas beaucoup dans leur successeur, c.à.d postgres).
Pour le PL/Python, je me permets d'ajouter que la doc de la 9.1 présente de nombreuses améliorations par rapport à la 8.2 que tu cites.
Sur la réplication de pg, GLMF a publié quelques articles instructifs (voir par exemple numéros 130++ à la fin de cette liste) [begin sequence publicité]soutenez-les, abonnez-vous à leurs revues ou faites abonner votre employeur[end sequence publicité].
"bidouiller" : tu peux préciser dans quel sens tu emploies "bidouiller" ? (c'est une formulation qui peut faire un peu peur)
Au plaisir de te lire à nouveau.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à -2.
@hamelg
Même avis, mais je ne sais pas si je dois l'écrire, je vais finir par me prendre une bordée d'injures :-)…
Cordialement.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 2.
@weonbin - Je suis resté "sur le c*l" en lisant ton commentaire, je ne sais pas trop comment te répondre, j'ai beaucoup hésité car je ne suis pas un habitué de ce genre de lieu d'expression et je n'en connais pas les règles, explicites ou implicites, donc j'ai toutes les chances de me planter.
En fait, je ne sais même pas comment je dois comprendre ton commentaire : est-ce méchant, désinvolte, dois-je t'ignorer, pourquoi utilises-tu le conditionnel pour discréditer mon propos en une petite phrase fielleuse et rapide au lieu de prendre le temps de vérifier par toi-même les documentations que je cite, veux-tu seulement me faire comprendre que la forme de mon post te semble inappropriée, pourquoi le dire ainsi alors, … ?
Comme je ne sais pas comment comprendre ton commentaire, j'ai plusieurs idées de réponses en tête et je vais donc te fournir celle-ci, qui est factuelle, donc à priori appropriée (je l'espère - sinon, il ne me restera plus qu'à ouvrir un nouveau compte et publier un commentaire le jour même :-)) :
Cordialement.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 4.
Sommaire
@hamelg et @Niniryoku : j'aurais aimé compléter vos sujets mais il se fait trop tard pour mon petit cerveau.
@baud123
10g
Chantier "migration" en cours :-) (mais, à ma connaissance, on est toujours supporté).
Ceci explique aussi pourquoi je parle beaucoup de la 10g : c'est ce que nous avons en prod' depuis longtemps, c'est donc ce que je connais le mieux.
Streams
En effet, déprécié comme tu dis.
Mais cela ne signifie pas que ce composant va disparaître demain. Voir par exemple "Oracle Streams: What's New in Oracle Database 11g Release 2" : ça bouge encore pas mal.
Et quand bien même ils arrêtent sur la 12 ou 13 d'améliorer le composant, il restera en place un bon bout de temps (comme l'ancien scheduler de jobs par exemple). Ces deux point sont clairement annoncés dans Oracle GoldenGate Statement of Direction , page 4 :
Evidemment, les promesses n'engagent que ceux qui y croient comme on dit…
Scheduler
Merci du retour sur le produit que tu cites, il fut un candidat potentiel pour un projet passé et je suis heureux de ne pas l'avoir retenu (je crois qu'on a remplacé le scheduler par un humain dans cette histoire).
Concernant le scheduler d'Oracle, c'est sans doute différent de l'idée que tu en as. En résumé :
Pour l'IHM :
Pour les fonctionnalités :
FREQ=MONTHLY; BYDAY=MON; EXCLUDE=JoursFeries; BYSETPOS=-1(JoursFeriesétant le nom d'un calendrier que l'on a défini par ailleurs avec la liste … des jours fériés).Je ne doute pas qu'il existe des schedulers (? $U ?) qui savent faire bien plus que celui qui est nativement intégré à Oracle. Ce dernier possède cependant, à mon sens, quelques caractéristiques qui peuvent avoir de la valeur selon l'environnement dans lequel on travaille, les contraintes, les besoins, …
En résumé : "ça juste fonctionne" ("it just works"), c'est toujours installé, toujours disponible, et c'est la même chose partout où une base Oracle est déployée.
Perspectives
En complément, par rapport à mon premier post :
Au final, cela peut représenter une "force de frappe" conséquente quand on commence à faire l'inventaire de tous les composants qu'il faut assembler, faire fonctionner de manière harmonieuse et maintenir si on souhaite (ou si on doit !) partir sur une approche "brique par brique" plutôt que "all in one".
Oracle n'est certainement pas une solution miracle mais le produit a de réelles qualités, sur un vaste périmètre, souvent méconnues, et qui prennent tout leur sens quand on considère l'architecture d'un système d'information, sa réalisation, sa qualité, sa maintenance, et son exécution. Libre à chacun de déterminer si les fonctionnalités du produit fournissent de la valeur (qualitatif : moins de code à écrire = moins de bug, moins de technos à assembler et maîtriser, portabilité, …) et si le coût (quantitatif) est compétitif avec d'autres solutions.
Cela influe évidemment sur l'intérêt et le coût d'une migration :
En tout état de cause, merci de ton article initial sur Ora2Pg - il a intégré mon catalogue d'outils "au cas où" et il me permettra peut-être un jour de proposer une solution pertinente à un client.
Au plaisir de te lire à nouveau.
# Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. É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.