Oracle9i. Sono le dieci di sera, state impazzendo sul database. Indietro nel tempo con. Flashback Query

Transcript

1 Nella versione 9i del database più diffuso al mondo sono state aggiunte molte nuove funzionalità, una di queste consente di visualizzare i dati com erano in un determinato istante del passato Indietro nel tempo con Oracle9i Flashback Query Sono le dieci di sera, state impazzendo sul database di un cliente perché c è qualcosa che non vi torna nei dati. Dopo avere fatto decine di select, pregato in molti modi il Santo protettore dei programmatori e pianto lacrime amare, vi giunge l illuminazione: <<Eureka! Ecco i record di troppo!>>. Pensate subito al programma, o all utente, che sbagliando ha inserito quei dati. OK, niente panico, cancello questi record e sono a cavallo! Il comando da eseguire si scrive in pochi secondi: Delete from tabella Where condizione; Commit; «A posto! Controlliamo, per sicurezza ma che succede perché non trovo più? NO! HO CANCEL- LATO LE RIGHE SBAGLIATE!». Dite la verità, se lavorate su database da un po di tempo sicuramente vi è capitato. Dato il comando di Commit, il danno è fatto ed irreparabile. Bisogna recuperare il backup (se è disponibile) e questo comporta comunicare l errore al cliente e, soprattutto, al proprio capo. Problemi in vista! Il database è Oracle 9i? Ok, non ci sono problemi, c è modo per recuperare subito le righe cancellate mediante una flashback query. In quest articolo vedremo cos è e come si utilizza il package DBMS_FLASHBACK. In generale La logica è piuttosto semplice: i dati modificati vengono conservati in un apposito tablespace, detto di Massimo Ruocchio mruocchio@programmers.net È laureato in matematica ed è certificato Oracle Application Developer. Si occupa di analisi, progettazione e sviluppo di applicazioni software. UNDO Tablespace, anziché nei classici Rollback Segment. Si stabilisce un ammontare di tempo (chiamiamolo periodo di conservazione) durante il quale il DBMS deve conservare i dati modificati in questo tablespace. Scaduto il periodo di conservazione, i dati potranno essere sovrascritti. In qualunque momento all interno del periodo di conservazione, è possibile leggere i dati com erano in un istante precedente. I dati vecchi possono, ovviamente, essere reinseriti nelle tabelle attuali in modo da ripristinare, a tutti gli effetti, la situazione antecedente all istruzione da annullare. La lettura dei dati dal tablespace di UNDO è effettuata mediante il package DBMS_FLASHBACK che vedremo nel dettaglio più avanti. Se il periodo di conservazione è scaduto ma i dati non sono stati sovrascritti nel tablespace di UNDO, allora è comunque possibile effettuare la lettura dei vecchi dati. Ma come si individua l istante temporale a cui si intende ritornare? In due modi: mediante un system change number oppure mediante un timestamp. Un system change number non è altro che un numero attribuito automaticamente da Oracle ad ogni modifica occorsa al sistema. Nel Listato c è un esempio 7

2 LISTATO Esempio di assegnazione dei System Change Number SQL*Plus: Release Production on Mar Mar 9 ::9 00 (c) Copyright 00 Oracle Corporation. All rights reserved. Il compito del DBA La prima cosa da fare è creare il tablespace di UNDO. L istruzione è semplice: Create UNDO tablespace nome Datafile percorso SIZE Dimensione; 8 Connesso a: Oracle9i Personal Edition Release Production JServer Release Production Select * from pippo; declare xscn number; begin for i in.. loop 6 select dbms_flashback.get_system_change_number 7 into xscn 8 from dual; 9 dbms_output.put( OLD SCN= xscn); 0 delete pippo where rownum=; commit; select dbms_flashback.get_system_change_number into xscn 6 from dual; 7 dbms_output.put_line( - NEW SCN= xscn); 8 9 end loop; 0 end; / OLD SCN= NEW SCN=0990 OLD SCN= NEW SCN=099 OLD SCN=099 - NEW SCN=099 OLD SCN=099 - NEW SCN=099 OLD SCN=099 - NEW SCN=099 per capire il funzionamento del system change number. La tabella PIPPO contiene cinque record. Lo script effettua la delete di una riga alla volta e, per ogni cancellazione, mostra il system change number prima e dopo l operazione. Come si vede, il system change number cambia per ogni istruzione di delete eseguita. È possibile tornare ad uno stato precedente del database passando un timestamp (cioè una data munita di ore, minuti, secondi e frazioni di secondo), ma c è un problema di precisione di cui parleremo più avanti. Ovviamente, affinché il package DBMS_ FLASHBACK possa essere utilizzato, il database deve essere opportunamente parametrizzato. L attività di impostazione e parametrizzazione tocca al DBA e sarà discussa nel prossimo paragrafo. A questo punto bisogna impostare tre parametri di inizializzazione: UNDO_MANAGEMENT deve essere impostato ad AUTO per consentire la gestione automatica del tablespace di UNDO; UNDO_TABLESPACE deve essere valorizzato con il nome del tablespace di UNDO creato; UNDO_RETENTION deve essere valorizzato con il numero di secondi che definiscono il periodo di conservazione, per default vale 900 ( minuti). Dopo avere impostato il parametro UNDO_ MANAGEMENT bisogna riavviare il, perché il parametro viene letto solo nella fase di start-up. Infine bisogna dare all utente che intende utilizzare il package DBMS_FLASHBACK il permesso di farlo, quindi connessi con l utente SYS bisogna dare il comando GRANT EXECUTE ON DBMS_FLASHBACK TO nomeutente; A questo punto il compito del DBA è finito (non c è voluto molto, in verità) e comincia il compito dello sviluppatore. Per di più nell installazione standard di Oracle9i i passi che abbiamo elencato (tranne la concessione della GRANT) vengono eseguiti automaticamente. Nel prossimo paragrafo descriviamo nel dettaglio il package DBMS_FLASHBACK. Il package DBMS_FLASHBACK Il package è costituito dalle seguenti procedure e funzioni: Procedure enable_at_time(query_time in TIMESTAMP); Procedure enable_at_system_change_number (query_scn in NUMBER); Procedure disable; Function get_system_change_number return NUMBER; La funzione GET_SYSTEM_CHANGE_NUMBER ritorna il system change number corrente. L abbiamo vista utilizzata nel Listato. Per far tornare il sistema ad una situazione antecedente bisogna utilizzare una delle procedure

