Administration des

bases de donnes

Jean-Yves Antoine
http://www.info.univ-tours.fr/~antoine/

J.Y. Antoine

Administration des
bases de donnes

IV SGBD Transactionnels :
protection et scurit des donnes

J.Y. Antoine

OBJECTIFS
4.1. NOTIONS
4.1.1. SGBD transactionnel
4.1.2 Panne : protection et rcupration des donnes
4.1.3. Gestion des accs concurrents

4.2. PRATIQUES
4.2.1. Gestion de transaction en SQL
4.2.2. Panne : journalisation sous Oracle 10g
4.2.3. Squences Oracles

J.Y. Antoine

4.1.1

PANNES & TRANSACTIONS

Type de panne
Panne daction et de transaction : locale la BD
Globale au systme
Panne systme (soft crash): sans atteinte la mmoire physique
Panne mmoire (hard crash) : problme sur la mmoire secondaire

Exemple : gros systmes

Dfaillance
Locale
Soft crash
Hard crash

Frquence
Tps reprise
~ 10 / minute
instantan
2 3 / semaine qques minutes
1 2 / an
qques heures
[Gray 81, Hrder, Reuter 83]

Rsistance aux pannes : mmoire sre

Reprise sur panne

SGBD restreint : pas de support la reprise
SGBD complet : reprise base sur la notion de transaction
J.Y. Antoine

4.1.1

PANNE LOCALE & TRANSACTIONS

Problme
Plusieurs clauses SQL pour une seule action logique
Problme de cohrence si panne lors dune de ces instructions
Exemple Suppression manuelle dun enregistrement en cascade
table2
DELETE FROM table2 WHERE

table1

INSERT INTO table2 VALUES

Transaction
- Unit logique de traitement correspondant un ensemble dactions
- Actions atomiques : validation, annulation et r-excution de transaction
- Unit de base pour la gestion des pannes et celle des accs concurrents

J.Y. Antoine

4.1.1

TRANSACTION
Transaction Unit logique de traitement
forme dune suite dactions limite par une
opration de validation ou dannulation
Validation Publication dfinitive
modifications (enregistrement physique)

OK

des

INSERT INTO
UPDATE
SELECT

OK

Annulation / Invalidation Retour de la BD

ltat en dbut de transaction
En cours de transaction : mmorisation des
actions ralises dans un journal (fichier de
log ou de redo-log) avant et aprs
Accs concurrents : verrous en cours de
transaction

J.Y. Antoine

SELECT
INSERT INTO

NO

OK
ALTER TABLE
.

4.1.1

TRANSACTION
Principes ACID

[Bjork, 1973]

Atomicit

Transactions atomiques (tout ou rien)

Cohrence

Les transactions maintiennent la cohrence de la BD

Isolation

Les Transactions, mmes concurrentes, sont isoles

les unes des autres

Durabilit

Aprs validation, mise jour prenne mme si panne

J.Y. Antoine

Dbut de transaction implicite

Dbut de session ou fin de la transaction prcdente

Fin de transaction implicite

Ordre LDD (CREATE, ALTER, DROP etc.), fin de session ou panne

Fin de transaction explicite

Validation

COMMIT

Termine une transaction par la validation des actions effectues

Annulation des verrous et publication dfinitive des modifications
effectues, qui deviennent alors visibles aux autres utilisateurs

Annulation

ROLLBACK

Termine une transaction en annulant toutes les actions effectues

Annulation des verrous et publication dfinitive des modifications
effectues
J.Y. Antoine

4.1.1

TRANSACTION : SQL

4.1.1

TRANSACTION : SQL

DELETE FROM personne WHERE .... ;

INSERT INTO TABLE personne VALUES ... ;
COMMIT ;
UPDATE personne ... SET ;
ALTER TABLE societe ADD . ;
UPDATE personne ... SET ;
?
DELETE FROM personne WHERE .... ;

ROLLBACK ;
J.Y. Antoine

