Objectifs

Ce chapitre présente l'architecture d'un serveur de base de données Oracle. Il décrit les
structures physiques et logiques, et les différents composants de l'architecture.
Architecture d'un serveur de base de données Oracle : Présentation
Un serveur de base de données Oracle se compose d'une base Oracle, et d'une ou de
plusieurs instances de base de données. Une instance se compose de structures mémoire et
de processus en arrière-plan (BGP – Background Process). Chaque fois qu'une instance est
démarrée, une zone de mémoire partagée appelée mémoire SGA (System Global Area) est
allouée et les processus en arrière-plan sont démarrés.
La mémoire SGA contient les données et les informations de contrôle relatives à une instance
de base de données Oracle.
Les processus en arrière-plan regroupent des fonctions qui, sinon, seraient prises en charge
par plusieurs programmes de serveur de base de données Oracle exécutés pour chaque
processus utilisateur. Ils peuvent exécuter des entrées/sorties (E/S) de manière asynchrone et
contrôlent les autres processus de base de données Oracle. Cela accroît le parallélisme et
permet d'obtenir de meilleures performances et une plus grande fiabilité.
La base de données se compose de fichiers physiques et de structures logiques qui seront
présentés ultérieurement dans ce chapitre. Comme les structures physiques et logiques sont
distinctes, il est possible de gérer le stockage physique des données sans incidence sur les
structures de stockage logique.
Remarque : Oracle RAC (Real Application Clusters) est un environnement comprenant au
moins deux instances de base de données Oracle exécutées sur plusieurs ordinateurs en
clusters qui communiquent entre eux à l'aide d'une interconnexion entre noeuds et
accèdent à la même base Oracle.
Connexion à une instance de base de données
Lorsque les utilisateurs se connectent à un serveur de base de données Oracle, ils sont
connectés à une instance de base de données Oracle. Pour gérer les utilisateurs, l'instance
alloue d'autres zones de mémoire en plus de la mémoire SGA. Par ailleurs, elle démarre
d'autres processus en plus des processus en arrière-plan de la base de données Oracle :
• Des processus utilisateur, parfois appelés processus client ou processus en avant-plan,
sont créés pour exécuter le code logiciel d'une application. Dans la plupart des
environnements, ils sont exécutés sur des machines distinctes. Les processus utilisateur
gèrent les communications avec les processus serveur correspondants via une interface.
• Le serveur de base de données Oracle crée des processus serveur pour prendre en
charge les demandes des processus utilisateur connectés. Un processus serveur
communique avec un processus utilisateur. Il interagit avec l'instance et la base de
données pour traiter les demandes du processus utilisateur associé.
Une instance de base de données Oracle peut être configurée pour permettre la variation du
nombre de processus utilisateur correspondant à chaque processus serveur. Dans une
configuration avec serveur dédié, le processus serveur prend en charge les demandes d'un
seul processus utilisateur.
Dans une configuration avec serveur partagé, de nombreux processus utilisateur peuvent
partager un petit nombre de processus serveur partagés. Cela réduit le nombre de processus
serveur et optimise l'utilisation des ressources système disponibles. Un ou plusieurs processus
répartiteur sont alors utilisés pour mettre en file d'attente les demandes de processus utilisateur
dans la mémoire SGA et sortir les réponses du serveur partagé de la file d'attente.
Structures mémoire d'une base de données Oracle : Présentation
La base de données Oracle alloue les structures mémoire pour des objectifs divers. Par
exemple, la mémoire sert au stockage du code du programme qui est exécuté, des données
partagées entre les utilisateurs et des zones de données privées correspondant à chaque
utilisateur connecté. Les deux structures mémoire de base associées à une instance sont les
suivantes :
• Mémoire SGA (System Global Area) : Elle est partagée par l'ensemble des processus
serveur et des processus en arrière-plan. Elle contient les structures de données
suivantes :
- Cache de tampons (buffer cache) de la base de données : Il sert à la mise en
mémoire cache des blocs de données extraits des fichiers de base de données.
- Tampon de journalisation (redo log buffer) : Il sert à la mise en mémoire cache
des informations de récupération avant leur écriture dans les fichiers physiques.
- Zone de mémoire partagée : Elle sert à la mise en mémoire cache des différentes
structures pouvant être partagées par les sessions.
- Zone de mémoire LARGE POOL : Zone facultative utilisée pour certaines
opérations, telles que la sauvegarde et la restauration Oracle et les processus
serveur d'E/S.
- Zone de mémoire Java : Zone utilisée pour le code Java propre à la session et
pour les données de la Java Virtual Machine (JVM).
 - Zone de mémoire Streams : Zone utilisée par Oracle Streams pour le
