UNIVERSITÀ DEGLI STUDI DI MILANO

Транскрипт

1 UNIVERSITÀ DEGLI STUDI DI MILANO Facoltà di Scienze e Tecnologie Corso di Laurea Triennale in Informatica LA TECNOLOGIA FLASHBACK NEI RDBMS ORACLE E POSTGRESQL RELATORE Prof. Stefano Montanelli CORRELATORE Dott. Sergio Mior TESI DI LAUREA DI Michele Mariani Matricola Anno Accademico 2012/ 2013

2 A Ornella e Pierangelo

3 Indice Introduzione 3 1 Architettura RDBMS Architettura Oracle Architettura PostgreSQL Oracle Flashback technology Panoramica generale della tecnologia Oracle Flashback Requisiti per utilizzare la tecnologia Oracle Flashback Utilizzo delle funzioni Flashback per lo sviluppo di applicazioni Utilizzo delle funzioni Flashback per gli amministratori del database PostgreSQL TimeTravel technology Panoramica generale della tecnologia TimeTravel Installazione e disinstallazione della tecnologia TimeTravel Utilizzo delle funzioni TimeTravel Utilizzo dell'applicazione PHP Conclusioni 76 Sitograa 78 Indice analitico 80 2

4 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

5 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

6 Capitolo 1 Architettura RDBMS Indice 1.1 Architettura Oracle Database Oracle Istanza Oracle Architettura PostgreSQL Libreria libpq Processi server Storage manager Cluster database Nel seguente capitolo descriverò l'architettura dei due RDBMS scelti evidenziando per ciascuno le principali strutture siche e logiche. 5

7 CAPITOLO 1. ARCHITETTURA RDBMS 1.1 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 Database Oracle Un database Oracle è formato sia da strutture logiche che da strutture siche 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 database. 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

8 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 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

9 CAPITOLO 1. ARCHITETTURA RDBMS Tablespace: 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 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 rappresentanti 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

10 CAPITOLO 1. ARCHITETTURA RDBMS Sequence: è 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 pubblici 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'utente, 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

11 CAPITOLO 1. ARCHITETTURA RDBMS Figura 1.1.2: Strutture logiche 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 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

12 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 informazioni 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 processo 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

13 CAPITOLO 1. ARCHITETTURA RDBMS Figura 1.1.3: System Global Area 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

14 CAPITOLO 1. ARCHITETTURA RDBMS Figura 1.1.4: Program Global Area 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

15 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

16 CAPITOLO 1. ARCHITETTURA RDBMS Figura 1.1.5: Processi in background 15

17 CAPITOLO 1. ARCHITETTURA RDBMS 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

18 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

19 CAPITOLO 1. ARCHITETTURA RDBMS Figura 1.2.1: Struttura PostgreSQL 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 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

20 CAPITOLO 1. ARCHITETTURA RDBMS di dati 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 consistenza. 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

21 CAPITOLO 1. ARCHITETTURA RDBMS 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 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 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 proprietario, le informazioni sulle modalità di creazione e i privilegi per accedervi. 20

22 CAPITOLO 1. ARCHITETTURA RDBMS pg_statistic: fornisce informazioni sulle statistiche degli oggetti del cluster; questa tabella 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 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 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'autenticazione del client. Il le PG_VERSION contenente la versione di PostgreSQL utilizzata. 21

23 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 contenente i le di status delle subtransazioni. La directory pg_tblspc 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. Tali 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 memorizzate tutte le variazioni a livello di blocco. Infatti quando una pagina dati viene 22

24 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

25 Capitolo 2 Oracle Flashback technology Indice 2.1 Panoramica generale della tecnologia Oracle Flashback Funzionalità per lo sviluppo di applicazioni Funzionalità di amministrazione di database Requisiti per utilizzare la tecnologia Oracle Flashback Automatic undo management Permessi Utilizzo delle funzioni Flashback per lo sviluppo di applicazioni Premessa Oracle Flashback Query Oracle Flashback Version Query Oracle Flashback Transaction Query DBMS_FLASHBACK Package Flashback Transaction Flashback Data Archive Utilizzo delle funzioni Flashback per gli amministratori del database Recycle bin Oracle Flashback Drop Oracle Flashback Table Oracle Flashback Database Nel seguente capitolo utilizzerò stralci della guida oracle database 11.2 [SIT-04] per descrivere il concetto della Flashback, faranno seguito degli esempi. 24

26 CAPITOLO 2. ORACLE FLASHBACK TECHNOLOGY 2.1 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

