consolidamento database oracle

Meeting Oracle Community Education – Bologna 12 – 13 settembre 2005

Dir. Informatica e TelecomunicazioniGestione Sistemi

Consolidamento

Database

Oracle



Come eravamo…

•Contabilità •Segreteria Studenti (ora replica di Esse3)

•Logistica

•Gestione PTA

•Gestione DOC

•Timbrature

•Controllo accessi

•Didattica on line •LDAP

•Datastore Citrix Farm



…e dove siamo arrivati

eth0 eth0

eth2 eth2

eth1 eth1

heartbeat

Cross 1000

100Mb/sec 100Mb/sec

Cross 1000

ORAFilerDIT

CIOP

ORAFilerRETT

100Mb/sec

CIP

50Gb Database



Configurazione HW/SWNodi cluster

– HP Proliant BL20p • 2x Intel Xeon 2.8 GHz• 2x36GB HDD UltraSCSI in

RAID 1• 2 GB RAM

– Red Hat Enterprise 3 AS– Heartbeat 1.2.3 + mon– ORACLE 9.2.0.5

Storage condiviso

– Netapp F87 • 8x72GB HDD SCSI

– Data ONTAP 6.5.1 R1– Snapshot– SnapRestore– SnapMirror– NFS



Struttura fisica database

• Layout Oracle OFA (Optimal Flexible Architecture) per NetApp• Tutti i datafile, controlfile, redo log, archive log sono sul filer• Sul filesystem dei nodi questi file sono dei link simbolici ai filesystem nfs montati su

filer• I binari di Oracle sono mantenuti sui dischi locali dei nodi• Le mount nfs seguono delle best practice Oracle/Netapp: rw, bg, tcp, hard,

