Strategie di backup e ripristino dei dati con Oracle
0 likes52 views
Parliamo di backup e ripristino dei dati in Oracle e vediamo come impostare una corretta ed efficace gestione di backup e recovery dei database aziendali. 際際滷 del webinar tenuto il 29 novembre 2023 da Anna Bruno e Cristiano Gasparotto di Datamaze.
More Related Content
Similar to Strategie di backup e ripristino dei dati con Oracle (20)
More from Datamaze (6)
Strategie di backup e ripristino dei dati con Oracle
- 1. Strategie di backup e ripristino dei dati con ORACLE Dueville, VI 2023.11.29
- 2. Chi sono? Laurea in Ingegneria Informatica presso Universit degli Studi di Lecce. Nel 2003 inizio la mia attivit in T-Systems Italia S.p.a. come Operatore di HD per poi passare nellarea sistemistica con mansioni di DBA Oracle. Ho seguito clienti in ambito bancario, assicurazioni , trasporti, energia, manifatturiero e servizi . Dal 2013 in Engineering D.HUB con medesime mansioni diventando responsabile del Gruppo DBA Vicenza. Nel 2022 inizio la nuova avventura in Datamaze. www.datamaze.it
- 3. Backup e ripristino dei dati Sono attivit fondamentali! Servono a garantire che i dati siano disponibili nel tempo. Necessari in situazioni di questo tipo: User error a causa di un errore nella logica dell'applicazione o per lesecuzione di un comando errato (update, delete, truncate,..) da parte delloperatore umano, i dati nel database vengono modificati o eliminati in modo errato; Media failure un problema sul supporto fisico ove risiedono i file del database.
- 4. Backup and Recovery: Concetti base La struttura fisica del database e il ruolo che ciascun elemento riveste nel processo di backup e recovery sono gli elementi che concorrono a determinare quali tecniche di backup e recovery utilizzare. Quali sono le componenti fisiche del database che ci consentono di recoverare i dati? I file e le altre strutture che compongono un database Oracle archiviano i dati e li proteggono da possibili guasti.
- 5. Backup and Recovery: Concetti base Physical Database Structures Used in Recovering Data Datafiles e data block Un database Oracle consiste di una o pi湛 unit storage logiche chiamate tablespace; ciascun tablespace 竪 costituito da uno o piu file fisici che risiedono sul sistema operativo chiamati datafiles. I dati (tabelle, indici, procedure,..) risiedono sui datafile. Il database gestisce lo spazio di archiviazione nel datafile in unit chiamate data blocks. Control Files Il control file contiene le informazioni relative alle strutture fisiche del database e al loro stato e diverse informazioni relative al backup e recovery.
- 6. Backup and Recovery: Concetti base Physical Database Structures Used in Recovering Data Redo logs registrano le modifiche fatte sui dati. Con un insieme completo di redolog e una vecchia copia di un datafile, il db pu嘆 riapplicare tutte le modifiche registrate nei redologs per ricreare il database ad un PIT tra il momento in cui 竪 stato eseguito il backup e lultima transazione sullultimo redolog disponibile. Undo segments quando un dato viene aggiornato viene creata unimmagine before update cos狸 che se una trx effettua rollback, le informazioni nellundo permettono di tornare indietro a prima dellaggiornamento.
- 7. Strumenti per Backup and Recovery: RMAN e User-Managed Backup Per eseguire il backup e leventuale ripristino in riferimento ai backup fisici, esistono 2 possibili soluzioni: Recovery Manager (RMAN), uno strumento (con client da riga di comando ed Enterprise Manager GUI interface) che si integra con le sessioni in esecuzione su Oracle per eseguire una serie di attivit di backup e ripristino, mantenendo inoltre un repository di dati storici relativi ai backup; Il tradizionale backup e ripristino gestito dall'utente, dove sei tu che gestisci direttamente i file che compongono il tuo database con un mix di comandi di sistema operativo e funzionalit di backup e ripristino SQL*Plus.
- 8. Strumenti di backup e ripristino Strumenti nativi per effettuare le operazioni di backup e ripristino RMAN Strumenti di terze parti Basati su comandi nativi Alcuni player: Veeam, Commvault, TSM,
- 9. Il processo di recovery del database: Concetti base Per ricostruire un database da un backup si fa riferimento a due fasi distinte: la prima consiste nel restore della copia di/dei datafile dal backup e la seconda nel recover del database fino allSCN desiderato riapplicando le modifiche contenute negli archive e nei redo logs.
- 10. Backup Il backup 竪 una copia dei dati del nostro database che pu嘆 essere utilizzata per ricostruire tali dati. I backups possono essere suddivisi in due categorie: Backup fisici (rman)- sono backup dei file fisici utilizzati per contenere i dati e per recoverare il database ossia datafile, controlfile e archived redolog. In definitiva, ogni backup fisico 竪 una copia dei file che memorizzano le informazioni del database in un'altra posizione, su disco o su un dispositivo di archiviazione offline come una tape library. Backup logici (expdp) essi contengono i dati logici (tabelle, stored procedure, trigger,) esportati attraverso lutility export di Oracle. Tali dati sono conservati in uno o pi湛 file binari (.dmp) e sono utilizzati per essere eventualmente reimportati nel database con lutility import. I backup fisici sono il fondamento di qualsiasi strategia di backup e ripristino. I backup logici sono un utile complemento ai backup fisici in molte circostanze.
- 11. Tipologie di Backup Oracle con RMAN Ci sono pi湛 modi per distinguere tra backup fisici che dipendono sia dallo stato del database quando il backup 竪 stato eseguito, sia da quale parte del database 竪 stato backuppato e anche da come il backup risultante 竪 stato conservato. Consistent and Inconsistent Backups Backup consistenti sono quelli effettuati quando tutte le trx nei redolog sono state applicate ai datafiles. Un db cos狸 restorato pu嘆 essere immediatamente aperto, senza effettuare media recovery. Per ragioni di disponibilit h24 del servizio, Oracle 竪 strutturato per lavorare anche con Backup inconsistenti, fatti a db aperto, pertanto dopo la fase di restore dei datafile, effettuer la recover applicando le modifiche contenute negli archived e online redo logs prima che il db sia nuovamente aperto.
- 12. Tipologie di Backup Oracle con RMAN Full and Incremental Backups FULL - Include tutti i datafile che costituiscono il database; essi possono essere creati con RMAN o con comandi di copia file di sistema operativo. Incrementali - salvano solo i blocchi dati dei datafile che sono stati modificati rispetto allultimo full. Image Copies, Backup Sets and Backup Pieces Il risultato di un bck RMAN pu嘆 essere sia una image copy che un backup set. Image copy - 竪 una copia identica bit-per-bit dei datafile. Backup set un insieme di backup piece, ciascuno contenente la copia di uno o pi湛 datafiles.
- 13. Un buon piano di backup Recovery Point Objective (RPO) 竪 il periodo massimo tollerabile per quanto riguarda la perdita di dati. Definisce sostanzialmente quanti dati possono essere persi a causa di un disastro. L'obiettivo definito per questo KPI ha un impatto sull'implementazione dei backup. Recovery Time Objective (RTO) 竪 il tempo massimo che abbiamo a disposizione per ripristinare il sistema. 際際滷 tratta dal modulo di formazione 束Amministrare un database server損, Datamaze
- 14. Pianificare le nostre Strategie di backup Decidere tra ARCHIVELOG e NOARCHIVELOG Mode In modalit ARCHIVELOG il redo log in uso, prima di essere sovrascritto, deve essere archiviato su una destinazione fisica preservando quindi tutte le transazioni che esso contiene affinch辿 possano essere riapplicate in operazioni di recovery. In NOARCHIVELOG, i redolog saranno semplicemente sovrascritti ciclicamente pertanto tutte le trx registrate andranno perse. Di conseguenza: in NOARCHIVELOG non 竪 possible effettuare backup online del db e non si pu嘆 recuperare il database ad uno specifico Point-In-Time che richiede lapplicazione dei redo logs; in ARCHIVELOG deve essere previsto dello storage aggiuntivo per la conservazione degli archivelog; pu嘆 esserci un minimo (trascurabile) overhead dovuto ai processi archiver; gli archived redo logs devono essere mantenuti per un periodo di tempo possibilmente su storage esterno.
- 15. Pianificare le nostre strategie di backup Determinare la frequenza dei backup Dipende dalla frequenza con cui vengono create e cancellate le tabelle, effettuate insert, delete e update nelle tabelle. Eseguire i backups prima e dopo eventuali modifiche strutturali Creazione di nuove tablespace, aggiunta o rename di datafile nelle tablespace esistenti, modifica dei gruppi dei redologs. Backup di Tablespaces pi湛 usate. Backup dopo operazioni in NOLOGGING. Operazioni di caricamento in direct path oppure creazione di tabelle e indici in NOLOGGING che non scrivono nei redologs. Export dei Dati ad integrazione dei bck e per maggior flessibilit. Mantenere copia della configurazione HW e SW del Server.
- 16. Pianificare le nostre Strategie di backup Archiviare i vecchi backups Esistono diversi motivi per conservare i backup pi湛 vecchi di datafile e archivelog: necessario un backup precedente dei datafile e degli archivelog per eseguire la recover a un point-in-time precedente al backup pi湛 recente; Se il backup pi湛 recente 竪 danneggiato, 竪 comunque possibile ripristinare il database utilizzando un backup precedente e l'insieme completo degli archivelog a partire da quel backup precedente; Potrebbe essere necessario conservare una copia del database a scopo di archiviazione.
- 17. Scenario 1. Backup Full Il backup di tipo FULL costituisce la base per ogni successivo ragionamento: la nostra catena dei backup parte sempre da qui. In questo caso eseguiamo per esempio ogni giorno il backup full del database. Supponiamo sia schedulato a mezzanotte. Il nostro crash avviene alle ore 7 del mattino successivo al backup. Potremo ripristinare il nostro database alla mezzanotte dal backup della notte precedente, tutti i dati prodotti fino alle ore 7 andranno persi.
- 18. Scenario 2. Backup Full + Incrementale Immaginiamo adesso di avere una strategia di backup che consiste nelleseguire un Full la Domenica alle ore 22 e nei successive giorni della settimana, sempre alle ore 22, eseguire lincrementale. Supponiamo che il crash avvenga alle ore 18 del gioved狸. Oracle partir dalla restore del full della Domenica, applicher gli incrementali dal Luned狸 al mercoled狸 ma tutti i dati prodotti dalle 22 del mercoled狸 alle 18 del gioved狸 andranno persi.
- 19. Scenario 3. Backup Full + Incrementale con Archivelog Immaginiamo adesso di avere una strategia di backup che consiste nelleseguire un Full la Domenica alle ore 22 e nei successive giorni della settimana, sempre alle ore 22, eseguire lincrementale. Avendo per嘆 il database in ARCHIVELOG, ho anche schedulato il bck degli archivelog ogni ora. Il nostro crash avviene alle 17.50 del gioved狸. Oracle partir dalla restore del full della Domenica, applicher gli incrementali dal Luned狸 al mercoled狸 e in ultimo gli archivelog prodotti dallultimo incrementale, quindi fino alle 17. Andranno persi soli i dati prodotti dalle 17 alle 17.50.
- 20. Oracle Flashback Database La tecnologia di Flashback Database e relativi restore point (disponibile gi da versione 10g ma su Enterprise Ed.) 竪 una funzionalit di protezione dei dati che consente di riportare il database indietro nel tempo per correggere eventuali problemi causati dalla corruzione logica del dato o da errori utente in un intervallo di tempo designato. Pu嘆 essere molto utile durante gli aggiornamenti dei database, la distribuzione di nuove release applicative e in quegli gli scenari di test quando i database devono essere creati e ricreati rapidamente. Si basa sulla configurazione di 3 parametri: 1. DB_RECOVERY_FILE_DEST 2. DB_RECOVERY_FILE_DEST_SIZE 3. DB_FLASHBACK_RETENTION_TARGET e sulla struttura dei flashback logs, che sono Oracle-generated logs utilizzati per eseguire le operazioni di flashback, possono essere scritti solo nella fast recovery area (indicata dalla DB_RECOVER_FILE_DEST) e non possono essere salvati su disco.
- 21. Oracle Flashback Database Un esempio di utilizzo del Flashback Database. Supponiamo che si debba effettuare un rilascio applicativo che avr un impatto significativo sulla base dati. Prima di effettuare tale intervento, si pu嘆 creare un restore point sul db: SQL> create restore point <restore point name>; Effettuare quindi il rilascio e in caso di problemi, per i quali si reputa necessario tornare indietro a prima dellintervento: SQL> flashback database to restore point <restore point name>; Limitazioni: non pu嘆 essere utilizzata a fronte di media failure, di cancellazione dei datafiles, di flashback a un PIT precedente alla restore o rigenerazione di un controlfile, altro.
- 22. Ridondanza Naturalmente, la strategia di backup scelta deve tener conto sia delle esigenze di ripristino del database ma anche di questioni relative a costi, risorse, personale e altri fattori. Laddove possibile si suggerisce sempre di ridondare, duplicare le strutture dati pi湛 sensibili. Il miglior insieme di ridondanza dovrebbe contenere: lultimo backup del controlfile e tutti i datafiles; tutti gli archivelog generati dopo lultimo backup; copia degli online redologs; copia del current controlfile; copia dei file di configurazione quali server parameter file, tnsnames.ora, and listener.ora La prima regola per proteggere il nostro insieme di ridondanza 竪: mettere le copie di datafile, control file e redo logs su dischi separati.
- 23. Il ripristino dei backup Nessun backup 竪 valido finch辿 non 竪 stato ripristinato con successo. Cosa dobbiamo fare: Validare i file di backup il pi湛 spesso possibile Mantenere vivi i database di test o sviluppo partendo dai backup di produzione Eseguire i test di ripristino e laggiornamento della documentazione. Nel caso di ripristino del database facciamo un backup del database che stiamo sostituendo
Editor's Notes
- #6: DATA BLOCK: la pi湛 piccola unit dati utilizzata dal database cos狸 come 竪 la pi湛 piccola unit di archiviazione che il database pu嘆 allocare. Quando il dato viene modificato, esso non 竪 scritto immediatamente sul datafile ma la modifica avviene in memoria e scritta sul datafile dopo un certo intervallo di tempo; se il database viene spento in modo irregolare (instance failure, shutdown abort) allora alcune modifiche ai dati saranno in memoria ma non sui datafile. CF: Database information (RESETLOGS SCN and time stamp),Tablespace and datafile records (filenames, datafile checkpoints, read/write status, offline ranges), Information about redo threads (current online redo log), Log records (log sequence numbers, SCN range in each log), A record of past RMAN backups, Information about corrupt datafile blocks
- #7: UNDO: Nel contesto della recovery, le informazioni nellundo vengono utilizzate per annullare le trx non committate dopo che sono stati applicati i redologs ai datafiles.
- #12: Backup consistenti - Tuttavia, un bck consistente pu嘆 essere creato solo a fronte di uno spegnimento pulito (normal) del database (non uno shutdown abort o dopo un crash del db). Backup inconsistenti - sar quindi necessario avere il database in ARCHIVELOG mode.
- #13: Lincrementale permette di ridurre notevolmente I tempi di recover perch竪 recupera I blocchi modificati rispetto al full evitando lapplicazione dei redolog. I backup incrementali possono essere creati solo con RMAN. Image copy - (la stessa che creerei col commando cp di Unix o il copy di Windows) con il plus per嘆 che RMAN effettua anche un check su possible corruzione del datafile. I backup set - sono la sola modalit con cui RMAN pu嘆 scrivere i suoi bck su media manager device come p.e. le tape libraries.
- #21: Questa funzionalit fornisce un'alternativa pi湛 efficiente al ripristino point-in-time e non richiede il ripristino preventivo del backup del database.