27 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 Funzionalità per lo sviluppo di applicazioni Nello sviluppo di applicazioni è possibile utilizzare le seguenti funzioni di Flashback per riportare i dati storici o annullare le modiche errate Oracle Flashback Query Utilizzare questa funzione per recuperare i dati in un tempo del passato specicato con la clausola as of del comando select 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. 1 È possibile anche utilizzare queste funzioni in modo interattivo come un utente di database o amministratore. 26

28 CAPITOLO 2. ORACLE FLASHBACK TECHNOLOGY 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 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 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 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

29 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 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 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 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 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

30 CAPITOLO 2. ORACLE FLASHBACK TECHNOLOGY 2.2 Requisiti per utilizzare la tecnologia Oracle Flashback 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

31 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; 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 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

32 CAPITOLO 2. ORACLE FLASHBACK TECHNOLOGY 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 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

33 CAPITOLO 2. ORACLE FLASHBACK TECHNOLOGY EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO 7369 SMITH CLERK dic ALLEN SALESMAN feb WARD SALESMAN feb JONES MANAGER apr MARTIN SALESMAN set BLAKE MANAGER mag CLARK MANAGER giu SCOTT ANALYST apr KING PRESIDENT 17-nov TURNER SALESMAN set ADAMS CLERK mag JAMES CLERK dic FORD ANALYST dic MILLER CLERK gen 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

34 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) 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, : Modichiamo il salario di smith: UPDATE emp SET sal = 500 WHERE ename = SMITH ; COMMIT; 33

35 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 dello stesso giorno della modica) basta dare il comando: SELECT ename, sal FROM emp AS OF TIMESTAMP TO_TIMESTAMP ( :54:00, YYYY-MM-DD HH24:MI:SS ) WHERE ename = SMITH ; oppure: SELECT ename,sal FROM emp AS OF SCN WHERE ename = SMITH ; ENAME SAL SMITH 800 che infatti ci mostra 800 come ci si aspettava Oracle Flashback Version Query Come prima vediamo il valore del salario di smith: SELECT ename, sal FROM emp WHERE ename = SMITH 34

36 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, : 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, : 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

37 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 AND 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( :23:02, YYYY-MM-DD HH24:MI:SS ) AND TO_TIMESTAMP( :23:47, YYYY-MM-DD HH24:MI: SS ) WHERE ename = SMITH ; ENAME SAL VERSIONS_STARTSCN VERSIONS_STARTTIME VERSIONS_XID OP VERSIONS_ENDSCN VERSIONS_ENDTIME SMITH GEN-14 16:23:38, U SMITH GEN-14 16:23:28, GEN-14 16:23:38, AD U SMITH GEN-14 16:23:28, 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

38 CAPITOLO 2. ORACLE FLASHBACK TECHNOLOGY ˆ VERSIONS_STARTTIME: 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) 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, : Mettiamo 100 come valore del salario di smith e poi cancelliamo tutta la tupla: 37

39 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, : 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 AND ); XID OPERATION START_SCN COMMIT_SCN LOGON_USER UNDO_SQL B DELETE 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'); B BEGIN SCOTT AF UPDATE SCOTT update "SCOTT"."EMP" set "SAL" = '800' where ROWID = 'AAAR3sAAEAAAACTAAA'; AF BEGIN SCOTT 38

40 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; 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

41 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, : 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 ( ); oppure exec DBMS_FLASHBACK.ENABLE_AT_TIME (TO_TIMESTAMP( :49:00, YYYY-MM-DD HH24:MI:SS )); 40

42 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 ; ENAME SAL ALLEN 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

43 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

44 CAPITOLO 2. ORACLE FLASHBACK TECHNOLOGY VERSIONS_XID VERSIONS_STARTSCN VERSIONS_ENDSCN V TEST1COL I MNO I JKL I GHI 06000B00AA I DEF 06000B00AA 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) := ; 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

45 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 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

46 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 Recycle bin Il recycle bin è una tabella del dizionario dati che contiene informazioni riguardo alle tabelle droppate e agli oggetti ad esse collegate. 45

47 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

48 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 denitivamente ˆ 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 ORIGINAL_NAME OPERATION TYPE CREATETIME DROPTIME DROPSCN CAN_UNDROP CAN_PURGE BIN$6MdVJuC/STyQhjllkmq6HA==$0 EMP DROP TABLE :11:06: :17:13: YES YES 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

49 CAPITOLO 2. ORACLE FLASHBACK TECHNOLOGY che ritorna lo stesso risultato della query SELECT * FROM emp; se non avessimo però fatto il drop di emp 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; 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

50 CAPITOLO 2. ORACLE FLASHBACK TECHNOLOGY ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME EMP BIN$9GnQ4c9fgzjgQAB/AQAUww==$0 TABLE :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 ENAME SAL SMITH 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