stockage des informations sur les processus de capture et d'application des
modifications.
• Mémoires PGA (Program Global Areas) : Zones de mémoire qui contiennent
des données et des informations de contrôle relatives à un processus serveur ou
un processus en arrière-plan particulier. La mémoire PGA est allouée à partir de
la zone de mémoire PGA agrégée.
Cache de tampons de la base de données
Le cache de tampons (buffer cache) de la base de données est la partie de la mémoire SGA
qui contient des copies des blocs de données lus à partir des fichiers de données. Tous les
utilisateurs connectés simultanément à une instance partagent l'accès au cache de tampons de
la base.
Un processus serveur de base de données Oracle effectue une recherche dans le cache de
tampons lorsqu'il a besoin de données particulières. S'il trouve les données dans le cache
(succès en mémoire cache), il peut les lire directement à partir de la mémoire. S'il ne les trouve
pas (échec en mémoire cache), il doit extraire le bloc approprié d'un fichier de données se
trouvant sur le disque et le copier dans un tampon du cache afin de pouvoir accéder aux
données. L'accès aux données est plus rapide en cas de succès en mémoire cache.
Les tampons du cache sont gérés à l'aide d'un algorithme complexe qui utilise une
combinaison de listes LRU (Least Recently Used) et de nombre d'accès (touch count). Les
processus DBWn (Database Writer) sont chargés d'écrire sur le disque les tampons qui ont été
modifiés dans le cache de tampons de la base (tampons "dirty") lorsque cela est nécessaire.
Tampon de journalisation
Le tampon de journalisation (redo log buffer) est une mémoire tampon réutilisable incluse dans
la mémoire SGA qui contient des informations relatives aux modifications effectuées dans la
base. Ces informations sont stockées sous la forme d'entrées de journalisation. Les entrées de
journalisation contiennent les informations nécessaires pour reproduire les modifications
apportées à la base de données via des opérations INSERT, UPDATE, DELETE, CREATE,
ALTER ou DROP. Les entrées de journalisation sont utilisées pour la récupération de la base de
données, si nécessaire.
Elles sont copiées par les processus serveur de base de données Oracle depuis l'espace
mémoire de l'utilisateur vers le tampon de journalisation situé dans la mémoire SGA. Les
entrées de journalisation occupent un espace continu et séquentiel dans le tampon. Le
processus LGWR (Log Writer) en arrière-plan écrit le tampon de journalisation dans le fichier de
journalisation (fichier redo log) ou dans le groupe de fichiers de journalisation actif sur le
disque. LGWR est un processus en arrière-plan capable d'effectuer des E/S asynchrones.
Remarque : En fonction du nombre de CPU dans votre système, il peut y avoir plusieurs
tampons de journalisation, dont l'allocation est automatique.
Zone de mémoire partagée
La partie zone de mémoire partagée de la mémoire SGA contient les éléments principaux
suivants :
• Le cache "library" comprend les parties qui peuvent être partagées des instructions SQL,
des procédures et des packages PL/SQL. Il contient également des structures de contrôle
telles que des verrous externes (locks).
• Le dictionnaire de données est une collection de tables de base de données contenant
des informations de référence relatives à la base. Il est si souvent utilisé par la base
Oracle que deux emplacements sont définis spécialement dans la mémoire pour le
contenir. La première zone est le cache du dictionnaire de données, également appelé
cache de lignes (row cache), et la seconde est le cache "library". Tous les processus
serveur de la base de données Oracle partagent ces deux caches pour accéder aux
informations du dictionnaire de données.
• Le cache de résultats se compose du cache de résultats des instructions SQL et du
cache de résultats des fonctions PL/SQL. Il sert au stockage des résultats des
instructions SQL et des fonctions PL/SQL pour accélérer leurs exécutions ultérieures.
• Les structures de contrôle sont essentiellement des structures de verrous externes.
Remarque : En général, les éléments de la zone de mémoire partagée sont conservés jusqu'à
ce qu'ils soient éliminés en fonction d'un algorithme LRU (Least Recently Used) modifié.
Traitement d'une instruction LMD : Exemple
Les étapes intervenant dans l'exécution d'une instruction LMD (Langage de manipulation de
données) sont les suivantes :
1. Le processus serveur reçoit l'instruction et recherche dans le cache "library" une zone
SQL partagée contenant une instruction SQL similaire. S'il trouve une telle zone, il vérifie
les privilèges d'accès de l'utilisateur aux données demandées et utilise cette zone pour
traiter l'instruction. Dans le cas contraire, une nouvelle zone SQL partagée est allouée
pour l'instruction pour qu'elle puisse être analysée (parsed) et traitée.
2. Si les blocs de données et les blocs de segments d'annulation ne figurent pas encore
dans le cache de tampons (buffer cache), le processus serveur les lit à partir des fichiers
de données et les place dans le cache de tampons. Le processus serveur verrouille les
lignes à modifier.
3. Le processus serveur enregistre les modifications à apporter aux tampons de données,
ainsi que les modifications d'annulation (undo). Ces modifications sont écrites dans le
tampon de journalisation (redo log buffer) avant la modification des tampons de données
et de segments d'annulation en mémoire. Cette opération est appelée journalisation à
écriture anticipée.
4. Les tampons de segments d'annulation contiennent les valeurs des données avant leur
modification. Ils sont utilisés pour stocker l'image "avant" des données afin que les
instructions LMD puissent être annulées si nécessaire. Les tampons de données
enregistrent les nouvelles valeurs des données.
Traitement des opérations COMMIT : Exemple
Lors d'une opération COMMIT, les étapes suivantes sont exécutées :
1. Le processus serveur place un enregistrement de validation (commit) et le numéro SCN
(System Change Number) dans le tampon de journalisation (redo log buffer). Ce numéro,
incrémenté à chaque fois, est unique dans la base de données. Il est utilisé en tant
qu'horodatage interne pour synchroniser les données et assurer la cohérence en lecture
lorsque les données sont extraites des fichiers de données. Il permet à la base d'effectuer
des vérifications de cohérence sans avoir à se fonder sur la date et l'heure du système
d'exploitation.
2. Le processus LGWR en arrière-plan écrit toutes les entrées du tampon de journalisation
jusqu'à l'enregistrement de validation inclus dans les fichiers de journalisation (redo log
files), de manière contiguë. A ce stade, la base de données Oracle peut garantir que les
modifications ne seront pas perdues en cas d'échec de l'instance.
3. Si les blocs modifiés se trouvent toujours dans la mémoire SGA et si aucune autre
session ne les modifie, la base de données supprime de ces blocs les informations
relatives aux transactions de verrouillage. Il s'agit là du processus de nettoyage des blocs
validés.
4. Le processus serveur fournit au processus utilisateur des informations sur la fin de la
transaction.
Remarque : Enfin, si cela n'est pas déjà fait, le processus DBWn écrit les modifications sur le
disque en fonction de son propre mécanisme de synchronisation interne.
Zone de mémoire LARGE POOL
Vous pouvez configurer une zone de mémoire facultative nommée LARGE POOL qui permet
d'allouer des espaces de mémoire volumineux pour les éléments suivants :
• Mémoire allouée par session (session memory) pour le serveur partagé, l'interface Oracle
XA (utilisée lorsque les transactions interagissent avec plusieurs bases de données) ou
les tampons d'exécution en parallèle.
• Processus serveur d'E/S
• Opérations de sauvegarde et de restauration de la base de données Oracle.
Lorsque ces éléments sont alloués à partir de la zone de mémoire LARGE POOL, la base
Oracle peut utiliser la mémoire partagée principalement pour la mise en cache des parties
partagées des structures SQL et PL/SQL. A l'origine, la mémoire partagée était conçue pour le
stockage des structures SQL et PL/SQL. L'utilisation de la zone de mémoire LARGE POOL
permet d'éviter les problèmes de fragmentation liés au partage d'une même zone de mémoire
entre des allocations d'espaces de petite taille et de grande taille. Contrairement à la zone de
mémoire partagée, la zone de mémoire LARGE POOL n'a pas de liste LRU (Least Recently
Used).
Il est conseillé de configurer une zone de mémoire LARGE POOL si votre instance utilise un
des mécanismes suivants :
• Exécution en parallèle : Parallel Query utilise la zone de mémoire partagée pour la mise
en mémoire cache des tampons d'exécution en parallèle.
• Recovery Manager : Recovery Manager utilise la zone de mémoire partagée pour la
 mise en mémoire cache des tampons d'E/S pendant les opérations de
