Architecture d`Oracle
publicité
Architecture d’Oracle © Richard CHBEIR Email : [email protected] Plan Architecture Structure Physique Composants Processus Traitement de requêtes Structure Logique © [email protected] Architecture Un serveur Oracle est composé de 3 éléments Mémoire System Global Area ou SGA Disque Données, fichiers Redo, fichiers de contrôle, fichiers de paramètres, fichiers de mot de passe, etc. Processus Services d'arrière plan ou demons © [email protected] Architecture SGA (System Global Area) Permet de contenir les structures d'une instance Oracle Contient les données et les informations de contrôle pour le serveur Oracle Est allouée de la mémoire virtuelle de l'ordinateur où réside le serveur Oracle © [email protected] SGA (System Global Area) Buffer de données Zone mémoire réservée aux buffers de données, d’index et de rollback segments. Espace paramétrable Shared Pool Area Buffer Redo log SQL area (parsing des requêtes) Library cache (exécutable PL/SQL) Zone mémoire qui enregistre l ’activité transactionnelle des utilisateurs. Dictionary cache (infos sur les méta-données) © [email protected] Large Pool (Optionnel) Utilisé pour la gestion des bases de données parallèles Composants de SGA Buffer de données Est utilisé pour stocker les données en mémoire afin d'accélérer l'interrogation et/ou la modification Aucune modification est faite directement sur les données du disque Oracle lit les données suite à la demande d'un processus utilisateur et ensuite valide les modifications sur le disque Il utilise un algorithme nommé LRU (Least-Recently Used) pour déterminer les données à libérer du cache La taille de chacun des buffers (DB_BLOCK_BUFFERS) est égale à la taille d'un bloc de données (DB_BLOCK_SIZE) © [email protected] Composants de SGA Buffer de données Buffer Redo Log Il stocke une information spéciale nommé Redo permettant à Oracle de reconstruire les modifications des données en cas de panne Bloc de données modifié Emplacement Nouvelle valeur L'information Redo est stockée dans le buffer Redo log à chaque modification de données effectuée par un utilisateur L'information Redo reste dans le buffer Redo log jusqu'à ce qu'Oracle la stocke sur le disque Sa taille est définie par LOG_BUFFER © [email protected] Composants de SGA Buffer de données Buffer Redo Log Shared Pool Permet de stocker plusieurs éléments cruciaux pour la gestion des données : Library cache : permet d'analyse l'ordre d'exécution d'une requête SQL et de définir un plan d'exécution. Si la même requête est ré-exécutée, le serveur n'analyse pas son ordre. Cela permet d'améliorer la performance des applications Dictionary (ou row) cache : utilisé pour le stockage des métadata dans la mémoire afin d'accélérer l'accès au dictionnaire et les mécanismes de contrôle (nom d'utilisateurs, privilèges, etc.). © [email protected] Composants Disque © [email protected] Composants Disque Les fichiers de données (DataFiles) Ils sont utilisés pour stocker le dictionnaire de données et les objets de la base de données. Ces fichiers sont souvent très volumineux. Les données dans le buffer de données et le dictionnaire cache sont récupérées de ces fichiers Une base de données contient au moins un fichier de données © [email protected] Composants Disque Les fichiers Redo Logs Ils sont utilisés pour stocker les informations Redo sur le disque afin de garantir la reconstruction des données en cas de panne Une BDD Oracle requiert au moins 2 fichiers redo log 2 familles de redo log : 1- ONLINE pour la restauration face à une défaillance de l’instance 2- OFFLINE pour une restauration dans le cas d ’une défaillance d’un support de stockage. © [email protected] Composants Disque Les fichiers de contrôle Ils sont utilisés pour définir la localisation des composants disque sur le serveur. La localisation de fichiers de données et les redo logs y apparaissent. Pour cette raison, ils sont modifiés à chaque ajout ou suppression des fichiers redo logs ou fichiers de données. Oracle lit les fichiers de contrôle au démarrage de la BDD. Une BDD requiert au moins un fichier de contrôle © [email protected] Composants Disque Le fichier de paramètres Utilisé pour définir les caractéristiques d'une instance Oracle (taille SGA, Bloc Oracle, etc). C'est le fichier init.ora © [email protected] Composants Disque Le fichier de mot de passe Il est utilisé pour établir l'authenticité des utilisateurs privilégiés de BDD Oracle. Sans ce fichier, la BDD est administrable avec n'importe quel outil de gestion (ex : SQL*Plus) © [email protected] Les processus ORACLE Effectuent les fonctions nécessaires au traitement simultané de plusieurs requêtes utilisateurs, sans compromettre L'intégrité La performance du système © [email protected] Les processus ORACLE 2 types de processus Processus utilisateur Processus sur le serveur oracle Processus Serveur Processus Background (Oracle.exe) Ces processus exploitent Program Global Area ou PGA © [email protected] Les processus ORACLE Un utilisateur peut se connecter à Oracle Connexion directe au serveur L'utilisateur se connectant à un serveur Unix exécutant Oracle lance Server Manager Connexion à deux tiers (Client-serveur) L'utilisateur se connectant à une machine Windows XP exécute Developper/2000 Connexion à trois tiers L'utilisateur lançant un explorateur réseaux sous Windows exécute une application sur un autre poste qui extrait les données sur un serveur Oracle © [email protected] Les processus ORACLE Processus utilisateur (ou client) Il fonctionne sur la machine du client Il démarre lors de l'appel de l'outil ou de l'application SQL*Plus, Server Manager, Developper/2000, Oracle Entreprise Manager, etc.) Il se termine lorsque l'utilisateur quitte ou interrompre l'application Il appelle le serveur Oracle © [email protected] Les processus ORACLE Processus serveur Il fonctionne sur la machine serveur (hôte) Suite à la demande du processus utilisateur, le processus serveur lit les données des fichiers à l'intérieur du buffer de données Dans une config de serveur dédié 1 processus utilisateur + 1 processus serveur Dans une config MTS (mutlithreads) Partage de processus Il utilise une PGA (Program Global Area) exclusive Il envoie les résultats au client © [email protected] Zone mémoire du processus (PGA) Est une zone mémoire contenant des données relatives à un processus serveur unique ou à un thread unique Elle n'est ni partagé ni accessible en écriture Elle est allouée lorsqu'un processus serveur est créé Elle contient Une zone de tri utilisée avant le traitement ou le renvoi du résultat à l'utilisateur Processus Des informations sur la session Serveur L'état du curseur PGA © [email protected] Background Threads DBWR (Data Base WRiter) Ecrire les blocs modifiés dans le cache de données sur les disques. Compte tenu de la journalisation (Redo log), les blocs ne sont pas forcément écrits à la validation des transactions. LOGWR (LoG WRiter) Ecrire dans les fichiers Redo Log le contenu du cache Redo Log SMON (System MONitor) Réalise le Recovery au moment du Startup Efface les segments temporaires Organise les blocks de données © [email protected] Background Threads PMON (Process MONitor) Vide le cache Libère les ressources bloquées Ré-active si nécessaire les dispatchers ARCH (ARCHiver) Copie les redo log, quand ils sont pleins, dans les fichiers d ’archive. RECO Termine ou annule les transactions en suspend dans les BD distribuées LISTENER ou KMNLS Permet d’établir des connexions Client-Serveur avec la base de données © [email protected] Traitement d'une requête (ici) Il y a 3 étapes Analyse Exécution Récupération © [email protected] Traitement d'une requête Analyse Syntaxique Analyse Sémantique Plan ou ordre d'exécution Select * From emp; Envoie état Envoie requête Processus Utilisateur Processus Serveur 1- Analyse © [email protected] Traitement d'une requête Select * From emp; Préparation à l'extraction Processus Utilisateur Processus Serveur 2- Exécution © [email protected] Traitement d'une requête Select * From emp; Envoie Données Envoie Données …. Processus Utilisateur Processus Serveur 3- Récupération © [email protected] Traitement d'une MAJ INSTANCE Update emp; SET sal = sal*1.5 Buffer de données Buffer Redo log Shared Pool Processus Serveur 1 Fichiers de données Fichiers de contrôles © [email protected] Fichiers Redo Traitement d'une MAJ INSTANCE Update emp; SET sal = sal*1.5 Buffer de données Buffer Redo log Shared Pool 2 Processus Serveur Fichiers de données Fichiers de contrôles © [email protected] Fichiers Redo Traitement d'une MAJ INSTANCE Update emp; SET sal = sal*1.5 Shared Pool Buffer de données Buffer Redo log Library Cache Cache du dictionnaire 3 Processus Serveur Fichiers de données Fichiers de contrôles © [email protected] Fichiers Redo Traitement d'une MAJ INSTANCE Update emp; SET sal = sal*1.5 Shared Pool Buffer de données Buffer Redo log Library Cache Cache du dictionnaire 4 Processus Serveur Fichiers de données Fichiers de contrôles © [email protected] Fichiers Redo Traitement d'une MAJ INSTANCE Update emp; SET sal = sal*1.5 Shared Pool Buffer de données Buffer Redo log Library Cache Cache du dictionnaire 5 Processus Serveur Fichiers de données Fichiers de contrôles © [email protected] Fichiers Redo Rollback Segment Table Ancienne Image Nouvelle Image Rollback Segment Ordre MAJ © [email protected] Traitement des COMMIT Enregistrement de validation INSTANCE Shared Pool Buffer de données Buffer Redo log Library Cache Cache du dictionnaire 1 Processus Serveur Fichiers de données Fichiers de contrôles Processus Utilisateur © [email protected] Fichiers Redo Traitement des COMMIT INSTANCE Shared Pool Buffer de données Buffer Redo log Library Cache Cache du dictionnaire LGWR 2 Processus Serveur Fichiers de données Fichiers de contrôles Processus Utilisateur © [email protected] Fichiers Redo Traitement des COMMIT INSTANCE Shared Pool Buffer de données Buffer Redo log Library Cache Cache du dictionnaire LGWR Processus Serveur 3 Fichiers de données Fichiers de contrôles Processus Utilisateur © [email protected] Fichiers Redo Traitement des COMMIT INSTANCE Shared Pool 4 Buffer de données Buffer Redo log Library Cache Cache du dictionnaire LGWR Processus Serveur Fichiers de données Fichiers de contrôles Processus Utilisateur © [email protected] Fichiers Redo Traitement des COMMIT INSTANCE Shared Pool Buffer de données 5 Buffer Redo log Library Cache Cache du dictionnaire LGWR Processus Serveur Fichiers de données Fichiers de contrôles Processus Utilisateur © [email protected] Fichiers Redo Architecture Une BDD Oracle Représente les structures physiques et logiques et se compose des fichiers du OS Est identifée par DB_Name au niveau du OS Une instance Est un moyen d'accéder à une base de données Oracle Ouvre toujours une seule et unique base de données Identifié par Oracle_SID au niveau du OS © [email protected] Une BDD Oracle La structure physique Fichiers de contrôles Fichiers redo log Fichiers de données La structure logique Tablespaces Segments Extents Blocs de données © [email protected] Structure logique Oracle Système d'exploitation BDD Oracle TableSpace Fichier de données Segment Extent Bloc Oracle Bloc OS © [email protected] Structure logique TableSpace Une BDD Oracle est divisée en plus petites zones logiques nommées tablespaces Un Tablespace ne peut appartenir qu’à une seule BDD Chaque Tablespace est constitué d’un ou plusieurs fichiers de données stockés sur disque Un fichier ne peut appartenir qu’à un seul Tablespace à la fois Une fois un fichier ajouté à un Tablespace, on ne peut plus le retirer ou l’associer à un autre Tablespace © [email protected] Structure logique Table Table Tablespace IQ2 Tablespace System Fichier de données Fichier de données Fichier de données Table Tablespace Users Fichier de données © [email protected] Fichier de données Structure logique TableSpace Chaque BDD possède au moins un Tablespace appelé « system » Contenant les tables du dictionnaire de données On peut ajouter des Tablespaces supplémentaires pour grouper des utilisateurs ou des applications Tablespace user contient les tables des utilisateurs TableSpace IQ2 contient les tables des étudiants en IQ2 Un Tablespace peut être physiquement sur un autre disque © [email protected] Structure logique Visibilité des tablespaces Chaque utilisateur possède : Un tablespace par défaut : – Est celui dans lequel les tables de l'utilisateur seront créées de façon privilégiée Un tablespace temporaire – Utilisé pour les tris et en cas d’insuffisance en mémoire centrale © [email protected] Structure logique Intérêts de plusieurs tablespaces spécialisés : Distribuer les E/S en fonction des applications Gérer les quotas utilisateurs Passer un tablespace OFFLINE sans perturber les autres tablespaces Mieux utiliser les supports de stockage Distribuer les index et les données sur des supports différents pour une meilleure fluidité © [email protected] Structure logique Extent Ensemble contiguë de blocs de données alloués simultanément à un segment Segment Tout segment est créé avec au moins un extent (Initialextent) Lorsqu’un segment est plein, attribution d’un nouveau extent © [email protected] Structure logique Les types de segments dans un tablespace : Segments de données Stockent les données. Chaque table a un et un seul segment qui contient toutes les données de la table. Créé automatiquement Segments d’index Stockent les infos sur les index séparément de données. Créés lors de la création d’un index Segment d’amorçage Créé dans le Tablespace SYSTEM, contient les définitions du dictionnaire de données © [email protected] Structure logique Les types de segments dans un tablespace : Segments temporaires Pour exécution des requêtes nécessitant de l’espace disque temporaire Sont crées et détruits automatiquement par des ordres SQL ayant besoin d’espace temporaire une requête qui contient les trois clauses DISTINCT, GROUP BY et ORDER sont « gourmandes » en espace temporaire © [email protected] Structure logique Les types de segments dans un tablespace : Segments d’annulation (RollBack) Enregistrent les actions, et les données avant modification Ne sont utilisables que pour les objets du Tablespace SYSTEM Seul un segment ROLLBACK qui n’est pas en cours d'utilisation peut être détruit © [email protected] Structure logique Blocs de données Plus petite unité logique La taille d’un bloc peut être choisie au moment de l’initialisation d’une base. Elle correspond obligatoirement à un multiple de la taille des blocs du système d’exploitation. Exemple, un bloc dans un système comme Linux occupe 1024 octets, et un bloc ORACLE occupe typiquement 4 096 ou 8 092 octets. © [email protected] Structure logique BLOCS , EXTENSIONS ET SEGMENTS SEGMENT (128 K) EXTENT (32 K) EXTENT (32 K) Bloc de 4K © [email protected] Structure logique Les objets d'une BDD Oracle Table : contient les données d’une BDD Index : structure contenant l’adresse physique de chaque ligne d’une table ou d’un cluster. Accès direct à l’information. Vue : représentation logique de données issues d’une combinaison d’une ou plusieurs tables ou vues Synonyme : Attribution de plusieurs noms à un même objet Séquence : générateur d’entiers uniques © [email protected] Structure logique Les objets d'une BDD Oracle Les clusters : permettent d'établir un groupement de tables qui ont des colonnes communes pour accès rapide aux lignes issues d’une jointure Procédure : ensemble de commandes (écrites en PL/SQL, SQL, C, Java, etc.) stockées dans la BDD Fonction : ensemble de commandes (écrites en PL/SQL, SQL, C, Java, etc.) qui retourne une valeur Package : collection de fonctions et procédures (privé et public) Déclencheur (Trigger) : procédures associées à un événement sur une table © [email protected] Structure logique Les objets d'une BDD Oracle Source et classe Java Tableaux (VARRAY) Schéma XML © [email protected] Structure logique © [email protected]
