Comment résoudre les erreurs ORA-00018 ou ORA-00020 sur une instance de base de données Amazon RDS for Oracle ?

Brève description

Ces erreurs peuvent être provoquées par un exercice de mise à l'échelle planifié ou par un événement non planifié qui entraîne un nombre important de connexions à la base de données. Dans ces situations, de nombreuses sessions clientes sont lancées sur une instance de base de données et l'une des limites suivantes est atteinte :

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

Si le nombre maximum de connexions est atteint en raison d'un exercice de mise à l'échelle planifié, augmentez les valeurs des paramètres SESSIONS et/ou PROCESSES. Cela permet une adaptation à la nouvelle échelle de votre application. Ces deux paramètres n'étant pas dynamiques, vous devez modifier les paramètres et redémarrer l'instance.

Si le nombre maximal de connexions est atteint suite à un événement non planifié, identifiez la cause de celui-ci afin de prendre les mesures appropriées.

Par exemple, il se peut que votre application surcharge la base de données lorsque les temps de réponse augmentent en raison de conflits de verrouillage ou de blocs. Dans ce cas, l'augmentation des valeurs des paramètres SESSIONS ou PROCESSES ne fait qu'augmenter le nombre de connexions autorisées, mais n'empêche pas que la limite soit à nouveau atteinte. Cela peut aggraver les problèmes causés par les conflits. Le système de surveillance Amazon RDS peut alors se trouver dans l'impossibilité de se connecter, d'effectuer des surveillances de l'état ou de prendre des mesures correctives (telles que le redémarrage).

Solution

Profil d'utilisateur Oracle (PROFILE)

L'une des causes les plus fréquentes des ORA-18 et ORA-20 est le grand nombre de connexions inactives. Les connexions inactives restent dans une base de données sans être correctement fermées par l'application ou les administrateurs de base de données. L'augmentation du nombre de connexions inactives (IDLE) peut amener la base de données à atteindre la limite maximale du paramètre SESSIONS/PROCESSES. Par conséquent, aucune nouvelle connexion n'est autorisée. Il est recommandé de définir un profil (PROFILE) pour les connexions aux applications avec une valeur de délai d'inactivité IDLE_TIME limitée.

Dans les bases de données Oracle, un PROFILE est attribué à chaque utilisateur. Un PROFILE Oracle est un ensemble de ressources attribué à chaque utilisateur associé à celui-ci. L'une de ces ressources est IDLE_TIME. IDLE_TIME indique en minutes le délai d'inactivité continue autorisé pendant une session avant que la requête ne soit supprimée par la base de données. Les requêtes de longue durée et les autres opérations ne sont pas soumises à cette limite.

Cet exemple illustre la façon de créer un profil avec un délai IDLE_TIME maximal de 30 minutes et de l'attribuer à un utilisateur de l'application. Toute connexion inactive (IDLE) pendant plus de 30 minutes est automatiquement supprimée par la base de données :

Créez un PROFILE avec un paramètre IDLE_TIME limité :

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

Attribuez ce PROFILE à un utilisateur spécifique :

  SQL> ALTER USER <username> PROFILE <profile_name>;

Mise à l'échelle de la taille de l'instance RDS

Le valeur maximum des paramètres SESSIONS ou PROCESSES peut être atteinte en raison d'une augmentation de la charge de travail entrante des utilisateurs de l'application. Par défaut, dans RDS for Oracle, les deux limites de paramètres sont calculées selon une formule prédéfinie qui dépend de la mémoire de classe d'instance de base de données. Dans ce cas, il n'est pas recommandé de modifier manuellement les paramètres SESSIONS et PROCESSES. Augmentez ou diminuez plutôt l'instance en fonction de la charge de travail.

Les paramètres RDS par défaut pour les paramètres PROCESSES ou SESSIONS sont calculés à l'aide des formules suivantes :

• PROCESSES= LEAST({DBInstanceClassMemory/9868951}, 20000)
• SESSIONS = la valeur Oracle par défaut = (1.5 * PROCESSES) + 22

La configuration manuelle des paramètres PROCESSES ou SESSIONS au-delà de leur limite par défaut peut entraîner une augmentation de la consommation de mémoire. Par conséquent, la base de données peut se bloquer en raison de problèmes de mémoire insuffisante. De plus, la configuration manuelle des paramètres PROCESSES ou SESSIONS peut provoquer une inadéquation de configuration lors de l'augmentation ou la réduction de la taille de l'instance. Cela se produit parce que les paramètres PROCESSES et SESSIONS ne dépendent plus de la mémoire d'instance allouée.

LICENSE_MAX_SESSIONS

Le paramètre LICENSE_MAX_SESSIONS permet de spécifier le nombre maximal de sessions utilisateur simultanées autorisées. Il ne s'applique pas aux processus en arrière-plan d'Oracle ni aux utilisateurs disposant de privilèges de session restreinte RESTRICTED SESSION (y compris les utilisateurs ayant le rôle DBA). Définissez le paramètre LICENSE_MAX_SESSIONS sur une valeur inférieure à celles des paramètres SESSIONS et PROCESSES. Les connexions client reçoivent alors une erreur ORA-00019 au lieu d'une erreur ORA-18 ou ORA-20. Une erreur ORA-00019 ne s'applique pas aux utilisateurs disposant de privilèges RESTRICTED SESSION. Ainsi, les utilisateurs principaux et RDSADMIN peuvent se connecter à l'instance de base de données et effectuer des dépannages administratifs ainsi que des actions correctives. De plus, les fonctionnalités de surveillance Amazon RDS peuvent continuer à se connecter à la base de données en utilisant RDSADMIN afin d'effectuer des surveillances de l'état.

