Eléments de contexte

ORACLE a lancé le 1er Septembre 2015 une nouvelle édition de son SGBD Standard  « ORACLE Database Standard Edition 2 » ou SE2. L’annonce faite par l’éditeur à la sortie du produit était une SE2 vendue au même prix que la Oracle Standard Edition ou SE (en tout cas sur la price list en date de sortie).

Cependant l’édition s’accompagne de plusieurs limitations:

• Les serveurs la recevant ne doivent pas avoir plus de 2 sockets (à mi-chemin donc entre les limitations des éditions Standard et Standard One)
• L’option RAC est incluse mais les clusters ne doivent pas avoir plus de 2 sockets au total
• Chaque base de données ou instance n’utilisera pas plus de 16 threads concurrents
• Pour les UN+ le minimum est relevé à 10 UN+ par serveur (en lieu et place des 10 UN+ nécessaires à l’édition Standard)

En pratique ces limitations impliquent des contraintes d’architecture telles qu’un cluster limité à 2 sockets. Vous avez la possibilité d’utiliser RAC et ainsi de créer des clusters SE2. Les combinaisons acceptées par ORACLE pour le cluster sont:

1. Un serveur désigné explicitement comme à un socket avec un processeur installé

2. Un serveur désigné à deux sockets avec un processeur installé et l’autre socket vide

3. Un serveur désigné explicitement à deux sockets avec deux processeurs installés mais utilisant des technologies reconnues de « Hard Partitioning » qui lie une VM avec un CPU/Socket.

Une autre contrainte que l’on peut souligner est un maximum de 16 CPU Threads par instance, ce qui constitue une limite cette fois technologique et non contractuelle. En pratique par exemple:

• J’ai un serveur 2 sockets pouvant délivrer 48 threads : ce serveur reposant sur une plateforme INTEL à 12 cœurs par socket.
• Sur ce serveur il y a deux applications A et B nécessitant 18 threads pour A et 12 threads pour B.
• En SE2, de façon instantanée le serveur pour délivrer 16 threads pour A et 12 threads pour B

Il faut ainsi bien voir la limitation à 16 threads comme une limitation pour chaque instance.

Basé sur notre expérience l’impact de cette limitation est à analyser de façon très spécifique pour des instances devant recevoir 800 utilisateurs concurrents ou plus et pour des processeurs de dernières générations.

Dans le cas d’une configuration en cluster, la limitation par instance est portée à 8 threads par serveur. Sachant que les deux serveurs peuvent fournir à tout moment la puissance de 16 threads à l’instance.

Fin de vie des produits SE et SE1

Ces deux éditions du produit ont été retirées de la liste de prix le 1Er Décembre 2015. Concernant le support, la documentation ORACLE nous indique que:

• Les éditions SE et SE1 s’achèvent à la version 12.1.0.1 (pas de version ultérieure développée)
• L’édition SE2 débute à la version 12.1.0.2
• Le support étendu (extended support) des deux éditions SE et SE1 (dans leur version 11.2.0.4 et 12.1.0.1 donc) s’achève au 1er septembre 2016

Dois-je migrer mes licences SE et SE1 vers la SE2 ?

Le premier point à considérer est que cette migration n’est pas obligatoire. La migration vers la SE2 se trouvant être nécessaire des lors que vous souhaitez migrer vers la release 12.1.0.2. du SGBD.

La migration des licences sous support et dans le cadre du respect des limitations hardwares donne les chemins de migration suivants :

• De SE vers SE2 : aucun coût
• De SE1 vers SE2 : coût de la migration égal à 20% du coût de support actuel

On comprend ainsi l’intérêt « business » pour l’éditeur de fusionner les deux éditions précédentes. On peut imaginer que  les parts de marché de la SE1 ont été jugées (trop ?) bon marché au regard des services rendus (vu de Redwood Shores) et ont pesées dans l’élaboration de la politique licence de la SE2.