Chapitre 1 Gestion de La Base de Données Distribuée

Gestion de la base de données distribuée
Vous pouvez gérer un environnement de base de données distribué.
 Concepts de bases de données distribuées
 Gestion d'une base de données distribuée
 Développement d'applications pour un système de base de

données distribué
 Concepts de transactions distribuées
 Gestion des transactions distribuées
1
Concepts de bases de données distribuées
Les concepts liés aux bases de données distribuées incluent :
 Architecture de base de données distribuée
 Liens de bases de données
 Administration de la base de données distribuée
 Traitement des transactions dans un système distribué
 Développement d'applications de bases de données distribuées
2
Un système de base de données distribué permet aux applications
d'accéder aux données de bases de données distantes.
Dans un système de base de données distribué homogène, chaque

base de données est un Base de Oracle.
Dans un système de base de données distribué hétérogène, au

moins l'un des bases de données ne sont pas une base de données
Oracle
3
Les bases de données distribuées utilisent une architecture client /
serveur pour traiter les requêtes.
Systèmes homogènes de bases de données distribuées

Un système de base de données distribué homogène comprend
uniquement un SGBD Oracle.
Systèmes de bases de données distribuées hétérogènes

Un système de base de données distribué hétérogène inclut à la fois
bases de données Oracle et bases de données non-Oracle.
4
5
Note :
Une application peut simultanément accéder ou modifier les
données de plusieurs bases de données dans un seul environnement
distribué.
Exemple:
une seule requête à partir d'un client de Manufacturing sur la base
de données locale mfg peut récupérer les données jointes de la
Table produits sur la base de données locale et la table dept sur la
base de données hq distante.
Note: Pour une application client, l'emplacement et la plate-forme

des bases de données sont transparents.
6
Vous pouvez également créer des synonymes pour les objets distants
dans le système distribué afin que les utilisateurs peuvent y accéder
avec la même syntaxe que les objets locaux.
Exemple:
si vous êtes connecté à la base de données mfg mais vous voulez
accéder aux données sur la base de données hq, créant Un
synonyme sur mfg pour la table dept distante vous permet d'émettre
cette requête:
SELECT * FROM dept;
7
Bases de données distribuées VS traitement distribué
Les termes base de données distribuée et traitement distribué sont
étroitement liés, mais ont des significations distinctes.
Distributed database
Un ensemble de bases de données dans un système distribué qui
peut apparaître aux applications en tant que source de données
unique.
Distributed processing
Les opérations qui se produisent lorsqu'une application distribue ses
tâches entre différents ordinateurs dans un réseau.
8
Les termes système de base de données distribué et la réplication de

base de données sont liés, mais distinct.
Dans une base de données distribuée pure (c'est-à-dire non

répliquée), le système gère une seul copie de toutes les données.
Généralement, les applications de base de données distribuée

utilisent des transactions distribuées pour accéder aux données
locales et distantes et modifier la base de données globale en temps
réel.
9
Replication : Le terme réplication fait référence à l'opération de
copie et de maintenance des objets de base de données dans
plusieurs bases de données appartenant à un système distribué.
Systèmes de bases de données distribuées hétérogènes

Dans un système de base de données distribué hétérogène, au
moins au niveau d’un site, on un système de bdd non oracle.
Pour l'application, le système de base de données distribué

hétérogène apparaît comme un seul, local, Base de données Oracle.
Au niveau locale, le SGBD Oracle gère d’une façon transparente la

localisation des données.
10
Client/Server Database Architecture
Le serveur de base de données est le logiciel Oracle gérant une base
de données
Le client est une application qui envoi des requêtes au serveur de

base de données
Chaque ordinateur dans le réseau peut heberger une ou plusieurs
bdd
Chaque nœud peut aggire comme client, serveur ou les deux
11
12
Database Links
Le concept central dans les systèmes de base de données distribués

est celui des liens de base de données
Un lien de base de données est une connexion entre deux serveurs

