Explication graphique détaillée de l'architecture de la base de données Oracle

Cet article vous apporte des connaissances pertinentes sur Oracle, qui présente principalement des problèmes liés à l'architecture de la base de données Oracle. Le serveur se compose d'une base de données Oracle et d'une ou plusieurs instances de base de données. L'instance se compose d'une structure de mémoire et d'une composition de processus backend. j'espère que cela sera utile à tout le monde.

Tutoriel recommandé : "Tutoriel Oracle"

Vue d'ensemble

Le serveur Oracle DB se compose d'une base de données Oracle et d'une ou plusieurs instances de base de données. Les instances sont constituées de structures de mémoire et de processus en arrière-plan. Chaque fois qu'une instance est lancée, une zone de mémoire partagée appelée System Global Area (SGA) est allouée et les processus en arrière-plan sont démarrés.
La base de données comprend la structure physique et la structure logique. Les structures physiques et logiques étant distinctes, l'accès à la structure de stockage logique n'est pas affecté lors de la gestion du stockage physique des données.

Les instances Oracle utilisent des structures et des processus de mémoire pour gérer et accéder aux bases de données. Toutes les structures de mémoire existent dans la mémoire principale des ordinateurs qui composent le serveur de base de données. Les processus sont des tâches qui s'exécutent dans la mémoire de ces ordinateurs. Un processus est défini comme un « fil de contrôle » ou un mécanisme dans un système d'exploitation qui exécute une séquence d'étapes.

Structure de mémoire

Les instances Oracle ont deux structures de mémoire de base associées :
1. System Global Area (SGA)
Un groupe de structures de mémoire partagée appelées composants SGA. Ces composants contiennent les données et le contrôle des informations d'une instance de base de données Oracle. . Le SGA est partagé par tous les serveurs et processus en arrière-plan. Des exemples de données stockées dans le SGA incluent des blocs de données mis en cache et des zones SQL partagées.
SGA est la zone mémoire qui contient les données et les informations de contrôle de l'instance. Le SGA contient les structures de données suivantes :
• Cache tampon de base de données : utilisé pour mettre en cache les blocs de données récupérés de la base de données
• Tampon de rétablissement : utilisé pour mettre en cache les informations de rétablissement utilisées pour la récupération d'instance jusqu'à ce qu'elles puissent être écrites. Fichiers de rétablissement physiques stockés sur le disque.
• Pool partagé : utilisé pour mettre en cache diverses structures pouvant être partagées entre les utilisateurs
• Grand pool : utilisé pour certains processus volumineux (tels que les opérations de sauvegarde et de récupération Oracle) et les serveurs d'E/S. Les processus fournissent des régions facultatives d'allocations de mémoire importantes.
• Java Pool : utilisé pour tous les codes et données Java spécifiques à la session dans la machine virtuelle Java (JVM)
• Stream Pool : utilisé par Oracle Streams pour stocker les informations requises pour les opérations de capture et d'application

2. )
Une zone mémoire contenant des données et des informations de contrôle pour un processus serveur ou un processus en arrière-plan.
PGA est une mémoire non partagée créée par Oracle DB lorsque le processus serveur ou le processus en arrière-plan démarre. L'accès des processus serveur au PGA s'exclut mutuellement. Chaque processus serveur et processus en arrière-plan possède son propre PGA.
La Program Global Area (PGA) est une zone mémoire qui contient des données et des informations de contrôle pour chaque processus du serveur. Le serveur Oracle traite les demandes des clients de service. Chaque processus serveur possède son propre PGA dédié, qui est créé au démarrage du processus serveur. L'accès au PGA est limité à ce processus serveur et ne peut être lu et écrit que par le code Oracle au nom de ce processus serveur.

Oracle DB utilise des paramètres d'initialisation pour créer et gérer des structures de mémoire. Le moyen le plus simple de gérer la mémoire consiste à permettre à la base de données de gérer et d'optimiser automatiquement la mémoire. Pour ce faire (ce qui suit fonctionne sur la plupart des plates-formes), définissez simplement le paramètre d'initialisation de la taille de mémoire cible (MEMORY_TARGET) et le paramètre d'initialisation de la taille de mémoire maximale (MEMORY_MAX_TARGET).

Cache de tampon de base de données

Le cache de tampon de base de données fait partie du SGA et est utilisé pour stocker des copies de blocs de données lus à partir de fichiers de données. Tous les utilisateurs connectés à l'instance en parallèle partagent l'accès au cache tampon de la base de données.
La première fois qu'un processus utilisateur Oracle DB nécessite une donnée spécifique, il recherche les données dans le cache tampon de la base de données.
Si le processus trouve les données dans le cache (appelé accès au cache), les données sont lues directement depuis la mémoire. Si un processus ne parvient pas à trouver des données dans le cache (appelé échec du cache), le bloc de données du fichier de données sur le disque doit être copié dans un tampon du cache avant de pouvoir accéder aux données. L’accès aux données en cas d’accès au cache est plus rapide que l’accès aux données en cas d’échec du cache.
Les tampons du cache sont gérés par un algorithme complexe qui utilise une combinaison de listes de moins récemment utilisées (LRU) et de mécanismes de comptage de quais.

Redo Log Buffer

