Basi di dati replicate e applicazione in Oracle 11.2g

UNIVERSITÁ DEGLI STUDI DI NAPOLI FEDERICO II
CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA INFORMATICA
BASI DI DATI II
DOCENTE
LUCIO SANSONE
TESINA D’ESAME
BASI DI DATI REPLICATE E APPLICAZIONE IN ORACLE 11.2 G
IVANO DI COSTANZO
885/599
ROSARIO MATTERA
M63/19
ANNO ACCADEMICO 2010/2011
Sommario
Elenco delle figure .............................................................................................................................................................. 2
Acronimi e abbreviazioni ................................................................................................................................................... 3
1. INTRODUZIONE ALLA REPLICAZIONE ................................................................................................................. 4
2. ARCHITETTURE PER LA REPLICAZIONE .............................................................................................................. 5
2.1 MODELLO MASTER-SLAVE – REPLICAZIONE ASIMMETRICA .................................................................. 5
2.2 DUAL MASTER – REPLICAZIONE SIMMETRICA ........................................................................................... 6
2.3 MULTI-MASTER .................................................................................................................................................... 7
3. MODALITÀ DI AGGIORNAMENTO ......................................................................................................................... 7
3.1 REPLICAZIONE SINCRONA (AVIDA) ................................................................................................................ 7
3.1.1 VOTING ............................................................................................................................................................ 8
3.1.2 READ-ANY WRITE-ALL ................................................................................................................................ 8
3.2 REPLICAZIONE ASINCRONA (PIGRA) .............................................................................................................. 9
4. MODALITÀ DI ALLINEAMENTO ........................................................................................................................... 10
5. REPLICAZIONE IN ORACLE 11.2 G ........................................................................................................................ 11
5.1 PANORAMICA SUGLI ORACLE STREAMS .................................................................................................... 11
5.2 FUNZIONALITÀ DEGLI ORACLE STREAMS ................................................................................................. 12
5.2.1 CATTURA DELLE MODIFICHE DALLA SORGENTE .............................................................................. 12
5.2.2 PROPAGAZIONE DELLE MODIFICHE ...................................................................................................... 13
5.2.3 APPLICAZIONE DELLE MODIFICHE ALLE DESTINAZIONI ................................................................ 13
5.2.4 RILEVAMENTO E RISOLUZIONE DEI CONFLITTI ................................................................................. 13
5.3 LE REGOLE .......................................................................................................................................................... 14
5.4 AMBIENTI DI REPLICAZIONE .......................................................................................................................... 16
5.4.1 AMBIENTE DI REPLICAZIONE TWO-DATABASE.................................................................................. 16
5.4.2 AMBIENTE DI REPLICAZIONE HUB-AND-SPOKE ................................................................................. 17
5.4.3 AMBIENTE DI REPLICAZIONE N-WAY ................................................................................................... 19
6. REALIZZAZIONE DI UN AMBIENTE DI REPLICAZIONE ................................................................................... 20
6.1 CREAZIONE DI UN DATABASE ....................................................................................................................... 20
6.2 PREREQUISITI ..................................................................................................................................................... 21
6.3 CREAZIONE DELLE CODE E DEL DATABASE LINK ................................................................................... 25
1
6.4 CONFIGURAZIONE DEI PROCESSI DI CATTURA, PROPAGAZIONE ED APPLICAZIONE .................... 27
6.5 MODIFICHE DML E DDL SU UNA TABELLA E VERIFICA DEL RISULTATO .......................................... 31
Bibliografia ....................................................................................................................................................................... 34
Elenco delle figure
FIGURA 1: SISTEMA INFORMATIVO DELLA TANDEM .............................................................................. 5
FIGURA 2: MODELLO MASTER-SLAVE .................................................................................................. 6
FIGURA 3: MODELLO DUAL-MASTER ................................................................................................... 7
FIGURA 4: MODELLO MULTI-MASTER .................................................................................................. 7
FIGURA 5: TRASMISSIONE SINCRONA .................................................................................................... 8
FIGURA 6: TRASMISSIONE ASINCRONA .................................................................................................. 9
FIGURA 7: ESEMPIO TRIGGERS DI REPLICAZIONE ................................................................................. 10
FIGURA 8: ALLINEAMENTO INCREMENTALE ........................................................................................ 10
FIGURA 9: FLUSSO DELLE INFORMAZIONI NEGLI ORACLE STREAMS ................................................... 11
FIGURA 10: PROCESSO DI CATTURA, PROPAGAZIONE E APPLICAZIONE DELLE MODIFICHE ................... 14
FIGURA 11: UN RULE SET PUÒ ESSERE USATO DA MOLTEPLICI CLIENT DEL RULES ENGINE ................ 15
FIGURA 12: ONE-WAY REPLICATION NELL'AMBIENTE DI REPLICAZIONE TWO-DATABASE ................. 16
FIGURA 13: BI-DIRECTIONAL REPLICATION NELL'AMBIENTE DI REPLICAZIONE TWO-DATABASE ....... 17
FIGURA 14: HUB-AND-SPOKE REPLICATION ENVIRONMENT CON SPOKE IN SOLA LETTURA ............... 18
FIGURA 15: HUB-AND-SPOKE REPLICATION ENVIRONMENT CON SPOKE IN LETTURA/SCRITTURA ..... 19
FIGURA 16: N-WAY REPLICATION ENVIRONMENT.............................................................................. 20
FIGURA 17: SCHEMA DEL PROCESSO DI REPLICAZIONE ........................................................................ 20
FIGURA 18: CONFIGURAZIONE LISTENER CON IL NET MANAGER........................................................ 23
FIGURA 19: CONFIGURAZIONE DEL SERVIZIO TEST2 CON IL NET MANAGER ....................................... 23
FIGURA 20: CREAZIONE
DELL'UTENTE AMMINISTRATORE ED ESECUZIONE DEGLI SCRIPT DI
CONFIGURAZIONE ......................................................................................................................... 26
FIGURA 21: INSERIMENTO DI UNA TUPLA NELLA TABELLA GIOCATORI ............................................... 32
FIGURA 22: QUERY DI VERIFICA DELLA PROPAGAZIONE DELL'INSERIMENTO DELLA TUPLA ............... 32
FIGURA 23: MODIFICA DEL TIPO DELL'ATTRIBUTO SQUADRA ............................................................. 33
FIGURA 24: PROPAGAZIONE DELLA MODIFICA DEL TIPO DI ATTRIBUTO SUL DB DESTINAZIONE .......... 33
2
Acronimi e abbreviazioni
AP – Apply Process
CP – Capture Process
DB – DataBase
DBA – DataBase Administrator
DBMS – DataBase Management System
DDL – Data Definition Language
DML – Data Manipulation Language
DW – Data Warehouse
IP – Internet Protocol
LCR – Logical Change Record
OS – Oracle Streams
P2P – Peer To Peer
SC – Synchronous Capture
SCN – System Change Number
3
1. INTRODUZIONE ALLA REPLICAZIONE
La replicazione è una tecnologia supportata dai maggiori DBMS moderni, che consente di
condividere oggetti e dati di un database tra molteplici DBMS. Per ottenere questo risultato, un
cambiamento ad un elemento presente in un database deve propagarsi sugli altri, solitamente
remoti, in modo da garantire una specifica sincronizzazione tra i dati e quindi la proprietà di
consistenza.
Le ragioni principali che spingono all’utilizzo della replicazione sono:

Availability (disponibilità del servizio) : è l’intervallo temporale in cui il sistema funziona
correttamente. La replicazione migliora questa proprietà in quanto rende il sistema meno
sensibile ai guasti poichè, se la copia principale non è disponibile (ad es. a causa di un
guasto sul nodo su cui si trova) è possibile almeno accedere ad una sua copia.

Performance (efficienza) : la replicazione consente di realizzare il cosiddetto load balancing
(bilanciamento del carico) che consiste nel bilanciare le richieste di servizio su più nodi
comportando un minor carico per gli stessi.

Riduzione del carico della rete : disponendo i nodi in maniera opportuna a livello geografico
è possibile ridurre la quantità di dati trasmessa su una porzione di rete, distribuendola su più
canali.

Backup and Recovery : la presenza di dati replicati permette di evitare backup espliciti del
DB di interesse e consente operazioni di gestione dei nodi guasti senza interrompere il
servizio.
Un buon modello di replicazione deve essere capace di mantenere consistenza tra le varie
copie, garantire scalabilità ed essere affidabile. Inoltre la distribuzione dei dati deve essere tale da
garantire l’autonomia dei singoli nodi e l’eventuale cooperazione tra di essi per la realizzazione di
specifiche operazioni.
La replicazione è garantita dai cosiddetti replicatori dei dati (data replicator) che
consentono la creazione di copie di tabelle o sottoinsiemi di tabelle in un generico contesto
distribuito, e di mantenere l’allineamento tra di esse.
Un esempio tipico di utilizzo della replicazione è relativo al sistema informativo della
Tandem: la Tandem disponeva di diversi stabilimenti distribuiti in varie parti del mondo, ciascuno
specializzato nel realizzare una specifica parte dell’architettura del calcolatore (tastiere, schermi,
etc.). Si pensò all’epoca di frammentare le tabelle in modo da riflettere la distribuzione fisica del
processo di costruzione dei componenti, allocandole in modo ridondante. In particolare, venne
previsto di allocare la copia principale del frammento presso il nodo responsabile del processo
4
relativo ai dati contenuti nel frammento. Al contempo, i restanti nodi possedevano una copia
secondaria di tale frammento in sola lettura. Le modifiche venivano sempre dirette alla copia
principale dalla quale venivano poi propagate agli altri nodi: il gestore della replicazione
collezionava un insieme di modifiche (batch) e le applicava agli altri frammenti.
F1
COPIA (F2)
DBMS 1
COPIA (F3)
MODIFICHE
(BATCH)
COPIA (F1)
F2
DBMS 2
COPIA (F3)
Figura 1: Sistema informativo della Tandem
2. ARCHITETTURE PER LA REPLICAZIONE
2.1 MODELLO MASTER-SLAVE – REPLICAZIONE ASIMMETRICA
Il modello Master-Slave è il più semplice e diffuso tra i modelli. Esso prevede un server
principale, detto master, che contiene la copia principale del DB sulla quale sono consentite le
operazioni di lettura e scrittura; e uno o più server secondari, detti slave, che posseggono ciascuno
una copia secondaria del DB sulla quale è possibile applicare solo operazioni di lettura.
Questo modello può essere esteso consentendo ad un nodo slave di essere a sua volta master
per altri nodi, realizzando una struttura ad albero. Esistono anche varianti del modello (vedi Figura
1) in cui la base di dati viene frammentata e ogni nodo può essere master per un frammento e slave
per tutti gli altri.
Il modello Master-Slave in caso di partizionamento della rete presenta il problema che uno o
più slave non vengono più aggiornati dal nodo master.
5
MASTER
SLAVE 1
SLAVE 2
SLAVE 3
Figura 2: Modello Master-Slave
2.2 DUAL MASTER – REPLICAZIONE SIMMETRICA
Il sistema Dual-Master è costituito da una coppia di server di tipo master. Questa
configurazione risulta utile nel caso in cui due organizzazioni geograficamente distanti hanno
l’esigenza di accedere in scrittura/lettura allo stesso database condiviso. Questo modello è soggetto
a problemi di inconsistenza in caso di partizionamento della rete. Infatti, la presenza di due nodi
master consente operazioni di scrittura su entrambi i DB. Con il partizionamento della rete due
transazioni, in scrittura su uno stesso valore e dirette ciascuna ad uno dei nodi, produrranno una
inconsistenza su tale valore. Un’altra situazione di inconsistenza può verificarsi anche senza
partizionamento della rete se gli aggiornamenti delle due transazioni citate in precedenza, non
vengono comunicati immediatamente alle altre copie. Queste situazioni vanno risolte con
meccanismi di riconciliazione, che solitamente sono specifici della particolare piattaforma, oppure
vanno evitate con altri meccanismi. Due di questi sono:
1.
Ad ogni master è concesso di poter modificare solo un frammento di una relazione,
tipicamente tramite frammentazione orizzontale, e ogni coppia di frammenti è modificabile
solo da master differenti (architettura Tandem).
2.
I diritti di modifica sono posseduti in un certo istante da un solo master che possiede
un token (Token Ring). Nel caso in cui il master che lo possiede fallisse (ad esempio in
seguito alla caduta del nodo), un altro master acquisisce il token.
6
MASTER
MASTER
Figura 3: Modello Dual-Master
2.3 MULTI-MASTER
La replicazione Multi-Master è un’evoluzione del caso Dual-Master in cui il numero di nodi
master è pari a n, con
. Tale modello ha le caratteristiche tipiche dei sistemi peer-to-peer
(P2P) poiché tutti i nodi sono posti allo stesso livello e soffre degli stessi problemi del Dual-Master.
MASTER
MASTER
MASTER
Figura 4: Modello Multi-Master
3. MODALITÀ DI AGGIORNAMENTO
La modalità di aggiornamento delle variazioni sulle basi di dati replicate può essere sincrona
o asincrona. Queste differiscono principalmente per il momento in cui viene effettuato l’invio delle
variazioni.
3.1 REPLICAZIONE SINCRONA (AVIDA)
La replicazione sincrona prevede che tutte le copie del DB siano mantenute “esattamente”
sincronizzate e consistenti. Se una copia subisce un aggiornamento, i cambiamenti vengono
applicati immediatamente a tutti gli altri DB con la stessa transazione. La replicazione sincrona è
desiderabile quando la tempistica degli aggiornamenti è importante per l’applicazione.
7
Figura 5: Trasmissione Sincrona
Esistono due tipologie di replicazione sincrona, dette rispettivamente Voting e Read-Any
Write-All.
3.1.1 VOTING
Questa modalità di replicazione prevede che la transazione in fase di scrittura vada ad
aggiornare la maggioranza delle copie, mentre in lettura debba leggere un numero sufficiente di
esse in modo da assicurarsi la lettura della copia più recente. In particolare, la fase scrittura deve
interessare almeno la metà più uno delle copie esistenti; mentre in lettura, per poter individuare
sicuramente una delle copie aggiornate, bisogna leggere un numero di copie pari alle rimanenti
rispetto alla fase di scrittura, più uno. Detto n il numero di copie totali, devono essere scritte almeno
copie mentre occorre leggerne almeno
. Poiché tutte le copie hanno un numero di
versione tale che quella con l’identificativo più alto è la più aggiornata, con il precedente schema di
lettura e scrittura si ha un funzionamento corretto del sistema.
Il numero di letture e scritture da realizzare può essere configurato in modo da minimizzare
il numero di operazioni: in base alle esigenze è possibile ridurre il numero di letture o di scritture.
Questo metodo presenta delle controindicazioni relativamente alla fase di lettura poiché
necessita di un numero cospicuo di letture per accedere ad un unico dato.
3.1.2 READ-ANY WRITE-ALL
Questa modalità di replicazione prevede, come il nome lascia intendere, che una transazione
8
debba scrivere su tutte le copie del DB e leggerne al più una. Ovviamente, poiché basta leggere una
sola copia il processo di lettura è molto veloce mentre quello di scrittura è particolarmente lento, in
quanto è necessario agire su tutte le copie del DB.
3.2 REPLICAZIONE ASINCRONA (PIGRA)
La replicazione asincrona, detta anche di store and forward, prevede la presenza di due
transazioni: una transazione master aggiorna la base di dati principale dopodiché, in un secondo
momento viene emessa una transazione di allineamento verso le copie secondarie, che propaga le
variazioni.
COPIA
j-ESIMA
COPIA
i-ESIMA
MODIFICA
PROPAGAZIONE
TRANSAZIONE DI
ALLINEAMENTO
TRANSAZIONE MASTER
Figura 6: Trasmissione asincrona
Queste
modifiche,
chiamate
transazioni
differite
o
di
allineamento,
vengono
successivamente propagate in tre possibili modalità:

Periodica

A comando

Ad accumulo di variazioni
L’allineamento periodico viene effettuato allo scadere di un certo timer T. L’allineamento a
comando realizza l’aggiornamento delle copie secondarie su richiesta del DBA. Infine,
l’allineamento ad accumulo di variazioni viene attivato al superamento di una soglia, che definisce
il massimo disallineamento tra copia principale e secondarie (ad esempio in termini di tuple).
9
4. MODALITÀ DI ALLINEAMENTO
Le modalità di allineamento tra due o più copie sono:

Incrementale

Refresh
La modalità incrementale prevede di scambiare tra i DB solo le effettive variazioni
avvenute, senza necessariamente copiare l’intera base di dati. Ciò necessita di trigger dedicati alla
cattura delle modifiche, da memorizzare in apposite tabelle dette convenzionalmente Delta Plus e
Delta Minus. Queste ultime sono del tutto trasparenti all’utente.
Figura 7: Esempio triggers di replicazione
COPIA
i-ESIMA
COPIA
j-ESIMA
Δ+
ΔFigura 8: Allineamento incrementale
La modalità refresh consiste invece nel copiare l’intero DB principale presso la copia
secondaria. Poiché tale operazione è piuttosto onerosa si sceglie solitamente un allineamento
periodico; ciò comporta che nei periodi di disconnessione le copie secondarie non ricevano alcun
aggiornamento.
10
5. REPLICAZIONE IN ORACLE 11.2 G
In questo lavoro si è scelto di studiare il processo di replicazione nel DBMS Oracle versione
11.2 g. Nei paragrafi successivi sono descritti brevemente i concetti chiave e la terminologia
utilizzata in ambiente Oracle. In seguito a questa descrizione teorica, verrà illustrato un esempio
pratico di replicazione.
5.1 PANORAMICA SUGLI ORACLE STREAMS
Gli Oracle Streams (OS) abilitano la condivisione di informazioni. Usando gli OS, ciascuna
informazione condivisa è detta messaggio, ed è possibile condividere questi messaggi in uno
stream. Lo stream può propagare informazioni all’interno dello stesso DB o da un DB all’altro. È
possibile specificare quali informazioni inoltrare e a quali destinazioni. Questa soluzione fornisce
maggiore flessibilità e funzionalità per la cattura, la gestione di messaggi e la condivisione degli
stessi con altri DB e applicazioni, rispetto a quelle tradizionali. Gli OS forniscono la possibilità di
costruire applicazioni distribuite, Data Warehouse, e soluzioni caratterizzate da un alto grado di
availability. Tutte le funzionalità degli OS possono essere utilizzate nello stesso momento e, se
necessitano cambiamenti, è possibile estenderle senza sacrificare quelle esistenti.
Usando gli OS, è possibile controllare quali informazioni inserire nello stream, come
trasferire le informazioni da un DB ad un altro, cosa succede ai messaggi nello stream quando
fluiscono verso altri DB, e come lo stream viene chiuso. In base alla configurazione impostata, l’OS
può automaticamente catturare, posizionare, e gestire messaggi nel DB, incluse modifiche DML
(Data Manipulation Language) e DDL (Data Definition Language). È possibile inserire nello
stream anche messaggi definiti dall’utente, e l’OS può propagare tali messaggi ad altri DB o
applicazioni in maniera automatica. Quando un messaggio raggiunge la destinazione, l’OS può
consumarlo in base alla configurazione impostata.
Figura 9: Flusso delle informazioni negli Oracle Streams
Gli Oracle Streams possono essere utilizzati per eseguire molteplici compiti tra cui:
• Replicazione dei dati
• Estrazione e caricamento per un DW
• Notifica degli eventi
11
• Migrazione di piattaforma del DB
5.2 FUNZIONALITÀ DEGLI ORACLE STREAMS
Le seguenti sezioni forniscono una panoramica su cosa può fare un OS. Come rappresentato
in Figura 9, il flusso di informazioni in un OS è caratterizzato da 3 fasi:
1. Cattura delle modifiche dalla sorgente
2. Propagazione delle modifiche
3. Applicazione delle modifiche alle destinazioni.
5.2.1 CATTURA DELLE MODIFICHE DALLA SORGENTE
Con gli Oracle Streams sono implementati due modalità di cattura delle modifiche. La prima
avviene attraverso un processo chiamato capture process, la seconda è la modalità synchronous
capture. Il CP può catturare modifiche DDL e modifiche DML su tabelle, schemi o database interi;
mentre un SC può catturare le modifiche DML apportate sulle tabelle. Impostando opportunamente
delle regole, rules, si determina quali modifiche debbano essere catturate da un CP o da un SC.
Come ben si sa, le modifiche apportate ad un DB sono elencate nel corrispondente log redo.
Il CP esamina il file di log redo e cattura i cambiamenti presenti in esso creando quindi un LCR
(Logical Change Record), un record che descrive, secondo uno specifico formato, un certo
cambiamento del DB. Gli LCR vengono mantenuti in una coda per poi essere processati.
Diversamente un SC non esamina il log redo per individuare le modifiche, ma utilizza un
meccanismo interno. Le modifiche catturate dal CP sono dette captured LCRs, mentre quelle
catturate da un SC sono detti persistent LCRs.
Le regole usate da un CP o da un SC determinano quali modifiche catturare. Quando le
modifiche sono catturate da un CP, il DB che genera le modifiche nel log redo è detto source
database. Con lo stesso termine si indica il DB dove è configurato un SC. Un CP può catturare le
modifiche di un DB locale oppure remoto, detto downstream database (Figura 10); al contrario un
SC può catturare solo le modifiche apportate al DB locale. Quando un CP o un SC catturano delle
modifiche, queste vengono riferite come implicit capture. Allo stesso modo anche un utente o
un’applicazione può inserire manualmente messaggi in una coda. Questi messaggi possono essere
LCR o messaggi di un tipo definito dall’utente, detto user message. I messaggi inseriti nella coda da
un utente o da un’applicazione vengono riferiti come explicit capture.
Con entrambe le modalità di cattura gli LCR vengono inseriti e mantenuti in una coda
generica, detta ANYDATA queue, che può contenere messaggi di tipi differenti. Utenti e
applicazioni possono accodare messaggi nella coda generica oppure in una coda specifica, detta
12
typed queue, la quale può contenere messaggi di un solo tipo.
5.2.2 PROPAGAZIONE DELLE MODIFICHE
Gli Oracle Streams consentono di propagare i messaggi mediante un propagation, e quindi
di trasferire gli LCR accodati da una coda producer queue ad un’altra consumer queue. Queste code
possono risiedere nello stesso DB o in DB differenti: sono le regole a determinare la propagazione.
Gli LCR possono, quindi, passare anche attraverso DB intermedi prima di giungere a destinazione. I
DB intermedi possono a loro volta consumare o no tali messaggi. Queste modifiche vengono
condivise attraverso la cosiddetta directed network.
5.2.3 APPLICAZIONE DELLE MODIFICHE ALLE DESTINAZIONI
Un messaggio si dice consumato quando viene prelevato dalla coda. Nel destination
database, un processo chiamato apply process consuma i messaggi della coda applicando
direttamente le modifiche alla base dei dati oppure facendole gestire da un apply handler,
opportunamente istruito tramite regole.
5.2.4 RILEVAMENTO E RISOLUZIONE DEI CONFLITTI
Un AP rileva i conflitti automaticamente quando le modifiche vengono applicate
nell’ambiente di replicazione. Tipicamente, un conflitto si verifica quanto la stessa riga nel source
database e nel destination database viene modificata approssimativamente nello stesso istante.
Quando si verifica un conflitto, occorre un meccanismo per assicurarsi che lo stesso sia risolto in
accordo con le regole dell’applicazione. Gli OS offrono un’ampia gamma di gestori dei conflitti,
con i quali è possibile definire un sistema di risoluzione per ciascun DB. Se si verifica una
situazione singolare in cui il gestore dei conflitti fornito fallisce, è possibile assemblare un proprio
risolutore dei conflitti.
13
Figura 10: Processo di cattura, propagazione e applicazione delle modifiche
5.3 LE REGOLE
Una regola è un oggetto che abilita un client ad eseguire un’azione quando occorre un
evento e una condizione è soddisfatta. Con gli OS, ognuno dei seguenti meccanismi è detto Oracle
Streams client perché ciascuno di essi è un client del cosiddetto rules engine, un modulo di Oracle
che valuta i rule sets, ossia gli insieme delle regole:

Capture process

Synchronous capture

Propagation
14

Apply process

Messaging client
Eccetto per il synchronous capture, ciascuno di questi client può essere associato con al più
due insiemi di regole: un insieme di regole positive, positive rule set, e un insieme di regole
negative, negative rule set. Invece un SC può essere associato solo con un insieme di regole
positive. Un singolo insieme di regole può essere usato da molteplici CP, SC, Propagation, AP e
Messaging Client (un OS client opzionale che preleva persistent LCR o persistent user message
quando è invocato da un’applicazione o da un utente) all’interno dello stesso DB. Inoltre, un
singolo insieme di regole può essere considerato positivo per un OS client e negativo da un altro OS
client.
Figura 11: Un Rule Set può essere usato da molteplici client del Rules Engine
In generale un client esegue un certo compito se l’LCR corrente soddisfa i suoi insiemi di
regole. Un LCR soddisfa gli insiemi se nessuna regola all’interno del negative rule set viene
valutata come VERA e almeno una regola all’interno del positive rule set viene valutata come
VERA. Se un OS client è associato sia ad un insieme di regole positive che ad un insieme di regole
negative, allora le regole negative sono sempre valutate per prime.
Riassumendo, il DBA può utilizzare gli insiemi delle regole negli OS nei seguenti modi:

Indicando tra le modifiche registrate nel log redo quali tra esse il CP deve esaminare e
processare. Se la modifica soddisfa le regole il CP le esegue, altrimenti le rigetta.

Indicando quali modifiche fatte su una tabella attivano un SC.

Indicando quali LCR devono essere propagati da una coda ad un’altra. Se l’LCR soddisfa gli
insiemi di regole per una propagazione, allora la modifica viene propagata, altrimenti no.

Indicando quali modifiche un AP deve consumare.
Le regole create per un OS possono essere specificate a tre livelli:

Livello di tabella : contiene una condizione che attiva un client per modifiche fatte su una
specifica tabella;
15

Livello di schema : contiene una condizione che attiva un client per modifiche applicate allo
schema o agli oggetti in esso contenuti. Uno schema è una collezione di oggetti del DB in
cui è definito. Nello specifico, uno schema è di proprietà di un utente del DB ed è
caratterizzato dallo stesso nome dell’utente proprietario.

Livello globale : contiene una condizione che attiva un client per qualsiasi modifica fatta al
DB.
5.4 AMBIENTI DI REPLICAZIONE
Gli OS consentono di configurare diversi tipi di ambienti di replicazione. I più comuni sono
tre:

Two-Database

Hub-And-Spoke

N-Way
5.4.1 AMBIENTE DI REPLICAZIONE TWO-DATABASE
In un ambiente di replicazione Two-Database solo due DB condividono oggetti replicati. Le
modifiche apportate sugli oggetti replicati su un DB sono catturati ed inviati direttamente all’altro,
dove vengono applicate. In un tale ambiente, è possibile consentire sia modifiche su entrambi i DB
(Dual-Master) che su uno soltanto (Master-Slave). Se consideriamo il caso in cui sono ammesse
modifiche solo su un DB, allora l’altro DB contiene repliche in sola lettura degli oggetti condivisi.
Questo genere di replicazione viene definito in ambiente Oracle come One-Way replication
environment e tipicamente è caratterizzato dai seguenti componenti base:

Il primo DB ha un CP o un SC per catturare le modifiche sugli oggetti replicati.

Il primo DB ha un propagation che invia le modifiche catturate all’altro DB.

Il secondo DB possiede un AP per applicare le modifiche provenienti dal primo DB.

Per ottimizzare le prestazioni, ogni CP e AP possiede una propria coda.
Figura 12: One-Way Replication nell'ambiente di replicazione Two-Database
Nel caso in cui entrambi i DB consentano modifiche sugli oggetti replicati, ciascuno di essi
16
cattura le modifiche e le propaga verso l’altro, dove vengono applicate. Questo ambiente viene
definito Bi-Directional replication environment ed è caratterizzato dai seguenti componenti di base:

Ogni DB ha un CP o un SC per catturare le modifiche sugli oggetti replicati.

Ogni DB ha un propagation che invia le modifiche all’altro DB.

Ogni DB ha un AP per applicare le modifiche provenienti dall’altro DB.

Per migliorare le prestazioni, ciascun CP e AP possiede una propria coda.
Figura 13: Bi-Directional Replication nell'ambiente di replicazione Two-Database
5.4.2 AMBIENTE DI REPLICAZIONE HUB-AND-SPOKE
In un ambiente di replicazione Hub-And-Spoke è presente un DB centrale, detto hub, che comunica
con DB secondari, detti spoke. Gli spoke non comunicano direttamente tra loro e possono o meno
consentire cambiamenti sugli oggetti replicati. Nel caso in cui non consentano tali modifiche, allora
gli spoke contengono repliche in sola lettura degli oggetti dell’hub. Questo ambiente di replicazione
è caratterizzato dai seguenti componenti di base:

L’hub possiede un CP o un SC per catturare le modifiche sugli oggetti replicati.

L’hub ha un propagation che invia le modifiche catturate a ciascuno degli spoke.

Ciascun spoke possiede un AP per applicare le modifiche provenienti dall’hub.

Per ottimizzare le prestazioni, ciascun CP e AP possiede la propria coda.
17
Figura 14: Hub-And-Spoke Replication Environment con Spoke in sola lettura
Se gli spoke consentono modifiche sugli oggetti, allora tipicamente tali modifiche sono catturate ed
inviate presso l’hub e quest’ultimo le ritrasmette agli altri spoke. Questa variante è caratterizzata dai
seguenti componenti di base:

L’hub possiede un CP e un SC per catturare le modifiche sugli oggetti replicati.

L’hub ha più propagation che inviano le modifiche catturate a ciascuno degli spoke.

Ciascuno spoke possiede un CP o un SC per catturare le modifiche sugli oggetti replicati.

Ognuno degli spoke ha un propagation che invia le modifiche catturate all’hub.