51 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, : 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 ; oppure 50

52 CAPITOLO 2. ORACLE FLASHBACK TECHNOLOGY FLASHBACK TABLE scott.emp TO TIMESTAMP TO_TIMESTAMP( :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 ; ENAME SAL SMITH 800 ALLEN 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

53 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 e creiamo anche un punto di ripristino: 25-GEN-14 14:49:56, : 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

54 CAPITOLO 2. ORACLE FLASHBACK TECHNOLOGY SHUTDOWN IMMEDIATE; STARTUP MOUNT EXCLUSIVE; FLASHBACK DATABASE TO SCN ; oppure FLASHBACK DATABASE TO RESTORE POINT bef_update; oppure FLASHBACK DATABASE TO TIMESTAMP to_timestamp( :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

55 Capitolo 3 PostgreSQL TimeTravel technology Indice 3.1 Panoramica generale della tecnologia TimeTravel File per l'installazione e la disinstallazione Le funzioni PL/pgSQL L'applicazione php per la gestione della TimeTravel Installazione e disinstallazione della tecnologia TimeTravel Utilizzo delle funzioni TimeTravel Premessa Attivazione Transazioni sulla tabella Tabella dei log delle transazioni TimeTravel Query TimeTravel Restore Disattivazione Utilizzo dell'applicazione PHP Installazione Avvio Transazioni sulla tabella Uso della TimeTravel Tabella dei log delle transazioni TimeTravel Query TimeTravel Restore Disattivazione Nel seguente capitolo descriverò il lavoro svolto per sviluppare una funzionalità simile alla Oracle FlashBack nell'rdbms PostgreSQL, faranno seguito degli esempi. 54

56 CAPITOLO 3. POSTGRESQL TIMETRAVEL TECHNOLOGY 3.1 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

57 CAPITOLO 3. POSTGRESQL TIMETRAVEL TECHNOLOGY File per l'installazione e la disinstallazione 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 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 Le funzioni PL/pgSQL Attivazione Per poter utilizzare le funzionalità della TimeTravel su una tabella bisogna innanzitutto attivarla sulla tabella in questione. 56

58 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(); 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

59 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(); 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

60 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 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 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

61 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); 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

62 CAPITOLO 3. POSTGRESQL TIMETRAVEL TECHNOLOGY 3.3 Utilizzo delle funzioni TimeTravel Vediamo ora tramite esempi l'uso di tutte le funzioni presenti nella tecnologia TimeTravel 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 ); 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 demo TABLE_NAME 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

63 CAPITOLO 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: 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: del 01/03/2014 eliminiamo il dipendente con id 2 : DELETE FROM demo.dipendenti WHERE id=2; Alle ore 15:21: 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; ID NAME SAL 1 Mario Luca Tabella dei log delle transazioni Ora interroghiamo la tabella dei log delle transazioni per conoscere i metadati delle transazioni avvenute sulla tabella dipendenti: 62

64 CAPITOLO 3. POSTGRESQL TIMETRAVEL TECHNOLOGY SELECT * FROM tt.demo_dipendenti_log; ID NAME SAL TT_MODE TT_TUPLE TT_TIME TT_USER TT_REDO TT_UNDO 1 Mario 2000 INSERT NEW :13: 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 = '1' AND name = 'Mario' AND sal = 2000 ); 2 Davide 1500 INSERT NEW :13: 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 :13: 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 :18: postgres delete from demo.dipendenti where id=2; INSERT INTO demo.dipendenti( id, name, sal) VALUES( '2', 'Davide', 1500); 3 Luca 500 UPDATE NEW :21: 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

