Aperçu des entrailles de la base de données Oracle 12c avec Digora
Publié par La rédaction le | Mis à jour le
Beaucoup de monde évoque Oracle 12c, mais peu l'ont réellement exploré. Entretien avec Gery Pannequin, responsable avant-vente chez Digora, qui évoque quelques innovations attendues ou appréciables.
Spécialiste des bases de données, la société de services Digora dispose de fortes compétences Oracle depuis sa création en 1997. Voir à ce propos notre portrait : « L'expert des infrastructures critiques Digora monte en puissance ».
Parmi ses consultants, trois personnes disposant de la plus haute certification Oracle, à savoir l'OCM ou Oracle Certified Master, ont fait partie du programme bêta test d'Oracle 12c, lancé au printemps 2013.
Silicon.fr a interrogé l'un de ces spécialistes pour parler de quelques évolutions qui lui semblent importantes dans cette nouvelle version (tout juste disponible) du SGBD leader du marché mondial.
On fait grand bruit sur le multitenant. Qu'est-ce que cela apporte réellement ?
Si un client (entreprise ou hébergeur, par exemple) possède une application de comptabilité qu'il souhaite installer plusieurs fois, et que l'application ne permet pas d'héberger plusieurs sociétés dans la même base de données, il devra installer autant de bases de données que d'entités utilisatrices.
C'est pourquoi on constate fréquemment dans certains environnements 5 à 10 bases de données installées sur un même serveur et même plus parfois. Avec au final "n" instances en mémoire.
Si l'entreprise utilise la solution RAC (Real Application Clusters), elle se retrouve alors avec n instances sur le serveur 1, n instances sur le serveur 2, et donc de nombreux processus de gestion de verrouillage de base entre les serveurs du cluster.
Avec le multitenant, il suffit d'ajouter des bases dans un conteneur général. Ce qui procure une architecture beaucoup plus performante et simplifie fortement l'infrastructure finale. Cela favorise également la consolidation des différentes bases de données.
En quoi la nouvelle gestion multithread sous Unix apporte-t-elle un plus ?
Historiquement sous Unix (tous les Unix), toute session Oracle déclenche la création d'un processus Unix. Jusqu'à la version 11 Oracle, on retrouve donc un processus Unix par base de donnée auxquels il faut ajouter les processus d'arrière plan Oracle. Sous Windows, un seul processus par base contient tous les threads des sessions de la base.
La version 12c sait gérer plusieurs threads dans un même processus Unix. Outre des gains en performances, l'utilisateur y gagne une meilleure gestion de la mémoire et des changements de contexte bien moins lourd. Désormais, les traitements Oracle peuvent donc tirer un meilleur parti des processeurs disposant de nombreux threads, SPARC, par exemple.
Et la technologie de threads est d'autant plus efficace que le nombre de connexions est élevé. En effet jusqu'à présent, chaque connexion nécessitait un processus.
Côté stockage, la nouvelle mouture a-t-elle aussi amélioré la situation ?
Sur ce point, il faut signaler une avancée importante dans la gestion du cycle de vie des données. Avec cette version, Oracle peut positionner les données en sélectionnant automatiquement un support de stockage en fonction de la criticité de l'information, de sa fraîcheur, etc. Pour y parvenir, les algorithmes tirent profit des statistiques sur les lignes ou sur les tables. La solution distingue trois niveaux : actif (mises à jour fréquentes), accès fréquent en consultation, ou archivage.
Outre ces capacités d'automatic tiering, il est possible d'utiliser divers modes de compression. Une partie de ses fonctions est utilisable avec le Heat Map Oracle (zones chaudes de la base).
Autre nouvelle fonction : sous Exadata, les baies ZFS ou les équipements Pillar Data System, Data Pump permet de modifier le mode de compression sous forme de tâche automatisée, via paramétrage, lors d'un import. De plus, il est désormais possible de désactiver la journalisation lors d'un chargement Data Pump. Cela n'évite pas la sauvegarde, mais allège fortement les archive-logs.
Enfin, quelques exemples d'auto-réparation de nouvelle génération ?
Le logiciel de gestion du stockage Oracle ASM (Automatic Storage Management) sait désormais détecter les blocs corrompus et peut les reconstruire lui-même. Jusqu'à présent, une reconstruction du disque s'avérait indispensable dans ce cas.
De même, le logiciel de sauvegarde RMan (Recovery Manager) peut recharger uniquement une ou plusieurs tables jusqu'à une certaine date/heure (par exemple), et pas forcément toute la base de données.
Dans le même ordre d'idées, le moteur peut déplacer tout fichier d'une base de données d'un répertoire à l'autre, ou vers ASM, sans interrompre la production.
En 12c, un cluster Oracle peut aller jusqu'à plusieurs centaines de nouds, avec la possibilité de spécialisation (stockage, fonction de bases de données, etc.).
Enfin, la nouvelle fonctionnalité Transaction Guard prend en charge le cas où une connexion s'interrompt juste après un Commit et permet d'éviter à l'application de réappliquer cette transaction une deuxième fois.
Voir aussi
Quiz Silicon.fr - La saga Oracle