3 ENABLE_AT, passando un istante (timestamp) oppure un system change number. Mediante la procedura DISABLE si fa ritornare il sistema allo stato corrente. Dopo una ENABLE_AT, e prima di una DISABLE, non è possibile modificare i dati né effettuare un ulteriore ENABLE_AT. Si tratta a tutti gli effetti di una sessione di sola lettura dei dati così com erano in un momento precedente. Facciamo qualche esempio. Un po di pratica Abbiamo cancellato queste benedette righe e dobbiamo reinserirle. Abbiamo imparato a leggere i dati come erano ad un certo istante, ma abbiamo visto che durante una sessione di FLASHBACK non è possibile effettuare inserimenti. Vediamo come fare per ripristinare i dati. Dal Listato vediamo che, prima della prima cancellazione dalla tabella PIPPO, il system change number era Nel Listato ripristiniamo la tabella come era in quel momento. Si può tornare ad un istante oppure ad un System Change Number Dichiariamo un cursore che prende i dati dalla tabella PIPPO e lo apriamo all interno di una sessione FLASHBACK relativa al system change number desiderato. Prima di effettuare gli inserimenti in tabella chiudiamo la sessione di FLASHBACK, tanto ormai i vecchi dati sono stati caricati in memoria. Scorriamo il cursore dei vecchi dati ed inseriamo nella tabella attuale. Se proprio non riusciamo a fare a meno dei cicli For, possiamo fare come indicato nel Listato. Abbiamo dichiarato una PL/SQL Table chiamata TN e basata sul tipo TAB_N (che è un vettore di variabili numeriche). All interno della sessione FLASH- BACK abbiamo caricato il vettore e, dopo essere tornati alla situazione attuale, lo abbiamo scorso per ripopolare la tabella. Il risultato è lo stesso. Il problema dei Timestamp Cos è un timestamp? Timestamp(N) è un nuovo tipo di dato presente in Oracle9i che aggiunge alla data classica le frazioni di secondo. N indica il numero di cifre decimali dei secondi e può valere da 0 a 9, dunque la precisione del timestamp può arrivare fino al miliardesimo di secondo. Per consentirci di gestire LISTATO Ripristino dei dati SQL*Plus: Release Production on Mar Mar 9 ::9 00 (c) Copyright 00 Oracle Corporation. All rights reserved. Connesso a: Oracle9i Personal Edition Release Production JServer Release Production select * from pippo; Nessuna riga selezionata Declare Cursor PIPPO_OLD is select * from pippo; N Number; Begin 6 DBMS_FLASHBACK.ENABLE_AT_SYSTEM_ CHANGE_NUMBER(0998); 7 OPEN PIPPO_OLD; 8 DBMS_FLASHBACK.DISABLE; 9 loop 0 FETCH PIPPO_OLD INTO N; Exit When PIPPO_OLD%NOTFOUND; Insert into pippo values(n); End loop; Commit; End; 6 / Select * from pippo; meglio i timestamp, Oracle ha fornito una funzione di conversione (TO_TIMESTAMP) ed una funzione che restituisce il timestamp di sistema (SYSTIME- STAMP). Per intuito, quando si sente parlare di tornare indietro ad una situazione precedente, si pensa ad un particolare istante. È quindi ovvio che ci debba essere la possibilità di vedere il sistema com era, ad esempio, il giorno 8 di Marzo 00 alle ore 0, minuti, secondi e 7 millesimi (a patto che questa data ricada nel periodo di conservazione). Il package DBMS_FLASHBACK mette a disposizione la funzione ENABLE_AT_TIME che, preso in input un timestamp, cerca il system change number corrispondente ed effettua una chiamata alla procedura ENABLE_AT_SYSTEM_CHANGE_NUMBER. C è, però, un problema: per associare il timestamp al system change number, Oracle conserva automaticamente ogni cinque minuti il timestamp ed il system change number correnti. Quando l utente richiede di tor- 9

