Instance de Base

Voici, la magnifique architecture de base de données Oracle, une multitude

de composants individuels fonctionnant en tandem pour permettre à une base de
données Oracle d'être une base de données vous permettant de lire et d'écrire des
données de manière sûre, rapide, évolutif et sécurisé. L'architecture de la base de
données Oracle peut être divisée en trois composants principaux. Commençons par
jeter un coup d'œil sur l'architecture d'Oracle et dresser la liste des trois principaux
composants de notre base de données Oracle.
Notre premier composant est l'instance Oracle. Notre deuxième composant est le
stockage de la base de données Oracle. Et notre troisième composant sont
les processus du serveur Oracle , ou SP. Commençons par en parler un peu plus sur
l'instance Oracle, qui est essentiellement le programme Oracle, ou binaire, chargé
dans la RAM du serveur. Il existe seulement en mémoire, et créé par Oracle chaque
fois que vous démarrez votre base de données. Créé, vous dites? Oui, il est non
persistant et disparaît chaque fois que la base de données redémarre.
Qu'est ce que ça fait? Eh bien, il contient des zones spéciales utilisées pour mettre
en cache des données très importantes ainsi que des métadonnées en
mémoire. Note de côté rapide, quelles sont les métadonnées, demandez-vous? Eh
bien, ce sont des données qui décrivent d'autres données. Par exemple, nous
pouvons avoir une table d' employés stockant des rangées d'employés, c'est-à-dire
nos données réelles. La structure de la table et de sa colonne est également connue
sous le nom de métadonnées. Bon, revenons au sujet de l'instance Oracle.
Nous avons parlé de l'instance Oracle qui met en cache les données et les
métadonnées fréquemment utilisées en mémoire. Alors pourquoi avons-nous besoin
de mettre les données en cache dans la mémoire en premier lieu? Parce que la
lecture de la mémoire est beaucoup plus rapide par rapport à la lecture à partir du
disque. Il est judicieux de stocker en mémoire les données fréquemment
consultées afin qu'après la première session de base de données, les données du
disque soient lues, elles seront mises en cache, de sorte que les sessions
suivantes demandant les mêmes données ou métadonnées amélioreront
considérablement les performances en lecture. .
Mais attendez, la mise en cache des données et des métadonnées en mémoire n'est
pas tout ce que fait l'instance Oracle. Il comprend également un ensemble de
processus s'exécutant en arrière-plan qui sont appelés, vous l'avez deviné, des
processus d'arrière-plan. Ces processus d'arrière-plan fonctionnent en tandem avec
l'instance Oracle dans les caches mémoire que nous venons de décrire pour
effectuer diverses opérations de base de données de routine. Ces opérations
incluent l'écriture de données sur le disque, assurant la cohérence de la base de
données, et plus encore. Vous savez, tout ce que la base de données Oracle doit
faire régulièrement pour être cohérente, bien réglée, opérationnelle et sécurisée.
Ok, c'était l'instance de base de données Oracle. Mais l'instance Oracle seule n'est
pas encore une base de données entièrement fonctionnelle. Rappelez-vous que j'ai
mentionné la nature non persistante de l'instance Oracle, le fait qu'elle soit recréée
en mémoire après le redémarrage de chaque base de données Oracle. Hmm, cela
voudrait dire que les données mises en cache dans l'instance Oracle seront
vaporisées chaque fois que nous redémarrerons notre base de données. Nous allons
le perdre, ce qui donne? Nous voulons que nos données dans notre base de
données soient sûres et sécurisées.
Hmm, peut-être sur le disque quelque part?

Stockage de base
Nous venons d'apprendre sur la nature non persistante de l'instance Oracle. Toutes
les informations chargées dans l'instance Oracle sont effacées chaque fois que nous
redémarrons notre base de données. Cela ne mettrait-il pas vos données en danger,
vous pouvez demander? Oui, mais heureusement pour nous, rendre nos données
cohérentes et sûres est exactement là où la deuxième partie de l'architecture de la
base de données Oracle entre en jeu, le stockage de la base de données Oracle. Le
nom donne à peu près son but: le stockage des données de base de données sur le
disque.
Le stockage de base de données Oracle est essentiellement une collection spéciale
de fichiers Oracle utilisés pour conserver nos données de l'instance Oracle qui est
uniquement en mémoire sur un disque physique. Afin qu'Oracle puisse s'assurer que
tous nos précieux contenus dans notre base de données sont sûrs et
sécurisés, Oracle doit stocker ces données sur un disque quelque part sous la forme
d'un ensemble de fichiers. Ces fichiers de disque constituent notre base de données
physique Oracle.
L'instance Oracle dont nous avons parlé précédemment est seulement une copie du
programme Oracle chargé en mémoire, pas nos données réelles. Une bonne
analogie est les documents Microsoft Word et Microsoft Word. De la même façon
que Microsoft Word est un programme que vous exécutez sur votre ordinateur mais
vos données réelles sont stockées dans des documents Word sur disque, l'instance
Oracle est un programme et le stockage de la base de données est nos
données. Cependant, contrairement à notre analogie avec Microsoft Word, le
stockage de la base de données Oracle est généralement placé sur un système de
stockage super résilient de type entreprise, de type SAN ou NAS .
Si vous ne savez pas ce que signifie NAS ou SAN, ne vous inquiétez pas. Il ne
revient généralement pas à l'administrateur de base de données ou à l'administrateur
de base de données de gérer la configuration réelle du système de stockage utilisé
pour la base de données Oracle. C'est pourquoi vous avez des experts en stockage
dans votre organisation. Vous les avez, non? Mais il appartient au DBA de
demander, ou plus exactement, de demander aux experts en stockage
d'allouer un stockage suffisamment puissant et hautement disponible pour notre
base de données.
Remarque rapide, SAN est synonyme de réseau de stockage qui est le type de
stockage accessible par l'infrastructure Fibre Channel tandis que NAS signifie
stockage en réseau qui est le type de stockage accessible via un
réseau, généralement Ethernet. Les deux types de stockage sont supportés
nativement par Oracle. Le stockage de base de données Oracle peut également être
placé sur un disque local tel que le disque individuel à l' intérieur de votre
ordinateur. Au lieu de connecter votre serveur Oracle à un système de stockage de
niveau entreprise, vous pouvez demander à Oracle de stocker la
base de données sur un lecteur local qui se trouve physiquement dans le serveur
Oracle.
Cependant, ce n'est pas quelque chose que vous voudriez généralement faire dans
un environnement Oracle de production , à moins que vous ne préfériez vous
réveiller à 2h00 du matin et restaurer votre base de données à partir de sauvegardes
en utilisant le disque unique pour le stockage et ce disque a juste échoué. Rappelez-
vous qu'un disque local n'a pas de tolérance de panne intégrée. C'est pourquoi nous
souhaitons placer toutes nos données Oracle sur un système de stockage centralisé,
résilient, hautement disponible, de qualité professionnelle, à ajouter à votre propre
superlatif .
Je l'ai? Protégez vos données Donc, notre point à retenir est, si votre base de
données est perdue, vos données sont perdues, votre base de données est
perdue. Ceci est, bien sûr, contrairement à l'instance Oracle qui, comme nous
l' avons mentionné, mais se répète encore une fois parce que vous savez ce qu'ils
disent, « La répétition fait pour un DBA parfait » , l'instance Oracle est utilisé pour
la mise en cache et le traitement transactionnel est recréée chaque temps que vous
redémarrez votre base de données. Donc, perdre le stockage de la base de données
en raison d'un crash de disque?C’est Très Mal! Vous devez restaurer à partir d'une
sauvegarde.
Bonne chance pour ça. Perdre l'instance Oracle parce que votre serveur de base de
données a planté? Pas de problème. Redémarrez-le et Oracle le rechargera en
mémoire.

Processus Serveur
Êtes-vous avec moi jusqu'à présent? Génial. Maintenant, détournons notre attention
vers la dernière pièce du puzzle Oracle. Le dernier des trois principaux
composants constituant l'architecture de la base de données Oracle. Ce sont les SP
Oracle, ou, dans leur nom complet, les processus serveur. Leur but, simple. Oracle
démarre les processus serveur pour gérer les demandes des processus
clients connectés à la base de données Oracle.
Un processus client, qui est essentiellement un nom sophistiqué pour appeler une
session utilisateur connectée à la base de données, communique toujours via un
processus serveur. Les processus serveur sont créés au nom d'une session qui a
initié la connexion à la base de données Oracle. Ces processus serveur effectuent
une ou plusieurs des tâches suivantes. Le premier rôle des processus serveur est de
transmettre et d'exécuter des instructions SQL émises par la session de connexion.
Ainsi, lorsqu'un utilisateur émet une instruction select, le processus serveur est
responsable de s'assurer que l'instruction select est syntactiquement correcte et de
trouver le meilleur moyen de l'exécuter. Le deuxième rôle du processus serveur
consiste à agir au nom d'une session client qui doit lire des données à partir du
disque. Le processus serveur est responsable de la lecture des données de la base
de données à partir du stockage de la base de données et du chargement de ces
données dans le cache du tampon d'instance Oracle.
Nous parlerons plus en détail du cache tampon dans notre chapitre de plongée
d'instance Oracle plus tard. Pour l'instant, tout ce que vous devez savoir est que le
cache tampon est originaire de la mémoire à l'intérieur de l'instance Oracle utilisée
pour la mise en cache des données récemment accédées. Rappelez-vous qu'Oracle
vise à être une base de données rapide, et l'un des meilleurs moyens d'y
parvenir consiste à mettre en mémoire cache les données fréquemment utilisées afin
de minimiser les débits de disque. En avançant, la troisième règle pour le processus
serveur est de renvoyer les résultats d'une instruction SQL exécutée au client.
Donc, pour résumer, les principales règles et responsabilités des processus serveur
incluent un, ils agissent au nom des sessions client pour transmettre des instructions
SQL, deux, ils lisent les données du disque et le mettent en mémoire cache, trois, ils
retournent les résultats au utilisateur. Simple, non? C'est en fait une approche très
évolutive, avec un processus de serveur dédié qui gère le traitement pour un
utilisateur spécifique.
Plus d'utilisateurs équivaut à plus de processus serveur dédiés. En plus des rôles
des processus serveur que nous venons d'examiner, notez également que chaque
processus serveur possède son propre cache dédié à chaque client connecté. Ce
cache est également connu sous le nom de PGA et représente la zone globale du
programme. Le PGA utilisé par chaque processus serveur est une région de
mémoire non partagée réservée uniquement à la session d’utilisateur
spécifique connectée à ce processus serveur spécifique.
À quoi sert le PGA? Bonne question De manière générale, il contient des données et
des informations de contrôle utilisées par les processus du serveur lors du tri des
données, la réunion de grandes tables dans le cadre d'une instruction SQL,
etc. Essentiellement, les données qui ne devraient pas persister après une session
d'utilisateur ont fini de faire ce qu'il fallait faire. Données temporaires Ceci est en
contraste direct avec les différents autres caches utilisés par l'instance Oracle elle-
même, qui sont partagés entre toutes les sessions de connexion.
Dans la plupart des déploiements Oracle, vous trouverez généralement une relation
un-à-un entre la connexion des sessions utilisateur et les processus serveur. Ainsi,
pour chaque utilisateur connecté à la base de données, vous trouverez également un
processus serveur unique. Ceci est également connu sous le nom de modèle de
processus de serveur dédié Oracle. Pouvez-vous penser à un problème avec cette
approche? Eh bien cette approche pourrait fonctionner si vous avez deux, 10 ou
peut-être 100 utilisateurs connectés à une base de données oracle.
Mais que se passe-t-il si vous avez 100 000 utilisateurs, un million d'utilisateurs qui
ont besoin d'un accès à la base de données? Avoir la base de données Oracle
démarrer un million de processus serveur pour un million de sessions utilisateur n'est
pas très efficace et peut être très exigeant en ressources du serveur Oracle. La
solution? Ce que la plupart des professionnels de la base de données choisissent de
faire est d'introduire un middleware de mise en commun des connexions quelque
part entre les utilisateurs actuels et la base de données elle-même.
Un exemple pour un tel middleware est d' avoir un serveur d'application entre les
sessions utilisateur réel et le serveur de base de données afin que nos millions
d' utilisateurs se connectent à un ou plusieurs serveurs d'applications et ces serveurs
d'applications ouvrira un ensemble fixe de connexions de base de
données, traduisant ainsi en ensemble fixe de processus de serveur de base de
données. Ainsi, dans notre exemple, nous avons beaucoup d'utilisateurs finaux qui
se connectent à un serveur d'applications, mais ce serveur d'applications n'ouvre
que deux connexions à la base de données. La base de données Oracle n'a donc
besoin que de démarrer deux processus serveur.
Très très efficace. Le serveur d'application agit ici comme un pool de connexion pour
les utilisateurs. Il n'est pas très important pour vous de bien comprendre
le fonctionnement de la mise en commun des connexions à ce stade, mais vous
saurez qu'en raison de la relation utilisateur un à un avec la relation de processus
serveur d'Oracle, la mise en commun des connexions est incontournable. en cas de
besoin.

Pools de mémoire d’instance

Zone Globale du system
Dites bonjour à l' Instance Oracle dans toute sa splendeur. Beau, n'est-ce
pas? Auparavant, lors de l'introduction de la fonction de l'instance Oracle, nous la
considérions comme une unité unique servant à mettre en cache les données et à
effectuer les opérations de routine requises pour le traitement transactionnel via un
ensemble de processus d'arrière-plan. Mais cela ne fait que gratter la
surface. L'instance Oracle est en fait plus complexe que cela. Et maintenant il est
temps pour nous de tirer le rideau et de jeter un coup d'œil à l'intérieur.
La première partie de l'instance Oracle que vous devez connaître est appelée
SGA ou zone globale du système. Cela peut sembler un peu déroutant, au
début, mais supporter avec moi, car il y a une logique à la dénomination. Le SGA est
la première partie de l'instance Oracle utilisée pour mettre en cache des données et
des métadonnées en mémoire. La deuxième partie concerne les processus d'arrière-
plan d'Oracle, dont nous parlerons dans notre prochain chapitre. Le SGA est un
groupe de structures de mémoire partagée, connu sous le nom de composants SGA
individuels, utilisés pour mettre en cache les données générées par les
utilisateurs, c'est-à-dire les lignes des tables basées sur les données, ainsi que
diverses autres informations de contrôle .
Le SGA est le nom utilisé pour représenter une collection de caches différents en
mémoire. Le cache tampon, le pool partagé et les autres sont tous des composants
d'un seul SGA. Bien que chacune de ces caches individuelles ait son propre
but, heureusement pour nous, nous n'avons pas à dimensionner
manuellement chacun de ces composants individuellement. Lorsque nous
configurons la base de données, nous allons utiliser quelques paramètres pour
déterminer la taille globale du SGA dans son ensemble.
Ces paramètres sont SGA_MAX_SIZE et SGA_TARGET. Nous définissons une taille
maximale pour l'ensemble du SGA, disons 64 gigaoctets, et c'est à Oracle de
déterminer la quantité de SGA totale qu'il doit allouer pour chaque composant de
mémoire en fonction de la demande et de la disponibilité de la mémoire. Nous
pouvons, bien sûr, passer autre le dimensionnement automatique, si nous préférons.

