Skip to main content
Enterprise applications
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Backup in linea

Collaboratori jfsinmsp

Per proteggere e ripristinare un database Oracle in modalità backup sono richiesti due set di dati. Si noti che questa non è l'unica opzione di backup di Oracle, ma è la più comune.

  • Un'istantanea dei file di dati in modalità di backup

  • I registri di archivio creati mentre i file di dati erano in modalità backup

Se è richiesto il recupero completo, comprese tutte le transazioni impegnate, è necessario un terzo elemento:

  • Una serie di registri di ripristino correnti

Esistono diversi modi per eseguire il ripristino di un backup online. Molti clienti ripristinano le snapshot utilizzando l'interfaccia CLI di ONTAP e quindi Oracle RMAN o sqlplus per completare il ripristino. Ciò è particolarmente comune negli ambienti di produzione di grandi dimensioni, in cui la probabilità e la frequenza dei ripristini dei database sono estremamente ridotte e qualsiasi procedura di ripristino viene gestita da un DBA esperto. Per un'automazione completa, soluzioni come NetApp SnapCenter includono un plug-in Oracle con interfacce sia a riga di comando che grafiche.

Alcuni clienti su larga scala hanno adottato un approccio più semplice configurando script di base sugli host per impostare i database in modalità di backup in un momento specifico in preparazione a uno snapshot pianificato. Ad esempio, pianificare il comando alter database begin backup alle 23:58, alter database end backup alle 00:02, quindi programmare le snapshot direttamente sul sistema storage a mezzanotte. Il risultato è una strategia di backup semplice e altamente scalabile che non richiede licenze o software esterni.

Layout dei dati

La configurazione più semplice prevede l'isolamento dei file di dati in uno o più volumi dedicati, LUN o namespace NVMe. Le risorse di storage non devono essere contaminate da altri tipi di file. Questo per garantire che i file di dati possano essere ripristinati rapidamente tramite un'operazione di SnapRestore senza distruggere un importante redo log, controlfile o archive log.

SAN presenta requisiti simili per l'isolamento dei datafile all'interno di risorse dedicate. Con un sistema operativo come Microsoft Windows che utilizza AFF storage, un singolo volume può contenere più LUN di datafile, ciascuno con un file system NTFS. Con altri sistemi operativi, in genere è presente un volume manager logico. Ad esempio, con Oracle ASM, l'opzione più semplice sarebbe quella di confinare i LUN di un gruppo di dischi ASM in un singolo volume che può essere sottoposto a backup e ripristinato come un'unità. Se sono necessari volumi aggiuntivi per motivi di prestazioni o gestione della capacità, la creazione di un gruppo di dischi aggiuntivo sul nuovo volume semplifica la gestione.

ASA non dispone dell'astrazione a livello di volume che, su un sistema AFF, può ospitare più LUN. Al suo posto ASA utilizza i gruppi di coerenza. In molti casi, un singolo LUN o namespace NVMe può soddisfare i requisiti di gestione e prestazioni per un database. Se sono necessari più LUN o namespace, è possibile aggiungere risorse aggiuntive e raggrupparle in un gruppo di coerenza che diventa il container di datafile.

Se queste linee guida vengono seguite, è possibile programmare gli snapshot direttamente sul sistema storage.

Attenzione: verificare che l'ASM spfile e. passwd i file non si trovano nel gruppo di dischi che ospita i file di dati. Ciò interferisce con la capacità di ripristinare selettivamente i dati e solo i file di dati.

Procedura di ripristino locale: NFS

Questa procedura può essere gestita manualmente o tramite un'applicazione come SnapCenter. La procedura di base è la seguente:

  1. Arrestare il database.

  2. Ripristina i volumi NFS dei datafile allo snapshot immediatamente precedente al punto di ripristino desiderato.

  3. Riprodurre i log di archivio nel punto desiderato.

  4. Se si desidera completare il ripristino, riprodurre i registri di ripristino correnti.

Questa procedura presuppone che i log di archivio desiderati siano ancora presenti nel file system attivo. In caso contrario, è necessario ripristinare i log di archivio oppure è possibile indirizzare rman/sqlplus ai dati nella directory snapshot.

Inoltre, per i database di dimensioni inferiori, i file di dati possono essere recuperati da un utente finale direttamente da .snapshot directory senza l'assistenza di tool di automazione o amministratori dello storage per eseguire una snaprestore comando.

Procedura di ripristino locale: SAN

Questa procedura può essere gestita manualmente o tramite un'applicazione come SnapCenter. La procedura di base è la seguente:

  1. Arrestare il database.

  2. Chiudere i gruppi di dischi che ospitano i file di dati. La procedura varia a seconda del volume manager logico scelto. Con ASM, il processo richiede lo smontaggio del gruppo di dischi. Con Linux, i file system devono essere smontati e i volumi logici e i gruppi di volumi devono essere disattivati. L'obiettivo è quello di interrompere tutti gli aggiornamenti del gruppo di volumi di destinazione da ripristinare.

  3. Ripristina le LUN che ospitano i gruppi di dischi dei datafile allo snapshot immediatamente precedente al point-in-time di ripristino desiderato.

  4. Riattivare i gruppi di dischi appena ripristinati.

  5. Riprodurre i log di archivio nel punto desiderato.

  6. Se si desidera eseguire il ripristino completo, riprodurre tutti i registri di ripristino.

Questa procedura presuppone che i log di archivio desiderati siano ancora presenti nel file system attivo. In caso contrario, i log di archivio devono essere ripristinati portando completamente offline i LUN/namespace dei log di archivio ed eseguendo un ripristino (oppure creando un clone di uno snapshot precedente, operazione che può risultare complessa a causa della creazione di UUID o nomi LVM duplicati sullo stesso host). Questo è anche un esempio in cui la separazione dei log di archivio in risorse di storage dedicate si rivela utile. Se i log di archivio condividono un gruppo di volumi con i log di redo, questi ultimi devono essere copiati altrove prima del ripristino dell'intero set di LUN. Questo passaggio impedisce la perdita delle transazioni finali registrate.