de bases de données physiques qui permet à un client d'accéder à
eux comme une seul base de données logique.
Remarques:
Un lien de base de données est un pointeur qui définit un chemin à
un sens unique d‘un serveur de bdd Oracle vers un autre serveur de
bdd
13
Cette figure montre un example d’un utilisateur scott qui accède à la table emp qui se
trouve au niveau de la bdd distante de nom global hq.example.com:
14
Type de liens
Type de lien Description

Connected user link Les utilisateurs doivent avoir un des compts au niveau de la bdd
distante avec le meme mot de passe et logine que leurs compte
locaux.
Fixed user link Les utilisateurs se connectent le nom utilisateur et mot de passe
referencé dans le link.
Current user link L’utilisateur se connecte comme un utilisateur global. Un

utilisateur local se connect comme un utilisateur global dans le
contexte de procedure stockées sans avoir le login et le mot de
passe.
15
Lien de bdd partagé (Shared Database Links)
 Un lien de bdd partagé, est un lien entre un processus serveur

local et une bdd distante.
 Le lien est partagé, parceque plusieurs processus client peuvent

partager le meme lien simultanément.
Pourquoi utiliser les Liens de BDD ?
 Intégration de bdd
 Permettre à un utilisateur d’ acceder aux autres objets distant
d’un autre utilisateur
16
Lien de bdd partagé (Next) (Shared Database Links)
Lorsqu'une base de données locale est connectée à une base de

données distante via un lien de base de données, l'une ou l'autre
base de données peut s'exécuter en mode serveur dédié ou
partagé.
Local Database Mode Remote Database Mode
Dedicated Dedicated
Dedicated Shared server
Shared server Dedicated
Shared server Shared server
17
Liens partagés VS Liens de Base de Données Standard
 Partage de connexion reseau pour acceder aux objets d’un

meme schéma
 Les processus qui accèdent à la bdd distante peuvent

réutiliser les conexion déja établies
 Avec le mode serveur partagé, la conexion est établie

facilement (pas de processus dediés)
18
Nom Global De la base de données dans les liens de bdd
Chaque bdd dans une bdd distribuée est identifiée par son nom
global de bdd
Le nom global de la bdd est formé par: DB_DOMAIN. DB_NAME
DB_DOMAIN : database network domain
DB_NAME : individual database name
19
Nom Global De la base de données dans les liens de bdd (Next)
Exemple:
20
Le nom de la bdd est formé en commençant de la feuille de l’arbre

et en suivant le chemin vers la recine
Le nom de la bdd mfg est : mfg.division3.example_tools.com
Le nom de la bdd Finance est : Finance.division1.example_tools.com
21
Le système de nomage , fait difference entre la bdd sales dans la

division americaine et la bdd sales dans l’europe division comme
suit.
sales.us.americas.example_auto.com
sales.uk.europe.example_auto.com
22
Syntaxe pour créer un lin de bdd
Après la création du lien de bdd, on peut l’utiliser dans des requêtes
SQL pour accéder aux tables, vue et objet PL/SQL dans l’autre bdd
en ajoutant @dblink aux nom de: tables, vues et objets PL/SQL
Prérequis:
 Pour créer un lien de bdd privé, il faut avoir le privilège système
CREATE DATABASE LINK
 Pour créer un lien de bdd public, il faut avoir le privilège système
CREATE PUBLIC DATABASE LINK
 Il faut avroir le privilège système CREATE SESSION au niveau de la
bdd distante
 Oracle Net doit être installé au niveau des bases de données local
et distante
23
Syntax
CREATE [ SHARED ] [ PUBLIC ] DATABASE LINK dblink

[ CONNECT TO
{ CURRENT_USER
| user IDENTIFIED BY password [ dblink_authentication ]
}
| dblink_authentication
]...
[ USING connect_string ] ;
dblink_authentication
AUTHENTICATED BY user IDENTIFIED BY password
24
Semantics
PUBLIC :
 Specify PUBLIC to create a public database link visible to all users.
 If you omit this clause, then the database link is private and is
