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. Slide del webinar tenuto il 29 novembre 2023 da Anna Bruno e Cristiano Gasparotto di Datamaze.

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
nell’area 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
l’esecuzione di un comando errato (update, delete, truncate,..) da
parte dell’operatore 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 l’ultima transazione sull’ultimo redolog
disponibile.
 Undo segments – quando un dato viene aggiornato viene
creata un’immagine ‘before update’ così che se una trx effettua
rollback, le informazioni nell’undo permettono di tornare
indietro a prima dell’aggiornamento.

7. Strumenti per Backup and Recovery: RMAN
e User-Managed Backup
Per eseguire il backup e l’eventuale 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 all’SCN
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 l’utility export di Oracle. Tali dati sono conservati in
uno o più file binari (.dmp) e sono utilizzati per essere eventualmente reimportati
nel database con l’utility 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 all’ultimo 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.
Slide 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 l’applicazione
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 nell’eseguire un
Full la Domenica alle ore 22 e nei successive giorni della settimana, sempre alle ore
22, eseguire l’incrementale. 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 nell’eseguire un Full
la Domenica alle ore 22 e nei successive giorni della settimana, sempre alle ore 22,
eseguire l’incrementale. 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 dall’ultimo 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 dell’intervento:
 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:
 l’ultimo backup del controlfile e tutti i datafiles;
 tutti gli archivelog generati dopo l’ultimo 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 l’aggiornamento della
documentazione.
 Nel caso di ripristino del database… facciamo un backup del
database che stiamo sostituendo