12c : Oracle soigne la productivité de ses DBA

Plus de productivité pour les administrateurs et une utilisation optimisée des ressources matérielles. C’est en résumé le message qu’ont pu entendre les quelque 600 personnes qui ont bravé la pluie qui s’abattait mardi dernier sur la région parisienne afin d’assister au lancement en France d’Oracle 12c, la nouvelle version de la base de données du troisième éditeur mondial. Une version de rupture, selon Tom Kyte, architecte senior chez Oracle (en photo), qui rappelle que cette mouture, ayant nécessité 2 500 années homme de développement, masque une nouvelle architecture, « une première depuis 25 ans », note l’Américain.

Selon l’architecte, cette architecture, caractérisée par le concept des containeurs et par des instances de bases de données qu’on connecte et déconnecte sur ces containeurs à la volée, vise à aller plus loin que 11g en matière de consolidation. « Dans 11g, soit vous mutualisiez les serveurs via la virtualisation – ce qui du point de vue d’un DBA ne change rien -, soit vous partagiez les serveurs et le système – ce qui est certes un plus pour un administrateur système, mais tourne au cauchemar pour un DBA en raison des problématiques de performances que cela pose -, soit vous partagiez les machines, l’OS mais aussi la base de données – ce qui crée toute une série de problématiques en matière de sécurité et d’accès à l’information », détaille l’architecte.

12c est censé dépasser ces limitations. La conjugaison de containeurs et d’instances pluggables de la base permettant d’offrir à la fois une administration centralisée (les mises à jour s’effectuant au niveau du containeur et s’appliquant à toutes les bases connectées) et une isolation logique entre les bases, même lorsqu’elles sont hébergées par un containeur unique.

Gestion des patchs : débranchez, rebranchez

« A cela s’ajoute une utilisation optimisée des ressources, ajoute Tom Kyte. Dans la nouvelle architecture, un certain nombre de processus sont partagées au niveau du containeur (aussi appelé root database par Oracle, NDLR), plutôt que d’être dupliqués dans chaque instance. Ce qui permet une utilisation optimisée de la mémoire ». Selon lui, ce nouveau paradigme permet, à architecture matérielle constante, d’héberger une fois et demie plus d’instances de bases de données. « Et le gestionnaire de ressources est à même de gérer les priorités, en attribuant un pourcentage maximal d’utilisation de ressources à chaque instance », remarque l’architecte.

Une fonction qui doit contribuer à améliorer la productivité des DBA. Comme bien d’autres. Le concept de containeurs se révélant, selon Oracle, particulièrement intéressant en la matière. Par exemple, en permettant l’application d’une politique de sauvegarde à un ensemble d’instances connectées à un containeur.

Plus intéressant encore, le mécanisme consistant à débrancher une instance d’un containeur pour la rebrancher à la volée sur un autre, permettant ainsi une mise à jour des paramètres associés à ladite instance. « Ce qui facilite grandement la mise à jour des SLA d’une application chez un hébergeur », note Tom Kyte.

Pour Vincent Berny, responsable de la practice Cloud chez GFI, « l’usage de cette fonction de connexion à chaud présente un intérêt évident pour un hébergeur comme nous. Les upgrades de SLA nécessitent aujourd’hui un gros travail de migration et de provisionning des environnements de la part de nos équipes. »

PRA distants, mais en mode synchrone

Comme l’explique Laurent Leturgez, de l’intégrateur Digora, le mécanisme d’instances à brancher sur un containeur s’avère également très efficace dans le cadre d’une production  informatique chez un grand compte : « chez un de nos clients utilisateur de Siebel, un cycle de développement aboutit à la création de 23 instances Oracle. Connecter ces 23 instances à un containeur unique permet de définir une seule fois la politique de sauvegarde ou  d’appliquer les patchs en une seule passe. »

Comme le souligne Ludovic Sorriaux, consultant chez Oracle, ce mécanisme de connexion/déconnexion aux containers s’avère  également très pratique pour le cas d’applications migrant à des vitesses différentes, ou pour gérer différents niveaux de sécurité.

Trois autres fonctions au moins devraient également retenir l’attention des DBA. La première permet de gérer la température des données automatiquement, en fonction de règles prédéfinies. « Une fois celles-ci établies, le DBA n’a plus rien à faire », martèle Tom Kyte. De son côté, le duo Transaction Guard et Application Continuity permet d’obtenir des certitudes sur l’aboutissement d’une transaction.

Enfin, 12c s’accompagne d’une fonction dite Far Sync permettant de mettre en place des PRA (Plans de reprise d’activité) distants, sans risque de pertes de données. En effet, du fait des temps de latence réseaux, ces PRA fonctionnent aujourd’hui souvent en mode asynchrone. En créant une instance légère renfermant les journaux de transactions à proximité du site primaire afin d’alimenter le site secondaire (le principe de Far Sync), Oracle affirme dépasser cette limite. L’éditeur offre cette fonction sans licence supplémentaire dans le cadre de 12c.

Voir aussi

Quiz Silicon.fr – La saga Oracle