65 CAPITOLO 3. POSTGRESQL TIMETRAVEL TECHNOLOGY Dalla tabella possiamo osservare in ordine cronologico i metadati delle transazioni dal più vecchio al più recente 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 :20:00. Diamo il comando: SELECT tt.query( demo, dipendenti, :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 Luca 1000 Come ci aspettavamo luca ha il salario che aveva prima della transazione di update TimeTravel Restore Vogliamo invece ora riportare la tabella dipendenti a come si trovava subito dopo l'assunzione dei tre dipendenti. 64

66 CAPITOLO 3. POSTGRESQL TIMETRAVEL TECHNOLOGY Scegliamo quindi un tempo intermedio tra l'ultimo insert e il delete: :15:00. Diamo il comando: SELECT tt.restore( demo, dipendenti, :15:00 ); Proviamo ora a vedere quali dati contiene la tabella dipendenti dopo il restore: SELECT * FROM demo.dipendenti; ID NAME SAL 1 Mario Luca Davide 1500 La tabella dipendenti è tornata proprio come era prima delle transazioni di delete e di update Disattivazione Per disattivare la TimeTravel sulla tabella dipendenti basta usare il comando: SELECT tt.off( demo, dipendenti ); 3.4 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

67 CAPITOLO 3. POSTGRESQL TIMETRAVEL TECHNOLOGY ˆ myhost: indirizzo dell'host ˆ myuser: nome dell'utente col quale si vuole accedere ˆ mypsw: password dell'utente myuser ˆ mydb: nome del database al quale si vuole accedere Avvio Per avviare l'applicazione PHP basterà aprire il browser alla pagina 1. 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

68 CAPITOLO 3. POSTGRESQL TIMETRAVEL TECHNOLOGY ˆ Mostra dati: pulsante per vedere i valori della tabella ˆ TimeTravel attiva?: informazione che ci dice se la TimeTravel è attiva o no ˆ Attiva TimeTravel: pulsante per attivare la TimeTravel ˆ Disattiva TimeTravel: pulsante per disattivare la TimeTravel ˆ Usa 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 timetravel : 67

69 CAPITOLO 3. POSTGRESQL TIMETRAVEL TECHNOLOGY Ora sono presenti i pulsanti disattiva timetravel e usa timetravel mentre è stato disabilitato il pulsante attiva timetravel 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: 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: del 01/03/2014 eliminiamo il dipendente con ID 2: DELETE FROM demo.dipendenti WHERE id=2; Alle ore 15:21: 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

70 CAPITOLO 3. 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

71 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

72 CAPITOLO 3. POSTGRESQL TIMETRAVEL TECHNOLOGY ˆ TORNA: per tornare alla pagina precedente 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 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

73 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

74 CAPITOLO 3. POSTGRESQL TIMETRAVEL TECHNOLOGY modicato dalla transazione update 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

75 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 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

76 CAPITOLO 3. POSTGRESQL TIMETRAVEL TECHNOLOGY 75

77 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

78 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 Time- Travel 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

79 Sitograa Oracle 11g Release 2 (11.2) [SIT-01] Oracle Database Administrator's Guide < /e25494/toc.htm> [SIT-02] Oracle Database 2 Day DBA < /e10897/toc.htm> PostgreSQL [SIT-03] PostgreSQL Documentation < 78

80 SITOGRAFIA Oracle Flashback Tecnology [SIT-04] Using Oracle Flashback Technology in Oracle Database Advanced Application Developer's Guide < /adfns_flashback.htm#adfns1008> [SIT-05] Managing Undo in Oracle Database Advanced Application Developer's Guide < undo.htm#admin013> PL/pgSQL [SIT-06] PL/pgSQL - SQL Procedural Language in PostgreSQL Documentation < PHP [SIT-07] PHP: Manual < 79

81 Indice analitico Archived log le, 7 Archiver (ARCH), 14 Automatic undo management, 29 base directory, 23 Block, 8 Buer manager, 19 Catalogo di sistema, 20 Checkpoint (CKPT), 13 Cluster database, 20 Cluster index, 9 Control le, 6 Data dictionary, 21 Data le, 6 Database buer, 10 Database template, 21 Database writer (DBWn), 13 Db link, 9 DBMS_FLASHBACK Package, 27, 39 Disk manager, 19 Extent, 8 File manager, 19 Flashback Data Archive, 27, 44 Flashback log, 7 Flashback Transaction, 27, 41 Function, 9 global directory, 22 Indici, 9 IPC, 19 Istanza, 6 Istanza Oracle, 10 Java pool, 11 Large pool, 11 Libreria libpq, 18 Lock manager, 19 Log writer (LGWR), 13 80

82 INDICE ANALITICO Oracle Flashback, 25 Oracle Flashback Database, 28, 51 Oracle Flashback Drop, 28, 48 Oracle Flashback Query, 26, 33 Oracle Flashback Table, 28, 49 Oracle Flashback Transaction Query, 27, 37 Oracle Flashback Version Query, 26, 34 Package, 9 Page manager, 19 Parameter le (ple), 7 Password le, 7 pg_clog directory, 22 pg_database, 20 pg_hba.conf, 21 pg_ident.conf, 21 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 pg_user, 20 pg_version, 21 pg_xlog directory, 22 pgdata, 21 PL/pgSQL, 55 Postgres TimeTravel Technology, 54 postgres.conf, 21 Postmaster, 18 postmaster.opt, 22 postmaster.pid, 22 Process monitor (PMON), 14 Processi in background, 13 Program Global Area (PGA), 12 Recycle bin, 45 Redo log buer cache, 11 Redo log le, 6 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 81

83 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