Contraintes diffres
Il est possible de diffrer la vrification dune contraintes en fin de transaction
Deux statuts : contrainte diffrable (DEFERRABLE) ou non
Deux tats (contrainte diffrable) : immdiate ou diffre (DEFERRED)

Utilisation dune contrainte diffrable

Attribution du caractre diffrable lors de la cration + tat initial
CREATE TABLE piece
(id NUMBER,
elt NUMBER,
CONSTRAINT fk_piece_elt FOREIGN KEY(elt) REFERENCES elt(id)
DEFERRABLE INITIALLY DEFERRED );
INITIALLY IMMEDIATE

Changement dtat dans une transaction ou toute une session

SET

{ CONSTRAINT | CONSTRAINTS} { ctr1 [, ctr2] | ALL}

{ IMMEDIATE | DEFERRED }

ALTER SESSION SET CONSTRAINTS = { IMMEDIATE | DEFERRED }

J.Y. Antoine

4.2.1

ORACLE : TRANSACTIONS & CONTRAINTES

Associer des proprits une transaction

Valable uniquement si aucune autre transaction en cours
SET TRANSACTION [mode_acces] [niveau_isolation]

Niveau disolation

cf. partie verrouillage

SERIALIZABLE | REPEATABLE READ | READ COMMITED | READ UNCOMMITED

Mode daccs
READ ONLY | READ WRITE

READ WRITE incompatible avec READ UNCOMMITED

Sous-transaction
positionnement dun point intermdiaire dans la transaction
SAVEPOINT <point_repere> ;

annulation des actions depuis ce point de repre (et non depuis le dbut)
ROLLBACK TO <point_repere> ;
J.Y. Antoine

4.2.1

ORACLE : PROPRIETES DES TRANSACTIONS

4.1.2

PANNES ET TRANSACTION : JOURNALISATION

Journalisation
- Performance : modifications mmorises en cache
(volatil) et recopie sur disque intervalles prdfinis.
- Scurit : cache perdu lors des pannes systmes
- Journalisation : mmorisation des informations qui ont
t modifies en cache mais pas encore reportes sur
disque

Journal
Id_transaction
Time
Fichier / Page
Valeur avant
Valeur aprs

Journal des images avant

- Valeurs des donnes mises jour et pas encore sur crites sur disque, avant
modification
- Protection des donnes : utilisation pour dfaire une transaction (undo log)

Journal des images aprs

- Valeurs des donnes mises jour et pas encore sur crites sur disque, aprs
modification
- Protection des donnes : utilisation pour rejouer une transaction (redo log)
J.Y. Antoine

 Protection des donnes : journalisation avant action

log
avant

journal

log
aprs

3
donne
lue

Cache

donne
modifie

BD persistante

 Performance : journal galement en mmoire volatile (cache)

 Protection des donnes
validation sauvegarde automatique sur DD
validation aprs criture
J.Y. Antoine

4.1.2

PANNES ET TRANSACTION : JOURNALISATION

Fichiers de journalisation
- Fichiers de redo-log (.rdo ou .log) : journalisation avant et aprs
Peuvent tre multiplexs pour limiter les risques sur panne mmoire
- Dimensionnement du journal : tablespace UNDO
- Restauration de la base : suppression ou archivage (ARCHIVELOG
MODE) du fichier une fois utilis pour rejouer les transactions
- Manipulation : outil Log Miner
Vue

Rle

V$LOGFILE

Description des fichiers de journalisation

V$LOG_HISTORY

Informations sur l'historique de tous les redos

V$LOG

Information sur chaque groupe de log

J.Y. Antoine

4.2.1

JOURNALISATION : ORACLE

4.2.1

JOURNALISATION : ORACLE
Gestion des tablespaces UNDO
- Tablespace : partition logique de la mmoire
- Tablespace UNDO : partition spcifiquement attribue au journal.
- Dimensionnement : importance du dimensionnement du journal : tude
des vues dynamiques du dictionnaire de donnes + outil Undo Advisor
Vue