Ognuno degli spoke ha un AP per applicare le modifiche provenienti dall’hub, catturate
presso l’hub stesso o provenienti da altri spoke.

L’hub ha un AP dedicato all’applicazione delle modifiche provenienti da ciascuno spoke.

Per ottimizzare le prestazioni, ciascun CP e AP possiede una propria coda.
18
Figura 15: Hub-And-Spoke Replication Environment con Spoke in lettura/scrittura
Alcuni ambienti di replicazione Hub-And-Spoke prevedono la possibilità di configurare solo
alcuni spoke in modalità lettura/scrittura e lasciare gli altri in sola lettura.
5.4.3 AMBIENTE DI REPLICAZIONE N-WAY
In un ambiente di replicazione N-Way (Multi-Master) ciascun DB comunica direttamente con tutti
gli altri DB presenti nell’ambiente. Le modifiche apportate sugli oggetti replicati presso un DB
vengono catturate ed inoltrate direttamente verso ciascuno degli altri DB, dove vengono
contestualmente applicate. Un ambiente di replicazione N-Way è caratterizzato tipicamente dai
seguenti componenti:

Ciascun DB possiede uno o più CP o SC per catturare le modifiche apportate sugli oggetti
replicati.

Ciascun DB possiede più propagation per inoltrare le modifiche catturare a tutti gli altri DB.

Ciascun DB possiede più AP per applicare le modifiche provenienti dagli altri DB.

