Rbert Scarpitti ORACLE DATA GUARD 11G OVERVIEW Oracle Database e la business cntinuity: Oracle Data Guard 11g Pagina 1 di 11
Rbert Scarpitti Indice INDICE... 2 INTRODUZIONE... 3 Benefici... 3 CONFIGURAZIONE... 4 Prerequisiti... 4 Primary Database... 4 Standby Database... 4 Tiplgia di Standby Database... 5 METODI DI PROTEZIONE... 6 Esempi di cnfigurazine: physical standby database... 7 SERVIZI OPERATIVI DELLA TECNOLOGIA DATA GUARD... 8 Red Transprt Services... 8 Apply Services... 8 Rle Transitins... 8 DATA GUARD BROKER... 9 DATA GUARD E LE TECNOLOGIE AVANZATE DI ORACLE... 10 Oracle Real Applicatin Clusters (RAC)... 10 Flashback Database... 10 Recvery Manager (RMAN)... 10 PERCHÉ SCEGLIERE ORACLE DATA GUARD 11G... 11 Pagina 2 di 11
Rbert Scarpitti Intrduzine Oracle Data Guard 11g è l evluzine naturale di Oracle Standby Database di Oracle 8i, passand dalle versini 9i e 10g. Per quant riguarda la sla base dati, la tecnlgia Oracle Data Guard può essere impiegat in ambit high availability, data prtectin, disaster recvery e business cntinuity basandsi semplicemente sul mtre Oracle 11g e sulle ptenzialità fferte dalla versine Enterprise Editin, senza dver installare nessun altr sftware aggiuntiv apparat hardware. Data Guard frnisce inltre servizi adeguati a creare, mantenere e mnitrare un più standby databases, prevened le situazine di disastr semplicemente di crruzine di dati, cnsentend di mantenere cstantemente allineati due più database identici, ubicati in siti differenti, anche a distanze rilevanti, purché cnnessi via netwrk tra lr. Quest permette di attivare l istanza secndaria in qualsiasi istante, nel mment in cui la primaria divenisse inutilizzabile per cause vlute men, schedulate n, riducend al minim il temp di dwntime e sprattutt prevenend la perdita di dati. Data Guard può inltre integrare in maniera del tutt nativa, le ptenzialità di Oracle Real Applicatin Cluster, realizzand in maniera sinergica la tecnlgia Real Applicatin Guard che garantisce una prtezine cmpleta a frnte di guasti hardware, sftware e di disastri. Grazie all standby database è pssible demandare all istanza secndaria sia le prcedure di backup che la reprtistica massiva ed invasiva, nrmalmente attuata sulle istanze di prduzine direttamente, semplicemente integrandsi cn l utility Recvery Manager di Oracle. Benefici Cme megli illustrat in seguit sn mlteplici le mtivazini che inducn a scegliere la tecnlgia Data Guard. Eccne un elenc: Nn si hann perdite di dati in cas di disastr ed è inltre pssibile garantire un sistema in alta affidabilità. E pssibile scegliere le plitiche di prtezine dei dati e di ripristin a frnte di un disastr, in base alle esigenze applicative. La gestine della struttura Data Guard nel su cmpless può essere fatta da riga cmand tramite interfacce http(oracle Enterprise Manager). Attivazine del sit di DR a rul primari, per attività di manutenzine prgrammata al termine della quale il sit primari ritrna ad assumere il su rul nativ. Distribuzine dei carichi di lavr su tutti i ndi della cnfigurazine, cn differenziazine dei ruli assunti dai database(oltp, DDS, DATA WAREHOUSE). Integrazine di Data Guard cn altre pzini ed utility fferte da Oracle (RAC ed RMAN) per garantire massima prtezine, massima dispnibilità e massime perfrmance. Pagina 3 di 11
Rbert Scarpitti Cnfigurazine Oracle Data Guard si basa essenzialmente sulla presenza di due database identici, allineati applicand in mdalità sincrna a asincrna gli archivelgs generati dal prim Oracle Data Guard si basa essenzialmente sulla presenza di due database identici, allineati applicand in mdalità sincrna a asincrna gli archivelgs generati dal primari. Di seguit la tplgia appena descritta: Prerequisiti L installazine base in mdalità primari-secndari di Oracle Data Guard prevede essenzialmente che vengan rispettati i seguenti prerequisiti: 1. RDBMS Oracle 11g Database Enterprise Editin cmprendente la feature Data Guard e apertura della base dati in mdalità ARCHIVELOG. 2. Due server che abbian la stessa cnfigurazine sftware ed hardware ma per cui è pssibile decidere di utilizzare hardware ridimensinat sui sit secndari, riducend csì i csti cmplessivi di infrastruttura. E preferibile che i due server sian ubicati in pstazini fisicamente separate, quest per garantire, in cas di disaster, che almen un dei due nn venga cmprmess. 3. Un apparat di rete efficiente che cnsenta il trasprt degli archive lgs dal server primai vers i clne in tempi brevi e senza perdita di dati. Per quant riguarda la cnfigurazine base, nn è necessari alcun apparat disc estern cndivis, il sistema lavra tranquillamente sui dischi interni. In cnfigurazine RAC invece, essend Cluster, al cntrari è necessari far us di dischi shared. La gestine dei siti primari e secndari può essere fatta utilizzand riga cmand e SQL*PLUS ppure utilizzand l interfaccia frnita da Data Guard Brker Interface la cui utility di sistema è DGMGRL ppure direttamente integrata in Oracle Enterprise Manager. Primary Database Standby Database La tecnlgia Data Guard prevede la presenza di un database primari di prduzine attiv in mdalità primary rle, in single instance d in RAC, il quale allinea il database secndari attravers l invi e l applicazine degli archivelgs. Il database primari deve quindi essere sempre apert in mdalità lettura/scrittura vviamente. L standby database è ttenut cme restre da una cpia di backup a fredd del database primari, per cui cnsistente. E pssibile attivare fin a trenta cpie di standby database tutte appartenenti ad un unica cnfigurazine Oracle Data Guard. Opprtunamente cnfigurat sia lat primary che standby, il meccanism di trasmissine dei redlgs ed applicazine degli stessi nei siti remti è cmpletamente autmatic. Cme il sit primari, anche l standby database può appartenere alla cnfigurazine single-instance RAC. Pagina 4 di 11
Rbert Scarpitti L standby database a differenza del primari è generalmente apert in mdalità recver, vver nn accessibile all estern, ma in cntinu aggirnament. In quest md tutte le transazini generate dal sit primari ed inviate tramite i prcessi Oracle al sit secndari, vengn applicate sull standby. Ovviamente le plitiche di recver e la scelta della cnfigurazine cmplessiva dipendn frtemente dalle esigenze applicative. Dalla versine Oracle 9i il database secndari può essere apert e accessibile e dalla 11g è addirittura pssibile lavrare in cnfigurazine updatable snapsht sul secndari, cme megli spiegat di seguit, per cui cn istanza aperta in mdalità read/write. Tiplgia di Standby Database Per prcedere cn il disegn dell architettura in Standby è necessari decidere a priri due aspetti: che tip di database secndari creare e quale livell di prtezine attuare all intera architettura lgica. Physical standby database Riprende la cnfigurazine riginaria del classic Standby Database: il database secndari è identic a quell primari, blcc per blcc; la sincrnizzazine avviene attravers l applicazine degli archive lgs e la base dati è chiusa, nn accessibile dall estern in quant in stat di recver. Dalla versine 11g release 1 (11.1.X) i red lg sull standby database pssn essere applicati anche se il database è apert in mdalità read-nly. Questa ptenzialità garantisce la massima prtezine dei dati ma anche la pssibilità di accedere in lettura per reprtistica agli stessi dati di prduzine, ma lavrand su database remt. Lgical standby database La base dati primaria è identica all standby sl a livell di dati mentre l rganizzazine fisica e la struttura dati ptrebbe essere differente; L allineament tra le basi dati avviene attravers l applicazine diretta degli statement SQL estratti dai red del primari ed applicati direttamente all standby database, per cui la base dati secndaria dvrà essere aperta. Quest cnsente l utilizz del database secndari nn sl per garantire il disaster recvery, bensì anche per sfruttare megli le attività di reprtistica ed infine per pter aggirnare l RDBMS Oracle sftware cn il minim dwntime di sistema sul primari. Snapsht Standby Database In quest cas l standby è apert e cmpletamente aggirnabile! Le transazini generate dal primari nn sn applicate direttamente sul secndari finché quest ultim nn viene riprtat nella mdalità di physical standby database, effettuand un rllback su tutte le transazini lcalmente applicate sull snapsht standby database. In sintesi il physical standby può essere apert in mdalità snapsht ed adperat cme se fsse un database primari, accedend ai dati in lettura/scrittura per fare test reprting massivi su delle immagini di database primari ed al termine di tutt, riattivare l allineament delle base dati tra primari e secndari. Ovviamente finché su tutte le transazini applicate sull snapsht standby database nn viene effettuata la rllback, quest nn sarà dispnibile per il sit di DR e la tempistica necessaria ad un eventuale failver switchver è direttamente legata alla quantità di transazini applicate. Pagina 5 di 11
Rbert Scarpitti Metdi di prtezine La scelta del metd di prtezine dati dipende dalle plitiche adttabili a frnte del disastr, ma anche dalle perfrmance che si vrrebber mantenere sul sit primari. Sulla base di queste scelte vengn cnfigurate le tecnlgie per determinare il livell di sincrnizzazine tra le basi dati ma anche quale livell di rischi di perdita dati garantire. Data Guard cnsente di scegliere di massimizzare un dei tre ambiti: prtezine dati, dispnibilità di servizi e perfrmance: 1. Maximum prtectin: garantisce il massim livell di dispnibilità e prtezine dei dati sul database primari e secndari, assicurand una perdita dati in cas di disaster pari a zer. In quest cas i redlgs del primari sn immediatamente inviati dal primari vers il secndari, realizzand csì una sincrnizzazine delle basi di dati cmpleta: la transazine sul primari è cmpletata e cmmittata sl quand c è la certezza che questa sia dispnibile ed applicata sul server secndari. Tale sluzine è adttata per sistemi ad alta prtezine cn almen due standby database ed un primari in cui basta che almen un dei due DB secndari abbia ricevut la transazine affinché il primari pssa ultimarla. Nel mment in cui l standby database risulta irraggiungibile anche il primari viene blccat, assicurand quindi che nessuna transazine venga persa. Tale sluzine è pssibile sl per physical standby database. 2. Maximum availability: questa cnfigurazine garantisce la massima prtezine a frnte di failures dvute ai cmpnenti singli della base dati(crruzine fisica dei datafiles) senza cmprmettere la dispnibilità del sistema primari. Anche in quest cas, la transazine sul primari è cmpletata sl quand c è la certezza che questa sia dispnibile su almen un server secndari però, a differenza della mdalità Maximum Prtectin, nel mment in cui l standby database nn è più dispnibile(a causa di prblemi di rete per esempi), il primari cntinua a lavrare nn creand quindi alcun disservizi. In quest md l standby database può tempraneamente divergere dal primari ma, nel mment in cui l standby trna ad essere dispnibile, verrà autmaticamente sincrnizzat al primari senza perdita di dati. Tale cnfigurazine è dispnibile sia per il physical che per il lgical standby database. 3. Maximum perfrmance: è la cnfigurazine di default in cui viene garantit il massim livell di perfrmance ma anche una limitata prbabilità di perdita di dati in quant le transazini vengn spedite dal primari al secndari in mdalità asincrna dai prcessi Oracle LGWR ARCH. La cmmit sulle transazini del primari nn è minimamente cndizinata dalla crretta applicazine della transazine sul secndari. Se l standby database si rende nn dispnibile per qualunque ragine, il database primari cntinua a lavrare indisturbat, evitand perdite di perfrmance e di servizi. Per tutte e tre le pssibili cnfigurazini di Data Guard è necessari apprre mdifiche pprtune ai parametri di istanza primaria e secndaria dell infrastruttura, per cui sarà necessari un ferm del database primari, un backup cnsistente dell stess, un restre sul secndari ed un avvi dell istanza in mdalità recver. La seguente tabella riassume le caratteristiche salienti delle tre mdalità: Prtectin Mde Rischi di perdita di dati Mdalità di invi transazini Maximum Prtectin Null; prtezine dppia dalle failures Sincrn vers due siti tramite LGWR Maximum Availability Null; prtezine singla dalle faillures Sincrn attravers LGWR Maximum Perfrmance Limitat tra 0 e diversi secndi Asincrn attravers LGWR ARCH La cnfigurazine maggirmente utilizzata è quella di default vver Maximum Perfrmance, in cui è più imprtante mantenere alt il livell di servizi sul master Pagina 6 di 11
Rbert Scarpitti mentre sul secndari, è cnsentit un margine di pssibilità di perdita di dati e quindi di divergenza dal primari. La mdalità di aggirnament del secndari può variare a secnda delle esigenze, ma sprattutt della frequenza cn cui vengn generati gli archive lgs sul primari, per cui si può scegliere di archiviare in autmatic le transazini sul secndari gni vlta che viene emess un archive lg nuv, piuttst che demandare a degli shell script tali cmpiti. Esempi di cnfigurazine: physical standby database Di seguit h rappresentat graficamente la cnfigurazine Data Guard su due siti, Master e Secndari, su una architettura a tre livelli basata su SAP. La prima rappresentazine riguarda il cas di funzinament nrmale, la secnda invece il cas di disastr. Client level SAP Gui Applicatin Level (SAP Server) CONFIGURAZIONE IN MODALITA NORMALE Netwrk Oracle Net Data Base Level Master Site (Primary Database Active Instance) Data Base Level Remte Site (Secndary Database Recver Instance) Netwrk base dati archive lg base dati archive lg Cme si può ntare dal grafic la base dati è acceduta sl dall applicatin server il quale punta al Master Site, mentre il database server secndari nn viene accedut. Sarà il database primari ad inviare le transazini generate dal primari anche sul secndari tramite gli archive lgs e, quindi ad applicarle sul secndari mantenend allineati i database. In cas di Disaster la nuva cnfigurazine diventerà la seguente, per quant cncerne la base dati: Client level SAP Gui CONFIGURAZIONE IN MODALITA DISASTER Netwrk Applicatin Level (SAP Server) Oracle Net Data Base Level: disastered site (Primary Database defunct instance) Data Base Level Remte Site (Primary Database Active Instance) base dati archive base dati archive lg lg Dp il disastr il database primari è inaccessibile, l standby è diventat primari e l applicazine punterà al sit remt invece che a quell riginari senza aver pers nessuna transazine derivante dal primari. Pagina 7 di 11
Rbert Scarpitti Servizi perativi della tecnlgia Data Guard Red Transprt Services La tecnlgia Data Guard fa us di tre tipi di servizi: un dedicat alla trasmissine dei redlg, un all applicazine degli stessi ed un alla gestine dei ruli delle istanze. Sn adibiti al trasferiment autmatic del cntenut dei redlg da database primari agli standby database. Queste le attività svlte: Trasmissine dei redlg dal database primari a tutti gli standby presenti in cnfigurazine Data Guard Risluzine del gap esistente tra gli archive lg spediti dal primari e quelli effettivamente pervenuti sui secndary; la differenza può essere causata da una caduta di rete tempranea assenza dei database secndari Individuazine degli archive lg persi crrtti sugli standby database e sstituzine degli stessi, richiedendli al primari ad altri database secndary che li hann ancra dispnibili Apply Services Si ccupan di applicare le transazini prvenienti dal database primari, sull standby, garantendne l allineament. La sincrnia è gestita tramite l applicazine degli archivelg, ve pprtunamente cnfigurat, direttamente degli standby redlg del secndari. La principale differenza tra il physical ed il lgical standby database risiede nella mdalità in cui i redlg sn applicati: Nel physical standby database Data Guard utilizza la tecnlgia REDO APPLY applicand le transazini sul database secndari in mdalità tradizinale cn DB in stat recver e nn accessibile. Nel lgical standby database Data Guard utilizza la tecnlgia SQL APPLY trasfrmand le transazini pervenute dal database primari in statement sql applicate al database secndari apert, in stat readwrite. Rle Transitins Un database Oracle può essere attivat in mdalità primaria standby: questi sn i ruli assciati alle istanze. Cn Oracle Data Guard è pssibile scambiare il rul delle istanze tramite le perazini di switchver e failver. Switchver è il rul che cnsente di eleggere un dei physical standby database a primari e, successivamente a far assumenre al primari riginari il su rul, senza perdita di dati. Questa tecnica viene impiegata nrmalmente durante attività di manutenzine prgrammata sul database primari, per cui il database primari assume il rul di standby ed un dei secndari assumn quell di primari fin al termine della manutenzine. Finita l attività I ruli vengn nuvamente scambiati cn un dwntime mlt bass e senza perdita di transazini, il rul è quindi reversibile. Failver invece è la situazine in cui il primari risulta inaccessibile per cui l standby database assume il rul di primari senza perdita di dati ed in mdalità irreversibile, per cui senza la pssibilità di ritrnare a rul secndari. L scambi di ruli all intern della cnfigurazine in Data Guard è gestita tramite cmandi SQL ppure tramite Data Guard Brker di OEM tramite l utility di riga cmand DMGRL. Pagina 8 di 11
Rbert Scarpitti Data Guard Brker Data Guard brker è un framewrk di gestine distribuita utilizzat per la creazine, la gestine e la manutenzine di Data Guard. Si può utilizzare sia Oracle Enterprise Manager graphical user interface (GUI) sia Data Guard cmmand-line interface (DGMGRL). Le principali perazini cnsentite tramite quest tl sn: Cnfigurazine di Oracle Data Guard, inclusi la definizine del red transprt services e degli apply services. Gestine e mnitring dell inter sistema Data Guard da un unic sistema in cnfigurazine single instance RAC. Switchver ed failver da interfaccia grafica da riga cmand tramite l utility DGMGRL. Abilitazine della facility fast-start failver cn cui, in maniera del tutt autmatica viene avviat il failver vers un istananza di standby specificata, nel mment in cui Data Guard Brker si accrge che l istanza primaria è diventata inaccessibile, senza l intervent di un DBA. Tramite Oracle Enterprise Manager è inltre pssibile: Creare un physical lgical standby database partend da una cpia di backup cnsistente di un database primari. Aggiungere un nuv standby database ad una cnfigurazine Data Guard già presente. Mnitrare l inter sistema, verificand la frequenza di applicazine dei redlgs, le infrmazini relative a prblematiche di disallineament e perfrmance. Avviare chiudere istanze. Verificare eventi e schedulare jbs. Avviare prcessi di backup e recvery. Pagina 9 di 11
Rbert Scarpitti Data Guard e le tecnlgie avanzate di Oracle Per massimizzare i servizi in alta affidabilità rendend i sistemi ancra più sicuri e facilmente ripristinabili a frnte di failure, Oracle integra in maniera del tutt nativa Data Guard cn RAC, Flash Back Recvery e Recvery Manager. Oracle Real Applicatin Clusters (RAC) Flashback Database Recvery Manager (RMAN) Il cnnubi tra RAC e Data Guard prta ad avere i sistemi al più alt livell di prtezine ed affidabilità, garantend cntinuità di servizi a frnte di prblemi hardware, sftware, crruzine dati e perdita di dati. Flashback Database cnsente invece di recuperare i dati a frnte di crruzine lgica degli stessi a frnte di errri umani, andand a ripristinare le infrmazini ad un istante prima dell avvenuta crruzine perdita di dati, eliminand la necessità di restrare l inter database da un backup cnsistente. L utilizz del Flashback Database cnsente inltre di ridurre il temp di delay di applicazine dei redlgs sull standby database, nrmalmente attuat per prteggere cntr errri lgici di crruzine. Riducend il temp di delay si riduce anche il temp di failver e di switchver. Infine attivand Flashback Database sull standby database si evita di dver ricreare cmpletamente i siti secndari dp il failver. Recver Manager(RMAN) è una feature integrata in tutte le installazini Oracle che nn necessita particlari cnfigurazini ma che, integrat cn Data Guard, cnsente di creare un nuv standby database dal backup del primari utilizzand il cmand DUPLICATE, attivand le plitiche di backup sull standby database invece che sul primari. Pagina 10 di 11
Rbert Scarpitti Perché scegliere Oracle Data Guard 11g I principali benefici fferti da questa architettura sn principalmente 6: 1. Implementazine dell alta affidabilità e prtezine da eventi di disastr, grazie alla cnfigurazine distribuita, ma anche di prtezine a frnte di crruzine fisica dei dati, cn bassi tempi di disservizi, garantend zer data lss. 2. Differenziazine nella scelta delle plitiche di implementazine di Data Guarding rispett agli aspetti salienti quali perfrmance, prtezine dei dati e livell di servizi. 3. Centralizzazine e semplificazine del prcess di gestine di Data Guard, cn l intrduzine di Data Guard Manager, una interfaccia grafica di Oracle 11g. 4. Assunzine dei ruli di Switchver per l switch temprane del sit primari sull standby, a frnte di manutenzine preventiva(reversibile) del sul di Failver in cas di disastr failure(irreversibile). 5. Ottimizzazine delle risrse hardware utilizzate, riducend il caric di lavr sul server primari e distribuendl invece sui siti di standby. 6. Integrazine di Data Guard cn RAC ed RMAN che cnsente di garantire massima prtezine, massima dispnibilità e massime perfrmance. Pagina 11 di 11