sauvegarde et de restauration.
• Serveur partagé : Dans une architecture avec serveur partagé, la mémoire
allouée par session (session memory) pour chaque processus client est comprise
dans la zone de mémoire partagée.
Zones de mémoire Java et Streams
La zone de mémoire Java est utilisée pour tout le code Java propre à la session et pour toutes
les données de la Java Virtual Machine (JVM). Elle est utilisée de différentes manières, selon
le mode d'exécution de la base de données Oracle.
Oracle Streams permet de propager et de gérer les données, les transactions et les
événements inclus dans un flux de données au sein d'une base ou entre deux bases. La zone
de mémoire Streams est utilisée exclusivement par Oracle Streams. Elle sert au stockage des
messages dans une file d'attente tampon et fournit de la mémoire aux processus de capture et
de traitement d'Oracle Streams.
Remarque : L'étude détaillée de la programmation Java et d'Oracle Streams n'entre pas dans
le cadre de ce cours.
Mémoire PGA (Program Global Area)
La mémoire PGA est comparable à un espace de travail temporaire que le responsable des
fichiers (le processus serveur) exploite pour exécuter une fonction au nom d'un client (le
processus client). L'agent nettoie une zone de l'espace de travail et y enregistre les
informations relatives à la demande du client, puis il relibère cette zone une fois la demande
traitée.
En général, la mémoire PGA comprend les zones suivantes :
• La mémoire allouée par session (session memory) est destinée au stockage des
variables d'une session (informations de connexion) et d'autres informations associées.
Pour un serveur partagé, cette mémoire est partagée (et non privée).
• Les curseurs sont des pointeurs vers des structures mémoire privées d'instructions SQL
particulières.
• Les zones de travail d'exécution du code SQL sont allouées pour prendre en charge les
opérations consommatrices de mémoire telles que celles répertoriées dans la diapositive
ci-dessus. En règle générale, l'utilisation de zones de travail volumineuses améliore
considérablement les performances de ces opérations, mais au prix d'une consommation
de mémoire importante.
Processus en arrière-plan
Les environnements autres que RAC ou ASM comprennent généralement les processus en
arrière-plan suivants :
• Le processus Database Writer (DBWn) écrit de manière asynchrone sur le disque les
tampons modifiés ("dirty") figurant dans le cache de tampons (buffer cache) de la base de
données.
• Le processus Log Writer (LGWR) écrit dans un fichier de journalisation (fichier redo log)
situé sur le disque les informations de récupération (ou informations de journalisation)
figurant dans le tampon de journalisation.
• Le processus de point de reprise (CKPT) enregistre les informations relatives au point
de reprise dans les fichiers de contrôle et dans chaque en-tête de fichier de données.
• Le processus System Monitor (SMON) effectue la récupération au démarrage de
l'instance et nettoie les segments temporaires non utilisés.
• Le processus Process Monitor (PMON) effectue une récupération en cas d'échec d'un
processus utilisateur.
• Le processus en arrière-plan du cache de résultats (RCBG) sert à gérer le cache de
résultats dans la zone de mémoire partagée.
Gestion automatique de la mémoire partagée
Vous pouvez utiliser la fonction de gestion automatique de la mémoire partagée (ASMM -
Automatic Shared Memory Management) pour permettre à la base de données de définir
automatiquement la taille de chacun des composants de mémoire, dans la limite de la taille
totale de la mémoire SGA.
Le système utilise un paramètre définissant la taille de la mémoire SGA (SGA_TARGET) qui
prend en compte toute la mémoire figurant dans la zone SGA, y compris les composants
dimensionnés automatiquement, les composants dimensionnés manuellement et les
allocations internes effectuées lors du démarrage. La fonctionnalité ASMM simplifie la
configuration de la mémoire SGA en vous permettant d'indiquer une quantité de mémoire totale
à utiliser pour l'ensemble des composants SGA. La base de données Oracle modifie
périodiquement la répartition de l'espace entre les composants réglés automatiquement en
fonction des exigences liées à la charge globale.
Remarque : Vous devez affecter la valeur TYPICAL ou ALL à STATISTICS_LEVEL pour
utiliser la fonctionnalité ASMM.
Gestion automatique de la mémoire d'exécution du code SQL
Cette fonctionnalité permet d'allouer automatiquement de la mémoire aux zones de travail dans
la mémoire PGA. Vous pouvez utiliser le paramètre PGA_AGGREGATE_TARGET pour indiquer
la quantité totale de mémoire à allouer aux zones de mémoire PGA des sessions de l'instance.
En mode automatique, les zones de travail utilisées par les opérateurs consommateurs de
mémoire (tris et jointures de hachage (hash joins)) peuvent être ajustées automatiquement et
dynamiquement.
Cette fonctionnalité offre plusieurs avantages sur le plan des performances et de l'évolutivité
pour les charges globales des systèmes d'aide à la décision ou les charges hétérogènes avec
interrogations complexes. Les performances globales du système sont poussées au maximum
et la mémoire disponible est allouée de façon plus efficace entre les interrogations, afin
d'optimiser à la fois le débit et le temps de réponse. Les gains découlant d'une meilleure
utilisation de la mémoire se traduisent notamment par un débit plus important lorsque la charge
est élevée.
Remarque : Dans les versions antérieures du serveur de base de données Oracle, vous
deviez définir manuellement la taille maximale de la zone de travail pour les différents types
d'opération SQL tels que les tris et les jointures de hachage. Cela était très difficile car la
charge globale change constamment. Même si la version actuelle de la base de données
Oracle permet la gestion manuelle de la mémoire PGA, qui peut s'avérer utile pour des
sessions particulières, il est conseillé de laisser la gestion automatique de la mémoire PGA
activée.
Gestion automatique de la mémoire
Comme indiqué précédemment, la taille des différentes zones de mémoire de l'instance influe
directement sur la vitesse du traitement des instructions SQL. Selon la charge globale de la
base de données, il est difficile de dimensionner ces composants manuellement.
Avec la gestion automatique de la mémoire, le système adapte automatiquement la taille de
chaque composant de la mémoire aux besoins en mémoire correspondant à votre charge
globale.
Vous affectez une valeur au paramètre d'initialisation MEMORY_TARGET pour l'instance de base
de données et le processus en arrière-plan MMAN effectue automatiquement un réglage en
fonction de la taille de mémoire cible. Il redistribue la mémoire de manière appropriée entre les
composants internes de la mémoire SGA, ainsi qu'entre la mémoire SGA et les zones de
mémoire PGA agrégées.
La fonctionnalité de gestion automatique de la mémoire partagée utilise le gestionnaire de
mémoire SGA qui est implémenté via deux processus en arrière-plan, Manageability Monitor
(MMON) et Memory Manager (MMAN). Des statistiques et des données de conseil relatives à
la mémoire sont saisies de manière périodique en mémoire par le processus MMON. Le
processus MMAN coordonne le dimensionnement des composants de mémoire en fonction
des décisions du processus MMON.
Remarque : Actuellement, ce mécanisme est implémenté seulement sous Linux, Solaris, HP-
UX, AIX et Windows.
Architecture de stockage dans la base de données
Les fichiers constituant une base de données Oracle sont organisés de la manière suivante :
• Fichiers de contrôle : Ils contiennent des informations sur la base de données (c'est-à-
dire les informations sur sa structure physique). Ces fichiers sont essentiels à la base.
Sans eux, vous ne pouvez pas ouvrir de fichiers de données pour accéder aux données
contenues dans la base.
• Fichiers de données : Ils contiennent les données d'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 : Ils permettent de récupérer la base de données en
cas d'échec de l'instance. Si le serveur de base de données tombe en panne sans perdre
de fichiers de données, l'instance peut restaurer la base grâce aux informations de ces
fichiers.
Les fichiers supplémentaires suivants sont importants pour la réussite de l'exécution de la base
de données :
• Fichier de paramètres : Il est utilisé pour définir la configuration de l'instance au
démarrage.
• Fichier de mots de passe : Il permet aux utilisateurs sysdba, sysoper et sysasm de
se connecter à distance à la base de données et d'effectuer des tâches d'administration.
• Fichiers de sauvegarde : Ils sont utilisés pour la récupération de la base de données.
Un fichier de sauvegarde est généralement restauré en cas de panne ou lorsqu'une
erreur d'un utilisateur a endommagé ou supprimé un fichier d'origine.
• Fichiers de journalisation archivés : Ils contiennent un historique mis à jour en
permanence des modifications de données (informations de journalisation) qui sont
générées par l'instance. A partir de ces fichiers et d'une sauvegarde de la base,
vous pouvez récupérer un fichier de données perdu. En d'autres termes, les
fichiers de journalisation archivés permettent la récupération de fichiers de
données restaurés.
Structures logiques et physiques de la base de données
La base de données comprend des structures logiques et des structures physiques.
Tablespaces
Une base de données est divisée en unités de stockage appelées tablespaces, qui regroupent
des structures logiques liées. Par exemple, les tablespaces regroupent généralement tous les
objets d'une application pour simplifier certaines opérations d'administration. Il peut y avoir un
tablespace pour différentes applications.
Bases de données, tablespaces et fichiers de données
La diapositive ci-dessus propose une illustration des relations entre les bases de données, les
tablespaces et les fichiers de données. Chaque base de données est divisée de manière
logique en un ou plusieurs tablespaces. Un ou plusieurs fichiers de données sont explicitement
créés pour chaque tablespace afin de stocker physiquement les données de toutes les
structures logiques temporaires. S'il s'agit d'un tablespace TEMPORARY, au lieu d'un
tablespace contenant des données, le tablespace dispose d'un fichier temporaire.
Segments, extents et blocs
Les objets de base de données, tels que les tables et les index, sont stockés dans les
tablespaces sous forme de segments. Chaque segment contient un ou plusieurs extents
(ensembles de blocs contigus). Un extent est constitué de blocs de données contigus, ce qui
signifie que chaque extent ne peut se trouver que dans un seul fichier de données. Les blocs
de données constituent la plus petite unité d'E/S de la base.
Lorsque la base demande un ensemble de blocs de données au système d'exploitation, ce
dernier le met en correspondance avec un bloc réel du système de fichiers ou du disque sur le
périphérique de stockage. Par conséquent, vous n'avez pas besoin de connaître l'adresse
physique des données de la base. Cela signifie également qu'un fichier de données peut être
réparti ou mis en miroir sur plusieurs disques.
La taille du bloc de données peut être définie lors de la création de la base. La taille par défaut
(8 ko) est adaptée à la plupart des bases de données. Toutefois, si votre base de données
prend en charge une application de data warehouse qui comporte des tables et des index
volumineux, il peut être judicieux de définir une taille de bloc plus importante.
Si votre base de données prend en charge une application transactionnelle dans laquelle les
lectures et les écritures sont aléatoires, il peut s'avérer préférable de définir une taille de bloc
inférieure. La taille maximale des blocs dépend du système d'exploitation utilisé. La taille
minimale des blocs Oracle est de 2 ko, mais cette taille ne doit être que rarement (voire jamais)
utilisée.
Vous pouvez utiliser des tablespaces avec une taille de bloc non standard. Pour plus
d'informations, reportez-vous au manuel Oracle Database Administrator's Guide.
Tablespaces SYSTEM et SYSAUX
Chaque base de données Oracle contient obligatoirement un tablespace SYSTEM et un
tablespace SYSAUX, qui sont créés automatiquement en même temps que la base. Par défaut,
le système crée un tablespace smallfile. Vous pouvez également créer des tablespaces bigfile
pour permettre à la base de données Oracle de gérer des fichiers très volumineux (jusqu'à
8 exaoctets).
Un tablespace peut être en ligne (accessible) ou hors ligne (non accessible). Le tablespace
SYSTEM reste toujours en ligne lorsque la base de données est ouverte. Il sert au stockage des
tables qui prennent en charge les fonctionnalités principales de la base de données, telles que
les tables du dictionnaire de données.
SYSAUX est un tablespace auxiliaire du tablespace SYSTEM. Il sert au stockage de nombreux
composants de base de données. Il doit être en ligne pour que tous les composants de la base
fonctionnent correctement.
Remarque : Le tablespace SYSAUX peut être mis hors ligne pour effectuer une récupération,
alors que cela n'est pas possible pour le tablespace SYSTEM. Ni l'un ni l'autre ne peut être
placé en lecture seule.
Réponse : a
Réponse : b
Réponse : b