Principale > Blog sul backup e sul ripristino > RMAN Database Backup and Recovery Essentials
Aggiornato 10th Marzo 2025, Rob Morrison

Contents

Un ambiente aziendale moderno non accetta la perdita di dati in nessuna forma, considerando come un evento del genere possa causare danni enormi all’azienda in questione, comprese perdite finanziarie, problemi di reputazione, ecc. Quando si tratta di amministratori di database Oracle, è praticamente necessario creare e implementare una solida strategia per le attività di backup e ripristino. Esistono diversi metodi di backup che Oracle stessa fornisce ai propri utenti, ma RMAN (Recovery Manager) è l’eccezione, una soluzione di backup e ripristino di punta con un approccio sofisticato ma semplice alla protezione dei dati.

L’obiettivo principale di questo articolo è esplorare le capacità di RMAN, compresi sia i concetti di base che i complessi scenari di ripristino. Dovrebbe essere un’ottima fonte di informazioni sia per i nuovi arrivati che per i professionisti esperti, con un’ampia varietà di passaggi pratici e approfondimenti pratici sulla salvaguardia dei database Oracle. Poiché le aziende continuano a lavorare con volumi di dati crescenti nel contesto di rigorosi obiettivi di tempo di ripristino, una corretta comprensione di RMAN diventa inestimabile per qualsiasi professionista che interagisce regolarmente con i database Oracle.

Il valore di RMAN per i database Oracle

La scelta di uno strumento di backup per un ambiente Oracle può essere impegnativa per molti amministratori di database. Recovery Manager di Oracle è una delle tante opzioni tra cui scegliere, ma il suo status complessivo di soluzione rivoluzionaria è rimasto invariato sin dalla sua introduzione in Oracle 8.

RMAN non è solo una soluzione di backup e ripristino, ma anche un approccio integrato alla protezione dei database in grado di affrontare molteplici sfide nella moderna gestione dei dati. Alcuni dei suoi vantaggi più preziosi sono il design incentrato sul ripristino, l’integrazione diretta con il database, le capacità di ottimizzazione delle risorse, la gestione intelligente dei backup e altro ancora.

La definizione di backup e ripristino RMAN

Recovery Manager è un’utilità specifica per Oracle in grado di comunicare direttamente con il motore del database. Il profondo livello di integrazione di RMAN con l’architettura Oracle consente di offrire operazioni a livello di blocco invece di semplici copie di file. È inoltre in grado di rilevare e saltare blocchi di dati non allocati o inutilizzati, il che tende a ridurre significativamente i tempi di backup e il consumo di spazio di archiviazione.

Gli scenari di ripristino sono quelli in cui RMAN dà il meglio di sé. È in grado di calcolare percorsi di ripristino ottimali durante i processi di ripristino dei dati, tenendo conto di tutti i backup incrementali, dei log archiviati e delle modifiche ai blocchi. Tale intelligenza a livello di software semplifica le operazioni di ripristino, eliminando completamente le congetture che in passato erano spesso associate alle operazioni di ripristino dei database.

Caratteristiche importanti di RMAN in Oracle

Come accennato in precedenza, RMAN non è solo una soluzione di backup e ripristino, ma può fornire una vasta gamma di strumenti che aiutano a risolvere i problemi di gestione dei database contemporanei. Ad esempio:

  • Il meccanismo di tracciamento delle modifiche ai blocchi fornisce una registrazione di tutti i blocchi modificati, migliorando notevolmente l’efficienza dei backup incrementali.
  • Le capacità di elaborazione parallela migliorano le prestazioni dell’hardware moderno utilizzando più thread CPU o GPU contemporaneamente.
  • Il trasporto di tablespace multipiattaforma migliora le capacità di migrazione del database di qualsiasi ambiente, aiutando le aziende a creare siti di disaster recovery su piattaforme diverse.

Questo è solo un piccolo esempio delle funzionalità non convenzionali di RMAN, ma dovrebbe essere sufficiente per mostrare quanto la soluzione vada oltre il tradizionale set di funzionalità di backup/ripristino.

Principali vantaggi dell’utilizzo di RMAN per la gestione dei database

Alcune delle funzioni di RMAN sono rivolte più agli ambienti di produzione e alla gestione dei database che alle operazioni di backup o ripristino, operando come un potente framework di protezione dei dati.

La capacità di rilevamento automatico dei danneggiamenti funge da sistema di allarme preventivo per potenziali problemi con il database. L’integrazione con Oracle Enterprise Management può offrire un controllo centralizzato su vari ambienti di backup.

La conformità normativa è un’altra area in cui RMAN può brillare più di quanto ci si aspetterebbe. Le dettagliate funzionalità di reportistica e registrazione del software possono aiutare le aziende a dimostrare come aderiscono ai vari requisiti di protezione dei dati. D’altra parte, la funzione di crittografia delle informazioni funge da salvaguardia per le informazioni sensibili durante e dopo le attività di backup.

Confronto tra RMAN e strumenti di backup di terze parti

Nonostante esistano diversi esempi di soluzioni di backup di terze parti con supporto per i backup Oracle, devono convivere con il fatto che RMAN avrà sempre una più profonda integrazione con l’ambiente.

Allo stesso tempo, RMAN è gratuito per tutti i possessori di una licenza per il database Oracle, il che lo rende un concorrente difficile da battere per la maggior parte delle soluzioni di backup di terze parti che hanno prezzi separati.

Ci saranno anche altre differenze tra RMAN e gli altri concorrenti, ma molte di queste riguardano funzionalità specifiche che sarebbe difficile presentare in modo conciso.

