Issuu on Google+

UN IVERSITÀ DEGLI STUDI DI MILAN O Facoltà d i Scienze e Tecnologie Corso d i Laurea Triennale in Inform atica

LA TECN OLOGIA FLASHBACK N EI RD BMS ORACLE E POSTGRESQL

RELATORE Prof. Stefano Montanelli CORRELATORE Dott. Sergio Mior

TESI DI LAUREA DI Michele Mariani Matricola 729914

Anno Accad em ico 2012/ 2013


A Ornella e Pierangelo


Indice

Introduzione

3

1 Architettura RDBMS

5

1.1

Architettura Oracle

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Architettura PostgreSQL

. . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Oracle Flashback technology

6 17

24

2.1

Panoramica generale della tecnologia Oracle Flashback

. . . . . . . . . . .

25

2.2

Requisiti per utilizzare la tecnologia Oracle Flashback

. . . . . . . . . . .

29

2.3

Utilizzo delle funzioni Flashback per lo sviluppo di applicazioni

. . . . . .

31

2.4

Utilizzo delle funzioni Flashback per gli amministratori del database . . . .

45

3 PostgreSQL TimeTravel technology

54

3.1

Panoramica generale della tecnologia TimeTravel

. . . . . . . . . . . . . .

3.2

Installazione e disinstallazione della tecnologia TimeTravel

3.3

Utilizzo delle funzioni TimeTravel

3.4

Utilizzo dell'applicazione PHP

55

. . . . . . . . .

60

. . . . . . . . . . . . . . . . . . . . . .

61

. . . . . . . . . . . . . . . . . . . . . . . .

65

Conclusioni

76

Sitograa

78

Indice analitico

80

2


Introduzione

L'errore umano nell'eseguire modiche ai dati è una delle principali fonti di disagio che necessita di una particolare attenzione, in quanto tale errore non viene rilevato da sistemi di disaster recovery ed è anche dicile da correggere perché si vorrebbe estirpare senza ledere le modiche corrette eseguite da altri, persone o applicativi che siano. Nel seguente elaborato parlerò della possibilità di rimediare a una transazione sbagliata dovuta a un errore umano confrontando le relative funzionalità nei RDBMS Oracle e PostgreSQL. Ho scelto Oracle 11.2 perché, oltre ad essere il più famoso e utilizzato sistema di gestione di basi di dati in ambito lavorativo nonostante il suo alto costo di licenza, possiede la tecnologia Flashback che ha l'obiettivo di correggere errori umani e sulla quale concentrerò la mia attenzione in questa tesi. PostgreSQL è una reale alternativa a Oracle in quanto è rilasciato con licenza libera BSD ed è tra gli RDBMS open source quello sostenuto dalla comunità di supporto più numerosa. L'obiettivo principale del mio lavoro è stato quello di implementare una tecnologia nel RDBMS PostgreSQL 9.3 che, prendendo spunto dalla tecnologia Oracle Flashback, permettesse di visualizzare i dati all'interno del database allo stato in cui si trovavano in un momento del passato e ripristinarli se necessario. L'aspetto che più mi ha interessato di questo lavoro è stato quello di poter arricchire un

3


INTRODUZIONE

RDBMS con licenza open source fornendo agli utenti nali un prodotto più completo. Il mio lavoro è suddiviso in tre capitoli. Nel primo capitolo descriverò l'architettura dei due RDBMS scelti evidenziando per ciascuno le principali strutture siche e logiche. Nel secondo capitolo, dopo aver introdotto teoricamente la tecnologia Oracle Flashback, mostrerò come utilizzarla con degli esempi. Nel terzo e ultimo capitolo proporrò la mia implementazione in PostgreSQL descrivendone le funzioni e presentandone l'utilizzo tramite esempi.

4


Capitolo

1

Architettura RDBMS

Indice 1.1

1.2

Architettura Oracle 1.1.1

Database Oracle

1.1.2

Istanza Oracle

. . . . . . . . . . . . . . . . . . . . . . . . .

6

. . . . . . . . . . . . . . . . . . . . . . . . . . .

6

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Architettura PostgreSQL

. . . . . . . . . . . . . . . . . . . . .

10

17

1.2.1

Libreria libpq

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

1.2.2

Processi server

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

1.2.3

Storage manager

. . . . . . . . . . . . . . . . . . . . . . . . . . .

19

1.2.4

Cluster database

. . . . . . . . . . . . . . . . . . . . . . . . . . .

20

Nel seguente capitolo descriverò l'architettura dei due RDBMS scelti evidenziando per ciascuno le principali strutture siche e logiche. 5


CAPITOLO 1.

1.1

ARCHITETTURA RDBMS

Architettura Oracle

L'architettura Oracle si basa sui concetti di database e di istanza, considerata la parte  logica del database cui essa è associata. Per ogni database ci possono essere una o piÚ istanze (RAC) ognuna con il proprio SID (Oracle System ID) che la identica unicamente.

1.1.1

Database Oracle

Un database Oracle è formato sia da strutture logiche che da strutture siche.

1.1.1.1 Strutture siche La struttura sica del database è costituita principalmente da tre tipi di le (Figura 1.1.1):

Data le:

contengono tutti i dati del database. Un database Oracle ha uno o piĂš data

le mentre ogni data le è associato solo ad un singolo database.

Control le:

mantengono le informazioni sulla struttura sica del database, sono critici

per il database per cui Oracle può mantenerne piÚ copie mirrored (di default 1). Contengono il nome e l'ID del database, il timestamp della creazione, le caratteristiche di ruolo e la locazione sica di tutti i data le e redo log le.

Redo log le:

nei redo log le vengono memorizzate tutte le modiche eettuate al data-

base. Ogni database possiede almeno due redo log le, perchÊ Oracle scrive in questi le in maniera circolare: quando un redo log le è pieno allora Oracle scrive in quello successivo, quando l'ultimo redo log le è pieno allora Oracle ricomincia dal primo.

1

Ciò viene fatto al ne di poter eettuare una recovery nel caso in cui un guasto, un errore, o semplicemente uno shutdown improvviso del database impedisca di scrivere

1 Se

siamo in modalitĂ  archive log il redo log le prima di essere sovrascritto viene archiviato su disco per garantire un eventuale restore/recover all'ultima transazione confermata (commit) 6


CAPITOLO 1.

ARCHITETTURA RDBMS

le modiche apportate nei data le e renderle così denitive e permanenti; infatti basterà eseguire nuovamente le istruzioni contenute nei redo log le per ripristinare una situazione precedente consistente.

Oltre a queste tre vi sono altre strutture siche, tra cui:

Parameter le (ple), server parameter le (sple):

deniscono la congurazione

dell'istanza all'avvio.

Password le:

utilizzati per la gestione delle password degli utenti appartenenti ai gruppi

sysdba o sysoper e per permettere agli utenti di connettersi da remoto.

Flashback log:

creati solo se la funzionalità Flashback è attiva e utilizzati per mantenere

le informazioni necessarie al funzionamento della tecnologia Flashback.

Archived log le:

log le archiviati.

Figura 1.1.1: Strutture siche

1.1.1.2 Strutture logiche Per gestire, immagazzinare e recuperare i dati in maniera più eciente Oracle divide il database in unità logiche più piccole (Figura 1.1.2): 7


CAPITOLO 1.

Tablespace:

ARCHITETTURA RDBMS

un database è logicamente suddiviso in unità più piccole chiamate tablespace

a cui sono associati uno o più data le. Quando si crea un database, Oracle crea almeno i tablespace system e sysaux.

Block:

un block è la più piccola unità di storage in Oracle ed è generalmente pari ad un

multiplo della misura del blocco di sistema operativo. La misura del block è data dal parametro db_blocksize ed è determinata alla creazione del database. A livello di tablespace invece si possono denire dei db_blocksize_nk diversi da quello denito alla creazione.

Extent:

un extent è un raggruppamento di block contigui.

Segment:

un segmento è costituito da un insieme di extent allocati per ospitare le righe

degli oggetti del database.

1.1.1.3 Schema Raccolta di oggetti di cui un utente è proprietario. Lo schema non è collegato ai tablespace in cui le strutture logiche sono state create poiché gli oggetti di uno stesso schema possono risiedere su più tablespace ed un tablespace può contenere oggetti di diversi schema. Inoltre, un utente può essere proprietario di un solo schema. All'interno dello schema troviamo i seguenti oggetti:

Tabella:

è l'unità minima di memorizzazione dei dati; composta da colonne rappresen-

tanti le caratteristiche secondo cui vengono distinti i dati, dette attributi, e da righe che rappresentano l'occorrenza dei dati, denite tuple.

Vista:

è un oggetto del database che contiene il risultato di una query (stored query):

copie locali di dati locali o remoti. Le viste non contengono dei dati ma li ottengono dalle tabelle su cui si basano (based tables). 8


CAPITOLO 1.

Sequence:

ARCHITETTURA RDBMS

è un oggetto del database dal quale piÚ utenti possono generare numeri interi

univoci (serie aritmetica di ragione x, ad esempio per generare una primary key).

Trigger:

sono oggetti di codice PL/SQL memorizzati nel database, vengono eseguiti o

attivati automaticamente in seguito ad un evento.

Indici:

sono strutture opzionali associate alle tabelle per migliorare le prestazioni del

recupero dei dati, forniscono un accesso diretto ai dati della tabella.

Sinonimi:

sono usati per fornire un alias agli oggetti giĂ  esistenti, possono essere sia pub-

blici ed accessibili a tutti gli utenti che privati, concedendo l'accesso solo all'utente proprietario del sinonimo.

Cluster index:

è un oggetto contenente una o piÚ tabelle che hanno in comune almeno

una colonna. Costituisce in pratica un join sico tra le tabelle coinvolte.

Db link:

è un oggetto pubblico o di uno schema, che permette l'accesso ad oggetti di un

altro database.

Snapshot:

memorizza il risultato di una query tra una o piĂš tabelle situate in un database

remoto. Utilizzato nell'eettuare la replica dei dati, consente di ottenere una copia in sola lettura dei dati remoti nel nodo locale.

Stored procedure o function:

sono entrambe dei blocchi di comandi eseguibili dall'u-

tente, che vengono memorizzate all'interno del database; la seconda, però, ha la caratteristica di restituire un valore.

Package:

questo oggetto contiene procedure, funzioni e variabili. Ăˆ suddiviso in header

(specication) e body.

9


CAPITOLO 1.

ARCHITETTURA RDBMS

Figura 1.1.2: Strutture logiche

1.1.2

Istanza Oracle

L'istanza Oracle acquisisce la risorsa memoria (RAM) ed è formata dalla SGA (System Global Area), PGA (Program Global Area) e dai processi in background.

1.1.2.1 System Global Area La SGA è un'area di memoria condivisa da tutti gli utenti del database, viene allocata all'avvio dell'istanza Oracle e rilasciata alla chiusura (shut down). La System Global Area è costituita dalle seguenti aree di memoria (Figura 1.1.3):

Database buer:

blocchi dei data le letti recentemente mantenuti in memoria (cache)

per migliorare le prestazioni rendendo necessari meno accessi su disco. Possono essere dirty buer (non ancora copiati nei datale), pinned buer (acceduti al momento

10


CAPITOLO 1.

ARCHITETTURA RDBMS

o mantenuti per uso futuro) o free buer (non usati o contenenti blocchi in sola lettura).