4 LISTATO Ripristino dei dati utilizzando due cicli FOR select * from pippo; Nessuna riga selezionata Declare Cursor PIPPO_OLD is select * from pippo; type TAB_N is table of Number index by binary_integer; TN TAB_N; 6 i number := ; 7 Begin 8 DBMS_FLASHBACK.ENABLE_AT_SYSTEM_ CHANGE_NUMBER(0998); 9 0 For rec in PIPPO_OLD loop TN(i):= rec.pluto; i := i + ; End loop; DBMS_FLASHBACK.DISABLE; 6 7 For i in..tn.count loop 8 Insert into pippo values(tn(i)); 9 End loop; 0 Commit; End; / Select * from pippo; nare ad un certo istante, Oracle determina il system change number registrato più prossimo al timestamp richiesto, ma questo system change number potrebbe essere relativo ad una situazione dati che si era verificata due minuti e mezzo prima o dopo rispetto all istante che avevamo richiesto. In due minuti e mezzo su un può succedere di tutto, quindi i dati potrebbero essere molto diversi da quelli che ci aspettiamo. Come risolvere questo problema? Si può creare una tabella applicativa che conserva le coppie (timestamp, system change number) ad una frequenza superiore ad una volta ogni cinque minuti oppure ad ogni modifica delle tabelle critiche. La struttura della tabella potrebbe essere la seguente create table TAB_SCN_TIME (TSTAMP Timestamp(9), SYSTEMCN Number); Poi basterebbe scrivere una semplice procedura del tipo: create or replace procedure TORNA_ALLE (Istante in TIMESTAMP) is xscn number; Begin DBMS_FLASHBACK.DISABLE; Select SYSTEMCN into xscn from TAB_SCN_TIME where TSTAMP = ( Select Max(TSTAMP) From TAB_SCN_TIME Where TSTAMP <= Istante); DBMS_FLASHBACK.ENABLE_AT_ SYSTEM_CHANGE_NUMBER(xSCN); Exception When no_data_found then Null; End; / che fa all incirca le stesse operazioni della procedura ENABLE_AT_TIME associando, però, all istante richiesto dall utente, un system change number più significativo. Nella procedura precedente abbiamo inserito una DISABLE prima di ogni ENABLE per evitare l errore ORA-088 che corrisponde al tentativo di riabili- TABELLA Errori collegati al Package DMBS_FLASHBACK 60 Errore ORA-880 ORA-88 ORA-88 ORA-88 ORA-88 ORA-88 Descrizione Si è cercato di tornare indietro oltre il periodo di conservazione ed i dati sono stati già sovrascritti nel tablespace di UNDO. Si è specificato un system change number non valido. Quando si è in modalità Flashback non è possibile eseguire istruzioni che modificano i dati o le strutture dati (DML e DDL). Prima di entrare in modalità Flashback bisogna chiudere la transazione facendo Commit oppure Rollback. Quando si è in modalità Flashback non è possibile aprire una nuova sessione con ENABLE prima di avere chiuso la precedente con DISABLE. L utente SYS non è abilitato a lavorare in modalità Flashback.

5 tare la modalità Flashback mentre si è già in modalità Flashback. Gli altri errori collegati all utilizzo del package DBMS_FLASHBACK sono elencati in Tabella. Per quanto visto in questo paragrafo possiamo affermare che conviene fare riferimento, laddove possibile, ai system change number invece che ai timestamp. Conclusioni La possibilità di vedere i dati com erano in un istante del passato, e poi di poterli riutilizzare, stuzzica molto la fantasia dello sviluppatore. Non solo per riparare agli inevitabili errori. Ad esempio si potrebbe aggiungere, ad una funzione che visualizza delle statistiche su dati che cambiano velocemente, la possibilità di vedere com era la situazione in un istante precedente scelto dall utente (ovviamente all interno del periodo di conservazione). Molti altri utilizzi possono essere trovati per il package DBMS_FLASHBACK, ma bisogna tenere conto delle limitazioni e della logica dell oggetto. Meglio, allora, scrivere codice ragionando in termini di system change number anziché di timestamp. Se in un certo istante occorre una modifica strutturale di una tabella, anche solo l allargamento di un campo, i dati di quella tabella precedenti a tale modifica non saranno più recuperabili, quindi conta molto anche la stabilità del database. DBMS_FLASHBACK ed il datatype TIMESTAMP sono solo due delle modifiche migliorative apportate ad Oracle9i. Per maggiori informazioni su questi strumenti si possono consultare le risorse indicate in Bibliografia e nei Riferimenti. Altre novità introdotte nell ultima versione di Oracle saranno trattate nei prossimi numeri di Computer Programming. BIBLIOGRAFIA [] Oracle Oracle9i Flashback Query, Oracle Corp., 00 [] Oracle Oracle9i Supplied PL/SQL Packages and Types Reference, Cap 6, Oracle Corp., 00 RIFERIMENTI [] (Oracle Technology Network) 6