Integrazione di RMAN in Bacula Enterprise

Tra le soluzioni di backup di terze parti presenti sul mercato, Bacula Enterprise si distingue per la sua sofisticata integrazione con RMAN. Anziché sostituire le funzionalità native di RMAN, Bacula le integra aggiungendo le proprie caratteristiche di livello enterprise: pianificazione avanzata, gestione centralizzata, coordinamento del backup multipiattaforma e così via.

L’approccio di Bacula utilizza le competenze a livello di database di RMAN con una serie di funzionalità di protezione dell’infrastruttura più ampie. Tale strategia ibrida si dimostra preziosa in ambienti eterogenei in cui i database Oracle possono coesistere con altri ambienti mission-critical. La soluzione può mantenere l’efficienza del backup a livello di blocco di RMAN utilizzando al contempo i propri report completi, le politiche di backup unificate, la deduplicazione e molte altre funzionalità.

Svantaggi degni di nota di RMAN e quando prendere in considerazione alternative

Detto questo, RMAN ha anche una sua lista di limitazioni e problemi. Non può funzionare come soluzione di backup completa in ambienti eterogenei, per esempio, considerando la sua posizione come soluzione specifica per Oracle. In queste situazioni, le aziende che gestiscono più piattaforme di database contemporaneamente dovrebbero cercare un software che integri RMAN su questo fronte.

Le funzionalità di compressione e crittografia del backup tendono a causare cali di prestazioni del sistema se eseguite durante operazioni ad alta intensità di risorse, specialmente in ambienti in cui le risorse hardware sono già limitate. È qui che l’utilizzo di uno strumento di terze parti incentrato su operazioni leggere potrebbe essere più adatto, e gli snapshot a livello di storage possono anche aiutare a sfuggire ad alcuni dei problemi di prestazioni più eclatanti.

Tenendo presente tutto ciò, possiamo tranquillamente affermare che i fattori più importanti che contribuiscono alla decisione di utilizzare RMAN o una delle sue alternative sono:

  • Parametri e limitazioni dell’infrastruttura esistente.
  • Competenza tecnica disponibile.
  • Requisiti organizzativi specifici.

Una chiara comprensione di questi fattori può aiutare i gestori di database a prendere decisioni informate sulla strategia di backup.

Configurazione di RMAN per i database Oracle

Un’efficiente impostazione di RMAN richiede un’attenta considerazione di tutte le caratteristiche uniche di un ambiente di destinazione. Anche se le impostazioni predefinite di RMAN tendono a offrire una solida base, è comunque necessaria una configurazione esperta per diventare un potente framework di protezione dei dati e non solo una semplice utility di backup.

Alcuni dei maggiori contributi alla configurazione di RMAN sono l’allocazione delle risorse, la gestione dello storage e le opzioni di ripristino. Ogni sezione ha i propri parametri che devono essere considerati, come l’elaborazione parallela e la larghezza di banda I/O per l’allocazione delle risorse, le politiche di conservazione e le impostazioni di compressione per la gestione dello storage e la ridondanza del backup con l’automazione dei file di controllo nelle opzioni di ripristino.

Tutte queste decisioni di configurazione iniziale sono estremamente importanti per il successo a lungo termine di una strategia di backup. Con una pianificazione adeguata, le configurazioni RMAN dovrebbero ottimizzare l’utilizzo delle risorse di sistema, semplificare le operazioni di ripristino e garantire al contempo backup affidabili.

Impostazioni di configurazione standard di RMAN

La configurazione predefinita di RMAN è la combinazione della saggezza di Oracle su un tipico ambiente di database, accumulata nel corso degli anni di esperienza sul campo. Molte delle scelte predefinite danno priorità alla compatibilità rispetto all’ottimizzazione delle prestazioni, compresi i livelli di compressione di base, l’allocazione automatica dei canali, la destinazione del backup su disco e altro ancora.

Nella maggior parte dei casi queste opzioni di configurazione non sono perfettamente in linea con i requisiti di produzione, ma fanno sì che RMAN sia immediatamente funzionale dopo l’installazione. Pertanto, è necessario conoscere tutte le impostazioni predefinite per sapere su cosa dovrebbe lavorare un gestore di database nella maggior parte dei casi.

Un altro caso d’uso per la configurazione standard di RMAN è la rete di sicurezza, che funge da opzione di riserva stabile per qualsiasi impostazione personalizzata che potrebbe diventare problematica per un motivo o per l’altro. Questo particolare vantaggio è particolarmente importante quando si passa da una versione Oracle all’altra o si esegue una sorta di risoluzione dei problemi.

Implementazione della configurazione RMAN

Le configurazioni RMAN differiscono notevolmente da un caso all’altro, rendendo difficile fornire raccomandazioni precise. Possiamo quindi cercare di offrire raccomandazioni generali che dovrebbero adattarsi alla maggior parte dei casi.

La creazione di una configurazione personalizzata per RMAN richiede un approccio metodico all’intero processo. Il primo passo dovrebbe essere quello di stabilire un catalogo di ripristino, che è un archivio dedicato in grado di tracciare le impostazioni di configurazione e la cronologia dei backup. L’esistenza di un tale catalogo semplifica notevolmente la gestione tra diversi database e aiuta a creare strategie di backup più complesse.

La configurazione stessa viene eseguita utilizzando un’interfaccia a riga di comando o l’interfaccia di Enterprise Manager. Alcune delle decisioni più importanti da prendere in fase iniziale riguardano:

  • Configurazione dei canali per operazioni parallele.
  • Configurazione dell’algoritmo di compressione.
  • Definizione della destinazione e del formato del backup.
  • Configurazione della politica di conservazione a fini di manutenzione.