available only to you.
 The data accessible on the remote database depends on the

identity the database link uses when connecting to the remote
database:
25
PUBLIC (Next)
 If you specify CONNECT TO user IDENTIFIED BY password, then

the database link connects with the specified user and password.
 If you specify CONNECT TO CURRENT_USER, then the database

link connects with the user in effect based on the scope in which
the link is used.
 If you omit both of those clauses, then the database link connects
to the remote database as the locally connected user.
26
SHARED
Specify SHARED to create a database link that can be shared by
multiple sessions using a single network connection from the source
database to the target database.
Dblink :
 Specify the complete or partial name of the database link.
 If you specify only the database name, then Oracle Database
implicitly appends the database domain of the local database.
27
Restriction on Creating Database Links
 You cannot create a database link in another user's schema,

and you cannot qualify dblink with the name of a schema.
 Periods are permitted in names of database links, so Oracle

Database interprets the entire name, such
as ralph.linktosales, as the name of a database link in your
schema rather than as a database link named linktosales in
the schema ralph.)
CONNECT TO Clause
The CONNECT TO clause lets you specify the user and
credentials, if any, to be used to connect to the remote database
28
CURRENT_USER Clause
Specify CURRENT_USER to create a current user database link.
The current user must be a global user with a valid account on
the remote database.
user IDENTIFIED BY password

Specify the user name and password used to connect to the
remote database using a fixed user database link.
If you omit this clause, then the database link uses the user
name and password of each user who is connected to the
database.
29
dblink_authentication
 You can specify this clause only if you are creating a shared
database link—that is, you have specified the SHARED clause.
 Specify the username and password on the target instance.
 This clause authenticates the user to the remote server and is

required for security.
30
USING 'connect string‘
Specify the service name of a remote database.
If you specify only the database name, then Oracle Database

implicitly appends the database domain to the connect string to
create a complete service name.
if the database domain of the remote database is different from

that of the current database, then you must specify the
complete service name.
31
Remarques:
 Les liens de bdd sont utiliser entre bdd Oracle
 Pour acceder à une bdd distante non oracle on utilise Oracle
Heterogeneous Services.
32
Transaction distante
Une transaction distante contient une ou plusieurs instructions
distantes, toutes faisant référence à nœud distant unique.
Example:
UPDATE scott.dept@sales.us.americas.example_auto.com
SET loc = 'NEW YORK'
WHERE deptno = 10;
UPDATE scott.emp@sales.us.americas.example_auto.com
SET deptno = 11
WHERE deptno = 10;
COMMIT;
33
Distributed Transactions
Une transaction distribuée est une transaction qui comprend une ou
plusieurs instructions qui, individuellement ou en groupe, m-à-j les
données sur deux ou plusieurs nœuds distincts d'un dans une bdd
distribuée.
Exemple:
UPDATE scott.dept@sales.us.americas.example_auto.com
SET loc = 'NEW YORK‘
WHERE deptno = 10;
UPDATE scott.emp
SET deptno = 11
WHERE deptno = 10;
COMMIT;
34
Mécanisme de validation en deux phases
Le mécanisme de validation en deux phases de la base de données
garantit que tous les serveurs de base de données participant à une
transaction distribuée
 soit ils valident tous la transaction
 soit ils annulent tous la transaction
35
What Are Distributed Transactions?
A distributed transaction includes one or more statements that,
individually or as a group, update data on two or more distinct nodes
of a distributed database.
36
Example:
UPDATE scott.dept@hq.us.example.com
SET loc = 'REDWOOD SHORES'
WHERE deptno = 10;
UPDATE scott.emp
SET deptno = 11
WHERE deptno = 10;
UPDATE scott.bldg@maint.us.example.com
SET room = 1225
WHERE room = 1163;
COMMIT;
37
There are two types of permissible operations in distributed
transactions: DML and DDL transactions, and transaction control
statement.
DML and DDL Transactions
 CREATE TABLE AS SELECT

 DELETE
 INSERT (default and direct load)
 UPDATE
 LOCK TABLE
 SELECT
 SELECT FOR UPDATE