Le tampon redo log est un tampon circulaire dans SGA qui contient des informations sur les modifications apportées à la base de données. Ces informations sont stockées dans des entrées de rétablissement. Les entrées de rétablissement contiennent les informations nécessaires pour reconstruire (ou rétablir) les modifications apportées à la base de données par DML, DDL ou des opérations internes. Si nécessaire, les entrées rétablies seront utilisées pour la récupération de la base de données.
Lorsque le processus du serveur modifie le cache du tampon, le système génère des entrées de rétablissement et écrit les entrées de rétablissement générées dans le tampon de journalisation du SGA. Les entrées de rétablissement occupent un espace séquentiel contigu dans le tampon. Le processus d'arrière-plan LGWR écrit les tampons de journalisation dans les fichiers de journalisation actifs (ou groupes de fichiers) sur le disque.

Shared Pool

La partie pool partagé de SGA contient un cache de bibliothèque, un cache de dictionnaire de données, un cache de résultats de requête SQL, un cache de résultats de fonctions PL/SQL, un tampon pour les messages d'exécution parallèle et des structures de contrôle.
Un « dictionnaire de données » est un ensemble de tables et de vues de base de données qui contiennent des informations de référence sur une base de données, sa structure et ses utilisateurs. Lors de l'analyse des instructions SQL, Oracle DB accède fréquemment au dictionnaire de données. Cette opération d'accès est essentielle au fonctionnement continu d'Oracle DB.
Oracle DB accède très fréquemment au dictionnaire de données, c'est pourquoi deux emplacements spéciaux sont désignés dans la mémoire pour stocker les données du dictionnaire.
Une zone appelée « cache du dictionnaire de données », également appelée « cache de lignes » car elle stocke les données sous forme de lignes plutôt que sous forme de tampons (les tampons servent à stocker des blocs de données complets). Une autre zone de mémoire utilisée pour les données du dictionnaire est appelée « cache de bibliothèque ». Tous les processus utilisateur Oracle DB partagent ces deux caches pour accéder aux informations du dictionnaire de données.
Oracle DB utilise des régions SQL partagées (ainsi que des régions SQL privées réservées dans la PGA) pour représenter chaque instruction SQL qu'elle exécute. Oracle DB reconnaît lorsque deux utilisateurs exécutent la même instruction SQL et réutilise la région SQL partagée pour ces utilisateurs.
La « Zone SQL partagée » contient l'arborescence d'analyse et le plan d'exécution pour une instruction SQL donnée. Oracle DB économise de la mémoire en utilisant une région SQL partagée pour les instructions SQL exécutées plusieurs fois. Lorsque de nombreux utilisateurs exécutent la même application, la même instruction SQL est souvent exécutée plusieurs fois.
Lors de l'analyse d'une nouvelle instruction SQL, Oracle DB alloue de la mémoire du pool partagé pour stocker l'instruction dans la zone SQL partagée. La taille de cette mémoire dépend de la complexité de l'instruction.
Oracle DB gère les unités de programme PL/SQL (procédures, fonctions, packages, blocs anonymes et déclencheurs de données) de la même manière qu'il gère les instructions SQL individuelles. Oracle DB alloue une zone partagée pour stocker l'unité de programme sous sa forme analysée et compilée. Oracle DB alloue une zone privée pour stocker les valeurs spécifiques à la session dans laquelle l'unité de programme s'exécute, y compris les variables locales, les variables globales et les variables de package (également appelées « instanciation de package »), et pour stocker les tampons utilisés pour exécuter SQL. . Si plusieurs utilisateurs exécutent la même unité de programme, tous les utilisateurs utilisent la même zone partagée mais conservent des copies séparées de leurs propres zones SQL privées pour contenir les valeurs spécifiques à leurs propres sessions.
Les instructions SQL individuelles contenues dans une unité de programme PL/SQL sont traitées de la même manière que les autres instructions SQL.
Quelle que soit l'origine de ces instructions SQL dans l'unité de programme PL/SQL, elles utilisent toutes une zone partagée pour contenir leur représentation d'analyse, et une zone dédiée pour chaque session dans laquelle l'instruction est exécutée.
Le cache des résultats des requêtes SQL et le cache des résultats des fonctions PL/SQL sont de nouvelles fonctionnalités d'Oracle Database 11g.
Ils partagent la même infrastructure, apparaissent dans la même vue de performances dynamiques (V$) et sont gérés à l'aide du même package fourni.
Les résultats des requêtes et les fragments de requête peuvent être mis en cache en mémoire dans le « Cache des résultats des requêtes SQL ». De cette façon, la base de données peut utiliser les résultats mis en cache pour répondre aux exécutions ultérieures de ces requêtes et fragments de requête. Étant donné que la récupération des résultats du cache des résultats de requête SQL est beaucoup plus rapide que la réexécution de la requête, la mise en cache des résultats de requêtes fréquemment exécutées peut améliorer considérablement les performances de ces requêtes.
Cette fonction est parfois utilisée pour renvoyer les résultats d'un calcul si l'entrée du calcul est une ou plusieurs requêtes paramétrées émises par une fonction PL/SQL. Dans certains cas, ces requêtes accèdent à des données qui changent rarement (par rapport à la fréquence d'appel de la fonction).
Vous pouvez inclure une syntaxe dans le texte source d'une fonction PL/SQL pour demander que les résultats de la fonction soient mis en cache dans le "Cache des résultats de la fonction PL/SQL" et que le cache soit vidé lorsque DML est rencontré sur une table de la liste des tables. (pour assurer la correction correcte).

Grand Pool

Un administrateur de base de données peut configurer une zone de mémoire facultative appelée "Grand Pool" pour fournir de grandes allocations de mémoire pour :
• Mémoire de session de serveur partagée et Oracle utilisé lors de l'interaction avec plusieurs bases de données)
• E/S processus serveur
• Opérations de sauvegarde et de restauration Oracle DB
Oracle DB peut principalement utiliser le pool partagé en allouant de la mémoire de session à partir d'un grand pool pour les serveurs partagés, Oracle XA ou les tampons de requêtes parallèles Cache SQL partagé et éviter la surcharge de performances causée par la réduction. le cache SQL partagé.
De plus, la mémoire utilisée pour les opérations de sauvegarde et de restauration de la base de données Oracle, les processus du serveur d'E/S et les tampons parallèles est allouée en tampons de plusieurs centaines de Ko. Les grands pools répondent mieux à des demandes de mémoire aussi volumineuses que les pools partagés.
Il n'existe pas de liste LRU pour les grands bassins. Il est différent de l'espace réservé dans le pool partagé, qui utilise la même liste LRU que les autres mémoires allouées à partir du pool partagé.

Java pool et stream pool

La mémoire du serveur qui stocke tout le code et les données Java spécifiques à la session dans la JVM utilise la mémoire du pool Java. La mémoire du pool Java peut être utilisée de plusieurs manières, selon le mode de fonctionnement d'Oracle DB.
Les statistiques Java Pool Guidance fournissent des informations sur la mémoire cache de la bibliothèque pour Java et prédisent comment les modifications de la taille du pool Java affectent les taux d'analyse. Lorsque Statistics_level est défini sur TYPICAL ou supérieur, le guidage du pool Java est activé en interne. Ces statistiques seront réinitialisées lorsque vous fermerez le guide.
Le pool de flux est utilisé exclusivement par Oracle Streams. Le pool de flux stocke les messages de file d'attente mis en mémoire tampon et fournit de la mémoire pour les processus de capture et d'application Oracle Streams.
Sauf si le pool de flux est spécialement configuré, sa taille part de zéro. Lors de l'utilisation d'Oracle Streams, la taille du pool augmente de manière dynamique selon les besoins.

Program Global Area (PGA)

La Program Global Area (PGA) est une zone de mémoire dédiée qui contient des données et des informations de contrôle pour le processus du serveur. Chaque processus serveur possède son propre PGA. Le PGA n'est accessible que par le processus serveur correspondant, et seul le code Oracle agissant au nom de ce processus serveur peut le lire. Le code du développeur ne peut pas accéder au PGA.
Chaque PGA contient un espace de pile. Dans un environnement de serveur dédié, il existe un processus serveur distinct pour chaque utilisateur qui se connecte à l'instance de base de données. Pour ce type de connexion, le PGA contient une subdivision de mémoire appelée User Global Area (UGA). UGA se compose des parties suivantes :
• Zone de curseur, utilisée pour stocker les informations d'exécution du curseur
• Magasin de données de session utilisateur, utilisé pour stocker les informations de contrôle sur la session
• Espace de travail SQL, utilisé pour traiter les instructions SQL, notamment :

• Zone de tri, utilisée pour les fonctions de tri des données, telles que ORDER BY et GROUP BY
• Zone de hachage, utilisée pour effectuer des jointures de hachage de tables
• Zone de création de bitmap, utilisée pour créer des index bitmap couramment utilisés dans les entrepôts de données
• Bitmap zone de fusion, utilisée pour analyser l'exécution des plans d'index bitmap
  Dans un environnement de serveur partagé, plusieurs utilisateurs clients partagent le processus du serveur. Dans ce mode, l'UGA est déplacé vers le SGA (pool partagé ou grand pool si configuré) et le PGA ne contient que de l'espace de pile.

Structure des processus

Les processus du système Oracle DB sont principalement divisés en deux groupes :
1. Processus utilisateur exécutant le code de l'application ou de l'outil Oracle
Pour différentes configurations Oracle DB, la structure des processus utilisateur est différente, selon le système d'exploitation. et les options OracleDB sélectionnées. Le code pour les utilisateurs connectés peut être configuré comme un serveur dédié ou un serveur partagé.
• Serveur dédié : pour chaque utilisateur, le processus utilisateur exécutant l'application de base de données est servi par un processus serveur dédié exécutant le code du serveur Oracle DB.
• Serveur partagé : Pas besoin d'avoir un processus de serveur dédié pour chaque connexion. Le répartiteur dirige plusieurs demandes de session réseau entrantes vers le pool de processus du serveur partagé. Le processus de serveur partagé traite toutes les demandes des clients.
2. Processus Oracle DB (y compris le processus serveur et le processus en arrière-plan) qui exécute le code du serveur Oracle DB
2.1 Processus serveur
Oracle DB crée un processus serveur pour gérer les demandes des processus utilisateur connectés à l'instance. Les processus utilisateur représentent des applications ou des outils qui se connectent à Oracle DB. Il peut se trouver sur le même ordinateur qu'Oracle DB ou sur un client distant utilisant le réseau pour accéder à Oracle DB. Le processus utilisateur communique d'abord avec un processus d'écoute qui, dans un environnement dédié, crée un processus serveur.
Le processus serveur créé pour représenter l'application de chaque utilisateur peut effectuer une ou plusieurs des opérations suivantes :
• Analyser et exécuter les instructions SQL émises via l'application
• Récupérer les instructions SQL à partir d'un fichier de données sur le disque. Les blocs de données nécessaires sont lus dans le Tampon de base de données partagé de SGA (si ces blocs de données ne sont pas actuellement dans le SGA)
• Les résultats sont renvoyés afin que l'application puisse traiter les informations

2.2, Processus en arrière-plan
Pour maximiser les performances et Pour répondre aux besoins de plusieurs utilisateurs, multi- processus Les systèmes Oracle DB utilisent un certain nombre de processus Oracle DB supplémentaires appelés « processus d'arrière-plan ». Une instance de base de données Oracle peut avoir plusieurs processus en arrière-plan.
Les processus d'arrière-plan courants dans les environnements non-RAC et non-ASM incluent :
• Processus d'écriture de base de données (DBWn)
• Processus d'écriture de journal (LGWR)
• Processus de point de contrôle (CKPT)
• Processus de surveillance du système (SMON)
• Moniteur de processus Processus (PMON)
• Processus de récupération (RECO)
• Coordinateur de file d'attente de tâches (CJQ0)
• Processus d'esclave de travail (Jnnn)
• Processus d'archivage (ARCn)
• Processus de surveillance de file d'attente (QMNn)
Plus avancé Il peut y avoir d'autres arrière-plans processus dans la configuration (tels que RAC). Pour plus d'informations sur les processus en arrière-plan, consultez la vue V$BGPROCESS.
Certains processus en arrière-plan sont créés automatiquement lors du démarrage d'une instance, tandis que d'autres sont créés à la demande.
D'autres structures de processus ne sont pas spécifiques à une seule base de données, mais peuvent être partagées entre plusieurs bases de données sur le même serveur. Les processus d'infrastructure de réseau et les processus de réseau entrent dans cette catégorie.
Les processus Oracle Grid Infrastructure sur les systèmes Linux et UNIX incluent :
• ohasd : démon du service de haute disponibilité Oracle, responsable du démarrage des processus Oracle Clusterware
• ocssd : démon du service de synchronisation de cluster
• diskmon : démon de surveillance des disques, responsable de la surveillance des entrées HP et sortie d'Oracle Exadata Storage Server
• cssdagent : démarrer, arrêter et vérifier l'état du démon CSS ocssd
• oraagent : étendre le clusterware pour prendre en charge les exigences spécifiques à Oracle et les ressources complexes
• orarootagent : un processus d'agent Oracle dédié, peut vous aider gérer les ressources appartenant à l'utilisateur root (comme le réseau)

Processus d'écriture de base de données (DBWn)

Le processus d'écriture de base de données (DBWn) peut écrire le contenu du tampon dans le fichier de données. Le processus DBWn est responsable de l'écriture des tampons modifiés (tampons de données gris) dans le cache de tampon de base de données sur le disque. Bien que pour la plupart des systèmes, un seul processus d'écriture de base de données (DBW0) soit suffisant ; cependant, si le système nécessite des modifications fréquentes des données, des processus supplémentaires (DBW1 à DBW9 et DBWa à DBWz) peuvent être configurés pour améliorer les performances d'écriture. Ces processus DBWn supplémentaires ne sont pas utiles sur les systèmes monoprocesseur.
Lorsqu'un tampon dans le cache de tampon de base de données est modifié, le système le marque comme tampon de données gris et l'ajoute en tête de la file d'attente des points de contrôle dans l'ordre SCN. Par conséquent, l'ordre est cohérent avec l'ordre dans lequel les entrées de rétablissement pour ces tampons modifiés sont écrites dans le journal de rétablissement. Lorsque le nombre de tampons libres dans le cache de tampons tombe en dessous d'un certain seuil interne (au point que le processus serveur considère qu'il est difficile d'obtenir des tampons libres), DBWn écrit les tampons rarement utilisés dans le fichier de données, en écrivant. L'ordre commence à la fin de la liste LRU, permettant aux processus de remplacer les tampons selon leurs besoins. DBWn écrit également à partir de la queue de la file d’attente des points de contrôle pour protéger les points de contrôle à l’avenir.
Il existe une structure de mémoire dans le SGA qui contient l'adresse d'octet de rétablissement (RBA) de l'emplacement dans le flux de rétablissement à partir duquel la récupération démarrera en cas d'échec d'une instance. Cette structure sert de pointeur à refaire et est écrite dans le fichier de contrôle par le processus CKPT une fois toutes les trois secondes. Étant donné que DBWn écrit le tampon de données gris dans l'ordre SCN et que la restauration est effectuée dans l'ordre SCN, chaque fois que DBWn écrit le tampon de données gris à partir de la liste LRUW, le pointeur contenu dans la structure de mémoire SGA sera également avancé pour faciliter la récupération de l'instance (. Si nécessaire) Commencez la lecture et la restauration à partir de la position approximativement correcte et évitez les E/S inutiles. C'est ce qu'on appelle un « point de contrôle incrémentiel ».
Remarque : Il existe d'autres situations dans lesquelles DBWn peut effectuer des opérations d'écriture (par exemple, lorsque le tablespace est défini en lecture seule ou est mis hors ligne). Dans ces cas, les points de contrôle incrémentiels ne se produisent pas car l'ordre dans lequel les tampons de données grises appartenant uniquement aux fichiers de données correspondants sont écrits dans la base de données est indépendant de l'ordre SCN.
L'algorithme LRU conserve les blocs les plus fréquemment consultés dans le cache tampon pour minimiser les lectures sur le disque. Vous pouvez utiliser l'option CACHE avec une table pour conserver les blocs en mémoire plus longtemps.
Le paramètre d'initialisation DB_WRITER_PROCESSES spécifie le nombre de processus DBWn. Le nombre maximum de processus DBWn est de 36. Si l'utilisateur ne spécifie pas ce nombre de processus lors du démarrage, Oracle DB déterminera comment définir DB_WRITER_PROCESSES en fonction du nombre de processeurs et de groupes de processeurs.
Le processus DBWn écrit des tampons de données grises sur le disque dans les conditions suivantes :
• Lorsque le processus serveur ne parvient pas à trouver un tampon propre et réutilisable après avoir analysé un nombre seuil de tampons, DBWn est invité à effectuer une opération d'écriture. DBWn écrit le tampon de données gris sur le disque de manière asynchrone tout en effectuant d'autres traitements.
• Tampon d'écriture DBWn pour avancer les points de contrôle. Un point de contrôle est la position de départ dans le thread de rétablissement (journal) utilisé pour effectuer la récupération d'instance. La position du journal est déterminée par le tampon de données gris le plus ancien du cache de tampon. Dans tous les cas, DBWn effectue des opérations d'écriture par lots (multiblocs) pour améliorer l'efficacité. Le nombre de blocs écrits lors d'une opération d'écriture multibloc varie en fonction du système d'exploitation.

Processus d'écriture de journal (LGWR)

Le processus d'écriture de journal (LGWR) est responsable de la gestion du tampon de journalisation en écrivant les entrées du tampon de journalisation dans le fichier de journalisation sur le disque. LGWR écrit toutes les entrées de rétablissement copiées dans le tampon depuis la dernière écriture.
Le tampon redo log est un tampon circulaire. Une fois que LGWR a écrit les entrées du tampon de journalisation dans le fichier de journalisation, le processus serveur peut copier les nouvelles entrées dans le tampon de journalisation en plus de celles qui ont été écrites sur le disque. La vitesse d'écriture de LGWR est généralement suffisamment rapide pour garantir qu'il y a toujours de la place dans le tampon pour de nouvelles entrées, même lorsque l'accès au journal de rétablissement est lourd. LGWR écrit une partie contiguë du tampon sur le disque.
LGWR effectue des opérations d'écriture lorsque :
• Lorsqu'un processus utilisateur valide une transaction
• Lorsqu'un tiers du tampon de journalisation est plein
• Lorsque le processus DBWn écrit le tampon modifié sur le disque (si nécessaire) avant
• Tous les 3 secondes
Tous les enregistrements de rétablissement associés aux modifications du tampon doivent être écrits sur le disque avant que DBWn puisse écrire un tampon modifié sur le disque (protocole d'écriture anticipée). Si DBWn constate que certains enregistrements de restauration n'ont pas encore été écrits, il demandera à LGWR
d'écrire ces enregistrements de restauration sur le disque et attendra que LGWR termine l'opération d'écriture du tampon de journalisation avant d'écrire dans le tampon de données. LGWR écrira dans le groupe de journaux actuel. Si un fichier du groupe devient corrompu ou indisponible, LGWR continuera à écrire dans d'autres fichiers du groupe et enregistrera une erreur dans le fichier de trace LGWR et le journal d'alerte système. Si tous les fichiers d'un groupe sont corrompus ou si le groupe n'est pas disponible car il n'a pas été archivé, LGWR ne peut pas continuer à fonctionner.
Lorsque l'utilisateur émet une instruction COMMIT, LGWR placera un enregistrement de validation dans le tampon de journalisation et écrira immédiatement l'enregistrement sur le disque avec le journal de restauration de la transaction. Les modifications correspondantes apportées aux blocs de données sont retardées jusqu'à ce qu'elles puissent être écrites plus efficacement. C'est ce qu'on appelle le « mécanisme de validation rapide ». L'écriture atomique d'une entrée de rétablissement contenant un enregistrement de validation de transaction est un événement unique qui détermine si une transaction a été validée.
Oracle DB renvoie un code de réussite pour les transactions validées même si le tampon de données n'a pas encore été écrit sur le disque.
Si plus d'espace tampon est nécessaire, LGWR écrira parfois des entrées de journalisation avant de valider la transaction. Ces entrées ne deviennent permanentes que si la transaction est validée ultérieurement. Lorsqu'un utilisateur valide une transaction, la transaction se voit attribuer un numéro de modification du système (SCN), qu'Oracle DB enregistre dans le journal de rétablissement avec les entrées de rétablissement de la transaction. Les SCN sont enregistrés dans le journal redo afin que les opérations de récupération puissent être synchronisées entre les clusters d'applications réels et les bases de données distribuées.
Lorsque l'activité est élevée, LGWR peut écrire des fichiers de journalisation en utilisant des validations de groupe. Par exemple, supposons qu'un utilisateur soumette une transaction. LGWR doit écrire les entrées de rétablissement pour cette transaction sur le disque. Lorsque cela se produit, les autres utilisateurs émettent des instructions COMMIT. Cependant, LGWR ne peut pas écrire dans les fichiers de journalisation pour valider ces transactions tant qu'il n'a pas terminé son opération d'écriture précédente. Une fois les entrées de la première transaction écrites dans le fichier de journalisation, la liste complète des entrées de restauration pour les transactions en attente (pas encore validées) peut être écrite sur le disque en une seule opération, ce qui est plus rapide que le traitement individuel des entrées de transaction. O est requis. En conséquence, Oracle DB peut minimiser les E/S disque et maximiser les performances de LGWR. Si le taux de demandes de validation est constamment élevé, chaque opération d'écriture à partir du tampon de journalisation (effectuée par LGWR) peut contenir plusieurs enregistrements de validation.

Processus de point de contrôle (CKPT)

Un « point de contrôle » est une structure de données qui définit un numéro de modification du système (SCN) dans le thread de rétablissement d'une base de données. Les points de contrôle sont enregistrés dans le fichier de contrôle et dans l'en-tête de chaque fichier de données. Ce sont des éléments essentiels des opérations de rétablissement.
Lorsqu'un point de contrôle se produit, Oracle DB doit mettre à jour les en-têtes de tous les fichiers de données pour enregistrer les détails du point de contrôle. Cela se fait par le processus CKPT. Le processus CKPT n'écrit pas de blocs sur le disque ; ce travail est effectué par DBWn. Le SCN enregistré dans l'en-tête du fichier garantit que toutes les modifications apportées aux blocs de base de données jusqu'à ce SCN seront écrites sur le disque.
Le moniteur SYSTEM_STATISTICS dans Oracle Enterprise Manager affiche les statistiques des points de contrôle DBWR indiquant le nombre de demandes de points de contrôle terminées.

Processus de surveillance système (SMON)

Le processus de surveillance système (SMON) effectue une récupération au démarrage de l'instance (si nécessaire). SMON est également responsable du nettoyage des segments temporaires qui ne sont plus utilisés. Si des transactions terminées sont ignorées lors de la récupération de l'instance en raison d'erreurs de lecture de fichier ou d'erreurs hors ligne, SMON reprendra ces transactions lorsque l'espace table ou le fichier reviendra en ligne.
SMON vérifie périodiquement si le processus est nécessaire. D'autres processus peuvent également l'appeler lorsqu'ils détectent le besoin de SMON.

Process Monitor Process

Le Process Monitor Process (PMON) effectue une récupération de processus lorsqu'un processus utilisateur échoue. PMON est responsable de vider le cache du tampon de la base de données et de libérer les ressources occupées par le processus utilisateur. Par exemple, PMON réinitialise l'état des tables de transactions actives, libère les verrous et supprime l'ID de processus de la liste des processus actifs.
PMON vérifie périodiquement l'état des processus du répartiteur et du serveur et redémarre tous les processus du répartiteur et du serveur qui ont arrêté de fonctionner (à moins qu'ils ne soient intentionnellement interrompus par OracleDB). PMON enregistre également des informations sur les processus d'instance et de répartiteur auprès de l'écouteur réseau.
Comme SMON, PMON vérifie périodiquement s'il doit s'exécuter ; d'autres processus peuvent également l'appeler s'ils détectent que cela est nécessaire.

Processus de récupération

Le processus de récupération (RECO) est un processus d'arrière-plan pour les configurations de bases de données distribuées qui résout automatiquement les échecs impliquant le traitement des transactions distribuées. Le processus RECO de l'instance se connecte automatiquement aux autres bases de données impliquées dans le traitement des transactions distribuées en question. Lorsque le processus RECO rétablit les connexions entre les serveurs de bases de données impliqués, il résout automatiquement toutes les transactions problématiques et supprime de la table des transactions en attente de chaque base de données toutes les transactions correspondant aux transactions problématiques résolues.
Si le processus RECO ne parvient pas à se connecter au serveur distant, RECO tentera automatiquement de se reconnecter après un certain intervalle de temps. Cependant, RECO attendra un temps croissant (de façon exponentielle) avant de réessayer de se connecter.

Processus d'archivage (ARCn)

Après un changement de journal, le processus d'archivage (ARCn) copiera les fichiers de journalisation sur le périphérique de stockage spécifié. Le processus ARCn existe uniquement lorsque la base de données est en mode ARCHIVELOG et que l'archivage automatique est activé.
Si vous prévoyez une charge de travail d'archivage importante (comme lors du chargement par lots de données), vous pouvez augmenter le nombre maximum de processus d'archivage à l'aide du paramètre d'initialisation LOG_ARCHIVE_MAX_PROCESSES. L'instruction ALTER SYSTEM peut modifier dynamiquement la valeur de ce paramètre pour augmenter ou diminuer le nombre de processus ARCn.

Structure de stockage

Les fichiers qui composent Oracle DB peuvent être divisés dans les catégories suivantes :
• Fichiers de contrôle : contiennent des données liées à la base de données elle-même, c'est-à-dire les informations sur la structure physique de la base de données. Ces fichiers sont essentiels à la base de données. Sans ces fichiers, les fichiers de données ne peuvent pas être ouverts pour accéder aux données de la base de données.
• Fichiers de données : contiennent les données utilisateur ou d'application de la base de données, ainsi que les métadonnées et le dictionnaire de données.
• Fichiers de journalisation en ligne : utilisés par exemple pour la récupération de la base de données. Si le serveur de base de données tombe en panne mais qu'aucun fichier de données n'est perdu, l'instance peut utiliser les informations contenues dans ces fichiers pour récupérer la base de données.
Les fichiers supplémentaires suivants sont très importants pour le bon fonctionnement de la base de données :
• Fichier de paramètres : utilisé pour définir la configuration au démarrage de l'instance
• Fichier de mots de passe : permet à sysdba, sysoper et sysasm de se connecter à l'instance à distance et d'effectuer des tâches administratives.
• Fichier de sauvegarde : utilisé pour effectuer la récupération de la base de données. Les fichiers de sauvegarde sont généralement restaurés si les fichiers d'origine ont été endommagés ou supprimés en raison d'une défaillance du support ou d'une erreur de l'utilisateur.
• Fichiers de journalisation archivés : contiennent un historique en temps réel des modifications de données (rétablissements) survenues sur une instance. Grâce à ces sauvegardes de fichiers et de bases de données, les fichiers de données perdus peuvent être récupérés. En d'autres termes, les journaux d'archives peuvent restaurer les fichiers de données restaurés.
• Fichiers de trace : chaque serveur et processus en arrière-plan peuvent écrire dans les fichiers de trace associés. Lorsqu'un processus détecte une erreur interne, il transfère les informations sur l'erreur dans le fichier de trace approprié. Certaines informations écrites dans le fichier de trace sont fournies à l'administrateur de la base de données, tandis que d'autres informations sont fournies aux services de support Oracle.
• Fichiers journaux d'alerte : ces fichiers contiennent des entrées de trace spéciales. Le journal des avertissements de la base de données est un journal des messages et un journal des erreurs classés par ordre chronologique. Oracle vous recommande de consulter périodiquement le journal des alertes.

Structure logique et physique de la base de données

Base de données, espaces de table et fichiers de données

Cette diapositive explique la relation entre les bases de données, les espaces de table et les fichiers de données. Chaque base de données est logiquement divisée en deux ou plusieurs espaces table. Un ou plusieurs fichiers de données sont explicitement créés dans chaque espace table pour stocker physiquement les données de toutes les structures logiques dans l'espace table. Pour les tablespaces TEMPORAIRES, les fichiers de données ne sont pas créés, mais des fichiers temporaires
sont créés. Les fichiers de données d'espace table peuvent être physiquement stockés à l'aide de n'importe quelle technologie de stockage prise en charge.

Tablespaces

Une base de données est divisée en plusieurs unités de stockage logiques, appelées « tablespaces », qui sont utilisées pour regrouper des structures logiques ou des fichiers de données associés. Par exemple, les espaces table regroupent généralement tous les segments d'une application en un seul groupe pour simplifier certaines opérations de gestion.
Une base de données est divisée en « espaces tables », qui sont des unités de stockage logiques qui peuvent être utilisées pour regrouper des structures logiques associées. Chaque base de données est logiquement divisée en deux ou plusieurs espaces table : les espaces table SYSTEM et SYSAUX. Un ou plusieurs fichiers de données sont explicitement créés dans chaque espace table pour stocker physiquement les données de toutes les structures logiques dans l'espace table.
Un segment de taille 160 Ko s'étend sur deux fichiers de données et se compose de deux extensions. La première extension se trouve dans le premier fichier de données et a une taille de 64 Ko ; la deuxième extension se trouve dans le deuxième fichier de données et a une taille de 96 Ko. Les deux extensions sont constituées de plusieurs blocs Oracle contigus de 8 Ko.
Remarque : Il est possible de créer un tablespace de fichiers volumineux, qui ne contient qu'un seul fichier, généralement très volumineux. Le fichier peut atteindre la taille maximale autorisée par l'architecture des ID de ligne. Cette taille maximale correspond à la taille de bloc de l'espace table multipliée par 236, ou si la taille de bloc est de 32 Ko, la taille maximale est de 128 To. Un espace table de petits fichiers traditionnel (valeur par défaut) peut contenir plusieurs fichiers de données, mais ces fichiers ne sont pas très volumineux.

Blocs de données

Les données Oracle DB sont stockées dans des "blocs de données", qui constituent le niveau de granularité le plus bas. Un bloc de données correspond à un nombre spécifique d'octets d'espace physique sur le disque. La taille du bloc de données de chaque espace table est spécifiée lors de la création de l'espace table. La base de données utilise et alloue de l'espace de base de données libre en unités de blocs de données Oracle.

District

Le prochain niveau d'espace de base de données logique est "District". Une étendue est un nombre spécifique de blocs contigus de données Oracle (obtenus à partir d'une allocation unique) utilisés pour stocker un type spécifique d'informations. Les blocs de données Oracle au sein d'une extension sont logiquement contigus, mais peuvent être physiquement répartis à différents emplacements sur le disque (les implémentations de répartition RAID et de système de fichiers peuvent provoquer ce comportement).