Piscine Commun
Maintenant, il est temps de jeter un coup d'œil à l'intérieur du SGA et d'obtenir le
prénom avec toutes ces caches individuelles. Commençant avec la piscine
partagée, et non, je ne veux pas dire le même genre de piscine que vous partagez
avec vos collègues vacanciers tout en restant à votre station balnéaire
préférée. Dans un contexte Oracle, le pool partagé est le domaine le plus important à
l'intérieur de la SGA qui est utilisé pour mettre en cache les données non-
utilisateur. Autrement dit, d'autres choses que les lignes de base de données
réelles de nos tables réelles.
Alors, qu'est-ce qu'il y a à cache autre que des lignes, vous pouvez demander? Eh
bien, il existe diverses autres constructions de bases de données qui, si elles sont
partagées entre les utilisateurs, accéléreraient les performances de diverses activités
de base de données. Pour ce faire, le pool partagé, en lui-même, est divisé en un
autre sous-ensemble de caches. S'il vous plaît, supportez avec moi. Je ne veux pas
que tu aies peur. Rappelez-vous la hiérarchie. Nous avons l'instance Oracle. À
l'intérieur, nous avons un composant logique appelé SGA.
Lors de la configuration de la base de données, nous définissons la taille de la
SGA. Comme, je veux que mon SGA, dans son ensemble, occupe 64 gigaoctets de
RAM. À l'intérieur du SGA, nous avons une zone de mémoire appelée Pool partagé
utilisée pour mettre en cache la construction de base de données qui ne sont pas
des lignes réelles de nos tables. Et à l'intérieur du pool partagé, nous avons plusieurs
autres sous-domaines, chacun avec son propre but. Les principaux sont le cache de
dictionnaire de données Oracle et le cache de bibliothèque.
Le cache de dictionnaire de données est une collection de tables et de vues de base
de données gérées par Oracle contenant des informations de référence sur la
structure de la base de données et ses utilisateurs. Fondamentalement, les
métadonnées sur la base de données. Considérez-le comme le lieu de mise en
cache des informations de contrôle essentielles au fonctionnement de la base de
données Oracle. La base de données Oracle accède fréquemment au dictionnaire de
données. Plus précisément, chaque fois qu'un utilisateur exécute une requête de
suite, de nombreuses métadonnées sont nécessaires pour qu'une suite de requête
s'exécute correctement.
Les métadonnées, telles que les informations d'intégrité référentielle, les définitions
et la structure des tables, les informations d'annexe, etc. Maintenant, alors que ces
données sont également stockées sur ce dernier dans le cadre de l'espace de table
système Oracle, plus sur cela plus tard, Oracle met également ces données en
mémoire cache pour améliorer les performances. C'est là que le cache de
dictionnaire de données entre en jeu. Se déplaçant le long! Le cache de la
bibliothèque est une autre zone à l'intérieur d'un pool partagé.
Oracle utilise le cache de bibliothèque pour stocker les informations mises en
cache sur chaque instruction de suite exécutée. Pourquoi voudriez-vous faire
ça? Simple. Lorsque vous exécutez une instruction de suite, la base de données
Oracle a beaucoup de travail à faire. Avant même de commencer
à exécuter l'instruction elle - même, il doit analyser l'instruction, créer ce qu'on
appelle un plan d'exécution, ce qui est fondamentalement la façon dont la base
de données Oracle détermine la meilleure façon de récupérer les données requises
par la déclaration de suite, par exemple comme quels index utiliser.
Ce processus d'analyse peut prendre un peu de temps. Combien de temps? Eh bien,
généralement quelques secondes par déclaration de suite, mais quand beaucoup
d'utilisateurs exécutent beaucoup d'instructions de suite en parallèle, cela peut
représenter beaucoup de travail de CPU pour une base de données. Oracle, étant
une base de données efficace et tous, va essayer de mettre en cache l'état analysé
de l'instruction suite en mémoire de sorte que ces deux utilisateurs exécutent la
même instruction de suite.
L'analyse complète de la suite ne doit avoir lieu qu'une seule fois. Seulement quand
le premier utilisateur a exécuté une déclaration de suite. La première exécution d'une
instruction suite à une suite est connue sous le nom d'analyse syntaxique, et elle est
considérée comme l'analyse la plus exigeante en ressources qui puisse se produire
pour n'importe quelle instruction de suite donnée. Les exécutions ultérieures de la
même suite, en supposant qu'elle soit identique, même lorsqu'elles proviennent
d'utilisateurs différents, peuvent utiliser la présentation déjà analysée de l'instruction
suite conservée en mémoire.
Où? Tu l'as deviné. À l'intérieur du cache de la bibliothèque. Ceci est connu comme
une analyse douce, et il est considéré comme un événement beaucoup plus léger et
beaucoup moins exigeant en termes de ressources . Le deuxième utilisateur pourra
utiliser la version déjà analysée de l'instruction suite conservée en mémoire. Vous
serez surpris de constater à quel point les performances de la base de
données peuvent être améliorées lorsqu'une déclaration de suite passe à une
analyse par défaut, comparée à une analyse syntaxique stricte.
Surtout quand vous considérez une base de données de production avec des
centaines ou des milliers d'exécutions de suites chaque seconde. Cela prend
beaucoup de temps. Tu sais ce que je dis. Chaque centime va un long chemin. Cela
complète les principaux composants du pool partagé Oracle contenu dans le
SGA. Ceux-ci étaient le cache de dictionnaire de données et le cache de
bibliothèque. Il y a quelques caches supplémentaires dans le pool partagé, mais ils
ne sont pas aussi importants du point de vue du cours d'introduction, et nous n'en
discuterons pas aujourd'hui.

Cache de mémoire tampon

Se déplaçant avec notre grand tour du SGA, maintenant il est temps de parler du
cache de tampon de base de données. À côté de la piscine partagée, c'est l'une
des composantes les plus importantes de la SGA. Contrairement au pool partagé,
qui met en cache les instructions SQL analysées et les données de méthode de base
de données, le cache tampon est responsable de la mise en cache des données
utilisateur de la base de données. Lignes à partir des tables. Pourquoi? Comme
toujours, performance, performance, performance.
Lorsqu'un utilisateur exécute une instruction SQL, si les données sont lues à partir du
disque, les performances en souffriront, car les disques, quelle que soit leur
rapidité, seront toujours plus lents que la RAM, que la mémoire. Si l'utilisateur peut
obtenir les données requises pour l'instruction SQL directement à partir de la
mémoire, les performances augmenteront considérablement. C'est pourquoi la mise
en cache des données en mémoire est si importante, et dans ce but précis, nous
avons la zone de mémoire tampon dans la mémoire SGA.
Le cache tampon met en mémoire cache les données de base de données
fréquemment utilisées , de sorte que les performances peuvent en bénéficier. Il est
important de noter que le cache tampon met en cache des blocs de données au lieu
de lignes individuelles. La façon dont Oracle stocke nos données physiquement sur
le disque est différente de la façon dont nous structurons logiquement notre base de
données. Nous travaillons avec des tables et des lignes, mais Oracle les stocke
comme des blocs de données séquentielles appelées blocs Oracle.
Chaque bloc Oracle contient une ou plusieurs lignes pour une table donnée. Chaque
fois qu'une session utilisateur accède à une ligne, le bloc entier est lu et mis en
cache dans le cache tampon. Par défaut, un bloc de base de données Oracle a
une taille de huit kilo-octets, mais nous pouvons le changer. Et ne vous inquiétez pas
non plus. Nous parlerons des propriétés physiques du stockage de la base de
données Oracle plus tard dans notre cours. Il est important de noter qu'Oracle est
suffisamment intelligent pour s'assurer que les blocs chargés dans le cache tampon
satisfont toujours le modèle de cohérence de lecture de la base de données.
Tous les utilisateurs qui sont connectés simultanément à la base de
données partagent et accèdent à un seul cache de tampon de base de
données, ayant accès à une seule vue unifiée de toutes les données de base de
données de cache. Une autre remarque importante est
qu'Oracle gère automatiquement les données mises en cache dans le cache
tampon. Comme la RAM est une ressource limitée, Oracle s'assure que seules
les données les plus fréquemment lues sur le disque seront mises en mémoire, et
que les données rarement accédées finiront par être éliminées du cache afin de faire
place à des accès plus fréquents les données.
De la même manière que le pool partagé est divisé en plusieurs sous-caches, nous
le trouvons également divisé en sous-composants, y compris le pool de stockage, le
pool de recyclage, ainsi que d'autres. Ces sous-missions individuelles sont au-delà
de la portée de notre cours. Pour l'instant, il nous suffit de parler de l' un de ces
composants seulement, et c'est le pool de keep. Le pool de conservation est un
composant à l'intérieur du cache de mémoire tampon qui permet à un administrateur
de base de données d'épingler certains ensembles de données en mémoire et de
s'assurer qu'ils ne vieillissent jamais hors du cache, même s'ils sont rarement
accessibles.

Le Tampon de journalisation
Nous amusons-nous à explorer l'instance Oracle? Rappelez-vous, nous avons une
instance Oracle; à l'intérieur, nous avons un composant SGA qui regroupe différents
types de caches en mémoire qu'utilise Oracle; chacun de ces caches en mémoire est
utilisé pour stocker différentes informations pour une meilleure
performance. Maintenant, il est temps de passer au tampon RedoLog; un autre
élément essentiel de la SGA. Le tampon RedoLog est un tampon circulaire qui
stocke les informations relatives aux modifications apportées à la base de données.
N'ai-je pas simplement dit que le cache tampon et le pool partagé sont ceux utilisés
pour mettre en cache les données de base de données et les métadonnées
respectivement? Pourquoi avons-nous besoin d'un autre cache en mémoire pour les
modifications de la base de données? Eh bien, la réponse est que le tampon
RedoLog est spécifiquement conçu pour stocker quelque chose connu comme des
entrées de rétablissement. Les entrées de rétablissement sont de petits
enregistrements qui reflètent toutes les modifications apportées à la base de
données dans le cadre de transactions ou de changements de structure de base de
données, également connus sous le nom de DML; commandes de langage de
modification de données et DDL; commande de langage de définition de données.
Pensez à refaire les entrées en tant que vecteurs de changement de base de
données. Les entrées de rétablissement sont utilisées pour la récupération de
la base de données quand et si nécessaire. Ces entrées de rétablissement
contiennent les informations nécessaires pour reconstruire ou refaire, d'où le nom,
les changements qui ont eu lieu dans la base de données au cas où la base de
données échouerait à mi-chemin pendant une transaction. Les entrées de
rétablissement sont considérablement plus petites comparées aux blocs de base de
données réels qui sont stockés dans le cache de tampon.
Une dernière chose importante avant de passer à autre chose; les entrées du journal
Redo dans le tampon RedoLog sont également écrites sur une base périodique à un
ensemble de fichiers dans notre base de données Oracle appelée Redo logs, mais
plus sur cela plus tard. Essayons donc de décrire ce qui se passe
lorsqu'un utilisateur modifie des données dans une transaction. Les modifications
apportées aux lignes de la base de données sont appliquées à la fois aux lignes
elles-mêmes qui sont mises en cache dans le cache du tampon, mais également aux
entrées de restauration spéciales qui sont générées et stockées dans le tampon
RedoLog.
Rappelez-vous, ce sont des vecteurs de changement de base de données. Pour
chaque ligne qui est modifiée et votre entrée de rétablissement est créée dans le
tampon RedoLog, parce que les entrées de rétablissement contiennent juste les
changements; ils sont beaucoup plus petits et peuvent être écrits sur le disque à un
rythme beaucoup plus rapide comparé à l'écriture du contenu de blocs de base de
données entiers à partir du cache tampon. Ainsi, lorsqu'un utilisateur s'engage à
s'assurer que la transaction est sécurisée sur notre base de données, il ne suffit pas
de contenir de la mémoire que vous connaissez déjà ; les entrées de rétablissement
pour cette transaction spécifique seront écrites sur le disque de manière
synchrone et immédiatement lorsque l'utilisateur émet la commande Commit.
Immédiatement après, l'utilisateur recevra une notification que la transaction a été
stockée; c'est maintenant sûr sur notre base de données de stockage. Il suffit
qu'Oracle ait les entrées de rétablissement pour une transaction stockée sur le
disque pour qu'il soit cohérent. Pas besoin d'attendre que tous les blocs de la base
de données du cache contenant les lignes réelles modifiées par la transaction à
écrire sur le disque, ainsi. Cela peut être écrit de manière asynchrone en arrière-
plan. Ainsi, notre message à emporter est le suivant: Lorsque les utilisateurs
modifient les données, les blocs de la base de données réels sont modifiés dans le
cache tampon, mais les entrées de refaire sont également générées dans RedoLog
Buffer (en tandem).
Lorsqu'un utilisateur décide de valider une transaction et de la stocker de manière
permanente sur un disque, tout ce qu'Oracle doit faire est de s'assurer que les
entrées de restauration du journal de redo sont écrites sur le disque. Ce sont de
petits ensembles de données car ils représentent uniquement le vecteur des
modifications apportées aux lignes et non les lignes entières elles-mêmes. Les blocs
de base de données modifiés réels dans le cache du tampon seront également écrits
sur le disque, mais de manière asynchrone car ils sont beaucoup plus gros et plus
lents. Si la base de données échoue immédiatement après la fin d'une transaction ,
de sorte que seules les entrées de restauration de la transaction ont été stockées sur
le disque, la base de données Oracle peut utiliser ces entrées pour rétablir la
transaction. et assurez-vous qu'aucune donnée ne sera perdue.
Solution très intelligente pour équilibrer les performances et la résilience. Ne dirais-tu
pas?
Autre POOL SGA Et PGA
Woof. C'était une longue explication pour un si petit composant de l'instance Oracle,
littéralement. Le plus grand composant du SGA est généralement le cache
tampon. Comme il met en cache les données réelles lues à partir du disque. Dans
les lignes, beaucoup de lignes de, vous le savez, des tables, beaucoup, et beaucoup
de tables. Le deuxième cache le plus grand dans le SGA est généralement le pool
partagé. Il stocke la présentation passée des instructions simples ainsi que des
métadonnées. Cela nous laisse avec le tampon RedoLog.
Habituellement, ce qui en fait le plus petit des composants majeurs de la SGA. Mais
hélas, nous n'avons pas encore fini. Bare avec moi pendant quelques minutes alors
que nous passons brièvement en revue plusieurs autres composants SGA. Certains
d'entre eux ne sont pas aussi importants pour notre administration quotidienne de la
base de données Oracle que le pool partagé, le cache tampon et le tampon
redolog. Mais nous avons encore besoin de connaître leurs fonctions dans le
SGA. Suivant sur notre liste de composants SGA à gogo est la grande piscine.
Nous n'entrerons pas dans beaucoup de détails car le grand pool n'est pas aussi
important que le cache tampon, le pool partagé ou le buffer redolog que nous avons
décrit plus haut. Signalons brièvement que le grand pool contient de la
mémoire utilisée par des fonctionnalités spéciales d'Oracle. Tels que les transactions
distribuées, les processus de serveur partagé, c'est en fait la mise en commun de
connexions quand c'est fait du côté de la base de données, si vous choisissez de le
faire. Et les opérations de sauvegarde et de restauration Oracle. es-tu encore avec
moi? Êtes-vous sûr? Bien.
Les deux derniers composants composant un SGA complet sont le pool java, qui est
utilisé pour stocker tout le code java spécifique à la session et les données dans une
JVM spéciale et un pool de flux. Ce qui fournit de la mémoire pour les processus de
flux Oracle. Mais encore une fois les deux sont bien en dehors du cadre de notre
cours. Bon zoom arrière de tous ces composants individuels SGA, nous négligerions
si nous ne mentionnons pas le PGA à nouveau. Rappelez-vous les processus de
serveur dont nous avons parlé au cours de notre premier chapitre? Ces processus
serveur ou SP sont créés pour chaque session utilisateur connectée à la base de
données.
Ils effectuent le passage de suite, ils lisent les données du disque et ils renvoient les
résultats à l'utilisateur. Donc, sans connexion, tirer deux sessions
utilisateur connectées à notre base de données signifiera deux processus
serveur oracle . Un pour chaque session d'utilisateur. Chaque fois qu'une session
utilisateur a besoin d'une tranche de mémoire privée, elle obtient son propre PGA,
également appelé zone globale privée. Le PGA est utilisé par les clients se
connectant à la base de données comme une sorte de staging ou temporaire dans la
zone de mémoire contenant diverses informations d'exécution sur les curseurs de
suite ainsi que la mémoire utilisée pour des opérations de suite plus lourdes telles
que classées par, jointures , etc.
Ainsi, chaque session d'utilisateur obtient son propre PGA dédié et le contenu de
cette PGA existe uniquement pour la durée de cette session. Lorsqu'un client se
déconnecte, un PGA spécifique est effacé. Comment contrôlons-nous la quantité de
PGA que chaque utilisateur obtient? Est-ce que l'oracle décide? Fait-il partie de notre
taille SGA? Et bien non. Nous utilisons un seul paramètre pour contrôler la quantité
de mémoire PGA disponible sur toutes les sessions connectées. Chaque session
recevra une tranche de mémoire dédiée à partir de la taille globale de PGA que nous
avons configurée.
Basé sur la demande, et la disponibilité. Nous utilisons le paramètre PGA global
target pour contrôler la quantité totale de mémoire PGA disponible sur toutes les
sessions.