Rle

DBA_TABLESPACES

Liste des TABLESPACES. Champ CONTENT : type (UNDO)

DBA_UNDO_EXTENTS Caractristiques des UNDO segments

V$UNDOSTATS

J.Y. Antoine

% dutilisation du TABLESPACE

4.1.2

REPRISE APRES PANNE

Panne locale (problme de cohrence de la base)
Gestion immdiate : ROLLBACK explicite ou implicite

Reprise froid : hard crash

support mmoire physique endommag
recopie dune sauvegarde antrieure (dump)
si copie physique du journal non atteinte : on rejoue les actions du journal

Reprise chaud : soft crash

1. Recherche dans le journal du dernier point de reprise systme (copie physique)
2. R-excution des transactions mmorises aprs le point de reprise (redo log)
3. Annulation des transactions journalises mais non encore valides (undo log)
Oracle : gestion automatique laide des segments dannulation (ROLLBACK
segments / UNDO segments)

J.Y. Antoine

4.1.2

REPRISE A CHAUD : SOFT CRASH

Validation logique et sauvegarde physique
point de contrle

crash

(copie physique)

temps

T1

MIT
M
CO
M
CO

T2
T3

MIT
M
CO

MIT

T4
T5
Action de restauration
Aucune
Annulation (Rollback)
Rejouer le transaction
J.Y. Antoine

?
?

Transaction
T1
T4, T5
T2, T3

4.1.2

BD REPARTIES
Validation en deux tapes Double COMMIT
machine
machine
coordinateur
distante 1
distante 2
demande COMMIT distant
demande COMMIT distant
prt
ordre COMMIT distant
COMMIT OK
COMMIT global OK

J.Y. Antoine

prt
ordre COMMIT distant
Commit OK
COMMIT global OK

4.1.2

BD REPARTIES
Panne sur demande de prparation
machine
machine
coordinateur
distante 1
distante 2
demande COMMIT distant
demande COMMIT distant
panne
prt
timeout
ordre ROLLBACK distant
ROLLBACK OK
ROLLBACK global OK

J.Y. Antoine

ordre ROLLBACK distant

ROLLBACK OK
ROLLBACK global OK

reprise

4.1.2

BD REPARTIES
Panne sur validation distante
machine
machine
coordinateur
distante 1
distante 2
demande COMMIT distant
demande COMMIT distant
prt

ordre COMMIT distant

prt

ordre COMMIT distant

panne

COMMIT OK
timeout
COMMIT OK

J.Y. Antoine

reprise

4.1.3

CONCURRENCE : PROBLEME
Accs concurrents
Plusieurs utilisateurs ou applications accdent/modifient aux mmes donnes.
Problmes sur les valeurs de lectures et sur le maintien de la cohrence.

Perte dopration
UPDATE O1

O1

UPDATE O1
Lecture O1
Lecture O1

T1

UPDATE
tampon

UPDATE
tampon
criture O1

T2

Ecriture O1

Perte T2
J.Y. Antoine

4.1.3

CONCURRENCE : PROBLEME
Lecture fantme
Incohrence apparente : laisse croire au non respect des contraintes
CHECK 01 = 02
01

SELECT O1
SELECT O2

02

UPDATE O2
UPDATE O1 (idem)
Lecture O2

criture O2

T1

Lecture O1

T2
Lecture O2

01 02 !!
J.Y. Antoine

Lecture O1
criture O1

4.1.3

CONCURRENCE : PROBLEME
Incohrence de la base
Lecture fantme conduisant des inconsistances permanentes
CHECK 01 = 02
UPDATE O1
UPDATE O2 (idem)
Lecture O1
Ecriture O1

T1
01 02 ??
J.Y. Antoine

Lecture O2

Ecriture O2

01

UPDATE O2
UPDATE O1 (idem)

02
Lecture O2

criture O2
Lecture O1

criture O1

T2

4.1.3

