Discussion :

[ypicot]

C'est bizarre, j'ai souvenir d'un démarrage impossible avec une alerte concernant la SGA mini...

Je ne sais pas sous windows, mais j'ai déjà installé une 10g sur une fedora avec 256Mo de ram.
L'astuce consiste à pipeauter certaines valeurs dans les fichiers systèmes, et notamment /etc/sysctl.conf

Yvan

[rbaraer]

Question forums, il y en a que 3 (je passe sur les petits forums à 3 posts par mois..) : Les forums Oracle.com, OraFaq.com et developpez.net (qui est le seul francophone)... Donc y pas pléthore de forums Oracle surtout comparés à ceux d'autres techno.

Voici un excellent forum Oracle :

dbforums

Et bien sûr il y a asktom, une vrai mine d'or :-) !

Pour avoir passé 4 ans à développer sous Oracle (9iR2, 10g R1 puis R2) en m'appuyant beaucoup dessus (tous les accès à la base se faisaient par procédures stockées PL/SQL, usage intensif de vues, quelques vues matérialisées, beaucoup d'optimisation) et pour travailler maintenant depuis presque 1 an sous Postgresql et MySQL, je peux dire ceci :

Inconvénients d'Oracle :

- son prix, évidemment, mais Oracle XE est très bien (le site d'annonces immobilières http://www.lautreloc.com que j'ai réalisé s'appuie dessus et fonctionne très bien. De plus, énormément de fonctionnalités sont présentes dans la version "standard" (jusqu'à 4 CPU), qui est à peu près du niveau de prix de SQL Server. Après, la version Entreprise est très chère.
- la lourdeur des installations et patches du serveur
- c'est beaucoup mieux d'avoir un administrateur Oracle avec soi :-)... ou en tout cas prendre le temps de comprendre comment Oracle fonctionne pour bien l'utiliser (traitement des requêtes, gestion du cache, compréhension d'un plan d'exécution, optimisation par réécriture et/ou indexation...). Ce point est valable pour tout SGBD, mais particulièrement pour Oracle.