Taille SGA et PGA

Mettons une théorie en pratique. Maintenant que nous savons ce qu'il y a à l'intérieur
de l'Oracle SGA et quel est le rôle du PGA , parlons de la façon dont nous pouvons
les dimensionner correctement. C'est super important. Comme c'est à l'expert de la
base de données de décider combien de mémoire sera allouée à Oracle et combien
de mémoire sera fournie pour le SGA par rapport au PGA. Nous pouvons contrôler la
taille de la SGA en utilisant deux paramètres. SGA Target et SGA Max Size.
Sur la base de ces paramètres, Oracle calculera lui-même le dimensionnement des
autres composants SGA individuels. Tels que le cache de mémoire tampon, le pool
partagé et le tampon de journal de radio. A titre d'exemple, nous pouvons configurer
une cible SGA pour 64 Go et la taille maximale SGA pour 128 Go et demander à
Oracle de redimensionner dynamiquement la mémoire SGA entre 64 Go et 128 Go
de mémoire en fonction des caractéristiques de la charge de travail.
D'un autre côté, lors du dimensionnement de la PGA, nous définissons le paramètre
PGA Aggregate Target comme égal à la quantité totale de mémoire. Nous voulons
40 PGA disponibles mais dans tous les processus serveur. Chaque processus
serveur alloue un sous-ensemble de cette quantité totale de mémoire
PGA disponible à l'utilisateur qu'il sert en fonction des exigences de charge de travail
de l'utilisateur. Réglage de la taille de la SGA ainsi que le PGA est vraiment fait en
fonction de la charge de travail.
Le SGA avec son cache tampon est généralement plus grand par rapport au
PGA. Cependant, lorsque de nombreux utilisateurs se connectent à une base de
données, beaucoup de sessions, exécutant probablement des requêtes de suite
complexes reposant essentiellement sur le tri de données ou l'assemblage de
grandes tables, vous pouvez augmenter la taille du PGA en conséquence. Il n'y a
pas de nombre magique pour la taille SGA ou PGA. Cela dépend vraiment de la
quantité de mémoire disponible dans votre serveur de base de données Oracle ainsi
que des charges de travail générées par vos applications.
Maintenant, voulez-vous que je vous simplifie la vie en tant qu'administrateur de
base de données? Eh bien, c'est ton jour de chance. Nous avons également une
autre option, où au lieu de spécifier explicitement la taille SGA et PGA comme nous
venons de le décrire, nous pouvons simplement définir un seul paramètre. Nous
pouvons utiliser le paramètre Oracles Memory Target et laisser Oracle partitionner
automatiquement la mémoire entre le SGA et le PGA.
Nous fournissons une valeur pour ce paramètre comme la quantité totale de
mémoire que nous voulons qu'Oracle utilise à la fois pour le PGA et le
SGA. Oracle divisera automatiquement et dynamiquement la quantité de mémoire
disponible pour le SGA et le PGA en fonction de ce qui est en cours d' exécution et
des charges de travail passées. Nous définissons simplement une valeur unique
en fonction de la quantité de mémoire que nous avons sur le serveur et laissons
Oracle faire tout le travail en termes de taille SGA et PGA.
Vous pouvez demander quelle option est la meilleure? Dimensionner manuellement
le SGA et le PGA séparément ou avoir Oracle diviser la mémoire tout seul? Eh bien,
cela dépend généralement du contrôle de grain que vous voulez sur l'allocation de la
mémoire de la base de données ainsi que de la connaissance de votre
base de données et de vos applications. Quelle option est la
meilleure? Dimensionner manuellement le SGA et le PGA séparément ou avoir
Oracle diviser la mémoire entre eux tout seul? Eh bien, cela dépend
généralement du contrôle de grain que vous voulez sur l'allocation de la mémoire de
base de données.
Cela dépend également de votre connaissance de votre base de données et de votre
application. En tant que débutant avec Oracle, vous pouvez compter sur Oracle pour
obtenir de l'aide. Réglez simplement le paramètre Memory Target et laissez Oracle
faire tout le reste. En fait, même certains de nos vétérans DBA veulent parfois
qu'Oracle fasse le travail pour nous et configure la mémoire en fonction de sa propre
compréhension de nos charges de travail. Vous savez, c'est une technologie
intelligente après tout.

3. Processus d’arriere plan

Database Writer
Jusqu'à présent, nous avons parlé des parties SGA et PGA de l'instance Oracle.Le
SGA et PGA sont des zones en mémoire utilisées pour la mise en cache de divers
types de données de base de données ainsi que des métadonnées de base de
données. En plus de la mise en cache, l'instance Oracle contient également ce que
l'on sait être les processus d'arrière-plan Oracle. Il s'agit d'un ensemble de processus
côté serveur dédiés exécutés en arrière-plan. De même que la manière dont les
différents composants du SGA mettent en cache différents types de données,
de même, différents processus d'arrière-plan Oracle ont des fonctions différentes.
Des fonctions telles que l'écriture de blocs de base de données sur le disque,
l' écriture de nouvelles entrées sur le disque, en s'assurant que tous les fichiers de la
base de données sur le disque sont synchronisés, et d'autres. Les processus
d'arrière-plan exécutent les tâches de maintenance requises pour exploiter la base
de données et optimiser les performances pour plusieurs utilisateurs. C'est pourquoi
chaque processus en arrière-plan gère une tâche différente. Alors, êtes-vous prêt à
connaître ces processus de base? Si c'est le cas, allons-y tout de suite.
Beaucoup d'acronymes confus que j'ai placés sur votre écran, mais ne vous
inquiétez pas, tout cela aura un sens dans un instant. Ce ne sont que les noms de
certains des processus d'arrière-plan Oracle les plus importants et ceux que vous
devriez connaître. Nous allons maintenant décrire chacun de ces processus
d'arrière-plan et la fonction unique qu'il sert dans l'instance Oracle. Démarrage avec
le processus Oracle Database Writer, ou DBW pour faire court. Il dit en fait DBW et la
lettre N.
En effet, nous pouvons démarrer plusieurs processus Database Writer pour
des raisons de performances si nécessaire. Alors, que fait le Database Writer? Eh
bien, le Database Writer est le processus responsable de l'écriture du contenu des
tampons de la base de données dans les fichiers de données sur le disque. N'oubliez
pas que les modifications apportées aux données sont d'abord
effectuées directement dans l'instance Oracle, qui est uniquement de la mémoire. Eh
bien, le programme d'écriture de base de données est le processus qui est
responsable de s'assurer que ces modifications en mémoire effectuées à l'intérieur
du cache du tampon seront finalement écrites dans le stockage de la base de
données.
Bien qu'un processus Database Writer soit généralement suffisant pour la plupart
des instances, nous pouvons configurer des processus supplémentaires pour
améliorer les performances d'écriture si votre système modifie considérablement les
données. Il existe en fait deux déclencheurs qui amèneront le processus Database
Writer à écrire des données de la mémoire sur le disque. Ces déclencheurs sont, tout
d'abord, lorsque la mémoire tampon cache de l'espace, et l'un des processus du
serveur Oracle, ou SP, tente de charger de nouvelles données dans le cache du
tampon, vous le savez, à partir du disque.
Ce type d'événement signalera à l'éditeur de base de données d'écrire afin qu'il
puisse libérer de l'espace pour les nouvelles données. Une fois que les données ont
été effacées du cache tampon et que la salle est disponible, les processus
serveur peuvent désormais charger les nouvelles données en mémoire. La deuxième
raison qui provoque l' écriture sur le disque de Database Writer est, bien, des
opérations de base de données normales. Le programme d'écriture de la base de
données écrit périodiquement des tampons du cache du tampon sur le disque. C'est
un processus de routine qui s'exécute en arrière-plan de manière asynchrone.
Le Database Writer avance également le point de contrôle de la base de
données dans le cadre de son processus. Qu'est-ce qu'un point de contrôle de base
de données, demandez-vous? Eh bien, le point de contrôle de la base de données
est un mécanisme utilisé par Oracle pour garder trace des transactions qui
ont encore des blocs en mémoire, qui contiennent des lignes affectées par ces
transactions, qui n'ont pas encore été écrites sur le disque. Souvenez-vous de notre
chapitre précédent, sous Redo Log Buffer, lorsque vous utilisez une transaction
validée, la seule opération synchrone qui se produit au moment de
l'engagement consiste à vider les entrées du journal Redo de la mémoire vers le
disque.
Ceci est fait pour s'assurer que la transaction peut être récupérée en cas d'échec de
la base de données. Les lignes réelles qui ont été modifiées dans le cadre de la
transaction peuvent toujours résider dans des blocs qui sont en mémoire
uniquement, à l'intérieur du cache de tampon. Le point de reprise de la base de
données est un événement de synchronisation qui se produit à un moment précis et
qui entraîne l' écriture de certains de ces blocs dans le cache du tampon sur le
disque. Oui, c'est le terme qu'Oracle utilise pour décrire ces types de blocs qui ont
été modifiés mais pas encore écrits sur le disque.
Blocs sales. Une fois que l'éditeur de base de données a vidé des blocs contenant
des lignes modifiées de la mémoire sur le disque, il avance le point de contrôle de la
base de données pour indiquer cet événement. Et, comme je l'ai mentionné, le
Database Writer le fait régulièrement.

LOG WRITER
Passons au processus d'arrière-plan suivant dans notre liste. Celui-ci est appelé
LGWR, qui est l'abréviation de log writer. Comme son nom l'indique, il s'agit du
processus d'arrière-plan d'Oracle chargé d'écrire des enregistrements de
rétablissement à partir de la mémoire tampon de journalisation de restauration et sur
un disque physique. Regardons de plus près. Le processus d'écriture de journal est
responsable de la gestion du tampon de journalisation. Il le fait en écrivant les
enregistrements du tampon du journal de rétablissement dans un fichier journal de
rétablissement sur le disque.
La façon dont l'enregistreur de journalisation fonctionne fonctionne en écrivant toutes
les entrées de rétablissement qui ont été accumulées dans la mémoire tampon du
journal depuis la dernière écriture sur le disque. Le rédacteur du journal de reprise
peut démarrer et coordonner plusieurs processus d'assistant d'écriture de
journalisation qui peuvent effectuer une partie du travail en même temps pour le
rédacteur du journal de reprise. Ceci est fait dans des occasions où le rédacteur de
journal de rétablissement peut tirer bénéfice de plusieurs opérations
concurrentes. Ces scénarios exacts sortent du cadre de notre cours, mais ne vous
inquiétez pas.
Ils ne sont pas cruciaux pour votre compréhension de l'architecture de la base de
données Oracle. Étant donné que le tampon de journalisation est circulaire, chaque
fois que le consignateur écrit à partir du tampon de journalisation et sur les fichiers
journaux de restauration, les processus du serveur Oracle peuvent écrire de
nouvelles entrées sur les entrées précédentes dans le tampon de journalisation. Mais
encore une fois, seulement après que ces enregistrements de journalisation aient été
écrits avec succès sur le disque. Le processus d'écriture de journal écrit assez
rapidement pour s'assurer que l'espace est toujours disponible dans la mémoire
tampon pour les nouvelles entrées.
Parlons maintenant de ce qui déclenche l'écriture du journal sur le disque. Tout
d'abord, bien, chaque fois qu'une session d'utilisateur valide, ce qui signifie que
l'utilisateur demande à la base de données d'enregistrer la transaction et de
s'assurer que les modifications effectuées par cette dernière transaction sont
stockées de manière sûre et sécurisée. Cela déclenchera l'enregistreur de journal
pour écrire le contenu de la mémoire tampon du journal redo de la mémoire dans les
fichiers journaux redo sur le disque. Comme je l'ai mentionné précédemment, les
changements correspondants aux lignes contenues dans les blocs de données dans
le cache tampon sont différés jusqu'à ce qu'il soit plus efficace de les écrire.
Rappelez-vous, c'est ce que le processus d'écriture de base de données est
pour. Ce mécanisme consistant uniquement à écrire de manière synchrone
des entrées de restauration sur le disque s'appelle le mécanisme Oracle Fast
Commit. Le deuxième déclencheur qui provoque l'écriture des enregistreurs de
journal, et il est très important, est quand un changement de journal se produit. Nous
n'avons pas beaucoup parlé des journaux de redo Oracle après ce point, donc c'est
une excellente occasion de faire la lumière sur ce que sont les journaux de redo et
comment le processus d'arrière-plan de l'enregistreur de journal les écrit.
Le journal de rétablissement d'une base de données consiste en deux ou plusieurs
fichiers journaux de rétablissement. C'est une exigence difficile. La base de données
nécessite un minimum de deux fichiers pour garantir que l'un est toujours disponible
pour l'écriture pendant que l'autre est en cours d'archivage. Qu'est-ce que l'archivage
d'un journal de rétablissement, vous pouvez demander. Eh bien, c'est
essentiellement le processus de copie périodique des fichiers de journalisation à
un emplacement sûr et sécurisé à des fins de sauvegarde. Parce que les journaux de
rétablissement contiennent des informations sur toutes les transactions qui ont été
effectuées dans la base de données, ils sont instrumentaux si jamais il est
nécessaire de récupérer la base de données à partir d'une sauvegarde.
La copie des journaux de rétablissement dans un emplacement sécurisé est
effectuée automatiquement par l'instance Oracle. Il y a en fait un autre processus
d'arrière-plan dédié responsable de cela. C'est ce qu'on appelle le processus
d'archivage, et nous en reparlerons plus loin dans notre chapitre. Quoi qu'il en soit,
alors revenons à l'écrivain de journalisation. Donc, comme je l'ai mentionné, nous
avons besoin d'un minimum de deux fichiers de journalisation. Nous avons
généralement trois ou plus dans une base de données Oracle de production
réelle. L'enregistreur de journal écrit dans les fichiers de journalisation de manière
circulaire.
Lorsque le fichier journal en cours est rempli avec des données, l'enregistreur de
journaux commence à écrire dans le fichier journal de reprise disponible suivant. Une
fois que le fichier journal redo est également plein, l'enregistreur de journalisation
redo passe au fichier journal suivant. Lorsque le dernier fichier de journalisation
disponible est rempli, le processus de journalisation revient au premier fichier
journal et y écrit à nouveau, en commençant le cycle depuis le début. Un autre
déclencheur pour l'enregistreur de journal de réécriture pour écrire dans les fichiers
de journalisation sur le disque est que le tampon de journalisation lui-même est
rempli au 1/3 ou contient au moins un mégaoctet de données.
Mais nous n'avons pas encore fini. Un autre déclencheur pour le processus de
journalisation redo à écrire est juste avant que le processus d'arrière-plan de l' auteur
de la base de données n'écrive également sur le disque. Tu te souviens de ce
mec? Le processus DBW de notre vidéo précédente. Notez que l'enregistreur de
journal écrit dans les fichiers journaux de rétablissement sur le disque pendant que
l'auteur de la base de données écrit dans les fichiers de données sur le disque. Nous
parlerons du stockage de la base de données Oracle et de tous les différents types
de fichiers utilisés par la base de données Oracle dans notre prochain chapitre.
Alors, pourquoi l'enregistreur de journal doit-il écrire des entrées de restauration sur
le disque avant que l'auteur de la base de données puisse écrire un bloc modifié de
la mémoire sur le disque? En effet, tous les enregistrements de restauration associés
à des modifications apportées à une ligne de base de données spécifique contenue
dans un bloc en mémoire doivent d'abord être écrits sur le disque avant que le bloc
lui-même puisse être écrit. Et notre déclencheur final provoquant l' écriture du
processus d'arrière-plan de l'enregistreur de journal à partir du tampon de
journalisation en mémoire sur le disque est probablement le plus simple.
Toutes les trois secondes Oui, l'enregistreur de journal écrira tout le contenu du
tampon de journalisation de la mémoire dans les fichiers de journalisation du disque
toutes les trois secondes