38
Transaction Control Statements
Some transaction control statements are supported in distributed
transactions. The following are the supported transaction control
statements:
 COMMIT
 ROLLBACK
 SAVEPOINT
39
Session Trees for Distributed Transactions
A session tree is a hierarchical model that describes the relationships
among sessions and their roles.
About Session Trees for Distributed Transactions

As the statements in a distributed transaction are issued, the
database defines a session tree of all nodes participating in the
transaction.
40
About Session Trees for Distributed Transactions
41
All nodes participating in the session tree of a distributed transaction
assume one or more of the following roles:
Role Description
Client A node that references information in a database belonging to a

different node.
Database server A node that receives a request for information from another node.
Global coordinator The node that originates the distributed transaction
Le noeud à l'origine de la transaction distribuée
Local coordinator A node that is forced to reference data on other nodes to complete
its part of the transaction
Un noeud obligé de référencer des données sur d'autres noeuds
pour les compléter
sa partie de la transaction
Commit point site The node that commits or rolls back the transaction as instructed
by the global coordinator.
42
The role a node plays in a distributed transaction is determined by:
 Whether the transaction is local or remote
 The commit point strength of the node
 Whether all requested data is available at a node, or whether
other nodes need to be referenced to complete the transaction
 Whether the node is read-only
43
Local Coordinators
A local coordinator is responsible for coordinating the transaction
among the nodes it communicates directly with by:
 Receiving and relaying transaction status information to and from

those nodes
 Passing queries to those nodes
 Receiving queries from those nodes and passing them on to other

nodes
 Returning the results of queries to the nodes that initiated them
44
Global Coordinator
The node where the distributed transaction originates is called the
global coordinator
The global coordinator becomes the parent or root of the session

tree.
The global
coordinator performs the following operations during a distributed
transaction:
45
 Sends all of the distributed transaction SQL statements, remote
procedure calls, and so forth to the directly referenced nodes,
thus forming the session tree
 Instructs all directly referenced nodes other than the commit

point site to prepare the transaction
 Instructs the commit point site to initiate the global commit of the
transaction if all nodes prepare successfully
 Instructs all nodes to initiate a global rollback of the transaction if

there is an abort response
46
Commit Point Site
The system administrator always designates one node to be the
commit point site.
About the Commit Point Site

The job of the commit point site is to initiate a commit or roll back
operation as instructed by the global coordinator.
The system administrator always designates one node to be the

commit point site in the session tree by assigning all nodes a commit
point strength.
The node selected as commit point site should be the node that
stores the most critical data.
47
48
The commit point site is distinct from all other nodes involved in a
distributed transaction in these ways:
 The commit point site never enters the prepared state.

Consequently, if the commit point site stores the most critical
data, this data never remains in-doubt, even if a failure occurs.
 The commit point site commits before the other nodes involved in
the transaction. In effect, the outcome of a distributed transaction
at the commit point site determines whether the transaction at all
nodes is committed or rolled back: the other nodes follow the
lead of the commit point site. The global coordinator ensures that
all nodes complete the transaction in the same manner as the
commit point site.
49
How a Distributed Transaction Commits
A distributed transaction is considered committed after all non-
commit-point sites are prepared, and the transaction has been
actually committed at the commit point site.
The redo log at the commit point site is updated as soon as the
distributed transaction is committed at this node.
Note:
In the same way, a distributed transaction is considered not
committed if the commit has not been logged at the commit point
site.
50
Commit Point Strength (COMMIT_POINT_STRENGTH parameter)
 Every database server must be assigned a commit point strength.
 If a database server is referenced in a distributed transaction, the

