Nmedia - Fotolia

Conseil

Oracle Database : ce que le nouveau cycle de versions apporte aux DBA

Avec le nouveau de cycle de release sur un rythme annuel, les utilisateurs de la base de données Oracle auront accès aux nouvelles fonctions plus rapidement. Quelles sont les implications ?

Brian Peasland
par
Publié le: 22 août 2017

Oracle a entrepris de modifier le cycle de release et son schéma de numérotation des versions de sa très populaire base de données. Et cela constitue bien plus qu’un simple changement de versions pour les utilisateurs des outils de la marque.

A partir de l’année prochaine, Oracle présentera une version de sa base sur un rythme annuel, avec comme numérotation de version les deux derniers chiffres de l’année de sa sortie. Ainsi, la prochaine version d’Oracle Database sera Oracle Database 18 et non pas 12.2.0.2 comme la marque avait habitué ses utilisateurs. Ce qui aurait dû être la 12.2.0.3 en 2019 sera nommée Oracle Database 19 – et ainsi de suite.

Pourtant, il ne faut y voir qu’un simple changement de nomenclature. Le principal avantage pour les utilisateurs est qu’ils sont sûrs de  bénéficier de nouvelles fonctions une fois par an, au lieu d’avoir à attendre deux, trois ou quatre ans avant la sortie d’une version majeure, comme ce fut parfois le cas dans le passé.

Même si Oracle a déjà doté sa base de nouvelles fonctions entre deux versions majeures. C’est p           ar exemple le cas avec Oracle8i Database, qui était en fait une vraie 8.1. Cette version a apporté l’indexation de fonctions d’une colonne ; Oracle Database 11g Release 2 la technologie Oracle Grid Infrastructure.

Pas d’attente de nouvelles fonctions

Avec cette logique, les utilisateurs n’ont pas à attendre la seconde déclinaison d’une version pour disposer de nouvelles fonctions. Par exemple, la version 12.1.0.2 d’Oracle Database 12c – officiellement annoncée comme un ensemble de patches – embarquait l’option Oracle Database In-Memory.

En réalité, Oracle s’est écarté de cette logique il y a des années. Auparavant, nous disposions d’Oracle 9.2.0.3, et nous appliquions la mise à jour 9.2.0.5 au-dessus pour combler les failles connues de l’application. Mais depuis la mise à jour 11.2.0.2, cela ressemblent davantage à des versions complètes. Les administrateurs (DBA) y font probablement référence comme une mise à jour, mais l’ambition d’Oracle s’est affinée depuis 2012. 

Pour tout cela,  Oracle n’avait pas de bonnes raisons de maintenir l’ancienne numérotation de ses versions. Cette modification est davantage en ligne avec ce qui a cours depuis quelque temps. Oracle 12.1.0.1 et 12.1.0.2 étaient des releases différentes, tout comme 12.2.0.1 et la future Oracle Database 18.

Eliminer les problèmes de mises à jour

Aucun DBA ne déploierait la première déclinaison d’une version majeure en production. La logique était plutôt d’attendre la première mise à jour pour faire monter en gamme les bases de données ou en créer de nouvelles. S’ils sont encore nombreux à penser de la sorte, cela n’est plus vrai depuis longtemps.

Pour les non-initiés, - primo - chaque release d’Oracle Database contient des bugs. Même après une mise à jour, il reste des bugs, d’où la publication d’autres mises à jour. La frontière entre versions majeures et mises à jour étaient – donc - plutôt floues. Secondo, Oracle Database est une application mature utilisée dans des environnements critiques dans le monde entier. Oracle n’a donc pas intérêt à lancer  une version qui ne soit pas stable et ne fonctionne pas chez la grande majorité de ses clients.

Avec cette modification des cycles de releases et de changement de numérotation – ils sont détaillés dans My Oracle Support Note 74060.1 – les DBA vont prendre conscience que chaque version d’Oracle Database est une nouvelle version, avec de nouvelles fonctions. Pour les patches et rustines, toutefois, les DBA pourront appliquer les mises à jour trimestrielles d’Oracle (Critical Patch Update) à leur sortie.

 

Pour approfondir sur Base de données