Certes, je ne suis pas le DBA d’un data center de Software As A Service dans le cloud genre Salesforce, marché où la pléthore d’instances à administrer et consolider pose un réel problème. Moi, j’ai au mieux deux-trois bases Oracle sous la main, de versions différentes pour correspondre aux besoins de mes clients.

Je ne m’appelle pas non plus Richard Foote, qui est sans doute l’homme de la situation pour gratter 5% de perfs sur une base de plusieurs pétaoctets ; mais comme mes clients ont parfois de la peine à dépasser le gigaoctet, je n’ai pas les mêmes besoins. Je lis survole le blog de Foote avec le même émerveillement que mes anciens cours de prépa (« si je le voulais vraiment, avec du temps, je pourrais comprendre ça, mais je n’en ni le besoin ni le temps ni l’envie »).

Dans le même ordre d’idées, ça fait des années que je ne cherche plus à comprendre les choix de l’optimiseur d’Oracle. Je tiens à jour mes stats, je lui fais confiance et inch’Allah.

Bref, quel intérêt peut avoir la nouvelle base 12c toute neuve pour moi et mes clients, dont les volumétries sont donc assez modestes, très loin du big data ?

c

Le c de 12c veut dire cloud. En suivant la mode, Oracle ne prend pas de risque. 8i et 9i (i pour Internet) surfaient sur la vague vers l’an 2000 ; par contre 10g et 11g (grid) n’ont pas marqué les esprits point de vue marketing.

Multitenant

Au premier abord, LA grande nouveauté annoncée à grands renforts de trompettes, l’architecture multitenant semble une usine à gaz.

Au deuxième abord, on comprend qu’elle peut rendre de grands services aux fans de SaaS ci-dessus décrits, qui pourront consolider de nombreuses bases sur un seul serveur en gardant le même moteur. Hé, même au boulot ça pourrait nous servir : ras-le-bol des instances ne contenant qu’un petit référentiel, et mangeant un gigaoctet de mémoire juste pour se tourner les pouces.

Au troisième abord, on réalise qu’Oracle ne fait que corriger une grosse erreur de conception du début, à savoir considérer que les utilisateurs sont au sein d’une base et non séparés de la base. Toute la concurrence que je connais (MySQL, PostgreSQL, SQL Server...) considère qu’un utilisateur peut utiliser plusieurs bases, tout en incluant la notion de schéma comme espace de regroupement des tables et autres objets au sein de cette base, et avec un et un seul moteur commun aux bases. Sur Oracle, ça n’était pas possible. On pouvait toujours importer le contenu d’une base dans une autre, mais ça gênait les imports/exports en bloc, et en cas de schéma/utilisateur commun aux bases, on était bien embêté. Impossible par exemple d’avoir la base de dév’ d’une application au nom de schéma codé en dur dans la même instance que celle de test : on devait se rabattre sur deux instances séparées se battant pour les ressources de la machine.

Comme toujours avec Oracle, la compatibilité ascendante et l’incapacité à penser simplement a mené à toute une usine à gaz de bases container et pluggables. Les utilisateurs restent indépendants mais on peut en créer des communs.

Certains à-côtés sont plaisants, comme le clonage d’une base en quelques commandes (et même quelques secondes si le système de fichiers est en copy-on-write comme ZFS, peut-être btrfs mais ça a planté quand j’ai essayé ; quoique il y ait des restrictions relativement raisonnables).

La possibilité de déplacer une base d’un serveur à l’autre (déplug et re-plug) peut sacrément faciliter des montées de versions base par base. Et du point de vue de l’utilisateur final, c’est transparent, il ne voit que des bases indépendantes.

Évidemment, nous sommes sous Oracle, il y a des pièges : le démarrage des bases pluggables n’est pas automatique, il faut ajouter manuellement un trigger (!) ; et la création de la console web d’administration n’est pas spontanée non plus

Colonnes invisibles

