Bases de données

Solaris Resource Manager permet de gérer les ressources de base de données dans certains cas, selon le type de base de données et la façon dont elle est utilisée.

Topologies de base de données

Les bases de données peuvent s'exécuter selon deux modes : 2n ou serveur à plusieurs unités d'exécution (MTS). En mode 2n, chaque utilisateur de la base de données dispose d'un processus distinct. En mode à plusieurs unités d'exécution, un seul processus est disponible pour de nombreux utilisateurs. Il est impossible d'utiliser Solaris Resource Manager pour gérer une base de données exécutée comme processus unique à unités d'exécution multiples, telle que Oracle MTS.

On ne peut contrôler une base de données qui est en mode MTS, à l'aide de Solaris Resource Manager, qu'au niveau de base de données, car tous les utilisateurs consomment l'UC en vertu de la même UID, dans ce cas "oracle". Solaris Resource Manager permet de regrouper les bases de données, mais il n'offre pas un contrôle précis des utilisateurs de la base de données.

Certaines bases de données, comme Oracle 8i, offrent certaines fonctions de contrôle des ressources, notamment la possibilité d'imposer des restrictions quant à l'attribution de l'UC aux interrogations ou aux utilisateurs. Dans ce cas, les politiques de gestion des ressources et l'administration sont séparées de Solaris Resource Manager et doivent être assurées à l'aide d'un ensemble d'outils différent.

Les ressources d'une base de données tournant en mode 2n sont bien plus faciles à contrôler. En effet, plutôt que d'exécuter toutes les opérations de base de données sous une seule identité, les utilisateurs se servent chacun d'une UID différente.

Le mode 2n est en général compatible avec Solaris Resource Manager, car il se sert d'un processus distinct pour chaque utilisateur ; de plus, un noeud limite unique dans la hiérarchie est attribué à chaque utilisateur.

Oracle en mode 2n avec Solaris Resource Manager

Oracle présente un bon exemple de gestion des ressources d'une base de données 2n. Oracle en mode 2n lance un processus distinct, soit le "processus Oracle en double," pour chaque utilisateur qui se relie à la base de données. Ce processus en double se relie à la mémoire partagée centrale et exécute les opérations d'E/S directement avec les fichiers de la base de données. Même si les processus en double Oracle sont des programmes setuid Oracle, ils ne correspondent pas à un noeud limite Solaris Resource Manager différent. En effet, le noeud limite est précisé au moment de l'établissement de la connexion par l'appel système setuid() et il n'est pas transféré au lancement du programme setuid(), sauf si le programme cible appelle setuid().

Le schéma ci-après présente l'utilisation de Solaris Resource Manager par Oracle en mode 2n.

Oracle en mode 2n client-serveur

En mode client-serveur, un processus supplémentaire, le récepteur d'événements réseau Oracle, prend part à l'établissement de la connexion et il peut provoquer la perte de l'information contextuelle de l'utilisateur. Le récepteur d'événements réseau accepte une connexion de l'ordinateur client et il lance le processus en double Oracle pour cet utilisateur.

Des modifications peuvent s'avérer nécessaires pour que le récepteur d'événements Oracle fasse correspondre le processus en double au bon noeud limite.

Mémoire virtuelle et bases de données

Solaris Resource Manager permet en outre de limiter la quantité de mémoire virtuelle utilisée par les utilisateurs et les travaux. Il ne s'agit pas d'une gestion de la mémoire physique, mais plutôt d'une restriction imposée quant à l'ampleur de la zone de swap globale employée par chaque utilisateur.

Lorsqu'un utilisateur ou un travail atteint la limite de mémoire virtuelle définie pour leur noeud limite, le système envoie une erreur d'attribution de mémoire à l'application. Ainsi, les appels à malloc() échouent. Ce code d'erreur indique à l'application que sa zone de swap est épuisée.

Peu d'applications réagissent correctement aux erreurs d'attribution de mémoire. Ainsi, on doit faire en sorte qu'un serveur de base de données n'atteigne jamais sa limite de mémoire virtuelle. Si cette limite est atteinte, le moteur de la base de données risque de tomber en panne, ce qui pourrait entraîner une altération de la base de données.

On doit définir des limites de mémoire virtuelle élevées afin qu'elles ne soient pas atteintes dans des circonstances normales. De plus, la limite de mémoire virtuelle peut servir à imposer un plafond pour le serveur de base de données. Ainsi, une base de données en panne qui ne dispose pas d'une mémoire suffisante n'aura pas des répercussions négatives sur les autres bases de données et sur les travaux du système.