Segment

Le niveau supérieur de la zone de stockage logique de la base de données est appelé "segment". Un segment est un ensemble de zones allouées à une certaine structure logique. Par exemple :
• Segment de données : chaque table non clusterisée et non organisée en index possède un segment de données, à l'exception des tables externes, des tables temporaires globales et des tables partitionnées, dont chacune comporte une ou plusieurs parties. Toutes les données du tableau sont stockées dans l'étendue du segment de données correspondant. Pour les tables partitionnées, il existe un segment de données pour chaque partition. Chaque cluster possède également un segment de données. Les données de chaque table du cluster sont stockées dans le segment de données du cluster.
• Segment d'index : chaque index possède un segment d'index qui stocke toutes ses données. Pour un index partitionné, il existe un segment d'index pour chaque partition.
• Segment d'annulation : le système crée un espace de table UNDO pour chaque instance de base de données. Cet espace table contient un grand nombre de segments de restauration utilisés pour stocker temporairement les informations de restauration. Les informations du segment de restauration sont utilisées pour générer des informations de base de données cohérentes en lecture afin d'annuler les transactions utilisateur non validées lors de la récupération de la base de données.
• Segment temporaire : un segment temporaire est créé par Oracle DB lorsqu'une instruction SQL nécessite une zone de travail temporaire pour terminer son exécution. Une fois l'exécution de l'instruction terminée, l'étendue du segment temporaire est renvoyée à l'instance pour une utilisation ultérieure. Vous pouvez spécifier un espace table temporaire par défaut pour chaque utilisateur ou spécifier un espace table temporaire par défaut utilisé dans la portée de la base de données.
Remarque : Il existe également d'autres types de segments non répertoriés ci-dessus. De plus, certains objets de schéma, tels que des vues, des packages, des déclencheurs, etc., bien qu'ils soient des objets de base de données, ne sont pas considérés comme des segments. Les segments ont des allocations d'espace disque distinctes. D'autres objets sont stockés sous forme de lignes dans le segment de métadonnées système.
Le serveur Oracle DB alloue dynamiquement de l'espace. Si les extensions existantes du segment sont pleines, des extensions supplémentaires sont ajoutées. Étant donné que les extensions sont allouées selon les besoins, les extensions d'un segment peuvent ou non être adjacentes sur le disque et elles peuvent provenir de fichiers de données différents appartenant au même espace table.