CONCURRENCE : SECURISATION
Principes
Contrle des accs concurrents sur les donnes en cours de m.a.j.

Transaction : grain temporel minimal de gestion des accs (ACID)

Granularit : Unit de base dont laccs peut-tre contrl variable
suivant la transaction : champ, tuple, relation
Objectif : srialisation de lexcution des transactions.

Srialisation
Schma sriel: schma dexcution o les transactions sont
excutes la suite les unes des autres : pas de concurrence.
Schma srialisable : un schma de transactions concurrentes
T1,,Tn est srialisable si il existe un schma sriel de transactions
qui produit le mme rsultat quelque soit ltat initial de la base
Schma srialisable par permutation : schma srialisable o on
peut permuter les actions deux deux pour avoir un schma sriel
J.Y. Antoine

4.1.3

CONCURRENCE : SECURISATION
Oprations

Compatibles: excutables en parallle sans problme

Permutables: ordre dexcution sans influence sur le rsultat

Oprations de T1 et T2

compatible

permutable

Lecture/Ecriture A et Lecture/Ecriture B

oui

oui

Lecture A et Ecriture A

non

non

Ecriture A et Ecriture A

non

non

Graphe de prcdence dun schma dexcution

Dfinition: il y a prcdence dune transaction T1 sur une transaction T2 si il
existe au moins une opration O1 de T1 non permutable avec une opration
O2 de T2 et qui est avant O2 dans le schma dexcution

T1

T2

T3

T1

T2

T3

Condition suffisante de srialisation: un schma dexcution est srialisable

si le graphe de prcdence qui lui est associ est sans circuit.
J.Y. Antoine

4.1.3

GESITON DE CONCURRENCE PAR ESTAMPILLAGE

Srialisation
- approche optimiste : contrle par estampillage ou validation
- approche prudente : verrouillage

Estampillage
Numro dordre attribu aux transactions
Traces sur les lments de la BD lors de toute lecture / criture :
LL(E)
LE(E)

numro de la dernire transaction avoir lu llment E

numro de la dernire transaction avoir crit / modifi E

Algorithme dordonnancement: Ti veut oprer sur une donne E

si i LL(E) (resp. LE(E) ) alors on peut excuter i (transaction bien postrieure)
sinon, on annule et reprend la transaction destampille LL(E) ( resp. LE(E) ).

Approche optimiste : on suppose que tout se passe bien a priori. Si

ordonnancement non srialisable, il faut alors diffrer ou dfaire les
transactions
J.Y. Antoine

4.1.3

GESITON DE CONCURRENCE PAR VEROUILLAGE

Verrouillage : principes
Une transaction peut poser et librer des verrous sur les donnes sur lesquelles elle
travaille (lecture, mise jour, criture).
Une transaction ne peut raliser une opration sur une donne que sil ny a pas de
verrou pos dessus, o si la transaction possde le verrou en question. Sinon, elle
est mise en attente au niveau de lopration en cours
Approche prudente : pas dannulation de transaction en cours, sauf si verrou mortel

Stratgies de verrouillage
Verrous uniques stricts : verrou sur une donne ds quon lutilise
Verrous distincts non ncessairement exclusifs : verrous diffrents suivant laction
lecture (verrou partag) / criture (exclusif)
lecture, mise jour protgs ou non, exclusive ou non , etc

 Niveaux disolation des transactions

 Matrice de compatibilit des oprations
J.Y. Antoine

C=
lecture / criture

1 0
0 0

Accs concurrents : verrouillage

Algorithme de verrouillage (cas gnral : verrous distincts)
Avant chaque opration, la transaction vrifie si elle peut poser le verrou (exclusif ou
non) qui correspond cette dernire. Si non, attente.
En pratique :
Vecteur O(i,e) des oprations de la transaction Ti en cours sur llment e
Demande LOCK : vecteur boolen Mj(e) des modes de verrouillage demands
Demande UNLOCK: remise zro du mode correspondant dans O(i,e)
Verrouillage autoris si :
M (e) ( C *
O(i,e) )
j

