Informazioni sulla sincronizzazione dei database di test e di produzione

Quando gli ambienti di sviluppo e test sono distribuiti nel cloud, è necessario procedere ad un aggiornamento rapido ed efficiente oppure a una sincronizzazione, i dati di test con l'ambiente di produzione senza dover ricorrere a costi di storage di grandi dimensioni.

La gestione degli ambienti nel cloud non deve necessariamente essere complessa o con uso intensivo di memoria. È possibile creare una thin clone di Oracle Database per sincronizzare i dati utilizzando una frazione di capacità e tempo di memorizzazione necessari per creare una copia completa di un database.

Prima di iniziare

Prima di iniziare la sincronizzazione dei database di test e di produzione, rivedere i concetti coinvolti nella migrazione di un database.Leggere le informazioni sulla riduzione del tempo di inattività durante le migrazioni nel database.

Architettura

Questa architettura mostra tre opzioni per la creazione di una versione principale di test del database di produzione e quindi la distribuzione di thin clone o snapshot negli ambienti di sviluppo e di test.

Descrizione dell'immagine prod-testmaster-snap-db.png

I seguenti componenti fanno parte dell'architettura:

• Database di produzione: il database con dati di produzione, ovvero l'origine che si intende utilizzare per creare un database principale di test.
• Database principale di test: copia del database di produzione che verrà utilizzata per creare uno snapshot
• Snapshot: un thin clone creato dal database principale di test, che può essere utilizzato per gli ambienti di sviluppo o di test.

Il primo passo consiste nella creazione di un database principale di test del database di produzione. È possibile procedere in uno dei tre modi riportati di seguito.

• Creare un database in standby fisico dal database di produzione. Il database in standby fisico funge da database principale di test.

  Utilizzare questa opzione se si creano spesso copie del database di produzione, ad esempio giornalmente o settimanalmente, si desidera creare copie rapidamente o se si dispone di un database di produzione di grandi dimensioni. Quando il database principale di test è un database in standby fisico, il database principale di test viene sempre sincronizzato con la produzione e non è mai necessario aggiornare i dati. Nei database di grandi dimensioni non è possibile aggiornare rapidamente il database principale di test.

• Creare una copia del database di produzione utilizzando Oracle Recovery Manager (RMAN) come database principale di test.

  Utilizzare questa opzione se a volte si creano copie dell'ambiente di produzione, ad esempio quindicinale o mensile. Con questo metodo di creazione di un database principale di test, è possibile creare il database principale di test una volta utilizzando la duplicazione attiva di RMAN, quindi usare il database principale di test per creare copie più volte in un mese.

• Creare una copia di backup completa del database di produzione e utilizzare il backup per creare una copia e utilizzare la copia come database principale di test.

  Utilizzare questa opzione se si aggiornano le copie raramente, ad esempio trimestrale, quindicinale o annualmente. Con questo metodo di creazione di un database principale di test, viene eseguito un backup completo del database dal database di produzione e il database principale di test viene creato utilizzando il backup di produzione creato. È possibile utilizzare il database principale di test per creare copie più volte, in base alle esigenze.

È possibile utilizzare il database principale di test per creare copie (snapshot) efficienti dello spazio del database per gli ambienti di test e sviluppo.

I seguenti diagrammi di architettura forniscono alcune linee guida sui diversi metodi di creazione e gestione del database principale di test. Scegliere l'opzione ottimale per l'ambiente in uso e la frequenza con cui è necessario aggiornare il database.

Opzione I: se il database di produzione è di grandi dimensioni ed è necessario aggiornare rapidamente gli ambienti di sviluppo e di test dalla produzione (entro pochi minuti), utilizzare Oracle Data Guard per creare un database in standby come database principale di test. Il vantaggio di questo metodo è che il database principale di test è sempre sincronizzato con il database di produzione e non è mai necessario aggiornare il database principale di test.

Descrizione dell'immagine testmaster-dataguard.png

L'architettura supporta il seguente flusso:

1. Creare un database principale di test utilizzando Oracle Data Guard. In questo scenario, il database principale di test è un database in standby fisico del database di produzione ed è sempre sincronizzato con la produzione.
2. Creare snapshot di lettura/scrittura per gli ambienti di test. Gli snapshot vengono creati sul server principale di test. Il server principale di test utilizza il file system cluster Oracle ASM (Oracle ACFS).