Per ottimizzare le prestazioni, ciascun CP e AP possiede una propria coda.
19
Figura 16: N-Way Replication Environment
6. REALIZZAZIONE DI UN AMBIENTE DI REPLICAZIONE
In questo lavoro si è pensato di realizzare la replicazione One-Way nell’ambiente Oracle
11.2g Two-Database. Tale modalità di replicazione prevede che le modifiche possano essere
applicate ad un solo DB e da qui catturate e propagate verso l’altro DB. Nel nostro esempio
utilizziamo una tabella Giocatori presente all’interno del DB Test1, le cui modifiche vengono
propagate e applicate al DB Test2.
Figura 17: Schema del processo di replicazione
Per poter realizzare questo ambiente di replicazione occorre configurare opportunamente le
due macchine sulle quali sono stati installati i DBMS Oracle.
6.1 CREAZIONE DI UN DATABASE
Il primo passo da seguire per creare l’ambiente di replicazione è la creazione dei DB su
entrambe le macchine. Con Oracle questo è possibile mediante una procedura guidata denominata
20
Assistente alla configurazione del database. Al termine di tale procedura è possibile sbloccare, oltre
agli account di default sys e system, ulteriori account collegati al DB, mediante il tasto Gestione
Password. In questo esempio è stato sbloccato l’utente scott, con il quale è stata creata la tabella
oggetto di replicazione.
6.2 PREREQUISITI
Per poter realizzare l’ambiente di replicazione occorre seguire preventivamente la seguente
procedura:
1. Configurazione dei parametri di inizializzazione ai valori indicati:
a. GLOBAL_NAMES: deve essere impostato al valore TRUE su entrambi i DB; tale
parametro specifica se un Database link debba avere lo stesso nome del DB al quale
si connette;
b. COMPATIBLE: deve essere impostato ad un valore 11.2.0 o superiore su entrambi i
DB partecipanti all’ambiente di replicazione: esso specifica la release con la quale
l’Oracle Server deve mantenere la compatibilità.
Per settare opportunamente questi parametri occorre eseguire in SQL Plus (tool di default
per l’interazione con il DBMS) i seguenti comandi:
ALTER SESSION SET GLOBAL_NAMES = TRUE;
ALTER SESSION SET COMPATIBLE = 11.2.0;
Per rendere permanenti tali modifiche basta sostituire la parola chiave SESSION con
SYSTEM. Ovviamente ciò richiede privilegi di amministratore. L’utente sys può assumere i
privilegi di amministratore tramite il comando:
CONNECT SYS AS SYSDBA
dopo aver lanciato il programma SQL Plus in un interprete di comandi tramite la stringa:
sqlplus /nolog
Per controllare l’impostazione dei parametri basta eseguire il comando show che presenta la
seguente sintassi:
21
SHOW PARAMETERS NOME_PARAMETRO
2. Il DB sul quale vengono catturate le modifiche deve essere in esecuzione in modalità
ARCHIVELOG. Nel nostro esempio il DB Test1 deve essere eseguito in questa modalità.
Per fare ciò occorre eseguire i seguenti comandi:
SHUTDOWN
STARTUP MOUNT
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
3. A questo punto occorre configurare opportunamente la rete in maniera tale che il DB Test1
possa comunicare con il DB Test2. In particolare, è necessario impostare su entrambi i nodi
un processo listener che si ponga in ascolto di richieste remote. Per fare ciò è possibile
utilizzare l’utility Net Manager di Oracle. Nel nostro caso la configurazione del listener sul
nodo sorgente è quella riportata nella Figura 18. Notiamo che l’indirizzo IP di tale nodo è
172.16.1.9 ed è riportato nel campo Host. Esso corrisponde all’indirizzo IP del nodo
sorgente. Sul nodo destinazione la configurazione è duale e presenta l’IP 172.16.1.7. Un
altro punto che richiede attenzione è quello di configurazione della Denominazione dei
servizi. Essenzialmente si tratta di informazioni di localizzazione di un DB, o di altri servizi,
all’interno della rete. In Figura 19 è presentato il dettaglio della configurazione presso il
nodo sorgente (che è identica anche sul nodo destinazione) riguardante il servizio Test2 (DB
presente sul nodo destinazione). Una configurazione, con le opportune modifiche, deve
essere effettuata (su entrambi i nodi) anche per la localizzazione del DB Test1.
22
Figura 18: Configurazione listener con il Net Manager
Figura 19: Configurazione del servizio Test2 con il Net Manager
23
Una volta completata la configurazione occorre ricordarsi di salvarla opportunamente con la
voce presente nel menù File. Completata tale procedura è possibile avviare il listener
mediante l’appropriato strumento messo a disposizione da Oracle, lsnrctl. Per avviare tale
tool basta digitarne il nome all’interno di un interprete dei comandi ed eseguire start. Per
verificare i servizi associati al listener basta digitare il comando services.
4. Creare un amministratore dell’OS presso ogni DB dell’ambiente. In questo esempio
assumiamo che tale amministratore sia streamadmin.
a. Creare un tablespace per l’amministratore dell’OS. L’intero ambiente è gestito da un
utente amministrativo. L’amministratore necessita di alcuni specifici privilegi e deve
creare alcune tabelle per storicizzare le informazioni relative allo stream. Non
bisogna utilizzare questo account per nessun’altra finalità. L’amministratore crea
alcune tabelle nel suo tablespace di default e, a tale scopo, ne viene creato uno
dedicato per evitare di operare su quello predefinito. Un tablespace è un contenitore
di strutture logicamente correlate tra loro. È raccomandato utilizzare un tablespace
separato per ogni stream. Utilizzare il seguente comando per creare il tablespace:
CREATE TABLESPACE streams_tbs DATAFILE
'C:\Oracle11g\streams_tbs.dbf'
SIZE 25M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
b. Creare l’utente che agirà da amministratore, associandogli il tablespace appena
creato:
CREATE USER streamadmin IDENTIFIED BY password
DEFAULT TABLESPACE streams_tbs
QUOTA UNLIMITED ON streams_tbs;
c. Fornire all’amministratore i seguenti ruoli:
GRANT CONNECT, RESOURCE, DBA TO streamadmin;
d. Eseguire la procedura GRANT_ADMIN_PRIVILEGE per fornire i privilegi richiesti
all’amministratore:
24
BEGIN
DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(
grantee
=> 'streamadmin',
grant_privileges => TRUE);
END;
/
5. Su entrambi i DB, sia quello sorgente che destinazione, occorre creare la tabella oggetto di
replicazione:
CREATE TABLE scott.Giocatori (id number primary key, nome
varchar2(20), cognome varchar2(20), squadra
varchar2(15));
6.3 CREAZIONE DELLE CODE E DEL DATABASE LINK
A questo punto occorre eseguire il seguente script in SQL Plus su un computer che può
connettersi a tutti i DB dell’ambiente di replicazione. Tale script è diviso in varie parti:
a. Memorizza informazioni di controllo
SET ECHO ON
SPOOL streams_setup_simple.out
b. Crea la coda ANYDATA presso il database Test1
I dati si spostano dal DB sorgente a quello di destinazione attraverso code.
Utilizzando la procedura SET_UP_QUEUE nel package DBMS_STREAMS_ADM è
possibile costruire le code. Di default questa procedura crea una queue table il cui
nome è streams_queue_table ed una coda il cui nome è streams_queue. È possibile
sovrascrivere questi nomi specificando i paramentri queue_table e queue_name della
procedura SET_UP_QUEUE. I nomi di default vanno bene, a meno che si vogliano
creare code multiple e multiple queue tables.
CONNECT streamadmin@Test1
EXEC DBMS_STREAMS_ADM.SET_UP_QUEUE();
25
Figura 20: Creazione dell'utente amministratore ed esecuzione degli script di configurazione
c. Crea il Database link presso Test1
ACCEPT password PROMPT 'Enter password for user: ' HIDE
CREATE
DATABASE
LINK
Test2
CONNECT
TO
streamadmin
IDENTIFIED BY &password USING 'Test2';
d. Crea la coda ANYDATA presso il database Test2
CONNECT streamadmin@Test2
26
EXEC
DBMS_STREAMS_ADM.SET_UP_QUEUE();
e. Chiude le operazioni di controllo
SET ECHO OFF
SPOOL OFF
6.4 CONFIGURAZIONE DEI PROCESSI DI CATTURA, PROPAGAZIONE
ED APPLICAZIONE
Un secondo script si preoccupa di impostare opportunamente i processi di cattura,
propagazione e applicazione delle modifiche presso gli opportuni nodi. Come il precedente, anche
questo script è diviso in varie parti:
a. Configura la propagazione presso il DB Test1. Una volta che i cambiamenti sono
catturati ed accodati, occorre propagarli al DB di destinazione. Per fare questo, si
deve creare un processo di propagazione ed associare la coda sorgente con la coda di
destinazione. Le code sorgente e destinazione nel DB sorgente ed in quello di
destinazione sono state create nel precedente script. Questa procedura crea un
processo di propagazione,
per il quale la coda sorgente è streams_queue nel
database Test1 e la coda di destinazione è streams_queue nel database Test2. Inoltre
aggiunge anche regole DML e DDL all’insieme di regole positive.
SET ECHO ON
SPOOL streams_share_Giocatori.out
CONNECT streamadmin@Test1
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES(
table_name
=> 'scott.Giocatori',
streams_name
=> 'Test1_to_Test2',
source_queue_name
=>
'streamadmin.streams_queue',
destination_queue_name =>
'streamadmin.streams_queue@Test2',
include_dml
=> TRUE,
include_ddl
=> TRUE,
27
source_database
=> 'Test1',
inclusion_rule
=> TRUE,
queue_to_queue
=> TRUE);
END;
/
b. Configura il CP presso Test1. Il processo di capture inizia la replicazione catturando
i cambiamenti nel DB sorgente e formattando ognuno di essi in un LCR ed
accodandoli. Occorre creare un CP per estrarre i cambiamenti dal redo log. Mentre si
crea un CP, vengono aggiunte regole per specificare quali cambiamenti catturare e
quali scartare. Occorre fare questo utilizzando la procedura ADD_TABLE_RULES
del package DBMS_STREAMS_ADM:
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name
=> 'scott.Giocatori',
streams_type
=> 'capture',
streams_name
=> 'capture_simp',
queue_name
=> 'streamadmin.streams_queue',
include_dml
=> TRUE,
include_ddl
=> TRUE,
inclusion_rule => TRUE);
END;
/
Questa chiamata alla procedura crea il processo locale chiamato capture_simp. È
possibile utilizzare il parametro opzionale source_database per specificare un’altro
database per uno downstream capture. Se questo parametro viene omesso (come in
questo esempio) o impostato a NULL, la procedura creerà un processo di cattura
locale.
Il parametro streams_type indica che questa procedura creerà un CP (da notare che la
stessa procedura sarà utilizzata successivamente per creare un AP). Il parametro
inclusion_rule con il valore impostato a TRUE indica che questa procedura creerà un
insieme positivo di regole per il processo di cattura. Il valore TRUE per il parametro
include_dml indica che una regola sarà creata per i cambiamenti DML, ed il valore
28
TRUE per il parametro include_ddl indica che una regola sarà creata per i
cambiamenti DDL. Il parametro table_name indica che queste regole sono associate
alla tabella Giocatori. La coda, streams_queue, specificata in questa procedura era
stata creata dalla procedura SET_UP_QUEUE nello script precedente.
c. Impostazione dell’SCN per la tabella Giocatori nel DB Test2. È necessario istanziare
l’SCN per la tabella dal DB sorgente che si vuol replicare. Questo assicura che i
cambiamenti nella tabella sorgente, catturati prima di tale operazione non saranno
applicati al DB di destinazione. La procedura istanzia l’SCN per la tabella Giocatori
nel DB di destinazione, prendendo il valore corrente dal DB sorgente. La procedura
mostra
come
GET_SYSTEM_CHANGE_NUMBER
del
package
DBMS_FLASHBACK restituisca il corrente SCN del DB sorgente. E’ da notare che
la
procedura
SET_TABLE_INSTANTIATION_SCN
del
package
DBMS_APPLY_ADM è chiamata attraverso il Database link.
DECLARE
iscn
NUMBER;
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@TEST2(
source_object_name
=> 'scott.Giocatori',
source_database_name
=> 'Test1',
instantiation_scn
=> iscn);
END;
/
d. Configura l’AP presso il DB destinazione. Occorre creare un AP ed associargli la coda
di destinazione. Inoltre, per tale processo, occorre aggiungere anche delle regole. Si
realizza questo chiamando la procedura ADD_TABLE_RULES del package
DBMS_STREAMS_ADM:
CONNECT streamadmin@Test2
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name
=> 'scott.Giocatori',
29
streams_type
=> 'apply',
streams_name
=> 'apply_simp',
queue_name
=> 'streamadmin.streams_queue',
include_dml
=> TRUE,
include_ddl
=> TRUE,
source_database => 'Test1',
inclusion_rule
=> TRUE);
END;
/
Questa procedura crea un AP (come indicato dal parametro streams_type) per la
tabella Giocatori nello schema scott. L’AP, chiamato apply_simp, è associato con la
streams_queue. All’AP sono aggiunte anche regole di DML e di DDL all’insieme di
regole positive (come indicato dal parametro inclusion_rule).
e. Avvio dell’AP. Per far partire il processo di apply, occorre connettersi al DB di
destinazione
ed
eseguire
la
procedura
START_APPLY
del
package
DBMS_APPLY_ADM. Comunque, prima di fare questo, è raccomandato impostare
il parametro disable_on_error del processo di apply ad n, cosicché tale processo non
sarà disabilitato anche se incontrerà errori.
BEGIN
DBMS_APPLY_ADM.SET_PARAMETER(
apply_name
=> 'apply_simp',
parameter
=> 'disable_on_error',
value
=> 'N');
END;
/
BEGIN
DBMS_APPLY_ADM.START_APPLY(
apply_name
=> 'apply_simp');
END;
/
30
f. Avvio del CP. Per far partire il processo di capture, occorre connettersi al DB
sorgente
ed
eseguire
la
procedura
START_CAPTURE
del
package
DBMS_CAPTURE_ADM:
CONNECT streamadmin@Test1
BEGIN
DBMS_CAPTURE_ADM.START_CAPTURE(
capture_name
=> 'capture_simp');
END;
/
SET ECHO OFF
SPOOL OFF
6.5 MODIFICHE DML E DDL SU UNA TABELLA E VERIFICA DEL
RISULTATO
Per testare la configurazione dell’ambiente di replicazione abbiamo creato in entrambi i DB
la tabella caratterizzata dalla seguente relazione:
Giocatori(id, nome, cognome, squadra)
ed eseguito le seguenti operazioni sul DB sorgente, sia di natura DML che DDL. Innanzitutto, è
stata eseguita la seguente sequenza di comandi, che aggiunge una tupla all’interno della tabella su
menzionata:
CONNECT scott
Enter password: password
INSERT INTO scott.Giocatori VALUES (1, ‘Diego’, ‘Maradona’,
‘Napoli’);
COMMIT;
31
Figura 21: Inserimento di una tupla nella tabella Giocatori
In seguito abbiamo eseguito la query sul DB destinazione per verificare l’effettiva
propagazione e applicazione delle modifiche:
CONNECT scott
Enter password: password
SELECT * FROM Giocatori;
Figura 22: Query di verifica della propagazione dell'inserimento della tupla
32
Fatto ciò, abbiamo modificato il tipo di un attributo della tabella sul DB sorgente e
verificato la conseguente propagazione sul DB destinazione eseguendo su ciascuno,
rispettivamente, i seguenti due comandi:
1. ALTER TABLE scott.Giocatori MODIFY(squadra VARCHAR2(20));
2. DESC scott.Giocatori
Figura 23: Modifica del tipo dell'attributo Squadra
Figura 24: Propagazione della modifica del tipo di attributo sul DB destinazione
33
Bibliografia
[1] Paolo Atzeni, Stefano Ceri, Piero Fraternali, Stefano Paraboschi, Riccardo Torlone. Basi di
dati – Architetture e linee di evoluzione. McGraw-Hill, 2007.
[2] Roberto Achanoso et al. Oracle Database Net Services Administrator's Guide. Oracle,
Ottobre 2010.
[3] Sanja Misbra. Makind Data Flow. Oracle Magazine, Novembre/Dicembre 2004.
[4] Randy Urbano et al. Oracle Streams Extended Examples. Oracle, Agosto 2010.
[5] Randy Urbano et al. Oracle Database 2 Day + Data Replication and Integration Guide.
Oracle, Ottobre 2010.
[6] Randy Urbano et al. Oracle Streams Concepts and Administration. Oracle, Ottobre 2010.
[7] Randy Urbano et al. Oracle Streams Replication Administrator's Guide. Oracle, Ottobre
2010.
34