1 / 19

Consolidamento Database Oracle

Consolidamento Database Oracle. Come eravamo…. LDAP Datastore Citrix Farm. Didattica on line. Gestione PTA Gestione DOC Timbrature Controllo accessi. Contabilità. Segreteria Studenti (ora replica di Esse3) Logistica. …e dove siamo arrivati. 100Mb/sec. 100Mb/sec. 100Mb/sec.

eli
Télécharger la présentation

Consolidamento Database Oracle

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Consolidamento Database Oracle

  2. Come eravamo… • LDAP • Datastore Citrix Farm • Didattica on line • Gestione PTA • Gestione DOC • Timbrature • Controllo accessi • Contabilità • Segreteria Studenti (ora replica di Esse3) • Logistica

  3. …e dove siamo arrivati 100Mb/sec 100Mb/sec 100Mb/sec eth0 eth0 heartbeat eth2 eth2 CIOP CIP eth1 eth1 50Gb Database Cross 1000 Cross 1000 ORAFilerRETT ORAFilerDIT

  4. Configurazione HW/SW Storage condiviso • Netapp F87 • 8x72GB HDD SCSI • Data ONTAP 6.5.1 R1 • Snapshot • SnapRestore • SnapMirror • NFS Nodi 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

  5. 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 • /oracle_prod • Datafile • Controlfile, copia 1 • Primo membro redo log group • Archive log destination 1 /mnt/cluster/unitnprd/oracle_1 • /oracle_prod_1 • Controlfile, copia 2 • Secondo membro redo log group /mnt/cluster/unitnprd/archive • /oracle_prod_archive • Archive log destination 2

  6. 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!

  7. Hot backup con gli snapshot alter tablespace SYSTEM begin backup; alter tablespace DATI1 begin backup; alter tablespace DATI2 begin backup; • 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 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

  8. Hot backup con snapshot Un backup su filer sarà costituito da due snapshot: • ${ORACLE_SID}.datafile.xx • datafile • ${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

  9. 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

  10. Scenario di restore/recovery… …nel caso di perdita di un datafile. Segue la normale procedura di restore/recovery di un database Oracle • Restore del file mancante • Recovery del tablespace

  11. 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)

  12. Restore con gli snapshot • Restore del datafile mancante snaprestore -t file –s unitnprd.datafile.xx /vol/vol0/oracle_prod/oradata/dati1.dbf

  13. Scenario di restore/recovery • Recovery della tablespace alter tablespace dati offline temporary; <restore datafile> recover tablespace dati;

  14. 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 tablespace Alter tablespace dati online;

  15. Disaster Recovery MAN 100 Mbps • 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 snapmirror orafilerdit Direzione Informatica orafilerrettRettorato

  16. Disaster Recovery

  17. 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 orafilerdit Direzione Informatica orafilerrettRettorato

  18. Disaster Recovery Modifiche apportate al sito secondario 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 orafilerrettRettorato orafilerdit Direzione Informatica

  19. 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 ?)

More Related