Les applications client qui se connectent à une instance de base de données Amazon RDS Oracle sont refusées et génèrent les erreurs suivantes :

  • ORA-00018 maximum sessions exceeded
  • ORA-00020 maximum processes exceeded

Les tentatives de connexion à l'instance comme utilisateur principal ou comme autre utilisateur DBA avec le privilège « RESTRICTED SESSION » sont également refusées, ce qui permet difficilement de résoudre le problème sans redémarrer l'instance.

Ce problème peut survenir lors d'un exercice de dimensionnement programmé ou lors d'une « vague de connexions » non planifiée, lorsqu'un nombre de sessions client plus élevé que prévu est initié avec une instance de base de données RDS Oracle et que l'une des limites de base de données est atteinte.

  • PROCESSES : nombre maximal de processus utilisateur autorisés
  • SESSIONS : nombre maximal de sessions utilisateur autorisées

Lorsque cela se produit, vous essayez parfois de vous connecter en tant qu'utilisateur principal ou comme autre utilisateur DBA afin de prendre des mesures correctives (telles que l'annulation des connexions superflues ou l'activation de verrouillages), mais la connexion échoue parce que l'utilisateur principal rencontre les mêmes erreurs que l'application.

Pour pallier ce problème, définissez une valeur LICENSE_MAX_SESSIONS inférieure aux valeurs SESSIONS ou PROCESSES, conformément aux directives ci-dessous. La valeur LICENSE_MAX_SESSIONS s'applique uniquement aux connexions client, et non pas aux processus en arrière-plan ou aux utilisateurs associés au privilège « RESTRICTED SESSION » tels que l'utilisateur principal. En définissant un nombre inférieur à celui des valeurs SESSIONS ou PROCESSES, vous obligez les clients à recevoir ORA-00019 « Maximum number of licenses exceeded » au lieu d'ORA-18 ou ORA-20. Et comme le nombre maximal de licences (« maximum licenses ») ne s'applique pas aux utilisateurs restreints, l'utilisateur principal peut se connecter et résoudre le problème sans redémarrage.

LICENSE_MAX_SESSIONS est un paramètre « dynamique ». Autrement dit, il peut être défini sans avoir à redémarrer l'instance RDS. La façon de la spécifier dépend selon que vous utilisez des session partagées (SHARED) ou dédiées (DEDICATED).

Si vous utilisez principalement des sessions dédiées, les connexions client dépasseront probablement la valeur du paramètre PROCESSES (ORA-20). Dans ce scénario, définissez une valeur LICENSE_MAX_SESSIONS inférieure à PROCESSES, comme suit :

  • LICENSE_MAX_SESSIONS = nombre maximal de connexions client uniquement
  • PROCESSES = LICENSE_MAX_SESSIONS + tous les processus en arrière-plan, y compris les requêtes esclaves parallèles, et les utilisateurs DBA, y compris l'utilisateur principal + le facteur de flottement. Le « facteur de flottement » doit permettre de laisser suffisamment de marge pour accepter les nouveaux processus d'arrière-plan inattendus susceptibles d'être lancés ultérieurement. Pour voir le nombre de processus d'arrière-plan actuels :

SQL> select count(*) from v$session where type= 'BACKGROUND';

  • SESSIONS, qui correspond par défaut à (1.1*PROCESSES)+5, devrait faire l'affaire

Si vous avez configuré la base de données pour des serveurs partagés (SHARED), les connexions client atteindront vraisemblablement le nombre maximal de SESSIONS (ORA-18). Dans ce cas, définissez un paramètre LICENSE_MAX_SESSIONS beaucoup plus faible que la valeur SESSIONS, comme suit :

  • LICENSE_MAX_SESSIONS = nombre maximal de connexions client uniquement
  • PROCESSES = tous les processus en arrière-plan, y compris les requêtes esclaves parallèles, et les utilisateurs DBA, y compris l'utilisateur principal + le facteur de flottement. Veillez à inclure les paramètres SHARED_SERVERS et DISPATCHERS dans le nombre de processus en arrière-plan.
  • SESSIONS = (1.1*PROCESSES)+5 + LICENSE_MAX_SESSIONS

Si vous ne savez pas si vous utilisez des serveurs SHARED ou DEDICATED, vous utilisez probablement des serveurs DEDICATED, car les serveurs SHARED doivent être configurés explicitement. Toutefois, pour vous en assurer, utilisez la requête suivante :

SQL> select decode(server, 'NONE', 'SHARED',server) as SERVER, count(*)
from v$session group by decode(server, 'NONE', 'SHARED',server) ;

Vous devez comprendre pourquoi les clients atteignent le nombre maximal de connexions avant de pouvoir prendre les mesures appropriées :

  • Si le nombre maximal de connexions a été atteint suite à un exercice de dimensionnement planifié, vous devrez peut-être augmenter les valeurs SESSIONS et/ou PROCESSES afin de vous adapter à la nouvelle échelle de votre application. Ces deux paramètres ne sont pas dynamiques. Leur définition nécessite donc un redémarrage.
  • Si le nombre maximal de connexions fait suite à une vague de connexions imprévue, il convient d'en identifier la cause et de la corriger. Par exemple, il se peut que votre application bombarde la base de données de manière inappropriée lorsque les temps de réponse augmentent en raison d'un verrouillage ou d'un autre type de contention. Dans ce cas, l'augmentation des paramètres SESSIONS ou PROCESSES ne fait qu'augmenter le nombre de connexions avant d'atteindre à nouveau la valeur maximale, et exacerbe toute contention qui a lieu entre-temps.
  • Si vous utilisez des serveurs partagés (SHARED) et si vous atteignez le nombre maximal de processus (ORA-20) au lieu du nombre maximal de sessions (ORA-18), il est probable que les transmetteurs soient surchargés et qu'ils obligent les connexions à être dédiées (DEDICATED). Dans ce cas, augmentez la valeur DISPATCHERS pour permettre à plus de sessions de se connecter de manière partagée. Vous devrez peut-être également augmenter le paramètre SHARED_SERVERS. Pour plus d'informations, consultez la documentation Oracle.

Amazon RDS, LICENSE_MAX_SESSIONS, ORA-00018, ORA-00020, échec de connexion, erreur de connexion


Cette page vous a-t-elle été utile ? Oui | Non

Retour au Centre de connaissances AWS Support

Vous avez besoin d'aide ? Consultez le site du Centre AWS Support.

Date de publication : 24/06/2016