Vous êtes sur la page 1sur 9

INTRODUCTION

Introducing Oracle Database 12c Components


and Architecture
Présentation des composants d'Oracle Database 12c
et son architecture

L'objectif de ce chapitre consiste à:


- lister l'architecture des composants d'Oracle Database.
- Comprendre les structures mémoires.
- Décrire les processus background.
- Détailler la relation entre les structures de stockage physiques et logiques.
- décrire les outils de management de la base de données.

Exploring the Oracle Database Architecture


■■ List the architectural components of Oracle Database.
■■ Explain the memory structures.
■■ Describe the background processes.

■■ Explain the relationship between logical and physical

storage structures.
✓✓ Oracle Database Management Tools
■■ Use database management tools.

Les objets d'une base de données oracle 12c

oracle 12c supporte l'intégralité des objets d'une base de données requise pour une base de données relationnelle ou
une base de données objet-relationnel: tables, vues, contraintes, ainsi que des objets spécifiques à oracle tels que les
packages, les séquences, les vues matérialisée, ...etc.

objets d'une base de données oracle 12c


Type d'objet Description
Table La table est l'objet principal pour le stockage des données.
Vue Une vue est une requête stockée. pas d'espace de stockage réservé pour les données
d'une vue.
Index Un index est une structure optionnelle utilisée pour accélérer la recherche des données dans une
base de données.
Vue matérialisée Contrairement à la vue standard, dans une vue matérialisée les données sont dupliquées.
On l’utilise essentiellement à des fins d'optimisation et de performance dans le cas où la
requête associée est particulièrement complexe ou lourde, ou pour faire
des réplications de table.
La fraîcheur des données de la vue matérialisée dépend des options choisies lors de sa
création. Le décalage entre les données de la table maître et la vue matérialisée peut être
nul (rafraîchissement synchrone) ou d'une durée planifiée : heure, jour, etc. Suivant le
contexte il existe différents types de vue matérialisée possibles : sur clé primaire, rowid
(identifiant unique des tuples), et plus ou moins complexes : avec fonctions d'agrégation,
sous-requêtes, jointures, etc.

Syntaxe minimale pour la création d'une vue matérialisée sous Oracle :

CREATE MATERIALIZED VIEW MV1


AS SELECT Col1, Col2, [...], Coln FROM scott.emp

Requête de création d'une vue matérialisée avec précision de la fréquence de


rafraichissement sous Oracle :

CREATE MATERIALIZED VIEW MV_UneVueMaterialisee


REFRESH FAST
START WITH SYSDATE
NEXT SYSDATE + 1
AS SELECT Col1, Col2, [...], Coln FROM monSchema.MaTable;

Pour retrouver le select d'une vue matérialisée sous Oracle :


SELECT QUERY FROM ALL_MVIEWS
WHERE MVIEW_NAME='MV1'

Table IOT (Index-organized Une table IOT stocke la table de données avec les données de l'index au lieu de les stocker de
table) façon séparée.
Cluster A cluster is a group of tables sharing a common column.
The cluster stores the rows of the tables together
with the common columns stored once. A cluster is a group of tables sharing a common column.
The cluster stores the rows of the tables together
with the common columns stored once.

Use the CREATE CLUSTER statement to create a cluster. A cluster is a schema


object that contains data from one or more tables, all of which have one or more
columns in common. Oracle Database stores together all the rows from all the tables
that share the same cluster key.

For information on existing clusters, query the USER_CLUSTERS, ALL_CLUSTERS,


and DBA_CLUSTERS data dictionary view