CHECKPOINT.
Le processus d'arrière-plan suivant dans notre liste est le processus de point de
contrôle, ou CKPT en bref. Ce processus gère les points de contrôle de la base de
données. Nous avons discuté brièvement des points de contrôle de la base de
données lorsque nous avons parlé du processus de base de l'auteur de base de
données, mais faisons un récapitulatif rapide. Un point de contrôle Oracle est un
événement de base de données qui synchronise les blocs de données modifiés en
mémoire à partir du cache tampon avec les fichiers de données sur le disque. C'est
un événement qui se produit régulièrement lorsque la base de données Oracle
déclare un état de cohérence interne, une cohérence interne entre les modifications
qui ont été effectuées en mémoire et les données qui ont été écrites sur le disque.
Un point de contrôle a deux objectifs. L'une consiste à établir la cohérence des
données entre la mémoire et le disque, et l'autre est d'activer un processus de
récupération de base de données plus rapide. Les points de contrôle sont un
élément crucial dans la récupération de base de données. Plus nous avons de blocs
de bases de données qui ont été modifiés en mémoire mais qui ont également été
écrits sur le disque, moins nous devons compter sur les journaux de rétablissement
pour la récupération. Lorsqu'un point de contrôle se produit, la base de données
Oracle doit mettre à jour les en-têtes de tous les fichiers de données pour enregistrer
que le nouveau point de contrôle s'est effectivement produit.
Ceci est fait par le processus d'arrière-plan appelé CKPT. Chaque point de contrôle
de base de données génère un identificateur séquentiel unique
appelé numéro SCN ou numéro de modification du système. Ce numéro séquentiel
est enregistré par le processus CKPT dans les en-têtes du fichier de base de
données. Notez que le processus CKPT n'écrit pas les blocs de données réels de la
mémoire sur le disque. C'est ce à quoi sert l'auteur de la base de données. Le SCN
est enregistré dans les deux fichiers de données Oracle qui, bien, contiennent les
données réelles de notre base de données, ainsi que dans un ensemble spécial de
fichiers connus sous le nom de fichiers de contrôle Oracle.
Chaque base de données Oracle possède un fichier de contrôle, qui est un petit
fichier binaire qui enregistre la structure physique de la base de données. Par
structure physique, je veux dire que le fichier de contrôle conserve une trace de
l'emplacement, c'est-à-dire, le nom ou le chemin de certains fichiers dans le stockage
Oracle, pas les noms des tables ou des colonnes. C'est une structure logique. Nous
parlerons plus de fichiers de contrôle dans notre prochain chapitre.

PROCESSUS SMON
Le processus suivant dans notre liste de processus d'arrière-plan Oracle est le
processus System Monitor. Ce processus en arrière-plan effectue une récupération
au cours de la séquence de démarrage de l'instance Oracle si nécessaire. Donc là
vous l'avez. Il n'y a pas grand-chose à dire sur le processus du System Monitor. Il fait
un travail avec diligence. Oh, encore une chose avant d'aller de l'avant. Le processus
System Monitor est également responsable du nettoyage des segments temporaires
inutilisés.
Par exemple, si la base de données Oracle alloue un espace temporaire pour faciliter
la création d'un nouvel index et que cette opération échoue, le processus Moniteur
système nettoie et récupère cet espace temporaire

Processus PMON
Le processus suivant dans notre liste de processus d'arrière-plan Oracle est le
processus System Monitor. Ce processus en arrière-plan effectue une récupération
au cours de la séquence de démarrage de l'instance Oracle si nécessaire. Donc là
vous l'avez. Il n'y a pas grand-chose à dire sur le processus du System Monitor. Il fait
un travail avec diligence. Oh, encore une chose avant d'aller de l'avant. Le processus
System Monitor est également responsable du nettoyage des segments temporaires
inutilisés.
Par exemple, si la base de données Oracle alloue un espace temporaire pour faciliter
la création d'un nouvel index et que cette opération échoue, le processus Moniteur
système nettoie et récupère cet espace temporaire

Processus RECO
nous faisons vraiment de grands progrès. Nous avons passé en revue la plupart des
processus d'arrière-plan d'Oracle avec seulement trois autres à faire. Continuons à
bouger. Notre processus d'arrière-plan suivant est le processus RECO, qui
représente le processus de récupération. Le processus de récupération est un
processus d'arrière-plan utilisé dans le cadre de transactions de base de données
distribuées. Les transactions distribuées sont des transactions qui impliquent
plusieurs bases de données et doivent valider une restauration sur les deux bases
de données à la fois.
Une transaction distribuée ne doit pas être autorisée à réussir uniquement sur une
base de données unique. Par exemple, supposons que nous ayons deux bases de
données. Base dedonnées A et base de données B. Une transaction distribuée est
exécutée, demandant de modifier les données sur les deux bases de données,
en commençant par la base dedonnées A. Comme la transaction est en cours
d' exécution sur la base de données A, il commence des lignes de mise à jour de
la base de données locale A. La transaction est également exécutée sur la base de
données distante, base de données B, mise à jour des lignes locales à la base de
données B.
Si, lors de la mise à jour de la base de données B, la transaction a échoué, elle sera
marquée comme une transaction en attente ou échouée et doit être nettoyée sur les
deux bases de données. Le processus RECO gère cette tâche et résout
automatiquement toutes les défaillances de ces transactions distribuées. Il se
connectera automatiquement aux autres bases de données impliquées dans de
telles transactions douteuses ou échouées et supprimera toutes les lignes affectées
par la transaction.

Processus LREG
Le processus LREG, ou processus d'enregistrement des auditeurs, est suivi
de notre visite du processus d'arrière-plan Oracle . Le processus LREG joue un rôle
très direct dans l'architecture de la base de données Oracle. Il est responsable de
l'enregistrement de l'instance Oracle auprès du programme d'écoute du réseau
Oracle. Attends quoi? L'écouteur Oracle? Eh bien, c'est nouveau. Oui, ça
l'est. L'écouteur du réseau Oracle, souvent réduit à un simple écouteur Oracle ou
même simplement à un auditeur, est le processus responsable de l' acceptation des
connexions entrantes distantes et du démarrage des processus serveur Oracle
requis pour desservir ces connexions.
Oui, c'est vrai, nous avons déjà parlé de la manière dont les sessions individuelles
des utilisateurs se connectant à une base de données Oracle recevront un
processus de serveur dédié pour effectuer les diverses tâches en leur
nom. Cependant, nous n'avons pas encore parlé de la manière dont les
utilisateurs ouvrent réellement une connexion à une base de données Oracle. C'est
là que l'auditeur entre en jeu. Nous avons un chapitre complet dédié à l'écoute du
réseau Oracle, ainsi que la gestion des connexions client, mais pour l'instant, il suffit
de dire que les utilisateurs distants qui veulent se connecter à la base de données
Oracle doivent d'abord se connecter au programme d'écoute Oracle.
Immédiatement après cette connexion, l'écouteur Oracle est chargé de générer un
nouveau processus de serveur pour cet utilisateur et de passer la connexion entre
l'utilisateur et le processus de service. Le processus LREG est responsable de
l'enregistrement des informations sur l'instance de base de données en cours
d'exécution avec le programme d'écoute du réseau Oracle, de sorte que le
programme d'écoute Oracle sache qu'une instance Oracle est opérationnelle sur ce
serveur. Lorsque l'instance Oracle démarre, le processus LREG tente de se
connecter à l'écouteur.
Si le programme d'écoute est en cours d'exécution, le processus LREG enregistre
l'instance avec le programme d'écoute Oracle. Notez que nous avons utilisé ORCL
comme nom de l'instance Oracle dans notre exemple. Chaque instance Oracle a
besoin d'un nom. Nous le configurons lorsque nous créons l'instance. ORCL est un
nom par défaut commun utilisé pour les instances Oracle génériques. Nous verrons
exactement comment nommer une instance lorsque nous créerons notre propre base
de données Oracle plus tard dans le cours

Processus ARCn
Nous l'avons fait. Le processus d'arrière-plan Oracle final pour nous
d'examiner. Vous devriez vraiment vous féliciter d'être allé aussi loin. Je sais que ce
n'était pas facile, mais je suis sûr que ça valait le coup. Comme la compréhension de
ce qui se passe à l'intérieur de l'instance Oracle, derrière le rideau, est très
importante pour un expert en base de données Oracle. Heureusement, votre
provision de café frais n'est pas encore épuisée, car le processus de fond Oracle que
nous devons couvrir est également l'un des plus importants. C'est le processus
d'archivage ou ARCn pour faire court.
Similaire au processus de déplacement de la base de données, le processus
d'archivage a également la lettre n dans son nom. C'est parce que nous pouvons
démarrer plus d'unprocessus d'archivage si nécessaire. Nous verrons pourquoi dans
un instant. Le but du processus d'archivage est très simple. Il est responsable de
copier les fichiers journaux de redo Oracle sur un périphérique de stockage
distant après qu'un commutateur de journalisation a été effectué. Le processus
d'archivage copiera le fichier de journalisation et le placera sur tout stockage externe
de votre choix.
Là-bas, le journal de rétablissement sera sûr au cas où la base de données et le
système de stockage principal auquel il est connecté ont échoué. La copie de la
base de données reloge sur un autre système de stockage est très importante du
point de vue de la sauvegarde et de la récupération. Rappelez-vous, les fichiers
relog contiennent un enregistrement de toutes les transactions exécutées dans notre
base de données. Si nous plaçons une copie de chacun de nos fichiers relog de
base de données immédiatement après leur écriture, et souvenez-vous que les
fichiers relog sont écrits de manière cyclique, dans un endroit sûr.
Nous pouvons ensuite utiliser ces copies de journalisation pour réappliquer les
transactions après avoir restauré notre base de données à partir d'une sauvegarde
statique. Nous utilisons essentiellement ces fichiers relog archivés pour faire
avancer la base de données jusqu'à un moment donné. Et oui, comme je l'ai
mentionné au début, si vous prévoyez une lourde charge de travail en écriture, vous
pouvez ajouter des processus d'archivage supplémentaires à votre base de
données. Il peut également y avoir plusieurs destinations de journaux d'archivage à
des fins de redondance. De cette façon, chaque copie archivée du journal de
rétablissement est stockée dans plusieurs emplacements.

4. Structure de la base de données physique

Types de fichiers de stockage

Félicitations pour l'avoir fait aussi loin dans le cours. Vous commencez probablement
à vous sentir comme un véritable expert Oracle maintenant. Nous avons en fait
terminé une partie importante de notre cours, qui consiste à examiner l'instance
Oracle et tous ses composants. N'oubliez pas que l'instance Oracle est la moitié en
mémoire de la base de données Oracle, s'exécutant dans la RAM du serveur,
mettant en cache les données et traitant les demandes des utilisateurs. L'autre
moitié, dont nous parlerons maintenant plus en détail, est le stockage de données
Oracle ou les fichiers de base de données Oracle.
Le stockage de base de données Oracle est la représentation persistante sur disque
de la base de données Oracle. Rappelez-vous, c'est là que vos données résident en
tant que fichiers sur le disque. C'est à partir de là que le serveur Oracle traite les
données lues, et c'est ici que le rédacteur de la base de données Oracle ainsi que
l'auteur du journal écrivent des lignes modifiées. Tu veux que je te dise un secret très
connu? Le stockage de la base de données Oracle n'est pas constitué d'un fichier ou
même d'un type de fichier.
Comme vous l'avez déjà deviné, Oracle gère différents types de fichiers sur disque à
des fins différentes. Rappelez-vous que lorsque nous avons parlé de l'instance
Oracle, nous avons mentionné que différents caches en mémoire sont utilisés pour
différents types de données. De même, Oracle conserve différents fichiers sur disque
à des fins différentes. Ce que vous voyez sur votre écran en ce moment, ce sont tous
les types de fichiers qu'Oracle utilise. Lorsque vous regardez dans le répertoire sur
votre système de stockage où vous avez configuré votre base de données Oracle
pour résider, vous verrez réellement ces fichiers.
Pourquoi Oracle a-t-il besoin de tant de types de fichiers uniques? Eh bien, c'est une
excellente question. Pour vous donner un exemple, certains de ces fichiers, tels que
les fichiers de données, stockent nos données de base de données réelles. D'autres
fichiers, tels que les fichiers journaux redo, contiennent un enregistrement de toutes
les transactions qui ont été validées afin que l'instance Oracle puisse se rétablir
correctement en cas de panne ou de redémarrage. En revanche, le journal des
alertes est le journal des erreurs de la base de données. C'est ici que vous trouverez
des informations sur diverses conditions ou erreurs survenues pendant l'exécution de
votre base de données.
C'est le fichier que vous allez surveiller pour vous assurer que votre base de
données fonctionne bien, mais ce n'est que la pointe de l'iceberg. Commençons à
examiner les fichiers de stockage de base de données Oracle un par un.

Fichiers de données et tablespaces

Commençons notre discussion sur le stockage de la base de données Oracleen

