Depuis maintenant quelques temps, l’acquisition de licences standards pour le moteur de base de données Oracle se fait sous le label SE2. Cette notion étant plus contractuelle que technique, nous allons voir que l’impact technique n’est pas nul, d’autant plus si vous prévoyez de migrer de vieilles (mais encore très déployées) bases 11gR2 vers la 12c.
Licence SE2 – Quelques rappels contractuels
Il est obligatoire d’être licencié en SE2 (Dans le cas d’une licence Standard) pour exécuter un moteur dont la version est supérieure à une 12.1.0.1. Il n’est donc pas compliant (Conforme) d’utiliser des licences SE ou SE1 pour les moteurs supérieur ou égal à la 12.2.0.2. En revanche, il n’est pas interdit de licencier vos moteurs précédant en SE2.
Il n’est par ailleurs pas autorisé d’exécuter un moteur Oracle Standard licencié en SE2 sur un serveur ou un RAC de plus de deux sockets (Peu importe le nombre de cœurs). Pour un RAC en Standard, il faut comprendre un maximum de deux nœuds présentant un seul socket.
Une limitation en nombre de sockets d’accord, mais qu’en est il pour le nombre de cœurs ?
Les CPU récents présentent un nombre plus important de cœurs que dans le passé. Cette valeur est de plus souvent doublée par l’hyperthreading.
Nous venons de voir que le nombre de cœurs n’est pas limitant pour la licence SE2.
Cependant, depuis la version 12.1.0.2, le moteur standard a été « bridé » afin de n’être en capacité de n’exploiter que 16 threads simultanément (2*8 pour un RAC SE sur deux nœuds).
Cela veut dire qu’au-delà de 16 sessions travaillant en CPU, les suivantes sont placées en file d’attente par le gestionnaire de ressource jusqu’à ce qu’un thread se libère.
Détecter l’impact de cette limitation
Dans nombre de cas concrets, même dans un environnement OLTP assez sollicité, cette limite peut ne pas être souvent atteinte et l’impact peut être quasiment nul (une connexion établie à la base n’occupe pas un thread en permanence). Cela devient plus gênant quand plusieurs traitements longs occupent des threads de manière continue.
Un rapport Statspack (Pas d’AWR, nous sommes en Standard) révélera clairement l’événement d’attente pénalisant sous le nom de « resmgr:cpu quantum ».
Ci-dessous un article mettant en évidence cette limitation :
https://blog.dbi-services.com/standard-edition-2-testing-the-16-thread-limitation/
Y’a-t-il encore un intérêt à utiliser des serveurs présentant plus de 16 CPUs ou vCPUs?
Dans le cadre d’un serveur mutualisant plusieurs bases, les 16 threads utilisés par une instance ne sont pas nécessairement les mêmes que ceux utilisés par une deuxième instance.
Dans ce cadre-là, l’ensemble des instances exécutées sur un serveur sont en mesure d’exploiter plus de 16 cœurs. Mais il faut garder en tête que chacune des instances ne pourra exploiter plus de 16 threads.
Quelles solutions pour les applications à migrer vers une base Oracle 12c ?
Si vous êtes amené à migrer des bases Standard vers une 12c et que celles-ci utilisent couramment plus de 16 threads simultanés, l’une des solutions est d’envisager le passage en entreprise Edition (où cette limitation n’existe pas). Cependant, l’implication financière peut être dissuasive.
L’optimisation du code applicatif en se basant sur les requêtes les plus gourmandes en CPU (voir « SQL ordered by CPU » de votre rapport Statspack) reste l’abord le plus naturel et peut permettre moyennant quelques efforts de réduire suffisamment l’empreinte CPU. Cependant, la migration des bases se fait majoritairement indépendamment d’une re-livraison applicative et la charge liée au « re-développement » ne répond pas toujours aux contraintes de temps et/ou financières.
Il reste cependant possible dans certains cas de limiter très simplement le nombre de connexions simultanées à la base afin de réduire la concurrence CPU.
Pour les applications utilisant des connexions par pool (ce qui est très souvent le cas des applications Java), il peut être plus pénalisant de créer des pools avec un grand nombre de connexions (souvent 10 par pool par défaut). En effet, un grand nombre de connexions favorise la concurrence de celles-ci (plusieurs sessions potentiellement actives simultanément en CPU). Mais cette diminution du nombre de connexions peut aussi, si elle n’est pas maîtrisée, avoir des conséquences sur les performances de votre application. Seuls des tests avec une charge significative et différentes valeurs testées peuvent déterminer la configuration la plus efficace.
Par ailleurs, si votre architecture prévoit plusieurs serveurs applicatifs (montés « en cluster ») attaquant la même base, préférez un maximum de deux serveurs applicatifs (si vous voulez garantir une infrastructure haute disponibilité) plutôt qu’un nombre trop important, afin encore de limiter le nombre de sessions concurrentes.
Enfin, avec cette limite, il devient plus critique d’avoir un plan de production le plus rationalisé possible, afin que les traitements de type batch ainsi que les tâches de maintenance Oracle s’effectuent en dehors des heures où la base doit être le plus disponible possible pour vos applications.