value of its commit point strength determines which role it plays
in the two-phase commit.
Note:
Specifically, the commit point strength determines whether a given
node is the commit point site in the distributed transaction and thus
commits before all of the other nodes.
51
how the database determines the commit point site
The commit point site, which is determined at the beginning of the
prepare phase, is selected only from the nodes participating in the
transaction. The following sequence of events occurs:
 Of the nodes directly referenced by the global coordinator, the

database selects the node with the highest commit point strength
as the commit point site.
 The initially-selected node determines if any of the nodes from

which it has to obtain information for this transaction has a higher
commit point strength.
52
how the database determines the commit point site (Next)
 Either the node with the highest commit point strength directly
referenced in the transaction or one of its servers with a higher
commit point strength becomes the commit point site.
 After the final commit point site has been determined, the global
coordinator sends prepare responses to all nodes participating in
the transaction
Example:
53
54
The following conditions apply when determining the commit point
site:
 A read-only node cannot be the commit point site.
 If multiple nodes directly referenced by the global coordinator

have the same commit point strength, then the database
designates one of these as the commit point site.
 If a distributed transaction ends with a rollback, then the prepare

and commit phases are not needed.
55
Two-Phase Commit Mechanism
In a distributed database environment, the database must
coordinate the committing or rolling back of the changes in a
distributed transaction as a self-contained unit.
The commit mechanism has the following distinct phases, which the
database performs automatically whenever a user commits a
distributed transaction:
56
Two-Phase Commit Mechanism (Next)
Phase Description
Prepare phase The initiating node, called the global coordinator, asks
participating nodes other than the commit point site to
promise to commit or roll back the transaction, even if there
is a failure. If any node cannot prepare, the transaction is
rolled back.
Commit phase If all participants respond to the coordinator that they are
prepared, then the coordinator asks the commit point site to
commit. After it commits, the coordinator asks all other
nodes to commit the transaction.
Forget phase The global coordinator forgets about the transaction.
57
Prepare Phase
 Prepare phase is the first phase in committing a distributed

transaction.
 When a node is told to prepare, it can respond in the different

ways.
 The prepare phase in the two-phase commit process includes

specific steps.
58
About Prepare Phase
In this phase, the database does not actually commit or roll back the
transaction.
Instead, all nodes referenced in a distributed transaction are told to

prepare to commit. By preparing, a node:
 Records information in the redo logs so that it can subsequently
either commit or roll back the transaction, regardless of
intervening failures
 Places a distributed lock on modified tables, which prevents reads
59
Types of Responses in the Prepare Phase
When a node is told to prepare, it can respond in the different ways.
Response Meaning
Prepared Data on the node has been modified by a statement in the
distributed transaction, and the node has successfully prepared.
Read-only No data on the node has been, or can be, modified (only queried),
so no preparation is necessary.
Abort The node cannot successfully prepare.
60
Steps in the Prepare Phase
The prepare phase in the two-phase commit process includes
specific steps
To complete the prepare phase, each node excluding the commit

point site performs the following steps:
The node requests that its descendants, that is, the nodes
subsequently referenced, prepare to commit.
Le nœud demande que ses descendants, c'est-à-dire les nœuds par la
suite référencé, préparez-vous à vous engager.
61
Steps in the Prepare Phase (Next)
The node checks to see whether the transaction changes data on

itself or its descendants. If there is no change to the data, then the
node skips the remaining steps and returns a read-only response .
Le noeud vérifie si la transaction modifie les données sur lui-même
ou sur ses descendance. Si les données ne sont pas modifiées, le
nœud ignore le reste étapes et renvoie une réponse en lecture seule.
62
The node allocates the resources it must commit the transaction if

data is changed.
Le noeud alloue les ressources qu'il doit valider la transaction si les
données sont modifiées.
The node saves redo records corresponding to changes made by the