parlant des fichiers de données Oracle. Heureusement pour nous, ils sont aussi le
type de fichier Oracle le plus complexe dont nous ayons besoin. Assurez-vous donc
d'avoir une bonne tasse de café à portée de main, car nous sommes sur le point
d'aller au fond du trou de lapin sur la façon dont Oracle gère le stockage. Les fichiers
de base de données Oracle contiennent en réalité toutes les données utilisateur ou
application de notre base de données. Tables, lignes, ils sont stockés dans des
fichiers de données. Des index, oui, à l'intérieur de nos fichiers de données.
Les métadonnées de base de données, telles que les utilisateurs qui ont été créés et
leurs autorisations ou vues, et les procédures stockées? Oui, toutes les données de
la base de données, ainsi que les métadonnées, sont stockées dans les fichiers de
données. C'est pourquoi les fichiers de données sont un composant si important pour
le stockage de base de données Oracle. Vous les perdez, vous perdez votre base de
données. Chaque base de données Oracle contiendra plusieurs fichiers de
données. Certains sont créés automatiquement lorsque nous installons Oracle, et
d'autres sont créés par nous, ou utilisateurs, pour stocker les données de
l'application.
Les fichiers de base de données ont des propriétés physiques et vous pouvez
réellement les voir lorsque vous regardez dans le répertoire où vous avez configuré
votre base de données Oracle pour stocker ses données. Cependant, à l'intérieur de
ces fichiers de données, les choses deviennent un peu plus complexes. Oracle a sa
propre hiérarchie interne d'allocation d'espace dans les fichiers de données. Nous
allons jeter un coup d'oeil. À l'intérieur d'un fichier de données, l'unité la plus
fondamentale du stockage Oracle est appelée un bloc de données Oracle.
Les fichiers de données, à leur plus bas niveau, sont constitués de collections
séquentielles de blocs de base de données Oracle. Les blocs de données Oracle ont
généralement une taille de huit kilo-octets, ce qui signifie qu'un seul bloc de données
Oracle correspond à 8 000 octets d'espace physique sur votre disque. Alors que 8K
est la taille par défaut pour le bloc de données Oracle, il peut être configuré. Un seul
bloc de données Oracle contient une ou plusieurs lignes, généralement
plus. Lorsque nous exécutons nos requêtes, la base de données récupère les blocs
de données à partir des fichiers de données et renvoie les résultats pertinents à
l'utilisateur final.
Le niveau suivant de stockage de base de données logique est appelé Extent. Une
étendue est un ensemble de blocs de données Oracle continus. La raison pour
laquelle le terme Extent existe dans la terminologie Oracle Database est qu'il est
beaucoup plus efficace, lors de l'allocation d'espace à l'intérieur d'un fichier de
données, de l'allouer en morceaux relativement volumineux. Ainsi, au lieu d'allouer
un bloc de base de données à la fois, Oracle alloue des extensions complètes, qui
sont simplement une collection de plusieurs blocs de données Oracle regroupés.
Le niveau de stockage logique suivant au-dessus d'une étendue s'appelle un
segment. Êtes-vous avec moi jusqu'à présent? Un Segment est un ensemble
d'Extensions, une ou plusieurs Extensions, allouées pour certaines structures
logiques dans la base de données. Structures logiques, oui, tables, index, tables
temporaires, ce sont toutes des structures logiques. Une table, dans notre base de
données, peut être considérée comme un segment d'espace. Un index, aussi, un
segment d'espace.
Chaque objet logique de la base de données Oracle nécessitant de l'espace et dont
la taille peut augmenter au fil du temps est appelé Segment interne dans
Oracle. Vous pouvez aussi y penser d'une autre manière. Lorsque vous créez une
table, vous créez également ce que l'on appelle le segment de table. C'est
exactement comme cela qu'Oracle gère l'allocation de stockage en interne, à
l'intérieur de ses propres fichiers de données. Il est important que vous vous
familiarisiez avec ces termes, car Oracle peut parfois vous signaler des problèmes
ou des problèmes avec un segment de table spécifique, ce qui signifie le stockage
alloué à cette table.
Ensuite, dans notre liste de concepts logiques de stockage Oracle, nous avons des
tablespaces, et ce sont des groupes spéciaux. Contrairement aux segments, aux
extensions et aux blocs, qui sont généralement cachés aux utilisateurs de bases de
données pendant les opérations de base de données normales, les tablespaces sont
quelque chose que vous devriez être familier. En ce qui concerne le stockage des
données, chaque base de données Oracle est divisée en plusieurs
tablespaces, certaines créées automatiquement lors de la création de votre base de
données et d'autres générées par l'utilisateur.
Les tablespaces sont des groupes de stockage logiques pouvant être utilisés pour
stocker des constructions de base de données logiques, telles que des tables et des
index. Lorsque vous créez une table dans Oracle, vous spécifiez dans quel espace
de table vous souhaitez stocker cette table. Vous devez créer les tablespaces à
l'avance. Ensuite, après avoir créé les tablespaces, vous pouvez les utiliser lors de la
création de tables. Regardons un exemple rapide. Ici, nous créons un espace de
table EMP_DATA.
C'est juste un nom que nous avons inventé. Nous pouvons l'appeler comme nous
voulons. En plus du nom de l'espace de table , nous spécifions également les fichiers
de données que ce tablesapce doit utiliser pour le stockage. Oui, vous ne pouvez
pas créer un espace de table sans spécifier les fichiers de données qu'il doit
utiliser. Les fichiers de données seront créés automatiquement dans le cadre de la
création de l'espace de table. Nous pouvons spécifier un ou plusieurs fichiers de
données. Notez que nous spécifions en fait le chemin complet des fichiers de
données, y compris le répertoire, pour les données de notre exemple.
Cela signifie qu'une fois que l'espace de table a été créé, il créera également deux
fichiers de données pour nous, appelés emp_data01.dbf et emp_data02.dbf. Les
deux fichiers de données seront placés dans le dossier oradata. Par ailleurs, dbf est
un suffixe de fichier commun utilisé pour les fichiers de données Oracle, il représente
le fichier de base de données. Nous spécifions également la taille des fichiers de
données.
Dans ce cas, chaque fichier serait dimensionné à 100 mégaoctets. Nous pouvons
même configurer les fichiers de données pour qu'ils s'étendent automatiquement si
l'espace est insuffisant. Maintenant que nos tablespaces sont prêts, nous sommes
libres de créer des tables à l'intérieur de ce tablespace. Lorsque nous créons des
tables, nous les plaçons dans un espace de table. Dans notre exemple, nous avons
créé une table employee, et souhaiterions qu'elle soit stockée dans l'espace table
emp_data.
Cela signifie que le segment de table sera stocké dans les fichiers de données de
l'espace table emp_data. Fondamentalement, comme les utilisateurs écrivent de
nouvelles données dans les tables des employés, les blocs Oracle seront écrits dans
les deux fichiers de données qui font partie de l'espace de table d'une manière
circulaire. Un seul tablespace peut contenir un segment pour plusieurs tables et
index, et nous pouvons créer plusieurs tablespaces dans une base de
données, chacune avec ses propres fichiers de données dédiés.
Donc, pour récapituler, au niveau le plus bas de l'allocation de stockage logique,
nous avons des blocs Oracle. Ces blocs Oracle stockent nos lignes. Un niveau ci-
dessus, nous avons Extents, qui est une collection de plusieurs blocs
Oracle. Lorsqu'Oracle doit allouer de l'espace dans les fichiers de données, il l'alloue
via Extents, ce qui est un moyen plus efficace d'allouer le stockage par rapport aux
blocs individuels. Un Segment est une collection d'Extensions appartenant à une
table ou un index spécifique dans notre base de données.
Table ou index Les segments sont stockés dans Tablespaces, qui est l'unité logique
de stockage que nous utilisons pour spécifier où une table ou un index doit être
créé. Chaque table ou index de notre base de données ne peut être stocké que dans
un seul espace de table . Une base de données aura beaucoup d'espaces de
table. Nous pouvons en créer autant que nous voulons. Nous pouvons regrouper des
tables ayant des affinités dans des espaces de table spécifiques. Les tablespaces
eux-mêmes sont stockés en tant que fichiers de données, ce qui est la seule
manifestation physique du modèle de stockage de base de données Oracle dans
notre système de fichiers.
Cela signifie que nous pouvons réellement voir des fichiers de données dans nos
répertoires de stockage, mais nous ne pouvons pas voir Tablespaces, Segments,
Extensions ou Blocs,car ce sont des constructions de stockage logiques utilisées en
interne par Oracle.

Espaces de tablespace Oracle spéciaux

Oracle a des tablespaces très spéciales qu'il créera automatiquement dès la sortie
de la boîte lors de l'installation. Oracle utilise ces tablespaces pour
diverses raisons. Passons en revue eux. Les deux premiers espaces de
table créés par Oracle sont les espaces table SYSTEM et SYSAUX. Le take-away
ici? Ce ne sont pas pour nous, ne créez pas vos propres tables à l' intérieur de ces
tablespaces spéciaux. L'espace de table SYSTEM, par exemple, contient l'intégralité
du dictionnaire de données Oracle.
Toutes les métadonnées de notre base de données sont stockées dans l'espace
table SYSTEM. Si vous perdez l'espace de table SYSTEM, vous perdez la totalité de
votre base de données. C'est important comme ça. Nous avons également un
espace de table spécialconnu sous le nom de tablespace UNDO. Il est également
géré par la base de données Oracle et ne nous est pas destiné à créer des
tables. Que fait l'espace de table UNDO? Eh bien, chaque base de données Oracle a
une méthode de conservation des informations qui est utilisée pour annuler ou
annuler des modifications dans la base de données.
Par exemple, que se passe-t-il si un utilisateur a modifié une ligne, que les données
dans la base de données ont changé, puis que l'utilisateur a décidé d'annuler la
transaction? C'est supporté bien sûr. Toutes les transactions dans une base de
données relationnelle telle qu'Oracle peuvent être annulées jusqu'à ce qu'un
utilisateur effectue une validation. Ce qui se passe réellement est que pendant la
transaction, Oracle stocke automatiquement les versions précédentes des blocs qui
ont été modifiés dans le cadre des transactions dans le tablespace UNDO.
Ainsi, lors d'une restauration, Oracle peut restaurer les versions précédentes de ces
lignes à partir de l'espace table UNDO et dans le tablespace d'origine. Le tablespace
UNDO est également utile lorsqu'un utilisateur met à jour des données et, comme
mentionné, lors de la mise à jour, les versions précédentes des lignes
affectées seront copiées dans l'espace table UNDO. Le premier utilisateur n'a pas
encore validé les données, peut-être que la transaction est toujours en
cours, peut - être en mettant à jour beaucoup de lignes.
Mais maintenant un autre utilisateur se connecte à la base de données et essaie de
lire les mêmes lignes qui sont en cours de mise à jour par cet autre utilisateur. Ce qui
se passera réellement, c'est que le deuxième utilisateur aura directement ces blocs
à partir du tablespace UNDO. C'est vrai, le deuxième utilisateur verra les lignes dans
leur version précédente, au moins jusqu'à ce que le premier utilisateur a commis une
transaction. Enfin, la base de données Oracle dispose également d'un
espace table TEMP utilisé pour stocker les tables temporaires dans lesquelles les
données ne doivent pas être conservées après le redémarrage d'une instance et
utilisées lorsque les instructions SQL utilisent lourdement le tri des données ou
JOINs et manquent d'espace. mémoire à l'intérieur d'un PGA.

Les fichiers journaux de Redo

Les fichiers journaux de Redo stockent les vecteurs de modification de la base de
données, qui sont des événements représentant les modifications apportées aux
lignes de la base de données et à la structure de la table de la base de
données. Ces enregistrements Redo sont principalement utilisés par l'instance
Oracle à des fins de récupération après un incident. Redo Logs sont le nom
Oracle du journal des transactions de la base de données. Si vous perdez votre base
de données Redo Log Files, vous perdez votre base de données et vous ne pourrez
pas la démarrer. La base de données Oracle requiert au moins deux fichiers
journaux Redo à tout moment, car elle leur écrit de manière cyclique.
Cela signifie que la base de données écrit dans le premier fichier journal de Redo, et
une fois que ce dernier est rempli, la base de données commence à écrire dans le
second fichier journal de Redo. C'est ce qu'on appelle un bouton Redo Log. Une fois
que le deuxième fichier journal de Redo a été écrit sur, et est maintenant plein, la
base de données renvoie et écrit à la première, et vice versa. C'est pourquoi on
l'appelle une écriture cyclique. Alors que deux est la quantité minimale de Redo Logs
requise par une base de données Oracle, nous pouvons, et nous devrions souvent,
en créer plus.
Généralement, trois, cinq ou sept journaux de rétablissement sont communs. Peu
importe le nombre de Redo Logs que nous avons, ils sont toujours écrits de manière
cyclique. Nous pouvons également toujours ajouter des fichiers journaux Redo
supplémentaires à notre base de données. Cependant, il n'est pas souvent
nécessaire, car, en raison de la nature cyclique de Redo Log écrit, nous ne
manquerons jamais d'espace Redo Log. Oracle permet également de créer des
groupes de journaux Redo, qui nous permettent de stocker une copie de chaque
journal de Redo dans plus d'un emplacement.
Pour la redondance, parce que les journaux de rétablissement sont si critiques pour
la fonction de la base de données, rappelez - vous, si vous perdez un de vos
journaux de rétablissement, vous ne pourrez pas commencer votre base de
données. Ainsi, afin de minimiser les risques d'échec du stockage, ce qui entraîne la
perte de Redo File, Oracle prend en charge le multiplexage des journaux Redo. Le
multiplexage est une façon élégante de dire la redondance. Fondamentalement,
stocker chaque journal de Redo dans plus d'un emplacement.
Chaque fichier du groupe Redo Log est appelé un membre. Donc, le groupe numéro
un a deux membres: 1_1 et 1_2. Le groupe numéro deux a également deux
membres: membre 2_1 et membre 2_2. Nous pouvons nommer les membres du
Redo Log à notre guise. Si nous multiplexons nos journaux Oracle Redo et utilisons
les groupes Redo Log, le processus d'arrière-plan d'écriture de journal Oracle
écrira en même temps à un groupe et à tous ses membres, au lieu de simplement
écrire dans un journal Redo individuel, comme nous l'avons vu précédemment.
Les écritures seront cycliques entre les groupes Redo Log. Écrire à un groupe
signifie écrire à tous ses membres en même temps. Et laissez-moi vous donner un
conseil très important avant de passer au chapitre suivant: Par défaut, dans de
nombreuses versions de base de données Oracle, les extensions de fichier du fichier
journal de Redo sont .log. Cependant, il ne s'agit pas de fichiers journaux d'erreurs
de base de données. Ce sont vos fichiers journaux Redo, vos journaux de
transactions de base de données, qui sont cruciaux pour votre base de données.
Rappelez-vous, vous les perdez, vous perdez votre base de données. Je ne peux
pas vous dire le nombre de fois où j'ai vu des administrateurs de bases de données
juniors supprimer leurs journaux de redondance par erreur parce qu'ils pensaient qu'il
s'agissait simplement de fichiers journaux d'erreurs et qu'ils essayaient de libérer de
l'espace dans le répertoire de stockage. Alors laissez-moi finir notre vidéo de Redo
Log en vous laissant un conseil très important: Ne confondez pas accidentellement
vos fichiers journaux Redo pour les fichiers journaux d'erreurs de base de données
et ne les supprimez pas par erreur pour libérer de l'espace dans votre répertoire de
stockage .

Fichiers de contrôle
Il est maintenant temps de discuter du but du fichier de contrôle du stockage de
base de données Oracle. Chaque base de données Oracle possède un fichier de
contrôle unique qui contient des données sur la base de données elle-même. Cela
semble drôle, mais je ne plaisante pas. Le fichier de contrôle contient des
informations sur les propriétés physiques de la base de données, les propriétés telles
que les noms de bases de données, les noms et emplacements des fichiers de
données et les fichiers redolog appartenant à cette base de données,
les informations de point de contrôle, etc.
En passant, par les noms et les emplacements des fichiers de données et
des fichiers de redolog, je veux dire que le fichier de contrôle stocke en fait le chemin
complet d'où les fichiers de données et les fichiers redolog existent sur le
disque. Lorsqu'une instance Oracle démarre, elle doit connaître l'emplacement du
fichier de contrôle afin de savoir où se trouvent les fichiers de données et les fichiers
de redolog . Ce n'est qu'après que l'instance de base de données a lu le fichier de
contrôle qu'il sera capable de lire les fichiers de données et les fichiers redolog et de
poursuivre sa séquence de démarrage normale.
Oracle a intégré le support pour le multiplexage de fichiers de contrôle. Des copies
identiques multiples du fichier de contrôle peuvent être maintenues pour se protéger
contre la perte de la base de données. Rappelez-vous, sans le fichier de
contrôle, l'instance de base de données ne saura pas où chercher les fichiers
redolog et les fichiers de base de données, donc les fichiers de contrôle sont
essentiels pour le démarrage de la base de données. Et la meilleure chose à propos
du multiplexage de fichiers de contrôle? Nous n'avons pas à le faire nous-
mêmes. Oracle s'en occupera pour nous. Nous pouvons simplement demander à la
base de données Oracle de conserver plusieurs copies de nos fichiers de contrôle,
de préférence dans plusieurs emplacements, et Oracle s'occupera du reste.
En raison de la nature critique des fichiers de contrôle, ils sont également très
importants du point de vue de la sauvegarde. À chaque fois que vous sauvegardez
votre base de données, veillez à sauvegarder vos fichiers de base de données, vos
fichiers de redolog, ainsi que vos fichiers de contrôle. Ils sont tous requis pour que
l'instance Oracle puisse démarrer correctement.

