Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Administration des Bases de données Dr. Cheikh Tidiane DIENG Université Gaston

Administration des Bases de données Dr. Cheikh Tidiane DIENG Université Gaston Berger de Saint-Louis UFR Sciences Appliquées et Technologie Section Informatique cheikh-tidiane.dieng@ugb.edu.sn Module 3: Les processus d’arriére plan • Les processus d’arrière plan (background process ou shadow process) permettent d'assurer le bon fonctionnement de l’instance. • Ils gèrent les flux entre la mémoire et les disques, et sont nécessaires au bon fonctionnement de la base de données. Les processus d’arriere plan (DBWn) (1) • DBWn( Database Writer) • Transfert les blocs de données modifiées du data buffer dans les fichiers disque de la base de données. • Le paramètre d’initialisation DB_WRITERS_PROCESSES permet de démarrer plusieurs processus DBWR, afin d ’augmenter le taux d ’écriture sur disque. Le processus LGWR est active a chaque écriture du DBWRn, Les processus d’arriere plan (DBWn) (2) • DBWn copie les blocs modifiés des tables, index, les segments d’annulation et les segments temporaires à chaque occurrence d’un des évènements suivants: • Toutes le 3 secondes DBWn copie une petite partie des blocs modifies sur disque • Dès que la longueur de la « liste CHECKPOINT » dépasse un seuil défini en interne • Chaque fois qu’un processus consulte la liste des blocs récemment utilisés (LRU list) et ne peut trouver un emplacement libre après un nombre prédétermine en recherche de blocs. Ainsi la lecture d’une table de très grande taille peut forcer l’ écriture des blocs modifies sur disque • Lors de chaque CHECKPOINT • Chaque fois que la base de données est arrêté anormalement • Chaque fois qu’une table est effacée ou tronquée • Chaque fois qu’un tablespace est mis en mode hors ligne ou lecture seule ou s’il fait partie d’une sauvegarde en ligne. Les processus d’arriere plan (DBWn) (3) Plusieurs processus DBWn (numérotés DBW1, DBW2, DBW3, DBW4, etc .) peuvent s’executer simultanément selon la plateforme et le système d’exploitation, ce qui limite les risques de contention lors d’importantes opérations portant sur plusieurs fichiers de données. Le nombre de ces processus est défini à l’aide du paramètre « DB_WRITER_PROCESSES ». Si votre système n’accepte pas les opérations d’E/S asynchrones, vous avez la possibilité de créer un seul processus DBWn avec plusieurs esclave d’E/S DBWn. Le nombre de esclave est spécifié au moyen du paramètre d’initialisation « DBWR_IO_SLAVES ». Les processus d’arriere plan (LGWR) • LGWR(Log Writer) • Écrit les données modifiées depuis la zone mémoire redo-log buffer dans les fichiers redo-log. Cela est nécessaire pour éviter une incohérence de la base de données en cas de panne d’instance. Les informations journaux des blocs modifies doivent être écrites dans le fichier journaux avant que les blocs modifies eux-mêmes ne soient écrits dans les fichiers de données. Les fichiers de journaux doivent toujours être plus récents que les fichiers de données. Le processus LGWR maintient toujours l’état le plus à jour de la base, puisque le processus DBWn peut attendre avant de consigner les blocs de données modifies dans les blocs de données. Les processus d’arriere plan (LGWR) • L’ecriture des tampon de reprise (Buffer redo log) doit etre termine physiquement avant que le controle ne soit rendu au processus serveur demandant la validation. • LGWR ecrit le tampon de journaux de reprise (Buffer redo log) dans les fichiers journaux (fichiers redo log), sous l’une quelconque des conditions: • Toutes les secondes (independamment du DBWn) • Lors de la validation d’une transaction en cours COMMIT. • Chaque fois que le tampon des journaux de reprise est rempli • Lors de chaque Checkpoint (Voir processus CKPT) • Lorsqu’il est déclenché par le processus DBWn. Les processus d’arriere plan (CKPT) (1) • CKPT(Checkpoint) • Les points de contrôle (checkpoint) créent et enregistrent des points de synchronisation dans la BD, de manière à faciliter sa récupération en cas de défaillance d’une instance ou d’un media. • Le processus CKPT exécute des points de contrôle (checkpoints), met à jour l’en-tête des fichiers de données; lui-même n’écrit pas les données modifiées sur disque, c’est le role du processus DBWn. • Signe à des intervalles réguliers, le moment d ’écriture des données modifiées dans la SGA dans les fichiers de la base de données. • Ce processus s’execute naturellement à chaque basculement des fichiers journauux (fichier redo log) ou peut etre execute manuellement par un DBA. Les processus d’arriere plan (CKPT) (2) • Le processus Checkpoint (CKPT) a un rôle important dans le bon fonctionnement d'une Instance. Checkpoint inscrit les informations de point de reprise dans les fichiers de Controles et dans l'entête de chaque fichier de données. C'est ce point de reprise (SCN) qui permet de rendre cohérent les fichiers de controles et les fichiers de données, indispensable pour un processus de récupération. • Le processus Checkpoint n'écrit pas les blocs sur le disque, c'est le role du processus Database Writer DBWn. Les processus d’arriere plan (CKPT) (3) • Les numéros SCN enregistrés dans les fichiers garantissent que toutes les modifications apportées aux blocs de base de données avant un numéro SCN ont été écrites sur le disque.En cas d'arrêt anormal de l'instance, ce SCN marque le début début des données à utiliser pour la récupération de l'instance. Le processus Log Writer (LGWR) n’écrit pas dans le fichier de journalisation (REDO LOG) tant que le processus CKPT n'a pas synchronisé, car tant que cette synchronisation n'est pas faite, le fichier de journalisation contient des données nécessaires à une éventuelle récupération après défaillance de l'instance. A savoir qu'une synchronisation se déclenche aussi à chaque basculement de REDO LOG, lors de l’arrêt de la base de données, lors de la mise hors ligne d'un Tablespace. Les processus d’arriere plan (CKPT) (3) • Le paramètre FAST_START_MTTR_TARGET peut être utilisé pour obliger la base à effectuer des points de reprise régulièrement. En effet ce paramètre indique un nombre maximum de secondes pour le redémarrage de l’instance après un arrêt anormal. • Le positionnement de ce paramètre permet à l’instance d’ajuster des points de reprises de manière à pouvoir rejouer l’activité perdue sur la base en respectant les valeurs du paramètre. Attention à ne pas avoir de points de reprises trop fréquents ce qui dégraderait les performances. Archivage • Le processus LGWR écrit dans chacun des fichiers journaux (fichiers redo-log) à tour de rôle. Lorsque le premier est plein, il écrit dans le deuxième, et ainsi de suite. Une fois le dernier fichier rempli il écrase le contenu du premier. • Lorsque la BD opère dans le mode ARCHIVELOG, elle réalise une copie de chaque fichier journal (fichier redo-log) plein; ces fichiers archivés sont généralement enregistrés sur le disque. • La fonction d’archivage c’est-à-dire la copie de chaque fichier journal plein, est assure par le processus ARCn. • Le fichier ARCn n’est pas un processus obligatoire; il est active uniquement si la base de données fonctionne dans le mode ARCHIVELOG. • Si la base de données fonctionne dans le mode NOARCHIVELOG, les fichiers journaux (fichier redo log) seront écrasés régulièrement, ce qui réduit les chances de reconstruction des fichiers de données à partir des fichiers journaux (fichier redo- log). Le processus d’arriere plan (SMON) • SMON(System Monitor) • Le processus SMON est un processus obligatoire qui s’apparente a un observateur du système. Ce moniteur système est essentiel au démarrage de l’instance d’Oracle et est impliqué dans tout rétablissement qui s’avere nécessaire. Il nettoie egalement les segments temporaires et inutilisés, efface les vieux processus, et fusionne même l‘espace libre dans le plus grands blocs contigus. • SMON surveille la base de données lors de son démarrage, puis au cours de son fonctionnement. • Le fonctionne de ce processus est automatique, aucune action de l’adminsitrateur de la base de donnees n’etant requise. C’est l’un des points forts d’oracle. Le processus d’arriere plan (PMON) • PMON (Processus Monitor) • Le processus de surveillance PMON est un processus obligatoire qui est affecté à la récupération des processus utilisateurs défaillants. Il libère le cache de blocs de données ainsi que les ressources qui étaient exploitées par l’utilisateur, telles que les verrous, afin de les mettre à disposition d’autres utilisateurs. • Nettoie les transactions défaillantes, comme celle d ’un poste client arrêter brutalement durant une transaction (zonez allouées libérées, les verrous posés sont supprimés, les ressources affectées sont annulées). • A l’instar du processus de surveillance SMON (System Monitor), le processus de surveillance PMON s’active régulièrement pour se rendre compte si on a besoin de ses services. • Le rôle de PMON est très important si vous utilisez un système comportant de nombreux utilisateurs ou encore si vous effectuez des requêtes lourdes. Chaque connexion à une base Oracle consomme quelques méga-octets de mémoire et du temps processeur. Si un utilisateur arrête brutalement sa machine ou si la connexion réseau est perdue au cours d’une longue requête SQL, un ensemble de ressources peut ainsi être bloqué inutilement si PMON ne détecte pas et ne nettoie pas les transactions anormalement interrompues. AUTRES PROCESSUS • RECO Les transactions distribuées nécessite un « COMMIT » à deux phases. Le COMMIT dans une base de données doit être coordonnée avec le COMMIT correspondant dans une la uploads/Industriel/cours02-03.pdf