rsize=32768, wsize=32768 (http://www.netapp.com/tech_library/ftp/3369.pdf)

/mnt/cluster/unitnprd/oracle

/mnt/cluster/unitnprd/oracle_1

/mnt/cluster/unitnprd/archive

/oracle_prod•Datafile•Controlfile, copia 1•Primo membro redo log group•Archive log destination 1

/oracle_prod_1•Controlfile, copia 2•Secondo membro redo log group

/oracle_prod_archive•Archive log destination 2



Politiche di backup del database Oracle

• Su nastro con programma di backup centralizzato (con doppia scrittura su pool libreria e pool conservato in cassaforte ignifuga)

• Export di schemi selezionati due volte al giorno (ore 13 ed ore 23)

• Full export una volta alla settimana• Hot backup su filer utilizzando gli snapshot, con script

bash “crontabizzato” (ore 2,6,10,16,20)• Replica in sito di DR con SnapMirror

…lo sappiamo, siamo un po’ paranoici!



Hot backup con gli snapshot

• Database in backup mode

• Snapshot dei datafile

• End backup del database

• Switch log e backup dei controfile

• Snapshot dei log e dei controlfile appena creati

alter tablespace SYSTEM begin backup;alter tablespace DATI1 begin backup;alter tablespace DATI2 begin backup;

rsh orafilerdit snap create ${ORACLE_SID}.datafile.00

alter tablespace SYSTEM end backup;alter tablespace DATI1 end backup;alter tablespace DATI2 end backup;

alter system archive log current;alter database backup controlfile to trace noresetlogs;alter database backup controlfile to '/mnt/orabackup/unitnprd/backup/hot/last/unitnprd_ctrlfile.ctl' reuse;alter database backup controlfile to trace as '/mnt/orabackup/unitnprd/backup/hot/last/unitnprd_ctrlfile.sql' reuse noresetlogs;create pfile=/mnt/orabackup/unitnprd/backup/hot/last/initunitnprd.ora' from spfile;

rsh orafilerdit snap create ${ORACLE_SID}.ctrlarch.00



Hot backup con snapshot

Un backup su filer sarà costituito da due snapshot:1. ${ORACLE_SID}.datafile.xx

– datafile

2. ${ORACLE_SID}.ctrlarch.xx– Redo log generati durante il backup– Backup controlfile (generato immediatamente prima dello

snapshot), binario ed sql– Init file, generato a partire dal spfile– Lo spazio utilizzato da questo snapshot sarà particolarmente

ridotto, riconducibile praticamente ai tre tipi di file sopraelencati



Hot backup con gli snapshot

• Un backup viene creato in meno di un minuto• Lo snapshot viene creato in pochi secondi• Possibilità di fare backup più frequenti, anche

durante le ore di punta• Maggiore velocità durante un restore• Lo spazio disco richiesto da un backup con gli

snapshot è irrisorio:– 20 backup in linea– Spazio utilizzato dagli snapshot: poco più di 40 Gb



Scenario di restore/recovery…

…nel caso di perdita di un datafile.

Segue la normale procedura di restore/recovery di un database Oracle

1. Restore del file mancante

2. Recovery del tablespace



Restore con gli snapshot

• Restore da nastro

• Copia di un file dallo snapshot (con utility come cp)

• Utilizzo di snaprestore (più veloce, possibilità di effettuare il revert di un intero volume in pochi secondi)



Restore con gli snapshot

• Restore del datafile mancante

snaprestore -t file –s unitnprd.datafile.xx

/vol/vol0/oracle_prod/oradata/dati1.dbf



Scenario di restore/recovery

• Recovery della tablespace

alter tablespace dati offline temporary;

<restore datafile>

recover tablespace dati;



Scenario di restore/recovery

• Fornire gli archive log necessari– Dalla posizione specificata nei parametri di Oracle

“log_archive_dest”– Restore da nastro– Direttamente da snapshot

/mnt/cluster/unitnprd/oracle/.snapshot/${ORACLE_SID}.ctrlarch.xx/oradata/archive

• Riportare online la tablespaceAlter tablespace dati online;



Disaster Recovery

• Utilizza SnapMirror (asincrono)• Replica l’intero database su un altro filer in sede remota• Una replica ogni 15 minuti• Su linea a 100 Mbps: nessun problema di velocità (trasferimento dei soli

incrementali, modello rsync). Possibilità di limitare la banda utilizzabile• Una replica anche ogni 24 ore (un problema verificatosi entro 15 minuti si

propagherebbe anche sulla replica)• Snapmirror utilizzato anche per mantenere una copia sullo stesso filer. Utile

per avere una copia aggiornata del db per test

Documento tecnico NetApp di riferimento: http://www.netapp.com/tech_library/3057.html

orafilerdit Direzione Informatica

orafilerrettRettorato

snapmirror

MAN 100 Mbps



Disaster Recovery



Disaster Recovery

• Quiesce del filesystem di orafilerrett• Break della relazione tra i due filer: a questo punto il

mirror di orafilerrett è writeable• Cambio dell’IP nei file hosts dei nodi del cluster• Mount del filesystem di orafilerrett• Recovery del database• Open database e …di nuovo al lavoro sfaticati!


snapmirror




Modifiche apportate al sito secondario

Disaster Recovery

Al ripristino del sito primario è possibile risincronizzare il database:

• Creando un nuovo mirror tra i due filer (copiando l’intero db, con snapmirror o backup+restore da nastro)

• Reinizializzando il mirror a partire dall’ultimo snapshot in comune tra i due storage





To do• Consolidamento infrastruttura storage

– Cluster di filer– Possibilità di utilizzo dei protocolli già in uso in Ateneo (FC SAN,

iSCSI, CIFS, NFS)– Utilizzo di NDMP per backup su nastro

• Migrazione a Data ONTAP 7G– FlexVolume: volumi dinamici– FlexClone: “snapshot” r/w vs copia db snapmirrorata.

• Resource fencing sul cluster, tramite un meccanismo di STONITH, utilizzando HP iLO

• Completamento del sito di DR (VMware ?)

consolidamento database oracle

Documents