Gestion automatique du stockage

La gestion automatique du stockage (ASM) fournit une intégration verticale du système de fichiers et du gestionnaire de volumes pour les fichiers Oracle DB. ASM peut gérer un seul ordinateur multitraitement symétrique (SMP) ou plusieurs nœuds d'un cluster pour prendre en charge Oracle Real Application Clusters (RAC).
Oracle ASM Cluster File System (ACFS) est un système de fichiers et une technologie de gestion du stockage multiplateforme et évolutif qui étend les fonctionnalités d'ASM pour prendre en charge les fichiers d'application externes à Oracle DB, tels que les fichiers exécutables, les rapports, BFILE, la vidéo, l'audio, du texte, des images et d’autres données de fichiers d’application à usage général.
ASM répartit la charge d'entrée/sortie (E/S) sur toutes les ressources disponibles, éliminant ainsi l'optimisation manuelle des E/S et optimisant les performances. ASM aide les administrateurs de base de données à gérer les environnements de bases de données dynamiques en leur permettant d'ajuster les allocations de stockage en augmentant la taille de la base de données sans arrêter la base de données.
ASM peut conserver des copies redondantes des données pour assurer une tolérance aux pannes, ou peut être construit sur les mécanismes de stockage fournis par le fournisseur. La gestion des données est réalisée en sélectionnant les mesures de fiabilité et de performances requises pour chaque type de données, plutôt qu'en interaction manuelle fichier par fichier.
En automatisant les tâches de stockage effectuées manuellement, la fonctionnalité ASM fait gagner du temps aux administrateurs de base de données, augmentant ainsi la capacité des administrateurs à gérer des bases de données plus nombreuses et plus volumineuses avec une plus grande efficacité.

