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