Les processus d’Oracle 10g

Les threads indispensables, optionnels et utilisateur

Le fonctionnement d’une base Oracle est assuré par un ensemble de threads imbriqués qui réalisent de nombreuses actions. Pour plus de simplicité, nous avons regroupé les threads en trois familles : les indispensables, les optionnels et les threads utilisateur. Les threads indispensables sont présents dès qu’une base Oracle fonctionne. Ils sont requis pour en assurer le fonctionnement minimal. Si l’un d’eux s’arrête, la base de données n’est plus opérationnelle.  D’autres threads peuvent être lancés pour assurer des fonctions complémentaires, comme la réplication ou la sauvegarde automatique de vos fichiers redo-log. Si l’un de ces threads optionnels n’est pas démarré, cela ne met pas en cause le fonctionnement global de la base de données. Seule la tâche assurée par ce threads optionnel ne sera pas réalisée. Les threads utilisateur sont mis en œuvre dès qu’un utilisateur ouvre une connexion avec sa base Oracle. Leur existence et leur utilité sont très souvent méconnues. Les threads indispensables Pour un fonctionnement minimal, Oracle utilise 4 threads : • DBWR (Database Writer) ; • LGWR (Log Writer) ; • CKPT (Checkpoint) ; • PMON (Process Monitor) ; • SMON (System Monitor). La figure suivante décrit les liens inter-threads de l’architecture d’une instance Oracle 10g. Ce sont ces threads qui relient les fichiers de la base de données, la zone mémoire réservée à l’instance SGA (System Global Area), ainsi que la mémoire allouée à chaque connexion utilisateur PGA (Process Global Area)Nous commenterons largement cette figure tout au long de ce chapitre. Ces threads correspondent à une instance unique. Comme présenté au chapitre 5, Oracle 10g sous Windows, on peut les visualiser à l’aide de l’Oracle Administrative Assistant for Windows ou encore depuis Oracle Enterprise Manager. Dans ce chapitre, nous traitons chaque thread séparément. La tâche est difficile puisqu’ils sont très imbriqués et les dépendances mutuelles sont nombreuses. Le threads DBWR Le threads DBWR (Database Writer ou Dirty Buffer Writer) transfert les blocs de données modifiés ou « sales » (« dirty buffers ») du buffer mémoire de la SGA dans les fichiers disque de la base de données. Dès qu’un ordre SQL de type INSERT, UPDATE, DELETE intervient, il travaille prioritairement avec les buffers de données en mémoire, pour plus de performance. Les données non modifiées sont copiées dans la zone d’annulation (ou UNDO) de la SGA et les données modifiées dans la zone des buffers de données. La zone mémoire redo-log (destinée à être traitée par le Log Writer) est elle aussi modifiée. En cas de validation de transaction (ordre COMMIT), le DBWR libère la place des enregistrements dans le Segment UNDO. S’il y a annulation de transaction (ou ROLLBACK), les enregistrements non modifiés lus dans le UNDO Segment supprimeront les enregistrements modifiés en buffer de données et les rétabliront en leur état initial.Le rôle de DBWR est de vérifier qu’il y a toujours suffisamment de buffers libres en mémoire. Comme le nombre de blocs existants en mémoire est fixe, chaque buffer modifié (ou « sale ») diminue le nombre de buffers libres disponibles. Dans ce cas, si un ordre SQL a besoin de lire des données depuis les fichiers de données pour les placer dans les buffers de données mémoire, un algorithme LRU (Least Recently Used) écrit les plus anciennes données modifiées sur le disque pour libérer de la place mémoire. Pour optimiser les entrées/sorties disque, les écritures dans les fichiers de la base de données sont différées. La sécurité des transactions est assurée par les fichiers redo-log et le threads LGWR. Le comportement de DBWR est contrôlé par le paramètre d’initialisation DB_WRITERS, qui permet de démarrer plusieurs threads DBWR, afin d’augmenter le taux d’écriture sur disque dans les systèmes très fortement sollicités. Nous vous conseillons de démarrer une base Oracle 10g avec un seul thread DBWR et d’en augmenter progressivement le nombre dans les systèmes très sollicités en entrées/sorties disque.

Les threads LGWR et CKPT

Les fichiers redo-log garantissent la préservation des données validées, même si la base est arrêtée brutalement (coupure électrique par exemple). Le thread LGWR a pour mission d’écrire toutes les informations utiles à cette sécurité dans les fichiers redo-log. Dès qu’une transaction est validée, Oracle écrit les données modifiées à deux emplacements différents, de façon à pouvoir « repartir » si un problème matériel survient. La première copie vue précédemment est assurée par le Database Writer dans les fichiers contenant les données. Cette copie n’est par forcément immédiate : pour augmenter les performances et éviter des goulots d’étranglement, un délai d’écriture peut exister. Pour conserver l’intégralité des données présentes en mémoire mais en attente d’écriture sur disque, une seconde copie immédiate est assurée par le Log Writer dans les fichiers redo-log. Dès qu’un COMMIT ou un ROLLBACK intervient, le thread LGWR (Log Writer) écrit immédiatement les données modifiées depuis la zone mémoire redo-log dans les fichiers redo-log, suivi de l’ordre de validation (COMMIT) ou d’annulation (ROLLBACK). Ainsi, toute modification validée ou annulée est immédiatement écrite sur le disque, puis la zone mémoire redo-log occupée est libérée. À intervalles réguliers, toutes les données modifiées et présentes dans la SGA sont écrites dans les fichiers de la base de données par le thread DBWR. Cet événement se nomme un checkpoint. Le thread CKPT signale les checkpoints au thread DBWR et modifie l’ensemble des fichiers qui composent la base de données, pour que le numéro d’ordre du plus récent checkpoint soit inscrit en en-tête de fichier.

 Le thread System Monitor

 Le thread SMON (System Monitor) surveille la base de données lors de son démarrage puis au cours de son fonctionnement. La principale fonction du thread SMON a lieu lors du démarrage de la base de données : il vérifie si le dernier arrêt a été correctement effectué. Si tel est le cas, il ne fait rien. Mais en cas d’arrêt brutal, il existe certainement des transactions en cours qui n’ont été ni validées, ni invalidées. SMON lit alors les informations contenues dans les UNDO segments (l’emplacement où sont conservées les données en attente de validation) puis les annule. En ce qui concerne les enregistrements validés, SMON récupère dans les fichiers redo-log ceux qui ont été modifiés (par un COMMIT ou un ROLLBACK) mais n’ont pas encore été écrits dans la base Oracle, et ce afin de les y insérer. Les autres enregistrements présents dans les fichiers redo-log, mais qui n’ont pas été validés ou annulés explicitement, sont alors annulés par SMON. Enfin, SMON libère toutes les ressources de la base de données (verrous, segments temporaires…). Lorsqu’elle est en cours de fonctionnement, SMON surveille l’activité de la base. Il recycle les segments temporaires (utilisés par exemple lors des tris de requêtes SQL) devenus inutiles. Tous les tris ne pouvant avoir lieu en mémoire, c’est SMON qui assure ce rôle important : ainsi, les nouvelles transactions ayant besoin d’espace de tri disposent d’un maximum de place.