Oracle vient de sortir la version 12c de sa base de données. La version inclut plus de 500 nouvelles fonctionnalités, changements et améliorations dont vous avez certainement déjà entendu parlé dans la presse et sur le web… Mais, concrètement, pourquoi migrer en 12c ?

#1: « Pour préparer votre avenir »

Dans quelques mois les sites d’offres d’emploi et les réseaux sociaux proposeront des postes avec la mention “Expérience avérée de la Database 12c”. Ce serait dommage de ne pas pouvoir y répondre… Peut-être devriez-vous commencer à travailler sur la 12c dans votre poste actuel ?

#2: « Parce que le « support premier » de la 11gR2 se termine en Janvier 2015 »

Un projet de migration se déroule généralement de la manière suivante : on migre une première base de données de développement, quelques environnements de recette, ensuite on réalise des tests de non-régression et de performance avant d’envisager la migration des environnements de pré-production et de production. Tout cela prend du temps : des mois… voire des années en fonction de la criticité des applications, de la réactivité des équipes de recette, du renouvellement ou non du matériel etc. Raison de plus pour commencer maintenant !

#3: « Parce que vous êtes débordé »

Vous n’en pouvez plus… les équipes « études » n’arrêtent pas de vous demander de créer des bases de test pour paralléliser les développements, ce qui a un impact sur le nombre d’environnements de recette et au final sur votre quantité de travail. Avec la Database 12c ils pourront dupliquer leurs environnements en quelques lignes de SQL directement depuis SQL*Plus : pas besoin de se connecter à une machine et surtout pas besoin d’être DBA !

#4: « Parce que vous voulez affecter les ressources machine en fonction des besoins des applications »

Si vous avez 5 à 20 bases de données par machine, vous utilisez probablement Oracle Resource Manager (DBRM) au sein de chaque base de données mais pas au niveau machine. Les technologies dites « instance caging » ou l’utilisation des CGROUPS, PRM ou WLM ne vous permettent que de faire du partitionnement de ressources par instance. Ces technologies sont compliquées à mettre en oeuvre, maintenir dans la durée et vont rarement correspondre parfaitement aux besoins réels des applications qui changent régulièrement.
Avec Oracle 12c vous pouvez, avec « Resource Manager », créer des plans de ressource au niveau du Container (CDB) et des Pluggable (PDB) et contrôler les ressources suivantes :

• Nombre de sessions concurrentes
• CPU
• Utilisation des processus “parrallèles”
• I/O (Exadata uniquement)

Vous allez donc pouvoir créer un plan de ressource global pour votre machine qui correspond exactement aux besoins de vos applications dans le temps.

#5: « Parce que vous êtes surchargé de travail »

Vous travaillez sur un nouveau projet dans lequel vous devez mettre en œuvre un nouvel environnement de production, exactement comme la semaine dernière … Vous savez déjà que cela va vous prendre plusieurs jours : créer la nouvelle base de production, mettre en oeuvre et tester la procédure de sauvegarde, installer la supervision, mettre en place le plan de reprise avec Data Guard, etc.
Avec la Database 12c et l’option « Multitenant », vous pouvez réduire tout cela à quelques heures : quand vous ajouterez une PDB, cette dernière profitera automatiquement des procédures de sauvegarde déjà en place au niveau de la CDB. Elle sera automatiquement répliquée par Dataguard mis en oeuvre au niveau de la CDB, etc… De plus, quand vous devrez appliquer un patch (ex : PSU) sur vos bases de données vous le ferez au niveau CDB, réduisant ainsi la durée globale de l’opération.
Oracle utilise la formule suivante : “Manage many as one”; j’ajouterai volontiers “and do the job only once”.