Boole

ij

Protocole de verrouillage en deux phases (2PL)

2PL : dans la transaction, tous les verrouillages prcdent les librations de verrou.
Intrt : condition suffisante pour assure des schmas dexcution srialisables.
J.Y. Antoine

Accs concurrents : verrouillage

Problmes de verrouillage : verrou mortel
INSERT O2
SELECT O1

INSERT O1
UPDATE O2
01

02

LOCK : criture dans O1

LOCK : criture dans O2

WAIT

LOCK : criture dans O2

LOCK : Lecture dans O1

WAIT

J.Y. Antoine

Accs concurrents : verrouillage

Dtection des interblocages: graphe des attentes
Graphe des attentes: une transaction Ti attend une transaction Tj si Ti attend de
pouvoir verrouiller une donne d alors que le verrou correspondant appartient Tj.
Interblocage (verrou mortel) ssi le graphe des attentes possde un circuit
T1

T2

T3

T4

Rsolution des interblocages

Prvention: pr-ordonnancement des transactions
Correction: algorithme de dblocage implicite

Trop lourd

Stratgie DIE_WAIT : Ti attend Tj uniquement si Ti est plus vieille que Tj . Sinon, Ti est
annule (reprise).
Stratgie WOUND_WAIT : Ti attend Tj uniquement si Ti est plus jeune que Tj . Sinon, Ti
tue Tj (reprise provoque).
Stratgies plus souples : on blesse (ultimatum dune certaine dure) avant de tuer
J.Y. Antoine

Accs concurrents: verrouillage

Problmes de verrouillage : blocage permanent
Problme: ensemble de transactions effectuant des actions compatibles (pas de
verrou mortel) mais bloquant de facto les autres transactions.
Solutions - file dattente des demandes de verrouillage
- stratgies DIE_WAIT / WOUND_WAIT: pas de blocage permanent

Problmes de verrouillage : lecture fantme

Toujours possible : difficult de dfinir des granules logiques communs

T1

SELECT O1
SELECT O2
Lecture O1

01 02
01

UPDATE O2

02
LOCK : Lecture O2
LOCK : criture O2

01 02 ??
J.Y. Antoine

Lecture O2

UNLOCK : Commit

T2

Accs concurrents : verrouillage

Niveaux disolations variables
 2PL : assure la sriabilit mais restreint les excutions concurrentes

 Protocoles plus permissifs plus de concurrence mais dangers associs

 Mode doprations autoriss et dure des verrous :
verrou court
verrou long

libr aprs lexcution de lopration concerne

libr en fin de transaction (2PL maximal)

SQL2 : Niveaux disolation normaliss

Niveau 0

verrou exclusif court en criture uniquement

Garantie : mises jour assures uniquement

Niveau 1

verrou exclusif long en criture uniquement

Garantie : non perte et cohrence des mises jour

Niveau 2

Niveau 1 + verrous courts partags en lecture

Garantie : niveau 1 + cohrence des lectures

Niveau 3

2PL : verrous longs criture exclusive / lecture partage

Niveau 2 + lecture renouvelable

J.Y. Antoine

Accs concurrents : verrouillage

Niveaux disolations variables  problmes ventuels
Problme 1 : lecture salissante
UPDATE O2
01

SELECT O2

02

ROLLBACK

criture O2
Lecture O2

T1
O2??

ROLLBACK

T2

Verrou court : UNLOCK avant COMMIT

J.Y. Antoine

Accs concurrents : verrouillage

Problme 2 : lecture non renouvelable
UPDATE O2
01

02

SELECT O2
Lecture O2
Lecture O2

SELECT O2

UPDATE
tampon
criture O2

T1
Lecture O2

COMMIT

T2

O2??

Verrou court : UNLOCK avant COMMIT

J.Y. Antoine

Accs concurrents : verrouillage