Redo log buer cache:

la redo log buer è una memoria circolare che mantiene le infor-

mazioni sulle modiche apportate al database tramite i comandi: insert, update,

delete, create, alter o drop. Queste informazioni vengono usate per ripetere le modiche fatte in caso di failure e procedere alla recovery: se il database viene chiuso in maniera anomala e non viene perso alcun le, l'istanza può eseguire il recupero del database con le informazioni che da questa area di memoria vengono scritte nei redo log le.

Shared pool (Library cache, Data dictionary cache):

contiene le traduzioni delle

istruzioni in linguaggio eseguibile, necessarie per l'esecuzione.

Siccome il proces-

so di traduzione richiede del tempo, nel momento in cui deve essere eseguita una query si controlla innanzitutto se è già presente in questo buer la corrispondente traduzione o quella di uno statement identico o similare (equivalente).

Large pool (opzionale):

fornisce un ulteriore allocazione di memoria per particolari

operazioni quali backup e restore, e per letture sequenziali in parallelo.

Java pool (opzionale):

fornisce memoria per le operazioni Java.

11


CAPITOLO 1.

ARCHITETTURA RDBMS

Figura 1.1.3: System Global Area

1.1.2.2 Program Global Area La Program (o Process o Private) Global Area (PGA) contiene dati ed informazioni dei processi relativi ad ogni connessione utente: non c'è condivisione tra più processi; dunque viene allocata per ogni processo server e rilasciata quando il processo è terminato. Se siamo in modalità dedicated server (un processo server per ogni connessione) allora la PGA contiene lo stack space e le informazioni sulla sessione (Figura 1.1.4), in modalità shared server (connessioni raggruppate per mezzo di un dispatcher) invece le informazioni sulla sessione sono nella SGA.

12


CAPITOLO 1.

ARCHITETTURA RDBMS

Figura 1.1.4: Program Global Area

1.1.2.3 Processi in background Processi creati all'avvio di Oracle e associati ad ogni singola istanza, usati per svolgere le operazioni di input/output e per gestire gli accessi alle strutture di Oracle. Tra i principali citiamo (Figura 1.1.5):

Database writer (DBWn):

scrive nei data le il contenuto del database buer cache.

Di solito agisce quando non ci sono piÚ free buer, o la richiesta da un processo server utente è superiore alla disponibilità oppure dopo un checkpoint ma non ad ogni commit.

Log writer (LGWR):

scrive i blocchi del redo log buer nei redo log le online. Per

rendere eettive le modiche apportate ai dati è necessario eseguire il comando commit, se invece si vogliono eliminare gli ultimi cambiamenti si dovrà eseguire il comando rollback. Agisce quando viene lanciato il commit, quando il redo log buer è pieno per 1/3 o quando il DBWn scrive su disco.

Checkpoint (CKPT):

è un processo che gestisce l'evento che scarica le modiche dalla

buer cache al disco e aggiorna i control le e i data le, riducendo il tempo necessario per la recovery dell'istanza. Interviene automaticamente ad ogni checkpoint.

System monitor (SMON):

se il database è stato chiuso in modo non corretto potrebbe

trovarsi in uno stato inconsistente, quindi l'SMON all'avvio successivo del database 13


CAPITOLO 1.

ARCHITETTURA RDBMS

eettua il recovery usando i redo log online per ripristinare lo stato consistente. Inoltre libera i segmenti temporanei nei tablespace e realizza il coalesing degli spazi liberi contigui. Si attiva regolarmente o può essere richiamato da altri processi.

Process monitor (PMON):

ripulisce dai processi utente falliti (aggiornando la tabella

delle transazioni attive, ecc..) e libera le risorse rilasciate. Si attiva periodicamente.

Archiver (ARCH):

questo processo copia il contenuto dei redo log le quando il corrente

redo log è pieno quindi ne segue un checkpoint e viene chiuso. Arch non è sempre attivo ma solo quando si è in modalità archivelog e si sceglie quindi di archiviare e conservare i contenuti dei le di log per utilizzarli, se necessario, per un successivo restore/recovery.

14


CAPITOLO 1.

ARCHITETTURA RDBMS

Figura 1.1.5: Processi in background

15


CAPITOLO 1.

ARCHITETTURA RDBMS

1.1.2.4 Startup e shutdown Un'istanza è creata tramite il comando startup e chiusa tramite lo shutdown. Esistono tre comandi per avviare un'istanza Oracle:

Startup no mount:

si crea un'istanza utilizzando i parametri di inizializzazione (ple o

sple), viene allocata la SGA e vengono creati i processi di background.

Startup mount:

l'istanza viene creata e associata al database. Vengono letti i control

le e viene vericato lo stato di correttezza del database. Il database è comunque chiuso e quindi non è possibile accedere con utenti le cui password sono salvate al proprio interno ma si deve accedere tramite gli utenti sys, system o altri le cui password sono contenute nel password le. Può essere utile per svolgere funzioni amministrative non eseguibili nel caso siano connessi altri utenti.

Startup:

si crea l'istanza, si monta il database e vengono aperti i data le. Il database è

aperto e tutti gli utenti possono connettersi e accedere agli oggetti in esso contenuti.

Per terminare in modo regolare un'istanza si devono svolgere le seguenti fasi in sequenza:

ˆ

Scrivere i dati della SGA nei data le e nei redo log le, quindi eseguire un processo di checkpoint; ora i data le e i redo log le sono chiusi mentre i control le rimangono aperti e il database si trova nello stato  chiuso .

ˆ

Rilasciare le risorse del sistema operativo e aggiornare le voci rilevanti del control le per registrare l'avvento di uno shutdown consistente; ora anche i control le sono chiusi e il database si trova nello stato  no mount .

ˆ

Liberare la memoria associata alla SGA, PGA e terminare i processi di background.

16


CAPITOLO 1.

ARCHITETTURA RDBMS

Esistono diversi comandi di shutdown:

Normal shutdown:

prima di chiudere l'istanza si aspetta che tutti gli utenti connessi si

disconnettano, e si impedisce la connessione ai nuovi utenti.

Immediate:

eventuali transazioni sospese vengono eliminate con un rollback, si forza la

disconnessione di tutti gli utenti connessi e si procede con la chiusura dell'istanza.

Transactional:

prima di chiudere l'istanza si deve aspettare che almeno le transazioni

correnti degli utenti siano terminate con un commit o con una rollback. Quando non ci sono transazioni in sospeso si forza la disconnessione di eventuali utenti connessi.

Abort:

istanza chiusa incondizionatamente.

Il database si trova quindi in uno stato

inconsistente e si avrĂ  dunque la necessitĂ  di eettuare la recovery dell'istanza al prossimo startup.

1.2

Architettura PostgreSQL

PostgreSQL si basa sul concetto di cluster e di database come partizioni del cluster. Come Oracle, usa l'architettura client/server dove i dati sono gestiti in modo centralizzato dal server e messi a disposizione di piĂš client. Sul client troviamo la libreria libpq mentre sul server troviamo oltre allo Storage manager (la parte sica del server) principalmente due processi: il Postmaster e il Postgres server (Figura 1.2.1).

17


CAPITOLO 1.

ARCHITETTURA RDBMS

Figura 1.2.1: Struttura PostgreSQL

1.2.1

Libreria libpq

La libreria libpq ha il compito di inviare un pacchetto con la richiesta di connessione contenente il nome dell'utente e quello del database a cui ci si vuole connettere oltre alle opzioni e comandi specici.

1.2.2

Processi server

Il Postmaster è un demone in ascolto che viene raggiunto da una richiesta di connessione del client attraverso una socket unix o attraverso una porta TCP. Quando riceve la richiesta, controlla che il client sia abilitato e attiva una copia del Postgres server a cui poi fa connettere il client. Fatto ciò si rimette in ascolto di nuove richieste di connessioni dei client.

PostgreSQL,

quindi, attiva un processo Postgres server per ogni client che cerca di connettersi alla base

18


CAPITOLO 1.

ARCHITETTURA RDBMS

di dati.

1.2.3

Storage manager

Lo Storage manager è il responsabile della gestione dello spazio e delle risorse di controllo del server che attua grazie alle sue componenti, ovvero (Figura 1.2.2):

File manager:

provvede alla gestione dei le.

Buer manager:

provvede alla gestione del buer condiviso.

Page manager:

usa un algoritmo last recently used (LRU) per gestire le pagine.

Lock manager:

si occupa di coordinare la concorrenza sui dati per mantenerne la con-

sistenza.

IPC:

realizza la sincronizzazione della cache.

Disk manager:

si occupa dell'interfaccia con la parte di allocazione sica dei dati.

Figura 1.2.2: Storage Manager

19


CAPITOLO 1.

ARCHITETTURA RDBMS

1.2.3.1 Struttura della transazione Si tratta di utilizzare un'area di cache dove i dati vengono gestiti salvaguardando le proprietĂ  ACID e applicando la tecnica di shadowing nelle transazioni sui dati stessi. La tecnica consiste nel creare una copia dei dati da modicare, eettuare sulla stessa copia le modiche e poi renderla attiva solo al commit, rendendo inattiva la precedente versione che verrĂ  in seguito cancellata.

1.2.4

Cluster database

Un'istanza Postgres è costituita da un cluster (insieme di database di proprietà di utenti diversi) e dal processo Postmaster che gestisce il cluster. Il cluster è formato a sua volta dal catalogo di sistema, dai template database e dai database utente.

1.2.4.1 Catalogo di sistema Il catalogo di sistema è un insieme di tabelle possedute dal proprietario del cluster, le quali sono inoltre comuni a tutti i database presenti nel cluster. Tra le tabelle principali citiamo:

pg_user:

contiene informazioni sugli utenti come il nome, l'ID e i privilegi che gli sono

stati assegnati.

pg_tables:

fornisce informazioni sulle tabelle del cluster come il nome del proprietario,

lo schema e la tablespace a cui appartiene.

pg_settings:

contiene informazioni sui parametri di runtime dell'istanza tra cui il suo

nome, il valore corrente, una breve descrizione, ecc.

pg_database:

contiene le informazioni sulle basi di dati come il loro nome, il proprieta-

rio, le informazioni sulle modalitĂ  di creazione e i privilegi per accedervi. 20


CAPITOLO 1.

pg_statistic:

ARCHITETTURA RDBMS

fornisce informazioni sulle statistiche degli oggetti del cluster; questa ta-

bella viene aggiornata durante le operazioni di analyze degli oggetti.

Altro componente molto importante del catalogo è il Data dictionary il quale serve alla funzione di parsing (traduzione in codice eseguibile) dei comandi SQL.

1.2.4.2 Database Template Durante l'installazione di PostgreSQL vengono creati due database chiamati Template0 e Template1. Questi database sono usati come modelli per la creazione di tutti gli altri database. Template0 è un database non modicabile che contiene tutti gli oggetti standard. Template1 invece è il database di partenza utilizzato per la creazione dei nuovi database. Ogni nuovo database sarà una copia del Template1, quindi per creare una serie di database con determinate caratteristiche basterà modicare il Template1 in modo che nelle successive creazioni la modica sia propagata.

