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.
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...
1 |
0 |
Salut,
Envoyé par voran
Mirroring, copie de base de données ou la sécurité sont indéniablement des points forts de SQL Server... et il n'y a rien d'étonnant à ça : c'est évidemment beaucoup plus simple d'améliorer l'intégration du SGBD avec le système quand on est éditeur du SGBD et de l'OS sur lequel il est installé 