Molte aziende trascurano l’importanza della documentazione dei processi per le decisioni di configurazione, nonché la corretta motivazione di ogni azione. Una mappa di configurazione dettagliata può migliorare notevolmente la coerenza degli aggiornamenti del database, facilitando anche il trasferimento delle conoscenze da un membro del team all’altro. Inoltre, consigliamo di includere l’impatto di ogni modifica sulle prestazioni di backup e sulle capacità di ripristino, ove applicabile.

Aggiornamento dei parametri di configurazione RMAN

La gestione della configurazione in RMAN è immediata: il suo modello dinamico garantisce che tutte le modifiche abbiano effetto non appena vengono introdotte, senza alcun riavvio del database. Tale flessibilità consente di adattarsi rapidamente al campo in continua evoluzione dei requisiti di backup o alle esigenze di prestazioni dell’azienda.

Lo strumento principale per la modifica dei parametri è sempre CONFIGURE: può essere utilizzato per modificare le impostazioni di crittografia, regolare le dimensioni dei pezzi di backup e altro ancora. Tutte le modifiche apportate in questo modo persistono in tutte le sessioni RMAN fino a quando non vengono modificate.

Anche procedure di test adeguate sarebbero una forte raccomandazione per qualsiasi ambiente live, creando un ambiente di staging per risolvere eventuali problemi o domande sulle opzioni di configurazione. Un ambiente di staging come questo dovrebbe aiutare ad analizzare l’impatto di ogni cambiamento sul consumo di storage, sulle prestazioni del sistema, sulle finestre di backup e altro ancora. Alcune aziende creano persino una matrice di test che può convalidare diverse combinazioni di configurazione rispetto ai requisiti di backup della propria azienda.

Integrazione di RMAN con Oracle Enterprise Manager

L’Enterprise Manager di cui abbiamo parlato in precedenza può aiutare a trasformare i processi di amministrazione RMAN da un complesso esercizio a riga di comando a un’esperienza di gestione molto più visiva, preferita dagli utenti meno esperti. Questa particolare integrazione offre strumenti grafici per il monitoraggio dei backup, le operazioni di ripristino, la gestione della configurazione e altro ancora.

Tuttavia, il vero vantaggio di Enterprise Manager si manifesta negli ambienti aziendali, aiutando le aziende a ottenere configurazioni RMAN coerenti su molti database. Questo particolare livello di standardizzazione è reso possibile utilizzando varie politiche e modelli che possono ancora essere perfezionati per includere eventuali requisiti specifici del database.

Anche le funzionalità di monitoraggio di Enterprise Manager sono di per sé impressionanti, estendendosi oltre il semplice reporting sullo stato dei backup per fornire analisi predittive e tracciamento delle risorse, tra le altre caratteristiche. Può persino semplificare il reporting di conformità grazie alla capacità di offrire audit trail dettagliati per qualsiasi operazione di backup o modifica della configurazione, rendendo Enterprise Manager di Oracle estremamente utile per la maggior parte delle aziende.

Configurazione di RMAN per database multi-tenant

Negli ambienti Oracle contemporanei che utilizzano l’architettura di database multi-tenant è possibile introdurre considerazioni di backup uniche. La configurazione di RMAN in tali ambienti sarà diversa dagli altri esempi, richiedendo un livello competente di conoscenza dei database container e dei database collegabili (rispettivamente CDB e PDB), nonché di come sono correlati tra loro.

I Container Databases sono stati introdotti in Oracle 12c. Ogni container database è un singolo database fisico che include un numero di database virtuali (chiamati container) che si comportano proprio come un normale database. Poiché i container possono essere facilmente “collegati” o “scollegati”, vengono anche chiamati Pluggable Databases.

Qualsiasi strategia di backup in un ambiente multi-tenant dovrebbe tenere conto dei requisiti di ripristino individuali del PDB e della coerenza a livello di contenitore. Fortunatamente, le capacità di multi-tenant awareness di RMAN possono aiutare a consentire operazioni di backup efficienti in grado di rispettare i confini logici tra diversi PDB senza compromettere l’integrità complessiva del backup.

Qualsiasi ambiente multi-tenant sarà molto più complesso di uno normale, e richiederà un’attenta considerazione sia per l’allocazione delle risorse che per la pianificazione dei backup. L’implementazione di pianificazioni di backup scaglionate per diversi PDB aiuterebbe a gestire il carico di sistema in modo efficiente. Allo stesso tempo, dovrebbero essere sviluppate in anticipo chiare procedure per il trasferimento di PDB tra piattaforme e il ripristino di PDB in un punto nel tempo, poiché la maggior parte di questi compiti richiede innanzitutto diverse impostazioni di configurazione di RMAN.

Una configurazione RMAN di successo è un delicato equilibrio tra obiettivi di ripristino a lungo termine e necessità di backup immediato. Il processo di configurazione iniziale potrebbe sembrare difficile all’inizio, ma l’investimento in una configurazione adeguata ripaga in qualsiasi scenario di ripristino critico. Le configurazioni RMAN attuali dovrebbero essere riviste e adattate regolarmente per soddisfare le mutevoli esigenze aziendali.

Migliori pratiche per l’esecuzione dei processi di backup RMAN