Rappel : au mieux, on ne peut que limiter
les situations de lectures fantmes

Problme 3 : lecture fantme

01

SELECT O1
SELECT O2

02

UPDATE O2
UPDATE O1
criture O2

Lecture O1

T1

criture O1
Lecture O2

O1 ??

T2

COMMIT

Verrou court lecture / criture

J.Y. Antoine

Accs concurrents : Oracle

Verrouillage implicite des donnes
Gestion transparente: automatique, suivant le niveau disolation choisi
Plusieurs niveaux disolation : contrle plus ou moins strict de la concurrence
SERIALIZABLE | REPEATABLE READ | READ COMMITED | READ UNCOMMITED

Protocole 2PL : dverrouillage final sur COMMIT (si niveau SERIALIZABLE)

Granularit fine : on peut ne verrouiller quun tuple, un attribut
Dictionnaire Oracle : V$LOCK

Mise jour des donnes (INSERT, UPDATE et DELETE )

Niveau SERIALIZABLE: verrou sur le tuple (ROW) de la table concerne.
Cration dun ROLLBACK segment : modifications visibles du seul utilisateur
responsable de la transaction jusqu la fin de transaction.

Consultation de donnes (SELECT)

Niveau SERIALIZABLE : verrou lecture protge.
Ne peut pas voir les mises jour non encore publies par les autres transactions.
J.Y. Antoine

Accs concurrents : Oracle

Nom Age
Lo

Age = 5

A : Dbut SELECT Age FROM Nom ;

C : Dbut UPDATE .. SET Age=5;

A: Fin SELECT Age FROM Nom ;

Age
5

UNDO segment
C : Fin UPDATE .. SET Age=5;

B : Dbut SELECT Age FROM Nom ;

C : Fin transaction
Age = 5

Age =4
B : Fin SELECT Age FROM Nom ;

A
J.Y. Antoine

Accs concurrents : Oracle

Niveaux disolation
Niveau disolation

Lecture
salissante

Lecture non
renouvelable

Fantme

Lecture non valide

Lecture valide

Lecture renouvelable

Srialisable

SQL : Dfinir un niveau disolation

SERIALIZABLE par dfaut
Dfinition par transaction

SET TRANSACTION [niveau_isolation]

SERIALIZABLE | REPEATABLE READ | READ COMMITED | READ UNCOMMITED

J.Y. Antoine

Accs Concurrents : Oracle

Verrouillage explicite

sur table ou enregistrements

Verrouillage de table
LOCK TABLE <nom_table> IN {EXCLUSIVE | SHARED } MODE
Mode exclusif (X) : table totalement verrouille sauf en consultation (SELECT).
Mode partag (S) : dautres transactions peuvent mettre un verrou partag sur
la table. Si plusieurs verrous S, impossibilit de modifier les donnes par aucune
des transactions.
Verrouillage de tuple (ROW)
LOCK TABLE <nom_table> IN {ROW EXCLUSIVE | ROW
SHARED | SHARE ROW EXCLUSIVE} MODE
Si verrou partag uniquement sur les enregistrements (RS), modifications
parallles possible sur enregistrements diffrents.
J.Y. Antoine

Squences
Principe: dfinition de valeurs unique et accs concurrents
Objet nomm dans la base de donnes qui sert gnrer des valeurs (entiers)
uniques dans un environnement d utilisation multi-utilisateurs, sans conflit et sans
risque de verrous mortels
Une squence est un objet spcifique qui peut tre utilis dans plusieurs tables et par
plusieurs utilisateurs.
Un pas dincrment permet de dfinir le calcul de la valeur courante partir de la
valeur prcdente. Les valeurs sont comprises entre des valeurs maximales et
minimales (-1026 et 1027 par dfaut).
Une fois lensemble des valeurs parcouru, on peut autoriser le retour la valeur initiale
pour poursuivre la gnration laide de loption CYCLE

Exemple dutilisation : cl primaire

