Questo articolo fornisce una panoramica della replica del database Oracle. Tratta concetti, architetture, passaggi di implementazione e migliori pratiche operative. Si apprende come la replica si collega a RPO e RTO. Vengono illustrati i metodi fondamentali: Data Guard, GoldenGate, viste materializzate e opzioni legacy. Si scoprono inoltre il monitoraggio, gli avvisi e la sicurezza relativi alla replica.
Cos’è la replica del database Oracle?
Oracle acquisisce le modifiche effettuate su un database sorgente e le applica su uno o più database di destinazione. Supporta una modalità sincrona, che attende la conferma del commit, e una modalità asincrona, che invia le modifiche senza attendere. La modalità sincrona garantisce una perdita di dati quasi nulla, ma introduce latenza; quella asincrona riduce la latenza, ma comporta il rischio di piccole lacune nei dati in caso di guasto. Oracle utilizza il trasporto dei redo log, l’analisi dei log (log mining) o i log delle viste materializzate, a seconda del metodo scelto. I modelli di coerenza variano: immediata per la modalità sincrona ed eventuale per quella asincrona.
Replica è legata all’RPO (Obiettivo di punto di ripristino) e all’RTO (Obiettivo di tempo di ripristino). Le modalità sincrone consentono un valore di RPO quasi nullo. Le modalità asincrone bilanciano l’RPO rispetto alla distanza della rete. La scelta dipende dalle esigenze aziendali e dall’infrastruttura disponibile. È inoltre necessario pianificare l’RTO: la velocità con cui è possibile rendere operativa una replica. Questi obiettivi guidano la selezione del metodo e la sua configurazione.
Perché replicare il database Oracle?
La replica soddisfa le priorità operative fondamentali: ripristino dopo disastri, elevata disponibilità, bilanciamento del carico e continuità aziendale. Supporta inoltre l’analisi dei dati e le migrazioni.
Ripristino dopo un disastro e RPO/RTO: La replica memorizza copie in siti remoti. In caso di guasto, si passa al sistema di standby. La replica sincrona comporta una perdita minima di dati (RPO quasi nullo). La replica asincrona è adatta per siti distanti con un RPO modesto. L’RTO viene misurato in base alla rapidità con cui si effettua il passaggio dei ruoli. I test di failover verificano il raggiungimento degli obiettivi di RTO.
Alta disponibilità: Un database di riserva può subentrare mediante commutazione manuale o automatica. Data Guard fornisce servizi gestiti di applicazione per transizioni rapide. GoldenGate consente di realizzare configurazioni attivo-attivo in alcuni casi. Si riducono i tempi di inattività programmati e non programmati. Si rispettano gli SLA e si migliora l'affidabilità del servizio.
Bilanciamento del carico e reporting: Active Data Guard consente di aprire un database di standby in lettura. Si scarica il carico di reporting dal database primario. Le viste materializzate possono soddisfare le esigenze locali di reporting con aggiornamenti periodici. Ciò migliora le prestazioni per gli utenti finali e i team di analisi.
Continuità aziendale e manutenzione: È possibile applicare patch o aggiornamenti sull’istanza di standby mentre quella primaria è in esecuzione. Dopo aver eseguito i test, si procede al cambio dei ruoli. Ciò consente di ridurre al minimo i tempi di inattività legati alla manutenzione. È inoltre possibile eseguire la migrazione delle piattaforme replicando l’ambiente in un nuovo contesto.
Distribuzione dei dati: È possibile replicare i dati in uffici remoti o zone cloud. Le viste materializzate o Oracle GoldenGate possono inviare sottoinsiemi o dati filtrati. Si supportano applicazioni distribuite con copie locali.
Test e sviluppo: Si mantiene una replica per il controllo qualità o lo sviluppo. Questa viene aggiornata regolarmente a partire dall’ambiente di produzione. I team possono testare le modifiche senza mettere a rischio l’ambiente principale.
Tipi di replica del database in Oracle
Oracle offre diversi metodi. Ognuno è adatto a casi d’uso specifici e comporta compromessi in termini di RPO, RTO, complessità e licenze. Di seguito è riportato un riepilogo comparativo:
| Method | RPO | RTO | Use Case | Complexity | Licensing | Status | Oracle Version |
|---|
| Data Guard | Data Guard | Fast failover/switchover | HA/DR for Oracle only | Moderate | Included in EE | Current | 11g onwards |
| GoldenGate | Near-zero to configurable | Varies; depends on apply | Logical replication, heterogeneous, migrations, active-active | High | Separate license | Current | 11g onwards |
| Materialized Views | Scheduled lag | Depends on refresh | Reporting, caches, minimal sync | Low | Included in EE | Current | 11g onwards |
| Advanced Replication | Moderate; conflict risk | Slow for conflict resolution | Multi-master legacy | High | Included in EE | Legacy/Superseded | 11g,12c |
| Streams | Near-zero to async | Fast | Deprecated logical replication | High | Included but deprecated | Deprecated | Deprecated in 12c, desupported 19c |
Come replicare un database Oracle?
Le seguenti panoramiche illustrano la configurazione e le operazioni. Consultare sempre la documentazione Oracle relativa alla propria versione e ambiente.
Prerequisiti e pianificazione
Prima di configurare qualsiasi replica: verificare la connettività di rete, assicurarsi che sia disponibile una larghezza di banda sufficiente e che i collegamenti siano sicuri. Confermare che le edizioni e le licenze Oracle consentano i metodi scelti. Preparare i backup tramite RMAN. Assegnare utenti dedicati con i privilegi appropriati. Pianificare lo spazio di archiviazione sul sistema di standby o sulle destinazioni dei log. Definire gli obiettivi di RPO e RTO. Eseguire prima i test nell’ambiente di staging. Documentare le procedure operative per la configurazione, il monitoraggio e il failover.
1. Configurazione di Data Guard
Data Guard offre un’istanza standby gestita per l’alta disponibilità (HA) e il ripristino di emergenza (DR). È possibile utilizzare il Broker oppure configurare manualmente. Active Data Guard aggiunge la funzionalità in sola lettura.
Abilitare la modalità ARCHIVELOG e FORCE LOGGING. Creare i log di redo di standby: uno in più rispetto al numero di gruppi di redo log. Impostare DB_UNIQUE_NAME sia sul database primario che su quello di standby. Configurare le voci LOG_ARCHIVE_DEST_n: il database primario invia i redo log alle destinazioni di standby. Impostare FAL_SERVER e FAL_CLIENT per la risoluzione dei gap. Assicurarsi che i parametri di inizializzazione siano coerenti su entrambi i lati.
In modalità standby, il processo di recupero gestito (MRP) applica i record redo. Con Active Data Guard, è possibile aprire il database standby in sola lettura: ALTER DATABASE OPEN READ ONLY. Le query vengono eseguite sul database standby senza influenzare l’applicazione dei record redo. Per monitorare il ritardo nell’applicazione, utilizzare la vista V$ARCHIVE_DEST_STATUS con la colonna APPLIED_TIME.
Test di commutazione: commutazione pianificata in cui il database primario diventa di riserva. Utilizzare DGMGRL SWITCHOVER TO standby. Test di failover: commutazione non pianificata, il database primario non è raggiungibile. Utilizzare DGMGRL FAILOVER TO standby. Dopo la modifica dei ruoli, riconfigurare l’istanza originale come nuovo database di riserva. Documentare le procedure e verificarle regolarmente.
Eseguire query sulle viste V$ARCHIVE_DEST_STATUS e V$DATAGUARD_STATS per verificare il ritardo nel trasporto e nell’applicazione dei log. Utilizzare il comando DGMGRL SHOW CONFIGURATION per ottenere lo stato complessivo della configurazione. Configurare avvisi quando il ritardo supera la soglia prestabilita. Monitorare l’utilizzo dei log di standby (SRL) e lo spazio disponibile su sistema standby. Controllare la presenza di errori di rete nei log degli avvisi. Automatizzare le notifiche tramite script o strumenti di monitoraggio.
I guasti della rete causano lacune nei log di redo. Utilizzare FAL_SERVICE per recuperare i log mancanti. Risolvere con ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL, quindi riavviare il processo di recupero. Un numero insufficiente di log di redo standby causa un’applicazione lenta. La conservazione dei log di archivio deve tener conto del consumo da parte del sistema standby. Le incoerenze di versione bloccano l’applicazione; assicurarsi che i livelli di patch siano allineati. Eseguire un test di failover per convalidare la configurazione.
2. Configurazione di GoldenGate
GoldenGate fornisce la replica logica. Funziona su sistemi eterogenei e utilizza i processi Extract, file di traccia (trail files), Pump (opzionale) e Replicat.
Abilitare la registrazione supplementare: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA e ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS oppure ADD TRANDATA sulle tabelle. Ciò garantisce che i dati relativi alle modifiche necessarie siano presenti nei log redo. Creare un utente GoldenGate con i privilegi richiesti.
Installare i binari di GoldenGate sui server di origine e di destinazione. Utilizzare versioni compatibili con la versione di Oracle Database. Configurare il processo Manager con le impostazioni della porta.
Crea il gruppo Extract: definisci il database e le tabelle di origine. Specifica la posizione del file trail. Utilizza Integrated Extract per Oracle per migliorare l’efficienza. Configura le tabelle di checkpoint nello schema di destinazione per tenere traccia dell’avanzamento. In alternativa, configura Extract Data Pump per trasferire i file trail sulle destinazioni.
Crea gruppo di replicazione: definisci il database e le tabelle di destinazione. Configura l’archivio delle credenziali o un alias per l’autenticazione sicura. Usa i file di parametri per mappare gli schemi e le tabelle sorgente a quelli di destinazione. Gestisci le trasformazioni o i filtri nei file di parametri.
GoldenGate può replicare le istruzioni DDL con le opportune impostazioni, ma richiede una pianificazione accurata. Utilizzare DDL INCLUDEMAPPING o approcci basati su script. Verificare che lo schema di destinazione supporti le nuove strutture.
Avviare i processi Manager, Extract, Pump e Replicat tramite GGSCI. Utilizzare il comando INFO ALL per verificare lo stato e il ritardo. Controllare i file di report per individuare eventuali errori. Monitorare le metriche di ritardo e il throughput. Utilizzare le tabelle heartbeat per rilevare arresti anomali.
Proteggere i file di traccia mediante i permessi a livello di sistema operativo. Utilizzare collegamenti di rete crittografati o socket sicuri per il trasferimento. Utilizzare l’archivio credenziali GoldenGate per le password. Valutare l’integrazione con Oracle Key Vault.
Eseguire le query INFO EXTRACT e INFO REPLICAT per verificare il ritardo e lo stato. Analizzare i file di report alla ricerca di errori. Impostare soglie per il ritardo; generare un avviso se superate. Monitorare le tabelle dei checkpoint per rilevare eventuali ritardi. Utilizzare script o strumenti di monitoraggio per raccogliere le metriche.
L’assenza della registrazione supplementare causa la perdita di dati. Rilevare le lacune qualora i log redo vengano sovrascritti; pianificare la conservazione dei log archiviati. Le modifiche DDL potrebbero non riuscire se non corrispondono. Problemi di rete interrompono la consegna dei trail. Controllare i log di Manager per individuare errori. Monitorare lo spazio su disco disponibile per i trail. Testare gli scenari di failover.
Per gli aggiornamenti di GoldenGate, coordinare l’arresto e l’avvio di Extract e Replicat. Utilizzare un aggiornamento graduale per evitare tempi di inattività. Verificare la compatibilità con i nuovi patch Oracle.
3. Configurazione delle viste materializzate
Le viste materializzate copiano i dati a intervalli regolari. Sono adatte per report o cache.
Sulla sorgente, creare i log delle viste materializzate sulle tabelle: CREATE MATERIALIZED VIEW LOG ON schema.table WITH ROWID. Ciò consente l’aggiornamento rapido.
In caso di successo, CREATE MATERIALIZED VIEW mv_name REFRESH FAST ON DEMAND AS SELECT ... FROM schema.table@dblink;. Usare ON COMMIT per un aggiornamento immediato al momento dei commit sulla sorgente, se accettabile.
Utilizzare l’aggiornamento RAPIDO quando esistono i log; altrimenti, utilizzare l’aggiornamento COMPLETO. Programmare l’aggiornamento tramite Oracle Scheduler: DBMS_SCHEDULER.CREATE_JOB. Monitorare LAST_REFRESH_DATE in DBA_MVIEWS.
Controllare DBA_MVIEW_REFRESH_TIMES per la cronologia. Gestire gli errori di aggiornamento dovuti a problemi di rete o a incoerenze nei tipi di dati. Assicurarsi di disporre dei privilegi necessari sui collegamenti alle origini. Gestire i dati obsoleti scegliendo la frequenza di aggiornamento appropriata.
Reportistica quasi in tempo reale nei siti distribuiti. Memorizzazione nella cache dei dati di riferimento. Scarico delle query dal sistema primario.
4. Configurazione avanzata della replica (obsoleta)
La replica avanzata utilizza gruppi di replica e processi. Supporta la configurazione multi-master, ma è obsoleta. Per i nuovi progetti si consiglia l’uso di GoldenGate.
Definire il gruppo di replicazione tramite DBMS_REPCAT. Aggiungere i siti master. Definire gli oggetti da replicare. Configurare i metodi di risoluzione dei conflitti. Pianificare i processi di propagazione. Monitorare tramite DBA_REPCAT o le viste fornite da Oracle.
Non supporta le nuove funzionalità Oracle, come il multitenant. Configurazione complessa e gestione dei conflitti. Supporto limitato da parte dei fornitori. Sostituito da GoldenGate.
5. Streams (deprecato)
Oracle Streams offriva la replica logica. È stato deprecato nella versione 12c ed eliminato dal supporto nella versione 19c. Non utilizzarlo per nuovi ambienti di distribuzione. Per esigenze analoghe, utilizzare GoldenGate.
Eseguire in modo sicuro il backup del database Oracle con Vinchin
Anche con la replica attiva, i backup rimangono essenziali. La replica garantisce la disponibilità, ma non copre tutti i tipi di guasti: è quindi necessario eseguire regolarmente backup coerenti e affidabili. Vinchin Backup & Recovery è una soluzione professionale per il backup dei database a livello aziendale, che supporta la maggior parte dei database più diffusi — Oracle, MySQL, SQL Server, MariaDB, PostgreSQL e PostgresPro.
Offre numerose funzionalità; tra i punti salienti figurano il backup su cloud e l’archiviazione su nastro, backup completi e incrementali con supporto per i log archiviati di Oracle, backup pianificati con compressione dei dati e deduplicazione, ripristino su un nuovo server con recupero puntuale (point-in-time recovery) e protezione contro il ransomware, oltre ad altre caratteristiche. Per Oracle in particolare, include la compressione nativa Oracle, il supporto al rilevamento delle modifiche a livello di blocco (block change tracking), l’esclusione dei file accessibili e l’esclusione dei file offline per ottimizzare i processi di backup.
La console web Vinchin è semplice e intuitiva. Il backup di Oracle prevede quattro passaggi chiari:
1. Seleziona il database da eseguire il backup
2. Scegli l’archiviazione di backup
3. Definire la strategia di backup
4. Invia il lavoro.
L’interfaccia ti guida con etichette chiare e indicazioni esplicite. Puoi monitorare lo stato dell’elaborazione, visualizzare i log e modificare le pianificazioni dalla console, senza dover utilizzare comandi complessi.
Con una base globale di clienti e valutazioni elevate dei prodotti, Vinchin offre una prova gratuita completa di 60 giorni: clicca sul pulsante per scaricare il programma di installazione e distribuirlo facilmente.
Domande frequenti sulla replica del database Oracle
Q1: Come monitoro il ritardo nell’applicazione di Data Guard?
Utilizzare l’istruzione SQL: SELECT DEST_ID, DEST_NAME, STATUS, RECEIVED_TIME, APPLIED_TIME FROM V$ARCHIVE_DEST_STATUS WHERE STATUS NOT IN ('DEFERRED','INACTIVE'); controllare la vista V$DATAGUARD_STATS per le metriche relative al ritardo.
Q2: Come risolvere le lacune quando il trasporto viene rieseguito e non va a buon fine?
Eseguire ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; quindi recuperare i log mancanti tramite FAL_SERVER; riavviare il processo di recupero: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT.
Q3: Come testare il failover di GoldenGate?
Arrestare l’Extract sulla sorgente; promuovere la destinazione a nuova sorgente; modificare i parametri dell’Extract per acquisire dati dalla nuova sorgente; riavviare i processi; una volta risolto il problema, riconfigurare l’originale come destinazione.
Q4: In che modo la replica influisce sulle prestazioni del sistema primario?
La modalità SYNC aggiunge latenza al commit; quella ASYNC ne aggiunge una quantità minima. L’acquisizione tramite GoldenGate incrementa la generazione di file redo e il carico sulla CPU. Monitorare le metriche AWR e quelle di sistema; dimensionare di conseguenza le risorse.
Q5: Come scegliere tra Data Guard e GoldenGate?
Utilizzare Data Guard per l’alta disponibilità (HA) e il ripristino di emergenza (DR) interni a Oracle. Utilizzare GoldenGate per la replica logica, i target eterogenei, il filtraggio, le migrazioni senza interruzioni del servizio e gli scenari multi-master.
Conclusione
La replica Oracle migliora la disponibilità, la resilienza e la scalabilità. Data Guard e GoldenGate soddisfano la maggior parte delle esigenze aziendali. Le viste materializzate sono adatte per la generazione di report, mentre le opzioni legacy rimangono in uso limitato. Per operazioni efficaci è necessario definire obiettivi chiari in termini di RPO e RTO, effettuare test approfonditi e monitorare proattivamente i sistemi. Garantire la sicurezza della replica mediante crittografia e gestione adeguata delle credenziali.
Accoppia sempre la replica con backup affidabili. Vinchin offre una soluzione di backup solida per Oracle. Prova la versione di prova gratuita per proteggere il tuo ambiente.