1.2.4.3 La directory pgdata In questa directory si trovano le strutture che identicano il cluster del database. È una parte essenziale e va dichiarata (attraverso la variabile d'ambiente $PGDATA) durante la creazione di un nuovo cluster. Più precisamente dentro a questa directory troviamo:

Il le postgres.conf

per impostare i parametri di congurazione.

I le pg_hba.conf e pg_ident.conf

per impostare la congurazione per l'autentica-

zione del client.

Il le PG_VERSION

contenente la versione di PostgreSQL utilizzata. 21


CAPITOLO 1.

ARCHITETTURA RDBMS

Il le postmaster.pid

contenente il PID del postmaster se quest'ultimo è attivo.

Il le postmaster.opt

contenente le opzioni con cui è partito il Postgres server.

La directory global

contenente tutte le tabelle e viste di sistema condivise da tutti i

database del cluster e contenente il le pg_control che può essere interrogato con l'utility pg_controldata per ottenere informazioni relative allo stato del cluster.

La directory pg_clog

contenente i le di status delle transazioni che possono assumere

uno dei seguenti stati: committata, in progress, abortita.

La directory pg_multixact

contenente i le di status delle multitransazioni.

Questi

le sono necessari alla gestione dei lock shared di riga.

La directory pg_serial

contenente informazioni riguardo alle transazioni serializzabili

committate.

La directory pg_snapshots

contenente gli snapshot esportati.

La directory pg_stat_tmp

contenente i le temporanei delle statistiche.

La directory pg_subtrans La directory pg_tblspc

contenente i le di status delle subtransazioni.

contenente i link simbolici alle locazioni siche delle tablespace

eventualmente create nel cluster.

La directory pg_twophase

contenente i le di stato delle transazioni preparate. Ta-

li transazioni garantiscono le funzionalità di 2 phase commit, cioè le transazioni distribuite tra più database cluster.

La directory pg_xlog

contenente i le WAL (write ahead log) nei quali vengono me-

morizzate tutte le variazioni a livello di blocco. Infatti quando una pagina dati viene

22


CAPITOLO 1.

ARCHITETTURA RDBMS

modicata non viene immediatamente scritta sul disco, ma al commit viene memorizzata la transazione all'interno di questi le che hanno una dimensione standard di 16 MB. Nel caso ci sia un crash del database al successivo avvio, grazie a questi le sarà possibile eettuare la recovery del database automaticamente (automatic recovery) all'ultima transazione confermata, rielaborando tutte le transazioni presenti nei WAL a partire dall'ultimo checkpoint. Il checkpoint è il numero di WAL no al quale tutti i dati del database, su disco, riettono le informazioni presenti sui WAL, i quali quindi, no a quel numero, non sono piÚ utili per un automatic recovery. Se un WAL si corrompe allora l'istanza sarà non avviabile a meno di utilizzare il comando pg_resetxlog.

La directory base

contente il database vero e proprio. Dentro questa directory troviamo

tante sottodirectory numeriche. La directory 1 corrisponde al database Template1 mentre directory con valori piĂš elevati corrispondono al database Template0 e ai database creati nel cluster senza specicare l'eventuale tablespace di appartenenza. Ogni directory numerica ha il proprio OID corrispondente nella tabella di sistema pg_database.

Ogni directory di database contiene tanti le dal nome numerico

quanti sono gli oggetti presenti all'interno del database. Il nome corrisponde all'OID dell'oggetto.

23


Capitolo

2

Oracle Flashback technology Indice 2.1

2.2

2.3

Panoramica generale della tecnologia Oracle Flashback 2.1.1

Funzionalità per lo sviluppo di applicazioni

2.1.2

Funzionalità di amministrazione di database

Automatic undo management

2.2.2

Permessi

26

. . . . . . . . . . .

28

. . .

29

. . . . . . . . . . . . . . . . . . .

29

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

Utilizzo delle funzioni Flashback per lo sviluppo di applicazioni

2.4

25

. . . . . . . . . . . .

Requisiti per utilizzare la tecnologia Oracle Flashback 2.2.1

. . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

2.3.1

Premessa

2.3.2

Oracle Flashback Query

2.3.3

Oracle Flashback Version Query

2.3.4

Oracle Flashback Transaction Query

2.3.5

DBMS_FLASHBACK Package

2.3.6

Flashback Transaction

2.3.7

Flashback Data Archive

. . . . . . . . . . . . . . . . . . . . . . .

44

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32 33 34

. . . . . . . . . . . . . . .

37

. . . . . . . . . . . . . . . . . .

39

. . . . . . . . . . . . . . . . . . . . . . .

41

Utilizzo delle funzioni Flashback per gli amministratori del database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

2.4.1

Recycle bin

2.4.2

Oracle Flashback Drop

. . . . . . . . . . . . . . . . . . . . . . .

48

2.4.3

Oracle Flashback Table

. . . . . . . . . . . . . . . . . . . . . . .

49

2.4.4

Oracle Flashback Database

. . . . . . . . . . . . . . . . . . . . .

45

51

Nel seguente capitolo utilizzerò stralci della guida oracle database 11.2 [SIT-04] per descrivere il concetto della Flashback , faranno seguito degli esempi.

24


CAPITOLO 2.

2.1

ORACLE FLASHBACK TECHNOLOGY

Panoramica generale della tecnologia Oracle Flashback

La tecnologia Oracle Flashback è formata da gruppo di caratteristiche di Oracle Database che permettono di vedere stati precedenti di oggetti del database o di ripristinare oggetti del database allo stato precedente. Con la Flashback è possibile:

ˆ

Eettuare query per recuperare dati passati

ˆ

Eettuare query per recuperare metadati che mostrano una storia dettagliata dei cambiamenti del database

ˆ

Recuperare tabelle o righe in un particolare istante di tempo

ˆ

Tracciare e archiviare automaticamente modiche transazionali di dati

ˆ

Far tornare ad uno stato precedente un oggetto, cancellando a ritroso le transazioni sull'oggetto stesso mentre il database resta online

Oracle Flashback usa il sistema automatic undo management (AUM) per ottenere metadati e dati dalle transazioni precedenti. Esso memorizza gli undo data, registrazioni delle operazioni inverse delle singole operazioni a suo tempo proposte dalle transazioni.

Ad

esempio, se un utente esegue un comando update per cambiare l'attributo salario di una tupla da 1000 a 1100, Oracle Database memorizza un comando update con valore 1000 per il salario negli undo data per quella tupla. Gli undo data sono persistenti, cioè sopravvivono all'arresto del database. Utilizzando le funzionalità di Flashback è possibile utilizzare gli undo data per eseguire query sui dati del passato o riparare danni logici.

Oltre ad usarli nelle funzionalitĂ  Flashback, Oracle

Database usa gli undo data per eseguire le seguenti operazioni: 25


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

ˆ

Rollback delle transazioni attive

ˆ

Svolgere l'operazione di undo durante l'operazione di instance recovery, eseguita allo startup dell'istanza a seguito di un crash, coinvolgente tutte le transazioni per cui si erano aggiornati i dati su disco prima di eseguire il commit della transazione

ˆ

Garantire la coerenza di lettura (read consistency) per SQL query

2.1.1

Funzionalità per lo sviluppo di applicazioni

Nello sviluppo di applicazioni è possibile utilizzare le seguenti funzioni di Flashback per

1

riportare i dati storici o annullare le modiche errate.

2.1.1.1 Oracle Flashback Query Utilizzare questa funzione per recuperare i dati in un tempo del passato specicato con la clausola as of del comando select.

2.1.1.2 Oracle Flashback Version Query Utilizzare questa funzione per recuperare i metadati e i dati storici in un intervallo di tempo specico.

I metadati di ogni riga includono l'ora di inizio e di ne, il tipo di

operazione di modica e l'identità della transazione che ha creato la riga. Per creare una Oracle Flashback Version Query utilizzare la clausola versions between del comando

select.

possibile anche utilizzare queste funzioni in modo interattivo come un utente di database o amministratore. 26


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

2.1.1.3 Oracle Flashback Transaction Query Utilizzare questa funzione per recuperare i metadati e i dati storici di una transazione o per tutte le transazioni in un dato intervallo di tempo. Per eseguire Flashback Transaction Query interrogare la vista statica flashback_transaction_query del dizionario. In genere, si utilizza Oracle Flashback Transaction Query in combinazione con una Oracle Flashback Version Query che fornisce gli ID di transazione per le righe di interesse.

2.1.1.4 DBMS_FLASHBACK Package Utilizzare questa funzione per impostare l'orologio interno del database solo per la propria sessione ad un momento nel passato, in modo che sia possibile esaminare i dati validi in quel momento.

2.1.1.5 Flashback Transaction Utilizzare Flashback Transaction per eseguire il rollback di una transazione e le sue transazioni dipendenti, o meglio le operazioni implicite della transazione principale come quelle originate dalla clausola on delete cascade su un constraint di foreign key, mentre il database rimane online. Questa operazione di recupero utilizza dati undo per creare ed eseguire le relative transazioni di compensazione che restituiscono i dati interessati al loro stato originale. Flashback Transaction fa parte del pacchetto DBMS_FLASHBACK .

2.1.1.6 Flashback Data Archive (Oracle Total Recall) Utilizzare Flashback Data Archive per monitorare automaticamente e archiviare sia le query regolari che le Oracle Flashback Query, garantendo l'accesso a livello di SQL per le versioni degli oggetti del database senza rischiare di ottenere un errore di snapshot

27


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

too old. Quando si attiva tale funzione Oracle richiede di specicare un tempo o una classe a cui è associato un tempo, per automatizzare la pulizia degli undo di quella tabella

2.1.2

FunzionalitĂ  di amministrazione di database

Le seguenti funzionalitĂ  sono principalmente usate per il recupero dei dati.

In genere

queste funzioni sono riservate agli amministratori di database.

2.1.2.1 Oracle Flashback Table Utilizzare questa funzione per ripristinare una tabella allo stato in cui era in un momento precedente. Ăˆ possibile ripristinare una tabella mentre il database è online.

2.1.2.2 Oracle Flashback Drop Utilizzare questa funzione per recuperare una tabella droppata. Questa funzione inverte gli eetti di un comando drop table per la sola tabella, ma non per le sue entità deboli, come potrebbero essere gli indici e i trigger, per i quali si può operare la stessa funzione ma separatamente.

2.1.2.3 Oracle Flashback Database Utilizzare questa funzione per far tornare rapidamente il database ad un punto precedente nel tempo, restaurando tutti i cambiamenti che hanno avuto luogo da allora.

28


CAPITOLO 2.

2.2

ORACLE FLASHBACK TECHNOLOGY

Requisiti per utilizzare la tecnologia Oracle Flashback

2.2.1

Automatic undo management

Per poter utilizzare la funzione Flashback bisogna aver attiva l'automatic undo management. [SIT-05] Per vericare se l'AUM risulta attivo possiamo dare il comando:

show parameter undo

NAME

TYPE

VALUE

undo_management

string

AUTO

undo_retention

integer

900

undo_tablespace

string

UNDOTBS1

 Il parametro undo_management ci mostra che l'AUM è attivo e viene usato il tablespace undotbs1. L'undo_retention ci dice per quanti secondi vengono garantiti gli undo prima di poter essere sovrascritti. Per utilizzare la funzionalità Oracle Flashback Transaction Query l'amministratore deve aumentare i dati di logging tramite il comando:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Per la Flashback Transaction invece l'amministratore deve attivare l'archivelog mentre il database è montato ma non aperto:

29


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

ALTER DATABASE ARCHIVELOG;

ed eseguire dopo l'apertura questi ulteriori comandi:

ALTER SYSTEM ARCHIVE LOG CURRENT; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

se vogliamo che vengano registrate anche le dipendenze delle foreign key dobbiamo usare il comando:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (FOREIGN KEY) COLUMNS;

2.2.2

Permessi

Per utilizzare la Flashback è necessario che l'amministratore dia agli utenti che devono usarla particolari privilegi. Negli esempi riportati in questa tesi si userà l'utente scott e la sua tabella emp, quindi si mostrerà la concessione dei privilegi usando come schema scott.

2.2.2.1 Oracle Flashback Query Bisogna dare il privilegio flashback e select all'utente che deve usare la Oracle Flashback Query indicando l'oggetto o gli oggetti su cui può operare:

GRANT FLASHBACK ANY TABLE to scott;

Il privilegio select invece, in questo caso, non serve perché scott opererà su un oggetto (emp) di sua proprietà.

30


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

2.2.2.2 Oracle Flashback Version Query Come prima cosa dobbiamo dare il privilegio flashback:

GRANT FLASHBACK ANY TABLE to scott;

Inoltre l'utente deve possedere il privilegio di select su tutte le transazioni:

GRANT SELECT ANY TRANSACTION to scott;

Se poi vogliamo che l'utente sia in grado di eseguire l'undo della transazione esso dovrà possedere i privilegi di select, update, delete e insert sugli oggetti coinvolti nella transazione.

2.2.2.3 DBMS_FLASHBACK Package Essendo un package l'utente deve avere il privilegio di eseguire il package dbms_flashback:

GRANT EXECUTE ON DBMS_FLASHBACK to scott;

2.3

Utilizzo delle funzioni Flashback per lo sviluppo di applicazioni

Come già detto in queste dimostrazioni ci connetteremo al database come scott e lavoreremo sulla tabella emp di cui scott è proprietario. La tabella emp è cosi composta:

31


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

EMPNO

ENAME

JOB

MGR

HIREDATE

SAL

7369

SMITH

CLERK

7902

17-dic-80

800

7499

ALLEN

SALESMAN

7698

20-feb-81

1600

300

30

7521

WARD

SALESMAN

7698

22-feb-81

1250

500

30

7566

JONES

MANAGER

7839

02-apr-81

2975

7654

MARTIN

SALESMAN

7698

28-set-81

1250

7698

BLAKE

MANAGER

7839

01-mag-81

2850

30

7782

CLARK

MANAGER

7839

09-giu-81

2450

10

7788

SCOTT

ANALYST

7566

19-apr-87

3000

20

7839

KING

PRESIDENT

17-nov-81

5000

10

7844

TURNER

SALESMAN

7698

08-set-81

1500

7876

ADAMS

CLERK

7788

23-mag-87

1100

20

7900

JAMES

CLERK

7698

03-dic-81

950

30

7902

FORD

ANALYST

7566

03-dic-81

3000

20

7934

MILLER

CLERK

7782

23-gen-82

1300

10

2.3.1

COMM

DEPTNO 20

20 1400

0

30

30

Premessa

Nelle funzionalità di Flashback per il riferimento al tempo nel passato è possibile usare il timestamp o l'SCN (system change number). Oracle usa internamente l'SCN che mappa il timestamp ad una granularità di 3 secondi. Per conoscere il timestamp è suciente eseguire la seguente query:

SELECT systimestamp AS timestamp FROM dual;

L'SCN invece è un'informazione riservata al DBA, quindi se autenticati come scott non ci è concesso ricavarla direttamente, ma possiamo trasformare il timestamp in SCN tramite la funzione: 32


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

TIMESTAMP_TO_SCN(timestamp)

E quindi diamo l'istruzione:

SELECT TIMESTAMP_TO_SCN(systimestamp) AS scn FROM dual;

Esiste ovviamente la funzione inversa per ricavare il timestamp dall' SCN:

SCN_TO_TIMESTAMP(scn_number)

2.3.2

Oracle Flashback Query

Vediamo il salario di smith:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’ ;

ENAME

SAL

SMITH

800

Dobbiamo ora conoscere l'informazione sul timestamp e l'SCN:

SELECT systimestamp as timestamp, TIMESTAMP_TO_SCN(systimestamp ) AS scn FROM dual;

TIMESTAMP

SCN

23-GEN-14 15:55:46,368000000 +01:00

1272985

Modichiamo il salario di smith:

UPDATE emp SET sal = 500 WHERE ename = ’SMITH’ ; COMMIT; 33


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

E vediamo che infatti ora è 500:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’ ;

ENAME

SAL

SMITH

500

Per conoscere il salario che aveva smith in un determinato momento del passato (prima dell'update e quindi in questo caso alle 15.54 dello stesso giorno della modica) basta dare il comando:

SELECT ename, sal FROM emp AS OF TIMESTAMP TO_TIMESTAMP (’2014-01-23 15:54:00’, ’YYYY-MM-DD HH24:MI:SS’) WHERE ename = ’SMITH’;

oppure:

SELECT ename,sal FROM emp AS OF SCN 1272985 WHERE ename =’SMITH ’;

ENAME

SAL

SMITH

800

che infatti ci mostra 800 come ci si aspettava.

2.3.3

Oracle Flashback Version Query

Come prima vediamo il valore del salario di smith:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’

34


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

ENAME

SAL

SMITH

800

Dobbiamo ora conoscere l'informazione sul timestamp e l'SCN prima delle modiche:

SELECT systimestamp AS timestamp, TIMESTAMP_TO_SCN(systimestamp ) AS scn FROM dual;

TIMESTAMP

SCN

23-GEN-14 16:23:02,070000000 +01:00

1275513

Modichiamo il salario di smith prima a 100 poi a 200:

UPDATE emp SET sal = 100 WHERE ename = ’SMITH’ ; COMMIT; UPDATE emp SET sal = 200 WHERE ename = ’SMITH’ ; COMMIT;

Dobbiamo ora conoscere l'informazione sul timestamp e l'SCN dopo le modiche:

SELECT systimestamp AS timestamp, TIMESTAMP_TO_SCN(systimestamp ) AS scn FROM dual;

TIMESTAMP

SCN

23-GEN-14 16:23:47,355000000 +01:00

1275558

Ripristiniamo il salario di smith col valore 800:

UPDATE emp SET sal = 800 WHERE ename = ’SMITH’ ; COMMIT;

Adesso vogliamo conoscere i cambiamenti avvenuti tra i due momenti passati: 35


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

SELECT ename, sal, versions_startscn, versions_starttime, versions_endscn, versions_endtime, versions_xid, versions_operation as op FROM emp VERSIONS BETWEEN SCN 1275513 AND 1275558 WHERE ename = ’SMITH’;

oppure:

SELECT ename, sal, versions_startscn, versions_starttime, versions_endscn, versions_endtime, versions_xid, versions_operation as op FROM emp VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP(’2014-01-23 16:23:02’,’YYYY-MM-DD HH24:MI:SS’) AND TO_TIMESTAMP(’2014-01-23 16:23:47’,’YYYY-MM-DD HH24:MI: SS’) WHERE ename = ’SMITH’;

ENAME

SMITH

200

SMITH

100

SMITH

VERSIONS_STARTSCN

VERSIONS_STARTTIME

VERSIONS_ENDSCN

VERSIONS_ENDTIME

1275556

23-GEN-14 16:23:38,000000000

SAL

1275544

23-GEN-14 16:23:28,000000000

1275556

23-GEN-14 16:23:38,000000000

1275544

23-GEN-14 16:23:28,000000000

VERSIONS_XID

OP

200020089030000

U

05001400AD030000

U

800

Le informazioni che abbiamo sono:

ˆ

SAL: valore dell'attributo sal dopo aver eseguito la transazione

ˆ

VERSIONS_STARTSCN:

SCN di quando quella tupla ha iniziato ad essere

valida 36


CAPITOLO 2.

ˆ

VERSIONS_STARTTIME:

ORACLE FLASHBACK TECHNOLOGY

timestamp di quando quella tupla ha iniziato ad

essere valida

ˆ

VERSIONS_ENDSCN: SCN di quando quella tupla ha smesso di essere valida

ˆ

VERSIONS_ENDTIME: timestamp di quando quella tupla ha smesso di essere valida

ˆ

VERSIONS_XID: XID della transazione

ˆ

VERSIONS_OPERATION: tipo di operazione della transazione (Update, Delete, Insert)

2.3.4

Oracle Flashback Transaction Query

Vediamo il valore del salario di smith:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’;

ENAME

SAL

SMITH

800

Conosciamo l'informazione sul timestamp e sull'SCN prima delle modiche:

SELECT systimestamp AS timestamp, TIMESTAMP_TO_SCN(systimestamp ) AS scn FROM dual;

TIMESTAMP

SCN

23-GEN-14 17:03:19,663000000 +01:00

1278765

Mettiamo 100 come valore del salario di smith e poi cancelliamo tutta la tupla:

37


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

UPDATE emp SET sal = 100 WHERE ename = ’SMITH’ ; COMMIT; DELETE FROM emp WHERE ename = ’SMITH’; COMMIT; Conosciamo l'informazione sul timestamp e sull'SCN dopo le modiche:

SELECT systimestamp AS timestamp, TIMESTAMP_TO_SCN(systimestamp ) AS scn FROM dual;

TIMESTAMP

SCN

23-GEN-14 17:06:09,325000000 +01:00

1278903

Usiamo ora la Flashback Transaction Query:

SELECT xid, operation, start_scn, commit_scn, logon_user, undo_sql FROM flashback_transaction_query WHERE xid IN ( SELECT versions_xid FROM emp VERSIONS BETWEEN SCN 1278765 AND 1278903);

XID

OPERATION

START_SCN

COMMIT_SCN

LOGON_USER

UNDO_SQL 05000300B0030000

DELETE

1278845

1278848

SCOTT

insert into "SCOTT"."EMP"("EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","DEPTNO" values ('7369','SMITH','CLERK','7902',TO_DATE('17-DIC-80', 'DD-MON-RR'),'100',NULL,'20'); 05000300B0030000

BEGIN

1278845

1278848

SCOTT

05000200AF030000

UPDATE

1278804

1278805

SCOTT

update "SCOTT"."EMP" set "SAL" = '800' where ROWID = 'AAAR3sAAEAAAACTAAA'; 05000200AF030000

BEGIN

1278804

1278805

38

SCOTT


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

Vediamo ora le informazioni che abbiamo ottenuto:

ˆ

XID: ID della transazione

ˆ

OPERATION: tipo della transazione

ˆ

START_SCN: SCN di quando è stata data l'istruzione

ˆ

COMMIT_SCN: SCN di quando è stata committata

ˆ

LOGON_USER: utente che ha eettuato la transazione

ˆ

UNDO_SQL: istruzione contraria per annullare l'eetto della transazione data

Per annullare usiamo le modiche suggerite dagli undo_sql, nella sequenza indicata :

INSERT INTO "SCOTT"."EMP"("EMPNO","ENAME","JOB","MGR","HIREDATE ","SAL","COMM","DEPTNO") VALUES(’7369’,’SMITH’,’CLERK ’,’7902’,TO_DATE(’17-DIC-80’, ’DD-MON-RR’),’100’,NULL,’20’); UPDATE "SCOTT"."EMP" SET "SAL" = ’800’ WHERE ROWID = ’ AAAR3sAAEAAAACTAAA’; COMMIT;

2.3.5

DBMS_FLASHBACK Package

Vediamo il valore dei salari di smith e di allen:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’ OR ename = ’ ALLEN’;

ENAME

SAL

SMITH

800

ALLEN

1600

39


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

Conosciamo l'informazione sul timestamp e sull'SCN prima delle modiche:

SELECT systimestamp AS timestamp, TIMESTAMP_TO_SCN(systimestamp ) AS scn FROM dual;

TIMESTAMP

SCN

25-GEN-14 14:49:56,985000000 +01:00

1342458

 Aggiorniamo il salario di allen a 100 e cancelliamo la tupla di smith:

UPDATE emp SET sal = 100 WHERE ename = ’ALLEN’; DELETE emp WHERE ename = ’SMITH’; COMMIT;

Verichiamo che le modiche siano state eettuate:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’ OR ename = ’ ALLEN’;

ENAME

SAL

ALLEN

100

Ora usiamo il package per interrogare il database nello stato in cui si trovava in un dato momento del passato:

exec DBMS_FLASHBACK.ENABLE_AT_SYSTEM_CHANGE_NUMBER (1342458);

oppure

exec DBMS_FLASHBACK.ENABLE_AT_TIME (TO_TIMESTAMP(’2014-01-25 14:49:00’,’YYYY-MM-DD HH24:MI:SS’)); 40


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

D'ora in poi ogni query che facciamo ci restituirà le informazioni presenti nel database in quel determinato momento:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’ or ename = ’ ALLEN’;

ENAME

SAL

SMITH

800

ALLEN

1600

Disabilitiamo ora questa funzione:

exec DBMS_FLASHBACK.DISABLE;

Per avere la conferma che siamo tornati al momento corrente diamo:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’ or ename = ’ ALLEN’;

2.3.6

ENAME

SAL

ALLEN

100

Flashback Transaction

Creiamo da scott due tabelle, test1 con una sola colonna chiave primaria e referenziata dall'unica colonna della tabella test2.

create table test1( test1col varchar2(3) primary key ); create table test2( test2col varchar2(3) CONSTRAINT fk REFERENCES test1(test1col) on delete cascade ); Popoliamo con tre transazioni la tabella test1: 41


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

INSERT INTO test1 VALUES (’ABC’); INSERT INTO test1 VALUES (’DEF’); COMMIT; INSERT INTO test1 VALUES (’GHI’); INSERT INTO test1 VALUES (’JKL’); COMMIT; INSERT INTO test1 VALUES (’MNO’); COMMIT;

Popoliamo con un'unica transazione la tabella test2:

INSERT INTO test2 VALUES (’ABC’); INSERT INTO test2 VALUES (’DEF’); INSERT INTO test2 VALUES (’GHI’); INSERT INTO test2 VALUES (’JKL’); INSERT INTO test2 VALUES (’MNO’); COMMIT;

Osserviamo da sys le transazioni avvenute sulla tabella scott.test1:

SELECT versions_xid, versions_startscn, versions_endscn, versions_operation, test1col FROM scott.test1 VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE;

42


CAPITOLO 2.

VERSIONS_XID

VERSIONS_STARTSCN

0400040014020000

ORACLE FLASHBACK TECHNOLOGY

VERSIONS_ENDSCN

V

TEST1COL

952960

I

MNO

0700070027020000

952948

I

JKL

0700070027020000

952948

I

GHI

06000B00AA020000

952946

I

DEF

06000B00AA020000

952946

I

ABC

Utilizziamo la funzione dbms_flashback.transaction_backout per eliminare le modiche provocate dalla seconda transazione (inserimento dei valori GHI e JKL):

DECLARE xa sys.xid_array := sys.xid_array(); BEGIN xa.extend; dbms_output.put_line(xa.last); xa(1) := ’0700070027020000’; dbms_flashback.transaction_backout(1, xa); END;

Vediamo i valori correnti nelle due tabelle:

SELECT * FROM scott.test1;

TEST1COL ABC DEF MNO 

SELECT * FROM scott.test2;

43


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

TEST2COL ABC DEF MNO

Come ci si aspettava l'annullamento della transazione d'inserimento dei valori GHI e JKL sulla tabella test1 ha provocato la cancellazione dei valori della tabella test2 che referenziavano tali valori.

2.3.7

Flashback Data Archive

La funzionalitĂ  Flashback Data Archive consente di tenere traccia delle modiche apportate a tabelle in modo continuativo nel passato recente della loro vita. Per prima cosa da sysdba creiamo un archivio Flashback con il seguente comando:

CREATE FLASHBACK ARCHIVE fla1 TABLESPACE EXAMPLE RETENTION 1 DAY; ALTER FLASHBACK ARCHIVE fla1 SET DEFAULT;

Avremmo anche potuto scrivere insieme i due comandi in questo modo:

CREATE FLASHBACK ARCHIVE DEFAULT fla1 TABLESPACE EXAMPLE RETENTION 1 DAY;

Ora dobbiamo dare il privilegio di usare l'archivio Flashback a scott:

GRANT FLASHBACK ARCHIVE on fla1 TO scott;

Avremmo anche potuto dare all'inizio il privilegio:

GRANT FLASHBACK ARCHIVE ADMINISTER TO scott; 44


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

per permettere a scott di creare e amministrare gli archivi Flashback. Ora da scott creiamo la tabella:

CREATE TABLE employee (EMPNO NUMBER(4) NOT NULL, ENAME VARCHAR2 (10), JOB VARCHAR2(9), MGR NUMBER(4)) FLASHBACK ARCHIVE;

D'ora in poi sulla tabella creata sarà possibile eseguire query Flashback per vedere i dati contenuti no al giorno prima (RETENTION: 1 day). Su questa tabella è inoltre possibile eseguire alcune istruzioni ddl, mantenendo la continuità della funzionalità associata della Flashback Archive, come ad esempio:

ˆ

Aggiungere, togliere, rinominare e modicare le colonne

ˆ

Aggiungere, togliere, rinominare i vincoli

ˆ

Cancellare o troncare una partizione o una sottopartizione della tabella

ˆ

Troncare la tabella

ˆ

Rinominare la tabella

2.4

Utilizzo delle funzioni Flashback per gli amministratori del database

2.4.1

Recycle bin

Il recycle bin è una tabella del dizionario dati che contiene informazioni riguardo alle tabelle droppate e agli oggetti ad esse collegate.

45


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

Ogni utente possiede il suo recycle bin che contiene le tabelle che esso ha cancellato, mentre solo l'amministratore ha il privilegio di vedere globalmente gli oggetti cancellati da ogni utente. È possibile abilitare (di default è attivo) il recycle bin con le seguenti istruzioni:

ALTER SESSION SET recyclebin = ON;

ALTER SYSTEM SET recyclebin = ON SCOPE = SPFILE;

Oppure disattivarlo con le istruzioni opposte

ALTER SESSION SET recyclebin = OFF;

ALTER SYSTEM SET recyclebin = OFF SCOPE = SPFILE;

Per vedere il proprio recycle bin dare l'istruzione da scott:

SELECT * FROM RECYCLEBIN; oppure da sys:

SELECT * FROM DBA_RECYCLEBIN; Tra gli attributi principali del recycle bin citiamo:

ˆ

OBJECT_NAME: nome univoco dato da Oracle all'oggetto nel recycle bin

ˆ

ORIGINAL_NAME: nome originario dell'oggetto

ˆ

OPERATION: operazione che ha causato lo spostamento dell'oggetto nel cestino

ˆ

TYPE: tipo di oggetto

ˆ

TS_NAME: nome del tablespace in cui si trovava l'oggetto 46


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

ˆ

CREATETIME: timestamp di quando è stato creato l'oggetto

ˆ

DROPTIME : timestamp di quando è stato cancellato l'oggetto

ˆ

DROPSCN: SNC di quando è stato cancellato l'oggetto

ˆ

CAN_UNDROP: stringa che indica se l'oggetto può essere ripristinato

ˆ

CAN_PURGE

: stringa che indica se l'oggetto può essere eliminato denitiva-

mente

ˆ

SPACE : spazio occupato dall'oggetto

Cancelliamo da scott la tabella emp:

DROP TABLE emp; Ora osserviamo le informazioni del recycle bin riguardo alla tabella emp appena eliminata:

SELECT OBJECT_NAME, ORIGINAL_NAME, OPERATION, TYPE, CREATETIME DROPTIME DROPSCN CAN_UNDROP CAN_PURGE FROM RECYCLEBIN WHERE ORIGINAL_NAME=’EMP’;

OBJECT_NAME CREATETIME

DROPTIME

BIN$6MdVJuC/STyQhjllkmq6HA==$0 2010-03-30:11:06:23

2014-01-25:17:13:12

ORIGINAL_NAME

OPERATION

TYPE

DROPSCN

CAN_UNDROP

CAN_PURGE

EMP

DROP

TABLE

1357681

YES

YES

2.4.1.1 Interrogare gli oggetti del recycle bin È possibile interrogare una tabella anche se essa è stata cancellata e si trova nel cestino tramite la query:

SELECT * FROM "BIN$6MdVJuC/STyQhjllkmq6HA==$0"; 47


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

che ritorna lo stesso risultato della query

SELECT * FROM emp; se non avessimo però fatto il drop di emp.

2.4.1.2 Cancellare gli oggetti del recycle bin Per cancellare denitivamente un oggetto dal recycle bin bisogna dare l'istruzione:

PURGE TABLE " BIN$6MdVJuC/STyQhjllkmq6HA==$0";

oppure

PURGE TABLE "EMP";

o ancora se si vuole svuotare il recycle bin dagli oggetti che si trovavano in un determinato tablespace :

PURGE TABLESPACE users;

Inne per svuotare completamente il recycle bin:

PURGE RECYCLEBIN;

2.4.2

Oracle Flashback Drop

Per prima cosa cancelliamo la tabella emp con il seguente comando:

DROP TABLE emp;

Osserviamo che la tabella è stata inserita nel recycle bin

SHOW RECYCLEBIN 48


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

ORIGINAL NAME

RECYCLEBIN NAME

OBJECT TYPE

DROP TIME

EMP

BIN$9GnQ4c9fgzjgQAB/AQAUww==$0

TABLE

2014-03-12:17:00:51

 Anche se nel cestino, è ancora possibile interrogare la tabella emp:

SELECT ename, sal FROM "BIN$9GnQ4c9fgzjgQAB/AQAUww==$0" WHERE ename=’SMITH’;

ENAME

SAL

SMITH

800

Ripristiniamola con il comando:

FLASHBACK TABLE "BIN$9GnQ4c9fgzjgQAB/AQAUww==$0" TO BEFORE DROP ;

oppure

FLASHBACK TABLE scott.emp TO BEFORE DROP;

Verichiamo ora il ripristino della tabella:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’

2.4.3

ENAME

SAL

SMITH

800

Oracle Flashback Table

Se invece un utente modica una tabella, l'amministratore del database può ripristinare i dati in essa contenuti nell'istante di tempo passato che preferisce. Conosciamo l'informazione sul timestamp e sull'SCN: 49


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

SELECT systimestamp AS timestamp, TIMESTAMP_TO_SCN(systimestamp ) AS scn FROM dual;

TIMESTAMP

SCN

25-GEN-14 17:59:31,760000000 +01:00

1360026

L'utente scott fa le seguenti modiche alla tabella emp:

UPDATE emp SET sal = 100 WHERE ename = ’ALLEN’ ; DELETE emp WHERE ename = ’SMITH’ ; COMMIT;

Verichiamo che le modiche siano state eettuate:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’ OR ename = ’ ALLEN’ ;

ENAME

SAL

ALLEN

100

Dopo aver abilitato l'opzione row movement con il comando

ALTER TABLE emp ENABLE ROW MOVEMENT

l'amministratore può annullare le modiche fatte da scott e ripristinare la tabella con la seguente istruzione:

FLASHBACK TABLE scott.emp TO SCN 1360026;

oppure

50


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

FLASHBACK TABLE scott.emp TO TIMESTAMP TO_TIMESTAMP(’2014-01-25 17:59:00’, ’YYYY-MM-DD HH24:MI:SS’);

Controlliamo che i valori della tabella siano stati ripristinati:

SELECT ename, sal FROM scott.emp WHERE ename = ’SMITH’ OR ename = ’ALLEN’ ;

2.4.4

ENAME

SAL

SMITH

800

ALLEN

1600

Oracle Flashback Database

Ora vediamo come ripristinare in un colpo solo tutto il database. Da utente sys diamo i seguenti comandi:

STARTUP MOUNT EXCLUSIVE; ALTER DATABASE ARCHIVELOG; ALTER DATABASE FLASHBACK ON; ALTER DATABASE OPEN; ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=2880; Se volessimo dare a scott la possibilità di creare punti di ripristino, allora dobbiamo dargli il privilegio Flashback:

GRANT FLASHBACK ANY TABLE TO scott; Ora connettiamoci come scott e modichiamo la tabella emp come abbiamo fatto negli esempi precedenti. 51


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

Conosciamo l'informazione sul timestamp e sull'SCN prima delle modiche:

SELECT systimestamp AS timestamp, TIMESTAMP_TO_SCN(systimestamp ) AS scn FROM dual;

TIMESTAMP

SCN

25-GEN-14 14:49:56,985000000 +01:00

1342458

e creiamo anche un punto di ripristino:

CREATE RESTORE POINT bef_update; Vediamo il salario di smith:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’;

ENAME

SAL

SMITH

800

Modichiamo il salario di smith:

UPDATE emp SET sal = 500 WHERE ename = ’SMITH’; COMMIT; E vediamo che infatti ora è 500:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’;

ENAME

SAL

SMITH

500

Ora proviamo a ripristinare il database a come era prima dell'update usando la Oracle Flashback Database. Da sys: 52


CAPITOLO 2.

ORACLE FLASHBACK TECHNOLOGY

SHUTDOWN IMMEDIATE; STARTUP MOUNT EXCLUSIVE;

FLASHBACK DATABASE TO SCN 1342458;

oppure

FLASHBACK DATABASE TO RESTORE POINT bef_update;

oppure

FLASHBACK DATABASE TO TIMESTAMP to_timestamp(’2014-01-25 14:49:56’, ’YYYY-MM-DD HH24:MI:SS’);

ALTER DATABASE OPEN RESETLOGS;

Verichiamo che il database sia tornato a come era prima dell'update connettendoci come

scott e dando l'istruzione:

SELECT ename, sal FROM emp WHERE ename = ’SMITH’ ;

ENAME

SAL

SMITH

800

53


Capitolo

3

PostgreSQL TimeTravel technology

Indice 3.1

Panoramica generale della tecnologia TimeTravel

. . . . . . .

3.1.1

File per l'installazione e la disinstallazione . . . . . . . . . . . . .

56

3.1.2

Le funzioni PL/pgSQL

56

3.1.3

L'applicazione php per la gestione della TimeTravel

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2

Installazione e disinstallazione della tecnologia TimeTravel

3.3

Utilizzo delle funzioni TimeTravel

3.4

55

3.3.1

Premessa

3.3.2

Attivazione

3.3.3

Transazioni sulla tabella

3.3.4

Tabella dei log delle transazioni

3.3.5

TimeTravel Query

3.3.6

TimeTravel Restore

3.3.7

Disattivazione

60

.

60

. . . . . . . . . . . . . . . .

61

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61 61 62

. . . . . . . . . . . . . . . . . .

62

. . . . . . . . . . . . . . . . . . . . . . . . . .

64

. . . . . . . . . . . . . . . . . . . . . . . . .

64

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

Utilizzo dell'applicazione PHP

. . . . . . . . . . . . . . . . . .

3.4.1

Installazione

3.4.2

Avvio

3.4.3

Transazioni sulla tabella

3.4.4

Uso della TimeTravel

3.4.5

Tabella dei log delle transazioni

3.4.6

TimeTravel Query

3.4.7

TimeTravel Restore

3.4.8

Disattivazione

65

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

. . . . . . . . . . . . . . . . . . . . . .

68

. . . . . . . . . . . . . . . . . . . . . . . .

69

. . . . . . . . . . . . . . . . . .

71

. . . . . . . . . . . . . . . . . . . . . . . . . .

71

. . . . . . . . . . . . . . . . . . . . . . . . .

73

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

Nel seguente capitolo descriverò il lavoro svolto per sviluppare una funzionalità simile alla Oracle FlashBack nell'RDBMS PostgreSQL, faranno seguito degli esempi. 54


CAPITOLO 3.

3.1

POSTGRESQL TIMETRAVEL TECHNOLOGY

Panoramica generale della tecnologia TimeTravel

La tecnologia sviluppata in PostgreSQL, qui chiamata TimeTravel per ricordare il nome dato ai primi tentativi della comunità sull'argomento, consiste in un insieme di funzioni PL/pgSQL [SIT-06] Tale linguaggio è stato scelto perché è l'unico linguaggio PL (Procedural Language) già installato di default in PostgreSQL, rendendo quindi più facile l'installazione della tecnologia TimeTravel anche a persone con bassa esperienza. Inoltre con PL/pgSQL si possono raggruppare un blocco di calcolo e una serie di query all'interno del server database, e avere quindi la potenza di un linguaggio procedurale e la facilità d'uso dell'SQL, ma con considerevole risparmio di overhead di comunicazione client/server. Altre caratteristiche sono:

ˆ

Canale diretto tra client e server.

ˆ

Preelaborazione dei dati a livello del server garantendo così che quanto ricevuto dal client sia solo quanto dallo stesso richiesto.

ˆ

Riutilizzo delle istruzioni su cui sia ancora disponibile il risultato del loro parsing.

Questo risulta in un incremento di prestazioni considerevole se confrontato con un'applicazione che non usa funzionalità embedded. Oltre alle funzioni necessarie per il funzionamento, che vedremo successivamente, sono stati creati un le per l'installazione e uno per la disinstallazione e un'applicazione PHP per controllare e gestire la tecnologia TimeTravel sulle tabelle del database.

55


CAPITOLO 3.

3.1.1

POSTGRESQL TIMETRAVEL TECHNOLOGY

File per l'installazione e la disinstallazione

3.1.1.1 Installazione Si esegue il le d'installazione, richiamato come opzione dall'utility PSQL, che eettua le seguenti operazioni:

ˆ

Creazione di uno schema chiamato tt che conterrĂ  tutti gli oggetti e le funzioni necessari al funzionamento della tecnologia TimeTravel.

ˆ

Creazione dentro lo schema tt della tabella tt_tables per tenere traccia delle tabelle del database che hanno la funzione TimeTravel attiva.

ˆ

Creazione di tutte le funzioni che compongono la tecnologia TimeTravel.

ˆ

Creazione di un event trigger per disattivare automaticamente la TimeTravel su una tabella che viene cancellata.

3.1.1.2 Disinstallazione Eseguendo invece il le di disinstallazione, sempre richiamato come opzione da PSQL, verranno eettuate le seguenti operazioni:

ˆ

Disattivazione della TimeTravel su tutte le tabelle sulle quali è attiva.

ˆ

Cancellazione dello schema tt.

3.1.2

Le funzioni PL/pgSQL

3.1.2.1 Attivazione Per poter utilizzare le funzionalitĂ  della TimeTravel su una tabella bisogna innanzitutto attivarla sulla tabella in questione. 56


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

Per fare ciò è suciente eseguire la seguente istruzione:

SELECT tt.on( schemaname, tablename); Oltre all'inserimento del nome della tabella in tt_tables abbiamo i seguenti eetti:

ˆ

Tutte le modiche eettuate sui dati della tabella vengono salvati nella tabella

tt.schemaname_tablename_log.

ˆ

Se la tabella non possiede una primary key viene aggiunta alla tabella stessa, quindi con una operazione invasiva, la colonna tt_rowid

Ăˆ possibile inoltre attivare la TimeTravel su tutte le tabelle di un singolo schema con il comando:

SELECT tt.on(schemaname);

oppure su tutte le tabelle utente del database con:

SELECT tt.on();

3.1.2.2 Disattivazione La disattivazione è l'operazione contraria all'attivazione e in questo caso i comandi per disattivare la TimeTravel su una tabella sono simili a quanto visto prima. Per disattivare la TimeTravel basterà usare il comando:

SELECT tt.off( schemaname, tablename); Oltre all'eliminazione del nome della tabella in tt_tables abbiamo i seguenti eetti:

ˆ

La tabella tt.schemaname_tablename_log viene cancellata e quindi non verrĂ  piĂš registrata nessuna transazione eettuata sulla tabella. 57


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

ˆ

La colonna tt_rowid, se esistente, verrà cancellata.

ˆ

Vengono cancellati eventuali oggetti creati per il funzionamento della TimeTravel.

È possibile inoltre disattivare la TimeTravel su tutte le tabelle di un singolo schema con:

SELECT tt.off(schemaname);

oppure su tutte le tabelle utente del database con:

SELECT tt.off();

3.1.2.3 Tabella dei log delle transazioni Questa tabella, creata nello schema tt durante l'attivazione della TimeTravel sulla tabella

schemaname.tablename con il nome schemaname_tablename_log , ha il compito di registrare tutte le transazioni avvenute. È usata per conoscere i metadati delle transazioni avvenute sulla tabella tablename dello schema schemaname. Infatti interrogandola con la seguente query:

SELECT values FROM tt.schemaname_tablenamelog [WHERE ...]

ci vengono restituite le seguenti informazioni:

ˆ

TT_MODE: tipo di operazione (insert/delete/update)

ˆ

TT_TUPLE: new se la tupla è stata aggiunta, old se invece è stata eliminata

ˆ

TT_TIME: timestamp di quando la transazione è avvenuta

ˆ

TT_USER: utente che ha eseguito la transazione 58


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

ˆ

TT_REDO: istruzione o blocco di istruzioni che hanno generato la transazione

ˆ

TT_UNDO: operazione contraria a quella della transazione

3.1.2.4 TimeTravel Query Utilizzata per recuperare i dati in un tempo del passato specicato . Per utilizzarla bisogna dare il comando:

SELECT tt.query(schemaname, tablename, timestamp)

che crea la tabella schemaname_tablename_past nello schema tt, uguale a come si trovava la tabella tablename dello schema schemaname al tempo scelto. Sarà quindi possibile interrogare la tabella schemaname_tablename_past per avere le informazioni desiderate:

SELECT values FROM tt.schemaname_tablename_past

3.1.2.5 TimeTravel Restore Usata per riportare una tabella a come si trovava in un determinato istante compreso da quando è stata attivata la TimeTravel no all'istante corrente. È possibile, una volta fatto il restore ad un tempo t1, richiamare la restore al tempo t2 precedente o successivo a t1 per vedere  passo per passo tutti i cambiamenti fatti sulla tabella. Se una tabella possiede vincoli di chiave esterna, questi saranno disabilitati e andranno riabilitati manualmente dopo il restore. Interrogando la tabella schemaname_tablename_

fk creata nello schema tt prima della disabilitazione dei vincoli di chiave esterna, sarà possibile conoscere le operazioni per riattivare tutti i vincoli disabilitati.

59


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

Per fare il restore di una tabella bisogna usare il comando:

SELECT tt.restore(schemaname, tablename, timestamp)

È possibile inoltre fare il restore su tutte le tabelle di un singolo schema con:

SELECT tt.restore(schemaname, timestamp);

oppure di tutte le tabelle del database con il comando:

SELECT tt.restore(timestamp);

3.1.3

L'applicazione php per la gestione della TimeTravel

È stata anche creata un'applicazione PHP da installare su server Apache per consentire a qualsiasi utente di visualizzare le tabelle su cui è attiva la TimeTravel e utilizzare le funzioni di tale tecnologia.

3.2

Installazione e disinstallazione della tecnologia TimeTravel

Per installare la tecnologia TimeTravel sul nostro database basterà lanciare dal terminale del proprio sistema operativo il comando:

psql -f install_tt.sql

Se invece volessimo disinstallarla il comando sarebbe:

psql -f uninstall_tt.sql

60


CAPITOLO 3.

3.3

POSTGRESQL TIMETRAVEL TECHNOLOGY

Utilizzo delle funzioni TimeTravel

Vediamo ora tramite esempi l'uso di tutte le funzioni presenti nella tecnologia TimeTravel.

3.3.1

Premessa

Andremo a lavorare su un database di nome postgres e ci connetteremo ad esso con utente postgres. Dentro questo database creiamo lo schema demo e dentro di esso la tabella dipendenti:

CREATE SCHEMA demo; CREATE TABLE demo.dipendenti ( id BIGSERIAL PRIMARY KEY, name TEXT, sal INTEGER );

3.3.2

Attivazione

Per prima cosa attiviamo la TimeTravel sulla tabella dipendenti con il comando:

SELECT tt.on(’demo’,’dipendenti’); Per vericare la corretta attivazione interroghiamo la tabella tt_tables:

SELECT * FROM tt.tt_tables;

SCHEMA_NAME

TABLE_NAME

demo

dipendenti

In più si nota la creazione della tabella dei log demo_dipendenti_log nello schema

tt. Si noti inne che alla tabella dipendenti non è stata aggiunta la colonna tt_rowid perché già presente la chiave primaria. 61


CAPITOLO 3.

3.3.3

POSTGRESQL TIMETRAVEL TECHNOLOGY

Transazioni sulla tabella

Ora che la TimeTravel è attiva facciamo delle transazioni sulla tabella, che verranno quindi salvate nella tabella dei log delle transazioni. Alle ore 15:13:34.805 del 01/03/2014 inseriamo tre dipendenti :

INSERT INTO demo.dipendenti (name, sal) VALUES ( ’Mario’, 2000) ; INSERT INTO demo.dipendenti (name, sal) VALUES ( ’Davide’, 1500); INSERT INTO demo.dipendenti (name, sal) VALUES ( ’Luca’, 1000);

Alle ore 15:18:37.998 del 01/03/2014 eliminiamo il dipendente con id 2 :

DELETE FROM demo.dipendenti WHERE id=2;

Alle ore 15:21:37.793 del 01/03/2014 modichiamo lo stipendio del dipendente con id 3:

UPDATE demo.dipendenti SET sal=500 WHERE id=3; Vediamo ora i dati correnti della tabella dipendenti con il comando:

SELECT * FROM demo.dipendenti;

3.3.4

ID

NAME

SAL

1

Mario

2000

3

Luca

500

Tabella dei log delle transazioni

Ora interroghiamo la tabella dei log delle transazioni per conoscere i metadati delle transazioni avvenute sulla tabella dipendenti: 62


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

SELECT * FROM tt.demo_dipendenti_log;

ID

NAME

SAL

TT_MODE

TT_TUPLE

TT_TIME

TT_USER

2014-03-01 15:13:34.805

postgres

TT_REDO TT_UNDO 1

Mario

2000

INSERT

NEW

insert into demo.dipendenti (name, sal) values ( 'Mario', 2000); insert into demo.dipendenti (name, sal) values ( 'Davide', 1500); insert into demo.dipendenti (name, sal) values ( 'Luca', 1000); DELETE FROM demo.dipendenti WHERE ( id = '1' AND name = 'Mario' AND sal = 2000 ); 2

Davide

1500

INSERT

NEW

2014-03-01 15:13:34.805

postgres

insert into demo.dipendenti (name, sal) values ( 'Mario', 2000); insert into demo.dipendenti (name, sal) values ( 'Davide', 1500); insert into demo.dipendenti (name, sal) values ( 'Luca', 1000); DELETE FROM demo.dipendenti WHERE ( id = '2' AND name = 'Davide' AND sal = 1500 ); 3

Luca

1000

INSERT

NEW

2014-03-01 15:13:34.805

postgres

insert into demo.dipendenti (name, sal) values ( 'Mario', 2000); insert into demo.dipendenti (name, sal) values ( 'Davide', 1500); insert into demo.dipendenti (name, sal) values ( 'Luca', 1000); DELETE FROM demo.dipendenti WHERE ( id = '3' AND name = 'Luca' AND sal = 1000 ); 2

Davide

1500

DELETE

OLD

2014-03-01 15:18:37.998

postgres

delete from demo.dipendenti where id=2; INSERT INTO demo.dipendenti( id , name , sal) VALUES( '2' , 'Davide' , 1500); 3

Luca

500

UPDATE

NEW

2014-03-01 15:21:37.793

postgres

update demo.dipendenti set sal=500 where id=3; UPDATE demo.dipendenti SET id = '3' , name = 'Luca' , sal = 1000 WHERE ( id = '3' AND name = 'Luca' AND sal = 500);

63


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

Dalla tabella possiamo osservare in ordine cronologico i metadati delle transazioni dal più vecchio al più recente.

3.3.5

TimeTravel Query

Vogliamo ora conoscere quali dati conteneva la tabella dipendenti prima del cambio di stipendio del dipendente con ID=3, ma dopo il licenziamento del dipendente con ID=2. Scegliamo quindi un tempo intermedio tra le due transazioni, come ad esempio 2014-03-01 15:20:00. Diamo il comando:

SELECT tt.query(’demo’,’dipendenti’,’2014-03-01 15:20:00’);

Questa istruzione provocherà la creazione della tabella tt.demo_dipendenti_past che contiene i dati della tabella dipendenti alle ore 15:20 del 01/03/2014. Interroghiamo la tabella appena creata con la seguente query:

SELECT * FROM tt.demo_dipendenti_past;

ID

NAME

SAL

1

Mario

2000

3

Luca

1000

Come ci aspettavamo luca ha il salario che aveva prima della transazione di update.

3.3.6

TimeTravel Restore

Vogliamo invece ora riportare la tabella dipendenti a come si trovava subito dopo l'assunzione dei tre dipendenti.

64


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

Scegliamo quindi un tempo intermedio tra l'ultimo insert e il delete:

2014-03-01

15:15:00. Diamo il comando:

SELECT tt.restore(’demo’,’dipendenti’,’2014-03-01 15:15:00’); Proviamo ora a vedere quali dati contiene la tabella dipendenti dopo il restore:

SELECT * FROM demo.dipendenti;

ID

NAME

SAL

1

Mario

2000

3

Luca

1000

2

Davide

1500

La tabella dipendenti è tornata proprio come era prima delle transazioni di delete e di update.

3.3.7

Disattivazione

Per disattivare la TimeTravel sulla tabella dipendenti basta usare il comando:

SELECT tt.off(’demo’,’dipendenti’);

3.4

3.4.1

Utilizzo dell'applicazione PHP

Installazione

Per poter usare l'applicazione php per prima cosa dobbiamo copiare la directory tt nella directory www di Apache, successivamente bisogna modicare il le tt/conf.php inserendo i seguenti parametri: 65


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

ˆ

myhost:

indirizzo dell'host

ˆ

myuser:

nome dell'utente col quale si vuole accedere

ˆ

mypsw:

password dell'utente myuser

ˆ

mydb:

3.4.2

nome del database al quale si vuole accedere

Avvio 1

Per avviare l'applicazione PHP basterà aprire il browser alla pagina http://localhost:8080/tt . In questo modo si aprirà la seguente pagina:

Qui possiamo notare i seguenti campi:

ˆ

Tabella:

nome della tabella del database

ˆ

Schema:

schema in cui si trova la tabella

1 in

questo caso il server Apache lavora sulla porta 8080, che è il valore di default 66


CAPITOLO 3.

ˆ

Mostra dati:

ˆ

TimeTravel attiva?:

ˆ

Attiva TimeTravel:

ˆ

Disattiva TimeTravel:

ˆ

Usa TimeTravel:

POSTGRESQL TIMETRAVEL TECHNOLOGY

pulsante per vedere i valori della tabella

informazione che ci dice se la TimeTravel è attiva o no

pulsante per attivare la TimeTravel

pulsante per disattivare la TimeTravel

pulsante per usare la TimeTravel sulla tabella

Inne è possibile scegliere di attivare o disattivare la TimeTravel su tutte le tabelle di uno schema o dell'intero database scegliendo il nome dello schema dal menù a tendina e selezionando rispettivamente il pulsante  attiva timetravel o  disattiva

timetravel . Gli ultimi due pulsanti sono disabilitati in quanto la TimeTravel non è momentaneamente attiva sulla tabella. Attiviamo la TimeTravel sulla tabella dipendenti selezionando il pulsante  attiva ti-

metravel :

67


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

Ora sono presenti i pulsanti  disattiva timetravel e  usa timetravel mentre è stato disabilitato il pulsante  attiva timetravel .

3.4.3

Transazioni sulla tabella

Ora che la TimeTravel è attiva utilizzando PSQL facciamo delle transazione sulla tabella identiche a quelle fatte nell'esempio precedente. Alle ore 15:13:34.805 del 01/03/2014 inseriamo tre dipendenti :

INSERT INTO demo.dipendenti (name, sal) VALUES ( ’Mario’, 2000) ; INSERT INTO demo.dipendenti (name, sal) VALUES ( ’Davide’, 1500); INSERT INTO demo.dipendenti (name, sal) VALUES ( ’Luca’, 1000);

Alle ore 15:18:37.998 del 01/03/2014 eliminiamo il dipendente con ID 2:

DELETE FROM demo.dipendenti WHERE id=2;

Alle ore 15:21:37.793 del 01/03/2014 modichiamo lo stipendio del dipendente con ID 3:

UPDATE demo.dipendenti SET sal=500 WHERE id=3

Controlliamo che le modiche siano state eettuate selezionando il pulsante  guarda :

68


CAPITOLO 3.

3.4.4

POSTGRESQL TIMETRAVEL TECHNOLOGY

Uso della TimeTravel

Per usare le funzionalità TimeTravel sulla tabella dipendenti basterà selezionare il pulsante usa, che ci porterà in questa pagina PHP:

69


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

Questa pagina ci mostra sulla destra i valori contenuti nella tabella dipendenti mentre sulla sinistra troviamo i seguenti pulsanti:

ˆ

MOSTRA VALORI CORRENTI: per visualizzare i valori contenuti nella tabella nell'istante corrente

ˆ

MOSTRA LOG DELLE TRANSIZIONE:

per visualizzare tutti i metadati

delle transazioni avvenute sulla tabella dipendenti

ˆ

MOSTRA VALORI DEL PASSATO:

per usare la TimeTravel Query sulla

tabella dipendenti

ˆ

RIPORTA A VALORI DEL PASSATO: per usare la TimeTravel Restore sulla tabella dipendenti

ˆ

DISATTIVA TIMETRAVEL: per disattivare la TimeTravel sulla tabella dipendenti e tornare alla pagina precedente

70


CAPITOLO 3.

ˆ

POSTGRESQL TIMETRAVEL TECHNOLOGY

TORNA: per tornare alla pagina precedente

3.4.5

Tabella dei log delle transazioni

Selezionando il pulsante  MOSTRA LOG DELLE TRANSAZIONI potremo vedere la tabella dei log delle transizioni come mostrato dalla seguente immagine:

Si possono notare infatti, dalla più vecchia alla più recente, tutte le transazioni avvenute sulla tabella dipendenti.

3.4.6

TimeTravel Query

Per utilizzare la TimeTravel Query, invece, bisogna selezionare il pulsante  MOSTRA

VALORI DEL PASSATO . Dopo il primo click il pulsante ci consentirà di inserire la data e l'ora alle dell'istante di tempo in cui vogliamo ci vengano mostrati i valori della tabella:

71


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

Inserendo le ore 15:20 del 01/03/2014 ( tra il delete e l'update) e cliccando sul pulsante

ok, ci verrĂ  mostrata la tabella dipendenti coi valori che conteneva in quell'istante:

Possiamo notare che il dipendente luca ha come salario il valore 1000 e non 500, valore

72


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

modicato dalla transazione update.

3.4.7

TimeTravel Restore

Proviamo ora a riportare la tabella dipendenti a come si trovava nell'istante dopo le tre transazioni di commit, ma prima di quella di delete. Utilizziamo quindi la funzione TimeTravel restore selezionando il pulsante  RIPORTA A

VALORI DEL PASSATO. Dopo di che, anche in questo caso sarĂ  possibile inserire data e ora dell'istante desiderato:

Inserendo le ore 15:15 del 01/03/2014 ( tra il delete e l'update) e cliccando sul pulsante

ok, nella tabella dipendenti verranno ripristinati i valori che conteneva in quell'istante:

73


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

Notiamo infatti che sono presenti tutti e tre i dipendenti e che luca ha il salario assegnato in fase di inserimento.

3.4.8

Disattivazione

Disattiviamo la TimeTravel direttamente dal pulsante  disattiva timetravel o tornando alla pagina principale e da li usando il pulsante  disattiva corrispondente alla tabella dipendenti. In entrambi i casi avremo la medesima situazione nale:

74


CAPITOLO 3.

POSTGRESQL TIMETRAVEL TECHNOLOGY

75


Conclusioni

Il mio lavoro è consistito nella realizzazione di una tecnologia che permettesse di rimediare a eventuali errori umani nell'RDBMS PostgreSQL. Grazie alla TimeTravel, infatti, l'utente è ora in grado di visualizzare lo stato delle tabelle in un qualsiasi momento del passato e ripristinarle se necessario.

In particolare, grazie alla funzione TimeTravel Query, egli

è in grado di visualizzare qualsiasi dato in qualsiasi istante. Basta infatti solo conoscere il nome della tabella e il relativo schema di appartenenza per visualizzare tutti i dati contenuti in essa nel momento scelto. Tramite invece la TimeTravel Restore è possibile far tornare una tabella, sempre conoscendo solo il nome e lo schema di appartenenza, allo stato in cui si trovava nell'istante desiderato. È anche possibile usare la TimeTravel solo per conoscere tutte le transazioni avvenute sulla tabella interrogando la rispettiva tabella dei log delle transazioni. La tecnologia TimeTravel è attivabile su una singola tabella, su tutte le tabelle di uno schema oppure su tutte le tabelle utente del database a discrezione dell'utente stesso. Tutte queste funzionalità sono state rese utilizzabili in maniera più user friendly grazie alla creazione dell'applicazione PHP. Durante lo sviluppo della tecnologia TimeTravel, la gestione delle chiavi esterne ha costituito il maggior problema per il corretto funzionamento della Restore. Infatti l'uso di tale funzione non garantiva il rispetto del vincolo di referenziabilità sia diretto che indiretto.

76


CONCLUSIONI

Per questo motivo si è scelto di disattivare ogni vincolo di chiave esterna prima dell'utilizzo della funzione Restore. Sarà poi compito dell'utente ricreare tali vincoli vericando il rispetto di questi ultimi. Un'altra dicoltà riscontrata, ma di minore entità, ha riguardato le tabelle che non avevano il vincolo di chiave primaria. Il problema era dovuto all'incapacità di distinguere in modo univoco le tuple durante l'applicazione degli undo. Per questo motivo nelle tabelle sprovviste di chiave primaria è stata inserita la colonna tt_rowid che permette appunto la distinzione delle tuple. Il principale sviluppo futuro dell'applicazione sarà l'implementazione della funzione TimeTravel undrop che permetterà, come la Oracle Flashback Drop, di ripristinare una tabella cancellata. Il motivo per cui non è ancora stata realizzata è legato all'attuale mancanza di particolari parametri degli event trigger che dovrebbero essere disponibili nella versione 9.4 di PostgreSQL. Per lo stesso motivo non è stato ancora creato un event trigger che disabiliti automaticamente la tecnologia TimeTravel su una tabella sulla quale è stata eseguita una DDL di tipo alter. Un'altra possibile miglioria sarà di comprimere lo schema tt in cui vengono create le tabelle necessarie al corretto funzionamento della tecnologia TimeTravel per ridurre lo spazio da esse occupato. Inne, bisognerà permettere all'utente di classicare le tabelle in base alla loro importanza, assegnando così a esse un tempo oltre il quale i loro log vengano automaticamente puliti dalle transazioni che stanno oltre l'intervallo di attenzione.

77


Sitograa

Oracle 11g Release 2 (11.2)

[SIT-01]

Oracle速 Database Administrator's Guide <http://docs.oracle.com/cd/E11882_01/server.112

/e25494/toc.htm> [SIT-02]

Oracle速 Database 2 Day DBA <http://docs.oracle.com/cd/E11882_01/server.112

/e10897/toc.htm>

PostgreSQL 9.3.4

[SIT-03]

PostgreSQL 9.3.4 Documentation <http://www.postgresql.org/docs/9.3/static/index.html>

78


SITOGRAFIA

Oracle Flashback Tecnology

[SIT-04]

Using Oracle Flashback Technology in Oracle速 Database Advanced Application Developer's Guide <http://docs.oracle.com/cd/E11882_01/appdev.112/e41502

/adfns_flashback.htm#ADFNS1008> [SIT-05]

Managing Undo in Oracle速 Database Advanced Application Developer's Guide <

http://docs.oracle.com/cd/E11882_01/server.112/e25494

undo.htm#ADMIN013>

PL/pgSQL

[SIT-06]

PL/pgSQL - SQL Procedural Language in PostgreSQL 9.3.4 Documentation <http://www.postgresql.org/docs/9.3/static/plpgsql.html>

PHP

[SIT-07]

PHP: Manual <http://www.php.net/manual/en/>

79


Indice analitico

Archived log le, 7 Archiver (ARCH), 14

Disk manager, 19

Extent, 8

Automatic undo management, 29 File manager, 19 base directory, 23 Block, 8 Buer manager, 19

Catalogo di sistema, 20 Checkpoint (CKPT), 13

Flashback Data Archive, 27, 44 Flashback log, 7 Flashback Transaction, 27, 41 Function, 9

global directory, 22

Cluster database, 20 Cluster index, 9 Control le, 6

Indici, 9 IPC, 19 Istanza, 6

Data dictionary, 21

Istanza Oracle, 10

Data le, 6 Database buer, 10

Java pool, 11

Database template, 21

Large pool, 11

Database writer (DBWn), 13

Libreria libpq, 18

Db link, 9

Lock manager, 19

DBMS_FLASHBACK Package, 27, 39

Log writer (LGWR), 13 80


INDICE ANALITICO

Oracle Flashback, 25

pg_version, 21

Oracle Flashback Database, 28, 51

pg_xlog directory, 22

Oracle Flashback Drop, 28, 48

pgdata, 21

Oracle Flashback Query, 26, 33

PL/pgSQL, 55

Oracle Flashback Table, 28, 49

Postgres TimeTravel Technology, 54

Oracle Flashback Transaction Query, 27, 37

postgres.conf, 21

Oracle Flashback Version Query, 26, 34

Postmaster, 18

Package, 9 Page manager, 19 Parameter le (ple), 7 Password le, 7 pg_clog directory, 22

postmaster.opt, 22 postmaster.pid, 22 Process monitor (PMON), 14 Processi in background, 13 Program Global Area (PGA), 12

pg_database, 20

Recycle bin, 45

pg_hba.conf, 21

Redo log buer cache, 11

pg_ident.conf, 21

Redo log le, 6

pg_multixact directory, 22 pg_serial directory, 22 pg_settings, 20 pg_snapshots directory, 22 pg_stat_tmp directory, 22 pg_statistic, 21 pg_subtrans directory, 22 pg_tables, 20 pg_tblspc directory, 22 pg_twophase directory, 22

Schema, 8 SCN (System Change Number), 32 Segment, 8 Sequence, 9 Server parameter le (sple), 7 Shared pool, 11 Shutdown, 16 SID, 6 Sinonimi, 9 Snapshot, 9

pg_user, 20

81


INDICE ANALITICO

Startup, 16 Storage manager, 19 Stored procedure, 9 System Global Area, 10 System monitor (SMON), 13

Tabella, 8 Tabella dei log delle transazioni, 58, 62, 71 Tablespace, 8 Template0, 21 Template1, 21 TimeTravel Query, 59, 64, 71 TimeTravel Restore, 59, 64, 73 Trigger, 9

Vista, 8

82


La tecnologia flashback nei RDBMS Oracle e PostgreSQL