Fichiers de sauvegarde
Pour la dernière partie de notre discussion Oracle Database Storage, parlons de
quelques autres types de fichiers de base de données que vous devriez
connaître. En commençant par les fichiers liés aux sauvegardes de base de
données. Les fichiers de sauvegarde de base de données incluent toutes les
sauvegardes de votre base de données que vous avez prises et placées dans un
endroit sûr, ainsi que les copies des fichiers journaux de rétablissement créés par le
processus d'archivage de base de données. Il existe de nombreuses technologies
que vous pouvez utiliser pour sauvegarder votre base de données Oracle. Ils sont en
dehors du cadre de notre cours, mais du point de vue du stockage de base de
données, il est toujours très important de mentionner les fichiers de sauvegarde de
base de données quand on parle de stockage de base de données.
Nous pouvons supposer qu'au moins une fois dans votre carrière, vous serez chargé
de restaurer une base de données Oracle de l'échec. Espérons juste que ce n'est
qu'une seule fois. Lorsque vous effectuez une sauvegarde de votre base de données
Oracle, l'état cohérent de la base de données utilisée pour la récupération s'appelle
les fichiers de sauvegarde de la base de données. Ce sont généralement des copies
des fichiers de données de votre base de données, des journaux de rétablissement
et du fichier de contrôle.Ce sont les fichiers de stockage de base de
données actuellement utilisés par votre base de données. Sans ces fichiers inclus
dans votre sauvegarde, vous ne pourrez pas restaurer votre base de données dans
un état cohérent.
Les fichiers journaux redo archivés sont également très importants du point de vue
de la sauvegarde de la base de données. Ce sont les fichiers créés par le processus
d'arrière-plan Oracle Archiver . Parce que les fichiers de journalisation contiennent
des informations sur toutes les transactions qui ont été effectuées dans notre base
de données, elles sont essentielles si vous avez besoin de restaurer votre
base de données à partir d'une sauvegarde à un moment précis. C'est pourquoi il est
essentiel de copier les journaux de restauration et de les stocker dans un
emplacement de sauvegarde sûr et sécurisé , car ces copies archivées des journaux
de rétablissement peuvent être utilisées lors de la récupération de la base de
données.
Examinons de plus près comment vous pouvez utiliser les fichiers de sauvegarde de
base de données Oracle pour restaurer votre base de données. Supposons que
votre base de données fonctionnait normalement à 14h00. Vous avez pris une
sauvegarde complète de la base de données à 14h00. Cette sauvegarde a pris deux
heures à compléter. La sauvegarde s'est terminée à 16h00 mais contient une
sauvegarde cohérente de votre base de données à partir de 14h00. En effet, une
sauvegarde Oracle sera toujours cohérente jusqu'au moment où elle a été prise.
Vous avez pris une autre sauvegarde de base de données parce que vous êtes un
DBA Oracle très diligent, mais cette fois à 16h00. Cette sauvegarde a également pris
deux heures complètes à compléter. La deuxième sauvegarde était donc prête à
18h00, mais contenait une image cohérente de la base de données à partir de
16h00. C'est à ce moment que la sauvegarde a été démarrée. Prenez tout. Assurez-
vous que vous êtes avec moi jusqu'à ce point. En supposant qu'il est maintenant
22h00, et votre base de données vient de planté, vous voulez le récupérer.
Vous devez le récupérer. Alors bonne nouvelle, en tant qu'ADN Oracle diligent, vous
avez pris une sauvegarde de votre base de données à partir de 16h00. Utilisons
cette sauvegarde pour restaurer notre base de données. Cette sauvegarde pourrait
juste sauver la journée. Attendez. Attendez. Un problème majeur. Votre base de
données a été restaurée, mais dans l'état où la sauvegarde complète a été
effectuée, soit 16h00. La base de données s'est bloquée à 22h00. Qu'est-il advenu
de toutes les données générées par les utilisateurs et stockées dans votre base de
données entre 16h00 et 22h00? Devrions-nous, je ne sais pas, paniquer? Non, pas
besoin de paniquer.
Si vous avez vos copies archivées de refaire, qui se souviennent, contiennent une
copie de vos transactions de base de données dans un endroit sûr et
accessible, nous devrions avoir la plupart des changements qui ont été appliqués à
la base de données entre 16h00, l'heure de notre dernière sauvegarde a été prise, et
22h00, l'heure actuelle, le moment où la base de données s'est écrasé. Nous
pouvons donc utiliser les vecteurs de modification de la base de données ou les
entrées de restauration stockées dans ces fichiers de journalisation redo
archivés pour faire avancer notre base de données vers l'heure actuelle.
La base de données restaurée à partir de la sauvegarde peut utiliser ces fichiers
journaux redo archivés pour effectuer une opération dite de récupération aval et
refaire les transactions perdues. Refaire. C'est pourquoi on les appelle des journaux
de rétablissement. La base de données utilisera ces journaux de restauration
archivés pour appliquer toutes les transactions qui se sont produites après la
sauvegarde complète et juste avant l'arrêt brutal de notre base de données.

Fichiers de stockage supplémentaires

Nous avons besoin d'un peu plus de fichiers de stockage de bases de
données, brièvement, car nous avons déjà traité de la plupart des sujets de ce
chapitre. Prenons un moment pour parler du fichier de paramètres de la base de
données . Le fichier de paramètres de base de données également appelé fichier
SP ou fichier de paramètres de serveur est un fichier binaire qui stocke les
paramètres de configuration de l'instance Oracle. Lorsque vous configurez des
valeurs pour les paramètres qui affectent votre instance ou votre base de données,
des paramètres tels que la taille maximale SJ ou la cible agrégée PGA.
Ces paramètres et leurs valeurs sont stockés dans le fichier SP. Étant donné que le
fichier SP est un fichier binaire qui modifie les valeurs de ces paramètres ou d'autres
paramètres, vous devez utiliser les commandes Oracle. Vous ne pouvez pas modifier
directement le fichier SP.Si vous perdez votre fichier SP, ne paniquez pas, alors que
vous ne pourrez pas démarrer votre instance de base de données sans un fichier
SP, car il contient toutes les options de configuration de base de données , vous
pouvez simplement le recréer.
Vous devrez reconfigurer tous les paramètres, recréer le fichier SP, puis vous
devriez être en mesure de démarrer votre instance. Cependant, il est souvent plus
facile d'inclure simplement le fichier SP dans le cadre de vos sauvegardes de base
de données normales. Je veux dire pourquoi travailler dur quand ce n'est pas
nécessaire, non? Le suivant dans la ligne est le fichier de mot de passe de base de
données. Le fichier de mot de passe de la base de données stocke le mot de passe
de l' utilisateur administrateur Oracle, également appelé utilisateur SYSDBA.
C'est fondamentalement l'utilisateur le plus puissant dans la base de données
d'Oracle. Cet utilisateur a les privilèges de faire, eh bien, n'importe quoi. Accédez à
toutes les données stockées dans la base de données, modifiez toutes les options
de configuration, tout. Le fichier de mot de passe est créé lorsque vous configurez
votre base de données Oracle pour la première fois et que vous fournissez un mot de
passe pour cet utilisateur SYSDBA très puissant. Notez que vous pouvez utiliser le
mot de passe de l'utilisateur SYSDBA à tout moment, ce qui modifie également le
mot de passe dans le fichier de mot de passe.
Oh, et une chose plus importante à retenir, le fichier de mot de passe stocke
uniquement le mot de passe pour l'utilisateur SYSDBA, pas pour les autres
utilisateurs de la base de données, tels que les utilisateurs de l'application. Ces
utilisateurs et leur mot de passe sont stockés dans la base de données Oracle, en
particulier dans le dictionnaire de données Oracle contenu dans l'espace table
système. Et dernier mais certainement pas le moindre, le fichier Oracle Alert Log, ou
fichier d'alerte, ou simplement le fichier journal.
Il s'agit essentiellement du nom du fichier journal de flèches Oracle. Le fichier journal
des alertes Oracle contient une liste chronologique des messages, des alertes, des
erreurs et, fondamentalement, tout ce qui est arrivé à votre base de données depuis
sa création initiale. Il contient toutes les erreurs qui pourraient empêcher votre
base de données de fonctionner correctement, c'est donc votre fichier de référence si
vous essayez de résoudre un problème avec votre base de données. C'est une autre
façon de dire que le fichier d'alerte est le meilleur ami d'un DBA.

5. Démarrer et arrêter la base de données

Démarrage
Parlons de la séquence de démarrage et d'arrêt de la base de données Oracle . Oui,
c'est une séquence, pas un seul état activé ou désactivé. En réalité, plusieurs étapes
sont nécessaires chaque fois que vous démarrez ou arrêtez votre base de données
Oracle. Commençons par parler de la séquence de démarrage. Lorsque votre base
de données est hors service, c'est-à-dire hors connexion, cela signifie qu'aucune
instance Oracle n'est en cours d'exécution sur le serveur. Les fichiers de base de
données sont sûrs sur votre base de données de stockage, mais personne ne peut
accéder à vos données.
Lorsque vous émettez une commande de démarrage Oracle, notre objectif final est
de mettre l'instance en service afin qu'elle puisse lire et écrire des données à partir
du stockage de la base de données Oracle. Ceci est également connu comme un
état ouvert pour la base de données. Le processus d' obtention d' un état ouvert pour
la base de données Oracle est le suivant: le premier dans la séquence d'événements
menant à un état ouvert est un état de nom. C'est à ce moment-là que l'instance
Oracle a été créée en mémoire, c'est-à-dire que vous avez exécuté le programme
Oracle sur votre serveur.
Tout le cache mémoire SGA a été alloué et les processus d'arrière-plan sont tous en
cours d'exécution. L'instance Oracle traitera le fichier de paramètres d'initialisation du
serveur, ou SPFILE, que nous avons spécifié. Mais à ce stade, l'instance Oracle n'a
pas encore lu ou écrit quoi que ce soit à partir du stockage de la base de données
Oracle elle-même. Nous venons juste de lancer l'instance. C'est tout. La prochaine
étape de notre séquence de démarrage Oracle est l'étape de montage. C'est ici que
votre instance Oracle lit le fichier de contrôle à partir du stockage de la base de
données.
Il sait où trouver un fichier de contrôle car son emplacement est spécifié dans
le fichier de configuration de l' instance Oracle , ou SPFILE. À l'étape de montage de
la séquence de démarrage, l'instance Oracle ouvre simplement le fichier de contrôle
lui-même. C'est tout. Il ne lira pas les fichiers de base de données ou ne lira pas les
fichiers de verrouillage à ce stade. Rappelez-vous que le fichier de contrôle contient
des informations sur les emplacements des fichiers de la base de données, ainsi que
sur le journal de rétablissement. C'est pourquoi l'instance Oracle doit d'abord lire le
fichier de contrôle avant de pouvoir ouvrir la base de données et la rendre
fonctionnelle.
La prochaine et dernière étape de notre séquence de démarrage Oracle
Database est l'étape ouverte. À ce stade, l'instance Oracle utilise les
informations stockées dans le fichier de contrôle pour localiser et ouvrir les fichiers
de données Oracle et lire les fichiers de verrouillage. Si cette étape de la séquence
de démarrage a réussi, votre base de données sera désormais prête pour les
connexions entrantes. Les utilisateurs et les applications peuvent maintenant se
connecter à la base de données et lire ou écrire des données. Nous pouvons
effectuer un démarrage de base de données normal en émettant la commande de
démarrage à partir de l'invite SQL Oracle.
Cela mettra votre base de données dans un état ouvert. Cependant, nous pouvons
également demander à la base de données Oracle de démarrer mais de rester à une
étape spécifique de la séquence de démarrage. Ceci est utile principalement pour le
dépannage des problèmes avec votre base de données. Vous pouvez déplacer
manuellement la base de données Oracle entre chaque étape de la séquence de
démarrage en exécutant la commande que vous voyez à l'écran maintenant. Ces
commandes sont le nom de démarrage, le démarrage de démarrage et enfin, alter
database open.
Ce n'est qu'après avoir exécuté alter database open, si vous avez choisi de démarrer
votre instance en utilisant la route de menu, vous aurez une base de données Oracle
entièrement fonctionnelle, et les utilisateurs pourront se connecter.

Arret
Nous avons une histoire similaire pour arrêter l'instance Oracle. Aller d'un état de
base de données en cours à un ... Eh bien, pas en cours d'exécution. Nous avons
plusieurs méthodes ou modes d'arrêt de la base de données que vous pouvez
utiliser. Ces différents modes déterminent la propreté de la procédure d'arrêt de la
base de données par rapport à la durée nécessaire. Commencer avec la commande
SHUTDOWN ABORT. Si nous exécutons la commande SHUTDOWN ABORT, la
base de données Oracle passe immédiatement d'un état ouvert ou en état à un état
désactivé.
Toutefois, en raison de sa nature brute, la base de données ne sera pas cohérente
lors de l'arrêt. Et lorsque vous redémarrerez la base de données, Oracle devra
utiliser les fichiers journaux de rétablissement pour effectuer une récupération
automatique après un accident. C'est similaire à tirer la fiche de la base de données
Oracle. Cela peut sembler effrayant, mais tant que vous n'avez pas de corruptions
dans les fichiers de données de votre base de données ou dans les journaux de redo
manquants, cela devrait vous convenir. Le mode SHUTDOWN ABORT est
généralement utilisé lorsqu'il n'y a pas d'autre méthode pour arrêter l'instance qui
fonctionne.
Le mode d'arrêt suivant est le mode SHUTDOWN IMMEDIATE. Si vous exécutez
cette commande dans votre invite Oracle SQL, Oracle interrompt toutes les sessions
utilisateur ouvertes. Attendez que toute transaction non validée ait été annulée, puis
arrêtez la base de données pendant qu'elle conserve un état cohérent. C'est une
méthode d'arrêt plus lente que SHUTDOWN ABORT, mais beaucoup plus sûre. La
base de données effectuera un point de contrôle avant de fermer
l'instance. Cependant, du point de vue de l'utilisateur, leurs sessions seront
brusquement interrompues et toutes les données ou transactions non sauvegardées
seront perdues.
Le prochain mode d'arrêt de la base de données s'appelle SHUTDOWN
TRANSACTIONAL. Lorsque vous tapez cette commande dans l'invite Oracle
SQL, Oracle attend que toutes les transactions existantes terminent le traitement et
que les utilisateurs s'engagent ou annulent la transaction avant d'arrêter la base de
données. Cependant, les nouveaux utilisateurs ou les nouvelles sessions ne
pourront pas se connecter. Ce type d'arrêt peut prendre un certain temps car la base
de données ne sera pas déconnectée tant que tous les utilisateurs n'auront pas
terminé leur travail.
Il est également très non-perturbateur pour les utilisateurs déjà connectés. Et le
dernier mode d'arrêt de la base de données s'appelle SHUTDOWN NORMAL, ce qui
signifie qu'Oracle attendra que tous les utilisateurs ou sessions connectés se
déconnectent de la base de données avant de l'éteindre. C'est l'option d'arrêt la plus
lente, mais elle sera totalement non intrusive pour vos utilisateurs et vos
applications. Donc, là vous l'avez: les quatre façons différentes d'obtenir votre base
de données Oracle d'un état en ligne à un état hors ligne.
La plupart des administrateurs de base de données utilisent l'option SHUTDOWN
IMMEDIATE plus souvent. La principale raison est que lorsque vous fermez la base
de données en utilisant SHUTDOWN IMMEDIATE, SHUTDOWN TRANSACTIONAL
ou SHUTDOWN NORMAL, la base de données sera cohérente sur le disque après
l'arrêt. Donc, au démarrage, aucune récupération n'aura lieu. Tout bloc modifié de la
mémoire sera écrit sur le disque avant que la base de données ne tombe en
panne. C'est pourquoi ces modes d'arrêt prennent également plus de temps.
Vous pouvez appeler ces méthodes d'arrêt en tant que méthodes d'arrêt
propres. Comparez cela à l'option SHUTDOWN ABORT, qui est une méthode d'arrêt
incorrecte car l'instance de la base de données s'arrête juste brusquement. Certains
blocs Oracle modifiés en mémoirene pourront pas être gravés sur des disques. Ainsi,
au démarrage, Oracle devra utiliser les journaux de rétablissement pour effectuer
une récupération automatique après un accident.

Démarrer et fermer l'instance