L'architettura supporta i componenti riportati di seguito.

• Production Oracle Database: il database di produzione può utilizzare un file system Oracle Automatic Storage Management (Oracle ASM), Oracle ACFS o UNIX.
• Database principale di test: uno standby fisico completamente sincronizzato del database di produzione su Oracle ACFS.
• Snapshot: una o più copie di lettura/scrittura del database principale di test creato per gli ambienti di test.

Opzione II: se è necessario aggiornare periodicamente gli ambienti di test, ad esempio bisettimanale o mensile, copiare il database di produzione utilizzando RMAN Active Duplicate per creare un database principale di test.

Descrizione dell'immagine testmaster-rman-duplicate.png

L'architettura supporta il seguente flusso:

1. Copiare il database di produzione per creare un duplicato attivo RMAN del database principale di test. Eseguire il comando RMAN Active Duplicate da un database di produzione per creare il database principale di test.
2. Creare snapshot di lettura/scrittura per gli ambienti di test. Gli snapshot vengono creati sullo stesso server del database principale di test (server principale di test). Il server principale di test utilizza Oracle ACFS.
3. Aggiornare il database principale di test eliminando il database principale di test e ricreando una copia del database di produzione.

L'architettura supporta i componenti riportati di seguito.

• Production Oracle Database: il database di produzione può utilizzare un file system Oracle ASM, Oracle ACFS o UNIX.
• Database principale di test: copia completa del database di produzione su un file system Oracle ACFS.
• Snapshot: uno o più snapshot di lettura/scrittura del database principale di test creati per gli ambienti di test.

Opzione III: se è necessario eseguire l'aggiornamento da un ambiente di produzione occasionalmente (alcuni mesi), è possibile utilizzare il backup completo di RMAN dalla fase di produzione per creare un database principale di test. Per semplificare il processo di aggiornamento, creare un servizio Oracle Cloud Infrastructure File Storage ed eseguirne il MOUNT nel server del database principale di produzione e test. Quando si esegue il backup RMAN del database di produzione su Oracle Cloud Infrastructure File Storage, il backup è disponibile anche sul server principale di test e disponibile per la creazione di un database principale di test.

Descrizione dell'immagine testmaster-rman-full.png

L'architettura supporta il seguente flusso:

1. Creare una copia di backup completa del database di produzione sul servizio Oracle Cloud Infrastructure File Storage ed eseguire il MOUNT del backup sul server principale di test.
2. Creare snapshot di lettura/scrittura per gli ambienti di test. Gli snapshot vengono creati sul server principale di test. Il server principale di test utilizza Oracle ACFS.
3. Aggiornare il database principale di test, se necessario, eliminando il database principale di test esistente e ricreandolo utilizzando un nuovo backup del database di produzione.

L'architettura supporta i componenti riportati di seguito.

• Production Oracle Database: il database di produzione può utilizzare un file system Oracle ASM, Oracle ACFS o UNIX.
• Oracle RMAN- Backup completo: la utility RMAN crea un backup completo del database di produzione nel servizio Oracle Cloud Infrastructure File Storage.
• Database principale di test: copia completa del database di produzione su un file system Oracle ACFS.
• Snapshot: uno o più snapshot di lettura/scrittura del database principale di test creati per gli ambienti di test.

Informazioni sul thin clone con la utility gDBClone