Una corretta configurazione tecnica è solo uno dei tanti elementi che contribuiscono al successo dell’implementazione di RMAN. Lo scenario migliore include lo sviluppo di una strategia completa in grado di allinearsi agli obiettivi di ripristino di un’organizzazione, contribuendo al contempo agli sforzi di ottimizzazione dell’utilizzo delle risorse. Alcune pratiche si sono dimostrate efficaci in diversi ambienti di database, tra cui:

  • La consapevolezza delle risorse mira a trovare un equilibrio tra l’impatto sulle prestazioni del sistema e la completezza del backup.
  • La disciplina della documentazione comprende registrazioni dettagliate di tutte le procedure o strategie di backup.
  • La mentalità del ripristino al primo posto che influenza i processi di backup da progettare intorno a scenari di ripristino futuri e non solo al completamento del backup.
  • Metodologia di monitoraggio con convalida proattiva del successo del backup.

L’obiettivo principale di questa sezione sarà quello di illustrare le diverse best practice per l’implementazione del backup RMAN.

Creare una strategia di backup affidabile

Una solida strategia di backup non sarebbe possibile senza comprendere gli RPO (Recovery Point Objective) e gli RTO (Recovery Time Objective) della propria azienda. È molto difficile sottovalutare l’importanza di questi parametri, che influenzano ogni singolo aspetto di un approccio di backup, dalle politiche di conservazione alla pianificazione e tutto ciò che sta in mezzo.

Iniziare con la mappatura dei livelli di criticità del database è un buon modo per avvicinarsi alla creazione di una strategia di backup. Le diverse frequenze di backup e i periodi di conservazione dovrebbero essere attribuiti a diversi tipi di informazioni: schemi, spazi tabelle o PDB. Un tale approccio richiede spesso l’uso di una strategia di backup a più livelli che offra backup più frequenti per i dati mission-critical, mentre altre informazioni non così importanti possono essere sottoposte a backup con una pianificazione un po’ più rilassata.

La gestione del cambiamento è un altro aspetto importante di una strategia di backup. Qualsiasi procedura di backup dovrebbe essere in grado di adattarsi alla crescita complessiva del database, nonché all’evoluzione dei requisiti di ripristino, ai cambiamenti dell’orario di lavoro e altro ancora. Si raccomanda vivamente di effettuare revisioni strategiche regolari per garantire che l’attuale approccio di backup sia in linea con le esigenze aziendali necessarie, incorporando al contempo nuove caratteristiche e funzionalità di RMAN.

Scegliere un tipo di backup per RMAN

Esistono due tipi principali di backup utilizzati da RMAN: completo e incrementale. I vantaggi e gli svantaggi di entrambi sono ben noti nel settore dei backup, con backup completi che offrono una copertura più completa delle informazioni che è anche ad alta intensità di archiviazione, mentre backup incrementali possono copiare solo i blocchi di dati che sono stati modificati dall’ultimo backup di qualsiasi momento, semplificando i requisiti di archiviazione e prestazioni, ma rendendo qualsiasi processo di ripristino significativamente più impegnativo. In questo contesto vengono anche menzionati di tanto in tanto i backup differenziali, che forniscono un ambiente di acquisizione delle modifiche simile a un backup incrementale senza la necessità di raccogliere ogni singola istanza di un backup di questo tipo per un singolo processo di ripristino.

Va notato che l’implementazione di un backup incrementale da parte di RMAN non si limita a monitorare semplici modifiche a livello di file, ma utilizza il tracciamento delle modifiche a blocchi per ridurre al minimo i potenziali requisiti di archiviazione e i tempi di backup.

Ecco un approccio che dovrebbe funzionare con sufficiente competenza nella maggior parte dei database Oracle:

  • Backup incrementali di livello 0: linea di base della funzionalità, in un certo senso equivalente a un backup completo.
  • Backup incrementali cumulativi di livello 1: acquisizione di tutte le modifiche apportate dall’ultimo backup di livello 0.
  • Modifiche differenziali di livello 1: registrazione di tutte le variazioni apportate dall’ultimo backup incrementale.

Come per molti altri aspetti dei processi di backup, la soluzione migliore è cercare di trovare un equilibrio tra diversi tipi di backup all’interno di un’unica strategia, con modelli di backup facilmente adattabili quando è necessario.

Utilizzare i tag per la gestione dei backup

Il sistema di tagging di RMAN è un potente meccanismo per la gestione del ciclo di vita e l’organizzazione dei backup. Un’attenta implementazione dei tag può consentire di eseguire complesse sequenze di selezione dei backup durante qualsiasi operazione di ripristino. In questo caso è necessaria una nomenclatura coerente per l’assegnazione dei tag, che si allinei alla strategia di backup, con elementi preziosi come il tipo di backup, l’ambiente, lo scopo, le condizioni speciali e molti altri.

I tag sono praticamente inestimabili negli scenari di ripristino point-in-time o se i set di backup devono essere gestiti su più database. Una corretta strategia di assegnazione dei tag può migliorare i processi di gestione dei backup, riducendo al contempo il rischio di errori dell’operatore in ambienti di ripristino stressanti.

Implementare la compressione per ottimizzare l’archiviazione dei backup RMAN

La compressione è un altro strumento molto diffuso, comunemente menzionato nel contesto dell’ottimizzazione dello storage in diversi ambienti, compresi i database. RMAN può fornire diversi algoritmi di compressione tra cui scegliere, offrendo diversi livelli di risparmio di spazio di archiviazione al costo di un maggiore utilizzo della CPU. Selezionare il livello di compressione appropriato per il proprio ambiente specifico è il passo più difficile.

I moderni ambienti Oracle possono offrire l’Advanced Compression Option, una funzione che offre tassi di compressione superiori con prestazioni di backup accettabili. Tuttavia, ciò non rende obsolete le capacità di RMAN, soprattutto in ambienti che tengono conto dei costi totali delle licenze.