transaction to its redo log.
Le noeud enregistre les enregistrements de reprise correspondant
aux modifications apportées par la transaction à son journal de
refaire.
63
The node guarantees that locks held for the transaction are able to
survive a failure.
Le noeud garantit que les verrous détenus pour la transaction
peuvent survivre à un échec.
The node responds to the initiating node with a prepared response

or, if its attempt or the attempt of one of its descendents to prepare
was unsuccessful, with an abort response
Le nœud répond au nœud initiateur avec une réponse préparée ou, si
sa tentative ou la tentative de l'un de ses descendants de se préparer
a échoué, avec une réponse d'abandon
64
Note:
These actions guarantee that the node can subsequently commit or
roll back the transaction on the node. The prepared nodes then wait
until a COMMIT or ROLLBACK request is received from the global
coordinator.
Commit Phase
The second phase in committing a distributed transaction is the
commit phase. Before this phase occurs, all nodes other than the
commit point site referenced in the distributed transaction have
guaranteed that they are prepared, that is, they have the necessary
resources to commit the transaction.
65
Commit (Next)
Steps in the Commit Phase
The commit phase in the two-phase commit process includes
specific steps. The commit phase consists of the following steps:
1. The global coordinator instructs the commit point site to commit.

2. The commit point site commits.
3. The commit point site informs the global coordinator that it has
committed.
4. The global and local coordinators send a message to all nodes
instructing them to commit the transaction.
5. At each node, the database commits the local portion of the
distributed transaction and releases locks.
66
Commit (Next)
7. At each node, the database records an additional redo entry in the
local redo log, indicating that the transaction has committed.
8. The participating nodes notify the global coordinator that they
have committed.
Note:
When the commit phase is complete, the data on all nodes of the
distributed system is consistent.
67
Guaranteeing Global Database Consistency
Each committed transaction has an associated system change
number (SCN) to uniquely identify the changes made by the SQL
statements within that transaction.
The SCN functions as an internal timestamp (horodatage) that

uniquely identifies a committed version of the database.
In a distributed system, the SCNs of communicating nodes are

coordinated when all of the following actions occur:
68
Guaranteeing Global Database Consistency
 A connection occurs using the path described by one or more

database links
Une connexion se produit en utilisant le chemin décrit par un ou
plusieurs liens de base de données
 A distributed SQL statement executes

Une instruction SQL distribuée s'exécute
 A distributed transaction commits

Une transaction distribuée est validée
69
Note:
Among other benefits, the coordination of SCNs among the nodes of
a distributed system ensures global read-consistency at both the
statement and transaction level.
If necessary, global time-based recovery can also be completed.
During the prepare phase, the database determines the highest SCN
at all nodes involved in the transaction. The transaction then
commits with the high SCN at the commit point site. The commit
SCN is then sent to all prepared nodes with the commit decision.
70
Forget Phase
After the participating nodes notify the commit point site that they
have committed, the commit point site can forget about the
transaction.
1. After receiving notice from the global coordinator that all nodes
have committed, the commit point site erases (effacer) status
information about this transaction.
2. The commit point site informs the global coordinator that it has
erased the status information.
3. The global coordinator erases its own information about the

transaction.
71
In-Doubt Transactions (transaction dans le doute)
A transaction becomes in-doubt if the two-phase commit
mechanism fails.
Distributed transactions can become in-doubt in the following ways:
 A server system running Oracle Database software crashes
 A network connection between two or more Oracle Databases

involved in distributed processing is disconnected
 An unhandled software error occurs
72
Automatic Resolution of In-Doubt Transactions
Assume that there are two nodes, local and remote, in the following
scenarios.
The local node is the commit point site. User scott connects to local
and executes and commits a distributed transaction that updates
local and remote.
73
Failure During the Prepare Phase
74
Failure During the Prepare Phase
1. User SCOTT connects to Local and executes a distributed

transaction.
2. The global coordinator, which in this example is also the commit

point site,requests all databases other than the commit point
site to promise to commit or roll back when told to do so.
3. The remote database crashes before issuing the prepare