Gnrer les valeurs de la cl sur une importation si aucun champ de donnes ne joue ce
rle (quivalent NumeroAuto en ACCESS ou Auto Increment en MySQL)
J.Y. Antoine

Squences
Cration
CREATE SEQUENCE [<schema>.]<nom_seq>
[ INCREMENT BY <entier> ]
[START WITH <entier>]
[ MAXVALUE entier ] [ MINVALUE entier ]
[ {CYCLE | NOCYCLE}]
[{CACHE <entier> | NOCACHE}] ;

Modification
Gnralement pour changer lamplitude de variation ou le pas dincrment
ALTER SEQUENCE [<schema>.]<nom_seq> + un des lments de cration

Suppression
DROP SEQUENCE <nom_sequence> ;

J.Y. Antoine

Squences
Utilisation

Utilisation dans toute commande SQL de manipulation des donnes (SELECT,

INSERT, UPDATE) avec quelques restrictions

<nom_sequence>.NEXTVAL : directive (pseudo-attribut) gnrant la premire ou la

prochaine valeur de la squence et retourne la valeur de celle-ci (lecture et criture)

<nom_sequence>.CURVAL : valeur courante de la squence (lecture seule)

Exemple
CREATE SEQUENCE seq_exple NOCYCLE ;
SELECT seq_exple.NEXTVAL FROM seq_exple ;
...
SELECT seq_exple.CURVAL FROM seq_exple ;
...
SELECT seq_exple.CURVAL FROM seq_exple ;

J.Y. Antoine

/* 1re utilisation */
/* lecture 1re valeur */

Squences : Oracle
Visualisation de ltat dune squence
Lecture (SELECT) du pseudo-attribut <nom_seq>.CURVAL dans la
pseudo-table DUAL

Dictionnaire Oracle : vue ALL_SEQUENCES

Nom

NULL ?

Type

--------------------------------------

--------

---------------

SEQUENCE_OWNER

NOT NULL

VARCHAR2(30)

SEQUENCE_NAME

NOT NULL

VARCHAR2(30)

MIN_VALUE

NUMBER

MAX_VALUE

NUMBER

INCREMENT_BY

NOT NULL

NUMBER

CYCLE_FLAG

VARCHAR2(1)

ORDER_FLAG

VARCHAR2(1)

CACHE_SIZE

NOT NULL

NUMBER

LAST_NUMBER

NOT NULL

NUMBER

J.Y. Antoine

Squences
Utilisation explicite de squences avec SQL Loader
1.

Crer une squence

CREATE SEQUENCE seq_exple START WITH 1 INCREMENT 1 BY NOCYCLE ;

2.

Utiliser la squence dans le fichier de contrle

LOAD DATA INFILE 'donnees.don'
INTO TABLE Table_exemple
FIELDS TERMINATED BY ';'
(pk_att "seq_exple.nextval",
NOM .

Utilisation implicite de squences avec SQL Loader

LOAD DATA INFILE 'donnees.don' INTO TABLE Table_exemple
FIELDS TERMINATED BY ';'
(pk_att SEQUENCE(Valeur_Init, Increment),

J.Y. Antoine

Bibliographie
Ouvrages de rfrences
DATE C. J. (2000) Introduction aux bases de donnes (7 dition), Vuibert, Paris, ISBN
2-7117-8664-1. Partie IV : gestion de la concurrence, pp. 443-496.
GRAY J., ANDREAS R. (1993) Transaction processing : concepts and techniques.
Morgan Kaufmann, San Mateo, CA.

Travaux cits
GRAY J.N. et al. (1981) The recovery manager of the system R Database Manager.
ACM Computing Surveys, 13(2).
HRDER T., REUTER A. (1983) Principles of transaction-oriented database recovery.
ACM Comput. Surv. 15(4).
MOHON C. et al. (1992) A transaction recovery method supporting fine-granularity
locking and partial rollbacks using write-ahead logging. ACM TODS 17(1).

J.Y. Antoine