Alcune aziende potrebbero trarre maggiori vantaggi dall’utilizzo di un approccio ibrido che utilizza diversi gradi di compressione per diverse pianificazioni o tipi di dati. I backup dei file di dati funzionerebbero meglio con una compressione moderata come equilibrio tra i requisiti della finestra di backup e il risparmio di spazio di archiviazione, mentre i backup dei log di archivio sono tipicamente sequenziali in lettura e possono essere compressi più dei dati normali con pochi inconvenienti.

È inoltre necessario tenere in considerazione le attuali capacità dell’infrastruttura aziendale, soprattutto se il sistema dispone già di funzionalità di compressione integrate. Si consiglia di eseguire test approfonditi per trovare la combinazione più adatta di RMAN e compressione a livello di archiviazione in ogni caso specifico.

Esecuzione di backup di database utilizzando RMAN

Per eseguire correttamente i backup del database con RMAN è necessaria una combinazione di precisione tecnica e consapevolezza operativa. Le sequenze di comandi potrebbero sembrare semplici all’inizio, ma dovrebbero essere create con una corretta comprensione di tutti i tipi di sfumature nel comportamento di RMAN e di come interagisce con gli ambienti di database.

L’implementazione dell’operazione di backup si basa solitamente su quattro fattori principali: esigenze di verifica, ottimizzazioni delle prestazioni, requisiti di monitoraggio e coordinamento delle risorse. Tutti questi fattori contribuiscono alla corretta esecuzione dei comandi di backup e ripristino di RMAN.

Backup del database con i comandi RMAN

RMAN è noto per la flessibilità della sintassi dei comandi. Questi comandi possono adattarsi a diversi requisiti di backup mantenendo modelli di sintassi coerenti, sia che si tratti di backup completi del database o di strategie incrementali complesse.

Il comando BACKUP DATABASE è la pietra angolare di qualsiasi processo di esecuzione del backup, ma il punto cruciale della personalizzazione sta nel lavorare sui modificatori di comando e nel comprenderne le implicazioni. Ad esempio, possiamo utilizzare un singolo comando per un approccio di backup avanzato:

BACKUP AS COMPRESSED BACKUPSET
TAG ‘FULL_BACKUP_&YYYYMMDD’
DATABASE PLUS ARCHIVELOG
DELETE INPUT;
Ciascuno di questi parametri ha il proprio scopo in un’attività di backup.

  • La compressione del backup ottimizza l’utilizzo totale dello spazio di archiviazione.
  • La specifica dei tag consente una chiara identificazione dei comandi per un uso futuro.
  • Gli archivi dei log garantiscono la recuperabilità dei dati.
  • Il comando Delete input aiuta nella gestione automatica della conservazione dei log di archivio.

La padronanza della struttura dei comandi in RMAN consente all’utente finale di gestire vari scenari complessi: backup multisection, creazione di copie di immagini, backup granulari, ecc. Consigliamo vivamente di documentare accuratamente i comandi più comunemente usati con annotazioni dettagliate, sia per comodità personale che per il trasferimento delle conoscenze.

Scelta del database di destinazione per l’operazione di backup

RMAN può essere molto flessibile quando si tratta di scegliere i database di destinazione, una caratteristica preziosa negli ambienti aziendali. Una corretta specificazione della destinazione è fondamentale per il successo del backup, indipendentemente dal tipo di processo di backup.

Detto questo, la fase di connessione dovrebbe considerare tutti i diversi metodi di autenticazione e i privilegi necessari. L’autenticazione lato sistema operativo può aiutare a semplificare lo scripting, e l’autenticazione tramite file di password potrebbe essere più vicina alle politiche di sicurezza dell’azienda.

Nella maggior parte dei casi si raccomanda un’archiviazione sicura delle password esterne, realizzata appositamente per le operazioni automatizzate, in modo da semplificare la gestione del database mantenendone l’efficienza operativa. Ecco come può essere formata:

CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘+DATA/snapcf_&DBNAME…f’;

Scegliere tra disco e nastro come supporto di backup

La maggior parte delle moderne strategie di backup utilizzano livelli di archiviazione per diversi tipi di dati. RMAN eccelle nella gestione di ambienti così diversi grazie alla capacità di configurazione dei canali. Due degli ambienti di archiviazione legacy più comuni che possiamo usare come esempi sono il disco e il nastro.

  • I backup su disco offrono un ripristino rapido con potenziali problemi di ridondanza e archiviazione.
  • I backup su nastro sono ottimi per la conservazione a lungo termine a basso costo, ma potrebbero non essere particolarmente veloci o convenienti per le informazioni rilevanti.

Nella maggior parte dei casi è possibile anche un approccio ibrido, con molte opzioni di configurazione da considerare. Ad esempio, ecco come possiamo configurare il numero di processi in cui ogni tipo di backup può lavorare contemporaneamente:

CONFIGURE DEVICE TYPE DISK PARALLELISM 4
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 2
Come in molti altri esempi, la chiave qui è conoscere i limiti e le capacità della tua infrastruttura attuale. Un aumento del parallelismo potrebbe giovare ai sistemi a disco ad alte prestazioni, mentre il nastro ha un certo limite di lettura/scrittura, rendendo necessaria un’attenta messa a punto delle prestazioni per prevenire potenziali problemi con lo streaming.

Pianificazione del backup con RMAN

L’automazione può aiutare a trasformare le attività di backup manuali in processi molto più gestibili e ripetibili. Anche se RMAN non dispone di funzionalità di pianificazione integrate, può essere facilmente integrato con le funzionalità del sistema operativo o con strumenti di pianificazione aziendali per ottenere risultati simili.