C’est ballot, mais par défaut ni SQL Server ni PostgreSQL ni Oracle avant la 12c ne permettent de changer l’ordre des colonnes d’une table, au moins l’ordre apparent. Sous MySQL c’est possible. Des bidouilles existent, à base de recopie vers une autre table dans un ordre différent, mais deviennent pénibles avec de la volumétrie ou des contraintes entre tables. Ou encore les editioning views sous Oracle 11g, mais intercaler une vue rajoute un niveau de complexité (et de bugs vicieux).

Les puristes objectent que l’ordre d’un SELECT * n’a pas à être plus défini que celui des lignes d’une table (en clair : indéfini), et qu’il faut éviter de faire un SELECT *. Mais la réalité est là : le SELECT * est bien pratique en développement, et il existe malheureusement une foule d’outils qui se basent sur l’ordre des colonnes des tables. Le problème n’est pas qu’esthétique. Je rappellerai que le SQL est à l’origine destiné aux utilisateurs non informaticiens, il a une charge sémantique, et l’ordre des champs en fait partie.

Arrive Oracle 12c et ses colonnes invisibles, c'est-à-dire des champs de tables que l’on peut masquer dans le SELECT *. Ça n’a apparemment rien à voir avec le problème précédent, sauf que masquer une colonne cachée la fait réapparaître en fin de table. Pour réordonner des colonnes, on masquera donc presque tout, pour démasquer dans l’ordre esthétiquement et fonctionnellement le plus pertinent : par exemple clé primaire d’abord, clé alternative ensuite, puis clés étrangères, dimensions dégénérées, indicateurs, et chacun par ordre alphabétique.

Tout cela n’a pas d’impact sur l’ordre des champs dans la table physique (ce dont, fondamentalement, personne ne devrait avoir rien à battre).

Ajoutons des colonnes virtuelles : le résultat d’un SELECT * n’a plus qu’un lointain rapport avec ce qui se trouve sur le disque dur. Perturbant mais parfois très pratique.

Outils annexes

  • EM Express, en flash, postule au rang de nouvelle console d’administration de la base de données (pluggable ou pas). Comme j’ai écrit dans le billet précédent, elle fait plutôt de la pub à tous les outils concurrents. La console de surveillance se laisse voir, toutefois.
  • SQL Developer passe en version 4. J’ai testé et approuvé. Il remplace souvent avantageusement l’outil précédent pour les opérations d’administration.

Ce qu’il y a aussi

Le site de Digora résume bien d’autres nouveautés plus mineures (page 1, 2, 3) notamment pour l’administration.

Je retiens surtout le déplacement des fichiers de données sans arrêter la base, ou la fusion de partitions. Il y a plein d’autres petits détails qui ravissent les spécialistes.

Ce qu’il n’y a pas

Dieu Larry Ellison a promis que la base serait buzzword-compatible dès la prochaine release : en clair, la 12cR2 supportera le in memory. (Oui, chez Oracle, il faut toujours attendre la R2).

Cet effet d’annonce est probablement destiné à rattraper le retard sur la base HANA de SAP, en gros une base de données à peu près intégralement en mémoire, avec les améliorations en performance que l’on devine. À plus petite échelle, Qlikview a montré tout l’intérêt de tout monter en mémoire (malgré de sévères limites). Coup de bol, SAP a le « complexe du panzer géant » et l’habitude de rendre le plus simple trop complexe, laissant ainsi le temps à Oracle de torcher une option IN MEMORY sans doute pleine de limites, et dont il faudra prouver l’intérêt — après tout Oracle sait déjà utiliser en cache l’espace mémoire qu’on lui donne.

Dans le camp d’en face, Microsoft SQL Server 2014 annonce aussi une option in memory. Je suis curieux de voir le résultat sur de vraies tables de bases de données.

Bref, comme souvent chez Oracle : attendons la 12cR2 ! De toute façon le temps que mes clients migrent tous il y en a pour une demi-décennie…