La utility Gestione snapshot di copia del database (gDBClone consente di fornire metodi semplici ed efficienti per la creazione di copie snapshot e la gestione dei database per ambienti di test e sviluppo.

La utility utilizza Oracle ASM Cluster File System (Oracle ACFS). La tecnologia di snapshot point in time di Oracle ACFS e l'utility gDBClone forniscono strumenti potenti, flessibili e semplici che riducono il tempo e la complessità della gestione dei server di test e sviluppo. Utilizzare questi strumenti per sincronizzare rapidamente ed efficiente i dati tra i database di test, sviluppo e produzione in base a una pianificazione normale o a seconda delle esigenze.

Uno snapshot di Oracle ACFS è una copia in linea, di sola lettura o di lettura, point in time di un file system Oracle ACFS. La copia snapshot è efficiente dello spazio e utilizza la funzionalità Reindirizzo-scrittura (ROW) di Oracle ACFS. Prima di modificare o eliminare un extent di file Oracle ACFS, il relativo valore corrente viene conservato nello snapshot per mantenere il punto di vista tempo del file system. Oracle ACFS supporta 1023 snapshot per ogni file system.

Lo script gDBClone consente di eseguire le seguenti funzioni chiave:

• Clone: crea una copia del database da un database di produzione. La duplicazione è il database principale di test. La quantità di tempo necessaria per creare una copia di database dipende dalle dimensioni del database e dal throughput della rete.
  • Il database di origine può trovarsi in qualsiasi tipo di file system, incluso Oracle Automatic Storage Management (Oracle ASM).
  • Se il database è remoto, gDBClone deve connettere il database remoto tramite il listener Listener o SCAN (Single Client Access Network) per Oracle Real Application Clusters (Oracle RAC).
  • La copia, o il database principale di test, può essere un database primario o in standby.
  • Quando si utilizza Oracle Recovery Manager (RMAN) Duplica da database attivo, gDBClone alloca 3 canali RMAN. È possibile sovrascrivere l'impostazione predefinita utilizzando l'opzione di comando -channels RMAN channels number.
• Snap: crea uno snapshot con sparsità (thin clone) di un Oracle Database. La copia snapshot è un'area con un adattatore e utilizza la funzionalità Reindirizzamento in scrittura (riga ACFS).
• Convert: converte un database specificato in Oracle Real Application Clusters (Oracle RAC) One Node, Oracle RAC o da un database non appartenente a un database collegabile (PDB) di un database contenitore (CDB) specificato.
• ListDBs: elenca i database duplicati e i relativi snapshot.
• DelDB: elimina i database duplicati o i relativi snapshot.
• ListHomes: elenca la Oracle home disponibile
• ACFS
• SYSPwF: crea un password file cifrato

Informazioni su servizi, prodotti e ruoli richiesti

Questa soluzione richiede i seguenti prodotti, servizi e ruoli:

Il sistema di origine (database di produzione) può essere uno dei seguenti:

• 1-node Sistema di database Oracle Cloud Infrastructure Virtual Machine
• Sistema di database Oracle RAC Virtual Machine 2-node
• Sistema Oracle Database bare metal a nodo 1-node
• Sistema di database Oracle Database Exadata Cloud Service

Il database di produzione può utilizzare Oracle Automatic Storage Management (Oracle ASM), Oracle ASM Cluster File System (Oracle ACFS) o un file system UNIX.

Il sistema di destinazione (server principale di test) può essere uno dei seguenti:

• Configurazione del sistema di database bare metal (a istanza singola) bare metal

  Il database principale di test non può essere un sistema di database di virtual machine poiché un sistema di database di Virtual Machine non supporta più database.

• Oracle Database Exadata Cloud Service

Per l'istanza di database principale di test, Oracle Database deve essere memorizzato su un file system Oracle ACFS locale.

Si consiglia di specificare che le home del database di origine e di destinazione siano uguali a edizione e versione. Si consiglia di utilizzare entrambe le home DB allo stesso livello di patch, sia le patch bundle che le patch singole.

Questi sono i ruoli necessari per ogni servizio.

Nome prodotto: ruolo	Richiesto per...
Oracle Database: privilegi di sistema root o sudo con la possibilità di eseguire comandi come root.	Creare il database principale di test duplicando il database di produzione, creando un database in standby o creando una copia di backup completa.
Utility gDBClone: privilegi di sistema root o sudo con la possibilità di eseguire comandi come root.	Eseguire la maggior parte dei task gDBClone, inclusi la copia e gli snapshot.
Servizio Oracle Cloud Infrastructure File Storage: membro del gruppo OCI_Administrators.	Creare un backup completo del database con Oracle Recovery Manager (RMAN) sul servizio Oracle Cloud Infrastructure File Storage.

Per ottenere i servizi cloud necessari, vedere Informazioni su come ottenere i servizi Oracle Cloud per le soluzioni Oracle.