Honnêtement, il y a des bugs, mais les autres SGBD en ont aussi, et le pire est de loin MySQL (regardez la liste des bugs corrigés à chaque version sur la 5.0, tous les 2 mois en moyenne, c'est incroyable !!!).

Avantages :

- documentation d'EXCELLENTE qualité (en anglais)
- fiable et robuste
- système de sauvegarde très complet et très performant (RMAN, cf posts précédents)
- le scheduler (planificateur de taches) extrêmement complet (introduit en MySQL 5.1, existe pour PostgreSQL en module complémentaire, mais franchement pas très pratique et moins complet)
- les envois de mails, utilisés avec le scheduler pour planifier des envois de mails "de masse" fonction des données (date de péremption de l'annonce qui approche...)
- les vues quelque soit leur complexité (MySQL est ridicule à ce niveau : les SELECT sont interdits dans le FROM d'une vue !!! PG est très bon également)
- les vues matérialisées (MySQL n'a pas, PG pas encore)
- les files de messages (Advanced Queuing, pas dans XE)
- le PL/SQL très complet pour la manipulation des données. Le langage de procédures stockées de MySQL est très insuffisant, notamment dans la gestion des erreurs. Le PL/PgSQL de Postgres est quant à lui très bon.
- PL/SQL : le regroupement de procédures en packages, gestion des droits au niveau du package : les comptes utilisateur "applicatifs" peuvent n'avoir que des droits d'exécution sur package, aucun droit SELECT, INSERT, UPDATE, DELETE, ce qui sécurise les accès à la base depuis les applications. Pour MySQL on ne peut pas regrouper du tout, pour Postgres on regroupe par schémas mais on ne peut pas compiler un schéma entier, contrairement aux packages.
- PL/SQL : toutes les librairies fournies : e-mails, internationalisation, XML...
- SQL : très riche, optimiseur très bon à partir de la 10g R1. Nombreuses fonctions SQL. Fonctions analytiques propriétaires très pratiques parfois.
- Cache de requêtes très performants s'il est correctement utilisé (requêtes préparées, procédures stockées)
- Nombreuses possibilités d'optimisation (indexes b-arbre classiques, indexes sur fonctions... indexes bitmap sur version entreprise). PG est très bon aussi, MySQL est faible ici.
- les transactions autonomes, qui permettent d'ouvrir une transaction indépendante de la transaction courante, hyper-pratique pour logger ! Propre à Oracle pour le moment.

J'en oublie sûrement.

Oracle est extrêmement riche et c'est avec un vrai plaisir que je l'ai utilisé pendant 4 ans. Oracle vaut vraiment la peine si on se donne la peine de lire la doc pour voir tous les outils qu'il propose et qu'on les utilise, car cela peut faire gagner énormément de temps de développement. Cela demande par contre un réel investissement. Je pense que c'est en partie ce qui fait qu'il est beaucoup utilisé aujourd'hui : il est cher mais le package est très très complet. Alors bien sûr si on ne veut l'utiliser que comme une couche de persistance sans intelligence, c'est stupide, même s'il est très fiable et robuste, mais si on l'utilise à fond c'est une vrai mine d'or.

Postgresql est une vrai alternative (fiable, robuste, performant, sécurisé si bien programmé/administré ) mais reste moins riche et n'a pas de support (sauf version payante EnterpriseDb par exemple). MySQL reste très loin du compte pour le moment (je ne vais pas épiloguer ici mais je peux si qqn le désire).

Pour le RAC, il est compris dans la version Standard, cad jusqu'à 4 CPU, après c'est une option très chère sur la version entreprise.

rbaraer

[orafrance]

Je persiste mais pour moi il y a un inconvénient majeur d'Oracle trop souvent passé sous silence c'est le manque de sécurité. La 10g résoud pas mal de problème notamment dans la gestion des mots de passe et le code wrapper mais ça reste très insuffisant

Un exemple de bug toujours pas corrigé à ma connaissance : il est possible de faire un update grace à une simple vue. Cela signifie que les droits en SELECT uniquement ne suffise pas à s'assurer que personne ne viendra modifier les données.

[scheu]

Sur le nombre de bugs élevés d'Oracle, je confirme que c'est parfois déroutant. Ca m'est déjà arrivé de patcher pour corriger un bug, or le patch rajoute un autre bug qui est lui-même corrigé par un autre patch, etc ...

Le pire c'est quand on passe le dernier niveau de patch d'une release majeure (genre 9.2.0.8 pour la 9i) et qu'on rencontre des nouveaux bugs qui ne sont corrigés qu'en 10g En gros on passe de "patch mineur de 9.0.2.x à 9.2.0.8" à "vaste projet de migration de 9i en 10g avec recette, mise à niveau de l'applicatif, etc ..."

Néanmoins la richesse fonctionnelle d'Oracle est telle qu'il y a forcément des compromis comme celui-là, même si le produit est déjà très mature

Comme dirait l'autre : seuls ce qui ne font rien ne font rien ne se plantent jamais ...

[Alain B.]

C'est bizarre, j'ai souvenir d'un démarrage impossible avec une alerte concernant la SGA mini... ça a peut-être changé depuis mon essai alors. Tant mieux

J'ai surtout connu des patchs difficiles pour cette raison.

[retha]

désolé mais il y a également le forum de dba_village.com qui est totalement francophone (bon ok, il n'est pas français mais belge).

Personellement, je travaille sur Oracle depuis la V7 et j'ai un peu travaillé sur SQL-SERVER qui m'a beaucoup déçu notamment au niveau de la sécurité.

C'est vrai les licenses Oracle sont chères mais pour moi, il n'y a pas photo dès que l'on travaille sur de gros volumes notamment dans le décisionnel, je ne jure que par Oracle.

[orafrance]

Personellement, je travaille sur Oracle depuis la V7 et j'ai un peu travaillé sur SQL-SERVER qui m'a beaucoup déçu notamment au niveau de la sécurité.

Ha tiens donc... alors là ça m'intéresse parce que SQL Server utilise la sécurité de Windows qui même si elle est perfectible reste bien plus robuste que celle d'Oracle... c'est donc assez curieux

[wizdom]

Inconvénient d'Oracle pour la tarification avec la virtualisation :

Si on installe une base Oracle dans une machine virtuelle sous VMWARE (par exemple) qui n'utilise qu'un seul processeur sur les 2 procs physiques existants, on doit tout de même payer une licence pour 2 processeurs, car la tarification se base sur les processeurs physiques et non pas sur les virtuels.

Le seul moyen d'éviter cela :

Installer une base Oracle dans une machine virtuelle sous Oracle VM (le produit de virtualisation maison basé sur Xen). La licence se fait alors sur le nombre de processeurs virtuels et non pas physique. Un bel exemple de lobbying.


Dans les avantages, j'aurais cité ce bon vieux SQL*Net (le middleware qui permet de connecter de façon transparente un client et un serveur ou 2 serveurs) :

- Oracle MultiProtocol Interchange : possibilité de communiquer avec des réseaux utilisant des protocoles différents (IP <--> IPX par exemple)
- Oracle Advanced Networking Option : permet notamment l'encryption de la couche SQL*Net pour sécuriser la communication entre le client et le serveur. La liste des fonctionnalités disponibles (http://download.oracle.com/docs/cd/A...a58229/toc.htm) est assez impressionnante.
- Possibilité de traçage (côté client et côté serveur, fonction TNSPING..)

Et puis un autre avantage indéniable : la richesse et la grande diversité des composants disponibles en standard avec la base Oracle. J'en cite ici deux :

- OHS : Oracle HTTP Server (disponible sur le CD "Companion"), qui n'est ni plus ni moins qu'un serveur Apache à la sauce Oracle. Il ne supporte pas officiellement tous les mods apache, mais en plus du mod_plsql, on peux installer en standard le mod_php. Evidemment on préférera sans doute l'original au clone, mais cela permet d'installer un soft open source (Apache) avec un tampon "validé par Oracle" qui plaît toujours à certaines DSI (même si cela reste discutable j'en conviens, mais au moins on peut profiter de la maintenance Oracle sur cette fonctionnalité).

- Oracle Text : ou comment utiliser sa base Oracle pour faire du Google et indexer des documents (dans la base ou en dehors). Au passage, cette fonctionnalité existe également sous XE.

[Alain B.]

Installer une base Oracle dans une machine virtuelle sous Oracle VM (le produit de virtualisation maison basé sur Xen). La licence se fait alors sur le nombre de processeurs virtuels et non pas physique. Un bel exemple de lobbying.

Ca va plus loin, Oracle n'est pas officiellement certifié(=supporté) sur d'autres plateformes de virtualisation que celle d'Oracle.
Le demandeur du support devra prouver lui même que son soucis n'est pas lié à virtualisation (=reproduire le cas sur une plateforme native).

A classer dans la rubrique "inconvénients d'Oracle"...

[wizdom]

Effectivement cette précision est très importante !

Et c'est assez étonnant car je connais un cas (Communauté Urbaine d'une grande ville de l'ouest de la France entourée de chateaux et de vignes) où les bases Oracle sont installées dans des machines virtuelles fonctionnant sous RedHat Linux 4.7 . Ces machines virtuelles tournent sous VMWare ESX 3.0. Toutes leurs bases de prod fonctionnent dans cet environnement. Cela voudrait dire qu'ils se passent du support Oracle en cas de pépin ?

[Vincent Rogier]

Ca va plus loin, Oracle n'est pas officiellement certifié(=supporté) sur d'autres plateformes de virtualisation que celle d'Oracle.
Le demandeur du support devra prouver lui même que son soucis n'est pas lié à virtualisation (=reproduire le cas sur une plateforme native).

A classer dans la rubrique "inconvénients d'Oracle"...

Effectivement, la politique d'Oracle n'est pas très claire dessus...
Mais en cas de bug avéré, le reproduire sur une machine physique est certes emmerdant mais généralement pas un gros obstacle (du moins généralement) ...

[Pomalaix]

Mais en cas de bug avéré, le reproduire sur une machine physique est certes emmerdant mais généralement pas un gros obstacle (du moins généralement) ...

Je suis tout sauf d'accord là-dessus !
Si tu as un problème bloquant de production, que tu dois commencer par trouver un autre serveur physique, installer Oracle, dupliquer ta base, installer l'environnement applicatif, reproduire l'erreur, etc, avant que le support Oracle daigne s'intéresser à ton cas, tu es mal.

Pas de VM sauf la nôtre, c'est honteux comme politique. Mais j'ai tendance à penser qu'ils ne pourront pas tenir ce discours longtemps.

A force de prendre le client pour une vache à lait (repasser à la caisse pour utiliser AWR) et de fournir des produits dont les listes de bogues ont de plus en plus le volume d'un bottin, la vache risque d'aller voir ailleurs si l'herbe ne serait pas plus verte.

[pachot]

Bonjour,

A mon avis le gros avantage d'Oracle, c'est la lecture non bloquante.
Sur la pluspart des SGBD, pour avoir une lecture consistente il faut empêcher des mises à jour concurrentes sur ce qu'on lit. Celà se fait avec des verrous (locks) et peut poser des problèmes (attente de verrous, deadlocks). Même lorqu'on ne fait que lire des données, on bloque les mises à jour.
Oracle et Postgresql ont pris une autre alternative: la lecture ne bloque rien mais reconstruit une image consistente. Oracle le fait grace aux rollback segments (chaque mise à jour génère l'information nécessaire pour retourner en arrière - les rollback segments) L'inconvénient est la gestion des rollback segments, mais celà s'est bien amélioré depuis les dernières versions.
Postgresql le fait en gardant toutes les versions et les nettoyant plus tard. C'est aussi une lecture non bloquant, mais je pense un peu moins performante.

Une autre grosse différence d'architecture entre les différents SGBD est le fonctionnement en cluster: Oracle partage une seule base de données entre plusierus serveurs. Celà permet d'avoir de la haute disponibilité en plus du du load-balancing. Par contre, il peut y avoir des problèmes de performance. La pluspart des autres SGBD partitionnent la base de donnée sur plusieurs serveurs.

Sinon, Oracle a l'avantage d'être portable sur toutes les plateformes, il a une extension procédurale du SQL, le PL/SQL qui est très puissant - mais propriétaire.
Facile de changer d'os, mais pas facile de changer de SGBD.

Il a par contre un domaine où il a toujours été pas terrible: la stabilité des plans d'exécution. Avec DB2 par exemple, le plan d'exécution est déterminé au déploiement. Pas de surprises en production. Oracle a introduit plusieurs moyens d'atteindre ce but, mais ce n'est pas encore l'idéal.

Cordialement,
Franck.

[scheu]

Ces machines virtuelles tournent sous VMWare ESX 3.0. Toutes leurs bases de prod fonctionnent dans cet environnement. Cela voudrait dire qu'ils se passent du support Oracle en cas de pépin ?

La politique d'Oracle n'est pas très claire, il y a une note sur le support Metalink qui, quand je la lis, je comprends que tu as quand-même du support, mais que si ton bug n'est pas référencé, ils ne développeront pas de correctif spécifique spécialement pour toi

Mais même cette note n'est pas très claire et peut être interprêtée de multiples façons ...

Ceci dit, Oracle VM est très peu coûteux (beaucoup moins que VMWare ESX), donc pourquoi pas ?

[orafrance]

Ceci dit, Oracle VM est très peu coûteux (beaucoup moins que VMWare ESX), donc pourquoi pas ?

Parce que VMware c'est assez largement éprouvé alors qu'Oracle VM c'est encore assez confidentiel

[Fabien Celaia]

Il a par contre un domaine où il a toujours été pas terrible: la stabilité des plans d'exécution. Avec DB2 par exemple, le plan d'exécution est déterminé au déploiement. Pas de surprises en production. Oracle a introduit plusieurs moyens d'atteindre ce but, mais ce n'est pas encore l'idéal.

En phase d'être "résolu" via les baselines et le RAT de la 11g.

[eprost]

Pour ceux qui ne connaissent pas Oracle mais veulent réellement se faire une idée de la richesse de la "bête", je suggère de prendre le temps de lire les deux documents suivants qui détaillent les nouveautés de la version 10 et de la version 11. Quelques exemples pour la 11g : intégration au Volume Shadow Services et à Active Directory.

En soi, ces nouveautés ne seront pas toujours très "parlantes", mais à chaque fois, on trouve un lien vers la documentation de référence Oracle qui détaille la chose et permet d'en apprendre plus.

Je recommande de commencer par la doc 10g qui me semble contenir plus de nouveautés "parlantes", c.à.d qui auront un sens pour ceux qui ne maîtrisent pas Oracle.

• Nouveautés 10g
• Nouveautés 11g

De plus, la documentation Oracle est une réelle richesse du produit (ça fait 1,2 Go pour la 10G sur mon poste - j'ai bien écrit 1,2 giga-octets). Elle est consultable et téléchargeable gratuitement sur le site Web OTN (voir ici pour télécharger la doc 10g).

Voir par exemple ici pour un accès à toute la documentation 10g : cliquer ici puis ensuite sur "View Library".


Pour ce qui est des fonctionnalités d'Oracle, je confirme ce qui a déjà été écrit dans ce topic : ce SGBD est bien plus qu'un moteur de base de données et il offre des fonctionnalités qui permettent de réels gains de productivité, à condition de connaître leur existence et de savoir s'en servir.

Je rejoins en cela l'analyse faite par Thomas Kyte (le monsieur derrière AskTom) dans son livre "Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions" (ISBN-10 : 1590595300, feuilletable en ligne sur Amazon) : il ne sert à rien de payer une licence Oracle pour faire du SQL standard. Cela est un réel gâchis car on se prive de multiples fonctionnalités qui font gagner de l'argent et du temps.

Parmi celles-ci, quelques exemples (faites un search dans la doc 10g en ligne pour avoir des explications très détaillées, je donne juste une petite synthèse ici car ce post est déjà long) :

- Index calculés, ou "function based index" : permet de faire un index sur le résultat de 0..n fonctions appliquées aux colonnes de la table. Utile par exemple pour indexer UPPER(NOM) au lieu d'avoir à ajouter une colonne NOM_MAJUSCULES + un trigger + tous les problèmes habituels quand on dénormalise un MCD. Une requête faisant "WHERE UPPER(NOM) = 'TATA' utilisera alors cet index.

- Vues matérialisées, ou "materialized views" : je n'ai pas assez de place pour faire une synthèse vraiment fidèle car ce sont des objets très riches... Disons que c'est l'alliance entre une table et une vue, offrant une grande finesse sur la manière dont les données sont rafraîchies (automatiquement ou non), et utilisable par l'optimiseur pour re-écrire des requêtes qui dont la clause WHERE correspond à celle de la vue matérialisée... Oui, c'est un objet très riche.

- Scheduler : quiconque cherche à déployer rapidement un scheduler fonctionnant de la même manière sur Windows, Linux, Solaris, HPUX, OpenVMS, ... aura à coeur de lire la documentation de cet outil. Il n'atteient pas la souplesse des produits dédiés au scheduling mais il est très très largement supérieur à des solutions type crontab (ou équivalent Windows).

- Advanced Queuing : un broker de messages disposant notamment d'une API JMS, intégré à la base de données, donc exploitable depuis tous les langages supportés par Oracle sur toutes les plate-formes Oracle. Et, comme cela est intégré à la base de données, on ne se demande pas s'il faut faire des transactions XA (ou du code bien plein de bugs pour émuler XA) afin d'avoir la garantie de ne jamais perdre un seul message quoiqu'il arrive.

- Streams et Change Data Capture (en mode asynchrone) : framework et outillage par-dessus permettant de répliquer des données en temps réel entre deux instances Oracle, avec éventuellement des filtrages, des règles de routage pour orienter / dupliquer les données vers plusieurs noeuds physiques, gestion des erreurs, ... le tout étant évidemment totalement transactionnel. Qui a déjà voulu coder ce genre de choses saura apprécier le gain de productivité.

- PL/SQL : un véritable langage de programmation, avec un compilateur optimisant, orienté objet (mais ce n'est pas une obligation d'en faire usage). Conceptuellement, PL/SQL est très proche de ADA (définition de sous-types par exemple).

- Packages pré-installés : la liste est trop longue pour lister tous les packages de code pré-installés, c'est une véritable bibliothèque (indexation full text, ...).

- SQL étendu (oui, pas standard) : gestion native du XML, opérateurs hiérarchiques (chercher "CONNECT BY" par exemple), opérateurs analytiques (chercher "OVER"), ... toutes ces extensions permettent de véritablement tirer profit du SGBD. Les opérateurs analytiques par exemple évitent d'avoir à écrire des requêtes complexes faisant des auto-jointures sur elles-mêmes. Le gain est immédiat en coût de maintenance (et bien souvent en performances). Les opérateurs hiérarchiques permettent de faire des requêtes qui parcourent des structures de données arborescences (sans aucune limite de profondeur, évidemment, avec toute la souplesse de SQL pour définir la relation père <=> fils). Le gain est immédiat en codage et maintenance.

- Optimiseur par les coûts (cost based optimizer) + statistiques données + statistiques système : l'un des points forts du SGBD. Juste pour donner une idée, il est utile de savoir que Oracle va calculer le chemin d'accès physique aux données (= le plan d'exécution) en fonction de la répartition statistique des valeurs dans les tables (+ index existants) afin de choisir le ou les index qui seront les plus efficaces pour les valeurs données dans la clause WHERE. Mais cela va aussi être pondéré par le fait que l'index et la table sont à peu près (ou non) organisés physiquement dans le même ordre (sinon, cela génère beaucoup d'I/O sur des blocs très éloignés les uns des autres). Cela peut aussi être pondéré par les performances du CPU, des I/O pour x blocs séquentiels, pour x blocs aléatoires, ...

- Consistent read : encore un élément capital qui est bien souvent ignoré (sauf par Firebird, PGSQL), qui fait que le SGBD pose très très très peu de verrous. Cela est un facteur clef quand on doit faire face à une montée de charge car Oracle. Par exemple, Oracle ne pose aucun verrou quand on fait un SELECT : une autre session peut faire de l'UPDATE sur les mêmes lignes sans être bloquée, à l'inverse de beaucoup d'autres SGBD. Ce fonctionnement est natif, c'est d'ailleurs la seule et unique manière dont Oracle sait fonctionner. Quand on a un système avec plusieurs centaines de requêtes par seconde en concurrence sur une même table, ça fait un sérieux avantage, en prenant bien conscience que la performance ne se fait pas au prix de dénormalisations du MCD pour ajouter des tables intermédiaires, "tordre" les requêtes, ou que sais-je encore.

- Consistent read : c'est aussi cette fonctionnalité qui fait que les résultats produits par une requête Oracle sont toujours cohérents par rapport à l'isolation (souvenez-vous, le I de ACID). Pour faire un reporting un peu gourmand par exemple, on passe en mode READONLY (ou SERIALIZED si écritures nécessaires) et on peut laisser tourner les 50 requêtes de reporting pendant 5 heures : le résultat fourni à la fin sera totalement isolé de ce qui a été fait sur le SGBD pendant 5 heures ET sera totalement cohérent (un count(*) from T fait un début retourne le même résultat quand on l'exécute 5 heures après, même si la table T a grossi de 1 million de lignes) ET tout ceci est obtenu "out of the box" de manière native.

- Architecture et consistent read : le bon fonctionnement d'une requête Oracle dépend uniquement de l'espace disque attribué Oracle. Cela paraît anodin mais je pense que c'est plus profond qu'il n'y paraît et cela a de véritables impacts en termes de productivité. En effet, l'architecture Oracle est très largement basée sur les journaux (redo logs et archive logs) afin d'offrir ce fameux "consistent read". En première lecture, on comprend qu'il faut acheter des disques durs ou du SAN. C'est vrai. Mais en seconde analyse, on comprend surtout que l'on peut coder les fontions d'une application de manière "naturelle", c.à.d avec un seul et unique COMMIT à la fin, lorsque tout le travail a été fait. Je m'explique : combien de fois avez-vous vu du code qui fait des trucs du genre "lecture ligne à ligne, traitement, si nb_lignes % 500 = 0 alors tracer 'je suis à la ligne XXX' puis commit, etc" ? Ce sont de véritables mines : si le traitement plante au milieu, il faut prévoir du code pour repartir (= bug, = maintenance, = cher). Et surtout, cela laisse la base de données dans un état incohérent - c'est dramatique. Il faut alors faire le traitement dans des tables annexes, isolées, ... = code, = bug, = cher... L'architecture Oracle permet (d'autres aussi ?) de ne pas faire de genre de code : on code l'application en fonction des contraintes métier et le COMMIT est codé quand on a atteint un état cohérent, pas avant. Ensuite, c'est à l'architecture système de s'adapter, et c'est la bonne démarche (ou alors, c'est qu'on n'a pas les moyens de ses ambitions, et le problème n'est plus technique). Tout cela se fait sans aucune difficulté technique.

- Architecture : pour illustrer la richesse de la chose par rapport au point précédent, on peut même ajouter de l'espace disque à Oracle "à chaud" : en attendant que le DBA et l'ingénieur système interviennent pour allouer un peu plus d'espace disque, le moteur se met en attente, les requêtes qui ont provoqué le débordement disque sont juste bloquées. Puis, après ajout d'espace disque, tout repart, zéro plantage, zéro arrêt, les applications qui avaient des requêtes en cours n'ont strictement rien vu. Cela est un véritable gain par rapport à un Système d'Information qui se plante à cause d'un "file system full" provoqué par une volumétrie inattendue par exemple.

- Et de multiples autres choses telles que RMAN qui est un véritable outil de backup à chaud / à froid livré en standard, ou encore Oracle Enterprise Manager (= frontal Web d'administration), ou encore AWR (= collecte en temps réel de métriques de performance très très pointues), ...

Donc, pour synthétiser : quand on achète Oracle, on achète une Formule 1 car on a pour objectif de gagner un Grand Prix. Dès lors, il faut s'entourer d'expertise (ou l'acquérir) afin de savoir tirer profit d'un engin exceptionnel et des capacités qu'il offre (et cela est certainement vrai pour d'autres SGBD).

Dès lors, il est également contre-productif de vouloir s'en tenir à du SQL standard (que ce soit avec Oracle ou d'autres) : quel intérêt ? j'ai payé pour avoir accès à du SQL performant, pourquoi s'en priver ? qui oserait dire par exemple "on va coder en Java mais il faut être portable vers C#, Pascal et COBOL" ? en quoi est-ce différent pour un SGBD ?

Maintenant, si l'objectif n'est pas de gagner un Grand Prix (ou si on n'a pas les moyens / le temps d'apprendre à conduire une Formule 1), alors il faut impérativement choisir un véhicule plus approprié.

Merci de leur courage à ceux qui ont lu ce post jusqu'ici...

[eprost]

En phase d'être "résolu" via les baselines et le RAT de la 11g.

Il reste toutefois à déterminer si la stabilité du plan d'exécution est souhaitable ou pas, et quand il est préférable de déterminer ledit plan. Je pense que la réponse dépend du contexte et ne peut pas être décidée de manière absolue.

En la matière, Oracle offre des choix et je considère que cela constitue un atout par rapport à d'autres SGBD qui sont peut-être plus directifs et moins souples. Il y a aussi des limitations à connaître.

Avertissement : mon propos se base sur ce que je connais d'Oracle 10g. Je sais que la version 11 apporte des améliorations en la matière mais je ne les connais pas assez pour m'exprimer sur ce sujet (et surtout, je ne les ai pas mises en oeuvre).

# Plan d'exécution calculé lors du déploiement

Déterminer le plan d'exécution lors du déploiement ne permet pas - je suppose car je ne connais pas assez DB2 - de tirer profit des caractéristiques des données stockées dans les tables.

C'est une chose que l'optimiseur Oracle sait faire (je crois que c'est depuis la 9i, sortie en 2000) : par exemple, quand on écrit "where col = 'YES'", le plan d'exécution pourra être différent selon que 'YES' est une valeur très sélective ou pas au moment de l'exécution de la requête, en fonction des statistiques collectées sur le contenu des tables concernées par la requête et leurs index. Typiquement, dans l'exemple "where col = 'YES'" :

• Si on a un index sur la colonne mais que 80% des valeurs sont 'YES', il est alors probablement inutile, et surtout inefficace, d'utiliser cet index : on va parcourir (gross modo) 80% des blocs de l'index, puis (grosso-modo) 80% des blocs de la table. Il est préférable de parcourir directement la table, sans passer par l'index : en termes de volume, ce sera peu ou prou la même chose. Et en termes d'I/O disque, ce sera beaucoup mieux car on peut faire des lectures multi-blocs (= rapides) pour parcourir toute la table plutôt que d'avoir à faire des allers/retours entre les blocs de l'index et les blocs de la table.
• A l'inverse, si les statistiques collectées par Oracle sur cet index montrent que la valeur 'YES' correspond à 10% des valeurs, alors il est très efficace d'exploiter cet index, tant en termes d'I/O que de performances.
• Nota : bien comprendre que l'exemple donné ci-dessus n'est pas une vérité absolue, c'est juste une illustration. En pratique, la manière dont Oracle détermine le plan d'exécution est bien plus complexe et peut, par exemple, prendre en compte la performance relative des lectures mono-blocs, multi-blocs, séquentielles, et aléatoires du sous-système disque utilisé.

Evidemment, on peut vouloir figer un plan d'exécution lors du déploiement : on a trouvé un plan meilleur que celui produit par l'optimiseur, on considère que la stabilité est primordiale sur la performance (voir plus bas), ...

Dans ce cas, le comportement de DB2 semble pertinent et il est utile de savoir que Oracle permet d'obtenir ce même comportement.

Cela peut se faire en utilisant ce que l'on appelle des "hint" dans la litérature Oracle. Ce sont des directives techniques, données sous forme de commentaires dans la requête et qui respectent un formatage particulier. Par exemple "SELECT /*+ INDEX(T I) */ ... FROM T WHERE ..." permet de forcer l'utilisation de l'index I pour accéder à la table T.

Cela peut aussi se faire en déployant ce que l'on appelle un "stored outline", c.à.d un plan d'exécution complet généré par une exécution précédente ou généré par le moteur lui-même en lui demandant de prendre tout le temps nécessaire pour trouver le "meilleur" plan. Cela peut être réalisé sur une plate-forme de pré-production, ou directement en production, le jour du déploiement.

A mon sens, l'intérêt d'Oracle sur DB2 dans ce cas est que JE décide de ce qui est le meilleur comportement : figer au déploiement ou non.


# De l'intérêt ou non de la stabilité du plan d'exécution

La stabilité du plan d'exécution peut-être une bonne chose. Ce peut-être une simple mesure de prudence car on ne veut pas avoir de "surprise" lorsque le système passe en production.

Dans ce cas, les "hint" et "stored outline" décrits auparavant constituent une bonne solution.

Mais cela a un inconvénient si on souhaite généraliser la chose à toutes les requêtes exécutables par l'application : il faut alors faire un travail préparatoire important, soit pour "hint"er toutes les requêtes (argh !), soit pour générer tous les "stored outline", ce qui nécessite là encore une phase de collecte exhaustive (argh encore !).

On peut limiter l'ampleur de la tâche en demandant à Oracle de se mettre dans un mode de collecte : de là, on fait un "run" de l'application. Une fois ceci fait, on ferme la collecte et on fige les plans d'exécution : ils seront alors utilisés lors des prochains "run" de l'application (je crois que ceci est le mode opératoire recommandé par Oracle pour passer de l'optimiseur "par règles" de la version 8 à l'optimiseur "par coûts" de la 9i). Là encore, il y a toutefois au moins un inconvénient : il faut que le "run" initial couvre toutes les requêtes pour lesquelles on veut une stabilité du plan d'exécution (et, inconvénient plus subtil : il faut que ce "run" initial soit fait avec des données d'entrée représentatives - voir l'exemple du "where col = 'yes'" au dessus => si le premier "run" est fait avec 'col = 'yes'" mais que l'application va ensuite plus souvent utiliser "col = 'no'", le plan "pré-mâché" sera très souvent inefficace).

Je considère que ceci est une des limites d'Oracle : obtenir la stabilité totale de tous les plans d'exécution est un objectif compliqué à atteindre (je connais surtout la 10g - c'est peut-être différent sur d'autres versions)

Question ouverte : Comment faire pour les requêtes dont le texte est généré dynamiquement par le code, par exemple pour faire une recherche multi-critères avec une liste de critères variables ? On remarquera que cette question concerne tous les moteurs SGBD.


D'un autre côté, la stabilité de tous les plans d'exécution n'est pas toujours un objectif souhaitable. En effet, si on reprend l'exemple "where col = 'YES'", on peut vouloir obtenir la meilleure performance pour 'YES' ET pour 'NO', plutôt que d'avoir une bonne performance pour 'YES' à l'aide d'un plan figé MAIS une performance moyenne voire faible pour 'NO'...

Dans ce cas, on laisse Oracle faire sa cuisine par défaut sur toutes les requêtes et on utilise les "hint" ou "stored outline" sur le périmètre des requêtes que l'on identifie comme critiques au niveau fonctionnel, ou qui ont été identifiées automatiquement par les composants AWR + ADDM d'Oracle comme très consommatrices de ressources (AWR + ADDM collectent des métriques de performance très variées en temps réel et en déduisent des recommandations pour, par exemple, attirer l'attention des DBAs et développeurs sur les requêtes les plus longues, les plus coûteuses en I/O, en CPU, en espace disque dans les journaux, ... le rendu de la chose peut se faire par requête SQL ou de manière intuitive dans l'IHM Web offerte par la composant natif nommé OEM - de là, il est alors possible de demander à Oracle de faire une analyse poussée de la requête afin de déterminer un plan d'exécution optimal, lequel peut ensuite être stocké en "stored outline" ; le moteur peut aussi conseiller d'ajouter un index sur quelques colonnes bien choisies).

Note : sous réserve du peu de connaissances que j'ai de la 11g, ce comportement d'auto-adaptation des plans d'exécution est intégré à 11g.

Il convient toutefois de noter que Oracle, commes tous les autres moteurs, recommande de ne jamais construire les requêtes par concaténation de chaînes de caractères afin d'éviter les attques de type "sql injection". Il est nettement préférable d'utiliser ce que l'on appelle le "binding". C.à.d que la requête est écrite sous la forme "select * from T where C = :V" et l'application utilise une API lui permettant de transmettre au moteur la valeur de la pseudo-variable identifiée par ":V". Ceci évite tout risque d'injection SQL, et c'est - définitivement - une bonne chose.

Note : les détails techniques peuvent varier selon que l'on fait du COBOL avec le pré-compilateur ou du JDBC en Java ou ... mais le principe reste le même, et, que je sache, cela est vrai pour tous les SGBD.

Le comportement par défaut d'Oracle (10g !) sur des requêtes de type "where C = :V" peut cependant s'avérer surprenant, voire néfaste. En effet, lors de la première exécution de cette requête, Oracle détermine le plan d'exécution adéquat, et si elle connue, la valeur de ":V" au moment de cette première exécution est utilisée. Ensuite, lors des exécutions suivantes et sous réserve que le plan n'ait pas été purgé du cache (algorithme type LRU), ce plan sera systématiquement ré-utilisé. Cela permet de gagner du temps car générer un plan d'exécution est une opération coûteuse : pour une application de type OLTP qui émet quelques centaines de requêtes par seconde, on ne peut pas se permettre de calculer systématiquement un plan.

Et on atteint là une seconde limite d'Oracle (10g) : en effet, lorsque la première exécution est faite avec des valeurs dans la clause WHERE qui correspondent à un cas particulier, le plan sera généré pour ce cas particulier, et ré-utilisé ensuite pour les autres appels. Il sera alors statistiquement inefficace. Pour reprendre l'exemple sur "where col = 'YES', si 'YES' correspond à 80% des valeurs et que c'est ainsi qu'est exécutée la requête la première fois, le plan sera (probablement) un parcours séquentiel de la table. Malheureusement, ce plan sera réutilisé lorsque l'application va exécuter "where col = 'NO'", et ce sera très inefficace car 'NO' correspond à 20% de la table : un parcours d'index aurait été préférable.

Ce fonctionnement, nommé "bind variable peeking" dans la littérature Oracle peut être un piège.

Note : de ce que j'en connais, la 11g apporte des améliorations en la matière en re-évaluant les valeurs des paramètres "bind"és pour déterminer s'il est utile ou pas de regénérer un plan d'exécution.

Ayant été confronté à ce problème sur un système en production de type Decision System (donc pas OLTP), nous avons résolu la chose pour les requêtes émises par notre code (C#) en ajoutant systématiquement un commentaire aléatoire dans chaque requête (select /* guid généré à chaque fois */ ...). Cela force l'optimiseur Oracle à considérer que chacune de nos requêtes est unique. Nous contraignons ainsi l'optimiseur à calculer à chaque fois un nouveau plan d'exécution, optimal pour les valeurs données dans la clause WHERE.

Note : attention, ceci est une solution particulière à un problème particulier sur un environnement particulier dans un périmètre applicatif particulier - je ne recommande à personne de généraliser la chose sans réflexion préalable et sans avoir pris bonne note que l'environnement dont je parle n'est pas OLTP ou "temps réel".

Il reste le cas du code écrit en PL/SQL : par défaut, toutes les requêtes codées en PL/SQL font du "binding". Sauf "hint" ou "stored outline", elles sont donc sujettes au piège du "bind variable peeking". A ce jour, si on ne veut pas faire du "hint" ou du "stored outline", je pense que la seule solution est de faire des requêtes dynamiques en PL/SQL, c.à.d à la manière de JDBC par exemple, en ajoutant le fameux commentaire aléatoire qui force l'optimiseur à croire que c'est la première fois qu'il voit notre requête.

Au final, tout est cependant une affaire de nuance et de contexte : les comportements décrits ici peuvent être hautement souhaitables, par exemple dans un environnement qui "crache" des kilos de "petites" requêtes à la seconde. Idem quand on fait du reporting : il est utile que la requête du rapport utilise au mieux les critères donnés par l'utilisateur en fonction du contenu effectif des tables et des index. A l'inverse, on peut considérer qu'il est préférable d'avoir un plan d'exécution figé "pour toujours" et dont la performance sera - probablement - toujours moyenne. Comme on dit, "your mileage may vary"...

En comparaison avec d'autres moteurs, je considère que c'est un véritable avantage de travailler avec un moteur qui permet de faire un réel tuning sur les plans d'exécution des requêtes très coûteuses sans avoir nécessairement besoin de re-écrire la requête (voire, pire, de modifier le modèle physique). Il est important de bien comprendre que ce tuning se fait, sauf rares exceptions :

• au niveau système ;
• pour la requête qui pose problème ;
• en fonction de l'environnement sur lequel est déployée l'application (perfs des disques, contenu effectif des tables mises en oeuvre, ...) ;
• sans toucher au SQL ;
• sans toucher à l'application (capital !) ;
• sans toucher à la structure des tables (capital !).

Cela constitue un gain de temps et d'argent (je parle d'expérience pour avoir été contraint plus d'une fois à modifier des requêtes, la logique applicative, voire à créer des tables supplémentaires juste pour résoudre un problème de performance SQL).


# Synthèse

Comme sur d'autres sujets, il me semble que le fonctionnement d'Oracle sur les plans d'exécution est très riche.

Cela constitue évidemment un avantage. Mais cela peut aussi être perçu comme un inconvénient, soit que l'on constate des comportements "bizarres" que l'on n'explique pas car, bien souvent, on n'a pas idée de la richesse du moteur, donc de sa complexité, soit que l'on ne peut pas acquérir l'expertise nécessaire (ou la payer). Dans les deux cas, il en résulte obligatoirement une grande insatisfaction, et probablement, un sentiment de rejet d'Oracle.

Formulé autrement : à mon sens, comparativement à d'autres moteurs, Oracle offre une réelle valeur ajoutée sur bien des sujets (ici, les plans d'exécution) mais il faut s'investir pour en tirer toute la puissance et en comprendre les limites. Si vous avez besoin d'une fusée pour aller sur la lune, il faudra nécessairement passer du temps pour apprendre à quoi peuvent bien servir tous les boutons sur le tableau de bord ou se payer les services d'un pilote assermenté. Sinon, on accepte de prendre le risque de s'écraser, ou on prend un autre véhicule, ou on dépense beaucoup d'argent à vouloir re-construire une fusée puis on dépense ensuite encore plus d'argent pour faire la maintenance de la chose, ou on décide que "finalement tout bien considéré" on veut pas aller sur la lune, ou alors moins vite que prévu...

Choisir Oracle ou un autre moteur est une affaire de nuances et de contexte, pas une vérité absolue. Il ne fait aucun doute que déployer SQL Server avec une équipe DBA qui connaît bien le produit peut être une excellente solution. Et il ne fait, à mon avis, aucun doute, que Oracle offre une palette de fonctionnalités très riches dont il convient de connaître l'existence et les limites avant de s'engager dans l'achat de licences.

[eprost]

...

Un exemple de bug toujours pas corrigé à ma connaissance : il est possible de faire un update grace à une simple vue. Cela signifie que les droits en SELECT uniquement ne suffise pas à s'assurer que personne ne viendra modifier les données.

Bonjour,

Tu peux nous fournir plus d'info sur cette faille ? Un numéro de bug MetaLink ou un truc de ce genre ?

Ou alors tu confonds peut-être avec le fait que l'on peut exécuter un UPDATE sur une vue si elle n'a pas été déclarée avec l'option WITH READ ONLY (et sous réserve de la complexité de la requête qui définit la vue) ?

Voir par exemple la doc de la 10g sur UPDATE, et surtout la documentation sur CREATE VIEW, chercher "Notes on Updatable Views" pour quelques informations sur le sujet (extrait : "An updatable view is one you can use to insert, update, or delete base table rows.").


Cela étant, de manière plus générale, il me semble qu'une telle faille nécessite un accès direct à la base de données (ou doit faire usage d'une autre faille de type sql injection rendue possible via la couche applicative) ? A ma connaissance, sur un environnement de production normal, personne n'a accès direct à la base sauf quelques personnes de confiance (par nécessité) type DBA ou équipe support d'urgence pour les "corrections à chaud". Et il y a eu assez de cas d'injections SQL pour que des chantiers de sécurisation soient mis en oeuvre au niveau applicatif ou par déploiement d'un proxy applicatif ou ... mais on n'a pas le droit de laisser une telle faille ouverte.

Je sais que cela ne corrige pas la faille que tu décris mais on ne peut pas considérer la sécurité sous le seul point de vue d'un unique composant de l'architecture. Tordons un peu la situation et faisons l'hypothèse que SQL Server est plus sécurisé que Oracle (je n'en sais absolument rien, c'est une hypothèse). Maintenant, je mets SQL Server sur une machine qui est connectée en direct à Internet, pas de firewall, tous les services Windows par défaut activés, et des pages Web qui générent directement le code des requêtes SQL sur le poste client par concaténation de chaînes de caractères : quelle est alors la sécurité de mon Système d'Information ? J'ai une base de données blindée hébergée sur une architecture pleine de trous à tous les niveaux. Je préfère ne pas être celui qui a conçu cette architecture et qui devra répondre devant sa hiérarchie quand ça va commencer à chauffer parce que dire "SQL Server a été bien blindé" ne suffira pas.

=> Au final, peu importe que SQL Server ou Oracle ou ... possède plus ou moins de failles de sécurité. Je pense que ce qui est important, c'est de connaître ces failles et d'être capable de s'en prémunir à l'aide d'une architecture correctement conçue (sans avoir besoin de faire des contorsions, évidemment, sinon on a un problème de coût et de complexité).


Merci de ton retour sur le numéro de bug, cordialement.

[orafrance]

Ou alors tu confonds peut-être avec le fait que l'on peut exécuter un UPDATE sur une vue si elle n'a pas été déclarée avec l'option WITH READ ONLY (et sous réserve de la complexité de la requête qui définit la vue) ?

Je ne sais plus exactement mais c'est un truc du style ne effet. Si tu as les droits CREATE VIEW même sans avoir les droits UPDATE tu peux mettre une table à jour... ce qui est "facheux"

Cela étant, de manière plus générale, il me semble qu'une telle faille nécessite un accès direct à la base de données (ou doit faire usage d'une autre faille de type sql injection rendue possible via la couche applicative) ?

Peu importe, le piratage vient souvent de l'interieur et j'estime qu'autoriser la mise à jour du table alors que t'es sensé ne pouvoir que la consulter c'est une faille

Maintenant, je mets SQL Server sur une machine qui est connectée en direct à Internet, pas de firewall, tous les services Windows par défaut activés, et des pages Web qui générent directement le code des requêtes SQL sur le poste client par concaténation de chaînes de caractères : quelle est alors la sécurité de mon Système d'Information ? J'ai une base de données blindée hébergée sur une architecture pleine de trous à tous les niveaux. Je préfère ne pas être celui qui a conçu cette architecture et qui devra répondre devant sa hiérarchie quand ça va commencer à chauffer parce que dire "SQL Server a été bien blindé" ne suffira pas.

Je ne te parle pas de bonnes pratiques en terme de sécurité mais bien de failles. Et pouvoir écrire dans une table sans avoir de privilège UPDATE c'est une faille

=> Au final, peu importe que SQL Server ou Oracle ou ... possède plus ou moins de failles de sécurité. Je pense que ce qui est important, c'est de connaître ces failles et d'être capable de s'en prémunir à l'aide d'une architecture correctement conçue (sans avoir besoin de faire des contorsions, évidemment, sinon on a un problème de coût et de complexité).

Moi je pense que c'est à l'éditeur d'éviter les failles et pas au client de monter des solutions plus ou moins contraignantes pour s'en prémunir. Si la solution c'est interdire le CREATE VIEW alors c'est pas une solution, c'est juste la suppression d'une fonctionnalité