Nous pouvons démarrer et fermer l'instance de base de données Oracle directement
à l'aide de la suite plus. Nous pouvons le faire en ouvrant une suite plus invite
enutilisant l'utilisateur sysdba oracle. Vous écrivez espace sqlplus, guillemet, barre
oblique inverse, as, espace, sysdba. Cela ouvrira une connexion à la base de
données en tant qu'utilisateur sys ou sysdba, qui est l'utilisateur Oracle le plus
puissant.
Nous devons nous connecter à cet utilisateur afin de pouvoir démarrer et
arrêter l'instance Oracle avec succès . Nous pouvons fermer l'instance en tapant
simplement shut rephrase. Nous pouvons arrêter l'instance en tapant shutdown
immédiatement. L'arrêt immédiat est la méthode d'arrêt d'instance la plus courante. Il
déconnectera les utilisateurs existants et annulera toute transaction en cours. Il
s'assurera également que la base de données est correctement arrêtée, donc
aucune récupération automatique ne sera nécessaire au démarrage.
Appuyez sur Entrée pour lancer l'arrêt de l'instance. Notez qu'Oracle nous
affichera les différentes étapes de la séquence d'arrêt de l'instance au fur et à
mesure que l'instance décline. Il mentionnera qu'il ferme l'instance, démonte
l'instance et, finalement, ferme. De même, nous pouvons démarrer l'instance Oracle
à partir de la suite plus. Nous pouvons le faire simplement en tapant la commande de
démarrage. En appuyant sur Entrée, Encore une fois, Oracle nous notifiera lors du
démarrage de l'instance lors de toutes les phases de la séquence de démarrage.
Oracle nous affichera également avec l' allocation de mémoire SGA. Nous pouvons
voir combien de mémoire a été allouée via nos paramètres de configuration au cache
de base de données, à la mémoire tampon du journal redo, et ainsi de suite. Nous
pouvons également amener l'instance Oracle à une phase de démarrage
spécifique, pas à une base de données ouverte. C'est très utile pour le dépannage
de divers problèmes de démarrage d'une instance Oracle. Essayons-le, d' abord en
fermant à nouveau l'instance.
Je suis en train de taper arrêt immédiat et en appuyant sur Entrée. Voilà, l'instance
Oracle va s'arrêter. Maintenant, au lieu de taper start qui va amener l'instance à son
état complètement ouvert, tapons le nom de démarrage, un mot, nom. Cela amènera
l'instance au puits, étape de nomenclature, qui alloue simplement le SGA dans
l'instance. Il n'ouvrira aucun des fichiers de stockage de base de données Oracle.
Passons à l'étape précédente dans la séquence de démarrage et saisissons alter
database mount pour déplacer la base de données d'un nomount vers une phase de
montage. L'ouverture complète de l'instance peut être effectuée en exécutant alter
database open, en rappelant le point-virgule et en appuyant sur enter. L'instance est
maintenant entièrement ouverte. Les fichiers de données et les fichiers de
journalisation ont été accédés. Et les utilisateurs et les applications peuvent
maintenant se connecter à la base de données Oracle, lire et écrire des données.

Afficher et définir les paramètres

L'instance de base de données Oracle est configurée via une longue liste de
paramètres d'initialisation stockés dans le fichier SPFILE de la base de données ou
dans le fichier de paramètres du serveur. Rappelez-vous que c'est un fichier binaire
qui contient la configuration de l'instance. La modification des paramètres peut être
effectuée à l'aide de l'interface Oracle SQL * Plus. Allons de l'avant et modifions une
partie du paramètre d' instance Oracle en commençant toujours par se connecter à
la base de données en tant qu'utilisateur DBA sys.
SQL * Plus comme DBA sys. Nous pouvons afficher la valeur actuellement
configurée pour un paramètre Oracle spécifique en exécutant la commande
show space parameter, puis le nom du paramètre. Tels que SGA soulignent la
cible. Nous voyons que dans ma base de données, j'ai le paramètre de cible de
soulignement SGA configuré avec une valeur d'environ 1400 mégaoctets.
Nous pouvons aussi taper show, parameter, SGA underscore, appuyer sur enter, et
voir les valeurs de tous les paramètres commençant par SGA. Tels que les deux
soulignent la cible SGA, ainsi que le paramètre de taille de soulignement max de
soulignement SGA. La valeur d'un paramètre est définie via la commande alter
system set.
Par exemple, définissons la valeur de la cible de soulignement SGA en tapant alter,
system, set, SGA, underscore target, équivaut à 1000 mégaoctets ou un
gigaoctet. Donc, je diminue la taille disponible pour le SGA, espace, je vais devoir
suivre cette commande avec un argument de portée égale .
Où nous pouvons spécifier soit la mémoire, qui modifiera temporairement le
paramètre dans l'instance, et il sera réinitialisé à la valeur précédente après un
redémarrage. Je peux également spécifier SPFILE, ce qui signifie que le paramètre
ne sera stocké dans le fichier SPFILE et ne prendra effet qu'après un redémarrage
de l'instance. Ou, je peux spécifier les deux, ce qui signifie que le paramètre sera à la
fois dynamiquement modifié en mémoire et stocké dans le fichier SPFILE, de sorte
qu'au redémarrage, la nouvelle valeur prendra effet.
Jetons un coup d'œil à la valeur de la cible SGA après avoir effectué une
modification. Afficher le paramètre SGA soulignant la cible. Et vous pouvez voir que
nous avons une nouvelle valeur en vigueur. N'oubliez pas qu'Oracle arrondit parfois
les valeurs pour les paramètres de mémoire. Alors que le fichier SPFILE est un
fichier binaire, vous ne pouvez donc pas le modifier manuellement, mais uniquement
modifier les paramètres à l'aide de l'interface SQL * Plus ou Oracle Enterprise
Manager par exemple. Vous pouvez exporter le fichier SPFILE dans un fichier texte .
Nous pouvons le faire en tapant create, PFILE, qui signifie fichier de
paramètres. Stockons-le dans le répertoire de base de l'utilisateur Oracle
Linux. Ainsi, les guillemets slash slash maison slash Oracle, et donnons-lui un nom
comme mon soulignement PFILE dot ora guillemets, à partir de SPFILE. Oh, mon
mal! Notez que j'ai spécifié l'emplacement du fichier de paramètres à l'aide de
guillemets doubles; Cependant, Oracle s'attend à des guillemets simples.
Modifions donc la commande pour utiliser des guillemets simples à la place. mon
PFILE dot ora de SPFILE. Ah, nous l'avons. Comme vous pouvez le voir, Oracle a
créé un fichier PFILE à partir de notre fichier SPFILE. Jetons un coup d'oeil à
l'intérieur de notre PFILE. Pour ce faire, nous devons quitter SQL * Plus, aller dans
notre répertoire de base Oracle, taper ls, et comme vous pouvez le voir, nous
avons créé un fichier monogramme PFILE dot ora .
Jetons un coup d'oeil à l'intérieur du fichier et voyons son contenu. Alors écrivez
l'espace de chat mon PFILE dot ora, appuyez sur Entrée, oh et c'est une longue liste
de paramètres que vous avez là. Le fichier PFILE contient une liste de tous
les paramètres d'instance Oracle actuellement configurés . Nous pouvons rechercher
un paramètre spécifique en tapant l'espace de chat mon soulignement PFILE dot
ora, et en passant la commande grep, comme la cible de soulignement SGA grep.
Rappelez-vous ce paramètre? Nous l'avons juste modifié. Donc là vous l'avez. Nous
pouvons facilement afficher et définir les paramètres d'instance Oracle à l'aide de
l'interface de ligne de commande SQL * Plus et exporter le fichier de configuration
Oracle binaire, ou SPFILE,dans un fichier texte, afin qu'il soit lisible par l'utilisateur.

Créer des utilisateurs et attribuer des autorisations

Oracle est intégré avec un super utilisateur appelé Sys. La connexion à Sys à partir
de SQL Plus nécessite soit l' ajout de sysdba au suffixe, tel que sqlplus sys / le mot
de passe, qui est oracle dans mon cas, et sysdba. Cela ouvrira une connexion à
l'instance Oracle en tant qu'utilisateur sys ou sysdba le plus puissant.
Alternativement, nous pouvons simplement taper sqlplus, guillemets, comme
sysdba, et être connecté à l'instance avec l'utilisateur sys, sysdba. Nous n'avons pas
besoin de fournir un mot de passe spécifique à l'utilisateur sys, uniquement parce
que nous sommes physiquement connectés au même serveur que l'instance
Oracle. De plus, nous exécutons SQL Plus à partir de l'utilisateur Oracle Linux, qui
est l'utilisateur qui a démarré l'instance Oracle.
C'est la seule raison pour laquelle nous pouvons ignorer le mot de passe d'un
utilisateur aussi puissant lors de la connexion à la base de données. Une connexion
avec sys depuis n'importe quelle autre machine de notre réseau vers notre base de
données, nous aurait demandé de fournir le mot de passe. La création d'utilisateurs
supplémentaires dans Oracle est également extrêmement simple. Pour créer des
utilisateurs, nous devons d'abord nous connecter en tant qu'utilisateur sys, en tant
qu'utilisateur le plus puissant de notre base de données, car cet utilisateur a la
permission de créer d'autres utilisateurs.
Donc, assurez-vous que vous exécutez les commandes que je suis sur le point de
vous montrer avec l'utilisateur sys Oracle. Alors créons un nouvel utilisateur de base
de données. Par exemple, tapons create user et tapez un nom tel que
melissa. Identifié par, Identifié par, et tapez un mot de passe, comme, vous savez
quoi, mot de passe. Colon, entrez, utilisateur créé.
Cependant, avant que cet utilisateur puisse faire quoi que ce soit, même se
connecter à la base de données, nous devons lui donner des permissions. Chaque
opération dans Oracle requiert une autorisation spécifique pour y être associée. Par
exemple, si je veux me connecter à la base de données en utilisant l'utilisateur
melissa que je viens de créer, j'obtiendrai une erreur. Quittons SQL Plus et
tapez, sqlplus, melissa, mot de passe, et entrez.
Oh, cet utilisateur ne peut pas se connecter à la base de données. Comme vous
pouvez le voir, Oracle a renvoyé l'erreur utilisateur melissa n'a pas le privilège de
création de session, ouverture de session refusée, alors réparons cela. Ouvrons à
nouveau SQL Plus, en tant qu'utilisateur sysdba, et accordons l'autorisation
manquante à notre utilisateur melissa. Donnons donc grant, créez une session à
melissa.
Nous l'avons. Essayons de nous connecter à nouveau avec l'utilisateur
melissa. sqlplus, melissa, mot de passe, et maintenant nous sommes en mesure
d'établir une connexion à la base de données. Cependant, que pensez-vous qu'il se
passera si nous essayons de créer une table pendant que nous sommes connectés
en tant qu'utilisateur melissa? Des paris? Essayons. Créer une table, test_table1.
Donnons-lui une seule colonne. Colonne un, numéro un. Essayons de créer cette
table de test. Oh, nous avons une autre erreur. Privilèges insuffisants. C'est parce
que j'ai accordé à l'utilisateur melissa une permission de connecter la base de
données mais pas d'action. Alors réparons ça aussi. Je quitte SQL Plus et me
reconnecte en tant qu'utilisateur sysdba. Cette fois, fournir à l'utilisateur melissa deux
autorisations supplémentaires.
Accordez un espace de table illimité, ce qui permettra à l'utilisateur melissa d'utiliser
autant de stockage d'espace de table que nécessaire et également le privilège create
table de mélissa. Notez que je peux fournir plusieurs privilèges dans la même
déclaration de subvention. Appuyez sur entrer. Grant a réussi. Et connectons en
utilisant l'utilisateur melissa. Notez que je peux également ouvrir une nouvelle
connexion tout en étant directement connecté à SQL Plus.
Je n'ai pas besoin de quitter SQL Plus et de l'ouvrir à nouveau chaque fois que je
veux changer d'utilisateur. D'accord, je suis connecté avec l'utilisateur
melissa. Essayons d'exécuter la même commande qui a échoué précédemment. Es-
tu prêt? Essayons. Eh bien, nous y voilà. Table créée avec succès. Dans Oracle,
chaque utilisateur est également appelé schéma, nous pouvons donc référencer les
tables créées par cet utilisateur en préfixant le nom d'utilisateur au nom de la table.
Reconnectez-vous en tant qu'utilisateur sysdba et tapez select * depuis
le point melissa . Notez que c'est l'utilisateur que je viens de créer et le nom de la
table, test_table1. Maintenant, la table n'a pas encore de ligne, donc je ne m'attends
pas à recevoir des résultats, mais je m'attends aussi à ne pas recevoir un message
d'erreur m'indiquant que la table n'existe pas.
Alors essayons. Oh, on y va. La sélection a été exécutée avec succès, mais m'a
donné un message me disant qu'aucune ligne n'est retournée. C'est parce que la
table existe, mais elle est fondamentalement vide. Vraiment, vraiment
simple. Souvenez-vous que c'est ainsi que vous pouvez référencer les tables qui ont
été créées par un utilisateur d'un autre utilisateur. Si j'omets le préfixe melissa et que
je tape simplement * from test_table1, j'obtiens une erreur car je suis maintenant
connecté avec l'utilisateur sys et l'utilisateur sys ne possède pas de table appelée
test_table1.
La suppression d'un utilisateur est également super simple. Nous pouvons
simplement taper la commande drop melissa de l' utilisateur . Cependant, comme cet
utilisateur possède également une table, je dois également spécifier un mot-clé
cascade dans ma commande. Donc j'ai besoin de taper drop user
melissa cascade. Cela supprimera l'utilisateur, mais supprimera également toutes les
tables, index, toutes les données avec des objets créés par cet utilisateur.
Et avant de terminer cette vidéo, laissez-moi vous montrer une autre chose
intéressante à propos des utilisateurs et de la sécurité dans Oracle. Ouvrons à
nouveau SQL Plus en tant qu'utilisateur sys et parlons des rôles de base de
données. Nous pouvons regrouper plusieurs privilèges à l' intérieur de ce qui est
connu dans Oracle en tant que rôle et les accorder à un utilisateur. Par exemple,
créons le rôle de connexion et de création, donc nous allons taper, créer un
rôle connect_and_create et accorder des privilèges à ce rôle, comme grant create
table to connect_and_create, qui est mon nom de rôle.
Notez qu'Oracle n'est pas sensible à la casse lorsqu'il s'agit de commandes
système. Accordons un autre privilège au rôle connect_and_create, tel que
grant create session, qui est le privilège Oracle qui permet aux utilisateurs de se
connecter à la base de données connect_and_create. Maintenant, je peux accorder
ce rôle, connect_and_create, à un utilisateur, et en faisant cela, l'utilisateur aura
essentiellement les permissions contenues dans ce rôle.
À titre d'exemple, accordons connect_and_create à notre utilisateur hr. Là nous
allons, très, très simple. N'oubliez pas d'utiliser souvent des rôles pour simplifier
l' octroi d'autorisations généralement accordées aux utilisateurs, c'est tout, c'est le
concept des utilisateurs et des rôles dans une base de données Oracle.

Dictionnaire de données

Le dictionnaire de données Oracle est une collection de tables et de vuesgérées par