Un quadro di pianificazione completo per RMAN dovrebbe tenere conto dei vincoli di larghezza di banda della rete, della disponibilità del sistema di archiviazione, dei modelli di carico di lavoro del database, delle finestre di manutenzione e altro ancora.

Lo sviluppo di script è una parte sostanziale nell’ambito della gestione dell’automazione. Gli script personalizzati possono essere utilizzati come strumenti di automazione se altri mezzi non sono disponibili o non sono in grado di ottenere i risultati necessari. Possono includere praticamente qualsiasi cosa, che si tratti di meccanismi di registrazione, gestione degli errori, notifiche di script di backup, ecc. Anche in questo caso vale la raccomandazione di una documentazione completa e dettagliata sull’argomento, che richiede un adeguato controllo delle versioni e il monitoraggio di tutte le decisioni di pianificazione (con le relative motivazioni).

Risoluzione degli errori durante l’esecuzione del backup RMAN

Anche le attività di backup meglio pianificate incontrano regolarmente dei problemi. Sviluppare un approccio sistematico alla risoluzione dei problemi, una combinazione delle capacità diagnostiche integrate di RMAN e un monitoraggio più ampio del sistema, è la chiave sicura per il successo.

Un buon primo passo in questo senso sarebbe cercare di comprendere meglio i livelli di output dei messaggi di RMAN. Ecco come configurare i dettagli di registrazione appropriati in un backup RMAN:

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘/backup/%F’;
CONFIGURE DIAGNOSTIC DESTINATION TO ‘/diag/rman’;
Sarebbe inoltre opportuno sviluppare un manuale di risoluzione dei problemi per classificare i problemi più comuni: problemi di stato del database, problemi di archiviazione, vincoli di risorse, problemi relativi alla rete e altro ancora. Il monitoraggio proattivo, d’altra parte, può aiutare a individuare e risolvere la maggior parte dei problemi comuni prima che possano avere un impatto sui processi di backup o ripristino.

Il successo nell’esecuzione del backup è una combinazione di consapevolezza operativa e competenza tecnica. Molte opportunità di ottimizzazione possono essere trovate utilizzando revisioni e analisi regolari, e lo stesso si può dire per molte potenziali problematiche in grado di interrompere la recuperabilità.

Ripristino e recupero per database Oracle con RMAN

Il vero valore di qualsiasi strategia di backup RMAN emerge solo in situazioni in cui si verifica un qualche tipo di errore nel database. Per il successo della maggior parte delle operazioni di ripristino è necessaria una combinazione di calma nel prendere decisioni sotto pressione e competenza tecnica. Situazioni potenzialmente catastrofiche possono essere trasformate in sfide tecniche gestibili con una corretta comprensione di ciò che RMAN può offrire in termini di recupero dei dati.

Guida al ripristino del database

Qualsiasi processo di ripristino dovrebbe iniziare con una valutazione dei danni, seguita dalla selezione di una strategia di recupero. RMAN può anche identificare i set di backup necessari e ottimizzare automaticamente la sequenza di ripristino, dimostrando la sua intelligenza come soluzione di backup e ripristino.

Il modello più comune di ripristino dei dati include i seguenti comandi:

STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN;
Detto questo, molte situazioni reali sono solitamente molto più sfumate e richiedono un approccio completamente diverso in ogni caso. Tenendo presente questo, possiamo consigliare la creazione di un albero decisionale che possa coprire diversi scenari di errore, tra cui:

  • Problemi con il file di controllo
  • Perdita di tablespace o file di dati
  • Lacune nel registro di archivio
  • Errore completo del database
  • Corruzione temporanea dei file

Tutte le procedure e i piani di ripristino devono essere accompagnati da istruzioni chiare e dettagliate con comandi specifici, risultati attesi e punti decisionali in cui potrebbe essere necessario che un operatore offra il proprio giudizio nel processo decisionale.

Ripristino dei file di dati con RMAN

Il ripristino dei file di dati è considerato lo scenario di ripristino più comune per RMAN poiché i guasti parziali del database, e i successivi ripristini, sono molto più comuni dei crash completi del database. Le capacità di recupero a livello di blocco che RMAN può fornire consentono di eseguire operazioni di recupero mirate nel modo seguente:

RECOVER DATAFILE ‘/path/to/datafile’ UNTIL TIME ‘YYYY-MM-DD:HH24:MI:SS’;
Il rapporto tra disponibilità del database e recupero dei file di dati è molto importante in questi scenari. Alcune operazioni di ripristino possono essere eseguite anche quando il database rimane parzialmente disponibile, al fine di ridurre al minimo l’impatto sul business, che si tratti del ripristino di spazi tabella non critici, del ripristino parallelo di più file di dati, del ripristino di blocchi online dopo corruzioni minori, ecc.

Recupero blocco media in RMAN

Il recupero blocco media è una delle funzionalità più complesse di RMAN. Anziché recuperare interi file di dati, BMR può concentrarsi su blocchi specifici che sono stati danneggiati o modificati in altro modo. Questo approccio consente di ridurre i tempi di recupero per problemi di danneggiamento localizzati, ma richiede anche un’attenta considerazione dei seguenti fattori:

  • Disponibilità del blocco di backup
  • Impatto sul carico di lavoro del database
  • Metodi di identificazione del danneggiamento dei blocchi
  • Implicazioni sui tempi di recupero

Dovrebbero essere implementati anche controlli regolari di corruzione come parte della routine di manutenzione di backup e ripristino:

BACKUP VALIDATE CHECK LOGICAL DATABASE;
Un approccio così proattivo richiede l’identificazione di potenziali problemi di blocco prima che possano avere un impatto sulle operazioni critiche. In questo modo, la risoluzione dei problemi viene trasformata in un ripristino programmato invece che in una risposta di emergenza dell’ultimo minuto.

Pianificazione del disaster recovery con RMAN

Il disaster recovery non è solo una procedura tecnica di ripristino, ma è un elemento sostanziale della pianificazione della continuità operativa. RMAN offre le basi tecniche per il disaster recovery, ma per essere efficace richiede anche una preparazione completa e test regolari.

Gli elementi più importanti del disaster recovery nel contesto di RMAN sono:

  • Convalida dell’RTO.
  • Conferma dell’RPO.
  • Pianificazione della capacità di archiviazione.
  • Requisiti di larghezza di banda della rete.
  • Preparazione e manutenzione del sito di ripristino.

Le capacità di ripristino multipiattaforma di RMAN si rivelano particolarmente utili negli scenari di disaster recovery in cui il sito di ripristino di destinazione potrebbe funzionare utilizzando un sistema operativo o hardware diverso. Tutti questi scenari dovrebbero essere testati regolarmente utilizzando comandi specifici, come ad esempio:

CONVERT DATABASE NEW DATABASE ‘RECOVERY_DB’
TRANSPORT SCRIPT ‘/tmp/transport_script.sql’
TO PLATFORM ‘Linux x86 64-bit’;

Convalida del backup prima del ripristino

La convalida del backup in situazioni di ripristino non è solo una pratica consigliata, ma una necessità fondamentale che elimina la possibilità di riscontrare problemi di backup durante un momento di crisi. Una strategia di convalida completa può essere costruita sulla seguente struttura:

RESTORE DATABASE VALIDATE;
RECOVER DATABASE VALIDATE;
Entrambi questi comandi possono essere utilizzati per eseguire un’ampia verifica senza effettivi processi di ripristino dei dati, verificando i checksum dei blocchi, la fattibilità della sequenza di ripristino, la coerenza dei metadati, la completezza del set di backup e altro ancora.

Gli sforzi di convalida regolari dovrebbero includere anche altri tipi di comandi simili: raccolta di metriche delle prestazioni, test casuali del set di backup, aggiornamenti della documentazione e simulazioni complete di ripristino.

Una combinazione di esecuzione tecnica e comunicazione efficace è il modo migliore per affrontare l’implementazione di RMAN. Le parti interessate dovrebbero essere a conoscenza di tutti i progressi del ripristino, nonché di eventuali potenziali difficoltà o dei tempi previsti per la risoluzione dei problemi. Ogni attività di ripristino deve essere documentata in modo completo, coprendo tutte le questioni impreviste e il modo in cui sono state risolte, in modo che l’organizzazione possa costruire una base di conoscenze per un uso futuro.

I prossimi passi dopo l’implementazione di RMAN

L’implementazione di successo di RMAN non è nemmeno la fine del “viaggio” complessivo in un ambiente di backup e ripristino. Quando si tratta di attività di protezione dei database, l’implementazione di successo è solo l’inizio. L’attenzione continua al monitoraggio, alla manutenzione e all’ottimizzazione sono tutti elementi vitali per qualsiasi implementazione competente di RMAN, con conseguenti innumerevoli vantaggi potenziali: miglioramenti delle prestazioni, miglioramenti della gestione dello storage, adozione di nuove tecnologie, migliore perfezionamento dei processi, ecc.

Monitoraggio e manutenzione del backup RMAN

Un efficace monitoraggio dei backup non consiste semplicemente nel verificare se un processo di backup ha avuto successo o meno. Un monitoraggio completo deve coprire contemporaneamente le metriche di consumo dello storage, le tendenze delle prestazioni e i modelli di utilizzo delle risorse. Ecco un esempio di come queste metriche operative di base potrebbero essere implementate:

SELECT 
OPERATION, 
STATUS, 
START_TIME, 
END_TIME, 
INPUT_BYTES, 
OUTPUT_BYTES,
COMPRESSION_RATIO
FROM V$RMAN_STATUS 
WHERE START_TIME > SYSDATE – 7;
È importante guardare oltre le metriche operative standard per vedere i picchi di utilizzo delle risorse, le tendenze della durata dei backup, le variazioni dei tempi di ripristino, i modelli di efficienza della compressione e la crescita del consumo di spazio di archiviazione. In realtà non è così raro che vengano implementate soluzioni di monitoraggio personalizzate per i database, combinando la funzionalità di reporting integrata di RMAN con una gamma più ampia di metriche di sistema.

Implementazione del Recovery Catalog di RMAN per una migliore gestione

Recovery Catalog è una funzionalità di RMAN, uno schema che viene creato in un database separato, in grado di memorizzare metadati su altri database Oracle per migliorare i processi di backup e ripristino in diversi modi. L’utilizzo di RMAN Recovery Catalog introduce una serie di funzionalità avanzate per gli ambienti aziendali, quali:

  • Protezione avanzata dei metadati
  • Conservazione estesa della cronologia dei backup
  • Reportistica dettagliata dei backup
  • Gestione dei backup tra database
  • Script memorizzati sofisticati e altro ancora.

Tuttavia, la sua implementazione richiede un’attenta pianificazione, con comandi come questi che rappresentano l’approccio più superficiale all’implementazione del catalogo:

CREATE CATALOG RMAN;
REGISTER DATABASE;
RESYNC CATALOG;
Il vero potenziale del Recovery Catalog si manifesta quando viene combinato con strategie di backup aziendali, può trasformare gli script memorizzati in procedure standardizzate con un’esecuzione coerente su molti database senza perdere la flessibilità per ogni database specifico.

La tecnologia Flashback e il suo valore in RMAN

La tecnologia Flashback di Oracle può integrare le tradizionali funzioni di backup e ripristino di RMAN, consentendo un rapido ripristino dagli errori logici senza la necessità di eseguire un ripristino completo del database. Può anche essere utilizzata per creare una strategia di ripristino a più livelli per risolvere gli errori logici su diversi livelli:

  • Flashback Database offre un ripristino temporizzato a livello di sistema.
  • Flashback Table fornisce un ripristino mirato degli oggetti.
  • Flashback Drop si occupa della cancellazione accidentale degli oggetti.
  • Flashback Query viene utilizzato per scopi di indagine sui dati.

La sinergia tra i due offre una copertura completa dei dati in modi diversi. Mentre RMAN gestisce il danneggiamento fisico e il disaster recovery, Flashback può affrontare gli errori logici e i risultati degli errori commessi dagli utenti finali. La combinazione di approcci riduce al minimo il tempo totale di ripristino e ci sono molte opzioni di personalizzazione per adattarsi a diversi scenari di ripristino.

Conclusione

Come abbiamo visto in questo articolo, RMAN è la pietra angolare delle capacità di protezione dei database Oracle, un solido framework per una moltitudine di operazioni di backup e ripristino. RMAN offre gli strumenti necessari per proteggere le risorse di dati critici delle vostre organizzazioni, dalla configurazione iniziale fino agli scenari di ripristino avanzati.

Tuttavia, il successo con RMAN richiede più di una semplice competenza tecnica: richiede un approccio strategico, una combinazione di test regolari, una pianificazione ponderata, un monitoraggio continuo, investimenti nella conoscenza del team e la capacità di adattarsi alle esigenze aziendali in evoluzione.

Tutti gli utenti Oracle dovrebbero considerare come le tecnologie emergenti e le mutevoli esigenze aziendali potrebbero influenzare le attuali implementazioni di RMAN. Si raccomanda di tenere d’occhio i vari sviluppi nell’integrazione del cloud, nell’automazione, nelle funzionalità di sicurezza avanzate, nell’ottimizzazione delle prestazioni e così via.

Soprattutto, dovrebbe essere ormai ovvio che l’implementazione di RMAN non consiste nel completare il processo in questione, ma nel creare una base e migliorarla continuamente nel tempo. Aggiornare la configurazione dell’implementazione esistente e aggiungere nuove funzionalità, ove possibile, è il modo migliore per affrontare qualsiasi attività di implementazione di RMAN nei database Oracle.

Domande frequenti

Quali sono le differenze tra RMAN e Data Pump nei backup dei database Oracle?

Sebbene entrambi gli strumenti supportino tecnicamente le operazioni di protezione dei dati, i loro scopi sono completamente diversi. RMAN si concentra molto di più sul backup fisico e sul ripristino a livello di blocco del database, offrendo una serie completa di funzionalità di disaster recovery. Data Pump, invece, si occupa più di backup logici, essendo un ottimo strumento per la migrazione dei dati e l’aggiornamento delle versioni con movimenti selettivi dei dati.

È possibile eseguire migrazioni di database multipiattaforma con RMAN?

Il comando CONVERT DATABASE di RMAN supporta la migrazione di database tra piattaforme diverse. Consente agli utenti di spostare database tra diverse architetture hardware o sistemi operativi con conversione automatica del formato dei dati. Va notato, tuttavia, che sia la piattaforma di destinazione che quella di origine devono essere esplicitamente supportate da Oracle e che ci sono ancora alcune limitazioni a questo processo che potrebbero influenzare le versioni del database o i set di caratteri in determinate situazioni.

RMAN è in grado di gestire backup per database Oracle distribuiti su larga scala?

La gestione di ambienti di database su larga scala utilizzando l’elaborazione parallela, la copia proxy o i backup section size è la specialità di RMAN. Può anche coordinare i backup tra cluster RAC per ambienti distribuiti, gestire database container multi-tenant e gestire configurazioni Data Guard in modo efficiente. La parte importante qui è la corretta configurazione dei canali e l’allocazione delle risorse al fine di ottimizzare le prestazioni di backup in un’infrastruttura distribuita.

RMAN è adatto per lavorare su backup di database Oracle basati su cloud?

RMAN supporta pienamente le strategie di backup basate su cloud sia per i database che già funzionano nel cloud sia per i database che utilizzano lo storage cloud come destinazione di backup. Utilizza una combinazione di funzionalità native di integrazione cloud e il modulo di backup cloud di Oracle per scrivere direttamente sui servizi di storage cloud, fornendo al contempo funzionalità di backup e ripristino di base.

Informazioni sull'autore
Rob Morrison
Rob Morrison è il direttore marketing di Bacula Systems. Ha iniziato la sua carriera nel marketing IT con Silicon Graphics in Svizzera, ottenendo ottimi risultati in vari ruoli di gestione del marketing per quasi 10 anni. Nei 10 anni successivi, Rob ha ricoperto anche diverse posizioni di gestione del marketing in JBoss, Red Hat e Pentaho, assicurando la crescita della quota di mercato di queste note aziende. Si è laureato all'Università di Plymouth e ha conseguito una laurea ad honorem in Digital Media and Communications e ha completato un programma di studi all'estero.
Lascia un commento

Il suo indirizzo e-mail non sarà pubblicato. I campi obbligatori sono contrassegnati da *