ASM n'entrave aucune fonctionnalité de base de données existante. Les bases de données existantes peuvent fonctionner comme d'habitude. De nouveaux fichiers peuvent être créés en tant que fichiers ASM et les fichiers existants peuvent être gérés tels quels ou migrés vers ASM.
Le diagramme ci-dessus illustre la relation entre les fichiers de données Oracle DB et les composants de stockage ASM. La marque de la patte d'oie représente une relation un-à-plusieurs. Il existe une relation un-à-un entre les fichiers de données Oracle DB et les fichiers ou fichiers ASM stockés dans le système de fichiers du système d'exploitation.
Un groupe de disques Oracle ASM est un ensemble d'un ou plusieurs disques Oracle ASM gérés comme une unité logique. Les structures de données du groupe de disques sont autonomes et utilisent une partie de l'espace pour les besoins en métadonnées. Les disques Oracle ASM sont des périphériques de stockage provisionnés pour les groupes de disques Oracle ASM et peuvent être des disques physiques, des partitions, des numéros d'unité logique (LUN) dans une matrice de stockage, des volumes logiques (LV) ou des fichiers connectés à un réseau. Chaque disque ASM est divisé en un certain nombre d'unités d'allocation (AU) ASM, qui constituent la plus petite quantité d'espace disque contigu qu'ASM peut allouer. Lorsque vous créez un groupe de disques ASM, vous pouvez définir la taille de l'unité d'allocation ASM sur 1, 2, 4, 8, 16, 32 ou 64 Mo, en fonction du niveau de compatibilité du groupe de disques. Une ou plusieurs unités d'allocation ASM forment une région ASM. Les zones Oracle ASM sont un stockage brut utilisé pour stocker le contenu des fichiers Oracle ASM. Les fichiers Oracle ASM se composent d'une ou plusieurs extensions de fichiers. Pour prendre en charge des fichiers ASM très volumineux, des extensions de taille variable peuvent être utilisées, avec des tailles d'extension égales à 1x, 4x et 16x la taille de l'AU.

Tutoriel recommandé : "

Tutoriel vidéo Oracle"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!