la base de données Oracle et qui nous permet de récupérer des informations très
pertinentes sur la base de données Oracle, son noyau et son état. Quel genre
d'information? Eh bien, les utilisateurs qui ont été créés, les tables qui ont été créées,
les tablespaces et les fichiers de données, la configuration, etc. Nous pouvons
réellement utiliser le langage SQL standard pour extraire le dictionnaire de
données, ce qui en soi est très très cool.
Les tables et les vues du dictionnaire de données dans Oracle commencent soit par
dba_, soit par préfixe v $. Le dictionnaire de données compte plus de 6 000 vues et
plus de 2 000 tableaux. Maintenant, ils ne sont pas tous très utiles, et nous ne les
couvrirons pas tous dans cette vidéo, mais jetons un coup d'œil sur les plus
intéressants. Commençons par ouvrir une connexion à notre base de données
Oracle en tant qu'utilisateur sysdba.
Et pour notre premier exemple, montrons-en un simple, en visualisant les utilisateurs
dans la base de données. Pour ce faire, nous allons récupérer les données de la vue
du dictionnaire de données dba users. Commençons par regarder la structure de la
vue du dictionnaire de données dba_users en écrivant desc, qui est la commande
Oracle SQL + nous permettant de structurer les tables et les vues, et dba_users.
Rappelez-vous, je suis connecté avec l'utilisateur Oracle sysdba. C'est pourquoi j'ai
accès au dictionnaire de données. Vous pouvez voir qu'il contient des
colonnes relatives aux utilisateurs de la base de données. Si vous voulez récupérer
une liste de tous les utilisateurs dans la base de données, ainsi que la date à laquelle
ils ont été créés, nous pouvons exécuter le nom d'utilisateur sélectionné, créé à partir
de dba_users; et appuyez sur Entrée.
Si nous voyons que les lignes de notre sortie SQL + commencent à s'enrouler l'une
autour de l'autre, nous pouvons augmenter la taille de ligne en tapant set lignes un
cinq zéro, ou 150. Cela changera la longueur de ligne de la sortie SQL +. Et répétons
notre commande. Sélectionnez le nom d'utilisateur, créé à partir de dba_users.
Ah, beaucoup mieux. Comme vous pouvez le voir, nous avons une liste de tous les
utilisateurs dans notre base de données et leur date de création. C'est la vue du
dictionnaire de données dba_users. Comme autre exemple, nous pouvons
également voir les fichiers de journalisation et de données de la base de données,
voir leurs emplacements. Commençons par les journaux de rétablissement. Nous
utiliserons un autre dictionnaire de données, appelé v $ logfile.
Nous allons taper select member à partir de v $ logfile; entrer. Nous pouvons voir les
emplacements physiques des fichiers de journalisation que notre base de données
utilise. Si vous vous en souvenez, membre est la terminologie Oracle pour un fichier
journal de rétablissement qui fait partie d'un groupe de journalisation. Essayons la
même chose pour les fichiers de données. Cette fois, nous allons utiliser la vue
dba_data_files.
Tapons donc select file_name, tablespace_name de dba_data_files; Et là nous
l'avons. Une liste de tous les fichiers de données et de leurs emplacements
physiques. Rappelez-vous, les fichiers de données sont la manifestation physique du
stockage de base de données Oracle pour les données. C'est pourquoi nous
pouvons réellement voir les emplacements des fichiers de données dans notre
système de fichiers Linux, et nous voyons aussi quels tablespaces chaque fichier de
données appartient.
Nous pouvons donc voir que le fichier de données
/mnt/san_storage/oradata/orcl/system01.dbf appartient à l'espace
de table système. Notez que pour les journaux de rétablissement, nous utilisons la
vue v $ logfile, alors que pour les fichiers de données, nous utilisons la vue
dba_data_file. Diverses vues de dictionnaire de données ont différents préfixes
différents en fonction de leur contenu, mais n'arrêtons pas ici.
Voyons également notre fichier de contrôle de base de données. Pour ce
faire, décrivons d'abord la vue v $ controlfile, et sélectionnons name à partir de v $
controlfile pour voir l'emplacement de nos fichiers de contrôle de base de
données. Nous pouvons voir que nous avons deux fichiers de contrôle. En effet,
notre base de données a été configurée avec le multiplexage de fichiers de contrôle.
Donc, Oracle stocke plus d'une copie du fichier de contrôle dans deux endroits
différents pour la redondance. Nous pouvons bien sûr changer ces endroits là où
nous voulons. Une autre vue utile du dictionnaire de données est v $ session, que
nous pouvons utiliser pour voir qui est actuellement connecté à notre base de
données Oracle. Jetons un coup d'oeil à la structure de cette vue de session v
$. Donc desc v $ session, et comme vous pouvez le voir, nous avons beaucoup de
colonnes dans cette vue car nous pouvons obtenir beaucoup d'informations utiles sur
les sessions en cours qui sont connectées à la base de données.
Essayons-le en tapant select, et utilisons USERNAME, ainsi que PROGRAM, ainsi
que les colonnes MACHINE. Nom d'utilisateur, programme et machine de v $
session. Nous avons maintenant une liste de tous les utilisateurs connectés à notre
base de données Oracle, le programme qu'ils exécutent et la machine à partir de
laquelle ils sont connectés.
Nous ne voyons réellement qu'un seul utilisateur ici. SYS connecté à partir de SQL
+, s'exécutant à partir de la même machine sur laquelle la base de données Oracle
est en cours d'exécution. C'est ma session actuelle. La raison pour laquelle vous
voyez toutes ces lignes avec des valeurs vides sous le nom d'utilisateur, c'est parce
que nous voyons aussi les processus d'arrière-plan Oracle, les processus d'arrière-
plan de l'instance Oracle, en tant que sessions. Par exemple, nous pouvons voir
DBW0, qui est l'auteur de la base de données Oracle.
Nous pouvons également voir LGWR, qui est l'enregistreur de journal Oracle. La vue
de session v $ nous montre donc à la fois les processus d'arrière-plan de
l'instance, ainsi que toutes les sessions utilisateur connectées telles que SYS, qui est
à nouveau l'utilisateur auquel je suis actuellement connecté via ma fenêtre SQL
+. Donc là vous l'avez. Un aperçu rapide du dictionnaire de données Oracle et
comment l'interroger. Je parie qu'à ce stade, vous pouvez commencer et avoir une
idée de la puissance du dictionnaire Oracle.
À l'aide de commandes SQL simples, vous pouvez obtenir beaucoup
d'informations sur la configuration de la base de données et sur son état actuel. Vous
pouvez même filtrer le résultat. Par exemple, je peux utiliser la même requête, que je
viens de spécifier, mais ajouter où username = 'SYS', et je ne recevrai qu'une ligne
montrant ma session actuelle.

Résoudre les problèmes en utilisant le journal des

alertes

Le fichier journal des erreurs de la base de données Oracle s'appelle le journal des
alertes. Il contient une liste chronologique des événements, erreurs, avertissements,
tout ce qui s'est passé dans la base de données depuis sa création. C'est l'aller au
fichier quand un DBA doit résoudre les problèmes d'infrastructure de la base de
données Oracle. Le fichier journal des alertes est un fichier texte que nous pouvons
facilement ouvrir avec n'importe quel éditeur de texte. Commençons par
rechercher l'emplacement du journal d'alerte.
Il est placé dans un sous-répertoire de notre répertoire de base Oracle. Nous
pouvons voir la valeur de notre répertoire de base de soulignement Oracle en tapant
echo $ Oracle_BASE dans l'invite Linux. Rappelez-vous que les variables
d'environnement telles que la base Oracle ainsi que d'autres doivent être configurées
par le DBA. Alors allons-y et ouvrez le répertoire de base Oracle.
Cd / u01 / app / oracle. Dans le répertoire de base Oracle, nous avons un sous-
répertoire appelé diag court pour les diagnostics. Allons dans ce répertoire. Sous le
répertoire diag, nous devrons aller dans le sous - répertoire SGBDR car nous
recherchons le journal des erreurs ou le fichier journal des alertes de la base de
données.
RDBMS est synonyme de système de gestion de base de données
relationnelle. Dans le répertoire RDBMS, nous avons un autre sous-répertoire appelé
ORCL ou le nom de notre base de données, alors allons-y. Et à l'intérieur d'ORCL
nous avons aussi un autre sous-répertoire appelé ORCL, car c'est le nom de notre
instance Oracle. Alors allons dans celui-là aussi. Maintenant, dans le deuxième
répertoire ORCL, nous avons un sous-répertoire appelé Trace.
Ce répertoire contient à la fois le fichier journal des alertes ainsi que de nombreux
fichiers de trace qui sont des fichiers incidents créés lors d'erreurs spécifiques dans
la base de données Oracle. Nous sommes spécifiquement intéressés par le fichier
journal d'alerte. Alors ouvrons ce fichier en utilisant la commande Linux less. Tapons
moins alert_orcl., Qui est le nom de notre instance, .log et appuyez sur Entrée.
Nous y avons, le contenu du fichier journal d'alerte de base de données ou le fichier
journal des erreurs. Toute erreur, message ou message d'information ou message
d' avertissement, tout événement survenu dans notre base de données depuis sa
création est documenté dans ce fichier. Nous pouvons faire défiler vers le bas en
utilisant soit la touche espace et voir une longue liste d'événements. Tout ce qui est
arrivé dans notre base de données.
Tels que la création de la base de données elle-même. Ou nous pouvons également
utiliser les flèches du clavier pour faire défiler vers le haut et vers le bas. Lorsqu'une
erreur Oracle est survenue, une erreur qui exige habituellement que nous fassions
attention, elle inclura également un code d'erreur Oracle. Chaque erreur Oracle a un
code d'erreur spécifique. Les codes d'erreur Oracle commencent par un préfixe
ORA. Cherchons donc les erreurs dans notre fichier journal d'alerte.
Pour ce faire, tapons / ORA-enter. Comme nous pouvons le voir, nous avons
plusieurs erreurs Oracle. Chaque type d'erreur avec son propre code d'erreur
unique tous préfixés par ORA - dans notre fichier journal d'alerte. Nous pouvons
appuyer sur la touche de fin de clavier pour avancer entre ces erreurs. Ne vous
inquiétez pas de ces erreurs, car il s'agit simplement d'un environnement
d'entraînement local.
Nous pouvons quitter le dernier éditeur de texte en appuyant sur Q sur le
clavier. Rappelez-vous, il incombe à l'administrateur de base de données de
surveiller le fichier journal des alertes pour déceler toute erreur qui aurait pu
survenir lors du fonctionnement de la base de données. Il y a beaucoup d'outils qui
peuvent être utilisés pour accomplir cela et vous savez ce qu'ils disent, "A chacun
son". Notez également qu'il est de la responsabilité de DBA de nettoyer
régulièrement le répertoire des journaux et les fichiers de trace contenu dans, car
ceux - ci peuvent consommer un peu d'espace au fil du temps et que vous ne voulez
pas que vos serveurs de base de données ne parce que vos disques ont couru hors
de l' espace en raison de fichiers journaux.
Veillez donc à surveiller la taille de vos répertoires de journaux Oracle et prenez
l'habitude de surveiller fréquemment le contenu du fichier journal des alertes de la
base de données.

Stockage: tablespaces et fichiers de données

La manifestation physique du système de stockage de base de données Oracle pour

les données utilisateur est constituée de fichiers de données. Toutes les données de
la base de données sont stockées dans des fichiers de données. Toutefois, lorsqu'un
utilisateur crée une table, les utilisateurs spécifient l'espace table dans lequel cette
table doit être créée. Un espace table est une collection de fichiers de données
utilisés pour le stockage. Voyons les noms des espaces table existants que nous
avons déjà définis dans notre base de données. Pour ce faire, ouvrons une invite
sqlplus de l'utilisateur sysdba et ouvrons une session sur notre base de données.
Nous pouvons utiliser l'affichage du dictionnaire de données dba_tablespaces pour
afficher des informations sur les espaces table existants. Commençons par décrire la
structure de la vue dba_tablespaces. Rappelez-vous, pas besoin de point-virgule à la
fin de cette commande, car la commande describe n'est pas une instruction sql, c'est
une commande interne pour sqlplus. Une fois que nous connaissons la structure de
l' affichage du dictionnaire de données dba_tablespaces , nous pouvons afficher les
noms des espaces table existants en écrivant select tablespace_name from
dba_tablespaces, et nous pouvons voir que nous avons six espaces table déjà créés
dans notre base de données.
Ce sont les espaces table par défaut créés dans le cadre de l'installation
d'Oracle. Par exemple, l'espace table de l'assistant est utilisé pour stocker le
dictionnaire de données Oracle lui-même, donc si vous avez perdu cet espace
table, vous avez essentiellement perdu votre base de données. Nous pouvons
également obtenir une liste de fichiers de données dans notre base de données et
les espaces de table auxquels ils appartiennent en tapant select
nom_fichier, nom_table_données de dba_data_files, et comme nous pouvons le voir,
nous avons une liste de fichiers de données et leur espace table correspondant.
Nous pouvons réellement voir l'emplacement physique, le chemin physique de ces
fichiers de données. Nous pouvons créer nos propres espaces de table, essayons
cela. Tapons create tablespace, et donnons-lui un nom, tel que my_data. Rappelez-
vous, c'est le nom que les utilisateurs devront utiliser quand ils voudront que leurs
tables soient créées dans cet espace table. Nous devrons créer un ou plusieurs
fichiers de données pour cet espace table, et nous pouvons le faire dans le cadre de
la commande en spécifiant le fichier de données, puis l'emplacement où nous
voulons que ce fichier de données soit créé.
Utilisons le même chemin que tous nos autres fichiers de données, qui dans ma
machine est juste un répertoire local sur le système de fichiers Linux, mais rappelez
- vous, dans une base de données de production Oracle, ce chemin doit être un
répertoire de stockage d'entreprise hautement disponible, et nous devons également
spécifier un nom pour le fichier de données, tel que my_data01.dbf, juste au cas où
nous aimerions ajouter plus de fichiers de données à cet espace table dans le futur,
et nous pouvons le faire.
N'oubliez pas de fermer le chemin d' accès au fichier de données avec le
guillemet. Nous devons également spécifier la taille du fichier de
données. Commençons avec 200 mégaoctets. Nous pouvons également configurer
le fichier de données pour qu'il s'étende automatiquement s'il a épuisé tout son
espace de stockage existant. Pour ce faire, nous spécifions le mot-clé autoextend,
puis sur. Et voilà, nous avons créé notre propre espace de table.
Nous pouvons maintenant le voir maintenant ainsi que son fichier de données en
tapant select nom_fichier, nom_espace_de_dba_données_fichiers, et voilà, notre
nouvel espace table my_data en bas de notre sortie, juste au-dessus de l'espace
table d'annulation. Nous pouvons voir qu'il a un fichier de données associé. Lorsque
nous créons notre table, nous pouvons également choisir qu'elle sera créée dans un
espace table spécifique.
Alors créons une table de test et choisissons qu'elle sera créée dans notre nouvel
espace table my_data. Nous tapons simplement create table, et donnons-lui un
nom tel que my_first_table, disons qu'il a une seule colonne, colonne un, et c'est une
colonne numérique. Après la commande create table, nous spécifions simplement
tablespace, et my_data, qui est le nom de l'espace table que nous venons de créer.
Notre nouvelle table va maintenant être placée à l'intérieur de cet espace de table, et
toutes les données que nous insérons dans notre table my_first_table, ça sonne
drôle, n'est-ce pas? Sera réellement stocké dans le fichier de données
my_data01.dbf que nous avons associé à notre espace table. Allons un peu plus loin
et voyons notre fichier de données actuel dans notre système de fichiers
Linux. Rappelez-vous, les fichiers de données sont des manifestations physiques du
stockage Oracle, donc pour ce faire, nous allons quitter sqlplus et cédons dans le
répertoire mnt / san_storage / oradata / oracl où tous nos fichiers de données sont
stockés.
Tapez ls, nous pouvons voir tous nos fichiers de données, y compris le fichier de
données que je viens de créer, my_data01.dbf, c'est le troisième à partir de la
gauche. Nous pouvons également voir la taille des fichiers de données en tapant ls -l
$ et nous pouvons voir que le fichier de données my_data01.dbf a une taille
d'environ 200 mégaoctets.
C'est ce que nous avons spécifié quand nous avons créé l'espace table. Voyons
comment nous pouvons laisser tomber notre espace table nouvellement
créé. Ouvrons une connexion sqlplus avec l'utilisateur sys. Encore une fois,
connectez - vous sur notre base de données et tablespace baisse de type my_data,
et porter une attention particulière à ce qui suit, je dois aussi préciser le mot - clé , y
compris le contenu et les fichiers de données, qui instruira Oracle pour supprimer
l'espace table my_data même si elle a des tables créé à l' intérieur il.
Le paramètre des fichiers de données fin supprime également les fichiers de
données du système de fichiers Linux. Donnons-nous un moment, et là nous
l'avons, notre espace de table a été abandonné. Pour en revenir au système de
fichiers Linux, nous voyons que le fichier de données est introuvable. Oracle a
nettoyé après nous. Voici donc un bref aperçu de la façon dont vous pouvez créer et
afficher des espaces table et des fichiers de données dans une base de données
Oracle.