Appunti

 

In questa sezione cercheremo di analizzare i dati raccolti durante l’analisi di fattibilità per comprendere se  una installazione basata su Dataguard può essere supportata dall’infrastruttura esistente ed eventualmente intervenire con l’aggiunta di risorse o con la modifica della configurazione esistente.

Si esegue una prima indagine per verificare se la rete è in grado di smaltire il picco massimo di traffico di sincronizzazione negli orari di massimo impegno della rete da parte dell’utenza normale. Nel caso peggiore deve essere smaltibile entro le 24 ore.

1. Il traffcio di picco è abbondantemente assorbibile nelle 24 ore essendo smaltito in circa un’ora e 37 minuti. 
2. Nelle stesse condizioni ed usando lo stesso modello di calcolo si ricava che il picco orario di 1,7GB viene smaltito in circa 28 minuti; ne consegue che l’implementazione potrebbe avere un RPO inferiore a 30 minuti.
3. Nelle stesse condizioni la replicazione sincrona non è usabile visto che il picco istantaneo di 1,4MB/sec non è assorbibile dalla rete avendo questa un limite teorico di 1,05MB/sec di throughput. Per poter replicare in modalità sincrona serve una disponibilità pari ad almeno il 55%. In ogni caso, per evitare impatti negativi sulle prestazioni all’utenza, la replicazione sincrona è sconsigliabile per problemi di latenza.
4. Il modello può implementare un schema di Disaster Recovery basato su DataGuard in configurazione MAXIMUM PERFORMANCE e RPO < 30’.
5. La copia iniziale della banca dati (Dimensione backup totale = 8,5GB) richiede circa 1h40’. A piena disponibilità di banda circa 56’.  (tempo reale di clonazione: 1h10’2”)
6. Spazio disco: 95GB e 20% di crescita = circa 120GB
7. Spazio di backup su S3: sette giorni per 8,5GB = circa 60GB.
8. Trasferimenti in rete pari a Redo Rate (totale mese).

Stima dei costi

Sono necessari circa 335€/mese; considerare un valore di contingency pari ad almeno il 20% aggiuntivo.

Note sulla realizzazione

La configurazione di un database in standby è relativamente semplice; lo è ancora di più se si fa uso di Oracle Enteprise Manager Grid Control. In rete esistono vari tutorial da usare come supporto alle procedure di configurazione di Dataguard.  Ne segnaliamo tre:

Per la configurazione di Dataguard su Amazon EC2:

http://www.oracle.com/technetwork/database/features/availability/dr-cloud-bestpractices-173309.pdf

Per la configurazione di Dataguard via Enteprise Manager:

http://gjilevski.wordpress.com/2010/07/24/managing-data-guard-11g-r2-with-oem-11g/

Per la configurazione di Dataguard via Command Line:

http://st-curriculum.oracle.com/obe/db/11g/r2/prod/ha/dataguard/physstby/physstdby.htm

In funzione della disponibilità di banda verso il server di standy può essere necessario o meno ricorrere a procedure manuali per la duplicazione iniziale della banca dati. I tutorial succitati creano la banca dati di standby mediante il comando DUPLICATE FROM ACTIVE che prevede una copia online dei file di dati; questo approccio non sempre è conveniente in presenza di connessioni a relativamente bassa velocità. Soprattutto nei casi in cui il backupset abbia una dimensione nettamente inferiore a quella del database, per ridurre drasticamente i tempi di clonazione, è utile seguire le indicazioni dell’articolo di Metalink “Creating Physical Standby using RMAN Duplicate Without Shutting down The Primary” ID 789370.1 avendo l’accortezza di abilitare l’opzione di compressione in RMAN.

La procedura prevista nell’articolo sostituisce la copia diretta via DUPLICATE FROM ACTIVE DATABASE con un backup compresso della banca dati sul sito primario, la copia dei file dal sito primario a quello secondario e la duplicazione via comando DUPLICATE sul server di standby.  La stessa procedura torna utile nel caso in cui la clonazione iniziale via rete non sia fattibile per le elevate dimensioni della banca dati; in questo caso lo spostamento  verso il sito secondario dei backup può essere fatto via supporti esterni (es dischi USB)  sfruttando il servizio Amazon AWS Import/Export.

Per comprimere tutti i backup verso disco (la scelta dell’algoritmo di compressione è disponibile solo dalla versione 11.2:

RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;

RMAN> CONFIGURE COMPRESSION ALGORITHM 'HIGH';

Per comprimere un particolare backupset:

RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;