response back to local.
4. The transaction is ultimately rolled back on each database by the

RECO processwhen the remote site is restored.
75
Failure During the Commit Phase
76
Failure During the Commit Phase (Next)
User Scott connects to local and executes a distributed transaction
The global coordinator, which in this case is also the commit point
site, requests all databases other than the commit point site to
promise to commit or roll back when told to do so.
The commit point site receives a prepared message from remote

saying that it will commit.
The commit point site commits the transaction locally, then sends a
commit message to remote asking it to commit.
77
The remote database receives the commit message, but cannot
respond because of a network failure.
The transaction is ultimately committed on the remote database by

the RECO process after the network is restored.
78

Chapitre 1 Gestion de La Base de Données Distribuée

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapitre 1 Gestion de La Base de Données Distribuée

Transféré par

Droits d'auteur :

Formats disponibles

Gestion de la base de données distribuée

Vous pouvez gérer un environnement de base de données distribué.

 Concepts de bases de données distribuées

 Gestion d'une base de données distribuée

 Développement d'applications pour un système de base de

 Concepts de transactions distribuées

 Gestion des transactions distribuées

 Architecture de base de données distribuée

 Liens de bases de données

 Administration de la base de données distribuée

 Traitement des transactions dans un système distribué

 Développement d'applications de bases de données distribuées

Dans un système de base de données distribué homogène, chaque

Dans un système de base de données distribué hétérogène, au

Systèmes homogènes de bases de données distribuées

Systèmes de bases de données distribuées hétérogènes

Note: Pour une application client, l'emplacement et la plate-forme

SELECT * FROM dept;

Les termes système de base de données distribué et la réplication de

Dans une base de données distribuée pure (c'est-à-dire non

Généralement, les applications de base de données distribuée

Systèmes de bases de données distribuées hétérogènes

Pour l'application, le système de base de données distribué

Au niveau locale, le SGBD Oracle gère d’une façon transparente la

Le client est une application qui envoi des requêtes au serveur de

Chaque nœud peut aggire comme client, serveur ou les deux

Le concept central dans les systèmes de base de données distribués

Un lien de base de données est une connexion entre deux serveurs

Type de lien Description

Current user link L’utilisateur se connecte comme un utilisateur global. Un

 Un lien de bdd partagé, est un lien entre un processus serveur

 Le lien est partagé, parceque plusieurs processus client peuvent

Pourquoi utiliser les Liens de BDD ?

Lorsqu'une base de données locale est connectée à une base de

 Partage de connexion reseau pour acceder aux objets d’un

 Les processus qui accèdent à la bdd distante peuvent

 Avec le mode serveur partagé, la conexion est établie

Le nom global de la bdd est formé par: DB_DOMAIN. DB_NAME

DB_DOMAIN : database network domain

DB_NAME : individual database name

Le nom de la bdd est formé en commençant de la feuille de l’arbre

Le nom de la bdd mfg est : mfg.division3.example_tools.com

Le nom de la bdd Finance est : Finance.division1.example_tools.com

Le système de nomage , fait difference entre la bdd sales dans la

CREATE [ SHARED ] [ PUBLIC ] DATABASE LINK dblink

 Specify PUBLIC to create a public database link visible to all users.

 The data accessible on the remote database depends on the

 If you specify CONNECT TO user IDENTIFIED BY password, then

 If you specify CONNECT TO CURRENT_USER, then the database

 You cannot create a database link in another user's schema,

 Periods are permitted in names of database links, so Oracle

user IDENTIFIED BY password

 Specify the username and password on the target instance.

 This clause authenticates the user to the remote server and is

If you specify only the database name, then Oracle Database

if the database domain of the remote database is different from

DML and DDL Transactions

 CREATE TABLE AS SELECT

About Session Trees for Distributed Transactions

Client A node that references information in a database belonging to a

 Receiving and relaying transaction status information to and from

 Passing queries to those nodes

 Receiving queries from those nodes and passing them on to other