News: Après la 12, la 18.

Détails: Catégorie : News; Publié le mercredi 13 décembre 2017 22:05; Écrit par Administrator; Affichages : 57759

En janvier 2018 va sortir la version d’Oracle 18.1.0. Non ce n’est pas une erreur, ni un poisson de décembre. Cette version sera la suite de la version 12.2.0.1, et elle correspondra à la version 12.2.0.2. Il n’y aura donc jamais de version 13 ce qui aurait certainement porté malheur à Oracle. Plus sérieusement, Oracle change sa nomenclature des versions de base de données ainsi que le mode/rythme des mises à jour.

Oracle prévoit de sortir une release tous les ans, et cette release portera le nom de l’année de sortie d’où le 18 à la place de la 12.2.0.2 qui est prévu pour janvier 2018. Ensuite pour cette release, tous les trimestres sortira un RU (Release Update), qui est un peu l’équivalent du Proactive Bundle Patch, qui s’appliquera à une Release. Et chaque trimestre sortira un RUR (Release Update Revisions), l’équivalent d’un PSU (Patch Set Update), qui s’appliquera à un couple Release.RU. La frise chronologique ci-dessous permet mieux appréhender l’enchainement des sorties des Release, RU et RUR:

Extrait de la note Oracle: Release Update Introduction and FAQ (Doc ID 2285040.1)

Dans la vie réelle d’un DBA cela pourrait donner quelque chose comme cela :

- Le 1^er janvier 2018, j’installe un nouveau moteur Oracle, le 18.1.0 (18 la release, 1 le 1^er RU de cette release, 0 pas RUR de disponible).

- En Avril 2018, je ne me découvre pas d’un fil.

- Ensuite en Juillet 2018 je passe le 3^ème RU qui vient de sortir (pour rappel: équivalent à un proactive bundle patch), le moteur se trouve alors en 18.3.0. Forcement 0 à la fin, car le 3ème RU vient de sortir, il n’y a donc pas de RUR (équivalent PSU) pour lui.

- En Octobre 2018, je décide de passer le dernier RUR, c’est donc le premier RUR qui sort pour mon couple Release.RU, donc je me retrouve avec une version 18.3.1.

- En janvier 2019, je vais au ski. La nouvelle release 19(.1.0) vient de sortir.

- En avril 2019, il faut passer urgemment le dernier RUR qui corrige une faille de sécurités avec un score CVSS de 10 ! Et il n’y a pas le temps de tester le dernier RU, encore moins la nouvelle release 19 qui vient de sortir, il faut donc passer le dernier RUR pour ma version 18.3.1, et c’est le 18.3.3.

Il est à noter que pour les versions 11.2 et 12.1 et 12.2.0.1, rien ne change pour le versioning, il y aura toujours de Proactive Bundle Patch et des PSU. Cette nouveauté ne s’applique qu’à partir de la 12.2.0.2 qui ne sortira jamais avec ce nom là, mais avec le numéro de version 18.1.0.

Avec ce changement de numérotation, il est plus compliqué de savoir facilement si on peut passer d’une version Release.RU.RUR à une autre, c’est-à-dire si tel version est plus récente que telle version. En effet, avant c’était facile, il suffisait d’enlever tous les points entre les digits pour les deux versions à comparer et celle qui obtenait le numéro le plus élevé était la plus récente, et l’upgrade d’une version à une autre avait un sens.

Exemple :
Source 12.1.0.2.5, cible 12.1.0.2.170117 --> 121025 < 12102170117 : la cible est plus récente, c’est un upgrade.
Source 12.1.0.2.170718, cible 12.1.0.1.170418 --> 12102170718 > 12101170418 : la cible est moins récente, ce n’est pas un upgrade. L'exécution du PSU en l'occurrence ici, échouera.

Cela change avec la nouvelle nomenclature. Si je vois que ma base est en version 18.2.2, je me dis naturellement que je pourrais l’upgrader en 18.3.0… et bien je me trompe. En regardant la roadmap ci-dessus (extrait Doc ID 2285040.1), la version 18.3.0 est sortie en Juillet 2018, alors que la version 18.2.2 est sortie elle en Octobre 2018. Pour éviter d’avoir sous la main la liste chronologique des Release/RU/RUR, il y a une règle simple pour savoir si c’est un upgrade possible pour une même release: il faut faire la somme du 2^ème et 3^ème digit pour la version cible et le résultat doit être supérieur ou égale à la somme du 2^ème et 3^ème digit de la version source

Exemple :
Source 18.2.2, cible 18.3.0 --> 4 (2+2) > 3 (3+0) : Erreur on ne peut pas upgrader
Source 18.2.2, cible 18.4.1 --> 4 (2+2) < 5 (4+1) : OK c’est un upgrade possible

Quelques interrogations en guise de conclusion :

Quelle sera le nom long de la version dans la base: 18.1.0 ou bien 18.1.0.0.0. ? A priori la réponse est sans importance mais si jamais vous avez des scripts d’administration qui font des checks de version du genre "if [ $version -ge 12102 ] then execute new feature from 12.1.0.2", alors la question peut prendre un peu plus d’importance…

Il n’y aura plus la petite lettre marketing qui existe de depuis la 8.1. Le i de la 8i et 9i pour internet, le g de la 10g et 11g pour grid computing et le c de la 12c pour cloud ?

Les certifications pour une version seront up-to-date qu’un an ? une certification Oracle 18 est dépassée en 2019 ? Il faut en repasser une ?