Contrainte Une contrainte d'intégrité est une règle qui définit la cohérence d'une donnée ou d'un
ensemble de données de la BD.
Il existe deux types de contraintes :
sur une colonne unique,
ou sur une table lorsque la contrainte porte sur une ou plusieurs colonnes.
Les contraintes sont définies au moment de la création des tables.
Les contraintes d'intégrité sur une colonne sont :
PRIMARY KEY : définit l'attribut comme la clé primaire
UNIQUE : interdit que deux tuples de la relation aient la même valeur pour l'attribut.
REFERENCES <nom table> (<nom colonnes>) : contrôle l'intégrité référentielle entre
l'attribut et la table et ses colonnes spécifiées
CHECK (<condition>) : contrôle la validité de la valeur de l'attribut spécifié dans la
condition dans le cadre d'une restriction de domaine
Les contraintes d'intégrité sur une table sont :
PRIMARY KEY (<liste d'attibuts>) : définit les attributs de la liste comme la clé
primaire
UNIQUE (<liste d'attibuts>) : interdit que deux tuples de la relation aient les mêmes
valeurs pour l'ensemble des attributs de la liste.
FOREIGN KEY (<liste d'attibuts>) REFERENCES <nom table>(<nom colonnes>) :
contrôle l'intégrité référentielle entre les attributs de la liste et la table et ses colonnes
spécifiées
CHECK (<condition>) : contrôle la validité de la valeur des attributs spécifiés dans la
condition dans le cadre d'une restriction de domaine

séquence La notion de compteur ou de suite de nombres est implémentée sous Oracle à l'aide des
séquences.

Une séquence est donc un objet appartenant à un schéma, générateur de nombres de 38


chiffres.

On récupère le prochain n° de séquence via la pseudocolonne NEXTVAL, et le n°


courant via la pseudocolonne CURRVAL, ceci pour une session données.

Contrairement à la propriété de colonnes IDENTITY présente sous Microsoft SQL


Server ou DB2 , la séquence n'est fonctionnellement pas rattachée à la table qui l'utilise,
ce qui a ses avantages et ses défauts:

 Avantage : plusieurs tables peuvent se partager une séquence (ce qui est fort
pratique dans les héritages, lors du traitement d'une clé par des tables filles
mutuellement exclusives)
 Désavantage : sans une certaine rigueur, on peut ne plus savoir quel compteur
est utilisé dans une table donnée, mélanger les clés, etc.....

synonyme C'est un Alias sur un Objet de la base ou Schéma, une sorte de raccourcis.


L'Objet peut être une Table, une Vue, une Séquence, une Procédure, une Fonction, un
Package.
Le synonym peut être Public ou Privé.
Public, il sera accessible à partir de tous schéma et user.
Privé il sera accessible uniquement à partir du schéma dans lequel il a été créé.

Pourquoi créer des synonyms?

- Masquer le vrai nom des objets et leur localisations.


- Simplifier les noms des objets.
- Éviter le pré-fixage dans les requêtes avec le nom de son propriétaire.
Trigger Un trigger ou encore un déclencheur est un bloc PL/SQL associé plus particulièrement à
une table. Ce bloc s’exécutera automatiquement lorsqu’une instruction DML (insert ,
update , delete) sera fait sur la table. Il faut savoir qu’un trigger peut être exécuté avant
ou après la modification d’une table , donc avant ou après les différents contraintes . Il y
a une règles très importante à respecter Les triggers ne doivent en aucun cas être utilisés
lorsque vous pouvez utiliser une contrainte. En effet cette dernière étant défini sur la
table , elle est plus rapide.
Syntaxe d’un Trigger
CREATE [OR REPLACE ] TRIGGER nom_trigger
{BEFORE | AFTER | INSTEAD OF }
{INSERT [OR] | UPDATE [OR] | DELETE}
[OF nom_colonne]
ON nom_table/vue
[REFERENCING OLD AS o NEW AS n]
[FOR EACH ROW]
WHEN (condition)
BEGIN
—  requete SQL
END;
Explications
CREATE [OR REPLACE ] TRIGGER nom_trigger : Nous permet de créer /remplacer
(si le nom existe) un trigger
{BEFORE | AFTER | INSTEAD OF }  : Les deux premiers nous permettent de spécifier
à quel moment le trigger sera déclenché et le troisième est utilisé seulement pour les
VUES (les deux autres ne peuvent être utilisés avec les vues)
{INSERT [OR] | UPDATE [OR] | DELETE} : Nous permet de spécifier pour quel
évènement déclencher le trigger (on peut en utiliser plusieurs).
[OF nom_colonne] : Utilisé avec les triggers de type update , nous permet de déclencher
un trigger seulement si une colonne particulière est mise à jour.
[ON nom_table/vue] : Nous permet de dire pour quel table ou vue le trigger est associé.
[REFERENCING OLD AS o NEW AS n] : Ici cette clause va nous permettre tout
simplement de donner un alias aux termes « OLD » et « NEW ». Le terme « OLD »
nous permet de connaitre la ligne avant modification (update) ou en cours de
suppression (delete) alors que le terme « NEW » nous permet de connaître la nouvelle
ligne insérée (insert) ou la ligne après modification (update).
[FOR EACH ROW] : Nous permet de spécifier le trigger en tant que  « Row level
Trigger »(déclencheur de ligne). Un déclencheur de ligne est lancé une fois pour chaque
ligne qui est affectée par l’instruction de déclenchement. (par défaut  Statement Trigger)
WHEN (condition) : Utilisé avec FOR EACH ROW , le trigger s’exécutera seulement si
la ligne respecte la condition.

Procédure stockée Une procédure est un code PL/SQL défini par l’utilisateur et stocké dans la base de
données. Ce qui permet d’éliminer la redondance de code.
Avantages:
• Le code SQL est précompilé.
• Exécution plus rapide (puisque stockée dans le serveur)
• Moins de code redondant
Fonction stockée Les fonctions sont considérées comme des procédures qui retournent des valeurs.
Package Un package est un objets de la base de données qui encapsule d’autres objets
(procédures, fonctions ..)
• Un package a essentiellement deux parties:
– la partie déclaration: dans cette partie sont déclarées les variables globales, les
curseurs, les procédures et les fonctions
– la partie corps du programme: dans cette partie, sont définies les procédures et les
fonctions et les curseurs.
Java Des procédures stockées en java peuvent être stockées dans une base de données oracle
Stored Java procedures can be created in Oracle to
define business processes.
Lien base de données DB Un DBlink est un objet Oracle permettant de créer un lien entre plusieurs base de
Link données Oracle, ce lien peut être sur le même hôte, sur un hôte appartenant au domaine
ou sur tout autre hôte joignable par le protocole TCP/IP.

Oracle Database 12c Architecture


As the DBA,
you take care of each of these tasks, as well as others, which include the following:
■■ Selecting the server hardware on which the database software will run
■■ Installing and configuring the Oracle Database 12c software on the server hardware
■■ Deciding to use Oracle Database 12c Container or a traditional single database (now
known as non-Pluggable Database (PDB).
■■ Creating Oracle Database 12c database
■■ Creating and managing the tables and other objects used to manage the application data
■■ Creating and managing database users
■■ Establishing reliable backup and recovery procedure for the database
■■ Monitoring and tuning database performance
■■ Analyzing trends and forecasting resource and storage requirements

The remainder of this book is dedicated to helping you understand how to perform these
and other important Oracle database-administration tasks. But first, to succeed as an Oracle
DBA, you need to completely understand Oracle’s underlying architecture and its mechanisms.
Understanding the relationship between Oracle’s memory structures, background processes,
and I/O activities is critical before learning how to manage these areas.

The Oracle server architecture can be described in three categories:


■■ Server processes that communicate with users processes and interact with an Oracle
instance to fulfill requests
■■ Logical memory structures that are collectively called an Oracle instance
■■ Physical file structures that are collectively called a database

You will also see how the physical structures map to the logical structures of the database
you are familiar with, such as tables and indexes.
Database is a confusing term that is often used to represent different things on different
platforms; the only commonality is that it is something related to storing data. In Oracle,
however, the term database represents the physical files that store data. An instance is composed
of the memory structures and background processes. Each database should have at
least one instance associated with it. It is possible for multiple instances to access a single
database; such a configuration is known as Real Application Clusters (RAC). In this book,
however, you’ll concentrate only on single-instance databases because RAC is not part of
the OCA certification exam.
components is described in more detail in the following sections, beginning with the userrelated
processes, and is actually fairly simple. This figure is an important piece of fundamental
information when learning about the Oracle Database 12c architecture.
The key database components are memory structures, process structures, and storage structures. Process and
memory structures together are called an instance; the storage structure is called a database. Taken together, the
instance and the database are called an Oracle server.

The Oracle Database 12c architecture

Each Oracle database consists of several schemas that reside in tablespaces. Tablespace is a logical storage structure at
the highest level in the database. Each tablespace consists of one or more data files. The database has user data and
overhead, such as database dictionary, memory, control files, archived log files, flashback files, etc. Do not worry if
you do not understand these components yet; you will get to know them in the next few chapters.
Oracle Database 12c comes with a major architectural change compared to its predecessors. Oracle Database 12c
allows multitenancy, meaning, you can have more than one database in a structure called a container database. The
database overhead will be shared by all the databases in the container database. The databases in the container database
are called pluggable databases. Administration and resource overhead are reduced by going with this architecture.
Figure 8.6 shows database multitenancy.
What Is a Schema?
When working with Oracle, you will often hear the words schema and user used interchangeably.
Is there a difference between the two? Yes and no. A user is a defined database
entity that has a set of abilities to perform activities based on their granted rights. A schema,
which is associated with a user entity, is more appropriately defined as a collection of database
objects. Some examples of database objects are tables, indexes, and views.
A schema can be related to a real person, such as a user of your Sales database who may
have a user ID and password they use to access the database. This user may or may not
own any schema objects.
Because a schema is a collection of objects, DBAs often define a schema to represent
a collection of objects associated with an application. For example, a DBA might create
a schema called SALES and create objects owned by that schema. Then, they can grant
access to other database users who need the ability to access the SALES schema.
In this way, the schema becomes a logical collection of objects associated with an application
and is not tied to any specific user. This ability makes it easy to logically group common
objects that are related to specific applications or tasks using a common schema name.
The main difference is that users are the entities that perform work, and schemas are the
collections of objects on which users perform work.

User and Server Processes


At the user level, two types of processes allow a user to interact with the instance and,
ultimately, with the database: the user process and the server process.
Whenever a user runs an application, such as a human-resources or order-taking application,
Oracle starts a user process to support the user’s connection to the instance. Depending
on the technical architecture of the application, the user process exists either on the user’s own
computer or on the middle-tier application server. The user process then initiates a connection
to the instance. Oracle calls the process of initiating and maintaining communication between
the user process and the instance a connection. Once the connection is made, the user establishes
a session in the instance.
After establishing a session, each user starts a server process on the host server itself.
It is this server process that is responsible for performing the tasks that actually allow the
user to interact with the database. The server processes are allowed to interact with the
instance, but not the user process directly.
Examples of these interactions include sending SQL statements to the database, retrieving
needed data from the database’s physical files, and returning that data to the user.

Server processes generally have a one-to-one relationship with user processes—


in other words, each user process connects to one and only one
server process. However, in some Oracle configurations, multiple user processes
can share a single server process. We will discuss Oracle connection
configurations in Chapter 12, “Understanding Oracle Network Architecture.”

The relationship between user and server processes and the PGA
Creating and Operating Oracle Database 12c

Création et utilisation de la base de données Oracle 12c

Understanding Storage and Space Management


Comprendre le stockage et la gestion de l'espace

Managing Data Concurrency and Undo


Gestion de la simultanéité et de l'annulation des données

Understanding Oracle Network Architecture


Comprendre l'architecture de réseau Oracle

Implementing Security and Auditing


Mise en œuvre de la sécurité et de l'audit

Maintaining the Database and Managing Performance


Maintenance de la base de données et gestion des performances

Using Backup and Recovery


Utilisation de la sauvegarde et de la récupération
Controlling Resources and Jobs
Contrôle des ressources et des emplois

Upgrading to Oracle Database 12c


Mise à niveau vers Oracle Database 12c

Using Grid Infrastructure and Data Movement Tools


Utilisation des outils d'infrastructure de grille et de transfert de données

Vous aimerez peut-être aussi