Remarque : le paramètre LICENSE_MAX_SESSIONS était initialement destiné à limiter l'utilisation en fonction du nombre de sessions simultanées. Oracle ne propose plus de licences basées sur le nombre de sessions simultanées et le paramètre LICENSE_MAX_SESSIONS est désormais obsolète. Cependant, vous pouvez toujours l'utiliser si vous disposez de la version 19c d'Oracle (ou d'une version antérieure). Par ailleurs, le rôle DBA ou des privilèges RESTRICTED SESSION ne doivent pas être attribués aux utilisateurs de l'application. Pour plus d'informations, veuillez consulter la documentation Oracle relative au paramètre LICENSE_MAX_SESSIONS (français non garanti).

LICENSE_MAX_SESSIONS est un paramètre dynamique. Il peut donc être défini sans avoir à redémarrer l'instance de base de données. Pour plus d'informations, veuillez consulter la section Utilisation des groupes de paramètres.

Le paramètre LICENSE_MAX_SESSIONS peut être défini sous forme de formule, de la même manière que le paramètre PROCESSES. Il est recommandé de définir le paramètre LICENSE_MAX_SESSIONS de manière à ce qu'il soit basé sur une formule plutôt que sur une valeur statique. Cela permet d'éviter les erreurs de configuration lors de l'augmentation ou la réduction de la taille de l'instance. Par exemple :

• Pour le définir de la même manière que le paramètre PROCESSES : LICENSE_MAX_SESSIONS= LEAST({DBInstanceClassMemory/9868951}, 20000)
• Pour le définir à 4/5 du paramètre PROCESSES : LICENSE_MAX_SESSIONS= LEAST({DBInstanceClassMemory/12336188}, 20000)

Utilisation de sessions DEDICATED

Avec les sessions dédiées (DEDICATED), vos connexions client sont susceptibles de dépasser la limite du paramètre PROCESSES (ORA-20). Si vos connexions client dépassent cette limite, définissez la valeur du paramètre LICENSE_MAX_SESSIONS de façon à ce qu'elle soit inférieure à celle du paramètre PROCESSES :

• LICENSE_MAX_SESSIONS = nombre maximal de connexions client uniquement.
• PROCESSES = LICENSE_MAX_SESSIONS + l'ensemble des processus en arrière-plan y compris les requêtes parallèles, les utilisateurs DBA (dont les utilisateurs principaux) et une mémoire tampon. Une mémoire tampon permet d'effectuer des processus en arrière-plan imprévus pouvant se produire ultérieurement. Afin de connaître le nombre de processus s'exécutant actuellement en arrière-plan, exécutez une requête similaire à la suivante :

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

Remarque : le paramètre SESSIONS, dont la valeur par défaut est (1.5 * PROCESSES) + 22, devrait être suffisant. Pour plus d'informations, veuillez consulter la documentation Oracle relative au paramètre SESSIONS (français non garanti).

Afin de vous connecter manuellement à votre instance et vérifier le paramètre SESSIONS, exécutez une commande similaire à la suivante :

SQL> select name, value from v$parameter where upper(name) in ('SESSIONS','PROCESSES','LICENSE_MAX_SESSIONS');
NAME   VALUE
------------------------------ ------------------------------
processes   84
sessions   148
license_max_sessions   0

Utilisation de sessions SHARED

Avec les sessions partagées (SHARED), vos connexions client sont susceptibles de dépasser la limite du paramètre SESSIONS (ORA-0018). Si les connexions client dépassent la limite, utilisez une valeur supérieure pour le paramètre PROCESSES.

• LICENSE_MAX_SESSIONS = nombre maximal de connexions client uniquement.
• PROCESSES = l'ensemble des processus en arrière-plan y compris les requêtes parallèles, les utilisateurs DBA (dont les utilisateurs principaux) et une mémoire tampon. Veillez à inclure les paramètres SHARED_SERVERS et DISPATCHERS dans le nombre de processus en arrière-plan.
• SESSIONS = (1.5 * PROCESSES) + 22

Si vous utilisez des serveurs partagés (SHARED) et que vous recevez une erreur relative au nombre maximal de processus (ORA-20) au lieu d'une erreur relative au nombre maximal de sessions (ORA-18), il est possible que vos répartiteurs soient surchargés. Lorsque les répartiteurs sont surchargés, les connexions sont obligées d'entrer en mode DEDICATED. Augmentez la valeur du paramètre DISPATCHERS afin de permettre à davantage de sessions de se connecter de manière partagée. Vous devrez peut-être également augmenter le paramètre SHARED_SERVERS.

Afin de vérifier si vous utilisez des serveurs SHARED ou DEDICATED, exécutez une commande telle que celle-ci :

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

---

Informations connexes

Bonnes pratiques applicables à l'utilisation du système Oracle